Flight Dynamics Operational Systems at EUMETSAT and

EUM/FLO/VWG/21/1244503, v1, 10 September 20211

Jose Maria de Juana Gamo, Carlos Miranda, Francesco Croce

FDSSO, 21-23 September 2021

1st European Workshop on Space Flight Dynamics sevices, Systems and Operations

Flight Dynamics Operational Systems at EUMETSAT and planned roadmaps


Agenda

• EUMETSAT • Flight Dynamics at EUMETSAT• Re-engineering: justification, drivers, roadmaps• Computational layer• G-FDS infrastructure re-engineering• Conclusions & outlook


EUMETSAT – AN INTERGOVERNMENTAL ORGANISATIONWITH 30 MEMBER STATES

HUNGARY

BULGARIA

ICELAND

AUSTRIA BELGIUM

DENMARK FINLAND

FRANCE GERMANY GREECE

IRELAND ITALY

UNITED KINGDOMTURKEY

SWEDENSPAIN

PORTUGAL

NORWAYTHE NETHERLANDSLUXEMBOURG

CROATIA

POLAND

LATVIA

SLOVENIA

ROMANIA

CZECHIA

LITHUANIA

ESTONIA

SLOVAK REPUBLIC

SWITZERLAND

PRIMARY OBJECTIVE: Establish, maintain and exploit European systems of operational meteorological satellites...

Darmstadt

Supplying weather and climate-related satellite data, images and products to the National Meteorological Services of our Member States… in real time, 24 hours a day, 365 days a year, during decades


CURRENT EUMETSAT SATELLITES

Metop-BMetop-C

Metop-ASentinel-3A

Sentinel-3B

Jason-3

Meteosat-8

Meteosat-10Meteosat-9Meteosat-11

Sentinel-6 Micheal Freilich

SENTINEL-3A & -3B (98.65° incl.)

Copernicus satellites delivering marine and land observations

Low Earth, sun-synchronous orbit

JASON-3 (63° incl.)Low Earth, non-synchronous orbitCopernicus ocean surface topography mission (shared with CNES, NOAA, NASA and Copernicus)

Sentinel-6 Micheal Freilich (66° incl.)Low Earth, drifting orbitCopernicus ocean surface topography mission (shared with CNES, NOAA, NASA and Copernicus)

Meteosat Second Generation

Two-satellite systemFull disc imagery mission (15 mins) (Meteosat-11 (0°))Rapid scan service over Europe (5 mins) (Meteosat-10 (9.5° E))BACKUP SATELLITE and gap filler for RSS (Meteosat-9 (3.5°E))

METEOSAT-8 (41.5° E)

METEOSAT-9, -10, -11Geostationary orbit

Geostationary orbitMeteosat Second generation providing IODC from February 2017 – mid-2020

METOP-A, -B & -C (98.7° incl.)Low Earth, sun-synchronous orbitEUMETSAT Polar System (EPS)/Initial Joint Polar System

FD operates currently 4 GEO + 6 LEO

FD to further operate in comingyears MTG, EPS-SG, Sentinel-7…


• In the past EUMETSAT deployed end-to-end solutions for each successive programme (MTP, MSG and EPS), with relatively little re-use or commonality in implementation between programmes

• Later programmes (S3, S6, EPS-SG) followed a different approach: Flight Dynamics is a system separately instantiated by each program. The FDS of each program is composed by a set of generic functions (called Flight Dynamics kernel) which is reused by every mission and a set of mission specific functions developed specifically for each mission.

• Flight Dynamics is NOT a single element instance (facility) used by several programmes

Control Centre Mission A

Flight Dynamics at EUMETSAT (systems)

FD specific FD kernel

Control Centre Mission B

FD specific FD kernel

…


• Technical management of external suppliers for maintaining each FD system is made by multi-mission team at EUMETSAT (within the Technical and Scientific Support department)

• Operations are performed by a multi-mission Flight Dynamics team (within the Operations and User Services department)

• Unified service for on-site consultancy support to both departments starting in 2022 (see separate presentation)

Flight Dynamics at EUMETSAT (teams)


Justification for re-engineering

EUMETSAT experiencing a relevant increase in number of

missions

Needs to improve GS Systems lifecycle costs/efforts through

harmonisation

An engineering roadmap defined for Mission Control Applications

(Mission Planning, Flight Dynamics, Ops Prep tools)

Maximise Re-Use

Long Term Maintainability

Lessons Learned

Knowledge Harmonization

ArchitectureModel

Re-UseModel

ReferenceTechnologies

Roadmap Strategic Objectives

Roadmap EngineeringDrivers

Design allowing maximum re-use across missions

Modular/component basedNon-crontroversial IPRsAvailable industry support

Maintenance, s/w engpractices, mission specific development lifecycle, operational experience

Teams/contracts harmonizations, improve cross-team knowledge base (design, technologies, processes…)


Before continuing…a look first at current System

• The Flight Dynamics Systems (FDS) in use for current LEO missions (EPS, Sentinel-3, Sentinel-6) as well as the ones under preparation (EPS-SG) are based on ESA’s NAPEOS, with extensive modifications performed by EUMETSAT and its contractors in order to adapt software to the mission needs

• Two distinct layers can be identified in current application s/w• Computational layer: computational programs used for the Flight Dynamics

computations (Orbit Determination, Orbit propagation, Manoeuvre generation, Telecommands generation, Products computation and generation, etc)

• Infrastructure layer: FD application functions (context manager, databases, graphics generation, incoming/outgoing manager) plus application agnostic elements (HMI, data management, logging, access…

-> communication between them done via well defined interface

Computational layer is further subdivided in core functions (common to all missions) and mission-specific functions (only needed by a particular mission for covering specific needs)


Generic Flight Dynamics systemDriversThe main strategic drivers:

- To separate the flight dynamics application functions (FDS Application) from the flight dynamics algorithms (FDS computational programs)

- To include a strong distributed services / components based architecture approach with definition of services exposing formal and well defined interfaces

- To be ‘resilient’ as much as possible to big changes/evolutions in technologies

- To allow extensions of application capabilities without software changes through configuration, FDS Data Model definitions (including creation of required panels) and implementing mission specific extensions through new or modified FDS computation programs

- To re-engineer the FDS HMI using up-to-date technologies and high level of FDS panel configurability ensuring consistency and protection of user inputs

- To take advantage of updated deployment technologies such as containers and containers orchestration


Generic Flight Dynamics systemRoadmap scope

Current System: FDF

G-FDS HMI Specific Components

Middleware and Infrastructure Services (MIS)

G-FDS Application ServicesComputational

Programs

Application LayerNew System: G-FDS

• Service Based Architecture (cloud based)• Formal Separation (ICD) with Computational Programs• Mission Specific limited to Computation Programs• Application Agnostic Middleware and Infrastructure Services

(MIS) layer re-usable by other systems/roadmaps• HMI with web based technologies

Application Functions

Application LayerHMI

Computational Layer

• Single “Fat” monolithic application functions• Obsolete design with impossibilities to migrate to

upgraded operational concepts and technologies• Obsolete Technologies particular on HMI

Computational Programs ROCONTROL

G-HMI Components


Flight Dynamics Re-engineering roadmaps

• By keeping the interface between Computational layer and Infrastructure layer unchanged, re-engineering of the two layers can be decoupled

• Computational layer re-engineering roadmap

• Infrastructure layer re-engineering roadmap


Computational layer re-engineering (1/1)

• Given current use of Orekit at EUMETSAT, and considering preliminary market research performed internally, an Orekit-based solution was studied

• Initial feasibility study for the migration of the S3FDF Computational layer to an Orekit-based solution was performed in 2019/2020. In a nutshell:

• The migration to an Orekit-based solution is doable• A staged migration is achievable• Many functions already exist in Orekit. Two major ones missing: Orbit Control, Inputs processing and other mission

specific features• Even though most functions exist in Orekit, large efforts in linking current interfaces to Orekit APIs (user-defined

information to Orekit APIs, plus inverse process to return to S3FDF APIs)

• Orekit-based BAHN-prototype implemented in 2020 to further confirm assumptions and results of the initial feasibility study. In a nutshell:

• Efforts higher than anticipated • Main issues: lack of NAPEOS knowledge, some development of functionalities not identified nor in initial

requirements, more validation test cases necessary than anticipated • BAHN prototype missing few features and/or with still some trade-off/operability issues, but works (implementation

confirmed feasibility)

• Future migration still to be decided, not earlier than 2023.


Infrastructure layer re-engineering (1/4)Development status• Initial prototyping (2019)

• Technologies assessment, fundamental mechanisms, implications• This phase included: Requirements Engineering and architectural design, as well as generation of a HMI prototype.

• Ongoing development (2020- )• Based on previous phase, a delta requirements engineering and architectural design was done, plus the

implementation phase.


Infrastructure layer re-engineering (2/4) Reference TechnologiesTechnologies selected with stable and proved support to secure investment in thelong term and minimize re-engineering in case of obsolesces

Software Platform

Web based Technologies• How back-end services are accessed and

exposed• HTML/CSS/JS technology solution for desktop

HMI platform

Java and Springboot as nominal back-end servicesdevelopment technology

System Platform

Recognized relevance and advantages of cloud likeapplication hosting

Containerization and containers Orchestration adoptedas application runtime environment

Hardware, virtualisation, storage, networking,Containerization and Orchestration as PaaS, IaaS by thein-house data center.


Infrastructure layer re-engineering (3/4) System Platform

Cluster

Application Family

Hardware

Virtualization

Operating System

ContainerizationClus

ter/

Orc

hest

ratio

n M

anag

emen

t

Middleware And Infrastructure Services

Family Context

…

API Gateway

ApplService …Appl

Service

Application Family

Family Context

ApplService …Appl

Service

cluster administrator

Application User

Application Administrator

Application Administrator

Application I&V Manager Application I&V Manager

Application HMI Client

API

API

Kubernetesas container orchestration and cluster management

Dockeras container runtime

Kubernetes Cluster Ensures• containers instantiation and runtime management• containers replica for redundancy• load balancing• cloud virtual network• local (per container) and external storage management• automated rollouts• Ingress (API Gateway) as external entities access gateway to cluster

services and hosted applications• ConfigMap as a way to manage configuration static properties• Support for virtual sub-clusters through Namespaces (Namespaces

used for Family Context allocation)


Infrastructure layer re-engineering (4/4) Human Machine Interface

Architecture model for HMI Applications follows the same re-use strategies for back-end services. It includes:• Generic HMI Framework: generic HMI building block for fundamental HMI features and services (e.g. layout management, extensions points, …)• HMI Components: making use of HMI Framework and implementing specific HMI functionality in support to MIS and applications services use-cases• HMI Applications: aggregation (though assembly definition) of generic framework and selection of HMI components toward a specific HMI application scope

Technologies• HTML, CSS, Javascript and associated frameworks• HMI Desktop platform based on Electron• Javascript Frameworks (Angular and others) HMI framework and some components

Web

bas

ed te

chno

logi

es

HMI Platform(electron)

Generic Application Framework

HMI Components

HMI Application Assembly Definition

Javascript Frameworks(Angular and other)


Conclusions and Outlook• Due to the increase of missions, EUMETSAT decided to optimise overall lifecycle of future systems

via harmonization and use of more modern technologies

• Engineering roadmaps were identified in the Monitoring Control Application domain, based on engineering drivers (re-use, service architectures, reference technologies)

• The roadmap definitely constitutes a challenge and a move from the currently in place system scenarios

• Flight Dynamics system was selected as the first system to be addressed/moved to new harmonized and more modern technologies

• In addition, via the definition of well defined formal interfaces, Flight Dynamics Computational layer/programmes can be decoupled completely from the rest of infrastructure and follow a different, fully independent, engineering roadmap

• Flight Dynamics System re-engineering (excluding computational layer) already in ongoing/advanced development status, under the Technical and Scientific Support department

• First version(s) shall be available to OPS (Operations and User Support department) in 2022

• In parallel, preliminary feasibility studies have been done for migrating the Flight Dynamics Computational layer programmes into an Orekit-based solution.

Documents

Flight Dynamics Operational Systems at EUMETSAT and