Engineering Techniques in the CERN RD-38 ( CICERO ) Project

The complexity of the software required in the forthcoming control systems for LHC experiments necessitates a re-think of the strategies employed in the design of such systems. Use of software engineering standards and systems development methodologies are required to ensure the success of High Energy Physics (HEP) control system design. The CERN RD-38 (CICERO) project aims to use modern software engineering methods such as Object Orientation to design the main building blocks of a generic control information system which will be based on the distributed object standard, CORBA [1]. This paper outlines conclusions that can be drawn from the use of Object Orientation and the ESA standards in the design of Cortex [2], an integrating environment which enables user control objects to be ‘plugged and played’ in CICERO. 1 The Cortex approach to Designing HEP Control Systems The large number and variety of parameters that require monitoring in HEP experiments as well as the complexity of the software to perform that monitoring and control has forced systems designers to reconsider the entire design of HEP control systems [3]. The increase in the numbers of sensors and in functionality required by these experiments has led inevitably to the construction of very heterogeneous and distributed control systems where integration and communication between the different detector (sub-)systems has become an issue. It is only by reducing the apparent complexity of the control system that the operation of these systems and their overall maintenance can be efficiently handled by physicists. In addition, since these experiments evolve over time, any HEP control system must also be scalable and flexible to change and provide reusability of its constituent components. To help reduce development costs and to simplify the apparent complexity of the HEP control systems, physicists are looking for partially reusable solutions to their technical problems. However, in the recent past it has proved difficult to integrate commercial products together (such as PLCs with front-end VME crates) and to integrate these products with existing CERN-made control (sub-)systems [4]. In essence, what is required by those responsible for HEP control systems is an overall framework to facilitate integration between control system components. Such a framework (or software integration platform) should go beyond defining standard interfaces; its design should guarantee that commercial products and 'home-grown' systems can exchange information and collaborate regardless of the organisation of the overall control system. The CICERO research and development project, involving both academic institutes and industrial partners, aims amongst other things to investigate the use of Object Oriented Design (OOD) techniques and distributed system standards in providing an integration framework (Cortex) to simplify HEP control systems design. The Cortex design concepts are described in another paper contributed to this conference [5]. Experience of the development of control systems for the LEP experiments [3] and anticipation of the increased demands which will be generated by the new and larger experiments for LHC, has identified the main constraints for the design of such an integrating scheme. Firstly, since the LHC experiments will be equipped with > 100,000 sensors and activators, the management of control system complexity is a major consideration. Object-oriented design techniques embodying abstraction, inheritance and the use of classes and objects will aid the design here. Secondly the problem of concurrent and collaborative software engineering requires addressing. This is particularly true when the development of the control software is carried out by engineers who are separated geographically. Thirdly, the software developed should provide stability, flexibility and availability of control system elements so that system downtime (both for repair and for upgrades) is minimised. Finally, the control system software should provide balanced, distributed processing in the heterogeneous environment of High Energy Physics (HEP) control systems. The architecture of any distributed control system will inevitably change during the lifetime of the accelerator or the experiment it is operating. As a consequence, Cortex must support a mechanism to allow a new version of the distributed control system to be in preparation off-line while an older one is operated on-line. Furthermore this off-line/online facility is needed since tests and validation (and possibly simulations) of a new configuration will be needed before it is applied to the operating on-line system. These constraints have led to a so-called dual-face approach being taken in CICERO for the Cortex integrating framework: * an off-line Cortex Repository is proposed to handle the logical descriptions of the architecture of the distributed control system and to describe the various information and commands to be exchanged between the different components. * an on-line Cortex Infrastructure is proposed comprising so-called Distributors through which the User (control) Components can exchange information and commands in a pseudo'plug-and-play' fashion. A generation mechanism is provided to facilitate updates of the on-line Infrastructure according to the Repository contents. The physicist then builds a logical model of the required control system architecture off-line in the Cortex Repository, specifying detail at the configuration level to enable updates to be carried out on the existing architecture. These updates are validated against the existing architecture and the generation procedure instantiates the updates and creates the new updated Cortex Infrastructure. The details behind the operation of Cortex have been dealt with elsewhere [6] & [7]; this paper examines the design approach taken in implementing the building blocks behind Cortex. In particular, section 2 investigates constraints on the Cortex design approach and section 3 outlines the methods followed in delivering a Cortex prototype. A critique of this approach is presented in section 4 and conclusions are drawn in the final section. 2 The Need for Software Engineering in the Design of HEP Control Systems Historically, high energy physicists have been slow in adopting the software engineering methods of computer scientists. The systems developed in HEP have often responded to the development needs on an ad-hoc basis, with many short term solutions to similar problems [3]. Structured software development methods have been used [8] for the analysis and design of control systems for HEP experiments at LEP. Since then, experience of structured software engineering methods and CASE tools has increased at CERN [9], [10]. As yet, however, there have only been a few examples of the use of OOD methods in the design of control systems at CERN. One notable exception is that of Myers et al [11] which investigated the use of OOD in a controls environment. In industry, OOD techniques are more prevalent and have been used in the design of control systems for Supervisory Control And Data Acquisition (SCADA). Ericsson et al [12], advocate both the use of object design techniques and the use of CORBA as the distributed communication platform for control systems. The CICERO project is using both OOD and CORBA to implement a generic control information system for LHC experiments. As HEP control systems evolve for LHC, the need for rigor in software engineering increases in importance. In addition, as the development of these complex systems is increasingly carried out remotely from CERN or by developers on short-term contracts at CERN, the need for clearly defined deliverable code and interfaces between (sub-)systems also becomes crucial. As a consequence, software engineering standards have been investigated in the last few years by large groups of developers in HEP. Furthermore, work at the European Southern Observatory [13] into standards has recommended the use of the European Space Agency software engineering standards alongside those from the IEEE and IEE. LHC experiments will involve collaborations of many tens of institutes and over 1,000 physicists, engineers and computer scientists from around the world. The knowledge required to construct and monitor the hearts of the experimental detectors will be distributed between these institutes making it difficult to impose standards. There will consequently be significant problems of information transfer in ensuring that each detector subsection retains autonomy of control but can work with other detector subsections for data-acquisition. In addition, the LHC detectors will be required to have a long lifecycle, since the experiments will take data for several years and as a consequence maintainability will be an important consideration. Clearly, to reduce problems of interoperability and integration the project needs to adopt a set of standards both for the development of the CICERO software and its operation across heterogeneous hardware platforms [5]. The methods used and the standards followed must enable collaborative working in a systematic manner and adherence to a strict discipline. Support tools are required to provide crosschecks of the design and to reduce the possibility of error in the construction of design models. 3 The Choice of Methods and Standards in CICERO The European Space Agency Procedures, Specifications and Standards [14] method has been atapted as an essential feature of CICERO. This standard has been developed for the European Space Agency to ensure that any project has the best chance of being successful. There are two major parts: the product standards themselves and the procedures standards used to produce them. The products are the documents and software used to create, use and maintain software. The procedures guide the system developer in software project management, software configu