How would you decide the width and generator polynomial for the frame check on a new long-lived industrial bus?

## Start from a failure budget, not from a width The question "16 or 32?" has no answer until someone states the rate of **accepted corrupt frames** the system can live with. That number comes from the consequence, not from the protocol: a frame that nudges a dashboard reading and a frame that commands an actuator sit orders of magnitude apart. With it, the arithmetic runs in one direction: 1. Estimate frames per second, from the busiest configuration the bus will ever be sold into — not today's. 2. Estimate the fraction of frames arriving corrupted, from the physical layer and the environment. 3. Multiply by the residual, about `2^-r`, and compare against the budget. Solve for `r`. The result is usually generous, because the residual falls by a factor of 65,536 for two extra bytes. The value of the exercise is less the width it picks than the assumptions it forces onto paper, where a reviewer can argue with them. ## Match the width to the noise structure The residual describes unstructured damage. Real buses rarely deliver that. Electrical disturbance smears across adjacent bit times, so the guaranteed **burst window** — equal to the generator's degree — is frequently the guarantee that earns its keep. - If the fault model is disturbance events of a known duration, convert that duration into bit times at the line rate and require the degree to exceed it. - If the model is scattered single flips, the odd-weight guarantee from an `(x + 1)` factor matters more than raw degree. - Where the environment is genuinely unknown, choose for bursts: it is the failure mode that physical links actually exhibit. ## Choose a characterised generator; do not invent one Home-made polynomials are where this goes wrong quietly. A generator's guarantee for **isolated multi-bit errors** holds only up to a maximum data length, and published generators come with that characterisation as a table rather than a slogan. | Decision input | What it tells you | | --- | --- | | Maximum frame length in bits | Which characterised length range the generator must cover | | Dominant fault: bursts | Required generator degree | | Dominant fault: scattered flips | Whether to require the `(x + 1)` factor for odd weight | | Budget from step one | Minimum width from the residual | The `(x + 1)` factor is a genuine trade rather than a free win: reserving it guarantees every odd-weight pattern, and it constrains what the remaining factors can deliver for isolated flips at a given length. Make that choice explicitly against the fault model. ## Decide the coverage extent and what happens at hops Two design decisions here outrank the polynomial: - **Which bytes are covered.** Every field excluded from the division is unprotected forever, and exclusions made for implementation convenience tend to be relied upon later as though they were protected. - **Per-hop or end-to-end.** If relays verify and recompute, each wire is protected and the relay's own memory is not: corruption inside it is re-blessed by a freshly computed field and travels on looking perfect. If that matters, carry an additional check computed once at the source and verified only at the sink, above the link check rather than instead of it. ## Nail the parameterisation in the specification The classic interoperability failure is not the polynomial; it is everything around it. Two vendors implementing "the same" 32-bit CRC will disagree unless the specification pins, by value and with a worked test vector: - the generator, written out unambiguously; - the initial register value; - whether input bits and the output are reflected; - the final inversion, if any; - the byte order of the field inside the frame; - the exact covered byte range, by offset. A published test vector — one named frame, one expected field — settles all six at integration time instead of on a customer's site. ## Decide tamper evidence separately Ask explicitly whether any party might have an interest in a modified frame being accepted. If yes, the answer is a **keyed authentication tag** as its own field, with its own key distribution and rotation story, layered above a link check that keeps doing its cheap noise-filtering job. It is never a wider check field, because the construction is public and linear at every width. Write the distinction into the specification's own wording, so nobody downstream reads "integrity" as covering an adversary. ## Design for the lifetime A bus that ships for twenty years cannot renegotiate. Carry a version or format identifier in the frame from day one, so a future revision can introduce a different check or an additional field without a flag day, and record the failure-budget assumptions beside the specification — the next engineer needs to know what the width was chosen against, not just what it is.