CANaerospace

CANaerospace is a higher layer protocol based on Controller Area Network (CAN) which has been developed by Stock Flight Systems in 1998 for aeronautical applications.

Background

CANaerospace supports airborne systems employing the Line-replaceable unit (LRU) concept to share data across CAN and ensures interoperability between CAN LRUs by defining CAN physical layer characteristics, network layers, communication mechanisms, data types and aeronautical axis systems. CANaerospace is an open source project, was initiated to standardize the interface between CAN LRUs on the system level. CANaerospace is continuously being developed further and has also been published by NASA as the Advanced General Aviation Transport Experiments Databus Standard[1] in 2001. It found widespread use in aeronautical research worldwide. A major research aircraft that employs several CANaerospace networks for real-time computer interconnection is the Stratospheric Observatory for Infrared Astronomy (SOFIA), a Boeing 747SP with a 2.5m astronomic telescope. CANaerospace is also frequently used in flight simulation and connects entire aircraft cockpits (i.e. in Eurofighter Typhoon simulators) to the simulation host computers. In Italy CANaerospace is used as UAV data bus technology.[2] Furthermore, CANaerospace serves as communication network in several general aviation avionics systems.

The CANaerospace interface definition closes the gap between the ISO/OSI layer 1 and 2 CAN protocol (which is implemented in the CAN controller itself) and the specific requirements of distributed systems in aircraft. It may be used as a primary or ancillary avionics network and was designed to meet the following requirements:

  • Democratic network: CANaerospace does not require any master/slave relationships between LRUs or a "bus controller", thereby avoiding a potential single source of failure. Every node in the network has the same rights for participation in the bus traffic.
  • Self-identifying message format: Each CANaerospace message contains information about the type of the data and the transmitting node. This allows the data to be unambiguously recognized at each receiving node.
  • Continuous Message Numbering: Each CANaerospace message contains a continuously incremented number which allows coherent processing of messages in the receiving stations.
  • Message Status Code: Each CANaerospace message contains information about the integrity of the data is conveying. This allows receiving stations to evaluate the quality of the received data and to react accordingly.
  • Emergency Event Signaling: CANaerospace defines a mechanism that allows each node to transmit information about exception or error situations. This information can be used by other stations to determine the network health.
  • Node Service Interface: As an enhancement to CAN, CANaerospace provides a means for individual stations on the network to communicate with each other using connection-oriented and connectionless services.
  • Predefined CAN Identifier Assignment: CANaerospace offers a predefined identifier assignment list for normal operation data. In addition to the predefined list, user-defined identifier assignment lists may be used.
  • Ease of Implementation: The amount of code to implement CANaerospace is very little by design in order to minimize the effort for testing and certification of flight safety critical systems.
  • Openness to Extensions: All CANaerospace definitions are extendable to provide flexibility for future enhancements and to allow adaptions to the requirements of specific applications.
  • Free Availability: No cost whatsoever apply for the use of CANaerospace. The specification can be downloaded from the Internet[3]

Physical interface

To ensure interoperability and reliable communication, CANaerospace 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 are CAN connector, wiring considerations and design guidelines to maximize electromagnetic compatibility.

Communication layers

The Bosch CAN specification itself allows messages being transmitted both periodically and aperiodically but does not cover issues like data representation, node addressing or connection-oriented protocols. CAN is entirely based on Anyone-to-Many (ATM) communication which means that CAN messages are always received by all stations in the network. The advantage of the CAN concept is inherent data consistency between all stations, the drawback is that it does not allow node addressing which is the basis for Peer-to-Peer (PTP) communication. Using CAN networks in aeronautical applications, however, demands a standard targeted to the specific requirements of airborne systems which implies that communication between individual stations in the network must be possible to enable the required degree of system monitoring. Consequently, CANaerospace defines additional ISO/OSI layer 3, 4 and 6 functions to support node addressing and unified ATM/PTP communication mechanisms. PTP communication allows to set up client/server interactions between individual stations in the network either temporarily or permanently. More than one of these interactions may be in effect at any given time and each node may be client for one operation and server for another at the same time. This CANaerospace mechanism is called "Node Service Concept" and allows i.e. to distribute system functions over several stations in the network or to control dynamic system reconfiguration in case of failure. The Node Service concept supports both connection-oriented and connectionless interactions like with TCP/IP and UDP/IP for Ethernet.

Enabling both ATM and PTP communication for CAN requires the introduction of independent network layers to isolate the different types of communication. This is realized for CANaerospace by forming CAN identifier groups as shown in Figure 1. The resulting structure creates Logical Communication Channels (LCCs) and assigns a specific communication type (ATM, PTP) to each of the LCCs. User-defined LCCs provide the necessary freedom for designers and allow the implementation of CANaerospace according to the needs of specific applications.

Figure 1: Logical Communication Channels for CANaerospace

As a side effect, the CAN identifier groups in Figure 1 affect the priority of the message transmission in case of bus arbitration. The communication channels are therefore arranged according to their relative importance:

  • Emergency Event Data Channel (EED): This communication channel is used for messages which require immediate action (i.e. system degradation or reconfiguration) and have to be transmitted with very high priority. Emergency Event Data uses ATM communication exclusively.
  • High/Low Priority Node Service Data Channel (NSH/NSL): These communication channels are used for client/server interactions using PTP communication. The corresponding services may be of the connection-oriented as well as the connectionless type. NSH/NSL may also be used to support test and maintenance functions.
  • Normal Operation Data Channel (NOD): This communication channel is used for the transmission of the data which is generated during normal system operation and described in the CANaerospace identifier assignment list. These messages may be transmitted periodically or aperiodically as well as synchronously or asynchronously. All messages which cannot be assigned to other communication channels shall use this channel.
  • High/Low Priority User-Defined Data Channel (UDH/UDL): This channel is dedicated to communication which cannot, due to their specific characteristics, be assigned other channels without violating the CANaerospace specification. As long as the defined identifier range is used, the message content and the communication type (ATM, PTP) for these channels may be specified by the system designer. To ensure interoperability it is highly recommended that the use of these channels is minimized.
  • Debug Service Data Channel (DSD): This channel is dedicated to messages which are used temporarily for development and test purposes only and are not transmitted during normal operation. As long as the defined identifier range is used, the message content and the communication type (ATM, PTP) for these channels may be specified by the system designer.

Data representation

The majority of the real-time control systems used in aeronautics employ "big endian" processor architectures. This data representation was therefore specified for CANaerospace as well. With big endian data representation, the most significant bit of any datum is arranged leftmost and transmitted first on CANaerospace as shown in Figure 2.

Figure 2: "Big Endian" Data Representation for CANaerospace

CANaerospace uses a self-identifying message format which is realized by structuring the message payload as shown in Figure 3. This structure defines a 4-byte message header and a 4-byte parameter section.

Figure 3: CANaerospace Self-Identifying Message Format

On first sight the use of 50% of the CAN message payload for purposes other than transmitting operational data may seem like a waste of bandwidth. However, the CANaerospace message header delivers valuable information which would require the use of message payload bytes also when realized otherwise: The header allows receiving stations to analyze received messages immediately with respect to origin, data type, integrity and creation time. To accomplish this, no further information except the knowledge of the CAN identifier assignment for the particular system is needed. The message header bytes have the following meaning:

  • Node-ID: For ATM communication (EED, NOD), the Node Identifier specifies the transmitting node. For PTP communication (NSH, NSL) it specifies the addressed node (client, server). For PTP communication, Node_ID "0" is used to address all stations in the network (multicast).
  • Data Type: The Data Type specifies how the payload of the message shall be interpreted with respect to its data type (i.e. floating-point data or number of bytes in case of integer data). The corresponding data type code is taken from the CANaerospace data type list which allows also user-defined data type definitions.
  • Service Code: For Normal Operation Data (NOD) the Service Code delivers information about the integrity of the parameter transmitted with the message. This may be the result of a continuous sensor built-in test, the current validity flag of a navigation signal or other parameter specific information. In case of PTP communication the Service Code specifies the service for the corresponding client/server interaction.
  • Message Code: For Normal Operation Data (NOD) the Message Code is incremented by one for each message with a particular CAN identifier by the transmitting node. After reaching the value of 255, the Message Code rolls over to zero. This allows receiving stations to determine missing or delayed messages and to react accordingly. Concerning PTP communication (NSH, NSL) the Message Code is used in conjunction with the Service Code to specify the service for the corresponding client/server interaction in more detail.

The above information contained in the CANaerospace message header contains important information to determine the integrity of the parameters for the use in flight safety critical systems and supports system redundancy. Additionally, it significantly improves the interoperability between LRUs of different vendors and allows the monitoring of CANaerospace networks concerning the status of the LRUs attached to it. For further interoperability, CANaerospace defines aerospace specific axis systems with the corresponding sign conventions and physical units. Together with the predefined identifier assignment list, these definitions describe the traffic in a CANaerospace network unambiguously. The CANaerospace Standard Identifier Assignment List reserves the CAN identifiers between 300 and 1799 and assigns parameters to them as shown in the excerpt of this list (Figure 4).

Figure 4: Excerpt from the Standard Identifier Assignment List of CANaerospace V 1.7

System designers may use self-defined identifier assignment lists. The mandatory "Node Identification Service" which each CANaerospace LRU has to respond to allows to scan the network for attached LRUs and their identifier assignment list code to avoid inconsistencies. The CANaerospace Standard Identifier Assignment List as well as the lists for data types and units provide user-defined sections which may be used by system designers to expand these lists according to their needs.

Bandwidth management

An essential characteristic of all flight safety critical systems is that their behavior has to be precisely defined, analyzed and tested to meet formal certification requirements. This characteristic is often misinterpreted as timing determinism but is in fact predictability. The degree of precision required for timing is specific to each application and has to be quantified by system analysis. The ultimate target to be reached, however, is that it may be demonstrated to certification authorities (i.e. FAA, EASA) that a safety critical system behaves predictably under foreseeable circumstances. Using CANaerospace, this predictability may be achieved.

CANaerospace sets forth a concept of managing the available bandwidth of a multi-drop CAN network to ensure predictable behavior for ATM and PTP communication which is called Time Triggered Bus Scheduling. Time Triggered Bus Scheduling is based on a limitation of the number of CAN messages that any node in the network may transmit within a minor time frame. The minor time frame is defined during initial system design. The maximum number of messages transmitted within one minor time frame may differ from node to node and contain growth potential if granted by system design. It is crucial to the Time Triggered Bus Scheduling concept that every node in the network adheres to its transmission schedule at all times when generating network traffic. It is neither required nor prohibited, however, that nodes in the network synchronize to other nodes concerning their message transmission order or transmission times.

CAN error frames may lead to unpredictable behavior if the bandwidth is consumed by error frames resulting from faults of the network or the nodes attached to it. Therefore, CANaerospace recommends to limit the bandwidth usage to 50% of the maximum bandwidth so that unpredictability is mitigated. While Time Triggered Bus Scheduling requires margins and does not optimize network bandwidth usage, it provides a safe and straightforward approach to build certifiable (predictable) systems. For ensuring this under fault conditions the system designer has to define the behaviour under these conditions (error frames and avoidance of priority inversion).[4] Applying the Time Triggered Bus Scheduling concept, it may be demonstrated that a CANaerospace network behaves predictably. Shown in Figure 5 is the transmission schedule of a CANaerospace network with two nodes transmitting their messages asynchronously, in alternating order and at random times within their minor time frames (worst-case scenario). This example utilizes 50% of the maximum bandwidth.

Figure 5: Simplified CANaerospace Transmission Scheme

Using Time Triggered Bus Scheduling, no message in this transmission schedule has a latency exceeding 50% of one minor time frame plus the duration of the longest message. Time Triggered Bus Scheduling reduces the effect of message priority due to the fact that the nodes on the network are required to meter their message transmissions.

Local oscillator tolerances and lack of time synchronization between the nodes will result in minor time frames drifting away from each other. This does not adversely affect message latencies as long as the duration of the minor time frame in all nodes matches closely. To ensure predictability, all aperiodic messages must be included in the bandwidth management calculations.

Time Triggered Bus Scheduling ensures adequate flexibility for increasing network traffic during the lifetime of the system if growth potential is planned. As an example, system design will allow nodes to be integrated into the network without affecting the existing nodes. Furthermore, the predictable behavior enforced by Time Triggered Bus Scheduling allows systems with different criticality levels to coexist on the same network.

gollark: Truly glorious.
gollark: `|Hello, World!|P` - Turi Hello World.
gollark: That image is quite something.
gollark: It, er, seems to be missing something.
gollark: The language would be named `⁡`. The command to run it would be `⁡`.

References
  1. "NASA AGATE Data Bus Specification". NASA.
  2. Short overview of CAN-based avionics protocols on www.avionics-networking.com
  3. "CANaerospace Specification" (PDF). Stock Flight Systems.
  4. "Application Note AN-ION-1-0104" (PDF). CAN-based Protocols in Avionics. 7 May 2010.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.