Testing Ethernet Based Avionics in Aircraft

Since the 1970’s, military aircraft avionics systems have communicated via the MIL-STD-1553 bus. This has proven to be a very effective method, and is still in widespread use today. MIL-STD-1553 is a time division multiplexed command and response bus with a bus controller initiating all communications on the bus. The bus operates at 1 Mbps, and is dual redundant for reliable operation.

Airbus Military’s A400M multi-role transport aircraft has completed a series of tests to validate the lowest speed at which it can take off. (Airbus S.A.S. 2011)

During this same time period, other communications standards were developed that greatly increased the throughput capability, but lacked the reliability and determinism necessary for real-time avionics systems to operate. The most popular of these standards in the commercial realm is Ethernet. However, the topology of Ethernet, by design, allows for multiple broadcasts, collisions and retransmissions. This has made Ethernet unsuitable for high reliability, time-critical applications such as avionics systems.

The commercial aircraft market made an effective transition to Ethernet based systems over the past decade by adding special protocol extensions to provide deterministic timing and redundancy management to provide secure and reliable communications of critical and non-critical data. The use of switched Ethernet implementations, therefore avoiding traffic collisions, has also been a key part of the migration of Ethernet into the avionics domain.

AFDX and its derivative, ARINC 664P7, is the predominant avionics data network used today in this industry. It is based on commercial 10/100-Mbps switched Ethernet. Its communication protocols were derived from commercial standards (IEEE 802.3 Ethernet MAC, Internet Protocol, and User Datagram Protocol) to achieve the required deterministic behavior for avionics applications. Also maintenance support, e.g. via SNMP and ICMP protocols, has been adopted. AFDX is a registered trademark of Airbus, which has filed several patents around this technology. The technology has become accessible via the public ARINC 664 standard, which describes the core technology of AFDX. In particular, the end system and switch functionalities are defined in ARINC 664 Part 7.

Figure 1. AFDX System showing Virtual Links

So called End systems (E/S), or LRUs (line-replaceable units), communicate based on VLs (Virtual Links) with traffic shaping by use of BAGs (Bandwidth Allocation Gaps), which are the minimum intervals between transmitted Ethernet frames on a VL. An additional Sequence Number, which is added to every AFDX frame, is another key element to support the AFDX concepts for traffic integrity and redundancy. AFDX switches, which are an important component of an AFDX network, incorporate functions for filtering and policing, switching (based on configuration tables), and end-system and network monitoring (Figure 1).

This field proven standard is already widely deployed in the commercial sector. The Airbus A380/A350/A400, Boeing B787 Dreamliner, COMAC C919 & ARJ21, and Sukhoi Superjet 100 all use Ethernet data communications. In addition, AFDX and ARINC 664P7 are being used as the backbone for all systems, including flight controls, cockpit avionics, air conditioning, power utilities, fuel systems, and landing gear. The first flight of the Airbus Industries A380 in Toulouse, France, on April 27, 2005, was a major milestone because it was the first flight with AFDX on board that was based on the commercial 100-Mbps switched Ethernet with deterministic behavior.

Figure 2. Ethernet/AFDX Test System

The Airbus A400M is the largest military use of the AFDX bus alongside the “traditional” ARINC 429 and MIL-STD- 1553, although many other Ethernet based systems are finding their way into aircraft sub-systems. In new flight control guidance systems, video processors all employ “proprietary” Ethernet based protocols.

With the adoption of the Ethernet based networks, all devices can communicate on a single bus at much higher data rates (100 times higher with the use of 100-Mbps Ethernet). This allows for much greater versatility and higher data throughput, so devices can communicate in real time. For the system designer, however, it introduces another set of challenges, since communications become time-division multiplexed, and timing must be controlled.

The added complexity also creates a greater possibility for system-level problems, and the architecture of the bus, which includes multiple links and systems, makes it difficult to troubleshoot an issue. There is no simple method for monitoring all the data traffic, since multiple data paths are possible. This has led test companies to develop innovative tools and techniques for addressing this formidable test challenge.

Test Systems for Ethernet Based Systems

All five next-generation A400M airlifters used for certification testing pose for an impressive “family photo” during a formation flight performed by the Airbus Flight Test teams on June 6, 2012 (Airbus S.A.S. 2012)

The ideal test system for an Ethernet system should be able to monitor all traffic, modify the data, and report results. A platform that combines a network “tap” (which can act in multiple modes), a dual-port simulation/analysis module, and a set of software test tools running on a PC can perform all the necessary testing and troubleshooting. This single configuration can monitor all traffic, modify and retransmit packets, change the destination of the packets, record data, convert the data into engineering units, and display the parameters (Figure 2).

Here are some of the most valuable tools a test system should include for testing and debugging Ethernet based systems:

Simulation capability: All the conceptual extensions of AFDX for achieving deterministic behavior of Ethernet traffic also require dedicated features on traffic simulation and monitoring equipment. Capabilities of proper traffic shaping including BAG scheduling and sequence numbering, as well as error injection features and redundancy support, are required on the simulation side and are ideally implemented on the interface level. On the receiver and monitoring side, especially the redundancy management, the handling of two associated physical network ports is a critical feature. This is required for simulation (of receiving equipment) as well as for monitoring and the evaluation of network behavior.

Tapping capability: In-line monitoring of Ethernet traffic can be useful when debugging networks. Compared to grabbing data from a monitoring port of an Ethernet switch, in-line monitoring requires taps, which are ideally nonintrusive and can deliver time-stamped Ethernet traffic representing the traffic as it appears on the line. Because Ethernet defines redundancy by a duplication of the network connections, in-line monitoring requires the monitoring of up to four Ethernet lines in total, two lines (Tx/Rx) per network connection. A tap such as the AIM fdXtap, for instance, can be used either to monitor one redundant Ethernet network, up to two non-redundant independent Ethernet networks, or even standard Ethernet networks.

The monitored lines need to be handled as four receive lines. Standard Ethernet test equipment offers taps but also often requires another four Ethernet ports to monitor the tapped traffic. With an Ethernet-specific tap device, the four monitored Ethernet lines can be uplinked to a host via a USB 2.0 connection and integrated into the application software, where tapped data can be handled in the same manner as all normal traffic and received by an end-system. Through synchronization, all generated (simulation interfaces) and captured traffic (by the tap) can be correlated.

Latency measurement: When integrating complex Ethernet networks with multiple switches, designers may become concerned about latencies. The capability of a network interface to transmit the time information, when the frame has been transmitted as part of the payload, allows a time-synchronized receiver to determine the latency through the network. Some Ethernet tools offer such capability by default. For example, on the application and driver software level, frames can be configured accordingly on the transmitter side. All received frames are time tagged, and the application software can decode them to deliver a measured latency time to the user.

Software: Aircraft networks carry data that is used by end systems to perform time-sensitive critical tasks. Any error in communication or the interpretation of data can produce malfunctions of prime aircraft systems. Due to this criticality, it is as important to test end system responses to erroneous, as well as valid, data.

It is not usually feasible to modify software in each of the various system components to introduce errors onto the bus. The best method to perform this function is to have a “test” device inline, so that events on the bus can be modified at will to emulate error conditions. A unique solution to this problem is AIM’s REROS (re-routing software) functionality, which is executed on an Ethernet interface board level under control of an RTOS (real time operating system). The offered functionality starts with a configurable re-routing of Ethernet frames, based on VL numbers, to the network ports on the same interface board or to network ports of Ethernet interface boards on the same backplane (PCI/cPCI). As a functional extension, the Ethernet frames can be modified prior to retransmission in order to introduce physical errors or modify frame data (MAC Addresses, IP header, UDP header, Ethernet payload). Rerouting can happen as fast as possible or with a configurable delay, to compensate processing and transfer times when rerouting is done across several interface boards. The REROS functionality is typically supported and fully configurable using the corresponding application software, such as the AIM fdXplorer and PBA.pro.

The transition from simple point-topoint systems to fully networked systems has provided a multitude of advantages to avionics systems designers. The added capability also has driven innovation in test techniques and tools. The first generation of Ethernet systems saw the test methods develop concurrently with the systems to be deployed. Today, off-the-shelf hardware and software tools are available that can fully test and verify Ethernet systems, and these tools can greatly increase the efficiency in the development of new systems.

This article was written by William D. Wargo, President of AIM-USA (Trevose, PA), and Joachim Schuler, Managing Director of AIM GmbH (Freiburg, Germany). For more information, Click Here .