Multi-Core Ready to Become Airborne

February 11, 2020


It is considered a good practice in avionics to centralize software into one hardware platform. De facto standard ARINC653 describes how this works properly.

It is considered a good practice in avionics to centralize software into one hardware platform. De facto standard ARINC653 describes how this works properly based on the partitioning model excluding and mitigating hardware resource conflicts. With the success of this model and Multi-Core processors (MCP) becoming more present, the certification authorities have started to broaden their level of acceptance of utilizing Multi-Core processors.

The CAST-32 Approach Opened the Gates for Multi-Core Processors…

With regard to that the Certification Authorities Software Team (CAST), an international group of certification and regulatory authority representatives (EASA, FAA), published a paper named CAST-32, describing the conditions, that would allow the use of Multi-Core-Processors in airborne systems. In essence, the paper identifies major topics that may have impact on the system safety and in most of the cases it turned out that determinism is the key. The final conclusion of CAST-32 is that Multi-Core processors may be used, but the scope was limited to a maximum of two active cores.

… but the Subsequent Development Actually Allows Utilizing Them Efficiently 

With the update of the CAST-32 document, CAST-32A (2016), this situation has changed. The parallel use of all cores of a processor in an airborne system becomes possible now. The paper explicitly allows the use of multiple cores, as long as the organization (applicant), that files the certification, can provide state of the art solutions for the issues mentioned. Those issues refer to aspects of the hardware design as well as matters of the software architecture. The latter requires a solid foundation by means of an appropriate operating system. Advanced operating systems have already tightly incorporated Multi-Core support into their partitioning management.

Challenges of Planning

The section “Planning” of the CAST-32A positioning paper discusses all topics related to the choice of processor, architecture, operating system and tools. It starts with the applicant’s responsibility to identify the MCP. Furthermore CAST-32A requires the applicant to take care for the software architecture (including IMA considerations), the resource partitioning model and the development tools to be used.

The Biggest Challenge: Managing the Shared Processor Cache without Conflicts

The most controversially discussed topic of CAST-32A is referenced as “Interference Channels and Resource Usage”. It leaves it up to the applicant to identify the interferences between applications, define the resource usage, and evaluate the impact on the deterministic behaviour of the overall system. Two issues, the impact of the shared processor cache and the main memory bandwidth are challenging the applicant to build the system.

Because high-level caches are shared amongst processor cores, the hardware of the CPU has to deal with synchronization issues. Furthermore, the state of a shared cache might be affected by an erroneous application, having a serious impact on the performance of a safety critical partition.

The Solution to Memory Conflicts to Handle Tasks Just in Time

In order to be prepared for worst case scenarios, CAST-32A compliant operating systems have to provide monitoring of the cache bandwidth in order to shut down erroneous applications. Apart from these technical methods applicable at runtime, the applicant should have the possibility to (almost) eliminate the cache effects at architecture level. The most obvious method is to increase the safety margins of the time partition windows, so that the worst-case execution time (WCET) can be met even when the shared cache is permanently unstable. While doing so, the performance will be significantly impacted. Instead, the applicant may order the applications into groups with same software level. By making sure, that safety critical processes are running in parallel, the cache can be invalidated at the start of the critical time frame. This should be similar to the situation on a single core processor, where applications are scheduled sequentially, performing a resource clean up on the start of the critical safety applications.Another source of interference is the main memory bus. Even if memory areas are partioned and therefore protected against each other, the access to the bus requires a certain amount of time. Intensive usage of the memory bus by one application is on the expense of applications running in parallel. This topic is very similar to the shared cache discussion and the mitigation measures are almost the same.

Fine Grained Locking and Clear Prospect

Contention may also occur when applications executing on different cores are entering the kernel space at the same time, potentially accessing the same data structures. Traditionally, the access to the entire kernel memory is protected by a global lock, allowing only one core at a time to execute operating system services. This might be technically sufficient but not satisfying in terms of scalability. In order to reduce the impact of this kind of interference channel, a well-compliant operating system has to use fine grained locking, that significantly reduces the probability of applications requesting the same lock at the same time.

In addition to the identification of the interference channels, the CAST-32A paper requires an analysis of the resource usage on a per core basis. For example, the applicant still needs to determine the WCET for a safety task under reasonable conditions and the safety margins must be defined eventually. The same applies to the analysis of the size of the memory areas. A good operating system has to support the user by providing information on memory budget and execution time.


The Certification Authorities Team (CAST) group has sketched the way to usage of multiple processor cores in avionic systems. Their positioning paper CAST-32A refers to aspects of the hardware design as well as matters of the software architecture. With the operating system PikeOS, the company SYSGO has delivered one of the major building blocks, extending robust resource and time partitioning to CPUs with multiple cores perfectly applying the described demands of the CAST-32A paper.