Alleantia Core
e ISA-95

Le basi per un'integrazione di fabbrica strutturata e manutenibile

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 estenderee diffcile da verificare. Unified Namespace è diventato il termine di riferimento per chiunque stia ripensando l'architettura dei dati industriali. L'idea è convincente: un unico spazio semantico condiviso, un broker MQTT al centro, tutto il resto che si abbona. Niente più integrazioni punto-punto, niente più mappature personalizzate per ogni coppia sistema-sistema.

Ma UNS non è un prodotto che si installa, è un pattern architetturale. E come ogni pattern, funziona solo se poggia su fondamenta solide. Quelle fondamenta hanno un nome preciso: ISA-95.

ISA-95 è lo standard che definisce il vocabolario e la gerarchia condivisi: Enterprise, Site, Area, Line, Cell, Equipment, che rendono i topic MQTT di un'architettura UNS qualcosa di più di una convenzione di naming locale. Senza ISA-95, o un equivalente semantico, UNS è un broker con topic arbitrari: ogni stabilimento, ogni fornitore, ogni team usa le proprie etichette, e il problema della frammentazione si ripresenta un livello più in alto.

Ma ISA-95 risolve solo metà del problema semantico: struttura dove il dato vive nel namespace, la gerarchia dei topic. L'altra metà riguarda come quel dato è formato quando arriva, il payload. È qui che entra in gioco Sparkplug B, il protocollo che definisce il formato standardizzato dei messaggi MQTT per ambienti industriali: tipi di dato strutturati, gestione del ciclo di vita dei nodi, e un meccanismo di birth/death certificate che rende il broker davvero la fonte di verità sull'intero 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. Il collo di bottiglia reale, in quasi tutti i progetti UNS che faticano a decollare, non è il broker. È la normalizzazione semantica a monte, quello che una categoria crescente di strumenti dedicati all'Industrial DataOps si propone di risolvere: fare sì che "temperatura forno linea 3" nello stabilimento di Milano e Line3_Oven_T nello stabilimento di Barcellona siano lo stesso dato, con lo stesso significato, per qualsiasi sistema li consumi.

Alleantia Core risolve questo problema una volta sola, a livello edge, prima che i dati raggiungano qualsiasi consumer, broker MQTT incluso.

Fondamenta architetturali

Perché ISA-95 è una scelta valida di architettura dei dati

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.

Indipendenza da fornitore e protocollo
I dati di una macchina significano la stessa cosa indipendentemente dal fatto che arrivino a un'applicazione via OPC-UA, Kafka, MQTT, SQL o Modbus. Una macchina, un gateway o un intero fornitore di automazione possono essere sostituiti senza dover riscrivere l'interpretazione dei dati per i sistemi a valle.
Interoperabilità attraverso il confine IT/OT
MES, ERP, piattaforme di analytics e storici consumano tutti lo stesso modello normalizzato, senza richiedere ciascuno un proprio livello di traduzione personalizzato. Esattamente il confine che ISA-95 è stato progettato per colmare, tra le operazioni di produzione e i sistemi di controllo.
Scalabilità dello sforzo di integrazione
L'integrazione punto-punto cresce in modo combinatorio: ogni nuova macchina e ogni nuova applicazione moltiplicano le mappature necessarie. Un modello semantico condiviso cresce in modo lineare, una nuova macchina si inserisce una sola volta nella gerarchia esistente, e ogni consumer già presente la comprende immediatamente.
Longevità e minor costo totale di proprietà
Adottare un modello dati comune ha un costo iniziale reale, ma viene pagato una sola volta. La mappatura ad hoc continua invece a pagare una "tassa" di integrazione a tempo indeterminato, che si aggrava man mano che lo stabilimento o l'azienda cresce.
Un linguaggio condiviso tra ruoli, non solo tra sistemi
Il vocabolario di ISA-95 offre a ingegneri OT, architetti IT e stakeholder di business un modo comune di parlare della stessa realtà produttiva, riducendo la perdita di significato che si verifica quando ciascun gruppo ricorre al proprio gergo locale.
Una base per casi d'uso a maggior valore
Il benchmarking tra stabilimenti, il roll-up di KPI a livello enterprise e i modelli di machine learning addestrati su più linee o siti dipendono tutti da dati che significano la stessa cosa ovunque provengano.

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 della gerarchia; le scelte tecnologiche sottostanti restano aperte. Quando il trasporto scelto è MQTT, Sparkplug B completa il quadro definendo il formato standard del payload, assicurando che non solo i topic, ma anche il contenuto dei messaggi sia strutturato in modo coerente e interoperabile tra sistemi diversi.

Alleantia Core supporta pienamente questi principi, garantendo una semantica standardizzata per l'intero set di dati macchina. Ecco come mette in pratica questi vantaggi.

Un solo modello semantico, applicato una sola volta

Alleantia Core normalizza i dati macchina e di processo in una struttura semantica standardizzata attraverso il concetto di machine driver: la connessione a ogni macchina è definita da un file di configurazione standardizzato 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 univoco dall'Alleantia Core a cui è collegato. Ogni istanza di Alleantia Core riceve un Machine ID univoco a livello globale. Ogni macchina dispone di nome, descrizione e alias, tutti pubblicati nei messaggi in uscita. Ogni Alleantia Core dispone infine di un parametro System ID configurabile.

Questa struttura — System ID → Machine ID → Device ID → Var ID non è solo un'identificazione univoca: è una gerarchia semantica che si mappa direttamente sui livelli ISA-95 e, quando il trasporto è MQTT, si traduce naturalmente in una struttura di topic compatibile con Sparkplug B. Il Device ID corrisponde al concetto di Node in Sparkplug B; le variabili (Var ID) corrispondono alle Metric.

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 ma solo cosa significhino.

Aperto in ingresso

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.

Coerente in uscita

Una volta normalizzato, lo stesso modello semantico viene esposto in modo uniforme su oltre 20 API a valle di Alleantia Core. MES, ERP, piattaforme di analytics e applicazioni consumer di tipo storico ricevono tutti dati con struttura e significato identici, non un diverso livello di traduzione per ogni integrazione.

Tra le API disponibili, l'output MQTT merita una menzione separata in ottica UNS: i messaggi pubblicati da Alleantia Core verso un broker MQTT esterno, HiveMQ, EMQX, Mosquitto o qualsiasi altro, portano già la struttura gerarchica ISA-95 nei topic e il payload normalizzato nelle variabili. Questo rende Alleantia Core un producer naturale per qualsiasi architettura Unified Namespace: il broker riceve dati già semanticamente corretti, senza richiedere uno strato di trasformazione intermedio.

Aggiungere una nuova API a un'implementazione esistente non significa ricostruire la mappatura semantica.

Conclusioni

Struttura, manutenibilità, longevità

Nel complesso, le tre caratteristiche descritte, un solo modello semantico, connettività agnostica in ingresso, esposizione uniforme in uscita sono ciò che l'"allineamento a ISA-95" dovrebbe concretamente significare per un'architettura di integrazione:

Strutturata
Ogni punto dato porta lo stesso contesto gerarchico e semantico indipendentemente dalla fonte.
Manutenibile
La logica di normalizzazione risiede in un unico punto, non dispersa in decine di mappature punto-punto.
Estensibile
Nuove macchine a monte e nuovi consumer a valle si inseriscono in un modello esistente anziché richiederne uno nuovo.

Vale la pena essere precisi sul perimetro: ISA-95 non impone un protocollo di trasporto, un'architettura software specifica o un modello di sicurezza. La Parte 5 (B2MML) offre una serializzazione XML di riferimento, ma la maggior parte delle implementazioni reali sceglie il proprio trasporto preservando l'allineamento semantico sottostante. Quando quel trasporto è MQTT, Sparkplug B è diventato lo standard de facto per il payload: aggiunge al messaggio il contesto che ISA-95 fornisce alla gerarchia, completando il quadro semantico dall'edge al consumer.

Alleantia Core è progettato per operare in questo ecosistema mantenendo la struttura libera di adottare i protocolli effettivamente utilizzati sul campo pur continuando a parlare internamente un linguaggio comune e allineato agli standard.