On-Board Data Handling (OBDH) Hardware Introduction

On-Board Data Handling (OBDH) Hardware

Introduction

THEOS-2 Small Satellite

Poonsak Pasit

Outline:

Introduction: On-Board Data Handling (OBDH)

Scope of On-Board Computer (OBC)

Core Data Handling System (CDHS)

Data Handling Unit (DHU) Architecture

OBDH Interconnection Architecture

OBDH Operating Diagram

Network Considerations

Designing an On Board Computer

Radiation Effect Mitigation

Data Protection

On-Board Computer (Processor Architecture)

Memory Selection

The Hardware Module Development Process

Ex. De-rating Electronic Devices Sheet

Ex. Electrical Electronic Electromechanical (EEE) Parts Assessment

Ex. Test Verification Matrix (TVM) Sheethttps://www.sstl.co.uk/space-portfolio/launched-missions

THEOS-2 SmallSAT

Acronyms

AOCS = Attitude and Orbit Control Systems

AIT = Assembly, Integration and Test

AMBA = Advanced Microcontroller Bus Architecture

BSP = Board Support Package

CAN = Controller Area Network

CCSDS = Consultative Committee for Space Data Systems

C&DH = Command and Data Handling

DHU = Data Handling Unit

DR = Discrepancy Report

ECSS = European Co-operation for Space Standardization

ESA = European Space Agency

EVT = Environment Test

FPGA = Field Programmable Gate Array

GPS = Global Positioning System

JTAG = Joint Test Action Group

OBDH = On-Board Data Handling

OBC = On-Board Computer

RF = Radio Frequency

SPARC = Scalable Processor Architecture

TC = Telecommand

TCC = Telemetry, Tracking and Command

TM = Telemetry

VHDL = Very High Speed Integrated Circuit (VHSIC) Hardware Description Language

Introduction: On-Board Data Handling (OBDH)

It receives, validates, decodes and distributes command to other subsystem.

It gathers, processes, storages, housekeeping and manage downlink data.

• The on-board data handling (OBDH) subsystem of a satellite is the subsystem which carries and stores data between the

various electronics units and the ground segment, via the telemetry, tracking and command (TT&C) subsystem.

On-Board Data Handling (OBDH) Hardware comprise of

On-Board Computer (OBC) for controlling satellite platform.

RF transmitter and receiver units for handles all communication to ground station.

Data Handling Unit (DHU) for stores data, manage payload

and manage downlink data.

Introduction: On-Board Data Handling (OBDH) Hardware

Role : What we going to do?

Design electronic circuit and hardware for satellite application

Contribution to the requirements definition as well as during preparation

and maintenance of specifications for Data Handling subsystems

and elements (e.g. Onboard Computer, Interface Units, Mass-Memory etc.)

Producing written documentation, specification, design, integration and test

(including presentation material) of technical work in accordance

with project requirements.

Execution of electrical tests on platform and satellite level, interface tests, functional tests,

performance tests Onboard Data Handling (OBDH) Hardware as well as support for payload testing

Picture during perform electrical test at Lab.


Requirements : Skill to work in OBDH hardware

Bachelor’s degree or higher in Electrical/Electronic Engineering

Experience with analogue / digital electronics design

Experience with coding for embedded platforms using C and / or C++

Experience with designing/building FPGAs using VHDL, Verilog

Knowledge of on board links, buses, wireless local networking and

communication protocols.

Well-developed communication skills, used to work in a team

Sense of responsibility and an effective way of working

Good English skillPicture during the FPGA design training


Design tools in THEOS-2 Small Sat

Schematic/PCB design software : CADSTAR Design Editor 16.0

Circuit simulation software: Pspice

FPGA Tools :

Vivado HLS is a design environment for FPGA products from Xilinx only ( For design high performance processor

Xilinx Zynq ARM cortex-A9 )

Libero® SoC Design Suite from Microsemi -> For core OBC

CADSTAR Design Program

Scope of OBC

OBC (On-Board Computer) responsible for:

The control of the spacecraft platform and payload

• Provide the primary routine telecommand/telemetry interface for the spacecraft

• Provide the Payload and Data Recorder control interface

• Provide the file transfer between the spacecraft and ground

• Provide the processing capability to

– Implement the attitude control algorithm

– Schedule platform/payload operations

– Maintain log files of telemetry/telecommands

– Spacecraft safety & health monitoring

Core Data Handling System (CDHS)

Key Specification:

Main Flight Computer

- LEON3FT Base OBC

High Performance CPU (not used on THEOS-2)

- Dual Core ARM Cortex-A9

GPS Receiver GPS L1 (1575.42 MHz)

Command processor

- S-Band Receiver

- S-Band Transmitter

AOCS interfaceCore Data Handling System (CDHS) of THEOS-2 SmallSAT

SSTLTV: https://www.youtube.com/watch?v=WpbIH-IXr9M

Data Handling Unit (DHU) Architecture

OBDH Interconnection Architecture

The OBDH Subsystem comprises of

x2 CDHS

OBC (On-Board Computer)

AIM (AOCS Interface Module)

GPS module

Receiver

CAN (Controller Area Network)

1 X DHU (Data Handling Unit)

OBDH Operating Diagram

The memory card functions are store payload dataand managing file Uplink, Downlink via Saratogaprotocols. Saratoga was first developed at SurreySatellite Technology Ltd, for hop-by-hop transferson privately-owned networks.


CDHS

OBC

RFGPS

Board I/O

DHU

Star tracker

Gyros

Magnetometers

Magnetorquers

Reaction Wheels

Centralized Architecture (Star)

- Addition of new modules is not easy

- Wiring harnesses become larger


CDHS

OBC

RFGPS

Board I/O

DHU

Star tracker

Gyros

Magnetometers Magnetorquers Reaction Wheels

Distributed Architecture (Bus)

- Data bus support all data for the system

- Component are node that use standard communication protocols

to exchange data, interrupt

Data

Bus

Bus Architecture Network

MIL-STD-1553B Introduced by USAF in 1973

Used in thousands of military and commercial aircraft and in many spacecraft

Multi-drop bus (Master-Slave architecture)

The raw data rate is 1 Mbit/s

On-Board Data Handling (OBDH) data bus European Space Agency (ESA) standard onboard data bus (was defined the mid-1970s)

Used in thousands of military and commercial aircraft and in many spacecraft

Multi-drop bus (Master-Slave architecture)

Controller Area Network (CAN) Bus

Ex. Distributed Architecture Network (MIL-STD-1553B)

MIL-STD-1553B , it was originally published in 1973 by US Air Force and was designed for use in US military aircraft.A MIL bus consist of a “Bus Controller” (BC) and up to 31 “Remote Terminals”

Ex. OBDH Network (ESA OBDH Bus)

CAN Bus

CAN Node Each node requires a

Central processing unit, microprocessor, or host processor .

CAN controller; Usually an integral part of the microcontroller.

Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU]. SSTL has developed its own higher layer protocol on top of the standard CAN frame.

CAN for spacecraft usage (CAN-SU2) forces peer to peer addressing and is optimized for

Telemetry, Telecommand and Buffer Transfer.

Two sub-system categories are connected to the CAN bus

Semi-smart modules that respond to tele-commands and provide telemetry for example a reaction wheel will have a tele-command

to set its speed, and telemetry value to read its speed.

Data processing modules, onboard computers etc., that control the satellite, OBC will control all payload by tele-command on the CAN bus.

Redundant busses are selected via latching relay

A module can be commanded to change to the secondary bus or will automatically switch buses if

the module does not receive any messages for 5 minutes.

SSTL CAN Bus System topology


Environmental Considerations

Launch phase issues.

Vibration : occurs when rocket launches

Structural vibration : motors and atmosphere

Acoustic noise

Shock : occurs during launch when

Fairing of rocket jettisoned

Satellite separated

Release of Deployable

De-pressurization

Atmospheric pressure drops rapidly with altitude

Spacecraft design needs sufficient venting


Environmental Considerations

In orbit environmental issues.

Vacuum Outgassing of materials

Cold-welding of materials (Bonding between metals)

Thermal issues as no effective convection

Radiation The Sun and other more distant objects in space emit radiation

Particles can upset satellite memories and cause the performance of electrical

components, like solar panels, and sensitive surfaces such as thermal and optical to get worse over time

In orbit environmental issues : Radiation

2 main types of radiation effects considered :

Dose effects - accumulation over time effect caused by large number of protons and electrons

Total Ionizing Dose (TID) -> Long term degradation of components

Optical/thermal coatings degradation

Displacement damage dose (DDD) -> Protons in space can cause damage to the silicon lattice – protons strike silicon atoms.

Random in time - caused by random heavy ions

Single Event Effects (SEE)

Destructive SEE (DSEE) SEB (Single event burnout), SEGR (Single event gate rupture) -> concern MOSFETs

SEDR (Single event dielectric rupture) -> concern non-transistor devices such as capacitors

SEL (Single event latch-up) -> Most CMOS products at risk and it can destructive.

Non Destructive Effect (NDSEE) SEU (Single Event Upset)

SET (Single Event transient)

SEFI (Single Event Functional Interrupt)

In orbit environmental issues : Radiation

Design activities :

TID : Can be shielded

Testing shows most COTS parts can survive at least 5krads

SEE Redundancy within circuit, Primary/Secondary at subsystem level

Assume issues are going to occur and put in protection devices eg.

– EDAC, TMR, Latch protection etc.

Data Protection

Techniques for protecting data:

• Triple Module Redundancy (TMR)

– Data is written (triplicated) to 3 memory devices/locations. On read-back, data is voted at the bit level.

• Error Detecting and Correction (EDAC)

– Linear block code represented as (n,k) where k = data bits coded with parity bits to form an n bit code

• Scrubbing

– Routine read, correction of bit errors and writing correct data back to original location.

Both TMR and EDAC Code schemes are able to prevent errors, however if data is left in memory the errors can

accumulate over time and eventually defeat the protection scheme.

To mitigate this, the memory has to be routinely “scrubbed”. “Scrubbing” or memory washing involves reading out

each bit of data and rewriting it to reinitialize the error protection and correct any errors that have appeared since

the last use.

Data Protection->Triple Modular Redundancy (TMR)

TMR can be used to mitigate the effect of a SEU in sequential logic,

Memory and processor blocks by implementing voting logic on critical signals.

Data Protection->Hardware EDAC

Processor Selection - Types

There are several types of processor that could be used to create a OBC:

Microprocessor is a single-chip implementation of a CPU.

Low power consumption

Small footprint

Flexible features

FPGA Embedded Soft Core Processor

Allows for customization

Increased performance over Microprocessor

Flexible design

Can customize features

ASIC Processor

High performance

Dedicated functions

Proven design


The Zynq-7000 architecture tightly integrates a dual-core, 650 MHz ARM Cortex-A9 processor with Xilinx 7-series Field Programmable Gate

Array (FPGA) logic.


GR712RC is a dual-core LEON3FT (Fault-tolerant) SPARC V8 processor, with advanced interface protocols, dedicated for high

reliability Rad-Hard aerospace applications.

It has been designed for operation in the harsh space environment, and includes functionality to detect and correct (SEU) errors

in all on-chip RAM memories.

https://www.gaisler.com/index.php/products/components/gr712rc

The Arty Z7 is a ready-to-use development platform designed

around the Zynq-7000™ System-on-Chip from Xilinx. The Zyn

q-7000 architecture tightly integrates a dual-core, 650 MHz A

RM Cortex-A9 processor with Xilinx 7-series Field Programma

ble Gate Array (FPGA) logic.

FPGA part: XC7Z020-1CLG400C

On-Board Computer Development

The GR712RC development board has been designed to support the develop

ment and fast prototyping of systems based on our GR712RC dual-core 32-bit

fault tolerant LEON3FT SPARC V8 processor

Memory Selection

Several different memory technologies are available for use:

SRAM

DRAM

MRAM

FRAM

Flash

Each technology however has advantages and disadvantages that

naturally determine where they can be used

Memory Selection - SRAM

Technology: SRAM - Static Random Access Memory

Advantages:- SRAM has lower access time,

which is faster compared to DRAM.

- Data does not require refreshing

- Low power consumption

- High reliability

Disadvantages:- Cost

- Memory Capacity

- Availability

SRAM is usually used for cache memory.

Volatile: loses data content on power loss

Memory Selection - DRAM

Technology: SDRAM – Synchronous Dynamic Random Access Memory

Advantages:- Increased Capacity over SRAM

- DRAM offers a high packaging density.

- Lower Cost

Disadvantages:- Requires data to be refreshed periodically (refresh each memory cell)

- Increased power consumption over SRAM

- Small speed penalty for random access

SDRAM usage as main memory

SDRAM while the Core-DHS makes use of the newer technology DDR3 to increase capacity further and minimize board area required.

Volatile: loses data content on power loss

Memory Selection - MRAM

Technology: MRAM – Magneto-resistive Random Access Memory

Advantages:- Low power consumption

- Low access times

- High number of write cycles

Disadvantages:- Large component size

- Low capacity compared to flash

MRAM is a good alternative to flash providing not only low access times, but also has a high number of write cycles making it a good alternative

for storage of data that will be updated.

Non Volatile: Content not loss on power down

Memory Selection - FeRAM

Technology: FeRAM – Ferro-electric Random Access Memory

Advantages:- Low power consumption

- Low access times

- Good Radiation Performance

- Not sensitive to magnets

Disadvantages:- High cost per bit

- Low capacity compared to Flash

Similarly to MRAM, FeRAM is good for storage of log files / software images that a likely to change or be updated on a regular basis


Memory Selection - Flash

Technology: Flash

Advantages:- High Capacity

- Small component size

- Low Cost

- Simple interface

Disadvantages:- Limited number of write cycles

Flash memory is very appealing due to its storage capacity and simplicity.

Due to the limited number of write cycles flash memory cannot be used for log files but it primarily used for software images.


Requirements Capture

The Hardware Module Development Process

Definition Phase: PDR (Preliminary Design Review)Lessons learnt SSTL heritage circuit designs.

Design Development Verification Plan (DDVP)

Status update, QST, DRs, Risk, Plan

Design Phase: CDR (Critical Design Review)To review the final design of module

PIB Interface Control Document (ICD) Review

EEE PAS Review (ECSS-E-ST-10-12C)

De-rating (ECSS-Q-ST-30-11C) Review

Schematic PCB Layout Review

Build Instruction review

Test Verification Matrix review

Support Failure Mode Effects & Criticality Analysis (FEMECA)

Support Failure Detection , Isolation and Recovery (FDIR)

Manufacturing Phase: MRR (Module Readiness Review)Examines the status of the module and determines whether they are ready for integration

and the commencement of the AIT phase.

Unit Bring Up test procedure review

TRR (Test Readiness Review)EQM/FM bring up and functional test

EQM shock test procedure

FM post flight prep functional test

ARR (AIT Readiness Review)ARR has the purpose of checking that module was passed all AIT requirements,

e.g. passed the burn-in process and thermal cycle process before the integration process.

PSR (Pre Shipment Review)To review status and checking all equipment is ready to ship to Launch Vehicle

Ex. De-rating Electronic Devices Sheet

In electronics, de-rating is the operation of a device at less than its rated maximum capability in order to prolong its life.

Ex. EEE Parts Assessment Sheet

Electrical Electronic Electromechanical (EEE)

Ex. TVM of Payload Interface Board

Training Skill & Knowledge: OBDH Hardware

Training Skill & Knowledge: OBDH Hardware

This payload interface board was designed and

test by me with mentoring from SSTL mentor

under Know-How Transfer and Training task.

1 Transfer knowledge lecture notes for the introductory KHTT courses and general knowledge courses

2 OBDH Hardware architecture

Explain hardware design of CDHS schematics (AOCS Interface, Power, OBC, TMU ,RF,GPS, JTAG, Command Decoder).

3 OBDH Hardware architecture

Explain hardware design of DHU schematics/ Circuit analysis

4 Electronic Circuit design (Payload Interface Board)

• Circuit analysis

• De-rating PIB circuit

• Inrush current analysis

• Power consumption analysis

5 CADStar program to design electronics circuit.

6 Pspice program for electronic circuit analysis and simulation

7 Vivado program for digital circuit design in System on Chip FPGA

8 Comprehensive VHDL Course & Practice

9 Digital Chip hardware design (FPGA/VHDL)

Write VHDL code to generate ADS-B message for DHU testing

Training OBC architecture design

10 CDHS/DHU (Bring up & Functional test, Thermal test, AIT integration test)

11 Payload Interface Board (Bring up & Functional test, Thermal test, AIT integration test)

Training & Knowledge Transfer Plan

On-Board Data Handling (OBDH) Hardware Introduction

Documents

Transcript of On-Board Data Handling (OBDH) Hardware Introduction