Studenti
Dell’Oca Samuele
Relatore
Landolfi Giuseppe
Correlatore
Bonomi Niko
Committente
ISTePS - SPS Lab
Corso di laurea
Ingegneria Informatica
Codice progetto
C10367
Anno
2020/2021
Data
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
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
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
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.
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.
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 9M C), 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 9M C) 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.
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.
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.
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
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.
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.
• 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”,
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
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
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ì
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]
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.
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 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]
– 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
(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.
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
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
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.
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
• HiveMQ
• EMQ
Degli 8 Broker selezionati in fase di analisi sopra riportati, il benchmark considera solo 6 di questi. Come precedentemente menzionato per quelli restanti non è stato possibile trovare un client Java adeguato e di conseguenza realizzarne un’implementazione. Oltre ad Apa- che Kafka (che per comunicare con MQTT deve appoggiarsi ad un broker a parte, come Mosquitto) e Orion Context Broker (per il quale l’unica possibilità di integrazione con Java è l’utilizzo di un framework client REST), sono stati presi in considerazione anche Mosca e JoramMQ, dei broker particolarmente validati dalla letteratura ma per i quali non è disponibi- le un client Java. I broker restanti, Mosquitto, Redis, RabbitMQ, ZeroMQ, HiveMQ ed EMQ, sono quelli che sono stati effettivamente implementati e comparati, come viene descritto nella sezione successiva.
Di questi solo alcuni sono dei Broker MQTT: Mosquitto, RabbitMQ, ZeroMQ, HiveMQ, EMQ;
mentre Redis è un database distribuito NoSQL in memoria con archiviazione chiave-valore, funziona bene con i server MQTT perché può fungere da Broker di messaggi. Il carico del server MQTT può essere spostato in gran parte su un cluster Redis in modo da ottenere una maggiore concorrenza.
L’idea alla base del programma è quella di realizzare l’implementazione di ogni singolo Bro- ker e di un modulo principale dal quale è possibile impostare quale broker utilizzare, ap- poggiandosi agli appositi connettori. L’implementazione dello specifico Broker è realizzata in un package dedicato, che comprende un gestore dei publisher e dei subscriber. Inoltre, per Mosquitto e per EMQ è stata realizzata una callback esterna, che viene implementata dal subscriber. Oltre che dal package principale i vari publisher e subscriber possono es- sere eseguiti anche indipendentemente, direttamente nella classe stessa. Nel file pom.xml sono state inserite le dipendenze per ogni client che sono state importate tramite Maven e utilizzate nei vari package. Per ogni Broker è stato utilizzato un server già esistente, senza realizzarne uno ad hoc. Dove possibile si è optato per un’implementazione asicrona, uti- lizzando a dipendenza del Broker la versione 3 o 5 di MQTT. Per i Broker MQTT (tranne che per ZeroMQ) è stata impostata anche la Quality of Service, come verrà illustrato nella prossima sezione. Per quanto concerne autenticazione e sicurezza, la maggior parte dei Broker permettono di impostare diverse opzioni, ma all’interno di questo lavoro si è deciso di omettere questi fattori.
All’interno del package principale sono presenti anche le interfacce che definiscono i metodi che publisher e subscriber devono implementare, unitamente ad una classe astratta che definisce la struttura dei vari gestori. Nello specifico i manager si occupano di istanziare e
gestire delle liste di publisher e subscriber, chiamando i metodi delle rispettive classi. Questi gestori sono istanziati all’interno del package principale rispettivamente per publisher e sub- scriber, sulla base del Broker che si intende usare. È qui che è possibile specificare anche quanti elementi istanziare, assieme ai topic e messaggi da inviare. Inoltre, per garantire il corretto funzionamento del programma, bisogna installare e avviare sulla macchina i client di Mosquitto, RabbitMQ e Redis; oltre che importare le dipendenze specificate nel pom. Per ZeroMQ è stato utilizzato il paradigma publish-subscribe.
Una volta implementato il programma sono stati svolti dei test di esecuzione, considerando la durata di quest’ultima e il numero di messaggi correttamente consegnati. I valori mostrati nelle tabelle seguenti sono una media di varie esecuzioni. Tranne che in Redis e ZeroMQ, sono stati cambiati nelle varie esecuzioni i parametri di Quality of Service, oltre che dei messaggi e del numero di publisher e subscriber coinvolti, per vedere come questi fattori influenzano l’esecuzione. Nei casi in cui non è stato possibile impostare la QoS i risultati sono stati riportati nella colonna QoS=0, mentre le celle inutilizzate sono indicate con uno sfondo grigio. Per semplicità è stato misurato il tempo di esecuzione del publisher principale con l’implementazione dei vari Broker, questo perché il subscriber principale rimane sempre in attesa. Non sarebbe stato semplice verificare il termine della ricezione, mentre il publi- sher, quando ha finito di pubblicare i messaggi, termina la sua esecuzione. Inoltre, i tempi non prendono in considerazione l’inizializzazione dei vari client, ma solo i tempi di invio. Gli stessi test sono stati svolti su gruppi di rispettivamente 10 publisher/subscriber, un nume- ro ristretto di test è stato effettuato anche con gruppi di 100 publisher/subscriber; i risultati sono riportati nelle tabelle seguenti. Per semplicità tutti i test sono stati svolti pubblicando e leggendo da un unico topic, ma dalle prove effettuate è emerso che anche coinvolgendo molteplici topic i risultati sono molto simili.
Tutti i test sono stati svolti sulla stessa macchina: un Asus Vivobook Pro con processore Intel Core i7-7700HQ 2.80GHz, 16 GB di RAM e sistema operativo Windows 10 Home. La versione di Java è la 11.0.2 LTS.
Un’importante premessa è che la colonna “Inviati” indica il numero totale di messaggi inviati (numero di messaggi per client*numero publisher), mentre le colonne “Ricevuti” indicano il numero totale di messaggi ricevuti, che sarà ulteriormente moltiplicato per il numero di subscriber, essendo tutti registrati allo stesso topic. Esempio: 10 messaggi per publisher, 10 publisher, 10 subscriber. In un caso ottimale, Inviati=100, Ricevuti=1000. I tempi di esecuzione estremamente lunghi (oltre i 10 minuti) sono in arancione.
Figura 3.3: Test con 10 publisher/subscriber
Figura 3.4: Test con 100 publisher/subscriber
* L’implementazione del Broker è bloccante, pertanto i messaggi ricevuti si riferiscono ad un unico subscriber. Si può stimare il numero totale moltiplicando per i subscriber.
Ciò che emerge dai risultati del benchmark, visibili nelle Figure 3.3 e 3.4, è che i migliori Broker MQTT sono, in ordine, Mosquitto e RabbitMQ. Redis invece è la soluzione migliore in assoluto, pur non essendo MQTT.
• EMQ: pur essendo semplice a livello implementativo, le performance non sono delle migliori, e fatica molto specie con tanti publisher/subscriber.
• HiveMQ: uno dei Broker più complessi a livello implementativo, questo perché è possi- bile sviluppare diversi tipi di client (sincroni, asincroni, bloccanti, paralleli). Nonostante sia molto completo, le performance non sono ottimali, seppur migliori di quelle di EMQ.
• Mosquitto: si è dimostrato essere il migliore come performance fra i Broker MQTT ed è caratterizzato da un’implementazione abbastanza semplice.
• RabbitMQ: è la seconda scelta fra i Broker MQTT, ed ha un’implementazione un po’
più complessa di quella di Mosquitto.
• Redis: pur non essendo prettamente un message Broker ma bensì un database di- stribuito NoSQL in memoria con archiviazione chiave-valore, sì è dimostrato essere il migliore come performance, ed è una valida alternativa ad un Broker MQTT. L’unico problema potrebbe essere che, trattandosi di un database in memoria, potrebbe non inserirsi correttamente all’interno dell’architettura del progetto.
• ZeroMQ: potrebbe avere molto potenziale, ma adottando il paradigma publish sub- scribe non risulta particolarmente ottimale nell’utilizzo, sia come implementazione che come performance in ricezione, mentre quelle di invio sono estremamente buone. Un altro punto a suo sfavore è che solo un publisher può essere bindato ad uno specifico indirizzo, e non esiste il concetto di topic, che rimane implicito all’interno del messag- gio (la categoria di appartenenza di un messaggio viene stabilita dalla prima parola di quest’ultimo).
Non c’è da escludere che le performance dei vari Broker siano state influenzate dall’imple- mentazione specifica adottata in questo Benchmark e che questi ultimi potrebbero perfor- mare in maniera migliore, nonostante siano state seguite diverse guide e documentazioni per ogni soluzione, cercando di realizzare quella più valida e consolidata. La grossa utilità del benchmark realizzato è che, oltre ad aver permesso di selezionare i Broker migliori, ha permesso di comprenderne anche l’implementazione, facilitando il compito di integrazione del Broker all’interno dell’architettura più avanti nel progetto.
Per ulteriori informazioni in merito al Benchmark si rimanda al documento "Benchmark_broker"
presente negli allegati.
3.3.2 Classificazione e scelta dei wearable device
Lo scopo di questa analisi è quello di realizzare un SoA (State of the Art) dei dispositivi wearable presenti sul mercato, considerando sia quelli commerciali che quelli medici. Grazie a questa raccolta sarà possibile scegliere quali dei dispositivi analizzati si adattano meglio al caso d’uso del progetto.
Come criteri per l’individuazione dei dispositivi sono stati utilizzati l’appartenenza ad almeno di una di queste categorie:
• Migliori dispositivi wearable
• Migliori dispositivi wearable medici
• Migliori dispositivi wearable per misurazioni/metriche del corpo
• Migliori dispositivi wearable per dati fisiologici
Le fonti utilizzate sono vari articoli scientifici e di letteratura, classifiche, comparatori e blog, nonché i siti dei produttori stessi. Di conseguenza sono stati presi in considerazione sia i dispositivi per il tracking dell’attività fisica che vengono comunemente acquistati dal pubblico che dispositivi progettati specificatamente per la rilevazione di determinate metriche, medici e non.
La raccolta dei dispositivi è presente nell’allegato "Wearable_devices_classification".
Al fine di classificare i dispositivi presi in considerazione sono state prese in considerazione varie caratteristiche di questi ultimi, che sono state suddivise in macro-gruppi per semplicità:
• Generali: tipo di dispositivo, posizione sul corpo, presenza di uno schermo, presenza di una memoria interna, dimensioni dell’eventuale memoria interna, durata della batte- ria, durata della batteria con eventuale GPS, tempi di ricarica, capacità della batteria, classificazione di impermeabilità (IP o ATM), peso e prezzo
• Protocolli di comunicazione: ANT+, Bluetooth Low Energy (BLE), WiFi
• SDK : trasmissione real-time direttamente dal dispositivo, App, API generica, tramite web/piattaforma
• Metriche di tracciamento: elettromiografia (EMG), elettrocardiogramma (ECG/EKG), bioimpedenza, battito cardiaco (HR), variabilità del battito cardiaco (HRV), intervallo RR/intervallo intra battito (IBI), intervallo da picco a picco (PPI), temperatura cutanea (ST), risposta cutanea galvanica (GSR)/ attività elettro dermica (EDA), pressione san- guinea, saturazione dell’ossigeno, volume di ossigeno consumato per minuto (V02 max), pletismogramma pulsato (PPG)/impulso del volume sanguigno (BVP)
• Sensori presenti: misuratore del battito cardiaco, sensore SpO2, pedometro, accele- rometro, giroscopio, magnetometro, barometro, GPS, altimetro, termometro, microfo- no, bussola, sensore di luce ambientale, sensore ottico, NFC
Ognuna di queste singole caratteristiche contribuisce a determinare il livello di adeguatezza del dispositivo preso in analisi. Non tutte le caratteristiche sono specificate per tutti i disposi- tivi, specie per quanto riguarda quelle generali, alcuni produttori non rilasciano determinate specifiche oppure non è stato possibile trovarle.
È importante specificare che sono stati presi in analisi solo quei dispositivi non particolar- mente invasivi che non andassero ad influire sull’attività dell’operatore, considerando ad esempio smartwatch, smartband, tracker e simili. Sono quindi stati esclusi dispositivi come smartglasses, elmi, headsets e bilance, che o non erano indossabili oppure erano troppo invasivi.
Nella fase iniziale è stato studiato e rivisto quanto presente nella prima classificazione for- nita dai membri del team ad inizio attività: considerava circa 110 dispositivi, ma per quanto approfondita era limitata ad una nicchia di produttori e non considerava determinate solu- zioni, specie quelle mediche. Inoltre, molti dei dispositivi considerati erano obsoleti e/o non più in produzione, alcuni poco adatti al caso d’uso.
La base delle caratteristiche da analizzare era già presente in questa classificazione, le ma- crocategorie sono state leggermente modificate e integrate per considerare ulteriori aspetti.
Svolte queste operazioni, è stata realizzata una lista della maggior parte dei dispositivi pre- senti sul mercato adatti al contesto. L’errore iniziale è stato quello di considerare anche i modelli più obsoleti e i dispositivi che tracciano informazioni scarse o poco utili al contesto.
Questa attività, oltre che dispendiosa in termini di tempo, si è rivelata poco utile in quanto i dispositivi da analizzare erano troppi (circa 550 escludendo quelli medici) e molti di essi non erano neanche più in commercio.
L’approccio è stato rivisto, e grazie alle informazioni acquisite nella fase precedente è stata realizzata un’abbondante scrematura della lista dei dispositivi, arrivando a considerarne cir- ca 90. Tendenzialmente sono stati considerati i dispositivi più recenti e gli ultimi modelli, a meno che non si trattasse di un dispositivo particolarmente validato dalla letteratura seppur con qualche anno alle spalle. Questo è stato fatto per due motivi: il primo è che sarebbe stato estremamente dispendioso in termini di tempo considerare tutti i dispositivi esistenti (quindi anche i modelli più obsoleti e non più in commercio), secondariamente nella mag- gioranza dei casi nei nuovi modelli si contemplano le caratteristiche di quelli precedenti e se ne aggiungono di nuove; quindi, sarebbe stato relativamente inutile considerare anche i dispositivi più vecchi.
Ogni dispositivo presente in questa lista è stato analizzato singolarmente, incrociando le in- formazioni presenti sui siti dei produttori, schede tecniche, manuali e articoli online. Grazie a questo lavoro le informazioni raccolte sono da considerarsi come affidabili e abbastanza esaustive, probabilmente sono presenti delle caratteristiche ulteriori (escludendo quelle non rilevanti per il contesto che sono state escluse), ma non sono state inserite nella raccolta perché non individuate nelle fonti utilizzate.
Sono state riportate nella raccolta anche eventuali osservazioni particolarmente significative per i dispositivi e il link alla fonte maggiormente utilizzata per la classificazione. Successi- vamente sono state stabilite delle metriche di valutazione per i dispositivi considerati.
Al fine di valutare i dispositivi presenti nella raccolta effettuata, inizialmente sono stati as- segnati dei punteggi alle singole caratteristiche di ogni macrocategoria, escludendo deter- minate informazioni generali perché poco indicative o mancanti in diversi dispositivi. Si
è poi deciso di optare per una metodologia più scientifica, adottando un AHP: una tecni- ca di supporto alle decisioni multicriterio. Negli allegati è presente il documento integrale
"AHP_wearables".
L’intenzione era quella di stabilire un’importanza per le caratteristiche primarie di un dispo- sitivo (presenza di uno schermo, memoria interna, peso, tecnologia ANT+, BLE, WiFi, data stream dal dispositivo, piattaforma), con lo scopo di definire un peso per ognuna di queste.
Per fare ciò i 4 partecipanti all’AHP hanno attribuito un’importanza soggettiva, quantificata secondo i criteri in Figura 3.5, ad ogni caratteristica rispetto ad un’altra. Un esempio di compilazione dell’AHP è visibile in Figura 3.6.
Figura 3.5: Significato dei punteggi attribuiti
Figura 3.6: Struttura AHP
Andando a fare la media dei punteggi assegnati da ogni partecipante si è ottenuto il peso finale. I risultati ottenuti sono visibili in forma grafica in Figura 3.7 e in formato percentuale in Figura 3.8.
Figura 3.7: Risultato AHP grafico
Figura 3.8: Risultato AHP percentuale
I pesi generati per le caratteristiche precedentemente citate sono stati utilizzati all’interno di una formula (Figura 3.9) per attribuire un punteggio complessivo al singolo device. Andando a verificare la presenza o meno della caratteristica (o del valore normalizzato nel range 0-1 per i valori numerici) e moltiplicando per il peso assegnato si è ottenuto uno score nel range 0-1, dove 1 rappresenta i dispositivi migliori.
Figura 3.9: Calcolo del punteggio per il dispositivo
Andando ad ordinare i vari dispositivi in modo decrescente per il valore dello score, si è otte- nuta una classifica dei dispositivi migliori sulla base delle caratteristiche primarie. A questo punto però vi era ancora la necessità di considerare anche le caratteristiche secondarie nella scelta (autonomia della batteria, metriche tracciate, posizionamento del device. . . ).
Sulla base della classifica ottenuta nella fase antecedente, le caratteristiche secondarie so- no state utilizzate come filtro, andando a scartare i dispositivi che non le rispettavano. Più
