Cos'è ISA-95 e perché è la base di un Unified Namespace

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 — è 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.

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 è 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.

Una sola normalizzazione, per tutti i consumer

Alleantia 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.

Struttura che dura, integrazioni che scalano

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.