European Space Agency

1
European Space Agency
Innovative Concepts to reduce Costs of Mission
Control and Simulators for LISA-Pathfinder
F. Delhaise, T. Bru ESA/ESOC, OPS-GDS
2
Outline

• LISA Pathfinder (LPF) Mission
• Mission Control System (MCS)
• Requirements Management Tools RENATO
• Benefits of using RENATO for LPF
• Simulator development (SIM)
• Reuse from Infrastructure, previous missions and
  industrial simulators development
• Simulation Model Portability 2 (SMP 2)
• Conclusions

3
Objectives of LISA(Laser Interferometer Space
Antenna)

• LISA will be the first space-based mission to
  attempt the detection of gravitational waves.
  These are ripples in space that are emitted by
  exotic objects such as black holes.
• The high level LISA mission needs can be
  expressed as
• The LTP test mass must be shielded from all
  external non-gravitational forces

4
LISA Pathfinder Mission goal and concept

• The technologies for LISA cannot be proven on the
  ground
• Thus, ESA has conceived the LISA Pathfinder
  Mission
• LPF has one fundamental goal
• to verify that a test mass can be put in pure
  gravitational free fall within one order of
  magnitude from the requirement for LISA.
• The basic idea is that of squeezing one LISA
  interferometer arm from 5 106 km to a few
  centimetres (the LISA Test Package) on-board a
  small spacecraft.
• A similar system (Disturbance Reduction System,
  DRS) will be provided by NASA

5
The LPF System

• The science spacecraft
• two main sensor packages, the LTP and DRS
• 2 micro-propulsion systems
• Field Emission Electric Propulsion (FEEP)
• colloidal thrusters of the DRS
• 1 drag free control system (DFACS),
• spacecraft equipment required to provide support
  functions to the payloads over the mission
  lifetime
• Disposable propulsion module for apogee raising
• One single X-band antenna
• 35m Cebreros, nominally 8 hours/day
• Launch on Rockot (or Dnepr)
• Operations by ESOC

6
The LPF Mission Sequence
The target orbit is at the Earth-Sun L1 Lagrange
point. very challenging LEOP up to 14
manoeuvres over 15 days. Launch Date Oct. 2009
7
LPF Mission Operations Centre
8
LISA Pathfinder Mission Data System Status

• Requirements Phase until Nov. 2006
• Ground Segment Review Nov. 2006
• MCS and Simulator Development (design and DDD
  phases) start Jan. 2007
• Simulations campaign Launch 5 months
• Launch Oct 2009

9
LISA Pathfinder MCS

• MCS will be based on SCOS-2000 R5.0
• S2K 5.0 provides a large proportion of the
  required functionality Archive, DDS, OBSM, TMS,
  TCS, PUS services
• Mission specific development needed
• Database editor
• Time correlation
• PUS service 11 improvement
• Etc
• Identification of potential reuse from previous
  projects

10
Software Reuse (Cont.)

• Reuse across missions is a delicate operation
  the combined effort and risk required to reuse
  the software has to be less than the effort
  required to implement again from scratch !

• Is the software component tested, proven, stable?
• Is it of sufficient quality?
• Is it easy to customize it?
• Is it easy to understand its structure?
• Does it fully or partly meet projects needs?

11
Avoid building Frankenstein
12
Coping with Similar RequirementsThe
traditional approach

• For each new mission, previous missions
  requirements are carefully reviewed to check
  applicability
• These requirements are maintained on an
  individual repository from which a SRS document
  is generated

• Problem Number of missions is ever
  increasingTherefore this task is
• more and more complex
• expensive
• almost impossible to do exhaustively
• exchange between DSMs, developers and end-users
  from different missions is point-to-point,
  informal and relies on knowledge and availability
  of individuals
• Solution RENATO Elaborated Requirements Mgt
  Tool

13
The Tool RENATO
A More Elaborated Requirements Management Tool
14
RENATO Requirements Mgt Tool

• Two Major Goals
• to analyse and consolidate the ever-increasing No
  of requirements which had to be implemented on
  top of the infrastructure kernel
• to ease the production of SRS document of future
  MDS in such a way to optimise software reuse from
  previous missions
• RENATO is based on Telelogic DOORS (commercial
  product)
• DOORS incorporates a macro-programming language
  (DXL) ? tailored functionality

Note Many of the products and the names of
companies mentioned are trademarks or registered
trademarks of their respective owners. Their use
neither constitutes a claim of the trademarks by
ESA nor affiliation of the trademark owners with
ESA
15
RENATO (DOORS) View
Graphic
SRSChapters
Text
Requirements
16
RENATO Features

• One single Database for all projects
• One dedicated module per project
• Powerful Classification of requirements to
  support easy searching
• Dynamic linking between requirements from
  different modules
• It combines a database facility for storing
  requirements and high quality word processing for
  the text cut, copy, paste, spell-checking,
  search, Pictures, Diagrams and Tables
• Ability to define save a View particular
  Display of the data

17
RENATO Features (Cont.)

• Configuration Control via
• Maintenance of Software Change Requests
• Definition of Baseline
• Export the content of a module to MS Word to
  generate the SRS document. WEXP freeware module
  has been integrated into RENATO
• The usage of WEXP offers an improved version of
  the standard DOORS output. Example of requirement
  export

DBS-FU-150-LPF
Note that it is not required to support the
import of partial SDB versions.
18
Analysis of ESA MCS Requirements

• As a start RENATO holds requirements of all the
  SCOS-2000 based MCSs in a single database
• Result of systematic review of all requirements
  coming from
• Interplanetary missionsMars Express, Rosetta,
  Venus Express
• Earth exploration missionsCryosat, Goce,
  Aeolus, METOP
• Technology missionsSmart-1, Lisa Pathfinder
• Observatory missionsIntegral, XMM,
  Herschel-Planck

19
Common Requirements

• Identification of commonrequirements used by
  more than one missions
• These requirements result from a process of
  generalisation and consolidation of mission
  specific requirements through rewording, terms
  standardisation or parameterisation
• Advantages
• SRS authors can now look in a single place to see
  which requirements are applicable to which
  missions
• Precious feedback for possible extensions of the
  infrastructure
• To deduce statistics on reuse across missions

20
Requirements Management Process for LISA
Pathfinder
Reuse
Identify existing functionality
Common Requirements
Retrofit
21
Identification of reuse for LISA Pathfinder

• The following common functionality (not
  part of SCOS) have been identified for LPF
• TM Packets Decompression
• Telemetry Replayer
• Time Correlation with the use of the OWLT files
• Time-Stamping and Time Checks
• Extraction of Non-PUS TM through the use of
  configuration file
• Service 11 Onboard Scheduling Service, update
  ground model with TM(11,13) summary schedule
  packets
• TC Verification Service using live and playback
  data

22
Benefits of Software Reuse

• The quality of the SRS is enhanced by the
  adoption of requirement specifications that have
  already been reviewed or have even been
  implemented and/or operationally validated
• Potential candidates for retrofit into the
  infrastructure are identified
• Harmonization of the mission specific
  requirements across projects which will
  ultimately ease the retrofit into the
  infrastructure.
• If same requirements are formulated in the same
  way across missions the familiarity with them and
  their understanding by all parties is improved.
• The assumptions for potential software re-use are
  equally made known to all MDS development
  bidders, enhancing competition on the same ground

23
LISA Pathfinder Simulator

• First Draft of the requirements in 2005
• Updated requirement End June 2006
• Internal Review until September 2006
• Main review at the GSPDR October 2006
• Start of development February 2007
• Simulations campaign Launch 5 months
• Launch Oct 2009

24
LISA Pathfinder Simulator

• High fidelity software model of the
• Spacecraft
• Ground stations
• orbital and environment model
• Goal
• MCS and FDS Testing and Validation
• Functional testing and validation of the LPF
  Operations Database
• Validation of Timelines, Flight Control and
  Contingency Recovery Procedures
• Operations staff training in an operational
  environment
• Execution of the Simulation Campaign
• Potential investigation of in-orbit operational
  anomalies
• Operational validation of on-board software
  modifications
• Ground Segment End-to-End Tests

25
LPF Simulator Components
Spacecraft Models
Ground Station Models




CDMU
1553 Bus And Controller


File

TCS
FTP Interface

Storage
RCS

Ground Segment Systems
TM/TC Streams
EPS



TIF

TMTCS
PRM
TMTCS

TX

Interface



RFCS




NIS
LTP
TMTCS Models
RX


DRS
EMULATOR


Attitude Model
Positioning And environment Model

DIF

MCS

MCS
Direct






SMI
/SMP2


LPF simulator components ESOC infrastructure
generic components


SIMSAT Kernel (LINUX)
Satellite Databases OBSW



M M I

26
Reuse of infrastructure

• It will be based on ESOC SIMSAT R4.0 offering
• Event Scheduler
• Break pointing Facility
• Standard Simulation Graphical User Interface
• Logging facilities
• User interaction with the systems, e.g. ability
  to inject failures via user commands
• Visualization and monitoring of simulator
  parameters
• Ground Station SLE based Models,
• infrastructure generic models, i.e.
• ERC32 on-board processor emulator
• spacecraft dynamics (SIMDYN)
• orbit and environment models (PEM)
• Electrical and Thermal Models

27
Reuse from previous missions

• The ERC-32 emulation from ESOC Simulation
  Infrastructure
• The FEEP system from GOCE simulators
• Common AOCS sensors like Star Tracker, Sun
  sensors etc
• EPS and Thermal systems reused as best suited
  from previous simulators such as Rosetta, Mars
  Express or Venus Express.

28
Reuse from industrial models

• reuse of the model design inspired from the
  Software Verification Facility (ASU-SVF)
  developed by EADS ASTRIUM
• Encapsulation of source code into SIMSAT
  infrastructure
• or
• Use as baseline for the design of the ESOC
  simulator

29
Conclusions

• MCS development
• Benefits of using a more elaborated requirements
  management tool RENATO
• Generates SRS documents with powerful
  traceability
• Direct access to all other missions requirements
  located in the same database
• SIM development
• Reuse of ESOC SIMSAT generic simulation
  infrastructure based on ESA Standard (SMP2)
• Reuse of models from previous simulators
• Reuse of models from Industry
• Full benefit of RENATO

30
Any Questions?