Industry 4.0
Product News
AI
Perché il costo di un Unified Namespace scala "male"
Lo Unified Namespace (UNS) viene spesso presentato come un modo naturale e facile da implementare per realizzare una semantica unificata dei dati di macchine e sensori.
UNS realizza il modello con un unico backbone event-driven, tipicamente costruito su MQTT e Sparkplug B, che collega i dispositivi di fabbrica (OT) alle applicazioni dell'azienda (IT) utilizzando una struttura dei topic con una specifica naming convention e gerarchia in stile ISA-95.
Per un singolo stabilimento o un deployment pilota, con un numero ridotto di macchine e applicazioni, questa proposta regge nella maggior parte dei casi.
Contesto - La tesi di questo documento è che lo UNS pone limitazioni, vincoli e, col tempo, complessità e costi reali quando viene utilizzato su scala aziendale, e questi costi crescono continuamente man mano che l'implementazione OT/IT cresce.
Non si afferma qui che il concetto di base dell'UNS sia sbagliato in linea di principio. Si afferma piuttosto che il meccanismo di partenza (topic MQTT e naming convention, eventualmente strutturate tramite Sparkplug B), su cui poi si basano la maggior parte delle implementazioni "UNS", comporta una complessità, un modello operativo e un costo che scala in modo non favorevole proprio quando serve, ovvero quando il numero di siti, il numero di macchine, i sistemi legacy, le business unit e i confini organizzativi aumentano.
La causa di fondo: semantica applicativa portata a livello di trasporto
Il contributo reale di ISA-95 (Parti 1, 2 e 4) è un modello semantico indipendente dal trasporto: una gerarchia (Enterprise → Site → Area → Line → Cell) e un insieme di relazioni tra oggetti (Equipment, Material, Process Segment) pensati per mantenere il proprio significato indipendentemente da come vengono veicolati.
(img- 1) La gerarchia funzionale ISA-95 (Purdue Model): dal processo fisico alla pianificazione aziendale, con le scale temporali tipiche di ciascun livello.
La Parte 5 di ISA-95 (B2MML) definisce una serializzazione XML di riferimento, ma nulla nello standard privilegia uno specifico protocollo di trasporto.
La maggior parte delle implementazioni UNS non preserva invece questa separazione fra "modello" e "comunicazione". La denominazione e la gerarchia vengono espresse come topic MQTT [2]. Sparkplug B viene considerato per maggiore rigore, con una stringa di topic fissa e vincolata, con un numero limitato di elementi [1].
Si tratta in tutta evidenza di un "downgrade", da modello semantico ad un "indirizzo" di un trasporto specifico [7]. Funziona su scala limitata, ma il suo costo e i suoi vincoli crescono con la dimensione dell'implementazione e dell'azienda.
Cinque categorie di costo UNS e come crescono
1. Costo della governance.
MQTT non impone alcuno schema: le stringhe dei topics sono convenzioni, non specifiche, per cui la coerenza dipende interamente dalla disciplina documentale e non dà alcuna garanzia strutturale [2]. Le analisi sui rollout aziendali di UNS sono chiare su dove questo fallisce: lo UNS non è sufficiente a garantire la portabilità dei dati fra applicazioni aziendali, proprio a causa di una governance limitata, dell'assenza di contratti dati standardizzati e della titolarità "condivisa" tra IT (che "governa" le infrastrutture e quindi i broker MQTT) e OT (che "governa" le macchine e quindi i loro dati) [4]. Un pilota su un singolo sito e magari un solo reparto coinvolge un solo team e una limitata necessità di naming. Un'azienda con venti siti ha venti storie diverse e nessun meccanismo strutturale che le costringa a convergere. Il costo di riconciliazione è combinatorio, non lineare, rispetto al numero di siti.
2. Lo "UNS basato su MQTT" richiede integrazioni aggiuntive.
Un'analisi rigorosa di ciò che un UNS richiede effettivamente individua cinque capacità necessarie: un namespace gerarchico, publish/subscribe in tempo reale, persistenza e replay, request/reply, e federazione sicura multi-sito, e afferma chiaramente che un semplice broker MQTT standard copre in modo solido solo le prime due. La federazione sicura multi-sito, in particolare, viene identificata come la capacità che determina se uno UNS resti un progetto di singolo stabilimento o diventi una vera capacità aziendale, ed è esplicitamente indicata come l'elemento più comunemente rimandato finché non diventa costoso. In altre parole, le parti di "UNS" semplici ed economiche sono esattamente quelle che non scalano a livello aziendale, mentre le parti che scalano a livello aziendale non sono disponibili di serie e sono particolarmente onerose da implementare [5].
3. Moltiplicazione della topologia dei broker e dei costi infrastrutturali.
I deployment aziendali richiedono tipicamente broker locali per ogni sito, collegati selettivamente a un broker centrale d'azienda, un approccio che a sua volta richiede una piattaforma per gestire la ripubblicazione tra i livelli, introdotta esplicitamente come onere operativo aggiuntivo. Aggiungendo il clustering ad alta disponibilità dei broker, la segmentazione di rete OT/DMZ per ogni sito, e l'autenticazione e cifratura cross-site, la spesa infrastrutturale scala con il numero di siti, indipendentemente da qualsiasi lavoro di modellazione dati. Il sintomo onestamente riportato quando questo non viene preventivato: collisioni di topic, modelli di sito incoerenti e collegamenti fragili tra broker [6].
4. Il costo organizzativo cresce con il numero di team e sistemi legacy coinvolti.
La governance aziendale dello UNS richiede una titolarità cross-funzionale, perché né l'IT né l'OT possono definirla e gestirla da soli: l'OT comprende le macchine e i processi, l'IT porta competenze di rete, identità e sicurezza, e i responsabili di business definiscono quali dati devono fluire e perché [3]. Questo costo di coordinamento è grosso modo proporzionale al numero di business unit, stabilimenti e sistemi legacy coinvolti, esattamente dove le aziende più grandi sono strutturalmente svantaggiate rispetto a un pilota su singolo sito.
5. Vincoli strutturali di Sparkplug.
Lo spazio dei topic di Sparkplug ha un numero limitato e fisso di elementi, e le linee guida per gli sviluppatori avvertono già che si può esaurire lo spazio disponibile per mappare l'intera gerarchia ISA-95 che una specifica azienda necessita. La soluzione documentata (il "metodo Parris") comprime più livelli gerarchici in un unico campo stringa utilizzando un delimitatore personalizzato. Funziona, ma ogni sottoscrittore deve poi scomporre quella stringa e ripubblicarla in una struttura di topic espansa per recuperare la gerarchia; senza una convenzione di delimitatore standardizzata, ogni applicazione dovrebbe altrimenti essere codificata rigidamente sulla specifica gerarchia esposta dal broker a cui si connette. Un deployment poco profondo se ne accorge a malapena. Un'azienda con gerarchie profonde (Enterprise → Business Unit → Site → Area → Line → Cell → Equipment → Variable) esaurisce prima gli elementi nativi dei topic, necessita prima della soluzione alternativa, e paga il costo di parsing e ripubblicazione a ogni livello aggiuntivo e a ogni ulteriore applicazione consumer.
Perché parliamo di costi di UNS, non costi di ISA-95
Nessuna delle cinque categorie di costo sopra indicate è richiesta da ISA-95 in sé. ISA-95 non impone un broker, una topologia di federazione, una specifica di schema del payload, o un modello di governance. Definisce esclusivamente una gerarchia semantica e un insieme di relazioni tra oggetti, lasciando il meccanismo di comunicazione e l'implementazione completamente liberi. Le categorie di costo sopra descritte sono una conseguenza della scelta specifica di MQTT e Sparkplug B come meccanismo per esprimere quella gerarchia, non una conseguenza del perseguire l'allineamento a ISA-95 in quanto tale.
Una grande azienda che adotta "lo UNS per essere allineata a ISA-95" sta quindi sottoscrivendo un programma di infrastruttura e governance specifico per una tecnologia e un protocollo che ISA-95 non ha mai richiesto. La curva di costo di quel programma diventa più ripida esattamente man mano che aumentano la dimensione dell'azienda, il numero di siti e la profondità della gerarchia. Questo è l'opposto di ciò che dovrebbe accadere con uno standard il cui scopo dichiarato è l'integrazione a livello aziendale: il meccanismo scelto per implementarlo non dovrebbe diventare più costoso, più fragile e più dipendente da soluzioni alternative man mano che cresce l'azienda che è destinato a servire.
L'alternativa: semantica indipendente dal protocollo
Una lettura asettica di ISA-95 suggerisce un'architettura diversa: mantenere il modello di naming e semantica in un livello a oggetti indipendente dal protocollo (un registro o uno schema con identificatori e relazioni stabili, possibilmente governato da una singola funzione aziendale es. OT) e trattare qualsiasi trasporto OT/IT specifico (MQTT, OPC-UA PubSub, Kafka, REST, o qualunque cosa arrivi in futuro) come una delle possibili proiezioni di quel modello, non come la sua fonte di verità. Con questa architettura, aggiungere un nuovo sito non moltiplica le necessità di governance; cambiare o aggiungere un'applicazione con una diversa interfaccia non richiede di ricostruire il livello di naming, e la profondità della gerarchia non è limitata dai vincoli di un singolo protocollo, perché il modello semantico è espresso in altri elementi.
Perché Alleantia Core evita questi costi
L'approccio di Alleantia Core all'identità di dispositivi e variabili è un'istanza pratica dell'alternativa descritta sopra, ed è utile spiegarlo in modo concreto, perché si mappa direttamente sulle cinque categorie di costo, anziché limitarsi ad affermare una filosofia diversa.
Alleantia Core stabilisce l'identità una sola volta, in un livello di configurazione indipendente dal protocollo, non all'interno dello schema di indirizzamento di un trasporto. Ogni dispositivo connesso porta un Device ID univoco, ogni istanza gateway/macchina porta un Machine ID univoco a livello globale, e ogni variabile porta un Var ID definito dal machine driver. È fondamentale che questi identificatori, insieme a descrizioni testuali libere e alias dei dispositivi, siano configurabili, in modo che la gerarchia in stile ISA-95 del cliente (Enterprise, Site, Area, Line, Cell) possa essere incorporata direttamente nei nomi dei dispositivi, negli alias e nella denominazione dei gateway già in fase di configurazione, anziché essere ricostruita successivamente a partire da una stringa di topic.
Poiché questa identità risiede nel modello dati stesso, lo stesso payload pienamente contestualizzato (che porta Var ID, Device ID, Machine ID ed eventuali metadati di gerarchia configurati) viene consegnato in modo identico su ogni API esposta da Core: MQTT, REST, accesso SQL/database, Kafka, Azure Event Hub e altre. L'identità semantica viaggia con il dato, non con il trasporto.
Rapportato alle cinque categorie di costo sopra descritte, questo cambia l'economia su scala, non solo la filosofia:
- L'onere di governance non peggiora con il numero di siti.
La gerarchia viene configurata una sola volta per dispositivo/gateway al momento della connessione, non ricostruita a ritroso da convenzioni di topic che divergono tra i siti. Aggiungere il ventunesimo sito non richiede di riconciliare venti storie di denominazione diverse, richiede di configurare gli identificatori in modo coerente con i primi venti. - Nessun tetto sugli elementi di topic.
Poiché gerarchia e identità risiedono in campi di payload strutturati anziché in segmenti di stringa concatenati all'interno di un percorso di topic specifico per un trasporto, non esiste alcun limite in stile Sparkplug al numero di livelli gerarchici rappresentabili, né serve alcuna soluzione basata su delimitatori man mano che la profondità aumenta. - Nessuna federazione per preservare l'identità tra i siti.
Poiché ogni gateway porta già un Machine ID univoco a livello globale e ogni dispositivo un Device ID univoco, lo spostamento o l'aggregazione dei dati tra broker, siti o trasporti non rischia sovrapposizioni o collisioni come invece accade collegando alberi di topic locali governati in modo indipendente. - Aggiungere o cambiare trasporto non richiede di ricostruire il naming.
Che l'architettura del cliente richieda MQTT, Kafka, Azure Event Hub, accesso SQL diretto o un'integrazione REST, l'identità e la semantica dei dispositivi resta invariata. Questa è la differenza pratica e diretta tra trattare una stringa di topic come il modello semantico, e trattarla come una delle possibili proiezioni di un modello che esiste in modo indipendente.
In breve: dove le implementazioni UNS pagano tipicamente un costo ricorrente per mantenere la denominazione coerente all'interno di una convenzione vincolata al trasporto, il modello di Alleantia Core evita questo costo in modo strutturale, tenendo la convenzione fuori dal trasporto fin dall'inizio.
Fonti
1. HiveMQ — Implementing Unified Namespace (UNS) With MQTT Sparkplug — documenta i limiti sugli elementi di topic di Sparkplug e la soluzione del metodo Parris.
2. FlowFuse — MQTT vs OPC UA: Which One Should You Use? — "i namespace dei topic sono convenzioni, non specifiche."
3. IIoT World — How to Standardize a Unified Namespace — assenza di uno standard UNS universale; necessità di governance cross-funzionale.
