Title: Safety Design Decisions Across Vehicle Domains | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/domain-safety-design-decisions Description: Nine automotive domains walk the exact same ISO 26262 Part 3-6 chain - Item Definition, HARA, FSC, TSC, HSI, hardware and software - yet arrive at radically different technical answers. --- Concept guide · ISO 26262-3 to -6 · 11 chapters # Safety Design Decisions Across Vehicle Domains Powertrain, brakes, steering, ADAS, battery, cockpit, airbag, power-net and thermal systems all walk the same ISO 26262 Part 3-6 chain - yet each arrives at a different technical answer. Learn the four forces that make one method produce nine different architectures, and why none of those differences are arbitrary. 9 Vehicle Domains 11 Chapters 7 Work-Product Steps QM-D ASIL Range Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fdomain-safety-design-decisions&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **The Design-Decision Chain** 2. 02 **Powertrain: EV Traction & Torque Control** 3. 03 **Braking: ESC & Brake-by-Wire** 4. 04 **Steering: EPS & Steer-by-Wire** 5. 05 **ADAS: AEB & L2 Highway Assist** The short version ## Quick answers What are domain safety design decisions in ISO 26262? Domain safety design decisions are the concrete architectural answers - safe states, monitoring concepts, redundancy patterns, and timing budgets - that each vehicle domain derives when it walks the ISO 26262 Part 3 to Part 6 chain from item definition through HARA, functional and technical safety concepts, the hardware-software interface, and hardware and software design. Powertrain, brakes, steering, ADAS, battery, cockpit, airbag, power-net, and thermal systems all use the same method, yet land on different architectures because their hazard physics, fault-tolerant time intervals, ASIL profiles, and availability needs differ. None of those differences are arbitrary - each is traceable to a safety goal. Why do ASIL D systems have different architectures in different domains? Because the hazard dictates the answer. An EV powertrain fighting unintended torque can simply shut off - so it uses three-level (E-Gas style) monitoring with two independent shut-off paths and a millisecond FTTI. An AEB function, whose dominant hazard is false-positive braking, can just stop acting - so it centres on two-modality sensor confirmation and a doer/checker split. A traction battery has safety goals running in seconds, not milliseconds, which permits a smart-primary/dumb-secondary protection layering. Same standard, same chain, opposite architectures - and both are correct, which is exactly what the cross-domain synthesis chapter demonstrates. 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 3 ## Why it pays for itself ### Defend design choices in review See why three-level monitoring belongs in powertrain, doer/checker in ADAS, and dual-winding motors in steering - so you can justify an architecture from hazard physics instead of copying a neighboring domain. ### Nine domains, one method Walk the same Part 3 to 6 chain - item definition, HARA, FSC, TSC, HSI, hardware, software - through nine real vehicle domains and learn the four forces that make the answers diverge. ### Safe states from physics Derive torque-off, honest-blank, ramp-down, or degrade-and-continue from how fast each hazard develops, and set FTTI as a calculation from hazard dynamics rather than a negotiation with the supplier. After the course ## What you’ll be able to do ### Trace any domain down the Part 3-6 chain Walk a system from Item Definition through HARA, FSC, TSC, HSI, hardware and software without skipping a link. ### Derive safe states from hazard physics Read a hazard's dynamics to justify torque-off, honest-blank, or ramp-down rather than picking a safe state by habit. ### Set FTTI from hazard dynamics Calculate fault-tolerant time intervals from how fast a hazard develops instead of negotiating them after the fact. ### Justify redundancy and monitoring per ASIL Explain why three-level monitoring, doer/checker or dual-winding motors appear where they do and not elsewhere. ### Design safety islands inside QM systems Protect an ASIL element with freedom-from-interference arguments while the rest of the domain stays QM. ### Compare architectures across nine domains Recognise which safety patterns repeat and which diverge so you can defend a design choice in review. The curriculum · 11 chapters ## Chapter by chapter 1. 01 **The Design-Decision Chain** The same seven-step work-product sequence - Item Definition, HARA, FSC, TSC, HSI, hardware and software - that every safety-related E/E system walks, and the four forces that push domains toward different answers. - Requirements flow down, safety arguments flow up - A decision untraceable to a safety goal is not a safety decision - Why hazard physics, FTTI and ASIL diverge the outcomes 2. 02 **Powertrain: EV Traction & Torque Control** How an electric drive derives its safety goal against unintended torque, landing on three-level monitoring and two independent shut-off paths. - Unintended acceleration as the ASIL D driver - Three-level (E-Gas style) monitoring concept - Two independent torque shut-off paths 3. 03 **Braking: ESC & Brake-by-Wire** Why an integrated one-box brake system treats degradation as a ladder rather than a switch, and where ASIL D forces redundancy. - Loss of braking as the ASIL D hazard - Graceful degradation ladder, not a hard cutoff - Hydraulic and electronic fallback paths 4. 04 **Steering: EPS & Steer-by-Wire** The ramp-down doctrine for electric power steering, built on a fail-silent channel, dual-winding motor and bounded torque overlay. - Self-steering and torque reversal hazards - Fail-silent channel with bounded overlay - Dual-winding motor for ASIL D availability 5. 05 **ADAS: AEB & L2 Highway Assist** A system that can simply stop acting - so its safety concept centres on false-positive braking, two-modality confirmation and a doer/checker split. - False positive vs false negative asymmetry - Two-modality sensor confirmation - Doer/checker architecture and mode-confusion control 6. 06 **HV Battery Management System** A 400 V traction battery whose safety goals run in seconds not milliseconds, split into a smart primary and a dumb secondary protection layer. - Thermal runaway and overcurrent hazards - Seconds-scale FTTI changes the whole design - Smart-primary / dumb-secondary contactor control 7. 07 **Airbag & Restraint Systems** The famous ASIL asymmetry - inadvertent deployment is ASIL D while non-deployment is lower - and a domain with no meaningful FTTI. - Inadvertent deployment ASIL D asymmetry - A domain effectively without an FTTI - Two independent arming decisions in series 8. 08 **Power Distribution & E-Fuse** A zonal 12 V power net that inherits availability hazards from other items, using selective tripping and a load-shedding ladder on a millisecond clock. - Hazards owned by other items, executed here - Partitioned net with selective e-fuse tripping - Priority-based load-shedding ladder 9. 09 **QM Domains with Safety Islands** Cockpit/infotainment and EV thermal systems that are mostly QM, protecting a small ASIL island in a QM ocean via the honest-blank and integrity-island doctrines. - Honest-blank safe state, not keep-showing-something - Safety islands and freedom from interference in QM - Safe states derived from hazard physics, not chosen 10. 10 **Cross-Domain Synthesis** The patterns that repeat and the ones that diverge, showing FTTI as a derivation from hazard dynamics rather than a negotiation. - FTTI derived from how fast hazards develop - Comparing safe states across all nine domains - Prevention-only vs degrade-and-continue strategies 11. 11 **The HSI as the Domain Contract** How the Hardware-Software Interface pins down registers, timing, and diagnostics differently in each domain to make the split responsibilities auditable. - What hardware guarantees software and vice versa - Selected contract entries per domain - Timing and diagnostic coverage obligations Diagrams & Visuals ## Not just text: the visual toolkit ### The Part 3-6 Decision Chain Animates the seven work products from Item Definition through software design and shows how each decision constrains the next. ### Cross-Domain Safe-State Map Compares the chosen safe state for each of the nine domains against the hazard physics that forced it. ### FTTI Timeline by Domain Plots fault-tolerant time intervals from milliseconds in steering to seconds in the battery to show why architectures diverge. ### Degradation Ladder Diagram Shows how braking and power distribution degrade in graded steps instead of a single hard cutoff. ### Doer/Checker & Redundancy Patterns Contrasts the ADAS doer/checker split, the steering fail-silent channel and the battery dual-layer protection. ### Safety Island in a QM Ocean Illustrates freedom from interference between a small ASIL island and the surrounding QM cockpit or thermal software. Worked Example ## One Hazard, Two Domains, Two Very Different Answers Take 'unintended longitudinal motion' as it appears in the EV powertrain and in the ADAS AEB function. Both start from an ASIL C/D hazard, yet the powertrain lands on three-level torque monitoring with two shut-off paths while AEB lands on two-modality confirmation with a doer/checker split - because the hazard physics and FTTI differ. - Powertrain safe state: torque-off via two independent shut-off paths, millisecond FTTI - AEB safe state: stop acting (release brake demand), false-positive braking as the dominant hazard - Powertrain TSC: three-level (E-Gas) monitoring on an ASIL D lockstep core - AEB TSC: two-modality sensor confirmation guarding against phantom targets - Divergence driver: FTTI derived from how fast each hazard develops, not chosen - Same standard, same chain, opposite architectures - and both are correct Cross-Domain Decision Table Powertrain (ASIL D): unintended torque, safe state = torque-off, two independent shut-off paths Unlock the full nine-domain decision table with safe states, FTTI and architecture per domain Built for ## Who this guide is for - Engineers moving between domains - from powertrain to ADAS, or braking to battery - System architects who must explain why their TSC differs from the sister project - Safety newcomers who know the method but have not seen it produce real architectures - Reviewers judging whether a proposed safe state actually fits the hazard ## Frequently Asked Questions Common questions about Safety Design Decisions Across Vehicle Domains The fault-tolerant time interval is derived from how fast the hazard develops, not negotiated. Self-steering torque becomes uncontrollable in tens of milliseconds; thermal runaway in a battery builds over seconds; an airbag has effectively no meaningful FTTI because inadvertent deployment is instantaneous. Reading the hazard dynamics gives you the interval, and the interval then forces the architecture - it decides whether monitoring can live in software, whether you need a hardware path, and how detection and reaction windows split. The course plots FTTI across all nine domains to make the derivation visible. Cockpit, infotainment, and EV thermal systems are mostly QM, but each usually contains one small safety-relevant function - a telltale, a warning, a protective cutoff. Rather than raising the whole domain to an ASIL, you protect a small ASIL island inside the QM ocean using freedom-from-interference arguments: partitioning, monitoring, and an honest-blank safe state that shows nothing rather than something stale and wrong. The course covers the honest-blank and integrity-island doctrines and how to argue them without over-engineering the surrounding QM software. The guide runs 11 chapters across 9 vehicle domains: the seven-step work-product chain, then powertrain, braking, steering, ADAS, HV battery, airbag, power distribution, and the QM domains with safety islands, closing with a cross-domain synthesis and the HSI as the domain contract. It includes 6 diagrams - among them the cross-domain safe-state map and the FTTI timeline - plus a worked example following one hazard through two domains to two very different answers. A free account starts you off, and the Pro and Expert plans unlock more of the library. ## 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%2Fdomain-safety-design-decisions&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)