Onboard Data Handling and Telemetry

Onboard Data Handling and Telemetry
LESSON 8: TELECOMMAND & TELEMETRY

Syllabus (I)
0. Introduction to Onboard Data Handling (2 h)
1. OBDH Fundamentals and architectures. Traditional and New Space (4 h)
2. OBDH Design process (2 h)

3. Onboard communication links commonly used in spacecrafts (8 h)
• Onboard communications links introduction
• MIL-STD-1553B
• CAN
• SpaceWire and OTHERs: Ethernet, I2C
4. Telecommand & Telemetry (3-4 h)

Syllabus (II)
4. Data Handling and Processing. Traditional and new space (6 h)

• Processing
• OBC implementation: processors, microcontrollers, FPGA, ASICs, SoC,..
• Failure Detection, Isolation and Recovery (FDIR)
• Onboard Redundancy & Reconfiguration
• Onboard Time Management
• Space signal encryption
• Discrete I/O interfaces
• The Remote Terminal Unit (RTU)

Subject Overview
As defined in CCSDS 130.0-G-3 [RD24]

“A space link is a communications link between a spacecraft and its associated ground system or between two spacecraft.
A space communications protocol is a communications protocol designed to be used over a space link, or in a network that
contains one or multiple space links.”
Extracted from RD24
Space link communications are inherently complex:

The CCSDS (Consultative Committee for Space Data Systems) releases standards for the space link
communications from 1980. ESA (through ECSS) has released compatible standards (based on CCSDS
standards are less extensive than the ones prepared by CCSDS).
[RD24] CCSDS 130.0-G-2 and [RD37] CCSDS 130.2-G-3 provides a great summarizing view of the general
rationale of the space link communications protocols. More detailed space link related standards from RD25 to
RD36.
Space link characteristics
Space link communications are inherently complex:

• Large distances with important distortions involved
• Availability windows pending on mission characteristics implies physical channel is available for a specific
period of time every cycle.
• Doppler effect shall be considered due to spacecraft velocity
• High Bit Error Rates (BER) shall be considered
• Security considerations to be included for safe commanding of the satellite avoiding sabotage.
As usual in space… reliable and error protected protocols are involved in the space link
TC/TM protocols
CCSDS are based on the seven layer of the OSI Basic

Reference Model:
The space communications protocols are defined for
the following five layers of the ISO model:
a) Physical Layer;
b) Data Link Layer;
c) Network Layer;
d) Transport Layer;
e) Application Layer.
(Session and Presentation Layers of the OSI model are
rarely used over space links)
As shown in the following figure, protocols are layered following ISO Basic Reference Extracted from RD37
Model including in the data link layer two sub-layers_ i) channel coding and
ii)synchronization. Also there are other optional sub-layers for authentication and
segmentation.
Space link characteristics
CCSDS has developed several Space Data

Link Protocols (SDLP):
• The TC Space Data Link Protocol
(TCSDLP). For telecommands
• The TM Space Data Link Protocol (TM-
SDLP).For telemetry
• The AOS Space Data Link Protocol (AOS-
SDLP). AOS – Advance Orbiting Systems
(as the ISS)
• The Data Link Layer of the Proximity-1
Space Link Protocol. The Proximity-1
protocol is a bi-directional Space Link
Protocol designed for the purpose of
proximate communications among probes,
landers, rovers, orbiting constellations,
and orbiting relays
• TM and TC Synchronization and Channel
Coding
• Space Packet Protocol
Extracted from RD37 • …
TC/TM protocols
Space communication
protocols cathegorized
by layer: CCSDS
Extracted from RD24

TC/TM protocols
Space communication
protocols cathegorized
by layer: ESA
Extracted from RD24

TC/TM managed by the CDHS
Spacecraft Ground System
OBC
Packet encoding
Telecommand packets are
Packet decoding
OBDH decoding (bit stream segmented, framed and cut into

reassembled to TC packets Command Link Transfer Units
for OBC proccessing by On- (CLTU).
board Software
Ground StationTransmitter
Transponder receiver
TELECOMMAND
Spacecraft Ground System
OBC
Packet decoding
Various telemetry packets
from the S/S subsystemas
Packet decoding
(mainly from OBC and

payload) are multiplexed Decodinig On-ground
following priority, framed and
encoded to Channel Access
Data Units (CADU) and
transmitted to ground
Ground StationTransmitter
Transponder receiver
TELEMETRY
Pending on the S/C OBDH architecture:

- Specific hardware boards entirely implementing TC function and some telemetry functions without
involving any OBC software.
- Data link layer and upper layers implemented by software in the OBC and:
- a hardware Command Decoder decoding tasks.
- hardware telemetry encoder implementing encoding tasks.
- Mainly all TC/TM task implemented in the OBC (CubeSats)
OBC
Serial Serial VC 1 VC n Spacecraft BUS DATA

Data Link- Generate … Generate
Protocol
Hardware Sub-Layer
Software
Command VC Assembler & VC Assembler &

Cmd
Buffer memory
CLCW
Buffer memory S/S subsystems
Hardware Cmd
VC Reception Idle Frame
Command Pulse
CLCW
Decoding Unit
VC Demux VC Multiplexer
(CPDU)
MC Demux
Master Channel
Power
Status
All frames Gen Control &
All Frames Rec
Distribution
Sync Marker
Unit
(PCDU)
Pseudo Dec Channel Reed-Solomon
Coding
BCH Decoder Sub-Layer Pseudo Enc
Transponder
Start Sequence Convolutional
Physical Telemetry CADU

NRZ-L NRZ-L
Layer
Telecommand CLTU Developed from RD43&12
TELECOMMAND
TELECOMMAND LAYER BY LAYER
The commanding of satellites today is performed by applying a standardized communication protocol named after
the “Consultative Committee for Space Data Systems”, (CCSDS).
TC Space Data Link Protocol defines a packet layout and how telecommand packets are segmented, framed and
cut into “Command Link Transfer Units”, (CLTU), for radio frequency, (RF), uplink. In orbit the spacecraft
transponder receives this bit stream which must be reassembled to TC packet level, before the OBSW can use
them.
Extracted from RD43

Two sublayers of the Data Link Layer are defined for CCSDS
space link protocols.
• Data link Protocol Sublayer
• Sync. and channel coding sublayer
The TC Space Data Link Protocol corresponds to the Logical

Link Sublayer and provides functions of transferring various data
using a variable-length protocol data unit called the Transfer
Frame. The optional Space Data Link Layer Security Protocol is
provided within the Data Link Protocol Sublayer.
The Channel Coding Sublayer provides some additional

functions necessary for transferring Transfer Frames over a
space link. These functions are error-correction
coding/decoding, the delimiting/synchronizing of codeblocks
(consisting of one or more Transfer Frames), and bit transition
generation/removal (optional). For the Channel Coding Sublayer, Extracted from RD44
the Channel Coding and Synchronization Recommended
Standard must be used with the TC Space Data Link Protocol.
TELECOMMAND LAYER BY LAYER. GENERAL
Because the space link is prone to error (as previously commented) it is desirable to break large service data units into
relatively small pieces so that each piece has a lower probability of being invalidated by transmission error than if the entire
service data unit were sent contiguously. System throughput efficiency is improved because only small pieces have to be
retransmitted when errors are detected.
For efficient transfer of service data units, it is desirable to group these small units into larger pieces. The TC Space Data Link
Protocol provides the capability to break large service data units into relatively small pieces (segmentation) and to group
small service data units into larger pieces (blocking).
The protocol data units employed by CCSDS TC protocol are the TC Transfer Frame and the Communications Link Control
Word (CLCW):
• Each Transfer Frame contains a header, which provides protocol control information, and a variable-length data field,
within which higher-layer service data units are carried. Transfer Frames are sent in the direction of the flow of service
data units.
• Each CLCW contains a report that describes the status of acceptance of Transfer Frames. CLCWs are sent from the receiver
to the sender of Transfer Frames (as part of the TM).
TC Transfer Frame
Sender User Receiver User
Extracted from CCSDS
Communications Link Control Word (CLCW)
TELECOMMAND LAYER BY LAYER. GENERAL
Extracted from RD43

Telecommand interface timing
The TC Space Data Link Protocol controls the transmission of service data units through the space link performing
retransmissions needed to ensure delivery of service data units in sequence and without gaps or duplication. This
function is provided by an automatic retransmission control mechanism called the Communications Operation
Procedure (COP).
A COP can be used to ensure that commands are always received and accepted on-board a spacecraft in the
same order as they are generated. This is done by using sequence counters in the telecommand transfer frame
header, by only accepting transfer frames that arrive in sequence, and by down-linking in telemetry the next
expected value of the sequence counter to detect whether a frame has been lost.
In addition, a systematic retransmission mechanism for use on deep space links can optionally be provided by the
Synchronization and Channel Coding Sublayer. In this case the protocol does not guarantee the command order
is often used because the communication delays do not allow receiving telemetry information about lost frames
in due time.
Extracted from RD112 & RD44

Telecommand interface timing
The interface timing within the spacecraft, between the Transponder and the OBC, is sometimes given in the
ICD (interface Control Document). SAVOIR defines the following:
Extracted from 21
• For telemetry there are only two signals: Clock and Data.
• The data is sampled on the falling edge.
Telecommand redundancy and physical layer
The TC Physical layer modulates the CLTUs (Command Link Transmission Unit) onto the RF
carrier, and provides the procedures necessary to activate and deactivate the channel.
Sharing the Physical Channel
The mechanism used by the Space Data Link Protocols for transferring data with different QoS
(Quality of Service, mostly priority and latency in this case) requirements is the use of Virtual
Channels (i.e. a way to define what messages have higher priority/latency than others using
same physical channel).
The Virtual Channel facility allows one Physical Channel to be divided into multiple separate
logical data channels, each known as a Virtual Channel (VC) and identified by a Virtual
Channel Identifier (VCID)
Sharing the Physical Channel

An example is provided in RD-37 where the Physical Channel has two Virtual Channels: VC 0 for high-priority traffic and VC 1
for low-priority traffic:
A long, low-priority Packet (for memory upload or download, for example) is being transmitted on VC 1. Since this Packet is
long it is carried by two consecutive Transfer Frames of VC 1. Then, when the first Transfer Frame carrying this low-priority
Packet is being transmitted, a short, high-priority Packet (carrying an on-off command or an event report, for example) is
generated. Since this high-priority Packet needs to be transmitted as soon as possible, a Transfer Frame of VC 0 is generated to
carry this high-priority Packet and inserted between the first and second Transfer Frames of VC 1 that carry the low-priority
Packet. To use this kind of algorithm, a buffer memory with a sufficient capacity to store Service Data Units and/or Transfer
Frames temporarily must be implemented in the service provider (satellite in our case).
Extracted from 37
When the telecommand function is made redundant, it is almost always operated in hot redundancy. The virtual
channel ID is typically used by the ground operator to properly address the two telecommand functions. For
implementations without the segmentation sub-layer, different sets of virtual channel IDs can be assigned to the two
telecommand functions.
Three different connections with the Transponders as described in SAVOIR documents:
The typical configuration, which

is selected by the majority of
missions, is Configuration 1. In
this configuration the cross-
strapping between the
Transponders and the TC
Decoders is made in the
spacecraft harness.
Developed from RD21&12

Maximum configuration:
Dual band, four transponders
The implementation of second is typically done with the two methods described in the
figures:
Receiver
A TC
• The first method: connect the nominal and redundant line receivers in parallel.
Decoder
A
Caution with reflections!. Signal termination scheme shall be considered for
avoiding undesirable reflections.
Receiver
C
OBC • The second method uses a single line receiver that is powered from a power line
Receiver that is the OR of the power to the TC Decoders. This method avoids the signal
D
TC
Decoder
reflection problems at the expense of a bit more complex implementation. Some
Receiver
B
B caution is needed also here to avoid that a failure in a line receiver is spread to
both TC Decoders.
Configuration 2
Developed from RD21

Finally, in case a Transponder only has one output it is still possible to

cross-strap the Transponders with the TC Decoders using the optional
OBC internal cross-strap functionality.

Telecommand addressing and multiplexing

The Space Data Link Protocols use some addresses or identifiers to
identify data streams. All the Space Data Link Protocols use the
following identifiers:
• Transfer Frame Version Number (TFVN)
• Spacecraft Identifier (SCID) . Assigned according to CCSDS
procedure CCSDS 320.0-B-6
• Virtual Channel Identifier (VCID). As defined by each project.
• Master Channel Identifier (MCID)
• Physical Channel Name
In addition to these identifiers, the TC-SDLP optionally uses an

identifier called the Multiplexer Access Point Identifier (MAP ID).
The MAP ID determines the physical output port of the TC Decoder.
In a basic system there are only a few destinations for direct ground
commanding. The mandatory destinations in SAVOIR are the
Essential TC function (CPDU) and the Processing function. This
implies to have three separate output ports, one to the
corresponding CPDU and one to each Processor Module.
Channel coding and

synchronization sub-layer
The TC Coding layer satisfies the TC System requirement for the error-free delivery of commands to the
spacecraft, by encoding the TC user data from the layer above to protect them against noise-induced errors
during transmission through the underlying ground-to-spacecraft radio frequency (RF) channel.
The basic protocol data unit of the Coding layer is the TC Codeblock, which appends a small block of information
bits with parity bits that provide error detection and (optionally) correction capability. Strings of TC Codeblocks,
conveying the information bits representing one or more TC Transfer Frames in the form of parity-protected
channel symbols, are encapsulated within a Command Link Transmission Unit (CLTU) before being passed to the
layer below. Any errors that occur in the encoded information bits as a result of the physical transmission process
may be detected or corrected at the spacecraft receiving end of the Coding layer.
Developed from RD25

Channel coding and As the data is subject to pseudo-randomization process before

synchronization sub-layer being uplinked in order to ensure a sufficient bit transition
density on the uplink, the decoded data from the code blocks
are then subject to a de-randomization process before being
sent to the next layer in the decoding process.
The next part of the CLTU consists of data

Pseudo Dec
coded with a (63,56) Bose-Chaudhuri-
Hocquenghem (BCH) code capable of
BCH Decoder
correcting any single bit in the code word. A
selection process selects which signal to use A CLTU begins with the start sequence, which is a pattern
Start Sequence
for further processing based on the quality of having good autocorrelation properties
the start sequence and the quality of the NRZ-L
code blocks.
The channel coding and synchronization sub-layer receives

command link transmission units (CLTU) from one or more RF
receivers depending on the specific configuration selected for
the spacecraft.
Data link protocol sub-layer
The data link protocol sub-layer receives telecommand transfer frames from the channel coding and
synchronization sub-layer. These frames contain a 5-byte header, which among various control information
includes the address of the spacecraft and a virtual channel identifer (ID), a data field and a 2-byte cyclic
redundancy check (CRC) field for further protection of the data.
As the BCH decoding process may incorrectly correct code words that have more than two bit errors, there is a
small chance that errors remain when the frame is processed.
The frames are therefore checked for errors using the CRC. The spacecraft address is then checked and the data
field routed either to an end user or to the next layer. If routed directly to an end user, the virtual channel ID
can be used to determine the destination.
Developed from RD12


FRAMES
A TC Transfer Frame shall encompass the major fields, positioned contiguously, in the following sequence: a) Transfer Frame
Header (5 octets, mandatory); b) Transfer Frame Data Field (up to 1019 or 1017 octets, mandatory); c) Frame Error Control
Field (2 octets, optional).
Developed from RD28

FRAMES
The Transfer Frame Primary Header is mandatory and shall consist of eight fields, positioned contiguously, in the following
sequence: a) Transfer Frame Version Number (2 bits, mandatory); b) Bypass Flag (1 bit, mandatory); c) Control Command Flag
(1 bit, mandatory); d) Reserved Spare (2 bits, mandatory); e) Spacecraft Identifier (10 bits, mandatory); f) Virtual Channel
Identifier (6 bits, mandatory); g) Frame Length (10 bits, mandatory); h) Frame Sequence Number (8 bits, mandatory).
Extracted from RD28

Optional segmentation sub-layer
The optional segmentation sub-layer receives the data field from the data link protocol sub-layer. If
implemented this sub-layer is always enabled.
The data field is now called a telecommand segment and starts with a single-byte header that provides
information on whether the segment is a standalone entity or a beginning, middle, or end segment of a
larger data structure. The segment header also includes a multiplexer access point (MAP) ID, which is used
to determine the destination of the telecommand segment.
Developed from RD12

Optional authentication sub-layer
The optional authentication sub-layer receives the tele-command segments from the segmentation sub-layer and
the data fields from the data link protocol sub-layer.
It can often be enabled and disabled by telecommand. The first step in this sub-layer is to determine whether the
commanding source is the correct one. This is done by comparing parts of an appended authentication tail by a
calculated authentication code.
This code is calculated from an on-board secret key also known by the ground station, from the telecommand
segment data and a logical authentication channel (LAC) counter provided in the authentication tail. If the
uplinked and calculated authentication codes are identical and if the uplinked LAC counter value is within an
expected window, the telecommand segment (or the data field) is considered authentic and can be forwarded to
the end user by the same mechanisms as described above. To prevent unauthorized access by someone
recording and resending the same CLTU, the LAC counters are never reused with the same key.
Keys are also replaced at regular intervals in case the key in use has been compromised.
Developed from RD12

Essential Telecommand Function
The end user of a telecommand is in most cases the processing function. However, in some missions it is required
to be able to perform essential telecommanding even if the processing function is not operating properly. In ESA
missions, this function is called the Command Pulse Distribution unit (CPDU). The essential TC function consists of
one or more Command Pulse Distribution Units (CPDUs) that accept TC Segments and generate command pulses
of specific durations in order to execute basic and “high priority” commands (HPC) for critical spacecraft parts
and functions reconfiguration (such as resetting the processing function). A CPDU receives a telecommand
segment and extracts the embedded CCSDS space packet that contains a list of one or more pulse commands to
be generated.
The typical usage was to perform critical spacecraft reconfiguration and to handle on/off switching of critical
spacecraft platform units.
With the introduction of more autonomous spacecraft and the requirements for lower mass and power, this asset
has gradually been accessible also from the Reconfiguration Module and the Central Software via the Processing
Module. Having one resource shared by multiple requesters introduces the need for two sub-functions:
• Prioritizing the requesters
• Providing access protection for selected commands

One CPDU can drive several tens (usually in the order of one hundred) hard-wired output lines. Command pulses are
encoded within the CPDU specific TC Segment application data field in the form of several two-octets command
instructions. A single instruction specifies the Command Pulse output to be activated and the duration of the pulse.
Actually, segmentation of TC packets addressed to CPDU is not allowed. TC Segments sent to CPDU shall contain only one
entire packet.
Telecommand segments are checked for validity and cleanness
inside the Command Pulse Distribution Module. If this check
fails, the instruction is not carried out and an error is
generated.
After decoding and verifying the TC segment, the command is
further conditioned by the CPDU drivers before leaving the
CPDU and being forwarded to the subsequent units, via hard-
wired output lines.
Typically the TC decoder is equipped with a buffer. It is used to
temporary store one TC frame, which currently cannot be
executed by the CPDU. This is the case while the unit is still
executing a previous command.
Developed from RD23,RD21&12

CPDU prioritizes the requesters as following described (following SAVOIR recommendations):

1.The On-Board FDIR function via the Reconfiguration Module
2.The Ground Operator via the TC Decoder
3.The Central Software via the Processor Module
The Ground Operator has not the highest priority (for modern autonomous spacecraft the spacecraft itself has
recovery tools as the FDIR/Reconfiguration Module that allows to recover from failures faster and even better
than by ground telecommanding). Thus a request from the Reconfiguration Module must never be discarded or
aborted, but it must abort on-going requests from ground and or the Processor Module in order to ensure that a
new spacecraft configuration is established within the requested time for a mission.
Nevertheless, exceptions can be made: for spacecraft contingency operation the ground operator might want to
have full access to the CPDU and not be disturbed by autonomous on-board FDIR mechanisms. The proper way
to do this is to disable the related software FDIR mechanisms via normal PUS commands and to disable the RM
via the CPDU

The CPDU is often used to command functionality that should not be accessible from software, like enabling and
disabling of the RMs and generation of arming commands. Thus the CPDU must provide some mechanism to
prevent incorrect command execution due to software errors.
The protection does not need to be complex. One method used in todays OBCs is to set a barrier such that
commands with numbers below the barrier cannot be executed by a software request. Another more
sophisticated method is to apply a separate mask for each pulse output.
There should be no need to include protection against erroneous RM requests in the CPDU. The RM is
considered to be a reliable piece of hardware with a low probability of failing such that it requests incorrect
CPDU pulse outputs to be activated.

TELEMETRY
TELEMETRY General
The Platform Telemetry function is responsible for handling the spacecraft platform telemetry link. This link has
classically been associated with an S-band RF link for LEO and GEO missions and an X-band RF link for missions at
larger distances.
The platform telemetry function receives TM from a TM producer in the spacecraft. Producers (process
generating data to be transmitted to ground) can be one of the following:
• The processing function
• The Platform Data Storage function
• The Essential Telemetry function
• The Payload Data Storage
• CLCW (Communications Link Control Word) from the TC Decoding function
The telemetry function is like the telecommand function quite well defined by CCSDS international standards. For
ESA missions [ECSS-E-ST-50-03C] applies.
OBC
Serial Serial VC 1 VC n Spacecraft BUS DATA

Data Link- Generate … Generate
Protocol
Hardware Sub-Layer
Software
Command VC Assembler & VC Assembler &

Cmd
Buffer memory
CLCW
Buffer memory S/S subsystems
Hardware Cmd
VC Reception Idle Frame
Command Pulse
CLCW
Decoding Unit
VC Demux VC Multiplexer
(CPDU)
MC Demux
Master Channel
Power
Status
All frames Gen Control &
All Frames Rec
Distribution
Sync Marker
Unit
(PCDU)
Pseudo Dec Channel Reed-Solomon
Coding
BCH Decoder Sub-Layer Pseudo Enc
Transponder
Start Sequence Convolutional
Physical Telemetry CADU

NRZ-L NRZ-L
Layer
Telecommand CLTU Developed from RD43&12
TELEMETRY LAYER BY LAYER
Data Link-Protocol Sub-Layer

Each source of data is allocated one or more Virtual Channels on the
downlink and for each Virtual Channel there is an assembly mechanism
VC 1
Generate … VC n
Generate
that sequentially packs the received data into fixed length TM Transfer
Frames (later we will see Virtual Channel multiplexing).
VC Assembler & VC Assembler &
Buffer memory Buffer memory
Idle Frame
The structure of the frame is similar to that of the telecommand transfer
frame. It starts with a 6-byte header followed by the user data stream.
The telemetry transfer frame may end with a field called a command link
VC Multiplexer
control word (CLCW), which is used as reporting mechanism in a
CLCW ET
telecommand COP, followed by an optional 2-byte CRC for error
Master Channel
All frames Gen Status detection purposes.
CLCW OBC
elemetry packets before downlink have to be preprocessed into

Sync Marker
“Channel Access Data Units”, (CADU)
Developed from RD23,RD21,RD43&12

Data Link-Protocol Sub-Layer The assembly mechanisms sequentially number the generated frames
using one numbering sequence for each virtual channel and temporarily
stores them in a small buffer memory. The next step in the process is to
VC 1 VC n
Generate … Generate select which frames to transmit. The most common principle used is a
bandwidth allocation method that guarantees to each virtual channel a
VC Assembler & VC Assembler & minimum available bandwidth. This bandwidth is automatically
Buffer memory Buffer memory
increased when other virtual channels do not fully use their minimum
Idle Frame allocated bandwidth. Other principles may use priority for specific virtual
channels. If there is no virtual channel ready to send data, the virtual
VC Multiplexer channel multiplexer will start generating an idle transfer frame because
the telemetry downlink relies on a continuous flow of equally sized
CLCW ET
Master Channel telemetry transfer frames in order to keep the ground station reception
CLCW OBC
All frames Gen Status
process locked to the data stream.
Sync Marker The virtual channel multiplexer adds some information to the telemetry
transfer frame header. The most important parts are the spacecraft ID
and an overall frame count that is common for all frames irrespective of
their virtual channel.
Developed from RD23,RD21,RD43&12
Extracted from RD43


FRAMES
The TM Transfer Frame shall be of constant length throughout a specific Mission Phase for any Virtual Channel or
Master Channel on a Physical Channel
Extracted from RD34


TRANSFER FRAME PRIMARY HEADER
The TM Transfer Frame shall be of constant length throughout a specific Mission Phase for any Virtual Channel or
Master Channel on a Physical Channel.
The Transfer Frame Primary Header is mandatory and shall consist of six fields, positioned contiguously, in the
following sequence: a) Master Channel Identifier (12 bits, mandatory); b) Virtual Channel Identifier (3 bits,
mandatory); c) Operational Control Field Flag (1 bit, mandatory); d) Master Channel Frame Count (1 octet,
mandatory); e) Virtual Channel Frame Count (1 octet, mandatory); f) Transfer Frame Data Field Status (2 octets,
mandatory).
Extracted from RD34

The Channel Coding and Synchronization sub-layer receives the TM Transfer Frames
from the Data Link sub-layer. To protect the data when being transferred on a noisy
downlink the frames can be protected by an optional error-correcting code. Two coding
mechanisms are defined in the standards.
Channel Coding Sub-Layer • The first code is using a non-binary block code, a Reed-Solomon RS(255, 223) code,
allowing the correction of up to a maximum of 16 wrong bytes for each 255-byte
block in the frame.
Reed-Solomon
• The second code is a forward error correction code called Turbo code giving even
Pseudo Enc
better performance than the RS code but at the expense of a more complicated
implementation.
Convolutional
After the coding process the frames can be subject to an optional pseudo-
randomization process in order to generate a sufficient bit transition density on the
downlink. The next step is then to add a 32-bit Attached Sync Marker (ASM) before the
frame. Finally, if no coding or RS coding has been selected a final optional coding step
called Convolutional Encoding can take place.

As commented in some slides before, the data structure now generated, starting
with the ASM, is called a Channel Access Data Unit (CADU).
Channel Coding Sub-Layer

In case more transmitters are used on-board the number of outputs per multiplexer
are just doubled. The number of outputs per multiplexer may be increased if there
are more transmitters used on-board. Note that the multiplexer ensures that a
Reed-Solomon failure in a TM Encoder does not affect the capability of the redundant TM Encoder
to send data via both multiplexers. The Telemetry function provides an additional
Pseudo Enc output to be connected to the umbilical connector or to a test connector during the
AIT phase.
Convolutional
The bit transmission rate is determined by the available link bandwidth. The
maximum possible transmission rate varies, but today the maximum baud rate of
transmitters/receivers does not exceed 10 Mbps (it could change in the future), and
depends on factors like the distance between the spacecraft and the ground
antenna and the elevation of the ground antenna.

PLATFORM TM & PAYLOAD TM (SAVOIR perspective)
In SAVOIR there are two telemetry functions, Platform Telemetry and Payload Telemetry. The Payload Telemetry
function is basically identical to the Platform Telemetry function, the main difference being that the CLCW is not
transmitted via the payload telemetry.
Platform Telemetry and Payload Telemetry may be implemented by two separate hardware blocks or by a single
hardware block.Three different concepts are outlined in the handbook:
A) The OBC houses the Platform Telemetry and some payload unit houses the Payload Telemetry. In this case
the spacecraft has two separate RF links and the payload link often runs at speeds up to several hundred
Mbps, while the platform link runs at one or a few tens of kbps. Typical missions applying this concept are
LEO Earth Observation missions, like the LEO satellites in the Copernicus programme.
B) The OBC houses both the platform telemetry and the payload telemetry and the spacecraft has two
separate RF links fed from two separate TM encoders. This is for example the case of deep space or scientific
missions where mass reduction has an important role. The concept will be used in the JUICE mission but has
also been applied in the Aeolus LEO mission. Also here the Platform Telemetry transmits data up to a few
tens of kbps while the Payload Telemetry is typically limited to less than 100 Mbps.
Developed from RD21

PLATFORM TM & PAYLOAD TM (SAVOIR perspective)
C) The OBC houses both the platform telemetry and the payload telemetry and the spacecraft has a single RF
link. In this case the single platform TM encoder is equipped with additional inputs to receive data from the
Payload Data Storage or directly from payload instruments. This concept was for instance used in the
Herschel and Planck missions and is also used in the GAIA and ExoMars Trace Gas Orbiter missions, all with
a single X-band downlink. The data rates on the common downlink are now drastically increased, with up to
10 Mbps for the GAIA mission as current state of art.
D) There is actually a fourth concept, mainly used in telecom missions, where there are dual RF links but a
single TM Encoder. In this concept the same data stream is sent in parallel to both Transponders. Typically
the S-band Transponders are used during transfer to the correct GEO position, and then the traffic is
switched to Ku-band or whatever band used for the payload
Developed from RD21

TM redundancy and physical layer
The telemetry function is operated in cold redundancy. The redundancy management is in most cases done by
the ground operator, based on the quality of the received TM data.
In case on-board users find that they cannot send their data to the TM function they may request an automatic
on-board redundancy switchover. This switchover is then typically managed by an Application Software FDIR task.
Developed from RD23

TM Cross-strapping with the transponders
The SAVOIR baseline for connecting the TM Encoders with the Transponders is presented in the following figure:
Advantages:
• It is used in the majority of today´s missions.
• The harness is very simple Developed from RD21
• There is no need for a separate input selection mechanism in the Transponder.
Note that the multiplexer function now logically becomes a part of the Transponder Fault Containment
Group, i.e. a fault in one multiplexer has the same effect as a fault in the Transponder.
TM Cross-strapping with the transponders
There are some missions that have used a TM cross-strapping configuration for TM that is the same as the one
used for TC, i.e. having the cross-strapping in the harness. This is shown below for the two Transponder
configurations. This cross-strapping configuration simplifies the OBC at the expense of a more complex harness
and the need for a multiplexing or signal selection function inside the transponders, and it is not included as an
option in the SAVOIR architecture.
Developed from RD21

Essential TM
The Essential Telemetry manages the acquisition of telemetry needed to operate the spacecraft in case the On-
Board software is not operational. The objective is to collect TM data and generate TM packets without
involving the main application software. The acquired TM data are formatted into packets and sent to the
Platform Telemetry where it is downlinked using a dedicated virtual channel.
Developed from RD23

Essential TM
The data to be included in Essential TM packets are selected in the design phase to allow ground control to assess the status
of essential spacecraft items. The amount of data available is often constrained by the OBC design. Looking back into past
projects the following data has in most cases been part of the essential TM.
• On-Board Time at packet generation

• TC Decoder Frame Analysis Report
• Authentication Unit Status Report (only if the Security Function is used)
• CPDU Status Report
• Last PM boot report (from both PMs)
• OBC hardware configuration
• Current alarm status (includes OBC status)
• ID of last performed reconfiguration
• OBT value at last reconfiguration
• OBC hardware configuration at last reconfiguration
• Alarm status of last reconfiguration
Developed from RD21

Essential TM
Essential TM function is operated in cold redundancy.

This is to indicate that the assumed way of operation is that the currently active Essential
Telemetry function acquires data from both nominal and redundant functions inside the OBC
and sends the Packets to the currently active Platform Telemetry function.
However, there can be different implementations that fulfil this functionality:
Developed from RD21

Essential TM
Essential Telemetry function is implemented by

two blocks that operate in a Master/Slave mode.
The nominal block operated in Master mode and
has direct connection with the currently active TM
Encoder, acquires data from the nominal OBC
functions and formats the essential TM packets.
The redundant block operates in Slave mode only
collects data from the redundant OBC functions
and then forwards data to the nominal Essential
TM Collector. The formatter in the redundant block
may be used or not pending in different
configurations.
Developed from RD21

Essential TM
Another possible implementation is shown above, where the Essential Telemetry function actually operates
in hot redundancy, with each block sending complete Space Packets to a single Virtual Channel in the TM
Encoder.
This concept has a slightly higher overhead on the downlink since there are two packet headers and two
OBT values generated, but otherwise it fulfils the functional need in being able to collect status from both
nominal and redundant OBC functions. Note that in this case it is necessary to have different APID values for
the two packets as they contain different data.
Developed from RD21

TM/TC REAL EXAMPLE
REAL EXAMPLE
Biography
• [RD1] G. Maral, M. Bousquet and Z. Sun Satellite Communications Systems: Systems, Techniques and Technology,
Wiley, 2009
• [RD2] M. Macdonald and V. Badescu The International Handbook of Space Technology, Springer, 2014
• [RD3] P. Fortescue, G. Swinerd and J. Stark (Editors) Spacecraft Systems Engineering, 4th Edition, John Wiley, 2012
• [RD4] J.Bouwmeester Lecture Notes - Spacecraft Technology (AE3534), TuDelf, 2018.
• [RD5] E. Keesee Satellite Telemetry, Tracking and Control Subsystems, Massachusetts Institute of Technology, 2003
• [RD6] Architectures of Onboard Data Systems:
https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Onboard_Computer_and_Data_Handling/Architect
ures_of_Onboard_Data_Systems
• [RD7] ECSS, ECSS-S-ST-00-01C – Glossary of terms (1 October 2012)
• [RD8] P. Armbruster Space Avionics Open Interface Avionics Architecture SAVOIR Overview, ESA, 2011
• [RD9] LARSON, Wiley J.; WERTZ, James Richard. Space mission analysis and design. Torrance, CA (United States);
Microcosm, Inc., 1999.
• [RD10] What is On-board Data Processing?:
http://www.esa.int/Enabling_Support/Space_Engineering_Technology/Onboard_Data_Processing/What_is_On-
board_Data_Processing
Biography
• [RD11] M. RIMPAULT, Multi-mission On-board High Performance Payload Data Processing Platform, ESTEC – Workshop
OBDP2019 Noordwijk, 25th of February 2019
• [RD12] HULT, Torbjörn; PARKES, Steve. On-Board Data Systems. The International Handbook of Space Technology. Springer,
Berlin, Heidelberg, 2014. p. 441-470.
• [RD13] “New Space and Old Space”. https://wanderingalpha.com/new-space-vs-old-space
• [RD14] A. de Concini, J. Toth The future of the European space sector How to leverage Europe’s technological leadership and
boost investments for space ventures. European Commission, 2019
• [RD15] SAVOIR. SAVOIR Generic OBC Functional Specification. European Space Research and Technology Centre, 2019.
• [RD16] SAVOIR. SAVOIR Flight Computer Initialisation Sequence Generic Specification. European Space Research and
Technology Centre, 2016
• [RD17] SAVOIR. SAVOIR RTU Functional and Operability Requirements. European Space Research and Technology Centre,
2018
• [RD18] SAVOIR. SAVOIR Data Storage System Requirement Document. European Space Research and Technology Centre,
2017
• [RD19] Generic OIRD Working Group. Generic Operations Interface Requirements Document (GOIRD). European Space
Operations Centre, 2019
• [RD20] SAVOIR. SAVOIR On-board Communication System Requirement Document. European Space Research and
Technology Centre, 2019
Biography
• [RD21] SAVOIR. SAVOIR Data Handling Handbook. European Space Research and Technology Centre, 2019
• [RD22] SAVOIR. SAVOIR FDIR Handbook. European Space Research and Technology Centre, 2019
• [RD23] SAVOIR. SAVOIR Functional Reference Architecture. European Space Research and Technology Centre, 2019
• [RD24] CCSDS 130.0-G-2: Overview of Space Communications Protocols. Green Book. Issue 2. December 2007. Available at
www.ccsds.org.
• [RD25] CCSDS 200.0-G-6: Telecommand Summary of Concept and Rationale. Green Book. Issue 6. January 1987.
• [RD26] CCSDS 727.0-B-4: CCSDS File Delivery Protocol (CFDP). Blue Book. Issue 4. January 2007
• [RD27] CCSDS 231.0-B-2: Telecommand Synchronization and Channel Coding. Blue Book. Issue 2. September 2010
• [RD28] CCSDS 232.0-B-2: Telecommand Space Data Link Protocol. Blue Book. Issue 2. September 2010
• [RD29] CCSDS 232.1-B-2: Communications Operation Procedure-1. Blue Book. Issue 2. September 2010
• [RD30] CCSDS 133.1-B-2: Encapsulation Service. Blue Book. Issue 2. October 2009
• [RD31] CCSDS 133.0-B-1: Space Packet Protocol. Blue Book. Issue 1. September 2003
• [RD32] CCSDS 301.0-B-4: Time Code Formats. Blue Book. Issue 4. November 2010
• [RD33] CCSDS 727.0-B-4: CCSDS File Delivery Protocol (CFDP). Blue Book. Issue 4. January 2007
• [RD34] CCSDS 132.0-B-1: Telemetry Space Data Link Protocol. Blue Book. Issue 1. September 2003
• [RD35] CCSDS 100.0-G-1: Telemetry Summary of Concept and Rationale. Green Book. Issue 1. December 1987
Biography
• [RD36] CCSDS 131.0-B-1: Telemetry Synchronization and Channel Coding. Blue Book. Issue 1. September 2003
• [RD37] CCSDS 130.2-G-3. Space Data Link Protocols—Summary of Concept and Rationale. 2012.
• [RD38] Jalilian, S., SalarKaleji, F., & Kazimov, T. Fault Detection, Isolation and Recovery (FDIR) in Satellite Onboard
Software,2017,
• [RD39] J. Day, M.Ingham. Fault Management at JPL: Past, Jet Propulsion Laboratory, California Institute of Technology,
ADCSS 2011
• [RD40] SalarKaleji, Fatemeh, and Aboulfazl Dayyani. "A survey on Fault Detection, Isolation and Recovery (FDIR) module in
satellite onboard software." 2013 6th International Conference on Recent Advances in Space Technologies (RAST). IEEE,
2013.
• [RD41] WANDER, Alexandra; FÖRSTNER, Roger. Innovative fault detection, isolation and recovery strategies on-board
spacecraft: state of the art and research challenges. Deutsche Gesellschaft für Luft-und Raumfahrt-Lilienthal-Oberth eV, 2013.
• [RD42] Guide, Partial Reconfiguration User. "UG702 (v14. 1)." Xilinx Inc., Apr 24 (2012).
• [RD43] Eickhoff, Jens. Onboard computers, onboard software and satellite operations: an introduction. Springer Science &
Business Media, 2011.
• [RD44] CCSDS 232.0-B-3 2015. TC SPACE DATA LINK PROTOCOL.
• [RD45] ECSS. ECSS-M-30-01A. Organization and conduct of reviews. 1999
Biography
• [RD46] ECSS. ECSS-Q-ST-30C-Rev.1. Dependability.2017

• [RD47] ECSS. ECSS-Q-ST-30-11C Rev.1 – Derating – EEE components, 2011
• [RD48] ECSS. ECSS-Q-ST-30-02C – Failure modes, effects (and criticality) analysis (FMEA/FMECA), 2009
• [RD49] Web resource: https://www.isispace.nl/products/command-data-handling-systems/
• [RD50] Web resource: https://sentinel.esa.int/web/sentinel/missions/sentinel-5/instrument-payload
• [RD51] P. Snoeij et al. Sentinel-1 Instrument Overview. SEASAR 2012 ESA, June 2012.
• [RD52] Web resource: https://www.esa.int/About_Us/Business_with_ESA/How_to_do/
ESA_s_Invitation_to_Tender_System_EMITS
• [RD53] Condor Engineering, Inc. MIL-STD-1553 Tutorial (1600100-0028), Issue 3.41, June 5, 2000
• [RD54] G. Maral, M. Bousquet and Z. Sun Satellite Communications Systems: Systems, Techniques and Technology, Wiley,
2009
• [RD55] ECSS. ECSS-E-ST-50-13C: Interface and communication protocol for MIL-STD-1553B data bus onboard spacecraft,
ESA, November 2008
• [RD56] MIL-STD-1553B Military Standard. Department of Defence USA. Sep. 1978
• [RD57] MIL-STD-1553C Military Standard. Department of Defence USA. Feb. 2018
• [RD58] S.Corrigan. TI Application Report SLOA101B - Introduction to the Controller Area Network (CAN), Texas Instruments,
May 2016
Biography
• [RD59] ECSS. ECSS-E-ST-50-15C. CAN bus extension protocol. ESA, May 2015
• [RD60] Texas Instruments. Product Datasheet SNOSAN0B - DS16F95QML EIA-485/EIA-422A Differential Bus Transceiver,
Texas Instruments, Sep 2005.
• [RD61] S.Corrigan. TI Application Report SLLA270 - Controller Area Network Physical Layer Requirements, Texas Instruments,
Jan 2008
• [RD62] ECSS. ECSS-E-ST-50-12C. SpaceWire - Links, nodes, routers and networks. ESA. May 2019
• [RD63] http://www.arquimea.com/?q=products-services/microelectronics/standard-components
• [RD64] LOPEZ, J., et al. LVDS: A RAD-HARD Octal 500 Mbps Bus LVDS Repeater for Space. AMICSA, 2016
• [RD65] SCHOLZ, Artur, et al. SpaceCAN-A low-cost, reliable and robust control and monitoring bus for small satellites. Acta
Astronautica, vol. 161, p. 1-11, 2019.
• [RD66] Leens, F. (2009). An introduction to I 2 C and SPI protocols. IEEE Instrumentation & Measurement Magazine, 12(1), 8-
13.,2009
• [RD68] Bouwmeester, J., Langer, M., & Gill, E. (2017). Survey on the implementation and reliability of CubeSat electrical bus
interfaces. Ceas space journal, 9(2), 163-173, 2017
• [RD69] https://networklessons.com/cisco/ccna-routing-switching-icnd1-100-105/introduction-to-ethernet
• [RD70] https://www.lantronix.com/resources/networking-tutorials/ethernet-tutorial-networking-basics/
• [RD71] Webb, E. "Ethernet for space flight applications." Proceedings, IEEE Aerospace Conference. Vol. 4. IEEE, 2002.
Biography
• [RD72] Breitenreiter, A., López, J., Reviriego, P., Krstic, M., Gutierro, Ú., Sánchez-Renedo, M., & González, D. (2019, July). A
Radiation Tolerant 10/100 Ethernet Transceiver for Space Applications. In 2019 IEEE 25th International Symposium on On-Line
Testing and Robust System Design (IOLTS) (pp. 220-223). IEEE, 2019.
• [RD73] Microsemi. HB0143 Handbook CoreEDAC v2.10. 50200143. 11.0, 2017

Onboard Data Handling and Telemetry

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Onboard Data Handling and Telemetry

Uploaded by

Copyright:

Available Formats

Onboard Data Handling and Telemetry

LESSON 8: TELECOMMAND & TELEMETRY

0. Introduction to Onboard Data Handling (2 h)

1. OBDH Fundamentals and architectures. Traditional and New Space (4 h)

2. OBDH Design process (2 h)

4. Telecommand & Telemetry (3-4 h)

4. Data Handling and Processing. Traditional and new space (6 h)

• Discrete I/O interfaces

• The Remote Terminal Unit (RTU)

As defined in CCSDS 130.0-G-3 [RD24]

Extracted from RD24

Space link communications are inherently complex:

Space link characteristics

Space link communications are inherently complex:

CCSDS are based on the seven layer of the OSI Basic

Space link characteristics

CCSDS has developed several Space Data

Extracted from RD24

Extracted from RD24

TC/TM managed by the CDHS

Spacecraft Ground System

OBDH decoding (bit stream segmented, framed and cut into

TC/TM managed by the CDHS

Spacecraft Ground System

(mainly from OBC and

TC/TM managed by the CDHS

Pending on the S/C OBDH architecture:

Serial Serial VC 1 VC n Spacecraft BUS DATA

Command VC Assembler & VC Assembler &

Start Sequence Convolutional

Physical Telemetry CADU

TC/TM managed by the CDHS

TELECOMMAND LAYER BY LAYER

Extracted from RD43

TELECOMMAND LAYER BY LAYER

The TC Space Data Link Protocol corresponds to the Logical

The Channel Coding Sublayer provides some additional

TELECOMMAND LAYER BY LAYER. GENERAL

TELECOMMAND LAYER BY LAYER. GENERAL

Extracted from RD43

Telecommand interface timing

Extracted from RD112 & RD44

Telecommand interface timing

Telecommand redundancy and physical layer

Sharing the Physical Channel

Telecommand redundancy and physical layer

Sharing the Physical Channel

Telecommand redundancy and physical layer

The typical configuration, which

Developed from RD21&12

Telecommand redundancy and physical layer

Developed from RD21

Telecommand redundancy and physical layer

Finally, in case a Transponder only has one output it is still possible to

Developed from RD21&12

Telecommand addressing and multiplexing

In addition to these identifiers, the TC-SDLP optionally uses an

TELECOMMAND LAYER BY LAYER

Channel coding and

Developed from RD25

TELECOMMAND LAYER BY LAYER

Channel coding and As the data is subject to pseudo-randomization process before

The next part of the CLTU consists of data