SW Architecture & Unit Design

ISO 26262-6, Clause 7 requires a software architecture that implements the software safety requirements and supports their verification. That means applying design principles - modularity, encapsulation, restricted coupling, high cohesion - with rigor scaled by ASIL through the method tables; performing safety analysis at the architectural level to identify how errors propagate; ensuring freedom from interference when components of different ASIL coexist; and specifying the safety mechanisms (range checks, plausibility monitoring, program flow monitoring, E2E protection) allocated to the architecture. Clause 8 then carries the same discipline into unit design: notations, data type discipline, and design for structural testability, all traceable to the requirements above.

Freedom from interference (FFI) is the absence of cascading failures from a lower-ASIL (or QM) component to a higher-ASIL one sharing the same ECU. ISO 26262-6 treats three interference channels: memory (a QM task corrupting ASIL data - countered by MPU-backed spatial partitioning and stack protection), timing (a runaway task starving the safety function - countered by temporal partitioning, scheduling budgets and deadline monitoring), and exchange of information (corrupted or stale messages - countered by E2E protection, CRCs and alive counters). Without demonstrated FFI, every component on the ECU must be developed to the highest ASIL present - which is usually unaffordable.

Part 6 requires mechanisms for error detection and error handling at the architectural level, selected by ASIL from its method tables rather than as a fixed list. The working set in practice: range and plausibility checks on inputs and outputs, control flow monitoring to catch program sequence corruption, memory integrity mechanisms such as CRC verification of parameters and code, end-to-end protection with sequence and alive counters on safety-relevant communication, and defensive design at unit level - pre and postconditions, invariants and disciplined data types. Each mechanism must trace to a safety requirement and be verified, not just sprinkled in as good practice.

AUTOSAR provides the standardized platform mechanisms that safety architectures are built from: OS applications as partitioning units with MPU-backed memory protection for spatial FFI, timing protection in the OS for temporal FFI, the Watchdog Manager for supervised program flow, and the E2E library for communication protection between software components. The layered architecture also gives a clean structure for mixed-criticality integration - deciding which SWCs, which BSW modules and which OS applications carry which ASIL. The guide covers configuring these mechanisms so the AUTOSAR platform actually delivers the FFI claims your architecture depends on, rather than assuming the platform is safe by default.

The guide has 14 chapters, from the ISO 26262-6 scope and theoretical foundations through architectural principles, architecture patterns, unit design, freedom from interference, software-level DFA and safety analysis, AUTOSAR architecture, software safety mechanisms, coding guidelines integration and mixed-criticality design, to ML/AI integration, verification and review, and best practices. It goes to ASIL D design depth with AUTOSAR treated as a first-class architecture. A free account starts you off, and the Pro and Expert plans unlock more of the library.