afdx overview

Avionics Full Duplex Switched Ethernet (AFDX) Bob Pickles SBS Technologies 05.18.2006

Introduction

This white paper provides an overview of the AFDX communications protocol

past, present and future. AFDX is the recent replacement technology for

ARINC 429. The gradual move to Ethernet and distributed computing in

commercial and military aerospace projects has hinted for many years at the

eventual development of AFDX. However, it was not until ARINC 664 Part 7

was issued on June 27, 2005 that AFDX was formally defined as a standard.

ARINC and the AEEC, working with the industry, created a deterministic

protocol for real time application on Ethernet media, which is now recognized

by most of key aerospace players as ARINC 664 Part 7 or AFDX.

© 2006 SBS Technologies, Incorporated, All rights reserved. 2

AFDX History Statement This White Paper touches briefly on the history of AFDX, but further information may be obtained

at the ARINC/AEEC web site: www.arinc.com/aeec. The standard for AFDX is ARINC 664 Part 7,

which is also available from this site.

AFDX is intended for aircraft flight critical interfaces, including Engines, Flight Controls,

Navigation Systems, as well as systems deemed to be critical to the operation of the platform.

Traditionally, ARINC 429 has been and is still used to implement safety or flight critical interfaces

in airborne platforms, connecting critical Systems. ARINC 429 is a Point to Point bus system,

consisting of Transmitters and Receivers, with 1 to 1 or 1 to many connections, operating at 12.5

KHz or 100 KHz. AFDX is intended as a direct replacement for ARINC 429. However, ARINC 429

may still be used for low speed applications in cooperation with high speed AFDX traffic within

Avionics Systems.

Figure 1. Example Engine Control system

NOTE: The system designer may wish for more redundancy and have multiple Engine control computers, as well as separate AFDX networks per engine.


AFDX, an Ethernet standard? The birth of AFDX was made possible only by the progress of Ethernet technologies within the

commercial networking community. Ethernet played a very important role in the inception of

AFDX, and future technologies will use Ethernet media.

The advent of Ethernet switch technology provided a method for implementing an ARINC 429

replacement technology on Ethernet media using Ethernet transmission speeds. Airbus Industries

was the pioneer of AFDX for the Airbus A380 aircraft. Adoption by other aerospace companies,

has guaranteed the success of AFDX as a technology for the longer term. The Commercial

Aerospace community recognizes the performance edge and costs savings that AFDX brings to

Avionics Systems of the future.

AFDX or Avionics Full Duplex Switched Ethernet is a based around Ethernet concepts, using

copper or fiber optic media and Ethernet switch technology. However, AFDX is very different from

Ethernet 802.3 as a communications protocol.

AFDX, the Protocol

The AFDX protocol was designed to use Ethernet media, but with ARINC 429 characteristics,

implying point-to-point communications, known bandwidth and redundancy of data where

necessary, and prioritized quality of service. These concepts provide a path towards determinism,

which is extremely important in real time, safety critical systems.

The main characteristics of an AFDX network are its deterministic nature through a number of

restrictions and enhancements to the standard Ethernet protocol:

Fixed or Bandwidth Limited: with tight latency requirements for transmission and reception

of data. This implies a maximum data packet size to allow guaranteed bandwidth.

Ordinal Packets: packets are received in the same order that they are transmitted.

Dual Port: dual redundant; both ports transmit the same data.

Virtual Link: a concept to implement ARINC 429 type transmitters and receivers utilizing

switched Ethernet point-to-point mechanisms. Switches are the most important components

of an AFDX network.


The Virtual Link (VL) concept implements a form of ARINC 429 over Ethernet media using

AFDX technology and the AFDX protocol. Virtual Links are the point-to-point connections

between transmitters and receivers on an AFDX network. We will find out more, later in this

white paper, on the use of VL’s within an Avionics System AFDX network.

AFDX Latency and Jitter Consideration Although the AFDX traffic is bandwidth limited, there are complications with transmitting End

Systems and Jitter. Jitter is the effect, caused by the time regulation and scheduling components

of a transmitting End system, where multiple VL traffic is time regulated and scheduled into the

BAG for the Virtual Link. End Systems and Switches are required to provide algorithms to reduce

Latency and Jitter. To simplify an explanation of Jitter, imagine a three lane autobahn or

motorway reducing down to a single lane of traffic. Jitter is a timing delay whereby the rate of flow

is reduced to accomplish a safe ordering of traffic.

Figure 2. Illustration of End System induced Jitter


The Jitter is caused by the Scheduler attempting to transmit all VL traffic that is to be sent within

the VL Bandwidth Allocation Gap.

AFDX End System Virtual Link Performance AFDX End System performance is directly related to the number of Virtual Links within the End

System. Each transmitting VL uses some bandwidth; maximum calculated bandwidth may be

calculated as follows:

VL Maximum Frame Size (1518 bytes, as per A664 part 7)

VL Bandwidth Allocation Gap (1msec to 128msec fixed at startup)

So for a VL with a BAG of 1msec and a max frame of 1518, we can see that the

VL may transmit 1,518,000 bytes per second maximum.

A VL with a BAG of 128msec and a max frame of 1518, we can see that the

VL may transmit 11,859 bytes per second maximum.

Compared to Ethernet rates this is extremely slow. However, the AFDX protocol requires

determinism. Limited bandwidth and known latency and jitter, combined with dual redundancy,

provide the needed determinism for safety-critical systems.


Performance Consideration Performance of a VL may be calculated in bytes per second. However, there may be several

transmitting VL’s in the End System, each with different Bandwidth Allocation Gaps. Therefore,

true performance may be affected by Jitter issues within the system.

System Designers must ensure that the BAG values for all VL’s will allow the required bandwidth

performance. Otherwise, Jitter issues may impact system performance drastically, making the

system non-deterministic.

Severe Jitter may cause the BAG to be exceeded, the scheduler must send no more than one

frame from each VL in the allocated BAG limits. If Jitter causes severe delays, there may be

contention or frame collisions.

To be clear, AFDX may not be at fault in certain scenarios, for example where the system

implementers are not aware of the implications of having too many VL’s with low BAG limits,

which may cause severe Jitter and subsequently aircraft system non-response.

AFDX Technology The AFDX Technology relies on the implementation of the AFDX protocol, the technology

implements the AFDX protocol, the network interfaces, switched and interconnect cabling are the

technology of AFDX.

The concept of a NIC or Network Interface Card is replaced with the term End System within an

AFDX network. End System relates to the End Address on an AFDX network, and each End

System has an Internet Protocol (IP) network address just like an Ethernet IP address.

There are variations on the implementation of AFDX Technology, which is allowed within the

ARINC 664 Part 7 standard.

Hard AFDX or COTS Hardware AFDX Hard AFDX is widely implemented today by various vendors for both laboratory and flight use.

Hard AFDX is implemented on a custom designed board with Ethernet chipsets and a DSP

running firmware or an FGPA processor running IP Cores. There are also component suppliers

that provide AFDX chipsets for COTS applications.


As usual, there are advantages and disadvantages for this implementation:

Advantages

Reduced Host Processing as the DSP or FPGA implements the AFDX protocol.

Designs may be distributed as a COTS PMC-style board.

Disadvantages

Protocol changes may require hardware design changes at a later date. AFDX is a very new

technology, guaranteeing change in the short term.

Component End of Life issues may affect the program at a later date; this may require redesign and

re-certification of the product.

Costs associated with creating and maintaining firmware code, which is typically written in low-level

assembly language.

Soft AFDX or Software Loadable AFDX Stack Soft AFDX or software loadable AFDX protocol stacks exists in a number of programs to date.

Software Loadable implies a host CPU running the software stack, along with application

software, to implement the End System using standard Ethernet hardware that is readily available.

The advantages and disadvantages for Soft AFDX are as follows:

Advantages

Hardware is readily available.

Hardware is much cheaper than COTS DSP or FPGA solutions.

Industry standard Ethernet boards are available in PCI or PMC formats.


Faster Ethernet products may be used as soon as the ARINC 664 standards are

implemented without redesign.

No End of Life issues since industry standard Ethernet is in use.

AFDX protocol changes are implemented in a high-level language, such as ‘C’, C++, Ada,

etc.

Disadvantages

Host processor requires sufficient performance to deal with AFDX protocol implementation.

Typical safety-critical AFDX speeds are currently 10Mbps and others run at a maximum of

100Mbps; these are bandwidth-limited with restrictions on transmission bursts delayed by

1ms maximum per session.

The Ethernet driver and protocol stack require optimization to meet the latency

requirements of the ARINC 664 Part 7 standard. This is currently set at 150usec for

transmission and reception of data between the physical layer and the AFDX stack

Communication Services layer mandating an appropriate OS and CPU to meet these

requirements.

AFDX Network Switch Although this white paper concentrates on AFDX End Systems, the AFDX Switch has an

extremely important role in an AFDX network.

The AFDX Switch provides the following functions:

Filtering and Policing of AFDX frames, discarding invalid frames.


Switching of AFDX Frames to End Destinations.

Switch Monitoring and logging of Filter and Policy events, SNMP.

Data and Configuration Table Load, achieved with internal End System.

Configuration Table Management and switch mode management.

AFDX End Systems would still be able to operate with a standard Ethernet switch, but on a

critical system, an AFDX Switch is vital for correct operations of the AFDX network, especially

filtering and policing of invalid frames.

The AFDX Switch also plays a part in implementing AFDX protocol latency requirements,

ensuring that received frames are processed and reach the destination address within the

required time.

AFDX End System Overview The AFDX End System is the interface from the subsystem function to the network media. An

END System may implement a number of Virtual Links for transmission of data and also

subscribe to transmitting Virtual Links as a receiver. The AFDX End System implements the

AFDX protocol stack to implement the ARINC 664 Part 7 standard. The AFDX End System has

two dual redundant ports for transmission and reception of data.

High Level Overview of an AFDX End System


AFDX End System Function Blocks The AFDX End System functional blocks all play an important role in the implementation of an

AFDX End System.

Transmit Management allows creation of VL, transmitting of data, time regulation of data, and

scheduling of messages onto the network interconnect media.

Redundancy Management allows gathering of correctly ordered data using both port A and port B

in case of data corruption.

Receive Management allows correctly ordered data to reach the API level and subsequently

software processes within the User Application that is using the AFDX stack

There are other services that an AFDX End System implements including SNMP, file transfer

service, and port sampling. However, this white paper will not cover these services due to the

current ambiguous nature of these services within the AFDX standards. Application of these

services will evolve, as will AFDX, as a communications protocol.


References

The following items are referenced within this White Paper. [1] ARINC 664 date 25th June 2005 see www.arinc.com [2] ARINC 653 [3] RTCA DO-254 [4] RTCA DO-178B Glossary The following abbreviations are used within this White Paper. AFDX Avionics Full Duplex Switched Ethernet AFDX Com AFDX Communications Port ARINC Aeronautical Radio Inc. BAG Bandwidth Allocation Gap BIT Built in Test BSP Board Support Package CBIT Continuous Built in Test COTS Custom of the Shelf CRC Cyclic Redundancy Check ES End System IEEE Institute of Electrical and Electronics Engineers, Inc IMA Integrated Modular Avionics IP Internet Protocol MIL STD Military Standard NIC Network Interface Card MIB Management Information Base OS Operating System PBIT Power-Up Built in Test PMC PCI Mezzanine Card PPC Power PC SAP Service Access Point SBC Single Board Computer SNMP Simple Network Management Protocol RTCA Radio Technical Commission for Aeronautics TFTP Trivial File Transfer Protocol UDP User Datagram Packet VL Virtual Link VME Versa Module Europa vxWorks Wind River vxWorks Real Time OS Integrity Greenhills Integrity OS


© 2006 SBS Technologies, Inc. All rights reserved.

SBS Technologies and the SBS logo are trademarks of SBS Technologies, Inc. All other brand names and product names contained herein are trademarks, registered trademarks, or trade names of their respective holders. This document contains information, opinions and conclusions that the author believed to be accurate as of the date of its writing, but SBS does not guarantee the accuracy of any portion of this document. This document and its contents are provided as is, with no warranties of any kind, whether express or implied, including warranties of design, merchantability, and fitness for a particular purpose, or arising from any course of dealing, usage, or trade practice. If you reproduce any parts of this document, you must reproduce and include all SBS copyright notices and any other proprietary rights notices. In no event will SBS be liable for any lost revenue or profits or other special, indirect, incidental and consequential damage, even if SBS has been advised of the possibility of such damages, as a result of the usage of this document and the software that this document describes. RESTRICTED RIGHTS LEGEND Use, duplication, reproduction, release, performance, display or disclosure by the Government is subject to restrictions set forth in subparagraph (b)(3) of the Rights in Technical Data and Computer Software clause at 48 CFR 252.227-7013. SBS Technologies, Inc., 7401 Snaproll NE, Albuquerque, NM 87109

afdx overview

Documents