Unified Namespace spiegato in italiano:cos'è, quando serve, quando no

Nel progetto su cui sto lavorando l'impianto è nuovo, e quasi ogni trimestre arrivano una o due macchine da integrare. Nessuna è uguale alla precedente. Una parla OPC UA, una FINS, una è un PLC Siemens SIMATIC. Una scrive un CSV per ogni pezzo lavorato, un'altra un file di testo. Una espone un socket TCP/IP, l'ultima un'API REST. Ogni volta c'è qualcosa di nuovo.

Se ogni macchina nuova obbligasse a toccare tutti i sistemi che ne usano i dati, ogni trimestre si rifarebbe mezzo progetto. Quello che lo tiene in piedi è semplice da dire: per ogni macchina c'è un adattatore che parla la sua lingua, e un mapper che riporta tutto a un oggetto standard. Da lì in poi, per il resto del sistema, una macchina vale l'altra.

È questa l'idea dietro l'Unified Namespace, e quando progetto un middleware industriale ci ragiono già dall'inizio, anche se c'è una sola macchina. In italiano se ne parla poco, e in inglese ne scrivono soprattutto i vendor di broker e piattaforme. Provo a spiegarlo come lo uso io.

01Cos'è

Un Unified Namespace (UNS) è una ricetta di comunicazione comune. Macchine e software diversi si scambiano informazioni secondo le stesse regole, sia in lettura sia in scrittura.

In pratica c'è un punto centrale, di solito un broker MQTT. Ogni sistema pubblica lì quello che sa e si abbona a quello che gli serve. Le informazioni hanno un indirizzo che dice da dove vengono e di cosa parlano. Per esempio:

stabilimento-a/assemblaggio/linea-2/avvitatrice-01/stato
stabilimento-a/assemblaggio/linea-2/avvitatrice-01/allarmi
stabilimento-a/assemblaggio/linea-2/ordine/richiesta

Il vantaggio non è il broker. È che chi acquisisce i dati non deve conoscere tutti i sistemi che li useranno, e chi li consuma non deve conoscere le particolarità di ogni macchina. Gli accoppiamenti tra i componenti si riducono, e aggiungere una macchina o un sistema diventa un lavoro locale invece di una modifica a catena.

02Cosa non è

03ISA-95 sì, ma non a macchinetta

La struttura degli indirizzi di solito ricalca la gerarchia di ISA-95: stabilimento, area, linea, macchina. È un ottimo punto di partenza, e lo standard è stato aggiornato di recente: la Parte 1 è stata rivista ad aprile 2025.

L'errore è applicarlo in modo meccanico. Prima guardo il contesto: i sistemi coinvolti, le informazioni da scambiare, le logiche da implementare. Poi adatto la convenzione al progetto. Conta che sia chiara e condivisa: chiunque deve capire dove si trova un'informazione e come va interpretata, senza una gerarchia più profonda del necessario.

04Stesse regole, non stesso posto

{
  "tipo": "telemetria",
  "workcenter": "linea-2/avvitatrice-01",
  "istante": "2026-11-03T08:15:02Z",
  "dati": {
    "coppia_nm": 12.4,
    "esito": "ok"
  }
}

Questo non vuol dire salvare tutto nello stesso posto, né dare a tutto lo stesso ciclo di vita. Ordini, ricette, allarmi e telemetria seguono lo stesso modello di comunicazione, ma ognuno con la sua gestione.

05MQTT o Sparkplug B

Sparkplug B l'ho studiato per interesse, ma non l'ho mai implementato in un progetto. Non è sbagliato: quando controllo io l'architettura e gli interlocutori, semplicemente non aggiungo vincoli senza un beneficio concreto.

06Quanto costruire

Introduco una struttura comune anche con una sola macchina. Oggi è una, domani possono essere dieci, e con buone fondamenta si cresce senza rifare tutto.

07Quando il broker non c'è

L'acquisizione deve dipendere il meno possibile dal broker e dai sistemi a valle. Se il broker non risponde, continuo a raccogliere i dati dalle macchine, nei limiti delle risorse, e gestisco in locale ciò che non richiede una risposta esterna. Per gli eventi che non posso perdere c'è un buffer persistente, con il recupero al ritorno della connessione.

Non tutto però può andare avanti. Non posso confermare un cambio d'ordine o una rischedulazione se il sistema che deve rispondere non è raggiungibile. Il guasto va gestito senza perdere informazioni e senza fingere che un'operazione sia andata a buon fine. Ne ho scritto in La rete cade, la linea no.

08L'errore più comune

Pensare che un UNS sia semplice e immediato. Prima vanno raccolti i requisiti: chi sono gli interlocutori, quali informazioni si scambiano, quali logiche vanno supportate. Solo dopo si definiscono la struttura e le regole.

Altrimenti si ottiene una struttura formalmente ordinata che non risolve niente. I sistemi restano dipendenti, i dati mantengono significati diversi, le eccezioni si accumulano nel middleware.

Da fuori sembra tutto in ordine: un punto solo, cavi puliti. Basta aprire il coperchio.

Il groviglio non è sparito: è stato spostato in un posto solo.