The boards have arrived. Why is your engineer still spending all day preparing them?

The assembled boards arrive from the factory. Then an engineer spends the next two days loading firmware, typing serial numbers, setting calibration values, checking outputs and recovering the units that did something unexpected.

For ten early prototypes, that may be exactly the right use of engineering time. For two hundred units of a stable design, it is manufacturing work that has never been turned into a manufacturing process.

Write down what happens between assembled board and saleable unit

Start with the actual work, not an automation project. Follow one unit from the box the assembler shipped to the state in which it can be packed for a customer.

The list may include loading a bootloader or application image, assigning a device identity, writing configuration, pairing a modem or SIM, loading certificates, setting calibration values, exercising inputs and outputs, checking communications, fitting the enclosure and recording the result.

Have someone other than the designer follow the process. The aim is not to prove the designer is replaceable. It is to find every point where the process still depends on something that exists only in their head.

If the instruction is 'ignore that warning' or 'sometimes it needs another power cycle', stop there and decide what the warning means. Production work needs an outcome a competent operator can recognise without rediscovering the product every time.

Separate provisioning from testing

Provisioning puts the unit into its intended state. Testing establishes whether it got there and whether the hardware behaves as required. Those are related jobs, but keeping them conceptually separate makes failures much easier to reason about.

A provisioning step might write software version 2.4.1, install a device certificate and assign serial DP-004812. A test step might then confirm the expected firmware is running, the serial can be read back, Ethernet negotiates, two digital inputs change state and an analogue channel falls inside its allowed range.

If the test changes the product while it is checking it, make that explicit. Calibration is an obvious example: measurement produces a value that is then written into the unit. Record the value, the method and the version of the calibration process that produced it.

Give every board the same examination

The test harness is often a collection of scripts and physical wiring. Sometimes it is a professionally built fixture with a bed of pins and a lid. Sometimes it is a bird's nest of breadboards, USB adaptors and jumper leads. Either can do useful work. What matters is that every new board connects to it and goes through the same checks.

The harness loads test firmware that exercises the board's hardware. On the other side of the connectors are known loads, loopback connections and programmed interfaces. Digital outputs drive something whose response can be measured. Inputs receive known signals. Serial ports exchange data with a loopback or another device. Analogue channels see known voltages. Where appropriate, the test cycles outputs under load and runs interfaces repeatedly to expose intermittent faults that a single successful exchange would miss.

The fixture needs to test the path you intend to ship. Reading back an output register proves very little about the connector, solder joint or driver beyond it. A loopback through the physical connector checks more of that path. A representative load checks something else again. Decide what each test establishes, then give it a clear pass limit.

Once the board passes, the process installs the production firmware and configuration, verifies that it boots, and records the result against the unit's identity. Version the harness scripts and test firmware too. When a batch starts failing, you need to know whether the boards changed or the thing testing them did.

Make the unit record useful

You do not need a factory MES to get value from traceability. A useful first record can be very small: unit identity, board revision, software version, relevant configuration or calibration revision, test result and the time it was prepared.

That record pays for itself the first time support needs to know whether a field failure belongs to one board revision or one batch of firmware. It also lets manufacturing answer a basic question without opening the enclosure: what exactly did we ship?

Do not record everything merely because it is measurable. Keep what helps reproduce the build, investigate failures or establish that the required process ran.

Put the repeated decisions into the tooling

Once the manual path is understood, remove decisions that do not need a person.

The programming tool should select the approved release rather than asking an operator to browse for a file. Identity assignment should refuse duplicates. Configuration should come from a controlled source. A test should end with a clear pass or a failure that identifies what failed.

Do not hide useful engineering information to make the screen look simple. Keep the detailed log, measurements and programmer output behind the result so that a failed unit can be investigated without reproducing the entire session.

Decide what the assembler should do

Once the process is defined, ask the assembler to quote the repeatable parts. Programming, serialisation and functional testing are normal manufacturing services for some suppliers and awkward extras for others. The important thing is that you can now give them a concrete job to price.

The handover package should say what equipment is needed, what files and versions are authorised, how identities are allocated, what constitutes pass or fail, what data must be returned, and what happens to a failed unit.

If the assembler is not the right place to do it, the same definition lets you build a small internal production station or give the work to another contractor. You are choosing where a process runs rather than relying on one engineer to keep doing it forever.

Give failed units somewhere to go

A production process needs a failure path. Otherwise the operator retries until the unit passes and nobody learns that the product or test process has a problem.

Allow the obvious deterministic retries where they are understood: reseat the fixture, retry a programmer connection once, restart a known flaky external instrument if that is genuinely part of the test procedure. Then stop.

Keep the failure information and move the unit to investigation. Engineering can decide whether it is a manufacturing defect, a test-fixture problem, a design issue or a bad assumption in the pass criteria. If the same fault appears repeatedly, fix the process or product rather than normalising the rework.

The economics appear quickly

If final preparation takes twenty minutes per unit, two hundred units consume about 67 hours before interruptions and failures. That is nearly two working weeks. The number is illustrative, but the calculation is worth doing with your actual process.

Now compare the cost of keeping that work in engineering with the one-off effort to make it repeatable, the assembler's charge to perform it, or the cost of a simple production station. Include the investigation value of having engineers touch the early units; that value may be high for the first batch and close to zero once the same steps have become routine.

This is why the right answer changes with maturity. Ten boards that exist to expose design problems should probably receive engineering attention. The hundredth board of an unchanged product should not need an engineer to remember which command comes next.

A useful handover is boring

A good production preparation process is deliberately uninteresting. The operator connects the unit, the approved software is loaded, identity and configuration are applied, the test runs, the result is recorded, and failures leave enough information for somebody else to investigate them.

That is not glamorous automation. It is the point where the company stops manufacturing its product through repeated acts of engineering memory.