ARINC 825

This article or section needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

Bus systems have been used in aviation technology for many years to network electronic components . In more recent systems, the Controller Area Network (CAN) is gaining in importance. The specification ARINC 825 of the standardization 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. Due to the large number of different physical interfaces, data formats, communication mechanisms and the inadequately coordinated use of CAN identifiers, the effort for system integration turned out to be increasingly problematic from the aircraft manufacturer's point of view. This realization led to a joint initiative by Airbus and Boeing in 2004, which aimed to create a uniform CAN standard for commercial aviation. ARINC was selected as the standardization organization and, under the leadership of 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 educated. On the basis of 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. On the basis of this experience, a standard was created which, thanks to the support from the major aircraft manufacturers Airbus and Boeing, has a very significant influence on the development of CAN in the aviation sector.

ARINC 825 is not only an aviation-specific, higher-level protocol , but also deals with CAN as a whole and also describes levels 1 and 2 of the CAN protocol implemented in the CAN controllers themselves. It also contains an extensive chapter in which development guidelines for CAN in the aviation sector are specified. These guidelines include 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 with instructions for the design of 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. ARINC specification 825 was first published in November 2007; the current version is Supplement 2.

properties

In commercial aircraft, CAN is mainly 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 avionic devices that require low to medium communication speeds. CAN is therefore primarily used in this aircraft class as a complementary network to the complex "backbone" networks such as AFDX. In general aviation aircraft, on the other hand, CAN can be the central avionics network and must therefore meet all the requirements for a data bus that is critical to flight safety . ARINC 825 was designed in such a way that it meets both requirements and can therefore serve as both a secondary and a main network. ARINC 825 therefore fulfills the following criteria:

• Easy connection of local CAN buses to other aircraft networks

• Lowest possible cost of implementation and changes over the life of the aircraft

• Highest possible interoperability and exchangeability of CAN-connected line-replaceable units (LRUs)

• Maximum flexibility with regard to removing, adding or changing individual bus users while avoiding avoidable influences on other bus users

• Support of cross-network communication for individual parameters and block data transfers via gateways

• Integrated error detection and signaling

• Support of cross-system functions such as the configuration of individual bus users and aircraft health analysis ("Aircraft Health Management")

Physical interface

In order to ensure interoperability and reliable data exchange, ARINC 825 defines electrical properties, bus connection requirements and data transmission speeds including the corresponding tolerances on the basis of ISO 11898 . Particular attention is paid to the definition of CAN-specific time calculations (accuracy of the data transmission speed, definition of the sampling time). The data transmission 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

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

The CAN specification stipulates that sent CAN messages are generally received by all connected bus participants, a communication principle which is also referred to as “Anyone-to-Many” (ATM). The advantage of this concept is the inherent data consistency between all bus participants. Both the periodic and the aperiodic sending of messages during normal operation are possible. The disadvantage of the exclusive definition of the CAN specification on ATM is that there is by definition no subscriber addressing for CAN, which in turn represents the basis for “Peer-to-Peer” (PTP) communication. For use in the aviation sector with its high demands on continuous system monitoring, however, the ability to communicate with individual bus users is extremely important. ARINC 825 therefore provides the necessary protocol functions to enable PTP communication. This also enables the implementation of additional functions of the ISO / OSI layers 3, 4 and 6, which in turn enables the generation of logical communication channels (Logical Communication Channel, 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 the 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 certain type of communication (ATM, PTP). User-defined LCCs give the user a great deal of freedom in order to enable the implementation of ARINC 825 according to his needs.

Figure 2: Logical communication channels of ARINC 825

In addition, the 29 bits of the identifier for ARINC 825 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, 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 the 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 standards based on ARINC 825. 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 it indicates the direction of data transfer between client and server for PTP communication. This bit is set to 1 for service requests (i.e. messages sent by the client), while it is set to 0 for responses from the server.

• The Local Bus Only (LCL) bit is set to 1 for messages that remain within the relevant network segment and should not be passed through gateways to other networks.

• The private (PVT) bit is set to 1 for messages that have no meaning for bus users who 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 parameters 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 relevant message 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 redundant leaps in the system to be overcome in a simple manner.

• 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 on the basis of PTP communication. The combination of SID, Server FID and RCI together forms a Node Identifier (NID). This NID ensures the unique addressing of a server in the network.

In addition to the “normal” data flow in a system, PTP communication allows interactions between individual bus participants to be established temporarily or permanently and also to be resolved again, which enables network services on a “client / server” basis. Several of these interactions can run in parallel, and each bus participant can be a client for certain interactions and a server for others at the same time . With the help of this mechanism, referred to as the “Node Service Concept” in ARINC 825, system functions can, for example, be transparently distributed over various participants in the network or the dynamic reconfiguration of an entire system can be controlled to increase reliability in the event of a fault. The Node Service Concept differentiates 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 offers a number of definitions:

• Data format definition (only Big Endian )

• 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 division according to 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 definitions for system design that have been in use in the aviation industry for decades.

Timing

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 limitation of the number of CAN messages that a bus participant may send within a time frame (minor time frame) defined as part of the advance development of the overall system, as well as on a maximum of 50% utilization of the available bandwidth. This ensures that the sending of any message is not delayed beyond a specified time. The largest possible number of CAN messages sent within a minor time frame can differ from bus subscriber to bus subscriber and can provide a certain “reserve” for future expansions. Time Triggered Bus Scheduling makes use of the knowledge that not all CAN messages in a system have to be sent with the same renewal rate specified by the minor time frame. The definition of integer multiples of the renewal rate specified by the minor time frame and the associated “transmission slots” allow a significantly larger number of CAN messages to be sent in a predictable manner than if these were all linked to the minor time frame itself.

Time Triggered Bus Scheduling requires that every bus participant adheres to the specified transmission scheme at all times, i.e. never sends more than the maximum number of messages specified for him within a minor time frame. However, this does not mean that the bus subscribers have to synchronize 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 different times within their minor time frame. When using this concept, it can be demonstrated that an ARINC 825 network behaves in a predictable manner and meets the requirements of a flight safety-critical system. In order to maintain this even under error conditions, the system designer must specify how to deal with faults (e.g. high number of error frames ).

ARINC 825 can therefore also be used for systems up to Design Assurance Level (DAL) A, provided that the loss of a single network has no effect, the classification of which is rated 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 were completely left to the user. The lack of a self-identifying data format like CANaerospace made it necessary to ensure interoperability in another way. ARINC 825 therefore uses a so-called "communication profile database" for the clear and cross-system network description. For this purpose, the ARINC 825 specification contains the description of a communication profile file format, from Supplement 1 on the basis of XML 1.0, which must be created for each bus participant. The totality of the communication profiles of all bus participants in a given ARINC 825 network describes the entire bus traffic and is therefore used for the specification of 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 in advance and avoided. Test tools for ARINC 825 networks must be able to read this communication profile database and interpret it correctly.

Gateways to other networks

The Integrated Modular Avionics system architectures of modern commercial aircraft generally use different data buses with different properties. The data exchange between these data buses must be ensured by gateways , since the bandwidth and communication mechanisms of the networks concerned typically do not match. In order to support the design of the corresponding gateways between CAN and other networks, ARINC 825 defines a simplified gateway model and contains in-depth information on protocol adjustments, bandwidth management, data buffering and error handling.

Development guidelines

The ARINC Specification 825 contains a chapter with extensive development guidelines, which are intended to help system engineers and LRU developers to use ARINC 825 in accordance with the specification and in a permissible manner. The development guidelines document a wide range of experiences from the aviation industry, which have influenced the design of ARINC 825 to a considerable extent. However, the development guidelines are not about hard requirements, but rather recommendations that should help developers avoid potential weak points in the development of CAN-based systems for aircraft.

Effects on other standards

The consistency and correctness of the ARINC specification 825 was continuously checked with the help of a reference system during the design process, which took several years. All protocol functions were implemented in this reference system, tested against the specification and thus the integrity of ARINC 825 ensured. Due to this quality assurance procedure, which was used for the first time for ARINC specifications, the Airlines Electronic Engineering Committee (AEEC) has decided that all future ARINC specifications that use CAN will be based on ARINC 825. Examples of this are the ARINC 826 Data Load and the ARINC 812 Galley Insert Communication Standard. Technical development requirements from Airbus already define ARINC 825 for a large number of systems for the new Airbus A350 . CANaerospace remains one of the foundations of ARINC 825 as an "11-bit" alternative and is continuously developed, with increased compatibility with ARINC 825 being ensured from CANaerospace version 1.8.

Individual evidence

1. ^ Stock Flight Systems
2. ↑ ^{a b} ARINC 825-2 Specification . ARINC . Retrieved on June 7, 2012.  ( Page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.  
3. ↑ Application Note AN-ION-1-0104 (PDF; 242 kB) In: CAN-based Protocols in Avionics . May 5, 2010. Retrieved October 7, 2010.
4. ↑ ARINC 825 website ( Memento of the original from February 15, 2013 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.