Multicore Integration in Avionic Systems

Integration of multicore systems is rather new in the context of avionic systems. Even though there are many initiatives to enable multicores for avionic use cases, reality is still the use of single-core systems.

The reason for this are manifold regulations and the long product cycles: any product developed for application in airborne systems need to be certified. This certification is extremely expensive and, hence, once a system is certified it will be used for many years. Novel developments require a good reason that must be more than just higher integration. Moreover, if higher integration is an argument, multiple systems are affected. Accordingly, recertification must be done for all these systems, resulting in even higher cost.

Nevertheless, for new systems it is intended to reach a higher degree of integration. This includes the use of multi-core systems, requiring suitable regulations and development tools. The position paper CAST-32a published by the Certification Authorities Software Team (CAST) provides some ideas on which topics need special attention. When integrating multiple applications into a single multicore system, a major challenge is the extensive testing of the different functions inside the chip.

The usecase selected for demonstrating feasibility of the COEMS technology is a novel dual-core based network switch for aircraft cabin networks: to reduce cabling for weight, cost, and installation reasons, all cabin-related networks should be combined into a single physical net-work by using virtual separation. Therefore, a special network switch is under development (prototype see Figure) that implements the virtualization of the physical network and splits the shared network to the individual network domains.

The current implementation uses a Xilinx Zynq with two ARM cores as central processing system. In addition to that, the FPGA part of the Zynq is used for fast packet transportation. Today, the system executes only the mandatory switch application on one core, the second core is not used at all. To provide extra performance for application specific extensions, the second core needs to be activated. This means additional development and verification as well as certification effort, i.e. this is the perfect platform to test and evaluate the COEMS technology.

The used hardware provides a free connector that has
been equipped with an adapter board to be used as Aurora/Nexus interface (on the back side of the base board shown in Figure 1). Now, this hardware can be connected to the hardware observation device developed by partner Accemic. We expect to identify possible bottlenecks in the single core implementation when running only the switch in the first step. In the second step, we will extend the system to two cores and investigate the power of the static analysis and runtime verification.