E-CABIN - Progettazione del middleware di comunicazione per la raccolta dati e del sistema di backend

In questo documento sono illustrati i risultati dell'attività di progettazione della piattaforma di raccolta dati, che sarà sviluppata per e-Cabin, insieme al sistema di back-end su cui saranno in esecuzione tutti i servizi di supporto a tale architettura. Nel capitolo 1 sono introdotti i modelli di comunicazione e raccolta dati in ambienti distribuiti per la gestione di grandi quantitaÌEUR di informazioni. La necessitaÌEUR di avere un middleware che permetta di interfacciarsi con il sistema e-Cabin da più dispositivi di natura diversa e da più ambienti di esecuzione implica una scelta architetturale che garantisca flessibilitaÌEUR ed estendibilità. L'approccio scelto consiste nell'avere un'entità dispatcher che gestisce le comunicazioni tra nodi mittenti e destinatari mediante il paradigma publisher/subscriber. Per quanto riguarda la raccolta dei dati, è importante definire prima della fase implementativa le caratteristiche delle informazioni trattate, quali: frequenza e dimensione dei dati, tipo di analisi (real-time o batch), metodo di elaborazione, formato dei contenuti, sorgenti e consumatori di dati, hardware che si intende utilizzare. Viene infine presentato lo schema panoramico dell'infrastruttura di e- Cabin in cui sono mostrati i nodi principali (gateway per le reti di sensori, dispositivi mobili personali e server di back-end), i moduli che, a grandi linee, saranno installati su di essi e i relativi canali di comunicazione. Nel capitolo 2 sono presentate le tecnologie che saranno utilizzate per lo sviluppo della piattaforma di comunicazione. Fra i tre più rilevanti modelli di comunicazione per ambienti distribuiti, quali Remote Procedure Call (RPC), Remote Object Invocation (ROI) e Message Oriented Middleware (MOM), quest'ultimo è quello che meglio si adatta ad ambienti in cui eÌEUR richiesta flessibilitaÌEUR, asincronicità, resilienza e performance. Le tecnologie che saranno adottate per lo sviluppo del middleware saranno pertanto guidate dal modello MOM. Il protocollo MQTT (Message Queue Telemetry Transport), ampiamente diffuso nell'ambito delle comunicazioni Machine-to-Machine, sarà utilizzato per la distribuzione dei dati nel layer sottostante il middleware. MQTT è basato sul paradigma publish/subscribe, garantendo alte prestazioni e flessibilità. COAP (COnstrained Application Protocol) saraÌEUR invece utilizzato per integrare nel middleware di comunicazione sensori che utilizzano un stack protocollare IPv6 e che usano il modello REST per rappresentare le risorse interne. Come spiegato in seguito, COAP puoÌEUR essere considerata una versione leggera del protocollo di trasferimento web HTTP, specificatamente progettato per adattarsi alle esigenze di dispositivi con risorse limitate in termini computazionali ed energetiche. Il framework su cui saranno sviluppati i moduli del middleware eÌEUR OSGi (in particolare l'implementazione Apache Felix), un'ambiente di esecuzione modulare per la piattaforma Java. Questo permette di sviluppare moduli autonomi chiamati bundle, che possono comunicare tramite interfacce ben definite denominate service. Al tempo d'esecuzione, i bundle possono essere installati, avviati, fermati, aggiornati e rimossi senza dover riavviare l'intero framework OSGi. L'utilizzo di questa piattaforma comporta ridotta complessitaÌEUR, riutilizzo dei componenti, dinamicitaÌEUR, supporto al versioning, ottimizzazione delle prestazioni e gestione della sicurezza a grana fine. Infine, eÌEUR stata studiata la possibilitaÌEUR di integrazione del componente TCP bridge per l'Event Bus di Vert.x. Questo per un duplice scopo: i) fornire la connettività al middleware anche ai dispositivi mobili (IP- based) che non possono sfruttare la piattaforma OSGi e ii) offrire un punto di connessione con il precedente progetto myCabin di FC, allo scopo di predisporre l'eventuale integrazione fra i due sistemi. Questo componente consentirà al middleware di fungere da "bridge" fra gli ambienti e-Cabin e myCabin. Nel capitolo 3 (Specifiche generali della piattaforma di raccolta dati e del sistema di back-end) sono definite le caratteristiche dei livelli di astrazione per utilizzare il middleware proposto nel WP3. Nella prima parte del capitolo si definiscono quali sono gli attori in gioco che devono essere considerati nell'ambito del progetto e-Cabin: Persona, Cabina, Dispositivo e Decisore sono le classi principali di attori considerate in questo progetto. All'attore Persona sono associati determinati attributi che sono finalizzati a definire sia le sue caratteristiche soggettive che le attività, o azioni, che può svolgere all'interno dell'ambiente cabina. L'attore Cabina rappresenta l'ambiente che sarà caratterizzato da certe dimensioni, che sono riferibili a una certa categoria, e da un certo tipo di dotazioni, quali la presenza di finestra o balcone e il numero di posti letto. Nelle cabine sarà presente un determinato numero di dispositivi classificabili nella categoria di attori Dispositivo e i sistemi di regolazione, o sistemi di comando DSS, definiti come attore Decisore. Viene inoltre presentato il modello di analisi del sistema creato tramite un diagramma delle classi secondo un linguaggio di tipo UML (Unified Modeling Language). L'obiettivo è fornire informazioni dettagliate riguardo le proprietà e le interazioni delle classi. Inoltre, sono definite le specifiche funzionali di comunicazione di e-Cabin. In particolare, definiamo il formalismo di comunicazione per i sensori ambientali di comfort, i sensori relativi al consumo energetico, gli attuatori ambientali di comfort, gli attuatori relativi al consumo energetico, i sensori fisiologici, la knowledge base, il modulo di reasoning, la APP e-Cabin. Infine, sono definiti i casi d'uso con cui gli attori interagiscono con la piattaforma di raccolta dati (sensori, attuatori e applicazioni) e i requisiti funzionali e non funzionali della stessa. Nel capitolo 4 sono definite le interfacce di comunicazione dei componenti del middleware e le modalitaÌEUR di interfacciamento con i client tramite diagrammi delle classi e diagrammi di sequenza in formato UML. E' definita anche la modalità con cui i messaggi circolano sul bus MQTT sottostante ed il loro formato (JSON). E' inoltre descritta l'interfaccia per fornire la connettività ai dispositivi mobili tramite il bridge IP-based che permette a tutti i dispositivi che non possono sfruttare la piattaforma OSGi di usufruire pienamente di tutte le funzionalità del middleware tramite connessione TCP. Sono poi definiti i meccanismi che garantiranno la sicurezza delle comunicazioni fra i dispositivi presenti in cabina e il server tramite: i) connessione SSL/TLS a mutua autenticazione e ii) restrizioni sui canali disponibili alle istanze del middleware di una cabina per evitare accessi fra cabine diverse. Infine è discussa l'organizzazione dei moduli presenti sul back-end: broker MQTT, ambiente OSGi e database storico (MongoDB). Il capitolo 5 illustra lo scenario predisposto per l'integrazione fra e-Cabin e il precedente progetto myCabin di FC. Viene presentato un diagramma semplificato dell'architettura di myCabin, desunto dai pochi documenti a nostra disposizione, e proposto di seguito uno schema che mostra i componenti necessari all'interfacciamento con e-Cabin. In particolare: i) un'interfaccia verso l'Event Bus di myCabin che permetta al middleware di eCabin di inviare/ricevere messaggi su esso e ii) un modulo con logiche ad alto livello che permetta le interazioni fra le entitaÌEUR presenti nei due ambienti. Le entità di myCabin ricavate dalla documentazione sono: Cabina (ospite, luce, temperatura, ecc.), Servizi (concierge, acquisti, ristorazione) e Attività (servizi in cabina). L'utilizzo di MongoDB come database per entrambi i sistemi rappresenta una soluzione vantaggiosa che permette di unire lo storico generato nei due ambienti (in modo piuÌEUR o meno profondo, in base ai dettagli che saranno forniti riguardo le specifiche dei dati circolanti in myCabin).