Elaborato Karamanolis Gabriella N46001643
Transcript
Elaborato Karamanolis Gabriella N46001643
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione II Analisi di soluzioni per la distribuzione dati affidabile e in tempo reale basate su DDS Anno Accademico 2015/2016 Candidato: Gabriella Karamanolis matr. N46/1643 A colui che più di tutti vorrebbe essere qui con me oggi e a colei senza la cui forza non sarei qui: a mio padre e mia madre. Indice Analisi di soluzioni per la distribuzione dati affidabile e in tempo reale basate su DDS ....................I Indice .............................................................................................................................................. III Introduzione ..................................................................................................................................... 4 Capitolo 1: Lo standard DDS ........................................................................................................... 6 1.1 Livelli del DDS .................................................................................................................... 6 1.2 Modalità di funzionamento .................................................................................................. 9 1.3 Global Data Space .............................................................................................................. 10 1.4 Quality of Service .............................................................................................................. 10 Capitolo 2: RE.VE.N.GE. .............................................................................................................. 12 2.1 Architettura ........................................................................................................................ 13 2.2 Policy DDS ........................................................................................................................ 15 2.3 Sistema di code .................................................................................................................. 17 2.4 Test .................................................................................................................................... 17 Capitolo 3: RDDS .......................................................................................................................... 20 3.1 Architettura ........................................................................................................................ 21 3.2 Comunicazione semantics-aware ...................................................................................... 24 3.3 Garanzie Quality of Service e Quality of Data .................................................................. 25 3.4 Test ..................................................................................................................................... 27 Conclusioni .................................................................................................................................... 30 Bibliografia .................................................................................................................................... 32 Introduzione “Il mio programma gira su un sistema distribuito quando non funziona per colpa di una macchina di cui non ho mai sentito parlare” - L. Lamport. Siamo sempre più circondati da macchine e software eterogenei nella vita di tutti i giorni ma non ce ne rendiamo conto. Sistemi eterogenei che possono interagire fra di loro solo tramite scambio di opportuni messaggi sono detti sistemi distribuiti. Nei sistemi distribuiti vari fattori aumentano la complessità dello sviluppo di un buon software : • le applicazioni sono distribuite su una rete di calcolatori, con hardware e sistemi operativi diversi ; • occorre adoperare linguaggi di programmazione diversi ; • i dati sono distribuiti su più nodi di elaborazione memorizzati in archivi o DBMS diversi. In informatica, è raro che i sistemi più complessi vengano costruiti ex novo, ma sono invece evoluzioni e integrazioni di sistemi datati ma robusti con in aggiunta qualche modifica. L‟integrazione di sistemi informativi sviluppati in momenti diversi, con linguaggi e tecniche diverse, è un problema centrale delle tecnologie software. Prima di proseguire è giusto dare una defizione di middleware. Esso è uno strato software che si interpone fra sistema operativo e applicazioni, in grado di fornire servizi utili per lo sviluppo di applicazioni distribuite: questo fornisce ai programmatori le API (Application Programming Intarface), librerie di funzioni in grado di mascherare l‟eterogeneità dei 4 sistemi permettendo al programmatore di ignorare i dettagli degli stessi. Molte tecnologie middleware sono nate con il preciso obiettivo di fornire una risposta al problema dell‟integrazione di applicazioni differenti (EAI). Alcune applicazioni real-time e fault-tolerant hanno la necessità di modellare la loro comunicazione come puro scambio incentrato sul dato, data-centric, dove dei processi pubblicano il dato che è poi disponibile ad altri processi remoti interessati ad esso. In questo elaborato verrà presentata la specifica emergente per la distribuzione dei dati, Data Distribution Service, che tenta di risolvere il problema e verranno analizzate due diverse modalità d‟uso dello stesso. La prima è un lavoro svolto da ingegneri italiani, “RE.VE.N.GE.: implementazione tramite RTI-DDS e replicazione del sistema di consegna”3, che tratta di un progetto chiamato „Reliable and versatile news delivery support for agencies‟ il cui scopo è quello di realizzare un sistema per la distribuzione di notizie su larga scala usando RTI-DDS. La seconda è un lavoro svolto da americani, “RDDS: A Real-Time Data Distribuition Service for Cyber-Physical System”4 che tratta dell‟implementazione dello standard DDS per la creazione di una nuova applicazione, RDDS, usata nei sistemi ciber-fisici, sistemi che lavorano a stretto contatto con il mondo fisico. 5 Capitolo 1: Lo standard DDS Il Data Distribution Service (DDS) è uno standard emanato dall'Object Management Group (OMG) che definisce un middleware per la distribuzione di dati in tempo reale secondo il paradigma publish/subscribe. DDS è un MOM (message-oriented middleware) data-centric che prevede un‟architettura ad alte prestazioni, caratterizzata da scalabilità e affidabilità. L‟obiettivo della specifica del DDS può essere riassunto nella frase “Efficient and Robust Delivery of the Right Information to the Right Place at the Right Time.”1 I middleware data-centric hanno un differente approccio dai tipici MOM messagecentric: i data-centric si focalizzano sulla distribuzione dei dati da più sorgenti a più destinazioni in tempo reale e delle informazioni sullo stato del sistema. Più nel dettaglio, il middleware sa se un dato è condiviso tra più applicazioni di sistemi distribuiti e i messaggi sono costruiti dal middleware in maniera tale che possano comunicare eventuali cambiamenti dello stato del sistema. 1.1 Livelli del DDS La specifica DDS si compone di due livelli e le applicazioni hanno libero accesso ad entrambi i livelli : Data Centric Publish-Subscribe (DCPS) definisce le funzionalità usate da una applicazione per pubblicare o sottoscriversi ai valori di un dato oggetto. 6 Le principali classi del DCPS che realizzano la comunicazione sono: • La classe DomainPartecipant, il cui oggetto rappresenta la partecipazione dell‟applicazione a un piano di comunicazione, il dominio, che isola le une dalle altre le applicazioni in esecuzione sullo stesso insieme di elaboratori fisici. Un dominio stabilisce una “rete virtuale”, collegando tutte le applicazioni che condividono lo stesso domainID e isolandole dalle applicazioni in esecuzione su domini differenti. In questa maniera, diverse applicazioni distribuite indipendenti possono coesistere in una stessa rete fisica senza che interferiscano fra loro o che siano a conoscenza le une delle altre. Gli oggetti DomainPartecipant sono creati e distrutti dal singleton DomainPartecipantFactory. • La classe Publisher, il cui oggetto è responsabile della reale diffusione delle pubblicazioni. Ad un Publisher possono appartenere più oggetti DataWriter, in questo modo un oggetto di tipo Publisher può inviare dati su più Topic distinti. Quando è informato di un cambiamento di un dato associato ad uno dei suoi oggetti DataWriter, il Publisher decide quando è realmente appropriato mandare un messaggio di data-update in accordo alla propria QoS o a quella del corrispondente DataWriter. • La classe DataWriter, il cui oggetto rappresenta l‟intenzione del Publisher di pubblicare un dato. Esso consente all‟applicazione di settare il valore del dato che dev‟essere pubblicato sotto il Topic scelto. Un DataWriter è legato a un solo Publisher che gli fa da costruttore, a un solo Topic e di conseguenza a un solo tipo di dato. Il Topic deve esser creato prima del DataWriter. DataWriter è una classe astratta che dev‟essere specializzata per ogni particolare tipo di dato dell‟applicazione. • La classe Subscriber, il cui oggetto è responsabile della reale ricezione dei dati derivanti dalla sottoscrizione. Ad un Subscriber possono appartenere più oggetti DataReader; in questo modo un oggetto di tipo Subscriber può leggere dati su più Topic distinti. Quando riceve un dato (da un‟altra parte del sistema), costruisce una lista dei DataReader interessati, e poi indica all‟applicazione quale dato è disponibile, attraverso i suoi listener o abilitando le relative condizioni. • La classe DataReader, il cui oggetto consente all‟applicazione di dichiarare il dato che 7 desidera ricevere e di accedere al dato interessato tramite il Subscriber. Un DataReader si riferisce al Topic che identifica il dato che dev‟essere letto. La sottoscrizione può dare un solo tipo di risultato. Il DataReader potrebbe avere accesso a molte istanze del risultato distinte dalla loro chiave. DataReader è una classe astratta che dev‟essere specializzata per ogni particolare tipo di dato dell‟applicazione. • La classe Topic è la descrizione base del dato che dev‟essere pubblicato e sottoscritto. Un Topic è identificato dal suo nome che dev‟essere unico in tutto il dominio. Tutte queste classi estendono la classe Entità del DCPS che a sua volta rappresenta la possibilità di queste di essere configurate attraverso le politiche di QoS e di poter ricevere notifiche di eventi attraverso i Listener. DCPS è la API più bassa tra gli strati di DDS ed è utilizzata dalle applicazioni per le comunicazioni con altri processi basati su DDS. Data Local Reconstruction Layer (DLRL) è invece opzionale e situato sullo strato più alto perché specifica come un‟applicazione può interfacciarsi attraverso una visione objectoriented ai servizi sottostanti. La specifica OMG definisce anche un livello aggiuntivo sottostante il DDS: il Real-Time Publish Subscribe (RTPS)2. Esso è un wire control (protocollo di collegamento) che indica “come” deve avvenire l‟interazione fra publisher e subscriber. La specifica RTPS quindi usa molte delle entità centrali usate dalla specifica DDS. RTPS è progettato per funzionare su IP multicast e con protocolli di trasporto connectionless e best-effort come UDP/IP. Il protocollo presenta le seguenti principali caratteristiche: • Specifiche QoS atte a realizzare comunicazioni publish-subscribe best-effort e affidabili per applicazioni Real-Time, utilizzando reti IP standard; • La tolleranza ai guasti per consentire la connessioni di reti senza single point of failure; • Estensibilità per consentire al protocollo di essere esteso e migliorato senza toccare compatibilità e interoperabilità con vecchie versioni dello standard; • Connettività plug-and-play così che le nuove applicazioni vengano rilevate 8 automaticamente e le applicazioni possano aderire e abbandonare la rete in qualsiasi momento senza necessità di riconfigurazione; • Modularità, per consentire ai dispositivi di utilizzare soltanto un sottoinsieme delle caratteristiche offerte dal protocollo; • Scalabilità; • Type-safety per prevenire errori di programmazione che possano compromettere il funzionamento di nodi remoti. 1.2 Modalità di funzionamento Consideriamo due nodi, A e B, separati e distinti. Sul nodo A agisce un‟applicazione, il producer, che produce messaggi mentre sul nodo B vi è un‟applicazione, il receiver, che riceve messaggi. Attraverso il DDS e più specificamente tramite il suo livello DCPS il producer invia i suoi messaggi al DataWriter. I messaggi verranno poi inviati al Publisher, l‟elemento attivo che dissemina il messaggio attraverso la rete. Il legame fra DataWriter e Publisher è Topic-Based e tale legame rappresenta l‟intenzione dell‟applicazione di pubblicare un messaggio di uno specifico dato. Il Pulisher attraverso il Domain, canale virtuale che collega Publisher e Subscriber, invia il messaggio verso il Subscriber nel nodo di ricezione B. La comunicazione fra Publisher e Subscriber è regolata dalle politiche di QoS secondo un pattern offerta/richiesta : la comunicazione è instaurata se le QoS del Subscriber concordano con quelle offerte dal Publisher. Il Subscriber manda il messaggio al DataReader, il cui legame è sempre Topic-based. Infine il messaggio giunge a destinazione. 9 1.3 Global Data Space Il DDS fornisce un‟archiviazione dati locale ad ogni applicazione detta Global Data Space. Ad ogni partecipante del dominio, il GDS appare come una memoria locale alla quale si accede tramite apposite API, mentre DDS gestisce l‟invio degli opportuni messaggi finalizzati all‟aggiornamento della memoria sui rispettivi nodi remoti. I dataobject sono accessibili dalla tupla (Topic, Key). Le sottoscrizioni sono disaccoppiate dalle pubblicazioni. Le relazioni sono stabilite tramite QoS. Il DDS fornisce anche il Local Object Cache costruito dal GDS; le modifiche sul Local Object Cache vengono riportarte sul GDS. DDS opera una comunicazione peer-to-peer, per cui non è necessaria la presenza di un‟entità broker. Questo permette di garantire un certo grado di affidabilità grazie all‟assenza di single point of failure. 1.4 Quality of Service Con QoS (Quality of Service) si intende un insieme di caratteristiche che controlla alcuni aspetti del comportamento del Servizio DDS. Esse controllano come i dati devono essere condivisi tra le applicazioni permettendo di garantire requisiti di affidabilità, sicurezza e salute del sistema: • In un sistema non tutte le applicazioni necessitano di tutti i dati presenti nel Global Data Space: DDS invia solo ciò di cui ogni processo ha effettivamente bisogno; • Se i messaggi non raggiungono le destinazioni, il middleware implementa l‟affidabilità della consegna quando necessario; • Se la quantità di dati è notevole, il DDS li filtra e invia soltanto i dati di cui ogni applicazione ha bisogno; • Quando il sistema cambia, DDS riconosce dinamicamente a chi inviare quale dato, e informa i partecipanti dei cambiamenti; 10 • Quando sono necessari aggiornamenti veloci, DDS invia messaggi multicast per eseguire l‟aggiornamento di molte applicazioni remote contemporaneamente; • Con l‟evolversi dei tipi di dato, DDS tiene traccia delle versioni utilizzate dalle varie parti del sistema ed esegue automaticamente le dovute traduzioni; • Per applicazioni security-critical, DDS controlla gli accessi, impone percorsi ai flussi di dati e cripta i dati on-the-fly. 11 Capitolo 2: RE.VE.N.GE. RE.VE.N.GE. è l‟acronimo di „Reliable and versatile news delivery support for agencies‟, un progetto nato da ingegneri italiani il cui scopo è quello di realizzare un sistema per la distribuzione di notizie su larga scala. Obiettivi principali per la realizzazione del middleware sono : • il disaccoppiamento delle due realtà interessate, fonti e fruitori (sources e sinks) ; • un supporto alle QoS sia per le fonti che per i fruitori che devono essere capaci di configurarle; • replicazione del servizio di consegna per incrementare l‟affidabilità del sistema. Utile strumento per rispondere a questi obiettivi è proprio lo standard DDS per sistemi real-time, RTI-DDS. Esso è un middleware sviluppato da Real-Time Innovations che implementa le API DCPS fornite dalla specifica DDS per applicazioni distribuite realtime. Il middleware RTI-DDS non è a conoscenza del sistema operativo e del linguaggio di programmazione, permettendo a sistemi eterogenei la comunicazione. Esso ha riscosso successo in molti campi mission-critical e data-critical come: monitoraggio del traffico aereo, ferroviario e nella gestione di transazioni finanziarie. RTI-DDS offre servizi utili all‟applicazione che si vuole creare, che sono: heartbeat, ovvero il controllo della vita di sink e source, responsabilità dunque del middleware; affidabilità della comunicazione, garantita per mezzo di protocolli di ack e code di ritrasmissione configurabili; partizioni dei topic che permettono di mettere in comunicazione solo alcuni DataReader/DataWriter all‟interno dello stesso topic. 12 Sono stati appurati i „limiti‟ della struttura DDS per il progetto e dove è necessario operare per l‟aggiunta di uno strato ulteriore, con i suoi pro e contro e nello specifico sono state analizzate le problematiche relative alla fault tolerance del sistema. 2.1 Architettura Sono tre le entità che partecipano alla comunicazione: la fonte, source, che è il produttore delle notizie, caratterizzato da una quantità minima e massima di notizie consegnabili nell‟unità di tempo e livelli di affidabilità e priorità; il fruitore, sink, che riceve le notizie, caratterizzato da affidabilità delle consegne, i tempi minimi e massimi di consegna della notizia, il numero minimo e massimo di notizie da ricevere nell‟unità di tempo e gli argomenti di interesse, sui quali è anche possibile richiedere un‟esclusiva riguardo alcuni tipi di notizie; il sistema di consegna, system, fulcro del progetto che fa da ponte fra sources e sinks inglobando tutte le principali funzionalità dell‟applicazione, ovvero il controllo della qualità di servizio e della distribuzione delle news, garantendo alta affidabilità del servizio, essendo replicato; il system permette la registrazione dei sources e dei sinks, con associata la QoS da loro richiesta, e assicura la ricezione e l‟inoltro delle notizie secondo la QoS. Al fine di garantire flessibilità nel settaggio della QoS, essa è resa completamente personalizzabile per ogni sink/source: in particolare si hanno N+M canali, monodirezionali o bidirezionali a seconda della garanzia di trasmissione di cui si necessita (rispettivamente best-effort o reliable), con N numero di source registrati e M numero di sink registrati. La QoS è imposta tramite delle code interne: in esse le notizie vengono ordinate secondo la priorità delle sources ed eliminate se la loro deadline di consegna non viene rispettata. Per rendere il sistema robusto ad eventuali guasti è implementata una replicazione spaziale del sistema: infatti, in un sistema distribuito, la presenza di un insieme di processori partecipanti permette la replicazione delle risorse che servono all‟applicazione su più nodi diversi, facendo sì che se cade un nodo ve ne sia un altro pronto ad essere utilizzato. 13 Il modello di replicazione scelto è quello a copie attive indipendenti, non basato su una comunicazione di tipo master-slave che avrebbe snaturato il modello DDS, bensì orientato a una comunicazione alla pari. All‟atto della pubblicazione di una notizia ad opera di un source, tutti i sistemi ne ricevono una copia attraverso una trasmissione multicast realizzata dal DDS, il quale, realizzando un‟astrazione di un sistema unico, assicura ad ogni singolo sistema di potersi occupare del proprio insieme di sink lavorando indipendentemente dagli altri sistemi-copia, distribuendo così il carico di elaborazione. A seguito di un invio di una notizia ad un suo sink, un sistema informa i suoi pari tramite messaggi di sincronizzazione, caratterizzati da quadruple che hanno al loro interno i GUID (identificatore unico globale) della notizia inviata, del sistema-copia che ha recapitato la notizia, del source origine e del sink destinazione. Le tempistiche dipendono dalla bufferizzazione operata dal DDS nell‟invio dei messaggi dai DataWriter ai DataReader. La comunicazione è ovviamente basata su Topic, divisi in due gruppi: quelli inerenti il rapporto fra system e sink/source e quelli interessati alla comunicazione tra i sistemicopia. I Topic tra system e source/sink sono: sourceNewsTopic e sinkNewsTopic, topic partizionati che si occupano rispettivamente dell‟invio della notizia da source a system e dell‟invio della notizia da system a sink; sourceManagerTopic e sinkManagerTopic, che si occupano delle richieste di Join/Leave rispettivamente di source e sink. I Topic dedicati all‟interazione tra i sistemi-copia sono: systemMsg, topic adibito alla presentazione del nuovo sistema di consegna che vuole unirsi, così da attivare il protocollo di join usato per garantire una corretta sincronizzazione delle copie; sourceSync e sinkSync attraverso i quali i sistemi-copia si scambiano informazioni in modo tale da garantire consistenza globale (tutti i sistemi-copia dovranno conoscere le stesse entità); queueUpdate, in cui un sistema-copia avvisa gli altri sistemi che una determinata notizia destinata a un proprio sink è stata correttamente inviata, permettendo loro di rimuoverla dalle proprie code interne, necessarie in caso di cadute impreviste (se va offline un sistema, le notizie ai sink di quest‟ultimo vengono recapitate dagli altri); whois, sink/source/peer recovery sono 14 invece topic usati in casi di malfunzionamento, come ad esempio un messaggio mancante. 2.2 Policy DDS Una buona quality of service è obbiettivo centrale del progetto e attraverso delle policy del DDS vengono risolti alcuni problemi essenziali. Per la heartbeat, cioè il controllo della liveliness delle entità, è usata la policy discovery_config per configurare il processo di discovery. Questa politica offre delle callback implementabili all‟avvenire di un evento come quando un dataWriter perde/acquista un dataReader associato o viceversa. Personalizzando la frequenza di invio dei pacchetti di discovery si stabilisce un criterio per decidere se un‟entità (sink o source) è attiva o meno (pacchetti liveliness). Il sistema-copia nel lato source ha N dataReader su un topic partizionato N volte, quindi alla caduta di un nodo source si saprà presso quale dataReader è scattato l‟evento e così il sistema-copia saprà quale fonte è caduta, provvedendo a rimuovere le entità, procedura necessaria con RTI-DDS per non appesantire l‟applicazione. Nel lato sink, invece, il fruitore, avente un unico dataReader, riceve notizie da un sistema-copia che possiede un solo dataWriter che lavora su un topic partizionato; risulta pertanto semplice riconoscere la caduta di un sink e informare gli altri sistemi. Il protocollo di discovery del DDS non copre la caduta di un sistema-copia, essendo DDS un publish/subscribe e non potendo dunque riconoscere quale specifico dataReder/dataWriter si sia disassociato dal topic. Così si è previsto un heartbeat firmato con cui un sistema-copia, ogni quanto di tempo deciso con criterio, manda un messaggio imfine con il GUID associato. I sistemi-copia garantiscono un sistema robusto che difficilmente perde notizie: infatti, alla caduta di un sistema-copia, un sink registratovi viene spostato su un altro, lasciando lo stesso dataReader in attesa sul topic; nel sistema-copia subentrato, invece, viene aggiunto un nuovo dataWriter per comunicare col nuovo fruitore, in maniera del tutto trasparente agli occhi del sink grazie al DDS. Per l‟affidabilità delle comunicazioni è adottata la policy reliability del DDS, che permette 15 di decidere se il dato pubblicato da un DataWriter su un preciso Topic va trasmesso a un DataReader in maniera affidabile. Settando reliability a best_effort, il dato verrà inviato al DataReader senza attendere conferme di buon esito della ricezione; altrimenti, settando a reliable, a seguito dell‟invio del dato viene ricevuto un ack di conferma, senza il quale il dato è inviato ancora. Modificando il parametro history si può scegliere la quantità di dati da bufferizzare per la pubblicazione mentre si aspetta l‟ack riguardante la ricezione del dato precedente. La reliability effettiva verrebbe raggiunta permettendo al DDS di allocare code send e receive illimitate: rispettivamente, le prime mantengono i messaggi per i quali non vi sono stati gli ack relativi ai dataReader associati al Topic e le seconde mantengono i messaggi successivi ad un eventuale messaggio mancante mentre viene inviato un ack negativo per la ritrasmissione del messaggio mancante. Allocando code send/receive illimitate si eviterebbe il caso di code piene e la conseguente mancanza di messaggio, ma questa strategia è sconsigliata poiché il DDS sforerebbe i limiti di memoria accettabili. Il progetto adotta quindi una politica reliable con history a keep all, mantenendo soltanto i messaggi relativi alle fasi di Join/Leave di sink/source, allo scopo di evitare, in caso di pubblicazioni di notizie ad un rate troppo elevato, un sovraffaticamento del sistema. Questo è possibile grazie al protocollo RTPS usato dal DDS che abbassa notevolmente le probabilità di un‟eventuale perdita di messaggio. Nel caso peggiore di perdita di un messaggio di leave/join di un sink/source, il sistema recupera la piena consistenza grazie al protocollo whois: quando riceve un messaggio di aggiornamento (consistente in una quadrupla: GUID della notizia inviata, del sistemacopia che ha inviato la notizia, del source origine e del sink destinazione), ogni singolo sistema-copia o riconosce le entità in gioco o, in caso contrario, utilizza il topic whois per chiedere agli altri sistemi-copia le informazioni di tali entità ignote. La policy partitioning assicura un canale personalizzato qualora richiesto, nonostante tutti i sink e source utilizzino lo stesso Topic (news). Esiste la policy deadline del DDS, ma questa dà solo la possibilità di scatenare un evento in caso non si presentino notizie entro un certo lasso di tempo e non è d‟aiuto per il 16 controllo della frequenza minima/massima di trasmissione delle news dove è invece sfruttato un meccanismo a code esterno al DDS. 2.3 Sistema di code Come detto nel capitolo precedente, il sistema di code agisce dove le policy DDS non sono sufficienti. Source e sink hanno delle entità predisposte, rispettivamente: NewsCatcher legge le notizie e NewsDispatcher effettua la consegna al sink interessato ad esse. Quando una source/sink si registra vi sono parametri da specificare che vanno mantenuti dal sistema in una struttura dati, quali: priorità, numero massimo e minimo di news per unità di tempo, l‟unità di tempo da considerare e l‟affidabilità. L‟affidabilità è usata per considerare i DataReader e DataWriter opportuni mentre i restanti parametri sono usati dal sistema di code. All‟arrivo di una notizia questa viene inserita in coda. La coda è in grado di controllare la QoS del source; infatti, ha un timer per controllare il numero minimo di news per unità di tempo, che se non rispettato attiva un listener per segnalare il problema, mentre, per il numero massimo di news, la coda si blocca appena si raggiunge il numero massimo durante l‟unità di tempo e si sblocca quando il timer conclude il conteggio; l‟entità NewsPusher usa take sulla coda controllando che la deadline della notizia non sia stata superata: se è scaduta, la notizia viene eliminata e si continua ad estrarre dalla coda fino a che non viene trovata una notizia con deadline valida, la quale viene prelevata e inserita da NewsPusher nelle altre code possedute dai NewsDispatcher, che provvedono a recapitarla ai sink. 2.4 Test I test sono stati eseguiti su una macchina monitorata facente da sistema-copia e altre due macchine usate per sink, source e altri sistemi-copia. In fig. 1 è possibile consultare i risultati in termini di banda impiegata dal sistema-copia monitorato in diverse situazioni d‟utilizzo: 17 1. Due sistemi-copia a riposo attivi solo per analizzare l‟overhead causato dai meccanismi di discovery del DDS e i messaggi imfine. 2. Un source attivo con rate 10 news/sec che fa aumentare la banda di 3 KB/sec a causa delle pubblicazioni. 3. Un sink attivo, gestito dal sistema-copia 2, aumento della banda di 3 KB/sec a causa degli update da sistema-copia 2. 4. Un sink attivo gestito da sistema-copia 1, ulteriori 3 KB/sec per l‟invio delle notizie più altri 3 per l‟invio degli update. 5. Un ulteriore sink attivo gestito da sistema-copia 1. 6. Attivazione di sistema-copia 3, altri 10 kb/sec per gli update e gli overhead del DDS e dei messaggi imfine. 7. Un sink attivo gestito dal sistema-copia 3, aumento della banda di 3 KB/sec. Dal test emerge il peso che comporta un nuovo sistemacopia, che non introduce overhead nella trasmissione della notizia, sempre realizzata da uno solo dei sistemi, ma „consuma‟ una porzione crescente di banda per via dei messaggi di Figura 1: risultati test sulla banda impiegata update e sincronizzazione. Simile andamento è seguito dal costo di gestione di un sink (supponendo una frequenza di trasmissione di 10 news/sec) al crescere del numero di copie (in altre parole, inserire un sink in N copie equivale a inserire N sink in un unico sistema). 18 È stato svolto anche un test per capire il carico limite del processore (avente frequenza 600MHz). Il test è stato eseguito con un sistema-copia e 10 sink e ha fatto registrare dei malfunzionamenti raggiungimento al della soglia di 600 news/sec, ma i risultati sono soddisfacenti considerato che il rate-soglia è molto alto. Figura 2: risultati test sul carico della CPU 19 Capitolo 3: RDDS Requisito principale in molti sistemi ciber-fisici (Cyber-Physical Systems, CPS, ovvero sistemi informatici interagenti in modo continuo con un sistema fisico) è che i dati dei sensori, usati per interagire strettamente col mondo fisico, dovrebbero essere diffusi in maniera tempestiva e affidabile a tutte le entità che interagiscono nel sistema. In questi sistemi, infatti, un gran numero di entità coopera per il raggiungimento di scopi comuni. I sensori acquisiscono i dati dal mondo esterno per poi trasmetterli alle risorse computazionali, che a turno, in cooperazione, prendono le decisioni in tempo reale con la condivisione dei dati e delle informazioni. Le difficoltà in questi sistemi si riscontrano nella natura altamente dinamica dei sistemi, sia per quanto riguarda le risorse di calcolo che per i processi fisici; inoltre, la disponibilità delle entità partecipanti può cambiare nel corso delle operazioni per cause diverse, e negli strati-rete usati da questi sistemi vi sono di solito instabilità, dato che molte delle applicazioni non possono permettersi di avere reti fisse e affidabili. Nell‟articolo “RDDS: A Real-Time Data Distribuition Service for Cyber-Physical System”, viene presentata una nuova archittettura middleware publishe/subscribe, chiamata RDDS che mira a fornire un servizio dati affidabile e tempestivo in ambienti dove i carichi di lavoro schizzano improvvisamente e la comunicazione è instabile. Il lavoro si focalizza su due aspetti del RDDS per ottenere un servizio di distribuzione affidabile e tempestivo. Uno dei meccanismi fondamentali del RDDS è la comunicazione semantics-aware che usa modelli di sensori predittivi leggeri. 20 Dato che la maggioranza dei processi fisici reali lavora in tempo-continuo, ad esempio i cambi di temperatura, RDDS modella i flussi di dati usando modelli computazionalmente leggeri. Quest‟abilità può apportare benefici significativi per i sistemi dove il feedback real-time è necessario ma la rete è lenta o instabile. Inoltre, viene esteso il meccanismo comunicativo semantics-aware al problema della QoS in TPS (Topic-Publish-Subscribe), integrando meccanismi di controllo della qualità dei dati dei sensori. Dei meccanismi feedback ai publisher e feedforward ai subscribers sono integrati per accrescere la qualità della distribuzione dei dati in real-time. Con questi anelli di controllo integrati, si può provvedere alla robustezza contro i carichi di lavoro imprevedibili sia in favore del publisher che dei suoi sottoscrittori. Per mostrare la validità dell‟approccio proposto, gli ideatori hanno implementato RDDS come estensione dello standard DDS di OMG per includere i meccanismi che sostengono ambienti instabili e valutato RDDS mettendo in piedi un banco di test con carichi di lavoro realistici. 3.1 Architettura RDDS concepisce un CPS su larga scala, in cui molti publisher collezionano dati realtime da sensori sia fisici che logici e li pubblicano per molti sottoscrittori. Ciascun publisher colleziona dati da un set di sensori e pubblica i corrispondenti flussi di dati al sottoinsieme di subscribers interessato. Sottoscrittori interessati al consumo di dati da un gruppo di sensori si uniscono al gruppo dei sottoscritti con la sottoscrizione al topic corrispondente. Il dato in RDDS è identificato dal Topic, che permette al publisher e al sottoscrittore di riferirvisi senza ambiguità. Ciascun tipo di topic appartiene o alla categoria DATA_CONTINUOUS o alla categoria DATA_DISCRETE. Un topic che appartiene alla prima categoria riceve flussi di dati da sensori che monitorano continuamente fenomeni fisici in evoluzione. Al contrario la seconda rappresenta flussi di dati provenienti da sensori che registrano valori discreti. Il lavoro si focalizza su sensori che hanno proprietà continue. 21 Mentre la trasmissione dei dati dai publishers ai sottoscrittori si verifica direttamente tra le due parti, la scoperta delle entità (publisher, subscriber e topics) e la negoziazione QoS/QoD si verifica in maniera centralizzata usando un broker. RDDS usa un meccanismo di scoperta centralizzato per ragioni di performance e semplicità, visto che un meccanismo di scoperta distribuito può essere più robusto ma causa maggiore overhead di comunicazione. Per evitare di essere un single point of failure, un broker di RDDS può essere replicato. L‟esistenza di flussi di dati dei sensori è comunicata dai publishers ai sottoscrittori via broker o un gruppo di broker. In RDDS, QoD (Quality of Data) è definita in termini di limite di precisione dei data sensor, il cui limite massimo può essere specificato dagli utilizzatori. Esiste un compromesso fra QoD e la freshness dei dati, per aumentare la quale va ridotto il limite di precisione richiesto, al costo di un incremento di carico di lavoro. D‟altronde, ciò è necessario per prevenire sovraccarichi e conseguenti ritardi sulla consegna dei messaggi a ciascun nodo, in ragione del soddisfacimento della QoD richiesta. A questo fine, la primaria metrica QoS nell‟articolo in esame è il limite di utilizzazione della CPU in ciascun nodo. Entrambe le parti, publisher e sottoscrittori, possono definire il livello di QoS e QoD, che essi forniscono o che richiedono negoziando un livello di QoS e QoD che soddisfi entrambe le parti e al quale accettano di aderire. La negoziazione QoS/QoD, gestita dal broker, segue un modello di richiesta/offerta nel quale la richiesta QoD/QoS dev‟essere la stessa o minore di quella che è stata offerta. Un broker mantiene inoltre meta-informazioni come la liveliness delle entità partecipanti, con controlli periodici del segnale di heartbeat dalle entità. La registrazione delle entità di RDDS coinvolge un broker ma la consegna effettiva del data sensor si verifica tra il publisher e i suoi sottoscrittori. Entrando nel vivo dell‟architettura, RDDS ha una struttura asimmetrica per publishers e subscribers. Per i publishers, RDDS consiste in: un negoziatore di QoS/QoD, un controllore di precisione, modelli per i sensori, un monitor del carico e protocolli di trasporto settabili. Ogni flusso di dati dai sensori continui ha un corrispondente modello sia lato publisher sia lato subscriber; questi modelli sono utilizzati dai publisher per determinare se i dati in arrivo 22 dai sensori vadano trasmessi ai subscriber o meno. I nuovi aggiornamenti vengono inviati ai subscriber solo se i valori osservati dai sensori si scostano dal valore predetto dal modello di un δ che sia superiore allo specifico limite di tolleranza, settato dinamicamente per adattarsi al carico di CPU desiderato. Il monitor di carico riporta periodicamente l‟attuale carico della CPU al controllore di precisione, il quale calcola la differenza fra il carico di CPU desiderato e quello misurato. Sulla base di questo errore, il controllore determina se e come il limite di tolleranza andrà aggiornato al successivo periodo di campionamento. Per i subscribers, RDDS consiste in: un negoziatore di QoS/QoD, un buffer, modelli dei sensori, un previsore di occupazione del buffer e un controllore di carico. In primo luogo, le rilevazioni dei sensori provenienti dai publishers vengono bufferizzate. Per i sensori continui, ogni flusso di dati ha un modello corrispondente, lo stesso che hanno i publisher. I modelli sono aggiornati solo se arriva una nuova osservazione da un publisher: è in questa situazione che avviene l‟effettiva sincronizzazione tra publisher e subscribers. Quando non ci sono aggiornamenti in arrivo da un publisher, i modelli dei subscribers predicono periodicamente lo stato corrente dei sensori corrispondenti e popolano il buffer con i dati predetti. Con questo meccanismo, i subscribers mantegono aggiornati i valori dei sensori anche in assenza di comunicazione con i publishers, utile soprattutto in sistemi la cui rete è lenta o instabile. Per settare la giusta frequenza di ricezione di dati dai publishers, il previsore di occupazione del buffer stima il riempimento di buffer previsto. Il controllore di carico invia periodicamente un segnale di controllo del carico al broker. Il broker mette insieme i segnali di controllo provenienti dai subscribers, ricavandone il minimo, ovvero il segnale generato dal subscriber più in sovraccarico. Il publisher usa questo valore minimo per regolare il proprio target di carico di CPU. Essenzialmente, il ciclo di controllo a retroazione dei publisher e il ciclo di controllo con azione in avanti dei subscriber formano un doppio ciclo utile a migliorare la qualità della distribuzione dei dati. 23 3.2 Comunicazione semantics-aware A differenza degli approcci basati su cache, RDDS sfrutta il fatto che la maggior parte dei processi fisici lavora in continuo nel mondo reale. Avvantaggiandosi della semantica dei dati dei sensori, non soltanto si riducono i carichi di computazione/comunicazione, ma in più si fornisce una disseminazione dei dati affidabile e puntuale. Quando un publisher riceve l‟osservazione v dal sensore si, la va a confrontare col valore predetto dal modello relativo a si. Se la differenza tra il valore previsto dal modello e l‟osservazione del sensore rientra nel limite di precisione, la nuova osservazione viene cestinata (o salvata localmente per ragioni di logging). Questo implica che i modelli attuali (condivisi da publisher e subscriber) sono sufficientemente precisi nel predire l‟osservazione del sensore entro i limiti di precisione richiesti. In caso contrario, se la differenza è maggiore del limite di tolleranza, il modello non è più in grado di catturare il corretto comportamento in uscita dal sensore. In questo caso, il modello del publisher è immediatamente aggiornato, e v viene trasmessa in multicast per raggiungere tutti i subscribers. A seguito della ricezione di v, il subscriber aggiorna il proprio modello in accordo con v. Un beneficio di quest‟approccio è che un‟applicazione può ottenere dinamicamente il valore corrente di un sensore dal suo modello, usando le predizioni anziché comunicando realmente col publisher. Questo rende RDDS altamente resistente a potenziali perdite di pacchetti di dati in reti con comunicazione instabile. Inoltre, dato che le letture dei sensori possono essere stimate prontamente senza ritardi di comunicazione, può essere raggiunta la timeliness negli accessi ai dati. Le stime dei modelli di publisher e subscriber possono essere differenti quando la rete è instabile. Per applicazioni nelle quali quest‟errore è critico, RDDS permette agli utenti di scegliere il protocollo di trasporto richiesto, TCP o UDP, benché TCP non si adatti alle esigenze delle applicazioni real-time. Basarsi su modelli complessi è computazionalmente proibitivo. Perciò, ogni sensore in RDDS è modellato con un semplice spazio di stato. In RDDS, un processo fisico, come la temperatura misurata da un sensore al tempo k, è rappresentato in un vettore di stato 24 avente due variabili, [x 𝑑𝑥 𝑑𝑡]t, dove x è il valore corrente del sensore all‟istante k e 𝑑𝑥 𝑑𝑡 è la derivata rispetto al tempo di x. A giudizio degli autori dell‟articolo, la dinamica della maggior parte dei processi fisici semplici può essere descritta usando queste due variabili di stato. Tuttavia, i dati dei sensori sono spesso imprecisi per via di disturbi nella misura, comunicazione instabile e incertezze nel modello. RDDS sfrutta filtri di Kalman per predire correttamente stato corrente xk e stato futuro xk+1 a partire da osservazioni del sensore rumorose. Non c‟è comunicazione tra publisher e subscribers a meno che il modello non abbia perso accuratezza; tuttavia, la freshness dei dati ricevuti dal subscriber va a perdersi col passare del tempo. Il periodo in cui l‟ultimo valore ricevuto resta valido è chiamato intervallo assoluto di validità (avi). Dal momento che ogni subscriber possiede i modelli dei sensori, può esso stesso determinare stato presente e stati futuri del sistema per mantenere osservazioni dei sensori “fresche” anche in assenza di aggiornamenti dai publishers. Periodicamente, lo stato di ciascun sensore stimato localmente viene aggiunto al buffer. In RDDS, il carico di comunicazione aumenta solo quando i modelli non sono sufficientemente accurati. Anziché usare un modello più complesso, che causerebbe un overhead costante, è stato sviluppato un meccanismo di adattamento della QoD che gestisce i temporanei e improvvisi carichi di lavoro causati da inaccuratezze nel modello. 3.3 Garanzie Quality of Service e Quality of Data È un compito proibitivo settare un corretto limite di precisione in fase di progetto o di sviluppo, dal momento che la massima qualità dei dati che il sistema può reggere si evolve dinamicamente con il carico del sistema. Per questo, RDDS usa meccanismi di controllo per tarare dinamicamente il limite di precisione. In RDDS, la specifica di un sistema comprende sia una specifica sulla QoD, corrispondente alla definizione di un limite di tolleranza massimo della precisione dei sensor data, sia una sulla QoS, indicante il massimo carico di CPU, allo scopo di evitare 25 situazioni di sovraccarico; in base al limite di carico specificato, dinamicamente viene di volta in volta settato il carico target, mai superiore a tale limite. Ogni publisher e subscriber setta la QoS richiesta e, prima che i subscribers si sottoscrivano a un topic creato da un publisher, le due entità dovrebbero raggiungere un accordo sulle QoS associate al topic. Per ottenere il carico di utilizzo richiesto, i publishers sono supportati da una strategia di controllo a retroazione. Lo scopo del controllore è quello di assicurare che l‟utilizzo di CPU misurato sia quanto più possibile vicino a quello di riferimento. Perché si possa agire sia sulle proprietà a regime che su quelle del transitorio, viene utilizzato un controllore PI (proporzionale integrale), grazie al quale, selezionando i giusti valori per i parametri di controllo, è possibile raggiungere le proprietà desiderate, come tempo di assestamento e sovraelongazione. Altro parametro critico è quello relativo all‟intervallo di campionamento: se troppo ridotto, in caso di uscita del sistema misurata rapidamente variabile, il controllore può risultare troppo sensibile a cambiamenti non significativi del sistema; al contrario, se eccessivo, il controllore può non riuscire a catturare in modo appropriato la dinamica del sistema. Invece il principale obiettivo del ciclo con azione in avanti dei subscribers è quello di stabilire la giusta frequenza di arrivo delle letture dei sensori dai publishers. La teoria delle code fornisce strumenti di previsione dell‟occupazione di buffer e dei ritardi a partire dai carichi d‟ingresso. Anziché inviare il segnale di controllo associato al carico di CPU richiesto direttamente al publisher (il che richiederebbe al publisher di tener traccia degli stati di ogni singolo subscriber), ogni subscriber lo indirizza al broker: tutti questi segnali di feed-forward sono raccolti dal broker che ne individua il minimo, che rappresenta il segnale di feed-forward da trasmettere al publisher. 26 3.4 Test Gli obiettivi del test sulle performance sono: accertare l‟efficacia della comunicazione semantics-aware e determinare se i meccanismi di controllo riescono a garantire i carichi di CPU richiesti dalle specifiche QoS. Il banco di simulazione emula le operazioni di emergenza svolte nel corso di un‟operazione in un edificio in fiamme. Ciascun vigile del fuoco possiede un palmare che colleziona i dati dai sensori vicini, installati nell‟edificio, tramite comunicazione senza fili e li pubblica per gli altri nodi. Il banco di test impiega un tablet Nokia N810 (con processore TI OMAP 400 MHz, su cui sono state effettuate le misurazioni) e un insieme di 33 PC, di cui 31 atti a simulare i dispositivi di 31 pompieri, 1 a fare la parte del broker e 1 atto a generare le letture dei sensori, tramite il simulatore CFAST (Consolidated model of Fire And Smoke Transport) del NIST (National Institute of Standards and Technology). È utilizzato di default il protocollo di trasporto UDP. I test su RDDS sono stati effettuati in comparazione con un‟implementazione tradizionale dello standard DDS, OpenDDS, e con un‟implementazione che sfrutta una strategia differente, denominata approx-caching, in cui la trasmissione dei valori osservati dai sensori avviene soltanto se la differenza tra il corrente e il valore precedentemente trasmesso è superiore di una data soglia. In primo luogo, viene mostrata la distribuzione dati in RDDS che sfrutta la semanticsawareness. A tal fine, sono stati monitorati i carichi di lavoro al variare del numero di pompieri partecipanti da 1 a 32; durante questo test, i controllori di publisher e subscriber non sono stati attivati, dunque il limite di tolleranza sulla precisione dei dati è rimasto fissato. Il test è stato ripetuto 10 volte, e mostra, in tutti e 3 i casi analizzati, una crescita lineare del numero di messaggi scambiati tra le entità all‟aumentare del numero di pompieri chiamati in causa, con una sostanziale differenza nel caso di RDDS, in cui la crescita avviene con una pendenza molto meno elevata rispetto ad esempio all‟approccio tipico di OpenDDS. Queste evidenze pratiche dimostrano che le operazioni di filtraggio effettuate in RDDS sui messaggi da trasmettere permettono una estrema scalabilità anche 27 in ambienti con reti a banda limitata. Risultati simili sono scaturiti dal carico di CPU, che aumenta proporzionalmente in tutti gli approcci; mantenere un livello corretto del carico della CPU è particolarmente importante per sistemi cyber-physical, in cui la distribuzione tempestiva dei dati va sempre garantita. Con OpenDDS e approx-caching il sistema va in sovraccarico rispettivamente a 16 e 32 terminali attivi, mentre con RDDS mantiene un carico di CPU inferiore al 20% anche con tutti i terminali in funzione. L‟approccio semantics-aware basato sui modelli di RDDS, dunque, permette di ridurre sensibilmente l‟overhead dovuto alla comunicazione fra le entità coinvolte. Il secondo esperimento verifica l‟adattabilità a carichi di lavoro impredicibili. Per questo test, sono stati invece attivati i controllori di QoS (carico di CPU) e QoD (limite di precisione) di publisher e subscriber. È stato scelto un limite di precisione massimo di 1°C e un carico di CPU massimo del 70%, e si sono confrontati i risultati con i controlli in funzione o meno. I risultati hanno mostrato che la presenza del controllo permette al carico di CPU di avvicinarsi al target qualunque sia il carico di lavoro del sistema; al contrario, il carico di CPU fluttua significativamente tra sotto-utilizzo e sovraccarico quando i meccanismi di controllo non sono in funzione, causando con ciò potenzialmente gravi ritardi di disseminazione dei dati. In RDDS, il limite di precisione sui dati aumenta all‟aumentare dei carichi di lavoro. Oltre a questa valutazione “a regime”, ne è stato valutato comportamento il transitorio quando vengono introdotte improvvise variazioni del – in carico di lavoro particolare sul device N810 – oppure quando aumenta il tempo di elaborazione dei Figura 3: test sull‟utilizzo della CPU 28 messaggi lato subscriber, al fine di testare il ciclo di feed-forward. Non appena è introdotta l‟anomalia nel carico, il limite di precisione segue la CPU e aumenta anch‟esso per far decrescere il carico di CPU verso il target; entrando in gioco, poi, il segnale di controllo proveniente dai subscriber in sovraccarico, il carico di riferimento viene ancora una volta regolato verso il basso grazie all‟aumento del limite di precisione fin quasi al valore limite 1°C. 29 Conclusioni Con l‟elaborato appena presentato si è cercato di mostrare l‟ampia potenzialità dello standard DDS. I due articoli presentati si costruiscono sul DDS andando con intelligenti artifici a personalizzare il sistema rispetto alle necessità della situazione. La prima applicazione che si concentra sulla distribuzione di notizie su larga scala consente alle fonti e ai fruitori di personalizzare il canale di comunicazione configurando alcuni parametri. È una soluzione flessibile che introduce dei costi che sono stati ridotti dall‟utilizzo del DDS. Per ottenere un buon livello di disponibilità di servizio si è fatto ricorso alla replicazione del sistema di consegna le cui copie si spartiscono i sink in modo casuale, lavorando in load balancing. Il test ha mostrato che la quantità di overhead è risultata linearmente proporzionale al numero delle copie. È stato necessario introdurre un ulteriore strato di gestione per realizzare funzionalità specifiche che le QoS del DDS non coprono. Il secondo articolo che si concentra su sistemi distribuiti ciber-fisici è uno dei primi tentativi di portare garanzie di QoS sfruttando la semantica sui dati provenienti dai sensori e i doppi cicli di controllo integrati. Esso ha mirato a mostrare come l‟utilizzo di CPU di publisher e subscriber sia una metrica di QoS di primaria importanza, dal momento che i 30 sovraccarichi dei processori sono la prima causa di congestione e di conseguenti ritardi di propagazione delle informazioni dalla sorgente alle destinazioni, da evitare il più possibile in applicazioni real-time mission-critical o safety-critical. 31 Bibliografia [1] OMG, “Data Distribuition Service (DDS)”, http://www.omg.org/spec/DDS/1.4 [2] OMG, “The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification”, http://www.omg.org/spec/DDSI-RTPS/2.2 [3] M. Altini, S. Bonetti, G.Cardone, A. Corradi e L. Foschini, “RE.VE.N.GE.: implementazione tramite RTI-DDS e replicazione del sistema di consegna”, http://lia.deis.unibo.it/Research/REVENGE/sb_revenge.pdf, http://www-lia.deis.unibo.it/Courses/RetiLS/prove/Altini/REVENGE%20-%20QoS%20%20relazione.pdf, http://lia.deis.unibo.it/Research/REVENGE/index.html [4] W. Kang, K. Kapitanova e S. Hyuk Son, “RDDS: A Real-Time Data Distribuition Service for Cyber-Physical System”, 2012 32