SO96.5.01 1

Abstracts

All together 4 versions of the ISO (Infrared Space Observatory) Simulators with varying functionality, performance and usage have been produced:

* IPS: The ISO Platform Simulator

* IHPS: The ISO Hybrid Platform Simulator

* ISIS: The ISO Stand-Alone Instrument Simulator

* IIIS: The ISO Integrated Instrument Simulator

After an introduction on the purpose of the project main points in the approach for its development are described from start of the project until date

ISO Mission Background

The Space Segment of the ISO mission, the ISO satellite, is a space observatory in the infrared portion of the spectrum. The ISO satellite system is split in a service module and a payload module. The service module provides the standard support functions for the payload module. The payload module comprises a cryostat with four scientific instruments in the focal plane of a Ritchey-Cretien telescope. The ISO satellite was launched 17. November 1995.

* The Launch and Early Orbit Phase (LEOP) was conducted from the Operations Control Centre (OCC) at ESOC/Darmstadt supported by a network of Ground Stations. Tasks to be accomplished was monitoring, control and commissioning of the spacecraft and its interfaces to the payloads. The LEOP has terminated with handover of operations and transfer of operational staff to SCC/VILSPA.

* The succeeding In Orbit Phase (IOP) is conducted from Villafranca/Spain (VILSPA) in the combined Spacecraft Control Centre (SCC) and the Science Operations Centre (SOC). Commissioning of the payload scientific instruments is completed. Current activities involve monitoring and control of both service and payload modules in addition to support for payload exploitation.

Different versions of ISO satellite simulators have been developed to support the various scope of activities at VILSPA, ESOC and ESTEC.

Simulators at ESOC for validation and verification of the Control Centres.

Simulators of the subject type are developed prior to launch and used to verify and validate the Ground Segment functionality and readiness to support LEOP and if applicable to the succeeding IOP. Other simulators cover other aspect such as Ground Station verification and validation or the more accurate flight dynamic simulations which do not execute in real time awhich are not treated in this paper.

A major goal is to gain confidence and evidence that all preparations are adequate for the coming operations and that all nominal and failure cases can be properly mastered..

A simulator thus:

* is used to support testing of the Control Centre software during development;

* is used during the final simulation campaign prior to launch;

* is used for preparation and execution of Control Centre validation tests to:

- verify the Control Centre database;

- verify that nominal and contingency flight operations procedures are in conformance with the specifications made by the manufacturer;

- validate that the nominal and contingency flight operations procedures are correctly implemented;

* provides training to the flight control team with the purpose to:

- educate in understanding of S/C;

- familiarise newcomers with the operational interface and thus enable fluctuation of personnel;

- keep proficiency for seldomly used operations in contingency cases;

* provides support during LEOP and IOP;

* supports post launch flight software validation prior to on-board software maintenance activities.

A simulator for validation of the Control Centre is required to provide interfaces as close to reality as possible where it communicates with the real spacecraft via Ground Stations through an X25 like communication network. Simulators of this type therefore include modelling of the Ground Stations involved. The Ground Station modelling usually restricts itself to the channelling, decoding and encoding aspects for telemetry and telecommands. Ranging and Ground Station monitoring interfaces are simplified to support only the message protocol with the OCC and do not produce realistic data content.

ISO Simulator Project:

All together 4 versions of the ISO Simulators with varying functionality, performance and usage have been produced:

* IPS: The ISO Platform Simulator

Pre launch and LEOP support at ESOC (terminated)

Post launch support at VILSPA (ongoing)

* IHPS: The ISO Hybrid Platform Simulator

Support of the final simulations campaign at ESOC (terminated)

Post launch support at VILSPA (ongoing)

* ISIS: The ISO Stand-Alone Instrument Simulator

Pre launch support at VILSPA and ESTEC (terminated)

Post launch support at VILSPA (ongoing)

* IIIS: The ISO Integrated Instrument Simulator

Pre launch IOP support at VILSPA (terminated)

Requirements for the various simulators were driven by the approach selected for the development of the Control Centres and their evolving configurations requiring simulator support. OCC/SCC and SOC were developed and tested separately, then transferred, integrated and tested at VILSPA prior to ISO launch:

* The Pre-launch OCC/LEOP facilities at ESOC and the post-launch SCC facilities at VILSPA were developed under the responsibility of ESOC. Both facilities required simulator support with largely the same functionality: high fidelity in the area of the platform subsystems and low fidelity in the payload area. This led to the IPS version.

* The Pre-launch SOC facilities at ESTEC and the post-launch SOC facilities at VILSPA were developed under the responsibility of ESTEC. The associated simulator functionality was driven by the requirements for realistic TM and TC interfaces to the 4 payload subsystems. This led to the upgrade of IPS required for both ISIS and IIIS versions.

* Communication between SOC and S/C or Simulator always takes place via SCC. Any use of the ISIS or IIIS by SOC requires the interfaces between SOC and SCC to be met. During pre-launch testing at VILSPA this was effected by the operational SOC/SCC. This led to the IIIS version.

* Pre-launch activities at ESTEC took place without access to SCC. Post-launch use of operational facilities (SCC) at VILSPA was prohibited for safety reasons. The simulator thus required inclusion of relevant portions of the SCC (ODS and IDCS functions to be of any use. This led to the upgrade required for the ISIS version.

* A genuine requrement for the Hybrid simulator did not exists. However it was recognised that a facility which allowed execution of the original on-board code had advantages. The IHPS was developed under a study contract. The results also being of value for other projects.

FUNCTIONAL DIFFERENCES BETWEEN THE SIMULATOR VERSIONS	SIMULATOR VERSION
	IPS	IHPS	IIIS	ISIS
ACC software modelled by reuse of original ADA source code	yes	no	yes	yes
ACC software machine code loaded and executed by a HW attachment to the Simulator computer including a 1750 processor	no	yes	no	no
Reduced modelling of the Payload without modelling of the instrument software	yes	yes	no	no
Payload instrument (8086) processor emulators executing the original flight code	no	no	yes	yes
Limited modelling of the SCC (IDCS and ODS) facilities	no	no	no	yes

All 4 Simulator versions are all installed on DEC Equipment:

* The Platform Simulator executes on a DEC VAX Workstation under Open VMS

* The Hybrid Simulator includes in addition a 1750 processor attached to the Workstation hosting the Simulator (TASCO board and VME interface).

* The Integrated Instrument Simulator is installed on a DEC Alpha station and a DEC VAX Workstation. The DEC Alpha station is needed to meet the increased performance required for emulation of the 8086 processors in the payload instruments. The DEC VAX Workstation is needed as interface to the IDCS for reasons of protocol compatibility (OSAK (x25) software not available on DEC-AXP).

* The Stand Alone Instrument Simulator has in addition a further DEC VAX Workstation used for the SOC applications.

Implementation approach

Application of the ESA Software Engineering Standards ESA-PSS-05-0 is compulsory to all ESA software projects and consequently also to simulators. These standards call for a sequentially phased development approach with interface documents in both technical and managerial domains.

* The User Requirements Document (URD) is defined by the customers of the simulator in the User Requirement Definition Phase.

* The Software Requirements Document (SRD) results from an analysis of the URD and defines WHAT shall be the simulator functions in terms of software.

* The Architectural Design Document (ADD) builds on the SRD and defines HOW the SR can be met.

* The Detailed Design Phase results in the first deliveries to the customer which includes:

- System tested (against SR) operational delivery to be used for acceptance tests;

- Draft versions of the Detailed Design Document (DDDs);

- User Documentation.

* The Transfer Phase is intended for execution of the acceptance tests by the customer giving:

- Second operational delivery with fixes to problems found during acceptance tests.

- Updated User Documents

- Updated DDD(s)

* Operation and Maintenance phase which usually are scheduled to start at L-12 months.

The original overall timescale for IPS was:

- start of SR phase after final issue of the URD: July 1991;

- end of Transfer phase: end 1992;

- launch date: November 1995.

Identification for the need of an Instrument Simulator started in Nov 1992. This at a time when the IPS was already into the transfer phase but at a time when the launch date had been postponed.

Strict adherence to the sequential nature of phases were not adhered to during the ISO simulator project. Overlaps between the phases were applied as found feasible mostly to maintain efficiency of assigned staff.

The ISO Simulator Project had two distinct customer:

* The ESOC Operations Department (MOD) who provided the ISO Platform Simulator URD. The simulator used to fulfill their sole responsibilities for the LEOP operations and their respons- ibilities for S/C operations during the following IOP.

* ESTEC who provided the ISO Instrument Simulator URD and SRD. The simulator used to fulfill their responsibility for operations of the 4 scientific instrument payloads during the IOP.

Development of the IPS was entrusted to the ESOC Flight Control and Support Department (FCSD) as from start of the SR Phase. The IPS/SRD itself was made in-house and with begin of the AD Phase further work was contracted to the Marcol company (later CRAY Systems). As from start of the AD phase for IIIS/ISIS the Marcol company was also contracted this work justified by the fact that the Instrument Simulator was an upgrade of the existing IPS.

FCSD is working with industrial frame contracts based on a competitive tender action. These frame contracts cover simulator development and maintenance awarded for a given period of time. Separate work packages are then assigned subject to competitive bids or direct negotiations. Work packages can be assigned for any phase of development and/or maintenance.

ISO Platform Simulator - IPS

The IPS forms the backbone of all the ISO Simulators. IHPS, IIIS and ISIS can be considered variations of the IPS with upgradings and downgradings of implemented functions and which came into being at a point in time when the IPS had already completed the development phase.

The IPS URD/SRD calls for a simulator with:

* models of the S/C platform subsystems as there are:

- Telemetry Encoder model;

- Telecommand Subsystem model;

- Radio Frequency Subsystem;

- Data Handling Subsystem Software model;

- Data Handling Subsystem Hardware model;

- Attitude and Orbit Control Subsystem Hardware model with FSS, SAS, ELS, Gyros and QSS ;

- Attitude and Orbit Control Subsystem Software model;

- Reaction Control Subsystem model

- Star Tracker model;

- Power Distribution model;

- Power Generation model;

- Payload models;

- Thermal model;

* reduced payload modelling without modelling of the instrument on board software functions;

* a model of the S/C dynamical behaviour (attitude and orbit);

* a model of the celestial environment (earth, some planets and star field) and

* a model of the Ground Stations (Perth, Kourou and Vilspa) acting as the interface to the IDCS operations control centre.

The SRD also included the architectural decision to apply the ESOC developed infrastructure, the General Purpose Software Simulator Package (GPSSP). GPSSP is a Fortran IV based system including scheduling, logging, user interface for simulator control etc. and a set of hooks to add the special to project S/C models. In the meantime ESOC has developed a new ADA based and object oriented infrastructure SIMSAT (Software Infrastructure for Modelling of SATellites).

The AD activities started off with a feasibility study on the optional methods for implementing the functions of the Attitude Control Computer (ACC) and the associated interfaces to the rest of the simulator. The option of embedding a maximum amount of the actual ADA code was selected.

The other options were to reimplement the algorithms as defined by the manufacturer or to introduce hardware in the loop. The first of these alternatives were considered too costly, the second one too risky for lack of existing hardware installations. The idea of using hardware in the loop was later taken up as a study project with the ISO Platform Simulator as a test bed. It resulted in a the ISO Hybrid Platform Simulator which proved very successful and was used during most of the final simulation campaign prior to launch.

IPS was planned to be delivered in phases according to progress in development and testing:

* ED1: Engineering Delivery 1 functioning only as a pure telemetry source. This was used for the first data flow tests during development of the Control Centre Software.

Planned delivery: 1. August 1991. Actual delivery: 31. July 1991.

* ED2: Engineering Delivery 2 with telecommand funcions added. Also this delivery was used for Control Centre Software testing during development. The delivery included a few subsystems and allowed close loop testing.

Planned delivery: 1. September 1991. Actual delivery: 30. September 1991.

* OD1: Operational Delivery 1 with a subset of subsystem models implemented: Planned delivery: 1. February 1992. Actual delivery: 31. January 1992.

* OD2: Operational Delivery 2 includes all required models. This system tested version was used for the acceptance tests by the customer (MOD). OD2 was made at the end of the development phase. Operational Delivery 2 included fixes made as a result of the testing since OD1.

Planned delivery: 31. June 1992. Actual delivery: 31. July 1992.

Acceptance tests took place during the transfer phase and terminated with start of the maintenance phase.

Planned duration was 1. July 1992 until end 1992. Actual duration was 1. August 1992 until end 1992.

At the end of the Transfer Phase it should in principal have been possible to state provisional acceptance of the simulator. In the case of IPS this was not the case. After this date numerous updates to the S/C TM and TC databases and versions of the on-board ACC application software together with related documents were to be received. The OM phase of the simulator was extended significantly due to the large launch slippage (May 93 to November 95). This enabled many outstanding problems to be resolved before finally entering the simulations campaign prior to launch. All together more than 500 Software Problem reports in 3 categories of priority (critical, urgent and routine) have been handled prior to launch. Out of these only 10 routine ones were still not solved when entering the simulations campaign which took place in 3 phases mainly using the IHPS:

* 29 May 1995 to 22 June 1995 Simulations Program at ESOC

* 04 July 1995 to 03 August 1995 Simulations Program at VILSPA

* 08 August 1995 to 15 August 1995 Simulations Program at ESOC


ISO Instrument Simulators IIIS and ISIS:

The ISO Instrument Simulators were developed for the purpose of testing the Science Operations Centre Instrument Stations and the associated instrument operating procedures. Common to both simulators were an upgrade of the ISO Platform Simulator implementing fully functional models of the ISO instrument payloads ISOPHOT, LWS, ISOCAM and SWS. These instrument models should support the telecommand and telemetry interfaces to a sufficient level of detail in order to meet these objectives. The simulators was intended for use at ESOC and VILSPA via ODS and IDCS and also located at ESTEC with direct connection to the SOC.

Work started with a 2 man month study performed by CRAY Systems on the subjects of:

* analysis of the existing draft URD provided by ESTEC

* evaluation of the existing document and their relevance for instrument modelling

* feasibility of developing instrument models

* IDCS elements to be included for the ISIS

* Schedule and Costs.

The main recommendation was that the on-board software executing in the 8086 processors should be emulated. SWS and LWS on-board software was written in assembler making a functional rebuild time consuming and cumbersome.

Another recommendation of the study was to combine the AD and DD Phases into one DID Phase. This was justified by the critical time assigned to this part of the project and also by the fact that most of the architectural issues had been resolved in the IPS development.

Following the draft Study report in May the DID started in June 1993 with a go ahead for implementation of the ISOPHOT and the IDCS elements to be included. These items were considered sufficiently documented to make a simulator development feasible. The remaining LWS, SWS and CAM instruments could only be considered feasible to model if a solution to emulation of the 8086 processor could be found. A further assessment on the 8086 emulation took place prior to the final study report in July 1993 and with positive results. For this purpose the source code of the Microtec Inc. XRAY86 development environment was acquired. Subsequent restructuring and adaptations then made this into an emulator finally enabling at least two emulators to run in real time and in parallel on a DEC Alpha Work Station.

The DID Phase was terminated by end of may with a delivery including all instrument models. The efforts during this period was 1420 mandays against the original estimated of 1360.

The following transfer phase concluded in November 1994 after acceptance tests with provisional acceptance granted subject to completion of a number of outstanding urgent Software Problem Reports (SPRs).

Maintenance of the IPS/IHPS and IIIS/ISIS was carried out independantly until launch. Pos launch since begin 1996 one contractor at VILSPA is fully occupied with the maintenance of all simulator versions. Until date 248 Software Problem Reports hav been issued in three priorities out of which 22 of lowest priority are still open.

The IIIS contributed to End-to-End simulations involving SCC and SOC. Primarily these tests were preparations for the System Validation Tests (SVTs) with the ISO spacecraft in terms of dry runs, but also

pre tests for these dry runs were found necessary to iron out problems both in the simulator and control systems:

* 14 April 1994 to 25 April 1994 EE0 Interconnection tests ESOC(SCC)/ESTEC(SOC)

* 11 July 1994 to 18 July 1994 EE0 Same tests after reinstallation at VILSPA

* December 1994 EE1 Pre testing revolutions 260-265, LVS/AOT testing

* 03 January 1995 to 12 January 1995 EE1 Dry run in preparation for SVT1 with S/C

* 27 March 1995 to 03 April 1995 EE2 Pre testing revolutions 227-233 AOT Testing

* 05 April 1995 to 12 April 1995 EE2 Dry run in preparation for SVT2 with S/C

References:

1. C. Breneol "ISO Instrument Simulator: The Role of the User". Third Workshop on Simulators for European Space Programmes. ESA wpp-084, 15-17 November 1994

2. R. Smietana and K. Booty. "The ISO Operational Training Simulator". Proceedings of the 2nd ESA workshop on Simulators for the European Space Program. 25-27 November 1992.

3. R.M. Golding and C.J. Todd. "The Infrared Space Observatory Instrument Simulator (IIS)". Proceedings of the Conference on Modelling and Simulations 1994 eds Guash and Huber, page 624. Barcelona, Spain.