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

Questo lavoro presenta una metodologia di verifica e un banco di prova strutturato per confrontare l'architettura di produzione FPGA-based e il mock-up basato su Raspberry Pi del sistema di lettura MOPS, al fine di qualificare la soluzione finale per il controllo e il monitoraggio del nuovo Inner Tracker (ITk) dell'esperimento ATLAS nell'ambito dell'aggiornamento High-Luminosity del LHC.

L'essenziale

🌌 Il Grande Esperimento: ATLAS e il suo "Sistema Nervoso"

Immagina il Large Hadron Collider (LHC) come un gigantesco acceleratore di particelle, una sorta di "corsa di Formula 1" dove i protoni viaggiano a velocità incredibili. L'esperimento ATLAS è il pubblico che guarda la gara: è un rivelatore enorme che deve catturare ogni singolo dettaglio di queste collisioni.

Per il futuro, l'LHC diventerà ancora più veloce e potente (chiamato HL-LHC). Questo significa che il "pubblico" (ATLAS) dovrà lavorare in condizioni molto più difficili: più radiazioni, più dati e più caos. Per sopravvivere, l'attuale rivelatore interno deve essere sostituito da uno nuovo e più resistente, chiamato ITk (Inner Tracker).

🛠️ Il Problema: Chi controlla il "Sistema Nervoso"?

Ogni pezzo di questo nuovo rivelatore ha bisogno di essere monitorato costantemente: temperatura, tensione elettrica, salute generale. È come se ogni atomo del rivelatore avesse bisogno di un medico personale.
Il sistema che fa questo lavoro si chiama DCS (Sistema di Controllo del Rivelatore). È il "sistema nervoso" che tiene tutto in vita.

All'interno di questo sistema, c'è un componente cruciale chiamato MOPS (Monitoring of Pixel System). Il suo compito è leggere i dati dai sensori (i "pixel") e portarli al centro di controllo.

🥊 La Sfida: Due Candidati per un Lavoro Importante

Per costruire il nuovo MOPS, gli scienziati hanno dovuto scegliere tra due approcci:

1. Il Candidato "Fai-da-te" (MH Mock-up): Usa un Raspberry Pi (quel piccolo computer a basso costo che usiamo per i progetti hobbistici). È stato utile per iniziare, come un prototipo veloce ed economico.
2. Il Candidato "Professionale" (MH): Usa un FPGA (un chip programmabile molto potente e veloce, usato nell'industria ad alta tecnologia). È progettato per il lavoro pesante e per non sbagliare mai.

La domanda è: Il Raspberry Pi è abbastanza veloce e affidabile per un esperimento da miliardi di euro? O dobbiamo passare al chip professionale?

🕵️‍♂️ L'Investigatore: Il "Testbed" (Il Campo di Prova)

Il problema è che non puoi semplicemente guardare i dati e dire "sembra veloce". Devi misurare il tempo con una precisione incredibile (millesimi di secondo).
Se usi un normale computer per misurare i tempi, il computer stesso è troppo lento e disordinato (come un orologio che si ferma ogni volta che arriva una notifica su WhatsApp). Questo renderebbe la misura inutile.

Per risolvere questo, gli autori del paper hanno costruito un investigatore speciale: un piccolo circuito elettronico basato su un microcontrollore (STM32).

• L'analogia: Immagina di dover misurare quanto tempo impiega un corridore a fare un giro. Se usi un cronometro tenuto da una persona che guarda il telefono, il tempo sarà sbagliato. Se usi un sensore laser automatico collegato direttamente al traguardo, il tempo è perfetto.
• Questo "investigatore" ascolta i messaggi che viaggiano sul cavo e segna l'ora esatta in cui arrivano e in cui vengono elaborati, senza farsi distrarre da nulla.

🏁 La Gara: I Tre Test

Per decidere quale sistema è il migliore, hanno organizzato tre prove (Test Case):

1. La Prova di Velocità (Baseline):

   • Cosa fanno: Mandano un solo messaggio e misurano quanto tempo ci vuole per tornare indietro.
   • Obiettivo: Vedere chi è il più veloce in condizioni di calma.
   • Regola: Il tempo deve essere inferiore a 7 millisecondi (un tempo brevissimo, come il battito di un ciglio).

2. La Prova di Resistenza (Stress Test):

   • Cosa fanno: Immagina di far arrivare 64 messaggi contemporaneamente, per 8 ore di fila. È come far correre un'auto in pista per un'intera giornata senza fermarsi.
   • Obiettivo: Vedere se il sistema si blocca, perde dati o si surriscalda.
   • Regola: Nessun dato deve andare perso. Zero.

3. La Prova di Isolamento (Isolation Test):

   • Cosa fanno: Mandano un segnale forte su un cavo (Canale A) e controllano se quel segnale "trabocca" sul cavo vicino (Canale B).
   • Obiettivo: Assicurarsi che i cavi non si "parlino" tra loro creando interferenze (rumore).
   • Regola: Il Canale B deve rimanere perfettamente silenzioso.

🏆 Le Previsioni e il Risultato Atteso

Gli autori prevedono che:

• Il Raspberry Pi (Mock-up) farà fatica. È come un corridore che deve gestire 16 corse contemporaneamente usando solo un cervello umano: alla fine, perderà dati o sarà troppo lento perché deve "cambiare pensiero" troppo spesso.
• Il FPGA (MH) sarà un campione olimpico. È come un'orchestra dove ogni musicista suona la sua parte in perfetto sincrono. Non perde tempo a cambiare pensiero, perché fa tutto in parallelo.

💡 Conclusione Semplice

Questo paper non è il risultato finale, ma il piano di gara.
Spiega come costruire il campo di prova e come misurare le prestazioni per essere sicuri che il nuovo sistema di controllo (il "sistema nervoso" di ATLAS) sia abbastanza veloce e sicuro per il futuro.

L'obiettivo è dire: "Ok, il Raspberry Pi è stato utile per imparare, ma per il lavoro vero e proprio dobbiamo usare il chip professionale (FPGA), e abbiamo un metodo scientifico per dimostrarlo".

Se questo test funziona, il nuovo sistema sarà pronto per essere installato nel cuore dell'esperimento ATLAS, garantendo che non perderemo nemmeno un singolo dettaglio delle collisioni più importanti della storia della fisica.

Sommario tecnico

Titolo: Analisi Comparativa della Lettura MOPS del CERN ATLAS ITk: Uno Studio di Fattibilità su Configurazioni di Produzione e Sviluppo

1. Il Problema

L'esperimento ATLAS al Large Hadron Collider (LHC) sta affrontando l'aggiornamento per l'era dell'High-Luminosity (HL-LHC), che richiede la sostituzione completa del Rivelatore Interno con il nuovo Inner Tracker (ITk). Questo nuovo ambiente, caratterizzato da un'irradiazione più intensa e tassi di dati superiori, impone requisiti stringenti al Sistema di Controllo del Rivelatore (DCS).
Un componente critico è il MOPS (Monitoring of Pixel System), responsabile del monitoraggio di tensioni e temperature dei moduli del rivelatore a pixel.

• Sfida principale: È necessario validare quantitativamente l'architettura finale di lettura (basata su FPGA) rispetto a una soluzione preliminare (basata su Raspberry Pi, denominata "MH Mock-up").
• Limitazioni delle soluzioni esistenti: I metodi di test standard basati su PC (adattatori USB-CAN e convertitori USB-UART) introducono latenze non deterministiche e jitter dovuti al sistema operativo e al bus USB, rendendo impossibile misurare con precisione le prestazioni sub-millisecondo richieste dal sistema. Inoltre, la soluzione Raspberry Pi, sebbene utile per lo sviluppo iniziale, presenta rischi di perdita dati e latenze elevate a causa dello switching software dei bus CAN, inadatto per un sistema di controllo critico in tempo reale.

2. Metodologia

Il paper propone una metodologia rigorosa basata su un banco di prova dedicato ("Readout Hub") progettato per eliminare le fonti di errore esterne.

• Architettura del Testbed:

  • Utilizzo di un singolo microcontrollore STM32F767ZIT6 (core ARM Cortex-M7) come cuore del sistema di misura.
  • Sincronizzazione: Tutti gli timestamp sono generati da un unico orologio ad alta frequenza, eliminando errori di temporizzazione relativa.
  • Misurazione: Il sistema cattura non intrusivamente i messaggi sul bus CAN (1.2V, 125 kbit/s) e registra l'orario di arrivo ($t_1$) e l'orario in cui i dati elaborati vengono letti dalla porta UART del dispositivo sotto test ($t_2$).
  • Pipeline Dati: I dati grezzi ($t_1, t_2$, payload) vengono inviati via USB a un PC per l'analisi automatizzata in Python, calcolando latenza ($\Delta t$), jitter (deviazione standard) e integrità dei dati.

• Piano di Valutazione a Tre Fasi:

  1. Prestazioni di Base (Test Case 1): Misura della latenza di andata e ritorno (round-trip) in condizioni di carico minimo (1 nodo MOPS). Obiettivo: verificare la funzionalità base e la coerenza temporale.
  2. Test di Stress Completo (Test Case 2): Simulazione del carico massimo (fino a 64 nodi MOPS su 16 canali). Durata di 8 ore ("soak test") per rilevare problemi di stabilità a lungo termine, perdite di memoria o degradazione termica.
  3. Test di Isolamento CIC (Test Case 3): Verifica dell'isolamento elettrico tra i canali A e B di una scheda CIC (CAN Interface Card). Si iniettano segnali ad alta frequenza su un canale per verificare l'assenza di diafonia (crosstalk) sull'altro.

3. Contributi Chiave

• Testbed Microcontrollere Single-Clock: Sviluppo di una piattaforma di misura basata su STM32 capace di misurare latenze e jitter nell'ordine dei microsecondi, superando i limiti degli strumenti basati su PC.
• Piano di Test Strutturato: Definizione di un protocollo di validazione completo che copre prestazioni di base, stress estremo e requisiti di sicurezza elettrica (isolamento), andando oltre le semplici verifiche funzionali.
• Pipeline di Analisi Dati Automatizzata: Integrazione di hardware (tap non intrusivi), firmware per la cattura e script Python per la visualizzazione statistica e la validazione oggettiva dei risultati.
• Criteri di Accettazione Quantitativi: Stabilimento di limiti precisi (es. latenza media < 7 ms per il round-trip, jitter limitato, zero perdita di pacchetti) basati sui vincoli fisici del bus CAN e sui fattori di sicurezza richiesti.

4. Risultati Attesi

Sebbene il paper presenti la metodologia e non i risultati sperimentali finali (che saranno oggetto di un articolo complementare), le aspettative sono chiare:

• MH Mock-up (Raspberry Pi): Si prevede che il sistema basato su Linux e Raspberry Pi mostrerà latenze elevate e jitter significativo a causa dello scheduling non deterministico e dello switching software dei bus. È atteso che fallisca i test di stress ad alto carico, confermando la sua inadeguatezza per la produzione finale.
• MH (FPGA): L'architettura basata su FPGA dovrebbe dimostrare prestazioni superiori, con latenza deterministica e jitter estremamente basso. Si prevede che il sistema gestisca il carico massimo di 64 nodi senza perdita di pacchetti, limitando la latenza principalmente dalla velocità fisica di trasmissione del bus (circa 2.2 ms per il round-trip teorico) piuttosto che dall'elaborazione interna.

5. Significato

Questo lavoro è fondamentale per il successo dell'aggiornamento ATLAS ITk:

• Validazione per la Produzione: Fornisce la prova quantitativa necessaria per approvare l'architettura FPGA per la produzione di massa, garantendo che il sistema di monitoraggio sia affidabile nell'ambiente ostile della caverna di ATLAS.
• Ponte tra Componenti e Sistema: Colma il divario tra i test di qualità dei singoli componenti e la messa in servizio del sistema completo, offrendo un metodo ripetibile per valutare le prestazioni di comunicazione.
• Sicurezza e Affidabilità: Assicura che il sistema DCS possa gestire migliaia di alimentatori e monitorare parametri ambientali in tempo reale, prevenendo guasti e garantendo la sicurezza del rivelatore durante le collisioni ad alta luminosità.
• Standardizzazione: Stabilisce un protocollo di test rigoroso che può servire come modello per la validazione di altri sottosistemi di controllo nei futuri esperimenti di fisica delle alte energie.

In sintesi, il paper delinea un approccio ingegneristico solido per trasformare un prototipo di sviluppo in un sistema di produzione critico, garantendo che l'infrastruttura di controllo dell'ITk sia pronta per le sfide dell'era HL-LHC.