Difference between revisions of "SpaceCAN"
(→Multiple Frame Transmission) |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [https://de.wikipedia.org/wiki/Controller_Area_Network CAN] | + | The [https://de.wikipedia.org/wiki/Controller_Area_Network CAN bus] is ideally suited as control and monitoring bus (referred to as system bus) for embedded systems. The purpose of the system bus is not to route science data, images, software patches, or other large volume data among attached system (for this a dedicated bus shall be used), but to ensure reliable and robust communication between master and slave nodes of the network. For this, small messages are sent between nodes that must arrive without error and with very little delay. |
| + | |||
| + | CAN has many years of heritage in automotive and industrial applications and is also [https://artes.esa.int/news/after-decade-development-can-bus-space-flight-ready qualified for space use]. The bit rate of the bus is 1 Mbps (although lower rates are possible as well). The specification shown here for the CAN bus operation are for most parts taken from the international space standard [http://ecss.nl/standard/ecss-e-st-50-15c-space-engineering-canbus-extension-protocol-1-may-2015/ ECSS-E-ST-50-15C]. | ||
== Topology == | == Topology == | ||
| Line 36: | Line 38: | ||
| SCET Time || 180 + Node ID || Master | | SCET Time || 180 + Node ID || Master | ||
|- | |- | ||
| − | | UTC Time || 280 + Node ID || Master | + | | UTC Time || 200 + Node ID || Master |
| + | |- | ||
| + | | Telecommand (TC) || 280 + Node ID || Master | ||
| + | |- | ||
| + | | Telemetry (TM) || 300 + Node ID || Slave | ||
|- | |- | ||
| Message || 380 + Node ID || Master, Slave | | Message || 380 + Node ID || Master, Slave | ||
| Line 45: | Line 51: | ||
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 [http://ecss.nl/standard/ecss-e-st-50-15c-space-engineering-canbus-extension-protocol-1-may-2015/ ECSS-E-ST-50-15C standard] (except for message exchange, which is derived from [https://en.wikipedia.org/wiki/ISO_15765-2 ISO 15765-2 protocol]) and were modified slightly to facilitate implementation. | 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 [http://ecss.nl/standard/ecss-e-st-50-15c-space-engineering-canbus-extension-protocol-1-may-2015/ ECSS-E-ST-50-15C standard] (except for message exchange, which is derived from [https://en.wikipedia.org/wiki/ISO_15765-2 ISO 15765-2 protocol]) and were modified slightly to facilitate implementation. | ||
| − | === Redundancy Management === | + | === 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 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 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 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: | The slave nodes monitor the presence of the heartbeat from the master to determine the active bus. It follows this logic: | ||
| Line 60: | Line 66: | ||
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. | 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. | ||
| − | === | + | === Synchronization === |
| − | Synchronous network | + | 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. |
=== Time Distribution === | === Time Distribution === | ||
| Line 80: | Line 86: | ||
[[File:Utc data format.PNG|400px]] | [[File:Utc data format.PNG|400px]] | ||
| − | === Message Exchange === | + | === Telecommands and Telemetry === |
| + | |||
| + | [[File:Can_network.png|600px]] | ||
| + | |||
| + | 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). | ||
| + | |||
| + | === Message Exchange (optional) === | ||
The minimal set protocol of ECSS-E-ST-50-15C (clause 9.4) uses the concepts of [https://www.canopensolutions.com/english/about_canopen/pdo.shtml CANopen PDO] and [https://en.wikipedia.org/wiki/CANopen#Object_dictionary object dictionary] to implement command and telemetry exchange. The use of it is complicate and not at all intuitive. It also limits the exchange of data to maximum of eight bytes. (CANopen SDO can be used to transfer larger amounts of data at the cost of even higher complexity for the developer). | The minimal set protocol of ECSS-E-ST-50-15C (clause 9.4) uses the concepts of [https://www.canopensolutions.com/english/about_canopen/pdo.shtml CANopen PDO] and [https://en.wikipedia.org/wiki/CANopen#Object_dictionary object dictionary] to implement command and telemetry exchange. The use of it is complicate and not at all intuitive. It also limits the exchange of data to maximum of eight bytes. (CANopen SDO can be used to transfer larger amounts of data at the cost of even higher complexity for the developer). | ||
| Line 143: | Line 157: | ||
* CONTINUE (0): authorization to continue to send | * CONTINUE (0): authorization to continue to send | ||
| + | * WAIT (1): wait for next flow control | ||
* ABORT (2): abort the ongoing transmission | * ABORT (2): abort the ongoing transmission | ||
| − | |||
| − | |||
==== Error Handling ==== | ==== Error Handling ==== | ||
Latest revision as of 14:58, 21 September 2019
The CAN bus is ideally suited as control and monitoring bus (referred to as system bus) for embedded systems. The purpose of the system bus is not to route science data, images, software patches, or other large volume data among attached system (for this a dedicated bus shall be used), but to ensure reliable and robust communication between master and slave nodes of the network. For this, small messages are sent between nodes that must arrive without error and with very little delay.
CAN has many years of heritage in automotive and industrial applications and is also qualified for space use. The bit rate of the bus is 1 Mbps (although lower rates are possible as well). The specification shown here for the CAN bus operation are for most parts taken from the international space standard ECSS-E-ST-50-15C.
Contents
Topology
The CAN system bus is designed as a linear bus and is composed of a nominal and redundant chain (bus A and bus B).
The master node can talk to slaves and the slaves can talk to the master. The slaves DO NOT talk with each other. If data needs to be transferred from one slave to the other, this must be coordinated by and go through the master. 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 master and the various slave nodes form a network.
The network is thus composed of a single master (with node ID 0) and up to 127 slaves (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.
Bus Access Architecture
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.
CAN-ID Format
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 |
|---|---|---|
| Heartbeat | 700 | Master |
| Sync | 080 | Master |
| SCET Time | 180 + Node ID | Master |
| UTC Time | 200 + Node ID | Master |
| Telecommand (TC) | 280 + Node ID | Master |
| Telemetry (TM) | 300 + Node ID | Slave |
| Message | 380 + Node ID | Master, Slave |
Services
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 (except for message exchange, which is derived from ISO 15765-2 protocol) and were modified slightly 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.
Synchronization
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.
Time Distribution
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.
SCET Format
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:
UTC Format
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:
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).
Message Exchange (optional)
The minimal set protocol of ECSS-E-ST-50-15C (clause 9.4) uses the concepts of CANopen PDO and object dictionary to implement command and telemetry exchange. The use of it is complicate and not at all intuitive. It also limits the exchange of data to maximum of eight bytes. (CANopen SDO can be used to transfer larger amounts of data at the cost of even higher complexity for the developer).
Therefore, a different protocol is used for message exchange (that is, command and telemetry exchange), which is the ISO 15765-2 protocol, referred to as ISO-TP. The advantage of ISO-TP is that it does not modify the CAN ID field, but instead injects its meta information into the CAN frame data field. This way, the frame routing can still make use of the ECSS-CAN concept (namely using a dedicated PDO slot) and thus stays consistent with the other services.
ISO-TP prepends one or more metadata bytes to the payload data field, reducing the payload to seven or fewer bytes per frame. The metadata is called the protocol control information, or PCI. The PCI is one, two or three bytes. The initial field is four bits indicating the frame type, and implicitly describing the PCI length.
| Frame Type | Byte #1 | Byte #2 | Byte #3 | |
|---|---|---|---|---|
| Bits 7 - 4 | Bits 3 - 0 | |||
| Single Frame (SF) | 0 | message length | ||
| First Frame (FF) | 1 | message length | ||
| Consecutive Frame (CF) | 2 | sequence number | ||
| Flow Control (FC) | 3 | flow status | block size | separation time |
Node Addressing Scheme
The CAN ID is constructed from the function code (0x380) plus a node ID. The node ID is selected as follows:
- Master node uses node ID set to zero (0) for broadcast messages.
- If master node wants to send a message to a specific node, then the node ID shall be set to the ID of that slave.
- Slave nodes shall use for the node ID to their own node ID. This way, the master can identify from which node the messages was sent. Remember that slave nodes can only communicate to the master and not to each other.
This scheme may seem to be conflicting as it maps the node ID to the target node ID for messages from the master and the source node ID for messages from slaves. But it is garantueed to work because each node also configures its CAN controller to filter for the CAN IDs it is listening to.
Single Frame Transmission
For messages of seven or less bytes, the protocol uses a single frame (SF) transmission. The first data field byte encodes the frame type (0) and the length of the message. The message is then inserted into the remaining bytes. On the receiving side the message data is extracted.
Multiple Frame Transmission
Transmission of longer messages (8 - max. 4095 bytes) is performed via segmentation of the message and transmission as multiple frames. On the receiving side, these multiple frames are reassembled (concatenated) into a message.
The transmission starts with a first frame (FF) that carries the first six (6) data bytes, followed by consecutive frames (CF). Each CF carries seven (7) data bytes, except for the last CF, which carries the remaining bytes of the message.
The receiver has the possibility of adapting the transmission throughput by means of the flow control mechanism using the flow control (FC) frame. The parameters to control througput are:
- Block size (BS): the maximum number of CFs the receiver allows the sender to send before the sender has to wait for authorization to continue transmission. (Set to zero to request to send all remaining CFs in one go.)
- Separation time (ST): the minimum time the sender has to wait between transmission of each CF.
In addition to the adaption of transmission throughput, the receiver has the possibility to either authorize the transmission of following CFs, to delay such transmission, or to deny the reception alltogether. For this the receiver sets the flow status (FS) to:
- CONTINUE (0): authorization to continue to send
- WAIT (1): wait for next flow control
- ABORT (2): abort the ongoing transmission
Error Handling
Each time the sender of receiver waits for a frame from the other side, a timeout mechanism allows detection of a transmission failure (and prevents hanging). In such case, the transmission is terminated and any further incoming frames from this transmission will be ignored.
The sequence number (SN) is used to specify the order of consecutive frames (CFs). It starts with zero (0) for the FF and has a value of one (1) for the first CF. The SN shall be incremented by one (1) for each new CF that is transmitted during a segmented message transmission. When the SN reaches the value of fifteen (15), it shall wraparound and be set to zero (0) for the next CF. If a CF is received with an incorrect sequence number, the ongoing transmission shall be aborted.
Message Interpretation
The message service garantees the delivery of large messages. The interpretation of these messages and whether to interpret them as command or telemetry is application specific and not prescribed here.
