Standardizzazione semantica dei dati: ruolo di metadati e mappatura dei tag

Dati di macchine diverse che non si possono confrontare, analisi che richiedono settimane di preparazione manuale, nuove macchine che ogni volta ripartono da zero. Dietro questi problemi c’è spesso un’unica causa: dati senza un linguaggio comune. In questo articolo vediamo come metadati, naming convention e mappatura dei tag rendono i dati di fabbrica confrontabili e pronti per l’analisi, dal Programmable Logic Controller (PLC) fino all’edge.

Lo stesso dato, cento nomi diversi

Ogni stabilimento misura pressioni e temperature, ma raramente le chiama allo stesso modo. Quando i programmatori PLC nominano le variabili in piena libertà, senza alcuno standard condiviso, lo stesso dato finisce per avere cento nomi diversi. Il risultato è che i dati di linee e stabilimenti diversi restano incomparabili.

In questo articolo affrontiamo il tema dal lato tecnico: naming, metadati e modelli semantici. La parte organizzativa, cioè governance, ruoli e responsabilità, è nell’articolo su data strategy e governance del dato: qui la richiamiamo soltanto, senza ripeterla.

1. Cos’è la standardizzazione semantica dei dati industriali

La standardizzazione dei dati consiste nel dare ai dati nomi, unità di misura e significati comuni, così che sistemi e persone li interpretino allo stesso modo. Non coincide con la normalizzazione: normalizzare vuol dire portare i valori a un formato o a una scala uniforme (per esempio convertire tutte le pressioni in bar). Standardizzare a livello semantico significa definire regole valide per tutte le macchine su nome, unità, significato e struttura del dato.

Con dati descritti nello stesso modo, aggiungere, spostare o sostituire una macchina diventa più semplice, ed è una delle basi della riconfigurabilità industriale.

2. Il problema dei nomi: tag eterogenei tra PLC, linee e stabilimenti

Nella pratica ogni programmatore PLC è libero di nominare le variabili, sia interne che di scambio dati verso l’esterno,  come preferisce, e spesso lo fa. La stessa temperatura di processo può chiamarsi T_PROC su una macchina e Temperatura_Forno_Zona1 su un’altra. Il problema non riguarda solo i nomi:

• Famiglie di macchine che non si parlano. Due macchine della stessa famiglia, una più recente dell’altra, possono non condividere nulla nella struttura dei dati pur avendo molti dati in comune.

• Indirizzamento casuale in S7. Nella programmazione Siemens S7 la scelta tra differenti aree di memoria per memorizzare gli stessi tipi di dato è spesso arbitraria, quindi lo stesso dato vive in spazi diversi da una macchina all’altra.

• Identificatori OPC UA scelti a caso. I NodeId possono essere numerici oppure stringa, senza un criterio comune.

• Variabili difficili da trovare. Se una variabile non è identificata correttamente, riconoscerla nell’address space di un client OPC UA come UaExpert diventa una ricerca per tentativi.

• Unità e decimali non uniformi. La stessa grandezza può essere espressa in bar o in psi, e la temperatura può arrivare come intero o con 1 decimale.

Un esempio illustrativo di come questi aspetti si combinano su due macchine della stessa famiglia:

La causa radice è sempre la stessa: la mancanza di standardizzazione interna. Senza regole comuni, i dati non sono confrontabili tra macchine, linee e stabilimenti.

3. Metadati: cosa sono e quali servono in fabbrica

I metadati sono le informazioni che descrivono il dato: dicono che cosa rappresenta un valore, come è espresso, a quale asset appartiene e da dove arriva.

Eppure la documentazione è spesso il punto debole. Di frequente il programmatore PLC non fornisce né un documento con i metadati né una descrizione di ogni variabile, e si limita a inviare uno screenshot del progetto, per esempio da TIA Portal. Uno screenshot non è documentazione utile: non è interrogabile, non è versionabile, non è leggibile da un sistema e soprattutto non contiene il significato dei dati. Vediamo i metadati indispensabili.

Unità di misura e scala

Serve per evitare che 6 sia letto come 6 bar su una macchina e 6 psi su un’altra. Insieme all’unità vanno indicati la scala, il numero di decimali, il tipo di dato e il range minimo e massimo: è così che un sistema sa se un valore è plausibile e come confrontarlo con quello di un’altra macchina.

Contesto dell’asset

Un tag deve dire a quale asset appartiene: la macchina, la linea, lo stabilimento. Una temperatura ha senso solo se si sa di quale forno e di quale linea si parla. Qui rientrano anche nome e descrizione della variabile.

Qualità e provenienza del dato

Per fidarsi di un dato bisogna sapere da dove viene: l’indirizzo sorgente nel PLC, il tipo di identificatore OPC UA e la modalità di accesso (lettura o scrittura).

4. Mappatura dei tag: il metodo passo per passo

La mappatura dei tag associa ogni variabile sorgente di un impianto a un tag standard con nome, unità e significato definiti.

1. Censire i tag esistenti. Si parte esportando le tag table dai PLC: è l’inventario reale di ciò che esiste.

2. Definire il documento di standard. Un data dictionary, o specifica dei tag, che descrive metadati e struttura standard da applicare a tutte le macchine.

3. Allineare unità, scala e decimali per ogni grandezza, ad esempio un’unica unità di misura per la pressione.

4. Fissare la regola di nomenclatura (naming convention).

5. Collocare i tag nel modello gerarchico ad asset.

6. Mappare e verificare: associare ogni tag sorgente al tag standard e controllare il risultato, per esempio navigando l’address space con un client come UaExpert.

Il documento di standard come requisito. Il data dictionary non va compilato a posteriori: va fornito ai programmatori PLC e ai costruttori fin dall’inizio del progetto, per esempio nel capitolato, in un formato strutturato e leggibile da sistemi, come un file tabellare o l’export delle tag table dal PLC. Per ogni variabile può contenere:

• nome secondo la naming convention e descrizione;

• tipo di dato, unità di misura, scala e numero di decimali;

• range minimo e massimo;

• asset di appartenenza e modalità di accesso (lettura/scrittura);

• indirizzo sorgente nel PLC e tipo di identificatore OPC UA da usare.

I vantaggi sono concreti: meno ambiguità, onboarding più rapido di nuove macchine, confronto diretto tra macchine vecchie e nuove della stessa famiglia e una base solida per la mappatura dei tag e per i modelli semantici.

Naming convention

La naming convention è la regola che stabilisce come si scrive il nome di un tag: quali elementi contiene, in che ordine e con quale formato. Deve essere unica, documentata e applicata a tutte le macchine, così che lo stesso dato abbia sempre lo stesso nome.

Modello gerarchico ad asset

Il modello gerarchico organizza i tag secondo la struttura dell’impianto: stabilimento, linea, macchina, componente. Ogni tag trova così una posizione prevedibile.

5. Modelli semantici e standard (OPC UA Information Model, Asset Administration Shell)

OPC UA Information Model. Definisce tipi di oggetto e relazioni standard nell’address space di OPC UA, così che macchine diverse espongano la stessa struttura. Conviene quando sistemi e fornitori diversi devono leggere gli stessi dati.

Asset Administration Shell (AAS). È la rappresentazione standardizzata di un asset in ambito Industria 4.0: raccoglie in modo strutturato le informazioni che lo descrivono. Conviene quando l’asset deve essere descritto e scambiato lungo tutta la filiera, oltre i confini del singolo stabilimento.

Non è necessario partire da qui: un buon data dictionary e una naming convention solide sono la base su cui questi modelli si innestano. Per approfondire il tema dell’integrazione, leggi l’articolo su API e interoperabilità.

6. Standardizzare all’edge con Mirai4UniversalEdge

Un ulteriore aspetto da non sottovalutare è la standardizzazione a livello Edge. 
Sempre più spesso sistemi edge vengono utilizzati come data Gateway o per fare pre-processing e inferenze prima di inviare dati verso sistemi di più alto livello.

In scenari in cui non sia possibile agire direttamente sulla fonte dati per la Standardizzazione semantica il livello edge diventa in candidato naturale per questo processo. Acquisendo dati da fonti disomogenee permette di processarli e arricchirli con tutto il necessario per renderli fruibili nel punto più vicino alla macchina stessa.

E’ inoltre importante considerare che anche tutti i dati generati da sistemi di pre-processing, inferenza, tracciabilità e in generale ogni algoritmo applicato a livello edge sono anche loro dati e devono quindi seguire le buone pratiche descritte per quanto riguarda i dati direttamente il PLC.

E’ quanto avviene con sistemi Edge come Mirai4UniversalEdge, che oltre a offrire un sistema di orchestrazione del processo e tracciabilità del sistema permette di acquisire, elaborare e contestualizzare dati direttamente dal PLC. 

7. Un linguaggio comune per i dati di fabbrica

Metadati e mappatura dei tag trasformano nomi arbitrari in un linguaggio comune: i dati diventano confrontabili tra macchine, linee e stabilimenti, e pronti per l’analisi e per l’IA. Anche la storicizzazione in un time series database ne risulta più semplice.

Vuoi capire a che punto sono i tag del tuo impianto? Prenota un assessment dei tag con un esperto Miraitek o richiedi una demo di Mirai4UniversalEdge.

FAQ

Che differenza c’è tra normalizzazione e standardizzazione dei dati?

La normalizzazione porta i valori a un formato o a una scala uniforme. La standardizzazione definisce regole comuni su nomi, unità, significati e struttura, valide per tutte le macchine.

Da dove si parte per mappare i tag di un impianto?

Dal censimento dei tag esistenti, esportando le tag table dai PLC. Su quell’inventario si costruiscono il documento di standard e la naming convention.

I metadati servono anche per l’IA?

Sì. Per usare dati di macchine diverse un modello deve sapere cosa rappresenta ogni valore, in quale unità è espresso e a quale asset appartiene. Senza metadati serve una preparazione manuale prima di ogni analisi.