NASA - stockflightsystems.com

1 Interfacespecification for airborne CANapplicationsV data busRevision , (C) 1998-2006 Stock Flight SystemsRevision lists connector identifiers system parame-ter definitions changed, multi-ple data type support section rearranged, newdata types definitions up-dated, some data support andtime triggered bus distribution listexpanded, several nodeservices added, clarificationsCopyright statementCANaerospace is an interface standard open to everyone. No copy-rights are reserved and no licenses are necessary for its implementati-on, use or distribution. Consequently, the author explicitely refusesany responsibility arising from the use of this standard in any applicati-on. This document in its current version is available to this standard are welcome:Stock Flight SystemsSch tzenweg 8a82335 Berg/FarchachGermanyphone.

2 : +49-8151-9607-0fax: +49-8151-9607-30 Email: cover photograph: NASA test pilot Rogers Smith flying the X-29 research aircraftover Mojave Desert, CaliforniaRevision , (C) 1998-2006 Stock Flight SystemsTable of ContentsSectionPage1 Introduction42 Message data types and identifier types53 Message message event data (EED) operation data (NOD) message service data (NSH/NSL) message format service data (DSD) message data (UDH/UDL) message format94 Node service service (IDS) synchronisation service (HSS) download service (DDS) upload service (DUS) control service (SCS) interval service (TIS) programming service (FPS) transmission service (STS) setting service (FSS) control service (TCS) setting service (BSS) setting service (NIS) information service (MIS) configuration service (MCS)

3 Setting service (CSS) distribution setting service (DIS)225 CANaerospace default identifier state/air controls engine/fuel system data31 Revision , (C) 1998-2006 Stock Flight SystemsTable of transmission system system system system gear system data456 Time-triggered bus transmission slot load computation527 System redundancy message identifier and the CANaerospace header548 Physical connector definition55 Revision , (C) 1998-2006 Stock Flight Systems1 IntroductionCANaerospace is an extremely lightweight protocol/data format defini-tion which was designed for the highly reliable communication ofmicrocomputer-based systems in airborne applications via CAN (Con-troller Area Network). The purpose of this definition is to create a stan-dard for applications requiring an efficient data flow monitoring andeasy time-frame synchronisation within redundant systems.

4 The defi-nition is kept widely open to allow implementation of user-definedmessage types and protocols. CANaerospace can be used with and (11-bit and 29-bit identifiers) and any bus data types and identifier assignmentThe data format definition specifies 6 basic message types, which areused for different network services. Each message type has an asso-ciated CAN-ID range defining the message priority. Generally, theidentifier distribution within the specified ranges is at the user s discre-tion. A standard CANaerospace identifier distribution addressing com-monly used data objects and devices in aerospace applications ismade in section 5, however. The use of this standard distribution sche-me is highly encouraged for interoperability TypeCAN-IDRangeExplanationEmergencyEvent Data(EED)0 - 127($000 - $07F)Transmitted asynchronously whe-never a situation requiring imme-diate action PriorityNode ServiceData (NSH)128 - 199($080 - $0C7)Transmitted asynchronously orcyclic with defined transmissionintervals for operational com-mands (36 channels)High Priority-User-DefinedData (UDH)200 - 299($0C8 -$12B)Message/data format and trans-mission intervals entirely user-de-finedNormal Opera-tion Data(NOD)300 - 1799($12C - $707)Transmitted asynchronously orcyclic with defined transmissionintervals for operational and sta-tus Priority-User-DefinedData (UDL)1800 - 1899($708 - $76B)

5 Message/data format and trans-mission intervals entirely typesRevision , (C) 1998-2006 Stock Flight SystemsFor data representation, the most commonly used basic data typesare defined. Additionally, combined data types ( two, three and four16 bit and 8 bit data types in one CAN message) and aggregate datatypes (64-bit double float) are supported. Other data types can be ad-ded to the type list as required. The type number in the range of 0-255is used for data type specification as described in section Data(DSD)1900 - 1999($76C -$7CF)Transmitted asynchronously orcyclic for debug communication &software download PriorityNode ServiceData (NSL)2000 - 2031$7D0 - $7 EFTransmitted asynchronously orcyclic for test & maintenance ac-tions (16 channels).Data TypeRangeBitsExplanationType # No data type0($00) eventdata type1($01)FLOAT1-bit sign23-bit fraction8-bit exponent32 Single precisionfloating-point va-lue according toIEEE-754-19852($02)LONG-2147483647 to+2147483648322 s complementinteger3($03)ULONG0 to429496729532unsigned integer4($04) bit defines adiscrete state.

6 32bits are coded intofour CAN data by-tes5($05)SHORT-32768 to+32767162 s complementshort integer6($06)USHORT0 to 6553516unsigned short in-teger7($07)Message typesRevision , (C) 1998-2006 Stock Flight bit defines adiscrete state. 16bits are coded intotwo CAN data by-tes8($08)CHAR-128 to +12782 s complementchar integer9($09)UCHAR0 to 2558unsigned char in-teger10($0A) bit defines adiscrete state. 8bits are coded intoa single CAN databyte11($0B)SHORT2-32768 to+327672 x162 x 2 s comple-ment short integer12($0C)USHORT20 to 655352 x162 x unsigned shortinteger13($0D) x162 x discrete short14($0E)CHAR4-128 to +1274 x84 x 2 s comple-ment char integer15($0F)UCHAR40 to 2554 x84 x unsigned charinteger16($10) x84 x discrete char17($11)CHAR2-128 to +1272 x82 x 2 s comple-ment char integer18($12)UCHAR20 to 2552 x82 x unsigned charinteger19($13) x82 x discrete char20($14)MEMID0 to429496729532 Memory ID forupload/download21($15)CHKSUM0 to429496729532 Checksum forupload/download22($16)ACHAR0 to 2558 ASCII character23($17)Data TypeRangeBitsExplanationType #Revision , (C)

7 1998-2006 Stock Flight Systems3 Message structureThe coding of the data into the CAN message bytes is according to the Big Endian definition as used by Motorola 68K, SPARC, PowerPC,MIPS and other major processor architectures. All CAN messagesconsist of 4 header bytes for identification and between 1 and 4 databytes for the actual to 2552 x82 x ASCII character24($18)ACHAR40 to 2554 x84 xASCII character25($19)CHAR3-128 to +1273 x83 x 2 s comple-ment char integer26($1A)UCHAR30 to 2553 x83 x unsigned charinteger27($1B) x83 x discrete char28($1C)ACHAR30 to 2553 x84 xASCII character29($1D)DOUBLEH 1-bit sign52-bit fraction11-bit exponent32 Most significant 32bits of double pre-cision floating-point value accor-ding to IEEE-754-198530($1E)DOUBLEL1-bit sign52-bit fraction11-bit exponent32 Least significant32 bits of doubleprecision floating-point value accor-ding to IEEE-754-198531($1F) for fu-ture use32-99($20-$63) datatypes100-255($64-$FF)

8 Data TypeRangeBitsExplanationType #Revision , (C) 1998-2006 Stock Flight SystemsThe general message format uses a 4 byte message header for nodeidentification, data type, message code and service code (for normaloperation data (NOD) , the service code field is user-defined). This al-lows identification of each message by any receiving unit without theneed for additional information. Every message type uses the samelayout for the CAN data bytes 0-3, while the number and the data typeused for CAN data bytes 4-7 is user-defined:The header data fields have the following meaning: The node-ID is in the range of 0-255 with node-ID 0 beingthe broadcast-ID referring to all nodes . Note that for emer-gency event data (EED) and normal operation data (NOD)messages, the node-ID identifies the transmitting station,while for node service data (NSH/NSL) messages the node-ID identifies the addressed station.

9 The data type specifies the coding of the data transportedwith the corresponding message. The number is taken fromthe data type list (see section ). For normal operation data (NOD) messages, the messagecode is incremented by one for each message and may beused to monitor the sequence of incoming messages. Themessage code then rolls over to zero after passing 255. Thisfeature allows any node in the network to determine the ageof a signal and the proper sequence for monitoring node service data (NSL/NSH) messages, however, themessage code is used for extended specification of the ser-vice. For normal operation data (NOD) messages, the servicecode consists of 8 bits which may be used as required by thespecific data (should be set to zero if unused). For node ser-vice data (NSL/NSH) messages, the service code containsthe node service code for the current messa-ge formatByte 4 Byte 5 Byte 6 Byte 7 Byte 0 Byte 1 Byte 2 Byte 3 Message Data (message type specific)Message Code (UCHAR)Service Code (xCHAR*)Node-ID (UCHAR)Message headerData Type (UCHAR)*: xCHAR may be CHAR, ACHAR, BCHAR or UCHARR evision , (C) 1998-2006 Stock Flight SystemsEmergency Event Data (EED) is transmitted asynchronously by the af-fected unit whenever an error situation occurs.

10 The correspondingdata contains information about the location within the unit at whichthe error ocurred, the offending operation and the error code:Normal Operation Data (NOD) is transmitted during normal operation,either cyclic or asynchronously. The data type (and therefore the mes-sage byte count) is taken from the data type list:Node Service Data (NSH/NSL) is data associated to the node serviceprotocol as specified in section 4. The message format is similar toNOD. Node service data, however, is transmitted on specific identi-fiers only:The Debug Service Data message format is entirely user-defined be-cause of the specific requirements resulting from the various host/tar-get communication protocols. Aside from using the specified identifierrange, no restrictions apply.