Un gateway per protocolli industriali non va scelto soltanto cercando nella scheda tecnica i nomi dei due protocolli che devono comunicare. Per stabilire se un modello è realmente compatibile bisogna verificare protocollo sui due lati, ruolo del gateway in ciascuna rete, direzione o modalità dello scambio, dati da mappare e capacità richieste dall'applicazione.
La presenza, per esempio, di PROFINET e PROFIBUS nelle specifiche non garantisce che il converter possa funzionare nella topologia prevista. Lo stesso principio vale per EtherNet/IP, CANopen, J1939 e gli altri protocolli industriali: ruoli e funzioni dipendono dallo standard e dall'implementazione del singolo prodotto.
Se l'esigenza è invece esclusivamente convertire Modbus TCP e Modbus RTU/ASCII, il problema appartiene alla guida dedicata al Modbus. Qui il focus è l'integrazione tra protocolli industriali differenti.
Quando serve un gateway di protocollo industriale
Un protocol gateway serve quando due dispositivi, segmenti di rete o sistemi di automazione devono scambiarsi dati ma utilizzano protocolli che non comunicano direttamente tra loro.
Non è quindi un semplice adattatore dell'interfaccia fisica. In base al modello, il gateway può acquisire informazioni attraverso un protocollo, gestirle internamente, mapparle e renderle disponibili attraverso il protocollo utilizzato sull'altro lato. La conversione può inoltre richiedere che il dispositivo assuma un ruolo preciso in ciascuna rete.
È uno scenario tipico quando:
- due sistemi utilizzano protocolli industriali differenti.
- un PLC o un dispositivo legacy deve rimanere operativo durante una migrazione.
- un fieldbus esistente deve essere integrato con una rete Industrial Ethernet.
- determinati dati devono diventare disponibili attraverso un protocollo diverso da quello originario.
- la comunicazione richiede ruoli specifici sui due lati.
Un caso Modbus chiarisce bene il confine. Collegare Modbus RTU e Modbus TCP significa rimanere all'interno dell'ecosistema Modbus. Integrare invece un dispositivo Modbus con PROFINET o EtherNet/IP è una conversione multiprotocollo.
Protocollo, ruolo e direzione: cosa determina davvero la compatibilità
Il primo filtro è il supporto dei protocolli presenti sui due lati. È però solo il punto di partenza.
Bisogna poi stabilire che cosa deve fare il gateway all'interno di ciascuna rete. PROFINET, EtherNet/IP, PROFIBUS, Modbus e CANopen utilizzano modelli e terminologie differenti: Controller, Device, Scanner, Adapter, Master, Slave, Client e Server non sono sinonimi universali.
| Protocollo o ecosistema | Ruolo o relazione da verificare | Domanda da porsi | Perché conta |
|---|---|---|---|
| PROFINET | IO Controller / IO Device | Il gateway deve controllare dispositivi o presentarsi come dispositivo alla rete? | Controller e Device svolgono funzioni diverse |
| EtherNet/IP | Scanner / Adapter | Chi origina le connessioni I/O e chi ne è il target? | Scanner e Adapter non sono intercambiabili |
| PROFIBUS DP | Master / Slave | Quale lato deve governare la comunicazione PROFIBUS? | La stessa coppia di protocolli può richiedere gateway con ruoli diversi |
| Modbus | Client / Server, nelle implementazioni seriali è ancora comune Master / Slave | Chi genera le richieste e chi risponde? | Il solo supporto Modbus non definisce l'architettura |
| CANopen | Modalità e ruolo CANopen supportati | Il gateway implementa la funzione richiesta verso i nodi CANopen? | Ruolo, oggetti e servizi supportati incidono sulla compatibilità |
| J1939 | Supporto J1939 esplicito | Il dispositivo implementa realmente J1939 per lo scenario richiesto? | Una generica interfaccia CAN non implica supporto J1939 |
In PROFINET, un IO Controller è tipicamente il PLC sul quale gira il programma di automazione, l'IO Device è invece il dispositivo di campo che scambia dati con uno o più Controller. PROFIBUS & PROFINET International distingue esplicitamente queste classi nel modello PROFINET.
Per EtherNet/IP, ODVA definisce lo Scanner come originator delle connessioni I/O verso gli Adapter, gli Adapter sono i target di tali richieste.
La tabella non stabilisce equivalenze fra i ruoli dei diversi protocolli. Serve a evidenziare che il ruolo va verificato all'interno dell'ecosistema specifico.
I ruoli cambiano da protocollo a protocollo
Un gateway che opera come PROFINET IO Device può essere integrato da un IO Controller compatibile, ma non per questo può assumere anche il ruolo di Controller.
Lo stesso vale per EtherNet/IP: un prodotto che opera soltanto come Adapter non equivale a un dispositivo capace di funzionare come Scanner. Alcuni gateway implementano entrambi i ruoli, altri soltanto uno.
Anche sul lato PROFIBUS bisogna sapere se l'architettura richiede un Master o uno Slave. Per Modbus, la documentazione corrente utilizza la terminologia client/server, mentre nelle implementazioni seriali e nella documentazione di molti dispositivi industriali rimane diffusa la terminologia master/slave. La documentazione Modbus ufficiale distingue in ogni caso chiaramente client, server e implementazione gateway.
Il requisito utile per la selezione non è quindi «serve PROFIBUS e PROFINET», ma qualcosa di più preciso: «il gateway deve svolgere questo ruolo sul lato PROFIBUS e quest'altro ruolo sul lato PROFINET».
Perché 'supporta entrambi i protocolli' non basta
Due prodotti che riportano le stesse sigle possono essere progettati per architetture differenti.
Oltre alla coppia di protocolli bisogna controllare:
- ruolo sui due lati.
- direzione o modalità della comunicazione.
- profili o versioni richiesti.
- dati da trasferire.
- capacità del gateway.
- eventuali funzioni specifiche necessarie all'applicazione.
Anche un trasferimento di dati in entrambe le direzioni non implica automaticamente la disponibilità di tutti i ruoli previsti dai due protocolli.
Mapping, capacità, diagnostica e certificazioni: cosa verificare oltre ai protocolli
Dopo avere verificato protocolli e ruoli, bisogna stabilire se il gateway può gestire i dati, le dimensioni dell'applicazione e le condizioni di installazione.
| Criterio | Cosa verificare | Perché può escludere un gateway |
|---|---|---|
| Mapping | Registri, oggetti o aree dati trasferibili | Non tutte le informazioni hanno necessariamente un equivalente sull'altro protocollo |
| Quantità dati | Limiti in byte, punti o altri elementi | Un gateway può essere compatibile ma insufficiente per il carico richiesto |
| Nodi e connessioni | Numero massimo supportato | L'architettura può superare i limiti del modello |
| Performance applicativa | Tempi e frequenza di aggiornamento richiesti | Non esiste una latenza universale valida per tutti i protocol converter |
| Diagnostica | Monitor del traffico, log, stato ed eventi | Aiuta a individuare errori durante commissioning e manutenzione |
| Conformance / certificazione | Certificati, listing o profili richiesti | Supporto dichiarato e certificazione non sono la stessa cosa |
| Interfacce | Porte e standard fisici | Il protocollo corretto non compensa un'interfaccia inadatta |
| Isolamento | Protezione richiesta dall'installazione | Può essere un requisito elettrico o ambientale |
| Alimentazione | Range e tipo | Deve essere compatibile con il quadro o l'impianto |
| Temperatura | Range operativo della SKU precisa | La variante standard può non essere adatta all'ambiente |
| Firmware e documentazione | Versione corrente e funzioni documentate | Le caratteristiche disponibili possono dipendere dalla versione |
Mapping e capacità devono corrispondere ai dati reali
La conversione di protocollo richiede spesso un mapping tra rappresentazioni differenti dei dati.
In CANopen, per esempio, parametri di comunicazione e applicativi sono organizzati nell'Object Dictionary, servizi come SDO e PDO accedono o trasportano informazioni secondo il modello CANopen.
Un gateway che collega CANopen a un altro protocollo deve quindi trasformare i dati secondo le funzioni previste dalla propria implementazione. Questo non significa che ogni servizio o oggetto del protocollo sorgente disponga automaticamente di un equivalente funzionale sull'altro lato.
Lo stesso vale per la capacità. Un produttore può dichiarare byte di input/output, un altro numero di punti, nodi, comandi o connessioni. Queste metriche descrivono limiti differenti e non sono direttamente confrontabili.
Per lo stesso motivo non è corretto ricavare una 'latenza tipica dei gateway industriali' dal solo baud rate della porta seriale o dalla velocità nominale dell'interfaccia Ethernet. Le prestazioni reali dipendono da gateway, protocolli, quantità di dati, connessioni e configurazione.
Diagnostica e commissioning
Un protocol converter è il punto d'incontro tra due sistemi differenti. In caso di mancata comunicazione, l'errore può trovarsi sul lato sorgente, sul lato destinazione oppure nella configurazione e nel mapping.
Funzioni come traffic monitor, status monitoring ed event log possono quindi essere utili per il commissioning e il troubleshooting. La loro disponibilità dipende però dalla serie e dal modello: non è una caratteristica da attribuire automaticamente a qualsiasi gateway.
La serie Moxa MGate 5103, per esempio, documenta un traffic monitor Modbus dedicato al controllo dei dati acquisiti durante l'installazione.
Certificazione, ambiente e versione del prodotto
Il supporto dichiarato di un protocollo e un'eventuale certificazione o dichiarazione di conformità sono due livelli differenti.
Se un capitolato richiede una specifica conformance, bisogna verificarla per il modello effettivamente utilizzato. Lo stesso vale per documenti di integrazione come GSD/GSDML, EDS, PICS o equivalenti quando richiesti dal protocollo o dall'ambiente di engineering.
Anche le condizioni fisiche devono essere controllate sulla SKU precisa. All'interno della stessa famiglia possono esistere modelli standard e versioni wide-temperature, oltre a differenze di isolamento, alimentazione o interfacce.
Scenari tipici di conversione tra protocolli industriali
I criteri di scelta diventano più concreti se applicati a pochi scenari rappresentativi. I prodotti citati di seguito sono esempi legati a requisiti precisi, non una classifica generale di gateway.
Migrazione da PROFIBUS a PROFINET
Un impianto può avere dispositivi PROFIBUS ancora operativi mentre il livello di controllo viene progressivamente migrato verso PROFINET. Un protocol gateway può permettere la coesistenza dei due sistemi senza sostituire immediatamente tutti i dispositivi legacy.
La prima verifica riguarda i ruoli.
Se il gateway deve operare come PROFIBUS DP-V1 Master verso il segmento esistente e come PROFINET IO Device verso il Controller, la serie Moxa MGate 5102-PBM-PN è un esempio coerente. La documentazione corrente Moxa dichiara questi due ruoli e mette a disposizione AutoScan dei dispositivi PROFIBUS, una data mapping table ed esportazione dei moduli in GSDML per assistere la configurazione PROFINET.
La condizione è essenziale: se il lato PROFIBUS richiede un ruolo diverso, la presenza delle sigle PROFIBUS e PROFINET nella scheda non rende automaticamente idoneo il prodotto.
Il gateway consente quindi una forma di integrazione o migrazione graduale, ma non trasforma il dispositivo PROFIBUS in un PROFINET IO Device nativo sotto ogni aspetto.
Modbus verso PROFINET o EtherNet/IP
La presenza di Modbus non rende automaticamente lo scenario un caso 'Modbus-only'.
Se occorre esclusivamente passare tra Modbus TCP e Modbus RTU/ASCII, l'approfondimento appartiene alla pagina dedicata al Modbus. Quando invece Modbus deve essere collegato a PROFINET o EtherNet/IP, il problema è multiprotocollo.
Per un'integrazione verso PROFINET, Moxa MGate 5103 è un esempio concreto. Moxa lo documenta per la conversione di Modbus RTU/ASCII/TCP o EtherNet/IP verso una rete PROFINET, sul lato EtherNet/IP opera come Adapter, mentre i dati raccolti vengono resi disponibili al PROFINET IO Controller. Sono inoltre documentati buffering dei dati, esportazione GSDML e traffic monitoring Modbus.
Per una relazione Modbus↔EtherNet/IP, Moxa MGate 5105-MB-EIP è invece un esempio di gateway che supporta Modbus RTU/ASCII/TCP e, sul lato EtherNet/IP, sia Scanner sia Adapter. La presenza di entrambi i ruoli mostra perché, durante la selezione, è necessario andare oltre la semplice dicitura 'EtherNet/IP supportato'.
Questi esempi non richiedono di entrare in indirizzamento, timeout, registri o troubleshooting specificamente Modbus: tali aspetti appartengono alla guida dedicata.
CANopen e J1939 verso Industrial Ethernet
CANopen e J1939 possono utilizzare CAN come base di comunicazione, ma sono protocolli differenti. Una porta CAN generica non dimostra quindi la compatibilità con entrambi. CiA documenta anche meccanismi specifici per il mapping tra servizi CANopen e parameter group J1939, confermando che si tratta di modelli distinti che possono essere messi in relazione solo attraverso implementazioni definite.
Se dispositivi CANopen o J1939 devono essere collegati a PROFINET, Moxa MGate 5123 è un esempio pertinente. La documentazione corrente indica conversione da CANopen, J1939 e CAN proprietario verso PROFINET, supporto come CANopen Master e funzionamento come PROFINET IO Device. Il produttore dichiara inoltre limiti specifici per nodi, PDO, connessioni e quantità dati: esattamente il tipo di verifica che deve seguire il controllo della compatibilità di protocollo.
Il prodotto rimane pertinente solo se questi ruoli e la destinazione PROFINET corrispondono allo scenario reale.
Telecontrollo, utility e building automation
I protocol converter possono essere utilizzati anche fuori dalla factory automation.
Negli ambienti power e utility possono comparire DNP3, IEC 60870-5-101, IEC 60870-5-104 e IEC 61850. Sono standard distinti: IEC 60870-5-101 è un companion standard per compiti di telecontrollo con trasmissione seriale codificata, mentre IEC 60870-5-104 definisce l'accesso di rete per IEC 101 attraverso profili di trasporto standard. IEC 61850 è invece una famiglia dedicata alle reti e ai sistemi di comunicazione per la power utility automation.
In uno scenario di retrofit utility, Moxa MGate 5119-T rappresenta un esempio specialistico: la documentazione attuale lo indica come IEC 61850 MMS Server e supporta, nei ruoli dichiarati, Modbus, DNP3, IEC 60870-5-101 e IEC 60870-5-104 sul lato di raccolta dati.
Nella building automation, BACnet è invece definito da ASHRAE come protocollo di comunicazione per building automation and control networks. Per un caso Modbus↔BACnet/IP, la serie Moxa MGate 5217 supporta Modbus RTU/ASCII/TCP e BACnet/IP in modalità Client/Server e comprende varianti da 600 e 1200 punti.
Se un progetto richiede una specifica certificazione o listing BACnet, lo stato corrente deve comunque essere verificato separatamente per la variante effettivamente utilizzata.
Checklist per scegliere un gateway di protocollo prima dell'acquisto
Prima di filtrare il catalogo, conviene completare una sequenza di verifiche precisa.
Prerequisiti: devono essere noti i due sistemi da integrare, le relative interfacce, il ruolo funzionale dei dispositivi coinvolti e almeno i dati che devono essere trasferiti.
- Identifica il protocollo sul lato A. Non fermarti al mezzo fisico: 'Ethernet' o 'CAN' da soli non identificano necessariamente il protocollo applicativo.
- Identifica il protocollo sul lato B. Usa la denominazione precisa richiesta dall'architettura: per esempio PROFINET, EtherNet/IP, CANopen, J1939 o lo specifico protocollo IEC coinvolto.
- Definisci il ruolo richiesto al gateway sul lato A. Verifica se deve operare come Master, Slave, Client, Server, Scanner, Adapter, Controller, Device o secondo un altro ruolo previsto dall'implementazione.
- Definisci il ruolo richiesto sul lato B. Il controllo deve essere svolto indipendentemente anche per il secondo protocollo.
- Verifica che il produttore documenti quella specifica combinazione. La presenza dei due nomi nella scheda tecnica non sostituisce la verifica di ruoli e modalità operative.
- Controlla mapping e capacità. Definisci quali dati devono attraversare il gateway e verifica limiti relativi a byte, punti, nodi, comandi o connessioni. Considera i requisiti prestazionali dell'applicazione senza dedurre latenze non documentate.
- Verifica interfacce e condizioni di installazione. Porte, isolamento, alimentazione e temperatura operativa devono essere coerenti con il quadro e con l'ambiente reale.
- Controlla profili, certificazioni, diagnostica e versione. Quando pertinenti, verifica GSD/GSDML, EDS, PICS o altri documenti di integrazione, oltre a certificazioni, firmware, manuale corrente e strumenti di commissioning.
- Solo a questo punto restringi il catalogo. Una volta definiti protocolli, ruoli, mapping e limiti, è possibile escludere le famiglie incompatibili e valutare soltanto i gateway coerenti con lo scenario.
La verifica finale può essere sintetizzata in un requisito operativo: 'serve un gateway che operi come X sul lato A e come Y sul lato B, trasferendo questi dati entro questi limiti'.
Se ruolo, direzione, profilo o capacità non risultano chiaramente documentati, la selezione del prodotto è ancora prematura.
Non viene inserito un collegamento ecommerce alla categoria perché nei dati disponibili non è presente un URL Digitx.it verificato per una categoria o un filtro specifico dedicato ai protocol converter.
Quando serve un altro tipo di gateway
Non tutti i problemi di comunicazione industriale richiedono un protocol converter multiprotocollo.
- Solo Modbus TCP↔RTU/ASCII: consulta la guida ai gateway Modbus.
- Devi ancora individuare la famiglia corretta: parti dalla panoramica sui gateway industriali.
- Il requisito principale è una WAN tramite SIM: consulta i gateway cellulari 4G/5G/LTE.
- Devi collegare sensori o dispositivi LoRaWAN: consulta la guida ai gateway LoRaWAN.
- La priorità è accesso remoto sicuro, VPN, firewall o segmentazione: consulta i gateway VPN e sicurezza.
Prima di selezionare un modello, quindi, il passo decisivo è descrivere con precisione i due lati dell'integrazione, i ruoli richiesti, i dati da trasferire e i vincoli tecnici. Quando queste informazioni sono note, il catalogo può essere filtrato in modo utile, se mancano, partire dai prodotti aumenta il rischio di scegliere un gateway che supporta le sigle corrette ma non l'architettura reale.