NeX: A step by step approach to automation

1
NeX A step by step approach to automation

D. Evans, EUTELSAT SCC Operations Manager EGOS
2005 Workshop 8-10 November 2005, ESOC, Darmstadt
2
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

3
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.

4
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.
• 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.

Automated Execution System
Control System
5
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.

6
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 dont restrict its use to automated ops only
• SUMMARY
• Dont change a successful operations concept -
  automate it !

7
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
AUTOMATION REQUIREMENTS
STEP TYPE ..
STEP TYPE N
8
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.
9
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 ESAs 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 EUTELSATs
  requirements this was always done on the
  principle that no existing functionality should
  be lost.

10
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.

11
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

12
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
13
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
verifier
TC HF
TC Hist Display
14
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.

15
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.

16
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 dont 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.

17
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.

18
(No Transcript)