sys - architecture of onboard systems.ppt

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 DavidsenAge: 32Education: Civilingeniør E, 1993, DTUExperience: 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 [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 t ru ct u 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 an d C trl B u s

P ow erInter fac 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

In terfac e 2Hous ekeep ing(Analog T M

T em perature T M )

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

T CPExternal Event

D ebugIn ter fac e

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

Inter fac e n


O B C

M e m o ry Ele ctr ica lI n te rfa ce s

H o u s e -k e e pin g

Po we rI n te rfa ceC o re

M 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 t e r Tim e ba s e

B o o t s t ra p

No n -V o la t i le

S y s t e m M e m o ry

ED A C

D e bu g

I n t e rfa ce 1

TC P

I n t e rfa ce 2

. . . . . . . .

Ex t e rn a l Ev e n t

V o lt a g e

C u rre n t

Te m pe ra t u re

Filte 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 t e rru pt co n t ro l C o n n e ct o rs

M o u n t in gFra m e

M e m o ry co n t ro l

I de n t if ica t io n

I n te rfa ce n


OBC Key Problem AreasProcessor 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 SS TA 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

Pack e t

D a t a 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 ctr ica l Fu n ct io n a l M e ch a n ica l Th e rm a l

Po we rV o lta g e s u pply

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

I /F S ch e m a t ics

D a taI /F S ch e m a t ics

Tim in gI /F S ch e m a tics

Gro u n din g dia gra m

C o n n e ct o r ta ble

L o w le v e l pro to co lFra m e

B it /by te o rde r

D a ta rat eTim in g

H ig h le v e l pro t oco lTC /TM h e ade r (PUS )

TC /TM t a il ( PUS )

Tim in g

Te le co m m a n d l is t

Te le m e t ry lis t

Fu n ct io n a l blo ck dia g ra mTC e v e n t s

Ex pe ct e d TM

Tra n s i t io n lis t

D im e n s io n sEle 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 r ia ls

S ta bility

M in /m ax 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 SI /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 ksiden tif 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 ter fac es , Hous ekeep ing , D C/D C Conver ter etc .

S atellite O rbitLifetim e

Radiation analys isCom ponents s elec tion

Arc hitec tural D es ign

EngineeringBread-Board M odel

Engineer ing M odel

F ligh t M odel

P ow erM ec h. /T herm alEnvironm en tal

Cou ld es s entially beany S atellite s ubs ys tem

P rob lem areanum ber one!

EM S atelliteT es ting

S atelliteIn teg ration

S W c hanges

S WDevelop 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 MANT1

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

unda

nt D

ata

Bus

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

Para

llel B

us

S e r ia l S y n ch ro n ou 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 lt ag e o u t pu ts

A C SS e n s o r( s )

A C SA ctu a to r

Pa y lo adS e n s o r

S o la rPa n e l( s )

B a t te ry

A n a log 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

sys - architecture of onboard systems.ppt

Documents