RVS 3.19 Launched
Rapita is proud to be an ISOLDE Partner
Rapita and SYSGO underline partnership
RVS 3.18 Launched
Measuring response times and more with RapiTime
Why mitigating interference alone isn’t enough to verify timing performance for multicore DO-178C projects
There are how many sources of interference in a multicore system?
Supporting modern development methodologies for verification of safety-critical software
DO-178C Guidance: Introduction to RTCA DO-178 certification
MATLAB® Simulink® MCDC coverage and WCET analysis
Code coverage for Ada, C and C++
AMC 20-193
DASC 2023
DO-178C Multicore In-person Training (Huntsville)
HISC 2023
NXP's MCFA 2023
Multicore Timing analysis for Critical Systems
The critical embedded industry is moving towards the use of multi-core rather than single-core processors due to improved performance. The increased performance of multicore and manycore systems per unit area is especially sought after in the embedded aerospace and automotive industries due to the limited physical space often available and the ever-increasing complexity of software in these industries.
However the increase in computational power of complex multicore systems comes at a price; these systems are less predictable than their single-core counterparts. Multicore processors can suffer from interference channels which can significantly affect timing behavior of software running on them. These interference channels can be the result of competition for shared resources or a range of other hardware idiosyncracies. When developing software for safety-critical systems, it is essential to identify and quantify these interference channels.
What is Multicore Timing Analysis?
When developing safety-critical applications to DO 178C (A(M)C 20-193) guidelines or ISO 26262 standards, there are special requirements for using multicore processors. Evidence must be produced to demonstrate that software operates within timing deadlines.
The goal of multicore timing analysis is to produce execution time evidence for these complex systems. In multicore processors, multiple cores compete for the same shared resources, resulting in potential interference channels that can affect execution time. Accounting for this interference and producing robust execution time evidence is a challenge addressed by Rapita’s Multicore Timing Solution.
Challenges of multicore timing analysis
‘‘Using multicore processors poses specific challenges in the critical embedded domain. As traditional worst-case execution time analysis methods don’t take interference effects into account, we need to use new methods.‘‘
In the critical automotive domain, the rapid development of technologies such as autonomous driving and Advanced Driver Assistance Systems (ADAS) has placed increasing importance on the safety of multicore systems. Per ISO 26262, multicore software should be free from cascading failures caused by software failing to meet timing deadlines.
In the critical aerospace domain, worst-case timing evidence must be provided to certification authorities for multicore systems certified against DO-178B or DO-178C. In this context, the use of multicore architectures is addressed specifically in A(M)C 20-193.
Validating the timing requirements of multicore systems offers new challenges. In multicore systems, the timing behavior of a task is affected not only by the software running on it, and its inputs, but also by contention over resources shared with other tasks.
This contention causes interference to the timing behavior of the task. As traditional worst-case execution time analysis methods don’t take interference effects into account, we need to use new methods, such as Rapita Systems' Multicore Timing Analysis Solution.
What is an interference channel?
In the AMC 20-193 position paper published by the EASA, an interference channel is defined as "a platform property that may cause interference between independent applications". This definition can be applied to a range of ‘platform properties’, including thermal factors etc.
Of these interference channels, interference caused by the sharing of certain resources in multicore systems is one of the most significant in terms of execution times. Interference based on shared resources may occur in multicore systems when multiple cores simultaneously compete for use of shared resources such as buses, caches and main memory.
Rapita’s Multicore Timing Solution analyzes the effects of this type of interference channel.
Example
This is a very simple example of a shared resource interference channel.
In this simplified example, tasks running independently on the two cores may need to access main memory simultaneously via the memory controller. These accesses can interfere with each other, potentially degrading system performance.
Solving the challenges of multicore timing analysis
Our multicore timing analysis solution comprises three components: a process, tool automation, and services. Our multicore timing analysis process is a V-model process that we developed in line with DO 178C and A(M)C 20-193. It follows a requirements-based testing approach that focuses on identifying and quantifying interference channels on multicore platforms.
The tools we have developed let us apply tests to multicore hardware (RapiTest) and collect timing data (RapiTime) and other metrics such as scheduling metrics (RapiTask) from them. We use RapiDaemons to create a configurable degree of traffic on shared hardware resources during tests, so we can analyze the impact of this on the application’s timing behavior.
Our multicore timing analysis services include tool integration, porting RapiDaemons, performing timing analysis, identifying interference channels, and others depending on customer needs.
What is a RapiDaemon?
A RapiDaemon is an application designed to create contention in a predictable and controlled manner on a specific shared resource in a multicore system. The effect of this contention can then be measured to identify interference channels and impacts on execution times.
Rapita have developed and optimized a set of standard RapiDaemons that target shared resources common to most multicore architectures, such as main memory. Some projects will require the creation of custom RapiDaemons for a specific architecture.
Demo
This demo highlights the effects of interference on multicore execution times on the YOLO real-time object detection software.
It demonstrates a slowdown in task execution time of almost a factor of 10 when we applied contention for shared resources used by that task.
