Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione II

Analisi del middleware DDS per la distribuzione di dati in tempo reale

Anno Accademico 2017/2018 Candidato: Massimo Benedetto matr. N46001596

Ai miei genitori, alla mia famiglia.

Indice

Indice ............................................................................................................................................ III Introduzione .................................................................................................................................... 4

Capitolo 1: DDS e l’implementazione OpenSplice .......................................................................... 6

1.1 Il concetto di Middleware ...................................................................................................... 6

1.2 Lo Standard DDS .................................................................................................................. 7

1.2.1 Global Data Space .......................................................................................................... 8

1.2.2 Architettura .................................................................................................................... 8

1.2.3 Dynamic Discovery ...................................................................................................... 10

1.2.4 Quality of Service (QoS) .............................................................................................. 10

1.3 L’implementazione OpenSplice ........................................................................................... 13

1.3.1 Caratteristiche principali ............................................................................................... 13

1.3.2 Architettura .................................................................................................................. 14

Capitolo 2: Analisi Sperimentale di OpenSplice ............................................................................ 16

2.1 Sistema di riferimento ......................................................................................................... 16

2.2 Strumenti di sviluppo e di test.............................................................................................. 17

2.3 Esempio 1: Tempestività ..................................................................................................... 18

2.3.1 Implementazione Publisher e Subscriber ....................................................................... 19

2.3.2 Configurazione DataListener ........................................................................................ 21

2.3.3 Test .............................................................................................................................. 22

2.4 Esempio 1: Affidabilità ....................................................................................................... 25

2.4.1 Implementazione Publisher e Subscriber ....................................................................... 25

2.4.2 Test .............................................................................................................................. 27

Conclusioni ................................................................................................................................... 30

Bibliografia ................................................................................................................................... 31

4

Introduzione

Oggigiorno è notevolmente aumentato l’uso di sistemi distribuiti ovvero sistemi «… i cui

componenti, localizzati in computer connessi in rete, comunicano e coordinano le loro

azioni solo attraverso scambio di messaggi» - G. Coulouris, J.Dollimore . In genere, tali

sistemi risultano anche eterogenei –sia dal punto di vista hardware che software. Sistemi

così complessi raramente vengono sviluppati integralmente ex novo; tipicamente essi

evolvono a partire da sistemi esistenti già funzionanti. E proprio l’esigenza di integrare

sistemi informativi sviluppati in momenti, con linguaggi e con tecniche diversi, ed

operanti su piattaforme eterogenee, ha portato alla nascita e allo sviluppo del Middleware.

Con il termine middleware si intende uno strato software interposto tra il sistema operativo

e le applicazioni, in grado di fornire le astrazioni ed i servizi utili per lo sviluppo di

applicazioni distribuite.

Lo strato middleware offre ai programmatori di applicazioni distribuite librerie di

funzioni, o middleware API (Application Programming Interface), in grado di mascherare

i problemi dovuti all’eterogeneità dei sistemi su rete. In particolare, esso rende più

semplice implementare la comunicazione e l’input/output, e consente quindi agli

sviluppatori di concentrarsi sullo scopo specifico della loro applicazione.

Esistono vari tipi di Middleware, che si distinguono per i servizi offerti. In quest’elaborato

l’attenzione verrà focalizzata sullo standard middleware Data Distribution Service (DDS).

Tale standard, definito dall’OMG (Object Managament Group) nel 2004, è un tipo di

5

Middleware orientato ai messaggi (MOM), che adotta il paradigma di comunicazione

publish-subscribe.

L’obiettivo dello standard DDS è di agevolare la distribuzione efficiente dei dati in sistemi

distribuiti, e ha come oggetto sistemi real-time e applicazioni IoT (Internet of Things). In

particolare, esso garantisce un’interoperabilità e uno scambio di dati scalabile, in tempo

reale, affidabile, sicuro, e ad alte prestazioni tra publisher e subscriber.

Alcuni esempi di applicazione dello standard DDS sono i sistemi di comando e controllo

militari, i sistemi di controllo del traffico aereo, e i sistemi di gestione dei trasporti.

Nel presente elaborato dopo aver introdotto lo standard DDS e averne analizzato gli aspetti

caratterizzanti, quali la centralità dei dati, l’architettura e le Quality of Service (QoS),

saranno esibite due applicazioni pratiche, utilizzando l’implementazione di PrismTech del

middleware, nota come: Vortex OpenSplice.

Tali applicazioni mirano ad esaminare e testare alcune funzionalità del middleware DDS.

Specificamente, nel primo esempio proposto viene analizzato l’aspetto relativo alla

tempestività dei dati, simulando la comunicazione necessaria tra sensori e controllori in un

sistema per il controllo della temperatura.

Nel secondo esempio invece, sulla base dello stesso sistema, viene approfondito l’aspetto

riguardante l’affidabilità del middleware.

6

Capitolo 1: DDS e l’implementazione OpenSplice

In questo capitolo vengono esaminate le principali caratteristiche dello standard DDS,

come l’architettura unica di cui dispone e la vasta gamma di QoS di cui è equipaggiato.

In aggiunta, viene anche analizzata una specifica implementazione del middleware: Vortex

OpenSplice.

Prima di ciò però, si ritiene opportuno fare una breve premessa, andando ad esporre il

concetto di middleware.

1.1 Il concetto di Middleware

Il middleware è uno strato software interposto tra il sistema operativo e le applicazioni, in

grado di fornire le astrazioni ed i servizi utili per lo sviluppo di applicazioni distribuite.

Lo strato middleware offre ai programmatori di applicazioni distribuite librerie di

funzioni, o middleware API (Application Programming Interface), in grado di mascherare

i problemi dovuti all’eterogeneità dei sistemi su rete. In particolare, esso rende più

semplice implementare la comunicazione e l’input/output, e consente quindi agli

sviluppatori di concentrarsi sullo scopo specifico della loro applicazione.

7

Figura 1 : Il Middleware interposto tra il sistema operativo e le applicazioni

1.2 Lo Standard DDS

Data Distribution Service (DDS) è uno standard middleware per sistemi incentrati sui dati

(data-centric), ovvero sistemi distribuiti il cui funzionamento è basato sullo scambio di

dati in tempo reale.

DDS, quindi, è un MOM data-centric, ovvero un middleware in grado di distribuire dati

da più sorgenti a più destinazioni.

Inoltre come già accennato precedentemente, DDS adotta il paradigma di comunicazione

publish-subscribe. Dunque a differenza dell’ugualmente diffuso paradigma di

comunicazione message queuing (Code di Messaggi), in cui i messaggi vengono inviati in

e prelevati da una coda, in questo modello i producers pubblicano messaggi differenziati

8

per tipo, ed i consumers possono dichiararsi interessati al messaggio in base al loro tipo. In

altri termini, ad ogni messaggio è associato un tipo (in questo contesto, detto anche Topic),

e il consumer dichiara alla piattaforma il tipo a cui è interessato.

1.2.1 Global Data Space

Lo standard DDS si basa sull’astrazione di un Global Data Space (GDS), in cui i publisher

producono dati ed i subscriber li consumano. Alle applicazioni lo spazio dati globale

appare come la memoria locale, accessibile tramite un'API; pertanto hanno l'illusione di

avere accesso all'intero spazio dati globale. Tuttavia questa è solo un'illusione; non esiste

un luogo globale in cui tutti i dati vivono. Ogni applicazione memorizza localmente solo

ciò di cui ha bisogno e solo per il tempo necessario.

Figura 2: DDS e lo Spazio Dati Globale

1.2.2 Architettura

La specifica del DDS definisce due livelli di interfacce:

• DCPS (Data Centric Publish-Subscribe): è il livello inferiore di DDS. Definisce le

entità, i ruoli, le interfacce e le policy di QoS per la piattaforma publish/subscribe,

nonché le tecniche di discovery dei partecipanti alla comunicazione. DCPS

9

rappresenta in sostanza la parte dello standard relativa alla comunicazione di rete.

• DLRL (Data Local Reconstruction Layer ): è il livello superiore di DDS. Definisce

il modello di interazione tra il mondo ad oggetti dell’applicazione ed i dati

provenienti dal DCPS. DLRL è dichiarato opzionale all'interno di DDS.

Dunque, il DCPS rappresenta l’interfaccia fondamentale di DDS. Esso definisce i seguenti

componenti:

• Dominio: è il costrutto di base con il quale il DDS gestisce le applicazioni per

permetterne la comunicazione. Ogni nodo può partecipare ad uno o più domini, ma

i componenti di un dominio possono comunicare solo con componenti dello stesso

dominio.

• DomainParticipant: rappresenta il punto di accesso per la comunicazione in uno

specifico dominio. Ogni nodo è dotato di un DomainParticipant per ogni dominio a

cui partecipa.

• Publisher: è l’entità responsabile della disseminazione dei dati.

• DataWriter: è lo strumento che consente al Publisher di pubblicare dati all’interno

di un Topic.

• Subscriber: è l’entità responsabile della ricezione dei dati.

• DataReader: è lo strumento che permette al Subscriber di leggere dati dal Topic.

• Topic: costituisce l’elemento di collegamento tra Publisher e Subscriber. Ogni Topic

è caratterizzato da un nome e da un tipo. Il nome identifica in maniera univoca il

Topic all'interno del dominio, ed il tipo caratterizza i dati scambiati all'interno del

Topic stesso. Il tipo associato ad un Topic è specificato attraverso il linguaggio

IDL (Interface Definition Language) e può essere visto come una struttura che può

comprendere sia tipi primitivi che tipi composti. DDS fornisce anche la possibilità

di distinguere varie istanze di un Topic (tutte dello stesso tipo) tramite l’uso di

semplici chiavi. Il concetto di chiave è preso in prestito dal modello Entita-

Relazione [tipico dei database relazionali], e come tale è composta da un attributo

o da un insieme di attributi di un dato che permettono di identificare univocamente

un’istanza del Topic. Inoltre, ad ogni Topic è possibile associare specifiche qualità

10

del servizio (QoS).

1.2.3 Dynamic Discovery

Lo standard DDS offre un servizio di Dynamic Discovery dei publisher e dei subscriber,

che permette un riconoscimento automatico degli endpoint. Le applicazioni dunque

risultano estensibili, in quanto non è necessario conoscere o configurare gli endpoint per le

comunicazioni dato che essi vengono rilevati automaticamente da DDS. Tutto ciò può

avvenire in fase di runtime, consentendo così un vero e proprio plug-and-play per le

applicazioni.

Grazie al Dynamic Discovery, DDS è inoltre in grado di scoprire se l’endpoint sta

pubblicando dati, sottoscrivendo dati, o entrambi. Per di più, il Dynamic Discovery

permette di individuare il tipo di dati pubblicati o sottoscritti, nonché i requisiti di

comunicazione offerti dal publisher e i requisiti di comunicazione richiesti dal subscriber.

È importante notare che nonostante le applicazioni possano trovarsi sulla stessa macchina,

o distribuite su una rete, esse utilizzano sempre le stesse API DDS per le comunicazioni.

Pertanto, non è necessario conoscere o configurare gli indirizzi IP, oppure tenere conto

delle differenze nelle architetture delle macchine: l'aggiunta di un ulteriore partecipante

alla comunicazione, con qualsiasi sistema operativo e piattaforma hardware esso operi,

diventa un’operazione estremamente semplice.

1.2.4 Quality of Service (QoS)

Data Distribution Service offre una vasta gamma di parametri relativi alla qualità del

servizio. Le QoS (Quality of Service) consentono di configurare la comunicazione tra

Publisher e Subscriber in base alle specifiche esigenze; esse infatti controllano come e

quando i dati devono essere distribuiti tra le applicazioni.

Le QOS relative al Publisher/Subscriber gestiscono la spedizione/ricezione di un insieme

di dati, incidendo su relativi tempi e modalità. È importante sottolineare che affinché un

Subscriber possa ricevere le pubblicazioni di un Publisher, le proprietà di QoS devono

essere compatibili: le QoS richieste dal DataReader non devono eccedere (ossia non

devono essere più rigorose) le QoS offerte dal DataWriter. Per verificare questa

11

compatibilità tra QoS, DDS utilizza il modello RxO (Request vs Offer).

Di seguito sono elencate le più importanti Policy QoS dello standard DDS, suddivise in

base all’aspetto che permettono di controllare:

• Data availability: tra le QoS che gestiscono la disponibilità dei dati, vi è la:

o Durabilty: mediante questa policy è possibile definire il tempo di vita dei dati

scritti dal publisher. DDS supporta tre tipi di persistenza: Volatile, Transient e

Persistent. Con Volatile i dati non vengono salvati da DDS. Con Transient

invece i dati vengono salvati localmente, così da essere disponibili anche per

successivi lettori iscritti. Infine, con Persistent i dati vengono salvati in modo

persistente, così da essere disponibili per i successivi lettori iscritti anche se il

publisher lascia il GDS.

Altre 2 importanti policy relative alla Data availability sono:

o Lifespan: permette di controllare l'intervallo di tempo durante il quale i dati

sono considerati validi; il valore predefinito è infinito.

o History: fornisce un modo per controllare il numero di campioni di dati, cioè

le scritture successive nello stesso Topic, che devono essere memorizzati per

il lettore; i possibili valori attribuibili sono: l’ultimo campione, gli ultimi N,

oppure tutti i campioni.

• Data delivery: per gestire le modalità di consegna dei dati, DDS mette a disposizione

le seguenti policy:

o Presentation: permette di gestire il modo in cui sono presentati i dati ai

subscrubers.

o Reliabilty: permette di controllare il livello di affidabilità associato alla

diffusione dei dati. Le scelte possibili sono Best-Effort e Reliable. Con la

politica Best-Effort non è garantito che tutti i messaggi siano ricevuti, né

l’ordine di consegna. Mentre con la politica Reliable è garantito che tutti i

messaggi siano ricevuti e l’ordine di consegna.

o Partition: consente di suddividere un dominio del middleware in più

partizioni logiche identificate da un nome.

12

o Destination_order: permette di definire l’ordine delle modifiche apportate da

un publisher a qualche istanza di un determinato Topic. DDS consente

l’ordinamento delle modifiche in base ai time-stamp della sorgente o della

destinazione.

o Ownership: consente di controllare il numero di scrittori di un Topic, e se la

scrittura del Topic risulta esclusiva, permette di individuare lo scrittore

autorizzato. Inoltre, in quest’ultimo caso, è possibile associare una

ownership_strenght ad ogni scrittore, ovvero un valore numerico che

permette di stabilire il proprietario del Topic: il Topic appartiene allo scrittore

che ha il valore di ownership_strength più alto. Se più DataWriter

condividono lo stesso valore di ownership_strengt, tutti i DataReader

sceglieranno lo stesso DataWriter come proprietario del Topic.

• Data Timeliness: queste policy forniscono il controllo sulle proprietà temporali dei

dati. Le QoS supportate sono:

o Deadline: consente alle applicazioni di definire l’intervallo massimo di tempo

per l’arrivo dei dati; DDS può essere configurato per notificare

automaticamente le applicazioni quando tale intervallo trascorre senza

l’arrivo di un messaggio.

o Latency_budget: fornisce un mezzo alle applicazioni per informare DDS

dell'urgenza associata ai dati trasmessi. Il latency_budget indica il tempo

entro il quale DDS deve consegnare le informazioni; questo periodo comincia

nel momento in cui i dati vengono scritti da un publisher, e termina nel

momento in cui essi diventano disponibili nella cache dei dati del subscriber.

o Transport_priority: pemette alle applicazioni di definire l'importanza

associata a un Topic o a un'istanza del Topic, consentendo in tal modo a DDS

di dare maggiore priorità ai dati più importanti.

• Resources: queste policy forniscono il controllo sulle risorse usate, come la memoria

e la larghezza di banda, per la disseminazione dei dati. Le policy messe a

disposizione da DDS sono:

13

o Time_based_filter: permette alle applicazioni di specificare l’intervallo

temporale minimo tra i campioni dei dati, esprimendo così la velocità

massima alla quale possono consumare le informazioni; i campioni prodotti

ad una velocità maggiore non vengono consegnati.

o Resource_limits: consente alle applicazioni di controllare le risorse massime

disponibili per la memorizzazione delle istanze di Topic, in modo da adattare

la consegna dei messaggi anche a dispositivi meno performanti.

1.3 L’implementazione OpenSplice

Vortex OpenSplice è un prodotto sviluppato da PrismTech, e rappresenta una delle

implementazioni più avanzate, complete e ampiamente utilizzate (commerciale e Open

Source) dello standard OMG DDS.

Vortex OpenSplice consente di condividere e integrare i dati su un ampio spettro di

sistemi operativi e piattaforme. Tuttavia si presta particolarmente all'uso su piattaforme di

tipo server-class (desktop, rack etc.), e in ambienti embedded con sistemi operativi real-

time.

Lo standard API DDS garantisce la portabilità del codice sorgente attraverso diverse

implementazioni del fornitore, in particolare OpenSplice fornisce API per i linguaggi: C,

C ++, Java e C #.

Di seguito vengono descritte le principali caratteristiche di quest’ implementazione, per

poi esaminare in dettaglio l’architettura che la caratterizza.

1.3.1 Caratteristiche principali

Vortex OpenSplice si distingue dagli altri tipi di tecnologie di messaggistica grazie alle

funzioni avanzate e alle proprietà non funzionali che apporta in un sistema. Tra queste

proprietà vi sono:

• Centralità dei dati: consente di progettare applicazioni intorno a un modello di dati

estensibile ed evolutivo, promuovendo la sicurezza di tipo end-to-end e l'efficienza

di tempo e spazio. Inoltre, la centralità dei dati promuove il disaccoppiamento di

14

tempo e spazio portando a sistemi che sono più facili da integrare, evolvere e

riutilizzare.

• Real-Time: le informazioni giuste vengono consegnate nel posto giusto al momento

giusto, sempre. La mancata consegna di informazioni chiave entro i termini

prescritti può portare a situazioni di pericolo di vita, o a fallimenti di missioni e

attività commerciali.

• Affidabilità: garanzia di disponibilità, affidabilità, sicurezza e integrità nonostante

guasti hardware e software.

• Prestazioni elevate: in grado di distribuire volumi di dati molto elevati con latenze

molto basse.

• Scalabilità: da sistemi semplici a sistemi di sistemi su larga scala, e da sensori

intelligenti a server di fascia alta.

• Sicurezza: offre la possibilità di mantenere la riservatezza, l'integrità e l'autenticità

dei dati scambiati.

1.3.2 Architettura

Vortex OpenSplice deriva dal mondo mission-critical, in cui requisiti come la tolleranza ai

guasti e la robustezza sono fondamentali. Pertanto, la necessità di soddisfare tali requisiti,

e allo stesso tempo garantire una distribuzione efficiente dei dati, ha portato allo sviluppo

di due diverse architetture:

• Distribuzione autonoma o Single Process.

• Distribuzione federata o Shared Memory.

Nell’architettura Single Process ogni processo di applicazione DDS contiene l’intera

infrastruttura DDS, pertanto non è necessario avviare alcun servizio del Middleware DDS,

in quanto essi sono già raggruppati all’interno del processo di applicazione. Un altro

vantaggio di quest’implementazione è che non è necessario pre-configurare un segmento

di memoria condivso, in quanto ogni processo utilizza la sua memoria heap per il database

DDS. Il principale vantaggio di quest’architettura è proprio la totale indipendenza tra

15

applicazioni DDS, che evita di introdurre un unico point of failure nel sistema.

Nell’architettura Shared Memory invece l’infrastruttura DDS viene avviata una sola volta

per macchina, creando un segmento di memoria condiviso tra tutti processi DDS in

esecuzione su quella macchina. Dunque ogni processo dell’applicazione DDS si

interfaccia con la memoria condivisa anziché creare l’infrastruttura DDS stessa, cosicché i

dati risultano presenti solo una volta su qualsiasi macchina. Pertanto quest’architettura

risulta molto vantaggiosa nel caso di più applicazioni DDS sulla stessa macchina, in

quanto la condivisione dei servizi e della memoria consente un miglioramento delle

prestazioni e della scalabilità.

Infine quest’architettura permette di separare il ciclo di vita del middleware (avviato

manualmente) dal ciclo di vita dell’applicazione, cosi da assicurare che applicazioni non

funzionanti abbiano un impatto limitato, fattore essenziale per sistemi mission-critical.

16

Capitolo 2: Analisi Sperimentale di OpenSplice

In questo capitolo, attraverso la realizzazione di due applicazioni pratiche, vengono

approfonditi alcuni aspetti chiave di OpenSplice e del middleware DDS. In particolar

modo, saranno valutate l’efficienza nella distribuzione dei dati, e la robustezza del sistema

a fronte di malfunzionamenti.

È importante sottolineare che l’analisi è stata condotta su uno stato soft del sistema, ovvero

modellando uno stato che viene frequentemente aggiornato. Gli esempi considerati infatti,

prevedono il continuo invio di dati da parte di sensori al controllore (ad una frequenza

elevata) e quindi anche un eventuale funzionamento non ottimale del sistema non è da

considerarsi disastroso.

Inoltre per agevolare i test e per favorirne una maggiore chiarezza, nei due esempi che

seguono vengono considerati, rispettivamente, soltanto uno e poi due publisher a fronte di

un unico subscriber. Tuttavia i risultati ottenuti sono da considerarsi di carattere generale,

e quindi estensibili anche in presenza di più publisher e subscriber.

Infine è importante sottolineare che negli esempi considerati i publisher e i subscriber non

risultano collegati fisicamente, bensì appartengono alla stessa rete LAN, e comunicano

attraverso l’uso di switch. Pertanto, i test sono stati effettuati eseguendo i publisher e i

subscriber su macchine differenti.

2.1 Sistema di riferimento

Il sistema preso in esame rappresenta un sottosistema di sensori e controllori che ha il

compito di regolare la temperatura all’interno di un edificio. In particolare, in questo

17

elaborato è stata analizzata la comunicazione a distanza tra sensori e controllori, che

ricordiamo sono collegati esclusivamente attraverso la rete, necessaria al fine di un

corretto ed efficiente controllo della temperatura.

In questo contesto i sensori rappresentano i publisher, che pubblicano i dati relativi alle

misurazioni effettuate, mentre i controllori rappresentano i subscriber, che ricevono i dati

pubblicati dai sensori. Fondamentalmente quindi i sensori inviano la temperatura rilevata

ai controllori, i quali poi, sulla base dei dati ricevuti, determinano la logica di controllo

(che esula dallo scopo di questo lavoro) da attuare.

2.2 Strumenti di sviluppo e di test

Gli esempi che a breve saranno presentati sono stati implementati nel linguaggio di

programmazione Java, ed eseguiti con l’ambiente di sviluppo Eclipse (a valle

dell’installazione di JDK).

La tipologia dei dati scambiati è stata definita in IDL (Interface Definition Language), che

permette di definire interfacce di oggetti indipendentemente dal linguaggio di

programmazione usato.

Come si nota dal codice riportato sotto, il messaggio scambiato è composto da 2 campi:

• id: è stato definito come chiave della struttura, e permette quindi di distinguere le

varie istanze all’interno di un Topic.

• temp: rappresenta l’informazione vera e propria del messaggio, ovvero la

temperatura rilevata dai sensori.

module TempData

{

struct TempSensorType

{

long id;

float temp;

};

18

#pragma keylist TempSensorType id

};

Per ricavare le interfacce specializzate (Type Support, Data Reader e Data Writer) dal file

“TempData.idl” è stato impiegato il pre-processore messo a disposizione da Vortex

OpenSplice: IDL Pre-processor. Il quale ha permesso di generare codice sorgente Java a

partire dal file IDL.

Per ottenere le classi necessarie allo scambio del tipo di dato appena definito, è stata

eseguita dal Prompt dei Comandi la seguente istruzione:

“idlpp –l java nomefile.idl”

Per quanto concerne OpenSplice, è stata utilizzata la Community Edition messa a

disposizione da PrismTech. Inoltre è stata adottata l’architettura Single Process,

utilizzando la configurazione fornita con la Community Edition del Middleware.

Tuttavia è importante sottolineare che Vortex OpenSplice consente di cambiare

l’architettura dell’applicazione semplicemente modificando un parametro di runtime.

Dunque è possibile realizzare la propria applicazione liberamente, per poi selezionare

l’architettura più adatta alle proprie esigenze.

Il test del sistema invece, è stato eseguito servendosi di due macchine diverse, entrambe

con un sistema operativo Windows, ma con versioni differenti (la prima con Windows 7

Home Premium, la seconda con Windows 10 Home)

2.3 Esempio 1: Tempestività

In questo esempio, caratterizzato dalla presenza di un Publisher e un Subscriber, si vuole

testare la capacità di DDS di distribuire i dati in tempo reale. Per fare ciò viene impostata

una deadline, insieme ad altri parametri di QoS. Si procede quindi alla configurazione

completa del Publisher e del Subscriber. Dopodichè si analizza il comportamento delle

entità coinvolte, verificando in particolar modo che venga rispettato il vincolo della

19

deadline, ovvero che la deadline impostata non venga mai mancata (in caso contrario si

parla di deadline_missed). In caso di deadline_missed viene visualizzato un opportuno

messaggio d’errore sulla console di Output. Inoltre, per una migliore analisi dei risultati,

vengono stampati a video anche tutti i dati inviati e ricevuti.

Per meglio esaminare il comportamento di DDS, questo test viene effettuato 2 volte, con 2

diversi valori della deadline:

1. Nel primo caso la deadline risulta pari a 1,5 millisecondi.

2. Nel secondo caso la deadline risulta uguale a 3 millisecondi.

Ora viene mostrata l’implementazione del Publisher e del Subscriber, che risultano

perfettamente uguali per i due casi di test, eccezion fatta per il valore della deadline (e di

conseguenza del Latency_budget di cui parleremo tra poco)

2.3.1 Implementazione Publisher e Subscriber

Prima di mostrare in dettaglio il codice relativo al Publisher e al Subscriber, si vuole

descrivere il comportamento di queste 2 entità:

• Publisher: pubblica 50 messaggi, uno ogni millisecondo, con un valore casuale

della temperatura compreso tra 0 e 100.

• Subscriber: sottoscrive il Topic di interesse e attende di ricevere messaggi.

Inoltre, sia il publisher che il subscriber stampano a video i rispettivi valori della

temperatura di ciascun messaggio inviato/ricevuto.

Per un corretto funzionamento della comunicazione, è necessario che le QoS del Publisher

e del Subscriber rispettino il modello RxO (Request vs. Offer) del middleware. Dunque le

Quality of Service del Publisher e del Subscriber vengono cosi impostate:

20

...

//Settaggio delle QoS:

Reliability r = PolicyFactory.getPolicyFactory(env).Reliability()

.withBestEffort();

Durability d = PolicyFactory.getPolicyFactory(env).Durability()

.withVolatile();

History h= PolicyFactory.getPolicyFactory(env).History().withKeepLast(1)

Deadline deadline=PolicyFactory.getPolicyFactory(env).Deadline()

.withPeriod(1500, TimeUnit.MICROSECONDS);

LatencyBudget lat_budget=PolicyFactory.getPolicyFactory(env).LatencyBudget(

.withDuration(750, TimeUnit.MICROSECONDS);

...

Il latency budget è stato posto pari al valore della deadline/2, come suggerito dal

Produttore. Mentre le altre QoS sono state impostate in modo da modellare un sistema

soft, come spiegato in precedenza.

Di seguito invece viene mostrato il codice che permette al Publisher di pubblicare i dati

nel Topic:

...

for(int i=0;i<50;i++) {

float temp= (float) Math.random()*100;

// Il messaggio che si vuole pubblicare

//( id, temp)

msg = new TempSensorType(1,temp);

// Pubblicazione del messaggio

writer.write(msg);

System.out.println("| Messaggio "+ (i+1) +" Temperatura : "

+ msg.temp );

//Invia i dati ogni millisecondo

Thread.sleep(1);

}

...

Infine, viene esibito il codice che consente al Subscriber di leggere i dati dal Topic:

21

...

System.out.println("[Subscriber] Subscriber avviato!");

while(true) {

reader.setListener(myListener);

}

...

Osservando il codice del Subscriber si nota che l’istruzione per leggere i dati si trova in un

ciclo while. Si suppone infatti che il subscriber non sappia quanti messaggi dovrà leggere,

e che sia sempre in attesa di dati; pertanto l’istruzione viene eseguita per un periodo di

tempo indefinito (“per sempre”).

Inoltre, da un attento confronto dei codici sopra riportati, si evince che il codice del

Subscriber relativo alla lettura dei dati risulta leggermente diverso dal codice che permette

al Publisher di pubblicare dati nel Topic; esso infatti non è semplicemente duale, ma si

serve di una nuova entità per mettersi in attesa di dati: il Listener.

2.3.2 Configurazione DataListener

Il Listener è un servizio offerto dal DataReader che permette al subscriber di attendere in

modo asincrono l’arrivo di dati. Grazie a questo servizio infatti, una volta configurato il

Listener con il relativo metodo “onDataAvailable”, il subscriber può tranquillamente

dedicarsi ad altre operazioni, sarà infatti l’infrastruttura DDS ad inviargli una notifica non

appena arriveranno nuovi dati.

Inoltre l’uso del Listener risulta di fondamentale importanza per il test che si vuole

eseguire. Esso infatti grazie al metodo “onRequestDeadlineMissed consente di rilevare le

eventuali deadline mancate, e nel caso specifico, segnala l’evento tramite un messaggio su

console, come si evince dal codcie sottostante:

...

public class DataListener extends DataReaderAdapter<TempSensorType>

{

@Override

public void onDataAvailable(DataAvailableEvent<TempSensorType> status)

{

DataReader<TempSensorType> reader = status.getSource();

List<Sample<TempSensorType>> samples =

22

new ArrayList<Sample<TempSensorType>>();

reader.take(samples);

if (samples.size() > 0) {

TempSensorType msg = samples.get(0).getData();

if (msg != null) {

System.out.println("[DataListener] Messaggio ricevuto");

System.out.println("\t\tid : "+msg.id);

System.out.println("\t\tTemp : "+msg.temp);

}

}

}

@Override

public void onRequestedDeadlineMissed(RequestedDeadlineMissedEvent

<TempSensorType> status)

{

System.out.println("[ListenerDataListener.on_requested_deadline

_missed] : triggered");

System.out.println("[ListenerDataListener.on_requested_deadline

_missed] : stopping");

}

}

...

2.3.3 Test

Per testare il comportamento del sistema innanzitutto viene avviato il Subscriber.

Dopodichè viene avviato il publisher. Un estratto degli output dell’esecuzione è mostrato

in figura 3 e 4, per il Publisher e il Subscriber rispettivamente.

Figura 3: Output dei primi 5 messaggi inviati dal Publisher; deadline pari a 1,5 ms.

23

Figura 4: Output dei primi 5 messaggi ricevuti dal Subscriber; deadline pari a 1,5 ms.

Ora viene invece mostrata parte dell’output relativo all’esecuzione del test con la deadline

fissata a 3 millisecondi:

Figura 5: Output dei primi 4 messaggi inviati dal Publisher; deadline pari a 3 ms.

Figura 6: Output degli ultimi 4 messaggi inviati dal Publisher; deadline pari a 3 ms.

24

Figura 6: Output dei primi 4 messaggi ricevuti dal Subscriber; deadline pari a 3 ms.

Figura 7: Output degli ultimi 4 messaggi ricevuti dal Subscriber; deadline pari a 3 ms.

Nel caso di deadline pari a 1,5 millisecondi (figura 4), si nota che la deadline_missed

viene ”catturata” 7 volte, e vengono recepiti 37 messaggi dei 50 inviati.

Le figura 7 e 8 invece mostrano un netto miglioramento delle prestazioni. Con la deadline

posta a 3 millisecondi infatti, la deadline non viene mai mancata, e inoltre vengono

recepiti 47 messaggi a fronte dei 50 inviati.

Nell’analizzare i risultati tuttavia bisogna ricordare la natura del sistema. Trattandosi

infatti di un sistema soft, che prevede un invio dei dati ad alta frequenza, e che mette in

conto l’eventuale perdita di alcuni messaggi, i risultati ottenuti sono da considerarsi

25

soddisfacenti. Inoltre c’è da tenere in conto che le applicazioni DDS sono state eseguite su

un sistema time-sharing, che quindi non permette di raggiungere risultati ottimali, e che

molto probabilmente è la causa dello smarrimento di 6 messaggi nel primo test, e di 3

messaggi nel secondo.

2.4 Esempio 1: Affidabilità

Con questo esempio, caratterizzato dalla presenza di 2 Publisher ed un Subscriber, si vuole

testare l’affidabilità di OpenSplice. Per fare ciò viene simulato il malfunzionamento di un

publisher, che quindi ad un certo punto smetterà di inviare messaggi al Subscriber.

Tra i vari parametri di QoS impostati in quest’esempio vi è la deadline, che è stata settata a

3 secondi così da poter osservare meglio il susseguirsi degli eventi.

Inoltre in aggiunta alle QoS del primo esempio, per garantire una maggiore chiarezza, è

stata configurata la QoS ownership, che permette di assegnare la proprietà delle istanze di

un Topic.

Nel paragrafo che segue vengono mostrate in dettaglio le varie implementazioni dei

Publisher e dei Subscriber, per poi procedere alla fase di test, che, come nell’esempio

precedente, è caratterizzata dalla stampa a video di tutti i dati inviati e ricevuti.

2.4.1 Implementazione Publisher e Subscriber

Prima di esibire le implementazioni dei 2 Publisher e del Subscriber, viene di seguito

illustrato il comportamento previsto da queste 3 entità:

• PublisherPrincipale: pubblica 5 messaggi, uno ogni secondo, con un valore casuale

della temperatura che va da 0 a 49.

• PublisherSecondario: pubblica 10 messaggi, uno ogni secondo, con un valore

casuale della temperatura che va da 51 a 100.

• Subscriber2: sottoscrive il Topic di interesse e attende di ricevere messaggi.

Da notare che il PublisherPrincipale e il Publisherecondario generano diversi valori della

temperatura, così da essere facilmente distinguibili in fase di analisi dei risultati.

26

Le QoS del PublisherPrincipale, PublisherSecondario, e del Subscriber2 sono settate come

segue:

... //Settaggio delle QoS: Reliability r = PolicyFactory.getPolicyFactory(env).Reliability()

.withBestEffort(); Durability d = PolicyFactory.getPolicyFactory(env).Durability()

.withVolatile(); History h= PolicyFactory.getPolicyFactory(env).History().withKeepLast(1);

Deadline deadline=PolicyFactory.getPolicyFactory(env).Deadline() .withPeriod(3000, TimeUnit.MILLISECONDS);

LatencyBudget lat_budget=PolicyFactory.getPolicyFactory(env).LatencyBudget() .withDuration(1500, TimeUnit.MILLISECONDS);

DestinationOrder dest_order =PolicyFactory.getPolicyFactory(env) .DestinationOrder().withSourceTimestamp();

Ownership own=PolicyFactory.getPolicyFactory(env).Ownership().withExclusive(); ...

Si nota innanzitutto la presenza della Policy Ownership, come era stato già accennato nel

precedente paragrafo. Dal codice soprastante si vede poi che tale Policy è stata impostata

come Exclusive, e pertanto risultano Exclusive anche le istanze del Topic condivise dai

Publisher e dal Subscriber dell’esempio considerato.

Oltre a ciò, non essendo stato settato alcun valore della ownership_strenght per nessuno

dei due Publisher, nel caso in cui più DataWriter tentano di modificare l’istanza del Topic,

il DataWriter proprietario dell’istanza del Topic, ovvero il DataWriter con il diritto di

pubblicare i dati nel Topic, viene scelto dal DataReader.

Il codice relativo alla pubblicazione e alla sottoscrizione dei dati è sostanzialmente uguale

a quello dell’esempio precedente, con l’unica differenza di dover considerare QoS

aggiuntive. Per tale motivo, e per ragioni di brevità, si fa a meno di riportarlo.

Inoltre, anche stavolta il DataReader fa uso del Listener, la cui implementazione viene

omessa in quanto totalmente identica a quella mostrata nell’Esempio 1.

27

2.4.2 Test

Per testare il comportamento del sistema, per prima cosa viene avviato il processo

Subscriber2. Dopodichè viene eseguito il PublisherPrincipale. E, Immediatamente dopo

viene lanciato il processo PublisherSecondario.

I risultati dell’esecuzione sono mostrati in figura 9, 10 e 11.

Figura 8: Output dei 5 messaggi inviati dal PublisherPrimario

Figura 9: Output degli ultimi 5 messaggi inviati dal PublisherSecondario

28

Figura 10: Output dei 10 messaggi ricevuti dal Subscriber2

Come si evince dalle immagini soprastanti, nei 5 secondi (circa) successivi al lancio delle

applicazioni, entrambi i publisher tentano di pubblicare i dati rilevati nell’istanza del

Topic. Tuttavia, siccome il PublisherPrincipale è il primo Publisher avviato, esso risulta

essere il proprietario esclusivo dell’istanza del Topic considerata.

Per questa ragione, i dati ricevuti e stampati a video dal subscriber nei primi 5 secondi

(circa), si rivelano essere proprio quelli pubblicati dal PublisherPrincipale.

Trascorsi all’incirca 5 secondi dall’avvio delle applicazioni, il PublisherPrincipale ha

pubblicato tutti e 5 i messaggi previsti dalla sua implementazione, e passa quindi allo stato

29

not alive.

È in quest’istante che è possibile apprezzare una delle peculiarità del middleware e di

OpenSplice: il Dinamic Discovery. Osservando l’output della console infatti, ci si accorge

che il PublisherScondario inzia a pubblicare messaggi nel Topic, e che gli stessi messaggi

giungono al Subscriber. Ciò è reso possibile, appunto, grazie al servizio di scoperta

dinamica di cui è dotato il middleware, che consente di modificare dinamicamente, e in un

tempo molto breve, il DataWriter del Topic.

Quindi, il PublisherSecondario continua a pubblicare messaggi, per poi terminare con

l’esecuzione dell’ultima istruzione del suo codice.

Questo permette di evidenziare anche un’altra importante proprietà di OpenSplice. Se si

suppone infatti che l’esecuzione del PublisherPrincipale sia cessata, precocemente, a causa

di un malfunzionamento improvviso, questo test può fornire un’idea generale

sull’affidabilità di cui gode OpenSplice. Difatti, a fronte di un’interruzione improvvisa del

PublisherPrincipale, il funzionamento del sistema non ne ha risentito particolarmente, anzi

ha continuato a funzionare come se niente fosse accaduto, il Subscriber2 infatti ha

continuato a ricevere dati da un altro publisher, senza sospettare minimamente del

fallimento del PublisherPrincipale.

30

Conclusioni

Con il presente elaborato è stato possibile esaminare nel dettaglio le grandi potenzialità

dello standard middleware DDS, uno standard univocamente incentrato sui dati, che

rappresenta la tecnologia ideale per sistemi mission-critical e IoT (Internet of Things).

Inoltre, ai fini di un’analisi più approfondita, è stata di grande importanza la realizzazione

di applicazioni pratiche, per le quali è stata adoperata l’implementazione Vortex

OpenSplice di PrismTech. Tale Implementazione è risultata di semplice utilizzo, grazie

alle API fornite dal produttore.

In particolare, con lo sviluppo delle due applicazioni pratiche, si è tentato di sperimentare

due importanti proprietà del middleware.

Il primo esempio ha mirato a mostrare l’abilità del middleware di distribuire dati in tempo

reale, caratteristica imprescindibile per sistemi mission-critical.

Con il secondo esempio invece, si è cercato di testare l’affidabilità del middleware DDS,

ovvero la capacità di garantire la disponibilità, la sicurezza e l’integrità dei dati nonostante

improvvisi guasti software e/o hardware.

Le applicazioni realizzate quindi, forniscono un riscontro concreto di alcuni aspetti chiave

del middleware DDS, e dell’implementazione OpenSplice nello specifico. Tuttavia, come

spiegato nei paragrafi precedenti, è importante ricordare che ai fini di una maggiore

chiarezza e facilità di test, sono state adottate alcune semplificazioni, e inoltre la verifica

degli esempi sviluppati non è avvenuta negli ambienti e con le modalità ottimali.

31

Bibliografia

[1] S. Russo, C. Savy, D. Cotroneo, A. Sergio, “Introduzione a corba”, McGraw-Hill,

2002

[2] OMG, “What is DDS?”, http://portals.omg.org/dds/what-is-dds-3/

[3] PrismTech, “Vortex OpenSplice” , http://www.prismtech.com/vortex/vortex-

opensplice

[4] PrismTech, “Quality of Service”,

http://download.prismtech.com/docs/Vortex/html/ospl/DDSTutorial/qos.html

[5] PrismTech, “Vortex OpenSplice Architectural Modes”,

http://download.prismtech.com/docs/Vortex/html/ospl/EvaluationGuide/architectural.html

[6] Angelo Corsaro, “The DDS Tutorial”, http://www.laas.fr/files/SLides-A_Corsaro.pdf