Come visibile nell’architettura generale del sistema riportata in Figura 3.1, l’IIoT Layer è solo uno dei componenti del sistema nel suo complesso. Questo si colloca nella parte in basso a sinistra, fra il Middleware e i wearable devices. È infatti composto da agenti e Gateway.
Il Gateway è responsabile di abilitare la connessione tra il Middleware IIoT e i dispositivi, inclusi i dispositivi indossabili, creando un canale di comunicazione sicuro e affidabile.
I diversi sensori sono collegati al Gateway grazie agli Agents, componente software ap-partenente al gateway, destinato a raccogliere dati psicofisici dai dispositivi collegati. Se necessario, il Gateway potrebbe prevedere anche semplici algoritmi di preelaborazione al fine di ridurre la quantità di dati trasmessi al Middleware IIoT.
Figura 3.1: Architettura generale del sistema (progetto STAR)
Inoltre, Agenti e Gateway fungono da interfacce standard per accedere al Middleware IIoT, il che significa che sono responsabili dello streaming dei dati secondo formati di dati prede-finiti. In questo modo, l’armonizzazione dei dati è preservata per costruzione, poiché tutti i Gateway scrivono le informazioni utilizzando formati di dati condivisi, impedendo così a Gateway diversi di scrivere le stesse informazioni in formati diversi. Viene proposto un for-mato dati specifico per ogni tipo di informazione (ad esempio, frequenza cardiaca, gsr, ecc.) e la sua documentazione sarà accessibile tramite l’Orchestrator, aiutando gli sviluppatori a capire come implementare correttamente il Gateway dati. Sono preferiti formati di dati leg-geri (es. chiave-valore), in modo tale da ridurre l’overhead necessario per trasformare i dati grezzi provenienti dai sensori nel formato desiderato.
Il Gateway trasmette i dati su un particolare topic nel Middleware IIoT, dedicato al worker con cui si sta interfacciando. Questo permette di evitare la gestione della sincronizzazio-ne dei dati poiché in un topic sono presenti dati con la stessa frequenza, provenienti dallo stesso dispositivo. Inoltre, i Moduli Funzionali, inclusi i moduli AI come il Fatigue Monitoring System, possono lavorare direttamente con i dati provenienti dai sensori, applicando così le proprie tecniche di preelaborazione senza influenzare i dati in streaming sul Middleware IIoT.
Di seguito vengono descritti gli altri componenti che costituiscono l’architettura del sistema nel suo complesso:
• Middleware IIoT : il suo obiettivo principale è rendere disponibili i diversi flussi di dati a ciascun componente dell’architettura. Fondamentalmente, ogni componente connes-so può fungere da fornitore e/o consumatore. Ciò consente a determinati componenti
di consumare gli output prodotti da altri (ad es. un Modulo Funzionale può consumare dati provenienti da un altro Modulo Funzionale). I messaggi scambiati (le cui strutture sono descritte nei Data Descriptors) sono definiti nell’Orchestrator a livello di com-ponente, in modo che ogni componente connesso possa specificare lo schema dei messaggi che verranno pubblicati sull’IIoT Middleware. Un broker MQTT viene utiliz-zato per implementare il Middleware, poiché è un protocollo di scambio di messaggi leggero e veloce. Viene implementato un topic per ogni lavoratore e un sotto-topic per ogni flusso di dati riguardante una metrica o un modulo. L’architettura del sistema per-mette comunque di sostituire il Broker utilizzato nel caso in cui in futuro si decidesse di cambiare quello utilizzato.
• Orchestrator e Administration shell: l’orchestrator è il componente principale respon-sabile dell’organizzazione e della gestione dell’intero Human Digital Twin. L’ammini-strazione avviene tramite una serie di API REST. L’orchestrator sa come sono struttu-rati l’HDT e la sua architettura. Inoltre, sa chi sono gli operatori, quali sono i moduli installati, i sensori collegati e gli schemi di messaggio adottati dai diversi moduli e sen-sori. L’orchestrator fornisce una serie di API REST per consentire ai moduli funzionali di recuperare dati quasi statici (ad es., competenze dei lavoratori) dal core HDT. Inol-tre, l’Orchestrator integra una shell di amministrazione che consente agli amministra-tori HDT di definire nuovi lavoraamministra-tori, connettere nuovi dispositivi indossabili e sensori, ecc. tramite una GUI fornita. Quest’ultima permette anche la visualizzazione dei dati, delle metriche e degli output dei Moduli Funzionali, consentendo all’utente di vedere le diverse informazioni scambiate nell’HDT. Infine, la GUI supporta la classificazione dei lavoratori. Per facilitare questa attività, attraverso le GUI viene visualizzato un questio-nario per consentire l’auto-caratterizzazione dei lavoratori. L’orchestrator si avvale di un database SQL (Platform data PostgreSQL), per memorizzare tutte le informazioni amministrative e organizzative.
• Video image streamer : ha lo scopo di consentire ai vari moduli di accedere a un flusso video di un’area dell’impianto o di una cella di lavoro. Attualmente ci sono due opzioni: memorizzare i video in un videoregistratore di rete (NVR) e utilizzare il protocollo RTSP per rendere disponibile il flusso video quasi in tempo reale.
• Persistency Layer : per supportare l’implementazione HDT, sono integrati i seguenti database (evidenziati in arancione in Figura 1):
– PostreSQL: è un database di relazioni tra entità potente e open source che sfrut-ta ed estende il linguaggio SQL combinato con molte funzionalità per archiviare in modo sicuro e scalare virtualmente la quantità di dati in qualsiasi applicazione.
Nel contesto dell’HDT, viene utilizzato per memorizzare dati statici e quasi statici dell’HDT, principalmente descritti da CharacteristicDescriptor. [7]
– MongoDB: è un database NoSQL che memorizza i dati in documenti simili a JSON. Poiché non c’è limite allo schema di ogni documento archiviato, è molto flessibile e facile da usare. La flessibilità di MongoDB si adatta particolarmen-te bene all’HDT, dove ogni Modulo Funzionale può avere le sue caratparticolarmen-teristiche specifiche e lo schema di output. Nell’HDT, l’obiettivo principale di MongoDB è quello di conservare lo storico dei dati complessi generati dai vari Moduli Funzio-nali, consentendo di mantenere un backlog di ogni previsione o stima effettuata da ciascun modulo installato. [8]
– InfluxDB: è un database open source progettato specificamente per l’elabora-zione di dati di serie temporali. È ideale per qualsiasi caso d’uso di big data in cui la dimensione temporale è importante quanto i dati stessi (ad esempio, casi d’uso che coinvolgono dati di sensori IoT e analisi in tempo reale). Nell’ambito dell’HDT, InfluxDB viene utilizzato in modo simile a MongoDB, ma invece di me-morizzare i dati complessi che provengono dai moduli, supporta l’archiviazione dei dati ad alta frequenza provenienti dai vari sensori installati nell’impianto o in-dossati dai lavoratori. La decisione di utilizzare Influx invece di conservare tutto in MongoDB è stata quella di consentire una memorizzazione più flessibile ed efficiente dei valori dei sensori. Influx è ottimizzato per l’archiviazione rapida e ad alta disponibilità e il recupero di dati di serie temporali. [9]
• History keeper module: è responsabile della memorizzazione di tutti i dati pubblica-ti nel Middleware IIoT. È sottoscritto per ogni argomento che scorre sul Middleware IIoT. Non appena viene pubblicata una nuova informazione, l’History keeper module memorizza questi dati in una serie temporale dedicata in InfluxDB o in un JSON de-dicato in MongoDB, a seconda delle fonti di dati (sensore o Modulo Funzionale). Ciò consente di conservare le informazioni storiche utilizzate soprattutto da quei moduli che visualizzano dati di serie temporali, eseguono analisi e ottimizzazioni o adde-strano modelli di intelligenza artificiale. L’History keeper module deve anche gestire la politica di conservazione dei dati, al fine di evitare di archiviare i dati per troppo tempo.
Infine, ci sono i Modelli Funzionali, evidenziati in verde in Figura 1. Sono componenti colle-gabili, inclusi i moduli AI, che possono essere facilmente aggiunti o rimossi dall’HDT. Questi Moduli Funzionali possono essere iscritti ai topic dell’IIoT Middleware di loro interesse, al fine di utilizzare flussi di dati da sensori e output di altri Moduli Funzionali per eseguire i loro calcoli. Inoltre, possono anche recuperare dati quasi statici dall’HDT tramite l’API REST fornita dall’Orchestrator. I Moduli Funzionali hanno anche la possibilità di pubblicare i propri output nel Middleware IIoT. Di seguito vengono descritti i vari moduli presenti:
• Fatigue Monitoring System: è un componente software il cui scopo è quello di rilevare possibili disagi psicologici (es. perdita di attenzione, affaticamento mentale) o fisici
(es. stanchezza) o situazioni dannose per un lavoratore. Il sistema di monitoraggio della fatica si basa sui dati fisiologici trasmessi dai dispositivi wearable ai Gateway e da quest’ultimo al Middleware IIoT a cui è iscritto il modulo. I dati fisiologici sono arricchiti con le informazioni quasi statiche memorizzate nell’HDT. Il sistema di monitoraggio della fatica utilizza questi dati arricchiti per calcolare il livello di sforzo percepito del lavoratore. L’output di calcolo viene quindi pubblicato sul Middleware IIoT per rendere disponibili queste informazioni agli altri componenti.
• Mental and Emotional Condition Detection Module: ha il compito di valutare lo stato mentale ed emotivo dei lavoratori. Questo viene fatto acquisendo i dati del batti-to cardiaco (EDA) o l’elettroencefalogramma (EEG), il segnale sonoro dei movimenti dei muscoli facciali e la meccanomiografia a pressione superficiale (MMG). Le fon-ti di quesfon-ti dafon-ti sono: smartwatch, microfoni a stetoscopio su caschi intelligenfon-ti e meccanomiografia a pressione tessile sulla fronte.
• Activity Detection Module: consente di rilevare il tipo di attività che l’operatore sta svol-gendo in un determinato periodo di tempo. I dati richiesti provengono da vari sensori IMU come lo Shimmer 3 e anche da uno smartwatch. Ciò consente di raccogliere i dati inerziali e biofisici necessari per svolgere il compito di riconoscimento dell’attività del lavoratore.
• Safety Zones Detection System: l’obiettivo è rilevare e localizzare le persone nelle infrastrutture critiche. Inoltre, questo modulo rileva oggetti in movimento (ad es. robot) e oggetti statici che sono stati spostati nella scena e che potrebbero essere nuovi ostacoli in futuro. Come input, prende un flusso RTSP e fornisce come output in tempo reale un oggetto JSON contenente il timestamp, le posizioni 3D o 2D e il tipo di entità osservata. Internamente, il modulo utilizzerà probabilmente ZeroMQ per gestire lo scambio di messaggi in modalità pub/sub.
• Workers’ Training Platform: è l’entry point web per i lavoratori che vogliono realizza-re azioni di formazione e apprealizza-rendimento continuo sui diversi moduli e strumenti che fanno parte del progetto. La piattaforma sarà composta da 3 parti principali: rac-comandazione di programmi di formazione; documenti e materiali sui diversi moduli e soluzioni sviluppate; punto di accesso ai diversi ambienti di simulazione. Al fine di facilitare lo sviluppo di ciascuna soluzione e lo sfruttamento post-progetto, l’inte-grazione cercherà di essere il più disaccoppiata possibile. L’obiettivo è che gli altri moduli/strumenti risiedano sulle proprie piattaforme e che la Workers’ Training Plat-form sia il punto di accesso a queste piattaPlat-forme. Durante il progetto verrà discusso se l’integrazione avverrà tramite routing, contenuto incorporato o componenti web.