ISO 26262 and AUTOSAR: How They Work Together for Functional Safety

Hello, automotive embedded software engineers, AUTOSAR integrators, and functional safety professionals! AUTOSAR and ISO 26262 are two of the most important frameworks in modern automotive ECU development – and understanding how they work together is essential for anyone building safety-relevant automotive software. AUTOSAR provides the standardized software architecture and infrastructure. ISO 26262 provides the safety requirements and development methods. Together, they enable efficient development of functionally safe automotive ECUs.

In this comprehensive guide at PiEmbSysTech, we will explain the relationship between these two frameworks, how AUTOSAR’s safety mechanisms map to ISO 26262 requirements, how AUTOSAR enables freedom from interference, and how AUTOSAR components are typically developed as SEooC for reuse across safety projects. Let us begin.

1. The Relationship – Different Standards, Shared Goal

AUTOSAR (AUTomotive Open System ARchitecture) is an industry consortium standard that defines a standardized software architecture, methodology, and set of basic software modules for automotive ECUs. ISO 26262 is an international safety standard that defines the requirements for developing functionally safe E/E systems. They are different types of standards with different scopes – AUTOSAR is a software architecture standard, while ISO 26262 is a safety process and requirements standard.

Critically: AUTOSAR compliance does not automatically guarantee ISO 26262 compliance, and vice versa. An ECU can be fully AUTOSAR-compliant but not functionally safe if the safety requirements are not properly implemented. Conversely, a functionally safe ECU can be developed without AUTOSAR. However, AUTOSAR provides a standardized framework with built-in safety features that significantly facilitate ISO 26262 compliance – particularly for Part 6 (software development) requirements. This is why the two frameworks are almost always used together in modern automotive ECU projects.

2. AUTOSAR Recap – Classic and Adaptive Platforms

The AUTOSAR Classic Platform (CP) is designed for deeply embedded, hard real-time ECUs with static software configurations – such as EPS, ABS/ESC, engine management, and body control modules. It features a layered architecture: MCAL (Microcontroller Abstraction Layer) → ECU Abstraction → Services → RTE (Runtime Environment) → Application SWCs (Software Components). The Classic Platform is the primary AUTOSAR platform for safety-critical applications up to ASIL D.

The AUTOSAR Adaptive Platform (AP) is designed for high-performance computing ECUs with dynamic software configurations – such as ADAS domain controllers, autonomous driving platforms, and connected vehicle gateways. It is based on POSIX-compliant operating systems and supports C++14/17, service-oriented communication (SOME/IP), and dynamic software updates. The Adaptive Platform is increasingly relevant for safety applications in ADAS and autonomous driving, though its safety mechanisms are less mature than the Classic Platform’s.

3. ISO 26262 Software Safety Requirements That AUTOSAR Addresses

ISO 26262 Part 6 defines several categories of software safety requirements that AUTOSAR’s architecture and BSW modules directly address:

Freedom from interference (FFI): ISO 26262 Part 6 Clause 7 requires that software components of different ASILs (or ASIL and QM) do not interfere with each other – ensuring that a QM component cannot corrupt safety-relevant data, consume safety-relevant CPU time, or disrupt safety-relevant control flow. AUTOSAR provides memory partitioning (OS-Applications with MPU protection) and timing protection to achieve FFI.

Communication protection: ISO 26262 requires that safety-relevant data transmitted between software components (or between ECUs) is protected against corruption, loss, delay, and repetition. AUTOSAR provides the E2E (End-to-End) Protection Library for this purpose.

Program flow monitoring: ISO 26262 requires that the execution of safety-relevant software is monitored to detect deviations from the expected execution sequence and timing. AUTOSAR provides the Watchdog Manager (WdgM) module for alive supervision, deadline supervision, and logical supervision.

Safe state management: ISO 26262 requires that the system can transition to a defined safe state upon detection of a safety-relevant fault. AUTOSAR provides error handling through the Diagnostic Event Manager (DEM), Basic Software Mode Manager (BswM), and ECU State Manager (EcuM) modules.

4. The AUTOSAR Layered Architecture and ISO 26262 Part 6

AUTOSAR’s layered architecture naturally aligns with ISO 26262 Part 6’s software architecture requirements. The clear separation between MCAL (hardware-dependent), BSW (services layer), RTE (communication layer), and Application SWCs (application logic) provides the hierarchical structure, loose coupling, and restricted interfaces that Part 6 Table 1 requires as architectural design principles. Each layer has well-defined interfaces, and the AUTOSAR methodology enforces that application software communicates only through the RTE – never directly accessing hardware registers or BSW internal data. This architectural discipline directly supports FFI and facilitates safety analysis at the software architectural level.

5. Freedom from Interference (FFI) Through AUTOSAR

Freedom from Interference is one of the most critical ISO 26262 requirements for mixed-criticality ECUs – those running both safety-relevant (ASIL) and non-safety-relevant (QM) software on the same hardware. ISO 26262 Part 6, Annex D defines the interference categories that must be addressed: corruption of safety-relevant data (spatial interference), blocking or delaying safety-relevant execution (temporal interference), and corruption of safety-relevant control flow (logical interference).

AUTOSAR addresses all three interference categories through its OS-Application concept (spatial protection via MPU), execution budget monitoring (temporal protection via OS timing facilities), and RTE-controlled inter-component communication (logical protection through controlled data flow). These mechanisms, when correctly configured, provide a strong FFI argument that satisfies ISO 26262 requirements for ASIL decomposition between software components sharing the same MCU.

6. Memory Protection – OS-Applications and MPU Configuration

AUTOSAR’s OS-Application concept groups software components into protection domains, each with its own memory access permissions enforced by the MCU’s Memory Protection Unit (MPU). Safety-relevant SWCs are assigned to “trusted” OS-Applications with access to their own memory regions and (where needed) privileged hardware access. QM SWCs are assigned to “non-trusted” OS-Applications that run in user mode with restricted memory access – if a QM component attempts to access memory outside its permitted region, the MPU generates a hardware exception, and the AUTOSAR OS invokes a Protection Hook that can shut down or restart the offending partition without affecting safety-relevant software.

This mechanism provides the spatial FFI evidence that ISO 26262 requires: a QM software error cannot corrupt ASIL data because the hardware (MPU) physically prevents the access. The AUTOSAR OS configuration (through tools like DaVinci Configurator or EB tresos) defines the partition boundaries, memory regions, and access permissions.

7. Timing Protection – Execution Budgets and Deadlines

AUTOSAR OS provides timing protection mechanisms that prevent QM tasks from consuming excessive CPU time and blocking safety-relevant tasks: execution budget monitoring (each task has a maximum execution time – if exceeded, the OS terminates the task), time limit for blocking resources (preventing priority inversion that could delay safety tasks), and inter-arrival time monitoring (detecting tasks that are activated too frequently). These mechanisms provide the temporal FFI evidence that ISO 26262 requires – ensuring that safety-relevant tasks always execute within their FTTI-derived timing constraints, regardless of QM software behavior.

8. End-to-End (E2E) Communication Protection

AUTOSAR’s E2E Protection Library implements communication protection profiles that detect data corruption, message loss, message repetition, message delay, and message sequence errors in safety-relevant data exchanged between software components (intra-ECU via RTE) or between ECUs (inter-ECU via CAN, CAN FD, Ethernet). Each E2E Profile uses a combination of CRC (data integrity), alive counter (message sequence and loss detection), and timeout monitoring (message delay detection).

The standard defines several E2E Profiles (Profile 1, Profile 2, Profile 4, Profile 5, Profile 6, Profile 7, Profile 11) – each with different CRC polynomials, counter sizes, and header structures optimized for different communication protocols. For ISO 26262, the E2E protection provides the diagnostic coverage for communication faults that the TSC safety mechanisms require. The E2E Library is typically developed as SEooC by the AUTOSAR BSW supplier and qualified for ASIL D usage.

9. Watchdog Manager (WdgM) – Program Flow Monitoring

The AUTOSAR Watchdog Manager (WdgM) provides comprehensive program flow monitoring for safety-relevant software entities. It implements three supervision mechanisms:

Alive supervision: Verifies that a supervised entity (runnable or task) executes cyclically at the expected rate – neither too fast nor too slow. The supervised entity calls a WdgM checkpoint function at defined points. If the checkpoint is not reached within the expected time window, a supervision failure is reported.

Deadline supervision: Verifies that a supervised entity completes its execution within a maximum time limit. The entity reports entry and exit checkpoints, and the WdgM verifies that the elapsed time between them does not exceed the configured deadline.

Logical supervision: Verifies that the execution follows the expected sequence of checkpoints – detecting control flow errors such as skipped steps, incorrect branching, or infinite loops. Checkpoints and transitions form a directed graph (internal graph within a supervised entity, external graph across supervised entities), and any deviation from the expected graph is reported as a supervision failure.

The WdgM links these software supervision mechanisms to the hardware watchdog – if a supervision failure triggers a safety-relevant response, the WdgM can stop servicing the hardware watchdog, causing a hardware reset that forces the system into its safe state. This provides the program flow monitoring evidence that ISO 26262 Part 6 Annex D requires.

10. Safe State Management Through AUTOSAR

AUTOSAR provides several BSW modules that together implement the safe state transition logic required by ISO 26262: the Diagnostic Event Manager (DEM) stores and manages diagnostic events (DTCs) including safety-relevant fault status, the Function Inhibition Manager (FiM) inhibits specific functions based on the status of monitored events, the Basic Software Mode Manager (BswM) implements state machine logic to coordinate mode transitions (including safe state transitions) based on input conditions from DEM, FiM, and other modules, and the ECU State Manager (EcuM) manages ECU startup and shutdown sequences – including the controlled shutdown path to the safe state. Together, these modules provide the systematic framework for implementing the fault detection → fault handling → safe state transition logic that the FSC and TSC define.

11. Safety-Relevant BSW Modules

The following AUTOSAR BSW modules are most directly relevant to ISO 26262 safety implementation: the OS (scheduling, memory protection, timing protection), the RTE (inter-component communication with protection), the E2E Library (communication integrity verification), the WdgM (program flow monitoring), the DEM (diagnostic event management), the FiM (function inhibition based on faults), the BswM (mode management and safe state coordination), the EcuM (ECU startup/shutdown management), and the NvM (Non-Volatile Memory Manager – for safe storage and retrieval of safety-relevant calibration data and fault memory). Each of these modules has an AUTOSAR specification with defined functional safety requirements and is typically developed as SEooC by BSW suppliers for ASIL D usage.

12. MCAL and Hardware Abstraction for Safety

The AUTOSAR MCAL (Microcontroller Abstraction Layer) provides the interface between the BSW and the specific MCU hardware. For safety applications, the MCAL is critical because it directly controls safety-relevant hardware peripherals – ADCs reading sensor data, PWM outputs driving actuators, SPI interfaces communicating with sensor ASICs, and timer modules implementing timing supervision. The MCAL must be developed to the ASIL of the safety function it supports and is typically provided by the MCU vendor or a specialist BSW supplier as SEooC. The MCAL’s safety manual documents the assumptions of use – including which MCU safety features (MPU, ECC, clock monitoring) must be enabled and configured by the integrator.

13. RTE Safety Features

The AUTOSAR RTE (Runtime Environment) acts as the communication middleware between application SWCs and between SWCs and BSW modules. For safety, the RTE provides partition-aware data access (ensuring SWCs in different OS-Applications access data through controlled interfaces, not through direct memory access), data transformation support (integrating E2E protection transparently into the communication path), and consistent data access (ensuring that composite data structures are read/written atomically, preventing partial data corruption). Safety-qualified RTE implementations (such as EB tresos Safety RTE or Vector MICROSAR Safe RTE) are developed to ASIL D and provide the safe communication infrastructure for mixed-ASIL ECU architectures.

14. Mixed-ASIL Partitioning – QM and ASIL Software on One ECU

One of the most powerful synergies between AUTOSAR and ISO 26262 is the ability to run QM and ASIL software on the same ECU – a mixed-criticality architecture. AUTOSAR’s OS-Application partitioning, combined with MPU-based memory protection and timing protection, provides the FFI evidence needed for ISO 26262 to accept that a QM software fault cannot compromise ASIL software behavior. This enables significant cost savings by consolidating functions that would otherwise require separate ECUs — for example, running ASIL D steering control and QM comfort features (heated steering, ambient lighting) on a single MCU, as long as the partitioning is correctly configured and the FFI argument is supported by the AUTOSAR OS safety features.

15. AUTOSAR Components as SEooC

Most AUTOSAR BSW modules (OS, RTE, E2E, WdgM, DEM, MCAL drivers) are developed by specialized BSW suppliers (Vector Informatik, Elektrobit, ETAS, KPIT) as SEooC (Safety Elements out of Context). The supplier develops the module to a target ASIL (typically ASIL D) based on assumptions about the MCU platform, the AUTOSAR version, and the integration context. The safety manual documents the assumptions of use, the ASIL capability, the configuration requirements, and the integrator’s responsibilities. The ECU project integrator uses the SEooC BSW modules by validating the assumptions against the actual project context, configuring the modules correctly (using tools like DaVinci Configurator or EB tresos), and performing integration testing to verify that the configured BSW behaves correctly in the actual ECU environment.

16. Classic vs Adaptive Platform – Safety Considerations

AUTOSAR Classic Platform (CP): Well-established safety ecosystem. Static architecture, deterministic scheduling, hardware MPU-based protection. Safety-qualified OS, RTE, E2E, and WdgM available from multiple vendors up to ASIL D. The primary platform for ASIL C/D safety-critical ECUs (EPS, ABS, airbag, engine management).

AUTOSAR Adaptive Platform (AP): Evolving safety ecosystem. Dynamic architecture, POSIX-based OS, C++14/17 programming, service-oriented communication. Safety mechanisms are less mature – AP relies on process-level isolation (rather than MPU partitioning), inter-process communication with protection, and health monitoring services. Adaptive Platform is increasingly used for ADAS domain controllers and autonomous driving systems – typically at ASIL B or lower, with safety-critical functions often delegated to a companion Classic Platform ECU or a dedicated safety MCU (e.g., Infineon AURIX as safety companion to an AP SoC).

17. AUTOSAR Configuration Tools and ISO 26262 Tool Qualification

AUTOSAR configuration tools (Vector DaVinci Configurator, Elektrobit EB tresos Studio, ETAS ISOLAR) generate the BSW configuration code – including OS task scheduling, MPU configuration, E2E profile parameters, and WdgM supervision graphs. These tools are classified as TI2 (can introduce errors) under the ISO 26262 tool qualification framework because their output (generated configuration code) directly influences the safety behavior of the ECU software. The tool’s TCL depends on whether the generated configuration is independently verified – if integration testing fully verifies the configured behavior, TD1 and TCL1 may be achievable. If the tool’s output is relied upon without complete independent verification, TCL2 or TCL3 qualification may be needed. Leading AUTOSAR tool vendors provide TÜV-certified tools and tool qualification kits for this purpose.

18. ISO 26262 Part 6 Requirements Mapped to AUTOSAR Features

ISO 26262 Part 6 Requirement	AUTOSAR Feature
Hierarchical software architecture (Table 1)	AUTOSAR layered architecture (MCAL/BSW/RTE/SWC)
Restricted size of interfaces (Table 1)	AUTOSAR port-based SWC communication through RTE
Freedom from interference – spatial (Annex D)	OS-Application partitioning + MPU configuration
Freedom from interference – temporal (Annex D)	OS timing protection (execution budgets, blocking time limits)
Freedom from interference – logical (Annex D)	RTE-controlled communication + WdgM logical supervision
Communication protection (Annex D)	E2E Protection Library (CRC + alive counter + timeout)
Program flow monitoring (Annex D)	WdgM (alive, deadline, logical supervision)
Safe state transition	DEM + FiM + BswM + EcuM coordination
Coding guidelines (MISRA)	AUTOSAR BSW developed to MISRA C/C++ (by SEooC supplier)
Software component qualification (Part 8)	AUTOSAR BSW modules as SEooC with safety manuals

19. Common Mistakes and How to Avoid Them

Mistake 1: Assuming AUTOSAR compliance = ISO 26262 compliance. AUTOSAR compliance ensures the software architecture follows the AUTOSAR standard. ISO 26262 compliance ensures the software meets the safety requirements derived from the vehicle-level HARA. Both are needed, but they are independent assessments.

Mistake 2: Not configuring the MPU correctly for safety partitioning. AUTOSAR’s OS-Application concept only provides FFI if the MPU is correctly configured to enforce the partition boundaries. An incorrectly configured MPU provides no protection, regardless of the AUTOSAR OS configuration.

Mistake 3: Using E2E protection without verifying the E2E Library’s SEooC assumptions. The E2E Library is developed as SEooC with specific assumptions about the communication stack, timing, and data types. The integrator must validate these assumptions for their specific project.

Mistake 4: Not qualifying the AUTOSAR configuration tool. Configuration tools (DaVinci Configurator, EB tresos) generate safety-relevant code. If the tool’s TCL requires qualification, the project must perform it – even if the tool vendor provides a TÜV certificate (which supports but does not replace project-specific qualification).

Mistake 5: Neglecting AUTOSAR BSW integration testing. The individual BSW modules may be SEooC-qualified, but the integrated BSW stack (OS + RTE + E2E + WdgM + DEM + MCAL on the specific MCU with the specific configuration) must be integration-tested to verify that the safety mechanisms work correctly in the actual system context.

Mistake 6: Using AUTOSAR Adaptive Platform for ASIL D without a companion safety MCU. The Adaptive Platform’s safety mechanisms are evolving but not yet as mature as the Classic Platform’s for ASIL D applications. Many current ADAS architectures pair an AP-based SoC with a CP-based safety MCU for ASIL D functions.

20. Frequently Asked Questions

Q1: Is AUTOSAR required for ISO 26262 compliance?

No. ISO 26262 does not mandate any specific software architecture framework. However, AUTOSAR’s standardized architecture, pre-qualified BSW modules, and built-in safety features make it significantly easier to achieve ISO 26262 compliance compared to developing a proprietary software platform from scratch. The vast majority of new automotive ECU projects targeting ISO 26262 compliance use AUTOSAR.

Q2: Can I achieve ASIL D with AUTOSAR Classic Platform?

Yes. AUTOSAR Classic Platform BSW modules (OS, RTE, E2E, WdgM) are available from multiple vendors (Vector, Elektrobit, ETAS) qualified up to ASIL D. The Classic Platform is the standard choice for ASIL D safety-critical applications such as EPS, ABS/ESC, and airbag systems.

Q3: How do AUTOSAR C++14 coding guidelines relate to ISO 26262?

The AUTOSAR C++14 coding guidelines (used primarily with the Adaptive Platform) serve a similar purpose to MISRA C++ — they restrict the use of C++ language features that could lead to undefined behavior or safety issues. ISO 26262 Part 6 requires the use of coding guidelines, and both MISRA C++ and AUTOSAR C++14 satisfy this requirement.

Q4: Does AUTOSAR handle all ISO 26262 software requirements?

No. AUTOSAR provides the infrastructure for many safety mechanisms, but it does not provide the application-level safety logic. The application software components (SWCs) that implement the actual safety functions (torque calculation, brake control, airbag deployment logic) must be developed by the ECU project team following ISO 26262 Part 6 requirements. AUTOSAR provides the platform; the project builds the safety application on top of it.

Q5: How does DaVinci Configurator relate to ISO 26262 tool qualification?

Vector’s DaVinci Configurator is an AUTOSAR configuration tool that generates BSW configuration code. Under the ISO 26262 tool qualification framework, it is classified as TI2 (can introduce errors through incorrect configuration). The TCL depends on the project’s verification workflow. Vector provides TÜV-certified qualification support, but the project must still perform its own tool classification and ensure the qualification covers their specific use cases.

21. Conclusion

AUTOSAR and ISO 26262 are complementary frameworks that together provide the foundation for modern automotive safety-critical software development. AUTOSAR provides the standardized architecture, the pre-qualified BSW modules, and the safety mechanisms (memory protection, timing protection, E2E communication, watchdog management) that implement the safety concepts defined by ISO 26262. ISO 26262 provides the safety requirements, the development methods, and the verification framework that ensure the AUTOSAR-based software achieves the required safety integrity level. Neither framework alone is sufficient – together, they enable the efficient development of functionally safe automotive ECUs.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For related topics, visit our AUTOSAR Architecture and Adaptive AUTOSAR guides.

Stay safe. Stay AUTOSAR-enabled. Keep engineering the future.

— The PiEmbSysTech Team