The Observatory Reduction and Acquisition Control (ORAC) project began in April 1997 (Bridger et al. 1998) as a tightly funded project to overhaul the UKIRT Observing System. Specifically ORAC was to replace all of the software at UKIRT that interacted with the observer with a modern, flexible and extensible system. In October 1999 ORAC was delivered to UKIRT integrated with a recently delivered Infra-red imager, UFTI. The principal goals of the project were to increase the observing efficiency and hence the publication rate of UKIRT.
We took a systems level approach to the ORAC project. It was desirable to use modern software technologies and in addition the UKIRT control systems were to be moved onto the Unix platform. Interfaces with the existing UKIRT instruments, and other major Observatory systems, had to be supported. The effort required to completely rewrite existing telescope or instrument control systems was not available. Thus the design was highly modular, and much attention was paid to defining clean and extensible interfaces between the systems, allowing new instruments and new observing techniques to be supported with little effort. The interfaces were also based on the existing system, enabling backwards compatibility. The system naturally divided into a number of components.
The advance preparation system, (ORAC-OT, a Java application) facilitates complete preparation of observing at the users' home institute, and allows remote submission of the completed Science Program to the Observatory site (using Java RMI). Library Programs created and maintained by the expert observatory staff form a backbone to the majority of Science Programs, making preparation even simpler. ORAC-OT is a variant of the Gemini Observing Tool (Wampler et al. 1997), and supports integration with the Gemini Phase 1 tool.
Also a Java application, The Observing Manager (ORAC-OM, Tan et al. 2000) forms the initial observing interface at the telescope. A submitted Science Program can be retrieved by an authorized OM user who then selects observations to be executed. The OM translates each observation into the ASCII files that are used to drive the major UKIRT systems. The unrolled observing sequence is passed to the Observation Sequencer for execution. Concurrent instruments are supported by the creation of multiple Sequencers. Observation selection can be made in other ways (not necessarily by an interactive user), anticipating possible upgrades to support flexible scheduling
The Observation Sequencer (ORAC-OS) is the primary user-interface to observation control. This system is written in the Drama tasking environment, with a Java user-interface. Although completely new it is based heavily on the previous UKIRT system and provides a visible, interruptible command sequence. It is also table driven allowing new systems, including new instruments, to be included with no rebuilding. Limited dynamic control over the sequence is provided and there is provision for some command concurrency.
The ORAC Data Reduction system (ORAC-DR, Economou et al. 1998) is a pipelined system that uses the concepts of Recipes and Primitives to sequence applications from an algorithm engine (currently the Starlink application suite) ORAC-DR is almost fully decoupled from the acquisition system, being completely header-driven. Again the design of the system is highly modular, a Perl pipeline infrastructure using Perl primitives, linking to the algorithm engine using a messaging system. It is in principal possible to replace any of these parts.
An essential part of the overall system, the new UKIRT Data Handling System (DHS) is a collection of Drama tasks that receives data from the detector controller using the Gemini ICD3 interface (Hill & Gaudet 1996), collects header data from the other systems and then stores the data asynchronously to enhance efficiency. Additionally new data are passed to a modified version of the Gaia/Skycat tool for rapid display (Draper 1999, Herlin, Brighton & Beireilchel 1996). The DHS is being produced by the Michelle instrument project, a mid-infrared imager/spectrometer destined for UKIRT and Gemini.
The VMS ADAM based system already in operation at UKIRT used ASCII files, Configs and EXECs, to configure the instrument and sequence acquisition commands. Limited advance preparation was possible, and one instrument had an automatic, but not very extensible, data reduction facility (see references in Bridger et al. 1998). This system had been very successful in its 10+ years of use but a more extensible and flexible system was required for the increasingly sophisticated instruments and observing styles that UKIRT is developing. However, a limited budget (approximately 6 staff-years) was available to replace this system, so any new system would be limited in scope or would have to make significant use of existing software. We took the approach that the present system had been very successful, despite its limitations in the modern observing world, and so we used this experience to shorten the requirements capture process, and we also reused existing designs. Finally we took pragmatic design decisions in order to support the operation of legacy instruments and infrastructure, not requiring major upgrades to these systems.
The ORAC project has made extensive use of other peoples' software. This has been a choice determined not only by the tight funding of the project, but also by the convenient availability of suitable software precisely at the time the project was under way.
An examination of the Gemini Observing Tool (in beta release at the time) suggested that it came close to meeting our observation preparation needs but took a slightly different approach. Given all that the Tool gave us - a substantial code infra-structure and functionality that we could not possibly recreate within our budget (for instance a visual position editor) we re-examined our requirements and discovered that it was perfectly possible to meet them using the tool. We simply had to work with it and not against it. Ignoring the ``not invented here'' temptation has worked extremely well for us.
The Gemini dhsLib implementation of the ICD3 interface was becoming available at a time when UKIRT instrumentation was moving to Unix systems. Clearly UKIRT needed such a module. In addition Michelle is also to be a Gemini instrument, so it had to meet the ICD3 interface in any case. Thus adopting the dhsLib seemed to be a straightforward decision. Gaia/Skycat is a sophisticated image-viewing tool that also provided a Real-Time Display functionality. There simply was little point in re-inventing it.
The AAO's Drama system (Farrell, Shortridge & Bailey 1993) is a descendent of ADAM. Thus adopting it made use of our experience in tasking models, reducing our required implementation effort for many parts of the system. However, the use of Drama highlighted an issue that can arise with re-use: The dhsLib also uses the Drama messaging system, imp, which would seem at first to be an advantage. However, a single task cannot support two imp interfaces, one for the dhsLib and one for Drama, so creating one of our major problems. Thus software re-use is not necessarily straightforward - examining how the software's interfaces fit into your system must be an essential component.
There are other issues that arise in attempting to re-use software. In particular for software in development like the Gemini OT the timescales and directions of the software must be examined. For us the first of these problems did, and does exist. Despite this we feel strongly that ORAC has and will benefit from the synergy achieved and that timescales are a relatively short term issue.
Using other peoples' software carries risks. However, by bringing an open mind and a desire to make it work the experience can be very worthwhile. A large amount of functionality can be obtained essentially ``for free''. This is a worthy goal for small projects.
The ORAC system delivers a modern, flexible, extensible and easy to use system to UKIRT. It is a new system, but makes heavy use of familiar concepts and thus should allow a relatively painless transition to a new observing paradigm for UKIRT users. In creating this system there was extensive use of pre-existing software and of old designs. This was a challenging approach, but ultimately successful and rewarding. Delivery of the system was imminent at the time of the ADASS conference, but has been very successfully achieved at the time of writing. UKIRT has a new Observing System for the next Century.
The ORAC project would be much poorer without the software provided by many other groups: the Gemini Observing Tool team; the Gemini DHS team; the creators of Skycat; Starlink for the Gaia modification and its application suite; the AAO Drama team. Finally, many thanks to the JAC and ATC scientists and software engineers for many useful comments.
Bridger, A., Economou, F., Wright, G. S., & Currie, M. J. 1998, Proc. SPIE, 3349, 184, ed. P. J. Quinn
Draper, P. 1999 Starlink User Note 214, Starlink Project, Rutherford Appleton Laboratory
Economou, F., Bridger, A. Wright, G. S., Rees, N. P., & Jenness, T. 1998, in ASP Conf. Ser., Vol. 145, Astronomical Data Analysis Software and Systems VII, ed. R. Albrecht, R. N. Hook, & H. A. Bushouse (San Francisco: ASP), 196
Farrell, T. J., Shortridge, K., & Bailey, J. A. 1993, BAAS, 25, 954
Herlin, T., Brighton, A., & Biereilchel, P. 1996, in ASP Conf. Ser., Vol. 101, Astronomical Data Analysis Software and Systems V, ed. G. H. Jacoby & J. Barnes (San Francisco: ASP), 396
Hill, N. & Gaudet, S. 1996 Gemini Project document dhs_pdr_icd3, Dominion Astrophysical Observatory
Tan. M., Bridger A., Wright, G. S., Adamson, A., Currie, M. J., & Economou, F. 2000, this volume, 471
Wampler, S., Gillies, K., Puxley, P., & Walker, S. 1997 Proc. SPIE, 3112, 246, ed. H. Lewis