Uno degli elementi architetturali fondamentali nella visione di Industria 4.0 è il digital twin (gemello digitale), basato sull’intuizione che ogni entità fisica debba avere una rappresentazione fedele nel mondo digitale. Sebbene il termine venga utilizzato in ambiti più ampi, per esempio per indicare le identità digitali delle persone fisiche o molti dispositivi IoT, esso dà origine a interessanti possibilità di utilizzo nell’ambito industriale.
Le aziende italiane hanno iniziato la transizione a Industria 4.0, e dovranno accelerare nel tempo, come anche la recente emergenza Covid-19 ha dimostrato, se si vuole mantenere la resilienza del sistema produttivo e contemporaneamente aumentarne la produttività attraverso l’inserimento nativo di flessibilità ed adattività agli eventi. Architetture come quelle che andiamo a presentare e framework tecnologici dovranno essere analizzati, compresi, dispiegati e realizzati nei prossimi anni in modo da diventare parte integrante della strategia per l’innovazione tecnologica e la digitalizzazione del Paese entro il 2025.
L’utilizzo dei digital twin
In primis bisogna chiarire che un digital twin (DT) espone un insieme di servizi che consentono di eseguire determinate operazioni e produrre dati che descrivono l’attività dell’entità fisica (es. un macchinario industriale) rappresentato. In sistemi industriali di recente installazione, le macchine potrebbero essere dotate nativamente di un loro gemello digitale; in altri casi, soprattutto quando l’approccio è applicato a fabbriche e processi di produzione già consolidati, i gemelli digitali sono ottenuti incapsulando (wrapping) attori (macchinari, fornitori ed interfacce con l’utente) che sono già in funzione.
Tutte le definizioni di DT concordano su alcune caratteristiche essenziali, quali
- la connettività, ovvero la capacità di comunicare in rete con altre entità e DT,
- l’autonomia, ovvero possibilità per il DT di vivere indipendentemente dalle altre entità,
- l’omogeneità, ovvero la capacità, strettamente connessa all’autonomia, che consente di utilizzare lo stesso DT indipendentemente dallo specifico ambiente di produzione,
- la facilità di personalizzazione, ovvero la possibilità di modificare il comportamento di un’entità fisica utilizzando le funzionalità esposte dal suo DT
- la tracciabilità, vale a dire il fatto che un DT lascia tracce dell’attività dell’entità fisica corrispondente.
I framework per lo sviluppo dei digital twin
Recentemente alcuni framework per la descrizione e sviluppo di DT sono stati proposti dai vendor commerciali e dalle comunità open source. Nel seguito, ne esaminiamo alcuni , e proponiamo un’architettura concettuale in cui i DT sono composti dinamicamente al fine di raggiungere specifici obiettivi di produzione, con funzionalità adattive integrate. Una possibile architettura di riferimento per processi smart è presentata nella figura seguente, in cui i componenti principali sono i DT, il datastore industriale, i supervisori umani e un mediatore.
Figura A. Architettura di riferimento per processi di produzione “intelligenti” (smart process) (tratta da Tiziana Catarci, Donatella Firmani, Francesco Leotta, Federica Mandreoli, Massimo Mecella, Francesco Sapio: A Conceptual Architecture and Model for Smart Manufacturing Relying on Service-Based Digital Twins. ICWS 2019: 229-236)
I DT incapsulano le entità fisiche coinvolte nel processo. Queste entità fisiche possono essere macchine per la produzione o operatori umani. Un DT espone una web API costituita, in generale, da tre parti: quella sincrona (bloccante), l’interfaccia di query e quella asincrona (non bloccante, a notifiche). L’interfaccia sincrona consente di dare istruzioni all’entità fisica. Queste istruzioni possono, ad esempio, produrre un cambiamento di stato in una macchina di produzione (nel caso in cui il DT sia “sopra” una macchina) o chiedere a un operatore umano di eseguire un’attività manuale (nel caso in cui il DT si trovi “sopra” un operatore in fabbrica). L’interfaccia di query consente di chiedere informazioni all’entità fisica sul suo stato e le informazioni correlate; queste ultime possono essere ottenute anche applicando i risultati di funzioni diagnostiche e prognostiche basate su tecniche di AI/deep learning. L’interfaccia asincrona genera eventi, relativi solitamente alla generazione continua in streaming di dati di sensore oppure ad errori ed allarmi. È importante notare come sia le macchine di produzione che gli attori umani possano essere considerati identici dal punto di vista dell’API offerta: anche gli attori umani producono eventi asincroni, ad esempio generando allarmi.
La disponibilità dei dati
In tale contesto, i dati sono generalmente disponibili attraverso diverse fonti che non condividono uno schema e un vocabolario comuni, poiché i DT provengono da fornitori diversi. È ragionevole considerare uno dataspace eterogeneo in cui è presente un mediatore che assume anche il ruolo di traduttore tra diversi formalismi e metodi di accesso. Il machine/deep learning è una caratteristica fondamentale di un DT. Le funzioni apprese includono la generazione automatica di allarmi, ma anche l’attivazione automatica di azioni e cambiamenti di stato. Inoltre, i DT possono essere interrogati sulle funzioni apprese e, di conseguenza, il dataspace è molto più dinamico che in scenari più tradizionali. Il dataspace contiene tutti i dati disponibili per il processo.
Questi dati sono eterogenei nella loro natura dal punto di vista della tecnologia di accesso, dello schema impiegato (o della sua eventuale assenza, schemaless) e del vocabolario impiegato. È importante notare come i DT contribuiscono al dataspace sia con l’API di query sia con quella asincrona. Altre fonti che fanno parte del sistema informativo della fabbrica possono includere database relazionali e no-SQL o fonti non strutturate come file.
L’importanza della supervisione umana
Il supervisore umano è quello che definisce gli obiettivi del processo in termini sia di risultati finali che di indicatori chiave di prestazione da ottenere. Per raggiungere l’obiettivo definito dal supervisore umano, i DT e i dati disponibili devono essere composti, integrati ed orchestrati. Questo compito è svolto dal mediatore. Il mediatore agisce in due fasi: la fase di sintesi e la fase di esecuzione. Durante la fase di sintesi, le specifiche delle API esposte dai DT e i metadati (ad es. schemi delle fonti di dati) disponibili nel dataspace, sono composte al fine di costruire il processo. Durante la fase di esecuzione, il mediatore esegue il suo programma (il processo sintetizzato appunto) preparando i messaggi di input per i singoli DT coinvolti seguendo la corretta schedulazione. Infatti, poiché ogni DT può potenzialmente adottare una lingua e un vocabolario diversi, al fine di comporre i messaggi di input / output richiesti, il mediatore traduce e integra i dati disponibili nel dataspace per conformarsi al formato richiesto dallo specifico servizio chiamato.
Un aspetto importante dell’architettura proposta è che più aziende possono partecipare al processo (in genere quelle coinvolte nella catena del valore). Anche in questo caso, non è ragionevole avere due DT che comunicano direttamente tra loro. Ancora una volta, il ruolo del mediatore è fondamentale, essendo il componente che può accedere ai servizi offerti dai DT disponibili nelle diverse società. I vendor tradizionali e le iniziative open source hanno iniziato a fornire supporto a diversi aspetti collegati ai DT, tra cui servizi di specifica, implementazione, e hosting. Tuttavia mancano ancora funzionalità, incluso il supporto nativo alla simulazione e all’integrazione dei dati.
Esempi di piattaforme per digital twin
Eclipse Ditto è una piattaforma open source per implementare DT. In particolare, fornisce supporto per
- definire API che astraggono l’entità fisica dietro un DT,
- instradare richieste tra l’hardware sottostante (il macchinario) ed il client,
- gestire criteri di controllo degli accessi,
- notifiche.
Per Eclipse Ditto il DT è un’astrazione di un asset / dispositivo del mondo reale con tutte le capacità e gli aspetti, inclusa la sua rappresentazione digitale. Eclipse Vorto è una piattaforma il cui obiettivo è definire specifiche di DT e generare automaticamente codice (ad esempio, basato sul framework Eclipse Ditto). Vorto fornisce librerie e strumenti di integrazione per evitare l’accoppiamento stretto dei dispositivi nelle soluzioni basate su IoT. Pertanto, può fungere da strato di astrazione su diversi dispositivi, consentendo una comunicazione uniforme nonostante la diversità dei protocolli. I DT sono descritti usando un linguaggio specifico offerto dalla piattaforma.
Bosch IoT Things è una soluzione basata su cloud per ospitare DT basati su Ditto. Ad ogni modo, Bosch IoT Things non è un semplice wrapper cloud per Ditto, in quanto fornisce funzionalità aggiuntive predefinite come: integrazione con altri progetti IoT Eclipse; un’interfaccia utente Web per il monitoraggio e la gestione dei DT; la possibilità di estendere le funzionalità di Eclipse Ditto con altri servizi appartenenti alla suite IoT Bosch (ad esempio, autorizzazioni per gestire utenti e permessi)
AWS IoT Device Shadow Service è fornito come parte della piattaforma AWS IoT. È un documento JSON utilizzato per archiviare e recuperare le informazioni sullo stato corrente per un dispositivo. Il servizio mantiene un’”ombra” per ogni dispositivo collegato a AWS IoT, dove viene utilizzata per ottenere e impostare lo stato di un dispositivo, indipendentemente dal fatto che il dispositivo sia connesso a Internet.
Azure Digital Twins è un servizio IoT (parte dei servizi cloud di Azure) il cui obiettivo è creare modelli di ambienti fisici con grafi di intelligenza spaziale, una tecnica per rappresentare le relazioni tra persone, luoghi e dispositivi in modo gerarchico. Tali grafi sono popolati da istanze di modelli di oggetti, che descrivono concetti, categorie e proprietà specifici del dominio. IoT Plug and Play fa parte della piattaforma Azure e fornisce quasi gli stessi servizi di Eclipse Vorto, che sono: un linguaggio per descrivere i DT; un repository contenente dispositivi IoT plug&play pronti (Azure IoT Central); strumenti e librerie per integrare i dispositivi. I DT sono descritti usando il Digital Twin Definition Language.
Conclusione
Gli strumenti e i framework appena introdotti consentono di implementare la maggior parte dell’architettura precedentemente introdotta. In particolare, le interfacce sincrone e asincrone esposte da un DT sono facilmente supportate poiché i framework, come Eclipse Ditto, consentono di comunicare con la “cosa” dietro il DT in entrambe le modalità. Inoltre, esistono linguaggi di specifica, come Eclipse Vorto, che consentono di definire classi di DT con i rispettivi attributi, variabili di stato e operazioni. Le soluzioni possono essere implementate on premise o nel cloud. Quest’ultima possibilità semplifica lo scenario in cui il processo da automatizzare abbraccia diverse organizzazioni. Un aspetto che viene solitamente trascurato dalle soluzioni disponibile è il supporto per la simulazione e la previsione, che è una parte fondamentale dell’architettura proposta. Se, da un lato, la simulazione e la previsione possono essere offerte con canali simili a quelli delle altre interfacce, dall’altro lato, tali funzionalità richiedono il supporto di prospettive virtuali sullo stato del dispositivo, che di solito non sono fornite immediatamente nelle soluzioni disponibili.
_
Note
- Cfr. C. Santos, A. Mehrsai, A.C. Barros, M. Araújo, E. Ares (2017). Towards Industry 4.0: an overview of European strategic roadmaps. In Procedia Manufacturing, Volume 13, Pages 972-979, ISSN 2351-9789,. ↑
