Figure 1: Network of the SUBARU Summit System.
Figure 1: PS 930 Kb
Next: The Integration of Telescopes, Instruments, and User Interfaces at KPNO and WIYN
Previous: Automatic Sequencing for Experimental Protocols
Table of Contents --- Search ---
PS reprint
George Kosugi, Yoshihiko Mizumoto, Toshiyuki Sasaki, Junichi Noumaru, Yoshihiro Chikada, Tadafumi Takata
National Astronomical Observatory of Japan (NAOJ)
Osawa 2-21-1, Mitaka, Tokyo 181, JAPAN
Yasuhide Ishihara, Jun Kawai, Akihiko Kidou
Fujitsu Limited 9-3 Nakase 1-Chome Mihama-ku Chiba, Chiba 261, JAPAN
The SUBARU computer system resides at three facilities; the SUBARU telescope at the top of Mauna Kea, a base facility at Hilo in Hawaii, and a headquarters at Mitaka in Tokyo. The computer system at the summit has the responsibility to control the telescope and the observing equipment, and to transfer acquired data to the Hilo base facility. The acquired data are basically analyzed and stored in an archival system at the Hilo facility. The Mitaka facility is expected to have nearly the same functions as the Hilo facility and to operate as a data archival center. Computers at other institutes and universities in Japan are planning to connect to the Mitaka computers. The SUBARU control system, located at the summit, controls the telescope and instruments and handles the observation data. Physically, the SUBARU control system consists of distributed computers and CPUs for the telescope and equipment control, for data acquisition, for data processing, and for monitoring the weather and telescope/enclosure environment. A current design of the SUBARU network is shown in Figure 1. These computers and CPUs are interconnected on the SUBARU control network which may consist of several segments; a control LAN (C-LAN) for the telescope and observation equipment (OBE) control, a data acquisition highway (DAQ-Highway) to transfer image data generated by the OBEs, a data LAN for distribution of image data and database data (D-LAN), a video LAN (V-LAN) for the digital video data which will be generated by auxiliary instruments and monitor systems, and a firewall segment for remote access. E-LANs can be used for transferring image data with low data rates and for controlling OBEs. The control LAN is divided, mainly for security, into two segments, one for the telescope control (C-LAN(T)) and one for the OBEs control (C-LAN(O)). As some OBEs produce huge amounts of data with high rates (an estimated maximum data production rate of 20 Mbytes/second), the data LAN should be separated from the control LAN to avoid interference with control sequences and signals. A standard clock which is generated with a GPS receiver and a rubidium clock are planned to be supplied via the control LAN by using Network Time Protocol (NTP). There are mainly three clusters of computers (OBC/OBCP, TSC, OBS) concerned with the observation control. Data acquisition computers (OBC/OBCP) take charge of the observation equipment control. Data produced from OBE are transferred via DAQ-Highway or E-LANs to the OBC/OBCP, which processes the acquired data for quick-look and for examining statistics of the data. OBC then transfers the data to a remote archival system located at the Hilo base facility via an OC12 network with an ATM protocol. The raw data will be stored in the mass-storage and the tape library for backup at the summit. The telescope control system consists of processors of three levels; a telescope control computer (TSC), mid-level processors (MLP), and local processor units (LCU) which control individual devices. TSC controls three MLPs, which organize LCUs and carry out interlocking among the LCU operations. TSC also manages the interface between the telescope control system and the observation control system. OBS is a supervisor for the observation scheduling. Two key processes, the observation scheduler and the status logger, are designed to perform efficiency and security by cooperation with any other processes as described below.
Figure 1: Network of the SUBARU Summit System.
Figure 1: PS 930 Kb
Figure 2: Control Flow for Observation Scheduling and Status Logging.
Figure 2: PS 2.5 Mb
The observation control system is composed of several subsystems for scheduling and logging status, telescope control, observing equipment (OBE) control, data acquisition, data reduction and analysis, data archive and remote access control. The final goal of the system is that the scheduler subsystem controls both the telescope and equipment by actively configuring the optimized observation scheme. A logger subsystem collects status information generated by other subsystems so that the scheduler can recognize every status of the system without access to each subsystem. The scheduler and logger subsystems are composed of several processes. Basic data inputs to control processes are the observation program which consists of the observation list and the observation constraints. Then Translator and Optimizer transform this observation program into observation datasets and observation procedures. Common procedures among several exposures are merged to a single one by the Optimizer. The Optimizer should work with the help of an optimizing scheduling engine by examining the status of the telescope and OBEs and the data previously taken with the OBEs, as well as by monitoring weather and seeing. Once images are produced from the OBEs, they are immediately analyzed as described in the observation procedure file by the data analysis system working on OBC, and the results are stored in the logger subsystem. In accordance with the extracted results such as the S/N ratio, Optimizer makes real-time re-optimization of the observation procedure. We are planning to link the data analysis system on OBC and on the super computer in Hilo to each other. In that case, the fairly complicated data analysis with huge image data sets such as from the mosaic CCD (160 Mbytes/frame typically) will be accomplished rapidly. As we have seven instruments approved for the SUBARU telescope, an observation schedule is expected to be optimized based on abstract commands for these instruments with the help of device-dependent parameters and operation sequence/timing in a Device Table. Executor executes an abstract command under observation restrictions, examined with Condition Checker. Decoder transforms the abstract command to device commands by using parameters stored in the Device Table. Device commands are sent to each instrument by Command Dispatcher with some synchronizing mechanism supplied by Status Checker.