As Avionics Full-Duplex Switched Ethernet (AFDX) rapidly emerges as the standard network for avionics systems, network analysis tools must be enhanced to fulfill both commercial and avionics requirements.
Bus analysis in a nutshell
The activities of a full-featured bus analyzer can be divided into three categories:
1. Logic-analyzer type functions – These include the ability to trigger, enabling the user to set up separate files, based upon certain activity patterns or events that occur on the bus. This is more logic-analyzer related than protocol-related. Another logic-analyzer type function is the ability to save and present errors or RG7 (terminal types) – and also display percentage of bus loading and percentage based on individual terminal communications.
2. Protocol analyzer type functions – These include the ability to filter, which means the analyzer can be programmed to discard words or messages that are totally unrelated to bus analysis.
3. System-level troubleshooting – This is based upon interpretation and therefore the ability to interpret the bus data and set upper and lower boundaries. System-level troubleshooting denotes that data that is being transferred. For instance, a user may set up upper and lower limits so that whenever a certain word occurs more than 500 or less than 45 times, an alarm will be sent.
Other valuable features include:
Archiving traffic – Another desirable feature is the capability of archiving traffic off the bus, which means the user can play back a particular activity. This is such an invaluable feature because observed problems can be recreated by rerunning it repeatedly to facilitate appraisal of how the data is performing. A related feature that can be found on some bus analyzers is the ability to play back to the interface bus, the screen, or both.
Different vantage points – When examining protocol and performing system-level analysis, it is important to be able to view activity from different vantage points. Bus analyzer tools provide the viewer with many different ways to look at the protocol and perform system-level analysis. This data watch feature enables data graphing, which makes it much easier to identify patterns. The user also wants to be able to filter out message types that are not important so they do not detract from the essential aspects of the analysis. Also valuable are comparative windows of activity at different points of the bus traffic.
Users may want to compare the message or the data. For instance, with some analyzer tools, such as BusTools/AFDX, users can request a sequential view, which displays data that occurs contiguously within an inverted stack. It displays the first message recorded, followed by a sequence of other messages that followed the first message. This is sometimes called a sequential view or a stacked view.
Simulation ability – Bus analysis software users may want the analyzer to simulate the bus controller, or a remote terminal. This means users can program-up various bus components with data and errors that can then be used to stimulate other components on the bus to learn how they will respond.
Ethernet technologies permeate today’s world, and aircraft systems are no different. Most new commercial, and several military aircraft have now adopted AFDX, officially known as ARINC 664, Part 7, as a backbone network for their avionics systems. As with any avionics system, data packets between computers need to be transferred with precise frequencies and exhibit extremely high-data accuracy. However, to properly troubleshoot and qualify such a system, the design engineer must have a network-analysis tool that can function at the highest level at full-rate error monitoring, data recording, real-time data analysis, and traffic transmission.
Requirements of ARINC 664
An ARINC 664 system is essentially a 100-BASE-T switched network where the protocol layers (Ethernet, IP, and UDP) are modified to provide unique addressing and data management for the various avionics computers. The fail-safe of the network is a unique switch that polices the network traffic to ensure that no computer or subsystem of a computer violates preassigned bandwidth allocations. For an actual aircraft system, the ARINC 664 switch is critical to ensure that any particular avionics computer, or Line Replaceable Unit (LRU), does not start to babble on the network and disrupt the critical timing of avionics data packets.
In a typical avionics integration laboratory, however, a common network switch is often used because the LRU rarely, if ever, will violate its allocated transmission bandwidth and real flight hardware is expensive to have scattered around the lab room. But ARINC 664 networks can become heavily loaded, by system design, and this places a heavy burden on the analysis equipment to accurately read and time stamp all data packets and be able to replicate network traffic with high precision. Therefore, the ideal network analyzer must be able to present and replicate an accurate picture of system data patterns.
Fortunately, modern PCs have plenty of processing bandwidth to record and dissect data packets of fully loaded ARINC 664 networks. The problem is that modern PCs still implement low-fidelity Network Interface Cards (NICs) and most standard office or communication systems rely on Transmission Control Protocol (TCP) to manage quality of service (retransmission) of dropped packets. Standard NICs are not required to provide high-resolution time stamp in nanoseconds and high-resolution packet transmission. Avionics systems require near 100 percent data transmission accuracy at precise, regular frequencies, whereas office and communication systems are relatively much less demanding and their PCs and Windows or Linux operating systems do not build to these higher-end requirements. Consequently, the ideal PC-based ARINC 664 analysis tool must overcome the Ethernet processing shortcomings while utilizing a high enough processing capability to fulfill avionics engineers’ demanding requirements, while still retaining PC pricing.
The ideal bus analyzer for AFDX
There are a number of essential features for AFDX. These include auto-discovery, simultaneous real-time monitoring and logging, advanced filters and triggers, a data-centric analyzer, AFDX traffic generation, and header protocol format analysis.
Auto-discovery – The auto-discovery feature provides the user with an immediate overview of all network traffic. Utilizing a familiar Tree view, as depicted in Figure 1, the user can instantly drill-down through adapters, end systems, VLs, and ports to quickly survey the network configuration. Then by simply selecting the level one wishes to view and right-clicking, the software will respond with an immediate context menu access to packet summaries, and dissected packets – MAC/IP/ UDP headers, message structures – as well as raw hex data. Each data layer is presented in a resizable window that can be easily altered to meet individual user requirements.
Figure 1
Simultaneous real-time monitoring and logging – This feature combines analysis software and a two-channel CNIC interface to enable the user to employ the power of a pipelined DMA architecture. The reason is that this software/interface combination is able to simultaneously support real-time monitoring and log fully loaded traffic into disk storage. The user is then able to apply message structure definitions, then monitor data elements in real time with engineering unit displays, as depicted in Figure 2.
This data monitoring also means being able to view real-time statistics – packet count, byte count, and bandwidth – as well as the ability to capture, view, and dissect data from multiple levels simultaneously in engineering units or hex. Received packets are then time-tagged with high resolution, typically on the order of 20 nanoseconds for analysis or playback. This enables logged data to be replayed or looped with accurate timing.
Advanced filters and triggers – Advanced filtering and triggering functionality is supported by a simple and intuitive user interface. As with many of the other features of the analysis software, filters and triggers are structured in a hierarchical fashion, in the form of Trees. Filters can be used to screen the packets according to complex Boolean rules and then can be employed during network traffic capture, both at the protocol level and at the data-element level.
Triggers associate a condition with an action. They utilize filters for activation and for data reduction to easily detect irregular conditions or to automate recurrent tasks.
Data-centric analyzer – An analysis software package should utilize a message structure/dataset/datatype architecture for managing ICD information by translating packet payload data into engineering unit information. This enables packet headers, payloads, and message structures to be examined in a capture viewer while the various data elements are displayed simultaneously in real-time monitor viewers. In addition, advanced Boolean logic-filtering tools can then be applied to message structures – and intuitive, drag-and-drop techniques may be used to manually create AFDX datasets, message structures, and port assignments.
A highly user-friendly GUI can present captured/logged AFDX data in a three-panel, user-configurable viewer. As depicted in Figure 3, the top panel can then provide a list view where each row summarizes corresponding identification for each packet. The middle panel would contain a dissection of an individual packet selected in the top panel. Header and payload information – in engineering units, if message structures have been applied – can be displayed in the middle panel. Finally, the bottom panel can display a hex dump of the packet selected in the top panel.
AFDX traffic generation – An AFDX bus analyzer must be able to accurately replay or loop previously captured log files. To quickly create new files, filters would be applied while replaying a file and then by logging again, a revised file would be created for traffic generation.
Header protocol format analysis – The user wants to be able to analyze AFDX header protocol formats. This means that there should be Boolean logic filtering tools that can be applied to reduce traffic while utilizing triggering applied to packet headers or message content.
(visit our sponsor below)
Why PC-based analyzers are preferable to box-based analyzers There are some distinct benefits of analysis software that runs on a PC and is therefore a PC-based analyzer, as compared with a box-based analyzer, which may be anything from a handheld to a rack-mount device. PC-based analyzers, such as GE Fanuc’s Windows XP/2000-based BusTools/AFDX, are not only able to perform protocol checking but also provide a simple and easy way of setting up terminals because of the Graphical User Interface (GUI) software that supports it. Also, it is easy to set up data streams and data buffers enabling the importation of information into spreadsheets such as Excel for spreadsheet and database manipulation, or to convert the data into a hexadecimal format. Another plus for a PC-based analyzer approach is that the companion software-based bus tools that are part of a PC-based analyzer are able to interpret data – such as performing engineering-unit conversion – which would be very difficult to set up in a box-based analyzer. There are still other essentials in a bus analyzer that are spelled out in the sidebar entitled “Bus analysis in a nutshell.”
Outlook: Analyzer systems, AFDX, and ARINC 664 Effforts to bring products to market that will employ bus systems that build upon AFDX and ARINC 664, Part 7 are well underway. Vital to product development are analyzer systems with features that are dedicated to the support of these two specifications. Such analysis software packages will undoubtedly play a crucial role in lowering costs and speeding these modern bus products to the market.
Richard Schuh is Avionics Products Manager for GE Fanuc Embedded Systems. He is responsible for the identification and assessment of new strategic growth initiatives for GE Fanuc Embedded Systems. Richard brings more than 17 years of senior management experience to GE Fanuc, much of which has been in the avionics market. Richard was V.P. of Sales at Condor Engineering for six years. Prior to joining Condor, he was Chief Operating Officer for Linux NetworX, a high-end cluster computer company. For eight years, he was also President of SBS Technologies' avionics division. Richard has a BSCS from National University and is an alumnus of Stanford's Executive Business Development Program.
To learn more, contact Richard at: GE Fanuc Embedded Systems
101 W. Anapamu Street
Tel: 805-965-8000
Fax: 805-963-9630
E-mail: Rick.Schuh@ge.com
Website: www.gefanucembedded.com/gef/avionics.php
AFDX is an Airbus trademark.
Related articles: Avionics
This content is temporarily unavailable. Sorry for the interruption. The specified file could not be found.
)
