Nel primo post relativo alla piattaforma IoT abbiamo parlato di alcuni aspetti introduttivi:
In questo e nei prossimi articoli, descriveremo molti aspetti del mondo IoT e come la piattaforma GV IoT li indirizza, utilizzando come scenario reale per la discussione un progetto per monitorare le deformazioni strutturali di un tunnel autostradale soggetto a smottamenti. Questo scenario verrà utilizzato come sfondo per la narrazione per tutti i post successivi relativi a questo argomento.
Per semplificare l'esposizione della piattaforma GV IoT, in termini di ciò che è e in che modo affronta alcuni dei principali problemi dell'IoT (quantità di dati da elaborare, sicurezza, scalabilità, archiviazione e analisi), descriveremo il viaggio di una singola misurazione che parte dal sensore (oggetto=thing) ed arriva fino agli umani.
In seguito descriveremo il viaggio di ritorno di un comando dagli umani agli “oggetto”.
Cominciamo ora a descrivere lo scenario di monitoraggio e subito dopo inizieremo la descrizione dall’“oggetto”, il vero protagonista di questa storia.
Il nostro scenario di riferimento sarà il monitoraggio della deformazione strutturale di un tunnel.
La tematica consiste nel monitorare la salute di un tunnel, in termini di deformazioni strutturali che potrebbero danneggiare il tunnel stesso e mettere in pericolo le persone.
Tra le cause naturali che influenzano la struttura di un tunnel ci sono:
Problemi possono nascere anche da cause umane che influenzano la struttura di un tunnel, come ad esempio:
Ma come si prepara effettivamente un tunnel per monitorare le deformazioni.
Nel nostro caso abbiamo utilizzato un BraggMETER industriale FS22 (figura 1 - https://www.hbm.com/en) ed è stato cablato l'intero tunnel con il cavo in fibra (figura 2) e sensori di deformazione e temperatura (figura 3).
Prendiamo come referenza, l’attività svolta con il nostro partner NTSG per il monitoraggio della Val di Sambro: "Sono state installate 3 linee di sensori lungo tutto il tunnel, mentre i sensori termici sono stati installati a distanze precedentemente studiate per consentire il monitoraggio della deformazione dell’intera struttura. I sensori termici sono stati inseriti per compensare gli effetti, sulle letture, delle variazioni termiche (cicli giorno/notte e stagionali) e ottenere informazioni della sola deformazione meccanica. Con questi sensori, è possibile controllare i movimenti longitudinali del tunnel e verificare se il tunnel mantiene la forma iniziale come progettato."
così da avere:
Molte informazioni sulla tecnologia IoT utilizzata possono essere trovate qui: https://www.hbm.com/en.
(1) FS22: Industrial BraggMETER |
(2) Fibre cable: can be very long |
(3) Strain sensor |
(4) BraggMONITOR application |
(5) BraggMONITOR application |
(6) Other sensors |
L'immagine 4 dell'applicazione BraggMONITOR (applicazione per finestre che si collega via LAN all’Industrial BraggMETER) mostra tutti i sensori di deformazione che partono dall’Industrial BraggMETER, che in questo caso ha quattro porte per i cavi in fibra.
|
(7) The tunnel from one of the working platform (PLE) |
(8) The FS22 + switches |
(9) The fibre cable |
(10) Wiring elements |
(11) Switch + wiring elements |
(12) Wiring elements |
Come anticipato la nostra storia inizia con un sensore di deformazione SS01 che misura una lunghezza d'onda di 1572,52 nm (nanometro = un miliardesimo di metro). In realtà non è solo quel sensore che misura la lunghezza d'onda in ogni istante, ma tutti i 780 sensori a una frequenza comune di 10 Hz.
 |
At 2018-Set-10 10:10:20.1 (.1 = 1/10 of a sec)
Wavelength = 1572.52 nm |
Ecco alcune domande iniziali a cui abbiamo dovuto rispondere per poter utilizzare la sensoristica in fibra ottica offerta dal BraggMETER:
Fortunatamente il BraggMETER ha una porta ethernet e un manuale utente che vi invitiamo a leggere per capire le reali problematiche di interfacciamento agli “oggetti”:
In breve, ecco le risposte:
Se si apre un socket con la porta di comando e si invia un comando specifico, il BraggMETER può inviare informazioni in modalità continua su un'altra porta. Si può anche decidere se si vogliono le informazioni in modalità binaria o ascii.
L'FS22 parla infatti la lingua "skippy":
Ogni pacchetto (binario in questo esempio) che si riceve ha un'intestazione di 30 byte e 6 byte per ciascun sensore. In totale (780 sensori * 6 byte) + 30 byte = 4710 byte
Uscita del BraggMETER (ogni 1/10 di secondo = 10 Hz):
Queste sono tutte le informazioni che vi servono per poter integrare le informazioni dei sensori. Si conclude qui la prima parte del nostro viaggio.
Nei seguenti Blog posts vedremo come si programma lo strato di Edge computing e come il dato del sensore (la nostra misura) può lasciare il sensore e viaggiare in tutte le sue fasi fino ad arrivare alla visualizzazione da parte dall’essere umano.
Se volete approfondire alcuni argomenti non esitare a lasciarci un commento qui sotto, anche solo per farci sapere la vostra opinione.
Viviamo in una grande era per l’information technology. Abbiamo a disposizione una moltitudine di potenti strumenti che ci permettono facilmente di sviluppare, distribuire e scalare soluzioni informatiche per adempiere alle più complesse e dinamiche esigenze di business. Grazie allo IaaS riusciamo ad ottenere una schiera di server in pochi minuti, per mezzo di SaaS […]
Ormai l’ IoT, acronimo di Internet of things è un concetto alla portata di tutti. Ma qualora ci fosse ancora qualcuno che non conosce il suo significato specifichiamo che quando si parla di IoT si intende quel complesso di tecnologie avanzate che permettono agli oggetti, anche i più comuni, di essere costantemente connessi alla rete. […]
Che cosa si intende per sharing mobility? Quali sono oggi le alternative all’uso dell’auto privata? È possibile integrare ai mezzi di trasporto pubblici quelli privati? Come gestire tale integrazione? Pianificare viaggi su misura, anche in ottica di intermodalità dei mezzi, è diventata una prerogativa per i car rental e i costruttori di automezzi in sharing […]
