visualizza

4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Distributed Maintenance Training Infrastructure
Simulazione real-time su piattaforma distribuita
Maurizio Fuschetto
Societa’ Italiana Avionica, SIA SpA, Strada Antica di Collegno 253 – 10146 Torino - Italy
[email protected]
FabioBello
Societa’ Italiana Avionica, SIA SpA, Strada Antica di Collegno 253 – 10146 Torino - Italy
[email protected]
ABSTRACT
Il settore della difesa è uno dei campi in cui l'evoluzione tecnologica gioca un ruolo fondamentale:
difatti solo utilizzando nuove tecnologie si possono ottenere strumenti e sistemi sempre più
sofisticati che consentano, ad esempio, un'efficace contromisura ad eventi ostili.
Conseguentemente, questi sistemi di elevata complessità impongono un adeguato addestramento
professionale non solo per gli utilizzatori, ma anche per gli addetti alla manutenzione.
Affiché l’addestramento risulti maggiormente efficace, vi è la necessità di organizzare sessioni di
esercitazioni pratiche, durante le quali gli aspiranti manutentori possano operare sulla
componentistica originale con tutti i problemi ed i rischi logistici ed economici che ciò comporta.
Per questo motivo negli ultimi anni sono nati diversi sistemi di simulazione CBT (Computer Based
Training) per la manutenzione di sistemi complessi: dapprima i simulatori sono stati realizzati ad
hoc per specifiche unità; in seguito sono stati sviluppati dei framework che consentono di
realizzare la simulazione di un qualsivoglia sistema.
Questi framework di simulazione basati su PC, pur supportando un addestramento congiunto di più
allievi, hanno spesso il limite di concentrare il carico elaborativo su un'unica macchina; ciò crea
notevoli problematiche di scalabilità al crescere della complessita’ del modello di simulazione,
determinando una drastica diminuzione delle prestazioni. Inoltre, sono spesso dotati di GUI basate
su grafica 2D, il che limita, in alcuni casi, il realismo della rappresentazione e la libertà
d’ispezione dell’allievo manutentore.
SIA, sfruttando il know-how maturato in oltre trent'anni di attività nel settore aeronautico ed
avionico e, più di recente, nella produzione di materiale di training, ha compiuto un'attività di
ricerca e sviluppo in questo senso.
L'obiettivo è stato quello di realizzare un “motore” distribuito e scalabile per la simulazione
finalizzata all'addestramento del personale addetto alla manutenzione e che offrisse, ove
necessario, anche un ambiente GUI in realtà virtuale (tridimensionale), alternativo alla GUI bidimensionale.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Questo paper si propone, quindi, di descrivere brevemente l’architettura e la tecnologia alla base
del prodotto di SIA, per poi soffermarsi sulla presentazione dei risultati della sperimentazione
effettuata su un sistema campione.
Introduzione
Da molti anni, ormai, la simulazione ha assunto un ruolo insostituibile nel mondo aeronautico. Si
può dire che oggi tutto il ciclo di vita di un velivolo viene riprodotto con i simulatori: dalla
progettazione di un velivolo all’addestramento dei piloti.
In periodi più recenti, soprattutto a causa della crescente complessità dei velivoli e dei relativi
sistemi di bordo, nel mondo aeronautico la simulazione ha iniziato a giocare un ruolo importante
anche nel settore dell’addestramento dei manutentori dei velivoli come affiancamento ai corsi in
aula con istruttore ed alle sessioni CBT (computer based training).
L’impiego di questa soluzione tecnologica offre innumerevoli vantaggi in termini di qualità della
formazione ed al contempo mantiene minimi gli impegni economici e logistici.
Vantaggi logistici
Per tenere una sessione di esercitazione sul velivolo reale è necessario disporre di un velivolo su cui
operare, avere un hangar attrezzato e condurre allievi ed istruttore sul posto.
Bisogna anche mettere in conto il rischio che, durante l’esercitazione, un allievo “distratto” causi
danni ad apparecchiature di bordo o strumentazione diagnostica.
Inoltre, realisticamente, un istruttore difficilmente potrà seguire l’attività simultanea di più allievi
dando origine, così, ad un collo di bottiglia.
In una singola giornata di attività si potrà ottenere l’esercitazione di un unico allievo su un’attività
complessa, oppure di dieci allievi a turno su un’attività semplice. È evidente che l’efficacia di una
sessione simile è molto bassa.
Al simulatore, invece, è sufficiente un’aula multimediale per consentire l’esercitazione simultanea
di numerosi allievi anche con un unico istruttore: non bisogna attendere la disponibilità di un aereo
e neppure di un hangar.
Se poi si pensa alle tecnologie oggi ampiamente disponibili, come Internet, si ha che gli allievi
possono essere dislocati anche a chilometri di distanza, ciascuno nel proprio ufficio, se non
comodamente seduto nella poltrona di casa, mentre partecipano insieme alla medesima
esercitazione.
L’istruttore, dotato di una propria postazione di lavoro, può seguire l’attività di tutti gli allievi
passando rapidamente da una parte all’altra del velivolo virtuale e può eventualmente registrare e
rivedere le sequenze di particolare interesse. Può anche indurre tipologie di guasto che sul velivolo
reale non sarebbero riproducibili se non al prezzo di danneggiarne i componenti!
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Trattandosi di un’esercitazione simulata, inoltre, è annullato il rischio di eventuali danni materiali
prodotti dagli allievi, così come di infortuni degli stessi.
Vantaggi economici
Impegnare un velivolo ed un hangar per un’esercitazione ha un certo costo, a cui si aggiungono le
spese da sostenere in caso di eventuali danni o di infortuni.
Impiantare una sala multimediale in grado di offrire tutti i vantaggi accennati, invece, ha un costo
ampiamente inferiore al solo hangar, quindi senza contare il velivolo.
C’è anche da considerare che, poiché il simulatore consente di eseguire un addestramento molto
dettagliato e molto intensivo ad un costo contenuto, i tecnici maturano una maggiore efficacia nella
successiva attività lavorativa, riducendo così i tempi d’intervento, e di conseguenza i costi,
nell’individuazione e risoluzione dei guasti a bordo del velivolo reale.
Vantaggi qualitativi
Una sala multimediale dedicata all’addestramento offre un netto incremento in termini di
disponibilità del “banco di esercitazione”. Ciò consente di aumentare proporzionalmente l’offerta di
ore di addestramento per un dato velivolo ottenendo un’indubbia positiva ricaduta sull’efficacia dei
tecnici.
Certo che, così come a nessuno viene rilasciata la patente di pilota aereo solo perché ha “volato” per
alcune centinaia o migliaia di ore con un simulatore di volo, un tecnico non potrà sostituire
totalmente l’addestramento sul velivolo reale con quello virtuale.
Il simulatore, però, favorisce indubbiamente l’apprendimento delle procedure. Una volta che lo
studente ha familiarizzato con la sequenza di operazioni da compiere, tanto da eseguirla senza
necessità di consultare i manuali tecnici, saranno sufficienti solo poche sessioni sul velivolo reale
per completare il percorso formativo.
Caratteristiche di un simulatore
Vediamo ora alcune delle caratteristiche da tenere in considerazione nella valutazione di un
simulatore finalizzato all’addestramento del personale di manutenzione.
Adattabilità
I primi simulatori per la manutenzione presentati sul mercato sono stati sviluppati ad hoc per
specifici aerei e, nella maggioranza dei casi, internamente ad aziende costruttrici di velivoli. Questo
tipo di prodotti in genere soffre di mancanza di adattabilità: una volta sviluppato un simulatore
specializzato, risulta molto impegnativo l’adattamento ad un velivolo differente.
Successivamente alcune aziende di software del settore aeronautico hanno sviluppato sistemi più
aperti che offrono la possibilita’ di essere adattati a diverse tipologie di velivolo, ma l’adattabilita’
non e’ stata ancora spinta al punto di ottenere un vero e proprio framework, cioe’ uno strumento che
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
dia la possibilita’ di costruirsi una simulazione personalizzata in completa autonomia per un
qualsiasi velivolo.
In molti casi, infatti, l’infrastruttura di base del simulatore viene realizzata in modo sufficentemente
generico, ma tutti i sistemi critici (come ad esempio i bus di comunicazione digitale) vengono
implementati ad hoc in base alla specifica richiesta.
Sarebbe auspicabile un maggiore sforzo verso lo sviluppo di un sistema pienamente adattabile,
magari in grado di essere personalizzato da aziende completamente estranee al produttore originario
del sistema. In questo modo, il costo di acquisto del simulatore subirebbe un abbattimento
significativo poiché potrebbe essere distribuito in un gran numero di copie ed adattato ai velivoli
più disparati aprendo le porte anche al mercato civile ed eventualmente privato/turistico.
Interfaccia grafica
In un simulatore per l’addestramento è indubbiamente fondamentale ricreare l’ambiente reale in
modo più aderente possibile, eppure a tuttoggi la gran maggioranza di questi sistemi propone
interfacce pseudo-3D che fanno anche uso parziale di riproduzioni fotografiche di sezioni del
velivolo: si tratta comunque di un considerevole passo in avanti rispetto ai primi sistemi che
proponevano riproduzioni poco piu’ che schematiche dei sistemi di bordo.
In ogni caso, anche i sistemi attualmente piu’ curati propongono delle scene staticamente
predeterminate in cui l’allievo vede riprodotta con qualita’ fotografica la parte del velivolo su cui
opera, ma senza la liberta’ di muovere liberamente il punto di vista della scena stessa.
Si tratta in pratica di una scena 2D che rende un effetto pseudo-tridimensionale e che, pertanto, e’
una ricostruzione che approssima la realta’ in modo grossolano: questo tipo di presentazione è
tecnicamente riferita come 2D e ½ .
Anche per un “non addetto ai lavori” risulta evidente il divario, in termini di interfaccia, con lo stato
dell’arte della realtà virtuale. Per fornire un elevato livello di realismo al manutentore è necessario
che il simulatore riproduca la situazione desiderata in una scena realmente tridimensionale.
Un sistema in realta’ virtuale facilita anche il compito di chi realizza le scene della simulazione:
lavorando su un vero modello tridimensionale, l’attenzione del modellista, che è l’addetto alla
personalizzazione del framework in base al velivolo da simulare, è rivolta principalmente alla
riproduzione dei sistemi di bordo. In un ambiente 2D, invece, è necessario pianificare in anticipo le
viste che si intende offrire, poichè la grafica delle bitmap è strettamente legata alle caratteristiche
del punto di vista e dell’illuminazione che si vuol dare alla scena. Modificare il punto di vista o un
qualsiasi altro parametro caratterizzante di una scena 2D comporta la rilavorazione e rigenerazione
di tutte le bitmap coinvolte, mentre con un motore di presentazione in tridimensionale puro si crea
la scena in un’unica fase e si possono modificare successivamente tutte le caratteristiche della scena
senza necessita’ di rilavorare la grafica.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Multiutenza e teledidattica
In un’esercitazione sono coinvolti di solito un istruttore ed uno o piu’ allievi, pertanto e’ di
fondamentale importanza che il simulatore sia in grado di offrire a piu’ utenti la possibilita’ di
partecipare simultaneamente ad una medesima sessione di esercitazione.
Cio’ vuol dire che il sistema deve necessariamente prevedere la cooperazione tra piu’ computer,
poiche’ e’ evidente che ciascuna persona fisica deve essere dotata di una propria stazione di lavoro
per poter operare con la dovuta comodita’.
Sotto questo punto di vista, molti sistemi esistenti consentono l’esercitazione simultanea di piu’
allievi, ma non permettono all’istruttore di intervenire, tramite la propria workstation, in aiuto di un
allievo. Inoltre e’ importante che sia fornita la possibilita’ di avere un gruppo di allievi che operi
sulla medesima istanza di un velivolo simulato, ed anche questa e’ una caratteristica che non sempre
si trova nei prodotti esistenti.
Facendo ancora un passo in avanti, come accennato nell’introduzione l’attuale diffusione di
connessioni Internet favorisce lo sviluppo della teledidattica. Pertanto un sistema di simulazione
moderno non puo’ prescindere dalla possibilita’ di coinvolgere nell’esercitazione uno o piu’
studenti connessi attraverso Internet. Questo e’ un punto molto importante anche per le aziende che
effettuano le esercitazioni, poiche’, grazie alla teledidattica, possono ridurre notevolmente i costi di
trasferta del personale da addestrare.
Scalabilità
Nella realizzazione di un sistema di simulazione aperto non si puo’ non tenere conto di uno dei piu’
importanti parametri: il carico di elaborazione.
Se si realizza un simulatore specializzato e per cui si ha la certezza che nessuna modifica
consistente sara’ mai richiesta, il carico puo’ essere stimato a priori e quindi possono essere
opportunamente dimensionate le macchine destinate a supportare il software.
Ma se l’obiettivo e’ quello di realizzare un framework generico, oppure si sta realizzando un
sistema mirato che, come e’ realmente plausibile, potrebbe essere successivamente esteso, e’
necessario che l’infrastruttura di simulazione sia scalabile, cioe’ estendibile in funzione delle
necessita’ di elaborazione.
Da considerare anche il caso in cui la simulazione da realizzare risulta essere di una complessità tale
da non poter essere stimata con estrema precisione, pertanto è necessario avere un’architettura di
sistema che sia scalabile man mano che il sistema viene costruito ed integrato.
La scalabilita’ puo’ essere ottenuta con accorgimenti nella selezione e progettazione della
sistemistica hardware e/o software, ma è facilmente intuibile che agire sull’hardware comporta
svantaggi enormi in termini di costo e di logistica. Reperire una macchina più veloce di quella
disponibile può essere semplice se si chiedono incrementi di prestazioni dell’ordine del 10-20%. Ma
se il gap da coprire comincia ad assumere proporzioni considerevoli (come, ad esempio, il
raddoppio della potenza di calcolo) è necessario passare ad un livello tecnologico superiore con i
conseguenti incrementi quasi esponenziali dei costi (basti pensare al costo medio di un normale PC,
quello di una workstation RISC e quello di un mainframe). Inoltre le macchine più costose hanno
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
una diffusione minore e di conseguenza una manutenzione più costosa e meno capillare sul
territorio.
Tutte queste considerazioni portano alla conclusione che il software di un sistema di simulazione
ottimale dovrebbe essere in grado di offrire scalabilità basandosi su comuni personal computer, al
più con due processori, per mantenere basso il costo dell’hardware. Ciò è effettivamente possibile
attraverso la realizzazione di un cluster di macchine che si dividono il carico elaborativo.
La soluzione SIA
La SIA è impegnata da molti anni nella relizzazione di materiale formativo nel settore aeronautico e
partecipa anche all’attività modellistica per il Maintenance Simulation Trainer per il velivolo
Eurofighter Typhoon.
Forte dell’esperienza maturata, e dell’osservazione della situazione attuale del mercato, in SIA si è
voluto compiere uno sforzo di ricerca finalizzato alla realizzazione di un framework di simulazione
per l’addestramento dei manutentori, denominato Distributed Maintenance Training Infrastructure
(in sigla, DMTI).
Facendo riferimento a quanto accennato nella sezione precedente, SIA sta sviluppando il DMTI
dopo aver focalizzato la progettazione sulle seguenti caratteristiche principali:
1. Adattabilità – il DMTI sarà totalmente configurabile ed adattabile a qualsiasi tipologia di
velivolo. Anzi, è allo studio la possibilità di sfruttare il prodotto anche in settori diversi,
partendo da quelli attigui. Nella progettazione si è imposto di mantenere una totale apertura
all’integrazione con moduli software di simulazione sviluppati in un qualsiasi linguaggio e/o
tecnologia.
2. Interfaccia utente in realtà virtuale – l’ambiente di lavoro per l’utente finale sarà principalmente
tridimensionale fornendo la totale libertà a studenti ed istruttori di muoversi liberamente in
modo virtuale in qualsiasi parte del velivolo, favorendo la familiarizzazione con la dislocazione
delle baie che ospitano l’avionica e gli altri dispositivi di bordo.
3. Teledidattica – il DMTI, che prevede di offrire una workstation per ciascuno studente e per
l’istruttore, è progettato appositamente per essere utilizzato tanto su una rete locale, quanto
attraverso Internet. Ciò fornisce la massima garanzia alle aziende che vorranno investire in
questo prodotto sul ritorno che potranno ottenere dallo sfruttamento di questa caratteristica,
come già accennato in precedenza. Grazie a ciò, il prodotto può essere acquistato anche da
aziende che, pur non possedendo velivoli da manutenere, rivendono il servizio di addestramento
in teledidattica a compagnie medio piccole di manutenzione che altrimenti non potrebbero
accedere a questi strumenti.
4. Scalabilità – il DMTI si pone come obiettivo la capacità di funzionare con normali PC connessi
in rete a formare un cluster. Ciò fornisce i notevoli vantaggi economici e logistici già accennati
senza compromettere l’estendibilità. Come vedremo più avanti, in caso di necessità particolari è
possibile eventualmente utilizzare due connessioni di rete su ciascuna macchina per ottenere un
ulteriore incremento prestazionale.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Per scelta aziendale, la realizzazione del DMTI, tutt’ora in corso, si basa quasi interamente su
prodotti e tecnologie freeware e/o open source, con un duplice vantaggio:
•
contenimento dei costi dello sviluppo
•
nessuna dipendenza da tecnologie proprietarie o chiuse
Principali strumenti e tecnologie impiegati
Linguaggio Java (JDK 1.4.2)
JBuilder 9 Personal
Librerie grafiche OpenGL
openORB (CORBA)
Altova XMLspy Home edition (editor XML)
Delphi 7 Personal
Architettura di DMTI
Architettura hardware del sistema
Facendo riferimento alla figura 1, vediamo com’è composto un cluster esemplificativo su cui opera
DMTI.
Come si può vedere, per ciascuna macchina che partecipa al cluster, DMTI individua uno fra tre
modi operativi: stazione studente, stazione istruttore e stazione di simulazione.
Questi ruoli logici sono parzialmente sovrapponibili tra essi: si può avere che una macchina fisica
assuma un singolo ruolo oppure la combinazione del modo operativo di simulazione con uno a
scelta tra studente ed istruttore.
Nell’ambito di un cluster è teoricamente possibile avere un numero illimitato di macchine di
simulazione e di macchine studente, mentre, attualmente, è consentita la presenza di un solo
istruttore per ciascuna sessione di esecitazione.
Le macchine che ricoprono il ruolo di simulazione eseguono tutte le attività strettamente legate
all’esecuzione della simulazione: raccolta degli input di utente, elaborazione dei modelli,
produzione degli output. Queste macchine non hanno un’interfaccia grafica dedicata, se non un
piccolo pannello di controllo per presentare alcune informazioni diagnostiche.
Esse hanno un’organizzazione gerarchica su due livelli: si individua una macchina che ricopre il
ruolo di supervisore, mentre tutte le altre sono asservite ad essa.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Per motivi prestazionali è preferibile fare in modo che le macchine di simulazione siano connesse
tra loro esclusivamente da una semplice LAN. Infatti la presenza di tratti di rete che passano
attraverso router multipli o addirittura attraverso Internet può compromettere seriamente le
prestazioni (nel secondo caso anche la robustezza) del sistema.
S
S
S
SIM
S
Internet
SIM
S
SIM
S
I
Rete locale
S – PC studente
I – PC istruttore
SIM – PC dedicato all’elaborazione della simulazione
Figura 1 - Tipica costituzione di un cluster DMTI
Le macchine studente offrono l’interfaccia grafica verso gli studenti, appunto, per presentare lo
stato del modello di simulazione e ne raccolgono gli input per stimolare opportunamente il modello
stesso.
Queste macchine non hanno alcuna interdipendenza, ma si connettono esclusivamente con il
supervisore di simulazione a cui inviano i comandi impartiti dallo studente e da cui ricevono gli
aggiornamenti sullo status del sistema.
Le macchine di studente possono essere tranquillamente connesse attravero reti geografiche anche a
banda stretta come i modem su linea telefonica analogica oppure telefoni cellulari.
La macchina istruttore è in pratica un’estensione della macchina di studente: l’istruttore infatti ha
tutte le possibilità d’interazione dello studente, ma può anche svolgere compiti ‘amministrativi’
come la creazione di una situazione di esercitazione, l’avvio della registrazione o riproduzione di
una sessione, l’iniezione di difetti oppure il monitoraggio delle attività di un qualsiasi studente.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Attualmente è previsto che vi sia un solo istruttore a dirigere una singola sessione di esercitazione,
ma è comunque possibile la condivisione delle medesime macchine fisiche tra più sessioni di
simulazione simultanee. In questo modo un singolo istruttore puo’ controllare più sessioni.
Tutti gli elaboratori coinvolti in un cluster DMTI sono semplici personal computer del tipo che tutti
i giorni troviamo sulla scrivania dell’ufficio oppure nelle nostre case. Solo per i computer dedicati
alla simulazione può risultare utile avere dei PC di fascia più alta, ma comunque si tratta di una
libera scelta da operare in fase di allestimento del centro di addestramento.
Nella simulazione di un sistema molto sofisticato, la banda della rete locale si potrebbe rivelare
insufficiente a supportare da sola il carico di comunicazione tra le macchine. In questi casi è
possibile connettere i computer di simulazione con due reti distinte di cui una verrà utilizzata
esclusivamente per la comunicazione del traffico relativo ai bus di bordo, che di solito sono
piuttosto ingombranti in termini di banda.
Architettura software
DMTI ha un’architettura software per la simulazione che si basa sui principi costitutivi di una
macchina sequenziale sincrona. Ogni elemento della simulazione deve avere un proprio stato
definito in corrispondenza del segnale di sincronismo e può modificare il proprio stato
esclusivamente in funzione degli stimoli che riceve.
È richiesto che tutti i modelli siano estremamente deterministici in modo da assicurare che,
assegnato un determinato stato iniziale, indipendentemente da qualsiasi altra condizione esterna, il
modello risponda ad uno stimolo, o una combinazione di stimoli, in maniera totalmente predicibile.
Questa scelta progettuale è stata necessaria principalmente per un motivo: poichè la simulazione
può essere eseguita su un cluster di costituzione arbitraria, è necessario garantire che il
comportamento dei modelli non dipenda da alcuna interferenza esterna.
Infatti è molto importante che, durante la sessione di addestramento, le risposte del sistema simulato
siano esattamente riproducibili altrimenti si avrebbe che, ripetendo più volte la stessa manovra, il
modello darebbe reazioni variabili in funzione del carico della rete o delle macchine di simulazione.
Questo accorgimento consente anche di implementare in modo molto semplice due importanti
caratteristiche:
1. la possibilità di interrompere una sessione di simulazione in qualsiasi momento e ripartire
successivamente dalla esatta situazione in cui si era in precedenza
2. la funzione di registrazione, e di successiva riproduzione, di una sessione che può essere
ottenuta memorizzando lo stato iniziale e registrando esclusivamente gli stimoli che i modelli
ricevono dagli utenti.
Vediamo più da vicino come opera il sistema al suo interno.
Nella figura 2 è riportato un diagramma di collaborazione che riassume un tipico ciclo di
simulazione.
Gli oggetti rappresentati in questo diagramma sono dislocati su macchine diverse.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
: Generic Event
Producer
Viene prodotta una
serie di eventi
1: Dispatch(Event)
Ogni istanza e’ in un
processo (e/o
macchina) separato.
2: Sync(SyncTime)
: Supervisor
Questi eventi
saranno
processati alla
successiva Sync
: LocalEvDispatcher
Nell’eseguire la Sync vengono
processati tutti gli eventi ricevuti fin
dalla precedente esecuzione della
Sync stessa.
5: Dispatch(Event)
3: Dispatch(Event)
local_LRI_collection : LRI
4: Update( )
Per gli eventi generati
dall’utente, riferirsi al
diagramma apposito.
: PresentationLayer
Figura 2 - Ciclo di esecuzione della simulazione
Il Supervisor ed i LocalEventDispatcher sono ospitati ciascuno su una diversa macchina di
simulazione.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Il PresentationLayer rappresenta il canale d’ingresso per l’interfaccia di tutte le GUI attive delle
macchine studente ed istruttore.
I LRI (line replaceble item) sono i componenti che costituiscono il modello da simulare e sono
ospitati in modo distribuito dai singoli LocalEventDispatcher.
Dinamicamente accade che un componente generico del sistema (ad esempio una GUI) produce uno
o più eventi e li invia al gruppo di macchine di simulazione – con l’ausilio del Supervisor ogni
evento raggiunge direttamente il LocalEventDispatcher che ha in carico il destinatario.
Gli eventi entranti nel LocalEventDispatcher non sono immediatamente elaborati, ma vengono
accodati in attesa di un segnale di sincronismo.
Il Supervisor, ad intervalli regolari, inoltra il segnale di sincronismo (Sync) a tutti i
LocalEvDispatcher ed attende che tutti terminino le elaborazioni derivanti.
In corrispondenza del Sync, il LocalEventDispatcher inizia ad elaborare tutti gli eventi accodati. Per
esso, l’elaborazione consiste nel trasferire gli eventi ai rispettivi destinatari secondo un preciso
ordine, e richiederne l’elaborazione.
I singoli LRI, in risposta ad un evento, potranno attivare una combinazione di tre tipi di reazioni:
modificare in tutto o in parte il proprio stato interno; modificare lo stato di un componente grafico
associato; produrre nuovi eventi destinati ad altri LRI.
In ogni caso è richiesto che l’elaborazione di un evento abbia un termine.
Gli eventi prodotti nell’elaborazione di quelli precedenti vengono accodati. Quando tutti gli eventi
pendenti sono stati elaborati, quelli neo-prodotti vengono distribuiti alle macchine destinatarie ed
infine viene inviato un segnale di controllo al Supervisor per indicare che tutta l’attività relativa al
Sync ricevuto è stata totalmente eseguita.
Quando tutti i LocalEventDispatcher terminano il proprio ciclo di attività, il Supervisor verifica i
dati di prestazione ed eventualmente decide di ridistribuire il carico tra le macchine. In questo caso
inoltra i comandi opportuni di carico/scarico ai LocalEventDispatcher interessati (v. figura 3),
altrimenti procede con un nuovo ciclo di Sync.
Come si vede, tutto il sistema si basa sugli eventi che vengono utilizzati come tramite di
comunicazione e stimolo tra i diversi elementi del sistema e del modello. Questo approccio
favorisce la trasparenza della dislocazione dei componenti di modello poichè nessuno di essi ha
relazioni dirette con gli altri. Se uno qualsiasi dei LRI vuole comunicare con l’esterno, produce un
evento e lo passa al LocalEventDispatcher che si occupa di consegnarlo al destinatario che lo
elabora nel successivo ciclo di Sync.
Per la comunicazione dalla simulazione verso le interfacce grafiche è stato introdotto, come
accennato, il PresentationLayer. Questo componente permette di mantenere disaccoppiate la
simulazione dalla presentazione grafica. Grazie a questo accorgimento, è possibile modificare anche
radicalmente l’aspetto e l’architettura dei motori di presentazione senza andare ad intaccare neanche
minimamente quanto è stato realizzato nei singoli LRI.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Il Supervisor ritiene la
tabella di distribuzione
degli oggetti.
3: Load(LRIReferencesList)
1: Unload(LRIReferencesList)
theSource : LocalEvDispatcher
: Supervisor
theDest : LocalEvDispatcher
4: Retrieve( )
2: Store( )
: LRI
Questa operazione effettua
lo snapshot di persistenza
degli oggetti specificati e
successivamente libera la
memoria ad essi allocata.
Questa operazione effettua
l’allocazione della memoria
per gli oggetti specificati e
preleva lo snapshot di
persistenza.
: LRI
Figura 3 - Attività di trasferimento di uno o più LRI
Tutte le GUI si iscrivono al PresentationLayer all’atto dell’attivazione e, man mano che l’utente
naviga nelle scene, dichiarano il loro interesse a ricevere gli aggiornamenti sui dati relativi alle
scene visitate.
Ogni volta che gli LRI aggiornano uno o più elementi di grafica, lo comunicano al
PresentationLayer. Quest’ultimo, se rileva che le informazioni modificate sono di interesse per una
o più GUI, notifica l’aggiornamento dei dati in modo mirato.
Queste brevi note sul PresentationLayer lasciano intendere che il legame tra le GUI ed il cuore della
simulazione è piuttosto lasco. Quest’approccio è stato intenzionalmente introdotto proprio perchè il
sistema è nato con l’idea di esplorare diverse possibilità anche per la presentazione grafica (si era
pensato a Java3D, DirectX, OpenGL): in questo modo lo sviluppo della GUI in realtà virtuale ha
potuto prescindere dai progressi della simulazione e tutt’oggi è possibile sostituire il motore grafico
attuale con uno basato su tecnologie del tutto differenti. L’unico vincolo è l’interfacciamento con il
PresentationLayer.
Attualmente, a scopo esemplificativo, sono state realizzate diverse interfacce GUI bidimensionali
proprio per evidenziare la possibilità di integrare tecnologie diverse nello stesso sistema. Questa
caratteristica si trasforma in un vantaggio per un futuro cliente che decidesse di sfruttare
l’infrastruttura di simulazione del nostro sistema e di integrarla con una GUI di sua proprietà.
L’ambiente grafico in realtà virtuale sviluppato per il DMTI è molto flessibile e facilmente
configurabile.
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Esso è in grado di utilizzare modelli sviluppati con un qualsiasi tool di grafica tridimensionale
capace di esportare in formato 3DS. La configurazione dell’ambiente grafico è affidata ad un file
XML che può essere modificato con un normale editor testuale oppure con un più comodo editor
dedicato.
Di seguito è possibile osservare una scena esemplificativa e la corrispondente rappresentazione a
griglia del file XML che la descrive. La natura non propriamente aeronautica della scena evidenzia
ancora una volta la notevole generalità della soluzione di SIA.
Attualmente è in sviluppo il gestore dei bus di comunicazione che, articolato in tre livelli di
astrazione, consente di supportare la simulazione di un qualsiasi tipo di bus o di rete con la relativa
messaggistica.
Stato attuale di sviluppo e conclusioni
Come accennato, lo sviluppo di DMTI è iniziato nello scorso aprile ed è attualmente in corso. Il
sistema attuale è in grado di mostrare tutte le caratteristiche peculiari a cui si punta e segnatamente
il funzionamento del cluster (attualmente testato con fino a quattro PC), la presentazione
dell’ambiente in realtà virtuale, la possibilità di operare in teledidattica e la semplicità con cui è
possibile costruire un sistema simulato di qualsiasi natura.
SIA sta ora indirizzando l’attività di sviluppo verso due direzioni principali:
1. la realizzazione di un modello simulato di media complessità per verificare la risposta del
sistema su una scala maggiore
2. la costruzione degli strumenti che consentano l’installazione, la configurazione e la
personalizzazione del sistema in modo integrato e guidato
4° Convegno Tecnico Scientifico
Torino 25, 26, 27 Ottobre 2004
Secondo la pianificazione attuale, queste attività si concluderanno nel primo bimestre del 2005.
SIA, confortata dai risultati finora ottenuti, confida molto nella validità delle proprie idee e stima di
poter introdurre il DMTI in una simulazione ‘reale’ nell’arco del prossimo anno.