upgrade del sistema di acquisizione dati dell`esperimento auriga

UPGRADE DEL SISTEMA DI ACQUISIZIONE DATI
DELL’ESPERIMENTO AURIGA: MIGRAZIONE SU
NUOVE PIATTAFORME HARDWARE E SOFTWARE
RELATORE: Ch.mo Prof. Alessandro Beghi
CORRELATORI: Dott. Antonello Ortolan
LAUREANDO: Stefano Longo
A.A. 2003 - 2004
UNIVERSITÀ DEGLI STUDI DI PADOVA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE
TESI DI LAUREA
UPGRADE DEL SISTEMA DI
ACQUISIZIONE DATI
DELL’ESPERIMENTO AURIGA:
MIGRAZIONE SU NUOVE
PIATTAFORME HARDWARE E
SOFTWARE
RELATORE: Ch.mo Prof. Alessandro Beghi
CORRELATORI: Dott. Antonello Ortolan
LAUREANDO: Stefano Longo
Padova, 23 Novembre 2004
2
“Ai miei genitori e
a Laura
che mi sono sempre
stati accanto”
Sommario
Nei moderni esperimenti di fisica, l’intera elaborazione delle informazioni avviene con metodi digitali, beneficiando delle crescenti capacitá di calcolo presenti
nei calcolatori. La gestione di segnali digitalizzati non puó prescindere dalla loro
conversione, rendendo i sistemi di acquisizione fondamentali per la buona riuscita
di qualsiasi esperimento.
Il lavoro sviluppato in questa tesi riguarda il sistema di acquisizione utilizzato
dall’esperimento AURIGA, il rivelatore di onde gravitazionali situato presso i laboratori di Legnaro dell’Istituto Nazionale di Fisica Nucleare. Viene presentato il
processo di migrazione del sistema verso nuove piattaforme resosi necessario per
il rispetto dei requisiti dell’esperimento, con particolare riguardo ai problemi di
sincronizzazione dei dati acquisiti. Nella tesi vengono discussi e analizzati i principali problemi che é stato necessario affrontare, proponendo soluzioni e verifiche
di funzionalitá che hanno certificato il buon funzionamento del sistema. Trova
infine spazio la discussione dei problemi relativi alla calibrazione e alle tecniche di
diagnostica del sistema di acquisizione, presentando gli strumenti esterni al DAQ
che sono stati implementati allo scopo, permettendo un incremento globale delle
prestazioni del sistema.
Indice
1 Introduzione
1
2 Onde Gravitazionali
2.1 Onde Gravitazionali . . . . . .
2.2 Sorgenti di Onde Gravitazionali
2.3 Scopo della rivelazione . . . . .
2.4 Tipi di Rivelatori . . . . . . . .
2.5 L’esperimento AURIGA . . . .
.
.
.
.
.
5
5
6
7
7
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
17
18
22
24
26
26
27
28
30
30
31
31
36
37
37
37
38
38
39
4 Upgrade e BugFix del Sistema
4.1 Malfunzionamenti . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Aggiornamento Hardware . . . . . . . . . . . . . . . . . . . . . .
43
44
44
3 Il DAQ
3.1 Il Sistema di Acquisizione .
3.2 La strumentazione VXI . . .
3.3 Il GPS e la sincronizzazione
3.4 Il canale Antenna . . . . . .
3.5 I canali Ausiliari . . . . . .
3.6 Il sistema Host . . . . . . .
3.7 L’Ambiente di Sviluppo . .
3.7.1 omniORB . . . . . .
3.7.2 OSE . . . . . . . . .
3.7.3 Frame Library . . . .
3.7.4 ROOT . . . . . . . .
3.7.5 FFTW . . . . . . . .
3.7.6 NI-VXI . . . . . . .
3.8 Il Software di Acquisizione .
3.8.1 ANT . . . . . . . . .
3.8.2 AUX . . . . . . . . .
3.8.3 GPS . . . . . . . . .
3.8.4 BLD . . . . . . . . .
3.8.5 DSK . . . . . . . . .
3.8.6 LOG . . . . . . . . .
3.8.7 GUI . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3
4.4
4.5
4.6
4.2.1 Il nuovo Crate . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Il nuovo PC Host . . . . . . . . . . . . . . . . . . . .
Soluzione dei problemi di Sincronizzazione . . . . . . . . . .
4.3.1 Errori di comunicazione . . . . . . . . . . . . . . . .
4.3.2 Ritardo nel sollevamento delle Interruzioni . . . . . .
4.3.3 Mancata lettura di un timestamp dalla coda di GPS
Segnali Ausiliari . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Stato dell’ADC HP 1413 . . . . . . . . . . . . . . . .
4.4.2 Sincronizzazione degli Ausiliari . . . . . . . . . . . .
4.4.3 Frequenza di campionamento . . . . . . . . . . . . .
4.4.4 Migliorie e correzioni minori . . . . . . . . . . . . . .
Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . .
Librerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Calibrazione e Diagnostica del Sistema
5.1 Latenza delle Interruzioni . . . . . . .
5.1.1 Il Filtro Analogico . . . . . . .
5.1.2 Il Filtro Digitale . . . . . . . .
5.1.3 Stima della Latenza . . . . . . .
5.2 Ampiezza e Offset . . . . . . . . . . . .
5.3 DAQ Calibration . . . . . . . . . . . .
5.4 Risultati . . . . . . . . . . . . . . . . .
5.5 Diagnostica del Sistema . . . . . . . .
5.6 Diagnostica Off-Line . . . . . . . . . .
5.7 Diagnostica On-Line . . . . . . . . . .
5.8 DAQ Control . . . . . . . . . . . . . .
5.8.1 Architettura del sistema . . . .
5.8.2 Tipologie di diagnostica . . . .
5.8.3 Interfacce . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
48
50
50
52
54
58
58
59
61
62
63
64
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
66
66
69
70
73
73
77
79
80
81
82
83
85
86
6 Conclusioni e sviluppi futuri
89
Bibliografia
93
II
Capitolo 1
Introduzione
Le tecnologie digitali vengono oramai ampiamente utilizzate nella fisica moderna;
per coglierne tutti i benefici i dati forniti dagli esperimenti devono essere digitalizzati utilizzando un sistema di acquisizione, rendendolo quindi un punto cruciale
per la riuscita di qualsiasi sperimentazione. Ad un aumento della difficoltá di quest’ultimo corrisponde quasi sempre un incremento dei requisiti imposti al sistema,
aumentandone la criticitá.
In particolare, nella ricerca di onde gravitazionali, la difficoltá intrinseca é
dovuta principalmente alla scarsa interazione con la materia che attraversano,
una misura della complessitá della rivelazione puó essere dedotta semplicemente
considerando che ad oggi non esiste alcuna conferma di osservazione di fenomeni
gravitazionali nonostante gli sforzi di quarant’anni di ricerca.
Le peculiaritá del rivelatore di onde gravitazionali AURIGA (rivelatore a barra risonante in operazione presso i Laboratori Nazionali di Legnaro dell’INFN),
impongono vincoli stringenti al sistema di acquisizione adottato. La natura delle onde gravitazionali richiede che il DAQ - inteso come insieme di hardware e
software - effettui un trattamento ottimale del segnale proveniente dal rivelatore,
introducendo un disturbo che va necessariamente minimizzato. L’impossibilitá di
avere una qualche sorta di controllo su sorgenti artificiali, inoltre, fa di AURIGA
un osservatorio di onde gravitazionali, richiedendo all’intero sistema di acquisizione la massimizzazione del duty-cycle, riducendo al minimo i tempi in cui deve
essere fermato. La debolezza di interazione con la materia infine, rende necessaria
la collaborazione con altri rivelatori per aumentare il livello di confidenza della
rivelazione, imponendo vincoli aggiuntivi al sistema di acquisizione in particolar
modo per quanto riguarda la sincronizzazione con il tempo universale e l’adozione
di un formato comune che renda possibile lo scambio di dati tra diversi esperimenti.
Il lavoro presentato in questa tesi muove i suoi passi partendo dal sistema di
acquisizione esistente, progettato e realizzato nel 2001 per rispondere ai requisiti dell’esperimento. Le cause che hanno richiesto la rielaborazione del sistema
possono essere principalmente riassunte, in ordine di importanza, nel bisogno di
risolvere alcuni problemi di funzionamento che si sono rivelati dall’utilizzo del
1
Capitolo 1. Introduzione
sistema, nell’evoluzione dello stesso richiesta per l’introduzione di nuove funzionalitá e - infine - dalla necessitá di allineare il software di acquisizione ai nuovi
strumenti hardware e software che sono stati sviluppati da quando il precedente
DAQ é entrato in funzione.
La presentazione del lavoro svolto per questa tesi é stato articolato nel modo
seguente:
Nel Capitolo 2 viene introdotto brevemente il fenomeno delle onde gravitazionali citando la fisica che lo supporta, ovvero la Relativitá Generale di Albert
Einstein. Si é scelto uno stile qualitativo poiché lo scopo di questa sezione é di
fornire la possibilitá ad un lettore di inquadrare il problema ingegneristico dato
dal sistema di acquisizione per l’esperimento. Viene quindi introdotta l’origine
delle onde gravitazionale e le possibili sorgenti che sono oggetto di studio, con
una particolare enfasi sulla loro interazione con la materia. L’importanza di una
possibile rivelazione é costituita, oltre che dalla verifica di un aspetto teorico della
teoria della Relativitá Generale, dalla possibilitá di estendere lo spettro di osservazione del cosmo, permettendo un’indagine complementare a quelle giá realizzate
mediante la radiazione elettromagnetica (onde radio, infrarosso, luce visibile, ultravioletto, raggi X e γ). In conclusione vengono presentate le possibili tecniche
di indagine, mediante rivelatori interferometrici oppure risonanti. Viene infine
descritto nello specifico il rivelatore AURIGA, nella sua attuale configurazione
operativa.
Nel terzo capitolo viene descritto il sistema dal quale ho iniziato il lavoro per
questa tesi. Vengono presentate le ragioni che hanno portato alla scelta di determinata strumentazione hardware mostrando che le scelte allora effettuate sono
tuttora adeguate per le funzionalitá che si vogliono realizzare. Segue la presentazione dell’architettura hardware utilizzata per l’acquisizione, particolarmente
utile per risolvere il problema della sincronizzazione con il tempo universale, che
sta alla base di qualsiasi sistema di acquisizione da utilizzare nella rivelazione
di onde gravitazionali. Si presenta quindi l’ambiente di sviluppo adottato nella
prima versione del DAQ, analizzando le ragioni che hanno portato alla sua scelta
ed illustrando i motivi per cui taluni elementi sono stati conservati mentre per
altri si sono preferite soluzioni differenti. Infine trova ampio spazio la descrizione
del precedente sistema di acquisizione vero e proprio, inteso come software che
realizza il DAQ. Ne viene descritta l’architettura e si presentano i singoli processi che lo compongono, descrivendo le peculiaritá di ognuno e introducendo i
problemi che saranno affrontati e risolti nelle sezioni successive.
Nel quarto capitolo si presentano le novitá introdotte con il lavoro della tesi. In particolare viene trattata la migrazione del sistema di acquisizione verso
nuove piattaforme e la correzione degli errori effettuata per risolvere i problemi che sono emersi con l’utilizzo del DAQ. Vengono preventivamente trattate le
questioni relative all’upgrade dell’hardware, la scelta dei nuovi componenti e i
test che sono stati necessari per verificare la conformitá alle specifiche richieste.
Successivamente trova ampio spazio la descrizione degli inconvenienti riscontrati
nella sincronizzazione dei dati con il tempo universale e nell’utilizzo dei canali
ausiliari, essendo stati soggetti alle maggiori modifiche. Sono analizzate le cause
2
dei malfunzionamenti e proposte soluzioni, assieme ai test che ne hanno verificato
la funzionalitá. Vengono inoltre presentati gli aggiornamenti di carattere software
e quindi i nuovi pacchetti scelti per lo sviluppo del sistema.
Nel Capitolo 5 si discute il problema della calibrazione del sistema di acquisizione, operazione resa necessaria per ottenere l’accuratezza richiesta dall’esperimento, e della sua diagnostica. Particolare risalto viene dato alla calibrazione dei
ritardi di fase introdotti dall’ADC, analizzando il funzionamento dalla strumentazione e presentando il metodo adottato per la stima della latenza delle interruzioni
utilizzate per la sincronizzazione. Successivamente viene affrontato il problema
della calibrazione in ampiezza dell’ADC utilizzato per il canale principale e delle
soluzioni che sono state proposte. A conclusione dell’argomento viene presentato
il tool “DAQ Calibration” sviluppato per l’automatizzazione di alcune operazioni
necessarie alla calibrazione del sistema di acquisizione.
L’ultimo argomento affrontato in questa tesi riguarda la diagnostica del sistema, necessaria per garantirne il buon funzionamento e per ottenere i requisiti di
resilienza richiesti. Vengono proposti due sistemi di diagnostica che sono stati implementati (on-line e off-line) analizzando le possibilitá fornite da ognuno. Infine
viene presentato “DAQ Control”, il tool che é stato sviluppato per la diagnostica remota del sistema di acquisizione, assieme alle utilitá fornite a corredo che
permettono l’integrazione con i sistemi giá presenti nel laboratorio di AURIGA.
3
Capitolo 2
Onde Gravitazionali
In questo capitolo si descrive brevemente il concetto di Onda Gravitazionale.
Si procederá quindi con una introduzione prevalentemente qualitativa del fenomeno per poi presentare le tecniche di rivelazione attualmente utilizzate. Infine si presenterá il rivelatore di onde gravitazionali AURIGA, il cui sistema di
acquisizione dati (DAQ) é l’oggetto di questa tesi.
2.1
Onde Gravitazionali
Pubblicata nel 1916, la teoria della Relativitá Generale di Albert Einstein ha portato ad una radicale modifica di come debbano essere interpretati i fenomeni che
riguardano l’interazione gravitazionale. In essa la forza gravitazionale viene ad
essere modellata non piú come un campo, ma geometricamente. Gli oggetti dotati
di massa alterano la geometria dello spazio-tempo, producendo una curvatura. In
buona analogia con i fenomeni elettromagnetici, la teoria della Relativitá Generale prevede che la variazione nella distribuzione di massa altera lo spazio-tempo
e questa variazione produce un’onda, l’onda gravitazionale, che si propaga nello
spazio alla velocitá della luce. Le frequenze dell’onda prodotta sono inversamente
proporzionali alla massa della sorgente [1].
Le somiglianze tra onde elettromagnetiche e gravitazionali sono molte, tuttavia l’analogia non é completa. Per citare alcune tra le differenze sostanziali vi
sono le modalitá di generazione, il mezzo di propagazione e l’interazione con la
materia. Si é giá detto che nel caso delle onde gravitazionali é l’alterazione della
distribuzione di una massa a dare origine al fenomeno. Per quanto riguarda il
mezzo di propagazione sappiamo che le onde elettromagnetiche sfruttano lo spazio
vuoto come mezzo, mentre le onde gravitazionali alterano lo spazio stesso (anzi,
per la precisione lo spazio-tempo). L’interazione con la materia che investono
inoltre é molto differente nel caso di onde elettromagnetiche e gravitazionali. Nel
secondo caso, effetto dell’onda consiste nell’alterare la distanza relativa di punti
in “caduta libera”1 e, a differenza della prima, é estremamente piccolo. Infatti
1
La dicitura punti in caduta libera indica punti non sottoposti ad alcuna forza in senso
relativistico ossia punti che sono sottoposti alla sola forza di gravitá
5
Capitolo 2. Onde Gravitazionali
si é stimato che l’effetto delle onde gravitazionali piú intense, quelle che dovrebbero svilupparsi da eventi come l’esplosione di supernovæ galattiche, é tale da
indurre una variazione della distanza di due punti posti ad un metro, di 10−19 m.
Considerando che il diametro del nucleo di un atomo é dell’ordine di 10−15 m,
la misura di un’onda gravitazionale é possibile solo se si riesce a rilevare con
precisione grandezze inferiori a un decimillesimo di questa dimensione.
Proprio a causa degli effetti cosı́ difficilmente misurabili, ad oggi non abbiamo
alcuna misurazione diretta di onde gravitazionali. Oltre alla dimostrazione della
necessitá della loro esistenza come conseguenza della teoria della Relativitá Generale, disponiamo solamente di una verifica indiretta dovuta a J. Taylor. Questi,
osservando la pulsar binaria PSR1913+16, notó un rallentamento del moto orbitale [2]. Essendo l’emissione di onde gravitazionali l’unica possibilitá per spiegare
il fenomeno, Taylor effettuó una serie di misurazioni su tale rallentamento e le
confrontó con i dati ottenibili analiticamente dalla teoria della Relativitá Generale. L’accordo fra dati calcolati e sperimentali fu ottimo e confermó la sua teoria
che gli valse nel 1993 il Premio Nobel.
2.2
Sorgenti di Onde Gravitazionali
Data la debolezza dell’interazione gravitazionale, le sorgenti vanno ricercate tra i
corpi celesti che, per le masse in gioco, sono gli unici oggetti in grado di produrre
ondulazioni sufficientemente ampie da poter essere rilevate dalla strumentazione.
In base al tipo di fenomeno ondulatorio a cui danno origine si distinguono due
tipi di sorgenti: quasi-periodiche ed impulsive. Tra le prime vanno indicati tutti
i corpi celesti in rapida rotazione (pulsar) o i sistemi binari, mentre al secondo
gruppo appartengono quelli che producono eventi catastrofici come l’esplosione
di supernovæ.
Le sorgenti periodiche sono costituite essenzialmente da tutti i sistemi binari2 .
Durante la loro vita infatti, le stelle del sistema tendono ad avvicinarsi l’un l’altra,
riducendone l’energia potenziale. Questa energia ovviamente non scompare, ma
lascia il sistema sotto forma di onde gravitazionali. I sistemi binari possono
essere costituiti da diversi corpi: oltre alle normali stelle possiamo avere stelle di
neutroni3 e buchi neri (oltre a tutte le loro possibili combinazioni).
Vanno considerati fra le sorgenti impulsive tutti i corpi destinati ad una repentina modifica della loro struttura. Oltre alle giá citate esplosioni di supernovæ,
sono eventi promettenti per l’emissione di onde gravitazionali tutti i corpi celesti che stanno per collassare (inclusi i sistemi binari, quando i due corpi che lo
costituiscono sono giunti a contatto). Questi fenomeni risultano particolarmente
interessanti per le alte energie sprigionate. La grande distanza dell’evento dalla
terra - infatti - fa si che ci arrivi solo una piccola parte dell’energia emessa sotto
2
Complesso di due astri in rotazione l’uno attorno all’altro
Si dice stella di neutroni un corpo celeste costituito dal nucleo collassato di una stella
massiva. Essenzialmente sono costituite da materia degenere sotto forma di flusso di neutroni
e quindi la loro densitá é elevatissima
3
6
2.3. Scopo della rivelazione
forma di onde gravitazionali. Per loro natura inoltre, le onde gravitazionali interagiscono molto debolmente con la materia e quindi solo eventi di questa portata
sono particolarmente favorevoli alla rivelazione.
Anche se al di sopra delle nostre attuali sensibilitá di misurazione, vanno
citate come sorgenti i fenomeni avvenuti al tempo della formazione delle galassie
e il Big-Bang stesso. Questi devono aver prodotto una gran quantitá di onde
gravitazionali che tutt’ora potrebbero essere misurabili. Ad oggi peró non vi é
alcuna conferma sperimentale dato che nessuno strumento é stato in grado di
distinguere tali segnali gravitazionali da quelli legati alle fluttuazioni del proprio
rumore.
2.3
Scopo della rivelazione
L’importanza della rivelazione di onde gravitazionali va oltre la semplice dimostrazione di un risultato della teoria della Relativitá Generale. Esse infatti permetterebbero di allargare gli attuali orizzonti nell’esplorazione del cosmo consentendo un’osservazione di oggetti astrofisici complementare a quella che giá avviene
utilizzando la radiazione elettromagnetica.
Quello che attualmente osserviamo - alle bande γ, X, visibile, infrarosso e
radio - é prodotto da fenomeni che avvengono sulla superficie del corpo celeste
e quindi puó offrirci informazioni solo relativamente a quanto avviene in quella
zona. Le onde gravitazionali invece sono prodotte dal moto della massa stessa e
quindi possono fornirci dati su quanto accade al suo interno.
Le onde gravitazionali inoltre dovrebbero rendere possibile lo studio di tutti
quei corpi celesti che non emettono radiazione elettromagnetica (ad esempio i
buchi neri) provandone finalmente l’esistenza e quanto finora si é congetturato
sulla loro natura.
Infine, per la loro scarsa interazione con la materia, le onde gravitazionali
dovrebbero permetterci di studiare fenomeni che attualmente non possiamo osservare per la distanza o per la composizione del materiale interstellare tra la
terra e la zona di esplorazione. Le onde elettromagnetiche infatti vengono distorte, assorbite, ecc. durante il loro percorso, giungendo alla terra alterate ed
attenuate e limitando cosı́ la zona di universo che possiamo osservare. La propagazione delle onde gravitazionali invece non risente di tutto ció e permetterebbe
quindi l’esplorazione di zone attualmente irraggiungibili.
2.4
Tipi di Rivelatori
I rivelatori di onde gravitazionali sono essenzialmente di due tipi: interferometrici
e risonanti. In entrambi la rilevazione si riconduce alla misura di deformazione dello spazio-tempo che, come indicato nella Sezione 2.1, viene alterato dal passaggio
dell’onda.
7
Capitolo 2. Onde Gravitazionali
I rivelatori interferometrici vengono derivati essenzialmente dall’interferometro di Michelson. Sono costituiti da due bracci ortogonali, nei quali viene creato
il vuoto. Un raggio laser proveniente da una sorgente viene diviso in due da un
“beam splitter” (Specchio semiargentato) e inviato lungo i due bracci. Al loro
termine i raggi vengono riflessi da due specchi e, giunti nuovamente all’intersezione dei due bracci, vengono fatti interferire. Dall’osservazione della figura di
interferenza si puó determinare se la distanza percorsa dai due raggi é diversa.
Dato il tipo di misura, affinché l’esperimento fornisca i risultati voluti, vanno
utilizzati molti accorgimenti. In primo luogo la lunghezza dei bracci dell’interferometro va scelta in maniera tale da soddisfare le richieste di sensibilitá (che
cresce con la lunghezza del percorso coperto dal laser). Ad esempio gli esperimenti LIGO4 e VIRGO5 - attualmente tra i piú avanzati in questa tipologia di
rivelatori - utilizzano rispettivamente bracci di 4 Km e 3 Km.
Figura 2.1: Schematizzazione dell’interferometro VIRGO
Per aumentare ulteriormente la distanza percorsa dal laser, questo viene riflesso piú volte da una estremitá all’altra del braccio, cosı́ da incrementarne il
percorso effettivo (nel caso di VIRGO, ad esempio, diventa 120 Km). Inoltre,
tutti i dispositivi ottici utilizzati nell’esperimento devono essere sospesi in maniera tale da soddisfare il requisito di caduta libera nella banda d’interesse. Nella
rivelazione di onde gravitazionali, il rumore e la sua reiezione diventano fondamentali. Per questa ragione vengono adoperati tutta una serie di accorgimenti
atti a ridurre le possibili cause di disturbo. Di particolare interesse é il sistema
di sospensione il cui compito consiste nel disaccoppiare il rivelatore dall’attivitá
sismica dell’ambiente circostante. Nel caso di VIRGO ad esempio, vengono utilizzati due sistemi di attenuazione delle vibrazioni meccaniche in cascata. Il primo, direttamente connesso agli elementi ottici, é cotituito da filtri sismici passivi
4
5
Due interferometri in operazione a Livingston(NC) e Hanford(WA) negli Stati Uniti
Interferometro Italo-Francese in operazione a Cascina (PI) in Italia
8
2.4. Tipi di Rivelatori
(molle a balestra) che vengono sospesi al secondo sistema, costituito da una piattaforma controreazionata in maniera attiva tale da mantenere una precisione nel
posizionamento dell’ordine del micron. Le possibili sorgenti di rumore ovviamente non si esauriscono col rumore sismico e, per ognuna di esse, vengono adottate
tecniche di isolamento che, diverse esperimento per esperimento, esulano dallo
scopo di questa introduzione. Nella documentazione fornita dai vari rivelatori si
possono reperire informazioni sulle metodologie utilizzate (si vedano [6] e [7] per
VIRGO e LIGO rispettivamente).
LIGO e VIRGO non sono gli unici rivelatori interferometrici esistenti. Tra i
maggiori progetti attivi vanno indicati GEO 600 e TAMA 300, rispettivamente
in operazione ad Hannover (DE) e Tokyo (JP).
Con particolare interesse va citato il progetto LISA6 (Laser Interferometer
Space Antenna [8]) il cui scopo é costituire un osservatorio per onde gravitazionali
situato nello spazio. L’interferometro é costituito da tre satelliti in orbita attorno
al sole, che formano un triangolo equilatero con lato di 5 · 106 Km.
(a) Orbita
(b) Posizionamento
Figura 2.2: Schematizzazioni dell’esperimento LISA
Il progetto - in fase di realizzazione - si propone lo scopo di mantenere questi tre satelliti in orbita grazie ad un controllo inerziale in grado di mantenere
la posizione delle masse di prova con un errore inferiore ai 10nm. La grande
dimensione dei bracci dell’interferometro unita al rumore esterno estremamente
ridotto rispetto ai dispositivi terrestri fanno di LISA un progetto estremamente
promettente.
I rivelatori risonanti invece basano il loro funzionamento sull’utilizzo di una
antenna costituita da una massa che, attraversata dall’onda, varia le sue dimensioni. Il materiale e le caratteristiche geometriche dell’antenna vengono scelte in
modo tale che presenti una o piú risonanze nella banda di interesse (da cui il nome). Fanno parte di questa categoria di rivelatori quelli che utilizzano una barra
6
Lisa é un progetto dell’Agenzia Spaziale Europea (ESA) e di quella americana (NASA)
9
Capitolo 2. Onde Gravitazionali
(ALLEGRO7 , AURIGA8 , EXPLORER9 e NAUTILUS10 ) e quelli che utilizzano
una sfera (MiniGRAIL11 , Mario Schemberg12 , ecc). Entrambi i rivelatori utilizzano lo stesso principio, l’esistenza di due diverse tipologie é legata a motivi storici:
i rivelatori a barra risonante sono stati i primi ad essere progettati mentre quelli
sferici sono di piú recente concezione. I rivelatori a barra risonante, inoltre, sono
dotati di un preciso antenna pattern mentre quelli sferici sono isotropi cosicché
gli ultimi presentano uguale sensibilitá indipendentemente dalla direzione di incidenza dell’onda (questo a spese di una maggiore complessitá nella ricostruzione
dell’evento).
Come nel caso dei rivelatori interferometrici, la riduzione del rumore é di
fondamentale importanza per la misura, in particolare il rumore termico che dipende dal rapporto tra la temperatura T e il fattore di merito Q. Per ottenere
questo risultato i rivelatori risonanti sono racchiusi in criostati nei quali l’antenna viene portata a temperature criogeniche od ultracriogeniche. In questa
maniera si puó quasi annullare il moto browniano delle particelle e riuscire a misurare effettivamente le deformazioni dell’antenna dovute al passaggio di un’onda
gravitazionale.
2.5
L’esperimento AURIGA
AURIGA13 é l’antenna gravitazionale installata presso i Laboratori Nazionali
di Legnaro dell’Istituto Nazionale di Fisica Nucleare. Il rivelatore é costituito
dal una barra in lega di Alluminio mantenuta a temperature ultracriogeniche
mediante un criostato all’elio liquido [3].
I rivelatori risonanti sono schematizzabili come oscillatori armonici costituiti
da due masse unite da una molla e uno smorzatore viscoso. qParticolaritá di
k
questo sistema é l’oscillare alla pulsazione caratteristica ω0 = M
, dove k é la
costante elastica della molla e M é la massa. La barra di un rivelatore risonante
segue il precedente comportamento in cui la massa M , la lunghezza della molla
l, la pulsazione caratteristica ω0 e la costante di decadimento τ vanno calcolate
rispettivamente come
M=
Mbarra
,
2
l=
4Lbarra
,
π2
ω0 =
πvs
,
Lbarra
τ=
2Q
,
ω0
(2.1)
dove Mbarra , Lbarra sono rispettivamente la massa e la lunghezza fisica della barra
mentre vs é la velocitá del suono nel materiale. Si possono quindi scegliere le
caratteristiche fisiche e geometriche della barra in modo tale da ottimizzare la
sensibilitá, la banda di utilizzo, ecc.
7
LSU - Luisiana
I.N.F.N. - Legnaro (IT)
9
CERN - Ginevra (CH)
10
I.N.F.N. - Frascati(IT)
11
Leiden University - Leiden (NL)
12
Universitá di San Paolo - San Paolo (BRA)
13
Antenna Ultracriogenica Risonante per l’Indagine Gravitazionale Astronomica
8
10
2.5. L’esperimento AURIGA
Nel caso di AURIGA é stata utilizzata una barra in una lega di Alluminio
(AL5056) di lunghezza 3m e con un diametro di 60cm per un peso complessivo
di 2300Kg. Il materiale é stato scelto in maniera tale da assicurare buone caratteristiche al rivelatore, quindi una velocitá di propagazione del suono elevata
vs = 5400 m/s e un alto fattore di merito Q ' 107 . La lunghezza della barra invece é imposta dalla banda oggetto di studio. Il rivelatore deve infatti presentare
delle risonanze prossime alla frequenza di 1KHz.
Il cilindro dell’antenna viene mantenuto a temperature criogeniche mediante un criostato a due strati: quello piú esterno mantiene una temperatura dello
schermo a T ' 100K mentre quello piú interno porta la temperatura a T ' 20K.
Come tutti i rivelatori di onde gravitazionali va posta particolare attenzione nell’isolamento dell’antenna dal rumore dell’ambiente circostante. Per quanto riguarda l’isolamento da interferenze elettromagnetiche, questo dovrebbe essere fornito
dallo schermo costituito dai metalli che racchiudono la barra. Questi, essendo
a temperatura criogenica, diventano superconduttivi e quindi si prestano come
schermi magnetici anche per le componenti del campo perpendicolari alla superficie. L’isolamento acustico nella presente configurazione di AURIGA [3] [4] viene
ottenuto mediante due cavitá, OVC (Outer Vacuum Chamber) e IVC (Internal
Vacuum Chamber), nelle quali é stato creato il vuoto cosı́ da non permettere la
propagazione delle onde di pressione. La disposizione del criostato e delle citate
cavitá é visibile in Figura2.3(a). L’isolamento meccanico é fornito da un sistema
a due livelli. Il rivelatore é posto su di una piattaforma - separata dal resto del
laboratorio - che poggia su sabbia. Questa da sola fornisce un’attenuazione di
20dB. All’interno del criostato poi la barra viene sospesa mediante quattro colonne costituite da molle realizzate in una particolare lega di alluminio (Alumold
1-500) che, alla frequenza caratteristica di 1KHz, forniscono un’attenuazione di
240dB.
(a) Criostato
(b) Sospensioni
Figura 2.3: Schema della criogenia e degli stadi di attenuazione
del rumore sismico di AURIGA
La deformazione della barra, o meglio lo spostamento del suo modo fondamentale, viene misurata mediante un trasduttore capacitivo. Questo é costituito
11
Capitolo 2. Onde Gravitazionali
in prima approssimazione da un condensatore piano in cui un’armatura é solidale
con la barra mentre l’altra é un corpo risonante alla stessa frequenza della barra
costituito da una massa di circa 0.3Kg. Il sistema trasduttore/barra é equivalente a due oscillatori armonici accoppiati e quindi ogni variazione nella lunghezza
dell’antenna viene trasdotta in una variazione della distanza x(t) tra le armature
del trasduttore e dunque in una variazione di tensione ai capi del condensatore
come segue :
V (t) =
Q0
Q0
' E0 δx +
,
C(t)
C0
1
x0 + δx
1
δx
=
=
+
C(t)
0 S
C 0 0 S
(2.2)
dove 0 é la costante dielettrica del vuoto, Q0 , C(t) e S sono rispettivamente la
carica (costante), la capacitá al tempo t e la sezione del condensatore ed infine
E0 é il campo elettrico con cui viene polarizzato.
Figura 2.4: Vista dell’interno di AURIGA II. Si notano il sistema
di sospensioni, il gruppo readout+SQUID montato all’estremitá
della barra e i due stadi del criostato
Il segnale ottenuto dal trasduttore viene poi amplificato utilizzando un sistema a doppio SQUID14 . Quest’ultimo é un circuito amplificatore costituito da un
anello superconduttivo dotato di due giunzioni Josephson e utilizzato per misurare il campo magnetico proveniente da un pick-up accoppiato con il trasduttore.
Il segnale ottenuto all’uscita dello SQUID viene inviato al sistema di acquisizione. Oltre al segnale principale in uscita allo SQUID, vengono acquisiti almeno
una decina di canali ausiliari per monitorizzare l’ambiente attorno al rivelatore
(accelerometri, microfoni, sismometri, sonde elettromagnetiche, tiltmetri, ecc).
Questi dati sono utilizzati per anticorrelare i valori forniti dal canale antenna con
14
Superconducting QUantum Interference Device
12
2.5. L’esperimento AURIGA
il rumore proveniente dall’ambiente esterno, cosı́ fornendo un sistema robusto per
la diagnostica del sistema e la validazione dei risultati ottenuti.
13
Capitolo 3
Il DAQ
Nella realizzazione di un sistema di acquisizione (DAQ), vanno operate delle scelte atte a massimizzarne la produttivitá. In questo capitolo vengono descritti gli
apparati che sono utilizzati per il sistema di acquisizione, analizzandone le caratteristiche e le motivazioni che ne hanno giustificato la scelta. Successivamente
viene descritto brevemente il software componente il sistema di acquisizione nella
configurazione dalla quale si é partiti per lo sviluppo di questa tesi. Il DAQ in
questione é stato sviluppato dal personale del gruppo AURIGA e trova ampia
descrizione nei riferimenti [10] e [11]. La descrizione del software di acquisizione
vuole essere semplicemente un’introduzione al sistema che rende agevole la lettura dei capitoli successivi nei quali si tratteranno le modifiche che si sono rese
necessarie.
3.1
Il Sistema di Acquisizione
Gli strumenti utilizzati per il DAQ di AURIGA - sia hardware che software - sono
stati determinati in maniera tale da soddisfare i seguenti requisiti [12]:
Robustezza : Le sorgenti di onde gravitazionali che il rivelatore AURIGA si propone di misurare, essendo legate a processi astrofisici completamente al di
fuori del nostro controllo, devono essere sotto osservazione continua, di conseguenza il DAQ deve permettere un’acquisizione ininterrotta dell’antenna,
limitando al minimo gli stop del sistema dovuti a malfunzionamenti
Sincronizzazione : AURIGA fa parte di un network di rivelatori [9] e, affinché
sia possibile correlare i dati raccolti dagli altri rivelatori, questi devono
essere sincronizzati con lo standard di tempo universale (UTC) con un errore
massimo inferiore a 1µs
I/O Formattato : Per facilitare lo scambio dei dati con altri rivelatori, questi
vanno memorizzati in un formato standard. AURIGA a questo scopo ha
scelto il formato Frame [24], nato dalla collaborazione LIGO-VIRGO.
15
Capitolo 3. Il DAQ
Diagnosi efficiente : Il sistema di acquisizione deve inoltre facilitare la diagnostica in linea dell’esperimento, permettendo la visualizzazione e l’interpretazione di quanto viene acquisito (spia dei dati).
Per soddisfare le precedenti richieste, la versatilitá necessaria per un esperimento in continua evoluzione e la precisione occorrente per la misura, si é optato
per l’utilizzo, come DAQ, di un PC a cui é connesso un crate VXI contenente
la strumentazione di misura. Nei paragrafi successivi verranno analizzati tutti i
componenti del sistema assieme alle caratteristiche che li contraddistinguono.
3.2
La strumentazione VXI
Lo standard hardware adottato per la strumentazione del DAQ é il VXI. Differenza fondamentale di questo dagli altri standard (VME, PXI, ecc.) é che completa
la definizione delle specifiche della strumentazione aggiungendo precisi requisiti
riguardanti la schermatura e il raffreddamento degli apparati. Con l’adozione del
VXI si é quindi voluto garantire i livelli massimi di rapporto segnale/disturbo per
l’acquisizione.
(a) Crate HP E1401A
(b) NI VXI-PCI8026
Figura 3.1: Mainframe e dispositivi di interfacciamento.
La strumentazione VXI é costituita da schede - C-size o B-size - che vengono
inserite in un crate o mainframe (nel caso specifico l’HP E1401A - Figura 3.1(a)).
Quest’ultimo é il responsabile delle comunicazioni tra le schede inserite, fornisce
le rispettive sorgenti di alimentazione e si occupa del raffreddamento del sistema.
Lo standard VXI permette la creazione di sistemi di acquisizione espandibili grazie alla sua modularitá. Uno stesso crate puó ospitare qualsiasi tipo di dispositivo
dotato di interfaccia VXI e, nel caso in cui si debbano utilizzare piú schede di
quante ne possano essere ospitate da un singolo crate, il sistema puó essere esteso collegando vari mainframe in “daisy-chain”, il tutto in maniera trasparente
all’utente.
16
3.3. Il GPS e la sincronizzazione
La comunicazione tra i dispositivi VXI ed il “sistema PC Host” é affidata al
kit National Instruments VXI-PCI8026 (Figura 3.1(b) - [27]). Questo é costituito
da due interfacce: una scheda PCI che permette la comunicazione tra il PC e il
bus MXI1 e una scheda VXI che connette il bus MXI al VXI. Se quest’ultima
viene inserita nello slot 0 - che ha una piedinatura diversa dagli altri - il controller puó svolgere funzioni di temporizzazione del bus, di arbitraggio e gestire le
interruzioni. L’intero kit permette di connettere un insieme di strumenti al bus
PCI in modo praticamente trasparente. Con l’utilizzo dei driver forniti a corredo
i trigger diventano gestibili dal PC, nel sistema host le interruzioni generate dalle
schede VXI vengono rilevate come se fossero locali ed infine é possibile utilizzare
memoria condivisa tra il PC e la strumentazione. Le precedenti caratteristiche
assieme ad una banda verso la strumentazione di 33MB/s (23MB/s in utilizzo
continuo), ottenuta mediante l’utilizzo di buffer e DMA, rendono il VXI-PCI8026
piú che adeguato per il DAQ di AURIGA.
3.3
Il GPS e la sincronizzazione
Il sistema GPS (Global Positioning System) - di proprietá del dipartimento della
difesa americano - é costituito da una costellazione di 24 satelliti in orbita a circa
20.2 Km2 . Ogni satellite contiene orologi atomici (al cesio e al rubidio) dai quali
viene ricavato il segnale da trasmettere. Progettato per scopi militari, l’utilizzo
del GPS permetterebbe ad un ricevitore di determinare la propria localizzazione
in maniera accurata misurando i ritardi di propagazione dei segnali provenienti
dai satelliti (almeno 4 per stimare correttamente la posizione). Affinché il sistema consenta la precisione necessaria agli scopi militari, l’errore massimo ammesso
nella temporizzazione proveniente dalla costellazione di satelliti é di 100ns; tuttavia all’atto della messa in opera del sistema di posizionamento é stato ritenuto
inopportuno - per ovvie ragioni - permettere a chiunque la possibilitá di localizzare un qualunque oggetto con la precisione di qualche decina di centimetri per cui
il segnale trasmesso viene codificato con un algoritmo di scrambling non noto che
ne innalza l’errore a circa 150ns. In questo modo il segnale rimane di pubblico
utilizzo ma con diversa precisione a seconda dell’utilizzo a cui si é ammessi.
Il sistema di acquisizione di AURIGA sfrutta i segnali inviati dai satelliti GPS
per mantenere la sua temporizzazione con un errore (cfr. 3.1) inferiore a 1µs.
Tale scopo viene raggiunto mediante un ricevitore GPS prodotto da ESAT, precisamente l’ESAT GPS 100 [13], il quale riesce a contenere l’errore commesso nel
timing ad un livello inferiore ai 150ns che si otterrebbero utilizzando direttamente
il segnale GPS per utilizzi civili.
La temporizzazione fornita dal sistema ESAT GPS 100 proviene da un oscillatore locale (VCO) altamente stabilizzato che viene adoperato come sorgente di
1
Lo standard MXI stabilisce le specifiche utilizzate per il bus che connette i crate VXI. Nella
connessione di un crate ad un PC come in Figura 3.1(b), il bus MXI é costituito dal cavo che
connette le due interfacce.
2
I satelliti hanno un periodo di rivoluzione di circa 12 ore
17
Capitolo 3. Il DAQ
clock a breve termine. Il segnale ricevuto dai satelliti GPS viene utilizzato per
correggere lo sfasamento dell’oscillatore sul lungo periodo utilizzando un anello ad
aggancio di fase. Con questo accorgimento l’errore del GPS viene statisticamente
ridotto e si ottiene una precisione che arriva a 70ns.
Il GPS 100 é in grado di fornire un segnale a 10MHz (su due porte) e un PPS
(Pulse Per Second) in fase con il primo. Il segnale a 10MHz viene utilizzato per la
temporizzazione dell’ADC connesso all’antenna (vedi paragrafo 3.4) e il secondo
per effettuare diagnostica o calibrazione del sistema. Inoltre il ricevitore é dotato
di tre porte seriali mediante le quali é possibile ottenere informazioni sullo stato
del GPS (statistica) e pacchetti contenenti le informazioni per la datazione di
eventi (timestamp).
Il sistema GPS utilizzato da AURIGA é completato dalla scheda S80, un’interfaccia con 8 canali di ingresso optoisolati. Utilizzando questo dispositivo é
possibile inviare al GPS un segnale e ottenerne il suo tempo di invio mediante
interfaccia seriale, con l’errore di 70ns precedentemente indicato. Questa é la modalitá di funzionamento utilizzata dal DAQ, grazie alla quale é possibile datare
in maniera accurata ogni buffer di dati che viene acquisito dalla strumentazione
[5].
3.4
Il canale Antenna
Il DAQ di AURIGA dispone di due ADC per le diverse caratteristiche dei segnali
che vengono acquisiti; il canale principale é costituito dall’uscita dello SQUID,
cioé dal segnale proveniente dall’antenna.
Nella scelta dell’ADC da utilizzare intervengono molti fattori, tra cui la banda passante, la distorsione introdotta e le possibili modalitá di funzionamento
dell’apparato ma, fondamentale per questo tipo di acquisizione é la precisione
con cui avviene la conversione. Come indicato nel Capitolo 1, il segnale captato
dall’antenna, per la sua debolezza, é dominato dal rumore ed é quindi indispensabile che il numero di bit in con cui viene convertito sia sufficiente a garantire
che la presenza di un evento gravitazionale non venga mascherata dal rumore di
quantizzazione introdotto nella conversione analogica/digitale.
L’errore di quantizzazione é dovuto alla discretizzazione del valore acquisito
e il suo valore (in modulo) aumenta con l’ampiezza dell’intervallo ∆. Date le sue
caratteristiche l’errore di quantizzazione é modellabile come una variabile random distribuita uniformemente tra − ∆2 e + ∆2 e quindi media e varianza valgono
rispettivamente :
∆2
(3.1)
12
Lo spettro del rumore di quantizzazione, considerato come processo nel dominio del tempo discreto, bianco e a media nulla, é dato da:
2
σQ
= E[e2 ] =
mQ = E[e] = 0
SQ (ω) =
X
n
RQ (n)e−inφ =
∆2
12
18
con RQ (n) =
∆2
δn0
12
(3.2)
3.4. Il canale Antenna
La stima del numero minimo di bit da utilizzare puó essere effettuata mediante
alcune considerazioni sulla forma dello spettro S(ω) dell’uscita dello SQUID.
In assenza di un evento gravitazionale, in esso sono presenti due componenti:
una prima a banda larga SW B dovuta al rumore dell’amplificatore SQUID e una
seconda a banda stretta SN B (ω) costituita dai picchi attorno ai quali il sistema
entra in risonanza. Affinché la conversione introduca un contributo di rumore
trascurabile é necessario che SQ (ω) sia trascurabile rispetto allo spettro S(ω) =
SN B (ω) + SW B . Considerando lo spettro in prossimitá di un picco3 si ha che
l’RMS del segnale a banda stretta SN B (ω) é nettamente superiore di quello a
banda larga SW B , infatti integrando lo spetto del segnale su tutta la banda si
ottiene:
2
2
σ 2 = σW
B + σ N B ' S 0 Fc +
Γω0 S0
2Q
(3.3)
dove Γ = SW B /SN B (ω0 ) é il rapporto tra il livello del rumore a banda larga e
quello a banda stretta al massimo in ω0 e Fc é la frequenza di campionamento. Il
primo addendo é il contributo del rumore a banda larga mentre il secondo é quello
del picco di risonanza. L’obbiettivo del calcolo proposto consiste nel determinare
la precisione della conversione affinché il rumore di quantizzazione non degradi il
segnale acquisito. Lo spettro del segnale campionato deve essere quindi maggiore
del rumore di quantizzazione, ovvero :
∆2
.
(3.4)
12
Imponendo che la dinamica dello strumento - cioé il fondo scala A - sia N
volte maggiore del rumore a banda stretta σN B otteniamo:
2
σW
B ∆
A
s
24QFc
N 2 Γω0
con A = N σT
e σT2 =
Γω0 S0
.
2Q
(3.5)
Sostituendo nella precedente espressione il valore atteso per le variabili, ovvero
√
Γ = 105
N = 100 Q = 5 · 106
ω0 = 5 · 104
T = 10−4 s
(3.6)
si ottiene il risultato richiesto, cioé ∆/A 4.9 · 10−4 ' 10−5 . Affinché siano
rispettati i requisiti dati per l’acquisizione dell’antenna la conversione analogico/digitale deve avvenire con almeno 5 cifre significative. Essendo il numero di
bit necessari per l’ADC dato dal logaritmo in base 2 di ∆/A, si ottiene immedia' 18 bit. In base
tamente che il convertitore deve utilizzare almeno n = log 2 ∆
A
ai requisiti illustrati, per il canale antenna é stato scelte l’Agilent E1430 [15], un
ADC a 23 bit in formato VXI, in grado di operare a 10 MSa/s, il cui utilizzo
tipico é il testing di apparati per telecomunicazioni. Il dispositivo E1430 é di
3
Analoghi risultati si ottengono considerando piú picchi, per esempio i dieci picchi piú significativi per il sistema. Tuttavia, vista la qualitativitá del calcolo proposto ci si pone in
prossimitá della risonanza della barra il cui picco ha un’ampiezza superiore agli altri di alcuni
ordini di grandezza.
19
Capitolo 3. Il DAQ
tipo C-Size e supporta pienamente lo standard VXI. L’accesso al dispositivo é
possibile sia mediante il linguaggio SCPI4 che operando direttamente sui registri.
Figura 3.2: Schema semplificato del dispositivo Agilent E1430
La modalitá con cui avviene l’acquisizione é stata schematizzata in Figura 3.2.
Il segnale presente all’ingresso puó essere accoppiato sia in AC che in DC, con
un’impedenza di di 50Ω al preamplificatore di ingresso di cui é possibile regolare
il guadagno. Il passo successivo consiste nell’applicazione di un filtro analogico
antialiasing che, come buona parte delle caratteristiche dello strumento, puó essere attivato o escluso a discrezione dell’utente. In uscita dal filtro avviene la
conversione analogico/digitale mediante l’ADC a 23 bit e viene effettuata sempre
alla frequenza di campionamento di 10MHz. La riduzione o lo zoom alla frequenza di campionamento desiderata viene affidata al DSP posto all’uscita dell’ADC
che provvede alla decimazione del segnale in base alla programmazione dell’apparecchio. La parola a 23 bit viene infine memorizzata all’interno di una memoria
RAM dalla capacitá di 8MB che viene gestita come una FIFO, permettendo la
bufferizzazione temporanea dei dati acquisiti.
Il clock con cui la scheda E1430 lavora puó essere prelevato dal bus VXI,
generato interamente oppure fornito dall’esterno mediante un segnale TTL da
applicare all’apposito connettore BNC posto sul frontalino dello strumento. Visti i requisiti stringenti di temporizzazione dell’esperimento AURIGA, l’ultima
modalitá é quella adoperata, utilizzando una delle uscite a 10MHz del ricevitore
GPS ESAT 100 come sorgente del clock.
Mediante l’utilizzo dei registri é possibile impostare tutte le funzionalitá dello strumento. In primo luogo la frequenza di campionamento viene ottenuta
attraverso la divisione del clock fornito all’ingresso: nel caso di AURIGA questo divisore viene solitamente impostato a 11 ottenendo una frequenza finale di
10M Hz/211 = 4882.8125Hz, che é il frutto di un compromesso tra la linearitá del
sistema nella banda tra 800 e 1100Hz e l’occupazione di spazio per la memorizzazione dei dati. Infatti, sebbene la frequenza di campionamento immediatamente
inferiore sia circa 2.4KHz, sufficiente quindi per acquisire i segnali nella banda
del sistema, DAQ viene fatto solitamente operare a 5KHz perché a tale frequenza
la distorsione introdotta dal DSP posto all’uscita dell’ADC é minima (Cf. 5.1.2).
Nel dispositivo Agilent E1430 sono impostabili varie opzioni come l’utilizzo
di trigger (sia interni che esterni), il formato dei dati di uscita (16 o 32 bit, reali
o complessi), l’introduzione di un offset5 , la programmazione di interruzioni e
buffer di memoria.
4
5
La libreria SCPI non é disponibile per Linux
La correzione dell’offset é stata resa disponibile nella versione del DAQ successiva al porting
20
3.4. Il canale Antenna
Nel dispositivo E1430 i valori in uscita all’ADC vengono memorizzati nella
FIFO senza subire conversioni: sono quindi numeri interi a 23 bit che rappresentano il livello di quantizzazione del segnale in ingresso. Nel trasferimento dei
dati al calcolatore, questi vengono convertiti in interi a 32 bit per ragioni di allineamento; per ottenere i valori in virgola mobile da memorizzare nei frame é
dunque sufficiente che il DAQ li moltiplichi per un coefficiente che dipende dal
fondo scala utilizzato nell’acquisizione.
La modalitá di acquisizione in cui opera la scheda Agilent E1430 é l’ acquisizione continua in cui l’ADC converte i dati e li deposita nella FIFO senza alcun
controllo su un eventuale riempimento di quest’ultima, nel qual caso rimangono
disponibili all’utente gli ultimi 2MSa letti.
Di particolare interesse é la possibilitá di gestire le interruzioni sollevabili dallo
strumento visto che hanno fornito la possibilitá di temporizzare correttamente i
dati acquisiti. La scheda Agilent E1430 é in grado di generare due interrupt
distinti collegati al verificarsi di un evento, delle quali é possibile impostare il
livello di prioritá. Nello standard VME/VXI, il bus presenta sette linee - attive
basse - che rappresentano lo stato dei sette possibili livelli di interruzione. Gli
strumenti in grado di generare interruzioni possono modificare il livello di queste
linee per propagare lungo il bus e/o ad altri “crate” l’evento. La quantitá ridotta
di linee di interruzione non limita il numero degli IRQs, infatti piú strumenti
possono sollevare lo stesso livello di interruzioni il cui riconoscimento, in questo
caso, avviene in daisy-chain. Il 1430 puó sollevare un’interruzione in seguito al
verificarsi di 6 possibili eventi, in base alla programmazione del registro 1416 , in
particolare quando :
• almeno un dato (word) é disponibile per la lettura
• la FIFO contiene almeno un blocco di dati
• la scheda é armata e pronta per l’acquisizione
• l’acquisizione é stata fermata
• si é verificato un overload6
• si é verificato un errore hardware
Nel DAQ di AURIGA viene utilizzata una sola delle due interruzioni per segnalare la presenza di un blocco di dati nella FIFO. Il sistema di acquisizione
infatti, all’avvio programma l’ADC affinché acquisisca in maniera continua il segnale e avverta mediante un’interruzione quando la FIFO contiene 64KB (cioé
16KSa) di dati; in questa maniera i trasferimenti dal bus VXI avvengono in modalitá bursty, riuscendo a sfruttare meglio le caratteristiche dell’hardware (buffer
e DMA) e rendendone piú comoda la gestione nel software.
6
Tensione all’ingresso superiore al fondo scala utilizzato
21
Capitolo 3. Il DAQ
La cosa interessante dell’utilizzo delle interruzioni nel DAQ di AURIGA é che
sono state sfruttate per la temporizzazione. Allo scopo é stata sviluppata una
scheda VXI C-size che permette l’estrazione dei livelli delle linee di interruzioni
dal bus VXI. Questa in realtá altro non é che un buffer invertente che si frappone
fra i connettori posti sulla scheda di estrazione e le linee del bus, permettendone
l’isolamento e fornendo all’uscita un segnale con caratteristiche TTL.
Le linee delle interruzioni cosı́ estratte, vengono inviate alla scheda S80 del
ricevitore GPS presentata nella Sezione 3.3. Con questo sistema, il sollevarsi di
un interrupt genera un evento che viene datato dal GPS e quindi, per ogni buffer
che viene acquisito si puó leggere dalla seriale del PC il tempo del suo completamento, ottenendo in questo modo la datazione dei dati con un errore assoluto pari
a quello del ricevitore GPS. In realtá il tempo che viene letto presenta un errore
sistematico pari alla latenza dell’interruzione, cioé é presente un offset temporale
dovuto al tempo necessario per la generazione dell’interrupt e al suo ritardo di
propagazione. Tale inconveniente é stato superato nella versione del DAQ successiva al porting mediante una procedura automatizzata che stima la latenza
dell’interrupt e permette la correzione del timing del canale principale.
3.5
I canali Ausiliari
Al segnale proveniente dal rivelatore ne devono essere affiancati altri di monitor
per poter determinare se i segnali acquisiti hanno origine locale. Per fare ció si
utilizzano alcuni canali ausiliari a cui sono connessi dispositivi come sismometri,
tiltmetri, accelerometri, sonde magnetiche, microfoni, ecc. per poter identificare
i disturbi presenti nell’ambiente circostante il rivelatore.
A differenza del segnale proveniente dallo SQUID, dai canali ausiliari provengono segnali lenti, cioé per i quali non é necessario un campionamento ad alta
frequenza. Inoltre il livello delle tensioni é molto maggiore (gli ausiliari non sono dominati dal rumore) e quindi non sono necessari ADC con caratteristiche
analoghe all’Agilent E1430. Per queste ragioni si é optato per l’acquisto di un
secondo strumento da impiegare per l’acquisizione dei soli ausiliari. É da escludere la possibilitá di utilizzare uno stesso ADC con gli ingressi multiplexati per
acquisire contemporaneamente sia il canale Antenna che gli ausiliari dato che per
gli ultimi sono necessari molti canali (almeno una decina) e in commercio non
sono disponibili strumenti con caratteristiche analoghe all’Agilent E1430, con un
numero di ingressi sufficiente. Inoltre negli ADC con ingressi multiplexati quando
vengono impostate le modalitá con cui effettuare l’acquisizione, queste vengono
tipicamente utilizzate per tutti i canali. Optando per un sistema di questo tipo si sarebbe costretti ad acquisire i canali ausiliari con la stessa frequenza di
campionamento del’antenna e quindi, anche se ovviamente non viene peggiorata
la qualitá del segnale, si ottiene un’inutile esplosione della quantitá di dati da
gestire. Per esempio, nell’utilizzo attuale del DAQ - Antenna piú 10 ausiliari - si
passerebbe da un troughput di circa 27KB/s (' 2.4 GB/giorno) a circa 215KB/s
(' 18.6 GB/giorno).
22
3.5. I canali Ausiliari
Lo strumento che é stato scelto é l’HP 1413 (ora VT1413C, prodotto da VXItech [16]), un ADC C-size a 16 bit in grado di operare ad un massimo di 100KSa/s7
su 64 canali multiplexati [14].
Figura 3.3:
HP 1413
Schema di funzionamento semplificato dell’ADC
In Figura 3.3 é riportata una schematizzazione semplificata del circuito d’ingresso dell’ADC. Prima degli SCP (Signal Conditioning Plug-on), nello strumento é presente una batteria di relays (non indicata nella figura) che permette di
selezionare se all’ingresso degli SCP deve giungere il segnale proveniente dal connettore presente sul frontalino dello strumento oppure un segnale di calibrazione
(uguale per tutti i canali). Questo serve perché la scheda HP 1413 puó calibrarsi
autonomamente basandosi su di un riferimento generato internamente. Lo stesso riferimento poi, puó essere calibrato mediante una tensione - molto stabile fornita dall’esterno. Subito dopo il blocco di relays il segnale arriva agli SCP, dei
circuiti di condizionamento dei segnali la cui presenza é obbligatoria per ogni canale che si vuole utilizzare. Essi si presentano sotto forma di una daughter-board
che va installata all’interno della scheda VXI. Ogni SCP é in grado di gestire
otto canali e all’interno del 1413 possono essere installati tipi diversi di SCP
permettendo quindi di ottenere un diverso comportamento dei vari ingressi. In
commercio sono disponibili diversi tipi di SCP che permettono di filtrare e/o amplificare il segnale in ingresso, di fornire delle sorgenti in uscita, che effettuano il
sample-and-hold, ecc. Nel caso di AURIGA sono stati installati 3 SCP VT1503A
[16], cioé dei circuiti che permettono il filtraggio degli ingressi con un passa basso a due poli la cui frequenza di taglio puó essere impostata a 2, 10 e 100Hz
oltre che in modalitá pass-through con banda passante approssimativamente di
1.5KHz. Inoltre l’SCP contiene 8 amplificatori programmabili che permettono
di variare il fondo scala utilizzabile a ±0.25V , ±2V e ±16V . Grazie a questa
configurazione il DAQ di AURIGA permette l’acquisizione contemporanea di 24
canali ausiliari, oltre ovviamente al canale dell’antenna.
I segnali condizionati vengono quindi inviati ad un multiplexer realizzato in
tecnologia FET che viene gestito mediante scanning list, una lista ordinata di
canali programmata dall’utente. Nell’ADC HP 1413 se ne possono impostare
7
La velocitá massima di acquisizione é pari a 10KSa/s su di un singolo canale. I 100KSa/s
sono la banda massima dell’intero ADC, raggiungibile utilizzando piú ingressi
23
Capitolo 3. Il DAQ
fino a 4 diverse fornendo quindi la possibilitá di commutare al volo l’elenco e/o
l’ordine dei canali da utilizzare. Ad ogni ciclo di campionamento, lo strumento provvede ad acquisire tutti i canali elencati introducendo un ritardo (la cui
granularitá é pari a 10µs) impostabile mediante un registro. I dati in uscita dal
multiplexer giungono finalmente alla sezione di conversione vera e propria dove
possono venire ulteriormente trattati ed infine convertiti mediante un ADC a 16
bit. Successivamente all’ADC i dati vengono convertiti nel formato IEEE-754
e quindi memorizzati in una RAM di 64KSa gestita come FIFO. In aggiunta
a questa esiste una seconda memoria chiama CVT (Current Value Table) nella
quale vengono memorizzati i dati dell’ultima scansione permettendone quindi un
accesso diretto.
La frequenza di campionamento che si imposta viene utilizzata per tutti i
canali, per la precisione il sampling time che viene programmato é l’intervallo tra
l’esecuzione di due scanning list. Lo strumento non permette l’utilizzo di un clock
esterno e quindi esso viene prelevato dal bus VXI. Tuttavia é possibile fornire un
clock esterno al bus di un crate mediante l’utilizzo dell’interfaccia MXI/VXI (se
installata nello slot-0) oppure sfruttando una caratteristica dell’Agilent E1430
grazie alla quale lo strumento puó propagare all’intero mainframe il clock esterno
che gli viene fornito.
La partenza di una acquisizione puó avvenire mediante trigger hardware o software, oppure si puó settare il dispositivo affinché operi in acquisizione continua
(modalitá free-run). Per poter impostare una precisa frequenza di campionamento si é utilizzata la modalitá soft-trigger (cioé con trigger generato dal 1413
stesso). In questo modo ogni scansione dei canali da acquisire inizia l’arrivo di un
trigger e la frequenza di quest’ultimo é impostata alla frequenza di campionamento desiderata. Come per il 1430 anche nel 1413 si é sfruttato il meccanismo delle
interruzioni (l’unica sollevabile) per il timing dei dati acquisiti. In particolare
il sistema permette di generare un’interruzione al verificarsi dell’evento “buffer
half-full” che é stata utilizzata per informare il PC della presenza di 32 KSa nella FIFO dello strumento. Anche in questo caso il segnale di interruzione viene
estratto dal bus con la scheda custom indicata in Sezione 3.4 per venire inviato
alla scheda S80 del ricevitore GPS, ottenendo ancora una volta la datazione di
ogni pacchetto di 32KSa con l’errore assoluto commesso dal GPS.
3.6
Il sistema Host
Mediante il kit di interfacciamento PCI-VXI della National Instruments, alla
strumentazione é connesso un personal computer che si occupa della gestione
dell’hardware: dalla configurazione e controllo, alla raccolta, formattazione e
memorizzazione definitiva dei dati acquisiti.
Il PC utilizzato si basava su un’architettura di calcolo i686 in cui i componenti
rilevanti per il DAQ sono:
• Scheda Madre ABIT VP6 con chipset VIA Apollo Pro 133A
24
3.6. Il sistema Host
• 2 Microprocessori Intel Pentium III Coppermine a 800MHz (800/133MHz)
• 512 MB di memoria SDRAM a 133MHz
Oltre alle prestazioni, nella scelta dell’hardware aveva influito la struttura del
DAQ che, come si vedrá nella sezione successiva, é costituito da vari processi
indipendenti che girano in parallelo. In quest’ottica la scelta migliore é stata
l’architettura SMP grazie alla quale vengono eseguiti contemporaneamente due
processi. Il quantitativo di memoria RAM é stato dimensionato in base alle
richieste del DAQ: oltre al semplice calcolo dell’occupazione dei buffer di dati,
si é verificato che in esecuzione non viene mai richiesta al sistema una capacitá
superiore a mezzo gigabyte.
Figura 3.4: Case Supermicro SC830
Per le ragioni indicate in Sezione 3.1, nel dimensionamento del sistema si
é cercato di ottenere la massima resilienza possibile, duplicando i componenti
con maggiore probabilitá di rottura. Il PC é stato quindi alloggiato in un case
Supermicro SC830 (Figura 3.4), dotato di due alimentatori e di un sistema di
monitoraggio degli stessi in maniera tale che, in caso di rottura, il PC possa
continuare ad operare fino alla sostituzione dell’alimentatore guasto, operazione
che puó avvenire a caldo. Lo chassis inoltre dispone di un sistema di ventilazione
sovradimensionato in maniera tale che sia impossibile incorrere in problemi di
surriscaldamento indipendentemente dal carico della macchina e dalla durata del
run.
Altro componente delicato per un PC sono i dischi fissi e quindi, anche se
attualmente la memorizzazione dei dati avviene su di un server NFS (via rete e
non in locale), si é scelto di adottare una scheda madre dotata di un controller
IDE RAID, precisamente l’High Point Technologies HPT370. Gli HD installati
nel PC di acquisizione servono ad aumentare la resilienza dell’intero sistema anche in un’altra modalitá: nel caso di un guasto della rete o del server NFS. Nel
DAQ é infatti prevista la possibilitá di memorizzare i dati in due percorsi contemporaneamente (in modo simile al mirroring) ed é anche possibile modificare
il percorso senza interrompere l’acquisizione. Grazie a queste caratteristiche, in
caso di malfunzionamento della rete il sistema puó continuare a memorizzare i
dati localmente mantenendo un livello di affidabilitá accettabile.
25
Capitolo 3. Il DAQ
Come sistema operativo - e quindi come ambiente di sviluppo - é stato scelto
Linux per la sua natura open source e per le prestazioni ottenibili dal suo utilizzo.
In particolare si é optato per Red-Hat Linux 6.2 - anche se giá superato all’epoca
della prima messa in opera del sistema - per due ragioni: l’ampia diffusione fra
l’utenza ne assicurava la stabilitá e il supporto, e i vincoli imposti dalle librerie
fornite da National Instruments. Il DAQ infatti é in esecuzione su di un kernel
2.2.18 SMP, questo per poter compilare la libreria ni-vxi 1.6.2, necessaria per
l’utilizzo dell’interfaccia PCI-VXI.
3.7
L’Ambiente di Sviluppo
L’intero sviluppo del DAQ é avvenuto mediante strumenti open source. Il linguaggio di programmazione scelto é stato il C++ dato che era richiesto il pieno
supporto del paradigma OOP, la velocitá di esecuzione del compilato e la possibilitá di interfacciarsi a basso livello con il PC, ad esempio per l’interrogazione degli
strumenti. Come compilatore é stato utilizzato GCC, nella versione egcs-2.91.66,
le cui prestazioni sono state dimostrate dalla diffusione e utilizzo nell’intera comunitá open-source. Per lo sviluppo del sistema e la sua gestione si é scelto
l’ambiente grafico KDE 2.1, basato su QT 2.2, tra i cui componenti é presente
anche l’ambiente di sviluppo integrato (IDE) che é stato adottato: KDevelop 1.4.
Lo sviluppo dell’interfaccia grafica del sistema (GUI ) é avvenuto in QT, utilizzando il QTdesigner per la progettazione dei form e il compilatore (preprocessore)
uic per la generazione del codice sorgente da compilare con GCC.
L’adozione di software open-source ha reso possibile l’utilizzo, oltre che di
strumenti quali quelli precedentemente citati, anche di librerie e/o collezioni di
sorgenti - di utilizzo generale - prodotti da terzi con licenza GNU. Questo ha
facilitato l’implementazione del sistema riducendone i tempi di sviluppo; l’utilizzo
di librerie disponibili pubblicamente ha inoltre permesso di integrare componenti
giá testati nel sistema migliorandone la stabilitá. Vengono di seguito presentati
i pacchetti software di maggiore interesse che sono stati integrati all’interno del
DAQ di AURIGA.
3.7.1
omniORB
Il DAQ é stato progettato come un insieme di processi interagenti in un’architettura client/server distribuita; come protocollo a supporto dello scambio di informazioni si é scelto CORBA [20], cioé il Common Object Request Broker Architecture, un insieme di specifiche atte a realizzare un software distribuito, orientato
agli oggetti e indipendente dalla piattaforma utilizzata. CORBA, come proposto
dall’OMG (Object Management Group [19]) , é uno standard aperto, prodotto da
un consorzio e quindi indipendente dal singolo produttore, per costruire un’infrastruttura attraverso la quale diversi applicativi possono collaborare utilizzando
una rete. La comunicazione avviene attraverso l’implementazione di un “BUS
software” chiamato ORB (Object Request Broker) mediante il quale gli oggetti
26
3.7. L’Ambiente di Sviluppo
distribuiti possono scambiare dei messaggi. L’interoperabilitá e l’indipendenza
dalla piattaforma utilizzata vengono assicurate da due strumenti:
1. l’impiego di un linguaggio standard per la specifica delle interfacce dei
processi;
2. l’adozione di un protocollo comune per la comunicazione.
Il primo obbiettivo viene raggiunto grazie all’OMG IDL (Interface Definition
Language) che viene utilizzato per la definizione dell’interfaccia di un oggetto:
la specifica dei metodi da esportare mediante CORBA, i tipi di dato dei parametri, ecc., vengono dichiarati con questo linguaggio indipendentemente dall’implementazione di CORBA utilizzata. Al secondo si giunge mediante l’uso di due
protocolli: il GIOP (General Inter-ORB Protocol) che definisce il formato e la
rappresentazione dei dati scambiati da tutti gli oggetti distribuiti in uno stesso ORB e l’IIOP (Internet Inter-ORB Protocol) che é una implementazione del
protocollo GIOP che si avvale del TCP/IP per realizzare lo strato di trasporto. Ogni implementazione di CORBA puó introdurre caratteristiche aggiuntive
a quelle citate ma, per poter dichiarare di aderire allo standard CORBA, deve
implementare obbligatoriamente l’IDL e l’IIOP.
Per il DAQ di AURIGA é stato utilizzato omniORB 3.0.4 [21], un’implementazione GNU di CORBA 2.3 della AT&T (divenuto ora un progetto indipendente).
La scelta é stata in favore di questo prodotto per le caratteristiche di stabilitá e
funzionalitá. Essendo inoltre un’implementazione completamente multithread di
CORBA permette di sfruttare piú conveniente l’architettura SMP scelta per il
sistema di acquisizione.
3.7.2
OSE
La libreria OSE [23] consiste in una raccolta di software general purpose distribuita gratuitamente grazie alla licenza QPL. Le sue funzionalitá sono molto varie
e solo un sottoinsieme degli oggetti vengono effettivamente utilizzati nel DAQ
di AURIGA. Uno degli scopi di OSE consiste nell’aumentare la portabilitá del
software tra diversi compilatori C++ grazie alla tattica di naming utilizzata. In
essa vengono definiti dei tipi base che sono largamente utilizzati nella libreria
stessa e, se adottati nello sviluppo del software, permettono al sorgente di essere compilato su diverse piattaforme o compilatori semplicemente includendo la
libreria nel progetto. Altre funzionalitá di OSE che sono state sfruttate sono la
possbilitá di effettuare comunicazioni interprocesso stream based e la “Message
Log Facility”, grazie alle quali é possibile intercettare i messaggi di errore generati da un processo. Ad esempio il logger (LOG) del DAQ che verrá introdotto
successivamente sfrutta queste caratteristiche di OSE per intercettare i messaggi
d’errore che possono venire generati dai processi del DAQ. Parte della gestione
delle stringhe infine é stata implementata grazie a OSE, laddove questa si é resa
di maggiore utilitá rispetto all’implementazione standardizzata del C++.
27
Capitolo 3. Il DAQ
Come accennato, le precedenti funzionalitá sono solo un sottoinsieme delle
caratteristiche della libreria che permette ad esempio la gestione della memoria,
delle eccezioni, fornisce un insieme completo di “contenitori” di utilizzo generico
(vettori, liste, insiemi, ecc), permette la programmazione event-driven oltre a
fornire wrapper verso altri linguaggi come Pyton. Per approfondire le funzionalitá
di OSE si rimanda alla documentazione online [23].
3.7.3
Frame Library
Il formato Frame o IGWD [24] é uno standard che permette la memorizzazione
di tutti i dati relativi ad un rivelatore di onde gravitazionali (posizione, set-up,
ecc.) assieme ai dati acquisiti, ai risultati delle analisi effettuate e ai dati di
simulazione montecarlo. Prodotto dalla collaborazione LIGO-VIRGO, permette
di raggiungere un’uniformitá del trattamento delle informazioni precedentemente
non possibile, permettendo - se correttamente utilizzato - di rendere indipendenti
gli applicativi dal formato dei file utilizzato per l’elaborazione. Un software per
l’analisi ad esempio, se determina la configurazione del rivelatore in base a quanto
memorizzato nei frame puó operare indifferentemente sui dati prodotti nello stesso
esperimento che ha concepito l’analisi o su quelli di un altro rivelatore, a patto
che il software di acquisizione si occupi della corretta formazione del Frame.
Il Frame (Figura 3.5) altro non é che un contenitore nel quale possono essere
inserite - mediante puntatori - sottostrutture contenenti informazioni organizzate per categoria. Un’insieme delle sottostrutture é dedicato all’utilizzo online,
cioé da parte del sistema di acquisizione; tra queste trovano posto le informazioni relative alla posizione del rivelatore (FrDetector), ad un eventuale registro di
log (FrHistory) oltre ovviamente ai dati raw che vengono memorizzati canale per
canale (FrAdc). Il frame viene completato successivamente all’acquisizione degli
applicativi di analisi per i quali sono state previste delle apposite sottostrutture
grazie alla quali il frame diviene omnicontenitivo, nel senso che al suo interno
vengono memorizzati tutti i risultati dell’esperimento, cessando cosı́ la necessitá
di file ausiliari. L’ultima sezione del frame é dedicata ai dati simulati in modo
da poter operare in maniera uniforme anche su di essi. L’organizzazione gerarchica del frame, oltre a semplificarne l’utilizzo da un punto di vista concettuale,
migliora le prestazioni degli applicativi potendo quest’ultimi accedere alle sezioni
di interesse in modalitá random access.
L’utilizzo del formato IGWD avveniva mediante la Frame Library v4r31 [24],
una libreria scritta in C contenente la definizione di tutte le strutture presenti nel
frame, le funzioni per la loro gestione e infine il codice che implementa la memorizzazione dei frame su disco. Grazie a quest’ultima caratteristica si raggiunge
l’uniformitá tra gli utenti della libreria anche dal punto di vista dello storage essendo uniche le funzioni che effettuano il salvataggio, la compressione e la lettura
dei frame.
Nel DAQ di AURIGA la Frame Library non viene utilizzata direttamente ma
attraverso un wrapper, questo non per aggiungere delle funzionalitá assenti ma
per uniformare l’accesso ai frame alla modalitá OOP. All’interno della PCL sono
28
3.7. L’Ambiente di Sviluppo
Figura 3.5: Struttura del frame IGWD
29
Capitolo 3. Il DAQ
presenti delle classi come PclFrame il cui scopo consiste nell’incapsulare l’insieme
di strutture del frame in un oggetto utilizzabile con le modalitá tipiche della
programmazione OOP.
A corredo della Frame Library inoltre vengono fornite utility di supporto che
permettono operazioni come la copia, il controllo di integritá, il “dump” di un
frame, rendendo possibile alcuni livelli di diagnostica di quanto acquisito.
3.7.4
ROOT
ROOT [25] é un framework realizzato dal CERN per fornire un insieme di strumenti comuni utilizzabili in tutte le fasi di un esperimento. Anche se nella “Mission Statement” di ROOT si legge che particolare enfasi é stata dedicata alla
visualizzazione e analisi interattiva dei dati, dal pacchetto ROOT vengono anche
offerti i mezzi per affrontare la simulazione e la ricostruzione degli eventi.
Particolaritá di ROOT é l’utilizzo di CINT, cioé l’interprete interattivo di
script in C. Grazie all’utilizzo di questo pacchetto é possibile implementare all’interno del framework ROOT degli script di analisi - in C o C++, i cui standard
sono supportati entrambi quasi completamente - che possono essere scritti, testati
ed eseguiti in modalitá interattiva, caratteristica che tipicamente viene riservata
ai linguaggi interpretati. Questa modalitá di “istruire“ il sistema di analisi ne
facilita la programmazione e rende la portabilitá del software completa visto che
gli script non vengono compilati, il tutto al costo di un leggero aumento dei tempi
di esecuzione.
La libreria ROOT é costituita da un insieme di strumenti OO espressamente
progettati per affrontare grandi volumi di dati. Fanno parte del framework oggetti
per effettuare fit, minimizzazioni, ecc. oltre ad un insieme completo di oggetti in
grado di gestire la visualizzazione dei dati elaborati.
Nel DAQ di AURIGA l’utilizzo di Root é alquanto ridotto e si limita all’uso
degli oggetti per la visualizzazione dei dati ad opera di processi specializzati
chiamati monitor. Questi sono dei programmi costruiti ad-hoc per spiare le code
dei processi del sistema di acquisizione (vedi Sezione 3.8) e permettere una
diagnostica online del sistema fornendo la possibilitá di visualizzare nel tempo
o in frequenza (FFT e PSD) i vari segnali acquisiti.
3.7.5
FFTW
A supporto del DAQ (e di tutta l’analisi) viene utilizzata la libreria FFTW 2.1.3
(the Fastest Fourier Transform in the West) [26]. La FFTW é costituita da un
insieme di subroutine scritte in C per il calcolo efficiente della DFT in una o
piú dimensioni. L’utilizzo di questa libreria é reso particolarmente interessante
dalle prestazioni ottenibili. Giá in fase di compilazione é possibile ottimizzare la
velocitá di esecuzione delle subroutine sfruttando le caratteristiche del sistema
(SSE, SSE2, 3DNow! e Altivec) su cui devono essere eseguite. Inoltre, grazie
all’utilizzo di diversi algoritmi per l’esecuzione della DFT, viene garantita una
30
3.8. Il Software di Acquisizione
complessitá computazionale di O(n log n), indipendentemente dalla dimensione
del set di dati utilizzato come input.
3.7.6
NI-VXI
La comunicazione tra il computer e la strumentazione VXI infine viene realizzata
utilizzando la libreria NI-VXI 1.6.2, fornita da National Instruments a corredo del
kit di interfaccia VXI-PCI8026 (vedi Sezione 3.2 [28]). Essa é composta da due
parti: un modulo del kernel8 che deve essere caricato all’avvio del sistema (driver)
e una libreria che fornisce le API in C per la comunicazione con gli strumenti.
L’utilizzo della libreria ni-vxi rende la comunicazione tra il computer e la
strumentazione trasparente nel senso che le schede VXI possono essere utilizzate
come un’estensione del PC. Essendo caricata come parte del kernel linux inoltre
diventa possibile per i dispositivi VXI utilizzare - mediante il driver - strumenti
tipici del sistema operativo come i segnali.
3.8
Il Software di Acquisizione
Il DAQ di AURIGA segue un’architettura gerarchica spesso utilizzata nei sistemi di acquisizione da impiegare in ambito scientifico, costituita da tre livelli
corrispondenti ad altrettanti strati di astrazione.
Figura 3.6: Strutturazione del DAQ
Il livello piú basso, il primo, é costituito dai processi che si interfacciano direttamente con l’hardware. Essi realizzano il front-end con la strumentazione,
implementando la logica necessaria per configurare e utilizzare l’hardware che,
nel caso di AURIGA, é costituito dagli ADC e il GPS. Allo strato immediatamente superiore viene posto un processo particolare detto builder, il cui scopo
consiste nel ricevere i dati provenienti dal livello sottostante e formattarli in base
alle specifiche stabilite, per poi costruire i frame di dati a partire dai flussi raw
provenienti dal livello 1. A questo livello tipicamente avviene anche un primo
controllo di consistenza dei dati raccolti. L’ultimo livello é costituito dai client,
8
Per eseguire operazioni di I/O sui registri del sistema é infatti necessario che l’applicativo
sia in esecuzione in kernel-space
31
Capitolo 3. Il DAQ
ossia i processi che operano sui dati raccolti, come ad esempio gli applicativi di
analisi.
Nel sistema di acquisizione di AURIGA, i tre livelli precedentemente descritti
sono interamente realizzati attraverso processi specializzati e indipendenti. Questi
comunicano fra loro mediante il middleware CORBA, realizzando un’architettura
client/server che puó essere distribuita, ottenendo quindi un sistema altamente
scalabile; CORBA, infatti, permette ad un processo l’invocazione di metodi di
oggetti remoti e quindi l’intero sistema puó essere distribuito attraverso una rete.
L’ORB viene realizzato grazie ad un nameserver (omniNames nell’implementazione scelta) al quale ogni oggetto viene associato all’atto della creazione. Grazie
ad esso, processi su piú sistemi appartenenti alla medesima subnet possono comunicare senza dover conoscere dettagli della rete come gli indirizzi degli host su
cui sono in esecuzione gli oggetti remoti, la presenza di eventuali apparati di rete
attivi, ecc.
Figura 3.7: Architettura Cliet/Server del DAQ dove sono stati
messi in evidenza i 3 livelli di progettazione.
In Figura 3.7 sono illustrati i componenti del DAQ assieme ai flussi dati che
vengono scambiati; ognuno dei processi funge da server per il livello successivo e agisce come client nei confronti del precedente, ad eccezione ovviamente
del primo. La scalabilitá del sistema, ottenuta grazie all’utilizzo di CORBA, si
concretizza nella possibilitá di eseguire i processi del DAQ su calcolatori diversi.
Attualmente le capacitá di calcolo fornite dai computer disponibili sul mercato
sono piú che sufficienti a gestire la mole di dati che il sistema produce. L’utilizzo
di questa struttura tuttavia lascia aperta la possibilitá di aggiornare il DAQ con
un impatto contenuto; l’aggiunta di piú canali principali da acquisire ad una frequenza molto superiore, necessaria ad esempio con un nuovo tipo di rivelatore o
con l’acquisizione in coincidenza con rivelatori di raggi cosmici, potrá essere gestita semplicemente istanziando piú front-end verso la strumentazione e, qualora il
32
3.8. Il Software di Acquisizione
troughput di un singolo calcolatore risultasse insufficiente, il problema potrebbe
essere risolto semplicemente distribuendo i processi fra piú computer. Un’altra
interessante possibilitá sfruttabile da questa architettura consiste nell’eseguire
parte del DAQ su sistemi embedded. Per ridurre le interferenze che si sommano
al segnale acquisito é buona norma porre la strumentazione di acquisizione il piú
possibile vicina al rivelatore: in questo modo vengono concatenate meno sorgenti
di interferenze elettromagnetiche e diventa agevole ridurre i disturbi introdotti
dalle alimentazioni utilizzando la stessa massa per rivelatore e strumentazione.
Una configurazione di questo tipo generalmente risulta problematica visto che,
per un sistema monolitico, diventa necessario posizionare il crate con la strumentazione assieme ai PC nelle vicinanze del rivelatore. L’implementazione del
sistema come Client/Server permette di risolvere questo inconveniente in modo
agevole: eseguendo i front-end verso la strumentazione su un sistema embedded
VXI (o al limite piú sistemi se la capacitá di un singolo risulta insufficiente) diventa sufficiente posizionare in prossimitá del rivelatore unicamente il crate dove
avviene l’intera acquisizione. I livelli successivi del DAQ, come ad esempio il builder, possono essere eseguiti su altri PC che, utilizzando una normale connessione
di rete, possono interagire con il front-end in maniera totalmente trasparente.
I processi del DAQ presentano una certa uniformitá nelle operazioni che devono svolgere; questo fatto ha consentito di definire in fase di progettazione un’interfaccia di comunicazione standard utilizzata da tutti i processi, facilitando quindi
l’integrazione del sistema. Inoltre é stato possibile realizzare la libreria condivisa (PCL) che, implementando al suo interno le operazioni di comunicazione,
le rende trasparenti ai processi costituenti il DAQ. Nella PCL inoltre sono state
implementate le strutture dati piú diffusamente utilizzate nel progetto, come le
code che verranno descritte in seguito.
Figura 3.8: Rappresentazione mediante FSM di un processo PCL
L’interfaccia di comunicazione comune é stata realizzata anche grazie all’implementazione di ogni processo come una macchina a stati finiti (FSM o Finite
State Machine - Figura 3.8. In ogni istante infatti, un processo puó trovarsi
solamente in uno dei cinque stati ammessi, precisamente INITIAL, LOADED,
CONFIGURED, ACTIVE o FAILURE. Il processo si trova nello stato INITIAL
non appena viene istanziato e puó passare allo stato LOADED in seguito all’invocazione del metodo Boot. Alla ricezione dei parametri di configurazione, in
seguito alla chiamata di Config, il processo puó passare allo stato CONFIGURE
33
Capitolo 3. Il DAQ
e infine da quest’ultimo puó entrare nello stato ACTIVE in seguito alla chiamata del metodo Start, che fa partire il “working thread” vero e proprio. Sono
possibili anche le transizioni opposte che avvengono, come indicato nello schema,
rispettivamente in seguito alla chiamata di Stop (che ferma il working thread),
Abort e Shutdown. Lo stato FAILURE viene utilizzato per segnalare la presenza
di qualche malfunzionamento ed é raggiungibile da qualsiasi altro. Mediante il
metodo reset, il processo puó uscire dallo stato FAILURE e ritornare nello stato
INITIAL per ripartire. Il metodo reset puó inoltre essere utilizzato da un qualsiasi
stato diverso da failure per eseguire la sequenza di chiamate necessaria a riportarlo nello stato iniziale. Oltre a quelli indicati in Figura 3.8, esiste un ulteriore
stato - INTRANSITION - il cui scopo é il controllo delle operazioni concorrenti.
Un processo entra nello stato INTRANSITION durante le transizioni di stato a
indicare che non puó ricevere ulteriori richieste finché non viene ultimata quella
in corso.
Dalla descrizione del sistema come macchina a stati finiti segue immediatamente la definizione dell’interfaccia dell’oggetto, alla quale, oltre a quelli necessari
alla transizioni di stato, sono stati aggiunti altri metodi per completare la comunicazione interprocesso. Precisamente, raggruppando in sezioni i metodi dichiarati
nell’interfaccia in base alla funzione svolta, si ha:
PRODUCER In questa sezione sono presenti i metodi per lo scambio dei dati
tra client e server, in particolare i metodi PutData, GetData e SpyData
implementano l’interfaccia verso le code dei processi
ACTIONS Sono i metodi per operare le transizioni di stato della FSM come
descritti precedentemente
LOGGER L’unico metodo presente in questa sezione permette ad un processo
esterno di ottenere l’elenco dei messaggi di log dell’oggetto chiamato.
MONITOR I metodi di questa sezione sono necessari per conoscere lo stato del
processo, in particolare GetFsmStatus ritorna lo stato - in termini di FSM del processo mentre GetQueueStatus permette di conoscere lo stato di una
coda (numero di frame memorizzati, ecc).
Dalla precedente definizione dell’interfaccia dei processi PCL si nota un’ulteriore particolare: la gestione degli errori. Grazie all’utilizzo di omniORB infatti, é
stato possibile utilizzare le eccezioni anche su oggetti remoti, di conseguenza sia la
gestione degli errori che la sincronizzazione tra i processi sono stati implementati
in questa modalitá.
Vediamo ora alcuni dettagli della PCL.
Al suo interno in primo luogo trova la definizione processo PCL la cui struttura é stata schematizzata in Figura 3.9. Grazie all’utilizzo di metodi virtuali é
stato definito l’oggetto PclProducer che implementa l’interfaccia presentata nello
schema; di conseguenza ogni processo PCL (processo server) viene definito come
figlio del precedente e, ereditandone tutte le strutture e i metodi, deve definire
34
3.8. Il Software di Acquisizione
Figura 3.9: Schema funzionale dei Processi PCL
al suo interno solamente la parte ACTIONS dell’interfaccia che necessariamente
deve essere diversa tra i vari processi.
Altro componente fondamentale della libreria PCL sono le code su cui si basano tutte le operazioni di memorizzazione - temporanea o permanente - e la spia
dei dati. Gli oggetti che implementano le code utilizzano i “template” per la definizione dei dati contenuti, in questo modo si adattano a qualsiasi tipo di dato primitivo o strutturato - permettendo a compile-time di ottenere un oggetto ottimizzato per operare su una particolare struttura9 . Le code sono definite a partire
da tre oggetti, cioé PclQueue, PclXQueue e PclPersistentQueue che implementano rispettivamente la coda dei dati, le funzionalitá di spia e infine il salvataggio
su memoria di massa, incapsulandone tutte le problematiche (gestione della comunicazione, errori, ecc). Da questi oggetti, per derivazione, discendono tutte le
altre code implementate. Particolarmente interessante é la PclMirroringQueue,
derivata da PclPersistentQueue, che si occupa della memorizzazione contemporanea di uno stesso flusso di dati su due percorsi diversi, tipicamente due dischi
fissi. Essa é stata sviluppata per aumentare la resilienza del sottosistema di
memorizzazione di massa che inizialmente era costituito da dischi fissi locali, rendendo quindi necessaria una qualche forma di duplicazione per mettersi al riparo
da possibili fallimenti dei dispositivi. La PclMirroringQueue viene ampiamente
utilizzata nel processo DSK (vedi paragrafo 3.8.5) che si occupa del salvataggio
dei dati raccolti.
La gestione delle condizioni anomale nel DAQ di AURIGA é stata interamente
implementata mediante eccezioni. Per rendere uniforme la gestione, compreso il
caso di eccezioni provenienti da oggetti remoti, é stato utilizzato un particolare
oggetto: PclException, anch’esso appartenente alla PCL. Grazie al suo utiliz9
Nel DAQ tutte le operazioni di I/O, comprese le comunicazioni fra processi, avvengono
utilizzando il formato Frame IGWD. Tuttavia la generalitá con cui sono state implementate le
code ne permette l’utilizzo anche su strutture di tipo diverso
35
Capitolo 3. Il DAQ
zo diventa possibile gestire proprie condizioni di eccezione, anche via CORBA,
semplicemente derivandole da PclException.
3.8.1
ANT
Il programma ANT costituisce il front-end verso la scheda Agilent E1430, incapsulando all’interno di un processo PCL tutti gli aspetti della comunicazione con
il dispositivo. Oltre alla configurazione del dispositivo, ANT - con il suo working thread - gestisce il trasferimento verso il PC dei dati acquisiti dall’ADC e li
formatta in accordo allo standard IGWD. Come accennato in Sezione 3.4, una
volta attivato con il metodo Start, l’ADC opera in acquisizione continua comunicando al sistema host la presenza nella FIFO di un buffer (64 KB) mediante
un’interruzione. Tra le diverse modalitá fornite dal driver ni-vxi per la gestione
dell’interrupt generato, si é scelta la sua conversione in segnale. Quando l’ADC
solleva l’interruzione quindi, il modulo kernel del driver la intercetta e la converte
in un segnale equivalente a quelli utilizzati normalmente nei sistemi Linux. Il
processo ANT quindi, dopo aver configurato l’ADC e la gestione dei segnali, si
pone in attesa sulla coda con un WaitForSignal che sospende il processo fino
all’arrivo di un segnale. Nell’implementazione del DAQ si é scelto di utilizzare
una singola coda per i segnali provenienti dalla strumentazione e quindi ANT, al
ritorno da WaitForSignal deve in primo luogo controllare se il segnale proviene
dal canale Antenna. La funzione WaitForSignal in output fornisce il Logical
Address10 a 16 bit11 del mittente assieme al controller da cui proviene il segnale.
Queste informazioni permettono di determinare se la richiesta é stata generata
dall’Agilent E1430 oppure dall’HP 1413, nel qual caso ANT lo riaccoda e si sospende per alcuni millisecondi, fornendo cosı́ la possibilitá ad AUX (vedi Sezione
3.8.2) di recuperare il segnale che gli era stato inoltrato. Una volta verificata
la provenienza dell’interruzione, ANT provvede al recupero di un buffer di dati
(16KSa) e alla conversione degli stessi in formato IGWD. Il dispositivo Agilent
E1430 fornisce in uscita direttamente il valore letto dall’ADC e quindi in primo
luogo questo va convertito in un float12 , si procede poi alla creazione del frame
inserendovi, oltre ai dati, le informazioni relative alla configurazione dell’ADC
(scala, frequenza di campionamento, ecc.). Infine i frame vengono accodati per
essere successivamente richiesti dal builder.
10
Logical Address o LA é un numero di 8 bit che viene assegnato ad ogni strumento VXI per
un’identificazione univoca. Solitamente viene configurato mediante dip-switch e quindi non é
modificabile via software (a run-time)
11
Gli otto bit meno significativi costituiscono il LA della scheda VXI mentre i piú significativi
vengono utilizzati per stabilire il tipo di comunicazione (Dati, Info, ecc)
12
L’utilizzo di numeri floating point a 32 bit (IEEE-754) non pregiudica la precisione del
sistema dato che la mantissa, costituita da 24 bit, é sufficiente a contenere i 23 bit forniti
dall’ADC
36
3.8. Il Software di Acquisizione
3.8.2
AUX
Il processo AUX implementa, per la scheda HP 1413, le stesse funzionalitá di
ANT. Le differenze tra gli strumenti come la dimensione dei buffer o la memorizzazione dei canali acquisiti in multiplexing sono ininfluenti a questo livello.
L’unica cosa in cui si differenziano é, all’atto del recupero dei dati, nella modalitá
di conversione. A differenza del convertitore E1430 infatti, HP 1413 fornisce in
uscita i valori acquisiti direttamente nello standard IEEE-754 per cui questi vengono prelevati dalla FIFO dello strumento e direttamente memorizzati nel frame
che, come per ANT, viene infine accodato.
3.8.3
GPS
GPS é il processo che si occupa della ricezione dei timestamp provenienti dal
ricevitore GPS ESAT 100 in seguito agli eventi generati dalla scheda S80, come indicato in Sezione 3.3. L’associazione del tempo ai frame avviene ad un
livello successivo, precisamente nel builder, quindi GPS si limita alla ricezione
di pacchetti temporali dalla seriale e alla loro diagnostica. Il working thread del
processo é costituito da un ciclo all’interno del quale avviene la lettura (bloccante) della porta, successivamente viene verificato il pacchetto ricevuto affinché
rispetti le specifiche dello stamp e in caso negativo questo viene scartato e generata un’eccezione. Superato il controllo di integritá, vengono estratti dalla stringa
ricevuta i dati relativi a data, ora, il canale che ha generato lo stamp e le informazioni statistiche prodotte dal ricevitore. Dato che ad uno stesso ricevitore
potrebbero essere connessi piú dispositivi (altri DAQ ad esempio anche se non
necessariamente) viene effettuato un ultimo controllo sul canale che ha generato
lo stamp e, anche in questo caso, se non é fra quelli gestiti dal DAQ il pacchetto
viene scartato. Superati tutti i test, i tempi vengono finalmente memorizzati nella
coda associata al canale che li ha generati, in attesa del successivo consumo da
parte del builder.
3.8.4
BLD
BLD o builder é il processo che si occupa della costruzione dei frame in formato
IGWD a partire dai frame provenienti dai front-end (ANT, AUX e GPS). Il
working-thread del processo interroga ciclicamente i processi ANT o AUX per
verificare la presenza di nuovi frame accodati e in caso affermativo li recupera dalle
rispettive code. Successivamente alla ricezione di un nuovo frame da un ADC é
necessario recuperare il timestamp ad esso associato; a seguito del successo nella
lettura di un frame viene quindi interrogato GPS per recuperare il timestamp
relativo all’ADC. Qui avviene il primo livello di controllo di consistenza dei dati
acquisiti. Infatti, anche se si considera corretta la presenza di nuovi frame dagli
ADC, i dati provenienti dal GPS possono essere affetti da errore: possono essere
mancanti, relativi ad un frame diverso da quello in costruzione oppure riportanti
un tempo errato in seguito alla generazione di un interrupt spurio. Nell’ultimo
37
Capitolo 3. Il DAQ
caso gli stamp vengono semplicemente scartati mentre per gli altri errori il BLD
provvede al calcolo dello stamp da associare al frame. Il controllo del tempo
proveniente dal GPS avviene mediante il confronto con quello precedentemente
ricevuto dallo stesso canale. Si assume infatti un errore massimo commettibile
dal ricevitore e quindi, noto il numero di campioni componenti un frame, si puó
verificarne la correttezza della datazione.
Il builder deve occuparsi di un ulteriore problema per i dati provenienti dall’HP 1413. Nel caso di piú canali l’ADC fornisce dei buffer i cui i dati consecutivi
sono relativi ai canali della scanning-list utilizzata (nello stesso ordine). Diventa
quindi necessario effettuare lo “spacchettamento” (demultiplexing) dei buffer per
ottenere i campioni relativi ad ogni ingresso; inoltre a differenza del canale antenna, per gli ausiliari il numero di campioni in un buffer varia a seconda del numero
di ingressi utilizzati. Volendo utilizzare dei frame a dimensione costante (4KSa),
il builder deve provvedere alla memorizzazione temporanea dei dati acquisiti fino
al raggiungimento della dimensione scelta. Questo introduce un ulteriore difficoltá dovuta al fatto che i tempi provenienti dal GPS sono relativi alla fine del
buffer acquisito e non alla fine del frame. Il builder deve quindi provvedere anche
al calcolo del tempo da associare ad ogni frame dei canali ausiliari, interpolando
i tempi ricevuti dal GPS.
3.8.5
DSK
Il compito del processo DSK é la gestione della memorizzazione dei frame su
memoria di massa. Le richieste di resilienza del sistema portano ad implementare
in questo processo tutte le strategie necessarie a risolvere i diversi inconvenienti
che possono derivare dall’utilizzo dei dischi fissi, come gli errori di scrittura dovuti
all’esaurimento dello spazio, il tempo necessario all’operazione che virtualmente
non ha un limite superiore, ecc. Il DAQ, inoltre, inizialmente era stato concepito
per utilizzare i dischi fissi come supporto di memorizzazione definitiva e quindi,
periodicamente, questi dovevano essere sostituiti a causa dell’esaurimento dello
spazio disponibile.
Il processo DSK é stato progettato per rendere sicura e agevole la memorizzazione definitiva dei dati, utilizza buffer interni per prevenire perdite dovuta
a ritardi di scrittura, implementa il mirroring inteso come scrittura degli stessi
flussi su due percorsi distinti e infine facilita all’utente il compito di sostituire i
dischi fissi in modalitá hot swap.
3.8.6
LOG
Come indicato in precedenza, ogni processo puó produrre dei messaggi di LOG
in seguito al verificarsi di alcuni eventi, tipicamente situazioni che richiedono
l’attenzione dell’utente. Nella progettazione del DAQ si é deciso di centralizzare
la gestione del registro di log utilizzando questo processo il cui compito consiste
nell’interrogare periodicamente tutti i processi PCL in esecuzione per recuperare
i messaggi che eventualmente sono stati prodotti. La memorizzazione del registro
38
3.8. Il Software di Acquisizione
di log avviene successivamente al recupero di nuovi messaggi utilizzando un file
ASCII che non richiede quindi particolari editor per la consultazione.
3.8.7
GUI
La GUI (Figura 3.10) costituisce l’interfaccia grafica del sistema di acquisizione.
L’implementazione é avvenuta utilizzando il framework QT di Trolltech, particolarmente il tool QTdesigner per la progettazione dei frame e il compilatore uic
per la generazione del codice sorgente.
Figura 3.10: Interfaccia grafica del DAQ
Essa sfrutta l’interfaccia CORBA dei processi per inviare i comandi e ottenere
informazioni sullo stato di esecuzione.
Sul lato sinistro dell’interfaccia sono disposti i pulsanti che permettono il
controllo dei processi; questi, invocando i metodi della sezione ACTIONS dell’interfaccia CORBA (vedi Sezione 3.8), comandano le transizioni di stato delle
FSM dei processi. Nel riquadro Process Status sono visualizzati i processi PCL
in esecuzione assieme alle informazioni sullo stato e sul numero di frame memorizzati nelle code. Il frame Message fornisce in real-time i messaggi catturati
dal processo LOG; questo assieme al precedente pannello fornisce un quadro del
funzionamento del DAQ.
Nella GUI vengono presentate un insieme di informazioni di servizio come il
tempo di partenza dell’acquisizione assieme al tempo attuale, il numero del Run,
la possibilitá di impostare veti e lo stop degli allarmi. L’utilizzo dei veti serve per
poter marcare un porzione di dati acquisiti come non validi per diverse ragioni.
Durante un trasferimento di Elio ad esempio il sistema presenta un eccesso di
39
Capitolo 3. Il DAQ
rumorositá e quindi i dati raccolti sono pressoché inutilizzabili. Volendo evitare lo
stop del DAQ diventa necessario stabilire un sistema per la marcatura dei dati non
validi e questo viene realizzato mediante l’impostazione di un veto. Lo stop degli
allarmi invece é collegato al logger. Ogni processo oltre a produrre un messaggio
di log stabilisce un livello di allerta che caratterizza la probblematicitá dell’evento
verificatosi. In base a questo livello é possibile impostare la GUI affinché generi
dei messaggi sonori nei periodi in cui vengono intercettate segnalazioni di log
corrispondenti ad un certo livello configurabile dall’utente. Il tasto Stop Alarm
serve a segnalare alla GUI che l’utente ha riconosciuto la presenza dell’errore e
quindi l’avviso acustico puó essere fermato.
(a) Configurazione del processo
ANT
(b) Configurazione del
processo BLD
(c) Configurazione
del processo DSK
(d) Configurazione del processo AUX
Figura 3.11: Utilizzo della GUI per la configurazione dei processi
PCL
Di particolare interesse é la configurazione dei processi PCL all’interno dell’interfaccia. Facendo infatti doppio click sopra qualsiasi processo compare una
schermata che permette la modifica della configurazione se il processo é nello stato
40
3.8. Il Software di Acquisizione
LOADED oppure la visualizzazione della configurazione utilizzata negli altri stati.
In Figura 3.11 vengono riportati alcuni screenshot delle finestre di configurazione.
Sono stati omessi quelli relativi alla configurazione del LOG che non prevede
alcun parametro e del GPS la cui unica opzione é la seriale da utilizzare per la
ricezione dei pacchetti.
Le precedenti immagini forniscono un’idea di quali e quante siano le possibili
modalitá di funzionamento del sistema di acquisizione e di come, nonostante le
diversitá nei processi che lo costituiscono, si sia riuscito a dare uniformitá al
sistema, dal progetto fino alla realizzazione dell’interfaccia.
In aggiunta all’interfaccia grafica, il DAQ é dotato di un processo chiama DSC
che implementa le funzioni della GUI da riga di comando. Il funzionamento, al
di la della presentazione dei risultati, é il medesimo: anch’esso é un processo
client CORBA che utilizza l’interfaccia di comunicazione dei processi PCL per
interagire con essi.
41
Capitolo 4
Upgrade e BugFix del Sistema
L’Upgrade di un sistema di acquisizione non si riduce alla semplice sostituzione
dell’architettura Hardware e Software ma viene complicato dalla necessitá di caratterizzare i nuovi componenti adottati assieme all’intero sistema operante nella
nuova configurazione. Di conseguenza l’aggiornamento non viene richiesto solo
per utilizzare nuove piattaforme hardware, ma richiede ragioni ben piú profonde.
Nel caso di AURIGA il vecchio sistema di acquisizione presentava dei malfunzionamenti che dovevano essere corretti. Vista la necessitá di modificare il DAQ
- anche se in parte - si é deciso di provvedere contestualmente anche all’aggiornamento dello stesso, sostituendo l’hardware non piú perfettamente funzionale
e migrando il sistema di acquisizione verso la piattaforma piú conveniente per
l’esecuzione.
Dal punto di vista dei sistemi operativi, il porting si é articolato in due fasi: dal
sistema originale Red-Hat Linux 6.2 alla distribuzione Red-Hat Linux 7.3 prima
per poi procedere alla Red-Hat Linux 9. La scelta del primo sistema operativo
é dovuta alla sua diffusione in ambito scientifico; la Red-Hat Linux 7.3 é infatti
la distribuzione adottata per i sistemi di calcolo di AURIGA, inoltre é la base di
partenza su ci é stata costruita la Scientific Edition, una distribuzione realizzata
dal CNR appositamente per l’utilizzo negli ambienti di ricerca. Come si vedrá
nel seguito, tale distribuzione presentava alcune importanti lacune per il DAQ,
ragione per cui si é optato per una migrazione all’ultima release free disponibile
all’interno della stessa famiglia: Red-Hat Linux 91 .
In questo capitolo si descriveranno in primo luogo i problemi riscontrati nel
funzionamento del vecchio DAQ di AURIGA e quindi se ne analizzeranno le cause
giungendo alle soluzioni che sono state proposte e implementate.
1
La Red-Hat Linux 9 non é in realtá la piú recente distribuzione free prodotta da Red-Hat.
Le successive - Fedora Core 1 e Fedora Core 2 - tuttavia non si prestavano all’utilizzo richiesto
perché il kernel non é compatibile col driver della scheda di acquisizione
43
Capitolo 4. Upgrade e BugFix del Sistema
4.1
Malfunzionamenti
La prima versione del DAQ, sebbene frutto di un’attenta progettazione, nel corso
dell’utilizzo ha presentato alcuni malfunzionamenti incompatibili con i requisiti
imposti al sistema. Due in particolare sono stati i punti affetti da problemi:
• La sincronizzazione dei dati con il tempo universale (UTC)
• La robustezza richiesta al sistema di acquisizione
I malfunzionamenti del primo tipo si presentavano con frequenza abbastanza bassa, tuttavia il tipo di esperimento richiede che l’acquisizione possa essere
mantenuta operativa per intervalli di tempo molto lunghi - dell’ordine di mesi e di conseguenza anche se tra due errori di temporizzazione potevano trascorrere
alcuni giorni, la mancata sincronizzazione costituiva un problema sostanziale per
il sistema di acquisizione.
Con l’uso del DAQ inoltre sono stati riscontrati dei malfunzionamenti a carattere deterministico relativamente ad alcune funzioni, in particolare nel caso dei
canali ausiliari.
Per la sua evoluzione AURIGA necessitava di un terzo sistema di acquisizione
da affiancare ai due - utilizzanti il vecchio software - giá operativi. Si é colta
l’occasione data dalla necessitá del nuovo sistema per provvedere alla soluzione
dei problemi precedentemente indicati e contestualmente, data la velocitá di evoluzione del settore informatico, per migrare verso piattaforme sia hardware che
software piú recenti e quindi performanti.
Il terzo sistema é stato utilizzato infine come banco di prova per la sostituzione
dei suoi due predecessori che, come di consuetudine, per un periodo verranno
lasciati in funzione parallelamente al terzo per verificarne le funzionalitá.
4.2
Aggiornamento Hardware
La prima fase nella costruzione del nuovo sistema é stata la scelta dei nuovi componenti da impiegare. Visto che la strumentazione VXI utilizzata nella precedente
versione del DAQ verifica tutti i requisiti richiesti e inoltre che, nonostante l’etá,
continua ad essere supportata, come ADC sono stati scelti gli stessi del vecchio
sistema e quindi sia la scheda Agilent E1430 che il VXItech VT1413C. Per la
sincronizzazione con il GPS si é utilizzato uno dei ricevitori GPS giá presenti
nel laboratorio dato che non erano richieste prestazioni ulteriori. La presenza
di canali liberi in ingresso alle schede S80 ha fornito la possibilitá di sfruttare il
medesimo ricevitore GPS per due sistemi di acquisizione.
Le modifiche piú significative dal punto di vista hardware si sono quindi concretizzate nell’adozione di un diverso crate per alloggiare la strumentazione e
l’impiego di un computer basato su una diversa architettura.
44
4.2. Aggiornamento Hardware
4.2.1
Il nuovo Crate
La costruzione di un nuovo sistema di acquisizione ha richiesto l’utilizzo di un
nuovo mainframe per l’alloggiamento della strumentazione VXI. Il crate precedentemente impiegato - l’HP E1401A (vedi Sezione 3.2) - non viene piú prodotto
da Hewlet Packard per cui si é adottato un prodotto di National Instruments: il
VXI-1200. Si tratta di un crate VXI/VME compatto (Figura 4.1), con 6 alloggiamenti disponibili per schede C-size (tipo gli ADC impiegati in AURIGA) e 3 per
schede B-size, in grado di fornire una potenza di picco di 720W e di provvedere
al raffreddamento degli strumenti.
Figura 4.1: Mainframe National Instruments VXI-1200
Sebbene la scelta di un nuovo crate possa sembrare irrilevante ai fini del
funzionamento del DAQ, la sua adozione ha richiesto un periodo di studio per la
caratterizzazione del rumore e delle latenze introdotto del dispositivo.
Per la stime delle interferenze sono state effettuate varie acquisizione nelle possibili modalitá di funzionamento, con uno o due ADC e con o senza la
scheda di estrazione degli interrupt che é stata introdotta nel Sezione 3.4. La
scheda in questione basa il suo funzionamento sull’utilizzo del circuito integrato SN74LS240N che é costituito da 8 buffer 3-state invertenti mediante i quali
vengono rese accessibili le 7 linee di interrupt del BUS VXI.
Nel corso dei test effettuati si é visto che, nonostante lo standard VXI specifichi in modo molto stringente le caratteristiche che i dispositivi devono supportare
relativamente al rumore, in seguito alla presenza della scheda di estrazione delle
interruzioni, il BUS VXI veniva in qualche maniera accoppiato con il canale di
ingresso dell’ADC Agilent E1430. In Figura 4.2 é riportato l’andamento di un
segnale fuori massa acquisito della scheda Agilent E1430 in assenza della scheda per l’estrazione dell’interrupt; la forma d’onda ottenuta é il classico rumore
bianco.
In Figura 4.3 e in Figura 4.4 sono plottati invece gli andamenti del medesimo
segnale acquisito in presenza della scheda di estrazione delle interrupt. I due
grafici rappresentano acquisizioni con lunghezza diversa del buffer e frequenza di
45
Capitolo 4. Upgrade e BugFix del Sistema
Figura 4.2: Acquisizione effettuata con l’ADC Agilent E1430 senza scheda di estrazione degli interrupt. Le linee verticali tratteggiate indicano la fine di un buffer e quindi il momento in cui
viene sollevata l’interruzione.
campionamento, cosı́ da modificare l’intervallo tra il sollevamento delle interruzioni nel BUS VXI. Si nota in entrambi i casi che, alla generazione dell’interruzione
- che nel bus VXI é attiva bassa - il segnale presenta un calo del livello in dc
denotando un accoppiamento dell’ingresso dell’ADC con la linea di interruzione
del BUS, traducendosi in un disturbo a bassissima frequenza2 che si aggiunge al
segnale di ingresso.
Volendo mantenere gli errori massimi nella temporizzazione entro i requisiti
per l’esperimento diviene importante stimare se il nuovo crate introduce tempi
di propagazione diversi rispetto al suo predecessore. L’importanza della misura
assieme alla necessitá della sua esecuzione su tutti i sistemi di acquisizione ha
portato all’implementazione di un apposito software che automatizza il compito
della stima dei tempi di latenza dell’interrupt e di altri parametri. Tale applicativo
viene illustrato nel Capitolo 5.
2
Nell’utilizzo tipico del DAQ il segnale di interruzione viene sollevato con un periodo di circa
3.355s, con una frequenza quindi prossima a 0.3Hz
46
4.2. Aggiornamento Hardware
Figura 4.3: Acquisizione effettuata con l’ADC Agilent E1430 con
scheda di estrazione delle interruzioni. La frequenza di campionamento utilizzata é 4882Hz e la dimensione del buffer é stato impostata a 32KSa. Le linee verticali tratteggiate indicano il
momento in cui viene sollevata l’interruzione.
Figura 4.4: Acquisizione effettuata con l’ADC Agilent E1430 con
scheda di estrazione delle interruzioni. La frequenza di campionamento utilizzata é 2441Hz e la dimensione del buffer é stato impostata a 16KSa. Le linee verticali tratteggiate indicano il
momento in cui viene sollevata l’interruzione.
47
Capitolo 4. Upgrade e BugFix del Sistema
4.2.2
Il nuovo PC Host
Inizialmente si era pensato di continuare a utilizzare i vecchi PC presentati nella
Sezione 3.6, questo perché i flussi di dati che il nuovo sistema deve gestire non
sono radicalmente diversi come quantitá da quelli del precedente e quindi l’architettura SMP che era stata scelta poteva essere sufficiente per gestire i troughput
richiesti. La scelta di un nuovo calcolatore é stata forzata dall’incompatibilitá
con il driver fornito dalla National Instruments (unico componente closed source
utilizzato), che abbiamo potuto appurare dopo un lungo periodo di sperimentazione. Infatti, utilizzando la versione 2.0.1 della libreria ni-vxi, immancabilmente
dopo alcuni giorni di acquisizione non venivano piú sollevate interruzioni dalla
strumentazione di misura. Il sistema non presentava alcuna anomalia, tutti i processi rimanevano in esecuzione e in attesa dei segnali provenienti dal bus VXI,
tuttavia né l’Agilent E1430 né l’HP 1413 fornivano buffer di dati, pur potendo
verificare che gli stessi rimanevano in acquisizione.
Dopo numerose sperimentazioni con tutte le possibili tecniche di interfacciamento previste dalla libreria ni-vxi (a segnali, a interruzioni con uno o due
handler e tecniche miste) e altrettante richieste di assistenza alla National Instruments, finalmente lo sviluppatore della libreria ci ha proposto l’utilizzo di
alcune funzioni (non documentate) che permettevano di determinare lo stato dei
registri dell’interfaccia PCI-VXI al verificarsi dell’evento. Dalla lettura dei registri si é potuto determinare che, ad ogni blocco, l’interfaccia si trovava nella
stessa configurazione che per default ha all’avvio del sistema, permettendoci di
trarre la conclusione - assieme ai tecnici National Instruments - che il chipset
VIA Pro Apollo 133A, con regolaritá, ogni 3-4 giorni provvedeva a resettare la
scheda PCI. Un’ulteriore verifica dell’incompatibilitá tra il chipset e la scheda di
interfaccia NI VXI-PCI8026 ci é stata fornita quando la scheda é stata testata
sul sistema utilizzato per lo sviluppo del DAQ, che monta una scheda madre
basata sul chipset Intel 875P. Su questo sistema infatti, il DAQ é stato lasciato
in esecuzione per mesi senza sperimentare alcun blocco delle segnalazioni che riceve e indipendentemente dal metodo di interfacciamento utilizzato (interrupt o
segnali).
Dovendo cambiare l’architettura del sistema di acquisizione si é voluto continuare a privilegiare la resilienza, cercando di non penalizzarne la capacitá di calcolo. Dopo alcune verifiche effettuate con il computer di sviluppo, per i calcolatori
dei sistemi di acquisizione sono state formulate le seguenti specifiche:
Processore: Intel Pentium IV HT (Prescott) a 3GHz/800MHz FSB con 1MB
di Cache L2
Mother Board: ASUS P4C800-Deluxe (chipset Intel 875P)
Memoria: 2 x CORSAIR XMS ExtraLowLatency 512MB DDR PC3200XL
Controller SCSI: Adaptec 19160 U160 LVD
HD: MAXTOR ATLAS 10K-IV 36GB U320 10Krpm SCSI
48
4.2. Aggiornamento Hardware
Non essendo piú disponibili sistemi SMP nella fascia Pentium IV si é optato
per un’unitá Hyper Threading in grado di offrire una sorta di parallelismo. Nella
scelta dei componenti si nota che la qualitá é stata privilegiata affidandosi, qualora
la scelta fosse possibile, al modello che garantisce le minori probabilitá di rottura.
Una nota a parte va fatta per la scelta del sottosistema di I/O SCSI; la velocitá ottenuta dall’esecuzione in hardware delle operazioni di controllo dei dischi
riduce notevolmente il carico richiesto alla CPU durante le operazioni di lettura/scrittura e questo sicuramente aiuta a ridurre i tempi di attesa di un sistema,
quale il nostro, in cui devono essere in esecuzione molti processi contemporaneamente. L’utilizzo di controller e Hard Disk SCSI inoltre permette di aumentare la
resilienza del computer. Il problema che piú frequentemente si presenta nell’utilizzo di un disco fisso é il danneggiamento di uno o piú settori a seguito del quale
é necessario effettuare una scansione dell’intero dispositivo per “marcare” come
non utilizzabili i settori danneggiati. I dischi SCSI mantengono al loro interno
una lista dei settori non utilizzabili che viene inizializzata alla formattazione e
aggiornata ogniqualvolta ne vengono trovati di nuovi; grazie a questa caratteristica diviene superfluo fermare il PC per procedere alla scansione dell’Hard Disk.
Inoltre, nel disco SCSI viene riservato un insieme di settori non utilizzabili da sostituire con quelli che vengono trovati danneggiati. Il controller infatti é in grado
di eseguire lo “slittamento o rinnovo“ di un settore che permette la sostituzione
logica al volo di un settore danneggiato con un altro appartenente all’insieme di
quelli inutilizzati.
Per lo sviluppo e il testing del DAQ é stato adoperato un’altro computer che,
anche se dotato di un’architettura simile, ha permesso la verifica di alcuni componenti come il sottosistema di I/O. Precisamente la configurazione del computer
utilizzato é la seguente:
Processore: Intel Pentium IV 2.8GHz/533MHz FSB con 512KB di Cache L2
Mother Board: Gigabyte 8IK1100 (chipset Intel 875P)
Memoria: 4 x Corsair Value 512MB DDR PC3200
HD OS e DAQ: 2 x Maxtor DiamondMax Plus 9 da 80GB - Interfaccia UATA133, 7200RPM con 8 MB cache, in configurazione RAID 1 (mirroring)
utilizzando i RAID tools di linux (software RAID)
HD storage dati: 1 x MaxLine Plus II da 250 GB - Interfaccia U-ATA133, 7200
RPM con 8MB di cache
Il sistema di sviluppo ha permesso di testare le funzionalitá del DAQ in due
interessanti situazioni e cioé l’assenza di un’unitá con supporto SMP e l’utilizzo
di dischi ATA (in RAID). Particolarmente l’ultimo caso ha reso evidente il carico
di lavoro richiesto al computer e quindi, volendo rispettare i requisiti di velocitá
e resilienza, la necessitá di optare per altre soluzioni per le memorie di massa; le
specifiche per i nuovi sistemi di acquisizione discendono direttamente dai numerosi
test effettuati sul computer di sviluppo in condizioni di carico diversificate.
49
Capitolo 4. Upgrade e BugFix del Sistema
4.3
Soluzione dei problemi di Sincronizzazione
Il precedente DAQ di AURIGA, come introdotto nel paragrafo 4.1, presentava dei
malfunzionamenti nella sincronizzazione dei frame acquisiti dal rivelatore. Sono
stati effettuati molti test all’inizio del lavoro di tesi per meglio caratterizzare il
problema e, grazie all’analisi effettuata, si é giunti ad evidenziare i seguenti tre
possibili tipi di errore:
• Temporizzazione errata dovuta alla perdita o al danneggiamento, nella
comunicazione seriale, di un timestamp
• Errore nell’associazione dei tempi ai frame acquisiti dovuto al ritardo nella
generazione di un interrupt da parte della strumentazione VXI
• Perdita di un timestamp da parte di GPS anche in assenza di errori di
comunicazione
Come risulta evidente dalla tipologia di problemi riscontrati, tutte le cause di
errore non si presentano sistematicamente e quindi la loro riproduzione é risultata
talvolta complessa. Dall’identificazione del malfunzionamento si é proceduto alla
ricerca delle possibili cause e, dov’é stato possibile, alla loro rimozione.
Nelle sottosezioni successive vengono discusse in dettaglio le cause e le soluzioni agli inconvenienti riscontrati.
4.3.1
Errori di comunicazione
Capitava sovente, nella precedente versione del DAQ, che i timestamp inviati dal
ricevitore satellitare ESAT GPS 100 via seriale risultassero mancanti o corrotti.
Effettuando un log dei dati trasmessi dal GPS al PC si é notato che intere sequenze
(burst) di caratteri risultavano perse, portando a pacchetti ricevuti non conformi
alle specifiche del GPS.
Il primo passo nello studio del problema é stato scoprire se ci fosse una situazione in cui la perdita di dati si presentasse con una probabilitá piú elevata.
Dopo alcuni test si é riusciti a determinare che la probabilitá di errore cresceva
all’aumentare del carico del sistema, tuttavia non si trattava di carenza di capacitá di calcolo ma di utilizzo intenso del sottosistema di I/O. Per essere piú
precisi si é verificato che gli errori di comunicazione si presentavano con maggiore
frequenza all’aumentare del carico del sistema di I/O e quindi la relazione con il
carico del sistema andava ricercata nell’esaurirsi della memoria RAM e nell’utilizzo dello spazio di swap, situazione tuttavia non sufficiente a spiegare il motivo
della perdita dei dati. La ragione del malfunzionamento va ricercata nella porta
seriale e precisamente nel modo in cui linux la utilizza [34] [35].
Com’é noto, nei sistemi x86 piú recenti, le comunicazioni seriali sono affidate
alle UART 16550 - o derivati - che adottano un protocollo di comunicazione
seriale nel quale sono configurabili vari parametri come la velocitá, la paritá, la
50
4.3. Soluzione dei problemi di Sincronizzazione
presenza e il numero dei bit di stop, ecc. É inoltre previsto l’utilizzo del flowcontrol, grazie al quale due dispositivi seriali in comunicazione possono regolare il
flusso di dati utilizzando un protocollo start-stop. Il funzionamento dell’algoritmo
é abbastanza semplice: se ad esempio un dispositivo ricevente esaurisce i suoi
buffer e quindi non é in grado di accettare ulteriori dati, questo invia un segnale
di stop al trasmettitore che cessa istantaneamente la spedizione. Nel momento
in cui il ricevitore ritorna in grado di accettare nuovi dati invia un comando di
start al trasmettitore e cosı́ la comunicazione riprende. Con queste modalitá é
possibile regolare i flussi di trasmissione in entrambe le direzioni, andando cosı́ a
“proteggere” i buffer dei dispositivi impegnati nella comunicazione.
I sistemi operativi Linux permettono l’utilizzo completo del protocollo seriale,
compreso il controllo del flusso, tuttavia nulla fanno per proteggere il buffer di
ricezione dell’UART che, nel caso del 16550, ha una capacitá di 16 Byte. Quando
l’UART riceve un Byte solleva un’interruzione richiedendo l’intervento della CPU
per la lettura dei dati; i 16 Byte di buffer presenti nel dispositivo servono come
memoria temporanea per contenere gli ulteriori byte che arrivano alla seriale prima dell’intervento della CPU, a seguito del quale vengono copiati in memoria
centrale tutti i dati presenti nel buffer liberandolo. In Linux viene fatta l’assunzione che il sistema sia sufficientemente veloce da servire l’interruzione dell’UART
prima che questo abbia saturato il buffer e quindi non vi é alcun controllo del
flusso della comunicazione che provveda a fermare la ricezione qualora si verifichi
un overflow della memoria dell’UART. Viste le capacitá di calcolo attualmente disponibili, questa modalitá di operare sembra adeguata, infatti anche alla velocitá
massima dell’UART che é di 115.2Kbps, é sufficiente che la CPU risponda alla
richiesta di servizio entro un millisecondo. Il ricevitore satellitare utilizzato dal
DAQ trasmette i timestamp ad una velocitá di 38400bps e quindi, affinché non si
verifichi un buffer overflow, la CPU del sistema su cui é in esecuzione il DAQ deve
rispondere entro 3.8ms, tempo che sembra piú che accettabile. Si puó verificare tuttavia che, costringendo il sistema a operare pesantemente sulle memorie di
massa (HD e CD-ROM), vengono persi gran parte dei caratteri giunti alla seriale.
Il problema segue dalle dimensioni delle sezioni critiche (non interrompibili) delle
procedure di servizio alle interrupt.
Nel sistema operativo Red-Hat Linux 6.2, utilizzato originariamente per il
DAQ, come nel Red-Hat Linux 7.3 a cui é stato effettuato il primo porting, le
sezioni non interrompibili delle procedure che si occupano delle operazioni di
I/O su memoria di massa sono tali che, in caso di richiesta continua di letture
o scritture, bloccano completamente il sistema impedendogli non solo di servire
le richieste dell’interfaccia seriale ma anche qualsiasi altro processo. Per questa
ragione principalmente é stata abbandonata la distribuzione Red-Hat Linux 7.3
a cui inizialmente si era pensato di portare il sistema; utilizzando questa versione
infatti non é possibile evitare di incorrere nella perdita di pacchetti, nemmeno
agendo sui livelli di prioritá delle interruzioni, a meno di non voler sviluppare nuovi driver per la gestione delle porte seriali. Infatti, anche configurando il sistema
affinché una richiesta di interruzione da parte dell’UART 16550 venga servita
immediatamente, non si puó garantire che all’atto della ricezione via seriale di un
51
Capitolo 4. Upgrade e BugFix del Sistema
carattere il sistema non stia utilizzando il disco fisso e quindi, essendo il pacchetto
contenente lo stamp di 43 Byte, non é possibile garantirne la completa ricezione.
Una possibile soluzione, anche se parziale, del problema consiste nell’utilizzo
di un convertitore seriale/USB. Il ricevitore satellitare infatti é dotato di sole
porte seriali e quindi, a meno di non provvedere all’acquisto di un nuovo strumento, la comunicazione deve avvenire mediante l’utilizzo di dispositivi RS-232.
L’adozione di un convertitore seriale/USB, dispositivi ben supportati dal sistema
operativo Linux, permette di aggirare il problema. Essendo le comunicazioni su
bus USB molto piú veloci di quelle realizzate con dispositivi RS-232, il convertitore deve possedere un buffer interno di dimensioni maggiori rispetto a quello
integrato nell’UART 16550 (nei modelli considerati nei nostri test tipicamente
ammontava ad alcune centinaia di Byte), per cui puó contenere piú pacchetti
completi provenienti dal ricevitore GPS senza causare la perdita di un singolo
carattere. In questo modo non viene risolto l’inconveniente causato dall’ininterrompibilitá del sistema, ma viene aumentata la resilienza della comunicazione,
permettendo tempi di attesa molto maggiori: con un buffer di soli 256 Byte il
sistema puó evitare perdite di dati anche se non effettua alcuna lettura dalla
seriale per 16s.
Si é comunque deciso di utilizzare Red-Hat Linux 9, ultimo prodotto “stabile”
della famiglia free, dato che la politica adottata dalle procedure di servizio in
termini di ininterrompibilitá é stata radicalmente cambiata, riducendo le sezioni
critiche e limitando quindi gli intervalli di tempo in cui il sistema non é in grado
di rispondere a ulteriori stimoli. Rendere interrompibili le procedure di servizio
che si occupano dell’I/O del computer ovviamente ha un prezzo che si traduce
in un maggiore ritardo per il loro completamento, tuttavia questo slow-down,
stimato in qualche punto percentuale, per nulla incide sul buon funzionamento
del DAQ; di conseguenza si é adottata quest’ultima versione di Linux non solo
per l’esecuzione, ma per l’intero sviluppo del sistema.
4.3.2
Ritardo nel sollevamento delle Interruzioni
Un altro problema che si verificava durante l’utilizzo del DAQ era la presenza
di frame con una datazione errata anche se ricevuta dal GPS. Come indica nella
Sezione 3.3, l’errore assoluto che viene commesso dal ricevitore é di circa 70ns, nei
dati raccolti peró erano presenti degli errori di datazione di alcuni millisecondi,
giungendo in prossimitá del secondo in qualche caso piú raro. Se si considera
corretto il tempo proveniente dal GPS, le uniche possibilitá sono la generazione
delle interruzioni in un momento sbagliato oppure la presenza di segnali “spuri”
sulle linee di interruzione del bus VXI.
Il secondo caso é stato facilmente eliminato confrontando nei vari run il numero
di interruzioni generate dagli ADC con il numero dei segnali ricevuti - canale per
canale - dalla scheda S80. Dall’uguaglianza di questi valori anche nei periodi di
acquisizione in cui si era verificata l’anomalia si é potuta escludere la generazione
di “interrupt anomale”. La causa dell’errata temporizzazione era quindi dovuta
ad una generazione ritardata del segnale di interruzione.
52
4.3. Soluzione dei problemi di Sincronizzazione
La gestione in “daisy-chain” delle interruzioni nel bus VXI richiede che uno
strumento, prima di generare il segnale, verifichi la linea che desidera utilizzare per
accertarsi che non vi sia una richiesta di servizio precedente di un altro dispositivo.
Dopodiché il protocollo VXI prevede che uno strumento possa sollevare un segnale
di interruzione - cioé porti a massa la linea corrispondente nel bus VXI - e lo
mantenga attivo fino alla ricezione di un interrupt acknowledge (IACK) da parte
del controllore del BUS che certifica l’avvenuta elaborazione della richiesta.
Sono stati effettuati test ad-hoc per verificare la corrispondenza alle specifiche
e, come atteso, si é potuto accertare che la strumentazione, anche nella gestione
delle interruzioni, rispetta il protocollo VXI. In particolare si é investigato il meccanismo di generazione delle interruzioni in presenza di precedenti richieste non
ancora servite, verificando che in questo caso non vengono generati ulteriori segnali. Lo strumento infatti accoda le richieste di interruzioni pendenti e, all’arrivo
dell’IACK, provvede alla elaborazione delle ulteriori richieste di servizio.
Il tassello rimanente nella soluzione del problema é il motivo per cui non venivano riscontrate le interruzioni in tempo utile che, per inciso, é abbastanza
lungo. Visto che le interruzioni vengono utilizzate per la datazione dei frame,
il problema si verificava non appena una richiesta di interruzione veniva accodata. Considerando la scheda Agilent E1430 nella configurazione utilizzata per
l’acquisizione del rivelatore (frequenza di campionamento 4882.8125Hz, rappresentazione a 32bit dei campioni e utilizzo di buffer di 64KB - 16KSa), affinché
venga accodata una richiesta di servizio é necessario che lo strumento non riceva alcun riscontro per l’intera durata di un buffer che, nel caso specifico, é
16KSa/4882.8125Hz ' 3.355s.
La ragione per un tale ritardo é la gestione della comunicazioni a segnali adottata nella versione del DAQ precedente l’aggiornamento. In essa infatti, utilizzando la libreria ni-vxi di National Instruments, tutte le richieste di interruzione
provenienti dal bus VXI venivano convertite in segnali, permettendo ai processi
del DAQ di eseguire operazioni come WaitForSignal, sospendendosi in attesa di
segnalazioni provenienti dal bus VXI.
In questa modalitá peró, la risposta ad una richiesta di servizio puó richiedere
un tempo piuttosto lungo essendo necessaria in primo luogo la conversione dell’interruzione in segnale da parte del driver ni-vxi, successivamente deve essere
modificato lo stato del processo sospeso in runnable per essere schedulato per
l’esecuzione. Infine, quando il processo riconquistava l’utilizzo della CPU poteva
finalmente leggere il segnale dalla coda ed eseguire le operazioni successive.
Si é verificato che, in condizioni di carico elevato, poteva accadere che la
risposta al segnale fosse ritardata di un tempo superiore alla durata di un buffer, causando quindi il ritardo nell’invio dell’acknowledge e quindi l’accodamento
dell’interruzione successiva.
Per risolvere questo malfunzionamento si é quindi deciso di modificare la gestione della comunicazione con le schede VXI, passando dalla modalitá a segnali
alla gestione ad interrupt. Sono stati quindi implementati gli handler specifici
per gli strumenti utilizzati (Agilent E1430 e HP 1413), riducendo le operazioni
eseguite al loro interno alla semplice lettura dei dati dal buffer dello strumento
53
Capitolo 4. Upgrade e BugFix del Sistema
alla memoria RAM, limitandone cosı́ la durata di esecuzione. In questa modalitá,
la richiesta di interruzione da parte di uno strumento VXI causa immediatamente
l’invocazione dell’handler che, implementando un numero di operazioni minimale,
termina la sua esecuzione nel tempo necessario al solo trasferimento dei dati. Il
completamento dell’esecuzione della procedura di servizio causa l’immediato invio di un segnale di Interrupt Acknowledge allo strumento che aveva sollevato la
richiesta; con questa modalitá si é quindi riusciti a minimizzare i tempi di risposta
del sistema risolvendo i problemi di temporizzazione dovuti all’accodamento di
interruzioni.
A prova della soluzione proposta é stato effettuato un periodo di acquisizione
di poco piú di due mesi. A fronte di una frequenza iniziale degli errori di temporizzazione del tipo discusso di circa tre alla settimana, con l’utilizzo della gestione
ad interrupt si é scesi ad una frequenza di zero eventi in due mesi.
4.3.3
Mancata lettura di un timestamp dalla coda di GPS
Un possibile malfunzionamento é legato alla modalitá con cui avviene la comunicazione tra BLD (vedi Sezione 3.8.4) e GPS (vedi Sezione 3.8.3) e in particolare
all’algoritmo che veniva utilizzato per la verifica della presenza di nuovi timestamp
nella coda del GPS.
Come giá indicato nel capitolo precedente, la comunicazione fra i processi
componenti il DAQ avviene utilizzando CORBA, middleware che permette l’invocazione di metodi di oggetti remoti. Caratteristica di CORBA ampiamente
sfruttata nel progetto del DAQ é la possibilitá di gestire le eccezioni sollevate
dall’invocazione di un metodo remoto, infatti la sincronizzazione tra i processi
produttori e consumatori, piuttosto che essere realizzata con strutture esterne
classiche tipo semafori, é stata implementata utilizzando le eccezioni. In buona
sostanza, quando un processo client (consumatore) desidera leggere dei frame da
una coda remota, questo effettua la richiesta di lettura che avrá successo nel caso
in cui il processo server (produttore) ha dei frame accodati, altrimenti solleverá
un’eccezione indicante l’assenza di dati.
Per comprendere le ragioni di un fallimento della lettura di un frame che
invece era presente nella coda, oltre al processo di sincronizzazione, é necessario
considerare come il builder opera l’associazione tra un frame e il tempo a cui é
stato generato.
Il working thread del builder consiste essenzialmente in un ciclo all’interno del
quale viene effettuata una richiesta di lettura al processo server che si interfaccia
con l’ADC, alternando le operazioni tra ANT (vedi Sezione 3.8.1) e AUX (vedi
Sezione 3.8.2). Se il processo interrogato non dispone di nuovi frame viene
generata un’eccezione a seguito della quale il builder rinuncia nella lettura e
cambia processo da interrogare. In seguito ad un successo nella lettura il builder,
ottenuto il frame, deve provvedere alla sua corretta datazione, effettuando una
richiesta di nuovi frame al processo GPS. Come indicato nella Sezione 3.8.3,
quest’ultimo mantiene al suo interno una coda per ogni strumento utilizzato dal
54
4.3. Soluzione dei problemi di Sincronizzazione
DAQ - normalmente sono 2, una per ANT e una per AUX - nelle quali vengono
memorizzati in ordine di arrivo i timestamp ottenuti dal ricevitore satellitare.
La presenza di un nuovo frame nel processo ANT o AUX indica che necessariamente é stata sollevata un’interruzione dalle schede di acquisizione e quindi
il ricevitore satellitare deve aver generato un nuovo timestamp. Di conseguenza,
a seguito di un successo nella lettura di un frame da ANT o AUX, il builder
deve considerare che la presenza di un frame in GPS é quasi certa, a meno di un
errore di trasmissione che comunque ha un probabilitá molto ridotta; il builder
inoltre deve tener conto di operare in un sistema in time-sharing e quindi deve
considerare che un processo non sia pronto per la sincronizzazione per ragioni di
scheduling.
In seguito a tutte le precedenti considerazioni, la lettura di nuovi frame dal
processo GPS non avviene semplicemente invocando il metodo GetData e considerando la presenza di un’eccezione come l’indicazione dell’assenza di un frame.
Viene invece utilizzato un algoritmo simile al backoff binario impiegato nelle reti
Ethernet in cui, a seguito di una richiesta con esito negativo, il builder si sospende
per un tempo crescente in modo da aumentare la probabilitá che il processo GPS
venga mandato in esecuzione e diventi pronto per la sincronizzazione. In maniera
simile al backoff, dopo dieci tentativi il builder rinuncia alla lettura considerando
il timestamp perso a seguito di un errore di trasmissione e provvede quindi in
proprio alla generazione di un tempo basandosi sull’ultimo stamp ricevuto, sulla
dimensione del frame e sulla frequenza di campionamento.
Nella versione del DAQ precedente, accadeva che talvolta l’algoritmo sopra
descritto fallisse, indicando l’assenza di un timestamp che in realtá era stato
regolarmente accodato, andando ad incidere pesantemente sui requisiti di temporizzazione per l’esperimento. Infatti, essendo le code del GPS delle FIFO, il
timestamp erroneamente non elaborato rimaneva nella coda e veniva considerato
come il tempo del frame successivo a quello che lo aveva generato. A questo punto
erano possibili due strategie, che portavano entrambe a inficiare l’errore massimo
ammesso per la temporizzazione. La prima e piú semplice possibilitá consisteva
nel non effettuare alcuna correzione dei tempi, in tal modo tutti i frame successivi a quello in cui si era verificato l’evento presentano uno slittamento all’indietro
pari al tempo di un frame. L’altra possibilitá consisteva nella verifica del tempo proveniente dalla coda GPS con un tempo calcolabile dal builder. Stabilito
un errore massimo commettibile nella temporizzazione, il builder provvedeva
allo scarto dei timestamp con errore superiore ad e al calcolo via software di
tempi sostitutivi. Essendo piccolo, dell’ordine del microsecondo o meno, tutti
i pacchetti nella coda del GPS venivano scartati a seguito del verificarsi di una
mancata ricezione; essi infatti presentavano un errore fittizio pari alla durata di
un frame e quindi, prendendo ad esempio il caso di ANT, superiore a 3 secondi.
Quest’ultima modalitá, sebbene avesse il vantaggio di generare frame con tempi consecutivi, andava ad incidere sull’errore assoluto ammesso. I tempi infatti
venivano tutti calcolati in base all’ultimo timestamp precedente il verificarsi dell’errore a seguito del quale non era quindi piú possibile garantire una datazione
con un errore assoluto inferiore ai 100ns.
55
Capitolo 4. Upgrade e BugFix del Sistema
La causa dell’inconveniente va ricercata nel funzionamento in time-sharing del
calcolatore utilizzato e nell’adozione di CORBA che introduce un’ulteriore step
nella comunicazione fra processi.
Figura 4.5: Schematizzazione della sincronizzazione tra i processi
BLD e GPS
In Figura 4.5 sono schematizzati i passaggi necessari per compiere la sincronizzazione e quindi il trasferimento di dati tra il processo BLD e GPS. Si nota
che affinché BLD possa effettuare la richiesta é innanzitutto necessario che precedentemente GPS sia stato eseguito ed abbia ultimato l’accodamento di nuovi
stamp. In seguito BLD puó effettuare la chiamata la metodo remoto che richiede
la disponibilitá di CORBA per essere effettuata. É necessario quindi che venga
tolto l’utilizzo della CPU a BLD, che vada in esecuzione CORBA e infine GPS,
il quale provvederá alla gestione della richiesta. Nel caso siano presenti nuovi
timestamp sono necessari anche i passaggi inversi per cui deve essere eseguito
CORBA e infine BLD che riceve i nuovi frame. In un sistema che opera in multitasking con molti processi in esecuzione (basti pensare solo a quelli del sistema
operativo a cui si aggiungono i vari demoni) puó trascorrere un certo tempo prima che l’ordine di scheduling porti alla sequenza di esecuzione richiesta. Dai test
effettuati sul computer di sviluppo (Sezione 4.2.2) si é appurato che un’attesa di
8 secondi tra la ricezione di uno stamp e il successivo, quindi un’attesa di circa 5
secondi perché la comunicazione sia possibile, é tutt’altro che rara, come indicato
in Figura 4.6 dove sono stati istogrammati gli intervalli trascorsi tra la ricezione
di due timestamp relativi al canale principale, in un periodo di osservazione di
12 giorni di acquisizione continua.
L’algoritmo di backoff utilizzato in precedenza effettuava dieci tentativi prima
di dichiarare l’indisponibilitá di nuovi frame nella coda del GPS e, tra di essi, il
builder veniva sospeso per un tempo pari a 100ms moltiplicato per il numero
56
4.3. Soluzione dei problemi di Sincronizzazione
Figura 4.6: Istogrammazione degli intervalli di tempo tra due
ricezioni di timestamp relativi al processo ANT
del tentativo, giungendo quindi ad un’attesa massima totale di 4.5s, che, come
dimostrato, é insufficiente.
Nella nuova versione del DAQ si é quindi modificato l’intervallo d’attesa totale in considerazione delle osservazioni effettuate. Tuttavia, con periodi cosı́
lunghi, l’algoritmo di backoff si rivelava inefficiente, rischiando di sospendere il
builder per un periodo troppo elevato e quindi, dovendo questo elaborare anche
le richieste degli altri strumenti, introducendo la possibilitá che alcuni frame andassero persi. Si é quindi provveduto a rendere il periodo di sospensione statico
impostandolo a 100ms (intervallo che sperimentalmente é sembrato adeguato) e
introducendo la possibilitá di richiedere il timestamp per una durata massima di
20s. In questo modo, qualora lo stamp sia immediatamente - o quasi - disponibile
(prima colonna in Figura 4.6), il builder procede al recupero del frame con un
ritardo minimo mentre, nel caso l’intervallo di attesa si allungasse, i tempi di
sospensione rimangono brevi, evitando di rendere unrunnable BLD per periodi
troppo lunghi anche se in questa modalitá si penalizza leggermente il sistema
dato che, per lunghe attese, il BLD va in esecuzione semplicemente per essere
risospeso.
Le modifiche descritte, introdotte nella nuova versione del DAQ, oltre ad
essere suffragate dalla statistica dei tempi di arrivo dei frame sopra esposta, sono
state verificate sperimentalmente mediante piú run di acquisizione effettuati con
diverso carico del sistema. Il risultato, come attendibile, é stato la totale assenza
dell’errore descritto, in qualsiasi condizione e con qualsiasi durata del run3 .
3
Il test piú lungo é consistito in circa due mesi di acquisizione
57
Capitolo 4. Upgrade e BugFix del Sistema
4.4
Segnali Ausiliari
Il processo AUX (vedi Sezione 3.8.2) ha subito i maggiori cambiamenti, probabilmente per il funzionamento non intuitivo dello strumento HP 1413 a cui si
interfaccia. Per esso infatti sono previste librerie a corredo, dalla SCPI al DAQ
Express di National Instruments, utilizzando le quali operazioni come lo “spacchettamento” dei canali risultano trasparenti all’utente, semplificandone di molto
l’utilizzo. Tuttavia, qualora sia richiesto l’utilizzo diretto dello strumento - come
nel nostro caso - la documentazione fornita con esso é decisamente incompleta.
Non trovano posto nella manualistica infatti i dettagli implementativi del funzionamento dell’ADC e della programmazione dei registri per cui, nella soluzione
dei problemi che erano stati riscontrati per gli ausiliari, si é dovuto procedere con
tecniche di reverse-engineering fino alla comprensione delle strategie adottate dal
dispositivo.
Le modifiche apportate ad AUX possono essere considerate sostanziali. Di
seguito vengono analizzate le variazioni introdotte assieme ai problemi che le
hanno rese necessarie.
4.4.1
Stato dell’ADC HP 1413
L’acquisizione dei canali ausiliari, nella versione precedente del sistema, presentava una serie di problemi, causando malfunzionamenti che andavano dal crash del
DAQ all’acquisizione di valori non validi; all’aumentare della frequenza di campionamento, inoltre, nei valori letti si presentavano degli intervalli costituiti da
NaN4 , indicanti un qualche tipo di errore di lettura del buffer dell’ADC. Inoltre,
utilizzando piú di due canali per l’acquisizione, il processo AUX dopo qualche
giorno si fermava senza alcuna apparente motivazione.
Questi malfunzionamenti erano dovuti prevalentemente alla mancanza di un
controllo dello stato dell’ADC prima di effettuare una lettura, che tuttavia veniva
eseguita come indicato nel manuale. Dalla documentazione infatti risulta che,
prima di procedere alla lettura di un buffer dalla FIFO, é necessario accertarsi
della presenza di almeno 32KSa, cosa giá nota al momento dell’operazione dato
che nel DAQ la lettura di un buffer viene effettuata in seguito ad un’interruzione
e lo strumento viene configurato per sollevarla al verificarsi all’evento FIFO HALF
FULL, cioé non appena dispone di 32KSa.
La parte piú complessa nella soluzione di questo problema é stata appunto il determinare - mediante reverse engineering - cosa accadeva nell’ADC visto
che all’esterno, ad esclusione dei valori NaN, non traspariva alcun tipo di segnalazione di errore. Attraverso una serie di test congiunti dello strumento e del
funzionamento della libreria ni-vxi, si é riusciti risolvere il malfunzionamento
comprendendo i motivi del blocco del processo AUX.
La presenza di valori NaN era indice di un errore di lettura a seguito del quale
lo strumento asseriva un “BUS Error”, cioé una richiesta di servizio al sistema
4
Not A Number: numero non valido la cui rappresentazione in floating point (IEEE-754)
consiste in un numero con tutti i bit dell’esponente a 1.
58
4.4. Segnali Ausiliari
host a seguito del verificarsi di un non meglio specificato errore di comunicazione.
All’atto del caricamento in memoria della libreria ni-vxi, venivano installati dei
“default handler” per tutte le possibili richieste di servizio - senza alcun tipo
di operazione al loro interno - che potevano poi essere sovrascritti da handler
implementati dall’utente. Al verificarsi del BUS error veniva quindi invocato il
default handler, andando cosı́ a mascherare il problema di comunicazione senza
risolverlo visto che la procedura non eseguiva alcunché.
Compresa la sequenza di eventi che andava a minare il funzionamento del
sistema, la soluzione é stata semplice. Nell’ADC HP 1413 esiste un registro chiamato FIFO STATUS (indirizzo 2416 ) i cui bit indicano vari parametri della memoria
come la dimensione dei dati (32 bit), di un blocco della FIFO (32768 campioni),
ecc. In particolare il bit meno significativo, denominato FIFO READY, indica se lo
strumento é pronto per un accesso alla FIFO oppure no. É stato quindi sufficiente, nell’handler che si occupa della copia dei dati dallo strumento alla memoria
RAM del computer, far precedere ogni operazione di lettura dall’asserzione di
questo bit. Con la modifica descritta sono state eliminate tutte le presenze di
NaN indipendentemente dal numero di canali utilizzati e dalla frequenza di campionamento (si puó ora operare a banda piena, cioé a 100KSa/s) e risolvendo
anche il blocco del processo AUX che era dovuto alla mancata gestione degli
errori di comunicazione.
4.4.2
Sincronizzazione degli Ausiliari
La temporizzazione dei frame acquisiti avviene con la stessa modalitá del canale
principale, viene cioé configurato l’ADC per generare un’interruzione - al termine
di un buffer - che viene inviata alla scheda S80 del ricevitore satellitare ottenendo
cosı́ la datazione dei campioni. A differenza dell’Agilent E1430, il buffer della
scheda HP 1413 ha una dimensione prestabilita di circa 32KSa, a fronte di una
dimensione richiesta per i frame degli ausiliari di 4KSa. La dimensione del buffer
utilizzato dallo strumento inoltre non aumenta in modo da ospitare un numero
costante di campioni per canale e quindi, volendo esemplificare, acquisendo un
singolo canale ogni buffer contiene 8 frame, utilizzando 2 canali ne contiene 4,
ecc., complicandosi ulteriormente la situazione qualora la dimensione del buffer
non sia un multiplo del numero di canali utilizzato.
Risulta evidente da quanto esposto che il processo BLD, il cui scopo é la
costruzione dei frame in formato IGWD, oltre a ricavare i campioni relativi ad ogni
canale a partire dal contenuto del buffer ricevuto, deve provvedere al calcolo del
tempo associato ad ogni frame utilizzando una qualche tecnica di interpolazione.
Il vecchio DAQ manteneva a questo scopo una coda dei tempi provenienti dal GPS
e, operando una media su di essi, calcolava il tempo del singolo frame. Nei dati
prodotti con questa modalitá tuttavia si presentava una discontinuitá al termine
di ogni frame, evidenziando un problema di temporizzazione.
La prima azione intrapresa é stata riscrivere la parte di BLD che si occupa del
timing, modificando il metodo con cui vengono calcolati i tempi. Il sistema utilizzato nel vecchio DAQ infatti, basandosi su una media, andava a ridurre l’errore
59
Capitolo 4. Upgrade e BugFix del Sistema
complessivo del risultato, tuttavia in presenza di un qualche problema di temporizzazione, questo, piuttosto che rimanere confinato al frame in cui si é verificato,
veniva distribuito almeno sull’intero buffer. Si é quindi deciso di abbandonare
l’utilizzo di medie e di considerare i timestamp solo localmente: nell’algoritmo
implementato il tempo di un frame viene calcolato in base all’ultimo timestamp
disponibile e all’indice relativo al primo campione del frame, associando ad ogni
timestamp una validitá pari al numero di campioni costituenti un buffer. In questo modo i tempi associati ai frame sono soggetti ad un errore assoluto che é
prossimo a quello commesso dal GPS (70ns) e l’eventuale presenza di un errore
di temporizzazione influenza solo il buffer in cui é stato prodotto.
Effettuando delle misurazioni sui dati raccolti con l’algoritmo appena descritto
si é verificata la presenza costante di una irregolaritá al termine di ogni buffer,
con un andamento deterministico. Si é verificato infatti che la dimensione della
discontinuitá era inversamente proporzionale al numero di canali impiegati e alla
frequenza di campionamento; il suo valore alle frequenze utilizzate era tuttaltro
che trascurabile: con un canale a 200Hz, consisteva in circa 0.45ms per ogni
frame, introducendo un errore stimabile nello 0.22%.
Per comprendere la provenienza di questa irregolaritá é necessario considerare
l’algoritmo utilizzato dalla scheda HP 1413 per comandare l’acquisizione. Come
indicato nella Sezione 3.5, lo strumento utilizza delle scanning list per mantenere
l’elenco dei canali da acquisire, assieme ad un registro che contiene l’intervallo di
attesa tra l’acquisizione di un canale e il successivo. Per impostare una frequenza
di campionamento TC , la scheda va impostata in modalitá soft triggered, in cui la
scansione di una lista viene iniziata a seguito della presenza di un trigger software
generato dallo strumento stesso con la frequenza di campionamento richiesta.
Ogni TC secondi viene dato inizio ad una acquisizione e quindi la reale frequenza
di campionamento non é quelle impostata ma vale
1
Hz,
(4.1)
TC + DT RIG
dove DT RIG é il ritardo introdotto dalla generazione del trigger. Considerando in quest’ottica la discontinuitá presente al termine di ogni frame, si puó
ottenere il ritardo introdotto dalla generazione del trigger; per l’acquisizione di
un canale a 200 Hz, condizione in cui il buffer é di 32768 campioni, si ottiene
DT RIG ' 3.6ms/32768Sa ' 110ns, tempo compatibile con i ritardi introdotti
dall’elettronica dello strumento.
Per poter determinare la durata di un frame in base ai timestamp ricevuti
dal GPS é indispensabile conoscere la dimensione del buffer che - nella documentazione - viene indicata come costante e pari a 32768 campioni, cioé metá della
dimensione della FIFO.
Dai test effettuati per la verifica del timing si é scoperto che, quando il numero di canali utilizzato non é un sottomultiplo della dimensione del buffer, la
sua durata varia indicandone un cambiamento di dimensione. Dopo numerose
verifiche si é infatti appurato che lo strumento solleva l’interruzione di fine buffer
al termine dell’esecuzione di una scanning list e quindi, qualora non sia possibile
FC =
60
4.4. Segnali Ausiliari
ultimare la scansione all’interno dei 32KSa, l’ADC posticipa la generazione dell’interruzione. Dalle considerazioni esposte si puó derivare la dimensione effettiva
del buffer che é data da:
32768
Dim Buffer =
∗ chNum
(4.2)
chNum
dove chNum é il numero di canali utilizzato per l’acquisizione. Considerando questo valore come dimensione reale del buffer vengono corretti sia i tempi calcolati
che gli intervalli in cui devono essere considerati “validi” i timestamp ricevuti,
ottenendo infine la corretta datazione e quindi, nel corso di un run, l’assenza di
discontinuitá temporali tra i frame prodotti.
4.4.3
Frequenza di campionamento
Collegato in parte al precedente problema vi é la frequenza di campionamento
utilizzata dall’ADC HP 1413. La configurazione della frequenza di esecuzione
delle scanning list nello strumento si imposta mediante una scrittura del registro
Trigger Timer Register (indirizzo 2C16 ) il cui valore a 16 bit determina l’attesa
tra una scansione e la successiva secondo la seguente espressione
Intervallo = (10−4 ∗ valore registro) + 10−4
s
(4.3)
dalla quale possono essere ricavate un paio di osservazioni. La frequenza massima a cui puó operare lo strumento su di un singolo canale - ottenibile in corrispondenza del valore 0 del registro - é pari a 10KHz, di conseguenza la banda
massima dell’ADC, dichiarata in 100KSa, puó essere ottenuta solo mediante l’utilizzo di piú canali. Inoltre la precedente espressione indica la granularitá con
cui é selezionabile il periodo di campionamento, pari a 0.1ms. Non é quindi
possibile impostare una frequenza di campionamento qualunque com’era previsto
nell’interfaccia grafica del DAQ.
Come indicato nella Sezione 3.7.3, nei frame salvati su disco vengono inserite tutte le informazioni sulla configurazione degli ADC affinché il software che
effettua successivamente l’analisi possa prelevarvi sia i dati che i parametri da
utilizzare. L’inserimento in un frame di una frequenza di campionamento non
corrispondente a quella realmente impiegata dallo strumento porta ad un problema di inconsistenza che, nella migliore delle ipotesi, si traduce nell’indicazione
della mancanza di una porzione di dati al termine di ogni frame, causata dalla
differenza tra la durata effettiva e il tempo calcolabile con la frequenza di campionamento in esso memorizzata. A tale discontinuitá va ad aggiungersi inoltre
il tempo dovuto al ritardo nella generazione del trigger che avvia la scansione,
aumentandone l’entitá.
Si é dovuto procedere ad una correzione della frequenza di campionamento
memorizzata nei frame per tener conto dei due aspetti citati. La soluzione adottata consiste nel calcolare dinamicamente la frequenza di campionamento di ogni
buffer, svincolandosi in questo modo anche da possibili jitter del clock. Allo scopo, il builder utilizza la coda contenente i tempi di arrivo dei buffer provenienti
61
Capitolo 4. Upgrade e BugFix del Sistema
da AUX e, posticipando la creazione dei frame di un buffer, calcola per ognuno
la reale frequenza di campionamento a partire dalla differenze dei tempi di inizio
e fine buffer (forniti dalla coda) e dalla dimensione degli stessi, calcolata come
indicato nella Sezione 4.2.
4.4.4
Migliorie e correzioni minori
Oltre a quanto giá indicato, AUX é stato oggetto di altre modifiche di entitá
inferiore, la cui descrizione viene raggruppata nel seguente paragrafo.
Il processo AUX nella versione precedente del DAQ presentava un errore in
seguito al quale la precisione dei valori letti degradava. La lettura dei dati memorizzati nel buffer dell’ADC HP 1413 avviene mediante due registri di 16 bit,
FIFO MSW (indirizzo 2016 ) e FIFO LSW (indirizzo 2216 ), la cui lettura sequenziale
permette di ottenere il valore rispettivamente della parte piú e meno significativa
del dato nel formato IEEE-754; l’incremento del contatore al campione successivo
avviene automaticamente in seguito alla lettura del primo registro. Nella versione precedente del DAQ la lettura avveniva con le stesse modalitá della scheda
Agilent E1430, nella quale viene utilizzato un solo registro, che alterna il suo
contenuto con la parte piú significativa e quella meno significativa.
Avendo utilizzato la stessa modalitá di lettura per gli ausiliari, la precisione
massima raggiungibile era di 7 bit sui 16 forniti dall’ADC. Si é provveduto in
primo luogo a correggere questo malfunzionamento rendendo la precisione dei
dati conforme alle specifiche.
La correzione dei problemi indicati nelle precedenti sezioni ha fornito la possibilitá di utilizzare piú completamente lo strumento, permettendo di sfruttarne
la completa banda passante insieme ad un maggior numero di canali. Si é quindi proceduto alla modifica del front-end affinché queste operazioni diventassero
possibili.
Gli SCP (vedi Sezione 3.8.2) utilizzati assieme all’ADC permettono il filtraggio del segnale di ingresso con un filtro passa-basso avente frequenza di taglio
programmabile a 2, 10 o 100Hz. Non era stato previsto nel DAQ l’utilizzo della
modalitá pass-throught grazie alla quale il canale viene filtrato a 1.5KHz. Si é
quindi provveduto a modificare sia la programmazione degli SCP che l’interfaccia
grafica per rendere possibile l’esclusione del filtro e quindi l’aumento della banda
di un fattore quindici per canale.
Affinché fosse possibile utilizzare tutti i canali disponibili (24 su 64) é stato
inoltre necessario provvedere ad un corretto dimensionamento di alcune strutture
della libreria PCL. In particolare, prima del processo di scrittura dei frame su
disco, questi vengono memorizzati in un buffer che funge da memoria temporanea per il passaggio dei dati da PclFcl alla Frame Library. Tale buffer, per
ridurre l’occupazione di memoria, era stato creato con una dimensione tale da
poter ospitare al massimo quindici canali ausiliari (da 4 KSa) e quindi era insufficiente alla memorizzazione di tutti i canali disponibili. Si é quindi provveduto
alla modifica del precedente, creando lo storage necessario all’utilizzo di tutti gli
ingressi disponibili.
62
4.5. Sistema Operativo
Infine, la disponibilitá dei nuovi ingressi ha permesso la connessione al sistema
di acquisizione di nuovi strumenti come microfoni, sonde magnetiche, titlmetri,
ecc. Dato che nei frame vengono memorizzate le informazioni relative alla configurazione degli ADC e quindi anche quali strumenti vi sono connessi, si é provveduto
a modificare il DAQ (GUI ed altro) affinché fosse possibile tener traccia dei nuovi
dispositivi.
4.5
Sistema Operativo
Come giá indicato il sistema operativo utilizzato per il DAQ é il Red-Hat Linux
9.0 [29], nell’ultima versione disponibile, cioé corredato di tutti gli aggiornamenti
ufficiali di Red-Hat, la cui fornitura peró é terminata definitivamente il 30 Aprile 2004, data in cui Red-Hat ha abbandonato il prodotto. In seguito alla fine
del supporto si é dovuto provvedere in proprio all’aggiornamento dei pacchetti
utilizzati.
L’indisponibilitá di aggiornamenti assieme alla necessitá di ottenere il massimo
livello di prestazioni e resilienza del sistema di acquisizione ha fornito l’occasione
per provvedere alla creazione di una vera e propria nuova distribuzione composta
dai tools selezionati per lo sviluppo del DAQ.
Alla versione ufficiale di linux si é in primo luogo provveduto ad aggiornare
il gestore del desktop per poter utilizzare la versione selezionata di KDevelop
[32]. Si é quindi prima installato la versione 3.3.3 di QT [30] su cui si basa KDE
[31], il gestore del desktop scelto, ottenendo cosı́ anche l’IDE per lo sviluppo
dell’interfaccia grafica del DAQ e del software di calibrazione: QTDesigner. La
compilazione di KDE in realtá si é articolata in due fasi: una prima in cui si é
effettuato il passaggio alla versione 3.2 - precisamente terminato il processo di
aggiornamento si é arrivati alla 3.2.3 - seguita di una seconda resasi necessaria
dalla distribuzione della release 3.3. L’utilizzo di KDE é stato reso indispensabile
dall’aver scelto KDevelop come IDE; le versione 3.2 di KDE venivano distribuite
con KDevelop 3.0.x in quale introduceva delle interessanti migliorie rispetto al
suo predecessore - il 2, integrato nella Red-Hat 9 - ma presentava anche qualche
leggera instabilitá, come tutti i nuovi prodotti. Si é voluto, all’uscita della release correttiva di KDevelop (la 3.1) poterla adottare e quindi é stata necessaria
l’adozione di di KDE 3.3.1.
Come in una reazione a catena, l’adozione di questo specifico IDE (e quindi del
gestore del desktop) ha richiesto l’aggiornamento di buona parte dei componenti
di sistema: dagli autotools ai vari interpreti come python, ruby, ecc. Uno dei
pochi pacchetti che é rimasto nella configurazione iniziale é stato il GCC 3.2.2
assieme alla glibc dato che il DAQ é stato sviluppato usando lo standard C++
adottato da questo compilatore.
L’ultimo kernel distribuito dalla Red-Hat per la distribuzione 9.0 é il 2.4.20 31.9 che, anche se con probabilitá ridotta, ha presentato degli inconvenienti, in
particolare dei kernel panic in seguito alla’esecuzione di alcuni task amministrativi.
63
Capitolo 4. Upgrade e BugFix del Sistema
Si é pensato quindi di ricompilare un nuovo kernel, appositamente per il sistema di acquisizione. L’utilizzo della libreria ni-vxi imponeva l’utilizzo di un
kernel della famiglia 2.4, si é quindi scelta l’ultima release disponibile [33], la
2.4.27, e la si é compilata.
Vista la necessitá di un nuovo kernel, si é provveduto a compilarlo in base alle
specifiche della macchina di sviluppo, utilizzando tutte le possibili ottimizzazioni
(codice macchina specifico per Intel Pentium IV, supporto di tutte le caratteristiche di CPU e MB) e selezionando solo i driver necessari, i quali sono stati inclusi
direttamente nel kernel se di utilizzo molto frequente (ad esempio il supporto
RAID) altrimenti come modulo (USB, FireWire).
4.6
Librerie
Contestualmente all’upgrade del sistema operativo e dell’ambiente di sviluppo si é
provveduto all’aggiornamento delle librerie utilizzate dal DAQ, dopo ovviamente
aver testato la funzionalitá di ogni singolo componente. In particolare sono state
adottate :
• omniORB dalla versione 3.0.4 alla 4.0.3
• OSE dalla versione 6.0 alla 7.0pl9
• Frame Library dalla versione 4r31 alla 6r15
• FFTW dalla versione 2.1.3 alla 3.0.1
• NI-VXI dalla versione 1.6.2 alla 2.0.1
L’aggiornamento di alcune delle librerie citate ha permesso l’implementazione
di nuove funzionalitá, in particolare la versione 4.x di omniORB aggiunge una
varietá di opzioni non disponibili in precedenza; tra le piú interessanti vi é la
possbilitá di configurare la gestione delle comunicazioni di rete, permettendo di
impostare timeout ed altri parametri che inglobano la gestione degli errori di
comunicazione. L’adozione di FFTW nella release 3 ha permesso di sfruttare le
architetture SMP e quindi di scalare il tempo di esecuzione delle DFT; infine
l’uso della versione aggiornata del driver NI-VXI ha permesso l’aggiornamento
del sistema operativo utilizzato dal DAQ.
64
Capitolo 5
Calibrazione e Diagnostica del
Sistema
Il tipo di segnale fornito dal rivelatore AURIGA necessita del trattamento piú
accurato possibile per evitare l’introduzione di rumore aggiuntivo che puó rendere maggiormente complessa la rivelazione del segnale gravitazionale o, vista la
debolezza, mascherarlo. Per questa ragione, assieme alle problematiche di sincronizzazione introdotte nei capitoli precedenti, si impone al DAQ di porre in
opera tutte le azioni necessarie al raggiungimento di una acquisizione ottimale,
introducendo le minime distorsioni di ampiezza e fase possibile, utilizzando efficacemente la dinamica di cui dispone e misurando i ritardi che esso introduce per
poter procedere, a posteriori, alla loro eliminazione.
Nel sistema di acquisizione di AURIGA la procedura di configurazione era
affidata all’utente che, in base alla propria esperienza ed eventualmente a misure
di prova, doveva provvedere ad impostare i parametri delle schede di acquisizione
per ottenere la migliori risoluzione del segnale. Mancava al sistema la possibilitá
di correggere il livello di offset in dc del segnale e stimare le latenze introdotte
nella sincronizzazione dei dati.
In seguito a queste richieste, successivamente all’aggiornamento del DAQ, si é
provveduto a realizzare un’applicazione in grado di configurare automaticamente
la strumentazione valutando la dinamica e l’offset del segnale di ingresso. Inoltre
é stata automatizzata la stima della latenza dell’interrupt, permettendo all’utente l’utilizzo di un singolo applicativo per la calibrazione dei tre sistemi DAQ e
fornendo la possibilitá di impostare l’accuratezza con cui effettuarla.
Nel presente capitolo viene descritta la calibrazione del sistema, le problematiche che solleva e le soluzioni che sono state adottate per l’implementazione di
”DAQ Calibration”, il tool che automatizza il processo di calibrazione.
Successivamente viene affrontato il problema della diagnostica del DAQ, necessaria per ottenere i requisiti di resilienza richiesti, presentando le soluzioni che
sono state implementate e discutendone i benefici.
65
Capitolo 5. Calibrazione e Diagnostica del Sistema
5.1
Latenza delle Interruzioni
Per rispettare i requisiti di sincronizzazione con il tempo universale UTC, é indispensabile poter conoscere il ritardo di generazione e di propagazione dei segnali
introdotto dall’elettronica degli strumenti utilizzati.
La sincronizzazione dei dati acquisiti con il tempo universale avviene grazie
all’utilizzo delle interruzioni. Considerando l’ADC usato per acquisire il canale
principale (Agilent E1430), la tecnica di sincronizzazione é quella descritta nella
Sezione 3.4: la linea di interruzione del bus VXI viene estratta dal crate mediante
una scheda custom e inviata alla scheda S80 del ricevitore satellitare ESAT GPS
100 (Sez.3.3). Come descritto nel Capitolo 3, con tale modalitá di funzionamento
il sistema di acquisizione effettua la datazione dei frame acquisiti.
I requisiti per il DAQ dell’esperimento AURIGA richiedono che l’errore commesso nella sincronizzazione sia dell’ordine di 1µs o inferiore e quindi, affinché
questo sia rispettato, diventa essenziale conoscere i ritardi introdotti dall’elettronica che deve generare e trasmettere il segnale di interruzione.
La determinazione della latenza dell’interrupt, intesa come somma di tutti
i possibili contributi, avviene misurando direttamente lo sfasamento. Il segnale di interruzione proveniente dal bus VXI viene riportato all’ingresso dell’ADC
E1430 che lo acquisisce, ottenendo quindi - all’inizio di ogni buffer - il segnale di
interruzione relativo alla fine del buffer precedente. L’interruzione viene filtrata
dall’ADC prima e dopo il campionamento per cui, una volta acquisita, perde la
forma di onda quadra posseduta inizialmente e presenta un andamento distorto
dovuto alla sua banda che é molto maggiore della frequenza di campionamento utilizzata per l’acquisizione. Dai buffer acquisiti si puó calcolare il ritardo
utilizzando un algoritmo di signal matching [18] che provvede al confronto dell’interruzione acquisita con un segnale della stessa forma costruito via software.
Affinché l’algoritmo svolga efficacemente il suo compito, é necessario che il segnale generato via software, con cui avviene il confronto, sia nella forma uguale
all’interruzione e quindi deve essere filtrato con le stesse modalitá. É quindi necessario conoscere e implementare i filtri presenti all’ingresso dell’unitá Agilent
E1430 (vedi Sezione 3.4).
5.1.1
Il Filtro Analogico
Lo schema di acquisizione utilizzato dall’ADC Agilent E1430 é riportato in Figura 3.2, dove si nota la presenza di due filtri, uno precedente e uno successivo la
conversione analogico/digitale. Il primo filtro, a monte dell’ADC, é un dispositivo
analogico sempre presente la cui funzione di trasferimento puó essere selezionata
programmando i registri della scheda. Lo scopo di questo dispositivo é l’eliminazione dell’errore di aliasing e quindi la forma del filtro varia a seconda che nel
setup dell’acquisitore venga attivato o meno. In particolare, quando l’antialiasing
viene disattivato, la risposta in frequenza del filtro analogico risulta :
66
5.1. Latenza delle Interruzioni
1
H(f ) =
s Q2
(1 − c0 ) n=1 [(1 −
s
)(a
cn
−
s
)]
∗
c
n
,
(5.1)
s=j2πf
dove i coefficienti cn , corrispondenti ai poli della funzione, sono riportati in
Tabella 5.1.
n
0
1
2
cn
2π
20 MHz
40 + j52 MHz
50 + j120 MHz
Tabella 5.1: Coefficienti della risposta in frequenza.
In Figura 5.1 sono rappresentati rispettivamente il modulo e la fase della
risposta in frequenza del filtro. Si noti come, con il filtro antialiasing disattivato,
l’attenuazione e il ritardo introdotti, per segnali nella banda di interesse per
AURIGA, sono sostanzialmente nulli.
(a) Modulo
(b) Fase
Figura 5.1: Risposta in frequenza del filtro analogico in ingresso
all’ADC Agilent E1430, con antialiasing disattivato
Se lo strumento viene impostato per rimuovere l’aliasing, la risposta in frequenza del filtro presente all’ingresso dell’acquisitore diviene:
H(f ) =
Q5
(1 −
s
s
n=1 [(1 − an )(1 − a∗n )]
s Q5
s
s
)
[(1
−
)(1
−
)]
n=1
b0
bn
b∗n ,
s=j2πf
dove in questo caso, i coefficienti an e bn sono riportati in Tabella 5.2.
67
(5.2)
Capitolo 5. Calibrazione e Diagnostica del Sistema
n
0
1
2
3
4
5
an
j3.4904432 · 107
j3.7024164 · 107
j4.2617433 · 107
j5.6601087 · 107
j1.0424240 · 107
bn
−8.2909964 · 106
−7.5372809 · 106 + j9.0528495 · 106
−5.7386094 · 106 + j1.6425689 · 107
−3.7379055 · 106 + j2.1470763 · 107
−2.0233064 · 106 + j2.4424917 · 107
−6.3191539 · 105 + j2.5754323 · 107
Tabella 5.2: Coefficienti della risposta in frequenza.
In Figura 5.2 viene riportato l’andamento di modulo e fase della risposta in
frequenza del filtro. A differenza della condizione precedente, si nota come, con
il filtro antialiasing attivato, il dispositivo si comporta come un buon passa-basso
nella banda utile per l’acquisitore, introducendo inoltre uno sfasamento ridotto; il
comportamento oscillatorio della fase all’estremitá del grafico é poco significativo
per l’acquisizione dato che, in quella zona, si é giá oltre la massima frequenza di
campionamento dell’ADC.
(a) Modulo
(b) Fase
Figura 5.2: Risposta in frequenza del filtro analogico in ingresso
all’ADC Agilent E1430, con antialiasing attivato
Le frequenze di campionamento usate nell’esperimento AURIGA sono ridotte
rispetto alle capacitá dell’ADC. Tipicamente il segnale proveniente dal rivelatore
viene campionato a circa 5KHz, prevedendo comunque la possibilitá di aumentare
tale valore fino a 10KHz o 20KHz, a fronte di un ADC in grado di raggiungere i
10MSa.
Nella banda utilizzata per l’acquisizione, quindi, l’apporto del filtro analogico
antialiasing alla distorsione del segnale é praticamente nullo. Come si vedrá in
68
5.1. Latenza delle Interruzioni
seguito, anche un segnale ad alta frequenza come l’interruzione del bus VXI viene
solo leggermente alterato nella forma.
5.1.2
Il Filtro Digitale
Dopo essere stato trattato dal filtro antialiasing, il segnale viene convertito in digitale dall’ADC a 23 bit presente nella scheda Agilent E1430. Il campionamento
avviene a 10MHz; la decimazione dei dati per ottenere la frequenza di campionamento impostata avviene in un momento successivo, ad opera del DSP posto
all’uscita dell’ADC, che implementa un filtraggio digitale.
La risposta in frequenza del filtro digitale é data da:
HN
f − f0
fc
!


1
=  QN z 3 +2z 2 +2z+2 5 n=1
4z 3 +2z
z=e
se N = 0
j2n π
f −f0
fc
se N > 0
(5.3)
dove i parametri f0 e fc sono rispettivamente la frequenza attorno alla quale
é stata centrata l’acquisizione (zoom frequency) e la frequenza di campionamento
(10MHz nel sistema usato per AURIGA). Il parametro N é il selettore di banda,
cioé il valore impostato nel registro dello strumento che indica al DSP quante
volte deve essere decimato il segnale (vedi Sezione 3.4) e quindi la frequenza di
campionamento finale voluta.
(a) Modulo
(b) Fase
Figura 5.3: Risposta in frequenza del DSP alla frequenza di
campionamento finale di 4882.8125 Hz
In Figura 5.3 sono stati riportati anche per questo filtro il modulo e la fase
della risposta in frequenza. Si noti come il modulo approssimi un passa-basso
andando ad eliminare le componenti del segnale in ingresso oltre le frequenze
69
Capitolo 5. Calibrazione e Diagnostica del Sistema
richieste dalla configurazione dello strumento (circa 2441Hz nella configurazione corrispondente alla Figura 5.3); lo sfasamento invece rimane contenuto entro
le prime due decadi, dopodiché aumenta giungendo ad incidere marcatamente
verso la fine della banda utile. Com’era ovvio, nella cascata dei due filtri, il maggior contributo alla deformazione del segnale avviene ad opera del DSP, la cui
implementazione di conseguenza richiede la maggiore accuratezzza possibile.
5.1.3
Stima della Latenza
La stima della latenza delle interruzioni sollevate dall’ADC Agilent E1430 avviene
collegando la linea di interruzione del bus VXI da esso impiegata all’ingresso
dell’ADC; in questa configurazione in ogni buffer viene acquisito il segnale di
interruzione relativo alla fine del buffer precedenete, come del resto giá indicato.
Figura 5.4: Segnale di interruzione (in logica positiva). In ascissa
viene riportata la posizione del campione relativamente all’inizio
del buffer che ha una durata di circa 3.355s e viene campionato
alla frequenza di 10MHz.
Per applicare efficacemente l’algoritmo di signal matching deve essere generato, via software, un segnale con le medesime caratteristiche dell’interruzione.
Questo é costituito da un impulso rettangolare molto stretto (vedi Figura 5.4) che
deve venir filtrato per ottenere la medesima forma del segnale acquisito dall’ADC
con cui verrá confrontato.
Allo scopo sono state implementate due classi, AnalogFilter e DigitalFilter,
che implementano rispettivamente il filtro analogico e il filtro digitale utilizzati nell’ADC Agilent E1430, realizzando tutte le caratteristiche disponibile nel
convertitore.
Nell’effettuare la stima delle latenze quindi, il primo passo consiste nell’applicare il filtro analogico al segnale di interruzione da utilizzare per il confron70
5.1. Latenza delle Interruzioni
to. In Figura 5.5 é riportato il segnale di interruzione dopo essere stato filtrato
con AnalogFilter; si vede, come anticipato, che il filtro analogico provoca una
distorsione minima del segnale, nonostante la sua banda.
Figura 5.5: Segnale di interruzione filtrato da AnalogFilter. In
ascissa viene riportata la posizione del campione relativamente
all’inizio del buffer che ha una durata di circa 3.355s e viene
campionato alla frequenza di 10MHz.
Il segnale cosı́ ottenuto va successivamente filtrato mediante DigitalFilter,
con impostato il selettore di frequenza utilizzato nell’acquisizione (N=11). Il
risultato del filtraggio digitale in questo caso é molto diverso dal segnale originario
dato che, oltre tutto, questo viene decimato 11 volte fino al raggiungimento della
frequenza di campionamento che é stata impostata per l’acquisizione. L’impulso
corrispondente ad un’interruzione in uscita al DSP e quindi dopo la cascata dei
due filtri ha la forma riportata in Figura 5.6.
Ottenuto finalmente l’omologo del segnale acquisito puó avere inizio l’algoritmo di signal matching che calcola la convoluzione
c(t) = f ∗ g(t) =
Z
T
f (τ )g(t − τ )dτ ,
(5.4)
dove con f (t) e g(t) vengono indicati rispettivamente il segnale acquisito e
quello generato via software; l’intervallo di integrazione T é costituito da un
singolo buffer. Il valore della latenza dell’interrupt per un buffer corrisponde al
tempo t0 in cui il valore della convoluzione é massimo. In altre parole l’algoritmo
di signal matching ricerca il ritardo da applicare al segnale generato via software
per massimizzare l’area della curva prodotto tra f (t) e g(t).
Operando su segnali discreti, la traslazione di g(t) ha un quanto temporale
pari al periodo di campionamento, permettendo quindi una granularitá di circa
204.8µs, troppo elevata per gli scopi della calibrazione. Una ricerca piú fine del
71
Capitolo 5. Calibrazione e Diagnostica del Sistema
Figura 5.6: Segnale di interruzione filtrato DigitalFilter. In
ascissa viene riportata la posizione del campione relativamente
all’inizio del buffer che ha una durata di circa 3.355s e viene
campionato alla frequenza di 4882.8215Hz.
massimo si puó articolare in due passi: un primo in cui, spostandosi di valori multipli del periodo di campionamento, si trovano i due campioni tra i quali
si verifica il massimo e un secondo nel quale, interpolata la convoluzione tra i
campioni trovati, si intensifica la ricerca utilizzando un passo inferiore. La parte piú delicata di questo processo é l’interpolazione, infatti con questo metodo
é possibile ottenere risultati con una precisione arbitraria a patto peró di aver
utilizzato la corretta tecnica di interpolazione, in mancanza della quale la diminuzione della granularitá puó rivelarsi inefficace. All’aumentare della complessitá
dell’interpolazione inoltre cresce il numero di punti necessari ad accrescerne la
precisione e quindi l’algoritmo diviene piú dispendioso in termini di tempo di
calcolo, rimanendo comunque limitato dalla forma del fit adottata.
La soluzione scelta per il tool “DAQ Calibration” permette di ottenere deterministicamente la precisione richiesta eliminando il problema dell’interpolazione.
In esso, dopo aver effettuato la convoluzione tra i due segnali {Cn }, si procede
al trattamento del risultato con un filtro interpolatore dato da [18]
Sk =
N
X
n=1
Cn
sin[π( FFC0 k − n)]
C
π( FFC0 k
C
− n)
U≡
FC
FC0
(5.5)
dove Sk é il segnale interpolato alla frequenza di campionamento FC0 , FC é la
frequenza di campionamento originale e U é il rapporto di “up-conversione”; gli
estremi della sommatoria sono dati dalla dimensione del buffer di partenza. Con
questa modalitá di operare é possibile ottenere la precisione richiesta dall’utente
semplicemente impostando il rapporto FC /FC0 . L’algoritmo di signal matching
72
5.2. Ampiezza e Offset
poi, eseguendo la ricerca del massimo su Sk , nel nuovo dominio, fornisce la latenza
dell’interruzione secondo i requisiti.
5.2
Ampiezza e Offset
La calibrazione del sistema richiede, oltre alla stima dei ritardi, l’uso efficiente
della dinamica dell’ADC. La scheda Agilent E1430 prevede l’utilizzo di diversi
valori di fondo scala, da ±8V a ±7.8125mV , tra i quali l’utente deve scegliere
prima di avviare l’acquisizione. Infatti, sebbene la provenienza del segnale da
acquisire non cambi, la sua ampiezza massima puó variare in seguito al setup dello
SQUID o altri parametri, ragione per cui, l’utente deve di volta in volta scegliere il
miglio setup dell’ADC. Dalla configurazione dello SQUID inoltre non é possibile
conoscere a priori l’ampiezza del segnale in uscita con la sufficiente precisione,
per cui l’utente é spesso costretto ad iniziare un’acquisizione per verificare che i
parametri scelti siano adeguati ai livelli del segnali.
Per queste ragioni si é scelto di automatizzare il processo di selezione del fondo
scala integrandolo nel tool “DAQ Calibrator”, permettendo quindi, attraverso una
misurazione preventiva, di impostare il fondo scala adeguato prima dell’inizio
dell’acquisizione. Attraverso una serie di opzioni impostabili dall’utente (vedi
Sezione 5.3) inoltre, questo puó selezionare quale scarto utilizzare rispetto al
segnale presente all’ingresso e con che precisione realizzare la misura.
Un alto parametro importante per l’acquisizione é l’offset del segnale presente
all’ingresso dell’ADC. Puó capitare infatti che l’elettronica utilizzata per il trattamento del segnale introduca un offset del livello dc o che sia lo stesso ADC a
provocare lo scostamento. Questo, sebbene piccolo, puó diminuire la dinamica
del sistema sia perché impedisce di sfruttare correttamente l’intervallo di tensioni
rappresentabili sia perché un segnale fuori massa puó causare delle interferenze
nell’acquisizione: gli accoppiamenti tra il canale principale del DAQ e le linee di
interruzione del bus VXI presentati nella Sezione 4.2.1 ne sono un esempio.
Per queste ragioni la scheda Agilent E1430 prevede la possibilitá di ridurre
l’offset del segnale in ingresso attraverso la programmazione del registro Input
Offset (indirizzo 816 ). Nel tool di calibrazione é stata quindi integrata la possibilitá di ridurre l’offset, come nel caso del fondo scala, attraverso una breve
acquisizione di test. Questa puó essere realizzata con l’ingresso in corto circuito,
possibilitá fornita dalla scheda E1430 per annullare l’offset da essa introdotto, oppure utilizzando il segnale proveniente dal rivelatore e quindi abbattendo l’offset
introdotto da tutta l’elettronica della catena di acquisizione.
5.3
DAQ Calibration
Il tool “DAQ Calibration” si occupa della calibrazione del canale principale utilizzando le soluzioni descritte nelle precedenti sezioni. L’implementazione é avvenuta utilizzando il framework QT 3.3.3, particolarmente l’intera costruzione
73
Capitolo 5. Calibrazione e Diagnostica del Sistema
dell’interfaccia - assieme alla scrittura di tutto il codice interno all’applicativo é stata sviluppata utilizzando il QT Designer 3.3.3 di Trolltech.
Figura 5.7: Finestra principale di “DAQ Calibrator”.
All’avvio il programma si presenta come in Figura 5.7, con una finestra divisa
in 4 sezioni principali:
Configurazione Iniziale: La parte superiore sinistra della finestra é occupata
dall’impostazione corrente dell’ADC. I parametri visualizzati corrispondono
al setup dell’ultima acquisizione e vengono automaticamente letti dal file di
configurazione dell’ADC all’avvio del programma.
Tipo di Calibrazione: La parte superiore destra invece contiene le impostazioni sull’esecuzione del tool, in particolare con questi controlli l’utente puó
selezionare quale tipo di calibrazione effettuare e con che precisione.
Tempo Stimato: Nel riquadro inferiore sinistro si trovano le informazioni sulla
durata dell’acquisizione necessaria alla calibrazione richiesta. In particolare
vengono calcolati il numero di campioni e quindi il tempo necessario affinché
vengano svolti tutti i test richiesti con la precisione impostata.
Comandi: L’ultimo riquadro in basso a destra raccoglie i pulsanti di controllo
che permettono di lanciare la calibrazione, salvarne il risultato o terminare
l’esecuzione del programma.
I parametri relativi al setup dell’ADC possono essere modificati a discrezione
dell’utente, nel qual caso le successive verifiche di calibrazione da essi dipendenti
verranno effettuate nella nuova configurazione.
74
5.3. DAQ Calibration
Figura 5.8:
Calibrator”.
Sequenza di calibrazione utilizzata da “DAQ
La sequenza di calibrazione ottimale é riportata in Figura 5.8 ed é la stessa
adottata da “DAQ Calibration”. L’abbattimento dell’offset infatti viene eseguito prima della determinazione del fondo scala, altrimenti quest’ultimo verrebbe
stimato su di un segnale asimmetrico rispetto allo zero; la configurazione dello
strumento per sfruttare pienamente la dinamica (fondo scala e offset) infine é condizione necessaria per ottenere la massima precisione nella conversione e quindi la
stima della latenza delle interruzioni viene effettuata come ultimo passo, quando
lo strumento é calibrato in ampiezza.
A discrezione dell’utente alcune fasi possono essere omesse deselezionandole
nel riquadro superiore destro della finestra principale di “DAQ Calibration”. Le
fasi non selezionate vengono escluse dalla sequenza di calibrazione supponendo
che per quei particolari aspetti la configurazione corrente oppure quella fornita
in modo manuale dall’utente sia ottimale.
Impostati tutti i parametri desiderati si puó dare inizio alla calibrazione premendo il tasto Calibrate. Il primo passo, costituito dalla riduzione dell’offset,
consiste nella semplice acquisizione di
√ un numero di pacchetti dipendente dalla
precisione richiesta (precisione ∼ 1/ numero campioni) seguito dal calcolo del
valore medio del segnale che determina l’offset. Questo viene salvato in una struttura di configurazione (AntCfg) che verrá successivamente caricata dal processo
ANT, il quale lo utilizza per impostare il registro Input Offset. Interessante
é la possibilitá di eseguire l’abbattimento dell’offset con un segnale di ingresso.
Normalmente l’elettronica che tratta il segnale non dovrebbe introdurre alcuno scostamento rispetto alla massa, anzi, spesso il trovarne uno é sintomo di
malfunzionamento, tuttavia la calibrazione dell’offset pué essere effettuata anche basandosi sul segnale di ingresso, riportando in massa un eventuale segnale
disturbato dalla strumentazione.
Ridotto l’offset il tool esegue la calibrazione del fondo scala (Figura 5.9(a))
che consiste nell’acquisizione di un numero di pacchetti definito dall’utente dai
cui dati viene ricavata una media quadratica (RMS per la precisione). Il valore
determinato, moltiplicato per la fattore impostabile dall’operatore, viene utilizzato come fondo scala e salvato nella struttura di configurazione dello strumento
AntCfg per essere successivamente utilizzato
Ultimo passo consiste nella determinazione della latenza delle interruzioni
(Figura 5.9(b)) che si articola in tre punti:
• Generazione e filtraggio del segnale di interruzione da utilizzare per il confronto
75
Capitolo 5. Calibrazione e Diagnostica del Sistema
• Acquisizione di un numero di buffer (e quindi di interruzioni) impostabile
dell’utente
• Determinazione per ogni buffer della latenza dell’interruzione e successiva
media dei valori ricavati.
(a) Calibrazione del Fondo Scala
(b) Stima della latenza delle interruzioni
Figura 5.9: Screenshoots del tool “DAQ Calibration” durante il
suo utilizzo
Il tool di calibrazione é completato da un insieme di opzioni - a cui si puó
accedere mediante il menú Options → Program Options (CTRL+O) - che lo
rendono versatile, permettendo di adattarsi ad eventuali variazioni nel setup dell’esperimento. La prima finestra che compare richiamando le opzioni é presentata
in Figura 5.10(a). In essa é possibile impostare i parametri relativi alla determinazione del fondo scale, precisamente quanti pacchetti devono essere utilizzati
per la calibrazione e il fattore da moltiplicare per l’RMS trovato. Trovano spazio
nella medesima finestra anche il numero di pacchetti da acquisire per la stima
della latenza dell’interrupt e la precisione con cui deve essere effettuata (periodo
di campionamento del segnale interpolato). La presenza dei parametri “numero
di pacchetti per” relativamente al fondo scala e alle interruzioni é dovuta alla
relazione tra precisione e quantitá di dati da acquisire. Essendo la dipendenza
quadratica infatti, l’impostazione di una precisione troppo spinta porta alla necessitá di acquisire un numero molto elevato di campioni, particolarmente nel caso
delle interruzioni dove é presente un solo segnale utile per buffer. Ad esempio,
per ottenere una precisione pari 10% nella stima dei ritardi é necessario acquisire
ben 100 buffer che si traducono, lasciando inalterata la configurazione dell’ADC
rispetto al normale modo di operare, in piú di 5 minuti di acquisizione. Si é scelto
quindi di utilizzare la precisione presente nella schermata principale per il calcolo
dei pacchetti da acquisire per la sola calibrazione dell’offset, mentre viene data
all’utente la possiblitá di impostare manualmente la durata delle acquisizioni per
gli altri tipi di calibrazione.
76
5.4. Risultati
(a) Opzioni relative alla calibrazione
(b) Opzioni del programma
(c) Opzioni relative al segnale di interruzione generato via
software
Figura 5.10: Opzioni del tool “DAQ Calibration”
In Figura 5.10(b) sono mostrate le opzioni relative al funzionamento del programma tra le quali viene data la possibilitá all’utente di modificare la sequenza
di calibrazione.
L’ultima finestra, mostrata in Figura 5.10(c), presenta le opzioni relative al
segnale di interruzione che viene generato per il confronto. In essa l’operatore é
libero di modificare i parametri significativi per il segnale presentato in Figura
5.4, particolarmente il numero di campioni da utilizzare per la rappresentazione
iniziale dell’interruzione, la sua durata e il ritardo rispetto all’inizio del buffer1 .
Sempre a livello di sperimentazione é stata fornita la possibilitá di variare i livelli di tensione utilizzati da segnale anche se, nel calcolo della convoluzione,
cambiamenti a questi parametri risultano essere poco significativi.
5.4
Risultati
A conclusione del capitolo vengono presentati i risultati ottenuti dall’utilizzo delle
tecniche descritte e del tool che le implementa.
Il compito piú semplice della calibrazione é la determinazione del fondo scala
1
Il filtraggio presentato nella Sezione 5.1.3 viene eseguito su di un singolo buffer e quindi,
spostando il segnale verso le sue estremitá possono venir eseguiti dei troncamenti. La possibilitá
di impostare il ritardo rispetto all’inizio del buffer viene data appunto per poter sperimentare
la migliore configurazione
77
Capitolo 5. Calibrazione e Diagnostica del Sistema
da utilizzare per l’acquisizione. Questa, variando il parametro “Numero di pacchetti da acquisire”, puó essere ottenuta con precisione arbitraria, a discrezione
dell’operatore.
Anche per l’abbattimento dell’offset é possibile impostare la precisione - nella
finestra principale - con cui si vuole ottenere il risultato ed automaticamente
ottenere un’acquisizione della durata necessaria2 . Il valore ricavato da “DAQ
Calibration” viene poi utilizzato dal processo ANT per l’impostazione del registro
Input Offset, ottenendo da parte dell’ADC l’introduzione di una tensione DC
secondo la relazione
Offset =
V
2
N
−1 ,
211
(5.6)
dove V é lo Scale Factor per il fondo scala scelto e N é costituito dai 12 bit meno
significativi del registro Input Offset. Sebbene la stima dell’offset sia ottenibile
con una precisione arbitraria, in definitiva la precisione con cui puó essere variato
dipende dall’ADC, essendo questo ottenuto come multiplo di V /212 . Utilizzando
ad esempio il fondo scala di ±0.25V come presentato nei vari screenshot, si ha
che il valore dello scale factor é pari a V = 0.576794 e quindi la minima quantitá
con cui puó essere impostato l’offset é pari a 0.576794/212 ' 141µV .
Figura 5.11: Stima della latenza delle interruzioni: risultato della
calibrazione.
Per la stima delle latenze introdotte dall’elettronica infine, il valore determinato viene memorizzato nella struttura AntCfg per essere successivamente utilizzato
dal software di analisi, la precisione con cui si puó ottenere la stima quindi é li2
Il calcolo viene effettuato per eccesso dato che l’acquisizione consiste in un numero intero
di buffer di dimensione pari a 16 KSa
78
5.5. Diagnostica del Sistema
mitata solamente dalla rappresentazione numerica adottata e dal tempo che si
vuole impiegare per la sua esecuzione.
In Figura 5.11, a titolo di esempio, é riportata la stima dei ritardi introdotti
dal nuovo DAQ, realizzata con un’acquisizione di 100 buffer e quindi con una
precisione di circa il 10%. Il valore trovato per i ritardi e all’incirca 1102µs come
confermato dalle misurazioni manuali che erano state effettuate in precedenza.
Con il numero di buffer impostato si ottiene inoltre una deviazione standard di
circa 173ns che deve essere considerata nel computo dell’errore che viene commesso - complessivamente - nella sincronizzazione con il tempo universale. Quest’ultimo puó essere maggiorato3 dalla somma degli errori di sincronizzazione e
quindi, aggiungendo alla stima dei ritardi l’errore di temporizzazione del ricevitore satellitare pari a 70ns, si ottiene complessivamente un errore di circa 250ns,
perfettamente compatibile con i requisiti dell’esperimento che fissano il massimo
errore ad un µs.
5.5
Diagnostica del Sistema
Il rivelatore AURIGA, facendo parte di un osservatorio di onde gravitazionali,
richiede che l’acquisizione possa essere mantenuta operativa per intervalli di tempo molto lunghi, dell’ordine di mesi, assicurando una buona stabilitá di tutti i
parametri del sistema. Come indicato nei capitoli precedenti, la necessitá di ottenere la massima resilienza del DAQ ne ha condizionato le scelte sia hardware che
software. In un sistema di elaborazione tuttavia é sempre possibile che si verifichi
un qualche tipo di problema come un malfunzionamento hardware oppure una
qualche anomalia in un processo esterno al DAQ, ad esempio il sistema operativo.
Per queste ragioni é indispensabile, dopo aver implementato quanto possibile per
garantire il buon funzionamento del sistema, integrare il DAQ con qualche metodologia di controllo che permetta di riscontrare un malfunzionamento nel minor
tempo possibile e faciliti il riconoscimento della causa che l’ha provocato.
Dalla precedente versione del DAQ é stato previsto un apposito processo
(LOG) che si occupa della registrazione di tutti i messaggi di errore generati
dal software componente il sistema di acquisizione, assieme ad un indice di gravitá ad essi associato. L’interfaccia grafica (GUI) inoltre prevede la possibilitá
di generare degli allarmi sonori in seguito alla cattura, da parte del logger, di un
errore con un indice di gravitá superiore ad una soglia stabilita dall’utente.
Questo sistema di diagnostica, sebbene utilizzato molto diffusamente nel settore informatico per il controllo del funzionamento del software, non si é rivelato
del tutto sufficiente alle richieste di AURIGA. In particolare gli aspetti rilevati
come maggiormente carenti e che hanno suggerito lo sviluppo di nuovi strumenti
sono
• L’affidare ad un processo del DAQ il controllo del funzionamento del sistema
3
La maggiorazione ottenuta come somma degli errori é imposta dall’assenza di errori con
distribuzione gaussiana
79
Capitolo 5. Calibrazione e Diagnostica del Sistema
stesso. In questa modalitá infatti, il logger puó svolgere il suo computo fintanto che il sistema di acquisizione rimane operativo. Nel caso di un blocco
del computer o dei processi costituenti il DAQ il logger non puó funzionare
e quindi si perde la possibilitá di intercettare il malfunzionamento.
• La diagnostica, come implementata dal processo LOG, é limitata al solo
controllo del software. Non vi é alcuno strumento che verifica la bontá dei
dati acquisiti.
Per queste ragioni si é deciso di aggiornare il software di diagnostica, affiancando al logger altri strumenti che ne completano le funzionalitá. Sono state
quindi sviluppate due soluzioni indipendenti che permettono la diagnostica del
sistema sia off-line che on-line.
5.6
Diagnostica Off-Line
Con diagnostica off-line va inteso il processo di verifica, da parte del software
di analisi o di altri tool appositamente progettati, della bontá dei dati acquisiti,
permettendo di controllare a posteriori il comportamento dell’intera catena di
acquisizione.
Figura 5.12: Schema readout del rivelatore AURIGA dove sono evidenziati barra, trasduttore, circuito risonante elettrico e
amplificatore SQUID
In Figura 5.12 é rappresentato il readout utilizzato nel rivelatore AURIGA.
Il segnale in uscita dal trasduttore capacitivo viene inviato all’induttanza superconduttiva LP che é accoppiata all’ingresso dell’amplificatore SQUID mediante il
circuito costituito da LS e LSQ . In questa maglia é stata introdotta un’ulteriore
induttanza che permette, mediante Mcal , di iniettare un segnale all’ingresso dello
SQUID.
La diagnostica off-line é in grado di sfruttare il readout del rivelatore per
verificare continuamente il comportamento della catena di acquisizione. Con
una periodicitá prestabilita, viene posto all’ingresso dello SQUID un segnale che,
amplificato, viene acquisito dal DAQ al pari dell’uscita del trasduttore; in seguito
il software di analisi puó controllare i parametri relativi alla catena di trasduzione
80
5.7. Diagnostica On-Line
e puó inoltre verificare se il sistema é rimasto in condizioni di linearitá per tutta
la durata del RUN evidenziando eventuali saturazioni dell’elettronica. L’unico
requisito affinché la diagnostica funzioni é la conoscenza dell’esatto istante di
tempo in cui il segnale é stato iniettato.
La precisione della temporizzazione viene realizzata utilizzando un generatore
di funzione il cui clock é fornito dal ricevitore satellitare, ottenendo in questo
modo la stessa precisione del DAQ. La generazione del segnale di test avviene in
seguito alla ricezione, da parte del generatore, di un numero impostabile di fronti
di salita del PPS, mantenendo quindi i requisiti di sincronizzazione. A tempi
regolari tk stabiliti dall’operatore (ad esempio ogni ora), il generatore comanda
l’invio di un segnale impulsivo di tipo sine-gaussian
x(t) = A sin(ω0 (t − tk ))e−
(t−tk )2
2∆2
,
(5.7)
dove ∆ é la durata dell’impulso e ω0 é la sua frequenza centrale, che viene
amplificato dallo SQUID e acquisito dal DAQ.
Per ottenere le informazioni sul tempo di generazione del segnale si é scelto
di utilizzare una delle linee di ingresso alla scheda S80, con modalitá analoghe
alla temporizzazione degli ADC utilizzati nel sistema di acquisizione. La linea
che comanda l’invio del segnale quindi viene posta all’ingresso del ricevitore GPS
ottenendo in questo modo per ogni impulso prodotto il timestamp relativo al suo
inizio.
Sono inoltre stati modificati due processi del sistema di acquisizione per rendere possibile il trattamento corretto della informazioni di temporizzazione relative
agli impulsi di calibrazione. Nel processo GPS é stata aggiunta un’apposita coda
per la memorizzazione dei timestamp relativi alla generazione dei segnali sinegaussian. In questo modo GPS mantiene un elenco dei tempi di arrivo dei segnali
di test separato dalle code relative ad altri eventi e permette ad un processo
esterno di richiederli ordinatamente. Il processo BLD deve tener traccia nella
costruzione dei frame in formato IGWD dell’eventuale presenza di impulsi di calibrazione, per cui é stato modificato di conseguenza l’algoritmo di interrogazione
dei front-end. All’arrivo di un nuovo frame viene controllata la presenza di un
timestamp relativo al canale della scheda S80 connesso al generatore di impulsi
di calibrazione. In tal caso il frame viene marcato come contenente un impulso di
calibrazione utilizzando una struttura FrHistory all’interno della quale inoltre
ne viene memorizzato il tempo di invio.
5.7
Diagnostica On-Line
Dovendo mantenere operativa la presa dati per lunghi periodi senza alcuna interruzione, diventa estremamente importante poter diagnosticare in ogni momento
il sistema di acquisizione. Inoltre, dovendo confrontarsi con il mondo reale in
cui, nonostante l’accuratezza della progettazione, possono verificarsi malfunzionamenti (possibilmente esterni al sistema) che impediscono al DAQ il suo normale funzionamento, é essenziale che questi fallimenti vengano riscontrati nel
81
Capitolo 5. Calibrazione e Diagnostica del Sistema
minor tempo possibile onde massimizzare il duty-cycle dell’esperimento. Il sistema di diagnostica deve inoltre facilitare all’operatore il compito di riconoscere le
possibili cause che hanno portato al malfunzionamento.
La versione precedente del DAQ prevedeva il processo LOG come forma di
diagnostica on-line del sistema. Esso si occupa della raccolta e memorizzazione
dei messaggi di errore che ogni processo del DAQ puó generare. Tale tool si rivela
insufficiente per la diagnostica completa del sistema soprattutto perché fa parte
del sistema stesso e quindi, al verificarsi di situazioni di “crash”, non puó avvisare
l’utente dell’accaduto.
5.8
DAQ Control
Nella versione del DAQ oggetto di questa tesi, oltre al processo logger é stato
implementato un sistema di controllo remoto che, utilizzando CORBA per le
comunicazioni, provvede ad interrogare periodicamente i processi del DAQ e a
verificarne lo stato di funzionamento.
Il nuovo strumento ha inoltre permesso di aggiungere un ulteriore livello di resilienza nella diagnostica dei malfunzionamenti prevedendo la possibilitá di inviare
messaggi di avviso qualora si verifichi una qualche anomalia.
Lo sviluppo dell’applicativo si é articolato in due fasi, la prima delle quali é
stata utilizzata per il test del sistema di comunicazione realizzando una versione
‘ridotta della diagnostica. Tale verifica é imposta dalla necessitá di integrazione
con gli strumenti software utilizzati nei laboratori di AURIGA, particolarmente
il middleware omniORB la cui versione installata nei sistemi di calcolo é rimasta
quella del precedente sistema di acquisizione (2.3) mentre quella utilizzata dal
nuovo DAQ é la 4.0.3. Le differenze tra le due release sono importanti e l’integrazione completa della comunicazione tra i software che le utilizzano é tuttaltro
che semplice. In particolare nella versione 2.3 non esiste alcuna gestione degli errori di comunicazione, cosa invece implementata dettagliatamente nella versione
4, rendendo quindi obbligatorio per i client l’adozione delle strategie necessarie
alla gestione di problemi come la mancata risposta di un computer remoto (caso
particolarmente interessante dato che corrisponde alla situazione in cui si verifica
uno stallo del sistema di acquisizione).
La prima versione del sistema di diagnostica remota quindi é consistita nello
sviluppo di un tool - per vari aspetti monolitico - il cui compito constava nel
verificare lo stato di funzionamento dei processi del DAQ, effettuato mediante un
controllo sullo stato delle code associate ad ogni processo, e nell’implementazione
di un sistema di allarmi che entrava in funzione al verificarsi di un’anomalia. É
stato inoltre sviluppato uno strumento in grado di avvisare gli utenti via posta
elettronica del verificarsi di un qualche malfunzionamento.
Il banco di prova costituito dalla prima applicazione, oltre a costituire il test
delle strategie di controllo delle comunicazione implementate, ha stimolato le idee
che hanno portato alla versione attuale del sistema “DAQ Control”.
82
5.8. DAQ Control
5.8.1
Architettura del sistema
La molteplicitá delle operazioni indipendenti da svolgere assieme alla generalitá delle stesse ha suggerito l’adozione di un sistema OOP totalmente multithread, basato sull’astrazione fornita dalla libreria omniThread [22], componente
del pacchetto omniORB.
Figura 5.13: Schematizzazione dei principali oggetti implementati
nel tool DAQ Control, assieme alle relazioni tra essi intercorrenti. Le frecce non vanno intese secondo le specifiche UML ma
semplicemente come relazioni “di utilizzo”.
In Figura 4 5.13 sono stati rappresentati i principali oggetti che sono attualmente implementati nel controllo remoto.
Il nucleo delle funzionalitá di DAQ Control é realizzato dall’oggetto ctrlCore,
che implementa le operazioni di gestione dei controlli da effettuare. Al suo interno
é presente un vettore - thVector - che tiene traccia di tutti gli oggetti che implementano i singoli controlli del DAQ. ctrlCore implementa i metodi necessari alla
creazione ed eliminazione di nuovi processi di diagnostica, gestisce le operazioni
di avvio e shutdown di ogni controllo e permette di conoscere lo stato degli oggetti
istanziati, inteso sia come stato di funzionamento della proprietá controllata che
come stato in cui si trova l’oggetto controllante.
4
Lo stile grafico utilizzato é simile all’UML, tuttavia la rappresentazione ha un significato
diverso. Gli oggetti sono rappresentate assieme alle relazioni tra essi intercorrenti. Le frecce non
vanno intese secondo le specifiche di UML ma semplicemente come una relazione “di utilizzo”
83
Capitolo 5. Calibrazione e Diagnostica del Sistema
Ogni operazione di diagnostica viene implementata da un oggetto di tipo
ctrlThread, a cui viene associato, all’atto della creazione, un processo remoto
del DAQ con cui puó mettersi in comunicazione. Questa avviene secondo parametri impostabili dall’utente: creato l’oggetto é possibile indicare l’intervallo
da utilizzare fra le comunicazioni e il timeout oltre il quale una trasmissione
va considerata come fallita. ctrlThread mantiene inoltre al suo interno alcune utili informazioni ausiliarie come lo stato attuale del processo controllato, il
timestamp relativo alla creazione e all’ultimo avvio del processo di diagnostica;
al suo interno é inoltre contenuto il puntatore a ctrlMonitoringThread, generalizzazione del thread contenente il processo di diagnostica, ottenendo cosı́ il
preannunciato ambiente multi-thread in cui i processi istanziati sono liberi di
evolvere indipendentemente.
Il processo di diagnostica vero e proprio é affidato agli oggetti ctrlRunControl
e ctrlRunControlMonitor i quali implementano in due thread separati il controllo dello stato di un processo remoto. La necessitá di due thread distinti é data
dal bisogno di gestire gli errori di comunicazione nel caso si scelga di far girare
il tool con la libreria omniORB 2.3. Mancando in essa la possibilitá di gestire
i timeout di comunicazione si é optato per realizzare due thread sincronizzati
mediante un semaforo. Ad ogni ciclo di diagnostica ctrlRunControl invoca la
partenza di ctrlRunControlMonitor e successivamente si mette in attesa con un
timed wait su di un semaforo comune ai due oggetti. A ctrlRunControlMonitor
é affidata la comunicazione effettiva con il processo remoto; ad ogni avvio esso
richiede - mediante le librerie del processo DSC - lo stato della coda associata al processo che deve controllare. Se ottiene una qualche risposta archivia
il risultato e segnala il successo della comunicazione con il semaforo comune,
a questo punto ctrlRunControl si riattiva e verifica se il risultato ottenuto da
ctrlRunControlMonitor indica un corretto funzionamento del processo del DAQ.
Un eventuale errore di comunicazione viene gestito diversamente a seconda della
libreria omniORB installata nel sistema su cui viene eseguito DAQ Control. Se la
versione adottata é la 4, le comunicazioni possono essere gestite con un timeout
e quindi, nel caso di un blocco del sistema remoto, dopo il timeout impostato
l’invocazione del metodo remoto ha come risultato il sollevarsi di un’eccezione.
Se la versione in uso invece é la 2.3 il timeout viene ottenuto dal semaforo precedentemente citato; in questo caso ctrlRunControl dopo il valore impostato per il
timed wait, viene riattivato riscontrando l’assenza di una segnalazione da parte di
ctrlRunControlMonitor che viene interpretata come un errore di comunicazione.
Il tipo di diagnostica implementata dai due precedenti oggetti consiste nel
verificare la continuitá del funzionamento dell’acquisizione. Essi periodicamente
vanno a controllare lo stato delle code remote, inteso come numero di frame che
vi sono stati accodati, andando a segnalare una qualche anomalia se riscontrano
un blocco nella generazione di nuovi frame per un intervallo di tempo impostabile
dall’utente.
É stato previsto di realizzare online anche un controllo di linearitá della catena di acquisizione che tuttavia, allo stato attuale, non é ancora ultimato. La
struttura progettata rispecchia esattamente quella degli oggetti ctrlRunControl
84
5.8. DAQ Control
e ctrlRunControlMonitor in cui, nel secondo, vengono ricevuti i frame dalla
coda remota e viene effettuato il controllo di linearitá.
L’architettura OOP progettata permette di aggiungere ulteriori forme di diagnostica online semplicemente andando ad implementare gli ultimi oggetti descritti ossia l’omologo di ctrlRunControlMonitor che implementa la comunicazione
col processo remoto e l’omologo di ctrlRunControl che, dai valori forniti dalla
comunicazione, stabilisce lo stato di funzionamento del processo remoto.
Tutte le interazioni del sistema di diagnostica con il mondo esterno sono effettuate mediante i metodi forniti dall’interfaccia di ctrlCore. Per facilitarne l’utilizzo e permetterne un uso piú ampio é stata implementata una console virtuale
con l’oggetto ctrlConsole. Si tratta di un piccolo interprete per un linguaggio
molto semplice appositamente definito per il sistema di diagnostica; tale oggetto
puó interagire con ctrlCore con semplici comandi testuali. E’ possibile creare
a run-time un nuovo oggetto che effettua le diagnostiche previste, associarlo al
processo remoto, richiederne l’avvio, lo stop e lo stato attuale. L’utilizzo di un
interprete di comandi come quello implementato nella console permette inoltre la
possibilitá di creare script di configurazione con il medesimo linguaggio adottato
per la console, facilitando quindi la possibilitá di impostare la diagnostica in modo automatizzato. Il meccanismo adottato per la gestione dei flussi di ingresso
e di uscita inoltre, essendo realizzato con un sistema di callback, permette l’uso
dello stesso oggetto console in diversi ambiti, semplicemente al costo d’implementazione delle funzioni di ingresso e uscita. Con questa modalitá diviene possibile
realizzare una console remota dal comportamento identico a quella locale, inoltre
viene facilitata l’integrazione con altri software rendendo possibile, ad esempio,
operazioni come il comando di DAQ Control da una pagina WEB.
A completamento dell’applicativo sono stati realizzati altri oggetti che si occupano di verificare lo stato della diagnostica e di allertare gli utenti in caso di
errori. Nella Figura 5.13 é mostrato solo l’oggetto ctrlWatchDog, il piú semplice
della categoria. Esso, costituito da un thread a se stante, si occupa di controllare
periodicamente lo stato del sistema di diagnostica per verificare se qualcuno dei
thread di controllo ha riscontrato anomalie, nel qual caso l’utente viene allertato
mediante la console. É previsto un sistema analogo per la gestione degli avvisi
via posta elettronica, giá implementato nella prima versione di DAQ Control; sostanzialmente il comportamento é analogo a ctrlWatchDog ad eccezione del fatto
che la comunicazione avviene via posta elettronica e che, a seguito del riscontro
di una stessa anomalia, gli avvisi non vengono ripetuti.
5.8.2
Tipologie di diagnostica
Il tool DAQ Control é stato progettato con lo scopo di implementare solamente
due tipi di diagnostica online, tuttavia le scelte implementative sono state effettuate nell’ottica di poter aggiungere altri controlli in un momento successivo
con il minimo sforzo: in pratica si tratta di scrivere semplicemente gli oggetti
che gestiscono la comunicazione e il controllo dei dati ottenuti, cosa comunque
necessaria nel caso si implementino nuove operazioni.
85
Capitolo 5. Calibrazione e Diagnostica del Sistema
La diagnostica giá sviluppata prevede il controllo del funzionamento dei processi remoti. Ad ognuno di essi é associato uno stato della FSM (vedi 3.8) e una
coda di frame che utilizzano per realizzare la comunicazione con gli altri processi del DAQ. Nell’oggetto implementante la coda sono presenti due contatori
che tengono traccia rispettivamente del numero di frame che sono stati accodati
dall’avvio del sistema di acquisizione e del numero di frame che devono ancora
essere elaborati. Durante il normale funzionamento dei processi del DAQ deve
essere generato un nuovo frame con una frequenza dipendente dall’impostazione
del sistema. Gli oggetti di tipo runcontrol verificano lo stato di funzionamento dei
processi del DAQ basandosi sullo stato della FSM e sul numero di pacchetti accodati dall’inizio dell’acquisizione. Se dopo un periodo di tempo stabilito dall’utente
un processo del DAQ non genera nuovi dati segnalano un malfunzionamento che
genererá un avviso all’utente.
Oltre alla precedente é stata prevista l’implementazione del controllo di linearitá della catena di acquisizione, ottenibile introducendo nel sistema due sinusoidi ai margini della banda utile per non interferire con il segnale generato
dal rivelatore. Se le sinusoidi introdotte non aggiungono rumore (interferenze
elettromagnetiche) allora il controllo di linearitá in DAQ Control potrebbe essere
ottenuto filtrando i dati dalla coda del processo ANT con il metodo spyData. É
sufficiente infatti trattare il segnale acquisito con due filtri lock-in centrati sulle
frequenze delle sinusoidi introdotte per ottenere tutte le informazioni necessarie
a stabilire la linearitá di ampiezza e fase della catena di trasduzione, dal punto
di introduzione del segnale fino al sistema di acquisizione. Gli oggetti che implementano la diagnostica di linearitá provvedono al filtraggio del segnale acquisito
come descritto e successivamente controllano ampiezza e fase delle sinusoidi ricavate, qualora uno dei parametri superi l’intervallo ammesso per l’acquisizione
viene segnalato il malfunzionamento del sistema.
5.8.3
Interfacce
L’interazione di DAQ Control con l’utente viene fornita grazie all’oggetto ctrlConsole
che implementa un terminale testuale (Figura 5.14) in grado di interpretare un
semplice linguaggio, adatto per il sistema di diagnostica.
I comandi attualmente supportati, assieme alla loro sintassi, sono i seguenti:
NEW <NomeThread> <tipo> <PRC_da_controllare>
[<numero_di_code> <sleep_time> <timeout>]
DELETE <NomeThread>|<ThreadID>
START <NomeThread>|<ThreadID>
STOP <NomeThread>|<ThreadID>
STATUS [ALL|all [FULL|full]] |
<NomeThread>|<ThreadID> [FULL|full]
QUIT
Il comando NEW viene utilizzato per creare un nuovo oggetto ctrlThread,
impostandone il nome, il tipo e il processo remoto da controllare. Come opzio86
5.8. DAQ Control
Figura 5.14: Console di interfaccia al tool DAQ Control
ni possono essere forniti il numero di code, necessario per processi come BLD e
DSK in cui possono essere usate una o due code a seconda degli ADC impiegati,
l’intervallo temporale tra controlli successivi e il timeout oltre il quale una comunicazione senza riscontro deve essere considerata fallita. Il comando DELETE
viene utilizzato per la cancellazione di un thread di controllo. Questa puó essere
effettuata indicando il nome assegnato al thread durante la sua creazione o indicando l’ID che viene associato automaticamente ad ogni oggetto ctrlThread.
I comandi START e STOP vengono utilizzati, con opzioni analoghe al comando DELETE, rispettivamente per avviare e fermare il thread di controllo. La
semplice creazione dell’oggetto infatti non determina l’inizio della diagnostica che
puó essere fatta partire arbitrariamente in un momento successivo. Il comando
STATUS permette di conoscere, con diversa granularitá, lo stato del sistema
di diagnostica. Invocato con il parametro NomeThread o ThreadID permette di
conoscere lo stato dell’oggetto di controllo indicato. A seconda del livello di profonditá richiesto (parametro full ), sará possibile conoscere dallo stato del processo
locale e remoto all’insieme di tutte le variabili interne. Il comando STATUS puó
essere invocato senza alcun parametro nel qual caso fornirá lo stato del sistema
di diagnostica inteso come il numero di thread istanziati, il numero di thread in
esecuzione, ecc. Invocato con il parametro all invece fornirá i dati di ogni thread
istanziato.
Un’ulteriore interfaccia con il mondo esterno é fornita dai thread di controllo
del sistema di diagnostica come ctrlWatchDog. Questi si occupano di verificare
se qualcuno tra i processi di diagnostica ha riscontrato un’anomalia nei processi
remoti del DAQ e, in quest’ultimo caso, avvertono l’utente mediante indicazioni
sulla console oppure via posta elettronica.
La necessitá di poter controllare in modo semplice quale sia lo stato attuale
del sistema di acquisizione ha indotto l’implementazione di un ulteriore oggetto:
ctrlDAQStatus. Il compito da esso svolto é relativamente semplice: con un
periodo impostabile dall’utente esso verifica lo stato del sistema provvedendo a
87
Capitolo 5. Calibrazione e Diagnostica del Sistema
(a) STATUS ALL
(b) STATUS Thread
Figura 5.15: Informazioni ottenibili da console mediante il
comando STATUS
raccogliere tutti i dati di interesse per una descrizione sintetica dello stato del
DAQ Dalle informazioni ottenute provvede alla generazione di una pagina in
formato HTML standard che viene pubblicata nel sito di AURIGA permettendo
quindi, ad ogni utente del gruppo, di verificare via WEB con un comune browser
se l’acquisizione procede correttamente oppure se é necessario un qualche tipo di
intervento.
88
Capitolo 6
Conclusioni e sviluppi futuri
L’evoluzione continua del settore informatico richiede un aggiornamento parimenti costante degli strumenti utilizzati, tuttavia una buona progettazione alla base
di un prodotto lo rende piú longevo e permette, quando inevitabilmente diviene
necessario apporvi modifiche, di riutilizzarne una parte consistente. É questo il
caso della versione precedente del DAQ di AURIGA, la cui attenzione nello sviluppo non ha richiesto una riprogettazione dell’architettura del sistema: il nuovo
sistema di acquisizione infatti é costituito dai medesimi processi interoperanti con
i protocolli che erano stati stabiliti quasi due anni or sono.
Un sistema di acquisizione, se rispetta i requisiti di progetto, ha un ciclo
di vita molto maggiore dei normali tool informatici, non essendo indispensabili
gli aggiornamenti necessari ad inseguire l’evoluzione del mercato. Come ogni
prodotto software tuttavia, in seguito all’uso possono essere riscontrati problemi
e vengono dunque richieste modifiche. L’utilizzo stesso del sistema é fonte di
bisogno per nuove funzionalitá che precedentemente non era state contemplate,
oppure erano considerate di importanza ridotta. Tutto ció assieme alla necessitá
di un terzo sistema di acquisizione ha reso necessario l’aggiornamento del DAQ,
inteso come migrazione verso nuove piattaforme hardware e software, correzione
dei problemi riscontrati e introduzione di nuove caratteristiche.
Il nuovo DAQ trae le sue origini dalla versione sviluppata nel 2001 e fondamentalmente ne utilizza l’architettura. In esso sono stati corretti i malfunzionamenti
riscontrati, particolarmente i problemi descritti nel Capitolo 4 relativamente alla
sincronizzazione con il tempo universale e l’utilizzo dei canali ausiliari, e sono
state apportate alcune migliorie dettate dalle modificate esigenze di utilizzo.
Il sistema cosı́ ottenuto é stato oggetto di attente verifiche in condizioni di
utilizzo diversificate. Sono stati effettuati numerosi test con diverse condizioni di
carico, nelle varie configurazioni possibili, ottenendo ottimi risultati che si possono riassumere in due mesi di acquisizione di tutti i canali senza errori. Le verifiche
di sincronizzazione sono state effettuate con run ingegneristici acquisendo alcuni
segnali di forma nota e procedendo a posteriori al controllo della sincronizzazione
con il tempo UTC. I risultati dei test di funzionamento sono quindi soddisfacenti,
dimostrando la correttezza delle soluzioni adottate. Superate queste verifiche si é
provveduto al confronto diretto dei dati acquisiti con il vecchio sistema di acqui89
Capitolo 6. Conclusioni e sviluppi futuri
sizione, di cui erano noti i parametri di funzionamento, in modo da poter stabilire
la compatibilitá dei Frame acquisiti. Il test si é svolto fornendo in ingresso ad
entrambi i sistemi un segnale, con metodologia analoga alla diagnostica off-line
descritta nel Capitolo 5. Il risultato dell’esperimento é stato un buon accordo tra
i due sistemi, con una sincronizzazione a livello di un campione dei segnali acquisiti, massima precisione ottenibile dato che i due sistemi iniziano l’acquisizione
in modo totalmente indipendente e asincrono. In conclusione dai test effettuati
contestualmente allo sviluppo e a posteriori, il nuovo DAQ di AURIGA rispetta
i requisiti imposti dall’esperimento, riuscendo in piú di qualche occasione a fornire risultati migliori rispetto alle richieste, ad esempio aumentando la banda di
acquisizione per i canali ausiliari.
Al DAQ, nella sua versione aggiornata e corretta, sono stati affiancati altri
strumenti, di cui i maggiormente importanti sono stati trattati nel capitolo 5,
permettendo di calibrare il sistema e di mantenerlo sotto controllo per tutta la
durata del run.
Il tool “DAQ Calibration” ha permesso di ottenere una procedura automatica
e replicabile del processo di calibrazione, fornendo uno strumento utilizzabile su
tutti i sistemi di acquisizione e permettendo all’utente di impostare la precisione
con cui si vuole ottenere la misura. Grazie a questo applicativo é stato possibile
stimare con la precisione richiesta i ritardi introdotti dalla strumentazione nel
sollevamento delle interruzioni utilizzate per la sincronizzazione e l’errore massimo
commesso dal sistema nella sincronizzazione con il tempo universale. Nelle misure
esposte nei capitoli precedenti di questa tesi si é arrivati a stimare un errore di
sincronizzazione di circa 250ns, pari al 25% dell’errore massimo richiesto per
l’esperimento.
Utilizzando il sistema di diagnostica é ora possibile certificare i dati raccolti,
potendo stabilire la costanza della funzione di trasferimento lungo l’intera durata
dell’acquisizione, anzi la determinazione stessa dei parametri di trasduzione puó
essere effettuata a partire dai dati acquisiti.
Grazie alla diagnostica online infine é possibile monitorizzare il sistema durante il suo funzionamento anche remotamente, permettendo di intervenire tempestivamente al verificarsi di malfunzionamenti inevitabili in sistemi informatici
complessi.
Il sistema oggetto della tesi ha fornito finora ottimi risultati ed é essenzialmente completo. I possibili sviluppi che non sono stati interamente affrontati
in questo lavoro riguardano prevalentemente il completamento della diagnostica
on-line.
90
Ringraziamenti
Molte sono le persone a cui vorrei esprimere la mia gratitudine per aver contribuito alla realizzazione di questa tesi. In particolare vorrei ringraziare i miei genitori
Ughetta e Giuseppe, che mi hanno sempre incoraggiato e sostenuto durante i lunghi anni di universitá, e Laura, che mi é stata accanto credendo in me. Ringrazio
i miei familiari per l’affetto che negli anni hanno saputo dimostrarmi, gli amici e
i compagni di studio, con i quali ho condiviso tante esperienze. Vorrei ringraziare
il mio relatore, Ch.mo Prof. Alessandro Beghi, per la sua disponibilitá e per l’avermi indirizzato presso AURIGA: non avrei potuto sperare in un posto migliore.
Ringrazio il Ch.mo Prof. Massimo Cerdonio che mi ha accolto nel suo gruppo,
il Dott. Antonello Ortolan che ha avuto la pazienza di seguirmi e consigliarmi
durante tutto il periodo della tesi, tutti i membri di AURIGA con i quali é stato
un piacere e un privilegio lavorare, i miei colleghi di tesi, Martina e Stefano che
hanno contribuito a rallegrare il mio lavoro. Grazie di cuore a tutti.
Bibliografia
[1] Si veda ad esempio:
Schutz, Bernard F., Gravitational Radiation, Enciclopedia of Astronomy and
Astrophysics, (IoP Publishing, Bristol, and Macmillan Publishers, London,
2000).
David Blair, Geoff McNamara, Ripples on a cosmic sea: the search for
gravitational waves, (Addison-Wesley, USA, 1998).
[2] J.H. Taylor, Binary pulsars and relative gravity, Rev. of Mod. Phis., 1994.
[3] M. Cerdonio et al., The Ultracryogenic Gravitational Wave Detector
AURIGA, Class. Quantum Grav. 14 (1997) 1491.
L. Conti at al., The AURIGA second scientific run and the dual detector of
gravitational waves, Nucl. Instrum. Meth. Phys. Res. A 518 (2004) 236.
J.-P. Zendri et al., Status report and near future prospects for the gravitational
wave detector AURIGA, Class.Quant.Grav. 19 (2002) 1925.
[4] M. Bignotto et al., New AURIGA cryogenic suspension system, proceedings of the ’28th International Cosmic Ray Conference, T.Kajita, Y.Asaoka,
A.Kawachi, Y.Matsubara and M.Sasaki eds., (Univ. Ac. Press, Tokyo, 2003)
3089.
[5] M. Cerdonio et al., Sub-Millisecond Absolute Timing: Toward an Actual
Gravitational Observatory, Mod. Phys. Lett A 12 (1997) 554.
V. Crivelli Visconti et al, Timing with resonant gravitational wave detectors:
an experimental test, Phys. Rev. D 57 (1998) 2045.
[6] http://www.virgo.infn.it/
[7] http://www.ligo.caltech.edu/
[8] http://lisa.jpl.nasa.gov/
[9] http://igec.lnl.infn.it/
[10] A. Cesaracciu, Progettazione e realizzazione di un sistema di acquisizione
dati per l’esperimento AURIGA, Tesi di Laurea, Universitá di Padova, 2001.
93
Bibliografia
[11] A. Cesaracciu, G. Vedovato and A. Ortolan, A modular object oriented
data acquisition system for the gravitational wave AURIGA experiment,
Proceedings of CHEP03, La Jolla (CA), 2003.
[12] A. Ortolan et al., Parametric adaptive filtering and data validation in bar
gw detectors, Class.Quant.Grav. 19 (2002) 1457.
[13] http://www.esat.it/
[14] A.A.V.V., HP E1413A 64-channel high speed scanning A/D User’s manual,
Hewlet Packard, 1993.
[15] A.A.V.V., HP E1430A VXI ADC operator’s guide, Hewlet Packard, 1993.
[16] http://www.vxitech.com/
[17] Bruce Eckel, Thinking in C++, Volume 1, (Mindview, USA, 2001).
Bruce Eckel, Thinking in C++, Volume 2:
(Mindview, USA, 2003).
Practical Programming,
[18] John G. Proakis, Dimitris G. Manolakis, Digital Signal Processing: principle,
algorithms, and applications, (Macmillan, New York, 1992).
Athanasios Papoulis, Probability, random variables and stochastic processes,
Second edition, (McGraw-Hill, Singapore, 1984).
[19] http://www.omg.org
[20] http://www.corba.org
[21] Duncan Grisby, Sai-Lai Lo, David Riddoch, The omniORB version 4.0 User
Guide, Apaspere Ltd, 2004.
Tristan Richardson, The OMNI Naming Service, AT&T Laboratories,
Cambridge, 2000.
Duncan Grisby, The omniORB IDL Compiler, AT&T Laboratories,
Cambridge, 2000.
Eoin Carroll, The omniORB utilities, Apaspere Ltd, 2000.
Sito web di riferimento: http://omniorb.sourceforge.net
[22] Tristan Richardson, The OMNI Thread Abstraction, AT&T Laboratories,
Cambridge, 2001.
[23] http://ose.sourceforge.net/
[24] LIGO Data and Computing Group, Virgo Data Acquisition Group, Specification of a Common Data Frame Format for Interferometric Gravitational
Wave Detectors (IGWD), VIRGO-SPE-LAP-5400-102, 2002.
94
Bibliografia
LIGO Data and Computing Group, Virgo Data Acquisition Group, Frame
Library User’s Manual, VIR-MAN-LAP-5400-103, 2004.
http://lappweb.in2p3.fr/virgo/FrameL/
[25] http://root.cern.ch/
[26] Matteo Frigo, Steven G. Johnson, FFTW for Version 3.1, MIT, 2003.
http://www.fftw.org/
[27] A.A.V.V., Getting started with the VXIpc 770/870/870B series and the
NI-VXI/NI-VISA software for Linux, National Instruments, 2002.
A.A.V.V., Getting started with your PCI-MXI-2 and the NI-VXI/NI-VISA
software for Linux, National Instruments, 2002.
[28] A.A.V.V., NI-VXI User manual, National Instruments, 1996.
A.A.V.V., NI-VXI Programmer reference manual, National Instruments,
1996.
[29] http://www.redhat.com/
[30] http://www.trolltech.com/
[31] http://www.kde.org/
[32] http://www.kdevelop.org/
[33] http://www.kernel.org/
[34] http://www.tldp.org/
[35] David S.Lawyer, Greg Hankins, Serial HOWTO, The Linux Documentation
Project, 2003.
95