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:

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:

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:

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.

External links

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 - version of the 7/12/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.