Functional Test Software for Embedded SBC Production: What Should Be Automated?

If an operator can make a board pass by clicking Start several times, the production dashboard may look healthy while the process is getting worse. A weak fixture contact, unstable supply, or marginal interface can disappear into an overall green result unless the test software preserves attempts and measurements.

Functional test software for embedded SBC production should automate repeatable stimulus, measurement, comparison, and recording. Its value comes from consistent decisions and useful failure evidence. Start with the defects the station must catch, then choose the instruments, fixture, software, and operator steps needed to detect them.

Discuss that coverage during embedded board manufacturing planning, while test access and production image behavior can still be changed.

Define defect coverage before writing scripts

List likely assembly and configuration faults: missing components, wrong storage variant, damaged connectors, poor solder joints, swapped cables, missing radio firmware, incorrect image, and duplicate identifiers. Map each fault to a test that could actually detect it.

A port enumeration check may prove that a controller exists but leave its external connector untested. A local software loopback may bypass the transceiver or magnetics. Be explicit about the boundary reached by each stimulus.

Separate development qualification from production screening. Long thermal campaigns and destructive margin tests serve a different purpose from checks on every unit. The production sequence should target the agreed risks within the required station cycle time.

Automate measurements with stable references

Automated checks work well when the result has a clear limit and the station provides a controlled stimulus. Rail voltage, image identity, storage capacity, communication errors, digital I/O, and programmed identity are good starting points.

Keep visual and acoustic checks where the measurement method is not yet reliable. A guided operator step can be appropriate if it uses a known pattern, explicit acceptance criteria, and a recorded result. Calling every subjective inspection “AI vision” does not make the criteria repeatable.

Separate the sequence from measurement code

The sequence should decide order, product configuration, limits, retry policy, and result handling. Instrument adapters and board commands should return measurements or structured errors. This makes it easier to reuse a voltage measurement when a product variant has different approved limits.

NI’s test module development guidance describes returning measurement values for evaluation by the sequence. That separation is useful whether the station uses TestStand or another maintained test framework.

Version the limits independently where the chosen system supports it, but approve them together with the sequence. A wider limit can change outgoing quality as much as a code edit. Production should not silently inherit an engineer’s local configuration file.

Give the fixture its own health checks

Before blaming the unit, verify the station supply, instrument communication, fixture closure, cable presence, and reference endpoint. Track fixture identity and maintenance, including pogo-pin replacement and connector wear.

Use known-good units for repeatability checks and controlled fault samples to confirm defect detection. A station that passes a reference board but also passes a deliberately disconnected test path has inadequate coverage.

The functional fixture design should provide access to the signals needed by the software. In a custom SBC design, include locating features, programming access, and test pads early enough for the station concept to influence layout.

For parallel fixtures, verify channel isolation and identity mapping. A result from the neighboring unit is worse than an obvious timeout because it can produce a plausible but incorrect pass record.

Preserve measurements, limits, and attempts

An overall pass flag is useful for the operator. Engineering needs more detail. Save the measurement, unit, limits, test ID, result status, elapsed time, and the software configuration used for each step.

This fictional result illustrates the structure; the limits are examples, not production specifications:

{
  "unit_serial": "EXAMPLE-0001",
  "fixture_revision": "A2",
  "sequence_revision": "1.4",
  "attempt": 1,
  "test_id": "SUPPLY_5V_IDLE",
  "value": 5.03,
  "unit": "V",
  "limits": {"minimum": 4.85, "maximum": 5.15},
  "status": "pass"
}

The complete record should add hardware and image identity, station ID, timestamps, instrument details where needed, and any operator intervention. Keep credentials and private keys out of ordinary test output.

Plan what happens when the reporting server is unavailable. A controlled local queue may be acceptable; define reconciliation and release rules so an unrecorded result cannot simply disappear after shipment.

Make retries visible and bounded

Some tests need a defined retry because a network endpoint or instrument takes time to settle. Specify that behavior per test rather than applying a global retry-until-pass loop.

Retain the first failure and every later attempt. Distinguish product failure, fixture failure, infrastructure error, and aborted test. These categories let quality teams investigate the process without counting all events as bad boards or hiding all of them as station noise.

If reseating a board restores operation, record the action. Investigate whether contact wear, board flatness, contamination, or a connector problem caused it. Repeated reseating is a process signal even when the final attempt passes.

Optimize the slowest meaningful steps

Measure where cycle time goes: flashing, boot, instrument settling, network transfer, manual handling, and data upload. Parallelize only independent steps whose interactions are understood. Concurrent radio traffic and power measurements, for example, may change the result being evaluated.

Use product variants to select the approved sequence. A board without a populated radio needs an explicit variant configuration, not an operator who remembers to skip the red wireless test. Validate the variant against observed hardware identity where practical.

Preserve coverage when reducing time. Shortening a storage or traffic test should be justified by defect-detection evidence, not just a faster station dashboard.

Release the station alongside the product

Treat the test software as a controlled production deliverable. Archive the sequence, configuration, limits, instrument settings, fixture drawing, dependencies, reference samples, and maintenance instructions. Define who approves changes and how a station is restored after a computer replacement.

During pilot-run quality review, examine first-pass yield, retest frequency, common failure codes, and differences between stations. Sample raw records rather than reviewing only totals.

Before volume release, demonstrate a good unit, representative faulty units, a station fault, an interrupted run, and an unavailable reporting service. A useful production system reaches the correct decision in each case and leaves enough evidence for the next person to understand it.