What’s Sigmon?

The LHC relies on more than 1,500 superconducting circuits. During every shutdown and technical stop, each circuit must be tested—and every test produces data that somebody has to assess. SigMon performs that assessment automatically and returns a result that an expert can sign off on.

A single campaign can involve up to 17 tests per circuit. At that scale, manual analysis is not merely a question of effort, but also of consistency: the same signal must be assessed in the same way every time. Historically, test analysis relied on multiple tools and required several expert signatures for each test, creating a heavy workload and sometimes producing inconsistent results.

The Signal Monitoring (SigMon) framework centralizes the analysis of powering tests in a unified Python environment. It aims to automate tests performed on the LHC’s superconducting magnet circuits—not only during Hardware (Re)Commissioning, technical stops, and other shutdown periods, but also during operation. SigMon applies expert-defined acceptance criteria to recorded signals, returns a pass-or-fail result, and clearly shows how that result was reached. In doing so, it provides the precision, consistency, and transparency needed to help protect multimillion-euro equipment at the heart of the world’s largest machine.

Why the circuits are tested

Superconducting magnets are what let the LHC reach record collision energies: they carry enormous currents without resistance, and so produce very strong magnetic fields. But under certain conditions a magnet can lose its superconductivity — a quench — and an uncontrolled quench can damage it beyond repair.

Quench protection systems exist to prevent that. Those systems, and everything else needed to operate a magnet, are themselves monitored by two logging systems: Post Mortem (PM), which stores data at high rate around critical events, and NXCALS, which records continuously at a lower rate. To confirm that every component works and communicates as expected, all circuits undergo rigorous testing during each shutdown or technical stop — the hardware (re)commissioning campaign.

How a circuit is protected

Four systems cooperate to shut a circuit down safely. The QPS (Quench Protection System) detects the resistive transition. The PIC (Powering Interlock Controller) distributes the resulting interlock. The PC (Power Converter) stops driving current. And the EE (Energy Extraction) system dumps the circuit’s stored energy into a resistor.

They are wired into two hardware loops, and most of what SigMon checks during a powering test is whether the right signals appeared on those loops, in the right order, within the right time.

Architecture

SigMon is a set of Python packages layered on a single data-access library, plus the services that connect them to the outside world.

Repository	What it does
lhc-sm-api	Data access: PM and NXCALS queries, circuit and signal metadata, and the base analysis class everything else builds on.
lhc-sm-powering	Powering test analyses — PIC, PLI, PLIS, PNO, PCC — each triggered by an AccTesting test execution.
lhc-sm-ee	Energy extraction analyses for the 13 kA and 600 A systems, triggered by events rather than by a scheduled test.
lhc-sm-qh	Quench heater discharge analyses for RB, RQ, IPD, IPQ and IT circuits.
lhc-sm-it	Commissioning notebooks for the IT String.
sigmon-analysis-server	The service AccTesting calls after a test: runs the analysis and returns pass or fail plus a link to the report.
sigmon-swan-deployer	Publishes the analysis packages and notebooks to SWAN so experts can run them interactively.
sigmon-report-browser	Browses the generated HTML reports.

The analysis pipeline

SigMon is written in Python, and every analysis — whatever the circuit or the test — follows the same three stages.

Stage	What happens
Query	Signals are retrieved from PM for high-precision data and from NXCALS for continuous monitoring, which covers events PM cannot fully capture. The data is then conditioned: smoothing filters, removal of spikes from electromagnetic interference, and detection of the key timestamps — plateau starts and ends, current and voltage decay ends.
Analyze	Modular checks run against the conditioned data. Analog checks find plateaus, verify bounds and calculate resistances. Digital checks verify state transitions and their timing. Timestamp checks confirm PM buffers are present and that everything is properly synchronised.
Output	A Passed or Failed result, together with detailed logs covering every stage — so a disagreement with the verdict can be traced rather than argued.

Each analysis is associated with a Jupyter notebook displaying logs, analysis results and interactive plots. Automatically executed analyses generate interactive HTML reports. SigMon is fully integrated with AccTesting, CERN’s centralized framework for test scheduling and tracking, enabling storage of analysis results and logs, as well as direct access to interactive reports.

Powering tests

Most of what SigMon analyses is powering tests. Each circuit is taken through a sequence of tests defined for its type, at gradually increasing current — from a first minimal-current interlock check up to nominal current and beyond. Tests are grouped into families: the same test code means different things on different circuit types, so each has its own analysis and its own written specification. The Circuits page lists every test and what covers it today.

Running that sequence is how the protection chain above gets proven to work before beam returns. AccTesting hands each test to the Hardware Commissioning Sequencer, which drives the real devices — PC, QPS, PIC, EE — through it, and only reports the test as run once that’s done.

From there SigMon queries PM and NXCALS and runs the checks defined by experts — the current profile check above is one of dozens like it — before returning a signature to AccTesting alongside an automatically generated HTML report: the same notebook, run through papermill with that test’s actual parameters and rendered to HTML. SWAN itself is now mostly a fallback: an expert opens the live notebook there, pasting in the test parameters by hand, only when the automated report needs a closer look.

Energy extraction

Energy Extraction systems are one of the main defences against a quench. They are designed to pull the maximum possible stored energy out of an entire superconducting circuit: when a quench is detected, extraction switches open and redirect the current into a dump resistor in series with the magnet chain. The current then decays exponentially and under control, instead of depositing its energy in the magnet.

Circuit	Count	EE systems
13 kA main dipole (RB)	8	Two each — one at the mid-point, one near the power converter
13 kA quadrupole (RQF, RQD)	16	One each
600 A corrector	~200	Being equipped with their own

The 13 kA systems always come in pairs — ODD and EVEN for the dipoles, RQF and RQD for the quadrupoles — and the pair is judged together: peak voltages and the difference between them, the time constant of the decay, and the gap between the two recorded events. When many events are analysed at once, a search step pairs them by circuit and timestamp, keeping at least ten minutes between pairs so that redundant recordings from a single perturbation are not counted as separate events.

The 600 A systems are judged first on whether the Z capacitor opened during the event, and then on whether U_CAP_A, U_CAP_B and U_CAP_Z stayed within bounds, along with the current at the end of the decay and the peak voltages.

Alongside those analog checks, each digital signal carries an expected behaviour over a window defined relative to the event trigger. There are four, and criteria can be chained so that a verdict depends on several signals together.

Expected behaviour	Meaning
REMAINS_EQUAL_TO_TRUE	Held high for the whole window.
REMAINS_EQUAL_TO_FALSE	Held low for the whole window.
CHANGES_ONCE_TO_TRUE	Went high exactly once, and stayed there.
CHANGES_ONCE_TO_FALSE	Went low exactly once, and stayed there.

During HWC’25 the automated analysis ran for 372 circuits across two powering tests, PLI3.b1 and PNO.b1. In normal operation, an application integrated into the CCC lets operators watch many 13 kA systems over a configurable window and spot a failed check quickly.

Quench heaters

Quench heaters are the other main protection: fired on detection, they deliberately spread the quench through the magnet so the stored energy is dissipated over a large volume rather than a single spot. Each discharge is recorded by PM, and SigMon analyses it for RB, RQ, IPD, IPQ and IT circuits — extracting the characteristic decay time and the initial resistance, voltage and current, and comparing them against a stored reference discharge for that heater.

How we keep the results trustworthy

A result is only useful if it can be relied on without being re-checked by hand. Four layers of testing stand behind every analysis.

Layer	What it protects against
Unit tests	A single check, function or method behaving incorrectly in isolation.
Integration tests	Historical analyses drifting — recorded runs are compared against their expected log output.
Notebook tests	A visualisation notebook crashing when an expert actually opens it.
Validation tests	Systematic error — hundreds of past tests are re-run and compared with results from previous automatic or manual analysis.

Those same validation runs are how acceptance thresholds get revisited. A circuit in perfect condition can fail a check by a very small margin, and when that happens the honest fix is not to wave the result through but to re-run the validation set, plot the variable in question across hundreds of past tests, and set the threshold from evidence.

Code is reviewed by the team on every merge request, and GitLab CI runs the test suites on commits, pushes and tags. The toolchain is pytest, mypy, ruff, black, markdownlint, papermill; issues and changes are tracked in Jira. Once merged, notebooks and packages are deployed to SWAN through sigmon-swan-deployer, and a new tag of the main repository is released to Acc-Py — typically when a new test has been written or a significant capability added.

The 2026 campaign

The 2026 hardware commissioning campaign was the first in which automated analysis was applied to every powering test across the LHC’s superconducting circuits. 5,095 mandatory and on-request tests were planned, together with 24 special tests; counting re-executions, 5,409 were run.

Measure	2026 campaign
Automation coverage	100% of mandatory and on-request powering tests
Tests executed	5,409, of which 5,384 were analysed in SigMon
Signatures issued automatically	5,392
False positive rate	1.5%, down from 10%

Two changes account for most of that improvement: acceptance criteria were reviewed and tightened against evidence, and the several signatures a test used to produce were consolidated into one signature per test. Fewer false positives means less expert time spent confirming that a result was fine after all.

The practical consequence is that analysis is no longer what limits a campaign. How long HWC takes is now set by cryogenics availability, by the tests themselves, and by how cleanly the sequences execute. The same framework carries over to most of the circuits that will be commissioned after the LHC’s major upgrade.

The full account is in A. Chmielinska et al., “The first fully automated analysis of the Hardware Commissioning tests for superconducting circuits at the LHC”, IPAC’26, MOP7082 — listed with the rest of the project’s writing on the Resources page.

What’s next

Event-driven analysis, with the same automatic reports. Powering tests already get an automatic HTML report the moment AccTesting triggers them. Energy extraction and quench heater events don’t yet — an expert still runs the notebook by hand on SWAN. The plan is the same move for both problems at once: put EE and QH analysis onto DPP, CERN’s event-driven platform, so it reacts to Post Mortem events as they’re recorded and generates a report the same way powering tests already do. The groundwork — sigmon-dpp-integration — is built.

Wider coverage. Alongside both, the ongoing work is simply more circuits and more tests brought under automated analysis.