OPS Forum EGOS Architecture 21.10.2005

572 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
572
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OPS Forum EGOS Architecture 21.10.2005

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

×