CareWatch è un progetto open source sviluppato per il corso di Progettazione di Sistemi a Sensore durante il corso di Laurea Magistrale in Informatica dell'Università degli Studi di Milano.

Il repository contiene il codice sorgente per la parte software del dispositivo, sviluppato in C++ utilizzando il framework ESP IDF di Espressif, e la documentazione necessaria per comprendere il funzionamento del progetto e come poterlo utilizzare e migliorare.

CareWatch nasce come dispositivo wearable avente l'obiettivo di monitorare lo stato di salute della persona che lo indossa.
E' pensato in particolare per essere utilizzato da persone anziane o con problemi di salute, in modo da poter segnalare eventuali anomalie, incidenti o situazioni di pericolo.

Le funzionalità che sono state predisposte sono:

• Monitorare il battito cardiaco e individuare anomalie collegate
• Monitorare l'ossigenazione del sangue e individuare anomalie collegate
• Determinare se l'orologio è indossato o meno
• Rilevamento delle cadute accidentali e conseguente invio di un segnale di allarme
• Dare la possibilità all'utente di inviare un segnale di allarme in caso di necessità
• Visualizzare le informazioni sullo stato di salute dell'utente tramite il display LCD
• Visualizzare le informazioni sullo stato di salute dell'utente tramite un'applicazione mobile
• Visualizzare le informazioni sullo stato del dispositivo tramite un'applicazione mobile

CareWatch è un dispositivo wearable che si presenta come un orologio da polso.
Il dispositivo è formato da molte componenti che lavorano in simultanea per garantire il corretto funzionamento e il monitoraggio dello stato di salute dell'utente.

Le componenti utilizzate nel progetto sono state:

L'ESP32-S3 Dev Board è una scheda di sviluppo basata sul microcontrollore ESP32-S3, dotata di un display LCD da 1.28 pollici e di un'interfaccia touch. Questa scheda è progettata per facilitare lo sviluppo di applicazioni IoT e wearable, grazie alle sue caratteristiche avanzate come il supporto per Wi-Fi e Bluetooth, la capacità di elaborazione ad alte prestazioni e la flessibilità nella gestione delle periferiche.
La scheda è dotata inoltre di un'interfaccia USB-C per la programmazione e l'alimentazione, di una IMU a 6 assi per il rilevamento di movimenti e orientamento, di un connettore per la ricarica della batteria e di 6 GPIO per la connessione di sensori e altri dispositivi.

Nello specifico le componenti a bordo della scheda sono:

Il sensore MAX30102 è un dispositivo di monitoraggio della salute che combina le funzionalità di rilevamento dell'elettrocardiogramma (ECG) e della saturazione di ossigeno nel sangue (SpO2). Questo sensore è progettato per essere utilizzato in dispositivi indossabili consentendo il monitoraggio continuo dei parametri vitali dell'utente. Il MAX30102 utilizza la tecnologia di fotopletismografia (PPG) alternando l'emissione di luce rossa e infrarossa per misurare la variazione del volume del sangue nei vasi sanguigni, che è correlata alla saturazione di ossigeno. Il dispositivo è dotato di un'interfaccia I2C per la comunicazione con il microcontrollore.

Il framework di sviluppo scelto è stato ESP IDF , framework ufficiale di sviluppo rilasciato da ESPRESSIF. E' stato scelto l'utilizzo di questo framework in quanto è il framework ufficiale di sviluppo per i microcontrollori ESP32 e offre una vasta gamma di funzionalità e librerie per lo sviluppo di applicazioni IoT e wearable. E' presente inoltre una buona documentazione di supporto e la comunity è molto attiva, il che facilita la risoluzione dei problemi e l'implementazione di nuove funzionalità.

Il framework è stato utilizzato con l'aggiunta di "Arduino as an ESP-IDF component" che permette di utilizzare nel framework le librerie di Arduino, rendendo più semplice l'utilizzo di alcune funzionalità e non richiedendo la scrittura di codice a basso livello per alcune operazioni già largamente utilizzate nella comunity di Arduino.

Per lo sviluppo del progetto è stato utilizzato Visual Studio Code, con l'utilizzo dell'estensione Espressif IDF che permette di semplificare la configurazione e l'utilizzo del framework ESP IDF all'interno dell'IDE.
Vengono forniti i passaggi per la configurazione dell'ambiente di sviluppo così da rendere più semplice l'utilizzo del framework e la scrittura del codice.

Passaggi:

• Scaricare VSCode e installalo
• Aprire VSCode
• Nella barra verticale di sx degli strumenti selezionare estensioni e cercare Espressif IDF. Si consiglia la versione 1.10.0.
• Installata l'estensione nella barra in alto digitare: >esp-idf: configure esp-idf extension
• Selezionare l'installazione express utilizzando come server di download EspressIF
• Una volta completato il processo di installazione scaricare il progetto dal repository

Ready to work

In caso di problemi si possono trovare maggiori informazioni a questa Guida di Installazione

Per la progettazione dell'interfaccia grafica del display LCD è stato utilizzato SquareLine Studio, un software di progettazione grafica per dispositivi embedded che permette di creare interfacce utente personalizzate in modo semplice e intuitivo.
SquareLine Studio offre un ambiente di sviluppo visuale che consente di progettare l'interfaccia utente tramite meccanismi drag-and-drop, limitando almeno per questo aspetto la necessità di scrivere codice a basso livello. Il software supporta una vasta gamma di componenti grafici, come pulsanti, slider, etichette e immagini, che possono essere facilmente personalizzati per adattarsi alle esigenze del progetto.
SquareLine Studio genera il codice C++ necessario per l'interfaccia utente, che può essere integrato nel progetto ESP IDF. Il codice generato è ottimizzato per l'esecuzione su microcontrollori e può essere facilmente adattato alle specifiche del progetto.

Il firmware del dispositivo è stato sviluppato con l'ausilio di FREE RTOS, un sistema operativo open source per microcontrollori che permette di gestire in modo efficiente le risorse del dispositivo e di eseguire più task in parallelo.
Il progetto infatti lo si può considerare come un sistema embedded in cui sono presenti più task che devono essere eseguiti in parallelo per garantire il corretto processamento dei dati e la gestione di tutte le periferiche connesse.

Le abstract components sono una serie di classi astratte che permettono di gestire dei comportamenti comuni a più componenti del progetto. Queste classi astratte definiscono un'interfaccia comune che le classi concrete devono implementare, permettendo di gestire in modo uniforme le diverse componenti del progetto.

Le abstract components principali nel progetto sono:

La classe ComponentBase è la classe che viene utilizzata da tutte le componenti fisiche del progetto. Essa infatti mette a disposizione un'interfaccia molto semplice che permette di gestire inizializzazione e reset delle componenti.

La classe AsyncTaskable permette una gestione completa delle task all'interno del progetto. Essa infatti permette un completo controllo (come la creazione, la gestione e la terminazione) di tutte le task nel progetto, centralizzandone il controllo e permettendo a chi la implementa di non doversi preoccupare di queste operazioni.

La classe DataProducer viene implementata da tutte le componenti che producono dati. Questo permette un unico modo uniforme di accesso ai dati di qualsiasi componente.

La classe EnergyManagable permette di impostare per tutte le componenti che la implementano una modalità di consumo energetico. Questo permette di gestire in modo uniforme il consumo energetico delle diverse componenti del progetto, permettendo di impostare una modalità comune di consumo energetico condivisa tra tutte le componenti che la implementano.

La classe UpdatableScreen viene utilizzata da tutte le componenti che rappresentano una schermata del dispositivo e che possono essere dunque aggiornate.

All'interno del progetto sono state definite una serie di componenti principali che vengono gestiti in maniera centralizzata dal MaincomponentManager. Ogni componente è formata da una o più Abstract Components dai quali ereditano alcune funzionalità comuni.
Tutte le singole componenti principali sono sempre formate da una componente Manager che ne gestisce i principali comportamenti

All'interno della classe MainComponentManager sono definiti tutti i componenti del progetto divisi in base all'implementazione di una delle Abstract Components quali EnergyManagable, ComponentBase, DataProducer e AsyncTaskable.
Da questa classe è possibile ottenere le varie istanze dei componenti e gestire in maniera centralizzata l'inizializzazione, il reset, il setting della modalità energetica e la gestione di tutte le task.
Ogni qual volta si deve interagire con una componente del progetto lo si fa a partire da questa classe.

Questa componente è responsabile della gestione e del controllo della batteria del dispositivo. Al suo interno è stato definito un controller che consente di determinare il livello di carica della batteria, stimare il tempo rimanente alla ricarica completa e verificare se la batteria è attualmente in carica.

Tutte queste operazioni vengono eseguite interpretando i dati letti dal convertitore analogico-digitale (ADC) del dispositivo. Il valore numerico restituito dall’ADC.

La percentuale di batteria viene calcolata in modo differente se il dispositivo è in carica o meno.

• Batteria NON in carica:
  Se la batteria non è in carica la percentuale viene calcolata usando una funzione logistica sigmoide. La formula utilizzata è: $$ \text{percentage} = \frac{100.0}{1.0 + e^{k \cdot (x - x0)}} $$ Dove:

  • $x$ è il valore ADC letto dal sensore (adc_value).
  • $x0$ è il punto medio (ADC value al 50%), fissato a $1215.0$
  • $k$ è un coefficiente che controlla la pendenza della curva, fissato a $-0.03$ (negativo perché il valore ADC diminuisce al diminuire della carica della batteria). Questa funzione permette di modellare in modo più realistico il comportamento di scarica della batteria, dove la relazione tra voltaggio (e quindi valore ADC) e percentuale di carica non è lineare, ma tende a variare più rapidamente agli estremi (batteria quasi scarica o quasi carica). Il risultato viene arrotondato all'intero più vicino e vincolato tra 0 e 100. Per evitare fluttuazioni rapide, la percentuale viene aggiornata solo se differisce di più di $2%$ rispetto all'ultima percentuale registrata.

• Batteria in carica:
  Se la batteria è in carica, la percentuale viene calcolata tramite una mappatura lineare del valore ADC in un intervallo specifico. Il valore ADC viene mappato dall'intervallo $[1850, 1930]$ all'intervallo $[0, 100]$. $$ \text{percentage} = \text{map}(\text{adcValue}, 1850, 1930, 0, 100) $$ Il valore risultante è quindi vincolato tra $0$ e $100$. Durante la carica, la percentuale viene aggiornata solo se il nuovo valore è maggiore dell'ultima percentuale registrata, per riflettere un aumento progressivo.

Il tempo stimato per la ricarica viene calcolato solo quando il dispositivo è in carica.

• Se il valore ADC raggiunge o supera $1930$, la batteria è considerata completamente carica e il tempo stimato rimanente è $0$ minuti.
• Se il valore ADC è inferiore o uguale a $1800$, viene stimato un tempo di $30$ minuti rimanenti.
• Per i valori ADC compresi tra $1800$ e $1930$, il tempo rimanente viene calcolato utilizzando una curva di decadimento esponenziale. Viene prima calcolato il progresso della carica (chargingProgress) come una percentuale lineare del valore ADC all'interno dell'intervallo $[1800, 1930]$. $$ \text{chargingProgress} = \frac{\text{adcValue} - 1800}{1930 - 1800} $$ Successivamente, viene calcolata una remainingRatio ($1.0 - \text{chargingProgress}$) e il tempo in minuti viene stimato con la formula: $$ \text{minutes} = 30.0 \cdot \text{remainingRatio} \cdot \text{remainingRatio} $$ Questa formula modella il comportamento reale delle batterie, dove la velocità di ricarica tende a diminuire significativamente man mano che la batteria si avvicina alla carica completa. Il risultato viene arrotondato all'intero più vicino. Per garantire stabilità, il tempo viene aggiornato solo se la differenza rispetto all'ultimo tempo registrato è maggiore di $2$ minuti, o se il nuovo tempo è inferiore o uguale al precedente (per riflettere un avanzamento della carica).

Per determinare se la batteria è in carica, viene semplicemente letto il valore ADC dal pin della batteria. Se questo valore è maggiore di $1500$, la batteria è considerata in carica. Questo valore soglia è stato scelto per distinguere lo stato di connessione a una fonte di alimentazione rispetto al normale utilizzo a batteria.

Il DisplayManager si occupa unicamente di gestire la luminosità del display LCD. L'aggiornamento del contenuto e la visualizzazione delle schermate sono gestite dai componenti di UI.

L'iMUManager è responsabile della gestione del sensore IMU (Inertial Measurement Unit) presente sul dispositivo. Questo sensore fornisce dati ricevuti da un accelerometro e un giroscopio, che vengono utilizzati per rilevare la caduta dell'utente e per rilevare il gesto di osservazione del display.

Oltre ad accellerometro e giroscopio, il sensore incorpora inoltre un buffer FIFO per memorizzare i dati letti, così da non dover leggere i dati in tempo reale, ma poterli leggere in maniera asincrona.
Il buffer è stato configurato per poter memorizzare 16 campioni alla volta e una volta rimepito genera un interrupt. Quest'ultimo permette ad una task apposita di leggere i dati e di trasferirli in un secondo buffer circolare di memoria più grande da 160 campioni da cui dunque poter fare le elaborazioni necessarie.

Una volta riempito il buffer di memoria interviene l'IMUDataAnalyzer, che si occupa per i dati presenti nel buffer di definire la presenza di una caduta o di un gesto di osservazione del display.

Il gesto di osservazione del display viene rilevato analizzando unicamente il valore dell'asse x del giroscopio. Quando infatti l'utente osserva il display, il dispositivo viene inclinato verso l'alto e il valore dell'asse x del giroscopio ha un picco che viene utilizzato per rilevare il gesto.

Il rilevamento della caduta viene effettuato secondo quanto riportato all'interno del paper "A_wrist_-worn_fall_detection_system_using_accelerometers_and_gyroscopes".
L'approccio consiste in 4 passaggi consecutivi:

1. Rilevamento picco giroscopio: I dati del giroscopio (assi Y e Z) vengono utilizzati per escludere la maggior parte dei movimenti che non sono cadute, come i movimenti del braccio. Un valore GS superiore a 350 °/s è un primo indicatore di un potenziale evento di caduta.
2. Rilevamento picco accelerometro: Vengono esaminati gli ultimi 4 SVM (Signal Vector Magnitude) derivanti dall'accellerometro. Se uno di questi valori supera la soglia di 6G, viene considerato un potenziale evento di caduta.
3. Deviazione standard SVM: Per distinguere una caduta da un movimento del braccio, viene calcolata la deviazione standard dei valori SVM prima e dopo l'impatto. Una deviazione standard superiore a 1.5G aiuta a confermare una caduta.
4. Momento fermo: Infine, viene calcolato l'SMA per determinare se il corpo è in uno stato di movimento o stazionario. Un valore SMA inferiore a 200G nei successivi due secondi dopo un potenziale impatto indica uno stato di inattività, confermando una caduta.

Il MQTTManager si occupa della gestione della connessione al broker MQTT e della pubblicazione dei dati raccolti dalle varie componenti del dispositivo.
Il dispositivo si connette a un broker MQTT remoto e ciclicamente lo aggiorna con gli ultimi dati raccolti dai vari sensori a bordo.
Richiede la connessione del dispositivo a una rete Wi-Fi.

Il PulsOxManager si occupa della gestione del battito cardiaco e della saturazione di ossigeno nel sangue. Utilizza il sensore MAX30102 per raccogliere i dati e calcolare i valori di frequenza cardiaca e SpO2.

Il device ha a disposizione un buffer di memoria ma per il quale non è stato collegato il sensore di INT a causa di mancanza di PIN disponibili in fase di progettazione. Il sensore viene dunque interrogato in polling per leggere i dati.

Il sensore è stato configurato per lavorare ad intervalli di funzionamento e spegnimento per evitare di consumare troppa energia. Quando è in funzione il sensore imposta il led ad alta intensità per poter leggere i dati dal polso e in maniera regolare scarica questi dati in un buffer circolare di memoria.

Quando il buffer di memoria si riempie i dati grezzi (specificamente i buffer dei canali rosso e infrarosso)vengono analizzati per verificare l'affidabilità delle misurazioni di SpO2 (saturazione di ossigeno nel sangue) e della frequenza cardiaca, con l'obiettivo di archiviare e utilizzare esclusivamente i dati che soddisfano criteri di validità.

Dopo la verifica del contatto con la pelle misurando il ritorno della luce infrarossa i dati vengono validati verificando che rientrino all'interno di intervalli fisiologici accettabili (SpO2 non inferiore a 60, frequenza cardiaca tra 40 e 220). Inoltre si valuta la coerenza dei nuovi dati con lo storico recente, scartando le misurazioni che presentano variazioni eccessive rispetto all'ultimo dato valido (più di 40 per la frequenza cardiaca o più di 8 per l'SpO2), a patto che ci siano sufficienti dati storici per consentire l'avvio del sistema. Solo i dati che superano tutti questi controlli vengono considerati validi.

Lo SharedI2CManager è responsabile della gestione centralizzata del bus I2C condiviso tra diversi dispositivi nel sistema. Questa componente implementa un pattern singleton per garantire che il bus I2C venga inizializzato una sola volta e che sia accessibile da tutte le componenti che ne hanno bisogno.

Il manager configura il bus I2C sui pin SDA (6) e SCL (7) e opera a una velocità di 400 kHz per garantire una comunicazione efficiente. Fornisce inoltre meccanismi di protezione tramite mutex per prevenire accessi concorrenti al bus, garantendo operazioni I2C thread-safe durante le comunicazioni con dispositivi come il sensore QMI8658 e il controller touch CST816S.

Attraverso questa centralizzazione, il sistema può gestire in modo più efficiente le risorse hardware limitate, evitando conflitti di comunicazione e garantendo l'integrità dei dati trasmessi sul bus I2C condiviso.

Il TouchManager è responsabile della gestione del controller touch CST816S integrato nel display LCD del dispositivo. Questa componente si occupa di rilevare e interpretare gli eventi touch sull'interfaccia utente, convertendo i segnali del sensore capacitivo in dati utilizzabili dall'applicazione.

Il manager inizializza la comunicazione I2C con il controller CST816S e gestisce la lettura degli eventi touch, inclusi tocchi singoli, gesti di swipe (su, giù, sinistra, destra), doppi tocchi e pressioni prolungate. Supporta inoltre la configurazione dell'angolo di rotazione per adattare le coordinate touch all'orientamento del display.

Attraverso la classe TouchProducedData, il TouchManager fornisce un'interfaccia uniforme per accedere ai dati touch, permettendo all'UIManager di gestire l'interazione utente e la navigazione tra le diverse schermate del dispositivo. Il riconoscimento dei gesti viene implementato dal controller CST816SController che elabora i dati raw del sensore per identificare i pattern di movimento specifici.

Il TimeManager è responsabile della sincronizzazione automatica dell'orario del dispositivo tramite protocollo NTP (Network Time Protocol). Questa componente garantisce che l'orologio interno del CareWatch rimanga sempre accurato e sincronizzato con il tempo universale.

Il manager implementa un task asincrono che si attiva ogni 5 minuti quando il dispositivo è connesso a una rete Wi-Fi. Utilizza un client NTP configurato con un offset di fuso orario di +2 ore per sincronizzare l'RTC interno dell'ESP32-S3 con i server di tempo remoti. In caso di assenza di connessione Wi-Fi, il sistema attende 10 secondi prima di ritentare la sincronizzazione.

La sincronizzazione temporale è fondamentale per il corretto funzionamento delle funzionalità del dispositivo, permettendo la visualizzazione accurata di data e ora sulle schermate principali tramite il MainScreenUpdater, e garantendo timestamp precisi per la raccolta e trasmissione dei dati dei sensori verso il sistema MQTT di monitoraggio remoto.

L'UIManager è responsabile della gestione completa dell'interfaccia utente grafica del dispositivo CareWatch, fungendo da ponte tra il framework LVGL e l'hardware del display touchscreen. Questa componente coordina tutte le operazioni relative alla visualizzazione e all'interazione utente attraverso il display LCD.

Il manager inizializza e configura la libreria LVGL per la gestione grafica, registra i driver per il display GC9A01A e il controller touch CST816S. Attraverso la classe UIDataUpdater, coordina l'aggiornamento ciclico dei dati su tutte le schermate del dispositivo (principale, ricarica, eventi anomali, allarmi e informazioni). Molte funzionalità di interazione e animazione sono gestite direttamente dal framework LVGL attraverso le configurazioni impostate nel design dell'interfaccia utente.


L'UIManager interpreta i gesti touch dell'utente, implementando funzionalità critiche come l'attivazione del segnale SOS tramite pressione prolungata e la navigazione tra le diverse schermate. Gestisce inoltre la logica di cambio automatico delle schermate in base allo stato del dispositivo e dei suoi sensori.

Il WifiManager è responsabile della gestione completa della connettività Wi-Fi del dispositivo CareWatch, garantendo una connessione stabile e affidabile alla rete wireless per l'accesso a servizi remoti. Questa componente coordina tutte le operazioni di rete necessarie per il funzionamento del sistema di monitoraggio remoto.

Il manager inizializza la connessione Wi-Fi tramite il WiFiController utilizzando le credenziali di rete configurate, gestisce automaticamente la riconnessione in caso di perdita del segnale e monitora continuamente lo stato della connessione attraverso un task asincrono dedicato.

Permette ad altri componenti come il MQTTManager e il TimeManager di accedere ai servizi di rete per la trasmissione dati e la sincronizzazione temporale.

L'interfaccia utente di CareWatch è stata progettata con l'obiettivo di fornire un'esperienza semplice, intuitiva e accessibile, particolarmente adatta agli utenti anziani o con problemi di salute. Il design minimalista e le informazioni chiare permettono una facile lettura e comprensione dei dati vitali e dello stato del dispositivo.

L'UI è stata sviluppata utilizzando SquareLine Studio e si basa sul framework grafico LVGL, ottimizzato per dispositivi embedded con risorse limitate. Il design sfrutta appieno il display LCD circolare da 1.28 pollici (240x240 pixel) della scheda ESP32-S3, con un'interfaccia touch capacitiva che supporta gesti di navigazione intuitivi.

Il sistema è composto da sei schermate principali, ognuna con una funzione specifica nel monitoraggio della salute e nella gestione del dispositivo.

La schermata principale rappresenta il cuore dell'interfaccia utente, mostrando tutte le informazioni essenziali in un'unica vista. Presenta:

• Frequenza Cardiaca: Visualizza il battito cardiaco attuale in BPM (battiti per minuto).
• Saturazione di Ossigeno (SpO2): Mostra la percentuale di ossigeno nel sangue.
• Stato della Batteria: Indica il livello di carica della batteria in percentuale.
• Data e Ora: Visualizza la data e l'ora correnti, sincronizzate tramite NTP.

Tramite la pressione prolungata del display, l'utente può passare alla schermata SOS, che consente di inviare un segnale di allarme in caso di necessità.

Facendo swipe verso l'alto o verso il basso è possibile aumentare o diminuire la luminosità del display.

La schermata si attiva automaticamente quando il dispositivo viene indossato e si spegne dopo un periodo di inattività.

Questa schermata viene visualizzata automaticamente quando il dispositivo è collegato alla ricarica. Mostra:

• Livello di Carica della Batteria: Indica il livello attuale di carica della batteria in percentuale con un'icona di ricarica.
• Tempo Rimanente per la Carica Completa: Stima il tempo necessario per completare la ricarica, espresso in minuti.

La schermata SOS viene attivata tramite pressione prolungata sulla schermata principale.
L'utente premendo nuovamente lo schermo può inviare un segnale di allarme.
Scorrendo verso sinistra ritorna alla schermata principale.

Questa schermata viene visualizzata automaticamente quando il sistema rileva una potenziale caduta dell'utente o un evento di allarme. Presenta:

• Icona di Allarme: Un'icona chiara che indica il tipo di evento rilevato.
• Messaggio di Allerta: Indica cosa è stato rilevato.
• Timer di Conferma: Un conto alla rovescia che permette all'utente di annullare l'allarme se si tratta di un falso positivo.

La schermata offre all'utente la possibilità di interrompere l'invio automatico dell'allarme se la caduta rilevata non rappresenta una reale emergenza.

Questa schermata viene attivata quando il sistema rileva anomalie nei parametri vitali monitorati. Mostra:

• Icona di Anomalia: Identifica visivamente il tipo di anomalia rilevata (cardiaca o di ossigenazione).
• Parametri Anomali: Visualizza i valori dei parametri vitali che hanno scatenato l'allarme.
• Messaggio Informativo: Spiega la natura dell'anomalia rilevata.

La schermata informazioni fornisce dettagli informativi relativamente alla connessione, allo stato dell'sos o al corrento posizionamento del device. Include:

• Icona di Stato: Indica il tipo di informazione visualizzata.
• Messaggio Informativo: Fornisce dettagli sullo stato attuale del dispositivo, come la connessione Wi-Fi o l'attivazione dell'SOS.

L'integrazione di algoritmi avanzati per il monitoraggio del sonno permetterà di fornire all'utente informazioni più complete e dettagliate sul proprio stato di salute generale. Questa funzionalità includerà l'analisi delle fasi del sonno, la qualità del riposo e correlazioni con altri parametri vitali, offrendo una visione olistica del benessere dell'utente.

Il sistema di riconoscimento dei gesti del dispositivo indossabile necessita di un perfezionamento significativo per adattarsi alle attività quotidiane dell'utente. L'obiettivo è ridurre drasticamente le attivazioni accidentali del sistema SOS e i falsi positivi nella rilevazione delle cadute. L'implementazione di reti neurali specializzate permetterà di creare modelli predittivi più accurati, in grado di distinguere tra movimenti intenzionali e situazioni di emergenza reale, considerando il contesto e i pattern comportamentali individuali.

L'ottimizzazione del consumo energetico rappresenta una priorità fondamentale per garantire una maggiore autonomia del dispositivo. Questo obiettivo sarà raggiunto attraverso l'implementazione di algoritmi di gestione intelligente dell'energia, l'ottimizzazione dei processi in background e l'adozione di tecniche di sleep mode dinamico basate sull'utilizzo effettivo del dispositivo.

Il sistema di gestione della memoria richiede un'ottimizzazione approfondita per garantire prestazioni fluide e stabili nel tempo. Saranno implementati algoritmi di garbage collection più efficienti, tecniche di memory pooling e strategie di caching intelligente per ridurre la latenza e migliorare la responsività del sistema.

Gli algoritmi per il monitoraggio dello stato della batteria necessitano di un aggiornamento per fornire stime più precise della durata residua e dello stato di salute della batteria stessa. L'implementazione di modelli predittivi avanzati permetterà di ottimizzare i cicli di ricarica e prolungare la vita utile della batteria.

L'aggiunta di un motore eccentrico al dispositivo permetterà di implementare feedback tattili più sofisticati, migliorando l'esperienza utente attraverso notifiche discrete e personalizzabili. Questa funzionalità sarà particolarmente utile per gli utenti con difficoltà uditive o in situazioni dove le notifiche sonore non sono appropriate.

L'integrazione di un modulo GPS combinato con connettività SIM rappresenta un upgrade fondamentale per le funzionalità di sicurezza e localizzazione. Questo modulo permetterà il tracciamento preciso della posizione, la comunicazione diretta con i servizi di emergenza e la possibilità di funzionare indipendentemente dallo smartphone dell'utente, garantendo maggiore autonomia e affidabilità del sistema di sicurezza.