View
227
Download
0
Category
Preview:
Citation preview
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 so!!!!pd@terma.com
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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)
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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…..
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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?
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsOn-Board Systems, Tasks and Architecture
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
Architecture of On-Board SystemsData Interfaces
- 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
Architecture of On-Board SystemsData Interfaces
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
Architecture of On-Board SystemsData Interfaces
- 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
Architecture of On-Board SystemsData Interfaces
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
Recommended