Design and implementation of machine learning-based anomaly detection in the ITER Tokamak Systems Monitor

Abstract

The Tokamak Systems Monitor (TSM) is a software suite under development at ITER that provides operators with an integrated view of the tokamak’s engineering health based on operational instrumentation. A key functionality of TSM is anomaly detection, aimed at identifying unexpected behaviors across a wide range of systems. To this end, a dedicated anomaly detection module is being developed to integrate multiple machine learning-based algorithms, ranging from intershot classification of complete pulses to online detection of localized events. The current status of this module and its roadmap for future development are illustrated with two implemented examples: an intershot algorithm that uses dimensionality reduction and clustering to classify gyrotron pulses, and a time-localized approach based on an invertible neural network to monitor magnet power supplies. Automated warnings generated by the module will support operators in evaluating anomalies, thereby enhancing the reliability of ITER operations.

1 Introduction

Large fusion devices rely on extensive operational instrumentation to ensure that components operate within expected conditions and that early signs of degradation can be detected before they lead to failures or performance losses. In practice, however, anomalous behaviors in engineering signals can take various forms and may not always breach predefined thresholds or trigger existing alarm logic. As the number of monitored channels grows into the thousands, as expected for ITER, manually diagnosing such behaviors becomes impractical, motivating the need for scalable and automated anomaly detection tools.

Machine learning (ML) approaches have increasingly been explored in fusion research for their ability to capture high-dimensional structure, model complex relationships, and identify deviations from nominal operation without relying solely on manually defined rules. Several fusion devices have begun applying ML-based anomaly detection to engineering subsystems and components, including JET [1], DIII-D [2], and WEST [3–5], where these methods have demonstrated their value for the visual monitoring of component damage, assessing sensor integrity, and thermal monitoring respectively. This broader trend highlights a growing recognition that data-driven techniques can complement traditional threshold-based ones by identifying subtle signs of faults or drifts in ways that scale with both sensor count and signal complexity.

In parallel, many fusion laboratories are developing increasingly sophisticated digital twins, which are virtual replicas of tokamak components or subsystems that combine validated physics models with real operational data. As reviewed in a recent survey of digital twins in fusion research [6], these efforts aim to support tasks such as real-time forecasting, scenario optimisation, and early detection of abnormal behavior through model-data comparison. Although many existing implementations remain system-specific or exploratory, their rise reflects a community-wide shift toward data-assisted monitoring frameworks that leverage both physics knowledge and data-driven insights.

The Tokamak Systems Monitor (TSM) software [7] under development at ITER aggregates operational and archived data from a wide range of engineering systems and provides a suite of analysis tools and algorithms to support operators during commissioning and operation, ranging from the reconstruction of parameters [8] to the verification and calibration of numerical models [9]. These capabilities rely on both measured signals and the outputs of numerical engineering models, which together define a broad set of observables that can be monitored for consistency with expected behavior. Anomaly detection is one of the top-level functions of TSM, for which a dedicated module has been designed to host multiple ML-based algorithms under a unified software framework, enabling both intershot analysis of entire pulses and time-resolved monitoring during operation. The goal is not to replace existing protection systems but to provide early warnings that help operators detect unusual behaviors, investigate potential root causes, and refine monitoring strategies over time.

This paper presents the design and implementation of the machine learning-based anomaly detection module of the ITER Tokamak Systems Monitor. A modular software framework is described, together with two representative anomaly detection algorithms illustrating intershot and time-localized monitoring. The focus is on integration and operational considerations rather than algorithmic novelty, reflecting the pre-operational status of ITER. Section 2 describes the architecture of the anomaly detection module and its integration within the TSM. Section 3 presents the two machine-learning case studies used to illustrate intershot and time-localized anomaly detection. Section 4 discusses the challenges of operational deployment, including expert feedback and continuous model evolution. Finally, Section 5 summarizes the main conclusions and outlines remaining challenges toward long-term use.

2 Anomaly detection module

The anomaly detection module is designed to operate as a set of monitoring algorithms managed by the main TSM application. Within the Plant Operation Zone (POZ)¹, the TSM application provides a generic execution framework for monitoring algorithms. This framework covers configuration handling, data acquisition, triggering, execution, and publication of results. The anomaly detection module integrates into this framework as a collection of Python-based algorithms unified under a common interface and executed under the supervision of the TSM POZ application.

This section focuses on the requirements, interfaces, and internal structure of the anomaly detection module itself. It relies on the main TSM POZ application to provide lifecycle management, triggering, and interaction with CODAC services². The goal is to ensure that anomaly detection algorithms can be developed, deployed, and evolved independently, while remaining fully compatible with the architecture of the main TSM code.

2.1 Operational requirements and design constraints

The anomaly detection module targets engineering and operational instrumentation rather than plasma diagnostics. Algorithms operate on collections of multidimensional arrays acquired from TSM-monitored plant systems. These include one-dimensional time series from sensors, as well as sequences of images from visible or infrared cameras, spanning electrical, thermal, mechanical, and other engineering domains. While current implementations focus on time series data, future developments will extend to image-based methods, for instance for the detection of arcs and sparks.

The sampling frequencies of the monitored signals span several orders of magnitude. Slow-control variables acquired via EPICS [12] are typically sampled between 1 and 10 Hz, while archived signals and data retrieved using UDA³ may reach frequencies in the kHz range. The module must therefore adapt to heterogeneous temporal resolutions, variable-length time windows, and non-uniform sampling.

The execution of algorithms is driven by a unified time-based or EPICS-based triggering mechanism managed by the main TSM application. Consistent with the role of TSM as a monitoring (i.e., non-protection-related) system, the anomaly detection module does not perform strict real-time processing. Depending on the specific algorithm, the execution can therefore either occur in quasi-real-time during operation, or in an intershot context, as some analyses require access to the complete time evolution of a pulse to run. All algorithms are therefore treated uniformly from the point of view of the anomaly detection module, regardless of their specific core implementation or intended use case.

Each anomaly detection instance typically processes between a few and a few hundred input variables. The design must therefore accommodate both low-dimensional detectors and higher-dimensional algorithms exploiting correlations across multiple signals.

Finally, because ITER is not yet operational and the need for anomaly detection algorithms is expected to evolve, the module has been designed to be deliberately flexible. The architecture avoids hard assumptions on the number of signals, execution frequency, or algorithmic paradigm, allowing the module to evolve seamlessly as new monitoring needs arise and new methods are developed. This emphasis on flexibility and maintainability will be further discussed in the following sections.

2.2 Interfaces with the TSM plant operation zone application

The anomaly detection module interfaces with the main TSM application, which is implemented primarily in C++ and provides the runtime environment for all subsequent monitoring algorithms. Within this architecture, anomaly detection algorithms are executed as part of MonApp (Monitoring Application) instances, which are the basic execution units managed by the main application.

Each MonApp is responsible for: (i) detecting trigger events, (ii) acquiring and preprocessing input data, (iii) executing the monitoring algorithm, and (iv) publishing the results through the configured output interfaces. The anomaly detection module is mainly responsible for the algorithm execution step, while the surrounding MonApp infrastructure handles triggering, data access, and publication.

At the interface between the main C++ application and any algorithm implemented in TSM (beyond anomaly detection alone), an AlgorithmAdapter class plays a crucial role: it acts as a translation and orchestration layer. It receives standardized input structures from the application, validates them, and reshapes them when necessary to match the requirements of the algorithm implementation. This adapter ensures that all algorithms managed by TSM can be executed seamlessly, regardless of whether they are written in C++, Python, MATLAB, or another supported language. This design abstracts away language-specific details, allowing the main application to interact with all algorithms through a uniform interface.

At the level of the anomaly detection module, all algorithms are implemented in Python and executed in separate processes, each with its own Python interpreter. This design avoids limitations related to shared interpreter state and allows multiple algorithms to run concurrently. The corresponding AlgorithmAdapter for Python manages communication between the main C++ application and the Python process via an XML-RPC mechanism. This mechanism enables the exchange of structured data between both languages through HTTP, without requiring complex Python-C++ bindings.

From the perspective of the Python module, input data are provided as a collection of numerical arrays organized in a dictionary structure. Each signal is identified by name and associated with its time base and sampled values. This format is independent of the data acquisition source and allows algorithms to operate uniformly on streamed EPICS data, transported over the Plant Operation Network (PON)⁴, or on archived data retrieved through UDA.

Algorithm outputs are returned using a predefined AnomalyResult dataclass, which defines a standardized set of fields describing the detection outcome. This structure is directly convertible to a Python dictionary, can be serialized transparently through the XML-RPC interface, and is ingestible by the main C++ application. The output format is compatible with EPICS PVAs and with streaming to DAN⁵, enabling integration with operator interfaces and downstream monitoring components.

A schematic overview of the interaction between the main TSM application and the Python anomaly detection module is provided in Figure 1.

FIGURE 1

2.3 Internal structure and execution model

A central design objective of the anomaly detection module is the separation between a stable software development kit (SDK) and a rapidly evolving catalogue of algorithms. This separation preserves long-term stability of interfaces, data structures, and execution semantics, while allowing frequent iteration on detection methods without impacting the surrounding POZ infrastructure. To implement this design, the module is organized into two Python packages: tsmadkit (TSM Anomaly Detection Kit) and tsmadalg (TSM Anomaly Detection Algorithms).

The tsmadkit package provides the core SDK and defines the execution contract that all anomaly detection algorithms must satisfy. At the core of this package is the abstract base class AnomalyDetection, which specifies the minimal interface required for algorithm integration. This interface mirrors the lifecycle expected by the algorithm adapter and includes configuration handling, initialization, execution, standardized logging, and the production of a unified output structure via the AnomalyResult dataclass. By centralizing these responsibilities, the SDK enforces consistent behavior across algorithms.

The tsmadalg package contains concrete implementations of anomaly detection algorithms. It depends exclusively on tsmadkit for abstract interfaces and shared utilities, while isolating algorithm-specific logic, dependencies on external artifacts such as pre-trained ML models, and experiment-specific assumptions from the core infrastructure. Algorithms are discovered and registered dynamically based on their package structure and configuration files, allowing new detectors to be deployed without changes to the main TSM application.

A key aspect of this design is the use of a structured, configuration-driven approach based on JSON files. Each anomaly detection algorithm is instantiated from a configuration that specifies its identity and the set of input signals it operates on. These signals may optionally be divided into target signals, on which anomalies are detected, and context signals, which provide additional information to the model. When required, the configuration also defines how trained models, parameters, and auxiliary artifacts are loaded. An example of such configuration file can be found in Appendix A. The configuration is validated at instantiation time against a strict JSON Schema embedded in the SDK, ensuring that all algorithms expose a consistent and self-describing interface, while algorithm parameters are automatically mapped to instance attributes. This minimal yet expressive structure supports a wide range of ML-based methods, from unsupervised, data-driven detectors to supervised or semi-supervised approaches relying on external models, as well as both binary and multiclass anomaly classification through optional class definitions. By decoupling configuration from implementation, the same detection logic can be reused across multiple algorithm instances with different configurations. This enables scalable deployment on replicated or structurally similar subsystems, while preserving a uniform execution contract and reproducible behavior.

Each AnomalyDetection instance follows a two-phase lifecycle consisting of a setup phase and an execution phase. The setup() method is invoked once to perform algorithm-specific initialization, such as loading pre-trained models, initializing buffers, or preparing reference data. By default, setup() supports loading models from common ML frameworks (e.g., scikit-learn or TensorFlow) based on the configuration file, while more complex or custom initialization logic can be implemented by overriding this method when needed. This explicit initialization phase ensures that all required resources are prepared before the algorithm is used operationally.

The core detection logic is implemented in the detect() method, which is declared abstract in the base class and must therefore be implemented by all concrete algorithms. This method is called whenever the enclosing MonApp is triggered and receives pre-formatted input data corresponding to the signals declared in the configuration file. The detect() method returns an AnomalyResult object, which is subsequently converted into a serializable structure by the SDK for consumption by the main C++ application. This structure minimizes the implementation burden for new algorithms and allows developers to focus on modeling rather than integration concerns. For example, a fully functional anomaly detection algorithm relying on a pre-trained model can be implemented with code as concise as the following:

Where self.model is automatically declared as an instance attribute during the setup() phase based on the configuration file.

The current architecture is intentionally permissive and does not restrict algorithms to single subsystems, since the input signals declared in the JSON configuration can be drawn from any plant system. In particular, it supports cross-system anomaly detection methods that exploit correlations between signals originating from different plant systems (e.g., tracing back stray radiations from heating systems to abnormal temperature profiles in vacuum vessel thermocouples). This flexibility is essential for capturing complex operational behaviors.

3 Anomaly detection algorithms

The following subsections present two representative machine-learning case studies implemented within the Tokamak Systems Monitor, illustrating how the anomaly detection module supports different monitoring needs across ITER subsystems. These initial developments cover complementary operating modes: (1) an intershot, pulse-level analysis designed to compare complete operational cycles, and (2) a time-localized, quasi-real-time approach aimed at detecting short-lived deviations during machine operation. Together, these case studies demonstrate how a common software framework accommodates diverse data characteristics, modeling assumptions, and anomaly definitions.

While these first implementations focus on electrical and thermal behaviors in power supplies and heating systems, the same framework is designed to extend to other subsystems and to higher-level observables produced by TSM, such as reconstructed forces, modal frequencies, or damping ratios. Monitoring such derived indicators opens the door to structural health monitoring approaches [9], [15], in which subtle deviations from nominal dynamic behavior can provide early warning of degradation mechanisms that are not directly observable at the sensor level.

3.1 Case study: intershot analysis of gyrotron collector pulses

As a representative application of an intershot anomaly detection algorithm implemented within TSM, we consider the analysis of the thermal behavior of the gyrotron collector whose surface is instrumented with multiple thermocouples. The objective of this algorithm is to compare complete pulses acquired under different operating conditions and to identify those that deviate from the dominant, nominal thermal behavior. A detailed description of the dataset, feature engineering choices, parameter selection, and representative results for this gyrotron collector application is provided in a dedicated study [16]. The following summarizes the main modeling steps and illustrates representative results.

Each gyrotron pulse consists of a set of temperature time series recorded by multiple thermocouples distributed over the collector surface. Since pulse durations can vary significantly, direct comparison of raw time series is impractical. Instead, each pulse is transformed into a fixed-size representation using time-independent statistical features extracted from each signal. In practice, a feature extraction library for time series is applied independently to each thermocouple signal, and the resulting features are concatenated to form a single vector describing the pulse as a whole. This representation allows pulses of different lengths to be compared consistently, while capturing key aspects of their thermal evolution.

The resulting feature vectors are first standardized to account for differences in scale between features. To improve robustness and reduce redundancy, simple feature selection steps are applied, including the removal of low-variance features and features strongly correlated with pulse duration. This ensures that the anomaly detection focuses on waveform shape and thermal behavior rather than trivial differences in pulse length.

Dimensionality reduction is then performed using principal component analysis (PCA) [17], projecting the data into a low-dimensional space that retains most of the variance of the original feature set. In this reduced space, pulses exhibiting nominal behavior tend to form a compact cluster, reflecting the strong similarity of their thermal profiles. An illustrative example of the resulting low-dimensional representation, together with representative thermal profiles of nominal and anomalous pulses, is shown in Figure 2.

FIGURE 2

Anomaly detection is finally carried out using the DBSCAN clustering algorithm [18]. In this context, DBSCAN is used as a density-based method that explicitly distinguishes between samples belonging to dense regions of the feature space (clusters) and samples classified as noise. The latter are, by construction, points that do not belong to any sufficiently populated region and are therefore interpreted here as anomalous with respect to the dominant pulse behaviors. The dominant cluster in Figures 2a is interpreted as representing nominal pulses, while samples labeled as noise or located in low-density regions are flagged as anomalous.

Importantly, this formulation does not rely on outliers forming identifiable clusters. On the contrary, isolated behaviors are expected to remain unclustered and are directly captured through the noise label of DBSCAN. If similar anomalous behaviors become recurrent, they naturally form their own dense region and are then identified as a separate cluster, which may correspond to a new operating regime or to a specific class of recurrent faults.

Pulses flagged as outliers in the reduced feature space exhibit clear deviations in their global thermal profiles compared to nominal pulses. This unsupervised, density-based approach is well suited to early operational phases, where labeled data are not yet available. It provides a pragmatic criterion to distinguish common from atypical pulse behaviors in the absence of ground truth. In the dedicated study, the robustness of the DBSCAN-based separation was assessed through parameter-sensitivity analyses. The identified outliers showed over 90% overlap with those obtained using Isolation Forest [19], supporting the consistency of the detected atypical pulses. Further details on the methodological choices, parameter selection, and quantitative performance are provided in Reference [16].

3.2 Case study: time-localized monitoring of magnet power supplies

In contrast to intershot methods, some subsystems require continuous monitoring with precise temporal localization of anomalous behavior. This is for instance the case for magnet power supplies, where short-lived voltage deviations may indicate off-normal conditions.

For this application, a probabilistic, model-informed anomaly detection approach based on a conditional invertible neural network (CINN) is employed [20]. CINNs belong to the broader class of normalizing flow models [21], which learn an invertible transformation between a complex data distribution and a simple, tractable latent distribution. In the present case, the CINN models the conditional probability density of measured power supply voltages given the operational context. Specifically, the model learns a bijective mapping:where denotes a time window of measured voltages, the corresponding outputs of a physics-based Simulink model, and the actuator commands. The latent variable is constrained to follow a standard multivariate normal distribution, , under nominal operating conditions. Thanks to the invertibility of the transformation, the conditional likelihood can be evaluated explicitly using the change-of-variables formula.

The Simulink model is executed as a standalone algorithm in TSM, using the actuator commands as input to simulate the corresponding voltages needed by the CINN. The outputs of this model, together with the actuator commands and measured voltages , form the input set for the CINN.

At the time of this study, experimental voltage measurements from ITER magnet power supplies were not yet available. To demonstrate the feasibility of the approach and validate the detection pipeline, synthetic measured voltages were therefore generated from the simulated signals. This was achieved by applying controlled nonlinear distortions and additive noise to the simulated voltages according to:where denotes Gaussian noise scaled by a constant , and and are smooth sigmoid functions parameterized by constants and that introduce amplitude-dependent and dynamics-dependent nonlinearities, respectively. These perturbations emulate typical measurement effects such as gain nonlinearities, response distortions under rapid transients, and sensor noise, while remaining controlled and reproducible. Although such synthetic modifications do not fully capture the complexity of real measurement distributions, they provide a practical approximation for validating the end-to-end anomaly detection pipeline in the absence of experimental data. These synthetically corrupted signals were used as for training and inference, while preserving full control over the nature and timing of the introduced deviations.

During inference, time-series data are processed in a sliding-window fashion with repeated calls to the detect() method. For each time window, the negative log-likelihood (NLL) of the measured voltages under the learned conditional distribution,is computed and used as a continuous, time-resolved anomaly score. Large NLL values indicate that the observed measurements are unlikely given the current operating context and are therefore interpreted as anomalous, triggering further analysis.

Indeed, a key advantage of the CINN-based formulation is that the invertibility of the model enables a direct interpretation of such detections in the physical signal space. When an anomalous time window is identified, the corresponding latent representation lies in a low-probability region of the reference distribution. By sampling multiple latent vectors and propagating them backward through the inverse transformation,the model generates an ensemble of expected voltage realizations conditioned on the same operational context. Averaging these inverse predictions yields an estimate of the nominal expected signal, while their dispersion provides an empirical uncertainty bound. This allows the deviation of the measured voltages from their expected behavior to be quantified directly in voltage space, offering a more intuitive and actionable interpretation than the NLL value alone.

An illustrative example of time-localized anomaly detection is shown in Figure 3 for the power supply of poloidal field coil #6. For clarity, only one representative power supply is shown here, although the CINN model was trained using data from all 12 magnet power supplies of the Simulink model and applied to each of them during inference. Figures 3a shows that an injected voltage deviation remains subtle in the raw signal, yet becomes clearly identifiable when compared against the CINN-reconstructed expected behavior and its associated uncertainty envelope shown in the inset. While the corresponding residuals between measured and simulated voltages in Figures 3b increase locally, their amplitude alone is not sufficient to reliably distinguish anomalous behavior from normal operating variability using simple thresholding. In contrast, the probabilistic formulation leads to a pronounced and well-localized peak in the negative log-likelihood shown in Figures 3c, enabling robust detection of the deviation with precise temporal localization. This illustrates how the CINN-based approach naturally accounts for regime-dependent behavior and modeling uncertainties, thereby reducing false positives compared to residual-based criteria and providing anomaly detection results that can be directly exploited by the TSM.

FIGURE 3

4 Toward operational deployment and continuous improvement

The anomaly detection methods discussed in this work are intended to operate within a long-lived and evolving experimental environment, where operating conditions, available signals, and expected behaviors change over time. In this context, the primary challenge–beyond the performance of individual algorithms–is their ability to be deployed, executed, maintained and progressively refined throughout commissioning and operation.

From a computational perspective, the anomaly detection methods presented in this work are designed to be lightweight and compatible with standard workstation environments. For the intershot gyrotron collector analysis presented in Section 3.1, the full pipeline (feature extraction, preprocessing, PCA, and DBSCAN) requires approximately 15 s on a single CPU core, and can be reduced to under 1 s per pulse when leveraging feature caching and parallelization. For the time-localized monitoring of magnet power supplies presented in Section 3.2, the CINN model (approximately 46 k parameters) processes 1 s of multivariate signals sampled at 1 kHz in about 25 m on CPU using batched inference, enabling operation well above real-time requirements. These figures are indicative of the computational footprint of individual algorithms, and the overall resource requirements of the TSM will depend on the final number and nature of deployed algorithms for all monitored systems.

To address the challenges posed by an evolving experimental environment, the TSM anomaly detection module enforces a standardized execution model and output structure across all algorithms. Each detector produces anomaly events following a common schema, with optional fields such as time localization, severity indicators, or contributing signals when available. This abstraction allows fundamentally different detection approaches (i.e., supervised vs. unsupervised and time-localized vs. intershot) to coexist within a single framework and ensures that algorithms can be compared, replaced, or updated without modifying the surrounding infrastructure.

During early operational phases, anomaly detection will necessarily be dominated by unsupervised or weakly supervised approaches due to the limited availability of labeled data. As commissioning progresses, expert feedback on detected anomalies is expected to progressively accumulate and enable recalibration of thresholds, retraining of models, or replacement of algorithms within the same standardized framework. This feedback loop relies on a dedicated anomaly event database, which serves as the persistence layer for detection results and expert annotations. While this database and the associated expert interaction workflows have been prototyped, their full operational deployment lies outside the scope of this paper. In practice, these interactions–including event review, validation, cross-algorithm comparison, and longer-term performance monitoring–will be performed through a dedicated data analysis HMI in XPOZ⁶. The overall data analysis strategy and supporting tools developed for TSM are described in a forthcoming companion paper [22].

Robustness to changes in operational regime is another central consideration. The performance of models trained on limited operating conditions may degrade as new regimes are explored, such as changes in plasma current or pulse duration. The modular structure of the anomaly detection framework allows multiple detectors to coexist for the same system, each tailored to specific assumptions or regimes, and to be activated or retired without disrupting the surrounding infrastructure.

From a broader perspective, this progressive deployment, monitoring, and refinement cycle aligns with established machine learning operations (MLOps) practices [23], in which models are continuously evaluated and adapted after deployment rather than treated as static artifacts. In such a context, monitoring the performance of anomaly detection algorithms over time, together with indicators of data drift and concept drift, is essential to ensure their continued relevance as operating conditions evolve. While a full MLOps pipeline–encompassing automated performance tracking, drift detection, and retraining workflows–is not yet implemented within TSM, the current design of the anomaly detection module explicitly anticipates this evolution by enforcing stable interfaces, versioned algorithms, and standardized outputs. The definition and integration of these MLOps mechanisms will be the focus of future work as operational data becomes available and monitoring needs mature.

Finally, care must be taken to ensure that automated anomaly detection supports, rather than overwhelms, operators. The module is explicitly designed to generate early warnings rather than safety-critical alarms, allowing conservative thresholds to be used initially with a focus on sensitivity and interpretability. As confidence in individual algorithms increases, their outputs may be progressively integrated into higher-level decision logic, subject to validation and operational approval.

Taken together, these considerations highlight that effective anomaly detection in ITER is not a one-time modeling task, but an ongoing process. The architecture presented here is intended to provide a stable foundation on which anomaly detection methods can be deployed, assessed, and improved throughout the lifetime of the project.

5 Conclusion

This work has presented the design and current implementation of the machine learning-based anomaly detection module within the ITER Tokamak Systems Monitor software. Rather than focusing on algorithmic novelty or benchmark performance, the emphasis has been on the practical problem of integrating heterogeneous anomaly detection methods into a unified, operational monitoring framework suitable for a large fusion facility.

The two case studies illustrate complementary roles that anomaly detection is expected to play in ITER. The clustering-based intershot algorithm provides a capability to identify atypical operational cycles without prior labeling, while the time-localized, probabilistic CINN-based algorithm enables the detection of transient deviations during operation using model-informed approaches. Together, they demonstrate how fundamentally different methods can be deployed under a common execution and output model.

A central conclusion of this work is that the long-term effectiveness of anomaly detection in ITER will depend less on any individual algorithm than on the surrounding software infrastructure. Standardized interfaces, reproducible execution, and clearly defined anomaly outputs are essential to allow algorithms to evolve, be replaced, or coexist as operating regimes change and new data become available. This perspective is particularly important in a pre-operational context, where ground truth is limited and anomaly detection strategies must remain adaptable.

The framework presented here provides a foundation for deploying, evaluating, and refining anomaly detection methods throughout commissioning and early operation. Future efforts will focus on extending coverage to additional systems, exploiting expert feedback to guide model evolution, and progressively increasing the operational role of anomaly detection as confidence in the methods grows.

References

• 1.

  SkiltonRGaoY. Combining object detection with generative adversarial networks for in-component anomaly detection. Fusion Eng Des (2020) 159:111736. 10.1016/j.fusengdes.2020.111736

  • CrossRef
  • Google Scholar
  • View reference in article

• 2.

  AnandHSammuliBSOlofssonKEJHumphreysDA. Real-time magnetic sensor anomaly detection using autoencoder neural networks on the DIII-D tokamak. IEEE Trans Plasma Sci IEEE Nucl Plasma Sci Soc (2022) 50:4126–30. 10.1109/tps.2022.3181548

  • CrossRef
  • Google Scholar
  • View reference in article

• 3.

  GrelierEMitteauRMoncadaV. Deep learning-based process for the automatic detection, tracking, and classification of thermal events on the in-vessel components of fusion reactors. Fusion Eng Des (2023) 192:113636. 10.1016/j.fusengdes.2023.113636

  • CrossRef
  • Google Scholar
  • View reference in article

• 4.

  GorseVMitteauRMarotJ. Anomaly classification by inserting prior knowledge into a max-tree based method for divertor hot spot characterization on WEST tokamak. Rev Scientific Instr (2023) 94:083510. 10.1063/5.0156956

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 5.

  GorseVGrelierEMoncadaVMitteauR. Real-time monitoring system for detection and characterization of thermal events on WEST tokamak: implementation and first results. Fusion Eng Des (2025) 215:114960. 10.1016/j.fusengdes.2025.114960

  • CrossRef
  • Google Scholar
  • View reference in article

• 6.

  BattyeMIPerinpanayagamS. Digital twins in fusion energy research: current state and future directions. IEEE Access (2025) 13:75787–821. 10.1109/ACCESS.2025.3561920

  • CrossRef
  • Google Scholar
  • View reference in article

• 7.

  MaquedaLAlmenaraJPiñeiroDRodríguezERuedaFYáñezAet alFeasibility evaluation and pre-conceptual design of the ITER tokamak systems monitor. Fusion Eng Des (2023) 188:113435. 10.1016/j.fusengdes.2023.113435

  • CrossRef
  • Google Scholar
  • View reference in article

• 8.

  VilloneFIserniaNRubinacciGVentreSIglesiasDMaquedaLet alReconstruction of electromagnetic loads during disruptions in ITER. Nucl Fusion (2025) 66:016030. 10.1088/1741-4326/ae1b1a

  • CrossRef
  • Google Scholar
  • View reference in article

• 9.

  ParetJIglesiasDBakHCloughMVayakisGWalshM. Preliminary machine learning-based calibration strategy for the ITER tokamak systems monitor. Fusion Eng Des (2026) 222:115485. 10.1016/j.fusengdes.2025.115485

  • CrossRef
  • Google Scholar
  • View reference in article

• 10.

  StepanovDArtemevKKumarDLangeRLobesLMocquardXet alProgress with remote participation tools in ITER control system. Fusion Eng Des (2025) 211:114787. 10.1016/j.fusengdes.2024.114787

  • CrossRef
  • Google Scholar
  • View reference in article

• 11.

  LiuGMakijarviPPonsN. The ITER CODAC network design. Fusion Eng Des (2018) 130:6–10. 10.1016/j.fusengdes.2018.02.072

  • CrossRef
  • Google Scholar
  • View reference in article

• 12.

  KnottMGurdDLewisSThuotM. EPICS: a control system software co-development success story. Nucl Instr Methods Phys Res Section (1994) 352:486–91. 10.1016/0168-9002(94)91577-6

  • CrossRef
  • Google Scholar
  • View reference in article

• 13.

  CastroRMakushokYAbadieLVegaJ. Large-scale indexing system for iter data handling. Fusion Eng Des (2026) 224:115577. 10.1016/j.fusengdes.2025.115577

  • CrossRef
  • Google Scholar
  • View reference in article

• 14.

  CastroRAbadieLMakushokYRuizMSanzDVegaJet alData archiving system implementation in ITER’s CODAC core system. Fusion Eng Des (2015) 96-97:751–5. 10.1016/j.fusengdes.2015.06.076

  • CrossRef
  • Google Scholar
  • View reference in article

• 15.

  FarrarCRWordenK. An introduction to structural health monitoring. Philos Trans A Math Phys Eng Sci (2007) 365:303–15. 10.1098/rsta.2006.1928

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 16.

  ParetJIglesiasDSabio RuizDMeloniDAntonioneABertazzoniRet alMachine learning-based anomaly detection for ITER’s tokamak systems monitor: a gyrotron case study. TechRxiv (2025). 10.1109/TPS.2026.3670510

  • CrossRef
  • Google Scholar
  • View reference in article

• 17.

  GewersFLFerreiraGRArrudaHFDSilvaFNCominCHAmancioDRet alPrincipal component analysis: a natural approach to data exploration. ACM Comput Surv (2021) 54:1–34. 10.1145/3447755

  • CrossRef
  • Google Scholar
  • View reference in article

• 18.

  EsterMKriegelHPSanderJXuX. A density-based algorithm for discovering clusters in large spatial databases with noise. In: Proceedings of the second international conference on knowledge discovery and data mining (AAAI press), 96 (1996). p. 226–31.

  • Google Scholar
  • View reference in article

• 19.

  LiuFTTingKMZhouZH. Isolation forest. In: Proceedings of the 2008 eighth IEEE international conference on data mining (USA: IEEE computer society). Pisa, Italy: IEEE (2008) p. 413–22. 10.1109/ICDM.2008.17

  • CrossRef
  • Google Scholar
  • View reference in article

• 20.

  Anantha PadmanabhaGZabarasN. Solving inverse problems using conditional invertible neural networks. J Comput Phys (2021) 433:110194. 10.1016/j.jcp.2021.110194

  • CrossRef
  • Google Scholar
  • View reference in article

• 21.

  KobyzevIPrinceSJDBrubakerMA. Normalizing flows: an introduction and review of current methods. IEEE Trans Pattern Anal Machine Intelligence (2021) 43:3964–79. 10.1109/TPAMI.2020.2992934

  • Pubmed Abstract
  • CrossRef
  • Google Scholar
  • View reference in article

• 22.

  IglesiasDMoncadaVParetJAbadieLNunesISabio RuizDet alData analysis strategy for the ITER tokamak systems monitor. Front In Phys (Forthcoming) (2024).

  • Google Scholar
  • View reference in article

• 23.

  KreuzbergerDKühlNHirschlS. Machine learning operations (mlops): Overview, definition, and architecture. IEEE Access (2023) 11:31866–79. 10.1109/ACCESS.2023.3262138

  • CrossRef
  • Google Scholar
  • View reference in article