CANaerospace Resources
.
To obtain more info about the CANaerospace protocol, please download the following PDF´s:
.
* CANaerospace - Nato per lo Spazio
* AVIONICS - CAN Bus in Aviation
.
.
CANaerospace Newsletter
.
The CANaerospace newsletter informs about current developments involving the CANaerospace data bus protocol. The most recent issues can be downloaded here:
.
* CANaerospace Newsletter 0102
* CANaerospace Newsletter 0103
© 2004 A2TECH - Advanced Aviation Technology * Via Leopardi, 16 * 37019 Peschiera d/G (VR) * Italy * Phone: +39-045-6409967 * Fax: +39-045-6402132
CANaerospace is an extremely lightweight protocol/data format definition which was designed for the highly reliable communication of microcomputer-based systems in airborne applications via Controller Area Network (CAN). The purpose of this definition is to create a standard for applications requiring an efficient data flow monitoring and easy time-frame synchronisation within redundant systems. The definition is kept widely open to allow implementation of user-defined message types and protocols.
.
The CANaerospace data format definition specifies 5 basic message types, which are used for different network services. Each message type has an associated CAN-ID range defining the message priority. The identifier assignment within the specified ranges is at the user's discretion. A proposal for an identifier list addressing commonly used data objects and devices in aerospace applications has been made, however.
.
For data representation, the most commonly used basic data types are defined. Additionally, combined data types (i.e. two 16 bit and four 8 bit data types in one CAN message) are supported, others can be added to the type list as required.
.
The coding of the data into the CAN message bytes is according to the "Big Endian" definition as used by Motorola 68K, SPARC, PowerPC and MIPS architectures. All CAN messages consist of 4 header bytes for identification and between 1 and 4 data bytes for the actual data.
.
The general message format uses a 4 byte message header for node identification, data type, message code and service code (for normal operation data (NOD), the service code field is user-defined). This allows identification of each message by any receiving unit without the need for additional information. Every message type uses the same layout for the CAN data bytes 0-3, while the number and the data type used for CAN data bytes 4-7 is user-defined:
CANaerospace Informations
Node-ID (Byte 0): Some system architectures employ backup units which become active if the main unit fails. The Node-ID allows to immediately identify this situation and react accordingly (i.e. mode change within redundancy management).
Data Type (Byte 1): CANaerospace supports multiple data types for every message. Backup units (or units from different vendors) may use different data types while performing identical functions. Specifying the data type with each message allows automatic system configuration, even during runtime.
Service Code (Byte 2): For Normal Operation Data, this byte should continously reflect the status of the data (or the transmitting unit) to support data integrity monitoring within receiving units. With this information, the validity of data is known at any given time.
Message Code (Byte 3): Message numbering allows to detect if messages are missing and if the transmitting unit is operating properly. Also, it can be used to compare the "age" of messages from redundant sources.
.
To support the interface definition, the most commonly used data for aerospace application has been assigned fixed identifiers. For this purpose, the available identifiers for normal operation data have been grouped for the various aircraft systems, thereby reserving the identifier range 200-1499. The identifiers from 1500-1799 are unassigned and may be used for other aerospace specific data at the user's discretion. Note that CANaerospace also allows other identifier distributions aside from the default definition.