The Evolution of Avionics Networks From ARINC 629 to AFDX

Suchithra G T MTech student, Digital Communication And Networking, GSSSIETW, Mysuru

Suchithrasuchi93@gmail.com ABSTRACT—Signaling and inter-system communication in avionics have been difficult topic ever since electronic devices were first used in aerospace systems. To deal with the challenges introduced by the widespread use of general purpose computing in commercial avionics, standards like ARINC 429 and later on 629 were published and adopted by the industry. While in industrial use, 429 has been adapted and extended very little since the standard was formulated in the late 1970s. 629 today cannot meet challenges and new requirements generated by the use of Integrated Modular Avionics and flexible system design. Because lower security and higher cost of ARINC 629 to overcome from these use AFDX. AFDX combines proven safety and availability functionality with modern Ethernet technology to be able to handle today’s requirements. This paper

outlines two of the most important avionics network architectures and aims at depicting the evolution of networking concepts and requirements over the course of the past 30 years. It mainly focuses on ARINC 629 and AFDX, the most prominent current and past standards. Key words: AFDX, ARINC 664, ARINC 429, Ethernet, avionics, security, safety.

I. INTRODUCTION Avionics Full DupleX Switched Ethernet (AFDX) is a standard that defines the electrical and protocol specifications (IEEE 802.3 and ARINC 664, Part 7) for the exchange of data between Avionics Subsystems. One thousand times faster than its predecessor, ARINC 629, it builds upon the original AFDX concepts introduced by Airbus. One of the reasons that AFDX is such an attractive technology is that it is based upon Ethernet, a mature technology that has been continually enhanced, ever since its inception in 1972. In fact, the commercial investment and advancements in Ethernet have been huge compared say, to ARINC 629 and other specialized data communications technologies. Signaling and inter-system communication in avionics have been a crucial topic ever since electronic devices

were first used in aircraft. Initially, simple sensory feedback and components like radar and engines needed to be interconnected with cockpit controls. As time progressed, more and more systems which produce and consume data were introduced in avionics, at some point becoming crucial for even the most essential tasks, such as steering and later fly-by-wire. To deal with these challenges in commercial avionics, standards like ARINC 429 (and later on 629) were drafted and adopted not just by individual corporations, but collectively by almost the entire industry [1, 2]. Today, ARINC 629 can be found in most active and retired aircraft series. While it is well-established in the industry, it has been adapted and extended little since the initial specifications were formulated in the late 1970s. In contrast to avionics standards, multiple technological revolutions have happened in the computer industry at a fast pace. Networking of computers aboard aircraft may have been unthinkable in 1970, while modern aircraft without any networked computers are very uncommon. Legacy avionics communication standards still reflect past views on computing [1, 3]. Ultimately, a modern networking architecture for avionics use should offer a maximum of safety, redundancy and security, as well as apply failsafe defaults. The resulting infrastructure should be efficiently maintainable, flexible and offer a solid foundation for software development. More recent standards reflect these demands, though few sawbroader use across the industry [4]. In contrast to the Internet, security and cost efficiency are not the key objectives in avionics; rather safety is. However, most modern networking standards are aimed at achieving traditional PC-world security objectives and only indirectly address safety requirements (by fulfilling traditional security objectives) [5, 6]. In ARINC 664 Part 7, also referred to as AFDX, standard Ethernet technology is extended and design objectives are built around safety.

II. ARINC 629 Modern digital avionics systems require a system capable of transporting microwave and millimeter-wave RF signals that carry digital data on board an aircraft . The high bandwidth-to-weight ratio, performance and

routing flexibility offered by the combination of single mode optical fiber and wavelength division multiplexing (WDM) are among the prime attractions justifying the optical network approach to on-board avionics communications systems . The ARINC 629 is a new standard for aviation industry for the transformation of digital data between avionics system elements. It was first introduced in May 1995 and is currently used on the Boeing 777, Airbus A330 and A340 aircraft. The ARINC 629 civil aircraft data bus standard has been developed as a successor to ARINC 429. It is used in the MAC layer protocol . By the concept of bus cycle, this protocol manages periodic and aperiodic traffic exchanges. Its unique feature is that there is no need for a bus controller and bus access is determined by each terminal independently .

A. ARINC 629- SPECIFICATIONS AND

CHARACTERISTICS ARINC 629 source transmits either broadcast or address specific message to all or specific receiver or sinks. If the sinks equipment needs to reply, each will need to be fitted with own transmitter and a specific physical bus for the same. The single pair of wire connecting LRUs works in full duplex mode. In 629 LRU may transmit and receive digital data using a standard protocol. The protocol is described as Carrier Sense Multiple Access/ Collision Avoidance (CSMA/CA). 629 is a dual redundant data bus architecture where two buses are hot standby to each other in a linear bus topology, Fig. 1. Each terminal can transmit 629 data to and receive data from every other terminal on the data bus, which allows much more freedom in the exchanging of data between units in the avionics system. The 629 data bus cable has an unshielded twisted pair of wires and can be up to 100 meters long. Remote terminals are autonomous and for timing synchronization each RT has independent transmitter and receiver PROM for sequencing the time.

Fig 1 ARINC 629 Data Bus Topology

To identify the labels of messages, PROM is available in each RT. This feature is not available in 429, where all these activities are done by master controller (MC). 629 have unique label word and each message has a source channel identification code (CID) which identifies the source of messages.

B. WORD FORMAT ARINC 629 20 bit data word format is shown in Fig. 2. The first three bits are related to word time synchronization. The next 16 bits are the data contents, and the final bit is a parity bit. Data groups transmitted by ARINC 629 are called messages. Messages are comprised of word strings, up to 31 word strings can be in a message. So, maximum 620 bits are possible in a word string.

Fig 2 ARINC 629 Digital word format

The ARINC 629 standard defines a multi-level protocol for inter LRU communications across a common, multiple access data bus. For the 777 project, Boeing developed ARINC 629, a higher-speed data networking solution, rather than continuing with ARINC 429. ARINC 629 is a bidirectional bus supporting data rates up to 2 Mbps with a maximum of 120 data terminals. The bus operates without the need for a bus controller each terminal is self monitoring, enhancing the reliability of the architecture. Although ARINC 629 reduced the amount and weight of wiring needed in an aircraft and increased the data rate over ARINC 429 by 20 fold, it requires custom hardware, which adds to the overall cost of the aircraft. In addition, ARINC 629 has not met with acceptance by other aircraft makers, increasing its costs.

III. AVIONICS FULL DUPLEX PACKET EXCHANGE

The solution to the new challenge is to use commercially proven hardware base technology and apply a protocol to it, capable of delivering the reliability in packet transport and timing. Asynchronous Full Duplex Switched Ethernet (AFDX) is based on standard IEEE 802.3 10/100 Mbit Ethernet hardware. This is a well known standard and it is widely used. The packets are enveloped as IP and UDP packets, a software protocol known from the internet. However, the base requirements for a

network for avionics applications are not covered by standard technology: • reliable packet transport • bounded transport latency Special extensions to the network protocol and a fixed topology are needed to meet these requirements. The AFDX protocol has been standardized by an ARINC working group. ARINC-664 describes aircraft data networks (AND) and part 7 specifically deals with AFDX.

A. FLEXIBLE NETWORK TOPOLOGY

Normal Ethernet technology uses a topology where each node is treated equally. If a peer wants to transmit a packet on the network and the media is occupied, a collision occurs, the peer backs up and tries again, until the transmission is successful, or a predefined amount of time has elapsed. This behavior introduces variable length latency, which is not tolerable in safety critical applications. In order to avoid collisions on the network, a switched full duplex topology is introduced.

Fig 3 AFDX Topology

Regular switches forward packets according to a connection table, which is build and updated while the switch is in operation; it “learns” and “forgets” about the

peers connected to it. Of course, this technique is very appropriate in a network with temporary peers that attach and detach from the net. The process of learning however, introduces variable latency and has to be eliminated in an avionic data network. Consequently, an AFDX switch forwards packets according to a static table. This is, in fact, a general policy in this network to statically define all peers and their respective network addresses. There is no address resolution protocol (ARP) necessary to resolve MAC addresses from IP addresses.

B. VIRTUAL LINKS

At the heart of an AFDX network is the virtual link (VL). Each VL builds a unidirectional logic path from the one and only source ES to one or more destination ESes. Each VL is allocated dedicated bandwidth, the amount

being defined by the system integrator. The total bandwidth of all created VLs cannot exceed the maximum available bandwidth of the network, and the bandwidth allocated to a given VL is reserved to that link. To accommodate less critical data communication needs, AFDX also allows for the construction of subvirtual links (sub-VLs). The data queues of all sub-VLs assigned to a single VL are read in a round robin sequence among the sub-VLs with data to transmit. Data from a single sub-VL cannot be split across multiple VLs. Although the bandwidth and latency of a VL are guaranteed, there is no guarantee for the sub-VLs. Note that from the Media Access Controller (MAC) layer down, a VL composed of multiple sub- VLs is handled the same way a single-data-stream VL is handled. The specification states that a VL queue is required to have the ability to handle four sub-VL queues at a minimum. The number of VLs a single switch can support is limited to 4,096. In a cascaded switch network, the total number of VLs in the system will also be limited by any links that cross switch boundaries. The specification does not specify a limit for the number of VLs a single ES can handle. However, based upon the maximum bandwidth allocation gap (BAG) value of 128 ms and the minimum of 1 ms, the total number of VLs through an ES is limited to 128 The specification does limit the number of sub-VLs that may be created within a single VL to four.

C. GUARANTEED SERVICE Fundamental to an AFDX network is guaranteed service: both the bandwidth and maximum end-to-end latency of the link are guaranteed. However, there is no guarantee of packet delivery. Transmission acknowledgements and retransmission requests must be handled at the application level.

BAG The primary bandwidth control mechanism is the BAG (Figure 4). The BAG defines the minimum time interval between the starting bits of two successive AFDX frames, assuming zero jitter. BAG values range from 1 ms to 128 ms (values must be a power of 2: BAG = 2k, where k is an integer). The BAG value, and thus the allocated bandwidth, for a given VL is determined by the system integrator as required by the application and equipment. BAG values for all VLs are stored in the appropriate ES and switch configuration tables.

Fig 4 Bandwidth Allocation Gap

Jitter The ES may introduce jitter when transmitting frames for a given VL. This jitter is defined as the interval from the

beginning of the BAG to the first sent bit of the frame being transmitted at the VL's maximum allocated bandwidth (Figure 5). This jitter may be introduced by the transmitting technology and the traffic-shaping function. A given ES may have to transmit data for multiple VLs, so a frame from one VL can be delayed up to the maximum allowed jitter value to limit the instantaneous ES frame rate and thus accommodate frames from other VLs.

Fig 5 Jitter Defined

D. FRAME FORMAT The AFDX frame format is shown in Figure 3. The destination and source addresses listed contain the MAC addresses for the ESes. Actual IP address information is contained in the IP Structure block. The UDP structure identifies the appropriate application port. The AFDX payload ranges from 1 to 1471 bytes. Payload sizes less than 17 bytes must be padded to maintain a minimum length of 17 bytes.

Fig 6 AFDX Frame

The one-byte sequence number is used to maintain ordinal integrity within a given VL. The frame sequence number is initially set to 0 upon ES start-up or reset. During continuous operation, the number wraps back to 1 after reaching a value of 255. The maximum frame size is set for each VL and is represented by the parameter LMAX. The range of this parameter is between 64 and 1518 bytes.

E. ADDRESSING AFDX network addressing is based upon the MAC address of each ES. ARINC 664 does not specify an algorithm for assigning MAC addresses. This task is left to the system administrator and must be compliant with

the IEEE 802.3 specification for locally administered addresses. The MAC address is 16 bits in length. In Boeing applications, the full 16 bits are available for assignment. In Airbus applications, only the least significant 12 bits are used, and the most significant four bits are set to zero. The source address must be a unicast address and follow the format detailed in the specification. The source address includes bits for identifying to which of the two redundant networks the MAC is attached. The destination address is a multicast address that includes a 16-bit VL identifier.

F. REDUNDANCY An AFDX network is constructed so there are two independent paths (including MACs, PHYs, and cabling) between each ES, as well as redundant switches to protect the network from a failure at the MAC level or below (Figure 7). The default mode is to transmit the same frame (with identical frame sequence numbers) across both networks. The receiving ES then accepts the first valid frame and passes it to the application. Once a valid frame is received, any other frame with the same sequence number is discarded. The redundancy option must be configurable frames for a given VL may be sent along either or both of the networks.

Fig 7 Network Redundancy

IV. CONCLUSION

Integrating with an Avionics Full-Duplex Switched Ethernet benefits the Defense Industry Avionics customer by lowering life cycle cost and accommodating increasing requirements. Not every platform will benefit from AFDX. The analysis must be repeated with the specific platform characteristics. A small avionics suite with only short messages can be integrated with ARINC 629 successfully at small costs and the highest reliability. AFDX is best suited for an IMA platform integrating high speed capabilities with traditional avionic equipment, with differing criticalities.

Future research will include specific platforms, specific criterion, specific characteristics, and laboratory demonstration. First, this research will be customized to a particular aircraft platform or Requirements Document. An actual cost and weight trade could be performed. A partnership with suppliers would encourage greater Commercial-Off-The-Shelf support. Second, each point of this paper could be examined further. The security and certification aspect requires a theoretical analysis.

Measures such as QoS can be further investigated to educate the systems engineer on what to expect when suppliers quote their performance. Third, a mock-up of the network using Avionics hardware could be accomplished in a System Integration Lab (SIL) to demonstrate its design benefits, marked. ARINC 629 ARINC 664

Topology (logical)

Bus Star

Duplex Half-Duplex Full-Duplex Medium Shared Shared

Speed 2 MHz 100 MHz Bandwidth Variable 3,000,000+

frames/sec

Latency Bounded Bounded QoS None Configurable

REFERENCES [1] P. Frodyma and B. Waldmann. ARINC 429

Specification Tutorial. AIM GmbH, 2.1 edition, 2010.

[2] Working Group. ARINC 615, P2: ARINC Airborne Computer Data Loader. Technical Report 1, Aronautical Radio, INC, June 1991.

[3] P. Frodyma, J. Furgerson, and B. Waldmann. MIL-STD-1553 Specification Tutorial. AIM GmbH, 2.3 edition, 2010.

[4] L. Buckwalter. Avionics Databuses, Third Edition. Avionics Communications Incorporated, 2008.

[5] Miguel A. S´anchez-Puebla and Jes´us Carretero. A new approach for distributed computing in avionics systems. In Proceedings of the 1st international symposium on Information and communication technologies, ISICT 2003, pages 579 – 584. Trinity College Dublin, 2003.

[6] N. Thanthry and R. Pendse. Aviation data networks: security issues and network architecture. Aerospace and Electronic Systems Magazine, IEEE, 20(6):3 – 8, June 2005.