Barcode Scan and Programmer Identity Disagree: Stop Before Writing the Unit Record
When a scanned label disagrees with the device identity observed through the programmer, stop before attaching results or writing identity data. Compare the documented relationship between identifier namespaces rather than expecting every string to be equal. Preserve the mismatch so a swapped board, stale inventory relation or wrong adapter can be distinguished.
This article uses upstream OpenOCD 0.12.0 adapter-selection semantics and NASA SP-2016-6105 Rev2 configuration-identification guidance. Seven synthetic relationship checks passed under Python 3.12.14. No barcode was scanned, hardware identifier read, manufacturing record corrected or provisioning operation performed.
Define what each identifier names
| Identifier | Typical object | Unsupported assumption |
|---|---|---|
| Scanned product label. | An enclosure, assembly or inventory item under a defined labeling scheme. | That the scanned label is physically attached to the connected board. |
| Chip identifier. | A silicon device under its vendor’s documented identity contract. | That it is always globally unique, immutable or authenticated. |
| Programmer serial. | The debug adapter. | That it is the product’s serial number. |
| Fixture position. | A nest or routing destination. | That its current occupant is the last scanned unit. |
| Inventory relationship. | The approved association among product, assembly and component identities. | That an old association remains valid after repair or replacement. |
Use the actual chip documentation to define the identifier’s meaning and read method. A family/revision register can be useful for compatibility while being unsuitable as a unique unit identity. Do not label a convenient hexadecimal value “UID” without that contract.
Compare a relationship, not unlike strings
A valid product might have label LABEL-A, chip CHIP-17 and probe PROBE-X. These strings should differ because they belong to different namespaces. The decision is whether the observed tuple matches the approved inventory relationship and current station assignment.
The OpenOCD 0.12.0 adapter serial setting selects a probe for supported drivers. It does not establish which board is connected to the probe. If no serial selector is configured, that command’s serial-string check is absent. Confirm actual driver support and selection evidence.
Keep the adapter binding and product binding as separate fields. Two products tested sequentially on one probe legitimately share the probe identity. Two simultaneously connected probes may require different explicit selections even when their target boards are the same model.
Capture one coherent occupancy instance
Associate the scan with the fixture occupancy and test attempt. If the fixture opens, a cable moves or the board can be replaced, invalidate the previous association and require the defined revalidation. A scan from several minutes earlier should not remain indefinite permission to record results.
Serialize the final binding check with admission of the operation that matters. If software checks the tuple and then another worker changes the multiplexer, the comparison was true only before the route changed. The station’s ownership and physical occupancy controls must cover that gap.
Do not treat a returned identity as trustworthy merely because it matches the inventory. A cached programmer response or previous console record can match perfectly while belonging to another connection. Record how the observation was obtained from the current instance and preserve acquisition errors.
Use a mismatch decision matrix
| Observation | Next controlled check | Automatic action to avoid |
|---|---|---|
| Known label, unexpected chip. | Inspect physical label/board relationship and current route. | Overwriting inventory to match the latest read. |
| Expected chip, unexpected probe. | Confirm adapter selection and station wiring. | Assuming any compatible probe belongs to this lane. |
| Unknown label. | Check format and authorized inventory enrollment. | Creating a new product record from unreviewed scan text. |
| Correct identities, wrong assembly revision. | Review the required compatibility relationship. | Attaching the result to a superficially similar product. |
| Previously correct tuple, occupancy now uncertain. | Re-establish the current physical association. | Reusing the old scan as continuing authorization. |
Record the observed mismatch before manipulating the setup. Changing the label, board and route together may make the next attempt pass while leaving the original cause unexplained. Use one controlled change at a time where practical.
Read the executed synthetic checks
The model’s supplied inventory associated LABEL-A with CHIP-17 at revision R1 and LABEL-B with CHIP-29. PROBE-X was the expected station adapter. The valid tuple used three different strings and correctly matched the inventory.
Six further cases were held: a swapped label, another chip behind the same probe, an unknown label, the wrong probe, stale occupancy and the wrong revision. All seven expected outcomes passed. These are relationship checks against synthetic authoritative inputs, not proof that the inputs were authentic or physically observed.
The model intentionally did not repair any mismatch. A production implementation should likewise make correction a separately authorized workflow, with evidence and a historical record, rather than a side effect of trying to continue the test.
Handle repaired assemblies through genealogy
A legitimate board replacement can change the chip identity while preserving an enclosure-level product identity. Define whether that service action is allowed and which record approves the new relationship. Preserve the removed assembly’s association and replacement event instead of rewriting history as though the new board had always been present.
NASA’s configuration-management guidance uses unique identification and historical status to make changes traceable. Here, the engineering adaptation is a versioned product-to-assembly relation with explicit validity boundaries. It is not a universal serial-number policy.
If the intended identity does not yet exist on an unprogrammed unit, use the approved pre-provisioning identity process. Do not write a serial merely to make a mismatch disappear. Irreversible identifiers, credentials and secure provisioning require their own controlled procedure.
Close with a bound unit record
The accepted record should contain the label namespace, current device observation, fixture/adapter assignment, relationship revision and attempt identity. Keep diagnostic exports minimal and use synthetic or approved redacted identifiers when sharing evidence.
The outcome is a justified association between a physical product and its test evidence. It prevents a technically valid result from being stored under the wrong unit, while keeping identity correction, authentication and provisioning separate from ordinary result collection.
