Industria 4.0 sta oggi cavalcando l’enorme vantaggio fornito dal calcolo elaborato in “cloud” che contribuisce a migliorare qualità del prodotto, efficienza del sistema complessivo e semplificando il processo decisionale [1]. In questo quadro si inserisce la cosiddetta Nube Computazionale (Fog Computing): abilita servizi che non erano disponibili nel recente passato, come, ad esempio, il servizio “Machine Learning”, in grado di rendere i dispositivi più intelligenti e autonomi attraverso l’elaborazione di un’enorme quantità di dati raccolti e gestiti nello spazio virtuale del cloud. Approfondiamo vantaggi tecnici e industriali, analizzando i passaggi di un caso di studio esemplare per l’adozione di architetture Fog&Cloud in open source da parte delle Pmi.
La quarta rivoluzione industriale, in via di consolidamento, esalta l’integrazione di entità e dispositivi dando vita a un unico sistema di elaborazione, caratterizzato da un sistema centralizzato in architettura “cloud” raccordato con la potenza di elaborazione collocata ai margini dell’architettura. Ma il decentramento dei processi di elaborazione richiede un livello di intermediazione, dal momento che occorre ridurre i tempi di latenza, indotti dall’implicita distribuzione crono-topologica degli agenti responsabili dell’elaborazione.
Ciò è particolarmente vero per le decisioni da assumere in ambienti critici come quello industriale, naturalmente e artificialmente sottoposto ai vincoli stringenti del tempo reale. Questo lavoro descrive la pianificazione e lo sviluppo di un’architettura “Industrial Fog”, denominata IFog4.0, basata sull’impiego di strumenti open source per Industria 4.0. Tale architettura è in grado di gestire lo scambio delle informazioni su reti industriali e molteplici protocolli di comunicazione come, ad esempio, Profinet e Modbus TCP, essendo destinata principalmente alle PMI.
L’automazione si realizza attraverso l’impiego di un ambiente di sviluppo e integrazione (IDE), mentre la gestione della piattaforma avviene con uno strumento dedicato al dispiegamento della componente “Fog”, denominata IFog4.0. Quest’ultima incorpora altri strumenti open source come Docker e Grafana, acquisite per realizzare le componenti di visualizzazione e trasmissione dei dati. La validazione della soluzione è stata effettuata utilizzando una piattaforma sperimentale in emulazione di una specifica applicazione industriale, costituita da una stazione di regolazione del gas, selezionata come caso d’uso di riferimento.
Industria 4.0: come superare i limiti della rete
L’introduzione delle tecnologie Internet nell’industria ha condotto alla nascita di Industria 4.0. I metodi e gli standard ivi proposti raccontano di uno sforzo operativo inestimabile orientato alla fusione di tutte le tecnologie esistenti finalizzato allo sviluppo di un prodotto industriale completo efficace, reattivo rispetto all’ecosistema in cui dovrà essere inserito.
I nuovi standard, sia quelli già introdotti sia quelli in corso di elaborazione, mirano a unificare tutte le risorse hardware e software, oltre alle macchine e ai dispositivi industriali [2]. Tutto si muove nella direzione di un ambiente interconnesso debolmente strutturato, ove le parti coinvolte comunicano e cooperano, scambiando informazioni che collocano il dato al centro dell’interazione [3]. Il paradigma del “cloud computing” recentemente introdotto per far fronte alla necessità di una gestione centralizzata e la contemporanea decentralizzazione delle capacità locali di elaborazione ha parzialmente risolto alcune delle criticità emerse nel paradigma IoT [4].
Ma le potenzialità della rete sono cresciute a un tasso neanche confrontabile con la crescita della capacità di elaborazione locale del singolo dispositivo autonomo. La larghezza di banda necessaria per operare con appropriati tempi di risposta potrebbe non essere disponibile a causa della stessa articolata e complessa architettura “cloud”, che rende insostenibili i requisiti di tempo reale propri delle applicazioni industriali [5].
In questo quadro, uno degli approcci più diffusi è quello di distribuire le attività critiche sui nodi di elaborazione prossimi all’utente finale dell’applicazione. Questo paradigma, centrato sul principio di prossimità, meglio noto come “fog computing” [6], supera il concetto di cloud computing centralizzato, lontano dal dispositivo locale, muovendosi verso un’architettura decentralizzata ove i compiti critici sono collocati nei nodi prossimi al dispositivo autonomo, iniziatore della transazione. Questo schema consente di ridurre le latenze computazionali in corrispondenza delle applicazioni critiche nel tempo, delegando solo l’elaborazione non critica al nodo centrale collocato nel “cloud” [7].
Fog computing, il nodo “soluzioni proprietarie”
Il decentramento dei processi di elaborazione introduce una nuova serie di problemi, completamente nuovi, concernenti la realizzazione dell’architettura dei servizi fog/cloud. In altre parole, diventa più complicato realizzare servizi in mutua interazione sulla rete senza predeterminare modalità efficaci di distribuzione dei compiti computazionali ai nodi responsabili dello sviluppo delle elaborazioni, collocati ai margini del sistema [8]. Inoltre, la maggior parte delle soluzioni disponibili è attualmente di tipo proprietario, inducendo costi di commissione e/o piani di abbonamento per poter essere utilizzati con successo dagli utenti [9][10]. Quest’ultima condizione compromette anche la possibilità di configurare un prodotto su misura per le esigenze particolari di uno specifico utente.
Questo lavoro propone la realizzazione di un’architettura completamente open source per ambienti di tipo industriale, nella prospettiva dell’“Industrial Internet of Things” (IIoT). In particolare il dominio di intervento prevede anche la valutazione del potenziale fornito dagli strumenti open in termini di competizione prestazionale con le soluzioni proprietarie. La struttura proposta è costruita operando sui requisiti espressi dalle piccole e medie imprese (PMI). Viene dunque presentato un caso di studio finalizzato all’esplorazione dell’efficacia del processo di controllo di un sistema industriale.
La discussione è organizzata come segue: background e letteratura vengono esaminati nella Sezione II. L’architettura proposta viene descritta nella Sezione III. Il caso d’uso e il risultato sono descritti in Sezione IV, infine le conclusioni sono riportate nella Sezione V.
Calcolo e servizi in cloud: la base tecnologica
I miglioramenti apportati recentemente alle soluzioni e ai meccanismi di interconnessione e il progresso tecnologico complessivo del settore dell’informazione ha dato vita a un nuovo paradigma computazionale noto come cloud computing [11]. La caratteristica chiave di questo approccio è la centralizzazione di un insieme di servizi, resi disponibili da un cluster di nodi server. Il cloud computing consente di scalare l’architettura in una certa misura, come la potenza di elaborazione che può essere aumentata, ad esempio, facendo crescere il numero di nodi impegnati nel calcolo. La tecnologia cloud dipende fortemente dalla rete per fornire i propri servizi, rete che deve sostenere un grado elevato di affidabilità e ridondanza a sostegno delle connessioni da gestire per fornire una soluzione in piena trasparenza rispetto alla percezione locale della qualità del servizio erogato.
Il cloud computing trae enorme vantaggio dai processi di virtualizzazione per gestire e controllare le risorse hardware, che possono essere assegnate in base alle esigenze. Questo approccio separa di fatto l’erogazione del servizio dal requisito di disponibilità dell’hardware fisico, il quale può essere dinamicamente esteso o ridotto in funzione delle esigenze.
La tecnologia “cloud” può introdurre significativi miglioramenti e vantaggi nel dominio industriale, perseguendo opportunità di semplificazione anche attraverso l’individuazione di un’unica sorgente rispetto alla fornitura di specifici servizi [12], considerando inoltre che, con l’emergere di Industria 4.0, maggiori investimenti sono stati indirizzati al settore dell’automazione, razionalizzando anche l’organizzazione dei servizi federati. Il “cloud” consente di sostenere attività complesse come l’apprendimento automatico a seguito dell’elaborazione di enormi insiemi di dati anche raccolti attraverso l’impiego di tecnologie abilitanti quali l’IoT per l’ambiente industriale.
La criticità emergenti, oggetto di ulteriori indagini e ricerche, concernono la necessità di regolare l’impatto crono-topologico della connessione di rete in termini di tempi di latenza e vincoli connessi ai requisiti di tempo reale.
Come funziona il Fog Computing
Una soluzione recentemente promossa prevede di allontanare parte del potenziale computazionale dai nodi centrali, collocandola ai margini della rete, nei pressi dei nodi utilizzati dall’utente. Questo approccio viene denominato “fog computing” [13].
L’azione di decentramento consente di creare nodi specializzati dedicati ai processi di elaborazione da realizzare in tempo reale. Essi eseguono compiti che sarebbero penalizzati significativamente dalla distanza fisica dei cluster di elaborazione remoti e dai ritardi indotti dal transito in rete. Tali compiti sono tipicamente relativi alla gestione di situazioni critiche, causa eventuale di danni a persone e cose, ove sempre il tempo di risposta è contenuto e rigorosamente determinato, oltre che invalicabile. Per tali situazioni si ritiene indispensabile utilizzare nodi foglia di elaborazione, che offrono prontezza di reazione garantendo tempi di risposta adeguati ai vincoli connessi ai requisiti di sicurezza.
Il “fog computing” migliora l’applicazione di questi nuovi paradigmi computazionali e sono particolarmente indicati per l’ambiente industriale, poiché consente comunque di estendere lo scenario cloud a compiti caratterizzati da elevata criticità. Il decentramento dei servizi computazionali tuttavia aumenta il livello di complessità esperito nello scenario industriale, frammentando l’esecuzione di servizi attraverso la rete dei nodi di elaborazione. È quindi essenziale fornire un’architettura in grado di eseguire efficacemente i servizi richiesti, indipendentemente dalla collocazione fisica dei processi di elaborazione [14].
Comunicazione e applicazioni industriali
Lo scambio di informazioni tra dispositivi collocati in ambiente industriale avviene tradizionalmente attraverso protocolli di comunicazione ben consolidati in un quadro evolutivo che esperisce un processo di innovazione non comune, con nuove opportunità emergenti promosse attraverso Industria 4.0. Questa riflessione introduce la sfida di riuscire a individuare un insieme di prodotti e tecnologie open source che creano un ambiente operativo, forse più complesso, ma sostenibile anche da organizzazioni di piccole dimensioni e potere d’ingaggio (PMI).
In questo quadro ben si inserisce Profinet, che è uno standard per la comunicazione basato su Ethernet industriale. Esso è particolarmente indicato per applicazioni con vincoli temporali rigorosi e rende disponibili meccanismi integrati di diagnosi e sicurezza. L’interazione tra controllore e dispositivi periferici viene gestito dal sistema PROFINET-IO, che definisce le modalità di scambio dei dati [15]. È basato sul paradigma consumatore-produttore e può essere implementato da qualsiasi controllore ethernet. Un elevato grado di disponibilità viene garantito attraverso l’uso di un’architettura ridondata, che è estremamente efficace per le applicazioni critiche nel tempo.
Analogo a Profinet, Modbus si propone come protocollo industriale, creato nel 1979 per i sistemi di automazione e per i controllori programmabili [16]. Il protocollo è basato su un modello client-server, ove un cliente avvia la trasmissione e il server può solo rispondere ad una richiesta specifica. Ogni cliente è direttamente raggiungibile e il server risponde solo al cliente che ha avviato la comunicazione. Il protocollo Modbus comunica su diversi bus e reti ed è diventato lo standard de facto per trasmissione seriale in ambito industriale. La variante Modbus TCP è una versione modificata dello stesso protocollo Modbus. Permette di utilizzare il livelli OSI TCP/IP in una comunicazione nell’ambito della stessa rete o attraverso Internet. Come sperimentazione per il caso d’uso esplorato in questo lavoro, tale variante di Modbus è stata utilizzata per sostenere l’interazione con i dispositivi PLC che implementano il controllo sul campo.
Più recentemente OPC-UA si è imposto sul mercato come standard aperto utilizzato nell’industria per lo scambio dei dati eseguito in modo sicuro e affidabile [17]. È stato rilasciato nel 1996 ed è diventato una delle piattaforme più utilizzate in ambito industriale. Viene utilizzato per l’interazione internamente ai singoli dispositivi, tra dispositivo e dispositivo, oltre che tra dispositivo e sistema. La specifica OPC definisce un’interfaccia unificata, normata, tra tutte le componenti del sistema, considerato nel suo complesso. È multipiattaforma e scalabile, quindi può essere utilizzato in una vasta gamma di ambienti, da piccole applicazioni integrate a enormi sistemi cloud e applicazioni mobili. Tale protocollo di comunicazione è progettato per migliorare la sicurezza fornendo autenticazione e crittografia e può essere quindi utilizzato non solo all’interno di reti private dedicate, ma anche in Internet.
Lo standard principale è stato rilasciato solo per sistemi Microsoft, ora noto come Classic OPC, mentre la norma più recente è stata introdotta nel 2008, denominata OPC-UA (Unified Architecture). Quest’ultima si basa sullo standard IEC62541 e include tutte le funzionalità della versione classica, oltre ad alcune aggiuntive, come l’indipendenza della piattaforma dai fornitori e ulteriori meccanismi di diagnosi.
Oltre ai protocolli menzionati, una nota particolare deve essere riservata a Message Queuing Telemetry Transport (MQTT), che è un protocollo per connessione macchina-macchina (M2M) basato sul meccanismo pubblicazione/sottoscrizione [18]. Creato nel 1999 da IBM e Arcom, è stato progettato per essere estremamente leggero e semplice, inizialmente destinato ai sensori a bassa potenza. Tuttavia, è stato ampiamente impiegato nei prodotti industriali, a seguito della vasta gamma di ambienti in cui può essere utilizzato.
Poiché l’obiettivo è mantenere la semplicità del protocollo, MQTT non fornisce metodi specifici per migliorare la sicurezza. Tuttavia può contare su qualsiasi ulteriore livello di sicurezza aggiuntivo, come ad esempio SSL. Il principio di funzionamento di MQTT si basa sul concetto di argomento, che corrisponde a un canale specifico pubblicato da un nodo dedicato a tale funzione sistemica.
Un cliente MQTT può iscriversi ad alcuni argomenti (canali) rispetto ai quali ricevere notifiche e messaggi. MQTT è attualmente in fase di normazione presso OASIS.
Architettura iFog4 basata su metodo Rami 4.0
RAMI 4.0 (Reference Architectural Model Industrie 4.0) è un modello che consente di rispettare lo standard Industria 4.0 [19]. Si tratta di un’architettura orientata ai servizi basata su una rappresentazione a tre assi, come illustrato in Fig. 1. Il primo asse rappresenta la struttura a livelli funzionali, che si è evoluta da una struttura basata sull’hardware a un modello di servizio distribuito in rete. Il secondo asse rappresenta il ciclo di vita del prodotto, dallo sviluppo, alla manutenzione, fino all’utilizzo, mentre il terzo asse mostra l’architettura del servizio a livelli. La sicurezza è alla base del modello RAMI 4.0, infatti le applicazioni sviluppate includono nel modello la sicurezza, declinata a partire dalla fase di progettazione.
Sono state proposte in letteratura [20][21] diverse architetture “Fog computing”. Alcune di esse si basano sul Modello di riferimento di Purdue (PRM). Tuttavia l’architettura IFog4.0 si basa sulla norma RAMI 4.0, ivi collocandosi in corrispondenza dei due livelli, specificatamente a “informazione” e “comunicazione”. Essa fornisce inoltre la piattaforma di calcolo “ai margini” (edge) utilizzando la finestra mobile del sistema di virtualizzazione. Inoltre l’architettura può essere facilmente implementata in ambiente industriale. In effetti, essa è progettata per sostenere elaborazione di confine collocata in architetture cloud ibride per piccole medie imprese (PMI), con elevati margini di sicurezza per le tradizionali esigenze industriali. Inoltre, essa si può connettersi facilmente anche a PLC utilizzando protocolli di comunicazione industriale. Tale architettura mostra come strumenti open source possano ridurre i costi trasferendo livelli di efficienza e efficacia adeguati al dominio dei requisiti rappresentato dalla PMI.
L’architettura della piattaforma proposta in questo lavoro è presentata in Fig. 2. È stata denominata IFog4.0 ed è basata sul kernel Linux v 4.15. Inoltre, essa è progettata per essere conforme ai requisiti critici delle applicazioni industriali, come rappresentato nella sezione III. La conformità ai vincoli è ottenuta utilizzando componenti come Fog Management, la virtualizzazione Docker, l’IDE, la visualizzazione, l’Enterprise Resource Management (ERP) e il Driver di comunicazione industriale.
IFog4.0 è una piattaforma industriale ad architettura “Fog” basata sulla norma RAMI4.0 [6]. È stato progettato utilizzando un approccio modulare che consente di installare e distribuire facilmente nuovi componenti e strumenti. In questo modo, è possibile aggiungere nuove funzionalità, a seconda dell’esigenza dell’applicazione. L’architettura è divisa in quattro livelli: il sistema operativo, la virtualizzazione, il sistema di gestione e il livello di rete.
Un sistema operativo basato su Linux-server
Ogni componente è stato accuratamente selezionato esaminando una serie di scelte disponibili, considerando tra le caratteristiche principali: la flessibilità, la modularità e la disponibilità della licenza open source. Inoltre, per le aree più critiche – come, ad esempio, il Driver per la Comunicazione Industriale – sono stati considerati i vincoli di throughput, latenza e correttezza. Il sistema operativo è basato su Linux-server e utilizza un modulo specifico, denominato “Industrial Communication Driver”, che è stato sviluppato appositamente per questa architettura. L’elevata flessibilità, che viene fornita dall’ambiente del kernel Linux, è la ragione principale della scelta, direttamente connessa alla semplicità del processo di integrazione di nuovi moduli personalizzati nello stesso kernel del sistema operativo.
Il sistema Fog-Management (il rettangolo verde in Fig. 2) viene eseguito al di sopra del sistema operativo, e al livello di virtualizzazione, che si basa sulla piattaforma Docker (evidenziata in blu in Fig. 2). Il sistema di contenitori Docker è ampiamente utilizzato nell’ambiente di sviluppo ed è open source. Esistono altre soluzioni simili basate su software proprietario o architetture meno stabili – come Linux Containers (LXC) – che non sono adatte allo scopo in quanto richiederebbero ulteriori attività di specializzazione per migliorarne la stabilità. Docker consente agli sviluppatori di progettare e distribuire facilmente nuovi componenti (scatole blu) nell’architettura. Il livello di rete è separato dagli altri livelli, come lo strato fisico della comunicazione industriale, che può essere basato su norme differenti come, ad esempio, la comunicazione seriale, il bus Hart o CAN. Tutti i moduli all’interno della casella tratteggiata in colore rosso sono strumenti open source.
Come mostra la Fig. 3, esistono due diversi tipi di moduli che possono essere sviluppati e accolti sulla piattaforma IFog4.0: il componente, che è un’entità realizzata offline utilizzando un Software Development Kit (SDK) dedicato, e che esegue un contenitore Docker immediatamente al di sopra del livello di virtualizzazione; l’applicazione, che è un modulo istanziato ed eseguito all’interno di un componente. Le applicazioni vengono sviluppate direttamente sulla piattaforma IFog4.0, utilizzando gli strumenti forniti dai componenti sottostanti.
Per dispiegare l’architettura IFog4.0, occorre sviluppare alcune componenti, che devono essere installate, come, ad esempio, il modulo “Fog Management”, gli strumenti di programmazione e di visualizzazione dei dati, l’Enterprise Resource Planning (ERP), il Data Storage e il Driver di comunicazione industriale. Tutte le componenti sono collocate nei corrispondenti contenitori dell’architettura.
Il modulo Fog-Management
È stato sviluppato per gestire i contenitori “Docker”. Esso consente anche di installare, eseguire e interrompere le applicazioni da un apposito cruscotto. Tale componente è in grado di condurre l’utente attraverso il processo di sviluppo di altre nuove componenti caricando il codice eseguibile corrispondente.
Nonostante le soluzioni esistenti per gestire i contenitori Docker (come, ad esempio, Portainer), lo sviluppo di una soluzione personalizzata consente la gestione diretta del processo di integrazione delle nuove funzionalità, garantendo maggiore flessibilità.
Fog-Management utilizza l’SDK Docker [22] per distribuire ed eseguire un nuovo contenitore, infatti l’SDK fornisce accesso alle API Docker, usando le quali è possibile istanziare, eseguire e terminare uno specifico contenitore. In altri termini, il comando eseguirà il file componente nella piattaforma IFog4.0. Il componente può essere raggiunto dall’utente finale, che, a sua volta, può essere in grado di sviluppare ed eseguire nuove applicazioni all’interno dello stesso contenitore. Inoltre, l’uso di contenitori Docker migliora la sicurezza dell’architettura IFog4.0 proposta, poiché i container non sono connessi direttamente a internet. Il modulo Fog-Management è l’unico componente esposto alla rete esterna. Deve essere connesso a internet per l’aggiornamento della stessa installazione, con ulteriore protezione fornita eventualmente da un firewall introdotto per i noti fini.
Come mostrato in Fig. 4, la piattaforma IFog4.0 comprende tre componenti principali: gli strumenti di programmazione, quelli di visualizzazione dei dati e il gestore delle risorse (Enterprise Resource Planning – ERP). Inoltre, per il monitoraggio complessivo del sistema, è presente un cruscotto informativo sullo stato della piattaforma relativamente all’utilizzo della CPU, lo stato della macchina in esecuzione e della relativa manutenzione.
Programmazione, visualizzazione dati e pianificazione risorse
Questa componente fornisce gli strumenti di programmazione resi disponibili da Node-RED [23], che è stato inizialmente sviluppato da IBM Emerging Technology come prodotto open source sotto Licenza Apache versione 2.0 [24] [25]. Questo strumento di sviluppo è basato sulla programmazione per flussi (FBP), confrontabile con la programmazione per blocchi funzionali (FBD), di cui alla norma IEC61131-3 per le applicazioni industriali. In questo paradigma di programmazione ciascuna applicazione è una scatola nera inserita in una rete omogenea, ove ciascun blocco, che ha propri ingressi e uscite, nell’ambiente Node-Red è rappresentato come nodo. Di conseguenza ciascun nodo può ottenere dati di ingresso e elaborarli secondo il sottoprogramma presente nel nodo. Ogni nodo è programmabile con Node-Js, che è runtime JavaScript. Nell’architettura IFog4.0, Node-RED viene usato come strumento di programmazione, e tre nodi sono stati sviluppati per l’architettura come driver relativi a strumenti industriali comuni: il nodo sensore di pressione, il nodo sensore di pressione differenziale e il nodo sensore di Temperatura. Come presentato in Fig. 5, ciascuno di essi è progettato seguendo requisiti che caratterizzano dispositivi industriali, quali ad esempio, intervalli minimo e massimo della grandezza fisica, soglie di allarme, tipo di strumento, unità di misura e l’ultimo tempo di calibrazione ai fini della manutenzione predittiva.
Visualizzazione dei dati. L’ambiente Grafana è stato utilizzato in questa architettura per la visualizzazione dei dati. Descrive le diverse connessioni a molte fonti di dati [26]. Inoltre, il cruscotto di visualizzazione si appoggia a MySQL, utilizzato anche in Node-RED. I dati di misurazione sono forniti dal PLC Siemens S7-1200 atTRAVERSO il protocollo S7 Profinet, trattato nella sezione IV.
Pianificazione delle risorse aziendali (ERP). Secondo il modello RAMI 4.0, ogni impresa richiede un adeguato sistema di pianificazione delle risorse aziendali (ERP), prevista al livello business della stessa architettura, pertanto l’ERP è stato incluso nella piattaforma IFog4.0, insieme alla visualizzazione dei dati e alla gestione dello sviluppo del software attraverso un ambiente di sviluppo integrato (IDE), oltre a un cruscotto di controllo. Odoo è stato utilizzato come gestionale aziendale (prevista nel Business Layer in RAMI), poiché comprende un ERP, la gestione della relazione con il cliente (CRM), la fatturazione, la contabilità, la gestione degli asset e la gestione delle scorte [27]. Si sottolinea che l’edizione community è open source, anche se è pur sempre possibile inserire plugin commerciali per estendere l’azione dell’applicazione nel suo complesso. Tutto ciò premesso, emerge anche come la piattaforma IFog4.0 consenta di tracciare lo stato di funzionamento e di manutenzione di tutti gli asset dell’impresa, infatti, il sistema di gestione interagisce con le sorgenti dei dati e consente di produrre un report da trasferire al livello superiore dell’architettura RAMI4.0.
Archiviazione dei dati e comunicazione industriale
L’archiviazione dei dati è sempre un aspetto chiave nell’elaborazione distribuita collocata al margine della rete, così come nell’architettura propria del Fog computing. MySql e Mongodb sono stati entrambi utilizzati in questa proposta. Inoltre, la piattaforma semplifica la distribuzione di nuove istanze del sistema di base dati aggiungendo semplicemente l’immagine Docker corrispondente nel Sistema di Fog Management.
Comunicazione industriale. L’adeguatezza dei protocolli di comunicazione è un requisito necessario per una piattaforma destinata ad operare in ambiente industriale. Lo stesso vale per alcune piattaforme IoT, che altrimenti non sarebbe compatibili con i requisiti di elaborazione espressi per ambienti ad elevata criticità. Per questo motivo, spesso vengono impiegati gateway per trasferire dati acquisiti in ambiente industriale alla rete IoT [28].
Come si può notare in Fig. 2, uno specifico driver di comunicazione è stato realizzato per il kernel Linux. L’architettura proposta opera con protocolli industriali diffusi e consolidati, quali Profinet, Modbus e OPC-UA. Tutti i componenti trattati nel caso di studio possono interagire con applicazioni industriali. Il sistema di distribuzione di componenti e applicazioni è rapido e diretto, in quanto richiede solamente l’installazione di eseguibili in ambiente Linux, fornito dalla piattaforma IFog4.0. In questo quadro lo scopo primario dell’esperienza discussa in questo lavoro è mostrare come la piattaforma possa essere resa disponibile anche alle PMI, in grado così di cogliere i vantaggi della tecnologia Industria 4.0. Tutta la piattaforma impiega strumenti open source e funzionalità aggiuntive sviluppate o adattate per le applicazioni industriali. Il meccanismo di distribuzione della piattaforma è stato simulato e validato utilizzando come caso di studio una stazione di regolazione del gas industriale, trattato nella prossima sezione.
Il caso di studio: iFog4.0 applicato a una stazione di regolazione gas
L’obiettivo di questa sezione è descrivere il dispiegamento dell’architettura IFog4.0 realizzato nel contesto di un’applicazione industriale selezionata per lo scopo. L’applicazione è raffigurata in Fig. 7, che riporta lo schema meccanico di un sistema in grado di ridurre la pressione di un gas da un valore troppo elevato a uno inferiore sostenibile. Lo schema raffigura due stadi di filtri, SCRUBBER e DRY-GAS, progettati rispettivamente per particelle grandi e piccole, solitamente presenti all’interno del flusso di gas. La pressione del gas in entrata è 1200 Psig (pound x square inch gauge), e dopo il filtraggio a due stadi, si riduce a 600 Psig utilizzando la valvola di controllo. Si noti che, all’atto della riduzione della pressione, se la temperatura diminuisce eccessivamente potrebbe determinare in breve tempo il danneggiamento del diaframma di quella stessa valvola. Per questo motivo, il Water Bath Heater (WBH) è stato inserito nella stazione di regolazione per elevare la temperatura del gas in ingresso fino a una temperatura di 60-65 gradi Celsius. Questa configurazione è stata dottata negli ultimi dieci anni ed è ora parte integrante dello standard internazionale ASME [29].
L’automazione del filtro del gas secco è stata realizzata in questa proposta utilizzando l’architettura Ifog4.0. Questo filtro assorbe le particelle solide usando cartucce filtranti. Poiché il flusso di gas è elevato, potrebbe manifestarsi una pressione differenziale tra i vasi, indicativamente ricompresa tra i 3 e 1 15 Psig, a seconda di quanto la cartuccia filtrante risulti essere piena. Come mostrato in figura, un trasmettitore di pressione differenziale (DPT) è stato integrato nel sistema per misurare tale valore in tempo reale.
Nel caso d’uso proposto sono presenti due sottosistemi principali, entrambi provenienti dal dominio dell’impiantistica industriale. L’architettura IFog4.0 può essere efficacemente testata su tali sottosistemi, che sono gestiti ciascuno attraverso uno specifico PLC.
Come mostrato in Fig. 7, entrambi i controllori dei sottosistemi e i corrispondenti emulatori sono istanziati all’interno dei PLC. Prima di discutere i risultati, nel seguito vengono descritti l’installazione dell’hardware di test e i criteri di configurazione.
Configurazione dell’hardware
La piattaforma hardware che ospita IFog4.0 deve essere dotata di risorse appropriate. In questo caso si è operato con una CPU multi-core e una rete Gigabit Ethernet: in particolare il PC ha un CPU Intel® Core ™ i5-6200U a 2.30 GHz a 4 core per il dispiegamento dell’architettura IFog4.0. Il Multi-core consente di sfruttare la capacità di parallelizzazione nativa della CPU.
In questo prototipo sono stati utilizzati due PLC S7-1200, entrambi simulano ed emulano il caso in esame. Uno switch Ethernet da 1 Gigabit è stato utilizzato per gestire la comunicazione tra la rete di PLC e la piattaforma IFog4.0. La configurazione dell’hardware è mostrata in Fig. 8. I due sottosistemi sono stati simulati usando gli stessi PLC.
Dopo aver impostato i requisiti hardware, IFog4.0 può essere installato su una macchina dedicata. Il processo di installazione è semplice e richiede i seguenti passi:
- scaricare l’immagine del server Linux Ubuntu (la piattaforma è basata sulla versione LTS 16.04);
- specializzare gli archivi presenti nel package Ubuntu aggiungendo il contenitore del motore Docker e il driver di kernel dedicato alla comunicazione industriale (versione 4.15) per sostenere le funzionalità connesse al tempo reale;
- dispiegare le componenti principali di IFog4.0, disponibili nel repository, come contenitori Docker;
- installare lo strumento Fog-Management, presente nel repository IFog4.0;
- avviare il sistema, ponendo in esecuzione prima Docker e successivamente Fog-Management;
- accedere al sistema Fog-Management, raggiungibile attraverso l’interfaccia web disponibile all’indirizzo http: // <indirizzo IP IFog4.0>:8000.
Il cruscotto presente nella pagina consente di visualizzare lo stato corrente del sistema, offrendo la possibilità di eseguire ulteriori specializzazioni. Inoltre, offre l’accesso diretto alle tre componenti principali di IFog4.0: Grafana, IDE (Node-Red) e ERP (Odoo). La comunicazione industriale e le componenti del servizio di base dati funzionano in background e non sono mostrati nell’applicazione Fog-Management.
Simulazione: le prove in laboratorio
Node-Red è stato utilizzato per realizzare l’automazione della stazione di regolazione del gas, come descritto nelle precedenti sessioni. Il driver è stato sviluppato all’interno di Node-RED per pianificare l’interazione con le applicazioni PLC e IFog4.0. Node-RED ha un’interfaccia drag-and-drop estremamente intuitiva che consente di progettare e sviluppare facilmente una nuova applicazione. Il nodo denominato UI permette di sviluppare un’interfaccia web veloce rendendo disponibili cruscotti con grafici semplici, ma adatti a rappresentare anche specifiche grandezze fisiche. Come mostrato in Fig. 6, WBH dispone di quattro sensori di temperatura collegati come ingressi all’applicazione, che deve pilotare l’accensione o lo spegnimento del motore riscaldatore WBH.
Per automatizzare il processo, un algoritmo viene utilizzato per controllare la temperatura del gas in uscita. Il processo di controllo legge il valore di temperatura del gas di ingresso e di uscita tenendo conto dei valori della temperatura esterna. Il controllore PID decide di accendere o meno il motore in base a un valore di set point impostato su WBH. Come raffigurato nel P&ID in figura, è presente un sensore di temperatura ambiente che legge la temperatura esterna.
Il secondo sottosistema è il filtro del gas secco. L’obiettivo principale è automatizzare la manutenzione della cartuccia del filtro. Come spiegato nel paragrafo dedicato al caso di studio, la pressione differenziale aumenta quando il filtro è pieno, pertanto il sensore di pressione differenziale rileva tali valori direttamente sul vaso. Il valore rilevato del sensore è monitorato dall’applicazione, che prende la decisione di aprire la valvola di scarico quando il valore del sensore è più elevato rispetto al set-point.
Come illustrato in Fig. 9 è disponibile un’interfaccia (UI) specifica per il caso d’uso, composta da un regolatore rispetto al set-point per la temperatura in uscita del gas nel WBH e un grafico online per la rappresentazione dei dati in tempo reale, memorizzati anche in un database Mysql.
L’applicazione di analisi è stata sviluppata utilizzando lo strumento analitico Grafana, che utilizza MySql come origine dei dati. È presente anche un sistema ERP che aiuta a pianificare la manutenzione preventiva utilizzando il tempo di calibrazione definito dal nodo Instrument Driver presente nella programmazione realizzata con Node-RED.
In effetti l’ERP elabora i tempi di calibrazione e può pianificare l’operazione sui dispositivi considerando l’incidenza delle informazioni attinenti le procedure di manutenzione tecnica preventiva, anche seguendo le indicazioni tracciate nello standard ISA [30].
La sperimentazione proposta si riferisce, infatti, a un tipico impianto industriale. In particolare, come mostrato in questa sezione, IFog4.0 fornisce un insieme di applicazioni di base finalizzato allo sviluppo dell’automazione degli impianti che adottano il sistema di riferimento RAMI4.0. La piattaforma può essere personalizzata rispetto alle esigenze di ciascun impianto. Nonostante la sperimentazione sia stata realizzata in un ambiente laboratoriale protetto, essa può essere facilmente trasferita nelle applicazioni reali. Infatti il sistema trasmette e riceve informazioni utilizzando lo standard ISA per la sottorete industriale ed è inoltre possibile trasferire la sperimentazione dall’ambiente emulato a quello reale modificando l’indirizzo IP dei PLC.
BIBLIOGRAFIA
[1] J. Lee, B. Bagheri, and H.-A. Kao, “A cyber-physical systems architecture for industry 4.0-based manufacturing systems,” Manufacturing Letters, vol. 3, pp. 18 – 23, 2015. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S221384631400025X
[2] F. Shrouf, J. Ordieres, and G. Miragliotta, “Smart factories in industry 4.0: A review of the concept and of energy management approached in production based on the internet of things paradigm,” in 2014 IEEE International Conference on Industrial Engineering and Engineering
Management, Dec 2014, pp. 697–701.
[3] L. D. Xu, E. L. Xu, and L. Li, “Industry 4.0: state of the art and future trends,” International Journal of Production Research, vol. 56, no. 8, pp. 2941–2962, 2018. [Online]. Available: https://doi.org/10.1080/00207543.2018.1444806
[4] M. Mukherjee, L. Shu, and D. Wang, “Survey of fog computing: Fundamental, network applications, and research challenges,” IEEE Communications Surveys Tutorials, vol. 20, no. 3, pp. 1826–1857, thirdquarter 2018.
[5] M. Wollschlaeger, T. Sauter, and J. Jasperneite, “The future of industrial communication: Automation networks in the era of the internet of things and industry 4.0,” IEEE Industrial Electronics Magazine, vol. 11, no. 1, pp. 17–27, March 2017.
[6] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in the internet of things,” in Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, ser. MCC ’12. New York, NY, USA: ACM, 2012, pp. 13–16. [Online]. Available: http://doi.acm.org/10.1145/2342509.2342513
[7] B. Chen, J.Wan, L. Shu, P. Li, M. Mukherjee, and B. Yin, “Smart factory of industry 4.0: Key technologies, application case, and challenges,” IEEE Access, vol. 6, pp. 6505–6519, 2018.
[8] I. Stojmenovic and S. Wen, “The fog computing paradigm: Scenarios and security issues,” in 2014 Federated Conference on Computer Science and Information Systems, Sep. 2014, pp. 1–8.
[9] S. Yi, C. Li, and Q. Li, “A survey of fog computing: Concepts, applications and issues,” in Proceedings of the 2015 Workshop on Mobile Big Data, ser. Mobidata ’15. New York, NY, USA: ACM, 2015, pp. 37– 42. [Online]. Available: http://doi.acm.org/10.1145/2757384.2757397
[10] P. Hu, S. Dhelim, H. Ning, and T. Qiu, “Survey on fog computing: architecture, key technologies, applications and open issues,” Journal of Network and Computer Applications, vol. 98, pp. 27 – 42, 2017. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1084804517302953
[11] B. P. Rimal, E. Choi, and I. Lumb, “A taxonomy and survey of cloud computing systems,” in 2009 Fifth International Joint Conference on INC, IMS and IDC, Aug 2009, pp. 44–51.
[12] J. Wan, H. Cai, and K. Zhou, “Industrie 4.0: Enabling technologies,” in Proceedings of 2015 International Conference on Intelligent Computing and Internet of Things, Jan 2015, pp. 135–140.
[13] A. Dastjerdi, H. Gupta, R. Calheiros, S. Ghosh, and R. Buyya, “Chapter 4 – fog computing: principles, architectures, and ˘applications,” in Internet of Things, R. Buyya and A. V. Dastjerdi, Eds. Morgan Kaufmann, 2016, pp. 61 – 75. [Online]. Available: http://www.sciencedirect.com/science/article/pii/B9780128053959000046
[14] I. Stojmenovic, “Fog computing: A cloud to the ground support for smart things and machine-to-machine networks,” in 2014 Australasian Telecommunication Networks and Applications Conference (ATNAC), Nov 2014, pp. 117–122.
[15] Profinet, “Profinet,” https://www.profibus.com/technology/profinet/, accessed: 2019/02/06.
[16] Modbus, “Modbus protocol,” http://modbus.org/, accessed: 2019/02/06.
[17] O. Foundation, “Opc ua system,” https://opcfoundation.org/about/whatis- opc/, accessed: 2019/02/06.
[18] MQTT.org, “Mqtt protocol,” http://mqtt.org/faq, accessed: 2019/02/06.
[19] “Rami4.0 standard.” [Online]. Available: https://www.plattformi40.de/I40/Redaktion /DE/Anwendungsbeispiele/265-agentenbasiertevernetzung- von-cyber-physischen-produktionssystemen-tumuenchen/agentenbasierte-vernetzung-von-cyber physischenproduktionssystemen.html
[20] W. Steiner and S. Poledna, “Fog computing as enabler for the industrial internet of things,” e & i Elektrotechnik und Informationstechnik,
vol. 133, no. 7, pp. 310–314, Nov 2016. [Online]. Available: https://doi.org/10.1007/s00502-016-0438-2
[21] C. C. Byers, “Architectural imperatives for fog computing: Use cases, requirements, and architectural techniques for fog-enabled iot networks,” IEEE Communications Magazine, vol. 55, no. 8, pp. 14–20, Aug 2017.
[22] “Develop with docker engine sdks and api,” Jan 2019. [Online]. Available: https://docs.docker.com/develop/sdk/
[23] “Node-red,” Jan 2019. [Online]. Available: https://nodered.org/
[24] “Ibm emerging technology,” Jan 2019. [Online].
[25] “Js foundation,” Jan 2019. [Online]. Available: https://js.foundation/
[26] “Grafana – the open platform for analytics and monitoring,” Jan 2019. [Online]. Available: https://grafana.com/
[27] B. Z. Cadersaib, H. B. Sta, and B. A. G. Rahimbux, “Making an interoperability approach between erp and big data context,” in 2018
Sixth International Conference on Enterprise Systems (ES), Oct 2018, pp. 146–153.
[28] M. Hemmatpour, M. Ghazivakili, B. Montrucchio, and M. Rebaudengo, “Diig: A distributed industrial iot gateway,” in 2017 IEEE 41st Annual Computer Software and Applications Conference (COMPSAC), vol. 1, July 2017, pp. 755–759.
[29] J. R. Farr and M. H. Jawad, Design of Heat Exchangers. New York, NY: ASME, 2019/02/12 2006, ch. Design of Heat Exchangers, book, Section. [Online]. Available: http://dx.doi.org/10.1115/1.802396.ch7
[30] ISA, “Isa,” https://www.isa.org/, accessed: 2019/02/06.
FIGURE
Fig. 1 – Architettura RAMI 4.0 – Fonte: Plattform Industrie 4.0
Fig. 2 – IFog4.0: Industria 4.0, architettura Fog Open Source
Fig. 3 – Architettura IFog4.0: componenti and applicazioni
Fig. 4 – Fog-Management per componenti e applicazioni
Fig. 5 – Node-Red: strumenti di programmazione per ambienti Fog
Fig. 6 – Diagramma Pipe-Instrument (P&ID) raffigurante la regolazione di un impianto gas (caso d’uso)
Fig. 7 – Riscaldatore del bagno d’acqua (WBH): collegamenti con il PLC
Fig. 8 – Configurazione del test-bed
