L’arte di cucinare buoni dati: 3 passi fondamentali per ottenere dati di qualità

L’arte di cucinare buoni dati: 3 passi fondamentali per ottenere dati di qualità
       Scritto da Claudio Vivante

In questo articolo parliamo di alcuni semplici accorgimenti che permettono di avere dati buoni pronti per nutrire il vostro applicativo di DATA ANALYTICS, semplici ma non così scontati.

A chi di voi mangia pesce, sarà capitato di ordinare un’orata o un branzino al ristorante ed osservare il cameriere che rimuove le lische e la pelle prima di porgervi il piatto. Togliere le lische e servire la parte “utile” del cibo, è la mia immagine preferita quando devo illustrare il concetto di buoni dati.

Il commensale è l’utilizzatore dei dati ovvero l’analista dei dati oppure, come accade sempre più spesso, è il software di analisi. Come ho ricordato in un mio precedente post (leggi articolo) tutta la gestione dei dati (raccolta, post-elaborazione e metodologie di salvataggio, devono essere orientate a semplificarne l’analisi. L’analisi dei dati è la parte più critica e costosa dell’intero ciclo di gestione delle informazioni (a parte i casi in cui i dati provengano da sensori e processi fisici particolarmente complessi, ma si tratta di una esigua minoranza di casi) e dunque ogni euro speso per migliorare la qualità dei dati forniti al processo di analisi, è un euro ben speso, che ne ha fatti risparmiare almeno due. Oggi parliamo dunque di alcuni semplici accorgimenti che permettono di avere dati buoni pronti per nutrire il vostro applicativo di DATA ANALYTICS.

 

1. Scegliere nomi univoci per le sorgenti dei dati

La prima cosa da fare è scegliere nomi univoci per le sorgenti dei dati: per esempio se dobbiamo misurare delle sonde di temperatura in un macchinario è meglio aggiungere un prefisso nell’identificativo che ci ricorda che le termocoppie sono in quella macchina (es. M1/Temp1, M1/Temp2). Questo perché prima o tardi ci sarà una seconda macchina da cui misurare le temperature ed è meglio evitare di cambiare i nomi degli identificati dei segnali a lavori in corso.

È sempre desiderabile che ogni segnale misurato disponga di un nome editabile che può cambiare nel tempo ed un identificativo globale univoco (GUID) che è usato dal programma di analisi per accedere ai dati e fare i calcoli: questo semplifica il lavoro dei programmatori e riduce gli errori. La definizione del GUID può essere fatta in vari modi, io consiglio di scegliere un formato che riprende la codifica dei TAG EPC-SGTIN adottata dagli RFID, in cui il carattere punto “.” separa le parti del nome, per esempio

CompanyID.PlantID.SystemID.SubsystemID.AcquisitionID.SensorID

Ovviamente un altro carattere separatore tra le parti che compongono il GUID va altrettanto bene, alcune piattaforme usano “/”, altre “:”, l’importante è non mettere caratteri utilizzabili nella definizione degli ID stessi.

 

2. Uniformare le grandezze dei segnali prima di analizzare i dati

La seconda cosa di cui tener conto è l’unità di misura in cui sono espresse le grandezze raccolte. Sempre più spesso i punti di raccolta dati sono di marche diverse e con l’avvento dell’Industrial Internet Of Things (IIOT), gli smart sensors sono collegati direttamente alle applicazioni di raccolta dati tramite webservices o altri protocolli e con troppi PLUG & PLAY si rischia di perdere il controllo di quello che si sta misurando: il sensore di temperatura che ho installato, di default pubblica le temperature in gradi Celsius o in gradi Fahrenheit? Il tempo ciclo della macchina che confeziona è espresso in secondi o in decimi di secondo? E così via.

L’ideale è progettare uno stadio di post elaborazione appositamente dedicato ad uniformare le grandezze in cui i segnali sono passati al sistema di analisi, capace di identificare eventuali valori “sospetti” prima di alimentare le procedure automatiche di analisi dei dati. Ad esempio se la temperatura misurata nella sala meeting è 77°Celsius, è meglio verificare le impostazioni di fabbrica del sensore, prima di chiamare i pompieri!

 

3. Utilizzare il formato UTC per la rappresentazione dei tempi

La terza cosa da ricordare è utilizzare il formato UTC per la rappresentazione dei tempi, specialmente per chi fa monitoraggio 24/7. Molti pensano che l'uso del formato UTC sia sensato per aggregare dati provenienti da regioni del globo con diversi fusi orari, io credo che l'UTC sia un’ottima soluzione al problema dei “dati fantasma” che si verifica due giorni all’anno quando si passa dall’ora legale all’ora solare. In primavera accade che i dati arrivano fino all’ora 01:59 AM e poi riprendono alle 03:00 AM perché i computer hanno spostato l’orologio in avanti di un’ora. In autunno succede invece che i dati dalle ore 01:59 alle ore 2:59 sono doppi, perché i computer hanno spostato indietro l’orologio interno di un’ora! Il secondo caso è più subdolo del primo perché si misura capacità produttiva raddoppiata e tutti i KPI producono dati non plausibili!

Altre cose semplici si possono fare per ottenere dati di qualità e risparmiare tempo e denaro nel debug delle applicazioni di analisi e soprattutto per rendere il sistema di misura più robusto e scalabile e ne parlerò nei prossimi post.

Per approfondimenti, trovate utili informazioni ai link:
Codifica EPC: http://www.epc-rfid.info/sgtin
Standard UTC: https://www.timeanddate.com/time/aboututc.html
 


CONDIVIDI:        

Aggiungi commento

Codice di sicurezza Aggiorna

Iscriviti alla nostra newsletter

Iscriviti per ricevere i nostri aggiornamenti.

Lingua