Un database per la costruzione delle camere rpc
La costruzione sara' fatta in 2 laboratori (Bari e Pavia) e si tratta di
480 camere con la necessita' di memorizare forse 10K di informazione per camera
per un totale di alcuni giga.
La costruzione inizia a Luglio 2000 ma le informazioni per i fogli di bakelite
devono cominciare ad essere inserite nel database a partire dal 4 Febbraio.
Al momento attuale il CMS propone di usare Cristal che pero' sembra essere
troppo complicato per i sottodetector come il nostro(Cristal e' stato
progettato pensando a ECAL coi suoi 80000 cristalli). Alcuni subdetector
come le camere a drift di Padova stanno usando
dei sistemi piu' semplici.
Qualcuno (Organtini) ha usato Cristal ma semplificandolo al massimo.
Obiettivi
- Entro Febbraio 2000 valutazione dei database esistenti
- L'installazione del sistema di Padova sulla Sun cms al Cern dovrebbe
servirci come addestramento sui data base e linguaggi ad oggetti.Inoltre dovremmo capire che lavoro occorre per adattare il sistema di Padova agli RPC e su
quale macchina si puo' installare.
- Documentarsi meglio su Cristal e vedere se e' possibile fare qualche test
preliminare.
- Scrivere un rapporto con le raccomandazioni
- Modello dei dati per le camere RPC prima stesura per Febbraio 2000
- Installazione software sperimentale entro Febbraio-Marzo
- Definizione dell'interfaccia Web.
- Installazione software definitivo entro Luglio 2000
- Installazione sistema integrato in CMS entro ?
Una maniera di procedere
Una maniera possibile di procedere e' di studiare e risolvere il problema per passi facendo diverse iterazioni.
- Prima iterazione - definizione dettagliata delle procedure con un documento Web:creare una prima definizione delle tabelle che servono
- Seconda iterazione - realizzazione delle tabelle piu' urgenti
(bachelite) con un sistema artigianale:Access su netview oppure Mysql su alboot.
- Cominciare a studiare Cristal e gli altri sistemi della collaborazione e raffinare la definizione del database
fino ad arrivare a una sua definizione completa.
- Cominciare col fare un sistema ad hoc
semplificato che includa tutto il database e intanto cominciare a studiare il problema dell'integrazione dei dati in CMS.
- Realizzazione del sistema finale integrato in CMS.
Descrizione
Il sistema integrato richiede un database ad oggetti distribuito (Per adesso Objectivity) e un'interfaccia verso il database. Questa interfaccia e' realizzata
con CORBA in Cristal e con Java RMI a Padova.
In particolare per quanto riguarda l'implementazione RMI, si tratta di una
tipica organizzazione a 3 livelli dove i 3 livelli sono:
- il database distribuito Objectivity
- Un normale server Web(Apache) + server RMI Java
- uno o piu'
applet che fanno da client
La comunicazione tra 1 e 2 avviene usando l'API Java fornita da Objectivity;
tra 2 e 3 usando Java RMI e il Web.
Ogni centro di produzione ha una copia locale dei dati e un server locale di RMI.Ma nel nostro caso potremmo fare anche a meno del data-base distribuito
ed avere un solo database centralizzato a Bari.
Il modello dei dati
Il rivelatore dei muoni CMS nel barrel e' costituito da 5 ruote indipendenti sistemate
intorno al tubo dell'accelleratore,ciascuna delle quali e' formata da quattro
livelli concentrici di camere.Le camere RPC vere e proprie sono delle camere a drift e sono indicate dalla sigla MB.Le camere o "stazioni" RPC(resistive plate chamber) costituiscono invece un rivelatore dedicato al trigger. Esse sono disposte esternamente e (nei due strati piu' vicini al tubo dell'accelleratore) anche internamente
rispetto alle camere dei mu . Dato che ogni
ruota e' divisa in 12 spicchi e che le camere rpc
dei 2 strati esterni sono 2, abbiamo un totale di 8 camere per spicchio,60
per ruota e 480 per tutto il barrel.
Le ruote sono numerate da -2 a + 2 seguendo l'orientamento dell'asse z. Infatti
il sistema di riferimento di CMS prevede che l'asse x sia diretto verso il centro di LHC, l'asse y verso l'alto e l'asse z in modo da formare una terna destrorsa. In pratica l'asse z e' parallelo all'anello e se guardiamo a questo col
Jura davanti a noi, esso va in senso antiorario.
Gli spicchi sono numerati da 1 a 12 cominciando dallo spicchio alle "ore 3" in senso antiorario.
Ogni camera detta anche stazione e' ottenuta assemblando piu'
RPC singole gap a formare una doppia gap. All'interno di
questo sandwich di singole gap, abbiamo il piano di strip.Le strip corrono
parallele all'asse z,in modo da permettere la lettura e i rifornimenti lungo
i bordi delle ruote.Invece la suddivisione delle stazioni in singole avviene
tagliando parallelamente all'orlo della ruota.Dato che lo spessore della ruota
e' fissa, tutte le camere sono assemblate con doppie gap di identica dimensione lungo lo spessore della ruota. L'altra dimensione varia invece da camera a camera.
A sua volta una singola gap e' composta
da due piani di bachelite separati da un volume gassoso che ne costituisce
la parte attiva.In totale verranno fabbricate 3675 lastre di bachelite.Queste
saranno assemblate a formare 1920 singole gap.
I piani di strip sono collegati a un'elettronica che ne
permette la lettura.Sia la lettura delle strip che i vari collegamenti non avvengono per tutte le doppie gap dalla stessa parte.Le camere sono progettate
con 2 possibili tipi simmetrici riguardo ai collegamenti e costruiti
meta' secondo un tipo e meta' secondo l'altro tipo.L'uso di un tipo o dell'altro dipende dal verso di estrazione della camera dalla ruota.
Gli strati di camere sono numerati da 1 a 4
da quello piu' interno a quella piu' esterno.Le camere hanno tutte la stessa struttura
con un sandwich di 2 singole gap sopra e 2 singole gap sotto, eccetto 60 camere dello strato 2 che hanno una struttura invece 3+3. La nomeclatura delle
camere e' percio':
- RB1(120)
- RB2_HPT(60 3+3 )
- RB2_LPT(60)
- RB3(120)
- RB4(120)
Le dimensioni sono identiche nei 12 settori
tranne per RB4 dove variano e ci sono 5 formati diversi
- RB4a(settori 1,2,3,5,6,7)
- RB4b(4)
- RB4c(8,12)
- RB4d(9,11)
- RB4e(10)
All'interno delle camere abbiamo dei fogli di bachelite che devono essere
controllati separatamente.
Abbiamo inoltre una serie di strip.Un Front End per il readout delle stesse ed inoltre i collegamenti di alta tensione(HV) e bassa tensione (LV).
Ogni Singola Gap ha una dimensione e puo' essere di vari tipi.Le Singole
Gap si distinguono anche per come e' disposta l'alta tensione.
Ogni componente deve essere rappresentato nel database da una classe(di seguito parleremo di classi/oggetti ma la stessa cosa vale per le tabelle/righe).
Quindi avremo oggetti Chamber che possono contenere 2 0 3 Doublegap. Una Doublegap contiene 2
Singlegap e una Singlegap 2 oggetti Bachelite. L'oggetto
DoubleGap contiene anche 6 oggetti FrontEnd e ogni FrontEnd
2 Chip.Inoltre e' previsto un oggetto Kapton che descrive i vari tipi di Kapton usati:a ogni tipo di Kapton e' associato un certo disegno.
L'oggetto ChamberType descrive la
diecina di differenti misure di strip usate,ognuna delle quali corrisponde a una diversa larghezza della camera.Invece la dimensione lungo il beam (asse Z) e'
uguale per tutte le camere. I fogli di bachelite sono a loro
volta caratterizzati da svariate misure fatte all'atto della costruzione, un
codice a strisce e un codice di colore.Dato che le dimensioni di molte camere
sono identiche, invece di ripetere le informazioni da un oggetto all'altro
usiamo una classe ChamberType per definire tutte le diverse dimensioni.
Altre informazioni che potrebbero essere inserite nel data base
La costruzione e il test avviene in 4 fasi:
- Costruzione e test dei fogli di bakelite non tagliata a Pavia
- I fogli di Bakelite provvisti di codice a barre sono mandati a Colli
dove sono tagliati delle corrette dimensioni, assemblati in singole gap e
testati. La stessa cosa viene ripetuta con le doppie gap e le camere senza
elettronica.
- Le camere sono spedite a Bari dove viene aggiunta l'elettronica e avviene
il test complessivo.
- Le camere sono spedite al Cern dove avviene il test finale
- Una parte delle camere (120 RB1) sono fatte dai cinesi che devono
ricevere alcune parti delle camere e poi le spediscono a Bari per il test
elettronico.
- La Bulgaria fa un'altra parte con test elettronico completo e poi le
spedisce al Cern.
Domanda: dobbiamo avere delle tabelle separate di componenti non ancora
assemblati e componenti assemblati? Inizializzare i componenti assemblati
coi valori di progetto?
I dati di Pavia vengono raccolti "a mano".Lo stesso succedera' per Colli?
Non c'e' il pericolo di errori?
Altre informazioni che il db potrebbe contenere sono legati alla progettazione
e all'acquisto dei vari pezzi oltre la bakelite(bulloni,etc..) necessari per l'assemblaggio e cioe':
- Lista dei componenti con stato degli acquisti e del magazzino.
- dimensione dei profili
Dobbiamo preparare dei formulari da far riempire coi dati della costruzione
di ogni gap, bigap e camera completa a Colli.
Fornire per ogni camera da costruire, informazioni per i Cinesi e i
Bulgari.
Requisiti
Il sistema deve consentire la memorizzazione,la visualizzazione e la modifica di informazioni relative ai componenti del rivelatore.Il database deve essere accessibile
su tutti i laboratori che effettuano la costruzione con un'interfaccia Web facile da usare.La modifica dei dati deve avvenire solo dopo aver fornito una password.Tutti i pezzi devono avere un identificatore. Il database deve servire per
memorizzare i test fatti su ogni componente possibilmente dal banco di test
con un'interfaccia diretta. Probabilmente l'uso di codice a barre puo' essere
la scelta migliore per evitare errori manuali.
Il sistema prescelto:MySQL+php3 su macchina Unix/Linux
Si e' deciso di usare questo sistema perche' risponde in pieno alle nostre
esigenze. In particolare:
- MySQL e' adatto a trattare database delle nostre dimensioni.
- Interfaccia Web molto facile da costruire con PHP3
- Il database e' centralizzato (su un unico computer a Bari) ma nel nostro caso
questo e' piu' che sufficiente:non abbiamo bisogno di sistemi distribuiti.
- Interfaccia per l'amministratore gia' disponibile.
In ogni caso il sistema sara' sviluppato in maniera che l'interfaccia utente
sia indipendente dal dbms usato:cioe' se in futuro decidiamo di cambiare
dbms, l'utente non dovrebbe accorgersi del cambiamento.Inoltre,fin dall'inizio, avremo un apposito programma che estrarra' tutti i dati di interesse generale
per CMS e li carichera' in un database,presumibilmente Objectivity, accessibile
a tutti i programmi generali di CMS.
Interfaccia Web
L'interfaccia Web dovrebbe essere indipendente dal dbms usato.Inoltre dovrebbe
esistere un'interfaccia sofisticata per l'amministratore e quella semplice per
il normale utilizzatore.
Questo approccio e' stato gia' applicato
alla pagina iniziale,dove le immagini presentate permettono di selezionare la camera senza bisogno di conoscere come e' fatto il database.
Esso sara' ora esteso alle altre pagine. Per cominciare si scrivera' un programma Java che leggendo le informazioni del database creera' 480 immagini,
una per ogni camera, con una rappresentazione schematica della stessa
che,oltre a visualizzare le maggiori proprieta' della stazione, permettera' di accedere in maniera intuitiva alla descrizione delle sue parti. Questo programma potrebbe diventare in futuro un'applet incluso direttamente nella pagina.
La scelta tra applet o immagine generata da un programma Java e' dettata da compromessi tra :
- Un applet e' pesante in termini di calcolo (lento da caricare) ma fornisce
una rappresentazione aggiornata del database .
- Un'immagine e' veloce da caricare ma riflette il contenuto del data base di quando e' stata creata.
.
Questo programma e' essenziale anche per:
- Essere sicuri che la struttura del database sia OK
- Essere sicuri che il dbms usato permette un facile accesso dei dati
non solo dal Web ma anche a normali programmi.(Es scrittura programmi di
calibrazione).
Integrazione del data base in CMS
Si propone di scrivere anche qui un programma Java che acceda al database
MySQL, ne estrae i dati che servono, e li carica in un database Objectivity
accessibile al normale software CMS.Questo richiede un soggiorno al Cern
per discutere con gli altri membri della collaborazione:
- Dove sono i dati di RPC attualmente usati dal software CMS (CMSIM,Oscar)
- Quali dati degli RPC devono essere accessibili al software CMS.
- Come devono essere organizzati:definizione delle classi per Objectivity
L'aggiornamento di questo database potrebbe essere fatto dal programma Java
suddetto in maniera automatica, facendolo girare come cronjob su alboot.
Confronto tra Cristal e Quality Control di Padova
| Cristal | Padova
|
| server con Objectivity | 300Mhz/128Mb/9GB | 300Mhz/128Mb/9GB
|
| stazione operatore | 200Mhz/64Mb/1GB |
|
| sistema operativo | | Windows Nt e Sun Unix
|
| software di interfaccia | Orbix CORBA software from Iona Technologies | Java RMI
|
| database distribuito | Objectivity V5 | Objectivity V5
|
| Ruoli previsti | Centre Supervisor
Operator
Information Manager | -
|
| Assembly sequences per ogni sottocomponente | integrate nel sistema | a mano |
| Integrato col sistema centrale al cern | si | ?
|
| Installazione | | Su NT facile ma il sistema operativo non sembra affidabile.
|
| Lavoro da fare per adattare alle camere rpc | | 1 mese?
|
| Installazioni gia' esistenti | Ecal cristalli,Pisa silici,Roma | Padova su Sun
|
| Test comunicazione database separati
|
| Facilita' d'uso | |
|
Glossario
- CSC - Cathode Strip Chambers
- DT - Drift Tube
- EDMS - Engineering Data Management System - archivio per tutti i
documenti necessari per la costruzione di una serie di componenti.
- FE - Front End
- PACT - Pattern Comparator Trigger - part of Level1 RPC trigger electronics.
- QC - Quality Control - serie di procedure per accertare la qualita'
di un componente.
- Workflow Manager - Programma che permette di seguire l'iter completo
della fabbricazione di una serie di componenti : Cristal e' un workflow manager.
Risorse online
Giuseppe Zito
Last modified:
