Etapa 3 (Ianuarie – Mai 2022)
PL3 – Pregatire tranziție și continuare
Obiective:
(1) Prototip final componenta Gateway
Componenta Gateway se identifică la nivel logic printr-un set de programe server și module, fiecare fiind responsabil de un task bine stabilit (bridge, server, baza de date, interfața utilizator, client). La nivel hardware Gateway se identifică printr-un miniPC conectat prin cablu sau Wi-Fi la rețeaua ethernet a locuinței. Tot la acest miniPC sunt conectate și controllerele pentru subrețețele de comunicație Z-Wave, ZigBee, Bluetooth.
(2) Prototip final componenta Sistem Expert
Din punct de vedere arhitectural, Sistemul Expert se situează la nivelul Serverului Cloud și conține următoarele componente principale:
- Modulul Sistem de telemonitorizare
- Sub-Modulul de agregare date
- Sub-Modulul de management date și proiecte
- Sub-Modulul de configurare scenarii de monitorizare și notificări
- Asistentul virtual
- Back-end Rapoarte
Sistemul Expert comunică prin intermediul componentei de serviciu REST a serverului Cloud, cu celelalte module ale aplicației SMARTCARE.
(3) Prototip final componenta DeveloperUI
Modulul DeveloperUI este implementat folosind Python ca back-end și HACS (Home Asssistant Community Store) pentru interfața grafică pentru a facilita descoperirea, instalarea, înnoirea, ștergerea dispozitivelor de monitorizare asociate beneficiarilor sistemului SMARTCARE. Acest modul ia forma unei interfețe utilizator și are rolul de a ușura proiectarea de soluții pentru aplicații specifice de asistență la domiciliu. Modulul a fost instalat pe plăci de bază Raspberry Pi 4 pentru sistemul pilot Info World, într-o locuință și într-un laborator de la Universitatea Tehnică Gheorghe Asachi Iași (Figura 13).
Figura 13 – Senzorii prototipului SMARTCARE la sediul Info World (stânga), într-o casă (centru) și într-un laborator (dreapta)
(4) Integrarea componentelor hardware și software și testarea tehnică a sistemului SMARTCARE
Testarea tehnică a integrării dintre hardware și componentele bridge au presupus testarea robusteții componentelor bridge în eventualitatea defectării hardware-ului conectat și a avut două etape:
- testarea cazurilor limită la nivelul fluxurilor de date – au fost create componente software dedicate, driverele au fost trecute într-un mod de emulare hardware și au fost injectate date eronate către componentele bridge. Validarea valorilor s-a realizat pe baza elementului de configurare generat/disponibil la pornirea bridge-ului ce conține limitele/seturile de valori valide pentru fiecare flux de date generat de hardware;
- testarea comportamentului în cazul întreruperii fluxului de date de la hardware – au fost deconectate pe rând componentele subsistemelor hardware (inclusiv controller-ele principale pentru rețelele Z-Wave și ZigBee) și au fost generate cereri de interacțiune de la nivelul componentei gateway. În cazul componentelor bridge bazate pe o interfață web s-au obținut valori stocate în bazele de date asociate sistemelor hardware, iar în cazul celorlalte componente hardware au fost tratate excepții cauzate de un time-out de citire/scriere.
(5) Definirea scenariilor de evaluare și a indicatorilor cheie de performanță
Testarea componentei Gateway s-a realizat prin tehnica testării orientate pe date:
- comunicația între fiecare dispozitiv de monitorizare și gateway;
- comunicația între gateway și sistemul expert;
- reguli de notificare (conform standardelor WHO, EU);
- studii de caz pentru pacienți hipertensivi, diabetici, cardiaci, COVID, obez, Alzheimer.
(6) Evaluarea platformei SMARTCARE prin aplicații prototip
Trei becuri Philips Hue și alte trei becuri Zipato 2 au fost folosite pentru a fi comparate cu becul inteligent realizat în proiectul anterior, i-Light (figura 14). Partea stângă prezintă un dispozitiv care a fost creat ca parte a proiectului de cercetare i-Light și include senzori pentru măsurarea temperaturii, umidității și a nivelurilor de compuși volatili. În centru este un bec inteligent disponibil în comerț, Philips Hue, în timp ce în dreapta este un alt bec inteligent din comerț, Zipato Bulb 2.
Figura 14 – Dispozitiv de iluminat inteligent dezvoltat ca parte a proiectului i-Light (stânga), becul Philips Hue (centru) și becul Zipato 2 (dreapta)
Raspberry Pi 4 Model B a fost folosit pentru a colecta valorile indicatorului de putere a semnalului (RSSI) primit de la cele trei corpuri de iluminat i-Light, trei Philips Hue și alte trei becuri Zipato, instalate acolo unde sunt marcate cu cercuri galbene în figura 15. O conexiune Wi-Fi stabilă a fost folosită între corpurile de iluminat și serverul de sistem. Persoana monitorizată avea un smartphone cu Bluetooth activat și a fost observată de dispozitivele Raspberry Pi ale sistemului instalat în ceea ce privește locația. La dispozitivele Raspberry Pi a fost atașată o placă RaZberry, astfel încât să poată comunica cu becurile Zipato care folosesc protocolul Z-Wave Plus. Sistemul s-a dovedit a fi funcțional după ce a fost testat cu cele trei tipuri de corpuri de iluminat.
Figura 15 – Planul apartamentului pentru testele care au inclus corpuri de iluminat i-Light, becuri Philips Hue și Zipato pentru validarea sistemului tehnic. Săgețile arată mișcările utilizatorului (a) de la pat la dulap (albastru); (b), de la dulap la pat (verde); (c) de la pat la birou (magenta)
(7) Planul tehnic de continuare a proiectului
În a treia etapa de lucru a proiectului SMARTCARE au fost efectuate numeroase experimente cu echipamente hardware, cât și a fost implicată testarea soluției software.
În primul rând, a fost realizată o analiză detaliată a componentelor finale Gateway, Sistem Expert și Developer UI. În al doilea rând, s-a realizat integrarea componentelor hardware și software și testarea tehnică a sistemului SMARTCARE. Au fost definite scenariilor de evaluare și a indicatorilor cheie de performanță, alături de evaluarea platformei SMARTCARE prin aplicații prototip. Consorțiul a pregătit tranziția și continuarea proiectului SMARTCARE spre a fi comercializat.
Figura 16 – Sinergia elementelor cheie pentru planul tehnic de continuare al proiectului SMARTCARE
Etapa 2 (Ianuarie – Decembrie 2021)
PL2 – Dezvoltarea, integrarea și evaluarea prototipului final
Obiective:
(1) Prototip final componenta Gateway
În cadrul etapei 2 am studiat din punct de vedere hardware datele despre pacient și ambientul în care se află. Acestea sunt preluate de o rețea heterogenă de senzori și transmise către Gateway pentru preprocesare, analiză de bază și stocare în cloud (sistem expert). O cerință expres formulată în documentul de definire a cerințelor a fost ca sistemul să fie independent de medii și protocoale de comunicație. Astfel rețeaua conține senzori ce comunică prin fir sau radio diverse protocoale de comunicație: ZigBee, Z-Wave, BLE, Wi-Fi. Gateway-ul abstractizează mărimea fizică sau evenimentul monitorizat, decuplându-l de dispozitivul care îl furnizează. Arhitectura propusă permite ca la runtime să se poată adăuga, elimina, schimba un senzor din rețea.
Din punct de vedere logic există trei rețele de senzori: rețea de senzori pentru monitorizarea parametrilor vitali ai persoanei monitorizate, rețea de senzori pentru monitorizarea activității fizice și rețea de senzori/actuatori pentru monitorizarea mediului ambiental (domotică). Așa cum s-a precizat, separarea nu este realizată la nivel fizic ci la nivel logic, la consumatorul de informații furnizate de senzori, funcție de identificatorul acestuia.
Figura 5 – Arhitectură hardware subsistem pentru automatizare mediu ambiental – domotică
Figura 6 – Arhitectură hardware subsistem pentru monitorizare parametri vitali
Figura 7 – Arhitectură hardware subsistem pentru determinarea activității fizice
(2) Prototip final componenta Sistem Expert
Componentele Sistemului Expert sunt astfel definite, încât să permită vizualizarea, configurarea, gestiunea, agregarea și raportarea datelor și a modului în care utilizatorii finali le vor putea vizualiza la rândul lor, în interfețele grafice aferente.
Sistemul Expert, prin intermediul unui serviciu REST, comunică cu celelalte module ale sistemului (Gateway/DeveloperUI) și prin intermediul componentelor sale, el agregă, gestionează, controlează și transmite datele către baza de date și interfețele grafice. Astfel, cu ajutorul Sistemului Expert, sunt gestionate regulile de logică și funcționare ale aplicației SMARTCARE.
Figura 8 – Vedere de ansamblu asupra interacțiunii Sistemului Expert cu celelalte componente SmartCare
Figura 9 – Tehnologii folosite pentru Sistemul Expert
(3) Prototip final componenta DeveloperUI
Interfața componentei DeveloperUI este dedicată utilizatorilor cu rol de administrator integrator sau proiectant, ce oferă următoarele funcționalități: gestiunea utilizatorilor, configurarea drepturilor de utilizator în funcție de rol; gestiunea echipamentelor și instrumentelor pentru configurarea mai multor aspecte legate de localizarea interioară și a scenariilor de monitorizare și alertare; gestiunea proiectelor; stabilirea regulilor business ce țin de proiecte; vizualizarea diferitelor tipuri de rapoarte.
Figura 10 – Testarea echipamentelor din interfața grafică pentru cazul în care se detectează mișcare, cât și deschiderea ușii
(4) Raport de validare tehnică a prototipului final SMARTCARE
Scopul principal este de a asigura că echipamentele hardware dezvoltate sunt complet interoperabile cu platforma software, că eventualele cazuri limită la nivel hardware cât și software sunt acoperite la nivel funcțional și că nu cauzează erori generalizate în cadrul sistemului.
Figura 11 – Interfața grafică locală a Gateway – starea sistemului, controale manuale, bridge-urile/device-urile/resursele conectate
(5) Plan de testare și evaluare
În etapa actuală am realizat planificarea testării sistemului SMARTCARE. Testarea funcțională este o testare în principal cutie neagră / black-box testing care verifică funcționalitatea unui sistem. Definirea cazurilor de testare pentru testarea funcțională se face pe baza specificației. Functionalitatea unui sistem este testată prin stimularea lui cu diverse intrări, urmărind corectitudinea răspunsului sistemului la aceste intrări. Ori de câte ori este nevoie, va fi folosit și un test cu casetă gri / grey-box testing. Acest tip de testare este o combinație între testarea cutie neagră bazată pe intrări și verificarea ieșirii și testarea cutie albă bazată pe cod. Pentru testarea funcțională a componentelor SMARTCARE, vor fi urmate următoarele două direcții principale: defalcarea funcționalității, izolarea acesteia și testarea individuală (testarea unităților funcționale); testarea generală a sistemului (testarea funcțională a sistemului).
(6) Raport de testare și evaluare a prototipului SMARTCARE
Testarea și evaluarea parțială a inclus acuratețea localizării în interior atunci când se utilizează becuri inteligente disponibile în comerț, respectiv Philips Hue, împreună cu monitorizarea evoluției ritmului cardiac pe baza unei brățări inteligente, FitBit Versa 2. Am folosit becuri inteligente disponibile în comerț pentru a înlocui elementele hardware personalizate dezvoltate anterior în cadrul proiectului i-Light.
Figura 12 – Planul apartamentului folosit pentru experiment. Săgețile indică mișcarea utilizatorului (a) de la pat la dulap (albastru); (b) din dulap spre pat (verde) și (c) din pat spre birou (magenta); ritmul cardiac al utilizatorului este corelat cu mișcarea, cu mostre prelevate afișate de-a lungul căii de mișcare
(7) Website-ul proiectului actualizat
Etapa 1 (Iunie – Decembrie 2020)
PL1 – Proiectarea sistemului SMARTCARE și dezvoltarea prototipului inițial
Obiective:
(1) Cerințe sistem
În cadrul etapei 1 am studiat domeniul sistemelor de asistență pentru autonomie la domiciliu, identificând actorii sistemului, elementele hardware necesare pentru server și utilizatorii finali și cazurile de utilizare. În plus, s-a determinat cerințele funcționale privind activitățile administrative, de gestiune proiecte, monitorizare a pacientului de către sistem, utilizare a asistentului virtual de către pacienți și a rapoartelor generate de sistem. S-au stabilit activitățile pentru notificările primite de aparținător și medic, alături de operațiile efectuate de medic. Pentru fiecare caz de utilizare determinate cerințele non-funcționale, respectiv performanța, interfața, securitatea și siguranța.
(2) Document de proiectare arhitecturală
Proiectarea arhitecturala a sistemului SMARTCARE se bazează pe descrierea obiectivelor proiectării privind utilizatorul final, performanța, fiabilitatea și modelul de dezvoltare. Obiectivele vor fi luate în considerare în implementarea detaliată a arhitecturii software. De asemenea a fost definită o schema arhitecturală ce va sta la baza implementării sistemului hardware-software. Au fost stabilite componentele hardware pentru server, servicii Cloud și utilizatorii finali, alături de componentele software pentru gestiunea utilizatorilor, serviciile REST, agregarea datelor, analiza inteligentă a datelor, configurarea scenariilor de monitorizare și alertare personalizate. Au fost detaliate modurile de generare a rapoartelor de monitorizare, a analizei datelor ambientale și a alertelor în timp real. S-au identificat responsabilitățile, modul de funcționare, tehnologiile utilizate și modulele componentei Gateway.
Figura 1 – Diagrama de context a sistemului SMARTCARE
(3) Prototip inițial componenta Gateway
Componenta Gateway a fost analizată din punct de vedere arhitectural, fiind identificate bridge-uri pentru modurile de interfațare, structura generală și a datelor, interacțiunea core. La acestea, au fost incluse submodulele pentru protocoalele de comunicație Z-Wave și ModBus, parametrii vitali, video și client MQTT. Alte bridge-uri, respectiv Core, West, East și North bridge, vor fi responsabile de realizarea unei modularizări eficiente a aplicației pentru a oferi o flexibilitate ridicată în vederea extinderii ulterioare a sistemului. Rolurile acestora sunt de a facilita configurarea, controlul datelor și excepțiilor, modelarea datelor și particularizarea clientului MQTT. Bazele de cunoștințe au fost detaliate pentru activitățile monitorizate video pentru pacienții cu diabet. În procesul de dezvoltare și testare al modulului Z-Wave a fost folosit un controler Z-Wave.Me UZB Smart Controller (shorturl.at/aqyFY) și un dimmer cu un canal pentru iluminat (Everspring AD146 – shorturl.at/bnEQX). În procesul de dezvoltare și testare al modulului ModBus a fost folosit un adaptor USB-serial pentru interfațarea unei magistrale seriale RS485 la care au fost conectate două dispozitive slave (modul cu 24 de canale de intrare, modul cu 24 de canale de ieșire). În ceea ce privește unitatea de achiziție a imaginilor, s-au testat senzorii video apăruți recent pe piață care oferă informații color și de adancime. În urma testelor efectuate, camerele candidat selectate pentru sistemului SmartCare sunt ZED 2 și ZED mini. Dezvoltarea în acest moment nu este condiționată de alegerea unuia dintre cei doi senzori de imagine.
Detecția și clasificarea activităților pacientului monitorizat se realizează în două etape:
- în primă instanță se efectuează o detecție a persoanei și a obiectelor de interes implicate în aceste activități (podea, scări, pizza, pahar). Detecția obiectelor se poate realiza utilizând modele concepute atât pentru aplicații în timp real, cât și modele mai complexe a căror viteză de procesare este mai scăzută. S-au testat: YOLO v4 – 33 fps și Faster RCNN – 2 fps pe o arhitectură Nvidia Titan RTX.
- utilizând rezultatul anterior, dar și alte caracteristici precum configurația spațială, se produc triplete de forma subiect-predicat-obiect cu ajutorul unui model pentru detecția interacțiunii om-obiect. În acest sens s-a testat arhitectura iCAN și se au în vedere teste utilizând TNI și HAKE. Rezultatul poate fi interpretat în vederea identificării activităților monitorizate: servitul mesei – persoana stă la masă, persoana ține o furculiță, persoana mănâncă pizza.
Figura 2 – Arhitectura Gateway
(4) Prototip inițial componenta Sistem Expert
În etapei 1 s-au stabilit funcționalitățile componentei Sistem Expert, arhitectura, sub-modulele privind agregarea datelor, analiza inteligentă a datelor, scenariile de monitorizare și alertare. S-a prezentat generarea rapoartelor pentru activitatea utilizatorilor, localizarea acestora, parametrii biofizici și dispozitive medicale, condiții de mediu și alerte. Testarea componentei Sistem Expert a fost făcută prin dezvoltarea unei aplicații folosind tehnologiile Node.js, Express.js, Angular.js și Apache CouchDB.
Figura 3 – Comunicarea dintre Sistemul Expert/ Gateway/ Dispozitive
(5) Prototip inițial componenta DeveloperUI
În cadrul acestei etape s-au identificat, implementat și testat funcționalitățile modulului DeveloperUI privind gestionarea utilizatorilor, echipamentelor și instrumentelor, localizarii interioare, scenariilor de monitorizare și alertare, stabilirea regulilor business ce țin de proiecte, alături de vizualizare rapoarte. Integrările făcute pentru a funcționa sistemului testat au implicat folosirea software-urilor deConz, HACS, serviciului web Meteorologisk Institutt pentru a prelua date despre vreme, Mobile App pentru a accesa aplicația de pe telefonul mobil, Raspberry Pi Power Supply Checker pentru a permite verificarea sursei de alimentare a Raspberry Pi care trimite datele de la panoul de testare la modulul DeveloperUI și protocolul Z-Wave. Localizarea interioară a fost studiată în două situații reale, folosind becurile inteligente dezvoltate de partenerul spaniol din cadrul proiectului i-Light. Sistemul SMARTCARE se bazează pe adaptarea soluției i-Light, încât un articol a fost publicat în această direcție.
Figura 4 – Interfața principală a utilizatorului de tip administrator
(6) Website-ul proiectului
PRODUSE
Prototip final componenta Gateway
Gateway se identifică la nivel logic printr-un set de programe server și module, fiecare fiind responsabil de un task bine stabilit (bridge, server, baza de date, interfața utilizator, client).
Prototip final componenta Sistem Expert
Componentele Sistemului Expert permit vizualizarea, configurarea, gestiunea, agregarea și raportarea datelor și a modului în care utilizatorii finali le pot vizualiza în interfețele grafice aferente.
Prototip final componenta DeveloperUI
Componenta DeveloperUI ca interfață grafică pentru utilizator și are rolul de a ușura proiectarea de soluții pentru aplicații specifice de asistență la domiciliu.
Plan de testare și evaluare
Planificarea testării sistemului SMARTCARE este o combinație între testarea cutie neagră/black-box testing bazată pe intrări, verificarea ieșirii și testarea cutie albă/white-box testing bazată pe cod.