Common EGSE and MCS for ESA Herschel Planck Missions

1
Common EGSE and MCS for ESA Herschel / Planck
Missions

• Nestor Peccia
• ESA / ESOC / TOS-GI, Darmstadt, Germany
• John Dodsworth, Pierre Estaria, Brian Melton,
  Stephane Veillat, Frederick Wechsler
• ESA

2
Introduction

• Rational
• Smooth Transition across Mission Phases
• Commonality across Instrument level, CCS and MCS
• SCOS 2000 as EGSE / CCS
• SCOS 2000 Kernel and modifications
• Herschel Planck MCS
• Conclusions

3
RATIONAL

• Electrical Ground Support Equipment (EGSE)
• The equipment used to support the Assembly,
  Integration and Validation (AIV) Program of the
  space segment of a major ESA mission (spacecraft
  and instruments)
• Mission Control System (MCS).
• The core of the MOC equipment, which is necessary
  to support the mission operations phase
• The computer systems and the software used for
  the spacecraft / instruments checkout phase and
  for the mission operations phase are normally
  developed separately and used by different groups
  of scientists, engineers and technicians
• On the other hand, many of the functions they are
  required to perform are identical, and a common
  core system can in principle be defined that can
  be used in all these environments.
• The faint border between checkout and flight
  operations for the Herschel / Planck mission make
  it particularly suitable to achieve maximum
  compatibility / commonality between the EGSEs
  (instruments and Spacecrafts) and the MCS.

4
H / P Ground Segment Centres
5
Smooth Transition across Mission Phases

• To facilitate transfer of knowledge and
  procedures, as well as for reducing conversion
  efforts, it is very desirable to have the same
  (or at least a similar) environment through all
  Herschel / Planck mission phases from ILT to post
  operations.
• The commanding and the handling of the test
  outcomes in ILT / IST shall closely resemble the
  final operational environment. The ILT and IST
  set-up should subsequently smoothly adapt into
  the in-orbit phase operations environment.
• Smooth transition between phases means that
• SW development for a given phase can be largely
  re-used in the following phase (software
  compatibility)
• Data collected in a given mission phase can still
  be accessed and processed in the following phases
  (data compatibility).

6
HERSCHEL GS SMOOTH TRANSITION
7
Smooth Transition across Mission Phases

• The basic data flow between the HCSS and these 3
  systems are
• Commands (instrument commands, S/C commands or
  test environments commands) exported from the
  HCSS and
• TM and ancillary data received by the HCSS.
• The data compatibility across phases then points
  to the following
• TM produced by the instruments, the S/C and the
  test environment in ILT and IST follow the ESA TM
  standard format.
• Ancillary data produced by EGSE-ILT, CCS or the
  MOC system, for the same purpose (e.g. TC
  history), has the same content and follow the
  same format.
• This point is guaranteed by the fact that the
  EGSE-ILT, the CCS and the MOC system shall all be
  SCOS-2000 based.

8
Commonality across Instrument Level, CCS and
Control Centre

• As mentioned above there is an expressed desire
  within the Herschel -Planck mission to achieve
  commonality between the systems used for
  instrument level testing, system level testing
  and mission control. This commonality covers
• System hardware
• System interfaces
• Test/Control system software
• Test procedures
• Synoptic pictures / Mimic diagrams
• Onboard Control Procedures (OBCPs)
• System database

9
SCOS 2000 as Instrument EGSE and Central Checkout
Equipment

• SCOS 2000, being designed as a mission control
  system, has the implicit assumptions that the
  satellite is tested and operational, and that the
  satellite database contains all the necessary
  data to be able to control the satellite
• it is fundamentally success oriented.
• Such assumptions are not valid in the test domain
  where the equipment under test may be
  malfunctioned and the database incomplete,
• i.e. a CCS needs to be failure oriented. In order
  to cope with this, some adaptations are needed to
  the basic SCOS 2000 kernel.

10
SCOS 2000 as Instrument EGSE and Central Checkout
Equipment

• To store all unexpected data in the normal way
  for further analysis (rather than dumping it
  outside the main system)
• Be prepared to handle large amounts of warnings,
  especially during the early phases of integration
• A powerful test sequence language must be added
  to the kernel to allow repeatable, automatic
  testing to be performed.
• A further improvement is the runtime control of
  the telemetry parameter definitions (e.g. curves,
  limits, enable state), which is not needed by an
  MCS but is normal within a CCS, where this
  information may be determined empirically.

11
SYSTEM CONTROL AND DATA FLOWS
12
SCOS 2000 KERNEL

• The CCS Kernel is based on ESA's generic
  SCOS-2000 kernel.
• The SCOS 2000 architecture is typical of that
  found in many distributed systems.
• It is comprised of a network of workstations,
  using a client-server paradigm, in which server
  processes provide services to the clients as a
  whole (e.g. database server, archive server).
• The system is scaleable in order to suit
  different missions requirements, budgets and/or
  mission phases.
• Low cost missions used a single workstation for
  each spacecraft whereas the Rosetta / Mars
  Express missions use a system of 4 servers and
  more than 20 client workstations during the
  complex and critical LEOP phase of the missions

13
SCOS 2000 KERNEL

• SCOS 2000 provides the following key
  functionality, possible to be customised by
  client missions
• Archiving, distribution and retrieval facilities
• Telemetry extraction, processing and display
  (e.g. alphanumeric, graphic, scrolling, schematic
  animations (mimics) and variable packet displays
  (PUS)
• Commanding including multiplexing, on-board queue
  model management, command history, auto stacks
  etc.
• Data archiving and retrieval
• Event and action handling (e.g. page support
  personnel, send command etc.)
• User login, roles privileges
• Homogenous high level man-machine interface
• On-board software management.
• Ground station and EGSE interfaces

14
SCOS-2000 KERNEL DECOMPOSITION
15
SCOS 2000 MODIFICATIONS

• Several modifications have to be implemented in
  SCOS-2000 to be used as an EGSE or CCS system
• Database Importer and TM model (e.g.
  enable/inhibit parameters, modification of active
  data definitions according to condition
  parameters, patch active data definitions)
• Raw TC Handling (to implement the capability to
  handle directly raw command, without using the DB
  definitions).
• Customisation of OBSM (to support for managing TM
  dump data from the onboard memories).
• Handling of System Parameters (to allow the user
  to keep under control the CCS behaviour)
• Dangerous Command Handling (to prevent the user
  to send it on board unless the relevant
  "Authorisation command" had been issued)
• Synoptic Picture Subsystem (e.g. Synoptic
  consistency checking, definition of rules to
  graphical elements in order to model element
  dynamic behaviour)Telecommand Verification window
  automatic popup
• Test Session management. The SCOS 2000 packet
  archive shall need a specific approach to manage
  the CCS needs for multiple sessions.

16
H / P MISSION OPERATIONS CENTRE
17
H / P MISSION OPERATIONS CENTRE

• The Central Checkout System will provide the
  following subsystems for the MCS development
  (shown as yellow shadowed in the above figure)
• Database
• Telecommand chain
• On Board Software Maintenance
• Telemetry chain (without the packetiser)
• These subsystems will only be enhanced with MOC
  specific requirements. This approach implies
  lower development costs, lower risks and an
  already validated DB and interfaces.

18
CONCLUSIONS

• At the time of writing this paper
• the Instrument EGSEs are starting to support
  their Instrument Level Tests (ILTs).
• The Central Checkout System (CCS) has finished
  successfully its Preliminary Design Review (PDR).
  
• The Mission Control System (MCS) development will
  start during the second half of 2003.
• A common core system has been defined in the last
  three years to be used in all these environments.
  
• Maximum compatibility / commonality between the
  EGSEs (instruments and Spacecrafts) and the MCS
  has been achieved by agreeing a concept of smooth
  transition across mission phases from ILT
  (Instrument Level Test) to Post Operations.
• This has facilitated the transfer of knowledge
  and procedures, as well as for reducing
  conversion efforts.

19
CONCLUSIONS

• The Herschel / Planck EGSEs / MCS that will
  support this concept is based on ESA SCOS-2000
  and common EGSE (TM / TC routing, automatic
  procedure execution, etc.) infrastructure.
• The benefits gained from using SCOS 2000 are
  twofold
• They are not confined solely to the Herschel /
  Planck missions, but to other scientific missions
  and potentially all ESA sponsored missions
• They offer a better solution in terms of lower
  cost, lower risk, more co-ordinated interfaces
  and improved functionality.