Analisi e valutazione delle prestazioni di un sistema per l Air Traffic Control

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica Analisi e valutazione delle prestazioni Anno Accademico 2008/2009 Relatore Ch.mo Prof. Domenico Cotroneo Correlatori Ch.mo Prof. Giuseppe Lieto Ing. Antonio Pecchia Candidato Brunella Ilda Scognamiglio matr

2 La perplessità è l inizio della conoscenza. (K.Gibran) 2

3 Indice Introduzione 7 Capitolo 1. Il dominio di riferimento : l Air Traffic Control L Air Traffic Control I requisiti di un sistema ATC I Servizi del Traffico Aereo L ATC e i Middleware CORBA CORBA TAO CARDAMOM Servizi Offerti dal middleware CARDAMOM System Management Load Balancing Servizio di Replicazione DDS OMG DDS Standard 39 Capitolo 2. Analisi dell Architettura di un FDPS Il Flight Data Processing System I Requisiti di un FDPS L Architettura presentata I Componenti del Sistema Il Facade Il ProcessingServer Il Test Client e il GroupCreatorFT La comunicazione Analisi dell architettura originaria Le inefficienze individuate La soluzione proposta 71 3

4 Capitolo 3. La verifica sperimentale Obiettivi della valutazione Tecniche di Valutazione e Misurazione Progettazione del benchmark Il Sistema di Riferimento Risultati Fase 1 : Analisi delle Performance Risultati Fase 3 : Analisi degli Impatti Gli effetti della modifica Conclusioni 99 Bibliografia 102 4

5 Indice delle figure Figura 1. Fasi di volo 11 Figura 2. Struttura di un tipico sistema ATM 16 Figura 3. Organizzazione dei livelli software 19 Figura 4. Architettura CORBA 20 Figura 5. ORB 22 Figura 6. Servizi di CORBA 24 Figura 7. Architettura TAO 26 Figura 8. Architettura CARDAMOM 29 Figura 9. Servizi CARDAMOM 30 Figura 10. Un sistema che utilizza il Load-Balancing 33 Figura 11. Architettura FT di CARDAMOM 34 Figura 12. Modello Publish/Subscribe 37 Figura 13. Architettura DDS 39 Figura 14. Global Data Space 40 Figura 15. Modello di programmazione del DDS 41 Figura 16. Modello di interazione tra le entità del DDS 42 Figura 17. Data Dictionary del progetto Avenue 45 Figura 18. Statistiche relative all'operazione di update in un FDPS 47 Figura 19. Architettura del prototipo in esame 48 Figura 20. Il Sistema e i suoi componenti principali 49 Figura 21. Pattern Architetturale Facade 52 Figura 22. Interfaccia IDL del componente Facade 53 Figura 23. Diagramma delle classi del componente Facade 54 Figura 24. Struct Lock 55 Figura 25. Funzioni lock() e unlock() 56 Figura 26. Interfaccia IDL del ProcessingServer 58 Figura 27. Diagaramma delle classi del componente ProcessingServer 59 Figura 28. Diagramma delle classi del componente TestClient 60 Figura 29. Interfaccia IDL del Client 61 Figura 30. Struct FDP 66 Figura 31. Sequence diagram del caso d'uso Aggiornamento di un FDP 67 Figura 32. Sequence diagram del caso d'uso Aggiornamento dopo la modifica 72 Figura 33. Implementazione dei metodi updatefdp() e request_rtn() del Facade 74 Figura 34. Implementazione del metodo updatefdp() nel ProcessingServer 76 5

6 Figura 35. Rilevazione dei tempi iniziali nel file ClientThread.cpp 80 Figura 36. Rilevazione del tempo di fine nel file Client_impl.cpp 81 Figura 37. Architettura del sistema e collocazione del benchmark 82 Figura 38. Sessione di test 84 Figura 39. Configurazione dello scenario 87 Figura 40. Risultati dei test con un Client 88 Figura 41. Riassunto dei risultati dell'intera sessione di test 89 Figura 42. Risultati dell'intera sessione di Test 90 Figura 43. Performance del Sistema 91 Figura 44 Risultati complessivi della seconda sessione di Test 92 Figura 45. Risultati dei test dopo la modifica con un Client 92 Figura 46. Risultati della seconda sessione di test 93 Figura 47. Risultati della seconda sessione di test 94 Figura 48. Confronto dei risultati nel caso di un Client 95 Figura 49. Confronto dei risultati nel caso di 5 Client 96 Figura 50. Confronto dei risultati nel caso di 10 Client 96 Figura 51. Confronto dei risultati nel caso di 15 Client 97 Figura 52. Confronto dei risultati nel caso di 20 Client 98 Figura 53. Confronto complessivo dei risultati 98 Figura 54. Miglioramento delle prestazioni in termini percentuali 99 Figura 55. Miglioramento percentuale del num di elaborazioni corrette 100 6

7 Introduzione Tale lavoro di tesi si inserisce nell ambito di un progetto di ricerca il cui obiettivo primario è la realizzazione di una piattaforma middleware open source, Mission-critical e Near Real-Time, in grado di fornire astrazioni e servizi utili per lo sviluppo di applicazioni distribuite con requisiti critici di affidabilità. Le motivazioni sono da ricercare nello stato attuale dell'industria del software nel campo dei sistemi complessi: interi settori dell'attività umana dipendono sempre di più dallo strato software, che deve trovare le innovazioni e le risorse per sopperire al bisogno crescente di infrastrutture e di servizi migliori. Un esempio ci viene dal campo dell Air Traffic Management, la gestione del traffico aereo. I problemi che attualmente si vivono, come la difficoltà a rispondere alla crescente richiesta di servizi, si riflettono anche sui sistemi software che supportano tale settore, e ai quali è richiesta sempre maggiore flessibilità e capacità di interoperare. La sfida è la realizzazione di architetture che, oltre ai requisiti funzionali propri del particolare sistema, soddisfino anche i requisiti critici tipici dei sistemi ATM, quali affidabilità, safety, performance e predicibilità. In quest'ottica, il lavoro di tesi che è stato realizzato mira ad essere un'esperienza nel campo dei sistemi distribuiti complessi con requisiti critici da soddisfare. In particolare è 7

8 stato studiato un sistema per il processing dei piani di volo (FDPS Flight Data Processing System) ponendo un attenzione particolare sull aspetto delle performance del sistema stesso. E stata analizzata l architettura di un prototipo esistente e individuati alcuni punti salienti in cui tale architettura poteva essere migliorata. Le modifiche individuate sono state quindi apportate al prototipo e, sono stati verificati sperimentalmente, attraverso opportuni test, gli impatti che tali modifiche hanno avuto sul sistema. Nel seguito viene descritto nel dettaglio come tale lavoro sarà presentato: Nel primo capitolo è esposto il problema dei sistemi distribuiti, ponendo particolare attenzione ai sistemi ATM (Air Traffic Management); viene descritto il loro dominio di riferimento e i requisiti che tali sistemi devono soddisfare. Ci si sofferma inoltre sullo strato Middleware che viene utilizzato in tali architetture. Si tratta di Middleware che hanno delle caratteristiche specifiche per poter essere impiegati in sistemi mission e safety critical. Nel secondo capitolo viene affrontata la problematica dell analisi di un sistema per il processing dei Piani di Volo (FDPS), studiandone architettura e implementazione. Vengono poi messe in evidenza le inefficienze riscontrate in un prototipo esistente e descritte nel dettaglio le modifiche da apportare al sistema per tentare di risolvere tali inefficienze. Nel terzo capitolo, infine, è descritta in maniera dettagliata la fase sperimentale del lavoro. Incentrandosi principalmente sull aspetto delle performance del sistema, sono stati effettuati dei test per valutarne le prestazioni prima e dopo la modifica, test che hanno portato alla conferma delle valutazioni svolte nella fase precedente di analisi. 8

9 Capitolo 1 Il dominio di riferimento : l Air Traffic Control Ad oggi i sistemi informatici sono utilizzati in molteplici scenari critici sia dal punto di vista economico (business critical) sia in termini di affidabilità e sicurezza (mission e safety critical). I requisiti di affidabilità, infatti, sono diventati negli anni di primaria importanza per un numero sempre crescente di sistemi, sottoponendo a continue rivisitazioni l interpretazione del concetto di dependability. Sebbene i sistemi informatici siano diventati essenziali in quasi tutti gli aspetti della vita dell uomo, infatti, essi non sempre sono dependable. In alcuni scenari critici, come quello dell Air Traffic Control, è, per questo motivo, importante caratterizzare soprattutto uno degli attributi di dependability, la safety, ovvero la capacità di un sistema di non recare danni all uomo o all ambiente circostante in seguito all occorrenza di un fallimento. I sistemi per il controllo del traffico aereo inoltre, rientrano nella categoria dei sistemi real-time, sistemi cioè per i quali l elaborazione deve terminare entro una scadenza temporale prefissata, che prende il nome di deadline. In tali applicazioni un risultato prodotto oltre la propria deadline non è solo in ritardo, ma potrebbe essere dannoso per la vita dell uomo o per l ambiente. Risulta quindi chiaro che realizzare un sistema di questo genere è un'attività estremamente complessa sia in termini economici che di tempi di sviluppo. 9

10 Verrà di seguito fatta una panoramica sui sistemi per il controllo del traffico aereo che, per questo lavoro di tesi, sono stati presi in considerazione, sottolineandone i requisiti e le caratteristiche generali, per soffermarsi poi, nei capitoli successivi, su come tali requisiti siano stati implementati. 1.1 L Air Traffic Control Il controllo del traffico aereo (ATC - Air Traffic Control) è quell insieme di regole ed organismi che contribuiscono a rendere sicuro, spedito e ordinato il flusso degli aeromobili sia al suolo che nei cieli di tutto il mondo. Chiunque voglia attraversare lo spazio aereo, si tratti di compagnie aeree o di privati, deve sottoporre all'attenzione dell ente nazionale per la gestione del traffico aereo (in Italia dell'enav - Ente Nazionale per l Assistenza al Volo) il proprio piano di volo; solo se tale piano viene approvato, l'aeromobile può impegnare una porzione dello spazio aereo. Alla Torre di Controllo (TWR - Aerodrome Control Service) è affidata la garanzia della sicurezza di un aeromobile nell'aeroporto e nelle sue vicinanze. La gestione dei movimenti a terra, che includono l'allontanamento dai parcheggi e il rullaggio, è di competenza invece del Controllore Ground che, esaurito il suo compito, affida il volo al Controllore di Torre, cui spetta concedere l'autorizzazione al decollo in modo che sia garantita la distanza di sicurezza da tutti gli altri aeromobili. Al centro di controllo dell avvicinamento, (APP -Approach Control Service) spetta poi il compito di instradare i velivoli appena decollati facendoli salire per l'inserimento in aerovia. La gestione passa infine al Centro di Controllo d'area (ACC - Area Control Center), che ha il compito di armonizzare l'ingresso e l'uscita degli aeromobili con il grande flusso di traffico che scorre lungo le aerovie. Ai velivoli vengono in questa fase assegnati differenti livelli di volo e indicate le traiettorie da seguire in modo che rimangano sempre reciprocamente distanziati, fino a 10

11 che, verranno affidati nuovamente all APP che ne gestirà l'avvicinamento, stabilendo la corretta sequenza e guidandoli quando lasciano le aerovie per iniziare la discesa fino all'allineamento con la pista. Quando il velivolo è ormai stabilizzato sul sentiero di atterraggio ed in vista dell'aeroporto, la gestione viene affidata alla torre di controllo di destinazione, che guida l'aereo fino al parcheggio. Figura 1. Fasi di volo Ogni Stato deve avere un ente che detta le norme vigenti (il Regulator) e un ente che fornisce i servizi del traffico aereo (l'air Navigation Service Provider - ANSP). Negli Stati Uniti la Federal Aviation Administration (FAA) funge sia da Regulator che da ANSP, mentre per il vecchio continente Eurocontrol ha stabilito che i due enti debbano essere distinti ed autonomi. In Italia, quindi, il Regulator è l' Ente Nazionale per l'aviazione Civile (ENAC), su delega del Ministero delle Infrastrutture e dei Trasporti, mentre i due ANSP sono rispettivamente ENAV SpA e l'aeronautica Militare Italiana, che operano in stretto coordinamento tra loro, ciascuno gestendo i Servizi del traffico Aereo all'interno degli spazi aerei e sugli aerodromi di propria competenza, così come previsto dalla legge (DPR 484/81). 11

12 1.1.1 I requisiti di un sistema ATC L ICAO - International Civil Aviation Organization stabilisce gli scopi del controllo del traffico aereo, ovvero i compiti principali di un sistema ATC. Essi sono: 1. Prevenire le collisioni tra gli aeromobili durante la fase di volo; 2. Prevenire le collisioni sia tra gli stessi aeromobili che tra aeromobili ed eventuali ostacoli presenti nell area di manovra di un aeroporto; 3. Accelerare e mantenere ordinato il flusso del traffico aereo; 4. Fornire suggerimenti ed informazioni utili per una sicura ed efficace condotta dei voli; 5. Dare l'allarme agli organismi di ricerca e soccorso, quando necessario. Tali requisiti non possono che essere stringenti. Si tratta di un'attività complessa in cui è in gioco la vita umana e per tale motivo i sistemi ATM sono ritenuti safety-critical. Il concetto di safety a molte persone viene in mente quando guidano, quando sono in volo su aereo di linea, o quando sono in ascensore. In ogni caso, la maggiore preoccupazione è data dalla minaccia dell occorrenza dei cosiddetti mishap, che il Dipartimento per Difesa degli Stati Uniti definisce come un evento o una serie di eventi non previsti che possono causare danni fisici a persone o compromettere l ambiente circostante. La valutazione dei rischi legati ai mishap, viene influenzata da due aspetti: la severità e la probabilità di una sua occorrenza. Ad esempio, un incidente aereo provoca degli effetti ben più gravi di un incidente d auto, ma è meno probabile che accada. Dovrebbe, allora, risultare chiaro che in alcuni contesti (trasporti su strada, aerei o impianti nucleari) non è possibile definire in 12

13 maniera assoluta il concetto di safety. Tutto ciò stabilisce un principio importante che sta alla base della progettazione di sistemi safety-critical: in base alle conoscenze fino ad ora maturate, non è possibile eliminare completamente il rischio di mishap nei sistemi safety-critical, ma è possibile soltanto ridurlo. Ovviamente ridurre i rischi implica aumentare i costi. Effettivamente in alcuni contesti, come quello dell energia nucleare, gran parte dei costi sono dovuti alla gestione della safety degli impianti. A causa di vincoli economici, occorre raggiungere un compromesso sulla quantità di risorse impiegate per la progettazione di un sistema safe: per questo motivo diventa raggiungibile solo un livello accettabile di rischio di mishap. Il problema principale a questo punto diventa stabilire quando il livello dei rischi di incidenti catastrofici può ritenersi accettabile. In molti casi tale risultato si considera raggiunto se la frequenza d occorrenza di un mishap è molto bassa. Sulla base di studi statistici sulla frequenza d occorrenza di mishap più comuni, si considera raggiunto un livello accettabile di rischio di mishap se la relativa frequenza di occorrenza varia tra 10-2 e incidenti per ora. Tali valori forniscono dei parametri di confronto utili ai progettisti di sistemi safe. Infatti, se la probabilità di incidenti gravi raggiunge valori ben lontani da quelli espressi in precedenza, un sistema può essere definito unsafe. Fortunatamente i progettisti di sistemi safe non stabiliscono in maniera indipendente quando ritenere accettabile il livello di safety, ma fanno riferimento ad alcuni standard prodotti da aziende e società del settore o da istituti appositi che cercano di individuare precisamente i livelli di safety creando in questo modo un consenso generale e delle linee guida I Servizi del Traffico Aereo Fornire una classificazione completa, e soprattutto dettagliata, dei servizi e delle componenti riguardanti il controllo del traffico aereo è assai complesso. Se ne fornisce 13

14 perciò, in questo contesto, una visione più generale, citando le macro-categorie e analizzando in maniera più esaustiva i componenti che sono stati parte integrante del lavoro di tesi. Gli Air Traffic Services (ATS) possono essere suddivisi in : Air Traffic Management (ATM), che a sua volta si compone di: Air Traffic Control (ATC), il cui compito è di stabilire le regole del volo strumentale, anche denominate Instrument Flight Rules (IFR), per il traffico relativo allo spazio aereo gestito. Un IFR è un insieme di regole di volo comprendenti una serie di regolamenti e procedure ideate per consentire il volo degli aeromobili anche in condizioni nelle quali i piloti non siano in grado di vedere, in modo tale che essi possano evitare ostacoli, il terreno o altri aeromobili in volo. Il servizio ATC cerca di rendere il flusso del traffico aereo sicuro, regolare e nello stesso tempo ottimale, prevenendo le collisioni tra gli aeromobili in volo e tra gli aerei e gli ostacoli, presenti nell aeroporto, in fase di manovra. Air Traffic Flow Management (ATFM), fornito ad ogni volo gestito, prevede di regolare e accelerare il traffico aereo. Air Space Management (ASM), organizza e gestisce lo spazio aereo. Air Information Service (AIS), che fornisce avvisi e informazioni utili alla sicurezza e all efficienza dei voli (funzione 4). Search & Rescue (SR), che fornisce il servizio d ispezione e soccorso agli aeromobili (funzione 5). 14

15 Il servizio di Air Traffic Control può essere a sua volta suddiviso in 3 funzioni principali: 1. controllo degli aerei durante la fase di volo o più semplicemente controllo della traiettoria (servizio A ); 2. controllo degli aerei in avvicinamento (servizio B ); 3. controllo dell aeroporto (servizio C ). Il servizio A viene fornito da opportuni centri di controllo della traiettoria e soddisfa i requisiti 1 e 3 relativamente alla fase di volo degli aerei. Il servizio B gestisce le aree di manovra dell aerostazione (TMAs Terminal Manoeuvring Areas ) e viene fornito dai centri di controllo dell aerostazione. Esso compie le funzione 1 e 3 relativamente alle fasi di partenza e di arrivo dei voli. Il servizio C viene fornito dalle postazioni di vedetta delle torri di controllo di ciascun aeroporto e corrisponde al soddisfacimento dei requisiti 1 e 3 ad esclusione delle fasi di volo gestite dal servizio B. Creare un singolo sistema software che garantisca tutte queste funzionalità è un'operazione ardua. Per lo sviluppo di tali architetture, come già detto, si utilizzano sistemi a loro volta complessi che forniscono funzionalità di alto livello. Un tipico sistema ATM è quindi costituito da una serie di componenti, ognuno dei quali ha un compito ben preciso. In particolare tali componenti sono: CWP - Controller Working Position: è il sistema di supporto alle operazioni di controllo di responsabilità umana; FDP - Flight Data Processing: è il sistema per il processing dei piani di volo; CMS - Control Monitoring System: è il sistema di diagnostica; SN - Safety Nets: è il sistema per la generazione di allarmi; AGDL - Air Ground Data Link : è il sistema per il coordinamento con gli strumenti di terra; 15

16 SDP -Surveillance Data Processing: è il sistema per la sorveglianza; RPB - Recording & Playback: è il sistema per la registrazione e la riproduzione a video della situazione di traffico; AIS - Auxiliary Information System: i sistemi informativi ausiliari; Adv. Tools: i tools che offrono supporto ausiliario di varia natura. Figura 2. Struttura di un tipico sistema ATM E chiaro che, ottenere questo livello di modularità, è una sfida per i sistemi attuali, considerando il fatto che ogni sottosistema deve comunicare ed interagire con quasi tutti gli altri. Per questo motivo l ultima frontiera dell ingegneria del software nel campo di sistemi di siffatta complessità è l utilizzo di tecnologie a componenti (CBSE Component Based Software Engineering), di cui uno dei maggiori vantaggi consiste proprio in una maggior chiarezza nell indicare i servizi e le interfacce messe a disposizione e utilizzate da altri componenti. Ciò ha permesso che un sistema per il controllo del traffico aereo, si 16

17 presenti come un architettura aperta, nel senso che i vari blocchi funzionali che lo compongono, come quelli citati sopra, non debbano essere necessariamente realizzati dallo stesso produttore; si parla di tecnologie COTS (Commercial off the shelf ), componenti da bancone, acquistati da terze parti e montati insieme per fornire una certa funzionalità (del resto è questo l obiettivo della CBSE, realizzare programmi software così come si realizza l hardware,ossia basandosi su componenti prefabbricati da assemblare opportunamente). In ogni caso preannunciamo fin da ora che nel resto del lavoro proposto non si farà uso di tecnologie a componenti, ma semplicemente di quelle ad oggetti distribuiti. Del resto è da queste ultime che le prime sono nate, ereditando tutti i vantaggi di cui prima si è discusso, e che da soli riescono a risolvere buona parte delle problematiche che ci è posti in questo lavoro di tesi. 1.2 L ATC e i Middleware L utilizzo dei sistemi informatici oggi giorno è diventato massivo in ogni scenario, da quelli ludici a quelli critici. Come risulta evidente dalle argomentazioni dei paragrafi precedenti, i sistemi di Air Traffic Control sono estremamente complessi, real-time e safety-critical e, pertanto, richiedono in genere lunghi tempi di sviluppo. In un contesto altamente critico, come quello per il controllo aereo, l'utilizzo di middleware permette di sviluppare un sistema software concentrandosi esclusivamente sulla business logic applicativa, realizzando applicazioni distribuite senza tener conto delle differenze tra le varie entità in gioco: linguaggi di programmazione, sistemi operativi, protocolli di rete, ecc. I sistemi di controllo aereo, in generale, utilizzano infrastrutture proprietarie sia hardware che software e la realizzazione di un sistema software ex-novo che permetta di gestirle nel loro complesso è una attività complessa e molto costosa, in poche parole non affrontabile. 17

18 Per aggirare questi problemi, vengono utilizzate tecnologie orientate agli oggetti e al calcolo distribuito, il riutilizzo del codice e l'utilizzo massiccio dei COTS, Commercial OFF-The-Shelf. Implementando un sistema software basandosi su tale modello, si riesce a renderlo maggiormente scalabile, estensibile, più performante e più available. Interporre tra il livello applicativo ed il sistema operativo uno strato middleware qualsiasi garantisce molti vantaggi, ma in alcuni campi non basta. Nella realizzazioni di sistemi per il controllo del traffico aereo, ad esempio, visti i loro requisiti di Quality of Service (QoS), fault-tolerance e real-time, bisogna utilizzare dei middleware che attraverso le loro componenti riescano a fornire tali servizi. Nel seguito si approfondiranno tre middleware diversi che, insieme, riescono a ricoprire l intero spazio dei requisiti; tali strumenti sono quelli utilizzati per realizzare l'applicativo software che verrà descritto nei capitoli successivi. I middleware in questione sono: CORBA: Common Object Request Broker Architecture, middleware a oggetti, che fa parte di un più ampio modello architetturale denominato OMA - Object Management Archictecture; CARDAMOM: piattaforma middleware Open Source basata su CORBA, sviluppata in collaborazione da THALES e SELEX-SI. Si tratta di un middleware orientato ai sistemi safety e mission-critical tra i quali si annoverano i sistemi per il controllo del traffico aereo, sistemi navali e per la difesa; DDS: Data Distribution System, middleware data-centric di tipo publish/subscribe per sistemi distribuiti e real-time. Introdotto in ambito industriale e militare, è diventato uno standard OMG che quindi, facilmente si integra in architetture CORBA-based. 18

19 Nella figura successiva è mostrata l organizzazione dei livelli software in un sistema FDPS costruito con l ausilio dei middleware appena citati. Figura 3. Organizzazione dei livelli software CORBA Da alcuni anni a questa parte si stanno diffondendo enormemente middleware orientati agli oggetti, capaci di interfacciarsi con applicativi e linguaggi di programmazione ad oggetti oltre che con i classici linguaggi procedurali. CORBA, acronimo di Common Object Request Broker Architecture, è la specifica di un modello di riferimento per un middleware a oggetti, che fa parte di un più ampio modello architetturale denominato Object Management Archictecture (OMA). CORBA è definito dal consorzio Object Management Group (OMG) formatosi nel E' da tenere ben presente che OMG non produce software, ma specifiche che guidano i produttori durante lo sviluppo di piattaforme middleware che supportino l'interoperabilità, la riusabilità e la portabilità di componenti software su sistemi eterogenei. 19

20 Difatti, CORBA altro non è che la specifica di un middleware non proprietario che fornisce caratteristiche che ben si adattano ai sistemi di controllo aereo. Questo in quanto, essendo uno standard per i sistemi distribuiti, permette di continuare ad utilizzare vecchi componenti del sistema (il legacy code) e di potersi interfacciare con sistemi ATM di altri costruttori grazie alla definizione di un'interfaccia indipendente dalla particolare piattaforma. Figura 4. Architettura CORBA L'architettura CORBA è così costituita: Object Services: sono i servizi per gli oggetti (ad esempio i servizi per scoprire gli altri servizi raggiungibili). Fanno parte di questa classe: Il Naming Service, che consente al client di trovare un oggetto a partire dal nome; Il Trading Service, che consente al client di trovare un oggetto basandosi sul servizio offerto. Tra gli altri servizi si annoverano quelli per la sicurezza, le transazioni e gli event notification; 20

21 Common Facilities: contengono servizi per le applicazioni, di tipo orizzontale, utili a diverse categorie di applicazioni; Domain Interfaces: contengono servizi specializzati per domini applicativi, quali quello per le telecomunicazioni, quello finanziario e assicurativo e così via; Application Interfaces: si tratta di interfacce sviluppate specificamente per una data applicazione. Dal momento che si tratta di interfacce application-specific, e visto che OMG non sviluppa applicazioni, ma solo specifiche, queste interfacce non sono standardizzate. L'ORB (Object Request Broker) rappresenta l'elemento chiave dell'architettura CORBA, che permette agli oggetti client e server di interagire indipendentemente dalla loro localizzazione, dal linguaggio e dalla piattaforma sottostante. Gli elementi che costituiscono l ORB possono così essere schematizzati: Object: si tratta di una CORBA programming entity, la quale non è altro che un'interfaccia o un'implementazione detta Servant; Servant: è l'applicazione vera e propria, scritta in un linguaggio qualsiasi (es. C++, Java.. ), che implementi le funzioni definite dalle interfacce IDL; Client: è l'entità che invoca un'operazione implementata da un oggetto remoto. L'accesso al servizio remoto deve essere trasparente al chiamante. Deve essere semplice come la chiamata di una funzione (es. obj->op(args) ); 21

22 Object Request Broker (ORB): l'orb fornisce il meccanismo per rendere la comunicazione tra il client e l'oggetto remoto che implementa il servizio richiesto. L'ORB semplifica la programmazione distribuita non rendendo necessario conoscere i dettagli della comunicazione; la richiesta del client appare come una chiamata ad una funzione locale. Quando il client richiede un'operazione, l'orb deve trovare l'oggetto che implementa il servizio, richiedergli l'operazione e ritornare al client la risposta; Figura 5. ORB ORB Interface: l'orb è un'entità logica, che può essere implementata in diversi modi. Per disaccoppiare l'applicazione dai dettagli implementativi, le specifiche CORBA, definiscono un'interfaccia astratta per l'orb, che fornisce varie helper functions; 22

23 CORBA IDL stubs and skeletons: CORBA IDL stubs e skeletons fungono da collante" tra il client e l'applicazione server e l'orb. La trasformazione dalla definizione CORBA IDL al linguaggio di programmazione prescelto è automatizzata dal compilatore CORBA IDL. L'utilizzo di un compilatore riduce le inconsistenze tra lo stub e lo skeleton; Dynamic Invocation Interface (DII): questa interfaccia permette al client di accedere direttamente ai meccanismi di richiesta sottostanti forniti dall'orb. Le applicazioni utilizzano le DII per richiedere un object senza ricorrere alla relativa interfaccia IDL. A differenza degli IDL stubs (che permettono solo richieste simili alle RPC), le DII permettono ai client di realizzare anche delle chiamate non bloccanti e chiamate oneway; Dynamic Skeleton Interface (DSI): è l'interfaccia sul lato server analoga a quella DII lato client. Il client che fa la richiesta non sa se l'implementazione utilizzi uno skeleton dinamico o utilizzi uno skeleton statico. Object Adapter: detto anche POA (Portable Object Adapter), è un'interfaccia lato servente, il cui compito principale è di isolare un oggetto dall'orb, fornendone l'astrazione di un'entità sempre disponibile, dalla creazione alla sua distruzione. Ha anche la responsabilità di assegnare un identificativo univoco (l'object Reference, OR) all'oggetto, di gestirne il ciclo di vita e di inoltrarne le richieste provenienti dall'orb. 23

24 Figura 6. Servizi di CORBA Come si evince dalla fiugra di cui sopra, molti sono i servizi e le facilities che CORBA mette a disposizione. Tra questi i più importanti sono l'event Service, il Naming Service, il Time Service, il Transaction Service ed il Security Service. Tali servizi non verranno qui approfonditi, verrà invece approfondito il supporto per applicazioni Real-Time, ovvero software in cui sono di vitale importanza il controllo di parametri quali la latenza, il throughput ed il jitter end-to-end. Una piattaforma middleware che permette di gestire questi parametri è CORBA TAO CORBA TAO CORBA TAO nasce per sviluppatori che necessitano di stringenti requisiti in termini di QoS, quali bandwidth, latenza e jitter. A differenza delle implementazioni di CORBA convenzionali", Corba TAO (in seguito solo TAO), introduce dei patterns per il delivery di applicazioni distribuite con alte prestazioni in merito al real-time QoS. E' proprio nei sistemi real-time e nelle applicazioni mission-critical, che richiedono tempi di 24

25 sincronizzazione prevedibili e robustezza, che TAO fornisce i maggiori benefici. TAO si rivolge, infatti, principalmente ai sistemi nei quali lo scheduling delle operazioni è cruciale per ottenere una correttezza globale del sistema. Gli ostacoli in cui ci si imbatte nella realizzazione di sistemi real-time utilizzando CORBA, sono i vari livelli di cui esso è formato, non gestibili completamente. TAO invece integra le interfacce di rete, il sottosistema di I/O del sistema operativo ed i servizi middleware per fornire una soluzione end-to-end. Si consideri ad esempio l'event Service di CORBA. Questo servizio semplifica le applicazioni software disaccoppiando produttori e consumatori garantendo la possibilità di una comunicazione di gruppo grazie ad un sistema asincrono di event delivery. TAO migliora l'event Service di CORBA inserendo caratteristiche importanti, quali il dispatching e lo scheduling real-time degli eventi, il loro processamento periodico e il loro filtering ed un protocollo multicast necessario per le applicazioni real-time. Le modifiche rispetto alle normali versioni di CORBA si riscontrano nel POA, esso infatti supporta anche le seguenti politiche: Threading: sia a singolo thread, sia controllate dall'orb; Lifespan: specifica quali objects sono transienti e quali persistenti; ObjectId Uniqueness: specifica se una o più entità sono implementate; Servant Retention: specifica se le associazioni tra servant e CORBA object sono mantenute oppure stabilite ad ogni richiesta; Request Processing: specifica come le richieste devono essere processate dal POA; Implicit activation: utilizzando questo servizio si può registrare un servant e creare un object reference in una singola operazione. Oltre ai servizi OMG CORBA services e alle caratteristiche peculiari di CORBA, già accennate in precedenza, TAO introduce altre caratteristiche: 25

26 CORBA Messaging: Asynchronous Method Invocation (callback), ed un Framework per la gestione del QoS; Figura 7. Architettura TAO Portable Interceptors: ovvero oggetti che l'orb invoca in un determinato punto durante il request ed il reply (request interceptor), o durante la generazione dello IOR (IOR interceptors); 26

27 Interface Repository: che provvede allo storage, alla distribuzione ed alla gestione di un insieme di interfacce di object correlati; Implementation Repository: che consente il binding indiretto tra le richieste del client e le implementazioni del server per soddisfare tali richieste. In alternativa, prevede l'avvio automatico del server quando un client effettua una invocazione; Bi-Directional GIOP: che consente alle richieste e alle risposte di viaggiare bidirezionalmente attraverso una singola connessione tra due processi, che sono l'invio e la ricezione delle domande e delle risposte. Questa capacità aiuta a risolvere il problema di invocare callbacks sui clienti situati dietro un firewall. Object by Value: che parzialmente attua la CORBA OBV, che combina la semantica delle strutture e delle interfacce, consentendo in tal modo agli oggetti di essere passati per valore (cioè copiati) attraverso interfacce IDL fintanto che l'implementazione esiste a livello locale sul lato di ricezione. Object Reference Template (ORT): TAO implementa l'object Reference Template (ORT) definito in CORBA 3.0 Core per l'implementazione di un interfaccia per la generazione di un object reference da parte di un object adapters. TAO, inoltre, è conforme a Real-Time CORBA versione 1.1 e offre i seguenti servizi che consentono di apprezzare le capacità di TAO in vari ambienti real-time deterministici o statistici: TAO Real-Time Event Service: aumenta le funzionalità fornite da CORBA Event Service standard fornendo l'event correlations ed il real-time dispatching; 27

28 Pluggable Protocols: permette agli sviluppatori di inserire un modello personalizzato di trasporto sotto GIOP senza modificare l'applicazione a livello di codice. Un componente importante di TAO è ACE (Adaptive Communication Environment), un framework object-oriented che implementa molti modelli di progettazione di base utili nei software di comunicazione concorrente. ACE fornisce un ricco set di wrapper C++ e componenti framework che permettono la comunicazione tra O/S platforms. Tali comunicazioni così garantite includono l'event demultiplexing e l'event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic recon_guration dei servizi distribuiti, l'esecuzione concorrente e la sincronizzazione. Questo è il più basso livello del middleware ed implementa il nucleo di concorrenza e di distribuzione di un software per la comunicazione. ACE, fornendo wrapper C++ riutilizzabili, fornisce tutti i componenti che supportano i requisiti di QoS ad alte prestazioni per le applicazioni real-time. ACE è multi-piattaforma e può essere utilizzato sia con sistemi operativi real-time che con quelli convenzionali" CARDAMOM CARDAMOM è una piattaforma middleware opensource per i sistemi mission e safety critical ( ), nata con lo scopo di diventare un framework per lo sviluppo, il deployment e la messa in esercizio di sistemi complessi come l'air Traffic Management, il Combat Management, i sistemi di volo, l Electronic Warfare, il Naval Combat Management, ecc. CARDAMOM è quindi un middleware multi-domain e, con lo scopo di renderlo utilizzabile ed adattabile in diversi ambienti con differenti requisiti, è stato realizzato 28

29 organizzandolo in un core necessario all'utilizzo base, più una serie di pluggable services che possono essere utilizzati o meno al fine di rispondere ai requisiti dell'ambiente in cui dovrà operare. Con l ausilio della figura successiva è possibile apprezzare la struttura appena descritta. Figura 8. Architettura CARDAMOM Per fornire queste funzionalità Plug and Play" dei suoi componenti, CARDAMOM si basa sui principali standard di interoperabilità definiti dall'omg, Object Management Group: a livello di business logic CARDAMOM utilizza UML (OMG standard) e XML (W3C standard); come strato di separazione CARDAMOM utilizza CCM (CORBA Component Model) OMG standard al fine di isolare la business logic dai servizi; a livello tecnico CARDAMOM utilizza CORBA OMG standard. 29

30 CARDAMOM, quindi, è un middleware CORBA creato per configurare, modellare e realizzare sistemi distribuiti near real-time and fault-tolerant. Tali sistemi sono anche denominati CCIS, Command Control and Information Systems Servizi Offerti dal middleware CARDAMOM I servizi offerti da CARDAMOM sono quelli che fanno la differenza da altri middleware. Essi, infatti, permettono di adattarlo facilmente ai diversi ambiti in cui dovrà agire, utilizzando o meno uno dei suoi servizi. Nella figura successiva si mette in luce come l'applicazione sia al disopra di uno strato di astrazione al quale sono collegati, ovvero fanno parte, tutti i servizi pluggable". Nel seguito verranno descritti alcuni dei servizi più importanti di questo middleware. Figura 9. Servizi CARDAMOM 30

31 System Management Il System Management è il servizio che permette di definire, progettare e monitorare le applicazioni. Si tratta di un servizio estremamente utile se si considera il fatto che la gestione di un sistema complesso è un compito arduo. Già la sola caratteristica base di un sistema distribuito, ovvero il fatto che i nodi operativi sono dislocati in posti tra loro anche molto lontani, oppure a cui è difficile accedere manualmente, rende l'idea della sua complessità. Il compito del System Management è aiutare l'uomo in queste operazioni, sostituendosi ad esso nelle attività di gestione. Nella pratica si distribuiscono su ogni nodo, uno o più moduli di supervisione, rendendo possibile monitorare in ogni istante il sistema da una posizione fissa, ed intervenire nel caso ve ne sia la necessità. Senza ombra di dubbio un servizio di tal genere, non è utile solo per sistemi complessi come il controllo del traffico aereo, ma anche per sistemi mediamente complessi. Il System Management, nello specifico dà la possibilità di effettuare le operazioni di: System Configuration: permette di definire, durante la fase di configurazione, il sistema in tutte le sue parti (nodi, applicazioni, processi... ). Dà anche la possibilità di effettuare la riconfigurazione dinamica dl sistema a run-time, possibilità che risulta molto utile in caso di fallimenti di parti del sistema, in quanto possono essere fatte ripartire senza dover riavviare il resto che è ancora correttamente funzionante; System Control: consente il controllo di tutte le entità del sistema, a diversi livelli di granularità, dalle operazioni di start-up, stop, shut-down e reboot. Viene fornita 31

32 anche la possibilità di stabilire l'ordine di inizializzazione, di esecuzione e di stopping di applicazioni e processi che costituiscono il sistema; System Monitoring: permette di monitorare il sistema a livello di processo (in caso di fault viene segnalato lo stato del processo) e a livello host (attraverso un polling periodico su ciascun nodo); System State Report and Notification: fornisce la possibilità ad un client di ottenere informazioni sullo stato complessivo del sistema secondo due possibili modalità: attraverso richiesta esplicita da parte del client (modalità push denominata Admin HMI); mediante sottoscrizione al servizio di notifica per una certa entità (modalità pull denominata Observer) Load Balancing Questo servizio è responsabile dell'instradamento in modo dinamico delle richieste dei client verso i server disponibili, al fine di ottimizzarne i tempi di risposta e l'utilizzo delle risorse. Sono possibili diverse politiche per selezionare il server che elaborerà la richiesta in un modo trasparente per i client. Le strategie di load balancing possono anche essere personalizzate per rispondere alle necessità dell'applicativo da sviluppare. 32

33 Per permettere l'invio delle richieste ai server, vi è la necessità che, all'interno di un load balancing group, sia definita una lista di objects in grado di processare le richieste dei client. Il load balancing group può anche fare riferimento ad un elenco di componenti, in altre parole la capacità di bilanciamento del carico può essere definita non solo a livello di oggetti, ma anche a livello di componenti. Questo significa che le decisioni vengono prese ogni volta che un client effettua una richiesta, rendendo piuttosto economica la richiesta di bilanciamento a regime. Figura 10. Un sistema che utilizza il Load-Balancing L'infrastruttura che garantisce il Load Balancing in Cardamom è replicata in modo da non rappresentare un single point of failure. 33

34 Servizio di Replicazione CARDAMOM prevede un'implementazione della replicazione stile CORBA. Si tratta di una replicazione Warm Passive basata su una forte coerenza, garantendo in tal modo che in qualsiasi momento, tutte le repliche disponibili abbiano lo stesso stato. Supporta la Fault Detection e la Fault Notification monitorando i processi e gli host basandosi sul paradigma push e/o pull. Figura 11. Architettura FT di CARDAMOM L'implementazione della replicazione in CARDAMOM è basata sui seguenti componenti: Replication Manager, che espleta i seguenti task: Replication Management. Se la replicazione è WARM PASSIVE e la replica primaria è faulty, il Replication Management indice l'elezione di una nuova replica; 34

35 Fault Detection: scopre la presenza di un fault nel sistema e genera un fault report; Fault Notification: propaga i fault reports alle entità che si sono registrate per le notifiche. Location Manager, entità locale che raggruppa le interfacce degli object. Ognuna di queste interfacce permette di aggiornare la Fault Tolerance Location quando un gruppo viene modificato (aggiunto o rimosso un membro, eletto un nuovo nodo primario). Quindi, quando la replicazione è di tipo WARM PASSIVE, l'object viene attivato quando è eletto come primario ed il vecchio membro primario disattivato dai rispettivi Location Manager; State Replication Framework, fornisce applicazioni con data stores transazionali altamente efficienti. Il framework supporta il meccanismo di callback per notificare alle applicazioni che il data store è stato aggiornato, oppure che è stato inizializzato. Le letture dei dati sono sempre locali alla location del data store, le scritture invece sono effettuate solo sulla location primaria e poi viene utilizzato un protocollo di two-phase commit per aggiornare le repliche; Activation Framework. L'attivazione e la disattivazione delle repliche all'interno di un FT Location è una parte dell'activation Framework destinata alle applicazioni per sviluppare il meccanismo di replicazione, oppure per le applicazioni che richiedono il controllo dell'attivazione o disattivazione delle repliche. Le applicazioni possono registrare localmente un ActivationHandler per ottenere notifiche ogni qual volta che la replica viene promossa a primaria o a copia di backup; 35

36 Request Logging Framework, fornisce un framework per fare il log delle richieste per garantire che le richieste siano processate at most once" (al massimo una volta). Ogni richiesta ha un tempo di scadenza associato e viene tenuta dal server durante tutto il tempo. Se viene effettuata una richiesta simile prima che scada il tempo, il server risponde con quella registrata. Se invece il tempo è scaduto, il server risponde sollevando al client un'eccezione BAD CONTEXT CORBA System Exception; Ultimate Fallback and Service Discovery. CARDAMOM Fault Tolerance definisce un meccanismo di callback al Service Locator per trovare l'ultima reference di un object replicato. Il Service Locator si basa su un protocollo di multicast per il discovery dell'infrastruttura dei Fault Tolerance di CARDAMOM DDS Il modello di comunicazione publish/subscribe si sta diffondendo sempre di più tra gli sviluppatori poiché gode di proprietà che facilitano la realizzazione di applicazioni dinamiche e distribuite su larga scala. I componenti di tale modello sono: 1. il Publisher: è il produttore" dei messaggi di comunicazione, rappresenta l'elemento attivo del modello; 2. il Subscriber: riceve i messaggi a cui è interessato, comunicando il suo interesse mediante sottoscrizioni, rappresenta il componente passivo del modello; 3. un Event Service: è l'intermediario tra i publishers ed i subscribers. Il modello ha lo scopo di gestire le modalità per fornire spazio per i dati, gestire le 36

37 sottoscrizioni e consegnare efficacemente i messaggi. Figura 12. Modello Publish/Subscribe Come si evince dalla figura 12, le interazione tra le parti possono così essere riassunte: 1. il publisher invia messaggi all'event service; 2. il subscriber comunica il suo interesse ad una determinata categoria di messaggi mediante un meccanismo di sottoscrizione; 3. quando un messaggio risulta disponibile presso l'event Service, esso informa i subscribers interessati alla categoria di cui fa parte il messaggio mediante notifiche. Si nota immediatamente che tale modello, si basa su di uno schema di interazione asincrono con un elevato grado di disaccoppiamento tra le parti. In particolare i sistemi basati su tale modello introduco tre forme di disaccoppiamento: Disaccoppiamento nello spazio: le entità interessate nella comunicazione, dal momento che interagiscono con l'event Service, non hanno bisogno di avere 37

38 reference tra di loro. In particolare il publisher non ha riferimenti dei subscribers coinvolti ne tanto meno del loro numero. Dall'altra parte anche i subscribers non hanno riferimenti sui publishers. Si nota che tale modello è uno schema di comunicazione di tipo molti-a-molti; Disaccoppiamento nel tempo: le interazioni tra le entità che partecipano alla comunicazione possono avvenire anche in istanti di tempo differenti. Può quindi essere possibile che qualche publisher effettui una pubblicazione durante il periodo in cui un subscriber sia disconnesso, oppure che il subscriber possa ricevere una notifica di un messaggio quando il publisher che l'ha pubblicata non è più attivo; Disaccoppiamento della sincronizzazione: la comunicazione tra i publisher ed i subscribers è di tipo asincrono. I publishers non sono bloccati dopo l'invio di una pubblicazione ed i subscribers ricevono le notifiche in maniera asincrona mediante una callback mentre stanno effettuando altre elaborazioni. Questo modello di disaccoppiamento tra la produzione ed il consumo delle informazioni introduce un elevata scalabilità in quanto le reference esplicite tra le entità partecipanti sono rimosse. Rimuovere tali dipendenze riduce la necessità di coordinazione e sincronizzazione tra le parti, rendendo i sistemi publish/subscribe adatti ad ambienti distribuiti asincroni per natura e che richiedono un pattern di comunicazione di tipo moltia-molti. Vi è però uno sconto da pagare se il sistema si trova ad operare in contesti in cui è necessario garantire anche un'elevata affidabilità della comunicazione. In tali scenari infatti, bisogna scongiurare la perdita dei messaggi e quindi tener conto anche del recupero dalle perdite. Per far ciò la scalabilità viene in qualche modo ridotta in quanto sorge la necessità di memorizzare gli eventi per poterne eventualmente effettuare la ritrasmissione. 38

39 OMG DDS Standard Adottare una soluzione specifica per la data distribution, consente di semplificare notevolmente le applicazioni distribuite data-centriche. Un sistema di questo tipo, però, deve garantire determinati requisiti ed essere conforme a degli standard per poterne permettere l'utilizzo su diverse piattaforme. La crescita dell'utilizzo di tali sistemi middleware, ha portato l'omg, Object Management Group, a rilasciare uno standard definitivo per il DDS, Data Distribution Service. Figura 13. Architettura DDS In base a tale standard, DDS è un middleware di tipo data-centric, publish-subscribe, espressamente dedicato alla realizzazione di applicazioni distribuite in scenari safety critical che hanno la necessità di condividere informazioni in tempo reale ed in maniera affidabile. In particolare realizza un semplice modello di programmazione, quale quello publish/subscribe, in un sistema di distribuzione efficiente dei dati, scalabile e robusto che permette di rispettare anche stringenti requisiti di QoS. Lo standard definisce un Platform Indipendent Model (PIM), utilizzando il linguaggio UML. Ciò permette di descrivere tutti i servizi in maniera indipendente dalla specifica piattaforma hardware e dai linguaggi di programmazione. Le specifiche dello standard 39

40 DDS definiscono due interfacce (cfr. figura 14): Data-Centric Publish-Subscribe (DCPS): il livello base, che si occupa della consegna efficiente del dato al destinatario; Data-Local Reconstruction Layer (DLRL): il livello opzionale, che permette una più semplice integrazione nel livello applicativo. Figura 14. Global Data Space Grazie all'astrazione fornita dalle specifiche del DDS, è possibile realizzare delle applicazioni distribuite basate sul modello publish/subscribe, composte da processi, detti participants", che possono ricoprire i ruoli sia di publisher che di subscriber. Questi processi, sfruttando le potenzialità del DDS, possono effettuare delle semplici operazioni di scrittura (write), o di lettura (read) di dati. Sarà poi il middleware DDS sottostante a distribuire i dati in modo che ogni participant possa accedere al valore più recente del dato. Un modello di tal genere, si basa sul concetto di spazio dei dati globale" (global data space), reso accessibile a tutti i processi interessati alla comunicazione (figura 14). 40

41 I processi possono scrivere informazioni nel global data space semplicemente dichiarando di voler diventare publisher. I processi che invece vogliono accedere alle informazioni presenti sul global data center, dichiarano di voler diventare subscriber. Quando un publisher pubblica nuovi dati, il middleware propaga le informazioni a tutti i subscriber interessati. Figura 15. Modello di programmazione del DDS Ritornando alle interfacce del Middleware DDS, poniamo l'attenzione sull'interfaccia DCPS, Data-Centric Publish-Subscribe. Il modello di programmazione del Middleware DDS visibile nella figura 15 prevede le seguenti entità: DomainParticipant; DataWriter; DataReader; Publisher; 41

42 Subscriber; Topic. Tutte le classi derivano dalla classe base Entity, quindi per ogni classe vi è la possibilità di configurare tutto con politiche di QoS e ricevere notifiche degli eventi attraverso dei listeners. Scendendo nei rami dell'albero delle classi, troviamo il Publisher, l'oggetto responsabile della pubblicazione dei dati. Questi ultimi possono essere differenti e a tal fine ad ogni tipo è associato un DataWriter. Figura 16. Modello di interazione tra le entità del DDS La figura 16 mette in risalto le operazioni effettuate all'interno del Middleware DDS. In particolare un DataWriter attraverso il Publisher effettua una scrittura sul Data Domain. Una volta che il dato è presente nel Data Domain, viene ricevuto dal Subscriber interessato al dato pubblicato ed attraverso il DataReader passato all'applicazione. Le applicazioni (i partecipants) in esecuzione su di un nodo, possono essere raggruppate in domini (Domain Partrecipant) e possono contenere sia publisher che subscriber e più DataReader e DataWriter associati a diversi Topic. 42

43 Capitolo 2 Analisi dell Architettura di un FDPS 2.1 Il Flight Data Processing System In precedenza si è visto quali siano alcuni dei sottosistemi principali che compongono una piattaforma di Air Traffic Management: uno dei più importanti è il sistema per il processing dei piani di volo (FDPS Flight Data Processing System) e che viene assunto come riferimento per il seguente studio. Verrà per questo motivo di seguito data una definizione di piano di volo, e chiarite quali siano le operazioni tipiche di un sistema FDP. Un piano di volo è sostanzialmente un modulo che deve essere riempito e consegnato dai piloti alle autorità locali per l'aviazione (come l'enav - Ente Nazionale per l Assistenza al Volo in Italia) prima della partenza. Esso contiene una serie di informazioni di base, quali ad esempio aeroporto di partenza e di arrivo, tipo di volo (strumentale IFR o visuale VFR), numero di persone a bordo, aeroporti di arrivo alternativi (informazione utile in caso di problemi, come cattivo tempo), e una serie di informazioni più interessanti, prodotte nella fase di flight planning, che sono le informazioni riguardanti gli aspetti safety-critical. La prima è il calcolo della benzina da imbarcare per il volo: è ovvio che bisogna calcolare quanta benzina necessita l aereo per giungere la destinazione tenendo conto di fattori 43

44 come la rotta da seguire, l altezza, la velocità, il carico, ma anche fattori extra come la volontà di minimizzare la benzina imbarcata, che contrasta ad esempio con le regole di sicurezza per cui bisogna imbarcare più del minimo necessario (almeno per raggiungere la seconda destinazione in caso di problemi). L altra operazione riguarda il calcolo di rotta e traiettorie dell aereo nelle varie fasi del volo: tali operazioni vanno fatte in conformità con le regole del controllo del traffico aereo, in modo da minimizzare il rischio di collisioni in aria. Ad esempio gli organi di supervisione dell ATC impongono agli aerei di calcolare la rotta basandosi sulle cosiddette airways, delle rotte predeterminate e che rientrano nello spazio aereo controllato. Risulta chiaro allora che adempiere a tali compiti, producendo piani di volo ottimizzati e accurati secondo tutti i parametri e i vincoli di cui bisogna tenere conto, è un attività complessa da demandare ad un apposito sistema di calcolo, che si occupa appunto del processing dei piani di volo. Per dare un idea di tale complessità, possiamo rifarci al modello di piano di volo proposto nello standard AVENUE. Si tratta di una delle iniziative a livello europeo, nata per risolvere i problemi di interoperabilità tra le piattaforme ATM dei vari paesi. L idea è di fornire un Data Dictionary per il controllo del traffico aereo, ossia un insieme di strutture dati che rappresentano un modello da seguire nel momento in cui bisogna implementare la struttura dati FPL - FlightPlan (piano di volo) all interno di un sistema. Dal punto di vista dell interoperabilità, avere sistemi che implementano le rappresentazioni interne dei piani di volo da un comune standard di riferimento è un aspetto fondamentale. Inoltre, anche l inserimento di nuovi sistemi nel contesto delle piattaforme ATM europee risulterebbe essere accelerato nel momento in cui questi siano stati realizzati in conformità con degli standard largamente adottati. 44

45 Figura 17. Data Dictionary del progetto Avenue L immagine proposta riassume le principali strutture dati del Data Dictionary del progetto AVENUE, e dà un idea della complessità reale della struttura dati FPL, nonché delle operazioni che devono essere effettuate quando si parla di processing dei piani di volo I Requisiti di un FDPS Un sistema FDPS garantisce agli operatori ATC i servizi di gestione dei dati di volo, fornendo una piena visione operativa ed assistenza nelle fasi di: acquisizione dei dati; pianificazione: autorizzazioni di pianificazione, analisi strategica dei conflitti, sequenziamento di partenza ed arrivo; coordinamento: silent coordination, coordinamento tra autorità civili e militari; tattica: istruzioni al pilota, trasferimenti di controllo. 45

46 Il sistema FDPS esegue, inoltre, un calcolo molto accurato della traiettoria 4D (spazio, quota, tempo), mediante l'uso di modelli matematici che tengono conto dei dati del piano di volo, delle prestazioni dell'aeromobile, del vento in quota, dei dati di geografia aeronautica, dei vincoli tattici e strategici. In base alla traiettoria calcolata, viene determinata anche la lista degli operatori responsabili, per effettuare la distribuzione dei dati. Tutte queste informazioni e dati, vengono utilizzate anche per confrontare la posizione prevista di ciascun volo ed i dati provenienti dai radar per consentire la tactical conflict detection", ovvero confrontare la conformità del dato con la traiettoria attesa per permettere revisioni, rapporti di posizione, allarmi di deviazione, ecc. Il sistema FDPS in generale è affiancato da una CWP, Controller Working Position, che garantisce al controllore un'interfaccia in grado di fornire una visione strategica dei dati. Saranno di seguito riassunti i requisiti funzionali di un componente per il processing dei piani di volo schematizzandoli come segue: Creazione e cancellazione dei piani di volo Aggiornamento dello stato dei piani di volo Distribuzione dei piani di volo per ogni aggiornamento alle entità interessate secondo delle ben specificate regole di distribuzione, create e mantenute all interno del sistema Gestione della rotta, dei vincoli di viaggio, sia tattici che strategici e predizione delle traiettorie 46

47 Coordinamento e trasferimento dei piani di volo: elaborazione dei dati di environment, gestione dei messaggi ATS, monitoring del progresso del volo, correlazione traccia radar-piano di volo Viste le funzionalità che deve offrire, è chiaro che quando si parla di componente FDP lo si inquadra nel contesto dell architettura di una piattaforma ATM: in realtà si tratta di un sistema mediamente complesso, a sua volta scomponibile in più componenti che si occupano di funzionalità specifiche. Tra queste la funzionalità di business principale è quella dell aggiornamento dei piani di volo e la relativa distribuzione alle entità interessate. In gergo tecnico tale operazione prende il semplice nome di update, e per farci un idea della sua importanza presentiamo delle statistiche relative a quest operazione, raccolte da sessioni reali di utilizzo di sistemi per il flight data processing. Num.istanze totali Num.istanze attive Frequenza update Dimensione FPL upd/sec bytes Figura 18. Statistiche relative all'operazione di update in un FDPS Si intuisce che i requisiti di performance richiesti da tale categoria di sistemi sono tali che in fasi di progettazione bisogna fare degli sforzi ulteriori per ottimizzare l architettura in quest ottica. Un ulteriore elemento di difficoltà però, è che si tratta pur sempre di sistemi da inserire nel contesto di piattaforme di Air Traffic Management, quindi sottoposti a vincoli ancora più stringenti di safety, e in generale di dependability. Sebbene si tratti di requisiti non funzionali, anche questi influenzano l architettura del sistema, che deve prevedere in generale servizi e infrastrutture per soddisfare anche questo tipo di requisiti. Sarà in seguito presentato un modello architetturale per un componente per il processing 47

48 dei piani di volo. Si tratta di un core-component, ovvero di un modulo che si occupa di attività centrali nel sistema, nella fattispecie delle attività di creazione, cancellazione, aggiornamento e distribuzione dei piani di volo, da espletare tenendo conto dei requisiti funzionali e non a cui si è accennato, e che saranno ripresi e approfonditi nel presentarne l architettura di riferimento. 2.2 L Architettura presentata L architettura del sistema FDPS presentata, si affida ai servizi dei middleware per migliorare le caratteristiche del sistema nel suo complesso, allo scopo di rispettare i requisiti dei sistemi ATM già ampiamente affrontati in precedenza. Il componente FDPS presentato, si può considerare abbastanza funzionale e di conseguenza utilizzabile in sistemi reali. Figura 19. Architettura del prototipo in esame 48

49 Per descrivere il sistema FDPS partiamo dalla disamina delle operazioni da effettuare sui piani di volo. Una delle cose più importanti da svolgere è la distribuzione dei piani di volo all'interno del sistema. Il piano di volo, come detto, è una struttura dati complessa, modificata da alcune entità del sistema e scambiata tra tutte le altre entità del sistema ATM. Tutte queste operazioni devono naturalmente godere di proprietà di QoS. Trattandosi di sistema real-time il tempo di esecuzione rappresenta un requisito critico. Vista la notevole mole di dati da scambiare tra le entità in gioco (cfr. figura 18.), è di impossibile realizzazione una comunicazione diretta tra le entità. Viene a tal fine utilizzato il paradigma di comunicazione publish/subscribe fornito dal middleware DDS. L'utilizzo di un componente data-centric quale il middleware DDS, ma in generale tutto lo strato middleware, fornisce un elevato disaccopiamento tra le varie entità permettendo di realizzare un sistema scalabile e dependable. Tutti coloro che hanno bisogno di un'informazione, in questo caso il piano di volo, devono semplicemente fare una sottoscrizione; sarà poi il middleware a fornirgli la notifica dell'aggiornamento dell'informazione. In maniera analoga, l entità che modifica un piano di volo non deve preoccuparsi della sua distribuzione. Figura 20. Il Sistema e i suoi componenti principali 49

50 Tra i componenti principali del sistema in esame emergono: 1. il Facade, che rappresenta un'interfaccia unica per il generico client, 2. il Processing Server, che effettua realmente l'elaborazione, 3. il Client che invia le richieste al sistema. Per il sistema FDPS inoltre, bisogna adottare delle strategie affinché esso risulti performante ed high available. Per far ciò viene utilizzato un gruppo di Processing Server e tra tale gruppo ed il Facade viene utilizzato il servizio di LoadBalancing del middleware CARDAMOM. In questo modo il sistema acquisisce requisiti di scalabilità, ovvero se aumenta il carico di lavoro complessivo, il lavoro per singolo Processing Server non aumenta in maniera proporzionale. Inoltre, in caso di crash di un Processing Server, il servizio è comunque garantito dagli altri componenti del gruppo. Va nella direzione di rendere il sistema high available anche la replicazione e l'utilizzo di tecniche di faul tolerance per il Facade. La replicazione dei ProcessingServer e dei Facade è legata anche ad un altro fondamentale requisito nel contesto ATM, il requisito di safety: garantire la continuità di un servizio, anche a seguito di eventi anomali, migliora nel complesso il grado di safety del sistema. Introducendo tutte queste funzionalità, si rende il sistema Fault-Tolerant, cioè in grado di porre rimedio ad un fault. Il sistema sarà in grado di riconfigurasi dinamicamente al verificarsi di un fault, lavorando in maniera degradata (cioè fornendo il servizio solo in parte o sospendendolo) senza coinvolgere l'intero sistema. Il componente da rendere necessariamente Fault-Tolerant nel sistema FPDS preso in considerazione, come già accennato, è il Facade poiché rappresenta un single point of failure e svolge un ruolo critico. Per questo scopo viene utilizzato il servizio di Fault Tolerance fornito da CARDAMOM. Sarà tale servizio a sostituire il Facade primario in caso di crash. 50

51 Nella rappresentazione di figura 19 le operazioni di richiesta al sistema vengono effettuate tramite la Visu (interfaccia CWP sperimentale), le richieste al sistema possono però provenire sia dall'esterno che dall'interno del sistema ed è quindi lecito parlare di Generic Client Request. Si possono ad esempio realizzare delle classi per effettuare degli stress test, come effettuato in tale lavoro di tesi e come presentato nel capitolo successivo, oppure creare delle interfacce grafiche ad hoc per simulare le operazioni sul sistema. Per completare la trattazione, bisogna menzionare il procedimento seguito per correlare le tracce con i piani di volo presenti nel sistema. Nell'FDPS realizzato il sottosistema che ha in carico la produzione dei dati di correlazione (Correlation Data) è il CORLM. Nel dettaglio, il componente CORLM PS effettua un'operazione di matching tra i piani di volo presenti nel DDS (External Distribution) e le tracce radar create utilizzando un apposito generatore. Quando viene rilevata una corrispondenza, il CORLM PS provvede ad invocare il CORLM Facade che provvederà a pubblicare sul DDS (Correlation Data) le informazioni ottenute. In conclusione, bisogna dire che come strumento di supervisione del sistema è stato utilizzato il System Management di CARDAMOM. Per questo motivo, i componenti del sistema sono realizzati come oggetti CORBA che implementano delle interfacce IDL, ma incapsulati in uno strato funzionale che li rende entità CARDAMOM. Ciò conferisce loro l'astrazione di processo, rendendoli gestibili tramite i servizi del System Management. 51

52 2.2.1 I Componenti del Sistema Il Facade Prima di scendere nei dettagli implementativi del Facade, ne verranno ricordati alcuni aspetti. La modalità con cui esso è replicato è di tipo Warm Passive (unica possibile in CARDAMOM): vi è un Facade primario ed un Facade di backup pronto a sostituire il primario in caso di necessità. Tutte le richieste effettuate al sistema sono accettate dal Facade che rappresenta un'interfaccia unica di alto livello per il generico client, in questo modo tutte le richieste hanno un'interfaccia semplificata per le operazioni, minimizzando le dipendenze tra i client ed i Processing Server (cfr. figura 20). Il Facade costituisce il livello d'interfaccia (technical tier ) tra i Generic Client ed i ProcessingServer che rappresentano il livello di business (functional tier ) del sistema. Il Facade raccoglie, quindi, le richieste dai client e le instrada, tenendo conto delle strategie da adottare, verso i server per l'elaborazione. Figura 21. Pattern Architetturale Facade Varrà di seguito riportata l interfaccia IDL del componente Facade: 52

53 module CdmwFDPSDemo { /** * Facade interface */ interface Facade: FT::Checkpointable{ /* * callback per il ProcessingServer */ oneway void request_rtn(in Mockup::FullFDP fdp); oneway void insertfdp(in long fdpid,in string client_back); oneway void deletefdp(in long fdpid,in string client_back); }; }; //callback per il ProcessingServer nell'operazione di delete di un FDP oneway void delete_return(in Mockup::FullFDP fdp); oneway void updatefdp(in long fdpid, in string client_back); Figura 22. Interfaccia IDL del componente Facade Salta subito all'occhio la definizione delle funzioni tutte oneway per rendere la comunicazione asincrona. Le operazioni di inserimento, cancellazione ed aggiornamento del piano di volo, oltre ad avere l'identificativo dell'fpl, hanno come parametro aggiuntivo la callback del client utilizzata per restituire il risultato alla fine della fase di esecuzione. Per realizzare tale comunicazione, sono necessari altri due metodi, request_rtn() e la delete_return(). Non sono altro che la parte di codice del Facade per poter realizzare la callback. Tali metodi vengono invocati dal Processing Server per restituire il piano di volo aggiornato o creato nel caso dalla request_rtn(), o l'esito dell'operazione di cancellazione nel caso della delete_return(). A questi servizi vanno aggiunti quelli ereditati dall'interfaccia Checkpointable, interfaccia che deve essere implementata da un oggetto che utilizza il servizio di Fault Tolerance di CARDAMOM quando possiede uno stato interno da salvare e da trasferire alle copie di backup. L'implementazione dell'interfaccia Checkpointable viene effettuata dalla classe Facade_impl, che conterrà anche una serie di metodi per gestire la struttura dai piani di 53

54 volo: fare il lock di un FPL, l'unlock e salvarne lo stato. Figura 23. Diagramma delle classi del componente Facade Il problema del locking non è da sottovalutare, in quanto avendo scelto per il Facade un POA multithreaded possono sorgere dei problemi di concorrenza nell'accesso alle risorse condivise. Considerando la tabella dei lock come un vettore composto da una struttura dati Lock, in cui un campo rappresenta l'id del piano di volo ed un flag booleano indica se l'fpl considerato è locked o meno, al giungere delle richieste dei client, ogni thread processa una richiesta per un singolo FPL andando prima a leggere il flag relativo e poi a settarlo. Si tratta di un problema di lettori/scrittori generalizzato, in cui ogni entità può sia leggere che scrivere sulla risorsa condivisa. Per risolvere il problema bisogna imporre la mutua esclusione tra i thread nell'accesso alla risorsa, ottenibile con il costrutto Monitor. Per disciplinare l'accesso, bisogna aggiungere alla struttura Lock, un Monitor, ottenibile attraverso l'uso di in Mutex e di una ConditionVariable. Così facendo, è presente un 54

55 monitor associato ad ogni piano di volo che, regolando l'accesso alla risorsa, farà in modo che un solo thread alla volta si trovi nella sezione critica: l'accesso ed il processamento del piano di volo. namespace Facade{ struct Lock{ }; long id; bool flag; CORBA::String_var client_back_id; Cdmw::OsSupport::Mutex* mutex; Cdmw::OsSupport::Condition* cond; }; typedef vector<lock> VecLock; Figura 24. Struct Lock Per apprezzare l'utilizzo di questa struttura verrà di seguito riportato anche il codice delle funzioni lockfpl() ed unlockpl(). Una soluzione alternativa per l'utilizzo della risorsa condivisa potrebbe essere quella di suddividere la tabella dei lock in sotto tabelle e per ognuna di loro utilizzare un monitor. In tal modo si diminuirebbe il numero di Monitor da utilizzare ma, se due thread dovessero accedere a piani di volo diversi facenti parte della stessa sotto tabella, dovrebbero attendere l'esecuzione dell'altro diminuendo così l'efficienza del sistema. Nella struttura Lock è presente anche un campo, il campo client_back_id, necessario sia per salvare temporaneamente la callback (il riferimento al client) in modo da garantirsi la possibilità di restituire il risultato dell'operazione, sia per gestione lo stato del Facade. 55

56 int Facade_impl::lock(long fdpid){ } int index=search(fdpid); //ricerca dell'fpl //Accesso al monitor lockz[index].mutex->lock(); while(lockz[index].flag==true){ //test CV //in attesa se l'fpl utilizzato lockz[index].cond->wait(); } lockz[index].flag=true; //accesso in scrittura lockz[index].mutex->unlock(); //uscita return index; void Facade_impl::unlock(long fdpid){ } int index=search(fdpid); lockz[index].mutex->lock(); lockz[index].flag=false; recover_stato(index); //risveglio tutti i thread in attesa lockz[index].cond->broadcast(); lockz[index].mutex->unlock(); Figura 25. Funzioni lock() e unlock() Veniamo ora alla gestione Fault Tolerant del Facade. Bisogna in primo luogo dire che tale gestione si basa sia sui servizi del middleware presentati nel capitolo 1, ma anche sull'uso di un Locator e di un ActivationHandler per implementare un meccanismo di logging&recovery per la gestione dello StateTransfer tra il Facade primario e le sue repliche. Al fine di chiarire il concetto, consideriamo uno scenario in cui un client effettua una richiesta su di un piano di volo. Il Facade setta il lock associato al piano di volo a true, salva il suo riferimento ed invia la richiesta al Processing Server. Nell'eventualità che durante l'esecuzione si verifica un crash del Facade, verrà eletta una sua replica. La replica avrà il lock del piano di volo su cui è in corso l'operazione ed inoltre deve conoscere il riferimento al client che ha richiesto l'operazione per potergli restituire il risultato della stessa. Per risolvere questo problema vengono utilizzate le funzioni di utilità 56

57 save_stato(client_cback) e get_client_cback() che si occupano rispettivamente di salvare e recuperare lo stato del client. In questo modo la replica del Facade che verrà eletta sarà a conoscenza dello stato del Facade primario. Un accenno inoltre va dato anche alle funzioni on_initialize(), on_run() ed on_next_step(). Si tratta di funzioni di inizializzazione attraverso le quali vengono creati gli oggetti CARDAMOM per poter utilizzare i servizi che il middleware mette a disposizione. In particolare nel metodo on_initialize() viene inserito il codice CORBA per inizializzare la piattaforma: recupero del servizio di Naming, registrazione dell'istanza Facade sul POA e naturalmente nel servizio di Naming. Il vantaggio che si ottiene è da ricercare nell'incapsulamento dell'oggetto CORBA in un'entità CARDAMOM. Tale entità rappresenta a tutti gli effetti un processo, che può così essere supervisionato e gestito dal middleware attraverso i servizi Supervision e PlatformAdmin. Il Facade ha il compito di preparare il gruppo load balanced dei Processing Server e, per svolgere questa operazione, viene utilizzato il servizio LbGroupManagement del middleware Cardamom. La restante parte del codice è utilizzata per creare l'infrastruttura fault-tolerant per il Facade, ed in particolare il meccanismo di Logging&Recovery discusso precedentemente. In conclusione verranno descritte in maniera sintetica l'operazioni updatefpl() e request_return() fornite dal Facade. Le altre: insertfpl(), deletefpl() e delete_return() sono simili e verranno tralasciate. updatefpl: effettua l'operazione di locking del piano di volo richiesto all'interno della tabella dei lock, salva il riferimento alla callback del client da usare per ritornare il risultato dell'operazione, infine effettua la richiesta di elaborazione utilizzando il riferimento al gruppo dei ProcessingServer. Sarà il servizio di LoadBalancing a provvedere in maniera trasparente al client al dispatching della richiesta ad uno solo dei Processing Server, secondo la politica RoundRobin. 57

58 request_rtn : il piano di volo aggiornato che viene passato come parametro d'ingresso, viene pubblicato sul DDS. Si recupera il riferimento del client che aveva richiesto l'elaborazione, viene eseguito l'unlocking del piano di volo nella tabella dei lock al fine di poter eseguire le operazioni eventualmente in coda. Si ritorna al client una stringa che indica il risultato dell'elaborazione effettuata Il ProcessingServer Nell'interfaccia IDL del Processing Server sono presenti le funzioni richiamate dal Facade. Anche in questo caso sono di tipo oneway. module CdmwFDPSDemo { /** * ProcessingServer interface */ interface ProcessingServer{ // rich di aggiornamento di un FDP (comunic asincrona) oneway void updatefdp(in long fdpid,in Facade facade_back); // Funzione di cancellazione piano di volo oneway void deletefdp(in long fdpid,in Facade facade_back); // Funzione di inserimento piano di volo oneway void insertfdp(in long fdpid,in Facade facade_back); }; }; Figura 26. Interfaccia IDL del ProcessingServer L implementazione dell interfaccia IDL è fatta secondo le regole CORBA classiche, realizzando una classe PServer_impl che eredita dal codice generato dal compilatore IDL, lo skeleton, e che implementa i metodi dichiarati virtuali dell interfaccia, ossia nel caso in 58

59 esame il metodo request(). Tale metodo, che verrà descritto nel dettaglio successivamente, ha il compito di svolgere le seguenti operazioni: cerca e carica il piano di volo da elaborare dal DDS, effettua un elaborazione fittizia che riempie il campo Dati della struttura FPL e restituisce il piano di volo aggiornato al Facade tramite la callback passata in ingresso; Da menzionare è l'impostazione della policy di sincronizzazione di tipo SYNC WITH SERVER per l'oggetto callback. Come già descritto in precedenza tale policy rende la chiamata oneway sul gruppo FT di tipo reliable, in questo modo in caso di fallimento del Facade primario durante l'elaborazione del Processing Server, il messaggio di risposta sarà inviato al nuovo Facade eletto. Per rendere l'oggetto CORBA un entità CARDAMOM, ovvero un Managed Object gestibile dal System Management, si procede come per il Facade. Viene Creata la classe MyProcessPServerBehaviour che eredita dalla classe della libreria PlatformLibrary ProcessBehaviour, in modo tale che essa erediti tutto il codice necessario per essere creato all'interno di un main() come oggetto di tipo MyProcessPServerBehaviour (utilizzando la funzione CDMW init(orb, argc, argv,processbehaviour.get())) e per essere gestito a livello di sistema CARDAMOM come un processo. Figura 27. Diagaramma delle classi del componente ProcessingServer 59

60 Per impostarne il comportamento vanno opportunamente implementati i metodi on_initialize() e on_run(), così come fatto per il Facade. Nel caso del ProcessingServer, nel metodo on_initialize() si inserisce tutto ciò che è necessario per l'oggetto CORBA: si recupera il servizio di Naming, si istanzia e si registra sul POA l'oggetto ProcessingServer. In questo modo, così come per il Facade viene creato un oggetto CORBA incapsulato in un'entità CARDAMOM, che altro non è che un processo che può essere supervisionato e gestito dal middleware tramite i componenti Supervision e PlatformAdmin Il Test Client e il GroupCreatorFT Il modulo TestClient è stato inserito nell architettura con la funzione di driver dello scenario implementato, avendo il compito di generare richieste per l aggiornamento di piani di volo. Figura 28. Diagramma delle classi del componente TestClient Per poter simulare la presenza di N client, si decide di implementare la classe 60

61 ThreadClient all interno della quale verranno effettuati un certo numero di richieste per determinati piani di volo, preinseriti nel sistema. A livello di sistema, anch esso appare come un processo CARDAMOM: a tal proposito la classe MyProcessClientBehaviour, al solito, implementa le operazioni necessarie, in particolare nel metodo on_initialize() recupera il riferimento al gruppo FT dei Facade pubblicato sul servizio di Naming, che sarà usato in maniera trasparente per effettuare le richieste di aggiornamento. Nel metodo on_run() vengono creati e lanciati un certo numero di ThreadClient, dopodiché ci si mette in attesa della fine dello scenario. All interno del metodo run() di un ThreadClient è inserito il codice di business per effettuare le richieste di aggiornamento dei piani di volo: in particolare viene impostata la Synchronization policy per il riferimento facade_group ottenuto e viene istanziata e pubblicata la callback da inviare al Facade per ricevere il risultato dell elaborazione, secondo quanto già illustrato. Mostriamo a seguire l interfaccia IDL implementata da ogni client. module CdmwFDPSDemo { interface TestClient{ // servizio di calla back per il facade oneway void request_rtn(in FPL_id fdpid,in Status stato); }; }; Figura 29. Interfaccia IDL del Client Il GroupCreatorFT è un'altra entità del sistema, il cui compito è provvedere alla creazione e alla pubblicazione del gruppo di Facade fault-tolerant. A tale scopo la classe GroupCreatorProcessBehaviour implementa le operazioni necessarie: 61

62 recupera un riferimento al ReplicationManager, utilizzato per la creazione e l aggiunta delle repliche (così come il LBGroupManager) imposta i criteria per la creazione del gruppo: MinimumNumberReplicas, fissato a due, ReplicationStyle, naturalmente warm-passive, MembershioStyle, di responsabiltà dell applicazione creato l oggetto, vengono aggiunti come membri i riferimenti dei Facade recuperati tramite il servizio di Naming il group_object ottenuto è a sua volta pubblicato sul Naming, per essere acceduto dai client La comunicazione La comunicazione tra i diversi componenti del sistema FDPS, è un dettaglio implementativo molto importante, che necessita di un approfondimento. Una necessità per tutte le operazioni del sistema, è quella di realizzare tra i vari componenti una comunicazione asincrona. In caso contrario, infatti, risulterebbe inutile la replicazione dei Processing Server. Quando il Facade, ricevuta una richiesta, la inoltra ad un Processing Server utilizzando il servizio di Load Balancing, rimarrebbe bloccato in attesa della terminazione dell'operazione mettendo in coda le altre richieste, che verrebbero quindi serializzate rendendo inutile l utilizzo di un gruppo di Processing Server. Si ricorda infatti, che la scelta di utilizzare un gruppo di Processing Server è stata necessaria per aumentare la scalabilità del sistema, poiché in media un FDPS deve gestire l'aggiornamento di 100 piani di volo al secondo. Per questo motivo la comunicazione scelta è quella asincrona, e in modo particolare la distributed callback. In tale paradigma di comunicazione il client che effettua la richiesta ha un riferimento, la callback, che rimane in attesa della risposta da parte del server. In CORBA il paradigma di comunicazione asincrono è rappresentato dalle chiamate oneway: 62

63 richieste in una sola direzione, di conseguenza asincrone. Le chiamate oneway, possono avere solo parametri d'ingresso e non possono sollevare eccezioni, per questo motivo il client deve dotarsi di un'interfaccia CORBA aggiuntiva, implementando i metodi per poter ricevere le risposte alla sue invocazioni. Bisogna tenere presente che la semantica delle chiamate oneway è di tipo best effort, viene infatti utilizzato il protocollo UDP e non TCP come nelle chiamate sincrone. Nell'ambito dei sistemi critici, come quelli per la gestione del traffico aereo, è indispensabile essere sicuri dell'arrivo del messaggio al destinatario. Queste motivazioni, hanno spinto l'omg a realizzare un'espansione delle specifiche CORBA, per fornire tutti gli strumenti atti a risolvere questo genere di problemi. La specifica CORBA Messaging mira proprio a risolvere i problemi di comunicazione nei sistemi DRE, introducendo la possibilità di specificare politiche di QoS per le chiamate oneway. Utilizzando tali policies è possibile rendere affidabili" le comunicazioni, oppure realizzare il modello di comunicazione distributed callback utilizzando i servizi del middleware. Il POA del Facade viene reso multithreaded, imponendo un'apposita policy quando vengono inizializzate le strutture CORBA necessarie al funzionamento del servizio. Per realizzare ciò, viene utilizzato il servizio Foundation di CARDAMOM, che tramite la classe StrategyList permette di definire la POA Threading Policy, la quale accetta come possibili valori: Thread per request: ogni richiesta comporta la creazione di un thread; Thread Pool: è presente un numero fisso di thread utilizzato per gestire le richieste. Necessita di un ottimo dimensionamento del numero di thread. I thread vengono creati in fase di inizializzazione, una richiesta giunta quando tutti i thread sono occupati viene messa in coda in attesa che se ne liberi uno; Thread per connection: l'orb crea un solo thread per ogni connessione con il client. La scelta della soluzione da utilizzare è stata quella della politica Thread pool. 63

64 In tal modo non si genera un eccessivo overhead per la macchina ospitante, la quale non deve continuamente creare e distruggere thread. La macchina ospitante ha un numero di thread ben definito di cui può usufruire, che se ben dimensionato può adattarsi a qualunque situazione di carico del sistema. Ovviamente le richieste con tale policy, vengono servite in parallelo e non serializzate. Tale procedura permette di sfruttare in maniera adeguata il servizio di LoadBalancing. Nella comunicazione client-server tra oggetti CORBA, il server mette a disposizione un metodo oneway, dichiarato nella sua interfaccia IDL, nel quale tra i suoi vari parametri viene passato anche il riferimento alla callback del client, che verrà poi utilizzato per invocare il servizio di risposta. I riferimenti passati come callback sono, nel caso del Facade e del Processing Server, gli IOGR del gruppo FT e del gruppo LB, perché in tal modo viene mantenuta trasparenza nell'utilizzo dei servizi. Ciò comporta degli inconvenienti di compatibilità con le chiamate oneway: i servizi di LoadBalancing e di FaultTolerance si basano sul servizio di LocationForwarding. Vi sono, infatti, vari TaggedProfile che contengono diversi IOR a cui fare riferimento; se nel contattare uno di questi l'orb lato client riceve un'eccezione di LocationForward, significa che la richiesta va inoltrata al prossimo indirizzo. Il problema è situato nella semantica di invio di una chiamata oneway: dopo che la richiesta è stata affidata dall'orb lato client al livello di trasporto, il controllo ritorna all'applicazione client, rendendo impossibile sia il location forwarding sia l'acknowledgment dell'avvenuta ricezione lato server. Per risolvere questo inconveniente viene utilizzato un framework di CORBAMessaging che permette di impostare delle politiche di QualityOfService nella comunicazione. Tra le varie policy possibili, è stata utilizzata la Synchronization policy, policy che fornisce alle applicazioni la possibilità di controllare in maniera esplicita la semantica delle operazioni oneway, garantendo quindi la possibilità di implementare reliable oneway. La policy di sincronizzazione scelta è, come accennato precedentemente, SYNC WITH SERVER, in tal modo il server invia una risposta dopo aver invocato un qualsiasi servant 64

65 manager ma prima di smistare la richiesta all'oggetto target. In questo modo il client resta bloccato solo il tempo necessario affinché l'invocazione venga processata dall'orb e dal POA lato server. Con questa procedura, il client ha la sicurezza che l'oggetto remoto è stato individuato ed è possibile usufruire del location forwarding. 65

66 2.3 Analisi dell architettura originaria Per poter approfondire lo studio e la progettazione del componente Flight Data Processing, nonché l attività di analisi e le modifiche affrontate nel prosieguo di questo lavoro, si è deciso di assumere uno scenario base di riferimento, che in realtà rappresenta una funzionalità di core tra le funzionalità di business che un FDPS deve offrire: il caso d uso Aggiornamento dei Piani di Volo. Prima di proseguire, è necessaria una puntualizzazione: quando si parla di aggiornamento dei piani di volo, si è molto generici, non specificando che tipo di operazione viene effettuata tra le tante possibili. In realtà questa genericità è volutamente mantenuta poiché in questo contesto non è tanto interessante fornire un esempio pratico di come realizzare l aggiornamento della rotta o la correzione di una traiettoria, ma quali siano i passi da effettuare sui componenti del sistema e quali le interazioni necessarie tra essi per ottenere uno qualsiasi di questi risultati. Per questo motivo il piano di volo scambiato è una generica struttura dati (di cui viene presentato un esempio in IDL) con un campo Dati (i dati reali su cui fare l elaborazione), un campo Stato e un campo ID : quest ultimo serve ad identificare univocamente un piano di volo all interno del sistema, il che è una caratteristica dei piani di volo reali (la firma del FPL). module CdmwFDPSDemo { typedef string FDP_id; typedef string Status; typedef long Data; struct FDP { FDP_id fdpid; Status stato; Data dato; }; }; Figura 30. Struct FDP 66

67 In maniera del tutto analoga, una richiesta di servizio da parte di un client è rappresentata dalla generica request(), con la quale si fornisce solo l ID del piano di volo di interesse. Lato server, l operazione di processing() sarà totalmente fittizia, consistente in un certo numero di operazioni di computazione per simulare il tempo di elaborazione che un ProcessingServer spende per un certo FPL. Premesso ciò, viene di seguito presentato un sequence diagram che aiuta a dettagliare quali siano i passi svolti nello scenario, a chiarire le interazione (i messaggi scambiati, essendo nel modello ad oggetti) tra i componenti, e alcuni vincoli necessari che introducono alla sezione sulle modifiche progettuali. Figura 31. Sequence diagram del caso d'uso Aggiornamento di un FDP 67

68 L interazione necessaria per effettuare l aggiornamento di un piano di volo è la seguente: 1. un generico client invia una richiesta di aggiornamento al sistema (1); esso non attende che venga effettuata l elaborazione, ma sarà avvisato solo al termine di quest ultima (meccanismo asincrono); 2. la richiesta effettuata dal client viene raccolta dal componente di front-end, il Facade. In base al parametro FPL_id, che identifica univocamente un piano di volo, il Facade verifica se sono in corso altre richieste di aggiornamento per lo stesso FPL: in caso affermativo la nuova richiesta viene messa in coda, altrimenti si può procedere con l inoltro ai ProcessingServer, dopo aver effettuato un lock del piano di volo (2) in un apposita struttura dati (tabella dei lock). Effettuato il lock,e salvato il suo stato (3) il Facade può inoltrare la richiesta al gruppo dei ProcessingServer (4) affidandosi al servizio di LoadBalancing del middleware, che provvede al dispatching della richiesta secondo la policy adottata. 3. Quando la richiesta giunge ad un ProcessingServer, quest ultimo carica il piano di volo su cui effettuare l elaborazione dal DDS (5-6). Sul piano di volo viene effettuata l elaborazione (7), sulla quale non viene specificato nulla, e la struttura dati così aggiornata viene restituita, come parametro d uscita o di ritorno, al Facade (8) che provvede alle ultime operazioni. 4. Arrivata la risposta al Facade, si è nella situazione in cui solo il ProcessingServer che ha effettuato l elaborazione possiede, nella sua cache, la versione aggiornata del FPL, mentre tutti gli altri componenti, ad esempio gli altri ProcessingServer devono allineare il loro stato. Per fare ciò si utilizza il DDS: il Facade provvede a pubblicare il piano di volo aggiornato (9) e la sua copia compatta (10-11), di modo che tutti i subscriber interessati (i ProcessingServer e gli altri componenti del 68

69 sistema ATM) possano accedere alla nuova versione. A questo punto il Facade effettua le ultime operazioni, recupera la callback del client (12), sblocca il piano di volo nella tabella dei lock (13), in modo tale che altre richieste in attesa per quel piano di volo possano essere soddisfatte, e restituisce al client che aveva effettuato la richiesta un parametro stato, che indica ad esempio il successo o meno dell operazione (14) Le inefficienze individuate L architettura presentata in questo capitolo, il cui comportamento è stato schematizzato nello scenario di cui sopra, è il frutto di un evoluzione, avuta nel tempo, di un prototipo dalle caratteristiche simili ma che in principio utilizzava tecnologie differenti. La versione precedente di tale prototipo, infatti, non faceva uso del DDS come middleware per la distribuzione dei dati ma utilizzava un Data Store Distribuito su cui venivano memorizzati i Piani di Volo. L architettura così costituita era quindi inevitabilmente priva di tutti i benefici che sono messi a disposizione, in maniera trasparente, da un middlware di tipo DDS che, come più volte ripetuto, lascia all utente il solo compito di implementare la business logic, facendosi esso stesso carico di tutti i problemi che un architettura distribuita può portare, primi fra tutti quello della concorrenza tra i processi e della coerenza tra i dati. E per questo motivo che, non essendoci un disaccoppiamento tra l Application e il Data level, disaccoppiamento introdotto con l inserimento del DDS, alcuni dei problemi relativi all architettura distribuita erano gestiti a livello applicativo, il che ha portato a delle scelte progettuali non dettate esclusivamente dalla logica e dal funzionamento del Sistema. Entrando nel dettaglio infatti, il problema principale di questo tipo di architettura era la gestione delle scritture dei Piani di Volo sul Data Store. Come si evince dai paragrafi precedenti, infatti, nell architettura si è fatto in modo che un solo componente nel sistema, 69

70 il Facade, avesse l onere di scrivere sul Data Store. Questo perché, avendo nel sistema più di un Processing Server, se ognuno di essi avesse effettuato scritture sul Data Store Distribuito, sarebbe nato il problema di gestire l ordine con cui tali scritture fossero fisicamente fatte sulla Base Dati, problema che, con le tecnologie utilizzate in quell architettura era di impossibile risoluzione. Si è quindi preferito fare in modo tale che fosse solo il Facade a scrivere sul Data Store con l evidente conseguenza che l ordine delle scritture logiche andasse inevitabilmente a coincidere con quelle fisiche, evitando in questo modo, qualsiasi problema di incoerenza tra i dati inseriti nel Data Base. Con l introduzione del DDS però, tale problema viene gratuitamente risolto, in quanto è il DDS stesso che ha il compito di gestire l ordine con cui le scritture vengono eseguite, lasciando quindi a chi progetta la libertà di inserire la scrittura del Piano di Volo in un qualsiasi punto del flusso elaborativo e su qualsiasi componente, facendo in modo che tale scelta sia dettata esclusivamente da ragioni architetturali e/o funzionali. A tal proposito risulta evidente come, nell architettura appena presentata, che lascia inalterata la logica applicativa, andando soltanto a sostituire al Data Store Distribuito il middleware DDS, il flusso di elaborazione sia ancora influenzato dalle decisioni prese per risolvere i problemi di incoerenza. La scrittura del Piano di Volo da parte del Facade, in particolare, è il punto su cui verrà posta più attenzione. Ragionando esclusivamente da un punto di vista architetturale, è buona norma fare in modo che ogni componente del sistema abbia un suo ruolo : il Facade quello di interfaccia unica verso il sistema e il Processing Server quello di elaborazione vera e propria dei dati del piano di Volo. Tale divisione però, non è così netta nella architettura appena presentata, nella quale il Facade, oltre a svolgere il suo ruolo di interfaccia, ha anche il compito di scrivere sul DDS il Piano di Volo, aggiornato e passatogli dal Processing Server, compito che rende un po ibrido il suo comportamento. 70

71 Oltre che dal punto di vista architetturale, tale ragionamento può essere fatto anche valutando le performance del sistema. Affidando le operazioni di scrittura ai ProcessingServer, anziché al Facade, si avrebbero due conseguenze immediate che potrebbero portare ad un miglioramento delle prestazioni del prototipo : Essendo in configurazione di Load Balancing, le scritture che prima erano eseguite interamente sul Facade, unico, andrebbero divise tra i Processing Server che si dividerebbero quindi il carico applicativo. Il Processing Server che adesso effettua l aggiornamento del Piano di Volo, scrivendo anche sul DDS, potrebbe evitare di restituire l intera istanza del Piano di Volo al Facade, che non ne avrebbe più bisogno. Il parametro di ritorno della callback, in questo caso, potrebbe diventare l id dell FDP in esame e non più l intera struttura dati, andando a diminuire la dimensione dei dati restituiti attraverso CORBA. 2.4 La soluzione proposta A valle delle considerazioni poc anzi fatte, è necessario entrare nel merito delle modifiche che, in tale lavoro di tesi, andranno svolte sul prototipo fin ora descritto al fine di apportare dei miglioramenti sia da un punto di vista architetturale sia da un punto di vista di prestazioni. La modifica che andrà fatta non va ad invalidare nessuna delle considerazioni di carattere generale descritte nei paragrafi precedente, né va a modificare la struttura delle classi del prototipo in esame. Essa si limita a modificare la sequenza nel flusso di elaborazioni anticipando la scrittura sul DDS del Piano di Volo aggiornato nel Processing Server e alleggerendo la logica della callback sul Facade che, a questo punto, dovrà semplicemente 71

72 sbloccare il piano di volo in esame e richiamare la callback su client. Tali modifiche possono essere chiarite percepite attraverso il seguente diagramma di sequenza. Figura 32. Sequence diagram del caso d'uso Aggiornamento dopo la modifica Entrando nel dettaglio, il flusso di elaborazione è stato così modificato: 1. un generico client invia una richiesta di aggiornamento al sistema (1); esso non attende che venga effettuata l elaborazione, ma sarà avvisato solo al termine di 72

73 quest ultima (meccanismo asincrono); 2. la richiesta effettuata dal client viene raccolta dal componente di front-end, il Facade. In base al parametro FPL_id, che identifica univocamente un piano di volo, il Facade verifica se sono in corso altre richieste di aggiornamento per lo stesso FPL: in caso affermativo la nuova richiesta viene messa in coda, altrimenti si può procedere con l inoltro ai ProcessingServer, dopo aver effettuato un lock del piano di volo (2) in un apposita struttura dati (tabella dei lock). Effettuato il lock e aslvato il suo stato (3), il Facade può inoltrare la richiesta al gruppo dei ProcessingServer (4) affidandosi al servizio di LoadBalancing del middleware, che provvede al dispatching della richiesta secondo la policy adottata. 3. Quando la richiesta giunge ad un ProcessingServer, quest ultimo carica il piano di volo su cui effettuare l elaborazione dal DDS (5-6). Sul piano di volo viene effettuata l elaborazione (7), sulla quale non viene specificato nulla, e la struttura dati così aggiornata, insieme alla sua copia compatta, viene registrata sul DDS (8-9-10). Al Facade, come parametro d uscita o di ritorno, il ProcessingServer provvederà ad inviare soltanto l id del piano di volo modificato e non più l intera sua istanza (11). 4. Arrivata la risposta al Facade, grazie al DDS, già tutti i subscriber interessati (gli altri ProcessingServer) saranno a conoscenza della nuova versione del piano di volo. A questo punto il Facade si limita a sbloccare il piano di volo nella tabella dei lock (13) e a restituire al client che aveva effettuato la richiesta il parametro stato, che indica il successo o meno dell operazione (14). Viene di seguito riportato il codice relativo ai due componenti in esame, il Facade e il ProcessingServer, e ai metodi finora descritti. 73

74 void Facade_impl::updateCB(CORBA::Long fdpid,const char* client_back)throw(corba::systemexception){ } std::cout << "[INF] DemoFacade_impl - Request for FDPID = " << fdpid << " -" << std::endl; //====Lock the FDP===== int index=blocca(fdpid); save_stato(index,client_back); //============Call the LB-group================ ps_group_interface->requestcb(fdpid,facade_group,client_back);... void Facade_impl::request_rtn(CORBA::Long fdpid, const char* client_back) throw(corba::systemexception){ std::cout << "\n -- REQUEST RETURN -- \n"; Cdmw::CommonSvcs::Naming::NamingInterface ni = Cdmw::NamingAndRepository::RepositoryInterface::get_domain_namin g_interface ("demo_fdps/hello_clients"); CORBA::Object_var obj; CdmwFDPSDemo::ClientCB_var client_back_ref; try { obj = ni.resolve (client_back); client_back_ref = CdmwFDPSDemo::ClientCB::_narrow(obj.in()); } catch (const CORBA::SystemException& e) { std::cerr << FILE << " " << LINE << std::endl; } //====Unlock the FDP====== sblocca(fdpid); //====Return to client==== client_back_ref->request_rtn(fdpid,0); } std::cout << "[INF] DemoFacade_impl - Request for FDPID = " << fdpid << " entirely served - " << std::endl; Figura 33. Implementazione dei metodi updatefdp() e request_rtn() del Facade 74

75 void ProcessingServer_impl::updateFDP(CORBA::Long fdpid, ::CdmwFDPSDemo::Facade_ptr facade_back, const char* client_back) throw(corba::systemexception){ std::cout << "Elaborazione per l'fdpid " << fdpid << endl; //RELIABLE ONEWAY: imposto la policy a livello di oggetto*/ CORBA::PolicyList policy_list; policy_list.length(1); CORBA::Any object_level; object_level <<= Messaging::SYNC_WITH_SERVER; policy_list[0]=the_orb->create_policy (Messaging::SYNC_SCOPE_POLICY_TYPE,object_level); CORBA::Object_var object = facade_back->_set_policy_overrides (policy_list,corba::set_override); facade_back = CdmwFDPSDemo::Facade::_narrow(object.in()); //recupero del FPD dal DDS Mockup_FullFDPDataReader *FullMessageDDS_reader= Mockup_FullFDPDataReader::narrow( reader ); Mockup_FullFDPSeq data_seq; DDS_SampleInfoSeq info_seq; Mockup::FullFDP_var fdp_temp = new Mockup::FullFDP(); fdp_temp->key=fdpid; DDS_InstanceHandle_t fdp_handle=dds_handle_nil; fdp_handle = FullMessageDDS_reader->lookup_instance(*fdp_temp); if(dds_instancehandle_is_nil(&fdp_handle)) std::cout << "[INFO DDS_HANDLE]:!!!WARNING handle non registered!!!" << std::endl; else std::cout << "[INFO DDS_HANDLE]: Handle registered by the FDP publisher" << std::endl; retcode = FullMessageDDS_reader->read_instance (data_seq,info_seq,dds_length_unlimited, fdp_handle,dds_any_sample_state,dds_any_view_s TATE,DDS_ANY_INSTANCE_STATE); if( data_seq.length()>0) *fdp_temp=data_seq[0]; else std::cout << "!!!WARNING no data for the specified ID"; FullMessageDDS_reader->return_loan( data_seq, info_seq ); // Elaborazione sull fdp std::cout << "ELABORATION... " << std::endl; fdp_temp->revision=fdp_temp->revision+10; 75

76 fdp_temp->key=fdpid; //======= write public on_dds ========================== DDS_InstanceHandle_t ffdp_handle= FullMessageDDS_writer->lookup_instance(*fdp_temp); if( DDS_InstanceHandle_is_nil(&ffdp_handle)) { ffdp_handle=fullmessagedds_writer->register_instance (*fdp_temp); } else std::cout << "[ntinfo DDS_HANDLE]: FDP handle already registered" << std::endl; FullMessageDDS_writer->write(*fdp_temp, ffdp_handle); //======================================================= //================Extract the PUBLIC fdp================= Mockup::CompactFDP c_fdp; c_fdp.key=fdp_temp->key; c_fdp.revision=fdp_temp->revision; c_fdp.ssr=fdp_temp->ssr; Mockup::extract_PublicFlightPlanData(c_fdp.fpd,fdp_temp->fpd); Mockup::extract_PublicTrajectory(c_fdp.traj,fdp_temp->traj); //======================================================= //============== Write compact ========================== DDS_InstanceHandle_t cfdp_handle = DDS_HANDLE_NIL; cfdp_handle = CompactMessageDDS_writer->lookup_instance(c_fdp); if( DDS_InstanceHandle_is_nil(&cfdp_handle)) { cfdp_handle=compactmessagedds_writer->register_instance (c_fdp); } else std::cout << "[INFO DDS_HANDLE]: FDP handle already registered" << std::endl; CompactMessageDDS_writer->write( c_fdp, cfdp_handle); //====================================================== try{ facade_back->request_return(fdp_temp->key,client_back); } catch (const CORBA::SystemException& e) { std::cout << " ===> SystemException received: " << Cdmw::OrbSupport::OrbSupport::exception_to_string(e); } } Figura 34. Implementazione del metodo updatefdp() nel ProcessingServer 76

77 Capitolo 3 La verifica sperimentale In questo capitolo sarà illustrata dettagliatamente la fase sperimentale del lavoro, nella quale sono state condotte campagne di test atte a valutare le prestazioni del sistema in esame. Sarà descritta la modalità con cui tali test sono stati effettuati, i loro obiettivi, nonché i criteri di valutazione utilizzati e i risultati da essi ottenuti. 3.1 Obiettivi della valutazione Obiettivo principale di questo lavoro è quello di effettuare un analisi quantitativa dell impatto che, dal punto di vista prestazionale, la modifica architetturale descritta nel capitolo precedente, ha sul funzionamento dell intero sistema. La migrazione di parte della business logic dal Facade Server ai Processing Server, presuppone una diminuzione del carico applicativo sul Facade, carico che sarà ridistribuito e bilanciato, con l ausilio del servizio di Load Balancing di Cardamom, sui diversi Processing Server, alleggerendo il lavoro dell unico Facade. Questa modifica, unita al fatto che, in questo modo, sarà possibile non restituire al Facade, attraverso CORBA, l intera istanza del Piano di Volo ma solo il suo Identificativo, 77

78 dovrebbe migliorare le prestazioni generali del sistema. Verificare sperimentalmente tali considerazioni, svolte in una fase preliminare di analisi, è lo scopo di questa parte del lavoro che, attraverso la misura delle prestazioni del sistema prima e dopo la suddetta modifica, può condurre ad una conferma o ad una smentita delle stesse. Per effettuare tali verifiche il lavoro è stato suddiviso in tre fasi principali: Fase I : Analisi delle Performance. In tale fase è stato effettuato uno studio delle prestazioni del sistema prima della modifica architetturale. E stata condotta una prima sessione di test, che verrà di seguito descritta nel dettaglio, e valutati i risultati che da essa sono emersi. Fase II : Modifica dell architettura. In tale fase sono state effettuate le modifiche sull architettura del sistema di cui si è ampiamente discusso in precedenza ed è stato testato funzionalmente il suo comportamento. Fase III : Analisi degli impatti. In tale fase, è stata condotta nuovamente la stessa sessione di test della Fase I e, i risultati riscontrati, sono stati confrontati con quelli ottenuti precedentemente. E stato possibile, in questo modo, verificare sperimentalmente dal punto di vista delle prestazioni l impatto che la modifica ha avuto sul funzionamento del sistema in esame. 78

79 3.2 Tecniche di Valutazione e Misurazione Stabilire quali dovessero essere la grandezza o le grandezze da misurare per effettuare uno studio delle prestazioni del sistema, è stato il primo passo svolto nella fase di analisi delle attività da svolgere. A valle di tale fase, la scelta dell indice di prestazione è ricaduta sulla misura del tempo medio impiegato dal sistema per eseguire una serie di operazioni. In particolare si è provveduto alla creazione di un benchmark che ha il compito di calcolare, sui Client, due timestamp, t1 e t2, rispettivamente prima dell invocazione dell elaborazione sul Facade e subito dopo la relativa callback; ogni misura quindi, è stata calcolata come la differenza tra le quantità t2 e t1. I tempi di inizio e fine così rilevati sono memorizzati, per ogni Client, in due file di testo e tali valori saranno poi elaborati con l ausilio di MATLAB, un tool specializzato nel calcolo numerico e nell analisi e rappresentazione grafica dei dati. Vengono di seguito riportati i due frammenti di codice nei quali sono rilevati i tempi di inizio e fine dell elaborazione. In particolare il tempo di inizio è calcolato nel file ClientThread.cpp, thread che ha il compito di sostituire l interfaccia grafica per generare l invio delle richieste al Facade; il tempo di fine è invece rilevato nel file Client_impl.cpp, implementazione dell interfaccia ClientCB.idl, in cui è presente la logica associata alla callback sul Client. Il nome del File su cui scrivere i valori rilevati è passato ad entrambi i componenti dal ProcessClientBehaviour che ha il compito di istanziarli, inizializzarli e configurarli per l interazione con Cardamom e CORBA. 79

80 void ClientThread::run() throw() {... srand(time(null)); Cdmw::OsSupport::OS::sleep(rand() % m_freq); //Ciclo di 100 richieste for(int j=0;j<100;j++) { int i =(rand() % m_nfdp); try{ // // CALCOLO TEMPI INIZIALI // gettimeofday(&t1,null); tempoin = (t1.tv_sec* )+(t1.tv_usec); tempi << codici[i] << "\t" << tempoin << "\n"; tempi.flush(); // // FINE CALCOLO TEMPI INIZIALI // //Invocazione dell update sul Façade Server facade_interface->updatecb(codici[i],client_back_id.c_str()); } catch (const CORBA::SystemException& e) { std::cout<< "ECCEZIONE Request num." << i << " del thread n." << id_thread << "con codice " << codici[i]<<std::endl; std::cout << " ===> SystemException received: " << Cdmw::OrbSupport::OrbSupport::exception_to_string(e) << std::endl; } } Cdmw::OsSupport::OS::sleep(m_freq); tempi.close(); std::cout<< "***DEMO STOPPED***" <<std::endl;... } Figura 35. Rilevazione dei tempi iniziali nel file ClientThread.cpp 80

81 void ClientCB_impl::update_return(CORBA::Long fdpid,corba::long status) throw(corba::systemexception){... // // CALCOLO TEMPI FINALI // // Variabili per calcolare il tempo di fine richiesta struct timeval t2; long time = 0; gettimeofday(&t2,null); time=(t2.tv_sec* )+(t2.tv_usec); tempi << fdpid << "\t" << time << "\n"; tempi.flush(); // // FINE CALCOLO TEMPI FINALI // } request_count++; std::cout << "[Debug-Client]:risultato Callback per il FDP: " << fdpid << " = " << status << std::endl; std::cout << "[Debug-Client]:Num.rich eseguite con successo ->" << request_count << std::endl;... Figura 36. Rilevazione del tempo di fine nel file Client_impl.cpp Il sistema, in questo modo, è considerato come una black box (cfr. figura 37) e la stima dei tempi è effettuata all ingresso e all uscita di quest ultima, indipendentemente da come il sistema si comporti al suo interno. 81

82 Questo perché, a valle delle modifiche architetturali, sarà possibile effettuare nuovamente la stessa sessione di test, lasciando inalterato il benchmark e sostituendo solo il sistema su cui esso opera. Timestamp t1 Client Timestamp t2 write CDMW FT Facade Primary Facade Backup read CDMW LB Server 3 Server 2 Server 1 Full FDP Compact FDP read read read Figura 37. Architettura del sistema e collocazione del benchmark 3.3 Progettazione del benchmark La fase di analisi delle attività di test ha previsto inoltre una seconda fase, quella in cui, cioè, sono stati valutati tutti i parametri che potessero influenzare in qualche modo il tempo di elaborazione delle richieste. Tra questi, sono emersi i seguenti parametri: 1. La Frequenza con la quale i Client richiedono sequenze di elaborazione al Facade 82

83 Server. Tale parametro influenza la quantità di elaborazioni e di conseguenza la quantità di risorse utilizzate da tale componente, aumentando o diminuendo il carico applicativo a sua responsabilità. 2. Il Numero di Client che effettua richieste al Facade. Tale parametro influenza in prima istanza il carico applicativo insistente sul Facade (che aumenta all aumentare del numero di Client) e, in secondo luogo, la probabilità che vengano effettuate più richieste relative allo stesso Piano di Volo, influenzando, quindi, il tempo medio di attesa sui lock. 3. Il Numero di Piani di Volo (FDP) risiedenti sul DDS e sui quali vengono effettuate le richieste da parte dei Client. Anche questo parametro influenza la probabilità di un eventuale attesa prima che un Piano di Volo sia libero, a causa di un eventuale suo lock concesso ad una richiesta precedente. Tali parametri vanno in linea di massima ad influenzare principalmente due caratteristiche che potrebbero costituire due punti di criticità del sistema e modificarne quindi il tempo di elaborazione; tali caratteristiche sono: il numero di elaborazioni che, nell unità di tempo, il Facade deve servire; il numero di richieste fatte in contemporanea sullo stesso piano di volo. A valle di queste considerazioni, si è ritenuto opportuno mantenere costante il Numero di piani di Volo su cui eseguire le richieste e, in particolare, si è deciso di fissare il suo valore ad un valore realistico fornito dai partner industriali del progetto (cfr. figura 18), ritenendo che tale numero sia sufficientemente grande da non influenzare l andamento della sessione di test. 83

84 Viceversa è stato scelto di far variare gli altri due parametri, ovvero il Numero di Client e la frequenza con cui questi richiedono elaborazioni al sistema. Questa scelta, infatti, permette di eseguire una sessione di test pressoché completa che, partendo da una situazione di carico normale, riesce a stressare il sistema intervenendo sulle due componenti critiche precedentemente individuate. Partendo quindi dal presupposto che i requisiti del prototipo sviluppato richiedevano che il sistema supportasse una frequenza di 100 richieste al secondo (provenienti complessivamente da tutti i client), si è deciso di far variare i parametri di cui sopra secondo lo schema riportato in tabella: Figura 38. Sessione di test In realtà, quello che viene modificato nel benchmark, oltre al numero di Client, è il periodo di invocazione delle richieste, che rappresenta l intervallo di tempo che trascorre tra un invocazione da parte del Client e la successiva. Verrà di seguito riportata, per chiarezza, una tabella contenente il mapping tra i valori del periodo di invocazione e quelli di frequenza che saranno utilizzati nel resto del lavoro. 84

85 PERIODO FREQUENZA 500 ms 2 ric/sec 200 ms 5 ric/sec 100 ms 10 ric/sec 50 ms 20 ric/sec 10 ms 100 ric/sec Consideriamo come situazione limite di corretto funzionamento la condizione in cui al sistema vengono sottoposte circa 100 richieste al secondo, la sessione di test comprende casi in cui il sistema è poco stressato (funzionamento nominale) e casi in cui il sistema è sottoposto a un carico superiore a quello limite (funzionamento in condizioni di stress). In questo modo è stato possibile avere una visione piuttosto completa di quelle che sono le prestazioni del prototipo in esame. Per ogni caso di test sono state effettuate 100 richieste per client e calcolato il tempo medio su tutti i risultati; il risultato è stato poi opportunamente depurato di eventuali valori spuri, ovvero troppo lontani dal risultato medio. Nel caso di più client i risultati sono stati calcolati singolarmente nella modalità appena descritta e poi effettuata la media tra questi ultimi. C è da tenere in considerazione che, oltre alla stima del tempo medio impiegato dal sistema per eseguire una richiesta, come altro parametro, è stato considerato il numero di elaborazioni che, nella sessione di test, sono andate a buon fine. Questo parametro infatti, può dare una stima dell affidabilità del sistema al variare della condizione di stress ad esso applicata. Si presuppone che, nel caso di funzionamento nominale, il numero di richieste soddisfatte correttamente sia pressoché uguale al numero di richieste inviate; oltre il limite imposto dai requisiti invece, tale numero può iniziare a decrescere, coerentemente con l aumentare del carico applicato al sistema. 85

86 3.4 Il Sistema di Riferimento Verrà di seguito descritto nel dettaglio il testbed su cui i test sono stati effettuati, prestando particolare attenzione sulla configurazione delle macchine e dei singoli processi che su di esse sono in esecuzione. Entrando nel dettaglio, lo scenario su cui la demo è stata eseguita è costituito da 3 macchine host, denominate per semplicità HOST1, HOST2 e HOST3, ognuna delle quali sarà di seguito descritta sia in termini di caratteristiche hardware e prestazionali, sia in termini di processi e applicazioni che girano su di esse. 1. HOST 1 (N. 2 CPU Xeon 2.8 Ghz con Hyperthreading, 6 GB di memoria RAM, Disco fisso di 36 GB, N. 2 interfacce Gigabit Ethernet, N. 1 interfaccia Myrinet 2+2Gbit) Su tale macchina risiedono i processi di Cardamom che gestiscono: Naming and Repository; Fault Tolerance (FT Manager); il Platform Daemon, presente su ogni host; e il Platform Supervision Server (SMG Supervision), unico nel sistema; Sono inoltre in esecuzione: uno dei 3 Processing Server; e il o i Client che utilizzano il sistema. 2. HOST 2 (N. 2 CPU Xeon 2.8 Ghz con Hyperthreading, 6 GB di memoria RAM, Disco fisso di 36 GB, N. 2 interfacce Gigabit Ethernet, N. 1 interfaccia Myrinet 2+2Gbit) Su tale macchina risiede il processo di Cardamom che gestisce: il Load Balancing tra i 3 Processing Server (LB-Group Observer); e il Platform Daemon, presente su ogni host; 86

87 Sono inoltre in esecuzione: uno dei 3 Processing Server; e uno dei 2 Facade Server (quello di backup). 3. HOST 3 (N. 2 CPU Xeon 2.8 Ghz con Hyperthreading, 6 GB di memoria RAM, Disco fisso di 36 GB, N. 2 interfacce Gigabit Ethernet, N. 1 interfaccia Myrinet 2+2Gbit) Su tale macchina risiede: il Platform Daemon, presente su ogni host; e sono inoltre in esecuzione: uno dei 3 Processing Server; uno dei 2 Facade Server (quello primario). e i componenti CORLM (Corlm Processing Server e Corlm Facade). La figura sottostante riassume graficamente quanto appena descritto. Figura 39. Configurazione dello scenario 87

88 3.5 Risultati Fase 1 : Analisi delle Performance Verranno di seguito illustrati i risultati ottenuti nella prima sessione di test, il cui scopo è stato quello di studiare il sistema nel suo complesso e capire come esso si comportava al variare di parametri che andassero a influenzare il carico elaborativo che incide su di esso. I primi test effettuati sono stati i quelli relativi alla configurazione del sistema in cui un solo Client ha il compito di inviare richieste di elaborazione al Facade e tali test sono stati ripetuti al variare della frequenza, che ha assunto i valori illustrati in precedenza. I risultati di tali test sono illustrati nella figura 40. Figura 40. Risultati dei test con un Client Dai risultati emersi il tempo medio per eseguire una richiesta cresce al crescere della frequenza con cui tali richieste sono effettuate. Tale comportamento risulta plausibile se si considera il fatto che, aumentando la frequenza di invocazione delle richieste, aumenta inevitabilmente il numero di elaborazioni nell unità di tempo a carico del Facade. Il tempo medio, inoltre, cresce notevolmente quando il sistema è nella condizione 88

89 considerata limite (100 richieste al secondo), nel quale tutte le richieste sono soddisfatte correttamente ma in tempi maggiori. Anche tale situazione può essere considerata ragionevole poiché le richieste sono effettuate in modalità casuale sui piani di volo risiedenti sul DDS e quindi la probabilità di trovare un FDP bloccato perché già utilizzato da una richiesta precedente cresce notevolmente, portando ad una aumento del tempo di attesa sui lock per concludere il flusso di elaborazione. Gli stessi test sono stati poi ripetuti anche con 5, 10, 15 e 20 Client in parallelo, riscontrando più o meno lo stesso andamento dei risultati. Al crescere del numero dei Client e della frequenza di invocazione delle richieste però, ovvero quando il sistema era sotto stress, non tutte le richieste sono pervenute a destinazione. Il tempo medio, in questi casi, è stato calcolato sulle sole richieste andate a buon fine. Figura 41. Riassunto dei risultati dell'intera sessione di test 89

90 In figura 41 è riportato un resoconto generale dei risultati di tutta la sessione di test, comprendente il risultato dei tempi rilevati (in microsecondi) e il numero di richieste andate a buon fine nello specifico test. Nelle figure 42 e 43 sono mostrati invece i risultati appena espressi sotto forma tabellare in due grafici che illustrano in maniera più immediata i tempi al variare di numero di Client e frequenza di invocazione. In tali grafici sono riportati solo i risultati dei test in cui il sistema ha risposto correttamente a più del 50% delle richieste inoltrate. Gli altri casi infatti, sono da ritenersi non troppo affidabili ai fini della valutazione poiché, essendo il sistema sottoposto ad un carico superiore a quello limite, potrebbe non aver risposto in maniera attendibile. Figura 42. Risultati dell'intera sessione di Test I tempi medi calcolati crescono all aumentare del numero di Client e della frequenza di invocazione delle richieste, essi inoltre risultano essere dello stesso ordine di grandezza quando il sistema è in condizione di funzionamento nominale (più Client a frequenza di 2 ric/sec o 1-2 Client a diverse frequenze), mentre iniziano a crescere notevolmente quando 90

91 al sistema è applicato un carico notevole. Tale considerazione risulta forse più evidente nel grafico di seguito riportato, nel quale gli stessi risultati sono illustrati in un grafico di carattere tridimensionale. Figura 43. Performance del Sistema 3.6 Risultati Fase 3 : Analisi degli Impatti Verranno di seguito riportati i risultati della seconda sessione di test effettuata a valle della modifica architetturale che ha previsto lo spostamento della logica relativa alla scrittura sul DDS dei Piani di Volo dal Facade ai Processing Server. Tali risultati verranno poi confrontati con quelli presentati prima, in modo da analizzare nel dettaglio gli effetti del cambiamento. 91

92 Si ricorda che, in questa fase, il testbed utilizzato e il workload applicato allo scenario sono esattamente gli stessi della fase precedente; l unico componente ad essere stato modificato è il sistema sotto esame (black-box). Figura 45. Risultati dei test dopo la modifica con un Client Figura 44 Risultati complessivi della seconda sessione di Test 92

93 Nella tabella precedente sono riportati i risultati di tutta la sessione di test, comprensivi del valore dei tempi rilevati (in microsecondi) e del numero di richieste andate a buon fine nello specifico test. L andamento generale dei tempi, in relazione alla condizione di stress del sistema, è rimasta pressoché uguale al caso precedente. Anche in questo caso, infatti, il tempo medio necessario all elaborazione delle richieste cresce al crescere delle condizioni di stress del sistema (frequenza di invocazione e numero di Client). C è da rilevare però che, a valle della modifica architetturale, il sistema offre un servizio migliore dal punto di vista dell affidabilità. Esso, infatti, risponde in maniera corretta a tutte le richieste inviategli anche in condizioni di maggiore stress, limitando a sole due combinazioni i casi di test in cui il numero di elaborazioni andate a buon fine è minore di 100 (numero di richieste effettuate). Figura 46. Risultati della seconda sessione di test Tale miglioramento può essere giustificato dal fatto che le scritture sul DDS, che prima erano interamente a carico del Facade, adesso sono distribuite sui 3 Processing Server. Questo bilanciamento del carico applicativo (n/3 scritture per ogni server invece di n 93

94 scritture tutte a carico del facade), fa sì che i componenti dell architettura siano sottoposti ad una condizione di minore stress, migliorandone il funzionamento e garantendone una maggiore affidabilità. Figura 47. Risultati della seconda sessione di test Anche in questo caso, nei grafici appena presentati, non sono presenti i risultati relativi ai casi in cui il sistema ha risposto correttamente ad un numero inferiore di 50 richieste (50% delle richieste totali). 3.7 Gli effetti della modifica Verranno in questo paragrafo messi a confronto i risultati delle due sessioni di test presentate prima singolarmente, osservate nel dettaglio le loro differenze e analizzate le motivazioni che a tali differenze hanno condotto. In tal modo sarà possibile comprendere 94

95 se e in che modalità la modifica applicata al sistema ha influito sulle sue prestazioni. Figura 48. Confronto dei risultati nel caso di un Client Partiamo dal considerare il caso in cui ad effettuare richieste al sistema sia stato un solo Client; come si evince dalla figura di cui sopra, i tempi medi per effettuare le elaborazioni sono migliorati a valle della modifica architetturale. Tale miglioramento risulta minimo nel caso di funzionamento nominale del sistema, cresce all aumentare del numero di richieste al secondo e risulta molto evidente nel caso di 100 richieste al secondo, caso in cui il sistema (cfr figura 38) risulta in una condizione di funzionamento limite. Anche nel caso di 5 e 10 Client i risultati della seconda sessione di test sono molto inferiori a quelli della prima, in molti casi infatti, che corrispondono ai casi in cui il sistema è in una condizione considerata di stress, i valori rilevati risultano più che dimezzati rispetto ai precedenti, portando ad un miglioramento delle prestazioni del sistema di un più del 50 %. 95

96 Figura 49. Confronto dei risultati nel caso di 5 Client Figura 50. Confronto dei risultati nel caso di 10 Client 96

97 Nel caso di 15 Client, le differenze rispetto al caso precedente sono notevoli. Oltre ad un miglioramento del tempo medio per eseguire le richieste infatti, che continua a crescere con l aumentare della condizione di stress, si registra un numero maggiore di elaborazioni andate a buon fine. Figura 51. Confronto dei risultati nel caso di 15 Client Entrando nel dettaglio, infatti, mentre nella prima sessione di test l unico caso in cui il sistema aveva risposto correttamente a tutte le richieste era il caso corrispondente a 2 richieste al secondo, nella seconda sessione di test il sistema ha risposto correttamente al 100% delle richieste in tutti i casi, anche quello in cui il carico sottoposto al sistema supera il limite stabilito nella fase dei requisiti del prototipo in esame. Stesso discorso vale anche nel caso in cui i Client che sollecitano il sistema sono 20; anche in questo caso infatti, il miglioramento delle prestazioni del sistema risulta notevole sia in termini di tempo medio per l esecuzione delle elaborazioni, che in termini di numero di richieste eseguite correttamente. 97

98 Figura 52. Confronto dei risultati nel caso di 20 Client Figura 53. Confronto complessivo dei risultati 98

99 3.8 Conclusioni Come illustrato dettagliatamente attraverso l utilizzo di tabelle e grafici nei paragrafi precedenti, risulta evidente il miglioramento delle prestazioni del sistema a valle delle modifiche architetturali, confermando i risultati attesi nella fase di analisi. In particolar modo i miglioramenti interessano entrambi i parametri del sistema presi in considerazione, ovvero: tempo medio di elaborazione delle richieste, numero di elaborazioni completate correttamente. Riguardo al primo parametro, il miglioramento delle prestazioni va da un minimo di 9,3 % ad un massimo del 96,7%. In linea di massima però, come è possibile evincere anche dalla figura 53, i tempi medi di elaborazione migliorano al crescere del carico applicato al sistema. I miglioramenti riscontrati perciò, risultano più evidenti nel caso di tanti Client e frequenza di elaborazione piuttosto bassa. Figura 54. Miglioramento delle prestazioni in termini percentuali 99