XMM Optical Monitor

MULLARD SPACE SCIENCE LABORATORY UNIVERSITY COLLEGE LONDON Author: David Lumb, PSU

DPU Software Validation Plan

DOCUMENT: XMM-OM/PENN/SP/0006.draft 3-May-94

CHANGE RECORD

ISSUE DATE  PAGES  COMMENTS

CHANGED

Draft 3-May-94  skeleton

1 Overview

One of the major concerns for the validation of the DPU software is the complex multi-task nature of its operation. It is the general intent that the low-level operating system code will be fixed and immutable once proven in the development phase. Thus the science data acquisition code which can be changed or re-programmed to suit science operations, changes in instrument configurations or performance, mission operations alteration etc., must be capable of verification and validation before implementing on the flight unit. The code must be verified, not only for its functional integrity, but also for performance compatibility.

This doocument provides a description of the means by which this verification process is accomplished in the current development environment, as a paradigm for the mode to be used in the flight program. Specific features which require performance validation are also listed, wherever possible linked to spexifix items from the Software Requirements Document.

This draft issue of the Validation plan is designed to be informative for the outside reader, and to illicit comments and suggestions from the rest of the OM consortium.

2 Validation Process

—————— It is forsee that there are two major aspects to the validation of the high-level science data acquisition code:

Firstly, where the code may be revised for a change in features, fixing bugs or other substantive revision. In this case it must be demonstrated that the basic functionality has not been compromised.

Secondly, when a stable code revision has been tested, it must be tested for the wide range of operating parameters which may be encountered in flight, and to ensure that the key performance requirements are met.

This validation is completed by simulation and emulation.

3 Emulation

A detailed end-to-end simulation of the whole instrument is being developed by the consortium. Currently this already employs a detailed representation of the capture of realistic astronomical fields by the MIC detector, and the operation of the DPU, to produce the final image data sent from DPU to ICU.

The release version of code may be checked out of the controlled code directory, and the relevant modules revised in response to the perceived requirements. When the developer believes that the new development cycle has finished, the entire end-to-end simulation is run with the new code embedded, on a Sun workstation. The output data are compared with previous runs using the release version of code, to validate that the data are consistent. While the ’C’ code algorithms may be essentially identical to the DPU code, file I/O can only emulate the functionbality of the DPU OS.

When the Software Scientist is satisfied with the new configuration, the code will be used to re-program a copy of the DPU hardware which is resident at the developers’ site (currently SNLA). The same input simulation files may be passed to the DPU by a ”Telescope Interface Simulator”, and the data outputs captured by an ”ICU Simulator” card. The resulting data are compared with the output of the simulations run on the SUN to validate the results. This phase completes the functional nature of validation.

4 Performance simulation

In order to confirm that the software is able to comply with all the performance requirements a number of key features must be demonstratable. This will be performed by a test of different astronomical targets, supplied as simulation data files. The range of these data will include pathological cases to exercise the DPU features, and representative star fields chosen to populate a large parameter space in the specimen mission plan.These will be used for simulation both in a Sun implementation and with the hardware.

Acquisition : The target acquisition will be tested by varying the number and distribution of guide stars. The HST catalog will be used to select cases around expected XMM targets, in typical high and low galactic fields, and with artificial distributions generated by hand. The nominal mode will be with a V filter band but other cases will be trioed, and both BLUE and RED detector operation simulated for the acquisition. The time required for denerating the position solution, and accuracy compared with the known inputs will be compared with the minimum specification required. Failure modes will be deliberately generated, to test the autonomous mode of operation for default set-up, and for exercising the real-time aspect of the interaction with the SOC.

Tracking: The same parameters of number of usable reference stars and their distribution will be important for the tracking of the OM pointing direction. Similarly the minimum specifications for accuracy and calculation time must be demonstrated for each case. In addition for any star field, the effect of different filter bands must be addressed. Failure handling modes can be tested by deliberately introducing pathological fields. Other operationla parameters which must be tested include the use of both BLUE and RED detectors data for tracking, variation in observer-selected windows configuration and integration times. Data products automatically produced such as a verbose tracking history will be compared with the input tracking data to examine the tracking accuracy as a function of all the above variables.

The effect on reference star selection and tracking as a function of paramterized ”goodness” criteria, statistical weighting etc.. This will be done both for the case of manual intervention at observation set-up, and during autonomous tracking..

Other science modes: Fast mode data products must be tested, not only for ability to collect data at the highest rate (of order 10msec resolution), but also for accuracy. the simulation data will be designed to include manually specified temporal fluctuation examples. Comparison of input and output data streams will be made for the same sets of variables as above. Particular care will be taken to examine effects of degraded tracking accuracy on FAST data products, presence of nearby contaminating stars, and pathological cases of window size, position resolution combinations.

Thresholdmode is essentially derived by an identical algorithm as FAST mode. Similar simulation date saets and pathological cases will be tested.

Bright star mode is a special case and tested by manually generating pathologicalsets of data for stars brightening to different magnitudes, in order to see the threshold of DPU detection and accuracy are as expected.

5 Failure testing

An important aspect of validation is to ensure that autonomous handling of errors and failure modes is graceful and predictable. The following are typical of the sorts of failures which will be tested by simulation

1. Apparent variability of guide stars beyond expected bounds of Poissonian count variation

2. Detector data parity errors

3. Data input rate exceeding specified bounds

4. Intermittent input data loss

5. lack opf appropriate ICU response

6. TBD

6 General mission simulation

In addition to all pathological simulations, a typical mission simulation derived from representative sources will comprise not less than 2 full 48 hour orbit phases

7 In-orbit operations phase

The DPU consortium will maintain two breadboard units of the DPU together with suitable EGSE (for example a unit at instrument level maintained in Europe, and one DPU with DPU EGSE in the US TBC). These will be utilized for continued support of software validation during in-orbit operations in the same manner as discussed above.

Subject to further discussion with ESA, as this validation plan is developed, the DPU consortium will provide the validation and simulation software as necessaryto support the ESA SOC as required.