RAYPCB · ENGINEERING GUIDE
PCBA Test Specifications: Write Limits a Factory Can Execute
A PCBA test specification converts product requirements into repeatable measurements and decisions. It identifies the board configuration, stimulus, measurement location, units, limits, timing and result record. Instructions such as check the voltage or make sure it works leave too much interpretation to the production station.
This guide focuses on writing the specification, while the circuit-card test plan coordinates the overall route. The limit worksheet compares entered measurements with entered inclusive bounds. It does not choose safe limits or account for uncertainty automatically.
Identify the product state precisely
Record the assembly revision, fitted options, firmware and configuration. Specify the supply and load conditions needed for each measurement without assuming they are obvious from the schematic. Include the reference node and any required settling state.
A measurement at a regulator output under no load may differ from the same measurement at a connector under load. State which one demonstrates the requirement. Use component data and design analysis to justify the allowed range.
Entered measurement-limit review
Entered measurement-limit review
Use the current inputs and keep the assumptions
Choose the engineering question before entering numbers. Fields begin blank. Load example fills teaching values so you can understand the model; those values are not recommended dimensions, process settings or market prices. The example label remains visible after edits. Reset before preparing a record based entirely on your own project data.
Use the displayed units and keep a reference for each input. Counts must describe the same scope, and measurements must share the declared conditions. A threshold entered by you remains your supplied review condition. The website does not turn it into an IPC limit or an approved product requirement. If the necessary value is unknown, obtain the evidence rather than replacing it with an attractive assumption.
Read the result and its limitations together. An access fraction is not fault coverage, a cost allowance is not a quotation, and a completed evidence checklist is not a safety or quality approval. Negative margins remain visible where the model permits them. They identify a conflict in the entered scenario rather than silently adjusting the result.
Changing an input invalidates the result and disables its download until you run the tool again. The text record contains the inputs, result and limitations. Processing stays in your browser; no CAD files, instruments or certificates are read. No data is automatically transferred to the enquiry form. Download and attach the record manually if useful, or contact RAYPCB directly without completing the tool.
| Input | What to establish before using it |
|---|---|
| Review reference | Use a nonconfidential revision or scope reference. |
| Measurement unit | All observations and bounds use this unit. |
| Measurements | Comma-separated signed decimals, maximum 500. |
| Entered lower bound | Your approved bound; inclusive comparison only. |
| Entered upper bound | Must be at least the lower bound; uncertainty not modeled. |
Write one unambiguous test item at a time
Each item should have an identifier, purpose, setup, stimulus, measurement, unit and decision rule. Specify how a result is stored and what constitutes an invalid measurement. Binary interface checks also need defined messages, timeouts and expected behavior.
Keep the specification independent enough to review while identifying implementation constraints. A screenshot of one instrument display is not a complete repeatable instruction. The test-equipment page connects measurement needs to station architecture.
| Review item | What to establish |
|---|---|
| Configuration | Name revision, firmware, options and operating state. |
| Measurement | Specify nodes, units, stimulus and timing. |
| Decision | Separate product tolerance and station decision rule. |
| Exceptions | Define invalid runs, retries and controlled retesting. |
Distinguish product limits from station acceptance limits
Product tolerance, instrument uncertainty, fixture effects and decision rules are related but different. A nominal value measured on one prototype should not automatically become the production center or limit. Review the complete measurement process before setting acceptance criteria.
The tool reports values below, within or above your entered bounds. It does not implement a guardband, statistical process control or an accreditation decision rule. If uncertainty changes the disposition, use the qualified metrology approach specified by the responsible engineer.
Define exceptions and invalid runs
Communication loss, missing data, a disconnected load and a fixture contact problem are not ordinary product results. The station needs a distinct response that preserves the event and prevents an invalid run from being counted as a pass.
Document permitted retries and retests. Separate an automatic communication retry from repeating a failed product test after repair. The functional test cost model can include additional cycles, but the quality rules must be established first.
Validate the specification against real hardware
Walk through the document using representative assemblies and the intended station. Check whether another qualified person can reproduce the sequence and interpretation. Use approved reference and fault conditions where suitable to evaluate detection behavior.
Record discrepancies between the written requirement and the implemented program. Resolve them through revision control. A program that happens to run successfully is not evidence that every stated requirement has been implemented correctly.
Example: a voltage line that becomes executable
Instead of a generic rail check, identify the two measurement nodes, supported product variant, operating state, load condition, unit and approved bounds. Add the sample timing and the required record. This turns an intention into a reviewable test item.
The actual numerical limits remain the product engineer's responsibility. The worked structure is a documentation example, not a recommended tolerance for all rails or all assemblies.
Release and maintain the test definition
Assign an owner, revision, approval and change history. Link the specification to fixture and software versions, and identify which changes trigger correlation. Record deviations explicitly rather than hiding them in station code.
Send the specification with the assembly enquiry and the circuit-card test plan. RAYPCB can review the requested production work, while missing product requirements remain visible engineering actions rather than invented factory defaults.
Questions to resolve before the next build
Can limits be copied from one known-good board? One board provides observations under its particular conditions, not a complete distribution of acceptable product behavior. Use design requirements, tolerances and measurement capability to establish the limits. Representative hardware can help validate the implementation, but it should not become the sole basis for a production range without an appropriate engineering justification.
Should retries appear in the specification? Yes, distinguish communication recovery, invalid measurements, product retesting and testing after repair. Define what is retained in the record and which result controls disposition. A program that retries until a value enters the range can conceal an intermittent problem. Keep the original event and the permitted sequence visible to the people interpreting yield and customer evidence.
If the requirement involves dielectric withstand, use the separate hipot planning guide and qualified safety review before defining an executable test.
Keep the written requirement and implementation aligned
Begin with a requirement-to-record map. Each important decision should identify the object being evaluated, the method, the responsible owner and the evidence expected. This makes gaps visible before a supplier quotation or production program turns assumptions into routine practice. Keep mandatory requirements separate from useful supplementary observations.
Control document identity at the level needed for the task. A drawing, standard, firmware image, test program and fixture may each have its own revision. Record the compatible combination rather than assuming that the newest file in every category belongs together. Resolve conflicts between the purchase requirement and the implementation before work begins.
Ask whether another qualified reviewer can reproduce the interpretation. The record should identify units, locations, conditions, limits and any decision rule. A pass statement without scope can be misleading; a long report without specimen identity can be equally unhelpful. More data is valuable only when it answers the question and remains traceable.
Separate evidence availability from evidence verification. A box marked recorded means that someone reports having a document, not that the document is current, applicable or correct. Review the actual material and retain a reference to the approved version. The online worksheets intentionally avoid a compliance percentage because incomplete evidence does not become acceptable through averaging.
Define the handling of exceptions. Missing information, an invalid run, an unavailable station and a confirmed product failure need different actions. Record who can approve a deviation and which requirements remain binding. A supplier acknowledgment should not be mistaken for technical approval, and a successful software run should not substitute for method validation.
For external work, confirm scope and responsibility. Identify any subcontracted activity, the method used, the report issuer and the records that will be returned. Where accreditation is relevant, verify the applicable scope rather than relying on a broad logo. Where the work is outside that scope, describe it accurately instead of implying a status that has not been established.
Use the handoff to support the next person in the process. A buyer needs comparable scope, an engineer needs interpretable evidence and a production team needs executable instructions. A concise controlled package can serve all three when the task, version, result and open points are clear. Keep confidential design and customer information in the agreed project channel rather than in public comments or analytics.
Standards, source context and limits
Use each reference for its stated scope. Equipment and material documentation applies to the identified product and conditions. A published study describes its own specimens and methods; its settings are not universal production limits. Public standard summaries and revision tables do not replace the controlled normative document.
Agree the applicable standards, revisions, product class where relevant, measurement methods and exceptions before production. Distinguish printed-board requirements, assembly workmanship, laboratory competence and finished-product certification. A method name or photograph does not establish that a supplier holds an accreditation or that a particular test is included in an order.
Archive photographs illustrate relevant boards, equipment or operations from the existing RAYPCB website. They are not evidence of current equipment ownership or results from your project. Original diagrams explain concepts and measurement boundaries; they are not inspection records or released manufacturing drawings. Confirm the actual service and reporting scope in the project review.
