HSO Forum Ops-Sat presentation

OPS-SAT – Evolving Software Technology for Spacecraft Operations David Evans, HSO-OSA Mario Merri, HSO-GD HSO exchange 23 March 2012OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 1

A quizOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 2

Let me take you back to 1994 A top of the range PC was a 486, 33 MHz with 250 MByte hard drive 1994 was also the year that the Packet Utilisation Standard was issuedOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 3

Now wind forward 18 years….It is now 2012 and we.. live in an world of smart phones and high speed wireless networks are surrounded by “always on, always connected” smart devices take for granted the ease with which we interface with themWe still interface with our satellites using the Packet Utilisation StandardOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 4

Why has this happened?Because its difficult to sell innovation to project managers and operatorsTime after time we settle for reuse and therefore remain staticWhy? Is it because operators are not innovative?No, you can see that when a mission has a problem and we have manynew ideas in the spacecraft control domain (patents, innovativeapplications, new standards, concepts) – they just never flyWith mission critical software there are always strong barriers to flyingsomething new  Risk aversion  Hard to completely ground test - simulation is not real life  Few flight opportunities and long development times  Comfort zonesWe wanted to break these barriers down but how?OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 5

OPS-SAT is bornIn 2011 the ESOC future studies section dreamed up a concept wechristened…… OPS-SATA satellite specifically designed to allow constant experimentation withcritical on-board and ground software using modern space to groundinterfacesA satellite that’s mission would be to demonstrate innovation that isasked for by operators rather than imposed on operators. Only thiswould accelerate adoption (and sales for the innovators)A satellite that would be  Representative  Cheap  Quick to launchOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 6

The solution  Cheap  Quick to develop  Robust  Can carry powerful processors  Representative2008: started collaborating with SwissCubeSat (EPFL)2010: considered embarking IOD experiments on SwissCubeSat22011: contacted by CNES about hardware experiments they wanted to flyon a cubesat. Potential synergies and could be representative now!2011: GSP agreed to fund a CDF to test concept feasibility - out of cycle OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 7

We were not the first with the idea..OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 8

The Concurrent Design Facility (CDF) OPS-SAT CDF Jan-Feb 2012 1st ESOC customer 1st Software position 1st Cubesat designOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 12

OPS-SAT CDF Core Requirements• Must allow easy and complete replacement of on-board software in flight - i.e. an open experimental platform• Software should be able to be updated quickly, easily and often – a complete reload of the entire software in less than 3 passes• Allow the use of standard terrestrial CPU, OS and Java – aim for the equivalent of mobile phone performances• It must be no bigger than a 3U cubesat (30x10x10 cm)• COTS units shall be used wherever possible (no new developments)• Cost to be kept below 2 MEuro• Time to launch between 1-2 years from kick off• Single string but minimize single point failures• Make the satellite safe by design (even without processor running)• Do not assume that any unit will work all the time• Always ensure the ground can power cycle any unitOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 13

The ESOC experiments The first thing we did was collect the IOD experiment ideas from within ESOC ….over to MarioOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 14

Software Experiments 1. CCSDS Mission Operations Services • PI: M. Merri (HSO-GD) 2. File-based Operations • PI: C. Haddow/M. Pecchioli (HSO-GI) 3. Autonomy Operations and Opportunistic Science • PI: A. Donati/N. Policella (HSO-OS) 4. Housekeeping Telemetry Compression • PI: D. Evans (HSO-OS) 5. Potentially many more SW experiments • PI: … maybe you • Limited by imagination …!OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 15

Hardware Experiments  Deployment of Drag Enhancement Device • PI: R. Jehn (HSO-GF) • Downgraded during CDF to free flier monitor  Miniature X-Band Transmitter • PI: CNESOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 16

CCSDS Mission Operations (MO) Services ExperimentOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 17

Introduction: What is CCSDS MO about? Ground Segment Space Segment Ground Segment MCS OBC MCS MO Applications Domain Specific Services MO Applications MO Applications Message Abstraction Layer SM&C MO FrameworkMessage Abstraction Layer Abstraction Layer Message MO Messages TM/TC Device Space Space Network Command Network Message File and Device Protocols and Data Time Access Protocols Transfer Packet Store Enumeration (e.g. Space Acquisition Service (e.g. Space Service Services Service Packet) CCSDS Packet Router Services Packet) Messaging Messaging Middleware Communication Technology CCSDS Packets Essentially proprietary architecture Middleware SOIS using basic ECSS datalink standards Spacecraft Transfer Layer Subnetwork Subnetwork Subnetwork Subnetwork Subnetwork Subnetwork Space Data Link Space Data Link Packet Packet Memory Access Synchronisation Device Discovery Test Protocols Protocols Service Service Service Service Service Service Network Space Link Onboard SubnetworkOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 18

Objectives  Demonstrate equivalence of the MO services with PUS • Study implications of MO on the Space-to-Ground link • Demonstrate control of on-board application using either MO or PUS services on the ground  Demonstrate selected precursor MO services • Monitor & Control Service • Navigation Service • Software Management Service • Remote Buffer Management • Data Product Management • Time Management Service  Demonstrate the SOA Service Plug-In concept • Provide an On-Board MO “Framework” • Universities can develop and upload their own Apps using MO ServicesOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 19

Scenario A: PUS/MO Equivalence Primary OBC Primary OBC Scenario A1) Simple isolated MO application TMTC Onboard software AOCS MO Software • A simple MO-based on-board application is deployed MTL Services Thermal MO Application OBT Mgmt Power in isolation from the main OBSW Context mgmt SSMM mgmt Mode mgmt FDIR Java VM • Very trivial “2+2=4” application for testing communications OS • MO based OBSW is extremely simplified to a single TM/TC TM/TC SSMM SSMM Other Other Devices Devices OBC Hardware application as Proof of Concept Onboard Communications H/W Onboard Communications H/W (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) Scenario A2) Hybrid MO/PUS system System services Primary OBC Primary OBC Applications TMTC AOCS PUS GPS MO GPS • One aspect of the existing OBSW is mirrored with MTL Services Thermal an MO equivalent OBT Mgmt Power Context mgmt Mode mgmt SSMM mgmt FDIR • Seen from the ground the MO application behaves the same as the PUS equivalent Other RTOS TM/TC SSMM Other TM/TC SSMM Devices • On-Board GPS application would be a good candidate OBC Hardware Devices Onboard Communications H/W Onboard Communications H/W (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) Scenario A3) Full TM/TC Switch Primary OBC Primary OBC between PUS and MO Onboard software MO Software TMTC AOCS MO Based OBSW TMTC AOCS MTL Services Thermal MTL Thermal • Ground user can switch fully between PUS based OBT Power OBT Mgmt Power Context Mode mgmt SSMM FDIR Context mgmt Mode mgmt SSMM mgmt FDIR Java VM or MO based TM/TC OS All scenarios also demonstrate integration TM/TC TM/TC SSMM SSMM Other Other Devices Devices OBC Hardware of MO concept with S2k ground infrastructure Onboard Communications H/W Onboard Communications H/W (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) (e.g. MIL-STD-1553B, SpaceWire, CAN RS422)OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 20

Example of PUS and MO Equivalence PUS Sequence MO Sequence PUS TC(14,5) Enable Forwarding HK Packets MO Core::Aggregation::monitor::subscribe PUS TC(3,5) Enable HK Par. Report Generation MO Core::Aggregation::enableGeneration PUS TM(3,25) HK Parameter Report MO Core::Aggregation::monitor::publish PUS TC(3,6) Disable HK Par. Report Generation MO Core::Aggregation::disableGeneration PUS TC(14,6) Disable Forwarding HK Packets MO Core::Aggregation::monitor::unsubscribe … in addition MO expand the PUS service catalogueOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 21

Scenario B: On-Board MO App-Store  Provide an on-board MO Application Platform (Platform as a Service, PaaS in the Space)  3rd parties can deploy and execute on-board MO-based ‘Apps’  Access to devices and on-board parameters provided as MO Services • On-board storage (both TM packets and files) • Access to real devices like GPS receivers, cameras, thermal sensors • Access to on-board parameters such as satellite attitude, calibrated parameters Primary OBC Primary OBC Onboard software MO Software TMTC AOCS MO Framework  The MO Application Platform shall provide MTL Services Thermal Apps the capabilities for OBT Mgmt Power Context mgmt Mode mgmt • Multiple, concurrent App execution SSMM mgmt FDIR Java VM OS • MO-based Inter-app communication Other TM/TC SSMM Other TM/TC SSMM Devices Devices OBC Hardware  Also IoD for on-board Java Onboard Communications H/W Onboard Communications H/W (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) (e.g. MIL-STD-1553B, SpaceWire, CAN RS422)OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 22

Requirements on the Spacecraft Requirement Comment Scenario A1 A2 & 3 B Support for Java Support required in execution context    On-board GPS receiver To make the experiments more interesting to Universities  On-board camera To make the experiments more interesting to Universities  Access to TM/TC channels    Read only access to parameter pool   Read only access to attitude determination information This could be via the Parameter pool   Read only access to sensor information This could be via the Parameter pool   Other onboard characteristics No hard requirement (as much as possible) •Memory •Storage •Downlink Bandwidth Communication No specific RequirementOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 23

File-Based Operations ExperimentOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 24

Background  All ESA missions are currently based on the Packet Utilisation Standard  The use of packets has significant limitations in some operational scenarios  Several ESA scientific missions have already adopted partial solutions enabling the use of files as a complementary space/ground data unit  An ESOC Working Group has been tasked to identify an operational concept about the use of files for spacecraft operations of ESA missionsOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 25

File Based vs. File Transfer  File based operations is not only file transfer. We need… • Data Transport - The low level communication protocols • Files Transfer - File Delivery Protocol and associated management • Files Management (on ground and in space) - Basically a File System • Files Utilisation (on ground and in space) - This is the only layer which deals with the file content  A full solution covering all areas is needed! • E.g. transferring files from/to a system that doesn’t support and use files brings very littleOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 26

Spacecraft Control Scenario PUS/MO CFDP in open or closed loop PUS/ MO Spacecraft Control Scenario CFDP CFDP PUS/ MO SLE SLE TM/TC Terrestrial Bearer Terrestrial Bearer TM/TC SLE Protocols CCSDS Space Link Protocols Control Centre Ground Station SpacecraftOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 27

Spacecraft Asset Control via Data Relay Scenario File Mission Data Delivery to File / Packet Transfer Service File Delivery File Delivery mission product on-board file / packet handling End Users Scenario Protocol Protocol generation don’t care on-board on-board file / Terrestrial Bearer Terrestrial Bearer don’t care file / packet packet delivery delivery File File / Packets don’t care Payload Data Control Centre Space Asset Payload CentreOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 28

Several Other Possible Demonstration Scenarios …  For instance, direct delivery of files from Ground Station to PI  … but also for ground technologies, e.g. • Use of Multi-Domain S2k for the MCS - Domain 1 PUS TM/TC processor - Domain 2 MO TM/TC processor • Automation of recovery from some contingency cases • … and moreOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 29

Requirements on the Spacecraft  Something that can produce files on-board, e.g. camera  An on-board file management system  PUS/MO (as parallel stream to files)  OBSW that implements the new protocols related to files (e.g. CFDP and File Services)  CCSDS SOIS (it would already provide several of the File Services)OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 30

Autonomy Operations and Opportunistic Science ExperimentOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 31

Overview  Main objective: To validate enabling algorithms and technologies in the areas of • autonomous planning • autonomous diagnosis • autonomous decision making processes  Rationale: Autonomy operations will enable a new repartition of processes and functions between ground and space • on-ground routine operations workload will be reduced and refocused on supervisory role • operator intervention will be required only for non-nominal situations  Three different scenarios • Autonomous planning and opportunistic science • On-board autonomous spacecraft health monitoring • Interactive improvement of on-board softwareOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 32

General Mission Scenario On-board autonomous diagnosis On-board autonomous planning No Event Data taken by Event detection spacecraft Event detected Re-plan to: 1. Add downlink activity to inform ground 2. Add new scientific data taking activity in the relevant regionOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 33

Scenario A: autonomous planning and opportunistic science  Continuous image acquisition of soil • Conditional (e.g. GPS based) image acquisition (high and low resolution) • On-board processing and analysis of low-res image • Decision making for down-selection • Autonomous re-planning for hi-res image dumping and site revisiting  Opportunistic science in a target area • Conditional (GPS based) image acquisition limited to the target area (high and low resolution) • On-board processing and analysis of low-res image • Autonomous re-planning for hi-res imageOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 34

Scenario B: on-board autonomous spacecraft health monitoring  Autonomous analysis of house-keeping data and selective downlink of the following products: • In nominal conditions, the on-board system downlinks only summary HK TM • In the case of contingency or not-nominal situations, the on-board system detects the anomaly, records the relevant detailed HK TM and re-plans such that this could be downlinked at the next opportunityOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 35

Scenario C: interactive improvement of on-board software  During the execution of the mission, the on-board models & algorithms will be continuously improved based on the analysis of the mission products (both science and HK telemetry)  The expected benefits are • Optimise the image analysis and selection • Increase the capability of performing opportunistic science • Optimise the use of the downlink bandwidth • Understand and improve the role of the ground operator while using autonomous systemsOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 36

Requirements on the Spacecraft  Payload: • Camera with programmable resolution • GPS receiver  On-board SW • Planner: 10-50 MIPS, RAM 32 MB • Diagnosis: 10 MIPS, RAM 8MB • RTEMS (?), LINUX (?)  At least 1GB for data storage  Access to science and HK TM  Ability to upload onboard procedure, software and algorithmsOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 37

Housekeeping Telemetry Compression ExperimentOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 38

Housekeeping Telemetry is Hard to Compress Because it is a mix of different parameters and data types Packet StoreRICE (present CCSDS standard for on-board compression) expands themOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 39

Patents pending  The future studies section has two patents pending on HKTM compression waiting to be flown • Transposed Packet Store Reader (Patent 553) • POCKET and POCKET compression  Patent 553 is a method for reading packet stores in a particular way that allows compression of the resulting data stream i.e. STORED data  POCKET is a method that can compress housekeeping type spacecraft data units (frames or packets) individually as they are generated into smaller packets i.e. ON THE FLYOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 40

Better, faster and simpler than Zip ……..and POCKET works in real-time which zip cannot 100 90 80 ZIP 70 60 533 % 50 left 40 POCKET 30 20 10 0 Rosetta PROBA-1 Venus Express Herschel Goce Both Patent 533 and POCKET perform well enough to change the design paradigm but we need to demonstrate this in flight!OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 41

… based on the requirements from the experiments the CDF kicked off in Jan 2012 …OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 42

A great experience Position Team members Study Manager David Evans Study Payload Manager Jens Romstedt Team Leader Robin Biesbroek Systems Marco Garcia Matatoros System Support Benoit Deper Mission Analysis Rüdiger Jehn Configuration/Structures Sandra Mangunsong Thermal Giovanni Chirulli Thermal (Support) Matteo Giacomazzo GNC/AOCS Shufan Wu Power Hadrien Carbonnier Programmatics Jesus Crespo Data Handling Gianluca Furano Data Handling Alberto Valverde Software Mark Dean Software Mauro Caleno Components Simon Vanden Bussche Communications Paolo Concari Ground Segment and Operations David Patterson Cost Elisabetta Lamboglia Risk Charles Lahorgue Technical author Andy Pickering Position Consultants Mechanisms Michael Yorck Contributions provided by non-CDF members: Mass budget & comms MC analysis Guido Ridolfi http://www.esa.int/esaMI/CDF/SEM0N72YRYG_0.html X-band transponder Eric Paragin http://www.esa.int/esaMI/CDF/SEM9CD7YBZG_0.htmlOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 43 Sam Cooper, Mario Merri, MO services Mehran Sarkarati

OPS-SAT overall design Up to 9.6 kbps Classic ESA Up to 4.8 kbps up S band TX (1 Mbps downTC/TM 256 kbps up) decoder/encoder FPGA router X band TX (up to 50 Mbps down) 3 axis control 2 RWs Magnetotorquers Gumstix Overo Earth Processor boards Magnetometers 500 MHz, 500 Mbyte internal Flash GPS Native LINUXOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 44

OPS-SAT CDF designOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 45

OPS-SAT CDF design Deployable Solar Arrays Arrays on each surface except Nadir and anti-Nadir Omni-directional S band coverage Omni-directional UHF coverage 6 sun sensors 4 camerasOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 46

CDF engineers provide new ideasFinal slide from CDF software engineer in final presentation… • OBC Software easily expanded during mission – Can be handled exactly like experimental software –New task / service uploaded to SD Card and executed – Mix and match experimental / OBC software – Event logs stored to file system, compressed, CFTP to ground… • Flexible architecture with endless possibilities – Compression – Encryption – Multiple operating systems – Artificial Intelligence / Spacecraft autonomy – Time and space partitioning – TCP/IP, telnet, shell etc. etc. – Plug and Play payload interfaces over WiFi / Bluetooth….  After CDF many ESTEC engineers have continued to support us  An ESA Cubesat club between ESOC & ESTEC?OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 49

Building industrial supportCDF team leader and myself have contacted industry in the UK,Holland, Spain, France and Germany about the project  Cubesat Integrators  Providers of advanced cubesat technology  Software firms providing ground and on-board softwareThe response has been overwhelmingly positiveSoftware companies saw many other possibilities for experiments.  Safe mode recoveries tested by actually triggering safe mode  FDIR tested by actually triggering the FDIR  Trying to use modified cameras as star trackers/mappers  Advanced planning, scheduling and on-board decision making  Exotic GN&C strategies (“lost in space”)OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 50

Building industrial supportThis close contact with industry has also paid off in other ways Discovered new equipment that will help us improve the design Many new ideas on uses for such a platform Better understanding of some of the technologies that cubesat developers themselves would like to see fly in their rapid approach to providing operational missions Built a good relationship with some of these exciting new companies Improved ESOC’s (and ESA’s) image as innovatorsOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 51

Building Cross Agency Support Classic Cubesat (Cubesat community) Software based experiments (ESOC, DLR, CNES) Miniaturised S band technology (DLR) Miniaturised X band technology (CNES)OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 52

GSTP workshop on IOD 19/20 MarchJuan Miro/Manfred Warhaut organized that a small group from ESOCcould attend the recent GSTP workshop on IOD to promote OPS-SAT100 representatives from industry, national agencies and ESAdelegates Common theme was the need for smaller, cheaper missions for IOD Using cubesats for IOD was often proposed OPS-SAT was mentioned several times explicitly in industry presentationsTEC exceptionally allowed us to make an OPS-SAT presentation atthe workshopWorkshop report will be sent to the Director’s committee onTechnology and as information to the IPC OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 53

OPS-SAT Future Steps  OPS-SAT is something different for ESOC • New operational concepts • New operational software technologies • New standards • New software development methodologies  OPS-SAT is an excellent platform for cooperation between ESA and National Space Agencies, in particular CNES and DLR • All have heavily invested in the development of the new standards • Genuine technical cooperation with no competition  CDF feasibility and preliminary architecture completed. Now we need to keep the momentum and move forward rapidly. Possible funding options: • Industrial study to Phase B1 with internal funding • GSTP • Special funds for cooperation with National Agencies • Special funds for new member states • Any other suggestion is welcomeOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 54

Help us make OPS-SAT a flying success! Thank youOPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 | Page 55

HSO Forum Ops-Sat presentation

by ESA/ESOC - Darmstadt, Germany on Apr 18, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

HSO Forum Ops-Sat presentation Presentation Transcript