visualizza
Transcript
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.