European Space Agency European Space Operations Centre

1
European Space Agency - European Space Operations
Centre
European Space Agency - European Space Operations
Centre
On-Board Software Maintenance at the Control
Centre
J.Morales, C.Steiger, E.Montagnon, P.Ferri,
A.Accomazzo

2
Outline

• Introduction What is On-Board Software
  Maintenance
• The Rosetta Approach
• The Venus Express Approach
• In-Flight Experience
• Future Approach
• Conclusions

3
OBSM What For?

• To adapt the spacecraft capabilities to major
  changes in the mission definition
• To work-around problems occurred in the
  spacecraft hardware
• To solve small bugs in the code delivered by
  Industry at launch
• To modify configuration parameters hard-coded in
  the software.

4
OBSM Levels of Complexity

• Level 1 Modification or definition of
  independent software functions
• tightly linked to the OBSW (Application Programs)
  
• interpreted new functions (On-Board Control
  Procedures)
• Level 2 Simple patches to be applied to the
  on-board software code
• from simple constants update to software
  functions enabling/disabling by substituting
  processor instructions
• Level 3 Major re-work of large parts or the
  entire on-board software code
• e.g. major mission redefinition, full new AOCS
  modes, major hardware unit failures

5
OBSM ESOC Experience

• The vast majority of the OBSM needs can be
  covered by complexity Level 1.
• In a few cases, work at Level 2 is required.
• Only extremely rare, major mission re-definition
  cases (e.g. the gyro-less implementation of
  Hipparcos or ERS, after loss of all available
  gyroscopes) required interventions at Level 3.

6
The Rosetta Approach

• Level 1
• Rosetta Flight Control Team responsible for OBCP
  development and maintenance in-flight.
• Smooth transition Industry - ESOC with small
  investment.
• Level 2
• In the initial In-flight commissioning phase
  under Industry responsibility.
• Slowly taken over by ESOC.
• Level 3
• ESOC has all the tools and expertise to allow
  tracking and of changes in the code, recompile
  and prepare patches and full images and run a
  complete system validation campaign.
• In case the need arises during the mission, the
  small Flight Control Team will not have the
  resources nor expertise to directly implement the
  new software
• Ad-hoc contracts will be placed with expert
  companies.

7
The Venus Express Approach

• Level 1
• Initially no OBCP allowed by the Project in the
  baseline.
• After Rosetta experience and transfer of know-how
  (and operational philosophy) at ESOC to Venus
  Express, OBCP fully developed at ESOC.
• Level 2
• Contractual baseline foresees full responsibility
  retained by Industry until the end of the nominal
  mission .
• Appropriate for short missions (2 years).
• In case of mission extension the Project will
  trade off a possible transfer of OBSM
  responsibility to the ESOC flight control team.
• Level 3
• Same as Level 2 above.

8
In-Flight Experience Rosetta Level 1
9
In-Flight Experience Rosetta Level 2
10
In-Flight Experience VEX Level 1

• OBCP development carried out by ESOC pre-launch
• Use of Rosetta development environment and
  expertise
• Identical on-board language and design
• Efficient specification process loop closed
  within the Flight Control Team
• OBCPs uplinked after launch
• Some are regularly used in support of routine
  operations
• Others will support special activities such as
  OBSM
• Only one OBCP modified in flight up to now

11
In-Flight Experience VEX Level 2
12
Future Approach

• Tools and Expertise
• Specification of powerful OBCP capabilities in
  all future spacecraft
• Transfer of on-board software development tools
  from industry to ESOC around launch agreed at
  Project start
• Build up of OBSM expertise in the ESOC Flight
  Control Team via participation in reviews and
  pre-launch tests
• Responsibilities
• Level 1 ESOC FCT responsible for launch of all
  OBCP specification, development and maintenance
  activities
• Level 2 Transfer responsibility to ESOC after
  in-orbit commissioning for long duration missions
  (e.g. BepiColombo) and at mission extension for
  short missions (e.g. lt 2 to 3 years)
• Level 3 cover it by ad-hoc contracts only when
  the need arises
• Payload leave it fully under instrument
  developer

13
Conclusions

• The only efficient way to handle OBSM is to move
  it as close as possible to the operations team
• In general, implementation of the OBCP
  functionality on-board covers most of the OBSM
  needs for a mission
• Simple patches to on-board software can be
  implemented more efficiently by the developers
  for short missions
• However for long duration missions (e.g.
  interplanetary with long cruise) responsibility
  shall be transferred soon to Operations
• Major on-board software re-design, especially if
  late in the mission, cannot be performed easily
  by Industry nor by the Operations team
• In general this is unlikely and can be covered by
  ad-hoc contracts, under supervision of
  Operations.
• This approach will be followed for all future
  interplanetary missions, and possibly extended to
  other ESA missions.