5.4 Functional Test Design

Functional testTest (FCT) is the pointfinal wherestage of the electrical quality strategy, confirming that the fully assembled product meets its customer-defined behavioral and performance specifications. Unlike structural tests (ICT/BSCAN) which check connectivity, FCT validates the integration of all hardware and firmware under simulated operating conditions. FCT carries a boardhigh stopsNRE being(Non-Recurring Engineering) cost due to custom hardware and complex software development, making its design efficiency critical for manufacturing throughput.

5.4.1 FCT vs. Structural Test: The Critical Difference

FCT assumes all structural faults (shorts, opens, wrong parts) have been eliminated upstream by faster, cheaper methods (Chapter 5.1). FCT focuses on complex defects.

Test Type	Objective	Defect Type Covered	Cost Implication
Structural (ICT/BSCAN)	Verification of Assembly. Checks physical connections and passive values.	Open Circuits, Short Circuits, Missing Components, Wrong Value.	Low CoT (Fast cycle time, cheap diagnosis).
Functional (FCT)	Verification of Behavior. Checks system timing, firmware, I/O protocols, and performance under load.	Timing Errors, Logic Bugs, Power Integrity Issues, Firmware/Hardware Integration Failure.	High CoT (Slow cycle time, complex diagnosis, high development NRE).

Mandate: The FCT stage must not waste time diagnosing simple shorts. If FCT frequently flags structural errors, the ICT/BSCAN coverage upstream is inadequate and requires immediate tuning.

5.4.2 Fixture Design and Custom Hardware

FCT fixtures are custom-built systems designed to simulate the product's operating environment. Fixture complexity is a setmajor driver of assembled partsCapEx and must provebe it behaves like the finished product. Unlike structural tests, which catch build defects, FCT validates power sequencing, firmware operation, and critical use-case paths under controlled conditions. Golden Units anchor trust, while disciplined power-on safety and guard-banded parametrics keep both boards and operators safe. By trimming scope to only customer-relevant checks and logging results rigorously, FCT balances assurance with speed, avoiding the trap of turning production into a lab experiment.

5.4.1 What FCT is (in plain words)

Functional test (FCT) answers: minimized.“Does this board actually work?” You’ve already caught most build faults with ICT/Probe/BSCAN/AOI/AXI. FCT powers the PCA safely, loads the right firmware, talks to its interfaces, nudges peripherals, and checks a short list of parametrics that matter to the customer.

Mindset: fail fast on basics (power, ID, clocks), then prove a few use-case paths—not a full lab characterization.

---

5.4.2 Power-on safety (protect the DUT and the humans)

Before any code runs, make turn-on boring and safe.

Hardware

• Current-limitedCustom suppliesI/O: for each rail; per-rail fast cut-off.
• E-stop and interlocks: no power unless clamps closed /The fixture safe.
• Seriesmust safetyincorporate onspecialized I/Oloads, tosensors, thesignal outside world: resistorsgenerators, or bufferscommunication so you can’t drive a customer port into a short.
• Loads you control: electronic loads or resistor banks with relays, not improvised heaters.

Sequence (always this order)

1. Smoke check: power-off shorts/opens on main rails (mΩ or isolation test).
2. Soft power-up: enable primary rail → measure inrush/steady current.
3. Secondary rails: enable in order; verify voltages, ripple, and reset timing.
4. Safe state pins: force drivers off, H-bridges idle, backlights/RF disabled.
5. Only then run firmware.

If any step fails, drop power and flag NG. Don’t “retry until it works.”

---

5.4.3 Golden Units (GU) & reference artifacts

A Golden Unit is a known-good DUT you trust more than your tester.

• Keep two GUs: one for electronics, one for mechanics/fit (if your fixture mates connectors).
• Stamp each with firmware version, calibration constants, and a service life (# of runs or months).
• Run a GU pass at the start of each shift and after any tester change (code, cables, instruments). If the GU fails, stop—fix the tester first.
• Retire GUs on a schedule; store their last passing logs.

Other artifacts: loopback dongles, attenuators, sensor simulators, and a “fixture self-test coupon” that proves switching and measurement channels without a DUT.

---

5.4.4 Firmware load & configuration (fast, deterministic)

• Prefer programming earlier (BSCAN/ICT) to keep FCT short. If FCT must program:
• • Use a signed, versioned image; verify hash after write.
  • Provision SN/MAC/keys atomically with the image; store them in the log.
  • Control VTREF/reset/boot pins from the tester; isolate shared busesloopbacks (e.g., SPIEthernet flashloopbacks, vsoptical MCU)sensor withsimulators) seriesthat resistorsmimic the external devices the product interfaces with.
  • Power Supply and Measurement: It requires programmable power supplies to simulate various input voltages (e.g., battery low/high) and precision digital multimeters (DMMs) or tristate.oscilloscopes to measure critical voltage rails, ripple, or current consumption.
  • Minimizing Contact: Unlike ICT's "bed-of-nails," FCT fixtures aim for minimal contact via a single edge connector, programming header, or small, non-intrusive probe field. This reduces mechanical complexity and long-term fixture maintenance.
  • Safety Interlocks: Mandatory interlocks (hardware switches) ensure the fixture lid is fully closed and the unit under test (UUT) is secured before high voltage is applied, protecting both the operator and the test system.
• Time budget: programming must fit TAKT or be off-line/batched.
  

---

5.4.53 TesterSoftware, architectureThroughput, (blocksand thatFault scale)Isolation

StimulusThe FCT software is the most complex NRE component. Its design must prioritize speed →and DUTdiagnostic → Measurement

   |         |        |

 PSU/Loads   Firmware  DMM/DAQ/Scope/RF/Audio

 Switches    Drivers   Matrix/Relaysclarity.

• 
  SwitchTest matrix/relaysScript Optimization: routeThe signalstest andsequence loads;must defaultbe optimized to safefail fast. The script should check high-failure-rate blocks (e.g., power rails, processor boot) before initiating long, complex tests (e.g., memory burn-in, full protocol validation).
• Fault Isolation: When a test fails, the software must instantly identify the failing function and translate that failure into a precise, localized diagnosis (e.g., "U7 comms failure - check SPI bus lines 4-6"), directing the repair technician to the smallest possible area. Simply returning "Fail" is unacceptable.
• Test Core Parallelization: FCT is often the bottleneck. Throughput can be doubled or tripled by building parallel-core FCT systems, where one fixture and one PC simultaneously test two or more boards. This amortizes the fixture and software development cost over higher volume.

5.4.4 Data Logging and Traceability

FCT data is the final, auditable record of product quality.

• Data Capture: The FCT program must log the following for every UUT: Test Start/Stop Times, Cycle Time, Firmware/Software Version Used, and Actual Measured Values (not just Pass/Fail status) for critical parameters (e.g., current draw, output voltage).
• InstrumentsTraceability Link:: PSUThis +complete DMMdata aslog must be immediately linked to the core;board's addunique DAQ/scopeserial fornumber timing,(SN) SMUin forthe precision,MES audio/RF(Chapter only if your product needs it.5.5).
• ProtocolYield boxesAnalysis:: USB/Ethernet/CAN/LIN/I²C/SPI/UARTFCT mastersresults provide the cleanest data on design flaws (e.g., if a specific logic block consistently fails) or systemic component issues. This data must be fed back to exercisethe portsdesign and sensors.
• Simulator fixturesteam: sensorto emulatorsdrive (thermistors,product bridgereliability sensors), loopback plugs, and dummy antennas/attenuators.improvements.

Keep

Final itChecklist: modular:FCT swapDesign aMandates box, not the entire tester.

📋

---

5.4.6 Parametric verification (measure what matters)

Pick a few numbers that prove function without killing TAKT.

AreaRequirement	TypicalDesign checksMandate	NotesThroughput/Cost Impact
PowerTest Scope	RailFocus V/I100% aton idlefunctional &behavior oneand loadcustomer-facing point;features ripple;(power, PORI/O, timinglogic).	Guard-bandAvoids towasting measurementtime uncertaintyon structural faults already covered by ICT/BSCAN.
ClockingFixture Simplicity	MainFixture oscuses ±ppm;minimal PLLcontact lockpoints (edge connector/header preferred) and safe interlocks.	ShortReduces gateCapEx time;and pass/fail,minimizes notmechanical a thesismaintenance/wear.
DigitalSoftware I/OEfficiency	GPIOScript wiggle;is LEDoptimized on/off;to buttonFail readsFast and test high-risk blocks first.	QuickMaximizes loop;throughput recordby responseminimizing timestest iftime criticalfor defective units.
CommsFault Diagnosis	USB/EthTest linksoftware up;provides ping/loopback;a seriallocalized echodiagnosis (component or net) for every failure.	LogDrastically linkreduces speed/PHYrepair ID;time MAC/SNand setcost.
Sensors/ADC/DACCapacity Planning	2–3FCT calibrationstation pointscapacity is ≥ line TAKT time, often achieved via simulatorsparallel-core testing.	Linear spot-check, not full INL
Audio (if any)	THD+N at 1 kHz; gain	Use known load/attenuators
RF (if any)	Output power/EVM/channel mask (lite)	Use shielded box/attenuator; or sample offline

Guard-banding: set limits wider than customer spec by your uncertainty and drift. If spec is tight, calibrate instruments more often or sample deep tests.

---

5.4.7 Time & coverage (hit TAKT)

• Fail fast: shorts → rails → ID → clocks → comms →Prevents the one or two use-case paths.
• Parallelize independent waits (e.g., gather multiple rails in one DAQ sweep).
• Skip logic: if a port isn’t populated on this variant, don’t test it.
• Sampling: heavy RF/audio tests on N-of-M boards if allowed; 100% on critical safety paths.
  

---

5.4.8 Data & traceability (make results useful)

Log everything needed to reproduce decisions:

• Board SN, work order, date/time, station ID, tester software rev, instrument cal due dates.
• Firmware image ID/hash, keys/MAC/SN burned.
• Raw readings + limits used + pass/fail per step; graphs only when needed.
• Attach plots (e.g., power-up current vs time) for golden runs.
• Push records to MES; block pack-out if no record.

---

5.4.9 Tester care: calibration & self-health

• Daily: fixture visual check, connector clean, GU run.
• Weekly: switch/matrix self-test with coupon; cable wiggle check.
• Monthly/Quarterly: instrument calibration (per cert), PSU foldback trip tests.
• Spares: one fully imaged hot-swap PC, spare key cables/relays/instruments.
• Version control: tests are code—git them; tag releases that shipped product.
  

---

5.4.10 Common pitfalls → quickest fix

Pain	Why it happens	First fix
Random FCT fails	Flaky cables/ground loops	Shorten grounds; replace suspect harness; add ferrites
Brown-outs on power-up	Loads enabled too early	Delay loads; raise PSU current limit carefully
Tester “passes anything”	Limits too loose / drift	Re-run GU; restore limitsstage from repo;becoming recal instruments
Long test time	Doing lab work inthe production	Trim to fail-fast; sample deep tests; move programming upstream
Intermittent comms	Fixture strain on connectors	Add strain relief; reduce mating cycles; use better guides
ESD zaps DUT	No discipline at station	Add mats/straps; bond tester chassis; ESD auditsbottleneck.

---

5.4.11 Pocket checklists

Design (before you build the tester)

• Power-on sequence defined; rails/current limits chosen
• Golden Unit(s) identified; sensor/loopback simulators listed
• Firmware image & provisioning plan (keys/MAC/SN) fixed
• Parametric list trimmed to customer-meaningful items
• Data schema agreed (fields, limits, attachments)

Bring-up (first week)

• GU passes end-to-end; failure of GU blocks lot
• E-stop/interlocks verified; default state is safe/off
• Programming time within TAKT; hash verified
• Logs land in MES with all IDs

Daily run

• GU at shift start; fixtures clean; cables seated
• Fail-fast sequence intact; no “retries until pass”
• Top 3 failure codes reviewed; obvious process drifts routed upstream (print/reflow/placement)
  

---

A well-planned FCT flow ensures confidence in shipped products without burdening throughput. Done right, it keeps failures meaningful, prevents escapes, and delivers proof that each board truly works in the way customers expect.