Bridging the Gap Between AI tools and Particle Accelerators
Bridging the Gap Between AI tools and Particle Accelerators
26. August 2026
min read
Accelerators
Project
The gap separating research-grade AI tools and particle accelerators today
In this blog, we summarise the architecture behind our new paper published in Springer Nature EPJ Research Infrastructures 10, 18 (2026), and what it means for facilities exploring AI copilots and autonomous control. A persistent gap separates research-grade AI tools from the operational environments of real accelerator machines.
Accelerator control systems are built on mature frameworks, such as EPICS (Experimental Physics and Industrial Control System) and TANGO, or some variation of industrial SCADA (Supervisory Control and Data Acquisition), layered over decades of operational experience, established safety procedures, and legacy hardware. The deployment of an AI model in this environment requires systematic attention to real-time constraints, safety-interlock compatibility, operator trust, and long-term maintainability.
The Helmholtz-Zentrum Dresden-Rossendorf (HZDR) is investigating control system candidates for the Dresden Advanced Light Infrastructure (DALI), motivated in part by the observation that the control system of the ELBE Center for High-Power Radiation Sources “lacks openness and interfaces for modern scientific tools like machine learning and artificial intelligence”.
Laboratories choose their framework based on specific operational requirements, thus creating a diversity that reflects the diverse, innovation-driven nature of scientific facilities. It does, however, mean that there is no standardised interface through which software external to the control system can connect to it.
The absence of such an interface makes testing new tools on operational accelerators in realistic scenarios significantly harder and constrains adoption. This directly affects the mission of ARTIFACT (ARTificial Intelligence For Accelerators, user Communities and associated Technologies), which aims to deliver standardised, state-of-the-art tools that integrate into a broad range of particle accelerators with minimal change on the facility side.
Within the ARTIFACT network, Cosylab’s main contribution lies in the software integration layer: developing reusable connectors, a unified abstraction layer, and integration guidance that link AI-ready services to facility control systems and data archivers without requiring modifications to operational infrastructure.
Particle Accelerators’ Distributed Control System
Controlling a particle accelerator is a unique challenge for multiple reasons:
- The sheer number and variety of components to integrate
- The physical scale, from hundreds of metres to several kilometres
- The constant, concurrent programme of experiments, upgrades, and optimisations
To reduce complexity and maintenance burden, it makes sense for the same type of graphical user interface (GUI) to serve every aspect of the accelerator, where all devices are exposed to the control system through a common protocol.
All challenges put together make centralised architecture impractical. Instead, accelerator control systems are built on a distributed architecture: EPICS is one of the most widely deployed examples of this architecture and serves as the primary reference for the article.
EPICS in a nutshell
The Input/Output Controller (IOC), the fundamental building block of EPICS, is a software process, typically running on a dedicated front-end computer or embedded system, that interfaces to hardware through device-specific drivers and exposes the hardware state as a collection of named Process Variables (PVs).
A PV represents a single scalar or waveform quantity, such as a magnet current setpoint, together with associated metadata (e.g., engineering units). The IOC evaluates records and inter-PV logic and updates PV values accordingly.
Clients access PVs over the network using the Channel Access (CA) protocol, the original EPICS network layer¹. CA implements a publish-subscribe model: a client subscribes to a PV by name, and the IOC hosting that PV delivers an initial value and subsequent updates whenever the value changes beyond a configurable threshold.
Network discovery relies on UDP broadcast or a configurable name server, so no central data broker is required. The more recent PVAccess protocol, introduced with EPICS 7, extends this model to support structured data types and addresses throughput limitations of CA encountered with modern high-rate diagnostics and AI applications² (Fig. 1).
A client using Channel Access or PVAccess can connect to any PV on the network, read its value and alarm state, and write a new setpoint. This integration point is where AI services must connect.
Fig. 1 Overview of the EPICS architecture, with middle layer (core) working as a “Babel fish”, translating all different protocols and interfaces to a unified language, the PVAccess protocol.
Challenges of Integrating AI and ML into Operational Control Systems
The gap between a working AI/ML prototype and a deployable operational tool is primarily not one of model performance. It arises instead from practical constraints that are largely absent in research settings but unavoidable in operational Accelerator Control Systems (Fig. 2).
Fig. 2 Control systems serve as a hub that connects operators and scientists controlling the experiments, historical data stored in databases, ML and AI models, and high-performance computing clusters where models are trained to the accelerator. They translate different protocols and data structures, curate data flows and prevent unauthorised access and modifications.
The five recurring categories of challenges are:
- Data Access and Quality: Training ML models on accelerator behaviour requires substantial volumes of historical process data, which accumulate continuously, but are designed for operational monitoring and retrieval rather than as ML data sources.
- Control Network Access and Security: ML development teams require access to the control network to retrieve training data, validate models, and deploy interface scenarios, and the control network is usually separate from the general facility’s IT infrastructure.
- Compute Resources and Environment Management: Training ML models requires GPU-capable hardware that is not part of the control system network and may not be located at the facility.
- Framework Heterogeneity and Machine Interface: Once a model is ready to interface with the machine, it must connect through whichever control framework is deployed at that facility, each of which requires a different client library and presents a different data model.
- Operator Trust and Authority Transfer: Machine operators are responsible for the safe and efficient operation of the beam and must be confident that any automated system behaves predictably before ceding control to it.
Abstraction Layer Integration Architecture and Connector Framework
Design Principles
The challenges identified above impose a set of competing requirements on any integration layer that sits between AI services and operational control systems. The design principles listed below guide the architecture and together define what the integration layer must provide and what it must not change.
Design principles informing the Architecture:
- Non-invasiveness: The integration layer should not require modifications to existing control system configuration, hardware, or network topology.
- Framework-agnostic abstraction: an ML model or agentic workflow should address process variables through a single, unified interface regardless of which framework hosts them.
- Modularity: Each control system connector is an independently deployable service or component with a well-defined interface to the abstraction layer.
- Safety by default: The integration layer enforces a strict boundary between monitoring and actuation.
- Maintaining data quality: Data used for AI inference must be pre-processed to capture at least the following properties: timestamps, Connection state, Alarm/Quality, and Type precision.
Key Challenges of Abstraction Layer Design
Architecturally, we propose modelling a process variable as a stable identity paired with an access qualifier specifying how the data are retrieved (e.g., cycle selection, server-side filtering).
This separation of identity from qualifier enables uniform access across live and archived data and accommodates framework-specific retrieval mechanisms without complicating the core data model (Fig. 3).
Fig. 3 The core concept of the abstraction layer: for each control system framework, there is a connection layer implementing the appropriate interface. The rules that define the mapping between the Process Variables (PVs) on the control system side and the PVs on the AI side use the features of each specific framework. Access rules are implemented in a framework-independent manner.
Safety and Human‑in‑the‑Loop Mechanisms
The abstraction layer implements the following mechanisms based on the principles of Safety-by-Default and Human-in-the-Loop Control:
- Read-only Access to all PVs by default: write access is an explicit, opt-in, scope-restricted capability
- The abstraction layer access control acts as a safety mechanism, preventing the AI services from taking unintended actions
- Audit logging records which actions AI agents took, when, and with what outcome.
- The human-in-the-loop approval step lets operators review AI systems’ actions before execution, with an adjustable level of automation
- A watchdog mechanism confirms that an AI service capable of autonomous operation remains responsive
Facilities that wish to adopt autonomous AI agents should first confirm that the protective actions of their Machine Protection System (MPS) are non-degrading and do not shorten hardware lifetime. Training ML models often requires exploring operating regimes beyond those human operators would normally attempt, which increases the likelihood of triggering the MPS.
Large Language Models and Agentic AI in Control Systems
LLMs (Large Language Models) can play two complementary roles in accelerator control systems. In read-only tasks such as operator copilots they already offer immediate practical value, with frameworks such as Osprey³ and ChatEED⁴ showing encouraging early results. As actuating agents, they introduce substantially greater complexity and risk; open questions around automation scope, safety boundaries, and human oversight must be carefully resolved before wider adoption.
In both cases, the guiding principle is the same: LLMs should be deployed where their natural language capabilities are a genuine asset, within clearly defined boundaries, and with human oversight maintained throughout.
What’s coming next
Given the complexity of Large Language Models and Agentic AI in Control Systems, we will explore the topic in a separate blog. Stay tuned for a follow up blog by subscribing to our newsletter to make sure not to miss it.
TwinRise: Planned Validation of the Abstraction Layer
TwinRise is an EU-funded project within the ARTIFACT network that develops a Digital Twin Engine federating AI and simulation components across particle accelerators, oncology centers, and fusion research facilities.
Cosylab’s task within TwinRise is to implement the control-system abstraction layer presented in the Springer Nature EPJ Research Infrastructures 10, 18 (2026) published article “Bridging the Deployment Gap: Integrating AI into Accelerator Control Systems”.
For an in-depth read, head over to
“Bridging the Deployment Gap: Integrating AI into Accelerator Control Systems”
- 1 Dalesio LR, Kraimer MR, Kozubal AJ (1991) EPICS architecture. In: Proc. ICALEPCS’91, Tsukuba, Japan
- 2 Dalesio LR, Johnson K-UKAN (2019) The EPICS collaboration turns 30. In: Proc. ICALEPCS’19. https://doi.org/10.18429/JACoW-ICALEPCS2019-MOCPR02
- 3 Hellert T, Montenegro J, Sulc A (2026) Osprey: production-ready agentic AI for safety-critical control systems. APL Mach Learn 4(1):016a103. https://doi.org/10.1063/5.0306302
- 4 Reed AZ, Bisegni C, Shrestha S, Huang M, Ratner D (2025) ChatEED: An agentic retrieval assistant for accelerator operators. In: SC Workshops ’25: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis. ACM, St. Louis, MO, USA. https://doi.org/10.1145/3731599.3767408
Contact us
If you’re facing a similar challenge, get in touch with our engineering team.
What’s coming next
Given the complexity of the topic, stay tuned for a follow up blog. Subscribe to our newsletter to make sure not to miss it.