Wander and wonder are two similar words, yeah and sometimes they confuse us. Yes, maybe not you all but I get bemused by their meaning sometimes. I think you wonder while you wander and you also wander around while you’re wondering. One morning, sitting on the terrace of my house and having my cup of tea, I looked up in the sky, numerous colorful kites were flying in the open sky waving at each other. As if they are saying Hello to each other and partying up high at those high altitudes.
Okay, let me tell you it wasn’t just any other morning, It was a festival we celebrate in India called Makar Sankranti (Uttarayan or Maghi or simply Sankranti) dedicated to the deity Surya (Sun) also known as The Kite Flying Festival. These aircraft flying at high altitudes have their language and they speak within themselves, and to each other just as we say hello to each other. Though, they speak with electrical signals, RF waves and have their sensors to feel their surroundings. Let’s now focus on avionics language, i.e protocol specifications.
Many commercial aircraft use the ARINC 429 standard, designed in 1977, for safety-critical applications. A unidirectional bus is used by ARINC 429 with a single transmitter and up to 20 receivers. Two transmission speeds are available: high speed runs at 100 kbit/s and low speed runs at 12.5 kbit/s. ARINC 429 operates in such a way that it communicates with its single transmitter in point-to-point communication, thereby requiring a significant amount of wiring that amounts to extra weight. Another standard, ARINC 629, introduced for the 777 by Boeing, offered higher data speeds of up to 2 Mbps and allowed a maximum of 128 data terminals.
Airbus developed and patented the (Avionics Full Duplex Switched Ethernet) AFDX® data network to fix real-time issues for safety-critical avionics applications, initially for the A380. AFDX® is one of the deterministic Ethernet implementations specified in ARINC Specification 664 Part 7.
The Airbus A350 also uses an AFDX® network, with avionics and systems supplied by Rockwell Collins, building upon the experience of the A380. Through the EADS Technology Licensing initiative, Airbus and its parent company European Aeronautic Defence and Space Company (EADS) have made AFDX ® licenses available, including agreements with Selex ES and Vector Informatik GmbH.
Aircraft Data Network (ADN) is a concept in the ARINC 664 Specification defined by the Airlines Electronic Engineering Committee (AEEC). Data networking standards proposed for use in commercial aircraft installations are recommended in this document.
The standards provide a way to apply Commercial off-the-shelf (COTS) networking standards to an aircraft system. It refers to devices and their use, such as bridges, switches, routers, and hubs, in an aircraft system. When set up in network topology, this equipment can provide efficient data transfer and overall avionics efficiency.
The specification of ARINC 664 refers extensively to the set of standards developed for data networking by the Internet community and IEEE.
Across several sections, the specification is organized as follows:
- Part 1 – Systems Concepts and Overview
- Part 2 – Ethernet Physical and Data-Link Layer Specifications
- Part 3 – Internet-based Protocols and Services
- Part 4 – Internet-based Address Structure and Assigned Numbers
- Part 5 – Network Domain Characteristics and Functional Elements
- Part 6 – Reserved
- Part 7 – Deterministic Networks
- Part 8 – Upper Layer Protocol Services
The physical layer consists of an Ethernet network of star topologies with End Systems and layer two switches. Using Virtual Links (VL) is the defining characteristic of the network. A logical data path through the shared network is specified by a VL. It describes a data flow from a single source to one or more destinations in one direction. 16 bits in the destination MAC address identify the VL. The switches use this to adequately route the frame.
The frame format of the AFDX® is IEEE Std 802.3 compliant. The frame includes addresses for defining the end systems of the source and destination, as well as the virtual link allocated. The length of the AFDX® frame may vary between 64 and 1518 bytes (plus a 7-byte frame preamble, 1 frame start byte, and 12-byte interframe gap, with a payload of data between 1 and 1471 bytes (payload must be padded to a minimum length of 17 bytes).
|7 bytes||1 byte||6 bytes||6 bytes||2 bytes||20 bytes||8 bytes||1-1471 bytes||0-16 bytes||1byte||4 bytes||12 bytes|
|Preamble||Start Frame Delimiter||Destination Address||Source Address||0X800 IPv4||IP Structure||UDP Structure||AFDX Payload||Padding||SN||Frame Check Sequence||Inter-Frame Gap|
A virtual link is a fixed path that originates from just one end system via the AFDX® network and delivers packets to a fixed group of end systems. ARINC 429’s physical point-to-point connections are replaced by virtual links, connecting sensors, and actuators to the control units.
Frames are routed using a Virtual Link Id by the AFDX® switch that is encoded within the MAC address of the Ethernet destination. Multiple virtual links can support the Ethernet connection on an end device. For transmission over the network, VL links are time-division multiplexed at the end system.
The total bandwidth is shared by each connection. Each virtual link is allocated two parameters to prevent packets on one virtual link from interfering with packets on another virtual link using the same physical link. The Bandwidth Allocation Gap (BAG) represents the minimum interval in the virtual connection between frames. The Lmax is the largest Ethernet frame on a virtual link that can be transmitted. For each virtual connection, those two values provide a bandwidth limit.
At the data link layer, the system integrator assigns each VL a MAC address. The 48-bit MAC destination address consists of a constant field of 32 bits (similar to all end systems on the network) and a VL of 16 bits. In the switch configuration, AFDX frames are routed by the switch to all destination end systems specified for the VL.
|Constant Field||Vitual Link Identifier|
|XXXX XX11 XXXX XXXX XXXX XXXX XXXX XXXX||NNNN NNNN NNNN NNNN|
The 48-bit MAC source address specifies the end system’s Ethernet controller originating from the frame. The first 24 bits of the address are assigned a constant value. The constant value is followed by a 16-bit unique controller identifier set by the device integrator.
A 3-bit value used to define which network the controller is connected to is after the 16-bit specific identifier (001 for network A and 010 for network B, all other values are not used). A constant is set for the final 5 bits: 00000.
|Constant Field||User-Defined Identifier||Interface ID||Constant Field|
|0000 0010 0000 0000 0000 0000||NNNN NNNN NNNN NNNN||NNN||00000|
With the growth of AFDX® is the emergence of Integrated Modular Avionics (IMA). Rather than providing dedicated hardware for each Line-Replaceable Unit (LRU), a standardized computing platform is implemented to run one or more avionics subsystems. As per Xilinx, it provides various embedded development platforms that offer versatility to designers concerning rapid prototyping and system verification such as ML410 (Virtex-4 FX) and ML510 (Virtex-5 FXT) series.
AFDX® endorses the Asynchronous Transfer Mode (ATM) concepts of the telecoms to overcome the limitations of IEEE 802.3 Ethernet. Deploying these extensions to the standard ethernet helps in defining a deterministic network for the avionics that offers a higher Quality of Service (QoS) and Bandwidth. These networks offer a higher degree of reliability over the single network schemes and operate at speeds of 10 Mbps to 100 Mbps.
AFDX® offers a lot to discuss on its design to implementation from its network management perspective, end systems to switch methodology adopted which are not feasible to discuss all together here. Take it, easy folks, I have respect for your curious minds, just follow my content and I would address these in the upcoming blogs. Yes, but for those having great ideas and plans in mind, you are most welcome to our place.
We design and offer solutions to your most critical problems and implementations. We as a team endorse our efforts, designs, and are defining the future of the FPGA in the field of avionics.