Freedom from Interference ISO 26262: Spatial, Temporal & Logical Interference Explained

Hello, automotive embedded software engineers, system architects, and safety professionals! Freedom from Interference (FFI) is one of the most practically important concepts in ISO 26262 – and one that every engineer working on mixed-criticality ECUs must thoroughly understand. In today’s automotive industry, cost optimization demands that safety-relevant ASIL software and non-safety QM software coexist on the same microcontroller. FFI is the property that makes this mixed-ASIL coexistence possible while maintaining the safety integrity of the ASIL-rated functions.

In this comprehensive guide at PiEmbSysTech, we will explain the FFI concept, the three interference categories (spatial, temporal, logical/communication), the implementation mechanisms for each, and how FFI is achieved in practice using AUTOSAR and MCU hardware features. Let us begin.

1. What is Freedom from Interference (FFI)?

Freedom from Interference is defined in ISO 26262-1 as: “absence of cascading failures between two or more elements that could lead to the violation of a safety requirement or a safety goal.” In practical terms, FFI means that a fault in one software element (typically a QM or lower-ASIL element) cannot propagate to another software element (typically a higher-ASIL element) and cause it to fail in a way that violates a safety goal.

FFI is a directional property: we say “Element B is free from interference from Element A” – meaning that faults in A cannot cause B to fail. The reverse may not be true. FFI specifically addresses cascading failures – where a fault in one element propagates to another through a shared resource or interface. It does not address common cause failures (which are covered by the broader concept of independence).

2. Why FFI is Needed – The Mixed-ASIL ECU Challenge

Modern automotive ECUs frequently run software of different ASIL classifications on the same MCU: an EPS ECU might run ASIL D torque control alongside QM comfort functions (steering wheel heater, ambient lighting interface). Without FFI, all software on the ECU would need to be developed to the highest ASIL present – meaning the entire QM comfort software would need ASIL D development methods, dramatically increasing development cost. FFI provides the evidence that the QM software cannot interfere with the ASIL D software, allowing each software component to be developed to its own ASIL (or QM) while maintaining the safety integrity of the highest-ASIL functions.

FFI is also essential for ASIL decomposition. When a safety function is decomposed from ASIL D to ASIL B(D) + ASIL B(D), FFI must be demonstrated between the decomposed elements to prevent cascading failures from one decomposed element to the other.

3. FFI in ISO 26262 – Part 6, Annex D

FFI requirements for software appear primarily in ISO 26262 Part 6, Clause 7.4.10 and Annex D. Clause 7.4.10 states: “If the embedded software has to implement software components of different ASILs, or safety-related and non-safety-related software components, then all of the embedded software shall be treated in accordance with the highest ASIL, unless freedom from interference between the software components is demonstrated.” This is the fundamental rule – either develop everything to the highest ASIL, or demonstrate FFI. Annex D provides the detailed guidance on the three interference categories and the safety mechanisms to address them.

4. The Three Interference Categories

ISO 26262 Part 6, Annex D identifies three categories of interference that must be addressed:

Category	What It Means	Shared Resource
Spatial (Memory)	A fault in element A corrupts the data or code of element B through shared memory	RAM, Flash, registers, stack, heap, peripheral registers
Temporal (Timing)	A fault in element A prevents element B from executing within its required time	CPU cores, bus bandwidth, interrupt controller, DMA channels
Communication (Logical)	Incorrect data from element A is accepted by element B, leading to wrong behavior	RTE ports, function calls, shared buffers, CAN/SPI interfaces

5. Spatial (Memory) Interference – Concept and Examples

Spatial interference occurs when a fault in one software element corrupts the memory (data or code) used by another software element. This is the most fundamental and dangerous type of interference because a single wild pointer or array overflow in a QM task can silently corrupt the data of an ASIL D safety function – potentially causing incorrect actuator commands without any immediate error detection.

Examples: A QM task writes beyond its allocated array boundary, overwriting the ASIL D task’s torque command variable. A stack overflow in a QM function corrupts the stack frame of a calling ASIL function. A DMA transfer initiated by QM software writes to a memory region used by ASIL software. A QM interrupt handler modifies a hardware peripheral register that is also used by the ASIL safety mechanism. A wild pointer in QM code writes to arbitrary memory locations, potentially corrupting any data in the system.

6. Spatial FFI Mechanisms – MPU, Partitioning, Static Analysis

Hardware MPU (Memory Protection Unit): The primary mechanism for spatial FFI. The MPU is configured by the AUTOSAR OS to enforce partition boundaries – each OS-Application has defined memory regions (code, data, stack, peripheral access), and any access outside the permitted regions triggers a hardware exception. This is the strongest spatial FFI mechanism because it is enforced by hardware at every memory access, regardless of software errors.

AUTOSAR OS-Application partitioning: AUTOSAR’s OS-Application concept groups SWCs into trusted (ASIL) and non-trusted (QM) partitions. Non-trusted partitions run in user mode with MPU-enforced memory restrictions. Trusted partitions run in supervisor mode with full access – but only ASIL-qualified code should run in trusted mode.

Static analysis for memory interference: Tools like TASKING Safety Checker and Axivion Architecture Verification perform static analysis to identify potential memory access violations at compile time – before the software runs. This provides early detection of spatial interference risks that complement the runtime MPU protection.

Software-based memory protection: For MCUs without hardware MPU (older 16-bit microcontrollers), software-based approaches include mirrored copies with integrity checks (store data and its bitwise complement, verify before use), CRC protection on critical data areas, and stack canary values to detect stack overflows. These software approaches are weaker than hardware MPU but can provide partial spatial FFI evidence for lower ASILs.

7. Temporal (Timing) Interference – Concept and Examples

Temporal interference occurs when a fault in one software element prevents another software element from executing within its required time constraints – specifically, within the FTTI (Fault Tolerant Time Interval). If a safety function must execute every 10ms to maintain safe operation, any interference that delays its execution beyond 10ms constitutes a temporal FFI violation.

Examples: A QM task enters an infinite loop, consuming all CPU time and preventing the ASIL task from being scheduled. A QM task disables interrupts for an extended period, delaying the ASIL task’s interrupt-driven execution. A QM task holds a shared OS resource (mutex/semaphore) indefinitely, causing priority inversion that blocks the ASIL task. A DMA transfer initiated by QM software monopolizes the bus bandwidth, preventing ASIL software from accessing critical data. A QM task triggers excessive interrupt load, consuming CPU time that should be available for ASIL tasks.

8. Temporal FFI Mechanisms – OS Protection, Watchdog, Budgets

OS execution budget monitoring: The AUTOSAR OS assigns a maximum execution time (budget) to each task. If a task exceeds its budget, the OS terminates it – ensuring that a runaway QM task cannot monopolize the CPU indefinitely.

OS blocking time limits: The AUTOSAR OS limits the maximum time a task can hold a shared OS resource (mutex), preventing priority inversion scenarios where a low-priority QM task blocks a high-priority ASIL task.

Inter-arrival time monitoring: The OS monitors the activation frequency of tasks – detecting and handling tasks that are activated too frequently (which could consume excessive CPU time through repeated short executions).

Watchdog Manager (WdgM): AUTOSAR’s WdgM provides alive supervision (verifying periodic execution), deadline supervision (verifying execution within time limits), and logical supervision (verifying correct execution sequence). WdgM failures trigger safety reactions including hardware watchdog timeout and system reset.

Hardware timer protection: Safety MCUs (Infineon AURIX, Renesas RH850, NXP S32) provide hardware timer units that can be configured to enforce execution budgets independently of the software OS – providing a hardware backstop for temporal FFI.

9. Communication (Logical) Interference – Concept and Examples

Communication interference occurs when incorrect, corrupted, delayed, or repeated data from one software element is accepted by another software element, causing it to behave incorrectly. This applies to both intra-ECU communication (between SWCs via the RTE) and inter-ECU communication (between ECUs via CAN, CAN FD, Ethernet).

Examples: A QM SWC sends an out-of-range sensor value to an ASIL SWC, which uses it without validation – causing an incorrect actuator command. A CAN message from a QM ECU is corrupted during transmission but passes the CAN CRC check – and the receiving ASIL function acts on the corrupted data. An old (stale) sensor reading is used by the ASIL function because the QM SWC that should update it has stopped running. A repeated CAN message (e.g., due to a bus error retry) is processed twice by the ASIL function, causing a double-execution of a safety-relevant command.

10. Communication FFI Mechanisms – E2E, Range Checks, Firewalls

End-to-End (E2E) protection: AUTOSAR’s E2E Library provides CRC (data integrity), alive counter (sequence and loss detection), and timeout monitoring (staleness detection) – covering corruption, loss, repetition, delay, and sequence error faults.

Range checks: Input validation at the receiving ASIL SWC – verifying that received data is within physically plausible bounds before using it. Even if the sending QM SWC provides incorrect data, the range check prevents obviously wrong values from being acted upon.

Plausibility checks: Cross-checking received data against independent sources or physical models – for example, comparing a received temperature value against an expected range based on the current operating conditions.

Communication bus firewalls: Hardware firewalls on the CAN or Ethernet interface that filter incoming messages – preventing unauthorized or unexpected messages from reaching safety-relevant receive buffers.

Timeout monitoring: Detecting when expected data has not been received within the expected time – preventing stale data from being used by safety functions.

11. Two Fundamental FFI Approaches – Prevent vs Detect

ISO 26262 allows two fundamental approaches to achieving FFI:

Prevention: Design the system such that interference cannot occur. Example: MPU hardware enforcement prevents QM software from accessing ASIL memory – the interference is physically impossible. Prevention provides the strongest FFI argument because it eliminates the interference mechanism entirely.

Detection and mitigation: Accept that interference could occur, but detect it when it does and mitigate the effects within the FTTI. Example: E2E protection detects corrupted data and substitutes a default safe value – the interference is detected and its effect is neutralized. Detection and mitigation is acceptable when prevention is not feasible, provided the detection is reliable and the mitigation response occurs within the FTTI.

12. Hardware Support for FFI – MCU Safety Features

Modern automotive safety MCUs provide extensive hardware support for FFI: MPU/MMU for spatial protection (Infineon AURIX TC3xx/TC4xx with 16+ MPU regions per core), hardware timing protection (STM timers, watchdog timers), bus fabric firewalls (limiting which bus masters can access which peripherals), DMA channel protection (restricting DMA transfers to permitted memory regions), interrupt priority locking (preventing QM interrupts from preempting ASIL interrupt handlers), and core-to-core protection on multicore MCUs (restricting which cores can access which resources). These hardware features are the foundation upon which software FFI mechanisms (AUTOSAR OS, RTE, WdgM) are built.

13. AUTOSAR’s FFI Framework

AUTOSAR provides a comprehensive FFI framework through the combination of OS-Applications (partition boundaries for spatial FFI), OS timing protection (execution budgets for temporal FFI), RTE-controlled communication (controlled interfaces for communication FFI), E2E Protection Library (end-to-end data integrity), and WdgM (program flow monitoring). When correctly configured, AUTOSAR’s FFI framework provides the evidence needed to demonstrate FFI between QM and ASIL software components sharing the same MCU — enabling mixed-ASIL ECU architectures that are both safe and cost-effective.

14. Multicore MCU – Additional FFI Challenges

Multicore MCUs (such as Infineon AURIX with 6 cores or NXP S32K3 with 4 cores) introduce additional FFI challenges beyond single-core systems: shared cache interference (one core’s cache activity evicting another core’s cache lines – causing timing variability), shared bus contention (multiple cores competing for memory bus bandwidth – causing worst-case execution time degradation), shared peripheral access (both cores accessing the same peripheral – requiring arbitration), and inter-core communication protection (data exchanged between cores via shared memory must be protected against corruption). Achieving temporal FFI on multicore MCUs requires careful analysis of worst-case execution time (WCET) under maximum interference conditions – the WCET of an ASIL task on one core may be significantly affected by activity on other cores, even with separate memory partitions.

15. FFI Analysis Process – Step by Step

Step 1 – Identify software partitions: Define the ASIL and QM partitions based on the software architecture and safety concept.

Step 2 – Identify shared resources: For each pair of partitions, identify all shared resources (memory regions, CPU time, communication interfaces, peripherals, DMA channels).

Step 3 – Analyze spatial interference potential: For each shared memory resource, evaluate whether a fault in the QM/lower-ASIL partition could corrupt data in the higher-ASIL partition. Identify spatial FFI mechanisms (MPU, static analysis).

Step 4 – Analyze temporal interference potential: For each shared timing resource (CPU, bus, interrupt controller), evaluate whether a fault in the QM/lower-ASIL partition could delay the higher-ASIL partition beyond its timing constraints. Identify temporal FFI mechanisms (execution budgets, timing protection, watchdog).

Step 5 – Analyze communication interference potential: For each communication interface between partitions, evaluate whether incorrect data from the QM/lower-ASIL partition could cause the higher-ASIL partition to behave unsafely. Identify communication FFI mechanisms (E2E, range checks, plausibility checks).

Step 6 – Document the FFI analysis report: Compile all findings into the FFI analysis report – identifying each interference potential, the corresponding FFI mechanism, and the evidence that the mechanism is effective.

Step 7 – Verify FFI mechanisms: Through integration testing (including fault injection), verify that the FFI mechanisms correctly detect and handle interference when it occurs.

16. FFI Without MPU – Software-Only Approaches

Some automotive MCUs – particularly older 16-bit microcontrollers or certain cost-optimized 32-bit devices – lack hardware MPU. Achieving spatial FFI without MPU is significantly more challenging but possible for lower ASILs through software-only approaches: static analysis to verify at compile time that no software element accesses memory outside its permitted region (TASKING Safety Checker, Axivion), mirrored copies with integrity checks (store critical data and its complement, verify before use), CRC protection on critical data blocks (periodic integrity verification), coding guidelines (MISRA) that reduce the risk of wild pointers and buffer overflows, and stack monitoring (canary values, stack usage analysis) to detect stack overflows. These approaches provide weaker FFI evidence than hardware MPU and are generally accepted only for ASIL A/B. For ASIL C/D, hardware MPU is strongly recommended.

17. FFI vs Independence – Recap

As explained in detail in our DFA article: FFI addresses only cascading failures – failure propagation from one element to another. Independence addresses both cascading failures AND common cause failures. FFI is sufficient for mixed-ASIL coexistence (QM and ASIL software on the same MCU). ASIL decomposition requires full independence (FFI + no CCF). The formula remains: Independence = FFI + No Common Cause Failures.

18. Common Mistakes and How to Avoid Them

Mistake 1: Assuming MPU alone provides complete FFI. MPU provides spatial FFI only. Temporal FFI (execution budgets, watchdog) and communication FFI (E2E, range checks) must be addressed separately. All three interference categories must be covered.

Mistake 2: Not configuring the MPU correctly. An MPU that is present but misconfigured provides no protection. The MPU configuration must be verified (through testing and review) to ensure partition boundaries are correctly enforced.

Mistake 3: Ignoring DMA as an interference source. DMA controllers bypass the CPU and the MPU – a DMA transfer initiated by QM software can write to ASIL memory without triggering an MPU exception. DMA channel protection must be separately configured.

Mistake 4: Underestimating multicore interference. On multicore MCUs, interference from other cores affects WCET significantly. A task that meets its timing deadline on a single-core test may miss it under multicore load conditions.

Mistake 5: Not performing fault injection testing. Static analysis and design reviews are necessary but not sufficient for FFI verification. Fault injection testing – deliberately introducing faults (memory corruption, timing overruns, incorrect data) and verifying that the FFI mechanisms detect and handle them – is essential for ASIL C/D.

Mistake 6: Claiming FFI for communication without E2E protection. If an ASIL function receives data from a QM function, communication FFI requires that the ASIL function validates the received data. Simply reading the data without validation does not provide communication FFI.

19. Frequently Asked Questions

Q1: Is FFI only needed between QM and ASIL software?

FFI is needed between any software elements of different ASILs sharing the same resources – including QM vs ASIL and between different ASIL levels (e.g., ASIL A vs ASIL D). FFI can also be beneficial between same-ASIL elements for fault containment and availability, though it is not strictly required by the standard in that case.

Q2: Can FFI be achieved on a single-core MCU without MPU?

For ASIL A/B, software-only approaches (static analysis, mirrored copies, CRC, coding guidelines) can provide partial FFI evidence. For ASIL C/D, achieving robust spatial FFI without hardware MPU is extremely difficult and generally not recommended. Most ASIL C/D projects use MCUs with hardware MPU.

Q3: Does FFI need to be demonstrated at the system level or only at the software level?

FFI applies at every level where elements of different ASILs share resources. Software-level FFI (Part 6 Annex D) addresses CPU, memory, and software communication. System-level FFI (Part 4) addresses shared power supplies, communication buses, and physical interfaces. Hardware-level FFI (Part 5) addresses shared PCB resources and semiconductor-level coupling.

Q4: How does AUTOSAR’s OS-Application concept relate to FFI?

AUTOSAR’s OS-Application is the primary partitioning mechanism for FFI – it groups software components into protection domains with MPU-enforced memory boundaries and OS-enforced timing boundaries. An ASIL D OS-Application and a QM OS-Application running on the same MCU achieve FFI through the MPU (spatial), execution budgets (temporal), and RTE-controlled communication (logical) provided by the AUTOSAR OS.

Q5: What is the FFI analysis report?

The FFI analysis report documents the complete FFI argument: which partitions exist, which shared resources are identified, which interference potentials are evaluated for each shared resource, which FFI mechanisms are implemented, and what evidence (design review, static analysis, testing, fault injection) confirms that the FFI mechanisms are effective. This report is a key work product for the safety case and is reviewed during the functional safety assessment.

20. Conclusion

Freedom from Interference (FFI) is the essential safety property that enables modern mixed-criticality automotive ECU architectures – allowing QM and ASIL software to coexist on the same MCU while maintaining the safety integrity of the ASIL-rated functions. Achieving FFI requires addressing all three interference categories: spatial (through MPU-based memory protection), temporal (through OS execution budgets and watchdog monitoring), and communication (through E2E protection and data validation). The combination of hardware MCU safety features (MPU, timer protection, bus firewalls) and software frameworks (AUTOSAR OS, RTE, WdgM, E2E) provides a robust and well-proven FFI implementation for automotive safety ECUs up to ASIL D.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech.

Stay safe. Stay interference-free. Keep engineering the future.

— The PiEmbSysTech Team