Paper | Title | Page |
---|---|---|
MO2BCO01 | Driving Behavioural Change of Software Developers in a Global Organisation Assisted by a Paranoid Android | 25 |
|
||
Ensuring code quality standards at the Square Kilometre Array Observatory (SKAO) is of utmost importance, as the project spans multiple nations and encompasses a wide range of software products delivered by developers from around the world. To improve code quality and meet certain open-source software prerequisites for a wider collaboration, the SKAO employs the use of a chatbot that provides witty, direct and qualified comments with detailed documentation that guide developers in improving their coding practices. The bot is modelled after a famous character albeit a depressed one, creating a relatable personality for developers. This has resulted in an increase in code quality and faster turnaround times. The bot has not only helped developers adhere to code standards but also fostered a culture of continuous improvement with an engaging and enjoyable process. Here we present the success story of the bot and how a chatbot can drive behavioural change within a global organisation and help DevOps teams to improve developer performance and agility through an innovative and engaging approach to code reviews. | ||
![]() |
Slides MO2BCO01 [8.171 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO01 | |
About • | Received ※ 06 October 2023 — Revised ※ 07 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 19 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO02 | Concept and Design of an Extensible Middle-Layer Application Framework for Accelerator Operations and Development | 30 |
|
||
Data collection and analysis are becoming increasingly vital not only for the experiments conducted with particle accelerators but also for their operation, maintenance, and development. Due to lack of feasible alternatives, experts regularly resort to writing task-specific scripts to perform actions such as (event triggered or temporary) data collection, system failure detection and recovery, and even simple high-level feedbacks. Often, these scripts are not shared and are deemed to have little reuse value, giving them a short lifetime and causing redundant work. We report on a modular Python framework for constructing middle-layer applications from a library of parameterized functionality blocks (modules) by writing a simple configuration file in a human-oriented format. This encourages the creation of maintainable and reusable modules while offering an increasingly powerful and flexible platform that has few requirements to the user. A core engine instantiates the modules according to the configuration file, collects the required data from the control system and distributes it to the individual module instances for processing. Additionally, a publisher-subscriber messaging system is provided for inter-module communication. We discuss architecture & design choices, current state and future goals of the framework as well as real use-case examples from the European XFEL. | ||
![]() |
Slides MO2BCO02 [1.915 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO02 | |
About • | Received ※ 05 October 2023 — Revised ※ 07 October 2023 — Accepted ※ 13 October 2023 — Issued ※ 30 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO03 | Strategy and Tools to Test Software in the SKA Project: The CSP. LMC Case | 34 |
|
||
The Square Kilometre Array (SKA) Telescope will be one of the largest and most complex scientific instruments ever built. The development of a reliable software for monitoring and controlling its operations is critical to the success of the entire SKA project. The Local Monitoring and Control of the Central Signal Processor (CSP. LMC) is a software responsible for controlling a key subsystem of the telescope, i.e. the Central Signal Processor (CSP). The software is implemented as a "device" within the TANGO framework, written in Python. In this paper we describe a testing strategy that addresses some typical problems of such a large and complex instrument. It is a multi-level strategy, based on a combination of automated tests (unit/component/integration), in the context of CI/CD practices. Software is also tested against errors and anomalous conditions that can occur while the CSP. LMC is interacting with external subsystems, which can be simulated. The paper also discusses needs and solutions based on data mining test results. This allows us to obtain statistics of unexpected failures and to investigate their causes. Furthermore, a database containing test results supports discovery of interesting and unexpected patterns of behaviors of the tests based on correlations about different test-related events and data. This helps us to develop a deeper understanding of the code’s functioning and to find suitable solutions to minimize unexpected behaviors. In addition it can be used also to support reliability testing. | ||
![]() |
Slides MO2BCO03 [2.336 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO03 | |
About • | Received ※ 06 October 2023 — Revised ※ 08 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 13 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO04 | Applying Standardised Software Architectural Concepts to Design Robust and Adaptable PLC Solutions | 40 |
|
||
Between evolving requirements, additional feature requests and urgent maintenance tasks, the Programmable Logic Controllers (PLC) at the European X-Ray Free Electron Laser Facility (EuXFEL) have become subjected to an array of demands. As the maintainability effort towards the existing systems peak, the requirement for a sustainable solution become an ever pressing concern. Ultimately, in order to provide a PLC code base which can easily be supported and adapted to, a reworking was required from the ground up in the form of a new suite of libraries and tools. Through this, it was possible to bring standardised software principals into PLC design and development, conjunctively offering an interface into the existing code base for ongoing support of legacy code. The set of libraries are developed by incorporating software engineering principles and design patterns in test driven development within a layered architecture. In defining clear interfaces across all the architectural layers - from hardware, to the software representation of hardware, and clusters of software devices, the complexity of PLC development decreases down into modular blocks of unit tested code. Regular tasks such as the addition of features, modifications or process control can easily be performed due to the adaptability, flexibility and modularity of the core PLC code base. | ||
![]() |
Slides MO2BCO04 [0.910 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO04 | |
About • | Received ※ 05 October 2023 — Revised ※ 08 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 09 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO05 | Enabling Transformational Science Through Global Collaboration and Innovation Using the Scaled Agile Framework | 47 |
|
||
Funding: Square Kilometre Array Observatory The SKAO is one observatory, with two telescopes on three continents. It will be the world’s largest radio telescope once constructed, and will be able to observe the sky with unprecedented sensitivity and resolution. The SKAO software and computing systems will largely be responsible for orchestrating the observatory and associated telescopes, and processing the science data, before data products are distributed to regional science centres. The Scaled Agile Framework (SAFe) is being leveraged to coordinate over thirty lean agile development teams that are distributed throughout the world. In this paper, we report on our experience in using the Scaled Agile Framework, the successes we have enjoyed, as well as the impediments and challenges that have stood in our way. |
||
![]() |
Slides MO2BCO05 [6.064 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO05 | |
About • | Received ※ 06 October 2023 — Revised ※ 08 October 2023 — Accepted ※ 12 October 2023 — Issued ※ 15 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO06 | Embedded Controller Software Development Best Practices at the National Ignition Facility | 54 |
|
||
Funding: This work was performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344. Software development practices such as continuous integration and continuous delivery (CI/CD) are widely adopted by the National Ignition Facility (NIF) which helps to automate the software development, build, test, and deployment processes. However, using CI/CD in an embedded controller project poses several challenges due to the limited computing resources such as processing power, memory capacity and storage availability in such systems. This paper will present how CI/CD best practices were tailored and used to develop and deploy software for one of the NIF Master Oscillator Room (MOR) embedded controllers, which is based on custom designed hardware consisting of a microcontroller and a variety of laser sensors and drivers. The approach included the use of automated testing frameworks, customized build scripts, simulation environments, and an optimized build and deployment pipeline, leading to quicker release cycles, improved quality assurance and quicker defect correction. The paper will also detail the challenges faced during the development and deployment phases and the strategies used to overcome them. The experience gained with this methodology on a pilot project demonstrated that using CI/CD in embedded controller projects can be challenging, yet feasible with the right tools and strategies, and has the potential to be scaled and applied to the vast number of embedded controllers in the NIF control system. LLNL Release Number: LLNL-ABS-848418 |
||
![]() |
Slides MO2BCO06 [1.346 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO06 | |
About • | Received ※ 29 September 2023 — Revised ※ 12 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 30 November 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO2BCO07 | Continuous Integration and Debian Packaging for Rapidly Evolving Software | 61 |
|
||
We describe our Jenkins-based continuous integration system and Debian packaging methods, and their application to the rapid development of the ChimeraTK framework. ChimeraTK is a C++ framework for control system applications and hardware access with a high level of abstraction and consists of more than 30 constantly changing interdependent libraries. Each component has its own release cycle for rapid development, yet API and ABI changes must be propagated to prevent problems in dependent libraries and over 60 applications. We present how we configured a Jenkins-based continuous integration system to detect problems quickly and systematically for the rapid development of ChimeraTK. The Debian packaging system is designed to ensure the compatibility of binary interfaces (ABI) and of development files (API). We present our approach using build scripts that allow the deployment of rapidly changing libraries and their dependent applications as Debian packages. These even permit applications to load runtime plugins that draw from the same core library, yet are compiled independently. | ||
![]() |
Slides MO2BCO07 [0.805 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO2BCO07 | |
About • | Received ※ 06 October 2023 — Accepted ※ 13 October 2023 — Issued ※ 26 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO01 | Using BDD Testing in SKAO: Challenges and Opportunities | 183 |
|
||
Defining what a system should do is one of the hardest parts of system design. Using Behaviour Driven Design (BDD) techniques can help, and also help define the tests needed to check that the desired behaviour is implemented. We describe the challenges and opportunities that arise when adopting these techniques, including both technical and social issues, and especially why in our case BDD techniques provide significant value. We present our pathway towards using BDD and the lessons learned. By trying to use BDD testing to run integration tests, it enabled the identification of gaps in the testing infrastructure, particularly the TANGO testing infrastructure, and gaps in developers’ understanding of the system design. This allowed SKAO to take steps to improve the tests, the infrastructure, and the design, by integrating BDD techniques into the full product development lifecycle and using them also for monitoring the development process and the quality of software products. | ||
![]() |
Slides MO4BCO01 [1.496 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO4BCO01 | |
About • | Received ※ 06 October 2023 — Revised ※ 10 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 09 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO02 | Lessons from Using Python GraphQL Libraries to Develop an EPICS PV Server for Web UIs | 191 |
|
||
Diamond Light Source is currently developing a web-based EPICS control system User Interface (UI). This will replace the use of EDM and the Eclipse-based CS-Studio at Diamond, and it will integrate with future Acquisition and Analysis software. For interoperability, it will use the Phoebus BOB file format. The architecture consists of a back-end application using EPICS Python libraries to obtain PV data and the query language GraphQL to serve these data to a React-based front end. A prototype was made in 2021, and we are now doing further development from the prototype to meet the first use cases. Our current work focuses on the back-end application, Coniql, and for the query interface we have selected the Strawberry GraphQL implementation from the many GraphQL libraries available. We discuss the reasons for this decision, highlight the issues that arose with GraphQL, and outline our solutions. We also demonstrate how well these libraries perform within the context of the EPICS web UI requirements using a set of performance metrics. Finally, we provide a summary of our development plans. | ||
![]() |
Slides MO4BCO02 [4.243 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO4BCO02 | |
About • | Received ※ 29 September 2023 — Accepted ※ 13 October 2023 — Issued ※ 20 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO03 | Protecting Your Controls Infrastructure Supply Chain | 196 |
|
||
Supply chain attacks have been constantly increasing since being first documented in 2013. Profitable and relatively simple to put in place for a potential attacker, they compromise organizations at the core of their operation. The number of high profile supply chain attacks has more than quadrupled in the last four years and the trend is expected to continue unless countermeasures are widely adopted. In the context of open science, the overwhelming reliance of scientific software development on open-source code, as well as the multiplicity of software technologies employed in large scale deployments make it increasingly difficult for asset owners to assess vulnerabilities threatening their activities. Recently introduced regulations by both the US government (White House executive order EO14028) and the EU commission (E.U. Cyber Resilience Act) mandate that both Service and Equipment suppliers of government contracts provide Software Bills of Materials (SBOM) of their commercial products in a standard and open data format. Such SBOM documents can then be used to automate the discovery, and assess the impact of, known or future vulnerabilities and how to best mitigate them. This paper will explain how CERN investigated the implementation of SBOM management in the context of its accelerator controls infrastructure, which solutions are available on the market today, and how they can be used to gradually enforce secure dependency lifecycle policies for the developer community. | ||
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO4BCO03 | |
About • | Received ※ 02 October 2023 — Revised ※ 10 October 2023 — Accepted ※ 14 November 2023 — Issued ※ 24 November 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO04 | Improving Control System Software Deployment at MAX IV | 201 |
|
||
The control systems of large research facilities like synchrotrons are composed of many different hardware and software parts. Deploying and maintaining such systems require proper workflows and tools. MAX IV has been using Ansible to manage and deploy its full control system, both software and infrastructure, for many years with great success. We detail further improvements: defining Tango devices as configuration, and automated deployment of specific packages when tagging Gitlab repos. We have now adopted Conda as our primary packaging tool instead of the Red Hat Package Manager (RPM). This allows us to keep up with the rapidly changing Python ecosystem, while at the same time decoupling Operating System upgrades from the control system software. For better management, we have developed a Prometheus-based tool that reports on the installed versions of each package on each machine. This paper will describe our workflow and discuss the benefits and drawbacks of our approach. | ||
![]() |
Slides MO4BCO04 [1.969 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO4BCO04 | |
About • | Received ※ 06 October 2023 — Accepted ※ 13 October 2023 — Issued ※ 26 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO05 | Apples to Oranges: A Comparison of EPICS Build and Deployment Systems | 205 |
|
||
ESS currently uses two different systems for managing the build and deployment of EPICS modules. Both of these use modules that are packaged and prepared to be dynamically loaded into soft IOCs, based on the require module developed at PSI. The difference is the deployment: For the accelerator, we use a custom utility to define and build an EPICS environment which is then distributed on a global shared filesystem to the production and lab networks. For the neutron instrumentation side, in contrast, we use conda to build individual EPICS environments for each IOC, where the underlying packages are stored on a shared artifactory server. In each case, the goal is to provide a repeatable and controllable mechanism to produce a consistent EPICS environment for IOCs in use at ESS. The difference (other than the tools and storage) is in some sense philosophical: should a software environment be defined at build-time or at run-time? In this presentation we will provide an overview of some of the challenges, contrasts, and lessons learned from these two different but related approaches to EPICS module deployment. | ||
![]() |
Slides MO4BCO05 [0.819 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-MO4BCO05 | |
About • | Received ※ 06 October 2023 — Accepted ※ 13 October 2023 — Issued ※ 24 October 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
MO4BCO06 |
ATEF, an Automated Test Execution Framework for System Configuration Checkouts | |
|
||
Funding: This work is supported by Department of Energy contract DE-AC02-76SF00515. LCLS is home to nine beamlines with drastically differing capabilities and competencies. These beamlines are comprised of a wide variety of different devices, and are frequently reconfigured to improve these capabilities or fit the current experiment. This varied and rapidly changing environment has made automating system configuration checks a challenging but vital step toward consistently performing high impact research. LCLS has begun development on ATEF (automated test execution framework), which aims to provide a framework for LCLS scientists to perform system configuration checks quickly and reproducibly. Atef offers a suite of tools for performing both active and passive checks built on the Bluesky/Ophyd data collection framework, as well as a Qt-based GUI for constructing and configuring said checks. This talk will outline the development of this tool, along with lessons learned through its initial deployment amongst our beamlines. |
||
![]() |
Slides MO4BCO06 [4.179 MB] | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THMBCMO13 |
TwinCAT BSD Virtual Machines and Ansible Provisioning | |
|
||
Funding: This work is supported by Department of Energy contract DE-AC02-76SF00515. TwinCAT/BSD is a lightweight FreeBSD-based operating system for TwinCAT PLCs that Beckhoff has offered since 2021 as an alternative to Microsoft Windows. These BSD-based PLCs offer the same runtime capabilities as their Windows-based counterparts and also bring the benefits of a Unix-like operating system. With TwinCAT/BSD images provided by Beckhoff, virtual machines are now easy to spin up for prototyping, development, and unit testing without direct access to PLC hardware. Ansible playbooks with some custom additions make provisioning these VMs and real PLCs simple. Automated installation of TwinCAT tools and packages, upgrades of runtime versions, route management, AMS Net ID settings, firewall configuration, and more are now handled with ease when using TwinCAT/BSD with Ansible. |
||
![]() |
Slides THMBCMO13 [1.088 MB] | |
![]() |
Poster THMBCMO13 [1.633 MB] | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THMBCMO14 | Development of the SKA Control System, Progress, and Challenges | 1221 |
|
||
The SKA Project is a science mega-project whose mission is to build an astronomical observatory that comprises two large radio-telescopes: the SKA-Low Telescope, located in the Inyarrimanha Ilgari Bundara, the CSIRO Murchison Radio-astronomy Observatory in Western Australia, with the observing range 50 to 350 MHz, and the SKA Mid Telescope, located in the Karoo Region, South Africa, with the observing range 350 MHz to 15 GHz. The SKA Global Headquarters is in the Jodrell Bank Observatory, near Manchester, UK. When completed, the SKA Telescopes will surpass existing radio-astronomical facilities not only in the scientific criteria such as sensitivity, angular resolution, and survey speed, but also in the number of receptors and the range of the observing and processing modes. The Observatory, and each of the Telescopes, will be delivered in stages, thus supporting incremental development of the collecting area, signal and data processing capacity, and the observing and processing modes. Unlike scientific capability, which, in some cases, may be delivered in the late releases, the control system is required from the very beginning to support integration and verification. Development of the control system to support the first delivery of the Telescopes (Array Assembly 0.5) is well under way. This paper describes the SKA approach to the development of the Telescope Control System, and discusses opportunities and challenges resulting from the distributed development and staged approach to the Telescope construction. | ||
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THMBCMO14 | |
About • | Received ※ 06 October 2023 — Revised ※ 12 October 2023 — Accepted ※ 12 December 2023 — Issued ※ 22 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THMBCMO15 | Conan for Building C++ Tango Devices at SOLEIL | 1227 |
|
||
At SOLEIL, our Tango devices are mainly developed in C++, with around 450 projects for building libraries and device servers for our accelerators and beamlines. We have a software factory that has enabled us to achieve continuous integration of our developments using Maven, which manages project dependencies. However, Maven is uncommon for C++. In addition, it has limitations that hinder us from supporting future platforms and new programming standards, leading us to replace it with Conan. Conan is a dependency and package manager for C and C++ that works on all platforms and integrates with various build systems. Its features are designed to enable modern continuous integration workflows with C++ and are an ideal alternative to Maven for our C++ build system. This transition is essential for the upgrade of SOLEIL (SOLEIL II*), as we continue to develop new devices and update existing systems. We are confident that Conan will improve our development process and benefit our users. This paper will provide an overview of the integration process and describe the progress of deploying the new build system. We will share our insights and lessons learned throughout the transition process.
*SOLEIL II: Towards A Major Transformation of the Facility. Conan - C and C++ Open-Source Package Manager |
||
![]() |
Slides THMBCMO15 [0.824 MB] | |
![]() |
Poster THMBCMO15 [0.867 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THMBCMO15 | |
About • | Received ※ 04 October 2023 — Revised ※ 10 October 2023 — Accepted ※ 13 December 2023 — Issued ※ 16 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THPDP053 | Test Automation for Control Systems at the European Spallation Source | 1435 |
|
||
This paper describes several control system test auto-mation frameworks for the control systems at the Europe-an Spallation Source (ESS), a cutting-edge research facili-ty that generates neutron beams for scientific experi-ments. The control system is a crucial component of ESS, responsible for regulating and monitoring the facility’s complex machinery, including a proton accelerator, target station, and several neutron instruments. The traditional approach to testing control systems largely relies on manual testing, which is time-consuming and error-prone. To enhance the testing process, several different test automation frameworks have been devel-oped for various types of applications. Some of these frameworks are integrated with the ESS control system, enabling automated testing of new software releases and updates, as well as regression testing of existing func-tionality. The paper provides an overview of the various automa-tion frameworks in use at ESS, including their architec-ture, tools, and development techniques. It discusses the benefits of the different frameworks, such as increased testing efficiency, improved software quality, and reduced testing costs. The paper concludes by outlining future development directions. | ||
![]() |
Poster THPDP053 [1.020 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THPDP053 | |
About • | Received ※ 19 September 2023 — Revised ※ 10 October 2023 — Accepted ※ 08 December 2023 — Issued ※ 14 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THPDP059 | Towards Automatic Generation of Fail-Safe PLC Code Compliant with Functional Safety Standards | 1449 |
|
||
In agreement with the IEC 61511 functional safety standard, fail-safe application programs should be written using a Limited Variability Language (LVL), that has a limited number of operations and data types, such as LD (Ladder Diagrams) or FBD (Function Block Diagrams) for safety PLC (Programmable Logic Controller) languages. The specification of safety instrumented systems, as part of the Safety Requirements Specification document, shall unambiguously define the logic of the program, creating a one-to-one relationship between code and specification. Hence, coding becomes a translation from a specification language to PLC code. This process is repetitive and error-prone when performed by a human. In this paper we describe the process of fully generating Siemens TIA portal LD programs for safety applications from a formal specification. The process starts by generating an intermediate model that represents a generic LD program based on a predefined meta-model. This intermediate model is then automatically translated into code. The idea can be expanded to other equivalent LVL languages from other PLC manufacturers. In addition, the intermediate model can be generated from different specification formalisms having the same level of expressiveness as the one presented in this paper: a Cause-Effect Matrix. Our medium-term vision is to automatically generate fail-safe programs from diverse formal specification methods and using different LVLs. | ||
![]() |
Poster THPDP059 [1.935 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THPDP059 | |
About • | Received ※ 03 October 2023 — Revised ※ 26 October 2023 — Accepted ※ 08 December 2023 — Issued ※ 09 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THPDP064 | Selecting a Linux Operating System for CERN Accelerator Controls | 1475 |
|
||
Changing the operating system (OS) for large heterogeneous infrastructures in the research domain is complex. It requires great effort to prepare, migrate and validate the common generic components, followed by the specific corner cases. The trigger to change OS mainly comes from Industry and is based on multiple factors, such as OS end-of-life and the associated lack of security updates, as well as hardware end-of-life and incompatibilities between new hardware and old OS. At the time of writing, the CERN Accelerator Controls computing infrastructure consists of ~4000 heterogeneous systems (servers, consoles and front-ends) running CentOS 7. The effort to move to CentOS 7 was launched in 2014 and deployed operationally 2 years later. In 2022, a project was launched to select and prepare the next Linux OS for Controls servers and consoles. This paper describes the strategy behind the OS choice, and the challenges to be overcome in order to switch to it within the next 2 years, whilst respecting the operational accelerator schedule and factoring in the global hardware procurement delays. Details will be provided on the technical solutions implemented by the System Administration team to facilitate this process. In parallel, whilst embarking on moving away from running Controls services on dedicated bare metal platforms towards containerization and orchestration, an open question is whether the OS of choice, RHEL9, is the most suitable for the near future and if not what are the alternatives? | ||
![]() |
Poster THPDP064 [9.129 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THPDP064 | |
About • | Received ※ 07 October 2023 — Revised ※ 27 October 2023 — Accepted ※ 02 December 2023 — Issued ※ 11 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |
THPDP065 | Unified Software Production Process for CERN Cryogenic Control Applications | 1480 |
|
||
The software engineering of process control system for CERN cryogenic installations is based on an automatic code production methodology and continuous integration practice. This solution was initially developed for the LHC Accelerator applications, then adapted to LHC Detectors, test facilities and non-LHC cryogenic facilities. Over the years, this approach allowed the successful implementation of many control system upgrades, as well as the development of new applications while improving quality assurance and minimizing manpower resources. The overall complexity of automatic software production chains, their challenging maintenance, deviation between software production methods for different cryogenic domains and frequent evolution of CERN frameworks led to the system’s complete review. A new unified software production system was designed for all cryogenic domains and industrial technologies used. All previously employed frameworks, tools, libraries, code templates were classified, homogenized and implemented as common submodules, while projects specific configuration were grouped in custom application files. This publication presents the new unified software production solution, benefits from shared methodology between different cryogenics domains, as well as a summary of two years of experience with several cryogenic applications from different PLCs technologies. | ||
![]() |
Poster THPDP065 [0.531 MB] | |
DOI • | reference for this paper ※ doi:10.18429/JACoW-ICALEPCS2023-THPDP065 | |
About • | Received ※ 04 October 2023 — Revised ※ 25 October 2023 — Accepted ※ 12 December 2023 — Issued ※ 21 December 2023 | |
Cite • | reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml) | |