What is CAST-32A?

Discover CAST-32A

What is CAST-32A?

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’). 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.

Upcoming training

DO-178C/Multicore Training
Date: 19-Nov-19 to 21-Nov-19
Location: Bristol, UK
We're: Co-hosting
“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

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
Multicore Interference path

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

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 follows a V-model process to produce a clearly structured flow of verification artefacts that satisfy DO-178C traceability requirements and meet CAST-32A guidelines, ensuring a cost-effective and methodical verification process.