EPICS

EPICS — Experimental Physics and Industrial Control System — is an open-source toolkit for building distributed, soft real-time control systems. It is used to operate some of the most complex scientific instruments in the world: particle accelerators, synchrotron light sources, fusion reactors, neutron sources, and radio telescopes. Unlike a general-purpose programming language, EPICS is a domain-specific framework whose defining abstraction is the process variable (PV) — a named, network-accessible data point attached to a physical or logical quantity in a facility. The system’s configuration language is declarative: operators and engineers describe the structure of a control system — its sensors, actuators, interlocks, and alarms — as a database of typed records, and EPICS handles the real-time processing, network communication, and alarm management at runtime.

History & Origins

EPICS traces its roots to work begun in 1988 at Los Alamos National Laboratory (LANL), where a team led by Bob Dalesio and Jeff Hill was building controls for the Ground Test Accelerator (GTA), a linear accelerator research project. Dalesio designed the Input/Output Controller (IOC) model — the embedded software node at the heart of every EPICS system — while Hill conceived and implemented Channel Access (CA), the network protocol that allows any client on a facility’s network to read or write any process variable by name.

In 1989, Marty Kraimer of Argonne National Laboratory’s Advanced Photon Source (APS) project joined the collaboration. Kraimer redesigned the IOC’s internal database engine, introducing an extensible record-and-device-support architecture. This design, which separates the generic record processing logic from the hardware-specific device support and low-level driver code, is still the structural foundation of EPICS today.

The project was formally named EPICS and presented to the accelerator controls community at the 1991 IEEE Particle Accelerator Conference. The presentation sparked immediate interest across the high-energy physics and synchrotron communities, which were independently developing control systems for new facilities and recognized in EPICS a well-designed, collaboratively maintained alternative to building everything from scratch.

Design Philosophy

EPICS embodies a philosophy uncommon in software: it is explicitly designed to be operated by physicists and engineers who are not primarily software developers.

Process Variables as First-Class Citizens

Every quantity in an EPICS system — a temperature reading, a magnet current, a beam position, an on/off interlock — is a named process variable. PVs are first-class network objects: any authorized client anywhere on the network can subscribe to a PV and receive real-time updates whenever its value changes, without polling. This publish-subscribe model, implemented by Channel Access and its successor pvAccess, decouples data producers (the IOC hardware) from data consumers (operator displays, logging systems, automated programs) in a clean, scalable way.

Declarative Record Databases

Control system engineers configure an EPICS IOC by writing a database definition — a text file that instantiates records of predefined types and sets their field values. A simple analog input record for a temperature sensor might look like this:

record(ai, "MYDEVICE:TEMPERATURE") {
  field(DESC, "Inlet water temperature")
  field(EGU,  "deg C")
  field(HIHI, "80")
  field(HIGH, "70")
  field(HSV,  "MAJOR")
  field(SSV,  "MINOR")
}

This declarative style means that defining alarm limits, engineering units, scan rates, and calibration conversions requires no procedural programming — the record type handles all of it. Engineers compose hundreds or thousands of such records to describe a complete subsystem.

Openness and Collaborative Maintenance

From the beginning, EPICS has been free and open-source. The collaboration has no formal membership, no licensing fees, and no single controlling organization. Institutions share code through the official epics-controls.org infrastructure and GitHub repository, and the community gathers at semi-annual EPICS Collaboration Meetings to present advances and coordinate development. This model has proven remarkably durable: the same collaborative spirit that produced the original architecture in the late 1980s still drives development today.

Key Features

Record Types and the Process Database

An EPICS IOC contains an in-memory process database — a collection of records loaded at startup. Each record belongs to a record type that defines its fields and processing behavior. Standard built-in types include:

Custom record types can be written in C and linked into an IOC application, giving specialists the ability to implement specialized processing — motor controllers, fast digitizers, cryogenic regulators — within the standard framework.

Channel Access and pvAccess

Channel Access (CA) is the original EPICS network protocol. It is a UDP/TCP hybrid: clients broadcast a name-search request to discover which IOC hosts a given PV, then establish a TCP connection to that IOC and subscribe to the PV’s value. Updates are pushed to the client whenever the record processes and the value changes. Channel Access has been in production at major facilities since the early 1990s and is extraordinarily well-proven.

pvAccess, developed as part of the EPICS V4 initiative and merged into EPICS 7, is a newer protocol that supports structured data types beyond the scalar and array values Channel Access handles. pvAccess enables features such as normative types for standardized data exchange between services, remote procedure calls over the EPICS network, and native 64-bit integer support.

State Notation Language (SNL)

For control sequences that require more logic than a record database can express — complex startup sequences, interlock state machines, ramping procedures — EPICS provides the State Notation Language (SNL) and its associated sequencer. SNL is a domain-specific language with C-like syntax, compiled to native code and executed as a task inside the IOC. An SNL program is structured as a set of named states, each with when clauses that test conditions (expressed as Channel Access subscriptions) and trigger transitions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

ss mySequence {
  state idle {
    when (pvGet(beam_permit) == 1) {
      pvPut(shutter_cmd, OPEN);
    } state opening
  }
  state opening {
    when (pvGet(shutter_status) == OPEN) {
    } state beam_on
    when (delay(5.0)) {
      pvPut(alarm_msg, "Shutter timeout");
    } state fault
  }
}

SNL programs can read and write any PV in the IOC and can embed arbitrary C code, giving them full access to the facility’s process database while remaining clearly structured as state machines.

Alarm and Monitoring Infrastructure

Every record in an EPICS database has built-in alarm fields. When a value exceeds a threshold, the record transitions through defined alarm severities (MINOR, MAJOR, INVALID) and propagates the alarm state to any connected client. Tools such as the Alarm Handler and Alarm System Expert (ASE) aggregate alarms across an entire facility, providing operators with a single, real-time view of the system’s health.

Extensible Device and Driver Support

The separation of record type, device support, and driver support means EPICS can be adapted to virtually any hardware. Device support modules — typically written in C — translate generic record processing requests into hardware-specific operations. Drivers manage low-level communication with hardware interfaces (GPIB, serial RS-232, VME bus, Ethernet-based fieldbus systems, and more). This architecture means that a new instrument can be integrated into a facility’s EPICS system by writing a single device support module, without any changes to the core toolkit.

Evolution

EPICS has evolved continuously since its 1991 debut, with its most significant architectural shift occurring in EPICS 7.

The long life of EPICS 3.13 in production — some facilities ran 3.13-based systems for more than a decade — reflects both the stability of the architecture and the conservatism of operational scientific facilities, where control system stability can directly affect experiment availability worth tens of millions of dollars per year.

Current Relevance

EPICS remains the dominant control system toolkit in high-energy physics and photon science. The epics-controls.org community lists over 100 contributing institutions across North America, Europe, Asia, and Australasia. Active development continues on EPICS Base through a community process hosted on GitHub, with releases coordinated by the EPICS core developers and validated by a broad group of contributing facilities.

ITER — the international tokamak fusion project in southern France, representing a multi-billion-euro investment by 35 nations — selected EPICS as the foundation for its Plant Control System, a choice that secures the toolkit’s relevance well into the 2030s. New light sources have also adopted EPICS as their standard control framework, including MAX IV in Sweden (commissioned approximately 2016–2017) and facilities under construction in the UK and the United States.

The community communicates through the tech-talk mailing list (one of the oldest and most active in the scientific computing world), a Matrix chat server, and the semi-annual EPICS Collaboration Meetings, which rotate between facilities on different continents.

Client-side tooling has also diversified significantly in recent years. PyEPICS (Python), MATLAB Channel Access Toolbox, and caproto (a pure-Python Channel Access implementation) give physicists and data scientists flexible access to live facility data. The Phoebus operator display client, which replaced the long-lived Control System Studio (CS-Studio), provides a modern JavaFX-based interface for building operator screens connected to EPICS process variables.

Why It Matters

EPICS represents a successful, decades-long experiment in open, collaborative scientific software development that anticipated many practices — open governance, shared infrastructure, community maintenance — that only became mainstream in the broader software industry after the rise of GitHub and open-source foundations.

From a language design perspective, EPICS demonstrates the power of declarative, record-oriented configuration for hard real-time systems. The idea that a control engineer should describe what a system should monitor and alarm on — rather than how to implement the monitoring loop — separates policy from mechanism in a way that has scaled from 1991 to today without fundamental architectural revision.

The toolkit also illustrates how domain-specific languages succeed in practice. The record database language, Channel Access protocol, and State Notation Language each target a specific layer of the control problem. Together they form a coherent stack that specialists can learn and reason about without requiring deep software engineering backgrounds.

At the most concrete level, EPICS underpins real-time control at facilities such as the Spallation Neutron Source at Oak Ridge — where users can monitor their experiments from a laptop — and will reportedly govern portions of ITER’s first sustained fusion plasma operations, connecting that effort to technology first assembled in a New Mexico accelerator laboratory in 1988.