Sei sulla pagina 1di 111

UNIVERSITÀ DEGLI STUDI DI

ROMA
TOR VERGATA
FACOLTÀ 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 velocità 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 più 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 più difficile, e gli altri ragazzi del gruppo.

Infine voglio ringraziare il prof. Luca Zaccarian, senza il quale questa seconda

fantastica opportunità 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 capacità 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 è senza dubbio alcuno la più grande sfida che il genere umano

dovrà affrontare nel corso del secolo che stiamo vivendo. Il progressivo esaurirsi dei

combustibili fossili e la necessità di trovare sistemi per produrre energia quanto più

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, obbligherà l’umanità ad accelerare sempre più 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 capacità

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

vista della potenza erogata, non può 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 Č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 è 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 metà degli anni ’80 è stato costruito,

grazie ad una collaborazione tra 25 stati europei, il JET (Joint European Torus), il

più 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 è scelto di dare al plasma una forma non più circolare come in altri

Tokamak, ma allungata verticalmente, a seguire il più possibile la forma della camera.

Questo ha causato, tuttavia, una perdita della naturale stabilità verticale posseduta

dai plasmi circolari, portando alla necessità 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 è 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 verrà affrontata un’introduzione generale alle problematiche relative

alla fusione ed al confinamento del plasma, pur se senza nessuna pretesa di comple-

tezza data la complessità dell’argomento; nel capitolo seguente si analizzerà 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 è 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 è 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 più 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

È 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 metà del ventesimo secolo da un gruppo di scienziati

(tra i quali una figura di spicco è 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, è 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 quantità paragonabili di energia

in modo più pulito.

In questo modo è iniziata la ricerca nel campo della fusione.

Le reazioni di fusione nucleare avvengono di continuo nelle stelle, permettendo la

produzione dell’enorme quantità di energia da esse irradiata. In questo tipo di rea-

zione i nuclei di elementi leggeri si fondono per formare un nucleo più pesante, la cui

massa è 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 difficoltà di realizzazione e controllo dei processi di reazione nucleare è 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 ciò è necessario lavorare

in regimi di altissima temperatura e/o pressione. In particolare, nel caso della fusione

nucleare in laboratorio è 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 è un gas ionizzato la cui carica complessiva, a causa della possente forza

elettrostatica tra i due elementi costitutivi, resta generalmente neutra. Ciò nonostan-

te, grazie allo scorrimento relativo tra ioni ed elettroni, il plasma è un buon conduttore

di corrente. Tale proprietà è decisamente importante: proprio grazie alla possibilità

di generare una corrente di plasma è 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, è definito confinamento ma-

gnetico.

1.2 Il Tokamak

Tra le varie strutture proposte per il confinamento magnetico del plasma, quella più

diffusa è 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 semplicità, che per la sua efficacia. Un Tokamak è generalmente

composto da una camera da vuoto a forma di toro contornata da vari avvolgimenti


1
Da notare che nelle stelle le temperature necessarie affinché avvengano reazioni di fusione (circa
20 milioni di gradi) sono molto più basse rispetto a quelle richieste in laboratorio: infatti, pur essendo
la probabilità che due atomi si fondano direttamente proporzionale alla temperatura, in un corpo
celeste l’elevata gravità e conseguente pressione compensa tale minore probabilità.

7
CAP. 1 Cenni sulla fusione nucleare 1.2 Il Tokamak

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 è 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 perché esso si trasformi in plasma non è,

ovviamente, un’impresa semplice, tanto che è necessario adottare più 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 riferirà, salvo diversamente specificato, esclusivamente ai campi sul piano poloidale (generati da
avvolgimenti posti su quello toroidale, indicati come “poloidal field coils” in figura).

8
CAP. 1 Cenni sulla fusione nucleare 1.2 Il Tokamak

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 è decisa-

mente insufficiente perché possano avvenire reazioni di fusione nucleare. Tale limite

è legato al fatto che all’aumentare della temperatura la resistività 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, è quello di creare le condizioni af-

finché il plasma possa autoalimentarsi: perché ciò 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 purché vi sia presenza di combustibile nella

camera da vuoto.

1.3 Lo stato dell’arte: il JET

Il JET è 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 più

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 è 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 è capace di raggiungere

un fattore Q di 0.6.3

In figura 1.3 è 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
CAP. 1 Cenni sulla fusione nucleare 1.3 Lo stato dell’arte: il JET

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. È usato solo per riscaldare il plasma con

il principio del trasformatore, dove il plasma stesso funge da secondario. Questo

circuito è 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
CAP. 1 Cenni sulla fusione nucleare 1.3 Lo stato dell’arte: il JET

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), è il responsabile della stabilizzazione verticale del plasma, oggetto di

questa Tesi;

• Circuito di forma. Composto dalla serie delle bobine P2S e P3S, è il circuito

gestito dal controllore di forma, il cui compito è 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 più di 20 anni di attività e studio, ci si sta rendendo conto che il JET inizia

a non essere più sufficiente per la comprensione delle problematiche intrinseche ad

un futuro reattore a fusione, che dovrà necessariamente essere di dimensioni maggiori

rispetto agli attuali Tokamak.

Queste considerazioni sono state la base sulla quale si è iniziato a pensare ad

ITER, acronimo di International ThErmonuclear Reactor, ma anche “strada” in

latino (figura 1.5).

ITER è 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, sarà 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 verrà 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 più 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 è decisamente maggiore in pros-

simità 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 è visto che avere un plasma con una forte triangolarità (figura 2.2), definita come

[2]:

0.5 · (c + d)
δ=
a
2
L’H-mode è una modalità 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 triangolarità aumenti).

Figura 2.2: Misura della triangolarità 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

necessità 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 necessità si consideri che la perdita di stabilità 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 quantità di energia elettrica posseduta dal

plasma viene trasformata in forze magnetiche e quindi traslazionali sulla macchina.

Mentre un VDE può 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 perché dell’instabilità verticale del plasma è relativamente

semplice. A tal proposito si osservi la figura 2.3 [11].

Figura 2.3: Instabilità 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 (poiché possiede il medesimo segno).

18
CAP. 2 La stabilizzazione verticale 2.2 Analisi del problema fisico

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 è sufficiente un piccolo sposta-

mento da tale posizione perché una delle due forze diventi predominante, attirando il

plasma verso la relativa espansione polare sempre più velocemente, e portandolo ad

infrangersi contro le pareti del Tokamak. L’inverso del tempo in cui questo avviene è

definito, al JET, growth rate γ (tasso di crescita).

2.2.1 Stima del growth rate

È possibile ottenere una stima abbastanza attendibile del growth rate utilizzando un

modello semplificato dell’instabilità verticale del plasma. Secondo tale modello, il

plasma può essere visto come uno o più filamenti rigidi, percorsi da una corrente

costante, con un unico grado di libertà coincidente con la posizione verticale del

centro4 dell’insieme di filamenti (rigid displacement model ).

Il modello matematico è 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
~ è il flusso concatenato da circuiti, strutture passive e filamenti di plasma; R è
dove ψ

la matrice contenente tutti i termini resistivi; I~ è il vettore contenente tutte le correnti

del campo poloidale e ~u è il vettore degli ingressi, ovvero delle tensioni applicate ai
4
In realtà viene usato il centroide dell’insieme di filamenti, ovvero una sorta di centro “pesato”
dall’intensità di corrente che scorre in ogni filamento.

19
CAP. 2 La stabilizzazione verticale 2.2 Analisi del problema fisico

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 è

la corrente di plasma e Br il campo magnetico radiale che agisce sul plasma.

Tramite semplici passaggi è possibile linearizzare il modello ottenendo (omettendo

le dipendenze per maggiore chiarezza):



 ∂ψ~ ˙ ∂ψ ~

 δ ~+
I δ ż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 è la matrice delle induttanze dei circuiti, M quella delle mutue induttanze

circuiti-plasma, ed F la forza destabilizzante. In tale modo il modello linearizzato

può essere riscritto come:




 Lδ I~˙ + gδ ż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) è possibile desumere il growth rate dell’instabilità 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 è 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 realtà tale autovalore, non fosse per le correnti parassita (eddy current) circolanti nelle strut-
ture metalliche passive a causa dei movimenti del plasma, sarebbe decisamente più 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 velocità 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Φ è la corrente toroidale totale concatenata dalla curva l6 ; Zc è 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 żp = ai Ḃt (i) + bi Ḃn (i) − I˙p zp − I˙pass zpass (2.2)
i=1 i=1

dove il termine I˙pass zpass relativo alle strutture passive è dato da:


4
I˙pass zpass = I˙D(i) zD(i) − I˙rr zrr − I˙mk2 zmk2
i=1

Ip e żp rappresentano corrente e velocità 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 è rappresentato

in figura 2.7. In esso si distinguono cinque blocchi:

• FRFA (Fast Radial Field Amplifier ): è 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: è un blocco che, sulla base delle misure magnetiche, determi-

na la velocità verticale del plasma (in pratica implementando l’equazione (2.2)

vista precedentemente7 );
7
Si noti che in realtà si ottiene, come indicato dalla (2.2), il prodotto Ip Żp , rappresentante la
velocità verticale del plasma pesata dalla corrente di plasma.

24
CAP. 2 La stabilizzazione verticale 2.5 L’algoritmo di controllo

• Velocity loop: è il controllore che si oppone a variazioni della velocità verticale

del plasma;

• Current loop: è 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: è 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 velocità e di corrente

Il blocco denominato velocity loop ha come compito quello di regolare a zero la velocità

verticale del plasma. Ciò viene effettuato attraverso un controllore di tipo proporzio-

25
CAP. 2 La stabilizzazione verticale 2.5 L’algoritmo di controllo

nale. Considerando la dinamica di FRFA, il comportamento complessivo del sistema

è 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 velocità non potrebbe garantire che il plasma e la corrente

circolante in FRFA non abbiano alcun tipo di deriva. Di conseguenza è 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 è 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 è 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 velocità e corrente

(GV e GI ). Si noti che la forbice di variazione di tali guadagni è limitata in modo da

impedire sia la saturazione dell’attuatore che prestazioni eccessivamente basse.

Oltre al controllo sulla frequenza è 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, è 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 è infatti quello di sperimentare tecniche che consentano di limitare gli ELM

più pericolosi stimolandone artificialmente di più piccoli e frequenti.

2.6 Problematiche di controllo

Il controllo di una macchina complessa come il JET è, ovviamente, soggetto a nu-

merose problematiche dovute sia all’intrinseca complessità del sistema-plasma, sia a

27
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

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 più 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, è 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 è 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 capacità di fornire fino a 10 kV a 2.5 kA (figura 2.9).

Ciascuna delle sotto-unità 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’unità stessa molto veloce (l’attivazione o disattivazione di una sottounità

richiede solamente 200 µs), la dinamica complessiva dell’oggetto è legata soprattutto

al banco di filtri a monte di ogni modulo, il cui scopo è quello di limitare la variazione

di tensione percepita dagli avvolgimenti di campo radiale (attualmente all’incirca 600

V /µs). Tale banco di filtri è composto da due induttori di potenza (Lf ) da circa 200

28
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

Figura 2.8: Andamento ad isteresi di FRFA.

µH e da una resistore da 14 Ω.

In [16] è 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
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

Figura 2.9: Schema elettrico di FRFA.

30
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

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 farà 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 più piccole rispetto
quelle del sistema di stabilizzazione verticale.

31
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

gnetiche che registrano più rumore sono i saddle loop 1 e 14, e successivamente, una

volta che il campo magnetico generato dai disturbi è 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, è attivo al JET: ciò è

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 proprietà 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
È possibile, al fine di visualizzarli meglio, pensarli come un’onda che si muove circolarmente
nella camera da vuoto.

32
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

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, può quindi essere rappresentato come un modo con N = 0.

Dato che l’ampiezza di tali modi è 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 può notare dal suo andamento, un N mode può 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 realtà il plasma non si è mosso dal suo punto di equilibrio.

33
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

Tale errore di misurazione può 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 è stato risolto

mediando le misurazioni su quattro ottanti opposti della camera, riducendo notevol-

mente l’influenza dei modi sulla misura [16]. Si noti, però, che la soppressione di tali

modi non è 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 instabilità che si verificano solo nel mo-

mento in cui si porti la macchina a lavorare in H-mode. In tale modalità 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 è 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, più 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 è ancora sotto studio. Si noti, tuttavia, che la presenza
di ELM è considerata da molti necessaria, in quanto funge da “valvola di sfogo” per il plasma,
che altrimenti cotinuerebbe a crescere in energia. Sperimentalmente si è visto, infatti, che limitare
artificialmente gli ELM può causare enormi disruzioni nel plasma stesso.

34
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

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 è visto

sperimentalmente al JET che la cosa migliore da fare al sopraggiungere di un ELM è

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 è quella di limitare gli ELM più grandi

provocandone di più piccoli frequentemente, forzando al massimo FRFA per pochi

35
CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

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 è

ancora “canonizzata”, e lo studio del controllo degli ELM è ancora un campo aperto.

36
Capitolo 3

Scrittura e porting del sistema di


controllo
In questo capitolo si parlerà 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 difficoltà 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. È 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 è rilasciato come software libero secondo

la licenza GPL1 , ed è liberamente scaricabile dalla rete. Nessuna royalty è

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 più interessanti dal punto

di vista industriale;

• Sistema attivamente sviluppato. Linux-RTAI è sviluppato da una comu-

nità piuttosto ampia di programmatori. Ciò implica che eventuali bug ri-

portati o nuove funzionalità, non appena testate, vengano immediatamente

rese pubbliche, senza dover attendere il classico ciclo di rilascio dei software

closed-source;

• Compilatore moderno ed ottimizzato. È 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 ;

• Facilità di installazione. L’installazione di Linux-RTAI non richiede altro che


1
General Public License, la più 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 è 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 è la piattaforma x86, la più 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;

• Facilità di sviluppo. Essendo nulla più 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 possibilità di testare il codice realtime direttamente

sulla stessa macchina su cui si effettua lo sviluppo;

• Interfacce grafiche. Grazie alla possibilità di eseguire sulla stessa macchina

codice realtime e non, è facile pensare e progettare interfacce grafiche e soft-

ware di visualizzazione dati, senza curarsi di come questi possano penalizzare

le prestazioni (perché, a tutti gli effetti, non le penalizzano, venendo eseguiti

solo negli istanti di tempo in cui la CPU non è impegnata ad eseguire codice

realtime);

• Sorgenti liberi. La disponibilità 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 possibilità 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 più “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 è possibile sviluppare software proprietario
(closed source) che usa le librerie di RTAI, ma è 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 già 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 è 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 è sentita la forte necessità di scrivere il codice del sistema di controllo

nel modo più 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

è la possibilità di scrivere codice di controllo in un modo estremamente modulare, di-

videndolo in blocchi software indipendenti tra di loro (ed indipendentemente testabili).

6
In realtà la BaseLib2 è una libreria estremamente complessa che fornisce decine di funzionalità
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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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 leggerà i segnali

di interesse dal DDB, effettuerà le operazioni che le competono, e quindi salverà 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 è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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 è prettamente logico: a

livello di codice nulla differenzia una GAM standard da una di I/O.

42
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

3.2.2 Struttura di VsGAM

L’algoritmo di stabilizzazione verticale del plasma è stato implementato come due

GAM distinte: una che si occupa di effettuare il controllo vero e proprio, nella parte

di velocità 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 è riportata nei listati 3.1 e 3.28 .

Per quanto riguarda la funzione di inizializzazione (listato 3.1), facilmente com-

prensibile, è da notare l’estrema semplicità con cui è 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 è identico al codice effettivamente implementato: per motii
di spazio e semplicità 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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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(), è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

(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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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() è 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 velocità (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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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
CAP. 3 Scrittura e porting del sistema di controllo 3.2 Implementazione del controllo

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 verità, composte da poche righe di codice. Tale codice non è
stato inserito direttamente nel corpo di PerformKickControl() al fine di permettere una maggiore
modularità e comprensibilità 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 è 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 è riportato in figura 3.2: la macchina a stati

si occupa di coordinare l’attività 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 responsabilità.


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 è 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 può essere

“collegato” a più 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 già correttamente sotto VxWorks.

Tuttavia, viste le caratteristiche positive di Linux già evidenziate, si sentiva il forte

desiderio di effettuare le correzioni necessarie perché 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 è 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 è passati al porting del sistema sotto un ambiente Li-

nux realtime. Di conseguenza la prima scelta che ci si è trovati a dover affrontare è

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 è 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 è infatti nato da un branch di RTAI.
13
Xenomai, infatti, introduce il concetto di maschera. Una maschera, nel gergo di Xenomai, è
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 priorità

ne effettui una, un eventuale ulteriore processo con priorità 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, è 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 priorità 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 è incentrata sul

52
CAP. 3 Scrittura e porting del sistema di controllo 3.5 Linux-RTAI

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 è stato quello del miglioramento dell’algo-

ritmo di scheduling, che è 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, più che per la velocità del sistema operativo in sé, quanto per

l’imprevedibilità 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 è, 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 ciò derivano i problemi illustrati nel paragrafo precedente: qualora

un thread non realtime esegua istruzioni bloccanti, il thread realtime non potrà essere

53
CAP. 3 Scrittura e porting del sistema di controllo 3.5 Linux-RTAI

eseguito finché 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 è composto, sostanzialmente,

solo da un particolare “scheduler di sistemi operativi”: l’idea di fondo, infatti, è quella

di permettere a più 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, è molto
promettente, specie per quanto riguarda le prestazioni.

54
CAP. 3 Scrittura e porting del sistema di controllo 3.5 Linux-RTAI

do una priorità bassa al kernel Linux. In questo modo i processi non realtime (che

“vivono” nello spazio del kernel Linux) non hanno possibilità di bloccare quelli real-

time: ogni loro tentativo di accedere all’hardware (effettuando chiamate di sistema)

rimarrà infatti bloccato in coda nel livello di ADEOS/RTHAL, in attesa che la CPU

non sia impegnata con codice a maggiore priorità.

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 già previsto la possibilità di dare

55
CAP. 3 Scrittura e porting del sistema di controllo 3.5 Linux-RTAI

all’utente il controllo sulla distribuzione del carico sui vari processori.

Per quanto riguarda il kernel Linux, è possibile specificare sulla riga di comando

del bootloader l’opzione isolcpus, indicando quali processori lo scheduler del kernel

Linux dovrà ignorare15 . Per ciò che concerne RTAI, invece, è possibile specificare con

l’istruzione rt set runnable on cpus su quali processori il thread realtime appena

creato dovrà essere eseguito.

Utilizzando queste due tecniche si è 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 è quella di far sı̀ che ogni processore gestisca al più 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, poiché come si è visto l’algo-

ritmo di stabilizzazione è 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 è 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 è isolcpus=n1[,n2,n3...]. Ogni processore è identificato da un
numero intero, e il primo core della macchina è indicato come 0.

56
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

in quanto garantiva la possibilità 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 è 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 più adatta ad applicazioni realtime rispetto a quella AMD: da questa considera-

zione è 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

è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

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 già

scritti al JET per utilizzare la diversa sintassi (cosa impensabile); inoltre, cosa ancora

più grave, essendo lo scheduler realtime slegato da quello di Linux, qualsiasi chiamata

al kernel avrebbe avuto seri problemi di sincronizzazione.

Una prima ipotesi è 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 necessità di entrare ed uscire dal contesto del kernel come viene

ora fatto), questo avrebbe portato alla necessità di gestire un kernel personalizzato,

con tutti i problemi connessi (difficoltà di aggiornamento, mancanza di supporto da

parte della comunità open-source...).

58
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

Di conseguenza è 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 è 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 più 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 è totalmente trasparente: una volta in-

clusi nel codice i file che rimappano le chiamate di sistema, basterà 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
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

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 finché la chiamata di sistema non è eseguita dal kernel Linux (rigorosamente non
realtime). Di conseguenza è necessario ricordare che eventuali thread con funzioni di controllore non
devono assolutamente compiere chiamate di questo tipo!

60
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

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 disponibilità 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
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

possono leggerli): notare come la copia di parametri sia protetta da un semaforo

(fun caller mem block sem) al fine di evitare che più 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 è 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 già citata

call remote function, delega al primo thread disponibile l’esecuzione della medesi-

ma.

In figura 3.8 è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

Figura 3.7: Diagramma di flusso di call remote function.

63
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

Figura 3.8: Diagramma di flusso della componente userspace di FCOMM.

64
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

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 possibilità di utilizzare il C++ in kernelspace (supporto contestato

dallo stesso Linux Torvalds, e di conseguenza disattivato di default) e la possibilità

di effettuare dynamic cast tra i vari moduli kernel. Inoltre, al fine di rendere il

più agevole possibile l’uso di queste due ultime funzionalità in kernelspace, il codice

necessario è 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 è scontrati con numerose problematiche di

difficile soluzione. Ad aggravare la situazione c’è stato il problema dell’impossibilità

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. Poiché in kernelspace non è possibile allocare memoria a piacimento,

si è 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 è successo talvolta che un thread sovrascrivesse parte della memo-

65
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

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, è stato necessario aggiungere di

volta in volta vari semafori atti a proteggere la memoria finché un thread non avesse

finito il suo compito. Tuttavia la complessità “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 è provveduto a

scrivere alcuni programmi di test per “stressare” sempre di più il meccanismo di sin-

cronizzazione, finché non si è stati sufficientemente sicuri di aver eliminato ogni errore.

Altra fonte di problemi è stata la configurazione di RTAI. Di base la patch è 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 è 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 più oggetti di quanti permessi e la macchina andava in

blocco. Tale problema è stato risolto aumentando la relativa voce nella configurazione

di RTAI, e ricompilando i vari moduli.

Un ulteriore problema è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.6 FCOMM

fornite dalla BaseLib2 : poiché 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 girerà il sistema di stabilizzazione verticale. La prassi

attualmente seguita è 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: poiché il thread di gestione e i thread che “materialmente” eseguono tali

operazioni si trovano su due processori distinti, non viene più a crearsi la situazione

di blocco (che tuttavia persevera nelle macchine a singolo processore).

Il porting delle funzionalità del C++ in kernelspace, invece, è stato relativamente

semplice: usando in parte i suggerimenti trovati in rete di chi aveva già 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 è riusciti in modo

agevole a far funzionare le cose.

Il problema principale è 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.

Ciò causava la non corretta inizializzazione (seguita da inevitabile crash) di molti og-

getti della BaseLib2. Il problema è 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, è 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 è 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. Poiché i moduli

kernel vengono visti come “eseguibili differenti” e non come librerie, il confronto tra

puntatori, ovviamente, non poteva che fallire.

Il problema è stato risolto modificando il codice GNU utilizzato per portare il

C++ in kernelspace in modo da eseguire la più 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 è stata sviluppata una shell, denominata RTAICon-

sole, sulla falsariga di quella già 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 è 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 è riportato in

68
CAP. 3 Scrittura e porting del sistema di controllo 3.7 RTAIConsole

figura 3.9.

Figura 3.9: Screenshot della console RTAI in azione.

Uno dei compiti principali della shell è 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
CAP. 3 Scrittura e porting del sistema di controllo 3.7 RTAIConsole

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 è un progetto ancora in fase embrionale, e solo lo

stretto necessario ad un funzionamento di base del sistema è implementato. Il progetto

finale è 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 . Ciò garantirebbe la possibilità 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, è 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 è 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 è costituito da vari moduli kernel, ciascuno dei quali fornisce una par-

te delle funzionalità 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 capacità 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 è 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”, è stato progettato in modo da essere il più minimale possibile:

il kernel è 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 è riusciti ad ottenere un sistema

Linux perfettamente funzionante in poco più di 100 megabyte di spazio, permettendo

un’agile distribuzione dello stesso.

Accanto a tale sistema è stata anche sviluppata una distribuzione Live, dotata

di un kernel più 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 è stata di recente fornita all’Università degli

Studi di Napoli “Federico II”.

Infine è 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 è

cercato di inserire quante più 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), è stata

finanziata dalla borsa di studio fornita dal Programma “Leonardo da Vinci”, della

durata di sei mesi.

Durante questo periodo di tempo si è 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 è

rivelato essere la soluzione definitiva, cosa che, specie in vista del futuro ITER (in cui

una perdita di stabilità 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 stabilità, di pari passo procede la ricerca nel campo software, al fine di garantire

tempi di calcolo del controllo sempre minori, fondamentali data la velocità del modo

verticale instabile.

In questa tesi si è 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 è 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 semplicità 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 è in fase di studio e dovrebbe essere

approfondita nei prossimi anni.

Altro elemento da migliorare sarà 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 più a basso livello ci si propone di migliorare il

progetto della RTAIConsole, attualmente in fase embrionale, aggiungendo la possibi-

lità di interagire direttamente con le classi fornite dalla BaseLib2.

Da un punto di vista controllistico, sono iniziati degli studi sulle possibilità 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 possibilità 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 tornerà 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 più 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 necessità 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 è una libreria scritta interamente in C++ (fatta eccezione per alcune

parti in assembler), il cui compito è quello di fornire un’infrastruttura software su

cui costruire programmi nel modo il più semplice e robusto possibile, favorendo la

riutilizzazione del codice attraverso un uso intenso della programmazione orientata

agli oggetti. Inoltre è 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 è quello di per-

mettere una facile portabilità 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 più sistemi operativi. Essa è stata quindi struttu-

rata in sette livelli (la cui struttura è 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 è stato pensato per utilizzare solamente i livelli a lui sottostanti. In

questo modo il processo di compilazione risulta essere estremamente semplificato e

veloce (è sufficiente compilare uno dopo l’altro i vari livelli, e quindi effettuare il

linking della libreria completa). Inoltre ciò 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: ciò è giustificato dalla maggiore complessità del porting sotto tale

architettura, in quanto la libreria deve funzionare in kernelspace, e di conseguenza de-


2
Si tratta, ovviamente, di una semplificazione: è 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 probabilità di un tale errore sia decisamente più 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 funzionalità

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 familiarità 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 è 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) è fondamentalmente quello di permettere una forma di in-

trospezione alle classi, dove per introspezione si intende la capacità di una classe di

“conoscere se stessa”. In altri termini, ogni classe derivante da Object è 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++ è 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 è stato ampiamente ripagato dal tempo
guadagnato nel poter riutilizzare seduta stante tutti i software già scritti.

81
APP. A La BaseLib2 A.3 Le classi fondamentali

(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, è uno dei maggiori punti di forza della BaseLib2 in quanto permette la

creazione di oggetti per nome. È possibile, cioè, 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 è quello della lo-

ro eliminazione: se l’usufruitore dell’oggetto dimentica, all’interno del suo codice,

di distruggerlo quando esso non è più necessario, vi è la possibilità, 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 è quello di limitare gli “errori uma-

ni”, cercando di prevedere il più possibile le situazioni di errore, e risolvendole a monte.

A tal fine è 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

più usati.

Per garantire questa funzionalità ad un oggetto è 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 provvederà 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 è in pratica quello

82
APP. A La BaseLib2 A.3 Le classi fondamentali

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 è quella dei Named Object, concetto preso

in prestito dal linguaggio Smalltalk. Un Named Object è un oggetto che garantisce

ad ogni sua istanza la proprietà di avere un “nome proprio”, tramite il quale possa

essere identificata in modo univoco. Questo meccanismo è fondamentale per creare

riferimenti ad istanze specifiche di un oggetto a runtime: solo grazie ad esso è possibile

gestire il complesso sistema di messaggistica tra oggetti implementato nella BaseLib2,

di cui si tratterà in seguito nel capitolo apposito.

Per comodità dell’utente finale, le proprietà di GarbageCollectable e di Named

Object sono state racchiuse in un’unica classe, GCNamedObject: qualunque oggetto

erediti da essa si vedrà 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
APP. A La BaseLib2 A.3 Le classi fondamentali

camente la capacità di contenere riferimenti ad altri oggetti: grazie a tale siste-

ma è 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 è riportato in figura A.3, con

evidenziati gli oggetti più importanti.

4
Un sistema simile è 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 ereditarietà, quelle
tratteggiate l’utilizzo (in corsivo è specificato il nome della variabile usata). I rettangoli con spessore doppio indicano le
classi più importanti.
A.3 Le classi fondamentali

85
APP. A La BaseLib2 A.3 Le classi fondamentali

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 è un’esasperazione

di questa idea.

Un CDB è 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 proprietà. Un esempio di tale sintassi è 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) è programmata in modo da prevedere più stati

(StateMachineState), ciascuno dei quali può a sua volta essere configurato per pre-

vedere più eventi (StateMachineEvent).

Il CDB può 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
APP. A La BaseLib2 A.3 Le classi fondamentali

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 è la possibilità di

interazione di più oggetti tra loro. Nel C++ classico questo avviene tramite l’utilizzo

di metodi e proprietà 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 è 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.

Affinché 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 è un template che fornisce alla classe indicata le proprietà 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 più 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, è 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 verrà 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 può 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 è 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 più 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 è stata piuttosto importante. Tra le varie distribuzioni candidate (tra cui la

celebre Fedora Core), si è infine scelto di usare Gentoo a causa non solo della sua

personalizzabilità e stabilità, ma anche dell’ottimo supporto tecnico fornito dalla co-

munità. 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 funzionalità in

meno di mezzo gigabyte (e rinunciando al compilatore ed al sistema di aggiornamento

pacchetti è stato anche possibile scendere sotto i 100 megabyte!).

90
APP. B Distribuzione Linux usata al JET B.2 Installazione di Gentoo

Questa appendice è una versione ridotta e commentata, contenente solo i punti

salienti e le difficoltà 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 è proceduto a

riavviare il sistema effettuando il boot da CD. Il LiveCD è 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 è stato effettuato, usando

il comando fdisk, cercando di limitare il numero di partizioni presenti al minimo. In

particolare si è 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
APP. B Distribuzione Linux usata al JET B.2 Installazione di Gentoo

stessa dimensione, lasciando tutto il resto a disposizione per file temporanei e di

sviluppo.

Il filesystem usato è l’ext3, sia per la sua diffusione e provata stabilità, 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 difficoltà del processo risulta essere ancora

maggiore a causa del fatto che, da qualche anno, tale forma di installazione non è

più supportata nella documentazione ufficiale di Gentoo. Di conseguenza è stato

necessario procedere passo-passo, cercando nella rete informazioni sui passi più 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 è provveduto a scaricare e decomprimere

il file contenente lo stage 1 da uno dei numerosi mirror di Gentoo presenti in rete. A

questo punto è 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 è passati alla configurazione del

sistema e ad aggiornare i file di base con un emerge --sync && emerge -uD world1 .

1
emerge è 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
APP. B Distribuzione Linux usata al JET B.2 Installazione di Gentoo

Compilazione del kernel

La parte più complessa del lavoro è stata, senza dubbio alcuno, quella di configurare

il kernel della macchina. L’idea di base è stata quella di costruire un sistema il più

possibile snello, sia per garantire la massima efficienza, sia per eliminare quanto più

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 è 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 funzionalità e tempi di compilazione decisamente ridotti, ma

che è andata contro la portabilità del kernel stesso. Tuttavia si noti che, in effetti,

l’architettura finale su cui dovrà funzionare Linux-RTAI è ben determinata e non

soggetta a frequenti cambiamenti, cambiamenti che, in ogni caso, non richiedono molto

più del cambiare alcune opzioni nella configurazione del kernel, e una ricompilazione

dello stesso.

Oltre a queste operazioni è stata anche applicata la patch RTAI in modo da otte-

nere un kernel con le funzionalità realtime necessarie.

Completamento dell’installazione

Le ultime operazioni effettuate hanno riguardato l’installazione di un bootloader e la

sua configurazione. Si è inoltre proceduto ad installare alcuni software aggiuntivi per

facilitare le operazioni da riga di comando (come VIM, per garantire delle funzionalià

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 è stata quella di costruire una distribuzione Live2

a partire dall’installazione di Gentoo appena completata.

Si è 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 è 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

è sembrato estremamente vantaggioso.

Riduzione dello spazio occupato

La prima operazione necessaria alla trasformazione dell’installazione di Gentoo in un

LiveCD/LiveUSB è quella di ridurre il più possibile lo spazio occupato, limitato dalla

dimensione massima del CD o della penna USB usata.

A tal fine si è provveduto a rimuovere tutte le funzionalità non necessarie, quali il

sistema di aggiornamento pacchetti e relative dipendenze. Inoltre sono stati rimossi

tutti i file di documentazione e si è provveduto a lanciare un make clean per ripulire

le directory contenenti le sorgenti del kernel e di RTAI.

Ulteriore spazio è stato guadagnato utilizzando il filesystem SquashFS, estrema-

mente compresso. Sfortunatamente il kernel Vanilla non prevede quest’opzione, ed è


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 è 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 già questa

possibilità e fornisce un’immagine per CD pronta all’uso.

Viceversa, nel caso della LiveUSB, la procedura è stata leggermente più semplice:

poiché la penna USB viene vista da Linux come un vero e proprio hard disk, è stato

sufficiente installare su di essa grub. L’unico problema è 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 è stato quello di effettuare il boot della

macchina da remoto. In questo modo è stato possibile salvare filesystem e immagine

del kernel in un computer esterno alla sala macchine, col vantaggio di essere più facil-

mente accessibile e modificabile (cosa fondamentale in fase di sviluppo), e soprattutto

soggetto a periodici backup.

La tecnologia che ha permesso ciò è 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 già incorporato nella scheda di rete presente nella mac-

china, è 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: è stato suffi-

ciente far aggiungere alcune righe al file di configurazione del server DHCP affinché

“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 è 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 è, ovviamente, una delle più importanti e delicate. Ottenere un buon

compromesso tra costi, scalabilità, robustezza e velocità non è 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 è 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 è stata fatta in

modo da minimizzare proprio questa seconda tipologia di ritardi, in quanto la prima

è decisamente meno limitante data la potenza di calcolo dei processori moderni e la

possibilità di costruire sistemi multiprocessore. A tal fine si è 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) è uno

standard sviluppato dal PICMG (PCI Industrial Computer Manufacturers Group),

un consorzio internazionale composto da più di 400 società. Scopo dello standard è

quello di definire i requisiti di base per la strumentazione da telecomunicazioni futu-

ra. I principali punti di forza di questo standard sono la velocità 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 possibilità 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 possibilità 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 è specificato a priori, e nel caso del JET si è scelto

di usare la tecnologia PCI Express.

C.3 Il controllore ATCA

Il controllore ATCA, il cui schema logico è riportato in figura C.4, è 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 più evidente della soluzione proposta è 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 possibilità 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’unità risiede. Ciò permette un’esecuzione parallela

particolarmente adatta al processamento di segnali per sistemi MIMO.

Questa proprietà, insieme alla capacità degli FPGA di funzionare indipendente-

mente dalla scheda di controllo, garantisce la possibilità di elaborare segnali saltando

completamente il processore centrale: segue la possibilità di delegare buona parte dei

100
APP. C Specifiche hardware C.5 Prestazioni

compiti di filtraggio agli FPGA, scaricando di molto le responsabilità 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 possibilità 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 triangolarità di un plasma. . . . . . . . . . . . . . . . . . 17

2.3 Instabilità 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