OPS Forum Infrastructure Developments for Mission Operations Automation 02.02.2006
Upcoming SlideShare
Loading in...5
×
 

OPS Forum Infrastructure Developments for Mission Operations Automation 02.02.2006

on

  • 1,192 views

The presentation will provide an overview of the underlying operations concept that has been defined by the Automation Working Group (involving OPS-G and OPS-O staff) and describe the infrastructure ...

The presentation will provide an overview of the underlying operations concept that has been defined by the Automation Working Group (involving OPS-G and OPS-O staff) and describe the infrastructure systems that are being developed to support it.

Statistics

Views

Total Views
1,192
Views on SlideShare
1,186
Embed Views
6

Actions

Likes
0
Downloads
16
Comments
0

1 Embed 6

http://www.slideshare.net 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Largely manual Clear split in responsibility Network Operators responsible for shared resources, I.e. ground stations etc. Spacecraft Controller responsible for operation of mission specific resources, e.g. mission control system, network interface system etc. Coordination via voice loops
  • Largely manual Clear split in responsibility Network Operators responsible for shared resources, I.e. ground stations etc. Spacecraft Controller responsible for operation of mission specific resources, e.g. mission control system, network interface system etc. Coordination via voice loops
  • Largely manual Clear split in responsibility Network Operators responsible for shared resources, I.e. ground stations etc. Spacecraft Controller responsible for operation of mission specific resources, e.g. mission control system, network interface system etc. Coordination via voice loops
  • Largely manual Clear split in responsibility Network Operators responsible for shared resources, I.e. ground stations etc. Spacecraft Controller responsible for operation of mission specific resources, e.g. mission control system, network interface system etc. Coordination via voice loops
  • Current concept works well so automation concept built on top of this. Central system (ESTRACK Management System EMS) responsible for planning and controlling shared resources Mission specific systems responsible for the generation and execution of schedules for mission specific systems. Loose coupling minimises dependencies and impact of failures
  • Current concept works well so automation concept built on top of this. Central system (ESTRACK Management System EMS) responsible for planning and controlling shared resources Mission specific systems responsible for the generation and execution of schedules for mission specific systems. Loose coupling minimises dependencies and impact of failures
  • STC Station Computer G/S Groundstation equipment, e.g. TMTCS, IFMS etc. MPS Mission Planning System OPS Operations Preparation System (e.g. MOIS) MCS Mission Control System NIS Network Interface System FDS Flight Dynamics System EMS ESTRACK Management System MAS Mission Automation System SMF Service Management Framework
  • Composed of 3 loosely coupled systems; ESTRACK Planning System (EPS); Generates the ESTRACK Management Plan ESTRACK Scheduling System (ESS); Responsible for generating schedule for shared resources and SICFs. ESTRACK Coordination System (ECS); Responsible for monitoring the execution of the schedule.
  • Planning approach can be summarized as follows, Network service reqs of client missions are specified statically in mission agreements, comprising User service definitions, which specify required network operational services (telemetry reception, telecommanding, ranging, etc.) Standing orders, which specify when and how services shall be provided in a generic manner Client missions provide dynamic input during operations via event files, which include orbital event predictions and specific mission events relevant to the network service allocation process Network service allocation process periodically updates the ESTRACK Management Plan (EMP), which identifies the network service sessions that are implemented by each ground stations Client missions interact with EMS in order to Temporarily modify their network service requirements within limits given in the mission agreement Accept the service sessions proposed by EMS Refine service sessions proposed by EMS, providing the value of specific parameters used for the generation of the facility schedules
  • Main input is mission agreement; specifies agreed high level allocation of stations to mission. Effective;y a standing order. Flight Dynamics input also needed to determine when S/C has visibility of station. Interaction between EPS and MPS via allocated schedule, refinement requests and schedule commitments.
  • The ESS is the EMS component responsible for generation of schedules for all ESTRACK facilities, I.e. the ground stations the data communications network Also produces Master Schedule for the ESTRACK Coordination System SLE Service Instance Configuration Files (SICF) produced for groundstations, NIS and SLE compliant external facilities.
  • The ECS is the EMS component that implements the online management features of EMS ECS shall ultimately be able to automate facility schedule control and coordination of facilities during routine operations. This is achieved by execution of the EMS master schedule and the support of coordination procedures. Loosely coupled to MAS by a messaging service provided by the SMF
  • The Service Management Framework (SMF) is intended as a “wrapper” layer that provides a generic set of interfaces to services provided by the encapsulated system(s).
  • The Service Management Framework (SMF) is intended as a “wrapper” layer that provides a generic set of interfaces to services provided by the encapsulated system(s).
  • MAS is for the execution of schedules generated by the mission planning system (MPS) of a particular mission. There will be a mission specific MAS for every mission where automation of operation is required MAS wills support automation of any mission specific component of a ground segment. Initial scope limited to MCS and NIS In future could cover FDS and DDS.
  • Schedule Preparation System is an off-line part of MAS which allows the user to create and validate Mission Automation User Schedules. The MAUS may reference activity definitions (i.e. procedures, events etc.) already defined in the Operations Preparation System (OPS) and stored in the MAS KBS. The SPS allows a user to validate a schedule after creation and if validated, the schedule may be put under version control in the KBS.
  • SMSresponsible for the actual real-time execution of the schedules authorised in MAS. Multiple schedules may be running at a time and schedules may contain parallel executing activities. The SMS is in charge of keeping track of all the tasks associated to activities referenced by running schedules and to ensure the associated activities (i.e. procedures) are executed at the specified times maintaining any defined execution constraints etc.
  • MAS is for the execution of schedules generated by the mission planning system (MPS) of a particular mission. There will be a mission specific MAS for every mission where automation of operation is required MAS wills support automation of any mission specific component of a ground segment. Initial scope limited to MCS and NIS In future could cover FDS and DDS.
  • MAS is for the execution of schedules generated by the mission planning system (MPS) of a particular mission. There will be a mission specific MAS for every mission where automation of operation is required MAS wills support automation of any mission specific component of a ground segment. Initial scope limited to MCS and NIS In future could cover FDS and DDS.
  • MAS is for the execution of schedules generated by the mission planning system (MPS) of a particular mission. There will be a mission specific MAS for every mission where automation of operation is required MAS wills support automation of any mission specific component of a ground segment. Initial scope limited to MCS and NIS In future could cover FDS and DDS.
  • Phase 2 of EMS (I.e. ESS) may start early 2006. Phase 2 MAS ?
  • Systems are complex, no matter how much testing is carried out it will take time to fully validate them in a operational contex t. Initial use to ease load on Spacecraft Controller thereby possibly enabling one spacecraft controller to control more than 1 S/C Difficulty in capturing all data in current FOPs in manner that can be converted to executable procedure. How are automatic procedures to be debugged ? Both of the above points are especially true for contingency procedures
  • Concept developed covers both shared and mission specific resources. Only loose coupling between the EMS and MAS, mitigates against failures propagating from one system to the other Use of automation will increase as confidence in system is established and the required procedures defined Automation will be extendable to cover nearly all elements of ground segment

OPS Forum Infrastructure Developments for Mission Operations Automation 02.02.2006 OPS Forum Infrastructure Developments for Mission Operations Automation 02.02.2006 Presentation Transcript

  • Infrastructure Developments for Mission Operations Automation M. Pecchioli, C. Haddow, S. Haag, G. P. Calzolari (OPS-GI) OPS- G Forum 3 rd Feb 2006
  • Presentation Overview
    • Background
    • What is missing
    • Target architecture
    • ESTRACK Management System (EMS)
    • Service Management Framework (SMF)
    • Mission AuTomatIon System (MATIS)
    • MCS Infrastructure Upgrades
    • Issues
    • Conclusions
  • Background 1/3
    • Ground station resources scheduling is currently largely a manual process
    • Spacecraft planning carried out by mission specific Mission Planning Systems, interacting with the Flight Dynamics System
    • Responsibility for ‘run-time’ monitoring and control of shared resources (e.g. stations) falls under the network operator
    • Responsibility for mission operations via mission dedicated elements (e.g. Mission Control System) under the spacecraft controllers (SPACONs)
    • Coordination between the different operators during execution phase via voice loops
  • Background 2/3
    • ESA Tracking Network has increased in size, capabilities and complexity (migration from mission dedicated facility to a multi-mission approach with ground station shared between several missions). This imposes the need to increase reliability of service, resource optimization and reduction of manual interventions;
    • Spacecraft routine operations as such are largely executed without operator interaction but control center operations aren’t, primarily due to the fact that ESOC MCS infrastructure is lagging behind in the area of support to mission operations automation
    • Missions are adopting ‘ad-hoc’ solutions to minimize the load on spacecraft operators
  • Background 3/3
    • An Automation Working Group was set-up in year 2005 with the objective to define an automation concept and to derive the high-level requirements for the control center infrastructure:
      • E. Sorensen (OPS-ONV)
      • P. Ferri (OPS-OPR)
      • A. Rudolph (OPS-OFN)
      • T. Beck (OPS-ONF)
      • C. Haddow (OPS-GI)
      • A. Ercolani (OPS-GDS)
      • G. P. Calzolari (OPS-GIB)
      • M. Pecchioli (OPS-GIC)
  • Objectives of Automation
    • Enable optimised utilisation of shared resources
      •  Reduced cost
    • Enable reduction of the global number of operators required per shift and/or enable execution of ‘lights-off’ operations
      •  Reduced cost
    • Enable automated execution of repetitive operations
      •  Increased reliability
    • Enable automated reaction to ground equipment failures
      •  Increased operational resilience
  • What is missing in the infrastructure?
    • SCOS-2000 does already expose a number of external interfaces enabling the automation of spacecraft operations
      • but this set of interfaces is inadequate to allow the ‘replacement’ of a spacecraft operator with an automation tool. Same issue with the NCTRS
    • There is a significant amount of European proprietary tools supporting automated execution of ‘structured’ statements (procedures).
      • but none belongs to ESOC and none fits completely with other ESOC systems
    • The Flight Dynamics System supports the planning phase by means of a number of (more or less) standardised products
      • but no other generic system supports the planning of shared resources (e.g. ESTRACK) nor of mission dedicated resources
  • Automation Concept Highlights
    • Similar split of responsibilities as present but operators activities supported and/or autonomously executed by ‘automation’ tools
    • Clear split between preparation, planning and execution
    • Central system responsible for planning, scheduling and M&C operations execution of shared resources
    • Mission dedicated systems for the planning and execution of spacecraft operations and related control center systems operations
    • Loose coupling between central and mission dedicated systems.
  • System Context for Operations Automation Status Messages S/C Timeline Schedule (SCTS) S/C Pass Schedule (SCPS) Mission Automation Planned Schedule (MAPS) EMS FDS Predicts and Radiometric data Mission Planning Data Monitoring and Control Data TM and TC Data Ground Resource Planning Data TM and TC Data Control System Monitoring and Control Data + SCTS and SCPS G/S Schedules (GRSS)+ Service Instance Configuration Files (SICF) Service Instance Configuration Files (SICF) TM and TC Data Procedure Definitions Control System and G/S Link Monitoring and Control Data + SCTS, SCPS and MAPS + Status Messages G/S Link Monitoring and Control Data MPS MPS SMF SMF Status Messages S/C Timeline Schedule (SCTS) S/C Pass Schedule (SCPS) Mission Automation Planned Schedule (MAPS) NIS NIS MAS MATIS EMS STC STC FDS G/S G/S MCS MCS Predicts and Radiometric data Mission Planning Data Monitoring and Control Data TM and TC Data Ground Resource Planning Data TM and TC Data Control System Monitoring and Control Data + SCTS and SCPS G/S Schedules (GRSS)+ Service Instance Configuration Files (SICF) Service Instance Configuration Files (SICF) TM and TC Data MPS SMF NIS MAS STC G/S MCS OPS OPS OPS Procedure Definitions Control System and G/S Link Monitoring and Control Data + SCTS, SCPS and MAPS + Status Messages G/S Link Monitoring and Control Data
  • ESTRACK Management System (EMS) Overview EMS File Server ESTRACK Planning System ESTRACK Scheduling System ESTRACK Coordination System Planning Products ESTRACK Ground Station Communications Network Management Mission Operations Centre EMS User Flight Dynamics Mission Planning External Provider (scheduling office) Proxy Format Converter Planner MMI Online MMI EMS Operator Positions SMF
  • Network Service Allocation EMS User EMS Event Files Initial EMP View Order Refinement Updated EMP View Service Session Commitment Final EMP View Service Session Refinement
  • ESTRACK Planning System (EPS)
    • Creates resource allocation plan for ESTRACK
    • Models stations resources
    • Input based on mission agreement on station availability (I.e. standing order)
    • Flight Dynamics prediction used to determine when mission have station visibility
    • Mission can submit refinement requests
    • Output conflict free resource ESTRACK Management Plan (EMP)
  • ESTRACK Scheduling System (ESS)
    • Input is the conflict free ESTRACK Management Plan
    • Generates schedules for use for Station Computer
    • Generates Service Instance Configuration Files (SICF) for use by station equipment and Network Interface System (NIS)
    • SICFs also produced for SLE compliant external facilities
  • ESTRACK Coordination System (ECS)
    • Downloads schedules to station equipment
    • Monitors service provision and schedule execution
    • Control schedule
    • Coordinates possible with MAS via loosely coupled messaging system utilising the SMF
    • Logs events and generates reports
    • Executes EMS Master Schedule From ESS
    • SMF is a service provision middleware infrastructure designed to be generic.
    • Can be tailored to expose the services of different software systems.
    • Scalable and flexible architecture and run time environment.
    • Ensures ‘transparent’ access to a service i.e. independence of underlying implementation.
    Service Management Framework (SMF)
  • SMF exposes services according to ECSS-70-31
    • All services are described in XML files as a tree of System Elements ;
    • Each System Element is composed of:
      • Activities : to initiate actions on the system;
      • Reporting Data : to Get/Set the data describing the status of the system;
      • Events : to notify external user of system changes.
    • SMF provides generic methods to:
      • Initiate activities;
      • Access to reporting data;
      • Register for notification of events.
  • SMF Service Example
    • Extract of S2K TC configuration system element configuration:
    • System Element Name: TcMCConfiguration
    • Description This System Element define services for allowing a external user to monitor and modify the various global parameters affecting the behaviour of commands
    • Activities (name / description)
    • GetGlobalUv : It allows to get the global status of the Uplink Verification
    • ResetGlobalUv : It allows to reset the global status of the Uplink Verification to an OK state
    • ReportingData (name/ description)
    • GlobalUv : Current status of the Uplink Verification (OK or FAIL).
    • Event :
    • ServiceAvailability : Event to inform the external user of a change in the service availability status.
    • GlobalCommandingStatus Event to inform the external user of a change in the Global Command Status.
  • SMF / S2K 5.0 Automation Upgrade
    • External User:
      • Application Software assessing the services
    • Session Manager:
      • User access manager
    • Service Directory System:
      • Central repository of the Services Location
    • Service Request Handler
      • Separation layer from the service consumer and the service provider
    • Driver:
      • Component that allows the access to the services exposed by the Application Unit.
    • Application Unit:
      • Application exposing the services
    SMF Components External User Session Manager Service Directory Application Unit A Service Application Unit B Service Service Request Handler Generic Driver I/F AU Driver AU Driver
  • Mission Automation System (MATIS)
    • Responsible for the automation of operations executed via mission dedicated facilities (‘automated spacecraft controller’)
    • Executes schedules prepared by the mission specific planning system or manually prepared
    • Supports execution of predefined procedures
    • Procedures can initiate any action ‘published’ by the control center systems (e.g. S2K+NIS) via SMF
    • Implementation based on S2K low level services and Vitrociset product ASE (schedules/procedure execution engine)
  • MATIS Preparation Environment
    • Allows user to create/manipulate a Mission Automation User Schedule (MAUS)
      • Intended to be used for ‘standing orders’ that always apply (e.g. produce daily printouts)
    • Provides facilities for importing/validating a schedule generated by the Mission Planning System
    • Provides facilities to import Procedures defined by the Operation Preparation System (MOIS). No capability to create/edit procedures
  • MATIS Execution Environment
    • MATIS will support the execution of schedules containing procedure execution requests, events and links between them
    • Multiple schedules may be running at a time and schedules may contain parallel executing procedures
    • MATIS will support the execution of procedures defined according to the PLUTO standard syntax
      • Either ‘called’ by a Schedule
      • Or manually loaded by the user
    • Interaction between the various schedules/procedures will be possible
    • User control of schedule/procedures execution possible via Graphical User Interface .
  • MATIS Execution Layers LAYERS MAPS and MAUS Scheduling, Standing orders MAPS and MAUS execution, Task scheduling, Event check point management Procedure execution, Activity initiation, Contingency handling External services invocation, external event handling 1 2 3 4 1: MAPS Mission automation planned schedule 2: MAUS (mission automation user schedule) & Calendar Monitoring 3: Schedule execution request 4. Procedure execution, tracing. MATIS MPS SMF FLIGHT CONTROL TEAM Calendar Management Schedules Management Procedures Management Activities & external events Management
  • MCS Infrastructure Upgrades for Automation
    • The SCOS-2000 kernel (R5.0) and the NIS (R1.0) will enable access (via SMF) to all functions required for automation
    • The EGOS Data Dissemination System (EDDS) will support services enabling tools ‘á la MUST’ to access data required e.g. to automate the routine operations planning and/or the reporting
    • A new application (MATIS) will be ‘developed’ supporting automated execution of schedules and procedures (accessing SMF services)
  • MCS Infrastructure Target Architecture EGOS Framework (Basic Services) Common Libraries Events Logging Service Directory Configuration Management Others Others Common Services Archive Users System M&C Alarms User Desktop Others TM/TC Processing Components TM Servers TC Servers NIS Client applicat. Others Ancillary Systems MATIS EDDS ECS GUIs SMF Driver Driver Driver Driver Driver
  • Towards the Target Architecture MCS Framework (S2K-R5.0 Basic Services) Ancillary Systems MATIS EDDS ECS TM/TC Processing Components TM Servers TC Servers NIS Client applicat. Others GUIs SMF Driver Driver Driver Driver Driver
  • Developments Status and plan Q1/2008 RFP out in Q4/2006 ECS Q3/2007 RFP ongoing ESS Q2/2007 Requirements Definition EDDS Q2/2007 Design ongoing MATIS Q4/2006 Development ongoing EPS Q4/2006 Development ongoing S2K-R5 Q2/2006 Development ongoing NIS Available Provisionally accepted SMF PA Delivery Status Product
  • Issues
    • Automation requires upfront ‘investment’!
    • No infrastructure available in the medium-term in the area of Mission Planning Systems
      • Missions will have to develop their own interfaces to EMS/MATIS
    • Will other systems (e.g. FDS) adopt SMF?
    • The infrastructure commitments/plans are very ambitious!
  • Conclusions
    • Flexible concept has been developed
    • Covers shared and mission dedicated resources
    • Will allow gradual increase in the amount of automation as products are delivered and procedures are defined and debugged
    • Extendable to cover most of the elements in the ground segment
    • Ambitious infrastructure development plan!
  • Thank you for your attention. Questions ?