CAST-32A is a position paper published by the Certification Authority Software Team (CAST) in 2016 providing guidance on the use of multicore processors in software airborne systems. CAST-32A identifies issues that could impact the safety, performance, and integrity of software executing on a multicore processor, and it lists ten objectives to address those concerns. The main concern is contention for shared resources, which can result in non-deterministic behavior. That contention can also cause one application to impact the execution of another application, violating the requirement for isolation.
The ten objectives in CAST-32A augment the DO-178C processes for multicore processors and span from planning through verification while focusing on shared resources and interference channels. CAST-32A does not proscribe methods for achieving those objectives but leaves those to the system integrator and their suppliers. Because multicore interference is inherently a hardware issue, the most effective and efficient solutions are possible in the software that interacts directly with the hardware, namely the operating system. It is the operating system that can extend safety-critical determinism to cover the use and allocation of shared resources.
CAST-32A pays special attention to “robust” partitioning. It defines Robust Time Partitioning on a multicore processor as the “result of mitigating the time interference between partitions hosted on different cores [such that] no software partition consumes more than its allocation of execution time on the core(s) on which it executes, irrespective of whether partitions are executing on none of the other active cores or on all of the other active cores.” Robust partitioning enables “separate determination of the WCET [worst case execution time] of an application without any other applications executing.” Without robust partitioning, an application needs to be tested and verified together with all the other applications that will be running concurrently on other cores. Robust partitioning, therefore, is critical to meeting the goals of DO-297 Integrated Modular Avionics (IMA), particularly that applications are independently modifiable.
CAST-32A Objectives Summary
CAST-32A lists ten objectives that augment guidance for multicore processors. Although the applicant/system integrator always has overall responsibility for all objectives, some objectives are extremely difficult to meet without strong support from the RTOS supplier and the RTOS itself. The table below summarizes the objectives and provides an indication of how much support is needed from the RTOS supplier for each objective.
|CAST-32A Objective||Summary||RTOS Input|
|MCP_Planning_1||Document number of active cores, software architecture, IMA hosting, tools, etc.||Helpful|
|MCP_Planning_2||Identify and mitigate shared resource contention||Critical|
|MCP_Resource_Usage_1||Determine the configuration settings||Critical|
|MCP_Resource_Usage_2||Verify mitigation if critical configuration settings are altered||N/A|
|MCP_Resource_Usage_3||Identify interference channels and verify mitigation||Critical|
|MCP_Resource_Usage_4||Verify that demands do not exceed resources||Critical|
|MCP_Software_1||Verify that applications have enough time to complete while other software is running||Critical|
|MCP_Software_2||Verify testing of data and control coupling between applications across cores||N/A|
|MCP_Error_Handling_1||Identify, detect, and contain errors||N/A|
|MCP_Accomplishment_Summary_1||Summarize meeting each of these objectives||Critical|
Meeting CAST-32A Objectives
Meeting CAST-32A objectives takes a joint approach from the system integrator and the RTOS supplier. Because multicore interference is primarily a hardware issue, mitigation is accomplished most effectively and efficiently with support by the RTOS because it is closest to the hardware. Many of the CAST-32A objectives required detailed knowledge of the multicore processor, such as how each of the registers works, the cache replacement algorithm, cache snooping, the detailed performance monitoring capabilities, and variation in I/O device accesses. While it is possible for the system integrator to acquire that knowledge, a knowledgeable RTOS supplier will have already acquired it to implement their software with high assurance and high performance. That detailed knowledge of the processor is used to identify areas of shared resource contention and interference channels.
Two of the most challenging objectives are MCP_Resource_Usage_3 and MCP_Resource_Usage_4. MCP_Resource_Usage_3 requires identification of interference channels between processor cores and verification of the chosen means of mitigation. Identification involves interference analysis of the shared resources on the multicore processor, of which the RTOS supplier should have intimate knowledge. The RTOS supplier is also in the best position to provide the mitigation solution by controlling access to the shared resources. The system integrator is responsible for applying that mitigation solution and verifying it is effective.
MCP_Resource_Usage_4 requires identification and allocation of shared resources to the hosted software application and verification that the demands for the resources do not exceed what is available when the software system is executing. The most challenging part of that objective is actually determining the maximum values for available resources. That involves measuring the impact of interference on shared resources such as bandwidth to shared memory, both before and after mitigation techniques have been applied.
Testing and measuring the multicore interference utilizes interference generators running on all cores not executing the application under test and measures the effect of the interference on the WCET execution time of the application. One approach is to use interference generators that mimic the types of operations expected to be running on the other core. Such an approach does not support a true IMA concept because it does not allow an arbitrary application to be swapped in. Instead, the interference generators need to run many, many types of interference to find the true WCET. For example, the interference generating library available with INTEGRITY-178 tuMP includes hundreds of interference profiles tailored to each processor type. Running that interference library on all cores simultaneously can be used to determine the worst-case bandwidth in the face of interference.
The most challenging aspect of meeting CAST-32A objectives is controlling shared resource contention and mitigating multicore interference. Simplistic approaches sometimes involve segmenting applications by memory intensive, I/O intensive, and compute intensive, and then placing those groups on different cores. Such approaches are problematic because almost all applications need to access memory, and the I/O intensive application needs to access the same on-chip interconnect as the memory-intensive applications. A better approach is to employ an OS that can control off-core accesses to limit multicore interference. The Bandwidth Allocation and Monitoring (BAM) capability in INTEGRITY-178 tuMP does just that by allocating and enforcing off-core bandwidth allocations to shared resources on the multicore processor. Using BAM, the software architect sets the bandwidth allocation for each core, and the INTEGRITY-178 tuMP kernel monitors off-chip bandwidth at a very high frequency. If a processor core exceeds its bandwidth allocation, the kernel briefly throttles execution to bring the core back into compliance. Through the enforcement of bandwidth allocation to shared resources, BAM effectively mitigates multicore interference and supports robust partitioning as described in CAST-32A.
The Future of CAST-32A
Although the original CAST-32 position paper was published in 2014 and later updated to CAST-32A in 2016, approval and certification of multicore systems has eluded avionics systems manufacturers. That includes manufacturers that have been promising approvals coming soon since 2018. It is only now in 2021 that we are starting to see multicore systems being approved by the FAA, and the first several are with the INTEGRITY-178 tuMP RTOS.
Later this year, the FAA and EASA are planning to update CAST-32A in an upcoming harmonized document issued by the FAA as AC 20-193 and by EASA as AMC 20-193. That update is expected to include only minor revisions from CAST-32A, so that multicore interference techniques designed to CAST-32A should be relevant for years to come.