L'integrazione dei dati industriali presenta un problema ben noto: ogni nuova macchina, ogni nuova applicazione consumer e ogni nuovo stabilimento aggiungono un'ulteriore mappatura punto-punto da mantenere.
Nel tempo, questo trasforma la connessione di una fabbrica in una rete sempre più estesa di logiche di traduzione personalizzate, fragile, costosa da estenderee diffcile da verificare.
Unified Namespace si propone come un approccio architetturale alternativo per l’integrazione dei dati in ambito Industry 4.0 e IIoT. Ma la sua promessa si regge su un presupposto che spesso viene dato per scontato: che i dati abbiano già un significato condiviso prima di arrivare al broker.
Negli ultimi anni Unified Namespace è diventato il punto di riferimento per chiunque stia ripensando l'architettura dei dati industriali. L'idea è solida: un unico spazio semantico condiviso, un broker MQTT al centro, tutti i sistemi che si abbonano invece di parlare punto-punto. Meno cablaggio. Meno mappature personalizzate. Meno dipendenze silenziose tra sistemi che non si conoscono.
Il problema è che UNS non è un prodotto che si installa ma un pattern architetturale. E come ogni pattern, funziona solo se poggia su fondamenta solide. Il broker MQTT è il punto visibile, quello su cui si concentra quasi tutto il dibattito. Le fondamenta invisibili, quelle che determinano se il pattern funziona davvero sono altrove: nell'edge, dove i dati nascono.
Il collo di bottiglia reale in quasi tutti i progetti UNS non è il broker. È la normalizzazione semantica a monte.
Pensa a una situazione concreta. Hai due stabilimenti. Nel primo, la temperatura del forno sulla Linea 3 si chiama "temperatura forno linea 3". Nel secondo, lo stesso dato si chiama Line3_Oven_T. Entrambi arrivano al tuo broker MQTT. Entrambi, dal punto di vista del trasporto, sono messaggi perfettamente validi. Ma per qualsiasi sistema consumer — un MES, una dashboard KPI, un modello predittivo — sono due cose diverse, da trattare separatamente, da riconciliare manualmente. Il problema del silos si è semplicemente spostato un livello più in alto.
Il livello semantico
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 è dove il dato vive nel namespace — la struttura dei topic MQTT. ISA-95 (formalmente IEC/ISA 62264) risolve questo: definisce 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 — 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.
Nessuno dei due standard impone uno stack tecnologico specifico — è 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.
Come Alleantia Core rispondeAlleantia Core risolve il problema semantico una volta sola, a livello edge, prima che i dati raggiungano qualsiasi consumer.
Il meccanismo centrale è il machine driver: ogni connessione a una macchina è definita da un file di configurazione standardizzato che struttura la telemetria come coppie chiave-valore con una gerarchia fissa — System ID → Machine ID → Device ID → Var ID. Questa struttura non è solo identificazione univoca: è una gerarchia semantica che si mappa direttamente sui livelli ISA-95, e quando il trasporto è MQTT si traduce naturalmente in topic compatibili con le convenzioni Sparkplug B.
Il risultato pratico: una lettura di temperatura da un PLC del 2008 e un segnale diagnostico da un moderno controllore CNC arrivano nella stessa forma strutturata, con lo stesso contesto gerarchico, su ogni API configurata a valle. MES, ERP, piattaforme analytics, storici — tutti ricevono dati con struttura e significato identici. Nessun layer di traduzione aggiuntivo per ogni nuova integrazione.
L'adozione di ISA-95 come base semantica ha un costo iniziale reale. La mappatura punto-punto, invece, non ha un costo iniziale evidente — ma paga una tassa continua ogni volta che si aggiunge una macchina, si cambia un fornitore o si vuole portare i dati in un nuovo sistema. Quella tassa si aggrava nel tempo, e diventa insostenibile nel momento in cui il progetto scala da uno stabilimento a cinque.
Il confronto tra stabilimenti, il roll-up di KPI a livello enterprise, i modelli di machine learning addestrati su più linee o siti — tutti questi casi d'uso dipendono da dati che significano la stessa cosa ovunque provengano. Strutturalmente impossibile con convenzioni locali incompatibili. Strutturalmente scontato con una semantica normalizzata a monte.
Alleantia Core è progettato per operare in questo ecosistema: mantiene la libertà di adottare i protocolli effettivamente usati sul campo, continuando a parlare internamente un linguaggio comune, allineato agli standard e pronto per qualsiasi architettura a valle — UNS incluso.