Title: Software Architectural & Unit Design | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/software-architectural-unit-design Description: Learn architecture patterns for fault isolation, testability, and diagnostic coverage in safety-critical software. --- Concept guide · ISO 26262-6 §7-8 · 14 chapters # SW Architecture & Unit Design Master ISO 26262-6 software architectural design principles, safety design patterns, Freedom from Interference, AUTOSAR architecture, and unit design techniques for safety-critical automotive software. 14 Chapters FFI Core Topic AUTOSAR Architecture ASIL-D Design Depth Included in Pro Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fsoftware-architectural-unit-design&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **Overview & Scope** 2. 02 **Theoretical Foundations** 3. 03 **Architectural Design Principles** 4. 04 **Architecture Patterns** 5. 05 **Unit Design** The short version ## Quick answers What does ISO 26262-6 require for software architectural 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. What is freedom from interference in software? 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. 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, Clause 7-8 ## Why it pays for itself ### Architect with the right principles Apply the ISO 26262-6 design principles - modularity, encapsulation, low coupling, high cohesion, defensive design - plus safety patterns such as monitor-actuator, safety wrapper and 1oo2 voting. ### Partition mixed-criticality software Master freedom from interference for mixed-ASIL designs: temporal and spatial partitioning, information hiding, and communication integrity between components of different ASIL on one ECU. ### Design units that pass verification Write unit designs with proper data types, range checks, pre and postconditions and documented invariants, structured for the reviews and structural coverage testing that follow. After the course ## What you’ll be able to do ### Design Safety Architectures Apply ISO 26262-6 architectural design principles and proven safety patterns to create modular, analyzable, and verifiable software structures. ### Implement FFI Partitioning Enforce Freedom from Interference between mixed-criticality software components using temporal partitioning, spatial partitioning, and communication integrity mechanisms. ### Apply SW Safety Mechanisms Select and implement the right software safety mechanisms for each failure mode including range checks, program flow monitoring, and E2E protection. ### Design AUTOSAR Safety Applications Structure AUTOSAR-based software with appropriate OS application configuration, memory protection, and communication stack safety settings. ### Handle Mixed-Criticality Systems Design software architectures where ASIL-A through ASIL-D components coexist with proper isolation, monitoring, and decomposition strategies. ### Verify Architecture & Unit Design Plan and execute architecture verification activities with appropriate methods, independence levels, and completeness criteria per ISO 26262-6. The curriculum · 14 chapters ## Chapter by chapter 1. 01 **Overview & Scope** Introduce the scope of software architectural and unit design within ISO 26262-6, clarify the relationship between architectural design, unit design, and implementation, and map to the V-Cycle phases. - Scope definition - V-Cycle placement - Phase relationships 2. 02 **Theoretical Foundations** Build the theoretical foundation for safety-oriented software design including fault models, error propagation, design for testability, and the role of formal specification in high-ASIL components. - Fault models - Error propagation - Formal specification 3. 03 **Architectural Design Principles** Apply ISO 26262-6 architectural design principles including modularity, encapsulation, low coupling, high cohesion, and the use of defensive design strategies to prevent error propagation. - Modularity & encapsulation - Coupling & cohesion - Defensive design 4. 04 **Architecture Patterns** Explore architectural patterns for safety-critical software including monitor-actuator, watchdog supervisor, safety wrapper, heterogeneous redundancy, and 1oo2 voting architectures with ASIL applicability guidance. - Monitor-actuator pattern - Safety wrapper pattern - Voting architectures 5. 05 **Unit Design** Apply unit design principles per ISO 26262-6 including proper use of data types, range checking, pre/postcondition definition, invariant documentation, and design for structural testability. - Data type design - Pre/postconditions - Structural testability 6. 06 **Freedom from Interference** Master Freedom from Interference (FFI) requirements for mixed-criticality software. Covers temporal partitioning, spatial partitioning, information hiding, and communication integrity between components of different ASIL. - Temporal partitioning - Spatial partitioning - Information hiding 7. 07 **SW DFA & Safety Analysis** Apply software-level Dependent Failure Analysis (DFA) and safety analysis techniques including FMEA at software level, FTA for software failures, and common cause failure analysis for redundant software channels. - SW-level FMEA - SW FTA - Common cause analysis 8. 08 **AUTOSAR Architecture** Design safety-compliant software architectures using the AUTOSAR framework. Covers AUTOSAR layered architecture for safety, memory protection configuration, OS application design, and integration with the safety architecture. - AUTOSAR layers for safety - Memory protection config - OS application design 9. 09 **SW Safety Mechanisms** Implement software safety mechanisms including range checks, plausibility monitoring, program flow monitoring, CRC verification, end-to-end protection, and alive counters as per ISO 26262 method requirements. - Range & plausibility checks - Program flow monitoring - E2E protection 10. 10 **Coding Guidelines Integration** Integrate coding guidelines (MISRA C, AUTOSAR C++14) with architectural and unit design. Learn how design decisions upstream reduce guideline violations and how static analysis fits into the design verification workflow. - MISRA integration - Design-to-guideline mapping - Static analysis role 11. 11 **Mixed-Criticality Design** Design systems where software components of different ASILs coexist on the same hardware. Master ASIL decomposition at software level, partition isolation strategies, and the role of the OS in mixed-criticality enforcement. - SW ASIL decomposition - Partition isolation - OS role in criticality 12. 12 **ML/AI Integration** Address the architectural challenges of integrating machine learning components into safety-critical software. Covers safety wrapper patterns for ML, SOTIF boundary handling, monitoring strategies, and current ISO/PAS 21448 guidance. - ML safety wrappers - SOTIF boundary handling - Monitoring strategies 13. 13 **Verification & Review** Verify software architecture and unit design using design reviews, walk-throughs, architecture analysis methods (ATAM, SAAM), and model checking techniques. Learn independence requirements for ASIL-C and ASIL-D reviews. - Architecture reviews - ATAM/SAAM methods - Independence requirements 14. 14 **Best Practices** Industry best practices for efficient and compliant SW architectural design including design pattern libraries, architecture documentation templates, and lessons learned from common safety assessment findings. - Design pattern libraries - Documentation templates - Assessment lessons Interactive Diagrams ## Not just text: the visual toolkit ### Architecture Pattern Explorer Interactive library of safety architecture patterns with ASIL applicability, structural diagrams, pros/cons, and example use cases for each pattern. ### FFI Partitioning Visualizer Visual demonstration of temporal and spatial partitioning between mixed-criticality software components with configurable partition boundaries and violation detection. ### SW Safety Mechanism Selector Decision tool mapping failure modes to appropriate software safety mechanisms with diagnostic coverage estimates and implementation complexity ratings. ### AUTOSAR Safety Stack Interactive AUTOSAR architecture diagram highlighting safety-relevant layers, memory protection unit configuration, OS application boundaries, and inter-application communication. ### Mixed-Criticality Decomposition Visual tool for planning ASIL decomposition at software level showing valid channel combinations, independence requirements, and FFI obligations for each configuration. ### Unit Design Template Interactive unit design specification template with fields for pre/postconditions, data ranges, error handling strategy, and testability considerations linked to ASIL requirements. Worked Examples ## SW Architecture for ASIL-D Steering Angle Controller Complete architectural design walkthrough for a steering angle controller with FFI between diagnostic monitor (ASIL-D) and actuation control (ASIL-D), including AUTOSAR implementation. - SW safety requirements analysis and architectural decomposition strategy - Monitor-actuator pattern selection and FFI partitioning design - OS application configuration for spatial and temporal partitioning - SW safety mechanism selection for each identified failure mode - Architecture DFA and independence requirements verification - Unit design specification for the plausibility monitoring component Steering Controller Architecture Monitor-actuator pattern - ASIL-D partitioning with 3ms temporal budget Unlock 5 more design phases Built for ## Who this guide is for - Embedded software engineers on their first ASIL-rated project - Software architects putting QM and ASIL components on the same ECU - AUTOSAR integrators configuring memory protection and OS applications for safety - Developers who need their unit designs to survive an ISO 26262-6 verification review ## Frequently Asked Questions Common questions about SW Architecture & Unit Design 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. ## 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%2Fsoftware-architectural-unit-design&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)