Functional Safety with AUTOSAR
10 chapters 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.
How You Learn
Video and text stay in sync. As you scroll through the chapter, the video jumps to the matching explanation automatically.
Learning Objectives
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.
Chapters
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
Diagrams & Visuals
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
Fault Handling Budget vs 100 ms FTTI
Master Functional Safety with AUTOSAR
Work through every safety mechanism, the Classic and Adaptive platforms, and a fully assembled steering torque path with its timing budget.
Start Learning Now