Onboard Data Handling and Telemetry

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH Introduction

• The On-Board Data Handling System (OBDHS) or Command

and Data Handling System (CDHS) is responsible for:
• Collecting, processing, routing, storing and downlinking on-board
generated data.
• Routing and storing uplinked data and commands.
• Perform onboard operations.
• Manage internal communications.

Can be compared with the nervous system of the satellite…

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH in the spacecraft

THEMAL AOCS
SUBS.
POWER
SUBSYSTEM PAYLOAD 1 PAYLOAD n
(EPS)

PROPULSION PLATFORM PAYLOAD DATA

CDHS HANDLING SYSTEM

GPS
RECEIVER

RADIO/TRANSPONDERS
Other satellites COMMAND LINK DATA LINK

TELECOMMAND TELEMETRY

GROUND
CONTROL
COMMAND DATA COLLECTION
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Different types of architectures

As described in [RD-8]
Reference architecture – A set of architectural design principles and a mapping of the
usual functions implemented by the software and the hardware
(General overview of your system)
Functional architecture – Focus is on the system functionalities to be implemented and on
the relation to their environment – A functional architecture is built, independently from the
issues brought by the integration on an execution platform.
(Function blocks that implements your system)
Physical architecture – The Physical architecture describes the processing nodes of the
system (i.e. on-board computer), sensors and actuators, the network topology (buses/point-
to- point links/serial lines) that interconnects them and the communication protocol used by
the physical communication layers.
(The hardware blocks that implements your system)
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

A Hardware Overview

HW architecture for Avionics as defined by

the SAVOIR Advisory Group [RD8]
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

The OBDH architecture (I)

• The reference block diagram presented in this course is a functional block

diagram.
• It is focused in providing an overview of the generic OBDH architecture and used
as a guide for understanding the different functionalities of the CDHS and how
their relations are. Hardware implementation is not represented in previous block
diagram.
• There is as many OBDH architectures as satellites. Nevertheless, excluding
human mission and launchers, the core of the OBDHS is very similar for much of
them in a general point o view.
• Pending on the type of mission (comms, EO, exploration,…) the OBDH
architecture corresponding to the payload varies drastically.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

The OBDH architecture (II)

• Pending on the satellite size and complexity, the OBDH can be implemented in
just a PCB or it may consist in several hardware elements distributed along the
satellite.
• The OBDHS shall be designed keeping in mind ALL the mission phases: testing,
launch, transfer orbit, operation and deorbiting.
• On-board Data Systems encompass a vast range of functional blocks that
include Telecommand and Telemetry Modules, On-Board computers, Data
Storage and Mass memories, Remote Terminal Units, Communication protocols
and Busses. These elements are common to all projects and are subject to a
demanding set of evolving requirements from Science, Exploration, Earth
Observation and Telecom missions.
 S/S Spacecraft Subsystems
TRANSPONDERS
TELEMETRY OBDH ARCHITECTURE
High / Low / Passive
Data format and
control logic
ADC (Functional)
Analog High Priority
Telemetry
S/S

Serial Digital HOUSEKEEPING

PAYLOAD

DATA STORAGE S/S

GPS On-Board
Processing HOUSEKEEPING
receiver Time
RTU S/S
Digital Bus
Interface
S/S S/S

Ultra-stable
Oscilator
RM &
Discrete
FDIR S/S
I/O Interfaces

HOUSEKEEPING

TELLECOMMAND DECODER S/S

COMMAND PULSE
TRANSPONDERS

Serial Digital DECODING UNIT

COMMAND COMMAND
MESSAGE MESSAGE High Priority Commands
VALIDATION DECODING Power Control & S/S
(HPC)
Distribution Unit
High Priority Command (PCDU)
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail - Telecommand

Telecommand (TC) function:

• Perform the telecommand reception, decoding, authentication, decryption and handling
including a direct ground capability of command pulse distribution.
• The telecommands, once validated, are multiplexed to the intended addresses. There are
two categories of commands: the high priority and the normal commands. The high
priority commands (HPC) are sent to the Command Pulse Distribution Unit (CPDU) for
immediate execution. The CPDU is either internal to the TC decoder or external and its
implemented in hardware, i.e. no software is involved in the execution of HPCs. The
normal commands are sent off to the OBC CPU to be either processed or relayed on the
system bus.

TELLECOMMAND DECODER S/S

COMMAND PULSE
Serial Digital DECODING UNIT
TRANSPONDER

COMMAND COMMAND
MESSAGE MESSAGE High Priority Commands
VALIDATION DECODING Power Control & S/S
(HPC)
Distribution Unit
High Priority Command (PCDU)
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail - Telecommand

• Commands, once received via the corresponding ground-space segment link

are decoded and placed in a queue for processing or distribution to other
subsystem/payload. The verification of each command is achieved by the
feedback of telemetry, usually from each stage in the command distribution
and after the operation of the command [RD2].

• Once received (from transponders or from the OBC) the command is firstly
validated (for verifying message integrity and security) and later decoded. The
command decoder determines command output type and the specific interface
channel to be used (serial digital or discrete).
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail - Telecommand

The commanding handling includes:

• Nominal commanding operations:
• Implement a digital data link to the OBC from ground.
• The possibility of implementing parameter changes
• Operational mode change following scheduling or specific commands.
• Software uplink
• High priority Commanding (HPC) or Essential Telecommand functions
• The Essential TC Function is mandatory on every spacecraft (ECSS). It 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 limited functions
• Exceptional situations when it is not possible to directly use nominal digital data link.
• The objective is to recover the satellite from the failure state
• Examples of HPC are switching a subsystem ON/OFF or resetting its parameters to the default
configuration
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Essential Telecommand Funtion

TELLECOMMAND DECODER S/S

COMMAND PULSE
Serial Digital DECODING UNIT
TRANSPONDER

COMMAND COMMAND
MESSAGE MESSAGE High Priority Commands
VALIDATION DECODING Power Control & S/S
(HPC)
Distribution Unit
High Priority Command (PCDU)

High Priority Command

Extracted from SAVOIR Advisory Group

[RD23]
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail - Telemetry

The Telemetry (TM) function:

• The Telemetry encoder collects the Telemetry packets from different sources (processing,
data storage, essential telemetry, payload), assembles the Telemetry transfer frames and
sends them to the TM/TC transceiver to be downloaded to the ground.
• Telemetry data generation or acquisition, Multiplexing and Transfer Frame generation,
coding and modulation can be done with an optional essential telemetry sampler for
monitoring of various spacecraft equipment without involvement of the processing function.

TELEMETRY OBDH ARCHITECTURE

TRANSPONDER

High / Low / Passive

Data format and
control logic
ADC (Functional)
Analog High Priority
Telemetry
S/S

Serial Digital
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail - Telemetry

• Some small satellites only have a single low speed transmitter and the housekeeping and
payload data are combined over the same link.
• For larger satellites with payloads capable of producing vast amounts of data, a dedicated
high-speed data link is used to store the data onto the onboard storage system. When the
satellites passes over a ground station, the OBC commands the high-speed radio
transmitter to retrieve and transmit the previously stored payload data through another
dedicated high-speed link from the onboard storage system.
• This approach frees the OBC from having to process large amounts of data and allows it to
devote its internal resources for time critical operations.
• A usual configuration is performing satellite bus platform control via a bi-directional TC/TM
radio data link in S-band (2.0-2.2 GHz). Payload TM downlink (uni-directional) is usually
performed via X-band (7.25-7.75 GHz). Nevertheless, for both, CCSDS standards are
applied.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – On-board time management

On-board time management:

• On-board time management provides a stable time reference that can be
synchronized from ground using TC. The time distribution for all systems of the
spacecraft is needed for synchronizations and time-stamping. Time can be
derived from on-board ultra-stable oscillator.
• Some satellites can also use GPS signal for synchronization.

GPS On-Board
Processing
receiver Time

S/S

Ultra-stable
Oscilator
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Processing

Processing function.
• The spacecraft control computer is a key element for controlling the spacecraft
and maintaining the safety of the spacecraft. The processing function is the core
of the OBDH subsystem and a key element of the spacecraft as the tendency is
implementing more and more functions in SW. Traditionally, large satellites used
a dedicated OBC for the SC bus platform and another OBC for the payload.
Nowadays, more and more satellites uses a single OBC for both payload and
bus platform.
• How this function is implemented varies pending on mission requirements, from
just a microprocessor running on a FPGA to tens of boards and different
components in charge of hosting different tasks of the processing function.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Processing

• The unit running the processing function receives different names and include
different functions pending on the mission: On Board Computer (OBC), also
referred to as Spacecraft Management Unit - SMU or Command & Data
Handling Management unit – CDMU or Central Processing Unit (CPU).
• The processing function hosts the Execution Platform SW (composed of RTOS,
SOIS upper layers, PUS, …) and the Application SW.
• Volatile and Non-volatile Memories, Safe Guard Memories, Booting mechanisms,
On Board Timer, Interface controllers, Reconfiguration modules, error detection
and reconfiguration mechanisms, scheduling…
• The OBDH is based on one or more OBC (standby redundancy is commonly
used for enhanced reliability).
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Processing

• SCs are systems that requires high level of autonomy as its maintenance is not
possible (or just reduced to remote commanding/reconfiguration).
• The S/C must perform autonomous decisions when ground communications is
not possible or increase the satellite autonomy as required by the mission.
• Processing function requires demanding timing requirements, real time control
and scheduling/planning.
• The control computer, whose internal architecture may depend on the
application and its availability requirements, includes autonomous failure
management functionalities to ensure that the spacecraft can autonomously
recover from major anomalies and enter a safe state without interaction from
the ground operators (we will see later the reconfiguration function).
 LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Processing

Extracted from [RD21]

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Processing

• Processors useful for space applications evolve and new processors appear at
intervals of several years instead of a new processor every year as happens on
the terrestrial market (same tendency but different cadence).
• If we do not consider the so-called New Space (CubeSats) lag of 6–8 years
between the commercial introduction of a technology in products and the
introduction of that technology in space products.
• ESA has qualified different OBC based on LEON processors. is a 32-
bit CPU microprocessor core, based on the SPARC-V8 RISC architecture
and instruction set.
• The current version is LEON4.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – RTU

The Remote Terminal Unit (also called Remote Interface Unit-RIU) is a unit
that is usually present on medium-large size spacecraft.
The RTU offloads the On Board Computer from analogue and discrete digital
data acquisition and actuators control tasks.

Processing

RTU S/S
Digital Bus
PAYLOAD
Interface
S/S
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – RTU

• Remote terminal unit acts as a data concentrator

• Standard interface to OBC/CDMU with a standardized protocol
• Standard Serial bus to devices
• S/C may employ several miniaturized versions

RTU overview as defined by the SAVOIR

Advisory Group [RD8]
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Data storage

Data storage functionality:

• Data storage capability for storage of telemetry and operational data (e.g. housekeeping data). Including
data compression when necessary.
• Data storage is essential when data generated exceeds link capacity or availability.
• A typical example is the Earth Observation missions where it is usually only possible to send data to
ground during 10 minutes once every 1.5 hours. It is therefore essential to have a very robust and
compact storage capability on-board. The mass-memories are being developed using various solid-state
storage technologies such as dynamic RAMs and Flash memories. For Earth Observation missions the
mass memory for the P/L data may belong to the satellite platform and sometimes, depending on the
capacity required, might be included inside the OBC as a single module
• Solid-state memories are prone to errors accumulation (e.g. SEU) due to radiation, therefore data
integrity must be maintained using coding and error correction techniques as scrubbing or EDAC
algorithms.
• Data compression algorithms allows to significant reduction on the storage needs in the satellite.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Internal communications

Internal communications function:

• Communication with the payload and other platform units through discrete signals, digital buses
or direct digital links.
• On-board buses and Data networks: Conventional space borne controls are based on Centralized
Control systems where a single central control unit is responsible to control the application tasks
and performing data management, resulting often in relatively high-performance requirements for
the CPU and high OBSW complexity. MIL-STD-1553 is used virtually in all ESA and European
OBDH systems, and the considerable amount of experience and know-how built by European
industries is enormous. Other low-medium speed data buses used are UART based on RS-422
physical layer and CAN. SpaceWire is a standard for high speed links (<160Mbit/s) and networks
for use onboard spacecraft, developed by the European Space Agency.
• The most common command and control bus used on a spacecraft platform is the MIL-STD-
1553B covered by the ECSS-E-ST-50-13C. An alternative to the MIL-STD-1553B is the CAN that
ESA and the European Space community is standardizing for space applications. UART serial
channels are also used specially to control AOCS sensors. The Spacewire technology is now
being increasingly used for data transfers < 160 Mbit/s and it can combine the command and
control function with massive data transfer. [RD6].
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Internal communications

According to ESA [RD6]:

• The space community is asking for a real improvement in the specification and use of
communications protocols. Interfaces between the central processing and the rest of
spacecraft subsystems are becoming more complex and demanding.
• Typically, previous developments have harmonized physical interfaces and low-level
data link protocols, but above this level proprietary solutions have been utilized. This has
without any doubt increased development and integration costs and limited the
possibility of element reuse without expensive modification. In comparison, the
commercial market on ground has systematically pursued the use of multilayer protocol
stacks resulting in simple integration and multi vendor compatibility. This commercial
trend is now being adopted for the flight avionics by the development and
standardization of protocols above the basic link layer.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – Internal communications

Buses in space overview as defined by the

SAVOIR Advisory Group [RD8]
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail – I/O & Housekeeping

• Discrete I/O interfaces for collection of on-board status and control data and for
distribution of configuration and control commands.
• The purpose of the housekeeping data (also known as engineering data)is to give
the operators an overview of the spacecraft health and general condition:
• Temperature of key elements of the satellite required for thermal regulation.
• Pressure in fuel tanks.
• Voltage and currents of electrical and electronics key elements.
• Operational status of the satellite, on/off status of valves and actuators, functional mode active etc.
• Status of the redundant elements.
• Batteries charge.
• …

Housekeeping data usually does not require high frequency sampling, nevertheless it
will be a continuous data flow during the entire mission.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH functionalities in detail –Reconfiguration and FDIR

As previously commented, SCs are systems that requires high level of autonomy as its maintenance is
not possible (or just reduced to remote commanding/reconfiguration).

The control computer, includes autonomous failure

management functionalities to ensure that the spacecraft
can autonomously recover from major anomalies and
enter a safe state without interaction from the ground
operators:
Processing
• On-board surveillance and Reconfiguration Module
(RM). RM receive alarms generated by the processing
function and takes actions in function of the alarm nature.
RM &
• Fault detection, isolation and recovery (FDIR) in the FDIR

form of a reconfiguration function that changes the current

COMMAND PULSE S/S
configuration when errors are detected, and a safeguard DISTRIBUTION
memory that is used to store the current context of the
processing function for later reuse in another configuration.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

• CDHS is not easy to be standardized: different companies/institutions approaches,

confidential information not shared, different satellite …
• Space AVionics Open Interface aRchitecture (SAVOIR) is an initiative to
federate the space avionics community and to work together in order to improve
the way that the European Space community builds avionics sub-systems.
• One of the main objective of SAVOIR initiative is:
• Rationalize the development of Data Handling Systems (DHS) in order to constrain
development costs
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

SAVOIR is working in cooperation with the

standardisation working groups of:
•the European Cooperation for Space
Standardisation (ECSS),
•the Consultative Committee for Space Data
Systems (CCSDS) and in particular the Spacecraft
Onboard Interface Services Area (SOIS).
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Taking the opportunity SAVOIR documentation provides we will analyze more in

detail the CDHS in spacecrafts commented in previous slides, with more detail.
Concepts are the same presented in the simplified diagram defined for this
subject, but with a more detailed description of different blocks interconnections,
hardware/software implementation and crosstrapping considerations.
From the understanding of custom general functional block diagram presented
so far, we will be able to better understand SAVOIR functional architecture.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Extracted from RD21

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

The same diagram but
where the functions are
located within typical
hardware building blocks.

Extracted from RD21

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Cross-strapping

Cross-strapping is the term used referring how to interconnect redundant modules. At physical
level there are several types of implantation and configurations (e.g. if cold redundancy is used,
the redundant modules that are switch off shall not disturb the active modules).
The objective of cross-strapping is to increase the reliability of a functional chain by better
exploiting the available redundant resources. However, it may introduce additional cases of
failure propagation, dependencies, and single point failures. Usually, electronics digital
components are not prepared to receive current/voltage signal at their inputs while the
component is not powered. This could lead to unwanted leakage currents, perturbances,
malfunctions or premature component degradation. Cross-strapping techniques shall be
carefully considered in the design, especially in the CDHS.
LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Showing the implicit cross-

straps derived from the
communication needs.
They basically occur within
the SAVOIR system when
a hot redundant function
has an input or output

Extracted from RD21

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

An overall view of the SAVOIR reference architecture: it presents the platform

functions groups, payload functions, and the layered structure of the software
executing in the OBC, called Central Software (CSW), and consisting of an
Execution Platform and Applications.

Extracted from RD21

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Extracted from RD21

LESSON 1: INTRODUCTION

OBDH Introduction – 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
LESSON 1: INTRODUCTION

OBDH Introduction – 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
LESSON 1: INTRODUCTION

OBDH Introduction – 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
LESSON 1: INTRODUCTION

OBDH Introduction – 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
LESSON 1: INTRODUCTION

OBDH Introduction – 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] https://www.esa.int/About_Us/Business_with_ESA/How_to_do/ESA_s_Invitation_to_Tender_System_EMITS