Tutti ormai siamo convinti che l’Internet of Things sta pervadendo le nostre vite; quello che a volte non si dice o si dimentica di dire è che l’IoT dipende quasi completamente dai sensori, dalle informazioni che raccolgono e dai dati che producono. Stando così le cose, sembra appropriato analizzare 5 aspetti che vengono sempre trascurati quando si parla di sensori e di dati dei sensori: non tutti i dati registrati dai sensori sono veritieri, oppure sono parziali, ed è necessario analizzare le serie temporali di dati. I sensori poi raccolgono dati ma non misurano effettivamente ciò che ci interessa direttamente, nel senso che, presi di per sé, i dati dei sensori spesso sono poco utili o al limite non utilizzabili. E infine l’IoT per funzionare ha bisogno di infrastrutture che vanno realizzate, anche se non sono a buon mercato.
Internet4Things ospita su questo tema un contributo di Martin Willcox, Director Big Data Centre of Excellence, Teradata Corporation
I sensori a volte mentono
La prima cosa che si tende a trascurare è che i sensori talvolta mentono. Questo fatto è spesso accolto con grande sorpresa da dirigenti e esperti IT: solo perché i sensori non arrivano al lavoro stanchi o distratti, non significa che tutti i dati che essi registrano siano effettivamente veritieri. Per averne la conferma è sufficiente fare una chiacchierata con gli ingegneri responsabili della progettazione e realizzazione delle reti di sensori. Il mio cardiofrequenzimetro ad esempio ha registrato – nel bel mezzo di una corsa di 30 minuti sul tapis roulant – 70bpm per parecchi minuti: o io sono una specie di supereroe o il sensore era difettoso. Purtroppo per me si trattava del secondo caso. Altro esempio forse più interessante: a causa degli estremi sbalzi di temperatura a cui sono sottoposti nei giacimenti petroliferi nel deserto, spesso i sensori perdono in termini di affidabilità poco dopo essere stati installati. Sostituire i sensori sotterranei è un’operazione da non prendere alla leggera: mentre infatti il costo dei sensori veri e propri risulta irrisorio, non si può dire altrettanto circa il costo della mancata produzione conseguente a tale operazione. Pensandoci bene è piuttosto ovvio che i sensori mentono. Il nostro stesso corpo si avvale di molti strumenti, e a volte capita di essere ingannati dai propri “sensori”. Avete mai avuto la sensazione di cadere da fermi? Avete mai avuto un capogiro dopo esservi alzati troppo velocemente? In caso di una “lettura sbagliata” si confronta il dato sospetto con i dati registrati dagli altri sensori. Allo stesso modo, si può compensare il malfunzionamento di un sensore in un giacimento petrolifero creando una rete neurale basata sulla lettura dei sensori adiacenti. Ogni scenario richiede un approccio specifico, ma qualsiasi approccio si scelga è fondamentale comprendere che i dati provenienti dai sensori devono essere gestiti. Non si può semplicemente supporre che i dati generati dalle macchine siano accurati, completi e coerenti solo perché sono stati prodotti da una macchina.
Anche se non stanno mentendo, i sensori potrebbero non dire tutta la verità
Il secondo aspetto da non trascurare quando si parla di sensori è che anche se non stanno mentendo, potrebbero non dire tutta la verità. Spesso i sensori sono gestiti da unità di controllo, progettate nella maggior parte dei casi per il monitoraggio remoto e il controllo dell’intera macchina, e non per immagazzinare e inoltrare dati ad alta frequenza provenienti dai singoli sensori. Spesso e volentieri le unità di controllo filtrano e sintetizzano quei dati.
Sia chiaro, non è per principio una cosa negativa. I dati dei sensori possono essere altamente ridondanti e ripetitivi e potrebbe non avere senso memorizzare enormi volumi di dati che si riducono ad un dispositivo che segnala “situazione normale” 5.000 volte al secondo. Ma siccome ciò che per un’applicazione è “rumore” potrebbe invece rappresentare un segnale vitale per un’altra, come minimo è necessario sapere dove e come i dati provenienti dai sensori sono stati filtrati e sintetizzati. In molti casi, andrebbe evitata la sintesi prematura dei dati raccolti dai sensori.
Le serie temporali di dati forniti dai sensori
I dati vengono prodotti dai sensori in diverse forme e dimensioni, ma fondamentalmente sono nella forma di una serie di misurazioni riportanti data e ora. Questi data point non sono tutti uguali. A volte risulta relativamente semplice per alcune applicazioni rilevare importanti data point: ad esempio, potrebbe essere necessario capire quando i dati provenienti da un particolare dispositivo superano un determinato valore. In altri scenari, invece, il “segnale” a cui siamo interessati può risultare più “subdolo”. Mi ricordo ad esempio un caso in cui il pattern “basso – medio – basso” si è rivelato un importante fattore predittivo. Il valore di questo schema apparentemente insignificante non era stato previsto da nessuno di coloro che erano coinvolti nel progetto fin dall’inizio. Ecco il terzo aspetto da non trascurare quando si tratta di dati dei sensori: l’estrazione di indicatori utili da ridondanti serie temporali di dati richiede un lavoro notevole, spesso accompagnato dall’integrazione di dati aggiuntivi.
Le prime applicazioni analitiche dei dati dei sensori risalgono a più di dieci anni fa, e il loro studio può dirci molto sulle sfide e le opportunità relative alla prossima generazione di applicazioni analitiche dei dati dei sensori. Sistemi costosi – e spesso critici per la sicurezza – come motori aeronautici, treni e reti di distribuzione di energia elettrica sono stati dotati di sensori già da molto tempo. Teradata ha utilizzato e sta utilizzando i dati prodotti da questi sensori per creare soluzioni di manutenzione preventiva per clienti appartenenti a diverse aree geografiche e settori: U.S. Air Force, per esempio, ha ottenuto un aumento tra il 5 e l’8 per cento della disponibilità in servizio della sua flotta di elicotteri. Union Pacific Railroad è stata in grado di ridurre del 75 per cento i deragliamenti legati alle prestazioni dei cuscinetti volventi. Una delle più grandi cartiere al mondo riesce a mantenere una produzione fluida senza incorrere in disastrosi inceppamenti nei suoi enormi impianti lunghi più di un chilometro e mezzo. Un operatore ferroviario europeo riesce a prevedere i guasti ai suoi treni fino a 36 ore prima che questi si verifichino.
L’aspetto più interessante di questi progetti è che, nonostante le apparenti differenze, in fin dei conti essi risultano molto simili. Chiaramente dipendono tutti dalla rilevazione e registrazione fatta dai sensori di dati pertinenti – come temperatura, pressione, vibrazione, e molti altri parametri. Generalmente però, è necessario eseguire una pre-elaborazione dei dati grezzi dei sensori per poter identificare i cosidetti “eventi”, cioè cambiamenti di stato significativi. Per fare ciò è necessario analizzare le serie temporali di dati. Ma è anche necessario classificare i dati dei sensori per creare e “educare” un modello predittivo gestito, che spesso richiede l’utilizzo di analisi testuale per estrarre i dettagli dei guasti e delle soluzioni dai rapporti ingegneristici – e può inoltre richiedere l’integrazione dei dati dei sensori con i dati operativi. Una volta classificati questi dati, è importante conoscere la sequenza di eventi che porta ad una particolare condizione (il “path to failure”). Per fare questo è necessaria l’analisi di percorso. La comprensione delle associazioni e delle relazioni tra eventi diversi ed elementi diversi è spesso vitale: proprio per questo motivo risulta spesso necessario l’utilizzo di analisi grafiche e di affinità per capire quali variabili possano contribuire maggiormente alle previsioni relative al target che si sta cercando di modellare. E così via. I modelli predittivi che stanno alla base di molti progetti analitici IoT fanno spesso affidamento a tecniche analitiche relativamente semplici, come la regressione logistica, gli alberi decisionali e le foreste casuali. Al contrario, il processo di creazione di un set analitico di dati – il carburante con cui vengono alimentati questi metodi – a partire dai dati grezzi dei sensori, è spesso tutt’altro che semplice.
I sensori e la quantità di interesse
La quarta cosa che dimentichiamo spesso a proposito dei sensori è che solitamente non misurano direttamente la quantità di interesse. Il dispositivo che portate al polso non misura effettivamente il vostro ciclo di sonno: per farlo dovrebbe essere connesso a degli elettrodi attaccati alla vostra testa che misurano la vostra attività cerebrale. Ma chi vorrebbe andare a dormire pieno di cavi come una cavia da laboratorio? In realtà i sensori misurano il polso e la frequenza e l’intensità dei vostri movimenti notturni, permettendo al dispositivo di dedurre se state dormendo o meno. Un modello generato altrove e basato su dati non provenienti da voi sta lavorando al vostro polso quasi in tempo reale – e mentre dormite. Ora, se conoscete abbastanza a fondo gli analytics e la scienza dei dati, allora saprete che la costruzione del modello e il suo funzionamento sono per lo più processi separati, anche quando fanno affidamento sugli stessi dati e sulla stessa infrastruttura (basta pensare ai modelli di rischio del credito che la banca utilizza per valutare la vostra domanda per una nuova carta di credito, ad esempio). Ma nel caso di applicazioni e dispositivi IoT, molto spesso questi processi risultano essere estremamente diversi – e il funzionamento del modello ha luogo su una rete di server edge ripartiti o sugli stessi dispositivi. Esistono ottime ragioni per distribuire modelli IoT che funzionano in questo modo. Molti dispositivi hanno una potenza di calcolo sufficiente per far funzionare modelli semplici come il nostro modello di misurazione del sonno – e tutti i dati di cui hanno bisogno per farlo sono spesso disponibili a livello locale, senza la necessità di trasmettere altrove i dati di basso livello, evitando così altri costi e complicazioni. Non è finita qui: i sistemi distribuiti possono fornire ridondanza e aumentare la disponibilità, isolando ad esempio i processi locali dai guasti di rete, altra buona ragione per distribuire l’elaborazione IoT in questo modo. Va sottolineato che non tutti i modelli possono essere eseguiti localmente sul dispositivo. Alcuni possono essere destinati ad ottimizzare i sistemi end-to-end, o le prestazioni di una intera flotta di dispositivi – e potrebbero richiedere dati non locali, o calcoli avanzati. Inoltre la costruzione del modello in un primo tempo, e la sua messa a punto in seguito, richiede quasi sempre che l’aggregazione di dati storici da numerosi dispositivi, perché la “variabile” che cerchiamo di prevedere potrebbe presentarsi solo di rado.
L’ultima cosa da non trascurare è che presi di per sé, i dati dei sensori spesso sono inutili, o al limite non utilizzabili. Poniamo ad esempio che il sensore di pressione dell’olio del cambio di un treno registri temporaneamente il superamento del valore limite – c’è da preoccuparsi o bisogna considerarlo solo un “contrattempo”? Per poter prendere qualsiasi tipo di decisione ponderata è necessario confrontare i dati attuali con quelli precedenti ai guasti avvenuti in passato; individuare quei segnali richiede l’analisi storica dei dati del sensore, delle operazioni, delle riparazioni e della manutenzione. Supponendo che quel “contrattempo” sia uno di quei segnali, e che il nostro modello preveda che il cambio si guasterà nelle prossime ore, è necessario prendere alcune decisioni.
È possibile aspettare che il treno arrivi al capolinea, o c’è bisogno dell’intervento di un tecnico specializzato alla prossima stazione? Nel caso fosse necessario l’intervento in corsa, bisognerebbe poter accedere ai dati delle risorse umane e ai dati operativi per verificare la disponibilità di un tecnico con le competenze richieste. Servirebbero i dati di inventario per verificare la disponibilità dei ricambi, e qualora questi non fossero disponibili sarebbero necessari nuovamente i dati delle operazioni per valutare le opzioni in caso di sospensione forzata del servizio.
Il fatto che “i dati amano altri dati” si applica perfettamente ai dati dei sensori. Non prevedere un’integrazione dei dati dei sensori con i dati provenienti da una più ampia rete di sensori e con altri dati provenienti da tutta l’azienda, equivale a fare fallire qualsiasi progetto. Eppure secondo Gartner Group, una sbalorditiva percentuale dell’80% di iniziative IoT che sono attualmente in essere stanno correndo esattamente questo rischio.
Internet of Things: una nuova speranza
L’Internet of Things è il futuro. E come si sente dire spesso – il futuro è già arrivato, solo che non è equamente distribuito. Tesla, ad esempio, trasmette i dati dei sensori dai suoi veicoli e ha già analizzato quei dati per implementare almeno un cambiamento significativo sulle sue vetture. Il tutto semplicemente attraverso l’aggiornamento di un software da remoto , senza dover richiamare un singolo veicolo. L’IoT – e i relativi dati prodotti dai sensori – non solo ci permetterà di ottimizzare i processi aziendali (anche nella prospettiva Industry 4.0) in modi che stiamo appena iniziando a comprendere, ma anche di creare prodotti e servizi data-driven completamente nuovi. Se avete dei dubbi sulla portata di questi cambiamenti, basta chiedere ad un taxista cosa ne pensa di Uber (state però a distanza di sicurezza mentre lo fate).
Anche i più ottimisti tra noi esperti del settore dovrebbero accettare il fatto che ultimamente l’IoT è stato è stato un po’ sopravvalutato di recente: i 21 miliardi di dispositivi intelligenti che si prevede saranno attivi entro il 2020 non saranno in grado di parlare magicamente gli uni con gli altri solo perché ognuno ha un indirizzo IP. Nell’immediato futuro non c’è nessun C-3PO che traduca i numerosissimi protocolli dei sensori già esistenti, per non parlare poi di tutti quelli che ancora devono venire. E se anche esistesse, come abbiamo già visto in precedenza, i dati che questi sensori producono sono testimoni inaffidabili e talvolta ingannevoli degli eventi che vogliamo capire. Secondo gli esperti manca ancora qualche anno perché il nostro frigorifero inizi a condurre aste al ribasso con tre diversi fornitori per approvvigionarsi di latte.
Tutto ciò ha effetti sul nostro modo di acquisire, memorizzare, elaborare, analizzare e gestire i dati dei sensori che sono alla base della rivoluzione IoT. Questi dati devono essere gestiti, poiché i sensori a volte mentono – o smettono di funzionare – e noi potremmo avere bisogno di interpolare ed estrapolare. Dobbiamo poter sapere dove e come lo abbiamo fatto – in modo da sapere se i dati che stiamo analizzando sono grezzi o elaborati. È necessario cercare di acquisire dati grezzi e, laddove non fosse possibile, capire come essi siano stati filtrati e sintetizzati. Solitamente sono necessarie molte analisi preliminari per poter eseguire l’analisi che ci interessa davvero; dobbiamo quindi essere sicuri di poter sostenere “analisi multi-genere” – su larga scala – in modo da poter trasformare le ridondanti serie temporali di dati in utili set analitici. Bisogna riflettere attentamente su dove fare funzionare quei modelli – e su come implementarli e gestirli – in modo da poter rendere operativi con successo e in modo affidabile gli analytics dello IoT. In questo modo è possibile utilizzare le informazioni ottenute in laboratorio a vantaggio dell’azienda. Infine è necessaria un’ipotesi di integrazione dei dati dei sensori con altri dati dei sensori e con altri dati di operazioni e di eventi provenienti da tutti i reparti dell’azienda (Industria 4.0). Se state pensando di acquisire i dati grezzi dei sensori in un data lake, la vostra priorità deve essere l’integrazione di quei dati con i dati delle operazioni e degli eventi nel vostro Data Warehouse.
Tutto ciò smentisce la tesi secondo cui saremmo sull’orlo di una rivoluzione alimentata esclusivamente dall’IoT. Di recente, durante Teradata Universe, un guest speaker di Monsanto ha approfondito questo tema dicendo: “La cosa di cui non si sente parlare è che lo Iot per funzionare ha bisogno di infrastrutture, e queste non sono a buon mercato e neanche facili da realizzare”. Quando si crea l’infrastruttura, è facile concentrarsi sui sensori e sulle reti che li collegano. Ma non bisogna trascurare i dati di supporto e l’infrastruttura analitica. Sono i dati dei sensori e l’utilizzo che ne si fa a determinare il successo o il fallimento di un’iniziativa.
- Martin Willcox, Director Big Data Centre of Excellence, Teradata CorporationMartin Willcox ha 19 anni di esperienza nel settore della tecnologia informatica, e ha lavorato in 5 grandi aziende tra cui due grandi catene di retailer, ragion per cui padroneggia gli analytics e il relativo scenario dalla doppia prospettiva di utente finale e di fornitore di tecnologia. Laureato cum laude in Fisica e Astronomia presso l’Università di Sheffield ha conseguito un Master in Informatica per il Commercio e l’Industria presso la Open University. È a capo del team internazionale di scienziati dei dati e specialisti Teradata incaricati di affiancare e assistere i clienti a trarre valore dai loro asset di dati.
Articolo originariamente pubblicato il 17 Ott 2016
