DESCRIZIONE DELLE ATTIVITA’ SVOLTE:
Il presente obiettivo realizzativo è stato strutturato su 2 attività:
- A3.1 Progettazione del sistema di acquisizione e monitoraggio dell’ambiente di vita
- A3.2 Progettazione del sistema di elaborazione delle informazioni per la gestione e il controllo dell’ambiente di vita
A3.1 Progettazione del sistema di acquisizione e monitoraggio dell’ambiente di vita
Nell’ambito dell’attività A3.1 in primo luogo è stata definita l’architettura della piattaforma MET-AAL, per poi eseguire l’individuazione dei dispositivi che andranno a costituirla e le tecniche utilizzate per la gestione.
Obiettivo della piattaforma MET-ALL è rendere fruibile ai soggetti target la tecnologia domotica avanzata in modo da soddisfarne i bisogni e le mutevoli e diverse esigenze. Nel contesto di Ambient Assisted Living il “sistema domotico” deve essere inteso nell’accezione più vasta del termine, cioè come un sistema in grado di gestire in maniera totalmente o parzialmente autonoma, gli impianti e i dispositivi che si trovano all’interno di un ‘abitazione, in modo da renderla più sicura e confortevole e d’aiuto per coloro che la abitano e più efficiente dal punto di vista energetico. A tale scopo, l’architettura MET-AAL deve prevedere un sistema di controllo centrale che svolga la funzione di supervisione rispetto ad un sistema ad “intelligenze distribuite” caratterizzato da vari moduli o sottosistemi, ciascuno dei quali dispone della necessaria “intelligenza” e autonomia per svolgere il proprio specifico compito ed essere in grado di interfacciarsi con gli altri sottosistemi secondo un protocollo comune. Tale approccio di tipo misto (intelligenze distribuite con supervisione centralizzata) è garanzia di massima espandibilità del sistema per le eventuali esigenze future.
Il sistema di controllo centrale deve essere costituito da un server che possegga potenza computazionale e memoria adeguate per poter gestire i vari dispositivi in campo e i servizi. Con riferimento alla prossima figura, nella quale si rappresenta uno schema dell’architettura MET-AAL, ogni dispositivo in campo, identificato in modo univoco all’interno del sistema domotico, comunicherà con il server mediante un gateway che si occuperà di tradurre le informazioni provenienti dall’ambiente assistito in un protocollo di comunicazione unico . La scelta di un protocollo unico è volta ad assicurare che il sistema possa comunicare con diversi tipi dispositivi, rendendo omogeneo ciò che è eterogeneo e garantendo inoltre l’interazione tra componenti diverse (ad es. un singolo sensore può essere coinvolto in scenari diversi cooperando assieme ad altri sensori di diversa tipologia). Inoltre avere un protocollo unico semplifica i processi decisionali ed in generale di aggregazione dati e di business intelligence in quanto definisce un unico linguaggio e quindi un’unica semantica che rappresenta le informazioni, diminuendo drasticamente la possibilità di errori.
Schema dell’architettura della Piattaforma MET-AAL
Le decisioni che il sistema centrale intraprenderà non saranno frutto di un processo a se stante e legato ad un singolo dispositivo e attuatore (ossia Segnale di rilevazione fumo -> invia segnale all’allarme antincendio), ma comprenderà una logica complessa che potrà attivare una serie di processi e attuatori legati ad un particolare evento segnalato (nell’esempio precedente: chiusura elettrovalvola del gas, apertura tapparelle, notifica di un allarme per il soggetto target e per eventuali soggetti esterni ecc.), allo scopo di non lasciare nulla al caso per l’incolumità dell’assistito. Tale efficacia sarà garantita configurando opportunamente ogni dispositivo facente parte dell’ambiente assistito e combinando secondo specifiche logiche, l’interazione dei diversi sensori e attuatori per ogni singolo scenario in modo da svolgere i requisiti funzionali descritti nell’ambito del primo obiettivo realizzativo del progetto.
Entrando nello specifico dei dispositivi in campo, in linea con quella che è la filosofia progettuale di flessibilità e modularità del sistema, ogni modulo è stato caratterizzato da un’analisi dedicata che ha condotto a scelta di specifiche tecnologie o all’integrazione di tecnologie complementari.
Relativamente al modulo per la rilevazione della caduta vengono integrati due tecnologie una a cura del partner CNR e una del partner AMT. Il CNR propone un nodo ambientale “smart” integrante un dispositivo metrologico Time-Of-Flight (TOF) commerciale e un sistema embedded che si occuperà delle attività di reasoning opportunamente implementate (rispettose delle esigenze di privacy) necessarie a comunicare alla piattaforma MET-AAL informazioni di alto livello allorquando è presente l’evento di caduta. AMT, in collaborazione con il DEI – Politecnico di Bari, adotta un approccio con il quale viene definito un sottositema capace di identificare la caduta in base alla rilevazione della postura del soggetto (intesa come eretta, seduta, sdraiata) e la posizione che il soggetto occupa nello spazio (ossia la stanza dell’ambiente domestico). Tali binomi sono, spesso, proposti in letteratura per distinguere una caduta da un movimento volontario da una postura all’altra, o per individuare la posizione del corpo ed indirizzare i soccorsi. I principali componenti utilizzati per l’implementazione del sottosistema sono un sensore visivo 3D a luce strutturata (Microsoft Kinect), un calcolatore per l’elaborazione del flusso video (2D o 3D), un bus di scambio per flusso video e configurazioni, un uscita per connessione con l’intero sistema MET-AAL.
Per quanto concerne i componenti che andranno a realizzare l’automazione domestica, sono stati realizzati dei moduli specifici per integrare nella piattaforma sia dispositivi che lavorano su bus (Wired), che dispositivi che lavorano in radiofrequenza (Wireless). Per l’una e per l’altra tecnologia sono stati adoperati sistemi che utilizzano i protocolli standard più diffusi ad oggi: per il wired il protocollo Konnex e per il wireless il protocollo ZigBee. I dispositivi introdotti nella piattaforma attraverso tali moduli consentono di gestire le luci di un ambiente domestico, i vari automatismi e motorizzazioni (tapparelle, vasistas, porte..), permettono di mettere a sistemi parametri per la sicurezza ambientale e personale (es.: sensori di presenza, allagamento, temperatura, luminosità, gas, fumo, antintrusione..).
Al fine di consentire un’interazione con la piattaforma anche ad utenti che scarsa mobilità, è stato realizzato un modulo di riconoscimento vocale. Caratteristica fondamentale nella realizzazione di questo tipo di interazione uomo – macchina è la precisione con la quale il sistema deve operare: è opportuno cioè che la presenza di comandi riconosciuti erroneamente sia praticamente nulla (non è accettabile che la luce si spenga mentre si sta discutendo con il/la proprio/a marito/moglie).
La piattaforma MET-AAL prevede inoltre la possibilità di acquisire parametri fisiologici. In particolare è stato realizzato un modulo capace di acquisire i segnali analogici relativi a:
- Pulse Rate (PR) e Saturazione di Ossigeno nel sangue (SpO2) rilevate tramite sensore ottico applicato a dito,
- Temperatura corporea rilevata su due canali distinti (tipicamente Temperatura Esterna e Temperatura Interna);
- Pressione Sanguigna non Invasiva (NIBP – Non Invasive Blod Pressure). In particolare i dati rilevati saranno Pressione Sistolica (SYS), Pressione Diastolica (DIA) e pressione Media (MAP). I dati saranno rilevati tramite bracciale indossabile.
Con riferimento a quella che è l’architettura della piattaforma MET-AAL, il sistema prevede la possibilità di fornire servizi. In particolare è stato pensato un servizio di promemoria per fornire un aiuto nel ricordo e nella pianificazione di attività che il soggetto deve svolgere nell’arco della giornata o in un prefissato arco di tempo. È di fondamentale importanza conoscere dettagliatamente il plan giornaliero dell’utente di riferimento affinché siano riportate le informazioni relative ad attività e al momento della somministrazione dei farmaci. Tali informazioni dovranno essere presenti visivamente in un’interfaccia di facile utilizzo che le riporti in modo semplice. Per utenti che presentano difficoltà visive il sistema deve prevedere anche un messaggio sonoro con una voce preimpostata che dia l’avviso dell’attività da svolgere.
Altro servizio offerto all’interno della piattaforma è quello relativo al modulo outdoor. Tale modulo consente di mettere a sistema i dati di referti provenienti da prelievi e dosaggi effettuati su un singolo paziente in un determinato lasso di tempo. Particolare attenzione viene rivolta al coefficiente chiamato “differenza critica” che consente di calcolare in modo rigoroso la differenza minima che due risultati in tempi successivi della stessa analisi devono avere perché si possa concludere che i risultati sono tra loro significativamente diversi. Il messaggio di info si riferirà a un singolo paziente con relativo codice fiscale e potrà contenere i dati relativi ai suoi esami oppure dei grafici dei risultati nel corso del tempo.
Il modulo prevede inoltre la possibilità di coordinarsi con enti specifici, e nell’arco temporale di una giornata, potrà generare degli alerts che conterranno informazioni circa la richiesta di intervento e prestazione sanitaria.
Gli eventi e le informazioni che circolano all’interno della piattaforma MET-AAL saranno gestite ed elaborate in maniera centralizzata da uno o più servizi lato server. La comunicazione di queste informazioni da/verso il server viene implementata utilizzando un protocollo comune che, utilizzato da tutti i componenti del sistema, fornisce un opportuno livello di espressività per la gestione degli eventi affrontati negli scenari definiti.
Per ogni sensore o entità deve essere quindi prevista un’opportuna interfaccia che permetta l’adattamento tra i protocolli utilizzati dai sensori stessi e quello comune in maniera totalmente trasparente al server.
Un approccio di questo tipo permette incontrare ancora una volta quelle che sono le richieste di progetto relativamente alla modularità ed espandibilità del sistema: Modularità in quanto separa il sensore dall’architettura di rete e dal sistema di gestione delle informazioni oltre a permettere la definizione chiara dei componenti macroscopici del sistema; Espandibilità in quanto aggiungere od eliminare un sensore o entità si traduce nell’aggiornare solo la configurazione del sistema
Inoltre avere un protocollo unico semplifica i processi decisionali ed in generale di aggregazione dei dati e di business intelligence in quanto definisce un unico linguaggio e quindi unica semantica che rappresenta le informazioni, diminuendo drasticamente la possibilità di errori che, dato il contesto delicato in cui il sistema verrà adoperato, è di vitale importanza.
Il protocollo di comunicazione lavora al livello di Sessione, con una sintassi XML, appoggiandosi a TCP/IP per i messaggi end-to-end e UDP per messaggi di broadcast.
A3.2 Progettazione del sistema di elaborazione delle informazioni per la gestione e il controllo dell’ambiente di vita
Nell’ambito dell’attività A3.2 si è rivelato necessario un coordinamento con i partner per analizzare i requisiti applicativi di questa. In particolare è stata richiesta la compilazione di schede rappresentanti le informazioni necessarie, per ogni apparato, per l’invio/ricezione di comandi/status, utili a strutturare delle logiche basate su queste, e di conseguenza un protocollo tramite il quale instradarle.
La scelta di un protocollo unico è stata ponderata in base alla complessità che il sistema avrebbe raggiunto. È stata scelta la politica di concentrarsi sul cuore della logica decisionale piuttosto che su componenti di traduzione di protocolli diversi. Alla luce di questo confronto con i partner sono state analizzate le possibili architetture per un’intelligenza ambientale che gestisca casistiche eterogenee, e si è arrivati alla conclusione che doveva essere un componente di tipo reattivo e orientato alle procedure. Sono state quindi decise, in accordo con i vari partner, le possibili sequenze di azioni da eseguire in particolari scenari all’interno del sistema domotico. In mancanza di una definizione precisa per i comportamenti, il componente software viene strutturato in modo tale da poter essere scalabile, omogeneo e modulare in line con quella che la filosofia progettuale.
La progettazione è stata strutturata su Work Flow, paradigma utilizzato nei Sistemi di Buisness Process Management. Ogni Work Flow è costituito da un processo radice, che possiede varie azioni successive, rappresentate da altri processi che a loro volta hanno altre azioni, con il risultato di un albero di processi. Ad ogni processo è collegata una funzione che può essere di tipo decisionale (un controllo su alcuni parametri), procedurale (inviare messaggi ad attuatori) oppure essere collegato un altro Work Flow. Con questo genere di struttura si possono creare in fase prototipale procedure basate sullo studio degli scenari, che possono essere migliorate grazie a riscontri inattesi, in maniera semplice.
Sono stati infine definiti tutti i componenti necessari alla realizzazione del server che gestirà tutto il sistema: per la gestione dei Socket è stato usato Apache MINA, componente estremamente leggero e veloce. Data la presenza di messaggi eterogenei che viaggeranno all’interno dell’applicazione, e la necessità di un instradamento di questi fra un componente e l’altro è stato deciso di utilizzare Apache Camel, un Framework di integrazione che offre un sistema di Routing robusto e semplice che permette al programmatore di focalizzarsi sulle logiche di Routing piuttosto che sul codice di controllo che è fornito nativamente, in linea con la politica scelta precedentemente.