⚛️ Overview #
Large-scale scientific experiments such as nuclear fusion place extreme demands on real-time data acquisition, deterministic control, and system reliability. In 2007, researchers from the Institute of Plasma Physics at the Chinese Academy of Sciences presented a practical implementation of a QNX-based distributed acquisition and control system for the Lower Hybrid Current Drive (LHCD) subsystem of the Experimental Advanced Superconducting Tokamak (EAST).
Published in Nuclear Fusion and Plasma Physics (Vol. 27, No. 4), the work documents how field-level data acquisition nodes and a centralized control room were connected into a cohesive, real-time distributed system. Although nearly two decades old, the design principles remain highly relevant in 2025 for fusion research, industrial automation, and edge-based Industrial IoT systems.
🔬 EAST Tokamak and LHCD System Requirements #
EAST is a superconducting tokamak designed to study long-pulse, steady-state plasma operation—an essential step toward practical fusion energy. The LHCD subsystem plays a critical role by driving plasma current and improving confinement during long discharges.
Ahead of EAST’s early experimental campaigns in 2006, engineers needed a single-tube LHCD test platform to validate wave injection and subsystem behavior without full plasma operation. This imposed several technical requirements:
- Deterministic, real-time acquisition of voltage and current signals
- Distributed deployment to reduce latency and noise by placing acquisition close to hardware
- Centralized monitoring, visualization, and parameter configuration
- Remote startup and recovery to minimize manual intervention during experiments
Meeting these constraints required careful selection of both hardware and operating system.
🧠 RTOS Selection: Why QNX Was Chosen #
The authors evaluated several real-time operating systems, including VxWorks, WinCE, and VRTX, before selecting QNX. The decision was driven by several key strengths:
- Deterministic scheduling: QNX provides priority-based preemptive scheduling with configurable policies such as FIFO and round-robin, ensuring predictable response times for control tasks.
- Native distributed architecture: Unlike many RTOS options, QNX was designed from the ground up as a distributed operating system.
- Message-passing IPC: QNX’s microkernel uses synchronous message passing, simplifying inter-process communication while maintaining real-time guarantees.
- Qnet networking: Qnet allows multiple QNX nodes to appear as a single logical system, enabling transparent remote process execution and resource access.
Compared to alternatives, QNX offered the best balance between real-time performance and distributed system scalability, which was essential for the EAST LHCD setup.
⚙️ System Architecture and Network Design #
The system was divided into two logical domains connected via Ethernet:
Field-Level Nodes #
Field machines were industrial PCs running QNX and equipped with PCI-1710HG data acquisition cards. These cards provided:
- 12-bit analog-to-digital conversion
- Sampling rates up to 100 kS/s
- Multiple input channels for voltage and current signals
Each field node was responsible for:
- Initializing and configuring acquisition hardware
- Sampling data at fixed rates (e.g., 8 channels at 10 kHz)
- Storing acquired data locally to ensure integrity
- Executing parameter-based control logic, such as triggering outputs when thresholds were exceeded
Control Room Node #
The control room system provided a centralized interface for operators and engineers. Its responsibilities included:
- Parameter configuration and experiment setup
- Real-time waveform visualization
- Remote program startup and shutdown
- Monitoring field-node status and experiment progress
The graphical interface was developed using Photon Application Builder (PHAB), QNX’s native GUI toolkit. Widgets such as PtTrend were used for real-time waveform display, enabling operators to observe experimental signals as they were acquired.
🛠️ Software Implementation Details #
Communication Model #
The system combined multiple QNX communication mechanisms:
- TCP/IP sockets for parameter transfer and waveform streaming
- QNX message passing for local inter-process communication
- Qnet services for remote process execution and transparent access to field nodes
This hybrid approach balanced performance, flexibility, and ease of development.
Field Program Workflow #
Each field node followed a structured execution sequence:
- Receive configuration parameters from the control room
- Initialize PCI-1710HG hardware and sampling parameters
- Start real-time data acquisition
- Store raw data locally while streaming waveforms back for display
- Execute control logic based on measured values
- Report status and completion back to the control room
This design ensured that time-critical operations remained local, while supervisory tasks were centralized.
Remote Operation and Fault Handling #
One of the most valuable features of the system was its support for remote startup and recovery. Using Qnet, the control room could launch field executables, detect abnormal termination, and restart programs without physical access to experimental hardware—an important capability in high-voltage fusion environments.
🧪 Experimental Validation #
The system was deployed during EAST’s 2006 LHCD single-tube wave addition experiments. Test results demonstrated:
- Stable real-time acquisition at 10 kHz with no data loss
- Reliable remote control and monitoring over extended runs
- Fast startup and responsive status updates
- Continuous operation over multiple hours without system crashes
These results confirmed that the system met EAST’s strict real-time and reliability requirements.
🌍 Relevance and Lessons for 2025 #
While fusion technology has advanced significantly since 2007, the architectural ideas in this work remain highly applicable. Modern systems—ranging from fusion reactors to smart factories and energy grids—still rely on distributed real-time control at the edge.
This case study highlights enduring lessons:
- Place time-critical logic close to hardware
- Use distributed RTOS capabilities to simplify system design
- Separate real-time execution from supervisory control
- Favor message-based architectures for robustness and scalability
With QNX continuing to evolve as a safety-certified RTOS, these principles remain foundational for engineers building reliable distributed systems today.