CANaerospace

CANaerospace is on Controller Area Network ( CAN) protocol aufsetzendes for control electronics in aviation and also defines the hardware interface. It was designed and developed in 1998 by Stock Flight Systems. Because of its open-source approach CANaerospace first came very quickly in the aviation research into the use and took regarding CAN - based systems, the further development of the aviation industry in many ways anticipated (see 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 by defined hardware interfaces, network layers, security mechanisms, data types and coordinate system definitions. CANaerospace has since been continuously developed, is widely used in the aerospace industry worldwide and has also been published by the U.S. National Aeronautics and Space Administration NASA as standard. A key research project in which a large number CANaerospace networked systems is used, the Stratospheric Observatory For Infrared Astronomy ( SOFIA ), a Boeing 747SP with a 2.5 m reflecting telescope for infrared astronomy. Even in the professional flight simulation CANaerospace prevailed and is used to connect simulation cockpits complete as that of the Euro Fighter Typhoon with the central simulation computers. In Italy CANaerospace is used in UAVs. Furthermore CANaerospace serves as a communication network of different modern integrated avionics systems for general aviation.

CANaerospace closes the gap between the implemented in the CAN controller CAN protocol and the special requirements of distributed systems in aircraft. An important criterion in the definition of CANaerospace was to enable a cost-effective implementation of the Protocol in Integrated Modular Avionics intelligent (IMA ) units. The reason for this is that in missions or flight safety critical aircraft systems whose predictable and correct function must be demonstrated, which - among other requirements - on the level of development requires the creation of quality-assured software. Which are necessary to ensure the quality and the relevant licensing requirements (eg, DO- 178B ) required procedures Although different in scope with regard to the possible consequences of failure of that system; generally increases the cost but still at least proportionally with the circumference of the appropriate software code. Because of time and cost for the software quality assurance particularly in systems that must meet very high reliability requirements, can be extremely high, is a "lightweight " protocol especially in these cases, a decisive advantage. But the - often used in an aircraft in large numbers - smaller systems with lower requirements benefit from it.

Basic Properties

The essential properties of CANaerospace are:

• Democratic Network: In CANaerospace there is no prescribed " master / slave" relationships between network participants. Each station has at any time basically the same rights with regard to the participation in the bus. The lack of a " bus master " eliminates the associated potential single point of failure in the system.

• Selbstidentifizierendes message format: Each CANaerospace message contains information about the type of data sent and thus the identification of the bus station, which sent the message. This allows the message by each receiving bus users interpret clearly.

• Continuous Nachrichtennumerierung: CANaerospace Each message contains a sequence number, which allows the coherent processing of redundant data from the receiving bus stations.

• Message status information: CANaerospace messages contain information about the integrity of the data content. Characterized the receiving bus user be able to judge the quality of the data obtained and to respond accordingly.

• Signaling of exception or error states: CANaerospace provides a mechanism that allows each bus signaling of exceptions or error conditions by appropriate CAN messages.

• Responsiveness of selected bus devices: CANaerospace supports the exchange of messages between certain bus stations in the sense of a general command interface. This is for example the verification of the integrity of the network or bus stations, the exchange of block-oriented messages or similar operations which interactions between two or more bus users, without requiring that participate not concerned about it.

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

• Ease of Implementation: The software overhead for implementing CANaerospace is extremely low. This is the testing and certification effort, particularly with regard to complex mission- or safety-critical systems is minimized.

• Expandability: All definitions of CANaerospace are user upgradeable to offer the greatest possible flexibility with respect to future developments.

• Free Availability: To use the CANaerospace protocol is no cost. The specification can be downloaded from the Internet.

Network layers

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. CANaerospace therefore provides the necessary protocol functions to enable PTP communication.

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 CANaerospace called "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.

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 generated by CANaerospace by a group of the CAN identifier is performed as shown in Figure 1. 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 CANaerospace according to his needs.

Figure 1: Logical communication channels of CANaerospace

Of course, the CAN identifier ranges in Figure 1 also have the corresponding effect on the priority of the various communication channels in case of bus arbitration. For this reason, the communication channels are ordered according to the relative importance of each other:

• Emergency Event Data Channel (EED ): This communication channel messages are sent, which must be sent as directly as possible and therefore a high priority. Associated with this are usually events that require a fast system response ( for example, system degradation or relocating certain functions to other bus nodes). Only ATM communication is used for Emergency Event Data.

• High / Low Priority Node Service Data Channel ( NSH / NSL ): These channels of communication client / server interactions by PTP communication can be realized. The corresponding services can both connection-oriented and connectionless also run. The NSH / NSL communication channels are also used to support test and maintenance functions.

• NORMAL OPERATION Data Channel (NOD ): This communication channel is used for the transmission of the operational aircraft data, which are obtained in the normal operation of the system. These messages can both synchronously and asynchronously, and are sent at predetermined intervals on the system architecture. All messages that are not associated with other communication channels must use this channel.

• High / Low Priority User-Defined Data Channel ( UDH / UDL ): These communication channels are available for custom messages are available, which can not be ship within the other communication channels due to their properties without violating their definition. As long as this set identifier range is observed, message content and the allocation of identifiers can be specified by the user. Both ATM and PTP communication is permitted. In order to limit the interoperability not too strong but is recommended as far as possible, to use other communication channels. The use of user-defined messages should remain the exception.

• Debug Service Data Channel ( DSD): Debug Service Data are messages which are used for download development tools in the course of development or in special cases, such as software and will not be shipped during normal operation. The contents of the corresponding message is completely user- defined.

Data representation

Since the majority of real-time computer systems used in aircraft is based on " big endian " processor architectures, these data arrangement was consequently set for CANaerospace. For the "Big Endian" - data arrangement, the most significant bit of a date of any length is left-aligned and is the first CAN message (see Figure 2). CANaerospace is designed for standard (11 bits ) identifier, but may also be implemented on the basis of extended ( 29 bits) identifiers. Bits 12-28 of the CAN identifier were up to version 1.7 used by CANaerospace for redundancy, as of version 1.8 the distribution of these bits on the compatibility with ARINC 825 is aligned.

Figure 2: Big endian data arrangement in sending CANaerospace News

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 header and a message of up to 4 bytes long parameter share.

Figure 3: Selbstidentifizierendes CANaerospace data format

The waiver appears at first glance forward to using all the maximum 8 bytes of the CAN messages for parameters to be inefficient, on the other hand met the Message Header important purposes, which was to be achieved with any other conception through the use of user data bytes: The CANaerospace message header allows the receiving bus users to analyze incoming CAN messages immediately after their receipt in terms of origin, type of data integrity and time of their creation. To this end, no other information of the bus except the knowledge of valid system identifier distribution needs. The individual header bytes have the following meaning:

• Node ID: The Node Identifier identified in the case of ATM communication (EED, NOD) the bus station, which has sent the message, in the case of PTP communication ( NSH, NSL), however, the addressed bus node (client or server). Node.ID " 0" is used in the latter case to address all nodes in a network simultaneously.

• Data Type: The data type defines how the contents of the message in question is to be interpreted in terms of its data format ( eg, number of bytes in integer formats, its complement or floating point number ). The corresponding encoding of the data type is in this case the CANaerospace Data Type List extracted, which also allows for custom extensions.

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

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

The header thus contains important supplementary information in order to analyze the integrity of the associated parameters for use in safety-critical, and especially in the redundantly designed systems. In addition, significantly improved in this way, the interoperability of bus devices from different manufacturers. Finally, the evaluation of the header simplifies the analysis of CANaerospace networks regarding the status of the individual nodes, which is extremely helpful for testability and maintainability of the often complex systems in aircraft.

To further improve the interoperability CANaerospace defined in addition to the data format and aviation-specific axis systems with their respective signs and physical units. Together with the predefined identifier distribution list are thus all messages in a CANaerospace network described distinctive. The default identifier allocation allocates the identifier range 300-1799 and has the different identifiers unique parameters. Figure 4 shows a part of this distribution.

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

Users can use them when needed Identifier own distribution lists, which allows the mandatory -to-implement in all CANaerospace bus stations "Node Identification Service " to query all devices connected to a network with respect to the distribution identifier used by them and thus avoid inconsistencies. Both the identifier distribution as well as the lists of data types and physical units also have custom sections where users can make the appropriate extensions.

Time behavior in CANaerospace networks

A special requirement for safety critical systems in aircraft is to be that their timing precisely defined, analyzed and tested, in order to meet formal admission requirements. This requirement for the timing means, that the time response of such a system must be unique and predictable. The temporal precision with which the communication must vonstattengehen is dependent on the application and must be determined by an appropriate system analysis. Must be actually proved the aviation regulatory authorities (eg FAA, EASA) that a safety-critical system behaves predictably under all circumstances. This can be ensured with CAN in the moment in which the temporal pattern according to which all nodes send their messages, a concept for the distribution of available bandwidth follows. This is true despite 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 a variation of times will be shipped to the messages inherent is. But the decisive factor is that the concept for the management of bandwidth ensures that no temporal variations occur which are not determinable.

CANaerospace defined such as " 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 5 shows an example of the transmission scheme of a CANaerospace network with two bus devices that asynchronously their messages, send in an alternating sequence and at varying time points within their minor time frames. The sample meets the requirements of the Time Triggered Bus Scheduling in full.

Figure 5: Simplified CANaerospace transmit scheme with two bus devices

When using time-triggered bus scheduling can be demonstrated that a CANaerospace network under the condition behaves predictably, that no more than 50 % of the bandwidth taken by CAN error frames to complete. In order to maintain this under stronger fault conditions, stipulations must be made by the system designer, how to deal with these problems.