Lezione 9: 1 aprile 2022

venerdì 1 aprile 2022 15:14

Seminario
SENSE-RISC – Sviluppo di abiti intelligENTi Sensorizzati per prEvenzione e mitigazione di Rischi
per la SiCurezza dei lavoratori

Il centro Piaggio si è occupato della realizzazione pratica del sistema che si compone di una
maglietta sensorizzata con una serie di elettroniche esterne che si interfacciano, in modalità
wireless, con una piattaforma centrale che raccoglie i dati e li invia ad un cloud. L’obiettivo è
analizzare i dati per fare una valutazione del rischio.

Nel progetto sono stati coinvolte diverse figure:

• Centro Piaggio: sviluppo hardware, programmazione firmware;
• Università di Pisa, Dipartimento di Chimica per lo sviluppo di sensori per il sudore e
dosimetri ottici;
• Sant’Anna che ha sviluppato un sistema per la misura della frequenza respiratoria tramite
fibre ottiche;
• Campus Bio­Medico di Roma che si è occupato dell’analisi dei dati e di sviluppare un
modello per fare la predizione del rischio;
• Istituto Don Gnocchi: ha fornito l’elettronica usata per acquisire l’ecg; si è occupato delle
metodologie di valutazione del sistema;
• Sapienza di Roma: si è occupata della parte sensoristica.

Architettura del sistema

• I segnali vengono acquisiti sia dall’ambiente sia dal lavoratore tramite dei nodi; il lavoratore
indossa l’abito che è cablato.
• I nodi comunicano con una piattaforma centrale attraverso un’interfaccia bluetooth.
• È stata sviluppata un’applicazione Android che raccoglie i dati provenienti dai vari nodi.
• I dati vengono, a loro volta, inviati su un cloud per essere analizzati. In questo caso è stata
usata la piattaforma Firebase che ha il pacchetto Firestore che permette di registrare file.
Firestore ha, inoltre, una serie di API che permettono l’interfacciamento con codici che
possono essere scritti con diversi linguaggi di programmazione: in questo caso è stato usato
Android per la piattaforma centrale e Python per la comunicazione con il resto
dell’elettronica. Una volta che i dati sono caricati sul cloud, il client è in grado di scaricarli e
di calcolare il rischio attraverso un modello di machine learning implementato in Matlab.
Effettuata la valutazione del rischio, viene ricaricata nel cloud e viene notificato alla
piattaforma centrale che mostra a video i risultati.

­
L’abito è composto da sensori strain gauge. Quando l’operatore indossa l’abito, i sensori di
deformazione risentono del movimento dovuto alla respirazione e si ottengono così informazioni
sull’estensione della cassa toracica. Sulla maglia è presente l’alloggiamento degli elettrodi per
eseguire l’ecg. Sulla schiena c’è un taschino per poter inserire una nuova elettronica (sempre
collegata tramite bluetooth) che serve a capire se ci sono stati o meno cambiamenti relativi allo
stato fisiologico della persona (cambio di temperatura, umidità della pelle, ecc..).

Ecco la spiegazione matematica che sta dietro la valutazione del livello di rischio: a seguito
dell’acquisizione dei segnali, vengono calcolati i parametri ma non facendo riferimento all’intero
segnale ma su finestre di 30 secondi. I dati calcolati vengono inviati al cloud. Il calcolo del rischio
viene implementato in Matlab. Quindi ogni 30 secondi viene calcolato un certo numero di
parametri (HR medio, LF, HF se si fa riferimento all’ecg) e ad ogni parametro calcolato
corrisponde un input del modello. Sulla base di ciò, in output dal modello abbiamo le classi di
rischio definite in fase di training e la probabilità con la quale può presentarsi una determinata
classe. L’operazione di training porta a definire i vari pesi del modello.

È stato necessario seguire e rispettare una serie di specifiche:

• Differenze nel luogo di lavoro: i segnali di interesse possono essere differenti a seconda del
tipo di task che il lavoratore è chiamato ad affrontare; è possibile quindi dover selezionare
solo i sensori di interesse: se, ad esempio, il lavoratore è seduto a lavorare al computer, il
sistema non avrà bisogno di un accelerometro; la selezione dei sensori di interesse avviene
sia per risparmio di energia sia perché ci sarebbe ridondanza;
• Cambiamenti di programma: è probabile che si voglia integrare un nuovo sensore all’interno
della board o che si voglia integrare un nuovo dispositivo nell’applicazione;
• Nodi: quanti nodi si vogliono utilizzare per acquisire i segnali? Bisogna tenere conto del fatto
che i siti di misura sono diversi e che, in generale, non si può avere un solo dispositivo di
misura. Nel caso di tanti segnali da acquisire, si presenta spesso il problema di dover
sincronizzare i dati dalle varie elettroniche.

Come risolvere eventuali problematiche che potrebbero presentarsi in fase di progettazione:

• Se i segnali provenienti dai sensori non sono tutti da acquisire, l’applicazione deve poter
selezionare i nodi di interesse;
• Il protocollo non dovrebbe dipendere dal numero di sensori. Ad esempio: se si ha la
possibilità di usare tanti canali con lunghezza limitata, è più semplice usare un canale per
 sensore e non uno solo per tutti i sensori. Questo perchè, nel caso in cui si vogliano
aggiungere nuovi sensori, potrebbe non bastare la lunghezza del canale (che è limitata).
Usare un canale per sensore permette di non modificare l’intero protocollo;
• Nel caso di più dispositivi, è necessario controllare contemporaneamente più nodi e
ottenere i dati simultaneamente sincronizzandoli dai vari device; questo complica le cose
dal punto di vista del software;

Di seguito sono mostrati i nodi utilizzati nel sistema dell’abito:

SensorTile Box e Seismote sono elettroniche progettate da terzi; le ultime due dal Centro Piaggio
per cui è stato deciso il protocollo, il tipo di comunicazione, ecc…. Con protocollo si intende il
modo in cui i dati vengono inviati all’applicazione.

Il protocollo bluetooth BLE è stato sviluppato da SIG che è una community che decide quali sono i
servizi, come devono essere strutturati, ne stabilisce le caratteristiche. Tutto ciò per permettere
la comunicazione tra dispositivi che non sono prodotti dallo stesso ente.

Funzionamento del protocollo:

• GAP: si occupa dell’interazione tra il dispositivo su cui il gap risiede e tutti gli altri device;
può essere a due ruoli: periferico e centrale. Quello periferico, in genere, non richiede
potenza elevata e si può connettere ad un solo device; quello centrale (pc, desktop,
smartphone, ecc…) può connettersi a più device ed è stato sfruttato nel progetto per la
comunicazione della periferica centrale con tutti i nodi;
• ADVERTISING e SCAN RESPONSE: sono meccanismi che permettono di segnalare la presenza
del dispositivo agli altri; mentre l’advertise è un messaggio più semplice, lo scan response
fornisce informazioni più dettagliate sul dispositivo. Prima della connessione, il gap
periferico e quello centrale si scambiano messaggi per segnalare la loro presenza e
scambiarsi informazioni: l’advertise viene inviato dal periferico con una certa cadenza e,
quando il centrale riceve un advertise, può richiedere uno scan response.
• BROADCASTING: si basa solo sull’uso degli advertise e non richiede una connessione, con
conseguenti vantaggi in termini di potenza. Al tempo stesso, però, c’è l’aspetto negativo
riguardante il fatto che i messaggi possono essere letti da tutti i dispositivi;
• GATT: contiene la struttura dei dati (cioè come i dati sono organizzati). In generale: il profilo
può avere più servizi; il servizio può avere più caratteristiche. Questa struttura dei dati è
molto vantaggiosa.
Ecco come si presenta l’interfaccia del setting di un nodo periferico:
si noti che il servizio contiene la caratteristica; la caratteristica contiene il descrittore. La
caratteristica contiene i campi e può avere diverse proprietà: tra le più importanti ci sono lettura,
scrittura, notifica, indicazione. Per quanto riguarda la notifica, il server avvisa il client che il campo
è cambiato in modo che il client possa leggere nel server. Dopo la notifica c’è la conferma da
parte del client dell’avvenuta lettura. È possibile decidere di dare o meno i permessi di
lettura/scrittura.

Il descrittore contiene, invece, altri metadati.

Esistono in commercio tanti moduli che integrano sia un micro che permette il campionamento
dei sensori (quindi di acquisire dati da altri dispositivi integrati presenti nel nodo stesso) sia un
modulo bluetooth che supporta il protocollo BLE e che può essere configurato con ambienti di
sviluppo particolari.

Alimentazione dei dispositivi

Le batterie usate sono lipo, con tensione non superiore a 3 o 4V. È richiesta un’alimentazione tra
1.7V e 3.6V e che sia stabile.
Le batterie lipo possono esplodere: necessitano quindi di un profilo di carica particolare.

Nell’immagine che segue è mostrato un integrato che segue il profilo che necessita la batteria; il
secondo integrato invece ha la funzione di stabilizzare la tensione e di portarla a 2.7V che è
compatibile con quella dell’integrato mostrato prima. Si noti il profilo di corrente nel grafico:
prima è costante, a 100 minuti inizia a diminuire. Questo consente una ricarica sicura del
dispositivo che, in caso contrario, potrebbe esplodere.

Nella figura che segue è mostrato il layout di uno dei nodi: in blu ci sono le tracce del bottom
(quindi della faccia inferiore); in rosso ci sono le tracce del top e poi ci sono degli strati intermedi.
I protocolli usati per la comunicazione tra gli integrati sono generalmente di due tipi: I2C o SPI.

I2C
La tecnologia I2C prevede il collegamento di due pin: uno per i dati (bidirezionale), uno per il
clock. Le operazioni che si possono compiere sono: scrittura e lettura. All’inizio di ogni
operazione, viene avviata l’operazione di start della sequenza (si passa dal livello logico alto a
basso prima per SDA e poi SCL); alla fine di ogni messaggio, c’è la stop sequence (viene alzato al
livello logico alto prima SCL e poi SDA). Sia per la scrittura sia per la lettura, all’inizio viene inviato
l’indirizzo: si noti che è possibile usare lo stesso bus per più sensori; il Master comunica con un
solo dispositivo alla volta; quando il Master interroga un sensore in particolare lo fa inviando il
suo indirizzo; tutti i sensori (Slave) leggono l’indirizzo, ma solo il sensore che effettivamente viene
interrogato dal Master acquisisce la linea e risponde. L’indirizzo è di 7 byte: sullo stesso bus è
possibile quindi attaccare 127 dispositivi. Inviato l’indirizzo, c’è un valore che indica se si tratta di
un’operazione di lettura/scrittura. L’ACK è la risposta da parte dello Slave: 0 se ha ricevuto il
messaggio, 1 altrimenti. Quanto appena descritto è la procedura che accomuna le operazioni di
lettura e di scrittura. I passi successivi sono invece differenti: per quanto riguarda la scrittura,
dopo l’invio dell’indirizzo, il Master invia il valore del registro su cui si vuole scrivere e poi il dato
corrispondente ad un certo numero di byte. Per la lettura invece il Master indica il registro da
leggere e lo Slave risponde acquisendo la linea SDA ed inviando i dati richiesti.

SPI
L’SPI è simile all’I2C. Si utilizzano però 4 pin: i primi due vengono utilizzati in direzioni diverse, la
terza linea corrisponde all’indirizzo di selezione (mentre nell’I2C si usava l’indirizzo per
selezionare lo Slave, nell’SPI c’è il Chip Select (CS) ovvero si abbassa la linea in modo da
selezionare lo Slave con cui il Master vuole comunicare), l’ultima linea è il clock che serve per
temporizzare i dati, cioè sincronizzare lettura e scrittura (c’è anche nell’I2C).

MISO è la porta di input del Master; MOSI di output; SDO e SDI sono le porte dello Slave
rispettivamente di output e di input.

Operazione di scrittura SPI:

CSB è il Chip Select che permette di selezionare il dispositivo con cui il Master vuole comunicare;
viene poi inviato l’indirizzo su cui si vuole effettuare l’operazione di scrittura (e non l’indirizzo del
dispositivo). Nell’esempio mostrato il dispositivo ha un indirizzo da 7 bit e in ogni registro c’è
un’informazione di 3 byte (guardare la linea dell’SDI che è la linea di input dello Slave). Si noti che
l’ottavo bit indicato con W codifica l’operazione di lettura/scrittura.

Operazione di lettura SPI:

anche in questo caso viene specificato il registro con cui però si vuole effettuare un’operazione
diversa: la lettura dei dati. In questo caso è importante la linea SDO: lo Slave risponde con i dati
contenuti nel registro

Nella figura che segue è mostrata l’architettura iniziale pensata per il sistema abito:
 • TensorFlow Life Model: è il modello di machine learning riportato in Android; è un modello
esterno che ha garantito il vantaggio di risparmiare memoria;
• La piattaforma su cui vanno a finire i dati è una piattaforma di Google; se i dati sono inferiori
a 2Gb, la piattaforma è gratuita;

Firebase ha una serie di tool disponibili:

• Analytics: permette di scambiare dati e quindi di analizzare in run time cosa succede
all’applicazione;
• È possibile creare un progetto in Firebase ma collegare gli stessi dati anche ad altre
piattaforme come Android, Python, Java, ecc…
• Cloud Functions: quando si verifica un certo evento che interessa il progetto vengono
invocate delle funzioni del cloud; queste funzioni sono automatiche e lavorano nel back
end, ovvero nella piattaforma serverless cioè l’infrastruttura non è gestita dall’utente ma da
un servizio esterno di Google;
• Firebase ML: è un modello di machine learning che risiede nell’infrastruttura e si può
interrogare; il modello è caratterizzato sempre dal modello di tipo TensorFlow;
• Remote Config: il developer può automaticamente configurare, ad esempio, i telefoni di
tutti gli utenti; l’utente pro può usufruire di servizi aggiuntivi rispetto all’utente base.

Teoria Laboratorio
Abbiamo visto come sia possibile, attraverso il protocollo MQTT, mandare le informazioni da un
sistema remoto ad un sistema centrale. Questo viene fatto attraverso una tecnologia di gestione
del messaggio che prevede il coinvolgimento di:

• PUBLISHER: chi pubblica il messaggio su un certo topic (argomento);

• SUBSCRIBER: chi sottoscrive il messaggio; è colui che “ascolta” il messaggio su un
determinato topic;
• BROKER: è colui che smista i messaggi con conseguente dispatching. In una forma a più
basso livello questo è il concetto di handler: l’handler è colui che gestisce il dispatch dei
messaggi all’interno di un sistema di comunicazione.

Il messaggio viaggia attraverso un paradigma topic: un determinato topic viene riconosciuto e

quindi il sistema riesce a catalogarlo. Attraverso questo metodo è possibile individuare i messaggi
che è possibile accettare in un sistema più complesso.
È interessante sottolineare che la comunicazione è asincrona. Questa cosa ci piace perché non c’è
dipendenza da una serie di eventi che obbligano a mantenere una determina tempistica. Per
questo motivo viene molto sfruttato il protocollo IoT classico.

Ci sono varie motivazioni a supporto dell’uso di questo tipo di comunicazione.

Tra le più importanti, la sicurezza del contenuto del dato e della sua persistenza.

Qualche differenza tra MQTT e HTTP a livello di prestazioni e di struttura del messaggio:
La slide mostra gli strumenti che useremo per il progettino e che vedremo durante il corso.

In particolare, vedremo più nel dettaglio InfluxDB che è un database dinamico.

Di seguito sono elencate alcune sue proprietà:
• È un database time­based: è previsto lo storage di serie temporali, cioè di un qualcosa che si
aggiorna temporalmente (è un database non relazionale, che tiene traccia dell’evoluzione
nel tempo);
• Supporta un protocollo http;
• È simile a SQL;
• Fa parte del gruppo dello stack TICK (Telegraf, InfluxDB, Chronograf, Kapacitor).

Questo tipo di database ci permette di fare:

• Analisi real time: il database viaggia con un certo clock che dipende dalla macchina che si sta
utilizzando; in questo caso per real time si intende lavorare tra eventi diversi con i tempi
macchina;
• Custom Monitoring: è possibile customizzare il modo in cui i dati vengono monitorati e le
modalità con cui vengono utilizzati;
• IoT e SensorData;
• Openstack, Docker, Virtualization.

Concetto di Timestamp
Quando si parla di sistemi di acquisizione o di monitoraggio, con timestamp si intende legare a
tutti i dati un contatore che tiene conto dei cicli di clock che intercorrono tra un campionamento
e l’altro. Questo perché, quando si ha a che fare con un hardware, non si avrà mai la sicurezza che
il tempo di campionamento venga sempre rispettato al ciclo macchina. Si crea dunque questo
contatore che viene incrementato ogni qual volta viene effettuato un campionamento. I dati non
viaggiano mai da soli: oltre ad essi, viene inviato anche il contatore (che prende il nome di tempo
macchina o di timestamp). Questo permette di effettuare un’operazione di ricostruzione di fitting
e di ricampionamento del dato. Questo fa sì che è possibile applicare la FT su un dato ma non
perché è stato inviato con una frequenza di campionamento uniforme ma perché, grazie al
timestamp, i dati vengono ricampionati alla frequenza opportuna. Le macchine non sono mai
costanti: non useranno mai lo stesso numero di cicli di clock per compiere le stesse operazioni
perché la macchina ha bisogno di fare altre operazioni diverse. Per questo, anche se di poco,
cambia il tempo di campionamento.
Di questo concetto va tenuto conto, soprattutto per il ricampionamento dei dati nel caso in cui si
voglia applicare la FT.

Da Telegraf i dati vanno a InfluxDB. Successivamente i dati vanno presentati sulla dashboard. Nel
mezzo possono essere fatte operazioni di processing (che noi non faremo). Telegraf è quindi
quell’agente che permette di gestire i dati che vengono mandati dal sistema e di trasferirli ad
InfluxDB. Quest’ultimo immagazzina i dati ricevuti e compie delle operazioni. InfluxDB è quindi un
vero e proprio database. Telegraf invece si occupa di aggregare, trasferire, trasformare i dati.

La dashboard che utilizzeremo è Grafana. Si tratta di un modulo grafico che presenta i dati che gli
vengono inviati da InfluxDB. Ci sono tantissime metriche che Grafana costruisce: noi avremo una
serie temporale (come mostrato nel grafico in alto a destra) rappresentata su una scala che sarà
più o meno corretta a seconda del tempo di campionamento con cui viene selezionato il segnale.
Sulla serie temporale Grafana calcola una serie di metriche che possono essere modificate.
Vedremo sicuramente il messaggio con uno specifico topic che Telegraf ha deciso di accettare.

Di seguito è mostrato uno sketch di Arduino dove è stata implementata la comunicazione tra
Arduino e il sistema che si basa sul protocollo MQTT. La parte iniziale consiste in assegnamenti di
variabili che servono per usare MQTT. Per poter accedere a MQTT c’è da stabilire una
connessione wi­fi: va fatta la gestione dello stato del wi­fi con le librerie apposite.
Viene poi mandato il broker (in questo caso del gruppo 23) con una stringa che deve
necessariamente contenere il topic. La stringa viene poi riconvertita e utilizzata da Telegraf per
conservarla su InflaxDB e visualizzarla su Grafana. Si noti che, a parte la gestione del wi­fi, va
gestita anche la tempistica e il tipo di messaggio da mandare. Successivamente il client pubblica il
topic sulla linea che viene poi stampata.