The CAN bus is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles and is also heavily used in robotics and aerospace.
CAN has many years of heritage and is also qualified for space use. In particular, ECSS has developed the CANbus Extenstion Protocol Standard ECSS-E-ST-50-15C specifically for spacecraft projects that opt to use the CAN Network for on-board communications and control. It also defines the optional use of the CANopen standard as an application layer protocol operating in conjunction with the CAN Network data link layer.
For LibreCube's purpose however, the ECSS CANbus is deemed too complex in terms of implementation and usage. Thus we have further modified the ECSS CANbus Standard to fit the needs of typical spacecraft (and robotics, drone, etc.) projects, while being easy to use and implement. This is what we call the SpaceCAN bus.
We consider that the SpaceCAN bus is used for control and monitoring, allowing the exchange of commands and telemetry among spacecraft subsystems. Typically, a central processing unit is commanding other intelligent nodes (such as the power system, communication system, and payloads) and collects status information from them. The data to be exchanged on this bus is of moderate volume but must be transmitted in a reliable way. The bus us not intended to route high-volume data, such as science data, but to ensure reliable and robust communication between controller and responder nodes of the network. For this, small messages are sent between nodes that must arrive without error and with very little delay.
The system bus is designed as a linear bus and is composed of a nominal and redundant chain (bus A and bus B).
The controller node can talk to responders and the responders can talk to the controller. The responders DO NOT talk with each other. If data needs to be transferred from one responder to the other, this must be coordinated by and go through the controller. The concept behind this architecture is that of a central computer that manages the satellite and which is connected to intelligent subsystems (i.e. that have their own microcontrollers). The interconnection of the controller and the various responder nodes form a network.
The network is thus composed of a single controller (with node ID 0) and up to 127 responders (with node ID 1 to 127). The node IDs are typically hard-coded in software and do not change during operation. Node IDs with lower value have higher priority in communication. That means, critical systems must be given lower IDs.
Nodes can connect to the bus via selective or parallel access.
The selective bus access architecture implements a single CAN controller and interfaces the redundant CAN network via two transceivers. A bus selection mechanism is implemented between the CAN controller and the transceivers allowing the application to select the bus to be used for communication.
The parallel bus access architecture interfaces the redundant CAN network through a pair of CAN controllers.
|Selective Bus Access||Parallel Bus Access|
The CAN data frames carry an 11-bit field for the CAN ID which identify the message and provide a priority scheme (lower CAN IDs have higher priority). ECSS-CAN, which is based on CANopen, splits the CAN ID into a 4-bit function code (to identify the service) and a 7-bit node ID address. The function code together with the node ID then forms a communication object.
|Object||CAN ID (hex)||Originator|
|SCET Time||180 + Node ID||Master|
|UTC Time||200 + Node ID||Master|
|Telecommand (TC)||280 + Node ID||Master|
|Telemetry (TM)||300 + Node ID||Slave|
SpaceCAN provides functionalities that are expected from a reliable and robust monitoring and control bus. These functionalities are defined as services. They are derived from ECSS-E-ST-50-15C standard and were modified to facilitate implementation.
Redundancy Management via Heartbeats
The system bus is made resilient to single point failure (such as problem in cabling or connector fault) through redundant physical media topology. Redundant communication channels require a redundancy management scheme. The selected scheme for cold redundancy (that is, one bus active at a time) applies the concept of node monitoring via heartbeat frames.
The master node defines the bus to be considered active by periodic transmission of heartbeat frames (CAN ID = 0x700, no data) on the active bus. The heartbeat period is typically in the range of severl hundred milliseconds. The master can switch over and operate on the alternate bus by stopping transmission of the heartbeat messages on the active bus and starting them on the alternate bus, which then becomes the active bus.
The slave nodes monitor the presence of the heartbeat from the master to determine the active bus. It follows this logic:
- When a slave node misses the master heartbeat for a defined number of times (Ttoggle), it shall switch to the alternate bus and listen there for heartbeats.
- If it detects a master heartbeat on that bus, it shall consider this one as the active bus.
- If no heartbeat is received after Ttoggle times, it shall switch again to the other bus.
- This bus toggling shall be continued for a predefined number of times (Ntoggle).
This way, the slave nodes will try to find the master heartbeats and when found, stay on the active bus.
The decision on when the master node initiates a bus switch is application specific and not prescribed here. Typically, when slave nodes do not respond to master commands the master node may try a bus switch-over to detect if a bus communication problems exists.
Synchronous network behavior is achieved with the SYNC protocol. The master node periodically transmits SYNC frames (CAN ID = 0x080, no data) to indicate to the slaves to start their application-specific behavior. This could trigger for example the initiation of measurements or the sending of telemetry to the master node. The SYNC period is usually in the range of few seconds.
Typically, the central on-board computer manages the spacecraft time. In addition, other systems on the spacecraft may also maintain a local time (for example an attitude control system with its own processing unit). The time distribution protocol specified here distributes a sample of the central time to devices maintaining a local time. When and how often the central time is distributed to time consumers is application specific.
The master node shall maintain time information using spacecraft elapsed time (SCET) as defined in clause 3.2 of CCSDS 301.0-B-4. The time code format of the SCET is the CCSDS unsegmented time code (CUC): an binary count of seconds and binary power of sub-seconds. The SCET is thus a free running counter of up to 232 seconds (coarse time) and sub-second representations (fine time) down to 2-8, 2-16 or 2-24.
The SCET time frame has CAN ID = 0x180 and the following data payload:
If the spacecraft provides the optional service of maintaing the UTC on board, the format of the UTC shall be that of the CCSDS day segmented time code(CDS): a 16 bit representation of the number of days elapsed from a predefined epoch (e.g. 1 Jan 2000), 32 bits representing the number of ms of the day and an optional 16 bit field of submilliseconds.
The UTC time frame has CAN ID = 0x280 and the following data payload:
|SCET Data Format||UTC Data Format|
Telecommands and Telemetry
The master node can send telecommands to slave nodes. Telecommands usually trigger some kind of action, like switching a unit on or off, changing the mode or configuration of a unit, deploying a solar panel, etc. A telecommand frame contains the node ID of the node to which the telecommand is being sent to and up to 8 bytes of data. (How the data is to be interpreted is application specific).
The slave nodes send telemetry to the master node. The sending of telemetry frames from slave nodes is triggered by the master node either via: a) a specific telecommand that serves as telemetry request, or b) the periodic SYNC frame. Telemetry comprises of essential information about the nodes (also called housekeeping data), such as operational status and sensor readings (temperatures, currents, voltages, etc.). A telemetry frame contains the node ID of the node that is sending the frame and up to 8 bytes of data. (Again, the interpretation of the data is application specific).
- MicroPython: https://gitlab.com/librecube/lib/micropython-spacecan
- mBed C++: https://gitlab.com/librecube/lib/mbed-spacecan
- FreeRTOS (prototype): https://gitlab.com/librecube/prototypes/freertos-spacecan