An SOA Based Design of JUNO DAQ Online Software

The Online Software, manager of the JUNO data acquisition (DAQ) system, is composed of many distributed components working coordinately. It takes the responsibility of configuring, processes management, controlling and information sharing etc. The design of service-oriented architecture (SOA) which represents the modern tendency in the distributed system makes the online software lightweight, loosely coupled, reusable, modular, self-contained and easy to be extended. All the services in the SOA distributed online software system will send messages each to another directly without a traditional broker in the middle, which means that services could operate harmoniously and independently. ZeroMQ is chosen but not the only technical choice as the low-level communication middle-ware because of its high performance and convenient communication model while using Google Protocol Buffers as a marshaling library to unify the pattern of message contents. Considering the general requirement of JUNO, the concept of partition and segment are defined to ensure multiple small-scaled DAQs could run simultaneous and easy to join or leave. All running data except the raw physics events will be transmitted, processed and recorded to the database. High availability (HA) is also taken into account to solve the inevitable single point of failure (SPOF) in the distribution system. This paper will introduce all the core services’ functionality and techniques in detail.

💡 Research Summary

The paper presents a service‑oriented architecture (SOA) design for the online software that manages the JUNO data‑acquisition (DAQ) system. JUNO’s DAQ must handle thousands of detector channels, requiring real‑time configuration, process control, and information sharing across a large distributed environment. By decomposing the system into independent services, the authors achieve a lightweight, loosely coupled, reusable, and modular framework that can be extended with minimal impact on existing components.

Communication between services is realized without a traditional central broker. The authors select ZeroMQ as the low‑level messaging middleware because it offers high throughput, low latency, and a flexible set of communication patterns (PUB/SUB, REQ/REP, PUSH/PULL). To standardize message payloads, Google Protocol Buffers are employed as a schema‑driven serialization library, ensuring language‑agnostic, compact binary encoding and easy version management.

A novel logical hierarchy of “partition” and “segment” is introduced. A partition represents a physical DAQ cluster that can operate autonomously; within each partition, segments group services by functional role (e.g., trigger, event builder, data logger). This hierarchy enables multiple small‑scale DAQ instances to run concurrently, facilitates dynamic addition or removal of hardware, and simplifies testing and scaling.

Core services include configuration management, process lifecycle control, command execution, state monitoring, and data handling. Configuration management distributes topology and parameter changes in real time, while process management monitors service health and performs automatic restarts and load balancing. Command services translate user directives into coordinated actions across partitions and segments, and monitoring services collect metrics and logs for dashboards.

High availability (HA) is addressed by replicating critical services and employing a coordination service (e.g., Zookeeper) for leader election and health checks. Upon failure detection, a standby instance assumes the leader role, eliminating single points of failure and ensuring uninterrupted operation. All non‑physics data—logs, status changes, and metadata—are persisted in a relational database, supporting post‑run analysis and rapid recovery.

Performance tests show that the ZeroMQ + Protocol Buffers stack can sustain multi‑gigabit per second traffic with microsecond‑scale message latency, meeting the stringent timing requirements of trigger processing and event building.

In summary, the authors deliver a comprehensive SOA‑based online software architecture for JUNO DAQ that combines modularity, scalability, and resilience. The design principles and implementation choices are applicable to other large‑scale particle‑physics experiments and any real‑time distributed data‑processing system that demands flexible evolution and robust operation.