Title: Multi-Core Safety Architectures: An ISO 26262 Overview | ISO 26262 Academy URL: https://iso26262.academy/blog/multi-core-safety-architectures-iso-26262-overview Description: Multi-core SoCs add shared hardware and timing interference to every ISO 26262 safety argument. A map of the architecture families and what decides the choice. --- [Technical](https://iso26262.academy/blog/category/technical) # Multi-Core Safety Architectures: An ISO 26262 Overview ![Close-up of a densely populated circuit board, with a square multi-pin integrated circuit in sharp focus among capacitors and smaller packages.](https://iso26262.academy/_next/image?url=https%3A%2F%2Facademy-videos.fra1.digitaloceanspaces.com%2Fblog%2Fimages%2F2026%2F08%2F707169a3-34d1-4a3b-9359-0a07f2df3c10.webp&w=1920&q=75) Multi-core automotive SoCs add shared hardware, mixed criticality, and timing interference to every safety argument. This article maps the families of multi-core safety architecture, the three interference concerns underneath them, and what actually decides which one fits. ![ISO 26262 Academy](https://iso26262.academy/logo.png) ISO 26262 Academy By [Paul Danci](https://iso26262.academy/about) 27 August 2026 6 min read Share Text size A faulty software task on one core can corrupt data that an automated emergency braking function depends on while it runs on another core. On a modern automotive system-on-chip that is a routine design problem, not a theoretical one. Multi-core devices buy performance and function consolidation, and they charge for it in new failure modes, timing interference, and a wider security surface. This article is an orientation rather than a design manual: what changes when safety-related functions move onto a shared SoC, the families of architecture that answer it, why freedom from interference ends up constraining all of them, and what genuinely decides which one fits a given item. ## What changes when safety moves onto a shared SoC On a single-core microcontroller, isolation is largely logical. Tasks are scheduled, memory is managed, and the execution timeline is predictable. A multi-core device adds concurrent execution and a layer of shared resources that sits underneath every safety argument. - **Shared hardware**: caches, interconnects, memory controllers, and peripherals are used by several cores at once, which couples elements that the software architecture treats as separate. - **Mixed criticality**: safety-related and quality-managed software commonly share the same die, so separation has to be established rather than assumed. - **Common-cause exposure**: a single fault in shared memory, clocking, or power can affect several cores together. - **Security coupling**: a compromised or misbehaving core can degrade the availability of a safety function without ever corrupting its data. Consider an ECU where perception and decision logic for automated emergency braking run on one core and actuator control runs on another. A high-bandwidth logging task on a third core can saturate the memory path and delay the actuator core past its deadline. Nothing was corrupted, and the function still degraded. ![Block diagram: three cores on one system-on-chip, two safety-related and one quality managed, all feeding a shared interconnect and memory controller above external memory. The quality-managed core's traffic is drawn heavy to show it delaying a safety-related core without corrupting its data.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/08/a42e2ab2-5c96-4fc7-a5ed-a7492c86c40d.svg) Consolidation puts every core on the same route to memory. Interference does not need shared data. ## The families of architecture Most multi-core safety designs are variations on a small number of ideas. Recognising the families is enough to read a device datasheet and follow a supplier conversation. Choosing between them for a specific item is a separate exercise, and a considerably harder one. ![Four panels showing the shapes of multi-core safety architectures: two cores compared against each other raising an alarm, two independent cores each with their own diagnostics, a main channel watched by a smaller monitor, and one die split between safety-related and quality-managed partitions.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/08/0cddd61e-9a73-4eef-8698-0c296f6a5c2a.svg) The four arrangements differ in what they compare, what they watch, and where they draw a boundary. ### Duplicate and compare Two cores execute the same work in step and hardware compares the result. A divergence is treated as a detected fault. This is the familiar lockstep arrangement, and it targets random hardware faults within the compared scope. ### Independent cores with added diagnostics The same silicon can often be configured so those cores run separately instead of in step. That returns the compute to the application, and it moves the burden onto whatever diagnostics, redundancy, or monitoring is put in place instead. ### Monitoring by a separate element A smaller, independent element verifies chosen properties of the main channel instead of repeating its computation. The check costs less than duplication, and its value depends entirely on which failure modes it can actually observe. ### Partitioned mixed criticality Safety-related and non-safety software share cores under enforced separation, typically through memory protection hardware, a partitioned operating system, or a hypervisor. Utilisation improves, and the separation argument becomes the difficult part. Keep learning [Free course preview Freedom from Interference (FFI)](https://iso26262.academy/features/concepts/freedom-from-interference) [Or test yourself with the 7-question demo exam](https://iso26262.academy/demo-exam) ## Freedom from interference is the constraint underneath all of them ISO 26262 expects that elements of different criticality, and the resources they share, cannot interact such that a safety requirement stops holding. On a multi-core device that concern spans three kinds of interaction: - **Memory**: one element reads or writes storage that belongs to another. - **Timing and execution**: one element delays another by consuming a shared resource, with no data corruption involved at all. - **Exchange of information**: a message between elements arrives late, out of order, duplicated, corrupted, or not at all, and the receiver acts on it anyway. This is usually where a multi-core architecture is won or lost. Every family above still shares memory, clocking, and interconnect with the rest of the die, so a comparison pair can be delayed even when its data is perfect, and an independent monitor is only as independent as its dependency list allows. Hardware features such as protection units, peripheral access control, and bandwidth regulation are the enforcement layer, not the argument itself. The argument needs configuration, analysis, and verification evidence behind each of them. ## What actually decides the choice There is no best multi-core safety architecture, only a fit against constraints. The decision is driven by the safety requirements allocated to the element, the behaviour required after a fault (a defined safe state permits a different design from continued or degraded operation), the timing and throughput the application needs, the dependencies that cross the intended boundary, and the evidence a supplier actually ships with the device. One caution outweighs the rest. A safety claim in a datasheet is conditional. Mechanism names do not carry diagnostic coverage, and an ASIL is a property of a safety goal, not of a core or a hardware feature. The device is an enabler; the safety lives in what is done with it. ## Turning multi-core complexity into a structured safety story Multi-core safety feels overwhelming mostly because several concerns arrive together: shared hardware, mixed criticality, timing analysis that no longer holds in isolation, and security assumptions that interact with availability. Naming the families of architecture and the three interference concerns is enough to make the problem tractable and to start asking a supplier the right questions. To go further on the platform, the Freedom from Interference concept covers the memory, timing, and communication concerns in depth, Safety Design Patterns walks through duplicate-and-compare and monitored architectures, and the Technical Safety Concept material shows how these architectural decisions become requirements you can argue in a safety case. ## Abbreviations & Key Definitions - **AEB** - Automated Emergency Braking, a system that automatically applies the brakes to avoid or mitigate a collision. - **ASIL** - Automotive Safety Integrity Level, the risk classification scheme defined by ISO 26262 for safety-related automotive systems. - **Diagnostic coverage** - The proportion of a failure rate that a safety mechanism detects or controls, always stated for a defined scope. - **ECU** - Electronic Control Unit, an embedded controller in a vehicle. - **Freedom from interference** - The ISO 26262 concept that elements of different criticality must not affect each other such that a safety requirement stops holding. - **Hypervisor** - A software layer that hosts several operating systems or partitions on shared hardware and enforces separation between them. - **ISO 26262** - The international standard for functional safety of electrical and electronic systems in production road vehicles. - **Lockstep** - An arrangement in which two cores execute the same instructions in step so hardware can compare their behaviour. - **QM** - Quality Management, used in ISO 26262 for functions with no specific safety requirements beyond standard quality processes. - **SoC** - System-on-Chip, an integrated circuit combining CPU cores, memory, and peripherals on one die. Related on the Platform [Freedom from Interference (FFI) Concept](https://iso26262.academy/features/concepts/freedom-from-interference) [Safety Design Patterns Concept](https://iso26262.academy/features/concepts/safety-design-patterns) [Technical Safety Concept Concept](https://iso26262.academy/features/concepts/technical-safety-concept) Last updated: 9 October 2026 Tags [multi-core](https://iso26262.academy/blog/tag/multi-core) [freedom-from-interference](https://iso26262.academy/blog/tag/freedom-from-interference) [system-architecture](https://iso26262.academy/blog/tag/system-architecture) [functional-safety](https://iso26262.academy/blog/tag/functional-safety) [iso-26262](https://iso26262.academy/blog/tag/iso-26262) Share this article ## Read the full story about Freedom from Interference From HARA to Safety Mechanisms - master every concept with clear, practical explanations and real-world examples. [Browse Concepts](https://iso26262.academy/features/concepts/freedom-from-interference) ## Comments ## Related Articles [![An automotive driver-assistance controller board with two identical processor packages side by side, next to a larger processor, memory, power components and a row of connectors, all on one PCB.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/10/d0792939-6e66-418e-935b-485f4dc3db35-1200.webp) Technical ### The Core Concept of Dependent Failure Analysis in ISO 26262 7 min Oct 2](https://iso26262.academy/blog/the-core-concept-of-dependent-failure-analysis-in-iso-26262) [![5 Essential Advices for ASIL Decomposition in ADAS Architectures](https://iso26262.academy/_next/image?url=https%3A%2F%2Facademy-videos.fra1.digitaloceanspaces.com%2Fblog%2Fimages%2F2026%2F03%2F85a4f098-5684-4484-9429-6ca19a3a4746.jpg&w=1920&q=75) ### 5 Essential Advices for ASIL Decomposition in ADAS Architectures 9 min Mar 2](https://iso26262.academy/blog/5-essential-advices-for-asil-decomposition-in-adas-architectures) [![An engineer at a desk writing an AUTOSAR-style CAN driver in C for an ECU, with a cross-compiler build finishing with zero errors and a laptop showing ECU software domains and CAN traffic.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/10/6d99d4b3-855e-4602-9bea-d367d9c6454f-1448.webp) Technical ### Software in ISO 26262: A Fault With No Failure Rate 7 min Oct 1](https://iso26262.academy/blog/software-in-iso-26262-a-fault-with-no-failure-rate)