Elaborato di Web and Real Time Communication Systems

1. UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II
Scuola Politecnica e delle Scienze di Base
Dipartimento di Ingegneria Elettrica
e Tecnologie dell’Informazione
Corso di Laurea Magistrale in Ingegneria Informatica
Elaborato del corso di Web and Real Time Communication Systems
IoT Remote Care
Docente: Candidato:
Prof. Simon Pietro Romano Marco Vaiano
Matr. M63001186
ANNO ACCADEMICO 2021/22

2. Sommario
Capitolo 1: Introduzione ........................................................................................................3
Capitolo 2: Tecnologie utilizzate ............................................................................................4
2.1 XMPP............................................................................................................................4
2.2 XML ..............................................................................................................................6
2.2 Spring Boot...................................................................................................................8
Capitolo 3: Sviluppo del sistema..........................................................................................10
3.1 Dispositivo IoT............................................................................................................11
3.1.1 Sviluppo Hardware..............................................................................................13
3.1.2 Gestione della configurazione.............................................................................18
3.1.3 Campionamento dei parametri vitali..................................................................20
3.1.4 Gestione dell’evento “allarme”...........................................................................20
3.1.5 XMPP Client.........................................................................................................22
3.2 Web Application.........................................................................................................29
Riferimenti ...........................................................................................................................33

3. Capitolo 1: Introduzione
Nel 2020 siamo entrati in una nuova era nel quale si è reso necessario
digitalizzare tutto ciò che ci circonda. L’emergenza sanitaria al quale
tutti i paesi sono stati chiamati ad affrontare ci ha costretti a restare
isolati nelle proprie abitazioni con la speranza di ritornare alla
normalità nel minor tempo possibile.
Risulta evidente che anche l’interazione paziente-dottore sia cambiata,
in quanto, specie nella fase più acuta della pandemia, al fine di limitare
gli spostamenti e quindi la diffusione del virus, si sono cercati metodi
alternativi di comunicazione.
Lo sviluppo delle reti di ultima generazione e dei dispositivi IoT ci
consentono, se ben integrati, di effettuare monitoraggio remoto dei
pazienti. In questo modo un dottore potrà ricevere automaticamente
e in tempo reale, i parametri vitali dei suoi pazienti sottoposti a
controllo senza che essi siano fisicamente presenti nelle strutture
sanitarie.
In questo elaborato si affronteranno le tematiche relative ai protocolli
di comunicazione di tipo Instant Messaging, nello specifico si riferirà a
XMPP definito dall’RFC 3920.
Grazie a questo protocollo e alla sinergia di altre tecnologie, come le
Spring Web Applications e il linguaggio XML, si è sviluppato un sistema
di remote-healthcare nel quale diversi dispositivi IoT installati presso
ciascun paziente sono in grado di rilevare parametri vitali, come ad
esempio la frequenza del battito cardiaco, l’ossigenazione del sangue e
la temperatura, per poi inviarli periodicamente ai propri dottori di
riferimento.
L’instant messaging al quale siamo già abituati, ovvero quello che
comunemente chiamiamo “chat”, effettuato tramite gli innumerevoli
client software, ad esempio Skype o Whatsapp, in questo caso verrà
utilizzato per inviare comandi verso dispositivi IoT e ricevere delle
informazioni dagli stessi.
Obiettivo dell’elaborato sarà pertanto quello di implementare un
client di messaggistica su tali dispositivi e integrarlo in un sistema più
ampio nel quale ci saranno altre componenti le quali abiliteranno
diverse funzionalità al fine di facilitare l’interazione paziente-dottore.

4. Capitolo 2: Tecnologie utilizzate
In questo capitolo si analizzano i protocolli e le tecnologie utilizzate
nello sviluppo del sistema di remote-healthcare.
2.1 XMPP
Figura 2.1 Logo XMPP
L’Instant Messaging è una interazione “real-time” basata sullo
scambio di messaggi tra due o più client. Gli approcci utilizzati a questo
scopo sono principalmente quella client-server e peer-to-peer.
Esistono diversi protocolli che definiscono l’instant messaging e nello
specifico, in questo elaborato, sarà trattato XMPP.
L’idea del protocollo XMPP (Exstensible Messaging and Presence
Protocol) è quella di implementare una sorta di architettura federata
in cui risulta possibile avere diversi componenti lato server che
interagiscono tra loro per distribuire le informazioni tra un ampio
insieme di partecipanti.
L’RFC 6120 definisce quindi l’architettura, il protocollo, ovvero il modo
in cui effettuiamo lo scambio delle informazioni. Tipicamente le
informazioni si riferiscono al modo in cui i messaggi devono essere
crittografati, l’autenticazione dei client e le primitive per lo scambio di
messaggi e informazioni sulla presenza degli utenti connessi.
L’RFC 6121 definisce invece estensioni per XMPP i quali permettono di
aggiungere nuove funzionalità al protocollo di base.

5. XMPP è definito come un profilo applicativo di XML (Extensible
Markup Language), il quale consente di scambiare messaggi strutturati
in una modalità quasi real-time tra entità connesse alla rete.
Uno scambio quasi real-time vuol dire che non c’è alcun vincolo
stringente sulla reale tempestività della comunicazione.
Figura 2.2 Architettura XMPP
Dalla figura 1.2 si evince che l’architettura di XMPP è caratterizzata
dalla presenza di un certo numero di XMPP Server distribuiti in
Internet. Essi possono comunicare tra loro sfruttando una delle
funzionalità definite dal protocollo, ovvero canali server-to-server
(s2s). Le informazioni scambiate attraverso questi canali sono relative
ai client che essi gestiscono.
Ad ogni singolo Server possono essere collegati più client che
comunicano attraverso XMPP. I vari Client, connessi a diversi Server,
potranno quindi essere raggiunti tra loro sfruttando i suddetti canali
“s2s”.
Si noti inoltre la presenza di un Gateway il quale avrà il compito di
tradurre le informazioni dal protocollo XMPP ad uno non conforme
allo standard. In questo modo sarà possibile far comunicare client
appartenenti a diversi protocolli di Instant Messaging in modo del
tutto trasparente all’utilizzatore finale.
Tutte le entità XMPP sono indirizzabili in modo univoco mediante JID
(Jabber Identifier):
Figura 2.3 Struttura JID
In questa struttura si evincono diversi elementi:
• Node è una stringa che identifica un nodo. Tipicamente è il
client che si collega alla rete.

6. • Domain è l’identificativo del dominio che rappresenta il server o
il gateway
• Resource rappresenta una specifica connessione associata al
client. Questo elemento è opzionale.
Nel protocollo risultano definiti gli “stream”, ovvero sequenze di byte
inviati su un canale TCP reso sicuro tramite TLS.
All’interno di uno stream potremo avere delle “stanzas” ovvero, una
sorta di scenario di comunicazione definito dal protocollo.
Esso definisce una comunicazione monodirezionale, pertanto per una
comunicazione bidirezionale saranno necessari due stream.
La comunicazione tra i diversi client avviene definendo una
connessione tra gli stessi e un server XMPP seguendo diverse fasi di
setup le quali saranno definite in seguito quando verrà descritta
l’implementazione del client su dispositivo IoT.
2.2 XML
XML, acronimo di Extensible Markup Language, non è un linguaggio di
programmazione, ma un meta-markup language in quanto permette di
definire nuovi elementi creando così nuovi linguaggi markup, a
differenza di HTML nel quale invece sono definiti dei tag
standardizzati.
I linguaggi di Markup consentono di descrivere la forma di un
documento e definiscono il modo in cui deve essere interpretato.
Come citato in precedenza, HTML è uno dei linguaggi di markup in cui
sono presenti dei tag predefiniti (es. “head”).
I documenti scritti in questo linguaggio possono generalmente essere
interpretati da un browser. Nel caso in cui si utilizzi un documento
scritto in HTML, il browser sarà già in grado di interpretare
correttamente l’intero documento e il modo in cui dovrà essere
presentato.
Qualora invece fosse definito un documento XML con dei tag
“personalizzati”, risulterà necessario fornire anche lo stile associato al
documento scritto. Questo risulterà scritto mediante XSL, ovvero
Extensible Style Sheets Language.

7. Un documento XML è caratterizzato da tre parti: prologo, root e una
parte opzionale.
La parte di prologo conterrà le processing instructions, commenti,
style sheet, ecc.
Un documento conforme alla specifica definita da W3C, si dirà well-
formed se rispetta le seguenti regole sintattiche:
• Ogni tag aperto deve essere chiuso
• Gli elementi non possono sovrapporsi. Ad esempio un tag figlio
non può essere chiuso dopo quello del padre.
• Ci deve essere un solo elemento root.
• I valori degli attributi devono essere inseriti tra virgolette
• I commenti e “processing instructions” non possono essere
inseriti all’interno dei tag
• Nessun carattere < o & può essere parte di un elemento o
attributo
Figura 2.4 Documento XML
La well-formed di un documento XML è un requisito essenziale, ma
non è l’unico. Può essere considerato valido se è associato e conforme
ad un DTD (Document Type Definition).
Un DTD definisce l’esatta struttura di un documento. In alternativa si
potrà definire un XML Schema il quale è stato introdotto al fine di
semplificare la descrizione di una struttura complessa. Risulta infatti
ad esempio possibile definire i tipi di dati effettivi di ciascun elemento,
specificare le occorrenze minime e massime, distinguere i tipi semplici
da quelli complessi.

8. Il metalinguaggio XML risulta essere molto utile anche per lo scambio
di informazioni tra dispositivi eterogenei connessi alla rete.
Questa soluzione è stata utilizzata nel corso dello sviluppo di questo
elaborato e verrà discussa in seguito.
2.2 Spring Boot
Figura 2.5 Logo Spring Boot
Spring è un framework opensource per lo sviluppo di applicazioni su
piattaforma Java. Esso introduce un container IoC (Inversion of
Control) il quale avrà il compito di chiamare porzioni di codice che
rappresenteranno la logica di business dell’applicazione che si sta
sviluppando. In questo scenario non saranno le applicazioni che
chiamano il framework, ma viceversa. Tale container gestisce inoltre
l’intero ciclo di vita degli oggetti che si vanno a richiamare.
Con il framework Spring risulta possibile implementare applicazioni
basate su microservizi, applicazioni reattive, web app, ecc.
Spring Boot è una soluzione per la creazione di applicazioni Spring.
Esso utilizza un paradigma convention-over-configuration nel quale si
riduce il numero di decisioni che uno sviluppatore dovrà prendere,
senza ridurre la flessibilità. Risulta altresì possibile introdurre una
configurazione esplicita qualora il comportamento desiderato
risultasse diverso da quello predefinito.
Spring Boot riduce quindi la complessità di configurazione di nuovi
progetti Spring e offre la possibilità di incorporare direttamente
applicazioni web server/container come Apache Tomcat.
Prima della sua creazione, tutte le applicazioni basate su Spring
avevano bisogno di un web server di supporto per essere eseguite.
Con Spring Boot invece si rende possibile sviluppare applicazioni
stand-alone avente un metodo “main” che lancia l’intera applicazione
web, compreso il web server integrato e lasciando nel caso la

9. possibilità di generare, mediante Maven o Grandle, pacchetti di tipo
war da usare all’interno di un web server.
Inoltre offre una configurazione Maven semplificata grazie ai POM
(Project Object Models) e configurazione automatica di Spring.
Esistono numerose dipendenze predefinite all’interno di Spring Boot al
fine di semplificare le configurazioni di build di un’applicazione.
Il framework comprende e risolve in automatico le dipendenze
associate analizzando il suo classpath.
Spring Boot fornisce funzionalità production-ready, ovvero funzionalità
messe a disposizione da Spring che possono essere utilizzate in
qualsiasi momento.
Un esempio sono i controlli di integrità i quali permettono di
controllare lo stato di attività dell’applicazione.
Questo approccio esalta la semplicità d’uso, infatti non richiede
generazione di codici o configurazioni XML.
Grazie a circa 20 moduli del framework di base, Spring Boot è adatto
per diversi scenari. Esso infatti non può essere semplicemente
classificato come framework per applicazioni web, né come soluzione
classica per applicazioni desktop.
Risulta inoltre, come citato in precedenza, possibile creare dei
pacchetti JAR con server embedded.
Questa possibilità è stata sfruttata per lo sviluppo di questo elaborato,
in particolare per una web application, la quale verrà descritta in
seguito.

10. Capitolo 3: Sviluppo del sistema
Si andrà adesso a descrivere la progettazione di un sistema nel quale
saranno presenti diversi componenti sviluppati con le tecnologie
descritte nel precedente capitolo.
Figura 3.1 Schema complessivo del sistema
L’obiettivo finale sarà quello di implementare un client XMPP
all’interno di dispositivi embedded i quali avranno il ruolo di “Agent”,
al fine di consentire lo scambio di informazioni con altri client, questa
volta “Manager”, tutti connessi ad un server XMPP.
Si prevede inoltre che tali dispositivi siano riconfigurabili in tempo
reale grazie ad una web application realizzata con il tool Spring Boot.
Lo scambio dei messaggi, quindi delle configurazioni, tra la web

11. application e i dispositivi IoT avviene grazie alla produzione di
documenti scritti sfruttando il metalinguaggio XML.
Dalla figura 3.1 si evince anche la presenza della piattaforma cloud
Azure, in particolare del database “NoSql” CosmosDB. Questo
database risulterà utile per la memorizzazione persistente delle
configurazioni inserite da ciascun dottore e prelevate dai dispositivi
associati ai pazienti.
Di seguito è riportato il diagramma dei casi d’uso al fine di
comprendere meglio i requisiti funzionali del sistema che si andrà a
realizzare.
Figura 3.2 Diagramma dei casi d’uso
Ciascun dispositivo IoT Agent andrà ad inviare periodicamente i
campioni dei parametri vitali ad uno specifico medico (in fig. 3.1
identificato come “Manager”) ad esso associato, mediante protocollo
XMPP. La configurazione dei dispositivi, quindi le informazioni relative
a ciascun paziente, ma anche dei dati di accesso, potranno essere
visualizzate e modificate da ciascun medico.
Si prevede pertanto che i dispositivi ricevano la propria configurazione
in fase di startup prelevandola dal server remoto.
3.1 Dispositivo IoT
Elemento fondamentale del sistema in sviluppo è rappresentato dal
dispositivo IoT situato presso ciascun paziente.

12. Esso è realizzato sfruttando le potenzialità della scheda di sviluppo
ESP8266-12E e di diversi sensori i quali consentono di prelevare la
frequenza del battito cardiaco, percentuale di ossigenazione del
sangue e la temperatura corporea.
Tutte queste informazioni dovranno poi essere inviate ad un server
XMPP utilizzando un client scritto ad-hoc per questi dispositivi.
Si prevede inoltre che essi siano alimentati a batteria e connessi ad
una rete Wi-Fi, in modo da consentirne l’utilizzo in mobilità.
Figura 3.3 Flowchart sistema complessivo

13. In figura 3.3 è rappresentato il diagramma di flusso relativo alle
operazioni effettuate dal software implementato nella scheda.
Nel caso di sviluppo software per dispositivi IoT come in questo caso,
risulta inoltre fondamentale evitare sprechi di risorse in quanto
limitate. La scheda ESP8266-12E utilizzata in questo progetto, monta
una memoria flash esterna da 1MB.
Le dimensioni del software implementato, calcolate mediante la
metrica “LOC” (Lines Of Code) ammontano a 382 Phy. SLOC (ver.
12_05_2022).
Il consumo della memoria è stato rispettivamente del 29% (312776
bytes) per lo “sketch” ovvero il codice e 38% (31856 bytes) per le
variabili globali lasciando 50064 bytes residui per le variabili locali.
Si andrà adesso a descrivere in dettaglio sia la parte hardware che
quella software.
3.1.1 Sviluppo Hardware
Caratteristica fondamentale del dispositivo in sviluppo è la sua
capacità di rilevare i parametri vitali del paziente per poi poterli inviare
su un canale di comunicazione wireless.
Si necessita pertanto dei seguenti componenti/schede elettroniche:
Figura 3.4 Figura 3.5 Figura 3.6
Figura 3.7 Figura 3.8

14. • Scheda di sviluppo ESP8266-12E (figura 3.4)
Si tratta di una scheda di sviluppo prodotta da “AI-Thinker”, tra le più
conosciute della famiglia ESP8266 di “Espressif”, ampiamente
utilizzata nell’IoT grazie anche al costo decisamente ridotto. Monta un
microprocessore RISC da 80MHz e una memoria flash esterna. Dispone
di diverse interfacce di comunicazione, tra cui UART e I2C.
Tra i punti di forza troviamo la presenza di una interfaccia di rete
wireless con supporto al protocollo 802.11 b/g/n “onboard” con
relativa antenna stampata sul PCB e la possibilità di utilizzare lo stesso
IDE di Arduino e SDK sviluppato ad-hoc.
• Sensore MAX30100 (figura 3.5)
Si tratta di una soluzione integrata per sensore di pulsossimetria e
cardiofrequenzimetro. Sviluppato da Maxim Integrated nel 2014,
dispone di due LED (IR e RED), un foto rilevatore, un’ottica ottimizzata
e un elaboratore del segnale analogico a basso rumore.
La comunicazione del sensore avviene mediante canale I2C grazie
all’utilizzo dei pin SDA e SCL, rispettivamente relativi al trasferimento
dei dati e alla sincronizzazione del clock.
Figura 3.9 System Block Diagram MAX30100
Il principio di funzionamento risulta essere semplice, esso si basa
sull’emissione di una certa quantità di luce rossa (o infrarossa) sulla
pelle del paziente ad una specifica lunghezza d’onda. La luce emessa

15. verrà poi riflessa dall’emoglobina e catturata dal fotosensore posto
sulla scheda. I valori vengono processati tramite una elaborazione ADC
per poi essere inseriti in un buffer circolare.
Il driver di gestione della periferica consente di effettuare diverse
operazioni di filtraggio dei campioni catturati in modo da ripulire il
segnale dall’eventuale rumore.
Figura 3.10 Fotopletismogramma
Il calcolo della frequenza del battito cardiaco si basa su una nota
ricerca pubblicata nel 2014 nel quale gli autori analizzarono il segnale
tracciato su un fotopletismogramma e individuarono un
comportamento ciclico dovuto a eventi di sistole e diastole.
Attraverso l’analisi dei valori dei campioni prelevati relativi alla
quantità di luce riflessa dal sensore, si è notato un comportamento
simile a quello pubblicato dai ricercatori.
Il codice pertanto rileva ciascuno dei battiti cardiaci e ne stima la
frequenza in un periodo di 60 secondi, ottenendo così i “battiti per
minuto”.
• Sensore AHT10 (figura 3.6)
Si tratta di un sensore ad alta precisione in grado di rilevare
temperatura e umidità. La precisione relativa alla temperatura è di ±
0.3 ° C, mentre la sua risoluzione è 0.01 °C.
Anche per questo sensore viene utilizzata una comunicazione I2C
grazie ai pin SCL e SDA.

16. In questo progetto il sensore viene calibrato in modo tale da ottenere
una tipica temperatura corporea (ascellare) a partire dal rilevamento
di quella rilevata sul polso.
• Batteria ricaricabile da 3.7v, 1000mAh (figura 3.7) e TP4056
(figura 3.8)
TP4056 è un modulo di ricarica per batterie Li-Ion con metodo di carica
a corrente costante e tensione costante (CC/CV) mediante interfaccia
micro-usb.
E’ inoltre dotato di un chip di protezione della batteria da sovra-
scariche, sovraccarichi e cortocircuiti.
Questo modulo risulta utile per la ricarica della batteria da 1000mAh
utilizzata nella realizzazione del dispositivo.
Si riporta adesso lo schema circuitale del sistema complessivo
ottenuto collegando i moduli descritti poc’anzi facendo anche
riferimento ai rispettivi datasheets forniti dai produttori.
Figura 3.11 Schema circuitale prodotto con EasyEDA
Dallo schema si può notare la presenza di alcune resistenze
denominate anche di “pull-up” per il canale I2C.

17. La loro presenza risulta fondamentale per la connessione di diversi
dispositivi sullo stesso canale di comunicazione.
Nel caso in cui venissero omesse, la linea di clock (SCL) e quella di dati
(SDA) resterebbero sempre intorno al valore 0 V.
Comunemente viene utilizzato un valore di 4.7 kΩ per entrambe le
resistenze poste rispettivamente sulle linee SCL e SDA.
Di seguito è riportata una foto del prototipo del dispositivo.
Figura 3.12 Prototipo del dispositivo IoT
Figura 3.13 Prototipo indossato sul braccio
Si noti, oltre ai vari moduli descritti in precedenza, la presenza di un
pulsante fisico attraverso il quale un paziente potrà inviare un
messaggio di “allarme” al proprio dottore.

18. 3.1.2 Gestione della configurazione
La prima operazione effettuata a livello software dal dispositivo IoT è
relativa alla configurazione di diversi parametri legati sia alla
connessione con il server XMPP che alle informazioni sul paziente.
Al fine di permettere un facile riutilizzo del dispositivo all’arrivo di un
nuovo paziente sottoposto al monitoraggio, si è deciso di integrare un
meccanismo di prelievo della configurazione attraverso la rete
Internet.
Queste informazioni di configurazione, formattati secondo il
metalinguaggio XML, una volta scaricate dal web server di riferimento
sul quale è installata una web application (descritta nel capitolo
successivo), saranno trasferite ad un Parser il quale andrà a
distinguere i diversi elementi e valori associati ad essi.
I valori prelevati andranno pertanto a configurare i parametri del
dispositivo evitando di dover modificare e compilare continuamente il
codice sorgente del software implementato sul dispositivo IoT.
Figura 3.14 Connessione http
La prima parte del codice aprirà una connessione HTTP con il server, il
cui percorso è definito dalla variabile “serverPath”.
La richiesta delle informazioni avviene mediante un metodo HTTP GET,
ovvero sfruttando il meccanismo delle “query string” inserendo in
questo caso l’identificativo associato al dispositivo in questione.
In caso di esito positivo (response code = 200) si andrà a memorizzare
il payload della risposta, altrimenti verrà stampato sulla seriale un
messaggio d’errore. Si noti che tutto ciò che viene scritto
sull’interfaccia seriale, sarà visualizzabile in fase debugging del
dispositivo quando esso viene connesso al PC.

19. Figura 3.15 Parsing documento XML
Ricevuto il payload dal server, si va ad analizzare il contenuto del
documento XML utilizzando un Parser il quale partendo dalla root,
andrà a scorrere e memorizzare tutti gli elementi “figlio” ad esso
associati.
Di seguito è riportata la visualizzazione del documento XML attraverso
un comune web browser.
Figura 3.16 Documento XML inviato dal server
Si noti la particolare struttura del documento.
Vista la mancanza di un foglio di stile ad esso associato, il browser non
riuscirà a rappresentarlo come una comune pagina HTML, ma nel
sistema in sviluppo non occorre in quanto il documento XML è
utilizzato al solo fine di trasferire delle informazioni tra due entità
connesse alla rete.

20. 3.1.3 Campionamento dei parametri vitali
Elemento chiave del dispositivo è rappresentato dal campionamento
dei valori rilevati dai sensori.
Come descritto nel flowchart in precedenza (figura 3.3), questi
parametri vengono campionati periodicamente ad intervalli di 30
minuti e poi inviati al destinatario della comunicazione XMPP, ovvero il
dottore di riferimento al paziente.
Figura 3.17 Setup dei sensori Figura 3.18 Campionamento dei valori
In questa porzione di codice (figura n. 3.18) viene effettuato il prelievo
dei valori di frequenza cardiaca, percentuale ossigenazione del sangue
e temperatura corporea ogni 500ms in modo da avere risultati
significativi per l’invio periodico dei parametri vitali del paziente.
L’accuratezza dei valori viene fortemente condizionata da una serie di
parametri tra i quali, il passaggio di fasci di luce all’interno del
fotosensore, oppure la temperatura stessa della scheda MAX30100.
Queste condizioni non consentono sempre di prelevare valori corretti
pertanto si è cercato di filtrarli e considerare rispettivamente quelli
relativi alla frequenza cardiaca compresa tra 30 e 250 bpm, e quelli
relativi alla percentuale di saturazione compresa tra 50 e 100 %.
3.1.4 Gestione dell’evento “allarme”
L’interazione tra paziente e dottore non avviene soltanto con un invio
periodico dei parametri vitali, ma anche a seguito di un comando
inviato da un dottore (descritto in seguito), oppure con la pressione di

21. un pulsante fisico di tipo “push button” sul dispositivo IoT situato
presso il paziente.
Una interrupt è associata all’evento di pressione del pulsante in modo
tale da richiamare una funzione di callback.
Figura 3.19 Configurazione Interrupt
A tal fine, in fase di setup della scheda ESP8266 si specifica un pin
fisico (D5) al quale viene associata e quindi richiamata la funzione di
callback (intCallBack) a seguito di un evento “Falling”, ovvero quando il
pin passa dallo stato logico 1 a 0.
Figura 3.20 Funzione di callback
La funzione di callback sviluppata non farà altro che impostare a “true”
la variabile “alert”.
Figura 3.21 Gestione dell’allarme
All’interno del “loop di sistema”, quando questa variabile viene posta
al valore “true” scatena l’invio di un messaggio di “allarme” verso il
destinatario della conversazione su protocollo XMPP, ovvero il medico
di riferimento.
Questa condizione scatena inoltre il campionamento manuale dei
parametri relativi al paziente, ovvero senza rispettare la periodicità di
invio, i quali verranno quindi anch’essi inviati al medico a seguito della
pressione del pulsante fisico.

22. 3.1.5 XMPP Client
Il meccanismo attraverso il quale un dispositivo IoT riesce ad inviare i
parametri vitali campionati, come visto in precedenza, in maniera
periodica o manuale è dato dal protocollo XMPP.
Questo protocollo, definito dall’RFC 6120 (con estensione RFC 6121)
sfrutta stream monodirezionali su canale TCP per scambiare messaggi
con un server di riferimento.
Gli stream vengono descritti mediante metalinguaggio XML e
all’interno di essi avremo delle “stanzas” i quali rappresentano l’unità
base di comunicazione.
Diverse “stanza” sono definite dal protocollo, tra i quali “Presence” e
“Message”.
Come introdotto nel capitolo precedente, tutte le entità in XMPP sono
indirizzabili in modo univoco mediante JID, ovvero dai parametri node,
domain e resource.
Risulta fondamentale registrare presso il server le credenziali di
accesso relative ai dispositivi IoT i quali avranno il ruolo di client XMPP.
Per lo sviluppo di questo elaborato si è scelto di installare e
configurare un server XMPP “ejabberd” su un server NAS sbloccando
inoltre le porte del firewall presente sul gateway in modo da garantire
l’accesso dall’esterno della rete.
Definito lo JID, il protocollo stabilisce diverse fasi per la connessione al
server.
Figura 3.22 Connessione a server XMPP

23. 1. Stream setup
Il client inizializza uno stream con il server.
Figura 3.23 Apertura stream
In questo caso viene inviato uno stream specificando il dominio,
ovvero uno dei parametri JID, nel documento XML da inviare al server.
Il flusso di dati viene inviato sfruttando il metodo “write” dell’oggetto
“client”, istanza della classe WifiClient.
2. Authentication
Il client effettua l’autenticazione presso il server XMPP sfruttando una
negoziazione SASL (Simple Authentication and Security Layer).
Figura 3.24 Richiesta di autenticazione

24. Le credenziali di accesso, espresse come username e password,
vengono codificate utilizzando la libreria “base64”.
Le credenziali vengono poi incapsulate in un messaggio, formattato
mediante metalinguaggio XML seguendo la struttura definita dal
protocollo, per poi essere inviato sul canale di comunicazione.
3. Stream restart
Se la negoziazione SASL ha avuto successo, il client dovrà riavviare lo
stream.
In questo caso si frutterà lo stesso messaggio inviato nella fase 1,
ovvero di creazione dello stream.
4. Resource binding
Ultima fase relativa alla connessione client-server in XMPP è
rappresentata dal “resource binding” nel quale il client può associarsi
ad una risorsa lato server.
Figura 3.25 Resource binding
Si noti (figura n. 3.22) che al termine di ogni fase è prevista una
elaborazione della risposta.
Tutte le fasi appena descritte infatti comportano la ricezione di un
messaggio di risposta da parte del server, codificato sempre
utilizzando il metalinguaggio XML.

25. Figura 3.26 Elaborazione della risposta dal Server
Il processing di basa essenzialmente sulla rilevazione di elementi che ci
riconducono ad una risposta “positiva” da parte server.
Per ciascuno stato infatti, sono state identificate delle parole chiave e
appositamente raccolte in un array.
Figura 3.27 keywords delle risposte relative a ciascuna fase
L’algoritmo prevede lo scorrimento dell’intero buffer contenente il
messaggio ricevuto dal server finalizzato a rilevare le parole chiave.
Si deciderà quindi se passare o meno al nuovo stato, quindi alla fase
successiva di setup della connessione XMPP.
Una volta stabilita la connessione, la successiva operazione è quella di
segnalare la presenza, quindi l’attività del client in modo tale che gli
altri client si accorgano della sua disponibilità.
Figura 3.28 Segnalazione della presenza

26. Anche questa operazione avviene secondo le modalità descritte in
precedenza, relative all’invio degli streams.
Stabilita la connessione e segnalata la presenza, il client adesso potrà
inviare e ricevere messaggi.
L’invio dei messaggi avviene mediante delle “stanzas” le quali, come
accennato in precedenza, sono unità semantiche di informazioni
strutturate ed inviate su un flusso XML.
Figura 3.29 Invio messaggio
Differenti attributi possono essere definiti all’elemento message. In
questo caso il “type” sarà chat in quanto si prevedono solo
conversazioni uno-a-uno tra i dispositivi IoT dei pazienti e i client
gestiti dai medici.
Negli attributi “from” e “to” avremo rispettivamente lo JID mittente e
destinatario.
Infine nel tag “body” si avrà il messaggio vero e proprio, inviato dal
client mittente.
Di seguito sono riportati degli esempi di messaggi inviati da un client
IoT e ricevuti da un generico client XMPP per ambienti Windows, in
questo caso Spark.
Figura 3.30 Richiesta e ricezione di campioni manuali e periodici

27. Figura 3.31 Richiesta e ricezione delle informazioni sul paziente
I messaggi mostrati nelle figure 3.30 e 3.31 riguardano le funzionalità
di invio periodico dei parametri vitali di uno specifico paziente
(campionati dagli specifici sensori come descritto nel capitolo
precedente) e delle sue informazioni personali.
Si precisa che le informazioni di ciascun paziente vengono prelevate
dal server mediante la web application che sarà descritta nel
successivo paragrafo.
Si noti inoltre che contestualmente all’invio dei campioni, viene inviato
anche data e ora, entrambe prelevate attraverso l’utilizzo della libreria
NTP Client.
Anche l’eventuale pressione del bottone di “allarme” situato sul
dispositivo IoT, innesca l’invio di un messaggio contenente un
campione dei parametri vitali.
Figura 3.32 Allarme asincrono generato dal dispositivo IoT su richiesta del paziente
Infine si è sviluppata una funzione in grado di ricevere sul dispositivo
IoT del paziente dei comandi inviati dal client XMPP associato al
medico di riferimento, come mostrato nelle figure 3.30 e 3.31.
Nelle immagini precedenti sono stati infatti evidenziati scenari di
comunicazione nel quale erano presenti anche dei campioni ricevuti in

28. modalità “manuale”, ovvero ricevuti su richiesta del medico attraverso
l’invio un comando.
Altri comandi sono stati implementati in modo da consentire il riavvio
del dispositivo da remoto o semplicemente per disconnetterlo dal
server XMPP.
Figura 3.33 Elaborazione del messaggio ricevuto
L’algoritmo sviluppato risulta alquanto semplice. Viene effettuato un
“parsing” del messaggio, formattato in metalinguaggio XML secondo le
specifiche del protocollo XMPP, al fine di individuare il tag di inizio e di
fine dell’elemento “body”. Si procede poi estrapolando il messaggio
compreso tra i due tag.
Figura 3.34 Scenario tipico “buddy-list” dottore
In questo modo ciascun medico che avrà in carico diversi pazienti
potrà, attraverso la sua buddy-list (roster) e le varie chat ad essi

29. associate, monitorare i parametri vitali ed interagire con il dispositivo
IoT situato presso ciascun paziente.
3.2 Web Application
Come già accennato nei precedenti paragrafi, la configurazione di
ciascun dispositivo IoT associato ai pazienti viene prelevata in fase di
startup dal web server di riferimento.
Questo avviene grazie all’utilizzo di una web application sviluppata
sfruttando le potenzialità del framework Spring, in particolare di
Spring Boot.
Si è inoltre scelto di memorizzare in maniera persistente ciascuna
configurazione su un database “NoSql” CosmosDB offerto dal cloud
Microsoft Azure.
Figura 3.35 Porzione del file pom.xml
L’applicazione dovrà pertanto includere le dipendenze dalle librerie di
accesso a CosmosDB oltreché quelle associate a thymeleaf, descritto in
seguito.
Figura 3.36 Gestione richiesta “getconfig”
Questa funzione andrà a prelevare una specifica configurazione in
base all’identificativo passato come parametro di un metodo HTTP
GET. Essa è associata ad un “item” nel container costruito in
CosmosDB e poi inserita in un oggetto di classe Device sfruttando il

30. meccanismo delle annotation. Con lo stesso meccanismo e sfruttando
la libreria JacksonXML si va inoltre a costruire un documento XML
andando ad inserire i valori negli elementi, e quindi nei specifici “tag”.
Questo documento viene poi inviato al client, ovvero al dispositivo IoT
che ne ha fatto richiesta il quale ne effettuerà il “parsing” per
recuperare i diversi parametri associati al paziente.
La web application sviluppata consente inoltre di modificare i valori di
configurazione sfruttando il meccanismo dei template, ovvero delle
pagine web parzialmente complete, riempite poi con dei parametri
inseriti a tempo di esecuzione.
Figura 3.37 Template della pagina “update”
In questo caso viene sfruttato il meccanismo Spring MVC in modo tale
che il template di pagina, ovvero la view, richiami gli attributi presenti
nel model.
Figura 3.38 Gestione della richiesta “modifica”
Nella documentazione di tymeleaf vengono definite diverse modalità
di inserimento degli attributi (definiti anche context variables)
all’interno della view, uno di questi si basa sull’utilizzo del metodo
.addObject(Object attributeValue) della libreria Spring.

31. Figura 3.39 Pagina di modifica configurazione Figura 3.40 Pagina di visualizzazione dispositivi IoT
Questa soluzione risulta particolarmente utile per il riutilizzo dei
dispositivi IoT. In questo modo infatti, un dispositivo già utilizzato in
precedenza potrà essere assegnato ad un nuovo paziente sottoposto a
monitoraggio semplicemente interagendo con la web application, con
il quale si potrà associare i parametri relativi al nuovo paziente.
La modifica delle configurazioni si conclude aggiornando di
conseguenza gli oggetti presenti nel container CosmosDB in Azure.
Capitolo 4: Conclusioni
In questo elaborato si è dimostrata la possibilità di implementare un
client XMPP all’interno di dispositivi embedded dotati di limitate
capacità elaborative, come la scheda di sviluppo a microcontrollore
ESP8266.
Grazie a questo protocollo di “instant messaging” è stato possibile
sviluppare un sistema di monitoraggio remoto dei pazienti.
Ciascun dottore avrebbe così la possibilità di interagire controllando i
parametri vitali di ciascun paziente attraverso un campionamento
periodico oppure in alternativa richiedendo un campione “manuale” in
tempo quasi reale.
Si evidenzia inoltre la possibilità per i pazienti di segnalare anomalie
attraverso un apposito bottone posto sul dispositivo IoT.

32. Grazie alla rapida diffusione del protocollo aperto si è assistito allo
sviluppo di diversi client open source per numerose piattaforme, come
ad esempio AstraChat per smartphone Android.
In questo modo risulterebbe possibile integrarlo nel progetto descritto
in questo elaborato in modo da consentire un monitoraggio anche in
mobilità dei parametri di ciascun paziente, da parte di un dottore.
Infine il servizio di database geo-distribuito offerto da Microsoft Azure,
denominato CosmosDB ha consentito una memorizzazione efficiente e
sicura delle informazioni di configurazione relative ai dispositivi IoT.
Fondamentale è stato inoltre l’utilizzo di XML il quale ha reso possibile
la comunicazione tra dispositivi eterogenei grazie alla descrizione in
metalinguaggio di ciascuno scambio di informazioni tra le varie entità.
Risultano però dei punti deboli relativi al protocollo XMPP.
Lo svantaggio principale è dato dall’overhead aggiunto dal protocollo,
infatti, in genere oltre il 70% del traffico con il server è costituito da
dati di presenza e quasi il 60% di esso è ridondante.
Inoltre XMPP non prevede l’encryption end-to-end poiché il canale
sicuro che negoziamo eventualmente mediante TLS, avviene tra un
client e un server e non tra i due client.
Nel tempo sono state proposte diverse alternative a XMPP, come ad
esempio “ WebSocket-enabled IM”. Questa soluzione parte da una
comunicazione HTTP la quale va poi a configurare uno scambio di
messaggi tra le due entità mediante utilizzo di WebSocket ottenendo
così una bassa latenza tra client e server e abilitando casi d’uso come il
multiplayer online games, chat applications, etc.
Anche MQTT (Message Queuing Telemetry Transport) risulta popolare
per la comunicazione tra dispositivi IoT.
Questo protocollo consente scambi di messaggi di tipo “publish-
subscribe”. È stato progettato specificamente per la telemetria
“machine-to-machine” e in genere viene utilizzata in situazioni dove la
banda è limitata. Il pattern “publish-subscribe” richiede un broker di
messaggistica. Il broker risulta così responsabile della distribuzione dei
messaggi ai client destinatari.
Di recente si sta rapidamente diffondendo un nuovo protocollo aperto
per la messaggistica istantanea. Matrix abilita una connessione sicura,
decentralizzata e in tempo reale consentendo agli utenti di
comunicare tramite chat, voip e videotelefonia.
Il protocollo tenta inoltre di risolvere problemi di interoperabilità non
considerati in precedenza da XMPP e IRC.

33. Riferimenti
1) Meir Nitzan, Salman Noach, Elias Tobal, Yair Adar, Yaacov Miller, Eran Shalom,
and Shlomo Engelberg, “Calibration-Free Pulse Oximetry Based on Two
Wavelengths in the Infrared”, ncbi.nlm.nih.gov, 2014
2) “AHT10 Technical Manual”, ASAIR, 2019
3) “MAX30100 - Pulse Oximeter and Heart-Rate Sensor IC for Wearable Health”,
Maxim Integrated, 2014
4) P. Saint-Andre , “RFC6120”, Internet Engineering Task Force (IETF), 2011
5) “ESP32 Arduino: Parsing XML”, techtutorialsx, 2019
6) “How to use the Spring Boot Starter with the Azure Cosmos DB SQL API”,
docs.microsoft.com, 2022
7) “Introduction to Using Thymeleaf in Spring”, baeldung.com, 2022