Embed Size (px)
Citation preview
EGOS Architecture
EGOSArchitecture
October 2005C. R. Haddow, OPS-GI
OPS-G Forum; 2005/10/21 EGOS Architecture - 2
EGOS Architecture
Presentation Overview
• Introduction
• Rational
• Architecture
• Implementation approach
• Status
OPS-G Forum; 2005/10/21 EGOS Architecture - 3
EGOS Architecture
Introduction
OPS-G Forum; 2005/10/21 EGOS Architecture - 4
EGOS Architecture
What is EGOS ?
• Future infrastructure for ESA ground segment systems– Aims to standardise and harmonise
existing systems– Improve interoperability issues
• Evolutionary approach required due to size of existing code base
OPS-G Forum; 2005/10/21 EGOS Architecture - 5
EGOS Architecture
Rational 1:If its not broke why fix it ?
• Heterogeneous operating systems,i.e. lack of common approach
• Heterogeneous hardware platforms• Different HCI (Human Computer Interface) look and feel.• No standard network and communication services• No standard language or protocol for data interchange • Lack of common metadata model• Lack of common standard for event and log messaging• Lack of common standard for data access (files and
databases)• Variety of databases used across subsystems• Different internal representations for data
OPS-G Forum; 2005/10/21 EGOS Architecture - 6
EGOS Architecture
Rational 2• Lack of common approach to system monitoring and control• Lack of common approach to security• Lack of common approach to fault management• Lack of common approach to configuration and system
initialisation• Lack of isolation of software systems from operating systems
and COTS to improve portability• Lack of clear isolation between components of a subsystem• Lack of synergy across developments• Proliferation of test tools to support the validation of the
various subsystems.
OPS-G Forum; 2005/10/21 EGOS Architecture - 7
EGOS Architecture
Scope: Near Term
• Mission Control Systems
• Simulators
• Ground Station Equipment:– Base-Band System at the Ground Station, i.e. the
systems to which the Operations Control Centre (OCC) interfaces to receive telemetry and transmit telecommands.
– Ground Station Monitoring and Control
OPS-G Forum; 2005/10/21 EGOS Architecture - 8
EGOS Architecture
Scope: Longer Term
• Satellite Electrical Ground Support Equipment (EGSE)
• Flight Dynamics Systems
• Mission Planning Systems
• Expandability
OPS-G Forum; 2005/10/21 EGOS Architecture - 9
EGOS Architecture
Context
OPS-G Forum; 2005/10/21 EGOS Architecture - 10
EGOS Architecture
Architecture: Approach
• Design goals: modular, layered design with– Clear boundaries between subsystems and layers– Clear interfaces between subsystems
• Systematic reuse,– an intentional effort is being made to create a
multiuse software architecture
• Evolutionary approach– take best elements from systems and adapt these.
OPS-G Forum; 2005/10/21 EGOS Architecture - 11
EGOS Architecture
Architecture: Elements 1
• Application Program Interface (API)– access to services is provided through API’s
• Libraries– concentrate on domain specific requirements –
low level reuse
• Service port– is a definition of required and provided interfaces
and the functionality of service location and routing
OPS-G Forum; 2005/10/21 EGOS Architecture - 12
EGOS Architecture
Architecture: Elements 2
• Component– an isolated functional part.
• Framework Infrastructure.– provides the functionality needed to ‘glue’
components together into a working whole, including the functionality of service ports
EGOS framework itself is the composition of the framework infrastructure and a set of components
OPS-G Forum; 2005/10/21 EGOS Architecture - 13
EGOS Architecture
Architecture: Framework Overview
Component A
Application
EGOS Framework
Application Logic
Framework Infrastructure
Library
API 1
Service Port1
API 2
Service Port2
API 3
Service Port3
Component B Component C
API 2
Service Port2
Component D
API 4
API 4
API 4
OPS-G Forum; 2005/10/21 EGOS Architecture - 14
EGOS Architecture
Architecture: Logical layers
High Level Component
High Level Component
High Level Component
High Level Component
Special High Level
Component
Special High Level
Component
EGOS Framework
Low Level Component
Low Level Component
Low Level Component
Low Level Component
Low Level Component
Low Level Component
Special Framework
Special Low Level
Component
Special Low Level
ComponentMid Level
ComponentMid Level
ComponentMid Level
ComponentMid Level
Component
Special Mid Level
Component
Special Mid Level
Component
Service Management Framework
Driver Driver Driver Driver
OPS-G Forum; 2005/10/21 EGOS Architecture - 15
EGOS Architecture
Low-Level Components and Framework
• Comprise the basic EGOS framework
• Provides– Inter process communications– Event logging– Service directory– Configuration services
OPS-G Forum; 2005/10/21 EGOS Architecture - 16
EGOS Architecture
Mid-Level Components
• Provide widely used services, e.g.– File archiving– Packet archiving– System control– Desktop– User management– Database– Help– Security– Encryption
OPS-G Forum; 2005/10/21 EGOS Architecture - 17
EGOS Architecture
Specialised Frameworks
• EGOS needs to allow expandability– provided by specialised frameworks
• Extend and build on basic EGOS functionality• Could be used in areas such as
– EGSE– Mission planning– Simulators– Groundstations
OPS-G Forum; 2005/10/21 EGOS Architecture - 18
EGOS Architecture
High Level Components
• Provides “end-user” functionality, e.g.– Telemetry chain– Mission Automation System (MAS)– Estrack Management System (EMS)– Network Interface System (NIS)– Onboard Software Maintenance System (OBSM)
OPS-G Forum; 2005/10/21 EGOS Architecture - 19
EGOS Architecture
Service Management Framework
• Provides encapsulation layer
• Exposes services to external users/systems in standardised manner
• Controls access to exposed services
• Interfaces to internal services via drivers that handle required protocol conversion
OPS-G Forum; 2005/10/21 EGOS Architecture - 20
EGOS Architecture
Architecture: High Levelid Component Model
«Components»Station Mid Level Componnts
+ Station Low Level Component
«Components»Mission Planning Mid Level Components
+ Mission Planning Low Level Component
«Components»Simulator Mid Level Components
+ Simulator Low Level Component
+ Simulator Scheduler
«Component»
Estrack Management
(EMS)
«Component»
EGOS Data Disposition
(EDDS)
«Component»
Mission Automation (MAS)
«Component»
Network Interface (NIS)
«Component»
On-board Software
Management (OBSM)
«Component»
Security Gateway
«Component»
TC Chain
«Driver»
TC Multiplexer
«Component»
TM Chain
«Driver»
TM Packetiser
«framework»Serv ice Management Framwork
«Component»
Station File Server
«Driver»
Station Packetiser
«Driver»
Station Multiplexer
«Component + Drivers»
TC Processor
«Component + Drivers»
TM Processor
«Component»
Mision Planning High Level Component
«Component»
Simulator High Level Component
«Components»EGOS Mid Level Components
+ Help Facility (CHAPP)
+ Configuration Management
+ Database
+ Desktop
+ File Archive (FARC)
+ Packet Archive (PARC)
+ Security
+ System Control
+ User Manager
«framework»EGOS Framework & Low Level Components
+ Configuration Access
+ EGOS Standard Library
+ Events and Actions
+ Inter-Process Communications
+ Service Directory
«library»
SLE API
«use»
«use»
«use»
«use»«use»«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»«use»
«use»
«use»
«use»
«use»
«use» «use»
«use»
«use»«use»
«use»«use»
«use»
«use»
«use»
«use»
«use»«use» «use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»«use»
«use»
«use»
«use»
«use»
«use»«use»
«use»
«use»
«use»
«use» «use»
«use»
«use»
«use»
«use»
«use»
«use»
«use»«use»
«use»
«use»
«use»
OPS-G Forum; 2005/10/21 EGOS Architecture - 21
EGOS Architecture
Physical
Boundar
y
N-Tier Architecture
• Splits components into tiers– Presentation layer– Business logic– Data access services
• Benefits– Business and data services are
deployed on servers enabling thin client solutions
– Applications do not need to be maintained on each client machine
– Scalability is enhanced
Data Services
Physical
Boundar
y
Business Logic
Presentation Layer
OPS-G Forum; 2005/10/21 EGOS Architecture - 22
EGOS Architecture
Presentation Layer
• Provides the interaction with the user
• Allows display of data
• Accepts input from user
• Clearly defined interface between presentation and business logic layers– Allows comparatively straightforward
change to GUI technologies used
OPS-G Forum; 2005/10/21 EGOS Architecture - 23
EGOS Architecture
Business Logic
• Process the data
• Carries out the “real” functions
• Useful to isolate from changes to GUI/Data storage technologies– quite often basic processing requirements
don’t change
OPS-G Forum; 2005/10/21 EGOS Architecture - 24
EGOS Architecture
Data Services
• Provides access to data
• Well defined set of interfaces between Business Logic and Data Services Layers required
• Manner of how data is physically accessed or stored transparent to Business Logic
OPS-G Forum; 2005/10/21 EGOS Architecture - 25
EGOS Architecture
Multi-Mission SystemsMission Specific SystemsShared Resources
EGOS Framework
Mid Level Comps
EMS Components
EGOS Framework
Mid LevelSim Framewrk
Sim CmpsSim Mid CmpsSim Hi Cmps
EGOS Framework
Mid Level Comps
NIS + MCS Comps
EGOS Framework
Mid Level Comps
MAS Components
SMF
EGOS Framework
Mid Level
Stn Cmps
Stn Framewrk
Stn Mid CmpsStn Hi Cmps
Deployment
SLE Service Provider
(Non-ESA)
Flight Dynamics
System
PI(External to
ESOC)
Mission Planning
Access to services via SMF
Access to services at component level
OPS-G Forum; 2005/10/21 EGOS Architecture - 26
EGOS Architecture
Lifecycle
• Low level components/framework– released as 1 entity
• Mid level components– ?
• High level components– each high level component, or possibly
component groups, will have its own lifecycle
OPS-G Forum; 2005/10/21 EGOS Architecture - 27
EGOS Architecture
Technologies
• Target platforms:– SUN/Solaris– PC/SuSE Linux (SLES)
• Languages:– C++– JAVA
• Adaptive Communication Environment (ACE) • Eclipse/SWT, possibly Rich Client Platform
(RCP)
OPS-G Forum; 2005/10/21 EGOS Architecture - 28
EGOS Architecture
Implementation Approach
• Evolutionary– Large existing code base ~106 LoC
• Development of new systems has to continue– try to minimise impact of future changes on
these developments
• Approach depends on component level
OPS-G Forum; 2005/10/21 EGOS Architecture - 29
EGOS Architecture
High Level Components
• New high level components, e.g. MAS, EMS, NIS, being built using existing mid-level components– Most existing mid level components have
been taken from S2K
OPS-G Forum; 2005/10/21 EGOS Architecture - 30
EGOS Architecture
Mid Level Components• No specific mid level development currently started• Existing mid level components provide functionality for
– System processes management (Task Manager)– System processes monitoring and control (Applications Launcher
GUI, System Control)– System static/dynamic configuration management (MISC)– Users/Privileges management– Events/Alarms management– Files Archive (FARC)– Packet Archive (PARC)
• Identified mid level components will be removed from S2K and maintained separately
• Expected that additional mid level components from other systems will be identified
OPS-G Forum; 2005/10/21 EGOS Architecture - 31
EGOS Architecture
Low Level Components and Frameworks
• New development foreseen• Evaluation of required low level functionality
being carried out, i.e.– Event logging– Service directory– Configuration– Inter process communication
• Software requirements will be defined for low level components/framework
• Critical for success of EGOS
OPS-G Forum; 2005/10/21 EGOS Architecture - 32
EGOS Architecture
Status
• Draft EGOS High Level architecture is ongoing– reviewed by OPS-GI– further work needed particularly wrt simulators and groundstations.
• SMF provisionally accepted• New systems being developed using existing mid level
components• Mid level component will be extracted from S2K during R5
development and in future be maintained separately• EGOS LLC and Framework SR and AD project kicked-off
mid August• User Desktop SoW just issued
OPS-G Forum; 2005/10/21 EGOS Architecture - 33
EGOS Architecture
Issues
• Lifecycle of different components and layers still to be completely defined
• Ensuring that all EGOS components defined are essential
• May be necessary to permit different implementations of similar functionality– could avoid extensive reworking of existing systems
• Incomplete coverage of groundstation requirements • Incomplete coverage of simulator requirements• “Gluing” everything back together• Participation of CNES & DLR under NoC umbrella
OPS-G Forum; 2005/10/21 EGOS Architecture - 34
EGOS Architecture
Thank you for your attention.Questions ?
![EGOS dossier [english ver.]](https://img.dokumen.tips/doc/110x75/568c4be71a28ab49169e05e2/egos-dossier-english-ver.jpg)
