Onboard Data Handling and Telemetry

LESSON 3: ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES |

OBDH SUBSYSTEM IN CUBESATS
LESSON 3 THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Extracted from SAVOIR-HB-001

[RD21]
LESSON 3: 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 SAVOIR-HB-001

[RD21]
LESSON 3: 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 3: 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 SAVOIR-HB-001

[RD21]
LESSON 3: 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 3: THE COMPLETE CDHS ARCHITECTURE

Space AVionics Open Interface aRchitecture (SAVOIR)

Extracted from RD21

LESSON 2: THE COMPLETE CDHS ARCHITECTURE

OBDH ITT ESA

The contents of the ITT package:
- COVER LETTER
- STATEMENT OF WORK
- DRAFT CONTRACT
- SPECIAL CONDITIONS OF TENDER
The contents of the proposal:
- The Cover Letter
- Executive Summary 2.
- The Technical Proposal 3.
- The “Administrative Proposal”, consisting of:
- 3.1 The Management Proposal
- 3.2 The Financial Proposal
- 3.3 The Contractual Proposal
CDHS ARCHITECTURE EXAMPLES AND STANDARDIZATION ISSUES
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDH architecture examples

REAL EXAMPLES REVIEW

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The role of standards

• Traditional space sector involves a large number of organizations between different

space companies and space agencies mainly.
• The large investments required and the complexity of the systems developed
(subdivided into more subsystems) involves the intervention of different actors
designing different parts of the satellites.
• Standards were required to ensure compatibility between different subsystems as well
as implement a sort of quality control demanding specific development requirements.

CCSDS: Consultative Committee for Space Data Systems

ECSS: European Cooperation for Space Standardization
MIL-STD: NASA standards
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The role of standards: Project Consorptium example

Extracted from [RD51]

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The role of standards

ECSS overview (https://ecss.nl/wp-content/uploads/2019/12/ECSS-Tree-global(3December2019).png)

PAYLOAD CDHS ARCHITECTURES
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

Satellite Mission Types

• We can talk of the following mission types:

• Earth Observation missions, which orbit the Earth taking measurements of
the atmosphere, oceans, land surface, topography etc.
• Science missions, which may orbit the Earth observing celestial objects free
from interference from the Earth’s atmosphere, or may travel to and possibly
land on other objects in the solar system in order to explore them.
• Commercial missions, which include telecommunications and global
positioning systems.
• Military: Killer satellites, spy satellites
• Demonstration missions: Technology demonstration in orbit to increase
TRL.
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The Payload Data Architecture

For those medium/large satellites (usually with more than one payload instrument ) and
with a specific Payload Data System (not integrated in the Spacecraft platform) the
architectures we can find varies more than the platform CDHS. Nevertheless, we can
identify common elements to provide an overview of a Payload Data Architecture.

Extracted from [RD11]

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The Payload Data Architecture

• On-board payload data processing encompasses the data acquisition, transfer, storage,
data compression or reduction and transmission to ground of instrument and sensor
data. Quite often the amount of raw data generated by modern instruments is in excess
of what can be transmitted to ground. This makes it is necessary to use various signal
processing and compression techniques to reduce the amount of data. It is equally
important to have high speed data links, large on-board storage capabilities and digital
signal processors available that are fast enough handle data in the range of gigabytes
per second [RD10].

This is the reason why several platform elements we have seen for the CDHS are
replicated in the payload architecture -> there is need of dedicated hardware for the large
amount of data generated by modern instruments.
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The Payload Data Architecture

• A closer view of the Payload Data Architecture is presented in RD12.

Extracted from [RD12]

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The Payload Data Architecture - Instruments

• The instrument (or better said instruments as many medium/large satellites includes
several of them) are the main objective of the satellite itself.
• The nature and complexity varies in function of the mission objective, although the
tendency is including in each new mission more complex and more on-board
processing demanding payloads, what is leading to more complex and sophisticated
Payload Data architectures:
• Advance imaging processing
• Regenerative/adaptative telecom payloads
• Autonomous payloads for distant missions (exploration)
• …
• This implies that the Payload Data Architecture is increasing in complexity as an
independent system from the platform OBDH architecture. Accordingly components
used for payload data management are more performance demanding: high
performance ADCs, processors, memories,…
ALL of this makes the use of COTS components (screened) more common in nowadays
payload data architectures.
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

Instrument Data Routing and Storage

• “The data routing function is responsible for passing data from the instruments to the
data storage system, for passing configuration and control information to all of the
instruments and payload data-handling units, and for gathering housekeeping
information from the instruments” [RD12]
• Each instrument generates a different amount of data at a different frequency (from
kbit/s to Gbit/sec) thus changing the management strategy of that data Routing:
• Directly forwarding the data to the payload dedicated or platform mass memory (large amount of data
generated)
• Using a common high-speed network with a central router for all the instruments.
• It is more efficient if all the payload data generated by the various instruments is packet
using a common data format so its data handling (storage) is simplified.
• A dedicated mass storage memory for the payload is common in medium/large missions
generating a significant amount of payload data.
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

Payload TM Encoder, Compression and Processing

• The payload telemetry encoder essentially works in the same way as the platform
telemetry encoder but at significantly higher data rates.
• To manage the entire mass memory operation it is common to have a dedicated
memory controller.
• The memory controller is often based around a general purpose processor since it
receives rather complex commands from the plat-form computer, either via the payload
data bus or via a high-speed serial link.
• There is normally an access path from the platform computer to the mass memory. This
path is used to send housekeeping telemetry packets that are necessary to interpret the
science data properly, like spacecraft attitude and position at regular points in time. For
debugging purposes it is sometimes possible to read out the stored data to the platform
computer.
• Processing of data to support the control or operation of an instrument is normally done
within the instrument itself. An example is data compression. These processing
functions are normally implemented in a separate unit or board within a unit (to
increasing the effective downlink data rate and thereby reduce the time to send the
information to ground).
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

Payload Data Architecture Example: SENTINEL 5

The main characteristics of SENTINEL-5 instrument

are:
•Type: passive grating imaging spectrometer
•Configuration: Push broom staring (non-scanning) in
nadir viewing
•Swath width: 2 670 km
•Spatial sampling: 50x50 km2(UV1), 7.5x7.5 km2 (all
other channels),
•Spectral: 5 spectrometers (1 in UV1, 1 in UV2VIS, 1 in
NIR, 2 in SWIR)
•Radiometric accuracy (absolute): 3%, 6%(SWIR) of the
measured earth spectral reflectance.
•Overall mass: 290 Kg.
•Dimensions (x.y.z): 1.145 x 1.032 x 1.026 m3
•Design lifetime: 7.5 years
•Power Demand: 300 W
•Generated data volume: 139 Gbits per full orbit.
Extracted from [RD50]
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

Payload Data Architecture Example: SENTINEL 5

Extracted from [RD50]

OBDH SUBSYSTEM IN CUBESATS
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats

• CubeSat has volume, mass, and power limitations more extreme than in other
satellites. Therefore all subsystems are highly integrated:
• Integration of several subsystems in one hardware element.
• Replace some hardware by software
• Risk is a key parameter: small satellites can assume higher risks compared
to large satellites as the cost is significantly lower. In this way small satellites
can take advantage of the latest technologies improving efficiency, costs and
capabilities, moving fast for including disruptive technologies in their design
and increasing their competitiveness.
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats

Considering the large amount of CubeSat developed in the last years and the
one under development and the lack of standardization it is difficult to stablish a
general OBDH architecture for CubeSats.
Nevertheless, in general w.r.t OBDH in CubeSats the OBC absorbs a great part
of the different functions of the OBDH subsystem and it is usually implanted in
1 PCB including mass memory, a microprocessor as central processing unit,
clock , analog interfaces and other subsystem functions (as attitude control
system features or imaging processing features).
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

The CubeSats Space Protocol

Cubesat Space Protocol (CSP) is a small protocol stack written in C. CSP is

designed to ease communication between distributed embedded systems in
smaller networks, such as Cubesats.

The layering of CSP corresponds to the same layers as the TCP/IP model. The
implementation consists of a connection oriented transport protocol (Layer 4), a
router-core (Layer 3), and several network-interfaces (Layer 1-2).
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats - ISIS

• 400 MHz, power efficient ARM9 processor

• Multiple OS options available:
• FreeRTOS operating system for simple and lightweight cooperative multitasking
• KubOS Linux
• On-board telemetry: voltages, power-controller, and real time clock
• High reliability data storage and fail safe filesystem
• Flexible daughterboard architecture
• Robust design
• Includes Hardware Abstraction Layer Library Extracted from https://www.isispace.nl/
• Compliant with CubeSat standard
• Processor: 400MHz 32-bit ARM9 processor ▪ Volatile Memory: 64MB SDRAM ▪ Code Storage: 1MB
NOR Flash ▪ Critical Data Storage: 256kB FRAM ▪ Mass Data Storage: 2 x 2 GB high reliability SD
iicards for fail safe data storage (up to 32 GB on iirequest) or 2x any size standard SD cards

• Interfaces:
I 2 C master or slave mode ▪ SPI master mode (up to 8 slaves) ▪ 2x UART (RS232 + RS232 / RS485 /
RS422) ▪ General Purpose Input / Output pins (GPIO) ▪ ADC (10-bit, 8 channels) ▪ Pulse Width Modulation
(PWM) ▪ JTAG for programming and debugging ▪ Dedicated debug LEDs and UART ▪ USB host and device
▪ Image Sensor Interface
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats - ISIS

• Daughterboard architecture, allowing for easy addition of mission specific electronics or

interfaces.
• The pluggable daughterboard offers flexibility and customizability by providing a wide
range of interfaces for payloads, sensors, actuators in a compact form factor
• EM daughterboard: all interfaces for development and debugging
• FM daughterboard: all interfaces in compact form factor using high reliability connectors
• ▪ Custom daughterboard: design your own daughterboard with additional interfacing and
electronics based on mission requirements.

Extracted from https://www.isispace.nl/

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS
OBDHS Architecture in CubeSats – GOMspace
On-board Computer for Cube, Nano and Microsat missions
• Hardware features:
• High-performance AVR32
MCU with advanced power
saving features
• 512 KB build-in flash
• 128 MB NOR flash (On two
dies of 64 MB each)
• 32 kB FRAM for persistent
configuration storage
• 32 MB SDRAM
• RTC clock
• On-board temperature
sensors
• Interfaces:
• I2C, UART, CAN-Bus
• 8 external ADC channels that
can also be used as GPIO
• External SPI with 3 chip
selects
• Cubesat Space Protocol
(CSP)
• GOSH interface for check-
out
• Attitude control system
features:
• 3-Axis magneto resistive
sensor
• 3-Axis gyroscope
• 3 bidirectional PWM outputs
with current measurements
• I2C interface for GomSpace
Sensor Bus (GSSB)
• Electrical features: Extracted from
https://gomspace.com/home.aspx
• 2 x 20-position hard-gold
plated FSI one-piece
connector
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats – GOMspace

Extracted from
https://gomspace.com/home.aspx
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats – GOMspace

• ARM/FPGA on-board computer for on-board payload data processing:

Main Features
Performance:
• Perfect for on-board payload data
processing
• Xilinx Zynq 7030 Programmable SoC
• Dual ARM Cortex A9 MPCore up to 800
MHz
• 1 GB DDR3 RAM and 32 GB storage
• Powerful FPGA module – 125k logic
cells
Interfaces:
• Linux operating system
• Requires a NanoDock SDR for
integration into PC104 type stack
Extracted from
• SPI, I2C, UART and CAN data interfaces
https://gomspace.com/home.aspx
• 75 LVDS pairs or 150 CMOS
(combinable)
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats – GOMspace

Extracted from
https://gomspace.com/home.aspx
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats – OrbitalSystems

• OrbitalSystems OBC
• Functional Characteristics
• Processing Unit MCU ARM STM32F427 Clock Speed Up to 180 MHz SRAM 256kB internal,
1 MB external Flash Memory 2MB and 2GB shielded external System bus I2C or CAN

• Interfaces
• PC-104 Standard
• I2C, SPI, CAN, USART, Ethernet, USB
• Communication module interface o 2 x UHF com. Interface o Support of IQ Wireless
HISPICO • MEMS 3D Gyro for attitude determination • External Watchdog • Real Time Clock
• PC-104 System Bus Connectors • Designed for CubeSat Kit • ADC channels for external
use

Extracted from https://www.orbitalsystems.de/

LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

OBDHS Architecture in CubeSats – CUBEspace

CubeComputer is an onboard computer suitable for nanosatellite

C&DH, TT&C, mass storage and ADCS. The computer conforms to
the standard CubeSat form factor
Microcontroller • 32-bit ARM Cortex-
M3 • 4-48 MHz @ 1.25 DMIPS/MHz •
Internal & external watchdog
Memory and Storage • 32 KB
EEPROM • 4 MB flash for code
storage • 2 x 1 MB external SRAM for
data storage o SEU protection: FPGA
based EDAC o Latch-up protection •
MicroSD socket
2 x I2C • 2 x UART • 1
x CAN V2.0B • 1 x SPI Extracgted from https://www.cubespace.co.za/
LESSON 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

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 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

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 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

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 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

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 3: CDHS ARCHITECTURE EXAMPLES | PAYLOAD CDHS ARCHITECTURES | OBDH SUBSYSTEM IN CUBESATS

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