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 be used. it. Ok, that's a mouth full. CAN and CANaerospace's concept is both, anyone-to-many and peer-to-peer communications that meaning 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 the 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, the Chain is interrogated by the use of the heart-beet or Identification Serice (IDS) on Node Service Channel 0 from the Controller. This lets the network be scanned for attached Line Replaceable Units (LRUs) and to determine their status., header type, and identifier assignment 1.
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 are compliant with the network that it is attached to. The addressed node returns 4-byte status information which contains information about hardware/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.
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) |
In my system IDS will be run every one (2 or 3) seconds, and it will run on Channel 0 exclusively. Most of the other traffic will be on Channel 1
As a side note, there can be multiple Controllers in a system each with many LRUs. These Controllers talk upstream to a 'Master-Controller' of a PC if you wish via Ethernet. The l0cal controllers will be a Raspberry PI with a CAN module attached.
** 1-3 are quoted from the NASA AGATE databus - CAN Aerospace Interface Specification for airborne CAN applications V 1.7