Abbiamo parlato di AgileIoT e di come le soluzioni IoT sono oggetto di sfide apparenti a domini differenti che devono trovare il modo di dialogare tra loro, aspetto alla base della stessa filosofia di AgileIoT.
Spesso però la nuova soluzione incontra una necessità che nasce con il suo stesso concepimento e che, nell’AgileIoT Framework, trova la collocazione nella fase di prototyping come Vision e si concretizza nella necessità di comunicare adeguatamente l’idea ad una Product Management Board (sia gestionale che tecnica). Bisogna riuscire a descrivere adeguatamente e sinteticamente il tutto, evidenziando gli aspetti rilevanti al fine di ottenere l’approvazione a procedere con la cerimonia di fast-prototyping per la valutazione della sostenibilità e dei rischi. È importante sottolineare che la cerimonia di fast-prototyping ha un costo ed è quindi naturale che il management, prima di autorizzarla, voglia quanto meno avere un’idea di quello di cui si sta parlando.
Per raggiungere tale obiettivo, tipicamente si ricorrere ad uno Statement of Work (SOW), ovvero un documento che mette in evidenza gli aspetti principali del progetto, dalle attività, ai deliverable fino alla timeline.
Il nostro contesto è però maggiormente Agile, e in accordo con il terzo principio di AgileIoT: “Think less and do it!”, proviamo a creare un documento tipo (si, avete capito bene: un documento! Esistono e servono anche in Agile!) che sia ridotto all’essenziale ma che comunque permetta di comunicare la nostra idea con una overview sufficiente ad inquadrare il contesto di business e l’Intentional Architecture di riferimento.
Il nostro documento, che chiameremo Product Vision Inception (PVI), sarà così strutturato:
- Scopo del documento;
- Business Epic;
- Piattaforme e Tecnologie abilitanti;
- Intentional Architecture;
- Conclusioni.
In questo approfondimento andremo a vedere un possibile esempio di PVI, senza la pretesa di creare un modello di riferimento, ma raccontando una possibile soluzione basata su un approccio Microservices realizzati sfruttando le soluzioni PaaS di Azure.
Scopo
Scopo del Product Vision Inception (PVI) è quello di presentare gli aspetti salienti del nuovo prodotto, valutando il suo allineamento con gli obiettivi di business e i relativi aspetti architetturali di riferimento, al fine di ottenere un’approvazione della perseguibilità dell’iniziativa di business e procedere con la successiva validazione della sostenibilità tramite la cerimonia di fast-prototyping.
Business Epic
La nostra iniziativa di business è orientata al mondo sanitario, in particolare è pensata per monitorare lo stato di post-degenza di un paziente e segnalare eventuali situazioni anomale. Dopo la degenza ospedaliera, lo stato dei pazienti viene costantemente monitorato attraverso dei braccialetti che inviano dati biomedici alla piattaforma in modo da arricchire la propria Cartella Clinica Digitale (PHR, Personal Health Record) e consentire agli operatori di intervenire prontamente in caso di problemi o anomalie consistenti nei dati rilevati.
Si tratta di un tema estremamente caldo, che punta a migliorare i livelli assistenziali e ridurre i tempi di degenza e i relativi costi annessi.
Il nome provvisorio del sistema è Seguimi.
Piattaforme e Tecnologie abilitanti
Come da definizione, una piattaforma IoT ha di base due elementi portanti: Internet (Cloud) e lo Smart Thing. Essendo la realizzazione guidata dall’approccio Make-Measure-Learn, così come consigliato da AgileIoT per realizzare una serie incrementale di Minimum Viable Product (MVP), si è proceduto ad un’analisi delle soluzioni disponibili sul mercato che maggiormente si allineano a questa esigenza.
La “I” dell’IoT: il Cloud
Se si vogliono sfruttare a pieno le potenzialità dell’Internet of Things, è necessario porre l’accento su due funzioni chiave:
- capacità di gestire l’enorme quantità di dati provenienti dai dispositivi e dalle applicazioni;
- capacità di attivare azioni in risposta ai dati ottenuti ed elaborati.
In pratica è fondamentale poter gestire in modo efficiente il flusso dei dati, sottoponendolo a query simil-realtime che permettono di prendere velocemente informazioni, sia interne (come lo storage degli stessi) sia esterne (come l’attivazione di azioni di risposta).
Le infrastrutture on-premise abilitanti richieste per assolvere a tali funzionalità hanno ancora oggi un costo proibitivo per la maggior parte delle aziende, obbligando a rivolgersi a soluzioni PaaS (Platform as a Service) e IaaS (Infrastructure as a Service) tra cui spiccano le soluzioni Microsoft basate su Azure, in primis con Event Hub e Stream Analytics.
EVENT HUBS E STREAM ANALYTICS
Gli Event Hub sono parte della piattaforma Azure Service Bus e fungono da punto di ingresso di milioni di messaggi al secondo. Streaming Analytics è posizionato logicamente a valle degli Event Hub e consente di eseguire analisi ed elaborazioni al volo sui dati raccolti.
Gli Event Hub seguono il classico pattern publish-subscribe in cui i mittenti dei messaggi (publisher) non comunicano direttamente con i destinatari, ma tramite un intermediario, un hub, da cui il destinatario finale (subscriber), a sua volta, recupera il messaggio. Si tratta di un modello asincrono particolarmente indicato per il contesto IoT dove i dispositivi possono essere disconnessi o disponibili a tratti.
I dati possono restare nella coda (hub) per un periodo definito, abilitando ad un’analisi realtime grazie alla possibilità di fornirli al volo su specifica richiesta. In particolare questo è proprio il compito di Stream Analytics che analizza costantemente il flusso dei in modo da validarne la conformità alla specifica logica di analisi: solo se si verifica un match vengono attivate (trigger) opportune azioni di risposta.
Stream Analytics è un “temporal system”, ossia basa le proprie azioni ed elaborazioni sulla specifica sequenza temporale dei dati, consentendo anche di accorpare le diverse sorgenti. Si tratta di un aspetto non di poco conto, considerando che gli strumenti tradizionali di BI, tipicamente, non operano in tale direzione se non attraverso complicate e costose procedure.
Un tipico esempio di utilizzo di Event Hub e Stream Analytics sono i sistemi di manutenzione preventiva in cui una rete di sensori, o le applicazioni di monitoraggio, inviano i dati sullo stato dei sistemi in esercizio.
Da febbraio 2016, le soluzioni Azure per il mondo dell’Internet of Things si sono arricchite di un nuovo servizio: l’IoT Hub. Si tratta di un hub specificamente ottimizzato per supportare milioni di device connessi simultaneamente, abilitando una comunicazione bi-direzionale (device-to-cloud and cloud-to-device), a differenze dell’Event Hub che consente una comunicazione solo mono-direzionale (device-to-cloud).
L’aspetto estremamente interessante nell’utilizzo di Azure risiede nella possibilità di attivare rapidamente un sistema completo in grado di supportare l’acquisizione e l’analisi realtime dei dati, andando a sperimentare le proprie assunzioni e a ottimizzare l’intera infrastruttura a supporto, come detto in chiave Make-Measure-Learn.
Make-Measure-Learn
Microsoft, inoltre, ha reso disponibile l’Azure IoT Suite, ovvero una serie di soluzioni pre-confezionate, attivabili velocemente e dedicati a specifici ambiti di utilizzo. Allo stato attuale sono disponibili due soluzioni: Predictive Maintenance e Remote Monitoring.
Non da ultima la questione dei costi: come tutti i servizi Azure, si pagano i componenti scelti solo in funzione del tempo effettivo di utilizzo.
La “T” dell’IoT: gli Smart Thing
Il secondo aspetto di rilievo è quello relativo agli Smart Thing, ovvero i device intelligenti in grado di raccogliere ed inviare dati alla piattaforma cloud. In linea generale possiamo individuare tre categorie di riferimento:
- Evaluation Kit, sono i dispositivi base che consento di costruire un prototipo di device in grado di acquisire dati dal mondo reale e, eventualmente, rispondere con impulsi elettro-meccanici. In questa categoria rientrano i ben noti Arduino, Raspberry PI, ecc…
- Production Device, sono i dispositivi industriali realizzati specificamente per un ambito o una soluzione specifica. Tipicamente sono di tipo personalizzato e derivante da una prototipazione basata sugli Evaluation Kit e poi costruiti sulla base di una specifica Bill of Materials (BOM);
- Wearable Devices, sono i dispositivi indossabili in grado di inviare dati biometrici o di contesto, come esempio la geolocalizzazione. Rientrano in questa categoria i vari Band, SmartWatch, ecc…
- Mobile Device, sono i dispositivi mobile con cui interagiamo quotidianamente. Rientrano in questa categoria gli Smartphone, i Tablet, ecc…
Wearable device: Microsoft Band
Proprio l’ampia disponibilità di device differenti, rafforza la necessità di avere una piattaforma di riferimento estremamente flessibile ed adattabile, caratteristiche architetturali alla base di Seguimi.
Chiaramente tutti i device devono in qualche modo poter comunicare con l’Event Hub specifico, e ciò avviene attraverso dei protocolli di comunicazione più o meno standard la cui scelta dipende sempre dal tipo di applicazione da realizzare. Inoltre, va sottolineato, che, in molti casi, si tende ad utilizzarne sempre più di uno in relazione alla specifica sotto-area di interesse.
I protocolli più utilizzati sono sicuramente:
- ReST/HTTP, particolarmente adatto per le applicazioni su tablet o smartphone che accedono al Cloud per mostrare all’utente finale i dati acquisiti. Questo protocollo soffre però del problema dell’overhead dei dati, ovvero dei dati aggiuntivi (ad esempio l’header) per il trasporto del contenuto informativo, cosa che può diventare un problema di costi/banda/energia/ecc…
- MQTT (Message Queue Telemetry Transport) nasce per la “telemetria” ed è estremamente leggero ed affidabile (garantisce tre livelli differenti di QoS) soprattutto su reti non perfette in termini di stabilità della connessione;
- AMQP (Advanced Message Queuing Protocol), pensato per la connessione “server to server” e quindi per sistemi enterprise, più “pesante” di MQTT ma con il supporto a numerosissimi pattern di comunicazione differenti.
Ad essi si aggiungono anche i vari XMPP, DDS, STOMP e così via, mentre se si vuole continuare ad utilizzare un approccio http-like, si può optare per CoAP (Constrained Application Protocol, basato sul pattern request/response e su UDP), “binario” e quindi più leggero del cugino diretto.
AMQP e HTTP sono supportati nativamente dagli Event Hub di Azure, mentre l’IoT Hub supporta anche MQTT.
Intentional Architecture
In chiave full Agile, l’Architettura definita è una Intentional Architecture, ovvero una soluzione di riferimento da validare e migliorare velocemente e costantemente in funzione dei feedback ottenuti dalla Continuous Delivery della propria soluzione.
Seguimi Intentional Architecture
A breve si andranno ad analizzare le macro aree dell’Intentional Architecture e i relativi servizi portanti, ma prima ci si concentrerà sulle motivazioni che spingono all’utilizzo di differenti tipologie di store per la persistenza dei dati.
Polyglot Persistence
L’ambito BigData di Seguimi impone l’utilizzo di diverse tecnologie di persistenza in grado di rispondere adeguatamente alle differenti esigenze di utilizzo.
In particolare, è possibile suddividere i dati in due grandi famiglie:
- Operational Data: sono i dati necessari alla corretta operatività real-time della Piattaforma;
- Analytics Data: sono i dati persistiti per analisi statistiche e predittive.
I primi sono supportati da tecnologie in grado di garantire bassi tempi di risposta e scalabilità istantanea, mentre i secondi da soluzioni maggiormente orientate alle attività di analisi su larga scala.
Partendo da questa distinzione non deve sorprendere che l’Intentional Architecture qui presentata abbia differenti tipologie di store e relativi sistemi di gestione. In particolare:
Azure SQL (Operational Data): consente di organizzare i dati in forma relazionale e renderli immediatamente disponibili e interrogabili;
Document DB (Operational Data): consente di organizzare i dati in forma aggregata non relazionale, in ottica di utilizzo rapido con interrogazioni dirette. Ottimizzato per lo scaling orizzontale ad alta affidabilità;
Blob Storage (Analytics Data): consente di memorizzare i dati in forma aggregata, non relazionale, in modo da essere elaborati con tecniche di Map-Reduce grazie alla specifica implementazione Azure di Hadoop, ovvero HDInsight;
Acquiring Area
L’Acquiring Area è la sotto area dedicata all’acquisizione e l’analisi dei dati real-time. Si compone dei seguenti servizi abilitanti:
Event Hub: consente di gestire la telemetria (acquisizione massiva di dati) e gli eventi, provenienti da sorgenti esterne, fornendo un buffer persistente e una latenza inferiore al secondo in funzione di uno scaling di milioni di dispositivi;
IoT Hub: specializza gli Event Hub per il mondo dell’Internet of Things, consentendo una comunicazione bi-direzionale ed ottimizzata per gestire i protocolli più comunemente utilizzati dagli EVK;
Stream Analytics: consente di effettuare operazioni real-time sull’enorme quantità di dati provenienti dalle varie tipologie di dispositivi connessi alla piattaforma. È fortemente integrato, anche se out-of-the-box, con gli Hub in modo da consentirne una rapida ed efficace attivazione, oltre a funzionare da filtro per la selezione dei dati stessi.
Staging Area
La Staging Area è dedicata alla persistenza passiva e attiva dei dati: nel caso “passivo”, i dati vengono persistiti su uno specifico storage, nel caso “attivo” vengono veicolati ad un secondo Hub che attiva specifiche azioni di risposta.
- Event Store: contiene i dati che hanno “superato” la validazione di Stream Analysis, accessibili tramite gli strumenti SQL e JavaScript di DocumentDB;
- Blob Storage: consente di memorizzare in forma aggregata, non-relazionale. Il vantaggio è quello di scalare con estrema rapidità e garantire un alto volume di transazioni su miliardi di Entità (dati atomici);
- Event Alarm Message (Hub): attiva una serie di azioni specifiche in relazione a specifiche condizioni rilevate nei dati in ingresso.
Services Area
La Services Area è la sotto-area dedicata all’esposizione dei Servizi con cui è possibile utilizzare le funzionalità messe a disposizione da Seguimi.
Ognuno dei Servizi (che verranno successivamente dettagliati) è sviluppato in chiave Microservices come rappresentato nella figura seguente:
Microservices Architecture
La scelta non è assolutamente causale ed è ad oggi considerata quella che consente maggiormente di realizzare soluzioni scalabili sfruttando intensivamente le potenzialità del Cloud, grazie anche ad una forte spinta all’automazione che la porta nella sfera DevOps.
Nell’architettura tipo possiamo individuare i seguenti layer di riferimento:
- Store, il layer di persistenza dei dati, non per forza relazionale e/o unico. In tale layer rientra anche il servizio di caching;
- Data Access, raggruppa i servizi relativi al recupero/persistenza dei dati dallo store di riferimento;
- Service, sono i servizi di Dominio, ovvero i servizi che assolvono alle funzioni proprie del Microservice;
- Protocol, sono i protocolli di comunicazione che consente di utilizzare il Microservice;
- API Gateway, è il layer di gestione delle API di comunicazione che consente di aggiungere specifiche caratteristiche (es: security, access level, ecc.) ai protocolli di riferimento;
- Enriched Protocol, sono i protocolli di comunicazione esposti verso gli utenti finali in relazione alle specifiche configurazioni di riferimento;
- SDK, sono i development kit per l’utilizzo del Microservice nei vari linguaggi di sviluppo;
- Models, rappresenta le Entità di Dominio che sono proprie del Microservice e attraversano i vari livelli logici;
- Automation, raggruppo tutti gli strumenti automatici (script, tool, ecc…) fondamentali per il provisioning e lo scaling del Microservice.
All’interno di Seguimi, i Microservices di riferimento sono:
Bio Service, consente di interrogare i dati raccolti dai dispositivi connessi alla piattaforma;
- Reference Data Service, consente di ottenere i dati di riferimento per caratterizzare correttamente la telemetria dei dispositivi (lat/long, formato di rappresentazione dell’orario, ecc..);
- Device Service, consente di gestire i device (configurazione, frequenza della telemetria, provisioning, ecc…) dei device connessi alla Piattaforma;
- Config Service, consente di gestire la configurazione dei vari aspetti della Piattaforma;
- Profile Service, consente di gestire gli aspetti di profilazione degli utenti, anche considerando l’approccio M2M.
Per quanto riguarda i servizi di API Management si è scelto di utilizzare l’omonimo servizio di Azure che consente di gestire ogni singolo aspetto dei servizi esposti in relazione ai protocolli, sicurezza, accessibilità, ecc..
Data Insight Area
La Data Insight Area è la sotto area dedicata all’analisi multi-dimensionale dei dati e alle funzionalità predittive in ottica Machine Learning.
I dati sottoposti all’azione dei vari servizi di Stream Analytics, vengono persistiti nello store non relazione Blob Storage, facente parte del pacchetto di servizi HDInsight che consente di gestire ed interrogare Big Data con estrema affidabilità ed efficienza.
HDInsight è sfruttato dal servizio di Machine Learning che consente di costruire, gestire e distribuire soluzioni di analisi predittive estremamente flessibili. I relativi risultati sono poi esposti tramite il succitato Predictive Microservice.
Alarm Area
L’Alarm Area è la sotto area dedicata alla notifica di segnalazioni (alarm) real-time laddove si dovesse verificare la necessità di notificare un particolare stato di attenzione: si immagini un abbassamento del battito cardiaco del paziente monitorato.
Quest’area si compone di:
- Alarm Event Hub: gestisce il flusso di dati che costituiscono un alarm, secondo quanto identificato dai servizi di Stream Analytics;
Alarm Worker Role: sono i servizi custom che prendono in consegna l’alarm, lo trasformano per le specifiche esigenze preparando la relativa notifica;
Notification Hub: si preoccupa di consegnare fisicamente il messaggio di notifica al dispositivo mobile.
Conclusioni
L’analisi condotta dimostra che Seguimi è realizzabile con un approccio Agile, in particolare tramite AgileIoT, incrementale e orientato ai servizi. Le ricerche di mercato hanno evidenziato particolare interesse per questo genere di soluzioni, potendo inoltre contare su specifici azioni di finanziamento a livello nazionale ed europeo.
Resta chiaramente necessario avviare la fase di fast-prototyping per validarne la sostenibilità rispetto agli aspetti cardine di una tipica soluzione IoT.
Spero che il PVI vi sia piaciuto! Aspetto i vostri feedback... stay tuned!
