23
Where is OPS-GI with the EGOS initiative? 2 nd October, 2009 - Darmstadt OPS-G Forum M. Pecchioli (OPS-GI)

OPS Forum EGOS Evolution 02.10.2009

Embed Size (px)

Citation preview

Where is OPS-GI with the EGOS initiative?

2nd October, 2009 - DarmstadtOPS-G Forum

M. Pecchioli (OPS-GI)

02-Oct-2009 p. 2Title of the presentation

Why data systems infrastructure?

Reduces cost to develop ground data systems for new missions

Enables the development of mission dedicated systems within a reasonable time-frame

Ensures that the overall footprint/expertise to develop/maintain does not increase linearly with the missions/stations

Promotes common solutions/culture across missions

Reduces risks of operational immaturity of mission systems

Encourages cross-fertilisation between ESA and Industry

02-Oct-2009 p. 3Title of the presentation

The infrastructure before EGOS

Purely ‘vertical’ implementation model:

Every application/system implemented the full functionality using ‘closed’ architectures

No sharing/commonality across applications

Little commonality in the engineering approach

No generic application serving multiple domains

Heterogeneous baselines/technologies (e.g. Windows, Solaris, Linux)

Limited scope

Lack of long-term maintainability e.g. no platform independence

02-Oct-2009 p. 4Title of the presentation

The EGOS Initiative

Harmonise the technologies/processes used by all infrastructure products

Develop solutions which are generic enough to serve the same need for different user communities

Promote re-use of the same implementation across infrastructure domains at various levels:

Common libraries (development)

Common components (integration)

Common services (run-time)

Objective minimise the development and long term sustaining efforts of the infrastructure code base

02-Oct-2009 p. 5Title of the presentation

The initial ambition

Move from a fully ‘vertical’ to a largely ‘horizontal’ implementation model: Layered implementation relying on extensive re-use of the same

implementations across all domains

Identify, design and implement all potentially common elements of the future infrastructure

Develop new systems according to the EGOS ‘re-use’ paradigm

Progressively re-engineer the existing systems to replace custom functionality with generic solutions

02-Oct-2009 p. 6Title of the presentation

Difficulties experienced

The larger systems (e.g. S2K) required significant re-engineering activities to rationalise their architecture

Lack of resources to accommodate the ambitious EGOS objectives in parallel with the need to evolve and expand the scope of the infrastructure

General/abstract solutions risk to be over-engineered for small applications e.g. the ones outside the ‘execution’ environment

The selected technology for the ‘native’ EGOS components (CORBA Component Model) is not well supported/widely used

02-Oct-2009 p. 7Title of the presentation

The Current Implementation Model

Platform Baseline

Support ServicesGeneric Applications &

Standards Implementation

Drivers Adapters

External Interfaces User Interfaces

Space SystemsMonitoring& Control

OperationalDataDissemin.Analysis &Reporting

OperationsPreparation

SpaceSystemsSimulators

OperationsPlanning &Automation

02-Oct-2009 p. 8Title of the presentation

Description of the Implementation Model

Common platform baselines (OS + 3rd Party Products) across domains

Run-time support services and generic implementations delivering functionality which is not domain specific

‘Infrastructure functional domains’ supporting generic features which are re-usable across the traditional boundaries of user communities e.g. for controlling or simulating all systems of the ground and space segment

Common service provision layer ensuring ‘integrability’ and ‘inter-operability’

Common user interface platform

02-Oct-2009 p. 9Title of the presentation

The Deployment Model

OperationsPreparation

Databases Management

Procedures Definition

Operational Systems Tailoring

Files Files

Databases

Multi-purpose Data Archive

Post-Operations

Analysis + Reports/Alerts

Data Dissemination

OfficePCs

Internet

RemoteUsers

Planning

Data Interfaces

Mission Data

Automation

M&C Kernel

Service Provision

Operators Interfaces

Operationalconsoles

OfficePCs

Support Services

02-Oct-2009 p. 10Title of the presentation

The support services and generic applications

Databases management (DABYS)Engineering Data Archive (DARC)Data Dissemination (EDDS)Data replication (SFT)

Data Management

Virtual Filestore (FARC)File routing and delivery (GFTS)

Files Management

Build and Installation (GABIS)Configuration Access (EGOS Core)Run-time directory (EGOS Core)Actions execution (EGOS Core)Events logging (EGOS Core)Services management (SMF)Real-time monitoring (OSMOSYS)

System Management

Identity and Session Management (EGOS Core)Secure Access Control (EGOS Core)

Users Management

02-Oct-2009 p. 11Title of the presentation

Harmonisation within functional domains: The simulators example

Simulation Infrastructure

Gro

un

d S

tatio

n

Mo

nito

ring

an

d

Co

ntr

ol V

alid

atio

n

OBS

W

Ma

inte

na

nc

e

Flig

ht

Dyn

am

ics

Gro

un

d S

yste

ms

Va

lida

tion

Spa

ce

cra

ft C

on

tro

l

TodayYesterday Tomorrow

02-Oct-2009 p. 12Title of the presentation

M&C Domain Harmonisation: The ECS example

MCSMCSMCSMCS

STCSTCSTCSTC

ECS

EPS/ESSDistribute products

(GFTS)

Distribute GS schedule(FIDES)

Inject Station Parameters(SMF S2K)

Receive Station Parametersand log messages

(GSC CORBA / SMF)

ECS History Repository

(DARC)

Store monitoring data(DARC API)

ECS ProductRepository

(FARC)

Store plan / schedule(FARC API)

ECS Monitoring(S2K + MATIS)

Inject Station Data(SMF S2K)

02-Oct-2009 p. 13Title of the presentation

M&C Domain Harmonisation: The GSMC example

Specific Mission Control System

SCOS-2000

Spacecraft M&C

GSMC

Ground stations M&C

Common M&C Platform Common M&C Platform

02-Oct-2009 p. 14Title of the presentation

GSMC based on a Common M&C Platform

Ground Station

CentralisedMonitoring

Script

Execution

MA

TIS

(+)

Control Center

Archive

User Desktop based GUI

MO

N M

odel per C

lient

Live Retrieval

File archive

Acquisition node

02-Oct-2009 p. 15Title of the presentation

The idea of Reference Architectures

A Reference Architecture provides a framework for developing and integrating generic and specific implementations

It consists of the definition of components, interfaces and lifecycle of a complete system

Only some of the components are delivered as generic implementations, the others are implemented specifically for a given system

It is a useful platform in all cases where fully generic solutions are not viable for any reason

It encourages the commonality across systems/missions through a progressive generalisation process (rather than the classical specialisation process of generic infrastructure)

02-Oct-2009 p. 16Title of the presentation

Reference Architectures: The EGOS User Desktop

02-Oct-2009 p. 17Title of the presentation

Reference Architectures: EUD Contributors

02-Oct-2009 p. 18Title of the presentation

Reference Architectures: the Post-operations domain

Virtual Data Store

Integration-API

On-line Archives(OPSLAN)

Off-line Archives(Pre-OPSLAN / Relay LAN)

PARC

FARC

DARC

…….

Firewall

Firewall

Web-BasedUser

Interfaces

EGOS views MUST Clients EDDSWS-API

HTTP

Internet

SFT

EDDS

02-Oct-2009 p. 19Title of the presentation

A common support and development environment

Change Management: Synergy Change

Requirements Management:

DOORS

Test Management: Mercury Quality

Centre

SharepointEGOS Portals

User Management

Configuration Management: Synergy CM

BIRFProject

Management Services

License Server

Software Development

Services

CentralServices

02-Oct-2009 p. 20Title of the presentation

Achievements

Advanced in the simulators domain, started in the pre&post-operations domain, awaiting programmatic decisions in the M&C domain (ECS + GSMC)

Harmonisation/rationalisation within functional domains

Implementation of support services and generic applications nearly completed. Deployment in operational systems is behind schedule.

Common implementation across domains

Good progress. Systems which are expected to be maintained in the long-term have or are being re-engineered

Legacy systems re-engineering

Good progress. Converging on Linux 64 bits platform + common 3rd party products

Technology/processes harmonisation

02-Oct-2009 p. 21Title of the presentation

Next (concrete) steps

Complete consolidation of platform baselines (SLES 11 64 bits)

Roll-out generic applications developed so far

Extend the generic applications (e.g. FARC, DARC, SMF) to support the needs of new systems (e.g. ECS and EDDS)

Define the Reference Architecture for the ‘new’ functional domains (i.e. Mission Planning, Pre & Post Operations) and provide a framework implementation

Re-implement the user interfaces of the main systems on the basis of the EGOS User Desktop

Deploy the EGOS Core Components as a multi-system service provider

Develop a common Monitoring and Control platform for spacecraft and ground station control

02-Oct-2009 p. 22Title of the presentation

Conclusions

The importance and the scope of infrastructure ground data systems has constantly increased in the last years

The EGOS initiative has promoted a ‘cross-communities’ culture which is now starting to deliver visible effects

Harmonisation within functional domains is ongoing and should be further supported/promoted

It is important to have strategic long-term visions but it is equally important to map them to concrete steps delivering visible outputs in the short term

Cultural changes take a long time to become visible…

02-Oct-2009 p. 23Title of the presentation

So, where is EGOS?