Unified Namespace (UNS) è diventato il punto di riferimento per chiunque stia ripensando l'architettura dei dati industriali.
L'idea è convincente: un broker MQTT al centro, un unico spazio semantico condiviso, e tutti i sistemi MES, ERP, analytics, SCADA, che invece di parlarsi direttamente si collegano a quell'unico punto centrale e ricevono solo i dati di cui hanno bisogno.
In pratica, UNS non è un prodotto che si installa ma un pattern architetturale. Come ogni pattern, funziona solo se poggia su fondamenta solide. Il problema che emerge quasi sempre nelle implementazioni reali non è il broker: è la semantica.
Il motivo è strutturale: UNS fornisce un'infrastruttura di trasporto e distribuzione, ma non risolve il problema del significato. Per farlo, serve uno standard che definisca il vocabolario condiviso, le entità, le relazioni e la gerarchia che rendono i dati interpretabili allo stesso modo da qualsiasi sistema, indipendentemente da chi li ha prodotti o da quale protocollo li ha trasportati. Quello standard è ISA-95.
ISA-95, lo standard internazionale per l'integrazione tra sistemi enterprise e sistemi di controllo, fornisce un modello semantico comune, un vocabolario e una gerarchia condivisi (Enterprise → Site → Area → Line → Cell → Equipment) che consentono ai dati di mantenere un significato coerente man mano che si spostano dal piano di fabbrica ai sistemi aziendali.
Perchè ISA-95 è una scelta valida di architettura dei dati
La maggior parte dei problemi di dati industriali non sono in realtà problemi di connettività. Connettersi a un PLC o a un sensore è un problema in gran parte risolto; esistono protocolli e gateway consolidati per quasi ogni esigenza.
Il problema più difficile e costoso è semantico. Una volta connessi a un centinaio di macchine di una dozzina di fornitori diversi, come si fa a far sì che quei dati significhino la stessa cosa per chiunque ne abbia bisogno, il manutentore, il MES, l'ERP, la dashboard KPI di un plant manager e un data scientist che addestra un modello predittivo?
ISA-95 (formalmente IEC/ISA 62264) esiste per rispondere a questa domanda.
Il suo contributo principale è un vocabolario e una gerarchia condivisi: Enterprise, Site, Area, Line, Cell, Equipment, oltre a un insieme di modelli a oggetti (Equipment, Material, Process Segment, Personnel) che descrivono come le entità produttive si relazionano tra loro, indipendentemente da uno specifico fornitore, protocollo o architettura software.
Questa indipendenza è ciò che lo rende una buona base architetturale, poiché garantisce:
- Indipendenza da fornitore e protocollo. I dati di una macchina significano la stessa cosa indipendentemente dal fatto che arrivino a un'applicazione via OPC-UA, Kafka, MQTT, SQL, Modbus, e indipendentemente da quale fornitore di automazione venga utilizzato. Questo disaccoppia l'architettura dei dati dalle decisioni sul ciclo di vita degli apparati.
Una macchina, un gateway o un intero fornitore di automazione possono essere sostituiti senza dover riscrivere l'interpretazione dei dati per i sistemi a valle.
- Un linguaggio condiviso tra ruoli, non solo tra sistemi. Il vocabolario di ISA-95 offre a ingegneri OT, architetti IT e stakeholder di business un modo comune di parlare della stessa realtà produttiva, riducendo la perdita di significato che si verifica quando ciascun gruppo ricorre al proprio gergo locale.
- Una base per casi d'uso a maggior valore. Il benchmarking tra stabilimenti, il roll-up di KPI a livello enterprise e i modelli di machine learning addestrati su più linee o siti dipendono tutti da dati che significano la stessa cosa ovunque provengano. Cosa strutturalmente impossibile se "Linea 3" in uno stabilimento e "Line 3" in un altro codificano convenzioni locali incompatibili.
Nulla di tutto ciò richiede l'adozione di uno stack software o di un protocollo di trasporto specifico, ed è proprio questo il punto. ISA-95 fornisce l'impalcatura semantica; le scelte tecnologiche sottostanti restano aperte.
Alleantia Core, supporta pienamente questi principi, e va oltre garantendo una semantica standardizzata per l'intero set di dati macchina.
WHITE PAPER
Vuoi vedere come Alleantia Core normalizza i dati del tuo impianto?
Il livello semantico
ISA-95 e Sparkplug B: due standard, un problema
Il problema semantico di UNS ha in realtà due dimensioni distinte, e confonderle è uno degli errori più comuni in fase di progettazione.
La prima dimensione riguarda dove il dato vive nel namespace, ovvero la struttura dei topic MQTT.
ISA-95 risponde a questo aspetto: fornisce una gerarchia standardizzata — Enterprise, Site, Area, Line, Cell, Equipment — che funziona come vocabolario condiviso indipendente da protocollo, fornitore e architettura software.
Quando i topic MQTT seguono questa gerarchia, "temperatura forno linea 3" e Line3_Oven_T diventano Site/Milano/Area-A/Line3/Forno/Temperatura e Site/Barcellona/Area-A/Line3/Forno/Temperatura: stessa struttura, significato immediatamente leggibile da qualsiasi consumer.
La seconda dimensione è come quel dato è formato quando arriva, ovvero il payload. Ed è qui che entra Sparkplug B: il protocollo che definisce il formato standardizzato dei messaggi MQTT per ambienti industriali.
Tipi di dato espliciti, gestione del ciclo di vita dei nodi, birth e death certificate che rendono il broker la vera e unica fonte di verità sullo stato della fabbrica.
Topic strutturati secondo ISA-95 e payload formattati secondo Sparkplug B sono i due livelli che insieme rendono un'architettura UNS tecnicamente completa.
ISA-95 → struttura dei topic Gerarchia semantica standardizzata: dove ogni dato risiede nel namespace, con un significato condiviso tra sistemi, fornitori e stabilimenti.
Sparkplug B → formato del payload Messaggi MQTT strutturati con typing esplicito, birth/death certificate e gestione del ciclo di vita dei nodi: il layer che completa la semantica end-to-end.
Nessuno dei due standard impone uno stack tecnologico specifico ed è proprio questa flessibilità il punto.
Forniscono l'impalcatura semantica; le scelte architetturali specifiche restano aperte. Ma il lavoro concreto di applicare quella semantica ai dati reali — ai PLC di 15 anni fa, ai controllori CNC di fornitori diversi, ai sensori con protocolli proprietari — deve succedere da qualche parte. Deve succedere nell'edge.
Un modello semantico unico, normalizzato una volta sola nell'edge
Alleantia Core normalizza i dati macchina e di processo in una struttura semantica standardizzata attraverso il concetto di machine driver: la connessione a ogni macchina è definita da un file di configurazione standardizzato (machine driver) che struttura la telemetria del dispositivo come coppie chiave-valore.
Le chiavi (Var ID) seguono l'ordinamento definito dal machine driver, così che ogni variabile sia denominata in modo coerente per qualsiasi macchina di un determinato tipo, indipendentemente dal sistema sorgente. Ogni dispositivo connesso riceve un Device ID (Dev ID) univoco dall'Alleantia Core a cui è collegato. Ogni istanza di Alleantia Core riceve un Machine ID univoco a livello globale — entrambi, insieme a descrizioni testuali libere del dispositivo, possono essere configurati per adattarsi alle convenzioni di denominazione del cliente. Inoltre, ogni macchina connessa dispone di un nome, una descrizione e un alias, tutti pubblicati nei messaggi in uscita. Infine, ogni Alleantia Core dispone di un parametro System ID configurabile.
Questo garantisce, immediatamente e senza configurazioni aggiuntive, un'identificazione univoca e coerente di ogni variabile su ogni dispositivo connesso. Tutte le variabili vengono consegnate nei messaggi di telemetria insieme al relativo timestamp, su qualsiasi API implementata sull'IoT Gateway Alleantia Core — esistente oggi o aggiunta in futuro.
Nel complesso, questo allinea Alleantia Core ai concetti a oggetti di ISA-95 — Equipment, Material, Process Segment — mappati in modo coerente lungo tutta la gerarchia di stabilimento. Questa normalizzazione avviene una sola volta, in fase di acquisizione, anziché essere reimplementata per ogni consumer a valle: la stessa struttura semantica si riflette nel formato dei messaggi di ogni API disponibile.
L'effetto pratico: una lettura di temperatura proveniente da un PLC di 15 anni fa e un segnale diagnostico proveniente da un moderno controllore CNC arrivano nella stessa forma strutturale, con lo stesso contesto gerarchico, su ciascuna API configurata. I consumer non hanno bisogno di sapere quale protocollo o fornitore si trovi dietro i dati — solo cosa significhino.
Connettività agnostica: qualsiasi protocollo, senza toccare i sistemi certificati
La connettività a monte di Alleantia Core è agnostica rispetto a protocollo e fornitore. Integra macchine, sensori e sistemi di controllo indipendentemente dal protocollo nativo — OPC-UA, Modbus, Ethernet/IP, FOCAS, fieldbus proprietari, MQTT, REST o altro — senza richiedere modifiche al sistema di controllo sottostante.
Questo conta ben oltre la comodità. In ambienti regolamentati o certificati per la sicurezza, modificare o dover ri-validare un sistema di controllo di Livello 0-1 comporta costi e rischi di conformità. Un livello di integrazione che osserva e normalizza i dati senza toccare il sistema certificato sottostante non è solo più semplice — è spesso l'unica strada percorribile.
Coerente in uscita
Una volta normalizzato, lo stesso modello semantico viene esposto in modo uniforme su oltre 20 API a valle di Alleantia Core. MES, ERP, piattaforme di analytics e applicazioni consumer di tipo storico ricevono tutti dati con struttura e significato identici — non un diverso livello di traduzione per ogni integrazione.
Questo è il risultato pratico dell'intento di ISA-95: un unico contratto dati standardizzato che si estende a nuovi consumer senza moltiplicare lo sforzo di integrazione. Aggiungere una nuova API a un'implementazione esistente non significa ricostruire la mappatura semantica — significa riutilizzarla.
Perché questo conta per struttura e manutenibilità
Nel complesso, queste tre caratteristiche sono ciò che l'"allineamento a ISA-95" dovrebbe concretamente significare per un'architettura di integrazione:
Vale la pena essere precisi sul perimetro: ISA-95 non impone un protocollo di trasporto, un'architettura software specifica o un modello di sicurezza — la Parte 5 (B2MML) offre una serializzazione XML di riferimento, ma la maggior parte delle implementazioni reali (Core incluso) sceglie il proprio trasporto preservando l'allineamento semantico sottostante. Si tratta di una scelta deliberata e difendibile, non di una scorciatoia: mantiene l'architettura libera di adottare i protocolli effettivamente utilizzati sul campo (MQTT, OPC-UA, REST) pur continuando a parlare internamente un linguaggio comune e allineato agli standard.
WHITE PAPER
Vuoi vedere come Alleantia Core normalizza i dati del tuo impianto?
