| Produttore: Modicon (ora Schneider Electric) Disponibilità: n.a. Categoria: standard Tipologia: protocollo di trasmissione seriale Difficoltà di implementazione: medio/alta |
Modbus (definizione Wiki), è “un protocollo di comunicazione Open Source e royalty-free creato nel 1979 da Modicon (azienda ora parte del gruppo Schneider Electric) per mettere in comunicazione i propri controllori logici programmabili (PLC). È diventato uno standard de facto nella comunicazione di tipo industriale, ed attualmente è uno dei protocolli di connessione più diffusi al mondo fra i dispositivi elettronici industriali.”
I controllori logici programmabili sono per l’appunto dei moduli, tipicamente adottati in ambito industriale, concepiti in modo da consentire ai più disparati macchinari di eseguire le più disparate funzioni in base alla loro programmazione e destinazione d’uso, dalla macchina che inscatola biscotti alla siviera che scarica metallo fuso su stampi: davvero la qualunque.
Ma perché ne parliamo su inDomus, dato che gli standard utilizzati in domotica personale sono solitamente altri?
Ne parliamo perché è falso che Modbus venga utilizzato solo in ambito industriale: capita infatti sovente che alcuni elettrodomestici, appliance o anche singoli componenti presenti nelle case e negli uffici presentino Modbus quale interfaccia utile all’integrazione.
Modbus consente la comunicazione fra diversi dispositivi connessi alla stessa rete, per esempio un sistema che misura la temperatura e l’umidità e comunica il risultato a un computer. Modbus è spesso usato per connettere un computer supervisore con un’unità terminale remota (RTU) nel controllo di supervisione e sistemi di acquisizione dati (SCADA).
Esistono sostanzialmente due versioni del protocollo: su porta seriale (RS485 di default, ma anche RS232) e su Ethernet/Wi-Fi (Modubus TCP).
Uso in domotica PERSONALE
Può capitare che esistano, come dicevamo, dei componenti domotici compatibili con Modbus, quindi è sano conoscere anche questo standard: un esempio sono alcuni modelli di climatizzatori, oppure dei componenti da quadro elettrico (banalmente, quelli della Schenider Eletric) e molti altri.
In caso si adotti un HUB personale per la propria domotica, come si può provvedere all’integrazione di tali componenti sfruttando tale standard? Invero, in modo relativamente semplice. Trattandosi di un protocollo seriale, solitamente i componenti compatibili con tale standard presentano dei contatti elettronici sui quali attestare un semplice adattatore che consenta poi di canalizzare telemetrie e comandi da e per il componente in questione su una rete (seriale, TCP o di altro tipo). Esistono per esempio adattatori Modbus↔︎Ethernet, oppure Modbus↔︎Wi-Fi, oppure Modbus↔︎USB e così via.
Una volta appurato che il componente domotico da integrare supporti Modbus e acquistato un adattatore che consenta di “dialogare” con esso, il passo successivo è quello di verificare che il proprio HUB supporti tale standard: nel caso del più che adottato Home Assistant, per esempio, esiste allo scopo uno specifico componente di integrazione (da noi illustrato in dettaglio qui). Ultimo step è quello di documentarsi rispetto ai registri Modbus del componente da integrare, informazioni utili alla configurazione logica dell’integrazione: tale documentazione solitamente è disponibile in rete, su manuali d’uso o presso i siti dei produttori.
| N.b. Ovviamente il ragionamento vale anche, al contrario, per componenti industriali: sul piano puramente teorico, nessuno vieta di controllare un macchinario industriale compatibile Modbus con un HUB personale. Un po’ forzato, ma certamente funzionante. |
In dettaglio
| Attenzione: ci addentriamo ora nei dettagli tecnici di questo standard, dettagli che, agli occhi di un novellino, possono – mettiamo le mani avanti – risultare ostiche. La lettura è consigliata a chi abbia un minimo di dimestichezza con questi temi. |
Il ModBus si posiziona a livello 7 nella pila ISO/OSI, definendo la formattazione dei messaggi detta framing e la modalità di trasmissione dei dati e delle funzioni di controllo. La comunicazione avviene tramite il paradigma client-server. Il protocollo definisce un Protocol Data Unit (PDU) che non dipende dal sottostante strato di comunicazione. L’Application Data Unit (ADU) introduce campi addizionali per l’indirizzamento e il controllo dell’errore.
Quando parliamo di Modbus è facile immaginare dispositivi come PLC (programmable Logic Controller), HMI (Human Machine Interface), dispositivi di I/O, controllori di movimento, driver, eccetera: spesso i dispositivi sono “monitorati” da sistemi di supervisione, controllo e acquisizioni di dati.
Esistono diverse versioni del protocollo ModBus, ASCII e RTU operano su reti implementate su tecnologie RS232 RS422 e RS485, mentre la versione TCP/IP opera su reti che supportano la suite TCP/IP.
ModBus seriale definisce la struttura dei messaggi che vengono spediti e che i dispositivi, distinti in master (client) e in slave (server), interpretano indipendentemente dalla tipologia di rete (client-server) su cui lavorano.
Il modello di registro è l’entità minima che contiene informazioni sull’indirizzo e le funzioni su cui opera.
| Tipo funzione | Terminologia | Caratteristiche |
| Discrete output | Coils | 16 Bit read and write |
| Discrete input | Input | 1 Bit read only (I/O) |
| Input register | Input register | 16 Bit read only (I/O) |
| Output register | Holding register | 1 Bit read and write |
Il protocollo ModBus seriale definisce due tipi elementari di dato: discrete input e input register. Il tipo di dato discreto rappresenta un valore (bit) per indirizzare gli output (coils) di un PLC, mentre il dipo di dato input register rappresenta valori interi a 16 bit. Molto spesso viene utilizzata una coppia di valori di tipo registro per rappresentare float a 32 bit – attenzione in questo caso l’ordinamento è little endian (byte meno significativi vengono memorizzati prima dei byte più significativi).
In generale questo tipo di dato, ad esclusione dei float a 32 bit, viene trasferito con ordinamento bit endian (byte più significativi vengono memorizzati prima di quelli meno significativi).
Per la parte seriale esistono due diverse modalità di formattazione dei messaggi:
- Modbus RTU che fornisce una rappresentazione binaria – compattezza dei dati
- Modbus ASCII versione più umana – i dati (indirizzi, funzioni, eccetera) sono leggibili da parte dell’utente poiché vengono codificati in esadecimale.
In entrambi i casi viene utilizzata una comunicazione seriale, RTU fa seguire a comandi, funzioni e dati un checksum di tipo CRC (Cyclic Redundancy Checksum) mentre per l’ASCII viene generato un checksum di tipo LRC (Longitudinal Redundancy Checksum). Nodi RTU non possono comunicare con nodi ASCII e viceversa.
Ci sono da sottolineare alcune limitazioni del protocollo ModBus seriale, utilizzando un paradigma master-slave non c’è modo per un dispositivo di forzare un invio di dati/eccezione. Il nodo master deve continuamente (pull) interrogare gli slave per conoscere eventuali modifiche nei dati. L’indirizzamento Modbus permette il collegamento di un massimo di 254 dispositivi, fattore che limita il numero massimo di dispositivi connessi ad una stazione master.
Abbiamo accennato che per il Modbus seriale esistono due modalità di trasmissione, ASCII e RTU. Vediamo da vicino come sono fatti i messaggi e cosa cambia tra le due modalità.
Per la versione ASCII ogni byte in un messaggio è spedito come due caratteri ASCII. Il vantaggio di questo metodo è che permette di avere delle interruzioni tra i caratteri fino ad 1 secondo senza che si generino errori.
Le caratteristiche della modalità ASCII sono:
- codifica esadecimale (0-9, A-F);
- 1 bit di inizio, 7 bit di dati, 1 bit parità/disparità, 1 bit di fine se viene attivato il controllo parità, altrimenti 2 bit;
- LRC checksum.
Per la versione RTU ogni byte in un messaggio contiene due caratteri esadecimali, il principale vantaggio di questa modalità è che a parità di bound rate abbiamo una maggiore densità di dati a flusso continuo.
Le caratteristiche della modalità RTU sono:
- codifica binaria 8 bit corrispondenti a due caratteri esadecimali;
- 8 bit di dati, 1 bit parità/disparità, 1 bit di fine se viene attivato il controllo parità, altrimenti 2 bit;
- CRC checksum.
In entrambi i casi i messaggi vengono contenuti in un frame dove abbiamo un punto di inizio e un punto di fine ben preciso.
Vediamo adesso come sono modellati i frame per le due modalità.
ASCII
In questo caso il messaggio inizia con il carattere “:” corrispondente in esadecimale a “3A” e termina con i caratteri “line feed / carriage return” corrispondente in esadecimale a “0D” e “0A”
| INIZIO | INDIRIZZO | FUNZIONE | DATI | LRC | FINE |
| 1 carattere | 2 caratteri | 2 caratteri | N caratteri | 2 caratteri | 2 caratteri |
RTU
Nella modalità RTU il messaggio inizia con un intervallo di tempo di silenzio di almeno 3.5 caratteri
| INIZIO | INDIRIZZO | FUNZIONE | DATI | CRC | FINE |
| T1 T2 T3 T4 | 8 bit | 8 bit | N x 8 bit | 16 bit | T1 T2 T3 T4 |
L’indirizzo nella modalità ASCII contiene due caratteri mentre nella modalità RTU 8 bit. Indirizzi validi assegnabili ai dispositivi slave vanno da 1 a 247 come valore numerico decimale. L’indirizzo 0 è riservato alla comunicazione broadcast. Quando il master interroga uno slave scrive l’indirizzo del destinatario nel campo indirizzo, quando lo slave risponde riscrive il proprio indirizzo nel campo indirizzo della sua risposta. Questo conferma l’avvenuta ricezione dell’interrogazione.
Il campo che definisce la funzione, anche in questo caso, per l’ASCII contiene due caratteri mentre per RTU 8 bit. I codici validi vanno da 1 a 255 come valori numerici decimali. Quando un master invia un messaggio ad uno slave, nel campo funzione viene specificata l’azione che lo slave deve compiere (leggere, scrivere caricare verificare eccetera). Anche in questo caso nella risposta lo slave inserisce lo stesso codice funzione richiesto dal master.
| CODICE | NAME | Descrizione |
| 01 | Read Coil Status | Lettura degli output discreti di uno slave |
| 02 | Read Input Status | Lettura degli input discreti di uno slave |
| 03 | Read Holding Register | Lettura del valore binario degli holding register di uno slave |
| 04 | Read Input Register | Lettura del valore binario degli input register di uno slave |
| 05 | Force Single Coil | Forza una coil al valore ON o OFF |
| … | … | … |
Per il campo dati abbiamo visto che esso è costruito usando coppie di cifre esadecimale che ricadono nell’intervallo 00 – FF; due caratteri ASCII o un carattere binario da otto bit per la modalità RTU.
Concludiamo questa panoramica su Modbus seriale analizzando un esempio di trasmissione di una query e sua risposta.
Nel 1999 è stato sviluppato “Modbus TCP”, standard dedicato alle reti che sfruttano la suite di protocolli TCP/IP: di fatto è una versione di Modbus seriale RTU basata appunto su TCP/IP, il che consente comunicazioni su reti internet/intranet. Negli ultimi anni la versione TCP/IP è sempre più utilizzata in quanto Open Source, semplice da implementare, dal basso costo di sviluppo e dal supporto hardware da garantire davvero minimo.
Il protocollo Modbus TCP/IP utilizza una codifica binaria dei dati ed il meccanismo di rilevamento errori TCP/IP, a differenza del Modbus seriale, la versione TCP/IP è orientata alle connessioni e permette di eseguirle in modo concorrente sullo stesso slave o su più dispositivi. Anche Modbus TCP/IP utilizza il paradigma master-slave; questa comunicazione utilizza in più quattro tipi di messaggio.
- Modbus request: il dispositivo client inizia una transazione;
- Modbus indication: il messaggio di request ricevuto dal dispositivo server;
- Modbus response: il messaggio di risposta alla request inviato dal dispositivo server;
- Modbus confirmation: il messaggio di response ricevuto dal dispositivo client.
Il frame del messaggio Modbus TCP/IP è differente rispetto al Modbus seriale.
Il Modbus Application Protocol Header identifica l’ADU, a differenza del modello seriale questo è identificato da un byte “unit identifier” che corrisponde all’indirizzo dello slave del protocollo RTU. Questo è utile per avere un router/gateway con un singolo indirizzo IP che può supportare più unità indipendenti.
Le richieste nel ModBus TCP/IP vengono costruite di modo che il dispositivo ricevente possa verificare la fine del messaggio. Per fare questo nel MBAP Header vengono inserite informazioni aggiuntive in modo da permettere al ricevente di identificare i limiti del messaggio, molto utile se il messaggio è stato spacchettato in più pacchetti.
Un dispositivo Modbus TCP/IP può fornire un’interfaccia client e/o server ed una di back end permettendo in generale di accedere indirettamente agli oggetti applicativi. E’ composta da quattro aree: input discreti, output discreti (coils), registri di input e registri di output.
| NOME | TIPO DI OGGETTO | MODALITÀ’ |
| Input discreti | Singolo bit | Solo lettura |
| Coils | Singolo bit | Lettura – Scrittura |
| Registri input | Parola a 16 bit | Solo lettura |
| Registri di output | Parola a 16 bit | Lettura – Scrittura |
Nel livello applicativo esistono quattro elementi principali:
- Client Modbus: dispositivo client che consente all’applicazione utente di controllare lo scambio di dati con un dispositivo remoto, il client costruisce una richiesta per far partire la transazione;
- Interfaccia client Modbus: interfaccia che permette all’applicazione utente di costruire una request, incluso l’accesso applicativo;
- Server Modbus: quando riceve una request questo modolo attiva una azione locale come ad esempio lettura, scrittura, o altra azione. Solitamente espongo la porta TCP 502/512 e attendono richieste;
- Interfaccia di back end Modbus: interfaccia dal server all’applicazione server dove sono definiti gli oggetti applicativi.
La principale funzione del servizio di messaggistica fornito da Modbus TCP/IP è quella di gestire la comunicazione in modo da gestirne anche il termine e il suo flusso di dei dati su connessioni TCP Standard. Questo permette di avere tutti i vantaggi che si porta dietro il protocollo TCP/IP come ad esempio il flusso di controllo, il controllo a livello data link ed a livello applicativo utente.
| Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa. |