RSS
Multicore Execution at DO-178C DAL A: It’s Hard!
Do you know anyone who avoided trying to do something very challenging and says, “It’s too hard!”? That’s where many of avionics companies are today when considering safety-critical applications running on multiple processor cores at DO-178C DAL A. It is hard. It is challenging. But it has also been done.
The first civilian certification of DAL A applications running on multiple cores happened in 2021. That certification was a TSO authorization of the CMC Electronics PU-3000 avionics computer as a flight director under TSO-C198. A few months later, a second CMC system, the MFD-3068, received three additional TSO authorizations (Figure 1). Both CMC systems run the INTEGRITY®-178 tuMP RTOS and have software running on each of the four cores. Last year, two more avionics companies achieved multicore certification.
Up to this point, almost all certifications on a multicore processor ran all applications on a single core. That was the safest thing to do but does not provide the computational power required for more complex applications, such as sensor fusion, or for further consolidation.
Robust Partitioning
So, what is the path forward if this is very hard? The primary capability needed is “robust partitioning” as defined in AC 20-193 “Use of Multi-Core Processors” (MCPs) and as required for DO-297 “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations.” Achieving robust partitioning proves that applications running on different cores are kept independent from each other, greatly simplifying development, testing, verification, and subsequent modification. In particular, AC 20-193 states that “Applicants who have verified that their MCP platform provides both robust resource partitioning and robust time partitioning (as defined in this document) may verify software applications separately on the MCP and determine their WCETs separately.”
Figure 1: MFD-3068 Multicore Multifunction display from CMC Electronics
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 quite different in that it requires new techniques to mitigate time interference between partitions hosted on different cores and running concurrently.
AC 20-193 defines “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.”
Mitigating Multicore Interference
Because multicore time interference is mostly a hardware issue, the best place to mitigate it is in the lowest level of software running directly on the hardware, namely the operating system or a bare-metal hypervisor. The mitigation method needs to be general enough to cover multiple sources of interference, including the memory controller, DDR memory, I/O, shared cache, and the internal fabric that connects them. Mitigation techniques designed for just one of those sources, such as cache partitioning, cannot achieve robust partitioning on their own.
A proven approach is to regulate the access of each core to the on-chip interconnect, allotting each core a specified portion of the bandwidth. The tricky part is to regulate access over small enough time windows so that no application has to wait any significant amount of time before it gets its allocation. Coarse-grain regulation can be implemented fairly straightforwardly using only the hardware counters available on most multicore processors and is useful for detecting and disabling a misbehaving application. This type of regulation is called a “safety net” in airworthiness standards. Advanced timing techniques are required to implement the fine-grain control needed for a quality-of-service mechanism for applications operating within design parameters.
Bandwidth Allocation with INTEGRITY-178 tuMP
The INTEGRITY-178 tuMP RTOS achieves robust partitioning using a fine-grain Bandwidth Allocation and Monitoring (BAM) capability, developed to DO-178C DAL A objectives. BAM uniquely uses an extremely small time quantum to monitor and enforce the cores’ use of shared multicore resources through the chip-level interconnect. Because the chip-level interconnect is at the center of interactions between the cores and other shared resources, it is the ideal place to observe and enforce limits on the use of shared resources.
The system architect decides how much bandwidth to allocate to each core based on the functional requirements of the applications or design assurance levels. When applications on a particular core reach the threshold bandwidth for a given BAM time quantum, that core is cut off from consuming shared resources until the next BAM time quantum. Using this mechanism, a DAL-A application can be allocated a set amount of resources, such as 50% of the total bandwidth, with the remaining cores sharing the remaining 50% bandwidth (e.g. 20%, 20%, and 10%).
Figure 2: Worst-case execution timing stays steady after applying BAM and selecting the amount of bandwidth allocated to a core.
Figure 2 shows how the resulting worst-case execution time (WCET) stays steady, independent of what is happening on the other cores. For example, an 80% bandwidth allocation holds the WCET steady at approximately 3x the WCET for executing with no interference instead climbing to 12-13x without BAM interference mitigation.
The INTEGRITY-178 tuMP RTOS enables multiple independent applications to execute on a multicore environment in a predictable, bounded, and application-independent manner. Its BAM capability enables system integrators to identify and mitigate interference in multicore systems. By directly addressing the AMC 20-193 guidance for multicore interference, BAM significantly lowers integration and certification risk. Together, BAM and the flexible multiprocessing architecture of INTEGRITY-178 tuMP enable system integrators to achieve their SWaP objectives by optimizing core utilization while maintaining the determinism required for safety-critical applications.
More details on multicore interference, mitigation methods, and Bandwidth Allocation and Monitoring (BAM) can be found in the white paper “Solving Multicore Interference for Safety-Critical Applications.”
