Database Object-Oriented per la gestione di dati sperimentali

UNIVERSITÀ DEGLI STUDI DI ROMA
“La Sapienza”
Facoltà di Ingegneria
Corso di Laurea in Elettronica
Tesi di Laurea
DataBase Object-Oriented per la gestione
di dati sperimentali Tokamak
Laureando
Carmelo Stracuzzi
Relatore
Correlatore
Prof. Umberto Nanni
Dott. Francesco Iannone
Anno accademico 1998/99
Sommario
I
SOMMARIO
INTRODUZIONE......................................................................................................................................................... 4
1. CENNI SULLA FUSIONE NUCLEARE............................................................................................................ 7
1.1.
1.2.
1.3.
1.4.
1.5.
LA FUSIONE TERMONUCLEARE ..................................................................................................................... 8
IL PLASMA ...................................................................................................................................................... 9
REAZIONI NUCLEARI ESOENERGETICHE ......................................................................................................11
LA FUSIONE TERMONUCLEARE CONTROLLATA ...........................................................................................13
IL TOKAMAK ................................................................................................................................................15
1.5.1. Riscaldamento del plasma ...........................................................................................................17
1.5.2. Gli scenari per la realizzazione del reattore ..............................................................................18
1.6. IL FRASCATI TOKAMAK U PGRADE ..............................................................................................................21
2. DESCRIZIONE DELL’IMPIANTO SPERIMENTALE...............................................................................25
2.1. DESCRIZIONE DELL’IMPIANTO SPERIMENTALE ...........................................................................................26
2.1.1. La Macchina .................................................................................................................................27
2.1.2. Alimentazioni Elettriche...............................................................................................................31
2.1.3. Radiofrequenza .............................................................................................................................33
2.2. DIAGNOSTICHE .............................................................................................................................................37
2.3. CONTROLLO E SUPERVISIONE ......................................................................................................................44
2.3.1. La sequenza di controllo veloce (FSC) .......................................................................................49
2.3.2. L’acquisizione dati veloce (FDA)................................................................................................51
2.3.3. Il sistema di feedback ...................................................................................................................51
2.4. ACQUISIZIONI DATI ......................................................................................................................................53
2.5. SPERIMENTAZIONE SU FTU .........................................................................................................................56
3. DATABASE OBJECT-ORIENTED ..................................................................................................................60
3.1. INTRODUZIONE .............................................................................................................................................61
3.2. BASI DI DATI AD OGGETTI ...........................................................................................................................63
3.3. CONCETTI CHIAVE DEL PARADIGMA OBJECT-O RIENTED ...........................................................................64
3.3.1. Oggetti ed identità ........................................................................................................................64
3.3.2. Incapsulamento.............................................................................................................................65
3.3.3. Classi.............................................................................................................................................65
3.3.4. Ereditarietà e polimorfismo.........................................................................................................66
3.4. MODELLI DEI DATI OBJECT-ORIENTED ........................................................................................................67
3.4.1. OID................................................................................................................................................67
3.4.2. Incapsulamento.............................................................................................................................68
3.4.3. Strutture dati degli OODBMS .....................................................................................................68
3.4.4. Persistenza ....................................................................................................................................70
3.4.5. Vincoli di Integrità .......................................................................................................................71
3.5. INTERROGAZIONI NEGLI OODBMS ............................................................................................................73
3.5.1. Accesso navigazionaleai dati.......................................................................................................74
3.5.2. Accesso tradizionale.....................................................................................................................76
3.6. MEMORIZZAZIONE DEGLI OID ....................................................................................................................77
3.7. PATTERN DI ACCESSO E STRATEGIE DI MEMORIZZAZIONE .........................................................................79
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Sommario
II
3.7.1. Modello diretto .............................................................................................................................80
3.7.2. Modello normalizzato...................................................................................................................81
3.8. CLUSTERING .................................................................................................................................................82
3.9. GESTIONE DELLE TRANSAZIONI: CONTROLLO DELLA CONCORRENZA ......................................................84
3.9.1. Multigranulary locking ................................................................................................................84
3.9.2. MGL in OODBMS ........................................................................................................................86
3.10. ODMG ......................................................................................................................................................87
3.10.1. Object Model ................................................................................................................................88
3.10.2. Object Model: Stato e comportamento .......................................................................................89
3.10.3. Object Model: Metadata ..............................................................................................................89
3.10.4. Operazioni sul tipo Database ......................................................................................................91
3.10.5. OQL (Object Query Language) ................................................................................................91
3.11. OBJECTSTORE PSE PRO FOR JAVA .............................................................................................................92
3.11.1. La persistenza ...............................................................................................................................92
3.11.2. Tools di sviluppo...........................................................................................................................93
3.11.3. Librerie..........................................................................................................................................94
3.11.4. Transazioni e concorrenza...........................................................................................................94
3.11.5. Oggetti composti e Relationships ................................................................................................95
4. SPECIFICHE ED ANALISI DEL PROBLEMA ............................................................................................96
4.1. L’AMBIENTE OPERATIVO .............................................................................................................................97
4.2. AMBIENTI HARDWARE E SOFTWARE ........................................................................................................100
4.2.1. Il DAS ..........................................................................................................................................100
4.2.2. L’archivio sotto AFS .................................................................................................................101
4.2.3. Il software di analisi...................................................................................................................105
4.3. ANALISI DEI REQUISITI ...............................................................................................................................109
4.3.1. Il quaderno di bordo ..................................................................................................................112
4.3.2. Le tabelle Hardware e Software................................................................................................115
Tabella Hardware ........................................................................................................................................ 116
Tabella Software ......................................................................................................................................... 117
4.3.3. L’archivio dei dati sperimentali ................................................................................................123
L’archivio dei dati DAS.............................................................................................................................. 124
L’archivio dei dati post-elaborati (PED) ................................................................................................... 125
4.4. MODELLO SEMANTICO DEI DATI DI FTU...................................................................................................128
4.5. SCHEMA LOGICO DEI DATI DELL’ARCHIVIO DI FTU .................................................................................131
4.5.1. Le Tabelle Hardware .................................................................................................................133
4.5.2. Le Tabelle Software....................................................................................................................135
4.5.3. I Dati Sperimentali .....................................................................................................................137
4.5.4. Schema completo ........................................................................................................................139
4.5.5. Vincoli .........................................................................................................................................140
4.5.6. Operazioni sul DB ......................................................................................................................142
5. REALIZZAZIONE.............................................................................................................................................150
5.1. SCHEMA RISTRUTTURATO .........................................................................................................................151
5.2. STRUTTURA DEL SOFTWARE .....................................................................................................................152
5.2.1. Le classi d’accesso al database.................................................................................................154
5.2.2. Routines di popolamento del DB...............................................................................................161
5.2.3. Interfaccia utente........................................................................................................................161
5.2.4. Metodi di elaborazione dei dati.................................................................................................163
5.2.5. Interazione con altri applicativi ................................................................................................167
CONCLUSIONI........................................................................................................................................................169
APPENDICE .............................................................................................................................................................170
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Sommario
A.
III
IL LINGUAGGIO UML.................................................................................................................................171
Introduzione............................................................................................................................................171
Che cos’e UML?.....................................................................................................................................174
Diagrammi dei casi d’uso......................................................................................................................176
Diagrammi di classe ..............................................................................................................................178
Diagrammi di comportamento ..............................................................................................................183
Diagrammi di interazione ( sequenza e collaborazione)........................................................................... 184
I diagrammi di stato .................................................................................................................................... 186
B.
C.
D.
E.
Diagrammi di implementazione (componenti e sviluppo) ...................................................................188
JAVADOC ....................................................................................................................................................191
TABELLE HARDWARE E SOFTWARE ..........................................................................................................193
Tabella Hardware ..................................................................................................................................193
Tabella Software ....................................................................................................................................196
ALGORITMO DI ELABORAZIONE CANALE ..................................................................................................201
CONVENZIONI.............................................................................................................................................202
BIBLIOGRAFIA ......................................................................................................................................................204
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Introduzione
4
INTRODUZIONE
Scopo della tesi è la realizzazione di uno schema logico, basato sul modello ObjectOriented, della base di dati di un laboratorio operante nell’ambito della fisica della
fusione nucleare a confinamento magnetico, nonché l’implementazione di un
sistema prototipo basato su un OODBMS di tipo commerciale.
In molti esperimenti di grandi dimensioni i dati acquisiti dai vari sistemi (controllo e
diagnostica) generano due tipi di problemi:
• il primo direttamente legato alla dimensione dell’esperimento che produce una
enorme mole di dati ,
• il secondo dovuto alla complessità dei dati acquisiti, conseguenza di una
eterogeneità principalmente legata ai sistemi diagnostici.
Il problema della mole dei dati prodotti da esperimenti di questo tipo è
strettamente legato allo sviluppo di sistemi di acquisizione veloci e compatti. Questi
producono una quantità di dati tale da rendere problematica perfino la sola
archiviazione sui supporti di massa.
L’impiego di un DBMS nasce dall’esigenza di avere un accesso ottimizzato ai dati,
congruenza ed integrità dei dati, metodi standard di interrogazione, accesso ai dati
da diverse piattaforme, possibilità di importazione ed esportazione di dati verso
altri database, accesso e modifica dello schema dei dati senza che questo comporti
una perdita delle informazioni esistenti.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Introduzione
5
I DBMS tradizionali, tipicamente relazionali, sono caratterizzati da modelli dei dati
con un limitato potere espressivo, il che li rende inadatti a modellare quei dati la cui
struttura e le cui relazioni con altri dati non possono essere direttamente mappati
nelle strutture tabulari del modello relazionale.
Ne consegue la difficoltà di modellizzazione di oggetti complessi quali sono le
misure provenienti dalla suddetta sperimentazione. Queste deficienze hanno sinora
relegato gli archivi del laboratorio a semplici magazzini di bytes, i quali necessitano
di applicazioni specifiche per essere esplorati.
L’incalzare del paradigma Object-Oriented e la conseguente introduzione di nuovi
strumenti per la manipolazione di dati hanno aperto nuovi orizzonti, grazie, non
solo, alla prerogativa di creare e gestire modelli dei dati ‘ad hoc’, ma anche alla
possibilità di esprimere proprietà e relazioni dinamiche, nonché di gestirne
l’evoluzione temporale.
Avendo finalmente a disposizione gli strumenti necessari si intende trasformare
l’archivio degli esperimenti in una vera base di dati che non solo dia la possibilità di
manipolare grosse quantità di dati e consenta l’impiego di altrimenti inapplicabili
strumenti di indagine, ma che permetta agli sperimentatori anche di scambiare dati
con altri laboratori. Allo stato attuale delle cose non è possibile fare un confronto
reale fra i dati dei diversi esperimenti se non come semplice raffronto grafico di
segnali. La realizzazione di basi di dati fondate sulla medesima filosofia
permetterebbe di avere dei dati se non proprio omogenei almeno compatibili così
che quelli prodotti da un laboratorio possano essere confrontati, attraverso
strumenti analitici, con quelli provenienti da altri laboratori.
Da qui l’esigenza di implementare uno schema che, quanto più possibile, costituisca
un punto di convergenza tra i diversi archivi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Introduzione
6
Gli sforzi proferiti in tal senso hanno teso a realizzare un punto di accesso ai dati da
diverse piattaforme hardware e software, nell’intento di mettere utenti diversi in
condizione di poter espandere, secondo le proprie esigenze, il modello di base.
Il primo capitolo contiene una breve introduzione alla fusione nucleare, alle
problematiche che la interessano ed alle future aspettative della ricerca.
Il secondo capitolo tratta la descrizione generale dell’apparato sperimentale,
evidenziando in particolar modo gli aspetti elettronici ed informatici, così da
permettere al lettore di entrare in confidenza non solo con gli strumenti adoperati,
ma anche con il particolare linguaggio in uso nell’ambiente sperimentale.
Il terzo capitolo si propone di dare una panoramica generale sulle basi di dati
orientate agli oggetti, focalizzandone i concetti fondamentali così da dare un’idea e
delle potenzialità e delle limitazioni degli OODBMS. Particolare attenzione viene
posta nel trattamento dei canoni di standardizzazione, di cui lo strumento in
questione, data la sua giovane età, necessita.
Il quarto capitolo riguarda la raccolta dei requisiti e l’analisi del problema, partendo
dalle esigenze comuni a tutti i laboratori fusionistici per poi scendere nel particolare
scenario di FTU.
Nel quinto capitolo viene effettuata una panoramica sulla realizzazione vera e
propria del progetto, soffermandosi con maggior attenzione sulle soluzioni adottate
e gli obiettivi raggiunti.
L’appendice infine contiene una breve documentazione intesa ad agevolare il lettore
nell’approccio alla tesi ed all’UML.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
7
1
Capitolo
1. CENNI SULLA FUSIONE NUCLEARE
In questo capitolo verranno brevemente trattati i concetti basilari
legati alla fisica della fusione a confinamento magnetico, ponendo
particolare attenzione sulle problematiche che la riguardano, sugli
sviluppi ottenuti e sulle future aspettative.
Verrà descritto il Tokamak come macchina sperimentale e come
trampolino di lancio per un futuro reattore, evidenziando le sue
caratteristiche strutturali ed i vantaggi che presenta rispetto ad altri
apparati sperimentali dello stesso tipo.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
8
1.1. LA FUSIONE TERMONUCLEARE
È la reazione nucleare che avviene nel sole e nelle altre stelle, con produzione di
un’enorme quantità d’energia.
Nella reazione di fusione nuclei di elementi leggeri, quali l’idrogeno, a temperature e
pressioni elevate, fondono formando nuclei di elementi più pesanti come l’elio.
I nuclei interagiscono solo a distanze molto brevi, equivalenti alle dimensioni del
nucleo (10-15 m); in questo caso le forze nucleari sono predominanti sulle forze di
repulsione elettrostatica dovute alla carica positiva dei nuclei (forze che crescono
all’avvicinarsi dei nuclei in proporzione inversa al quadrato della distanza). Perché
due nuclei si avvicinino a distanze sufficientemente brevi è necessario che la
velocità con cui si urtano sia molto alta; la loro energia cinetica (e quindi la
temperatura) cioè deve essere molto elevata. Per ottenere in laboratorio reazioni di
fusione, ad esempio, è necessario portare una miscela di gas ionizzato a
temperature elevatissime (100 milioni di gradi) per tempi di confinamento
sufficientemente lunghi. In tal modo i nuclei hanno tempo di fare molte collisioni,
aumentando la probabilità di dar luogo a reazioni di fusione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
9
1.2. IL PLASMA
A temperatura ordinaria, in un gas, le particelle sono neutre. A temperatura
superiore a qualche eV, poiché le singole particelle tendono a dissociarsi negli
elementi costitutivi ( ioni ed elettroni ), il gas si trasforma in una miscela di
particelle cariche e neutre. Le particelle cariche hanno un’influenza essenziale sulle
proprietà del gas soltanto se le relative concentrazioni sono tali per cui la carica
spaziale da esse create ne limita il moto. A concentrazioni sufficientemente elevate
di particelle cariche positive e negative, vi è un’interazione che ha come risultato il
mantenimento della neutralità macroscopica entro un volume confrontabile con il
volume del gas. Un gas ionizzato a tali concentrazioni viene detto plasma.
Il plasma costituisce il 99% della materia di cui e’ composto l’Universo e quindi è
detto anche “quarto stato della materia”. E’ il principale costituente delle stelle e del
sole. Nel sole, che ha una temperatura interna di 14 milioni di gradi, la reazione di
fusione di nuclei di idrogeno (reazione protone-protone) è responsabile di gran
parte dell’energia che giunge fino a noi sotto forma di calore e di luce (e di neutrini
solari).
La caratteristica principale del plasma è la sua neutralità macroscopica sostenuta
dalla reciproca compensazione della carica spaziale degli ioni positivi e degli
elettroni. Le dimensioni e gli intervalli di tempo entro cui viene stabilita la neutralità
macroscopica definiscono una distanza caratteristica e un tempo caratteristico di
separazione delle cariche. La distanza caratteristica è detta raggio di Debye e vale:
rD =
T
4 ! " ! ne ! e 2
dove T è espresso in eV, n e in cm-3 e r D in cm.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
10
Di conseguenza il tempo caratteristico di separazione delle cariche nel plasma è
determinato da:
tD =
me
4 ! " ! ne ! e 2
L’inverso del tempo caratteristico è nota come frequenza di plasma o di Langmuir.
Riportiamo in tabella 1.1 alcuni parametri caratteristici di plasmi di interesse
fusionistico, dove la lunghezza caratteristica è la dimensione lineare del volume di
plasma, Te e Ti sono rispettivamente le temperature elettroniche e ioniche, e infine
τ E è il tempo di confinamento.
esperimento
Lunghezza
caratteristica (m)
Densità
(m-3)
Te
(keV)
Ti
(keV)
τE
(sec)
rD
(m)
TOKAMAK
0.2 ÷ 1
1020
3
1
10-2
10-5
-PINCH
0.01
1023
1
1
10-5
10-7
LASER
0.01
1028
0.3
0.3
-
10-10
3
1021
10
10
5
10-5
10-6 ÷ 10-2
1030
10
10
10-10 ÷ 10-8
10-10 ÷ 10-9
REATTORE
TERMONUCLEARE
STAZIONARIO
REATTORE
TERMONUCLEARE
A LASER
Tabella 1.1 – Parametri del plasma di interesse fusionistico.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
11
1.3. REAZIONI NUCLEARI ESOENERGETICHE
Gli elementi, in natura, sono costituiti da molecole formate da atomi. Gli atomi
sono caratterizzati, da un nucleo carico positivamente e dagli elettroni periferici
negativi, che ne determinano la specie.
Il nucleo a sua volta è costituito da neutroni e protoni, i nucleoni, tenuti insieme da
forze estremamente intense e a breve raggio d’azione, le forze nucleari. La massa di
un nucleo è minore della somma delle masse dei nucleoni (protoni e neutroni) che
lo costituiscono: la differenza di massa (Δm), che è in relazione con l’energia di
legame secondo la legge di equivalenza massa energia, ΔE = c2⋅Δm, si chiama
difetto di massa.
energia di legame/nucleone
Sono possibili combustibili nucleari i
nuclei che hanno più bassa energia di
FUSIONE
D
legame per nucleone, cioè quelli a piccola o
3
He
ad elevata massa atomica: gli uni danno
T
energia nucleare per fusione, gli altri per
Li
fissione.
FISSIONE
4
He
U
Consideriamo ora le reazioni nucleari che
avvengono con sviluppo di energia:
massa atomica
Figura 1.1 – Rapporto tra energia di legame e
massa del nucleone.
-
la reazione di fusione di due nuclei
leggeri, in cui si origina un nucleo più
pesante: in essa si ha liberazione di energia perché il difetto di massa del
nucleo risultante è maggiore del difetto di massa dei due nuclei reagenti;
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
-
12
la reazione di fissione, in cui un nucleo molto pesante si spezza in due
nuclei più leggeri: anche in questo caso il difetto di massa complessivo dei
frammenti è maggiore del difetto di massa del nucleo di partenza.
L’energia liberata nelle reazioni nucleari, a parità di quantità di sostanze reagenti, è
milioni di volte più grande di quella liberata nelle reazioni chimiche (combustione).
Sono noti tre isotopi dell’idrogeno: l’idrogeno propriamente detto H, il deuterio D
e il trizio T. Il nucleo di tutti e tre contiene un protone, il che li caratterizza come
forme dell’elemento idrogeno; il nucleo di deuterio contiene inoltre un neutrone
mentre quello del trizio due neutroni. In tutti i casi l’atomo neutro ha un elettrone
al di fuori del nucleo per compensare la carica del singolo protone.
La reazione più probabile è quella che avviene tra un nucleo di deuterio D e un
nucleo di trizio T, reazione in cui si genera un nucleo di elio (particella alfa 4He) di
3.5 MeV e un neutrone di 14.1 MeV . La ragione per cui le reazioni D-T sono
preferite rispetto alle altre è chiaramente mostrata dalla figura 1.2, dove per le
reazioni sono mostrate le rispettive
probabilità:
D3 + D2 → He2 + n + 3.27 MeV
D2 + He3 → He4 + H + 18.3 MeV
D2 + T3 → He4 + n + 17.6 MeV
Figura 1.2 – Probabilità di reazione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
13
1.4. LA FUSIONE TERMONUCLEARE CONTROLLATA
Per ottenere in laboratorio la fusione termonucleare controllata, con un bilancio
energetico positivo, è necessario riscaldare un plasma di deuterio-trizio a
temperature molto alte (100 milioni di gradi, più di sei volte la temperatura
dell’interno del sole), mantenendolo confinato in uno spazio limitato per un tempo
sufficiente a che l’energia liberata dalle reazioni di fusione possa compensare sia le
perdite, sia l’energia usata per produrlo. Con riferimento allo schema in figura 1.3,
indicata con Pth la potenza termonucleare prodotta dalle reazioni di fusione e con
PL le perdite (dovute principalmente ad irraggiamento), la potenza PT , che lascia il
plasma, deve essere ceduta ad un generatore G con efficienza η. La condizione
affinché questo si verifichi è espressa dal Crite rio di Lawson, condizione che
dipende dalla temperatura del plasma.
Nel caso di un plasma di deuterio-trizio a 100 milioni di gradi, (pari a circa 10 KeV
di energia) a basso contenuto di impurità, il Criterio di Lawson afferma che il
prodotto della densità di particelle del plasma n per il tempo di confinamento τ E
deve esser maggiore di 6 ⋅ 10 19 m - 3 s.
PTh
PT = PTh + PL
PH = PL
PLASMA
PL
GENERATORE
PH < η PT
Figura 1.3 – Schema del flusso di potenza per il calcolo del Criteri o di La wson .
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
14
A temperature così elevate il problema è quello di confinare il plasma in un
contenitore. In linea di principio il plasma costituito da particelle cariche (ioni di
deuterio e trizio) può essere confinato mediante un campo magnetico: in assenza di
questo campo le particelle si muoverebbero a caso in tutte le direzioni, urterebbero
le pareti del contenitore e il plasma si raffredderebbe inibendo la reazione di
fusione. In un campo magnetico invece le particelle sono costrette a seguire
traiettorie a spirale intorno alle linee di forza del campo mantenendosi lontano dalle
pareti del contenitore.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
15
1.5. IL TOKAMAK
Nella fusione a confinamento magnetico il plasma caldo è racchiuso in una
camera a vuoto e una opportuna configurazione di campi magnetici esterni e/o
prodotti da correnti circolanti nel plasma impedisce il contatto con le pareti del
recipiente.
Sono state studiate, a questo proposito, diverse configurazioni magnetiche, tra cui
le configurazioni a specchio in cui le linee di forza del campo magnetico sono
aperte alle estremità del plasma e le configurazioni a simmetria toroidale (es.
Stellarator, Tokamak).
Quella che ha ottenuto finora i migliori risultati nella fusione a confinamento
magnetico, è quella del Tokamak1.
Il Tokamak è un dispositivo di forma toroidale caratterizzato da un involucro cavo,
il toro, in cui il plasma è confinato mediante un campo magnetico a linee di forza
spiroidali.
Questa
configurazione
magnetica
è
ottenuta mediante la combinazione di un
intenso
campo
magnetico
toroidale
prodotto da avvolgimenti magnetici posti
intorno al toro, con un campo magnetico
poloidale realizzato mediante la corrente
indotta
Figura 1.4 – Camera toroidale.
nel
plasma
dall’esterno.
Quest’ultimo è necessario per evitare la
deriva delle particelle del plasma verso le
pareti della camera, vincolandole lungo traiettorie a spirale intorno alle linee di
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
16
forza del campo Avvolgimenti supplementari esterni servono a realizzare campi
magnetici ausiliari per controllare la posizione del plasma nel toro. L’analisi del
confinamento del plasma mediante campo magnetico deve ovviamente essere
basata sulla soluzione simultanea delle equazioni che descrivono il comportamento
del plasma in presenza di campi magnetici e le equazioni del campo magnetico. In
molti casi è conveniente descrivere il plasma come un fluido, neutro ma conduttore
e sensibile all’azione del campo. Questo approccio è chiamato teoria
magnetoidrodinamica.
Il primo problema che si incontra nello
studio del confinamento del plasma
mediante campo magnetico consiste nel
determinare le condizioni per le quali
l’equilibrio viene raggiunto, cioè le
condizioni
per
cui
le
forze
elettromagnetiche agenti su ogni volume
di plasma equilibrano il gradiente di
pressione che guida l’espansione del
plasma. Le linee di campo risultante dalla
Figura 1.5 – Rappresentazione schematica del
Tokamak
presenza di una componente toroidale e
di una poloidale del campo magnetico definiscono delle superfici magnetiche sulle
quali risultano costanti i valori di pressione e di flusso magnetico.
1
Dal russo Toroidal Kamera Makine
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
1.5.1.
17
RISCALDAMENTO DEL PLASMA
Essendo il plasma un conduttore elettrico, è possibile riscaldarlo mediante una
corrente indotta dall’esterno. (Il plasma nella camera si comporta come una spira
cortocircuitata che costituisce il secondario di un trasformatore il cui primario è
all’esterno).
La corrente indotta ha così il duplice scopo di creare il campo poloidale e di
riscaldare il plasma a temperatura elevata. Questo tipo di riscaldamento è detto
riscaldamento ohmico o resistivo e obbedisce
alla legge di Joule. Un limite a questo tipo di
riscaldamento è dato dal fatto che la resistività
del
plasma
temperatura
decresce
e
la
al
crescere
massima
della
temperatura
ottenibile nel plasma, è di alcuni milioni di
gradi.
Per raggiungere le temperature richieste per la
fusione termonucleare è necessario, quindi,
ricorrere al riscaldamento supplementare, che
Figura 1.6 – Sistemi di riscaldamento.
-
si può realizzare:
per induzione nel plasma di correnti oscillanti a radiofrequenza, mediante
guide d’onda o antenne che trasferiscono ad esso energia elettromagnetica;
-
per iniezione di atomi neutri di elevata energia cinetica che attraversano il
campo magnetico, vengono ionizzati e trasferiscono per collisione la loro
energia al plasma;
-
per compressione adiabatica del plasma, ottenuta spostando il plasma verso
regioni a campo magnetico più forte, con conseguente riscaldamento.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
1.5.2.
18
GLI SCENARI PER LA REALIZZAZIONE DEL REATTORE
Il cammino per arrivare alla realizzazione del reattore a fusione prevede il
raggiungimento di alcuni obiettivi fondamentali in sequenza:
-
il breakeven, in cui l’energia generata dalla fusione eguaglia quella immessa
dall’esterno per mantenere il plasma a temperatura termonucleare. Il breakeven
dimostra la fattibilità scientifica del
reattore a fusione.
-
l’ignizione
in
cui
si
ha
l’autosostentamento della reazione
di fusione, ad opera dei nuclei di
elio prodotti,
-
la fattibilità tecnologica quando,
il
rendimento
netto
l’impianto è positivo.
di
tutto
Figura 1.7 – Risultati sperimentali della ricerca.
Nel futuro reattore a fusione la reazione dovrà infatti autosostenersi: si suppone
cioè che le particelle alfa intrappolate nel volume di plasma cedano ad esso la loro
energia così da mantenerlo caldo
dopo
l’iniziale
riscaldamento
ottenuto con mezzi esterni. I
neutroni trasferiscono intanto la
loro energia al mantello del
reattore, generando il trizio e
tramutando
Figura 1.8 – Modello di reattore.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
energia
in
calore,
Cap. 1 – Cenni sulla fusione nucleare
19
utilizzabile per produrre energia elettrica.
L’energia prodotta dalle reazioni di fusione si esplica sotto forma di energia cinetica
(calore) dei prodotti della reazione:
-
i neutroni, che trasportano circa l’80% dell’energia prodotta, abbandonano il
plasma senza interazioni apprezzabili e vengono assorbiti dal “mantello” di
litio, posto intorno al nocciolo del reattore e utilizzato per la rigenerazione del
trizio. Il mantello di litio deve essere sufficientemente spesso (circa 1 m) per
assorbire i neutroni di fusione (di 14 MeV). Essi vanno quindi a riscaldare un
fluido e producono energia elettrica attraverso uno scambiatore di calore.
-
i nuclei di elio, più pesanti, rimangono intrappolati nel plasma e trasferiscono
ad esso la loro energia, ottenendo così l’autosostentamento della reazione senza
ulteriore riscaldamento dall’esterno.
Questo schema prefigura il futuro reattore termonucleare in cui la potenza liberata
nella reazione (energia per unità di tempo) sarà proporzionale alla densità dei nuclei
reagenti, alla probabilità che ha la reazione di verificarsi e alla temperatura del
plasma.
La ricerca sulla fusione termonucleare controllata ha avuto inizio alla fine degli anni
’50 ed, a partire dai primi anni ‘70, gli sforzi furono concentrati sulle macchine di
tipo tokamak, che dimostravano avere le proprietà di confinamento nettamente
migliori.
Nel corso di questi anni Europa, USA e Giappone hanno realizzato ciascuna una
grande macchina di tipo tokamak (JET2, TFTR, JT-60) e numerosi esperimenti nei
laboratori locali. L’insieme dei risultati prodotti da questi esperimenti ha portato alla
2
Joint Europen Tourus
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
20
conferma di molti aspetti del comportamento di un plasma confinato
magneticamente.
Nel 1987 fu presa la decisione di realizzare un tokamak che dimostrasse l’ignizione
termonucleare. Quattro partners (EU, USA, Giappone, URSS) diedero vita al
programma ITER (International Tokamak Experimental Reactor) il cui progetto finale
(Final Design Report FDR) fu varato nel 1998.
L’elevato costo di ITER (6.6 MLD €), le incertezze sulle prestazioni della macchina
e la quanto meno dubbia prospettiva reattoristica hanno però provocato un radicale
cambio di opinioni nella comunità fusionistica, in particolar modo in quella
americana. Nel 1999, il Congresso USA, anche su sollecitazione di una parte
influente ed autorevole della comunità scientifica, ha imposto la fuoriuscita dal
programma ITER dirottando gli interessi più verso l’aspetto scientifico che quello
tecnologico. La risposta degli altri partners è stata la presa d’atto dell’impossibilità
di realizzare ITER-FDR e quindi il rapido avvio della definizione di un nuovo
progetto (ITER-FEAT Fusion Energy Advanced Tokamak) di dimensioni leggermente
ridotte e costo circa dimezzato. Per questo nuovo progetto vengono abbandonati
alcuni obiettivi tecnologici e quello scientifico della piena ignizione, ma si
mantengono quelli dell’elevata moltiplicazione energetica e della esecuzione di
lunghi cicli di reazione (della durata di 10 minuti). I proponenti di ITER-FEAT
sollecitano già per il 2000 decisioni relative all’inserimento di questo progetto nel
prossimo Programma Quadro della EU. Nel frattempo Canada e Giappone hanno
manifestato interesse e propongono un sito per la realizzazione dell’impianto.
Parallelamente al progetto di costruzione di una macchina di grosse dimensioni,
ciascuna associazione nazionale dei paesi europei in accordo con l’EURATOM
procede allo svolgimento di programmi nazionali e collaborazioni internazionali
(JET, TORE SUPRA, ASDEX, FTU).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
21
1.6. IL FRASCATI TOKAMAK UPGRADE
Frascati Tokamak Upgrade
rientra nel programma dell’ Associazione ENEA-
EURATOM per la FUSIONE nel campo della fisica della fusione a confinamento
magnetico ed è attivo dal 1989.
FTU è un tokamak compatto ad alto campo magnetico costruito sulla linea dei
tokamak Alcator realizzati al MIT e del Frascati Tokamak (FT) di Frascati. I tokamak
compatti ad alto campo sono caratterizzati da elevati valori della densità elettrica:
j ∝ B / R
Con B campo magnetico toroidale ed R raggio maggiore del toro.
Nella tabella 1.2 sono riportate le caratteristiche essenziali di FTU paragonate a
quelle di altri tokamak:
FTU
JET
TORE SUPRA
ASDEX-U
B(Tesla)
8
3.5
4
2.5
R(m)
0.93
3
2.4
1.5
I(MAmp)
1.6
6
1.3
1.0
Tabella 1.2 – Caratteristiche essenziali di alcuni Tokamak.
La combinazione di grandi valori del campo magnetico e piccole dimensioni riesce
a produrre elevate densità di corrente che si riflettono su:
• Alta densità di potenza associata al riscaldamento ohmico (> 1MW/m3) .
• Alta densità delle particelle (1019 ÷ 3·1020 m-3). Infatti la densità di particelle in
un tokamak raggiunge un valore limite oltre al quale il plasma perde la sua
configurazione di equilibrio e disrompe. Empiricamente è stato trovato che
questo limite è direttamente proporzionale alla densità di corrente.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
22
• Bassa concentrazione delle impurezze dovuta all’alta densità del plasma che
riduce il libero cammino medio degli atomi rilasciati dalle pareti della camera da
vuoto
• In aggiunta l’elevata densità delle particelle consente lo studio su un ampio
intervallo di condizioni dei coefficienti di trasporto di plasmi ad elevata
collisionalità, in cui i processi d’urto costituiscono l’elemento essenziale per
stabilire l’equilibrio termico fra ioni ed elettroni. Quest’ultima è una delle
prerogative importanti per la realizzazione del reattore.
La camera da vuoto, a geometria toroidale, ha una sezione circolare, la presenza di
un limiter poloidale limita il raggio della colonna di plasma a 0.3 m. È presente
anche un limiter toroidale per proteggere la parte interna della camera.
A differenza di altri tokamak, FTU ha il trasformatore principale in aria, la corrente
di plasma viene indotta grazie alla variazione del flusso di campo magnetico
prodotto dalla variazione di corrente nel trasformatore. Questa risulta essere una
configurazione, per altro ereditata da FT,
molto efficiente dal punto di vista
dell’accoppiamento induttivo e relativamente a basso costo.
Su FTU è stato studiato il trasporto in regime ohmico per la determinazione di leggi
di scala dei processi di turbolenza nei plasmi. Confinare un plasma significa avere
un nucleo centrale caldo circondato da un bordo più freddo. Questa configurazione
può essere sostenuta solo se il plasma ha la capacità di trattenere il calore nella parte
centrale della colonna. Tale capacità può essere quantificata in termini del tempo di
confinamento dell’energia, che dà una stima del tempo di decadimento dell’energia del
plasma se la sorgente esterna viene spenta. Il confinamento dell’energia è il risultato
di meccanismi di turbolenza nel plasma, la cui corretta descrizione è ancora oggetto
di studi. Per descrivere il confinamento sia in condizioni di basso regime che in
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
23
quelli dei cosiddetti regimi avanzati (caratterizzati dalla formazione di barriere di
trasporto ai bordi), si usano degli approcci empirici basati sui dati sperimentali,
capaci di fornire leggi di scala per i tempi di confinamento. Al momento la legge di
scala che meglio descrive i bassi regimi è la ITER89-P, ottenuta usando i tokamak
con sistemi addizionali di riscaldamento. Il confronto con i tokamak con il solo
riscaldamento ohmico consente
una
validazione
indipendente
della legge di scala. FTU ha
contribuito alla validazione di
questa poiché esso ricopre un
range
di
configurazione
del
campo magnetico che non è
ricoperto da altri tokamak, come
mostrato nella figura 1.9 dove
sono inclusi per confronto anche
Figura 1.9 – Caratteristiche di FTU
i parametri del futuro reattore
ITER.
Su FTU vengono sperimentati tre sistemi di riscaldamento addizionale del plasma,
tutti basati sulla radiofrequenza. Il primo alla frequenza ibrida inferiore (Lower
Hybrid LH) di 8 GHz è costituito da 6 gyrotron che consentono di fornire una
potenza addizionale di circa 6 MW. Oltre a fornire potenza addizionale a frequenze
di eccitazioni caratteristiche del plasma, con questo sistema è possibile guidare
completamente la corrente di plasma (Current Drive). Il secondo, denominato Ions
Bernstein Wave (IBW), è caratterizzato da una frequenza di 433 MHz e da una
potenza di 600 KW e provvede direttamente al riscaldamento degli ioni. A
differenza di sistemi simili presenti su altri tokamak, IBW su FTU ha le strutture di
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 1 – Cenni sulla fusione nucleare
24
accoppiamento costituite da guide d’onda al posto delle antenne convenzionali
interne alla camera da vuoto. Con un tale sistema, in configurazioni di alto campo,
è possibile raggiungere i cosiddetti regimi di confinamento avanzati. Il terzo
sistema, denominato Electron Cyclotron Heating Radiofrequency (ECRH), è alla
frequenza ciclotronica elettronica di 140 GHz con 4 gyrotron di potenza totale di
1.6 MW. Questo sistema ha la caratteristica di depositare l’energia in regioni
localizzate del plasma. In questo modo è possibile depositare energia in regioni del
plasma caratterizzate da basse energia di trasporto.
Grazie alla enorme varietà dei sistemi addizionali a radiofrequenza presenti su FTU,
è possibile configurare esperimenti in cui vi sia sinergia fra i vari sistemi, in
particolare fra LH ed ECRH.
Oltre agli studi sui sistemi di riscaldamento, su FTU sono state realizzate importanti
campagne sperimentali sull’interazione plasma-parete, di rilevanza per il futuro
reattore a fusione. Il flusso di energia e particelle dal plasma interagisce con le pareti
della camera producendo atomi di impurezze che riducono il numero di reazioni di
fusione. La penetrazione di impurezze nel plasma può essere evitata con particolari
soluzioni tecnologiche. La prima fra tutte è la scelta del materiale della prima parete
della camera (quella che si interfaccia direttamente al plasma). I risultati ottenuti con
FTU hanno mostrato che l’uso di materiali con alto numero atomico quali il
Molibdeno
(Mo) ed il tungsteno (W) possono ridurre significativamente la
contaminazione del plasma.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
25
2
Capitolo
2. DESCRIZIONE DELL’IMPIANTO SPERIMENTALE
In questo capitolo verranno descritti i principali sistemi che
costituiscono l’impianto FTU, al fine di avere un’idea della
complessità del sistema e una conoscenza di base degli elementi che
caratterizzano l’esperimento.
Si procederà pertanto ad una descrizione schematica dell’impianto, dei
sistemi di diagnostica, di controllo e di acquisizione dati [15, 16, 17,
18, 19], concludendo con una panoramica delle operazioni
sperimentali.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
26
2.1. DESCRIZIONE DELL’IMPIANTO SPERIMENTALE
FTU è un impianto sperimentale per lo studio della fisica del confinamento
magnetico di plasmi rilevanti per un reattore. La macchina segue la linea dei
tokamak compatti ad alto campo magnetico quali ALCATOR-C e il Frascati
Tokamak.
Le grandezze caratteristiche di FTU sono riportate in tabella 2.1.
Raggio maggiore del toro
Raggio minore del toro
Campo magnetico toroidale
Corrente di plasma
Durata della scarica si plasma
Sezione trasversale del plasma
Energia erogabile dal generatore del magnete toroidale
Energia erogabile dal generatore del trasformatore e
degli avvolgimenti poloidali
Potenza addizionale complessiva dei sistemi a
radiofrequenza
0.935 m
0.3 m
8 Tesla
1.6 MA
1.5 s – 2 s
Circolare
160 MJ
200 MJ
~ 10 MW
Tabella 2.1 – Grandezze caratteristiche di FTU.
FTU può essere suddiviso in tre impianti principali:
Macchina : magnete toroidale, camera da vuoto, trasformatore, avvolgimenti
poloidali, sottoimpianti per il
vuoto, l’immissione gas, il condizionamento,
criogenici e sicurezze.
Alimentazione elettriche: i generatori del magnete toroidale (MFG1), i generatori
del trasformatore e degli avvolgimenti poloidali (MFG3), i sottoimpianti di
conversione DC (CV) e di commutazione (CZ).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
27
Radiofrequenza: impianti di riscaldamento addizionale alla frequenza ibrida
inferiore (LH), di onde ioniche di Bernstein (IBW) ed alla frequenza ciclotronica
elettronica (ECRH).
2.1.1.
LA MACCHINA
La macchina è costituita da una struttura di base formata da dei moduli che
assemblano un magnete toroidale e supportano camera da vuoto ed avvolgimenti
poloidali. L’intera struttura è racchiusa all’interno di un criostato che provvede,
durante le operazioni, a mantenere la macchina alla temperatura dell’azoto liquido.
Il magnete toroidale crea il campo magnetico toroidale coassiale con il plasma. È
costituito da dodici moduli ciascuno dei quali è formato da due avvolgimenti in
rame di sezione trapezoidale racchiusi da un telaio in acciaio inossidabile. Il rame ha
le migliori prestazioni alla temperatura dell’azoto liquido, ma la sua temperatura,
durante un impulso, giunge fino a 100 °C, pertanto le strutture, oltre ai normali
carichi elettrodinamici, vengono sottoposte a notevoli carichi termici. Per evitare il
raggiungimento di soglie critiche è quindi necessario che le differenze di
temperatura tra acciaio e rame siano costantemente monitorate.
La camera da vuoto deve contenere la colonna toroidale di plasma caldo prodotto
durante gli esperimenti della macchina. La componente poloidale del campo
magnetico fa si che il plasma venga mantenuto a distanza dalle pareti della camera,
e per evitare ogni possibile interazione con le pareti è installato anche un limiter
toroidale interno, che limita il raggio minore del plasma ad un valore sempre più
basso del raggio della camera. Il bordo del plasma ha temperature di qualche decina
di migliaia di gradi centigradi, molto più basse di quelle del centro, laddove si
raggiungono i milioni di gradi centigradi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
28
La camera da vuoto è stata progettata per soddisfare i seguenti requisiti:
• Provvedere alla realizzazione di buone condizioni di vuoto: pressioni di 10 –8
mbar, basse velocità di degassamento delle pareti : < 10-11 mbar ls-1cm-2. La
presenza di impurezze
nel plasma, in particolare dovute ad elementi con
elevato numero atomico, producono considerevoli perdite di potenza limitando
l’aumento di temperatura.
• Resistenza meccanica alla pressione atmosferica e alle forze prodotte
dall’interazione dei campi magnetici toroidali e poloidali con le correnti indotte
nella camera. Particolarmente dannose sono le situazioni prodotte dai collassi
della colonna di plasma (disruzioni).
• Elevata resistenza elettrica nella direzione toroidale per ridurre effetti di
cortocircuiti sul flusso della componente poloidale del campo magnetico
collegata con il plasma.
• Supportare elevati stress termici prodotti dalle rapide variazioni di
temperatura durante le scariche di plasma: a regime, ci sono circa 10 MW di
potenza immessa per alcune centinaia di millisecondi (8MW dal riscaldamento
addizionale a radiofrequenza più 2 MW dal riscaldamento ohmico).
• Provvedere un certo numero di porte di accesso per i sistemi di riscaldamento
addizionali e le diagnostiche.
La camera da vuoto risultante è quindi costituita da 12 settori toroidali connessi da
12 settori rigidi di differenti configurazioni. Questi permettono di avere 8 porte
equatoriali per le strutture di accoppiamento dei sistemi a radiofrequenza, più un
settore usato per il limiter poloidale. Le restanti porte di accesso equatoriali insieme
a 6 porte verticali sono disponibili per le diagnostiche del plasma.
La figura 2.1 mostra la camera da vuoto assemblata.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
29
Il materiale usato è un acciaio inossidabile
AISI 316 LN. Il volume totale della
camera, comprese le porte di accesso, è di
circa 2.5 m3 . Il vuoto è realizzato con un
sistema di 4 pompe turbomolecolari
distribuite su quattro porte equatoriali
con una velocità di pompaggio di 500 ls-1.
I sistemi di condizionamento prevedono
scariche di idrogeno o deuterio a bassa
potenza con correnti comprese fra i 2 e i
Figura 2.1 – Camera da vuoto.
10 kA per la durata di 20 ms in un campo
magnetico di 0.1 T alla frequenza di 1 Hz.
Sistemi a nastri riscaldatori sono installati intorno alle porte di accesso in modo da
rilasciare le impurezze intrappolate nelle pareti (degassamento) e successivamente
rimosse dai sistemi da vuoto. Il sistema di iniezione del gas è basato sul metodo del
gas puffing . Il sistema consiste di un insieme di 5 valvole piezo-elettriche veloci
controllate in remoto.
Su FTU sono installati quattro insiemi di avvolgimenti poloidali.
• Il trasformatore TR. Agisce come il primario di un trasformatore, che induce
il secondario rappresentato dalla colonna toroidale di plasma che ha una
resistività dell’ordine di 10-8 Ω. Provvede a controllare la corrente di plasma
durante la rampa di salita, durante la fase stazionaria e la fase di terminazione.
Inoltre provvede a fornire una tensione di 40 V sul giro toroidale per la
preionizzazione del plasma (breakdown). A differenza di altri tokamak, il
trasformatore è in aria.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
30
• L’avvolgimento V. Genera il campo magnetico verticale usato per assicurare la
condizione di equilibrio che ostacoli la naturale tendenza del plasma ad
espandersi e lungo il suo raggio maggiore, e lungo il suo raggio minore. La
configurazione degli avvolgimenti è stata progettata in maniera tale da avere
una sezione del plasma circolare.
• L’avvolgimento F. È usato per il controllo a feedback degli spostamenti radiali
del plasma.
• L’avvolgimento H. È usato per il controllo a feedback degli spostamenti
verticali del plasma.
I sistemi criogenici garantiscono che le condizioni di bassa temperatura della
macchina mantengano bassi i valori di resistività del rame degli avvolgimenti. Di
conseguenza le potenze impiegate per alimentare questi ultimi sono basse e le
temperature dopo le scariche di plasma rimangono entro valori accettabili.
Su FTU viene utilizzato un sistema di raffreddamento a circuito chiuso ad azoto
liquido (-196 °C), che viene fatto circolare negli avvolgimenti da un sistema di
pompe. Per mantenere la macchina a temperature così basse un criostato circonda
l’intera struttura (camera da vuoto e avvolgimenti). Fatto in pannelli, assemblati in
fibra di vetro e poliestere, è dotato degli
opportuni fori per le porte di accesso
equatoriali e verticali e le strutture di
supporto.
La figura 2.2 mostra una sezione 3D del
criostato.
Figura 2.2 – Sezione 3D del Criostato
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
31
Il criostato ha una leggera sovrapressione rispetto a quella atmosferica, realizzata
con azoto. Un separatore di fase permette una circolazione dell’azoto gassoso
cinque volte superiore a quella dell’azoto liquido. L’eccesso di azoto liquido è
recuperato dal separatore di fase.
2.1.2.
ALIMENTAZIONI ELETTRICHE
I grandi valori di picchi di potenza richiesti per alimentare il magnete toroidale, gli
avvolgimenti poloidali e i sistemi a radiofrequenza, per un totale di circa 400 MVA,
non possono essere estratti direttamente dalla rete elettrica pubblica della linea dei
150 kV che alimenta il centro di ricerche di Frascati. Due gruppi di generatori AC,
del tipo motore-volano-generatore, MFG1 ed MFG3 vengono usati per alimentare
i carichi.
Le caratteristiche elettriche del generatore MFG1 e del magnete toroidale sono
riportate nella tabella 2.2.
V = 2x3 kV (2 statori a connessione a stella)
P (picco) = 120 MW
E =150 MJ (ogni 4 minuti)
Numero di giri = 6000 rpm
Frequenza = 100 Hz
LTF = 136 mH
RTF = 16 mΩ (a –196 °C)
ITF (picco) = 37.1 kA (a 8 Tesla)
VTF (picco) = 3 kV
Tabella 2.2 a – Caratteristiche elettriche del genetatore
MFG1
Tabella 2.2 b – Caratteristiche elettriche del
magnete toroidale
L’alternatore è bipolare a rotore liscio; l’avvolgimento di statore è costituito da due
stelle trifasi sfasate elettricamente di 30°, indipendenti ed isolate tra di loro. Il
raddrizzatore è costituito da due ponti di Graetz a diodi, uno per ciascuna stella,
connessi in parallelo lato continua.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
32
I ponti provvedono alla rettificazione della tensione e della corrente di uscita i cui
valori sono rispettivamente di 4 kV e 36.5 kA.
Il tempo di salita della corrente può essere impostato, così come la fase stazionaria,
fino a 1.5 secondi. Un controllo a feedback della corrente permette di mantenere la
corrente nel magnete ai valori impostati. Al termine dell’impulso la corrente
magnetica viene fatta passare attraverso un resistore di 180 mΩ per ridurre la
dissipazione di energia negli avvolgimenti del magnete.
Per produrre i 25 kV richiesti necessari ad innescare il breakdown del plasma, viene
impiegato un sistema che commuta i 25 kA DC su un banco di resistori di valore
preprogrammato.
Gli avvolgimenti poloidali sono alimentati da MFG3.
Le principale caratteristiche elettriche di MFG3, dei quattro avvolgimenti poloidale
e dei relativi alimentatori DC sono riportate in tabella 2.3.
V = 16 kV
P (picco) = 250 MVA
E =200 MJ
Numero di giri = 3600
Frequenza = 50÷ 60 Hz
Tabella 2.2.a – Caratteristiche
elettriche del genetatore
MFG3
L
(mH)
TR 60.5
VF 33.5
F
4.6
H
46
LDT (mH)
14.5
12
1.4
-
Rtot
(mΩ a –196 °C)
15
9.7
8
64
Tabella 2.2.b – Caratteristiche elettriche
degli avvolgimenti poloidali
Vout
(kV)
±5
±2.5
±5
±1.5
Iout
(kA)
±25
±25
±12.5
±1.2
Tabella 2.2.c – Caratteristiche
elettriche degli alimentatori
I quattro avvolgimenti sono magneticamente disaccoppiati da un trasformatore DT
esterno alla macchina. Questo permette di non dissipare grandi quantità di potenza
in special modo nei sistemi di feedback.
Gli avvolgimenti poloidali vengono alimentati attraverso 4 sistemi di conversione
basati su ponti dodecafase totalmente controllati a tristori, tre sono alimentati da
MFG3 (TR, V, F) e uno (H) dalla rete 20kV dell’ENEL.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
2.1.3.
33
RADIOFREQUENZA
La realizzazione del confinamento ad alte densità e temperature, nel range 5÷8 keV,
non è raggiungibile con il solo riscaldamento ohmico. Il riscaldamento addizionale
del plasma in FTU è
prevalentemente realizzato accoppiando potenza a
radiofrequenza al plasma, attraverso l’interazione con onde elettromagnetiche
iniettate nella camera da appropriati sistemi d’antenna e da lanciatori ottici. Infatti a
causa, sia della struttura compatta del magnete, che rende impossibile la
penetrazione di particelle a grossi angoli rispetto alla direzione radiale, sia delle alte
densità di lavoro (fino a 3·1020 m-3), non è indicato il metodo di riscaldamento per
iniezione di particelle.
I principali sistemi a radiofrequenza attualmente attivi su FTU sono:
• onde ioniche di Bernstein (Ions Bernstein Waves)
• ibrida inferiore (Lower Hybrid)
• elettronica ciclotronica (Electron Cyclotron Radiofrequency Heating)
Le principali caratteristiche dei tre sistemi sono riportate in tab.2.7.
Schematicamente un impianto a radiofrequenza è costituito dai seguenti sistemi:
• Generatore RF ad alta potenza. I sistemi LH ed ECRH utilizzano gyrotron
per la produzione delle microonde da lanciare nel plasma, mentre IBW utilizza
3 klystron da 600 kW ciascuno. Generalmente le sorgenti di radiofrequenza
sono costituite da cavità a microonde dove un fascio di elettroni prodotti da un
catodo interagiscono con un campo magnetico longitudinale variabile con una
frequenza di risonanza corrispondente a quella ciclotronica elettronica.
L’interazione del fascio con il campo magnetico eccita la cavità producendo
onde elettromagnetiche di frequenza caratteristica.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
34
• Strutture di accoppiamento. Le strutture di accoppiamento sono diverse per i
tre sistemi a radiofrequenza. IBW ed LH hanno una struttura di antenne
costituite da un insieme di guide d’onda rettangolari. In figura 2.4 riportiamo
una tipica antenna di LH costituita da 12x4 finestre rettangolari ciascuna delle
quali può fornire un impulso RF della potenza di 600 kW.
Figura 2.4 – Antenna LH.
Diverso è invece il sistema di lancio della potenza RF nel caso di ECRH. Infatti
considerate le elevate frequenze dell’impulso, un sistema ottico costituito da
specchi orientabili in maniera remota, permette di lanciare il fascio di
microonde nel plasma.
• Guide d’onda per la trasmissione di microonde ad alta potenza. La
potenza RF deve essere trasmessa dai generatori al plasma su una distanza di
circa 40-50 m. A tale scopo un sistema di guide d’onda è stato opportunamente
progettato per ottenere la più bassa attenuazione possibile. Nel caso dei
gyrotron da 1 MW di LH le linee di trasmissione sono costituite da guide
d’onda circolari che trasmettono il modo TE01 che producono un’attenuazione
di 0.2 dB/100 m. Alla fine della linea è installato un convertitore al modo TE01
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
necessario per l’accoppiamento con l’antenna.
35
Uno schema delle linee di
trasmissione per LH è riportato in figura 2.5.
Figura 2.5 – Linea di trasmissione per LH.
•
Generatore di tensione ad alta potenza (HVPS), modulatori e
protezioni. Tutti i sistemi a RF sono alimentati da generatori di tensione ad
alta potenza. Questi sono costituiti da un trasformatore 20 kV/500 V connesso
alla rete elettrica pubblica, da un sistema di regolazione della tensione a tristori
per LH e a tetrodi per ECRH. Il sistema di modulazione della tensione di
anodo dei generatori e un unità di protezione (crowbar) di quest’ultimi contro
la generazione di archi interni.
La figura 2.6 mostra lo schema a blocchi generale dell’impianto RF.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
36
RF
TRASMISSION
LINE
GYROTRON
#1
GUN-ANODE
HVPS
CROWBAR
RF
COUPLING
STRUCTURE
FTU
PLASMA
MOD & REG
RF
TRASMISSION
LINE
GYROTRON
#2
RF
COUPLING
STRUCTURE
GUN-ANODE
MOD & REG
Figura 2.6 – Impianto RF
Onde ioniche di
Bernstein
1.8 MW
Ibrida inferiore
6 MW
Ciclotronica
elettronica
1.6 MW
Frequency
433 MHz
8 GHz
140 GHz
Source
klystron
gyrotron
gyrotron
Source power
600 kW
1 MW
400 kW
n° of sources
3
6
4
2 rectangular
waveguide array
Grill
(12 x 4
rectangular
waveguide array)
1s
optical
Total output power
Coupling structure
Pulse length
1s
Tabella 2.7 – Grandezze caratteristiche dell’impianto RF.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
0.5 s
Cap. 2 – Descrizione di FTU
37
2.2. DIAGNOSTICHE
Un elevato numero di sistemi diagnostici sono usati su FTU per misurare le
grandezze caratteristiche del plasma. Per questo la macchina è dotata di numerose
porte di accesso suddivise in 6 porte a T, 6 porte orizzontali, 12 fori passanti
verticali e 4 piccoli accessi orientati a circa 20° rispetto alla direzione radiale. Poiché
FTU è un tokamak compatto, l’area di ciascuna porta di accesso è relativamente
piccola e lontana dal plasma, anche per evitare eventuali disturbi sulle elettroniche
delle diagnostiche dovuti ad eventuali flussi di neutroni.
Le diagnostiche di FTU possono essere sinteticamente suddivise in:
Campo magnetico: quantità fisiche integrali. Alcune come la tensione di giro, il
flusso del campo toroidale e verticale, la corrente di plasma, sono misurate da
sonde V-loop, sonde magnetiche e da spire Rogowski. Tutte le sonde sono installate
all’esterno della camera da vuoto sulla superficie toroidale. La caratterizzazione
delle
superficie
magnetiche
avviene attraverso le misure
standard del flusso magnetico
poloidale ψ =2· π ·r·A φ e della
sua
componente
normale
∂ψ / ∂ n sul contorno toroidale.
Queste,
condizioni
costituiscono
al
contorno
le
di
Cauchy per un problema tipico
Figura 2.7 – Sezione della camera da vuoto.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
38
di magnetostatica, la cui soluzione permette di definire il contorno del plasma.
La figura 2.7 mostra una sezione della camera da vuoto con le sonde installate.
Densità del plasma: misure interferometriche nell’infrarosso lontano consentono
di misurare la densità elettronica del plasma lungo un profilo lineare. Il profilo
medio di densità, lungo una linea, è misurato rilevando lo sfasamento tra due onde
elettromagnetiche di cui una attraversa il plasma. Poiché la densità programmata di
FTU è dell’ordine di 1019 ÷ 3·1020 m-3, solo le lunghezze d’onda dell’infrarosso
lontano possono consentire la determinazione dell’indice di rifrazione del plasma
che a sua volta è legato alla densità. Il sistema è costituito da 2 laser molecolari che
possono operare alle lunghezze d’onda di 337 mm (HCN), 194 mm (DCN) o a 119
mm (H2O) a secondo del gas usato nella scarica. L’ottica dell’interferometro,
normalmente denominato DCN, è montata su una struttura che riduce le
vibrazioni meccaniche in modo da non influenzare la misura. I fasci laser sono
indirizzati verso un sistema ottico che li divide in cinque segnali che attraversano 5
corde della sezione trasversale della colonna di plasma. Il sistema ottico è costituito
da circa 200 elementi controllati remotamente.
Temperatura elettronica: le principali diagnostiche per la misura elettronica del
plasma sono il Thomson Scattering (TS) e L’Electron Cyclotron Emission (ECE).
La prima permette di misurare la temperatura elettronica T e e la densità elettronica
n e sulla base della sezione d’urto Thomson determinata dalla teoria classica della
diffusione di onde elettromagnetiche su elettroni liberi. Un fascio laser a neodimio
viene focalizzato nel plasma, la luce diffusa viene raccolta da un’ottica ed inviata a
19 policromatori, ognuno corrispondente ad una posizione spaziale nel plasma con
una risoluzione di 2 cm nella regione centrale e di 4 cm al bordo. Il laser spara 10
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
39
volte nel plasma. Ragion per cui durante una scarica si possono ottenere 10 profili
di temperatura e di densità.
La seconda diagnostica è basata sull’emissione di radiazione da parte degli elettroni
nel loro moto ciclotronico intorno alle linee di campo magnetico. La radiazione
viene emessa alla frequenza ciclotronica elettronica.
La misura dello spettro di emissione di ciclotrone elettronica consente di ottenere
informazioni spazialmente localizzate sulla temperatura elettronica assoluta del
plasma ed in certi casi sulla densità. Su FTU questa misura si effettua con un
interferometro di Michelson a polarizzazione. I dati acquisiti necessitano di una
elaborazione per ottenerne le grandezze fisiche di plasma significative. La
diagnostica è composta di un’antenna equatoriale che raccoglie la radiazione, un
sistema quasi-ottico che la seleziona e l’interferometro vero e proprio. Tutte le
grandezze misurate sono quindi riferite all’asse equatoriale. La risoluzione spaziale
dello strumento è migliore di ±2 cm nelle tre direzioni. La risoluzione temporale è 5
ms, ed è determinata dal tempo necessario al Michelson per effettuare una
fotografia dello spettro. Oltre all’interferometro di Michelson, l’emissione di
ciclotrone elettronica alla seconda armonica modo straordinario, che è
proporzionale alla temperatura degli elettroni, viene misurata da un interferometro
a policromatore. Grazie alla variazione 1/R del campo di vuoto, elettroni a diverso
R emettono a frequenza diverse ed è quindi possibile separarli. Il policromatore
ECP misura l’intensità a 12 differenti frequenze fissate per ogni sparo e fornisce
l’evoluzione temporale della temperatura elettronica a 12 diversi raggi maggiori del
plasma.
Temperatura ionica: viene misurata rilevando il flusso dei neutroni o l’energia
delle particelle neutre di idrogeno e deuterio che lasciano il plasma. Le misure
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
40
neutroniche su FTU determinano il numero totale di neutroni (resa neutronica: Yn)
emessi in una scarica di plasma. Combinando questo dato con la misura della
densità elettronica n e , per esempio dal DCN, è anche possibile ottenere la
temperatura ionica. La variazione temporale dei segnali neutronici può anche
fornire informazioni su fenomeni di trasporto, instabilità del plasma, etc. Le
diagnostiche neutroniche su FTU consistono di 4 differenti sistemi di rilevazione:
camere proporzionali a BF3 e scintillatori per la misura della resa neutronica
assoluta in funzione del tempo come monitor delle fluttuazioni veloci; camere a
fissione per la misura integrale della resa neutronica e multicollimatore per una
misura spazio-temporale della resa neutronica. A causa della presenza delle strutture
(camere da vuoto, magnete toroidale, avvolgimento poloidali, etc.) lo spettro
energetico dei neutroni emessi è molto ampio. I valori aspettati della resa
neutronica sono dell’ordine di 1014 ns-1.
Un altro metodo per misurare la temperatura ionica è basato sul rilevamento di
particelle neutre veloci che lasciano il plasma dopo processi di ricombinazione ionielettroni. Su FTU è installato un analizzatore di neutri multicanale in massa e
velocità con la possibilità di fare scansioni su differenti corde della sezione circolare
del plasma.
Vi è anche uno spettrometro a cristalli per la rilevazione di raggi X che misura lo
slargamento Doppler di linee di emissione dovute a impurezze del plasma. Tale
misura consente di definire la distribuzione spaziale della temperatura ionica.
Perdite di radiazione: sono dovute principalmente alla presenza di impurezze
quali ossigeno, carbonio e metalli, tutte introdotte dall’interazione del plasma con le
pareti della camera. Pertanto un plasma emette sia radiazione con uno spettro
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
41
continuo, dal visibile alla regione dei raggi X, sia righe di emissione a lunghezze
d’onda caratteristiche.
Le diagnostiche interessate sono sia misure della radiazione emessa su un’intera
regione di lunghezze d’onda, sia di tipo spettroscopico.
Le prime sono fatte con array di bolometri e con array di diodi sensibili ai raggi X.
Un bolometro misura la potenza radiativa emessa dal plasma attraverso il
riscaldamento di un film sottile. Il tempo di risposta di questi sensori è
generalmente molto lento (dell’ordine dei ms). Un’array di bolometri a 16 canali,
assemblati in una camera pin-hole, è installato su una porta equatoriale per misurare
le perdite di radiazione sul range di lunghezze d’onda di λ=0.1-200 nm dove lo
spettro è piatto. La risoluzione spaziale è di 2 cm, mentre quella temporale è di 10
ms. L’array ricopre l’intero raggio del plasma. I dati misurati sono elaborati usando
un filtro numerico per la ricostruzione del segnale fornendo la potenza radiativa
assorbita dal sensore. Attraverso questa misura è possibile eseguire analisi di
bilancio di potenza del plasma.
I Raggi X molli sono rilevati da un’array di diodi e consentono di avere
un’immagine tomografica della sezione circolare del plasma. La loro misura
consente di analizzare le instabilità magnetoidrodinamiche.
I Raggi X duri sono rilevati da un insieme di scintillatori e fotomoltiplicatori. Lo
spettro di energia di queste emissioni consentono di avere informazioni su processi
che riguardano la produzione di elettroni altamente energetici.
Le misure spettroscopiche ricoprono l’intero range spettrale dall’ultravioletto al
visibile.
La spettroscopia Ultravioletta è eseguita con uno spettrometro da vuoto
(McPherson) ad incidenza radente e campo piano per la regione spettrale 100 e
1700 nm. Non esistendo elementi ottici trasparenti in questa regione spettrale lo
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
42
spettrometro lavora in contatto di vuoto con la sorgente e la focalizzazione delle
fenditure è ottenuta grazie all’impiego di reticoli di dispersione toroidali. Il basso
livello di aberrazioni ottenuto sul piano di uscita permette l’utilizzo di rivelatori
estesi per l’osservazione simultanea di tutto lo spettro. Lo strumento può utilizzare
due reticoli con diversa dispersione intercambiabili manualmente senza
interrompere il vuoto. Il rivelatore è composto da un intensificatore di immagine a
MicroChannelPlate accoppiato otticamente ad un PDA (PhotoDiode Array) composto
di 1024 diodi che si caricano a seconda dell’intensità del segnale e vengono poi letti
sequenzialmente (tipicamente alla velocità di 16 msec/pixel. È
possibile
programmare il rivelatore per tempi di scansione maggiori (aumentando il tempo
che intercorre tra due spettri) o minori (tralasciando la acquisizione dei pixels non
di interesse). Il modo di operazione tipico prevede un tempo di scansione di 20
msec.
La misura dell’emissione di radiazione di Bremmstrahalung nel visibile (acquisita a 540
nm, regione in cui non si evidenziano altre componenti di emissione) consente di
ottenere informazioni relativamente alla carica efficace (Z EF F ) del plasma. Su FTU
questa misura si effettua con l’ausilio di due fotocamere Nikon che focalizzano su
un array di 12 fibre ottiche ciascuna, l’emissione di luce di plasma. Entrambi gli
array sono posizionati su una stessa porta di accesso. Le fibre ottiche di ogni array
sono collegate ognuna ad un fotomoltiplicatore, che a sua volta è collegato a dei
moduli ADC per l’acquisizione dei dati. Le 12 linee di vista di ogni array spazzano
una sezione poloidale del plasma con una apertura angolare tra la prima e l’ultima di
circa 28°; l’asse ottico del sistema è inclinato di qualche grado rispetto alla verticale
(nel caso dell’array verticale) e rispetto al piano equatoriale (per l’array orizzontale);
la sezione della linea di vista della fibra è di circa 2 cm a due metri circa dal fuoco
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
43
della fotocamera. La misura effettuata è l’integrale dell’emissività del plasma su tutta
la linea di vista. La risoluzione temporale è di 0.5 msec.
La densità delle particelle neutre al bordo, può essere misurata dal valore assoluto
della linea di emissione α dell’idrogeno (Hα ). La misura di intensità degli Hα
permette di analizzare fenomeni di ricombinazione durante la fase di
preionizzazione del plasma (breakdown). I monitors Hα sono installati lungo la
direzione toroidale e lungo la direzione poloidale, questo per caratterizzare la forte
asimmetria del fenomeno.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
44
2.3. CONTROLLO E SUPERVISIONE
Quando il progetto FTU partì oltre 10 anni fa, la realtà dell’Information Technology era
molto differente da quella odierna. Pertanto a quel tempo venne sviluppato un
sistema ‘ad hoc’ per il controllo e la supervisione degli impianti da parte
dell’industria nazionale. Dopo alcuni anni di relativo funzionamento, venne deciso
nel 1994 di sostituirlo con un nuovo sistema basato su tecnologie hardware e
software di tipo commerciale. Le linee guida di questo nuovo sviluppo si basavano
su concetti quali: sistemi di elaborazioni con processori RISC, sistema operativo
UNIX, trasmissione dati su rete locale basata su TCP/IP, linguaggi di
programmazione C/C++, interfacce grafiche basate su X-window.
Essendo FTU un tokamak pulsato, il sistema di controllo in questi tipi di macchine
deve sostanzialmente gestire due regimi: un regime in cui gli impianti sono in standby ed un regime sperimentale in cui viene prodotta la scarica di plasma.
Quando la sperimentazione è temporaneamente sospesa (durante la notte, i fine
settimana e i fermi per manutenzione) il tokamak è in stand-by. In questo stato il
sistema di controllo deve garantire che gli impianti criogenici e quelli del vuoto
funzionino regolarmente. Durante questo regime il monitoraggio degli impianti
deve essere disponibile attraverso l’acquisizione lenta (1 s) di dati e visualizzata su
sinottici (mimici).
Durante il regime di sperimentazione, scariche di plasma vengono prodotte per
circa 1 s ogni 20-30 min. Quindi una volta che le operazioni di configurazione degli
impianti vengono completate, il sistema di controllo predispone una sequenza di
attività prima e dopo la scarica. Queste, a causa della complessità dell’impianto,
sono numerose e possono coinvolgere più sottoimpianti contemporaneamente
attraverso sequenze di comandi. Questi ultimi sono poi riconfigurabili in base alle
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
45
caratteristiche della scarica programmata. In un intorno temporale (20 s) della
scarica di plasma, gli impianti sono controllati in maniera hardware da una sequenza
di controllo veloce (FSC) [21].
L’attuale architettura del sistema di controllo, soprannominato PROMETEO, è
quella tipica a tre livelli:
• I livello. È basato su PLC (Programmable Logic Controller), per il controllo a
campo degli impianti. Tutti i sottoimpianti di FTU sono controllati da PLC
indipendenti.
• II livello. È costituito da unità concentratori basati su CPU VME con sistema
operativo OS9. Vi sono tre concentratori, uno per ciascun impianto: Macchina,
Alimentazioni e Radiofrequenza. I concentratori provvedono a gestire il
colloquio con i vari PLC attraverso un’interrogazione a polling e a trasmettere i
comandi emessi dal livello superiore. Attraverso le unità concentratori è fossile
avere la descrizione dello stato degli impianti e solo le variazioni a campo
vengono trasmesse al livello superiore.
• III livello. È il livello in cui viene gestito il database real-time dell’impianto e
viene eseguita la supervisione attraverso l’interfaccia uomo-macchina (mimici).
Esso si basa su una LAN composta attualmente da:
-
3 nodi Digital ALPHA (DEC 3000) con Sistema Operativo Digital UNIX
-
1 nodo Digital VAX (DEC 4000) con Sistema Operativo VMS
-
circa 20 Xterminals o computers in emulazione X ( consoles di operatore).
Sui nodi Unix è installato il database real-time ed i principali processi di
comunicazione con i PLC e di archiviazione delle misure storiche dell’impianto. Il
database dell’impianto è costruito intorno al pacchetto software commerciale Digital
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
46
BASEstar Open. Utilizzato nel settore dell’automazione industriale, Basestar è un
database distribuito basato su oggetti raggruppati in domini. Gli oggetti principali
sono:
-
data-point: associati ai punti di campo rappresentano lo stato dell’impianto
-
trigger: per la generazione automatica di variazioni di stato
-
enbox: per la notifica degli eventi.
events: per la gestione degli eventi (allarmi)
Accanto a questi è possibile integrare all’interno di Basestar applicazioni esterne
attraverso la definizione di oggetti activities. Numerose activities sono state scritte (in
C++ e CIMFAST, un linguaggio interprete di Basestar), per manipolare
l’acquisizione e il monitoraggio real-time automatico (Bridges, processi di colloquio
con i PLC), per l’esecuzione di sequenze di comandi e per la gestione di comandi
asincroni (Dispatcher).
Mimic
Process
Command
language
interpeter
BASESTAR
Sequence
Command
Manager
Bridge
tx
Camac
Crate
Camac
handler
Dispatcher
Bridge
rx
Figura 2.8 – Interazione dei sistemi durante l’esperimento.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Vme
trx
PLCs
Vme
tx
La
Cap. 2 – Descrizione di FTU
47
figura 2.8 mostra il diagramma del flusso dei dati tra una sequenza di comandi e la
loro trasmissione a campo.
La gestione degli allarmi e dell’archiviazione di misure storiche segue lo stesso
meccanismo.
Le activities usano eventi per acquisire le variazioni dei segnali di impianto o per
gestire le comunicazioni tra le varie activities stesse. Grazie alla caratteristica di
applicazione distribuita di Basestar è possibile bilanciare il carico di lavoro
costituito dai processi del database e da quelli esterni, su più nodi.
La tabella 2.8 mostra le dimensioni caratteristiche dell’attuale database del sistema
di controllo.
Nodi server
3
Domini
7
Sottodomini
30
Data-points
8000
Events
4000
Triggers
7000
Activities
25
Tabella 2.8 – Dimensioni caratteristiche del database del sistema di controllo.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
48
Attualmente il nodo Vax gestisce il bus CAMAC per l’acquisizione dei dati (DAS)
delle diagnostiche e per l’elettronica di temporizzazione dell’esperimento costituita
da clocks e gates. Il controllo veloce, sequenziale e temporizzato degli impianti
durante l’esperimento di fusione è pre-programmato ed eseguito dal sottosistema
Fast Sequence Controller (FSC), mentre l’acquisizione veloce delle misure
“ingegneristiche” è affidato al sottosistema Fast Data Acquisition (FDA). Entrambi i
sottosistemi sono realizzati con lo standard CAMAC. Il controllo della posizione
del plasma è eseguito da un sistema di feedback basato su CPU VME con sistema
operativo real-time Lynx-OS. Questi tre sistemi verranno trattati successivamente.
La parte di Man-Machine-Interface è composta da circa 25 Famiglie di Mimici
interattivi (realizzati con i software grafici Digital-BGE e SL-GMS) visualizzabili su
circa 20 Xterminals o emulatori, costituenti le consoles di operatore.
FTU è costituita da numerosi impianti o sottoimpianti dislocati fisicamente in vari
locali di un’area abbastanza vasta del C.R. ENEA di Frascati. Il nucleo centrale del
Sistema di Controllo e Acquisizione Dati , costituito da numerosi calcolatori e
dispositivi (clocks e generatori di gates), è invece centralizzato nella Sala Calcolatori.
Questa dislocazione geografica degli apparati, impone collegamenti a distanza, per
lo scambio dei dati e segnali, tra il nucleo centrale del Sistema di Controllo e tutte
quelle apparecchiature periferiche che sovraintendono al comando e controllo dei
singoli sottoimpianti di FTU (PLC, FSC, FDA, clock e gates etc.). Pertanto la Rete
di Trasmissione Dati e Segnali o RTDS costituisce proprio tutto il complesso di
cavi elettrici, fibre ottiche e apparecchiature speciali (MUX ottici, CAMAC etc.),
necessari ai collegamenti tra il nucleo centrale del sistema di controllo e le
apparecchiature periferiche di FTU.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
49
La RTDS comprende solo i collegamenti speciali non di tipo ethernet, e viene
generalmente suddivisa nei seguenti sottosistemi , ciascuno dei quali rappresenta un
collegamento dedicato e separato:
-
Sottosistema Collegamenti dei PLC degli Impianti di FTU;
-
Sottosistema Collegamenti FSC (CAMAC Fast Sequence Controller);
-
Sottosistema Distribuzione segnali Clock & Gates (CGD);
-
Sottosistema Distribuzione segnali Video e Audio (Monitors Broadcast);
-
Sottosistema Collegamenti Secondari.
Sottosistema Collegamenti FDA (CAMAC Fast Data Acquisition);
2.3.1.
LA SEQUENZA DI CONTROLLO VELOCE (FSC3)
FSC provvede a fornire durante uno sparo di FTU una sequenza sincronizzata di
comandi veloci da fornire agli impianti interessati. L’unità temporale è dell’ordine
dei ms. Le principali caratteristiche di FSC sono:
-
La generazione di una sequenza preprogrammata di comandi con una
risoluzione temporale di 1 ms.
-
Una lunghezza massima della sequenza di comandi di 166 secondi.
-
Una verifica continua degli stati aspettati degli impianti.
-
Il rilevamento di allarmi sugli impianti interessati.
-
La capacità di iniziare una sequenza di recupero una volta rilevato un allarme
sugli impianti.
3
-
Programmabilità e generazione di forme d’onda di riferimento.
-
Capacità di guidare fino ad 8 sequenze indipendenti.
Fast Sequence Control
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
50
-
Possibilità di sincronizzazione fra differenti unità FSC.
-
Rilevamento real-time di crash.
-
Registrazione degli eventi per analisi off-line.
L’hardware di un’unità FSC è costituito da moduli CAMAC commerciali e da
elettronica dedicata (figura 2.9). I principali moduli CAMAC impiegati sono:
generatori di funzione, registratori di eventi, buffer di memoria, moduli di
temporizzazione nonché moduli di generazione di sequenze di comandi, di
sequenze di stati aspettati e di sequenze di recupero.
L’elettronica dedicata esegue il confronto fra gli stati aspettati e quelli reali ed inizia
la sequenza di recupero qualora venga rilevato un allarme.
Figura 2.9 – Modulo di acquisizione CAMAC
per FSC.
Figura 2.10 – Modulo di acquisizione CAMAC
per FDA.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
2.3.2.
51
L’ACQUISIZIONE DATI VELOCE (FDA4)
Il sistema consente di acquisire le misure prevalentemente di tipo elettrico legate
alla macchina. Tutti i sistemi che appartengono a FDA sono costituite da unità
standard basate su bus CAMAC (figura 2.10). Queste unità costituite da moduli
ADC hanno frequenze di campionamento di 1 kHz e 4 kbyte di memoria locale,
consentendo di registrare eventi per una durata di 4 s.
FDA supporta l’acquisizione simultanea di più di 200 segnali e i processi di
acquisizione sono gestiti dal nodo VAX a cui è collegato tramite un collegamento
in fibre ottiche.
2.3.3.
IL SISTEMA DI FEEDBACK
La configurazione di equilibrio di un plasma confinato magneticamente all’interno
di una struttura passiva è generalmente instabile. Inoltre la presenza di sistemi di
riscaldamento addizionale, che iniettano onde elettromagnetiche, accentua
ulteriormente queste instabilità. Pertanto sono necessari sistemi di controllo della
posizione del plasma che evitino il verificarsi di distruzioni, le quali possono col
tempo danneggiare la camera da vuoto. Grazie alla sua sezione circolare FTU non
presenta instabilità verticali, ma fenomeni di spostamento radiale della colonna di
plasma si presentano con tempi dell’ordine di 1 ms.
Su FTU si intende sistema di feedback l’intero apparato che va dalle misure della
posizione del plasma, al calcolo dell’algoritmo di controllo, alla generazione dei
riferimenti corretti inviati ai generatori degli avvolgimenti poloidali.
Il sistema di feedback è costituito dai seguenti sottosistemi [22, 23]:
4
Fast Data Acquisition
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
52
• MMS (Magnetic Measurement System): sistema di misure magnetiche che esegue le
seguenti funzioni:
-
Acquisizione di 36 misure magnetiche.
-
Elaborazione delle misure magnetiche per ottenere un espansione
multipolare del campo magnetico in coordinate toroidali.
-
Calcolo della posizione del plasma sulla base dell’ultima superficie
magnetica.
-
Calcolo dell’errore del flusso magnetico verticale e orizzontale rispetto a
quello pre-programmato.
-
Trasmissione dell’errore al secondo sottosistema.
• PPCRS (Position and Plasma Current Regulation System): sistema di regolazione
della corrente e della posizione del plasma. Esso esegue le seguenti funzioni:
-
acquisire le misure di corrente di plasma.
acquisire dal MMS gli spostamenti della posizione del plasma rispetto ad un
valore pre-programmato.
-
controllare la posizione e la corrente del plasma attraverso 4 PID
(Proportional Integretor Derivator) che producono i riferimenti per gli
avvolgimenti poloidali TR, F, H,V.
Il sistema è basato su una CPU VME powerPC a 300 MHz, da 3 moduli ADC
veloci a 16 canali con una frequenza di massima di campionamento di 500 kHz e da
un modulo DAC (Digital Analog Converter) per la generazione di riferimenti. L’intero
ciclo di controllo è attualmente dell’ordine dei 100 µsec.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
53
2.4. ACQUISIZIONI DATI
Il sistema di acquisizione dati (DAS5) di FTU provvede a gestire in maniera
standard le misure rilevate dalle varie diagnostiche installate. FTU è una macchina
sulla quale insistono molte diagnostiche, ovvero molti (dell’ordine di alcune
migliaia) segnali di misura. Come nella totalità dei laboratori di ricerca di una certa
dimensione, di fronte a questa massa di segnali e quindi di dati, inizialmente venne
definito uno standard per il punto in cui il segnale da analogico doveva essere
trasformato in digitale e quindi acquisito dai calcolatori di archiviazione e di analisi
dei dati: il CAMAC. Questi è un bus standard di comunicazione veloce dei dati
organizzato in clusters di moduli (crates) gestiti ciascuno da un controller dislocati in
una configurazione ad anello chiuso (loop).
Attualmente questo standard comincia a mostrare la sua età essenzialmente perché
non consente di ospitare intelligenze locali (o comunque non esiste una soluzione
standard a questo problema). Questo costringe a scaricare tutti i dati dalle memorie
dei moduli a campo nelle memorie dei calcolatori prima di poter avviare qualunque
analisi dei segnali. In alcuni ambiti di ricerca questa limitazione viene oggi vissuta
come intollerabile. Difatti, in alcuni casi gli eventi di interesse si producono ad
istanti impredicibili ed il sistema di acquisizione deve essere sempre attivo per poter
acquisire dati. Questi devono però essere filtrati prima di essere memorizzati su
disco e magari su nastro, per evitare di avere un archivio di segnali inutili. Nel caso
della sperimentazione dei tokamak (sperimentazione ‘pulsata’) il problema è molto
meno stringente perché la finestra temporale utile per l’acquisizione coincide con
quella della scarica, quindi lo sperimentatore sa quando acquisire e in quell’ambito
5
Data Acquisition System
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
54
temporale tutti i dati sono buoni.
In definitiva, quel che si fa è immagazzinare i segnali nelle memorie dei moduli
durante la scarica, quindi prelevarli con calma successivamente.
Attualmente il DAS di FTU è caratterizzato da un’architettura centralizzata basata
su un calcolatore VAX 4000 con sistema operativo VMS. Su di esso sono installati
i drivers seriali per il controllo della loop CAMAC. Il calcolatore centrale provvede:
-
a configurare i parametri di acquisizione dei moduli CAMAC;
-
ad organizzare le misure da acquisire in canali software con eventuali parametri
di post-elaborazioni;
-
ad inizializzare, prima dello sparo, i moduli CAMAC con l’azzeramento delle
memorie locali e la predisposizione all’acquisizione su triggers esterni;
-
a scaricare, dopo lo sparo, le memorie locali dei moduli CAMAC nelle aree di
memoria del calcolatore centrale;
-
ad archiviare in un file (pulse file) l’insieme dei canali software acquisiti.
Il meccanismo di sincronizzazione dei moduli è assicurato da un insieme di gates
distribuiti da un link ottico, mentre la temporizzazione è stabilita da un clock
principale (Master Clock) distribuito otticamente a tutti i controllers dei crates
CAMAC.
Ogni qualvolta il DAS su VAX crea un canale software relativo ad una misura,
questi viene anche inviato ad un server su UNIX che provvede ad archiviarlo e a
renderlo immediatamente disponibile per l’analisi dei dati qualche minuto dopo lo
sparo.
Come già detto questa architettura centralizzata basata sullo standard CAMAC sta
evolvendo verso un’architettura distribuita di sistemi di acquisizione eterogenei
(CPU-RISC/VME, Pentium/PCI) dotati di proprie capacità di elaborazione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
55
La figura 2.11 mostra lo schema a blocchi dell’architettura fisica dell’attuale DAS di
FTU.
Server Unix
ethernet
Vax
Crate
Crate
Camac
loop
Crate
Crate
Crate
Figura 2.11 – Architettura del DAS.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
56
2.5. SPERIMENTAZIONE SU FTU
La scarica di plasma viene generata all’interno della camera da vuoto attraverso una
sequenza operativa denominata “sparo”. Una sequenza di sparo ha una durata
variabile fra i 10 e i 20 minuti a seconda degli impianti coinvolti. Circa 30 spari
vengono eseguiti durante una giornata sperimentale di FTU
Nelle varie sessioni sperimentali sono presenti nella sala controllo (figura 2.12) delle
figure professionali che rivestono ruoli caratteristici all’interno dell’esperimento.
Figura 2.12 – Sala controllo.
All’inizio di ogni giornata sperimentale viene eseguita una scarica di prova per
verificare se gli impianti di macchina, alimentazione, il sistema di controllo e di
acquisizione dati, siano perfettamente funzionanti. Dopodiché viene eseguito un
briefing, fra tutte le figure coinvolte nella sessione sperimentale, durante il quale
viene fatta una sintetica valutazione dello stato della macchina sia dal punto di vista
degli impianti, sia dal punto di vista della capacità di produrre il plasma (target) per il
programma scientifico. In questa sede viene monitorato lo stato di avanzamento
del programma scientifico deciso nelle riunioni di programma schedulate
settimanalmente.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
57
Oltre alle scariche di plasma di interesse scientifico, vengono anche prodotte
scariche di condizionamento della macchina. Infatti dopo ogni fermo prolungato di
quest’ultima, sia quando essa viene portata a pressioni atmosferiche, sia quando è
mantenuta sotto vuoto, vengono eseguite delle scariche con plasma. Si fa così in
modo che le elevate temperature producano il deassorbimento delle impurezze
dalle pareti della camera, rimosse dal sistema di vuoto.
La sequenza operativa di sparo si articola nelle seguenti fasi:
• Predisposizione degli impianti. In questa fase il sistema di controllo verifica
che tutti gli impianti inseriti nella configurazione dello sparo siano abilitati e
provvede alla chiusura dei sezionatori di fine linea (quelli che collegano le
alimentazioni elettriche agli avvolgimenti della macchina). Il sistema di
acquisizione dopo essersi inizializzato emette una gate di PRERUN.
• PRERUN. Questa fase dura 120 secondi. Il sottoimpianto di commutazione di
alimentazione elettrica si predispone per lo sparo e 10 secondi prima della
scarica di plasma viene emessa una gate di STARTRUN.
• STARTRUN. In questa fase, della durata di 10 secondi, si passa al controllo
hardware della sequenza di sparo attraverso l’emissione di comandi veloci da
parte di FSC. Il plasma viene prodotto attraverso unasuccessione di eventi:
-
Il campo magnetico toroidale risale al suo valore preprogrammato in circa
1.5 s.
-
Durante la risalita della corrente del magnete toroidale, il trasformatore
centrale è caricato ad un valore preprogrammato di corrente.
-
Una veloce variazione del flusso prodotta dalla commutazione del
trasformatore causa il breakdown della scarica. Durante la salita della
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
58
corrente di plasma, una sequenza preprogrammata di immissione di gas
consente di controllare la densità del plasma. Le correnti negli avvolgimenti
poloidali sono preprogrammate in modo da fornire un campo nullo nella
zona centrale del plasma. Questo per creare un flusso di particelle che eviti
di deviare verso le pareti, così da costituire il nocciolo del plasma.
-
Dopo la formazione del plasma, la corrente salirà a 100-150 kA in 10-15 ms
con una velocità di 107 A/s e raggiungerà il valore preprogrammato in ∼300
ms con una velocità minore a 5⋅106 A/s. Durante questa fase la posizione
del plasma viene controllata sia dal campo magnetico verticale che dal
feedback.
-
Raggiunto il valore preprogrammato della corrente di plasma, inizia la fase
stazionaria che dura ∼1.5 s. Durante questa fase la corrente di plasma viene
mantenuta costante anche in presenza di riscaldamento addizionale a
radiofrequenza. Infatti l’iniezione di radiofrequenza alla frequenza ibrida
inferiore può indurre corrente di plasma attraverso un processo
denominato Current Drive, che può essere bilanciato attraverso una
variazione della corrente di plasma fino a 5⋅105 A/s. Anche in questa fase la
posizione del plasma è controllata durante dal campo magnetico verticale e
dal sistema di feedback.
-
Dopo che i sistemi di riscaldamento a radiofrequenza e il trasformatore
sono stati spenti, la corrente di plasma decade a zero con una costante di
tempo (L/R) legata alle caratteristiche del plasma. L’equilibrio del plasma
deve comunque essere controllato in questa fase per evitare fenomeni di
disruzione che potrebbero usurare il limiter e danneggiare le pareti della
camera.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 2 – Descrizione di FTU
59
• ENDRUN. Dopo che la scarica di plasma è terminata, una gate di FINE
ESPERIMENTO viene fornita a tutti gli impianti affinché si riportino in uno
stato di stand-by per poi predisporsi per un nuovo sparo. Durante questa fase i
sistemi di acquisizione riversano i dati acquisiti in buffer di memoria locale al
sistema di acquisizione centrale che provvede ad archiviarli.
La figura 2.13 mostra i segnali principali acquisiti durante una scarica di plasma.
Fig.2.13 – Corrente di plasma, densità, V-loop, Btor, H-alpha, X-duri e resa neutronica
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
60
3
Capitolo
3. DATABASE OBJECT-ORIENTED
Nel presente capitolo si darà una panoramica generale delle
problematiche relative alla gestione delle basi di dati di grosse
dimensioni e con particolari esigenze rispetto ai tipi di dati trattati. Si
mostrerà perché e con quali strumenti l’approccio Object-Oriented
può risultare di particolare efficacia nell’affrontare le questioni
tradizionalmente ritenute più ostiche.
Si fa presente che per la stesura del suddetto capitolo si è fatto ampio
riferimento ai corsi di Basi di Dati tenuti da F. Mandrioli [10] presso
l’Università di Bologna e dal prof. C. Giolito [11] presso l’Università di
Torino
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
61
3.1. INTRODUZIONE
Una base di dati è un insieme di dati atomici strutturati e persistenti, raggruppati in
insiemi omogenei in relazioni tra loro organizzati con la minima ridondanza così da
essere utilizzati da applicazioni diverse in modo sicuro e controllato.
Sostanzialmente una base di dati è una collezione di dati, logicamente correlati e
rappresentati in modo omogeneo. Una base di dati rappresenta aspetti di una
porzione del mondo reale (universo d’interesse), ragion per cui i cambiamenti di
tale universo si riflettono invariabilmente nel database.
Le caratteristiche peculiari di un database possono essere individuate in:
• formato preciso;
• pochi tipi rispetto al numero di istanze;
• mole elevata di istanze;
• protezione contro accessi non autorizzati e malfunzionamenti.
Un
Applicazione
Applicazione
Applicazione
DBMS
Management
(Data
System)
Base
è
un
programma che interfaccia un
database con le applicazioni che
DBMS
lo impiegano.
Un DBMS è indipendente dalle
applicazioni che lo usano e
provvede
DB
Figura 3.1 – Struttura di interfaccia tra utente e dati.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
necessarie
alle
per
funzionalità
proteggere
e
gestire il database. Un DBMS,
Cap. 3 – DataBase Object-Oriented
62
inoltre, disaccoppia il modello dei dati visto dall’applicazione dalla rappresentazione
fisica degli stessi sul disco.
I DBMS si distinguono a seconda del modello dei dati che offrono per rendere
persistente la base di dati. Tale modello serve ad organizzare i dati in una struttura
logica, basata su operatori e vincoli di integrità prestabiliti, detta schema.
Il DBMS deve necessariamente garantire dei linguaggi per la definizione dei dati
(DDL) e per la loro manipolazione (DML), il rispetto dei vincoli di integrità,
strutture per un accesso efficiente ai dati, la gestione automatica delle transazioni, i
meccanismi di autorizzazione, la gestione della concorrenza nonché il ripristino dei
guasti.
I principali modelli di dati usati sono sostanzialmente del tipo relazionale e del tipo
ad oggetti. I database relazionali (RDBMS) tradizionali sono caratterizzati da
modelli dei dati con un limitato potere espressivo, il che li rende inadatti a
modellare quei dati la cui struttura e le cui relazioni con altri dati non possono
essere direttamente mappati nelle strutture tabulari del modello relazionale.
Le principali carenze dei RDBMS possono essere individuate:
• nella difficoltà di modellizzazione di un oggetto complesso, che implica una sua
suddivisione in un ampio insieme di tuple e la necessità di eseguire un gran
numero di join per ricostruirlo;
• nell’impossibilità da parte dell’utente di definire tipi di dati con associate le
corrispondenti operazioni e di utilizzarli per definire nuovi tipi;
• nell’impossibilità di esprimere proprietà e relazioni dinamiche e di gestire
l’evoluzione temporale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
63
3.2. BASI DI DATI AD OGGETTI
Una soluzione alle problematiche presentate dai RDBMS si è trovata nella
applicazione delle metodologie Object-Oriented
I database orientati agli oggetti (OODB) rispondono alle esigenze di applicazioni
altamente complesse e dinamiche tramite sistemi (denominati OODBMS6) che
consentono la specifica di strutture dati complesse con relazioni semantiche fra i
dati; la descrizione integrata dei dati e delle operazioni disponibili per il loro
ritrovamento e modifica, nonché di operazioni che soddisfano esigenze applicative
e che sono strettamente dipendenti dal tipo di dato astratto; una stretta integrazione
con linguaggi di programmazione ad oggetti, recuperando le tipiche astrazioni di
questi linguaggi quali incapsulamento, ereditarietà, overloading e overriding.
In buona sostanza gli OODBMS attingono da un lato dalla lunga esperienza dei
DBMS
nel
trattamento
delle
tradizionali
applicazioni
business;
nella
standardizzazione (SQL7); nella forte spinta al trattamento di sistemi distribuiti,
meccanismi di controllo dell’evoluzione (trigger) e operazioni come dati memorizzati
(stored procedures), dall’altro dal paradigma di programmazione OOPL, fondato su
oggetti, incapsulamento, classi, ereditarietà, polimorfismo.
6
7
Object Oriented Data Base Management System
Standard Query Language
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
64
3.3. CONCETTI CHIAVE DEL PARADIGMA OBJECT-ORIENTED
I linguaggi di programmazione object oriented presentano indiscutibili vantaggi
rispetto ai tipi di dato complesso innanzitutto per quanto riguarda la possibilità di
poter rappresentare l’universo d’interesse in modo più simile, e quindi più
facilmente intellegibile, a come esso ci si presenta.
L’interazione dell’utente è facilitata dall’introduzione di metodi che permettono una
più diretto contatto con gli oggetti, grazie anche alla possibilità di ereditare attributi
e metodi da una o più classi esistenti, di rimpiazzarne alcuni e di definirne altri
totalmente nuovi scaricando il lavoro di gestione che ne consegue sul sistema.
Inoltre la netta separazione tra interfaccia e stato della classe è una garanzia di
robustezza del sistema.
3.3.1.
OGGETTI ED IDENTITÀ
Ogni identità del mondo reale è modellata come un oggetto al quale è associato uno
stato ed un comportamento. Lo stato di un oggetto è l’insieme dei valori assunti
dalle sue proprietà in un determinato istante, il comportamento è definito dai
metodi che possono essere applicati all’oggetto stesso.
Ogni oggetto è identificato da un OID8 (indipendente dai valori assunti dalle sue
singole proprietà) che ne permette l’individuazione in modo univoco e consente di
costruire riferimenti tra oggetti.
È possibile definire oggetti complessi utilizzando oggetti come attributi di altri
oggetti. Quando il valore della proprietà di un oggetto è un altro oggetto il sistema
memorizza l’identificatore del secondo nel primo.
8
Object Identifier
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
3.3.2.
65
INCAPSULAMENTO
L’incapsulamento (information hiding) è il risultato del processo di nascondere tutti
i dettagli di un oggetto che non contribuiscono alla sua natura essenziale visibile
dall’esterno. L’incapsulamento deriva dal concetto di tipo di dato astratto essendo
le nozioni di astrazione ed incapsulamento complementari.
Un oggetto consiste sostanzialmente due parti: l’interfaccia che include l’elenco dei
metodi accessibili ciascuno con la lista dei suoi parametri (signature) e
l’implementazione che include lo stato dell’oggetto e l’implementazione dei
metodi (corpo).
Lo stato di un oggetto può essere manipolato solo attraverso l’interfaccia che
l’oggetto mette a disposizione. I metodi possono essere invocati inviando messaggi
ad oggetti, che includano il nome del metodo ed i parametri.
3.3.3.
CLASSI
Una classe è l’insieme degli oggetti aventi le stesse proprietà e gli stessi metodi. Un
oggetto è definito come l’istanza di una classe . Il codice associato ad un oggetto
risiede nella classe mentre i dati risiedono nell’oggetto.
In alcuni casi si effettua la distinzione tra il tipo cioè l’astrazione che consente di
descrivere lo stato ed il comportamento della classe e la classe che è rappresentata
da un tipo combinato con una implementazione dei metodi del tipo.
Alcuni sistemi permettono ad un oggetto di diventare istanza di una classe diversa
da quella da cui è stata generata, cioè un oggetto può modificare le sue
caratteristiche pur mantenendo la sua identità (OID).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
3.3.4.
66
EREDITARIETÀ E POLIMORFISMO
L’ereditarietà è una relazione tra classi che permette di definire e realizzare una
nuova classe (sottoclasse) a partire da classi preesistenti (superclassi). Grazie ad essa è
agevolata la gestione della complessità ed inoltre rappresenta un valido meccanismo
di riusabilità del codice.
La sottoclasse eredita lo stato ed il comportamento della superclasse, e può rendere
il suo comportamento più specifico mediante la ridefinizione delle proprietà e dei
metodi ereditati o l’introduzione di nuovi metodi e proprietà. Tutti gli oggetti delle
sottoclassi
appartengono
automaticamente
alle
superclassi
(principio
di
sostituzionalità). È inoltre possibile che una data classe possa essere derivata da
un’unica superclasse (ereditarietà semplice) o da più superclassi (ereditarietà
multipla), nel primo caso si ha una gerarchia di classi nel secondo un grafo aciclico.
Il meccanismo dell’ereditarietà è agevolato dal cosiddetto polimorfismo che
permette di avere varie versioni dello stesso metodo con lo stesso nome.
Mandando quindi lo stesso messaggio a classi derivate da una stessa superclasse,
ognuna risponde col proprio metodo.
Si distinguono l’overriding cioè la possibilità di ridefinire l’implementazione di un
metodo ereditato e l’overloading cioè la possibilità di associare lo stesso nome a
diverse implementazioni della stessa classe (con signature diverse) o in classi diverse.
La scelta del codice specifico per l’esecuzione di un metodo e determinata a runtime (late binding) ed è quindi tutta a carico del sistema.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
67
3.4. MODELLI DEI DATI OBJECT-ORIENTED
Il data model (modello dei dati) è un particolare modo di descrizione dei dati, delle
reazioni tra di essi e dei vincoli a cui devono sottostare. Chiaramente nel caso in
questione il data model è fortemente legato agli oggetti, in particolare l’obiettivo
principale è quello di creare un linguaggio di programmazione per oggetti
persistenti, in modo da integrare le caratteristiche dell’object oriented con i modelli
delle basi di dati, così da eliminare il problema dell’impedance mismatch. I modelli
relazionali trattano adeguatamente le interrogazioni espresse in linguaggio DML9
sfruttando il meccanismo dei cursori. Laddove però le operazioni richiedono la
combinazione di programmazione tradizionale e DML non sono efficienti, difatti i
modelli dei dati non coincidono poichè il linguaggio di programmazione è orientato
all’entità (record) mentre il DML è orientato all’insieme (il risultato è sempre una
relazione). Pur con l’ausilio dei cursori la maggiore quantità di codice necessaria al
colloquio raggiunge il 30%.
3.4.1.
OID
L’identificatore dell’oggetto corrisponde sostanzialmente al concetto di puntatore nei
linguaggi di programmazione e costituisce l’alter ego del concetto di chiave primaria,
basata sui valori, esistente nei RDBMS. L’OID presenta diversi vantaggi rispeeto
alla chiave come meccanismo d’identificazione degli oggetti. Innanzitutto è
completamente gestito dal sistema, quindi l’utente non deve preoccuparsi di
selezionare una chiave appropriata; è indipendente dallo stato dell’oggetto ed è
9
Data Management Language
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
68
unico in tutto il database inoltre è indipendente dalla classe a cui l’oggetto
appartiene quindi può essere fatto migrare.
3.4.2.
INCAPSULAMENTO
Negli OODM10 per incapsulamento s’intende che un oggetto contiene sia le
operazioni che i dati, esiste quindi una differenza sostanziale rispetto agli OOPL,
dove l’incapsulamento deriva dall’ADT11, infatti la maggior parte degli OODBMS
permette, in alcuni casi, una violazione al principio di incapsulamento consentendo
un accesso diretto agli attributi di un oggetto al fine di semplificare l’uso del
sistema. Lo scopo è quello di rendere meno complesso lo sviluppo di applicazioni
che semplicemente accedono e modificano valori di attributi. Si hanno così due
evidenti vantaggi il primo consiste nell’evitare al programmatore di sviluppare un
gran numero di metodi generali e convenzionali, il secondo nell’incrementare
l’efficienza delle applicazioni, in quanto l’accesso diretto agli attributi è
implementato come un’operazione fornita dal sistema.
3.4.3.
STRUTTURE DATI DEGLI OODBMS
Gli OODBMS mettono a disposizione oltre ai tradizionali tipi atomici quali
integer, char, boolean, float, string, bitmap alcuni costruttori non presenti nei
linguaggi ad oggetti i cosiddetti tipi strutturati definiti tramite costruttori di tuple,
set, bag, list che possono essere applicati a qualunque tipo atomico e non ed infine
la struttura più importante la classe.
La classe è la base su cui formulare le interrogazioni in quanto aggrega oggetti
correlati. Il body dei metodi è costituito da un insieme di istruzioni espresse in un
10
Object Oriented Data Model
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
69
qualche linguaggio di programmazione. L’insieme delle classi costituisce lo schema
del database.
Documento
Progetto
Sigla_documento: STRING
Titolo: STRING
Classificazione: STRING
Nome_progetto: STRING
Obiettivo: STRING
Documento *
Piano_di_lavoro *
sottoprogetto
Bilancio( ): NUMBER
Partecipante
Rapporto_tecnico
Argomento: STRING
Inizio_validità: DATE
Fine_validità: DATE
emend
Articolo
Autore *
Tipo_pubblicazione: STRING
Sede_pubblicazione: STRING
Dta: DATE
Task
Data_inizio: DATE
Data_fine: DATE
Descrizione_task: STRING
Partecipante
Anni_uomo: NUMBER
Responsabile
Precede *
Inserito( ):
Ricercatore
Gruppo
Nome_gruppo: STRING
Membro *
Responsabile
Nome: STRING
Specializzazione: STRING
Stipendio: NUMBER
Premio_produzione: NUMBER
Stipendio_mensile( ): NUMBER
Figura 3.0 – Schema logico di una base di dati.
Negli OODBMS ad ogni classe è associato un oggetto particolare detto class-object
che contiene le informazioni comuni alle istanze della classe, quali ad esempio
informazioni statistiche utili in fase di ottimizzazione delle interrogazioni, ed in
particolare i metodi della classe. Se si vuole sostenere il principio secondo il quale
11
Abstract Data Types
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
70
un oggetto è una istanza di una classe e le classi sono oggetti allora, per uniformità,
il sistema deve supportare il concetto di metaclasse ossia classe che descrive le classi.
Alcuni OODBMS consentono la definizione di oggetti eccezionali rispetto alla
classe di cui sono istanze, cioè attributi e metodi aggiuntivi o ridefiniti rispetto a
quelli della classe di appartenenza.
I metodi possono essere utilizzati o come attributi derivati, cioè il metodo
restituisce un valore, che può essere anche un identificatore di un oggetto. La sua
funzione è simile a quella di un attributo, ma mentre un attributo contiene un
valore, un metodo è una procedura che calcola un valore. Oppure come metodi
predicato, cioè il metodo restituisce un valore booleano come attributo derivato.
L’utilizzo di metodi pone problemi di ottimizzazione in quanto è difficile stimare
costo e selettività di un metodo, inoltre nei metodi con side-effect: ha importanza
l’ordine di esecuzione dei predicati e la terminazione dei metodi.
3.4.4.
PERSISTENZA
Un aspetto di rilevante importanza riguarda la persistenza delle istanze delle classi,
cioè secondo quali modalità gli oggetti sono resi persistenti ovvero inseriti nel
database. Esistono sostanzialmente due approcci di base: il primo prevede che la
persistenza sia una proprietà implicita di tutte le istanze delle classi, cioè un oggetto
diviene persistente al momento della sua creazione; il secondo che per rendere un
oggetto persistente sia necessaria un’operazione esplicita, o definendo un nome per
l’oggetto che si vuol rendere persistente o prevedere un’operazione speciale che
renda persistente ogni oggetto che la invoca.
Le difficoltà possono presentarsi qualora si renda necessaria la cancellazione di un
oggetto persistente. In questo caso è possibile prevedere un’operazione di
cancellazione esplicita che però da luogo a problemi d’integrità referenziale a cui si
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
71
può ovviare mantenendo un reference_counter, che permetta di determinare se un
oggetto è referenziato da altri oggetti (soluzione molto costosa), oppure consentire
sempre la cancellazione gestendo da applicazione le eccezioni che si verificano. In
alternativa si può non prevedere un’operazione esplicita di cancellazione ma un
oggetto viene cancellato automaticamente se lo sono tutti i suoi riferimenti e nomi
esterni(garbage collector).
3.4.5.
VINCOLI DI INTEGRITÀ
Per assicurare la correttezza e la consistenza dei dati un DBMS prevede meccanismi
per la definizione, gestione e verifica di asserzioni che devono essere soddisfatte
dagli oggetti. I vincoli di integrità formalizzano la nozione di stato consistente
della base di dati e sono indispensabili in ambiente transazionale.
I vincoli di integrità vengono spesso classificati in vincoli statici se riguardano lo
stato dell’oggetto e vincoli dinamici se riguardano le transazioni di stato.
I linguaggi devono prevedere dei costrutti per definire il vincolo e specificare
l’azione da eseguire nel caso di violazione del vincolo. È possibile adottare dei
meccanismi quali rule o trigger da attivare nel caso di particolari eventi che
garantiscano il rispetto di quei vincoli che non possono essere direttamente
controllati dal DBMS.
Tipi comuni di vincoli esistenti nei DBMS sono:
1. Chiavi uniche primarie
2. Vincoli referenziali
3. Vincoli esistenziali o di dominio
4. Not null
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
72
5. Pre_ e post_ condizioni: le pre_condizioni devono essere vere affinché si
possa attivare un metodo. Le post condizioni devono essere vere dopo
l’esecuzione di un metodo. Codificare un vincolo con una pre oppure post
condizione e’ essenzialmente un problema di gusti ed espressività.
Altri vincoli invece sono caratteristici degli OODBMS:
6. Vincoli sulla migrazione tra classi
7. Vincoli di specializzazione
8. Vincoli di disgiunzione e copertura
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
73
3.5. INTERROGAZIONI NEGLI OODBMS
I linguaggi di interrogazione sono una funzionalità importante degli OODBMS. In
generale, un linguaggio deve essere:
-
ad alto livello, per poter esprimere facilmente operazioni complesse
-
dichiarativo
-
efficiente, deve essere prevista un’ottimizzazione degli accessi
indipendente dall’applicazione
I sistemi relazionali trattano adeguatamente le interrogazioni ad hoc, espresse in
linguaggio DML nativo che solitamente è computazionalmente completo.
Le operazioni che richiedono la combinazione di programmazione tradizionale e di
DML non sono efficienti in quanto i modelli dei dati non coincidono inoltre il
linguaggio di programmazione è orientato all’entità (record) mentre il DML è
orientato all’insieme, infatti il risultato è sempre una relazione.
Alcuni meccanismi quali i cursori permettono la convivenza ma la maggiore
quantità di codice necessaria al colloquio raggiunge il 30%.
Nei RDBMS i linguaggi di interrogazione sono l’unico modo per accedere ai dati,
mentre gli OODBMS dispongono di due modalità:
•
Accesso navigazionale, cioè dato un OID, il sistema accede direttamente
all’oggetto e naviga attraverso gli oggetti referenziati dai suoi attributi.
•
Accesso tradizionale basato su linguaggi d’interrogazione SQL-like.
Questi due tipi di accesso possono essere combinati per specificare condizioni sugli
attributi innestati degli oggetti interrogati.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
74
Una sintassi standard per un linguaggio di interrogazione SQL-like per il modello a
oggetti non è ancora stata definita (vedi ODMG), pertanto allo stato attuale ogni
OODBMS utilizza un proprio ‘dialetto’.
Il risultato di una query nei DB relazionali è ancora una relazione. Il risultato di una
query su una classe o un insieme di classi presenta dei problemi di definizione.
Ogni oggetto appartiene a una classe e ogni classe ha una posizione nella gerarchia
di ereditarietà.
Gli oggetti che formano il risultato possono essere un insieme di attributi di una
classe o un insieme di istanze di classi diverse.
Esempio:
“Seleziona carrozzeria e colore dei veicoli prodotti a Torino”
fornisce il valore degli attributi colore e carrozzeria (che è a sua volta
un attributo composto della classe Veicolo).
A quale classe si possono associare questi oggetti ?
Che posizione occupa questa classe all’interno della gerarchia delle classi?
A causa di queste difficoltà formali molti OODBMS impongono restrizioni sulle
interrogazioni composte, cioè sull’uso del risultato di una query come operando di
un’altra query.
3.5.1.
ACCESSO NAVIGAZIONALEAI DATI
Si naviga la gerarchia di aggregazione della base di dati utilizzando direttamente gli OID
degli oggetti mediante un linguaggio di programmazione messo a disposizione
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
75
dall’OODBMS. Noto l’OID di un progetto si può ottenere l’Ente a cui afferisce il
responsabile navigando la catena di riferimenti.
Progetto
Ente
Responsabile
Figura 3.3 – Accesso navigazionale ai dati.
Durante la “navigazione” di una gerarchia di aggregazione si possono imporre
condizioni sugli attributi annidati.
Negli OODBMS distinguiamo: join implicito indotto dalla gerarchia di
aggregazione, e join esplicito che paragona esplicitamente gli oggetti.
Per semplificare la formulazione di condizioni sugli attributi annidati molti
linguaggi includono le path-expressions. Una path-expression specifica un join
implicito tra un oggetto e un suo oggetto componente.
Esempio:
Progetto.Responsabile.Ente.name = “ENEA”
si noti che tale espressione, apparentemente molto semplice, implica
tre join (impliciti) distinti.
Un’interrogazione può riguardare una singola classe C o la gerarchia di ereditarietà che
parte da C. Per consentire l’accesso ai soli oggetti di una classe o in alternativa agli
oggetti della classe e tutti quelli delle sue sottoclassi il sistema fornisce costrutti
speciali (predicati alternativi).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
3.5.2.
76
ACCESSO TRADIZIONALE
L’accesso tradizionale si basa su linguaggi di interrogazione tipo SQL
opportunamente estesi per operare con un modello di dati a oggetti. Le
interrogazioni sono applicate alle classi in quanto “contenitori di oggetti”.
L’operatore di selezione su una classe C (o sulla gerarchia che ha origine in C)
consiste nel recupero delle istanze della classe (o della gerarchia).
Si noti che il recupero di istanze di una classe C può comportare la necessità di
recuperare istanze di altre classi che formano gli attributi della classe C. Inoltre il
recupero dell’istanza di una classe C2 , che è il valore di un attributo A della classe
C1 , è l’operazione di join tra le classi C1 e C2 (Il join si applica all’attributo A
della classe C1 e all’identificatore dell’oggetto della classe C2 ). Ciò fa sì che, in un
OODBMS, un’interrogazione apparentemente semplice, possa essere in realtà
molto complessa a causa di un gran numero join impliciti.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
77
3.6. MEMORIZZAZIONE DEGLI OID
Lo schema di una base di oggetti è un insieme di classi legate da gerarchie di
ereditarietà e di aggregazione. Una memorizzazione efficiente di queste gerarchie ed
adeguate tecniche d’indicizzazione sono di fondamentale importanza per le
prestazioni del sistema.
Gli OID vengono utilizzati sia dai programmi applicativi per referenziare gli oggetti
sia per rappresentare le relazioni tra essi (associando, ad esempio, una lista di OID a
uno degli oggetti che partecipa a un’associazione).
La scelta del tipo di rappresentazione degli OID può influenzare le prestazioni di
un OODBMS. Gli OID possono essere:
• fisici: l’OID contiene l’indirizzo attuale dell’oggetto
• logici: l’OID è un indice dal quale si ottiene l’indirizzo dell’oggetto.
Alcuni approcci proposti per la rappresentazione degli OID fisici e logici sono:
-
Indirizzo fisico. L’OID è l’indirizzo fisico dell’oggetto. A fronte dell’elevata
efficienza si hanno problemi per spostamenti e cancellazioni di oggetti in
quanto è necessario modificare tutti gli oggetti che contengono riferimenti agli
oggetti spostati.
-
Indirizzo strutturato. L’OID è costituito da due parti: la prima contiene il
numero di segmento e di pagina di disco, la seconda un numero logico di slot
che determina la posizione all’interno della pagina (l’oggetto può essere
facilmente rilocato all’interno della stessa pagina). Usato in: ONTOS,
Objectivity.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
-
78
Surrogato. L’OID viene generato utilizzando un algoritmo che ne garantisce
l’unicità. Gli OID surrogati vengono poi trasformati in indirizzi fisici mediante
funzioni hash. Usato in: POSTGRES
-
Surrogato tipizzato. È una variante del surrogato, che utilizza sia un
identificatore di classe sia un identificatore di oggetto. Per ogni classe, un
contatore diverso genera la porzione di identificatore di oggetto. Lo spazio di
indirizzi risulta segmentato ed è possibile determinare la classe di appartenenza
di un oggetto senza doverlo prelevare fisicamente da disco.
La lunghezza degli OID è solitamente compresa tra 32 e 48 bit. Può essere
necessario utilizzare 64 bit o quando l’OID è rappresentato da surrogati generati da
una funzione monotonicamente crescente, in questo caso non è possibile
riutilizzare OID che sono già stati generati ma che non vengono più utilizzati
(‘buchi’), oppure nel caso di un ambiente distribuito, quando è necessario
aggiungere un prefisso per identificare la macchina su cui risiede l’oggetto.
In molte applicazioni gli OID vengono convertiti in indirizzi di memoria quando gli
oggetti vengono prelevati da disco e portati in memoria centrale (Swizzling). Questa
trasformazione permette di aumentare la velocità con la quale si può “navigare” tra
gli oggetti utilizzando gli OID.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
79
3.7. PATTERN DI ACCESSO E STRATEGIE DI MEMORIZZAZIONE
L’efficienza di un’organizzazione di memorizzazione dipende non solo dalla
struttura degli oggetti e delle loro relazioni, ma anche dal modo in cui i programmi
applicativi accedono agli oggetti ovvero dai pattern di accesso.
Si distinguono due tipi principali di pattern di accesso:
• Accesso basato sull’intero oggetto. È utilizzato per quelle applicazioni che
eseguono manipolazioni complesse di oggetti. In questo caso l’intero oggetto è
copiato.
• Accesso basato sulle componenti. È utilizzato per accedere ad attributi di
oggetti situati ad un certo livello di nesting nella gerarchia di aggregazione. È
utilizzato quando si vuole accedere ad oggetti di grandi dimensioni.
Essendo il modello object-oriented più complesso di quello relazionale,
l’organizzazione della memoria negli OODBMS deve essere in grado di supportare
efficientemente:
-
oggetti con attributi atomici e complessi
-
oggetti con attributi multivalore
-
oggetti con attributi BLOB (Binary Large OBject) utilizzati per manipolare
informazioni multimediali
Tutte le strategie di memorizzazione fin ora proposte in ambito OODBMS sono
inquadrabili tra due approcci estremi il modello diretto ed il modello normalizzato.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
3.7.1.
80
MODELLO DIRETTO
In questo caso gli oggetti sono memorizzati così come sono definiti nello schema
concettuale, gli attributi semplici o complessi vengono memorizzati insieme
all’oggetto, gli oggetti dello stesso tipo sono memorizzati nello stesso file.
Il vantaggio che si presenta consiste nell’efficienza del reperimento di interi oggetti,
in quanto non sono necessari join per ricostruirli.
Oggetto 1
Oggetto 2
a1
b1
d1
a2
c1
e1
b2
d2
c2
e2
...
Oggetto m
am
bm
dm
cm
em
Figura 3.4 – Memorizzazione diretta.
Lo svantaggio è che l’accesso ad un sottoinsieme delle componenti dell’oggetto può
risultare costoso, quando l’oggetto ha campi di grandi dimensioni.
Il modello diretto presenta alcune lacune quando:
-
Occorre gestire attributi di dimensioni variabili.
-
È prevista la possibilità di creare nuovi attributi.
-
Gli attributi hanno per lo più valore nullo (attributi sparsi).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
3.7.2.
81
MODELLO NORMALIZZATO
In questo caso gli oggetti vengono decomposti in componenti atomiche, ogni
insieme di componenti è memorizzato in un file diverso, le relazioni fra i vari
componenti sono mantenute tramite gli OID
Il vantaggio è che l’accesso diretto alle componenti è efficiente, lo svantaggio che per
ricostruire un intero oggetto occorre eseguire un certo numero di join.
a1
a2
... ...
ai
am
b1
b2
... ...
bi
bm
c1
c2
... ...
cm
Oggetto i
ai
bi
ci
di
ei
Figura 3.5 – Memorizzazione normalizzata.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
ci
Cap. 3 – DataBase Object-Oriented
82
3.8. CLUSTERING
Esiste un certo numero di schemi di memorizzazione che si pongono a metà strada
tra gli approcci precedenti. Sostanzialmente tali strategie fanno uso di tecniche di
clustering, ovvero cercano di raggruppare oggetti correlati, aventi caratteristiche in
comune, in aree di disco contigue.
Lo scopo delle tecniche di clustering è di ridurre il numero di operazioni di I/O
necessarie per accedere ai dati.
L’efficienza di un approccio di questo tipo dipende da una precisa conoscenza della
struttura degli oggetti e dei pattern di accesso. Questi ultimi possono essere definiti
in anticipo sulla base del tipo di applicazioni gestite, ma può essere anche utile
conoscerne l’evoluzione nel tempo. A tale proposito, le statistiche devono
riguardare non solo la frequenza di accesso a singoli oggetti ma anche la frequenza
con cui si accede ad un oggetto b, quando si accede all’oggetto a.
E’ possibile adottare diverse strategie di clustering.
1. Memorizzare gli oggetti di una classe in aree contigue in base al valore di un
attributo o di una combinazione di attributi.
2. Memorizzare gli oggetti di più classi in aree contigue nel caso in cui le classi
abbiano in comune uno o più attributi e gli attributi abbiano valori uguali.
3. Allocare le istanze delle classi di una gerarchia di aggregazione in una sequenza
lineare di raggruppamento (ad esempio adottando l’ordine depth-first), in modo
che tutti i nodi discendenti di ogni nodo p siano memorizzati immediatamente
dopo p.
4. Allocare le istanze delle classi di una gerarchia di ereditarietà in modo analogo
al punto 3.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
83
5. Utilizzare una combinazione di 3 e 4 per trovare una collocazione ottimale per
il prelevamento di istanze di un qualsiasi sottografo connesso del grafo dello
schema.
Una buona strategia di raggruppamento dovrebbe essere dinamica, cioè prevedere
riorganizzazione e ricompattamento a fronte delle operazioni di:
-
modifica della base di dati ovvero creazione e cancellazione di oggetti. La
cancellazione non crea problemi in quanto lo spazio occupato da un oggetto
cancellato può essere reso disponibile per un uso futuro. Invece, per quanto
riguarda la creazione di oggetti, è improbabile che la sequenza di creazione degli
oggetti della gerarchia di aggregazione coincida con quella di clustering richiesta
(es: inserimento breadth-first vs. visita depth-first). In questo caso, le pagine
che contengono gli oggetti devono essere collegate per realizzare la sequenza di
clustering richiesta.
-
modifica dei pattern di accesso. I pattern di accesso sono variabili in
funzione del tipo di operazione eseguita (inserimento, accesso, ecc.) e sono
differenziati per utenti diversi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
84
3.9. GESTIONE DELLE TRANSAZIONI: CONTROLLO DELLA
CONCORRENZA
I meccanismi di lock devono tenere conto:
-
dell’aggregazione. Quando si accede a un oggetto che ha come attributi altri
oggetti il lock va esteso anche agli oggetti componenti.
-
dell’ereditarietà. Quando si accede alle istanze di una classe va posto un lock
anche sulle sue superclassi perché non ne sia modificata la definizione.
Inoltre la durata delle transazioni nelle applicazioni avanzate (CAD, VLSI, ...) può
essere di parecchi giorni invece che di pochi secondi come normalmente avviene
nelle applicazioni gestionali (si pensi, ad esempio, alla modifica di un oggetto che
rappresenta un’ala di aereo).
Un lock esteso su un intero oggetto non sempre è accettabile. Si ha quindi la necessità
di un protocollo che consenta di aumentare il grado di concorrenza.
La maggior parte degli OODBMS commerciali sono privi di adeguati meccanismi
per il controllo della concorrenza. Un possibile protocollo è il multigranularity.
3.9.1.
MULTIGRANULARY LOCKING
Multigranularity locking (MGL) è un protocollo per il controllo della concorrenza
introdotto da Gray nel 1975 in ambito relazionale.
I dati sono organizzati in una struttura ad albero dove ogni nodo (granulo)
rappresenta i dati associati a tutti i suoi discendenti. (DB table tuple). Quando una
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
85
transazione pone esplicitamente un lock su un nodo, il sistema pone implicitamente
un lock su tutti i nodi discendenti.
Si distinguono lock esclusivi e lock condivisi:
-
Un lock esclusivo (exclusive-lock X) su un nodo N esclude la possibilità di
accesso a N (in lettura o scrittura) alle altre transazioni.
-
Un lock condiviso (shared-lock S) su un nodo consente un accesso al nodo (in
lettura) alle altre transazioni.
Normalmente per concedere un lock su un nodo N a una transazione, lo scheduler
deve verificare che nessun altra transazione sia in possesso di un lock in conflitto
con quello richiesto su un discendente di N (il che risulta chiaramente inefficiente).
Tale conflitto può essere evitato se tutti gli antenati di ogni nodo su cui si pone un
lock vengono “marcati” appropriatamente.
Il protocollo MGL propone un terzo tipo di lock detto lock intenzionale (intentionlock I). Tutti gli antenati di un nodo N devono essere locked in modo intenzionale
prima che un lock esplicito venga concesso su N. Ciò comporta un processo di
locking ricorsivo che termina con il lock intenzionale del nodo radice.
I lock intenzionali sono esclusivi o condivisi:
-
Un intention-shared lock (IS) su un nodo specifica l’intenzione di eseguire un
lock di tipo S su qualche discendente del nodo.
-
Un intention-exclusive lock (IX) su un nodo specifica l’intenzione di eseguire
un lock di tipo X su qualche discendente del nodo.
La presenza di un intention-lock su un nodo indica che esiste un lock su un qualche
discendente del nodo. In questo modo, ad ogni richiesta di lock su un nodo N, lo
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
86
scheduler evita di controllare la presenza di un eventuale lock su ogni discendente
di N.
Quando una transazione richiede un lock su un nodo, lo scheduler opera in base alla
seguente tabella di compatibilità dei lock.
3.9.2.
MGL IN OODBMS
In ambiente OODBMS il modello di dati fornisce un’organizzazione gerarchica
naturale in granuli di differenti dimensioni (si pensi alla gerarchia di aggregazione
delle classi).
-
Una relazione (is a member) esiste tra gli oggetti di una classe e la classe stessa.
-
Una classe può essere sottoclasse di una o più superclassi, il che implica una
relazione (is a) tra le istanze delle sottoclasse e quelle delle superclassi.
La struttura che modella le relazioni di sottoinsieme tra i diversi granuli, non può
essere rappresentata da un albero (si pensi all’ereditarietà multipla) e viene
rimpiazzata da un DAG con radice.
Il protocollo MGL è opportunamente esteso per operare con DAG:
la considerazione principale riguarda il fatto che prima di poter eseguire un lock su
un nodo N di un DAG è necessario porre un lock su tutti gli antenati di N.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
87
3.10. ODMG
ODMG12 è un gruppo di standardizzazione nato dal consorzio di compagnie di
produzione di ODBMS [9]. L’obiettivo è stato quello di definire una
standardizzazione sia a livello del modello dei dati che del linguaggio, in modo che
sia permesso ad un ODBMS customer di scrivere applicazioni portabili, cioè
applicazioni che possano essere eseguite da diversi OODBMS.
In quest’ottica lo schema dei dati, il binding con il linguaggio di programmazione, il
linguaggio di manipolazione ed interrogazione devono essere portabili. Inoltre basi
di dati eterogenee e distribuite dovrebbero scambiare informazioni attraverso
l’OMG13 Object Request Broker (ORB o CORBA).
Quello che si vuole non è produrre prodotti ODBMS identici, ma le differenze
dovranno esistere tra prodotti relativamente alle prestazioni, linguaggi supportati,
funzionalità , ecc.
Il linguaggio proposto bilancia compatibilità con il linguaggio SQL e con linguaggi
di programmazione (Java, C++, Smalltalk).
Le componenti dello standard definito sono:
• Object Model. E’ un’estensione del modello OMG designato come comune
denominatore per ORB, OODBMS, linguaggi di programmazione ad oggetti.
• Object Definition Language (ODL). E’ una estensione del linguaggio di
definizione di interfaccia di OMG.
12
13
Object Database Managment Group
Object Managment Group
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
88
• Object Query Language (OQL). E’ il linguaggio dichiarativo di
interrogazione e manipolazione di oggetti di un database (SQL standard +
nuove capacità).
•
Binding con C++. Include una versione di ODL che usa la sintassi C++, un
meccanismo per invocare OQL e procedure per operazioni su basi di dati e
transazioni. Viene quindi definito un meccanismo per scrivere codice C++
portabile che permetta di manipolare oggetti persistenti
3.10.1. OBJECT MODEL
Un tipo ha una interfaccia e una o più implementazioni.
L’interfaccia definisce l’interfaccia esterna supportata per le istanze del tipo, cioè le
proprietà (attributi e associazioni) e le operazioni che possono essere invocate su essi.
Un’implementazione definisce invece le strutture dei dati che rappresentano
fisicamente i dati e i metodi che operano su queste per supportare lo stato esterno e
il comportamento definito nell’interfaccia.
Le caratteristiche dei tipi sono:
-
supertipi (ereditarietà multipla)
-
chiavi
estensione (insieme di tutte le istanze di un tipo)
La combinazione dell’interfaccia di un tipo e una o più implementazioni è una
classe. Nell’interfaccia sono incluse le dichiarazioni di:
-
attributi, caratterizzati da signature: nome e tipo dei valori legali
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
-
89
associazioni, caratterizzate da signature: tipo dell’oggetto o insieme di oggetti
coinvolti nell’associazione e nome della funzione usata. Le relazioni sono
binarie, la cardinalità può essere uno-a-uno, uno-a-molti, molti-a-molti
-
operazioni, caratterizzate da signature: nome dell’operazione, nome e tipo di
ogni argomento, nome delle eccezioni
Inoltre, il modello include un insieme built-in di tipi collezione: set, bag, liste, array a
cui possono essere associati nomi.
3.10.2. OBJECT MODEL: STATO E COMPORTAMENTO
Un tipo definisce lo stato e il comportamento delle sue istanze. Lo stato è definito da
un insieme di proprietà Il comportamento di un tipo oggetto è specificato come
insieme di operazioni le quali sono sempre definite su un singolo tipo oggetto (non
c’è concetto di operazione definita tra più oggetti),
sono overloaded inoltre la
selezione di quale operazione invocare (chiamata operation name resolution o operation
dispatching) dipende dal tipo dell’oggetto indicato nella chiamata e viene scelta
l’operazione definita sul tipo più specializzato.
Un’operazione può avere effetti collaterali
3.10.3. OBJECT MODEL: METADATA
Tutti i tipi sono istanze del tipo Type che è a sua volta un sottotipo ed un’istanza
del tipo Atomic_Object.
Lo schema di un database è quindi accessibile usando le stesse operazioni che si
applicano ai tipi definiti dall’utente:
Il DML standard può essere usato per interrogare lo schema .
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
Type ha le seguenti proprietà ed operazioni:
has_operations:Set<Operation>
has_properties:Set<Property>
has_subtypes: Set<Type>
has_supertypes: Set<Type>
name: String
extent: Set<Atomic_Object>
name_of_extent:String
create_instances ([property =
property_value {,
property = property_value }]) -> o:
Denotable_Object
create_extent (name: String) -> c:
Collection
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
90
Cap. 3 – DataBase Object-Oriented
91
3.10.4. OPERAZIONI SUL TIPO DATABASE
Un database fornisce supporto alla memorizzazione degli oggetti persistenti di un
dato insieme di tipi. Ogni database ha uno schema che consiste di un insieme di
definizioni di tipo e può contenere istanze dei tipi definiti nel suo schema.
Un database può essere memorizzato in uno o più database fisici ed è un’istanza del
tipo Database che supporta le seguenti operazioni:
-
open ( )
-
close ( )
-
lookup_object (oid: Object) -> b : Boolean
contains_object (oid: Object) -> b : Boolean
3.10.5. OQL (OBJECT QUERY LANGUAGE)
Sostanzialmente è previsto un approccio di tipo funzionale con operatori
liberamente combinabili. È ammessa una sintassi astratta ma le sintassi concrete
sono fortemente ispirate al linguaggio SQL
Le queries possono richiamare delle funzioni sugli oggetti (ricordiamo che anche i
metodi sono interpretati come attributi) ed in ogni caso vengono effettuate su
collezioni e restituiscono ancora delle collezioni o elementi a cui è possibile
assegnare un nome riutilizzabile in altre interrogazioni.
È inoltre prevista la possibilità di effettuare queries annidate ed operazioni quali il
Group_by.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
92
3.11. OBJECTSTORE PSE PRO FOR JAVA
Le informazioni qui presentate provengono dalla documentazione tecnica di
ObjectStore PSE Pro Release 6.0 for Java.
Per comodità nel seguito si userà indicare l’applicativo in questione semplicemente
con la sigla PSE.
3.11.1. LA PERSISTENZA
Il PSE provvede alla persistenza di un oggetto tramite una forma potenziata della
serializzazione di un oggetto Java. La serializzazione provvede ad un semplice ed
estensibile meccanismo per immagazzinare oggetti persistenti, mantenendo intatti e
il tipo e le proprietà degli oggetti. Gli oggetti in questione vengono creati come
normali oggetti transienti dopodiché vengono aggregati ad un oggetto persistente
già esistente la cosiddetta root. Gli oggetti di tipo root costituiscono un entry point
per i database di tipo ObjectStore. Generalmente esistono solo un piccolo numero
di roots che contengono altri oggetti persistenti acceduti per riferimento.
Lo sviluppo di applicazioni usando PSE implica la costruzione di classi utilizzando
normali sorgenti di tipo Java, prima compilati da un normale compilatore Java e
successivamente post-processati in modo da ottenere delle classi che permettano la
realizzazione della persistenza. Il post processore altro non fa che rimpiazzare le
classi originarie con delle altre modificate.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
93
3.11.2. TOOLS DI SVILUPPO
Poiché il meccanismo della persistenza è basato sulla serializzazione, non vi sono
processi dedicati che richiedano amministrazione o monitoraggio. Una cosiddetta
Sessione, attiva su una JVM14, causa un lock su un database, cosicché una API
corredata da un’insieme di funzioni di management è disponibile all’interno della
sessione stessa. Vi sono peraltro una serie di strumenti che provvedono al
management dei database:
-
osjcheckdb: Malgrado non vi siano tools specifici, vi sono degli strumenti che
provvedono all’evoluzione dello schema (ossia la struttura del db) e permettono
il dumping ed il reloading dei dati serializzati,
-
OSDD15: è uno strumento di design che provvede allo sviluppo e
all’implementazione degli schemi, anche se nella versione shareware non sono
disponibili certe funzionalità, quale ad esempio l’associazione bidirezionale,
-
osjshowdb: un browser testuale che permette all’utente di visionare lo schema
ed i contenuti di uno o più databases,
-
osjbrowsedb: la versione beta di un browser grafico,
-
osjgcdb: uno strumento di Garbage Collection ‘persistente’. Viene usato un
approccio a due fasi: la prima volta vengono marchiati gli oggetti non
referenziati, la seconda vengono eliminati quelli ancora marchiati.
14
15
Java Virtual Machine
ObjectStore Database Designt
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
94
3.11.3. LIBRERIE
Il PSE include un API basato su una libreria di classi statiche i cui supporti sono:
-
Management della session.
-
Management del thread.
-
Sincronizzazione dei threads con le sessions.
Management per la creazione, l’apertura, la chiusura, la copia, il garbage
collecting, la distruzione e l’interrogazione di un database.
-
Management delle transazioni.
-
Collection come bag, map, tree, list.
-
Interfaccia delle queries secondo lo standard ODMG.
Manipolazione degli oggetti di tipo root.
3.11.4. TRANSAZIONI E CONCORRENZA
PSE provvede ad una implementazione delle transazioni che supporta un controllo
di concorrenza tradizionale del tipo multiple readers/single writer . PSE supporta
quattro tipi di transazioni: update, read-only, update non-blocking e read-only nonblocking.
Se viene selezionato il modo update l’applicazione può modificare i dati, viene
richiesto un lock che viene accordato se non ve ne è già presente alcuno, in caso
contrario si mette in attesa finche la risorsa non viene liberata.
Il modo read-only permette di leggere ma di non scrivere. Uno shared-grant viene
assegnato se non vi sono dei locks attivi o in attesa.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 3 – DataBase Object-Oriented
95
I modi di tipo non-blocking sono simili ai precedenti eccetto il fatto che se non
trovano la risorsa libera invece di attendere generano un’eccezione.
3.11.5. OGGETTI COMPOSTI E RELATIONSHIPS
PSE supporta attributi i cui tipi siano altre classi. Gli oggetti referenziati da un
oggetto persistente sono a loro volta persistenti, a meno che il riferimento non sia
stato esplicitamente definito come transiente. le operazioni di cancellazione e di
lock applicati a questi persistono attraverso gli oggetti referenziati.
Nel caso di relationships unidirezionali, PSE permette agli oggetti di essere interrelazionati attraverso l’uso dei referenziamenti tra di essi. Nel caso di relationships
unidirezionali multivalore si possono utilizzare le classi di tipo Collection. Le
relationships bidirezionali di tipo uno-ad-uno, uno-a-molti, molti-a-molti sono
supportate ed i riferimenti dopo la cancellazione possono essere verificati
attraverso il tool di check referenziale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
96
4
Capitolo
4. SPECIFICHE ED ANALISI DEL PROBLEMA
In questo capitolo verrà descritto l’ambiente operativo nonché degli
strumenti hardware/software su cui si basa il lavoro sperimentale di
FTU. In particolare si analizzerà l’attuale archivio degli spari, con le
informazioni ad esso correlati, così da fornire le caratteristiche del
dominio dei dati e le principali funzionalità attualmente disponibili.
Ciò costituirà la base per definire i requisiti necessari a sviluppare un
modello logico dei dati con metodologia orientata agli oggetti.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
97
4.1. L’AMBIENTE OPERATIVO
FTU è una macchina pulsata. L’esperimento consiste nel produrre una scarica di
plasma della durata di circa 2 sec all’interno della camera da vuoto. L’intera
sequenza di operazioni per realizzare la scarica ed acquisire i dati viene denominata
sparo o shot e dura circa una ventina di minuti. L’insieme dei sistemi diagnostici
installati sulla macchina permettono di caratterizzare le grandezze fisiche del
plasma, che costituiscono i dati sperimentali su cui validare i modelli teorici.
Dal punto di vista operativo, all’interno di un esperimento di FTU si possono
distinguere quattro componenti principali (vedi figura 4.2):
• il sistema di controllo (Prometeo)
• i sistemi di acquisizione dati (DAS)
• il sistema di archiviazione
• i sistemi di analisi dati
All’avvio di una sequenza di sparo, il sistema di controllo (Prometeo) comunica al
DAS
di
inizializzarsi..
Questi
dopo
aver
acquisito
la
configurazione
dell’esperimento provvede a predisporre i moduli di acquisizione nello stato di
attesa delle gates di PRERUN-STARTRUN-ENDRUN. Alla fine dello sparo
archivia i dati nel sistema di archiviazione, i quali sono immediatamente disponibili
per l’analisi e le successive elaborazioni.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
98
Lo schema di interazione durante una sequenza di sparo è rappresentato in
figura.4.1.
experiment
1: inizializza
3: configurazione
DAS
Prometeo
Tokamak
Diagnostic
4: data flow
5: storage
2: lettura parametri di configurazione
7: scrittura dati elaborati
DB
Analisi ed
Elaborazioni
6: lettura dati acquisiti
Figura 4.1 – Collaboration diagram dell’esperimento.
Le figure professionali (attori) presenti durante una sessione sperimentale sono:
• Il caposequenza: decide e predispone la scarica di plasma per il programma
scientifico concordato. Esegue anche l’analisi dei dati della scarica per fornire
una interpretazione sintetica da inserire nel quaderno di bordo.
• Il
responsabile
di
sistema:
assicura
al
caposequenza
il
perfetto
funzionamento di tutti gli impianti predisposti per ottenere il plasma. Provvede
all’analisi di eventuali situazioni anomale e decide le azioni da intraprendere per
risolverle. Annota in un opportuno registro le cause di anomalie che producono
ritardo nella sperimentazione e le soluzioni adottate. Con queste informazioni
viene successivamente eseguita l’analisi statistica della operatività degli impianti
di FTU.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
99
• Il responsabile di programma: predispone il programma scientifico
definendo il plasma target per l’esperimento. Di solito coordina un gruppo di
ricercatori che si occupa dell’analisi dei dati.
• Il responsabile CODAS: responsabile del sistema di controllo e di
acquisizione/archiviazione dati.
• Gli operatori di macchina: predispongono gli impianti, configurano la scarica
ed avviano le sequenze operative di sparo.
• I responsabili di diagnostica: assicurano il perfetto funzionamento di
ciascuna diagnostica.
aggiorna
Archivio scariche
RDS
Fisici
uses
CapoSequenza
Prometeo
Archivio delle anomalie
aggiorna
Software di analisi
Quaderno di bordo
Tokamak
misure
sync
sync
Diagnostiche
sync
Gates e Clock
trasferimento dati
DAS
DataBase
DB_DAS
Figura 4.2 – L’ambiente sperimentale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
DB_PED
Cap.4 – Specifiche ed analisi del problema
100
4.2. AMBIENTI HARDWARE E SOFTWARE
Il sistema di controllo (Prometeo), non rientrando negli scopi di questo lavoro, non
verrà incluso nell’analisi dei requisiti e verrà trattato come componente esterno.
4.2.1.
IL DAS
Il DAS è nato con un’architettura centralizzata in cui l’acquisizione è
completamente guidata dai moduli hardware basati sul bus standard CAMAC. Per
DAS si intende l’insieme dei processi che implementano le funzionalità di
configurazione, inizializzazione, lettura dei buffer di memoria dei moduli,
archiviazione locale e trasferimento ad un server di archivio.
Attualmente esiste un DAS principale residente su un unico nodo VAX-4000 con
sistema operativo OPEN-VMS. La stessa architettura del DAS è utilizzata per
l’acquisizione veloce delle misure macchina (FDA), la quale però utilizza tabelle di
configurazione distinte. Altri DAS basati su CPU VME sono stati installati di
recente. Essi comunque si interfacciano al DAS principale per la configurazione,
attraverso meccanismi di comunicazione tra processi client/server basati su socket.
In dettaglio l’attuale DAS su VAX esegue le seguenti funzioni (vedi figura 4.1):
• Attesa di inizio sparo da Prometeo. In questa fase è fornito (su richiesta) una
informazione di DAS_READY a Prometeo.
• Inizializzazione. Allo start proveniente Prometeo i moduli CAMAC sono
inizializzati secondo le direttive parametrizzate nella Tabella Hardware.
• Acquisizione. I moduli hardware acquisiscono i dati nei loro buffer di
memoria locale, con una sincronizzazione e temporizzazione di tipo hardware
(gates e master-clock). Alla fine dello sparo si acquisiscono i dati dalle memorie
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
101
e si creano i canali secondo le direttive parametrizzate nella Tabella Software.
Ad ogni canale creato il DAS esegue una chiamata di funzione remota (Remote
Procedure Call) ad un server RPC per trasferire i canali nell’archivio dei dati
acquisiti.
• Archiviazione locale su un disco del VAX del Pulse File. Il Pulse File
contiene tutte le informazioni della Tabella Software, i dati acquisiti e alcune
informazioni provenienti dalla Tabella Hardware riguardanti essenzialmente la
temporizzazione dei dati. L’archiviazione locale ha una dimensione limitata ad
un certo numero di spari (qualche centinaio) ed è utilizzata come strumento di
recupero dei dati qualora si presentino problemi di interruzione della rete locale
durante la fase di trasmissione dei canali al server RPC.
• Elaborazione. Seguendo le direttive della Tabella Software, vengono lanciati i
programmi di elaborazione e di grafica voluti dagli sperimentali. Va comunque
precisato che la maggior parte delle elaborazioni che il DAS esegue a fine sparo
sono state rese obsolete, in quanto eseguite da job di post-elaborazione
opportunamente schedulati in ambiente Digital-Unix
Nella prospettiva di distribuire le funzionalità del DAS a sistemi di acquisizione
eterogenei, è in corso di realizzazione una revisione dell’attuale architettura. In
particolare è stato introdotto un nuovo componente denominato Supervisore dei
DAS che consente di estendere a più sistemi tutte le funzionalità precedentemente
descritte.
4.2.2.
L’ARCHIVIO SOTTO AFS
FTU è un progetto partito nel 1989 e nell’arco di questi undici anni l’evoluzione
dell’Information Technology è stata particolarmente veloce. Pertanto le soluzioni
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
102
inizialmente adottate su FTU nel campo dei sistemi di elaborazione e archiviazione
hanno subito profonde variazioni sia per soddisfare richieste di produzione di dati
sperimentali sempre maggiore, dovute all’evoluzione dei sistemi di acquisizione dati
(più veloci e con maggiori capacità di memorizzazione locale), sia per sostituire
ambienti hardware e software ormai in declino.
Si è così proceduti alla migrazione dell’intero ambiente di archiviazione e di analisi
dei dati di FTU dal mainframe IBM/MVS 3090 del Centro Ricerche ENEA di
Frascati ad un sistema distribuito di server UNIX basato su piattaforma
Digital/Compaq.
La migrazione dell’ambiente è stata basata su una soluzione tipicamente usata nei
laboratori di fisica delle alte energie, che è quella del file system geografico
denominato Andrew File System (AFS) della Transarc Corp.
AFS è un file system distribuito tramite il quale possibile accedere a files e
directories residenti su macchine geograficamente distribuite.
AFS è una architettura client/server basata sul concetto di cella. Una cella è un insieme
di nodi computazionali suddivisi in servers e clients. Le celle AFS seguono la stessa
modalità di rappresentazione dei nomi usata da Internet, per esempio la cella AFS
del CERN è cern.ch, quella dell’ENEA è enea.it. Per FTU è stata realizzata una cella
specifica, denominata fusione.it (con alias fus), sulla quale sono stati sviluppati gli
ambienti operativi finalizzati per l’archiviazione e l’analisi dei dati sperimentali del
tokamak e utilizzabili in generale per la ricerca e sviluppo della fusione a
confinamento magnetico.
Le macchine clients AFS sono delle comuni workstation (digital-unix, risc-aix, intellinux, hp-ux, sun-solaris, ecc.) con una parte di disco locale non condivisa e
dedicata al funzionamento del client AFS. Su queste macchine è attivo un processo
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
103
Cache Manager che rende visibile ed accessibile all’utente finale il file system /afs.
Tutti i files e directories che si trovano sotto /afs sono fisicamente presenti sulle
macchine server AFS, geograficamente dislocate per il mondo. Tutte le celle sono
visibili al secondo livello dell’albero AFS. La cella fusione.it è visibile eseguendo il
comando unix:
cd /afs/fusione.it (oppure cd /afs/fus)
In teoria un utente AFS può eseguire sulla sua macchina un qualunque programma
il cui eseguibile sia presente in una directory AFS. Il comando di esecuzione fa sì
che il programma sia dapprima copiato dal Cache Manager sul disco locale e quindi
eseguito sulla CPU della macchina client.. L’utente non percepisce alcuna differenza
rispetto alla situazione in cui il programma è installato sulla macchina locale.
Ovviamente l’eseguibilità di un programma è subordinata alla compatibilità della
piattaforma hardware su cui deve girare.
Per la struttura stessa di tale file system, in cui la gestione dei server è affidata alla
figura dell’amministratore di AFS, l’utente finale usufruisce dei vantaggi tipici della
gestione centralizzata dei dati, quali: il reperimento, l’installazione, la manutenzione
ed il backup del software e dei dati.
Le caratteristiche principali di AFS sono:
• File system geografico. Il file system ha la struttura ad albero tipica di UNIX,
come mostra la figura 4.3. A partire dalla radice /afs è possibile accedere, previa
opportune autorizzazioni, ai file sytem delle varie celle distribuite
geograficamente.
/afs
cern.ch
enea.it
fusione.it
Figura 4.3 – Struttura ad albero di AFS
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
infn.it
Cap.4 – Specifiche ed analisi del problema
104
• Sicurezza. Oltre ai criteri di sicurezza tipici del file system UNIX, AFS ha una
politica di accesso ai files ad un livello più alto. Essa si basa su Access Control List
composta dai seguenti campi:
- l lookup: consente di effettuare comandi tipo ls e cd e di controllare la ACL
su un direttorio
- r consente la lettura del contenuto di tutti i file all’interno di un direttorio
- i consente di creare nuovi file/sottodirettori all’interno di un direttorio
- w consente di modificare il contenuto dei file
- d consente di rimuovere o rinominare i file
- k consente di eseguire programmi che effettuano la chiamata “flock” di
sistema su file contenuti all’interno del direttorio
- a consente di modificare l’ACL del direttorio
• Autenticazione centralizzata. Il sistema di autenticazione basato su Kerberos 4
consente all’utente di fare il proprio login da qualsiasi nodo client della cella.
Una volta acquisito il token di autenticazione è possibile ritrovare il proprio
ambiente operativo indipendentemente dal nodo.
• Multipiattaforma. Sia in versione server che client, è praticamente disponibile
per quasi tutte le piattaforme: Alpha-CompaqTrue64 (ex-Digital-Unix),
SPARC/SUN Solaris, RISC/IBM-AIX, INTELx86/Linux, INTELx86/Winnt.
• Software applicativo indipendente dalla piattaforma. È stato progettato per
l’uso su differenti piattaforme UNIX ed addirittura per CPU con differenti
instruction set. Come è già stato sottolineato, la stessa directory in AFS ha un unico
aspetto indipendentemente dall’architettura su cui sta lavorando l’utente.
Quindi l’utente può avere la necessità di generare e/o raggiungere file excutable
specifici di ogni piattaforma. Per distinguere in modo automatico i binari
specifici della piattaforma su cui l’utente si trova, AFS offre un nome di file
speciale: @sys. Tale nome viene risolto a seconda della piattaforma UNIX in
cui si trova ad operare l’utente
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
105
• Backup in linea. Con AFS si ha una copia di backup della propria cella
raggiungibile attraverso il percorso /afs/.fusione.it. Inoltre è possibile predisporre
strategie di backup per recupero dei disastri su unità a nastro.
Gli array di dischi su cui sono memorizzati i dati di FTU sono in configurazione
RAID 5 ed è prevista una prossima migrazione in architettura Storage Area Network
(SAN) con tecnologia fiber-channel.
La maggior parte dei nodi della cella (circa una ventina), in particolare tutti i server
e i clients utilizzati nella sperimentazione d FTU, sono collegati in rete locale
attraverso switch a 100 Mbit/s con un link FDDI ai sistemi di routing del Centro di
Calcolo di Frascati.
Su un client AFS alpha-Compaqtrue64 è installato il server RPC le cui caratteristiche
sono quelle di eseguire chiamate di funzioni da parte di clients RPC remoti una
volta che questi hanno acquisito i dati dopo lo sparo. In particolare vi è la funzione
di scrittura, che memorizza i canali nell’archivio di FTU. Le ragioni per le quali si è
utilizzato questo metodo di trasmissione dati sono legate alla eterogeneità delle
piattaforme dei vari DAS che hanno differenti rappresentazioni dei dati. Infatti
utilizzando RPC conforme a SUN Open Network Computing (SUN-ONC) è possibile
adottare lo standard eXternal Data Representation (XDR) che permette lo scambio di
dati indipendente dalla piattaforma. Va comunque sottolineato che il server RPC,
installato su un sistema alpha-Compaqtrue64 , memorizza i dati nel formato
dipendente dalla piattaforma (LITTLE-ENDIAN).
4.2.3.
IL SOFTWARE DI ANALISI
La maggior parte del software di analisi dei dati di FTU è scritto in Fortran. Come
per l’archivio dei dati, anche il software di analisi ha subito un laborioso processo di
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
106
migrazione dal mainframe IBM 3090 ai sistemi Alpha-Digital/Compaq in ambiente
UNIX.
Già sul mainframe IBM 3090, il principale software di analisi dei dati di FTU era
rappresentato da Show, un’applicazione che permette l’analisi integrata dei dati
prodotti da apparati sperimentali dedicati allo studio della fusione termonucleare
controllata. Il programma è utilizzato per l’analisi dei dati di FTU ed una versione è
disponibile anche al JET.
Show è un programma di visualizzazione dati 2D, 3D e contour map, con un
insieme di funzionalità completo confrontabile con i tool commerciali. Esso
permette l’analisi dei dati con una ricerca basata sulle chiavi sparo-canale ed ha
possibilità di eseguire elaborazioni sui dati avendo a disposizione, oltre che i
normali operatori algebrici, operatori di integrazione , di derivazione, di smoothing, di
interpolazione, etc. Sono incluse anche funzionalità di fitting dei dati, con funzioni
lineari e polinomiali e di elaborazione numerica di segnali sia nel dominio dei tempi,
sia nel dominio delle frequenze. Infine il programma include un insieme di librerie
di funzioni sviluppate in Fortran dagli utenti di FTU, che eseguono elaborazioni sui
dati acquisiti.
In merito a quest’ultima caratteristica di Show vi è la possibilità di accedere, oltre
che ai canali dei dati acquisiti (DAS) e post-elaborati (PED), ad una terza specie di
canali : %E o canali elaborati.
Essi possono essere creati da chiunque con un normale editor di testo e seguendo
una specifica sintassi. Un interprete ha la capacità di analizzare il contenuto
sintattico del canale elaborato ed eseguire le opportune elaborazioni sui dati DAS e
PED o interfacciarsi all’insieme di funzioni di librerie degli utenti. Questi canali,
quindi, non sono fisicamente memorizzati in un archivio ma sono creati just-in-time
ogni qualvolta vengono richiesti. Quasi un migliaio di canali %E sono attualmente
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
107
disponibili in Show. In appendice D è possibile visionare un esempio di sintassi del
canale %E.TSCTAUE che calcola il tempo di confinamento dell’energia
utilizzando le misure ottenute dal Thomson-Scattering.
La libreria che contiene la maggior parte delle funzioni di analisi dei dati di FTU è
la libftusoft.a. Sviluppata in ambiente alpha/Unix contiene funzioni scritte in
Fortran e C per l’accesso ai dati DAS e PED e le funzioni dell’interprete dei canali
%E. In particolare, al livello più alto vi è la funzione fuelar, che restituisce la quasi
totalità dei canali monodimensionali nella forma yi(xi). Grazie a questa funzione è
possibile interfacciare l’ambiente di analisi dei dati di FTU, oltre che a Show, anche
ai più diffusi tools commerciali di visualizzazione dati, quali IDL™ e MatLab™.
Per l’analisi dei dati da piattaforme diverse da quella alpha-Unix è stato adottato il
tool MDSPLUS sviluppato presso i laboratori MIT. Grazie ad esso è stato possibile
realizzare un server dei dati dell’archivio FTU accessibile tramite socket e installato
su un server alpha-unix. Si è poi utilizzato Javascope, un applicativo in java sviluppato
nel laboratorio del tokamak RFX dal CNR di Padova, per visualizzare i canali
acquisiti ed elaborati. Le enormi potenzialità di questo visualizzatore sono legate
alla sua caratteristica di essere indipendente dalla piattaforma (essendo scritto in
java) e alla facilità con cui possono essere definite nuove classi java che permettono
di interfacciarsi a qualsiasi server di dati. La figura 4.5 mostra una schermata
prodotta da Javascope per un insieme di canali acquisiti.
La figura 4.4 mostra uno schema sintetico di come attualmente è l’architettura del
software di analisi con le relative piattaforme hardware di riferimento.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
Applicazioni utenti
(alpha-unix)
SHOW
(alpha-unix)
108
IDL
(alpha-unix)
MATLAB
(alpha-unix)
fuelar
(alpha-unix)
Routine per lettura/scrittura PED
(alpha-unix)
JAVASCOPE
(tutte le piattaforme)
MDSPLUS
(alpha-unix)
Routine per lettura DAS
(alpha-unix)
PED
DAS
Figura 4.4 – Architettura del software di analisi.
Figura 4.5 – Segnali caratteristici dell’esperimento visionati con JavaScope.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
109
4.3. ANALISI DEI REQUISITI
I domini di interesse dei dati prodotti da FTU possono sostanzialmente essere
raggruppati in sette grandi aree:
1. L’archivio delle scariche predisposte dai Caposequenza. Esso è residente sul
VAX 4000 dove con specifici tool software vengono gestite le funzioni di
creazione, modifica, validazione e trasmissione a Prometeo dei parametri della
scarica. In questa sede non è prevista l’integrazione di tale archivio.
2. Il quaderno di bordo compilato dal Caposequenza. Esso è un database
residente su piattaforma MAC sviluppato con il tool Filemaker. Ciascun record
del database costituisce un’informazione sintetica dello sparo
3. Il registro delle anomalie e ritardi compilato dal responsabile di sistema.
Esso è residente su piattaforma MAC ed in questa fase è stato escluso dal
progetto.
4. L’archivio delle immagini. Su alcune porte di accesso di FTU sono installati
sistemi di visione, basati su telecamere sincronizzate con le gates della sequenza
di sparo. Con questi sistemi è possibile riprendere la scarica di plasma e
digitalizzare un certo numero di frames con le relative temporizzazioni. I frames,
digitalizzati in formato MPEG, sono archiviati attualmente su una workstation
Silicon Graphics che li rende disponibili attraverso Internet.
5. Le tabelle di configurazione del DAS, denominate Tabelle Hardware e
Software e attualmente sono residenti sul VAX.
6. L’archivio dei dati acquisiti dal DAS. Esso è costituito dai dati sperimentali
grezzi provenienti dalle diagnostiche installate su FTU.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
110
7. L’archivio dei dati post-elaborati denominato PED (Post Elaborated Database).
Contiene l’insieme di dati prodotto dal software di elaborazione dei dati
acquisiti.
In particolare su FTU l’insieme dei dati sperimentali è strutturato in modo
gerarchicamente ascendente come:
• Canale. Contiene tutte le informazioni (descrizione, unità di misura, costanti di
ingegnerizzazione, etc.) e i dati associati ad una specifica grandezza di interesse.
In questa struttura non c’è distinzione fra dati acquisiti e post-elaborati.
Solitamente attraverso il canale è possibile definire:
1. un vettore monodimensionale yi(xi) (i=1,N) con y variabile dipendente e x
variabile indipendente (p.e. l’asse temporale)
2. una vettore multidimensionale zij..k(xi,yj,..wk) (i=1,Ni ; j=1,Nj;..k=1,Nk) con z
variabile dipendente e x, y,..w variabili indipendenti (per un massimo di 4).
3. un vettore di parametri (p.e. i coefficienti di calibrazione di una diagnostica)
Va sottolineato che i canali appartenenti all’archivio dei dati acquisiti dal DAS
sono sempre di tipo 1 o 3, mentre quelli dell’archivio PED possono essere
anche di tipo 2.
• Famiglia. Insieme di canali correlati (p.e. quelli appartenenti ad una stessa
diagnostica oppure i canali prodotti da uno stesso programma di postelaborazione). Questa struttura viene trattata come un canale a tutti gli effetti.
• Sparo. Generalmente denominato Shot; contiene l’insieme dei canali prodotti
durante la sperimentazione. Uno sparo è caratterizzato da un numero intero
progressivo.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
111
Families of Channels
Families of Monitor Channels
Families of Data Acquisition
Simple Acquisition Channels
Families of Post Elaboration
Complex Acquisition Channels
Figura 4.6 – Struttura gerarchica dei canali.
Attualmente ciascun sparo è costituito da un numero variabile di canali del DAS e
FDA, che va da un minimo di ∼800 ad un massimo di ∼2000. Il trasferimento di
tutti i canali con la relativa memorizzazione avviene in un tempo di ∼200 s. Ciascun
canale ha una dimensione in bytes variabile e non c’è limitazione alla sua
dimensione relativamente alla trasmissione al server RPC. Attualmente le
dimensioni di un Pulse File variano fra i 10÷15 Mbytes. Sull’archivio dei dati
acquisiti sono applicati i criteri di sicurezza di AFS in base ai quali un unico utente
privilegiato può scrivere nella directory dei dati acquisiti, mentre tutti gli altri utenti
possono accedervi solo in lettura.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
112
Subito dopo la trasmissione dell’ultimo canale del DAS vengono lanciati attraverso
il gestore di code LSF i job di post-elaborazione sui nodi clients AFS. Questi
producono, a seconda della sperimentazione qualche centinaio di canali PED, per
una dimensione totale attuale di massimo 2 MB, memorizzati anch’essi nell’archivio
di FTU.
L’archivio di FTU ha un suo indice naturale basato sul numero si sparo.
Attualmente ∼13000 spari sono stati archiviati, con un valore del contatore di
18051. La dimensione attuale dell’archivio degli spari di FTU (DAS+PED) è di
∼100Gbytes.
L’archivio di FTU residente sotto il file system AFS è accessibile da
/afs/fusione.it/project/ftudati/. Da qui sono stati distinti due rami di directory: il ramo
das/ per i dati acquisiti, e il ramo dbd/ per i dati post-elaborati. All’interno di queste
gli spari sono stati suddivisi in directory contenenti gruppi da 100 spari. Per i dati
DAS, ciascuna directory contrassegnata dal numero di sparo, contiene il PULSE
FILE suddiviso a sua volta nella seguente struttura di directory/files:
sparo/famiglia/famiglia.canale. Per fare un esempio il canale della corrente di plasma, il
cui nome è ZZZZED.IPL dello sparo 17609 è localizzato dal seguente percorso:
/afs/fusione.it/project/ftudati/das/_117600/_117609_/ZZZZED/ZZZZED.IPL
Un’analoga struttura è stata costruita per i canali PED, dove per ovvie ragioni di
funzionalità qualsiasi utente del gruppo che lavora su FTU può modificare i files
della directory dbd/.
4.3.1.
IL QUADERNO DI BORDO
Il quaderno di bordo è un database sviluppato con il tool Filemaker su piattaforma
MAC. Esso è gestito dal Caposequenza durante la sessione sperimentale e contiene
le informazioni sintetiche dello sparo eseguito.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
113
Inizialmente queste informazioni non furono sottoposte ad alcuna specifica e sono
memorizzati in un’unica tabella di FILEMAKER costituita da una serie di campi di
tipo stringhe.
Attualmente è in corso un lavoro di analisi per individuare le informazioni
realmente utili da estrarre da questa sorgente di dati. Questo consentirà di inserirli
all’interno di un DBMS per poter eseguire delle interrogazioni con criteri di ricerca
opportunamente specificati.
I campi del quaderno di bordo che rivestono una importanza rilevante sono:
Numero Shot: numero dello sparo.
Data: data nel formato GG/MM/AA.
Programma: nome del programma scientifico in corso. È una stringa di
lunghezza limitata (40 bytes) che specifica il programma scientifico a cui lo sparo
appartiene. Nell’attuale database ci sono circa 340 nomi diversi di programma.
Questi andranno ridotti a non più di una decina.
Scarica: codice della scarica. Tale codice permette di individuare univocamente
una scarica nell’archivio delle scariche.
Campo Magnetico valore del campo magnetico toroidale. È un numero reale
(positivo o negativo) con un’unica cifra decimale ed esprime il valore in tesla del
campo magnetico toroidale
Corrente di Plasma: valore della corrente di plasma durante la fase stazionaria
(MAmpere). Talvolta viene impostata durante la fase stazionaria una rampa lenta e
pertanto devono essere memorizzati due valori di corrente: quello iniziale e quello
finale.
Densità: valore impostato della densità del gas. È un numero reale positivo con
un’unica cifra decimale ed esprime la densità del gas in m-3.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
114
Gas: esprime il tipo di gas usato. È una stringa che contiene i seguenti valori: ‘D’
per il deuterio, ‘H’ per l’idrogeno, ‘He’ per elio, ‘H+D’ per idrogeno e deuterio,
‘H+He’ per idrogeno ed elio. Ci sono anche scariche con deuterio più argon, ma
verranno considerate come scariche in deuterio.
Esito: riporta l’esito dello sparo. È una stringa che può contenere i seguenti
valori:
- Aborto Sparo
- Arresto Sequenza
- Disr. R.A. a t =
- Disr. R.F. a t =
- Disrompe a t =
- Nessun Plasma
- Non Acquisito
- OK
- Plasma OK
- Problemi Elettrotecnica
- Problemi Prometeo
- Quasi OK
- Run_Away
- Saltata a contatore
- Break-down
- Tecnologico OK
Nel caso della varie disruzioni ad un tempo specifico, va introdotto anche il valore
nel relativo campo.
Tempo di Disruzione: tempo di disruzione in millisecondi. È un intero che va
da zero a 2000.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
115
NOTE: campo note. È una stringa massima di 256 bytes.
4.3.2.
LE TABELLE HARDWARE E SOFTWARE
Le tabelle sono files, attualmente residenti su VAX-4000, in cui sono contenute le
informazioni di configurazione necessarie al DAS per l’acquisizione dei dati e la
generazione dei canali. Storicamente su FTU si è sempre distinto fra i dati acquisiti
dal DAS, provenienti dalle diagnostiche e quelli acquisiti da FDA provenienti dalle
misure elettriche di macchina. Questa distinzione, oltre ad essere concettuale è
anche fisica. Attualmente due distinti processi di acquisizione gestiscono le misure
del DAS e quelle di FDA ed esistono differenti files di configurazione per il DAS e
FDA. Le tabelle non gestiscono i canali dei dati PED.
Nell’ambiente sperimentale questi files di configurazione sono chiamati
semplicemente Tabella Hardware e Tabella Software in riferimento al loro
contenuto.
Entrambe le tabelle contengono campi i cui nomi sono composti da 4 lettere
maiuscole. I campi sono dei seguenti tipi:
• carattere (di diverse dimensioni: 8-20-40 bytes) con un valore ‘null’ di default
• intero (4 bytes) con il valore 1 di default
• reale (4 bytes) con il valore 0 di defult.
I campi impostati a valori differenti da quelli di default costituiscono l’insieme delle
informazioni di intestazione per il canale generato.
Di seguito si procederà ad una descrizione delle tabelle mettendo in evidenza le
caratteristiche salienti di quei campi che sono di rilevante interesse per il progetto.
Per una trattazione più completa si rimanda all’appendice C.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
116
TABELLA HARDWARE
Contiene le informazioni hardware connesse ai nomi logici usati nella Tabella
Software, nonchè le direttive per inizializzare ed acquisire i dati per tutti i tipi di
canali hardware.
I contenuti della tabella possono essere raggruppati secondo le seguenti aree di
interesse:
A. Informazioni generali sul modulo.
HAMN (char[8]): nome del canale hardware.
HAMM (char[8]): nome del modulo d’acquisizione.
HAIS (int): stato futuro del canale.
HAOF (int): coefficiente di offset per il segnale i input.
HABI (int): coefficiente di normalizzazione per il segnale i input.
B. Parametri di inizializzazione.
HIMM (int): memoria del modulo.
HINC (int): numero dei canali di input selezionati.
HIFR (int): frequenza di acquisizione.
C. Dati a disposizione del progettista di routine.
HD1..16 (int): parametri interi.
HF1..16 (float): parametri reali.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
117
D. Variabili indipendenti standard.
HVBN (int): numero di intervalli di campionamento (min 1, max 4).
HVUM (char[4]): unità di misura.
HVVN (char[8]): nome della variabile indipendente.
HVD1..4 (float): passo di campionamento per ogni intervallo.
HVJ1..4 (int): numero di campioni per ogni intervallo.
HVV1..4 (float): istante iniziale per ogni intervallo di campionamento.
E. Moduli opzionali necessari per il timing.
HZNB (int): numero di canali esterni.
HZN1..8 (char[8]): nome dei canali esterni.
TABELLA SOFTWARE
Descrive la situazione sperimentale, cioè le diagnostiche attive al momento dello
sparo insieme a tutte le informazioni per la generazione dei canali.
I records della tabella riguardano:
• Famiglie. Il nome è composto di 6 caratteri. Il raggruppamento in famiglie
permette una abilitazione/disabilitazione di un insieme di misure per le quali è
possibile stabilire un criterio di accorpamento. Questa associazione logica nulla
ha a che fare con la associazione fisica di canali che vengono acquisiti attraverso
un medesimo modulo CAMAC.
• Canali. Il nome è composto di due parti di 6 caratteri separate da un. La prima
parte identifica una famiglia, la seconda il canale. Per ogni sparo, un canale è
univocamente identificato dal suo nome.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
118
I contenuti della tabella possono essere raggruppati secondo le seguenti aree di
interesse:
A. Informazioni generali sul Canale. Tutti
i campi appartenenti a questo
gruppo costituiscono una parte dell’intestazione del canale.
ACHN (char[20]): nome univoco del canale nel formato famiglia.canale.
ACHT (int): specifica il tipo di canale secondo la codifica di tabella 4.1.
ASHN (int): numero di sparo.
ALBT (int): lunghezza in bytes della parte di intestazione del canale.
ALBD (int): lunghezza in bytes della parte dati del canale.
AFIN (int): numero di campi da aggiungere all’intestazione del canale.
Cod
Descrizione
15
misura semplice
512
famiglia
3
misura complessa, variabile indipendente
5
misura complessa, variabile dipendente
7
misura complessa, variabili dipendenti e indipendenti
64
elaborazione
31
calibrazione semplice
19
calibrazione complessa, variabile indipendente
21
calibrazione complessa, variabile dipendente
23
calibrazione complessa, variabile dipendente e indipendente
1
parametri
16
acquisizione remota (per le CPU VME)
Tabella 4.1 – Codifica del tipo di canale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
119
B. Informazioni opzionali. I campi appartenenti a questo gruppo sono a
disposizione di chi crea un proprio canale per conservare informazioni quali:
commenti, parametri interi e reali da utilizzare in applicazioni particolari.
C. Dati di acquisizione per l’elaborazione. I campi appartenenti a questo
gruppo rivestono particolare importanza in quanto definiscono le
caratteristiche fisiche del canale.
DNAC (int): definisce il numero di campioni acquisiti.
DTDA (int): definisce il tipo di dati del canale secondo la codifica di tabella
4.2
Codice
Descrizione
X
interi (X bytes)
1X
reali (X bytes)
1XX
stringa (XX bytes)
10XX
stringa(XX bytes)+valore intero(4 bytes)16
20XX
stringa (XX bytes)+valore reale (4 bytes)16
Tabella 4.2 – Codifica del tipo di dato.
D. Informazioni per l’elaborazione. Contiene indicazioni su come trattare i dati
del canale da parte del software applicativo.
EAPR (char[8]): in base al contenuto di questo campo è possibile eseguire
elaborazioni sui dati del canale corrispondente, in modo da fornire il vettore
della variabile dipendente. In tabella 4.3 sono riportate le opzioni disponibili
16
Gli ultimi due tipi di dati sono del tipo “nome-valore”.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
120
con le relative formule di elaborazione utilizzate poi dalle applicazioni
software.
Stringa di
codifica
STANDARD
STANDOFF
BIT
VOLT
PROMETEO
DIODI_DI
DIODI_RI
Elaborazione
Formula
ingegnerizzazione standard nell’unità [(val-QBOF)/QBBI]/
(QCR1*QCR2*QCR3*Q
di misura definita da EAUM
ingegnerizzazione standard
nell’unità di misura definita da
EAUM con sottrazione dell’offset
valore con sottrazione dell’offset
valore in volt della misura acquisita
ingegnerizzazione per misure del
sistema di controllo
per applicazioni specifiche
per applicazioni specifiche
CR4)
{[(val-QBOF)/QBBI]QCR5}/(QCR1*QCR2*
QCR3*QCR4)
Re(ival-QBOF)
(ival-QBOT)/QBBI
(ival-QBOF)*CCR1
+CCR2
non disponibile
non disponibile
Tabella 4.3 – Opzioni di elaborazione.
EAUM (char[4]) unità di misura della variabile dipendente (in MKSA)
ECI1..5 (int) ed ECR1..5 (float): vengono talvolta utilizzati per definire la
posizione del sensore. Queste informazioni hanno un’importanza notevole
per i sensori di campo magnetico installati sulla superficie esterna della
camera, e vengono utilizzati dai codici di equilibrio.
E. Canali necessari per l’elaborazione. Parametri che riguardano i canali %E.
F. Informazioni per la grafica. I
campi appartenenti a questo gruppo
contengono informazioni necessarie per l’uscita grafica della grandezza fisica.
GCA1 (char[20]): descrizione della variabile dipendente
GCI1..5 (int): parametri disponibili per il software applicativo.
GCR1..5 (float): parametri disponibili per il software applicativo.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
121
G. Parametri di acquisizione. I campi appartenenti a questo gruppo
consentono di convertire i dati grezzi acquisiti dai moduli hardware nelle
grandezze fisiche associate.
QACN (char[20]): nome del modulo hardware. Grazie a questo campo è
possibile relazionare zero o più canali software ad un modulo hardware.
QBBI (float): riprende il valore HABI della tabella Hardware.
QBOF(int): riprende il valore HAOF della tabella Hardware.
QCR1..5 (float): coefficienti reali per l’elaborazione
QRED (int): numero di dati che debbono essere immagazzinati nel canale.
Questo campo è utilizzato dal processo di acquisizione nel seguente modo:
Se QRED = -1 DAS pone nell’intestazione del canale acquisito QRED=HISR
(vedi tabella hardware)
Se QRED=0 tutti i dati definiti dai parametri di acquisizione del modulo
hardware associato vengono immagazzinati
Se QRED>0 vengono immagazzinati i primi QRED dati.
H. Variabili indipendenti interne o esterne. I campi appartenenti a questo
gruppo consentono di ricostruire la variabile indipendente. Questa può essere
ricostruita internamente con i valori dei campi appartenenti a questo gruppo,
oppure può essere definita esternamente con l’indicazione del canale i cui dati
costituiscono il vettore della variabile indipendente. Quando la variabile
indipendente è definita internamente, un massimo di 4 intervalli con diversi
passi di campionamento possono essere definiti.
VAAN (int): numero di variabili indipendenti per un massimo di 3 (per i dati
acquisiti è sempre 1)
VAD1..8 (int):
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
122
VAN1..8 (char[20]): descrizione della variabile indipendente (credo che qui si
definisca se la variabile è interna o esterna)
VAU1..8 (char[4]): unità di misura della variabile indipendente
VDA1..4, VDB1..4, VDC1..4 (float): passo di campionamento per ciascun
intervallo (1..4) relativamente ad ogni singola variabile indipendente (A, B, C).
VJA1..4, VJB1..4, VJC1..4 (int): numero di per ciascun intervallo (1..4)
relativamente ad ogni singola variabile indipendente (A, B, C).
VVA1..4, VVB1..4, VVC1..4 (float): valore per ciascun intervallo (1..4)
relativamente ad ogni singola variabile indipendente (A, B, C).
I. Informazioni per la lettura dei campi dai moduli. Parametri che entrano in
gioco se per l’acquisizione di un canale si ricorre all’uso di grandezze
provenienti da altri moduli di acquisizione.
J. Lista dei files interessati per l’acquisizione. Può accadere che dei moduli
debbano fare riferimento a dei file dati acquisiti da altri moduli.
ZAIF (char[20]): nome del file di input.
ZANB (int): numero di moduli che producono files di dati.
ZCN1 (char[8]): nome del modulo CAMAC che acquisisce il file di input.
K. Stato dei canali software.
S0SF (int): stato del canale.
S0GR (int): richiesta di grafico.
STCR (int): tempo critico (msec) per l’acquisizione.
S1NC (char[20]): nome del modulo CAMAC usato per la famiglia.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
4.3.3.
123
L’ARCHIVIO DEI DATI SPERIMENTALI
Il Pulse file, come unico file che contiene l’insieme dei dati acquisiti, è stato sostituito
da una struttura ad albero che permette di individuare direttamente il singolo
canale. In questo modo l’accesso ai dati basato prevalentemente sulle chiavi: sparocanale, risulta essere notevolmente ottimizzato.
Alcune note vanno evidenziate per avere una dettagliata descrizione dell’archivio
attualmente disponibile:
• I nomi dei canali (famiglia.canale) non superano i 20 caratteri. I caratteri speciali
($,*,/,?\) , non utilizzabili sotto un file system UNIX, sono stati sostituiti con i
caratteri (d,a,s,k,i) . All’interno del titolo di canale si è comunque conservato il
suo nome originario. Il mismatch fra il nome del canale e quello del file
corrispondente, nel caso fossero presenti i caratteri speciali precedentmente
indicati, viene risolto a livello applicativo.
• All’interno della directory dello sparo dei canali DAS vi sono 2 canali che non
hanno alcuna famiglia:
-
000001: contiene i parametri di impostazione del sistema di immissione gas,
-
000002: contiene la lista dei canali dello sparo (la presenza di questo canale
è una ridondanza mantenuta per ragioni di compatibilità con il software
applicativo).
• Storicamente i canali PED non erano raggruppati in famiglie. Successivamente si
è pensato di assegnare la famiglia DEFAULT a tutti i canali senza famiglia.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
124
L’ARCHIVIO DEI DATI DAS
Il dati di questo tipo una volta inseriti nel database non subiscono variazioni di
stato.
Ogni canale è immagazzinato in un file binario. Questo è composto da un header di
dimensione fissa (100 bytes) seguito da un header di dimensione variabile, in coda
seguono i dati veri e propri.
L’header fisso contiene i seguenti campi:
ACHN (char[20]): nome del canale (vedi Tabelle Software).
ACHT (int): tipo di canale (vedi Tabelle Software).
AART (int): tipo di archivio (vedi Tabelle Software).
ASHN (int): numero di sparo (vedi Tabelle Software).
ALBT (int): dimensione del titolo in bytes.
ALBD (int): dimensione dei dati in bytes.
AFIN (int): numero dei parametri opzionali presenti nella sezione compressa.
ADYE (int): anno.
ADYM (int): mese.
ADYY (int): giorno.
ADZH (int): ora.
ADZM (int): minuto.
ADZS (int): secondo.
DNAC (int): numero totale di dati.
DTDA (int): tipo di dati (vedi Tabelle Software).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
125
L’header di dimensioni variabili, detto compresso, contiene quelle informazioni,
provenienti dalla relativa Tabella Software, i cui valori non sono di default.
L’header compresso è costituito da una serie di record, tanti quanti specificati dal
parametro AFIN, posti di seguito al titolo fisso. La struttura adoperata per tali
record prevede un campo di quattro bytes col nome del parametro, un campo di un
byte per il tipo, un campo di un byte che indica la lunghezza della stringa se il tipo è
char, quattro bytes per il valore se è di tipo numerico.
Nome
5
6
Lunghezza
4
Tipo
0
Valore
Figura 4.7 – Struttura dei campi dell’header compresso.
L’ARCHIVIO DEI DATI POST-ELABORATI (PED)
Contiene i dati prodotti da tutti i codici di elaborazione che sono eseguiti alla fine di
ciascun sparo, o ottenuti durante elaborazioni successive. Il nome di ciascun canale
nell’archivio PED inizia con il carattere ‘$’ , per questo che i dati sono spesso
chiamati: canali ‘$’.
Ogni canale è immagazzinato in un file binario. Questo è composto da un header di
dimensione fissa (100 bytes) seguito da un header di dimensione variabile, in coda
seguono i dati veri e propri.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
126
L’header fisso contiene i seguenti campi:
ACHN (char[20]): nome del canale (vedi Tabelle Software).
ACHT (int): tipo di canale (vedi Tabelle Software).
NDIM (int): numero di variabili indipendenti, min 1, max 4.
AART (int): tipo di archivio (vedi Tabelle Software).
ASHN (int): numero di sparo (vedi Tabelle Software).
ALBT (int): dimensione del titolo in bytes.
ALBD (int): dimensione dei dati in bytes.
AFIN (int): numero dei parametri opzionali presenti nella sezione compressa.
ADYE (int): anno.
ADYM (int): mese.
ADYY (int): giorno.
ADZH (int): ora.
ADZM (int): minuto.
ADZS (int): secondo.
DNAC (int): numero totale di dati della variabile dipendente.
DTDA (int): tipo di dati (vedi Tabelle Software).
NTOTX (int): numero totale di dati delle variabili indipendenti.
A seguire vi sono delle sezioni che descrivono le variabili del canale, prima quella
dipendente, poi quelle indipendenti che vanno da un minimo di una ad un massimo
di quattro.
Numero di dati (int): se riguarda la variabile dipendente non può che coincidere
con DNAC. Se riguarda una variabile indipendente può accadere che tale valore
sia negativo, nel qual caso significa che il dato è in forma compressa ossia
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
127
contiene solo due valori: istante iniziale e passo di campionamento; mentre il
numero di campioni è dato dal modulo del valore in questione.
Label (char[20]): è il nome della variabile.
Unità di misura (char[12]): unità di misura della variabile.
Tipo di dato (int): ricalca il significato di DTDA ma può assumere la codifica
solo del il tipo intero o reale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
128
4.4. MODELLO SEMANTICO DEI DATI DI FTU
Come si evince dall’analisi delle specifiche, il fulcro dell’archivio di FTU è costituito
dalle misure effettuate nel corso dell’esperimento. L’obiettivo che ci si prefigge è
costruire un modello che possa ben descrivere non solo i dati di FTU ma anche
quelli di altri laboratori fusionistici. Malgrado la particolarità degli esperimenti
restano fondamentali i concetti di Sparo, Famiglia e Canale che costituiscono il
fulcro, gerarchizzato, dell’informazione.
L’idea è di fornire un modello a massimo comune divisore da cui ogni laboratorio
possa espandere, secondo le proprie esigenze, uno schema proprietario.
L’inconveniente potrebbe consistere in una base comune troppo ristretta, il che
porterebbe comunque ad avere delle differenze sostanziali incolmabili tra i diversi
schemi.
In figura 4.8 si osserva come la struttura di base sia molto sintetica ed allo stesso
tempo molto generale. Partendo da questo modello è poi semplice derivarne altri
che descrivano più propriamente le specifiche tipologie dei diversi laboratori.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
129
Sparo
num_sparo
data
attributi...
famiglie : Famiglia
Famiglia
nome
canali : Canale
descrizione : Descrizione
Canale
nome
descrizione : D escrizione
header : Head er
dati : Dati
Descrizione
stringhe...
Header
parametri...
Da ti
array di int, float, ...
Figura 4.8 – Modello semantico dei dati sperimentali.
Ad esempio, nel caso di FTU in cui sono presenti due diverse tipologie di dati,
nettamente
distinguibili
tra
esse,
quali
canali
provenienti
direttamente
dall’esperimento tramite il DAS e canali provenienti da elaborazioni successive, la
struttura assume la morfologia di figura 4.9.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
130
Sparo
num_sparo
data
attributi...
famiglie : Famiglia
Famiglia
nome
canali : Canale
descrizione : Descrizione
Canale
De scri zi one
nome
descrizione : Descrizione
heade r : Header
dati : Dati
stringhe...
CanaleDAS
CanalePP
header : HeaderDAS
dati : Dati
header : HeaderPP
dati : Dati
HeaderDAS
parametri...
Dati
array di int, float, ...
HeaderPP
pa ram etri ...
Figura 4.9 – Modello semantico dei dati sperimentali di FTU.
Come si può ben vedere la specializzazione, dovuta alle peculiarità di FTU, non
pregiudica assolutamente la struttura portante dell’architettura che continua quindi
a mantenere tutte le sue prerogative di generalità.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
131
4.5. SCHEMA LOGICO DEI DATI DELL’ARCHIVIO DI FTU
La modellazione dell’archivio di FTU verrà realizzata seguendo non l’importanza
scientifica del dato ma la sua priorità cronologica rispetto al sistema di acquisizione
dati.
Di conseguenza, verrà da principio presa in considerazione quella parte riguardante
i
settaggi
dell’hardware
preposto
all’acquisizione
dei
dati
provenienti
dall’esperimento, quindi sarà la volta degli strumenti atti a trasformare il dato
grezzo proveniente dai moduli di acquisizione in veri e propri canali dati, i quali
costituiscono il cuore stesso dell’archivio.
Lo schema di interazione tra il database ed il resto del sistema è presentato in figura
4.10.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
132
con figure s
uses
HardWare Table
Diagnostics
Tokamak
uses
FTU_Actors
OO-DB
DAS
Quaderno di bordo
uses
Shot
configures
crea tes
Post Processing Families
Data Acqui siti on Fa milies
SoftWare Table
Post Proces sing Channels
Data Acquisition Channels
create s
Software di analisi
Figura 4.10 – Schema di interazione tra il database ed il sistema.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
uses
Cap.4 – Specifiche ed analisi del problema
4.5.1.
133
LE TABELLE HARDWARE
È innanzitutto necessario osservare che, nell’accezione comune dell’ambiente di
FTU, il termine Tabella Hardware individua un insieme di records ognuno dei quali
contiene il setting di un Canale Hardware di acquisizione.
Nel seguito con lo stesso termine si indicherà una classe una cui istanza (oggetto)
conterrà tutte informazioni necessarie al setting di un solo canale. Di conseguenza
si farà spesso riferimento alle ‘Tabelle Hardware’ come all’insieme di oggetti istanze
della suddetta classe.
Si osserva che vi è una corrispondenza biunivoca tra i nuovi oggetti ed i vecchi
records, ragion per cui non ci si soffermerà sugli attributi delle varie classi se non
per puntualizzare le eventuali differenze o nuove funzionalità.
Il fulcro di questa sezione è costituito dalla classe Hard_Table che contiene una serie
di informazioni generali sul Canale Hardware il quale dipenderà fisicamente da un
certo modulo di acquisizione il cui tipo è descritto dalla classe Module_Type
(figura 4.11).
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
134
Figura 4.11 – Schema logico delle Tabelle Hardware.
Ad ogni oggetto di tipo Hard_Table corrisponde un oggetto appartenente alla classe
Setting_Parameters la quale a sua volta sarà costituito da oggetti appartenenti a delle
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
135
classi atte a descrivere le specifiche funzionalità riguardanti il setting vero e proprio
dei canali hardware.
Tutte le classi che riguardano questa parte del progetto sono state, per semplicità
d’uso, accorpate nel Package FTUdb.HardTables.
4.5.2.
LE TABELLE SOFTWARE
Anche in questo caso vale quanto detto in precedenza per le Tabelle Hardware,
poiché con ‘Tabelle Software’ si individuerà l’insieme di oggetti che caratterizzano i
Canali Software.
In questo caso il ruolo centrale è ricoperto dalla classe Soft_Table. Ad essa sono
legate la classe Status e la classe Optional_Parameters (figura 4.12)
Quest’ultima a sua volta risulta essere l’aggregazione di un insieme di altre classi che
contengono le informazioni necessarie alla trasformazione dei dati grezzi (senza
cioè nessun particolare valore se non quello di pure sequenze di bits) in
informazione concreta.
Le prime due classi sono state accorpate nel package FTUdb.SoftTables, mentre la
classe Optional_Parameters e quelle ad essa aggregate sono state accorpate nel
package FTUdb.OptPar.
Questo perché i cosiddetti “parametri opzionali” non riguardano solo le tabelle
software ma sono parte integrante ed indispensabile dei canali di acquisizione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
Figura 4.12 – Schema logico delle Tabelle Software.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
136
Cap.4 – Specifiche ed analisi del problema
4.5.3.
137
I DATI SPERIMENTALI
Nella modellazione della parte concernente i dati sperimentali non ci si è attenuti
rigorosamente alla struttura gerarchizzata presentata in precedenza. Questo perché
in effetti l’appartenenza di un canale ad una famiglia piuttosto che ad un’altra ha un
valore puramente associativo e di nessuna importanza relativamente al contenuto
del canale stesso.
I canali si distinguono in due tipologie differenti: quelli provenienti direttamente dal
DAS (Data_Acquisition_Channel) e quelli frutto di elaborazioni successive
(Post_Processing_Channel) (figura 4.13)
I primi, come già detto, oltre a possedere i dati provenienti dall’esperimento hanno
bisogno, per avere un senso, delle informazioni contenute negli oggetti di tipo
Optional_Parameters.
I secondi invece contengono l’informazione sotto forma esplicita in due o più
arrays. Rispetto alla struttura dei cosiddetti canali $ si è scelto di avere, oltre ai dati
di tipo Integer già presenti, quelli di tipo Double anziché di tipo Float, in previsione
di una futura necessità di maggior precisione.
Nella classe di tipo Post_Processing_Stream, si osserva la presenza dell’attributo
DNAC che contiene il numero di punti dello stream di dati. Tale informazione, a
prima vista ridondante, si rende necessaria a causa della particolare struttura di
questi streams. Difatti, nel caso in cui uno stream contenga ad esempio l’asse dei
tempi, può accadere che essendo i campioni presi con passo costante non viene
memorizzato l’intero array ma solo il valore iniziale ed il passo di campionamento,
ragion per cui DNAC ci permette di conoscere il numero di campioni da
considerare.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
Figura 4.13 – Schema logico dei dati sperimentali.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
138
Cap.4 – Specifiche ed analisi del problema
4.5.4.
SCHEMA COMPLETO
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
139
Cap.4 – Specifiche ed analisi del problema
4.5.5.
140
VINCOLI
Vista la particolare natura del sistema, prima dell’implementazione dei vincoli sul
database è importante osservare che un requisito fondamentale è la velocità con cui
i dati vengono immessi nell’archivio. Infatti, a fine esperimento, i fisici hanno
l’esigenza di visionare i risultati il più presto possibile. Tenendo conto della grande
mole di dati acquisiti e della loro frammentarietà, risulta evidente che
l’implementazione di un gran numero di vincoli è causa certa di un crollo delle
prestazioni. Bisogna inoltre tener conto, che i dati provengono da processi i quali,
di per se stessi, tendono a restituire dati consistenti e che in ogni caso eventuali
errori di trasmissione non potrebbero essere rilevati.
Per quanto riguarda poi i vincoli di integrità referenziale, non essendo previste
esplicite operazioni di cancellazione, il problema non si pone nemmeno. Anche le
operazioni di modifica degli oggetti non possono provocare inconsistenza dei dati,
infatti nel caso di modifica ( si pensi agli oggetti di tipo Optional_Parameters,
condivisi e dalle Tabelle Software e dai Canali ), quello che si fa è istanziare un
nuovo oggetto con lo stato desiderato abbandonando il riferimento a quello
precedente. Nel caso in cui questi non fosse referenziato da nessun altro oggetto,
automaticamente provvederebbe alla sua eliminazione il tool di Garbage Collection
dell’OODBMS.
In definitiva, visto che i processi del DAS forniscono dei dati già consistenti, non
rimane che focalizzare l’attenzione laddove l’immissione dei dati è da tastiera, ossia
nelle Tabelle Hardware e Software. Qui i vincoli sono quasi esclusivamente sul
dominio degli attributi e sono stati ampiamente trattati nel paragrafo riguardante
l’analisi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
141
Ad ogni modo risulta efficace implementare direttamente sul database i vincoli di
chiave riguardanti:
•
Hard_Table.HAMN
•
Module_type.HAMM
•
Soft_Table.ACHN
•
Shot.ASHN
•
Family.Name
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
4.5.6.
142
OPERAZIONI SUL DB
Le operazioni che vengono eseguite sul DB possono essere effettuate o
direttamente dagli utenti oppure dal DAS.
Gli utenti eseguono generalmente tre tipologie di operazioni:
-
accesso in lettura e scrittura delle Tabelle Hardware,
-
accesso in lettura e scrittura delle Tabelle Software,
accesso in lettura dei Canali.
Le prime due prima dell’esperimento, la terza successivamente.
Il DAS esegue tre tipologie di operazioni:
-
accesso in lettura delle Tabelle Hardware,
-
accesso in lettura delle Tabelle Software,
-
accesso in scrittura dei Canali.
La prima precedentemente all’esperimento, le altre due successivamente.
Di seguito vengono elencate le operazioni che è richiesto sia possibile compiere sul
DataBase:
Operazione: INSERT di un nuovo Modulo di Acquisizione
Input: Module_Type
Output: Module_Type
Descrizione: Inserimento di un nuovo oggetto di tipo Module_Type.
Se esiste già un oggetto con lo stesso nome (HAMM) restituisce
un’eccezione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
Operazione: SELECT di un Modulo di Acquisizione
Input: String
Output: Module_Type
Descrizione: Se presente restituisce l’oggetto avente l’HAMM desiderato.
Operazione: SELECT di tutti i Moduli di Acquisizione
Input:
Output: Collection di Module_Type
Descrizione: Restituisce tutti gli oggetti di tipo Module_Type.
Operazione: UPDATE delle proprietà di un Modulo di Acquisizione
Input: Module_Type
Output: void
Descrizione: Modifica lo stato di un oggetto di tipo Module_Type.
Operazione: DELETE un Modulo di Acquisizione
Input: Module_Type
Output: void
Descrizione: Cancella un oggetto del tipo Module_Type.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
143
Cap.4 – Specifiche ed analisi del problema
144
Operazione: INSERT di una Tabella Hardware
Input: Hard_Table
Output: Hard_Table
Descrizione: Inserisce nel db un oggetto del tipo Hard_Table. Se esiste già un
oggetto con la stessa chiave (HAMN) restituisce un’eccezione.
Viene effettuato un controllo per non immagazzinare oggetti
referenziati, che abbiano lo stesso stato di oggetti già presenti.
Operazione: SELECT di una Tabella Hardware
Input: String
Output: Hard_Table
Descrizione: Se presente restituisce l’oggetto avente la chiave desiderata,
altrimenti restituisce un’eccezione.
Operazione: SELECT di tutte le Tabelle Hardware
Input:
Output: Collection di Hard_Table
Descrizione: Restituisce tutti gli oggetti di tipo Hard_Table.
Operazione: UPDATE di una Tabella Hardware
Input: Hard_Table
Output: void
Descrizione: Modifica lo stato di un oggetto del tipo Hard_Table, o di uno o più
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
145
oggetti da esso referenziato.
Operazione: DELETE una Tabella Hardware
Input: Hard_Table
Output: void
Descrizione: Cancella un oggetto del tipo Hard_Table. Gli oggetti referenziati
dall’oggetto cancellato non vengono interessati dall’operazione, in
quanto possono essere in sharing con altri oggetti.
Operazione: INSERT di una Tabella Software
Input: Soft_Table
Output: Soft_Table
Descrizione: Inserimento un oggetto del tipo Soft_Table. Se esiste un oggetto
con la stessa chiave (ACHN) restituisce un’eccezione.
Operazione: SELECT di una Tabella Software
Input: String
Output: Soft_Table
Descrizione: Restituzione dell’oggetto di tipo Soft_Table con la chiave (ACHN)
desiderata. Se non è presente restituisce un’eccezione.
Operazione: SELECT di tutte le Tabelle Software
Input:
Output: Collection di Soft_Table
Descrizione: Restituzione di tutti gli oggetti del tipo Soft_Table.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
146
Operazione: UPDATE di una Tabella Software
Input: Soft_Table
Output: void
Descrizione: Modifica lo stato di un oggetto del tipo Soft_Table, o di uno o più
oggetti da esso referenziati.
Operazione: DELETE di una Tabella Software.
Input: Soft_Table
Output: void
Descrizione: Cancellazione di un oggetto del tipo Soft_Table. Gli oggetti
referenziati dall’oggetto
cancellato non vengono interessati
dall’operazione in quanto possono essere in condivisione.
Operazione: INSERT di una Famiglia
Input: Family
Output: Family
Descrizione: Inserisce un oggetto della classe Family nel db.
Se tale oggetto è già presente restituisce un’eccezione.
Operazione: SELECT di una Famiglia
Input: String
Output: Family
Descrizione: Se esiste restituisce l’oggetto del tipo Family avente la chiave
(ACHN) desiderata, altrimenti restituisce un’eccezione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
147
Operazione: SELECT di tutte le famiglie
Input:
Output: Collection di Family
Descrizione: Restituisce tutti gli oggetti istanze della classe Family.
Operazione: UPDATE di una famiglia
Input: Family
Output: void
Descrizione: Modifica lo stato di un oggetto del tipo Family
Operazione: INSERT di uno Shot
Input: Shot
Output: Shot
Descrizione: Inserisce l’oggetto di tipo Shot. Se già esistente restituisce
un’eccezione.
Operazione: SELECT di uno Shot
Input: String
Output: Shot
Descrizione: Se esiste restituisce l’oggetto di tipo Shot avente la chiave (ASHN)
desiderata, altrimenti restituisce un’eccezione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
148
Operazione: SELECT tutti gli Shots
Input:
Output: Collection di Shot
Descrizione: Restituisce tutti gli oggetti appartenenti alla classe Shot.
Operazione: SELECT di tutti i Canali di un dato Shot
Input: Shot
Output: Collection di Shot
Descrizione: Restituisce tutti gli oggetti di tipo Channel referenziati da un dato
oggetto di tipo Shot. Se il suddetto non esiste restituisce
un’eccezione.
Operazione: SELECT di tutte le Famiglie di un dato Shot
Input: Shot
Output: Collection di Shot
Descrizione: Restituisce tutti gli oggetti di tipo Family referenziati dall’oggetto
di tipo Shot.
Operazione: SELECT dei Canali di una data Famiglia per un dato Shot
Input: Shot, Family
Output: Collection di Channel
Descrizione: Restituisce tutti i canali di una dato oggetto di tipo Shot referenziati
da un dato oggetto di tipo Family.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap.4 – Specifiche ed analisi del problema
149
Operazione: SELECT di un Canale di un dato Shot
Input: Shot, String
Output: Channel
Descrizione: Se esiste, restituisce l’oggetto di tipo Channel avente la chiave
(ACHN) desiderata e referenziato da un certo oggetto di tipo Shot,
altrimenti restituisce un’eccezione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
150
5
Capitolo
5. REALIZZAZIONE
Lo scopo che ci si prefigge è quello di avere una realizzazione di
studio, per poter valutare l’effettiva portata ed efficacia del progetto. A
tal fine per una prima release del prodotto è stato scelto un software
shareware quale ‘ObjectStore PSE Pro for Java™, che estendendo
delle classi del Java, realizza la persistenza degli oggetti.
Non avremo quindi a che fare con un OODBMS, con tutte le
limitazioni che ne conseguono. In particolare durante la realizzazione
sono state fatte delle scelte che si allontanano dal progetto originale,
ma che si sono rese necessarie per non inficiare le prestazioni di
accesso ai dati, già troppo condizionate dallo strumento impiegato.
Tali modifiche verranno per altro evidenziate e commentate all’atto
della loro introduzione.
Ci si propone di implementare successivamente il progetto
impiegando un prodotto più adatto alle esigenze del caso. Tale
prodotto, dopo un attento ed accurato studio, è stato individuato in
Objectivity/DB™, che per le sue caratteristiche e potenzialità ben si
adatta alla gestione di un archivio di tale entità.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
5.1. SCHEMA RISTRUTTURATO
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
151
Cap. 5 – Realizzazione
152
5.2. STRUTTURA DEL SOFTWARE
Per maggior chiarezza ed eleganza l’intero pacchetto software è contenuto nel
Package FTUdb. All’interno di questo, vi sono i quattro packages contenenti le
classi che modellano l’archivio ed inoltre tutte le classi necessarie all’interfaccia
utente ed in generale all’interazione con il database.
FTUdb
HardTable
SoftTable
Channels
OptPar
Figura 5.1 – Struttura dei packages.
Nei paragrafi seguenti verrà effettuata una descrizione sommaria delle classi
disponibili e delle loro funzionalità. Per una più accurata documentazione si
rimanda in ogni caso al codice.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
153
Lo schema delle classi appartenenti al package FTUdb può essere modellizzato
come in figura:
HttpServlet
ChannelServlet
SoftServlet
HardServlet
FtuO ODBP rovi der
(f r om J Scop e)
Da te
(f r om FTUdb )
DeleteMenu
Ma nager
(f r om F TUdb )
(f r om FTUdb )
Utility
(f rom FTUdb)
OO-DB
(f rom Use Case View)
Im portMan ager
(f rom FTUdb)
Read HardFi le
ReadAcquisitionFile
(f rom FTUdb)
(f rom FTUdb)
ReadSoftFile
(f rom FTUdb)
ReadProcessedFile
(f rom FTUdb)
Figura 5.2 – Struttura delle classi.
Si fa notare che la presenza della classe Date si è resa necessaria a causa
dell’impossibilità da parte del PSE di rendere persistenti le classi di tipo java.util.Date
o ad essa equivalenti, se non impiegando delle particolari librerie non disponibili
nella versione shareware del prodotto.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
5.2.1.
154
LE CLASSI D’ACCESSO AL DATABASE
Classe: Manager
Descrizione: Gestisce l’accesso al DB.
Attributi
Nome
Tipo
db
Database ObjectStore database
Session
Session
Sessione sul database
allHardTables
Map
Contenitore di root
allDataTiming
Set
Contenitore di root
allInitParameters
Set
Contenitore di root
allModuleType
Set
Contenitore di root
allOptModules
Set
Contenitore di root
allStdInd
Set
Contenitore di root
allSoftTables
Map
Contenitore di root
allAcquisition
Set
Contenitore di root
allData
Set
Contenitore di root
allGeneralInfo
Set
Contenitore di root
allGraphicInfo
Set
Contenitore di root
allIndepVar
Set
Contenitore di root
allListFiles
Set
Contenitore di root
allModulesFields
Set
Contenitore di root
allNeedElab
Set
Contenitore di root
allInfoElab
Set
Contenitore di root
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Descrizione
Cap. 5 – Realizzazione
155
allStatus
Set
Contenitore di root
allFamilies
Map
Contenitore di root
allShots
Map
Contenitore di root
allShotsKeys
Map
Contenitore di root
allAcquisitionChannels
Set
Contenitore di root
allPostProcessingChannels
Set
Contenitore di root
allByteStreams
Set
Contenitore di root
allShortStreams
Set
Contenitore di root
allIntStreams
Set
Contenitore di root
allFloatStreams
Set
Contenitore di root
allDoubleStreams
Set
Contenitore di root
allStringStreams
Set
Contenitore di root
allStringIntStreams
Set
Contenitore di root
allStringFloatStreams
Set
Contenitore di root
allIntPostProcessingStreams
Set
Contenitore di root
allDoublePostProcessingStreams Set
Contenitore di root
Metodi
Nome
Input
Output
Descrizione
inizialize
String
void
Inizializza la Session sul
db
Chiude la Session
Restituisce il numero di
elementi presenti in una
certa root
Inserisce un Modulo
shutdown
void
sizeOfElement
String
int
insertModule
Module_Type Module_Type
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
selectModule
156
String
Module_Type
Restituisce un Modulo
String[ ]
updateModule
Module_Type void
Restituisce i nomi di
tutti i Moduli
Modifica un Modulo
deleteModule
String
void
Cancella un Modulo
void
Cancella tutti i Moduli
Inserisce una Tabella
Hardware
Restituisce una Tabella
Hardware
Restituisce tutte le
Tabelle Hardware
Modifica una Tabella
Hardware
Cancella un oggetto del
tipo Hard_Table
Cancella tutti gli oggetti
del tipo Hard_Table
Inserisce una Tabella
Software
Restituisce una Tabella
Software
Restituisce tutte le
Tabelle Software
Modifica una Tabella
Software
Cancella un oggetto del
tipo Soft_Table
Cancella tutti gli oggetti
del tipo Soft_Table
Restituisce un oggetto
del tipo Family
Restituisce tutti gli
oggetti del tipo Family
Modifica un oggetto del
tipo Family
listAllModules
deleteAllModules
insertHardTable
Hard_Table
Hard_Table
selectHardTable
String
Hard_Table
listAllHardTables
Collection
updateHardTable
Hard_Table
void
deleteHardTable
String
void
deleteAllHardTables
void
insertSoftTable
Soft_Table
Soft_Table
selectSoftTable
String
Soft_Table
listAllSoftTables
Collection
updateSoftTable
Soft_Table
void
deleteSoftTable
String
void
deleteAllSoftTables
selectFamily
void
String
allFamilies
updateFamily
Family
Collection
Family
void
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
selectShot
157
String
Shot
allShots
Collection
allShotsKeys
Set
selectChannelShot
Shot, String
allChannelsShot
Shot
Collection
allFamiliesShot
Shot
Collection
allFamilyChannelsShot Shot
Set
deleteChannel
String, String
void
deleteFamilyShot
String, String
void
deleteShot
String
void
get_yx_axes
Channel
Float_Array[ ]
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Restituisce un oggetto
del tipo Shot
Restituisce tutti gli
oggetti del tipo Shot
Restituisce le chiavi
(ASHN) di tutti gli
oggetti di tipo Shot
Restituisce Canale
Per un dato sparo
restituisce tutti i Canali
Per un dato sparo dà un
elenco di tutte le
famiglie presenti
Per un dato sparo
restituisce tutti i canali
appartenenti ad una data
famiglia
Cancella un Canale
Per un dato sparo
elimina tutti i canali di
una famiglia
Cancella uno Shot
Ingegnerizza e
restituisce i dati di un
canale
Cap. 5 – Realizzazione
158
Classe: ImportManager extends Manager
Descrizione: gestisce il porting dei dati dal vecchio archivio.
Attributi: nessuno
Metodi
Nome
Input
Output
Descrizione
Inserisce un
oggetto di tipo
Family nel db
Restituisce un
selectFamily
String
Family
oggetto di tipo
Family
Inserisce un
insertShot
Shot
void
oggetto di tipo
Shot nel db
Referenzia un
addChannelToShot
Shot, Channel void
Canale al relativo
Shot
Restituisce un
selectShot
String
Shot
oggetto di tipo
Shot
Inserisce un
insertStream
Stream
Stream
oggetto di tipo
Stream nel db
Inserisce un array
insertPostProcessingStreams Post_Processi Post_Processi di oggetti di tipo
ng_Stream[ ] ng_Stream[ ] Post_Processing_
Stream nel db
Inserisce un
insertDataAcquisitionChannel Data_Acquisit Data_Acquisit oggetto di tipo
ion_Channel ion_Channel Data_Acquisition
_Channel nel db
Inserisce un
insertPostProcessingChannel Post_Processi Post_Processi oggetto di tipo
ng_Channel ng_Channel Post_Processing_
Channel nel db
insertFamily
Family
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Family
Cap. 5 – Realizzazione
159
Classe: Utility
Descrizione: fornisce degli strumenti utili al trattamento dei dati.
Attributi: nessuno
Metodi
Nome
Input
Output
Descrizione
listDir
String
String[ ]
sortString
String[ ]
String[ ]
invertShort
byte[ ]
short
invertInt
byte[ ]
int
invertFloat
byte[ ]
float
invertDouble
byte[ ]
double
Restituisce l’elenco dei files e delle
subdirectories di una certa directory
Ordina ascendentemente un array di
stringhe
Converte uno short dal formato
LittleIndian a quello BigIndian
Converte un intero dal formato
LittleIndian a quello BigIndian
Converte un float dal formato
LittleIndian a quello BigIndian
Converte un double dal formato
LittleIndian a quello BigIndian
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
160
Classe: Date
Descrizione: modella la data.
Attributi
Nome
Tipo
Descrizione
year
int
Anno
month
int
Mese
day
int
Giorno
hour
int
Ora
minute
int
Minuto
second
int
Secondo
Metodi
Nome
Input
Output
Descrizione
set
int, int, int,
int, int, int
Date
void
Effettua il setting di una data
void
Effettua il setting di una data
int
Compara due oggetti di tipo Date
set
compareTo
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
5.2.2.
161
ROUTINES DI POPOLAMENTO DEL DB
Le routines preposte al popolamento della base di dati sono quattro:
• ReadHardFile. Scansiona un file di dump della tabella hardware acquisendo le
informazioni relative ai canali hardware.
• ReadSoftFile. Scansiona un file di dump della tabella software acquisendo le
informazioni relative ai canali software.
• ReadAcquisitionFile. Acquisisce gli shots con i relativi canali di acquisizione
attingendo direttamente dall’archivio esistente.
• ReadProcessedFile. Acquisisce i canali di post elaborazione attingendo
direttamente dall’archivio esistente.
5.2.3.
INTERFACCIA UTENTE
L’interfaccia tra utenti e database è stata implementata tramite le Servlet di Java.
Il relativo sito Internet sviluppato su piattaforma Windows NT 4.0, è gestito da
Apache (versione 1.3.12). Le servlets vengono trattate da Jserv for Apache
(versione 1.1).
Le funzionalità messe a disposizione dell’utente si limitano alla visione ed alla
modifica delle Tabelle Hardware e delle Tabelle Software, nonché alla visione delle
informazioni relative agli shots, alle famiglie ed ai canali.
È stata prevista una Servlet per ognuna delle tre aree logiche dell’archivio:
• HardTableServlet. Si occupa dell’accesso alle Tabelle Hardware.
• SoftTableServlet. Si occupa dell’accesso alle Tabelle Software.
• ChannelServlet. Si occupa dell’accesso agli shots attraverso diverse strategie di
navigazione, prediligendo soprattutto il ben noto aspetto gerarchico dei dati.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
Figura 5.3 – Interfaccia di accesso al database tramite web.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
162
Cap. 5 – Realizzazione
5.2.4.
163
METODI DI ELABORAZIONE DEI DATI
Come noto i dati si distinguono in dati di acquisizione e dati di post elaborazione.
Questi ultimi, essendo appunto frutto di elaborazioni successive all’esperimento,
possiedono l’informazione in modo esplicito, viceversa per ottenere l’informazione
dai canali acquisiti bisogna ‘ingegnerizzarli’ usando le informazioni contenute nei
Parametri Opzionali.
A scopo dimostrativo, solo per i canali monodimensionali, è stato implementato il
metodo Manager.get_yx_axes( ), che invocando i metodi y_axis( ) ed x_axis( ) su un
oggetto di tipo Channel, sia esso d’acquisizione o di post elaborazione, restituisce
due array di float, i quali rappresentano una funzione discreta di una variabile.
Nei due casi gli algoritmi possono essere così schematizzati:
• asse x:
VVA
VDA
ALG
out
VJA
Figura 5.4 – Algoritmo di calcolo dei valori dell’asse delle ascisse.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
X
Cap. 5 – Realizzazione
164
Dove:
-
Indep_Var.VVA
contiene
gli
istanti
iniziali
dei
sottointervalli
campionamento,
-
Indep_Var.VDA contiene i passi di campionamento relativi ai sottointervalli,
-
Indep_Var.VJA contiene il numero di campioni per ogni sottointervallo.
-
ALG esegue l’algoritmo:
int size=0;
int count=0;
int i=0;
float point=0;
for(int j=0;j<4;j++)
size+=VJA[j];
float[] x=new float[size];
while(count<size && i<4){
point=VVA[i];
x[count]=point;
..count++;
if(VJA[i]!=0)
for(int k=0;k<(VJA[i]-1);k++){
point+=VDA[i];
x[count]=point;
count++;
}
i++;
}
VVA[0]+VDA[0]
VVA[0]
VVA[1]+VDA[1]
VVA[1]
VVA[0]+VDA[0]*VJA[0]
VVA[2]
VVA[1]+VDA[1]*VJA[1]
Figura 5.5 – Struttura dell’intervallo di campionamento.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
VVA[3]
di
Cap. 5 – Realizzazione
165
• asse y:
out
out
IN
0
TEST_1
0
TEST_2
1
1
0
TEST_2
1
ALG_1
out
Y_1
Figura 5.6 – Algoritmo di calcolo dei valori delle ordinate.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
ALG_2
out
Y_2
Cap. 5 – Realizzazione
Dove:
- IN è il dato grezzo del canale,
- TEST_1 effettua un test sul parametro Info_for_Elab.EAPR,
- TEST_2 effettua un test su Acquisition.QCR,
- ALG_1 esegue l’algoritmo:
for(int i=1;i<4;i++)
den*=QCR[i];
for(int i=0;i<y.length;i++)
y[i]=(y[i]-QBOF)/(QBBI*den);
- ALG_2 esegue l’algoritmo:
for(int i=1;i<4;i++)
den*=QCR[i];
for(int i=0;i<y.length;i++)
y[i]=(((y[i]-QBOF)/QBBI)-QCR[5])/den;
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
166
Cap. 5 – Realizzazione
5.2.5.
167
INTERAZIONE CON ALTRI APPLICATIVI
Per visionare i grafici delle misure si è impiegato JavaScope, un programma
realizzato dal CNR di Padova per RFX, il locale laboratorio fusionistico. Tale
programma, anch’esso realizzato in Java, permette di attingere, da una qualsiasi
fonte dati, la mappatura per punti di una funzione di variabile, per poi restituirne il
grafico.
A tal guisa è stata realizzata una classe che funge da interfaccia tra JavaScope e la
fonte dati costituita dall’OODB.
Physicians
JScope
FtuOODBProvider
(from JScope)
Manager
(from FTUdb)
OO-DB
(from Use Case View)
Figura 5.7 – Schema di interazione tra l’utente e il database attraverso JavaScope.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Cap. 5 – Realizzazione
Figura 5.8 – Grafico di un segnale prelevato dall’OODB.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
168
Conclusioni
169
CONCLUSIONI
Vista la particolare natura dei dati sperimentali di tipo Tokamak la metodologia
orientata agli oggetti si è rivelata di particolare efficacia nel suo impiego come
strumento e di analisi e di sintesi.
In linea con gli obiettivi prefissati, il frutto del lavoro svolto si è concretizzato in
uno schema logico che descrive appieno la realtà di interesse e permette la sua
esportazione verso altri sistemi della stessa natura. La realizzazione del progetto è
stata portata a termine con notevole efficacia malgrado le limitazioni imposte dallo
strumento di archiviazione usato, la cui scelta è stata guidata da considerazioni di
tipo economico.
Pur non avendo impiegato un OODBMS altamente performante il prodotto
realizzato ha evidenziato le potenzialità delle tecnologie OO nell’ambito del
trattamento di dati sperimentali; si è inoltre rivelato un ottimo strumento di
indagine dell’archivio esistente riuscendo a cogliere delle informazioni finora
inaccessibili e di rilevante interesse dal punto di vista statistico.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
APPENDICE
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
170
Appendice
171
A. IL LINGUAGGIO UML
Introduzione
L
a creazione di modelli è di fondamentale importanza per la trattazione di
problemi più o meno complessi. Scopo del modello è permettere
l’astrazione di situazioni concrete così da eliminarne i dettagli superflui e potersi
così concentrare sui dati essenziali. In altre parole il modello permette una
rappresentazione della realtà tale da poterne cogliere più certi aspetti di particolare
interesse, che non altri.
Nello sviluppo di un sistema informatico è necessario astrarre diversi aspetti dal
suddetto, crearne dei modelli, verificare che essi soddisfino i requisiti, ed aggiungere
progressivamente dettagli che trasformino tali modelli in una implementazione.
La consapevolezza del ruolo centrale che ricopre l’individuazione degli elementi
essenziali di una data situazione ha avuto come naturale sviluppo la transizione da
approcci di tipo procedurale ad approcci cosiddetti orientati agli oggetti. In un
approccio di tipo procedurale l’attenzione era concentrata sul “come” risolvere un
dato problema, mentre in un approccio di tipo Object-Oriented l’enfasi è posta
sugli elementi costitutivi (oggetti) della realtà di interesse e sul modo in cui essi
interagiscono fra loro.
Utilizzare quindi il modello Object-Oriented nell’ambito della progettazione di sistemi
permette di separare le proprietà e le competenze delle diverse parti di cui saranno
costituiti i sistemi stessi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
172
Dalla fine degli anni ‘80 all’inizio degli anni ‘90 si è assistito al proliferare di
metodologie di Object-Oriented Analysis and Design (OOA&D). Tra le principali
si possono certamente annoverare la Object Modeling Technique (OMT),
sviluppata da Jim Rumbaugh, il metodo Booch, che prende il nome del suo
inventore Grady Booch, e la Object-Oriented Software Engineering (OOSE),
ideata da Ivar Jacobson.
Ciascuna delle suddette metodologie, pur avendo un sua validità, prediligeva un
aspetto particolare dello studio di un sistema complesso, fornendo strumenti più
adatti all’analisi e meno allo sviluppo o viceversa.
La costante evoluzione dei sistemi informatici e la necessità che essi rispondano alle
aspettative degli utenti richiedono una stretta interazione fra tutte le parti coinvolte
nella realizzazione e nell’utilizzazione dei sistemi stessi. Affinché questa interazione
possa essere proficua, è fondamentale disporre di un efficace e condiviso substrato
di comunicazione, in altre parole di un linguaggio comune.
Recentemente, Booch, Rumbaugh e Jacobson hanno deciso di unificare le loro
metodologie nel tentativo di porre fine alla confusione derivante dalla presenza sul
mercato di diverse notazioni, e allo stesso tempo, utilizzare quanto di meglio
ciascun approccio potesse offrire. Nasce così UML (Unified Modeling Language),
che si avvia a divenire lo standard de facto come linguaggio di modellazione per
sistemi Object-Oriented.
Grady, Booch e Jacobson hanno anche messo a punto un processo unificato di
sviluppo denominato Objectory Process. L’Objectory Process prevede un
approccio di tipo iterativo ed incrementale, nel senso che lo sviluppo di un sistema
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
173
procede attraverso una serie di iterazioni che evolvono nel tempo fino alla
realizzazione finale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
174
Che cos’e UML?
U
ML, è un linguaggio di modellazione, non un metodologia. Una
metodologia consiste infatti, in linea di principio, di un linguaggio di
modellazione e di un processo di sviluppo. Il linguaggio di modellazione è la
notazione che la metodologia utilizza per descrivere un progetto, mentre il
processo rappresenta la serie di passi necessari per sviluppare il progetto stesso.
UML può quindi essere utilizzato congiuntamente ad un qualsiasi processo di
sviluppo e non necessariamente assieme all’Objectory Process proposto da Grady,
Booch e Jacobson. Inoltre, per assicurare flessibilità ed estendibilità, UML consente
l’uso di stereotipi, ovvero di classificazioni di alto livello utilizzabili per creare nuovi
elementi di modellazione. Uno stereotipo viene rappresentato includendone il
nome tra due coppie di parentesi angolari17.
UML consente di presentare e documentare un progetto complesso fornendone
differenti viste, ciascuna delle quali descrive un aspetto rilevante del sistema ad un
diverso livello di astrazione.
In termini di viste di un modello, UML definisce quindi i seguenti diagrammi:
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
♦ Diagramma dei casi d’uso (Use Case Diagram)
♦ Diagramma delle classi (Class Diagram)
♦ Diagrammi di comportamento (Behavior Diagrams)
• Diagrammi di interazione (Interaction Diagrams)
 Diagramma di sequenza (Sequence Diagram)
 Diagramma di collaborazione (Collaboration Diagram)
• Diagrammi di stato (Statechart Diagrams)
♦ Diagrammi di implementazione (Implementation Diagrams)
• Diagramma dei componenti (Component Diagram)
• Diagramma di sviluppo (Deployment Diagram)
17
Tipici esempi di stereotipi sono <<extends>>, o <<control>> per le classi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
175
Appendice
176
Diagrammi dei casi d’uso
I
diagrammi dei casi d’uso (Use Case) servono a descrivere il comportamento
ad alto livello del sistema. Un diagramma Use Case illustra infatti le
funzionalità del sistema, chi (o cosa) vi interagirà e le modalità di tali interazioni.
Essi forniscono quindi un valido supporto alla comunicazione tra tutti i soggetti
coinvolti nella realizzazione e nell’utilizzazione del sistema.
Le funzionalità del sistema vengono rappresentate graficamente da ellissi
(contenenti il nome della funzionalità stessa) denominate appunto Use Case.
Formalmente, uno Use Case è la sequenza di azioni compiute dal sistema per
produrre un risultato rilevante per un determinato utilizzatore.
Gli utilizzatori delle funzionalità vengono rappresentati da omini stilizzati
denominati Actor. Un Actor può essere una persona che ricopre un determinato
ruolo nell’utilizzazione del sistema, o un sistema esterno che può interagire con
quello in questione. In ogni caso, un Actor è un entità esterna al sistema e non ne è
quindi parte.
L’interazione tra un Actor ed uno Use Case è rappresentata da un arco che li
congiunge. Gli archi possono essere orientati o non orientati a seconda che la
comunicazione sia unidirezionale o bidirezionale. Un Actor infatti può immettere
informazioni nel sistema (arco diretto dall’Actor verso lo Use Case), può ricevere
informazioni (arco diretto dallo Use Case verso l’Actor), oppure può sia immettere
che ricevere informazioni (arco non orientato). Possono inoltre essere presenti due
tipi di relazioni tra Use Case, denominate uses e extends, per evidenziare
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
177
rispettivamente dipendenza o generalizzazione. Una relazione di tipo uses tra uno
Use Case A ed uno Use Case B denota il fatto che A utilizza funzionalità fornite da
B, mentre una relazione di tipo extends da A a B indica che A esprime un
comportamento opzionale rispetto a B.
update accounts
Accounting
System
<<extends>>
request catalog
place order
<<uses>>
<<uses>>
supply customer data
Customer
Salesperson
<<uses>>
arrange payment
order product
fill orders
establish credit
Shipping Clerk
Supervis or
Figura A.1 – Esempio di Use Case Diagram
Nei diagrammi le relazioni uses ed extends vengono evidenziate etichettando i
rispettivi archi con gli stereotipi <<uses>> e <<extends>>.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
178
Diagrammi di classe
D
opo aver definito le funzionalità del sistema si rende necessaria la
identificazione degli oggetti che contribuiscono alla loro realizzazione. Per
oggetto si intende un’entità ben definita che abbia una rilevanza specifica nel
sistema. Più precisamente un oggetto di un sistema è individuato da tre
caratteristiche: stato, comportamento e identità.
Lo stato di un oggetto è una delle possibili condizioni in cui esso si può trovare,
condizione mutabile nel tempo e definita da un insieme di proprietà, chiamate
attributi, e dalle relazioni con altri oggetti. Il comportamento, invece, determina come
un oggetto risponde alle richieste provenienti da altri oggetti e caratterizza tutto ciò
che può fare definendo per esso un insieme di operazioni. L’identità, infine,
caratterizza univocamente ogni oggetto, permettendo così di distinguerlo da altri
oggetti aventi le medesime caratteristiche.
Oggetti aventi le stesse proprietà (attributi), lo stesso comportamento (operazioni),
le stesse relazioni con gli altri ed infine la stessa semantica si considerano istanze di
una medesima classe.
In UML, un oggetto è rappresentato da un rettangolo contenente il nome
dell’oggetto stesso (sottolineato), seguito da quello della classe di appartenenza
(anch’esso sottolineato). La sintassi per il nome di un oggetto è dunque la seguente:
objectName: ClassName
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
179
Una classe invece è rappresentata da un rettangolo diviso in tre compartimenti
contenenti rispettivamente il nome, gli attributi e le operazioni. In aggiunta, è
possibile specificare uno stereotipo per la classe (vedi figura A.2).
L’Objectory Process prevede l’uso di tre stereotipi base denominati entity, boundary e
control. Una classe etichettata <<entity>> è tipicamente indipendente dall’ambiente
circostante, ossia da come le classi di contorno comunicano con il sistema e, molto
spesso, è indipendente dall’applicazione stessa. Le classi entity vengono anche dette
domain-class in quanto hanno a che fare con astrazioni di entità del mondo reale.
Una classe <<boundary>>, invece, è preposta alla gestione della comunicazione tra
il sistema e l’ambiente esterno, e tra le varie parti del sistema stesso. Le classi
boundary costituiscono quindi l’interfaccia verso un utente o verso un altro sistema.
<<stereotype>>
Le ClassName
classi <<control>>, infine, coordinano gli eventi necessari a realizzare la
attribute : Type = initValue
funzionalità specificata in uno Use Case.
opname(argname : Type) : returnType
Figura A.2 – Esempio di classe
In un diagramma di classe (Class Diagram), oltre alle classi, si rappresentano anche
le relazioni statiche che sussistono fra esse. Le relazioni fra classi possono essere di
tre tipi fondamentali: associazione, aggregazione ed ereditarietà.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
180
Una relazione di associazione fra due classi indica la presenza di un legame fra le loro
istanze (oggetti), ovvero evidenzia la possibilità che esse si scambino messaggi in
entrambe le direzioni. Quando esiste una associazione tra oggetti di una stessa
classe, la relazione viene detta riflessiva. In UML, una associazione è rappresentata
da una linea continua che congiunge le classi implicate in tale relazione. Una
associazione unidirezionale viene invece detta relazione di dipendenza. Una relazione
di dipendenza tra una classe A, detta client, ed una classe B, detta supplier, è utilizzata
per evidenziare che A fa uso di funzionalità (metodi) fornite da B. In UML, una
relazione di dipendenza è rappresentata da una freccia diretta dalla classe client
verso quella supplier.
La relazione di aggregazione è invece usata per visualizzare un rapporto di
contenimento fra oggetti. Il fatto che un’istanza di una classe A sia composta da
una o più istanze di una classe B viene indicato da una linea, congiungente A e B, e
recante un piccolo rombo in prossimità di A. Infine, una relazione di ereditarietà
fornisce la possibilità di strutturare in modo gerarchico, e quindi secondo diversi
livelli di astrazione, le classi.
L’ereditarietà può assumere due forme: generalizzazione e realizzazione. La
generalizzazione permette di creare superclassi che incapsulano struttura e
comportamento comuni a più classi, mentre la realizzazione evidenzia il fatto che
una data classe implementa le operazioni offerte da un’interfaccia.
Ogni relazione può essere etichettata con un verbo che suggerisca il significato di
tale relazione. In alternativa, per le associazioni, è possibile utilizzare i cosiddetti
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
181
ruoli, cioè dei nomi, collocati vicino ad una classe, che indichino lo scopo o la
capacità di tale classe nel contesto dell’associazione in cui essa prende parte.
E’ inoltre possibile specificare la molteplicità di una relazione, ossia il numero di
oggetti che vi partecipano. Tipici esempi di indicatori di molteplicità sono:
0..*
Zero o più
1..*
Uno o più
0..1
Zero o uno
5..8
Intervallo specifico (5, 6, 7, opp. 8)
4..7,9 Combinazione (4, 5, 6, 7 opp. 9)
Order
dateReceived : Date
number : String
totalPrice : Money
Customer
1 name : String
address : String
0..*
dispatch()
close()
creditRating() : String
1
CorporateCustomer
contactName : String
creditLimit : Money
PersonalCustomer
creditCard# : String
1..*
OrderLine
product : Product 0..*
quantity : Integer
price : Money
1
Product
Figura A.3 – Esempio di Class Diagram
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
182
Classi aventi funzionalità simili, o che comunque abbiano affinità semantica,
vengono raggruppate in uno stesso package, rappresentato, in UML, da una cartella.
L’unica relazione possibile fra package è quella di dipendenza. Un package P
dipende da un package Q se una o più classi contenute in P stabiliscono una
comunicazione con una o più classi pubbliche del package Q. In tal caso,
analogamente a quanto visto per le classi, il package P viene detto client ed il
package Q supplier.
Order
Capture UI
AWT
Order
Capture
Orders
Mailing List
UI
Mailing List
Application
Customers
Figura A.4 – Esempio di Package Diagram
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
183
Diagrammi di comportamento
U
na volta definiti gli oggetti necessari alla realizzazione di una specifica
funzionalità del sistema e le relazioni (statiche) fra essi, è importante
individuare il loro comportamento. Per comportamento si intende sia l’interazione
fra oggetti diversi (rilevabile negli Interaction Diagram), sia il cambiamento di stato
di uno stesso oggetto (evidenziabile negli Statechart Diagram)18. Una analisi
comportamentale è di fondamentale importanza per verificare che gli oggetti
precedentemente definiti siano effettivamente adatti per produrre la funzionalità
richiesta e, in caso contrario, per correggere le assunzioni fatte.
18
Interaction e Statechart diagram vengono generalmente definiti Behavior Diagram per sottolineare il loro comune
scopo di rappresentazione del comportamento degli oggetti.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
184
Diagrammi di interazione ( sequenza e
collaborazione)
I
digrammi di interazione (Interaction Diagram), come già accennato, servono
a descrivere le interazioni fra oggetti, interazioni che possono essere
presentate dando maggiore enfasi alla sequenza temporale con cui vengono
scambiati i messaggi, oppure privilegiando il quadro complessivo di come avviene
la collaborazione tra gli oggetti stessi.
Nel primo caso si useranno i cosiddetti Sequence Diagram, nel secondo, invece, i
Collaboration Diagram. In un Sequence Diagram gli oggetti vengono rappresentati
da rettangoli contenenti il nome dell’oggetto stesso e della classe di appartenenza.
Da ogni oggetto inoltre parte una linea tratteggiata, detta timeline (o anche lifeline),
dalla quale (e verso la quale) partono (ed arrivano) i messaggi. Un messaggio è
rappresentato da una freccia che parte dalla timeline del mittente (client) ed arriva
alla timeline del ricevente (supplier). Ogni freccia è collocata più in basso rispetto
alla precedente.
In un Collaboration Diagram, invece, i legami tra gli oggetti sono rappresentati da
linee continue ed i messaggi da frecce orientate dal mittente verso il ricevente.
Un esempio di Sequence Diagram e fornito nella figura A.5, mentre in figura A.6 è
possibile vedere il Collaboration Diagram corrispondente.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
185
theCreditWindow :
CreditWindow
: Supervisor
1: enter login name
2: enter password
3: verify password
4: set Credit
Figura A.5 – Esempio di Sequence Diagram
3: verify password
1: enter login name
2: enter password
theCreditWindow :
CreditWindow
: Supervisor
4: set Credit
aCostumer :
Customer
Figura A.6 – Collaboration Diagram corrispondente
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
aCostumer :
Customer
Appendice
186
I diagrammi di stato
I
diagrammi di stato (Statechart Diagrams19) servono a focalizzare il
comportamento di un singolo oggetto analizzandone l’evoluzione in relazione
a sollecitazioni esterne.
Il comportamento di un dato oggetto viene quindi presentato come una serie di
transizioni fra stati. Lo stato di un oggetto è la condizione in cui esso si trova
quando verifica determinate condizioni, compie un’azione, o attende il verificarsi di
un evento. Lo stato di un oggetto, inoltre, può essere caratterizzato dal valore di
uno o più dei suoi attributi. Si ha una transizione, invece, quando lo stato di un
oggetto evolve in uno successivo (eventualmente uguale a quello originario). Le
transizioni possono essere automatiche o non-automatiche. Una transizione
automatica avviene quando l’attività dello stato originario è completata, ovvero
occorre senza essere indotta da un evento esterno; per questa ragione le transizioni
automatiche vengono anche dette spontanee. Una transizione non-automatica, invece, è
causata da un evento che può essere originato da un altro oggetto o dall’esterno del
sistema; per questo motivo tali transizioni vengono anche definite indotte.
In UML, lo stato di un oggetto è rappresentato da un rettangolo con gli angoli
arrotondati, mentre una transizione come una freccia diretta dallo stato originario
verso quello successivo. Nei diagrammi, inoltre, è possibile evidenziare lo stato
iniziale di un oggetto (Start State) e uno o più dei suoi stati finali (Stop State) come
mostrato in figura A.7.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Generic State
Start State
Stop State
Appendice
187
Figura A.7 – Notazione UML per gli stati di un oggetto
Ad una transizione, infine, può essere associata una action e/o una guard condition.
Una action rappresenta l’operazione (o le operazioni) che l’oggetto compie quando
avviene la transizione, mentre la guard condition è un’espressione booleana che
permette il verificarsi della transizione solo se tale espressione risulta vera.
La sintassi completa per descrivere una transizione è dunque la seguente:
event_name [guard condition] / action
Un esempio di state diagram è mostrato in figura 4.7.
Start
/ get first item
get next item[ not all items checked]
Checking
[ all itemscheckedANDsomeitemsnot available]
[ all itemscheckedANDall items available]
itemreceived[ someitemsnot available]
Waiting
Dispatching
itemreceived[ all itemsavailable]
delivered
Delivered
Figura A.8 – Esempio di State Diagram
19
Anche detti State transition diagram
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
188
Diagrammi di implementazione (componenti e
sviluppo)
D
opo aver definito le classi, le loro relazioni ed il loro comportamento,
inizia la fase di implementazione, cioè di realizzazione della struttura del
codice e della struttura dell’ambiente esecutivo dei processi. I diagrammi di
implementazione (Implementation Diagram) hanno quindi scopo quello di
mostrare i vari aspetti implementativi del software.
Essi si dividono in due tipi: Component Diagram e Deployment Diagram. I
Component
Diagram
presentano
una
vista
dell’architettura
incentrata
sull’organizzazione modulare del sistema, con particolare rilievo alla gestione del
software ed alle problematiche connesse con il riuso e la portabilità. Gli elementi di
cui è costituito un Component Diagram sono i package, i componenti software, e le
loro connessioni. Un package, in questa visione dell’architettura, rappresenta una
partizione fisica del sistema, ovvero un sottosistema. La notazione UML per i package
dei Component Diagram è la stessa usata nei Class/Package Diagram. In generale,
ad ogni package logico ne corrisponde uno fisico, ma possono esservi casi in cui si
renda necessario dividere un package logico in più package fisici, o unire più
package logici in un unico package fisico. Un componente, invece, rappresenta un file
di codice il cui tipo dipende dal particolare linguaggio utilizzato per
l’implementazione. La notazione UML per i componeneti è riportata in figura 4.9.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
189
ComponentName
Figura A.9 – Rappresentazione di un componente software
Per la corrispondenza tra classi e componenti software valgono considerazioni
analoghe a quelle concernenti la mappatura tra package logici e fisici.
Customer.class
Order.class
OrderLine.class
Product.class
Figura A.10 – Esempio di Component Diagram
I Deployment Diagram, invece, mostrano la corrispondenza tra processi e nodi di
elaborazione. Per nodo di elaborazione si intende una risorsa di elaborazione,
generalmente dotata di una memoria e di capacità di processamento. Su un dato
nodo di elaborazione possono essere attivi più processi contemporaneamente, e più
istanze di uno stesso processo possono essere eseguite su diversi nodi elaborazione.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
190
La vista dell’architettura presentata in un Deployment Diagram è incentrata quindi
su requisiti quali affidabilità, prestazione e scalabilità del sistema.
Application
Server 1
Router
Proc ess 1
Proc ess 2
Proc ess 3
Routin gProc es s
Database
Server
Trans ac tio nManager
Application
Server 2
Proc ess 1
Proc ess 2
Proc ess 4
Proc ess 5
In UML, un nodo di elaborazione viene rappresentato da una vista tridimensionale
di un cubo ed i processi che vi risiedono vengono elencati vicino al nodo stesso.
Infine i nodi possono essere collegati da linee indicanti l’esistenza di percorsi di
comunicazione fra essi (vedi figura 4.11).
Figura A.11 – Esempio di Deployment Diagram
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
191
B. JAVADOC20
A
nalizzando la documentazione ufficiale di Java o di una libreria Java di un
certo livello, si nota che lo stile è alquanto uniforme. La documentazione
di una libreria è molto importante, ma mantenere sincronizzate la libreria con la
documentazione può essere spesso molto faticoso, e non sono rari errori di
allineamento. Scrivere la documentazione direttamente nei sorgenti potrebbe essere
una soluzione, ma ciò comporta la distribuzione dei sorgenti. Anche se questo può
non rappresentare un problema per il programmatore, lo può rappresentare per
l’utente che deve andare direttamente nei sorgenti della libreria per cercare di capire
a cosa serve una certa funzione.
Lo strumento Javadoc, basandosi su una certa convenzione sulla scrittura dei
commenti in un programma, genera automaticamente la documentazione in
formato html comprensiva dei link che permettono la navigazione tra le varie classi.
Si ottiene così una documentazione a livello professionale.
I commenti riconosciuti da Javadoc hanno il seguente formato
/**
* Questo è un commento di una <b>classe</b>.
*
* @see nome di eventuali classi correlate.
*/
public class Classe {...}
/**
* Questo è un commento di un <b>metodo</b>.
*
* @param nomeParametro Commento al parametro.
*
* @return Commento a cosa restituisce il metodo.
*
* @see nome di eventuali classi correlate.
*/
public void Metodo(int i_iParametro) {...}
20
The Java API Documentation Generator.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
192
Da notare che è possibile utilizzare i tag standard dell’HTML (tranne alcuni, come
quelli degli header). Vi sono poi dei tag particolari interpretati da javadoc che
permettono di realizzare documentazione come quella del jdk. I tag @see
permettono di introdurre automaticamente dei link ad altre classi. Per una tr
attazione completa si rimanda alla documentazione ufficiale.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
193
C. TABELLE HARDWARE E SOFTWARE
Tabella Hardware
INFORMAZIONI GENERALI SUL MODULO
Parametro
Tipo
Descrizione
HAMN
char
Nome del modulo di acquisizione
HAMM
char
Modello del modulo di acquisizione
HAIS
int
Stato del modulo
HAFS
int
Stato dopo lo sparo
HAMT
int
Tipo di modulo
HACB
int
Branch21
HACC
int
Crate
HACN
int
Station
HAOP
int
Modo operativo
HAOF
int
Offset di campionamento
HABI
real
Parametro di normalizzazione
HAUM
char
Unità di misura
HAST
int
HSEL
int
HSNE
int
HSNT
HSPR
21
int
Esegue stampe di controllo
Branch, Crate e Station sono sostanzialmente le coordinate che individuano fisicamente la collocazione del
modulo di acquisizione
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
194
PARAMETRI DI INIZIALIZZAZIONE DEI MODULI
Parametro
Tipo
Descrizione
HIMM
int
Memoria del modulo di acquisizione
HINC
int
Numero di canali di input selezionati
HIPO
int
Numero di campioni post-trigger
HIPE
int
Numero di campioni pre-trigger
HIFR
real
Frequenza di acquisizione
HIOF
int
Registro di offset
HISR
int
Range selezionato
HIFL
char
File di input utente oppure note particolari.
PARAMETRI A DISPOSIZIONE DEL PROGETTISTA
Parametro
Tipo
HD[1..16]22
int
HF[1..16]
real
22
Descrizione
array
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
195
VARIABILI INDIPENDENTI
Parametro
Tipo
Descrizione
HVNB
int
Numero di intervalli acquisiti con campionamenti differenti(>0,<5)
HVUM
char
Unità di misura
HVVN
char
Variabile indipendente
HVNT
int
Numero di main sequence usati per fermare il trigger
HVT[1..4]
real
Tempi di trigger
HVD[1..4]
int
Intervalli di acquisizione
HVJ[1..4]
int
Numero di campioni
HVV[1..4]
char
Istanti iniziali
MODULI OPZIONALI ASSOCIATI PER IL TIMING
Parametro
Tipo
Descrizione
HZNB
int
Numero di moduli
HZN[1..9]
char
Nome dei moduli
HZI[1..9]
char
Campi di input selezionati
HZF[1..9]
char
Campi di output selezionati
HZC[1..9]
real
Coefficienti a disposizione
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
196
Tabella Software
INFORMAZIONI GENERALI SUL CANALE
Parametro
Tipo
Descrizione
ACHN
char
Nome del canale
ACHT
int
Tipo di canale
AART
int
Tipo di archivio (desueto)
ASHN
int
Numero di sparo
ALBT
real
Lunghezza in byte della tavola di canale
ALBD
int
Lunghezza dei dati
AFIN
int
Numero di campi
AUND
int
Numero di dati letti dall’utente con WKCHAN
AUNB
int
Numero di byte letti dall’utente con WKCHAN
INFORMAZIONI OPZIONALI
Parametro
Tipo
Descrizione
CACM
char
CCA[1..5]
char
Campo usato per i commenti e per le descrizioni. Se ACHT=512
parte la routine indicata.
Campi alfanumerici a disposizione
CCI[1..9]
int
Parametri interi disponibili per l’utente
CCR[1..9]
real
Parametri reali
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
197
DATI DI ACQUISIZIONE PER L’ELABORAZIONE
Parametro
Tipo
Descrizione
DNAC
int
Numero di campioni acquisiti
DNEX
int
Numero di campioni attesi
DTCM
int
Tipo di compattazione (desueta)
DTDA
int
Tipo di dato
DUNM
char
Unità di misura
INFORMAZIONI PER L’ELABORAZIONE
Parametro
Tipo
Descrizione
EAPR
char
Programma di elaborazione
EAUM
int
Unità di misura
ECI[1..5]
int
Coefficienti interi disponibili per l’utente
ECR[1..5]
real
Coefficienti reali disponibili per l’utente
ECST
int
Storage dei risultati elaborati (0-1)
ENBS
int
Numero dei canali connessi prodotti
ESN[1..6]
char
Suffisso del nome di canale %E
CANALI NECESSARI ALL’ELABORAZIONE
Parametro
Tipo
Descrizione
FNBN
int
Numero di canali necessari
FNBO
int
Numero di canali opzionali
FNC[1..6]
char
Nome dei canali necessari
FOC[1..6]
char
Nome dei canali opzionali
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
198
INFORMAZIONI PER I GRAFICI
Parametro
Tipo
Descrizione
GAPR
char
Programma di grafica
GCA1
char
Stringhe alfanumeriche disponibili per l’utente
GCI[1..5]
int
Coefficienti interi disponibili per l’utente
GCR[1..5]
real
Coefficienti reali disponibili per l’utente
ACQUISIZIONE
Parametro
Tipo
Descrizione
QACN
char
Nome del modulo di acquisizione
QAIN
int
Identificativo del canale hardware
QBBI
real
HBIT
QBOF
int
HOFF
QCR[1..5]
real
Coefficienti reali necessari per la ricostruzione del segnale
QLCN
char
Nome del file dati contenente i nomi dei canali di acquisizione
QRED
int
Numero di dati che debbono essere immagazzinati nel pulse file
QSTC
int
Storage dei canali di acquisizione
QUNM
char
Unità di misura
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
199
VARIABILI INDIPENDENTI INTERNE O ESTERNE
Parametro
Tipo
Descrizione
VAAN
int
Numero delle variabili indipendenti
VAD[1..8]
int
VAN[1..8]
char
Nome delle variabili indipendenti
VAU[1..8]
char
Unità di misura delle variabili indipendenti
VBBN
int
Numero di intervalli differenti per ogni variabile indipendente
VDA[1..4]
real
Coefficienti
VDB[1..4]
real
VDC[1..4]
real
VJA[1..4]
int
VJB[1..4]
int
VJC[1..4]
int
VVA[1..4]
real
VVB[1..4]
real
VVC[1..4]
real
INFORMAZIONI PER LA LETTURA DEI CAMPI DAI MODULI
Parametro
Tipo
Descrizione
XANB
int
Numero di campi letti dal modulo di acquisizione
XCF[1..9]
real
Coefficienti
XCN[1..9]
char
Nome dei moduli di acquisizione
XFN[1..9]
char
Campi di output della tabella software selezionata
XIN[1..9]
char
Campi di input della tabella hardware selezionata
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
200
LISTA DEI FILE INTERESSATI PER L’ACQUISIZIONE
Parametro
Tipo
Descrizione
ZAIF
char
File di input
ZANB
int
Numero di moduli che producono files di dati
ZCN[1..6]
char
Nome dei moduli
STATO DEI CANALI SOFTWARE
Parametro
Tipo
Descrizione
S0SF
int
S0GR
int
Stato del canale (0 no acquisizione, 1 acquisizione da CAMAC, 10
acquisizione da VME)
Grafica on-line
STDL
int
Delay minimo per la famiglia di acquisizione
S1NC
char
Nome del modulo usato per la famiglia del canale
S1IN
int
Input del modulo CAMAC
STCR
int
Tempo critico per la famiglia di acquisizione
S0PR
int
SELF
int
Elaborazione della tavola di canale
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
201
D. ALGORITMO DI ELABORAZIONE CANALE
* Plasma energy confinement time from THOMSON SCATTERING measurements
*
* CALLING SEQUENCE: %E.TSCTAUE
*
N_VARIABLES = 10
// numero di variabili definite da A a J
A = '$EQVBELI'
// pone in A il canale $EQVBELI
B = '$EQVIPLA'
// pone in B il canale $EQVIPLA
C = '$TSCWEL'
// pone in C il canale $TSCWEL
D = '(%MEA(2.*.935*3.1415E-07*B**2*A,0.02)):(A)'
E = '(%DER(D)):(D)'
// %MEA è un operatore di media
// %DER è un operatore di derivazione
F = '(E-%DER(C)*2./3.0):(C)'
G = '$EQVVPLA'
H = '(%MEA(B*G,0.02))'
I = '(H-F):(F)'
J = '(2.*C/I):(I)'
X_VALUE = 'X'
// l’output del canale ha come variabile indipendente il tempo
X_LABEL = 'TIME'
//label dell’asse x
X_UNIT = 'S'
// unità di misura dell’asse x
Y_VALUE = 'J'
//l’output del canale ha come variabile dipendente ‘J’
Y_LABEL = 'TAUE_THOM_SCATT'
//label dell’asse y
Y_UNIT = 'S'
//unità di misura dell’asse y
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Appendice
E.
202
CONVENZIONI
Vengono di seguito definite delle regole che permettono di aumentare la leggibilità
del codice e di facilitare l’individuazione di errori.
Tipo
Convenzione
Il nome di un package comincia sempre con almeno
una lettera maiuscola. Se vi sono dei packages
Package contenuti in un altro questi saranno preceduti dal
nome del package superiore, seguiti da un punto
quindi dal nome del sotto package.
I nomi delle classi devono iniziare con una lettera
maiuscola. Nel caso di nomi composti le diverse parti
Classe
cominceranno per maiuscola e saranno unita da un
under score (_).
Vale la regola delle classi con l’aggiunta della lettera I
Interfaccia
per identificare l’interfaccia
I nomi degli oggetti devono iniziare con una lettera
Oggetto minuscola. Se formati da nomi composti quelli
successivi al primo cominceranno per maiuscola
I nomi degli attributi derivanti direttamente dal
vecchio archivio di FTU, per continuità, sono costituiti
Attributo
da quattro caratteri maiuscoli. Gli altri attributi
cominciano per minuscola.
I nomi dei metodi devono iniziare con una lettera
Metodo minuscola. Se composti, i nomi successivi
cominceranno per maiuscola.
I nomi delle costanti devono essere sempre maiuscoli.
Costanti Le parti in cui è composto un nome vengono collegate
mediante il simbolo “_”.
Per l’indentazione si usa una tabulazione di 2 spazi.
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Esempio
FTUdb,
FTUdb.SoftTable
Channel,
Soft_Table
Channel,
softTable
ACHN,
streams
preDestroy()
Appendice
Esempio:
package Firstpackage.Secondpackage;
public class Class implements Super_Class
{
static final const CONST=1;
private int i;
public void insertShot(Shot shot)
{
allShots.put(shot);
}
}
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
203
Indice analitico
204
BIBLIOGRAFIA
[1] UML Summary, version 1.1, 1 September 1997
[2] UML Notation Guide, version1.1, September 1997
[3] UML Semantics, version 1.1, 1 September 1997
[4] Object Constraint Language Specification, version 1.1, 1 September 1997
[5] Martin Fowler with Kendall Scott, UML Distilled: Applying the Standard Object
Modelling Language, Addison-Wesley, 1997
[6] Terry Quatrani, Visual Modeling with Rational Rose and UML,
Addison-Wesley, 1998
[7] Bruce Eckel, Thinking in Java, Prentice-Hall, 1998
[8] Andrew S. Tanenbaum, Computer Networks, 3rd Edition, Prentice-Hall, 1996
[9] T. Connoly, C. Begg, A. Strachan, DataBase Systems: A practical approach to
design, implementation and management, Addison-Wesley, 1998
[10] F. Mandrioli, OODBMS: Object Oriented Database Management Systems,
DEIS Università di Bologna
[11] C. Giolito, Basi di Dati orientate agli oggetti, Università di Torino
[12] C. Savy, S. Russo, L. Merone, A. Sergio, Sistemi distribuiti ad Oggetti,
Università di Napoli Federico II
[13] G. McFarland, A. Rudmik, D. Lange, Object-Oriented Database Management
System Revisited, DoD DACS, 1999
[14] Bookshelf for ObjectStore Personal Storage Edition (PSE)/PSE Pro Release 6.0 for
Java
[15] Frascati Tokamak Upgrade – Project Description, ENEA, Ottobre 1992
[16] Fusion Annal Report, ENEA, 1986
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Indice analitico
205
[17] Fusion Annal Report, ENEA, 1990-91
[18] Fusion Annal Report, ENEA, 1992-93
[19] Fusion Annal Report, ENEA, 1994-95
[20] Fusion Annal Report, ENEA, 1997
[21] M. Panella et al., A commercial real-time manufcturing integration platform for the new
control system on FTU, ENEA, 1999
[22] V. Vitale et al., A 10 KHz Feedback Control System for Plasma Shaping on FTU,
ENEA
[23] 11th IEEE NPSS Real Time Conference Santa Fe 1999, Real time computing
applications in nuclear and plasma science
[24] G. Bracco, O. Tudisco, SHOW: A program for the integrated analysis of the data
produced in a nuclear fusion experimental device, ENEA, Febbraio 1998
[A1] D. Barry, ODMG 2.0: A Standard for Object Storage, Component Strategies –
July 1998
[A2] D. Barry, ODMG: The Industry Standard for Java Object Storage,
Component Strategies - September 1998
[A3] D. Barry, There’s an ODMG Database in Your Future, DB Prog & Design April 1998
[A4] D. Barry, If you want better answers about ODMG, DB Prog & Design April 1998
[A5] N. King, The Object Database Goes Online, Internet Systems - January 1997
[A6] N. King, Object DBMS, Internet Systems
[A7] D. Düllmann, Object Database as data stores for High Energy Physics,
CERN IT/ASD & RD45
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK
Indice analitico
206
[A8] L. Guzenda, Building Petabyte Database with Objectivity/DB, Objectivity Inc.
[A9] L. Vandoni, Implementazione di Database Object-Based con struttura variabile,
Computer Programming N. 53 - Dicembre 1996
[A10] G. Lo Russo, Introduzione ai database ad oggetti, MokaByte 26-27, Gennaio 1999
[A11] G. Lo Russo, POET: un Database a Oggetti, Computer Programming N. 53 Dicembre 1996
[A12] G. Bracco, et al., Data analysis software on the FTU experiment and its recent
developments, ENEA
Data Base Object-Oriented per la gestione di dati sperimentali TOKAMAK