HUMAN DIGITAL TWIN: IIOT LAYER - C10367 DELL'OCA SAMUELE - IN SUPSI TESI
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Human Digital Twin: IIoT Layer
Studenti Relatore
Dell’Oca Samuele Landolfi Giuseppe
Correlatore
Bonomi Niko
Committente
ISTePS - SPS Lab
Corso di laurea Codice progetto
Ingegneria Informatica C10367
Anno
2020/2021
Data
3 settembre 2021
i
Indice
Abstract (italiano) 1
Abstract (english) 3
Progetto assegnato 5
1 Introduzione 7
1.1 Tema trattato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Motivazione e contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Analisi iniziali 11
2.1 Requisiti e specifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analisi bibliografica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Industria 4.0 e Digital Twin . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Dispositivi wearable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Relazione fra metriche e salute dell’operatore . . . . . . . . . . . . . . 15
3 Progettazione 17
3.1 Progettazione generale del sistema . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Progettazione specifica del componente . . . . . . . . . . . . . . . . . . . . . 22
3.3 Scelte tecnologiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Analisi e Benchmark dei Broker . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Classificazione e scelta dei wearable device . . . . . . . . . . . . . . . 29
3.4 Progettazione del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Implementazione 39
4.1 Device Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1 Garmin Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.2 Polar Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.3 Empatica Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Device manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Gateway manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Human Digital Twin: IIoT Layer
ii INDICE
4.3.1 Orchestator Connector . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Persistency Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Broker manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 MQTT Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Historical Data Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Dashboard Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Testing e deployment 51
5.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Valutazione 53
6.1 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Criticità note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Migliorie future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Limiti del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5 Commento al piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.6 Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Conclusioni 61
Allegati 65
Human Digital Twin: IIoT Layer
iii
Elenco delle figure
3.1 Architettura generale del sistema (progetto STAR) . . . . . . . . . . . . . . . 18
3.2 Architettura IIoT Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Test con 10 publisher/subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Test con 100 publisher/subscriber . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Significato dei punteggi attribuiti . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Struttura AHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Risultato AHP grafico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 Risultato AHP percentuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 Calcolo del punteggio per il dispositivo . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Pianificazione iniziale del lavoro tramite diagramma di Gantt . . . . . . . . . . 37
4.1 Schermata app smartwatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Richiesta permessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Richiesta id worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Connessione a Polar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Connessione a Empatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Dashboard principale Grafanaa . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Dashboard dettagli metrica Grafana . . . . . . . . . . . . . . . . . . . . . . . 50
6.1 Piano iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Piano finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Human Digital Twin: IIoT Layer
iv ELENCO DELLE FIGURE Human Digital Twin: IIoT Layer
1
Abstract (italiano)
In un mondo in continua evoluzione, anche il settore dell’Industria si trova ad affrontare la
sua quarta rivoluzione: nasce il concetto di Industria 4.0, una tendenza all’automazione
industriale che integra alcune nuove tecnologie produttive per migliorare le condizioni di la-
voro, creare nuovi modelli di business e aumentare la produttività e la qualità produttiva degli
impianti.
Il lavoro proposto si colloca proprio in questo contesto, facendo parte di alcuni progetti di
ricerca europei che mirano non solo ad una produzione più efficiente ma, soprattutto, al-
l’aumento della collaborazione fra uomo e macchina, con una particolare enfasi sulla salute
fisica e mentale del lavoratore.
Il progetto consiste nella realizzazione di un sistema di acquisizione dati correlati all’opera-
tore di linea di un’azienda manifatturiera. Questo sistema prende il nome di IIoT Layer. Tali
dati dovranno essere condivisi sia ad un sistema di monitoring che a logiche di intelligenza
artificiale atte a identificare potenziali condizioni di stress e fatica dell’operatore.
Nella fase di analisi iniziale sono stati definiti i requisiti, per poi condurre delle ricerche in
merito ai dispositivi wearable esistenti e alle tecnologie che meglio potessero inserirsi nel
progetto. I dati del lavoratore provengono proprio da questi dispositivi indossabili e vengono
trasmessi tramite l’IIoT Layer agli altri componenti del sistema, fra i quali il database per i
dati dinamici e la dashboard di monitoring.
È stata studiata l’architettura generale del sistema definendo poi quella del progetto in que-
stione, rendendola molto flessibile nei confronti dei componenti utilizzati. Durante lo sviluppo
i vari componenti hanno preso forma, andando ad integrarsi per costituire la struttura finale
dell’IIoT Layer. Il sistema è stato testato e distribuito, da questo risultato si partirà per lo
sviluppo futuro del progetto.
Il lavoro realizzato consente ad un operatore di connettere alcuni wearable allo smartphone
e di trasmettere le sue metriche biologiche al sistema. Le informazioni correnti e storiche
sono consultabili attraverso la dashboard dedicata. Il resto del sistema permetterà di sta-
bilire la fatica percepita. Sarà poi possibile riconfigurare le attività e la postazione di lavoro
grazie all’aiuto di un robot. In questo modo viene migliorata la produzione e tutelata la salute
del lavoratore.
Human Digital Twin: IIoT Layer
2 Abstract (italiano) Human Digital Twin: IIoT Layer
3
Abstract (english)
In a constantly evolving world, the industry sector is also facing its fourth revolution: the
concept of Industry 4.0 is born, a trend towards industrial automation that integrates some
new production technologies to improve working conditions, create new business models
and increase the productivity and production quality of the plants.
The proposed work is placed in this context, being part of some European research projects
that aim not only at a more efficient production, but above all at increasing collaboration
between human and machine, with a particular emphasis on the physical and mental health
of the worker.
The project consists in the creation of a data acquisition system related to the line operator
of a manufacturing company. This system is called IIoT Layer. These data must be shared
both with a monitoring system and with an AI designed to identify potential stress and fati-
gue conditions for the operator.
In the initial analysis phase, the requirements were defined, and then research was carried
out on existing wearable devices and technologies that could best fit into the project. The
worker data comes from these wearable devices and is transmitted via the IIoT Layer to the
other components of the system, including the database for dynamic data and the monito-
ring dashboard.
The general architecture of the system was studied, then the one of the project in question
was defined, making it very flexible with regard to the components used. During develop-
ment, the various components were implemented, integrating them into the final structure
of the IIoT Layer. The system has been tested and deployed; from this result the future
development of the project will start.
This work allows an operator to connect some wearables to the smartphone and transmit
its biological metrics to the system. Current and historical information can be consulted th-
rough the dedicated dashboard. The rest of the system will allow to establish the perceived
fatigue and possibly reconfigure the activities and the workstation with the cooperation of a
robot. In this way production is improved and the health of the worker is preserved.
Human Digital Twin: IIoT Layer
4 Abstract (english) Human Digital Twin: IIoT Layer
5
Progetto assegnato
Il progetto di diploma, oggetto di questa tesi, si inserisce in due progetti di ricerca Europei
(KITT4SME e STAR), che mirano a realizzare delle piattaforme in grado di fornire un kit di
tool personalizzati per l’introduzione dell’Intelligenza Artificiale nelle Piccole e Medie Impre-
se del settore manifatturiero. Di seguito un breve riassunto dei progetti europei menzionati.
KITT4SME [1] (platform-enabled KITs of arTificial intelligence FOR an easy uptake by
SMEs). Le 23 milioni di piccole imprese europee costituiscono il 99% di tutte le imprese
e rappresentano circa i tre quarti di tutti i posti di lavoro. Le piccole imprese e le mid-cap
sono una parte fondamentale dell’economia. Il progetto KITT4SME, finanziato dall’UE (con
un budget complessivo di circa 9MC), sta sviluppando l’hardware, il software e kit su misura,
pronti per essere utilizzati dalle PMI europee. L’obiettivo del progetto è quello di realizza-
re una piattaforma in grado di fornire questi kit digitali in cui l’azienda può personalizzare i
moduli coinvolti con i quali sarà in grado di introdurre, e integrare facilmente, l’intelligenza
artificiale nei loro sistemi di produzione. Inoltre, la piattaforma considererà l’integrazione
con dei sensori IoT distribuiti nelle fabbriche, dispositivi indossabili, robot e con i sistemi
legacy presenti in azienda.
STAR [2] (Safe and Trusted Human Centric Artificial Intelligence in Future Manufacturing
Lines. I sistemi di intelligenza artificiale (AI) stanno migliorando sempre più l’automazione
della produzione nel settore manifatturiero. Ma affinché questi sistemi siano affidabili e ap-
plicabili quando sostituiscono le attività umane nel funzionamento dinamico, devono essere
sicuri e regolabili, in grado di reagire a diverse situazioni, a minacce alla sicurezza, ad eventi
imprevedibili in ambienti specifici. Il progetto STAR, finanziato dall’UE (con un budget com-
plessivo di circa 9MC) affronterà questa sfida progettando nuove tecnologie per consentire
l’implementazione di sistemi di IA basati su standard, sicuri, affidabili e incentrati sull’uomo
negli ambienti di produzione. Il progetto mirerà a ricercare ed integrare tecnologie di in-
telligenza artificiale all’avanguardia come sistemi di apprendimento attivo, sistemi di realtà
simulata, digital twin incentrati sull’operatore, tecniche avanzate di reinforcement learning
e meccanismi di difesa informatica, per consentire l’implementazione sicura di sofisticati si-
stemi di intelligenza artificiale nelle linee di produzione.
Human Digital Twin: IIoT Layer6 Progetto assegnato
Nel contesto di questi progetti si vuole realizzare un sistema di acquisizione dati, sia am-
bientali che biometrici, correlati all’operatore di linea di una azienda manifatturiera.
Tali dati dovranno essere condivisi sia ad un sistema di monitoring che a logiche di intelli-
genza artificiale, atte a identificare potenziali condizioni di stress e fatica o posture errate
dell’operatore.
I compiti da svolgere in collaborazione coi membri del team di progetto sono i seguenti:
• Identificare i requisiti funzionali e non funzionali del sistema di acquisizione.
• Selezionare un set di sensori indossabili e ambientali.
• Identificare le tecnologie che meglio rispondono alle esigenze del progetto.
• Progettare e sviluppare l’intero sistema di acquisizione dati considerando le esigenze
di integrazione con le logiche di intelligenza artificiale.
• Integrare il sistema di acquisizione con un Time Series DB.
• Realizzare una dashboard di monitoring.
• Testing del sistema di acquisizione: il sistema dovrà essere sottoposto a stress-test
per verificare la bontà del sistema di acquisizione e del canale di comunicazione
selezionato.
Il progetto richiede la conoscenza di Java for Android, protocolli di messaggistica publish/subscribe
(es. MQTT Broker o simili), Time series Database (es. InfluxDB), piattaforme per la realiz-
zazione di dashboard di monitoring (es. Grafana), Docker Container.
Non si esclude la necessità di acquisire la conoscenza di alcune tecnologie durante il
progetto di tesi.
Human Digital Twin: IIoT Layer7
Capitolo 1
Introduzione
In questo capitolo viene introdotto brevemente il tema sul quale è stato svolto il lavoro, facen-
do una panoramica sullo scopo del progetto, per poi discutere e motivare i fattori che hanno
portato alla scelta di questa tematica. Nel prossimo capitolo invece, verranno discusse le
analisi svolte nelle fasi iniziali, i requisiti e le specifiche del progetto.
1.1 Tema trattato
Come anticipato nella sezione in merito al progetto assegnato, che riporta il contenuto della
scheda progetto fornita in fase di scelta, il tema principale di questo lavoro è la realizzazio-
ne di un sistema di acquisizione dati che riguardano l’operatore di una linea di produzione.
Questi dati, che nella versione corrente del progetto sono limitati a quelli biometrici e dina-
mici, oltre che raccolti devono essere anche predisposti per la condivisione con logiche di
intelligenza artificiale, che rappresentano altre componenti del progetto nel suo complesso.
I dati devono inoltre essere riportati su un sistema di monitoring, che ne permetta una rapida
visione e interpretazione.
In questo lavoro verrà analizzato come è stato realizzato l’IIoT Layer, il componente re-
sponsabile della raccolta e della condivisione dei dati con gli altri moduli, ma questi ultimi
verranno ugualmente descritti in maniera sommaria nella sezione in merito alla progettazio-
ne generale del sistema, per fornire il contesto all’interno del quale il componente specifico
viene introdotto.
Nei prossimi capitoli verranno descritte le analisi svolte nelle fasi preliminari del progetto
sulla base degli obiettivi di quest’ultimo, per poi parlare della sua progettazione e implemen-
tazione, discutendo anche di testing e deployment per concludere infine con le opportune
valutazioni.
Human Digital Twin: IIoT Layer8 Introduzione 1.2 Motivazione e contesto Al termine del sesto semestre del Bachelor in Ingegneria Informatica presso la SUPSI viene richiesta la realizzazione di un lavoro di diploma, che prevede di studiare e sviluppare una delle proposte fornite da docenti e ricercatori in maniera autonoma, seppur con l’aiuto delle persone coinvolte nel progetto. All’interno della piattaforma contenente l’elenco e la descrizione dei progetti disponibili ce n’erano presenti diversi caratterizzati da tematiche molto eterogenee, ma tutti riconducibili al percorso di studi affrontato. Alcuni di questi vengono proposti da aziende esterne alla SUPSI, altri sono inerenti a progetti interni o a esigenze dei professori. In questo caso il progetto è stato fornito dall’ISTePS. L’Istituto di Sistemi e Tecnologie per la Produzione Sostenibile è focalizzato sull’innovazione dei sistemi produttivi, dei processi, dei prodotti e delle imprese attraverso lo sviluppo e lo sfruttamento di tecnologie industriali avanzate nonché di capitale umano altamente qualifi- cato. La mission dell’Istituto è l’innovazione di sistemi e processi produttivi, prodotti e modelli di business al fine di accompagnare le imprese nell’affrontare le sfide della globalizzazione sotto gli aspetti economici, ambientali e sociali. Il Laboratorio dei Sistemi di Produzione Sostenibile (SPS-Lab), nell’ambito di ISTePS, è de- dicato ad attività di ricerca e formazione finalizzate allo sviluppo e all’utilizzo di metodi e strumenti per la progettazione, l’analisi e la gestione di prodotti, processi e sistemi produt- tivi. Il framework integrato prodotto-processo-impianto considerato prevede la sostenibilità come elemento comune sottostante. In particolare, le attività svolte propongono un approc- cio olistico, che considera non solo elementi chiave come produttività, costo e qualità, ma anche principi ambientali e sociali, nella concezione, valutazione e gestione dei sistemi pro- duttivi e delle loro catene del valore. La metodologia adottata è supportata dallo sviluppo e dall’utilizzo di strumenti software dedicati per la progettazione e l’analisi di soluzioni di produzione e catene del valore collaborative attraverso sistemi di pianificazione avanzati e strumenti di simulazione e visualizzazione. Ciò che ha generato interesse nei confronti del progetto scelto è il fatto che presenta degli evidenti tratti in comune con il corso “Industry 4.0” frequentato durante il quarto semestre. Oltre ad aver apprezzato molto la qualità generale del corso, gli argomenti trattati e soprat- tutto il progetto svolto al suo interno sono stati parecchio stimolanti. Per questo l’idea di poter riprendere e approfondire quegli argomenti, unitamente alla possibilità di andare ad integrarli con lo studio e l’utilizzo di tecnologie fino a quel momento sconosciute come An- droid, i Message Broker e Docker, sono state alcune delle motivazioni principali che hanno Human Digital Twin: IIoT Layer
9
portato alla scelta di questo argomento.
Un’altra motivazione è stata la possibilità di poter lavorare e conoscere metodologie e perso-
ne all’interno dell’Istituto di ricerca, fattore molto importante a livello accademico, personale
e professionale. Infatti, un’ulteriore motivazione riguarda proprio l’opportunità di affronta-
re questo lavoro in preparazione all’attività di assistenza presso l’ISTePS, seguendo nel
frattempo il Master in Data Science nei prossimi anni.
Human Digital Twin: IIoT Layer10 Introduzione Human Digital Twin: IIoT Layer
11
Capitolo 2
Analisi iniziali
Come accennato nel capitolo precedente, di seguito verranno descritte la analisi svolte nelle
fasi preliminari del progetto, partendo da quella dei requisiti. Si passerà poi ad un’analisi
bibliografica dell’Industria 4.0, dei dispositivi wearable e dell’importanza della misurazione
di determinate metriche biologiche di un lavoratore, per capire come queste possano ri-
percuotersi sulla sua salute mentale e fisica. Nel prossimo capitolo si parlerà invece della
progettazione del sistema nel suo complesso e del componente specifico descritto in questo
lavoro, delle scelte tecnologiche e della pianificazione attuata.
2.1 Requisiti e specifiche
Di seguito vengono elencati i requisiti emersi nella fase di analisi con gli altri membri del
team per quanto concerne l’IIoT Layer:
• Il componente deve raccogliere dati da sensori distribuiti per il sistema produttivo,
inclusi wearable devices, supportando una frequenza target di 200Hz (minimo 100
Hz) a device.
• Il Gateway deve poter mostrare notifiche generiche o personalizzate per uno specifico
lavoratore fornite tramite il Broker.
• Il Gateway deve integrare almeno 5 metriche di aggregazione (con finestra variabile),
filtri e/o metodi di pre-processamento.
• Il Broker deve avere un topic per measurement per lavoratore (topic per la metrica HR
dell’operatore 1).
• L’IIoT Layer deve gestire l’autenticazione (login o RFID) tramite Gateway all’inizio del
turno.
• L’IIoT Layer deve inizializzare e gestire le sessioni, inclusa la selezione dei devices
che sta indossando e di quelli su cui vuol ricevere le notifiche.
Human Digital Twin: IIoT Layer12 Analisi iniziali
• Il Gateway, in caso di perdita di connessione, deve mantenere una coda impostabile
(valore di default).
• Il Gateway, in caso di perdita di connessione, deve poter garantire la gestione dei dati
in modo efficace, senza “intasare” il middleware (e.g. avere un canale diretto con il
time-series DB)
• Il Broker deve gestire n devices per m lavoratori.
• Un Gateway deve poter gestire n worker (valutando il limite di pairing con sensors/devices).
• I messaggi inviati al Broker devono essere il più possibile leggeri (in stile JSON) e
caratterizzati da una struttura eterogenea (possono riferirsi a misurazioni di metriche,
connessioni/disconnessioni di worker. . . ).
• La struttura e il funzionamento dell’IIoT Layer devono essere indipendenti dai com-
ponenti. I connettori utilizzati, sia per il Broker che per i dispositivi, devono essere
intercambiabili.
Come verrà descritto nei capitoli successivi, alcuni di questi requisiti sono stati semplificati
per facilitarne la realizzazione all’interno dello scope della tesi, sia per questioni di tempo
che per motivazioni legate all’interazione con altri componenti esterni all’IIoT Layer non
ancora realizzati (come l’Orchestrator). Questi ultimi verranno approfonditi nella sezione
dedicata alla progettazione generale del sistema.
2.2 Analisi bibliografica
In questa sezione vengono analizzati i concetti di Industria 4.0 e di Digital Twin, successiva-
mente viene fatta una panoramica sui dispositivi wearable per poi discutere dell’importanza
della misurazione di determinate metriche biologiche di un lavoratore. Lo scopo di que-
sta attività è quello di ottimizzare la collaborazione fra uomo e macchina per migliorare sia
l’efficienza della linea produttiva che la salute del lavoratore.
2.2.1 Industria 4.0 e Digital Twin
L’Industria 4.0 è un processo che scaturisce dalla quarta rivoluzione industriale e che sta
portando alla produzione industriale del tutto automatizzata e interconnessa. Le nuove tec-
nologie digitali avranno un impatto profondo nell’ambito di quattro direttrici di sviluppo: la
prima riguarda l’utilizzo dei dati, la potenza di calcolo e la connettività, e si declina in big
data, open data, Internet of Things, machine-to-machine e cloud computing per la centraliz-
zazione delle informazioni e la loro conservazione. La seconda è quella degli analytics: una
volta raccolti i dati, bisogna ricavarne valore. Oggi solo l’1% dei dati raccolti viene utilizza-
to dalle imprese, che potrebbero invece ottenere vantaggi a partire dal “machine learning”,
Human Digital Twin: IIoT Layer13
dalle macchine cioè che perfezionano la loro resa “imparando” dai dati via via raccolti e
analizzati. La terza direttrice di sviluppo è l’interazione tra uomo e macchina, che coinvolge
le interfacce “touch”, sempre più diffuse, e la realtà aumentata. Infine, c’è tutto il settore
che si occupa del passaggio dal digitale al “reale” e che comprende la manifattura additiva,
la stampa 3D, la robotica, le comunicazioni, le interazioni machine-to-machine e le nuove
tecnologie per immagazzinare e utilizzare l’energia in modo mirato, razionalizzando i costi e
ottimizzando le prestazioni. [3]
L’Industria 4.0 ha introdotto l’idea che il controllo e il processo decisionale del sistema pro-
duttivo possano essere realizzati, anche automaticamente, affidandosi ai Cyber Physical
Systems (CPS) come elementi duali composti da un elemento di produzione fisico e dalla
sua controparte digitale: il gemello digitale (Digital Twin). Esistono molti esempi in cui ven-
gono utilizzate copie digitali di macchine, dispositivi, prodotti o interi sistemi di produzione
per migliorare le prestazioni, fare previsioni e prendere decisioni. Tuttavia, gli esseri umani,
che hanno ancora un impatto rilevante sulla qualità del processo, sulle prestazioni e sul mi-
glioramento continuo, sono stati finora esclusi dalla rappresentazione digitale della fabbrica.
Il fattore umano è solitamente considerato solo all’interno della progettazione industriale e
del posto di lavoro per migliorare l’ergonomia, prevenire i rischi, formare ed educare, piutto-
sto che per il continuo processo decisionale e il controllo del sistema di produzione. Tuttavia,
per creare sistemi di produzione che integrino perfettamente le capacità umane, la fabbrica
digitale deve includere una rappresentazione digitale precisa e realistica degli esseri umani,
lo Human Digital Twin (HDT).
2.2.2 Dispositivi wearable
Piccoli, economici e molto diversi per forma, scopo e applicazione, i dispositivi IoT (Internet
of Things) hanno avuto un enorme impatto sullo sviluppo del settore delle telecomunica-
zioni, non solo portando sul mercato nuove tecnologie wireless a lungo raggio, definendo
nuovi requisiti in termini di affidabilità e disponibilità, ma anche spingendo gli operatori di
rete e i fornitori a riprogettare l’intero ecosistema, passando dal traffico generato dall’uomo
convenzionale a quello IoT più diversificato.
Lo sviluppo dell’IoT ha permesso agli sviluppatori di attirare la loro attenzione su un seg-
mento di mercato completamente nuovo: è nata una nicchia separata costituita da dispositivi
indossati da esseri umani. L’Internet of Wearable Things (IoWT) è emerso come parte di
un IoT più ampio, portando nuove sfide da varie prospettive tecnologiche alla comunità di
ricerca.
I termini dispositivi indossabili o anche tecnologia indossabile si riferiscono a piccoli dispo-
sitivi elettronici e mobili o computer con capacità di comunicazione wireless incorporati in
Human Digital Twin: IIoT Layer14 Analisi iniziali gadget, accessori o vestiti, che possono essere indossati sul corpo umano, o anche versioni invasive come micro-chip o tatuaggi intelligenti. Rispetto agli smartphone e ai tablet odierni, il principale valore aggiunto è che i dispositivi indossabili possono fornire varie funzionalità di monitoraggio e scansione, incluso il biofeedback o altre funzioni fisiologiche sensoriali come quelle relative alla biometria. I dispositivi wearable possono misurare continuamente tali valori, limitati dai vincoli della batteria; sono convenienti, portatili e possono offrire un facile accesso all’elettronica. La crescita del mercato dei dispositivi mobili porta a numerosi vantaggi e applicazioni dal punto di vista degli utenti. Uno degli stimoli principali portati dalla tecnologia indossabile è l’incoraggiamento di soluzioni proattive per affrontare l’assistenza sanitaria, il fitness, l’invec- chiamento, le disabilità, l’istruzione, i trasporti, le imprese, la finanza, i sistemi di ingresso, i giochi, la musica e molti altri. Poiché i wearable, come sono conosciuti oggi, sono stati stori- camente progettati come dispositivi puramente medici, consideriamo prima un esempio dal campo sanitario. Portare un dispositivo indossabile può potenzialmente prevedere la malat- tia attraverso il monitoraggio continuo della salute e persino informare automaticamente il medico al fine di adottare misure per prevenire attivamente la minaccia incombente. Anche i semplici tracker di attività sono già in grado di monitorare i modelli di sonno, la frequenza cardiaca, il livello di stress o la temperatura corporea che potrebbero essere utilizzati per migliorare le abitudini di salute di qualsiasi individuo. In generale, la classificazione dei dispositivi indossabili potrebbe essere delineata da varie prospettive in base a vari fattori. È interessante notare che i dispositivi wearable posso- no avere funzionalità simili ma fattori di forma, livelli tecnologici, diverse posizioni sul cor- po, ecc. completamente diversi. Pertanto, la classificazione più ampia si basa sul tipo di applicazione, anche se gli altri gruppi di classificazione possono sovrapporsi in modo si- gnificativo. Una delle classificazioni più ampie corrisponde, ma non è limitata, ai tipi di applicazioni/funzionalità. Un altro fattore significativo per la classificazione è legato al tipo di dispositivo (senza relazione con l’area di applicazione). L’ampia gamma di dispositivi indossabili e tecnologie correlate consente varie soluzioni di connettività supportate, definite dai requisiti dei wearable per portata, velocità dati, limita- zioni di alimentazione, tipi di forme, preferenze dello sviluppatore e numerosi altri aspetti. Anche le specifiche del trasferimento dei dati, inclusi il livello di crittografia, gli schemi di co- difica e trasmissione e la modulazione sono definite individualmente a seconda della tecno- logia utilizzata. Le tecnologie di trasmissione dati più comunemente utilizzate nei dispositivi indossabili includono Near Field Communication (NFC), Bluetooth Low Energy (BLE), Wire- less Fidelity (Wi-Fi), ZigBee, Low-Power Wide Area Network (LPWAN) e altre tecnologie di trasmissione IoT cellulari o non cellulari. Nelle reti wearable vengono impiegate tecnologie Human Digital Twin: IIoT Layer
15
di comunicazione sia a corto che a lungo raggio.
L’integrazione di più sottosistemi è alla base dei moderni sistemi IoT e IoWT. Tuttavia, gene-
ra nuovi problemi di interoperabilità e richiede ulteriore attenzione da parte dell’industria e
delle comunità di ricerca per creare una programmabilità senza interruzioni per connettere,
collaborare e scambiare efficacemente i dati tra i dispositivi. L’interoperabilità viene studiata
da varie prospettive, tra cui dispositivo, tecnologia, rete, sintattica, semantica e piattaforma.
Per riassumere, la tecnologia wearable è un elemento essenziale nei futuri sistemi ICT. È
ancora agli inizi e devono ancora essere affrontate diverse sfide critiche legate all’acquisi-
zione e all’elaborazione dei dati, alle comunicazioni, alla sicurezza, agli aspetti della privacy,
alle limitazioni dell’hardware e all’adozione da parte degli utenti. [4]
2.2.3 Relazione fra metriche e salute dell’operatore
Al fine di accertare lo stato di salute di un individuo e la sua reazione a fattori esterni, è
necessario monitorare i vari parametri fisiologici ritenuti rilevanti. Nel corso degli anni sono
stati esaminati i seguenti cinque parametri vitali: temperatura, frequenza cardiaca, pressio-
ne sanguigna, frequenza respiratoria e saturazione di ossigeno nel sangue. Questi possono
essere ottenuti tramite sensori indossabili non invasivi e non intrusivi, dei quali si è discusso
nella sezione precedente. Questi possono essere inclusi in sistemi di monitoraggio del-
la salute a lungo termine. Possono monitorare e registrare in tempo reale le informazioni
riguardanti la condizione fisiologica e le attività motorie di un individuo, senza causare disa-
gio né interrompere la pratica delle attività quotidiane. Questi sensori biomedici misurano i
segni fisiologici che possono essere utilizzati per ottenere elettrocardiogrammi (ECG), elet-
tromiogrammi (EMG), fotopletismogrammi (PPG), sismocardiogrammi (SCG), ballistocar-
diogrammi (BCG), pressione sanguigna, temperatura corporea, frequenza cardiaca (HR),
saturazione di ossigeno (SpO2), frequenza respiratoria (RR) e molti altri parametri. Questi
sensori sono generalmente collegati in una rete wireless del corpo (WBAN) o in una rete
di sensori del corpo (BSN) e possono essere posizionati direttamente sulla pelle, sopra i
vestiti o persino impiantati nel tessuto della persona. [5]
La definizione di salute mentale si riferisce al benessere di un individuo a livello emotivo,
sociale e psicologico. Lo stato di salute mentale degli individui ha un’influenza significati-
va sul modo in cui agiscono, elaborano le emozioni e prendono decisioni. Una persona in
buona salute mentale può mantenere relazioni sane, esprimere un’ampia gamma di emo-
zioni e gestire le difficoltà del cambiamento. L’Organizzazione Mondiale della Sanità (OMS)
definisce la salute mentale come lo stato di benessere in cui ogni individuo realizza il pro-
prio potenziale, gestisce i normali stress della vita, lavora in modo produttivo e fruttuoso e
può contribuire alla propria comunità. La differenza tra salute fisica e mentale non è così
Human Digital Twin: IIoT Layer16 Analisi iniziali pronunciata come si potrebbe pensare. Per anni, i ricercatori si sono chiesti come la salute mentale e fisica interagissero. La risposta è prevedibilmente complicata, ma è noto che il malessere mentale ha un impatto diretto e indiretto sulla salute fisica. La salute mentale è strettamente legata alla fatica e quella stanchezza persistente può facilmente portare a un peggioramento della salute fisica. Quando qualcuno è cronicamente depresso o ansioso, è meno probabile che si impegni nell’esercizio e che smetta presto quando lo fa. [6] Human Digital Twin: IIoT Layer
17
Capitolo 3
Progettazione
Nello scorso capitolo sono stati discusse le analisi svolte nelle fasi iniziali del progetto. Oltre
ai requisiti sono stati proposti anche degli approfondimenti in merito ad alcune tematiche
estremamente importanti e correlate all’interno di questo lavoro: l’Industria 4.0 e il concetto
di Digital Twin, i dispositivi wearable e la relazione che le metriche biologiche hanno con la
salute dell’operatore.
Di seguito viene discusso tutto ciò che concerne la progettazione effettuata. Inizialmen-
te viene proposta la progettazione generale del sistema, comprensiva di tutti i componenti
che lo compongono oltre all’IIoT Layer, soggetto protagonista di questo scritto. Successi-
vamente viene presentata e analizzata la struttura di quest’ultimo, per poi discutere delle
scelte tecnologiche compiute. Per concludere il capitolo viene descritta la progettazione
iniziale del lavoro, che verrà confrontata con quelle effettiva all’interno dell’ultimo capitolo,
nella sezione del commento al piano di lavoro. Nel prossimo capitolo verrà invece descritta
l’implementazione effettiva del componente realizzato.
3.1 Progettazione generale del sistema
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.
Human Digital Twin: IIoT Layer18 Progettazione
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
Human Digital Twin: IIoT Layer19
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 lavoratori, 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]
Human Digital Twin: IIoT Layer20 Progettazione
– 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 caratteristiche
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
Human Digital Twin: IIoT Layer21
(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 questi dati sono: smartwatch, microfoni a stetoscopio su caschi intelligenti 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 apprendimento 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 piattaforme. Durante il progetto verrà discusso
se l’integrazione avverrà tramite routing, contenuto incorporato o componenti web.
Human Digital Twin: IIoT Layer22 Progettazione
3.2 Progettazione specifica del componente
Nella scorsa sezione è stato presentato il contesto all’interno del quale l’IIoT Layer è collo-
cato e ne è stata fatta una prima descrizione. Di seguito vengono presentate la sua struttura
e la logica di funzionamento.
Figura 3.2: Architettura IIoT Layer
Come visibile in Figura 3.2, possono esserci più Gateway all’interno dell’IIoT Layer. Oltre
a quest’ulitmo sono rappresentati anche il Broker, il collegamento all’Orchestrator, i vari
dispositivi wearable, l’Historical Data Manager, il livello di persistenza e Grafana. Questi
elementi sono riportati in quanto interagiscono direttamente con l’IIoT Layer, seppur non
rientrino direttamente nell’architettura di quest’ultimo.
I componenti principale dell’IIoT Layer sono:
• Device Connector : possiedono una struttura in comune ma implementano la connes-
sione ad un dispositivo wearable o sensore ambientale specifico. Sono intercambiabili
e possono essere istanziati più volte, a dipendenza dei dispositivi ai quale ci si desi-
dera collegare. Integrano anche delle logiche di data manipulation sui valori ricevuti
dai dispositivi, per eliminare i dati nulli e opzionalmente effettuare delle aggregazioni
sui dati ricevuti. Questi connettori vengono istanziati e interpellati dal Device Mana-
ger che li utilizza. Offrono il controllo sul dispositivo al quale si riferiscono senza che
l’utilizzatore ne conosca il funzionamento.
• Device Manager : è responsabile di gestire l’interazione con l’utente (il worker) tra-
mite l’interfaccia dell’applicazione sul Gateway. Come anticipato, si occupa anche di
istanziare ed utilizzare i Device Connector per gestire i vari wearable e ottenere le
metriche. Oltre che con questi ultimi, comunica anche con gli altri moduli interni ed
Human Digital Twin: IIoT Layer23
esterni all’IIoT Layer tramite il Gateway Manager, al quale invia e dal quale riceve
informazioni.
• Gateway Manager : si occupa dell’invio e della ricezione dei messaggi fra i vari com-
ponenti all’interno del Gateway. Ottiene la configurazione del sistema tramite l’Orche-
strator (al momento sostituito da un file JSON come verrà descritto più avanti). Questa
configurazione si riferisce, ad esempio, ai worker e wearable presenti, ai topic sui quali
mandare le varie informazioni o alle strutture dati coinvolte. Una sua funzione tipica è
la ricezione di metriche dal Device Manager e l’inoltro al Broker Manager. Per quanto
riguarda i suoi componenti interni, l’OrchestratorConnector realizza la connessione
con l’Orchestrator, mentre il PersistencyManager si occupa di garantire la persistenza
dei dati ricevuti all’interno di una finestra temporale, per mantenere le informazioni
anche in assenza di connessione.
• Broker Manager : la sua funzione è quella di generalizzare la connessione con il Bro-
ker, a prescindere da quello utilizzato. In questo modo chi si interfaccia con questo
componente non deve curarsi dell’implementazione specifica del Broker ma può invia-
re e ricevere informazioni tramite funzioni generiche. Per fare ciò il Broker Manager
definisce una struttura comune alla quale tutti i connettori a Broker specifici devono
sottostare. Anche in questo caso i connettori sono intercambiabili, ma sono uno alla
volta può essere attivo.
Per quanto riguarda gli altri elementi presenti nell’immagine, invece:
• Environmental and wearable sensors: sono i sensori ambientali o dispositivi wearable
presenti nella cella dell’impianto o indossati dagli operatori. Tramite sensori integrati
sono in grado di fornire valori per metriche specifiche.
• Fake Orchestrator : soluzione che sostituisce provvisoriamente l’Orchestrator descrit-
to nella sezione precedente. È costituito da vari file JSON che rappresentano, ad
esempio, i dispositivi wearable presenti, i worker o i topic da utilizzare. Questi file
vengono interpretati dall’Orchestrator Connector.
• Broker : sinonimo del Middleware descritto nella precedente sezione. All’interno di es-
so scorre il flusso di messaggi fra i vari componenti dell’architettura complessiva. Al
momento si è deciso di utilizzare un Broker MQTT, ma grazie alle flessibilità dell’archi-
tettura questo può essere sostituito in futuro. Il suo utilizzo da parte dei componenti è
gestito da un connettore specifico.
• Historical Data Manager : si occupa di restare in ascolto su determinati topic del Bro-
ker per ottenere le informazioni da persistere all’interno dei DB. Al suo interno è pre-
sente una struttura costituita da Broker Manager e connettori simile a quella prece-
dentemente descritta. Una sua funzione tipica è quella di ricevere le informazioni
Human Digital Twin: IIoT Layer24 Progettazione
sulle metriche rilevate per i vari worker e di persisterle all’interno del DB dedicato ai
dati dinamici. È analogo all’History keeper module descritto nella sezione precedente.
• InfluxDB e MongoDB: si occupano rispettivamente della persistenza di dati dinamici e
statici/semi-statici. Sono stati descritti nella sezione precedente.
• Grafana: è la dashboard all’interno della quale i dati raccolti dall’IIoT Layer sono mo-
strati per permetterne una rapida consultazione e interpretazione. Queste informazio-
ni si riferiscono alle metriche correnti e al loro storico dei vari worker.
3.3 Scelte tecnologiche
Il linguaggio di programmazione utilizzato all’interno del progetto è Java. Più nello specifico,
sono state realizzate un’applicazione mobile per Android installata sul Gateway e un’appli-
cazione desktop per l’Historical Data Manager. La scelta di Java è stata fatta in base alle
conoscenze del linguaggio e la possibilità di riutilizzare il codice sul Raspberry in futuro.
Come anticipato sono stati utilizzati un MQTT Broker come protocollo di messaggistica pu-
blish/subscribe (nella fattispecie Mosquitto). Il perché di questa scelta sarà enunciato a
breve nel Benchmark sui Broker. Come DB per le serie temporali è stato scelto InfluxDB in
quanto già conosciuto e particolarmente adatto alle esigenze. Come detto la dashboard di
monitoring è stata realizzata con Grafana, questa verrà descritta più nel dettaglio nel pros-
simo capitolo. Infine, come viene discusso nel capitolo il merito a testing e deployment, ci si
è avvalsi di Docker Container.
Nelle prossime sottosezioni vengono descritte due della attività svolte al fine di scegliere le
tecnologie e dispositivi più adatti alle necessità del progetto.
3.3.1 Analisi e Benchmark dei Broker
In questa sottosezione viene presentata l’analisi svolta per la scelta di un Message Broker.
Nello specifico si ha la necessita di gestire una gran varietà di sensori diversi tra loro, che
inviano grandi quantità di dati con una frequenza di 100-200 Hz al Middleware. Si vuole riu-
scire a gestire il maggior numero di dispositivi collegati al Broker possibile garantendo buone
prestazioni. Inoltre, non si vuole trascurare la compatibilità del Broker scelto con vari tipi di
linguaggi di programmazione. Il Broker dovrebbe avere una memorizzazione persistente
dei dati ed essere in grado di sopportare un alto volume di traffico e set di dati massicci.
Dovrebbe avere la capacità di dividere il traffico in parti separate e logiche, per esempio,
i topic. Infine, il Broker dovrebbe avere un’affidabilità molto alta e una deliverability degli
eventi.
Human Digital Twin: IIoT Layer25
Per una consultazione approfondita delle analisi svolte in merito ai vari Broker si rimanda ad
documento integrale "Analisi_broker", presente negli allegati. Di seguito viene riportata una
panoramica del Broker scelto: Eclipse Mosquitto.
Mosquitto è una soluzione molto popolare tra gli sviluppatori. È un protocollo leggero creato
per progetti IoT. Si basa sul modello di publish/subscribe. Il Broker di messaggi è indipen-
dente da altre applicazioni o librerie. È concesso in licenza con EPL/END, il che significa
che è open source, inoltre fa parte della Fondazione Eclipse, è un fattore importante per
molti progetti. Mosquitto ha più librerie in molte lingue, quindi è abbastanza versatile, il che
significa che può essere facilmente adattato dagli sviluppatori a un progetto. Eclipse Mo-
squitto fornisce un’implementazione server leggera del protocollo MQTT che è adatta a tutte
le situazioni, dalle macchine a piena potenza alle macchine embedded e a bassa potenza.
I sensori e gli attuatori, che sono spesso le sorgenti e le destinazioni dei messaggi MQTT,
possono essere molto piccoli e privi di potenza. Questo vale anche per le macchine em-
bedded a cui sono collegati, che è dove Mosquitto potrebbe essere eseguito. Tipicamente,
l’attuale implementazione di Mosquitto ha un eseguibile dell’ordine di 120kB che consuma
circa 3MB di RAM con 1000 client connessi. Sono stati segnalati test di successo con
100.000 client connessi a velocità di messaggi modeste. Oltre ad accettare connessioni da
applicazioni client MQTT, Mosquitto dispone di un bridge che gli consente di connettersi ad
altri server MQTT, incluse altre istanze di Mosquitto. Ciò consente di costruire reti di server
MQTT, passando messaggi MQTT da qualsiasi posizione della rete a qualsiasi altra, a se-
conda della configurazione dei bridge. Attualmente Mosquitto non è multi thread. [10]
Il Benchmark prende in considerazione la maggior parte dei broker presentati e selezionati
nella fase di analisi, in particolare quelli MQTT. Sono stati esclusi quelli per i quali non è sta-
to possibile realizzare un’implementazione adeguata. Lo scopo di questo lavoro è quello di
identificare quale Broker si adatti in modo migliore alle esigenze che caratterizzano il proget-
to, considerando soprattutto l’efficienza e le performance, nonché la facilità implementativa
e di utilizzo.
I Broker selezionati per l’analisi nella prima fase sono:
• Apache Kafka
• Eclipse Mosquitto
• Redis
• RabbitMQ
• Orion Context Broker
• ZeroMQ
Human Digital Twin: IIoT LayerPuoi anche leggere
