Source-linked AI summary
A packet-level digital hardware twin for commissioning megahertz diagnostic edge AI and plasma control system integration in tokamaks
Semin Joung, Abhilasha Dave, Luca Scomparin, Filipp Khabanov, Zheng Yan, Benedikt Geiger, George McKee, Ryan N. Coffee, David R. Smith
TL;DR
Commissioning megahertz diagnostic-to-control paths is difficult because acquisition, transport, inference, and control handoff must work together. This paper builds a packet-level digital hardware twin to exercise those interfaces and fault paths. Its tests verify software continuity and fault propagation, with latency results based on a configured engineering model.
Problem
Commissioning is difficult because the complete path from high-rate diagnostic sampling through transport and inference to control-system handoff must be engineered across interacting interfaces.
Source: §1 · p. 1Method
Results
91.6 µs median and 108.1 µs 99th-percentile configured latency; the test also detected one dropped packet, invalidated two overlapping windows, and preserved sequence and CRC for 20/20 result packets.
Source: §7 · p. 8Takeaways & Limitations
The framework lets system integration begin while the final FPGA bitstream, receiver process, and PCS schema are still being finalized.
Source: §7 · p. 8The synthetic BES source and logistic ELM surrogate exercise interfaces but do not establish predictive performance.
Source: §6.3 · p. 7
Abstract
from arXiv · showhide
High-bandwidth plasma diagnostics increasingly provide inputs to machine learning and signal-processing algorithms intended for real-time tokamak control, but the complete path from diagnostic sampling to control-system handoff is difficult to commission because of their sampling rates. We develop a packet-level digital hardware twin for the megahertz diagnostic edge-AI architecture. The simulator represents a 64-channel, 1 MHz beam emission spectroscopy (BES) diagnostic embedded in a 96-channel dual-carrier acquisition system, two 48-channel streams with SPAD0 sample counters, 10 GbE Hardware UDP transport, packet loss and network jitter, FPGA parsing and dual-carrier alignment, causal preprocessing and edge inference, a compact Ethernet result packet, receiver-side shared state, and a 1 kHz PCS-like control cycle. Binary UDP payloads and PCAP files are generated rather than emulating transport only at the array level. With a baseline of 20 samples per packet, each carrier generates 50,000 packets s$^{-1}$ and 100 MB s$^{-1}$ of user payload. A 110 ms reference run produces 11,000 HUDP packets; an intentionally dropped 20-sample packet is detected by the sample-counter continuity logic and invalidates the two overlapping 128-sample inference windows without silent interpolation. For valid windows, the configured engineering latency model gives a median last-input-to-shared-memory latency of 91.6 us and a 99th percentile of 108.1 us. A separate operating-system loopback test sends binary FPGA-result datagrams through a UDP receiver into POSIX shared memory and preserves packet sequence and CRC for 20/20 packets. Interactive GUI interfaces expose timing, packetization, network faults, inference thresholds, and control-state inspection. The framework provides a reproducible environment for testing diagnostic-to-accelerator interfaces and fail-safe behavior for deployment on fusion devices.
1. Introduction
Megahertz diagnostics and machine-learning observers are increasingly relevant to real-time tokamak control, but commissioning requires the acquisition-to-control path to work as a complete deterministic system. This work develops a DIII-D-oriented engineering environment for exercising that path across hardware and software interfaces.
1. Introduction
- Real-time control increasingly needs high-dimensional diagnostics sampled above conventional control-cycle rates, while ML observers can reduce measurements to compact state estimates for feedback.The acquisition, transport, inference, and control handoff must operate as a complete deterministic path.Source: §1 · p. 1
- The DIII-D SHIELD framework integrated high-bandwidth diagnostics with PCS, and full-resolution real-time BES was reported to agree with corresponding off-line data.That work also emphasized local FPGA processing for submillisecond quantities.Source: §1 · p. 1
- Commissioning risk spans interacting interfaces, from clock and trigger interpretation through packet continuity and FPGA window validity to receiver stale-state detection and controller fail-safe behavior.Testing only the ML model or network bandwidth does not expose failures emerging from interactions among these layers.Source: §1 · p. 1
- The engineering baseline models two 48-channel ACQ2206-class carriers with 10 GbE HUDP transport, providing 96-channel capacity, of which 64 channels are assigned to BES.SPAD0 sample counters support recovery of data position and identification of missing samples.Source: §1 · pp. 1–2
- The digital hardware twin is an executable model of planned data, timing, packet, accelerator, and control interfaces, while synthetic plasma and observer components exercise downstream interfaces and controller transitions.The paper frames its principal contribution as an engineering commissioning environment.Source: §1 · p. 2
- The simulator links binary dual-carrier HUDP packetization, fault propagation through inference and control, versioned result packets, process-level loopback, and interactive commissioning frontends.It also quantifies baseline packet rates, fault detection, and configured latency while identifying interfaces still needing measured hardware behavior.Source: §1 · p. 2
2. DIII-D reference architecture and simulator boundary
The paper positions its simulator alongside DIII-D's deployed SHIELD infrastructure while distinguishing the proposed HUDP diagnostic-to-accelerator path from that existing acquisition path. It models the end-to-end path and distinguishes established quantities from adjustable engineering choices and simulator-only placeholders.
2.1. Existing DIII-D real-time diagnostic infrastructure
- SHIELD provides modular real-time acquisition, shared-memory transport, specialized processing nodes, and PCS integration for several diagnostics.Its ring buffers allow PCS to read diagnostic data at its own cycle rate, establishing relevance and feasibility for high-bandwidth diagnostic control on DIII-D.Source: §2.1 · p. 2
- The proposed path uses external HUDP transport rather than the AICC/SHIELD acquisition path, so the architectures are compared by function rather than assumed to share hardware.Both keep high-rate diagnostics outside central PCS until reduction to a compact control-relevant state; this simulator focuses on D-TACQ-to-FPGA transport and the PCS-facing handoff.Source: §2.1 · p. 2
2.2. Modeled hardware topology
- The modeled topology carries synthetic BES voltages through electronics, ADC quantization, two acquisition carriers and independent HUDP links to FPGA alignment, preprocessing, inference, and PCS-facing shared state.The receiver writes state for a 1 kHz control task; recording, PCAP capture, and replay are parallel support functions, not part of the hard real-time path.Source: §2.2 · p. 2
- The model separates publicly documented or project-grounded quantities from sweepable engineering choices and explicit simulator-only placeholders.This fidelity distinction is maintained throughout the software and exposed in the GUI.Source: §2.2 · p. 2
3. Full-system simulator
The simulator models a megahertz BES path from synthetic signal generation through dual-carrier acquisition and FPGA processing to PCS-facing shared state. It exercises packet faults, inference-window validity, and both event-driven and process-level execution.
3.1. Synthetic BES and ADC representation
- The 64-channel synthetic BES signal uses physics-motivated fluctuations and detector noise, not a first-principles turbulence simulation.It is sampled at 1 MHz and quantized into signed 16-bit codes; the active channels sit within a 96-channel hardware vector.Source: §3.1 · p. 2
3.2. Dual-carrier HUDP packetization and timing
- At 1 MSPS, the 20-sample-per-packet baseline produces 50,000 packets s−1 per carrier and 100 MB s−1 of user payload per carrier.The model serializes ADC codes and SPAD words into Ethernet/IPv4/UDP frames and can export PCAP files.Source: §3.2 · p. 3
3.4. Causal preprocessing and edge inference
- The FPGA model aligns both carriers by sample counter, then applies causal bandpass preprocessing and evaluates windowed features for edge inference.The compact logistic surrogate is trained on synthetic event-schedule labels and is not a scientific ELM predictor.Source: §3.3 · p. 4, §3.4 · p. 4
3.3. Network impairments and dual-carrier reconstruction
- A dropped 20-sample packet invalidates exactly two overlapping 128-sample inference windows, with missing data propagated as validity rather than interpolated.The example drops counters 84000–84019 on carrier B; the windows use a stride of 64 samples.Source: §3.3 · p. 4
3.5. Versioned FPGA-to-PCS packet and shared state
- A versioned 64-byte PCS Packet v0 carries model outputs and health information; the receiver CRC-checks it and publishes valid writes to shared state.The 1 kHz PCS-like task considers state usable only when the latest write is CRC-valid and younger than a configurable timeout; stale state holds the previous actuator request in the baseline controller.Source: §3.5 · p. 4
3.6. Discrete-event and process-level execution modes
- The simulator offers fast discrete-event execution and an operating-system UDP/POSIX shared-memory mode that checks binary compatibility across process boundaries.The process-level mode does not reproduce hard-real-time scheduling.Source: §3.6 · p. 4
4. Verification and commissioning tests
The verification runs exercise packet throughput, loss propagation, configured latency, and PCS-facing handoff. They show how injected faults affect inference and control state, while the latency and virtual-plant results remain simulation outputs.
4.1. Baseline packet rate and continuity
- A 110 ms reference run generated 11,000 HUDP packets, with each carrier carrying 100 MB s−1 of user payload before Ethernet/IP/UDP overhead.The cited passage says this rate is below the documented 10 GbE capability and identifies packet-rate handling, counter continuity, and deterministic processing as the baseline commissioning issues.Source: §4.1 · p. 4
4.2. Injected packet drop
- Dropping one carrier-B packet invalidated two overlapping inference windows, and no samples were silently synthesized to repair the gap.The short fault did not force a PCS hold because later valid edge packets updated shared state before the next relevant control read; longer dropouts can test hold-last or idle policies.Source: Figure 2 · p. 5, §4.2 · p. 5
4.3. Configured latency budget
- 91.6 µs median and 108.1 µs 99th-percentile last-input-ready-to-shared-memory latency were configured for 1715 valid windows, not measured on hardware.The budget combines 42.5 µs of FPGA-side delays, a modeled result-Ethernet delay, and receiver decode plus shared-memory write; 128-sample context is separate from this latency.Source: §4.3 · p. 5, Figure 3 · p. 6
4.4. PCS-facing control state and process-loopback verification
- The virtual plant’s “mitigated” and “suppressed” labels are heuristic, while the separate localhost loopback preserved sequence and generation counters and passed CRC for 20/20 packets.The loopback verifies binary UDP transfer into POSIX shared memory, not deterministic real-time performance.Source: §4.4 · p. 6
5. Interactive commissioning interface
The interactive commissioning interface lets multiple engineering roles inspect and vary a shared configuration. It brings packet health, inference, timing, and controller behavior together without attempting to mimic the production PCS GUI.
5. Interactive commissioning interface
- The GUI exposes diagnostic duration and seed, packetization, network faults, FPGA processing and delays, PCS timing and fail-safe settings, and control thresholds.Time-scrub views include native 8 × 8 BES pixels and interpolated images and contours; inspectors show packet metadata, payloads, result fields, and CRC status.Source: §5 · p. 6
- The interface uses the same configuration and packet-processing functions but is an engineering commissioning surface, not a replica of the production DIII-D PCS graphical environment.It is intended to show packet health, inference state, timing, and controller behavior together before the facility GUI is available.Source: §5 · p. 6
6. Discussion
The discussion frames the simulator as an interface-contract and regression environment for a proposed D-TACQ-to-FPGA path, distinct from deployed DIII-D systems. It motivates packet-level alignment, outlines staged validation, and limits the current evidence to synthetic software testing and engineering models.
6.1. Relation to the deployed DIII-D framework
- The simulator is a complementary proposed D-TACQ-to-FPGA path, best used as an interface contract and regression environment rather than treated as the deployed DIII-D framework.Changes to packet, timing, preprocessing, receiver, or control interfaces can be tested across the complete chain.Source: §6.1 · p. 6
6.2. Why packet-level simulation is needed
- Packet-level simulation tests whether diagnostic windows remain scientifically aligned after carrier delays, packet faults, counter changes, or reordering.The simulator separates device-specific acquisition adapters from a reusable preprocessing and inference core for potential cross-machine deployment.Source: §6.2 · pp. 6–7
6.3. Hardware measurements
- The latency distribution is a configured engineering model that should be replaced with component-level FPGA, network, receiver, and PCS shared-state measurements.PCS Packet v0 is a versioned placeholder, not the final DIII-D receiver schema.Source: §6.3 · p. 7
- Synthetic plasma and heuristic virtual-plant responses exercise downstream interfaces and controller states, but do not establish predictive performance or plasma-control results.The reported “mitigated” and “suppressed” labels are simulator-only.Source: §6.3 · p. 7, Figure 4 · p. 7
- Validation proceeds from synthetic software regression to recorded-shot replay, physical-hardware bench testing, and PCS receiver/shared-memory testing without actuator authority before any control experiment.The staged sequence separates high-bandwidth processing from the deterministic safety-critical PCS core.Source: §6.3 · p. 7
- The commissioning tool supports reproducible comparisons of packet sizes, accelerator latencies, network paths, and fail-safe policies before procurement or machine time is committed.The interface brings packet health, inference state, timing, and controller behavior into one engineering view, rather than mimicking the production PCS GUI.Source: §6.3 · p. 8, Figure 5 · p. 8
7. Conclusion
The packet-level twin models the megahertz BES-to-control path, including acquisition, transport, FPGA processing, inference, and PCS-facing state. Tests demonstrate packet-loss propagation and software loopback continuity, while the framework is positioned to support integration before final hardware and schemas are available.
7. Conclusion
- The twin spans 64 active BES channels in a 96-channel dual-carrier system, from binary HUDP acquisition through inference and result packets to a 1 kHz virtual control cycle.It models independent link timing and faults, synchronized FPGA inputs, causal preprocessing, and receiver shared state.Source: §7 · p. 8
- A dropped 20-sample carrier packet was detected by counter continuity and invalidated the two overlapping 128-sample inference windows.The baseline 110 ms test generated 11,000 packets across the two carriers.Source: §7 · p. 8
- 91.6 µs median and 108.1 µs 99th-percentile last-input-to-shared-memory latency were modeled for valid windows; the loopback test preserved sequence and CRC for all 20 packets.The latency is from the configured engineering model; the separate test used UDP and POSIX shared memory.Source: §7 · p. 8
- The framework supports integration while the final FPGA bitstream, receiver process, and PCS schema are still being finalized, with recorded BES replay and physical packet captures identified as next steps.The proposed transition also substitutes the final DIII-D receiver/shared-memory contract.Source: §7 · p. 8