Home>Design & Prototyping Test Center>Test How-To
Testing aircraft AFDX systems
William D. Wargo and Joachim Schuler, AIM- April 26, 2012
|
With the adoption of the AFDX (avionics full-duplex switched Ethernet) standard network, all devices can communicate on a single bus at much higher data rates (1000 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 for addressing AFDX test.
What is AFDX?
Using a special protocol to provide deterministic timing and redundancy management and to provide secure communications of data, AFDX is an avionics data network based on commercial 10/100-Mbps switched Ethernet. Its communication protocols were derived from commercial standards—IEEE 802.3 Ethernet MAC, IP (Internet Protocol), and UDP (User Datagram Protocol)—to achieve the required deterministic behavior for avionics applications.
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 functionality is defined in ARINC 664 Part 7.
End systems, or LRUs (line-replaceable units), communicate based on VLs (virtual links) with traffic shaping through the use of BAGs (bandwidth allocation gaps), which are the minimum intervals between transmitted Ethernet frames on a VL. AFDX switches have functions for filtering and policing, switching (based on configuration tables), and end-system and network monitoring (Figure 1).
|
This new standard is already being deployed. The Airbus A380/A350/A400M, Boeing B787 Dreamliner, Comac ARJ21, and Sukhoi Superjet 100 all use AFDX data communications. In addition, AFDX and ARINC 664 Part 7 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 April 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.
Test systems for AFDX
The ideal test system for AFDX should be able to monitor all traffic, modify the data, and report results (Figure 2). A platform that combines a network “tap” (which can act in multiple modes), one or more dual-port simulation/analysis modules, 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.
|
Here are some valuable tools that an AFDX test system should include:
• Tapping capability. In-line monitoring of AFDX traffic can be useful when debugging networks. Compared to grabbing data from a monitoring port of an AFDX switch, in-line monitoring requires taps, which are ideally nonintrusive and can deliver time-stamped AFDX traffic representing the traffic as it appears on the line. Because AFDX defines redundancy by a duplication of the network connections (“red” and “blue” in Figure 2), in-line monitoring basically 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 AFDX network, up to two nonredundant independent AFDX 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 AFDX-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 like traffic and received by an end-system simulation. Through synchronization, all generated (simulation interfaces) and capture traffic (by the tap) can be correlated.
• Latency measurement. When integrating complex AFDX and 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 sent as part of the payload, allows a time-synchronized receiver to determine the latency through the network. Some AFDX and 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. As a result, it is as important to test end-system responses to both erroneous and valid data. It is not usually feasible to modify software in each of the various system components to introduce errors onto the bus. So, the best way to perform this testing is to have a “test” device in-line so that events on the bus can be modified at will to emulate error conditions.
One solution to this problem is AIM’s REROS (re-routing software) functionality, which is executed on an AFDX interface board under control of an RTOS (real-time operating system). The functionality starts with a configurable re-routing of AFDX frames, based on VL numbers, to the network ports on the same interface board or to network ports of AFDX interface boards on the same backplane (PCI/CompactPCI). As a functional extension, the AFDX frames can be modified prior to retransmission in order to introduce physical errors or modify frame data (MAC addresses, IP header, UDP header, AFDX payload). Rerouting can happen as fast as possible or with a configurable delay, to compensate processing and transfer times when re-routing is done across several interface boards. The REROS functionality is typically supported and fully configurable using the corresponding application software.
The transition from simple point-to-point 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 AFDX 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 AFDX systems, and these tools can greatly increase efficiency in the development of new systems. T&MW
William D. Wargo, president of AIM-USA, has been engaged in aerospace electronics for 30 years, working in engineering, business development, program management, and general management. Prior to joining AIM-USA, he held the position of VP of airborne telemetry for L-3 Communications, Telemetry-East Division. Wargo holds an MBA from LaSalle University and a BS in electronics engineering technology from Capitol College.
Joachim Schuler became the managing director of AIM GmbH in January 2010. He received his engineering and technical computer science degrees in 1991 and began his career in software development at Siemens Automation. After two years, Schuler joined AIM as a software development engineer. He became leader of the AIM software development team and served as technical leader and project manager for such projects as ARINC 664 end-system and switch-compliance test-system development and AFDX/ARINC 664 test-tools development.
