Onboard Data Handling and Telemetry

LESSON 4: CDHS DESIGN PROCESS

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 (6-8 h)
• Onboard communications links introduction
• MIL-STD-1553B
• CAN
• SpaceWire and OTHERs: Ethernet, I2C

4. Telecommand & Telemetry (6 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)

 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 4: CDHS DESIGN PROCESS

CDHS Design process

• With the objective of providing a general overview of the CDHS design process,
following slides introduce an example of the usual phases of a project for the
development of a CDHS for a spacecraft.

• The process herein described it is just a general overview of main steps and
tools used during a typical CDHS design, with the only objective of providing a
general overview of this process. It does not intent to be an exhaustive
description of ESA standards or space projects management guide.

• ECSS standards can be consulted for further and more detail information.
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 0 – SPECIFICATIONS (KO - RR)

ALWAYS, ALWAYS, ALWAYS you should have specifications as much as clear as

possible before starting any engineering professional development.

• If you want to do something efficiently you should know what is required to be

done, right?

• Something so significant is constantly underestimated in engineering projects and

it is a typical root of problems…
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Extracted from
Requirements Engineering
— Introduction:

https://medium.com/omarelg
abrys-blog/requirements-
engineering-introduction-
part-1-6d49001526d3
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 0 – SPECIFICATIONS (KO-PRR)

In space projects a widely used tool is the so called TRACEABILITY MATRIX. A simple
tool used for requirements traceability along the project life.
Objectives:
• To provide visibility into the requirements implementation of the subcontracted item.
• To describe non-compliances in detail.
Example:
Requirement ID Requirement Compliance Notes
description (C,PC, NC..)

Let´s see some real examples

LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition (PRR – PDR/ARR)

Some stakeholders involved in the process:

• The data handling architect **
• The system engineer **
• The avionics design engineer **
• The product line manager
• The avionics integration responsible
• The verification responsible / engineer
• The project manager
• The equipment suppliers
• The customer
• The project sponsor
• …
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition (PRR – PDR/ARR)

Objective: Define the functional blocks (including functionality description and maybe
some general overview of each block) required for being compliant with requirements.

The number and complexity of the required functions to be included in our architecture
shall be the minimum necessary to be compliant with requirements (remember,
any function included in the architecture, later shall be developed meaning time and
cost).
• Considerations for architecture definition:
• Bus constrains (mass, power, volume budget)
• Reliability requirements
• Satellite mission, orbit and lifetime
• Development schedule and cost budget
• Mission environmental conditions (radiation or temperature)
• …
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition

The design team should consider:

• Analyse the payload/s of the spacecraft. It is required an specific payload CDHS or a
common CDHS can be used for payload and bus?
• What are the command processing and telemetry requirements (channel numbers,
coding/decoding requirements)?
• Processing needs? Which tasks HAS to be done on-board and which ones may be
processed on-ground? Other subsystems (e.g. AOCS) demand processing in the OBC?
• FDIR, reconfigurability, watchdog, high priority TM&TC…reliability considerations
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition

The design team should consider:

• Comms link time availability? Data storage ROM needs?
• Housekeeping sizing
• On-board time management possibilities: granularity (time resolution), uncertainty, stability,…
• On-board comms links protocol definition with other subsystems
• CDHS usually includes/absorb functionalities that seems not to fit in other subsystems.
CDHS architect should limit and identify those and analyse if they should be included as part
of the CDHS or delegated to other subsystems.
• Security (encryption) considerations
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition

Important notes:
• Evolutionary nature design for CDHS shall be considered as it is a central point and
critical system of the spacecraft.
• CDHS is usually one of the latest subsystems of the spacecraft to be defined: it can
not be completely defined until other satellite subsystems and payload are defined.
• Overall vision of other satellite subsystems is required
• This subsystem is usually done by the satellite prime contractor.
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition

CDHS architecture definition is a cycle between subsystem functional blocks definition

and feedback from other satellite development teams and stakeholders:

Requirements
Other susbystems inputs Architecture Other susbystems feedback
Upper level integrator budgets and I/Fs analysis & definition Upper level integrator budgets and I/Fs feedback
Other stakaholders inputs Other stakaholders feedback
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition
During your architecture definition overall CDHS budget definition and I/F shall be
provided:
• Estimated mass, volume, data, power,…
• I/Fs description

For estimations:
• Derive budgets estimations from previous hardware designs similar to the subsystems of your CDHS
(analogue estimation)
• Interview with internal/external team experts
• Scale & subdivide -> reduce the granularity of your estimations will always provide more accurate
results (consider time/cost constrains)
• Use analytics in your estimations for avoiding optimistic / pessimistic results:

𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐𝒐 + 𝟒𝟒 ∗ 𝒎𝒎𝒎𝒎𝒎𝒎𝒎𝒎 𝒍𝒍𝒍𝒍𝒍𝒍𝒍𝒍𝒍𝒍𝒍𝒍 + 𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷

𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬 =
𝟔𝟔
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 1 – Architecture definition

• Margins and spares should be considered!

• The margins are reduced as the uncertainty of your design decreases. Up to 25 %
margin at the beginning of architecture definition is a common practice.
• Including spare channels in your CDHS is a good risk mitigation technique. CDHS is
the nervous system of our satellite, therefore future channels may be required for
other subsystems included during definition phase.
• Your architecture is approved during the PDR or the ARR milestone. RIDs and
NCR,RFD,… could be raised…
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

RID
Review Item Discrepancy

Extracted from RD45

LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

NCR, RFD and RFW

NCR (Nonconformance Report): identification and processing of nonconforming items (not in

conformance with one or more specific requirements), which can be performed at each customer/supplier
level. This includes:
• corrective actions against root causes, to avoid recurrence for other products;
• prompt and effective communication between suppliers and customers;
• the prevention of nonconformance occurrence, from the analysis of nonconformance records and derived
lessons learned.
Let´s see an example (ECSS-Q-ST-10-09C)

RFD (Request for Deviation): requested by contractors prior to manufacture for obtaining a specific written
authorization to depart from a particular requirement(s).
RFW (Request for Waiver): is a request for authorization to accept an item which, during manufacture or
after inspection, is found to depart from specified requirements, but nevertheless is considered suitable for
use as is or after repair by an approved method.
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 2 – Detail Design (PDR – CDR/MRR )

Translation from functional architecture to hardware architecture shall be accomplished

first (usually this is done in parallel with the functional architecture definition as it is
closed related).
How we are going to implement physically the different functionalities described in the
functional architecture?
• Technology selection for the different subsystems: availability, costs, specifications, lead-time, size, mass,
volume….
• Physical distribution of the different elements, definition of development teams/subcontracting
• Define a clear set of requirements for all CDHS subsystems… (requirements scalability to other design teams or
subcontractors )
• Stablish mass, power, volume budgets for all developments
• Maintain and update all project documentation between all stakeholders (ICDs updated are essential).
• Design and simulation: WCA, PSA, FMECA,…
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Typically in space developments…

Pending on Project development strategy

Upper level subsystem integration for further test/qualification Integration in upper

FM subsystem

Breadboard -> Structural Model ->Engineering Model -> Qualification Model -> Flight Model

For functional verification

Structurally Shall be functional and
For design (representative but not fully
representative of physically representative of the
verification physically compliant with final
end item FM
purposes. FM)
General use
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 2 – Detail Design (PDR – CDR/MRR )

There is a characterization of the CDHS done before to proceed with manufacturing. In

this characterization the QM design is analysed for verifying results obtained after
simulation & analysis are within the specs and in line with the results obtained with
previous design steps (BB and EM). If not, there is need to modify design until being
within specifications. If this is not possible, there is need of release a RFD.
Detail Design phase is completed when the customer accepts the detail design during
the CDR.
• Document package delivered (including Detail Design Description Documents, ICD, WCA, SPF,
verification reports, Compliance Matrix….)
• RIDs (Review Item Discrepancy), RFD and NCs should be reviewed and accepted

Manufacturing authorization is obtain directly after CDR or in a separated milestone

(MRR) if further discussions analysis are required.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Typically in CDHS developments… “Pending on project development strategy”

Design -> S&A-> BB-> Re-Design/S&A-> EM -> Re-Design/S&A -> QM Design

Characterization
Analysis/simulation w.r.t specs & previous results

YES NO
OK? Re-Design, RFD

Tests &
qualification campaign

Acceptable YES
Re-Design RFW? FM and Acceptance Test
deviations?

S&A -> Simulation & Analisys

 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

STEP 3 – Qualification (TRR – TRB )

• Qualification camping starts with the acceptance of the Qualification Plan and related
documentation during the TRR and ends with the review of the Qualification results
after performing the qualification campaign.
• During the TRR (Test Readiness Review) the test plan and procedures are reviewed.
• Once performed the qualification campaign, in the TRB (Test Review Board) results
(Test Reports) from the qualification campaign are reviewed. After acceptance of the
TRB it would be possible to start FM development activities.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Worst Case Analysis (ECSS-Q-ST-30C-Rev.1)

As defined in ECSS-Q-ST-30C-Rev.1. “The purpose of the WCA is to demonstrate that the item
being analysed performs within specification despite particular variations in its constituent part
parameters and the imposed environment… Its principal use is to prove that the equipment is
able to meet the specified performance requirements under worst case conditions of operation
and to demonstrate sufficient operating margins for all operating conditions.”

WCA is a very important analysis tool for the CDHS process design. With this analysis the designer shall
evaluate the circuit performance w.r.t the operational requirements considering for the calcs the worst
(more severe case) conditions of each component that constitute the system under analysis (tolerances,
mission environmental conditions,… ).

The results obtained (propagation time delays, rising/falling times, voltage input/output voltage/current
levels…) shall be in agreement (with a relevant margin) in any operational condition of the circuits under
analysis.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Worst Case Analysis (ECSS-Q-ST-30C-Rev.1)

The WCA is calculated along the design. From a reference working point (usually
defined using the nominal values parameters for each component) the WCA studies
how different factors varies the performance of the circuit from this reference working
point (“drift”). Some of the effects to be consider that varies nominal values of
electronic components and are considered during WCA are the following:
• Temperature
• Initial tolerance
• Aging
• Radiation (mainly TID)
• EMC
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Worst Case Analysis (ECSS-Q-ST-30C-Rev.1)

WCA is implemented at different levels: from simple functional elements of the subsystems (e.g. power
on reset circuitry) up to functional block or subsystems (e.g. satellite decoder).
The data (how the electronics components varies their parameters from nominal values) for performing
the WCA is obtained from different sources:
• Component manufacturer (datasheets, information by request)
• Model libraries
• Test results
• Previous knowledge of the organization
• ESA/ECSS
• …
The designer tries to find data from any reliable source for completing its WCA. This is a complex
process, organization knowledge about components is usually a very costly and confidential
information.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Worst Case Analysis (ECSS-Q-ST-30C-Rev.1)

At the end, once we have obtained parameter information of the components that constitute our circuit
we shall consider, for each relevant parameter of our analysis the following:

Parameter value = Nominal value + Δf (ageing+temp, rad,EMC)

Numerical methods are used for analyzing the variance of all the parameters in the circuit and how it
affects circuit overall behaviour. The most common used method it eh Monte Carlo method using a CAD
software (e.g. PSPICE).
The software runs thousands of simulations, considering multiple combinations of values for each
parameter value in function of numerical distributions. At the end, as a result of combinatory, worst case
conditions are obtained as a combination of variance of each parameter value (this method is only valid if
a great number of simulations are performed)
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Part Stress Analysis

PSA is the analysis of the electrical/mechanical solicitations of an electrical/mechanical

component for an specific application (considering specific application conditions). The
objective of this analysis is verifying that every electrical/mechanical component of our
design will be used within the manufacturer limit values with a margin.

Affects to all the components of the design and to all parameters of each component
that are defined by the manufacturer for a certain application limits.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

Part Stress Analysis

All the components shall be used ALWAYS within the limits of use defined by the
manufacturer: we should not use a component out of maximum ratings values defined
by the manufacturer.

But with this is not enough, we should consider in our design reasonable margins. For
doing so, we use the so called “derating”. Derating is a security coefficient we should
consider, reducing the maximum rating values for our design.

A good PSA will define adequate derating valued for using the components without
“stressing” them, reducing its degradation, probability of failure is also reduced and
therefore increasing security margins and reliability of the design.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA

FMECA [“Fah-Me-Kah”](Failure Modes, Effects and Criticality Analysis) is a design tool

oriented to:
• discover and analyse ALL potential failure modes of a system.
• Once detected it is necessary to evaluate the effects of each individual failure mode and determinate
how to correct or mitigate those effects
It shall active along the whole design phase (from architecture to final detailed design)

For the OBDH subsystem this tool is essential as it will help to define an architecture and
detailed design in accordance with the reliability specified for each particular mission.

ECSS standard ECSS-Q-ST-30-02C – Failure modes, effects (and criticality) analysis

(FMEA/FMECA) [RD48] defines the process.
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA
Some relevant terminology used in FMECA/FMEA:
• FMECA: Failure Modes, Effects and Criticality Analysis
• FMEA: Failure Modes and Effects Analysis
FMECA is a quantitative tool directly linked with the reliability analysis (it provides values of
criticality for each failure mode detected) while FMEA is a qualitative tool, it just provides
analysis.
Criticality: “Combined measure of the severity of a failure mode and its probability of
occurrence”
Severity: “Classification of a failure or undesired event according to the magnitude of its
possible consequences”
SPF (Single point Failure): Part of a product that, if it fails, will result in the unrecoverable
failure of that product
Failure propagation: Physical or logical event caused by failure within a product which can lead
to failure(s) of products outside the boundaries of the product under analysis
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA
Basically the FMECA searches any possible failure and determines if the failure can
propagate to other systems (what shall be mitigated/reduced/eliminated as far as
possible).

SPF shall be identified and removed if the consequences are not acceptable at system
level (if its criticality is too high).
The most common analysis in FMECA are:
 Functional analysis of each failure mode and its effect at system/subsystem level
 Detail FMECA at component level (for CDHS electronic level)
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA
 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA

Extracted from RD48

 CDHS design process
LESSON 4: CDHS DESIGN PROCESS

CDHS Design process

FMECA/FMEA
LESSON 4: CDHS DESIGN PROCESS

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 4: CDHS DESIGN PROCESS

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 4: CDHS DESIGN PROCESS

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 4: CDHS DESIGN PROCESS

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 4: CDHS DESIGN PROCESS

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
LESSON 4: CDHS DESIGN PROCESS

Biography

• [RD59] ECSS. ECSS-E-ST-50-15C. CANbus 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