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 estendere e difficile da verificare.
Unified Namespace (UNS) è diventato il punto di riferimento per chiunque stia ripensando l'architettura dei dati industriali.
L'idea è convincente: un broker MQTT al centro, un unico spazio semantico condiviso, e tutti i sistemi MES, ERP, analytics, SCADA, che invece di parlarsi direttamente si collegano a quell'unico punto centrale e ricevono solo i dati di cui hanno bisogno.
In pratica, UNS non è un prodotto che si installa ma un pattern architetturale. Come ogni pattern, funziona solo se poggia su fondamenta solide.
Il problema che emerge quasi sempre nelle implementazioni reali non è il broker: è la semantica.
Il motivo è strutturale: UNS fornisce un'infrastruttura di trasporto e distribuzione, ma non risolve il problema del significato. È qui che ISA-95 diventa il layer che trasforma UNS da semplice broker a sistema davvero efficace: fornisce il vocabolario, la gerarchia e le relazioni che rendono i dati interpretabili allo stesso modo da qualsiasi sistema.
ISA-95, lo standard internazionale per l'integrazione tra sistemi enterprise e sistemi di controllo, fornisce un modello semantico comune, un vocabolario e una gerarchia condivisi (Enterprise → Site → Area → Line → Cell → Equipment) che consentono ai dati di mantenere un significato coerente man mano che si spostano dal piano di fabbrica ai sistemi aziendali.
La maggior parte dei problemi di dati industriali non sono in realtà problemi di connettività. Connettersi a un PLC o a un sensore è un problema in gran parte risolto; esistono protocolli e gateway consolidati per quasi ogni esigenza.
Il problema più difficile e costoso è semantico. Una volta connessi a un centinaio di macchine di una dozzina di fornitori diversi, come si fa a far sì che quei dati significhino la stessa cosa per chiunque ne abbia bisogno, il manutentore, il MES, l'ERP, la dashboard KPI di un plant manager e un data scientist che addestra un modello predittivo?
ISA-95 (formalmente IEC/ISA 62264) esiste per rispondere a questa domanda.
Il suo contributo principale è un vocabolario e una gerarchia condivisi: Enterprise, Site, Area, Line, Cell, Equipment, oltre a un insieme di modelli a oggetti (Equipment, Material, Process Segment, Personnel) che descrivono come le entità produttive si relazionano tra loro, indipendentemente da uno specifico fornitore, protocollo o architettura software.
Questa indipendenza è ciò che lo rende una buona base architetturale, poiché garantisce:
Nulla di tutto ciò richiede l'adozione di uno stack software o di un protocollo di trasporto specifico, ed è proprio questo il punto. ISA-95 fornisce l'impalcatura semantica; le scelte tecnologiche sottostanti restano aperte.
Alleantia Core, supporta pienamente questi principi, e va oltre garantendo una semantica standardizzata per l'intero set di dati macchina.
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 riguarda dove il dato vive nel namespace, ovvero la struttura dei topic MQTT.
ISA-95 risponde a questo aspetto: fornisce 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, ovvero 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.
Nessuno dei due standard impone uno stack tecnologico specifico ed è 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.
Vediamo come questi principi si traducono in pratica. Alleantia Core è il layer edge che applica concretamente la semantica ISA-95: normalizza i dati macchina e di processo in una struttura standardizzata attraverso il concetto di machine driver.
La connessione a ogni macchina è definita da un file di configurazione standardizzato (machine driver) che struttura la telemetria del dispositivo come coppie chiave-valore.
Le chiavi (Var ID) seguono l'ordinamento definito dal machine driver, così che ogni variabile sia denominata in modo coerente per qualsiasi macchina di un determinato tipo, indipendentemente dal sistema sorgente. Ogni dispositivo connesso riceve un Device ID (Dev ID) univoco dall'Alleantia Core a cui è collegato. Ogni istanza di Alleantia Core riceve un Machine ID univoco a livello globale — entrambi, insieme a descrizioni testuali libere del dispositivo, possono essere configurati per adattarsi alle convenzioni di denominazione del cliente. Inoltre, ogni macchina connessa dispone di un nome, una descrizione e un alias, tutti pubblicati nei messaggi in uscita. Infine, ogni Alleantia Core dispone di un parametro System ID configurabile.
Questo garantisce, immediatamente e senza configurazioni aggiuntive, un'identificazione univoca e coerente di ogni variabile su ogni dispositivo connesso. Tutte le variabili vengono consegnate nei messaggi di telemetria insieme al relativo timestamp, su qualsiasi API implementata sull'IoT Gateway Alleantia Core — esistente oggi o aggiunta in futuro.
Nel complesso, questo allinea Alleantia Core ai concetti a oggetti di ISA-95 — Equipment, Material, Process Segment — mappati in modo coerente lungo tutta la gerarchia di stabilimento. Questa normalizzazione avviene una sola volta, in fase di acquisizione, anziché essere reimplementata per ogni consumer a valle: la stessa struttura semantica si riflette nel formato dei messaggi di ogni API disponibile.
L'effetto pratico: una lettura di temperatura proveniente da un PLC di 15 anni fa e un segnale diagnostico proveniente da un moderno controllore CNC arrivano nella stessa forma strutturale, con lo stesso contesto gerarchico, su ciascuna API configurata. I consumer non hanno bisogno di sapere quale protocollo o fornitore si trovi dietro i dati — solo cosa significhino.
La connettività a monte di Alleantia Core è agnostica rispetto a protocollo e fornitore. Integra macchine, sensori e sistemi di controllo indipendentemente dal protocollo nativo — OPC-UA, Modbus, Ethernet/IP, FOCAS, fieldbus proprietari, MQTT, REST o altro — senza richiedere modifiche al sistema di controllo sottostante.
Questo conta ben oltre la comodità. In ambienti regolamentati o certificati per la sicurezza, modificare o dover ri-validare un sistema di controllo di Livello 0-1 comporta costi e rischi di conformità. Un livello di integrazione che osserva e normalizza i dati senza toccare il sistema certificato sottostante non è solo più semplice — è spesso l'unica strada percorribile.
Una volta normalizzato, lo stesso modello semantico viene esposto in modo uniforme su oltre 20 API a valle di Alleantia Core (MQTT/Sparkplug B, OPC-UA, REST, SQL e connettori diretti verso MES e piattaforme di analytics) così che MES, ERP, storici e dashboard ricevano tutti dati con struttura e significato identici, senza un livello di traduzione dedicato per ogni integrazione.
Questo è il risultato pratico dell'intento di ISA-95: un unico contratto dati standardizzato che si estende a nuovi consumer senza moltiplicare lo sforzo di integrazione. Aggiungere una nuova API a un'implementazione esistente non significa ricostruire la mappatura semantica — significa riutilizzarla.
Nel complesso, queste tre caratteristiche sono ciò che l'"allineamento a ISA-95" dovrebbe concretamente significare per un'architettura di integrazione: