Unified Namespace: il livello dati che sta sotto AI e digital twin

Il 28 agosto 2026 IIoT World ha pubblicato un articolo di Paul Viorel secondo cui la causa comune di molti progetti falliti di AI e digitalizzazione è il livello dati, e la risposta è l'Unified Namespace (UNS). Non è una notizia in senso stretto ma un pezzo di opinione, con forte presenza di fornitori: molte cifre sono citazioni di seconda mano o dati riportati dai vendor. Il tema, però, è concreto per chi gestisce impianti.

Il problema: dati che non arrivano in forma utilizzabile

L'articolo richiama tre numeri per descrivere lo stato dei progetti:

• il 57% dei dirigenti del manifatturiero dichiara che la scarsa qualità dei dati frena lo sviluppo di casi d'uso di AI (MIT Technology Review);
• l'85% dei progetti di trasformazione digitale non genera ROI a causa di problemi di integrazione (affermazione attribuita al CEO di ServiceNow);
• oltre il 70% dei progetti resta bloccato in fase pilota (McKinsey).

Sono cifre citate, non verificate in modo indipendente, ma l'indicazione qualitativa è familiare: i progetti si fermano sull'idraulica dei dati prima ancora che sui modelli.

Il problema N al quadrato

Nell'architettura tradizionale ispirata a ISA-95, i sistemi (PLC, SCADA, MES, ERP, CMMS, qualità, energia) sono collegati punto a punto. Con 50 sistemi si arriva fino a 2.450 collegamenti, ciascuno con la propria mappatura di protocollo e il proprio onere di manutenzione.

L'UNS propone un modello hub-and-spoke basato su un broker MQTT. Ogni sistema pubblica in uno spazio dei nomi gerarchico, ad esempio Azienda/Sito/Area/Linea/Asset, e gli altri lo consumano. Con 50 sistemi le connessioni diventano 50. Inoltre i dati mantengono il contesto, come unità di misura e gerarchia degli asset, dalla sorgente al consumatore, e i nuovi sensori possono essere individuati senza configurazione manuale.

Da fino a 2.450 collegamenti punto a punto a 50 connessioni verso un unico spazio dei nomi.

Cosa non è l'UNS

L'articolo chiarisce che l'UNS non sostituisce MES ed ERP: li affianca come livello di comunicazione. Completa anche uno storico o un data lake, che continuano a custodire i dati di addestramento e di trend. Non è nemmeno un protocollo: è un pattern architetturale. Lo stack più diffuso è MQTT con Sparkplug B, ma si usa anche l'aggregazione OPC UA.

Risultati e tempi: da leggere con cautela

I risultati riportati provengono in gran parte da fornitori:

• HighByte: ROI del 448% in tre anni e integrazione 4 volte più rapida (dati dichiarati dal vendor);
• Anexee: 40–70% di sforzo di integrazione in meno;
• aeroporto di Dallas-Fort Worth (caso HiveMQ): consumi energetici -20%, efficienza della forza lavoro +25%, perdite idriche dal 25% al 10%, intervalli di comunicazione da 6 ore a 15 minuti. È però un caso di infrastruttura, non di manifattura.

Sui tempi, Anexee, con implementazioni prevalentemente nell'industria pesante in India, indica 8–14 settimane per il primo stabilimento, 4–8 settimane per ciascuno dei successivi e 6–18 mesi per un UNS federato multi-sito. La modellazione gerarchica degli asset assorbe il 40–60% dell'impegno.

Cosa fare in pratica

Per responsabili di produzione e IT/OT, l'indicazione più utile riguarda l'ordine dei lavori. Prima di un progetto di AI o di analisi OEE conviene:

• definire la gerarchia degli asset e la convenzione dei nomi, che è la parte più onerosa;
• contestualizzare i dati alla fonte, con unità, stato e appartenenza a linea e area;
• individuare quali sistemi, tra cui MES e piattaforme di monitoraggio di linea, saranno sia publisher sia consumer;
• partire da un solo stabilimento o una sola linea e replicare il modello;
• trattare ROI e tempistiche dei vendor come ipotesi da validare in un pilota.

L'UNS non risolve da solo la qualità del dato né la governance, ma rende esplicito il lavoro di modellazione che i progetti punto a punto tendono a rimandare. È lì che, secondo l'articolo, si decide se AI e digital twin usciranno dalla fase pilota.