2011 1. raportul stiintific si tehnic (rst ... erisc rst etapa 4 2011.pdf · 2011 etapa - 4 1 1....

2011 www.erisc.ro Etapa - 4

1

1. Raportul Stiintific si Tehnic (RST) in extenso

PNCDI 2

Programul 4 – Parteneriate in domenii prioritare

“PLATFORMA E-HEALTH PENTRU MONITORIZARE, LOCALIZARE SI

PROCESARE IN TIMP REAL DESTINATA PACIENTILOR INREGISTRATI CU

RISC CARDIOVASCULAR – E-RISC”

Etapa IV:

Elaborare solutii de functionare; Proiectare model experimental ;

Realizare model experimental-hardware si software; Experimentare

sisteme si functii de localizare

Termen de predare: 10.12.2011

Decembrie 2011


2

CUPRINS

I.OBIECTIVE GENERALE 4

II. OBIECTIVELE ETAPEI DE EXECUTIE 6

III. REZUMATUL ETAPEI ..................................................................................................... 8

IV. RAPORTUL TEHNICO - STIINTIFIC ............................................................................. 10

A1. Elaborare solutii pentru model experimental - finalizare ........................................10

A1.1 Elaborare versiune alpha de software pentru management; Elaborare structura software medical; Elaborare model culegere cu senzori a informatiei; Elaborare solutie de comunicatie – finalizare (CO-WING) .................................... 10

A1.1.1 Elaborare versiune alpha de software pentru management ................... 10

A1.1.2 Elaborare structura software medical ..................................................... 10

A1.1.3 Elaborare model culegere cu senzori a informatiei ................................. 11

A1.1.4 Elaborare solutie de comunicatie – finalizare (CO - WING) .................... 14

A1.2 Elaborare solutie de localizare GPS/GSM –finalizare (P3 – IPA) ................. 21

A1.3 Elaborare solutie comunicatii cu fibra optica – finalizare (P4 – INOE) .......... 24

A1.4 Elaborare solutie comunicatii date cu un consum redus de energie – finalizare (P5 – IOEL) ............................................................................................ 26

A1.5 Elaborare solutie achizitie date multicanal – finalizare (P6 – ELCOS) .......... 30

A2. Elaborare solutii de functionare a sistemului cu relee personale GSM/GPRS ... 34

A2.1. Elaborare solutie generala a sistemului ....................................................... 34

A2.2. Elaborare solutie GSM GPRS (P3 – IPA si P6 – ELCOS) ........................... 36

A2.3. Elaborare solutie interconectare comunicatii (P4- INOE)…………………….37

A2.4. Elaborare solutie pentru modelul de comunicatii (P5 - INOE) ...................... 39

A3. Proiectare model experimental ................................................................................. 41

A3.1 Proiect general sistem; Proiectare sisteme senzori;Proiectare software comunicatii (CO-WING) ......................................................................................... 41

A3.1.1 Proiect general sistem ............................................................................ 41

A3.1.2 Proiectare sisteme senzori ..................................................................... 44


3

A3.1.3 Proiectare software comunicatii (CO-WING) 44

A3.2 Proiectare achizitii date (P2 – UPB+P6-ELCOS) .......................................... 48

A3.3 Proiectare automatizari (P3 – IPA) ................................................................ 50

A3.4 Proiectare canale legaturi (P4 – INOE) ......................................................... 53

A4. Realizare hardware si software ................................................................................. 55

A4.1 Realizare globala sistem; Realizare software global (CO-WING) ................. 55

A4.1.1 Realizare globala sistem ......................................................................... 55

A4.1.2 Realizare software global ....................................................................... 57

A4.2 Realizare elemente de testare medicala (P1 – SCUB) ................................. 67

A4.3 Realizarea automatizarilor (P3 – IPA) ........................................................... 71

A4.4 Realizarea structurilor de comunicatie si software aferent (P4 – INOE, P5 – IOEL) ..................................................................................................................... 72

A4.5 Realizare structuri hardware de achizitie date (P6 – ELCOS) ...................... 79

A5. Experimentare sistem pacient si functii de localizare ............................................. 82

A5.1 Experimentare sistem pacient; (CO-WING) .................................................. 82

A5.2 Experimentare medicala, solutii de optimizare (P1 – SCUB) ........................ 86

A5.3 Experimentare sistem pacient (P2 – UPB) .................................................... 95

A5.4 Experimentare functii de localizare (P3 – IPA) ............................................ 101

V.ANEXE .......................................................................................................................... 103

ANEXA 1 104

ANEXA 2 105

ANEXA 3 109

ANEXA 4 112

ANEXA 5 115

ANEXA 6 117

VI. CONCLUZII ................................................................................................................. 124

VII. BIBLIOGRAFIE ........................................................................................................... 126


4

I. OBIECTIVE GENERALE

Obiectivul proiectului consta in dezvoltarea unor cercetari privind obtinerea

unei solutii de monitorizare on-line pentru pacientii tratati in ambulatoriu, prin

preluarea comoda de la pacient printr-un dispozitiv purtabil, transmiterea

GSM/GPRS la dispecerat, prelucrarea computerizata a semnalelor ECG si

monitorizarea continua sau periodica a valorilor predefinite pentru fiecare pacient in

parte.

In cazul aparitiei unor „elemente critice predefinite” serverul specializat

notifica dispeceratul despre eveniment si comunica si pozitia geografica a

pacientului (printr-o dubla tehnologie: GPS si GSM) pentru a putea fi „recuperat” de

ambulanta usor.

Proiectul isi propune sa reduca costurile de spitalizare si sa creasca numarul

de pacienti care beneficiaza de asistenta medicala de inalta specialitate.

Toate acestea se vor realiza prin implementarea unui software de

management care va administra toate componentele Subsistemului de Prelucrare la

Distanta (SPD) si care va lucra impreuna cu software-ul biomedical.

Obiectivul implica rezolvarea urmatoarelor aspecte in realizarea sistemului

informatic purtabil de tip e-health:

- evaluarea informatiilor transmise de complexul de senzori si elaborarea unei

proceduri de validare la distanta a pozitiei senzorilor ECG, a datelor analizate

si a pragurilor de alarmare, determinarea tipurilor de senzori auxiliari si

evaluarea interdependentelor.

- realizarea softului biomedical si de management.

- filtrare digitala autoadaptiva multidimensionala a semnalului ECG in corelatie

cu informatiile transmise de accelerometrele XYZ.

- analiza si prelucrarea in timp real a semnalului ECG prin metode de analiza in

domeniul timp, in domeniul frecventa si timp-frecventa – analiza Wavelet 3D a

seriei RR a semnalului ECG;

- diagnoza automata a statusului medical in doua etape prin folosirea unei

matrici decizionale in cadrul subsistemului software de monitorizare a

pacientului.


5

- stabilirea schemei generale a sistemului informatic, proiectarea

componentelor, asamblarea acestora si testarea in conditii reale de lucru a

modelului experimental.

- rejectarea activa a artefactelor.

- metode pentru calibrarea sistemului in vederea reactiei active la artefacte.


6

II. OBIECTIVELE ETAPEI DE EXECUTIE

ETAPA IV. Elaborare solutii de functionare; Proiectare model experimental ;

Realizare model experimental-hardware si software; Experimentare sisteme si

functii de localizare

A1. Elaborare solutii pentru model experimental - finalizare

A1.1 Elaborare versiune alpha de software pentru management; Elaborare

structura software medical; Elaborare model culegere cu senzori a informatiei;

Elaborare solutie de comunicatie – finalizare (CO-WING)

A1.2 Elaborare solutie de localizare GPS/GSM –finalizare (P3 – IPA)

A1.3 Elaborare solutie comunicatii cu fibra optica – finalizare (P4 – INOE)

A1.4 Elaborare solutie comunicatii date cu un consum redus de energie –

finalizare (P5 – IOEL)

A1.5 Elaborare solutie achizitie date multicanal – finalizare (P6 – ELCOS)

A2. Elaborare solutii de functionare a sistemului cu relee personale

GSM/GPRS

A2.1 Elaborare solutie generala a sistemului; Elaborare solutie GSM;

Elaborare solutii de conectare (CO-WING)

A2.2 Elaborare solutie GSM GPRS (P3 – IPA + P6 – ELCOS)

A2.3 Elaborare solutie interconectare comunicatii (P4 – INOE)

A2.4 Elaborare solutie pentru modelul de comunicatii (P5 – IOEL)

A3. Proiectare model experimental

A3.1 Proiect general sistem; Proiectare sisteme senzori;Proiectare software

comunicatii (CO-WING)


7

A3.2 Proiectare achizitii date (P2 – UPB +P6 – ELCOS)

A3.3 Proiectare automatizari (P3 – IPA)

A3.4 Proiectare canale legaturi (P4 – INOE)

A4. Realizare hardware si software

A4.1 Realizare globala sistem; Realizare software global (CO-WING)

A4.2 Realizare elemente de testare medicala (P1 – SCUB)

A4.3 Realizarea automatizarilor (P3 – IPA)

A4.4 Realizarea structurilor de comunicatie si software aferent (P4 – INOE

,P5 – IOEL)

A4.5 Realizare structuri hardware de achizitie date (P6 – ELCOS)

A5. Experimentare sistem pacient si functii de localizare

A5.1 Experimentare sistem pacient; (CO-WING)

A5.2 Experimentare medicala, solutii de optimizare (P1 – SCUB)

A5.3 Experimentare sistem pacient (P2 – UPB)

A5.4 Experimentare functii de localizare (P3 – IPA)


8

III. REZUMATUL ETAPEI

Avand in vedere ca multe din activitatile din aceasta etapa sunt o finalizare a

celor din etapa anterioara (din motive de restrictii bugetare unele activitati au fost

anulate, altele au fost reduse cu 50%, iar unele au comasate) acesta etapa finala a

trebuit sa 'inchida" toate cercetarile incepute in 2008-2009 cand proiectul avea o

finantare cu aproximativ 70% mai mare decat s-a dovedit in realitate.

1. Se analizeaza hardware-ul si software-ul din structura de comunicatii la nivel

de sistem. Sunt aratate imbunatatirile aduse acestor structuri de la ultima etapa si

este explicat modul in care acestea optimizeza functionarea sistemului;

2. Ca punct cheie privind dezvoltarea software-ului de mangement si biomedical,

automatizarea monitorizarii este descrisa atat ca schema bloc cat si ca

functionalitate;

3. Se prezinta studiul privind interfetele de emisie-receptie si de comunicatie om-

sistem in care sunt detaliate optiunile avute privind viitoarea implemetare;

4. Este studiat software-ul de achizitii date specific, si sunt luate in considerare

variantele care vor functiona pe convertoarele AD de tip Sigma-Delta. Sistemele

purtabile avand restrictii importante privind consumul energetic si dimensiunile,

solutia aleasa este cea mai eficienta.

5. In privinta studiului software-ului de comunicatii se arata ca folosirea solutiilor

de tip CRC si PKI permit functionarea in parametri nominali si asigura beneficiarul ca

datele vehiculate pe reteaua virtuala sunt integre.

6. S-a inceput elaborarea versiunii alpha a software-ului de management de

sistem. Astfel, s-a descris functionalitatea sa in conditiile „rularii” a catorva scenarii

de functionare, E-RISC demonstrand astfel ca automatizarea monitorizarii este un

deziderat realizabil. In plus s-au creat interfetele de lucru ale programului.

7. In ceea ce priveste software-ul biomedical, s-a inceput realizarea acestuia

functie de locul acestuia in Sistemul de Prelucrare la Distanta: analiza in timp,


9

frecventa si timp-frecventa, filtrare, tratare artefacte, dinamica pacient. In toate

aceste cazuri s-a specificat si modul in care, pe principalele bucle de lucru ale

programului de management, se realizeaza rejectia artefactelor ca element vital, in

buna functionare a sistemului E-RISC. S-au gasit in acest sens chei de control

pentru reglarea sistemului in cazul in care acesta este compromis de artefacte, prin

calibrarea Serverului de Artefacte functie de aparitia „evenimentului unic” din

prelucrarea timp-frecventa.

8. S-a prezentat elaborarea solutiei de localizare nonGPS si modul in care

aceasta va acompania sistemul GPS.

9. S-au elaborat solutiile privind functionarea sistemului de comunicatii in conditii

de consum redus de energie, si a solutiei de achizitii date multicanal aratand pentru

fiecare caz in parte avantajele variantelor alese.

10. In cazul conectarii SPD (Sistemul de Prelucrare la Distanta) la operatorul

GSM prin fibra optica este descrisa solutia de back-up si modalitatea prin care este

asigurata calitatea transmisiei in contextul descris.

11. Informatii suplimentare privind derularea proiectului se gasesc la:

www.erisc.ro .

http://www.erisc.ro/


10

IV. RAPORTUL TEHNICO - STIINTIFIC

A1. Elaborare solutii pentru model experimental - finalizare A1.1 Elaborare versiune alpha de software pentru management; Elaborare structura software medical; Elaborare model culegere cu senzori a informatiei; Elaborare solutie de comunicatie – finalizare (CO-WING)

A1.1.1 Elaborare versiune alpha de software pentru management

Solutia aleasa pentru dezvoltarea software-ului de management al sistemului

E-RISC presupune existenta unei structuri de tip platforma in cadrul careia vom reuni

datele provenite de la toate subsistemele componente.Prin subsisteme componente,

intelegem subsistemul purtabil aflat la pacient si serverele intermediare utilizate

pentru preluarea informatiilor medicale si pozitionare GPS. Structura platformei de

management a sistemului trebuie sa permita atat colectarea datelor, cat si

prelucrarea acestora si gestionarea rezultatelor.

Proiectarea platformei are in vedere posibilitatea de a accesa in timp real

toate datele medicale aferente pacientului, datele suplimentare legate de pozitionare

si starea de functionarea a serverelor componente. Suplimentar, platforma trebuie sa

ofere posibilitatea conectarii la o baza de date ce ofera un istoric medical pacientilor.

Astfel in cazul apartitiei unei probleme, personalul medical va putea vizualiza

antecedentele medicale ale pacientului.

A1.1.2 Elaborare structura software medical

In etapa anterioara a proiectului a fost dezvoltat software-ul medical pentru

realizarea Transformatei Fourier, a Transformatei Wavelet, pentru Evaluare

interactiuni si Filtrare multidimensionala.In aceasta etapa ne propunem adaptarea

software-ul medical specific pentru analiza directa a biosemnalelor provenite de la

pacient si integrarea acestuia in cadrul platformei de management. Integrarea

software-ului medical in cadrul platformei de management ne ofera posibilitatea

realizarii analizei semnalelor pentru un esantion de date reale, inregistrate la


11

momentul de timp in care a fost semnalata aparitia unui eveniment. Acest lucru ne

ofera o imagine de ansamblu asupra starii de sanatate a pacientului si ajuta in

diagnosticarea corecta a pacientului.

Structura software-ului biomedical este urmatoarea:

a. Software biomedical on-line;

b. Software biomedical off-line.

Componenta celor doua categorii de software este:

a. Software biomedical on-line;

Cuprinde monitorizarea continua a urmatoarelor date:

• Date vitale directe:

- RR online: prelucrare obtinuta direct in subsistemul purtabil;

- Variatia toracica respiratorie;

- ECG primar;

• Date vitale prelucrate

- FFT aplicat pe RR;

b. Software biomedical off-line;

- Transformata Fourier;

- Transformata Wavelet;

- Evaluare interactiuni;

- Filtrare multidimensionala.

Modalitatea prin care aceasta structura a fost elaborata a fost prezentata in

predarea etapei din 2010.

A1.1.3 Elaborare model culegere cu senzori a informatiei

Culegerea informatiilor biologice si de pozitie reprezinta unul dintre

elementele principale ale proiectului si modul cum este tratat acest subiect este

hotarator asupra rezultatului final precum si a costurilor totale.

Modelul de achizitie de date ales induce in principal costul final al produsului,

regimul de utilizare precum si segmentul de piata caruia ii este destinat. Folosirea


12

unor senzori neadecvati va afecta in mod crucial precizia, dimensiunile sistemului

purtabil precum si indicele de purtabilitate al produsului nostru.In ultimi trei ani au

fost perfectionate in permenta tehnici si metode de masurare directa sau indirecta a

parametrilor biologici. Fiind un domeniu de granita, biosenzorii textili sunt o cota

importanta din gradul de noutate adus de proiectul nostru prin imperecherea

produselor fizice cu softul de achizitie si procesare a semnalelor provenite de la

acest tip de biosenzori. Dupa achizitionare si apoi testarea a diversilor senzorii ECG

pentru sisteme purtabile, echipa noastra a putut sa defineasca modelul experimental

ca un sistem de achizitie ECG ce foloseste senzori inteligenti de tip e-textil.

Figura.1 Senzori de tip e-textil

Senzorii inteligenti de tip e-textil permit cel mai scazut nivel al artefactelor de

miscare, din cei testati si analizati de echipa noastra in ultimii 2 ani. Folosirea unei

centuri elastice dotata cu acest tip de senzori permite reducerea semnificativa a

efortului de a filtra zgomotele produse de miscarile corpului, relative la senzor. In

sistemele clasice aceste zgomote sunt eliminate prin lipirea de tegument a senzorilor

metalici cu un gel special. Pentru ca sistemul nostru este purtabil, adica pacientul se

duce la plimbare, face sport sau efectueaza diverse munci cotidiene, folosirea

acestui tip de electrod este incomoda si mai ales nepractica pentru ca acesti

electrozi, fiind rigizi, genereaza tensiuni in gelul de lipire, la contactul cu pielea, care

duc in final la dezlipirea electrodului si pierderea semnalului ECG corespunzator.


13

Din motive de utilizare practica, in locul tricoului din e-tesut (foarte scump),

echipa noastra a folosit o centura ce este chiar lavabila, si pe care au fost cusute

portiuni de contact dintr-o tesatura speciala de tip Coolmax 70/80micro. In cursul

testelor sistemul de conectare a fost schimbat de mai multe ori, solutia actuala

dovedidu-se de departe cea mai stabila la numeroase montaje si demontaje a

CUTIEI asa cum este denumita cutiuta de sistem alarma auto in care au fost

montate elementele principale de procesare si control a modulului purtabil.

De mentionat ca au fost testate si doua tricouri produse de Numetrex pe baza

aceluiasi material textile tesut cu fir (Coolmax70/80), care sunt totusi mult mai

scumpe decat produsul nostru experimental manufacturat local.

Sen

zorii E

CG

Sen

zorii

res

pira

tie

preAm

plif.

analogice

Sen

zori

pozi

tie X

YZ

tem

p0

Mic

roco

ntroler M

SP430

Blu

etoo

thm

odu

lSurs

a Lipo

conv

erto

r CC

Figura.2 Arhitectura sistemului

Acesta arhitectura are avantajul ca permite modularizarea sistemului de

senzori, fiind posibil sa folosim doar o parte din senzorii disponibili si sa realizam

astfel importante economiii energetice in conditiile in care se reduc si numarul de

cicluri ale procesorului sistemului si deasemenea modularizarea permite sa

schimbam tipul senzorilor folositi.

Concluzie:

Achizitia datelor electrobiologice se va face prin intermediul senzorilor

e-textili tesuti, impreuna cu un set de informatii despre mediu si pozitia

subiectului in mediu. Modularizarea sectiuni de achizitie date permite

schimbarea cu usurinta a tipului de senzori utilizati.


14

A1.1.4 Elaborare solutie de comunicatie – finalizare (CO - WING)

Alegerea finala a solutiei de comunicatii este generata de avansul tehnologic

inerent aparut in timpul desfasurari proiectului precum si de restrictiile financiare

aparute dupa semnarea contractului. In aceste conditii s-a avut in vedere adoptarea

unei solutii de comunicatii care sa reduca la jumatate costurile de realizare, testare,

imbunatatire, retestare si caracterizare a sistemului.

Desi teoretic, solutia Zigbee este mai buna pentru BAN (Body Area Network)

si echipa noastra avea cele mai bune rezultate de laborator lucrand cu

echipamentele Zigbee (pana la aparitia efectiva a BLE in 2011) faptul ca trebuia sa

construim un dispozitiv special pe post de statie releu intre reteaua BAN si reteaua

GSM/3G ridica destul de mult costurile proiectului.

Chiar si in cazul in care se construia doar o interfata usb speciala care trebuia

conectata la un telefon mobil, ridica probleme destul importante vizand fiabilitatea

finala a intregului lant de comunicatii.Reducerea bugetului operata in timpul

desfasurarii proiectului a decis abandonarea solutiei Zigbee si orientarea spre

Bluetooth.

Evaluarea solutiei de comunicatii finale a avut ca principal obiectiv gasirea

solutiei care permitea finalizarea proiectului prin incadrarea in bugetul de cercetare

redus cu aproximativ 50% efectuata in anul 2010.

OperatorGSM HUB

Statie baza

legatura FO(fibra optica)

legatura FO(fibra optica)

lega

tura

FO

(fib

ra o

ptic

a)

legatura FO(fibra optica) FireWall

FireWall

Medicprimesteonline

date ECG

Smartphonemedic

Administrator de

retea

Server comunicatii

SPITALsectia cardiologie

medic cardiolog

BAN (Body Area Network)

Retea GSM/3G

Serverprocesare

datebiomedicale

Figura.3 Structura retea comunicatii


15

In figura de mai sus se observa existenta a 4 tipuri de retele care

interactioneaza in mai multe puncte de contact prin routere sau telefoane inteligente.

Filtrarea modului de acces la datele personale care circula in aceste retele se

face pe baza unor protocoale speciale si a unor programe specifice. De exemplu,

pentru securizarea SO Android care ruleaza pe telefoanele inteligente, sistemul

nostru foloseste aplicatia Bitdefender mobil, pentru evitarea aparitiei de malware sau

virusi in aplicatie.In plus, pentru filtrarea traficului se foloseste Droidwall - o aplicatie

cu functie de firewall.

nr. crt.

Tip retea Vulnerabilitati Contramasuri Obs.

1 BAN (Body AreaNetwork)

sensibila la bruiaj activ, banda foarta aglomerata.

Monitorizarea prin software a calitatii legaturii radio si semnalarea disfunctionalitatiilor

Banda de 2.4Ghz este ocupata de cuptoarele cu microunde, WIFI, Zigbee,

2 GSM /3G

Sensibilitate la bruiaj activ, banda negarantata poate intrerupecomunicatia curenta

Facilitati de switch automat in GSM-GPRS chiar daca exista semnal 3G pentru prezervarea limitei de 32kbs necesare.

In timpul testelor a fost observata posibilitatea de a pastra deschis canalul de comunicatii in GPRS.

3 WAN /internet

Cyberatacuri, Malware

Firewall si arhitectura securizata

Sol. initiala de a folosi o retea dedicata de FO intre HUB GSM si Datacenter-ulWing a fost anulata din motive financiare

4 LAN Malware, virusi Solutii antivirus, proceduri speciale de acces in lan

Concluzie:

Lantul de comunicatii dezvoltat in cadrul acestui proiect se poate

caracteriza cel mai bine ca o solutie minimalista pentru a rezolva comunicatiile

sigure la cel mai bun raport pret/performanta.Schimbarea a doua tehnologii in


16

trei ani, datorita progreselor tehnice aparute in acest domeniu este dovada ca

proiectul se bazeaza pe un suport tehnic de ultima generatie astfel incat

elementele novatoare vor avea o viata tehnologica suficient de lunga pentru a

se impune pe piata.

Firewall

Poate fi de tip software sau hardware.Are rolul de a preveni intruziunile

externe, atacuri de tip informatic, etc.Un firewall este un echipament destinat

controlului comunicatiilor in retea pe baza unui set de reguli.Este des utilizat pentru

protectia retelelor in cazul incercarilor de acces neautorizat, permitand in acelasi

timp trecerea traficului legitim.

Figura.4 Firewall-ul filtreaza traficul intre o retea locala si internet

Router

Routerele opereaza la nivelul 3 al modelului OSI.Acest lucru inseamna ca

sunt utilizate adrese IP ale pachetelor aflate in tranzit pentru a se decide prin ce

interfata se va face trimiterea pachetului.Decizia este luată comparand adresa

calculatorului destinaNie cu înregistrările (campurile) din tabela de rutare.

In esenta, router-ul este un dispozitiv hardware sau software care conectează

două sau mai multe reNele de calculatoare bazate pe "comutarea de pachete"

(packet switching).Functia indeplinita de acesta se numeste rutare.

Router-ul trebuie sa asigure:

- legatura la internet;

- comutarea de pe o fibra optica pe cealalta.


17

Deoarece un gateway poate executa si functii de rutare si operatii

suplimentare, producatorii de echipamente pot include si functia de firewall in cadrul

produselor lor.

Server Comunicatii si Autentificare: masina destinata asigurarii transmisei

sigure a datelor.

Securitatea comunicatiilor trebuie sa fie asigurata in primul rand de criptarea

informatiei.Unul dintre modurile de utilizare este combinatia dintre TLS sau SSL si

protocolul de comunicatie utilizat: FTP / HTTP / etc.

TLS (Transport Layer Security), Secure Sockets Layer (SSL) si Transport

Layer Security (TLS), succesorul sau, sunt protocoale criptografice care permit

comunicatii sigure pe Internet.Intre SSL 3.0 si TLS 1.0 exista anumite diferente, dar

protocolul ramane aproximativ acelasi. Pentru a cripta datele TLS / SSL utilizeaza un

sistem criptografic cu doua chei: una publica, cunoscuta de oricine, si una privata,

secreta, cunoscuta numai de destinatarul mesajului.

TLS / SSL asigura autentificarea endpoint-urilor si confidentialitatea

comunicatiei prin Internet folosind criptografia.In utilizarile uzuale, numai serverul

este autentificat (identitatea sa este certificata), în timp ce clientul ramane

neautentificat; autentificarea mutuala presupune existenta unui mecanism de

distributie a cheilor publice („PKI”) catre clienti.

TLS / SSL implica mai multe faze intermediare:

- Verificarea mutuala de suportare a protocolului;

- Schimbarea cheilor prin intermediul criptarii prin metoda cu chei

publice si autenficare pe baza de certificate;

- Trasmiterea de trafic criptat prin sistemul cheilor simetrice.

In timpul primei faze a protocolului serverul si clientul negociaza asupra

algoritmului de criptare care va fi folosit. Implementarile curente permit urmatoarele

posibilitati:

- criptografia bazata pe chei publice: RSA, Diffie-Hellman, DSA sau

Fortezza;

- pentru codari simetrice: RC2, RC4, IDEA, DES, Triple DES sau AES;


18

- pentru functii de hash unidirectional: MD5 sau SHA.

Switch management 1Gb – FO

Caracteristica minimala:

- 1Gb pe port;

- Versatilitate in programare: management layer 3;

- Imunitate la influente electromagnetice: transmisie pe fibra optica.

O retea locala virtuala (VLAN - Virtual Local Area Network) reprezinta

gruparea logica a componentelor unei retele locale, fara a tine cont de gruparea lor

fizica. Segmentarea fizica a unui LAN cu echipamente de comunicatie de tip hub,

switch sau bridge face posibila segmentarea domeniului de coliziune initial in mai

multe domenii de coliziune, dar pastreaza un singur domeniu de broadcast, ceea ce

permite un control mai eficient al congestiilor din retea dar nu reduce incarcarea

retelei prin transmisia mesajelor de broadcast.

Routerul este singurul echipament care delimiteaza un domeniu de broadcast,

indeplinind functia de firewall.

In multe cazuri este utila gruparea calculatoarelor-gazda in domenii de

broadcast separate, pe diferite criterii independent de conexiunile fizice existente in

retea si de amplasarea lor in spatiul unei cladiri.

Definirea VLAN-urilor se poate face in functie de diversi factori:

• numere de identificare (ID - identifier) a porturilor;

• adrese MAC;

• protocoale de retea;

• porturi de aplicatie.

Fiecare VLAN reprezinta un domeniu de broadcast independent, ceea ce

permite reducerea incarcarii retelei prin difuzarea mesajelor catre toti utilizatorii.

Se poate defini cate un VLAN pe fiecare port al switch-ului. Mai multe porturi

din switch pot sa apartina aceluiasi VLAN. La nivelul switch-ului, transmisiile prin

broadcast se fac numai pe porturile asociate aceluiasi VLAN.


19

Subsistemul Prelucrare Evenimente primeste date de la Subsistemul de

Transmisie (ST), ce vor fi utilizate de Serverul Prelucrare si Analiza.Datele

pacientilor sunt necesare in detectia artefactelor (prin comparatia semnalelor

specifice pacientului), iar datele GPS sunt disponibile pentru cazurile in care se

doreste recuperarea pacientului.

Figura. 5 Functii servere

In componenta Subsistemului de Prelucrare Evenimente:

Server stocare - dupa cum spune numele, acest server va cuprinde toate

informatiile transmise de Subsistemele de Telecomunicatii.

Necesar:

- spatiu mare de stocare;

- timp de acces mic la datele stocate;

- acces compatibil cu multiple sisteme de operare;

- acces securizat la informatii;

- organizare flexibila a datelor.


20

Server Anamneza Pacienti si Patternuri Deplasari - va contine istoricul medical al

fiecarui pacient, istoricul de deplasari (coordonate GPS) si modele de deplasari

privind traseele acestora.

Cerinte:

- securitatea datelor (fiind vorba despre informatii personale medicale);

- acces facil la date;

- un sistem de stocare flexibil, compatibil cu multiple OS-uri.


21

A1.2 Elaborare solutie de localizare GPS/GSM –finalizare (P3 – IPA)

Solutia de localizare finala va integra tehnologia de localizare livrata de

versiunea 2.3.3 a Android perfectionata prin aplicarea unei solutii tehnice propietare

de expediere in regim de pachete de date de pozitie pentru a fi recalculate pe

serverul de comunicatii. Acesta solutie, obtinuta dupa mai multe iteratii a diverselor

tehnologii de localizare duala, disponibile in cadrul consortiului, este cea mai solida

desi nu este foarte precisa.

Faptul ca acesta solutie de localizare este integrata in SO al smartphone-ului

asigura intrisec functionarea sigura a sistemului si permite cresterea disponibilitatii

sistemului prin reducerea numarului de procese care ruleaza sub SO, inlaturand

redundanta unor procese.

Pentru a compensa problemele de precizie ale acestei solutii, sistemul va

trimite periodic (10s-30s) rapoarte de pozitie complete ce vor include toate datele

necesare recalcularii pozitiei de catre serverul de comunicatii. Pozitia post calculata

a pacientului este comparata cu pozitia raportata de sistemul mobil si, in functie de

diferentele determinate, este aplicat un script cu raspunsuri gradate, de la calcularea

unor corectii minore, pana la ridicarea unui steag de atentionare pentru probleme

majore asupra integritatii SO din terminalul mobil.

In cazul unor abateri majore dintre pozitiile calculate de sistemul mobil si

serverul de comunicatii, inainte de declansarea unei alarme de sistem, se va utiliza o

analiza a log-urilor de deplasare cautand corelatii intre pozitiile anterioare, stabilite

prin GPS, si pozitiile calculate pe baza statiilor GSM. Aceasta strategie va permite

reducerea majora a rapoartelor de pozitie eronate, care pentru Google sunt

neimportante, dar foarte importante pentru aplicatia noastra.

T1 T2

T3

Figura.6 Principiu pozitionare


22

Schema pe baza careia SO Android calculeaza pozitia geografica, se

bazeaza pe masurarea timpul de propagare de la statiile de baza pe care terminalul

le receptioneaza si astfel se determina distanta pana la respectivele statii.Pentru

aceasta solutie sunt necesare cel putin 3 statii de baza.

In orase, precizia este mult imbunatatita faptului ca pot fi receptionate mult

mai multe statii.ln zonele rurale, precizia este mult mai scazuta pentru ca de obicei

sunt receptionate doar una sau doua statii de baza.In ultima situatia se poata

determina doar un perimetru in jurul antenei statiei de baza.

Precizia obtinuta astfel este suficienta pentru marea majoritate a aplicatiilor de

tip LBS (location based service). In cazul in care se doreste o precizie crescuta, se

va folosi GPS-ul integrat in terminalul mobil de tip smartphone.Pentru scaderea

timpului de sincronizare in versiunile "high end" se folosesc tabele speciale cu

configuratia satelitilor GPS la data si ora respective.

Aceste tabele sunt actualizate prin internet permanent de catre producator si

se reduce astfel timpul de sincronizare la sub 15 secunde (in mod normal acest timp

poate fi de 1minut sau mai mult).In plus, prin folosirea localizarii primare, furnizata de

reteaua GSM, se obtine scurtarea timpului de determinare a pozitiei geografice de

nivel comercial (7m).

Pentru aplicatii profesionale,aceasta precizie poate creste pana la nivel de

cm.In plus combinarea datelor de la GPS cu sistemul rusesc GLONASS permite

scaderea suplimentarea a timpului de asteptare pentru calcularea pozitiei cu nivel

comercial de precizie.

Din pacate folosirea extensiva a functionalitatiilor GPS duce la cresterea

exagerata a consumului si reducerea timpului de functionare cu pana la 63% (valori

masurate pentru HTC Android si HTC Touch Pro).

In cazul telefonului Motorola RAZR, care foloseste un nou tip de GPS,

consumul total scade cu pana la 50% prin folosirea unei microantene optimizate

pentru telefoane mobile si mai ales prin utilizarea unei ferestre temporale care

permite functionarea antenei active (care este marele consumator energetic) in

segmente alternative de timp.

Progresul in domeniul antenelor active, care beneficiaza astazi de noi

materiale semiconductoare speciale pentru receptoarele GPS, permite scaderea


23

costurilor unor sisteme de asistenta medicala la distant, acest lucru fiind dovada de

netagaduit a interdependetelor din societatea contemporana.

Concluzie:

Pentru localizarea pacientului se vor folosi in principal informatiile de

pozitie din API Android, fara GPS si doar in cazul unui eveniment se va

declansa un proces care va activa antena GPS si va initia procesarea de

precizie a informatiilor de pozitie, care vor fi coroborate cu datele

postcalculate de serverul distant.Doar noile smartphone care vor fi dotate cu

noul tip de receptor GPS pot folosi fara restrictii localizarea AGPS.


24

A1.3 Elaborare solutie comunicatii cu fibra optica – finalizare (P4 –

INOE)

Fibra optica reprezinta suportul fizic ales pentru realizarea legaturilor de

comunicatie, atat intre providerul de servicii internet si Subsistemul de prelucrare la

distanta, cat si intre echipamentele ce formeaza SPD.

Alegerea F.O este normala tinand cont de avantajele utilizarii acesteia:

- Distante de comunicatie foarte mari (de ordinul zecilor de km);

- Latimea de banda, ce poate ajunge la 100 Gbps;

- Flexibilitate;

- Imunitate la interferente electromagnetice;

- Costuri reduse;

- Compatibilitate echipamente.

Pentru realizarea redundantei in comunicatia dintre ISP si SPD se vor utiliza

doua fibre optice, al caror traseu metropolitan este diferit. Astfel in cazul aparitiei

defectiunilor pe un traseu, legatura va putea fi comutata pe fibra de pe cel de-al

doilea traseu.

Un plus pentru utilizarea F.O in anumite zone metropolitane este dat de

ingroparea acestora (proiectul NetCity national), acest lucru asigurand un nivel de

siguranta mai ridicat decat in cazul intinderii acestora aerian.

Figura.7 Trasee diferite fizic pentru fibra optica

In cazul utilizarii in interiorul SPD, pentru interconectarea echipamentelor

interne ale acestuia, se prefera fibra optica in detrimentul cablurilor de metal

deoarece:


25

- fibra optică economiseNte spaNiu în conductele de cablu deoarece o

singură fibră poate transporta mai multe date decât un singur cablu

electric;

- fibra optica nu conduce electricitate, nefiind afectata de descarcari

electrice, putand fi folosita in medii in care sunt prezente gaze inflamabile;

- interceptarea comunicatiilor este mult mai dificila.

Concluzie:

Folosirea Fibrei Optice (FO) permite scaderea costurilor de utilizare si

mai ales asigura securitatea legaturilor dintre HUB-ul GSM si DataCenter prin

folosirea unui link FO de fibra neagra.


26

A1.4 Elaborare solutie comunicatii date cu un consum redus de energie

– finalizare (P5 – IOEL)

In cadrul acestui proiect, un element constant in proiectarea modulului purtabil

a fost grija de a asigura disponibilitatea energetica a sistemului. Faptul ca a existat

din proiectare o limita la 450mW/h, din cauza dimensiunilor impuse initial

acumulatorului, a reprezentat un obstacol abordat din mai multe directii.Dupa multe

eforturi a fost gasit un acumulator LiPo de generatie noua cu o capacitate de

650mW/h care permitea atingerea nivelului minim de disponibilitate si care se

incadra in limitele dimensionale. O alta solutie, mult mai eficienta era reducerea

consumurilor sistemelor active din modulul portabil.

Configuratia sistemelor posibil de utilizat in BAN este urmatoarea:

nr. crt.

Standard capacitatea raza de lucru

topologie consum memorie necesara

Banda lucru (Mhz)

1 Bluetooth 2.1 0.1-3Mb 10m star 40mA 50-90kb 2400

2 Bluetouth Low

Energy 4

1Mb 10m star 20mA 40kb 2400

3 ZigBee 20-

250kbps

100m mesh/star 20mA 100kb 2400;

868

Din acest tabel rezulta clar ca Bluetooth Low Energy este castigator, dar fiind

un produs foarte nou, primele kit-uri de dezvoltare au aparut in august 2011 iar

primele telefoane care suporta Bluetooth ver. 4.0 au aparut in aceasta toamna.

Pentru nevoile noastre a fost nevoie de un telefon mobil care foloseste SO Android,

in Romania in noiembrie 2011, doar noul Motorola RAZR si IPhone 4S dispun de

aceasta facilitate, deci a trebuit sa facem testele cu Motorola RAZR.

Pentru a folosi acest nou terminal mobil a trebuit sa folosim si noua versiune a

pachetului de dezvoltare pentru Android - Motodev Studio ce include toate update-

urile pentru lucrul cu Bluetooth 4.0 (BLE/ULP/Wibree).


27

Datorita timpului foarte scurt avut la dispozitie si a problemelor de

compatibilitate software aparute la folosirea noii tehnologii am testat doar 4zile

obtinand rezultatele din tabelul de mai jos.

Figura.8 Analiza disponibilitate sistem

Folosirea noului telefon de la Motorola face posibila ca sistemul Bluetooth ver.

4.0 instalat in luna oct. 2011 pe modulul purtabil sa lucreze in parametri nominali si

majoritatea problemelor privind resursele energetice ale sistemului portabil se

simplifica dupa cum se vede din tabel. Imbunatatirea este absolut fenomenala,

practic autonomia sistemului s-a dublat desi conform calculelor ar fi trebuit sa

creasca doar cu 48%. Din analiza datelor colectate in scurtul timp avut la dispozitie a

rezultat ca rescrierea intregului protocol de comunicatii a permis reducerea drastica

a energiei necesare functionarii (in mod nativ BLE 4.0) nu numai pe partea de radio

(asa cum se calculase) ci si asupra numarului de cicluri de procesor necesare

generari pachetetelor de date radio. Reducerea numarului de cicluri procesor a

permis scaderea la 54% a resurselor energetice necesare functionarii modulului

purtabil.

Astfel unul din obiectivele principale al proiectului, un sistem purtabil cu o

independenta energetica care sa acopere o zi de activitate normala a fost rezolvat.

Caracteristicele tehnice ale Bluetooth 4.0 (ULP- Ultra Low Power) folosit in

noua configuratie sunt urmatoarele:

• 39 canale cu 2Mhz latime;


28

• Emisie in foarte scurte "burst-uri";

• raza de actiune 10m la 0dbi;

• Modulatie-FSK Gaussian cu BT=0.5;

• Facilitate de sleep mode pentru economisire energie;

• foloseste canale fixe pentru imperechere si detective dizpozitive noi;

• protocol optimizat for comunicatii de banda ingusta;

• numar redus de cicluri procesor si necesar de RAM mult scazut.

De specificat ca aceste date permit reconsiderarea solutiilor de comunicatii de

putere redusa pentru aplicatii medicale-majoritatea aplicatiilor medicale de

telemedicina pot folosi acesta tehnologie.Oricum experienta echipei noastre in acest

domeniu trebuie aprofundata pentru ca optimizarea softului dezvoltat de noi a fost

foarte sumara pentru lucrul cu Bluetooth ver.4.0

In aceste conditii celelalte tehnologii vor ramane incet, incet in afara zonei

medicale.Bluetooth ver.2.1 va pastra o pozitie dominanta datorita numarului urias de

echipamente care suporta standardul la ora acesta, insa din 2012 majoritatea

telefoanelor inteligente vor suporta BLE.

Noile module Bluetooth 4.0 sunt comparabile dimensional cu vechile module,

avand insa un alt mod de conectare, acest lucru asigurand un grad mai mare

integrare (vezi figura.9).

Figura.9 Module Bluetooth 4.0

Dotarea laboratorului de comunicatii de putere redusa cu kit-urile Zigbee a

ramas o referinta foarte utila in evaluarea lanturilor de comunicatii wireless ce includ


29

banda ISM mai ales cand, din diverse motive (mai ales suprapunerea diverselor

surse de semnal parazite in banda 2.4Ghz), apar probleme.

Concluzii:

Solutia noastra pentru comunicatiile dintre modulul purtabil este

Bluetooth 4.0 care asigura consum extrem de redus si permite functionarea

sistemului un timp considerabil mai lung datorita scaderii consumului si in

partea de terminal.


30

A1.5 Elaborare solutie achizitie date multicanal – finalizare (P6 – ELCOS)

Achizitia de date multi canal in cazul dispozitivelor purtabile este un subiect

delicat datorita limitariilor extreme de consum de putere si a restrictiilor dimensionale

implicate de notiunea de purtabilitate.Restrictiile de proiectare au modelat solutiile

noastre astfel incat la finalizarea proiectului s-a ajuns la urmatoarea arhitectura:

Figura.10 Schema interfata senzori

Pentru ca numarul de canale de masura este limitat dar mai ales din motive

de utilizare eficienta a resurselor energetice (folosirea a mai multor convertoare AD

creste semnificativ consumul sistemului am preferat sa utilizam multiplexarea pentru

semnalele care necesitau conversia pe 16bits. Pentru semnalele interne (tensiune

baterie si temperatura exterioara) modulului portabil am folosit convertoarele

analogic digitale pe 12bits, acest lucru permitand gestiunea informatiilor critice in

timp util si cu minim de resurse.

Pentru a putea compensa eventuale erori de pozitionare a senzorilor se vor

folosi doua solutii:


31

1. Referinta circulara - consta in efectuarea masuratorilor intre cei trei senzori

prin folosirea ca referinta a celorlalti doi senzori, in loc ca unul din senzori sa fie

considerat referinta.

2. Procedura de evaluare automata a coerentei masuratorilor - consta in

efectuarea de masuratori si compararea acestora cu mostre din memoria sistemului.

In cazul in care semnalele sunt iesite din plaja de valori se solicita repozitionarea

senzorilor.

Figura.11 Referinta circulara senzori

Senzorii ECG de tip e-textil au probleme inerente cu conexiunile, in conditiile

cand acestea trebuie sa asigure stabilitatea pe intreg lantul de masurare, de aceea

am testat multe solutii plecand de la conectoare de tip BNC pana la conectoare

SNB. Solutia finala pentru conector este o capsa metalica si care a fost tratata

chimic special pentru evitarea coroziunilor inerente care apar dupa spalarea centurii

sau de la transpiratie.

Obtinem astfel un contact sigur pentru o perioada mare de timp (una din

centurile de test a fost spalata in masina de spalat de 14 ori si inca este in plaja

normala de valori (important sa fie uscata rapid).

Figura.12 Centura test


32

Pentru a asigura contactul ferm pe o suprafata mare a materialului special, in

spatele acestuia este montata o umplutura de burete electroconductor

(1,6Ohmi/cm3). De mentionat ca banda elastica suport este un izolator si a fost

aleasa sa isi pastreze aceasta capacitate chiar si in cazul transpiratiei abundente

fiind puternic hidrofoba.

Determinarea suprafetei de contact (a cantitatii de material e-textil) pentru

fiecare senzor a reprezentat un element crucial, pentru ca nu exista referinte in

literatura stiintifica vizand acest aspect, in aceste conditii au fost efectuate teste de

dimensionare a suprafetei care a fost micsorata treptat pana cand suprafata ramasa

a inceput sa afecteze masuratorile in timpul miscarilor.

Penultima suprafata a fost considerata corecta si astfel, a fost dimensionat

fiecare electrod in parte.

In timpul testelor de dimensionare am constatat ca datorita diferentelor

anatomice trebuiesc efectuate dimensionari specifice fiecarui sex. Pentru o parte din

persoane este absolut necesar sa fie executate ajustari ale distantei intre senzorii.

Datorita limitarilor structurale ale sistemului bazat pe MSP430 este necesar

sa refolosim canalele de masurare pentru mai multe biosemnale.

Figura.13 Schema sistem purtabil si sisteme secundare


33

In figura de mai sus este aratata schema de baza a sistemului purtabil

impreuna cu sistemele secundare.Fata de varianta din figura 13, in versiunea finala

au aparut mici modificari la partea de interconectare dintre placa de baza si placa

secundara a modulului Bluetooth 4.0.De remarcat ca pentru fiecare varianta

constructiva a trebuit refacut PCB pentru ca exista diferente majore intre sistemele

de interconectare intre cele trei sisteme de comunicatii radio utilizate in decursul

dezvoltarii acestui proiect. Acest lucru a determinat si modul cum sunt utilizate

canalele de masurare si cum este folosita facilitatea MSP430 de a controla castigul

in canalul de masurare prin intermediul amplificatoarelor de programabile incluse in

chip.

Sistemul integrat al MSP430 de multiplexare multicanal utilizat in PCB ver.4.2

(ultima versiune realizata in cadrul acestui proiect) utilizeaza 4 canale diferentiale

care sunt conectate la senzorii externi.Datorita faptului ca raportul semnal zgomot

este foarte redus in cazul biosenzorilor, reproiectarea PCB din jurul MSP430 este

critica pentru prezervarea unor masuratori multi canal.Aceasta versiune este

prezentata in imaginea de mai jos.

Figura.14 Sistem MSP430

Concluzie:

Utilizarea unor sisteme de masura purtabile pe baza MSP430 este

posibila doar in conditiile in care proiectarea PCB-ului cuprinde tehnici

speciale de evitare a contaminarii cu zgomot a semnalelor utile datorita

raportului semnal zomot scazut specific.Pentru achizitia de date multe canal,

solutia noastra a fost folosirea unor trasee "izolatoare" de masa interpuse fata

de cele de semnal slab.


34

A2. Elaborare solutii de functionare a sistemului cu relee personale

GSM/GPRS

A2.1. Elaborare solutie generala a sistemului

Solutia generala de comunicatii vizeaza armonizarea interactiiunilor dintre

elementele constructive ale proiectului precum si intre diversele aspecte tehnice ale

lucrului cu echipe de specialisti cu prioritati diferite si culturi organizationale foarte

diverse. Daca pentru specialistii medicali importanta unei rezolutii cat mai mari era

evidenta, mai ales ca deja detineau aparate fixe cu rezolutii mari(16bits) si chiar mai

bune (ADC22bits), pentru specialistii care se luptau cu fiecare mA consumat, era

evident o cerinta aberanta in conditiile in care echipamentul trebuia sa se incadreze

in restrictii dimensionale si de greutate foarte stricte.

Acest sistem purtabil este clar un produs limitat de lipsa unei industrii de profil

care sa ofere suport tehnologic - a fost nevoie sa apelam la o colaborare cu o firma

din Bulgaria pentru a realiza un circuit imprimat si mai ales plantarea componentelor

SMD miniaturizate.Incercarile de plantare manuala in laboratorul nostru au generat

mai multe rezultate inestetice si mai ales nefiabile.

Daca obiectivele generale au ramas, solutiile prin care au fost atinse s-au

modificat de mai multe ori, de fiecare date obtinandu-se rezultate mai bune sau un

produs mai ieftin.

Figura. 15 Structura initiala sistem monitorizare pacient

Schema de mai sus reprezinta ideea de plecare din 2008 a proiectului si in

principiu, modelul experimental corespunde acestei idei (vezi figura 3 - structura


35

retelei de comunicatii de la A 1.1.4). Saltul tehnologic si constrangerile financiare au

generat solutii mai ieftine care permit cresterea evidenta a nivelului de

acceptabilitate a produsului de catre societate, acestea nefiind intodeauna si cele

mai bune solutii din punct de vedere tehnic.

De precizat ca dezvoltarea unei solutii de localizare duala (GPS/GPRS) de

catre Google-Android foarte apropiata de cea descrisa anterior (2008), de catre

echipa noastra la depunerea proiectului, este dovada ca avem un proiect in trendul

tehnologic chiar daca suportul financiar nu este comparabil.

Concluzie:

E-RISC - reprezinta un raspuns tehnologic la o problema umanitara si

economica - cum facem sa scadem costurile de spitalizare a bolnavilor cu risc

cardiac si cum reducem stresul si incomfortul acestora. Transferul in

ambulator reduce costurile si stresul, creste nivelul supravegherii medicale cu

mult peste limitele normale ( calculatoarele nu "obosesc" si nu serbeaza zile

onomastice) si asigura accesul la un diagnostician foarte specializat oriunde

se afla in realitate respectivul pacient.


36

A2.2. Elaborare solutie GSM GPRS (P3 – IPA si P6 – ELCOS)

Problemele de securizare si asigurare a legaturilor de date medicale prin

intermediul retelelor de telecomunicatii mobile GSM implica mai multe aspecte:

• disponibilitate;

• securitate;

• integritate.

Disponibilitatea este definita ca procentul din populatia tarii pentru care este

disponibil din punct de vedere fizic un anumit nivel de serviciu de telecomuncatii. La

data redactarii acestui material, aceasta era in medie de peste 90%. Disponibilitatea

este importanta pentru ca doar in zonele respective se poate deplasa pacientul care

foloseste E-RISC.

Securitatea datelor medicale este impuse de normele medicale EHR care

sunt definite la nivel european. Dupa mai multe iteratii de folosire a unei legaturi

criptate s-a stabilit ca modelul experimental va folosii doar o legatura "autentificata",

pentru ca operatorii de telefonie mobila nu pot asigura canale garantate decat in

marile aglomerari urbane. Cum majoritatea utilizatorilor E-RISC vor activa in afara

zonelor urbane am preferat sa raman la nivelul general acceptat de EHR (Electronic

Health Records).

Integritatea datelor care sunt schimbate prin intermediul retelei GSM este

puternic influentata de configuratia retelelor si de faptul ca trecerea de la o celula

GSM cu acoperire 3G la o celula vecina care dispune doar de acoperire GPRS

cauzeaza aparitia problemelor la integritatea unor pachete. Daca la voce acest lucru

se observa prin scurte deformari ale vocii, la nivelul datelor ECG acest lucru face

imposibila utilizarea acestora, aparand o "fereastra" in continuitatea inregistrarilor.

Concluzie:

Folosirea unei solutii mixte 3G/GPRS permite folosirea mai comoda a

sistemului mai ales in cladiri, unde semnalul 3G are propagare mai buna dar

trecerile de la o celula GSM cu 3G la o celula care dispune doar de GPRS

genereaza pierderi de pachete de date care nu sunt deocamdata recuperabile.


37

Testele finale au fost facute in reteaua Cosmote care declara urmatoarea

configuratie a acoperirii:

Figura 16 Acoperire retea Cosmote

Dupa cum se vede serviciul 3G este disponibil aproape exclusiv in orase,

acest lucru reducand in mod semnificativ posibilitatea produsului nostru sa

foloseasca acesta tehnologie.

Concluzie:

Pentru a asigura disponibilitatea dorita la inceputul proiectului trebuie

sa folosim doar GPRS. 3G este o tehnologie care se adreseaza momentan doar

zonei urbane.


38

A2.3. Elaborare solutie interconectare comunicatii (P4- INOE)

Interconectarea sistemelor a fost un element destul de greu de implementat

fara "bug-uri" in conditiile cand am schimbat de mai multe ori specificatiile sistemului

de comunicatii interne.Elementul principal in jurul caruia s-a construit sistemul de

comunicatii este urmatoarea structura a pachetului de date:

Figura.17 Structura pachet de date

Aceasta structura a ramas nealterata de schimbarile efectuate in decursul

ultimilor 2 ani si a permis interconectarea diverselor solutii intr-un mod transparent

pentru pachetele software aflate la DataCenter.Renuntarea la versiunea Zigbee a

eliminat aproape toate problemele de intercomunicare intre sisteme.Actuala solutie

integreaza BT4.0 cu suportul GPRS/3G. Solutia finala pentru modelul experimental

include doar doua punti suport :

• interconectarea modulului BT4.0 cu placa de baza a echipamentului purtabil

(SP);

• interconectarea senzoriilor cu placa de baza (SP).

In plus, interconectarea senzorului de deformare toracica (detecteaza

respiratia si masoara amplitudinea efortului respirator) in final se face tot prin

bluetooth pentru ca interconctarea fizica poate genera probleme insurmontabile (cu

actualul buget) la nivel practic.

Concluzii:

Interconectarea diverselor tehnologii de comunicatii s-a facut prin

prezervarea unui format de date stabilit in prima etapa si care a permis

gestiunea datelor impachetate in acest format in orice conditii.


39

A2.4. Elaborare solutie pentru modelul de comunicatii (P5 - INOE)

Modelul general de comunicatii este produsul a mai multor teste, efectuate pe

module functionale, efectuate cu mult inainte de executia modelului experimental,

pentru interactiunile dintre diversele componente genereaza puternice elemente

perturbatoare in functionarea corecta a sistemului. Se poate spune ca acest proiect

a generat mult mai multe probleme si solutii in zona comunicatiilor decat in zona

biosenzorilor si a postprocesarii medicale a datelor.

Solutiile finale pentru modelul experimental sunt urmatoarele:

1. Bluetooth ULP (Ultra Low Power)

2. GPRS -EDGE ( 3G este doar optional )

3. FO TCP-IP

Figura 18 Structura platformelor de comunicatii in proiectul E-RISC

Din figura 18 se poate observa ca acest model implica folosirea protocolului

TCP-IP deasupra tuturor sistemelor de comunicatii implicate in desfasurarea

proiectului. De mentionat ca solutia noastra nu functioneza pe Blackberry tocmai

datorita acestui model - RIM foloseste un sistem de accelerare a datelor care

deformeaza mult prea mult protocolul TCP-IP pentru a putea functiona in cazul

nostru.


40

Alte doua platforme care lucreaza cu sisteme de accelerare a browsingului

(Iphone si Samsung – BADA) nu pot folosi deocamdata acest produs.

Eventuala dezvoltare pentru Iphone a unei aplicatii echivalente presupune

modificarea acestui model care necesita ACK pentru fiecare pachet de date.

Sistemele de accelerare pentru aplicatii mobile comprima datele inainte de a le

trimite si in plus trimit pachetele de date fara a respecta cerinta expresa a TCP-IP

(verifica integritatea unui pachet de date si apoi sa trimita altul). Prin renuntarea la

acesta strategie se reduce traficul din retea - ACK se trimite pentru mai multe

pachete odata.

Concluzie:

Modelul de telecomunicatii se bazeaza pe protocolul TCP-IP standard,

care este suficient de cunoscut pentru a trebui sa fie explicat. Pentru orice alte

tipuri de SO decat Android, este necesar sa se dezvolte aplicatii specifice

odata cu produsul final.


41

A3. Proiectare model experimental

A3.1 Proiect general sistem; Proiectare sisteme senzori;Proiectare software comunicatii (CO-WING)

A3.1.1 Proiect general sistem

Proiectare legaturi

Informatia de la Subsistemul Purtabil la Subsistemul de Telecomunicatii este

transmisa prin intermediul semnalului GPRS / 3G la Baza GSM (serverele

operatorului GSM).

Legatura dintre operatorul GSM si serverele E-RISC (Subsistemul de

Prelucrare la Distanta prezent in DataCenter) este realizata prin intermediul fibrei

optice. Comunicatia intre elementele Subsistemului de Prelucrare la Distanta (server

stocare, server evenimente, switch management) este asigurata de asemenea prin

intermediul fibrei optice.

Subsistemul de Prelucrare la Distanta este compus din mai multe

componente si anume:

- Server comunicatii si autentificare;

- Subsistem prelucrare evenimente;

- Factor decisional;

- Switch management (utilizat pentru conectarea celor de mai sus);

- Echipamente de gestiune si securitate a comunicatilor: firewall, router.

Toate echipamentele vor fi sustinute de UPS-uri, cu posibilitatea de a trece

alimentarea pe generator, atunci cand alimentarea cu energie electrica este

intrerupta pentru durate mai mari de timp.

Pentru toate echipamentele este necesara o camera speciala, dotata cu

instalatie de aer conditionat, izolatie termica, accesul fiind permis doar personalului

autorizat.

Software general

Serverul decizional este alcatuit dintr-o interfata grafica, ce reuneste in

structura sa un modul de achizitie a datelor din baza de date MySql, un modul de

prelucrare in timp real a datelor si de semnalizare a problemelor aparute, precum si


42

un modul de prelucrari ulterioare a biosemnalelor obtinute (prelucrari offline). Pentru

realizarea acestui server decizional am utilizat mediul de dezvoltare Matlab,

versiunea 2011b.

Figura.19 Structura server decizional

Mediul de programare Matlab prezinta avantajul unei flexibilitati mari in

utilizare, datorita posibilitatii de conectare a mai multor functii si aplicatii intr-o

entitate unica.Platforma de monitorizare tehnica conceputa se bazeaza pe acest

principiu. Structura globala a softului, organizata sub forma unui panou central ce

apeleaza functii specializate pentru fiecare operatie in parte, permite adaptarea cu

usurinta a programului, modificarea parametrilor de functionare si imbunatatirea

acestuia prin adaugarea de functii suplimentare.

Platforma de monitorizare tehnica a fost dezvoltata pentru a centraliza datele

provenite din toate subsistemele componente ale structurii E-RISC.Aceasta prezinta

o fereastra principala, denumita consola de monitorizare tehnica, in cadrul careia

sunt monitorizate atat datele corespunzatoare pacientilor cat si datele principale de

functionare ale subsistemelor componente: Server prelucrare si analiza si Server

stocare.Interfata comunica in timp real cu serverele si ofera personalului tehnic

detalii despre parametrii cei mai importanti ai serverelor, precum utilizare CPU,

latime de banda si erori sau atentionari existente.Consola de monitorizare tehnica

prezinta de asemenea o lista cu pacientii ce sunt monitorizati si afiseaza starea de

sanatate curenta a acestora: pacient ok sau alerta pacient. Conexiunea cu serverele

se face prin intermediul unei baze de date cu mai multe tabele. Vom avea un tabel

pentru datele corespunzatoare fiecarui pacient, ce va fi populat cu date primite de la

subsistemul purtabil si inca un tabel cu datele oferite de servere. Vom inregistra la

un interval de timp predefinit datele corespunzatoare serverelor intr-un tabel din


43

baza de date. Aplicatia software va citi in permanenta datele din baza de date, atat

cele corespunzatoare pacientilor de monitorizat (mai des - la un interval de o

secunda) cat si cele corespunzatoare serverelor (mai rar – la un interval de 1 minut).

Am ales aceasta solutie constructiva deoarece este o solutie simpla si permite

totodata salvarea unui istoric al functionarii serverelor.


44

A3.1.2 Proiectare sisteme senzori

Sistemul de senzorii folosit in cadrul acestei versiuni finale ale modelului

functional-versiunea imbunatatita include urmatoarele elemente:

• senzori ECG;

• senzori miscare - accelerometre 3 axe;

• senzor deformare cutie toracica;

• senzor temperatura corp subiect.

Senzorii ECG sunt exteriori "Cutiei" si sunt cei mai supusi la zgomotul

exterior.In timpul testelor extinse nivelul de zgomot generat de mediu a fost un

element important mai ales ca acesta este de tip aditiv fiind exprimat astfel:

unde: (s) semnalul real, (n) semnalul parazit(zgomotul); (f) semnalul rezultat.

Acest zgomot este in general produs de dispozitive electrocasnice sau de

surse puternice radio ( in timpul testelor au fost masurate perturbatii puternice care

pe periade de aprox. 30sec. saturau amplificatoarele sistemului, prin apropierea de

un radar militar aflat pe soseaua Bucuresti -Giurgiu).Folosirea unor componente de

calitate si o proiectare atenta a permis realizarea unui model experimental care a

dovedit ca poate functiona in conditii normale de exploatare.

Rejectia digitala a zgomotului electric din mediu impreuna cu folosirea unor

proceduri speciale de proiectare prin care sistemul este protejat de perturbatiile EM

din mediu asigura functionarea sigura a sistemului chiar si in conditii de mediu

advers.

Concluzie:

Sistemele de senzori sunt proiectate sa functioneze in conditii

"normale" de lucru. Sunt necesare precautii speciale in zonele cu surse de

zgomot electric puternic. De asemenea echipamentul este sensibil la

dispozitive de tratament cu vibromasaj sau stimulare electrica a muschilor.


45

A3.1.3 Proiectare software comunicatii (CO-WING)

Software-ul folosit pentru comunicatiile din cadrul proiectului este structurat in

3 tipuri de legaturi:

Body AreaNetwork - Aplicatia ERISC ver.05 - dezvoltata sub Motodev Studio

(este un pachet personalizat de Motorola pe baza Eclipse) si Android SDK.Acesta

aplicatie asigura receptia, procesarea si trimiterea catre serverul de comunicatii aflat

la datacenter-ul din sediul Wing Computer Group srl. Pentru validarea comunicatiilor

la nivelul serverului de comunicatii de asemenea ruleaza un serviciu de certificare si

unul de autentificare cele doua aplicatii fiind scrise in C pentru ca serverele ruleaza

CERTOS - o versiune de Linux dezvoltata pe platforma RED HAT.

Cel mai important aspect al evolutiei aplicatiilor software care trateaza

comunicatiile, a fost trecerea intempestiva de la Eclipse, pe baza careia a fost

dezvoltata aplicatia ANDROID pentru HTC Desire, la o platforma derivata din

Eclipse dar care are si elemente de noutate special concepute pentru UI Motoblur si

pentru Bluetooth ULP vezi imaginea de mai jos.

Figura. 20 Dezvoltare aplicatie software

Aceasta evolutie a cauzat destule probleme mai ales datorita diferentelor

dintre modul cum sunt tratate optimizarile la nivelul procesoarelor noi.


46

Comunicatii 3G/GPRS - aplicatia Android gestioneaza si initierea

comunicatiilor cu serverul de comunicatii, asigura securitatea legaturii printr-un

protocol ce urmeaza sa fie dezvoltat ulterior.Modificarile la obiectivele definite la

startul proiectului au aparut dupa reducerea alocarilor bugetare.

Comunicatii incepand de la statia de baza GSM pana la Data Center care

asigura colocarea serverului de comunicatii precum si a serverului de analiza

medicala. Aplicatia de baza este insa in mod sigur software-ul dezvoltat pe platforma

Android care gestioneaza fluxul de date dintre SP (statia purtabila) si telefonul mobil.

Acesta aplicatie este scrisa in Java a necesitat foarte multe corectii in decursul

dezvoltarii proiectului, deoarece au fost modificate platformele suport de comunicatii,

de la Zigbee la Bluetooth si apoi la Bluetouth ULP (Ultra Low Power). Spre exemplu,

mai jos prezentam un extras din sursa programului E-RISC sub Motodev Studio:

@Override publicvoidonCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); /*trimitecerere la undispbt */ IntentFilter filter = newIntentFilter("android.bluetooth.device.action.PAIRING_REQUEST"); /*inregistreazaunnou device BT dupaimperechere*/ this.getApplicationContext().registerReceiver(newBTBroadcastReceiver(), filter); // inregistreazaunnoudispozitv BT la reveniredacaestedejaimperecheat IntentFilter filter2 = newIntentFilter("android.bluetooth.device.action.BOND_STATE_CHANGED"); this.getApplicationContext().registerReceiver(newBTBondReceiver(), filter2); //Obtaining the handle to act on the CONNECT button TextViewtv = (TextView) findViewById(R.id.labelStatusMsg); String ErrorText ="Nu suntconectat la CUTIE ! !"; tv.setText(ErrorText); Button btnConnect = (Button) findViewById(R.id.ButtonConnect); if (btnConnect != null) { btnConnect.setOnClickListener(newOnClickListener() { publicvoidonClick(View v) { String BhMacID = "00:07:80:9D:8A:E8"; //String BhMacID = "00:07:80:88:F6:BF"; adapter = BluetoothAdapter.getDefaultAdapter(); Set<BluetoothDevice>pairedDevices = adapter.getBondedDevices();


47

if (pairedDevices.size() > 0) { for (BluetoothDevice device : pairedDevices) { if (device.getName().startsWith("ERC")) { BluetoothDevicebtDevice = device; BhMacID = btDevice.getAddress(); break; } }

Concluzii:

Dezvoltarea de aplicatii Android sub Motodev Studio este un element

important in modul cum echipa noastra va rezolva pe mai departe diverse

aplicatii pentru BLE. Aparita BLE va permite in mod sigur explozia

dispozitivelor medicale purtabile mai ales ca incet, incet toate telefoanele

mobile vor fi dotate cu acest tip de interfata. Acest avantaj este major fata de

Zigbee care necesita in continuare interfete propietare pentru a interactiona cu

un smartphone.


48

A3.2 Proiectare achizitii date (P2 – UPB+P6-ELCOS)

Sistemul de senzorii folosit in cadrul acestei versiuni finale ale modelului

functional-versiune imbunatatita in mai multe etape, include urmatoarele elemente:

• senzori ECG

• senzori miscare - accelerometre 3 axe

• senzor deformare cutie toracica

• senzor temperatura corp subiect

Senzorii ECG sunt dispusi pe o centura elastica simpla pentru barbatii si o

centura elastica sustinuta si de o bretea pentru femei.In urma numeroaselor teste s-

a constat ca simpla centura elastica nu este suficienta (datorita particularitatiilor

anatomice) pentru ca folosirea unei centuri foarte stranse este incomoda de purtat o

perioada lunga de timp si 62% din pacienti afectati de probleme cardiace sunt femei.

Testele comparative rulate timp de 2 luni au aratat ca structura senzorilor

realizati de noi este net superioara celor comercializati in acest moment.

Figura.21 Solutie senzori purtabili

Faptul ca am interpus un substrat de burete conducator intre banda suport si

stratul e-textil permite reducerea drastica a artefactelor printr-un contact mult mai

bun, care poate prelua deformarile dinamice ale dermei fara sa ajunga la limita

minima de contact.


49

Acesta structura poate prelua deformari dinamice mult mai mari si permite un

grad mult mai mare de "purtabilitate". Buretele electroconductor are proprietatea de

a absorbi o parte din transpiratia generata de derma si a mentine contactul electric

si in plus nu mai permite alunecarea benzii elastice. Pentru celalalte solutii

constructive este nevoie sa fie crescuta forta de strangere a benzii elastice - lucru

care devine repede incomod pentru purtator.

De mentionat ca toate solutiile de mai sus pot fi spalate in masina de spalat si

asta este strict necesar pentru toate aceste sisteme de senzorii.

Senzorul de temperatura corporala este integrat in cutie si masoara

temperatura pe o suprafata de aprox. 12mm2 asigurata de capsa metalica care este

separata de derma doar de un strat subtire de material textil elastic. Datorita acestui

lucru, inertia masuratorilor este destul de mare (in media -1,4min/0C).

Senzorii de pozitie (accelerometrele 3D) permit cunoasterea pozitiei

pacientului si in plus daca se misca sau este in repaus.Acesti senzori sunt integrati

in cutie si sunt lipiti pe PCB.Datele normalizate sunt digitizate si citirea se face la

fiecare 0.5secunde.Obtinem astfel o corespondenta intre citirea ECG si activitatea

persoanei respective.

Concluzii:

Senzorii ECG imbunatatiti (prin adaugarea unui strat de burete

conductor sub e-textil) de echipa noastra au un comportament mult mai bun

cu derma uscata in conditiile unei activitati fizice ponderate asa cum au

pacienti nostri.Functionarea senzorilor de temperatura este stabila in noul

amplasament care permite "monolitizarea" intregului sistem.


50

A3.3 Proiectare automatizari (P3 – IPA)

Procesul de automatizare, in cazul sistemului E-RISC, consta in preluarea

continua a datelor, prelucrarea lor si semnalizarea aparitiei evenimentelor in timp

real, fara interventia operatorului uman.Produsul software conceput realizeaza

achizitia de date medicale de la pacient prin intermediul subsistemului purtabil,

transmiterea lor in timp real la baza de date, de unde vor fi preluate ulterior in

fereastra de lucru a aplicatiei software si prelucrate cu ajutorul Sistemului Decizional.

Proiectare rutina software medical detectie artefacte

Exista doua modalitati prin care sistemul E-RISC realizeza detectia

artefactelor:

- detectia software din semnalul ECG si care poate fi corectata prin procedee

specifice, asa cum se poate vedea la analiza in frecventa in cazul filtrarii semnalului;

- detectia hardware provenita din elemente obtinute dinspre subsistemul purtabil,

astfel de la:

- accelerometru pe 3 axe;

- detectie amplitudine respiratie.

Sistemul decizional a fost conceput astfel incat sa realizeze in mod automat

preluarea datelor din baza de date Mysql, prelucrarea lor si semnalizarea

evenimentelor. Aceasta versiune software realizeaza o rejectie automata a

artefactelor.Detectia artefactelor si eliminarea acestora se face pe baza studiului

datelor provenite de la subsistemul purtabil (accelerometru si amplitudine respiratie).

Aplicatia software stabileste o conexiune cu baza de date, care ramane deschisa pe

toata functionarea echipamentului, si preia date in timp real, pe masura inserarii lor

in tabela Mysql. Prelucrarea acestor date in vederea gasirii unui eveniment se

realizeaza conform schemei-bloc prezentata in figura urmatoare.


51

Figura. 22 Schema bloc functionare algoritm

Functionarea schemei bloc

La fiecare citire noua din baza de date, programul preia valorile inserate in

tabela si calculeaza parametrul RR.Valoarea parametrului RR reprezinta conditia

generala pentru validarea datelor si semnalizarea evenimentelor.Daca valoarea

primita pentru acest parametru se incadreaza in limitele prestabilite, programul

continua citirea noilor valori. In conditiile aparitiei unui RR ce nu se incadreaza in

plaja de valori, programul va verifica o conditie suplimentara, si anume starea

accelerometrului. Aceasta conditie suplimentara se impune datorita posibilei aparitii

a artefactelor. Daca accelerometrul indica o miscare brusca sau are o valoare peste

o limita prestabilita (pacientul este supus unui efort fizic), valoarea RR-ului va fi

considerata normala si se vor continua citirile. In cazul in care accelerometrul nu va

indica miscare, dar vom avea o valoare RR in afara limitelor, programul va genera

un semnal de alarma care va fi transmis in consola principala de monitorizare.


52

O metoda de a realiza prelucrarea datelor se poate face prin rejectia

automata a artefactelor la nivelul subsistemului purtabil. In acest caz, structura

algoritmului se schimba, in sensul ca vom avea o conditie unica de test, si anume

cea impusa pentru valoarea RR-urilor. Subsistemul purtabil va oferi in acest caz

numai valori valabile ale RR-ului.

Concluzii

Algoritmul conceput este integrat in cadrul unui ciclu repetitiv de tip

while, care permite rularea lui un timp infinit lung, fara a necesita opriri, altele

decat cele impuse strict de mentenata sistemului.

Deoarece produsul software dezvoltat are o structura organizata pe

functii specifice, poate fi imbunatatit ulterior, prin adaugarea unei functii de

alertare automata a echipajului de interventie medicala (ambulanta), in cazul in

care operatorul uman nu este prezent si nu poate lua o decizie in alertarea

echipajului medical.


53

A3.4 Proiectare canale legaturi (P4 – INOE)

Canalele de comunicatii folosite in cadrul versiuni finale ale acestui proiect

sunt urmatoarele:

• Bluetooth Ver.4.0;

• 3G/GPRS;

• FO link/LOS MIMO;

• FO link.

Vezi figura de mai jos:

Pacient Telefoninteligent

Statiebaza

HUBGSM

Spital

Bluetoothver. 4.0

HSPDAGPRS

FO linkLOS MIMO

FO Link

Figura.23 Structura sistem transmisie date

Intre echipamentul purtabil si cel portabil comunicatia este realizata prin noua

versiune Bluetooth Ultra Low Power si asigura protectia informatiilor prin legatura

criptata care este standard la aceasta versiune.

Transferul intre telefonul inteligent si statia de baza este realizat prin

intermediul standardelor de comunicatii mobile GSM (3G sau GPRS). Aceste

standarde in mod implicit asigura legaturi protejate dar nu in mod special (criptarea

legaturilor mobile creste necesarul de banda si in mod curent operatori de

telecomunicatii mobile renunta la acesta protectia daca o statie de baza este

supraincarcata). In versiunea initiala de dezvoltare era prevazuta dezvoltarea unui

protocol de protective usor (56 sau 128biti) dar dupa reducerea fondurilor am

considerat suficient sa solicitam operatorului GSM protectia explicita a legaturilor de

date implicate in proiect.Legaturile dintre statia de baza si HUB GSM precum si intre

HUB si Spital sunt realizate in mod curent prin fibra optica, sporadic aceasta este

suplinita de legaturi radio in domeniul microundelor de tip (LOS MIMO) in banda

24GHz.


54

Concluzie

Asigurarea securitatii legaturilor de date implicate in proiect poate fi

facuta la un nivel rezonabil prin proiectarea atenta a modului cum sunt validate

pachetele de date si prin utilizarea resurselor de securitate si de bune practici

din acest domeniu.


55

A4. Realizare hardware si software

A4.1 Realizare globala sistem; Realizare software global (CO-WING)

A4.1.1 Realizare globala sistem

Sistemul E-RISC este un sistem complex care implica sisteme multiple de

comunicatii, platforme software si hardware dedicate, sisteme de biosenzori si

sisteme MEMS pentru determinarea pozitiei pacientului.

Figura. 24 Structura proiect E-RISC

Interactiunile dintre diversele module globale ale sistemului sunt prezentate

in figura 24.

Se observa ca aceste platforme intereactioneaza intre anumite limite, definite

de functionalitatiile specifice precum si de masurile de siguranta necesare unei

solutii medicale ce va fi utilizata direct de pacientii.

Principala problema a sistemului nostru este faptul ca va fi utilizat de

persoane avizate (pacienti instruiti anterior) dar care nefiind profesionisti pot


56

manevra gresit sistemul care poate trimite date incorecte. Rezolvarea acestei

probleme a fost cheia de bolta a proiectului. Modalitatea de determinare a pozitei

corecte a senzorilor a permis functionarea, departe de privirea si mana

profesionistului, unui aparat ECG de nivel medical.

Elementul principal al sistemului este modulul purtabil care se "monteaza” cu

ajutorul unei barete elasitice pe torsul pacientului in contact direct cu derma. In

aceste conditii, sistemul trebuie sa indeplineasca caracteristici speciale, fiind inclus

in categoria dispozitivelor medicale.

Produsul final va trebui astfel sa poata fi igenizat si sa corespunda unor

norme foarte stricte de electrosecuritate si de dozare a radiatiilor electromagnetice

emise de sistem, pentru ca va functiona perioade foarte indelungate de timp lipit de

corpul persoanei respective.

Datorita normelor de siguranta impotriva radiatiilor a fost preferata solutia cu o

statie terminala (smartphone) in rol de releu intermediar, acesta fiind in masura sa

emita cu puteri de 200 ori mai mari decat sistemul purtabil. Se asigura astfel o

protectie eficienta la radiatia electromagnetica de foarte inalta frecventa.

Sistemul realizat sub forma unui model experimental modular in anul 2011 a

permis testarea in regim total incepand cu luna octombrie cand a fost achizitionat

ultimul element din sistem - primul telefon cu Bluetooth 4.0 si sistem de operare

Android 4.0.

Concluzii:

Realizarea unui sistem complex care implica o multitudine de tehnologii

si cooperarea unui important grup de persoane poate fi blocata de o problema

netehnica ( lipsa educatiei si a experientei medicale a celui care trebuie sa

monteze zilnic senzorii). Solutia a fost dezvoltarea unei noi tehnici de

evaluarea a semnalelor ECG si astfel a pozitionarii senzorilor.

Alternativa era tatuarea pe piele unor semne unde trebuiau pusi

electrozi.


57

A4.1.2 Realizare software global

Realizarea softului specializat pentru monitorizare s-a facut respectand

urmatorii pasi:

1. crearea de functii simple pentru fiecare procedura (preluare date din baza de date,

preluare parametrii servere, analiza date in timp real, transformata Fourier,

transformata Wavelet, evaluare interactiuni etc.)

2. stabilire interconexiuni intre functii : stabilire variabile globale program, apelarea

functiilor una de catre alta, dependenta executarii unei proceduri in functie de

rezultatul alteia

3. inglobare functii intr-o structura de tip GUI (Graphical User Interface), utilizand

toolbox-ul GUIDE (Graphical User Interface Development Environment) din mediul

de programare Matlab.

Figura.25 Programare grafica a interfetei utilizand modulul GUIDE

Platforma de monitorizare tehnica centralizeaza datele provenite din toate

subsistemele componente ale structurii E-RISC.Structura fereastrei principale,

denumita consola de monitorizare tehnica, este reprezentata in figura urmatoare.


58

Figura. 26 Consola monitorizare tehnica E-RISC

In cazul aparitiei unui eveniment, atat in ceea ce priveste structura software/

hardware a subsistemelor componente, cat si in cazul starii de sanatate a unui

pacient, consola de monitorizare va afisa un avertisment conform cu tipul problemei

aparute. Pentru investigatii amanuntite, fiecare subsistem va fi prevazut cu o consola

de management proprie in care vor fi furnizate informatii suplimentare.In cazul

aparitiei unui eveniment medical vom deschide consola de management aferenta

pacientului afectat, in care vom putea evalua starea pacientului in timp real. In

aceasta noua fereastra vom avea acces la datele particulare ale pacientului, precum

varsta, antecedente medicale, Patternuri Deplasari, dar si la date actualizate in timp

real legate de starea actuala a pacientului: puls, respiratie, viteza de deplasare,

eveniment in acceleratie fizica precum si o localizare pe harta a pacientului pentru a

facilita o interventie rapida in caz de necesitate.

Consola de management aferenta starii pacientilor este o fereastra specifica,

reprezentand frontend-ul principal al personalului medical. Fiecare operator se

logheaza si ii este atribuit in mod automat, de catre infrastructura, un eveniment aflat

in curs. In aceasta consola se prezinta detalii despre originea evenimentului,

parametrii sistemului de achizite, scoring-ul dat de sistemele de analiza si prelucrare

din infrastructura si informatiile medicale aferente evenimentului.


59

Figura. 27 Consola management pacient

Consola de management pacient permite atat vizualizarea prelucrarilor in timp

real (prelucrari online) cat si a prelucrarilor offline. Operatorul are posibilitatea de a

vedea semnalul prelucrat folosind butoanele pentru Transformata Fourier &

Transformata Wavelet, Evaluare interactiuni si Filtrare multidimensionala.Interfata

ofera, de asemenea, si posibilitatea de a vedea istoricul pacientului si Patternul

Deplasarilor.

Consola ofera trei actiuni posibile operatorului:

a) Urgenta medicala: acest eveniment este catalogat drept o urgenta si este

alertat personalul mobil de interventie. In acest caz se trimit automat date

despre eveniment personalului delegat cat si locatia de la care s-a generat

evenimentul, sau o aproximare a acesteia in cazul in care nu exista o locatie

precisa.

b) Trimite spre investigare suplimentara: in acest caz, operatorul nu considera

evenimentul apt pentru o interventie imediata, dar se doreste analizarea

suplimentara a acestuia si il trimite unui medic specialist.


60

c) Evenimentul nu este o urgenta si a fost generat datorita unor alti factori.

Descriere algoritm program

La baza realizarii acestei interfete grafice sta un program ce permite

preluarea datelor, testarea lor si apoi prelucrarea semnalelor obtinute in timp real.

Datele sunt citite din baza de date pas cu pas, pe masura inregistrarii in baza de

date. Fiecare linie preluata din baza de date este testata si prelucrata individual.

Pasii de desfasurare a algoritmului pentru preluarea si testarea datelor in timp

real sunt urmatorii:

1. Stabilire conexiune cu baza de date MySql;

2. Preluare date;

3. Testare date;

4. Construire vector de date valide;

5. Adaugare linie noua in matricea de prelucrare;

6. Testare matrice – semnalare aparitie eveniment;

7. Reprezentare graphic.

Pentru prelucrarea biosemnalelor exista algoritmi independenti ce se aplica

setului de date obtinut anterior. Prelucrarile biosemnalelor sunt prelucrari de tip off-

line, ce necesita stabilirea unui numar de parametrii suplimentari si sunt realizate pe

un set de date bine definit.

Functionalitate algoritm

Softul dedicat al subsitemului purtabil, pentru achizitia directa a datelor de la

pacient, ofera un set de date ce sunt trimise catre baza de date si preluate ulterior in

fereastra de lucru Matlab. Rolul pachetului software Matlab este de a prelucra datele

obtinute si de a genera o interfata pentru monitorizarea in timp real a

pacientilor.Asupra datelor obtinute se aplica diverse corectii pentru a putea fi utilizate

ulterior. Programul realizeaza corectii asupra urmatoarelor categorii de date: data de

inregistrare, valoarea parametrului RR si valoarea parametrului „heart beat number”

– corespunzator unei batai a inimii. Deoarece data de inregistrare oferita de

dispozitivul de monitorizare este exprimata in milisecunde, incepand cu anul 1970,

trebuie aplicata o corectie asupra acestei date pentru a putea permite o repezentare


61

relevanta a datelor pe grafic.Un alt parametru important este RR-ul. Acest parametru

nu este furnizat in mod explicit de catre subsistemul purtabil, dar se poate obtine ca

o diferenta de timp intre doua inregistrari „heart beat time”. Subsistemul purtabil

ofera la fiecare inregistrare in baza de date un numar de 16 valori ale „heart beat

time”, astfel putem obtine la orice moment de timp ultimele 15 RR-uri inregistrate

anterior. O problema a dispozitivului o reprezinta lipsa unor valori ale „heart beat

number” din tabela de inregistrari. Acest parametru este util in calcularea RR-urilor

succesive.

Exemplu date oferite de dispozitivul purtabil:

Vector pentru header:

„version,dateTime,serial,stx,msgId,dlc,firmwareId,firmwareVersion,hardWareId,hard

wareVersion,batteryIndicator,heartRate,heartBeatNumber,hbTime1,hbTime2,hbTime

3,hbTime4,hbTime5,hbTime6,hbTime7,hbTime8,hbTime9,hbTime10,hbTime11,hbTi

me12,hbTime13,hbTime14,hbTime15,reserved1,reserved2,reserved3,distance,spee

d,strides,reserved4,reserved5,crc,etx,hasLocation,locationAccuracy,locationAltitude,l

ocationBearing,locationLatitude,locationLongitude,locationProvider,locationSpeed,lo

cationTime”

Vector de date:

„2,1322222078373,1,2,38,55,26,26161,80,25649,100,102,74,16065,15477,14889,14

317,13729,13141,12565,11989,11405,10829,10257,9673,9085,8497,7905,0,0,0,16,

356,28,0,960,-115,3,true,2713.0,0.0,0.0,43.8948545,25.9941276,network,0.0,

1322212992334”

Pe baza acestor consideratii, am dezvoltat un algoritm de calcul ce permite

obtinerea unui set de date complet si corespunzator fiecarui moment de timp.

Prima parte a programului reprezinta o intializare a datelor medicale.Pentru

fiecare pacient in parte vor fi definite datele particulare: valorile pentru RR maxim,

RR minim, diferenta minima intre 2 RR-uri si diferenta maxima intre 2 RR-uri. Pe

baza acestor date se vor stabili conditiile de declansare a alarmei, in caz de

eveniment. Tot aici vor fi initializate si variabilele de lucru ale programului, precum


62

punctul de pornire a citirilor din baza de date (daca dorim citirea valorilor anterioare

sau incepand cu momentul actual de timp), timpul de asteptare intre 2 citiri

succesive de date etc.

Figura.28 Initializare date pacient

Dupa stabilirea caracteristicilor particulare pentru fiecare pacient, programul

se va conecta la baza de date MySql pentru a prelua datele in vederea prelucrarii

lor.Programul realizeaza conexiunea cu baza de date printr-un connector de tip java

(mysql-connector-java-5.1.13-bin). Dupa conectarea la baza de date, in program

este inclusa o subrutina pentru a verifica statutul conexiunii.Conexiunea poate fi

disponibila sau indisponibila (datorita unor cauze tehnice – defectiune server, lipsa

conexiune internet etc.). Starea conexiunii este utila in semnalizarea unor avarii ce

pot aparea independent de functionarea programului.

Inainte de inceperea citirii propriu-zise din baza de date, vom prelua prima

valoare inregistrata si vom stabili un punct de plecare, o intializare a datelor. Acest


63

pas este necesar deoarece programul realizeaza o diferenta intre 2 inregistrari

succesive, pentru validarea datelor si obtinerea unui RR corespunzator.

Dupa incheierea etapei de initializare a tuturor datelor, avem un ciclu repetitiv

de tip while care se va executa continuu, pentru o monitorizare permanenta a

datelor. Acest ciclu va contine urmatoarele etape:

a. verificarea liniei nou adaugate in baza de date;

b. verificarea elementelor de pe linia nou adaugata si prelucrarea lor;

c. compunerea vectorului ce urmeaza a fi inserat in matricea de analiza;

d. actualizarea matricei de analiza si testarea aparitiei evenimentelor;

e. afisarea graficului actualizat cu ultimele valori.

Programul este setat sa permita o pauza intre citiri succesive din baza de

date. Aceasta pauza este setata „by default” cu valoarea de o secunda. Pauza este

necesara pentru a asigura un timp suficient pentru achizitia datelor si inregistrarea

valorilor in baza de date.

a. Verificarea liniei nou adaugate in baza de date

Aceasta procedura se realizeaza pentru a ne asigura ca nu vom citi o linie

fara elemente sau cu elemente nule.In cazul in care aceasta conditie nu este

indeplinita, programul se opreste si asteapta inserarea unei valori noi in baza de

date. Aceasta conditie este utila in cazul opririi transmisiei de date si reluarii acesteia

dupa un anumit interval de timp. Programul verifica continuu, la un interval de timp

prestabilit, daca s-au adaugat valori noi in baza de date, iar odata cu inserarea unei

noi valori, se va relua ciclul.

b. Verificarea elementelor de pe linia nou adaugata si prelucrarea lor

La citirea unei linii noi din baza de date, inainte de inserarea acesteia in

matricea de prelucrare vom efectua cateva teste pentru a ne asigura ca datele

furnizate sunt valabile. Primul test care se va realiza este acela pentru „heart beat

number”. Acest parametru reprezinta numarul aferent al unei batai a inimii.

Parametrul reprezinta un indicator pentru obtinerea de valori consecutive ale RR-


64

ului. In cazul in care se observa lipsa unei valori a „heart beat number”, vom cauta

valoarea RR-ului pe una dintre coloanele urmatoare.

Figura de mai jos reprezinta un exemplu de date brute provenite de la

subsistemul purtabil. Putem observa pe coloana heartBeat aferenta parametrului

„heart beat number”, lipsa valorii 148. Pentru aceasta valoare, vom avea inserat in

linia elementului 149 un timp suplimentar „heart beat time”, in functie de care vom

putea calcula RR-ul corespunzator valorii cu numarul 148. Deci, la citirea din baza

de date a liniei ce contine bataia inimii cu numarul 149, vom introduce in matricea de

analiza 2 linii, cu elementele corespunzatoare valorilor 148 si 149.

Figura.29 Modul de inregistrare a datelor de catre subsistemul portabil

Analog vom proceda si in cazul unei diferente mai mari intre date. Diferenta

intre 2 valori ale parametrului „heart beat number” ne indica numarul de valori

consecutive ale RR-ului ce lipsesc si trebuie recuperate din coloanele suplimentare.

c. Compunerea vectorului ce urmeaza a fi inserat in matricea de analiza

Deoarece in baza de date MySql avem un numar mare de date ce nu sunt

necesare, vom insera in matricea de analiza doar datele direct prelucrate. Si anume,

vom calcula pentru fiecare inregistrare valoarea RR-ului si nu vom mai introduce in

matricea de analiza cele 16 coloane pentru „heart beat time”. In cazul lipsei unei

valori a parametrului „heart beat number”, vom insera simultan cele 2 valori primite


65

sub forma a 2 vectori.Analog vom proceda si in cazul in care vom semnala 3 sau mai

multe valori lipsa.

d. Actualizarea matricei de analiza si testarea aparitiei evenimentelor

La acest pas al algoritmului, programul apeleaza o subrutina ce actualizeaza

matricea de parcurgere a bazei de date. Dupa obtinerea matricei actualizate la pasul

„i” corespunzator ciclului, pentru acest pas se va testa aparitia evenimentelor, pe

baza valorilor stabilite pentru declansare alarma. Daca se va sesiza aparitia unei

nereguli, se va trimite un semnal de avertisment spre consola de monitorizate

tehnica, de aici urmand ca personalul tehnic sa distribuie evenimentul pentru studiu

unui operator.

e. Afisarea graficului actualizat cu ultimele valori

Afisarea graficului se va realiza in consola de management, numai in

momentul in care aceasta va fi activa pentru studiul unui pacient. Matricea de

parcurgere a datelor va avea o dimensiune corespunzatoare ultimelor 10 minute si

se va actualiza in timp real. Graficul realizat va introduce mereu ultima valoare si

simultan o va sterge pe prima. Actualizarea graficului se face in timp real, odata cu

inserarea de noi elemente.

Figura.30 Reprezentare in timp real a valorilor pentru parametrul RR


66

Prelucrari offline ale semnalelor – Software medical

Programul software permite realizarea de prelucrari suplimentare ale

semnalelor obtinute.Aceste prelucrari se pot realiza cu ajutorul optiunilor prezente in

consola de management pacient.In aceasta consola de management avem

urmatoarele optiuni:

1. Transformata Fourier & Transformata Wavelet;

2. Evaluare interactiuni;

3. Filtrare multidimensional.

Concluzii

Softul specializat dezvoltat permite atat o preluare in timp real a datelor,

cat si o prelucrare in timp real a acestora. In realizarea acestui obiectiv, un rol

important l-a avut utilizarea conceptului de matrice dinamica.Aceasta a permis

studiul unei ferestre de timp, actualizata cu fiecare inregistrare nou citita, si

prelucrarea in timp real a datelor precum si realizarea unei functii FFT in timp

real.


67

A4.2 Realizare elemente de testare medicala (P1 – SCUB)

Deoarece aceste analize suplimentare ale semnalelor necesita definirea unor

parametrii specifici, vor fi efectuate offline. La apasarea butoanelor corespunzatoare

acestor prelucrari, softul va genera fisiere cu valorile inregistrate in minutele

anterioare apasarii butonului. Aceste fisiere generate de catre software, vor contine

un numar de date suficient de mare pentru a putea realiza o analiza concludenta.

Lungimea acestor fisiere depinde de perioada de timp pentru care dorim sa

efectuam analiza (spre exemplu, dorim o analiza pentru ultimele 10 minute). Durata

de timp reprezinta un parametru ce se va configura la initierea functionarii

programului.

1.Transformata Fourier & Transformata Wavelet

Rularea programului lansat din interfata generala va avea urmatoarele etape: Etapa 1: Constituirea transformatei Wavelet in 10 voci pe octava incepand cu semnalul original:

Figura.31 Constituire Wavelet din RR - ECG–Semnal original J= 5 octave;M=10 voci

Figura. 32 Voce in desfasurare cu cele 5 octave


68

Etapa 2. Constituirea transformatei Fourier din seria RR

Figura. 33 Transformata Fourier

Etapa 3. Constituirea transformatei Wavelet din seria RR in 256 nuante gri

Figura. 34 Exemplu Transformata Wavelet 3D realizata in 256 nuante de gri

2. Evaluare interactiuni

Programul de evaluare interactiuni a fost conceput pentru o analiza complexa a

matricei wavelet.

In acest sens se pot evalua:

- Interactiuni in benzile de frecventa LF-VLF si LF-HF;

- Calcul maxim absolut a magnitudinii;

- Functii de filtrare selectiva a magnitunii;

- Detectie „eveniment unic”.

Detectia evenimentului unic este vitala in urmatoarele cazuri:


69

- Evenimentul unic apare in momentul in care interactiunea intre benzile de

frecventa proprii ECG depasesc un anumit nivel critic. Este atunci susceptibila

prezenta artefactelor in sistem, fapt care ne duce sa verificam buna functionarea

a intregului lant de detectie a artefactelor. Altfel spus, folosim „Evenimentul Unic”

ca mijloc de calibrare a sistemului de detectie artefacte.

- Validarea amplasarii corecte a senzorilor. Este astfel folosit ca mijloc de reglare

critica pentru “inidicele relativ de diferenţiere” (scoring) între înregistrarea curentă

(la momentul k) şi cea iniţială (la momentul 0).

3. Filtrare multidimensionala

Acest tip de filtrare realizeaza evaluarea nivelului de zgomot din semnal

functie de zona acestuia.Filtrarea digitala este realizata in SP (subsistemul purtabil)

este permisiva datorita resurselor energetice si de procesare reduse la nivelul

acestuia. In plus multitudinea fenomenelor care pot cauza unui sistem purtabil o

interferenta in semnalul util face ca o evaluare a nivelului de zgomot din semnal in

zona subsistemului de prelucrare la distanta, sa fie necesara.

Scopul acestei post-procesari este de a evalua:

- Daca este necesar aplicare unui filtru post-procesare;

- Ce tip de filtru trebuie aplicat (daca este necesar);

- Ce parametrii trebuie sa aiba acest filtru.

Secventa de programare Matlab:

[x2,x1,x3] = ndgrid(6:14,40:55,1:4);

slice(x1,x2,x3,S,[45,50],14,[2,4]);

Nivelul de zgomot din semnal se face pe o scala de culoare.

Dificultati aparute

La realizarea structurii software pentru prelucrarea in timp real a datelor,

dificultatea majora aparuta a fost data de structura datelor provenite de la


70

subsistemul purtabil – SP. Configurarea softului de achizitie si prelucrare date a fost

realizata astfel incat sa acopere toate situatiile posibile pentru inscrierea datelor in

baza de date MySQL.

Astfel, in timpul functionarii normale a dispozitivului SP, putem intalnii

urmatoarele situatii:

-lipsa uneia sau a mai multor valori a parametrului „heart beat number”;

-dublarea sau inregistrarea multipla a unei valori a parametrului „heart beat number”,

insotita de lipsa datelor din momentul dublarii;

-oprirea dispozitivului SP si aparitia unei diferente mari de timp intre inregistrari;

- inregistrarea unui eveniment unic – cauzat de plasarea necorespunzatoare a

senzorilor;

- inregistrarea de valori eronate in baza de date – format necorespunzator al datelor.

Produsul software dezvoltat a fost configurat pentru a trata corespunzator

toate aceste nereguli aparute in inregistrarea datelor, semnalizand astfel problemele

legate strict de anomalii ale semnalului RR provenit de la pacient si nu erori cauzate

de modul de intregistrare al subsistemului purtabil.

Concluzii

O etapa importanta in instalarea sistemului E-RISC o reprezinta

calibrarea produsului software.Aceasta etapa presupune setarea unor

parametrii specifici fiecarui pacient in parte, pe baza istoricului medical.

Solutia software propusa este puternic personalizata pentru caracteristicile

specifice fiecarui pacient.


71

A4.3 Realizarea automatizarilor (P3 – IPA)

Procesul de automatizare consta in trei etape:

- Realizarea citirii automate din baza de date;

- Rejectia automata a artefactelor;

- Alarmarea automata pentru aparitia unui eveniment.

Pentru prima etapa s-a utilizat un ciclu de tip while conditionat specific, astfel

incat sistemul sa preia informatiile din baza de date MySQL, de indata ce acestea

sunt inscrise. Ciclul este configurat pentru a retine ultima linie care a fost preluata din

baza de date si a cere linia urmatoare pana ce aceasta va fi primita.

Realizarea rejectiei automate s-a facut pe baza functiei Matlab descrise

anterior, in paragraful A4.1.2.In figura de mai jos este prezentata functia ce sta la

baza semnalizarii evenimentelor. Programul va testa fiecare valoare RR primita

pentru a stabili daca se incadreaza in limitele normale, specificate pentru fiecare

pacient la initializarea programului.

Figura. 35 Functie Matlab pentru semnalizarea automata a aparitiei evenimentelor


72

A4.4 Realizarea structurilor de comunicatie si software aferent (P4 –

INOE, P5 – IOEL)

Realizare structuri de comunicatie : Fibra optica

Pentru a asigura redundanta legaturii dintre operatorul GSM si serverele E-

RISC, se utilizeaza 2 legaturi, asigurate de doua trasee de fibra optica distincte.

Fibra optica a fost aleasa din cauza securitatii sporite pe care aceasta o ofera

in raport cu perturbatiile electromagnetice si eventualale tentative de brese in

securitatea sistemului. Cele doua fibre optice vor fi legate printr-o conexiune BGP

care va realiza trecerea in mod automat, in caz de avarie, pe una din legaturile

existente.

Solutia adoptata

Legatura intre sediul din Strada Blandesti si cel de pe Calea Vacaresti s-a

facut utilizand traseul de metrou intre statiile Piata Sudului si Aparatorii Patriei,

backup-ul fiind asigurat de un al 2-lea traseu ocolitor al lacului Vacaresti (zona Vitan

- Barzesti).

Ambele legaturi sunt conectate in regim redundant, timpul de comutare intre

fibre ajungand la maxim 3 secunde.Acest lucru este asigurat prin utilizarea

protocolului BGP, rulat de echipamente dedicate produse de CISCO Systems, aflate

in cele doua locatii.

Firewall: se afla plasat inaintea Serverului de Comunicatii si Autentificare si

este punctul de legatura intre reteaua interna E-RISC si exterior.

Acesta restrictioneaza accesul dinspre reteaua de Internet spre SPD, avand

grija sa permita traficul nestingherit intre ST si SPD.In acelasi timp monitorizeaza

conexiunile interne spre exterior. Toate informatiile sunt stocate in log-uri ce pot fi

agregate alaturi de cele generate de celelalte echipamente, intr-un punct central al

retelei pentru un manangement eficient.

Firewall-ul detecteaza orice incercare de intruziune din exterior si

semnalizeaza administratorului de retea evenimentele, putand sa blocheze sursa

atacurilor in scenarii predefinite.


73

Router-ul: este dispozitivul prin intermediul caruia se face conexiunea la

internet a Subsistemului de Prelucrare la Distanta, si implicit la Subsistemul de

Transmitere.

In configuratia utilizata in implementarea E-RISC, router-ul indeplineste 2

roluri:

- Comutarea legaturii la internet de pe fibra principala pe cea secundara in cazul

intreruperii comunicatiei

- Asigurarea accesului la internet pentru Subsistmul de Prelucrare la Distanta. In

acest caz router-ul are rolul de “gateway” (pasarela). Un gateway asigura

interfatarea mai multor noduri de retea utilizand protocoale diferite, si poate

opera la orice nivel de retea.

Peeringul BGP se va realiza utilizand numere AS private, deoarece nu este

necesar sa fie vizibil in internet. De asemenea, legaturile acestea vor fi monitorizate

si orice eveniment va fi logat. Se va utiliza suita de programe Quagga, versiunea de

Linux, pentru a asigura conectivitatea BGP. Deoarece nu va fi nevoie de load

balancing nu se va solicita decat ruta default de la partenerul de trafic.

Serverul de Comunicatii si Autentificare: face legatura intre subsistemul de

prelucrare la distanta si Subsistemul de Telecomunicatii.

Functiile de criptare PKI cu care au fost semnate pachetele de date trimise de

ST catre serverele E-RISC ruleaza si pe Serverul de Autentificare, fiind primul

proces care intervine asupra datelor primite si asigura certificarea integritatii datelor

precum si originea certa a acestora.

Mentionam ca stringurile de tip private KEY sunt preprogramate de echipa

tehnica in subsistemul ST si in Serverul de Comunicatii si Autentificare – solutia

aleasa de echipa tehnica este aceea cu chei asimetrice de tip cheie publica-cheie

privata.Evidenta acestora precum si o autoritate de certificare interna CA, ruleaza pe

Serverul de Comunicatii si Autentificare nefiind necesar accesul la o alta autoritate

exterioara sistemului, in conditiile in care reteaua de comunicatii ruleaza ca o retea

privata fara acces la internet sau la surse externe de certificare.


74

Pachetul software de autentificare dispune in plus si de o lista de MAC-uri

valide pe baza carora raspund sau nu pachetele de date primite, astfel incat, chiar si

daca reteaua operatorului GSM este compromisa, sa existe o functie suplimentara

de gestiune a actorilor din reteaua privata de tip VLAN implementata la nivelul retelei

operatorului GSM.In concluzie pachetele de software de gestiune procese de

comunicatii asigura securitatea comunicatiilor si in plus coopereaza la autentificarea

corespondentilor.

Figura.36 Rack servere

Toate echipamentele sunt conectate la sisteme UPS, pentru a preveni

intreruperea functionarii in timpul caderilor de tensiune.Durata de functionare pe


75

baza UPS-urilor este de 8 ore. Pentru o durata mai mare de 8 ore se utilizeaza un

generator.

Fig.37 Baterie UPS-uri

Switch management 1Gb – FO

Suporta: consola CLI, Telnet, web, SNMPv1/v2/v3, RMON, TFTP, Port

Mirroring, BootP, and DHCP. De asemenea suporta o varietate de optiuni de

management de trafic: 802.1x, Bandwidth Control, Broadcast Storm Control, etc.

Switch-ul de management cuprinde 24 de porturi de fibra optica, permitand

extinderea cu usurinta a echipamentelor ce pot fi conectate (servere aditionale,

echipamente de backup, etc).

Fig.38 Switch fibra optica


76

Serverul de stocare,Serverul de Anamneza pacienti, Serverul de Pattern

Deplasari si Serverul de Localizare GPS, au fost toate comasate intr-un singur

server fizic.

Serverul fizic ruleaza un sistem de operare bazat pe Linux, impreuna cu

serverul de baze de date MySQL.

S-a optat pentru utilizarea MySQL deoarece este cel mai popular SGBD

open-source la ora actuala.

MySQL este un sistem de gestiune a bazelor de date relational, produs de

compania suedeza MySQL AB si distribuit sub Licenta Publica Generala GNU.

Am ales MySQL deoarece:

- Este scalabil si flexibil. Bazele de date pot ocupa mai multi terabiti de

informatie, iar accesul la aceste baze de date se poate face de pe o

varietate de platforme de programare si sisteme de operare;

- Performanta : indiferent daca este vorba despre un numar mare de date

sau de un numar mare de operatii, MySQL dispune de numeroase

mecanisme ce asigura rezultatul dorit intr-un timp foarte mic;

- Disponibilitate : bazele de date pot functiona in regimuri master-slave, se

pot replica, pot fi utilizate intr-un cluster;

- Securitate: mecanisme de acces securizat la bazele de date, arhitectura

bazata pe useri si drepturi.

Fig. 39 Structura unui tabel din baza de date MySQL


77

Structura de Anamneza Pacienti consta in date privind istoricul medical al

fiecarui pacient: fise pacienti si valorie medicale standard ce vor fi comparate cu

citirile transmise de la ST.

Structura de Patternuri Deplasari - contine istoricul de deplasari

(coordonate GPS) si modele de deplasari privind traseele acestora.Serverul de

localizare GPS / GSM a fost integrat tot aici, deoarece Subsistemul de

Telecomunicatii permite in acest stadiu incorporarea informatiei privind localizarea

GPS in pachetele de date transmise.

Patternul de deplasari se bazeaza pe un algoritm de scoring in care locatiile

cele mai probabile sunt calculate si afisate in functie de ultima pozitie si prezenta

unui traseu anterior realizat de subiect.

Pentru afisarea pozitiei curente, tot ceea trebuie sa facem, este sa introducem

coordonatele curente intr-o aplicatie de afisat pozitia geografica, de tipul Google

Maps.

Figura.40 Localizare GPS


78

Concluzii:

• Transmisia sigura a datelor intre Subsistmul de Transmisie si Serverul

de Comunicatii si autentificare este asigurata de chei asimetrice de tip

cheie publica-cheie privata.

• Securitatea in cadrul Subsistemului de Prelucrare la Distanta este

asigurata de utilizarea firewall-ului si a VLAN-urilor.

• Pentru a stoca informatia cat mai eficient se utilizeaza un sistem de baze

de date (MySQL in cazul de fata).Un singur tabel poate contine chiar si 8

terabytes de informatie. Sistemul de securitate oferit cuprinde

restrictionarea datelor ce pot fi interogate, la nivel de tabel, camp,

utilizator.

• In cazul aparitiei defectiunilor privind alimentarea cu energie electrica,

sistemul poate rezista 8 ore pe bateriile de UPS-uri, sau mai multe zile,

alimentat de un generator.


79

A4.5 Realizare structuri hardware de achizitie date (P6 – ELCOS)

Realizarea elementelor hardware de achizitie date a fost realizate in peste 14

versiuni constructive pentru o parte din submodule. Problemele clasice de proiectare

, realizare si testare in cadrul unui proiect de cercetare care implica tehnologie de

ultima ora au fost accentuate de multiplele realocari de fonduri care au transferat

catre finalul proiectului executia subansamblelor necesare evaluarii fiecarui aspect in

conditiile in care aceasta tehnologie este o noutate pentru cercetarea romaneasca.

La inceput PCB-ul de test arata ca in imaginea de mai jos.

Figura.41 Structura PCB intial

Implicarea unor colective universitare precum si transferul catre cativa

parteneri a unor probleme tehnologice sau stiintifice (realizarea unor algoritmi

speciali sau manufacturarea PCB (circuitelor imprimate) pentru proiect (realizate in

Bulgaria la Plovdiv), pentru ca in Romania costurile erau prohibitive pentru SMD din

clasa micro au adus un plus tehnologic si stiintific proiectului.

Datorita achizitiilor din vara si toamna anului 2011 colectivul nostru a reusit

sa intre in posesia kitului de dezvoltare si hardware-ului aferent acestuia pentru

Bluetooth 4.0 iar in noiembrie 2011 a terminalului mobil Motorola RAZR care este la

data aceasta, singurul smartphone cu sistem de operare Android care ofera

Bluetooth ULP.


80

Figura. 42 Centura test si elemente componente

Fara acest terminal mobil echipa noastra putea testa comunicatiile BLE

(Bluetooth Low Energy) doar intre echipamentul purtabil si un laptop care dispunea

de un stickusb BLE achizitionat odata cu kit-ul de dezvoltare.

Pentru testarea comunicatiilor dintre SP si laptop s-a folosit pachetul software

furnizat de Texas Instruments pentru dezvoltarea aplicatiilor BLE.Software-ul de

dezvoltare folosit pentru acesta platforma hardware este Code Composer C/C+

Studio impreuna cu emulatoarele livrate de Blackhawk DSP.

Figura.43 Motorola Droid RAZR 2-XT910

Motorola Droid RAZR 2-XT910

Retea 2G: GSM 850 / 900 / 1800 / 1900;

Retea 3G: HSDPA 850 / 900 / 1900 / 2100

Dimensiuni 130.7 x 68.9 x 7.1 mm; Greutate: 127 g


81

EcranTip: Super AMOLED capacitive touchscreen, 16M culori, 540 x 960 pixeli, 4.3

inchi

Memorie interna: 16 GB (8GB valabili), 1GB RAM

Slotcard de memorie: microSD, pana la 32 GB

Transfer de date: GPRSClasa 12; EDGEClasa 12; 3GHSDPA 14.4 Mbps, HSUPA

5.76 Mbps WLAN Wi-Fi 802.11 b/g/n, dual-band, DLNA, Wi-Fihotspot;

Bluetooth: Da, v4.0 cu LE+EDR

USB: Da, microUSB v2.0

Sistem operare: Android OS, v2.3.5 (Gingerbread)

Procesor: 1.2 GHz dual-core Cortex-A9 CPU, PowerVR SGX540 GPU, TI OMAP

4430

Telefonul Motorola Android RAZR 2 este singurul sistem Android care ofera

BLE si care in plus ofera si un instrument software de dezvoltare specializat

MOTODEV STUDIO.

Concluzii

Platforma hardware a proiectului se bazeaza pe TI MSP430 care desi

este un microcontroller lansat in 2004 a devenit incepand cu anul 2010 cel mai

utilizat microcontroller pentru aplicatii medicale (acest lucru dovedind corecta

apreciere a echipei noastre in anul 2008.Pachetul hardware format din

telefonul Motorola XT910, sistemul portabil cu MSP430 si echipamentul de

calcul specializat din sediul coordonatorului proiectului.


82

A5. Experimentare sistem pacient si functii de localizare

A5.1 Experimentare sistem pacient; (CO-WING)

Teste SP si ST

Testele s-au efectuat folosind 3 tipuri de dispozitive mobile: 2 telefoane si o

tableta de 10.1”.Pentru fiecare dintre acestea, rezultatele au fost aceleasi.Prezentam

in continuare testul efectuat cu ajutorul tabletei deoarece este mai concludent din

punct de vedere vizual.

Figura. 44 Materiale si echipamente auxiliare folosite in cadrul subsistemului

purtabil si de telecomunicatii

Dupa cum se poate observa in figura (de mai sus) s-au folosit mai multe tipuri

de sisteme de achizite parametrii vitali (Polar si Texas Intruments) pentru a realiza o

coparatie in aceasta zona.Deasemenea se pot observa CD-urile continand kiturile de

dezvoltare folosite, kitul pentru semnalul ECG de test, acumultorul si incarcatorul

modelului experimental.In figura 45 sunt echipamentele efectiv folosite in test.


83

Figura.45 Echipamentele folosite la test

In prima etapa s-a montat banda elastic (figura 50) si s-a initializat legatura

prin Bluetooth intre device-ul purtabil (SP) si cel de telecomunicatii (ST), care in

acest caz a fost tableta de tip Samsung Galaxy tab 10.1”

Software-ul din ST a fost instalat dupa cum se poate observa pe desktopul

ST, versiunea 4 beta. (figura 46)

Figura.46 Versiune program E-RISC

Din momentul in care conexiunea se stabileste, programul este lansat (figura

47) si sunt afisate cele 3 ferestre care au fost programate pentru acest experiment.

Se poate dezvolta, daca cerinta exista, orice alt tip de prezentare a semnalului

prelucrat.Ferestrele reprezintă 3 situatii on-line: semnal ECG original (jos-figura 47),


84

statistica de tip histograma a intervalelor RR (mijloc- figura 47), distributie in timp pe

fereastra de 30 secunde a intervalelor RR (sus – figura 47).

Figura.47 Lansare executie program

Sunt monitorizate deasemenea, prin interfata programului numarul de pasi,

distanta parcursa si numarul de calorii consumate.

Figura 48 Afisare semnal ECG si statistica paliere RR

Resursele alocate de sistemul Android 3 sunt de cca. 800 KB asa cum se

poate observa in figura 49.


85

Figura 49. Alocare resurse pentru programul E-RISC


86

A5.2 Experimentare medicala, solutii de optimizare (P1 – SCUB)

Testele medicale s-au efectuat folosind o banda de alergat pentru simularea

miscarii, unui subiect sanatos din punct de vedere cardiologic.

Figura 50 Pozitionarea centurii pe pacient

Prelucrare statistica a datelor

Studiul datelor primite de la subsistemul purtabil (SP) prin intermediul

subsistemului de transmisie (ST) reprezinta un pas important deoarece pe baza

acestora s-a realizat algoritmul de prelucrare si analiza in timp real. Realizarea unei

analize corecte a biosemnalelor provenite de la pacient se bazeaza pe

corectitudinea datelor obtinute prin procesul de prelucrare. Din acest motiv s-a

acordat o atentie deosebita procesului de extragere a informatiilor utile din datele

primite.

In continuare am realizat un studiu statistic asupra structurii datelor

achizitionate de subsistemul purtabil pentru a evalua modul in care sistemul E-RISC

se comporta in vederea obtinerii unei serii RR corecte. Pentru intocmirea acestui

studiu am ales un esantion de 19 291 de inregistrari din baza de date. Fiecarei

inregistrari i s-a alocat un indice suplimentar, care reprezinta dinferenta dintre „heart

beat number-ul” inregistrarii curente si cel al inregistrarii precedente, denumit in

continuare indice de diferenta.

Pentru realizarea unui studiu cantitativ al datelor am ales reprezentarea

acestora sub forma unei diagrame de tip boxplot (figura 51).


87

Figura.51 Reprezentare de tip boxplot

Diagrama boxplot ofera informatii privind tendinta centrala si forma distributiei

studiate.O diagramă de tip boxplot reflecta grafic rezumarea prin cele 5 valori ale

unei distributii: valoarea minima, prima quartila, mediana,a treia quartila si valoarea

maxima. Graficul va prezenta deasemeni si valorile aberante sau valori situate mult

în afara distributiei.

Astfel, pentru esantionul ales am obtinut distributia de valori din figura.

Figura. 52 Diagrama de tip boxplot pentru distributia datelor inregistrate


88

Se poate observa ca majoritatea inregistrarilor obtinute se incadreaza in una

din situatiile urmatoare

- RR-uri succesive (indice de diferenta 1);

- lipsa unui RR intre 2 inregistrari succesive (indice de diferenta 2).

Pentru a avea o imagine completa asupra datelor culese, vom realiza si o

histograma pentru acest esantion. Histograma reprezinta un grafic de frecventa

simpla prin care se poate exprima participarea procentuala a unor entitati, figurata cu

ajutorul unor coloane verticale a caror latime corespunde cu un interval dimensional

iar inaltimea acestora corespunde cu frecventa de aparitie a entitatilor in esantionul

de proba. Histograma realizata pentru esantionul ales este reprezentata in figura

urmatoare.

Figura.53 Distributia RR pentru un esantion de 19000 de valori

Distributia din figura 53 a fost realizata pentru un esantion mare de valori

pentru a obtine o imagine de ansamblu a frecventei de aparitie a inregistrarilor in

functie de indicele de diferenta. Dupa cum observasem si anterior, in diagrama de tip

boxplot, majoritatea inregistrarilor au un indice de diferenta de valoare 1 sau 2. Din

histograma realizata in figura de mai sus, putem observa ca inregistrarile cu indice


89

de diferenta 2 au o pondere importanta, de circa 2 treimi din numarul inregistrarilor

totale.Inregistrarile cu indice de diferenta 0 (inregistrari dublate in baza de date), cele

cu indice 3 si 4 au ponderi foarte mici in raport cu numarul total de

valori.Inregistrarile cu indice de diferenta de valoare 5 sau mai mare apar foarte rar

(una la 50 000 de inregistrari sau mai mult) si nu vor fi luate in considerare.

Raportandu-ne la un numar atat de mare de inregistari am putea spune ca nu este

necesara nici studierea inregistrarilor cu indice de diferenta de valoare 0, 3 si 4.

Pentru a stabili daca acest lucru este necesar, vom considera un esantion mai

mic de 250 de inregistrari. Pentru acesta am obtinut histograma din figura

urmatoare.

Figura. 54 Histograma realizata pentru un esantion de 250 de inregistrari

Pentru acest esantion putem observa ca ponderea inregistrarilor cu indice de

diferenta 1 si 2 se pastreaza, si anume cele cu indice 1 vor fi circa 2/3 din numarul

total iar cele cu indice 2, vor avea o pondere de 1/3. Putem observa ca in acest caz

ponderea inregistrarilor cu indice 0,3 si 4 devine importanta in raport cu numarul total

de inregistrari. Pentru a ilustra acest lucru vom restrange progresiv acest esantion

ales.


90

Figura. 55 Histograma realizata pentru un esantion de 167 inregistrari

Pentru un esantion de 60 de inregistrari precum cel din figura de mai jos,

putem observa ca totalul inregistrarilor cu indice 0,3 si 4 reprezinta circa 10 % din

numarul total de inregistrari.Esantionul ales spre analiza mai prezinta o

particularitate si anume, inregistrarile cu indice de valoare 2 au o pondere aproape

egala cu cele cu indice de difernta 1.

Figura.56 Histograma realizata pentru un numar de 60 de inregistrari


91

Concluzie

Ignorarea inregistrarilor cu indice diferit poate cauza nedectarea unui

eveniment cardiac, in cazul aparitiei unui palier constituit numai cu inregistrari

cu indici de valori 0, 3 si 4. Din acest motiv, in cadrul algoritmului de

prelucrare a datelor sunt analizate si prelucrate acoperitor, toate datele pentru

indici de diferenta de pana la valoarea 6.

Figura. 57 Reprezentarea grafica in timp real a RR-urilor


92

Figura de mai sus ilustreaza principiul functionarii achizitiei de date in timp

real.Cele trei grafice sunt captate la momente de timp consecutive.Putem observa in

prima parte introducerea unui RR nou, cu numarul 50.La urmatoarea citire (graficul 2

din figura) se poate vedea inserarea unui element nou, cu numarul 51. La inserarea

unui element nou, elementele se deplaseaza pe afisajul grafic cu un pas spre

stanga. Astfel introducerea unui element nou pe grafic va genera eliminarea primului

element din stanga, si astfel actualizarea graficului pas cu pas. Afisarea graficului se

bazeaza pe principiul FIFO (First In First Out).

Figura. 58 Transformata Fourier obtinuta pentru pacient

Figura 58 reprezinta transformata Fourier pentru semnalul RR obtinut prin

preluarea datelor medicale ale pacientului.In aceasta figura se poate observa

formarea a trei benzi principale de frecventa.

Figura.59 Transformata wavelet 3D color


93

In continuare sunt reprezentate analizele datelor realizate cu ajutorul softului

biomedical.

Figura. 60 Program Evaluare interactiuni

Figura.61 Reprezentarea interactiunilor intre benzile de frecventa LF-VLF

Figura. 62 Reprezentarea interactiunilor intre benzile de frecventa LF-HF


94

Figura. 63 Reprezentare aparitie eveniment unic

Figura.64 Filtrare multidimensionala


95

A5.3 Experimentare sistem pacient (P2 – UPB)

Experimentare comunicatii intre ST si SPD - Experimentarea metodei

comunicatiei prin FTP

Conexiunea intre telefonul Android si Serverul de stocare si prelucrare se face

prin internet, prin intermediul protocolului FTP.

File Transfer Protocol (FTP)- este un protocol de retea utilizat pentru

transferul fisierelor intre doua dispozitive, printr-o retea ce suporta protocolul TCP

(cum este internetul).Protocolul este construit astfel incat sa functioneze pe baza

unei arhitecturi de tip client-server si utilizeaza conexiuni diferite pentru comenzi FTP

si transfer de date.

Comunicatia dintre un client FTP si un server FTP se realizeaza astfel:

serverul FTP asteapta conexiuni, de regula pe portul 21 de la clienti. Conexiunile

realizate pe portul 21 sunt numite conexiuni de control, si raman deschise pe toata

durata sesiunii.Pentru realizarea efectiva a transferului de date, o a doua conexiune

este necesara, numita conexiune de date. Aceasta conexiune este fie deschisa de

server (de regula de pe portul 20) spre un port al clientului (acest mod fiind numit

activ, clientul putand sa accepte conexiuni din afara), fie deschisa de client spre un

port indicat de server (numit si mod pasiv, cand clientul este in spatele unui firewall).

Conexiunea de control este utilizata pentru administrarea sesiunii (comenzi,

detalii de identificare, transmiterea parolelor), modul de functionare fiind asemanator

cu o conexiune de tip Telnet.

Deoarece FTP nu este un protocol gandit sa fie securizat, este necesara

combinarea acestui protocol cu o forma de criptare. Unul dintre modurile de utilizare

este combinatia dintre TLS sau SSL si FTP.

Fisierele generate pe telefon, sunt transferate prin intermediul protocolului

FTP pe server.Acest lucru presupune rularea unui client FTP pe telefonul Android.

Rolul acestui client nu va fi doar transmiterea de date spre serverul de baze de date

ci si monitorizarea directorului in care se vor salva acestea.

Cu alte cuvinte, clientul FTP realizeaza sincronizarea dintre telefon si server,

aceasta fiind in sens unic (dinspre telefon spre server).Asfel, orice fisier nou creat pe

telefon va fi transmis prin FTP pe server. Intervalul de verificare pentru fiecare fisier


96

nou aparut poate fi stabilit arbitrar, si este de preferat sa fie intre 5 si 15 secunde

pentru a avea o monitorizare “in timp real”.

Stocarea efectiva a informatiei presupune utilizarea unui server de baze de

date. S-a optat pentru utilizarea MySQL deoarece este cel mai popular SGBD open-

source la ora actuala.

Baza de date:

- Accepta conexiuni multiple: de la Aplicatia de Translatie (care o populeaza cu date)

si Serverul de Prelucrare.

- Contine mai multe tabele descrise mai jos:

- Tabel cu statistici (stats) privind resursele de sistem: incarcare procesor,

trafic, memorie disponibila, memorie ocupata, etc.

- Tabelele privind datele obtinute prin monitorizarea fiecarui pacient.

Acestea au urmatoarea structura:

Indice, DateTime, serial, batt, puls, hbn, hbTime1, hbTime2, locAcc,

gps_x, gps_y, provider

Tipul fiecarui camp:

Indice – int; dateTime - bigint

serial – int; batt - int

puls – int; hbn - int

btTime1 – int; btTime2 - int

locAcc – int; gps_x - double

gps_y – double; provider - int

Figura. 65 Informatii cuprinse in tabele de monitorizare


97

Cu semnificatia:

Indice: indexul bazei de date, porneste de la 1 si se incrementeaza pentru fiecare

noua inregistrare.

Data: numar cu 13 cifre ce reprezinta data scrisa in formatul urmator: numarul de

secunde scurse din 1970.

Serial: contor pentru fiecare inregistrare realizata de aparatura de monitorizare, la

fiecare sesiune este initializat cu valoarea 0.

Puls: pulsul pacientului.

Hbn: contor pentru bataile inimii, se reseteaza la 0 dupa 255 de batai

htTime1: numar exprimat in milisecunde, reprezinta momentul in care a survenit o

bataie a inimii. Acest parametru ia valori intre 0 si 65535.

hbTime2: numar exprimat in milisecunde, reprezinta momentul anterior in care a

survenit bataia precedenta.Valorile sunt cuprinse intre 0 si 65535.

Diferenta dintre hbTime1 si hbTime2 reprezinta RR-ul curent.

locAcc - acuratetea locatiei GPS, exprimata in metri.

gpx_x - latitundinea, cu 6 zecimale

gps_y - longitudinea, cu 6 zecimale

Provider: reprezinta metoda prin care sunt obtinute datele de localizare: GPS sau

NETWORK (sateliti sau celule de comunicatie GSM)

Alte valori:

Acc_x - acceleratia in coordonata x

Acc_y - acceleratia in coordonata y

Acc_z - acceleratia in plan vertical

batteryIndicator – reprezinta nivelul bateriei subsistemului purtabil.

Pentru a realiza conversia datelor din fisiere in campuri de tabele ale bazei de

date au fost necesare 2 aplicatii.Una dintre ele, numita Aplicatie de Translatie citeste

datele din fisier si se conecteaza la baza de date MySQL pentru a le stoca, iar

cealalta are rolul de a lansa Aplicatia de Translatie la aparitia unui nou fisier intr-un

folder predefinit.

Pentru a supraveghea un director, in Linux avem suita de utilitare inotify-tools.

Acestea sunt construite in jurul unei facilitati a kernelului de Linux, facilitate ce

permite aplicatiilor sa fie notificate in cazul evenimentelor privind fisierele si

directoarele.


98

Utilitarul incron (parte a intotify-tools) a fost ales pentru a se detecta prezenta

fisierelor transferate intr-un director predefinit prin intermediul protocolului FTP.

Detaliere incron: este reprezentat de un serviciu si o aplicatie pentru

manipularea unor table-uri (altele decat cele mysql). Serviciul supravegheaza

sistemul (apeluri de sistem) pentru evenimentele specificate in table-uri (creare a

unui fisier, modificare, redenumire, stergere, etc).

Folosire:

Pentru a introduce o monitorizare asupra dosarului populat prin tranfer FTP,

este necesara definirea a 3 parametrii: dosarul ce trebuie monitorizat, evenimentul,

si comanda de executat in cazul aparitiei evenimentului.

Exemplu:

/dosar_monitorizat IN_CLOSE_WRITE /home/erisc/./mysqltest3 $#

Explicatie:

/dosar_monitorizat - directorul pe care il monitorizam pentru fisiere nou create

IN_CLOSE_WRITE - eveniment declansat cand fisierul este inchis.

/home/erisc/mysqltest3 - comanda ce va fi realizata la aparitia evenimentului

$# - numele fisierului (care tocmai a fost creat in cazul nostru)

Cerinte de sistem: Linux kernel 2.6.13 sau mai nou (compilat cu optiunea inotify)

Aplicatia de Translatie:

• Este lansata de utilitarul de sistem incron, in momentul cand este creat un

nou fisier in directorul predefinit;

• Este scrisa in limbajul de programare C si utilizeaza un conector pentru

realizarea legaturii cu serverul MySQL;

• Primeste ca parametru fisierul ce trebuie citit (cu tot cu calea spre acesta)

pentru a fi inserat in baza de date;

• Parcurge fisierul linie cu linie, verifica si extrage elementele de care suntem

interesati din fiecare linie;

• Ignora header-ul, reduce din numarul de zecimale pentru GPS, inlocuieste

texul pentru provider cu un numar;

• Insereaza in baza de date elementele ce vor fi utilizate mai tarziu;


99

• Inchide conexiunea cu baza de date. Acest lucru este necesar, deoarece in

cazul apelarii repetate a Aplicatiei de Translatie, se deschide de fiecare data o

noua conexiune.

Figura. 66 Jurnal prinvind operatia de inserare a datelor in BD

Printre datele prelucrate inainte de a fi inmagazinate in baza de date se

numara:

- Scurtarea numarului de zecimale din coordonatele GPS. Un numar de 5

zecimale inseamna o precizie de +/- 1 metru;

- Pentru coloana provider - modul in care sunt obtinute coordonatele GPS s-

a facut urmatoarea translatie: 1 pentru network (in cazul in care datele

sunt obtinute de la celulele GSM) si 2 pentru GPS (in cazul in care datele

sunt obtinute folosind satelitii GPS).

Figura.67 Formatul datelor inainte de a fi prelucrate

Imbuntatiri:

1. Inlocuirea metodei FTP ca mod de transmisie si datelor pe server. Aceasta

metoda se poate inlocui cu un mod mai eficient de transmisie si anume prin

conectarea directa a telefonului Android la baza de date MySQL.Astfel eliminam

clientul si serverul FTP, programul de monitorizare a unui director, programul de

citire din fisier si scriere in MySQL.

Conectarea directa a device-ului la baza de date MySQL mai presupune

modificari de genul:

- Datele vor fi validate pe telefon inainte de a fi trimise;


100

- Datele vor fi prelucrate pe telefon inainte de a fi trimise;

- Ca avantaj se vor trimite doar datele de care sunt relevante, rezulta o

cantitate mai mica de date transferata;

- Un alt avantaj este eliminarea intarzierilor (verificarea la 5 secunde,

transferul fisierului, etc).

2. Integrarea unei arhitecturi de tip client-server. In actuala forma de functionare,

pentru fiecare pacient exista cate o tripleta de tipul: director supravegheat - aplicatie

de translatie - conexiune cu baza de date. Fiecare tripleta este independenta de

celelalte, numarul de conexiuni si numarul de aplicatii de translatie fiind egal cu

numarul de pacienti monitorizati. Intr-un scenariu client-server, exista o singura

aplicatie de translatie si o singura conexiune la baza de date.

Dificultati:

In actuala forma arhitectura Server FTP / Aplicatie de Translatie/ Server

Stocare este sensibila la exceptii survenite in cazul in care se sincronizeaza mai

multe fisiere simultan, din cauza latentelor mari, datorate aparitiei problemelor de

comunicare prin internet : pierdere semnal GSM, iesirea si revenirea din modul 3G al

telefonului, pierderea accesului la internet a serverului, etc.Acest fapt duce la

amanarea sincronizarii dintre telefon si server si reluarea acesteia cu transferul de

fisiere multiple. Serverul va incepe stocarea in BD a datelor imediat ce sincronizarea

se va fi reluata, dar pana atunci acestea nu vor fi disponibile in timp real, pentru a fi

preluate de Aplicatia de prelucrare.


101

A5.4 Experimentare functii de localizare (P3 – IPA)

Prin experimentarea functiilor de localizare, s-a verificat in primul rand

corectitudinea pozitiei GPS raportate prin verificarea preciziei coordonatelor, apoi

afisarea locatiei pe harta, atat pe telefon cat si pe calculator.

Figura.68 Coordonate raportate GPS raportate de telefon

Pasul urmator a fost afisarea hartii pe telefon, cu coordonatele curente.Am

folosit pentru aceasta Google Maps, utilitar inclus in sistemul de operare al

telefoanelor ce ruleaza Android.

Figura.69 Afisarea hartii pe telefon


102

Urmatorul pas este verificarea prezentei coordonatelor in baza de date.

Pentru a vizualiza continutul bazei de date am folosit utilitarul gratuit phpMyAdmin.

Figura. 70 Coordonate GPS din baza de date

Figura. 71 Coordonatele extrase din baza de date sunt afisate pe harta


103

V.ANEXE


104

ANEXA 1

Articole, carti si teze de doctorat publicate in cadrul Proiectului ERSIC 2009-2010

• Articole, carti si teze de doctorat publicate in cadrul Proiectului ERSIC 2011

– 5 articole stiintifice (dintre care 2 cotate ISI)

ARTICOLE 1. Stegemann, B., Mihalcz, A., Foldesi, C, Vatasescu, R., Kardos, A., Torok, Z., Splett, V., Cornelussen R, Rudos, L., Szili-Torok, T.

“Extrasystolic stimulation with bi-ventricular pacing: an acute haemodynamic evaluation” (ISI-Impact revista 1,871)

Europace 2011 Nov; 13(11): 1591-6. Epub 2011 Jun 28

2. Vatasescu, R.G., Dan, M., Dorobantu M.

“Deep inspiration unmasks Brugada syndrome” (ISI-Impact revista 5,385)

Heart 2011 Jan; 97(2):167. Epub 2010 Oct. 8

3. Paraschiv, A.-M., Cepisca, C., Banica, C., Enache, A

“Remote monitoring ECG Signals System”

International symposium on Advanced Topics in Electrical Engineering (ATEE), ISSN: 2068-7966, ISBN: 978-1-4577-0507-6

4. Enache, A.C., Cepisca, C., Paraschiv A.-M., Banica, C.K.

“Virtual instrument for electroencephalography data acquisition”

International symposium on Advanced Topics in Electrical Engineering (ATEE), ISSN: 2068-7966, ISBN: 978-1-4577-0507-6

5. Anatolie Boev, Marcel Stanciu

“ECG Pattern Analysis for High Sampling Rate Acquisition”

The 7th International Symposium on ADVANCED TOPICS IN ELECTRICAL ENGINEERING 2011


105

ANEXA 2 Cod sursa - Functii Matlab

1. Functie conectare la baza de date MySql % conectarea la baza de date de pe un server mysql javaaddpath ('mysql-connector-java-5.1.13-bin.jar'); conn = database('erisc', 'username', 'password', ... % data base name, user and password if required 'com.mysql.jdbc.Driver', ... % JDBC driver 'jdbc:mysql://ibm:3306/erisc'); % URL for location of data base 2. Functie validare conexiune cu baza de date % verificare daca baza de date este disponibila a=isconnection(conn); % a=1 if valid, else 0 if a==1 disp ('Conexiune disponibila') else disp ('Conexiune indisponibila ') end 3. Functie creare matrice dinamica, adauga mereu o linie noua pe ultima pozitie

%%% construire matrice pentru analiza in timp real function[A]=matricen(v1) global v1 global A j=1; for j=1:1:599 A(j,:)=A(j+1,:); end A(600,:)=v1; A; end

4. Functie creare matrice dinamica, prin adaugarea a 2 linii noi pe ultimele 2 pozitii

%%% construire matrice pentru analiza in timp real, in cazul adaugarii a 2 linii noi function[A]=matricedub2(v2)


106

global v2 v3 global A for j=1:1:598 A(j,:)=A(j+2,:); end A(599,:)=v2; A(600,:)=v3; A; end

5. Exemplu creare interfata erisc : pentru reunirea mai multor functii function varargout = erisc(varargin) % ERISC MATLAB code for erisc.fig % ERISC, by itself, creates a new ERISC or raises the existing % singleton*. % % H = ERISC returns the handle to a new ERISC or the handle to % the existing singleton*. % % ERISC('CALLBACK',hObject,eventData,handles,...) calls the local % function named CALLBACK in ERISC.M with the given input arguments. % % ERISC('Property','Value',...) creates a new ERISC or raises the % existing singleton*. Starting from the left, property value pairs are % applied to the GUI before erisc_OpeningFcn gets called. An % unrecognized property name or invalid value makes property application % stop. All inputs are passed to erisc_OpeningFcn via varargin. % % *See GUI Options on GUIDE's Tools menu. Choose "GUI allows only one % instance to run (singleton)". % % See also: GUIDE, GUIDATA, GUIHANDLES % Edit the above text to modify the response to help erisc % Last Modified by GUIDE v2.5 10-Dec-2011 16:30:24 % Begin initialization code - DO NOT EDIT gui_Singleton = 1; gui_State = struct('gui_Name', mfilename, ... 'gui_Singleton', gui_Singleton, ... 'gui_OpeningFcn', @erisc_OpeningFcn, ... 'gui_OutputFcn', @erisc_OutputFcn, ... 'gui_LayoutFcn', [] , ... 'gui_Callback', []); if nargin && ischar(varargin{1})


107

gui_State.gui_Callback = str2func(varargin{1}); end if nargout [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:}); else gui_mainfcn(gui_State, varargin{:}); end % End initialization code - DO NOT EDIT % --- Executes just before erisc is made visible. function erisc_OpeningFcn(hObject, eventdata, handles, varargin) % This function has no output args, see OutputFcn. % hObject handle to figure % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % varargin command line arguments to erisc (see VARARGIN) % Choose default command line output for erisc handles.output = hObject; % Update handles structure guidata(hObject, handles); % UIWAIT makes erisc wait for user response (see UIRESUME) % uiwait(handles.figure1); % --- Outputs from this function are returned to the command line. function varargout = erisc_OutputFcn(hObject, eventdata, handles) % varargout cell array for returning output args (see VARARGOUT); % hObject handle to figure % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Get default command line output from handles structure varargout{1} = handles.output; % --- Executes on button press in pushbutton1. function pushbutton1_Callback(hObject, eventdata, handles) run main_demo4 % hObject handle to pushbutton1 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)


108

% --- Executes on button press in pushbutton2. function pushbutton2_Callback(hObject, eventdata, handles) run wavecom % hObject handle to pushbutton2 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % --- Executes on button press in pushbutton3. function pushbutton3_Callback(hObject, eventdata, handles) run ekgfilt % hObject handle to pushbutton3 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % --- Executes on button press in pushbutton4. function pushbutton4_Callback(hObject, eventdata, handles run suv % hObject handle to pushbutton4 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)


109

ANEXA 3

Cod sursa program C

#include <my_global.h> #include <mysql.h> #include <stdio.h> #include <stdlib.h> #include <string.h> struct erisc { long int dateTime; int serial; int batt; int puls; int hbn; int hbTime1; int hbTime2; int locAcc; char gps_x[20]; char gps_y[20]; char provider[9]; }; struct erisc erisc_line; //int main(int argc, char **argv) int main ( int argc, char *argv[] ) { MYSQL *conn; MYSQL_RES *result; MYSQL_ROW row; int num_fields; int i; int indice; int j; int k; char temp[50]; int provider; float gpsx,gpsy; //FILE *p; FILE *p = fopen( argv[1], "r" ); //p = fopen("test.txt", "r"); if ( p == 0 )


110

{ printf( "Could not open file\n" ); } i = 0; provider = 0; indice=0; char *cmd; cmd=malloc(1024); char buf[500]; conn = mysql_init(NULL); mysql_real_connect(conn, "localhost", "username", "password", "erisc", 0, NULL, 0); while(( fgets(buf,sizeof(buf),p) != NULL) && i<800 ) { strcpy(temp, strtok(buf,",")); if (strcmp (buf,"version") != 0) { printf ("Not a header line\n"); printf ("i=%d\n",i); indice++; printf ("Indice=%d\n",indice); printf ("buf=%s\n",buf); erisc_line.dateTime = atol(strtok(NULL,",")); erisc_line.serial = atoi(strtok(NULL,",")); for (j=1;j<8;j++) { strcpy(temp, strtok(NULL,",")); } erisc_line.batt = atoi(strtok(NULL,",")); erisc_line.puls = atoi(strtok(NULL,",")); erisc_line.hbn = atoi(strtok(NULL,",")); erisc_line.hbTime1 = atoi(strtok(NULL,",")); erisc_line.hbTime2 = atoi(strtok(NULL,",")); for (k=1;k<25;k++) { strcpy(temp, strtok(NULL,",")); } erisc_line.locAcc = atoi(strtok(NULL,",")); strcpy(temp, strtok(NULL,",")); strcpy(temp, strtok(NULL,",")); // strcpy(erisc_line.gps_x,strtok(NULL,",")); gpsx = atof(strtok(NULL,",")); gpsy = atof(strtok(NULL,","));


111

// strcpy(erisc_line.gps_y,strtok(NULL,",")); strcpy(erisc_line.provider,strtok(NULL,",")); provider = 0; if (strcmp (erisc_line.provider,"network") == 0) { provider = 1; } if (strcmp (erisc_line.provider,"gps") == 0) { provider = 2; } //gpsx = atol(erisc_line.gps_x); //gpsy = atol(erisc_line.gps_y); printf ("%lu\n",erisc_line.dateTime); printf ("%d\n",erisc_line.serial); printf ("%d\n",erisc_line.batt); printf ("%d\n",erisc_line.puls); printf ("%d\n",erisc_line.hbn); printf ("%d\n",erisc_line.hbTime1); printf ("%d\n",erisc_line.hbTime2); printf ("%d\n",erisc_line.locAcc); printf ("%f\n",gpsx); printf ("%f\n",gpsy); printf ("%s\n",erisc_line.provider); printf ("Provider :%d\n",provider); sprintf(cmd, "INSERT INTO hrm (dateTime,serial,batt,puls,hbn,hbTime1,hbTime2,locAcc,gps_x,gps_y,provider) VALUES('%lu','%d','%d','%d','%d','%d','%d','%d','%f','%f','%d');",erisc_line.dateTime,erisc_line.serial,erisc_line.batt,erisc_line.puls,erisc_line.hbn,erisc_line.hbTime1,erisc_line.hbTime2,erisc_line.locAcc,gpsx,gpsy,provider); mysql_query(conn, cmd); } i++; } mysql_close(conn);

}


112

ANEXA 4

23 Nov, 2011

Next generation mobile human health monitoring

Wireless innovations company Hidalgo has launched its latest exciting

range of mobile products that monitor human life.

The technology could revolutionise the future of the healthcare and

pharmaceutical industries worldwide, with customers already including NHS

hospitals and international research bodies.

Under its innovative brand Equivital, the team of engineers, scientists and

doctors have been pioneering products that allow accurate data to be measured

from real people in real environments for over 10 years.

“The Equivital personal devices are designed to be used on a ‘wear and

forget’ principle and the latest product range is being appreciated for this

quality,” says Dr Ekta Sood from Hidalgo.

The new Equivital EQ02 LifeMonitor incorporates a miniaturised body-worn sensor

module that senses, records, processes and transmits data from the human body.

The data includes physiological parameters such as ECG, respiration rate and

body temperature but importantly can be used to derive information – for example for

biometric verification - or for creating indexes such as for stress monitoring. Using

external sensors the LifeMonitor data channels can include oxygen saturation,

galvanic skin response, and core body temperature.

In combination with the eqView PC, mobile and web based software platform,

the LifeMonitor sends information to be viewed and, where applicable, further

analysed or acted upon.

“Having the ability to measure and model physiological information about the

human body - in both health and disease states and on a mass scale - will lead to a

better understanding of its cause and effect behaviours and catalyse an era of more

proactive and personalised healthcare,” explained Dr Sood.


113

“Hidalgo is developing devices and software which can do this in real time so that in

the future, for example, timely and appropriate action can be taken if patterns of data

from the person under observation changes.

“What the Equivital brand stands for will ultimately enable an important shift in

the level of control an individual can have on their own personal health and wellbeing

by being better informed.”

The devices are already being put to good use in healthcare and

pharmaceutical fields. A trial funded by Oxford Biomedical Research Centre and the

Wellcome Trust - and run by a team at Churchill Hospital and Oxford University - is

using the Equivital LifeMonitor to continuously monitor haemodialysis patients. Such

patients are at a much higher risk of sudden and potentially fatal emergencies.

Using human data taken before, during and after haemodialysis, the team is

developing an index that pro-actively alerts clinicians to the likelihood of a life

threatening event. This could enable timely intervention and prevent adverse

situations.

Orders have already been received for the new EQ02 Equivital LifeMonitor

system through distributors around the world.

Mobile human health monitoring technologies offer a significant advance in

both personalising healthcare and extending care from the hospital into the

community and the home. Hidalgo, which is at the cutting edge of this emerging field,

believes it will see a rapid increase in the uptake and availability of such systems in

the next five years.


114

Sensors (Basel). 2011; 11(7): 6799–6815. Published online 2011 June 29. doi: 10.3390/s110706799

PMCID: PMC3231662

Copyright © 2011 by the authors; licensee MDPI, Basel, Switzerland.

A Comprehensive Ubiquitous Healthcare Solution on an Android™ Mobile Device

Pei-Cheng Hii1 and Wan-Young Chung2* 1 Department of Electronic Engineering, Graduate School, Pukyong National University, Busan 608-737, Korea; E-Mail: [email protected] 2 Department of Electronic Engineering, College of Engineering, Pukyong National University, Busan 608-737, Korea * Author to whom correspondence should be addressed; E-Mail: [email protected]; Tel.: +82-51-629-6223; Fax: +82-51-629-6210. Received April 20, 2011; Revised June 10, 2011; Accepted June 12, 2011. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).

• Other Sections▼

Abstract

Provision of ubiquitous healthcare solutions which provide healthcare services at anytime anywhere has become more favorable nowadays due to the emphasis on healthcare awareness and also the growth of mobile wireless technologies. Following this approach, an Android™ smart phone device is proposed as a mobile monitoring terminal to observe and analyze ECG (electrocardiography) waveforms from wearable ECG devices in real time under the coverage of a wireless sensor network (WSN). The exploitation of WSN in healthcare is able to substitute the complicated wired technology, moving healthcare away from a fixed location setting. As an extension to the monitoring scheme, medicine care is taken into consideration by utilizing the mobile phone as a barcode decoder, to verify and assist out-patients in the medication administration process, providing a better and more comprehensive healthcare service.

http://dx.crossref.org/10.3390%2Fs110706799

http://www.ncbi.nlm.nih.gov/pmc/about/copyright.html

mailto:[email protected]

mailto:[email protected]

http://creativecommons.org/licenses/by/3.0/

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231662/?tool=pubmed


115

ANEXA 5

Actualitatea proiectului ERISC

Solutii propuse dezvoltatorilor de catre Texas Instruments in august 2011 la Londra


116

Solutii propuse de Freescale la Bucuresti in septembrie 2011

Aceasta platforma propune solutii de monitorizare medicala prin Zigbee pentru pacientii din ambulator (tratati acasa).


117

ANEXA 6

Fragment din codul de log-are pentru date ECG (sursa Java Android)

.class public Lcom/elcospro/erisk/HrmLog;

.super Ljava/lang/Object;

.source "HrmLog.java" # static fields .field private static D:Z .field private static LOG_FILE_NAME:Ljava/lang/String; .field private static TAG:Ljava/lang/String; .field private static hrmInputStream:Ljava/io/FileInputStream; .field private static hrmLogBuffer:Ljava/io/BufferedWriter; .field private static hrmLogStream:Ljava/io/FileOutputStream; .field private static hrmLogWriter:Ljava/io/FileWriter; .field private static logFileDir:Ljava/lang/String; .field static logFileReader:Ljava/io/FileReader; .field private static logHrmData:Z .field static logReader:Ljava/io/BufferedReader; .field static logReaderFileName:Ljava/lang/String; .field static newSequence:I .field private static replayFromBinaryLog:Z .field private static replayFromTextLog:Z .field private static storageDir:Ljava/io/File; .field private static writeToBinaryLog:Z .field private static writeToTextLog:Z # direct methods .method static constructor <clinit>()V .locals 4 .prologue const/4 v3, 0x1 const/4 v2, 0x0 const/4 v1, 0x0 .line 41 const-string v0, "HrmLog" sput-object v0, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; .line 42 sput-boolean v3, Lcom/elcospro/erisk/HrmLog;->D:Z .line 43 sput-object v1, Lcom/elcospro/erisk/HrmLog;->hrmLogStream:Ljava/io/FileOutputStream; .line 44 sput-object v1, Lcom/elcospro/erisk/HrmLog;->logFileDir:Ljava/lang/String; .line 45 sput-object v1, Lcom/elcospro/erisk/HrmLog;->storageDir:Ljava/io/File; .line 46


118

sput-boolean v2, Lcom/elcospro/erisk/HrmLog;->writeToBinaryLog:Z .line 47 sput-boolean v3, Lcom/elcospro/erisk/HrmLog;->writeToTextLog:Z .line 48 sput-boolean v2, Lcom/elcospro/erisk/HrmLog;->replayFromBinaryLog:Z .line 49 sput-boolean v2, Lcom/elcospro/erisk/HrmLog;->replayFromTextLog:Z .line 50 const-string v0, "hrm.log" sput-object v0, Lcom/elcospro/erisk/HrmLog;->LOG_FILE_NAME:Ljava/lang/String; .line 55 sput-boolean v3, Lcom/elcospro/erisk/HrmLog;->logHrmData:Z .line 311 sput-object v1, Lcom/elcospro/erisk/HrmLog;->hrmLogWriter:Ljava/io/FileWriter; .line 312 sput-object v1, Lcom/elcospro/erisk/HrmLog;->hrmLogBuffer:Ljava/io/BufferedWriter; .line 485 sput-object v1, Lcom/elcospro/erisk/HrmLog;->hrmInputStream:Ljava/io/FileInputStream; .line 587 sput-object v1, Lcom/elcospro/erisk/HrmLog;->logReader:Ljava/io/BufferedReader; .line 588 sput-object v1, Lcom/elcospro/erisk/HrmLog;->logFileReader:Ljava/io/FileReader; .line 589 sput-object v1, Lcom/elcospro/erisk/HrmLog;->logReaderFileName:Ljava/lang/String; .line 590 sput v2, Lcom/elcospro/erisk/HrmLog;->newSequence:I .line 39 return-void .end method .method constructor <init>()V .locals 0 .prologue .line 170 invoke-direct {p0}, Ljava/lang/Object;-><init>()V .line 171 invoke-static {}, Lcom/elcospro/erisk/HrmLog;->init()V .line 172 return-void .end method .method public static final byteArrayToInt([B)I .locals 2 .parameter "b" .prologue


119

.line 251 const/4 v0, 0x0 aget-byte v0, p0, v0 shl-int/lit8 v0, v0, 0x18 .line 252 const/4 v1, 0x1 aget-byte v1, p0, v1 and-int/lit16 v1, v1, 0xff shl-int/lit8 v1, v1, 0x10 .line 251 add-int/2addr v0, v1 .line 253 const/4 v1, 0x2 aget-byte v1, p0, v1 and-int/lit16 v1, v1, 0xff shl-int/lit8 v1, v1, 0x8 .line 251 add-int/2addr v0, v1 .line 254 const/4 v1, 0x3 aget-byte v1, p0, v1 and-int/lit16 v1, v1, 0xff .line 251 add-int/2addr v0, v1 return v0 .end method .method public static declared-synchronized closeHrmLogs()Z .locals 4 .prologue const-string v1, "closeHrmLogs(): "naspa" .line 428 const-class v1, Lcom/elcospro/erisk/HrmLog; monitor-enter v1 :try_start_0 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogStream:Ljava/io/FileOutputStream; :try_end_0 .catchall {:try_start_0 .. :try_end_0} :catchall_0 if-eqz v2, :cond_0 .line 430 :try_start_1 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogStream:Ljava/io/FileOutputStream; invoke-virtual {v2}, Ljava/io/FileOutputStream;->flush()V .line 431 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogStream:Ljava/io/FileOutputStream; invoke-virtual {v2}, Ljava/io/FileOutputStream;->close()V


120

.line 432 const/4 v2, 0x0 sput-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogStream:Ljava/io/FileOutputStream; :try_end_1 .catchall {:try_start_1 .. :try_end_1} :catchall_0 .catch Ljava/io/IOException; {:try_start_1 .. :try_end_1} :catch_0 .line 439 :cond_0 :goto_0 :try_start_2 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogBuffer:Ljava/io/BufferedWriter; :try_end_2 .catchall {:try_start_2 .. :try_end_2} :catchall_0 if-eqz v2, :cond_1 .line 441 :try_start_3 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogBuffer:Ljava/io/BufferedWriter; invoke-virtual {v2}, Ljava/io/BufferedWriter;->flush()V .line 442 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogBuffer:Ljava/io/BufferedWriter; invoke-virtual {v2}, Ljava/io/BufferedWriter;->close()V .line 443 const/4 v2, 0x0 sput-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogBuffer:Ljava/io/BufferedWriter; :try_end_3 .catchall {:try_start_3 .. :try_end_3} :catchall_0 .catch Ljava/io/IOException; {:try_start_3 .. :try_end_3} :catch_1 .line 450 :cond_1 :goto_1 :try_start_4 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogWriter:Ljava/io/FileWriter; :try_end_4 .catchall {:try_start_4 .. :try_end_4} :catchall_0 if-eqz v2, :cond_2 .line 452 :try_start_5 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogWriter:Ljava/io/FileWriter; invoke-virtual {v2}, Ljava/io/FileWriter;->flush()V .line 453 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogWriter:Ljava/io/FileWriter; invoke-virtual {v2}, Ljava/io/FileWriter;->close()V .line 454 const/4 v2, 0x0


121

sput-object v2, Lcom/elcospro/erisk/HrmLog;->hrmLogWriter:Ljava/io/FileWriter; :try_end_5 .catchall {:try_start_5 .. :try_end_5} :catchall_0 .catch Ljava/io/IOException; {:try_start_5 .. :try_end_5} :catch_2 .line 461 :cond_2 :goto_2 :try_start_6 sget-object v2, Lcom/elcospro/erisk/HrmLog;->logReader:Ljava/io/BufferedReader; :try_end_6 .catchall {:try_start_6 .. :try_end_6} :catchall_0 if-eqz v2, :cond_3 .line 463 :try_start_7 sget-object v2, Lcom/elcospro/erisk/HrmLog;->logReader:Ljava/io/BufferedReader; invoke-virtual {v2}, Ljava/io/BufferedReader;->close()V .line 464 const/4 v2, 0x0 sput-object v2, Lcom/elcospro/erisk/HrmLog;->logReader:Ljava/io/BufferedReader; :try_end_7 .catchall {:try_start_7 .. :try_end_7} :catchall_0 .catch Ljava/io/IOException; {:try_start_7 .. :try_end_7} :catch_3 .line 471 :cond_3 :goto_3 :try_start_8 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmInputStream:Ljava/io/FileInputStream; :try_end_8 .catchall {:try_start_8 .. :try_end_8} :catchall_0 if-eqz v2, :cond_4 .line 473 :try_start_9 sget-object v2, Lcom/elcospro/erisk/HrmLog;->hrmInputStream:Ljava/io/FileInputStream; invoke-virtual {v2}, Ljava/io/FileInputStream;->close()V .line 474 const/4 v2, 0x0 sput-object v2, Lcom/elcospro/erisk/HrmLog;->hrmInputStream:Ljava/io/FileInputStream; :try_end_9 .catchall {:try_start_9 .. :try_end_9} :catchall_0 .catch Ljava/io/IOException; {:try_start_9 .. :try_end_9} :catch_4 .line 482 :cond_4


122

:goto_4 const/4 v2, 0x1 monitor-exit v1 return v2 .line 433 :catch_0 move-exception v2 move-object v0, v2 .line 435 .local v0, e:Ljava/io/IOException; :try_start_a sget-object v2, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; const-string v3, "closeHrmLogs(): naspa 2 HRM log" invoke-static {v2, v3, v0}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I :try_end_a .catchall {:try_start_a .. :try_end_a} :catchall_0 goto :goto_0 .line 428 .end local v0 #e:Ljava/io/IOException; :catchall_0 move-exception v2 monitor-exit v1 throw v2 .line 444 :catch_1 move-exception v2 move-object v0, v2 .line 446 .restart local v0 #e:Ljava/io/IOException; :try_start_b sget-object v2, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; const-string v3, "closeHrmLogs(): serious exception occurred trying to close the HRM log" invoke-static {v2, v3, v0}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I goto :goto_1 .line 455 .end local v0 #e:Ljava/io/IOException; :catch_2 move-exception v2 move-object v0, v2 .line 457 .restart local v0 #e:Ljava/io/IOException; sget-object v2, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; const-string v3, "closeHrmLogs(): serious exception occurred trying to close the HRM log"


123

invoke-static {v2, v3, v0}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I goto :goto_2 .line 465 .end local v0 #e:Ljava/io/IOException; :catch_3 move-exception v2 move-object v0, v2 .line 467 .restart local v0 #e:Ljava/io/IOException; sget-object v2, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; const-string v3, "closeHrmLogs(): var 3 naspa HRM log" invoke-static {v2, v3, v0}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I goto :goto_3 .line 475 .end local v0 #e:Ljava/io/IOException; :catch_4 move-exception v2 move-object v0, v2 .line 477 .restart local v0 #e:Ljava/io/IOException; sget-object v2, Lcom/elcospro/erisk/HrmLog;->TAG:Ljava/lang/String; const-string v3, "closeHrmLogs(): bou " invoke-static {v2, v3, v0}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)I :try_end_b .catchall {:try_start_b .. :try_end_b} :catchall_0 goto :goto_4 .end method .......................................................................................................................


124

VI. CONCLUZII

1. Proiectul E-RISC este, la aceasta ora, un exemplu clasic de tehnologie aflata la

limitele superioare, de multidisciplinaritate si dificultati de alocare pentru resurse

financiare si tehnologice.

Posibilitatea de a utiliza echipamente si solutii de ultima ora este

contrabalansata de problemele generate de utilizarea unor solutii tehnice imature, de

precaritatea suportului tehnic sau chiar de lipsa acestuia pentru utilizarea unor

dispozitive venite direct din sectiile de microproductie. Pe ansamblu, efortul de a

produce o solutie utila si originala este conditiia necesara, dar nu suficienta, pentru

impunerea in societatea romaneasca a unui produs bun sau a unei tehnologii

valoroase.

2. Glisarea activitatiilor de cercetare din motive bugetare (din 2009 in 2010 si apoi in

2011) si apoi reducerea cu peste 60% a fondurilor a generat solutii de urgenta, :

• comasarea intr-un singur server fizic a Serverului de stocare, a Serverului de

Anamneza pacienti, a Serverului de Pattern Deplasari si a Serverului de

Localizare GPS, numit Server de stocare

• reunirea intr-un singur subsistem (server) a Serverului de Analiza si

prelucrare, a Serverului de detectie artefacte si a Serverului Decizional,

denumit Server de Prelucrare si Analiza

• folosirea unei solutii software de pozitionare corecta a senzoriilor ECG si

renuntarea la senzorii cu masa flotanta (fara contact) mult mai scumpi.

3. Achizitia datelor electrobiologice se face in final prin intermediul senzorilor e-

textili tesuti, impreuna cu un set de informatii despre mediu si pozitia subiectului

in mediu. Modularizarea sectiuni de achizitie date permite schimbarea cu usurinta

a tipului de senzori utilizati.

4. Schimbare de doua ori a solutiilor de telecomunicatii este dovada ca echipa a

dorit sa ofere o solutie solida si eficienta pentru a suporta functionarea sistemului

in cele mai adverse conditii - de functionarea corecta a acestui sistem poate

depinde viata unui om care a avut incredere in produsul nostru.

5. Avantajul major al acestui produs este pe termen scurt - reducerea costurilor de

spitalizare si deblocarea unor paturi de spital ocupate altfel cu pacientii care vor

folosi E-RISC.


125

6. Pe termen mediu - elementul principal il reprezinta integrarea mult mai usoara a

personelor cu risc cardiac in societate cu toate beneficiile care vin de aici.

7. Pe termen lung datele medicale inregistrate de serverul de diagnoza de la

pacientii care au folosit E-RISC vor deveni un avantaj competitiv pentru medicina

romaneasca, baza de date in sine fiind un suport pentru cercetare medicala.

Existenta acestei baze de date cu zeci de mii de ore de inregistrare ECG va

permite dezvoltarea si testarea virtuala a zeci de produse medicale noi, pentru ca

virtualizarea in domeniul cercetarii medicale este noul Graal.

8. Solutia noastra purtabila (wearable) este asa cum rezulta si din materiale din

Anexa 5 si Bibliografie este una de top din punctul de vedere al solutiilor gasite si

a problemelor rezolvate dar ramane ca valorificarea unei asemenea cercetari sa

se poate face aici in Romania sau macar in Europa.

9. Avand in vedere ca telemonitorizarea medicala va fi un subiect fierbinte in lumea

stiintifica si in urmatorii ani dezvoltarea acestui subiect in cadrul grupului de

cercetatori este un argument in directia realizarii unui prototip si apoi valorificarii

acestuia sub forma unui transfer de Know-how.

10. Un castig cert este formarea unei echipe de cercetare si dezvoltare care a

dobandit noi competente dar si obisnuinta lucrului in colective multidisciplinare in

conditiile unui consortiu cu sapte parteneri. Dezvoltarea in continuarea de

cercetarii in domeniul biosenzorilor si a telemonitorizarii pentru sanatate va

permite acestui grup de cercetare dispune de certe avantaje de competitivitate

stiintifica si tehnologica bazate pe experienta dobandita in cadrul acestui proiect.

11. Dezvoltarea unui mediu concurential care sa permita colectivelor stiintifice sa

accelereze un proiect in vederea anuntarii unui rezultat sau sa astepte aparitia

anuntata a unor noi platforme tehnologice suport pentru subiectul cercetarii este

un deziderat realizabil in urmatorul program Parteneriate.

12. E-RISC este un proiect romanesc cu certe valente stiintifice ce demonstreaza

sincronismul cercetarii romanesti cu cea mondiala si pentru care colectivul de

cercetatori isi doresc finalizarea intr-un produs comercial.


126

VII. BIBLIOGRAFIE

1. BĂNICĂ,C.K, SERIAN,G.C., GHIŢĂ, O.M.,Optimal Acquisition for ECG Signal with Real–Time Processing, ATEE 2000, pp. 37-40, Bucharest, 2000;

2. AUGUSTYNIAK, P. (2008). "Detecting patient's emergency--a minimum-computation procedure for pervasive cardiac monitoring." Conf Proc IEEE Eng Med Biol Soc 2008: 1439-1442.

3. LIU, X., Y. ZHENG, et al. (2010). "Multiple Functional ECG Signal Processing for Wearable Applications of Long-Term Cardiac Monitoring." IEEE Trans Biomed Eng.

4. LIN, C. T., K. C. CHANG, et al. (2010). "An intelligent telecardiology system using a wearable and wireless ECG to detect atrial fibrillation." IEEE Trans Inf Technol Biomed 14(3): 726-733.

5. HUANG, W. T., C. H. CHEN, et al. (2008). "Exquisite textiles sensors and wireless sensor network device for home health care." Conf Proc IEEE Eng Med Biol Soc 2008: 546-549.

6. ZHENG, J. W., Z. B. ZHANG, et al. (2007). "A wearable mobihealth care system supporting real-time diagnosis and alarm." Med Biol Eng Comput 45(9): 877-885.

7. HONG, S., Y. YANG, et al. (2009). "Performance study of the wearable one-lead wireless electrocardiographic monitoring system." Telemed J E Health 15(2): 166-175.

8. YAZICIOGLU, R. F., T. TORFS, et al. (2009). "Ultra-low-power wearable biopotential sensor nodes." Conf Proc IEEE Eng Med Biol Soc 2009: 3205-3208.

9. THULASI BAI, V. and S. K. SRIVATSA (2007). "Design of wearable cardiac telemedicine system." Int J Electron Healthc 3(3): 303-316.

10. TADEUSIEWICZ, R. AND P. AUGUSTYNIAK (2005). "Information Flow and Data Reduction in the ECG Interpretation Process." Conf Proc IEEE Eng Med Biol Soc 1: 382-385

11. SHIN, K., H. TAE HWANG, ET AL. (2005). "WHAM: A novel, wearable heart activity monitor based on Laplacian potential mapping." Conf Proc IEEE Eng Med Biol Soc 7: 7361-7364.

12. SCHEFFLER, M. AND E. HIRT (2005). "Wearable devices for telemedicine applications." J Telemed Telecare 11 Suppl 1: 11-14.

13. PAWAR, T., S. CHAUDHURI, et al. (2007). "Body movement activity recognition for ambulatory cardiac monitoring." IEEE Trans Biomed Eng 54(5): 874-882

14. ORESKO, J. J., H. DUSCHL, et al. (2010). "A wearable smartphone-based platform for real-time cardiovascular disease detection via electrocardiogram processing." IEEE Trans Inf Technol Biomed 14(3): 734-740.

15. CEPIŞCĂ,C, ANDREI, H., BĂNICĂ,C.K, Măsurări în energetică, Editura ICPE, Bucuresti, 2000.

16. NEGOESCU, R., Iniţiere în electronica biomedicală, Editura Tehnică, 1985. 17. CEPIŞCĂ,C., Măsurări electrice şi electronice, Editura ICPE, 1997. 18. CEPIŞCĂ,C., VEYSSIERE,M., Condiţionarea senzorilor şi a semnalelor, Editura

ICPE, 1995. 19. CEPIŞCĂ,C., NEGOESCU, R., Instrumentaţie pentru biosemnale, Editura ICPE,

1998. 20. POPESCU,M. , Transformata Wavelet, IPB 1994. 21. LĂZĂRESCU, N., Prelucrarea digitală a semnalelor, Editura Amco Press, 1994.


127

22. ILIESCU, C., PANTELIMON, B., Senzori şi traductoare, Litografia I.P.B., Bucuresti, 1993.

23. WINKLER,R, Data acquisition embraces Ethernet, RD Magazine, 1999. 24. MATEESCU, A., DUMITRU,N, STANCIU, L, Semnale şi Sisteme, Editura Teora

2001. 25. POPESCU, D., Prelucrarea digitală a semnalelor, Editura ICPE 2000. 26. KEITHLEY Instruments, SUA, ADwin DSP System, Technical Data, 2004. 27. BĂNICĂ, C.K., Biosemnale – Prelucrari numerice, Editura Electra - ICPE.,

Bucuresti, 2007. 28. BĂNICĂ, C.K., SERIŢAN,G.C, - Tehnici de analiză a variabilităţii ritmului cardiac,

în domeniul timp-frecvenţă 29. NEGOESCU, R, Instrumentaţia electronică biomedicală, Editura Tehnica,

Bucuresti, 1985 30. STRUNGARU, R, Electronica medicală, EDP, Bucuresti, 1982 31. CIUPA, R.V., Introducere în Electronica Biomedicală, Inst. Politehnic Cluj-

Napoca, 1992 32. COSTIN, H., Electronica Medicală, Editura Cantes, Iaşi, 2000 33. NAGY, I., Curs de electronică medicală, Editura Eurobit, Timisoara, 1999 34. JOVANOV, T.,M, and RASKIVIC, D., Issues în wearable computing for medical

monitoring applications: A case study of a wearable ecg monitoring device. în Digest of Papers. Fourth International Symposium on Wearable Computers. IEEE Comput. Soc, 2000. în Proc. Eng. în Med. and Bio. Society (EMBS) 1997, Vol. 5, no. 30 Oct.-2 Nov. A.

35. KRAUSE, D.P., SIEWIOREK, et. al.“Unsupervised, dynamic identification of physiological and activity context în wearable computing,” în Proc. 7th Int’l Symp. on Wearable Computers, (ISWC ) 2003 Oct. 21-23.

36. BAR-OR, HEALEY,J, KONTOTHANASSIS, L,. VAN THONG, J.M, “BioStream: A System Architecture for Real-Time Processing of Physiological Signals” în Proc. Eng.in Med. and Bio. Society (EMBS) 2004 Sept. 1-5, 2004.

37. RANDALL, MULLER, H., “Context awareness by analysing accelerometer data,” în Proc. 4th Int’l Symp. on Wearable Computers (ISWC) 2000. Oct. 16-17,

38. DONNAY, S., “Wireless body-area networks (WBAN) for health monitoring applications”, In: ESF Workshop on Wireless Sensor Networks, April 1-2, 2004

39. PAHLM, O., SORNMO, L., Data processing of exercise ECG’s. IEEE Transactions on Biomedical Engineering, Vol.34, No.2, February 1987, pp.230-236.

40. SMITH, S, „MATLAB Advanced GUI Development”,Dog Ear Publishing 2006 41. MARCHLAND,P., HOLLAND, T., „Graphics and GUIs with MATLAB”, Chapman&

Hall/CRC, 2003 42. HANSELMAN, D., LITTLEFIELD, B., „Mastering MATLAB”, Pearson/Prentice

Hall, 2011 43. VASWANI, V., „Utilizarea si administrarea bazelor de date MySQL”,Rosetti

Educational, 2010 44. RUSU,I., GROSU, V., „Programarea calculatoarelor in limbaj C- probleme

rezolvate si comentate”, Matrixrom, 2009 45. RINCÓN F., RECAS J., KHALED N., ATIENZA D., “Development and Evaluation

of Multilead Wavelet-Based ECG Delineation Algorithms for Embedded Wireless Sensor Nodes”, IEEE Trans Inf Technol Biomed. 2011 Nov; 15(6):854-63. Epub 2011 Aug 8

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Rinc%C3%B3n%20F%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed/21827976


128

46. AUGUSTYNIAK P., “Wearable wireless heart rate monitor for continuous long-term variability studies”, Electrocardiol 2011 Mar-Apr;44(2):195-200

47. KIM BS, YOO SK, LEE MH, “Wavelet-based low-delay ECG compression algorithm for continuous ECGtransmission”, IEEE Trans Inf Technol Biomed. 2006 Jan; 10(1):77-83.

48. GALLEGO J, LEMOS D, MENESES GA, HERNANDEZ AM., “Development of a wearable vital signs monitor for healthcare”, Conf Proc IEEE Eng Med Biol Soc. 2010; 2010:6401-4

49. LIN WH., WONG MY., PU LN., ZHANG YT., “Comparison of median filter and discrete dyadic wavelet transform for noise cancellation in electrocardiogram”, Conf Proc IEEE Eng Med Biol Soc. 2010; 2010:2395-8

50. AGARWAL R., SONKUSALE S., “Direct Analog-to-QRS detection front-end architecture for wearable ECG applications”, Conf Proc IEEE Eng Med Biol Soc. 2010;2010:6527-30

51. YOO HJ., YOO J., YAN L., “Wireless fabric patch sensors for wearable healthcare”, Conf Proc IEEE Eng Med Biol Soc. 2010; 2010:5254-7

52. LIU X., ZHENG Y., PHYU MW, ZHAO B, JE M, YUAN X., “Multiple functional ECG signal is processing for wearable applications of long-term cardiac monitoring”, IEEE Trans Biomed Eng. 2011 Feb; 58(2):380-9. Epub 2010 Jul 29

53. CURONE D., TOGNETTI A, SECCO EL, ANANIA G, CARBONARO N, DE ROSSI D, MAGENES G., “Heart rate and accelerometer data fusion for activity assessment of rescuers during emergency interventions”, IEEE Trans Inf Technol Biomed. 2010 May; 14(3):702-10. Epub 2010 Apr 8

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Augustyniak%20P%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Kim%20BS%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Yoo%20SK%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Lee%20MH%22%5BAuthor%5D



http://www.ncbi.nlm.nih.gov/pubmed?term=%22Gallego%20J%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Lemos%20D%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Meneses%20GA%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Hernandez%20AM%22%5BAuthor%5D



http://www.ncbi.nlm.nih.gov/pubmed?term=%22Lin%20WH%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Wong%20MY%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Pu%20LN%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Zhang%20YT%22%5BAuthor%5D


http://www.ncbi.nlm.nih.gov/pubmed?term=%22Agarwal%20R%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Sonkusale%20S%22%5BAuthor%5D



http://www.ncbi.nlm.nih.gov/pubmed?term=%22Yoo%20HJ%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Yoo%20J%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Yan%20L%22%5BAuthor%5D


http://www.ncbi.nlm.nih.gov/pubmed?term=%22Liu%20X%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Zheng%20Y%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Phyu%20MW%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Zhao%20B%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Je%20M%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Yuan%20X%22%5BAuthor%5D


http://www.ncbi.nlm.nih.gov/pubmed?term=%22Curone%20D%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Tognetti%20A%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Secco%20EL%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Anania%20G%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Carbonaro%20N%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22De%20Rossi%20D%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22De%20Rossi%20D%22%5BAuthor%5D

http://www.ncbi.nlm.nih.gov/pubmed?term=%22Magenes%20G%22%5BAuthor%5D



2011 1. raportul stiintific si tehnic (rst ... erisc rst etapa 4 2011.pdf · 2011 etapa - 4 1 1....

Documents