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

Este artículo presenta una metodología de prueba y un banco de pruebas estandarizados para evaluar y comparar el rendimiento, la latencia y la integridad de los datos de las arquitecturas de lectura del sistema MOPS (basada en Raspberry Pi y FPGA) destinadas al control del nuevo detector de píxeles ITk del experimento ATLAS en el LHC de alta luminosidad.

Lo esencial

¡Hola! Imagina que el Gran Colisionador de Hadrones (LHC) es una ciudad futurista y gigante donde las partículas viajan a velocidades increíbles. Para estudiarlas, los científicos usan un detector llamado ATLAS, que es como un ojo gigante y muy sensible.

Ahora, esta ciudad va a sufrir una "explosión" de actividad (el HL-LHC), lo que significa que habrá muchísimos más datos y una radiación muy fuerte. Para sobrevivir a esto, necesitan cambiar el "cerebro" interno del detector (el ITk) por uno nuevo y más resistente.

El problema es: ¿Cómo nos aseguramos de que este nuevo cerebro no se desmaye cuando le lanzamos millones de datos a la vez?

Aquí es donde entra este artículo. Es como un manual de pruebas de estrés para dos versiones de un "centro de control" llamado MOPS-Hub. Vamos a explicarlo con una analogía sencilla:

🏗️ La Analogía: El Sistema de Correos de una Ciudad

Imagina que los sensores del detector son miles de ciudadanos que necesitan enviar cartas urgentes (datos de temperatura y voltaje) a una oficina central.

1. Las Cartas (Datos): Viajan por una carretera especial llamada CAN Bus. Es una carretera estrecha y segura, pero lenta (como una calle de un solo carril).
2. El Centro de Control (MOPS-Hub): Es la oficina que recibe todas las cartas, las ordena y las envía a la computadora principal.
3. El Reto: Tienen dos candidatos para ser el jefe de esta oficina:
   • Candidato A (Mock-up): Es un Raspberry Pi (una pequeña computadora de juguete, barata y fácil de usar). Es genial para probar ideas, pero es como un cartero que tiene que leer, escribir y organizar todo con sus propias manos. Si llegan muchas cartas a la vez, se abruma y puede dejar caer algunas o tardar mucho.
   • Candidato B (MH Final): Es un FPGA (un chip inteligente diseñado a medida). Es como un robot super-rápido con mil brazos que puede leer, clasificar y enviar cartas de todos los canales al mismo tiempo, sin pensar ni dudar.

🧪 ¿Qué hace este artículo? (El "Simulador de Tráfico")

El problema es que no podemos simplemente poner a los dos candidatos a trabajar y esperar a ver quién gana. Necesitamos medirlo con precisión quirúrgica. Si usamos una computadora normal para medir el tiempo, el sistema operativo de esa computadora (Windows o Linux) se entromete y nos da tiempos falsos (como si el cartero se detuviera a saludar a un vecino).

La solución del equipo:
Han construido un "Simulador de Tráfico" (Testbed) especial.

• Es como un cronómetro maestro hecho con un microchip muy rápido (un STM32).
• Este cronómetro no usa computadoras normales; es un reloj único y preciso que mide exactamente cuánto tarda una carta en llegar desde que sale del ciudadano hasta que el jefe de oficina la procesa.
• No deja que nada interfiera. Es como tener una cámara de alta velocidad que solo mira el movimiento de las cartas, ignorando todo lo demás.

📋 Las Tres Pruebas (El Examen de Conducción)

Para decidir quién se queda en el trabajo, han diseñado tres pruebas extremas:

1. La Prueba de Calma (Rendimiento Base):

   • Escenario: Solo llega una carta cada cierto tiempo.
   • Objetivo: Ver qué tan rápido es el sistema en su mejor momento.
   • Meta: Debe tardar menos de 7 milisegundos (¡es instantáneo para un humano, pero una eternidad para una computadora!).

2. La Prueba de Estrés (El "Tráfico Pesado"):

   • Escenario: ¡Llegan 64 ciudadanos enviando cartas al mismo tiempo, sin parar, durante 8 horas!
   • Objetivo: Ver si el sistema se agota, si pierde cartas o si se vuelve lento.
   • Meta: Cero cartas perdidas. Si el Candidato A (Raspberry Pi) empieza a perder cartas porque está muy ocupado, queda descalificado. El Candidato B (FPGA) debe mantenerse firme.

3. La Prueba de Aislamiento (El Muro de Fuego):

   • Escenario: Enviamos muchas cartas por el "Canal A" y miramos si alguna "se filtra" al "Canal B" (que debería estar vacío).
   • Objetivo: Asegurar que los canales eléctricos no se mezclen. Si se mezclan, se crea "ruido" y el sistema falla.
   • Meta: El Canal B debe estar completamente silencioso.

🏆 ¿Qué esperan encontrar?

• El Candidato A (Raspberry Pi): Se espera que funcione bien al principio, pero que en la prueba de estrés (8 horas) empiece a fallar, perder datos o tardar demasiado porque su "cerebro" de software no es lo suficientemente rápido ni predecible.
• El Candidato B (FPGA): Se espera que sea el ganador indiscutible. Al ser un chip diseñado específicamente para esto, debería manejar el tráfico pesado sin sudar, manteniendo un ritmo perfecto y sin perder ni una sola carta.

💡 Conclusión Simple

Este artículo no presenta los resultados finales (esos vendrán en un próximo trabajo), sino que explica el plan de batalla.

Es como si un ingeniero dijera: "No vamos a adivinar si nuestro nuevo sistema de seguridad funciona. Vamos a construir una máquina de pruebas perfecta, someteremos a los dos candidatos a un tráfico infernal y mediremos cada milisegundo con un reloj de precisión. Así sabremos con certeza que el sistema final no fallará cuando la ciudad esté en su momento más caótico."

Es un trabajo de preparación y rigor para asegurar que, cuando el LHC vuelva a encenderse, los datos lleguen limpios, rápidos y seguros.

Resumen técnico

Resumen Técnico: Análisis Comparativo de la Lectura MOPS del ATLAS ITk

1. Planteamiento del Problema

El experimento ATLAS en el Gran Colisionador de Hadrones (LHC) está experimentando una actualización mayor para la era de Alta Luminosidad (HL-LHC). Esto requiere el reemplazo completo del Detector Interno por un nuevo Rastreador Interno (ITk) basado en silicio. El Sistema de Control del Detector (DCS) es crucial para la supervisión y seguridad de este nuevo detector.

Un componente crítico del DCS del ITk es el Sistema de Monitoreo de Píxeles (MOPS), que supervisa voltajes y temperaturas locales mediante un ASIC (Circuito Integrado de Aplicación Específica) resistente a la radiación. Los datos se transmiten a través de un bus CAN físico no estándar de 1.2V (a 125 kbit/s) para evitar riesgos asociados con los transistores MOS de 5V en entornos de radiación.

El desafío principal radica en validar la arquitectura de lectura final antes de la producción masiva. Se han desarrollado dos arquitecturas:

1. MOPS-Hub Mock-up (MH Mock-up): Un prototipo intermedio basado en Raspberry Pi (Linux), destinado a validación temprana pero con limitaciones de tiempo real.
2. MOPS-Hub (MH): La arquitectura final de producción basada en un FPGA (Field-Programmable Gate Array) personalizada, diseñada para manejar 16 canales simultáneamente.

Es necesario un método riguroso y cuantitativo para comparar el rendimiento de latencia, jitter (variabilidad temporal) e integridad de datos entre ambos, asegurando que la solución final cumpla con los requisitos estrictos de fiabilidad del HL-LHC.

2. Metodología

El artículo propone una metodología de validación centrada en un banco de pruebas dedicado ("Readout Hub") diseñado para eliminar las fuentes de error inherentes a las herramientas de medición convencionales basadas en PC.

• Diseño del Banco de Pruebas:

  • Se utiliza un microcontrolador STM32F767ZIT6 (núcleo ARM Cortex-M7 a 216 MHz) como núcleo de medición.
  • Sincronización: Al usar un único reloj de alta precisión para todas las marcas de tiempo, se eliminan los errores de temporización relativos y la no determinismo de los sistemas operativos (Linux/Windows) y buses USB.
  • Medición: El sistema captura dos tiempos: $t_1$ (cuando el mensaje CAN es recibido por el controlador externo) y $t_2$ (cuando los datos procesados salen por el puerto UART del dispositivo bajo prueba). La latencia se calcula como $\Delta t = t_2 - t_1$.
  • Inyección y Taps: Incluye adaptadores no intrusivos para monitorear el bus CAN y capacidades para inyectar mensajes para pruebas de aislamiento.

• Plan de Evaluación de Tres Etapas:

  1. Rendimiento de Línea Base (Test Case 1): Prueba de latencia de ida y vuelta en condiciones de carga mínima (1 nodo, 1 canal). Objetivo: Latencia media < 7 ms y jitter bajo.
  2. Prueba de Estrés de Caja Completa (Test Case 2): Simulación de la carga máxima operativa (64 nodos en el MH, 8 nodos en el Mock-up) durante 8 horas ("soak test"). Objetivo: Cero pérdida de paquetes, latencia media < 3.3 ms (ida) y el percentil 99.9 < 7 ms.
  3. Prueba de Funcionalidad y Aislamiento del CIC (Test Case 3): Verificación del aislamiento eléctrico entre los dos canales de una Tarjeta de Interfaz CAN (CIC). Se inyecta tráfico intenso en un canal (200 Hz) mientras se monitorea el otro para detectar diafonía (crosstalk).

3. Contribuciones Clave

• Banco de Pruebas de Microcontrolador de Reloj Único: Una solución innovadora para medir latencias sub-milisegundo y jitter en la ruta de datos CAN a UART, superando las limitaciones de las herramientas estándar basadas en PC que introducen errores de milisegundos.
• Plan de Evaluación Estructurado: Definición de un protocolo de tres etapas que cubre desde el rendimiento básico hasta la escalabilidad bajo estrés y la validación de requisitos de seguridad eléctrica (aislamiento).
• Pipeline de Análisis de Datos Unificado: Implementación de un flujo de trabajo automatizado que incluye captura de datos en firmware, registro en CSV y análisis estadístico (Python) para visualizar latencia, desviación estándar y distribuciones temporales.
• Criterios de Aceptación Cuantitativos: Establecimiento de límites precisos basados en la física del bus CAN (tiempo de transmisión de 1.1 ms por trama) y factores de seguridad, diferenciando claramente entre el rendimiento óptimo y el de fallo.

4. Resultados Esperados y Discusión

Aunque el artículo es un plan de metodología (los resultados experimentales se presentarán en un artículo complementario), se anticipan los siguientes hallazgos basados en la arquitectura:

• MH Mock-up (Raspberry Pi): Se espera que este sistema actúe como un cuello de botella. La conmutación de contexto basada en software y la naturaleza no determinista del sistema operativo Linux probablemente causen pérdida de datos y aumentos significativos de latencia bajo carga alta (prueba de estrés), lo que lo hace inadecuado para la producción final.
• MH (FPGA): Se espera un rendimiento superior. La arquitectura FPGA permite un procesamiento verdaderamente paralelo de los 16 canales. Se anticipa que la latencia esté limitada únicamente por la velocidad física del bus (aprox. 2.2 ms de ida y vuelta teórica) en lugar del procesamiento interno, resultando en una latencia muy baja, altamente determinista y con un jitter mínimo.
• Aislamiento: Se espera que la prueba de aislamiento confirme que no hay propagación de ruido entre canales, cumpliendo con los esquemas de puesta a tierra del ITk.

5. Significado e Impacto

Este trabajo es fundamental para la transición del desarrollo a la producción del sistema DCS del ATLAS ITk:

• Garantía de Calidad: Proporciona un procedimiento repetible y objetivo para calificar la arquitectura FPGA antes de la fabricación masiva, mitigando riesgos de fallos en el entorno radiactivo del LHC.
• Validación de Seguridad: Al demostrar la integridad de los datos y el aislamiento eléctrico, asegura que el sistema de monitoreo no se convierta en un punto de fallo que pueda comprometer la seguridad del detector o la calidad de los datos científicos.
• Marco de Referencia: Establece un estándar metodológico para la validación de sistemas de control de detectores de alta energía, equilibrando pruebas de componentes individuales con la integración del sistema completo.

En resumen, el documento define el marco técnico necesario para certificar que la solución basada en FPGA es la única viable para la operación fiable del MOPS en las condiciones extremas del HL-LHC, descartando las soluciones prototipo basadas en computadoras de un solo chip (SBC) para la fase de producción.