CANaerospace

The logo

CANaerospace is a controller area network (CAN) protocol for control electronics in aviation and also defines the hardware interface . It was designed and developed by Stock Flight Systems in 1998. Due to its open source approach, CANaerospace was initially used very quickly in aerospace research and anticipated further developments in the aerospace sector in many ways with regard to CAN-based systems (see also ARINC 825 ).

Background of the development

CANaerospace supports the concept of Line Replaceable Units (LRU) and standardizes the communication between LRUs at the system level, for example through defined hardware interfaces, network layers , security mechanisms, data types and coordinate system definitions . CANaerospace has been continuously developed since then, is used in the aviation industry worldwide and has also been published as a NASA standard by the US National Aeronautics and Space Administration . A major research project that uses a variety of CANaerospace-networked systems is the Stratospheric Observatory For Infrared Astronomy ( SOFIA ), a Boeing 747SP with a 2.5 m reflector telescope for infrared astronomy. CANaerospace has also established itself in professional flight simulation and is used to connect complete simulation cockpits such as that of the Eurofighter Typhoon with the central simulation computers. In Italy, CANaerospace is used in UAVs . CANaerospace also serves as a communication network for various modern integrated avionics systems for general aviation .

CANaerospace closes the gap between the CAN protocol implemented in the CAN controller and the special requirements of distributed systems in aircraft. An essential criterion in the definition of CANaerospace was to enable a cost-effective implementation of the protocol in intelligent Integrated Modular Avionics (IMA) units. The reason for this is that mission- or flight safety-critical systems in aircraft must be proven to function correctly and predictably, which - in addition to other requirements - requires the creation of quality-assured software at the development level. The procedures necessary to ensure quality and required in the relevant approval regulations (e.g. DO-178B ) differ in their scope with regard to the possible consequences in the event of failure of the relevant system; In principle, however, this effort always increases at least proportionally with the size of the software code. Since the expenditure of time and money for software quality assurance can be extremely high, especially in systems that have to meet very high reliability requirements, a "lean" protocol is of decisive advantage, especially in these cases. But also the smaller systems with lower requirements - often used in large numbers in an aircraft - benefit from it.

Basic properties

The essential properties of CANaerospace are:

• Democratic network: In CANaerospace there are no prescribed "master / slave" relationships between the network participants. Every bus participant has the same rights in terms of participation in bus traffic at all times. The lack of a "bus master" eliminates the associated potentially singular source of error in the system.

• Self -identifying message format: Each CANaerospace message contains information about the type of data sent with it and the identification of the bus participant who sent the message. This means that the message can be clearly interpreted by each receiving bus participant.

• Continuous message numbering : Each CANaerospace message contains a sequential number, which allows the coherent processing of redundant data by the receiving bus participants.

• Message status information: CANaerospace messages contain information about the integrity of the data content. This enables the receiving bus subscribers to assess the quality of the data received and to react accordingly.

• Signaling of exceptional or error states: CANaerospace provides a mechanism that allows every bus participant to signal exceptional or error states through appropriate CAN messages.

• Accessibility of selected bus participants: CANaerospace supports the exchange of messages between certain bus participants in the sense of a general command interface. This is used, for example, to check the integrity of the network or bus participants, to exchange block-oriented messages or similar operations which require interactions between two or more bus participants without unaffected participants taking part.

• Predefined CAN identifier list: CANaerospace offers a predefined standard distribution of CAN identifiers for operational data, similar to the Mark 33 Digital Information Transfer Standard known in aviation. In addition to the standard distribution, lists defined by the user can also be used.

• Simple implementation: The software effort for implementing CANaerospace is extremely low. This minimizes the testing and certification effort, especially with regard to complex mission- or safety-critical systems.

• Expandability: All definitions of CANaerospace can be expanded by the user in order to offer the greatest possible flexibility with regard to future developments.

• Free availability: There are no costs for using the CANaerospace protocol. The specification can be downloaded from the Internet.

Network layers

The CAN specification provides that sent CAN messages are generally received by all connected bus users, a communication principle which is also referred to as "Anyone-to-Many" (ATM). The advantage of this concept is the inherent data consistency between all bus participants. Both the periodic and the aperiodic sending of messages during normal operation are possible. The disadvantage of exclusively setting the CAN specification to ATM is that, by definition, there is no subscriber addressing for CAN, which in turn represents the basis for "Peer-to-Peer" (PTP) communication. For use in the aviation sector with its high demands on continuous system monitoring, however, the ability to communicate with individual bus users is extremely important. CANaerospace therefore provides the necessary protocol functions to enable PTP communication.

PTP communication makes it possible, in addition to the "normal" flow of data in a system, to temporarily or permanently establish interactions between individual bus participants and also to resolve them again, which enables network services on a "client / server" basis. Several of these interactions can run in parallel, and each bus participant can be a client for certain interactions and a server for others at the same time . With the help of this mechanism, called "Node Service Concept" in CANaerospace, system functions can, for example, be transparently distributed over various participants in the network or the dynamic reconfiguration of an entire system can be controlled to increase reliability in the event of a fault. The Node Service Concept differentiates between connection-oriented and connectionless interactions, similar to the case of TCP / IP and UDP / IP for Ethernet .

The simultaneous use of ATM and PTP communication for CAN requires the introduction of different network layers that allow independent communication. These are generated by CANaerospace by grouping the CAN identifiers as shown in Figure 1. The resulting structure creates logical communication channels (Logical Communication Channel, LCC) and assigns them a certain type of communication (ATM, PTP). User-defined LCCs give the user a great deal of freedom in order to enable the implementation of CANaerospace according to his needs.

Figure 1: CANaerospace's logical communication channels

The CAN identifier areas in Figure 1 naturally also have the corresponding influence on the priority of the various communication channels in the case of bus arbitration. For this reason, the communication channels are arranged according to their relative importance:

• Emergency Event Data Channel (EED): Messages are sent via this communication channel, which must be sent as immediately as possible and therefore with high priority. This is usually associated with events that require a quick system reaction (for example system degradation or the relocation of certain functions to other bus users). Only ATM communication is used for emergency event data.

• High / Low Priority Node Service Data Channel (NSH / NSL): Client / server interactions are implemented using PTP communication via these communication channels. The corresponding services can be connection-oriented or connectionless. The NSH / NSL communication channels also serve to support test and maintenance functions.

• Normal Operation Data Channel (NOD): This communication channel is used for the transmission of the operational aircraft data that arise during normal operation of the system. These messages can be sent both synchronously and asynchronously and at intervals specified by the system architecture. All messages that are not assigned to other communication channels must use this channel.

• High / Low Priority User-Defined Data Channel (UDH / UDL): These communication channels are available for user-defined messages which, due to their properties, cannot be sent within the other communication channels without violating their definition. As long as the specified identifier range is maintained, the message content and the assignment of the identifier can be specified by the user. Both ATM and PTP communication are allowed. In order not to restrict interoperability too much, it is recommended, however, to use the other communication channels as much as possible. The use of user-defined messages should remain the exception.

• Debug Service Data Channel (DSD): Debug Service Data are messages that are used in the course of development or in special cases such as software downloads for development tools and are not sent during normal operation. The content of the corresponding messages is completely user-defined.

Data representation

Since the majority of the real-time computer systems used in aircraft are based on " Big Endian " processor architectures, this data arrangement was consequently also defined for CANaerospace. For the "Big Endian" data arrangement, the most significant bit of a data item of any length is left-justified and is sent first via CAN (see Figure 2). CANaerospace is designed for standard (11 bit) identifiers, but can also be implemented on the basis of extended (29 bit) identifiers. Bits 12-28 of the CAN identifier were used for redundancy up to version 1.7 of CANaerospace, from version 1.8 the division of these bits is geared towards compatibility with ARINC 825 .

Figure 2: Big Endian data arrangement when sending CANaerospace messages

A special feature of CANaerospace is the self-identifying message format, which is achieved by structuring the message content, as shown in Figure 3. This structure defines a 4-byte message header and a parameter portion up to 4 bytes long.

Figure 3: Self-identifying CANaerospace data format

At first glance, not using all of the maximum 8 bytes of the CAN messages for parameters appears to be inefficient; on the other hand, the message header fulfills important purposes that would have had to be achieved with a different concept by using user data bytes: The CANaerospace Message Header enables receiving bus participants to analyze incoming CAN messages with regard to origin, data type, integrity and time of their generation immediately after they have been received. Apart from knowledge of the identifier distribution valid in the system, no other information is required from the bus participants for this. The individual header bytes have the following meaning:

• Node-ID: In the case of ATM communication (EED, NOD), the node identifier identifies the bus participant who sent the message, but in the case of PTP communication (NSH, NSL) it identifies the bus participant addressed (client or server) . In the latter case, Node.ID "0" is used to address all bus participants in a network at the same time.

• Data Type: The data type defines how the content of the relevant message is to be interpreted with regard to its data format (e.g. number of bytes for integer formats, their complement or floating point number). The corresponding coding of the data type is taken from the CANaerospace Data Type List, which also allows user-defined extensions.

• Service code: For normal operation data (NOD) messages, the service code is intended to provide the receiving bus users with additional information regarding the integrity of the associated parameter. This can for example be the result of the continuous checking of a sensor, the determined accuracy of a GPS signal or the current validity information of a navigation system. With regard to PTP communication, the service code contains the node service code of the corresponding client / server interaction.

• Message code: For normal operation data (NOD) messages, the message code for each message per identifier is increased by one by the sending bus subscriber and jumps back to 0 after reaching the value 255. This allows receiving bus subscribers to identify missing or delayed messages and react accordingly. With regard to PTP communication, the message code is used for the detailed specification of the client / server interaction concerned.

The header therefore contains essential additional information in order to analyze the integrity of the associated parameters for use in safety-critical and especially in redundant systems. In addition, the interoperability of bus users from different manufacturers is significantly improved in this way. Last but not least, the evaluation of the header simplifies the analysis of CANaerospace networks with regard to the status of the individual bus participants, which is extremely helpful for testability and maintainability of the often complex systems in aircraft.

To further improve interoperability, CANaerospace not only defines the data format, but also aviation-specific axis systems with their respective signs and physical units. Together with the predefined identifier distribution list, all messages in a CANaerospace network are unmistakably described. The standard identifier distribution reserves the identifier range from 300 to 1799 and assigns unique parameters to the various identifiers. Figure 4 shows an excerpt from this distribution.

Figure 4: Extract from the standard identifier distribution from CANaerospace V 1.7

If necessary, users can use their own identifier distribution lists, whereby the "Node Identification Service", which must be implemented in all CANaerospace bus participants, allows all devices connected to a network to be queried with regard to the identifier distribution used by them, thus avoiding inconsistencies. Both the identifier distribution and the lists for data types and physical units also have user-defined sections in which users can make appropriate extensions.

Time behavior in CANaerospace networks

A special requirement for safety-critical systems in aircraft is that their time behavior must be precisely defined, analyzed and checked in order to meet formal approval requirements. This requirement on the time behavior means that the time behavior of such a system must be clear and predictable. The temporal accuracy with which the communication must take place depends on the respective application and must be determined by a corresponding system analysis. The aviation certification authorities (e.g. FAA , EASA ) must actually be shown that a safety-critical system behaves predictably under all circumstances. This can be ensured with CAN at the moment in which the time scheme according to which all bus users send their messages follows a concept for distributing the available bandwidth. This applies regardless of the fact that the controller area network, due to the variable message length (caused by bit stuffing) and the Carrier Sense Multiple Access / Collision Resolution ( CSMA / CR ) arbitration procedure, inherently varies the times at which messages are sent is. It is crucial, however, that the concept for managing the bandwidth ensures that no temporal variations occur that cannot be determined.

CANaerospace defines such a bandwidth management concept called "Time Triggered Bus Scheduling" for both ATM and PTP communication. This concept is based on a limitation of the number of CAN messages that a bus participant may send within a time frame (minor time frame) defined as part of the advance development of the overall system, as well as on a maximum of 50% utilization of the available bandwidth. This ensures that the sending of any message is not delayed beyond a specified time. The greatest possible number of CAN messages sent within a minor time frame can differ from bus participant to bus participant and can provide a certain “reserve” for future expansions. Time Triggered Bus Scheduling makes use of the knowledge that not all CAN messages in a system have to be sent with the same renewal rate specified by the minor time frame. The definition of integer multiples of the renewal rate specified by the minor time frame and the associated “transmission slots” allow a significantly larger number of CAN messages to be sent in a predictable manner than if these were all linked to the minor time frame itself.

Time Triggered Bus Scheduling requires that every bus participant adheres to the specified transmission scheme at all times, i.e. never sends more than the maximum number of messages specified for him within a minor time frame. However, this does not mean that the bus subscribers have to synchronize their transmission times or the order in which their messages are sent. Figure 5 shows an example of the transmission scheme of a CANaerospace network with two bus participants that send their messages asynchronously, in changing order and at different times within their minor time frame. The example fully meets the requirements of Time Triggered Bus Scheduling.

Figure 5: Simplified CANaerospace transmission scheme with two bus participants

When using Time Triggered Bus Scheduling, it can be demonstrated that a CANaerospace network behaves in a predictable manner, provided that no more than 50% of the bandwidth is used by CAN error frames. In order to maintain this even under severe error conditions, the system designer must specify how to deal with these faults.

Individual evidence

1. ↑ CANaerospace Specification . Stock Flight Systems . Retrieved December 17, 2010.
2. ↑ www.stockflightsystems.com
3. ↑ NASA AGATE Data Bus Specification . NASA . Retrieved December 17, 2010.
4. ↑ Brief overview of CAN-based avionics networks at www.avionics-networking.com , accessed on February 9, 2010.
5. ↑ Download page at www.stockflightsystems.com
6. ↑ Application Note AN-ION-1-0104 (PDF; 242 kB) In: CAN-based Protocols in Avionics . Retrieved December 17, 2010.