Functional Safety with AUTOSAR
AUTOSAR is a toolbox of specified safety mechanisms, not a certificate. You learn how the Classic and Adaptive platforms answer ISO 26262-6 across the three interference channels, using MPU-backed partitions, OS timing budgets, the Watchdog Manager and end-to-end communication protection.
- Chapters
- 12
- Chapters
- Interference Channels
- 3
- Interference Channels
- E2E Profiles
- 9
- E2E Profiles
- Platforms
- 2
- Platforms
- 01Why AUTOSAR Meets ISO 26262
- 02The Classic Platform Through a Safety Lens
- 03Mixed-ASIL Integration Strategies
- 04Memory Protection & OS Partitioning
- 05Timing Protection & Execution Integrity
Why it pays for itself
Map mechanisms to interference channels
Point at any AUTOSAR safety mechanism - MPU partitions, OS timing budgets, Watchdog Manager, E2E protection - and name which fault, on which of the three interference channels, it detects or contains.
Choose a mixed-ASIL strategy
Compare the three practical patterns for QM and ASIL software on one ECU - full MPU barriers, defensive ASIL islands, or a qualified silent stack - and pick one you can defend.
Make the FTTI arithmetic close
The worked lane-keeping example splits a 100 ms fault tolerant time interval into detection, decision, ramp-off, and margin, tracing every slice to a configured parameter and a measurement.
What you’ll be able to do
Map mechanisms to the three channels
Point at any AUTOSAR safety mechanism and name which fault, on which interference channel, at which layer it detects or contains.
Choose a mixed-ASIL partitioning strategy
Decide between full MPU barriers, defensive ASIL islands and a qualified silent stack based on your ECU and supply chain.
Configure memory and timing protection
Set OS-Applications, scalability classes, protection reactions and execution, arrival and lock budgets against a real safety concept.
Deploy E2E and supervision correctly
Pick the right E2E profile, manage data IDs network-wide, and wire alive, deadline and logical supervision to the watchdog.
Make the fault handling time add up
Trace every FTTI slice to a configured parameter and a measurement on the real target under load.
Assemble an AUTOSAR safety case
Verify each vendor assumption of use, argue tool confidence for generators, and check the assembled ECU against its safety requirements.
Chapter by chapter
- 01
Why AUTOSAR Meets ISO 26262
What AUTOSAR actually is (cooperate on the standard, compete on the implementation), what the platform gives a safety project, and the three errors hidden in "we use a qualified stack, so it is safe".
- Two platforms: Classic for deeply embedded control, Adaptive for high-performance computers
- A specification is quality-managed, not ASIL; only a qualified implementation carries claims
- The five safety documents worth reading, from the OS SWS to the E2E Protocol Specification
- 02
The Classic Platform Through a Safety Lens
The layered architecture from application software down to MCAL, how faults travel the three roads of a shared processor, and the memory, timing and information channels that structure everything else.
- Seven layers from SWCs and the RTE down to hardware, each read for its safety view
- ISO 26262-6 Annex D interference channels mapped to AUTOSAR mechanism families
- Defense in depth: hardware, OS, WdgM, E2E and application plausibility catching different faults
- 03
Mixed-ASIL Integration Strategies
ASIL lift-up versus coexistence, and the three practical patterns for putting QM and ASIL software on one ECU: full MPU barriers, defensive ASIL islands, and a qualified silent stack.
- Barriers: MPU-enforced OS-Applications with every crossing controlled
- Defense: redundant inverted copies and diverse recalculation when there is no MPU
- Silence: a BSW stack qualified so it will not trash your memory, under documented assumptions
- 04
Memory Protection & OS Partitioning
OS-Applications as the unit of isolation, the scalability classes SC1 to SC4, and exactly what happens when a wild pointer writes where it should not, step by step to the ProtectionHook.
- SC3 as the workhorse for mixed-ASIL ECUs: MPU partitions plus service protection
- The MPU traps a foreign write before the byte changes and raises E_OS_PROTECTION_MEMORY
- Protection reactions from PRO_TERMINATETASKISR through restart to PRO_SHUTDOWN
- 05
Timing Protection & Execution Integrity
How the OS bounds temporal interference with execution budgets, arrival frames and lock budgets, and why bounding stolen time is still not a schedulability proof.
- Execution overrun, arrival flooding and lock hogging, each with its matching budget
- Fixed-priority preemptive scheduling and the three loopholes it leaves open
- Timing protection contains interference; it does not guarantee anyone meets their deadline
- 06
The Watchdog Manager
From "kick the dog" folklore to structured supervision: alive, deadline and logical checkpoint supervision, the local and global status machines, and escalation to a hardware reset.
- Alive supervision counts checkpoints per cycle; deadline measures wall-clock latency of a flow
- Logical supervision checks execution against a graph of allowed checkpoint transitions
- OK to FAILED to EXPIRED to STOPPED, where WdgM stops triggering and the MCU resets
- 07
End-to-End Communication Protection
The seven-fault communication model, the four protection ingredients of CRC, counter, data ID and timeout, the E2E profile family, and the receiver state machine that E2E cannot substitute for good data.
- Corruption, repetition, loss, delay, insertion, masquerade and wrong sequence, each mapped to an ingredient
- Profiles from P1 (CRC-8 on classic CAN) to P4 (CRC-32, 16-bit counter for CAN FD and Ethernet)
- Data IDs must be managed network-wide, or masquerade detection silently disappears
- 08
Complex Device Drivers & Integration Risk Areas
Why CDDs exist and why they scare assessors, plus the classic holes in a tidy partitioning story: DMA bus masters, interrupt configuration, NvM integrity and mode management.
- A CDD is sanctioned improvisation: it bypasses the qualified stack and usually runs privileged
- The CPU MPU checks CPU accesses only; a stray DMA descriptor lands straight in ASIL RAM
- Interrupt maps, NvM block CRCs and EcuM/BswM sequencing are reviewed safety work products
- 09
The Adaptive Platform
Why a second POSIX and C++ platform exists for high-performance computers, and how the safety mechanisms translate rather than disappear across its functional clusters.
- Processes in MMU address spaces replace MPU-backed OS-Applications
- Platform Health Management is the WdgM idea reborn; EM and SM drive recovery and degradation
- E2E rides ara::com so the black-channel argument survives the jump from signals to services
- 10
Classic vs Adaptive & Safety Case
The honest platform comparison and deployment patterns, then who provides which evidence in the supply chain and why generated configuration drags tool confidence into every project.
- Companion MCU, on-die safety island, hypervisor box and degradation-ladder deployment patterns
- Silicon vendor, BSW vendor, tool vendor and integrator each own a slice of the evidence chain
- Every assumption of use must be verified one by one, and generators need a tool confidence argument
Not just text: the visual toolkit
Classic Layered Architecture Map
Interactive stack from application software and the RTE down through the services layer, MCAL and hardware, each layer read for its safety view.
Fault Propagation Channels
Animated paths showing memory corruption, timing starvation and data corruption travelling the three roads of a shared processor.
MPU Memory Violation Sequence
Steps a wild write from normal operation through the MPU trap and ProtectionHook to a contained partition restart.
Watchdog Manager Status Machine
The global supervision states from OK through FAILED and EXPIRED to STOPPED, where the hardware watchdog resets the MCU.
FTTI Budget Bar
Slices the 100 ms fault tolerant time interval across detection, decision, actuator ramp-off and margin for a steering torque path.
Classic and Adaptive Degradation Ladder
Shows nominal function on the Adaptive HPC falling back to a Classic controller over E2E-protected heartbeats.
Lane Keeping Sends Steering Torque Across Two Platforms
A lane keeping function on the central Adaptive HPC computes a steering correction that travels the vehicle network to a Classic lockstep steering ECU driving the assist motor. Against an ASIL D safety goal of avoiding unintended self-steering, with a 100 ms FTTI, every threat on the path is assigned exactly one owning mechanism.
- Steering request corruption owned by E2E Profile 4: CRC-32, 16-bit counter, explicit data ID
- Stale or lost requests caught by the E2E counter plus receiver-side timeout supervision
- Hung lane keeping process handled by PHM supervision with EM restart and SM degradation
- Torque task death, lateness or skipped plausibility caught by WdgM and the external windowed watchdog
- QM diagnostic and comfort code contained behind the MPU in a non-trusted OS-Application
- FTTI budget split 30 ms detection, 10 ms decision, 20 ms ramp-off and 40 ms margin
Unlock the full threat-to-mechanism table, the traced timing arithmetic and the ten-pitfall catalogue
Who this guide is for
- Integrators putting QM and ASIL software on the same ECU
- BSW engineers configuring the OS, Watchdog Manager, or E2E protection
- Safety engineers verifying vendor safety manuals and assumptions of use
- Architects weighing Classic versus Adaptive for a high-performance computer
Frequently Asked Questions
Common questions about Functional Safety with AUTOSAR
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 77-guide library. No credit card required.