INTEGRITY-178 tuMP RTOS

All multicore hardware architectures include shared resources, such as memory controllers, DDR memory, I/O, cache, and the internal fabric that connects them. Contention for these shared resources results 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, quality of service, and, ultimately, safety.

The impact of such multicore interference can be significant. With just one other core contending for the same resources, the worst-case execution time (WCET) of an application can be up to 8 times longer. With a second and third interfering core, the WCET can skyrocket to over 13 times longer. Note that this worst-case behavior is much worse than the linear 2x, 3x, 4x that might be expected for average cases.

Directly addressing this issue of multicore interference, the Certification Authority Software Team (CAST), supported by the FAA, EASA, TCCA, and other aviation authorities, has published a position paper with guidance for multicore systems called CAST-32A. The INTEGRITY-178 tuMP multicore RTOS supports robust partitioning as defined in CAST-32A, which allows system integrators to determine the worst-case execution time (WCET) of an application without any other applications executing. This avoids retesting and reverification of the entire system when any single application changes.

INTEGRITY-178 tuMP includes a Bandwidth Allocation and Monitoring (BAM) capability developed to DAL A objectives to observe interference channels and mitigate them. Based upon more than 60 man-years of research and development into multicore interference analysis and mitigation strategies, BAM monitors and enforces the bandwidth allocation of the chip-level interconnect to each of the cores, thereby controlling access to all 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 running on core 0, for example, can be allocated a set amount of resources, such as 60% of the total bandwidth, while the other 3 cores could be allocated only 15%, 15%, and 10% respectively.

Unlike competing solutions that use a coarse time threshold merely to provide a safety net, BAM time quantums approach that of a hardware timer. In that way, BAM effectively mitigates high resource usage of properly functioning applications instead of just malfunctioning or malicious applications.

Once the bandwidth from the interfering cores is limited, the execution time of the application comes back under control and remains nearly constant as the number of interfering cores increases. When the application on Core 0 is allocated 60% of the total shared-resource bandwidth, execution takes only 2.5 times longer than when it runs by itself and maintains approximately that execution rate when one or more interfering cores run simultaneously. Larger bandwidth allocations can reduce the WCET further.

Using this mechanism BAM enables system integrators to identify and mitigate interference on multicore-based systems and directly addresses the CAST-32A guidance, greatly lowering integration and certification risk. BAM also allows system integrators to achieve their SWaP objectives by enabling optimal core utilization. When coupled with Green Hills Software’s multicore SoC-specific WCET utility libraries, BAM ensures that critical partitions meet their required deadlines while enabling other lower criticality partitions to execute on other cores simultaneously with no impact on the critical applications. This remains true even as the other partitions are modified or as new partitions are introduced into the system. This is a vital capability for sustainment and growth of critical systems based on multicore architectures.