1.0 Introduzione
L'Industrial Internet of Things (IIoT) è costituito da dispositivi collegati in rete che creano sistemi in grado di monitorare, raccogliere, scambiare e analizzare dati per consentire alle aziende industriali di prendere decisioni aziendali più intelligenti e veloci. I vantaggi derivanti dall'applicazione degli approcci IIoT ai problemi aziendali industriali sono enormi, poiché anche un piccolo miglioramento in termini di efficienza, tempo, spese in conto capitale e allocazione delle risorse si traduce in risparmi significativi e/o in un aumento dei ricavi. Le soluzioni IIoT hanno dimostrato questo tipo di miglioramenti percentuali. Tuttavia, per implementare una soluzione IIoT è necessaria una comprensione dell'architettura e del design.
Lo scopo di questo documento è fornire tale comprensione per i sistemi di monitoraggio IIoT. Si noti che i sistemi IIoT possono essere utilizzati sia per il monitoraggio che per il controllo. Dei due casi d'uso, il monitoraggio è generalmente più semplice da configurare e mantenere. I vantaggi immediati del monitoraggio IIoT includono: allarme remoto delle condizioni, monitoraggio della cronologia ed eliminazione del tempo e dello sforzo necessari per il controllo manuale.
Il resto del presente documento inizia con un'architettura concettuale per la soluzione di monitoraggio IIoT nella Sezione 2.0. L'architettura concettuale fornisce un quadro di riferimento per descrivere le opzioni di progettazione dell'architettura che sono descritte in dettaglio nella Sezione 3.0. Una guida alla scelta tra le opzioni è fornita nella Sezione 4.0. La panoramica dell'ecosistema Omega Link e della linea di prodotti nella Sezione 5.0 mostra un'istanza dell'architettura di progettazione. La sezione 5.0 fornisce una breve introduzione al tema dell'edge computing, che riporta all'uso dell'IIoT per il controllo rispetto al monitoraggio.
Il tema della sicurezza dell'IIoT è importante. Lasciamo una discussione dettagliata per un altro documento, ma forniamo una sintesi delle linee guida relative all'architettura nell'Allegato. Le architetture concettuali e di progettazione presentate (così come l'ecosistema Omega Link di Omega) incorporano la sicurezza come parte integrante delle loro strutture.
2.0 Architettura concettuale
2.1 Panoramica
L'architettura concettuale di una soluzione IIoT è illustrata nella Figura 2.1. Un sistema viene monitorato da uno o più sensori. Il sistema e i sensori sono in loco. Le informazioni provenienti da tali sensori vengono inviate a una posizione fuori sede nel cloud tramite l'elemento di connettività. Ci riferiamo ai dati che si spostano dall'elemento di connettività al cloud come comunicazioni "northbound" e dall'elemento di connettività ai sensori come "southbound".
2.2 Elementi
2.2.1 Cloud
Il cloud è il luogo di archiviazione e analisi fuori sede dei dati provenienti dai sensori. Fornisce inoltre un accesso sicuro a questi dati da parte degli utenti, in genere tramite login dal browser web. A differenza dell'archiviazione in loco, che in genere è limitata all'accesso in quella posizione, l'archiviazione e l'analisi nel cloud sono disponibili tramite Internet. L'accesso a Internet consente all'utente o agli utenti di accedere a questi dati in remoto tramite computer desktop, tablet o telefono cellulare. Sono disponibili anche analisi avanzate (ad esempio, l'apprendimento automatico).
2.2.2 Connettività
Il trasferimento sicuro delle informazioni tra i sensori e il cloud è compito dell'elemento Connettività. Come si vedrà nella sezione successiva, questo elemento è complesso, a causa del numero di opzioni disponibili e dei sottoelementi coinvolti. Indipendentemente dalla complessità, il compito rimane lo stesso: il trasferimento sicuro dei dati.
2.2.3 Sensori
I sensori sono il mezzo per rilevare lo stato del sistema. L'obiettivo della soluzione IIoT è quello di trasferire i dati più importanti raccolti dai sensori nel cloud per ulteriori analisi e decisioni da parte degli utenti che si trovano a distanza dal sistema stesso.
3.0 Architettura di progettazione
3.1 Panoramica
L'architettura di progettazione (Figura 3.1) porta l'architettura concettuale a un livello di dettaglio superiore, fornendo opzioni di progettazione ed elementi per ciascuna delle funzioni principali (cloud, connettività, sensori). La Figura 3.1 fornisce maggiori dettagli sulle funzioni cloud, connettività e sensori. Ulteriori spiegazioni sono riportate nelle sottosezioni seguenti.
3.2 Sensori
3.2.1 Cablati vs wireless
Dal punto di vista dell'architettura delle soluzioni IIoT, la distinzione tra sensori cablati e wireless è l'attributo più importante. Le uscite dei sensori cablati possono essere analogiche o digitali. Se analogiche, è necessario che più a monte nella catena siano disponibili mezzi per convertire i dati in formato digitale per la trasmissione. Se digitali, il protocollo per lo spostamento dei dati deve essere noto e supportato dalla soluzione di connettività (quella che chiamiamo connessione "southbound"). Il protocollo digitale includerà sia i componenti fisici (cavi, connettori) sia il protocollo software. Maggiori dettagli sono forniti nella sezione Connettività: protocolli. Per i sensori wireless, analogamente ai sensori con uscita digitale cablata, i dati sono già stati convertiti, quindi devono essere stabiliti i protocolli per l'invio e la ricezione delle informazioni. Inoltre, i componenti fisici includono la capacità di trasmissione e ricezione wireless.
3.2.2 Fattori di forma
I fattori di forma consentono di raggruppare uno o più sensori che funzionano in ambienti e regimi normativi diversi. Dal punto di vista dell'architettura IIoT, è importante comprendere i fattori di forma che combinano i sensori con la trasmissione wireless. Questi sono riportati nella Figura 3.1 nei riquadri tratteggiati "unità singola". Uno mostra sensori che sono stati abbinati a una connettività cellulare, consentendo l'accesso diretto al cloud. L'altro mostra una combinazione di sensore/trasmettitore che fornisce il collegamento a un gateway tramite un collegamento wireless.
3.2.3 Tipi di rilevamento
I sensori rilevano una varietà di fenomeni fisici, chimici, biologici e nucleari tramite una serie di meccanismi o modalità. Dal punto di vista dell'architettura, le modalità di rilevamento sono meno importanti rispetto al modo in cui le informazioni vengono trasferite dal sensore al cloud.
3.3 Cloud
Il cloud è costituito da 4 componenti principali:
a. un hub, che fornisce una connessione sicura al sistema in loco, alla telemetria e alla gestione dei dispositivi. Un hub consente la comunicazione remota da e verso i sistemi in loco, su più siti, se necessario. In genere gestisce tutti gli aspetti della comunicazione, compresa la gestione dei collegamenti, il percorso di comunicazione sicuro e l'autenticazione e l'autorizzazione dei dispositivi. Inoltre, applica le quote di connessione e di throughput. La telemetria e altri messaggi provenienti dai dispositivi vengono immessi nel cloud e lo scambio di messaggi è gestito dall'hub.
b. archiviazione per la conservazione dei dati
c. elaborazione per l'analisi dei dati
d. interfaccia utente e visualizzazione per fornire i risultati dell'analisi all'utente finale, in genere tramite un'interfaccia browser web, ma in caso di allarmi tramite e-mail, SMS e/o chiamata vocale.
3.4 Connectivity: Configurations
La connettività trasferisce i dati verso nord al cloud e i comandi e le informazioni di configurazione verso sud. Anche le informazioni di autenticazione e autorizzazione per comunicazioni sicure vengono trasferite verso nord/sud. La struttura di questo percorso di comunicazione segue tre modelli descritti di seguito e illustrati nella Figura 3.1.
1. Sensori al cloud: il fattore di forma del sensore/cellulare a unità singola consente la connessione diretta al cloud dall'impianto locale
2. Sensori al gateway al cloud: la configurazione più tipica prevede un gateway (vedere la sezione successiva) che fornisce la connessione tra i sensori e il cloud. Il gateway avrà in genere opzioni di connessione cablata e wireless. L'opzione wireless sarà solitamente un sensore/trasmettitore a unità singola, come mostrato nella Figura 3.1.
3. Sensori a trasmettitore a ricevitore a gateway a cloud: questa configurazione è tipica delle installazioni legacy in cui sono presenti trasmettitori e ricevitori esistenti e/o in cui è presente un numero significativo di sensori cablati che si trovano a una certa distanza da dove si troverebbe un gateway.
3.5 Connectivity: Gateways
3.5 Connettività: gateway
Un gateway funge da abilitatore di comunicazione e, potenzialmente, da hub di elaborazione dei dati dei dispositivi. Il suo compito è quello di trasferire dati e informazioni tra i sensori e il cloud. Un gateway può anche trasformare i dati durante il trasferimento. Supporta protocolli di comunicazione sicuri che includono informazioni di autenticazione e autorizzazione. Un gateway è diverso da un router in quanto svolge un ruolo attivo nella gestione dell'accesso e del flusso di informazioni. I gateway possono essere istanziati in forma hardware o software.
3.5.2 Gateway hardware
I gateway hardware sono dispositivi autonomi. Forniscono una o più interfacce per la connessione dei sensori southbound: cablata (analogica e digitale) e wireless. Forniscono anche l'accesso a Internet, integrato o tramite un collegamento a un router.
3.5.3 Gateway software
I gateway software sono installati sui PC. Il software può essere eseguito in primo piano o in background, fornendo gli stessi collegamenti di comunicazione northbound e southbound del gateway hardware, con le interfacce fisiche fornite dal PC. I gateway basati su software possono fornire interfacce utente per l'accesso alla configurazione dei sensori visivi e alla visualizzazione dei dati dei sensori. Poiché il gateway software è in esecuzione su un PC, può offrire l'archiviazione e la visualizzazione dei dati in loco. È anche possibile l'accesso remoto se il reparto informatico consente l'accesso sicuro dall'esterno alla rete interna con il PC. In tal caso, il gateway software in loco può eliminare la necessità del livello di funzionalità cloud.
3.6 Connettività: protocolli
3.6.1 Panoramica
Il movimento dei dati attraverso la soluzione IIoT richiede l'uso di protocolli. Questi protocolli devono essere ben definiti, sicuri e, idealmente, standard industriali. Le specifiche dei protocolli possono includere uno o tutti i seguenti elementi: caratteristiche fisiche dei connettori e dei cavi, modalità di creazione di un canale di comunicazione, formato dei dati inviati attraverso tale canale. Il modello OSI (Figura 3.6.1 sotto) delinea il protocollo come un insieme di livelli, ciascuno dei quali ha una funzione specifica.
3.6.2 Northbound: gateway da/verso il cloud
Esistono diversi protocolli standard disponibili per l'interfaccia tra il gateway e il cloud. Di seguito sono definiti alcuni dei più comuni, insieme a un diagramma riassuntivo.
Advanced Message Queueing Protocol (AMQP) è un protocollo di trasferimento messaggi orientato al collegamento, bidirezionale e multiplexing con codifica dati intrinseca e compatta. A differenza dei protocolli più vecchi come HTTP, AMQP è stato progettato per collegamenti di tipo IIoT al cloud.
MQ Telemetry Transport (MQTT). MQTT è un protocollo di trasferimento client-server leggero per i messaggi. MQTT è utile per i dispositivi IIoT grazie al suo spazio di codice compatto e alle dimensioni ridotte dei frame dei messaggi.
Constrained Application Protocol (CoAP). Il Constrained Application Protocol è un protocollo basato su datagrammi che può essere implementato su un livello di trasporto come UDP. CoAP può essere considerato una versione compatta di HTTP creata per le esigenze dell'IIoT.
Constrained Application Protocol (CoAP). The Constrained Application Protocol is a datagram based protocol that can be implemented over a transport layaer such as UDP. CoAP can be thought of a compact version of HTTP that was built for IIoT needs.
3.6.3 Southbound: gateway da/verso i sensori
Analogamente ai protocolli northbound, esistono molte opzioni anche per il collegamento southbound tra il gateway e i sensori. Queste opzioni includono i protocolli northbound elencati in precedenza. Tuttavia, a causa dei vincoli dei dispositivi e dei vincoli locali, come i sistemi di produzione e le reti precedentemente implementati, tendono ad essere sviluppati internamente o a costituire uno standard de facto stabilito da un singolo fornitore per i propri prodotti. Alcuni esempi sono: Zigbee, Bluetooth, WiFi, USB, SimpliciTI. Questi protocolli coprono diverse aree dello stack OSI. Ad esempio, Zigbee specifica il livello di rete e quelli superiori, mentre WiFi specifica solo i livelli di collegamento dati e fisico. Questa separazione delle funzionalità consente anche una certa combinazione e abbinamento dei protocolli.
4.0 Guida alla selezione
La guida alla selezione (Figura 4.1) fornisce indicazioni sulla scelta tra le varie configurazioni nell'architettura di progettazione. L'enfasi è sulla scelta tra cellulare, wireless o cablato. La determinazione della configurazione wireless o tra collegamenti cablati digitali e/o analogici dipende da un'ulteriore analisi dell'applicazione specifica.
5.0 L'ecosistema Omega Link IIoT
L'ecosistema Omega Link IIoT è un'istanza dell'architettura di progettazione IIoT, come mostrato di seguito. Come previsto, ci sono tre livelli: cloud, connettività (tramite gateway) e sensori. Esistono diverse opzioni per i gateway, sia hardware (di Omega e Avnet) che software (OEG). I sensori sono disponibili in diversi formati con collegamenti sia cablati che wireless. Vengono utilizzati protocolli standard sicuri, tra cui l'autenticazione e l'autorizzazione tra livelli e dispositivi. I protocolli sfruttano AMQP e SimpliciTI per consentire la configurazione plug and play con prodotti compatibili con l'ecosistema.
6.0 Riferimenti
Architettura di riferimento Microsoft Azure IoT, versione 2.1, 26/09/2018.
http://www.steves-internet-guide.com/internet-protocol-suite-explained/
http://www.steves-internet-guide.com/iot-messaging-protocols/
https://www.postscapes.com/internet-of-things-protocols/
Allegato A. Sicurezza IIoT
Le soluzioni IIoT devono essere affidabili per fornire dati e informazioni con integrità, poiché monitorano e misurano sistemi e ambienti critici. Tale affidabilità viene verificata garantendo che il sistema sia protetto dalle minacce. La modellazione delle minacce è l'approccio migliore per progettare la sicurezza. Utilizzando una configurazione tipica di una soluzione IIoT, è possibile identificare diverse zone (Figura A.1). I confini di queste zone sono i punti in cui i dati e le informazioni passano da un elemento della soluzione a un altro. Le minacce saranno rivolte contro i confini di queste zone. Per eseguire l'analisi delle minacce è possibile utilizzare il modello STRIDE, che definisce le minacce in base alle seguenti categorie riportate nella tabella sottostante.p>
Una spiegazione dettagliata dell'utilizzo del modello STRIDE esula dallo scopo di questa guida, tuttavia la sicurezza di una soluzione IIoT dovrebbe essere convalidata utilizzando questo metodo o un suo equivalente per ciascuna delle zone illustrate nella Figura A.1.
Cosa sono i motori passo-passo e i relativi controller? – Omega Engineering Introduzione ai motori passo-passo
