Checksums in Product Design and Manufacturing: How to Prevent Wrong Labels, Barcode Scan Errors, and Costly Recalls

A pallet leaves the dock with the right product and the wrong label. The receiving plant scans it, the ERP accepts the code, and three weeks later a complaint traces back to a lot that nobody can locate. Nothing was wrong with the part. One digit was wrong in the data that identifies it.

A checksum is the cheapest control against this class of failure. It adds a few digits or bytes to a record, and any station downstream can verify the record without a database lookup.
Physical products carry data through many hands, machines and formats. A CAD file becomes a BOM, a BOM becomes a work order, and a work order becomes a label. The label becomes a scan, and the scan becomes a shipment record.

메모: regulatory dates in this article, such as those of the EU Cyber Resilience Act, the Digital Product Passport and the US DSCSA, were checked in November 2026. Confirm them again before you build a compliance plan on them.

Key takeaways

• A checksum detects accidental error. Stopping deliberate change needs a signature or a keyed code.
• Check digits protect identifiers that people and scanners handle. CRCs protect frames and firmware images. Cryptographic hashes protect files and records.
• The GS1 check digit catches every single-digit error. It misses about 11 percent of adjacent transpositions, namely those where the two digits differ by 5.
• Verify at the point of creation and again at the point of use. A single check at one stage leaves every other stage uncovered.
• Treat the check itself as a measurement system. Challenge it with known-bad samples, calibrate verifiers, and track the results.

1. Why physical products depend on data integrity

Where data errors enter the chain

Errors typically come from these five sources:

• People mistype digits or misread them.
• Machines misread marks that are damaged.
• Storage and transmission flip bits.
• Process changes replace the right version with an obsolete one.
• Finally, someone may alter data on purpose.

2. What is a checksum?

Terminology of the checksum world

Several terms are used loosely in plants and in software teams. The table separates them by the question each one answers.

Detection versus correction

Most checksums only detect an error. They tell you that something is wrong and not what. That is enough on a production line, where the right reaction is to stop, reprint, rescan or retransmit. Error-correcting codes go further and repair the data, which suits marks that will be scuffed or memories that will degrade. Chapter 15 covers these codes in detail.

3. Core properties and what they mean for quality metrics

Each property of a checksum has a counterpart in the vocabulary of quality engineering. Mapping them lets you write the check into an FMEA or a control plan without translation.

FMEA detection rating

In the AIAG-VDA FMEA handbook of 2019, detection controls are rated from 1 to 10, where 10 means no detection capability. The same handbook replaced the risk priority number with an action priority table that weighs severity first, then occurrence, then detection. An automated check that blocks the next operation can justify a much better detection rating than a visual check. Keep the evidence, for example a challenge test with known-bad samples.

False accept and false reject

Two error types apply to any check. A false accept lets bad data through, which is the escape. A false reject stops good data and costs line time. A correctly implemented check digit or CRC never rejects good data, because the rule is exact. False rejects come from the reading step, such as a scanner that fails on a valid but poorly printed code.

4. A short history of checksums ans similar

The techniques in this article are old, and that is a strength. Each one has decades of field evidence behind it, and each failure mode is documented.

5. Where checksums sit in the product lifecycle

Use this table as the map for the rest of the article. It shows which kind of check applies at each stage and where a failure would normally surface.

6. Parity bits and simple sums

Two-dimensional parity arranges data in rows and columns and adds a parity bit to each row and each column. It locates a single flipped bit and can therefore correct it. It detects all errors of two or three bits. Four flipped bits at the corners of a rectangle still escape.

Additive and XOR checksums

The next step up sums all bytes, or XORs them, and sends the result. These checks are cheap and fit on the smallest microcontroller. They share two weaknesses that matter in practice. They ignore byte order, so swapped bytes pass. Errors can also compensate: one byte rises by one while another falls by one, and the sum is unchanged.

An XOR checksum additionally misses any even number of flips in the same bit position across different bytes. Maxino and Koopman measured the effectiveness of such checksums for embedded control networks in 2009 and found that CRCs of the same width outperform them on structured errors.

Where they still appear

The Intel HEX case matters for firmware. A file can pass every record check and still be incomplete, because a missing record leaves no trace in the other records. Add an image-level CRC or hash, as chapter 18 describes.

Physical devices that still use parity and simple sums

Magnetic stripe cards Each character carries an odd parity bit, and a longitudinal redundancy check character follows the end sentinel. A reader rejects a swipe that fails either test.	Serial instruments and PLC peripherals RS-232 and RS-485 links can add a parity bit to every character, which catches single-bit flips caused by electrical noise.
	Flash programmers and bootloaders They read Intel HEX and Motorola S-record files, which carry a sum for each record, and the tool normally rejects a record that does not match.

7. Check digits: how to calculate a GS1 check digit and why it matters

Check digits are the oldest and most widely deployed checksums in industry. They sit at the end of identifiers that people type and machines scan. They form the backbone of traceability, because every lot, serial number, location and shipment is referenced through an identifier.

How to calculate a GS1 check digit

GS1 requires a check digit on all fixed-length numeric identification keys, including GTIN-8, GTIN-12, GTIN-13, GTIN-14, GLN and SSCC. The algorithm is a weighted sum modulo 10. The weights alternate between 3 and 1, and the digit next to the check digit always gets the weight 3.

1. Write the digits of the key without its check digit.
2. Starting from the right, multiply the digits alternately by 3 and 1.
3. Add up the products of all digits.
4. The check digit is the amount that brings the sum up to the next multiple of 10. If the sum is already a multiple of 10, the check digit is 0.

Written as a formula, the check digit [latex]C[/latex] uses the digits [latex]d_i[/latex] of the body, counted from the right. The weight is [latex]w_i = 3[/latex] for odd [latex]i[/latex] and [latex]w_i = 1[/latex] for even [latex]i[/latex].

[latex]\displaystyle C = \left(10 – \left(\sum_{i=1}^{n} w_i d_i \bmod 10\right)\right) \bmod 10[/latex]

Worked example for the GTIN-13 body 400638133393. Counted from the left, the weights are 1, 3, 1, 3 and so on, because the rightmost body digit is an odd position from the right.

The products add up to 89. The next multiple of 10 is 90, so the check digit is [latex]C = (10 – (89 \bmod 10)) \bmod 10 = 1[/latex] and the complete GTIN-13 is 4006381333931. The same rule applies to an SSCC. The 17-digit body 34012345000000001 sums to 43, which gives [latex]C = (10 – (43 \bmod 10)) \bmod 10 = 7[/latex] and the SSCC 340123450000000017.

What a check digit catches

The table compares the GS1 scheme with three alternatives. The GS1 and Luhn figures were confirmed by simulation on random keys. The Verhoeff and Damm properties are documented in their original publications.

The GS1 weighting is not the strongest scheme available. It is the one you must use for GS1 keys. For identifiers you define yourself, choose a stronger scheme.

A valid check digit also says nothing about existence. It shows that a number is well formed. It does not show that the GTIN is allocated, belongs to this product, or is active in your master data. Keep master-data validation in place next to the arithmetic check.

The VIN check digit in position 9

In North America, 49 CFR 565 requires a check digit in position 9 of the 17-character VIN. Each character is transliterated to a number and multiplied by a position weight: 8, 7, 6, 5, 4, 3, 2, 10, 0, 9, 8, 7, 6, 5, 4, 3, 2. The products are then summed. The remainder after division by 11 is the check digit, and a remainder of 10 is written as the letter X.

[latex]\displaystyle C = \left(\sum_{i=1}^{17} t_i w_i\right) \bmod 11[/latex]

Here [latex]t_i[/latex] is the transliterated value and [latex]w_i[/latex] is the weight of position [latex]i[/latex].

Many VINs of European origin do not carry a valid check digit, so a North American validation rule must not reject them automatically. A quick test for your own implementation: a VIN made of seventeen ones must produce the check digit 1. The text of the rule is in 49 CFR 565.15.

Other schemes you will meet

• The EAN-13 barcodes on books carry an ISBN-13 and use the GS1 algorithm. The legacy ISBN-10 used a mod 11 scheme.
• Payment card numbers and IMEI numbers use the Luhn algorithm, which Hans Peter Luhn of IBM described in a 1954 patent filing.
• IBAN uses MOD 97-10 from ISO/IEC 7064.
• Shipping container numbers under ISO 6346 end in a check digit.

Designing a check digit for internal part and serial numbers

Many plants invent identifiers and then add a homemade check. Homemade schemes often miss transpositions, which are a common keying error. Use a published scheme unless you have a documented reason not to.

• Choose an established, published algorithm. Damm or Verhoeff suit numeric identifiers. ISO/IEC 7064 defines pure and hybrid systems for numeric, alphabetic and alphanumeric strings, among them MOD 11-2, MOD 37-2 and MOD 97-10.
• Fix the length of the identifier and place the check character last.
• Remove look-alike characters such as O and 0, or I and 1, from the alphabet, or handle them explicitly in the scheme.
• Define the algorithm in a controlled document with test vectors, so that every system implements the same rule.
• Test the scheme against the error classes you care about: single substitution, adjacent transposition, twin errors, and phonetic errors where voice entry exists.
• Consider non-significant numbers for new schemes. They avoid renumbering when a classification changes.
• Validate in every entry point, including ERP, MES, label software and PLC scripts. A check that exists in one system is bypassed by the others.

Devices and tools that validate check digits

8. Barcode scan errors: causes, verification and fixes

Barcode scan errors fall into three classes. A no-read stops the process and costs time. A misread returns a wrong value that looks valid. A wrong-read returns a valid value from the wrong item, for example from a neighbouring label. Misreads are the dangerous class, and the checks built into symbologies exist to keep them rare.

Checks built into the symbology

Reading is not the same as quality

A scanner that decodes a symbol does not prove that the symbol is good. Marginal symbols decode today and fail after the label scuffs in transit. A verifier measures print quality against a standard and assigns a grade.

Verifiers need calibration with a conformance standard test card. The application standard or the customer defines the minimum acceptable grade. Check the current GS1 General Specifications and any sector rules for your symbol type.

Causes and fixes

Apply one rule at every scan station. Decode, validate the check digit, validate the format against the expected key, and only then accept the value. A scan that fails any step triggers a defined reaction. It must not trigger a retry loop that nobody counts.

9. How to prevent wrong labels

A wrong label is one of the most common and most visible data failures. It has several distinct causes, and a checksum addresses only some of them. Separate the causes before you choose the controls.

A closed-loop label process

1. Release the label template and its data source under change control. Store a hash of the template file in the release record.
2. At job start, the printer or label server computes the hash of the loaded template and compares it with the release record. A mismatch blocks the printing of the job.
3. Build the payload from the single authoritative record. Generate the check digit in software with a tested library, and never type it by hand.
4. Print, then verify the symbol inline. A grade below the specified minimum rejects the label.
5. Scan the printed label and compare its decoded content with the expected record for this unit. Reject any unit whose label does not match.
6. Scan again at the pack or ship station after application. The second check catches mix-ups that happen after printing.
7. Reconcile the counts at the end of each run. Labels issued, applied, scrapped and returned must add up.

The sequence uses three kinds of checks. The hash proves the right template. The check digit and the format prove that the key is well formed. The comparison with the expected record proves that it is the right key for this unit. Only the third one catches a label that is well formed but wrong.

10. Network and fieldbus checksums

Machines protect their data with checks defined in the protocol. These checks guard the link, one hop at a time. They do not guard the data once it sits in PLC memory or in a database:

Internet checksums IP headers, TCP and UDP use the 16-bit ones’ complement sum described in RFC 1071. It is cheap to compute and weak. It misses swapped 16-bit words and some compensating errors. Link layers add a stronger CRC underneath, which is why the weak checksum has survived. Fletcher and Adler-32 are simple sums with two accumulators, so they catch more ordering errors than a plain sum. Adler-32 appears in the zlib library. It is weak on short messages.	Modbus RTU Modbus RTU frames end with a 16-bit CRC. The polynomial is 0x8005, used in its reflected form 0xA001, with the initial value 0xFFFF. The low byte of the CRC is sent first. Modbus ASCII uses a simpler 8-bit longitudinal redundancy check instead. Here is a complete RTU request that reads 10 holding registers from slave 1, starting at address 0. The CRC value is 0xCDC5, which goes on the wire as C5 followed by CD. 01 03 00 00 00 0A C5 CD
CAN and CAN FD Classical CAN uses a 15-bit CRC with the polynomial 0x4599. It gives a Hamming distance of 6 for a fixed frame length, so any five randomly distributed bit errors are detected. CAN FD uses a 17-bit CRC for payloads up to 16 bytes and a 21-bit CRC above that, chosen to keep the same Hamming distance of 6. Bit stuffing complicates the picture. CAN in Automation notes that stuffing can reduce the effective Hamming distance for some bit patterns in classical frames, and CAN FD adds a stuff-bit counter to close that gap. The details are in the CiA explanation of CRC in CAN frames.	Ethernet-based buses PROFINET, EtherCAT, EtherNet/IP and Modbus TCP carry their data in standard Ethernet frames. Each frame ends with a 32-bit frame check sequence, a CRC-32, which devices check at every hop. Frames with a bad sequence are dropped. Other buses, among them PROFIBUS and IO-Link, define their own frame checks. Read the protocol specification and record the check in your FMEA instead of assuming it.
	Safety protocols on top of the bus Safety protocols such as PROFIsafe, CIP Safety and Fail Safe over EtherCAT treat the underlying bus as a black channel. The channel may corrupt, delay, repeat or reorder messages. The safety layer adds its own CRC, a sequence counter and a watchdog, so that the safety function does not depend on the checks of the link. Take the lesson into your own designs. A link-level CRC does not protect a recipe while it sits in memory or travels through an OPC UA server and an MES. Add an end-to-end check at application level for every parameter set that affects safety or quality.

11. What is CRC error checking?

A cyclic redundancy check treats the message as a long binary number, which is a polynomial over [latex]\mathrm{GF}(2)[/latex]. It divides that polynomial by a fixed generator polynomial and keeps the remainder. The remainder is the CRC, usually 8, 16 or 32 bits long. The sender appends it, the receiver divides again, and any mismatch signals corruption.

A worked example

Take the 3-bit generator 1011, which stands for [latex]x^3 + x + 1[/latex], and the message 1101. Append three zeros to get 1101000. Then divide by repeated XOR with the generator.

1101000
1011
-------
0110000
 1011
-------
0011100
  1011
-------
0001010
   1011
-------
0000001

The remainder is 001, so the transmitted word is 1101001. Dividing that word by 1011 gives the remainder 000. Flip any single bit and the remainder becomes nonzero. Real CRCs use generators of 8 to 32 bits and run in hardware or with lookup tables, but the principle is identical.

What a CRC guarantees

• Every single-bit error, as long as the generator has more than one term.
• Every burst error no longer than the CRC width.
• Every odd number of bit errors, for generators that contain the factor [latex]x + 1[/latex]. The common 16-bit polynomials qualify. The Ethernet CRC-32 does not.
• Longer bursts and random patterns pass with a probability of roughly [latex]2^{-n}[/latex].
• A Hamming distance that depends on the polynomial and on the message length.

The parameters that must match

Two parties compute the same CRC only if they agree on six parameters: width, polynomial, initial value, input reflection, output reflection and final XOR. Names such as CRC-16 or CRC-32 are ambiguous. The Reveng CRC catalogue lists the parameter sets in common use. Confirm an implementation with the check value of the ASCII string 123456789.

Choosing a polynomial by message length

The strength of a CRC depends on the polynomial and on the message length. Koopman showed in a study of 32-bit CRCs that the IEEE 802.3 polynomial reaches a Hamming distance of only 4 on maximum-length Ethernet messages, while other polynomials reach 6. Embedded networks with short messages show wider gaps, and some widely copied 16-bit polynomials perform poorly at the lengths where they are used.

• Fix the range of message lengths before you pick a polynomial.
• Decide which Hamming distance you need at the maximum length. Safety-critical applications commonly require a distance of 6.
• Take the polynomial from published exhaustive-search results, not from folklore or a code sample.

Limits of a CRC

A CRC is a linear function of the message. Given a message and its CRC, anyone can change the message and compute a matching CRC without a secret. A CRC therefore proves nothing about origin and cannot stop deliberate change. Chapters 13 and 14 cover the tools that can.

Devices that carry a CRC

12. Non-cryptographic hash functions

Non-cryptographic hash functions such as xxHash, MurmurHash, CityHash and FNV trade security for speed. They run close to memory speed on modern CPUs and produce 32, 64 or 128 bit values that spread inputs evenly.

They offer no protection against someone who builds colliding inputs on purpose:

13. Cryptographic hashes and how to verify a SHA-256 checksum

We are diving into technical practical details in this cghapter.

A cryptographic hash function must resist three attacks:

• Preimage resistance means nobody can find an input for a given digest.
• Second-preimage resistance means nobody can find a different input that matches the digest of a given input.
• Collision resistance means nobody can find any two inputs with the same digest.

NIST describes the SHA-1 retirement plan on its SHA-1 announcement page. A SHA-256 digest gives about 128 bits of collision resistance, which is far beyond any practical attack.

How to verify a SHA-256 checksum

You need two things: the expected digest from a trustworthy source, and the file. Compute the digest locally and compare the full string. Comparing only the first few characters throws away most of the protection.

# Linux
sha256sum firmware.bin
sha256sum -c SHA256SUMS

# macOS
shasum -a 256 firmware.bin

# Windows PowerShell
Get-FileHash .\firmware.bin -Algorithm SHA256

# Windows command prompt
certutil -hashfile firmware.bin SHA256

A SHA256SUMS file holds one line per file, with the digest, two spaces and the file name. The command sha256sum -c reads it and prints OK or FAILED for each file. Check any tool against the test vector in Appendix B before you rely on it.

14. Keyed checksums, signatures and authenticity

Everything so far is public. Anyone can compute a CRC or a SHA-256 for a modified message. To stop deliberate change, the check must depend on a secret or on a private key.

Shared-secret schemes put the key in every verifier. A key that sits in dozens of test stations or thousands of devices is hard to protect and hard to rotate. Signatures turn the problem around. Stations and devices hold only the public key, while the private key stays in a hardware security module at the release authority.

Do not build a MAC by hashing a secret followed by the message with SHA-256. SHA-2 allows length extension attacks on that construction. HMAC exists to avoid exactly this.

Use cases in product environments

• • Signed firmware and secure boot. The boot ROM verifies the bootloader signature, and the bootloader verifies the application. A CRC still has a place for runtime integrity of flash and RAM, but it never replaces the signature.

• Spare part authenticity is a separate question. A serial number with a valid check digit proves nothing about authenticity, since anyone can compute it. Authentication needs a secret, for example a cryptographic tag in a secure element or a code that a server can verify and nobody can derive from the serial.
• Labels can carry anti-counterfeiting data. GS1 defines an application identifier, AI 8030, for a digital signature carried in the data carrier alongside the key.
• Regulated records need extra care. A cryptographic signature supports electronic records but does not equal an electronic signature under 21 CFR Part 11. The regulation also demands identity controls, the meaning of the signature and its link to the record.

Locks, keys and access devices

Mechanical and electronic locks show the difference between error detection and authentication.

• Pin tumbler locks: the key cuts must match the pin heights, so the lock verifies a physical shape. The shape is effectively a shared secret, because anyone who copies it gains access.
• Low-cost contactless credentials: read frames carry a CRC against radio errors, which proves nothing about identity. Older cards built on a broken proprietary cipher, such as MIFARE Classic, can be cloned. Modern credentials use challenge-response with standard ciphers such as AES.
• Bluetooth Low Energy smart locks: the link layer protects each packet with AES-CCM, whose message integrity code is a keyed check.
• Authenticated consumables and accessories: some printer cartridges, battery packs and sensors carry a chip that answers a cryptographic challenge from the host device.

15. Error-correcting codes

Detection says that data is wrong, and correction repairs it. The price is more redundancy, and the benefit is that the process continues without a rescan, a retransmission or a rework step.

Marks that survive damage A QR code offers four correction levels, L, M, Q and H, which restore roughly 7, 15, 25 and 30 percent of the codewords. Data Matrix ECC 200 uses Reed-Solomon with a fixed amount of redundancy per symbol size. Laser-marked, dirty or scuffed parts benefit directly, and so do labels that travel through a supply chain. Error correction makes a mark robust. It can also hide degradation. A damaged Data Matrix symbol may decode perfectly while its spare correction capacity shrinks toward zero. Verification under ISO/IEC 15415 reports the unused error correction as a graded parameter. Monitor the verifier grade, not the read result, to follow print and marking quality.

ECC memory and flash in embedded products Microcontrollers for automotive and industrial use often protect flash and RAM with ECC. The hardware corrects single-bit flips and counts them. Read the corrected-error counters and log them. A rising count points to a degrading cell, a marginal supply or radiation upsets. A CRC computed after correction sees clean data, so the counter is the only early signal you get.

Devices and media that rely on error correction Laser-marked and dot-peened parts carry Data Matrix ECC 200 symbols, which use Reed-Solomon codes, so a scuffed mark can still decode. Servers, controllers and automotive microcontrollers: ECC memory typically corrects single-bit errors and detects double-bit errors. SSDs, eMMC and SD cards: the controller applies BCH or LDPC codes to flash pages, and its corrected-bit counters can serve as a wear indicator.

16. Comparison of algorithms

The table summarizes the families and where each one fits in this article. Speed figures depend on the platform, so measure them on your own target hardware.

17. Design and engineering

CAD, drawings and BOMs under release

A PLM or PDM system identifies a release by its revision. A revision letter says which version someone intended to release. A hash of the released package says which bytes were released. Store both in the release record. Any consumer can then verify what it received, which closes a gap that revision letters leave open: a file replaced or edited after release.

• Compute a SHA-256 digest for each released file, for example the STEP model, the drawing PDF and the BOM export.
• Compute one more digest over a manifest that lists all files and their digests, so a single value represents the whole package.
• Put the manifest digest into the ECO or ECN record and into the transmittal sent to suppliers.
• Let the supplier portal or the manufacturing system recompute and compare on receipt.
• Compare BOM exports by hash between as-designed and as-built configurations. A mismatch flags a difference, and a people-driven review then explains it.

Error-proofing in part numbers and connectors

Design decides how easy it is to make a mistake later. A check digit on part numbers catches keying errors at every entry point. Distinct number formats for purchased parts, drawings and assemblies prevent one class from being mistaken for another. Keyed connectors and asymmetric label formats work in the same spirit on the physical side.

Embedded firmware and calibration data

A firmware image should be self-describing and self-checking. A common layout places a fixed header at a known address.

Apply the same discipline to calibration and configuration blocks in EEPROM or flash. Store a CRC with each block. Define what happens when the check fails: fall back to defaults, raise a fault, and never use the data silently. Keep a redundant copy and write blocks in a way that survives a power loss.

Functional safety context

Functional safety standards treat memory corruption and communication errors as failure modes that need diagnostic measures. ISO 26262 for road vehicles, IEC 61508 for industrial systems and IEC 62304 for medical device software all expect you to show how such faults are detected. Typical measures are CRCs over code and data memory, protected communication with sequence counters, and redundant storage.

The analysis must state diagnostic coverage, the share of failures that a measure detects. A 32-bit CRC does not automatically give 99 percent coverage for the whole system. Coverage depends on what the CRC covers, how often it runs, and what the system does when it fails.

18. Industrialization and manufacturing, including how to verify firmware flashing

Industrialization turns design data into running processes. Most data errors that reach production enter here: wrong recipes, wrong label templates, mismatched test limits.

Marking and scan-station error-proofing

• Verify marks at the point of marking and again where the mark is first needed. ISO/IEC 15415, 15416 and 29158 define the grading.
• Make the scan station a gate. The PLC releases the next operation only when decode, check digit, format and expected-value tests all pass.
• Put check digits on serial numbers generated by the line, so that manual entry at rework stations is protected as well.
• Record every failed scan with station, time and, where possible, the symbol image. This feeds the DMAIC work in chapter 20.

Recipes and parameters

Machine recipes, torque programs, welding schedules and test limits live as files or database rows. A mistaken or outdated parameter set creates a quiet defect, because the machine runs correctly with wrong instructions.

Keep a golden record in the MES or PLM together with its hash. At every recipe download and at the start of each lot, the station software recomputes the hash of the active recipe and compares it. A mismatch blocks production of the lot. For parameters sent over a bus to a controller, add a CRC inside the data block, so that the receiving controller does not run on corrupted values.

How to verify firmware flashing at end of line

Flashing is a process step like welding or torquing. It needs a defined method, an acceptance criterion and a record per serial number. A programmer that reports success has told you only that its commands completed.

1. Program the image with the verify option of the programmer enabled, if the device and the tool support it.
2. Read back the programmed regions and compute a SHA-256 or CRC-32 over exactly the regions defined in the control plan. Compare the result with the golden digest from the release record.
3. Handle unit-specific data in a separate step. Serial number, MAC address and calibration values differ per unit. Exclude them from the whole-image digest and verify them against their own records, or compute the expected digest with the unit data patched in.
4. Verify option bytes, fuses and lock bits. A correct application with the wrong boot configuration or without readout protection is a defective unit.
5. Ask the running device for its software version and for the digest of its own image over the application protocol. Many products compute a CRC of their flash with a hardware peripheral and report it. This also tests the communication path.
6. Write the result to the MES against the unit serial number, together with the image digest and the tool version. Do not let the unit move on without a pass record.
7. Challenge the station at defined intervals with a known-bad sample, for example an image with one flipped bit. This proves that the station still rejects.

Mind the order of the steps: once you enable readout protection, a later readback is impossible. Verify first, then lock, then check that the lock bit is set.

Test-station and tool records

Torque, vision, leak and electrical test results are commercial and sometimes legal evidence. Records stored as plain files or rows can be altered or lost without a trace.

• Compute a record hash over serial number, station, time, result and measured values.
• Write records to an append-only store, or chain them as described in chapter 13, with periodic anchoring.
• Synchronize station clocks with a trusted time source, so that timestamps mean something.

Machine-to-machine communication

OPC UA offers message signing and encryption through its security modes Sign and SignAndEncrypt. Use them between stations, PLCs and the MES. Transport security protects the data in motion. It does not replace application-level checks on critical parameters, which must survive storage, conversion and export.

Station devices that error-proof the process

Some physical measures act like a checksum. The weight of a kit, for example, is a redundant property that must match the expected value.

19. Quality management and compliance

Quality systems ask for outcomes that checksums help to deliver: identification, traceability, controlled documents and trustworthy records. The standards rarely name checksums. They name outcomes, and a check is one way to prove an outcome.

Data integrity and ALCOA+ Regulators describe data integrity with the ALCOA principles: attributable, legible, contemporaneous, original and accurate. The extended ALCOA+ adds complete, consistent, enduring and available. A checksum maps to a few of these. It shows that a record is accurate and unchanged since it was created. A hash chain shows that records are complete and in order. A checksum does not show who created a record or when. It complements the audit trail and access control and does not replace them.

Traceability and recall readiness Traceability relies on identifiers that stay correct from component receipt to shipment. Check digits keep identifiers correct as they pass through scanners and keyboards. Genealogy links lot, batch and serial numbers across levels, one step up and one step down. Measure readiness with a mock recall. The metric is the time from a trigger, for example a supplier lot number, to the full list of affected finished units and their locations. Failed checks and duplicate identifiers are typical reasons why a mock recall takes days instead of hours.

Calibration, test equipment and supplier data Tie calibration certificates to equipment identifiers that carry a check digit, and keep a hash of each certificate file. For supplier certificates such as CoC, CoA and material test reports, ask for signed files or structured data. Compare lot number and part number automatically against the purchase order and the receiving record. For supplier CAD files, firmware and test programs, verify the digest against the transmittal before anyone uses the file.

Bonus: validating the check itself

In regulated settings the checking function is part of a computerized system and needs validation under GAMP 5 principles. Plan installation, operational and performance qualification (IQ, OQ and PQ) in proportion to risk.

The OQ must include negative tests. Feed the check bad data and prove that it rejects. Keep the test vectors in the validation file and rerun them after any change to software, reader firmware or label templates.

20. The Lean Six Sigma perspective

Poka-yoke and jidoka

Many commonalities with checksums: Shigeo Shingo formalized poka-yoke, or mistake-proofing, while working with Toyota. He separated control functions, which make the error impossible or stop the process, from warning functions, which only signal it. Jidoka, built-in quality, adds the stop: the machine halts when it detects an abnormality.

A check digit with a hard stop at a scan station is a control function. A scan failure that lets the unit pass anyway is only a warning. Audit your stations for exactly this difference.

FMEA

Rate the detection of each control honestly. A check with a hard stop, tested with known-bad samples and covering the failure cause, earns a better rating than the same check that operators can bypass. Record the evidence in the PFMEA.

The AIAG-VDA action priority method also pushes you to improve prevention first. Prevention here means designing the process so that the wrong data cannot arise, for example by generating identifiers and labels from one source instead of typing them.

DMAIC applied to data errors

The defects per million opportunities follow from the number of defects [latex]D[/latex], the units [latex]N[/latex] and the opportunities per unit [latex]O[/latex]. The sigma level adds the conventional 1.5 sigma shift to the normal quantile.

[latex]\displaystyle \mathrm{DPMO} = \frac{D}{N \times O} \times 10^{6}[/latex]

[latex]\displaystyle \sigma_{\mathrm{level}} = \Phi^{-1}\left(1 – \frac{\mathrm{DPMO}}{10^{6}}\right) + 1.5[/latex]

A worked example with illustrative numbers shows the arithmetic. 36 wrong-label defects in 480,000 labels, counting one opportunity per label, give [latex]\mathrm{DPMO} = 36 / 480000 \times 10^{6} = 75[/latex]. With the conventional 1.5 sigma shift, that is a sigma level of about 5.3. After the improvements, 6 defects in the next 480,000 labels give 12.5 per million and about 5.7 sigma. The figures illustrate the calculation. They are not a benchmark.

Control plan example

Three families of poka-yoke devices

Shingo grouped mistake-proofing methods into three families. Each has a counterpart among the checks in this guide:

Contact method Detects shape, size or color by touch or by a sensor, for example a limit switch or a keyed fixture. The data counterpart is a format or check digit test.

Fixed-value method Signals an error when a set number of parts or motions is not reached, for example a tray with counted positions. The data counterpart is a length field or a segment count.

Motion-step method Checks that the steps happen in the right sequence, for example an interlock that blocks a step until the previous one is complete. The data counterpart is a sequence number or a scan-to-release workflow.

21. Logistics: how to reduce warehouse picking errors

Picking errors are among the costliest data-driven failures in logistics. Each one starts a chain of returns, reshipments and complaints.

Scan-based error-proofing

1. Scan the label of the location first. Check digit and format validation catch a bad location code at once, and the WMS confirms that it is the expected location.
2. Scan the item or case GTIN. The system compares it with the pick task and rejects a wrong item before quantity entry.
3. Confirm the quantity by scan count, or by weight check where scanning every piece is impractical.
4. Scan the destination container or SSCC when closing the unit, and link the contents to it.
5. At loading, scan the SSCCs against the shipment manifest.

Quantify accuracy as defects per million lines picked. A line accuracy of 99.9 percent sounds high, yet it equals [latex](1 – 0.999) \times 10^{6} = 1000[/latex] errors per million lines, far from six sigma. State targets in DPMO, so that they connect to your Lean Six Sigma metrics.

22. Service, aftermarket and end of life

Over-the-air and field updates

An update process can fail in three ways. The transfer is corrupted, the image is wrong for the device, or the image is malicious. Layer the defences to match those failures.

• A CRC per chunk or per block catches transfer errors early.
• A hash of the whole image, checked before installation, confirms completeness.
• A signature check against a public key stored in the device confirms origin.
• A match of product and hardware identifier prevents installing an image meant for another device.
• A version check with rollback protection prevents downgrades to vulnerable releases.
• Dual partitions with a boot-time confirmation leave the old image runnable if the new one fails.

Spare parts, warranty and returns

• Spare part numbers carry a check digit, and web forms for warranty registration validate it, which exposes keying errors at the source.
• Serial numbers link a field failure to the production genealogy, including the firmware digest recorded at end of line.
• Reverse logistics needs the same identifiers and the same checks as the forward flow.

23. Accidental versus malicious corruption

The right check depends on who or what causes the error. Noise, wear and human slips are random. An attacker or a counterfeiter is not, and chooses the one modification that your check cannot see.

Collision attacks matter wherever two parties trust a digest over a file that one of them prepared. MD5 and SHA-1 fail this test. For message authentication, use HMAC and never a secret-prefix hash, because of length extension.

24. How to choose the right checksum

Start with the threat, then the data type, then the constraints. Work through the questions in order and stop at the first mechanism that fits, then add the next one if the answer to a later question is also yes.

1. Could someone change the data deliberately and benefit from it? If yes, use a digital signature or an HMAC. Keep a CRC or hash only for accidental errors.
2. Does a person type, read or scan the value? If yes, use a check digit on the identifier, validation at the scanner, and 2D marks with error correction against physical damage.
3. Does the data travel over a bus or sit in small memory? If yes, use a CRC with a polynomial chosen for the message length and the Hamming distance you need. Add an end-to-end CRC for critical parameters.
4. Must a file or record be shown identical to a reference? If yes, use SHA-256 for the comparison. A fast non-cryptographic hash is enough for non-critical comparisons.
5. Must the data survive damage without a retry? If yes, add an error-correcting code.
6. Is the data part of a regulated record? If yes, add an audit trail, validation, and a documented rationale for the chosen method.

25. Implementation guide

Three rules save most of the pain. Use a tested library or a single shared implementation. Fix every parameter in a controlled document. Test with published vectors before the first production run. Appendix B holds the vectors used below.

def gs1_check_digit(body: str) -> int:
    if not body.isdigit():
        raise ValueError('digits only')
    total = sum(int(d) * (3 if i % 2 == 0 else 1)
                for i, d in enumerate(reversed(body)))
    return (10 - total % 10) % 10

def gs1_is_valid(full: str) -> bool:
    return (full.isdigit() and len(full) > 1
            and gs1_check_digit(full[:-1]) == int(full[-1]))

assert gs1_check_digit('400638133393') == 1
assert gs1_check_digit('34012345000000001') == 7
assert gs1_is_valid('4006381333931')

=MOD(10-MOD(SUMPRODUCT(--MID(A1,{1,3,5,7,9,11},1))+3*SUMPRODUCT(--MID(A1,{2,4,6,8,10,12},1)),10),10)

WITH RECURSIVE d(i, n) AS (
  SELECT 1, LENGTH('400638133393')
  UNION ALL
  SELECT i + 1, n FROM d WHERE i < n
)
SELECT (10 - (SUM(CAST(SUBSTR('400638133393', i, 1) AS INTEGER)
                * CASE WHEN (n - i) % 2 = 0 THEN 3 ELSE 1 END) % 10)) % 10
       AS check_digit
FROM d;

FUNCTION GS1_CheckDigit : INT
VAR_INPUT
    sBody : STRING(17);
END_VAR
VAR
    i, n, iSum : INT;
END_VAR

n := LEN(sBody);
iSum := 0;
FOR i := 1 TO n DO
    IF ((n - i) MOD 2) = 0 THEN
        iSum := iSum + 3 * STRING_TO_INT(MID(sBody, 1, i));
    ELSE
        iSum := iSum + STRING_TO_INT(MID(sBody, 1, i));
    END_IF
END_FOR
GS1_CheckDigit := (10 - (iSum MOD 10)) MOD 10;

uint32_t crc32_update(uint32_t crc, const uint8_t *data, size_t len)
{
    while (len--) {
        crc ^= *data++;
        for (int bit = 0; bit < 8; bit++) {
            crc = (crc >> 1) ^ (0xEDB88320u & (0u - (crc & 1u)));
        }
    }
    return crc;
}

/* Start with 0xFFFFFFFF, feed every chunk, finish with a final XOR:
   crc = 0xFFFFFFFFu;
   crc = crc32_update(crc, buffer, length);
   crc ^= 0xFFFFFFFFu;
   The result for the ASCII string 123456789 is 0xCBF43926. */

import hashlib

def crc16_modbus(data: bytes) -> int:
    crc = 0xFFFF
    for byte in data:
        crc ^= byte
        for _ in range(8):
            crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1
    return crc

frame = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x0A])
crc = crc16_modbus(frame)
wire = frame + bytes([crc & 0xFF, crc >> 8])   # low byte first

def sha256_file(path, chunk=1024 * 1024):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        for block in iter(lambda: f.read(chunk), b''):
            h.update(block)
    return h.hexdigest()

Pitfalls in Checksum Implementations

26. Best-practice checklist by role

R&D and design Define a check digit and a fixed format in every identifier scheme, starting with the first draft of the numbering concept. Give firmware images a header with magic number, version, length, CRC and signature, and specify the behaviour on failure. Document CRC parameters and the reasoning for the polynomial in the interface specification. Store hashes of released packages in the release record and in supplier transmittals. Include diagnostic coverage of memory and communication checks in the safety analysis.	조작 Run scan and flash stations as gates with hard stops, and log every bypass. Verify firmware by readback or by a device-reported digest, and record the result per serial number. Compare active recipes with the golden hash at the start of each lot. Challenge each check with a known-bad sample every shift. Keep verifiers and scanners calibrated and maintained.
	품질 Rate FMEA detection from evidence, such as challenge test results and bypass records. Validate the checks, and keep the test vectors in the validation file. Run mock recalls and track the time to the list of affected units. Chart scan failure rates and verification grades, and act on trends. Match supplier certificates automatically against purchase order and receiving data.
기호 논리학 Scan to confirm location, item and container at each pick. Validate identifiers and messages at receipt, and track the rejection rate per trading partner. Allocate SSCCs centrally and enforce uniqueness. Verify labels at the point of labeling and use 2D symbols for long or rough supply chains. Express targets in defects per million lines.	IT and OT Provide one shared library or service for check digits, CRCs and hashes, with published test vectors. Sign firmware and builds, keep private keys in a hardware security module, and plan rotation and revocation. Synchronize clocks and keep records in append-only stores or hash chains with external anchoring. Store identifiers as strings in every system that touches them. Plan algorithm agility, because SHA-1 is being retired and post-quantum signatures are coming.

Conclusion on Checksums and Similar

Checksums are small, old and well understood. Their value in physical product work comes from placing the right one at the right point of the lifecycle, and from treating the check as a controlled process with evidence.

Use check digits where people and scanners handle identifiers. Use CRCs for frames, blocks and images, with a polynomial that fits the message length. Use SHA-256 for files and records, and signatures or keyed codes wherever deliberate change is a risk. Add error correction where marks and memories will be damaged.

Then close the loop with evidence. Challenge the checks, calibrate the verifiers, record the results and review the numbers. A check that nobody tests is an assumption.

자주 묻는 질문

Appendices

Appendix A: Test vectors

All values were computed or confirmed with the code shown in chapter 25 or with reference tools. All input strings are given as ASCII text.

Appendix B: Standards and references

Online sources used for this article, checked in November 2026:

• GS1 General Specifications 그리고 GS1 UK guide to calculating a check digit
• 49 CFR 565.15, content requirements of the VIN
• ISO/IEC 15416:2025 그리고 ISO/IEC 15415:2024, print quality grading of linear and two-dimensional symbols
• CAN in Automation, CRC in CAN frames
• Koopman, 32-bit cyclic redundancy codes for Internet applications
• Reveng CRC catalogue
• NIST, retirement of SHA-1
• Matheson, Cyber Resilience Act reporting obligations
• European Commission, batteries and the battery passport 그리고 Digital Product Passport registry announcement
• FDA, DSCSA exemptions for small dispensers 그리고 Buchanan, extension to 2027

Standards and publications cited by name, available from the issuing bodies:

• RFC 1071 (Internet checksum), RFC 2104 (HMAC), RFC 3161 (timestamp protocol)
• FIPS 180-4 (SHA-1 and SHA-2), FIPS 202 (SHA-3), NIST SP 800-38B (CMAC)
• ISO/IEC 7064 (check character systems), ISO 6346 (container codes), ISO/IEC 29158 (direct part mark quality)
• ISO 9001, IATF 16949, AS9100, ISO 13485, ISO 26262, IEC 61508, IEC 62304, IEC 62443
• AIAG and VDA FMEA Handbook, 1st edition, 2019
• 21 CFR Part 11, EU GMP Annex 11, GAMP 5
• Maxino and Koopman, The Effectiveness of Checksums for Embedded Control Networks, IEEE Transactions on Dependable and Secure Computing, 2009
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products), Regulation (EU) 2023/1542 (Batteries), Directive (EU) 2022/2555 (NIS2)