Difference between revisions of "SpaceCAN"
|Line 60:||Line 60:|
=== SYNC Protocol ===
=== SYNC Protocol ===
The master SYNC (CAN = 0x080, no data) the their (for example of sending of housekeeping data).
=== Time Distribution ===
=== Time Distribution ===
Revision as of 14:56, 27 November 2018
CAN was chosen as the control and monitoring bus (refered to as system bus). CAN is a reliable and robust bus that 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. The specification for the CAN bus operation are for most parts taken from ECSS-E-ST-50-15C.
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
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.
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.
The available communication objects are:
|Object||CAN ID (hex)||Originator|
|SCET Time||180 + Node ID||Master|
|UTC Time||280 + Node ID||Master|
|Message||380 + Node ID||Master, 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 (except for message exchange, which is derived from ISO 15765-2 protocol) and were modified slightly to facilitate implementation.
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 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 behaviour can be achieved with the SYNC protocol. The master cyclically transmits SYNC frames (CAN ID = 0x080, no data) to indicate to the slaves to start their application-specific behaviour (for example initiation of measurements or sending of housekeeping data), which is coupled to the reception of the SYNC frame.
Nodes use messages for exchange of commands (master to slave) and monitoring data (slave to master). A message can have a size of up to 4095 bytes. Messages of 7 bytes or less are sent in a single CAN frame. Larger messages are segmented into smaller chunks by the sending side and reassembled at the receiving side. For this, the ISO-TP protocol is used.