Figure 1: Gemini Interlock System Configuration.
Figure 1: GIF 86 Kb
Next: A High Speed Network for Remote Observing from Caltech with the Keck Telescope
Previous: The Gemini Core Instrument Control System
Table of Contents --- Search ---
PS reprint
M. Burns
Gemini Project, P. O. Box 26732, 950 N. Cherry, Tucson, AZ 85726
Figure 1 shows how the GIS is configured, with the important components described below.
The Interlock Management System is the PLC that receives events from the subsystems and issues demands to the various hardware devices. Even if the EPICS level fails, this PLC driven part of the interlock system can still protect people and hardware.
All of the event and demand signals are TTL in nature and are made up of two lines, denoted SET and not-SET. These lines should always be logical compliments, and if they are not complimentary a fault is deemed to have occurred, leading to appropriate actions. The motivation for having such redundancy is that it will catch some of the more common types of errors that are likely to occur such as wire breaks and short circuits. Such problems will probably affect both signal lines and therefore be detected.
As an example of the actions of the IMS consider the following case for the Mount Control System (MCS). An interlock event is issued by the MCS indicating that the azimuth drive motor power amplifier is over current. The IMS responds with a demand for the mount to go through an emergency stop. Current to the drive amplifiers are disabled, and brakes are set.
The Protection Management System watches over various hardware devices such as limit switches, pressure sensors, strain gauges, temperature sensors, and tachometers. All of the sensors are made to transmit a standard analog signal, most likely limited to +/- 10V. In the advent that the analog signal must be made fail-save, two parallel signals will be provided. The PMS can trigger interlocks. An example of action by the PMS would be for the MCS over velocity. If the altitude axis were noted to be over the velocity, then a stop would be initiated causing drive amplifier current to be disabled and brakes to be set.
Figure 1: Gemini Interlock System Configuration.
Figure 1: GIF 86 Kb
The Maintenance Mode System transmits control output signals so that the operator can move the telescope during maintenance. An example of operation under the Maintenance Mode System would be when using a hand-paddle to move the azimuth axis while the altitude axis was stopped and pointed at the zenith. In this case, many of the altitude interlocks would be disabled and the azimuth motion could be conducted for testing and maintenance.
The Safety Status System keeps track of alarms and status. EPICS is used extensively at this level. EPICS is used to provide an operator interface based on the information from the TTL Allen Bradley modules at the PLC level. The information is conveyed to the Observatory Control System using Channel Access via the control LAN. The individual modules can also communicate with the interlock system to let it know when soft limits have been reached or to warn when interlock conditions appear more likely. For example, differing levels of alarms could be set according to speed, dewpoint or wind conditions, with higher level alarms also setting interlocks.
EPICS is a very good tool for logging alarms and keeping a database of the status. Any time an alarm changes state, it is recorded including the channel name, alarm status, alarm severity, channel value and time. Knowing the alarm severity allows faults to be listed hierarchically. The faults are communicated to the observatory control system, and then conveyed to the operator.
Figure 2 shows a simplified example fault free for the Gemini Interlock System. At the highest level, the operator would see a fault with a number showing the severity. The first level of the fault tree would show that the problem was in the Mount Control System. The next level of the fault tree would narrow down the fault to the elevation drive, then to the drive amplifiers, and finally to an over-temperature condition. The actual fault tree is expected to have more items than listed in Figure 2, but a similar tree-like organization is expected to apply.
M1 Control
M2 Control
Mount Control--------------|Azimuth Drive
Enclosure Control |Elevation Drive----------|Motors
Hydraulic Control |Top-End Hardware |Brakes
Acquisition and Guiding |Counterweights |Amplifiers-----|Over Current
Active Optics Control |Castell Keys |Cable-Wraps |Over Volt
Instrument Control |Emergency Stop button |Over Temp
Figure 2: Example Fault Tree for the Gemini Interlock System.The main reasons to use EPICS in the GIS is for its ability to handle the various levels of alarms and for logging purposes.
EPICS is used to build the operator graphical user interface. Engineering screens will be developed for a Sun Sparcstation, using the EPICS display manager tool and other suitable tools. The purpose of the engineering screens is to enable an operator to interact with the Interlock System independent of other telescope systems.
It is event-driven which helps to nearly eliminate the need for polling. EPICS drivers isolate the low-level hardware characteristics from the application program, which makes the higher level changes easier.
The EPICS language is useful for making state-space machines, with the states representing various fault conditions and the state transitions controlled by the detected interlock events. Removing an event does not automatically cause the machine to revert to the no-fault state. It will often be necessary to go through other steps to clear the fault. The steps for clearing each particular fault will be listed in a procedures manual.
This paper describes the Gemini Interlock System and role played by the EIPCS database language. EPICS is the natural choice for the GIS because of its facility in logging and handling various levels of alarms.