CANaerospace


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

Background

CANaerospace supports airborne systems employing the Line-replaceable unit 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 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, a Boeing 747SP with a 2.5m astronomic telescope. CANaerospace is also frequently used in flight simulation and connects entire aircraft cockpits to the simulation host computers. In Italy CANaerospace is used as UAV data bus technology. 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 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

    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 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 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 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 and assigns a specific communication type 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 : This communication channel is used for messages which require immediate action and have to be transmitted with very high priority. Emergency Event Data uses ATM communication exclusively.
  • High/Low Priority Node Service Data Channel : 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 : 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 : 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 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 : 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 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, the Node Identifier specifies the transmitting node. For PTP communication it specifies the addressed node. For PTP communication, Node_ID "0" is used to address all stations in the network.
  • Data Type: The Data Type specifies how the payload of the message shall be interpreted with respect to its data type. 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 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 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 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: 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.