CERN

C Data Acquisition

46

consisting of only a few nodes. It contains already the main building blocks: Dedicated processing nodes, high speed data links, and a distributing switch. The test system will be used to evaluate different switching technologies and to simulate the architecture of a full scale system. It is used also to adapt the offline programs for event reconstruction and triggering which should be used on the farm and to perform benchmark tests for this programs. In the context the implementation of CERN libraries the usage of FORTRAN and the handling of system calls on the embedded system is a main issue.

ABS.133

BR9737184

Experience on using Databases in the Aleph Data Acquisition and Control System P. MATO (CERN) O.Carmona, M. Frank, J. Harvey, B. Jost, D.Michaud, W. Tejessy (CERN), A. Pacheco (Barcelona), 0. Callot, I. Videau (Orsay), D. Botterill (Rutherford)

the VME database, which describes the readout configuration, the trigger and slow control databases, as well as databases describing software components, such as the histogram database. We have estimated that at least 50effort for the Aleph DAQ system was put into development of these databases. In this paper we are going to describe the problems we have encountered with the current system not too much on the conceptual design but mainly on the implementation. Some of these problems arise from the duplication of information in different databases, the direct coupling of some application code to the data, the difficulty of developing applications which need to navigate through several databases, etc. In addition, each database originally had its own application program interface (API) and utility tools, such as an editor, which were developed independently and require substantial maintenance effort. We have recently developed a new database management tool (DBTool) which was designed to overcome the problems listed above. This new tool, which will be briefly described in the paper, allows to have a very simple and unique API (with C, Fortran and C++ interfaces) for each database in each domain and it also allows easily to make associations of objects in different domains, thus avoiding duplication. The data model of DBTool is object-oriented, it incorporates bidirectional associations, aggregation, inheritance among others. We believe that the experience we have acquired during the years of running a large DAQ system at LEP can clearly be useful for next generation of experiments. It is clear that the read-out technology used in LEP experiments is not adequated for LHC experiments. However some of the practical lessons we have learned concerning system configuration and management are certainly relevant.

The data acquisition and control system for the Aleph experiment has been running successfully during the last 5 years and needs to be maintained for another 5 years. Just to maintain such a system as it is is a challenge in itself, especially taking into account the reduced manpower available. We believe the only way we can survive is by re-engineering parts of the system to simplify and standardize as much as possible. For example, during the last year we undertook a major hardware upgrade by replacing 4 different types of in-house developed Fastbus processors by a unique commercial VME processor. More recently we ABS.127 BR9737185 have also made efforts to improve the tools and packages we use to manage our on-line databases and we are now seeing large benefits in the maintenance of our Status of the ZEUS Expert System ZEX system and configuration management software. U. BEHRENS (DESY) The DAQ system management and configuration software relies heavily on the use of databases to hold descriptions of the detector, the readout, the trigger, Mariusz Flasinski (Jagellonian U.), L. Hagge (DESY-ZEUS), J. control and data monitoring systems. It is important that the contents of Jurek (Jagellonian U.), K. Ohrenberg (DESY-ZEUS) these databases are described in a complete and consistent way and without redundancy. Using these databases makes our DAQ system completely "data A. Description of ZEX driven", therefore changes in the configuration don't require any program to The ZEUS detector is controlled and read out by a highly parallel distributed be re-compiled or re-linked. We have currently about 25 databases, each one online system. An expert system helps to increase both efficiency and reli- ability specialized on a given domain of the on-line system. Examples of these databases of experiment operation while reducing the required efforts and expertise of the include the Fastbus database, containing descriptions of the front-end electronics, shift crew. The task of the expert system is to detect anomalous behavior in any

C.3 Online Monitoring part of the experiment, to trace errors to their origin, and to recover or help to recover the system as quick as possible. ZEX is based on the commercial expert system shell RTworks. The large number of human experts in the ZEUS environment requires the knowledge to be stored in an intuitive way, and extending the knowledge base has to be possible without expert system experts. A rule based system was considered to be the only appropriate way of knowledge storing. Experience of this way of keeping the knowledge of human experts available will be discussed. ZEX is put on top of existing systems, and the layered structure of ZEX reflects the structure of the online system: - a slow control sub-expert-system monitors the basic hardware of the experiment. It surveys the states of power supplies, racks, crates, photomultipliers, temperature and radiation sensors, cooling, etc. Based on this information, it decides if efficient data taking is possible, and proposes what to do to regain an acceptable state. - a data quality sub-expertsystem tries to ensure a high quality of the data written to tape. It monitors the beam quality and background rates, and it checks the data from the major components for miscalibration, dead channels, etc. - a data flow sub-expertsystem surveys the data taking. It monitors the central components of the data acquisition system (ie front-end systems, trigger stages, data storage task) for data rates, deadtime, response times etc. - at the top level, ZEX is combining the information about the subsystems to an overall system understanding. For the 1995 data taking period, ZEX is tuned to speed up the procedure of expanding and modifying the knowledge of the system, thus enabling fast reactions to changes in the run conditions, and preparing ZEX to handle shortterm conditions in the ZEUS environment (eg crate failures). B. Impact on future experiments In a fast-changing environment like a HEP experiment, where experts are not always available at the location of the experiment and are frequently changing their positions, an expert system provides a central knowledge repository, which makes information available to anybody whenever (maybe also wherever) it is needed. Parts of the experiment operation (eg data acquisition operation, readout configuration etc) can even be automated with an ES. A mandatory condition for successful operation is the availability of monitoring information from and access to the different detector parts, their readout and the trigger system. It is thus beneficial to incorporate an expert system already at very early stages into the experiment design (protocols, network layout etc). Knowledge engineering and artificial intelligence are branches of computer science which are mostly alien to high-energy physicists. It should thus be considered to involve computer scientists into the design and development of expert systems in HEP.

47

ABS-126

BR9737186

OO-CHSM: Integrating C + + and Statecharts F. RICCARDI (CERN) A. Guerriero(CERN) Statecharts are a very powerful language for specifying system's behaviour as a set of Concurrent Hierarchical Finite State Machines. They have recently become very popular, and have become an integral part of the most popular 0 0 Analisys and Design methodologies (Booch, Rambough, Harel, ...) Neverthanless, tools for implementing them are extremely scarce, and the programmer is left alone with the burden of their implementation. We describe an implementation of the Statechart language that has been integrated in the C++ language, supporting Clusters (states in exclusiveor relationship), Sets (states in a and relationship), Events (triggering state transitions), Actions (executed by the scheduling of Events), and Conditions (to guard the execution of Actions). The 0 0 features of C++ have been preserved in the Statecharts, as one can derive a machine from a plain C++ object, or from another machine, orthogonally incrementing its state and behaviour, in conformity with the views of the most appreciated methodologies. This language system has been used for the implementation of the upgraded Run Control system and Event Builder of the CHORUS experiment at CERN, with great benefits in terms of code maintenability and reliability.

III! Ill

ABS-125

111"

• • • • • «"•

•—-•

BR9737187 Advanced Operating System Technologies F. RICCARDI (CERN) S. Cittolin, S.Vascotto (CERN)

In this paper we describe an R&D effort to define an OS architecture suitable for the requirements of the Data Acquisition and Control of an LHC experiment. Large distributed computing systems are foreseen to be the core part of the DAQ and Control system of the future LHC experiments. Neworks of thousands