Migration of the XMMNewton Mission

1
Migration of the XMM-Newton Mission Science
Operations Centre Systems to SCOS-2000

• Dr. Matthew Couch
• XMM Migration Project Manager

2
Introduction

• LogicaCMG is currently migrating to SCOS-2000,
  the SCOS-1 based components of the XMM-Newton
  Mission Operations Centre (MOC) based at ESOC,
  and the Science Operations Centre (SOC), based at
  Vilspa near Madrid
• This presentation outlines the different
  techniques which have been employed to perform
  the migration of these systems

3
Overview 1

• Brief Outline of XMM-Newton
• XMM-Newton Mission
• Features implications for ground segment design
• History of LogicaCMG involvement
• Ground Segment Architecture
• Reasons and benefits of migration
• Different migration approaches
• Data Migration
• Functional Migration (use of SCOS-2000 or reuse
  of existing systems)
• Code Migration

4
Overview 2

• Where we are now
• Lessons learned / whats required
• Summary

5
XMM-Newton Mission 1

• Observatory type mission used for X-ray astronomy
• Telescope tube of concentric cylinders focus
  x-ray light on to instrument detectors
• Launched in December 1999 on Ariane 504
• Operates in highly elliptical earth orbit to keep
  out of earths radiation as much as possible
• In permanent ground contact through ESA ground
  station network

6
XMM-Newton Mission 2

• Observation requests submitted via Internet which
  are scheduled at the XMM-Newton Science
  Operations Centre (SOC) at Vilspa (ESAC!)
• Planned operations schedule sent to XMM-Newton
  Mission Operations Centre (MOC) at ESOC
• Generated schedule of commands required to
  configure payload and re-point satellite are sent
  in real-time from ground based schedule running
  at the MOC
• All telemetry forwarded in real-time from the MOC
  back to the SOC where it is processed and
  products generated

Mars as seen by XMM-Newton
7
Features of Ground Segment Design

• Permanent ground contact mission with ground
  based schedule high level of availability
  required
• MOC SOC split site (Darmstadt/Madrid)
  requires a reliable RT link, consistent software
  and consistent database
• Science data processed and products generated in
  real-time

8
XMM-Newton Ground Segment Architecture
TM/TC
ESOC Darmstadt - MOC
GS Network
XMM Satellite
SCOS-1 ? SCOS-2000
- Real-time Telemetry 80kbps - TC History
records
Mission Planning Files
Science Products
VILSPA Madrid - SOC
Science Community
Observation Requests
SCOS-1 ? SCOS-2000 plus other non-SCOS based
systems
9
History of LogicaCMG Involvement

• LogicaCMG were awarded the original development
  contract (under DPD-5 Frame contract)
• Combined MOC-SOC development using the SCOS-1
  based infrastructure (where appropriate)
• Development started in 1996
• Have provided maintenance of the MOC since then
• LogicaCMG awarded MOC migration to SCOS-2000 as
  part of the GC-6 Frame contract bid
• Final go-ahead delayed but work started in late
  2002
• LogicaCMG awarded SOC migration to SCOS-2000
  under the GC-6 Frame contract
• Work started in early 2003

10
Why Migrate from SCOS-1 to SCOS-2000?

• XMM-Newton mission extension approved could
  potentially run for another 10 years ?
• Hardware Maintainability Issues
• SCOS-1 based MCS software runs on combination of
  aging HP Alpha obsolete SUN hardware
• System Support Issues
• In 10 years, all other ESOC missions will be
  running SCOS-2000 (at least) - a dedicated
  maintenance team would be required for XMM
  outdated skills potentially difficult to find
• Operator training and interoperability
• With ESOC having one common basic operating
  system (SCOS-2000), SPACONs, Analysts, and
  Engineers can transfer more easily across
  missions cross fertilisation of experience
  everyone benefits

11
XMM MOC Migration Approach
12
XMM MOC Migration Approach Use Vanilla SCOS
(1)

• XMM MOC is a relatively standard MCS
  implementation (packet based), lending itself
  well to the use of SCOS-2000
• Majority of MOC functionality provided directly
  by SCOS-2000
• Once initial converted database was in place,
  basic XMM TM could be processed and TCs sent,
  without code modifications
• Much of the XMM functionality, custom written for
  the SCOS-1 MOC is already provided by SCOS-2000,
  e.g.
• REPEX (Report Exception) display ? OBEH
  (OnBoardEventHistory) display
• Packet Dump Display ? TMPH (TM PacketHistory)
• Timeline Controller/scheduler ? Release based
  Autostack

13
XMM MOC Migration Approach Use Vanilla SCOS
(2)

• Thus able to start with vanilla SCOS-2000
  evolution and modify to meet much of the more
  specific existing MOC functionality
• In particular, this approach was used for
• TM processing (mainly changes to generic
  packetiser) to allow
• specific TM quality checks
• Packet declustering
• Datastream determination
• Time correlation
• TC chain
• Configuration (e.g. splitting acceptance/completio
  n verification global sub-sys control)
• Extensions to TTAG (on-board queue) model/display
  to allow TM report comparison
• Extension of Autostack to include real-time
  rescheduling

14
XMM MOC Migration Approach Use Vanilla SCOS
(3)

• Approach also applied to On-board Software
  Maintenance (OBSM) subsystem
• Majority of functionality provided by SCOS-2000
  mission specific device implementation required
  Integral MCS implementation used where
  appropriate

15
XMM MOC Migration Approach Non-SCOS-2000
Subsystems

• Other subsystems not provided by SCOS-2000
• File Transfer System
• existing UNIX based version of XMM system reused
  directly (scripts rewritten for UNIX)
• Mission Planning
• No MPS functionality provided by SCOS-2000
• Reused Integral MCS mission planning
  architecture simplified and then relatively minor
  modifications required the mission planning
  concepts for XMM and Integral are identical and
  the input file formats virtually identical
  (EPOS/APF)

16
XMM MOC Migration Approach Derived Parameter
Processing

• Over 200 existing FORTRAN routines generating 650
  derived parameters (derived from mainly raw
  telemetry input)
• SCOS-2000 hard coded synthetic parameters are
  implemented in quite a different way to SCOS-1
  derived parameters and would not be suitable
• Derived Parameter Server (DPS) developed for XMM
  (replacing SCOS-2000 SPPG)
• Existing FORTRAN routines called on arrival of
  triggering packet (SCOS-2000 is triggered on
  parameter values)
• Multiple derived parameters output from routines
  permitted (not the case in SCOS-2000)
• Intermediate values stored allowing averaging
  type derived parameters
• Individual routines may be switched on/off via TM
  Spacon constants
• Derived Packet generated for each triggering
  packet (eg 1001.AC1 ? 1001.AC1D)

17
XMM MOC Migration Approach Database Conversion 1

• Existing SCOS-1 database stored in Oracle tables
• 15,000 telemetry parameters in 1,400 telemetry
  packets
• 1,000 calibration curves
• 1,100 TM OOL plus 300 fixed status checks
• 4,200 TC parameters in 3,600 Telecommands
• 1,700 TC sequences and 1,400 event designators
  (high level sequences)
• 680 Alphanumeric, 600 graphical and 130 scrolling
  TM displays
• Converted into text files complying to the
  SCOS-2000 format using ProFORTRAN routines
  running on VMS system
• Mapping of SCOS-1 to SCOS-2000 database objects
  straightforward at high level, though many low
  level details need to be considered to replicate
  SCOS-1 functionality

18
XMM MOC Migration Approach Database Conversion 2
Mission planning

• Database conversion complications
• XMM use of nested TC sequences (and the need to
  preserve this structure) along with the need to
  use SCOS-2000 formal parameters to update TC
  parameters from MPS, has led to a complex and
  large SCOS-2000 database, with much information
  needed to be repeated

TC1 P1 P2
S1 FP1 FP2
S1 P1 P2
TC2 P1 P2
P3 P4
FP3 FP4
TC3 P1 P2
S2 P1 P2
S2 FP1 FP2
High level Seq formal params
Low level Seq formal params
Command params
High level Seq params
Low level Seq params
19
XMM MOC Migration Approach Database Conversion 3

• MS Access database editors consistency checker
  taken from the CryoSat mission and adapted for
  XMM use
• ASCII files from conversion directly imported
• Many mission specific checks added
• Different way of working the original Oracle
  based database prevented inconsistencies from
  being entered (many complex triggers and
  constraints on tables). MS Access approach relies
  more on post-input constraint checker
• Need to preserve commanding part of legacy
  Oracle database for non-migrated SOC systems (SOC
  mission planning). Editors required to
  down-convert SCOS-2000 back to SCOS-1 format and
  update legacy Oracle

20
XMM MOC Migration Approach Database Conversion 4
MSAccess DB and Editors
SCOS-2000 ASCII
SCOS-2000 ASCII
SCOS-1 to SCOS-2000 conversion
import
One-off conversions
Down-convert Legacy TC DB update
Legacy SCOS-1 Oracle DB
SCOS-2000 MIB
21
Not a face lift
But anyway, the before and after XMCS SCOS-1
SCOS-2000 Desktop
22
Before After TC History ManStack
23
XMM SOC Migration Approach
24
XMM SOC a whole new ball game

• Functionality the SOC is a science operations
  centre and not an MCS
• Telemetry processing facility no TC, OBSM, MPS
  etc
• Telemetry (as well as TC history, time
  correlation information) received over live link
  from MOC
• Science telemetry is handled by processes
  dedicated to each on-board instrument
• Standard FITS files generated leading to ODF
  science output
• Science data processing - doing new things with
  SCOS-2000
• Subject of the migration is the SCOS-1 / VMS
  based components there are other SOC subsystems
  not being migrated here!

25
XMM SOC Processing Chain
Live TM from MOC in DA
House Keeping TM History Files
One per on-board instrument
Instrument Processor
ODS
Science Community
Science FITS Files
Spontaneous TM
ODFs
TM Display

• Consolidated Science FITS
• Housekeeping FITS

26
XMM SOC Migration a different approach

• Use SCOS-2000 based telemetry chain from the XMM
  MOC SCOS-2000 system (mainly packetiser) this
  already gives much of the basic TM processing
  required by SOC
• Migrate Instrument processors, ODS and Support
  processes - non of the required functionality
  provided by SCOS it all sits on top

EPIC IP
ODS
RM IP
RGS IP
SCOS-2000 Environment TM Chain from MOC
27
XMM SOC Migration a code migration

• Leave as much of the original high level code
  (written in C) as possible unchanged this has
  been thoroughly tested over 4 years of operations
• Migrate SOC specific tasks
• SCOS version (1 ? 2000)
• O/S (VMS ? UNIX)

28
XMM SOC Migration Issues

• SCOS, TM/TC DB Interface Layer
• SCOS Console Handler
• SCOS Time Functions
• SCOS Utility Functions
• SCOS Condition Handling, Event Logging and VMS
  Messages
• SCOS Buffer Manager
• SCOS History File Access
• Derived Database
• Oracle interface

• Operating System Interface Layer
• Global Sections/shared memory
• Resource Locking
• Mailboxes
• Timers
• Process and exit handling
• File Handling
• Logical Names
• Byte Ordering
• VMS descriptors

29
Where are we now?

• Delivery of the MOC using latest version of
  SCOS-2000 (version 3.1) recently made
• Final acceptance of the MOC system now on-going
• First delivery of the SOC system (basic
  processing and link functionality) on SCOS-2000
  3.1 recently shipped to Vilspa
• TM tests using live XMM data (HK Science)
  passed through entire system were encouraging
• Main SOC delivery (Instrument Processors, ODS,
  QLA) to be made this summer
• Period of parallel operations planned for end of
  year
• Looking forward to full operations of MOC SOC
  on SCOS-2000 early 2005

30
Lessons Learned / whats required

• Good understanding of the legacy system to be
  migrated
• Existing documentation doesnt cover everything,
  and operators are used to a way of working
  there are many hidden requirements
• A functioning reference legacy system at the
  place where the migration performed
• Access to existing Input Output Data allows
  comparison
• A keen and enthusiastic user community,
  supportive of the migration
• A migration also has great benefits for an OPS
  team in the routine phase

31
Summary

• SCOS-2000 has proven to be highly suitable for
  the XMM MOC, but
• Having not started with SCOS-2000, and the need
  to fit existing operational procedures and
  established interfaces, has led to additional
  complications which would not be an issue in a
  fresh SCOS-2000 development
• SCOS-2000 has proven to be a suitable basis for a
  science ops centre widening the scope of
  SCOS-2000
• Different techniques have been applied across the
  migration to provide a low risk and cost
  effective solution

32
Any Questions?