The overall conceptual structure of the NCCS software model can best be described in terms of the following top-down schematic:
(Multiple) User Interfaces
| |
HartRAO Scheduler <---> VLBI Control System
| |
Astronomical Observing Algorithms |
| |
HartRAO Station Library Routines
|
SYPARM Configuration Database
(via ESRF TACO Application Programming Interface)
|
Device Server Processes
|
Physical Hardware
where:
The main purpose of the HartRAO scheduler is to parcel out amongst competing proposals use of the most 'expensive' device in the control system, namely the 26m telescope itself. The scheduler will also need to allocate time for maintenance, interactive observing, VLBI etc. To this end it must act as the master controller of the system, ensuring that the designated proposal will have access to all the devices it needs to set up and run an observing configuration and further ensuring that such access is unique ie. no other process can disturb these devices. An exact scheduler design is still needed. The initial concept is described in NCCS Scheduler Design and Implementation.
The Field System 9.3.x VLBI software supplied by the NASA Geodetic VLBI group is designed to operate as a standalone control system. To this end it will need to be able to operate with the priviledges of the scheduler. To integrate VLBI into standard observing, it will need to interlock with the HartRAO Scheduler using a priority VLBI override mode. Details of the handover need to be integrated into the scheduler design.
If all interactive observing and source scheduling support is amalgamated into the scheduler, each observing programs need merely be able to handle single observations of a specific object as designated by the scheduler at run time. Obviously each observing mode would also need specific support within the scheduler itself together with some form of source file composer/editor. Details of the conceptual source file design can be found in NCCS Input Files for Single-Dish Observing. It is also proposed to use a common modified FITS data output format as described in NCCS Output Files from Single-Dish Observing.
Each observing algorithm can be broken down into a sequence of simple code blocks, many of which are common to two or more algorithms. To reduce code redundancy and improve maintainability, a dynamically loadable station library implementing the individual building blocks is being developed at HartRAO. All this functionality is then implemented once in a single code base which can be updated without having to recompile or relink the various algorithms that make use of it. Extensive effort is being made to make these routines as reconfigurable as the device servers they control through the same resource database concept.
With the advent of a multitude of computer-controlled components in the various receiver systems, together with a proliferation of various interconnecting selector switches, it became clear that some central mechanism would be needed to keep track of and setup all the useable observing configurations. Since receiver setups are not static, this would need continuous maintenance, suggesting that it would be ill advised to hard code the various rules in software without reference to runtime configuration. A new separate SYPARM table was added into the HartRAO resource database implementation to contain all the lists and resources which describe the components and their interconnections. Calibration factors have been associated with most relevant components to facilitate tracking of which changes will affect calibration etc.
All support for the SYPARM database is coded as building blocks in the station library to ensure that all necessary functionality is made available there and not in disjoint code fragments associated with separate NCCS components. Every attempt will be made to keep all of the external configuration and access routines and their arguments consistent across library versions though the internal structure and associated SYPARM resources may vary quite considerably.
Its design is decribed in SYPARM Library design.
The entire connection to and parts of the software controlling the individual hardware devices is handled via the Telescope and Accelerator Control Object (TACO) API library supplied (either in source code or binary format) and maintained by various programmers at the European Synchrotron Radiation Facility (ESRF), see Telescope and Accelerator COntrol (TACO) System home page.
This takes the form of dynamically loadable libraries against which all the related NCCS software is linked. Use of shared libraries ensures that the TACO layer can be upgraded easily without the need to recompile and/or relink. Currently we are using Device Server API V6.6, Database API V5.10, and Device Server XDR V5.17 from the first TACO source code release.
Most of the NCCS hardware is connected to various interfaces on the main $NETHOST machine. Due to the dynamic allocation capabilities of the TACO control system, it is however possible to connect them to any machine that equipped with the requisite interface, with reconfiguration involving only a change to the responsible machine name in the startup/shutdown scripts. Even the Steer interface cage can in principle be moved to any machine by connecting it through a suitable PC14B interface card.
Typically each type of hardware device is handled by a device specific server that is capable of handling one or more such devices. In addition a serial based control bus known as SDIO (Serial Digital Input Output) has been developed which is capable of handling a large range of devices through a single standard RS232 serial port. Since the SDIO is based on a cooperative protocol, all of the devices on each serial port have to be handled by a single multi-device server which is capable of handling multiple device types. The current range of device servers includes the following:
The Antenna Control Subsystem is handled through a single monolithic device server which talks to the actual control sub-process through a shared memory segment or "dataport". The subprocess in turn controls the antenna in real time through the Steer interface cage connected to a PC14B interface card.
All devices connected to the SDIO tree connected to any one serial port are controlled by a single device server. The currently supported SDIO based devices are:
Note: Although device server binaries exist for each SDIO derivative device above, they should NOT be used as they are device specific ie. do not support multiple types of device on the same SDIO tree.
The NCCS includes a single Log/Alarm/Watchdog component implemented as a "software device" server. This in turn makes use of low-level hardware alarm/watchdog devices through their respective device servers and TACO.
Once the control system is up and running, all of the relevant hardware is then available as a set of HartRAO TACO control objects that may be manipulated via the TACO device server Application Programming Interface (API) libraries. The only exceptions to this model are certain parts of the VLBI sub-system which are controlled directly by non-TACO device servers internal to the VLBI Field System itself eg. the Mark IV data acquisition terminal and tape drive etc.
For more information on Device Server software, start at the Hartebeesthoek Local Guide for Device Server Programmers (DSP)