RSS
AC 20-193 Overview
AC 20-193 is an advisory circular (AC) from the U.S Federal Aviation Administration (FAA) that describes an acceptable means of compliance with the applicable airworthiness regulations for multicore processors (MCPs) contained in airborne systems and equipment used in type certification or technical standard order (TSO) authorization. Issued in January 2024, AC 20-193 is substantially identical to AMC 20-193 adopted by the European Union Aviation Safety Agency (EASA) in 2022. Those standards are based on the recommendations in the CAST-32A “Multi-core Processors” position paper published in 2016. (See Changes from CAST-32A to AC 20-193.)
The purpose of AC 20-193 is to describe acceptable means of showing compliance with the DO-178C/ED-12C airworthiness specification when using multicore processors. Published in 2011, DO-178C/ED-12C does not address issues arising from the use of MCPs, particularly contention for shared resources that can affect worst-case execution time (WCET).
Multicore Interference
Multicore processors have the ability to execute multiple software applications concurrently by running them on different cores. Those cores share system resources, such as memory, cache, and I/O interface, as well as the internal fabric that connects those resources to the cores. Contention for these shared resources occurs when multiple processor cores try to access the same resource concurrently. In safety-critical applications, the principal concern is how such shared resource contention can cause an application running on one core to interfere with an application running on another core, negatively affecting determinism, WCET, and, ultimately, safety.
Robust Partitioning
The general method for preventing inference between applications is partitioning. DO-178C/ED-12C defines partitioning as “a technique for providing isolation between software components to contain and/or isolate faults and potentially reduce the effort of the software verification process.” The reduction in verification effort can be significant, particularly given the exponential expansion of interactions among concurrent applications on an MCP.
AC 20-193 is more specific by referring to “robust” partitioning in objective MCP_Software_1:
AC 20-193 defines “robust partitioning” as:
“Robust resource partitioning (adapted from ED-94C / DO-248C and ED-124 / DO-297): robust resource partitioning is achieved when:
- Software partitions cannot contaminate the storage areas for the code, I/O, or data of other partitions;
- Software partitions cannot consume more than their allocation of shared resources; and
- Failures of hardware unique to a software partition cannot cause adverse effects on other software partitions.”
“Robust time partitioning (on an MCP): this is achieved when, as a result of mitigating the time interference between partitions hosted on different cores, 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 resource partitioning on an MCP is somewhat similar to that on a single-core processor in that the on-chip memory management unit (MMU) and I/O memory management unit (IOMMU) provide the majority of the required functionality. Robust time partitioning is much different in that it requires a new set of techniques to mitigate time interference between partitions hosted on different cores.
Key Objectives Directly Addressing Multicore Interference
Two of the objectives in AC 20-193 directly address the topic of multicore interference. MCP_Resource_Usage_3 includes:
Note (a) for that objective lists some of the sources of interference as shared memory, shared cache, on-chip interconnect, and shared peripherals. In addition to the section on robust partitioning shown above, MCP_Software_1 dictates what is needed without robust partitioning:
Software components or sets of software requirements for which interference is not avoided or mitigated should be tested on the target MCP with all software components executing in the intended final configuration, including robustness testing of the interfaces of the MCP.
The penalty for not mitigating multicore interference is quite high, requiring testing all software components together in the final configuration. That also requires retesting and reverification of all software components if any one component changes.
Mitigation Solutions for Multicore Interference
Multicore interference is essentially a hardware issue stemming from CPU designers optimizing for the highest average performance and throughput rather than worst-case execution time. Because it is a hardware issue, multicore interference is most effectively addressed at the lowest level of software, namely the host operating system or hypervisor running directly on the hardware.
To achieve robust partitioning, the mitigation solution needs to cover all or al>most all sources of interference for both resource partitioning and time partitioning. The most general solution to multicore interference is the allocation of bandwidth from each core to the shared resources on a multicore processor, which directly addresses robust time partitioning. The INTEGRITY-178 tuMP multicore RTOS includes a fine-grained Bandwidth Allocation and Monitoring (BAM) capability developed to DAL A objectives to observe interference channels and mitigate them. BAM monitors and enforces the bandwidth allocation of the chip-level interconnect to each of the cores, thereby controlling access to all shared resources. Using DRAM contention as an example, BAM can reduce multicore WCET from 13x the single-core WCET down to less than 2x.
One of the shared resources, namely the shared cache, has a secondary type of interference that needs to be mitigated. While most shared resources see interference only from access contention, the shared cache also has interference from cache line eviction. The general solution to cache line eviction is cache partitioning. Hardware-based cache partitioning, when available, is preferred for its simplicity and performance. Unsurprisingly, cache partitioning addresses only one type of interference within the cache, not the rest of the memory subsystem or any other sources of interference. As a result, cache partitioning alone is not sufficient to provide robust partitioning. For a comparison of cache partitioning techniques, a comparison to bandwidth allocation, and the implementation in INTEGRITY-178 tuMP, see the Tech Note: Cache Partitioning vs. Bandwidth Allocation for Mitigating Multicore Interference.
Additional AC 20-193 Objectives
Although addressing multicore interference is the most challenging issue in meeting AC 20-193 objectives, it is not the only challenge. The system integrator is ultimately responsible for meeting those objectives or showing an alternative means of compliance, but the supplier of the host operating system or hypervisor is in a position to help. For example, some objectives require detailed knowledge of the internals of the MCP, and the supplier must have gained at least some of that knowledge if they implemented any form of interference mitigation.
Out of the nine objectives in AC 20-193, a knowledgeable operating system supplier should be able to help address seven of those objectives, and their help is critical for at least two of the most challenging objectives. The two objectives where their help is critical include MCP_Planning_2, to identify and mitigate shared resource contention, and MCP_Resource_Usage_3, to identify interference channels and verify mitigation. The table below summarizes the nine objectives and where the operating system supplier can help.
| 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 | Helpful |
| MCP_Resource_Usage_3 | Identify interference channels and verify mitigation | Critical |
| MCP_Resource_Usage_4 | Verify that demands do not exceed resources | Helpful |
| MCP_Software_1 | Verify that applications have enough time to complete while other software is running | Helpful |
| 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 | Helpful |
Changes from CAST-32A to AC 20-193
The objectives outlined in AC 20-193 remain substantially the same from CAST-32A, although one objective (MCP_Resource_Usage_2) was deleted because it was redundant with an objective in another AC (AC 20-152A, Objective COTS-8). The key definitions of robust resource partitioning and robust time partitioning also remain consistent across the two documents.
Hosted Applications Requires Robust Partitioning
There are several new definitions and minor changes to CAST-32A definitions. The major new definition is for IMA, and it is based on robust partitioning:
Integrated modular avionics (IMA) platform: an integrated modular avionics MCP platform that provides both robust resource partitioning and robust time partitioning (as defined in this document).
This definition has significant implications for the MCP_Planning_1 objective, which includes identifying “all the software components that will be hosted on the MCP.” Using the same language as in CAST-32A, Note (b) specifies an exclusion for an IMA platform: “the software components that are identified do not have to include the hosted software applications.” Based on the new definition of IMA platform, AC 20-193 makes clear that to get that exclusion, the platform must have both robust resource partitioning and robust time partitioning.
Interference within a Single Component
Both MCP_Software_1 and MCP_Software_2 contain an additional note to make sure that verification testing covers interference that can occur within a single software component executing tasks on multiple cores (in Bound Multi-Processing or Symmetric Multi-Processing):
e) Interference may occur between tasks of a single component when the tasks execute on different cores.
Hardware Resources
MCP_Planning_2 contains an additional instruction to identify hardware resources:
2. Identify the MCP hardware resources to be used to support the objectives in this AC.
Some hardware resources, such as a memory management unit (MMU) and an I/O MMU, are commonly used and have a proven pedigree in safety certifications. Many MCPs have added other types of hardware resources to aid with multiprocessing, but such “novel” mechanisms have not been thoroughly verified from an airworthiness standpoint.
Use of the On-Chip Interconnect
MCP_Planning_2 contains additional language in Note (a) to include the on-chip interconnect:
a) … The description of shared resources should also include any use of shared interconnect and take into account the time interference due to arbitration for access to the shared interconnect.
Net Independence
MCP_Error_Handling_1 now includes a clarification that any “safety net” used to detect and handle failures must be independent from the MCP.
Verification on Final Hardware
MCP_Software_1 now clarifies that software verification should be done with the hardware in the intended final configuration as well as the software.
Verified Independence
In AMC 20-193 (but not AC 20-193), MCP_Planning_1 contains an additional note:
d) Where the applicable software and AEH [airborne electronic hardware] guidance calls for independence in meeting the objectives, the plans should identify how verification independence will be applied.
