The decreasing relative cost of electronics and the pace of electronics development have significantly increased the need to adopt modern commercial off-the-shelf (COTS) computing architectures in avionics.
Increasing demand for energy efficiency and performance has led to the adoption of multicore processors, and especially multiprocessor system-on-chips (MPSoCs), in the avionics domain. The problem of leveraging COTS hardware in avionics, however, is manyfold. Guidelines on certification of COTS hardware originating from its high integration level confer to a certification memorandum from the European Aviation Safety Agency (EASA). Yet, MPSoCs potentially also introduce additional problems related to isolation of functionally disjoint functions.
In the past, increased integration led to centralized avionics systems called integrated modular avionics (IMA). Advantages include lower purchasing cost, lower size and weight, reduced power needs, and lower maintenance costs.
In contrast to pre-IMA systems, IMA integrates functions of different criticality on the same set of resources. To keep safety aspects simple and thus feasible, unrelated functions should be segregated from each other and ideally run in separated environments. These concepts of time and space partitioning are defined, for example, in ARINC 653.
The partitioning concept comprises spatial and temporal separation. Spatial separation ensures that partitions are not able to access other partition's memory spaces, whereas temporal separation guarantees that partitions do not influence each other's timing behavior. In general, partitioning ensures that applications have the same behavior on IMA systems as in separated platforms. Multicore processors introduce some challenges regarding temporal isolation, originating from physically shared resources, such as network on chip (NoC), shared caches, and memory controllers.
According to the EASA, most existing MPSoCs are classified as “highly complex micro controllers.” Most of the existing MPSoCs were not designed with a special focus on certification and fall into this category.
Engineers from EADS addressed multicore solutions in aerospace applications to evaluate a TTNoC (time-triggered NoC) solution in the context of a helicopter landing aid application. The main goal was to create a sample mapping to a prototype, integrating and leveraging fault tolerance approaches as well as domain-specific standards. This work was performed as part of a public research project called ACROSS (ARTEMIS Cross-Domain Architecture).
The referenced helicopter landing aid system is an implementation of a degraded vision landing aid (DEVILA), a system designed to support helicopter pilots when landing in a desert environment with limited visibility. Visibility is limited since the air downstream from the rotor causes sandstorm conditions, which are also known as “brownout.”
To give the pilot an aid for orientation, a set of symbols is shown in the head-up display, which provides information such as a horizontal line or altitude. This increase of safety is especially needed when starting or landing the aircraft. In those critical phases, many accidents take place, which can be avoided by providing the pilot a synthetic-vision aid based on information collected from the inertial navigation system and radar altimeter system.
The main goals of the research were to learn about the ACROSS MPSoC abilities, particularly in respect to the following:
• Meeting hard real-time schedules (determinism)
• Integrating fault tolerance (different cores and partitions)
• Integrating different applications with different criticalities (IMA)
• Integration of domain-specific standards (e.g., ARINC)
A helicopter flight-data simulator was implemented using a COTS PC. The data from the various aircraft sensors were generated by a helicopter model inside the flight simulator. An aircraft data bridge extracted the information from the flight simulator via universal inter-process communication. It emulated the timing behavior of a real helicopter by assigning each parameter of the aircraft sensor data a specific timing behavior (i.e., a delay and an update rate). It then started encoding the information to ARINC 429 data format.
The ARINC 429 converter realized the data transfer of the encoded data to the ACROSS processing unit. It thereby relied on an ARINC 429 interface card.
The landing aid system was implemented on MPSoC inside the ACROSS processing unit. The landing aid system's main functionality was split over four micro components (µComponents) of the MPSoC.
The first µComponent (I/O gateway server) was responsible for filtering and forwarding input data from aircraft sensors. The second µComponent (algorithm) processed the received input data. The third µComponent (symbol) generated the synthetic vision for the pilot. And the fourth µComponent contained the system and the configuration management. It is responsible for health monitoring, system start-up handling, and compatibility checking.
Testing showed that the ACROSS MPSoC helped fulfill essential requirements needed in the aerospace environment. In particular, the segregation properties needed for integrating different criticality applications and a clear design structure helped in proving the design correctness of integrating applications.
Implementation of functional blocks of the MPSoC is relatively simple and provides a good basis for hardware assurance needed in aerospace. The current implementation on an FPGA has been proven sufficiently fast for the presented application. For more integrated approaches, however, more performance using higher-grade FPGAs and different cores may be needed. Additionally, a chip solution (or chip-like solution) would likely be needed for use in harsh aerospace environments with high single event effect rates.
This article is based on SAE International technical paper 2012-01-2117 by Michael Paulitsch, EADS Innovation Works; and Dietmar Geiger, Bernd Koppenhoefer, and Peter Ganal, EADS Cassidian.