Draft:ARINC825 DRAFT

The ARINC825 Standard – ARINC Specification 825: General Standardization of CAN (Controller Area Network) Bus Protocol for Airbome Use, was prepared by the Airlines Electronic Engineering Committee (AEEC) and published by ARINC in 2007. ARINC has since published subsequent revisions. Users are encouraged to check with ARINC as to the status of this standard.

Bus systems have been used in aviation technology for many years to network electronic components. In newer systems, Controller Area Network (CAN) is becoming increasingly important. The ARINC 825 specification from the standards organization ARINC describes the recommended use of CAN in civil aircraft. This specification has so far been used by the manufacturers Airbus and Boeing.

General

In commercial aircraft, such as the Airbus A380 or the Boeing 787, between 80 and 250 Controller Area Network (CAN) networks are integrated. However, due to the large number of different physical interfaces, data formats, communication mechanisms and the insufficiently coordinated use of CAN identifiers, the effort required for system integration turned out to be increasingly problematic from the aircraft manufacturers' perspective. This realization led to a joint initiative by Airbus and Boeing in 2004 with the aim of creating a uniform CAN standard for commercial aviation. ARINC was selected as the standardization organization and, led by Airbus and Boeing, a technical working group of the Airlines Electronic Engineering Committee (AEEC), consisting of experienced engineers from Airbus (Bremen, Hamburg and Toulouse), Boeing, GE Aviation, Rockwell Collins and Stock Flight Systems, was selected [1] formed. Based on CANaerospace, this group developed the ARINC specification 825 within three years, which was used for the first time in the Airbus A350. ARINC 825 was created through the collaboration of avionics engineers from four nations, all of whom have been responsible for the development and integration of CAN-based systems in aircraft for many years. Based on this background of experience, a standard was created which, thanks to the support of the major aircraft manufacturers Airbus and Boeing, has a significant impact on the development of CAN in the aviation sector.

ARINC 825 not only represents an aviation-specific higher-level protocol, but also addresses CAN as a whole and also describes levels 1 and 2 of the CAN protocol implemented in the CAN controllers themselves. It also contains a comprehensive chapter that defines development guidelines for CAN in the aviation sector. These guidelines cover the physical bus connection, but also contain important and extensive information regarding the programming of CAN controllers and the use of the communication mechanisms defined in ARINC 825. In particular, the avoidance and treatment of errors in CAN systems is discussed in detail and supplemented by tips for designing fault-tolerant systems. In this respect, ARINC 825 goes far beyond other ARINC specifications and represents a kind of development manual for CAN systems in aircraft. The ARINC specification 825 was first published in November 2007.

Characteristics

In commercial aircraft, CAN is essentially used as a secondary network for communication data buses according to ARINC Specification 664, Part 7 (AFDX). In this case, CAN is used to connect sensors, actuators or other avionics devices that require low to medium communication speeds. In this aircraft class, CAN is therefore primarily used as a complementary network to the complex “backbone” networks such as AFDX. In general aviation aircraft, however, CAN can be the central avionics network and must therefore meet all requirements for a data bus that is critical to flight safety. ARINC 825 has been designed to meet both requirements and can therefore serve as both a secondary and main network. ARINC 825 therefore meets the following criteria:

• Easily connect local CAN buses to other aircraft networks
• Lowest possible costs in terms of implementation and changes over the life of the aircraft
• Maximum interoperability and interchangeability of CAN-connected line-replaceable units (LRUs)
• Maximum flexibility with regard to the removal, addition or modification of individual bus participants while avoiding avoidable influences on other bus participants
• Support cross-network communication for individual parameters and block data transfers via gateways
• Integrated error detection and signaling
• Support for cross-system functions such as the configuration of individual bus participants and aircraft health analysis (“Aircraft Health Management”)

Physical interface

To ensure interoperability and reliable data exchange, ARINC 825 defines electrical properties, bus connection requirements and data transmission speeds including corresponding tolerances based on ISO 11898. Particular attention is paid to the definition of CAN-specific time calculations (accuracy of the data transmission speed, determination of the sampling time). The data transfer speeds supported by ARINC 825 are 1000 kbit/s, 500 kbit/s, 250 kbit/s, 125 kbit/s and 83,333 kbit/s.

Network layers

ARINC 825 is based on CANaerospace in many respects in terms of communication mechanisms, but only uses extended (29 bit) identifiers. This means that some of the identifier bits can be used to represent the large number of different systems typical for commercial aviation and to ensure interoperability even in very complex systems.

The CAN specification stipulates that CAN messages sent are generally received by all connected bus participants, a communication principle that is also referred to as “Anyone-to-Many” (ATM). The advantage of this concept is the inherent data consistency between all bus participants. Both periodic and aperiodic sending of messages during normal operation is possible. The disadvantage of setting the CAN specification exclusively on ATM is that, by definition, there is no subscriber addressing for CAN, which in turn forms the basis for “peer-to-peer” (PTP) communication. However, for use in the aviation sector with its high demands on continuous system monitoring, the ability to communicate with individual bus participants is extremely important. ARINC 825 therefore provides the necessary protocol functions to enable PTP communication. It also enables the implementation of additional functions of ISO/OSI layers 3, 4 and 6, which in turn allows the creation of logical communication channels (LCC) and corresponding communication types (ATM, PTP), as shown in Figure 1.

Figure 1: CAN identifier structures for ARINC 825

The simultaneous use of ATM and PTP communication for CAN requires the introduction of different network layers that allow independent communication. These are generated by ARINC 825 by grouping the CAN identifiers as shown in Figure 2. The resulting structure creates logical communication channels (Logical Communication Channel, LCC) and assigns them a specific communication type (ATM, PTP). Custom LCCs give the user great freedom to implement ARINC 825 according to their needs.

Figure 2: Logical communication channels of ARINC 825

In addition, for ARINC 825 the 29 bits of the identifier are divided into further fields which have the following meaning:

• The Function Code Identifier (Source FID or Server/Client FID) identifies the system or subsystem in which the message in question originates, and in the case of the Server FID also the receiving system or subsystem. The FID largely corresponds to the Air Transport Association (ATA) chapters used in aviation for many decades, with the ARINC 825 specification assigning ATA chapters to the corresponding identifier bit combination (and associated message priority) according to the importance of the individual aircraft systems. In addition, various FIDs are reserved, for example, for temporary test/maintenance systems or for use by other ARINC 825-based standards. The use of defined FIDs is mandatory for all communication channels except UDC and FMC.
• The Reserved/Service Message Type (RSD/SMT) bit is always 0 for ATM communication, while for PTP communication it indicates the direction of data transfer between client and server. For service requests (i.e. messages sent by the client), this bit is set to 1, while for server responses it is set to 0.
• The Local Bus Only (LCL) bit is set to 1 for messages that remain within the relevant network segment and should not be routed through gateways to other networks.
• The private (PVT) bit is set to 1 for messages that have no meaning for bus participants that have not been explicitly programmed to process these messages. Messages in which the PVT bit is set are usually not described in the communication profile database and are only intended for “private” use between selected bus participants.
• The Data Object Code (DOC) for ATM communication specifies the parameter sent with the message. The exact description of all parameters with regard to their properties (physical unit, data type, repetition rate, etc.) are described in the corresponding communication profile database.
• The Redundancy Channel Identifier (RCI) defines which redundancy channel the message in question is to be assigned to. ARINC 825 supports redundant systems up to level four, whereby the RCI allows, for example, redundant messages to be sent on a single bus and thus to easily overcome redundancy jumps in the system.
• The server identifier (SID) defines the bus participant (or a corresponding function in a bus participant), which provides a service that can be used within the framework of the Node Service Concept based on PTP communication. The combination of SID, server FID and RCI together forms a node identifier (NID). This NID ensures that a server is uniquely addressed in the network.
• PTP communication allows, in addition to the “normal” data flow in a system, to temporarily or permanently establish and dissolve interactions between individual bus participants, thereby enabling network services on a “client/server” basis. Several of these interactions can run in parallel, and each bus participant can simultaneously be a client for certain interactions and a server for others. With the help of this mechanism, referred to in ARINC 825 as the “Node Service Concept”, system functions can, for example, be distributed transparently across different participants in the network or the dynamic reconfiguration of an entire system can be controlled to increase reliability in the event of an error. The Node Service Concept distinguishes between connection-oriented and connectionless interactions, similar to the case of TCP/IP and UDP/IP for Ethernet.

Data representation

To support interoperability in aircraft systems, ARINC 825 provides a number of definitions:

• Data format definition (big endian only)
• Data type definitions (Boolean, Integer, Floating Point, ....)
• Aviation axis systems and sign definitions (ISO1151 or EN9300)
• Unit definitions (m, kg, ....)
• Definition of the various aircraft functions (Flight State, Air Data, ....)

The separation by aircraft functions is used, among other things, to identify the source and destination of ARINC 825 messages. The corresponding definitions are derived from the Air Transport Association (ATA) chapters, which makes it possible to use specifications in system design that have been used in the aviation industry for decades.

Time behavior

ARINC 825 uses the bandwidth management concept known from CANaerospace and known as “Time Triggered Bus Scheduling” for both ATM and PTP communication. This concept is based on a limit on the number of CAN messages that a bus participant is allowed to send within a time frame (minor time frame) defined as part of the pre-development of the overall system, as well as on a maximum of 50% utilization of the available bandwidth. This ensures that no message is delayed beyond a specified time. The largest possible number of CAN messages sent within a minor time frame can vary from bus participant to bus participant and can provide a certain “reserve” for future expansions. Time Triggered Bus Scheduling takes advantage of the knowledge that not all CAN messages in a system need to be sent at the same renewal rate specified by the Minor Time Frame. By defining integer multiples of the renewal rate specified by the Minor Time Frame and associated “transmission slots,” a significantly larger number of CAN messages can be sent in a predictable manner than if they were all tied to the Minor Time Frame itself.

Time Triggered Bus Scheduling requires that each bus participant adheres to the specified transmission schedule at all times, i.e. never sends more than the maximum number of messages specified for them within a minor time frame. However, this does not mean that the bus participants have to synchronize in time with regard to their transmission times or the order in which their messages are sent. Figure 3 shows an example of the transmission scheme of an ARINC 825 network with two bus participants that send their messages asynchronously, in changing order and at varying times within their minor time frame. Applying this concept, it can be demonstrated that an ARINC 825 network behaves predictably and meets the requirements of an aviation safety critical system. In order to maintain this even under error conditions, the system designer must specify how disruptions (e.g. high volumes of error frames) are to be dealt with.

ARINC 825 can therefore also be used for systems up to Design Assurance Level (DAL) A, provided that the loss of a single network does not have an impact, with a classification higher than “major”.

Figure 3: Simplified ARINC 825 transmission scheme with two bus participants

Communication profile database

For ARINC 825, the content and formatting of the user data was left entirely to the user. The lack of a self-identifying data format like CANaerospace therefore made it necessary to ensure interoperability in another way. ARINC 825 therefore uses a so-called “communication profile database” for the clear and system-wide network description. For this purpose, the ARINC 825 specification contains the description of a communication profile file format, from Supplement 1 onwards, based on XML 1.0[2], which must be created for each bus participant. The entirety of the communication profiles of all bus participants in a given ARINC 825 network describes the entire bus traffic and is therefore used to specify a network, but also for analysis for approval purposes and as a basis for acceptance and integration tests. A precise analysis of such a communication profile database allows potential network problems to be identified and avoided in advance. Test tools for ARINC 825 networks must be able to read and correctly interpret this communication profile database.

Gateways to other networks

The Integrated Modular Avionics system architectures of modern commercial aircraft typically use different data buses with different characteristics. The data exchange between these data buses must be ensured by gateways, as the bandwidth and communication mechanisms of the relevant networks typically do not match. To support the design of the appropriate gateways between CAN and other networks, ARINC 825 defines a simplified gateway model and contains in-depth information regarding protocol adjustments, bandwidth management, data buffering and error handling.

Development guidelines

The ARINC Specification 825 contains a comprehensive development guidelines chapter to help system engineers and LRU developers use ARINC 825 in a specification-compliant and acceptable manner. The development guidelines document a broad collection of experiences from the aviation industry, which have significantly influenced the design of ARINC 825. However, the development guidelines are not hard requirements, but rather recommendations that are intended to help developers avoid potential weak points when developing CAN-based systems for aircraft.

Impact on other standards

The consistency and accuracy of ARINC Specification 825 was continually verified using a reference system throughout the design process, which lasted several years. In this reference system, all protocol functions were implemented and tested against the specification, thereby ensuring the integrity of ARINC 825. As a result of this quality assurance process, applied for the first time to ARINC specifications, the Airlines Electronic Engineering Committee (AEEC) has decided that all future ARINC specifications using CAN will be based on ARINC 825. Examples of this are the ARINC 826 Data Load and the ARINC 812 Galley Insert Communication Standard. Airbus technical development requirements already define ARINC 825 for a variety of systems for the new Airbus A350. As one of the foundations of ARINC 825, CANaerospace remains as an “11-bit” alternative and is continuously being further developed, with increased compatibility with ARINC 825 being ensured from CANaerospace version 1.8.