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

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

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

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

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

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

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

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

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

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

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

The Current Implementation Model Platform Baseline Support Services Generic Applications & Standards Implementation Drivers Adapters External Interfaces User Interfaces Space Systems Monitoring & Control Operational Data Dissemin. Analysis & Reporting Operations Preparation Space Systems Simulators Operations Planning & Automation

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

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

The Deployment Model Operations Preparation Databases Management Procedures Definition Operational Systems Tailoring Files Files Databases Multi-purpose Data Archive Post-Operations Analysis + Reports/Alerts Data Dissemination Office PCs Internet Remote Users Planning Data Interfaces Mission Data Automation M&C Kernel Service Provision Operators Interfaces Operational consoles Office PCs Support Services

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

Harmonisation within functional domains: The simulators example Simulation Infrastructure Ground Station Monitoring and Control Validation OBSW Maintenance Flight Dynamics Ground Systems Validation Spacecraft Control Today Yesterday Tomorrow

M&C Domain Harmonisation: The ECS example MCS MCS MCS MCS STC STC STC STC ECS EPS/ESS Distribute products ( GFTS ) Distribute GS schedule ( FIDES ) Inject Station Parameters ( SMF S2K ) Receive Station Parameters and log messages ( GSC CORBA / SMF ) ECS History Repository (DARC) Store monitoring data ( DARC API ) ECS Product Repository (FARC) Store plan / schedule ( FARC API ) ECS Monitoring (S2K + MATIS) Inject Station Data ( SMF S2K )

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

GSMC based on a Common M&C Platform Ground Station Centralised Monitoring Script Execution MATIS (+) Control Center Archive User Desktop based GUI MON Model per Client Live Retrieval File archive Acquisition node

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)

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)

Reference Architectures: The EGOS User Desktop

Reference Architectures: EUD Contributors

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-Based User Interfaces EGOS views MUST Clients EDDS WS-API HTTP Internet SFT EDDS

A common support and development environment Change Management: Synergy Change Requirements Management: DOORS Test Management: Mercury Quality Centre Sharepoint EGOS Portals User Management Configuration Management: Synergy CM BIRF Project Management Services License Server Software Development Services Central Services

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 3 rd party products Technology/processes harmonisation

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

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

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…

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…

So, where is EGOS?