2000-05-04


Development plan for the DRCU simulator (DRCU-sim)


1. Background.

The Stockholm Observatory has agreed to deliver a software simulator for the SPIRE that as far as possible shall mimic the behaviour of the real instrument. It is clear that this work cannot be carried out in full detail until SPIRE becomes fully characterised, but at that moment there will be very little time to construct a simulator. For this reason the construction of the real instrument and the simulator has to happen in parallel. When the need for a separate real time simulator of the SPIRE, less digital processor unit (DPU), appeared it was judged natural to regards this simulator as part of the development of the (full) SPIRE simulator.


2. Purpose.

The DRCU-sim will first be used for testing the DPU and later for replacing (at least partly) the DRCU+FPU in the AVM.


3. Basic specifications

The DRCU-sim shall interface to the DPU in the same way as the DRCU and react to commands in a similar way as the DRCU (+FPU). By Œsimilar¹ is understood the same data format and transmission details as a minimum. In addition, the DRCU-sim shall have the capacity to produce realistic signal levels etc. when the behaviour of the SPIRE sub-systems become gradually better defined. It is understood, however, that the degree of sophistication will be limited by the capacity of a (fast) PC and (essentially) high level programming.


3. Preliminary development plan.

a) Before May 2000.

Three critical areas have been investigated: 

I. The speed requirements in generating and bit-coding the anticipated data flow.  

It is found that a standard PC, high level coding for the data generation and assembler coding for the bit encoding fulfil the expected requirement.

II. Operations in a Œfree-running¹ mode.

As a possible mode of operation would be Œfree-running¹, it is required that input commands shall be noticed and effectuated without (if required) interrupting on-going processes.

A solution for this (possible) requirement has been identified and tested for a standard serial command line.

III. Conforming to the required transmission format.

The previously specified synchronous DATA+CLOCK+GATE transmission deviate from all current standard serial data transmissions and a special solution is being investigated. 

It is understood that this transmission definition may change and if a solution is found that will conform to a common standard it will simplify the communication solution for the DRCU-sim. 

b) June 2000 ­ July 2001

It is assumed that the transmission lines will be defined in May 2000, and the first action will be to establish these. Depending on the choice of standard (or non-standard) this work may be either straight-forward or complicated and time-consuming. 

To proceed the coding of the first version of the DRCU-sim, it is understood that the following information will be made available:


I.	 A list of basic Œsetting¹ commands with defined parameters, including the range of the parameters.

Ex1.   BSM,v1,v2 ;set beam steering mirror in pos v1, v2; 0<v1<1024, 0<v2<2048

Ex2.   BIAS_ARR_1, b ; set bias level = b for Array 1 ; 0<b<256


II.	 A list of Œrequesting¹ commands with defined signal responses (including formats)

Ex1. READ_ARR_1 ; Read Array 1, data format: 9columns X 12rows, 16 bits integers(leading byte: MSB, trailing byte: LSB)

Ex2. READ_T23 ; read temperature probe 23; integer (MSB LSB)


III. A list of (preliminary) composite commands (if at all included in the DRCU capacity)

Ex1. SCAN_COMB_1,5,348  ; perform combination 1 (house-keeping combination No3, Array 4 and Array 5, MBS in FTS position), 5 scans, 348 frames ; data format: .......


b) July 2001 ­ (AVM)

A gradual refinement shall be implemented that accounts for the actual behaviour of the hardware. E.g. a new setting of a detector bias level should be reflected in the DC level and the noise of the signal and the response of a new setting of the beam steering mirror should include a typical relaxation of the positional error signals.

In addition to normal operation, the AVM testing includes the propagation of malfunctions. It is assumed that such malfunctions are defined well in advance of the AVM testing and that the physical consequences are estimated for the subsystems. It should be realised that the DRCU simulator is not expected to be based on full physical descriptions of the subsystems, but rather on schematic, parameterised models. If, for example, the switch-off command to a heater may fail it could well influence the performance of the detectors. A complete physical model of the focal plane and the detectors would be required to simulate such an event and this is beyond the scope of the simulator. On the other hand, the list of parameters may well include entries defining malfunctions (i.e. in addition to the list of settings and readings).