Nell’ambito della gestione di una vera smart community ci si concentra sugli use-case specifici e sull’integrazione degli stessi, sulla qualità e quantità di sensoristica distribuita e sulla possibilità di espandere queste soluzioni quasi senza continuità.
Indice degli argomenti
La gestione dei dati nelle smart community
Con il proliferare delle tecnologie di connessione wireless narrowband e a bassa potenza, sempre più si necessita di piattaforme che, nativamente, permettano la gestione del dato semplicemente da fonti diverse e trasportati in qualche modo fino alla stessa applicazione finale.
In tempi recenti, con le prime applicazioni di smart metering, sono nate le prime piattaforme SAC – sistema di acquisizione centralizzato – il cui scopo era collezionare i dati provenienti da contatori tutti uguali attraverso una rete radio proprietaria.
Dimenticandosi per un attimo della complessità di attivare e gestire una rete radio proprietaria, il vero compito della piattaforma di gestione era raccogliere i dati e metterli a disposizione del sistema gestionale per l’analisi successiva, in un rapporto univoco sensore-dato-soluzione applicativa finale.
Dalle prime reti a 868 MHz dedicate, si è poi passati alla rete LORAWAN (anch’essa dedicata) per arrivare oggi alle reti 4G/5G, Nb-IoT e per finire con l’evoluzione del WM-Bus nelle più comuni versioni Trash-by e Walk-by.
L’altra complicazione è sulla serie infinita di device e sensori che si possono collegare alla piattaforma di gestione, non solo per quantità, ma soprattutto per tipologia di misura o di dato raccolto, protocollo e necessità di gestione. Raccogliere la misura dei consumi idrici giornalieri da uno smart meter è diverso dal raccogliere ogni ora i dati sull’inquinamento e/o sulla temperatura.
Utilizzare il dato per una rappresentazione e una analisi quali-quantitativa di una grandezza (ad esempio la temperatura) per decidere le politiche di gestione del lavoro all’aperto nelle ore centrali della giornata in piena estate è ben diverso dall’usare la lettura del meter per calcolare i consumi ed emettere fattura.
Nel primo caso, avendo più sensori distribuiti in una zona, laddove una lettura venisse persa o un sensore non funzionasse, piuttosto che un dato arrivi corrotto, tutto sommato si riuscirebbe ancora a ricostruire la situazione su una area specifica (una città, un quartiere) e il suo trend nel tempo mentre la decisione sui provvedimenti da adottare spetterebbe a persone che utilizzano i dati a supporto di una scelta consapevole, informata e oggettiva, ma non assolutamente dettata in automatico dal dato in se. Ci sarebbero considerazioni sociali, si valuterebbero le previsioni nei giorni a seguire, si penserebbero a misure alternative, etc.
Nel secondo caso abbiamo una relazione univoca lettura del meter-fattura, non vi è decisione umana nel mezzo, e non vi è possibilità (almeno in prima battuta) di mediare con altri meter di altre utenze. Nel primo caso la piattaforma deve avere dei requisiti tali da assicurare un trend o un dato mediato, nel secondo caso semplicemente non può sbagliare un colpo perché si trasforma da strumento per la raccolta dei dati a strumento per la validazione fiscale dei dati e fattura per l’utente.
Piattaforme SAC e infrastrutture digitali per dati IoT
Una piattaforma SAC moderna, o meglio una piattaforma dedicata alla gestione massiva dei dati IoT, costituisce la spina dorsale delle infrastrutture digitali di una smart community.
Questi sistemi evoluti sono progettati per raccogliere, organizzare, elaborare e valorizzare enormi quantità di dati generati da una vasta rete di sensori e dispositivi, spesso distribuiti in modo capillare sul territorio urbano ed extraurbano.
Le complessità delle piattaforme SAC
Le complessità da affrontare sono quindi notevoli, vediamole in maniera semplificata partendo dagli end devices e attraversando i vari layer architetturali, di rete e di applicativi per finire ai vari sistemi di Input/Ouput.
Gli end devices come fonti primarie del dato
In ambito smart communities i più comuni sono smart meter, sensori di grandezze fisiche come portate, temperature, inquinamento fino a misuratori multiparametrici per il monitoraggio ambientale o di affollamenti, etc etc. L’importante è che i dati in uscita da ogni device siano strutturati.
Infrastrutture di trasporto e protocolli di rete
Trattandosi di sensoristica distribuita sul territorio, i sistemi di trasmissione e trasporto del dato per elezione sono quelli wireless con l’utilizzo di reti pubbliche e fisse, soprattutto Nb-IoT e LoraWan ma anche 4G, Sigfox ed altre soluzioni legacy, oltre che soluzioni in mobilità WM-BUS trash-by e walk-by che non possiamo definire connessioni fisse. Il compito di questo layer è raccogliere il dato dagli end devices e presentarlo nella maniera giusta al layer successivo.
Il core network e il ruolo dell’IoT engine
L’IoT Core Network è il primo engine fondamentale del sistema perché gestisce i pacchetti dati e li instrada correttamente legandoli anche ad applicazioni tipiche del layer di trasporto. Ad esempio, nel caso di trash-by o walk-by deve anche occuparsi di gestire l’attivazione del collegamento radio all’occorrenza, gestire e tradurre il payload in funzione dell’end-device e supportare questi ultimi con applicazioni tipo tool cartografici e fotografici che, nel caso di utilizzo di rete pubblica Nb-Iot, ad esempio, non sono necessari. In sostanza questo layer si assicura di mettere a disposizione dei device l’ambiente giusto per raccogliere e passare il dato al livello successivo, in maniera seamless per i livelli successivi. È un livello core con le sue declinazioni hardware e software e più prossimo ai devices.
Il network server come strato di provisioning
Il livello Network Server invece si occupa di attività di provisioning della rete, dei device e di monitoraggio del funzionamento degli stessi, soprattutto quando si utilizzano reti pubbliche per la trasmissione dei dati.
Applicazioni e gestione dei dati strutturati
Che i dati arrivino da un Network Server o da un sistema di acquisizione in mobilità, essi vengono consegnati al Livello Applicativo che, tra i principali compiti, ha quelli di storage dei dati e decriptazione del payload, traduzione payload, interfaccia di consultazione dei dati e fornire strumenti di analisi dei dati, gestione della connettività sulla rete, sincronizzazione dati con il CRM ed esportazione a quest’ultimo o alle applicazioni di gestione dedicate alla specifica tipologia di device. Se l’IoT Core è il layer di riferimento per il livello “fisico” di raccolta del dato, l’Application Layer è il riferimento logico per il “dato”.
Quando l’Application Layer ha ottenuto la piena padronanza del dato, ne ha assicurato la consistenza, l’integrità e la validità, utilizzando il gestore di I/O lo passa quindi all’applicazione specifica che può essere il sistema di fatturazione (applicazioni contabili e fiscali), piuttosto che sistemi Scada o di Telecontrollo (applicazioni di processo), o una piattaforma di monitoraggio ambientale (sistema DSS) oppure qualsiasi altra applicazione pertinente.
Scalabilità e interoperabilità delle piattaforme IoT
Caratteristiche come la scalabilità, ma più recentemente algoritmi di analisi e machine learning, stanno trasformando questi sistemi da gestori di dati grezzi a sistemi di analisi predittiva per la gestione della community proprio per la capacità di unire tecnologie cloud-native con interoperabilità, sicurezza e privacy in un unico ambiente.
E da questo unico ambiente si possono alimentare, o scambiare dati con, altre piattaforme per la gestione massiva dei dati IoT, affinché si costruiscano smart communities che integrano processi diversi, e che sfruttino end devices installati per applicazioni specifiche, come coadiuvanti in applicazioni apparentemente lontane tra loro. In questo senso sono dei veri e propri enabler di scenari tutti da percorrere.
