OSIRIS - Software - Detector Control System


The OSIRIS Detector Control System (DCS) will be responsible for the image acquisition in the OSIRIS instrument.

The main purpose of the OSIRIS Detector Control System is to perform the image acquisition of the OSIRIS instrument. The DCS will command the SDSU controller in charge of the CCD control. The images will be acquired through a RS-422 output connected to a PMC digital frame grabber, and then will be delivered upon request to the Data Factory subsystem for processing.

The DCS will also be in charge of the operation of the shutter in order to better synchronize it with the image acquisition operation.The DCS is an OSIRIS software subsystem. OSIRIS is a GTC instrument, so the OSIRIS software is a part of the GTC Control System (GCS), is included within the GCS distributed architecture and must fulfill the GCS software and hardware standards.

The software subsystems for GTC instruments are:

Also the part of the GCS common services (Logging and Alarms, System Monitoring, etc) specific to the OSIRIS instrument must be considered as belonging to the OSIRIS software.

The OSIRIS detectors controller will be based on a commercial SDSU-II controller, using a timing board with parallel cable linked to a commercial digital PMC frame grabber (at this moment, the model SNP-PMC-DIG16 from Datacell) plugged into a VME-LCU crate running VxWorks OS. Images will be sent from the controller to the frame grabber using a standard RS-422 digital output, and the commands will be sent to the controller through a dedicated RS-232 line (although the same RS-422 carrying the images could also be used).

The DCS is part of the Science Instrument Control System, one of the Equipment Control and Monitoring (ECM) subsystems. Other part of the Science Instrument Control System is the Mechanisms Control System (MCS).

The relation of the Science Instrument Control System with other GCS subsystems can be seen in the following diagram.

The DCS software will run in a Local Control Unit (LCU) with real-time capabilities. The necessary input and output signal to interface with the equipment to control and monitor will be connected to this LCU via dedicated Input-Output boards, described in the previous chapter. The DCS LCU will be also connected to the GCS real-time network with a connection in which several circuits with different Quality of Service (QoS) parameters will be established. The LCU, probably in combination with other crates, will be enclosed in a thermally conditioned rack or cabinet. The surface of the rack has to be kept at the same temperature as the external surrounding air. It should be decided which system is responsible of maintaining the cabinet surface temperature.

The hardware and software standards of the GCS will be used in the design and implementation of the DCS.

The OSIRIS DCS needs to perform some common actions in a control system: notify alarms, configure components, log a message, monitor some values, etc. These actions are part of the Common Services of the GCS and are defined as use-cases in other GCS subsystems (Logging and Alarms, Configuration Service, System Monitoring, etc). From the DCS point of view, these use-cases are invoked. These use cases are invoked and used without modification.

Detector Controller

The main task of the DCS is image acquisition, so the detector controller is the most important device to command. We will consider the whole image acquisition system as one actor, although it would also possible to split it in two parts, the SDSU controller and the frame grabber. In fact there will be different software components for commanding the SDSU and for acquiring the images with the frame grabber libraries, but this will actually be a design issue.

The SDSU-Generation II controller will include:

The main change regarding to typical SDSU controller configurations is the different timing board. This parallel cable version of the timing board is similar to the fiber optic version, but instead has support for a 16 bit parallel image data link that transmits over commercially available SCSI-3 cable to a host computer interface card for PCI buses. The cable will support very high data rates and is currently implemented at 6 Megapixels per second. This design was initially conceived by Dr Leach to operate infrared devices connected to a commercial PCI (from Spectral Instruments) RS-422 input card. Now, the frame grabber to be used is only different in format (PMC) and it would be connected directly to the parallel output of the SDSU controller. To do this, some specific programming shall be done into the controller?s code. It must be noted that the bandwidth (6 MHz the timing board, 20 MHz the frame grabber) is by far over the requested OSIRIS needs (maximum, 4 MHz running the four outputs at 1 MHz). Commands would be sent via RS-232 serial communication to the utility board, although it would be possible to send them via the same physical support as data. Both parts, SDSU and the chosen frame-grabber, support this implementation.

The frame grabber used for the prototypes is a commercial Datacell PMC-DIG-16, although this choice is not definitive.

Shutter Controller

The proposed shutter has two motorized plates, opening and closing like a curtain. The OSIRIS shutter operation (opening and closing) is to be controlled directly by DCS (TBC) through a SDSU controller digital output. The shutter will be previously configured through a RS-232 line. Shutter operation will be included in the detector working modes programmed at the SDSU utility board. TBC motors and encoders. TBC movement range.

Other GCS Subsystems

GCS Logging and Alarms Facilities

The Logging and Alarm Facilities is responsible for receiving, filtering and storing every significant event that a GCS component wish to report. Such events fall into different categories: emergency messages that require immediate attention, warning messages or informative messages. It plays the role of a logging facility because it stores the messages and allows for further retrieval. The Logging and Alarm Facilities is responsible too for the propagation of these events to the other GCS components that are interested on them.

So, DCS will send its alarms and logging to the Logging and Alarm Facilities and could also receive through it the alarms from other subsystems, in the case they were interesting for DCS (TBC).

GCS System Supervisor

System Supervisor's basic function is to take care of the health of every piece of software that is running in the system. It is responsible for:

The System supervisor does not provide a functionality specified by the final user of the system; it rather is intended to add robustness, fault tolerancy, service availability and failure detection to the software that implements the control system.

GCS Configuration Service

The Configuration Service is responsible for storing and managing every GCS component's parameters. The parameters are grouped together in the so-called GCS component configurations, some of them are predetermined or established configurations. One of these is the default configuration. The GCS global configuration is the ensemble of every GCS component's configuration. The Configuration Service provides the ability to store properties, group them into sets called configurations, view the current properties a component has, consult the available configurations for a given component (e.g. an instrument, the M2 subsystem, etc). It follows from this that a persistent support is to be used (e.g. some kind of database). Some GCS components will need to deal with the configuration manager in order to set up one device for an observation. A well defined software interface shall be provided to access to the configuration services from other pieces of software.

So the Configuration Service must provide DCS with the values for the configuration parameters for the detector controller, such as values of bias, detector timings, etc.

GCS System Monitoring Service

"System Monitoring" provides the ability to observe the value of certain selected magnitudes that are somewhat critical or interesting for some reason. The magnitude whose value is to be observed may belong to any hardware or software subsystem.

The GCS System Monitoring Service is also in charge of the distribution of the monitorized values to every interested GCS subsystem. So DCS must send it its internal status variables and could also receive through it the interesting variables from other subsystems (TBC).



OSIRIS Home Page

Last update July 26, 2005, by Héctor Castañeda