HSO Forum Ops-Sat presentation

OPS-Sat | D. Evans, M. Merri | HSO/ESOC | 23 March 2012 |

OPS-SAT – Evolving Software Technology for Spacecraft Operations

David Evans, HSO-OSA

Mario Merri, HSO-GD HSO exchange

23 March 2012


A quiz


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 issued


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 them

We still interface with our satellites using the Packet Utilisation Standard


Because its difficult to sell innovation to project managers and operators Time after time we settle for reuse and therefore remain static Why? Is it because operators are not innovative? No, you can see that when a mission has a problem and we have many new ideas in the spacecraft control domain (patents, innovative applications, new standards, concepts) – they just never fly With mission critical software there are always strong barriers to flying something new

Risk aversion Hard to completely ground test - simulation is not real life Few flight opportunities and long development times Comfort zones

We wanted to break these barriers down but how?

Why has this happened?


In 2011 the ESOC future studies section dreamed up a concept we christened…… OPS-SAT A satellite specifically designed to allow constant experimentation with critical on-board and ground software using modern space to ground interfaces A satellite that’s mission would be to demonstrate innovation that is asked for by operators rather than imposed on operators. Only this would accelerate adoption (and sales for the innovators) A satellite that would be

Representative Cheap Quick to launch

OPS-SAT is born


The solution

2008: started collaborating with SwissCubeSat (EPFL) 2010: considered embarking IOD experiments on SwissCubeSat2 2011: contacted by CNES about hardware experiments they wanted to fly on a cubesat. Potential synergies and could be representative now! 2011: GSP agreed to fund a CDF to test concept feasibility - out of cycle

Cheap

Quick to develop

Robust

Can carry powerful processors

Representative


We were not the first with the idea..


The Concurrent Design Facility (CDF)

OPS-SAT CDF Jan-Feb 2012 1st ESOC customer 1st Software position 1st Cubesat design


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 unit


The ESOC experiments

The first thing we did was collect the IOD experiment ideas from within ESOC ….over to Mario


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 …!


Hardware Experiments

Deployment of Drag Enhancement Device • PI: R. Jehn (HSO-GF) • Downgraded during CDF to free flier monitor

Miniature X-Band Transmitter

• PI: CNES


CCSDS Mission Operations (MO) Services Experiment


Network

Domain Specific Services

SM&C MO Framework

Communication Technology

Introduction: What is CCSDS MO about?

Ground Segment

MCS

Messaging Middleware

MO Applications

Space Data Link Protocols

Space Network Protocols

(e.g. Space Packet)

Message Abstraction Layer

Ground Segment

MCS

MO Applications


Messaging Middleware

Space Segment

TM/TC Device

OBC

Space Data Link Protocols

Spacecraft Transfer Layer

Subnetwork Packet Service

Subnetwork Packet Service

CCSDS Packet Router

Subnetwork Memory Access

Service

Subnetwork Synchronisation

Service

Subnetwork Device Discovery

Service

Subnetwork Test

Service

Space Network Protocols

(e.g. Space Packet)


MO Applications

Onboard Subnetwork

MO Messages

SOIS

Message Transfer Service

File and Packet Store

Services

Command and Data

Acquisition Services

Time Access Service

Device Enumeration

Service

CCSDS Packets

Space Link

Essentially proprietary architecture

using basic ECSS datalink standards


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 Services


Scenario A: PUS/MO Equivalence

Scenario A1) Simple isolated MO application • A simple MO-based on-board application is deployed

in isolation from the main OBSW • Very trivial “2+2=4” application for testing communications • MO based OBSW is extremely simplified to a single

application as Proof of Concept

Scenario A2) Hybrid MO/PUS system • One aspect of the existing OBSW is mirrored with

an MO equivalent • Seen from the ground the MO application behaves

the same as the PUS equivalent • On-Board GPS application would be a good candidate

Scenario A3) Full TM/TC Switch between PUS and MO

• Ground user can switch fully between PUS based or MO based TM/TC

All scenarios also demonstrate integration of MO concept with S2k ground infrastructure

TM/TCTM/TC SSMMSSMM OtherDevices

OtherDevices

Primary OBCPrimary OBC

OBC Hardware

OS

Onboard software

Thermal

Power

Mode mgmt

FDIR

AOCS

MTL Services

OBT Mgmt

Context mgmt

SSMM mgmt

TMTC

MO Software

MO Application

Onboard Communications H/W(e.g. MIL-STD-1553B, SpaceWire, CAN RS422)


Java VM


OtherDevices


OBC Hardware

OS

MO Software

MO Based OBSW



Java VM

AOCS

Onboard software

Thermal

Power

Mode mgmt

FDIR

AOCS

MTL Services

OBT Mgmt

Context mgmt

SSMM mgmt

TMTC

TMTCMTLOBT

ContextSSMM

ThermalPower

Mode mgmtFDIR


OtherDevices


OBC Hardware

RTOS

System services Applications

Thermal

Power

Mode mgmt

FDIR

AOCS

MTL Services

OBT Mgmt

Context mgmt

SSMM mgmt

TMTC PUS GPS MO GPS




Example of PUS and MO Equivalence

PUS TC(14,5) Enable Forwarding HK Packets

PUS TC(3,6) Disable HK Par. Report Generation

PUS TC(3,5) Enable HK Par. Report Generation

PUS TM(3,25) HK Parameter Report

PUS TC(14,6) Disable Forwarding HK Packets

MO Core::Aggregation::monitor::subscribe

MO Core::Aggregation::disableGeneration

MO Core::Aggregation::enableGeneration

MO Core::Aggregation::monitor::publish

MO Core::Aggregation::monitor::unsubscribe

PUS Sequence MO Sequence

… in addition MO expand the PUS service catalogue


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

The MO Application Platform shall provide the capabilities for

• Multiple, concurrent App execution • MO-based Inter-app communication

Also IoD for on-board Java


OtherDevices


OBC Hardware

OS

MO Software

MO Framework



Java VM

Onboard software

Thermal

Power

Mode mgmt

FDIR

AOCS

MTL Services

OBT Mgmt

Context mgmt

SSMM mgmt

TMTC

Apps


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 •Memory •Storage •Downlink Bandwidth

No hard requirement (as much as possible)

Communication No specific Requirement

Requirements on the Spacecraft


File-Based Operations Experiment


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 missions


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 little


Spacecraft Control Scenario CFDP

SLE

Terrestrial Bearer

SLE

Terrestrial Bearer TM/TC

TM/TC

SLE Protocols CCSDS Space Link Protocols

Control Centre Ground Station Spacecraft

PUS/MO CFDP PUS/

MO

CFDP in open or closed loop

PUS/MO

Spacecraft Control Scenario


Mission Data Delivery to End Users Scenario

File / Packet Transfer Service

File Delivery Protocol

Terrestrial Bearer

File Delivery Protocol

Terrestrial Bearer

don’t care

File don’t carePayload Data

Centre Control Centre PayloadSpace Asset

don’t careon-board

file / packet delivery

mission product generation

File / Packets

File

on-board file / packet handling

on-board file / packet delivery

Spacecraft Asset Control via Data Relay Scenario


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 more



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)


Autonomy Operations and Opportunistic Science Experiment


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 software


General Mission Scenario

Data taken by spacecraft

Event detection

On-board autonomous diagnosis On-board autonomous planning

No Event

Event detected

Re-plan to: 1. Add downlink activity

to inform ground

2. Add new scientific data taking activity in the relevant region


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 image


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 opportunity


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 systems



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 algorithms


Housekeeping Telemetry Compression Experiment


Housekeeping Telemetry is Hard to Compress

Packet Store

RICE (present CCSDS standard for on-board compression) expands them

Because it is a mix of different parameters and data types


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 FLY


Better, faster and simpler than Zip

0

10

20

30

40

50

60

70

80

90

100

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!

% left

ZIP

533

POCKET

……..and POCKET works in real-time which zip cannot


… based on the requirements from the experiments the CDF kicked off in Jan 2012 …


A great experience

http://www.esa.int/esaMI/CDF/SEM0N72YRYG_0.html http://www.esa.int/esaMI/CDF/SEM9CD7YBZG_0.html

Position Team membersStudy Manager David Evans

Study Payload Manager Jens RomstedtTeam Leader Robin Biesbroek

Systems Marco Garcia MatatorosSystem Support Benoit DeperMission Analysis Rüdiger Jehn

Configuration/Structures Sandra MangunsongThermal Giovanni Chirulli

Thermal (Support) Matteo GiacomazzoGNC/AOCS Shufan Wu

Power Hadrien CarbonnierProgrammatics Jesus CrespoData Handling Gianluca FuranoData Handling Alberto Valverde

Software Mark DeanSoftware Mauro Caleno

Components Simon Vanden BusscheCommunications Paolo Concari

Ground Segment and Operations David PattersonCost Elisabetta LambogliaRisk Charles Lahorgue

Technical author Andy Pickering

Position ConsultantsMechanisms Michael Yorck

Contributions provided by non-CDF members:Mass budget & comms MC analysis Guido Ridolfi

X-band transponder Eric Paragin

MO servicesSam Cooper, Mario Merri,

Mehran Sarkarati

http://www.esa.int/esaMI/CDF/SEM0N72YRYG_0.html

http://www.esa.int/esaMI/CDF/SEM9CD7YBZG_0.html

http://www.esa.int/esaMI/CDF/SEM9CD7YBZG_0.html


OPS-SAT overall design

X band TX (up to 50 Mbps down)

S band TX (1 Mbps down 256 kbps up)

Classic ESA TC/TM decoder/encoder

FPGA router

Up to 9.6 kbps Up to 4.8 kbps up

3 axis control 2 RWs Magnetotorquers Magnetometers GPS

Gumstix Overo Earth Processor boards 500 MHz, 500 Mbyte internal Flash Native LINUX


OPS-SAT CDF design


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 cameras


OPS-SAT CDF design


CDF engineers provide new ideas

Final 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?


Building industrial support

CDF 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 software

The response has been overwhelmingly positive Software 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”)


Building industrial support

This 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 innovators


Building Cross Agency Support

Classic Cubesat (Cubesat community)

Software based experiments (ESOC, DLR, CNES)

Miniaturised S band technology (DLR)

Miniaturised X band technology (CNES)


GSTP workshop on IOD 19/20 March

Juan Miro/Manfred Warhaut organized that a small group from ESOC could attend the recent GSTP workshop on IOD to promote OPS-SAT 100 representatives from industry, national agencies and ESA delegates 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

presentations TEC exceptionally allowed us to make an OPS-SAT presentation at the workshop Workshop report will be sent to the Director’s committee on Technology and as information to the IPC


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 welcome


Help us make OPS-SAT a flying success!

Thank you

HSO Forum Ops-Sat presentation

Technology

Transcript of HSO Forum Ops-Sat presentation