architettura basata su linux rtai per la stabilizzazione verticale del joint european torus

UNIVERSITA DEGLI STUDI DIROMA

TOR VERGATA

FACOLTA DI INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA

DELL’AUTOMAZIONE

A.A. 2006/2007

Tesi di Laurea

ARCHITETTURA BASATA SU LINUX-RTAI

PER LA STABILIZZAZIONE VERTICALE

DEL JOINT EUROPEAN TORUS

RELATORE CANDIDATO

Prof. Luca Zaccarian Riccardo Vitelli

CORRELATORE

Dott. Ing. Filippo Sartori

Alla mia famigliaAi miei amici

Indice

Ringraziamenti 1

Introduzione 2

1 Cenni sulla fusione nucleare 5

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

1.2 Il Tokamak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

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

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

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

1.4 Le sfide future: ITER e DEMO . . . . . . . . . . . . . . . . . . . . . 13

2 La stabilizzazione verticale 15

2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Analisi del problema fisico . . . . . . . . . . . . . . . . . . . . . . . . 18

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

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

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

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

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

INDICE I

INDICE

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

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

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

2.6.1 FRFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

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

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

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

2.6.5 ELM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Scrittura e porting del sistema di controllo 37

3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

3.2.1 Le GAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

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

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

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

3.5 Linux-RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

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

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

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

3.6 FCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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

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

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

3.7 RTAIConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

INDICE II

INDICE

4 Risultati ottenuti 71

5 Conclusioni e sviluppi futuri 74

Appendices 77

A La BaseLib2 78

A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

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

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

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

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

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

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

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

A.3.6 Il CDB - Configuration DataBase . . . . . . . . . . . . . . . . 86

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

B Distribuzione Linux usata al JET 90

B.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

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

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

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

C Specifiche hardware 97

C.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

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

INDICE III

INDICE

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

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

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

Elenco delle figure 102

Bibliografia 103

INDICE IV

Ringraziamenti

Colgo questa occasione per ringraziare tutti coloro che hanno reso possibile questa

esperienza, lunga ben sei mesi, al JET. Prima di tutti i miei genitori e mia nonna,

che mi sono stati vicini nonostante i chilometri che ci separavano, offrendomi sempre

un supporto incondizionato anche durante i momenti piu difficili vissuti, ora come

durante l’intero arco della mia carriera scolastica prima, ed universitaria poi.

A loro si aggiunge quella lunga teoria di amici vicini e lontani che con affetto

hanno continuato a mantenere stretti rapporti, facendomi sentire spesso quasi come

se Oxford fosse a pochi passi dalle loro case. Insieme a questi ultimi l’ing. (e futuro

dottor) Salvatore Annunziata, conosciuto al JET e senza la cui solare presenza e co-

stante aiuto tutto sarebbe stato piu difficile, e gli altri ragazzi del gruppo.

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

fantastica opportunita di lavorare nel campo della fusione non sarebbe stata nemmeno

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

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

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

Italy” del Plasma Operations Group, popolata da persone capaci di creare un clima

di lavoro rilassato ma allo stesso tempo estremamente professionale.

INTRODUZIONE 1

Introduzione

Il problema energetico e senza dubbio alcuno la piu grande sfida che il genere umano

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

combustibili fossili e la necessita di trovare sistemi per produrre energia quanto piu

possibile “puliti” al fine di frenare l’inquinamento del pianeta, aggiunti alla sempre

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

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

questo campo.

Varie possibili risposte sono state date nel tempo a questo problema, nessuna delle

quali sembra essere, ad oggi, proponibile come alternativa ai combustibili fossili. Fonti

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

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

vista della potenza erogata, non puo essere considerata una soluzione a lungo ter-

mine, sia a causa delle scorie prodotte altamente radioattive e con elevato tempo di

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

dell’opinione pubblica, rimasta scottata da gravi incidenti quale quello di Cernobyl’ o

di Three Mile Island.

Una possibile soluzione al problema energetico potrebbe, invece, derivare dalla fu-

INTRODUZIONE 2

INTRODUZIONE

sione nucleare, che permetterebbe di accedere ad una fonte di energia sicura, pulita

e, soprattutto, rinnovabile, utilizzando come combustibile semplici isotopi dell’idro-

geno ricavabili facilmente dall’acqua e dal litio, abbondantemente disponibile nella

crosta terrestre.

Tuttavia la strada da percorrere e ancora lunga: numerosi problemi e sfide in ogni

campo della scienza e della tecnica, dalla fisica, alla meccanica, all’ingegneria dei con-

trolli, costellano il tortuoso percorso verso un reattore a fusione. Proprio al fine di

studiare le varie problematiche inerenti il confinamento del plasma, numerosi centri di

ricerca sono sorti in varie parti del mondo. In particolare a Culham, piccola cittadina

nei pressi di Oxford, Regno Unito, nella prima meta degli anni ’80 e stato costruito,

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

piu grande Tokamak attualmente esistente sulla faccia della Terra.

Al momento della costruzione del JET numerose considerazioni (relative sia alla

robustezza meccanica della struttura che all’efficienza del processo) hanno portato

alla decisione di conferire alla camera da vuoto una forma allungata verticalmente,

simile alla lettera “D”. Di conseguenza, al fine di sfruttare nel modo migliore lo spazio

a disposizione, si e scelto di dare al plasma una forma non piu circolare come in altri

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

Questo ha causato, tuttavia, una perdita della naturale stabilita verticale posseduta

dai plasmi circolari, portando alla necessita di progettare un sistema in feedback per

garantire che il plasma stesso non terminasse rovinosamente contro le pareti del To-

kamak.

INTRODUZIONE 3

INTRODUZIONE

Scopo di questo elaborato e illustrare l’implementazione dell’algoritmo per la stabi-

lizzazione verticale del plasma al JET, soffermandosi soprattutto sulle problematiche

incontrate durante il porting del software in ambiente Linux-RTAI. In particolare, nel

primo capitolo verra affrontata un’introduzione generale alle problematiche relative

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

tezza data la complessita dell’argomento; nel capitolo seguente si analizzera invece

l’algoritmo di stabilizzazione verticale, riassumendo prima le basi di fisica necessarie

a comprendere il fenomeno, e quindi le soluzioni adottate per contrastarlo. Il terzo

capitolo e dedicato all’implementazione dell’algoritmo stesso, illustrando il funziona-

mento dell’esecutore di thread realtime del JET (MARTe) e la logica modulare con

cui il controllore e stato realizzato (le GAM), e concentrandosi infine sul porting del

software verso Linux-RTAI e le relative problematiche. Infine, nei capitoli in appen-

dice, verranno illustrate alcune delle specifiche tecniche piu importanti (sia hardware

che software).

INTRODUZIONE 4

Capitolo 1

Cenni sulla fusione nucleare

In questo capitolo verranno brevemente riassunti, senza alcunapretesa di completezza, alcuni concetti basilari della fusione nu-cleare e del confinamento magnetico del plasma, soffermandosi inparticolare sul JET e sulla sua struttura magnetica.

1.1 La fusione nucleare

E noto che all’interno del nucleo atomico i protoni, essendo dotati di stessa carica

elettrica, tendono a respingersi e causerebbero la disgregazione dell’atomo se non esi-

stessero le forze di coesione nucleare. Una reazione nucleare consiste sostanzialmente

nella modifica, anche solo in parte, dell’equilibrio tra tali forze.

Esistono due tipi di reazione nucleare: la fissione e la fusione.

La prima, scoperta nella prima meta del ventesimo secolo da un gruppo di scienziati

(tra i quali una figura di spicco e sicuramente Enrico Fermi), anche grazie ai fondi

“donati” dal Ministero della Difesa americano in vista di un potenziale utilizzo bellico

contro il regime nazista e i suoi alleati, e attualmente l’unico sistema tecnologicamente

stabile per ottenere produzione di energia elettrica attraverso reazioni nucleari.

Tuttavia la pericolosa produzione di scorie nucleari nocive per la salute, oltre a rendere

5

CAP. 1 Cenni sulla fusione nucleare 1.1 La fusione nucleare

i reattori a fissione alquanto impopolari presso la pubblica opinione, ha portato a

cercare soluzioni alternative che potessero produrre quantita paragonabili di energia

in modo piu pulito.

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

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

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

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

massa e minore della somma delle masse dei nuclei “genitore”. La massa mancante si

trasforma in energia secondo la nota equivalenza massa-energia di Einstein E = mc2.

Per la fusione nucleare in genere si usano due isotopi dell’idrogeno, il deuterio e il

trizio che, interagendo, si uniscono a formare un nucleo di elio (o particella α) ed un

neutrone.

Figura 1.1: Diagramma della reazione di fusione nucleare.

La difficolta di realizzazione e controllo dei processi di reazione nucleare e legato al

fatto che, per soverchiare le forze di repulsione elettrica tra i nuclei, gli atomi devono

6

CAP. 1 Cenni sulla fusione nucleare 1.2 Il Tokamak

avvicinarsi a distanze dell’ordine di 10−11m, e per ottenere cio e necessario lavorare

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

nucleare in laboratorio e necessario portare e mantenere gas ionizzato a temperature

dell’ordine di 100 milioni di gradi centigradi1. A tali temperature la materia tende

a dissociarsi nei suoi elementi costitutivi, trasformandosi in una specie di “brodo” di

ioni ed elettroni definito plasma, o quarto stato di aggregazione della materia.

Il plasma e un gas ionizzato la cui carica complessiva, a causa della possente forza

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

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

di corrente. Tale proprieta e decisamente importante: proprio grazie alla possibilita

di generare una corrente di plasma e possibile “guidare” il plasma stesso attraverso

l’utilizzo di campi magnetici [1] [2]. Tale processo, che permette di isolare il plasma

ad alta temperatura dalle pareti del suo contenitore, e definito confinamento ma-

gnetico.

1.2 Il Tokamak

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

diffusa e senza dubbio il Tokamak (acronimo per la frase russa “TOroidalnaya KA-

mera i MAgnitnaya Katushka”, ovvero “camera toroidale e avvolgimento magnetico”),

sia per la sua relativa semplicita, che per la sua efficacia. Un Tokamak e generalmente

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

1Da notare che nelle stelle le temperature necessarie affinche avvengano reazioni di fusione (circa20 milioni di gradi) sono molto piu basse rispetto a quelle richieste in laboratorio: infatti, pur essendola probabilita che due atomi si fondano direttamente proporzionale alla temperatura, in un corpoceleste l’elevata gravita e conseguente pressione compensa tale minore probabilita.

7


magnetici sia sul piano poloidale (ovvero lungo la sezione verticale della camera)

che toroidale (parallelamente alla camera)2. Si confronti per maggior chiarezza con

la figura 1.2.

Figura 1.2: Rappresentazione di avvolgimenti e campi toroidale e poloidale.

In figura 1.2 e anche possibile vedere come le due tipologie di avvolgimenti ma-

gnetici diano origine ad un campo risultante dalla forma elicoidale.

1.2.1 Formazione e riscaldamento del plasma

Portare un gas alle temperature richieste perche esso si trasformi in plasma non e,

ovviamente, un’impresa semplice, tanto che e necessario adottare piu di un metodo

2Si 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 Tesici si riferira, salvo diversamente specificato, esclusivamente ai campi sul piano poloidale (generati daavvolgimenti posti su quello toroidale, indicati come “poloidal field coils” in figura).

8


per portare la materia in temperatura.

Una parte del calore necessario deriva dall’effetto Joule dovuto alla corrente di

plasma che circola nel gas, generata dall’avvolgimento centrale (figura 1.2) per effetto

trasformatore dove il plasma si comporta da secondario. Tuttavia tale parte e decisa-

mente insufficiente perche possano avvenire reazioni di fusione nucleare. Tale limite

e legato al fatto che all’aumentare della temperatura la resistivita del plasma tende a

decrescere e di conseguenza il riscaldamento Ohmico ad essa dovuto.

Per fornire la potenza aggiuntiva richiesta sono state studiate tre tecniche fonda-

mentali:

• L’uso di onde elettromagnetiche, che vengono iniettate nel Tokamak con

antenne o guide d’onda ed assorbite dal plasma (Radio Frequency Heating);

• L’iniezione di atomi neutri ad elevata energia cinetica, che trasferiscono

la loro energia al plasma urtando contro gli atomi che lo compongono (Neutral

Beam Heating);

• La compressione adiabatica del plasma, che viene ottenuta direzionando lo

stesso verso regioni con campo magnetico maggiore, con conseguente aumento

di pressione e temperatura.

Al JET vengono adottate le prime due tecniche.

L’obiettivo che si spera di raggiungere, tuttavia, e quello di creare le condizioni af-

finche il plasma possa autoalimentarsi: perche cio avvenga si deve riuscire ad arrivare

al punto in cui le particelle α generate dalla reazione siano in numero sufficiente da

innescare la fusione di un’ulteriore coppia deuterio-trizio. Tale evento viene definito

9

CAP. 1 Cenni sulla fusione nucleare 1.3 Lo stato dell’arte: il JET

in gergo tecnico ignition: teoricamente, portato il plasma in tale stato, la reazione

di fusione dovrebbe continuare all’infinito purche vi sia presenza di combustibile nella

camera da vuoto.

1.3 Lo stato dell’arte: il JET

Il JET e una macchina costruita in collaborazione tra i vari stati membri dell’Unione

Europea, e rappresenta ad oggi, con i suoi quasi tre metri di raggio maggiore, il piu

grande Tokamak esistente sulla Terra. L’entrata in funzione della macchina, avvenuta

nel 1983, ha rappresentato un enorme passo in avanti nel campo della ricerca sulla

fusione nucleare.

I numeri relativi al JET sono impressionanti: il campo generato per il confina-

mento del plasma e dell’ordine di 4T , con una corrente di plasma di 7MA. Inoltre,

con i suoi 16MW di potenza da fusione generati, il Tokamak e capace di raggiungere

un fattore Q di 0.6.3

In figura 1.3 e riportato l’interno della camera da vuoto del Tokamak, cosı come

appare attualmente4. In particolare si possono notare le tile (letteralmente “mattonel-

le”) della parete a contatto col plasma (denominata first wall), e la zona dei divertori

(in basso) dove viene concentrata la maggior parte dell’energia termica.

3Il 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 = ∞.

4Durante la sua storia, infatti, il JET ha subito un’enorme evoluzione, in particolare per quantoriguarda l’interno del vessel, al fine di sperimentare nuovi scenari e correggere errori precedenti.

10


Figura 1.3: Interno della camera vuoto del JET, con sovrapposta un’istantanea presain presenza di plasma.

1.3.1 I principali circuiti e bobine poloidali

In figura 1.4 sono riportati i principali circuiti poloidali che generano la struttura ma-

gnetica del JET. Si noti come alcuni di essi condividano fisicamente la stessa bobina.

Essi sono:

• Circuito di riscaldamento ohmico. E usato solo per riscaldare il plasma con

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

circuito e composto dal solenoide centrale (P1) e da alcuni avvolgimenti di P3

(in particolare P3ML e P3MU);

• Circuiti di campo verticale e sbilanciamento, PFX. Sono i circuiti che

regolano l’elongazione verticale del plasma (PFX, Poloidal Field X-Point), e che

contrastano la tendenza del plasma ad espandersi sul piano poloidale (collegati

ai due avvolgimenti P4);

11


Figura 1.4: Posizione delle bobine poloidali del JET.

• Circuito di campo radiale. Il circuito, composto dalla serie delle bobine P2R

e P3R ed alimentato dall’amplificatore denominato Fast Radial Field Amplifier

(FRFA), e il responsabile della stabilizzazione verticale del plasma, oggetto di

questa Tesi;

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

gestito dal controllore di forma, il cui compito e quello di modificare la sezione

del plasma;

• Circuiti di divertore. Denominati da D1 a D4 in figura, sono i responsabili

del posizionamento degli strike points, ovverosia dei punti dove il plasma scarica

la maggior parte della sua energia termica nel caso di configurazione con X-

12

CAP. 1 Cenni sulla fusione nucleare 1.4 Le sfide future: ITER e DEMO

Point5. Contrariamente agli altri, i circuiti di divertore sono gli unici psizionati

all’interno della camera da vuoto.

1.4 Le sfide future: ITER e DEMO

Dopo piu di 20 anni di attivita e studio, ci si sta rendendo conto che il JET inizia

a non essere piu sufficiente per la comprensione delle problematiche intrinseche ad

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

rispetto agli attuali Tokamak.

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

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

latino (figura 1.5).

ITER e uno sforzo collettivo internazionale dell’Unione Europea insieme alla Sviz-

zera, al Giappone, alla Corea, all’India, alla Federazione Russa agli Stati Uniti ed alla

Repubblica Popolare Cinese.

Attualmente ancora in fase di sviluppo, a breve i lavori di costruzione dovrebbero

iniziare a Cadarache, nel sud della Francia. Con i suoi 6 metri di raggio maggiore,

gli obiettivi principali di ITER sono quelli di raggiungere un fattore Q maggiore di 1

(teoricamente 10), e di funzionare, a regimi ridotti, non come macchina ad impulsi,

ma continua (steady-state); si spera inoltre di dare origine alla prima ignition della

5In tale configurazione all’interno della camera da vuoto non sono presenti solo linee di campochiuse, 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 ilnome.

13

CAP. 1 Cenni sulla fusione nucleare 1.4 Le sfide future: ITER e DEMO

Figura 1.5: Struttura meccanica di ITER.

storia della ricerca sulla fusione.

Il passo seguente, dipendente dal successo di ITER, sara DEMO, il primo esempio

di reattore a fusione che, con i suoi previsti 2GW di potenza dovrebbe essere in scala

con una moderna centrale elettrica, dando il via allo sfruttamento pacifico della fusione

termonucleare.

14

Capitolo 2

La stabilizzazione verticale

In questo capitolo verra affrontata la problematica della stabiliz-zazione verticale del plasma, introducendo i concetti fisici fonda-mentali necessari alla comprensione del problema, e quindi analiz-zando come questo sia attualmente risolto al JET, segnalando leproblematiche ancora aperte.

2.1 Introduzione

Il problema della stabilizzazione verticale del plasma al JET nasce dall’aver deciso di

adottare per il Tokamak un plasma “a forma di D” (D-shaped): laddove un plasma a

sezione circolare risulta essere verticalmente stabile, un plasma allungato perde tale

caratteristica.

La scelta di questa apparente complicazione deriva fondamentalmente da una con-

siderazione meccanica: la forma a D risulta evidentemente piu robusta sia per quanto

riguarda gli stress verticali1, sia, e soprattutto, relativamente alla deformazione oriz-

zontale della camera da vuoto, soggetta alle enormi forze derivanti dall’interazione

magnetica tra plasma e pareti del Tokamak stesso.

1Una camera circolare permette un punto di contatto minimo -teoricamente infinitesimale- coni supporti verticali, mentre una camera a D garantisce una parete di supporto pari all’altezza dellacamera stessa.

15

CAP. 2 La stabilizzazione verticale 2.1 Introduzione

A questa considerazione meccanica va aggiunto che, come noto, il campo magneti-

co decresce col quadrato della distanza: di conseguenza la corrente di plasma indotta

dall’avvolgimento poloidale al centro del Tokamak e decisamente maggiore in pros-

simita della parete interna. Un plasma D-shaped, quindi, espone un volume molto

maggiore a questa zona particolarmente favorevole (figura 2.1).

Figura 2.1: Caduta della corrente di plasma in dipendenza dalla distanza dall’asse deltoro.

Col tempo, inoltre, man mano che le teorie sull’H-mode2 andavano affermandosi,

si e visto che avere un plasma con una forte triangolarita (figura 2.2), definita come

[2]:

δ =0.5 · (c + d)

a2L’H-mode e una modalita di funzionamento dei Tokamak caratterizzata da pressioni ed energie

decisamente maggiori rispetto al metodo di funzionamento standard, battezzato L-mode.

16

CAP. 2 La stabilizzazione verticale 2.1 Introduzione

favorisce di molto i rendimenti della macchina (e si noti come man mano che la forma

del plasma tende verso una “D” maiuscola -come al JET- la triangolarita aumenti).

Figura 2.2: Misura della triangolarita di un plasma.

In definitiva, avere un plasma elongato verticalmente garantisce una lunga serie di

vantaggi (ad avviso di molti indispensabili in un futuro reattore a fusione); segue la

necessita quindi di studiare un sistema di controllo che riesca a stabilizzare la dina-

mica verticale del plasma causata dalla configurazione non circolare.

A sottolineare tale necessita si consideri che la perdita di stabilita verticale cau-

sa, in generale, un’improvvisa disruzione nel plasma (anche detta VDE, o Vertical

Displacement Event) con conseguenti enormi stress per il Tokamak, soprattutto dal

punto di vista meccanico, mentre l’enorme quantita di energia elettrica posseduta dal

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

Mentre un VDE puo essere tollerato dal JET, un evento del genere nel futuro ITER

potrebbe causare la rottura del Tokamak.

17

CAP. 2 La stabilizzazione verticale 2.2 Analisi del problema fisico

2.2 Analisi del problema fisico

Dal punto di vista fisico, il perche dell’instabilita verticale del plasma e relativamente

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

Figura 2.3: Instabilita verticale del plasma. I segni + e - indicano la direzione dellacorrente 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

3Una struttura passiva soggetta ad un campo magnetico, genera infatti a sua volta un campomagnetico “riflesso” (a causa della corrente che lo attraversa) che, nel caso del Tokamak, attira ilplasma (poiche possiede il medesimo segno).

18


esso si trova in una posizione di equilibrio verticale nella camera (ovverosia nel punto

in cui le forze indotte sul plasma dalle due espansioni polari risultano essere uguali

ed opposte), il plasma resta in posizione. Tuttavia e sufficiente un piccolo sposta-

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

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

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

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

2.2.1 Stima del growth rate

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

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

plasma puo essere visto come uno o piu filamenti rigidi, percorsi da una corrente

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

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

Il modello matematico e ottenuto combinando le equazioni elettriche degli avvolgi-

menti poloidali e delle strutture passive in funzione del flusso magnetico per radiante,

con l’equazione di bilancio delle forze [16]:

~ψ

(~I(t), zp(t)

)+ R~I(t) = ~u(t)

mpzp(t) = −2πrpBr

(~I(t), zp(t)

)Ip

(2.1)

dove ~ψ e il flusso concatenato da circuiti, strutture passive e filamenti di plasma; R e

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

del campo poloidale e ~u e il vettore degli ingressi, ovvero delle tensioni applicate ai

4In realta viene usato il centroide dell’insieme di filamenti, ovvero una sorta di centro “pesato”dall’intensita di corrente che scorre in ogni filamento.

19


vari circuiti (posto pari a zero, ovviamente, per le strutture passive); mp, zp e rp

rappresentano, rispettivamente, massa e posizione verticale e radiale del plasma; Ip e

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

Tramite semplici passaggi e possibile linearizzare il modello ottenendo (omettendo

le dipendenze per maggiore chiarezza):

∂ ~ψ

∂~Iδ~I +

∂ ~ψ

∂zp

δzp + Rδ~I = δ~u(t)

mpδzp = −2πrp

(∂ ~Br

∂~Iδ~I +

∂ ~Br

∂zp

δzp

)Ip

(2.2)

Effettuando quindi, al fine di semplificare, le seguenti sostituzioni:

∂ ~ψ

∂~I= L

∂ ~ψ

∂zp

= Ip∂M

∂zp

.= g

−2πrp

(∂ ~Br

∂~I

)= Ip

(∂M

∂zp

)T.= gT −2πrp

(∂ ~Br

∂zp

)= F

dove L e la matrice delle induttanze dei circuiti, M quella delle mutue induttanze

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

puo essere riscritto come:Lδ~I + gδzp + Rδ~I = δ~u(t)

mpδzp = gT δ~I + Fδzp

(2.3)

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:(L − g · gT

F

)δ~I + Rδ~I = δ~u (2.4)

Dall’equazione (2.4) e possibile desumere il growth rate dell’instabilita verticale

analizzando gli autovalori con parte reale positiva della matrice [16]:

−(

L − g · gT

F

)−1

R

20

CAP. 2 La stabilizzazione verticale 2.3 Le misure magnetiche

Tramite tale modello si e visto che, in una scarica tipica, il growth rate del JET

ha un valore nell’ordine5 di 102 − 103s−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 strutturadi 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.

5In realta tale autovalore, non fosse per le correnti parassita (eddy current) circolanti nelle strut-ture metalliche passive a causa dei movimenti del plasma, sarebbe decisamente piu alto (dell’ordinedi 106s−1), rendendo virtualmente impossibile controllare il movimento verticale del plasma.

21

CAP. 2 La stabilizzazione verticale 2.4 Stima della posizione verticale del plasma

Figura 2.5: Posizione su un ottante dei sensori di misura del campo magnetico.

2.4 Stima della posizione verticale del plasma

La tecnica usata per stimare la velocita verticale del plasma deriva dalle equazioni

sviluppate da Zakharov [13]:

IΦzc =1

µ

∮l

[Bt(r, z)z − r log

(r

R0

)Bn(r, z)

]dl (2.1)

dove IΦ e la corrente toroidale totale concatenata dalla curva l6; Zc e la posizione

verticale del centroide della precedente; Bt e Bn sono le componenti tangenziali e nor-

mali del campo magnetico misurato lungo l; infine r e z rappresentano le coordinate

6Corrente che comprende, oltre quella di plasma, anche quella dovuta ai divertori e alle strutturepassive.

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:

Ipzp =18∑i=1

aiBt(i) +14∑i=1

biBn(i) − Ipzp − Ipasszpass (2.2)

dove il termine Ipasszpass relativo alle strutture passive e dato da:

Ipasszpass =4∑

i=1

ID(i)zD(i) − Irrzrr − Imk2zmk2

Ip e zp rappresentano corrente e velocita verticale del plasma e ai e bi sono dei pesi

ottenuti risolvendo la (2.1) nei punti dove i sensori sono posti nella camera.

In particolare si hanno 18 pesi corrispondenti ai Mirnov coils (misura del campo

tangenziale) e 14 per i saddle loops (misura del campo normale) (figura 2.6) [16].

Si noti che, dopo l’introduzione dei divertori per gestire l’X-point, le Mirnov coils

presenti nella parte bassa della camera sono risultate essere inutilizzabili (proprio a

causa dell’azione di schermatura dei divertori stessi), e di conseguenza i relativi pesi

nell’equazione precedente sono posti pari a zero (avvolgimenti dal 10 al 18 in figura

2.6).

23

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

0 5 10 15 20 25 30 35−0.2

0

0.2

0.4

0.6

0.8

1

1.2

Coil Number

Wei

ght

Modified Set

Mirnov CoilsSaddle Loops

Figura 2.6: Pesi per i vari sensori magnetici, come da modifica dopo l’inserimento deldivertore.

2.5 L’algoritmo di controllo

Lo schema di controllo adottato al JET per la stabilizzazione verticale e rappresentato

in figura 2.7. In esso si distinguono cinque blocchi:

• FRFA (Fast Radial Field Amplifier): e l’amplificatore utilizzato per la

stabilizzazione verticale, capace di fornire fino a 2.5 kA a 10kV, con un funzio-

namento ad isteresi;

• Speed observer: e un blocco che, sulla base delle misure magnetiche, determi-

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

vista precedentemente7);

7Si noti che in realta si ottiene, come indicato dalla (2.2), il prodotto IpZp, rappresentante lavelocita verticale del plasma pesata dalla corrente di plasma.

24


• Velocity loop: e il controllore che si oppone a variazioni della velocita verticale

del plasma;

• Current loop: e il controllore che regola la corrente circolante in FRFA secondo

un preprogrammato (generalmente nullo salvo esperimenti particolari). Si noti

come l’azione di controllo sia la somma dei contributi dei due loop di controllo;

• Adaptive controller: e un blocco adattativo che regola i guadagni dei due

controllori (ovverosia la predominanza di uno rispetto all’altro) sulla base della

frequenza di switch di FRFA, al fine di evitare surriscaldamenti del medesimo a

causa della dissipazione intrinseca durante gli switch.

Figura 2.7: Schema generale dell’algoritmo per la stabilizzazione verticale del plasma.

2.5.1 Controllo di velocita e di corrente

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

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

25


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

e quello di un controllore bang-bang, che fa sı che il plasma tenda ad oscillare attorno

alla sua posizione di equilibrio verticale con un’ampiezza e una frequenza proporzio-

nali al valore del guadagno [11].

Da solo il controllore di velocita non potrebbe garantire che il plasma e la corrente

circolante in FRFA non abbiano alcun tipo di deriva. Di conseguenza e necessario

introdurre un ulteriore loop di controllo sulla corrente circolante nell’alimentatore al

fine di regolarla a zero (o ad un valore preprogrammato desiderato per alcuni esperi-

menti particolari). Il blocco current loop si occupa proprio di questo attraverso l’uso

di un controllore PI.

Il comportamento complessivo dei due controllori dipende dallo stato dell’esperi-

mento: all’inizio e alla fine dell’impulso (quando non si e in presenza di plasma) solo

il controllo di corrente risulta essere attivo (in modo da inseguire il preprogrammato

che guida la nascita e la morte del plasma), mentre durante l’esperimento entrambi i

controllori sono attivi e il ciclo di retroazione viene chiuso.

2.5.2 Controllo adattativo

Il controllore adattativo e costituito da due blocchi logici: il primo stima la frequenza

di switch di FRFA (misurando il numero di passaggi per zero della tensione misurata

all’uscita dell’amplificatore stesso) e lo filtra con un passa-basso al fine di ridurne

i picchi, mentre il secondo applica un controllo proporzionale comparando il valore

stimato con quello desiderato (impostato a priori e posto pari ad un valore ottimo

26

CAP. 2 La stabilizzazione verticale 2.6 Problematiche di controllo

per FRFA) e genera i due valori di guadagno per i controllori di velocita e corrente

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

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

Oltre al controllo sulla frequenza e previsto anche un controllo logico sulla tem-

peratura di FRFA: qualora essa sia troppo elevata il controllore passa in uno stato

temporaneo di emergenza che riduce ulteriormente i guadagni GV e GI , in quanto

si preferisce una drastica diminuzione della prestazione alla terminazione improvvisa

dell’esperimento causata dal surriscaldamento dell’attuatore.

2.5.3 Kick Control

Un’ulteriore forma di controllo, non riportata nello schema di figura 2.7 in quanto non

in feedback, e il cosiddetto Kick Control. Tale controllore permette di bypassare

il controllo in feedback, assegnando direttamente la tensione desiderata su FRFA ad

istanti precisi decisi a priori, o periodicamente, o anche sulla base degli Hα, misura di

radiazione che permette di determinare l’insorgere di un ELM. Un uso del Kick Con-

troller e infatti quello di sperimentare tecniche che consentano di limitare gli ELM

piu pericolosi stimolandone artificialmente di piu piccoli e frequenti.

2.6 Problematiche di controllo

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

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

27


limiti tecnologici quali la saturazione degli attuatori, le temperature limite e i disturbi

di misura.

In questa sezione si vuole passare rapidamente in rassegna, al fine di fornire un qua-

dro quanto piu completo possibile del sistema di stabilizzazione verticale, i principali

problemi attualmente da affrontare e non ancora risolti (quantomeno non completa-

mente).

2.6.1 FRFA

FRFA, acronimo di Fast Radial Field Amplifier, e il nome dell’amplificatore che pren-

de in ingresso il segnale generato dal sistema di stabilizzazione verticale e genera la

tensione applicata al circuito di campo radiale.

FRFA e costituito da quattro moduli identici, inverter a GTO, capaci di generare

2.5 kV a 2.5 kA. L’attuale configurazione prevede il collegamento in serie dei moduli,

garantendo a FRFA la capacita di fornire fino a 10 kV a 2.5 kA (figura 2.9).

Ciascuna delle sotto-unita viene attivata o disattivata a seconda delle richieste del

sistema di controllo: per tale motivo la caratteristica di FRFA presenta un andamento

ad isteresi invece che continuo (figura 2.8).

Essendo l’unita stessa molto veloce (l’attivazione o disattivazione di una sottounita

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

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

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

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

28


Figura 2.8: Andamento ad isteresi di FRFA.

µH e da una resistore da 14 Ω.

In [16] e stata ottenuta una funzione di trasferimento ingresso-uscita di FRFA mo-

dellando l’azione di comando sull’inverter come proveniente da un condensatore, con-

siderando i valori precedentemente indicati per il banco di filtri e aggiungendo i valori

di induttanza e resistenza per la bobina di campo radiale ricavati sperimentalmente.

Tale funzione di trasferimento risulta essere:

W (s) =Rf (2Lcs + Rc)

2LfLcs2 + [2Lf (Rc + Rf ) + LcRf ]s + RcRf

I risultati simulativi ottenuti con la precedente sono stati successivamente confermati

da prove sperimentali [16].

29


Figura 2.9: Schema elettrico di FRFA.

30


2.6.2 Accoppiamento tra controllo di posizione e forma

Il controllore di forma e quello di posizione verticale, pur lavorando a frequenze diffe-

renti8, sono fortemente accoppiati in quanto condividono parte degli avvolgimenti ma-

gnetici poloidali. Per quanto un parziale disaccoppiamento in frequenza sia garantito

dalle diverse bande di lavoro, talvolta questo non risulta sufficiente.

Nella maggior parte dei casi tale fenomeno si verifica quando si adotta il sistema

di controllo completo della forma XSC (eXtreme Shape Controller) a causa della sua

azione forte su tutti gli avvolgimenti interessati.

Unica soluzione a questo problema risulta essere quella di disaccoppiare i due

controllori, cosa che comporta un ridisegno sia hardware che software del sistema di

stabilizzazione verticale. Tale sistema fara parte del progetto di aggiornamento e mi-

glioramento del JET attualmente in fase di studio [16].

2.6.3 Rumore degli alimentatori

Le principali fonti di rumore al JET derivano dai disturbi causati dagli alimentatori,

che influenzano parzialmente le misure effettuate dai sensori magnetici, in particolare

quelli posti all’esterno della camera da vuoto (in quanto non schermati dalle strutture

passive).

Analisi effettuate azionando gli attuatori non in presenza di plasma hanno mo-

strato che i circuiti che disturbano maggiormente i sensori, soprattutto nella banda di

frequenza attorno i 300 Hz, sono il circuito di sbilanciamento e FRFA, e le sonde ma-

8In particolare il controllore di forma lavora a frequenze un’ordine di grandezza piu piccole rispettoquelle del sistema di stabilizzazione verticale.

31


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

volta che il campo magnetico generato dai disturbi e riuscito a penetrare le strutture

passive, il 5 ed il 10 (per la posizione si confronti la figura 2.5) [16].

Si noti che attualmente, per quanto il rumore sia abbastanza forte e facilmente

misurabile, nessun tipo di filtro, sia esso analogico o digitale, e attivo al JET: cio e

dovuto al fatto che l’attuale semplice sistema di controllo riesce comunque a svolgere

il suo compito senza mai cercare di inseguire il rumore.

2.6.4 Modi MHD

Uno dei principali problemi legati alle misurazioni magnetiche della posizione del pla-

sma derivano dai cosiddetti modi MHD (MHD modes, dove MHD sta per “magnetoi-

drodinamici”). Tali modi rappresentano perturbazioni del plasma che ne modificano

la simmetria, e possono essere decomposti in perturbazioni lungo il piano poloidale

(detti N modes) e toroidale (M modes): mentre i primi causano deformazioni nel pla-

sma (e di conseguenza interagiscono solamente col controllore di forma), i secondi si

comportano come oscillazioni verticali, e di conseguenza disturbano almeno in parte

le misurazioni magnetiche effettuate al fine della stablizzazione verticale.

Gli N modes (cosı come gli M ) sono caratterizzati da un numero che identifica la

loro armonica rispetto ad una decomposizione di Fourier spaziale9 (figura 2.10). Tali

modi, inoltre, hanno la proprieta di ruotare nella camera assieme al plasma10.

9Si pensi, a fini pratici, ad una trasformata di Fourier applicata al Tokamak usando come variabilel’angolo toroidale φ.

10E possibile, al fine di visualizzarli meglio, pensarli come un’onda che si muove circolarmentenella camera da vuoto.

32


−10

1

−1

0

10

0.05

0.1

N=0 mode

−10

1

−1

0

1−0.1

0

0.1

N=1 mode

−10

1

−10

1−0.1

0

0.1

N=2 mode

−10

1

−10

1−0.1

0

0.1

N=3 mode

Figura 2.10: Esempi di N-modes.

Uno spostamento dal centro verticale della camera, l’unico d’interesse per la sta-

bilizzazione verticale, puo quindi essere rappresentato come un modo con N = 0.

Dato che l’ampiezza di tali modi e inversamente proporzionale al loro indice N,

gli unici che possono influenzare pesantemente le misure magnetiche del JET sono

stati visti essere quelli con N minore di 3, e di conseguenza sono gli unici a venir

considerati.

Come si puo notare dal suo andamento, un N mode puo profondamente falsare

la misura della posizione verticale. Si consideri, ad esempio, il caso di un modo con

N = 2: effettuando le misure magnetiche in solo due lati opposti della camera si

avrebbe l’effetto di vedere, a valle dei sensori, un plasma oscillante attorno al centro

della camera, mentre in realta il plasma non si e mosso dal suo punto di equilibrio.

33


Tale errore di misurazione puo causare un surriscaldamento di FRFA, costretto a

continui (ed inutili) switch per inseguire il non esistente spostamento, fino a portarlo

allo spegnimento di sicurezza. Tuttavia recentemente tale problema e stato risolto

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

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

modi non e totale, giustificando quindi l’esistenza della parte adattativa del control-

lore mostrata precedentemente.

2.6.5 ELM

Gli ELM (o Edge Localised Modes) sono delle instabilita che si verificano solo nel mo-

mento in cui si porti la macchina a lavorare in H-mode. In tale modalita viene infatti a

crearsi una sorta di barriera al bordo del plasma (ETB, Edge Transport Barrier) che

causa un brusco innalzamento del gradiente di pressione lungo la medesima (figura

2.11), proprio grazie al quale e possibile aumentare drasticamente le prestazioni della

macchina.

Gli ELM derivano dal collasso di tale barriera esterna, e si manifestano come eru-

zioni di plasma che, andando a colpire la parete della camera, piu fredda, causano la

perdita di parte dell’energia interna dello stesso11.

Un ELM causa un totale blackout dei circuiti magnetici, che vengono pratica-

mente “accecati” dall’improvviso lampo di energia, causando la registrazione di forti

11Il meccanismo di innesco degli ELM e ancora sotto studio. Si noti, tuttavia, che la presenzadi ELM e considerata da molti necessaria, in quanto funge da “valvola di sfogo” per il plasma,che altrimenti cotinuerebbe a crescere in energia. Sperimentalmente si e visto, infatti, che limitareartificialmente gli ELM puo causare enormi disruzioni nel plasma stesso.

34


Sawteeth

10

1

Internal Transport Barrier(ITB)

i) Advanced Operating Modes

Edge Localized Modes(ELMs)

Edge TransportBarrier (ETB)

(H-mode)

Normalised radius r/a

JG03

.35-

27c

Pla

sma

Pre

ssur

e

L-mode

Core

Pedestal

ii) H-mode

Figura 2.11: Struttura del plasma in H-mode.

escursioni (ovviamente non reali) della posizione verticale del plasma e il conseguen-

te intervento dell’algoritmo di controllo che, cercando di inseguire i segnali misurati,

porta alla saturazione di FRFA.

Non essendo ancora conosciuta una tecnica per limitare tale problema, si e visto

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

spegnere il controllore per qualche millisecondo, lasciando che il plasma scarichi l’e-

nergia in eccesso in evoluzione libera, per poi ritornare in una zona controllabile. Tale

tecnica, tuttavia, risulta essere altamente empirica, e proprio per questa sua caratteri-

stica non utilizzabile in situazioni estreme, dove una perdita di controllo verticale, per

quanto breve, potrebbe portare a grandi disruzioni e addirittura danni alla macchina.

Un’altra tecnica in fase di sperimentazione e quella di limitare gli ELM piu grandi

provocandone di piu piccoli frequentemente, forzando al massimo FRFA per pochi

35


istanti all’innalzarsi della misura delle Hα (ovvero al sopraggiungere di un ELM)

usando il Kick Controller. Pur avendo ottenuto buoni risultati, tale tecnica non e

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

36

Capitolo 3

Scrittura e porting del sistema dicontrollo

In questo capitolo si parlera diffusamente del porting delle libre-rie (BaseLib2), e dell’esecutore di thread realtime su di esse ba-sato (MARTe), dall’architettura proprietaria VxWorks al sistemaoperativo open source Linux-RTAI, soffermandosi brevemente sullastruttura di questa architettura, e prestando particolare attenzionealle difficolta incontrate nel processo.

3.1 Introduzione

Una delle prime domande che potrebbero sorgere considerando il lavoro svolto riguar-

da, senza dubbio, le motivazioni dietro lo spendere tempo e risorse per effettuare il

porting di software dalla piattaforma VxWorks (o un qualsiasi altro sistema operati-

vo realtime proprietario) a Linux-RTAI. E possibile individuare molte caratteristiche

che rendono Linux-RTAI decisamente appetibile per un impiego pratico, sia esso nel

campo della ricerca che in quello industriale, tra le quali:

37

CAP. 3 Scrittura e porting del sistema di controllo 3.1 Introduzione

• Costo di licenza nullo. Linux-RTAI e rilasciato come software libero secondo

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

dovuta ai programmatori per l’uso di RTAI o per distribuire software basato su

di esso. Contando il costo elevatissimo di piattaforme realtime blasonate come

VxWorks, questa voce risulta sicuramente una delle piu interessanti dal punto

di vista industriale;

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

nita piuttosto ampia di programmatori. Cio implica che eventuali bug ri-

portati o nuove funzionalita, non appena testate, vengano immediatamente

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

closed-source;

• Compilatore moderno ed ottimizzato. E possibile sviluppare software che

fa uso di RTAI usando l’ottimo compilatore della GNU2 chiamato gcc, anch’esso

open source, gratuito e continuamente aggiornato;

• Sistema multipiattaforma. Linux-RTAI esiste per numerose architetture,

quali x86 e PowerPC, cosa che permette di scrivere software estremamente

portabile3;

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

1General Public License, la piu diffusa licenza open-source che obbliga sia a rilascia-re il codice sorgente assieme al software, sia ad applicare la medesima licenza a tut-to il software derivato. Per maggiori informazioni e possibile consultare il sito ufficialehttp://www.gnu.org/licenses/gpl.html.

2GNU is Not Unix, l’associazione no-profit che si occupa della diffusione del kernel Linux, dellalicenza GPL, ed in generale della filosofia Open Source.

3Si noti, tuttavia, che il “cavallo di battaglia” di Linux-RTAI e la piattaforma x86, la piu testatae meglio funzionante.

38

CAP. 3 Scrittura e porting del sistema di controllo 3.1 Introduzione

il download di un kernel “Vanilla”4 dal sito ufficiale, e dell’applicazione di una

patch;

• Facilita di sviluppo. Essendo nulla piu che una modifica al kernel standard,

RTAI permette l’uso di tutti i software che funzionano normalmente sotto Linux,

ivi compresi ambienti grafici quali Gnome o KDE, e strumenti di sviluppo quali

Eclipse o Netbeans, dando la possibilita di testare il codice realtime direttamente

sulla stessa macchina su cui si effettua lo sviluppo;

• Interfacce grafiche. Grazie alla possibilita di eseguire sulla stessa macchina

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

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

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

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

realtime);

• Sorgenti liberi. La disponibilita dei sorgenti del kernel Linux e di RTAI rende

possibile, in casi estremi, personalizzare il codice di base del sistema operati-

vo stesso, garantendo la possibilita di migliorare ulteriormente le prestazioni

eliminando codice non utilizzato, o regolandone in maniera fine i parametri di

funzionamento5.

A questi si aggiunge, pur non essendo un vantaggio tangibile di RTAI su soluzioni

proprietare, un discorso piu “filosofico”: l’uso di tecnologie open-source, specie nel

4Dove per “kernel Vanilla” si intende la versione del kernel ufficiale fornita dahttp://www.kernel.org senza alcuna patch applicata.

5In questo caso, tuttavia, la GPL impone di ridistribuire il codice sorgente delle modifiche appor-tate ad RTAI secondo la stessa licenza. In altri termini e possibile sviluppare software proprietario(closed source) che usa le librerie di RTAI, ma e illegale modificare RTAI e quindi ridistribuirlo senzafornire i sorgenti modificati.

39

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

campo della ricerca, rappresenta un notevole passo in avanti, verso un futuro in cui

il sapere sia condiviso e le scoperte compiute da un qualsiasi ente di ricerca diventino

immediatamente disponibili per tutti gli altri, favorendo lo sviluppo e la diffusione

della conoscenza, evitando perdite di tempo per ripercorrere i passi gia compiuti da

altri, e slegandosi inoltre dai vincoli imposti dalle grandi multinazionali, siano esse

del campo informatico o meno.

3.2 Implementazione del controllo

Implementare un controllo come quello richiesto dalla stabilizzazione verticale al JET

non e di certo un compito banale: per quanto gli algoritmi illustrati nel capitolo

precedente siano relativamente semplici, riuscire a costruire una piattaforma hardware

e software capace delle prestazioni necessarie, ma che sia al contempo stabile, robusta,

failsafe e facilmente aggiornabile, rappresenta sicuramente una sfida.

Inoltre si e sentita la forte necessita di scrivere il codice del sistema di controllo

nel modo piu astratto possibile, delegando il compito di interfacciarsi con l’hardware

ad un pacchetto di librerie sviluppate internamente dal nome BaseLib2, e limitan-

do quindi alla riscrittura di parte di quest’ultime il lavoro necessario al porting da

un’architettura all’altra6.

Dal punto di vista controllistico, inoltre, uno dei punti di forza di questa libreria

e la possibilita di scrivere codice di controllo in un modo estremamente modulare, di-

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

6In realta la BaseLib2 e una libreria estremamente complessa che fornisce decine di funzionalitaaggiuntive al C++, arrivando anche a stravolgerne il funzionamento. Per maggiori dettagli ed unavisione d’insieme di questa libreria si rimanda all’appendice apposita.

40


3.2.1 Le GAM

I “blocchi di codice” denominati GAM (General Application Module) sono dei sem-

plici oggetti capaci di comunicare tra loro attraverso un database di segnali (detto

DDB, Dynamic Data Buffer). Le GAM scelte per svolgere un dato compito vengono

eseguite da un esecutore realtime una dopo l’altra: ciascuna di esse leggera i segnali

di interesse dal DDB, effettuera le operazioni che le competono, e quindi salvera i suoi

segnali di uscita. Si noti come tale sistema sia concettualmente estremamente simile

a quello degli schemi a blocchi (figura 3.1).

Le GAM vengono sviluppate in C++: si tratta di semplici classi derivanti dalla

classe astratta GAM, fornita dalla BaseLib2, della quale reimplementano due funzioni

virtuali pure particolari, nella fattispecie:

• Initialise(), che si occupa di inizializzare la GAM e di aggiungere le interfacce

di comunicazione tra il DDB e la GAM stessa, caricando i parametri da un

oggetto di tipo CDB contenente la configurazione desiderata7 per la GAM;

• Execute(), che contiene il codice vero e proprio della GAM, eventualmente spe-

cializzato a seconda dello stato dell’esperimento (a titolo d’esempio si consideri

il diverso comportamento che una GAM che si occupa del salvataggio dati su

hard disk deve avere nel caso di idle o nel caso di esperimento in corso).

Un tipo particolare di GAM e quello denominato I/O GAM. Laddove le GAM

contengono la “logica di funzionamento” del controllore, le I/O GAM sono responsabili

della comunicazione con l’hardware vero e proprio, facendo da interfaccia tra la logica

di alto livello della BaseLib2 e il driver, garantendo di poter trattare l’acquisizione o

7Per maggiori dettagli su CDB si confronti l’appendice relativa alla BaseLib2.

41


C P

H

u y

v

DDB

GAMC

read(v)

read(u)

read(y)

wri te(u)

wri te(y)

wri te(v)

TIMEGAMP

GAMH

Figura 3.1: Passaggio da uno schema a blocchi alla struttura a GAM.

la scrittura di segnali come fosse una normale parte del processo di elaborazione del

controllore. Si noti, tuttavia, che il concetto di I/O GAM e prettamente logico: a

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

42


3.2.2 Struttura di VsGAM

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

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

di velocita e corrente cosı come in quella adattativa, chiamata ControlGAM, e un’altra,

detta KickControlGAM, che si occupa, qualora deisderato, di sostituire l’uscita della

precedente con dei valori preprogrammati all’insorgere di eventi particolari.

ControlGAM

La parte che effettua il controllo vero e proprio e riportata nei listati 3.1 e 3.28.

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

prensibile, e da notare l’estrema semplicita con cui e possibile implementare una GAM.

Il codice verifica la presenza dei parametri necessari nel CDB fornito, crea le interfacce

verso il DDB (funzioni AddInputInterface e AddOutputInterface) e “aggancia” i

vari segnali attraverso le funzioni AddSignal e ObjectLoadSetup9.

8Si noti che il codice qui riportato non e identico al codice effettivamente implementato: per motiidi spazio e semplicita sono state omesse tutte le istruzioni relative al debug ed al logging degli errori,ed i commenti in formato Doxygen per la generazione automatica della documentazione.

9Questa funzione non fa nient’altro che configurare i segnali leggendoli direttamente dal CDB sescritti in un formato standard.

43


Listato 3.1: ControlGAM::Initialise().

1 bool ControlGAM::Initialise(ConfigurationDataBase& cdbData)2 3 CDBExtended cdb(cdbData);4

5 // Add input/output interfaces6 if(!AddInputInterface(input,"InputInterface"))return False;7 if(!AddOutputInterface(output,"OutputInterface"))return False;8

9 // Add output(s)10 if(!cdb−>Move("Outputs"))return False;11 if(!cdb−>NumberOfChildren())return False;12 else numberOfOutputs = cdb−>NumberOfChildren();13 if(numberOfOutputs == 0)return False;14 if(!output−>ObjectLoadSetup(cdb, NULL))return False;15 cdb−>MoveToFather();16

17 // Add input(s)18 if(!cdb−>Move("Inputs"))return False;19 numberOfInputs = cdb−>NumberOfChildren();20 if(numberOfInputs == 0)return False;21 if(!cdb.ReadFString(secTimeBaseSignal,"TimeBaseSignalName") )22 return False;23 24

25 if(!input−>AddSignal(secTimeBaseSignal.Buffer() ,"float"))26 return False;27 28 if(!cdb.ReadFString(vGainProportionalityBaseSignal,29 "VgainProportionalityBase") )return False;30 if(!input−>AddSignal(vGainProportionalityBaseSignal.Buffer() ,"float"))31 return False;32 33 if(!cdb.ReadFString(usecTimeSignal,"TimeSignalName"))return False;34 if(!input−>AddSignal(usecTimeSignal.Buffer(), "int"))return False;35 cdb−>MoveToFather();36

37 return True;38

Il cuore del controllore, la funzione Execute(), e invece riportato nel listato 3.2. Le

righe 3 e 26 effettuano le operazioni di lettura e scrittura dal DDB, mentre lo switch-

case diversifica le operazioni da eseguire a seconda della situazione dell’esperimento:

in particolare nel caso di GAMOnline (ovverosia di esperimento in corso) vengono ef-

fettuate le vere e proprie operazioni di controllo, mentre nella fase di GAMPrepulse

44


(subito prima di un esperimento) vengono inizializzate le strutture (in tutte le altre

fasi la ControlGAM non agisce).

Listato 3.2: ControlGAM::Execute().

1 bool ControlGAM::Execute(GAM FunctionNumbers functionNumber)2

3 input−>Read();4 switch( functionNumber )5

6 case GAMOnline : 7 // Read Input8 float ∗data = (float ∗)input−>Buffer();9 secTimeBase = data[0];

10 vGainProportionalityBase = data[1];11 usecTime = ((int∗)data)[2];12

13 // Waveform generation14 GenerateWaveformControl(secTimeBase, waveStruct);15 GenerateLookupTable(vGainProportionalityBase, waveStruct);16

17 // Control18 PerformControl(usecTime, waveStruct, waveOutput);19

20 // Write Output21 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 pulse31 waveStruct.InitControlWaveStruct();32 waveOutput.InitOutputReferenceStruct();33 waveStructMeasured.InitWaveformControlMeasuredDataStruct();34 waveStructTrue.InitWaveformControlTrueDataStruct();35 InitPulseWaveControlGenerator();36 InitPulseControl();37 38 case GAMOffline :39 case GAMSafety :40 break;41 42 return True;43

45


In particolare, nella fase di GAMOnline, le righe dalla 7 alla 11 caricano nelle varia-

bili locali della classe il contenuto del DDB, le righe 14 e 15 caricano nella struttura

waveStruct i valori preprogrammati per correnti e guadagni, la riga 18 effettua il con-

trollo vero e proprio (incapsulato nella funzione PerformControl(), che a sua volta

richiama altre funzioni per effettuare i calcoli necessari, come riportato nel capitolo

precedente), ed infine le righe da 21 a 26 scrivono i risultati (i.e. le azioni di controllo)

sul DDB.

La funzione PerformControl() e riportata nel listato 3.3. Le righe 6 e 7 effettuano

il calcolo dell’errore di corrente; la 10 aggiorna la misura dei segnali calcolati nell’i-

stante di campionamento precedente presenti nella struttura waveStructMeasured;

le linee dalla 13 alla 14 effettuano dei controlli sull’attuale condizione della macchina

a stati che segnala l’andamento dell’esperimento per attuare controlli particolari nelle

fasi di creazione e terminazione del plasma, per segnalare l’avvenuta saturazione su

FRFA e gestire il cambio di segno del feedback nel passaggio tra plasma circolare

e plasma in H-mode; le righe 20-25 sulla base della frequenza di switch di FRFA

calcolano i nuovi guadagni per il controllo di corrente e velocita (secondo la logica

illustrata nel capitolo precedente), controllo che viene materialmente calcolato nelle

seguenti righe 28-30. Infine le ultime righe riempiono la struttura per l’output dei

dati e concludono l’esecuzione della funzione.

46


Listato 3.3: ControlGAM::PerformControl().

1 bool ControlGAM::PerformControl(int usecTime,2 WaveformControlInputDataStruct& waveStruct,3 WaveformControlMeasuredDataStruct& waveStructMeasured,4 OutputReferenceStruct& waveOutput5 )6 localControl.currentError = waveStruct.frfaCurrentReferenceWaveform7 − waveStructMeasured.frfaCurrentMeasured;8

9 // Update data10 UpgradeOldData(waveStructMeasured);11

12 //State machine functions13 SetTerminationState(waveStructMeasured);14 PlasmaTerminationControl(waveStructMeasured, waveOutput);15 SaturationSetFrfaState(waveStructMeasured);16 FrfaSaturationControl(waveOutput, waveStructMeasured);17 ControllerPolaritySet(waveStructMeasured);18

19 // Adaptive Control20 localControl.proportionality= waveStruct.vgainProportionalityWaveform21 ∗ waveStruct.currentLoopGainWaveform;22 CalculateControllerGains(waveStruct);23 CalculateSwitchingFreq(waveStructMeasured, waveOutput);24 FrequencyGainAdaptation(usecTime, waveStructMeasured,25 waveOutput, waveStruct);26

27 // Controller28 CurrentControl(usecTime, waveStruct, waveStructMeasured);29 SpeedControl(waveStruct, waveStructMeasured);30 ClassicControl(waveStruct, waveOutput);31

32 // Fill structures for DDB33 waveOutput.velocityLoopGainOutput = localControl.velocityLoopGain;34 waveOutput.frfaVoltageReferenceWaveform =35 waveStructMeasured.frfaVoltageReference;36

37 return TRUE;38

47


KickControlGAM

Il codice delle funzioni Initialise() ed Execute() di questa GAM viene omesso, in

quanto concettualmente e formalmente simile al precedente. Viene invece riportata

la breve funzione PerformKickControl() (listato 3.4) per illustrare il principio di

funzionamento di massima.

Listato 3.4: KickControlGAM::PerformKickControl().

1 bool KickControlGAM::PerformKickControl(int& usecTime,2 WaveformKickMeasuredDataStruct& waveStructMeasured,3 OutputReferenceStruct& waveOutput,4 WaveformKickInputDataStruct& waveStruct5 )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.

10Le ultime due funzioni sono, in verita, composte da poche righe di codice. Tale codice non estato inserito direttamente nel corpo di PerformKickControl() al fine di permettere una maggioremodularita e comprensibilita del codice nel caso di modifiche future.

48

CAP. 3 Scrittura e porting del sistema di controllo 3.3 Il sistema RT del JET: MARTe

3.3 Il sistema RT del JET: MARTe

Le due GAM illustrate precedentemente, che effettuano materialmente i calcoli per il

controllo, non sono ovviamente sufficienti a far funzionare il sistema di stabilizzazione

verticale del JET: numerosi altri elementi hanno bisogno di essere controllati via soft-

ware, in particolare la comunicazione con le apparecchiature di salvataggio dati e con

la macchina a stati che segnala in che fase dell’esperimento ci si trovi (preparazione

all’impulso, impulso, problemi tecnici, nascita e morte del plasma...), la ricezione delle

impostazioni di configurazione per un dato esperimento, l’invio di log di sistema, la

sincronizzazione con il clock esterno, il caricamento in memoria delle GAM e la loro

esecuzione in realtime...

Tutte queste operazioni vengono eseguite da MARTe (acronimo di Multithreaded

Application RealTime executor), implementato in C++ usando le classi fornite dalla

BaseLib2.

MARTe e composto da una serie di classi che comunicano tra loro attraverso mes-

saggi, ciascuna con un compito specifico e ben determinato. Un grafico che illustra il

funzionamento di massima di MARTe e riportato in figura 3.2: la macchina a stati

si occupa di coordinare l’attivita dei vari thread realtime, indicando i cambiamenti

di stato del Tokamak (prepulse, postpulse, offline...) segnalati da CODAS 11. In par-

ticolare la macchina a stati invia le informazioni al gestore dei thread in esecuzione

(Realime Thread Pool in figura), il quale a sua volta manda quanto ricevuto ad ogni

singolo thread di sua responsabilita.

11COntrol and Data Acquisition Systems, il gruppo che si occupa di coordinare l’impiantoinformatico e di comunicazione del JET.

49

CAP. 3 Scrittura e porting del sistema di controllo 3.3 Il sistema RT del JET: MARTe

Figura 3.2: Interazione tra MARTe, hardware e sistemi esterni.

Una serie di moduli di comunicazione si preoccupa di “tradurre” i segnali esterni

provenienti da CODAS (quali lo scenario desiderato per l’esperimento ed eventuali

situazioni di emergenza) in segnali comprensibili alle GAM ed alla macchina a stati.

Ogni realtime thread e composto della serie di GAM ed I/O GAM che lo carat-

terizza; queste ultime si occupano di comunicare direttamente con l’hardware (nel

caso della stabilizzazione verticale, in particolare, con le schede di acquisizione e di

conversione digitale-analogico). Si noti che ogni oggetto hardware non puo essere

“collegato” a piu di una I/O GAM, al fine di evitare conflitti tra thread realtime.

50

CAP. 3 Scrittura e porting del sistema di controllo3.4 Scelta del sistema operativo realtime

3.4 Scelta del sistema operativo realtime

MARTe, e la BaseLib2 su cui si basa, funzionavano gia correttamente sotto VxWorks.

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

desiderio di effettuare le correzioni necessarie perche esso compilasse e funzionasse

prima in userspace, e quindi in realtime ed in kernelspace con RTAI.

Per quanto riguarda il porting sotto Linux in userspace, le modifiche necessarie

non sono state eccessivamente estese: si e trattato principalmente di correggere alcu-

ne chiamate di sistema per renderle compatibili con lo standard POSIX, e riscrivere

alcune funzioni (in particolare quelle di interfacciamento con l’utente).

Finita questa operazione si e passati al porting del sistema sotto un ambiente Li-

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

stata quella relativa a quale patch del kernel adottare tra le varie proposte, in parti-

colare tra Linux-RTAI e Xenomai12.

Tra i due contendenti, infine, si e scelto di adottare Linux-RTAI, soprattutto per

le sue maggiori performance rispetto a Xenomai: quest’ultimo, infatti, aggiunge pa-

recchio codice per garantire un facile porting da altri sistemi operativi realtime13,

cosa che comporta, ovviamente, una riduzione delle prestazioni, fondamentali per la

stabilizzazione verticale.

12Si noti che le due patch, seppure estremamente diverse come obiettivi, possiedono una base dicodice comune: Xenomai e infatti nato da un branch di RTAI.

13Xenomai, infatti, introduce il concetto di maschera. Una maschera, nel gergo di Xenomai, eun’interfaccia che “emula” il set di istruzioni di un altro sistema operativo realtime.

51

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

3.5 Linux-RTAI

Il kernel Linux (nella sua incarnazione “Vanilla”) possiede numerose caratteristiche

che non lo rendono ideale per un uso realtime, tra le quali [15]:

• Coarse-Grained Synchronization, ovvero il fatto che le chiamate di sistema

non siano interrompibili. In altri termini, qualora un processo a bassa priorita

ne effettui una, un eventuale ulteriore processo con priorita realtime non po-

trebbe essere eseguito fino al termine dell’intera chiamata (cosa evidentemente

inaccettabile in un sistema hard-realtime);

• Paging, ovvero il processo di swapping di pagine di memoria dalla RAM all’hard

disk che, evidentemente, e non deterministico;

• Scheduling “Fairness”, ovvero il fatto che il kernel Linux cerchi di distribuire

equamente il tempo macchina tra i vari processi, di conseguenza rischiando di

interromperne alcuni con priorita realtime per permettere lo scheduling di altri

meno importanti;

• Request reordering, ovvero il processo di raggruppare le operazioni di I/O

in modo da garantire un uso ottimale dell’hardware (ma allo stesso tempo

inserendo dei ritardi assolutamente non determinabili a priori);

• Operazioni batch, eseguite dal kernel Linux per “riorganizzare” l’uso delle

risorse ed ottimizzare la memoria.

Col passare del tempo, soprattutto assecondando le richieste degli utilizzatori de-

sktop, numerose migliorie sono state apportate al kernel in modo da renderlo, quan-

tomeno, soft-realtime. In particolare l’attenzione degli sviluppatori si e incentrata sul

52


rendere il kernel e le chiamate di sistema interrompibili, eccetto che in alcuni punti

critici, e nell’ottimizzare l’uso del processore rilasciandolo durante porzioni di codice

non fondamentali. Altro punto di sviluppo e stato quello del miglioramento dell’algo-

ritmo di scheduling, che e passato dall’avere un tempo di esecuzione proporzionale al

numero di processi attivi, ad uno fondamentalmente costante.

Queste evoluzioni nel codice del kernel hanno reso Linux un sistema operativo

pronto per il desktop, capace di riprodurre filmati e audio senza evidenti interruzioni,

ed in generale di garantire la “user experience” che normalmente ci si aspetta da un

computer moderno. Tuttavia tali miglioramenti non sono risultati essere sufficienti

per un uso industriale, piu che per la velocita del sistema operativo in se, quanto per

l’imprevedibilita dei tempi di esecuzione qualora il sistema venga messo sotto stress

(per esempio con un uso intensivo della rete). Per questo motivo numerosi studi sono

stati effettuati sulle possibili patch da applicare al kernel per migliorarne il compor-

tamento e renderlo hard-realtime. Tra di queste una delle migliori e, per l’appunto,

Linux-RTAI, sviluppato dal Dipartimento di Ingegneria Aeropaziale del Politecnico

di Milano (DIAPM).

3.5.1 Funzionamento di RTAI

Per capire il funzionamento di Linux-RTAI si osservi innanzitutto figura 3.3, rap-

presentante lo schema di funzionamento semplificato dello scheduler del kernel Linux

standard. Lo scheduler di Linux si trova a dover gestire sia i thread realtime che quelli

non realtime; da cio derivano i problemi illustrati nel paragrafo precedente: qualora

un thread non realtime esegua istruzioni bloccanti, il thread realtime non potra essere

53


eseguito finche il precedente non rilasci esplicitamente la CPU.

Hardware

Kernel Space

User Space

RT

Proc

Non-RT

Task

Non-RT

Task

Non-RT

Proc

Non-RT

Proc

RT

Task

SystemCalls

Task Scheduling

ProcessScheduling

HWInterrupts

RawData

Figura 3.3: Schema di funzionamento di Linux senza le patch di RTAI.

La patch RTAI cerca di risolvere questo problema utilizzando una strategia intel-

ligente, ovverosia quella di frapporre tra l’hardware e il kernel Linux un nanokernel

minimale chiamato ADEOS/iPipe. Tale nanokernel e composto, sostanzialmente,

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

di permettere a piu sistemi operativi di convivere su una stessa macchina, venendo ese-

guiti in sequenza14. RTAI modifica ADEOS/iPipe (ribattezzato ADEOS/RTHAL)

in modo che esso intercetti le chiamate di sistema ed esegua i task realtime, assegnan-

14ADEOS/iPipe funziona in modo simile ad una virtual machine (quale VMWare), ma usandoun principio di base diverso: laddove una virtual machine “sfrutta” il sistema operativo ospitanteper 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, mettendoliin comunicazione in sequenza con l’hardware reale della macchina. Tale tecnica, con l’avvento deinuovi processori dotati di un set di istruzioni dedicato specificamente alla virtualizzazione, e moltopromettente, specie per quanto riguarda le prestazioni.

54


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

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

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

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

non sia impegnata con codice a maggiore priorita.

HARDWARE

ADEOS / RTHAL

Linux Kernel

Linux

User Space

RTAI’s

Kernel Thread

RTAI’s

Userspace

Process

(LXRT)

Figura 3.4: Comportamento del sistema modificato da RTAI.

3.5.2 RTAI ed i sistemi multicore

Un’architettura come quella di RTAI si presta facilmente all’uso su sistemi multipro-

cessore, come quello previsto per l’hardware della stabilizzazione verticale; in parti-

colare i programmatori di Linux e di RTAI hanno gia previsto la possibilita di dare

55


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

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

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

Linux dovra ignorare15. Per cio che concerne RTAI, invece, e possibile specificare con

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

creato dovra essere eseguito.

Utilizzando queste due tecniche si e ottenuto che il kernel Linux lavori solo sul

primo processore della macchina, mentre i thread realtime vengono assegnati ai core

rimanenti. L’idea di fondo e quella di far sı che ogni processore gestisca al piu un

thread realtime, massimizzandone il tempo di esecuzione.

Si noti che allo stato attuale la macchina per la stabilizzazione verticale del plasma

possiede un processore a quattro core: di conseguenza, poiche come si e visto l’algo-

ritmo di stabilizzazione e composto da un unico thread, attualmente tre core vengono

dedicati ai processi non critici (ovverosia quelli dipendenti dal kernel Linux, quali il

logging, la gestione della rete, eccetera), e solo uno all’esecuzione esclusiva realtime.

3.5.3 Userspace o Kernelspace?

La principale decisione presa riguardo Linux-RTAI e stata quella tra il lavorare in

kernelspace (usando quindi i thread nativi RTAI), oppure in userspace usando le

estensioni di RTAI chiamate LXRT, che consentono di rendere realtime thread creati

in spazio utente. La seconda ipotesi, in particolare, era particolarmente interessante

15La sintassi del parametro e isolcpus=n1[,n2,n3...]. Ogni processore e identificato da unnumero intero, e il primo core della macchina e indicato come 0.

56

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

in quanto garantiva la possibilita di utilizzare tutti i software disponibili sotto Linux

per il debug del codice, quali gdb o ddd, ed il non dover riavviare la macchina ad ogni

crash dell’applicazione.

Tuttavia alla fine si e scelto di lavorare in kernelspace soprattutto per garantire

le prestazioni massime. A tal proposito si veda il grafico di figura 3.5 dove sono ri-

portati gli andamenti di latenza media e jitter16 nel caso di thread in kernelspace e

di LXRT, e a seconda dell’architettura hardware considerata [14]. Si noti la minore

latenza dello scheduler standard rispetto a quello di LXRT, specie se confrontato con

il caso a singola CPU [14].

Inoltre si osservi anche come la piattaforma Intel abbia dimostrato essere decisa-

mente piu adatta ad applicazioni realtime rispetto a quella AMD: da questa considera-

zione e derivata anche la scelta dell’hardware da utilizzare (per maggiori informazioni

sull’hardware usato si rimanda all’appendice apposita).

3.6 FCOMM

Una volta scelto di lavorare in kernelspace, uno dei principali problemi da affrontare

e stato quello di trovare un modo per effettuare chiamate di sistema (quali lettura e

scrittura su disco, ascolto di socket e similari) da parte dei kernel thread realtime. Si

incorre infatti in due problemi principali: generalmente le chiamate di sistema “lato

kernel” sono diverse da quelle userspace (la glibc17 effettua lavoro intermedio per tra-

16Per latenza e jitter si intendono rispettivamente il ritardo tra l’istante in cui si ha un interruptrealtime e l’effettiva esecuzione del codice, e l’ampiezza della variazione della latenza nel tempo. Inun 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 jittertrascurabile ad una latenza bassa.

17GNU C Library, la libreria standard C rilasciata dal progetto GNU.

57


0

2

4

6

8

10

RT

AI-

LXR

T

RT

AI-

SC

HE

D

Late

ncy

(uS

)

Configuration

32 bit schedule over interrupt

AMD 1 CPUAMD 2 CPUIntel 1 CPUIntel 2 CPU

Jitter

Figura 3.5: Confronto tra la latenza di thread in kernelspace ed in userspace (LXRT).

durre le chiamate standard POSIX in chiamate comprensibili al kernel Linux), e di

conseguenza si sarebbe dovuto necessariamente riadattare il codice dei software gia

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

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

al kernel avrebbe avuto seri problemi di sincronizzazione.

Una prima ipotesi e stata quella di riscrivere parte del codice del kernel Linux

introducendo meccanismi di sincronizzazione tra i thread realtime e il kernel stesso:

per quanto estremamente promettente dal punto di vista delle prestazioni (in quanto

non ci sarebbe stata la necessita di entrare ed uscire dal contesto del kernel come viene

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

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

parte della comunita open-source...).

58


Di conseguenza e stato necessario trovare una soluzione alternativa, che evitasse

di cambiare il codice esistente (ovverosia si frapponesse in maniera trasparente tra la

BaseLib2 ed il kernel stesso) e garantisse la sincronizzazione con lo scheduler realtime.

Tale soluzione e stata battezzata FCOMM .

FCOMM si compone di un modulo kernel e di un normale processo userspace: il

primo intercetta le chiamate di sistema effettuate dalla BaseLib2 in kernelspace e le

rigira al secondo che, composto da una serie di thread userspace, le esegue ritornando

il risultato della chiamata (figura 3.6). Un semaforo fa sı che il modulo kernel attenda

la fine dell’esecuzione della chiamata da parte della componente userspace prima di

ritornare ad eseguire il codice della libreria (risolvendo quindi il problema di sincro-

nizzazione tra i due scheduler).

Numerosi altri semafori nel codice di FCOMM, inoltre, garantiscono che esso sia

thread-safe, ovvero capace di lavorare con piu thread realtime, cosa fondamentale da-

to l’uso intensivo delle tecniche multithreading che fa la BaseLib2.

3.6.1 Analisi del funzionamento

Dal punto di vista dell’usufruitore, FCOMM e totalmente trasparente: una volta in-

clusi nel codice i file che rimappano le chiamate di sistema, bastera effettuare tali

chiamate normalmente, indipendentemente dal fatto che ci si trovi in realtime o me-

no18, per vederle eseguite.

18Si noti, tuttavia, che FCOMM non permette di rendere realtime chiamate di natura non tale(come operazioni di I/O col disco). Un thread realtime che faccia ricorso a funzioni di questo tipo

59


Figura 3.6: Architettura di FCOMM.

Internamente il modulo kernel non fa nient’altro che copiare i dati passati alla chi-

mata di sistema nell’area di memoria condivisa tra la parte kernel e user di FCOMM, e

quindi invocare la funzione call remote function (listato 3.5) indicando quale chia-

mata di sistema si vuole eseguire (l’intero fun id, i cui valori possibili sono definiti

da una serie di direttive #define) e un puntatore ai parametri stessi con la relativa

dimensione (par ids e par size rispettivamente). Una volta completata la chiama-

ta di sistema, il modulo si preoccupa di deallocare la memoria condivisa e restituire

l’esito alla funzione chiamante.

resta bloccato finche la chiamata di sistema non e eseguita dal kernel Linux (rigorosamente nonrealtime). Di conseguenza e necessario ricordare che eventuali thread con funzioni di controllore nondevono assolutamente compiere chiamate di questo tipo!

60


Listato 3.5: La funzione call remote function di FCOMM.

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

8 while(test call remote function() < 1)9 rt sem wait(fun call synch sem);

10

11 id = get rt free uid();12 rt sem wait(fun caller mem block sem);13

14 mem = (mem function ∗)real alloc(id, sizeof(mem function));15 if(mem != 0) 16 ∗remote fun call id shm = id;17 mem−>fun id = fun id;18 mem−>finished = 0;19 mem−>error errno = 0;20 for(; i<par size && i<MAX PARAMETERS CALL; i++)21 mem−>parameter ids[i] = par ids[i];22 else 23 rt printk("MEMORY ERROR!\n");24 rt sem signal(fun caller mem block sem);25 return ERROR SHM;26 27 rt sem signal(fun caller user sem);28

29 if(mem−>finished != 1) 30 rt sem wait(fun caller kernel sem);31 32

33 rt sem signal(fun caller mem block sem);34 while(mem−>finished != 1) 35 rt sem wait(fun return sem);36 37

38 i = mem−>return value;39 rt whoami()−>msg = mem−>error errno;40 rt sem signal(fun call synch sem);41 real free(mem);42 return i;43

In particolare le righe 8 e 9 attendono su un semaforo la disponibilita di un

thread di esecuzione in userspace; le righe da 11 a 33 copiano i parametri desi-

derati da kernelspace (dove risiedono) ad userspace (dove i thread di esecuzione

61


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

(fun caller mem block sem) al fine di evitare che piu thread scrivano contempora-

neamente nella zona di memoria comune tra user e kernelspace; le righe da 34 a 38

attendono che il thread userspace segnali di aver completato l’esecuzione e copiano

il valore di ritorno e l’eventuale codice d’errore da userspace; ed infine la riga 40

segnala agli altri thread eventualmente in attesa della liberazione di un thread di

esecuzione e la 41 libera la memoria allocata per il passaggio dei parametri. Un dia-

gramma di flusso che illustra il comportamento della funzione e riportato in figura 3.7.

In userspace, invece, FCOMM predispone una serie di thread di esecuzione e,

non appena viene richiesto di eseguire una chiamata di sistema con la gia citata

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

ma.

In figura 3.8 e illustrato il diagramma di flusso della componente userspace: nor-

malmente in attesa di richieste di esecuzione, non appena arriva una segnalazione sul

relativo semaforo da kernelspace, FCOMM si occupa di decrementare il numero di

thread di esecuzione disponibili (attualmente pari a 15), copiare i parametri per la

funzione da chiamare dalla zona di memoria condivisa con il kernel, eseguire la funzio-

ne stessa, memorizzando i valori di ritorno e l’eventuale codice di errore, e segnalando

al kernel il completamento dell’esecuzione.

62


Figura 3.7: Diagramma di flusso di call remote function.

63


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

64


3.6.2 Funzioni aggiuntive

Oltre al meccanismo di cui sopra, FCOMM fa parte di un pacchetto di codice svilup-

pato per risolvere ulteriori problemi relativi all’esecuzione della BaseLib2 sotto RTAI,

in particolare la possibilita di utilizzare il C++ in kernelspace (supporto contestato

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

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

piu agevole possibile l’uso di queste due ultime funzionalita in kernelspace, il codice

necessario e stato impacchettato in un singolo modulo da caricare in memoria prima

dell’esecuzione del codice basato sulla BaseLib2.

3.6.3 Problematiche e soluzioni

Durante lo sviluppo e il debug di un meccanismo di sincronizzazione complesso e

thread-safe come quello di FCOMM ci si e scontrati con numerose problematiche di

difficile soluzione. Ad aggravare la situazione c’e stato il problema dell’impossibilita

di eseguire un debugger sul codice funzionante in kernelspace, e il fatto di ottenere

blocchi totali di sistema ad ogni minimo errore (cosa che ha messo a dura prova anche

l’hardware delle macchine usate per lo sviluppo).

La maggior parte dei problemi emersi sono derivati dall’esecuzione di applicativi

multithreaded. Poiche in kernelspace non e possibile allocare memoria a piacimento,

si e dovuto risolvere il problema di dove porre i dati richiesti per la comunicazione

tra parte userspace e parte kernelspace di FCOMM preallocando, all’inserimento del

modulo, un certo spazio di heap, spazio, ovviamente, condiviso tra tutti i thread.

Di conseguenza e successo talvolta che un thread sovrascrivesse parte della memo-

65


ria destinata ai dati di un altro thread, causando errori imprevedibili e per giunta

difficilmente riproducibili, dipendendo largamente da condizioni a contorno.

Una volta localizzata la fonte d’errore, quindi, e stato necessario aggiungere di

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

finito il suo compito. Tuttavia la complessita “logica” della programmazione parallela

ha reso difficile, se non impossibile, prevedere tutte le possibili situazioni di conflitto,

e nuovi errori di sincronizzazione emergevano ogni volta che si provava ad eseguire un

nuovo programma, o a modificarne uno esistente. Di conseguenza si e provveduto a

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

cronizzazione, finche non si e stati sufficientemente sicuri di aver eliminato ogni errore.

Altra fonte di problemi e stata la configurazione di RTAI. Di base la patch e con-

figurata per un utilizzo “normale” del sistema: controllore in C che gira come modulo

kernel. L’enorme stress e quantitativo di oggetti RTAI19 generati dalla BaseLib2, tut-

tavia, portava spesso a crash di sistema assolutamente inspiegabili. Dopo numerose

analisi del codice (verificando anche nella versione Linux non-RTAI della BaseLib2 )

si e capito che il problema era proprio il limite imposto sul numero di oggetti RTAI

creabili. Il test principale della BaseLib2, infatti, instanzia numerosi oggetti, ciascuno

dei quali fa largo uso di semafori e mutex: al momento dell’esecuzione del test l’ap-

plicativo cercava di allocare piu oggetti di quanti permessi e la macchina andava in

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

di RTAI, e ricompilando i vari moduli.

Un ulteriore problema e sorto in un test che faceva uso delle operazioni atomiche

19Dove per “oggetto RTAI” si intendono, fondamentalmente, le primitive di sincronizzazione, qualisemafori e mutex.

66


fornite dalla BaseLib2 : poiche tali operazioni (incrementi e decrementi) vengono ese-

guite senza mai rilasciare il processore (al fine di non poter essere interrotte -da cui il

nome “atomiche”), qualora eseguite nello stesso processore del test portavano ad un

completo blocco della macchina (mentre il processore continuava indefinitamente ad

eseguirle).

Pur non esistendo una vera e propria soluzione a questo problema (in quanto di-

pendente dal funzionamento delle operazioni atomiche e di RTAI), la scoperta del bug

ha avuto il merito di far sorgere la questione su come gestire i sistemi multiprocessore,

come la macchina sulla quale girera il sistema di stabilizzazione verticale. La prassi

attualmente seguita e quella di porre il kernel Linux su un processore, e dedicare

gli altri a RTAI. Questo ha indirettamente risolto anche il problema delle operazioni

atomiche: poiche il thread di gestione e i thread che “materialmente” eseguono tali

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

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

Il porting delle funzionalita del C++ in kernelspace, invece, e stato relativamente

semplice: usando in parte i suggerimenti trovati in rete di chi aveva gia effettuato il

tentativo, copiando l’implementazione GNU dei metodi new e delete e aggiornando

i makefile dei moduli in modo da utilizzare il compilatore C++, si e riusciti in modo

agevole a far funzionare le cose.

Il problema principale e nato relativamente agli oggetti statici (i.e. quelli non

creati tramite le funzioni new e delete): il compilatore C++ in userspace si occupa,

normalmente, di richiamare i relativi costruttori, cosa che non avviene in kernelspace.

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

getti della BaseLib2. Il problema e stato risolto con un semplice hack: due funzioni,

67

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

chiamate init all constructors e delete all deconstructors, ottengono una li-

sta di puntatori a funzione dei costruttori e distruttori delle classi, e li richiamano in

sequenza. La soluzione del problema, quindi, si limita al dover lanciare tali funzioni

al caricamento ed alla rimozione del modulo kernel d’interesse.

Ultimo problema affrontato, infine, e stato quello di permettere dynamic cast tra

diversi moduli del kernel, altra cosa fondamentale per il buon funzionamento del-

la BaseLib2. Pur funzionando correttamente il C++ in kernelspace, infatti, tutte

le chiamate a dynamic cast fallivano. La causa e stata infine individuata nel fatto

che, normalmente, la glibc effettua i cast dinamici confrontando puntatori e non com-

parando le stringhe contenenti il nome della classe vere e proprie. Poiche i moduli

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

puntatori, ovviamente, non poteva che fallire.

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

C++ in kernelspace in modo da eseguire la piu lenta comparazione tra stringhe, im-

postando la variabile del preprocessore GXX MERGED TYPEINFO NAMES a 0.

3.7 RTAIConsole

Per facilitare l’utilizzo di RTAI e stata sviluppata una shell, denominata RTAICon-

sole, sulla falsariga di quella gia esistente per VxWorks. Tale console si compone di

un modulo kernel e una componente userspace: il primo, in particolare, espone una

funzione, CallRemoteFunction, il cui compito e quello di eseguire funzioni esportate

in kernelspace semplicemente indicandone l’indirizzo; la seconda, invece, si occupa

dell’interfacciamento con l’utente (uno screenshot della parte userspace e riportato in

68


figura 3.9.

Figura 3.9: Screenshot della console RTAI in azione.

Uno dei compiti principali della shell e quello, in fase di caricamento di un modulo,

di eseguire, se presente, la precedentemente citata funzione init all constructors

(e, simmetricamente, delete all deconstructors in fase di rimozione), permettendo

di risolvere il problema degli oggetti statici non inizializzati.

Per ottenere gli indirizzi in kernelspace di una funzione, RTAIConsole legge il file

/proc/kallsyms, generato in tempo reale dal kernel Linux, e contenente l’elenco di

tali funzioni.

In aggiunta a questo, RTAIConsole garantisce numerose altre funzioni che, in un

certo senso, cercano di “avvicinare” userspace e kernelspace (proprio come avviene

in VxWorks, dove non esiste lo spazio utente protetto), permettendo di eseguire sia

funzioni kernel che programmi userspace, e garantendo un supporto basilare per l’e-

69


secuzione di script con sintassi bash-like, utili per velocizzare operazioni ripetitive

(come il caricamento dei moduli standard della BaseLib2 ed eventualmente, in futu-

ro, avviare in modo automatico MARTe).

Si noti, tuttavia, che la shell e un progetto ancora in fase embrionale, e solo lo

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

finale e quello, molto ambizioso, di permettere la creazione di oggetti a partire da

classi C++ in modo da far sı che la shell possa interagire direttamente, anche per

mezzo di script, con la BaseLib2 stessa, eventualmente anche usando un interprete

C/C++ come CINT20. Cio garantirebbe la possibilita di scrivere codice ed eseguirlo

in realtime direttamente, senza passare per la compilazione ed il linking, ed ottenere

quindi una perfetta piattaforma di test per sistemi di controllo sotto RTAI.

20CINT, o C INTerpreter, e un progetto sviluppato al CERN. Maggiori informazioni sono reperibilisul sito ufficiale: http://root.cern.ch/twiki/bin/view/ROOT/CINT.

70

Capitolo 4

Risultati ottenuti

Con il lavoro di porting effettuato si e riusciti ad ottenere una piattaforma stabile,

efficiente e semplice da programmare per lo svolgimento di compiti hard e soft realti-

me, il tutto basato esclusivamente su software open source e liberamente distribuibile

(kernel Linux e patch RTAI).

Il software e costituito da vari moduli kernel, ciascuno dei quali fornisce una par-

te delle funzionalita del pacchetto: il modulo della BaseLib2 e FCOMM formano il

nucleo centrale sulla quale si basa il controllore usato per la stabilizzazione verticale

(o in generale un generico controllore sviluppato secondo il paradigma delle GAM),

mentre RTAIConsole permette di far comunicare kernelspace ed userspace in maniera

semplice.

Assieme al pacchetto di software “di base”, altre utility sono state sviluppate, in

particolare una shell che permette di manipolare in maniera agevole i moduli usati,

anche grazie alla capacita di eseguire dei file di script creati ad hoc per evitare di

perdere tempo con azioni ripetitive.

71

CAP. 4 Risultati ottenuti

Inoltre numerosi applicativi di test sono stati scritti da zero o portati sulla nuova

piattaforma, sia per verificarne il funzionamento, sia per velocizzare l’apprendimento

della peculiare sintassi della BaseLib2 da parte dell’utente finale.

Assieme al software sviluppato si e provveduto anche a creare un sistema Linux su

cui esso potesse girare. Tale sistema, costruito a partire da una normale installazione

di Gentoo da “stage 1”, e stato progettato in modo da essere il piu minimale possibile:

il kernel e stato ridotto all’osso, eliminando tutti i moduli non necessari e compilando

statici solo i driver dell’hardware effettivamente presente nella macchina, e tutti i

file di manualistica e documentazione sono stati rimossi, cosı come i software non

strettamente necessari (il sistema di gestione pacchetti di Gentoo, Python, Java e

Perl...) ed i sorgenti del kernel. In questo modo si e riusciti ad ottenere un sistema

Linux perfettamente funzionante in poco piu di 100 megabyte di spazio, permettendo

un’agile distribuzione dello stesso.

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

di un kernel piu generalista ed eseguibile direttamente da penna USB o da CD, col

compito di facilitare il testing su varie macchine del codice scritto facendo uso della

BaseLib2 e di RTAI. Tale distribuzione e stata di recente fornita all’Universita degli

Studi di Napoli “Federico II”.

Infine e stata posta particolare attenzione alla raccolta di documentazione sulla

stabilizzazione verticale dal punto di vista software, documentazione che prima dell’i-

nizio della scrittura di questa Tesi era praticamente nulla o sparsa su vari testi: si e

cercato di inserire quante piu informazioni possibili all’interno di questo documento,

indicando eventualmente i testi dove si possono approfondire i concetti esposti.

72

CAP. 4 Risultati ottenuti

Contributi da questo lavoro di Tesi sono stati usati per la preparazione dell’articolo

“Linux RTAI Real Time Framework for Fusion Devices”, approvato per la conferenza

SOFT 2008 ed attualmente in fase di correzione.

73

Capitolo 5

Conclusioni e sviluppi futuri

Questa Tesi, interamente svolta presso gli uffici del JET, a Culham (Oxford), e stata

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

durata di sei mesi.

Durante questo periodo di tempo si e avuto modo di approfondire il problema della

stabilizzazione verticale del plasma, problema che resta, ad oggi, ancora un campo

aperto: numerose proposte e tentativi sono stati effettuati, ma nessuno di questi si e

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

una perdita di stabilita verticale potrebbe causare danni irreversibili alla macchina),

sta portando ad un sempre maggiore interessamento di fisici ed ingegneri.

Assieme alla ricerca di un metodo per garantire misure accurate e ampi margini

di stabilita, di pari passo procede la ricerca nel campo software, al fine di garantire

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

verticale instabile.

In questa tesi si e cercato di illustrare il framework progettato al JET per la

74

CAP. 5 Conclusioni e sviluppi futuri

stabilizzazione verticale del plasma, soprattutto per quanto riguarda il porting dalla

piattaforma commerciale precedentemente utilizzata (VxWorks) al sistema operativo

libero ed open source Linux, modificato con le patch RTAI al fine di garantirne le

prestazioni hard-realtime.

Inoltre si e prestata particolare attenzione al fornire una documentazione semplice

e ad ampio spettro del problema della stabilizzazione verticale, indicando (dove ne-

cessario) i testi su cui approfondire i concetti esposti, e cercando di coprire tutte le

problematiche principali, sottolineando in particolare quelle ancora aperte e merite-

voli di ulteriore approfondimento.

Il framework sviluppato, grazie alla sua semplicita d’uso, si propone come otti-

ma base di partenza per la conversione alla struttura a GAM dei numerosi controlli

presenti al JET. In particolare l’unificazione del controllore di posizione verticale e di

forma potrebbe garantire un generale miglioramento delle prestazioni evitando situa-

zioni di conflitto tra i due sistemi. Questa idea e in fase di studio e dovrebbe essere

approfondita nei prossimi anni.

Altro elemento da migliorare sara quello relativo all’interfaccia con l’utente del

sistema: per la gestione da sala di controllo si sta prevedendo un sistema basato su

pagine web, mentre per un accesso piu a basso livello ci si propone di migliorare il

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

lita di interagire direttamente con le classi fornite dalla BaseLib2.

Da un punto di vista controllistico, sono iniziati degli studi sulle possibilita di mi-

75

CAP. 5 Conclusioni e sviluppi futuri

gliorare il ciclo di controllo, soprattutto per quanto riguarda il problema della quan-

tizzazione di FRFA. In particolare potrebbe essere possibile ottenere buoni risultati

usando tecniche di controllo a tempo minimo, parzialmente a catena aperta.

Le possibilita di sviluppo future, sia per quanto concerne il software, sia riguardo il

miglioramento del controllore, saranno studiate ed implementate nel corso dei prossimi

sei mesi, durante i quali si tornera a Culham per proseguire il lavoro al JET.

76

Appendices

77

Appendice A

La BaseLib2

In questa appendice vengono riassunti i principi di funzionamentodella BaseLib2, la libreria che si occupa di fornire i servizi di baseai software sviluppati al JET, e le motivazioni che hanno spinto asvilupparla.

A.1 Introduzione

Gestire l’infrastruttura software di un sistema complesso come un Tokamak (ed a mag-

gior ragione del Tokamak piu grande attualmente esistente) risulta essere un compito

estremamente gravoso: qualsiasi possibile modifica, per quanto piccola, all’impianto

deve ovviamente essere failsafe1 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.

1Per failsafe generalmente si intende un sistema che garantisca, in caso di errore, di causare danniminimi. In questo caso specifico ci si riferisce alla necessita di avere software che in caso di probleminon causi un crash di sistema.

78

APP. A La BaseLib2 A.2 Divisione in livelli

La BaseLib2 nasce proprio al fine di limitare questi problemi.

La BaseLib2 e una libreria scritta interamente in C++ (fatta eccezione per alcune

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

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

riutilizzazione del codice attraverso un uso intenso della programmazione orientata

agli oggetti. Inoltre e stata costruita in un modo estremamente gerarchizzato, con

un’astrazione progressiva dal sistema operativo sottostante, in modo da permettere

un facile porting su qualsiasi piattaforma (figura A.1).

A.2 Divisione in livelli

Come precedentemente sottolineato, uno degli obiettivi della BaseLib2 e quello di per-

mettere una facile portabilita del software scritto con essa da un’architettura all’altra,

azzerando il numero di righe di codice da modificare. A tal fine la libreria stessa deve

essere agevolmente compilabile su piu sistemi operativi. Essa e stata quindi struttu-

rata in sette livelli (la cui struttura e riportata in figura A.1), dei quali solo il primo

(Level0 ) contiene codice fortemente dipendente dal sistema operativo, e che quindi

necessita di essere riscritto ogni volta che si desideri effettuare il porting della libreria.

Ogni livello e stato pensato per utilizzare solamente i livelli a lui sottostanti. In

questo modo il processo di compilazione risulta essere estremamente semplificato e

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

linking della libreria completa). Inoltre cio ha permesso anche una semplificazione

della prima fase di debug della BaseLib2 : una volta testato e funzionante un livello,

79

APP. A La BaseLib2 A.2 Divisione in livelli

LEVEL 0(+ LEVEL RTAI C++)

(console, mutexes, atomic ops, streams...)

LEVEL 1

(named objects, garbage collection...)

LEVEL 2

(fi les, advanced streams...)

LEVEL 3

(CDB, Lexical Analyzer...)

LEVEL 4

(HTTP server...)

LEVEL 5

(GAMs & DDB, Message Handling, State Machine)

O.S.(Linux,RTAI,Win32..)

LEVEL 6

(Matrix operations, f i l ters...)

Figura A.1: Divisione in livelli della BaseLib2.

tutti i bug incontrati in un qualsiasi livello seguente sarebbero stati da imputare

solamente a quest’ultimo2.

Ai sette livelli di cui sopra ne va aggiunto un ottavo nella versione delle BaseLib2

per Linux-RTAI: cio e giustificato dalla maggiore complessita del porting sotto tale

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

2Si tratta, ovviamente, di una semplificazione: e possibile trovare bug non immediatamente evi-denti, ma che si palesavano con l’uso delle classi fornite da un livello da parte dei livelli seguenti.Tuttavia risulta evidente come la probabilita di un tale errore sia decisamente piu bassa rispetto aquella che si avrebbe mantenendo la libreria senza livelli.

80

APP. A La BaseLib2 A.3 Le classi fondamentali

ve “portarsi dietro” tutto il bagaglio di cast dinamico delle classi e delle funzionalita

proprie del C++3.

A.3 Le classi fondamentali

Capire il funzionamento di una libreria complessa come la BaseLib2 richiede uno

sforzo notevole: i numerosi concetti introdotti arrivano, in alcuni casi, a modificare

totalmente lo stile di programmazione “classico” del C++. Tuttavia, una volta acqui-

sita familiarita con i suoi meccanismi, ci si rende facilmente conto della mole di lavoro

che la libreria permette di risparmiare. Quello che ci si propone di fare in questa

sezione e fornire una visione d’insieme sulle “colonne portanti” di questa monolitica

libreria software.

A.3.1 Un antenato comune: la classe Object

Una parte (attorno al 20 %) degli oggetti della BaseLib2 ereditano in qualche modo

dalla classe Object, implementata nel secondo livello (Level1 ). Il compito assolto da

tale classe (oltre quello di garantire un padre comune a vari oggetti, al fine di poter

effettuare cast dinamici) e fondamentalmente quello di permettere una forma di in-

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

“conoscere se stessa”. In altri termini, ogni classe derivante da Object e in grado di

conoscere il proprio nome, la versione, il numero di istanze allocate dinamicamente

3Il sistema di compilazione dei moduli del kernel Linux, infatti, prevede l’uso solamente del Cclassico. A tutti gli effetti l’uso del C++ e una grossa forzatura al sistema, forzatura resa necessariae desiderabile data la potenza della programmazione orientata agli oggetti e della BaseLib2 stessa.Il tempo speso a far funzionare il C++ in kernelspace e stato ampiamente ripagato dal tempoguadagnato nel poter riutilizzare seduta stante tutti i software gia scritti.

81


(i.e. usando gli operatori new e delete) e altre caratteristiche interne.

L’introspezione, assieme ad un sistema di database interno per le classi ed i re-

lativi nomi, e uno dei maggiori punti di forza della BaseLib2 in quanto permette la

creazione di oggetti per nome. E possibile, cioe, creare a runtime un nuovo oggetto

“indirettamente”, semplicemente indicando il nome della relativa classe.

A.3.2 Garbage Collector

Un evidente problema legato alla creazione di oggetti a runtime e quello della lo-

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

di distruggerlo quando esso non e piu necessario, vi e la possibilita, a lungo anda-

re, di generare dei problemi di memoria man mano che essa si riempie di oggetti

“spazzatura”.

Uno dei principi fondamentali della BaseLib2 e quello di limitare gli “errori uma-

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

A tal fine e stato implementato un sistema di garbage collection (concetto preso in

prestito da Java) che si preoccupa al posto dell’utente di cancellare gli oggetti non

piu usati.

Per garantire questa funzionalita ad un oggetto e sufficiente farlo derivare da

GarbageCollectable. Questa classe non fa altro che aggiungere un sistema che con-

teggia i riferimenti all’oggetto stesso esistenti. In questo modo, qualora l’eliminazione

di un riferimento porti tale conteggio a zero, la classe provvedera ad “autodistrugger-

si”, liberando memoria. Si noti come tale sistema sia estremamente efficace dal punto

di vista delle prestazioni: l’unico codice aggiunto al proprio oggetto e in pratica quello

82


necessario ad incrementare o decrementare il contatore, ed influenza per giunta solo

la costruzione, distruzione e copia degli oggetti.

A.3.3 Named Objects

Una specializzazione della classe Object e quella dei Named Object, concetto preso

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

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

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

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

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

di cui si trattera in seguito nel capitolo apposito.

Per comodita dell’utente finale, le proprieta di GarbageCollectable e di Named

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

erediti da essa si vedra garantite tutte le caratteristiche di cui sopra (si confronti la

prima parte del diagramma di collaborazione di figura A.3).

A.3.4 GCReference e GCReferenceContainer

Per finire la panoramica sugli oggetti fondamentali che compongono la BaseLib2 ri-

mangono da citare gli oggetti di tipo GCReference e GCReferenceContainer, rappre-

sentanti, rispettivamente, il riferimento ad un qualsiasi oggetto di tipo GCNamedObject,

ed un contenitore di riferimenti.

Una qualsiasi classe che erediti da GCReferenceContainer acquista automati-

83


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

ma e possibile implementare in maniera estremamente semplice relazioni tra oggetti

rappresentabili come strutture ad albero.

Si consideri, ad esempio, il caso di un server web: immaginando di avere due ogget-

ti, Server e WebPage, rappresentanti rispettivamente il server stesso ed una singola pa-

gina, trasformando in contenitore i due oggetti facendoli ereditare da GCReferenceContainer,

sarebbe possibile aggiungere e togliere pagine dinamicamente semplicemente aggiun-

gendo (i.e. “creando per nome”) oggetti di tipo WebPage e inserendoli nel contenitore

Server per pagine di primo livello, o in un’altra WebPage per creare collegamenti tra

pagine (figura A.2)4.

SERVER

WEBPAGE WEBPAGE WEBPAGE

WEBPAGE WEBPAGE WEBPAGE

Figura A.2: Esempio di utilizzo delle classi GCReference e GCReferenceContainer

per implementare un server web.

Una volta generata questa struttura, l’oggetto Server non deve fare altro che

spostarsi tra le varie pagine, secondo le richieste effettuate dal browser, “navigando”

nella propria struttura ad albero, il tutto con pochissime righe di codice.

A.3.5 Vista d’insieme

Il grafico di collaborazione tra i vari oggetti citati sinora e riportato in figura A.3, con

evidenziati gli oggetti piu importanti.

4Un sistema simile e effettivamente utilizzato dal server web fornito dalla BaseLib2.

84


Ob

jec

tG

arb

ag

eC

oll

ec

tab

le

GC

Na

me

dO

bje

ct

GC

Re

fere

nce

Co

nta

ine

r

Lin

ked

Lis

tHo

lde

r

Lin

ked

Lis

tab

le

GC

RC

Ite

m

GC

RC

IBa

sic

GC

RC

ILin

k

GC

Re

fere

nce

gc

ob

jec

tPo

inte

r

lis

t

llh

roo

tn

ex

t

Fig

ura

A.3

:Sch

ema

UM

Ldeg

liog

gett

idibas

edel

laBas

eLib

2.

Le

frec

ceco

ntr

ato

conti

nuo

indic

ano

ered

itar

ieta

,quel

letr

atte

ggia

tel’uti

lizz

o(i

nco

rsiv

oe

spec

ifica

toil

nom

edel

lava

riab

ile

usa

ta).

Ire

ttan

goli

con

spes

sore

dop

pio

indic

ano

lecl

assi

piu

impor

tanti

.

85


A.3.6 Il CDB - Configuration DataBase

Come visto sinora, sfruttando i potenti meccanismi di creazione per nome, garbage

collection e contenimento di riferimenti della BaseLib2, risulta semplice modificare

profondamente la struttura di un’applicazione a runtime. Il CDB e un’esasperazione

di questa idea.

Un CDB e sostanzialmente l’unione di un database interno alla BaseLib2 con un

codice di programmazione minimale che permetta di descrivere oggetti da creare e le

relative proprieta. Un esempio di tale sintassi e mostrato nel listato A.1. Si osservi

come la sintassi usata sia di tipo “C-like”, dove i parametri di ogni elemento sono

racchiusi tra coppie di parentesi graffe.

In particolare si notino, all’interno del codice, le varie occorrenze della parola chia-

ve Class, che indica al CDB il nome della classe di cui si desidera creare un’istanza, e

la configurazione della classe stessa, che avviene all’interno delle due parentesi graffe

principali. Nel caso in esame la classe StateMachine (rappresentante, come dice il

nome stesso, una macchina a stati) e programmata in modo da prevedere piu stati

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

vedere piu eventi (StateMachineEvent).

Il CDB puo essere generato a partire da un qualsiasi oggetto utilizzabile come

stream, sia esso una stringa in memoria, un file o i dati provenienti da un socket.

86


Listato A.1: Esempio di file di configurazione (da TestStateMachine.cpp).

1 Class = StateMachine2 VerboseLevel = 23 +IDLE=4 Class = StateMachineState5 +TEST=6 Class = StateMachineEvent7 Code = 18 NextState = ACTIVE9 +NOTIFY=

10 Class = MessageEnvelope11 Destination = \"SENDERS.XOBJECT\"12 +MESSAGE= 13 Class = Message14 Code = 115 16 17 18 19 +ACTIVE=20 Class = StateMachineState21 +RESET=22 Class = StateMachineEvent23 Code = 124 NextState = IDLE25 +NOTIFY=26 Class = MessageDeliveryRequest27 Destinations = \"SENDERS.YOBJECT,SENDERS.ZOBJECT\"28 Message= 29 Class = Message30 Code = 131 32 33 34

87

APP. A La BaseLib2 A.4 Comunicazione tra oggetti

A.4 Comunicazione tra oggetti

Uno dei principi portanti della programmazione orientata agli oggetti e la possibilita di

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

di metodi e proprieta esposti da un oggetto.

La BaseLib2 stravolge questo concetto introducendo i messaggi, mutuati anch’es-

si da Smalltalk. Tale tecnica consiste nel permettere agli oggetti di comunicare tra di

loro inviandosi informazioni5, delegando il compito di recapitare il messaggio corretto

alla corretta destinazione ad un thread di gestione indipendente (un esempio di fun-

zionamento e raffigurato in figura A.4).

A

B

MessageQueue= = M e s s a g e 1 = == = M e s s a g e 2 = =

...==Message N==

MessageHandlerThread

SendMessage HandleMessage

ProcessMessage

Figura A.4: Schema di funzionamento della gestione dei messaggi nelle BaseLib2.

Affinche un oggetto possa far uso di questo meccanismo, esso deve ereditare dalla

classe MessageHandler e ridefinire il metodo virtuale ProcessMessage. Tale me-

todo prende come parametro un oggetto di tipo GCRTemplate<MessageEnvelope>6

che rappresenta la “busta da lettere” contenente il messaggio spedito all’oggetto.

Un MessageEnvelope possiede come parametri due stringhe che indicano il nome di

5Dove, per “informazioni” si intende qualsiasi tipo di variabile, struttura o persino classe.6GCRTemplate e un template che fornisce alla classe indicata le proprieta di garbage collection.

Ogni messaggio deve necessariamente avere tale caratteristica in quanto, altrimenti, si correrebbe ilrischio di riempire la memoria di “oggetti messaggio” non piu usati.

88

APP. A La BaseLib2 A.4 Comunicazione tra oggetti

mittente e destinatario, e il metodo GetMessage che restituisce un oggetto di tipo

Message, ovvero il messaggio vero e proprio.

Per inviare un messaggio, invece, e sufficiente istanziare un oggetto di tipo Message

ed inserirlo in una MessageEnvelope usando il metodo PrepareMessageEnvelope e

indicando la destinazione. Invocando quindi la funzione MessageHandler::SendMessage()

il messaggio verra inviato.

Si noti come il meccanismo di scambio messaggi permetta di creare strutture di og-

getti estremamente complesse, laddove l’uso di contenitori di riferimenti puo garantire

solo un metodo di comunicazione padre-figlio: il sistema delle macchine a stati (og-

getto StateMachine), ad esempio, fondamentale per MARTe, usa abbondantemente

questo meccanismo per segnalare transizioni di stato ed errori.

89

Appendice B

Distribuzione Linux usata al JET

In questa appendice viene illustrato a grandi linee il processo che haportato alla creazione della distribuzione Linux Gentoo-based (an-che nella sua incarnazione Live) che e poi stata usata come piat-taforma di testing e development al JET. Vengono riportati solo ipassaggi chiave, limitando il numero di comandi Linux al minimoindispensabile e rinviando, per una guida piu completa e dettagliata,ai siti web segnalati nell’introduzione.

B.1 Introduzione

La scelta della distribuzione Linux da usare per far girare il sistema di controllo del

JET e stata piuttosto importante. Tra le varie distribuzioni candidate (tra cui la

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

personalizzabilita e stabilita, ma anche dell’ottimo supporto tecnico fornito dalla co-

munita. Inoltre il fatto di poter preparare il sistema partendo quasi da zero (o “da

stage 1” nel gergo di Gentoo) ha permesso di installare solo lo stretto necessario,

ottenendo un sistema snello e veloce, capace di mantenere tutte le sue funzionalita in

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

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

90

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

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

salienti e le difficolta incontrate, delle guide pubblicate sul wiki mantenuto dal gruppo

di controllo del plasma agli indirizzi:

http://fusion-rt.sourceforge.net/wiki/Installing_Gentoo_from_Stage1

http://fusion-rt.sourceforge.net/wiki/Creating_a_Gentoo_LiveCD/LiveUSB

B.2 Installazione di Gentoo

Avvio dal LiveCD

Dopo aver scaricato e masterizzato il LiveCD di Gentoo 2007.1, si e proceduto a

riavviare il sistema effettuando il boot da CD. Il LiveCD e progettato per effettuare il

boot della macchina lasciando l’utente in un ambiente “temporaneo” da cui effettuare

tutte le operazioni necessarie all’installazione del sistema.

Per la sua natura “tecnica”, Gentoo non prevede un installer grafico, lasciando

all’utente l’obbligo di compiere tutti i passi normalmente compiuti da quest’ultimo,

quali, as esempio, il partizionamento dell’hard disk o la configurazione di base del

sistema.

Partizionamento

Il partizionamento del disco per l’installazione del sistema e stato effettuato, usando

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

particolare si e provveduto a creare una partizione per il sistema di base di circa 2 GB

(abbastanza grande da consentire “spazio di manovra”, ma non eccessiva considerato

il fatto di non dover installare un ambiente grafico) e una partizione di swap della

91


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

sviluppo.

Il filesystem usato e l’ext3, sia per la sua diffusione e provata stabilita, sia per

evitare qualsiasi forma di problema con i vari bootloader presenti.

Installazione del sistema di base

La procedura di installazione di Gentoo partendo da “Stage 1” risulta essere piuttosto

lunga e laboriosa, sebbene favorita dall’uso di numerosi script costruiti ad hoc dal

team di sviluppo della distribuzione. La difficolta del processo risulta essere ancora

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

piu supportata nella documentazione ufficiale di Gentoo. Di conseguenza e stato

necessario procedere passo-passo, cercando nella rete informazioni sui passi piu oscuri

e/o mancanti.

Dopo aver partizionato i dischi e montato i vari filesystem all’interno dell’ambiente

“virtuale” fornito dal CD di installazione, si e provveduto a scaricare e decomprimere

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

questo punto e stato effettuato il processo di bootstrap di Gentoo, che sostanzialmen-

te consiste nella creazione dell’ambiente di base necessario al buon funzionamento

della distribuzione (i.e. compilazione di GCC, perl e python, creazione dei file di

configurazione di base...).

Completato il (lungo) processo di bootstrap, si e passati alla configurazione del

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

1emerge e il comando che permette di lavorare con portage, il sistema di gestione pacchetti diGentoo, che automatizza il processo di scaricare dalla rete, compilare ed installare il software.

92


Compilazione del kernel

La parte piu complessa del lavoro e stata, senza dubbio alcuno, quella di configurare

il kernel della macchina. L’idea di base e stata quella di costruire un sistema il piu

possibile snello, sia per garantire la massima efficienza, sia per eliminare quanto piu

possibile codice “inutile” dalla memoria, al fine di limitare possibili conflitti tra i

moduli del kernel, RTAI e i thread realtime.

A tal fine si e provveduto ad abilitare come elementi statici del kernel tutti e solo

i driver delle periferiche presenti effettivamente nella macchina, cosa che ha garantito

un insieme minimale di funzionalita e tempi di compilazione decisamente ridotti, ma

che e andata contro la portabilita del kernel stesso. Tuttavia si noti che, in effetti,

l’architettura finale su cui dovra funzionare Linux-RTAI e ben determinata e non

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

piu del cambiare alcune opzioni nella configurazione del kernel, e una ricompilazione

dello stesso.

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

nere un kernel con le funzionalita realtime necessarie.

Completamento dell’installazione

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

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

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

di editing minimali, CVS e i tool per gestire le partizioni di rete NFS).

93

APP. B Distribuzione Linux usata al JET B.3 Costruzione di un LiveCD/LiveUSB

B.3 Costruzione di un LiveCD/LiveUSB

Un’ulteriore operazione effettuata e stata quella di costruire una distribuzione Live2

a partire dall’installazione di Gentoo appena completata.

Si e scelto di effettuare tale procedimento in modo da ottenere un sistema opera-

tivo “portatile” con cui avviare la macchina in caso di problemi, facilitando di molto

le operazioni di primo avvio e di ripristino. Inoltre si e pensato di mantenere que-

sta soluzione in caso di espansioni future dell’accoppiata Linux/RTAI come sistema

operativo realtime “ufficiale” del JET: molte postazioni, infatti, richiedono software

funzionante in realtime pur non essendo “critiche” per il buon funzionamento della

macchina. Poter avviare tali macchine utilizzando un unico LiveCD uguale per tutti

e sembrato estremamente vantaggioso.

Riduzione dello spazio occupato

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

LiveCD/LiveUSB e quella di ridurre il piu possibile lo spazio occupato, limitato dalla

dimensione massima del CD o della penna USB usata.

A tal fine si e provveduto a rimuovere tutte le funzionalita non necessarie, quali il

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

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

le directory contenenti le sorgenti del kernel e di RTAI.

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

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

2Per “distribuzione Live” si intende una distribuzione Linux capace di avviarsi direttamente daCD o da penna USB senza richiedere l’installazione su Hard Disk.

94

APP. B Distribuzione Linux usata al JET B.4 Avvio del sistema da rete

stato quindi necessario applicare un’ulteriore patch oltre a quella di RTAI.

Creazione del LiveCD/LiveUSB

Una volta costruita e compressa con SquashFS la directory contenente la “copia ri-

dotta” di Gentoo, si e proceduto a creare l’immagine ISO del LiveCD. La procedura,

piuttosto semplice, consiste nel fornire a mkisofs, oltre ai fila da masterizzare sul

CD, anche l’immagine di un bootloader. Fortunatamente grub prevede gia questa

possibilita e fornisce un’immagine per CD pronta all’uso.

Viceversa, nel caso della LiveUSB, la procedura e stata leggermente piu semplice:

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

sufficiente installare su di essa grub. L’unico problema e stato causato dalla lentezza

con cui il kernel Linux riconosce le periferiche USB, lentezza che ha portato al dover

inserire artificialmente delle pause all’interno degli script di boot della LiveUSB per

dare tempo al kernel di caricare i driver necessari.

B.4 Avvio del sistema da rete

L’ultimo passo nella preparazione del sistema e stato quello di effettuare il boot della

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

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

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

soggetto a periodici backup.

La tecnologia che ha permesso cio e detta PXE (Preboot eXecution Environment).

95

APP. B Distribuzione Linux usata al JET B.4 Avvio del sistema da rete

PXE Client

PXE DHCP Request

DHCPServer

Boot server IP

BootServer

Kernel request (TFTP)

KERNEL IMAGE

Figura B.1: Principio di funzionamento dell’avvio via PXE.

Tale sistema, fortunatamente gia incorporato nella scheda di rete presente nella mac-

china, e illustrato nella figura B.1: PXE crea un ambiente di boot che, lanciando

richieste DHCP, ricerca un boot server da cui scaricare, via TFTP3, l’immagine del

kernel da avviare, proseguendo poi nel normale processo di boot di Linux.

L’implementazione di tale sistema ha richiesto uno sforzo minimale: e stato suffi-

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

“indirizzasse” la macchina nella sala di controllo verso il corretto server di boot, ed

indicare nei parametri del kernel dove trovare la partizione NFS da montare come

root.

3TFTP e una versione “leggera” del classico protocollo FTP.

96

Appendice C

Specifiche hardware

In questa appendice vengono brevemente riassunte le specifiche tec-niche dell’hardware attualmente usato al JET per la stabilizzazioneverticale del plasma.

C.1 Introduzione

La scelta della piattaforma hardware su cui far girare il controllore per la stabilizza-

zione verticale e, ovviamente, una delle piu importanti e delicate. Ottenere un buon

compromesso tra costi, scalabilita, robustezza e velocita non e cosa semplice.

Secondo le specifiche, il nuovo controllore richiede fino a 50 segnali in ingresso

e un ritardo massimo nel loop di controllo di 50 µs, con la speranza di ridurlo a

soli 10 µs. Tale tempo di ritardo e dovuto fondamentalmente a due fattori, ovvero

il tempo di calcolo dell’algoritmo vero e proprio, e i tempi di acquisizione segnali e

attraversamento dei circuiti. La scelta della piattaforma hardware e stata fatta in

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

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

possibilita di costruire sistemi multiprocessore. A tal fine si e scelto di far uso dello

97

APP. C Specifiche hardware C.2 Lo standard ATCA

standard ATCA.

C.2 Lo standard ATCA

Lo standard ATCA (Advanced Telecommunications Computing Architecture) e uno

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

un consorzio internazionale composto da piu di 400 societa. Scopo dello standard e

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

ra. I principali punti di forza di questo standard sono la velocita di comunicazione

tra gli elementi del crate (figura C.1), e il fatto di essere pensato per garantire un

elevatissimo tempo di funzionamento, grazie ai sistemi di alimentazione ridondante

e alla possibilita di inserire nello stesso crate il doppio delle schede necessarie, in

modo che il sistema possa passare, in caso di malfunzionamenti, da un set all’altro

in maniera trasparente. Viene inoltre garantita la possibilita di collegare e scollega-

re schede “a caldo”, ovvero senza richiedere il preventivo spegnimento della macchina.

Lo standard ATCA definisce un crate di dimensioni ben precise (figure C.2 e C.3),

e una serie di interconnessioni, nel lato posteriore, seriali e con banda di un gigabit.

Il protocollo di comunicazione non e specificato a priori, e nel caso del JET si e scelto

di usare la tecnologia PCI Express.

C.3 Il controllore ATCA

Il controllore ATCA, il cui schema logico e riportato in figura C.4, e implementato su

una scheda madre ATX (assemblata in modo da raggiungere le dimensioni specificate

98

APP. C Specifiche hardware C.4 Le schede DGP

Figura C.1: Schema delle connessioni interne al crate secondo lo standard ATCA.

dallo standard) collegata al crate ATCA attraverso un connettore PCI Express x16,

ed usa un processore standard x86, nel caso del JET un Intel Quad Core.

La cosa piu evidente della soluzione proposta e il bassissimo costo derivante dal-

l’utilizzo di architetture standard e di processori general-purpose.

C.4 Le schede DGP

Il crate ATCA permette l’inserimento di fino a 12 schede DGP (Digitizer-Generator-

Processor), ciascuna delle quali comprende porte I/O digitali e analogiche, un con-

trollore FPGA (Field-Programmable Gate Array), una porta per clock esterno e due

link in fibra ottica Aurora da 2.5Gbit. In particolare questi collegamenti garantisco-

99

APP. C Specifiche hardware C.4 Le schede DGP

Figura C.2: Il crate ATCA.Figura C.3: Dimensioni del crate ATCA.

Figura C.4: Schema logico del controllore ATCA.

no la possibilita agli FPGA di comunicare tra loro e addirittura di poter accedere

in ogni istante ai dati acquisiti da una qualsiasi altra scheda come fossero stati cat-

turati dalla stessa scheda dove l’unita risiede. Cio permette un’esecuzione parallela

particolarmente adatta al processamento di segnali per sistemi MIMO.

Questa proprieta, insieme alla capacita degli FPGA di funzionare indipendente-

mente dalla scheda di controllo, garantisce la possibilita di elaborare segnali saltando

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

100

APP. C Specifiche hardware C.5 Prestazioni

compiti di filtraggio agli FPGA, scaricando di molto le responsabilita della CPU.

C.5 Prestazioni

Previsioni e test effettuati in laboratorio hanno mostrato le buone prestazioni di questa

architettura relativamente ai tempi di attraversamento.

In particolare, proprio ai fini di quanto richiesto dal JET, sono stati pensati due

scenari: il primo prevede il passaggio di segnali attraverso la scheda controllore, mentre

il secondo l’uso delle sole FPGA. I tempi calcolati sono risultati essere all’incirca pari,

rispettivamente, a 1.7µs e 0.7µs, indicando come effettivo collo di bottiglia del sistema

il canale PCI express. Si noti come l’accoppiata di una CPU veloce e dell’architettura

ATCA abbia buone possibilita di ridurre effettivamente il ritardo del loop di controllo

anche al di sotto dei 10µs.

101

Elenco delle figure

1.1 Diagramma della reazione di fusione nucleare. . . . . . . . . . . . . . 6

1.2 Rappresentazione di avvolgimenti e campi toroidale e poloidale. . . . 8

1.3 Interno della camera vuoto del JET. . . . . . . . . . . . . . . . . . . 11

1.4 Posizione delle bobine poloidali del JET. . . . . . . . . . . . . . . . . 12

1.5 Struttura meccanica di ITER. . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Caduta della corrente di plasma in dipendenza dalla distanza dall’asse

del toro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Misura della triangolarita di un plasma. . . . . . . . . . . . . . . . . . 17

2.3 Instabilita verticale del plasma. . . . . . . . . . . . . . . . . . . . . . 18

2.4 Esempio di Mirnov coil. . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Posizione su un ottante dei sensori di misura del campo magnetico. . 22

2.6 Pesi per i vari sensori magnetici, come da modifica dopo l’inserimento

del divertore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 Schema generale dell’algoritmo per la stabilizzazione verticale del plasma. 25

2.8 Andamento ad isteresi di FRFA. . . . . . . . . . . . . . . . . . . . . . 29

2.9 Schema elettrico di FRFA. . . . . . . . . . . . . . . . . . . . . . . . . 30

2.10 Esempi di N-modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.11 Struttura del plasma in H-mode. . . . . . . . . . . . . . . . . . . . . 35

102

ELENCO DELLE FIGURE ELENCO DELLE FIGURE

3.1 Passaggio da uno schema a blocchi alla struttura a GAM. . . . . . . . 42

3.2 Interazione tra MARTe, hardware e sistemi esterni. . . . . . . . . . . 50

3.3 Schema di funzionamento di Linux senza le patch di RTAI. . . . . . . 54

3.4 Comportamento del sistema modificato da RTAI. . . . . . . . . . . . 55

3.5 Confronto tra la latenza di thread in kernelspace ed in userspace (LXRT). 58

3.6 Architettura di FCOMM. . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.7 Diagramma di flusso di call remote function. . . . . . . . . . . . . 63

3.8 Diagramma di flusso della componente userspace di FCOMM. . . . . 64

3.9 Screenshot della console RTAI in azione. . . . . . . . . . . . . . . . . 69

A.1 Divisione in livelli della BaseLib2. . . . . . . . . . . . . . . . . . . . . 80

A.2 Esempio di utilizzo delle classi GCReference e GCReferenceContainer

per implementare un server web. . . . . . . . . . . . . . . . . . . . . . 84

A.3 Schema gerarchico degli oggetti di base della BaseLib2. . . . . . . . . 85

A.4 Schema di funzionamento della gestione dei messaggi nelle BaseLib2. 88

B.1 Principio di funzionamento dell’avvio via PXE. . . . . . . . . . . . . 96

C.1 Schema delle connessioni interne al crate secondo lo standard ATCA. 99

C.2 Il crate ATCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

C.3 Dimensioni del crate ATCA. . . . . . . . . . . . . . . . . . . . . . . . 100

C.4 Schema logico del controllore ATCA. . . . . . . . . . . . . . . . . . . 100

103

Bibliografia

[1] J. Wesson, The Science of Jet, JET Publication (Culham, Oxford), 2000.

[2] J. Wesson, Tokamaks, Clarendon Press (Oxford), 2004.

[3] G. De Tommasi, F. Piccolo, A. Pironti, F. Sartori, A flexible software for real-time

control in nuclear fusion experiments, Elsevier, Control Engineering Practice 14

(2006), pp. 1387-1393.

[4] A. Pironti, M. Walker, Control of Tokamak Plasmas, IEEE Control System

Magazine, October 2005, pp. 24-29.

[5] A. Pironti, M. Walker, Fusion, Tokamaks, and Plasma Control, IEEE Control

System Magazine, October 2005, pp. 25-43.

[6] A. Beghi, A. Cenedese, Advances in Real-Time Plasma Boundary Reconstruction,

IEEE Control System Magazine, October 2005, pp. 44-64.

[7] M. Ariola, A. Pironti, Plasma Shape Control for the JET Tokamak, IEEE Control

System Magazine, October 2005, pp. 65-75.

[8] G. Ambrosino, R. Albanese, Magnetic Control of Plasma Current, Position, and

Shape in Tokamaks, IEEE Control System Magazine, October 2005, pp. 76-91.

104

BIBLIOGRAFIA BIBLIOGRAFIA

[9] A. Pironti, M. Walker, Control of Tokamak Plasmas Part II, IEEE Control System

Magazine, April 2006, pp. 30-34.

[10] M.L. Walker, D.A. Humphreys, D. Manzon, D. Moreau, M. Okabayashi, T.H.

Osborne, E. Schuster, Emerging Applications in Tokamak Plasma Control, IEEE

Control System Magazine, April 2006, pp. 35-63.

[11] F. Sartori, G. De Tommasi, F. Piccolo, The Joint European Torus, IEEE Control

System Magazine, April 2006, pp. 64-78.

[12] JO B. Lister, A. Portone, Y. Gribov, Plasma Control in ITER, IEEE Control

System Magazine, April 2006, pp. 79-91.

[13] V. D. Shafranov, L. E. Zakharov, Equilibrium of toroidal plasma with no circular

cross section, Sov. Phys. Tech, 1973, vol.18, pp. 151-156.

[14] A. Barbalace, A. Neto, F. Sartori, F. Piccolo, Realtime Application Interface

Characterization on x86 Platforms, (unsubmitted).

[15] A. Barbalace, Porting e valutazione delle prestazioni di un ambiente per applica-

zioni di controllo hard Real-Time da VxWorks a Linux-RTAI/Xenomai-RTnet su

architettura PowerPC, Thesis, 2007.

[16] F. Piccolo, JET Vertical Stabilization System: Modelling and Control, PHD

Thesis, 2007.

105

architettura basata su linux rtai per la stabilizzazione verticale del joint european torus

Documents