Python Middle Layer CATAP Simplifies Control of Particle Accelerators

Particle accelerators are among the most complex machines ever built, packed with magnets, superconducting radio-frequency cavities, beam diagnostics, vacuum systems and detectors, much of it facility-specific hardware that no commercial supplier offers. Controlling that hardware falls to software systems that were engineered for controls specialists, not for the physicists and operators who need to run experiments. A team working across two major accelerator facilities has now described a Python package designed to bridge that gap, offering a modern, openly documented middle layer that translates the arcane language of a control system into functions a scientist can actually read.

The package, called CATAP, short for Controls Abstraction Towards Accelerator Physics, is presented in a review article published in EPJ Research Infrastructures. Its authors, led by Matthew King, describe a software layer that sits between the low-level control system interface and the end users, including operators, system experts, scientists and experimental users. Rather than requiring every script author to learn the naming conventions and interlock logic of the underlying control system, CATAP provides a structured and coherent interface through which higher-level control logic and device information can be centralized in one place.

The problem the package addresses is a familiar one in accelerator facilities. To change the strength of a magnet, a scientist should not need to know which interlocks must be cleared before the power supply can be activated, or the specific mechanism for switching on the power and adjusting the current. Yet control systems expose the full operating range of hardware, and only a small subset of parameters is relevant to daily physics work. Controls engineers also tend to name devices in ways that differ from the terms operators find useful, and deciphering those names can itself be a burden. Abstracting away that complexity has been a persistent challenge across the field.

Several middle layer frameworks have been developed before. The most notable is the Matlab Middle Layer, widely used at storage ring facilities, which nevertheless requires proprietary MATLAB licenses. A bespoke C++ middle layer was deployed during the commissioning and first experimental campaigns of the Compact Linear Accelerator for Research and Applications, known as CLARA, at Daresbury Laboratory in the UK, but that package could not easily be transferred to other facilities. Another Python-based option, Bluesky and its hardware abstraction library ophyd, has been adopted at some facilities, though its typical application is experiment orchestration and data acquisition, focused on process variable and device-level interfaces. CATAP was designed with accelerator operations as its primary use case, allowing devices of similar types to be grouped into Factories for group operations, heterogeneous devices to be combined into high-level systems with simplified interfaces, and the impact of control system changes on compiled executables to be reduced through YAML-based configuration.

The package is a Python interface to the Experimental Physics and Industrial Control System, built on the pyepics library for Channel Access process variables and p4p for PVAccess process variables. It has been deployed at two facilities: the Linac Coherent Light Source at SLAC in the United States, and CLARA. The scale contrast between the two is striking. The LCLS tunnel houses three linear accelerators that can operate simultaneously, spanning three kilometres and containing millions of process variables associated with radio-frequency systems, magnets and diagnostics. LCLS-cu has operated since 2009 and regularly delivers beams of up to 16 GeV at a repetition rate of 120 Hz, while the superconducting LCLS-sc saw first light in 2023 and is ramping up toward 4 GeV beams at 1 MHz, with additional cavities planned during the 2026 downtime to reach 8 GeV. CLARA, by comparison, is a normal-conducting facility operating at 100 Hz with a maximum beam energy of 250 MeV, yet even its daily operation requires monitoring and controlling thousands of process variables.

The architecture rests on human-readable YAML configuration files. Each hardware object read into the middle layer is described in a file containing two mandatory headings: controls_information, which maps the full names of process variables along with their data types and read-only flags, and properties, which define the root name of the process variable, the hardware type, and the machine area and position used for sorting. These files require no Python knowledge to write, are easy to version, and remain independent of hardware changes. Connections to the process variables are set up through pyepics or p4p, with additional type-checking and validation performed by the pydantic library, so that missing or misconfigured information throws an error rather than failing silently. The defined process variable types include binary, scalar, waveform, string, state and statistical categories, with the statistical type updating automatically through callbacks and maintaining a buffer from which statistics can be calculated.

Above that sits the Hardware class, where simplified, human-readable functions are provided. The abstraction can absorb genuine differences in low-level implementation: certain magnets on CLARA have a two-stage interlock chain that must both be cleared before the power supply can be switched on, while others have only one set, and the middle layer determines the required method and presents a single common interface for powering on the magnet. Similar examples include movable diagnostic screen stages of three different types, camera image saving that requires directory creation, acquisition state changes and post-acquisition queries, and automatic checks that all upstream screens or wires are retracted during beam tuning. Similar hardware objects are then grouped into Factory classes, from which a user can switch on all magnets, remove all diagnostic screens or acquire statistics from all beam position monitors without knowing any individual process variable names. Elements that operators regard as single pieces of hardware but that exist in the control system as groups of separate devices are handled as HighLevelSystem objects; the CLARA photoinjector laser, for instance, incorporates the laser attenuator, energy meter, shutters, mirrors and a virtual cathode camera into one coordinated unit.

A Snapshot interface captures the current machine state for any hardware object or factory, again in YAML format, so that settings can be saved, applied later, compared between two files, or compared against the live machine. Because buffers for statistical parameters are saved too, the snapshot can function as a general-purpose data acquisition tool. Applying saved settings respects the logic each object requires, such as clearing interlocks and degaussing a magnet before applying a saved field strength. Development is aided by a virtual accelerator for CLARA, an EPICS-based emulation hosted on a local server or available as a Docker image, on which scripts can be prototyped without disrupting machine operation; the authors report that rigorous testing on this virtual system made deployment on the physical machine relatively trivial.

Perhaps the most consequential feature is templated code generation. Because facilities differ in which parameters they use for a given hardware type and in their procedural logic, forcing a universal naming convention was judged unreasonable. Instead, facility-specific YAML files are injected into template files using the Jinja library, generating base model classes for each hardware type with the core functionality already implemented, alongside code stubs for facility-specific child classes that local developers extend. Regular procedures already benefit: photoinjector laser characterization scans on CLARA, measuring cathode electron emission across the cathode surface and as a function of laser energy, acquire laser position, pulse energy and bunch charge simultaneously through the high-level system, with virtual cathode images captured automatically. At LCLS, where legacy applications were written in MATLAB GUIDE, a language Mathworks has since sunset, the CATAP design now informs base device classes for new Python applications, with YAML files generated automatically from the Oracle hardware database for magnets, screens, wires, beam position monitors, beam loss monitors and transverse deflecting cavities. Factory-like access can reduce the task of switching off every magnet in an area, previously requiring repetitive panel interactions, to fewer than ten lines of code.

The generated version of CATAP is being investigated at CLARA, LCLS and the ISIS Neutron and Muon Spallation Source, and support for additional control protocols such as TANGO is under investigation. The authors caution that the specific implementation of the design will vary between facilities, owing to differences in how control systems and hardware have been set up, and that most hardware types still require facility-specific procedures best completed by developers at each site. What the package demonstrates, they argue, is that a generally applicable design can codify system knowledge that is usually anecdotal, greatly reduce duplicated code across high-level applications, and let researchers spend more of their attention on the physics rather than on the plumbing beneath it.

Subject of Research: A Python middle layer software package for abstracting particle accelerator control systems

Article Title: Controls Abstraction Towards Accelerator Physics: A Middle Layer Python Package for Particle Accelerator Control

Article References: King, M., Brynes, A. D., Neveu, N., Scott, D. J., Jackson, F., Jones, J. K., Ziyan, N., Johnson, M. A., Baker, K., Kabana, T., Garnier, C., Chowdhury, S., & Roussel, R. (2026). Controls Abstraction Towards Accelerator Physics: A Middle Layer Python Package for Particle Accelerator Control. EPJ Research Infrastructures, 10(1), Article 24. https://doi.org/10.1007/s41781-026-00169-4

Image Credits: AI Generated

DOI: 10.1007/s41781-026-00169-4

Keywords: particle accelerators, CATAP, control systems, EPICS, Python, middle layer software, YAML configuration, LCLS, CLARA, code generation, beam instrumentation, scientific software