2

Methodology for Rapid Prototyping Avionic Software

This second chapter will first present the specificities and the restrictions of the avionic domain in terms of both its functionalities (security, safety and system virtualization) and standardization (the need for a complete certification of the final system). Taking these specificities into account, a methodology of rapid development has been produced and will be presented in section 2.3. This methodology will be first described in the abstract and a list of its advantages will be given. Second, examples of tools enabling the implementation of its different stages will be provided. Specifically, the organization of the target architecture for the avionic software to be produced, modeling and transforming models into software source code will be described. Nevertheless, this instantiation example of our methodology is not unique and to conclude other examples of tool chains that can be used to meet the specific needs of each software product will be given.

2.1. The specificities of the avionic domain

The improved performance of aeronautical systems currently enables us to envisage the use of new technologies in the context of onboard aeronautical systems as well as avionic networks which to this day have remained closed to ensure their security and safety being opened up to public networks such as the Internet. With these new technologies come new security needs. Meanwhile safety must be maintained.

We therefore decided to work on a Secure Next Generation (SNG) router. This router enables the critical streams (such as communication between the pilots and controllers) to be multiplexed (as illustrated in Figure I.1 in the introduction) with uncritical streams (streaming for passengers) in one channel of communication and guarantees the security and safety of communications.

2.1.1. System virtualization: integrated modular avioni
cs

The first generations of avionic software systems were based on the direct relationships between systems: when a sensor transmitted information to two onboard computers, the data were duplicated across two independent channels of communication, each with its own receiver. The arrival of new technologies provided crews with new services and introduced new interactions.

Figure 2.1 depicts an Integrated Modular Avionics system (IMA, see [GAT 09]), which executes several independent software systems within the same hardware module. Entitled Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, the RTCA norm DO-297 [DO 05] of 8th November 2005 provides regulation on the design and the implementation of systems for IMA architectures in civil aeronautics. Prepared by the Special Committee 200 (SC-200) group, this norm defines IMA as a shared set of flexible, reusable and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of safety and performance requirements, [shared set designed] to host applications [on the hardware] performing aircraft functions. This norm explains and separates the roles of the different suppliers of IMA modules: application suppliers, suppliers of IMA platforms, system integrators and certification agents.

Figure 2.1. The concept of IMA

2.1.1.1. ARINC 653 APEX interface: application executive

In 1996 ARINC published the ARINC 653, a standard describing a programming and configuration interface that facilitates the independence of avionic applications with regards to hardware. The standard is called the ARINC 653 APEX (Application Executive). In 2003 an update was published that introduced IMA. The most recent publication (ARINC653P1-3, ARINC653P2-2, ARINC653P3, RINC653P4), in 2006, com
pletes the previous version by clarifying certain points.

This concept therefore avoids duplicating physical connections: one bus destined for the hardware transports the multiplexed data for the different software applications. The growing number of avionic systems has, however, continued to require interconnectivity between systems, each of which potentially has different restrictions.

2.1.1.2. AFDX bus: Avionics Full-Duplex switched ethernet

The development of the Airbus A380 increased the need to move toward the scale of communication mechanisms between systems. This resulted in the introduction of the Avionics Full-Duplex switched Ethernet (AFDX, see [LAN 09]). The AFDX is a network protocol at the data link level (layer 2 data link of the Open Systems Interconnection [OSI] model), based on the reliable and redundant Ethernet protocol which enables the generic transmission of data between emitter and receiver systems. AFDX systems are therefore connected by a standardized Ethernet interface. Data are contained in the Internet Protocol (IP) packets, which are transmitted into the Ethernet frames. AFDX switches ensure the direction of the frames within the AFDX network.

However, the size of the topology of an AFDX network is limited by technology. The current closed network of the A380 contains a hundred or so terminal nodes which represent large amounts of work in terms of administration and certification. In addition, specific research is required to optimize the performance of this avionic network. Opening up this network to external data increases the number of potential nodes in the network. At a higher protocol level than that of the AFDX, the IP protocol (level 3 network of the OSI model) offers the opportunity to increase the size of virtual networks by maintaining acceptable-sized physical networks at the lower layers. The IP protocol is linked to routing functionalities: while physica
l routing (the switching of frames) is realized at level 2 by AFDX switches, virtual routing (packet routing) is possible at level 3 using a network component known as the IP router. We have worked to design, realize and validate this type of router.

2.1.2. MILS: divide and conquer, to rule over a secure world

The segregation of the guests (see Figure 2.2 for example), brought about by a virtualization solution, has led to it being used to strengthen the security of sensitive systems.

The Multiple [and] Independent Levels of Security [/Safety] (MILS) architecture concept has come about gradually. Based on John Rushbys [RUS 81] concept of separation kernel, an MILS architecture guarantees a high level of security for the execution of programs in the same infrastructure.

Indeed, a founding principle of the engineering consists of decomposing a complex task into several more simple tasks. In computer science, this concerns decomposing/dividing a piece of software into modules. The evaluation of security is thus simplified because the evaluator does not need to evaluate a complete monolithic system but rather a set of smaller distinct modules and their couples.

Implementing a virtualization solution to realize the support of an MILS architecture is acceptable if it is proven to guarantee the four intrinsic properties of MILS:

These properties are gua
ranteed by evaluating the security of the solution [OMA 05]. Evaluation is complex for small systems; and it is just as complex for minimalist systems (micro-systems), which are dedicated to system virtualization and their separation, known as separation micro-kernels. These separation kernels ensure that temporal and spatial separation concepts between programs and the control of information stream are implemented.

The kernel ensures that each program and its virtual machine can use the real resources during the time that is assigned to them. A program cannot encroach upon another and steal its execution time. We therefore speak of the temporal separation between the two VMs.

The kernel also guarantees that a real-resource cannot simultaneously be assigned to two virtual machines. Address spaces for the memory and the input/output are shared during the configuration of the separation kernel: this is known as the partitioning of the address space. Then each time a resource is accessed, the kernel verifies that the virtual machine has authorized access and blocks the access attempt where necessary. The kernel therefore ensures the spatial separation between VMs.

Similarly, VMs can have channels dedicated to intercommunication. These channels are managed by the separation kernel (and not directly by the underlying electronics). The kernel then ensures the form of the communications: verification of the maximum length of the messages sent, access authorization, marking received messages, etc.

Figure 2.2. Architecture of a MILS system

As illustrated in Figure 2.2, each virtual machine in a MILS system is executed independently of its homologs. Seen from the host...