INT-PF-4

Controls for the INT PFC:
Software Requirements

Guy Rixon

Issue 1.1; 19th December 1994

Royal Greenwich Observatory,
Madingley Road,
Cambridge CB3 0EZ

Telephone (0223) 374000
Fax (0223) 374700
Internet gtr@ast.cam.ac.uk

Contents

1 Introduction 4

1.1 Purpose of this document 4

1.2 Scope of the system 4

1.3 Definitions, acronyms and abbreviations 4

1.4 References 4

2 General description 5

2.1 Relationship to current projects 5

2.2 Relationship to past and future projects 5

2.3 Function and purpose 5

2.4 Environment 5

2.5 Interaction with other systems at the INT 6

2.6 General constraints 6

2.7 Model description 6

2.7.1 Observe_with_PF 8

2.7.1.1 Control SCCDs 9

2.7.1.1.1 Command_CCDs 10

2.7.1.1.1.1 SEM for Command SCCDs 11

2.7.1.1.1.2 Accept_commands 12

2.7.1.1.1.3 Reject_commands 12

2.7.1.1.1.4 Change_CCDC_settings 12

2.7.1.1.1.5 Reset_CCDC 13

2.7.1.1.1.6 Readout_CCDs 14

2.7.1.1.1.7 Clear_CCDs 14

2.7.1.1.2 Drive_CCDS 15

2.7.1.1.3 Report_CCD_activity 16

2.7.1.1.3.1 Detect_readout_format 16

2.7.1.1.3.2 Detect_state_change 17

2.7.1.1.3.3 Detect_readout_speed 17

2.7.1.1.3.4 Detect_clear_speed 18

2.7.1.1.3.5 Detect_temperature 18

2.7.1.1.3.6 Detect_reset 18

2.7.1.2 Control_shutter 19

2.7.1.2.1 Monitor_shutter 19

2.7.1.2.1.1 Determine_shutter_position 20

2.7.1.2.1.2 Update_exposure_time 20

2.7.1.2.1.3 Detect_clamp_state 20

2.7.1.2.1.4 Determine_coverage 20

2.7.1.2.1.5 Report_shutter_state 21

2.7.1.2.2 Position_shutter 22

2.7.1.2.2.1 Clamp 22

2.7.1.2.2.2 Release 23

2.7.1.2.2.3 Detect_shutter_in_position 23

2.7.1.2.2.4 Monitor_shutter_command 23

2.7.1.2.2.5 Detect_end_of_exposure 24

2.7.1.2.2.6 Drive 24

2.7.1.2.2.7 Hold 24

2.7.1.3 DAS_server 26

2.7.1.3.1 Parse_DAS_command 27

2.7.1.3.2 Report_DAS_state 28

2.7.1.3.3 Manage_run 29

2.7.1.3.3.1 Capture_pixels 29

2.7.1.3.3.2 Assemble_image 30

2.7.1.3.3.3 Assemble_FITS_header 31

2.7.1.3.3.4 Save_FITS_file 31

2.7.1.3.3.5 Record_current_parameters 32

2.7.2 Data Dictionary 32

3 Specific requirements 64

3.1 Overall system behaviour 64

3.2 Control of SCCDs 64

3.2.1 CCD controller and local code 65

3.2.2 Monitoring the CCDs 65

3.2.3 Stored settings 65

3.2.4 SCCD commands 66

3.3 Data-acquisition 66

3.3.1 Parsing DAS commands 67

3.3.2 Reporting DAS state 67

3.3.3 Managing runs 67

Appendix A. Document History 68

1 Introduction

1.1 Purpose of this document

The software requirements come from an analysis of the user requirements (document INT-PF-1) and are a list of features that must be present in the delivered system. This document presents the analysis, records the rationale of the software requirements and presents the requirements in an auditable list.

Engineers working on the PFC controls should be fully familiar with the software requirements. Astronomers interested in the instrument are invited to read this document to validate the requirements.

1.2 Scope of the system

INT-PF-1 defines two quasi-independent systems for the INT PFC: the control system to drive the camera and telescope and the data-handling system to manage the data after observation. The analysis below is concerned almost entirely with the control system. See INT-PF-1 for a description of objectives and benefits.

1.3 Definitions, acronyms and abbreviations

PFC Prime-Focus Camera

1.4 References

[1] INT Prime-Focus Camera: User Requirements for Control
Technology-division document INT-PF-1.

2 General description

2.1 Relationship to current projects

The PFC-controls project runs in parallel with the INT-DAS project, which is concentrated on observations at the Cassegrain focus. The systems delivered by these two projects will share some programs and software-libraries.

There is no direct connection with current projects for the WHT.

2.2 Relationship to past and future projects

The systems for the PFC will be `complete' at or soon after commissioning. No follow-up projects are planned for this focus and any small changes in the years of operation will be done by OPerations division as routine maintenance. However, if the INT TCS is replaced, a small project may be launched to adapt the PFC controls to the new system.

The PFC systems replace the ADAM system for instrument control. INT-PF-1 discusses the areas wher the new system is expected to improve on ADAM.

2.3 Function and purpose

The primary functions of the two sysetms are as follows.

Control system:

z control the acquisition of targets by the INT, including operation of the autoguider;

z control observations with the PFC, including choice of filters and shutter operations;

z record observations on disk, including construction of a FITS file-header;

z provide programmable (CLI) and interactive (GUI) access to the above functions;

z provide continual feedback to the observers on the state of the system;

z log events during observing for engineering and quality-control purposes.

Data-handling system:

z construct the log of observations for each night, including commentary by the observers;

z write tapes of the observations for the observers and for the Lap Palma Archive;

z display the observations for immediate assessment by the observers;

z feed observations to data-reduction systems as appropriate.

See INT-PF-1 for more details of the instrument and the operation.

2.4 Environment

The systems will run at the INT and also in Cambridge to allow some support in the first few months of operation. At the INT, the control system will be typically be operated by one observer (driving the camera) and one TO (acquiring targets for the observer). Often, a second observer will use the data-handling system in parallel with observations to assess the data. It also likely that the on some nights one astronomer will run the entire operation. In cambrige, the systems are likely to be used by one engineer at a time. In fact, Cambridge operation will probably involve only a few pieces of the system at a time.

Most of the software runs on SPARCstations in the Solaris 2 operating environment. In the final system, one SPARCstation is supplied for each of the two systems; at Cambridge, a single SPARCstation 5 is available for engineering.

The autoguider system runs in a standard VME-based computer of the kind used at the WHT. The autoguider systems is, so far as is possible, a clone of the WHT FORTH system. One autoguider computer has been purchased for the project and will serve as both development and target platform.

The CCDCs are based on the Phase-II units for the WHT. The controller for the sciences CCDs (SCCDs) is modified to drive four CCDs at once. The controller for the autoguider CCD (ACCD) is a standard unit.

2.5 Interaction with other systems at the INT

The control system is interfaced closely to the TCS to allow control of target-acquisition and exposures from one point and to enable autoguiding. Apart from this, the control system is autonomous. The interface between the control system and the TCS is described in document [TBD].

The data-handling system interfaces to the control system by picking up observation files in FITS format; the two systems see some common disk-space. There is no hand-shaking between the control system and the data-handling system. Instead, the data-handling system uses the FITS headers and the file-modification times to manage the observations. The interface between the systems is descibed in document [TBD].

The data-handling system `interfaces' with the La Palma archive through the FITS tapes sent back to Cambridge. The tapes must be written to a particular standard, described in document [TBD].

The data-handling system interfaces to the data-reduction systems, which are poorly defined at this time. The minimal requirment is to make the observations available, on disk, to general programs from the IRAF environment. IRAF must be able to modify some copy of each observation without any risk of changing the raw data which goes to the archive. As a refinement, the data-handling system should provide some interface to a data-reduction pipeline that operates automatically on all suitable observations.

The log of observations from each night is retained by the observatory and stored as a record of operations and as an adjunct to the Archive. Acceptable forms of the log are descibed in document [TBD].

2.6 General constraints

All deliverables in the PFC systems must be maintainable by Operations division. It is not helpful to introduce new, comercial tools, either for programming or for documentation. The system must be delivered with all special tools and supporting software needed.

It is quite probable that parts of the PFC systems will be re-used at the JKT and WHT. The data-handling system is the obvious candidate. All assemblies should be assessed for generality and potential for re-use.

2.7 Model description

The model presented here describes the operation of the control system in terms as general as is possible while retaining clarity. The decomposition is strongly biased by the choices of hardware already made.

dfd Context-Diagram

2.7.1 Observe_with_PF

2.7.1.1 Control SCCDs

dfd 5

2.7.1.1.1 Command_CCDs

dfd 5.1

2.7.1.1.1.1 SEM for Command SCCDs

sem 5.1-s1

2.7.1.1.1.2 Accept_commands

Input

SCCD_command_packet : data_in

Function

Accept any command presented on SCCD_command_packet.Write the command packet put to the store Commands_in_progressand generate SCCD_event as appropriate:

Generate "Begin clear" if the command is "Clear";Generate "Begin readout" if the command is "Readout"Generate "Begin settings if the command is "Readout format"Generate "Begin settings if the command is "Clear speed"Generate "Begin reset" if the command is "Reset"

If the command carries parameters Readout_format or Clear_speed,write these out to the store of required settings.

Outputs

Clear_speed : data_out

Readout_format : data_out

SCCD_event : control_out

SCCD_command_packet : data_out

Notes

2.7.1.1.1.3 Reject_commands

Input

SCCD_command_packet : data_in

Function

Reject all commands input on SCCD_command_packet except Reset;output Status_packet for these commands showing that they havebeen rejected.

If a reset command appears, write it out to the store Commands in progressand set SCCD_event to "Begin reset".

Outputs

SCCD_event : control_out

SCCD_command_packet : data_out

Status_packet : data_out

Notes

2.7.1.1.1.4 Change_CCDC_settings

Input

SCCD_unet_status : data_in

Clear_speed : data_in

Readout_speed : data_in

Readout_format : data_in

SCCD_command_packet : data_in

Function

(1) Check the required settings against the currentvalues and generate a list of Unet commands to the CCDC that will makethem match (discard any Unet commands left over from previous invocationsof this process).

(2) Output Status_packet to show that an action is in progress. Include the command ID from SCCD_command_packet.

(3) Output SCCD_unet_command(s) to start the action.

(4) Monitor SCCD_unet_status to see when the action finishes. Detect(a) normal completion; (b) failure/rejection by the CCDC;(c) action cancelled by reset ofthe CCDC; (d) no response from CCDC.

(4) Set SCCD_event to "End settings"

(5) Output Status packet to show that the command completed or failed.Take the command ID from SCCD_command_packet.

Outputs

SCCD_event : control_out

Status_packet : data_out

SCCD_unet_command : data_out

Notes

2.7.1.1.1.5 Reset_CCDC

Input

SCCD_unet_status : data_in

SCCD_command_packet : data_in

Function

(1) Output Status_packet to show that an action is in progress. Include the command ID from SCCD_command_packet.

(2) Output SCCD_unet_command to start the action.

(3) Monitor SCCD_unet_status to see when the action finishes. Detect(a) normal completion; (b) no response from CCDC.

(4) For each command in the store Commands_in_progress (sampled onSCCD_command_packet), output Status packet. For any reset command,show successful completion; for all other commands, show that the commandwas cancelled by the reset.

Outputs

SCCD_unet_command : data_out

Status_packet : data_out

Notes

2.7.1.1.1.6 Readout_CCDs

Input

SCCD_unet_status : data_in

SCCD_command_packet : data_in

Function

(1) Output Status_packet to show that an action is in progress. Include the command ID from SCCD_command_packet.

(2) Output SCCD_unet_command to start the action.

(3) Monitor SCCD_unet_status to see when the action finishes. Detect(a) normal completion; (b) failure/rejection by the CCDC;(c) action cancelled by reset ofthe CCDC; (d) no response from CCDC.

(4) Output Status packet to show that the command completed or failed.Take the command ID from SCCD_command_packet.

Outputs

SCCD_unet_command : data_out

Status_packet : data_out

Notes

2.7.1.1.1.7 Clear_CCDs

Input

SCCD_unet_status : data_in

SCCD_command_packet : data_in

Function

(1) Output Status_packet to show that an action is in progress. Include the command ID from SCCD_command_packet.

(2) Output SCCD_unet_command to start the action.

(3) Monitor SCCD_unet_status to see when the action finishes. Detect(a) normal completion; (b) failure/rejection by the CCDC;(c) action cancelled by reset ofthe CCDC; (d) no response from CCDC.

(4) Output Status packet to show that the command completed or failed.Take the command ID from SCCD_command_packet..

Outputs

SCCD_unet_command : data_out

Status_packet : data_out

Notes

2.7.1.1.2 Drive_CCDS

Input

CCD_telemetry : data_in

Pixel_signal : data_in

CCD_unet_command : data_in

Function

This process represents all processing on the CCDC.Since the CCD is a standard unit, no further analysis is presentedhere. See WHT-CCD-1 for a description of the CCDC's behaviourin response to Unet commands.

In the specific context of the PFC, it is worth noting thatthe CCDC drives all four SCCDs in parallel as one CCD head. This means that CCD_clocks and CCD_telemetry apply to all four CCDs.However, there are four instances of Pixel_signal that are processedto four instances of Pixel_headcode + Pixel_value; a different Pixel_headcode is produce for each CCD.

Outputs

CCD_unet_status : data_out

CCD_Unet_status : data_out

CCD_clocks : data_out

Pixel_value : data_out

Pixel_headcode : data_out

Notes

2.7.1.1.3 Report_CCD_activity

dfd 5.3

2.7.1.1.3.1 Detect_readout_format

Input

Readout_format : data_in

SCCD_unet_status : data_in

Function

Monitor SCCD_unet_status for changes in readout format.When the format changes: (a) write it out to the current-settingsstore; (b) output it as SCCD_parameter_packet.

At all times, compare the current format with the required format.When they are different, set SCCD_event to "Settings drift".

Outputs

SCCD_parameter_packet : data_out

Readout_format : data_out

SCCD_event : control_out

Notes

2.7.1.1.3.2 Detect_state_change

Input

SCCD_unet_status : data_in

Function

Monitor SCCD_unet_status for the beginning and end of readouts and clears.Set SCCD_event to "Begin clear", "End clear", "Begin readout" or "End readout" as appropriate.

Outputs

SCCD_parameter_packet : data_out

SCCD_event : control_out

Notes

2.7.1.1.3.3 Detect_readout_speed

Input

Readout_speed : data_in

SCCD_unet_status : data_in

Readout_noise : data_in

SCCD_Gain : data_in

Function

Monitor SCCD_unet_status for changes in readout speed.When the speed changes: (a) write it out to the current-settingsstore; (b) retrieve the associated value of SCCD_gain and Readout_noiseand output the data together as SCCD_parameter_packet.

At all times, compare the current speed with the required speed.When they are different, set SCCD_event to "Settings drift".

Outputs

SCCD_parameter_packet : data_out

Readout_speed : data_out

SCCD_event : control_out

Notes

2.7.1.1.3.4 Detect_clear_speed

Input

Clear_speed : data_in

SCCD_unet_status : data_in

Function

Detect changes in clear speed from SCCD_unet_status. When the speedchanges: (a) write it out to the current-settings store; (b) writeit out as SCCD_parameter_packet. At all times, compare the current speed with the speed read fromthe required-values store. When the two are different, set SCCD_eventto "Settings drift".

Outputs

SCCD_parameter_packet : data_out

Clear_speed : data_out

SCCD_event : control_out

Notes

2.7.1.1.3.5 Detect_temperature

Input

SCCD_unet_status : data_in

Function

Read the current and required temperature from SCCD_unet_status.When either temperature changes by one degree or more report thisin SCCD_parameter_packet.

Outputs

SCCD_parameter_packet : data_out

Notes

2.7.1.1.3.6 Detect_reset

Input

SCCD_unet_status : data_in

Function

Whenever SCCD_unet_status indicates that the CCDC has been reset, output SCCD_parameter_packet with this information andset SCCD_event to "End reset".

Outputs

SCCD_event : control_out

SCCD_parameter_packet : data_out

Notes

2.7.1.2 Control_shutter

dfd 6

2.7.1.2.1 Monitor_shutter

dfd 6.1

2.7.1.2.1.1 Determine_shutter_position

Input

Shutter_encoder_reading : data_in

Function

Monitor Shutter_encoder_reading and produceShutter_position accordingly. In the conversion,allow for changes in scale, zero-point and sense of rotation.

Outputs

Shutter_position : data_out

Notes

2.7.1.2.1.2 Update_exposure_time

Input

Shutter_covers_SCCDs : data_in

Function

When Shutter_covers_SCCDs falls to below 0.5 [TBC], start timing the exposure: at least once per second,add the extra exposure time to the total time in thestore.

When Shutter_covers_SCCDs rises above 0.5 [TBC],stop timing the exposure.

Outputs

Exposure : data_out

Notes

2.7.1.2.1.3 Detect_clamp_state

Input

Shutter_clamp_reading : data_in

Function

Monitor Shutter_clamp_reading and set Shutter_clampsto Clamped or Free as appropriate. Do not considerintermediate cases.

Outputs

Shutter_clamps : control_out

Shutter_clamps : data_out

Notes

2.7.1.2.1.4 Determine_coverage

Input

Shutter_position : data_in

Function

Determine whether the CCDs are covered by the shutter disc.

Shutter_covers_SCCDs is 1.0 for [TBD] < Shutter_position < [TBD] degrees.Shutter_covers_SCCDs is 0.0 for [TBD] < Shutter_position < [TBD] degrees.In between, Shutter_covers_SCCDs is assumed to vary linearly withShutter_position.

Shutter_covers_ACCD is 1.0 for [TBD] < Shutter_position < [TBD] degrees.Shutter_covers_ACCD is 0.0 for [TBD] < Shutter_position < [TBD] degrees.In between, Shutter_covers_ACCD is assumed to vary linearly withShutter_position.

Outputs

Shutter_covers_SCCDs : data_out

Shutter_covers_ACCD : data_out

Notes

2.7.1.2.1.5 Report_shutter_state

Input

Shutter_clamps : control_in

Exposure : data_in

Shutter_covers_SCCDs : data_in

Shutter_covers_ACCD : data_in

Condition_code : control_in

Shutter_position : data_in

Function

Output Shutter_parameter_packet whenever(1) Shutter_clamps changes;(2) Exposure.Exp_time_required changes;(3) Exposure.Exp_time_totalled increases by one second.(4) Exposure.Finished changes;(4) Condition_code changes;(5) Shutter_covers_ACCD changes by 0.1;(6) Shutter covers SCCDs changes by 0.1;(7) Shutter_position changes by 5 degrees.

Outputs

Shutter_parameter_packet : data_out

Notes

2.7.1.2.2 Position_shutter

dfd 6.2

sem 6.2-s1

2.7.1.2.2.1 Clamp

Input

Function

Apply the clamps to hold the shutter disc.

Outputs

Shutter_clamp_reading : data_out

Notes

2.7.1.2.2.2 Release

Input

Function

Release the clamps holding the shutter disc.

Outputs

Shutter_clamp_reading : data_out

Notes

2.7.1.2.2.3 Detect_shutter_in_position

Input

Shutter_position : data_in

Function

Produce the In_position signal while the measured Shutter_position is within [TBD] degrees of the intended position.

Outputs

In_position : control_out

Notes

2.7.1.2.2.4 Monitor_shutter_command

Input

Shutter_command_packet : data_in

Condition_code : control_in

Function

When Shutter_command_packet arrives check the syntax. Rejectinvalid commands by producing Status packet.

If a valid Set_exposure command is found, output exposure (this goes toa store), then output Status_packet to show that the command completed successfully.

If a valid Position command is found, output the appropriate Shutter_position.remember this command as the current command.

If Condition_code arrives while there is a current command, output Status_packetfor that command and erase the current command.

If another Position command arrives while there is a current command, outputStatus packet to show that the first command was cancelled, then make thesecond command the current command.

Outputs

Status_packet : data_out

Exposure : data_out

Shutter_position : data_out

Notes

2.7.1.2.2.5 Detect_end_of_exposure

Input

Exposure : data_inout

Function

Monitor Exposure, and compare the required and total times.If the total time is greater or equal to the required time, andif the finished flag is not set: (1) close the shutter bysetting Shutter_position to 0; (2) Produce the signalExposure_finished; (3) set the finished flag in Exposure..

Outputs

Exposure : data_inout

Shutter_position : data_out

Exp_finished : control_out

Notes

2.7.1.2.2.6 Drive

Input

Function

Drive the shutter disc at its maximum rate.

Outputs

Shutter_drive_rate : data_out

Notes

2.7.1.2.2.7 Hold

Input

Function

Apply a holding torque to the shutter disc enough to keep itin position with the clamps off.

Outputs

Shutter_drive_rate : data_out

Notes

2.7.1.3 DAS_server

dfd 7

pat 7-s1

2.7.1.3.1 Parse_DAS_command

Input

DAS_command : data_in

DAS_channel_ready : data_in

DAS_channel : data_in

Run_number : data_in

Function

Separate out the parameters of DAS_command and output the values immediately on the appropriate flows.

All parameters corresponding to output flows from this process are specific to one active run and must be written immediately to that run's parameter-store in DAS_orders.If a command specifies a run-number, then the run with that number receives the data. If a command specifies a DAS channel as a parameter then the run affected is the newest on that channel. If an invalid run-number or channel is given, do not alter DAS_orders but instead produce Command_status indicating that the command was rejected.

If the command changes the readout format, assert New_readout_format with the number of the channel affected.

If the command is to abort an observation, assert Abort_observation with the number of the channel affected.

Outputs

DAS_command : data_out

New_readout_format : control_out

Abort_observation : control_out

Readout_format : data_out

N_FITS_descriptors : data_out

Pixel_headcode : data_out

Display_observation : data_out

Save_observation : data_out

FITS_header_packet_name : data_out

Notes

2.7.1.3.2 Report_DAS_state

Input

DAS_channel : data_in

Run_number : data_in

FITS_header_packet_name : data_in

Readout_format : data_in

Readout_progress : data_in

Header_progress : data_in

DAS_command : data_in

Function

Monitor the inputs flows and report changes to DAS_parameter as follows.

DAS_channel_ready, run-number and Readout_format should be reported each time theychange for any channel.

Header_progress and Readout_progress should be reported onece,immediately when they change to or from 0%. These data should be reportedperiodically whenever then are between 0% and 100%; a reporting period in the range 1 second to ten seconds is required.

Outputs

DAS_parameter_packet : data_out

Notes

2.7.1.3.3 Manage_run

dfd 7.3

2.7.1.3.3.1 Capture_pixels

Input

Pixel_value : data_in

Pixel_headcode : data_in

DAS_channel : data_in

Function

Read DAS_channel and Pixel_headcode from DAS_orders.

Invoke the flow Pixel_headcode + Pixel_value by opening a channel to the FOX. Set DAS_channel_ready to true for this channel.

Each time a Pixel_headcode + Pixel_value combination is detected, compare the headcodewith the one from DAS_orders. If they match, capture the pixel and write itto the buffer via Pixel_value.

When all the expected pixels have arrived, or if the readout is aborted or fails in some way, assert Readout_finished and exit.

Outputs

DAS_channel : data_out

DAS_channel_ready : data_out

Readout_finished : control_out

Pixel_value : data_out

Notes

2.7.1.3.3.2 Assemble_image

Input

Pixel_value : data_in

Readout_format : data_in

Display_observation : data_in

N_FITS_descriptors : data_in

Function

Read Pixel_values from the Pixel_buffer as they become available.Calculate the Pixel_offset that describes where each pixel fits in the final image, as determinbed by Readout_format.

If Display_observation is set to True, output Pixel_value and Pixel_offsetto the image-display system.

Convert Pixel_value to its FITS representation.

Output the FITS-converted Pixel_value to Current_FITS_file a part of theflow FITS_image. Place the value in the file at the position indicated byPixel_offset, allowing apce at the beginning of the file for a FITS headerwith a size indicated by N_FITS_descriptors.

After each pixel, update Readout_progress.

When all the expected pixels have arrived, exit.

Outputs

Pixel_value : data_out

Pixel_offset : data_out

Readout_progress : data_out

FITS_image : data_out

Notes

2.7.1.3.3.3 Assemble_FITS_header

Input

Readout_format : data_in

FITS_header_packet : data_in

FITS_header_packet_name : data_in

Function

Construct, from Readout_format, the mandatory FITS descriptors that define the image formatfor Current_FITS_file. Write these descriptors to Current_FITS_file as part of FITS_header.

Read the list of required packets from FITS_header_packet_name; if this is blank, assumeno packets are required; if this flow is set to wait, poll it until it changes to a list of packets or to blank.

Read the required packets, in the order that they were named, from FITS_header_packet, which isa set of separate stores. If any of the stores is locked, wait for it to be unlocked before proceeding. Write the descriptors of each packet to FITS_header.

When all the packets have been read in, write the FITS descriptor Then exit.

Outputs

Header_progress : data_out

FITS_header : data_out

Notes

2.7.1.3.3.4 Save_FITS_file

Input

Run_number : data_inout

Save_observation : data_in

Function

Allocate a new run number: read the last-used number fromthe store Last_run_number, and take a number one greater;write the allocated number back to the store.

Create an empty FITS-file and name it for the allocated runnumber [some naming convention must apply here: TBD]. Make thefile accessible to other processes inside the DAS, but not toexternal processes (set External_access appropriately).Generate the output flow Run_number which goes to the Work_in_progressstore.

If Save_observation is set to "Save", (a) wait forthe other DAS processes to finish writing the file; (b) alter External_access to make the file readable by processes outside the DAS [Question: should it also become writable?]; (c) exit.

If save_observation is set to "Discard", delete the file and exit.

If forced to exit while Save_observation is set to "Wait", delete thefile first (this is typically what happens when an observation is aborted).

Outputs

Run_number : data_inout

Run_number : data_out

File_name : data_out

External_access : data_out

Notes

2.7.1.3.3.5 Record_current_parameters

Input

DAS_channel : data_in

Readout_format : data_in

FITS_header_packet_name : data_in

Function

Echo the input flows, read from the store DAS_orders,to the ouput flows, aimed at the store Work_in_progress.

Outputs

FITS_header_packet_name : data_out

Readout_format : data_out

DAS_channel : data_out

Notes

2.7.2 Data Dictionary

This section contains the data dictionary definitions for the model.

Abort_observation (control flow, del) =
*
Requests that the observation on a DAS channel be aborted.
*
[ "TRUE" | "FALSE" ]
.

Acquisition_command (data flow) =
*
*
[ "Guide loop" Guide_loop_locked |
"Handset" |
"Halt telescope" |
"Acquire" + Target_name ]
.

Acquisition_dialogue (data flow) =
*
The set of message packets concerning target acquisition.
These packets are exchanged by the UI processes and the
central intelligence. See also Camera_packet.
*
[ Acquisition_command_packet |
Acquisition_parameter_packet |
Status_packet ]
.

Acquisition_display (data flow) =
*
A textual/and or graphical display of the state of the
telescope and autoguider.
*
Telescope_state +
<target>Sky_position +
Target_name +
AG_state +
Guide_star_name +
Guide_loop_locked +
Target_list
.

AG_command (data flow) =
*
An instruction to the autoguider to change state
immediately.
*
[ "Guide" + Guiding_integration_time + Guide_window |
"Search" + Search_integration_time + Search_window |
"Stop guiding" ]
.

AG_dialogue (data flow) =
*
The set of message packets concerning autoguiding, not including those
sent to the TCS. These packets are exchanged by the central intelligence
and the AG server.
*
[ AG_command_packet |
AG_parameter_packet |
Status_packet ]
.

AG_parameter (data flow) =
*
One group of related data describing the
current state of the autoguider.
*
AG_state +
Guide_star_position +
Guiding_integration_time +
Guide_window_size +
Seeing_estimate +
Transparency_estimate
.

AG_state (data flow, del) =
*
The current activity of the autoguider.
*
[ "Idle" | "Searching" | "Guiding" ]
.

Camera_dialogue (data flow) =
*
The set of message packets concerning the PFC, excluding
those concerning target acquisition and guiding. These packets
are exchanged between the UI processes and the central
intelligence. See also Acquisition_packet.
*
[ Camera_command_packet |
Camera_parameter_packet |
Status_packet ] .

Camera_display (data flow) =
*
A textual and/or graphical display of the state of
the filter wheel, shutter and science CCDs.
*
N_exposures +
Observation_type +
Data_disposal +
CCD_state +
Exposure_time +
Run_number +
Nth_exposure +
Exposure_progress +
Readout_progress +
Filter_name +
Filter_position +
Shutter_position +
Readout_format +
SCCD_set_temperature +
SCCD_actual_temperature +
Pause_state
.

CCD_clocks (data flow, cel) =
*
The set of analogue signals used to move photo-electrons
from pixel to pixel in the CCD and ultimately into the
readout register.
*
.

CCD_description (data flow) =
*
Feedback on the current state of the science CCDs.
*
CCD_state +
Readout_details +
CCD_temperature
.

CCD_frame (data flow) =
*not-defined*.

CCD_image (data flow) =
*
A set of CCD pixels, possible from several separate windows in
one CCD frame, reconstructed into a rectangular image.
*
{CCD_pixel_value}
.

CCD_state (control flow, del) =
*
An activity actual, or requested, of the science CCDs. This describes the normal
idle-clear-expose-readout-idle cycle. Inferring this datum requires
a memory of the recent activity on the system. For example, to distinguish
"Exposing" from "Idle", a program must remember that the CCD has been cleared
and that the shutter is open.
*
[ "Idle" |
"Clearing" |
"Cleared" |
"Exposing" |
"Paused" |
"Exposed" |
"Reading" |
"Aborted" ]
.
.

CCD_telemetry (data flow, cel) =
*
The set of analogue signals indicating the health of the
CCD. Includes temperature of the cryostat.
*
.

Clear_speed (data flow) =
*
The speed at which the CCDs can clear.
*
[ "Standard" | "Quick" ]
.

Command_instance (data flow, cel) =
*
This distinguishes instances of the same command. It does
not show what the command was - see Command_type for that
data.
*
.

Command_stage (data flow) =
*
This shows how far a command has progressed.
An instance of a command may cause several `pending'
and `active' reports, but it will always cause exactly
one `finished' report. A finished command may have
completed, failed or been rejected and this distinction
is made by the accompanying Condition_code.
*
[ "Pending" |
"Active" |
"Finished" ]
.

Command_type (data flow, del) =
*
This identifies a command, e.g. "Select filter", uniquely
within the whole control system. It does not distinguish
instances of a command - see Command_instance for that
data.
*
.

Commands_in_progress (store) =
*
List the commands for which Status_packet must eventually
be produced.
*
{SCCD_command_packet}
.

Comment_FITS_descriptors (data flow, pel) =
*
Zero or more FITS descriptors containing commentary added
by the observer.
*
0{ "COMMENT <comment text>" }N
.

Condition_code (control flow, del) =
*
A code indicating an error in some part of the system.
There is one code for `situation correct and normal' which
is shared by all parts of the system. Otherwise, the codes
are unique throughout the system, e.g. `SCCDs overheating'
and `ACCD overheating' would be different codes.
*
.

Continuous_clear (data flow) =
*
*
[ "On" | "Off" ]
.

Current_exposure (store) =
*
The exposure times that the Shutter sub-system is
currently working with.
*
Exposure
.

Current_filter (store) =
*
A record of the filter currently in the beam. This
information is normally available when the control processes
start up.
*
Filter_id
.

Current_FITS_file (store) =
*
The FITS file used to store the most recent observation.
While the observation is being acquired, the file has some
default name known to the processes of the DAS and
External_access is set to False: the file may not be
used by processes outside the DAS. To `export' the
file for archiving, File_name is set to a unique name
including the run number and External_access is set to true:
other processes may then read the file, as shown by the flow
FITS_file out of this store.
*
File_name +
External_access +
FITS_header +
FITS_image
.

DAS_channel (data flow) =
*
The channel of the DAS (actually of the S330A device) on
which data are acquired.
*
[ "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" ]
.

DAS_channel_readiness (store) =
*
This store records for each of eight DAS channel whether the channel is ready
to receive a readout. Initially, all eight channels are unready. A store is
used because this information must exist even when no processes
are present to generate the flows.
*
1{ DAS_channel +
DAS_channel_ready }8
.

DAS_channel_ready (control flow) =
*
Indicates that the named DAS-channel is ready to receive a readout.
*
[ "TRUE" | "FALSE" ]
.

DAS_channel_state (data flow) =
*
The current activity of a DAS channel.
Readouts should only be requested when the state
is "waiting for data".
*
[ "Waiting for image format" |
"Waiting for data" |
"Receiving data" ]
.

DAS_command (data flow) =
*
A change-state command to the DAS.

The "Format" command arms a DAS_channel for data-acquisition, setting the
required image and file formats. Once armed, the channel is continously
ready for data in the same format and does not need to be rearmed after each
observation. "Format" can be repeated to change the associated parameters:
such a change does not affect observations that have started to read out.

The "FITS" command tell the DAS which header packets to collect for a
given channel. It need only be sent once and then applies to all subsequent
observations on the channel. If there are no packets to collect,
FITS_header_packet_name is made blank. Until this command is sent, only the
mandatory FITS headers will be written in each observation.

The "Abort" command terminates the observation with the given run-number.
The associated FITS-file is destroyed. If "Abort" is sent during a readout,
the readout itself is not aborted and the channel does not become free until
the readout is finished; the "Abort" is not considered to have finished until
the channel is free.

The "Save" command authorizes the DAS to export the data with the given
run-number. When this run is complete, its file will be made available to
processes outside the DAS.

The "Display" command causes the DAS to write all pixels aquired on the given
channel to the image-display system for immediate display. This feature allows
the display to be updated while the image is reading out and before the FITS
file is available.

For each command, stati are returned to the client. Each status-packet will indicate
the progress of the command from the set "In progress", "Rejected", "Complete", "Failed";
"rejected" and "failed" will carry condition-codes and textual error-messages.

DAS_current_state (store) =
*
For each of eight channels, variables giving the state of thte channel.
*
1{ Readout_progress +
Header_progress +
Readout_format +
Run_number }8
.

DAS_description (data flow) =
*
A description of the activity on each acquisition channel.
For Prime Focus, there are four channels. The DAS can,
in principle, handle up to eight.
*
4{ DAS_channel_state +
Readout_details +
Run_number }4
.

DAS_dialogue (data flow) =
*
The set of message packets concerning recording
of observations. These packets are exchanged
by the central intelligence and the DAS server.
*
[ DAS_command_packet |
DAS_parameter_packet |
Status_packet ]
.

DAS_instruction (data flow) =
*
An instruction to the DAS to change state immediately.
*
[ "Set format" + Readout_details |
"Archive current observation" |
"Save current observation to scratch space " |
"Abandon current observation" ]
.

DAS_orders (store) =
*
This store contains parameters that must be applied to current observation.
Each active run has a separate set of parameters and there can be at most two
runs active on each channel (e.g. one reading out and one being written to disk).
Some of the parameters persist between observations: hence the use of a store.
*
1{ DAS_channel +
Readout_format +
N_FITS_descriptors +
FITS_header_packet_name +
Pixel_headcode +
Run_number +
Save_observation +
Display_observation }16
.

DAS_parameter (data flow) =
*
Any datum/data that the DAS send to its clients to explain what it is doing.
*
[ Header_progress |
Readout_progress |
Readout_format |
Run_number ]

DAS_parameter_packet (data flow) =
*
A parameter-packet describing some part of the state of the
DAS server.
*
[ DAS_channel + Readout_format |
DAS_channel + error_codes |
DAS_channel + FITS_header_packet_name |
DAS_channel + DAS_channel_ready |
Run_number + DAS_channel + Readout_progress + Header_progress + Save_progress ]
.

Data_disposal (data flow) =
*
Indicates what will happen (or has happened)
to an observation. "ARCHIVE" implied that the observation
passes to the DHS; "SCRATCH" implies that it is retained
in a scratch file and not passed to the DHS; "DISCARD"
implies that the observation is destroyed.
*
[ "ARCHIVE" |
"SCRATCH" |
"DISCARD" ]
.

Dec (data flow, cel) =
*
This datum is the declination of the target.
*
.

Dec_offset (data flow, cel) =
*
A small displacement of the telescope from the catalogued position of the current target.
The displacement is measured in arcseconds on the sky in the Declination direction.
*
.

Display_observation (data flow) =
*
Determines whether the image is piped to the image-display system as
pixels are read out.
*
[ "True" | "False" ]
.

END_FITS_descriptor (data flow, del) =
*
A mandatory FITS descriptor marking the end of the
FITS header.
*
"END"
.

Epoch (data flow, cel) =
*
The date, given as a year-number with a fractional part,
to which the given RA and declination refer.
This information is only relevant if non-zero proper
motions are given.
*
.

Equinox (data flow, cel) =
*
The equinox (calender system and year, including fractional
years if necessary) associated with the RA and dec.
For example, B1950 for Besselian 1950.0; A1994.4 for
apparent coordinates at the 146th day of 1994.
*
.

Error_message (data flow, cel) =
*
A message in English describing an error. Messages
should be kept to three or fewer lines per error.
*
.

Exp_finished (control flow, del) =
*
Shows, independtly of the exposure time, whether an
exposure is finished.
*
[ "TRUE" | "FALSE" ]
.

Exp_time_required (data flow, cel) =
*
The time, in seconds, for which an exposure should last.
The time may be totalled over several exposures leading
to one SCCD readout. C.f. Exp_time_totalled.
*
.

Exp_time_totalled (data flow, cel) =
*
The time, in seconds, for which an exposure has lasted
so far. This value may be totalled over several exposures.
C.f. Exp_time_required.
*
.

Exposure (data/control flow, cel) =
*
Describes the timing of an exposure of the SCCDs.
*
Exp_time_required +
Exp_time_totalled +
Exp_finished
.

Exposure_progress (data flow, cel) =
*
The number of seconds exposed so far in the
current exposure.
*
.

Exposure_times (store) =
*
The exposure time, possibly totalled over several
exposures, recorded by the shutter.
*
<total>Exposure_time+
<required>Exposure_time
.

External_access (data flow) =
*
Indicates whether the `current' FITS-file for a channel
of the DAS may be read by processes outside the DAS.
*
[ "True" | "False" ]
.

File_name (data flow, cel) =
*
The name of a FITS file in which an observation has been
saved. This datum applies when the file has been given
a unique name for puposes of archiving; the local,
temporary name used before archiving is not a data flow.
*
.

Filter_command_packet (data flow) =
*
The set of commands from the central intelligence to the
filter server. The Identify-filter command specifies the
position-name mappings for one of the six positions in the
filter wheel.
*
[ "Select filter" + Filter_id |
"Identify filter" + Filter_id ]
.

Filter_dialogue (data flow) =
*
The set of message packets concerning the PFC filter-wheel.
These packets are exchanged by the central intelligence
and the filter-wheel server.
*
[ Filter_command_packet |
Filter_parameter_packet |
Status_packet ]
.

Filter_drive_rate (data flow, cel) =
*
The rate of rotation required at the shaft of the
filter wheel.
*
.

Filter_encoder_reading (data flow) =
*
The angular position of the filter wheel shaft,
measured in arbitrary encoder units. The encoder
has a fixed zero point.
*

Filter_holder_code (data flow, del) =
*
A code that uniquely identifies a filter holder. The code
corresponds to a name which is known to the system; the set
of names/codes is closed.
*
.

Filter_holder_ids (store) =
*
The translations between codes for filter holders and
names for filter holders.
*
{ Filter_holder_code + Filter_holder_name }
.

Filter_holder_name (data flow, del) =
*
The name of a filter holder. This may be different from
the name of the filter in the holder; e.g., holder "USER1"
may be loaded with the filter "Halpha".
*
.

Filter_holder_read (data flow) =
*
A flag to control the system's reaction to the
filter-holder codes. When true, the system updates
the record of which holders are in the wheel each time the
wheel moves. When false, the system ignores the reports.
*
[ "TRUE" | "FALSE" ]
.

Filter_id (data flow) =
*
A specification of a filter/filter wheel position containing
four data of which up to three may have indeterminate values.
At least one of the data must have a definite value.
*
Filter_wheel_position +
Filter_holder_code +
Filter_holder_name +
Filter_name
.

Filter_index_position (data flow, cel) =
*
The angular position, in encoder units, that the
filter-wheel shaft should be at when a given filter is
in position for observing.
*
.

Filter_name (data flow, del) =
*
The name of a filter, from the set currently loaded in the
filter wheel. This name may be different from the name of
the filter holder.
*
.

Filter_parameter_packet (data flow) =
*
Data describing the state of the filter-wheel. The first form of
the packet is sent when the wheel moves. The second form is sent
when filters may have been mounted or dismounted. Note that
Filter_id is a composite item.
*
[ Filter_id + Filter_wheel_position + Filter_wheel_state |
Filter_id ]
.

Filter_table (store) =
*
A command to move the filter wheel. The wheel can either
be sent to a named filter, to a numbered position or to
an absolute angular position.
*
[ Filter_name |
Filter_number |
Filter_wheel_position ]
.

Filter_thickness (data flow, cel) =
*
The optical thickness (physical thickness times
refractive index) of a filter.
*
.

Filter_wheel (store) =
*
A list of the filters and holders mounted in the filter
wheel. The last-requested position of the wheel is also
stored, for use if the system is restarted.
*
<required>Filter_position +
6{ @ Filter_position +
Filter_name +
Filter_holder_name +
Filter_thickness }6
.

Filter_wheel_contents (data flow) =
*
A listing, for each of six filter positions, showing
what is in the wheel.
*
6{ Filter_id }6
.

Filter_wheel_position (data flow, cel) =
*
An angular position of the filter wheel. The
wheel can rotate through a full circle.
*
.

Filters_mounted (store) =
*
A list of attributes for the six filter-holders
currently mounted.
*
6{ @ Filter_position +
Filter_holder_name +
Filter_name +
Filter_thickness }6

FITS_file (data flow) =
*
A file in FITS format as formally defined by NOST.
*
FITS_header +
FITS_image
.

FITS_file_name (data flow, pel) =
*
The identity of the file. If the file is to be preserved
it must be given a unique name.
*
.

FITS_header (data flow) =
*
A collection of FITS descriptors describing the associated
FITS image and the circumstances under which it was
observed.
*
{Mandatory_FITS_descriptor} +
{Optional_FITS_descriptor} +
{Comment_FITS_descriptor} +
END_FITS_descriptor
.

FITS_header_packet (store) =
*
A collection of FITS descriptors, read as one unit but
not necessarily consitituting a complete FITS header.
Typically, each sub-system contributes one header packet.
When a FITS header is assembled, the boundaries between
the constituent header packets disappear.
*
{Optional_FITS_descriptor} +
{Comment_FITS_descriptor}
.

FITS_header_packet_name (data flow, cel) =
*
The name of a header-packet pertaining to a particular
observation. This is presumed to be a file name.
*
.

FITS_image (data flow, cel) =
*
A sequence of pixel values representing a CCD image.
Each pixel is encoded as a 16-bit unsigned integer, with
an offset of 32K subtracted from the true value (as noted
in the BZERO FITS-descriptor) to allow true values
from 0 to 64K to be stored.
*

Fraction_of_frame_read (data flow, cel) =
*
The fraction of a CCD frame that has been processed so far
in the current observation.
*
.

Guide_loop_locked (data flow) =
*
Indicates whether the TCS is acting on the tracking
corrections provided by the autoguider. This datum does
not indicate whether the corrections are derived from a
guide-star; the loop may be locked against dummy
corrections produced while the autoguider is blind.
*
[ "TRUE" | "FALSE" ]
.

Guide_star_option (data flow, del) =
*
This flag indicates how the system should find a guide-star.
The options are to look close to a given position on the
autoguider, to search a relatively large area of the sky,
or to abandon guiding for this target.
*
[ "Position_given" |
"Search_on_sky" |
"No_guide_star" ]
.

Guide_star_position (data flow, cel) =
*
The position of a guide-star on the autoguider
CCD. The position is in the reference frame of the CCD
pixels and is measured in pixels relative to the readout
register of the CCD. The centre of the first pixel is at
position (1.0,1.0).
*
.

Guide_window (data flow, pel) =
*
The window - described by its origin and size in pixel
coordinates on the autoguider CCD - in which the autoguider
centroids the guide star while guiding the telescope.
*
.

Guiding_integration_time (data flow, cel) =
*
The time for which the autoguider collects light in the
guiding window before digitizing the window and processing
the results. The time may not be less than one second.
*

Guiding_position (data flow) =
*
The position, in pixel coordinates on the autoguider CCD,
at which the telescope is tryingto keep the guide star.
*
.

Header_progress (data flow, cel) =
*
The percentage of expected FITS descriptors that have been processed
for the current observation. Between observations, the value is 0%.
*
.

Identify_filter (data flow) =
*not-defined*.

Image_display (data flow) =
*
A graphical display of one CCD frame.
*
.

Last_run_number (store) =
*
The last run number to be allocated. This is used to
ensure that the sequence of run numbers is contiguous from
night to night. Hence, this store must exist when the
DAS server is started up and must be preserved when
the server is shut down. This resource is shared between
all the processes that manage runs.
*
Run_number
.

Mandatory_FITS_descriptors (data flow, pel) =
*
The descriptors that are required to make a FITS file
valid. These mainly define the image format (size,
shape, bit-pattern of each pixel) and must be generated
inside the DAS.
*
.

N_exposures (data flow, cel) =
*
Number of exposures in the current sequence.
*
.

N_FITS_descriptors (data flow, cel) =
*
The number of FITS descriptors for which room must be
made in the current FITS-file.
*
.

New_readout_format (control flow, del) =
*
Indicates that a new readout-format is required for a DAS channel.
*
[ "TRUE" | "FALSE" ]
.

Noise_and_gain (store) =
*
The readout noise and gain that apply for each speed
of the SCCDs.
*
1{SCCD_noise + SCCD_gain}5
.

Nth_exposure (data flow, cel) =
*
The ordinal number of an exposure in a sequence of similar
exposures. This is not the same as the run number.
*
.

Observation_type (data flow) =
*
The purpose of an observation, expressed as a keyword
from the set below. Observation type TARGET means an
observation of a specific celestial source
(a.k.a a `science frame').
*
[ "TARGET" |
"BIAS" |
"DARK" |
"FOCUS" |
"SKY" |
"DOME" ]
.

Optional_FITS_descriptors (data flow, pel) =
*
The set of FITS descriptors that are not required by the
FITS standard but which are listed in the specific
requirements for this system.
*
.

Pause_state (data flow) =
*
Indicates whether an exposure is paused or not.
*
[ "TRUE" | "FALSE" ]
.

Pixel_buffer (store) =
*
The pixel buffer allows the DAS server to receive pixels
from the CCDC at any time, even when it is not ready to
write the pixels to disk. The buffer should be large
enough for at least two readouts at the current format.
*
{Pixel_value}
.

Pixel_headcode (data flow, cel) =
*
This datum, a byte, identifies which CCD controller
transmitted a particular pixel. The codes may vary from
night to night, and from telescope to telescope; the same
code may be used for different CCDCs on one night on
different telescopes. However, on a given night and
a given telescope, the codes are unique.
*
.

Pixel_offset (data flow, cel) =
*
The position of a pixel witin a rectangular image. A stream of mis-ordered
pixels may be reformed into an image by positioning them according to their
offsets.
*
.

Pixel_signal (data flow, cel) =
*
An analogue signal from the CCD's preamplifier representing
the light intensity on one pixel.
*
.

Pixel_value (data flow, cel) =
*
The value of one CCD pixel, stored as an integer in the
range 0 to 64K.
*
.

Proper_motion (data flow, cel) =
*
The proper motion of a target in RA and declination,
given in units of arcseconds per year for each coordinate.
*
.

RA (data flow, cel) =
*
This datum is the Right Ascension of the target.
*
.

RA_offset (data flow, cel) =
*
A small displacement of the telescope from the catalogued position of the current target.
The displacement is measured in arcseconds on the sky in the direction of right ascension.
*
.

Readout_finished (control flow, del) =
*
Indicates that the readout has completed on a DAS channel.
*
[ "TRUE" | "FALSE" ]

Readout_format (data flow) =
*
Data which indicates the number of pixels in each CCD frame
and where each pixel came from on the chip. Details of
readout windows are included but are not expected to be
used at prime focus.
*
X_CCD_size +
Y_CCD_size +
X_binning +
Y_binning +
4{ X_window_size +
Y_window_size +
X_window_offset +
Y_window_offset }4 +
Windows_enabled +
X_image_size +
Y_image_size
.

Readout_progress (data flow, cel) =
*
One number indicating the percentage of pixels
yet to be read out on a DAS channel. When no readout
is in progress the value is 0%; 100% indicates that a
readout is just completing but that (some of) the pixels
have not yet been processed. The percentage should be
resolved to an accuracy of 1%
*
.

Ready_for_image (data flow) =
*
This parameter shows whether the DAS is ready to
process another image. Normally, the parameter is set
to True., It is set to False when the DAS is first loaded
and until the DAS has been told the readout format.
Subsequently, the parameter is False while the DAS is
processing an image and True otherwise.
*
[ "True" | "False" ]
.

Required_activity (data flow) =
*
Defines what the shutter should be doing - needed
for validity checks in the monitoring.
*
[ "Expose" + Exposure_time |
"Pause" |
"Close" |
"Open" |
"Position" + Shutter_position ]
.

Run_number (data flow, cel) =
*
A number, unique among all INT observations, used to
identify a CCD frame. In the case of the PFC, one
observation will generate four frames each with a
different run number. The numbers for images taken
in the same exposure must be contiguous.
*
.

Run_status (data flow) =
*
Defines what is happening a run from the DAS server's point
of view.

`Waiting' => no data yet.
`Saved' => run over, data passed to archive.
`Aborted' => data discarded by the client command.
`Underrun' => Timeout on readout.
`Overrun' => Too many pixels or pixels arrived too fast.
*
[ "Waiting" |
"Saved" |
"Aborted" |
"Underrun" |
"Overrun" ]
.

Save_observation (data flow) =
*
This flow indicates whether the DAS should pass the current observation
to the (external) archiving system, or whether it should discard the
data. Note that this decision applies to the observation as recorded
on disk and does not affect the data-acquisition processes. The "don't know"
value indicates that the DAS should retain the observation internally, pending
a later decision.
*
[ "Save" | "Discard" | "Wait" ]
.

Saved_FITS_file (data flow) =
*
A FITS file stored safely so that it is not over-written
by other observation and so that it can be identified later.
*
FITS_file_name +
FITS_file
.

SCCD_actual_temperature (data flow, cel) =
*
The temperature in the SCCD's cryostat. In kelvin.
*
.

SCCD_command_packet (data flow) =
*
Any command to the SCCD sub-system.
*
[ "Readout format" + Readout_format |
"Clear_speed" + Clear_speed |
"Clear" |
"Readout" |
"Reset" ]
.

SCCD_Current_settings (store) =
*
Settings currently applied to the CCDC.
*
Readout_format +
Readout_speed +
Clear_speed
.

SCCD_dialogue (data flow) =
*
The set of message packets concerning use of the SCCDs.
These packets are excahnged by the central intelligence
and the SCCD server.
*
[ SCCD_command_packet |
SCCD_parameter_packet |
Status_packet ]
.

SCCD_Required_settings (store) =
*
Settings on the CCDC that the SCCD sub-system must maintain
until further notice.
*
Readout_format +
Readout_speed +
Clear_speed
.

SCCD_set_temperature (data flow, cel) =
*
The temperature at which the SCCSs are intended to run
(this can be varied at the CCDC).
*
.

SCCD_unet_command (data flow, pel) =
*
A command to the CCDC to execute an action or to return
status.
*
.

SCCD_unet_status (data flow, pel) =
*
A message from the CCDC showing the state of a machanism
and.or the result of an action.
*
.

Search_integration_time (data flow, cel) =
*
The time for which the autoguider collects light in the
search window before digitizing the window and processing
the results.
*
.

Search_window (data flow, pel) =
*
The window - described by its origin and size in pixel
coordinates - on the autoguider CCD in which the autoguider
searches for guide stars.
*
.

Shutter_clamp_reading (data flow, cel) =
*
An electrical signal indicating whether the
shutter clamps are open or closed.
*
.

Shutter_clamp_status (data flow) =
*
Indicates the health of the shutter clamps
*
Condition_code
.

Shutter_clamps (control flow, del) =
*
Indicates whether the shutter disc is free to move.
*
[ "Free" | "Clamped" ]
.

Shutter_command_packet (data flow) =
*
The set of commands sent to the filter server by the
central intelligence. `Set exposure' sets the
exposure time and can change it during an exposure; this
command does not start exposures. `Position' provides the
basic open/close functions and also the higher-level
functions `Expose', `Pause', `Continue'.
*
[ "Set exposure" + Exposure |
"Position" + Shutter_position ]
.

Shutter_covers_ACCD (data flow, cel) =
*
The fraction of the ACCD covered by the shutter.
*
.

Shutter_covers_SCCDs (data flow, cel) =
*
The fraction of the SCCDs covered by the shutter.*
.

Shutter_dialogue (data flow) =
*
The set of message packets concerning the shutter.
These packets are exchanged by the central intelligence
and the shutter server.
*
[ Shutter_command_packet |
Shutter_parameter_packet |
Status_packet ]
.

Shutter_drive_rate (data flow, cel) =
*
A rotation-rate demand for the drive shaft of the
shutter disc.
*

Shutter_drive_status (data flow) =
*
Indicates the health of the shutter drive
*
Condition_code
.

Shutter_encoder_reading (data flow, cel) =
*
The angular position of the drive-shaft to the shutter
expressed in arbitrary encoder units.
*
.

Shutter_parameter_packet (data flow) =
*
Data describing the current state of the shutter.
*
Shutter_position +
Shutter_covers_SCCDs +
Shutter_covers_ACCD +
Shutter_clamps +
Exposure +
Shutter_clamp_status +
Shutter_drive_status
.

Shutter_position (data/control flow, cel) =
*
The angular position of the shutter, in degrees.
The shutter is at zero degrees when the clear sector
is furthest from the SCCDs. The shutter moves in one
direction only and this is defined to be direction
in which Shutter_position increases.
*
.

Sky_position (data flow) =
*
A celestial position.
*
RA +
DEC +
Equinox
.

Status_packet (data flow) =
*
This structure reports the state of a command within the
control system; it does not report the health of any mechanism, since
such information is included in the various parameter packets which
are produced separately.
*
Command_type +
Command_instance +
Command_stage +
Condition_code +
(Error_message)

Target_details (data flow) =
*
The details of a target are the data that the system needs
to acquire a target and to lock on to a guide star.
*
Target_name +
Sky_position +
Guide_star_option +
(Guide_star_position)
.

Target_list (store) =
*
A list of targets compiled by the observer or TO.
*
{ Target_details }
.

Target_name (data flow, del) =
*
The name of the target. This is used to identify entries
in the general catalogue of targets.
*
.

TCS_dialogue (data flow) =
*
The set of message packets concerning the behaviour of the
TCS. These packets are exchanged by the central intelligence
and the TCS server.
*
[ TCS_command_packet |
TCS_parameter_packet |
Status_packet ]
.

Telescope_offset (data flow) =
*
A small displacement of the from the catalogued position of the current target.
*
RA_offset +
Dec_offset
.

Telescope_pointing (data flow) =
*
A collection of data defining the pointing of the
telescope. The data can be either a set of instructions
or a description of the telescope's current activity.
All the elements of this flow are needed to define the
pointing, and the flow is therefore modelled as a union.
However, when instructions are sent to the telescope,
it may be more practical buffer the data in the TCS and
thus to send several separate messages. This data-set does
not include the guiding information generated by the
autoguider.
*
Telescope_state +
Target_name +
Telescope_position +
(Guiding_position)
.

Telescope_position (data flow) =
*
The data that define a nominal pointing position of the
telescope.
*
RA +
Dec +
Equinox +
Epoch +
Proper_motion
.

Telescope_state (data flow, del) =
*
A simple classification of the state of the telescope.
"Moving" includes rotator movement. "Tracking" and
"Guided" imply that the rotator is stationary. "Stopped"
implies that all three drives - RA, dec and rotation -
are stopped. "Guided" implies that the TCS is correcting
the tracking in response to signals from the autoguider;
this is a stronger condition than just having the
autoguider send the signals.
*
[ "Stopped" |
"Moving" |
"Tracking" |
"Guided" ].

Title (data flow, pel) =
*
The title of an observation, to be recorded in the FITS header.
*
.

Total_exposure_time (store) =
*
In the general case (in practice, if an
observation is paused), the observation is made up of many
exposures which are registered in one readout and sum to
give one exposure time. This store accumulates the total
exposure time.
*
Exposure_time
.

Windows_enabled (data flow, del) =
*
A flag to tell the system whether to apply the window details that it has stored.
*
[ "TRUE" | "FALSE" ]
.

Work_in_progress (store) =
*
This store contains the current state of all processes managing runs.
At most times, there will be four such processes, one for each SCCD.
Occasionally, the processes for two runs on the same SCCS may overlap,
since each process starts as soon as the previous readout finishes and
possibly before that readout has been written to disk. There can never
be more than two runs active per SCCD and hence there will never be more
than eight for the PFC. In general, the DAS server could have up to 16
runs active. After initialization, the store contains no runs.

Also present is the state of each DAS channel - ready or not ready for
readout. This information is independent of the presence or absence of
runs. After initialization all channels become unready.

Finally, a list of active DAS commands is stored, so that stati can
be sent for these commands.
*
1{ Run_number +
DAS_channel +
Readout_format +
Readout_progress +
Header_progress +
FITS_header_packet_name +
Run_status }16
+
1{ DAS_channel_ready }8
+
{DAS_command}
.

X_binning (data flow, cel) =
*
The number of CCD pixels binned together in the x direction.
This must be an integer from 1 to 10 inclusive.
*
.

X_CCD_size (data flow, cel) =
*
The length of the CCD-frame in the x direction when no windows or binning are set.
*
.

X_image_size (data flow, cel) =
*
The size of the reconstructed image in the x direction.
*

X_window_offset (data flow, cel) =
*
The position of a window in the CCD frame in the x direction.
This is the offset, in pixels, between the edge of the
window and the edge of the CCD frame such that the offset
goes to zero when the window is at the left edge of the frame.
*
.

X_window_size (data flow, cel) =
*
The size of a window, in pixels, in the x direction.
*
.

Y_binning (data flow, cel) =
*
The number of CCD pixels binned together in the y direction.
This must be an integer from 1 to 10 inclusive.
*
.

Y_CCD_size (data flow, cel) =
*
The length of the CCD-frame in the y direction when no windows and binning are set.
*
.

Y_image_size (data flow, cel) =
*
The size of the reconstructed image in the y direction.
*
.

Y_window_offset (data flow, cel) =
*
The position of a readout window in the CCD frame in the y direction.
This is the offset, in pixels, between the edge of the chip and the edge
of the window such that the offset goes to zero when the window is at the
bottom of the frame.
*
.

Y_window_size (data flow, cel) =
*
The size of a readout window, in pixels, in the y direction.
*
.

3 Specific requirements

3.1 Overall system behaviour

Req. 1. : The system shall interface to the external devices and systems shown in Section 2.7.

Req. 2. : The system provide distinct sub-systems to manage its external connections as shown in Section 2.7.1. This includes sub-systems to handle interactions with the observers.

Req. 3. : All sub-systems shall be active in parallel.

Req. 4. : The system shall include software, represented by the bubble `Coordinate_state_changes' in Section 2.7.1 which ensures that all sub-systems interact correctly. This software is also known as the `central inteligence' (CI).

Req. 5. : During normal observing, sub-systems shall exchange command and status information only with the CI.

Req. 6. : For engineering work, it shall be possible to connect special user-interface programs (not shown in Section 2.7.1) directly to sub-systems.

Req. 7. : It shall be possible to operate a sub-system with the CI and one or more engineering interfaces active at the same time. It shall also be possible to run the sub-system with only the engineering interface(s).

Req. 8. : Failure of any one sub-system shall not prevent the system carrying out user commands, except where a given command requires the use of that sub-system. Wherever possible, the system shall offer degraded modes of operation that avoid the use of a sub-system.

Req. 9. : The interaction between a sub-system and the CI (or an engineering interface) shall be as represented by the flows <sub-system>_dialogue. That is, data shall be exchanged as discreet message-packets of the types command (sent to a sub-system) status (sent by the sub-system to resgister the progress of a command) and parameter (sent by the sub-system to register a change of state of state, independently of commands).

Req. 10. : All entities connected to a sub-system must be able to receive all the parameter and status packets generated. Further, when an entity connects to the sub-system, it must be able to find out the `full' state of the sub-system - the data that it would have received in parameter packets if it had been connected from the start.

3.2 Control of SCCDs

Req. 11. : The SCCD sub-system shall provide the principal fucntions (a) low-level control of the SCCDs; (b) monitoring and state-reporting for the SCCDs; (c) storage of persistent settings for the CCD controller; (d) processing of commands to the sub-system.

Req. 12. : The command/status/parameter interface to the sub-system shall include at least the packets defined by the data-dictionary entries SCCD_command_packet, SCCD_parameter_packet and Status_packet. Other variations on these packets should not occur in the context of the PFC control-system.

3.2.1 CCD controller and local code

Req. 13. : The CCD sub-system shall employ a standard `Phase-II' CCD-controller with the FORTH software developed for the WHT.

Req. 14. : The controller and its software shall provide the `utility-network' interface described in WHT-CCD-1.

Req. 15. : The controller shall be adapted to drive four CCDs in parallel, as noted in Section 2.7.1.1.2.

3.2.2 Monitoring the CCDs

Req. 16. : The CCD sub-system shall include software to monitor the behaviour of the CCD controller.

Req. 17. : This software shall be active whenever the sub-system is active and independently of any commands that the sub-system is processing.

Req. 18. : The CCD monitoring shall result in parameter packets being sent to all connected entities. The packets shall have the contents as defined in the data dictionary for SCCD_parameter_packet.

Req. 19. : The monitoring shall detect and report changes in image format as described in Section 2.7.1.1.3.1.

Req. 20. : The monitoring shall detect and report changes in state of the SCCDs as described in Section 2.7.1.1.3.2.

Req. 21. : The monitoring shall detect and report changes in CCD-readout speed as described in Section 2.7.1.1.3.3.

Req. 22. : The monitoring shall detect and report changes in CCD-clear speed as described in Section 2.7.1.1.3.4.

Req. 23. : The monitoring shall detect and report changes in temperature of the SCCDs as described in Section 2.7.1.1.3.5.

Req. 24. : The monitoring shall detect and report resets of the CCD controller as described in Section 2.7.1.1.3.6.

3.2.3 Stored settings

Req. 25. : The SCCD sub-system shall store the various settings that apply to the CCDC: readout (image) format, readout speed and clear speed. The sub-system shall store both the values currently set on the CCDC and the values most-recently requested in command packets.

3.2.4 SCCD commands

Req. 26. : The sub-system shall initiate and monitor actions on the CCDC controller in response to command packets. The results of each command shall be reported in status packets.

Req. 27. : The command-processing shall operate according to the perceived state of the CCD controller, as defined in Section 2.7.1.1.1. The states are Idle, Clearing, Reading, Setting and Resetting. The state-machine shall be sensitive to the events listed in the data dictionary for SCCD_event and detected by the monitoring function.

Req. 28. : In the Idle state, the command shall be accepted as described in Section 2.7.1.1.2.

Req. 29. : In states other than Idle, the sub-system shall reject commands as described in Section 2.7.1.1.3.

Req. 30. : In the Setting state, the sub-system shall send and receive utility-network messages as described in Section 2.7.1.1.1.4 and shall signal the transition back to the Idle state as there described.

Req. 31. : In the Resetting state, the sub-system shall send and receive utility-network messages as described in Section 2.7.1.1.1.5.

Req. 32. : In the Reading state, the sub-system shall send and receive utility-network messages as described in Section 2.7.1.1.1.6.

Req. 33. : In the Clearing state, the sub-system shall send and receive utility-network messages as described in Section 2.7.1.1.1.7.

Req. 34. : In the Reading state, the sub-system shall send and receive utility-network messages as described in Section 2.7.1.1.1.8.

3.3 Data-acquisition

Req. 35. : The data-acquisition sub-system shall provide (a) software to manage commands; (b) software to report the state of the data-acquisition hardware; (c) software to manage the acquisition of each `run'.

Req. 36. : The reporting software shall be active whenever the sub-system is active and shall not require the presence of DAS commands to operate.

Req. 37. : Runs shall be handled indepently on each of four acquisition channels (corresponding to the four SCCDs).

Req. 38. : The sub-system shall begin to handle a run when: (a) a readout (image) format is set or changed; (b) the previous run is aborted and (c) a readout finished. The handling of a run ends when the data from that run is saved to disk or discarded. Hence, runs can overlap and the sub-system must be capable of tracking at least two runs on each channel.

Req. 39. : The sub-system shall store between runs all the settings that apply to each channel, as defined in the data dictionary for DAS_orders.

Req. 40. : The command/status/parameter interface to the sub-system shall be defined by the data-dictionary entries DAS_command_packet, DAS_parameter_packet and Status_packet.

3.3.1 Parsing DAS commands

Req. 41. : The DAS_command flows shall be processed to extract and store the parameters and to recognize the sub-system events, as described in Section 2.7.1.3.1.

3.3.2 Reporting DAS state

Req. 42. : Reports of changes in the sub-system shall be made for the events defined in Section 2.7.1.3.2.

Req. 43. : State-change reprots shall have the contents defined in the data dictionary for DAS_parameter_packet.

3.3.3 Managing runs

Req. 44. : For each run, the sub-system shall perfom the following functions: (a) capture pixels as they come from the CCD controller and store them in a buffer; (b) assemble the pixels into an image and write hte image to a FITS file; (c) read packets of FITS descriptors and combine them in the FITS header of the current FITS file; (c) mantain the FITS-file's status as a run to be archived, a scratch file, data to be discarded or data whose fate is not decided; (e) record parameters applying to the run.

Req. 45. : All functions shall become active when the run is first managed. Various functions will shut down as they receive their data and complete. When all functions have completed, the run is no longer managed, and the sub-system shall forget about it.

Req. 46. : The capture of pixels shall proceed as described in Section 2.7.1.3.3.1.

Req. 47. : The reassembly of the image shall be a function of the readout format and shall proceeed as described in Section 2.7.1.3.3.2.

Req. 48. : The assembly of the FITS header shall proceed as described in Section 2.7.1.3.3.3.

Req. 49. : The accessibility of the current FITS file shall be managed as described in Section 2.7.1.3.3.4.

Appendix A. Document History

Issue 1.1 19/12/94 First issue, with incomplete analysis. Submitted for review in the parallel project Interim INT DAS.

Controls for the INT PFC: Software Requirements

1 Introduction

2 General description

3 Specific requirements

Controls for the INT PFC:
Software Requirements