I. INTRODUCTION

Our group was asked: "What does the telescope & facility need to provide for instrument control & calibration? What instrument info needs to get to the TCS & vice versa, how often?" We were provided with a description of the Gemini hardware instrument/telescope interface as a starting point for our discussions. The revision of this report (by GC) reflects irreversible SOAR Project Office decisions that have been made in the interim and which are not justified here; additions to the text by GC are in this red.

1) Why compatibility?

• Allows us to put our resources into things we need to change or improve rather than reinventing solutions to common problems. Gemini is applying a far greater budget to these problems and drawing on a larger community for input. However, because their budget is much greater each of their solutions must be critically examined to see if it is practical for SOAR. Moreover, many of their decisions were made years ago, so are clouded by issues of technological obsolescence.
• We see potentially significant cost savings from adopting or adapting in the following areas:
• specifications for instrument and telescope subsystem interfaces (active optics, tip tilt, wavefront sensors etc.). Tip/tilt and WFS will be addressed in the 2nd wave of SOAR contracts. It may turn out that Gemini's quest for ultimate performance exceeds out budget or manpower.
• design (observatory control system software, data handling system, alarm and status data base, control and data communication paths). SOAR has decided not to adopt the EPICS shareware package for the TCS. The OCS does not depend on EPICS so is a good candidate for adoption by SOAR. The alarm and status database is easily customized for SOAR in LabVIEW/BridgeVIEW. Adopting the rest for SOAR is TBD.
• documentation. Where relevant, sure. SOAR is doing that with e.g. the Wallace TCS.
• and especially debugging of the above. Gemini will have commisioned both its telescopes and its plausible that Gemini commissioning staff in Chile could move or contribute their expertise to SOAR. They will certainly be clever people, and may actually prefer the SOAR solution.
• During the operational phase, Gemini compatibility could provide:
• mutual technical support (shared problems, shared insights).
• backup staffing in periods of crisis.
• SOAR inherits new or ugraded Gemini software and can use hardware design improvements. Again there is a budgetary mismatch that may make Gemini hardware and software impractical for SOAR. There is an implicit assumption throughput this document that Gemini's choices are optimal for everyone. In fact they inevitably resulted from trades which probably had different criteria and weights for us.

* Similar imaging performance goals and technological approach. * Similar interests in remote observing and queue scheduling featuring rapid switches between instruments, with the likelihood of sharing at least the communication infrastructure. * Both projects serve broad user communities from the USA and Brazil. * Identical need for standard interfaces between all telescope subsystems and instruments and detectors. * Adjacent sites and very limited support staff: considerable potential for exchange of expertise and even spare parts. * SOAR science will support Gemini science, often with the same observers moving between telescopes. Common interfaces to astronomers (reduction and acquisition) and even telescope operators would be highly beneficial.

II. MECHANICAL COMPATIBILITY.

This already has been discussed by the SAC. The adopted requirements are for Gemini compatibility subject to some reduction in maximum mass, moment and volume. The project goal is to achieve the full Gemini specification in these areas. We understand that either Nasmyth port could in principle be configured this way , but that the present working plan (since the demise of the GNIRS clone) is that three-instrument clusters will normally be at both ports. When and if a Gemini instrument actually arrives at SOAR, a three-instrument cluster will be removed and the Gemini instrument mounted. We recommend that the actual bolt patterns and interface panels for the instruments on the three-instrument port should be identical to the one on the single-instrument port, so that instruments intended for the three-instrument port can easily be used on the one-instrument port if desired. I guess this says that the bolt pattern should be that of Gemini, which may be impractical considering that the clear aperture of their instruments is almost the same as the dimensions of our instrument cluster! In other words, why use their bolts if we can't mount our instruments on their telescope anyway?

III. CONNECTOR COMPATIBILITY.

The Gemini connector set and configuration is described in Gemini ICD (Interface Control Document) 1.9/3.6 "Science and Facility Instruments to System services Interface Control Document". Gemini will have a total of 32 connector panels in their cassegrain area. Each panel measures 10cm x 50cm. Each Gemini instrument requires a group of four panels for all of its connections. The full set of 32 panels includes spare panels and groups of panels allocated to the Gemini Aquisition and Guide, AO and Calibration units. Each individual instrument would be served by a set of four panels occupying a 40cm x 50 cm area with the general functions (1) Spare, (2) Electronics connections, (3) Mains/UPS Power, (4) Air, Helium, Coolant.

In general we feel that SOAR should adopt this same standard. We recommend that at each port SOAR should be designed to provide one set of four Gemini panels per instrument, plus one set for the A&G unit, plus one spare set. Both Nasmyth ports should be upgradable to supply three instruments. SOAR should use the same connectors as Gemini. This will be examined for feasibility on SOAR. However the problem is that Gemini has far more area for connectors than we do and their connectors may not enjoy being cramped.

However, we noticed three items that were missing from the Gemini specifications:

• Vacuum system. Even though vacuum has been used widely in the past to pump on liquid-helium-filled IR dewars, we do not expect it to be required for cooling future IR instruments. However, vacuum is sometimes needed in actuator mechanisms or in applications such as bending an aperture plate. The Hydra instrument being built for the Blanco telescope requires vacuum. The SAC feels that vacuum should be provided for on SOAR.
• Dry nitrogen. This would be useful for preventing condensation on dewar windows, rather than using window heaters (which both make heat and do not work well for large windows). It would also permit the slight pressurization of the interiors of instruments to help keep out dust and humidity, and helps to prevent oxidation on sol-gel coatings. SAC recommends that this be provided for SOAR.
• Grounding strategy. Inadequate grounding has been a persistent problem on the existing CTIO telescopes, often leading to 60-Hz noise in faint signals from our detectors. A proper grounding strategy should be developed and enforced on SOAR. It should include the telescope, instruments, and detector subsystems. This must also consider possible requirements for electrical isolation between subsystems. We still need to determine whether there is an existing Gemini specification for grounding; if so we may want to copy it.

• Two helium supply systems. Gemini calls for both Gifford-McMahon (GM) and Joule-Thomson (JT) systems. GM is widely used, but has the drawback of producing sometimes excessive vibrations at the instrument. However,the MICHELLE mid-IR imager is the only instrument we know of which uses or contemplates using JT. However, there may also be potential applications for cooling CCDs.  The SOAR Instrument Committee felt that cryocoolers would only be used on InSb-based Gemini IR instruments. There are none identified presently, so the intent is to install He flex lines but not compressors etc.

IV. COMPATIBILITY OF BASIC POWER SYSTEMS AND UTILITY SUPPLIES.

We recommend adhering to the Gemini power standards for instrument power. This would provide 50 Hz power as follows:
 

A more detailed description is given in the accompanying document "Recommended Power Specifications for SOAR", by R. Smith and G. Brehmer.

The Gemini specifications for other utilities are:

• Air supply: 80-100 psi, 120 l/min.
• Coolant: Ethylene-glycol/H2O at 0 deg C, 15 psi, 6 l/min.
• Helium GM supply at 300 psi, 3200 l/min.

We also recommend adopting the Gemini cooled enclosures that go with each instrument if they are cost effective. Gemini supplies these to the instrument builders. There are two types -- one is 1.3 m tall, the other 1.5 m tall. Both are ~34" deep and ~24" m wide. They have full size front/rear doors to access electronics and a breakout panel for distribution of power and signal lines. The 1.3 m enclosure weighs 94 kg, and the 1.5 m enclosure 106 kg. They are designed to handle a maximum power of ~1500 W and leak <50 W into the external environment.

V. SOFTWARE COMPATIBILITY.

This, including the issue of what electronics hardware supports the software, is by far the largest question faced in this document.

Most of what follows is of historical interest only. SOAR decided not to adopt EPICS shareware, instead opting for LabVIEW/BridgeVIEW commercial software that has better tool, language, and more complete driver support, runs on cheaper hardware/software platforms, and has perfectly adequate performance for our anticipated needs.

Our task group is assigned to study the issues of interfaces and Gemini compatibility, and should not try to specify details of the telescope design. However, the Gemini approach treats the instruments as a closely interwoven part of the telescope, in the sense that there is tight coordination of instrument control to implement observing sequences which involve both telescope and instrument commands and status, there is a global status monitoring and logging approach, header information comes from a wide variety of sources, and a goal is to provide real time feedback of both science and telescope data to plan the next observation. In addition, we think it is very desirable from the standpoints of both scientific usability and ease of operation that the user interface for SOAR look very similar to that for Gemini, especially in terms of specifying instrument setups and queue observations. Therefore we will briefly describe Gemini's overall approach.

A brief overview of the Gemini software approach can be found on the Gemini website in Gemini Preprint No. 14, "The software design of the Gemini 8m telescopes", by Steve Wampler. The control system software is organized into four principal systems:

• Observatory Control System (OCS). Provides the interface to the on-site observer and coordinates the activities of the other principal systems.
• Telescope Control System (TCS). Controls the telescope through several subsystems.
• Instrument Control Systems (ICS). There is one ICS per instrument. It sets up the instrument and the detector, controls the exposure and the detector readout, and supplies the science data and header information to the DHS for processing.
• Data Handling System (DHS). Accepts data from the instruments, archives it, provides quick-look reductions.

FIGURE 2.

EPICS is a publicly available data base and control system developed by several atomic accelerator labs. It is described at http://epics.aps.anl.gov:80/asd/controls/epics/EpicsDocumentation/WWWPages/EpicsFrames.html

The instrument side of the software/hardware system is based on a "standard controller". This is a VME crate with a fairly specific set of hardware modules including a Motorola cpu capable of running VxWorks and EPICS. The Gemini architecture allocates one standard controller for the various mechanisms on an instrument, and another one for the detector. An Instrument Control System (ICS) then consists of one or more of these VxWorks systems supporting software called the Instrument Sequencer, which in turn supervises via EPICS a detector controller and a component controller. A brief introduction to how this is intended to work is given in Gemini ICD 7a "ICS Subsystem Interfaces". Figures 3 and 4, from that document, show the basic setup.

ICD 7a notes that if the Gemini project chooses to use an existing detector controller rather than building one in-house, it might not have the same architecture as shown in Figure 3, but would still have to act like an EPICS channel access server at the interface with the control LAN.

This ICD also says that if an instrument has an on-instrument wavefront sensor (OIWFS), the component controller for that OIWFS will be mounted on the instrument's standard controller, but will not be controlled by the Instrument Sequencer that controls the rest of the instrument. Instead it will be controlled by the A&G controller, which is a subsystem of the TCS.

Otherwise the Instrument Sequencer software is responsible for managing the interfaces between all the instrument systems and the OCS, DHS and TCS.

The Gemini literature also discusses the possibility of "non-conforming" instruments. This is described in ICD 8 "Non-Conforming ICS Interfaces", which mostly says that it is possible for instruments to follow only part of the Gemini standard, at the cost of not having the full functionality of the telescope-instrument interaction. However, any instrument that wants to have any interaction at all with Gemini, even at the level of obtaining basic header information, must have an EPICS connection to the telescope environment.

Finally, it should be noted that all Gemini instruments are required to have a stand-alone capability for operation in an engineering mode. We do not know any details, but this may provide a basis for operating Gemini instruments on SOAR with no interaction with the telescope. Indeed, this is the approach that we will adopt to accommodate Gemini instruments if they ever show up on SOAR.

SOAR has decided not to follow the Gemini standard for the following main reason:

• The standard controller is described in Gemini ICD 13 "Standard Controller". The estimated cost of hardware and propietory software in 1996 was $34K. Two VME controllers are needed per instrument/detector combination. There is thus a $70K cost overhead per instrument to be Gemini compatible, plus the people developing the instrument software must be familiar with the fairly complex Gemini standards and with EPICS which is decidely user-unfriendly.
• These protocols and the standard controller package use hardware which inevitably will be obsolescent by the time SOAR adopts it. SOAR would be tied to Gemini, and at the point Gemini has to move to newer hardware SOAR would be under considerable pressure to follow the same route on a fairly short time scale, whether or not it was convenient. The cost of shortened hardware lifetime must be traded against the savings in system design and debug. The trade has been debated and the Project decided to go with modern (compactPCI instead of VME) hardware.
• There would also be an ongoing problem about how to keep the Gemini software compatible with SOAR and vice-versa; this would require continuing cooperation on the part of Gemini to not make changes that deleted functionality needed by SOAR. In fact the only part of the Gemini software that we have an interest in is the OCS. This JAVA/CORBA code does not depend on EPICS, so should be portable to SOAR in a straightforward manner. G. Schumacher notes (private conversation 1/99) that the OCS is becoming complex as it is actually written. It is becoming intertwined with the VLT and other large projects. If SOAR adopts it, it may take most of one programmer's time to stay current as an active participant. This may impose too great a financial burden on the operational phase of SOAR. The benefits of the Gemini OCS will have to be weighed carefully, once it is better defined.

• We feel that no matter exactly what we adopt, we must have some set of standards for the instrument-telescope interface in order to be able to maintain and operate the telescope in any reasonable manner. The Gemini use of EPICS is clearly an attempt to address many of the shortcomings of the interfaces presently used on many 4m-class telescopes (including the ones at NOAO), where there are many subsystems that do not do a good job of talking to each other. Keck, UKIRT and CFHT among others have also gone to EPICS-based interfaces because of the obvious benefit of having transparent communication between subsystems and the ability to have real time status display of any variable in the system. These capabilities enhance security of operations and greatly improve the tasks of debugging the system. If SOAR does not use the Gemini standard, it should still use something of similar complexity. In fact it seems that LabVIEW/BridgeVIEW offers exactly this flexibility but is not shareware so has excellent vendor support. It also does not need the ongoing license expense of VxWorks.
• Gemini North will be on the air a few years before SOAR and will have made all of this stuff work. To the extent that we can really copy it, we will have a working system instead of one of our own invention which we would then have to debug. Although it is a decision for the project office to make, this would pay off best if the project adopts OCS more-or-less in its entirety, at the cost of having to glue it on to the lower-level systems supplied by vendors. We note that EPICS is used only in the part of OCS that provides the current system state and alarm/status monitoring; not in the Observing Database used to define and schedule observations. This suggests that if SOAR does use the OCS user interface, we would have the option of gluing it to SOAR-specific software either above or below the EPICS layer. In fact, it appears likely that we will glue it to the LabVIEW/BridgeVIEW database.