Board test and fault diagnosis — fixture, vectors and a trained baseline

The situation

Testing digital boards sits between two unsatisfying options. A general-purpose automated test platform is programmable and precise, and it costs enough, and takes long enough to program, that it only makes sense at volume. Manual bench testing with a technician and an oscilloscope is fast to start and produces results that depend on which technician is working and what they had for lunch.

For repair operations the second problem is sharper than the first. A technician who is told a board has failed cannot act on that. They need to know which net to probe, and they need the answer before the board has been handled three times by three people.

The other constraint is quantity. Repair benches see a long tail of boards — many models, few units each, and the models change as equipment ages out.

The call we made

Specialise per product, not per bench. The system is built around a dedicated interface matching fixture and a test vector program set for each board type, rather than one universal probe arrangement. Adapting to a new board is then a fixture and a vector set, not a new system. That is the only way a bench can cover a long tail of low-volume boards without the test engineer becoming a bottleneck; it also means the per-product work is bounded and quotable.

Build the standard from the specimen, not from documentation. A pass/fail threshold set from a datasheet needs documented references that usually do not exist for boards in service. So the system trains and learns from known units to establish the test standard, and diagnoses against that baseline. This is the pragmatic answer for legacy hardware: the reference is a good board, and the reference is captured as data rather than as a note in a drawer.

Output the failing channel, not a verdict. The system reports fault channel information in seconds. Pass or fail tells a repair technician nothing; a channel narrows the search to a region of the board, which is where repair time is actually spent. The difference between a verdict and a channel is the difference between a screening tool and a diagnostic tool.

The software side is half the system. Hardware measures; software records, computes and displays. Raw test data, judgement criteria, board records and a fault knowledge base on one side; task management, judgement, trends, reports and production dashboards on the other. Without that layer the instrument produces readings that nobody can trend, and a board population cannot be compared across months. On the delivery side this is also the choice point: the platform can be delivered as software alone against a customer’s existing hardware, or as hardware and software together.

Define the interface once, at proposal stage. With a hardware and software split in the same system, the interface between them is where schedule is lost. It is fixed before implementation rather than negotiated during integration, and board models are added by extending vectors rather than by changing the architecture.

What we built

Test execution — the board under test, matching interface fixture, stimulus and acquisition, vector program execution.
Training and baseline — the standard learned from known units, stored per board type so it can be reviewed and versioned.
Diagnosis output — automatic fault diagnosis with channel-level results and measured values, in seconds rather than after a batch.
Data layer — raw test data, judgement criteria, a record per board and a fault knowledge base.
Software platform — test task management, judgement, trend and statistics, report export, with hooks into repair work orders and quality traceability.
Coverage — digital boards and related assemblies, more than 32 IO lines with expansion, channel drive above 24 mA, in a 0–40 °C operating envelope from a 210–230 V single-phase supply at up to 1500 W.

Status, stated precisely: technical demonstration, development, prototype integration and technical verification were completed over the past two years, and the technical baseline is mature. There is no instrument in stock at present; a demonstration or a delivery requires a new production slot, scheduled per project. The hardware specifications above are the publicly disclosable subset, and they move with component selection — the current version is confirmed with the technical partners before any commitment.

Result

The useful outcome is a bench that can be handed to a technician rather than to an engineer: insert the fixture, select the board type, get the failing channel. Used at the front of a repair flow it screens incoming units; used in production it gives a consistent first test; used in training it gives a trainee the same verdict a supervisor would.

The honest limits: the fixture and vector work is per board type, so a model that will never be seen twice is not worth instrumenting; and the system diagnoses against a reference population, so it needs a supply of known-good units to establish the baseline. Both are properties of the method, not defects to be engineered away.

Operator station: the test console, with the signal display above the instrument bay

Technology

Stack	Custom interface fixture · Test vector programs · Digital IO · Embedded control · Test management software
Delivery model	Cooperative capability: test system, software side optional
Client	Electronics manufacturing and repair operations
Status	MVP / pilot

What we cannot show

Hardware capability held jointly with long-term technical partners: cooperative, not a proprietary product line, and hardware specifications or delivery dates are not committed under our own name. No instrument is currently in stock; a demonstration or delivery is a new production slot. Only the console photograph is available as an asset — the bench and software screenshots are still missing.