Electronics Testing Before Mass Production

The limits, the sample and the configuration belong to a named revision. Change the supply, the firmware or the enclosure and you have a new question, not a footnote. Every figure below is hypothetical teaching maths. None of it is a yield, a field-return rate, or a BrahmWorks test result.

Design verification uses the limits from the product frame: electrical, timing, thermal, and whatever else you wrote, on units whose identity you can trace. The method says how many units, in which configuration, at which supply and temperature if those were in the limit, and what a failure means. A failure is a design change, a limit change, or an accepted gap with an owner. It is not averaged away because two other units passed.

The line test is built after those limits exist. It does not try to repeat the whole verification on every unit. It looks for the faults assembly can introduce: wrong population, opens and shorts the in-circuit or fixture can see, a dead programming step, a calibration missing, a function that must work for the unit to be worth shipping. A line test that never existed is how the verification samples, hand-built and hand-chosen, become the only good units you ever made.

The hardware product development process keeps these records apart on purpose. Bring-up is a third activity: the first careful power-up. It is not a substitute for either test. Environmental or electromagnetic evidence, where your market and your claims need it, is its own method on a stated configuration. Do not describe a functional pass on the bench as that evidence.

A limit for each step, written so two operators would make the same pass or fail. A fixture or a procedure that presents the unit the way it is shipped, or a written list of what is different. A way to program the image, read back an identity, and store the result against a serial number. A rule for retries: how many, and when a retry is itself a fail because the connection is intermittent.

Prefer checks that catch a class of assembly fault over checks that re-prove the laws of physics. A rail window, a current ceiling, a bus transaction with a known part, a calibration constant stored and read back: these sort units. If a fault class can escape, name it. An unnamed escape is how a "full functional" claim grows while the fixture still cannot see a backwards diode.

Firmware for the line may be the field image in a test mode, or a separate image. Either way, the mode must not be what the customer can stumble into, and the identity in the record must show which image was tested. A unit tested on different firmware from the firmware you ship was not tested as the product, unless you have shown that the difference cannot hide the faults you care about.

You do not need a theatrical sample to learn that a rail falls over at the low supply, if you have not yet tested the low supply. Corners you already wrote — supply, temperature, a discharged cell — belong in verification because they are the requirement, not because a spreadsheet demanded more units. Add units only when the failure varies and you need the spread. Repeating one easy condition is not confidence.

A large build also needs a first-article check that the production process, not the prototype process, built what you specified: materials, finishes, torques, images, labels. Electronics testing does not catch a wrong plastic. Leaving that to "the contract manufacturer" without a record is how the first large build teaches you the process in public.

Safety faults and claims you make to a customer are not an expected-value exercise. A cheap fixture is not a reason to skip a check whose failure can hurt someone or void the thing you promised. The arithmetic later in this article is for ordinary assembly escapes. It is the wrong tool for hazard.

Invented product: a small mains-adapter-powered meter with a sensing front end, a microcontroller, and a communications port. Teaching verification limit, written before the run and not taken from a lab: at the adapter's low and high teaching voltages, the reading over a stated input must stay within a stated band, on three units, enclosure closed, field image loaded. The numbers in the band are yours to set from the requirement. They are not supplied here, because a borrowed band would look like evidence.

Teaching line test, deliberately shorter: program the image, read identity, check the idle current against a ceiling, check the rail window, exchange one known message on the port, store a calibration, fail the unit if any step fails twice. The line test does not repeat the three-unit accuracy study. It assumes verification passed on this revision, and it tries to catch a unit that was built wrong.

Invented assumptions, not a yield and not a field study:

• A fault class the proposed line test cannot see, such as a diode fitted backwards that still allows a crude power-up, is imagined at 2 units in every 100.
• The large build in this exercise is 500 units.
• A teaching cost to find and handle one escaped unit later is INR 1,500.
• A fixture addition that would see this class is INR 40,000, invented.

Expected escapes in the build, if the imagined rate were true: 0.02 × 500 = 10 units. Teaching cash: 10 × 1,500 = INR 15,000. The fixture addition at INR 40,000 is larger than INR 15,000. On these inventions, expected cash does not by itself justify the addition.

The rate that would tie the fixture is 40,000 / 1,500 = 26.7 escapes in the batch of 500, which is 26.7 / 500 = 0.053, or about 5 in 100 rather than 2 in 100. If you cannot defend even a rough rate from a pilot, you cannot run this comparison. Leave it blank. If the fault can hurt someone, do not run it at all; the INR 15,000 is not the cost that matters.

What the arithmetic is for: stopping a review from saying "add every check" or "add no checks" as a mood. What it is not: a measured escape rate, a promise about the meter, or a reason to delete a check you already know verification depends on. Accuracy across three units remains a verification question. The fixture does not retire it.

• Verification limits are written, with configuration, revision and what a failure means.
• Line-test limits are separate, and two operators would agree on pass and fail.
• The line presents the unit as shipped, or the differences are listed.
• Programming, identity and results are stored against a serial number.
• Retries are limited, and intermittent contact is defined as a fail at a stated count.
• Fault classes the line cannot see are named, not covered by the phrase "full functional".
• The image under test is the field image or the difference is justified.
• Supply and temperature corners in the requirement have been run in verification, not assumed.
• Sample size has a reason: a corner, or variability, not ceremony.
• First-article process checks exist for what electronics test cannot see.
• Safety-related checks are not justified by expected cash.
• Bring-up notes have not been filed as if they were verification.

No. A functional test asks whether this unit behaves against your limits on the bench you defined. Electromagnetic evidence, when your claims and your market require it, is a method on a named configuration in a lab set up for that method. Passing messages on a desk does not generate that evidence. Failing to name the claim does not make the method optional by silence; it means you have not decided what you are selling.

Enough to cover the configurations your limits actually name, and more only where you have seen or expect spread. Three careful units at the real corners teach more than thirty at one comfortable voltage. If a process is new — a finish, a seal, a programming fixture — the first articles of that process are the sample that matters, and they are not interchangeable with hand-built prototypes.

Yes, unless a test mode or a separate image is the only practical way to reach a point, and you have shown that the difference cannot hide the faults you are sorting for. Record the identity either way. A unit that leaves the line on an image the customer will never run has been tested as a relative of the product.

The unit identity, the hardware and firmware revisions, the fixture or procedure revision, the limits used, the result of each step, and the time and place if those ever matter to a dispute. "Passed" with none of that is a sticker. A failure record includes the step and the measured value, not only a red cell, so the next revision can see what moved.

Bring the verification limits, the draft line-test steps, and the fault classes you already know the line will miss. A review can say whether this revision has evidence, and whether the line can see a bad copy of it, before quantity makes both questions expensive.

Review the next stage with BrahmWorks