SpaceCAN

From
Revision as of 15:29, 27 November 2018 by Admin (talk | contribs) (Time Distribution)
Jump to: navigation, search

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.

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).

Can bus topology.png

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.

Selective bus access architecture

The parallel bus access architecture interfaces the redundant CAN network through a pair of CAN controllers.

Parallel bus access architecture

CAN-ID Layout

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
Heartbeat 700 Master
Sync 080 Master
SCET Time 180 + Node ID Master
UTC Time 280 + Node ID Master
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

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.

SYNC Protocol

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.

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:

Scet data format.PNG

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:

Utc data format.PNG

Message Exchange

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.