1

THE CHALLENGES OF OPERATIONAL SIMULATORS: A NEW APPROACH FOR THEIR DEVELOPMENT AT ESOC

M. Spada

ESA/ESOC- European Space Operations Centre, Ground Segment Engineering Department

Robert-Bosch-Strasse 5, D-64293 Darmstadt, Germany Fax: +49-6151-90-2625; E-mail: mariella.spada@esa.int

ABSTRACT. A systematic review of the changes to the original contract for an already completed Operational Simulator development was carried out at ESOC recently. One of the key review results was that the unavailability of the external inputs required for the Simulator design, development and testing can have a considerable impact on the overall Simulator schedule and cost.

The review results confirmed the idea that Simulators could benefit from the adoption of a development approach which would allow the postponement of all engineering phases to as late as possible, to increase the likelihood that better defined and stable inputs are available, but still being able to support the early stages of Ground Segment testing.

The article presents the review conduct and results and the changes to the Simulator development lifecycle which are being implemented at ESOC to reach the above stated objective.

1. INTRODUCTION

Over the last 25 years ESOC has developed an extensive experience in the area of Operational Simulators, through the development of these systems for virtually all ESA Missions and, more recently, also for external customers.

Today the utilisation of Operational Simulators spans the overall Missions lifetime. The Simulator is a key tool for test and validation of Ground Segment facilities and operational procedures, training of operations personnel and, for those processors that are emulated in the Simulator, support to the validation of on-board software changes up to the end of the Mission.

Key drivers for the Simulator development plan are:

1. Support testing of Mission Control Systems (MCS). The Simulator is the key tool for the MCS testing in an integrated environment.

2. Prepare for the System Validation Test Campaign. The objective of the System Validation Tests (SVTs) is to confirm the capability of the Operations Control Centre (OCC) to support the Mission. This includes test and validation of the interfaces between the OCC and the satellite, confirmation of the correct functioning of the Mission Control System and Flight Dynamics System and the validity of the Flight Control Procedures. The Simulator is the only means used for validation of operational procedures prior to their execution with the s/c. This includes exercising contingency scenarios, e.g. recovery from on-board h/w or s/w failures.

3. Supporting training via the Simulations Programme. The aim of a Simulation Programme is to train a Mission Control Team so that it has the necessary skills, mutual trust and confidence to ensure Mission success. It practices the co-operation between team members under nominal and contingency situations.

2

To allow the functions above to be supported, a typical Simulator development plan foresees:

− Issuing the procurement ITT at least three years before s/c launch. At this stage the Simulator Software Requirements have to be defined. They are the basis for the Contractor offers.

− Definition of incremental deliveries based on the SVTs plan and content. Typically the first Simulator delivery concentrates on the satellite Data Handling, afterwards the Attitude and Orbit Control Subsystem is developed, then the payloads and the required failures.

2. PROBLEM STATEMENT

ESOC Operational Simulators are based on a common simulation infrastructure, which provides the simulation development environment. This infrastructure consists of the following main components: − SIMSAT (Software Infrastructure for Modelling Satellites), which provides the simulation kernel and

MMI. − Generic Models, including a spacecraft Positioning and Environment Model, a spacecraft Dynamics

Model, a Packet Telecommand and Telemetry Toolkit (SIMPACK) implementing the ESA Packet TM and TC Standard, and on-board processors software emulators.

− A Ground Station Simulation System, including models of the telecommand encoder and telemetry decoder ground-station equipment, implementing the space link and network link for both the ESA Stations Protocol and the CCSDS Space Link Extension (SLE).

Nevertheless a substantial ad-hoc development is required for each Mission to model the specifics of the spacecraft and its Ground Segment. In particular the Simulator is required to model: − All s/c subsystems. A different level of accuracy can be required, depending on the criticality of the

subsystem from an operational point of view. − Generation of all H/K TM. − Generation of science TM can be required for some or all of the payloads. − Verification and execution of all TCs. − Implementation of user commands for the manipulation of Simulator parameters or for injection of

failures. − Software emulation of on-board processors. It has become a mandatory requirement for all Missions

the emulation of the satellite platform processors, for the execution on the Simulator of the actual On-Board software (OBSW). For some Missions it is required to emulate the payload processors as well. The emulation allows full upgrades and patching of the OBSW to be performed with very little effort, with obvious large benefits in terms of testing of the software changes and their impact on the operational procedures.

The implementation of the above stated requirements relies on a number of inputs from third parties, which are Customer Furnished Items (CFIs) from the Agency to its Simulator subcontractors. The most important ones are:

Spacecraft specification and design documentation: By its nature, a simulation requires a well-defined specification of the object to be simulated, i.e. the spacecraft subsystems and all space-ground and ground-ground interfaces.

Satellite Database (SDB): This contains the definition of all spacecraft TM and TCs. The generation of telemetry and processing of telecommands in the Simulator is based on the SDB content.

3

Satellite On-Board Software: The software emulation of some or all of the spacecraft on-board processors introduces a strong dependency on the availability and quality of the on-board software and on a clear and stable definition of its interfaces with the other spacecraft components.

Therefore one of the main challenges in the development of Operational Simulators is in the management of the critical dependencies on these external inputs, on the availability and quality of which the Simulator has almost no influence.

3. IMPACT OF EXTERNAL DEPENDENCIES ON SIMULATOR DEVELOPMENT

A systematic review of the document changes to the original contract for an already completed Operational Simulator development was carried out at ESOC in 2000 [1]. Given the characteristics of the contract changes data, suitable to structuring and reduction into numerical form, an informal quantifying approach was adopted to turn the contract changes information into numerical form [2]. The Contract Change Notices (CCNs) were sorted by Project Phase:

− Architectural Design Phase − Detailed Design Phase (for the purpose of this ana lysis this includes the Transfer Phase, i.e.

integration and testing at ESOC) Within each Project Phase, CCNs were classified by: − Source of change

− Severity of schedule impact

3.1 Source of Contract Changes

The analysis started from the consideration of the causes of the contract changes in the different project phases. Documentation other than contract changes was used to support the understanding of the reason for the changes and their impact with respect to the original project baseline.

The following categories were considered for the source of changes: − New or Changed Requirements respect to original contract − Information Related: Unavailability or instability of information on which to base the Simulator

design − CFIs Related: Problems with deliverables to subcontractors, e.g. availability and quality − Others: Of various nature

4

Figure 1 below shows the cost impact of the changes split according to source.

% Cost Increase in AD Phase by Source

New/Changed Requirements

2%

Information Related

77%

Others21%

% Cost Increase in DD Phase by Source

New/Changed Requirements

4%

Information Related

83%

CFIs Related13%

Figure 1 Cost Impact of Contract Changes

It should be noted that 95% of the overall project cost increase was due to changes in the Project DD Phase. The difference between AD and DD Phase is largely justified by the fact that for ESOC Simulators the DD phase accounts for the largest part of the system development. For the analysed project, the DD phase accounted for 78% of the total development contract.

As appears from the statistics in Figure 1, the largest proportion of contract changes cost was due to ‘information related’ changes in all project phases. Contract changes classified as ‘information related’ were caused by the inadequate quality of the spacecraft specification and design documentation at the point in time when it was required for the Simulator design. This included unavailability or insufficient details in the documentation, inconsistency between different documents and/or between subsequent issues of the same document.

New/changed requirements resulted in the least cost impact in all project phases. Of the changes falling in this category the most part was caused by the inconsistency between the requirements contained in the original contractual documentation and the actual project needs, which became known only at later stages in the project.

All Customer Furnished Items were only used during the system DD phase. Therefore the related contract changes were all made during this phase.

3.2 Schedule Impact of Contract Changes

Based on the categorisation of the contract changes given above, an analysis was performed of the severity of their impact on the overall Ground Segment schedule.

The following categories were considered for the severity of the schedule impact deriving form the changes:

− Major Schedule Impact (overall Ground Segment schedule is impacted) − Minor Schedule Impact (can be absorbed internally to the project) − No Schedule Impact

5

Figure 2 below summarises the analysis results.

Schedule Impactof New/Changed Requirements

Major Impact

75%

Minor

Impact25%

Schedule Impactof Information Related Changes

Major Impact

26%

Minor Impact

74%

Schedule Impact of CFIs Related Changes

Major

Impact27%

Minor Impact

73%

Figure 2 Schedule Impact of Contract Changes

The results in Figures 1 and 2 show that a large part of the impact deriving from Information and Customer Furnished Items related changes, which represent the largest cost increase for the overall project, could be absorbed within the project, without direct impact on the project deliveries schedule and therefore on the overall Ground Segment. On the contrary, most changes to requirements, which had a very limited impact on the project cost, generated project slips. A justification for this phenomenon can be found in the fact that the need for changes to requirements was identified at later stages in the project development, when the schedule pressure did not allow anymore for absorption of the changes within the original schedule.

6

4. REVIEW IMPLICATIONS

The results of the project review reported above confirmed the idea that Simulators could benefit from the adoption of a development approach which would allow the postponement of all engineering phases to as late as possible, to increase the likelihood that better defined and stable inputs are available when required, but still being able to support the early stages of Ground Segment testing. The following is particularly important:

1. That the Simulator Requirements used as baseline for the design and development of the system reflect as close as possible the latest available knowledge about the spacecr aft and the ground segment and the user needs. The aim is to reduce to the minimum the introduction of requirements changes at later development stages.

2. That the Simulator external inputs, i.e. spacecraft design documentation, On-Board Software and SDB, are of good quality and as stable as possible.

Two are the measures which have been implemented to reach these two objectives:

1. Delay of schedule for first Simulator delivery. This has led to the conception and development of a new system, TTSIM (TM/TC Simulator) which can support the early integration and testing of the MCS

2. Change of approach to execution of the different project phases, from the definition of the Simulator requirements to the completion of its implementation.

4.1 TTSIM

TTSIM is a Telemetry Generator and Telecommand Responder, based on SIMSAT. TTSIM is supposed to be used to support initial testing of a Mission Control System (MCS), when the focus is on data flow and the extended modelling of the spacecraft provided by the Operational Simulator is not yet exercised. The TTSIM software is “ generic” and can be customised with very limited effort for specific Missions [3].

This reduces the dependency of the Simulator schedule on the MCS schedule and allows delaying the first Simulator delivery up to 2/3 months before the first SVT. In the past the Simulator had to be available from the first MCS delivery, which can be much earlier than the first SVT.

4.2 New Development Model

Adoption of an evolutionary development model, in replacement of the old incremental delivery model. This approach is characterised by the planned development of multiple releases and the execution for each release of all processes of the life cycle, starting with a Requirements Consolidation Phase and continuing with the definition of the architecture and design and testing of the parts of the system covered by the delivery. The content of each delivery reflects the operational priorities, e.g. System Verification Tests schedule and content. The aim of this approach is twofold:

− The introduction of a systematic review of the Simulator requirements before starting the design for a specific delivery aims at basing the Simulator design on requirements which reflect as close as possible the latest knowledge of the space and ground segment design and operational needs. The impact of requirements changes or new requirements is minimised, since they are introduced before the related design and implementation starts.

7

− The Architectural Design of the different Simulator subsystems, which in the past was completed before the start of the Detailed Design Phase, is split across the deliveries. This allows delaying as much as possible the design of those subsystems which are not well-defined earlier on in the Mission and the use of later versions, and therefore better quality and more stable CFIs.

5. CONCLUSIONS

The dependency of Operational Simulators development on stable requirements and external inputs can have considerable side effects on the development cost and schedule. Measures need to be taken to delay the start of the Simulator development and adopt a development model which includes a systematic review of the Simulator requirements and possibly more availability and stability of inputs.

The approach proposed in this article is currently being implemented on the Cryosat Simulator. Cryosat is the first ESA Opportunity Mission, therefore the efficiency requirements are particularly stringent. It is expected that an evaluation of the potential benefits should be possible in the near future.

6. REFERENCES

[1] Spada, M., Knowledge Management in a Project-Based Organisational Context, MBA Management Project Report, 2000

[2] Hussey, J. and Hussey, R., Business Research, Macmillan Press Ltd., 1997

[3] “TM/TC Simulator Software Specification Document”, DTOS-SST-0583-TOS-GMS, Issue 2.2, May 2002