In-Vehicle Network Safety

Because the claim a bus makes is local and one hop wide. A CAN controller reporting success has observed a valid transmission that at least one node acknowledged, and an Ethernet frame check covers one link segment. None of that proves the intended receiver got the data, that the value is recent enough for the vehicle state it describes, that it is the next sample rather than a replay, or that it came from the expected producer. Those four properties belong to the consuming function, and they have to be established by explicit requirements and endpoint checks rather than inherited from the protocol.

ISO 26262-6:2018 Annex D catalogs the ways an exchange of information can fail, including repetition, loss, delay, insertion, masquerade or incorrect addressing, incorrect sequence, corruption, asymmetric information reaching different receivers, information accepted by only a subset of receivers, and blocking access to the channel. The catalog is finite, which is its great virtue, and Annex D also names the families of detection mechanisms that address it. The guide crosses the two lists into a matrix and shows why no single mechanism covers everything, and why some modes need receivers comparing notes rather than a library setting.

It is one of two answers to the question of who carries the safety claim for data in transit. The white-channel answer allocates safety requirements to the elements of the transmission system itself. The black-channel answer places the integrity checks at the endpoints and treats transport behavior abstractly through an explicit fault model and stated assumptions such as bounded delay, independence and freedom from interference. It does not mean arbitrary faults are tolerated or that infrastructure carries no obligations: timing, availability, routing and interference requirements can still be allocated to gateways and switches.

No, for two separate reasons. The scope reason needs no mathematics: a link check is computed when a frame enters one link and verified when it leaves, so corruption in sender memory, in a gateway buffer, or between an ingress check and a freshly generated egress check is simply outside its coverage. The vocabulary reason is that even a perfect check only says these bits equal those bits; it cannot say who produced them, when they were produced, or where they belong in a sequence. That is why an end-to-end layer is a bundle of counter, timeout, relationship identifier and its own check over the protected data rather than a stronger checksum.

It depends on which of three patterns the architecture uses. In pass-through the gateway forwards the protected bytes without interpreting them, so its memory and software sit inside the protected span, which is the pattern worth fighting frame-layout battles to keep. In check-and-re-protect, forced by translation and repacking, the data crosses gateway memory unprotected between the check and the re-protection, and that gap needs named coverage and allocated requirements on the transformation function. Unprotected translation, where a signal is repacked with no protection on the far side, is the anti-pattern: it converts every gateway fault into clean-looking data at the consumer.

It runs 14 chapters as one arc: what six bus technologies actually provide, the Annex D failure catalog and the mode-versus-mechanism matrix, receiver-driven requirement derivation and signal contracts, the black-channel argument and residual error reasoning, AUTOSAR E2E profiles and receiver check statuses, the detection-to-reaction budget against the fault tolerant time interval, fault containment and fail-silence, gateways and their three protection patterns, redundancy and independence, load and overload behavior, the comm matrix as a controlled safety artifact, an interactive network fault laboratory, and a fictional radar to braking path worked end to end with its requirement set, budget arithmetic, assessor questions and pitfalls checklist.