ARINC 825

For cross-linking of electronic components Bus systems are used in the aerospace industry for many years. In newer systems, thereby gaining Controller Area Network ( CAN) in importance. The specification ARINC 825 ARINC standardization organization describes the recommended use of CAN in civil aircraft. Use this specification is far from 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. The large number of different physical interfaces, data formats, communication mechanisms and the insufficiently coordinated use of CAN identifiers, the effort for system integration from the perspective of the aircraft manufacturer has however made out to be increasingly problematic. This knowledge has already led in 2004 to a joint initiative of Airbus and Boeing, which had the creation of a single CAN standard for commercial aviation to the destination. As standardization organization ARINC was chosen and headed 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 Aerospace, Rockwell Collins and Stock Flight Systems formed. This group developed on the basis of CANaerospace within three years of the ARINC Specification 825, which is first used in the Airbus A350. ARINC 825 was created through the collaboration of avionics engineers from four nations, all of which are already 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, the result of the support of the major aircraft manufacturers Airbus and Boeing has a very significant influence on the development of CAN in the aviation sector.

ARINC 825 provides not only an aviation-specific high-level protocol itself but it CAN a whole and also describes the self-implemented in the CAN controllers levels 1 and 2 of the CAN protocol. It also contains an extensive chapter, are defined in the development guidelines for CAN in the aviation sector. These guidelines include the physical bus connection, but also contain significant and substantial information related to the programming of CAN controllers and the use of as defined in ARINC 825 communication mechanisms. In particular, the prevention and treatment of faults in CAN - systems is discussed in detail and with additional hints for the design of fault-tolerant systems. In this respect goes far beyond other ARINC 825 ARINC specifications and also provides a kind of development manual for CAN systems in aircraft represents the ARINC 825 specification was first published in November 2007, the current version is the supplement 2

Properties

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

  • Easy to connect local CAN buses to other aircraft networks
  • Lowest possible costs related to the implementation and changes over the lifetime of the aircraft
  • Highest possible interoperability and interchangeability of CAN - connected line- replaceable units ( LRUs )
  • Maximum flexibility with respect to the removal, addition or modification of individual bus while avoiding preventable effects on other bus users
  • Support network of cross- communication for individual parameters and block data transfers via gateways
  • Integrated error detection and signaling
  • Support system-wide functions such as configuring individual bus and airplane health analysis ( " Aircraft Health Management " )

Physical interface

To ensure interoperability and reliable data exchange, ARINC defined 825 electrical characteristics, bus interface requirements and data transfer speeds including appropriate 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 ). The 825 supported by ARINC Data transmission speed is 1000 kbit / s, 500 kbit / s, 250 kbit / s, 125 kbit / s and 83 333 kbit / s

Network layers

ARINC 825 builds regarding the communication mechanisms in many ways to CANaerospace, but used exclusively Extended ( 29-bit ) identifier. This allows a portion of the identifier bits are used for mapping the typical commercial aviation large number of different systems, and to ensure interoperability even in very complex systems.

The CAN specification stipulates that outgoing CAN messages are always received by all connected bus, a communication principle, which is also referred to as the " Anyone - to-many " (ATM). The advantage of this concept is the inherent data consistency between all bus stations. Both periodic and aperiodic transmission of the messages during normal operation are possible. The disadvantage of the exclusive definition of the CAN specification of ATM is that it CAN is no addressing participants by definition that (PTP ) is in turn the basis for " peer -to-peer " communication. For use in the aviation sector with its high demands on continuous monitoring system but is the ability to communicate with individual bus, extremely important. ARINC 825 therefore provides the necessary protocol functions to enable PTP communication. It also allows for implementing additional functions of the ISO / OSI layers 3, 4 and 6 is made possible, which in turn generate logical communication channels (Logical Communication Channel LCC) and corresponding communication types ( ATM PTP) allows, as shown in Figure 1.

Figure 1: CAN identifier structures for ARINC 825

The simultaneous use of the ATM and the PTP communication of the CAN network requires the introduction of different layers which permit mutually independent communications. These are produced by the ARINC 825 by a group of the CAN identifier as shown in Figure 2 is performed. The resulting structure creates logical communication channels (Logical Channel Communication, LCC) and assigns it to a particular type of communication ( ATM, PTP) to. Custom LCCs give the user great freedom in this case, to allow 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 are not divided into additional fields for ARINC 825, which have the following meaning:

  • Function code identifier ( FID source or server / client FID) identifies the system or subsystem in which the message in question has its origin, in the case of server FID and the receiving system or subsystem. The FID corresponds largely to the air used in the aviation industry for many decades Transport Association ( ATA) chapter, the ARINC 825 specification, the allocation of the ATA - section with the corresponding identifier bit combination ( and associated message priority ) according to the importance of the individual aircraft systems in place. In addition, various FIDs are, for example, for temporary testing / maintenance systems or for use by others, reserved for 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 communications, while it indicates the direction of data transfer between client and server for PTP communication. For service requirements (ie sent by the client messages ), this bit is set to 1, while it is set for the server's responses to 0.
  • Only the local bus (LCL) bit is set to 1 for messages, which remain within the same network segment, and should not be passed through gateways to other networks.
  • The Private ( PVT) bit is set to 1 for such messages, which have no meaning for bus users that were not explicitly programmed for processing these messages. Messages in which the PVT bit is set are not usually described in the communication profile database and intended only for "private" use between selected bus stations.
  • The Data Object Code (DOC) for ATM communication specifies the parameters sent with the message. The exact description of all parameters with respect to their properties ( physical unit, data type, repetition, etc. ) are described in the relevant communication profile database.
  • The Redundancy Channel Identifier (RCI) defines which redundancy channel assigned to the message in question. ARINC 825 supports redundant systems in order to grade four, the RCI allows to send, for example, redundant messages on a single bus, and thus to overcome redundancy jumps in the system in a simple manner.
  • The server identifier ( SID) defines the bus node (or an equivalent function in a bus station ), which provides a service available which is available as part of the Node Service Concept on the basis of PTP communication. The combination of SID, Server FID and RCI forms taken together are a Node Identifier ( NID). This NID provides the unique address of a server on the network.

PTP communication it allows, in addition to the "normal" data flow in a system temporarily or permanently establish interactions between individual bus and also to re-dissolve, which network services are enabled to " client / server " basis. This can run in parallel several of these interactions, and each bus can be both client and server for certain interactions with others. Using this mechanism, in ARINC 825 referred as "Node Service Concept ", for example, system functions in a transparent manner through various participants distribute or control the dynamic reconfiguration of an entire system to increase reliability in case of failure in the network. Node Service Concept distinguishes between connection-oriented and connectionless interactions similar to the case of TCP / IP and UDP / IP Ethernet.

Data representation

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

  • Data format definition (excluding 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 subdivision air vehicle functions is among other things used 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 in the system design specifications, are used in the aerospace industry for decades.

Time behavior

ARINC 825 uses the familiar from CANaerospace and " Time Triggered Bus Scheduling " specified bandwidth management concept for both ATM and PTP communication. This concept is based on limiting the number of CAN messages that are allowed to send a bus station within a defined during the preliminary development of the overall system time frame ( Minor Time Frame ) and to a maximum of 50% utilization of the available bandwidth. This ensures that the sending no message is delayed for a specified time out. The maximum number of sent CAN messages within a minor time frame may be different than bus users to bus users and can provide a certain " reserve" for future expansion. Time Triggered Bus Scheduling makes use of the fact that not all CAN messages must be sent in a system with the same predetermined by the Minor Time Frame renewal rate. The definition of integer multiples of the predetermined by the Minor Time Frame renewal rate and associated " transmission slots " can be a much larger number of CAN messages send in a predictable manner as if they were all tied to the Minor Time frame itself.

Time Triggered Bus Scheduling requires that holds each bus at any time to the predetermined transmission scheme, so never sent more than the specified maximum number of messages for him within a minor time frames. However, this does not mean that the nodes must be synchronized in time with respect to their transmission times or the sequence of transmission of their messages. Figure 3 shows an example of the transmission scheme of ARINC 825 network with two bus devices that asynchronously their messages, send in an alternating sequence and at varying time points within their minor time frames. In application of this concept can be demonstrated that a ARINC 825 network behaves predictably and meets the requirements of a flight safety critical system. In order to maintain this even under fault conditions, requirements must be of the system designer to be made, as with disorders (eg. High incidence of error frames ) deal.

ARINC 825 can therefore be used for systems up to Design Assurance Level ( DAL) A, provided that the loss of a single network has no effect, their classification is classified higher than " major".

Figure 3: Simplified ARINC 825 transmit scheme with two bus devices

Communication profile database

For ARINC 825 content and format of the payload has been completely left to the user. The lack of a self-identifying data format as in CANaerospace made ​​it necessary therefore to ensure interoperability in a different way. ARINC 825 is therefore used for the unique and cross-system network description a so-called " communication profile database ". For this, the ARINC 825 specification contains the description of a communication profile file format, from 1 Supplement on the basis of XML 1.0, which is to create for each bus. The totality of the communication profiles of all network devices in a given ARINC 825 network describes the entire bus and thus serves the specification of a network, but also the analysis for approval Wecke well as a basis for acceptance and integration testing. A detailed analysis of such a communication profile database allows us to identify potential network problems before they occur and avoid them. Test tools for ARINC 825 networks have to be able to read this communication profile database and interpret correctly.

Gateways to other networks

The Integrated Modular Avionics system architectures of modern commercial aircraft generally use different data buses having different properties. The exchange of data between these data buses must be ensured through gateways, as bandwidth and communication mechanisms of the relevant networks typically do not go together. To support the design of the corresponding gateway between CAN and other networks, ARINC 825 defines a simplified gateway model and contains profound information regarding protocol adjustments, bandwidth management, data buffering and error handling.

Development Guidelines

The ARINC 825 specification contains a section with extensive development of guidelines that will help system engineers and LRU developers to use ARINC 825 specification- compliant and in zulassbarer way. The development policy document a wide-ranging collection of experiences from the aerospace industry, which have influenced the design of ARINC 825 to a considerable extent. However, it is in the development guidelines not strict requirements, but to provide recommendations that will help developers to avoid potential weak points in the development of CAN-based systems for aircraft.

Impact on other standards

The consistency and accuracy of ARINC 825 specification was reviewed during the design process will take several years continuously with the aid of a reference system. In this reference system, all protocol functions have been implemented, tested against the specification and ensure the integrity of ARINC 825. Due to this quality assurance procedure for ARINC specifications for the first time applied the Airlines Electronic Engineering Committee ( AEEC ) has decided that all future ARINC specifications that use CAN, will be based on ARINC 825. Examples include the ARINC 826 Data Load and ARINC 812 Galley insert Communication Standard. Technical development requirements of Airbus define ARINC 825 already for a variety of systems for the new Airbus A350. CANaerospace remains as one of the foundations of ARINC 825 continue to receive a " 11-bit " alternative and is continually being developed, although as of version 1.8 CANaerospace an increased compatibility with ARINC 825 is ensured.

Avionics Full-Duplex Switched Ethernet Client (computing) DO-178B
77239
de