The AEEC (Airlines Electronic Engineering Committee) is one of the many programs under SAE ITC (SAE Industry Technologies Consortia) to produce standards for the aviation industry.  SAE ITC has many committees and sub committees with workgroups for setting standards for various equipments and systems in avionics. The ARINC Standards have been developed by AEEC and they provide industry specifications for the standardization of form, fit and function between various avionics products. This allows for interoperability and compatibility between different manufacturers’ systems and allows airlines and manufacturers the flexibility to choose and replace with equipment of their choice (even cross-manufacturer) for aircrafts and control systems. Today ARINC Standards have been implemented by a vast number of airlines and business aircrafts all over the world.

The overall aim of ARINC standards and the associated solutions is to improve efficiency, productivity, and cost effectiveness and to reduce life-cycle costs for airlines industry and their collaborators from the avionics, cabin system, flight simulation and training sectors.

SAE ITC is responsible for copywriting and publishing the AEEC produced ARINC standards.

The ARINC standards are divided into different series and further organized into the ARINC standard classes.

400 Series	Design foundation for ARINC 500 and 700 series equipments. Specify guidelines for installation, wiring, bus systems, databases and general instructions.
500 Series	Analog avionics equipment.
600 Series	Reference standards for ARINC 700 series equipment.
700 Series	Define the form, fit, function and interface in digital systems and equipments for modern aircrafts.
800 Series	Defines technologies that support the networked aircraft environment.
900 Series	Define avionics for integrated modular and networked components.

Avionics data bus systems have been used for electronic component interconnection in aviation industry for many years. The first common digital communication for aviation was MIL-STD-1553 published in 1973. MIL-STD-1553 is a 1 Mbit/s redundant multi-drop communication channel allowing data exchange between all connected units with all communication scheduled and controlled by a redundant master unit. MIL-STD-1553 was designed for flight control and by that relatively complex and expensive.

For less demanding communication needs, the ARINC429 is developed in 1977. It was intended for a communication network consisting of one transmitter to up to 20 receivers with 32 bits packages at 100 or 12.5 kbit/s. Basically it was a digital replacement of the analog signal wire, providing sensor data to different instruments. CAN, the multi-master communication bus become available in 1988 in which any unit could exchange up to 8 byte with any other unit connected to one single communication media. This made the cabling much simpler and it also facilitated high amount of data transfer that needed when the units contain programmable Micro Controllers.

The first attempt to standardize the CAN usage in aviation was CANaerospace that was a set of rules to simplify the use of CAN in aviation applications. Based on CANaerospace, J1939, Ethernet and other Higher Layer Protocols, the first ARINC825 specification version 1 was developed in 2007. Some modifications and extensions were done over the years but the major change was done when CAN FD was included as a part of ARINC825-4 on April 2018.

CAN is not used for the direct control of the airplane and is not a replacement for the MIL-STD-1553. Though it is possible to use CAN for flight control, it would demand a major addition of necessary hardware on top of the CAN-controller in order to provide the same redundancy as available with MIL-STD-1553. Another reason for not using CAN is that, since all units are connected to the single multi-master CAN bus, a bus failure could result in communication failure and data loss. CAN could be used in a point to point communication scheme, but that would not be the natural way to use CAN and hence MIL-STD-1553 is replaced by Ethernet as described in the ARINC664 Specification. Beyond the similarity of hardware sending and receiving the Ethernet-frame, ARINC664 has got additional capabilities compared to Ethernet. In ARINC, all units are connected to a pre-configured switch with all traffic being specified and configured.  So it is not feasible to add any new unit without reconfiguring the switch. The switch is performing the same tasks as the CAN-bus media and if it fails, the entire network will be down. To solve this problem all units are connected to three different parallel switches thus guaranteeing a working system even in case of failure of two switches, since the third switch will be up and working.

The ARINC664 use of Ethernet is very efficient and robust, but is very complicated to design, test and maintain. For that reason CAN (ARINC825) is used for less critical data communication in the aircraft. This information includes data from the sensor devices and all other low bandwidth information except the higher bandwidth needed video and audio information.

The new generation aviation systems are making use of CAN for networking due to the inherent capabilities of CAN like its reliability, the data rate that fulfils the need of any real-time control system, fault confinement, less overhead needed for bus arbitration and many others. Since CAN was originally meant for automotive control systems and industrial automation, its application in large aircrafts like Airbus A380, Boeing 787, etc. required increased integration and maintenance effort for the manufacturers. This was due to the high number of physical interfaces, data formats and inadequate CAN identifier coordination being employed in the avionics systems. In order to overcome this issue, a technical working group of the Airlines Electronic Engineering Committee (AEEC) was formed by the joined initiative and participation of Airbus, Boeing, GE Aerospace, Rockwell Collins and Stock Flight Systems to develop a uniform CAN standard for aviation. By 2007, the group developed the ARINC 825 Specification based on CANaerospace, the CAN protocol for aviation electronics and hardware interface. ARINC 825 Specification, thus provides a general standardization of the CAN bus protocol for airborne use.

The current version (September 2018), Supplement 4 of the ARINC 825 specification incorporates enhanced capabilities provide by the use of the CAN FD technology. These include the high data transfer rate (4MB) and increased package size from 8 byte to 64 byte that allows for accommodating more data in each CAN frame. New appendices are also included in the specification to provide the users information regarding ARINC 825 Compliance for manufacturers, bit timing configuration, Management Information Base (MIB) Counters and CAN bus security considerations.

 

Other ARINC 825 advantages are:

1. Provision of easy connectivity between local and external aircraft networks.
2. Reduction in life cycle cost for the avionics.
3. Maximum interoperability and inter device compliance through standardization.
4. Fast and flexible maintenance operations due to high interchangeability of LRUs.
5. Highly flexible and non-conflict based maintenance operations possible for each network component (bus users) related to addition, removal and modification while in connectivity.
6. Provision for both single parameter and data block transfers.
7. In-built error detection and correction.
8. Centralized and cross-system configuration of bus units and aircraft health management.
9. The ARINC 825 defined gateways facilitates smooth data exchange across a wide variety of data buses with varying bandwidth and communication mechanisms in commercial aircrafts.

This standard, known as Software Data Loader via CAN Interface, is intended to specify a protocol for simplifying avionics software loading onto LRUs (Line Replaceable Units) and (Line Replaceable Modules) LRMs in the aircraft through the CAN bus. The standard considers avionics software as a sequence of messages to be transferred over the CAN bus and also defines the byte organization of the messages.

CAN is designed according to ISO 11898-1 and ISO 11898-2 and provides definitions for ISO layers 1 and 2 only. In ARINC 825, additional ISO/OSI layer 3, 4 and 6 functions have been added to meet aviation data transfer needs such as high speed and volume, ultra synchronization and continuous system monitoring requirements. These functions facilitate for suitable communication methods like Logical Communication Channel (LCC) and communication modes like One-to-Many Communication (OTM), Peer-to-Peer Communication (PTP) and Station Addressing.

ARINC 825 is a higher layer CAN protocol developed specifically for aviation use and is derived from the CANaerospace protocol, but uses only the extended 29-bit identifier.

Apart from the protocol specifications, it also defines development guidelines for CAN in aviation like the bus interface, CAN controllers and other communication mechanisms. ARINC 825 goes well beyond the scope of a protocol specification and act as a complete manual for CAN in aviation by including detailed information and references for designing fault-tolerant CAN aviation communication systems.

Current commercial aircrafts use CAN as a complimentary bus system to the more complex, high capacity aviation communication backbones such as AFDX (Avionics Full Duplex Switched Ethernet) defined by the ARINC Specification 664, Part 7. In this role, CAN data bus is used for low to medium data transmission volumes such as for linking sensors, actuators etc. ARINC 825 expands the capabilities of CAN and meets the needs of a safety and mission critical flight network.  Thus it satisfies both needs; as a complimentary network and also as a fully fledged avionics backbone network.

The following table provides a comparison of the various CAN based aerospace protocols, pros and cons of each related to their strengths and effectiveness for aviation applications.

Protocol	Characteristics	Pros and Cons
ARINC 825	29 bit identifiers Payload carries several types of data signals Efficient transport protocols for large data sizes Time Triggered Bus Scheduling for timing	4/7Bandwidth wastage during low volume data transfers for 29 bit identifiers compared to 11 bit identifiers. Integrated channel/service/addressing schemes in identifier mitigate this. System designer can further optimize bandwidth usage by transporting several signals per message payload. Provides system design guidelines for implementing a predictable network with up to 50% bandwidth utilization. https://assets.vector.com/cms/content/know-how/_application-notes/canopen/AN-ION-1-0104_CAN-based_protocols_in_Avionics.pdf Page 4/7
ARINC 826	Uses ARINC 825 communications Efficient transport protocols for software loading as data messages	No usage during normal operation. Transport protocol is very efficient in facilitating software data loading through download/upload operations through CAN bus.
CANopen	Uses 11 bit identifiers Several signals transported in single payload Efficient transport protocols Provides several communication models like master/slave, client/server and producer/consumer.	Usage of 11 bit identifiers saves bandwidth in simple systems. Bandwidth can be improved in complex systems by transporting several signals per message. Normal usage provides quick response time, but not predictable due to the event driven service model.
CANaerospace	Uses 11 bit identifiers Normally transports only one message per payload Time Triggered Bus Scheduling for timing	11 bit identifiers save bandwidth. Transportation of one signal per message allows slightly efficient implementation in microcontrollers, but wastes bus bandwidth. Provides system design methods for achieving upto 50% bandwidth utilization through predictive networks.

The motivation and initiation for the development of ARINC 825 was driven by Airbus and Boeing. The overall aim was to create a uniform CAN standard for aviation and to achieve interoperability between different sub systems in the complex communication infrastructure of their aircrafts. The other members of the CAN Technical Working Group of AEEC that was responsible for the development of ARINC 825 were Rockwell Collins, GE Aviation and Vector Informatik.

CAN Aviation Alliance, a major participant in the international aviation standards development team actively contributes towards the ARINC 825 and CANaerospace aviation standards and also for other international CAN projects for aeronautics.

It also develops and delivers CAN aviation products and services worldwide for a target segment consisting of ARINC 825 system architects, vendors, aircraft manufacturers and airlines. This association was founded in 2007 by the aviation and simulation industrial giants Innovative Control Systems, Stock Flight Systems and Wetzel Technology GmbH. Their major ARINC 825 products include:

• XMC-A825-16 XMC 16 Channel CAN / CAN FD / ARINC-825 Board with 16 fully isolated channels.
• CANflight Dual Channel Bus Analyzer (CAN, CANaerospace and ARINC 825)
• PMC-825 Module with 4 optically isolated or 8 non-isolated ARINC 825 interfaces per module.

AIM GmbH, Germany, is a leading manufacturer of communications and networking components for the avionics test and simulation market.  It has developed the ACP825-x which is an ARINC 825 Test and Simulation module for PCI with 2 or 4 isolated CAN bus nodes.

Kvaser was represented by Kent Lennartsson as CAN FD expert in the working group that was formed to modify ARINC825-3. The group was assigned the task for including CAN FD in the next version of the standard.

Kvaser interfaces are generally compatible with CAN communication standards. While some support only Classical-CAN, the newer generation products support both Classical-CAN and CAN FD without any limitations. Kvaser’s CANlib driver software can send and receive any type of CAN frames. This inherent support provided by the driver software requires the application layer software to provide necessary functionality including the “Time Triggered Bus Scheduling” for configuring the CAN frames according to ARINC 825. So, while Kvaser interface products are capable for handling any type of CAN communication, the overall performance of the system depends upon the host computer’s configuration and performance.

Kvaser’s high-speed CAN interfaces support 29-bit identifiers and hence are compliant with ARINC 825 CAN frames transmission and reception. The Kvaser Memorator Pro 2xHS v2 CAN to USB high-speed interface and data logger is compliant with the timing requirements of ARINC 825, namely “Time Triggered Bus Scheduling” and hence can support highly synchronized CAN transmission schedules. The Memorator has the capability to handle 100% bus-load and by that it will record any ARINC825 installation. By t-programming it is possible to program the CAN-transmission according to the demands as described in ARINC 825 to comply to the “The time triggered Bus scheduling”.

ARINC (Aeronautical Radio, Incorporated of Annapolis, Maryland, USA), is a private corporation organized in 1929 with a group of airlines, aircraft manufacturers and avionics equipment manufacturers as shareholders. It is formed to develop specifications and standards for avionics and aerospace equipments for domestic and overseas manufacturers. The company was sold to Rockwell Collins on December 23 2013 and during 2014 the ownership and responsibility for the ARINC standards developed till that time were transferred to AEEC, an industry program of SAE ITC.

ARINC series of standards classification according to aircraft generations:

Class Standards	Aircrafts with high speed data network	Digital Aircraft and flight simulators	Analog aircraft and flight simulators
ARINC Characteristics	ARINC 700 Series ARINC 900 Series	ARINC 700 Series	ARINC 500 Series
ARINC Specification	ARINC 800 Series	ARINC 600 Series ARINC 400 Series	ARINC 400 Series
ARINC Reports	ARINC 800 Series	ARINC 600 Series ARINC 400 Series	ARINC 400 Series