Multi-Core Safety Architectures: An ISO 26262 Overview

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.

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.

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.

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