Title: Common EGSE and MCS for ESA Herschel Planck Missions
1Common 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
2Introduction
- 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
3RATIONAL
- 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.
4H / P Ground Segment Centres
5Smooth 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).
6HERSCHEL GS SMOOTH TRANSITION
7Smooth 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.
8Commonality 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
9SCOS 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.
10SCOS 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.
11SYSTEM CONTROL AND DATA FLOWS
12SCOS 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
13SCOS 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
14SCOS-2000 KERNEL DECOMPOSITION
15SCOS 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.
16H / P MISSION OPERATIONS CENTRE
17H / 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.
18CONCLUSIONS
- 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.
19CONCLUSIONS
- 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.