Document ID	Source	Title
Cics_smb_041	IGPO	CICS Software Design Document
SPE-C-G0014	IGPO	Software Requirements Specification
SPE-C-G0037	IGPO	Software Design Description
SPE-C-G00	IGPO	Software Programming Standards

3 Introduction

NIFS is a conforming Gemini instrument and is closely modeled after the Gemini Near Infrared Imager (NIRI). As a conforming instrument the software requirements for NIFS fall into the following categories:

· Compliance with Gemini software design requirements as described in ICDs 1-16 which describe a conforming ICS as one which runs on a VME-based IOC running VxWorks and EPICS.

· A conforming ICS is made up of three distinct components – the Instrument Sequencer (IS), the Components Controller (CC) and the Detector Controller (DC). Each of these components has particular requirements.

· NIFS is required to be a fast-track instrument. The instrument is modeled after NIRI, hence software should be very similar. The NIRI software model followed the CICS template, which turned out to be somewhat problematic. Regardless, the NIFS software design will adopt the NIRI code, except for the Detector Controller package, not expecting any significant differences.

· NIFS will also have an On-Instrument Wavefront Sensor (OIWFS) which will be a duplicate of NIRI’s OIWFS.

· Performance: Different readout methods employed by the DC package have specific processing and memory needs on the IOC.

4 Compliance With Gemini Software Design Requirements

The following list of requirements were gleaned from relevant Gemini documentation:

· Programming languages will be GNU C and, with justification, GNU C++.

· Software must follow the CICS model as closely as possible.

· All Gemini systems must interact via CAD/CAR/APPLY/SIR records.

· All widgets on the Engineering Interface must connect to a CAD, CAR, APPLY or SIR record.

· The engineering user interface must be written in the EPICS tools edd/dm.

· All EPICS databases must be written in Capfast.

· All public process variables must be made accessible via SIR records.

· Provide a historyLog record for logging status to the DHS.

· Provide a top-level debug command.

5 NIFS Fast-track Development

The initial approach taken by the NIFS team was to copy as much of the NIRI software effort as possible – at least with respect to the Instrument Sequencer (IS) and Components Controller (CC). Recently, however, it has become clear that this is now not the recommended approach to take. Both the Gemini Project Office and the NIRI software developers have advised us to look to other groups for a preferred software model. Immediately the requirement that NIFS be fast-tracked is at risk. Presently the Gemini software working group is considering how to redevelop the CICS so that instrument groups have a more flexible, efficient model to work with. But this work has yet to be completed, so we will adopt the NIRI code as is.

NIFS will use the SDSU 2 array controller for reading the detector. Software for this is a new piece of work but existing RSAA experience and software developed for this controller can be utilized. In addition, work done by the NOAO Gemini instrument group for the Gemini CCD controller can assist our development in the EPICS area.

6 Functional Requirements

The functional requirements of the components of NIFS are described below – the definition of each component is taken from the CICS Detailed Design Document.

6.1 OIWFS

This subsystem is a separate Components Controller responsible for the mechanisms belonging to the OIWFS of the instrument.

The NIFS OIWFS will be a duplicate of the NIRI OIWFS.

6.1.1 OIWFS Mechanisms

The OIWFS CC will control and position these 3 active elements:

· X-Axis Gimbal

· Y-Axis Gimbal

· Filter Wheel

6.1.2 OIWFS Interfaces

The OIWFS is part of the Gemini A&G system. The Gemini document ICD 5 describes the interfaces to the OIWFS.

6.2 Spectrograph Instrument Sequencer

This process is responsible for the overall operation of an instrument. It sequences the subsystems and ensures that commands directed to one subsystem do not clash with the requirements of another (e.g., it prevents the Components Controller reconfiguring the instrument while the Detector Controller is making an observation).

6.2.1 Spectrograph Instrument Sequences

The OCS provides the instrument with the science configuration and then issues a sequence of the following commands in order to run the instrument:

- TEST – test all components

- INIT – setup the instrument and read the hardware configuration file

- RESET – change to the start-up configuration

- CHECK – check a target configuration is feasible

- APPLY – move to a target configuration

- OBSERVE – make an exposure

- PAUSE – pause an exposure (not relevant to NIFS - ignored)

- CONTINUE – continue an exposure (not relevant to NIFS - ignored)

- STOP – cancel an exposure

- FLUSH – complete any pending data processing operations and store the data generated by an exposure

- ABORT – emergency stop

- PARK – adopt a safe configuration

These are the standard set of Gemini OCS commands more fully described in the SDD.

6.2.2 Spectrograph IS Interfaces

The IS software package will interface to the following Gemini subsystems:

- Gemini observatory control system (OCS).

- NIFS components controller running on the NIFS components controller IOC.

- NIFS detector controller running on the NIFS detector controller IOC.

- NIFS engineering interface running on a Sun Solaris workstation.

- Gemini status and alarms database (SAD).

- Gemini synchronization bus.

- Gemini time bus.

6.3 Spectrograph Components Controller

This subsystem is responsible for the mechanisms that define the optical path through the instrument and for controlling the instrument’s environment.

6.3.1 Spectrograph CC Mechanisms

The spectrograph Component Controller (CC) is responsible for moving and positioning all of the optical elements associated with the NIFS cryostat. Externally there is also a light tight window cover.

The spectrograph CC will control and position these 4 active elements:

· Focal Plane Mask Wheel

· Order Blocking Filter Wheel

· Grating Wheel

· Environmental Cover

The spectrograph active elements will mostly be controlled using copies of the NIRI mechanisms. An open loop scheme using stepper motors and dead reckoning is employed using Hall effect sensors to provide "home" or "datum" positions. Once a zero-point is established, the number of steps taken by the stepper motor determines position.

The NIRI software developers have developed the MECH EPICS record for interacting with the motors and sensors. NIFS will make use of this record with appropriate modifications (e.g., number of positions and steps).

6.3.2 Spectrograph CC Interfaces

The CC software package will interface to the following Gemini subsystems:

- NIFS instrument sequencer running on the NIFS components controller IOC.

- NIFS engineering interface running on a Sun Solaris workstation.

- Gemini interlock bus.

- Gemini time bus.

- Gemini status and alarms database (SAD).

6.4 Spectrograph Detector Controller

This subsystem is responsible for controlling the instrument’s detector array and obtaining and processing data from it.

The Detector Controller (DC) will be setup using standard CAD records and will be read out using the RSAA-developed SDSU 2 camera C++ class. This will be modified to interface to the Gemini DHS.

6.4.1 Spectrograph Detector

The NIFS science detector will be the Rockwell HAWAII-2 array. This detector will be read out from four outputs simultaneously, therefore the DC software will need to preprocess the data into a correct sequence before it is sent to the DHS.

6.4.2 Spectrograph Detector Electronics

The detector electronics will be the SDSU 2 infrared array controller from San Diego State University. The DC software will need to support the direct configuration of the SDSU 2 controller and handle all communications via the SDSU VME interface card installed in the DC IOC. Fiber optic cable will connect the VME interface to the SDSU electronics.

6.4.3 Spectrograph DC Interfaces

The DC software package will interface to the following Gemini and NIFS subsystems:

- NIFS instrument sequencer running on the NIFS components controller IOC.

- NIFS engineering interface running on a Sun Solaris workstation.

- The SDSU 2 controller electronics.

- Gemini data handling system and quick-look displays (DHS).

- Gemini status and alarms database (SAD).

- Gemini interlock bus.

- Gemini time bus.

6.5 Engineering Interface

The engineering interface will be developed using edd/dm and will be a modified copy of the NIRI engineering interface for the IS and CC. New edd/dm screens will have to be developed for the DC.

The NIRI engineering interface consists of screens that can send commands to the OIWFS, IS, CC, and DC independently.

7 Performance Requirements

The NIFS DC package is required to support the linear-fitting readout method (Chapman et al. 1990, SPIE, 1235, 34). Therefore it has to be able to process and deliver image data in a small enough time window so as to prevent data buffer overflow. The Fowler sampling method (Fowler & Gatley 1990, ApJ, 353, L33) will also be supported, so enough buffer space has to be available to contain multiple reads of the detector.

8 Software Development Environment

NIFS software will be developed according to Gemini software development standards that are described in document SPE-C-G009/05. These standards comprise the following elements:

· Software Programming Standards

The Gemini standards require that all code developed adheres to rules governing language selection, coding practices and style, module layout and formatting, and other related issues. For instance:

- Language selection

GNU C and C++ compilers are required for both Unix and VxWorks cross-development. The Tcl/Tk scripting tool is to be used for all interpreted applications.

- Coding Practices

Rules for modular techniques, function and data declarations, include files, error handling, style and comments are defined.

- GNU make

Code will be maintained and built using the GNU make utility.

· EPICS

Gemini requires that all VME-based applications be developed using EPICS. Specific requirements are:

- The EPICS database creation tool required to be used is CapFast.

- EPICS records must conform to the Gemini specified naming convention for the instrument. For NIFS this mean that all records should have the prefix “nifs:”.

- EPICS engineering screens will be created using dm (an EPICS extension tool).

- EPICS programming should be done in either:

- EPICS database code – for ease of reuse, to take advantage of existing client side tools and to utilize the documentation and structural aspects of CapFast.

- C code encapsulated in record, device or driver support routines – for support of complex code and new hardware interfaces.

- State-Notation-Language (SNL) – for ease of expressing database state transitions.

- EPICS lock-sets – critical section handling. Use must be carefully thought through.

· VxWorks with the PPC Board Support Package

VxWorks from WindRiver Systems is the IOC real-time operating system environment chosen by Gemini. All new Gemini IOCs will use the Motorola PPC single board computer, so the NIFS ICS will be developed for the PPC. The latest development environment is Tornado V2.0, though initially Tornado V1.0.1 will be used to ease transition to V2.0. NIRI has been developed using V1.0.1.

· Solaris (Unix Sys V Rel 4, POSIX)

Sun Solaris is the Gemini operating system of choice for the user operating and software developer environment. The Tornado development environment will be run on Solaris for cross-development for the PPC.

· The UAE Environment

All EPICS development will be within the Universal Application Environment UAE – see the Keck EPICS Programming manual. UAE provides a means for developing and releasing code in a fashion similar to the way EPICS code is developed.

· External Software Libraries

Gemini uses the external software libraries SLALIB, ASTLIB, CFITSIO and TIMELIB.

· Source Code Control

Developers are encouraged to use the GNU CVS source code control environment.

9 Testing and Simulation

During the NIFS development phase software will be developed in parallel to the NIFS hardware, so it will be necessary to build hardware emulators that can be used to fully test software in the absence of real hardware. These emulators are required for all of the software external interfaces, that is:

- The Observatory Control System – provided with the engineering interface. The engineering interface will emulate the OCS by using the same EPICS channel access that the OCS will use and by providing all the commands expected from the OCS.

- The Data Handling System – Gemini provides a test DHS at the IGPO for use by instrument developers.

- The science detector – it is important to build a dummy software science detector that emulates the behavior of the real infra-read array, so that full detector controller software testing can be carried out in the absence of the detector.

- Optical mechanisms – NIRI have built emulators for the NIRI mechanisms, NIFS will make use of these.

10 Documentation

The NIFS project needs to provide to Gemini the following software documentation:

- A list of parameters defining the modifiable attributes for the instrument.

- A parameter description file (PDF) containing a list of parameters that the instrument can provide as status and/or header information.

- A list of data types that the instrument can generate, together with a:

- Data reduction recipe.

- Search rule for each type.

Appendix A: List of Figures

Figure 1	figure.gif