 |
L. Fini, Osservatorio di Arcetri
Large Binocular Telescope Project
Technical Memo
OAA-98-01 lbtcontrol.tex 940f001a
December 11, 1998
In the following pages some ideas about the general features of the control software for the LBT are introduced and some aspects related to the software architecture and the design and implementation strategies are discussed with the purpose of stimulating further discussion within the LBT community.
The content of this document is not the offspring of the author alone, but benefits from discussions with G. Brusa, C. Del Vecchio, L. Miglietta, P .Ranfagni, A. Riccardi, P. Salinari.
All mistakes and omissions are mine only.
This report must not be considered as a proposal for the LBT Control Software or as a preliminary design of the control system, but rather as a mean to highlight some areas where further discussion is needed within a short time.
Although in some parts of the report specific problems are addressed and the related solutions are proposed, this is not to "freeze" particular choices, but only for the purpose of clarifying the topics discussed with examples as close as possible to the real world.
The LBT, not unlike the other telescopes of the last generation, is an extremely complex machine in which a large number of subsystems must cooperate in order to obtain the required quality of operation: this is due not only to the complexity of the telescope itself, but also to the strict interaction among the telescope, the instrumentation, the dome and the surrounding environment. In this respect we may consider as a target of the control system not the telescope alone, but the entire observatory and we will refer in the following pages to the control system as the "Observatory Control System" (OCS).
The LBT has various focal stations and operating modes, and the capability of fast switching among operating modes depending on observing conditions is one of the key points to optimize the scientific productivity of the telescope. In order to allow proper control of the dome environment and of the operating conditions of the telescope a large number of subsystems not directly related with the telescope itself must concurrently be operated (snow melting devices, fans, chillers, weather station, are examples of such subsystems).
It is thus clear that a proper and safe operation of the observatory will require that a suitable control system be in charge of the management not only when in observing mode, which is obvious, but also for almost any possible operating modes, including preliminary tests during commissioning, maintenance, setup operations prior of observing, instrumentation tests, and so on.
It must be also considered that the pointing and tracking functions, albeit crucial for the performance of the telescope, will likely account for only a very small fraction of the total complexity of the control system and of the related software, while the manifold of engineering tasks to be performed either during observation or during maintenance and other non observation tasks, will actually drive the requirements related to the control software.
In order to fix some key-points related to the control software specifications it is necessary to sketch, at least approximately, the overall architecture of the OCS1. It must be also clear that the brief resume reported here is not complete and detailed enough to be used as a basis for the design specification of the LBT control software, but is only provided to allow a preliminary discussion related to the structure of the control software, the design strategies, the development techniques, and so on.
As it is shown in figure 1, the OCS for LBT can be sketched as a group of ancillary control units (ACU) with different characteristics and purposes each of which has the direct control of some subsystem. Coordination of the subsystems is performed by a supervisor which gathers status information from the ACUs and issues appropriate commands to them.
In figure 2 all the LBT subsystems are listed for reference purpose. They are grouped into larger subparts, but each item in the list is a fairly complex assembly with its own control electronics and software.
It must be noted that most of the telescope subsystems have complex interactions among each other, in that the operation of one of them may depend on the status of others for safety, performances or other reasons. Various interlocks will be provided by hardware devices for safety reasons, but their purpose is only to avoid conditions which may lead to damages to the equipment. In normal operation all the interlocking functions must be provided by the control software so that abnormal conditions are detected and avoided before potentially dangerous states can be reached.
ACUs are implemented with VME based crates hosting some 680xx CPU2 with the appropriate interfaces toward the controlled subsystems. Although figure 1 has to be considered as an example for the purposes of the discussion about system architecture in that it doesn't represent the final layout of the working system, various possible configurations are represented: some of the ACUs will host custom data interface boards connected to specific devices, other will use standard interfaces towards some kind of field bus such as RS 422, CAN, IEEE 488, to connect to remote PLCs, other will be intelligent boards equipped with programmable devices such as DSPs or SBCs.
The ACUs will run the VxWorks operating system.
Due to the complexity of the control system and the fact that it will be used by different kinds of users, i.e.: the observer, the management staff, maintenance engineers, and so on, possibly at different locations, it is advisable that the supervisor functions can be split among a number of control workstations (CWS). Supervisor tasks will be allocated to various workstation in a flexible way according to the various needs. This capability will provide as a byproduct the possibility to perform all supervisor functions, and notably diagnostics, from a remote location.
The control workstations will be standard workstations such as SparcStations or Intel based PCs and will run some version of the Unix operating system with the X windowing software.
In order to allow communication between the CWSs and the ACUs a suitable network must connect them. For the purpose of this discussion the specification of the networking technologies and the layout of the connections is not required; we will only assume that the network provides enough communication bandwidth and delay times compatible with the coordination tasks.
The network protocol will be based on the TCP/IP suite.
In this section we will list a number of features and operational modes which must be provided by the LBT control system in order to allow the required flexibility and safety of operation.
The kind of information about the telescope and the control capabilities useful to the observing astronomer are obviously quite different from the ones needed by a maintenance engineer, or by someone who is integrating a new piece of instrumentation.
One of the required features of the OCS is thus the capability to present different views of the system for different purposes. A tool for the quick assembly of a particular configuration of a console could be very handy both for diagnostic and for the implementation and testing of new features.
Telescope control functions must be divided into different levels, e.g.: the subset of functions available to the observing astronomer will be much smaller than the one provided for the maintenance engineer; the latter, in turn, will probably not have access to some very specialized functions which may be useful when debugging and testing the system, and so on. A hierarchy of levels of control will be established: the highest the level the more complex and ``constrained'' will be the available functions. On the other side at lower levels simpler functions will be available but with a higher degree of freedom in the capabilities.
The access to any level must be protected by some authentication mechanism in order to ensure that only properly trained personnel accesses each level of control.
In order to support diagnostics and maintenance of the LBT subsystems a complete log of telescope statuses during operation must be recorded with proper time resolution. The status record will be very useful for debugging, simulation, preventive maintenance planning and so on.
The data flow deriving from this function might be pretty heavy, so a careful design of this part of the system is advisable.
The purpose of the LBT control software is to provide all the functionalities resulting from the above discussion with a further strong requirement: an open software environment. This essentially means that we must have the complete control on the software technologies and tools employed, because we must from one side provide specifications and support to instrument developers and on the other side allow the continuous enhancements and addition of new functionalities which are typical of a research instrument.
The LBT Control Software will be subdivided on a number of different CPUs and operating environments. Great care must be devoted to maintain the number of different operating environments to the minimum reasonable but it is obvious that either due to specific needs of subsystems or to the evolution of the system during its lifetime, some degree of heterogeneity will always be needed.
Different parts of the system will be implemented by different groups and contracts for some of the subsystems will likely include the software development at least for portions of software running on the ACUs. This will prevent the possibility to enforce a strict control on the software environment and developing techniques.
For this reason a number of suitable standards must be adopted in an early stage of the software design so that coordination of the different parts can be maintained manageable.
In figure 3 a sketch of the LBT control system software architecture is shown. The LBT control software is built around four main components which may be further subdivided into two levels:
At the lower level the system is made up of a set of software subsystems which have direct control on one or more telescope subsystems. E.g.: the telescope drives are controlled by an ACU and the related software. This module will implement the lower level (and higher frequency) control functions for the telescope axes drives; e.g.: it will provide the detailed motion control (position, speed, acceleration) and all the other local housekeeping function which are required. It will receive high level commands from the supervisor and will provide it with a proper subset of its internal data to be used for status monitoring.
At the higher level the system is divided into three components which, together, constitute the supervisor.
All the components are designed as independent tasks and will interact via messages passed through the network. This will allow a clear subdivision of specific tasks and the possibility to assign resources to each task as required in a flexible way.
It must also be noted that even the three components of the supervisor which are sketched as blocks in figure 3, are to be considered logical units from the architecture point of view, but their actual implementation might be done on a distributed system. E.g.: while a single CPU implementation for the RT-DBMS and the Supervisor Kernel could be a good choice, the User Interface functions will necessarily be split on several CPUs.
The ACUs Subsystems can only be described in very general terms in that their functions and architecture will strictly depend on the particular subsystem.
Each subsystem has its own specific problems and could be implemented independently from the other3, except for the fact that all of them must interact with the supervisor and at the end will need to be integrated into the OCS, so the problem to provide well sound specifications both for internal use and for the contractors will soon arise.
The Real Time Data Base System (RT-DBMS) has the purpose to maintain a global table of all the data necessary to completely define the status of the OCS. It communicates with all the ACUs to gather data either by polling at proper timings or upon request of the ACUs which signal that some data has changed4. All data items will be marked with the time of occurrence with resolution compatible with the specific process. All the knowledge needed to access data on the ACUs is confined in the RT-DBMS: no other components will never need to access data directly from ACUs in that all data will be retrieved from the RT-DBMS.
The status-logging facility could be implemented as a function of the RT-DBMS, so that no other subsystem has the need to cope with this particular problem.
The Supervisor Kernel (SK) has the purpose to coordinate all the operational requests from the User Interfaces. All the command consistency controls, safety controls, priority arbitration, and so on, are performed by the supervisor kernel.
User Interfaces are a crucial point in a software system. It is actually the part of the system that all users see, and its quality is of the greatest importance. In the case of a long life project, as the LBT is, a key feature of the user interface is the capability to grow easily to follow the evolution of the whole system.
At least two kinds of User Interfaces are needed for the OCS:
As it is usual in software system a considerable part of the development effort will be consumed in the GUI, so a good choice of the software environment and the development tools is particularly important.
The LBT Control Software must provide a number of consolidated and well defined Application Program Interfaces to be used by system programmers at various levels.
At least three levels of API will be needed:
All the software development both related to the OCS and to satellite activities such as instrument integration or observation planning support will be based to the above defined APIs: it is thus of crucial importance that these are well defined and stabilized as soon as possible.
All the OCS software will be supported by some sort of Run Time Environment. This will be represented at least by the supporting Operating Systems, but in order to cut development times, a higher level Run Time support environment could be adopted for some parts of the system.
In this respect the growing success that EPICS6 is gaining in the telescope community can be taken into account.
As it should be clear from the above discussion the software system supporting the OCS is a very complex and sensible set of programs and utilities running in a distributed environment. It is obvious, as a consequence that the software design and development processes must adhere to strict quality standards and be performed following well established and strictly enforced rules and procedures. The greatest care must be devoted to the selection of runtime environments, coding languages and rules, documentation standards, development tools.
A proper procedure must be established for software revision, test and acceptance.
Some of the preliminary decisions related to the software architecture, the coding standards and the like must be adopted as soon as possible because at least some of the subsystem are already in construction phase and will need some software support also in the factory for the activities related to pre-erection. It is advisable that also those preliminary pieces of software can be already developed according to the general LBT specifications so that they can be used as building blocks of the final system.
The choice of programming languages to be used for the OCS software coding is driven by a tradeoff among various aspects: a) suitability to the task, b) availability of programmers, c) other constraints depending on runtime environment support and/or the availability of high level packages suited to some of the tasks, d) future support.
As a preliminary choice the restriction to C/C++ for the coding of all the subsystems except the GUIs seems a well sound choice.
The GUIs are a special case in that the use of Java seems to provide a number of advantages for this particular component.
The quality of the documentation is a crucial point for the reliability and the maintainability of a complex software system.
To ensure that for this particular issue the requirements are met, the software documentation (as well as other kind of documentation, by the way) must undergo the same revision, test and acceptance procedures than the software itself.
A proper development of a complex software system cannot be performed without the support of proper tools.
Here is a short list of some areas which could be improved with the adoption of CASE tools:
This would also positively affect the following coding phase.
The adoption of consolidated libraries of modules for some parts of the development (E.G.: access to devices, GUI layout, etc.) could contribute to cut down the development time.
As it should be clear after the discussion in the previous pages the design and implementation of the software for the control of the LBT and the related subsystems is both a very complex and crucial task. None of the goals of the LBT project will be reached unless an high quality software system is available.
The complexity of the system will make it necessary to coordinate carefully the work of various teams, both on the industrial and on the academic sides.
A number of decisions related to the specification, the architecture and design procedures for the development of the OCS software must be frozen as early as possible if we want the software development to be aligned with the rest of the project both in quality and in time. A subset of the software modules, those related with ACUs, has even stricter time constraints because some of the subsystems are already in production phase and will soon need some kind of control software.
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 1 -no_navigation -antialias -no_footnode 940f001a.
The translation was initiated by Luca Fini on 1998-12-11
Doc_info_start Title: LBT Instrument Standards Document Type: Technical Report Source: Osservatorio di Arcetri Issued by: Luca Fini Date of Issue: 22/12/98 Revised by: Date of Revision: Checked by: Date of Check: Accepted by: Date of Acceptance: Released by: Date of Release: File Type: HTML Local Name: 940f001a.htm Category: Miscellaneous Sub-Category: More Project Office Assembly: Sub-Assembly: Part Name: CAN designation: 940f001 Revision: A Doc_info_end
