Satellite Systems and Design By Peter Davidsen Systems Engineer, TERMA “Architecture of On-Board...

Satellite Systems and DesignArchitecture of On-Board Systems

Presentation Structure- Who am I?- On-Board Systems, Tasks and Architecture

- Focus on On-Board Computer- Interfaces- Timing Concept- Redundancy Philosophy- Hardware Design Flow- Ørsted Case- Rømer Case- CubeSat Case

Architecture of On-Board SystemsWho am I?

Name: Peter Davidsen

Age: 32

Education: Civilingeniør E, 1993, DTU

Experience: 8 years in the Space Industry- Ørsted subsystem designer (CPD)- Ørsted systems engineer

- Test and validation- Launch and Operation

- Rømer lead systems engineer (Platform)- Terma Star Tracker lead systems engineer

Contact, and don’t hesitate to do so!!!!

[email protected]

Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture

Satellite on-board systems

- Functions indicated

- How shall these functions be implemented?

- How shall they be linked together? (Interfaces)

- What kind of tasks are assigned to each function? P a ylo a d(s )

O B C

S tru ctu re

A C S

A ctu a to rs

S e n s o rs

E P SP C D U

B a tte ry

S o l a rP a n e l (s )

C O M

A n te n n a

H a rn e s s

Th e rm a lC o n tro l

S e pa ra .M ES


Electrical Power Subsystem (EPS)- Power Control and Distribution Unit (PCDU)- Solar panel(s)- Battery (peak power, orbit eclipse)

PCDU- Solar panel(s) and battery management (BCR or MPPT)- Centralized or de-centralized DC/DC converters- User switches and protection- Housekeeping and protection- Control and OBC interface- AUX converter (internal power supply)


On-Board Computer- Command and Data Handling (CDH)

- Receive, process and distribute telecommands from ground- Collect science data- Collect housekeeping and report telemetry- Telemetry storage in mass memory- Forward telemetry to ground- Satellite autonomous control and monitoring (e.g. safe mode, time

tagged commands...)- Timing reference and correlation

- Autonomous attitude control- etc. e.g. Star tracker data processing, Payload data processing…..


OBC Core and Memory- Core

- Central processor- System clock- Watchdog- Memory and interrupt control- DMA, if needed

- Memory- Boot memory- Non-volatile memory- System and mass memory- EDAC

- Single event upset mitigation (Hamming coding)

- Power interface

Central P roc es s orCloc k, W atc hdogM em ory c ontro l

Boot s trap M em oryP RO M

N on-Volatile M em ory(P rogram M em ory)

S ys tem M em ory M as s M em ory

T em peratureS ens ors

ED A CED A C

P o w e r

P o w e r

T BC

A d d re s s /D a ta a n d C trl B u s

P ow erInterfac e


OBC Peripheral Units

- Interface unit 1..n

- Debug interface

- Master time-base and timer functions

- Housekeeping circuit (V, I, T)

- Discrete signal handling (I/O)

- TCP and external events

- Latch-up protection (not shown)

In terfac e 1

Interfac e 2Hous ekeeping(Analog T M

T em perature T M )

M as ter T im ebas e,T im er func tions

T CPExternal Event

D ebugInterfac e

A d d re s s /D a ta a n d C trl B u s

In terfac e n


O B C

M e m o ryEle ctrica l

I n te rfa ce sH o u s e -

k e e pin gPo we r

I n te rfa ceC o reM e ch . /

Th e rm a l

Pro ce s s o r

Pe rfo rm a n ce

W a tch do g

S y s te m C lo ck

M a s te r Tim e ba s e

B o o ts tra p

No n -V o la t ile

S y s te m M e m o ry

ED A C

D e bu g

I n te rfa ce 1

TC P

I n te rfa ce 2

. . . . . . . .

Ex te rn a l Ev e n t

V o lta g e

C u rre n t

Te m pe ra tu re

Filt e r & D is t r ib.

Po we rco n s u m pt io n

G ro u n din g

D im e n s io n s

M a s s

C O G /M O I

Th e rm a l I /F

I n te rru pt co n tro l C o n n e cto rs

M o u n t in gFra m e

M e m o ry co n tro l

I de n t if ica t io n

I n te rfa ce n


OBC Key Problem Areas

Processor selection

- Performance (MIPS and FLOPS)

- Power consumption

- Space environment

- Tools

Memory

- Technology (e.g. EEPROM/FLASH, SRAM/DRAM…)

- Power consumption

- Size (bytes)

- Space environment

- Protection

Interface implementation

- UART or FPGA

- FPGA selection (for space)

- Timing and peak load

- Protocol selection (high and low level)

- Test

Exercise: identify possible processors for the use in CubeSat OBC


OBC for CubeSat?

- Consider using a PIC controller

- PC104 ‘standard’, www.pc104.com

- Consider ‘reverse engineering’

- Look for LOW POWER and extended temperature range.

- or simply GET INSPIRED!

Problem area:

Not qualified for Space, but might be used by others?


Attitude Control Subsystem (ACS)

-ACS SW part of OBC

-Sensors

- Star tracker

- Rate sensors

- Magnetometer

- Sun sensors

- Earth horizon sensors

- Determine sensor configuration

- Select I/F to OBC

- HW

- Low and high level protocols

-Actuators

- Momentum/Reaction wheels

- Magnetorquer coils/rods

- Permanent magnet

- Thruster

- Libration Damper

-Determine actuator configuration

- Select I/F to OBC

- HW

- Low and high level protocols


Communication subsystem (COM)

- Receiver (Rx)

- LNA

- Down converter, IF amplifier

- Demodulator

- Transmitter (Tx)

- Modulator

- Solid state power amplifier (SSPA)

- Duplex filter (one Rx/Tx antenna)

- Antenna (S-band, VHF, UHF)

- Controller

- OBC interface

- Rx/Tx mode control

- Up/down link protocol handling

- either in COM or OBC

- Coding and decoding

- Housekeeping

- Essential V, I, T and Rx/Tx status

-Power control and interface

Architecture of On-Board SystemsInterfaces

Interface Types

- Electrical (HW)- Functional (SW)- Mechanical- Thermal

all this MUST BE SPECIFIED FOR ALL SUBSYSTEMS

Architecture of On-Board SystemsData Interfaces

-Configuration

- Star

- Bus

-Type

- Serial

- Parallel

-Timing

- Asynchronous

- Synchronous

-Control

- Master-Slave (MS)

- Master-Master (MM)

Exercise: List advantages and drawbacks of the Bus and Star configurations

O B C

S U S n

S U S 3

S U S 2

S U S 1

O B C S U S 3S U S 2

S U S 1

S U S n

B U SSTA R


- Typical interfaces- RS422 (Star, serial, async/sync, MS/MM)- RS485 (Bus, serial, async, MS/MM)- PASTE (Star/Bus, parallel, sync, MS)- CAN (Bus, serial, async, MM)- Mil-Std-1553 (Bus, serial, async, MM)- …..

- Avoid using to many I/F configurations and types !!!!!

Exercise: CubeSat interface brainstorming


Interface Protocol

- High level

- Application layer

-Low level

- Data link layer

- Physical layer

Pa ck e t

D a ta Ta ilH e a de r

. . . . . . . . . . . . . . . . . . . . .

A pplica t io n L a y e rH ig h le v e l

D a ta L in k L a y e rL o w le v e l

Ph y s ica l L a y e rL o w le v e l


- High level, e.g. Packet Utilization Standard- Low level, e.g. CAN, radio link- Note, some I/F standards include only electrical properties (e.g. RS422

and RS485), other also low level protocol (e.g. CAN and 1553).

Protocol standards- Use a standard low level protocol on the up/down link

- Re-use ground station- Use standard or non-standard between OBC and SUS


Data Flow Analysis

- Inter Satellite (OBC to subsystems)- Ground/Satellite link- Ground data distribution

- Interface bandwidth requirements including up/down link- Interface peak loads- OBC mass storage (if implemented)

Architecture of On-Board SystemsInterface Control Document

I n te rfa ceC h e ck lis t

Ele ctrica l Fu n ct io n a l M e ch a n ica l Th e rm a l

Po we r

V o lta g e s u pply

Po we r co n s u m pt io n /pro f ile

I /F S ch e m a t ics

D a ta


Tim in g


G ro u n din g dia g ra m

C o n n e cto r ta ble

L o w le v e l pro to co l

Fra m e

B it /by te o rde r

D a ta ra te

Tim in g

H ig h le v e l pro to co l

TC /TM h e a de r (PUS )

TC /TM ta il (PUS )

Tim in g

Te le co m m a n d lis t

Te le m e try lis t

Fu n ct io n a l blo ck dia g ra m

TC e v e n ts

Ex pe cte d TM

Tra n s it io n lis t

D im e n s io n s

Ele ctro n ics

M e ch a n ics

M a s s

C O G /M O I

D ra win g s

A lig n m e n t

To le ra n ce s

M a te ria ls

S ta bility

M in /m a x te m pe ra tu re

A bs o rpta n ce /Em it ta n ce( / )

Ty pe ( co n du ct iv e /e m it te d)

Architecture of On-Board SystemsTiming Concept

-Relative time correlation

- OBC to subsystem

-Absolute time correlation

- OBC to GPS

- OBC to Ground

-Both principles rely on local time stamping of the signal “pulse”, followed by interchange of timestamp.

O B C

C O M /G P S

S U S

I /F

I /F

Pu ls e

Pu ls e

Architecture of On-Board SystemsRedundancy Philosophy

Introduction to Redundancy- Redundancy is used to increase satellite/subsystem reliability- Redundancy can be applied on:

- system level- subsystem level (e.g. two OBCs, interface cross-coupling)- subsystem internal (e.g. double boot PROMs)

- Redundancy can be implemented as ‘hot or cold’- Typical problems when introducing redundancy

- increase in system complexity + mass, power and volume- will the reliability be increased at all?- test- cost

Architecture of On-Board SystemsRedundancy Philosophy

Redundancy Roadmap- Baseline minimum configuration that satisfies the mission

requirements- Evaluate reliability of each subsystem for a give lifetime and orbit- Evaluate complexity of making a subsystem redundant- Evaluate cost of making a subsystem redundant- Then decide

- Hot or Cold?- Interface cross strapping?

- Other constraints: mass, volume, power etc.

decide on redundancy concept

Exercise: CubeSat = Single String why?

Architecture of On-Board SystemsHardware Design Flow

High level tas ksidentif ic ation

e.g . C& D H, ACS . . .

CD H S P ECIF ICAT IO N :Core (perform anc e etc ) , M em ory ,

In terfac es , Hous ekeeping, D C/D C Converter etc .

S atellite O rbitLifetim e

Radiation analys isCom ponents s elec tion

Arc hitec tural D es ign

Engineer ingBread-Board M odel

Engineer ing M odel

F light M odel

P ow erM ec h. /T herm alEnvironm ental

Could es s entially beany S atellite s ubs ys tem

P roblem areanum ber one!

EM S atelliteT es ting

S atelliteIn tegration

S W c hanges

S WDevelo p ment

HW design, step-by-step

- Input

- High level tasks

- Radiation environment (given the orbit, lifetime and epoch)

- Max power, mass, envelope etc.

- External interface requirements

- Power and data

- Output

- Specification

- Component selection

- Architectural design

- Detailed design

Architecture of On-Board SystemsØrsted case

Architecture of On-Board SystemsRømer Case

Note:

- Single String Satellite

- Single Payload

- CDH Combines:

- Command and Data Handling

- ACS Computer

- Star Tracker Computer

- ‘Intelligent’ COM, EPS and Payload

- Common Data Bus (CAN)

- Easy Test Access

- ‘Simple Subsystems’ accessed through PDU

M O N SD P U

F MC H U

M O N SC H U

S T RC H U 2

DEB UG

C D H

C O M

ANT1

ANT2

R W A1

R a teS en s o r 1

T E S T

S T RC H U 1

S A 1

R W A0

R a teS en s o r 0

R W A3

R a teS en s o r 3

R W A2

R a teS en s o r 2

S A 2

B A T

M ES

S A S

M A G

TR Q

P C U

P D U

Red

un

dan

t D

ata

Bu

s

R Ø M E R O ve ra ll B lo c k D ia g ra m , is s ue 7

Architecture of On-Board SystemsCubeSat Case

CubeSat Block Diagram

- Gray boxes indicate ‘need to be’

- 2’nd priority

- Battery

- Payload sensor

- ACS actuator

- ACS sensor(s)

- No direct redundancy

- OBC tasks

- C&DH

- Up/Down link protocol handling

- ACS data processing

- PCDU high level control

- Payload data processing

O B C

CO M

P CD U

Par

alle

l B

us

S e r ia l S y n ch ro n o u s R S 4 2 2C lo ck a n d D a ta

D e bu g I /FR S 4 2 2 , R S 2 3 2J TA G

.......

R e g u la te d v o lta g e o u tpu ts

A C SS e n s o r( s )

A C SA ctu a to r

Pa y lo a dS e n s o r

S o la rPa n e l( s )

B a t te ry

A n a lo g o rD ig ita l I /F

A n a lo g I /F

Architecture of On-Board SystemsCubeSat Case

CubeSat, recommendation- Limit you ambitions!

1 Payload- Keep it simple!

- Is ACS necessary?-Keep constant track of engineering budgets (mass, power, volume)- Implement a simple satellite safe mode:

- Radio beacon- Non essential loads OFF- Make it possible to change OBSW

- Use simple COM (amateur radio)- UHF/VHF, COTS unit- Standard protocol

- Use a centralized DC/DC converter

- Include battery (peak power)

- Consider deployable solar panels

- Due to the tight engineering budgets COTs components/subsystems (e.g. PC104 as OBC)

- Pay attention to the thermal design

- Use simple interfaces AND simple protocols.

- Implement a direct access debug interface to the OBC used during ground tests

- Test, Test and Test

Satellite Systems and Design By Peter Davidsen Systems Engineer, TERMA “Architecture of On-Board...

Documents

Transcript of Satellite Systems and Design By Peter Davidsen Systems Engineer, TERMA “Architecture of On-Board...