Why are there so many avionics communications specifications?

I recently had occasion to give a course on avionics communications. While I often teach companies about MIL-STD 1553 and ARINC 429, this time I was asked to also speak about ARINC 629, ARINC 664 Part 7 (AFDX) and ARINC 825 (CAN Bus).

While I can’t say I recommend learning, or teaching,  five different specifications in one day, one good thing did come out of it. I was able to give over a better understanding of why so many specifications are needed.

The starting point is what the goals of each specification were. The next issue is what problems were encountered on the way that needed to be solved.

For avionics communications this is a short synopsis of these issues.

Goals of the Specification

1. Communicate between xxx devices.
2. Send yyy bytes per second per device (average)
3. Send repetitive or non-repetitive data
4. Send data to a single device, all devices or a subset of devices simultaneously.
5. Prevent simultaneous transmission by multiple devices
6. Synchronize devices
7. Prevent single point of failure

Problems to Solve

Let’s look at each specification in turn and see how it deals with each issue.

Mil-STD 1553

Mil–STD 1553 was developed in the late 70s and early 80s by the United States Department of defense for use in Military aircraft. The design goals were to connect up to 32 devices with the ability to transmit up to 32 16 bit words of data in a message. Messages were expected to be transmitted between once and fifty times a second.  Data was primarily repetitive, i.e. engineering units such as altitude, latitude and longitude.

Simultaneous transmission by multiple devices is prevented by having all messages initiated by a Bus Controller, of which there can only be one at a time in any system.

Synchronization is accomplished by using a Synchronize Mode Code.

Single point of failure is avoided by including dual redundancy as part of the specification.

Messages may be directed to a single RT or broadcast to all RTs simultaneously.

ARINC 429

ARINC 429 was published in 1978 with updates until 2001. It was based on a variety of devices that had been developed by various manufacturers with similar, but not identical specifications. ARINC 429 was developed to promote interoperability between devices used on civilian aircraft.

The design goals were to connect a single transmitter to up to 10 receivers. Messages were expected to be transmitted between once and fifty times a second.  Data was primarily repetitive, i.e. engineering units such as altitude, latitude and longitude.

Simultaneous transmission by multiple devices is prevented by only a single transmitter on each wire. This necessitated having some devices with multiple ARINC 429 connections.

Synchronization is accomplished between receivers by having all receivers receive their data simultaneously.

Synopsis of MIL-STD 1553 and ARINC 429

Single point of failure is not dealt with in the specification. It must be handled on the system level by making sure sufficient backup devices are available.

Note that MIL-STD 1553 and ARINC 429 were developed at about the same time and therefore assumed similar data requirements. Both are capable of transmitting non recurrent data such as data bases but neither are optimized for that kind of data.

Military aircraft of more likely to have multiple similar devices – missiles come to mind – as well as a greater need to change the configuration of the devices from flight to flight – again missiles come to mind. This makes a bus architecture, where each device requires only a single connection to the bus, more efficient that the point to point architecture of ARINC 429. Point to point architecture makes it harder to add devices which may need multiple connections to other devices thus affecting the already complex aircraft harness.

ARINC 629

ARINC 629 was published in 1990. It was intended to work in concert with ARINC 429 which by then was in very wide use in commercial aircraft. ARINC 629 was an attempt to reduce some of the wiring complexity inherent in the point to point ARINC 429 architecture and to facilitate the transfer of non-periodic data such as data bases or video.

The design goal was to connect up to 120 devices and be able to transmit strings of up to 256 sixteen bit words. A speed of two Megahertz was selected.

Each string is preceded by a label that indicates the type of data being sent. Each receiver has the option of paying attention to a particular label or ignoring it.

Multiple redundancy of devices is supported by the specification but redundancy of cables is not.

Simultaneous transmission by multiple devices is prevented by a set of timers in each device along with the ability to detect transmission on the bus.

Synchronization is not explicitly addresses by the specification.

ARINC 664 Part 7 (AFDX)

ARINC 664 Part 7 was published in 2005. It was intended to work in conjunction with ARINC 429 and has many features based on experience with ARINC 429. There is no real limitation on the number of devices that can be connected and the data size is up to 8Kbytes. To a large extent, the requirement driving AFDX were the same as the requirements that drove ARINC 629. The major difference between the two specifications was that ARINC 629 was designed from the ground up whereas AFDX was designed on top of standard Ethernet.  At this point I should admit to a major lie of omission earlier in the document. In listing the goals of avionics specifications I left out a very significant goal; the specification must be economically feasible to implement. As it turns out ARINC 629 did not meet this goal and was never successful.  The number of avionics suppliers capable of and willing to design devices that conformed to ARINC 629 was too small to create a competitive market resulting in a seller’s market and very high prices for ARINC 629 compliant devices. The response to this was AFDX which is based on Ethernet, a nearly ubiquitous technology. AFDX added some requirements on top of Ethernet to make it more robust and real time. It uses VLIDs to identify the type of data being sent as well as the device or devices the data is intended for. A speed of 100 Megahertz was selected. The high overhead per packet makes AFDX more optimized for file transfer than for engineering data but it is certainly intended and designed for repetitive engineering data as well.

Single point of failure is avoided by including dual redundancy as part of the specification. As opposed to most dual redundant systems which transmit on one bus and keep the second bus for use when errors are detected, AFDX always transmits on both buses and lets the receiver decide which of the two incoming packets to use. Personally, I’d have recommended sticking to the more common method.

Simultaneous transmission by multiple devices is prevented by the use of switches which buffer incoming data in the event that the output port the data is meant for is already in use.

Synchronization is not explicitly addresses by the specification.

ARINC 825 (CAN Bus)

ARINC 825 was first published in 2010. It was intended to work in conjunction with ARINC 429, AFDX and several other buses. It may connect between 30 and 60 devices depending on bus speed and it is limited to eight bytes per message. Multiple speeds are defined with one Megahertz being the highest permitted speed. The small message size makes it more optimized for engineering type data but the specification does describe a file transfer mechanism as well.

Each message is preceded by an Identifier, each receiver has the option of paying attention to a particular Identifier or ignoring it.

Dual redundancy and even quad redundancy is supported but not required by the specification.

Simultaneous transmission by multiple devices is permitted. The hardware is designed such that, when a collision does occur the device with the higher priority continues transmitting with no efficiency penalty to the bus while the lower priority device waits until the end of transmission before trying again.

Synchronization is possible by using the Node Synchronization Service defined in the specification.

Summary Table

Summary

Mil-STD 1553 and ARINC 429 were designed for a relatively small number of devices with limited data transfer requirements. They are used in a huge number of aircraft and will not disappear any time soon. They are robust, inexpensive and wired in.  Device designers would be well advised to support MIL-STD 1553 for the military market and ARINC 429 for the civilian market.

For new civilian aircraft designs ARINC 825 offers several significant advantages over ARINC 429. It is a bus rather than point to point and therefore has fewer connection points and fewer wires thereby decreasing weight, harness complexity and potential points of failure. It is also faster, supports more devices and transmits more data per message. Its limitations include relatively short bus length (at 1Mhz as short as 20 meters) and a maximum of eight bytes per message.

New civilian aircraft designs with large data requirements should consider AFDX with its 100Mhz speed and 1471 data bytes per packet it can handle large file transfers easily. The combination of ARINC 825 for local, low data devices with AFDX for long distance or large data requirements would seem to be the ideal combination for new designs.

I haven’t reviewed recent advances in military bus technology such as Firewire which is in use on the F35. I wouldn’t be surprised if the military moves towards the use of civilian specification like AFDX for future projects.

MACC II  - Miniature Airborne Communication Converter:

More information about MACC II >>