ICALEPCS2023 - Table of Session: MO4BC (Software Best Practises)

Paper	Title	Page
MO4BCO01	Using BDD Testing in SKAO: Challenges and Opportunities	183
	V.L. Allan University of Cambridge, Cambridge, United Kingdom G. Brajnik IDS, Udine, Italy L.R. Brederode SKAO, Macclesfield, United Kingdom
	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
	R.J. Auger-Williams OSL, St Ives, Cambridgeshire, United Kingdom A.L. Alexander, T.M. Cobb, M.J. Gaughran, A.J. Rose, A.W.R. Wells, A.A. Wilson DLS, Oxfordshire, United Kingdom
	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
	B. Copy, F. Ehm, P.J. Elson, S.T. Page, J.-B. de Martel CERN, Meyrin, Switzerland M. Pratoussy CPE Lyon, Villeurbanne, France L. Van Mol Birmingham University, Birmingham, United Kingdom
	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
	B. Bertrand, A. Freitaspresenter, A.F. Joubert MAX IV Laboratory, Lund University, Lund, Sweden J.T. Kowalczyk S2Innovation, Kraków, Poland
	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
	S.C.F. Rose, D.H.C. Araujo, L.A. Mello Magalhães, A.L. Olsson ESS, Lund, Sweden
	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
	R.S. Tang-Kong, K.R. Lauer SLAC, Menlo Park, California, USA
	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)

Paper

Title

Page

Using BDD Testing in SKAO: Challenges and Opportunities

183

V.L. Allan
University of Cambridge, Cambridge, United Kingdom
G. Brajnik
IDS, Udine, Italy
L.R. Brederode
SKAO, Macclesfield, United Kingdom

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

R.J. Auger-Williams
OSL, St Ives, Cambridgeshire, United Kingdom
A.L. Alexander, T.M. Cobb, M.J. Gaughran, A.J. Rose, A.W.R. Wells, A.A. Wilson
DLS, Oxfordshire, United Kingdom

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

B. Copy, F. Ehm, P.J. Elson, S.T. Page, J.-B. de Martel
CERN, Meyrin, Switzerland
M. Pratoussy
CPE Lyon, Villeurbanne, France
L. Van Mol
Birmingham University, Birmingham, United Kingdom

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

B. Bertrand, A. Freitaspresenter, A.F. Joubert
MAX IV Laboratory, Lund University, Lund, Sweden
J.T. Kowalczyk
S2Innovation, Kraków, Poland

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

S.C.F. Rose, D.H.C. Araujo, L.A. Mello Magalhães, A.L. Olsson
ESS, Lund, Sweden

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

R.S. Tang-Kong, K.R. Lauer
SLAC, Menlo Park, California, USA

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)