NeX: A step by step approach to automation
D. Evans, EUTELSAT SCC Operations Manager
EGOS 2005 Workshop 8-10 November 2005, ESOC, Darmstadt
Contents
Why automate operational execution ? The classic approach to automation
An alternative approach
How NEO has helped NeX: Putting it all together NeX: Creation of the new automation functionality NeX: Reuse of the NEO command and verification chain NeX: Fast and flexible NeX: The checklist CONCLUSIONS
2
Why automate operational execution ?
Currently 18 satellites of six different designs are being controlled from the Eutelsat SCC.
Two more are under construction and a further two are planned to be launched in 2008.
The controllers are responsible for the real-time control of 5 TCR sites and the mission control system itself, in addition to the execution of spacecraft flight procedures.
3
The classic approach to automation
The classic approach to automation is to develop a tool which is external to the control system. This then “plugs in” to the control system to access TM and TC functionality.
Automated Execution System
Control System
EUTELSAT has successfully used such a system (called PAROS) to automate some critical routine procedures (e.g. stationkeeping). The experience has been invaluable in assessing the strengths and weaknesses of such solutions.
4
Advantages and disadvantages of being classic
The approach works but not for all procedures or situations:
>
It is not suitable for rapidly changing situations. Both the automatic procedure and the manual procedure have to be maintained and deployed in parallel. It works best for operations that have a defined beginning and end. It is not suitable for operations which involve continuous monitoring and automatic reactions in case of events.
>
Also there are less obvious issues that should not be underestimated:
>
The transition between a procedure being executed automatically and manually can cause problems
>
The controllers experience a “detachment” from these operations. This MUST be mitigated.
5
An alternative approach: the golden guidelines
In March 2003, EUTELSAT Operations Staff began an assessment of several approaches for automation for an initial application to procedures requiring continuous monitoring and command execution, and for which PAROS was not well suited. The “golden” guidelines were drawn up:
> > > >
Use only one procedure for automated and manual ops Minimise any changes to existing procedures
Do not introduce extra complexity
Provide just the required level of functionality and don’t restrict its use to automated ops only
SUMMARY: Don’t change a successful operations concept - automate it !
6
The procedure is the key
Since two of the four golden guidelines were referring to the procedures it seemed clear that this was the place to start:
>
EUTELSAT procedure content had already become highly structured following the implementation in 2001 of a “procedure styleguide” This precisely describes the content of each step type in a procedure and limits all procedure content to only those step types. This critically bounded the requirements analysis.
STEP TYPE 1 EUTELSAT PROCEDURE STYLEGUIDE STEP TYPE 2 STEP TYPE .. STEP TYPE N AUTOMATION REQUIREMENTS
>
7
Finding the overlapping requirements
The analysis revealed that at the lowest level there was a large requirement overlap between many of the step types. In particular all the TM Check type steps (e.g. CHECK, VERIFY, WAIT FOR, MONITOR etc) and all the control structure steps (IF, IF(NOK), CASE etc) share the underlying common function: They wait for a condition to become TRUE or FALSE for a bounded period. If the condition is not met in this period then they return the opposite value. Also it was realised that this function could be relatively easily automated by extending an automatic TM checking concept that EUTELSAT has employed successfully for many years.
8
How NEO has helped
However we still needed an environment in which all the individual steps could be brought together to form a procedure. We started looking at NEO, our new SCC control system.
The NEO (New EUTELSAT Open) satellite control system project was started in March 2002.
> > >
It is based on ESA’s SCOS 2000. We are presently using it to control one satellite. The majority of the fleet will be migrated to use it within one year.
Although many S2K subsystems have been modified to customise the control system to EUTELSAT’s requirements this was always done on the principle that no existing functionality should be lost.
9
The NEO command stack
On examination, the NEO command stack had a wealth of existing functionality that was exploitable:
> > > >
Sequential commanding Absolute and relative release times Interlock Wait mode We realised that this formed the basis of automatic command execution.
10
NeX - Putting it all together
The NeX (NEO eXtended capabilities) project was started in April 2005 The contract was awarded to GMV, Madrid. It is scheduled to become fully operational in March 2006. The main aims are:
>
Creation of new automation functionality modules directly related to specific procedure steps
>
The integration of this new functionality into the system by the reuse of the NEO command and verification chain
The control and visualisation of the procedure execution by the reuse of the NEO command stack and its present automation functionality
>
11
NeX - Creation of the new automation functionality
Several modules have been designed: The most significant are:
>
Automatic TM checking function Automatic updating of TC parameters based on “constants” Automatic updating of “constants” based on set values or TM values
SET VALUES TM PARAMETERS CONSTANTS TC PARAMETERS
>
>
12
NeX - Reuse of the NEO command and verification chain
NeX reuses the existing system as much as possible
NeX commands New Automation Functionality Module
Command Chain
cmd stack
mux releaser
Verification Chain
TC Hist Display
TC HF
verifier
13
NeX - Fast and flexible
The application of classic spacecraft command philosophy to automation functions will enable operations staff to maintain control over the automation system. This lowers cost and makes the system highly reactive.
>
The underlying automation modules are controlled using parameters which are passed to them as TC parameters. The NeX commands are completely database driven including the associated automation module, parameter defaults and command stack behaviour/appearance. The same functionality module can be used for many different procedure step types. Therefore adding a new command is a simple as a database update.
>
>
14
NeX - The checklist (1)
>
Use only one procedure for automated and manual ops Procedures will be issued with corresponding command sequences that contain the spacecraft commands PLUS the NeX commands that automate all other steps. The transition between manual and automatic operations therefore just involves deleting the NeX commands.
>
Minimise any changes to existing procedures
NeX is based on the existing procedure styleguide. Very few changes are required to implement it. 99% of a procedure can remain as now.
>
Do not introduce extra complexity As NeX is based on extending existing functionality it requires no new machines, interfaces and very little in terms of new MMIs.
15
NeX - The checklist (2)
>
Provide just the required level of functionality…. Again since the requirements were derived from the procedure styleguide they address everything that a procedure requires and no more. ….and don’t restrict its use to automated ops only Most of the automation modules can be accessed directly from the MMI. Also the step by step nature of NeX gives us the possibility to use the functionality only for very specific steps of a procedure. This can be used to secure a particularly error prone operation (such as TC parameter editing), or to automate laborious tasks and reduce overall SCC workload.
>
16
CONCLUSIONS
>
The classic approach to automation using an external system works but it is not applicable for all situations. Therefore it is important to choose very carefully what you automate in this way. Our experience is that for many real world situations the concept of an external automation system is not ideal, in particular when continuous monitoring and command reactivity is required. We are convinced this means the integration of a certain level of autonomy into the control system itself. We believe that NeX is a innovative solution and will go some way to providing this. We hope that ESA will continue to improve SCOS 2000 in this direction.
>
>
>
>
17