On-Board Control Procedures: Autonomous and Updateable Spacecraft Operator Onboard and Beyond

Similar documents
Network on Chip round table European Space Agency, ESTEC Noordwijk / The Netherlands 17 th and 18 th of September 2009

Advanced On-board Control Procedure

Ensuring Schedulability of Spacecraft Flight Software

System Approach for a SpaceWire Network Template reference : C-EN

Standardisation of PF/PL interfaces TAS point of view

A Software-based Environment for Development & Validation of Spacecraft On-board Software

EagleEye TSP Porting to HWIL Configuration (RTB)

New Tools for Spacecraft Simulator Development

MicroPython Virtual Machine for On Board Control Procedures

LEVERAGING SERIAL DIGITAL INTERFACES STANDARDIZATION: THE RASTA REFERENCE ARCHITECTURE FACILITY AT ESA

Operability and Modularity concepts of future RTUs/RIUs

ECSS E-70-41: Telemetry & Telecommand Packet Utilisation Mario Merri European Space Agency

Spacecraft Monitoring & Control Systems

STRAST. UPMSat-2 On-board computers. Grupo de Sistemas de Tiempo Real y Arquitectura de Servicios Telemáticos Universidad Politécnica de Madrid.

Proposed SOIS Plug-and-Play Architecture and Resulting Requirements on SpaceWire Mapping

SVF User Requirements Specification

Integrated Modular Avionics for Space

CGS User Group Meeting September, 19-20, Noordwijk

Onboard Data Handling. Gert Caspersen Terma A/S

A Reference Architecture for Payload Reusable Software (RAPRS)

European Ground Systems - Common Core (EGS-CC) ASI Italian Information Day

The SOIS Plug-and-Play Architecture and Its Proposed Mapping onto SpaceWire

COrDeT Cannes : Use of domain engineering process to develop reusable architectures and building-blocks

Advanced Concepts and Components for adaptive Avionics

Towards SpaceWire Plug-And-Play ECSS Standard

The Avionics System Test Bench, Functional Engineering Simulator: New Developments in Support of Mission and System Verification

The Main Concepts of the European Ground Systems Common Core (EGS-CC)

Advanced Validation Strategies for On-Board Satellite Software in the Galileo IOV Programme

On-Board Data Systems

More processing power - Driving requirements

EMC2. Prototyping and Benchmarking of PikeOS-based and XTRATUM-based systems on LEON4x4

The Gaia real-time simulator (RTS) and avionics SCOE

Dynamically Reconfigurable Processing Module for Future Space Applications

SpaceWire-RT Project and Baseline Concepts

NASA/GSFC s Flight Software Architecture: Core Flight Executive and Core Flight System

1 COMMAND AND DATA HANDLING (C&DH)

System Impact of Distributed Multicore Systems December 5th 2012

RTU presentation. Torbjörn Hult Chief Engineer, Digital Products RUAG SPACE ADCSS 2015, ESTEC

SpaceWire Backplane Application Requirements

SpaceWire Technologies deliver multi-gigabit data rates for on-board Spacecraft. SpaceTech Expo Gregor Cranston Business Development Manager

OBC Mass Memories Final Presentation

A Packet Utilisation Standard (PUS) Model

Mission Families: a cost effective approach to Mission Control System development

The SpaceWire RTC: Remote Terminal Controller

Real-Time Component Software. slide credits: H. Kopetz, P. Puschner

SAVOIR Industrial Consultation

Multi-DSP/Micro-Processor Architecture (MDPA)

Operating real equipments with fully simulated On Board Computer

SWIFU: SPACEWIRE INTERFACE UNIT FOR VERSATILE SENSOR

Modeling Of Spacewire Traffic. - ESA study Contract No /10/NL/LvH. Executive Summary & Final Report

ENHANCED DYNAMIC RECONFIGURABLE PROCESSING MODULE FOR FUTURE SPACE APPLICATIONS

ExoMars Rover Vehicle

EGSE-Lite A Light Weight EGSE/Simulation environment for LEON based Satellite Subsystem & Payload Equipment

Using an Artificial Intelligence Tool to Perform Science Data Downlink Planning as Part of the Mission Planning Activities of Mars Express

LISA Pathfinder Sheet : 1

CRITICAL DESIGN REVIEW

Fifth SpaceWire WG Meeting SpaceWire based On-Board-Computer

Development of Generic Ground Systems by the Use of a Standard Modeling Method. Takahiro Yamada JAXA/ISAS March 1, 2005

RPWI Software Design SWEDISH INSTITUTE OF SPACE PHYSICS. Reine Gill

SpaceWire-RT. SpaceWire-RT Status SpaceWire-RT IP Core ASIC Feasibility SpaceWire-RT Copper Line Transceivers

Rad-Hard Microcontroller For Space Applications

SEMBRA SEnsoristica Multi Bus per Robotica spaziale (Multibus Wired and Wireless On-Board Sensors and Actuators Networks)

CCSDS Mission Operations Services

European Space Agency Directorate of Operations and Infrastructure Mission Operations Department GMES SENTINEL-1

Spacecraft Monitoring & Control Systems

Digital Control for Space Power Management Devices

Telemetry Processing and Display Ground System

Gaia. Title. EADS/Astrium. Name and Function Date Signature. Prepared by. Verified by. Approved by. Authorized by. Application authorized by

SpaceWire Remote Memory Access Protocol

SpaceWire Remote Terminal Controller

GR712RC A MULTI-PROCESSOR DEVICE WITH SPACEWIRE INTERFACES

HIGH PERFORMANCE ELECTRONICS FOR THE NEW SPACE AGE

COMPASS: FORMAL METHODS FOR SYSTEM-SOFTWARE CO-ENGINEERING

John Cornforth (1), Andrew Bacon (1), I Sturland (2), Roland Trautner (TO) (3) (1) Presented by John Cornforth

TAS RTU PRODUCTS. ADCSS 2015 Noordwijk. Thales Alenia Space 23/10/2015. Ref.: DOC-TAS-EN-001

Satellite Services B.V. Next Generation TM/TC System (NTTS final presentation) 4 th February ESA-ESTEC B.R. Tatman

Nanosat Crosslink Transceiver. Boot Code. External Interface Control Document

Flight Computer: Managing the Complexity

Remote Memory Access in Embedded Networked Systems

The Euclid Ground Segment Design for File-based Operations

ECSS E Test Platform Features and Applicability Area

SpaceWire-RT Update. EU FP7 Project Russian and European Partners. SUAI, SubMicron, ELVEES University of Dundee, Astrium GmbH

SpaceFibre Flight Software Workshop 2015

Goddard Mission Services Evolution Center. GSAW Demo

High Accuracy Time Synchronization over SpaceWire Networks

Citation for published version (APA): Bhanderi, D. (2001). ACS Rømer Algorithms Verification and Validation. RØMER.

SpaceWire 101 Seminar MAPLD 2006 SpaceWire origins and purpose From IEEE 1355 to ECSS-E-50-12A

TELECOMMAND AND TELEMETRY COMPONENTS FOR TODAY AND TOMORROW

Addressing Complexity in Connected & Autonomous Vehicles (and in fact everything else )

AUTOBEST: A United AUTOSAR-OS And ARINC 653 Kernel. Alexander Züpke, Marc Bommert, Daniel Lohmann

Blue Canyon Technologies XB1 Enabling a New Realm of CubeSat Science. George Stafford BCT Range St, Suite 200 Boulder, CO 80301

SpaceNet - SpaceWire-RT. Initial Protocol Definition

ESA ADCSS Deterministic Ethernet in Space Avionics

Lunar Reconnaissance Orbiter (LRO)

Space-to-Ground Data Viewer (S2G) & DFDL for Space Library (DFDL4S)

SINGLE MODULAR ON-BOARD COMPUTER FOR SPACE APPLICATIONS

FOR THE DEEP SPACE PROGRAM SCIENCE:.EXPERIMENT (DSPSE) FLIGHT SOFTW ARlt" CSCI. June 1, Prepared for:

The TASTE MBE development toolchain - update & case-studies

Reliable Computing I

Don t Be the Developer Whose Rocket Crashes on Lift off LDRA Ltd

Transcription:

On-Board Control Procedures: Autonomous and Updateable Spacecraft Operator Onboard and Beyond Marek Prochazka / Kjeld Hjortnaes European Space Agency, ESTEC, Software Systems Division. FSW-10, Pasadena 8-10 Dec 2010 OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 1

OUTLINE Overview of OBCP Overview of the OBCP ECSS standard Advanced concepts Conclusions OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 2

OPERATOR ON-BOARD? Having an operator on-board spacecraft would be more efficient?? Reduction of delay Reduction of bandwidth need Enhance autonomy (no need of 24/7 ground operations support) Useful in situations of reduced spacecraft visibility In deep-space missions with long signal propagation delays In situations when a rapid reaction is needed Implementation of on-board solutions in view of unforeseen failures occurring in orbit Adaptation to unpredictable environment End-of-life operations OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 3

ON-BOARD CONTROL PROCEDURES OBCPs are flight control procedures that can be resident on-board or that can be uploaded to the spacecraft as required by the ground Key features: Often interpreted No fault propagates to FSW Isolated in time & space Can be uploaded to the spacecraft in advance Currently used in a variety of ESA missions Deep space missions with high degree of autonomy Rosetta, Venus Express, LISA PF, Herschel-Planck, But also Earth observation missions as missions as GOCE, Cryosat, Sentinel, OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 4

ON-BOARD CONTROL PROCEDURES How does it work? OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 5

The OBCP Standard ECSS-E-ST-70-01C www.ecss.nl

THE OBCP CONCEPT European Cooperation for Space Standardisation (ECSS) ECSS-E-ST-70-01C Published in April 2010 Defines the OBCP concept, system capabilities and the associated engineering process OBCP system includes: OBCP system capabilities Language Preparation environment Execution environment OBCP engineering process Lifecycle of development and V&V OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 7

OBCP DOMAINS OF APPLICATION (I) Spacecraft Operations Streamline: Reduction of bandwidth, delay Enhance autonomy Implementation of on-board solutions in view of unforeseen failures occurring in orbit Adaptation to unpredictable environment End-of-life operations System design Platform functions To isolate mission-specific platform functions of FSW To implement one-shot applications deleted after use To accommodate late specification of detailed FDIR To accommodate late delivery/removal/addition/replacement of equipment Fine tuning configuration sequences without having to modify FSW Payload functions To accommodate late definition and tuning of complex configuration sequences and monitoring/recovery actions OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 8

OBCP DOMAINS OF APPLICATION (II) FSW design and development Ease of development and validation FSW generic, mission-specific functions in OBCP Easier maintenance Automation of tests Debugging Short-term workaround solutions Assembly, Integration and Testing (AIT) Fault injection and robustness testing Long and complex configuration sequences Temporary functions for testing purposes OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 9

TYPES OF OBCP OBOP: On-board Operation Procedures To operate spacecraft i.e. these procedures allow to execute a sequence of telecommands with corresponding logic, which would normally have to be executed manually by spacecraft operators OBAP: On-board Application Procedures Part of the spacecraft functionality Qualification together with FSW There are major differences how OBAP/OBOP are treated Scheduling Resource allocation Accessible services OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 10

OBCP SYSTEM Preparation environment Editor Static checking (constraints, consistency) Configuration Compilation Validation Execution environment Ground Control: Uplinking, Monitoring Visualisation Constraint and consistency checking On-board OBCP engine Monitoring and control (interfacing the ground) Interaction with FSW, platform and payloads Execution of OBCP Could be multiple of them, independent OBCP store Loading, garbage collecting out of the scope of the ECSS standard OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 11

OBCP LANGUAGE CAPABILITIES Domain-specific language or generic programming language Data types Based on another ECSS standard Ground Systems and Operations - Monitoring and control data definition (ECSS-E-ST-70-31) Structures and arrays Explicit type casting Declarations Variables of any data type Constants of any data type Local functions Expressions Assignment Math, time, string bitwise operations Constants, on-board parameters, activity arguments and variables Constants together with their engineering units Mix compatible units Automatic conversion of units On-board parameters by names and in engineering units and also raw form Refer to events by their names OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 12

OBCP LANGUAGE CAPABILITIES (II) Flow control Branching simple and multiple conditional based on any parameter or variable Repeated execution (for-loop, repeat-until, while-do) Waits Until a given OBT, or elapsed time Until a condition becomes true Until given event occurs Until an event from a list of events occurs Combination of conditions within wait statement Precondition/postcondition All waits + test a condition Timeouts for wait Should be possible to define Behaviour in case of exceeded timeout OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 13

OBCP LANGUAGE CAPABILITIES (III) External interactions Read/write on-board parameters Initiating activities (other OBCPs, possibly also using other FSW services) Including reporting conditions, information on started activities Both blocking and non-blocking (spawn or exec&wait) OBAP: Also execution of activities not accessible from the ground (bus access) Raising and accessing events which are reported to the ground and also can trigger appropriate FSW actions Contingency handling based on events/conditions OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 14

OBCP EXECUTION ENVIRONMENT CAPABILITIES (I) Ground Checks (resources, inter-dependecies, state transitions) Uplink Management (PUS 18) Activate request allows to pass parameters Monitoring and control OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 15

OBCP EXECUTION ENVIRONMENT CAPABILITIES (II) OBCP integrity Checksum generated by translation process Checksum checked during load to engine Checksum on request On-board capabilities Predefined scheduling policy Static and dynamic memory allocation policy Garbage collection policy Observability of these by ground Engine services Process the language capabilities Global service for all OBCPs Defined behaviour in case of reset, discontinuity of time (affects waits) Housekeeping information Loading policy OBCP stores Different types of memory Reprogrammable? should be defined Persistency? should be defined OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 16

OBCP EXECUTION ENVIRONMENT CAPABILITIES (III) On-board capabilities (cont.) Process scheduling Should be defined Minimum allocation time per time intervals Several OBCPs in parallel OBAP and OBOP resource allocation is independent Max number of loaded and active OBOPs is defined OBOP resource allocation independent from concurrently executing OBOPs (i.e. context does not change behaviour) OBAP resource allocation to concurrently executing OBAPs should be defined (i.e. definition of priority scheme) Isolation of OBCPs Internal faults do not propagate to OBSW Maximum allocated resources never exceeds Loading, activation and control of an OBCP should not affect active OBCPs How about higher-priority OBCP preempting a lowerpriority one? OBCPs are isolated no fault propagation, no illegal memory access OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 17

OBCP EXECUTION ENVIRONMENT CAPABILITIES (IV) On-board capabilities (cont.) Exception handling Internal errors detected and handled by OBCP or engine Internal errors reported to the ground Run-time error of error handler Termination of OBCP When condition to run OBCP(s) are not longer provided, actions taken defined Contingency handlers establishing default state of SW/HW All running OBCPs suspended Report to ground Continuity of service The concept should be defined Capability to define default autorun OBCPs at engine startup OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 18

TRADE-OFF ANALYSIS: OBOP VS. GROUND-BASED OPERATIONS OBOP benefits: Operations during phases of non-visibility or with long signal propagation Loss of ground control Synchronise with asynchronous elements (events) Coded and up-linked once, used many times Atomic operations (critical activities to be performed at once ) Decrease the need for human availability Ground-based operations benefits: Human response in unforeseen scenarios Decrease the complexity of FSW & validation Engineering effort required to develop and validated an ops procedure is lower than to develop an OBOP Less effort to update a procedure Less complex configuration management OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 19

TRADE-OFF ANALYSIS: OBAP VS. FSW OBAP benefits: Variability and flexibility (in case of mission requirements change) Late definition Maintenance FSW benefits: Better performance Complex functions (engineering process, techniques) Core system with stable reqs. and close to subsystems (e.g. AOCS) Functionality for survival modes (no interpreter activated) Generic functionality (e.g. PUS, reused subsystems) Subsystems to be available early in the lifecycle OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 20

Advanced Concepts Using OBCP

OBCP IN CURRENT EXECUTION ENVIRONMENT OBCP = Fault Containment + Dynamic Code Updates OBCP Engine OBCP 1 OS Library Time Library OBCP 2 OBCP 3 Math Library TM/TC Library OBCP Store Upload Delete Message Transfer Service Time Access Service TM/TC Device Enumeration Service Packet Service Memory Access Service SpaceWire Driver 1553 Driver RTOS Raw SpW/1553 Driver BSW OBCP's Prochazka / Hjortnaes FSW-10, Pasadena BSP 8 Dec 2010 Slide 22

OBCP IN IMA TIME & SPACE PARTITIONED ENVIRONMENT OBCP = Dynamic Code Updates OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 23

OBCPs in ExoMars Rover OBCP engine to manage more complex activities (support for autonomy) Most likely together with Mission Timeline Service (timetriggered actions) Event-Actions service triggering TC files or OBCPs upon an event occurence An option to use Interlocks in the OBCP engine Conditional execution flow of OBCPS Depending on the result of an OBCP another OBCP is allowed to start OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 24

OBCPs IN ESA FSW REFERENCE ARCHITECTURE ABB supported by abstract components : To be confirmed if ABB: Satellite Conf and Eqpt Mgmt Application BB (mission dependent) Plan/ Autonomy Framework System mode mgmt AOCS Thermal Power OBCP execution engine identified as a Flight Software Reference Architecture Building Block Central FDIR SSMM Mgmt OBT Mgmt P/L Manager OBCPs themselves are Execution platform PUS specific Abstract component services Component services Software bus Connector services Container services components (in an execution mode different from native TM/TC Security Unit SSMM Solid State Mass Memory File/ Compress/ Encrypt PUS and MTL services Libraries: mathematical, etc. OBC Hardware CAN OBCP interpreter PUS monitoring Avionics Equipment virtual devices =SOIS DVS MIL-1553 Context Mgmt On-board time =SOIS TAS SOIS Subnetwork layer (1553, CAN, SpW) (including HDSW) CPU/ NGmP RAM Communication services addressing physical distribution across nodes = SOIS MTS DSP BSP OBTimer SGM RTOS Standardized devices RTU/ Intelligent IO components) Legacy devices ADCs / DACs Intelligent devices Sensor and actuators Payloads & Instruments Space Linux SOIS Layers RS422 SpW EEPROM Boot PROM HW watchdog SOIS Layers Digital Sensorbus SOIS Layers Payload Computer Onboard Communications H/W OBCP's Prochazka / Hjortnaes FSW-10, Pasadena (e.g. MIL-STD-1553B, 8 Dec SpaceWire, 2010 CAN Slide RS422) 25

CHALLENGES OF THE OBCP BUILDING BLOCK Interface of the OBCP engine Provided interface To the flight software / To the Ground Required interface To flight software services (e.g. PUS services) To system resources (memory, CPU scheduler, I/O) On-board Operations Procedures (OBOPs) vs. On-board Application Procedure (OBAPs) Different verification approaches Different capabilities Different resource usage profiles (scheduling, memory utilisation) Different interfaces? Position of the OBCP BB in the reference architecture An application component or a part of the execution platform? Time and Space Partitioning Addressed on previous slides Source language Domain specific language, scripting language, Java? To be standardised? To be generated from different languages or MDE diagrams? Execution mode i.e. what is the target language Interpretation (i.e. source language = target language) Intermediate language (e.g. Java bytecode) Native code (Ahead-of-Time compilation, Just-in-Time compilation?) OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 26

CONCLUSIONS A new interesting paradigm - Scripting/Interpreter - Temporal & spatial isolation - Uploading new SW components and updating existing ones at runtime - Specific functionality - Telecommands, telemetry, events - Flow control (branching, loops) - Domain-specific language Interesting areas of application - Autonomy - Software maintenance Challenges remain OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 27

THANK YOU Marek Prochazka, Kjeld Hjortnaes European Space Agency Marek.Prochazka@esa.int Kjeld.Hjortnaes@esa.int OBCP's Prochazka / Hjortnaes FSW-10, Pasadena 8 Dec 2010 Slide 28