Dalle prime origini dei relè cablati e dei PLC isolati alle architetture aperte e interoperabili che guidano la produzione intelligente, la traiettoria dei protocolli di comunicazione industriale ha subito una profonda trasformazione. Nei primi decenni dell'automazione a livello di stabilimento, i circuiti di controllo operavano come isole digitali. I controllori eseguivano localmente una logica deterministica, ma la condivisione della telemetria tra i diversi processi richiedeva un esteso cablaggio punto-punto o schede di interfaccia personalizzate.

Con la crescita della complessità dei moderni processi industriali, la domanda operativa di diagnostica in tempo reale, coordinamento tra sistemi e visibilità a livello aziendale ha superato le capacità dei controllori di campo isolati. Il passaggio ad ambienti interconnessi non ha riguardato soltanto la trasmissione di bit su un cavo; rappresenta una riprogettazione fondamentale del modo in cui i dati industriali vengono strutturati, associati contestualmente e trasmessi tra dispositivi di campo, controllori edge e reti di analisi aziendale.

Le fondamenta del networking di stabilimento: Modbus, i primi PLC e la frammentazione dei protocolli

Quando i controllori logici programmabili entrarono negli stabilimenti produttivi alla fine degli anni Sessanta, sostituirono i complessi armadi a relè con la logica ladder basata su software. Tuttavia, con l'espansione degli impianti e l'installazione di decine di PLC autonomi lungo le linee di lavorazione, gli ingegneri ebbero bisogno di un mezzo fisico e logico standardizzato che consentisse ai controllori di scambiare i registri interni senza ricorrere a segnali intermedi trasmessi tramite relè.

Nel 1979, Modicon (oggi Schneider Electric) introdusse lo standard Modbus, alterando radicalmente le comunicazioni industriali. Progettato attorno a un'architettura master/slave (oggi client/server) operante su interfacce seriali come RS-485, Modbus offriva un protocollo aperto e senza royalty che semplificava il recupero dei dati a livello di registro. La sua semplicità e facilità di implementazione lo resero uno standard onnipresente, status che mantiene ancora oggi su milioni di endpoint operativi.

Nonostante il suo successo storico, Modbus presenta colli di bottiglia strutturali quando viene implementato in ambienti di automazione ad alta intensità di dati. Modbus non dispone nativamente di tipizzazione dei dati, metadati contestuali, marcatura temporale né funzionalità pub/sub. Per recuperare un valore analogico, un controllore master deve interrogare continuamente specifici registri di mantenimento. Con l'espansione delle reti di controllo fino a comprendere migliaia di punti I/O, l'interrogazione di routine ha creato gravi problemi di congestione della larghezza di banda e latenza.

Per superare queste limitazioni e ottenere un controllo deterministico ad alta velocità, i principali fornitori di sistemi di automazione hanno sviluppato architetture proprietarie per bus di campo ed estensioni dei protocolli orientate alle prestazioni:

• Siemens implementò PROFIBUS (e successivamente PROFINET) per supportare lo scambio ciclico ad alta velocità dei dati I/O e di complessi flag diagnostici tra stazioni di campo distribuite, come i controller Siemens SIMATIC.
• Allen-Bradley / Rockwell Automation introdusse Data Highway Plus (DH+) e ControlNet, che in seguito si evolsero in EtherNet/IP tramite il Common Industrial Protocol (CIP).
• Mitsubishi Electric implementò CC-Link per fornire un controllo deterministico ad alta velocità attraverso livelli fisici dedicati e immuni ai disturbi.

Sebbene queste tecnologie fieldbus consentissero un'esecuzione deterministica dei cicli, crearono un "vincolo del fornitore". Interfacciare un PLC Allen-Bradley con un azionamento Siemens o un contatore di energia di terze parti richiedeva convertitori di protocollo complessi, mappature di memoria personalizzate e hardware gateway fragili, aumentando i costi di manutenzione lungo il ciclo di vita.

Superare il vincolo del fornitore: da OPC Classic a OPC UA indipendente dalla piattaforma

Le difficoltà operative causate dalla frammentazione dei protocolli spinsero il settore dell'automazione verso livelli di astrazione unificati. Invece di scrivere driver software personalizzati per ogni connessione da PLC a HMI, gli ingegneri avevano bisogno di un'interfaccia di traduzione standardizzata.

Nel 1996, un gruppo di fornitori di sistemi di automazione collaborò con Microsoft per creare lo standard Open Platform Communications (OPC), in seguito denominato OPC Classic. Basato sulle tecnologie OLE, COM e DCOM di Microsoft, OPC Classic definì interfacce client-server standardizzate per l'accesso ai dati (OPC DA), gli allarmi e gli eventi (OPC AE) e l'accesso ai dati storici (OPC HDA). A un fornitore di sistemi di automazione bastava fornire un server OPC per il proprio hardware; qualsiasi software HMI o SCADA conforme a OPC poteva quindi leggere e scrivere i dati senza problemi.

Tuttavia, l'affidamento a Microsoft DCOM creava notevoli difficoltà operative con la modernizzazione delle reti industriali:

• Dipendenza dal sistema operativo: i server OPC Classic potevano funzionare solo sui sistemi operativi Windows, escludendo i controller Linux embedded, i dispositivi RTOS e i server aziendali Unix.
• Vincoli di sicurezza: la configurazione di DCOM attraverso firewall e confini tra sottoreti era notoriamente complessa e richiedeva intervalli di porte aperti, introducendo gravi vulnerabilità di sicurezza informatica.
• Mancanza di contesto semantico: i dati venivano trasmessi principalmente come valori grezzi, senza contesto integrato, unità ingegneristiche o metadati semantici incorporati direttamente nel frame di trasporto.

Per risolvere queste vulnerabilità architetturali, nel 2008 la OPC Foundation ha rilasciato l’OPC Unified Architecture (OPC UA). OPC UA ha abbandonato DCOM a favore di un’architettura aperta orientata ai servizi (SOA) che utilizza TCP/IP e i livelli di trasporto HTTP/HTTPS. Soprattutto, OPC UA è indipendente dalla piattaforma e consente l’integrazione nativa direttamente in gateway edge Linux, controller embedded e ambienti cloud.

Inoltre, OPC UA ha introdotto un Information Model orientato agli oggetti. Invece di trasmettere un numero isolato in virgola mobile, OPC UA incapsula i dati in oggetti complessi completi di unità ingegneristiche, limiti di allarme superiore e inferiore, precisione del timestamp e diritti di accesso. Insieme alla crittografia PKI integrata e all’autenticazione tramite certificati x509, OPC UA costituisce un pilastro della convergenza sicura tra IT e OT.

Architetture DCS, O-PAS e controllo ibrido moderno

Sebbene i PLC eccellano nel controllo discreto ad alta velocità, le industrie di processo, come la raffinazione petrolchimica, la generazione di energia e la chimica specialistica, si sono storicamente affidate ai Distributed Control System (DCS). Un DCS integra controller, sottosistemi I/O, database historian e workstation per operatori in un ambiente di progettazione unificato.

Le implementazioni DCS legacy garantivano un’elevata affidabilità del sistema e circuiti di controllo ridondanti. Tuttavia, questa stretta integrazione avveniva a scapito della modularità. Le reti proprietarie dei controller, i bus I/O chiusi e i software di configurazione specializzati vincolavano per decenni gli operatori degli impianti a ecosistemi di un unico fornitore. L’espansione di un DCS legacy o l’integrazione di sottosistemi specializzati di terze parti, come il monitoraggio online delle vibrazioni dei macchinari, richiedeva spesso costose modifiche ingegneristiche.

Figura 1. Livelli funzionali di un Distributed Control System (DCS) che illustrano i tradizionali livelli gerarchici di controllo. Immagine per gentile concessione di Wikipedia Commons.

Per superare questo paradigma, i principali operatori industriali, guidati da ExxonMobil, hanno avviato l’Open Process Automation Standard (O-PAS) nell’ambito dell’OPA Forum di The Open Group. O-PAS mira a creare un’architettura aperta e indipendente dall’hardware per l’automazione dei processi, definita da tre pilastri fondamentali:

1. Interoperabilità: bus di comunicazione standardizzati (basati su OPC UA) che consentono ai componenti di diversi produttori hardware di scambiare dati nativamente senza sviluppare driver personalizzati.
2. Modularità: disaccoppiamento delle applicazioni software dall’hardware sottostante tramite microservizi containerizzati e nodi di controllo distribuiti (DCN).
3. Sicurezza: cybersecurity integrata conforme agli standard IEC 62443 e applicata a ogni confine del dispositivo.

Oggi, gli impianti moderni implementano spesso architetture ibride. Gli asset di processo critici sono gestiti da solide piattaforme DCS come i sistemi di controllo DCS, mentre le apparecchiature ausiliarie, i monitor ambientali e i rack specializzati per la protezione delle turbomacchine trasmettono i parametri relativi allo stato degli asset direttamente alle piattaforme edge tramite protocolli aperti e standardizzati.

Telemetria basata sugli eventi: MQTT e reti edge a bassa larghezza di banda

Con l'evoluzione della strumentazione sul campo, dai semplici sensori discreti ai complessi trasmettitori intelligenti capaci di segnalare centinaia di parametri diagnostici, divennero evidenti i limiti operativi delle tradizionali reti client-server basate su richieste e risposte.

Nel 1999, Andy Stanford-Clark (IBM) e Arlen Nipper (Arcom, oggi Cirrus Link) svilupparono il Message Queuing Telemetry Transport (MQTT) specificamente per risolvere i vincoli di larghezza di banda e latenza nelle applicazioni SCADA remote, come il monitoraggio degli oleodotti e dei gasdotti tramite collegamenti satellitari. In questi ambienti, il polling continuo su connessioni ad alta latenza si rivelava costoso e inaffidabile.

MQTT ha risolto queste problematiche attraverso un'architettura Pubblica/Sottoscrivi (Pub/Sub) basata sugli eventi e che utilizza un broker centrale per i messaggi:

• Comunicazione disaccoppiata: i nodi edge (pubblicatori) e il software aziendale (sottoscrittori) non stabiliscono connessioni dirette punto-punto. Comunicano in modo asincrono tramite il broker MQTT.
• Overhead minimo: grazie a un'intestazione compatta di 2 byte, MQTT riduce drasticamente l'utilizzo della larghezza di banda rispetto alle API HTTP/REST o ai pesanti protocolli RPC.
• Report per eccezione (RBE): i dispositivi sul campo pubblicano i dati solo quando un valore cambia oltre una banda morta o una soglia di stato definita, eliminando il traffico di polling non necessario sulla rete.
• Consapevolezza dello stato: funzionalità come i timer "Keep Alive" e il "Last Will and Testament" (LWT) consentono al broker di notificare immediatamente agli iscritti se un dispositivo edge si disconnette improvvisamente.

Figura 2. Modello Pubblica/Sottoscrivi nell'architettura di rete MQTT, che connette i nodi edge ai broker applicativi centrali. Immagine per gentile concessione di Wikipedia Commons.

Sebbene il semplice MQTT fornisca un meccanismo flessibile per il trasporto dei payload, non standardizza il formato delle strutture dei topic o dei payload. Per risolvere questo problema, la comunità industriale ha sviluppato la specifica Sparkplug B. Sparkplug B definisce uno spazio dei nomi standardizzato per i topic, una struttura compatta dei payload basata su Google Protocol Buffer (Protobuf) e meccanismi di gestione dello stato, trasformando il semplice MQTT in un livello di trasporto industriale pronto per l'uso aziendale.

Il paradigma industriale moderno: architettura dello spazio dei nomi unificato (UNS)

L'accumulo di protocolli legacy basati sul polling, server OPC isolati e connessioni API punto-punto porta spesso a una complessa "architettura spaghetti". In questo ambiente, l'aggiunta di un singolo nuovo strumento di analisi richiede la creazione di connessioni personalizzate a ogni nodo SCADA, historian e database MES dell'impianto.

Per eliminare queste strozzature di integrazione, gli ingegneri dell'automazione moderna stanno implementando l'architettura Unified Namespace (UNS). Una Unified Namespace funge da livello di astrazione software centralizzato e in tempo reale, che costituisce la "singola fonte di verità" per tutti i dati operativi e aziendali all'interno di un'impresa.

Figura 3. Struttura della Unified Namespace (UNS) che orchestra il flusso di dati in tempo reale attraverso tutti i livelli aziendali ISA-95. Immagine per gentile concessione di Wikipedia Commons.

Basata su un modello di pubblicazione/sottoscrizione, generalmente implementato tramite MQTT Sparkplug B o piattaforme di flussi di eventi, la UNS struttura semanticamente i dati secondo gerarchie fisiche standard (come ISA-95):

Enterprise / Sito / Area / Linea / Cella / Asset

In un framework UNS pienamente implementato:

• Un PLC di campo pubblica direttamente lo stato del motore su Enterprise/Sito_A/Linea_2/Miscelatore/Velocità_Motore al verificarsi di un cambiamento di stato.
• Il sistema SCADA si sottoscrive alla struttura dei topic per visualizzare la grafica operatore in tempo reale.
• Il sistema di gestione degli asset aziendali (EAM) ascolta lo stesso flusso di topic per monitorare le ore operative e programmare automaticamente la manutenzione preventiva.
• I modelli di machine learning basati sul cloud acquisiscono il flusso di dati unificato per eseguire il rilevamento predittivo delle anomalie senza imporre richieste di polling aggiuntive al controllore di campo.

Disaccoppiando i produttori di dati dai consumatori di dati tramite una UNS, le aziende industriali possono aggiungere, modificare o scalare strumenti software e sensori edge senza riprogettare i loop di controllo esistenti.

Matrice dei protocolli a livello di campo e confronto tecnico

La selezione della strategia di protocollo ottimale richiede la comprensione delle caratteristiche prestazionali tecniche, dell'overhead dei payload e delle applicazioni target di ciascun livello di rete nell'intero ecosistema operativo:

Progettare un'architettura reale: aggiornare le operazioni di un impianto legacy

La migrazione di un impianto manifatturiero brownfield operativo dalle reti legacy basate sul polling a un'architettura aperta e basata sugli eventi richiede un approccio ingegneristico per fasi, anziché una revisione completa del sistema.

Consideriamo un tipico impianto di processo continuo che utilizza sistemi PLC-5 legacy o i primi sistemi ControlLogix insieme a dispositivi autonomi per la protezione dei macchinari rotanti. Tentare di sostituire simultaneamente tutto l'hardware legacy introduce rischi inaccettabili di fermo e costi di investimento elevati. Una roadmap di modernizzazione strutturata in tre fasi offre un percorso pratico:

1. Fase 1: Livello di traduzione dei protocolli edge
   Installa gateway edge industriali accanto ai rack dei PLC legacy. Il gateway edge interroga i registri locali di mantenimento tramite seriale o protocolli fieldbus legacy e converte i valori grezzi in nodi OPC UA strutturati o topic MQTT Sparkplug B.
2. Fase 2: Implementazione del broker e strutturazione dell'UNS
   Implementa in sede un broker MQTT ridondante ad alta disponibilità. Definisci uno spazio dei nomi unificato per i topic ISA-95 nell'intero stabilimento. Instrada la telemetria dei gateway edge nel broker, abilitando immediatamente la visibilità degli asset in tempo reale senza modificare i tempi di scansione dei PLC o la logica di controllo sottostanti.
3. Fase 3: Integrazione dell'analisi avanzata e del controllo ibrido
   Collega gli historian aziendali, i motori di analisi cloud e i moderni sistemi HMI direttamente all'UNS come sottoscrittori. Quando i controller legacy raggiungono la fine del ciclo di vita, sostituiscili con PAC moderni ad architettura aperta, nativamente compatibili con gli ambienti OPC UA e MQTT.

Grazie a questa strategia modulare, gli impianti industriali proteggono gli investimenti esistenti nelle apparecchiature di campo, ottenendo al contempo la flessibilità dei dati, la conformità ai requisiti di cybersicurezza e la scalabilità necessarie per le moderne operazioni dell'Industria 4.0.