AUTOSAR & ISO 26262 - Building Safety-Compliant ECU Software

Dhandapani R
12. May 2026
Categories:Technology

AUTOSAR Classic was designed with ISO 26262 firmly in mind, and the two standards reinforce each other in important ways. However, AUTOSAR does not make a system automatically safe. It provides the architectural scaffolding upon which a robust safety case can be built, significantly reducing the cost and complexity of ISO 26262 compliance. This article examines how AUTOSAR supports each ASIL level, the mechanisms it provides for freedom from interference, and the compliance criteria that engineering teams must address.

Understanding ASIL Classifications

ISO 26262 defines four Automotive Safety Integrity Levels, ASIL A through ASIL D, with ASIL D representing the most stringent requirements. The ASIL assigned to a safety goal determines the rigour of development processes, verification methods, and architectural constraints required. QM (Quality Management) applies to non-safety-relevant functions.

ASIL Level Severity Development Rigour Verification Methods Example Application
QM No safety impact Standard quality processes Standard testing Infotainment, seat heating
ASIL A Low Basic safety processes Review, analysis Rear parking lights
ASIL B Medium Semi-formal methods Walkthrough, unit test Wiper control, headlamps
ASIL C High Semi-formal to formal Inspection, integration test Airbag deployment timing
ASIL D Highest Formal methods required Formal verification, MC/DC Braking, steering assist

How AUTOSAR Supports ISO 26262 Compliance

Qualified BSW Deliverables

BSW modules from commercial AUTOSAR stack vendors are typically pre-qualified to ASIL B or ASIL D. They ship with a Safety Manual, FMEA, and qualification evidence package. This dramatically reduces the safety analysis effort a development team must invest in infrastructure software. Rather than auditing every line of a CAN driver’s source code, the team relies on the vendor’s qualified deliverable and focuses their safety effort on application SWCs and system integration.

Memory and Timing Partitioning

The AUTOSAR OS partitioning mechanism enforces memory protection and timing isolation between different ASIL-rated software partitions running on the same ECU. An ASIL D safety function and a QM comfort function can coexist on the same microcontroller, with the OS guaranteeing that the QM code cannot corrupt the memory or deadline behaviour of the ASIL D partition. This directly satisfies ISO 26262’s requirement for freedom from interference.

ASIL Decomposition Support

When a safety goal is decomposed across two independent software channels (for example, ASIL D decomposed to ASIL B + ASIL B), AUTOSAR’s SWC architecture and OS partitioning provide the structural separation needed to demonstrate that the channels are sufficiently independent. The RTE port model makes it straightforward to verify that no shared data paths exist between the two channels.

ASIL Compliance Criteria and Coverage

The following table summarises the key compliance criteria across ASIL levels, detailing the methods and coverage requirements that must be satisfied when developing AUTOSAR-based safety-critical software.

Compliance Criteria QM ASIL A ASIL B ASIL C ASIL D
Requirements Traceability Recommended Required Required Required Required
Design Verification Review Review Walkthrough Inspection Formal Inspection
Code Review Method Optional Review Walkthrough Inspection Formal Inspection
Unit Test Coverage Statement Statement Branch Branch MC/DC
Integration Testing Recommended Required Required Required Required
Safety Analysis (FMEA/FTA) Not required Recommended Required Required Required
Freedom from Interference Not required Required Required Required Required
Configuration Management Basic Required Required Required Required
MISRA C Compliance Recommended Required Required Required Required
Safety Manual Required No Yes Yes Yes Yes

ASIL Decomposition Reference

ISO 26262 permits ASIL decomposition, where a higher ASIL requirement is split across two independent elements with lower individual ASIL ratings. AUTOSAR’s OS partitioning and SWC port isolation make it practical to implement these decomposed architectures. The following table shows the permitted decomposition combinations.

Original ASIL Decomposition 1 Decomposition 2 Independence Required
ASIL D ASIL D(D) + ASIL D(D) N/A (no decomposition) N/A
ASIL D ASIL C(D) + ASIL A(D) ASIL B(D) + ASIL B(D) Yes - both channels
ASIL C ASIL B(C) + ASIL A(C) ASIL A(C) + ASIL B(C) Yes - both channels
ASIL B ASIL A(B) + ASIL A(B) ASIL B(B) + QM(B) Yes - both channels
ASIL A ASIL A(A) + QM(A) N/A Yes - both channels

Incorporating Safety Using AUTOSAR - Practical Approach

To build an ISO 26262-compliant system on AUTOSAR, engineering teams should follow a structured approach that leverages the framework’s built-in safety mechanisms:

Define safety goals and ASIL ratings during system design. Map each safety function to specific SWCs and assign ASIL levels before any AUTOSAR configuration begins.

Use OS partitioning to enforce memory protection boundaries between software of different ASIL levels. Configure separate OS Applications for safety-critical and non-safety partitions with distinct memory regions and timing budgets.

Leverage vendor-qualified BSW modules for the target ASIL level. Verify that the vendor’s Safety Manual covers your use case and configuration. Document any deviations and apply compensating measures.

Design SWC port interfaces to enforce data isolation between decomposed safety channels. Use the RTE’s port model to ensure no unintended shared data paths exist between independent ASIL-rated components.

Implement watchdog supervision using AUTOSAR’s WdgM module to monitor the alive status and deadline behaviour of safety-critical SWCs at runtime.

Maintain full traceability from safety requirements through ARXML configuration, SWC design, to test evidence. The ARXML-driven workflow inherently supports traceability if disciplined naming and documentation practices are followed.

Common Misconceptions About AUTOSAR and Safety

“AUTOSAR guarantees safety.”AUTOSAR provides the framework and qualified infrastructure to support compliance. The safety of application SWC logic still depends entirely on how that logic is designed, reviewed, and tested. No toolchain substitutes for engineering rigour.

“Using a vendor-qualified BSW eliminates safety work.”Qualification evidence covers the BSW module itself. The integration, configuration, and application-level safety analysis remain the development team’s responsibility.

“ASIL D means everything must be ASIL D.”ASIL decomposition allows distributing the safety burden across independent elements with lower ASIL ratings, provided sufficient independence is demonstrated, which AUTOSAR’s partitioning mechanisms are specifically designed to support.

Conclusion

AUTOSAR does not make a system safe by itself, but it provides the right architectural scaffolding, OS partitioning, vendor-qualified BSW, SWC isolation through the RTE, and watchdog supervision, to build a robust safety case upon. By understanding the ASIL classification criteria, leveraging decomposition where appropriate, and following disciplined development practices, engineering teams can achieve ISO 26262 compliance more efficiently and with greater confidence. Cross-domain expertise enabling AUTOSAR-based safety-critical ECU development across automotive systems.

About Embien

Embien’s teams are proficient in both Classic and Adaptive AUTOSAR development,from MCAL integration and BSW configuration to application SWC development, RTE management, and ARXML-based system design. We have delivered AUTOSAR-based ECU software across powertrain, chassis, body, and telematics domains. If you are starting an AUTOSAR program and need experienced hands from day one, reach out to the Embien team to discuss your requirements.

Related Pages

PRODUCT ENGINEERING SERVICES

Embien’s Product Engineering Services support AUTOSAR-based system design, integration, and efficient ECU flashing.

Read More

PRODUCT REGULATORY COMPLIANCE SERVICES

Product Regulatory Compliance Services supporting ISO 26262-compliant AUTOSAR development with safety analysis, traceability, and validation workflows.

Read More

UDS CLIENT FOR ANDROID CLUSTER-REMOTE DIAGNOSTICS & FOTA UPDATE

Case study: UDS Client for Android Cluster enables remote diagnostics and FOTA updates, improving ECU communication and system reliability.

Read More

Subscribe to our Blog