Skip to main content
SAIF Autonomy to use RVS to verify their groundbreaking AI platform
RVS 3.22 Launched
Hybrid electric pioneers, Ascendance, join Rapita Systems Trailblazer Partnership Program
Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification
How to certify multicore processors - what is everyone asking?
Data Coupling Basics in DO-178C
Control Coupling Basics in DO-178C
Components in Data Coupling and Control Coupling
DO-278A Guidance: Introduction to RTCA DO-278 approval
ISO 26262
Data Coupling & Control Coupling
Verifying additional code for DO-178C
DASC 2025
DO-178C Multicore In-person Training (Fort Worth, TX)
DO-178C Multicore In-person Training (Toulouse)
HISC 2025
What is CAST-32A?
If you're looking for our MACH178 solution, which is our product for AC 20-193, AMC 20-193 and CAST-32A compliance, you can find it here.
One of the most significant recent changes in the embedded computing world is the increasing adoption of multicore processors. These processors represent the future of aerospace development and their adoption is crucial to both meet the needs of modern avionics systems and avoid potential long-term single-core processor availability concerns.
The use of multi-core processors does come at a price, however, as unlike their single-core counterparts, they offer neither a deterministic environment nor predictable software execution times. This is particularly dangerous in the critical software domain.
In response to the increased use of multicore processors, the Certification Authorities Software Team (CAST) published Position Paper CAST-32A named ‘Multicore Processors’ (often referred to as just ‘CAST-32A’) in November 2006. This paper identifies topics that could impact the safety, performance and integrity of airborne software systems executing on multicore processors and provides objectives intended to guide the production of safe multicore avionics systems.
CAST-32A was replaced by official guidance document AMC 20-193 for avionics projects to be certified by EASA® in early January 2022, and replaced by AC 20-193 for avionics projects to be certified by the FAA™ in early January 2024. For more information on A(M)C 20-193, see our dedicated webpage on the topic.
“The purpose of this CAST paper is to identify topics that could impact the safety, performance and integrity of a software airborne system executing on Multicore Processors” - Federal Aviation Administration
Want to learn more about multicore avionics certification?
Rapita Systems regularly deliver technical, in-person training courses on the topics of CAST-32A and A(M)C 20-193.
We have developed this training to offer value for both beginners and experts alike.
Register your interest using the form.
CAST-32A addresses several multicore processor topics including software verification, error detection and handling and reporting of compliance. All topics have a rationale for being included and an objective or a set of objectives that the paper wants to achieve.
Interference Channels and Resource Usage
MCP_Resource_Usage_3: The applicant has identified the interference channels that could permit interference to affect the software applications hosted on the MCP cores, and has verified the applicant’s chosen means of mitigation of the interference.
Example of multicore interference 
Error Detection and Handling and Safety Nets
MCP_Error_Handling_1: The applicant has identified the effects of failures that may occur within the MCP and has planned, designed, implemented and verified means (which may include a ‘safety net’ external to the MCP) commensurate with the safety objectives, by which to detect and handle those failures in a fail-safe manner that contains the effects of any failures within the equipment in which the MCP is installed.
Software Verification
MCP_Software_1: The applicant has verified that all the software components hosted by the MCP comply with the Applicable Software Guidance. In particular, the applicant has verified that all the hosted software components function correctly and have sufficient time to complete their execution when all the hosted software is executing in the intended final configuration.
MCP_Software_2: The applicant has verified that the data and control coupling between all the individual software components hosted on the same core or on different cores of the MCP has been exercised during software requirement-based testing, including exercising any interfaces between the applications via shared memory and any mechanisms to control the access to shared memory, and that the data and control coupling is correct.
NOTE : When this objective cannot be completely met during the Software verification, applicants may propose to use System level testing to exercise the data and control coupling between components hosted on different cores.
MCP_Resource_Usage_4: The applicant has identified the available resources of the MCP and of its interconnect in the intended final configuration, has allocated the resources of the MCP to the software applications hosted on the MCP and has verified that the demands for the resources of the MCP and of the interconnect do not exceed the available resources when all the hosted software is executing on the target processor.
NOTE: The need to use Worst Case scenarios is implicit in this objective.
Key resources
How do I meet CAST-32A objectives?
Multicore systems are much more complex than their single core counterparts. To understand how to verify their timing behavior in line with CAST-32A objectives, we must first understand the unique challenges inherent in the analysis. We’ve listed some of these below.
We need to consider resource contention and interference
The execution time of a task in a multicore system is affected by contention for shared resources and the interference this causes. To investigate the timing behavior of a multicore system, we need to take this interference into account.
Multicore timing analysis can’t be entirely automated
The complexity of multicore processors means that building a fully automated timing analysis solution is unrealistic. While tool support can automate most of the data gathering and analysis processes, engineering wisdom and expertise is needed to understand the system and direct tool usage to produce necessary evidence.
We have to test on the real hardware
Multicore CPUs are complex and often their internals are hidden, making purely analytical models of limited use in understanding their timing behavior. As such, the only way to determine exactly how the processor and its components behave is to measure timing behavior on the system itself.
Assumptions need to be tested
To analyze the timing behavior of a multicore system, you will need to make some assumptions about things such as the interference channels in the system and their effects. After running tests based on these assumptions, you will likely need to reassess those assumptions and rerun tests.
The V-Model approach
The Rapita Systems multicore timing analysis solution (MACH178) follows a V-model process to produce a clearly structured flow of verification artefacts that satisfy DO-178C traceability requirements and meet CAST-32A and A(M)C 20-193 guidelines, ensuring a cost-effective and methodical verification process.
