Elaborato Flaminio Alessandro N46001998

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Programmazione II
Analisi sperimentale delle policy di QoS di
OpenDDS
Anno accademico 2015/2016
Candidato:
Alessandro Flaminio
mat. N46001998
Indice
Introduzione
0.1 Introduzione al concetto di middleware . . . . . . . . . . . . . . .
0.2 Metodo e finalità del lavoro . . . . . . . . . . . . . . . . . . . . .
1 DDS/OpenDDS
1.1 Lo standard DDS . . . . . . . . . . . .
1.1.1 Data-centricity . . . . . . . . .
1.1.2 Global Data Space . . . . . . .
1.1.3 Quality of Service . . . . . . . .
1.1.4 Dynamic Discovery . . . . . . .
1.1.5 RTPS . . . . . . . . . . . . . .
1.1.6 DCPS e DLRL . . . . . . . . .
1.2 OpenDDS . . . . . . . . . . . . . . . .
1.2.1 ACE e TAO . . . . . . . . . . .
1.2.2 Caratteristiche . . . . . . . . .
1.2.3 Compliance alle specifiche DDS
2 Le policy di QoS di DDS/OpenDDS
2.1 Timeliness dei dati . . . . . . . . . .
2.1.1 DEADLINE . . . . . . . . . .
2.1.2 LATENCY BUDGET . . . .
2.1.3 TRANSPORT PRIORITY . .
2.2 Disponibilità dei dati . . . . . . . . .
2.3 Consegna dei dati . . . . . . . . . . .
2.4 Risorse . . . . . . . . . . . . . . . . .
2.5 Configurazione . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
.
.
.
.
4
4
4
6
6
7
7
8
9
9
10
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
13
13
14
15
15
3 Applicazione dimostrativa basata su OpenDDS
3.1 Sistema . . . . . . . . . . . . . . . . . . . . . .
3.2 Strumenti utilizzati . . . . . . . . . . . . . . . .
3.3 Implementazione . . . . . . . . . . . . . . . . .
3.3.1 Definizione del tipo di dato Message . .
3.3.2 Implementazione Publisher e Subscriber
3.3.3 Immissione policy di QoS . . . . . . . .
3.3.4 Configurazione listener del Data Reader
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
18
18
19
20
20
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Analisi sperimentale delle policy di timeliness di OpenDDS
4.1 Policy di QoS utilizzate . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Caso 1: Calcolo empirico dei tempi di consegna di OpenDDS . . .
4.2.1 Controllore e sensore sulla stessa macchina . . . . . . . . .
4.2.2 Controllore e sensore su macchine diverse . . . . . . . . . .
4.3 Caso 2: Test di utilizzo della policy DEADLINE . . . . . . . . . .
4.4 Caso 3: Verifica prestazioni in presenza di TRANSPORT PRIORITY
22
22
22
22
23
24
24
5 Conclusioni
29
Sitografia
30
ii
Elenco delle figure
1
Il middleware si interpone tra il sistema operativo e le applicazioni.
2
1.1
1.2
Grazie a DDS le applicazioni possono comunicare tramite operazioni di publish/subscribe su determinati Topic. . . . . . . . . . .
Architettura dello standard DDS. . . . . . . . . . . . . . . . . . .
6
9
2.1
Le policy di QoS di DDS. . . . . . . . . . . . . . . . . . . . . . .
11
3.1
I processi comunicano tramite operazioni di publish/subscribe su
determinati Topic. . . . . . . . . . . . . . . . . . . . . . . . . . .
Definizione dell’interfaccia IDL per il tipo di dato Message. . . . .
Comandi necessari alla compilazione dell’interfaccia IDL. . . . . .
Output della compilazione IDL. . . . . . . . . . . . . . . . . . . .
La priorità viene indotta dall’argomento ricevuto dal terminale,
dopodiché vengono impostati i campi relativi alle policy di QoS. .
La funzione on data available() viene richiamata ogni qualvolta
sono disponibili nuovi dati al Data Reader. . . . . . . . . . . . . .
3.2
3.3
3.4
3.5
3.6
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Snippet di codice del sensore che mostra l’invio del messaggio
contenente il timestamp. . . . . . . . . . . . . . . . . . . . . . . .
Snippet di codice del controllore che mostra la ricezione del timestamp e il calcolo della latenza. . . . . . . . . . . . . . . . . . . .
Calcolo latenza da parte del controller a fine esecuzione. . . . . .
Grafico rappresentante sull’asse delle ascisse il numero di messaggi inviati dal sensore al controllore e sull’asse delle ordinate
la latenza in nanosecondi. In rosso sono riportati i risultati di
LatencyStatistics e in blu i risultati ottenuti dall’elaborazione
dei timestamp. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grafico relativo alla latenza tra due macchine diverse. In arancio
sono riportati i risultati di LatencyStatistics e in ciano i risultati
ottenuti dall’elaborazione dei timestamp. . . . . . . . . . . . . . .
Numero di deadline miss dato l’invio di 30 messaggi intervallati da
usleep(1) e con deadline di un microsecondo. . . . . . . . . . . .
Numero di deadline miss dato l’invio di 30 messaggi intervallati da
usleep(1) e con deadline di 5000 microsecondi. . . . . . . . . . .
Tramite le LatencyStatistics è possibile notare come i messaggi
vengano consegnati con le giuste priorità. . . . . . . . . . . . . . .
iii
17
18
19
19
20
21
23
24
25
26
26
27
27
28
Abstract
During the past decades, distributed Real-Time systems and Internet of Things
(IoT) applications have grown exponentially in importance. It is vital to have
efficient and simple tools to develop connected softwares. This work describes
the DDS middleware standard and traces the key features of the OpenDDS implementation of the standard. It is then reported an example application using
the OpenDDS APIs, which is used to demonstrate experimentally the Quality of
Service (QoS) timeliness policies of the platform.
Introduzione
Sommario
Al giorno d’oggi, con l’irrefrenabile sviluppo di sistemi distribuiti e di applicazioni
basate sull’Internet of Things (IoT), è sempre più utile disporre di strumenti
semplici e snelli per lo sviluppo di software connessi tra loro. Nella fattispecie,
questo elaborato approfondisce lo standard middleware Data Distribution Service
(DDS), focalizzandosi su una particolare implementazione di esso: OpenDDS. È
quindi riportata un’applicazione esemplificativa, implementata tramite le API
specifiche di OpenDDS, al fine di dimostrare il funzionamento del middleware e
di analizzare sperimentalmente le diverse policy di Quality of Service relative alla
timeliness o↵erte dallo standard.
0.1
Introduzione al concetto di middleware
In un sistema distribuito, un middleware è uno strato che si interpone tra sistema
operativo e applicazioni (fig. 1). Esso permette ai vari componenti del sistema di
comunicare più facilmente e di condividere dati tramite l’utilizzo della rete, a dispetto delle eterogeneità che possono caratterizzarli. Un middleware semplifica lo
sviluppo di sistemi, permettendo agli sviluppatori di concentrarsi sulla cosiddetta business logic delle loro applicazioni, piuttosto che sui dettagli implementativi
relativi alla comunicazione tra processi. Generalmente un middleware fornisce le
seguenti astrazioni:
• Trasparenza del sistema operativo;
• Trasparenza del linguaggio di programmazione;
• Trasparenza della locazione;
• Trasparenza della migrazione;
• Trasparenza ai guasti;
• Trasparenza della replicazione;
• Trasparenza delle implementazioni commerciali.
1
Figura 1: Il middleware si interpone tra il sistema operativo e le applicazioni.
0.2
Metodo e finalità del lavoro
Negli ultimi decenni sono stati realizzati numerosi middleware atti a semplificare
la progettazione e lo sviluppo di sistemi distribuiti. Nel caso di SoS (System of Systems) e di applicazioni dell’Internet of Things (IoT) si è distinto, in particolare,
uno standard in grado di supportare l’eterogeneità, la scalabilità e la dinamicità tipiche di questi sistemi: il middleware message-oriented Data Distribution
Service (DDS). Nell’ambito dei sistemi Real-Time, è di cruciale importanza la
capacità di DDS di permettere un controllo preciso su diversi aspetti di Quality
of Service (QoS) dello scambio di messaggi, specificamente su quelli riguardanti
la temporizzazione.
Per questi motivi il lavoro si è so↵ermato sullo standard DDS e sulle policy di
QoS o↵erte da esso. Nello specifico, data la loro primaria importanza nei sistemi
Real-Time, sono analizzate le seguenti policy relative alla timeliness: DEADLINE,
LATENCY BUDGET e TRANSPORT PRIORITY. Vengono anzitutto esaminati lo standard DDS ed una sua particolare implementazione (OpenDDS) e sono messe
in risalto le policy di QoS o↵erte, ponendo un particolare accento su quelle relative alla timeliness. Nell’ambito dell’implementazione OpenDDS, utilizzando
i numerosi strumenti e funzioni disponibili, è quindi riportata un’applicazione
esemplificativa relativa ad un SoS costituito da un controllore e tre sensori, realizzata al fine di testare l’utilizzo di alcune delle diverse funzionalità o↵erte da
OpenDDS. L’implementazione di esempio è stata utilizzata per e↵ettuare misu-
2
razioni temporali e per verificare sperimentalmente il funzionamento delle policy
di QoS dello standard DDS.
In questo modo vengono dimostrate la semplicità e l’efficienza dello standard, fornendo delle misurazioni empiriche che potrebbero essere utilizzate come punto di
partenza nella valutazione di DDS nell’ambito della progettazione di un ipotetico
sistema.
3
Capitolo 1
DDS/OpenDDS
1.1
Lo standard DDS
Data Distribution Service for Real-Time Systems (DDS) è uno standard middleware specifico per sistemi Real-Time sviluppato da Object Management Group
(OMG). DDS è un MOM (message-oriented middleware) data-centric basato sul
paradigma publish/subscribe, progettato per garantire connettività a bassa latenza, estrema affidabilità e un’architettura scalabile per applicazioni mission-critical
e Internet of Things (IoT).
1.1.1
Data-centricity
Un middleware data-centric come DDS rappresenta un approccio concettualmente di↵erente ai classici MOM message-centric: infatti la data-centricity assicura
che i messaggi scambiati tra le applicazioni contengano le corrette informazioni
contestuali per permettere all’applicazione di riconoscere i dati ricevuti. DDS
conosce i dati da esso immagazzinati e ne controlla la condivisione. La programmazione di sistemi distribuiti che utilizzano MOM message-centric prevede che
venga scritto del codice per l’invio dei messaggi, i sistemi data-centric permettono
invece di focalizzarsi direttamente su quando e come condividere dati, occupandosi direttamente dell’invio dei dati stessi. DDS implementa una condivisione
delle informazioni controllata e sicura.
Le applicazioni comunicano tramite le operazioni di publish e subscribe su specifici Topic, inoltre le sottoscrizioni possono essere caratterizzate da filtri, che
permettono di ottenere solo un sottoinsieme dei dati pubblicati su un determinato Topic.
Un’applicazione sviluppata con un middleware data-centric risparmia al team di
sviluppatori di scrivere migliaia di linee di codice, e per questo permette una significativa riduzione del budget economico e temporale garantendo una maggiore
affidabilità al sistema.
4
Message-Centric Middleware
È necessario definire un set di messaggi basandosi sugli scambi di informazioni richiesti per supportare i
casi d’uso previsti. Nel caso in cui si
presentino nuovi casi d’uso nelle applicazioni è necessario riprogettare il
set di messaggi.
Ogni applicazione deve gestire la
compatibilità tra dati ricevuti/inviati, mantenendo autonomamente una
versione locale del dato. Nel caso in
cui un’applicazione necessiti solo un
sottoinsieme dei dati ricevuti, è necessario gestire il filtraggio a livello
applicativo.
Data-Centric Middleware
Viene definito un modello dei dati basato sulle informazioni necessarie a descrivere lo stato del sistema. Quando nuove risorse vengono
aggiunte, il modello dei dati viene
espanso per includerle.
La compatibilità tra tipi di dato viene gestita dal middleware, che si occupa inoltre di garantire un modello locale dello stato del sistema ad
ogni applicazione. Il middleware è
in grado di recapitare automaticamente i messaggi ai partecipanti in
base alle informazioni di interesse,
garantendone il filtraggio.
Cambiamenti nel sistema quali l’ag- Il middleware si occupa automatigiunta di nuovi dispositivi, la presen- camente di notificare la presenza di
za di nuovi flussi di dati o problemi nuovi partecipanti, di recapitare i
di connessione devono essere gestiti dati provenienti da nuovi flussi di
direttamente dalle applicazioni.
dati e di tenere traccia delle informazioni inviate quando la rete non è
disponibile.
Tabella 1.1:
Data-Centric.
Confronto tra middleware Message-Centric e middleware
5
1.1.2
Global Data Space
DDS è caratterizzato da una posizione di archiviazione dati locale ad ogni applicazione chiamata Global Data Space (GDS). Ad ogni partecipante del dominio DDS, 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. Gli elementi presenti
in questa area di memoria sono accessibili tramite la tupla (Topic, Key). DDS
provvede alla creazione di Local Object Cache costruite a partire dal GDS; le
modifiche e↵ettuate sulla Local Object Cache vengono riportate sul GDS. Nonostante la presenza di questo ”modello comune” che potrebbe far pensare alla
presenza di un server, 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 (nodi di fallimento
centralizzati).
Figura 1.1: Grazie a DDS le applicazioni possono comunicare tramite operazioni
di publish/subscribe su determinati Topic.
1.1.3
Quality of Service
I dati possono essere condivisi con DDS utilizzando delle flessibili specifiche di
Quality of Service (QoS) che permettono di garantire requisiti di affidabilità,
sicurezza e salute del sistema (liveliness):
• In un sistema reale non tutti i nodi necessitano della totalità dei dati presente nel Global Data Space: DDS invia solo ciò di cui ogni processo ha
e↵ettivamente bisogno;
6
• Se i messaggi non raggiungono le destinazioni, il middleware implementa
l’affidabilità della consegna quando necessario;
• Se la quantità di dati è ingente, DDS e↵ettua un filtraggio intelligente e
invia soltanto i dati di cui ogni nodo ha bisogno;
• Quando il sistema cambia, DDS riconosce dinamicamente a chi inviare quale
dato, e informa intelligentemente i partecipanti dei cambiamenti;
• 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.
Le policy di QoS verranno ulteriormente esaminate in seguito, nell’ambito dell’implementazione dello standard DDS OpenDDS.
1.1.4
Dynamic Discovery
DDS dispone di un servizio di Dynamic Discovery dei publisher e dei subscriber
che permette un riconoscimento automatico degli endpoint da parte del middleware; grazie a questa caratteristica è infatti possibile realizzare applicazioni in
cui ulteriori partecipanti possono entrare a far parte del dominio gestito da DDS a
tempo di esecuzione, realizzando un vero e proprio sistema plug-and-play. Grazie
al Dynamic Discovery, DDS è inoltre in grado di riconoscere lo stato dei publisher
e dei subscriber, comprese le caratteristiche di connessione di entrambi e i tipi di
dato condivisi da essi.
Nonostante le applicazioni possano trovarsi sulla stessa macchina o su diversi sistemi posti in una rete, esse utilizzano le stesse API o↵erte dallo standard. Dato
che non è necessaria la configurazione manuale degli indirizzi IP per realizzare
le comunicazioni, è estremamente flessibile aggiungere partecipanti al dominio,
anche aventi piattaforme software/hardware diverse.
1.1.5
RTPS
Il protocollo Real-Time Publish Subscribe (RTPS) è stato specificamente realizzato per supportare i requisiti dei sistemi a data-distribution, ed, in particolare, esso viene utilizzato dallo standard DDS per permettere un’interoperabilità
multi-vendor tra le varie implementazioni dello standard. RTPS è progettato per
funzionare su IP multicast e con protocolli di trasporto connectionless e best-e↵ort
come UDP/IP. Il protocollo presenta le seguenti principali caratteristiche:
7
• Specifiche QoS atte a realizzare comunicazioni publish-subscribe best-e↵ort
e affidabili per applicazioni Real-Time, utilizzando reti IP standard;
• Tolleranza ai guasti;
• Estensibilità e interoperabilità tra varie versioni dello standard;
• Connettività plug-and-play per le nuove applicazioni;
• Modularità, per consentire ai dispositivi di utilizzare soltanto un sottoinsieme delle caratteristiche o↵erte dal protocollo;
• Scalabilità;
• Type-safety per prevenire errori di programmazione.
1.1.6
DCPS e DLRL
Data-Centric Publish Subscribe (DCPS) è una formalizzazione realizzata dallo
standard DDS per le comunicazioni publish-subscribe. In particolare, DCPS è la
API più bassa tra gli strati di DDS ed è utilizzata dalle applicazioni per le comunicazioni con altri processi basati su DDS. Il Data Local Reconstruction Layer
(DLRL) è invece situato sullo strato più alto perché specifica come un’applicazione possa interfacciarsi con i campi dati di DCPS attraverso le proprie classi in
ambiente di programmazione object-oriented.
Nello specifico, DCPS fornisce le seguenti entità primarie allo standard DDS:
• Domain,
• Domain Participant,
• Data Writer,
• Publisher,
• Data Reader,
• Subscriber,
• Topic.
Sebbene queste fondamentali proprietà del layer DCPS siano suscettibili ad ulteriori approfondimenti, si è preferito focalizzare questo elaborato su altri aspetti
salienti dello standard DDS.
8
Figura 1.2: Architettura dello standard DDS.
1.2
OpenDDS
OpenDDS è un’implementazione open-source scritta in C++ dello standard OMG
DDS, fruibile anche in applicazioni Java tramite l’utilizzo di binding Java e JMS.
OpenDDS è perlopiù sviluppato da Object Computing, Incorporated (OCI), che
ne rilascia i sorgenti sotto licenze open-source. Questa particolare implementazione di DDS è realizzata sull’abstraction layer fornito da ACE per garantire la
portabilità della piattaforma; inoltre fa utilizzo di TAO e del suo compilatore
Interface Description Language (IDL).
1.2.1
ACE e TAO
ADAPTIVE Communication Environment (ACE) è un framework object-oriented
teso alla portabilità che implementa i fondamentali design pattern per il software
concorrente che utilizza la rete. ACE fornisce una serie di wrapper e framework
in C++ che garantiscono diversi task per la comunicazione tra una vasta gamma
di sistemi operativi.
The ACE ORB (TAO) è un framework middleware basato sullo standard Common Object Request Broker Architecture (CORBA) che permette ai client di
invocare operazioni su oggetti distribuiti. L’utilizzo del framework TAO permette di non dover disporre obbligatoriamente di informazioni relative alla posizione
dell’oggetto remoto, al protocollo di comunicazione utilizzato, al sistema opera9
tivo o all’hardware remoti.
OpenDDS fa uso delle suddette tecnologie per snellire lo sviluppo del middleware
stesso, evitando di gestire problematiche quali la portabilità da una piattaforma
all’altra, problemi di multi-threading e sincronizzazione, rilevamento guasti, ecc.
1.2.2
Caratteristiche
OpenDDS è basato sulla versione 1.4 dello standard DDS (formal/2015-04-10) e
sulla versione 2.2 del protocollo DDS-RTPS (formal/2014-09-01).
OpenDDS o↵re di default le implementazioni dei seguenti protocolli di livello
trasporto (sia con IPv4 che con IPv6):
• TCP/IP,
• RTPS/UDP,
• UDP/IP,
• IP multicast.
Tramite l’utilizzo del Pluggable Transport Layer è comunque possibile per gli
sviluppatori realizzare protocolli di trasporto ad-hoc da utilizzare con OpenDDS.
1.2.3
Compliance alle specifiche DDS
OpenDDS, essendo compliant allo standard DDS, implementa tutti i profili del
layer DCPS. Gli sviluppatori possono inoltre definire strutture in IDL da utilizzare come tipi di dato di DDS. Le strutture possono includere tipi scalari base,
stringhe, sequenze, vettori, enumerazioni e unioni.
OpenDDS supporta anche le seguenti caratteristiche della specifica DDS-RTPS:
• Supporto a tutti gli RTPS Message;
• Supporto a RTPS Discovery tramite l’implementazione del Simple Participant Discovery Protocol (SPDP) e Simple Endpoint Discovery Protocol
(SEDP);
• Le implementazioni di tutti gli elementi hanno proprietà relative al tempo
modificabili;
• Supporto a tutti i comportamenti RTPS Reader e RTPS Writer richiesti;
• Supporto a tutte le funzionalità QoS di RTPS.
10
Capitolo 2
Le policy di QoS di
DDS/OpenDDS
In quanto compliant allo standard DDS, OpenDDS o↵re tutte le policy di QoS
descritte dalla specifica. In particolare, le policy possono essere suddivise in
base ai seguenti requisiti non-funzionali: timeliness dei dati, disponibilità dei
dati, consegna dei dati, risorse e configurazione. Ad ogni entità DCPS (come un
Topic, Data Reader o Data Writer) può essere associato un insieme di policy di
QoS. DDS è caratterizzato da un matching tra le policy di QoS o↵erte e richieste
da determinate istanze: ad esempio, un Data Writer e un Data Reader possono
associarsi solo nel momento in cui le QoS o↵erte dall’uno rientrano nei requisiti
di QoS richiesti dall’altro.
Figura 2.1: Le policy di QoS di DDS.
2.1
Timeliness dei dati
Le seguenti policy forniscono un controllo sulle proprietà temporali dei dati, caratteristiche più che significative in System of Systems (SoS) perché, grazie ad
esse, è possibile controllare gli aspetti temporali degli scambi di dati tra sottosistemi, assicurando, allo stesso tempo, che la larghezza di banda sia gestita in
modo ottimale. In considerazione del loro di↵uso utilizzo anche in ambito IoT e
11
dei sistemi embedded, alle suddette policy sono dedicati maggiori approfondimenti, tra tutte quelle che comunque sono oggetto di osservazioni nel corso del lavoro.
Nello specifico, si fa riferimento alle implementazioni in OpenDDS. Sarebbe preferibile, per garantire una resa più efficiente di queste policy prettamente relative
all’aspetto temporale dei dati, l’utilizzo di OpenDDS su un sistema operativo
Real-Time.
2.1.1
DEADLINE
La policy di QoS DEADLINE permette alle applicazioni di definire un massimo
tempo di inter-arrivo per i dati e, in caso di impossibilità di rientrare in questo
intervallo, permette di attivare un meccanismo di notifica per le deadline mancate.
Dal punto di vista implementativo, la policy DEADLINE permette di valutare se i
dati non sono stati letti o scritti in un certo intervallo di tempo. In OpenDDS
questa policy può essere applicata ad un Topic, ad un Data Writer o ad un Data
Reader tramite il campo deadline delle loro rispettive strutture QoS. Di seguito
è riportato l’IDL relativo alla policy deadline:
s t r u c t DeadlineQosPolicy {
Duration t period ;
};
Il valore di default della variabile membro period è infinito, per cui non è richiesto
alcun comportamento. Settando invece i campi period.sec e period.nanosec
a valori finiti, il Data Writer (Data Reader) monitora i cambiamenti di dato effettuati dall’applicazione e, in caso di superamento della deadline, segnala la corrispondente condizione di stato, richiamando la callback on offered deadline missed()
(on requested deadline missed()). Come già accennato precedentemente, la
policy DEADLINE può essere o↵erta e richiesta, per tale motivo vi sono due callback richiamabili nell’ambito del Data Reader o del Data Writer. Specificamente
il valore di period del Data Writer (deadline o↵erta) deve essere minore o uguale
all valore relativo al Data Reader (deadline richiesta). L’interfaccia e l’utilizzo
delle callback sopra riportate sono esaminate nel capitolo successivo.
2.1.2
LATENCY BUDGET
La policy LATENCY BUDGET rappresenta un mezzo per comunicare a DDS l’urgenza
associata ai dati trasmessi. La LATENCY BUDGET indica il tempo entro il quale
DDS deve consegnare le informazioni; questo periodo comincia nel momento in
cui i dati sono scritti da un publisher, e termina nel momento in cui essi sono
disponibili nella cache dei subscriber.
Da un punto di vista implementativo, la policy LATENCY BUDGET può applicarsi a
Topic, Data Reader e Data Writer tramite la variabile latency budget presente
nelle strutture relative alle policy di QoS. Di seguito è riportato l’IDL relativo
alla policy:
s t r u c t LatencyBudgetQosPolicy {
Duration t period ;
};
12
Il valore di default del campo period è zero, il che vuol dire che il ritardo andrebbe minimizzato. Questa policy è considerata come un suggerimento al livello
di trasporto per indicare l’urgenza dei campioni inviati. OpenDDS utilizza il
valore per delineare un intervallo massimo di latenza oltre il quale il ritardo viene segnalato come inaccettabile. Questa policy viene utilizzata perlopiù ai fini
di monitoraggio, infatti, in caso di superamento del budget, viene richiamata la
callback on budget exceeded().
2.1.3
TRANSPORT PRIORITY
La policy TRANSPORT PRIORITY permette di specificare l’importanza associata ai
messaggi, permettendo a DDS di dare priorità a dati più importanti rispetto ad
altri.
In particolare la policy può essere applicata a Topic e a Data Writer, settando
il campo transport priority delle strutture relative alle QoS delle entità. Di
seguito è riportato l’IDL della policy:
struct TransportPriorityQosPolicy {
long value ;
};
La priorità è rappresentata dal campo value. Valori più grandi della variabile
rappresentano valori più alti di priorità in un intervallo compreso tra 1 e 63. Il
valore di default della variabile è 0. Questa policy rappresenta un suggerimento al
livello di trasporto sulla priorità con la quale andrebbero consegnati i messaggi,
il che si concretizza nell’impostazione da parte di OpenDDS delle priorità dei
thread finalizzati alla consegna e alla ricezione del messaggio e nell’impostazione
dei codepoint dei Di↵erentiated Services (Di↵Serv). Ovviamente, per permettere
il corretto funzionamento dei servizi sopra descritti, è necessario che lo scheduler
del sistema operativo implementi le priorità per i thread, ed è inoltre essenziale
che l’hardware di networking supporti i codepoint.
2.2
Disponibilità dei dati
Queste policy disaccoppiano le applicazioni dal punto di vista temporale e spaziale, permettendo di lavorare in ambienti estremamente dinamici caratterizzati da
continui cambiamenti di publisher/subscriber. Queste proprietà sono particolarmente rilevanti in SoS perché aiutano il disaccoppiamento dei vari componenti.
DURABILITY
La policy DURABILITY controlla il ciclo di vita dei dati scritti sul Global Data Space. Esistono 3 livelli di durata dei dati: VOLATILE fa sı̀ che, una volta pubblicato
un dato, esso non sia disponibile ai subscriber pervenuti dopo la pubblicazione;
TRANSIENT LOCAL consente di rendere i dati disponibili anche ai subscriber entrati a far parte del dominio successivamente; PERSISTENT permette la consegna dei
dati a tutti i subscriber anche in caso di spegnimento e riavvio dell’intero sistema.
13
LIFESPAN
La policy LIFESPAN controlla l’intervallo di validità di un determinato messaggio.
HISTORY
La policy HISTORY permette di controllare il numero di messaggi (scritti nell’ambito dello stesso Topic) da tenere in memoria per i Reader ed i Writer.
2.3
Consegna dei dati
Le policy elencate nel presente paragrafo costituiscono degli strumenti di controllo delle modalità di consegna dei dati (affidabilità e disponibilità); in pratica
consentono che i corretti dati siano recapitati al momento esatto e al giusto destinatario. In tal modo, grazie al profilo di content-awareness di DDS, è inoltre
possibile garantire una funzione di filtraggio, che permette alle applicazioni di
selezionare le informazioni di interesse basandosi sul loro contenuto. Questo tipo
di policy è peculiarmente utile in sistemi complessi, in cui un mancato filtraggio
dei messaggi potrebbe comportare grandi sprechi di risorse.
PRESENTATION
La policy PRESENTATION rende possibile il controllo della presentazione ai subscriber dei cambiamenti al modello delle informazioni e↵ettuati dai publisher.
Questa funzione permette di gestire l’ordine e la coerenza degli aggiornamenti
dei dati.
RELIABILITY
La policy RELIABILITY permette di controllare il livello di affidabilità associato
alla di↵usione dei dati (RELIABLE o BEST EFFORT).
PARTITION
La policy PARTITION permette la creazione di partizioni logiche nell’ambito di
un dominio. Questa possibilità fornisce un’astrazione che riesce a suddividere
efficientemente il traffico tra diverse partizioni, migliorando le prestazioni e la
scalabilità del sistema.
DESTINATION ORDER
La policy DESTINATION ORDER consente di modellare l’ordine con cui i messaggi
vengono resi disponibili ai subscriber, basandosi sui timestamp della sorgente o
della destinazione.
14
OWNERSHIP e OWNERSHIP STRENGHT
La policy OWNERSHIP controlla i Writer che detengono i permessi di scrittura ad
un Topic. Esistono due opzioni per la policy: SHARED e EXCLUSIVE. Nel caso
in cui i permessi di scrittura siano condivisi, diversi Writer possono aggiornare concorrentemente un Topic; se invece sono esclusivi, viene garantita la possibilità di scrittura solo al Writer che presenta il valore maggiore della policy
OWNERSHIP STRENGHT.
2.4
Risorse
Queste policy permettono di controllare le risorse locali e end-to-end, come la
memoria e la larghezza di banda. Queste caratteristiche possono rivelarsi cruciali
in sistemi eterogenei, in cui è necessario adattare specificamente la quantità di
risorse utilizzabili.
TIME BASED FILTER
La policy TIME BASED FILTER consente alle applicazioni di specificare ogni quanto
tempo un Data Reader è interessato ai cambiamenti di dato, esprimendo praticamente il massimo tasso al quale possono elaborare informazioni. I campioni
prodotti ad un ritmo maggiore non vengono consegnati. Questa policy permette
quindi di adattare la consegna di dati a dispositivi caratterizzati da banda di rete
o da capacità di elaborazione limitate.
RESOURCE LIMITS
A mezzo della policy RESOURCE LIMITS si ottiene controllo sulle risorse massime
disponibili per la memorizzazione delle istanze dei Topic, in modo da adattare la
consegna dei messaggi anche a dispositivi meno performanti.
2.5
Configurazione
Le seguenti policy garantiscono meccanismi per l’inizializzazione e la configurazione di applicazioni che utilizzano DDS. Tutti i dati settati nell’ambito seguenti
policy vengono distribuiti tramite Topic built-in.
USER DATA
La policy USER DATA permette di associare una sequenza di ottetti (8 bit) ai
Domain Participant, Data Reader e Data Writer; questa policy è spesso utilizzata
per la distribuzione di credenziali di sicurezza.
15
TOPIC DATA
La policy TOPIC DATA consente di associare una sequenza di ottetti ai Topic; frequentemente questa policy viene utilizzata per estendere i Topic con informazioni
addizionali o meta-informazioni, come type-code IDL o XML schema.
GROUP DATA
La policy GROUP DATA rende possibile l’associazione di una sequenza di ottetti
ai publisher e ai subscriber. La finalità tipica di questa informazione è l’attribuzione di un maggiore controllo alle applicazioni sulle corrispondenze delle
sottoscrizioni.
16
Capitolo 3
Applicazione dimostrativa basata
su OpenDDS
Di seguito vengono riportati la specifica ed i dettagli implementativi di un sistema
teorico formato da un controllore e una serie di sensori, realizzato tramite le API
di OpenDDS. Come già accennato precedentemente, questa applicazione è stata
utilizzata per dimostrare ed analizzare le policy di QoS di OpenDDS.
3.1
Sistema
La configurazione presa in esame è, più propriamente, una sottoparte di un classico sistema di controllo (fig. 3.1). I sensori hanno il compito di misurare l’uscita
dell’impianto (elemento non approfondito in questo lavoro) con una certa tolleranza e accuratezza; il controllore, invece, sulla base dei dati ricevuti dai sensori,
determina la logica di controllo. Si suppone che i componenti non si trovino
collegati fisicamente tra loro, ma che siano connessi in rete tramite l’utilizzo di
hardware apposito. A causa della necessità di una comunicazione tra processi
basata sui messaggi e su eventuali requisiti di temporizzazione, risulta più che
adatto l’utilizzo dello standard DDS (OpenDDS) per implementare un meccanismo di comunicazione tra il controllore e i diversi sensori. In particolare il
controllore è un publisher, e i sensori sono dei subscriber.
Figura 3.1: I processi comunicano tramite operazioni di publish/subscribe su
determinati Topic.
17
3.2
Strumenti utilizzati
L’implementazione del sistema descritto è realizzata utilizzando una macchina
virtuale creata tramite VMware Workstation Pro 12 con sistema operativo guest
Xubuntu 14.04.4 a 64 bit. Per i test a più computer è stata adoperata la stessa
macchina virtuale caricata anche su VMware Fusion 8; entrambe le macchine
accedono alla rete LAN tramite connessione bridged.
È utilizzata la versione 3.8 di OpenDDS, compilata direttamente su Linux.
3.3
3.3.1
Implementazione
Definizione del tipo di dato Message
Ogni tipo di dato elaborato da DDS è definito utilizzando Interface Definition
Language (IDL) (fig. 3.2), avvalendosi delle direttive #pragma per permettere a
OpenDDS di identificare i tipi di dato che DDS trasmette e gestisce. I tipi di dato
sono dunque processati dai compilatori IDL di TAO e di OpenDDS (fig. 3.3), al
fine di generare il codice necessario ad inviare e ricevere i suddetti tipi di dato
tramite DDS (fig. 3.4).
In questo caso è stato creato un tipo di dato Message contenente i seguenti campi:
• id: utilizzato per identificare univocamente le istanze nell’ambito dello
stesso Topic;
• value: contenente il valore della misurazione da inviare al controllore;
• timestamp: adoperato per e↵ettuare misurazioni temporali, come dettagliato nel prossimo capitolo.
Figura 3.2: Definizione dell’interfaccia IDL per il tipo di dato Message.
18
Figura 3.3: Comandi necessari alla compilazione dell’interfaccia IDL.
Figura 3.4: Output della compilazione IDL.
3.3.2
Implementazione Publisher e Subscriber
La realizzazione del codice inerente al controllore e ai sensori utilizza come scheletro di partenza l’esempio Messenger, fornito di default dagli sviluppatori di
OpenDDS. In particolare sono state e↵ettuate le seguenti modifiche al codice:
• Sia i publisher (sensori) che il subscriber (controllore) stampano a video
i dati inviati/ricevuti, per una corretta verifica del funzionamento della
comunicazione;
• È stato implementato il passaggio della priorità tramite argomento ricevuto
da linea di comando, in modo da impostare in seguito la policy TRANSPORT PRIORITY
(fig. 3.5);
• È stato previsto l’invio di valori random in un range tra 1 e 100 da parte
dei sensori come misurazioni di esempio.
19
Figura 3.5: La priorità viene indotta dall’argomento ricevuto dal terminale,
dopodiché vengono impostati i campi relativi alle policy di QoS.
3.3.3
Immissione policy di QoS
Per dimostrare il funzionamento delle policy di QoS di OpenDDS sono stati associati dei determinati valori alle strutture corrispondenti delle entità Data Reader
e Data Writer. In particolare, una volta ottenuta la struttura contenente i valori
di default delle policy di QoS, sono stati modificati i campi relativi alla timeliness
(fig. 3.5). È necessario ricordare che le policy devono essere impostate coerentemente tra Data Reader e Data Writer per garantire la corrispondenza tra QoS
o↵erte e richieste.
3.3.4
Configurazione listener del Data Reader
In OpenDDS ogni entità del layer DCPS possiede un’interfaccia listener basata
sui cambiamenti di determinate variabili di stato. Ad esempio, nel caso di un
Data Reader, lo stato DATA ON READERS segnala la presenza di nuovi dati ricevuti,
richiamando la funzione on data available() (fig. 3.6). Le interfacce listener
contengono numerose funzioni relative ai cambiamenti di stato inerenti alle policy
di QoS; tra queste si cita la funzione on requested deadline missed(), che
viene attivata ogniqualvolta non si è ricevuto alcun messaggio entro la deadline
specificata.
20
Figura 3.6: La funzione on data available() viene richiamata ogni qualvolta
sono disponibili nuovi dati al Data Reader.
21
Capitolo 4
Analisi sperimentale delle policy
di timeliness di OpenDDS
4.1
Policy di QoS utilizzate
Tramite la predisposizione di alcune policy di QoS sull’implementazione controlloresensori riportata precedentemente, è possibile analizzare diversi dati sperimentali
degni di nota. In particolare, si è focalizzata l’attenzione sulle policy di QoS atte
al controllo della timeliness dei dati distribuiti come DEADLINE, LATENCY BUDGET
e TRANSPORT PRIORITY.
4.2
Caso 1: Calcolo empirico dei tempi di consegna di OpenDDS
Come primo caso si valutano i tempi richiesti da OpenDDS per la consegna di
un generico messaggio. Il test è e↵ettuato in due modalità: nella prima un controllore (subscriber) e un sensore (publisher) sono avviati sulla stessa macchina,
mentre nella seconda vengono eseguiti su macchine diverse.
Il calcolo della latenza da parte del controllore avviene tramite la sottrazione tra un timestamp ottenuto dalla funzione standard C++ clock gettime e
un timestamp (figura 4.2) inviato come campo del messaggio da parte del sensore (figura 4.1). Nel caso di controllore e sensore in esecuzione sulla stessa
macchina si confrontano i risultati ottenuti con i dati forniti dalla funzionalità LatencyStatistics, inclusa di default in OpenDDS come parte della policy
LATENCY BUDGET.
4.2.1
Controllore e sensore sulla stessa macchina
Sullo stesso sistema vengono avviati un processo controllore e un processo sensore, simultaneamente al processo DCPSInfoRepo che si occupa della registrazione
dei publisher e dei subscriber. Sono dunque inviati dal sensore un determinato
numero di messaggi, e, alla fine dell’esecuzione (fig. 4.3), il controllore e↵ettua il
calcolo della latenza media di consegna degli stessi messaggi. E↵ettuando il test
22
Figura 4.1: Snippet di codice del sensore che mostra l’invio del messaggio
contenente il timestamp.
trasmettendo 10, 20, 30, 100, 200, 300, 600 e 1000 messaggi è possibile notare
(fig. 4.4) come, all’aumentare dei messaggi scambiati, ci sia una leggera variazione
della latenza media di consegna, probabilmente dovuta al maggiore accodamento
di dati. Per limitare tale problema è quindi inserita un’attesa di 0,5 secondi tra
l’invio di un messaggio e l’altro tramite la funzione usleep(500000); infatti, senza questo accorgimento, le latenze aumenterebbero esponenzialmente al crescere
del numero di messaggi inviati. È da sottolineare (fig. 4.4) che la misurazione e↵ettuata tramite sottrazione di timestamp non si discosta particolarmente
da quella ottenuta tramite LatencyStatistics ed, e↵ettuando una media tra le
varie misurazioni, si ottiene una latenza di 570,78 microsecondi.
4.2.2
Controllore e sensore su macchine diverse
Su due dispositivi diversi, con identico hardware virtuale e sistema operativo,
vengono avviati un processo sensore ed un processo controllore; dopodiché il
test è e↵ettuato identicamente al precedente. Prima di analizzare i risultati,
bisogna notare che, in questo caso, diversi fattori aleatori possono incidere sulla
veridicità del test. I ritardi (non dovuti a OpenDDS) causati dal trasferimento dei
pacchetti in rete e l’imprecisione della valutazione della latenza tramite di↵erenza
di timestamp sono solo una parte dei fattori che possono causare incertezza.
In ogni caso, tramite la sincronizzazione dei timer con Network Time Protocol
(NTP), è possibile ottenere una stima approssimativa della latenza tra le due
macchine, che, com’era prevedibile, risulta essere sensibilmente superiore a quella
e↵ettuata su un solo dispositivo (fig. 4.5). La media tra le varie misurazioni è di
19048 microsecondi.
23
Figura 4.2: Snippet di codice del controllore che mostra la ricezione del timestamp
e il calcolo della latenza.
4.3
Caso 2: Test di utilizzo della policy DEADLINE
La policy DEADLINE, come descritto precedentemente, permette di rilevare quando i dati non vengono scritti o letti nell’arco di un certo intervallo di tempo.
Pertanto, potrebbe essere impiegata nell’ambito del sistema controllore-sensori,
dove è richiesta da parte del controllore una determinata frequenza di ricezione
delle misurazioni, in modo da evitare problemi causati dalla presenza di ritardi.
Bisogna precisare che, nel caso preso in esame di un sistema time-sharing, non
è possibile garantire una frequenza prefissata di invio dei messaggi, per la quale
sarebbe richiesto un sistema operativo Real-Time. Nonostante ciò, si riescono
ad ottenere ugualmente risultati soddisfacenti, come riportato di seguito. Ad
esempio, provando ad inviare 30 messaggi intervallati da una usleep(1) (attesa
di un microsecondo), si può verificare la possibilità di rispettare una deadline di
un microsecondo. In questa particolare esecuzione (fig. 4.6) ci sono ben 2032
deadline miss, il che significa che, dati i tempi di consegna medi ricavati, non è
possibile garantire o richiedere una deadline cosı̀ stringente, come del resto era
immaginabile. In particolare, analizzando i precedenti dati, si deduce che, nel
tempo in cui sono stati inviati e consegnati i 30 messaggi di test, il controllore
ne avrebbe attesi ulteriori 2032. Al contrario, settando una deadline di 5000
microsecondi, non viene riscontrata alcuna deadline miss (fig. 4.7).
4.4
Caso 3: Verifica prestazioni in presenza di
TRANSPORT PRIORITY
Come descritto nei capitoli precedenti, la policy TRANSPORT PRIORITY permette
di modificare il livello di priorità con il quale devono essere consegnati i mes24
Figura 4.3: Calcolo latenza da parte del controller a fine esecuzione.
saggi. Con il prossimo test si vuole verificare il funzionamento di questa policy
ottenendo la stampa a video dei messaggi ricevuti dal controllore (subscriber),
unitamente alle priorità dei tre sensori (publisher) sotto forma di misurazione
acquisita (ed inviata). Le priorità dei tre sensori sono impostate a 10, 20 e 30
tramite il campo value della policy, e viene previsto che i sensori inizino ad
inviare messaggi nello stesso momento. L’osservazione dei tempi medi di consegna (fig. 4.8) dei messaggi provenienti dai tre sensori (campo mean della struttura
LatencyStatistics) permette di a↵ermare che i messaggi del primo sensore vengono e↵ettivamente consegnati alla minima latenza, quelli del secondo a latenza
leggermente superiore, mentre quelli del terzo alla massima latenza.
25
7,5⋅105
Latenza in ns
5⋅10
5
2,5⋅105
Num messaggi
0
100
200
300
400
500
600
700
800
900
1000
1100
Figura 4.4: Grafico rappresentante sull’asse delle ascisse il numero di messaggi
inviati dal sensore al controllore e sull’asse delle ordinate la latenza in nanosecondi. In rosso sono riportati i risultati di LatencyStatistics e in blu i risultati
ottenuti dall’elaborazione dei timestamp.
3,5⋅107
3⋅107
Latenza in ns
2,5⋅107
2⋅107
1,5⋅107
1⋅107
Num messaggi
5⋅106
0
100
200
300
400
500
600
700
800
900
1000
1100
Figura 4.5: Grafico relativo alla latenza tra due macchine diverse. In arancio
sono riportati i risultati di LatencyStatistics e in ciano i risultati ottenuti
dall’elaborazione dei timestamp.
26
Figura 4.6: Numero di deadline miss dato l’invio di 30 messaggi intervallati da
usleep(1) e con deadline di un microsecondo.
Figura 4.7: Numero di deadline miss dato l’invio di 30 messaggi intervallati da
usleep(1) e con deadline di 5000 microsecondi.
27
Figura 4.8: Tramite le LatencyStatistics è possibile notare come i messaggi
vengano consegnati con le giuste priorità.
28
Capitolo 5
Conclusioni
A partire dalla disamina delle specifiche di DDS e↵ettuata, è possibile constatare
come lo standard rappresenti la tecnologia ideale per l’implementazione di SoS,
soprattutto grazie alle sue seguenti caratteristiche:
• Interoperabilità e portabilità,
• Accoppiamento lasco,
• Estensibilità,
• Scalabilità, efficienza e timeliness.
Sulla base dell’applicazione dimostrativa riportata si può inoltre assodare la grande semplicità di utilizzo delle API o↵erte da OpenDDS; non è stata infatti necessaria alcuna modifica dei parametri relativi alla comunicazione su rete, al
marshalling-unmarshalling dei dati o ad altri aspetti gestiti autonomamente dal
middleware.
Grazie alle verifiche e↵ettuate, sono stati ottenuti dei dati sperimentali che possono fornire, con la dovuta cautela, una visione d’insieme sulle prestazioni di
OpenDDS. Infatti le varie misurazioni, sebbene e↵ettuate in maniera sistematica, presentano un certo grado di alea causata, come riportato precedentemente,
da alcune fonti di incertezza presenti nel sistema esaminato.
29
Sitografia
[1] The Data Distribution Service, Angelo Corsaro, Douglas C. Schmidt https:
//www.dre.vanderbilt.edu/~schmidt/PDF/dds-sos.pdf [09/08/2016]
[2] An Introduction to DDS and Data-Centric Communications, Gerardo
Pardo-Castellote, Bert Farabaugh, Rick Warren http://www.omg.org/
news/whitepapers/Intro_To_DDS.pdf [09/08/2016]
[3] DDS Enabling Global Data,
Gerardo Pardo-Castellote, Gordon
A. Hunt. https://www.rti.com/docs/DDS_Enabling_Global_Data.pdf
[09/08/2016]
[4] About OpenDDS, http://opendds.org/about/ [09/08/2016]
[5] Data-Centric Middleware,
https://www.rti.com/docs/RTI_Data_
Centric_Middleware.pdf [09/08/2016]
[6] OpenDDS Developer’s Guide, http://download.ociweb.com/OpenDDS/
OpenDDS-latest.pdf [09/08/2016]
[7] The DDS QoS Model, http://download.prismtech.com/docs/Vortex/
html/ospl/DDSTutorial/qos.html [09/08/2016]
[8] The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire
Protocol Specification, http://www.omg.org/spec/DDSI-RTPS/2.2/PDF/
[09/08/2016]
[9] What is DDS?,
[09/08/2016]
http://portals.omg.org/dds/what-is-dds-3/
30