Architettura Basata Su Linux RTAI Per La Stabilizzazione Verticale Del Joint European Torus

UNIVERSITÀ DEGLI STUDI DI
ROMA
TOR VERGATA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA

DELL’AUTOMAZIONE
A.A. 2006/2007
Tesi di Laurea
ARCHITETTURA BASATA SU LINUX-RTAI

PER LA STABILIZZAZIONE VERTICALE
DEL JOINT EUROPEAN TORUS
RELATORE CANDIDATO
Prof. Luca Zaccarian Riccardo Vitelli
CORRELATORE
Dott. Ing. Filippo Sartori
Alla mia famiglia
Ai miei amici
Indice
Ringraziamenti 1
Introduzione 2
1 Cenni sulla fusione nucleare 5
1.1 La fusione nucleare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Il Tokamak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Formazione e riscaldamento del plasma . . . . . . . . . . . . . 8
1.3 Lo stato dell’arte: il JET . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 I principali circuiti e bobine poloidali . . . . . . . . . . . . . . 11
1.4 Le sfide future: ITER e DEMO . . . . . . . . . . . . . . . . . . . . . 13
2 La stabilizzazione verticale 15
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Analisi del problema fisico . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Stima del growth rate . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Le misure magnetiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Stima della posizione verticale del plasma . . . . . . . . . . . . . . . . 22
2.5 L’algoritmo di controllo . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1 Controllo di velocità e di corrente . . . . . . . . . . . . . . . . 25
INDICE I
INDICE
2.5.2 Controllo adattativo . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.3 Kick Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Problematiche di controllo . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.1 FRFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.2 Accoppiamento tra controllo di posizione e forma . . . . . . . 31
2.6.3 Rumore degli alimentatori . . . . . . . . . . . . . . . . . . . . 31
2.6.4 Modi MHD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.5 ELM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Scrittura e porting del sistema di controllo 37
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Implementazione del controllo . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Le GAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2 Struttura di VsGAM . . . . . . . . . . . . . . . . . . . . . . . 43
3.3 Il sistema RT del JET: MARTe . . . . . . . . . . . . . . . . . . . . . 49
3.4 Scelta del sistema operativo realtime . . . . . . . . . . . . . . . . . . 51
3.5 Linux-RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.1 Funzionamento di RTAI . . . . . . . . . . . . . . . . . . . . . 53
3.5.2 RTAI ed i sistemi multicore . . . . . . . . . . . . . . . . . . . 55
3.5.3 Userspace o Kernelspace? . . . . . . . . . . . . . . . . . . . . 56
3.6 FCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6.1 Analisi del funzionamento . . . . . . . . . . . . . . . . . . . . 59
3.6.2 Funzioni aggiuntive . . . . . . . . . . . . . . . . . . . . . . . . 65
3.6.3 Problematiche e soluzioni . . . . . . . . . . . . . . . . . . . . 65
3.7 RTAIConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
INDICE II
INDICE
4 Risultati ottenuti 71
5 Conclusioni e sviluppi futuri 74
Appendices 77
A La BaseLib2 78
A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.2 Divisione in livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.3 Le classi fondamentali . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3.1 Un antenato comune: la classe Object . . . . . . . . . . . . . 81
A.3.2 Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3.3 Named Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.3.4 GCReference e GCReferenceContainer . . . . . . . . . . . . . 83
A.3.5 Vista d’insieme . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3.6 Il CDB - Configuration DataBase . . . . . . . . . . . . . . . . 86
A.4 Comunicazione tra oggetti . . . . . . . . . . . . . . . . . . . . . . . . 88
B Distribuzione Linux usata al JET 90
B.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.2 Installazione di Gentoo . . . . . . . . . . . . . . . . . . . . . . . . . . 91
B.3 Costruzione di un LiveCD/LiveUSB . . . . . . . . . . . . . . . . . . . 94
B.4 Avvio del sistema da rete . . . . . . . . . . . . . . . . . . . . . . . . . 95
C Specifiche hardware 97
C.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
C.2 Lo standard ATCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
INDICE III
INDICE
C.3 Il controllore ATCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.4 Le schede DGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.5 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Elenco delle figure 102
Bibliografia 103
INDICE IV
Ringraziamenti
Colgo questa occasione per ringraziare tutti coloro che hanno reso possibile questa
esperienza, lunga ben sei mesi, al JET. Prima di tutti i miei genitori e mia nonna,
che mi sono stati vicini nonostante i chilometri che ci separavano, offrendomi sempre
un supporto incondizionato anche durante i momenti più difficili vissuti, ora come
durante l’intero arco della mia carriera scolastica prima, ed universitaria poi.
A loro si aggiunge quella lunga teoria di amici vicini e lontani che con affetto
hanno continuato a mantenere stretti rapporti, facendomi sentire spesso quasi come
se Oxford fosse a pochi passi dalle loro case. Insieme a questi ultimi l’ing. (e futuro
dottor) Salvatore Annunziata, conosciuto al JET e senza la cui solare presenza e co-
stante aiuto tutto sarebbe stato più difficile, e gli altri ragazzi del gruppo.
Infine voglio ringraziare il prof. Luca Zaccarian, senza il quale questa seconda
fantastica opportunità di lavorare nel campo della fusione non sarebbe stata nemmeno
possibile, il dott. Sartori, mio correlatore e guida durante l’esperienza al JET, il
dott. Piccolo, “capoufficio” e uomo di grande spessore, l’ing. Neto (dall’interminabile
pazienza e capacità di spiegarsi rara), la dott.ssa Zedda, e in generale tutta la “Little
Italy” del Plasma Operations Group, popolata da persone capaci di creare un clima
di lavoro rilassato ma allo stesso tempo estremamente professionale.
INTRODUZIONE 1
Introduzione
Il problema energetico è senza dubbio alcuno la più grande sfida che il genere umano
dovrà affrontare nel corso del secolo che stiamo vivendo. Il progressivo esaurirsi dei
combustibili fossili e la necessità di trovare sistemi per produrre energia quanto più
possibile “puliti” al fine di frenare l’inquinamento del pianeta, aggiunti alla sempre
crescente domanda di energia da parte della popolazione mondiale, soprattutto nei
paesi in via di sviluppo, obbligherà l’umanità ad accelerare sempre più la ricerca in
questo campo.
Varie possibili risposte sono state date nel tempo a questo problema, nessuna delle
quali sembra essere, ad oggi, proponibile come alternativa ai combustibili fossili. Fonti
di energia rinnovabile, quali fotovoltaico o idrico, non hanno la necessaria capacità
di produzione di energia, e la fissione nucleare, per quanto promettente dal punto di
vista della potenza erogata, non può essere considerata una soluzione a lungo ter-
mine, sia a causa delle scorie prodotte altamente radioattive e con elevato tempo di
dimezzamento, sia in quanto si trova a doversi scontrare con il “muro di gomma”
dell’opinione pubblica, rimasta scottata da gravi incidenti quale quello di Černobyl’ o
di Three Mile Island.
Una possibile soluzione al problema energetico potrebbe, invece, derivare dalla fu-
INTRODUZIONE 2
INTRODUZIONE
sione nucleare, che permetterebbe di accedere ad una fonte di energia sicura, pulita
e, soprattutto, rinnovabile, utilizzando come combustibile semplici isotopi dell’idro-
geno ricavabili facilmente dall’acqua e dal litio, abbondantemente disponibile nella
crosta terrestre.
Tuttavia la strada da percorrere è ancora lunga: numerosi problemi e sfide in ogni
campo della scienza e della tecnica, dalla fisica, alla meccanica, all’ingegneria dei con-
trolli, costellano il tortuoso percorso verso un reattore a fusione. Proprio al fine di
studiare le varie problematiche inerenti il confinamento del plasma, numerosi centri di
ricerca sono sorti in varie parti del mondo. In particolare a Culham, piccola cittadina
nei pressi di Oxford, Regno Unito, nella prima metà degli anni ’80 è stato costruito,
grazie ad una collaborazione tra 25 stati europei, il JET (Joint European Torus), il
più grande Tokamak attualmente esistente sulla faccia della Terra.
Al momento della costruzione del JET numerose considerazioni (relative sia alla
robustezza meccanica della struttura che all’efficienza del processo) hanno portato
alla decisione di conferire alla camera da vuoto una forma allungata verticalmente,
simile alla lettera “D”. Di conseguenza, al fine di sfruttare nel modo migliore lo spazio
a disposizione, si è scelto di dare al plasma una forma non più circolare come in altri
Tokamak, ma allungata verticalmente, a seguire il più possibile la forma della camera.
Questo ha causato, tuttavia, una perdita della naturale stabilità verticale posseduta
dai plasmi circolari, portando alla necessità di progettare un sistema in feedback per
garantire che il plasma stesso non terminasse rovinosamente contro le pareti del To-
kamak.
INTRODUZIONE 3
INTRODUZIONE
Scopo di questo elaborato è illustrare l’implementazione dell’algoritmo per la stabi-
lizzazione verticale del plasma al JET, soffermandosi soprattutto sulle problematiche
incontrate durante il porting del software in ambiente Linux-RTAI. In particolare, nel
primo capitolo verrà affrontata un’introduzione generale alle problematiche relative
alla fusione ed al confinamento del plasma, pur se senza nessuna pretesa di comple-
tezza data la complessità dell’argomento; nel capitolo seguente si analizzerà invece
l’algoritmo di stabilizzazione verticale, riassumendo prima le basi di fisica necessarie
a comprendere il fenomeno, e quindi le soluzioni adottate per contrastarlo. Il terzo
capitolo è dedicato all’implementazione dell’algoritmo stesso, illustrando il funziona-
mento dell’esecutore di thread realtime del JET (MARTe) e la logica modulare con
cui il controllore è stato realizzato (le GAM), e concentrandosi infine sul porting del
software verso Linux-RTAI e le relative problematiche. Infine, nei capitoli in appen-
dice, verranno illustrate alcune delle specifiche tecniche più importanti (sia hardware
che software).
INTRODUZIONE 4
Capitolo 1
Cenni sulla fusione nucleare

In questo capitolo verranno brevemente riassunti, senza alcuna
pretesa di completezza, alcuni concetti basilari della fusione nu-
cleare e del confinamento magnetico del plasma, soffermandosi in
particolare sul JET e sulla sua struttura magnetica.
1.1 La fusione nucleare
È noto che all’interno del nucleo atomico i protoni, essendo dotati di stessa carica
elettrica, tendono a respingersi e causerebbero la disgregazione dell’atomo se non esi-
stessero le forze di coesione nucleare. Una reazione nucleare consiste sostanzialmente
nella modifica, anche solo in parte, dell’equilibrio tra tali forze.
Esistono due tipi di reazione nucleare: la fissione e la fusione.
La prima, scoperta nella prima metà del ventesimo secolo da un gruppo di scienziati
(tra i quali una figura di spicco è sicuramente Enrico Fermi), anche grazie ai fondi
“donati” dal Ministero della Difesa americano in vista di un potenziale utilizzo bellico
contro il regime nazista e i suoi alleati, è attualmente l’unico sistema tecnologicamente
stabile per ottenere produzione di energia elettrica attraverso reazioni nucleari.
Tuttavia la pericolosa produzione di scorie nucleari nocive per la salute, oltre a rendere
5
CAP. 1 Cenni sulla fusione nucleare 1.1 La fusione nucleare
i reattori a fissione alquanto impopolari presso la pubblica opinione, ha portato a
cercare soluzioni alternative che potessero produrre quantità paragonabili di energia
in modo più pulito.
In questo modo è iniziata la ricerca nel campo della fusione.
Le reazioni di fusione nucleare avvengono di continuo nelle stelle, permettendo la
produzione dell’enorme quantità di energia da esse irradiata. In questo tipo di rea-
zione i nuclei di elementi leggeri si fondono per formare un nucleo più pesante, la cui
massa è minore della somma delle masse dei nuclei “genitore”. La massa mancante si
trasforma in energia secondo la nota equivalenza massa-energia di Einstein E = mc2 .
Per la fusione nucleare in genere si usano due isotopi dell’idrogeno, il deuterio e il
trizio che, interagendo, si uniscono a formare un nucleo di elio (o particella α) ed un
neutrone.
Figura 1.1: Diagramma della reazione di fusione nucleare.
La difficoltà di realizzazione e controllo dei processi di reazione nucleare è legato al
fatto che, per soverchiare le forze di repulsione elettrica tra i nuclei, gli atomi devono
6
CAP. 1 Cenni sulla fusione nucleare 1.2 Il Tokamak
avvicinarsi a distanze dell’ordine di 10−11 m, e per ottenere ciò è necessario lavorare
in regimi di altissima temperatura e/o pressione. In particolare, nel caso della fusione
nucleare in laboratorio è necessario portare e mantenere gas ionizzato a temperature
dell’ordine di 100 milioni di gradi centigradi1 . A tali temperature la materia tende
a dissociarsi nei suoi elementi costitutivi, trasformandosi in una specie di “brodo” di
ioni ed elettroni definito plasma, o quarto stato di aggregazione della materia.
Il plasma è un gas ionizzato la cui carica complessiva, a causa della possente forza
elettrostatica tra i due elementi costitutivi, resta generalmente neutra. Ciò nonostan-
te, grazie allo scorrimento relativo tra ioni ed elettroni, il plasma è un buon conduttore
di corrente. Tale proprietà è decisamente importante: proprio grazie alla possibilità
di generare una corrente di plasma è possibile “guidare” il plasma stesso attraverso
l’utilizzo di campi magnetici [1] [2]. Tale processo, che permette di isolare il plasma
ad alta temperatura dalle pareti del suo contenitore, è definito confinamento ma-
gnetico.
1.2 Il Tokamak
Tra le varie strutture proposte per il confinamento magnetico del plasma, quella più
diffusa è senza dubbio il Tokamak (acronimo per la frase russa “TOroidalnaya KA-
mera i MAgnitnaya Katushka”, ovvero “camera toroidale e avvolgimento magnetico”),
sia per la sua relativa semplicità, che per la sua efficacia. Un Tokamak è generalmente
composto da una camera da vuoto a forma di toro contornata da vari avvolgimenti

1
Da notare che nelle stelle le temperature necessarie affinché avvengano reazioni di fusione (circa
20 milioni di gradi) sono molto più basse rispetto a quelle richieste in laboratorio: infatti, pur essendo
la probabilità che due atomi si fondano direttamente proporzionale alla temperatura, in un corpo
celeste l’elevata gravità e conseguente pressione compensa tale minore probabilità.
7
magnetici sia sul piano poloidale (ovvero lungo la sezione verticale della camera)
che toroidale (parallelamente alla camera)2 . Si confronti per maggior chiarezza con
la figura 1.2.
Figura 1.2: Rappresentazione di avvolgimenti e campi toroidale e poloidale.
In figura 1.2 è anche possibile vedere come le due tipologie di avvolgimenti ma-
gnetici diano origine ad un campo risultante dalla forma elicoidale.
1.2.1 Formazione e riscaldamento del plasma
Portare un gas alle temperature richieste perché esso si trasformi in plasma non è,
ovviamente, un’impresa semplice, tanto che è necessario adottare più di un metodo

2
Si noti che, ovviamente, gli avvolgimenti su un piano generano campi magnetici sul piano orto-
gonale, cosa che potrebbe generare confusione. Per evitare problemi si consideri che in questa Tesi
ci si riferirà, salvo diversamente specificato, esclusivamente ai campi sul piano poloidale (generati da
avvolgimenti posti su quello toroidale, indicati come “poloidal field coils” in figura).
8
per portare la materia in temperatura.
Una parte del calore necessario deriva dall’effetto Joule dovuto alla corrente di
plasma che circola nel gas, generata dall’avvolgimento centrale (figura 1.2) per effetto
trasformatore dove il plasma si comporta da secondario. Tuttavia tale parte è decisa-
mente insufficiente perché possano avvenire reazioni di fusione nucleare. Tale limite
è legato al fatto che all’aumentare della temperatura la resistività del plasma tende a
decrescere e di conseguenza il riscaldamento Ohmico ad essa dovuto.
Per fornire la potenza aggiuntiva richiesta sono state studiate tre tecniche fonda-
mentali:
• L’uso di onde elettromagnetiche, che vengono iniettate nel Tokamak con
antenne o guide d’onda ed assorbite dal plasma (Radio Frequency Heating);
• L’iniezione di atomi neutri ad elevata energia cinetica, che trasferiscono
la loro energia al plasma urtando contro gli atomi che lo compongono (Neutral
Beam Heating);
• La compressione adiabatica del plasma, che viene ottenuta direzionando lo
stesso verso regioni con campo magnetico maggiore, con conseguente aumento
di pressione e temperatura.
Al JET vengono adottate le prime due tecniche.
L’obiettivo che si spera di raggiungere, tuttavia, è quello di creare le condizioni af-
finché il plasma possa autoalimentarsi: perché ciò avvenga si deve riuscire ad arrivare
al punto in cui le particelle α generate dalla reazione siano in numero sufficiente da
innescare la fusione di un’ulteriore coppia deuterio-trizio. Tale evento viene definito
9
CAP. 1 Cenni sulla fusione nucleare 1.3 Lo stato dell’arte: il JET
in gergo tecnico ignition: teoricamente, portato il plasma in tale stato, la reazione
di fusione dovrebbe continuare all’infinito purché vi sia presenza di combustibile nella
camera da vuoto.
1.3 Lo stato dell’arte: il JET
Il JET è una macchina costruita in collaborazione tra i vari stati membri dell’Unione
Europea, e rappresenta ad oggi, con i suoi quasi tre metri di raggio maggiore, il più
grande Tokamak esistente sulla Terra. L’entrata in funzione della macchina, avvenuta
nel 1983, ha rappresentato un enorme passo in avanti nel campo della ricerca sulla
fusione nucleare.
I numeri relativi al JET sono impressionanti: il campo generato per il confina-
mento del plasma è dell’ordine di 4T , con una corrente di plasma di 7M A. Inoltre,
con i suoi 16M W di potenza da fusione generati, il Tokamak è capace di raggiungere
un fattore Q di 0.6.3
In figura 1.3 è riportato l’interno della camera da vuoto del Tokamak, cosı̀ come
appare attualmente4 . In particolare si possono notare le tile (letteralmente “mattonel-
le”) della parete a contatto col plasma (denominata first wall ), e la zona dei divertori
(in basso) dove viene concentrata la maggior parte dell’energia termica.
3
Il fattore Q rappresenta il rapporto tra potenza generata e potenza fornita al Tokamak per riscal-
dare il plasma. Un reattore capace di fornire tanta potenza quanta gliene viene fornita (breakeven)
ha un fattore Q = 1. Nel caso di ignition si ha Q = ∞.
4
Durante la sua storia, infatti, il JET ha subito un’enorme evoluzione, in particolare per quanto
riguarda l’interno del vessel, al fine di sperimentare nuovi scenari e correggere errori precedenti.
10
Figura 1.3: Interno della camera vuoto del JET, con sovrapposta un’istantanea presa
in presenza di plasma.
1.3.1 I principali circuiti e bobine poloidali
In figura 1.4 sono riportati i principali circuiti poloidali che generano la struttura ma-
gnetica del JET. Si noti come alcuni di essi condividano fisicamente la stessa bobina.
Essi sono:
• Circuito di riscaldamento ohmico. È usato solo per riscaldare il plasma con
il principio del trasformatore, dove il plasma stesso funge da secondario. Questo
circuito è composto dal solenoide centrale (P1) e da alcuni avvolgimenti di P3
(in particolare P3ML e P3MU);
• Circuiti di campo verticale e sbilanciamento, PFX. Sono i circuiti che
regolano l’elongazione verticale del plasma (PFX, Poloidal Field X-Point), e che
contrastano la tendenza del plasma ad espandersi sul piano poloidale (collegati
ai due avvolgimenti P4);
11
Figura 1.4: Posizione delle bobine poloidali del JET.
• Circuito di campo radiale. Il circuito, composto dalla serie delle bobine P2R
e P3R ed alimentato dall’amplificatore denominato Fast Radial Field Amplifier
(FRFA), è il responsabile della stabilizzazione verticale del plasma, oggetto di
questa Tesi;
• Circuito di forma. Composto dalla serie delle bobine P2S e P3S, è il circuito
gestito dal controllore di forma, il cui compito è quello di modificare la sezione
del plasma;
• Circuiti di divertore. Denominati da D1 a D4 in figura, sono i responsabili
del posizionamento degli strike points, ovverosia dei punti dove il plasma scarica
la maggior parte della sua energia termica nel caso di configurazione con X-
12
CAP. 1 Cenni sulla fusione nucleare 1.4 Le sfide future: ITER e DEMO
Point5 . Contrariamente agli altri, i circuiti di divertore sono gli unici psizionati
all’interno della camera da vuoto.
1.4 Le sfide future: ITER e DEMO
Dopo più di 20 anni di attività e studio, ci si sta rendendo conto che il JET inizia
a non essere più sufficiente per la comprensione delle problematiche intrinseche ad
un futuro reattore a fusione, che dovrà necessariamente essere di dimensioni maggiori
rispetto agli attuali Tokamak.
Queste considerazioni sono state la base sulla quale si è iniziato a pensare ad
ITER, acronimo di International ThErmonuclear Reactor, ma anche “strada” in
latino (figura 1.5).
ITER è uno sforzo collettivo internazionale dell’Unione Europea insieme alla Sviz-
zera, al Giappone, alla Corea, all’India, alla Federazione Russa agli Stati Uniti ed alla
Repubblica Popolare Cinese.
Attualmente ancora in fase di sviluppo, a breve i lavori di costruzione dovrebbero
iniziare a Cadarache, nel sud della Francia. Con i suoi 6 metri di raggio maggiore,
gli obiettivi principali di ITER sono quelli di raggiungere un fattore Q maggiore di 1
(teoricamente 10), e di funzionare, a regimi ridotti, non come macchina ad impulsi,
ma continua (steady-state); si spera inoltre di dare origine alla prima ignition della
5
In tale configurazione all’interno della camera da vuoto non sono presenti solo linee di campo
chiuse, ma anche aperte. La prima di queste ultime, che segna la transizione tra le due forme,
possiede un punto a campo nullo in cui le linee di campo si incrociano formando una X, da cui il
nome.
13
CAP. 1 Cenni sulla fusione nucleare 1.4 Le sfide future: ITER e DEMO
Figura 1.5: Struttura meccanica di ITER.
storia della ricerca sulla fusione.
Il passo seguente, dipendente dal successo di ITER, sarà DEMO, il primo esempio
di reattore a fusione che, con i suoi previsti 2GW di potenza dovrebbe essere in scala
con una moderna centrale elettrica, dando il via allo sfruttamento pacifico della fusione
termonucleare.
14
Capitolo 2
La stabilizzazione verticale
In questo capitolo verrà affrontata la problematica della stabiliz-
zazione verticale del plasma, introducendo i concetti fisici fonda-
mentali necessari alla comprensione del problema, e quindi analiz-
zando come questo sia attualmente risolto al JET, segnalando le
problematiche ancora aperte.
2.1 Introduzione
Il problema della stabilizzazione verticale del plasma al JET nasce dall’aver deciso di
adottare per il Tokamak un plasma “a forma di D” (D-shaped ): laddove un plasma a
sezione circolare risulta essere verticalmente stabile, un plasma allungato perde tale
caratteristica.
La scelta di questa apparente complicazione deriva fondamentalmente da una con-
siderazione meccanica: la forma a D risulta evidentemente più robusta sia per quanto
riguarda gli stress verticali1 , sia, e soprattutto, relativamente alla deformazione oriz-
zontale della camera da vuoto, soggetta alle enormi forze derivanti dall’interazione
magnetica tra plasma e pareti del Tokamak stesso.

1
Una camera circolare permette un punto di contatto minimo -teoricamente infinitesimale- con
i supporti verticali, mentre una camera a D garantisce una parete di supporto pari all’altezza della
camera stessa.
15
CAP. 2 La stabilizzazione verticale 2.1 Introduzione
A questa considerazione meccanica va aggiunto che, come noto, il campo magneti-
co decresce col quadrato della distanza: di conseguenza la corrente di plasma indotta
dall’avvolgimento poloidale al centro del Tokamak è decisamente maggiore in pros-
simità della parete interna. Un plasma D-shaped, quindi, espone un volume molto
maggiore a questa zona particolarmente favorevole (figura 2.1).
Figura 2.1: Caduta della corrente di plasma in dipendenza dalla distanza dall’asse del
toro.
Col tempo, inoltre, man mano che le teorie sull’H-mode 2 andavano affermandosi,
si è visto che avere un plasma con una forte triangolarità (figura 2.2), definita come
[2]:
0.5 · (c + d)
δ=
a
2
L’H-mode è una modalità di funzionamento dei Tokamak caratterizzata da pressioni ed energie
decisamente maggiori rispetto al metodo di funzionamento standard, battezzato L-mode.
16
CAP. 2 La stabilizzazione verticale 2.1 Introduzione
favorisce di molto i rendimenti della macchina (e si noti come man mano che la forma
del plasma tende verso una “D” maiuscola -come al JET- la triangolarità aumenti).
Figura 2.2: Misura della triangolarità di un plasma.
In definitiva, avere un plasma elongato verticalmente garantisce una lunga serie di
vantaggi (ad avviso di molti indispensabili in un futuro reattore a fusione); segue la
necessità quindi di studiare un sistema di controllo che riesca a stabilizzare la dina-
mica verticale del plasma causata dalla configurazione non circolare.
A sottolineare tale necessità si consideri che la perdita di stabilità verticale cau-
sa, in generale, un’improvvisa disruzione nel plasma (anche detta VDE, o Vertical
Displacement Event) con conseguenti enormi stress per il Tokamak, soprattutto dal
punto di vista meccanico, mentre l’enorme quantità di energia elettrica posseduta dal
plasma viene trasformata in forze magnetiche e quindi traslazionali sulla macchina.
Mentre un VDE può essere tollerato dal JET, un evento del genere nel futuro ITER
potrebbe causare la rottura del Tokamak.
17
CAP. 2 La stabilizzazione verticale 2.2 Analisi del problema fisico
2.2 Analisi del problema fisico
Dal punto di vista fisico, il perché dell’instabilità verticale del plasma è relativamente
semplice. A tal proposito si osservi la figura 2.3 [11].
Figura 2.3: Instabilità verticale del plasma. I segni + e - indicano la direzione della
corrente circolante nel circuito.
Le espansioni polari (iron polar expansions, in viola nella figura), delle strutture
passive in ferro3 , e in parte minore i circuiti di forma (shaping coils, in azzurro nella
figura), sono i principali responsabili della forma allungata del plasma. Fino a quando
3
Una struttura passiva soggetta ad un campo magnetico, genera infatti a sua volta un campo
magnetico “riflesso” (a causa della corrente che lo attraversa) che, nel caso del Tokamak, attira il
plasma (poiché possiede il medesimo segno).
18
esso si trova in una posizione di equilibrio verticale nella camera (ovverosia nel punto
in cui le forze indotte sul plasma dalle due espansioni polari risultano essere uguali
ed opposte), il plasma resta in posizione. Tuttavia è sufficiente un piccolo sposta-
mento da tale posizione perché una delle due forze diventi predominante, attirando il
plasma verso la relativa espansione polare sempre più velocemente, e portandolo ad
infrangersi contro le pareti del Tokamak. L’inverso del tempo in cui questo avviene è
definito, al JET, growth rate γ (tasso di crescita).
2.2.1 Stima del growth rate
È possibile ottenere una stima abbastanza attendibile del growth rate utilizzando un
modello semplificato dell’instabilità verticale del plasma. Secondo tale modello, il
plasma può essere visto come uno o più filamenti rigidi, percorsi da una corrente
costante, con un unico grado di libertà coincidente con la posizione verticale del
centro4 dell’insieme di filamenti (rigid displacement model ).
Il modello matematico è ottenuto combinando le equazioni elettriche degli avvolgi-
menti poloidali e delle strutture passive in funzione del flusso magnetico per radiante,
con l’equazione di bilancio delle forze [16]:
 ( )
 ˙ ~
~ ~

 ψ I(t), zp (t) + RI(t) = ~u(t)
( ) (2.1)


 mp z̈p (t) = −2πrp Br ~
I(t), zp (t) Ip
~ è il flusso concatenato da circuiti, strutture passive e filamenti di plasma; R è
dove ψ
la matrice contenente tutti i termini resistivi; I~ è il vettore contenente tutte le correnti
del campo poloidale e ~u è il vettore degli ingressi, ovvero delle tensioni applicate ai
4
In realtà viene usato il centroide dell’insieme di filamenti, ovvero una sorta di centro “pesato”
dall’intensità di corrente che scorre in ogni filamento.
19
vari circuiti (posto pari a zero, ovviamente, per le strutture passive); mp , zp e rp
rappresentano, rispettivamente, massa e posizione verticale e radiale del plasma; Ip è
la corrente di plasma e Br il campo magnetico radiale che agisce sul plasma.
Tramite semplici passaggi è possibile linearizzare il modello ottenendo (omettendo
le dipendenze per maggiore chiarezza):


 ∂ψ~ ˙ ∂ψ ~

 δ ~+
I δ żp + Rδ I~ = δ~u(t)


 ∂ I~ ∂zp
 ( ) (2.2)

 ∂B~r ~r
∂B

 mp δz̈p = −2πrp δ I~ +
 δzp Ip
∂ I~ ∂zp
Effettuando quindi, al fine di semplificare, le seguenti sostituzioni:
∂ψ ~ ~
∂ψ ∂M .
=L = Ip =g
∂ I~ ∂zp ∂zp
( ) ( )T ( )
∂B~r ∂M . T ∂B~r
−2πrp = Ip =g −2πrp =F
∂ I~ ∂zp ∂zp
dove L è la matrice delle induttanze dei circuiti, M quella delle mutue induttanze
circuiti-plasma, ed F la forza destabilizzante. In tale modo il modello linearizzato
può essere riscritto come:



 Lδ I~˙ + gδ żp + Rδ I~ = δ~u(t)
(2.3)

 mp δz̈p = g δ I~ + F δzp
T
Considerando ora che la massa del plasma risulta essere decisamente trascurabile
(mp = 0) e sostituendo, opportunamente derivata, la seconda equazione nella prima,
si ottiene il sistema di equazioni lineari differenziali:

( )
g · gT ˙
L− δ I~ + Rδ I~ = δ~u (2.4)
F
Dall’equazione (2.4) è possibile desumere il growth rate dell’instabilità verticale
analizzando gli autovalori con parte reale positiva della matrice [16]:
( )−1
g · gT
− L− R
F
20
CAP. 2 La stabilizzazione verticale 2.3 Le misure magnetiche
Tramite tale modello si è visto che, in una scarica tipica, il growth rate del JET
ha un valore nell’ordine5 di 102 − 103 s−1 [11].
2.3 Le misure magnetiche
Al fine di misurare la posizione verticale del plasma, l’attuale algoritmo di controllo fa
uso di una vasta serie di sensori magnetici, posti in vari punti della camera da vuoto,
capaci di misurare le varie componenti del campo magnetico. In particolare vengono
usati al JET due tipologie di sensori: i Mirnov coil (o pick-up coil) -riportati in
figura 2.4- e i saddle loop, posizionati come da figura 2.5.
Figura 2.4: Esempio di Mirnov coil. In figura sono riportati il contenitore, la struttura
di supporto e il sensore vero e proprio.
Entrambi i sensori permettono la misura della derivata del flusso magnetico con-
catenato con il sensore (in particolare la componente perpendicolare alle spire del sen-
sore stesso). Segue quindi che i Mirnov coil misurano la componente tangenziale del
campo magnetico in un dato punto della camera, mentre i saddle loop quella normale.
5
In realtà tale autovalore, non fosse per le correnti parassita (eddy current) circolanti nelle strut-
ture metalliche passive a causa dei movimenti del plasma, sarebbe decisamente più alto (dell’ordine
di 106 s−1 ), rendendo virtualmente impossibile controllare il movimento verticale del plasma.
21
CAP. 2 La stabilizzazione verticale 2.4 Stima della posizione verticale del plasma
Figura 2.5: Posizione su un ottante dei sensori di misura del campo magnetico.
2.4 Stima della posizione verticale del plasma
La tecnica usata per stimare la velocità verticale del plasma deriva dalle equazioni
sviluppate da Zakharov [13]:

I [ ( ) ]
1 r
IΦ zc = Bt (r, z)z − r log Bn (r, z) dl (2.1)
µ l R0
dove IΦ è la corrente toroidale totale concatenata dalla curva l6 ; Zc è la posizione
verticale del centroide della precedente; Bt e Bn sono le componenti tangenziali e nor-
mali del campo magnetico misurato lungo l; infine r e z rappresentano le coordinate

6
Corrente che comprende, oltre quella di plasma, anche quella dovuta ai divertori e alle strutture
passive.
22
CAP. 2 La stabilizzazione verticale 2.4 Stima della posizione verticale del plasma
radiale e verticale.
A fini pratici, assumendo di far coincidere l con la sezione della camera del
JET, considerando che le componenti magnetiche tangenziali e normali possono esse-
re misurate solo in posizioni discrete dai sensori posti sulla camera e differenziando
opportunamente la (2.1) si ottiene:
∑
18 ∑
14
Ip żp = ai Ḃt (i) + bi Ḃn (i) − I˙p zp − I˙pass zpass (2.2)
i=1 i=1
dove il termine I˙pass zpass relativo alle strutture passive è dato da:
∑
4
I˙pass zpass = I˙D(i) zD(i) − I˙rr zrr − I˙mk2 zmk2
i=1
Ip e żp rappresentano corrente e velocità verticale del plasma e ai e bi sono dei pesi
ottenuti risolvendo la (2.1) nei punti dove i sensori sono posti nella camera.
In particolare si hanno 18 pesi corrispondenti ai Mirnov coils (misura del campo
tangenziale) e 14 per i saddle loops (misura del campo normale) (figura 2.6) [16].
Si noti che, dopo l’introduzione dei divertori per gestire l’X-point, le Mirnov coils
presenti nella parte bassa della camera sono risultate essere inutilizzabili (proprio a
causa dell’azione di schermatura dei divertori stessi), e di conseguenza i relativi pesi
nell’equazione precedente sono posti pari a zero (avvolgimenti dal 10 al 18 in figura
2.6).
23
CAP. 2 La stabilizzazione verticale 2.5 L’algoritmo di controllo
Modified Set
1.2
Mirnov Coils
Saddle Loops
1
0.8
0.6
Weight
0.4
0.2
−0.2
0 5 10 15 20 25 30 35
Coil Number
Figura 2.6: Pesi per i vari sensori magnetici, come da modifica dopo l’inserimento del
divertore.
2.5 L’algoritmo di controllo
Lo schema di controllo adottato al JET per la stabilizzazione verticale è rappresentato
in figura 2.7. In esso si distinguono cinque blocchi:
• FRFA (Fast Radial Field Amplifier ): è l’amplificatore utilizzato per la
stabilizzazione verticale, capace di fornire fino a 2.5 kA a 10kV, con un funzio-
namento ad isteresi;
• Speed observer: è un blocco che, sulla base delle misure magnetiche, determi-
na la velocità verticale del plasma (in pratica implementando l’equazione (2.2)
vista precedentemente7 );
7
Si noti che in realtà si ottiene, come indicato dalla (2.2), il prodotto Ip Żp , rappresentante la
velocità verticale del plasma pesata dalla corrente di plasma.
24
• Velocity loop: è il controllore che si oppone a variazioni della velocità verticale
del plasma;
• Current loop: è il controllore che regola la corrente circolante in FRFA secondo
un preprogrammato (generalmente nullo salvo esperimenti particolari). Si noti
come l’azione di controllo sia la somma dei contributi dei due loop di controllo;
• Adaptive controller: è un blocco adattativo che regola i guadagni dei due
controllori (ovverosia la predominanza di uno rispetto all’altro) sulla base della
frequenza di switch di FRFA, al fine di evitare surriscaldamenti del medesimo a
causa della dissipazione intrinseca durante gli switch.
Figura 2.7: Schema generale dell’algoritmo per la stabilizzazione verticale del plasma.
2.5.1 Controllo di velocità e di corrente
Il blocco denominato velocity loop ha come compito quello di regolare a zero la velocità
verticale del plasma. Ciò viene effettuato attraverso un controllore di tipo proporzio-
25
nale. Considerando la dinamica di FRFA, il comportamento complessivo del sistema
è quello di un controllore bang-bang, che fa sı̀ che il plasma tenda ad oscillare attorno
alla sua posizione di equilibrio verticale con un’ampiezza e una frequenza proporzio-
nali al valore del guadagno [11].
Da solo il controllore di velocità non potrebbe garantire che il plasma e la corrente
circolante in FRFA non abbiano alcun tipo di deriva. Di conseguenza è necessario
introdurre un ulteriore loop di controllo sulla corrente circolante nell’alimentatore al
fine di regolarla a zero (o ad un valore preprogrammato desiderato per alcuni esperi-
menti particolari). Il blocco current loop si occupa proprio di questo attraverso l’uso
di un controllore PI.
Il comportamento complessivo dei due controllori dipende dallo stato dell’esperi-
mento: all’inizio e alla fine dell’impulso (quando non si è in presenza di plasma) solo
il controllo di corrente risulta essere attivo (in modo da inseguire il preprogrammato
che guida la nascita e la morte del plasma), mentre durante l’esperimento entrambi i
controllori sono attivi e il ciclo di retroazione viene chiuso.
2.5.2 Controllo adattativo
Il controllore adattativo è costituito da due blocchi logici: il primo stima la frequenza
di switch di FRFA (misurando il numero di passaggi per zero della tensione misurata
all’uscita dell’amplificatore stesso) e lo filtra con un passa-basso al fine di ridurne
i picchi, mentre il secondo applica un controllo proporzionale comparando il valore
stimato con quello desiderato (impostato a priori e posto pari ad un valore ottimo
26
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo
per FRFA) e genera i due valori di guadagno per i controllori di velocità e corrente
(GV e GI ). Si noti che la forbice di variazione di tali guadagni è limitata in modo da
impedire sia la saturazione dell’attuatore che prestazioni eccessivamente basse.
Oltre al controllo sulla frequenza è previsto anche un controllo logico sulla tem-
peratura di FRFA: qualora essa sia troppo elevata il controllore passa in uno stato
temporaneo di emergenza che riduce ulteriormente i guadagni GV e GI , in quanto
si preferisce una drastica diminuzione della prestazione alla terminazione improvvisa
dell’esperimento causata dal surriscaldamento dell’attuatore.
2.5.3 Kick Control
Un’ulteriore forma di controllo, non riportata nello schema di figura 2.7 in quanto non
in feedback, è il cosiddetto Kick Control. Tale controllore permette di bypassare
il controllo in feedback, assegnando direttamente la tensione desiderata su FRFA ad
istanti precisi decisi a priori, o periodicamente, o anche sulla base degli Hα, misura di
radiazione che permette di determinare l’insorgere di un ELM. Un uso del Kick Con-
troller è infatti quello di sperimentare tecniche che consentano di limitare gli ELM
più pericolosi stimolandone artificialmente di più piccoli e frequenti.
2.6 Problematiche di controllo
Il controllo di una macchina complessa come il JET è, ovviamente, soggetto a nu-
merose problematiche dovute sia all’intrinseca complessità del sistema-plasma, sia a
27
limiti tecnologici quali la saturazione degli attuatori, le temperature limite e i disturbi
di misura.
In questa sezione si vuole passare rapidamente in rassegna, al fine di fornire un qua-
dro quanto più completo possibile del sistema di stabilizzazione verticale, i principali
problemi attualmente da affrontare e non ancora risolti (quantomeno non completa-
mente).
2.6.1 FRFA
FRFA, acronimo di Fast Radial Field Amplifier, è il nome dell’amplificatore che pren-
de in ingresso il segnale generato dal sistema di stabilizzazione verticale e genera la
tensione applicata al circuito di campo radiale.
FRFA è costituito da quattro moduli identici, inverter a GTO, capaci di generare
2.5 kV a 2.5 kA. L’attuale configurazione prevede il collegamento in serie dei moduli,
garantendo a FRFA la capacità di fornire fino a 10 kV a 2.5 kA (figura 2.9).
Ciascuna delle sotto-unità viene attivata o disattivata a seconda delle richieste del
sistema di controllo: per tale motivo la caratteristica di FRFA presenta un andamento
ad isteresi invece che continuo (figura 2.8).
Essendo l’unità stessa molto veloce (l’attivazione o disattivazione di una sottounità
richiede solamente 200 µs), la dinamica complessiva dell’oggetto è legata soprattutto
al banco di filtri a monte di ogni modulo, il cui scopo è quello di limitare la variazione
di tensione percepita dagli avvolgimenti di campo radiale (attualmente all’incirca 600
V /µs). Tale banco di filtri è composto da due induttori di potenza (Lf ) da circa 200
28
Figura 2.8: Andamento ad isteresi di FRFA.
µH e da una resistore da 14 Ω.
In [16] è stata ottenuta una funzione di trasferimento ingresso-uscita di FRFA mo-
dellando l’azione di comando sull’inverter come proveniente da un condensatore, con-
siderando i valori precedentemente indicati per il banco di filtri e aggiungendo i valori
di induttanza e resistenza per la bobina di campo radiale ricavati sperimentalmente.
Tale funzione di trasferimento risulta essere:
Rf (2Lc s + Rc )
W (s) =
2Lf Lc s2 + [2Lf (Rc + Rf ) + Lc Rf ]s + Rc Rf
I risultati simulativi ottenuti con la precedente sono stati successivamente confermati
da prove sperimentali [16].
29
Figura 2.9: Schema elettrico di FRFA.
30
2.6.2 Accoppiamento tra controllo di posizione e forma
Il controllore di forma e quello di posizione verticale, pur lavorando a frequenze diffe-
renti8 , sono fortemente accoppiati in quanto condividono parte degli avvolgimenti ma-
gnetici poloidali. Per quanto un parziale disaccoppiamento in frequenza sia garantito
dalle diverse bande di lavoro, talvolta questo non risulta sufficiente.
Nella maggior parte dei casi tale fenomeno si verifica quando si adotta il sistema
di controllo completo della forma XSC (eXtreme Shape Controller ) a causa della sua
azione forte su tutti gli avvolgimenti interessati.
Unica soluzione a questo problema risulta essere quella di disaccoppiare i due
controllori, cosa che comporta un ridisegno sia hardware che software del sistema di
stabilizzazione verticale. Tale sistema farà parte del progetto di aggiornamento e mi-
glioramento del JET attualmente in fase di studio [16].
2.6.3 Rumore degli alimentatori
Le principali fonti di rumore al JET derivano dai disturbi causati dagli alimentatori,
che influenzano parzialmente le misure effettuate dai sensori magnetici, in particolare
quelli posti all’esterno della camera da vuoto (in quanto non schermati dalle strutture
passive).
Analisi effettuate azionando gli attuatori non in presenza di plasma hanno mo-
strato che i circuiti che disturbano maggiormente i sensori, soprattutto nella banda di
frequenza attorno i 300 Hz, sono il circuito di sbilanciamento e FRFA, e le sonde ma-
8
In particolare il controllore di forma lavora a frequenze un’ordine di grandezza più piccole rispetto
quelle del sistema di stabilizzazione verticale.
31
gnetiche che registrano più rumore sono i saddle loop 1 e 14, e successivamente, una
volta che il campo magnetico generato dai disturbi è riuscito a penetrare le strutture
passive, il 5 ed il 10 (per la posizione si confronti la figura 2.5) [16].
Si noti che attualmente, per quanto il rumore sia abbastanza forte e facilmente
misurabile, nessun tipo di filtro, sia esso analogico o digitale, è attivo al JET: ciò è
dovuto al fatto che l’attuale semplice sistema di controllo riesce comunque a svolgere
il suo compito senza mai cercare di inseguire il rumore.
2.6.4 Modi MHD
Uno dei principali problemi legati alle misurazioni magnetiche della posizione del pla-
sma derivano dai cosiddetti modi MHD (MHD modes, dove MHD sta per “magnetoi-
drodinamici”). Tali modi rappresentano perturbazioni del plasma che ne modificano
la simmetria, e possono essere decomposti in perturbazioni lungo il piano poloidale
(detti N modes) e toroidale (M modes): mentre i primi causano deformazioni nel pla-
sma (e di conseguenza interagiscono solamente col controllore di forma), i secondi si
comportano come oscillazioni verticali, e di conseguenza disturbano almeno in parte
le misurazioni magnetiche effettuate al fine della stablizzazione verticale.
Gli N modes (cosı̀ come gli M ) sono caratterizzati da un numero che identifica la
loro armonica rispetto ad una decomposizione di Fourier spaziale9 (figura 2.10). Tali
modi, inoltre, hanno la proprietà di ruotare nella camera assieme al plasma10 .

9
Si pensi, a fini pratici, ad una trasformata di Fourier applicata al Tokamak usando come variabile
l’angolo toroidale φ.
10
È possibile, al fine di visualizzarli meglio, pensarli come un’onda che si muove circolarmente
nella camera da vuoto.
32
N=0 mode N=1 mode
0.1 0.1
0.05 0
0 −0.1
1 1
1 1
0 0 0 0
−1 −1 −1 −1
N=2 mode N=3 mode
0.1 0.1
0 0
−0.1 −0.1
1 1
1 1
0 0 0 0
−1 −1 −1 −1
Figura 2.10: Esempi di N-modes.
Uno spostamento dal centro verticale della camera, l’unico d’interesse per la sta-
bilizzazione verticale, può quindi essere rappresentato come un modo con N = 0.
Dato che l’ampiezza di tali modi è inversamente proporzionale al loro indice N,
gli unici che possono influenzare pesantemente le misure magnetiche del JET sono
stati visti essere quelli con N minore di 3, e di conseguenza sono gli unici a venir
considerati.
Come si può notare dal suo andamento, un N mode può profondamente falsare
la misura della posizione verticale. Si consideri, ad esempio, il caso di un modo con
N = 2: effettuando le misure magnetiche in solo due lati opposti della camera si
avrebbe l’effetto di vedere, a valle dei sensori, un plasma oscillante attorno al centro
della camera, mentre in realtà il plasma non si è mosso dal suo punto di equilibrio.
33
Tale errore di misurazione può causare un surriscaldamento di FRFA, costretto a
continui (ed inutili) switch per inseguire il non esistente spostamento, fino a portarlo
allo spegnimento di sicurezza. Tuttavia recentemente tale problema è stato risolto
mediando le misurazioni su quattro ottanti opposti della camera, riducendo notevol-
mente l’influenza dei modi sulla misura [16]. Si noti, però, che la soppressione di tali
modi non è totale, giustificando quindi l’esistenza della parte adattativa del control-
lore mostrata precedentemente.
2.6.5 ELM
Gli ELM (o Edge Localised Modes) sono delle instabilità che si verificano solo nel mo-
mento in cui si porti la macchina a lavorare in H-mode. In tale modalità viene infatti a
crearsi una sorta di barriera al bordo del plasma (ETB, Edge Transport Barrier ) che
causa un brusco innalzamento del gradiente di pressione lungo la medesima (figura
2.11), proprio grazie al quale è possibile aumentare drasticamente le prestazioni della
macchina.
Gli ELM derivano dal collasso di tale barriera esterna, e si manifestano come eru-
zioni di plasma che, andando a colpire la parete della camera, più fredda, causano la
perdita di parte dell’energia interna dello stesso11 .
Un ELM causa un totale blackout dei circuiti magnetici, che vengono pratica-
mente “accecati” dall’improvviso lampo di energia, causando la registrazione di forti

11
Il meccanismo di innesco degli ELM è ancora sotto studio. Si noti, tuttavia, che la presenza
di ELM è considerata da molti necessaria, in quanto funge da “valvola di sfogo” per il plasma,
che altrimenti cotinuerebbe a crescere in energia. Sperimentalmente si è visto, infatti, che limitare
artificialmente gli ELM può causare enormi disruzioni nel plasma stesso.
34
i) Advanced Operating Modes
Plasma Pressure Core
Internal Transport Barrier

ii) H-mode (ITB)
Sawteeth
Edge Localized Modes
(ELMs)
L-mode
Edge Transport
Barrier (ETB)
JG03.35-27c
Pedestal (H-mode)
0 1
Normalised radius r/a
Figura 2.11: Struttura del plasma in H-mode.
escursioni (ovviamente non reali) della posizione verticale del plasma e il conseguen-
te intervento dell’algoritmo di controllo che, cercando di inseguire i segnali misurati,
porta alla saturazione di FRFA.
Non essendo ancora conosciuta una tecnica per limitare tale problema, si è visto
sperimentalmente al JET che la cosa migliore da fare al sopraggiungere di un ELM è
spegnere il controllore per qualche millisecondo, lasciando che il plasma scarichi l’e-
nergia in eccesso in evoluzione libera, per poi ritornare in una zona controllabile. Tale
tecnica, tuttavia, risulta essere altamente empirica, e proprio per questa sua caratteri-
stica non utilizzabile in situazioni estreme, dove una perdita di controllo verticale, per
quanto breve, potrebbe portare a grandi disruzioni e addirittura danni alla macchina.
Un’altra tecnica in fase di sperimentazione è quella di limitare gli ELM più grandi
provocandone di più piccoli frequentemente, forzando al massimo FRFA per pochi
35
istanti all’innalzarsi della misura delle Hα (ovvero al sopraggiungere di un ELM)
usando il Kick Controller. Pur avendo ottenuto buoni risultati, tale tecnica non è
ancora “canonizzata”, e lo studio del controllo degli ELM è ancora un campo aperto.
36
Capitolo 3
Scrittura e porting del sistema di

controllo
In questo capitolo si parlerà diffusamente del porting delle libre-
rie (BaseLib2), e dell’esecutore di thread realtime su di esse ba-
sato (MARTe), dall’architettura proprietaria VxWorks al sistema
operativo open source Linux-RTAI, soffermandosi brevemente sulla
struttura di questa architettura, e prestando particolare attenzione
alle difficoltà incontrate nel processo.
3.1 Introduzione
Una delle prime domande che potrebbero sorgere considerando il lavoro svolto riguar-
da, senza dubbio, le motivazioni dietro lo spendere tempo e risorse per effettuare il
porting di software dalla piattaforma VxWorks (o un qualsiasi altro sistema operati-
vo realtime proprietario) a Linux-RTAI. È possibile individuare molte caratteristiche
che rendono Linux-RTAI decisamente appetibile per un impiego pratico, sia esso nel
campo della ricerca che in quello industriale, tra le quali:
37
CAP. 3 Scrittura e porting del sistema di controllo 3.1 Introduzione
• Costo di licenza nullo. Linux-RTAI è rilasciato come software libero secondo
la licenza GPL1 , ed è liberamente scaricabile dalla rete. Nessuna royalty è
dovuta ai programmatori per l’uso di RTAI o per distribuire software basato su
di esso. Contando il costo elevatissimo di piattaforme realtime blasonate come
VxWorks, questa voce risulta sicuramente una delle più interessanti dal punto
di vista industriale;
• Sistema attivamente sviluppato. Linux-RTAI è sviluppato da una comu-
nità piuttosto ampia di programmatori. Ciò implica che eventuali bug ri-
portati o nuove funzionalità, non appena testate, vengano immediatamente
rese pubbliche, senza dover attendere il classico ciclo di rilascio dei software
closed-source;
• Compilatore moderno ed ottimizzato. È possibile sviluppare software che
fa uso di RTAI usando l’ottimo compilatore della GNU2 chiamato gcc, anch’esso
open source, gratuito e continuamente aggiornato;
• Sistema multipiattaforma. Linux-RTAI esiste per numerose architetture,
quali x86 e PowerPC, cosa che permette di scrivere software estremamente
portabile3 ;
• Facilità di installazione. L’installazione di Linux-RTAI non richiede altro che

1
General Public License, la più diffusa licenza open-source che obbliga sia a rilascia-
re il codice sorgente assieme al software, sia ad applicare la medesima licenza a tut-
to il software derivato. Per maggiori informazioni è possibile consultare il sito ufficiale
http://www.gnu.org/licenses/gpl.html.
2
GNU is Not Unix, l’associazione no-profit che si occupa della diffusione del kernel Linux, della
licenza GPL, ed in generale della filosofia Open Source.
3
Si noti, tuttavia, che il “cavallo di battaglia” di Linux-RTAI è la piattaforma x86, la più testata
e meglio funzionante.
38
CAP. 3 Scrittura e porting del sistema di controllo 3.1 Introduzione
il download di un kernel “Vanilla”4 dal sito ufficiale, e dell’applicazione di una
patch;
• Facilità di sviluppo. Essendo nulla più che una modifica al kernel standard,
RTAI permette l’uso di tutti i software che funzionano normalmente sotto Linux,
ivi compresi ambienti grafici quali Gnome o KDE, e strumenti di sviluppo quali
Eclipse o Netbeans, dando la possibilità di testare il codice realtime direttamente
sulla stessa macchina su cui si effettua lo sviluppo;
• Interfacce grafiche. Grazie alla possibilità di eseguire sulla stessa macchina
codice realtime e non, è facile pensare e progettare interfacce grafiche e soft-
ware di visualizzazione dati, senza curarsi di come questi possano penalizzare
le prestazioni (perché, a tutti gli effetti, non le penalizzano, venendo eseguiti
solo negli istanti di tempo in cui la CPU non è impegnata ad eseguire codice
realtime);
• Sorgenti liberi. La disponibilità dei sorgenti del kernel Linux e di RTAI rende
possibile, in casi estremi, personalizzare il codice di base del sistema operati-
vo stesso, garantendo la possibilità di migliorare ulteriormente le prestazioni
eliminando codice non utilizzato, o regolandone in maniera fine i parametri di
funzionamento5 .
A questi si aggiunge, pur non essendo un vantaggio tangibile di RTAI su soluzioni
proprietare, un discorso più “filosofico”: l’uso di tecnologie open-source, specie nel

4
Dove per “kernel Vanilla” si intende la versione del kernel ufficiale fornita da
http://www.kernel.org senza alcuna patch applicata.
5
In questo caso, tuttavia, la GPL impone di ridistribuire il codice sorgente delle modifiche appor-
tate ad RTAI secondo la stessa licenza. In altri termini è possibile sviluppare software proprietario
(closed source) che usa le librerie di RTAI, ma è illegale modificare RTAI e quindi ridistribuirlo senza
fornire i sorgenti modificati.
39
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo
campo della ricerca, rappresenta un notevole passo in avanti, verso un futuro in cui
il sapere sia condiviso e le scoperte compiute da un qualsiasi ente di ricerca diventino
immediatamente disponibili per tutti gli altri, favorendo lo sviluppo e la diffusione
della conoscenza, evitando perdite di tempo per ripercorrere i passi già compiuti da
altri, e slegandosi inoltre dai vincoli imposti dalle grandi multinazionali, siano esse
del campo informatico o meno.
3.2 Implementazione del controllo
Implementare un controllo come quello richiesto dalla stabilizzazione verticale al JET
non è di certo un compito banale: per quanto gli algoritmi illustrati nel capitolo
precedente siano relativamente semplici, riuscire a costruire una piattaforma hardware
e software capace delle prestazioni necessarie, ma che sia al contempo stabile, robusta,
failsafe e facilmente aggiornabile, rappresenta sicuramente una sfida.
Inoltre si è sentita la forte necessità di scrivere il codice del sistema di controllo
nel modo più astratto possibile, delegando il compito di interfacciarsi con l’hardware
ad un pacchetto di librerie sviluppate internamente dal nome BaseLib2, e limitan-
do quindi alla riscrittura di parte di quest’ultime il lavoro necessario al porting da
un’architettura all’altra6 .
Dal punto di vista controllistico, inoltre, uno dei punti di forza di questa libreria
è la possibilità di scrivere codice di controllo in un modo estremamente modulare, di-
videndolo in blocchi software indipendenti tra di loro (ed indipendentemente testabili).
6
In realtà la BaseLib2 è una libreria estremamente complessa che fornisce decine di funzionalità
aggiuntive al C++, arrivando anche a stravolgerne il funzionamento. Per maggiori dettagli ed una
visione d’insieme di questa libreria si rimanda all’appendice apposita.
40
3.2.1 Le GAM
I “blocchi di codice” denominati GAM (General Application Module) sono dei sem-
plici oggetti capaci di comunicare tra loro attraverso un database di segnali (detto
DDB, Dynamic Data Buffer ). Le GAM scelte per svolgere un dato compito vengono
eseguite da un esecutore realtime una dopo l’altra: ciascuna di esse leggerà i segnali
di interesse dal DDB, effettuerà le operazioni che le competono, e quindi salverà i suoi
segnali di uscita. Si noti come tale sistema sia concettualmente estremamente simile
a quello degli schemi a blocchi (figura 3.1).
Le GAM vengono sviluppate in C++: si tratta di semplici classi derivanti dalla
classe astratta GAM, fornita dalla BaseLib2, della quale reimplementano due funzioni
virtuali pure particolari, nella fattispecie:
• Initialise(), che si occupa di inizializzare la GAM e di aggiungere le interfacce
di comunicazione tra il DDB e la GAM stessa, caricando i parametri da un
oggetto di tipo CDB contenente la configurazione desiderata7 per la GAM;
• Execute(), che contiene il codice vero e proprio della GAM, eventualmente spe-
cializzato a seconda dello stato dell’esperimento (a titolo d’esempio si consideri
il diverso comportamento che una GAM che si occupa del salvataggio dati su
hard disk deve avere nel caso di idle o nel caso di esperimento in corso).
Un tipo particolare di GAM è quello denominato I/O GAM. Laddove le GAM
contengono la “logica di funzionamento” del controllore, le I/O GAM sono responsabili
della comunicazione con l’hardware vero e proprio, facendo da interfaccia tra la logica
di alto livello della BaseLib2 e il driver, garantendo di poter trattare l’acquisizione o

7
Per maggiori dettagli su CDB si confronti l’appendice relativa alla BaseLib2.
41
C u
P y
v
H
read(v)
GAM
write(u) C
D
read(u)
GAM
D write(y) P
TIME
B read(y)
GAM
write(v) H
Figura 3.1: Passaggio da uno schema a blocchi alla struttura a GAM.
la scrittura di segnali come fosse una normale parte del processo di elaborazione del
controllore. Si noti, tuttavia, che il concetto di I/O GAM è prettamente logico: a
livello di codice nulla differenzia una GAM standard da una di I/O.
42
3.2.2 Struttura di VsGAM
L’algoritmo di stabilizzazione verticale del plasma è stato implementato come due
GAM distinte: una che si occupa di effettuare il controllo vero e proprio, nella parte
di velocità e corrente cosı̀ come in quella adattativa, chiamata ControlGAM, e un’altra,
detta KickControlGAM, che si occupa, qualora deisderato, di sostituire l’uscita della
precedente con dei valori preprogrammati all’insorgere di eventi particolari.
ControlGAM
La parte che effettua il controllo vero e proprio è riportata nei listati 3.1 e 3.28 .
Per quanto riguarda la funzione di inizializzazione (listato 3.1), facilmente com-
prensibile, è da notare l’estrema semplicità con cui è possibile implementare una GAM.
Il codice verifica la presenza dei parametri necessari nel CDB fornito, crea le interfacce
verso il DDB (funzioni AddInputInterface e AddOutputInterface) e “aggancia” i
vari segnali attraverso le funzioni AddSignal e ObjectLoadSetup9 .
8
Si noti che il codice qui riportato non è identico al codice effettivamente implementato: per motii
di spazio e semplicità sono state omesse tutte le istruzioni relative al debug ed al logging degli errori,
ed i commenti in formato Doxygen per la generazione automatica della documentazione.
9
Questa funzione non fa nient’altro che configurare i segnali leggendoli direttamente dal CDB se
scritti in un formato standard.
43
Listato 3.1: ControlGAM::Initialise().

1 bool ControlGAM::Initialise(ConfigurationDataBase& cdbData)
2 {
3 CDBExtended cdb(cdbData);
4
5 // Add input/output interfaces
6 if(!AddInputInterface(input,"InputInterface")){return False;}
7 if(!AddOutputInterface(output,"OutputInterface")){return False;}
8
9 // Add output(s)
10 if(!cdb−>Move("Outputs")){return False;}
11 if(!cdb−>NumberOfChildren()){return False;
12 } else {numberOfOutputs = cdb−>NumberOfChildren();}
13 if(numberOfOutputs == 0){return False;}
14 if(!output−>ObjectLoadSetup(cdb, NULL)){return False;}
15 cdb−>MoveToFather();
16
17 // Add input(s)
18 if(!cdb−>Move("Inputs")){return False;}
19 numberOfInputs = cdb−>NumberOfChildren();
20 if(numberOfInputs == 0){return False;}
21 if(!cdb.ReadFString(secTimeBaseSignal,"TimeBaseSignalName") ){
22 return False;
23 }
24
25 if(!input−>AddSignal(secTimeBaseSignal.Buffer() ,"float")){
26 return False;
27 }
28 if(!cdb.ReadFString(vGainProportionalityBaseSignal,
29 "VgainProportionalityBase") ){return False;}
30 if(!input−>AddSignal(vGainProportionalityBaseSignal.Buffer() ,"float")){
31 return False;
32 }
33 if(!cdb.ReadFString(usecTimeSignal,"TimeSignalName")){return False;}
34 if(!input−>AddSignal(usecTimeSignal.Buffer(), "int")){return False;}
35 cdb−>MoveToFather();
36
37 return True;
38 }
Il cuore del controllore, la funzione Execute(), è invece riportato nel listato 3.2. Le
righe 3 e 26 effettuano le operazioni di lettura e scrittura dal DDB, mentre lo switch-
case diversifica le operazioni da eseguire a seconda della situazione dell’esperimento:
in particolare nel caso di GAMOnline (ovverosia di esperimento in corso) vengono ef-
fettuate le vere e proprie operazioni di controllo, mentre nella fase di GAMPrepulse
44
(subito prima di un esperimento) vengono inizializzate le strutture (in tutte le altre
fasi la ControlGAM non agisce).
Listato 3.2: ControlGAM::Execute().

1 bool ControlGAM::Execute(GAM FunctionNumbers functionNumber){
2
3 input−>Read();
4 switch( functionNumber ){
5
6 case GAMOnline : {
7 // Read Input
8 float ∗data = (float ∗)input−>Buffer();
9 secTimeBase = data[0];
10 vGainProportionalityBase = data[1];
11 usecTime = ((int∗)data)[2];
12
13 // Waveform generation
14 GenerateWaveformControl(secTimeBase, waveStruct);
15 GenerateLookupTable(vGainProportionalityBase, waveStruct);
16
17 // Control
18 PerformControl(usecTime, waveStruct, waveOutput);
19
20 // Write Output
21 float ∗out = (float ∗)output−>Buffer();
22 out[0] = (−1)∗(waveOutput.velocityLoopGainOutput);
23 out[1] = waveOutput.frfaVoltageReferenceWaveform;
24 out[2] = waveOutput.frfaFrequency;
25 out[3] = waveOutput.frfaCommandVoltage;
26 output−>Write();
27 } break;
28
29 case GAMPrepulse :{
30 // Init parameter waveforms before pulse
31 waveStruct.InitControlWaveStruct();
32 waveOutput.InitOutputReferenceStruct();
33 waveStructMeasured.InitWaveformControlMeasuredDataStruct();
34 waveStructTrue.InitWaveformControlTrueDataStruct();
35 InitPulseWaveControlGenerator();
36 InitPulseControl();
37 }
38 case GAMOffline :
39 case GAMSafety :{
40 } break;
41 }
42 return True;
43 }
45
In particolare, nella fase di GAMOnline, le righe dalla 7 alla 11 caricano nelle varia-
bili locali della classe il contenuto del DDB, le righe 14 e 15 caricano nella struttura
waveStruct i valori preprogrammati per correnti e guadagni, la riga 18 effettua il con-
trollo vero e proprio (incapsulato nella funzione PerformControl(), che a sua volta
richiama altre funzioni per effettuare i calcoli necessari, come riportato nel capitolo
precedente), ed infine le righe da 21 a 26 scrivono i risultati (i.e. le azioni di controllo)
sul DDB.
La funzione PerformControl() è riportata nel listato 3.3. Le righe 6 e 7 effettuano
il calcolo dell’errore di corrente; la 10 aggiorna la misura dei segnali calcolati nell’i-
stante di campionamento precedente presenti nella struttura waveStructMeasured;
le linee dalla 13 alla 14 effettuano dei controlli sull’attuale condizione della macchina
a stati che segnala l’andamento dell’esperimento per attuare controlli particolari nelle
fasi di creazione e terminazione del plasma, per segnalare l’avvenuta saturazione su
FRFA e gestire il cambio di segno del feedback nel passaggio tra plasma circolare
e plasma in H-mode; le righe 20-25 sulla base della frequenza di switch di FRFA
calcolano i nuovi guadagni per il controllo di corrente e velocità (secondo la logica
illustrata nel capitolo precedente), controllo che viene materialmente calcolato nelle
seguenti righe 28-30. Infine le ultime righe riempiono la struttura per l’output dei
dati e concludono l’esecuzione della funzione.
46
Listato 3.3: ControlGAM::PerformControl().

1 bool ControlGAM::PerformControl(int usecTime,
2 WaveformControlInputDataStruct& waveStruct,
3 WaveformControlMeasuredDataStruct& waveStructMeasured,
4 OutputReferenceStruct& waveOutput
5 ){
6 localControl.currentError = waveStruct.frfaCurrentReferenceWaveform
7 − waveStructMeasured.frfaCurrentMeasured;
8
9 // Update data
10 UpgradeOldData(waveStructMeasured);
11
12 //State machine functions

13 SetTerminationState(waveStructMeasured);
14 PlasmaTerminationControl(waveStructMeasured, waveOutput);
15 SaturationSetFrfaState(waveStructMeasured);
16 FrfaSaturationControl(waveOutput, waveStructMeasured);
17 ControllerPolaritySet(waveStructMeasured);
18
19 // Adaptive Control
20 localControl.proportionality= waveStruct.vgainProportionalityWaveform
21 ∗ waveStruct.currentLoopGainWaveform;
22 CalculateControllerGains(waveStruct);
23 CalculateSwitchingFreq(waveStructMeasured, waveOutput);
24 FrequencyGainAdaptation(usecTime, waveStructMeasured,
25 waveOutput, waveStruct);
26
27 // Controller
28 CurrentControl(usecTime, waveStruct, waveStructMeasured);
29 SpeedControl(waveStruct, waveStructMeasured);
30 ClassicControl(waveStruct, waveOutput);
31
32 // Fill structures for DDB
33 waveOutput.velocityLoopGainOutput = localControl.velocityLoopGain;
34 waveOutput.frfaVoltageReferenceWaveform =
35 waveStructMeasured.frfaVoltageReference;
36
37 return TRUE;
38 }
47
KickControlGAM
Il codice delle funzioni Initialise() ed Execute() di questa GAM viene omesso, in
quanto concettualmente e formalmente simile al precedente. Viene invece riportata
la breve funzione PerformKickControl() (listato 3.4) per illustrare il principio di
funzionamento di massima.
Listato 3.4: KickControlGAM::PerformKickControl().

1 bool KickControlGAM::PerformKickControl(int& usecTime,
2 WaveformKickMeasuredDataStruct& waveStructMeasured,
3 OutputReferenceStruct& waveOutput,
4 WaveformKickInputDataStruct& waveStruct
5 ){
6
7 MultiKickLogic(usecTime, waveStructMeasured, kickControlParameters,

8 waveOutput, waveStruct);
9 kickControlParameters.oldHalpha = waveStructMeasured.hAlpha;
10 KickControlOut(kickControlParameters, waveOutput);
11 KickController(waveOutput, waveStructMeasured,
12 kickControlParameters);
13
14 return TRUE;
15 }
La linea 7 richiama la funzione principale del controllore, che decide se attivare o
disattivare il Kick Controller sulla base della configurazione dello stesso. Qualora il
controllore debba intervenire, il valore di tensione fornito ad FRFA viene cambiato
in quello desiderato. Le linee 10 e 11 registrano le modifiche al valore di tensione su
FRFA effettuate dal Kick Controller, e le salvano materialmente nella variabile fornita
al DDB10 .
10
Le ultime due funzioni sono, in verità, composte da poche righe di codice. Tale codice non è
stato inserito direttamente nel corpo di PerformKickControl() al fine di permettere una maggiore
modularità e comprensibilità del codice nel caso di modifiche future.
48
CAP. 3 Scrittura e porting del sistema di controllo 3.3 Il sistema RT del JET: MARTe
3.3 Il sistema RT del JET: MARTe
Le due GAM illustrate precedentemente, che effettuano materialmente i calcoli per il
controllo, non sono ovviamente sufficienti a far funzionare il sistema di stabilizzazione
verticale del JET: numerosi altri elementi hanno bisogno di essere controllati via soft-
ware, in particolare la comunicazione con le apparecchiature di salvataggio dati e con
la macchina a stati che segnala in che fase dell’esperimento ci si trovi (preparazione
all’impulso, impulso, problemi tecnici, nascita e morte del plasma...), la ricezione delle
impostazioni di configurazione per un dato esperimento, l’invio di log di sistema, la
sincronizzazione con il clock esterno, il caricamento in memoria delle GAM e la loro
esecuzione in realtime...
Tutte queste operazioni vengono eseguite da MARTe (acronimo di Multithreaded
Application RealTime executor ), implementato in C++ usando le classi fornite dalla
BaseLib2.
MARTe è composto da una serie di classi che comunicano tra loro attraverso mes-
saggi, ciascuna con un compito specifico e ben determinato. Un grafico che illustra il
funzionamento di massima di MARTe è riportato in figura 3.2: la macchina a stati
si occupa di coordinare l’attività dei vari thread realtime, indicando i cambiamenti
di stato del Tokamak (prepulse, postpulse, offline...) segnalati da CODAS 11 . In par-
ticolare la macchina a stati invia le informazioni al gestore dei thread in esecuzione
(Realime Thread Pool in figura), il quale a sua volta manda quanto ricevuto ad ogni
singolo thread di sua responsabilità.

11
COntrol and Data Acquisition Systems, il gruppo che si occupa di coordinare l’impianto
informatico e di comunicazione del JET.
49
CAP. 3 Scrittura e porting del sistema di controllo 3.3 Il sistema RT del JET: MARTe
Figura 3.2: Interazione tra MARTe, hardware e sistemi esterni.
Una serie di moduli di comunicazione si preoccupa di “tradurre” i segnali esterni
provenienti da CODAS (quali lo scenario desiderato per l’esperimento ed eventuali
situazioni di emergenza) in segnali comprensibili alle GAM ed alla macchina a stati.
Ogni realtime thread è composto della serie di GAM ed I/O GAM che lo carat-
terizza; queste ultime si occupano di comunicare direttamente con l’hardware (nel
caso della stabilizzazione verticale, in particolare, con le schede di acquisizione e di
conversione digitale-analogico). Si noti che ogni oggetto hardware non può essere
“collegato” a più di una I/O GAM, al fine di evitare conflitti tra thread realtime.
50
CAP. 3 Scrittura e porting del sistema di controllo 3.4 Scelta del sistema operativo realtime
3.4 Scelta del sistema operativo realtime
MARTe, e la BaseLib2 su cui si basa, funzionavano già correttamente sotto VxWorks.
Tuttavia, viste le caratteristiche positive di Linux già evidenziate, si sentiva il forte
desiderio di effettuare le correzioni necessarie perché esso compilasse e funzionasse
prima in userspace, e quindi in realtime ed in kernelspace con RTAI.
Per quanto riguarda il porting sotto Linux in userspace, le modifiche necessarie
non sono state eccessivamente estese: si è trattato principalmente di correggere alcu-
ne chiamate di sistema per renderle compatibili con lo standard POSIX, e riscrivere
alcune funzioni (in particolare quelle di interfacciamento con l’utente).
Finita questa operazione si è passati al porting del sistema sotto un ambiente Li-
nux realtime. Di conseguenza la prima scelta che ci si è trovati a dover affrontare è
stata quella relativa a quale patch del kernel adottare tra le varie proposte, in parti-
colare tra Linux-RTAI e Xenomai12 .
Tra i due contendenti, infine, si è scelto di adottare Linux-RTAI, soprattutto per
le sue maggiori performance rispetto a Xenomai: quest’ultimo, infatti, aggiunge pa-
recchio codice per garantire un facile porting da altri sistemi operativi realtime13 ,
cosa che comporta, ovviamente, una riduzione delle prestazioni, fondamentali per la
stabilizzazione verticale.
12
Si noti che le due patch, seppure estremamente diverse come obiettivi, possiedono una base di
codice comune: Xenomai è infatti nato da un branch di RTAI.
13
Xenomai, infatti, introduce il concetto di maschera. Una maschera, nel gergo di Xenomai, è
un’interfaccia che “emula” il set di istruzioni di un altro sistema operativo realtime.
51
CAP. 3 Scrittura e porting del sistema di controllo 3.5 Linux-RTAI
3.5 Linux-RTAI
Il kernel Linux (nella sua incarnazione “Vanilla”) possiede numerose caratteristiche
che non lo rendono ideale per un uso realtime, tra le quali [15]:
• Coarse-Grained Synchronization, ovvero il fatto che le chiamate di sistema
non siano interrompibili. In altri termini, qualora un processo a bassa priorità
ne effettui una, un eventuale ulteriore processo con priorità realtime non po-
trebbe essere eseguito fino al termine dell’intera chiamata (cosa evidentemente
inaccettabile in un sistema hard-realtime);
• Paging, ovvero il processo di swapping di pagine di memoria dalla RAM all’hard
disk che, evidentemente, è non deterministico;
• Scheduling “Fairness”, ovvero il fatto che il kernel Linux cerchi di distribuire
equamente il tempo macchina tra i vari processi, di conseguenza rischiando di
interromperne alcuni con priorità realtime per permettere lo scheduling di altri
meno importanti;
• Request reordering, ovvero il processo di raggruppare le operazioni di I/O
in modo da garantire un uso ottimale dell’hardware (ma allo stesso tempo
inserendo dei ritardi assolutamente non determinabili a priori);
• Operazioni batch, eseguite dal kernel Linux per “riorganizzare” l’uso delle
risorse ed ottimizzare la memoria.
Col passare del tempo, soprattutto assecondando le richieste degli utilizzatori de-
sktop, numerose migliorie sono state apportate al kernel in modo da renderlo, quan-
tomeno, soft-realtime. In particolare l’attenzione degli sviluppatori si è incentrata sul
52
rendere il kernel e le chiamate di sistema interrompibili, eccetto che in alcuni punti
critici, e nell’ottimizzare l’uso del processore rilasciandolo durante porzioni di codice
non fondamentali. Altro punto di sviluppo è stato quello del miglioramento dell’algo-
ritmo di scheduling, che è passato dall’avere un tempo di esecuzione proporzionale al
numero di processi attivi, ad uno fondamentalmente costante.
Queste evoluzioni nel codice del kernel hanno reso Linux un sistema operativo
pronto per il desktop, capace di riprodurre filmati e audio senza evidenti interruzioni,
ed in generale di garantire la “user experience” che normalmente ci si aspetta da un
computer moderno. Tuttavia tali miglioramenti non sono risultati essere sufficienti
per un uso industriale, più che per la velocità del sistema operativo in sé, quanto per
l’imprevedibilità dei tempi di esecuzione qualora il sistema venga messo sotto stress
(per esempio con un uso intensivo della rete). Per questo motivo numerosi studi sono
stati effettuati sulle possibili patch da applicare al kernel per migliorarne il compor-
tamento e renderlo hard-realtime. Tra di queste una delle migliori è, per l’appunto,
Linux-RTAI, sviluppato dal Dipartimento di Ingegneria Aeropaziale del Politecnico
di Milano (DIAPM).
3.5.1 Funzionamento di RTAI
Per capire il funzionamento di Linux-RTAI si osservi innanzitutto figura 3.3, rap-
presentante lo schema di funzionamento semplificato dello scheduler del kernel Linux
standard. Lo scheduler di Linux si trova a dover gestire sia i thread realtime che quelli
non realtime; da ciò derivano i problemi illustrati nel paragrafo precedente: qualora
un thread non realtime esegua istruzioni bloccanti, il thread realtime non potrà essere
53
eseguito finché il precedente non rilasci esplicitamente la CPU.
User Space
RT Non-RT Non-RT
Proc Proc Proc
System Process
Calls Scheduling
Kernel Space
RT Non-RT Non-RT
Task Task Task
Task Scheduling
HW Raw
Interrupts Data
Hardware
Figura 3.3: Schema di funzionamento di Linux senza le patch di RTAI.
La patch RTAI cerca di risolvere questo problema utilizzando una strategia intel-
ligente, ovverosia quella di frapporre tra l’hardware e il kernel Linux un nanokernel
minimale chiamato ADEOS/iPipe. Tale nanokernel è composto, sostanzialmente,
solo da un particolare “scheduler di sistemi operativi”: l’idea di fondo, infatti, è quella
di permettere a più sistemi operativi di convivere su una stessa macchina, venendo ese-
guiti in sequenza14 . RTAI modifica ADEOS/iPipe (ribattezzato ADEOS/RTHAL)
in modo che esso intercetti le chiamate di sistema ed esegua i task realtime, assegnan-
14
ADEOS/iPipe funziona in modo simile ad una virtual machine (quale VMWare), ma usando
un principio di base diverso: laddove una virtual machine “sfrutta” il sistema operativo ospitante
per emularne un altro (ospite), fornendo a quest’ultimo periferiche hardware “virtuali” che si inter-
facciano a quelle reali, ADEOS/iPipe pone tutti i sistemi operativi sullo stesso piano, mettendoli
in comunicazione in sequenza con l’hardware reale della macchina. Tale tecnica, con l’avvento dei
nuovi processori dotati di un set di istruzioni dedicato specificamente alla virtualizzazione, è molto
promettente, specie per quanto riguarda le prestazioni.
54
do una priorità bassa al kernel Linux. In questo modo i processi non realtime (che
“vivono” nello spazio del kernel Linux) non hanno possibilità di bloccare quelli real-
time: ogni loro tentativo di accedere all’hardware (effettuando chiamate di sistema)
rimarrà infatti bloccato in coda nel livello di ADEOS/RTHAL, in attesa che la CPU
non sia impegnata con codice a maggiore priorità.
RTAI’s
Userspace Linux
Process User Space
(LXRT)
RTAI’s
Linux Kernel
Kernel Thread
ADEOS / RTHAL
HARDWARE
Figura 3.4: Comportamento del sistema modificato da RTAI.
3.5.2 RTAI ed i sistemi multicore
Un’architettura come quella di RTAI si presta facilmente all’uso su sistemi multipro-
cessore, come quello previsto per l’hardware della stabilizzazione verticale; in parti-
colare i programmatori di Linux e di RTAI hanno già previsto la possibilità di dare
55
all’utente il controllo sulla distribuzione del carico sui vari processori.
Per quanto riguarda il kernel Linux, è possibile specificare sulla riga di comando
del bootloader l’opzione isolcpus, indicando quali processori lo scheduler del kernel
Linux dovrà ignorare15 . Per ciò che concerne RTAI, invece, è possibile specificare con
l’istruzione rt set runnable on cpus su quali processori il thread realtime appena
creato dovrà essere eseguito.
Utilizzando queste due tecniche si è ottenuto che il kernel Linux lavori solo sul
primo processore della macchina, mentre i thread realtime vengono assegnati ai core
rimanenti. L’idea di fondo è quella di far sı̀ che ogni processore gestisca al più un
thread realtime, massimizzandone il tempo di esecuzione.
Si noti che allo stato attuale la macchina per la stabilizzazione verticale del plasma
possiede un processore a quattro core: di conseguenza, poiché come si è visto l’algo-
ritmo di stabilizzazione è composto da un unico thread, attualmente tre core vengono
dedicati ai processi non critici (ovverosia quelli dipendenti dal kernel Linux, quali il
logging, la gestione della rete, eccetera), e solo uno all’esecuzione esclusiva realtime.
3.5.3 Userspace o Kernelspace?
La principale decisione presa riguardo Linux-RTAI è stata quella tra il lavorare in
kernelspace (usando quindi i thread nativi RTAI), oppure in userspace usando le
estensioni di RTAI chiamate LXRT, che consentono di rendere realtime thread creati
in spazio utente. La seconda ipotesi, in particolare, era particolarmente interessante

15
La sintassi del parametro è isolcpus=n1[,n2,n3...]. Ogni processore è identificato da un
numero intero, e il primo core della macchina è indicato come 0.
56
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM
in quanto garantiva la possibilità di utilizzare tutti i software disponibili sotto Linux
per il debug del codice, quali gdb o ddd, ed il non dover riavviare la macchina ad ogni
crash dell’applicazione.
Tuttavia alla fine si è scelto di lavorare in kernelspace soprattutto per garantire
le prestazioni massime. A tal proposito si veda il grafico di figura 3.5 dove sono ri-
portati gli andamenti di latenza media e jitter16 nel caso di thread in kernelspace e
di LXRT, e a seconda dell’architettura hardware considerata [14]. Si noti la minore
latenza dello scheduler standard rispetto a quello di LXRT, specie se confrontato con
il caso a singola CPU [14].
Inoltre si osservi anche come la piattaforma Intel abbia dimostrato essere decisa-
mente più adatta ad applicazioni realtime rispetto a quella AMD: da questa considera-
zione è derivata anche la scelta dell’hardware da utilizzare (per maggiori informazioni
sull’hardware usato si rimanda all’appendice apposita).
3.6 FCOMM
Una volta scelto di lavorare in kernelspace, uno dei principali problemi da affrontare
è stato quello di trovare un modo per effettuare chiamate di sistema (quali lettura e
scrittura su disco, ascolto di socket e similari) da parte dei kernel thread realtime. Si
incorre infatti in due problemi principali: generalmente le chiamate di sistema “lato
kernel” sono diverse da quelle userspace (la glibc 17 effettua lavoro intermedio per tra-
16
Per latenza e jitter si intendono rispettivamente il ritardo tra l’istante in cui si ha un interrupt
realtime e l’effettiva esecuzione del codice, e l’ampiezza della variazione della latenza nel tempo. In
un certo senso la latenza misura le prestazioni di un sistema realtime, mentre il jitter quanto esso sia
“deterministico”. Segue che in genere si preferisce, dovendo raggiungere un compromesso, un jitter
trascurabile ad una latenza bassa.
17
GNU C Library, la libreria standard C rilasciata dal progetto GNU.
57
32 bit schedule over interrupt

10
AMD 1 CPU
AMD 2 CPU
Intel 1 CPU
Intel 2 CPU
8 Jitter
Latency (uS)
0
RTAI-SCHED
RTAI-LXRT
Configuration
Figura 3.5: Confronto tra la latenza di thread in kernelspace ed in userspace (LXRT).
durre le chiamate standard POSIX in chiamate comprensibili al kernel Linux), e di
conseguenza si sarebbe dovuto necessariamente riadattare il codice dei software già
scritti al JET per utilizzare la diversa sintassi (cosa impensabile); inoltre, cosa ancora
più grave, essendo lo scheduler realtime slegato da quello di Linux, qualsiasi chiamata
al kernel avrebbe avuto seri problemi di sincronizzazione.
Una prima ipotesi è stata quella di riscrivere parte del codice del kernel Linux
introducendo meccanismi di sincronizzazione tra i thread realtime e il kernel stesso:
per quanto estremamente promettente dal punto di vista delle prestazioni (in quanto
non ci sarebbe stata la necessità di entrare ed uscire dal contesto del kernel come viene
ora fatto), questo avrebbe portato alla necessità di gestire un kernel personalizzato,
con tutti i problemi connessi (difficoltà di aggiornamento, mancanza di supporto da
parte della comunità open-source...).
58
Di conseguenza è stato necessario trovare una soluzione alternativa, che evitasse
di cambiare il codice esistente (ovverosia si frapponesse in maniera trasparente tra la
BaseLib2 ed il kernel stesso) e garantisse la sincronizzazione con lo scheduler realtime.
Tale soluzione è stata battezzata FCOMM .
FCOMM si compone di un modulo kernel e di un normale processo userspace: il
primo intercetta le chiamate di sistema effettuate dalla BaseLib2 in kernelspace e le
rigira al secondo che, composto da una serie di thread userspace, le esegue ritornando
il risultato della chiamata (figura 3.6). Un semaforo fa sı̀ che il modulo kernel attenda
la fine dell’esecuzione della chiamata da parte della componente userspace prima di
ritornare ad eseguire il codice della libreria (risolvendo quindi il problema di sincro-
nizzazione tra i due scheduler).
Numerosi altri semafori nel codice di FCOMM, inoltre, garantiscono che esso sia
thread-safe, ovvero capace di lavorare con più thread realtime, cosa fondamentale da-
to l’uso intensivo delle tecniche multithreading che fa la BaseLib2.
3.6.1 Analisi del funzionamento
Dal punto di vista dell’usufruitore, FCOMM è totalmente trasparente: una volta in-
clusi nel codice i file che rimappano le chiamate di sistema, basterà effettuare tali
chiamate normalmente, indipendentemente dal fatto che ci si trovi in realtime o me-
no18 , per vederle eseguite.

18
Si noti, tuttavia, che FCOMM non permette di rendere realtime chiamate di natura non tale
(come operazioni di I/O col disco). Un thread realtime che faccia ricorso a funzioni di questo tipo
59
Figura 3.6: Architettura di FCOMM.
Internamente il modulo kernel non fa nient’altro che copiare i dati passati alla chi-
mata di sistema nell’area di memoria condivisa tra la parte kernel e user di FCOMM, e
quindi invocare la funzione call remote function (listato 3.5) indicando quale chia-
mata di sistema si vuole eseguire (l’intero fun id, i cui valori possibili sono definiti
da una serie di direttive #define) e un puntatore ai parametri stessi con la relativa
dimensione (par ids e par size rispettivamente). Una volta completata la chiama-
ta di sistema, il modulo si preoccupa di deallocare la memoria condivisa e restituire
l’esito alla funzione chiamante.
resta bloccato finché la chiamata di sistema non è eseguita dal kernel Linux (rigorosamente non
realtime). Di conseguenza è necessario ricordare che eventuali thread con funzioni di controllore non
devono assolutamente compiere chiamate di questo tipo!
60
Listato 3.5: La funzione call remote function di FCOMM.

1 int call remote function(int fun id, unsigned long ∗par ids,
2 int par size)
3 {
4 mem function ∗mem;
5 int i = 0;
6 int id = 0;
7
8 while(test call remote function() < 1)

9 rt sem wait(fun call synch sem);
10
11 id = get rt free uid();
12 rt sem wait(fun caller mem block sem);
13
14 mem = (mem function ∗)real alloc(id, sizeof(mem function));

15 if(mem != 0) {
16 ∗remote fun call id shm = id;
17 mem−>fun id = fun id;
18 mem−>finished = 0;
19 mem−>error errno = 0;
20 for(; i<par size && i<MAX PARAMETERS CALL; i++)
21 mem−>parameter ids[i] = par ids[i];
22 } else {
23 rt printk("MEMORY ERROR!\n");
24 rt sem signal(fun caller mem block sem);
25 return ERROR SHM;
26 }
27 rt sem signal(fun caller user sem);
28
29 if(mem−>finished != 1) {
30 rt sem wait(fun caller kernel sem);
31 }
32
33 rt sem signal(fun caller mem block sem);

34 while(mem−>finished != 1) {
35 rt sem wait(fun return sem);
36 }
37
38 i = mem−>return value;
39 rt whoami()−>msg = mem−>error errno;
40 rt sem signal(fun call synch sem);
41 real free(mem);
42 return i;
43 }
In particolare le righe 8 e 9 attendono su un semaforo la disponibilità di un
thread di esecuzione in userspace; le righe da 11 a 33 copiano i parametri desi-
derati da kernelspace (dove risiedono) ad userspace (dove i thread di esecuzione
61
possono leggerli): notare come la copia di parametri sia protetta da un semaforo
(fun caller mem block sem) al fine di evitare che più thread scrivano contempora-
neamente nella zona di memoria comune tra user e kernelspace; le righe da 34 a 38
attendono che il thread userspace segnali di aver completato l’esecuzione e copiano
il valore di ritorno e l’eventuale codice d’errore da userspace; ed infine la riga 40
segnala agli altri thread eventualmente in attesa della liberazione di un thread di
esecuzione e la 41 libera la memoria allocata per il passaggio dei parametri. Un dia-
gramma di flusso che illustra il comportamento della funzione è riportato in figura 3.7.
In userspace, invece, FCOMM predispone una serie di thread di esecuzione e,
non appena viene richiesto di eseguire una chiamata di sistema con la già citata
call remote function, delega al primo thread disponibile l’esecuzione della medesi-
ma.
In figura 3.8 è illustrato il diagramma di flusso della componente userspace: nor-
malmente in attesa di richieste di esecuzione, non appena arriva una segnalazione sul
relativo semaforo da kernelspace, FCOMM si occupa di decrementare il numero di
thread di esecuzione disponibili (attualmente pari a 15), copiare i parametri per la
funzione da chiamare dalla zona di memoria condivisa con il kernel, eseguire la funzio-
ne stessa, memorizzando i valori di ritorno e l’eventuale codice di errore, e segnalando
al kernel il completamento dell’esecuzione.
62
Figura 3.7: Diagramma di flusso di call remote function.
63
Figura 3.8: Diagramma di flusso della componente userspace di FCOMM.
64
3.6.2 Funzioni aggiuntive
Oltre al meccanismo di cui sopra, FCOMM fa parte di un pacchetto di codice svilup-
pato per risolvere ulteriori problemi relativi all’esecuzione della BaseLib2 sotto RTAI,
in particolare la possibilità di utilizzare il C++ in kernelspace (supporto contestato
dallo stesso Linux Torvalds, e di conseguenza disattivato di default) e la possibilità
di effettuare dynamic cast tra i vari moduli kernel. Inoltre, al fine di rendere il
più agevole possibile l’uso di queste due ultime funzionalità in kernelspace, il codice
necessario è stato impacchettato in un singolo modulo da caricare in memoria prima
dell’esecuzione del codice basato sulla BaseLib2.
3.6.3 Problematiche e soluzioni
Durante lo sviluppo e il debug di un meccanismo di sincronizzazione complesso e
thread-safe come quello di FCOMM ci si è scontrati con numerose problematiche di
difficile soluzione. Ad aggravare la situazione c’è stato il problema dell’impossibilità
di eseguire un debugger sul codice funzionante in kernelspace, e il fatto di ottenere
blocchi totali di sistema ad ogni minimo errore (cosa che ha messo a dura prova anche
l’hardware delle macchine usate per lo sviluppo).
La maggior parte dei problemi emersi sono derivati dall’esecuzione di applicativi
multithreaded. Poiché in kernelspace non è possibile allocare memoria a piacimento,
si è dovuto risolvere il problema di dove porre i dati richiesti per la comunicazione
tra parte userspace e parte kernelspace di FCOMM preallocando, all’inserimento del
modulo, un certo spazio di heap, spazio, ovviamente, condiviso tra tutti i thread.
Di conseguenza è successo talvolta che un thread sovrascrivesse parte della memo-
65
ria destinata ai dati di un altro thread, causando errori imprevedibili e per giunta
difficilmente riproducibili, dipendendo largamente da condizioni a contorno.
Una volta localizzata la fonte d’errore, quindi, è stato necessario aggiungere di
volta in volta vari semafori atti a proteggere la memoria finché un thread non avesse
finito il suo compito. Tuttavia la complessità “logica” della programmazione parallela
ha reso difficile, se non impossibile, prevedere tutte le possibili situazioni di conflitto,
e nuovi errori di sincronizzazione emergevano ogni volta che si provava ad eseguire un
nuovo programma, o a modificarne uno esistente. Di conseguenza si è provveduto a
scrivere alcuni programmi di test per “stressare” sempre di più il meccanismo di sin-
cronizzazione, finché non si è stati sufficientemente sicuri di aver eliminato ogni errore.
Altra fonte di problemi è stata la configurazione di RTAI. Di base la patch è con-
figurata per un utilizzo “normale” del sistema: controllore in C che gira come modulo
kernel. L’enorme stress e quantitativo di oggetti RTAI19 generati dalla BaseLib2, tut-
tavia, portava spesso a crash di sistema assolutamente inspiegabili. Dopo numerose
analisi del codice (verificando anche nella versione Linux non-RTAI della BaseLib2 )
si è capito che il problema era proprio il limite imposto sul numero di oggetti RTAI
creabili. Il test principale della BaseLib2, infatti, instanzia numerosi oggetti, ciascuno
dei quali fa largo uso di semafori e mutex: al momento dell’esecuzione del test l’ap-
plicativo cercava di allocare più oggetti di quanti permessi e la macchina andava in
blocco. Tale problema è stato risolto aumentando la relativa voce nella configurazione
di RTAI, e ricompilando i vari moduli.
Un ulteriore problema è sorto in un test che faceva uso delle operazioni atomiche
19
Dove per “oggetto RTAI” si intendono, fondamentalmente, le primitive di sincronizzazione, quali
semafori e mutex.
66
fornite dalla BaseLib2 : poiché tali operazioni (incrementi e decrementi) vengono ese-
guite senza mai rilasciare il processore (al fine di non poter essere interrotte -da cui il
nome “atomiche”), qualora eseguite nello stesso processore del test portavano ad un
completo blocco della macchina (mentre il processore continuava indefinitamente ad
eseguirle).
Pur non esistendo una vera e propria soluzione a questo problema (in quanto di-
pendente dal funzionamento delle operazioni atomiche e di RTAI), la scoperta del bug
ha avuto il merito di far sorgere la questione su come gestire i sistemi multiprocessore,
come la macchina sulla quale girerà il sistema di stabilizzazione verticale. La prassi
attualmente seguita è quella di porre il kernel Linux su un processore, e dedicare
gli altri a RTAI. Questo ha indirettamente risolto anche il problema delle operazioni
atomiche: poiché il thread di gestione e i thread che “materialmente” eseguono tali
operazioni si trovano su due processori distinti, non viene più a crearsi la situazione
di blocco (che tuttavia persevera nelle macchine a singolo processore).
Il porting delle funzionalità del C++ in kernelspace, invece, è stato relativamente
semplice: usando in parte i suggerimenti trovati in rete di chi aveva già effettuato il
tentativo, copiando l’implementazione GNU dei metodi new e delete e aggiornando
i makefile dei moduli in modo da utilizzare il compilatore C++, si è riusciti in modo
agevole a far funzionare le cose.
Il problema principale è nato relativamente agli oggetti statici (i.e. quelli non
creati tramite le funzioni new e delete): il compilatore C++ in userspace si occupa,
normalmente, di richiamare i relativi costruttori, cosa che non avviene in kernelspace.
Ciò causava la non corretta inizializzazione (seguita da inevitabile crash) di molti og-
getti della BaseLib2. Il problema è stato risolto con un semplice hack: due funzioni,
67
CAP. 3 Scrittura e porting del sistema di controllo 3.7 RTAIConsole
chiamate init all constructors e delete all deconstructors, ottengono una li-
sta di puntatori a funzione dei costruttori e distruttori delle classi, e li richiamano in
sequenza. La soluzione del problema, quindi, si limita al dover lanciare tali funzioni
al caricamento ed alla rimozione del modulo kernel d’interesse.
Ultimo problema affrontato, infine, è stato quello di permettere dynamic cast tra
diversi moduli del kernel, altra cosa fondamentale per il buon funzionamento del-
la BaseLib2. Pur funzionando correttamente il C++ in kernelspace, infatti, tutte
le chiamate a dynamic cast fallivano. La causa è stata infine individuata nel fatto
che, normalmente, la glibc effettua i cast dinamici confrontando puntatori e non com-
parando le stringhe contenenti il nome della classe vere e proprie. Poiché i moduli
kernel vengono visti come “eseguibili differenti” e non come librerie, il confronto tra
puntatori, ovviamente, non poteva che fallire.
Il problema è stato risolto modificando il codice GNU utilizzato per portare il
C++ in kernelspace in modo da eseguire la più lenta comparazione tra stringhe, im-
postando la variabile del preprocessore GXX MERGED TYPEINFO NAMES a 0.
3.7 RTAIConsole
Per facilitare l’utilizzo di RTAI è stata sviluppata una shell, denominata RTAICon-
sole, sulla falsariga di quella già esistente per VxWorks. Tale console si compone di
un modulo kernel e una componente userspace: il primo, in particolare, espone una
funzione, CallRemoteFunction, il cui compito è quello di eseguire funzioni esportate
in kernelspace semplicemente indicandone l’indirizzo; la seconda, invece, si occupa
dell’interfacciamento con l’utente (uno screenshot della parte userspace è riportato in
68
figura 3.9.
Figura 3.9: Screenshot della console RTAI in azione.
Uno dei compiti principali della shell è quello, in fase di caricamento di un modulo,
di eseguire, se presente, la precedentemente citata funzione init all constructors
(e, simmetricamente, delete all deconstructors in fase di rimozione), permettendo
di risolvere il problema degli oggetti statici non inizializzati.
Per ottenere gli indirizzi in kernelspace di una funzione, RTAIConsole legge il file
/proc/kallsyms, generato in tempo reale dal kernel Linux, e contenente l’elenco di
tali funzioni.
In aggiunta a questo, RTAIConsole garantisce numerose altre funzioni che, in un
certo senso, cercano di “avvicinare” userspace e kernelspace (proprio come avviene
in VxWorks, dove non esiste lo spazio utente protetto), permettendo di eseguire sia
funzioni kernel che programmi userspace, e garantendo un supporto basilare per l’e-
69
secuzione di script con sintassi bash-like, utili per velocizzare operazioni ripetitive
(come il caricamento dei moduli standard della BaseLib2 ed eventualmente, in futu-
ro, avviare in modo automatico MARTe).
Si noti, tuttavia, che la shell è un progetto ancora in fase embrionale, e solo lo
stretto necessario ad un funzionamento di base del sistema è implementato. Il progetto
finale è quello, molto ambizioso, di permettere la creazione di oggetti a partire da
classi C++ in modo da far sı̀ che la shell possa interagire direttamente, anche per
mezzo di script, con la BaseLib2 stessa, eventualmente anche usando un interprete
C/C++ come CINT20 . Ciò garantirebbe la possibilità di scrivere codice ed eseguirlo
in realtime direttamente, senza passare per la compilazione ed il linking, ed ottenere
quindi una perfetta piattaforma di test per sistemi di controllo sotto RTAI.
20
CINT, o C INTerpreter, è un progetto sviluppato al CERN. Maggiori informazioni sono reperibili
sul sito ufficiale: http://root.cern.ch/twiki/bin/view/ROOT/CINT.
70
Capitolo 4
Risultati ottenuti
Con il lavoro di porting effettuato si è riusciti ad ottenere una piattaforma stabile,
efficiente e semplice da programmare per lo svolgimento di compiti hard e soft realti-
me, il tutto basato esclusivamente su software open source e liberamente distribuibile
(kernel Linux e patch RTAI).
Il software è costituito da vari moduli kernel, ciascuno dei quali fornisce una par-
te delle funzionalità del pacchetto: il modulo della BaseLib2 e FCOMM formano il
nucleo centrale sulla quale si basa il controllore usato per la stabilizzazione verticale
(o in generale un generico controllore sviluppato secondo il paradigma delle GAM),
mentre RTAIConsole permette di far comunicare kernelspace ed userspace in maniera
semplice.
Assieme al pacchetto di software “di base”, altre utility sono state sviluppate, in
particolare una shell che permette di manipolare in maniera agevole i moduli usati,
anche grazie alla capacità di eseguire dei file di script creati ad hoc per evitare di
perdere tempo con azioni ripetitive.
71
CAP. 4 Risultati ottenuti
Inoltre numerosi applicativi di test sono stati scritti da zero o portati sulla nuova
piattaforma, sia per verificarne il funzionamento, sia per velocizzare l’apprendimento
della peculiare sintassi della BaseLib2 da parte dell’utente finale.
Assieme al software sviluppato si è provveduto anche a creare un sistema Linux su
cui esso potesse girare. Tale sistema, costruito a partire da una normale installazione
di Gentoo da “stage 1”, è stato progettato in modo da essere il più minimale possibile:
il kernel è stato ridotto all’osso, eliminando tutti i moduli non necessari e compilando
statici solo i driver dell’hardware effettivamente presente nella macchina, e tutti i
file di manualistica e documentazione sono stati rimossi, cosı̀ come i software non
strettamente necessari (il sistema di gestione pacchetti di Gentoo, Python, Java e
Perl...) ed i sorgenti del kernel. In questo modo si è riusciti ad ottenere un sistema
Linux perfettamente funzionante in poco più di 100 megabyte di spazio, permettendo
un’agile distribuzione dello stesso.
Accanto a tale sistema è stata anche sviluppata una distribuzione Live, dotata
di un kernel più generalista ed eseguibile direttamente da penna USB o da CD, col
compito di facilitare il testing su varie macchine del codice scritto facendo uso della
BaseLib2 e di RTAI. Tale distribuzione è stata di recente fornita all’Università degli
Studi di Napoli “Federico II”.
Infine è stata posta particolare attenzione alla raccolta di documentazione sulla
stabilizzazione verticale dal punto di vista software, documentazione che prima dell’i-
nizio della scrittura di questa Tesi era praticamente nulla o sparsa su vari testi: si è
cercato di inserire quante più informazioni possibili all’interno di questo documento,
indicando eventualmente i testi dove si possono approfondire i concetti esposti.
72
CAP. 4 Risultati ottenuti
Contributi da questo lavoro di Tesi sono stati usati per la preparazione dell’articolo
“Linux RTAI Real Time Framework for Fusion Devices”, approvato per la conferenza
SOFT 2008 ed attualmente in fase di correzione.
73
Capitolo 5
Conclusioni e sviluppi futuri
Questa Tesi, interamente svolta presso gli uffici del JET, a Culham (Oxford), è stata
finanziata dalla borsa di studio fornita dal Programma “Leonardo da Vinci”, della
durata di sei mesi.
Durante questo periodo di tempo si è avuto modo di approfondire il problema della
stabilizzazione verticale del plasma, problema che resta, ad oggi, ancora un campo
aperto: numerose proposte e tentativi sono stati effettuati, ma nessuno di questi si è
rivelato essere la soluzione definitiva, cosa che, specie in vista del futuro ITER (in cui
una perdita di stabilità verticale potrebbe causare danni irreversibili alla macchina),
sta portando ad un sempre maggiore interessamento di fisici ed ingegneri.
Assieme alla ricerca di un metodo per garantire misure accurate e ampi margini
di stabilità, di pari passo procede la ricerca nel campo software, al fine di garantire
tempi di calcolo del controllo sempre minori, fondamentali data la velocità del modo
verticale instabile.
In questa tesi si è cercato di illustrare il framework progettato al JET per la
74
CAP. 5 Conclusioni e sviluppi futuri
stabilizzazione verticale del plasma, soprattutto per quanto riguarda il porting dalla
piattaforma commerciale precedentemente utilizzata (VxWorks) al sistema operativo
libero ed open source Linux, modificato con le patch RTAI al fine di garantirne le
prestazioni hard-realtime.
Inoltre si è prestata particolare attenzione al fornire una documentazione semplice
e ad ampio spettro del problema della stabilizzazione verticale, indicando (dove ne-
cessario) i testi su cui approfondire i concetti esposti, e cercando di coprire tutte le
problematiche principali, sottolineando in particolare quelle ancora aperte e merite-
voli di ulteriore approfondimento.
Il framework sviluppato, grazie alla sua semplicità d’uso, si propone come otti-
ma base di partenza per la conversione alla struttura a GAM dei numerosi controlli
presenti al JET. In particolare l’unificazione del controllore di posizione verticale e di
forma potrebbe garantire un generale miglioramento delle prestazioni evitando situa-
zioni di conflitto tra i due sistemi. Questa idea è in fase di studio e dovrebbe essere
approfondita nei prossimi anni.
Altro elemento da migliorare sarà quello relativo all’interfaccia con l’utente del
sistema: per la gestione da sala di controllo si sta prevedendo un sistema basato su
pagine web, mentre per un accesso più a basso livello ci si propone di migliorare il
progetto della RTAIConsole, attualmente in fase embrionale, aggiungendo la possibi-
lità di interagire direttamente con le classi fornite dalla BaseLib2.
Da un punto di vista controllistico, sono iniziati degli studi sulle possibilità di mi-
75
CAP. 5 Conclusioni e sviluppi futuri
gliorare il ciclo di controllo, soprattutto per quanto riguarda il problema della quan-
tizzazione di FRFA. In particolare potrebbe essere possibile ottenere buoni risultati
usando tecniche di controllo a tempo minimo, parzialmente a catena aperta.
Le possibilità di sviluppo future, sia per quanto concerne il software, sia riguardo il
miglioramento del controllore, saranno studiate ed implementate nel corso dei prossimi
sei mesi, durante i quali si tornerà a Culham per proseguire il lavoro al JET.
76
Appendices
77
Appendice A
La BaseLib2
In questa appendice vengono riassunti i principi di funzionamento
della BaseLib2, la libreria che si occupa di fornire i servizi di base
ai software sviluppati al JET, e le motivazioni che hanno spinto a
svilupparla.
A.1 Introduzione
Gestire l’infrastruttura software di un sistema complesso come un Tokamak (ed a mag-
gior ragione del Tokamak più grande attualmente esistente) risulta essere un compito
estremamente gravoso: qualsiasi possibile modifica, per quanto piccola, all’impianto
deve ovviamente essere failsafe 1 e garantire il minor tempo di non funzionamento pos-
sibile, al fine di evitare il rallentamento della sperimentazione. A questo, inoltre, si
aggiungono tutti i problemi derivanti da eventuali cambi di architettura hardware, che
obbligano ad una completa revisione del software per adattarlo alle nuove specifiche,
ed il desiderio di limitare al minimo la riscrittura di algoritmi, al fine di minimizzare
i tempi di programmazione e il numero di bug.
1
Per failsafe generalmente si intende un sistema che garantisca, in caso di errore, di causare danni
minimi. In questo caso specifico ci si riferisce alla necessità di avere software che in caso di problemi
non causi un crash di sistema.
78
APP. A La BaseLib2 A.2 Divisione in livelli
La BaseLib2 nasce proprio al fine di limitare questi problemi.
La BaseLib2 è una libreria scritta interamente in C++ (fatta eccezione per alcune
parti in assembler), il cui compito è quello di fornire un’infrastruttura software su
cui costruire programmi nel modo il più semplice e robusto possibile, favorendo la
riutilizzazione del codice attraverso un uso intenso della programmazione orientata
agli oggetti. Inoltre è stata costruita in un modo estremamente gerarchizzato, con
un’astrazione progressiva dal sistema operativo sottostante, in modo da permettere
un facile porting su qualsiasi piattaforma (figura A.1).
A.2 Divisione in livelli
Come precedentemente sottolineato, uno degli obiettivi della BaseLib2 è quello di per-
mettere una facile portabilità del software scritto con essa da un’architettura all’altra,
azzerando il numero di righe di codice da modificare. A tal fine la libreria stessa deve
essere agevolmente compilabile su più sistemi operativi. Essa è stata quindi struttu-
rata in sette livelli (la cui struttura è riportata in figura A.1), dei quali solo il primo
(Level0 ) contiene codice fortemente dipendente dal sistema operativo, e che quindi
necessita di essere riscritto ogni volta che si desideri effettuare il porting della libreria.
Ogni livello è stato pensato per utilizzare solamente i livelli a lui sottostanti. In
questo modo il processo di compilazione risulta essere estremamente semplificato e
veloce (è sufficiente compilare uno dopo l’altro i vari livelli, e quindi effettuare il
linking della libreria completa). Inoltre ciò ha permesso anche una semplificazione
della prima fase di debug della BaseLib2 : una volta testato e funzionante un livello,
79
APP. A La BaseLib2 A.2 Divisione in livelli
O.S.
(Linux,RTAI,Win32..)
LEVEL 0
(+ LEVEL RTAI C++)
(console, mutexes, atomic ops, streams...)
LEVEL 1
(named objects, garbage collection...)
LEVEL 2
(files, advanced streams...)
LEVEL 3
(CDB, Lexical Analyzer...)
LEVEL 4
(HTTP server...)
LEVEL 5
(GAMs & DDB, Message Handling, State Machine)
LEVEL 6
(Matrix operations, filters...)
Figura A.1: Divisione in livelli della BaseLib2.
tutti i bug incontrati in un qualsiasi livello seguente sarebbero stati da imputare
solamente a quest’ultimo2 .
Ai sette livelli di cui sopra ne va aggiunto un ottavo nella versione delle BaseLib2
per Linux-RTAI: ciò è giustificato dalla maggiore complessità del porting sotto tale
architettura, in quanto la libreria deve funzionare in kernelspace, e di conseguenza de-

2
Si tratta, ovviamente, di una semplificazione: è possibile trovare bug non immediatamente evi-
denti, ma che si palesavano con l’uso delle classi fornite da un livello da parte dei livelli seguenti.
Tuttavia risulta evidente come la probabilità di un tale errore sia decisamente più bassa rispetto a
quella che si avrebbe mantenendo la libreria senza livelli.
80
APP. A La BaseLib2 A.3 Le classi fondamentali
ve “portarsi dietro” tutto il bagaglio di cast dinamico delle classi e delle funzionalità
proprie del C++3 .
A.3 Le classi fondamentali
Capire il funzionamento di una libreria complessa come la BaseLib2 richiede uno
sforzo notevole: i numerosi concetti introdotti arrivano, in alcuni casi, a modificare
totalmente lo stile di programmazione “classico” del C++. Tuttavia, una volta acqui-
sita familiarità con i suoi meccanismi, ci si rende facilmente conto della mole di lavoro
che la libreria permette di risparmiare. Quello che ci si propone di fare in questa
sezione è fornire una visione d’insieme sulle “colonne portanti” di questa monolitica
libreria software.
A.3.1 Un antenato comune: la classe Object
Una parte (attorno al 20 %) degli oggetti della BaseLib2 ereditano in qualche modo
dalla classe Object, implementata nel secondo livello (Level1 ). Il compito assolto da
tale classe (oltre quello di garantire un padre comune a vari oggetti, al fine di poter
effettuare cast dinamici) è fondamentalmente quello di permettere una forma di in-
trospezione alle classi, dove per introspezione si intende la capacità di una classe di
“conoscere se stessa”. In altri termini, ogni classe derivante da Object è in grado di
conoscere il proprio nome, la versione, il numero di istanze allocate dinamicamente

3
Il sistema di compilazione dei moduli del kernel Linux, infatti, prevede l’uso solamente del C
classico. A tutti gli effetti l’uso del C++ è una grossa forzatura al sistema, forzatura resa necessaria
e desiderabile data la potenza della programmazione orientata agli oggetti e della BaseLib2 stessa.
Il tempo speso a far funzionare il C++ in kernelspace è stato ampiamente ripagato dal tempo
guadagnato nel poter riutilizzare seduta stante tutti i software già scritti.
81
(i.e. usando gli operatori new e delete) e altre caratteristiche interne.
L’introspezione, assieme ad un sistema di database interno per le classi ed i re-
lativi nomi, è uno dei maggiori punti di forza della BaseLib2 in quanto permette la
creazione di oggetti per nome. È possibile, cioè, creare a runtime un nuovo oggetto
“indirettamente”, semplicemente indicando il nome della relativa classe.
A.3.2 Garbage Collector
Un evidente problema legato alla creazione di oggetti a runtime è quello della lo-
ro eliminazione: se l’usufruitore dell’oggetto dimentica, all’interno del suo codice,
di distruggerlo quando esso non è più necessario, vi è la possibilità, a lungo anda-
re, di generare dei problemi di memoria man mano che essa si riempie di oggetti
“spazzatura”.
Uno dei principi fondamentali della BaseLib2 è quello di limitare gli “errori uma-
ni”, cercando di prevedere il più possibile le situazioni di errore, e risolvendole a monte.
A tal fine è stato implementato un sistema di garbage collection (concetto preso in
prestito da Java) che si preoccupa al posto dell’utente di cancellare gli oggetti non
più usati.
Per garantire questa funzionalità ad un oggetto è sufficiente farlo derivare da
GarbageCollectable. Questa classe non fa altro che aggiungere un sistema che con-
teggia i riferimenti all’oggetto stesso esistenti. In questo modo, qualora l’eliminazione
di un riferimento porti tale conteggio a zero, la classe provvederà ad “autodistrugger-
si”, liberando memoria. Si noti come tale sistema sia estremamente efficace dal punto
di vista delle prestazioni: l’unico codice aggiunto al proprio oggetto è in pratica quello
82
necessario ad incrementare o decrementare il contatore, ed influenza per giunta solo
la costruzione, distruzione e copia degli oggetti.
A.3.3 Named Objects
Una specializzazione della classe Object è quella dei Named Object, concetto preso
in prestito dal linguaggio Smalltalk. Un Named Object è un oggetto che garantisce
ad ogni sua istanza la proprietà di avere un “nome proprio”, tramite il quale possa
essere identificata in modo univoco. Questo meccanismo è fondamentale per creare
riferimenti ad istanze specifiche di un oggetto a runtime: solo grazie ad esso è possibile
gestire il complesso sistema di messaggistica tra oggetti implementato nella BaseLib2,
di cui si tratterà in seguito nel capitolo apposito.
Per comodità dell’utente finale, le proprietà di GarbageCollectable e di Named
Object sono state racchiuse in un’unica classe, GCNamedObject: qualunque oggetto
erediti da essa si vedrà garantite tutte le caratteristiche di cui sopra (si confronti la
prima parte del diagramma di collaborazione di figura A.3).
A.3.4 GCReference e GCReferenceContainer
Per finire la panoramica sugli oggetti fondamentali che compongono la BaseLib2 ri-
mangono da citare gli oggetti di tipo GCReference e GCReferenceContainer, rappre-
sentanti, rispettivamente, il riferimento ad un qualsiasi oggetto di tipo GCNamedObject,
ed un contenitore di riferimenti.
Una qualsiasi classe che erediti da GCReferenceContainer acquista automati-
83
camente la capacità di contenere riferimenti ad altri oggetti: grazie a tale siste-
ma è possibile implementare in maniera estremamente semplice relazioni tra oggetti
rappresentabili come strutture ad albero.
Si consideri, ad esempio, il caso di un server web: immaginando di avere due ogget-
ti, Server e WebPage, rappresentanti rispettivamente il server stesso ed una singola pa-
gina, trasformando in contenitore i due oggetti facendoli ereditare da GCReferenceContainer,
sarebbe possibile aggiungere e togliere pagine dinamicamente semplicemente aggiun-
gendo (i.e. “creando per nome”) oggetti di tipo WebPage e inserendoli nel contenitore
Server per pagine di primo livello, o in un’altra WebPage per creare collegamenti tra
pagine (figura A.2)4 .
SERVER
WEBPAGE WEBPAGE WEBPAGE
WEBPAGE WEBPAGE WEBPAGE
Figura A.2: Esempio di utilizzo delle classi GCReference e GCReferenceContainer

per implementare un server web.
Una volta generata questa struttura, l’oggetto Server non deve fare altro che
spostarsi tra le varie pagine, secondo le richieste effettuate dal browser, “navigando”
nella propria struttura ad albero, il tutto con pochissime righe di codice.
A.3.5 Vista d’insieme
Il grafico di collaborazione tra i vari oggetti citati sinora è riportato in figura A.3, con
evidenziati gli oggetti più importanti.
4
Un sistema simile è effettivamente utilizzato dal server web fornito dalla BaseLib2.
84
objectPointer
Object GarbageCollectable GCReference
APP. A La BaseLib2
GCNamedObject LinkedListable
gc
llhroot
next
GCReferenceContainer GCRCItem
list
LinkedListHolder GCRCILink GCRCIBasic
Figura A.3: Schema UML degli oggetti di base della BaseLib2. Le frecce con trato continuo indicano ereditarietà, quelle
tratteggiate l’utilizzo (in corsivo è specificato il nome della variabile usata). I rettangoli con spessore doppio indicano le
classi più importanti.
A.3 Le classi fondamentali
85
A.3.6 Il CDB - Configuration DataBase
Come visto sinora, sfruttando i potenti meccanismi di creazione per nome, garbage
collection e contenimento di riferimenti della BaseLib2, risulta semplice modificare
profondamente la struttura di un’applicazione a runtime. Il CDB è un’esasperazione
di questa idea.
Un CDB è sostanzialmente l’unione di un database interno alla BaseLib2 con un
codice di programmazione minimale che permetta di descrivere oggetti da creare e le
relative proprietà. Un esempio di tale sintassi è mostrato nel listato A.1. Si osservi
come la sintassi usata sia di tipo “C-like”, dove i parametri di ogni elemento sono
racchiusi tra coppie di parentesi graffe.
In particolare si notino, all’interno del codice, le varie occorrenze della parola chia-
ve Class, che indica al CDB il nome della classe di cui si desidera creare un’istanza, e
la configurazione della classe stessa, che avviene all’interno delle due parentesi graffe
principali. Nel caso in esame la classe StateMachine (rappresentante, come dice il
nome stesso, una macchina a stati) è programmata in modo da prevedere più stati
(StateMachineState), ciascuno dei quali può a sua volta essere configurato per pre-
vedere più eventi (StateMachineEvent).
Il CDB può essere generato a partire da un qualsiasi oggetto utilizzabile come
stream, sia esso una stringa in memoria, un file o i dati provenienti da un socket.
86
Listato A.1: Esempio di file di configurazione (da TestStateMachine.cpp).

1 Class = StateMachine
2 VerboseLevel = 2
3 +IDLE={
4 Class = StateMachineState
5 +TEST={
6 Class = StateMachineEvent
7 Code = 1
8 NextState = ACTIVE
9 +NOTIFY={
10 Class = MessageEnvelope
11 Destination = \"SENDERS.XOBJECT\"
12 +MESSAGE= {
13 Class = Message
14 Code = 1
15 }
16 }
17 }
18 }
19 +ACTIVE={
20 Class = StateMachineState
21 +RESET={
22 Class = StateMachineEvent
23 Code = 1
24 NextState = IDLE
25 +NOTIFY={
26 Class = MessageDeliveryRequest
27 Destinations = \"SENDERS.YOBJECT,SENDERS.ZOBJECT\"
28 Message= {
29 Class = Message
30 Code = 1
31 }
32 }
33 }
34 }
87
APP. A La BaseLib2 A.4 Comunicazione tra oggetti
A.4 Comunicazione tra oggetti
Uno dei principi portanti della programmazione orientata agli oggetti è la possibilità di
interazione di più oggetti tra loro. Nel C++ classico questo avviene tramite l’utilizzo
di metodi e proprietà esposti da un oggetto.
La BaseLib2 stravolge questo concetto introducendo i messaggi, mutuati anch’es-
si da Smalltalk. Tale tecnica consiste nel permettere agli oggetti di comunicare tra di
loro inviandosi informazioni5 , delegando il compito di recapitare il messaggio corretto
alla corretta destinazione ad un thread di gestione indipendente (un esempio di fun-
zionamento è raffigurato in figura A.4).
ProcessMessage
B
Message
Handler
MessageQueue
Thread
SendMessage ==Message 1== HandleMessage
A ==Message 2==
...
==Message N==
Figura A.4: Schema di funzionamento della gestione dei messaggi nelle BaseLib2.
Affinché un oggetto possa far uso di questo meccanismo, esso deve ereditare dalla
classe MessageHandler e ridefinire il metodo virtuale ProcessMessage. Tale me-
todo prende come parametro un oggetto di tipo GCRTemplate<MessageEnvelope>6
che rappresenta la “busta da lettere” contenente il messaggio spedito all’oggetto.
Un MessageEnvelope possiede come parametri due stringhe che indicano il nome di

5
Dove, per “informazioni” si intende qualsiasi tipo di variabile, struttura o persino classe.
6
GCRTemplate è un template che fornisce alla classe indicata le proprietà di garbage collection.
Ogni messaggio deve necessariamente avere tale caratteristica in quanto, altrimenti, si correrebbe il
rischio di riempire la memoria di “oggetti messaggio” non più usati.
88
APP. A La BaseLib2 A.4 Comunicazione tra oggetti
mittente e destinatario, e il metodo GetMessage che restituisce un oggetto di tipo
Message, ovvero il messaggio vero e proprio.
Per inviare un messaggio, invece, è sufficiente istanziare un oggetto di tipo Message
ed inserirlo in una MessageEnvelope usando il metodo PrepareMessageEnvelope e
indicando la destinazione. Invocando quindi la funzione MessageHandler::SendMessage()
il messaggio verrà inviato.
Si noti come il meccanismo di scambio messaggi permetta di creare strutture di og-
getti estremamente complesse, laddove l’uso di contenitori di riferimenti può garantire
solo un metodo di comunicazione padre-figlio: il sistema delle macchine a stati (og-
getto StateMachine), ad esempio, fondamentale per MARTe, usa abbondantemente
questo meccanismo per segnalare transizioni di stato ed errori.
89
Appendice B
Distribuzione Linux usata al JET

In questa appendice viene illustrato a grandi linee il processo che ha
portato alla creazione della distribuzione Linux Gentoo-based (an-
che nella sua incarnazione Live) che è poi stata usata come piat-
taforma di testing e development al JET. Vengono riportati solo i
passaggi chiave, limitando il numero di comandi Linux al minimo
indispensabile e rinviando, per una guida più completa e dettagliata,
ai siti web segnalati nell’introduzione.
B.1 Introduzione
La scelta della distribuzione Linux da usare per far girare il sistema di controllo del
JET è stata piuttosto importante. Tra le varie distribuzioni candidate (tra cui la
celebre Fedora Core), si è infine scelto di usare Gentoo a causa non solo della sua
personalizzabilità e stabilità, ma anche dell’ottimo supporto tecnico fornito dalla co-
munità. Inoltre il fatto di poter preparare il sistema partendo quasi da zero (o “da
stage 1” nel gergo di Gentoo) ha permesso di installare solo lo stretto necessario,
ottenendo un sistema snello e veloce, capace di mantenere tutte le sue funzionalità in
meno di mezzo gigabyte (e rinunciando al compilatore ed al sistema di aggiornamento
pacchetti è stato anche possibile scendere sotto i 100 megabyte!).
90
APP. B Distribuzione Linux usata al JET B.2 Installazione di Gentoo
Questa appendice è una versione ridotta e commentata, contenente solo i punti
salienti e le difficoltà incontrate, delle guide pubblicate sul wiki mantenuto dal gruppo
di controllo del plasma agli indirizzi:
http://fusion-rt.sourceforge.net/wiki/Installing_Gentoo_from_Stage1
http://fusion-rt.sourceforge.net/wiki/Creating_a_Gentoo_LiveCD/LiveUSB
B.2 Installazione di Gentoo

Avvio dal LiveCD
Dopo aver scaricato e masterizzato il LiveCD di Gentoo 2007.1, si è proceduto a
riavviare il sistema effettuando il boot da CD. Il LiveCD è progettato per effettuare il
boot della macchina lasciando l’utente in un ambiente “temporaneo” da cui effettuare
tutte le operazioni necessarie all’installazione del sistema.
Per la sua natura “tecnica”, Gentoo non prevede un installer grafico, lasciando
all’utente l’obbligo di compiere tutti i passi normalmente compiuti da quest’ultimo,
quali, as esempio, il partizionamento dell’hard disk o la configurazione di base del
sistema.
Partizionamento
Il partizionamento del disco per l’installazione del sistema è stato effettuato, usando
il comando fdisk, cercando di limitare il numero di partizioni presenti al minimo. In
particolare si è provveduto a creare una partizione per il sistema di base di circa 2 GB
(abbastanza grande da consentire “spazio di manovra”, ma non eccessiva considerato
il fatto di non dover installare un ambiente grafico) e una partizione di swap della
91
stessa dimensione, lasciando tutto il resto a disposizione per file temporanei e di
sviluppo.
Il filesystem usato è l’ext3, sia per la sua diffusione e provata stabilità, sia per
evitare qualsiasi forma di problema con i vari bootloader presenti.
Installazione del sistema di base
La procedura di installazione di Gentoo partendo da “Stage 1” risulta essere piuttosto
lunga e laboriosa, sebbene favorita dall’uso di numerosi script costruiti ad hoc dal
team di sviluppo della distribuzione. La difficoltà del processo risulta essere ancora
maggiore a causa del fatto che, da qualche anno, tale forma di installazione non è
più supportata nella documentazione ufficiale di Gentoo. Di conseguenza è stato
necessario procedere passo-passo, cercando nella rete informazioni sui passi più oscuri
e/o mancanti.
Dopo aver partizionato i dischi e montato i vari filesystem all’interno dell’ambiente
“virtuale” fornito dal CD di installazione, si è provveduto a scaricare e decomprimere
il file contenente lo stage 1 da uno dei numerosi mirror di Gentoo presenti in rete. A
questo punto è stato effettuato il processo di bootstrap di Gentoo, che sostanzialmen-
te consiste nella creazione dell’ambiente di base necessario al buon funzionamento
della distribuzione (i.e. compilazione di GCC, perl e python, creazione dei file di
configurazione di base...).
Completato il (lungo) processo di bootstrap, si è passati alla configurazione del
sistema e ad aggiornare i file di base con un emerge --sync && emerge -uD world1 .
1
emerge è il comando che permette di lavorare con portage, il sistema di gestione pacchetti di
Gentoo, che automatizza il processo di scaricare dalla rete, compilare ed installare il software.
92
Compilazione del kernel
La parte più complessa del lavoro è stata, senza dubbio alcuno, quella di configurare
il kernel della macchina. L’idea di base è stata quella di costruire un sistema il più
possibile snello, sia per garantire la massima efficienza, sia per eliminare quanto più
possibile codice “inutile” dalla memoria, al fine di limitare possibili conflitti tra i
moduli del kernel, RTAI e i thread realtime.
A tal fine si è provveduto ad abilitare come elementi statici del kernel tutti e solo
i driver delle periferiche presenti effettivamente nella macchina, cosa che ha garantito
un insieme minimale di funzionalità e tempi di compilazione decisamente ridotti, ma
che è andata contro la portabilità del kernel stesso. Tuttavia si noti che, in effetti,
l’architettura finale su cui dovrà funzionare Linux-RTAI è ben determinata e non
soggetta a frequenti cambiamenti, cambiamenti che, in ogni caso, non richiedono molto
più del cambiare alcune opzioni nella configurazione del kernel, e una ricompilazione
dello stesso.
Oltre a queste operazioni è stata anche applicata la patch RTAI in modo da otte-
nere un kernel con le funzionalità realtime necessarie.
Completamento dell’installazione
Le ultime operazioni effettuate hanno riguardato l’installazione di un bootloader e la
sua configurazione. Si è inoltre proceduto ad installare alcuni software aggiuntivi per
facilitare le operazioni da riga di comando (come VIM, per garantire delle funzionalià
di editing minimali, CVS e i tool per gestire le partizioni di rete NFS).
93
APP. B Distribuzione Linux usata al JET B.3 Costruzione di un LiveCD/LiveUSB
B.3 Costruzione di un LiveCD/LiveUSB
Un’ulteriore operazione effettuata è stata quella di costruire una distribuzione Live2
a partire dall’installazione di Gentoo appena completata.
Si è scelto di effettuare tale procedimento in modo da ottenere un sistema opera-
tivo “portatile” con cui avviare la macchina in caso di problemi, facilitando di molto
le operazioni di primo avvio e di ripristino. Inoltre si è pensato di mantenere que-
sta soluzione in caso di espansioni future dell’accoppiata Linux/RTAI come sistema
operativo realtime “ufficiale” del JET: molte postazioni, infatti, richiedono software
funzionante in realtime pur non essendo “critiche” per il buon funzionamento della
macchina. Poter avviare tali macchine utilizzando un unico LiveCD uguale per tutti
è sembrato estremamente vantaggioso.
Riduzione dello spazio occupato
La prima operazione necessaria alla trasformazione dell’installazione di Gentoo in un
LiveCD/LiveUSB è quella di ridurre il più possibile lo spazio occupato, limitato dalla
dimensione massima del CD o della penna USB usata.
A tal fine si è provveduto a rimuovere tutte le funzionalità non necessarie, quali il
sistema di aggiornamento pacchetti e relative dipendenze. Inoltre sono stati rimossi
tutti i file di documentazione e si è provveduto a lanciare un make clean per ripulire
le directory contenenti le sorgenti del kernel e di RTAI.
Ulteriore spazio è stato guadagnato utilizzando il filesystem SquashFS, estrema-
mente compresso. Sfortunatamente il kernel Vanilla non prevede quest’opzione, ed è

2
Per “distribuzione Live” si intende una distribuzione Linux capace di avviarsi direttamente da
CD o da penna USB senza richiedere l’installazione su Hard Disk.
94
APP. B Distribuzione Linux usata al JET B.4 Avvio del sistema da rete
stato quindi necessario applicare un’ulteriore patch oltre a quella di RTAI.
Creazione del LiveCD/LiveUSB
Una volta costruita e compressa con SquashFS la directory contenente la “copia ri-
dotta” di Gentoo, si è proceduto a creare l’immagine ISO del LiveCD. La procedura,
piuttosto semplice, consiste nel fornire a mkisofs, oltre ai fila da masterizzare sul
CD, anche l’immagine di un bootloader. Fortunatamente grub prevede già questa
possibilità e fornisce un’immagine per CD pronta all’uso.
Viceversa, nel caso della LiveUSB, la procedura è stata leggermente più semplice:
poiché la penna USB viene vista da Linux come un vero e proprio hard disk, è stato
sufficiente installare su di essa grub. L’unico problema è stato causato dalla lentezza
con cui il kernel Linux riconosce le periferiche USB, lentezza che ha portato al dover
inserire artificialmente delle pause all’interno degli script di boot della LiveUSB per
dare tempo al kernel di caricare i driver necessari.
B.4 Avvio del sistema da rete
L’ultimo passo nella preparazione del sistema è stato quello di effettuare il boot della
macchina da remoto. In questo modo è stato possibile salvare filesystem e immagine
del kernel in un computer esterno alla sala macchine, col vantaggio di essere più facil-
mente accessibile e modificabile (cosa fondamentale in fase di sviluppo), e soprattutto
soggetto a periodici backup.
La tecnologia che ha permesso ciò è detta PXE (Preboot eXecution Environment).
95
APP. B Distribuzione Linux usata al JET B.4 Avvio del sistema da rete
PXE DHCP Request
Boot server IP
DHCP
Server
Kernel request (TFTP)
KERNEL IMAGE
PXE Client
Boot
Server
Figura B.1: Principio di funzionamento dell’avvio via PXE.
Tale sistema, fortunatamente già incorporato nella scheda di rete presente nella mac-
china, è illustrato nella figura B.1: PXE crea un ambiente di boot che, lanciando
richieste DHCP, ricerca un boot server da cui scaricare, via TFTP3 , l’immagine del
kernel da avviare, proseguendo poi nel normale processo di boot di Linux.
L’implementazione di tale sistema ha richiesto uno sforzo minimale: è stato suffi-
ciente far aggiungere alcune righe al file di configurazione del server DHCP affinché
“indirizzasse” la macchina nella sala di controllo verso il corretto server di boot, ed
indicare nei parametri del kernel dove trovare la partizione NFS da montare come
root.
3
TFTP è una versione “leggera” del classico protocollo FTP.
96
Appendice C
Specifiche hardware
In questa appendice vengono brevemente riassunte le specifiche tec-

niche dell’hardware attualmente usato al JET per la stabilizzazione
verticale del plasma.
C.1 Introduzione
La scelta della piattaforma hardware su cui far girare il controllore per la stabilizza-
zione verticale è, ovviamente, una delle più importanti e delicate. Ottenere un buon
compromesso tra costi, scalabilità, robustezza e velocità non è cosa semplice.
Secondo le specifiche, il nuovo controllore richiede fino a 50 segnali in ingresso
e un ritardo massimo nel loop di controllo di 50 µs, con la speranza di ridurlo a
soli 10 µs. Tale tempo di ritardo è dovuto fondamentalmente a due fattori, ovvero
il tempo di calcolo dell’algoritmo vero e proprio, e i tempi di acquisizione segnali e
attraversamento dei circuiti. La scelta della piattaforma hardware è stata fatta in
modo da minimizzare proprio questa seconda tipologia di ritardi, in quanto la prima
è decisamente meno limitante data la potenza di calcolo dei processori moderni e la
possibilità di costruire sistemi multiprocessore. A tal fine si è scelto di far uso dello
97
APP. C Specifiche hardware C.2 Lo standard ATCA
standard ATCA.
C.2 Lo standard ATCA
Lo standard ATCA (Advanced Telecommunications Computing Architecture) è uno
standard sviluppato dal PICMG (PCI Industrial Computer Manufacturers Group),
un consorzio internazionale composto da più di 400 società. Scopo dello standard è
quello di definire i requisiti di base per la strumentazione da telecomunicazioni futu-
ra. I principali punti di forza di questo standard sono la velocità di comunicazione
tra gli elementi del crate (figura C.1), e il fatto di essere pensato per garantire un
elevatissimo tempo di funzionamento, grazie ai sistemi di alimentazione ridondante
e alla possibilità di inserire nello stesso crate il doppio delle schede necessarie, in
modo che il sistema possa passare, in caso di malfunzionamenti, da un set all’altro
in maniera trasparente. Viene inoltre garantita la possibilità di collegare e scollega-
re schede “a caldo”, ovvero senza richiedere il preventivo spegnimento della macchina.
Lo standard ATCA definisce un crate di dimensioni ben precise (figure C.2 e C.3),
e una serie di interconnessioni, nel lato posteriore, seriali e con banda di un gigabit.
Il protocollo di comunicazione non è specificato a priori, e nel caso del JET si è scelto
di usare la tecnologia PCI Express.
C.3 Il controllore ATCA
Il controllore ATCA, il cui schema logico è riportato in figura C.4, è implementato su
una scheda madre ATX (assemblata in modo da raggiungere le dimensioni specificate
98
APP. C Specifiche hardware C.4 Le schede DGP
Figura C.1: Schema delle connessioni interne al crate secondo lo standard ATCA.
dallo standard) collegata al crate ATCA attraverso un connettore PCI Express x16,
ed usa un processore standard x86, nel caso del JET un Intel Quad Core.
La cosa più evidente della soluzione proposta è il bassissimo costo derivante dal-
l’utilizzo di architetture standard e di processori general-purpose.
C.4 Le schede DGP
Il crate ATCA permette l’inserimento di fino a 12 schede DGP (Digitizer-Generator-
Processor ), ciascuna delle quali comprende porte I/O digitali e analogiche, un con-
trollore FPGA (Field-Programmable Gate Array), una porta per clock esterno e due
link in fibra ottica Aurora da 2.5Gbit. In particolare questi collegamenti garantisco-
99
APP. C Specifiche hardware C.4 Le schede DGP
Figura C.3: Dimensioni del crate ATCA.

Figura C.2: Il crate ATCA.
Figura C.4: Schema logico del controllore ATCA.
no la possibilità agli FPGA di comunicare tra loro e addirittura di poter accedere
in ogni istante ai dati acquisiti da una qualsiasi altra scheda come fossero stati cat-
turati dalla stessa scheda dove l’unità risiede. Ciò permette un’esecuzione parallela
particolarmente adatta al processamento di segnali per sistemi MIMO.
Questa proprietà, insieme alla capacità degli FPGA di funzionare indipendente-
mente dalla scheda di controllo, garantisce la possibilità di elaborare segnali saltando
completamente il processore centrale: segue la possibilità di delegare buona parte dei
100
APP. C Specifiche hardware C.5 Prestazioni
compiti di filtraggio agli FPGA, scaricando di molto le responsabilità della CPU.
C.5 Prestazioni
Previsioni e test effettuati in laboratorio hanno mostrato le buone prestazioni di questa
architettura relativamente ai tempi di attraversamento.
In particolare, proprio ai fini di quanto richiesto dal JET, sono stati pensati due
scenari: il primo prevede il passaggio di segnali attraverso la scheda controllore, mentre
il secondo l’uso delle sole FPGA. I tempi calcolati sono risultati essere all’incirca pari,
rispettivamente, a 1.7µs e 0.7µs, indicando come effettivo collo di bottiglia del sistema
il canale PCI express. Si noti come l’accoppiata di una CPU veloce e dell’architettura
ATCA abbia buone possibilità di ridurre effettivamente il ritardo del loop di controllo
anche al di sotto dei 10µs.
101
Elenco delle figure
1.1 Diagramma della reazione di fusione nucleare. . . . . . . . . . . . . . 6
1.2 Rappresentazione di avvolgimenti e campi toroidale e poloidale. . . . 8
1.3 Interno della camera vuoto del JET. . . . . . . . . . . . . . . . . . . 11
1.4 Posizione delle bobine poloidali del JET. . . . . . . . . . . . . . . . . 12
1.5 Struttura meccanica di ITER. . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Caduta della corrente di plasma in dipendenza dalla distanza dall’asse
del toro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Misura della triangolarità di un plasma. . . . . . . . . . . . . . . . . . 17
2.3 Instabilità verticale del plasma. . . . . . . . . . . . . . . . . . . . . . 18
2.4 Esempio di Mirnov coil. . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Posizione su un ottante dei sensori di misura del campo magnetico. . 22
2.6 Pesi per i vari sensori magnetici, come da modifica dopo l’inserimento
del divertore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Schema generale dell’algoritmo per la stabilizzazione verticale del plasma. 25
2.8 Andamento ad isteresi di FRFA. . . . . . . . . . . . . . . . . . . . . . 29
2.9 Schema elettrico di FRFA. . . . . . . . . . . . . . . . . . . . . . . . . 30
2.10 Esempi di N-modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11 Struttura del plasma in H-mode. . . . . . . . . . . . . . . . . . . . . 35
102
ELENCO DELLE FIGURE ELENCO DELLE FIGURE
3.1 Passaggio da uno schema a blocchi alla struttura a GAM. . . . . . . . 42
3.2 Interazione tra MARTe, hardware e sistemi esterni. . . . . . . . . . . 50
3.3 Schema di funzionamento di Linux senza le patch di RTAI. . . . . . . 54
3.4 Comportamento del sistema modificato da RTAI. . . . . . . . . . . . 55
3.5 Confronto tra la latenza di thread in kernelspace ed in userspace (LXRT). 58
3.6 Architettura di FCOMM. . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7 Diagramma di flusso di call remote function. . . . . . . . . . . . . 63
3.8 Diagramma di flusso della componente userspace di FCOMM. . . . . 64
3.9 Screenshot della console RTAI in azione. . . . . . . . . . . . . . . . . 69
A.1 Divisione in livelli della BaseLib2. . . . . . . . . . . . . . . . . . . . . 80
A.2 Esempio di utilizzo delle classi GCReference e GCReferenceContainer
per implementare un server web. . . . . . . . . . . . . . . . . . . . . . 84
A.3 Schema gerarchico degli oggetti di base della BaseLib2. . . . . . . . . 85
A.4 Schema di funzionamento della gestione dei messaggi nelle BaseLib2. 88
B.1 Principio di funzionamento dell’avvio via PXE. . . . . . . . . . . . . 96
C.1 Schema delle connessioni interne al crate secondo lo standard ATCA. 99
C.2 Il crate ATCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.3 Dimensioni del crate ATCA. . . . . . . . . . . . . . . . . . . . . . . . 100
C.4 Schema logico del controllore ATCA. . . . . . . . . . . . . . . . . . . 100
103
Bibliografia
[1] J. Wesson, The Science of Jet, JET Publication (Culham, Oxford), 2000.
[2] J. Wesson, Tokamaks, Clarendon Press (Oxford), 2004.
[3] G. De Tommasi, F. Piccolo, A. Pironti, F. Sartori, A flexible software for real-time
control in nuclear fusion experiments, Elsevier, Control Engineering Practice 14
(2006), pp. 1387-1393.
[4] A. Pironti, M. Walker, Control of Tokamak Plasmas, IEEE Control System
Magazine, October 2005, pp. 24-29.
[5] A. Pironti, M. Walker, Fusion, Tokamaks, and Plasma Control, IEEE Control
System Magazine, October 2005, pp. 25-43.
[6] A. Beghi, A. Cenedese, Advances in Real-Time Plasma Boundary Reconstruction,
IEEE Control System Magazine, October 2005, pp. 44-64.
[7] M. Ariola, A. Pironti, Plasma Shape Control for the JET Tokamak, IEEE Control
System Magazine, October 2005, pp. 65-75.
[8] G. Ambrosino, R. Albanese, Magnetic Control of Plasma Current, Position, and
Shape in Tokamaks, IEEE Control System Magazine, October 2005, pp. 76-91.
104
BIBLIOGRAFIA BIBLIOGRAFIA
[9] A. Pironti, M. Walker, Control of Tokamak Plasmas Part II, IEEE Control System
Magazine, April 2006, pp. 30-34.
[10] M.L. Walker, D.A. Humphreys, D. Manzon, D. Moreau, M. Okabayashi, T.H.
Osborne, E. Schuster, Emerging Applications in Tokamak Plasma Control, IEEE
Control System Magazine, April 2006, pp. 35-63.
[11] F. Sartori, G. De Tommasi, F. Piccolo, The Joint European Torus, IEEE Control
System Magazine, April 2006, pp. 64-78.
[12] JO B. Lister, A. Portone, Y. Gribov, Plasma Control in ITER, IEEE Control
System Magazine, April 2006, pp. 79-91.
[13] V. D. Shafranov, L. E. Zakharov, Equilibrium of toroidal plasma with no circular
cross section, Sov. Phys. Tech, 1973, vol.18, pp. 151-156.
[14] A. Barbalace, A. Neto, F. Sartori, F. Piccolo, Realtime Application Interface
Characterization on x86 Platforms, (unsubmitted).
[15] A. Barbalace, Porting e valutazione delle prestazioni di un ambiente per applica-
zioni di controllo hard Real-Time da VxWorks a Linux-RTAI/Xenomai-RTnet su
architettura PowerPC, Thesis, 2007.
[16] F. Piccolo, JET Vertical Stabilization System: Modelling and Control, PHD
Thesis, 2007.
105

Architettura Basata Su Linux RTAI Per La Stabilizzazione Verticale Del Joint European Torus

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architettura Basata Su Linux RTAI Per La Stabilizzazione Verticale Del Joint European Torus

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITÀ DEGLI STUDI DI

CORSO DI LAUREA IN INGEGNERIA

ARCHITETTURA BASATA SU LINUX-RTAI

Prof. Luca Zaccarian Riccardo Vitelli

1 Cenni sulla fusione nucleare 5

1.1 La fusione nucleare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Formazione e riscaldamento del plasma . . . . . . . . . . . . . 8

1.3 Lo stato dell’arte: il JET . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 I principali circuiti e bobine poloidali . . . . . . . . . . . . . . 11

1.4 Le sﬁde future: ITER e DEMO . . . . . . . . . . . . . . . . . . . . . 13

2.2 Analisi del problema ﬁsico . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1 Stima del growth rate . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Le misure magnetiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Stima della posizione verticale del plasma . . . . . . . . . . . . . . . . 22

2.5 L’algoritmo di controllo . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.1 Controllo di velocità e di corrente . . . . . . . . . . . . . . . . 25

2.5.2 Controllo adattativo . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.3 Kick Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 Problematiche di controllo . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6.2 Accoppiamento tra controllo di posizione e forma . . . . . . . 31

2.6.3 Rumore degli alimentatori . . . . . . . . . . . . . . . . . . . . 31

2.6.4 Modi MHD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Scrittura e porting del sistema di controllo 37

3.2 Implementazione del controllo . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Struttura di VsGAM . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Il sistema RT del JET: MARTe . . . . . . . . . . . . . . . . . . . . . 49

3.4 Scelta del sistema operativo realtime . . . . . . . . . . . . . . . . . . 51

3.5.1 Funzionamento di RTAI . . . . . . . . . . . . . . . . . . . . . 53

3.5.2 RTAI ed i sistemi multicore . . . . . . . . . . . . . . . . . . . 55

3.5.3 Userspace o Kernelspace? . . . . . . . . . . . . . . . . . . . . 56

3.6.1 Analisi del funzionamento . . . . . . . . . . . . . . . . . . . . 59

3.6.2 Funzioni aggiuntive . . . . . . . . . . . . . . . . . . . . . . . . 65

3.6.3 Problematiche e soluzioni . . . . . . . . . . . . . . . . . . . . 65

5 Conclusioni e sviluppi futuri 74

A.2 Divisione in livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.3 Le classi fondamentali . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A.3.1 Un antenato comune: la classe Object . . . . . . . . . . . . . 81

A.3.2 Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . 82

A.3.3 Named Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.3.4 GCReference e GCReferenceContainer . . . . . . . . . . . . . 83

A.3.5 Vista d’insieme . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.3.6 Il CDB - Conﬁguration DataBase . . . . . . . . . . . . . . . . 86

A.4 Comunicazione tra oggetti . . . . . . . . . . . . . . . . . . . . . . . . 88

B Distribuzione Linux usata al JET 90

B.2 Installazione di Gentoo . . . . . . . . . . . . . . . . . . . . . . . . . . 91

B.3 Costruzione di un LiveCD/LiveUSB . . . . . . . . . . . . . . . . . . . 94

B.4 Avvio del sistema da rete . . . . . . . . . . . . . . . . . . . . . . . . . 95

C.2 Lo standard ATCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C.3 Il controllore ATCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C.4 Le schede DGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

C.5 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Elenco delle ﬁgure 102

possibile, il dott. Sartori, mio correlatore e guida durante l’esperienza al JET, il

dott. Piccolo, “capouﬃcio” e uomo di grande spessore, l’ing. Neto (dall’interminabile

pazienza e capacità di spiegarsi rara), la dott.ssa Zedda, e in generale tutta la “Little

di lavoro rilassato ma allo stesso tempo estremamente professionale.

crescente domanda di energia da parte della popolazione mondiale, soprattutto nei

paesi in via di sviluppo, obbligherà l’umanità ad accelerare sempre più la ricerca in

di energia rinnovabile, quali fotovoltaico o idrico, non hanno la necessaria capacità

di produzione di energia, e la ﬁssione nucleare, per quanto promettente dal punto di

dimezzamento, sia in quanto si trova a doversi scontrare con il “muro di gomma”

dell’opinione pubblica, rimasta scottata da gravi incidenti quale quello di Černobyl’ o

di Three Mile Island.