TUDPP —  Control System Infrastructure 1   (08-Oct-19   16:30—17:30)
Chair: S. Perez, CEA, Arpajon, France
Paper Title Page
TUDPP01 A Monitoring System for the New ALICE O2 Farm -1
 
  • G. Vino, D. Elia
    INFN-Bari, Bari, Italy
  • V. Chibante Barroso, A. Wegrzynek
    CERN, Meyrin, Switzerland
 
  The ALICE Experiment has been designed to study the physics of strongly interacting matter with heavy-ion collisions at the CERN LHC. A major upgrade of the detector and computing model (O2, Offline-Online) is currently ongoing. The ALICE O2 farm will consist of almost 1000 nodes enabled to readout and process on-the-fly about 27 Tb/s of raw data. To increase the efficiency of computing farm operations a general-purpose near real-time monitoring system has been developed: it lays on features like high-performance, high-availability, modularity, and open source. The core component (Apache Kafka) ensures high throughput, data pipelines, and fault-tolerant services. Additional monitoring functionality is based on Telegraf as metric collector, Apache Spark for complex aggregation, InfluxDB as time-series database, and Grafana as visualization tool. A logging service based on Elasticsearch stack is also included. The designed system handles metrics coming from operating system, network, custom hardware, and in-house software. A prototype version is currently running at CERN and has been also successfully deployed by the ReCaS Datacenter at INFN Bari for both monitoring and logging.  
slides icon Slides TUDPP01 [1.133 MB]  
 
TUDPP02 Data Acquisition System for the APS Upgrade -1
 
  • S. Veseli, N.D. Arnold, T.G. Berenc, J. Carwardine, G. Decker, T. Fors, T.J. Madden, G. Shen, S.E. Shoaf
    ANL, Lemont, Illinois, USA
 
  Funding: Argonne National Laboratory’s work was supported by the U.S. Department of Energy, Office of Science, Office of Basic Energy Sciences, under contract DE-AC02-06CH11357
APS Upgrade multi-bend achromat accelerator (MBA) uses state-of-the-art embedded controllers coupled to various technical subsystems. These controllers have the capability to collect large amounts of fast data for statistics, diagnostics, or fault recording. At times, continuous real-time acquisition of this data is preferred, which presents a number of challenges that must be considered early on in the design; such as network architecture, data management and storage, real-time processing, and impact on normal operations. The design goal is selectable acquisition of turn-by-turn BPM data, together with additional fast diagnostics data. In this paper we discuss engineering specifications and the design of the MBA Data Acquisition System (DAQ). This system will interface with several technical subsystems to provide time-correlated and synchronously sampled data acquisition for commissioning, troubleshooting, performance monitoring and fault detection. Since most of these subsystems will be new designs for the MBA, defining the functionality and interfaces to the DAQ early in the development will ensure the necessary components are included in a consistent and systematic way.
 
slides icon Slides TUDPP02 [13.919 MB]  
 
TUDPP03 Improvement of EPICS Software Deployment at NSLS-II -1
 
  • A.A. Derbenev
    BNL, Upton, New York, USA
 
  The NSLS-II Control System has workstations and servers standardized to the usage of Debian OS. With exceptions like RTEMS and Windows systems where software is built and delivered by hand, all hosts have EPICS software installed from an internally-hosted and externally-mirrored Debian package repository. Configured by Puppet, machines have a similar environment with EPICS base, modules, libraries, and binaries. The repository is populated from epicsdeb, a community organization on GitHub. Currently, packages are available for Debian 8 and 9 with legacy support being provided for Debian 6 and 7. Since packaging creates overhead on how quickly software updates can be available, keeping production systems on track with development is a challenging task. Software is often customized and built manually to get recent features, e.g. for AreaDetector. Another challenge is services like GPFS which underperform or do not work on Debian. Proposed improvements target keeping the production environment up to date. A detachment from the host OS is achieved by using containers, such a Docker, to provide software images. A CI/CD pipeline is created to build and distribute software updates.  
slides icon Slides TUDPP03 [0.715 MB]  
 
TUDPP04 Data Acquisition and Virtualisation of the CLARA Controls System -1
 
  • R.F. Clarke, G. Cox, M.D. Hancock, S. Kinder, N. Knowles, B.G. Martlew, A. Oates, P.H. Owens, W. Smith, J.T.G. Wilson
    STFC/DL, Daresbury, Warrington, Cheshire, United Kingdom
  • S. Kinder
    DSoFt Solutions Ltd, Warrington, United Kingdom
 
  The CLARA experiment at the STFC, Daresbury laboratory has just completed its first successful exploitation period. The CLARA controls system is being rapidly deployed as CLARA enters its next development phase and our current infrastructure is becoming hard to maintain. Virtualization of the server infrastructure will allow the rapid deployment, recovery and testing of systems infrastructure. This talk will review our experience of migrating several key services and IOCs to a virtualized environment. KVM and LXD have been evaluated against our current system and Ansible has been used to automate many tasks that were normally done by hand. The Archiver Appliance is being exploited beyond its original deployment and is a critical component of several analysis tool-chains. Virtualization allows development, maintenance and deployment of the archiver without disrupting its users. Virtualization is also used to manage the CLARA Virtual Accelerator. The Virtual Accelerator can now run with many instances proving useful for scientists. Originally, it was limited to one instance per server.  
slides icon Slides TUDPP04 [0.950 MB]