Title: In-Vehicle Network Safety | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/in-vehicle-network-safety Description: What CAN, CAN FD, CAN XL, LIN, FlexRay and automotive Ethernet actually guarantee, the communication failure catalog of ISO 26262-6 Annex D, receiver-driven signal contracts, the black-channel argument, AUTOSAR E2E protection, containment, gateways and the comm matrix as a safety artifact. --- Concept guide · ISO 26262-6 Annex D + AUTOSAR E2E · 14 chapters # In-Vehicle Network Safety Follow one safety-related signal from sensor to consumer across six bus technologies and two gateways, and learn what has to be true before a receiver may act on it. 14 Chapters 6 Bus technologies 10 Failure categories 12 Pitfalls checklist Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fin-vehicle-network-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **The Message Arrived. So What?** 2. 02 **Six Buses, One Vehicle** 3. 03 **The Communication Fault Model** 4. 04 **Requirements Come From the Receiver** 5. 05 **The Black Channel** The short version ## Quick answers Why is a successful transmission not enough for safety-related data? 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. What communication failure modes does ISO 26262 identify? 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. Keep going, free - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 6 ## Why it pays for itself ### Stop confusing delivery with safety The gap between what a bus acknowledges on one hop and what a consuming function needs end to end becomes an explicit checklist: age, order, communication relationship and meaning, each with the mechanism that covers it and the mechanism that cannot. ### Requirements with a direction The receiver-driven derivation chain and the signal contract replace network folklore with numbers you can defend: tolerated staleness, tolerated losses, counter behavior, the mapped reaction, and the way back out of a degraded mode. ### The failure sites nobody budgets for Gateways, comm matrix releases and overload each manufacture failures that leave every naive indicator green. The chapters on those three carry the traps that surface late, in integration labs and in the field, rather than in design reviews. After the course ## What you’ll be able to do ### Derive Communication Requirements From the Consumer Start every communication safety argument at the consuming function, establish its real tolerance for age, loss and corruption, and allocate obligations to sender, network and receiver from there. ### Write Signal Contracts Both Sides Can Be Held To Specify value domain, cycle behavior, age semantics, counter rules, communication relationship, failure reaction and re-integration so nothing is left to an integration meeting three years later. ### Select and Place End-to-End Protection Deliberately Choose an E2E profile from payload, bus, residual-error allocation and multiplicity instead of precedent, and place protect and check at the application boundaries that make the span mean what you claim. ### Budget Detection and Reaction Against the FTTI Sum the worst cases of aging, detection, qualification and reaction, count from the fault rather than from the moment you noticed it, and know which four levers are left when the budget breaks. ### Read a Gateway Path Honestly Recognize the re-protection gap, keep pass-through where you can, name the coverage when translation forces a break, and treat a mixed-criticality gateway as the freedom-from-interference problem it is. ### Govern the Comm Matrix Like Safety-Related Software Baseline the matrix, pair releases across ECU builds, run change impact analysis on it, and apply tool confidence reasoning to the generator chain that compiles it into every image. The curriculum · 14 chapters ## Chapter by chapter 1. 01 **The Message Arrived. So What?** Why a successful transmission is not a safety claim: the local, one hop claim a bus actually makes against the age, order, source and meaning a consuming function needs, and where communication requirements enter the safety lifecycle. - The claim gap - Local versus end to end - Receiver-driven from the start 2. 02 **Six Buses, One Vehicle** What classical CAN, CAN FD, CAN XL, LIN, FlexRay and automotive Ethernet natively provide, from arbitration and error confinement to TDMA schedules and per-link frame checks, and the four blind spots every one of them shares. - CAN family mechanics - Scheduled buses - The per-hop trust gap 3. 03 **The Communication Fault Model** The finite failure catalog of ISO 26262-6:2018 Annex D, the physical, silicon, software and configuration causes behind it, and the matrix crossing failure modes against detection mechanism families. - Annex D catalog - Mode versus mechanism matrix - One fault, several masks 4. 04 **Requirements Come From the Receiver** The derivation chain from safety goal to consumer tolerance to obligations on sender, network and receiver, written down as a signal contract that covers value domain, timing, ordering, identity, failure behavior and who checks what. - Derivation chain - The signal contract - Three review-triggering sentences 5. 05 **The Black Channel** The white-channel and black-channel styles of argument, why a bus CRC is standing in the wrong place before its strength is even discussed, how residual error is reasoned about honestly, and the three things endpoint protection does not cover. - White versus black channel - CRC scope and strength - Stated exclusions 6. 06 **E2E Protection Done Right** What each field of an end-to-end header buys against the Annex D catalog, how the AUTOSAR E2E profile family differs and how to select from it deliberately, the receiver check statuses and their mandatory reactions, and what protection costs in bandwidth, CPU and process. - Header fields earned - Profile selection drivers - Placement and cost 7. 07 **From Detection to Reaction** The five stages between a fault and a completed reaction, why the worst-case sum has to fit inside the fault tolerant time interval, how timeouts must cover healthy jitter, and the aging-data trap that starts the clock earlier than teams expect. - FTTI budget - Timeout versus jitter - Re-integration rules 8. 08 **Containment: Bus-Off, Babbling Nodes and Guardians** Protecting the medium rather than the data: CAN error confinement and the rejoin policy that decides whether a faulty node flaps forever, the babbling idiot that error confinement cannot touch, and fail-silence as a per-interface design goal. - Error confinement - Four answers to babbling - Fail-silent anatomy 9. 09 **Gateways: The Middle of the Network** The busiest failure site on a zonal signal path: the six jobs a gateway performs, the recurring gateway faults mapped to what the consumer actually sees, and the three ways end-to-end protection survives a crossing, or does not. - Gateway fault catalog - Three E2E patterns - Signal to service 10. 10 **Redundancy and Independence** For functions where stopping is not safe: what a second channel really buys against random and systematic faults, how physical, logical and temporal independence are argued with evidence, and why the selection logic becomes the new single point. - When redundancy is warranted - Common-cause hunting - The voter problem 11. 11 **Bandwidth, Priority and Overload** How a network lies without corrupting a bit: average load versus burst alignment, CAN arbitration and the inversion mechanisms that decide whether the worst case is bounded, queue behavior on switched links, and degraded communication modes designed in advance. - Load as a safety parameter - Priority inversion - Designed load shedding 12. 12 **The Comm Matrix Is a Safety Artifact** One system description compiled into every ECU image, which makes a single configuration error a fleet-wide systematic fault: the defects a matrix can write, the governance that contains them, and tool confidence for the generator chain. - Fleet-wide fan-out - Baselines and release pairing - Generator tool confidence 13. 13 **The Network Fault Laboratory** Every mechanism from the previous chapters wired onto one path with you holding the injector, then the step to a production campaign: injection levels, requirement-based pass criteria, coverage honesty and four ways campaigns fool their owners. - Interactive fault injection - Five injection levels - Pass criteria that bind 14. 14 **Worked Path: Sensor to Zone to Central Compute** A fictional radar to braking path carrying the whole page: derived communication safety requirements with allocation and verification, the data-age budget arithmetic, five assessor questions answered in line, and a pitfalls checklist tagged by chapter. - Derived requirement set - Assessor questions - Twelve-item checklist Built for ## Who this guide is for - Network and communication architects allocating safety requirements across buses and gateways - Safety engineers writing technical safety requirements for signals that cross ECU boundaries - AUTOSAR and basic-software integrators configuring E2E protection and timeout monitoring - Gateway and zone controller developers facing mixed-ASIL traffic on one box - Test and validation engineers designing communication fault-injection campaigns ## Frequently Asked Questions Common questions about In-Vehicle Network Safety 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. ## Start the course today A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fin-vehicle-network-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)