Ground Control Means for Satellite Automated Operations: Thales Alenia Space Experience

Transcription

1 SpaceOps 2010 Conference<br><b><i>Delivering on the Dream</b></i><br><i>Hosted by NASA Mars April 2010, Huntsville, Alabama AIAA Ground Control Means for Satellite Automated Operations: Thales Alenia Space Experience Pierre-Yves Schmerber 1 Thales Alenia Space, Cannes, France Thales Alenia Space has been working in the past years on evolutions of its control center product to support operation during office hours concept, and fleet operation automation. Evolutions were identified to better structure the monitoring rules to be able to adjust reactions to alarm severity, and to systematize error handling in procedure execution. In parallel, a need for a control center open to extensions in size as well as functionalities was deemed necessary to handle heterogeneous fleets of satellites. The new product release named Open SCC (Operation Environment for Space Control Centers) is thus based on open standards and collaborative software modules, among which a Satellite Control Operation Preparation Environment extended with plug-ins to adapt to every structured operational data, Planning and Scheduler applications to automate computation and implementation of the complete schedule of operations, and a TM/TC/Event server to automate telemetry and logbook analysis, and to provide standard access for extensions. Open SCC has been used to develop the control centre for new constellations of LEO satellites, including the control of the previous constellation during the transition period. This experience where complete automation of routine operations for the constellation was implemented, has contributed to adjust the tools to real demanding operation needs. A first return from experience is it takes time and hands on practice by actual operators to adjust tools for smooth follow-up of many automated operations. I. Introduction Thales Alenia Space has developed since 1990 products for satellite control centers [1], at first dedicated to its SPACEBUS geostationary platforms, and to the control of one satellite at a time. These solutions were well adapted to internal operation engineers teams, that work on one satellite, with 24/7 presence in the control room. These products evolved rapidly to isolate platform and satellite dependant data from the generic software, and to bring some automation capacities; automation was used for ground repetitive tasks, and for automatic execution of ground equipment configuration procedures, while satellite procedures were still followed step by step by the operators. A further step was reached when the same software products were used on LEO platforms during assembly and integration tests and during on orbit operations, with automated execution of procedures that mix ground and satellite operations. In 2002, Thales Alenia Space started its WHO study [2] that aimed to optimize on orbit control operations of a geostationary telecom satellite so that the presence of operations team in the control centre could be reduced to Working Hours. This study identified a need for an improved monitoring and alarm system based on a structured and multi-levels limits definition tree. The new definition allows to switch whole subsets of monitoring conditions according to the conditions found on their mother node, and so to better manage monitoring changes according to the mode of satellite subsystems or equipments. The existing reflex mechanism allowing to launch specific actions when action limits exceed is confirmed was also extended to adapt automated actions to the alarm severity when sets of parameters are concerned. The WHO study also identified needs for operation procedures evolution, to take into account the possibility of scheduled execution out of operator presence: each procedure has to define how to recover or react to failures in much more detail than before. 1 Industrial Unit Ground, Thales Alenia Space, 100 bd du Midi, BP99, Cannes La Bocca, France. 1 Copyright 2010 by Thales Alenia Space. Published by the, Inc., with permission.

2 At the same time, our customers were controlling more and more satellites simultaneously, possibly coming from different manufacturers, with a need to optimize their operations while reusing their assets. It was necessary to open our control centre products to standards, so that they could be easily extended after delivery, either for the addition of new satellites, or for the addition of software such as external COTS or interface with proprietary systems. It was also necessary to provide a multi-satellite system, with improvements in satellite data management, in operator interface to select, mix and switch between satellites, and in operator access control to manage access rights to satellites while allowing shift of operators on the running system. II. Different Levels of Automation Adding automation in satellite operations simplify the day to day work, but adds complexity in the ground system. All tasks require manual activation when there is a doubt on the automated process behavior. Tasks foreseen to be manual may prove to become routine and good candidates for automation. Moreover, it is easier to build trust in a less automated system at first, and to raise operation automation progressively as experience with the system grows. In order to allow progressive automation, and to manage its complexity, we found it best to work with three different abstraction levels. A. Monitoring automation Satellite and ground telemetry monitoring is classically performed against double sets of thresholds: a minimum and maximum threshold to detect warning conditions, and a minimum and maximum threshold to detect action conditions. Default action is to raise an alarm, but other actions can be defined to take urgent measures (such as starting an operation procedure, or putting a GSM phone call to on-duty operators). To allow automatic change of monitoring thresholds when there is a change in the operation mode, it is possible to select the set of threshold to apply according to a validity condition computed from the telemetry, derived parameters (changed by a computation rule), or operator parameters (change by the operator or by an operational procedure). So monitoring rule selection could be selected automatically. However, with the growing complexity of on board automation, validity conditions became difficult to define and manage, as they had to take into account all the modes of operation that affect each monitored parameter. So to take into account global modes that affect many parameters (like mode of operation at system or subsystem level), a tree like organization was defined for monitoring rules, with validity conditions on nodes, that select the applicable branch holding the sub-tree of applicable monitoring rules. The WHO study has shown that when there is an anomaly, many parameters usually go in alarm, as there are links between the satellite parameters. When reaction needs to be automated to cope with unmanned situations, it is then necessary to adapt the reaction to the set of parameters in alarm, or to the number of alarms detected in subsets of related parameters. With the tree of monitoring rules, parameters are already organized in subsets affected by the mode of operation, with more global modes at higher level. So reaction at global level can be defined on the nodes of the monitoring tree, to react at the level of the mode of operation affected by the alarms detected on parameters that it controls. A capacity to test the number of alarms on each monitoring node within a reaction procedure is also needed in addition to the usual capacity to test the status of each parameter, to properly select the applicable operations in case of global reaction. B. Procedure automation Operation procedures were first written to guide controllers in satellite operations. The language used was then standardized to enhance reuse between satellite programs, and to allow satellite telecommand sending without manual copy. To enhance execution of procedures by the computer under operator supervision, check expressions and program structure was added to specify in the procedure how it should adapt itself to its operating environment, but questions to the operator were still part of the procedures, typically when decision had to be taken in case of unexpected results. For procedures that are designed to run automatically, without controller supervision, instructions to react to unexpected results must be included; this can be done with a continuation test as specified in the European standard for satellite operation procedures [3]. The reaction to the procedure result, be it a success or a failure, has to be taken by the calling environment, that can be another procedure or another application like the monitoring reaction system or the scheduler system. From procedures, it is possible to wait for events to appear, to mix ground equipment control with satellite operations, and to check parameter values to verify conditions. allow to automate any tasks that can be performed by a controller within the control centre, possibly initiating GSM calls to the on-duty controller when supervision is needed. 2

3 C. Schedule automation A schedule is a convenient abstraction to organize complex system operations, where activity synchronization and resource allocation are described. In the following text we will use the term planning for the preparation of the operation schedule, and schedule follow-up for dynamic execution of an existing schedule. Automated planning involves optimization of activity placement in a schedule, in relation to constraints on resource availability, and time and event synchronization. The first step in schedule automation was to allow automatic execution of time scheduled tasks, with manual preparation of a schedule compatible with all constraints. In the frame of the Skybridge constellation study, we identified two needs for engineers assistance in operation planning: first to select the most appropriate visibilities for satellite monitoring and control among all possibilities, and second to propose schedules compatible with resource availability and operation constraints. We also identified the interest to build the operation schedule from generic schedule elements, where activities representing sets of related tasks are synchronized on events rather than fixed time. Two types of events are considered in the schedule: timed events whose time of occurrence are known at planning time, and asynchronous events that may be raised by monitoring, by procedures, or by the schedule execution itself. Tasks are indivisible elements with duration that can be executed by the system; they match typically operation procedures. For coherence, a single master schedule should be planned for the system, however, schedule execution may have to be distributed between different sites and teams. We considered split operations where the system is split in distinct sets of satellites and stations, each set controlled by a different site and team, and shift operations where the site and team in charge of constellation control hands over the whole constellation control to the next site and team. Both operation modes are required to cover actual operations during a constellation lifecycle. III. Open SCC Control Centre The Open SCC software is designed for compatibility with international CCSDS standards and with European ECSS standards. It implements the CCSDS TM/TC protocol with COP-1 retransmission algorithm following ECSS standards for telemetry [5] and telecommand [6], it supports the European packet utilization standard [4], and it complies to the European satellite operation procedure standard [3]. The Open SCC roadmap foresee further support of operation services specifications from the CCSDS Satellite Monitoring and Control group [7], and of interface recommendations from the European Technology Harmonization on Ground System Software group [8]. The Open SCC Control Centre is based on a clear separation between satellite dependent data and actual kernel software. This architecture allows for a full customization of the Control Centre through a data base and its adaptability to different satellite buses and operator's operational concepts. It further provides on-line flexibility to change processing parameters, alarm levels, interfaces layout and more. The operator has full autonomy for smooth evolution of its system without need for re-compiling or involvement of the Control Centre provider. The choice of well adopted information technologies from the Java Enterprise Edition platform, with message communications between modules, XML files, open standard display description, open standard script language, and standard database access to archives allowed to bring adaptability in the Open SCC Control Centers. The software is made of a set of collaborating modules distributed over a network, completed by configuration data, so that it can be easily adapted or extended to interface an existing system, to deploy on new hardware, to add functionalities, or to control new satellites. This modular and distributed architecture is also well adapted to redundancy deployment to build highly reliable solutions. The Open SCC modules are all designed to offer a standard control interface allowing complete automation of their available actions through remote management. The Satellite Control Operation Preparation Environment is designed to federate all operation preparation tools, and to allow collaborative preparation of operational data for fleet of satellites, while keeping consistency with manufacturer provided satellite database. The choice of an Eclipse Rich Client Platform environment extensible with plug-ins proved to be very well adapted: it allows to provide ergonomic tools with a common access to the satellite databases and a proven configuration management plug-in. The initial development includes tools for preparation of operation procedures, derived parameter definitions, monitoring rules, and telemetry displays. After first deployment of the SCOPE environment for use by operation engineering teams, we made extensions to On Board Control Procedure and On Board Event Sequence preparation, that are smoothly integrated thanks to the plug-in mechanism of the platform. Today the flexibility and adaptability of the SCOPE software makes it one of the best basis for collaboration in operation preparation within Thales Alenia Space. 3

4 The Open SCC schedule planning software is designed to assist fly-bys selection according to satellite priorities and antenna availabilities, and to assist activity allocation in schedule according to their constraints. The list of all possible fly-bys is computed from the flight dynamics software, while the list of activities with their instantiated constraints is provided by the mission center for mission operations, and by the control center for maneuver and contingency operations. Activities are taken from an activity catalog that is part of the operational data, where the generic activities are listed with their associated description and constraints. Instantiation of an activity consists in providing values to the variables used in its generic description. The planning software allows to adjust the inputs and to check the results through Gantt displays that can be filtered by satellite or antenna resource. Schedule continuity and split operations are taken into account by the planning software when building the master schedule. Shift operations are handled by a synchronization message between the schedule execution software, so that the ending scheduler finishes all currently active tasks, while the starting scheduler only activates the new tasks. The schedule execution core is built from a generic job scheduling system, where graphical user interface clients connect to. The controller user can interact with the schedule through lists of tasks with their running status, or through a Gantt representation of activities. The schedule execution core starts tasks according to their trigger information. Each task contains an activation message and its logical destination resource. A directory for the dynamic allocation of applications in charge of each resource is maintained in the control centre, so that the schedule execution core can send the activation message to the right application. The schedule execution core follows task progress according to return events received from the application. Daily Plan Files Daily Plan Files Daily Plan Files Planning Activity Catalog Flight Dynamics Data Files Data Files Data Files Schedule Execution Execution Monitoring Core Figure 1. Open SCC Automation. Master Schedule Monitoring Rules Operation Preparation The Open SCC Procedure Execution software can work either in automated mode or in manual mode. In automated mode, procedures are loaded and started from external applications for fully automated execution, while in manual mode, procedures are loaded and started by the controller, who can select to how to execute them, and has the possibility to add breakpoints and to interrupt execution at any moment. can mix satellite commands with telemetry checks, control instructions, ground station commands, or any action on the Open SCC applications. The procedure execution software displays the sending status of all satellite commands as they are acknowledged in the successive transmission steps. It also includes a display of the on board stack to follow the execution of timetagged commands. The Open SCC monitoring core is coupled with an alarm management server to process all telemetry and events in the control centre. It raises events according to the tree of monitoring rules, and implements the reflex automation to start any action on the control centre. Event notifications can be caught by the scheduler to synchronize activities, and used by procedures to adapt their behavior. The monitoring core acts as a telemetry and event server for both real-time and archived information of all satellites and stations, and is used to automate processing of registered telemetry received delayed from the satellites. It is interfaced with a monitoring display Displays Monitoring Display 4

5 application where the controllers can follow constellation status and satellites telemetry through animated displays, manage alarms in the control centre, and process multi-satellite reports on archived data. IV. Constellation Experience The Open SCC product was in its last development steps when we started the actual development of a control centre for a constellation of 56 satellites. As it was the first time that we had to deliver a control centre for so many satellites, with a need for complete automation of routine operations, we identified two major risks linked to performance and to operation concepts. We made numerous iterations in a closed loop teamwork with our customer on his operation concepts, and thought to have taken a good picture of them in our requirements when we reviewed the graphical user interface. Resource optimization studies led to an optimized hardware architecture where processing switch over satellites according to fly-bys. This optimization was extended to the man-machine interface, where a managed satellite mode was added to multi-satellite displays to allow automatic switch between satellites when they come in and out of visibility. The data management of the Open SCC product was improved to manage similarities and specificities between the different satellite databases, and also to keep synchronization between procedures and databases used for each satellite according to the software upload status. The Open SCC automation concepts were put in practice, with complete automation of routine operations while keeping manned operation preparation and manned planning for conflict solving. The separation of automation in three distinct levels proved to be very effective for automation testing, and for progressive automation of operations. For example, an engineer can prepare controlled operations for a satellite, then put them in a daily plan for automated planning and scheduling on satellite fly-bys, that will automatically open the operation procedure on the controller workstation for controlled execution when the satellite is in visibility, while monitoring automation remains active to raise alarm in case of unexpected satellite behavior. At the beginning of the project, it was decided that the control centre should control the existing generation of satellites during the transition period needed for the deployment of all new generation satellites. So we took this opportunity with our customer, to perform on the job evaluation of the control centre applications through early deliveries for the existing satellites. Through these evaluations, we discovered many missing behaviors, that were not foreseen in the initial capture of the operation concepts, and that led to later upgrade release deliveries. As usual for performance, real conditions proved to be more demanding than simulated situations, but solutions were eventually found to reach the performance objectives. We also encountered satellite program delays that forced to postpone the validation of the control centre for the new generation satellites, and left fortunately more time for experiment and improvement with the existing satellites. V. Conclusion Even with a product designed for satellite operation automation and fleet control, it took time and involvement of actual operators to smooth the operation of the automated system for a full size constellation: the more automation we add to the system, the more adjustment possibilities we have, and the more time and experience it takes to select the best tuning. The Open SCC is now operational for the control of a LEO constellation of up to 56 satellites, and waiting the launch of the new generation satellites that will replace the old constellation in orbit. We think that the future of geostationary operations will go toward the same automation tools as more and more operators may wish to unify the operation of their growing fleets of satellites. 5

6 Appendix A Acronym List CCSDS Consultative Committee for Space Data Systems COP-1 Communications Operation Procedure 1 COTS ECSS LEO SCC TC TM W3C XML Planning Eclipse Commercial Off The Shelf Software European Cooperation for Space Standardization Low Earth Orbit Satellite Control Centre Tele Command Tele Measure World Wide Web Consortium Extensible Markup Language, open standard from the W3C Appendix B Glossary The schedule preparation activity Open source software development environment References [1] Chautard, J.C., Ten Years in Satellite Control Centers Domain: a Return of Experience, SpaceOps Conference, 2000 [2] Moffelein, L., WHO - Working Hours (for) Optimized Operations of geostationary telecom satellites, SpaceOps Conference, 2006 [3] Test and operations procedure language, ECSS-ST-E-70-32C, ESA ESTEC, Noordwijk, The Netherlands, 2008 [4] Ground systems and operations Telemetry and telecommand packet utilization, ECSS-E-70-41A, ESA ESTEC, Noordwijk, The Netherlands, 2003 [5] Space data links Telemetry transfer frame protocol, ECSS-ST-E-50-03C, ESA ESTEC, Noordwijk, The Netherlands, 2008 [6] Space data links Telecommand protocols synchronization and channel coding, ECSS-ST-E-50-04C, ESA ESTEC, Noordwijk, The Netherlands, 2008 [7] Mission Operation Services Concepts, CCSDS G-2, NASA, Washington, DC, 2006 [8] Peccia, N., European Technology Harmonization on Ground System Software, SpaceOps Conference,