This is the third post in the 'Adventures in CANaerospace'. Today I wish to demonstrate the FACT that a CANbus ie CANaerospace does not rely on the Master-Slave relationship, even though it could use it. Ok, that's a mouth full. CAN and CANaerospace's concept is both, anyone-to-many and peer-to-peer communications that means that any node could be a Master or a Slave. Neat huh?
The way to accomplish this is to use the CAN modules INT line which is triggered when there is a match in the selection registers. So if you are node #10 and messages coming down the wire, only messages addressed to node #10 will be caught, the rest are ignored. So when the CAN module sends the interrupt to the CPU, the CPU grabs the data and does something with it.
I like this CAN Bus Module, which has an MCP2515 CAN to SPI interface, as this is the chip that will do the message filtering, and the TJA1050 CAN Transceiver, as this combination is very standard.
The system that I will demo in the next Blog is node #10 and node #0 which is the controller and in a full system node #0 will talk and listen to a server via a protocol converter (CAN - Ethernet) as CAN uses only layer1 (physical layer), and layer2 (data link layer) ISO model itself. CANaerospace uses a Communications Profile DB (CPDB) for the entire network. The CPDB uses readable XML files and describes the network traffic in detail. ie.
In a full system; Each node must support at least the Identification Service (IDS) on Node Service channel 0. This makes sure that a CANaerospace network can be scanned for attached units to determine their status, header type, and identifier assignment1.
The identification service is a client/server type service. It is used to obtain a “sign-of-life” indication from the addressed node and check if its identifier distribution and message header format is compliant with the network that it is attached to. The addressed node returns 4-byte status information which contains information about hardware and software revision of the system, together with the identifier distribution and message header format the node is programmed for2.
A node service is initiated by a node service request message, transmitted on the corresponding identifier. All nodes attached to the network are obliged to continuously monitor these identifiers and check if received messages contain their own personal node-ID. If a match is detected, the corresponding node has to react by performing the required action and transmitting a node service response message on the corresponding identifier within 100ms (if this was required by the request type). The node service response must again contain the personal node-ID of the addressed node. Any node in the network is allowed to initiate node services. It is recommended, however, that each node in the network initiating node service requests use a dedicated node service channel to avoid potential hand-shaking conflicts. The channel on which a particular node service is run may be defined by the user. If only one service channel is used, node services must be run on channel 0 by default. Some frequently used types of node services are already specified below, other services may be added as required 3.
In my system IDS will be run every one (2 or 3) second(s), and it will run on Channel 0, along with regular network traffic as most of my strings (ie connected to a protocol converter). The Radio SubSystem or RSS has less a node for each radio, plus the protocol converter.
IDS Description
| Message Payload Byte |
Data Field Description | Service Request | Service Response |
| 0 | Node-ID | ServerNoeID | ServerNodeID |
| 1 | Data Type | NODATA | UCHAR4 |
| 2 | Service Code | 0 (IDS) | as in request |
| 3 | Message Code | 0 (Standard Identification) | 0 (Standard Identification) |
| 4-7 | Message Data | N.A. | Byte 0: Hardware Revision Byte 1: Software Revision Byte 2: Identifier Distribution (0 = CANaerospace Standard Distribution) Byte 3: Header Type (0 = CANaerospace Standard Distribution) |
Photo and other Credits:
- Michael Stock Flight Systems:
"Interface specification for airborne CAN application V1,7" p11 - " " p13
- " " p11
- Innovative Control Systems, Stock Flight Systems, Wetzel Technology:
"ARINC825 General Standardization of CAN (Controler Aera Network) Bus Protocol for Airborne Use": XML profile, p14
