Recording Firmware Version Changes with Semantic Rules and Supply Chain Checks

Equipment specification records often treat firmware as a single attribute in a datasheet, yet the practical work of validating a controller update is closer to software release management than to mechanical tolerancing. On a site dedicated to equipment specification records, a reproducible operating method should show how a maintenance engineer records a firmware change from the moment a vendor notification arrives until the updated device is signed back into service. The following procedure uses two reference frameworks: the version-numbering rules in Semantic Versioning 2.0.0 and the secure-supply-chain expectations described in NIST's guidance under Executive Order 14028. It produces a step-by-step record with inputs, observations, exceptions and an owner, and it applies to any instrument whose firmware is field-upgradable.

1. Define the Inputs Before the Update Window

The owner of the record is the instrumentation technician responsible for the asset tag, not the vendor and not a generic "engineering" mailbox. Before any file is downloaded, the owner collects four inputs: the equipment serial number, the currently recorded firmware string from the device menu, the vendor release note, and the cryptographic hash supplied by the vendor for the update image. If the vendor uses the MAJOR.MINOR.PATCH form described in the semantic versioning specification, the current string is parsed into major, minor and patch fields. A change from 1.4.2 to 1.5.0, for example, means backward-compatible functionality was added to the declared API of the firmware, while 1.4.2 to 2.0.0 signals a backward-incompatible change that may alter how the host system reads the device. The owner writes these parsed values into the record before the maintenance window opens. When the equipment falls into a class covered by type 14 records, the current calibration due date is also copied in, because a firmware jump across a major boundary often invalidates the prior uncertainty budget.

2. Verify the Update Against Supply Chain Criteria

NIST's software supply chain security guidance asks acquirers to consider criteria for evaluating both the software and the practices of the supplier. In this operating method, the owner turns that into a check block. The downloaded image is hashed locally and compared with the vendor-published digest; a mismatch is an exception that halts the record. The owner also confirms whether the vendor published the update through a channel that separates build metadata from precedence, using the '+' extension in the version string only for build identity, as the semantic specification allows. The observation field records the source URL, the download timestamp and the name of the person who approved the supplier evaluation. If the equipment is a measurement controller listed under type 25, the owner notes whether the new firmware changes the reported resolution; an incompatible major release that alters the digital output format is treated as a design change rather than a maintenance patch.

3. Capture the Installation Observations

During the update window, the owner records the exact version string shown by the device after the flash completes, including any pre-release suffix such as a hyphen and alphanumeric identifiers. Because the specification states that pre-release versions have lower precedence than the associated normal version, a device still showing 2.0.0-rc.1 after a production update is an exception: the owner must either install the final release or open a nonconformance item. The log also captures whether the device kept its configuration database; a backward-incompatible change may reset user offsets, and any loss of setup parameters is written into the exceptions column with the affected parameter names. For assets tracked as type 17, the owner adds the observed boot time and the first self-test result, because those devices integrate firmware with a mechanical stage whose homing routine can shift after an API change.

4. Record Exceptions with a Reproducible Format

An exception is any deviation from the planned path: a checksum failure, a rollback to the previous version, a missing vendor hash, or a major-version jump that was not preceded by a compatibility notice. Each exception gets four fields in the record: the observation text, the decision taken, the person who authorized that decision, and the follow-up due date. For instance, if the update fails halfway and the device reboots into the old 1.4.2 image, the owner records "rollback executed, watchdog triggered during write" and authorizes a retry in the next window. The semantic version rules help here: because the contents of a released version must not be modified, the owner knows that 1.4.2 observed after the failed attempt is the same artifact as before, so no new version entry is created for the aborted try. This keeps the equipment history from filling with phantom revisions.

5. Link the Version Change to the Equipment Record

Once the device runs the intended version and the self-test passes, the owner updates the equipment specification record. The old version string is retained in a history row rather than overwritten, with the date of supersession. The new string is stored in full, including build metadata if the vendor provided it, even though the specification says build metadata is ignored for precedence; keeping it preserves traceability to the exact image. The owner then states whether the update was a patch, a minor addition or a major incompatible release according to the vendor note and the observed behaviour. If the major version changed, the owner schedules a re-verification of the interface with the host system and, where relevant, a new uncertainty review, because the prior accuracy statement may no longer describe the modified firmware path.

6. Close the Record with Owner Sign-Off and Next Review

The final block names the owner, gives the date of closure, and sets the next review point. The closure note repeats the installed version only once, in the format X.Y.Z or X.Y.Z-pre-release+build, and cross-references the exception log if any was opened. By treating a firmware update as a supply-chain event and as a version-numbering event at the same time, this method gives a later reader everything needed to reproduce the decision: what went in, what was seen, what went wrong, and who was accountable. The two external references are not instructions to the equipment maker; they are the measurement scales for the record itself—one for how the version label behaves, one for how the software arrived. A hypothetical example: a controller moves from 3.2.1 to 3.3.0 with a vendor note about added Modbus registers; the owner records a minor increment, confirms no output format change, and leaves the calibration interval untouched, whereas a move to 4.0.0 would have triggered the compatibility checks above.