Ensuring Reliable Timing in Safety‑Critical Multicore Embedded Systems

Modern vehicles and aircraft no longer rely solely on mechanical components. Their safety and performance hinge on embedded software that runs on complex heterogeneous multicore processors, managing everything from flight control to power steering with microsecond‑level deadlines.

In a multicore environment, the execution time of a task is influenced not only by its own code but also by other tasks sharing the same hardware resources. This interference can push a system beyond its safety margins.

Developing safety‑critical embedded software demands a multi‑million‑euro, multi‑year effort. From the earliest design stages, safety must be ingrained in the architecture and the timing behavior of every task must be rigorously understood to guarantee deadlines are met.

Solving the Multicore Timing Analysis Puzzle

While multicore processors promise higher performance, they also introduce contention for shared resources such as buses, memory, caches, and accelerators. A task running on one core can slow down tasks on other cores, creating unpredictable timing variations.

Key questions arise: How can we quantify the impact of such interference? How do we analyze, test, and document that safety‑critical software will always finish within its deadlines on a multicore platform?

Industry leaders—Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC), and Marelli Europe (MAR)—have spent years addressing these challenges. BSC and Rapita are now delivering a solution set that will soon be adopted across aerospace and automotive sectors. The success hinges on specialized tooling, automation, and a safety‑oriented, requirements‑driven methodology.

This work underpins the MASTECS project, a European Commission‑funded, multidisciplinary R&D initiative launched in December 2019. MASTECS will mature the technologies and provide a proven approach for certifying avionics and automotive systems, with case studies from RTRC and MAR illustrating real‑world impact.

State‑of‑the‑Art Tools

Commercial tools excel for single‑core analysis but struggle with the complexity of multicore certification. The limitations include:

• Static timing analysis tools [1] hit a complexity wall, unable to model sophisticated hardware or extremely complex software.
• Measurement‑based solutions—while prevalent in single‑core testing (e.g., Rapita’s RVS toolset)—lack a hardware‑expert methodology to produce trustworthy timing bounds for multicore workloads with adequate traceability.

To date, no commercial tool outside the MASTECS development effort offers comprehensive multicore timing analysis that aligns with safety standards and emerging certification requirements.

Interference Analysis and Control in Action

The cornerstone of our approach is a structured test methodology that blends hardware and software expertise to generate evidence of multicore timing behavior. BSC’s multicore micro‑benchmark technology (MμBT), commercialized by Rapita as RapiDaemons, enables designers to create interference scenarios that stress specific shared resources.

Micro‑benchmarks—tiny, low‑level code snippets—operate at the hardware‑software interface to impose quantifiable pressure on a target resource. They reveal the effect of interference channels and can be tailored to induce, measure, or validate contention. Key attributes include:

1. Targeted, quantifiable pressure on a shared resource.
2. Verifiable behavior through event monitors.
3. Alignment with specific timing requirements, such as testing mitigation effectiveness.

click for larger image

Figure 1: Use of micro‑benchmarks in interference analysis. (Source: Authors)

A diverse library of micro‑benchmarks exists to match desired interference levels, maximize resource impact, or act as sensitive “victim” tests.

When analyzing interference, we pair MμBT with a Task Contention Model (TCM) that provides early estimates of contention delays. Rapita’s RapiTest and RapiTime automate test creation and execution on the embedded target.

Design Methodology

Following a seven‑step process integrated into the V‑model software lifecycle (see Figure 2), engineers gain deep insight into interference effects:

1. Hardware configuration & interference channel identification. Hardware experts pinpoint critical settings, interference pathways, and mitigation options, while selecting event monitors for verification.
2. Define timing requirements. Capture user‑specific needs, risks, and safety constraints, and evaluate hardware isolation strategies.
3. Test case design. Craft test descriptions that validate hypotheses, specifying the micro‑benchmarks needed for interference analysis under isolated and stressed conditions.
4. Implement test procedures. Assemble a test framework, micro‑benchmarks, and measurement probes. Currently manual, this will be automated within MASTECS.
5. Gather evidence. Execute tests on the target platform, collecting data that ties directly to verification requirements.
6. Analyze results. Technical experts review outcomes against requirements. For example, Figure 3 shows RapiTime’s execution‑time breakdown.
7. Validate & document. Final review, report generation, and qualification artifacts ready for certification submissions.

click for larger image

Figure 2: MTA steps in the V‑model software development process. (Source: Authors)

Hardware Expertise and the Timing Analysis Process

Hardware insight is vital from the outset. Early involvement includes:

1. Identifying multicore configurations that shape functional and timing behavior, and determining isolation mechanisms that reduce contention.
2. Spotting interference channels by navigating complex processor manuals and consulting vendors for missing details.
3. Selecting event monitors that capture task activity on interference channels, and validating them with dedicated micro‑benchmarks [2].
4. Collaborating with timing analysts to derive requirements and design tests that load specific interference channels.

In later stages, hardware experts assess test results, refine hypotheses, and propose additional tests as needed.

click for larger image

Figure 3: Analyzing results (RapiTime). (Source: Authors)

The Bigger Picture

The seven‑step design process is part of a broader multicore verification methodology (see Figure 2). It delivers full traceability—from evidence and results back to requirements and design—supporting both CAST‑32A and ISO 26262. CAST‑32A, released by the Certification Authorities Software Team (CAST) in 2016, outlines objectives for safe multicore avionics, including interference bounding. EASA and FAA are working on a unified AMC/AC (AMC 20‑193) adaptation expected later this year.

Expertise Cannot Be Automated

Interference dynamics are complex; automated tools can only complement, not replace, seasoned engineers. Multicore experts bring deep knowledge of hardware configurations and interference channels, while software analysts translate requirements into rigorous tests. Human insight is essential for validating assumptions, interpreting results, and iterating on designs.

References

1. Reinhard Wilhelm. Mixed Feelings about Mixed Criticality. Workshop on Worst‑Case Execution Time Analysis, 2018.
2. Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. High‑Integrity Performance Monitoring Units in Automotive Chips for Reliable Timing V&V. IEEE Micro 38(1): 56‑65 (2018).
3. EASA and FAA to issue further guidance on multicore certification this year.