Opzioni di protocollo a livello di applicazione per funzionalità M2M e IoT

Con l'adozione dell'Internet delle cose (IoT) e le funzioni di Impresa 4.0, i dispositivi sono sempre più connessi tramite protocolli industriali. Inoltre, le comunicazioni macchina-macchina (M2M) oggi si stanno rapidamente standardizzando su questi protocolli. A complicare le cose c'è il fatto che i protocolli IoT non descrivono un unico protocollo a livello di applicazione, poiché sono in atto diversi standard. Così, mentre le prime implementazioni IoT usavano protocolli internet standard, ora sono disponibili anche protocolli IoT dedicati.

Modellare le strutture di comunicazione e identificare il giusto protocollo per una particolare applicazione può essere scoraggiante. Questo articolo delinea i vari protocolli e le opzioni disponibili - così che i progettisti possano selezionare più facilmente quello più adatto da integrare.

Figura 1: Le funzioni IIoT nell'automazione industriale si basano su dispositivi sempre più connessi che utilizzano protocolli industriali per la connettività di rete. I livelli astratti di queste reti non richiedono alcuna conoscenza delle funzioni dei livelli sottostanti ... questo è il motivo per cui molto dello sforzo di sviluppo si concentra sul livello superiore (applicazione) delle reti di macchine. (Immagine per gentile concessione di Getty Images)

Definizione del protocollo a livello di applicazione per le reti industriali

Le strutture dei protocolli di comunicazione per i sistemi digitali M2M e IoT sono concettualmente suddivise in livelli astratti, dove i modelli più comuni hanno tre, quattro, cinque o sette livelli. Questi quadri concettuali presumono che ogni livello essenzialmente "nasconde" il funzionamento dettagliato di un dato dispositivo o livello software da altri dispositivi o algoritmi con cui sta comunicando. Questo perché i livelli sono definiti come contenenti solo le informazioni sufficienti per gli scambi di dati contestuali.

Figura 2: Le architetture di sistema tradizionali sono gerarchiche, ma il cloud e il fog computing hanno offuscato le linee tra le funzioni dei componenti. Questo ha determinato l'uso di nuovi modelli di protocollo di rete. (Immagine per gentile concessione di LEDiL)

A prescindere dal modello utilizzato, tutti stabiliscono un livello di applicazione come quello di astrazione più alto tra i dispositivi che comunicano tra loro su una rete. Si consideri il livello di applicazione come un modello OSI (Open Systems Interconnection) - definito per la prima volta dall'International Organization for Standardization (ISO) quasi trent'anni fa per le comunicazioni di rete. Questo classico modello a sette livelli è un po' troppo complicato per descrivere alcuni dei protocolli di oggi, ma è ancora utile per comprendere appieno il flusso di dati all'interno dei sistemi:

Il livello fisico di un protocollo permette la trasmissione di dati grezzi (bit digitali) come segnali elettrici, radio o ottici. Questo livello specifica la disposizione dei pin, i livelli di tensione, le velocità dei dati e le impedenze di linea degli elementi fisici che trasportano i dati. Ethernet è un comune protocollo di livello fisico. Leggere l'articolo DigiKey EtherNet/IP e PROFINET a confronto per saperne di più.

Il livello di link collega i nodi della rete per permettere ai dispositivi di stabilire le connessioni e correggere gli errori al livello fisico. All'interno dello standard IEEE 802, il livello di link è diviso in un livello MAC (Medium Access Control) (per permettere ai dispositivi di connettersi) e un livello LLC (Logical Link Control) per identificare il livello successivo da usare (il livello di network) così come il controllo degli errori e la sincronizzazione. Per maggiori informazioni sulle funzioni del livello di link leggere l'articolo DigiKey Implementare Industrial Ethernet con MCU a 32 bit. Per contro, il livello di network permette l'inoltro dei pacchetti di dati agli indirizzi di rete. Laddove i protocolli internet si riferiscono al modello TCP/IP (Transmission Control Protocol/Internet Protocol) - trattato nella prossima sezione di questo articolo - vi è un livello internet tra i livelli di link e di network. Infatti, il livello internet è spesso considerato una parte del livello di network.

Il primo dei successivi tre livelli del modello OSI è il livello di trasporto, che assicura l'affidabilità della comunicazione e la sicurezza durante i trasferimenti di sequenze di dati. Poi vi è il livello di sessione che controlla quando i dispositivi si collegano tra loro e se la connessione è unidirezionale (simplex) o bidirezionale (duplex). Infine, il livello di presentazione permette la conversione dei dati in modo che i dispositivi che usano sintassi diverse possano comunicare.

L'obiettivo di questo articolo - il livello di applicazione - è il più alto livello di astrazione e quello con cui gli utenti e il software di sistema interagiscono.

Figura 3: I moderni protocolli di rete (e il livello di applicazione) sono spesso descritti usando il classico modello OSI delle reti industriali (e commerciali). Invece i modelli di architettura IoT a tre livelli pongono il livello di applicazione sopra i livelli di percezione e di network; i modelli a quattro livelli lo pongono sopra i livelli di elaborazione dati, di network e di rilevamento. I modelli di protocollo IoT a cinque livelli sono simili, ma aggiungono i livelli di elaborazione e di impresa. (Immagine per gentile concessione di Design World)

Protocolli Internet nell'automazione industriale

I protocolli Internet sono sistemi di comunicazione dati così chiamati per il modo in cui trasmettono i dati tra le reti (e di solito reciprocamente) per le comunicazioni interconnesse. Le loro funzioni sono spesso descritte con il modello a quattro livelli TCP/IP menzionato sopra. Qui, il livello di network fisico o di link è lo stesso del livello fisico del modello OSI. Diversamente, il livello internet TCP/IP (che approssima una combinazione delle funzioni del livello di link e di network del modello OSI) gestisce le connessioni e i pacchetti di dati. In IPv6, questo livello utilizza indirizzi IP a 128 bit per identificare gli host sulla rete - e accetta più di 10³⁸ host univoci.

Il livello di trasporto in TCP/IP generalmente consiste nel protocollo di controllo della trasmissione (TCP) o nel protocollo di datagramma utente (UDP). TCP è generalmente utilizzato per le interazioni umane come la posta elettronica e la navigazione sul web; fornisce connessioni logiche, riconoscimento dei pacchetti trasmessi, ritrasmissione dei pacchetti persi e controllo del flusso. Tuttavia, i sistemi embedded usano UDP per un costo minore e prestazioni migliori in tempo reale. UDP funziona per i server dei nomi di dominio (DNS) e il protocollo di configurazione dinamica degli host (DHCP), così come le nuove applicazioni IoT.

Il livello di applicazione è il livello più alto nel modello TCP/IP delle reti. Le funzioni includono quelle associate ai livelli di sessione e presentazione del modello OSI.

Protocolli generici TCP/IP a livello di applicazione

Diversi protocolli a livello di applicazione hanno diverse larghezze di banda di dati, capacità in tempo reale e requisiti hardware. Questi fattori insieme alla familiarità dello stabilimento o del team OEM con un protocollo sono spesso un importante criterio di selezione. Anche se i primi protocolli internet, tra cui il protocollo di trasferimento ipertestuale (HTTP) e il protocollo di trasferimento della posta semplice (SMTP) sono in gran parte utilizzati per le comunicazioni comandate e usate dall'uomo, i protocolli TCP/IP con un'ottica IIoT sono più incentrati sulle comunicazioni macchina-macchina (M2M) e altre comunicazioni di tipo industriale.

A complicare un po' le cose c'è il fatto che molti protocolli stabiliti a livello di applicazione usati nel TCP/IP per le interazioni umane basate sul web con le informazioni hanno anche usi IoT in campo industriale e consumer. Questo è certamente vero per HTTP e SMTP, così come per la shell sicura (SSH) e il protocollo di trasferimento file (FTP). L'implementazione di funzioni IoT con tecnologie web è di solito fattibile se vengono utilizzati anche eXtensible Markup Language (XML) e JavaScript Object Notation (JSON). Un avvertimento è che l'uso di HTTP ha implicazioni di sicurezza. Ecco perché di solito è meglio se ogni dispositivo IoT in tali sistemi include solo un client e non un server. Ciò impedisce al dispositivo di ricevere richieste di connessione che potrebbero permettere un accesso esterno non autorizzato alla rete. Qui, il protocollo WebSocket può stabilire una comunicazione full-duplex via HTTP. Altrimenti, il protocollo di messaggistica estensibile e presenza (XMPP) può essere preferibile per le installazioni che devono rivolgersi a un gran numero di dispositivi con una buona sicurezza e comunicazioni dati in tempo reale.

Quando i progetti IoT sono guidati da personale con una preparazione in campo IT, questi standard familiari (dal web a lettura umana) possono essere preferenziali. Tuttavia, i nuovi protocolli IIoT possono in alcuni casi essere più adatti a M2M e ad altre comunicazioni industriali.

MQTT per funzioni di trasporto della connettività verticale

Il protocollo di telemetria di trasporto messaggi (MQTT), che ha visto l'adozione più rapida nell'IIoT, è un protocollo leggero inizialmente destinato ai dispositivi IoT con memoria limitata. Con funzioni su footprint di elaborazione compatti e un requisito di larghezza di banda minimo, MQTT è stato sviluppato per la prima volta da IBM per connettere i sensori sugli oleodotti. A differenza del protocollo di applicazione vincolata (CoAP), MQTT è già standardizzato ai sensi ISO/IEC 20922. MQTT usa il livello di trasporto TCP, un po' più dispendioso in termini di risorse, e quindi più energivoro ... ma i messaggi possono essere di due byte - ancora più piccoli di quelli di CoAP.

Grazie alla sua natura aperta, MQTT può anche essere particolarmente facile da implementare. Non c'è da stupirsi che AWS IoT di Amazon Web Services impieghi MQTT per il trasporto dei messaggi e (con eccezioni) supporti MQTT basato sulla specifica v3.1.1.

MQTT ha alcune limitazioni, che possono essere dovute al fatto che era stato inteso come un protocollo di telemetria - in contrasto con il protocollo Lightweight Machine to Machine (LwM2M) specifico per l'IoT che sarà trattato tra breve. Caratteristiche come gli oggetti, il monitoraggio della connettività e le azioni dei dispositivi remoti non sono incluse nello standard, quindi la loro inclusione tende ad essere specifica del fornitore, il che degrada in parte il valore del protocollo standardizzato. MQTT inoltre non offre alcuna capacità di gestione degli errori. Infine, anche se MQTT può essere reso sicuro con un protocollo TLS completo, ciò ne aumenta il costo.

AMPQ: soprattutto a livello aziendale

Advanced Message Queuing Protocol (AMQP) è un altro standard aperto che somiglia parzialmente a MQTT. Offre caratteristiche avanzate come la coda dei messaggi. Tuttavia, il costo di AMQP è superiore a quello di MQTT, il che lo rende poco adatto a connettere dispositivi molto limitati. Non c'è da stupirsi che il suo uso in applicazioni IoT industriali sia meno comune che nella messaggistica aziendale basata sulle prestazioni.

CoAP per connettere dispositivi semplici

Il protocollo CoAP (Constrained Application Protocol) della Internet Engineering Task Force (IETF) permette la comunicazione su reti a basso consumo tra dispositivi con memoria e potenza di elaborazione minime. Può funzionare con un costo molto basso e le richieste e le risposte possono essere anche di soli quattro byte. CoAP evita l'uso di uno stack di trasporto complesso a favore invece di UDP. Vedere l'articolo DigiKey EtherNet/IP e PROFINET a confronto già menzionato sopra per saperne di più su UDP. Come HTTP, anche CoAP utilizza il modello REST - con i server che rendono disponibili le risorse sotto un URL e i client che vi accedono tramite i metodi POST, GET, DELETE e PUT. Inoltre, CoAP può essere facilmente convertito in HTTP per l'integrazione con altre funzioni web ... e si integra con XML e JSON. Gli sviluppatori dovrebbero notare che connettere i dispositivi IoT con CoAP è molto simile alla connessione con un'API per il Web.

Figura 4: Il SiP di Nordic è un MCU a bassa potenza con un modem integrato LTE-M e in banda stretta (NB)-IoT, oltre a un GPS. Un kit di sviluppo software permette la configurazione di CoAP. (Immagine per gentile concessione di Nordic Semiconductor)

Connessione di dispositivi alimentati a batteria con LwM2M

Un protocollo a livello di applicazione della Open Mobile Alliance è LwM2M, creato appositamente per le applicazioni IoT. Impiegato in applicazioni per le città intelligenti, i container di spedizione e il monitoraggio dei trasporti merci, per routine automatizzate fuori strada e il monitoraggio delle utenze, LwM2M è basato su CoAP, quindi ne condivide molti degli attributi. Lo standard comprende una vasta gamma di oggetti standard chiaramente definiti e mantenuti, nonché azioni di monitoraggio della connettività e di dispositivi remoti. Gli aggiornamenti automatici del firmware semplificano anche la gestione dei dispositivi connessi a LwM2M. Anche se l'inclusione di moduli come JSON aumenta il suo costo, semplifica la progettazione per gli sviluppatori. Poiché LwM2M è stato progettato specificamente per le applicazioni IoT, può anche funzionare come un solido protocollo di sicurezza DTLS senza aumentare il costo.

DDS per applicazioni distribuite in tempo reale

Il servizio di distribuzione dei dati (DDS) è un po' diverso ed è spesso classificato come un middleware M2M piuttosto che un protocollo a livello di applicazione. Fornisce connessioni sicure e ad alte prestazioni, ad esempio in veicoli autonomi, per la generazione di energia e nei sistemi di controllo del traffico aereo. In queste impostazioni, DDS supporta la connessione di sistemi embedded per un controllo distribuito che è esente dall'eccessiva dipendenza dai gateway. DDS gestisce anche l'instradamento e la consegna dei messaggi senza richiedere l'intervento delle applicazioni. Inoltre la qualità dei parametri del servizio DDS sono configurabili - così le operazioni di rete possono essere ottimizzate nell'ottica dei vincoli del sistema.

Figura 5: Il software Connext Drive per i veicoli autonomi è costruito sul middleware DDS (servizio di distribuzione dei dati) - che fa parte della base per le architetture software AUTomotive Open System ARchitecture (AUTOSAR) Adaptive e ROS2. Questo è solo un esempio di come DDS supporta l'integrazione del software IoT. (Immagine per gentile concessione di Real-Time Innovations)

Conclusione: protocolli a livello di applicazione IIoT

Tutti i protocolli hanno pro e contro ma le opzioni open-source che permettono una rapida implementazione e sicurezza (preferibilmente a basso costo) sono le più adatte per le applicazioni IoT. I sistemi embedded e i dispositivi System-on-Chip (SoC) con capacità di calcolo sempre crescenti continuano a stimolare l'implementazione dell'IIoT e ad espandere ulteriormente ciò che è possibile a vari livelli di applicazione dei protocolli.