Title: Functional Safety with AUTOSAR | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/autosar-functional-safety Description: AUTOSAR gives the car industry a standard software platform, but a specification cannot be ASIL anything, and a qualified stack does not make your software safe. --- Concept guide · AUTOSAR + ISO 26262 · 12 chapters # 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. 12 Chapters 3 Interference Channels 9 E2E Profiles 2 Platforms Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fautosar-functional-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **Why AUTOSAR Meets ISO 26262** 2. 02 **The Classic Platform Through a Safety Lens** 3. 03 **Mixed-ASIL Integration Strategies** 4. 04 **Memory Protection & OS Partitioning** 5. 05 **Timing Protection & Execution Integrity** The short version ## Quick answers How does AUTOSAR support functional safety in ISO 26262? AUTOSAR is a toolbox of specified safety mechanisms, not a certificate. The Classic and Adaptive platforms provide standardized mechanisms that answer the three interference channels of ISO 26262-6: memory partitioning through MPU-backed OS-Applications, timing protection through execution budgets and arrival frames, program-flow supervision through the Watchdog Manager, and end-to-end communication protection through the E2E profiles. The AUTOSAR specifications themselves are quality-managed documents - only a qualified vendor implementation, integrated with its assumptions of use verified, can carry safety claims into a project. Understanding which mechanism owns which fault is the core skill of AUTOSAR safety engineering. Is AUTOSAR ASIL D certified? No - an AUTOSAR specification cannot be ASIL anything, because a specification is a document, not a product. The specifications are developed under quality management, and safety claims attach only to a specific vendor implementation that was developed or qualified according to ISO 26262. Even then, the vendor ships a safety manual full of assumptions of use, and every one of those assumptions must be verified in your integration before the claim holds. "We use a qualified stack, so it is safe" hides exactly this gap. 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 ## 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. After the course ## 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. The curriculum · 10 chapters ## Chapter by chapter 1. 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 2. 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 3. 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 4. 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 5. 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 6. 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 7. 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 8. 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 9. 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. 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 Diagrams & Visuals ## 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. Worked Example ## 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 Detection: 30 ms, three 10 ms communication cycles before the E2E state machine declares the channel invalid Unlock the full threat-to-mechanism table, the traced timing arithmetic and the ten-pitfall catalogue Built for ## 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 End-to-end (E2E) protection guards safety-relevant communication against a seven-fault model: corruption, repetition, loss, delay, insertion, masquerade, and wrong sequence. It combines four ingredients - a CRC, a sequence counter, a data ID, and receiver-side timeout supervision - packaged into profiles ranging from Profile 1 (CRC-8 on classic CAN) to Profile 4 (CRC-32 with a 16-bit counter for CAN FD and Ethernet). One operational trap matters most: data IDs must be managed network-wide, or masquerade detection silently disappears. Classic targets deeply embedded control ECUs: a statically configured OS with MPU-backed OS-Applications, scalability classes SC1 to SC4, and the Watchdog Manager for supervision. Adaptive targets high-performance computers: a POSIX-based, C++ platform where processes in MMU address spaces replace MPU partitions, Platform Health Management takes over the Watchdog Manager role, and Execution and State Management drive recovery and degradation. The mechanisms translate rather than disappear - E2E rides ara::com, so the black-channel argument survives the jump from signals to services. The guide runs 12 chapters covering both platforms, the 3 interference channels, and the E2E profile family with its 9 profiles. It closes with a worked example where a lane-keeping function on an Adaptive HPC sends steering torque to a Classic lockstep ECU, with every threat on the path assigned one owning mechanism against a 100 ms FTTI. 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%2Fautosar-functional-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)