- 1 ARINC Specification 825 - The General Standardization of CAN for Airborne Use
- 2 Role of CAN in Commercial Air Transport and General Aviation Aircraft
- 3 Physical Interface
- 4 Identifier Usage and Communication Layers
- 5 Interoperability
- 6 Bandwidth Management
- 7 Communication Profile Database
- 8 Gateways between ARINC 825 and other Networks
- 9 Design Guidelines
- 10 Participation
- 11 Outlook
- 12 External links
- 13 References
ARINC Specification 825 - The General Standardization of CAN for Airborne Use
Controller Area Network (CAN) found its way into aerospace applications because of its cost effective and efficient networking capability for systems to share data across a common media. The ability of CAN to transmit data, across a shared shielded twisted pair cable, has advantages in terms of weight savings at the aircraft integration level. Additionally, the CAN physical layer protocol specification provides error recovery and protection mechanisms that make this data bus standard attractive to aviation applications. Newer commercial air transport aircraft like the Airbus A380 or the Boeing 787 already accommodate CAN networks for all sorts of functions including flight deck systems, engine control and flight control systems. The Airlines Electronic Engineering Committee initiated the development of ARINC Specification 825. ARINC 825 goal is to ensure interoperability and to simplify interoperation of CAN subsystems with other airborne networks.
Role of CAN in Commercial Air Transport and General Aviation Aircraft
Current commercial air transport aircraft system architectures have incorporated CAN as an ancillary subsystem bus to ARINC Specification 664, Part 7 Deterministic Ethernet and Integrated Modular Avionics (IMA) architectures. For these aircraft, CAN has been used to link sensors, actuators and other types of avionics devices that typically require low to medium data transmission volumes during operation. In this role, CAN complements higher capacity networks that support systems controlling the flight deck information flow and presentation. General Aviation system architectures employ CAN as one of the major avionics buses or even as the avionics backbone network. In this role CAN may have to fulfill all requirements of a flight safety critical network. It may be used as a primary or ancillary avionics network and was designed to meet the following requirements:
- Easy connections of local CAN networks to other airplane networks.
- Minimal cost of implementation and cost of change over time.
- Maximum interoperability and interchangeability of CAN connected Line-replaceable units (LRU).
- Configuration flexibility: easy addition, deletion, and modification of bus nodes, without undue impact onto other LRUs.
- Simplified system and network boundary crossing for both parametric and block data transfers.
- Integrated error detection and error signaling.
- Support for system level functions such as on-board data load and airplane health management.
To ensure interoperability and reliable communication, ARINC 825 specifies the electrical characteristics, bus transceiver requirements and data rates with the corresponding tolerances based on ISO 11898. The bit timing calculation (baud rate accuracy, sample point definition) and robustness to electromagnetic interference are given special emphasis. Also addressed within ARINC 825 are CAN connector and wiring considerations. The data rates supported by ARINC 825 are 1000 kbit/s, 500 kbit/s, 250 kbit/s, 125 kbit/s and 83.333 kbit/s.
Identifier Usage and Communication Layers
ARINC 825 is based on CAN 2.0B using extended frames (29-bit identifiers) which provide an adequate number of bits to divide the identifier into several sub-fields. These sub-fields are key to employing the identifier bits not only for the data object identification and transmission prioritization inherent to CAN but also for the purpose of creating a standardized application layer. CAN communication using 11-bit identifiers may coexist on an ARINC 825 bus if it is free of potential deadlock scenarios caused by single source bus masters.
ARINC 825 defines additional ISO layer 3, 4 and 6 functions to support logical communication channels, one-to-many/peer-to-peer communication and station addressing. To accomplish this, the 29-Bit CAN identifier is given a special structure for ARINC 825 (see Figure 1). Logical Communication Channels (LCCs) provide these independent layers of communication (see Figure 2).
To support interoperability in airborne systems, ARINC 825 includes:
- Data Endian definition (Big Endian exclusively)
- Data Type definition (Boolean, Integer, Floating-Point, ....)
- Aeronautical Axis System and Sign Convention (ISO1151/EN9300)
- Engineering Unit definitions (m, kg, ....)
- Aircraft Function definition (Flight State, Air Data, ....)
The aircraft function definitions used to identify source and destination of messages are derived from the Air Transport Association (ATA) aircraft system chapters. This helps system engineers to assign the proper functions for their systems based on definitions well known in aeronautics since decades.
ARINC 825 uses a bandwidth management concept known as "Time Triggered Bus Scheduling". This concept provides a means of computing the bus load based on the number of messages in a network segment and adjusting their transmission rates. Bandwidth management minimizes peak load scenarios and jitter caused by the CAN bus arbitration. Applying this concept, it can be demonstrated that ARINC 825 networks behave predictably and are able to fulfill the requirements for flight safety critical systems. For ensuring this under fault conditions the system designer has to define the behaviour under these conditions (such as high occurrence of error frames and avoidance of priority inversion).
ARINC 825 may be used for systems classified up to Design Assurance Level (DAL) A if the effect of the loss of one bus does not present a hazard exceeding the classification "major". Figure 3 shows an example of two ARINC 825 nodes operating in accordance with the Time Triggered Bus Scheduling concept.
Communication Profile Database
ARINC 825 uses a communication profile database for the description of integrated networks. A communication profile is created for each LRU in a human readable file format, since supplement 1 based on XML 1.0. The combination of all LRU communication profiles for a given network describes the entire bus traffic and provides a valuable means for specification and verification of ARINC 825 networks. An analysis of the communication profile database allows to detect potential network problems at an early stage. ARINC 825 test tools must be able to read the communication profile database and interpret network data accordingly.
Gateways between ARINC 825 and other Networks
Commercial air transport aircraft Integrated Modular Avionics system architectures use multiple networks with different characteristics which have to exchange data with each other using gateways. Typically, bandwidth and communication principles of the involved networks differ widely. To support the design of gateways between CAN and other networks, ARINC 825 specifies a gateway model and provides substantial information about protocol conversion, bandwidth management, data buffering and fault isolation.
ARINC Specification 825 contains design guidelines intended to help system engineers and CAN LRU designers implement an ARINC 825 CAN network. The guidelines are general network design criteria to be considered when designing an ARINC 825 network; they are not requirements but rather the recommendations to avoid potential design traps a network designer may encounter.
ARINC 825 was developed in committee primarily supported by the following companies and representatives.
- Airbus (Ralph Knüppel: Co-chair, Nathalie Courmont, Holger Wolf)
- Boeing (Edgar L. von Trotha III: co-chair)
- GE (Don Hodges)
- Stock Flight Systems (Michael Stock)
- CMC Électronique (Steven Ford)
- Microflight (James Meer)
- Mentor Graphics (Antal Rajnak, Istvan Horvath, Martin Ottosson)
- Vector Informatik (Timo Nußbaumer)
The material included in ARINC Specification 825 was verified during the drafting process using a reference hardware/software system. The Airlines Electronic Engineering Committee completed this activity in 2011. ARINC 825 is a voluntary standard. Interested parties may contact ARINC for additional information.
As of this edit, this article uses content from "ARINC 825", which is licensed in a way that permits reuse under the Creative Commons Attribution-ShareAlike 3.0 Unported License, but not under the GFDL. All relevant terms must be followed.