A Comparative Analysis of the CERN ATLAS ITk MOPS Readout: A Feasibility Study on Production and Development Setups

TL;DR

The paper tackles the challenge of validating the ITk DCS MOPS readout for ATLAS by introducing a dedicated Readout Hub testbed to compare a Raspberry Pi–based prototype against a production FPGA-based MH, focusing on end-to-end latency and data integrity over a 125 kbit/s CANopen bus. It proposes a single-clock STM32-based measurement approach to achieve sub-10 microsecond timing uncertainty, plus a three-stage evaluation (Baseline, Full Crate Stress, CIC Isolation) to assess performance, scalability, and electrical isolation. The methodology includes a complete data-logging pipeline and explicit acceptance criteria (e.g., baseline mean latency $\leq 7~\mathrm{ms}$, full-crate latency targets of $\leq 3.3~\mathrm{ms}$ mean with $99.9^{\text{th}}$ percentile $\leq 7~\mathrm{ms}$). The work aims to produce a clear, reproducible qualification procedure for production deployment in the ATLAS ITk DCS, with results to be presented in a companion paper and future work extending to full crate end-to-end validation.

Abstract

The upcoming High-Luminosity upgrade of the Large Hadron Collider (LHC) necessitates a complete replacement of the ATLAS Inner Detector with the new Inner Tracker (ITk). This upgrade imposes stringent requirements on the associated Detector Control System (DCS), which is responsible for the monitoring, control, and safety of the detector. A critical component of the ITk DCS is the Monitoring of Pixel System (MOPS), which supervises the local voltages and temperatures of the new pixel detector modules. This paper introduces a dedicated testbed and verification methodology for the MOPS readout, defining a structured set of test cases for two DCS-readout architectures: a preliminary Raspberry Pi-based controller, the "MOPS-Hub Mock-up"(MH Mock-up), and the final production FPGA-based "MOPS-Hub" (MH). The methodology specifies the measurement chain for end-to-end latency, jitter, and data integrity across CAN and UART interfaces, including a unified time-stamping scheme, non-intrusive signal taps, and a consistent data-logging and analysis pipeline. This work details the load profiles and scalability scenarios (baseline operation, full-crate stress, and CAN Interface Card channel isolation), together with acceptance criteria and considerations for measurement uncertainty to ensure reproducibility. The objective is to provide a clear, repeatable procedure to qualify the MH architecture for production and deployment in the ATLAS ITk DCS. A companion paper will present the experimental results and the comparative analysis obtained using this testbed.

Figures (4)

• Figure 1: Comparison of the MH Mock-up and MH on-detector test architectures.
• Figure 2: The proposed general testbed architecture for latency and data integrity measurements.
• Figure 3: The proposed testbed architecture for CIC functionality and isolation verification.
• Figure 4: The data logging and analysis pipeline, from raw data collection to final validation.