Single-Core processors and controllers have been the de-facto standard for aviation software since the early beginnings when computers were utilized in flight systems. This is primarily due to their simple design and determinism of execution. At first glance, it seems comprehensible that a flight computer that takes control over a critical safety system should be dedicated to that task only. Certification authorities, such as the European Union Aviation Safety Agency (EASA) and the Federal Aviation Administration (FAA), have substantiated that point of view by not allowing to certify flight systems that support more than one active processor core (RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware, published by RTCA Incorporated. The European denomination is EUROCAE ED-80).

Interested in technical stuff regarding the implementation of the demands of CAST-32A? Download our whitepaper:
www.sysgo.com/wp-cast32a

New Technology infuses Planes

However, the development of electronic hardware has progressed and has led to more sophisticated and centralized systems like Integrated Modular Avionics (IMA). On the software side, this approach has been backed up by the introduction of operating systems that support robust time and resource partitioning. Expert of transport communications Aeronautical Radio Incorporated (ARINC) published the ARINC653 standard which defines the execution of applications with different software levels of criticality on the same CPU by confining the processes into static partitions, separating resources and processor time. This standard is widely accepted by certification authorities and many airborne flight systems have adopted the described method of partitioning. Nowadays, it is considered as good practise to centralize software into one hardware platform, even when multiple systems are affected.

With the success of the partitioning model and Multi-Core processors becoming more present, the certification authorities have started to broaden their level of acceptance. A first step was taken by the EASA, starting a research project on multicore processors in airborne system. The study was carried out by Thales Avionics and can be found under the name MULCORS.

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 – namely 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, that files the certification (henceforth called applicant), 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 such as PikeOS have already tightly incorporated Multi-Core support into their partitioning management. In the following, we will discuss the topics of the CAST-32A paper and look into their realization within SYSGO’s operating system PikeOS.

The CAST-32A publication is a positioning paper. It is not a strict guideline nor standard, but rather a tool to help the applicant making the right decisions. The document’s structure can be broken down into the sections “Planning”, “Interference Channels and Resource Usage”, “Software Verification” and “Error Detection and Handling”.

Claims of CAST-32A already implemented in PikeOS

The section “Planning” discusses all topics related to the choice of processor, architecture, operating system and tools. It starts with the applicant’s responsibility to identify the Multi-Core Processor (MCP). In case of PikeOS, this MCP identification has already been completed for a number of platforms on different architectures, such as x86, PPC and ARM. All MCPs have been tested on PikeOS with the maximum number of cores activated, which gives the applicant any freedom to the identification of the number of active cores. In terms of planning, CAST-32A furthermore requires the applicant to take care for the software architecture (including IMA considerations), the resource partitioning model and the development tools to be used. As the documentation of the PikeOS system fulfils the requirements for certification relevant, there is a solid base for the applicant’s system architecture. Any Multi-Core scheduling use case can be seamlessly realized on a high abstraction level by means of PikeOS mechanisms (namely time partition schemes). PikeOS itself is designed to satisfy any Symmetric Multiprocessing SMP) and Asymmetric Multiprocessing (ASP) needs, but the tooling even also allows to build systems, that are in between. The PikeOS documentation progressively enters upon CAST-32A issues and guides the applicant to build compliant and robust systems, also in regard of IMA systems.

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”. This section’s content keeps explanations on a very high abstraction level. 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. In the following, we will focus on two concrete contentions, namely the impact of the shared processor cache and the main memory bandwidth.

Processor cache is a mechanism to increase the performance of a CPU significantly. It temporarily holds copies of content in the main memory, enabling the CPU to operate on data that is in use frequently without having to utilize the relatively slow memory bus. Most CPUs have a hierarchical composition of caches with different levels (L1 – L4). The low-level caches usually are dedicated to a certain core, but the higher-level caches are shared amongst the processor cores. As a result, the hardware of the CPU has to deal with synchronization issues, if a shared cache is involved. 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.

In terms of PikeOS, the cache handling is implemented in a CPU-hardware specific component, called Platform Support Package (PSP). Generally, PikeOS PSPs provide enough flexibility to allow the partitioning of shared caches, e.g. by assigning different sets of a multiple-way associative cache to individual partitions, if supported by the hardware.

The Solution to Memory Conflicts to handle Tasks just in Time

In order to be prepared for worst case scenarios, PikeOS provides the technical means to implement monitoring of the cache bandwidth in order to shut down erroneous applications. Apart from these technical methods applicable at runtime, the applicant still has 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 is 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.

Fig. 1: Recommended Time-Partition scheme for applications with strong need for determinism

Another source of interference is the main memory bus. Although the memory areas are protected against each other by means of the PikeOS partitioning model, 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 Granular 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 OS services. In order to reduce the impact of this kind of interference channel, PikeOS uses fine granular 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. The PikeOS development supports the user by providing information on memory budget and execution time by means of tracing tool based on instrumented versions of the PikeOS kernel and user applications.

Finally, is worth mentioning, that the CAST-32A is not applicable in all situations. Processors with multiple cores activated in lock-step mode are explicitly excluded. Those systems have been designed for safety critical systems and are already in use long before the CAST-32A paper has been published. Lock-step processors however, are supported by PikeOS anyhow and already used in various airborne applications. In addition, CAST-32A is not applicable for CPU cores seemingly multiplying their performance by means of hyper threading.

Summary

The Certification Authorities Team (CAST) group has sketched the way to usage of multiple processor cores in avionic systems. Their positioning paper CAST32-A 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.

More information at www.sysgo.com/rtos-safety