Archive Concept and Products

1
Six Years of On-Board SW Maintenance for
XMM-Newton Instruments Long Life Mission
Challenges and Constraints
Guillermo Buenadicha XMM-Newton SOC OBSM, VEGA
guillermo.buenadicha_at_vega.de OPS-OFX, European
Space Astronomy Center, Spain
Jim Martin XMM-Newton MOC OBSM, VEGA
jim.martin_at_vega.de OPS-OFX, European Space
Operations Center, Germany
Mauro Casale XMM-Newton SOC OSG, ESA
mauro.casale_at_esa.int OPS-OFX , European Space
Astronomy Center, Spain
SPACEOPS 2006, ROME
2
TOPICS

• XMM-Newton Mission
• Instrument SW description
• SW Maintenance
• Concept
• Tools
• History of SW changes
• Some examples
• Lessons learnt

3
XMM-Newton Mission

• Cornerstone Mission of ESAs Horizon 2000
  program
• Launched on December 10th 1999
• Weight 3.8 tons length 10m
• 3 Wolter telescopes with 58 mirrors each plus
  one Optical Monitor telescope.
• 5 X-ray instruments, 3 EPIC cameras and 2 RGS
  spectrometers
• 2 solar panels with 16 meters span
• Telemetry rate 70Kbits/s (HK and Science)

observes objects that radiate in X-ray energies
from 0.2-15 keV
4
Orbit and Coverage
24 hours per day coverage Santiago GS at Chile
replaces Kourou Over 40 hours above the radiation
belts
5
Newton Ground Segment

• Ground Stations (Kourou, Perth)

6
Instruments

• 3 independent CCD-cameras (2 MOS 1 PN)
• 3 different light filters for both camera types
• different modes
• imaging modes - to accommodate brightness
• timing modes - time resolution up to 7 ?s (in the
  case of PN-Burst)
• 2 Radiation Grating Spectrometers (9 CCDs each)
  sharing mirror tubes with the MOS cameras.
• Optical Monitor Camera (OM) with independent
  telescope
• All instruments observe the same field
  simultaneously.

7
EPIC PN SW
EPDH Unit with EDAC for memory access All
memories with ROM image On Board
8
EPIC MOS SW
9
RGS SW
The IC code is kept unmodified in case of switch
off by a keep alive line (KAL).
10
OM SW
11
SW Maintenance Concept
SW MAINTENANCE TOOLS RESPONSIBILITY IT Spares
and one set of the SDEs ESA SOCSIM, one replica
of the SDEs. Control System OBSMS
12
OBSM TOOLS
13
Intrument Spare Chains
X RAY SOURCE
STIMULI SETUP
SC SIMULATOR
PANTER _at_ MPE Munich Leicester Uiversity _at_ UK SRON
_at_ Utrech MSSL _at_ UK
14
Reasons for SW modifications

• The OBSW is typically modified after launch due
  to 3 scenarios
• Need to correct launch SW bug and to tailor the
  OBSW during the commissioning phase.
• CORRECT
• Fit the unit to the nominal performance and
  implementation of improvements in performance.
• ENHANCE
• Preparation of the instrument for an extended
  lifetime and prevention/correction of HW failures
  or degradation.
• PREVENT

15
Instrument OBSW history
16
OBSW changes XMM
17
SW History
18
CORRECTION OM FM 11
NCR 171 Output Eng 4 image in 1 part, not 16
segments NCR 202 DPU software alerts from CGS
NCR 203 FAQ failure DPU assumes incorrect word
ordering of Input reference stars NCR 208 FAQ
failure Toggling of the fast mode data buffer
pointer NCR 209 Tracking offsets remembered by
Red DSP ECR 90 Add alerts at the beginning and
end of engineering exposures ECR 91 Full field
low resolution imaging mode
SEPT 2000
ESA/ESACs ROLE Reception of SW (code,
executables and intermediate products) Compilation
at ISS and comparison of executables, maps and
listings. Upload procedure tested at SOCSIM
level. Conversion into ISS image
format Coordination of the uplink with the
MOC Configuration Control for the SW
19
ENHANCE TC Watchdog
In case of loss of G/S or on board command
capability there is a risk that the cameras
remains a long time with the Filter Wheel open
while ground have no way to safe the instrument.

• New tasks using the scheduler APEX-2
• Scheduler cycle is 250 msecs.

PN AUGUST 2001 MOS JANUARY 2002

• TC WDOG
• Started upon TC reception
• Can be stopped from ground
• Period 32 (runs every 8 secs.)
• Priority low
• Counter is reset with any TC from ground
• Only one instance is allowed
• De-schedules on counter expiration

• FW CLOSE
• Started upon counter expiration
• Cycles through several status
• Period 32 (8 secs.)
• Priority high
• Sends Local Commands to EPCE to close FW
• Only de-schedules when the FW is closed
• If FW is not closed, cycles again

20
ENHANCE TC Watchdog
21
ENHANCE EPDH K
ECR 2, Dump of Offset Tables via HBR In order to
speed up and make the OFFSET table transmission
more reliable we should change the way it is
transmitted within the instrument. Currently it
is transmitted via the LBR (Low Bit Rate
I/F) With TC F0106 EAHBRSND OFFSET the EPEA will
transmit an OFFSET table through the HBR (High
Bit Rate) but currently the EPDH SW is not
handling this dump.
MAY 2002
Dump the OFFSET's in 15 seconds/CCD instead of
the current 8 minutes. With this they could be
dumped after every observation with minimal
overheads.
22
ENHANCE EPDH K
CRITICAL DESIGN CONSTRAIN TIMING and THROUGHPUT
23
ENHANCE EPDH K
GROUND SEGMENT PROCESSING DATA SYSTEM NEEDED
MODIFICATIONS New processing functions to extract
the Offset from the new format. New set of
archives for the new TM New routines to cope with
Offset reporting per Observation and not per
revolution New set of DB items (TM packets and
parameters)
SIGNIFICANT OBSERVING TIME GAIN AND SCIENCE
IMPROVEMENT
24
PREVENTION EMDH K

• ECR 7 Increase of number of bad pixels in the
  uploaded tables.
• The current maximum number of bad pixel storable
  on board by the EMDH is 50 pixels per CCD. Some
  CCDs were getting close to this limit, for
  instance 48 for MOS2 CCD1 already! Looking ahead
  at the potential future pixel "candidates" to be
  masked from the SOC MOS bad pixel monitoring,
  would lead to go over the 50 limit for a few CCDs
  in a few months.

POSSIBLE MICROMETEORITES !!!
25
PREVENTION EMDH K
DESIGN PROBLEMS Interaction on MASTER and SLAVE
processors Limited Data Area capacity discarding
simple extension of the current data structures
New TM and TC created Loading and reporting,
including proper ground comparison
26
PREVENTION EMDH K

• Preliminary tests carried on the SOCSIM, mainly
  related to the Data Handling functions, second
  half 2003.
• First set of tests on February 2004, at Leicester
  University, to verify Spare Chain readiness and
  capability to conduct K version tests.
• Second run of tests on March, validating K
  functionalities (ECR 7 and 9) and also a new ECR
  raised, number 12. Fully satisfactory.

27
XMM-Newton FUTURE?

• Better flagging and SW debugging?
• Becomes more and more important. Information on
  scheduled process, variable status, buffer
  occupation...
• Failures HW related?
• Impact of Latching Current Limiters (LCL)
  failures, CCDs not working, status of redundant
  channels (readout nodes, units, etc)?
• Degradation and performance
• How to cope with CCD degradation? Impacts of bad
  pixels? How to handle more failures or worse
  response from the event analyzers.
• New operational modes foreseen
• Will be anything expected? Old modes to be
  revisited?
• Instrument operations in reduced coverage
  scenario?
• Can we operate them with longer outage periods
  or different mission profile? Anything missing in
  SW?

28
Lessons learnt

• LESSONS LEARNT
• Early transfer of the instrument SW maintenance
  responsibilities to the operational side.
• Transfer of the expertise
• HW environments.
• The sooner this transfer takes place in the
  mission the better adaptation can be achieved
• Portable SW, independent from low level
  considerations.
• Usage of generic and widely used SDEs (likely to
  evolve)
• Design the SW for an extended mission.
• Re-mapping SW in EMDH J
• Lack of space RGS and EMDH
• Performance (EPEA)
• Code instrumented with debugging capabilities
  while flying.

Problems found Obsolescence of the ISS as an SDE
Maintain together the instrument Spare Units at
the developers sites Keep the knowledge
expertise at the SOC
Strategies adopted Testing the SW In Flight plus
keep equivalent machines in a frozen cold
redundancy Consultancy contracts, mutual
interest, adaptation of Spare environment to that
operational Documentation and history records of
past modifications.

• POSSIBLE MID TERM ACTIONS
• Hybrid SW-HW simulators, adding
• Realistic connectivity to existing control
  systems,
• Debugging environments and spacecraft level
  testing
• Removes the simulation constraints (lack of HW
  realism)
• Removes the difficulty of operation and lack of
  debugging of the Spares.
• Same control system SW (SCOS 2000 for XMM) as
  EGSE for the Spares.
• Common set of procedures
• Maintenance of the databases
• Equivalent telemetry analysis
• Transmission of expertise from IT and the
  operations teams.

29
Improvement of Spares

• The current Spare unit environment was developed
  ad hoc per IT.
• A problem is how to translate from spare
  environment procedures to flying unit ones and
  vice versa.
• The current environment in real operations is
  SCOS-2000, easier to install (previous one,
  SCOS-1, needed VAX, this one could in theory run
  Linux or cheap UNIX HW)
• Study ongoing to seek the usage of S2K in the
  Spares (MOS)
• easier talk and crossed analysis of problems,
• maintain up to date the EGSE DB with the
  operational one
• remote monitoring of operations in the Spare
• S2K expertise, vs. the specialized one required
  by the Spares.

OTHER ESA Missions following this
approach HERSCHEL
30

THANKS FOR YOUR ATTENTION !!! ANY QUESTIONS?