WHT-ISIS-4
Issue 1.1; 28/07/95
Royal Greenwich Observatory,
Madingley Road,
Cambridge CB3 0HJ
Telephone (01223) 374000
Fax (01223) 374700
Internet vea@ast.cam.ac.uk
This document describes the requirements as perceived and stated by astronomers and operations staff, for the software system that will control the ISIS polarisation module. The completeness and validity of the control system should be judged by reference to the following text. Questions of design, development method and underlying technology are not raised here, except where connections with existing technology are required.
1.2 Scope
The software product to be produced is the ISIS polarisation module control system software, hereafter referred to as the ISISP control system software. This software product is intended to execute a defined set of commands issued by an ADAM I-task; report the result of these commands and current status of the polarisation module back to the I-task; display the current module status on an engineering mimic; and to allow engineering control of the module from an engineering mimic.
1.3 Definitions, acronyms and abbreviations
4MS 4.2 meter Micro-processor System
ADAM Astronomical Data Acquisition Monitor. The software environment used with the WHT system software.
EPICS Experimental Physics and Industrial Physics Control System
I-task Instrumentation task. An ADAM control task using ADAM v2 software. An I- task may directly control a device or may co-ordinate a number of other tasks.
ICL Interface Command Language
ISIS Intermediate-dispersion Spectrograph and Imaging System
WHT William Herschel Telescope
Sources of requirements:-
FS Functional Specification for the ISIS polarisation module upgrade.
IM1 Instrumentation meeting on La Palma.
RGMR Suggestion by R. Rutten, ING.
VEA Suggestion by V. Austin, RGO.
WHT Detail deduced from experience on the WHT.
1.4 References
[1] Requirements for the ISIS Polarisation Unit Redesign, R.G. Rutten; November 1994.
The ISIS polarisation module is located immediately above the slit assembly within the ISIS spectrograph. The polarisation module was commissioned in 1990, one year after ISIS itself came into operation. The polarisation module optics contain a large super-achromatic half-wave plate and a smaller quarter-wave plate. Various problems1 associated with the operation of the polarisation module have necessitated an upgrade. The aim of the upgrade is to make the operation of the polarisation module more reliable, and to provide angular encoding of the half-wave and quarter-wave plates.
The polarisation module is currently controlled by the ISIS 4MS control system. This system is based on a Motorola 6809 processor card with 64k memory and a G64 backplane. The system contains two dedicated function boards and five Syntel ACM3 boards which each provide three serial communications ports to the remaining modules. There are no free backplane slots and only one spare serial port in the ISIS 4MS. Furthermore there is limited memory in both the 4MS and the Engineering Mimic, restricting the modification of the software to provide the required functionality of the upgrade.
The use of an additional control system based on EPICS/VxWorks has been agreed in consultation with staff on La Palma. This method of control requires a greater initial outlay, however the main advantage is that an upgrade path becomes available for the whole ISIS spectrograph. Other advantages are that fewer compromises need be made to the re-design of the polarisation module due to the flexibility of EPICS and that it becomes easier to provide diagnostic information on an engineering mimic.
2.2 User characteristics
Three classes of user require access to the system.
z Observers undertaking scheduled observations.
z RGO support astronomers and telescope operators.
z RGO staff carrying out repairs, tests or upgrades who need low-level access to all parts of the system.
2.3 General Constraints
The computer hardware for the ISISP control system software will be mounted on the ISIS spectrograph where space is limited.
Any system installed at the WHT should be capable of simulation at Cambridge so that Technology division can provide support. This may mean buying duplicates of all hardware. However the delivered system must be capable of support by Operations division once development has ceased at Cambridge.
2.4 Assumptions and dependencies
This document assumes that a new ADAM I-task will be written to provide an interface between the ISISP control system software and the ICL used by the operator to enter commands.
The system must ultimately be accepted for use by Operations division. It is assumed that Operations staff will take an interest in the development of the system and will put forward their specific requirements as amendments to this document in good time for inclusion in the delivered system.
2.5 Operational environment
The ISIS polarisation module comprises of two mechanisms, the half-wave polarisation plate and the quarter-wave polarisation plate. These mechanisms will be controlled, and their status read, via interface boards accommodated in a VME crate. The VME crate will contain a 68030 microprocessor running the VxWorks real-time kernel. The ISISP software must communicate with and control this hardware.
The ISISP software must also communicate with the control host, a VAX running the VMS operating system, and an engineering mimic, a SUN SPARCstation. Communications between these computers must be via ethernet using the TCP protocol.
User-level commands will be translated to ADAM actions by an ISISP control task, known as an I-task. A new I-task must be written for this purpose which will be a separate software product. An interface between this I-task and the ISISP software must be defined for all control and status information required when using the ISIS polarisation module. The context diagram is shown in figure 1 below.
Figure 1. ISISP Context Diagram
3.1.1 Module operation
Requirement 1 from RGMR; 07/11/94.
The half-wave polarisation plate and the quarter-wave polarisation plate must both perform the
following functions independently of each other:-
(i) Move wave-plate slide into the beam.
(ii) Move wave-plate slide out of the beam.
(iii) When the wave-plate is in the beam, rotate the wave-plate continuously at a user-defined speed between 0.1 Hz and a maximum of 1 Hz in intervals of 0.1 Hz.
(iv) Stop continuous rotation of the wave-plate.
(v) Rotate wave-plate to a minimum of 16 equi-spaced target angles with an angular tolerance no greater than + 0.1 degrees between target angle settings.
(vi) Initialise wave-plate to a zero position with tolerance of + 0.1 degrees.
3.1.2 Engineering control
Requirement 2 from VEA; 24/05/95.
The system should allow independent engineering control of the ISIS polarisation module,
providing the operations listed above.
3.1.3 Status display
Requirement 3 from RGMR; 07/11/94.
The following status information must be displayed on an engineering mimic:-
(i) Half-wave and quarter-wave plate angles in degrees or frequency of rotation in Hz, depending on mode of operation.
(ii) Half-wave and quarter-wave plate slide positions, in or out of beam.
(iii) Error messages if appropriate.
3.2 Constraint requirements
3.2.1 Software interface
Requirement 4 from VEA; 24/05/95.
The ISISP control system software must respond to a defined set of commands issued by the
ADAM I-task in response to ICL commands typed by the user.
3.2.2 Availability
Requirement 5 from WHT; 26/07/95.
Performance unacceptable if in any one night 5% of the total dark hours cannot be used for
observing due to technical faults.
3.2.3 Adaptability
Requirement 6 from IM1; 06/06/95.
The software must be structured to allow future modifications of the software to control all ISIS
mechanisms.
3.2.4 Security
Requirement 7 from WHT; 26/07/95.
(i) The system should be inaccessible to users not authorised by Operations staff, specifically an unauthorised user may not operate the ISIS polarisation module.
(ii) Write access to operational software shall be reserved to Operations staff.
3.2.5 Safety
Requirement 8 from WHT; 26/07/95.
Where the software system has control of a moving mechanism, safeguards must be built in to
prevent mechanical damage.
3.2.6 Standards
Requirement 9 from FS; 26/07/95.
Software must be written in accordance with an RGO-approved subset of the ESA software
engineering standards ESA PSS-05-0 Issue 2.
Appendix A. Document History
[1] Issue 1.1 28/07/95 First issue.