Zastosowanie języka XVCL do budowy repozytorium diagramów klas

The paper describes the idea of class diagram evolution management with  attribute-driven versioning and XVCL language – the XML dialect for variant description and generative programming. The proposed repository is designed as a three layer hierarchy of XVCL frames. This universal structure can also be used to manage changes of other project artifacts.Artykuł opisuje koncepcję zarządzania ewolucją diagramów klas z wykorzystaniem wersjowania opartego na atrybutach języka XCVL – dialektu XML, służącego do zarządzania wariantami i programowania generatywnego. Repozytorium zbudowano jako trójwarstwową hierarchię ramek XVCL, tworzącą dość uniwersalną strukturę, która może również zostać użyta do zarządzania zmiennością innych artefaktów projektowych

The Evolution of the ALICE Detector Control System

The ALICE Detector Control System has provided its service since 2007. Its operation in the past years proved that the initial design of the system fulfilled all expectations and allowed the evolution of the detectors and operational requirements to follow. In order to minimize the impact of the human factor, many procedures have been optimized and new tools have been introduced in order to allow the operator to supervise about 1 000 000 parameters from a single console. In parallel with the preparation for new runs after the LHC shutdown a prototyping for system extensions which shall be ready in 2018 has started. New detectors will require new approaches to their control and configuration. The conditions data, currently collected after each run, will be provided continuously to a farm containing 100 000 CPU cores and tens of PB of storage. In this paper the DCS design, deployed technologies, and experience gained during the 7 years of operation will be described and the initial assumptions with the current setup will be compared. The current status of the developments for the upgraded system, which will be put into operation in less than 3 years from now, will also be described

Service Asset and Configuration Management in ALICE Detector Control System

ALICE (A Large Ion Collider Experiment) is one of the big LHC (Large Hadron Collider) detectors at CERN. It is composed of 19 sub-detectors constructed by different institutes participating in the project. Each of these subsystems has a dedicated control system based on the commercial SCADA package "WinCC Open Architecture" and numerous other software and hardware components delivered by external vendors. The task of the central controls coordination team is to supervise integration, to provide shared services (e.g. database, gas monitoring, safety systems) and to manage the complex infrastructure (including over 1200 network devices and 270 VME and power supply crates) that is used by over 100 developers around the world. Due to the scale of the control system, it is essential to ensure that reliable and accurate information about all the components - required to deliver these services along with relationship between the assets - is properly stored and controlled. In this paper we will present the techniques and tools that were implemented to achieve this goal, together with experience gained from their use and plans for their improvement

Challenges of the ALICE Detector Control System for the LHC RUN3

The ALICE Detector Control System (DCS) has provided its services to the experiment since 10 years. During this period it ensured uninterrupted operation of the experiment and guaranteed stable conditions for the data taking. The DCS has been designed to cope with the detector requirements compatible with the LHC operation during its RUN1 and RUN2 phases. The decision to extend the lifetime of the experiment beyond this horizon requires the redesign of the DCS data flow and represents a major challenge. The major challenges of the system upgrade are presented in this paper.The ALICE Detector Control System (DCS) provides its services to the experiment for 10 years. It ensures uninterrupted operation of the experiment and guarantees stable conditions for the data taking. The decision to extend the lifetime of the experiment requires the redesign of the DCS data flow. The interaction rates of the LHC in ALICE during the RUN3 period will increase by a factor of 100. The detector readout will be upgraded and it will provide 3.4TBytes/s of data, carried by 10 000 optical links to a first level processing farm consisting of 1 500 computer nodes and ~100 000 CPU cores. A compressed volume of 20GByte/s will be transferred to the computing GRID facilities. The detector conditions, consisting of about 100 000 parameters, acquired by the DCS need to be merged with the primary data stream and transmitted to the first level farm every 50ms. This requirement results in an increase of the DCS data publishing rate by a factor of 5000. The new system does not allow for any DCS downtime during the data taking, nor for data retrofitting. Redundancy, proactive monitoring, and improved quality checking must therefore complement the data flow redesign

ADAPOS: An architecture for publishing ALICE DCS conditions data

ALICE Data Point Service (ADAPOS) is a software architecture being developed for the RUN3 period of LHC, as a part of the effort to transmit conditions data from ALICE Detector Control System (DCS) to Event Processing Network (EPN), for distributed processing. The key processes of ADAPOS, Engine and Terminal, run on separate machines, facing different networks. Devices connected to DCS publish their state as DIM services. Engine gets updates to the services, and converts them into a binary stream. Terminal receives it over 0MQ, and maintains an image of the DCS state. It sends copies of the image, at regular intervals, over another 0MQ connection, to a readout process of ALICE Data Acquisition.ALICE Data Point Service (ADAPOS) is a software architecture being developed for the Run 3 period of LHC, as a part of the effort to transmit conditions data from ALICE Detector Control System (DCS) to GRID, for distributed processing. ADAPOS uses Distributed Information Management (DIM), 0MQ, and ALICE Data Point Processing Framework (ADAPRO). DIM and 0MQ are multi-purpose application-level network protocols. DIM and ADAPRO are being developed and maintained at CERN. ADAPRO is a multi-threaded application framework, supporting remote control, and also real-time features, such as thread affinities, records aligned with cache line boundaries, and memory locking. ADAPOS and ADAPRO are written in C++14 using OSS tools, Pthreads, and Linux API. The key processes of ADAPOS, Engine and Terminal, run on separate machines, facing different networks. Devices connected to DCS publish their state as DIM services. Engine gets updates to the services, and converts them into a binary stream. Terminal receives it over 0MQ, and maintains an image of the DCS state. It sends copies of the image, at regular intervals, over another 0MQ connection, to a readout process of ALICE Data Acquisition

Managing operational documentation in the ALICE Detector Control System

ALICE (A Large Ion Collider Experiment) is one of the big LHC (Large Hadron Collider) experiments at CERN in Geneve, Switzerland. The experiment is composed of 18 sub-detectors controlled by an integrated Detector Control System (DCS) that is implemented using the commercial SCADA package PVSSII. The DCS includes over 1200 network devices, over 1,000,000 monitored parameters and numerous custom made software components that are prepared by over 100 developers from all around the world. This complex system is controlled by a single operator via a central user interface. One of his/her main tasks is the recovery of anomalies and errors that may occur during operation. Therefore, clear, complete and easily accessible documentation is essential to guide the shifter through the expert interfaces of different subsystems. This paper describes the idea of the management of the operational documentation in ALICE using a generic repository that is built on a relational database and is integrated with the control system. The experience gained and the conclusions drawn from the project are also presented

How low-cost devices can help on the way to ALICE upgrade

Cheap, ready to install and simple to configure, minicomputer and microcontroller boards have been in use in ALICE for a few years for specific, non-critical tasks, like integrating the environment sensors network in the experimental site, and to monitor and analyse clock signals. These systems have also been installed inside the ALICE experiment, in the presence of magnetic field and radiation, and subjected to a functionality test. While the major part of these devices proved to work correctly even under the experiment conditions, finally some weaknesses were revealed, thus excluding this class of devices from usage in the production setup. They have also played a role in the realization of scaled systems for the ALICE upgrade. With them, we have been able to simulate the presence of Front-End cards which are not yet available, allowing to proceed in the development of the software framework, of libraries and interfaces, in parallel with the production and validation of the hardware components. Being off-the-shelf and available everywhere in the world, they can be installed in remote institutes and laboratories participating to the collaboration. Some of the systems have been realised by students and trainees hosted at CERN for short periods of time. As well as being cheap and easy to procure, they proved to be a great didactic tool, allowing young collaborators to realise a complete system from scratch, integrate into a complex infrastructure and get a hands-on approach to modern control systems.The ambitious upgrade plan of the ALICE experiment expects a complete redesign of its data flow after the LHC shutdown scheduled for 2019, for which new electronics modules are being developed in the collaborating institutes. Access to prototypes is at present very limited and full scale prototypes are expected only close to the installation date. To overcome the lack of realistic HW, the ALICE DCS team built small-scale prototypes based on low-cost commercial components (Arduino, Raspberry PI), equipped with environmental sensors, and installed in the experiment areas around and inside the ALICE detector. Communication and control software was developed, based on the architecture proposed for the future detectors, including CERN JCOP FW and ETM WINCC OA. Data provided by the prototypes has been recorded for several months, in presence of beam and magnetic field. The challenge of the harsh environment revealed some insurmountable weaknesses, thus excluding this class of devices from usage in a production setup. They did prove, however, to be robust enough for test purposes, and are still a realistic test-bed for developers while the production of final electronics is continuing

ALICE Monitoring in 3-D

The ALICE experiment is a complex hardware and software device, monitored and operated with a control system based on WinCC OA. ALICE is composed of 19 detectors and installed in a cavern along the LHC at CERN; each detector is a set of modular elements, assembled in a hierarchical model called Finite State Machine. A 3-D model of the ALICE detector has been realized, where all elements of the FSM are represented in their relative location, giving an immediate overview of the status of the detector. For its simplicity, it can be a useful tool for the training of operators. The development is done using WinCC OA integrated with the JCOP fw3DViewer, based on the AliRoot geometry settings. Extraction and conversion of geometry data from AliRoot requires the usage of conversion libraries, which are currently being implemented. A preliminary version of ALICE 3-D is now deployed on the operator panel in the ALICE Run Control Centre. In the next future, the 3-D panel will be available on a big touch screen in the ALICE Visits Centre, providing visitors with the unique experience of navigating the experiment from both inside and out

Protecting Detectors in ALICE

ALICE (A Large Ion Collider Experiment) is one of the big LHC (Large Hadron Collider) experiments at CERN in Geneva. It is composed of many sophisticated and complex detectors mounted very compactly around the beam pipe. Each detector is a unique masterpiece of design, engineering and construction and any damage to it could stop the experiment for months or even for years. It is therefore essential that the detectors are protected from any danger and this is one very important role of the Detector Control System (DCS). One of the main dangers for the detectors is the particle beam itself. Since the detectors are designed to be extremely sensitive to particles they are also vulnerable to any excess of beam conditions provided by the LHC accelerator. The beam protection consists of a combination of hardware interlocks and control software and this paper will describe how this is implemented and handled in ALICE. Tools have also been developed to support operators and shift leaders in the decision making related to beam safety. The gained experiences and conclusions from the individual safety projects are also presented