European Space Agency

1
European Space Agency
Spacecraft Simulator Development Lessons
Learned from the Cryosat Earth Explorer mission!
.
June 2006
V. Reggestad, European Space Agency (ESA) /
European Space Operations Centre
(ESOC) Darmstadt, Germany

2
Contents

• Introduction
• Background
• Review of Selected areas
• The Cryosat Mission design driving simulator
  design.
• ERC-32 Emulation
• Benefits of Standard Hardware and TCP/IP only
  setup.
• System Testing for Simulators?
• What to do without documentation?
• SDB usage, how to improve?
• SMP-2 and reusable libraries
• Maintenance
• Conclusion.

3
Introduction

• Cryosat Simulator developed to
• Support testing of Mission Control Systems (MCS)
• Prepare for the System Validation Test Campaign.
• Supporting training via the Simulations
  Programme.
• Cryosat Simulator consist of
• the Spacecraft model
• The Space environment and orbit where the
  spacecraft is flying
• The Ground Stations models

4
Background

• ESOC has developed operational spacecraft
  simulators for virtually all ESA missions
• A more flexible approach was adopted prior to
  start of the Cryosat simulator.
• Lessons learned from previous projected
• Periodic review of the Software Requirements.
• Iterative design and development process.
• Presented last year.

5
Cryosat Emulator Interface

• Cryosat can use
• ESOC emulator on local or remote host
• ESOC emulator on Alpha co-processor card. (Old
  fashion)
• TSIM
• SW emulation very successfulexperience

6
Mission TrendsOn Board CPU usage

• Figure show CPU usage of different missions

7
Testing approach

• Testing is a major part of the Simulator
  development due to
• Extremely complicate systems.
• Developed in short time.
• Good input to define tests are seldom available.
• Highly configurable and flexible system makes
  realistic tests difficult.
• Automatic Testing
• Result in a reduction in the effort needed to
  perform system testing.
• However
• Investigation of output logs are time consuming.
• Test cases need to be maintained with new
  spacecraft databases and information.

8
Standard Hardware

• Used Win2003, dual Xeon 2.8 Ghz.
• No special hardware
• No X.25
• No Alpha coprocessor.
• TCP/IP only network.

9
What to do without documentation?

• Today we relay on S/C documentation in all
  phases!!!

This is unfeasible!?!
This is a problem!?!
10
The SRS?

• Regularly reviewed for each major delivery
• This is a must and worked realy good.
• Always up to date.
• Content of SRS?
• Guidelines and roles, not requirements.
• Todo, maybe split it in
• Generic Requirements with a generic
  implementation.
• Generic Requirements acting as a guideline to
  implement mission specific code.
• Mission specific requirements with mission
  specific implementation.

11
SDB usage, how to improve?

• Today
• Translate/convert the MS Access SDB into some XML
  files.
• XML files are read into the simulator.
• The information are either directly or indirectly
  used within the source code of the simulator.
• Problems
• No configuration control.
• No flexibility.
• A tight coupling.

12
SDB usage, how to improve?

• SDB tool is needed, that
• A per item configuration control system.
• A standard method similar to the S2K working
  database concept.
• A standard SDB independent interface between the
  SDB tool and the Simulator.
• Dynamic remapping and updating of SDB relevant
  information used by the simulator.
• A simulator source code that are completely
  independent from the content of the SDB.

13
SDB tool architecture

• Maybe like this

14
SMP-2

• Today entire Simulator in one model
• Many problems experienced in Cryosat where a
  breakdown would be beneficial.
• SMP-2 would provide this and the experience show
  that its needed.
• Increased reuse require standard interfaces!

15
Conclusion

• New ways and technologies tried successfully
• Use of Software Emulator for ERC-32
• TCP/IP only
• Maintenance with Fixed Price per Task
• Flexible approach.
• Ideas for the future
• SMP-2 study needed
• SDB tool to be developed
• SRS split
• Identify generic model interfaces and reusable
  libraries
• Encapsulate OPS-GI infrastructure (SMP2)