Future-Proofing Accelerator Operations: Where Control Systems and Machine Learning Converge

Publish date:

11. August 2025

Category:

Accelerators

Author:

David Pahor

Deploying ML in particle accelerators is no longer rare, yet its integration into day-to-day operations is far from universal, and the community is at a crossroads.

Future-Proofing Accelerator Operations: Where Control Systems and Machine Learning Converge

At the IPAC’25 conference in Taipei, Cosylab hosted a pivotal roundtable titled “Future-Proofing Accelerator Operations: Control Systems Meet ML.”

The discussion brought together leading experts in accelerator physics, control systems, and machine learning (ML) to explore a question that many facilities are only now beginning to ask themselves:

How can the next generation of control systems enable, rather than limit, the adoption of ML?

It is not so rare to find ML used in particle accelerators in some fashion, though its integration into day-to-day operations is far from commonplace.

The community is at a crossroads because early adopters have produced compelling results, but budget constraints, infrastructure mismatches, and a persistent lack of standardisation limit broad institutional usage.

This blog includes the Roundtable’s main insights, a summary of Cosylab’s ML-adoption poll at IPAC’25, and several use cases presented as contributed papers to the IPAC’25 conference.

The Roundtable featured (from left to right):

Dr Thorsten Hellert from the Lawrence Berkeley National Lab, a research scientist who works on accelerator physics and operations. His expertise lies in developing advanced diagnostics and control strategies for modern accelerator systems;

Dr Andrea Santamaria Garcia, a lecturer in Artificial Intelligence for Particle Accelerators at the University of Liverpool and a member of the Cockcroft Institute. Her research focuses on applying advanced AI techniques to optimise and control complex accelerator systems;

Dr Jonathan Edelen, the President of RadiaSoft, a company focused on computational accelerator science and AI-driven solutions for accelerator modeling and optimisation. He has a strong background in accelerator physics and applying machine learning to beam dynamics and control problems.

Tilen Žagar, a technical lead responsible for the design and architecture of control systems for particle accelerators and other big physics facilities. He develops embedded systems, timing and synchronisation systems, machine protection systems, and integrates devices and subsystems.

1. ML Is Here. Are We Ready?

Modern accelerator facilities are under growing pressure to deliver tighter beam parameters, faster switching between operating modes, more predictive uptime, and increasingly autonomous operation.

Dependable and well-understood traditional control system architectures are reaching their limits in managing this growing complexity.

Machine learning offers a transformational capability because, rather than hard-coding control logic, ML allows systems to learn from operational data, adapt to changing conditions, and support human operators in making faster, more accurate decisions.

Yet most control systems were not designed to be “ML-friendly.” They were built to acquire, store, and visualise data, but not to enable training loops, live feedback models, or inference pipelines.

2. ML-Readiness and the Invisible Bottleneck of Data

A recurring theme in the Roundtable was the idea that machine learning cannot be simply “added” to a system after it has been built because if it is not collecting the “right” operational data, no amount of later ML expertise will help.

Many things can make the data “not right”, for example not being sampled at a high enough rate, being processed instead of raw, having too little variance (non-optimal for training models), and not being fully synchronised across devices and made accessible in real time.

Additionally, Thorsten pointed out that many of today’s control systems result from decades of incremental design by different teams, with undocumented device behaviours and inconsistent naming schemes.

Thorsten added, “Documentation in general is often poor, and data archiving is either undersampled or lacks time synchronisation. While most operators do not notice all of these deficiencies, they make ML model development and deployment extremely difficult.”

“Documentation in general is often poor, and data archiving is either undersampled or lacks time synchronisation.”

Jonathan took the point further, warning that anomaly detection systems often fail because the diagnostics data needed to detect anomalies don’t exist, or weren’t collecting the right signals at the time of failure.

In other words, said Jonathan, “You can’t learn what you never saw.”

He called for new accelerator projects to be more deliberate about what data is collected, how it is labelled, and how it can be accessed.

True ML-readiness, according to the panel, includes:

High-resolution diagnostic data at full sampling rates;

Time-aligned data streams across subsystems;

Explicit metadata and labels for supervised learning;

APIs to enable both offline training and online inference;

Storage and compute pipelines compatible with model versioning and retraining cycles.

“You can't learn what you never saw.”

3. Ground Reality from the IPAC’25 Poll: Fragmentation and Pioneering Efforts

Despite the proven utility of machine learning in a growing list of use cases, the reality on the ground is more fragmented and sometimes reminds us of a “chicken-or-egg” situation. Facilities want to see clear evidence of return-on-investment (ROI) before funding ML efforts, yet that ROI is hard to prove without upfront investment and structural readiness.

Currently, much of the innovation is happening in small, experimental teams. Beamline operators at some light sources use ML models for tuning and diagnostics, sometimes during night shifts when they have more freedom to experiment. Others use ML to support junior operators or automate routine decisions.

A good example of an excellent test environment for the development of novel ML-based control and optimisation methods is the electron storage ring facility DELTA (https://delta.tu-dortmund.de/en/research/machine-learning/).

Among them are:

Self-regulating trajectory correction of the stored electron beam;

Feedback systems to control the working points and chromaticity values of the storage ring;

Optimization of the electron transfer rate from the pre-accelerator to the storage ring;

Spectral analysis of Coherent Harmonic Generation radiation.

Figure 1: ML Application Categories Reported at IPAC’25 Poll

Cosylab’s polling at IPAC’25 supports this picture, although the data reveals both promising advances and persistent fragmentation. Out of more than 100 responses, Beam Optimisation was the most common application of ML, followed by Diagnostics and “No/Not Using ML”, then Simulation/Modelling.

European institutions — especially CERN — showed the most diverse and mature implementations, while Asian respondents reported more exploratory uses. As there were less North American visitors, their responses were sparse, so we must take them with a statistical pinch of salt.

Nevertheless, we can make some general observations based on the data.

Specialisation versus diversification: some organisations focus on a single, well-developed ML application area (such as diagnostics), while others have multiple-pronged experimental or operational approach.

Quite some organisations reported no ML use, echoing the readiness and cultural adoption barriers already mentioned.

Control systems adoption is rare; despite the Roundtable’s emphasis on “ML-ready” control systems, few organisations report significant activity in this area.

Figure 2: Regional Trends in ML Application Types (IPAC’25 Poll)

The “other” group includes the following categories: Control Systems, Data Analysis, Design, Machine Operations, Machine Performance, Personal work optimisation, Uncler, Yes/Use unclear

Another key insight from the poll is that many ML use cases were categorised as “Misc/Other.” This suggests that while experimentation is happening, it lacks consistency, reproducibility, and standard interfaces, which is precisely the kind of structure that would allow ML benefits to be scaled across multiple facilities.

When talking about the results from the accelerator facilities that lead the way in machine learning usage, we may conclude that:

they are already making plans to be ML-ready in control system specifications;

their cross-disciplinary teams are starting to connect operations of both ML development and IT teams; and

machine operators at the sites are already helping in co-developing ML tools.

4. Cultural Resistance and Operator Buy-In

Another theme that came through strongly was the human factor. As Andrea put it, “We need to think of machine learning tools as co-pilots that assist operators.“ To be accepted by machine operators, ML tools must be embedded within existing interfaces and workflows.

Today, many ML applications run as standalone tools with GUIs that feel decoupled from the norm that operators are used to.

If ML is to become mainstream, it must feel like a natural extension of the operator’s panel, not a separate experiment requiring a new workflow.

"We need to think of machine learning tools as co-pilots that assist operators."

Cultural readiness is as important as technical readiness. The Roundtable panel agreed that operator buy-in, IT support, and cross-functional collaboration are as critical as data quality or compute capacity.

5. Infrastructure Support and the Role of IT

For ML models to run in real time, especially those involving deep learning or reinforcement learning, hardware acceleration (e.g. GPUs, dedicated ASICs or FPGAs) is often necessary.

However, deploying such infrastructure in operational control environments can pose logistical, budgetary, and political challenges in a research institution. One workaround is using cloud or shared infrastructure, which, on the flip side, brings challenges of its own about latency, permissions, and integration with protected control environments.

On the software side, things are no easier. One example shared involved deploying a model that failed to run due to a package dependency change by the facility’s IT team, without the ML developers’ knowledge.

This incident highlighted the urgent need for MLOps discipline in accelerator environments: reproducibility, versioning, rollback capability, and clear boundaries between IT and ML environments.

An additional challenge is the “silo effect.” In many facilities, physicists write their own control logic and software engineers are only loosely involved. As a result, even when ML results are promising in pilot studies, they often remain unintegrated into daily operations.

The consensus was that machine learning cannot be effectively deployed without institutional commitment to infrastructure: not just hardware, but also pipelines for data, model management, and operational support.

6. The Strategic Blind Spot in ML Project Planning — the Control System Specification

One of the strongest arguments made during the Roundtable was this: it costs very little to design an ML-ready control system, but it costs a great deal to retrofit that readiness later. Yet today, machine learning is often not included in the formal requirements of new large-scale accelerator facilities.

As a result, when budgets are drawn up, funding tends to flow towards the conventional areas that are “directly responsible” for creating the beam, such as magnets, vacuum systems and beamlines. ML ends up as an add-on, or worse, an afterthought.

Jonathan suggested that redefining ML from a “nice-to-have” to an essential element for achieving next-generation performance goals is the only way to change this. On the other hand, Andrea observed that in plasma accelerators and FELs, where tolerance margins are razor-thin, ML has already proven its “high-need” value through advanced optimisation routines and real-time control.

Project leaders and budget-holders are naturally cautious. But ML is undoubtedly promising, based on existing deployments that already enable several essential benefits they already need: increased uptime, faster commissioning, better user throughput, and more consistent beam quality.

Cosylab’s position on ML-readiness was straightforward – it should be a standard part of the control system specification, just like timing, synchronisation, or network topology. Even if no ML is deployed on day one, having the right data pipelines and hooks in place ensures that it can be deployed later, without significant rework.

7. A Vision for the Future: From Assistive to Autonomous Control

If today’s ambition of ML may be to assist operators with beam tuning and fault detection, its vision for tomorrow is broader. ML will enable adaptive, self-optimising systems that coordinate across subsystems and respond dynamically to changing experimental or grid conditions. Some examples are:

Virtual diagnostics that replace destructive probes;
Online phase-space reconstruction using real-time models;
Dynamic operation mode-switching to serve multiple beamlines.

Jonathan noted that the U.S. Department of Energy already demands light sources to increase user throughput. To meet these demands, facilities will likely need to adopt smarter, ML-driven optimisation routines to squeeze more performance from existing machines.

Andrea raised the point that we currently lack community standards or shared software skeletons to make this future vision practical now. Many ML tools remain hand-coded, site-specific, and poorly documented.

Without reusable software frameworks, system-wide deployment of ML will stay a complicated task, and teams will be hard-pressed to reproduce results.

8. Recommendations

Five Actions for the Community

The Roundtable suggested several actions for the accelerator community that can help steer towards this vision.

Design for ML-readiness from day one, using checklists.
This includes signal sampling rates, metadata tagging, synchronisation, and interfaces for inference and training.
Co-develop ML tools with operators, not just scientists.
Operators have hands-on experience with specific accelerators, which is vital for developing ML models that reflect real-world conditions and are more relevant. The tools must be practical for daily use and have a flat learning curve for those who aren’t ML experts.
Focus first on use cases with significant impact.
Start with tasks like beam orbit correction, anomaly detection, and operator guidance, where ML can show fast, measurable results.
Fund full-time research roles that combine ML, accelerator physics, and software engineering.
Cross-functional teams are essential for turning ML pilots into reliable tools.
Participate in shaping community standards.
Help shape and adopt common frameworks, benchmarks, and toolkits to accelerate shared progress. Hold regular community meet-ups to standardise approaches and share lessons, for example, as does the well-organised and motivated EPICS community with its collaboration model of semi-annual meetings, council activities and open-source model of software development.

A good starting point is MaLAPA (Machine Learning Applications for Particle Accelerators) community Discord server.

You can join the conversation by scanning the QR code or clicking on this link.

And finally, lean on expert partners.

There are engineering companies out there that possess both controls-integration knowledge and professional experience embedding ML principles into control system architecture, to make it future-proof, whether for new builds or legacy upgrades.

9. Final Thought: Retrofit Versus Native Integration?

The message from IPAC’25 was clear: machine learning in control systems isn’t “bleeding edge” anymore. It’s moving into the operational core of accelerator machines — just not everywhere, and not fast enough. The facilities that will design new ML-ready systems will have a decisive edge not only in performance, but in flexibility, maintainability, and long-term cost efficiency.

Yet the examples from the IPAC’25 contributed papers and the opinions from the Roundtable also reveal a common constraint: retrofitting ML into existing control systems is complex. It often requires restructuring data pipelines, developing custom interfaces, and dealing with legacy hardware constraints.

This poses a strategic question for the community, voiced clearly during the Roundtable: What if we designed our next control system with ML integration in mind from the start? Native integration would allow for:

Streamlined data acquisition pipelines;

Real-time inference paths with low latency;

Embedded retraining capabilities;

Modular interfaces to plug in new ML models without disrupting operations.

The vision is of a new generation of accelerator control systems that are intelligent by design, and which treat machine learning not as a bolt-on enhancement or afterthought, but as a fundamental architectural principle.

Table 1: ML Application Responses by Institution (Top 10 institutions by number of responses) (IPAC’25 Poll)

Institution	Beam Optimisation	Control Systems	Data Analysis	Design	Diagnostics	Machine Operations	Machine Performance	Personal Work Optimisation	No/Not Using ML	Simulation/Modelling	Unclear	Yes/Use Unclear
CERN	3	2	3	1	6	2	0	1	0	5	1	1
SLRI	2	0	0	1	3	1	0	0	1	1	0	1
GSI	2	0	1	0	0	0	2	0	0	0	0	1
IAP Frankfurt	3	0	1	1	0	1	0	0	0	0	0	0
PAL X-FEL	0	0	0	1	0	0	0	1	2	0	0	1
INFN	0	0	0	1	0	0	0	0	0	1	0	3
BINP	2	0	0	0	2	0	0	0	0	0	0	1
NSRRC	0	0	0	0	1	0	0	0	3	0	0	1
DLS	1	0	0	0	0	0	0	0	0	0	0	3
HZB	0	0	0	0	0	0	0	0	0	0	0	4

The Real-World Cases for ML from IPAC’25 Papers

The real-world cases for machine learning were taken from the published academic content presented at IPAC’25, which includes files of all invited and contributed papers, slides from oral presentations, and PDFs from poster sessions.

See full texts and summaries at: https://accelconf.web.cern.ch/ipac2024/index.html

The argument for machine learning (ML) in accelerator operations is not theoretical. It is grounded in dozens of real-world applications that have already shown measurable gains in stability, precision, efficiency, and fault detection.

Across the global accelerator community, teams are deploying ML models in increasingly sophisticated roles, spanning from beam tuning and anomaly detection to long-term predictive modelling and feedback control.

IPAC’25 presented a wealth of use-cases for applying ML in accelerator facilities. Here is a list of some of the most fascinating.

Case Study: FRIB – Learning-Based Model Predictive Control

One of the most mature implementations of ML in accelerator operations is at the Facility for Rare Isotope Beams (FRIB) in Michigan. There, a machine learning–based model predictive control (MPC) system has been integrated into the superconducting radio-frequency (SRF) beamline. This MPC system uses historical data to model the nonlinear correlation between control variables and beam loss. Once trained, the model can guide operational parameters in real time to minimise beam loss while maintaining high transmission efficiency. Notably, this is not a demonstration but a deployed, production-grade system that is now part of FRIB’s operational workflow.

CSNS: Correcting Orbit Drift with ML

At the Chinese Spallation Neutron Source (CSNS), researchers have applied ML to one of the most persistent problems in accelerator operations: orbit drift and injection instability. By learning the nonlinear relationships between control magnets and the beam orbit, the model supports real-time correction in the Rapid Cycling Synchrotron (RCS). This is especially relevant in high-repetition accelerators where small injection errors can compound into significant beam degradation downstream. The approach is both robust and adaptable, offering resilience against slow drifts and fast transients alike.

CERN IRRAD: Anomaly Detection for Beam Quality

At CERN’s IRRAD facility, ML has been deployed for beam anomaly detection, which is a task traditionally handled by interlock systems and threshold-based alarms. Using historical beam intensity profiles, sensor readings, and expert-labelled failure events, the ML model was trained to recognise subtle precursor patterns indicating beam quality degradation. It successfully detected anomalies in a 24 GeV/c proton beam that had previously gone unnoticed by standard monitoring systems. This demonstrates ML’s potential to go beyond threshold logic and into predictive maintenance territory.

LHC: Accelerating Dynamic Aperture Evaluation

Dynamic aperture (DA) calculations are critical for understanding beam stability. A key ML application comes from the Large Hadron Collider (LHC), where DA calculations traditionally rely on time-consuming particle tracking simulations. By replacing these with surrogate ML models trained on prior simulation data, researchers have dramatically reduced the evaluation time for new optics configurations. This directly influences operational agility, enabling faster iteration and decision-making during commissioning and upgrades.

MAX IV and Real-Time Corrections

In Sweden’s MAX IV facility, ML is being explored for device correction in its 3 GeV ring. Researchers trained models to infer optimal correction settings from noisy sensor input, enabling smoother and more stable operation. Such approaches are especially valuable in modern accelerators where conventional correction methods often struggle with system complexity and nonlinearity.

Infrared Imaging for Anomaly Detection

Beyond core beam dynamics, ML is also found to be used in peripheral, yet critical, subsystems. At Argonne National Laboratory, ML-enhanced infrared imaging has been deployed to detect thermal anomalies in power supply units. These components often operate under extreme load conditions and are prone to thermal degradation. The ML model classifies thermal images to flag potential failure zones early, thus enhancing reliability and reducing unplanned downtime.

ML in Beam Emittance Optimisation

At the European XFEL (EuXFEL), researchers depend on ML to improve beam emittance control, which is a key factor in maintaining beam quality and luminosity. By combining cavity and performance data with neural network regression and NARMAX modelling, they can predict and tune beam parameters under varying humidity and temperature conditions. This is a step toward self-correcting systems, capable of compensating for environmental fluctuations in real time.

Towards a Future-Ready Control Stack

These examples are not just proofs of concept but reflect ML’s ability to improve vital aspects of accelerator operations: stability, performance, and responsiveness.

From predictive feedback to early fault detection, the potential benefits are clear. Yet challenges remain: data quality, model generalisation, integration complexity, and trust in ML outputs. Overcoming these will require close collaboration between accelerator physicists, control system engineers, and ML practitioners.

In summary, machine learning is no longer on the periphery of accelerator operations. It is already driving tangible performance improvements across multiple facilities, and the next step is making it elemental to every system.

About the author

David Pahor is a physicist who exchanged software development for technical writing and now works in Cosylab's Marketing, where he mints content. In his free time, he writes short fiction and waits on two bull terriers.

Back

This website uses cookies