Sensor Node Plugin System

Middleware per reti di sensoriTecnologie

SNPS: Middleware OSGI per reti di sensoriConclusioni

Progettazione e sviluppo di un Middleware OSGIorientato ai servizi per reti di sensori

Francesco Pantano

Università degli studi di Catania

Facoltà di Ingegneria

25 Giugno 2013

Francesco Pantano Middleware OSGI per reti di sensori



Outline

1 Middleware per reti di sensoriIl problema affrontatoSoluzione

2 TecnologieIl framework OSGIVantaggi

3 SNPS: Middleware OSGI per reti di sensoriArchitetturaComponenti di baseEvent Admin ServiceCasi d’uso

4 Conclusioni




Il problema affrontatoSoluzione

Outline




4 Conclusioni





Problematiche affrontate





Outline




4 Conclusioni





Soluzione

Una piattaforma per:

Presentare un sensore sottoforma di servizioMonitorare e processare datiprovenienti dalla WSNEsporre servizi di discovery /inquiry alla SNS Platform

RequisitoInstallazione e rimozione di moduli a Runtime




Il framework OSGIVantaggi

Outline




4 Conclusioni





Il framework OSGI

Un sistema dinamico, che consente l’installazione, l’avvio, lo stope la rimozione dei moduli a runtime, senza, quindi, necessitare diriavvii;Orientato ai servizi, i quali possono essere dinamicamenteregistrati ed utilizzati.

Un software modulare e dinamico porta a molti vantaggi in ogni fasedel suo sviluppo, dalla progettazione alla realizzazione, fino alla suamanutenzione.





Outline




4 Conclusioni





Il framework OSGI

Vantaggi

InteroperabilitàCooperazione tra icomponentiCondivisione deiserviziBasso consumo dirisorse

Fornisce le specifiche per sviluppare applicazioni che implementanoservizi, permettendo di registrarne di nuovi, di aggiornare o rimuoveregli esistenti "on the fly", sfruttando piccoli componenti, detti Bundle.




ArchitetturaComponenti di baseEvent Admin ServiceCasi d’uso

Outline




4 Conclusioni





SNPS: Architettura

Il Middleware è visto come un insieme di componenti che poggianosul framework OSGI. Ogni componente, configurato in un bundleOSGI, svolge un ruolo ben preciso e interagisce, sia localmente cheda remoto, con altri bundle.

Strati del Middleware:

Sensor Integration InterfaceCore e componenti associatiWeb Integration Interface





Outline




4 Conclusioni





Sensor Integration Interface

L’integrazione con la WSN è realizzata attraverso due bundle OSGIche implementano un Gateway, su cui avviene lo scambio deicomandi.

Basato su R-OSGI, prevede la creazione di un endpoint unico, cherende trasparente il message passing tra il middleware e le BS dellaWSN.

Non serve conoscere latopologia/architettura dellaWSN





Sensor Integration Interface

Componenti:iMdwBundle : Interfacciaverso la WSN al fine digarantire un canale per lostream di comandi da everso il MiddlewareiWsnBundle: Interfacciaverso il Middleware al fine digarantire un canale per lostream di dati (modalità push)

La conoscenza dei servizi è resa possibile attraverso la condivisionedelle interfacce, che definiscono i metodi implementati.





Core e componenti associatiLo strato di logica

Si occupa di "svegliare" i componenti che possono soddisfare unacerta richiesta verso il Middleware, invocando gli appropriati servizi.

Funzionalità:

Orchestrazione deicomponenti del middlewareGestione delle immaginisoftware relative ai sensori,condivise tra i bundles delmiddleware





Core e componenti associatiRegistry Bundle e lo strato di persistenza

Funzionalità:

Registrazione e rimozione diun sensoreRecupero (parametrico) di unsensoreAggiornamento delladescrizione dei sensorirelativi ad una Base StationAggiornamento delladescrizione un sensore





Core e componenti associatiRegistry Bundle e lo strato di persistenza

Le immagini dei sensori recuperatedal registry permettono di:

Ignorare la topologia dello stratosottostanteEvitare problematiche diindirizzamento delle queryTrattare facilmente i componentidella WSN, attraverso le immaginisoftware





SensorML: Descrizione di un Sensore

In evidenza le parti principali di una descrizione in formato SensorMLper un sensore di temperatura





SensorML: Descrizione di un SensoreIdentification parameters

In questo frammento di SML sievince:

informazione relativa alposizionamento logico delsensoreinformazione relativa alla basestation a cui il sensore fariferimento





SensorML: Descrizione di un SensoreCapabilities parameters





SensorML: Descrizione di un SensoreInput parameters

Questo frammeto di SensorML descrive la parte riguardante lacatena di Input di un sensore di temperatura

Phenomenon: descrizione del fenomeno misurato dal sensoreUOM: unità di misura prevista dalle rilevazioni





SensorML: Descrizione di un SensoreOutput parameters

Questo frammeto di SensorML descrive la parte riguardante lacatena di Output di un sensore di temperatura

Phenomenon: natura del fenomeno misurato dal sensoreUOM: unità di misura prevista in output dalle rilevazioni





Core e componenti associatiGestione dei flussi di dati

Nasce dall’esigenza di avere una separazione logica tra:Comandi da e verso il middlewareFlusso di dati all’atto di una misurazione

Modalità:

Servizio push, per accumulare datiprovenienti dai sensoriProcessor, per applicare particolaristrutture ai dati ricevuti





Core e componenti associatiComposizione di sensori

Un sensore virtuale rappresenta un’entità software che va a mapparsisu un insieme di sensori fisici, residenti anche su BS differenti

Si ha visibilità di un unico sensoreUna richiesta di rilevazionesensoriale si traduce nell’invocazionedi tante richieste di lettura quantisono i sensori che lo compongonoÈ necessario processareopportunamente le singolerilevazioni





Core e componenti associatiComposizione di sensori

L’obiettivo è permettere di ottenere misure complesse a partire dairilevamenti dei singoli sensori

Disporre di un operatore chepermetta di combinare fra lorole misure, secondo appositicriteri di compatibilità

Operatore: Struttura datiparametrica per ilprocessamento di un insiemedi dati





Web Integration InterfaceApplication Layer

L’obiettivo è offrire, ai livelli superiori, interfacce per accedere aiservizi offerti dal Middleware.

Sensors as a Service:

Query dirette alla WSNsottostante, per accedere alledescrizioni dei componenti ealle misure effettuateComandi che possano agiresul comportamento deisensori della WSNServizio di composizione





Web Integration InterfaceTecnologie di riferimento

Web Services:permettono l’interoperabilità tradiverse applicazioni software sudiverse piattaforme hardwaredisaccoppiamento tra il Middleware elo strato immediatamente superiore

Wrapper Bundle:astrae ed esporta i servizi messi adisposizione dal middleware

Qualsiasi Web Client potrà invocare i servizi offerti dallo stratosottostante, evitando problematiche legate alle tecnologie





Web Integration InterfaceServizi esposti

Interrogazione di un sensore: permette di effettuareun’interrogazione sul sensore, restituendo la misuraInterrogazione Registry: permette di effettuare una ricerca diun sensore o delle rilevazioni sensoriali secondo appositi filtrispecificati come argomentoComposizione: generazione di un sensore virtuale; invocatotale servizio, verrà restituito l’identificativo del sensore creatoCreazione di un piano di campionamento: permette di inviareun piano di campionamento ad uno o più sensoriInvio di un comando ai sensori: abilitazione / disabilitazionedel sensore (modalità risparmio energetico)





Outline




4 Conclusioni





Snps: una piattaforma guidata dagli eventi

Duplice Modalità di funzionamento:Sincrona: richieste che sipropagano fino alla wsn, per poitornare in cascata una ResponseAsincrona: Response inerenti aduna certa Request notificate tramiteun meccanismo Publish/Subscribe

I bundle iscritti su un certo topic d’interesse, ricevono le notifichelegate a quella categoriaI topic (o Event Stream), rappresentano una categoria diinformazioni, legata o meno a specifici bundles





Snps: una piattaforma guidata dagli eventiEntità coinvolte

Event Producer: componente ingrado di generare eventiEvent Consumer: componente ingrado di ricevere notifiche eprocessare eventiEvent Stream: Topic a cui l’eventofa riferimento in funzione della suanatura intrinseca

OSGi Event Admin Service Specification che ben si adatta anche asistemi nei quali devono essere notificati degli eventi a grana fine adun numero elevato di handler diversi.





Snps: una piattaforma guidata dagli eventiOSGi Event Admin Service Specification

Interfacce di base:Event Class: Modella l’evento, uncontainer per informazioni specificheEvent Admin: interfaccia chepermette di implementare unpublisherEvent Handler: interfaccia chemodella un meccanismo diintercettazione degli eventi su untopic d’interesse





Esempio pratico: lettura di un dato da un sensoreSottoscrizione dei componenti

Subscription Phase: attivazione dell’Event handler per intercettare idati che transitano all’interno della piattaforma





Esempio pratico: lettura di un dato da un sensoreInterrogazione del sensore fisico





Outline




4 Conclusioni





Scenari principali sviluppati

Per avere un riscontro pratico, in accordo ai requisiti previsti(funzionali e non), è stata realizzata un’opportuna batteria di test.

Sensor_cu_1: Registrazione di un sensore all’interno dellapiattaformaSensor_cu_2: Settaggio di un piano di campionamentoSensor_cu_3_4: Invio di un comando (enable / disable) ad unsensoreSensor_cu_5: Creazione di un sensore virtualeSensor_cu_6: Interrogazione di un sensore virtuale(precedentemente creato)





Scenari principali sviluppatiSensor_cu_1: Registrazione di un Sensore





Scenari principali sviluppatiSensor_cu_2: Settaggio di un piano di campionamento





Scenari principali sviluppatiSensor_cu_3_4: Invio di un comando ad un sensore





Scenari principali sviluppatiSensor_cu_5: Generazione di un sensore virtuale





Scenari principali sviluppatiSensor_cu_6: Interrogazione di un sensore virtuale




Conclusioni

Modularità: Rappresenta una scatola chiusa, eventualmenteespandibile tramite ulteriori moduli (bundles)Flessibilità: Grazie ad una modellazione delle strutture dati informato JSON, si ha piena compatibilità per dialogare conapplicazioni esterneCooperazione: nell’ottica di una tecnologia a servizi, icomponenti cooperano e condividono in accordo alla logica diarchitetture SOABasso consumo di risorse: Esportazione di un environmentOSGi stand alone in grado di operare anche su macchine concapacità limitata


Sensor Node Plugin System

Technology

Transcript of Sensor Node Plugin System