Body Sensor Networks: Applicazioni, Tecnologie e Sfide aperte · Facoltà di Ingegneria Corso di...

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

Tesi di laurea

Body Sensor Networks: Applicazioni, Tecnologie e Sfide aperte

Anno Accademico 2009/2010 relatore

Ch.mo prof. Marcello Cinque candidato

Giovanni Giacco matr. 534/002839

A coloro che sanno ascoltarmi

"I computer sono incredibilmente veloci, accurati e stupidi.

Gli uomini sono incredibilmente lenti, inaccurati e intelligenti.

L’insieme dei due costituisce una forza incalcolabile"

Albert Einstein

Indice

Elenco delle figure v

Elenco delle tabelle vi

Simboli e Abbreviazioni vii

Introduzione 1

1 Reti di sensori wireless e l’assistenza sanitaria 4

1.1 Il contesto demografico . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Dalle Wireless Sensor Networks alle Body Sensor Networks . . . . . . 6

1.3 Monitoraggio pervasivo del paziente . . . . . . . . . . . . . . . . . . . 13

1.3.1 Context-Aware Sensing e Activity Recognition . . . . . . . . . 17

1.3.2 Monitoraggio nell’ambiente ospedaliero . . . . . . . . . . . . . 22

1.3.3 Monitoraggio nell’ambiente domestico . . . . . . . . . . . . . . 23

1.3.4 Monitoraggio di pazienti con malattie croniche . . . . . . . . . 25

1.3.5 Assistenza sanitaria personalizzata . . . . . . . . . . . . . . . 28

1.4 Oltre l’assistenza sanitaria . . . . . . . . . . . . . . . . . . . . . . . . 29

2 Tecnologie abilitanti per la realizzazione di BSN 35

2.1 Hardware e dispositivi . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.1.1 Sensori corporali . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.1.2 Piattaforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2 Architetture per BSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.1 Comunicazioni Intra–BAN . . . . . . . . . . . . . . . . . . . . 47

2.2.2 Comunicazioni Inter–BAN . . . . . . . . . . . . . . . . . . . . 49

i

Indice

2.2.3 Comunicazioni Beyond–BAN . . . . . . . . . . . . . . . . . . 52

2.3 Tecnologie Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.3.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3.2 Bluetooth 4.0: Low Energy . . . . . . . . . . . . . . . . . . . 59

2.3.3 IEEE 802.15.4 e ZigBee . . . . . . . . . . . . . . . . . . . . . 65

2.3.4 UWB e IEEE 802.15.6 . . . . . . . . . . . . . . . . . . . . . . 70

2.4 Piattaforme Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.4.1 nesC e TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . 72

2.4.2 Raccolta, Storage e Post-Processing dei dati . . . . . . . . . . 76

2.5 Standard e Interoperabilita . . . . . . . . . . . . . . . . . . . . . . . . 77

2.5.1 DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.5.2 HL7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2.5.3 ISO / IEEE 11073 . . . . . . . . . . . . . . . . . . . . . . . . . 87

Personal Health Data . . . . . . . . . . . . . . . . . . . . . . 93

3 Analisi di un caso di studio: Il morbo di Parkinson 108

2.6 Il tremore nel morbo di Parkinson . . . . . . . . . . . . . . . . . . . . 111

2.7 Hardware e Software Design . . . . . . . . . . . . . . . . . . . . . . . 114

2.8 Acquisizione delle accelerazioni . . . . . . . . . . . . . . . . . . . . . 119

2.8.1 Implementazione in TinyOS . . . . . . . . . . . . . . . . . . . 119

2.8.2 Raccolta e memorizzazione dei messaggi . . . . . . . . . . . . 124

2.8.3 Calibratura e conversione in mg . . . . . . . . . . . . . . . . . 125

2.9 Analisi dei risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Conclusioni 135

A Datasheet

Iris mote – MTS400/420 142

Bibliografia 146

ii

Elenco delle figure

1.1 Distribuzione dell’eta media della popolazione europea . . . . . . . . 5

1.2 Trend della spesa sanitaria in Italia (Fonte: OECD) . . . . . . . . . . 6

1.3 Rappresentazione schematica dell’architettura di una BSN . . . . . . 7

1.4 Piattaforme per WSN sviluppate fino al 2005 . . . . . . . . . . . . . . 8

1.5 Requisiti minimi e ottimali per polisonnografia digitale. . . . . . . . . 9

1.6 Data-rate di misurazioni biomediche . . . . . . . . . . . . . . . . . . . 10

1.7 CardioNET (sinistra) - Sensore in un anello (destra) . . . . . . . . . . 15

1.8 Code Blue (Harvard University) . . . . . . . . . . . . . . . . . . . . . 16

1.9 CardioMEMS: sensore di pressione utilizzato per la rilevazione di

aneurismi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.10 Legame tra i costi dell’assistenza sanitaria, la Qualita della Vita e

l’ambiente in cui le cure avvengono (Fonte: Intel) . . . . . . . . . . . 23

1.11 (Sinistra) Giocatore che utilizza il Wii Remote. (Destra) Playstation

Move. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.12 Accelerometro sugli occhialini del nuotatore - Sistemi di coordinate e

angoli utilizzati nello studio . . . . . . . . . . . . . . . . . . . . . . . 30

1.13 Nike + Ipod Sports Kit . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1 Sensori inseriti in una maglia - Accelerometro MEMS . . . . . . . . . 37

2.2 Sensore di pressione del sangue - Fascia elestica contenente sensori EEG 39

2.3 Sensore EMG - Sensore ECG - Sensore CO2 - Pulsossimetro . . . . . 41

2.4 Architettura di un nodo sensore. . . . . . . . . . . . . . . . . . . . . . 43

2.5 Un’architettura three-tier per un sistema di comunicazione basato su

BSN per applicazioni nell’assistenza sanitaria. . . . . . . . . . . . . . 46

2.6 Architettura della comunicazione intra–BAN . . . . . . . . . . . . . . 47

iii

Elenco delle figure

2.7 Architettura della comunicazione inter–BAN . . . . . . . . . . . . . . 50

2.8 BSN mobile connessa a una WSN ambientale. . . . . . . . . . . . . . 52

2.9 Posizionamento di una Wireless Body Area Network nel mondo delle

reti wireless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.10 Caratteristiche di una WBAN confrontate con WSN e WLAN. . . . . 55

2.11 BSN che utilizza Bluetooth + Health Device Profile (Fonte: Bluetooth

SIG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.12 Struttura della superframe . . . . . . . . . . . . . . . . . . . . . . . . 66

2.13 Stack di comunicazione ZigBee. . . . . . . . . . . . . . . . . . . . . . 68

2.14 Operazione split-phase in TinyOS. . . . . . . . . . . . . . . . . . . . . 74

2.15 Architettura di TinyOS. . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.16 Composizione di un messaggio HL7. . . . . . . . . . . . . . . . . . . . 84

2.17 Conversionde della stringa XML in un messaggio HL7. [22] . . . . . . 85

2.18 Timeline dello standard ISO /IEEE 11073. . . . . . . . . . . . . . . . 88

2.19 Package che compongono il DIM. . . . . . . . . . . . . . . . . . . . . 91

2.20 Sequence diagram dell’avvio di comunicazione tra due dispositivi. . . 92

2.21 Standard che compongono la famiglia di standard ISO / IEEE 11073

PHD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

2.22 Class diagram dell’IEEE 11073 PHD Domain Information Model. . . 99

2.23 Class diagram del DIM di una bilancia pesa persona. . . . . . . . . . 100

2.24 Messaggio di rischiesta associazione: (a) Agente non riconosciuto.

(b) Agente riconosciuto. . . . . . . . . . . . . . . . . . . . . . . . . . 102

2.25 (a) Operazioni di un oggetto Scanner. (b) Operazioni per l’accesso

al PM-Store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

2.26 Sistema generico di telemedicina che integra sistemi eterogenei. . . . . 106

2.27 (Sinistra) Sensor board MTS420. (Destra) Iris Mote. . . . . . . . . . 114

2.28 Programming Board MIB520. . . . . . . . . . . . . . . . . . . . . . . 116

2.29 Base Station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

2.30 Strumenti hardware e software utilizzati. . . . . . . . . . . . . . . . . 119

2.31 (Sopra) Collegamenti tra i componenti del programma ReadingAccel.

(Sotto) Sequenza di eventi che caratterizzano il programma. . . . . . 122

2.32 XSniffer: Sniffing dei messaggi . . . . . . . . . . . . . . . . . . . . . . 124

iv

Elenco delle figure

2.33 Rotazione del mote di 180◦ affinche l’asse Y dell’accelerometro sia

prima orientato a -1g e poi a +1g. . . . . . . . . . . . . . . . . . . . . 128

2.34 Rotazione del mote di 180◦ affinche l’asse X dell’accelerometro sia

prima orientato a -1g e poi a +1g. . . . . . . . . . . . . . . . . . . . . 130

2.35 Grafici delle accelerazioni sull’asse X e sull’asse Y quando il mote

viene ruotato come mostrato in Figura 2.33. . . . . . . . . . . . . . . 131

2.36 Grafici delle accelerazioni sull’asse X e sull’asse Y quando e simulato

un tremore di bassa intensita e i rispettivi grafici dei moduli dello

spettro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

2.37 Grafici delle accelerazioni sull’asse X e sull’asse Y quando e simulato

un tremore di forte intensita e i rispettivi grafici dei moduli dello

spettro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

2.38 Consumo di potenza medio di trasmettitori wireless (in arancione) e

microprocessori (in blu) in tipiche piattaforme BSN. . . . . . . . . . . 138

v

Elenco delle tabelle

1.1 Differenze tra WSN e BSN. . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Considerazioni su sistemi context-aware. . . . . . . . . . . . . . . . . 18

1.3 Stato dell’arte sul riconoscimento di attivita motorie con sensori inerziali 20

1.4 Malattie croniche e i parametri comunemente usati per monitorarle . 27

2.1 Sensori comunemente impiegati in BSN e relativi tassi di trasmissione

tipici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2 Confronto tra nodi sensore utilizzati in BSN. . . . . . . . . . . . . . . 44

2.3 Classi e rispettive caratteristiche dei dipositivi Bluetooth. . . . . . . . 56

2.4 Confronto tra diverse tecnologie wireless. . . . . . . . . . . . . . . . . 59

2.5 Alcuni degli standard dell’ISO 11073. . . . . . . . . . . . . . . . . . . 89

2.6 Comuni disordini del movimento nel morbo di Parkinson. . . . . . . . 109

2.7 Tipi di tremore e intervalli di frequenze associati. . . . . . . . . . . . 112

2.8 Riassunto delle specifiche dell’ADXL202JE. . . . . . . . . . . . . . . . 115

2.9 Stato dei LED del mote. . . . . . . . . . . . . . . . . . . . . . . . . . 123

2.10 Le 8 caratteristiche che definiscono un sistema autonomico (adattate

da [48]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

vi

Simboli e Abbreviazioni

ADC Convertitore analogico-digitale

AM Active Message

AP Access Point

ASN.1 Abstract Syntax Notation One

BAN Body Area Network

BASN Body Area Sensor Network

BCU Body Control Unit

BER Bit Error Ratio

BSN Body Sensor Network

CAP Contention Access Period

CEN Comitato europeo di normazione

CFP Contention Free Period

ECG Elettrocardiogramma

EEG Elettroencefalogramma

EOG Elettrooculografia

EMG Elettromiografia

FFD Full Function Device

FFT Fast Fourier Transform

g Accelerazione di gravita = 9,8 m/s2

GPS Global Positioning System

HAN Home Area Network

vii

Body Sensor Networks: Applicazioni,Tecnologie e Sfide aperte

HDP Health Device Profile

HSN Home Sensor Network

ISO International Organization for Standardization

LPU Local Processing Unit

MEMS Micro Electro-Mechanical System

OECD Organisation for Economic Co-operation and Development

OO Object–Oriented

PD Personal Device

PDA Personal Digital Assistant

PHD Personal Health Data

P2P Peer–to–peer

QoS Qualita del Servizio

RF Radiofrequenze

RFD Reduced Function Device

RTOS Real Time Operating System

SAR Specific Absorption Rate (Tasso di assorbimento specifico)

TEG Generatore termoelettrico

UWB Ultra Wide Band

WAN Wide Area Network

WBAN Wireless Body Area Network

WLAN Wireless Local Area Network

WMAN Wireless Metropolitan Area Network

WPAN Wireless Personal Area Network

WBSN Wireless Biomedical (Body) Sensor Network

WSAN Wireless Sensor and Actuator Network

viii

Introduzione

Gli sviluppi in campo scientifico e nella medicina sono fortemente collegati; il

loro progresso nel tempo e caratterizzato da salti improvvisi che spesso hanno effetti

radicali sull’umanita ed oltre. L’avvento delle body sensor networks deve essere vi-

sto come un salto; il motivo e da ricercarsi nel fatto che tutti i rami della medicina

moderna, spaziando dalla prevenzione a interventi complessi, richiedono accurate e

complesse diagnosi prima e un monitoraggio intensivo dei risultati dopo. Fino ad

oggi i tentativi di diagnosi e monitoraggio consistevano in un contatto intermitten-

te con l’interessato che produceva una serie di istantanee dei dati caratterizzanti

lo stato del paziente. Questa analisi, seguita da una serie di ipotesi, produceva

inevitabilmente un’immagine distorta del quadro reale.

D’altra parte il Progetto Genoma Umano ha mostrato che tutti siamo “uguali”

ma conferma che ognuno di noi ha caratteristiche uniche a molti livelli, alcuni dei

quali interessano la nostra predisposizione ai disagi e la risposta a molti stimoli

esterni, medicinali e terapie. Questo ha portato al concetto di medicina e terapia

personalizzata che promette di rivoluzionare il concetto di assistenza sanitaria. Per

raggiungere simili risultati abbiamo bisogno di informazioni accurate catturate in

continuo, in un modo, tuttavia, che non interferisca con la dignita umana o la qualita

della vita.

Le BSN offrono l’opportunita di monitorare l’essere umano in un modo prima

impossibile: la possibilita di un monitoraggio onnipresente e pervasivo del paziente

permettera, in prima istanza, di identificare i processi caratterizzanti il disagio, e

1


successivamente di monitorare progressi e validita delle terapie. Non e fantascienza,

infine, la possibilita di creare sistemi che permettano la somministrazione controllata

e automatica dei farmaci, riducendo di fatto gli effetti collaterali di sovradossagio.

Sommario

Il testo e strutturato come segue.

Al Capitolo 1 verra introdotto il nuovo concetto di Body Sensor Network, le

differenze con le tradizionali Wireless Sensor Network e le grandi potenzialita offer-

te da questa emergente tecnologia. Verra introdotto il concetto di “monitoraggio

pervasivo del paziente” e la possibilita di offrire assistenza sanitaria personalizzata.

Tutto cio diventa possibile attraverso la progettazione di sistemi context-aware e i

notevoli progressi in tecniche di activity recognition per mezzo di accelerometri e

giroscopi. Verranno analizzati i vantaggi delle Body Sensor Network nelle strutture

ospedaliere esistenti, soprattutto nelle fasi post-intervento, in ambiente domesti-

co, nel monitoraggio di persone anziane, e nello studio di malattie croniche. La

panoramica sulle applicazioni esistenti e potenziali partira dall’utilizzo nel campo

dell’assistenza sanitaria per poi mostrare applicazioni in numerosi altri contesti quali

il settore videoludico, il mondo della preparazione atletica etc.

Al Capitolo 2 verranno presentate le tecnologie abilitanti per Body Sensor Network.

Verra presentato il nuovo utilizzo di sensori chimici e biosensori e le piattaforme gia

esistenti. Verra fornita inoltre una panoramica sulle architetture per BSN, le tec-

nologie wireless utilizzabili e le piattaforme software esistenti, sia a bordo sensore

sia per la raccolta, memorizzazione, post-processing e analisi dei dati. Il capitolo,

infine, illustrera il problema dell’interoperabilita di diversi dispositivi e gli standard

esistenti.

Il Capitolo 3 mostrera l’analisi di un caso di studio reale: il tremore nel morbo

di Parkinson. Verranno introdotti i disordini del movimento che caratterizzano il

2


Parkinson, saranno illustrate le potenzialita degli accelerometri nello studio delle fasi

che scandiscono temporalmente la malattia e presentate le caratteristiche e differen-

ze del tremore parkinsionano rispetto ad altri tipi di tremore. Verra poi proposta

l’implementazione di una soluzione che, mediante l’utilizzo di un accelerometro bias-

sale, permettera di studiare in frequenza i segnali accelerometrici raccolti durante

la simulazione di tremore a differenti velocita. In particolare la frequenza dell’ar-

monica fondamentale del segnale accelerometrico verra utilizzata come parametro

caratterizzante il tipo di tremore.

Le Conclusioni ripercorreranno le potenzialita delle BSN e le sfide ancora aper-

te. Verra accennato all’utilizzo di array di sensori e il concetto di multi-sensor data

fusion per migliorare l’affidabilita. Verra illustrata la necessita di elaborare a bordo

sensore i segnali acquisiti per ridurre le trasmissioni, migliorare l’affidabilita e au-

mentare la durata della batteria. Infine verra introdotto il concetto di “Autonomic

Sensing” e la difficolta di ottenere un “sistema autonomico” con le risorse limitate

a disposizione.

3

Capitolo 1

Reti di sensori wireless e

l’assistenza sanitaria

Il cambiamento demografico caratterizzato da un invecchiamento globale della

popolazione grava fortemente sul sistema sanitario di ogni Paese nel mondo. Il

ruolo della tecnologia nel tentativo di muovere il punto di monitoraggio e di cura

quotidiano dagli ospedali all’ambiente domestico e fondamentale. La sfida e quella

di poter monitorare parametri fisici e biochimici del paziente in modo continuo e

in qualsiasi ambiente. Il problema di acquisire dati fisiologici e comportamentali in

ambiente clinico o domestico per diagnosi, monitoraggio o gestione di disagi cronici

trova soluzione nell’utilizzo delle reti di sensori wireless che rappresentano l’ultima

evoluzione nei tool diagnostici odierni.

1.1 Il contesto demografico

La popolazione globale sta invecchiando. Nel mondo occidentale le persone vi-

vono piu a lungo. Il tempo di pensionamento e cresciuto, cosı come e aumentato

il tempo in cui le persone vivono con disagi cronici, quali problemi al cuore, can-

cro, Alzheimer e altre forme di demenza. Questo comporta un’enorme domanda

sul sistema sanitario, non solo in termini di cura ospedaliera ma anche per il mo-

4


Figura 1.1. Distribuzione dell’eta media della popolazione europea nel 1995, 2025,2050

nitoraggio quotidiano e il tentativo di mantenere alto lo stato di salute su larga

scala. L’impatto economico sul sistema sanitario di ogni Paese e quindi forte. Il

risultato e una notevole difficolta finanziaria per i governi che ricade evidentemente

sulla qualita del servizio offerto a una popolazione che avra eta media sempre piu

alta: la popolazione mondiale over 65 si aspetta raddoppi, rispetto al 1990, nel 2025.

(Figura 1.1)

L’aumento della longevita della vita e direttamente legata alla diffusione di ma-

lattie legate all’invecchiamento, quali l’Alzheimer. A completare il quadro, infine,

c’e la difficolta, e spesso l’impossibilita, per gli adulti, molti dei quali hanno un

lavoro full-time, di assistere adeguatamente parenti affetti da malattie o disabilita.

In Figura 1.2 e mostrata la spesa sanitaria del governo italiano negli ultimi anni.

Dallo studio del grafico alla destra si nota come il trend sia chiaramente crescente:

la spesa sanitaria pro capite risulta addirittura raddoppiata dal 1990 al 2009. E

evidente, quindi, la necessita di invertire tale tendenza nell’assistenza sanitaria in

modo da migliorare il servizio offerto al numero crescente di persone anziane e ridurre

gli insostenibili costi attuali. Dato il costo notevole delle cure ospedaliere, aiutare

le persone anziane a vivere in maniera indipendente nelle proprie case deve essere

una priorita per il Sistema Sanitario di ogni governo.

5


Figura 1.2. Trend della spesa sanitaria in Italia (Fonte: OECD)

1.2 Dalle Wireless Sensor Networks alle Body Sen-

sor Networks

In una rete di sensori wireless, dozzine, centinaia o anche migliaia di dispositivi

dalle dimensioni ridotte e alimentati a batteria sono disseminati nell’ambiente. Ogni

dispositivo e capace di monitoraggio (“sensing”) e/o visualizzazione (“actuating”)

di informazioni. Il monitoraggio puo includere la raccolta di dati quali valori di

temperatura, umidita, vibrazione o altri dati utilizzabili in ambito medicale. La

visualizzazione puo essere il semplice lampeggiamento di un LED, informazioni te-

stuali visualizzate a schermo oppure ogni altra azione che produca una risposta o

informi il paziente. Le WSN sono usate in applicazioni medicali, oltre che nei piu

variegati contesti applicativi, per monitorare e raccogliere dati che potrebbero es-

sere difficili o costosi da catturare con sensori wired. In ambito medicale una rete

di sensori wireless potrebbe essere ottenuta attaccando semplicemente i sensori al

corpo oppure impiantando questi ultimi direttamente nei tessuti.

Tuttavia nonostante la tecnologia delle WSN continui ad evolversi e ad essere

utilizzata in diversi ambiti, essa non affronta in maniera specifica le nuove sfide as-

sociate al monitoring del corpo umano. Nasce, dunque, la necessita di introdurre

il nuovo concetto di wireless Body Sensor Network (BSN) che indica piattaforme

specificamente progettate per il collegamento wireless di sensori corporali impianta-

6


Figura 1.3. Rappresentazione schematica dell’architettura di una BSN

bili e indossabili. La Figura 1.3 mostra un paziente con un certo numero di sensori

attaccati al corpo, ognuno dei quali e collegato a un piccolo processore, un’antenna

wireless e una batteria, e tutti insieme formano un “nodo BSN complesso” capace

di integrarsi con l’ambiente domestico, lavorativo, ospedaliero. Il nodo assicura la

cattura accurata di dati dai sensori a cui e collegato, un processing di basso livello

dei dati e la trasmissione wireless dell’informazione a una “Local Processing Unit”

(LPU). I dati di tutti i sensori sono quindi raccolti dalla LPU, processati, fusi insieme

e trasmessi verso un server di monitoraggio centrale via wireless, LAN, Bluetooth,

GPRS, 3G. . . I sensori, strategicamente posizionati sul corpo umano, formano quella

che in gergo e chiamata Body Sensor Network oppure Wireless Body Area Network

(WBAN), o semplicemente BAN. Talvolta in letteratura si parla anche di Body Area

Sensor Network (BASN) a sottolineare la presenza di una unita di sensing o ancora

di Wireless Biomedical Sensor Network (WBSN) a sottolineare l’utilizzo di reti di

sensori wireless in applicazioni biomediche. All’interno del testo verrano utilizzati

estensivamente tutti i diversi acronimi ed i termini “applicazione BSN(BAN)” e “si-

stema BSN(BAN)” ad indicare applicazioni e sistemi che utilizzano le Body Sensor

Network.

Lo sviluppo delle BSN, comunque, ha fortemente beneficiato dei notevoli pro-

gressi che hanno interessato le WSN in questi ultimi anni. Dall’introduzione del

7


Figura 1.4. Piattaforme per WSN sviluppate fino al 2005

concetto di WSN e di “ubiquitous computing” sono state sviluppate un numero

enorme di piattaforme. La Figura 1.4 mostra questo trend crescente dal 1998 al

2005.

Tuttavia, nonostante attualmente molte delle piattaforme sviluppate per WSN

possono essere modificate per l’utilizzo in applicazioni generiche per BSN, deve essere

chiaro che il design e i requisiti delle BAN sono differenti dalle applicazioni tipiche

che utilizzano le WSN. I seguenti punti illustrano le differenze tra BSN e WSN e i

nuovi requisiti introdotti dalle reti di sensori corporali:

• Numero e Densita di sensori

Il numero di nodi sensori/attuatori impiegato dipende da diversi fattori. I

nodi di una BAN sono strategicamente posizionati sul corpo, nascosti nell’ab-

bigliamento o impiantati direttamente all’interno del corpo umano. Mentre le

WSN vengono tipicamente impiegate in ambienti le cui dimensioni sono anche

nell’ordine di metri e chilomentri, le BSN sono organizzate su uno spazio che e

il corpo umano e quindi le distanze sono nell’ordine di millimetri, centimetri e

pochi metri. Inoltre in una BAN tutti i device sono ugualmente importanti e

aggiunti solo quando richiesto dalla applicazione. Questo significa che non so-

no tipicamente impiegati nodi ridondanti come soluzione ai fallimenti, pratica

invece spesso utilizzata nelle WSN. Le BAN, dunque, non sono “node-dense”.

8


Figura 1.5. Requisiti minimi e ottimali per polisonnografia digitale. La risoluzione escelta in accordo alla precisione degli strumenti utilizzati. [19]

• Data-rate

Gran parte delle WSN sono impiegate per monitoraggio “event-based”, dove

eventi possono presentarsi a intervalli irregolari. Al confronto invece le BSN

sono impiegate per registrare le azioni e i parametri fisiologici del corpo uma-

no, che presentano in genere un andamento piu periodico, e che porta a rate

piu stabili per le applicazioni. La grande eterogeneita di dispositivi che com-

pongono una BAN, tuttavia, porta a richieste differenti delle risorse di rete in

termini di data rate, consumo energetico e affidabilita. I tassi di trasmissione

delle applicazioni variano fortemente, da pochi kbit/s a Mbit/s richiesti per il

video streaming. In Figura 1.5 e Figura 1.6 sono mostrate le velocita di tra-

smissione in diverse applicazioni. E possibile osservare che i valori di data rate

per le singole applicazioni non sono alti. Tuttavia se consideriamo una WBAN

con diversi dispositivi (es. dozzine di accelerometri, ECG, EMG. . . ) allora il

tasso del dato aggregato raggiunge facilmente l’ordine dei Mbps, che risulta

piu alto del bit rate di gran parte delle radio utilizzate in queste applicazioni.

L’affidabilita della trasmissione e fornita in termini del BER1 che e utilizzato

come misura del numero di pacchetti persi. Per un dispositivo medico l’af-

fidabilita dipende dal data-rate. Con un dispositivo con data-rate basso si

1Bit Error Ratio: e il rapporto tra i bit non ricevuti correttamente e i bit trasmessi.

9


Figura 1.6. [20] Data-rate di misurazioni biomediche. Formule utilizzate: (a)Bandwidth = fmax – fmin (b) SampleRate = 5 × fmax (c) InformationRate =Resolution× SampleRate

raggiunge un BER alto (es. 10−4), mentre dispositivi con data-rate elevato

permettono un BER basso (es. 10−10). Il BER richiesto dipende, ovviamente,

anche dalla criticita dei dati trasmessi.

• Mobilita

I dispositivi sono posizionati sul corpo umano che puo essere in movimento.

Per questo motivo le BSN devono essere robuste rispetto a frequenti cambi

nella topologia di rete.

• Radiazioni RF

Trasmissioni a bassa potenza devono essere impiegate per minimizzare le in-

terferenze e scongiurare danni alla salute. Bisogna, inoltre, tener conto della

propagazione delle onde nel corpo umano in termini di attenuazione del se-

gnale: le onde saranno attenuate considerevolmente prima di raggiungere la

ricevente.

• Consumo energetico ridotto e “Energy Scavenging”

Il consumo energetico puo essere diviso in tre domini: sensing, comunicazione

wireless e “data processing”. La trasmissione wireless e l’operazione che richie-

de maggior consumo di potenza. La dimensione della batteria e in gran parte

dei casi il contributo piu grande al dispositivo in termini sia di dimensioni che

di peso e per questo motivo viene scelta piu piccola possibile. Questa scelta

10


favorisce dimensioni ridotte ma porta evidentemente allo sviluppo di disposi-

tivi con risorse limitate. In diverse applicazioni, sensori/attuatori all’interno

di una BSN devono operare supportati da un’autonomia della batteria che

non richieda interventi per mesi o anche anni. Questo aspetto e fondamentale

in dispositivi impiantabili e d’altronde la necessita di sostituire o ricaricare

batterie e da evitare anche ove possibile.

L’autonomia di un nodo, dotato di una certa batteria, puo essere migliorata

mediante l’utilizzo di tecniche di “energy scavenging”2 durante l’utilizzo del

sistema. Idealmente se l’energia “accumulata” e piu grande di quella media

consumata, il sistema puo restare in esecuzione all’infinito. Tuttavia, le poten-

ze in gioco vanno da qualche nano-watts a poche centinaia di milli-watts per

centimetro cubo. Una combinazione, quindi, di consumo energetico ridotto e

energy scavenging e la soluzione ottimale per sviluppare WBAN autonome.

Per una BSN, sorgenti alle quali attingere sono il calore e le vibrazioni del cor-

po. Ad esempio un generatore termoelettrico (TEG) e usato per trasformare

la differenza di temperatura tra ambiente e corpo umano in energia elettrica.

Altre applicazioni, invece, utilizzano i passi come sorgente di energia.

Durante la trasmissione radio i dispositivi producono calore che e assorbito dai

tessuti circostanti e innalza la temperatura corporea. Per limitare l’aumento

di temperatura e, in aggiunta, risparmiare la batteria, il consumo energetico

deve essere minimo. La quantita di potenza assorbita dai tessuti e espresso dal

SAR3. Siccome i dispositivi sono in prossimita, o all’interno, del corpo umano

il SAR locale puo essere anche abbastanza alto. Esso deve essere minimizzato

2Energy harvesting (o scavenging) : conversione dell’energia dispersa nell’ambiente, come sotto-prodotto di processi artificiali e naturali, in energia elettrica. L’energia inutilizzata o di scarto epresente ovunque nell’ambiente che ci circonda: luce, vento, differenze di temperatura, onde aradiofrequenze, energia cinetica dalle onde del mare, dalle vibrazioni meccaniche e dal movimentoumano.

3Tasso di assorbimento specifico: misura la quantita di potenza da radio frequenze assorbitadal corpo quando questo e esposto ad un campo elettromagnetico. E definito come la quantita dienergia elettromagnetica che viene assorbita nell’unita di tempo da un elemento di massa unitariadi un sistema biologico. L’unita di misura e il W/kg

11


e rispettare vincoli internazionali. D’altronde i problemi sulla trasmissione in

prossimita del corpo umano sono simili a quelli gia affrontati per i telefoni

cellulari.

• Affidabilita

Una questione cruciale e l’affidabilita della trasmissione al fine di garantire che i

dati monitorati vengano correttamente ricevuti. Parametri di affidabilita sono

consegna garantita dei dati (es. tasso dei pacchetti consegnati), consegna in

ordine. . . Inoltre i messaggi dovrebbero essere consegnati in tempi ragionevoli.

L’affidabilita della rete si riflette direttamente sulla qualita del monitoraggio

del paziente e nel peggiore dei casi puo essere fatale.

• Usabilita

Nella maggioranza dei casi le BSN verranno poi utilizzate dallo staff medico

all’interno di un ospedale, dal paziente stesso e comunque non da ingegneri

esperti. Di conseguenza la rete dovrebbe essere capace di configurarsi e manu-

tenersi automaticamente; tecniche di “self-organization” e “self-maintenance”

devono essere supportate, oltre alla possibilita di riconfigurare facilmente la

rete per aggiungere nuovi servizi.

Quando un nodo viene preso, posizionato sul corpo e acceso esso deve essere

in grado in maniera automatica di attaccarsi alla rete senza richiedere alcun

intervento esterno.

I dispositivi, infine, devono essere piccoli per costruire BAN “invisibili” al

paziente.

• Sicurezza e Privacy

La comunicazione dei dati, che contengono informazioni mediche, tra nodi in

una BSN, e dove previsto su Internet, deve essere assolutamente privata e

confidenziale, oltre ad essere cifrata, per garantire la privacy del paziente. Lo

staff medico che raccoglie i dati di un paziente deve essere certo che quei dati

12


non sono stati manomessi e che siano effettivamente di quel paziente. Inoltre

bisogna ricordare che chi utilizza la rete non e un ingegnere e quindi non ci si

puo aspettare che lo staff medico o il paziente siano capaci di settare e gestire

i processi di autenticazione e autorizzazione. Il tutto deve avvenire in maniera

automatica e trasparente agli utenti. In aggiunta la rete deve essere accessibile

anche a coloro che ad esempio non possono inserire password perche disabili.

Tecniche che garantiscano sicurezza e privacy, infine, sono computazionalmente

onerose e quindi andrebbero riviste per essere “energy efficient” e leggere.

La Tabella 1.1 esplora alcune delle differenze tra WSN e BSN gia proposte sopra

e ne aggiunge altre fornendo un quadro completo sui nuovi requisiti delle BSN,

rispetto alla tecnologia delle WSN.

1.3 Monitoraggio pervasivo del paziente

Oggigiorno in gran parte dei sistemi sanitari il personale inadeguato, errori me-

dici, l’impossibilita in aree rurali di raggiungere l’ospedale in tempo, i costi enormi,

stanno peggiorando il servizio di assistenza offerto ai cittadini. Il concetto di “ubi-

quitous” e “pervasive monitoring”4 di parametri fisici, fisiologici e biochimici in

qualsiasi ambiente e senza vincoli sulle attivita che il paziente puo compiere e diven-

tato realta solo recentemente con i progressi nei sensori, processori miniaturizzati e

le comunicazioni wireless.

I notevoli progressi in aree chiavi quali la miniaturizzazione e la lunga durata delle

batterie, il ridotto consumo energetico sono fondamentali per i sistemi che attuano

un monitoraggio pervasivo, particolarmente con l’utilizzo di sensori impiantabili.

La tecnologia MEMS (Micro Electro-Mechanical System) e un’altra area che offre

4Lo ubiquitous computing (o ubicomp) e un modello post-desktop di interazione uomo-macchinain cui l’elaborazione delle informazioni e stata interamente integrata all’interno di oggetti e attivitadi tutti i giorni. Opposto al paradigma del “desktop”, in cui un utente aziona consciamente unasingola apparecchiatura per uno scopo specifico, chi utilizza lo ubiquitous computing aziona diversisistemi e apparecchiature di calcolo simultaneamente, nel corso di normali attivita, e puo anchenon essere cosciente del fatto che questi macchinari stiano compiendo le proprie azioni e operazioni.

13


Tab

ella

1.1

.D

iffer

enze

tra

WS

Ne

BS

N.

Diff

eren

ze

WS

NB

SN

Sca

laG

ran

de

tanto

qu

anto

l’am

bie

nte

da

mon

itora

re(m

etri

/ch

ilom

etri

)G

ran

de

qu

anto

lep

art

id

elco

rpo

um

an

o(m

illim

etri

/ce

ntr

imet

ri/p

och

im

etri

)

Nu

mer

od

in

odi

Ilp

iugra

nd

enu

mer

od

in

od

iri

chie

sto

per

elev

ata

acc

ura

tezz

ae

are

ad

ico

per

tura

este

saIl

piu

pic

colo

poss

ibile

(lim

itati

dallo

spazi

o)⇒

rich

iest

in

od

ise

nso

rip

iuacc

ura

ti

Fu

nzi

on

ed

ein

odi

Sen

sori

mu

ltip

li,

ognu

no

eseg

ue

ilp

rop

rio

com

pit

oS

enso

risi

ngoli,

ognu

no

eseg

ue

piu

com

pit

i

Acc

ura

tezz

ad

ein

odi

Un

nu

mer

oel

evato

di

nod

i(r

idon

dan

za)

com

pen

sal’acc

ura

tezz

ae

per

met

tela

valid

azi

on

ed

eiri

sult

ati

Nu

mer

od

in

od

ilim

itato

(nes

sun

ari

dond

aza

).O

gn

in

od

od

eve

esse

rero

bu

sto

eacc

ura

to

Dim

ensi

on

id

ein

odi

Dim

ensi

on

ip

icco

lep

refe

rib

ili

ma

non

son

ou

na

lim

itazi

on

est

rin

gen

tein

molt

ica

siIl

mon

itora

ggio

per

vasi

vo

nec

essi

tad

im

inia

turi

zzazi

on

e

Din

am

ica

Esp

ost

ia

con

diz

ion

iam

bie

nta

lies

trem

ee

rum

ore

Esp

ost

ia

un

am

bie

nte

piu

pre

ved

ibile

ma

suss

iste

ilp

rob

lem

ad

eim

ovim

enti

corp

ore

i

Det

ecti

on

di

even

tiR

icon

osc

imen

tod

iev

enti

avver

sid

esid

erab

ile;

ilfa

llim

ento

spes

soe

rever

sib

ile

Ilri

con

osc

imen

tod

iev

enti

avver

sie

di

imp

ort

an

zavit

ale

;il

fallim

ento

eir

rever

sib

ile

Va

ria

bili

taM

aggio

rip

rob

ab

ilit

ad

iaver

eu

na

stru

ttu

rafi

ssa

Vari

azi

on

ibio

logic

he

imp

lica

no

un

ast

rutt

ura

piu

vari

ab

ile

Pro

tezi

on

ed

eid

ati

Liv

ello

piu

bass

od

isi

cure

zza

del

trasf

erim

ento

dati

sen

zafi

liri

chie

sto

Liv

ello

di

sicu

rezz

ari

chie

sto

alt

op

ergara

nti

rala

pri

vacy

del

pazi

ente

Ali

men

tazi

on

eA

cces

sib

ile

ep

oss

ibilit

ad

ies

sere

cam

bia

tap

iufa

cilm

ente

efr

equ

ente

men

teIn

acc

essi

bile

ed

iffico

lta

nel

laso

stit

uzi

on

ep

erse

nso

riim

pia

nta

bili

Po

ten

zari

chie

sta

Pu

oes

sere

maggio

rein

qu

anto

l’alim

enta

zion

ep

uo

esse

reso

stit

uit

ap

iufa

cilm

ente

Dovre

bb

ees

sere

lap

iub

ass

ap

oss

ibile

sicc

om

el’alim

enta

zion

ee

poco

acc

essi

bile

En

ergy

Sca

ven

gin

gE

ner

gia

sola

reed

eoli

caso

no

im

aggio

rica

nd

idati

Movim

enti

(vib

razi

on

i)e

calo

reco

rpore

oso

no

im

aggio

rica

nd

idati

Acc

esso

Sen

sori

piu

faci

lmen

teso

stit

uib

ili

oan

che

usa

eget

taIl

rim

pia

zzam

ento

di

sen

sori

imp

ianta

bili

eco

mp

less

oe

rich

ied

eb

iod

egra

dab

ilit

a

Bio

com

pati

bili

taN

on

con

sid

erata

nel

lam

aggio

ran

zadel

leap

plica

zion

iR

equ

isit

ofo

nd

am

enta

led

ari

spet

tare

sia

per

sen

sori

este

rni

che

imp

ianta

bil

i.P

uo

au

men

tare

ico

sti

Co

nte

xtA

wa

ren

ess

Non

cosı

imp

ort

ante

inam

bie

nti

ben

defi

nit

iM

olt

oim

port

ante

per

che

ip

ara

met

rifi

siolo

gic

iso

no

fort

emen

ted

ipen

den

tid

aca

mb

iam

enti

nel

conte

sto

Tec

no

logi

ew

irel

ess

Blu

etooth

,Z

igB

ee,

GP

RS

,W

LA

N..

.T

ecn

olo

gie

wir

eles

sa

bass

oco

nsu

mo

ener

get

ico

rich

iest

e

Tra

sfer

imen

tod

ati

La

per

dit

ad

id

ati

du

rante

iltr

asf

erim

ento

wir

eles

sp

uo

esse

reco

mp

ensa

tod

ari

don

dan

zad

ein

od

ise

nso

riP

erd

ita

di

dati

maggio

re(n

on

c’e

rid

on

dan

za),

pu

ori

chie

der

em

i-su

razi

on

iad

diz

ion

ali

per

ass

icu

rare

QoS

eca

paci

tad

im

on

itora

ggio

real-

tim

e

14


Figura 1.7. (Sinistra) CardioNET (Destra) Sensore inserito all’interno di un anello

la prospettiva di un sensing sofisticato con l’utilizzo di dispositivi di dimensioni

ridottissime. Sistemi pervasivi nell’assistenza sanitaria, utilizzando su larga scala le

tecnologie offerte da BSN e WSN, daranno accesso a informazioni mediche accurate

in ogni luogo e momento, migliorando la qualita del servizio offerto.

Per la prima volta i medici hanno la possibilita non solo di monitorare i pazienti

da piu vicino ma di poterlo fare in ambienti dove mai prima si era stati capaci di

monitorare un paziente.

In un ambiente ospedaliero l’abilita di catturare dati continuamente su un pa-

ziente, o su una persona a cui non e stata ancora diagnosticata una malattia ben

precisa, ha il potenziale di permettere la “detection” di eventi avversi quanto prima

possibile e di avviare, dunque, trattamenti medici tempestivi ancor prima che l’even-

to dannoso vero e proprio si verifichi realmente. Per il paziente, inoltre, potra non

essere obbligatorio restare a letto o comunque all’interno della struttura ospedaliera

affinche il monitoraggio prenda atto, incrementando dunque la mobilita e il ritorno

alla vita quotidiana. D’altra parte solo l’introduzione di un sistema automatico di

monitoraggio pervasivo permette la memorizzazione di tutti i dati, che altrimenti

andrebbero parzialmente persi, per analisi off-line successive.

Nel tentativo di realizzare un sistema che monitori continuamente il paziente,

diverse sono le piattaforme emerse nel corso degli ultimi anni. Alcune utilizzano

sensori inseriti all’interno dell’abbigliamento o in accessori in modo da realizzare

15


Figura 1.8. Code Blue (Harvard University)

una “BAN indossabile” utilizzabile dal paziente in maniera completamente naturale.

E stato introdotto il concetto di “smart shirt” oppure “e-textile” laddove i sensori

sono inseriti in vestiti e tessuti.

In Figura 1.7 alla destra e mostrata la possibilita di inserire un sensore, ad

esempio un accelerometro MEMS, all’interno di un anello. Alla sinistra e mostrato

CardioNET, utilizzabile da pazienti con malattie cardiache: un sistema di telemetria

cardiaco costituito da tre sensori ECG connessi a un PDA che processa e visualizza

i dati di interesse, permettendo quindi il rilevamento di disturbi cardiaci in casa, al

lavoro, in viaggio.

In Figura 1.8, invece, e raffigurato il risultato del progetto “Code Blue” col quale e

stata realizzato una rete di sensori, utilizzando le piattaforme MicaZ e Telos, formata

da un “pulsossimetro”5, un sensore ECG e capace di “activity recognition”.

Tutte le soluzioni proposte hanno uno scopo comune: prevedere un monitoraggio

“discreto” e pervasivo del corpo umano indipendentemente dalla locazione geografica.

Inserire i sensori negli indumenti ha il vantaggio di creare un sistema indossabile piu

facilmente ma manca in flessibilita nel caso in cui si debba aggiungere o redistribuire

i sensori come suggerito dalla fisionomia del paziente. D’altra parte lo sviluppo di

sensori impiantabili utilizzabili in BSN e sicuramente la prospettiva futura piu ecci-

tante ma con il loro utilizzo il wiring e impraticabile e il “placement” dei sensori ha

numerosi vincoli. L’obiettivo e quello di progettare piattaforme dedicate che utiliz-

5dispositivo medico che misura indirettamente la saturazione di ossigeno nel sangue del paziente

16


zino sensori impiantabili ed esterni in modo da ottenere una rete di sensori quanto

meno intrusiva possibile e che nello stesso tempo offri la possibilita di aggiungere e

rimuovere sensori come necessario.

1.3.1 Context-Aware Sensing e Activity Recognition

Accanto al concetto di “pervasive computing” negli ultimi anni ha ottenuto con-

siderevole interesse il concetto di “context-aware computing” che si riferisce a una

classe di sistemi capaci di rilevare il “contesto” e di modificare il proprio comporta-

mento in accordo ad esso. La popolarita di architetture context-aware e dovuta alla

crescente ubiquita dei sensori e quindi alla diversita di ambienti in cui i segnali sono

raccolti. Il contesto e definito da Schilit, il primo a introdurre il concetto, come “le

circostanze in cui un evento si presenta”[8]. Altrettanto significativa e la definizione

di contesto e di sistema context-aware data da Dey e Abowd [9]: “Il contesto e

qualsiasi informazione che puo essere usata per caratterizzare lo stato di un’entita,

dove un’entita e una persona, un luogo o un oggetto fisico che e considerato rilevan-

te all’interazione tra un utente e un’applicazione. [. . . ] Un sistema e context-aware

se usa il contesto per fornire informazioni e/o servizi pertinenti all’utente, dove la

pertinenza dipende dai compiti dell’utente.”

Le caratteristiche principali per applicazioni context-aware, dunque, possono essere

considerate come:

1. presentazione dei dati e dei servizi in accordo al contesto corrente in modo da

fornire un supporto “intelligente” all’utente;

2. esecuzione automatica di servizi;

3. “tagging” del contesto al dato per il “retrieval” successivo.

In Tabella 1.2 sono riassunte le considerazioni sulla progettazione di sistemi context-

aware.

17


Tabella 1.2. Considerazioni su sistemi context-aware.

Informazioni principali del “contesto”

– Identita; identificazione dell’utente

– Informazione spaziale; posizione, orientamento, velocita e accelerazione

– Informazione temporale; ora del giorno, data, stagione dell’anno

– Informazione Ambientale; temperatura, qualita dell’aria, luce, livello di rumore

– Interazione sociale; con chi sei e le persone vicine

– Risorse in prossimita; device e host accessibili

– Disponibilita delle risorse; batteria, display, rete, banda

– Misurazioni fisiologiche; pressione sanguigna, battito cardiaco, frequenza del respiro, tono divoce e emozioni

– Attivita; parlare, leggere, camminare, correre

Le cinque W del contesto

Who (Chi) – l’identita dell’utente e/o le persone nell’ambiente

What (Cosa) – attivita e interazioni della persona nel sistema corrente

Where (Dove) – l’ambiente in cui l’attivita si svolge

When (Quando) – “timestamp” dei record salvati

Why (Perche) – stati della persona

Il context-awareness gioca un ruolo fondamentale nelle Body Sensor Networks

perche interpreta i segnali fisici e biochimici acquisiti da sensori impiantabili e in-

dossabili rispetto allo stato corrente dell’utente e dell’ambiente esterno. I fattori

caratterizzanti il contesto sono focalizzati sulle attivita del paziente, il suo stato

fisiologico e l’ambiente fisico che lo circonda e possono includere le attivita svol-

te dall’utente, la temperatura corrente dell’ambiente esterno, ora del giorno,etc.

Piu precisamente potremmo distinguere l’informazione contestuale in quella “user-

centred”, che include attivita fisiche o cognitive/mentali e lo stato emozionale,

e quella “enviroment-centred”, che include posizione, tempo, interazioni sociali,

connessione con dispositivi, etc.

L’informazione contestuale e ampiamente utilizzata per migliorare l’accuratezza

delle diagnosi realizzate a partire dal segnale acquisito. Questo perche dati simili

possono essere interpretati in maniera differente rispetto alle attivita correnti del

paziente e solo un accurato “context sensing” puo permettere la distinzione tra in-

formazioni “importanti” e “non importanti” nella grande quantita di dati acquisita.

18


Ad esempio, la causa di un rapido incremento del battito cardiaco osservato nel-

l’ECG puo essere il risultato dell’attivita fisica svolta dal paziente piuttosto che di

un sintomo di soggetto iperteso. Per queste ragioni segnali che permettono la de-

tection dei movimenti vengono acquisiti in situ ed utilizzati per “recuperare” i dati

provenienti dai sensori, “corrotti” dai movimenti della persona.

Attualmente il settore della ricerca ha indirizzato gran parte della sua attenzione

all’activity recognition e in particolare all’uso di sensori inerziali applicati al rileva-

mento di movimenti. In questo modo e possibile registrare le attivita quotidiane

della persona e utilizzare questa informazione come indicatore del suo stato di salu-

te oppure, come nel caso dell’esempio appena descritto, per contestualizzare i dati

fisiologici acquisiti. D’altra parte le attivita fisiche svolte rappresentano un’informa-

zione contestuale user-centred fondamentale in una applicazione BSN context-aware.

Ancora il rilevamento di movimenti puo essere utilizzato in applicazioni per pazienti

invalidi agli arti per ottenere una misura oggettiva del grado di disabilita oppure

nell’importante obiettivo di rivelare cadute accidentali di persone anziane.

In [10] gli RSSI6 tra due nodi sensori e un gateway opportunamente posizionati

rispettivamente sul braccio, avambraccio e giro vita sono utilizzati per il riconosci-

mento di 3 attivita motorie e, tramite analisi in frequenza, della velocita di esecu-

zione, al fine di realizzare un’applicazione che assisti nella riabilitazione dell’arto.

L’uso di BAN indossabili per gestire la riabilitazione e una prospettiva attrattiva

perche consente di registrare misure quantitative in ambienti che vadano oltre quello

ospedaliero o clinico.

Infine ricerche esistenti stanno investigando sulla relazione tra le attivita svolte

e i progressi in malattie croniche.

La documentazione e piuttosto vasta, soprattutto per quanto concerne la classi-

ficazione tramite dati raccolti da accelerometri e giroscopi. Le problematiche chiave

affrontate in tali studi riguardano in particolare:

6Misura della potenza del segnale alla ricevente

19


Tab

ella

1.3

.S

tato

del

l’ar

tesu

lri

con

osc

imen

tod

iat

tivit

am

otor

ieco

nse

nso

riin

erzi

ali

Rif

erim

ento

inle

tteratu

ra

Att

ivit

aric

on

osc

iute

Meto

do

di

cla

s-si

ficazio

ne

Nr.

dis

posi

tivi

ind

oss

ati

Att

rib

uti

dei

dati

per

cla

ssifi

care

Sp

ecifi

ch

ed

ei

dis

posi

tivi

uti

lizzati

Ravi,

Dan

dek

ar,

Act

ivit

yR

e-co

gn

itio

nfr

om

Acc

eler

om

e-te

rD

ata

,R

utg

ers

Un

iver

sity

,2005

8:

stare

inp

ied

i,ca

mm

ina-

re,

corr

ere,

salire

/sc

end

ere

lesc

ale

,la

vars

ii

den

ti,

alz

ars

i,u

sare

l’asp

irap

olv

ere.

Met

aC

lass

ifier

sw

ith

Plu

rality

Voti

ng

1:

posi

zion

ato

inzo

na

pel

vic

a.

Med

ia,

dev

iazi

o-

ne,

stan

dard

,co

r-re

lazi

on

e,en

ergia

.

Dis

posi

tivo

ad

hoc

con

cap

a-

cita

di

com

un

icazi

on

ese

nza

fili

tram

ite

Blu

etooth

.

Bao,

Inti

lle,

Act

ivit

yR

eco-

gn

itio

nfr

om

Use

rA

nn

ota

ted

Data

,M

IT,

2004

20:

cam

min

are

,se

der

si,

leg-

ger

e,la

vora

real

Pc,

usa

rel’asp

irap

olv

ere

ecc.

Alb

ero

di

dec

isio

-n

e3:

cosc

ia,

an

ca,

pols

o.

Med

ia,

ener

gy,

en-

trop

ia,

corr

elazi

o-

ne.

Dis

posi

tivo

ad

hoc

con

fun

-zi

on

alita

di

com

un

icazi

on

era

-d

ioe

di

salv

ata

ggio

sum

emo-

ria

Com

pact

Fla

sh.

Inte

gra

un

acc

eler

om

etro

bia

ssia

le.

Olg

uin

,P

entl

an

d,

Hu

man

Ac-

tivit

yR

ecogn

itio

n:

Acc

ura

cyacr

oss

Com

mon

Loca

tion

sfo

rW

eara

ble

Sen

sors

,M

IT,

2006

8:

sed

ersi

,co

rrer

e,acc

ucc

iar-

si,

cam

min

are

,st

are

inp

ie-

di,

avan

zare

gatt

on

i,sd

raia

rsi,

mu

over

ela

man

o.

Hid

den

Mark

ov

Mod

els

3:

pols

od

estr

o,

cosc

iasi

nis

tra,b

u-

sto.

Med

ia,

vari

an

za,

acc

eler

azi

on

ip

u-

re.

Dis

posi

tivi

ad

hoc

chia

mati

MIT

es.

Foer

ster

,M

oti

on

Patt

ern

an

dP

ost

ure

s,A

sses

sed

by

Cali-

bra

ted

Acc

eler

om

eter

s,F

rei-

bu

rgU

niv

ersi

ty,

2000

Div

erse

att

ivit

ap

erd

iver

seco

nfi

gu

razi

on

id

eln

od

o.

An

alisi

del

letr

an

-si

zion

itr

ast

ati

Div

erse

poss

ibilit

aan

alizz

ate

.A

ccel

erazi

on

ip

u-

re.

Acc

eler

om

etri

colleg

ati

con

un

dis

posi

tivo

di

salv

ata

ggio

di

tip

oV

itap

ort

2.

Am

inia

n,

Cap

turi

ng

Hu

man

Moti

on

Usi

ng

Bod

yfi

xed

Sen

-so

rs:

Ou

tdoor

Mea

sure

men

tan

dC

lin

ical

Ap

plica

tion

s,S

wis

sIn

stit

ute

of

Tec

hn

olo

gy,

2004

4:

stati

che

(rip

osa

re,

sed

e-re

,st

are

inp

ied

i),

din

am

ich

e(c

am

min

are

).

Patt

erm

oto

ri,

tran

sizi

on

ed

ip

ost

ura

1:

bu

sto.

Acc

eler

azi

on

ever

-ti

cale

.S

ingolo

dis

posi

tivo

con

acc

ele-

rom

etro

egir

osc

op

ioco

lleg

a-

tovia

cavo

au

nd

isp

osi

tivo

di

salv

ata

ggio

dati

(Physi

log

Data

Logger

)p

ersu

cces

siva

an

alisi

.

Manty

jarv

iet

al.

,R

ecogn

izin

gH

um

an

Moti

on

wit

hM

ult

i-p

leA

ccel

erati

on

Sen

sors

,O

u-

luU

niv

ersi

ty,

Fin

land

(Nokia

lab

),2001

4:

iniz

iom

oto

,fi

ne

moto

,ca

mm

inare

,sa

lire

lesc

ale

.R

eti

neu

rali

2:

an

ca.

PC

A,

ICA

per

lagen

erazi

on

ed

elvet

tore

del

lefe

atu

re

Dis

posi

tivi

colleg

ati

con

cavi.

20


• la quantita e la posizione dei sensori indossati;

• la definizione del processo necessario per trasformare delle primitive informa-

zioni riguardanti l’accelerazione in classi di movimento.

La Tabella 1.3 offre una panoramica su alcune delle applicazioni sviluppate riguar-

danti l’activity recognition.

Un’altra importante informazione contestuale e lo stato emozionale del paziente.

In [11] e descritto un framework che rileva, a partire da variazioni nell’EMG7, diversi

stati emozionali quali collera, odio, dolore, amore platonico, gioia.

In aggiunta, l’utilizzo dell’informazione legata al contesto e stata usata per svi-

luppare ambienti “intelligenti” nell’assistenza sanitaria. In [12] e illustrato l’utilizzo

della tecnologia RFID per identificare i pazienti e il loro team di infermieri e medici

associato.

I vantaggi portati dal context-awareness sono dunque chiari. Prima informazioni

sul contesto del paziente erano acquisiti manualmente dal paziente stesso attraverso

diari o questionari. Questo metodo, oltre a richiedere grandi quantita di tempo, e

anche inaffidabile, specialmente nel caso di persone anziane con problemi di memo-

ria. Un altro metodo di acquisizione e attraverso osservazioni cliniche che tuttavia

richiedono personale qualificato e laboratori dedicati; inoltre e ormai chiaro che i

dati acquisiti in ambiente clinico non riflettono il comportamento reale del paziente

nel suo ambiente domestico. Oggi e possibile, invece, provvedere a un monitoring

pervasivo del soggetto nel suo stato naturale attraverso i nuovi concetti di ubiquitous

e context-aware computing.

Il context-aware sensing e, quindi, parte integrante nel design di WBSN al fine

di conseguire l’obiettivo finale di un monitoraggio pervasivo a lungo termine.

7L’elettromiografia misura i potenziali elettrici che si formano in un muscolo durante la suacontrazione volontaria.

21


Figura 1.9. CardioMEMS: sensore di pressione utilizzato per la rilevazione di aneurismi.

1.3.2 Monitoraggio nell’ambiente ospedaliero

All’interno dell’ambiente ospedaliero un numero enorme di pazienti con diverse

malattie sono curati ogni anno. Attualmente il monitoraggio offerto ai degenti in

ospedale varia da “intermittente” (4 a 6 volte al giorno per pazienti in condizioni

stabili), a “intensivo” (ogni ora) e infine a “continuo”, in maniera invasiva o non

invasiva, con la strumentazione medica attuale. Il monitoraggio e basato su misure di

parametri vitali (pressione del sangue, temperatura corporea, ECG. . . ), l’assicurarsi

visivamente del livello di coscienza dei pazienti e su risposte verbali (chiedendo loro

il grado di sofferenza).

I pazienti che subiscono un’operazione sono certamente una classe il cui livel-

lo di monitoraggio varia da alto, durante e immediatamente dopo l’intervento, a

intermittente, durante il periodo di ricovero post-operazione. Allo stato attuale il

monitoring di parametri vitali e limitativo, “wired”8, “labour-intensive” e richiede

misurazioni e documentazione manuale, lasciando spazio a errori umani. Automa-

tizzare questo processo dando la possibilita di monitorare il paziente ovunque egli

e nell’ospedale, e non solo quando riposa nel suo letto, e desiderabile non solo per i

professionisti ma per il paziente stesso. L’utilizzo di sensori impiantabili in scenari

post-intervento e gia cominciato: e stato gia utilizzato un sensore con il compito

di monitorare la pressione in sacche aneurismatiche9 createsi in seguito a problemi

8In informatica si distingue tra tecnologie wired e wireless. Nelle prime i dispositivi comunicanotramite cavi, nelle seconde con trasmissioni RF

9Un aneurisma e una dilatazione progressiva di forma varia, generalmente sacculare, di unsegmento di un’arteria, che e stata causata da un’anomalia della parete del vaso sanguigno.

22


Figura 1.10. Legame tra i costi dell’assistenza sanitaria, la Qualita della Vita e l’ambientein cui le cure avvengono (Fonte: Intel)

endovascolari (Figura 1.9).

Il prossimo passo per ogni “ospedale del futuro” deve essere l’adozione di un

sistema di monitoraggio pervasivo, interno e/o esterno al degente, che abiliti gli

assistenti sanitari a predire, diagnosticare e reagire tempestivamente a eventi avversi

come mai prima e stata fatto.

1.3.3 Monitoraggio nell’ambiente domestico

L’altro scenario dove le BSN aggiungono nuove prospettive e certamente la

straordinaria possibilita di un monitoraggio regolare e non-intrusivo della popo-

lazione “a rischio”, ad esempio degli anziani. D’altronde il monitoraggio pervasivo

e tale se la persona viene monitorata dove effettivamente essa spende gran parte

del suo tempo. Come accennato nella sezione 1.1 l’idea di spostare il punto di as-

sistenza a casa del paziente puo aiutare a superare il peso economico e sociale di

una popolazione globale che sta invecchiando. Lo sviluppo tecnologico in supporto

all’assistenza sanitaria a casa ha il potenziale di ridurre drasticamente la pressione

L´aneurisma, nella maggior parte dei casi, e una malformazione di piccolo volume a sviluppolento o nullo e senza alcuna manifestazione clinica. I sintomi quindi sono nella grande maggio-ranza dei casi associati alla rottura della sacca aneurismatica, che generalmente avviene in modoimprovviso e senza sintomi premonitori.

23


sulle strutture ospedaliere ma rimane ancora una sfida significativa perche, come

verra successivamente messo in evidenza, alcune delle soluzioni tecnologiche ancora

non esistono o sono in una fase prototipale. La Figura 1.10 evidenzia i benefici

economici di spostare l’assistenza sanitaria nell’ambiente domestico ove possibile.

Il concetto di una “Home Sensor Network” non intrusiva per monitorare persone

anziane, o anche persone appena dimesse dall’ospedale, e l’altra grande innovazione

introdotta dalle WBAN. WSN (in casa del paziente) e BSN (sul corpo del paziente)

si affiancano e sovrappongono nelle loro applicazioni ; applicazioni che supportano

chi si prende cura del malato o dell’anziano (medici, membri della famiglia, vicini,

amici) con un modo innovativo di monitorare la persona, incrementando il livello di

comunicazione tra i fruitori e permettendo tempi di intervento piu brevi, sia nella

prevenzione che nel caso di crisi acute, che consentiranno di migliorare la degenza

e salvare vite. Una HSN, che dara feedback non solo a chi si occupa del pazien-

te ma al paziente stesso, sara formata da una WSN tradizionale, che monitora ad

esempio l’ambiente, e comunica con una BAN che trasmette dati fisiologici dell’in-

dividuo. Combinando le due reti si apprezzera meglio il contesto nel quale il sensing

e effettuato.

Questo nuovo approccio, nonostante la nuova realta sociale e che molti dei mem-

bri della famiglia sono geograficamenti lontani dall’anziano, permette ancora ai fami-

liari di giocare un ruolo attivo nella cura dei propri parenti e genitori superando pero

l’onere di un monitoraggio in prima persona 24 ore su 24 e 7 giorni alla settimana. I

sistemi “home-care”, in aggiunta, daranno la possibilita alle persone di monitorare

se stessi con dispositivi che forniranno “proactive warnings” della malattia in modo

da rivolgersi al medico prima, quando la cura puo dare risultati migliori.

I benefici, d’altra parte, sono non solo per i familiari ma anche per i medici stessi

che saranno affiancati da un “assistente elettronico”, offrendo ai pazienti il beneficio

di diagnosi e trattamenti piu rapidi. Le WBSN possono rilevare piccoli cambiamenti

nei parametri vitali che in una visita medica tradizionale potrebbero non essere

24


riscontrati. Inoltre i problemi dovuti alla cosiddetta “sindrome da camice bianco”,

che alterano i risultati dei test e sono dovuti allo stress e l’ansia associati a una

visita clinica, possono essere superati. Infine la raccolta di dati eseguita in maniera

trasparente e su periodi lunghi in un “habitat” naturale riflettera maggiormente i

valori veri per un dato parametro.

Deve essere chiaro, tuttavia, che il modello di home-care e progettato non per

sostituire il ruolo fondamentale degli ospedali, centri specializzati e medici nell’as-

sistenza sanitaria ma per includere il paziente, l’anziano, come partecipante attivo,

“man-in-the-loop”, nella propria cura e in particolare in quella di routine.

1.3.4 Monitoraggio di pazienti con malattie croniche

L’importanza di monitorare pazienti nell’assistenza sanitaria puo essere apprez-

zata solo se si pensa alla gran quantita di malattie croniche esistenti e la necessita di

anticipare quanto prima possibile la loro diagnosi e il trattamento. Diversi sono gli

esempi che illustrano questa necessita ma di seguito saranno utilizzati come esempi

l’ipertensione e il diabete. Al Capitolo 3, invece, verra discusso l’utilizzo delle BSN

nello studio del morbo di Parkinson e in particolare l’analisi del tremore mediante

accelerometri nei diversi stadi caratterizzanti la malattia.

La causa principale di morte nel mondo sono le malattie cardiovascolari. In accor-

do con la World Hearth Organisation circa 17.5 milioni di persone all’anno muore per

attacchi cardiaci o infarti. Un esempio di malattia cardiovascolare e l’ipertensione10.

Una diagnosi in tempo della pressione sanguigna alta e importante sia per controllare

fattori di rischio quali fumo, colesterolo alto, sia per l’avvio tempestivo dei tratta-

menti. Una volta che al paziente e stata diagnosticata l’ipertensione, e richiesto un

monitoraggio regolare della pressione per assicurare la correttezza della terapia. Nel

corso della vita del paziente la terapia farmacologica potrebbe cambiare anche nu-

merose volte. Si puo facilmente immaginare quanto “labour-intensive” possa essere

10L’ipertensione arteriosa e un aumento a carattere stabile della pressione arteriosa nellacircolazione

25


l’attivita di monitoraggio della pressione sanguigna, oltre a richiedere visite mediche

frequenti. Le BSN permettono ai medici di monitorare pazienti sospettati di soffrire

di ipertensione durante la loro vita quotidiana, correlare i risultati con le abitudi-

ni del paziente per meglio capire quale terapia avviare e monitorare i risultati del

trattamento scelto.

Nel mondo oltre 246 milioni di persone soffre di diabete, numero che le proiezioni

si aspettano arrivi a 380 milioni nel 2025. La diagnosi e fatta misurando il valore

di glicemia11 che risulta piu alta dei valori tipici. Una volta diagnosticato, ai pa-

zienti e richiesta la somministrazione regolare dell’insulina piu volte al giorno e il

controllo del livello di glucosio con apparecchiature che richiedono la puntura con

un piccolo ago. Questo metodo e chiaramente invasivo e poco desiderabile ma non

ci sono alternative altrettanto affidabili. Utilizzando le BSN nel monitoraggio dei

diabetici, impiegando un glucometro12 impiantabile o indossabile e possibile non solo

monitorare il livello di glucosio del paziente ma, affiancando un somministratore di

insulina, implementare un controllo a ciclo chiuso che di fatto realizzi un “pancreas

artificiale”.

I due esempi sopra citati illustrano il bisogno di un monitoring fisiologico e bio-

chimico continuo. D’altronde, solo il monitoraggio continuo puo “catturare episodi”

sporadici, caratterizzanti una data malattia, di cui non si possono conoscere a priori

i tempi in cui si presenteranno. Attualmente gran parte delle malattie croniche so-

no curate attraverso una serie di “fotografie” ottenute in ambiente clinico, che non

offrono quindi continuita di monitoraggio e sono acquisite in un ambiente che resta

artificiale rispetto al normale ambiente in cui il paziente vive.

In Tabella 1.4 sono elencate alcune malattie croniche e i parametri che potrebbero

essere utilizzati per il loro monitoraggio.

11Valore della concentrazione di glucosio nel sangue.12Strumento per la misurazione del tasso di glicemia nel sangue

26


Tab

ella

1.4

.M

alat

tie

cron

ich

ee

ip

ara

met

rico

mu

nem

ente

usa

tip

erm

onit

orar

le.

Iti

pi

di

sen

sori

sugg

erit

ip

erla

mis

ura

zion

edi

qu

esti

par

amet

riso

no

elen

cati

tra

pare

nte

si.

Tutt

equ

este

pat

olog

ieat

tual

men

tera

pp

rese

nta

no

un

pes

oec

onom

ico

elev

ato

per

ilS

iste

ma

San

itar

io,

pes

och

ep

otr

ebb

ees

sere

rid

otto

sequ

este

mal

atti

efo

sser

op

ronta

men

tedia

gnos

tica

te.

Pato

logie

Param

etr

ifi

siolo

gic

i(T

ipo

di

sen

sore

BS

N)

Param

etr

ib

ioch

imic

i(T

ipo

di

sen

sore

BS

N)

Iper

ten

sion

eP

ress

ion

esa

ngu

ign

a(m

ecca

nore

cett

ore

imp

ianta

bil

e/

ind

oss

ab

ile)

Ad

ren

oco

rtic

ost

eroid

ei(b

iose

nso

reim

pia

nta

bile)

Card

iop

ati

ais

chem

ica

Ele

ttro

card

iogra

mm

a(s

enso

reE

CG

imp

ianta

bile

/in

doss

ab

ile)

Tro

pon

ina,

crea

tin

ina

chin

asi

(bio

sen

sore

imp

ianta

bile)

Ari

tmia

Card

ia-

ca/

Insu

ffici

enza

card

iaca

Fre

qu

enza

di

batt

ito,

pre

ssio

ne

san

gu

ign

a,

EC

G(m

ecca

nore

cet-

tore

imp

ianta

bile

/in

doss

ab

ile

ese

nso

reE

CG

)T

rop

on

ina,

crea

tin

ina

chin

asi

(bio

sen

sore

imp

ianta

bile)

Can

cro

(sen

o,

pro

stata

,p

olm

oni,

colo

n)

Per

dit

ad

ip

eso

(sen

sore

di

gra

sso

corp

ore

o)

(mec

can

ore

cett

ore

imp

ianta

bil

e/

ind

oss

ab

ile)

Mark

ertu

mora

li,

rile

vam

ento

di

san

gu

e(u

rin

a,f

eci,

sali

va)

(bio

sen

sori

imp

ianta

bili)

Asm

aR

esp

irazi

on

e,p

icco

del

flu

sso

resp

irato

rio,

satu

razi

on

eoss

igen

o(m

ecca

nore

cett

ore

imp

ianta

bile

/in

doss

ab

ile)

Pre

ssio

ne

parz

iale

del

l’oss

igen

o((

sen

sore

ott

ico

imp

ianta

bi-

le/

ind

oss

ab

ile,

sen

sore

imp

ianta

bile)

Morb

od

iP

ark

inso

nA

nd

atu

ra,

trem

ore

,to

no

mu

scola

re,

att

ivit

a(E

EG

ind

oss

ab

ile,

acc

eler

om

etro

,gir

osc

op

io)

Liv

ello

di

dop

am

ina

nel

cerv

ello

(bio

sen

sore

imp

ianta

bile)

Morb

od

iA

lzh

eim

erA

ttiv

ita,

mem

ori

a,

ori

enta

men

to,

cogn

izio

ne

(acc

eler

om

e-tr

o/

gir

osc

op

ioin

doss

ab

ile)

Diff

usi

on

ed

ib

etam

iloid

e(c

ervel

lo)

(bio

sen

sore

imp

ianta

bi-

le/

EE

G)

Ictu

sA

nd

atu

ra,

ton

om

usc

ola

re,

att

ivit

a,

dis

turb

id

ellin

gu

aggio

,m

emori

a(E

EG

ind

oss

ab

ile,

acc

eler

om

etro

,gir

osc

op

io)

Dia

bet

eR

idu

zion

ed

ella

vis

ta,

dis

turb

ise

nso

riali

(acc

eler

om

etro

/gir

osc

op

ioin

doss

ab

ile)

Glu

cosi

on

elsa

ngu

e,em

oglo

bin

agli

cata

(bio

sen

sore

imp

ianta

bi-

le)

Art

rite

reu

mato

ide

Rig

idit

aco

mu

ne,

funzi

on

iri

dott

e,fe

bb

re(a

ccel

erom

etro

,gir

osc

op

io,

term

isto

rein

doss

ab

ile)

Fatt

ore

reu

mato

ide,

mark

erin

fiam

mato

ri(s

enso

reim

pia

nta

bile)

Insu

ffici

enza

ren

ale

Uri

na

(sen

sore

dip

ress

ion

ee

divolu

me

del

laves

cica

imp

ianta

bile)

Ure

a,

crea

tin

ina,

pota

ssio

(bio

sen

sore

imp

ianta

bil

e)

Mala

ttia

vasc

ola

re(p

eri-

feri

cae

an

euri

smi)

Per

fusi

on

ep

erif

eric

a,

pre

ssio

ne

san

gu

ign

a,

pre

ssio

ne

del

lasa

cca

an

euri

smati

ca(s

enso

reim

pia

nta

bile

/in

doss

ab

ile)

Liv

ello

di

emoglo

bin

a(b

iose

nso

reim

pia

nta

bile)

Mala

ttie

infe

ttiv

eT

emp

eratu

raco

rpore

a(t

erm

isto

rein

doss

ab

ile)

Mark

erin

fiam

mato

ri,

nu

mer

oglo

bu

lib

ian

chi,

met

ab

oliti

pato

gen

i(b

iose

nso

reim

pia

nta

bile)

Mon

itora

ggio

post

-op

erazi

on

eF

requ

enza

card

iaca

,p

ress

ion

esa

ngu

ign

a,

EC

G,

satu

razi

on

eoss

igen

o,

feb

bre

(sen

sore

imp

ianta

bile

/in

doss

ab

ile

ese

nso

reE

CG

)

Em

oglo

bin

a,

glu

cosi

on

elsa

ngu

e,m

on

itora

ggio

nel

lap

art

ein

tere

ssata

dalla

op

erazi

on

e

27


1.3.5 Assistenza sanitaria personalizzata

In una popolazione formata da gruppi diversi di persone vulnerabili come persone

con malattie croniche e anziani, la necessita di monitoraggio e cure personalizzate

ha portato al concetto di assistenza sanitaria personalizzata, dove i sistemi sono

“dinamici” e customizzati alle necessita mediche dell’individuo. Essi dovranno tener

conto di malattie croniche (fattori a lungo termine) e sporadiche (fattori a breve

termine) del paziente, oltre a dover tener conto di fattori sociali. Le BSN, con i

concetti di monitoring “everywhere” e context-awareness, offrono forse l’opportunita

di sviluppare sistemi per l’assistenza sanitaria personalizzata a diversi livelli.

A livello di monitoraggio, il sistema dovrebbe osservare in maniera affidabile la

fisiologia, le attivita e il contesto del paziente e rilevare cambiamenti avversi nello

stato di salute della persona. A livello di cura, il post-processing dei dati unito ad

algoritmi di scelta della terapia dovranno scegliere l’azione corretta per ottenere la

migliore cura. Ad esempio la somministrazione di farmaci, le cui dosi sono definite

in accordo alla popolazione media, potrebbe essere adattate all’esigenza specifica

dell’individuo.

A livello di ricerca sistemi per la medicina personalizzata permetteranno ai medici

di imparare molto di piu a riguardo di malattie che essi comunemente osservano solo

in ambiente clinico.

Infine a un livello informativo, dando al paziente un’informazione personalizzata

sul suo stato di salute lo si aiuta a capire meglio le proprie condizioni e a gestire

quindi se stesso in maniera piu appropriata.

E chiaro, pero, che offrire un’assistenza sanitaria davvero personalizzata signi-

fica utilizzare sensori per BSN “invisibili” al paziente in modo da evitare vincoli

nell’esecuzione delle attivita quotidiane o modifiche nelle abitudini dell’individuo.

28


Figura 1.11. (Sinistra) Giocatore che utilizza il Wii Remote. (Destra) Playstation Move.

1.4 Oltre l’assistenza sanitaria

L’utilizzo delle BSN non si limita esclusivamente al campo dell’assistenza sani-

taria. Accanto alle applicazioni mediche una WBAN puo essere utilizzata in appli-

cazioni appartenenti a campi estremamenti eterogenei tra loro. Di seguito vengono

illustrate alcune delle aree che possono beneficiare degli sviluppi tecnologici delle

BSN, con uno sguardo ad alcuni dei progetti gia esistenti:

• Gaming Interattivo

Reti di sensori corporali permettono ai videogiocatori di riprodurre all’interno

del gioco i movimenti corporei realmente eseguiti. In questo modo un video-

giocatore puo ad esempio giocare a bowling, a tennis, sparare etc. migliorando

in maniera innovativa la propria esperienza di gioco. Negli ultimi anni diverse

sono state le piattaforme immesse nel mercato dei videogiochi. Nel 2009 il

famoso Wii Sports, prodotto dalla Nintendo, ha venduto oltre 50,54 milioni di

copie nel mondo. Alla sinistra in Figura 1.11 e mostrata l’utilizzo del “WiiMo-

te”13 che riproduce i movimenti dell’individuo nel gioco permettendo cosı la

simulazione di un combattimento. Alla destra invece e mostrata la soluzione

proposta dalla Sony per Playstation 3. Entrambi i controller utilizzano un

13Il controller del Nintendo Wii, console per videogiochi prodotta da Nintendo.

29


Figura 1.12. (Sinistra) Accelerometro, reso impermeabile, montato sugli occhialini delnuotatore. (Destra) Sistema di coordinate geocentriche (X, Y, Z), sistema di coordinateper l’accelerazione (x, y, z) e gli angoli di beccheggio e di rollio utilizzati nello studio.

accelerometro triassale MEMS al proprio interno e sono impiegate le nuove

tecniche di Activity Recognition.

• Sport Training

Come gia descritto in 1.3.1, ricerche recenti hanno promosso l’uso dell’accele-

rometro posizionato in differente aree del corpo per rilevare posture specifiche.

Con questa tecnologia, atleti che praticano gli sport piu svariati possono fa-

cilmente migliorare le loro performance ed evitare infortuni dovuti a posture

scorrette assunte durante i movimenti. In [13], una BAN e usata per determi-

nare l’orientamento della mazza da golf e degli arti del giocatore per fornire un

feedback real-time al giocatore, o al suo coach, in termini di movimento del-

l’anca e forza del tiro. In aggiunta i dati sul movimento del giocatore vengono

salvati per analizzare come distribuire al meglio le energie del giocatore lungo

l’intera gara. In questo modo durante l’allenamento e possibile perfezionare il

tiro, sulla base dei feedback ottenuti, fino a trovare il “tiro perfetto” e ottenere

risultati migliori in tempi piu brevi.

In [14] viene proposto un sistema di sensori non-intrusivo indossabile per il

monitoraggio delle performance nel nuoto. E utilizzato un singolo accelerome-

tro MEMS posizionato sugli occhialini (Figura 1.12), in modo che in esercizio

sia prossimo all’orecchio del nuotatore, per ottenere un’analisi su movimenti

significativi caratterizzanti la nuotata. Derivando gli angoli di beccheggio e di

rollio e possibile rilevare il tipo di nuotata e di virata. Anche numero di vasche

30


Figura 1.13. Nike + Ipod Sports Kit. (Sinistra) Inserimento dell’accelerometro nel-la scarpa. (Destra) Accelerometro sulla sinistra e ricevente da connettere all’Ipod sulladestra.

e “split-times” possono essere derivati.

Diverse sono anche le soluzioni commerciali gia proposte nel mercato dell’high-

tech. Il Nike + Ipod Sports Kit (Figura 1.13), che connette insieme le scarpe

Nike e il lettore MP3 di casa Apple, ne e un esempio. Il kit comprende una

piattaforma dotata di accelerometro piu trasmittente wireless progettata per

essere inserita nel modello di scarpe Nike adatto, una piccola ricevente da

collegare al dock-connector dell’iPod nano e un software ad hoc che forni-

sce le informazioni su tempo, chilometri percorsi e sul passo tenuto durante

l’allenamento, sia nel caso di camminata che di corsa.

• Social sharing

Il Nike + Ipod Sports Kit fornisce tra le tante cose anche la connessione a

servizi web. Connettendosi a Nikeplus.com e possibile essere in contatto con

runner da tutto il mondo e confrontare i propri tempi con quelli altrui in una

sorta di gara virtuale.

Questa soluzione introduce un altro degli utilizzi interessenti delle BSN: infor-

mazioni private provenienti da sensori corporali possono essere raccolte e poi

condivise in applicazioni di uso quotidiano, sui social network, siti dedicati

etc.

• Addestramento e operazioni militari

31


Un esempio di utilizzo delle BSN in campo militare e SPARNET - Spartan

Sensor Network to Improve Medical And Situational Awareness Of Foot Sol-

diers During Field Training. Nell’addestramento sul campo dei soldati, e in

situazioni reali, restrizioni sul cibo e condizioni ambientali estreme sono comu-

ni. Una rete di sensori wireless e necessaria per monitorare in ogni momento

la situazione corrente. Questo scopo e raggiunto da SPARNET attraverso l’u-

tilizzo di una BAN indossabile, integrata nella maglia di ogni soldato, formata

da sensori capaci di monitoraggio di dati fisiologici e da un localizzatore GPS.

Gli istruttori utilizzeranno la geo-localizzazione e i dati fisiologici, trasmessi

dalle BAN indossate da ogni singolo soldato, che insieme vanno a formare una

rete mesh, per: supervisionare gli allievi (“chi, dove, quando, stato corrente”),

assicurarsi che la giusta quantita di acqua sia stata ricevuta e consumata, ri-

durre le probabilita di danni al corpo dovuti a condizioni ambientali estreme,

come ad esempio temperature alte, e migliorare l’assistenza medica per i feriti.

L’utilizzo di sensori impiantabili in ogni soldato potra aiutare anche nella

scelta “dinamica” della strategia da adottare in battaglia. Il tempo e una

risorsa preziosa sul campo e piccoli errori possono risultare fatali. Usando

le BSN, il capo plotone puo controllare la posizione dei soldati rispetto a

qualsiasi pericolo nell’area circostante, oltre a poterne monitorare sempre lo

stato fisiologico.

• Tecniche di autenticazione

Attualmente tecniche di autenticazione sofisticate si basano su sistemi di ri-

conoscimento biometrici che utilizzano caratteristiche biologiche e/o compor-

tamentali quali il riconoscimento facciale, vocale, impronte digitali, riconosci-

mento dell’iride etc. Il problema potenziale di falsificazione e duplicabilita

ha, tuttavia, portato ad investigare sull’utilizzo di nuove caratteristiche fisico-

comportamentali del corpo umano, come ad esempio l’EEG14 unito all’impiego

14L’elettroencefalogramma (EEG) registra l’attivita elettrica cerebrale tramite elettrodi di su-

32


di sistemi di riconoscimento biometrici multi modali15.

• Sistemi Intelligenti basati su BAN

– Sistema intelligente di biosensori per “Vehicle-Area-Networks”

In aggiunta alle informazioni standard fornite dal computer di bordo di

un veicolo, possono essere raccolte informazioni riguardanti il guidato-

re come ad esempio l’espressione facciale (tempo di battito delle ciglia,

sbadigli, movimenti della testa, flessione del mento. . . ). Anche dati fisio-

logici come variabilita del battito cardiaco, EEG, possono essere utilizzati

per determinare il livello di attenzione del guidatore. Altri segnali fisio-

logici quali ECG (ottenuto da un sensore wireless posizionato sul polso),

EOG16, EMG, pressione sanguigna, sudorazione delle mani (quando il

guidatore tocca il volante) potrebbero essere usati per la dection della

fatica in modo da predire episodi di colpi di sonno. Si andrebbe a pro-

gettare, quindi, una rete di sensori all’interno del veicolo che raccoglie

informazioni sulla vettura e conducente e trasmette i dati a un’unita di

monitoraggio centrale che, processando i dati, fornisce feedback e segnali

di allarme al guidatore .

– Affective computing

Come accennato nella sezione 1.3.1 lo stato emozionale della persona di-

venta un’informazione importante da registrare. L’Affective computing e

un ramo specifico dell’intelligenza artificiale che si propone di realizzare

calcolatori in grado di riconoscere ed esprimere emozioni. Con i progressi

nelle BSN si sono aperte nuove prospettive nella “emotion detection”. Le

perficie posizionati sulla testa. Si ottiene un tracciato che segna per ciascun elettrodo le variazionidel voltaggio nel tempo.

15Per aumentare la sicurezza del sistema di riconoscimento si possono utilizzare piu tecnichebiometriche. Questi sistemi permettono un riconoscimento piu preciso e diminuiscono il tasso dierrore.

16L’elettrooculografia e un esame che utilizza degli elettrodi applicati intorno agli occhi cherilevano le differenze di potenziale provocate dagli spostamenti dei globi oculari.

33


emozioni, infatti, inducono tipicamente manifestazioni fisiche che possono

essere misurate attraverso biosensori (es. i sensori che forniscono l’EEG,

EMG, ECG. . . ) . Ad esempio la paura aumenta il battito cardiaco, causa

sudorazione delle mani e cosı via. La disponibilita di sensori indossabili e

integrabili in oggetti di vita quotidiana (scarpe, orologi, t-shirt. . . ) e bio-

sensori low-cost apre la strada al monitoraggio delle emozioni del singolo

individuo ovunque e in ogni istante.

Digital-Being e un esempio interessante di sistema che utilizza lo sta-

to emozionale. In questo caso le emozioni di chi balla in pista vengono

utilizzate per adattare automaticamente e dinamicamente la musica e le

luci in modo che l’ambiente rifletta lo stato emotivo di chi in quel mo-

mento e intento a ballare. Allo scopo vengono impiegati diversi sensori:

ogni ballerino indossa sensori fisiologici utilizzati per rilevare lo stato di

eccitazione e sensori di pressione sono installati su di un tappeto posto

sulla pista da ballo per tracciare posizione e movimenti di ognuno. Un

sistema centrale combina i dati ottenuti dai sensori di pressione e i sen-

sori wireless indossati dai ballerini e dai risultati ottenuti modifica luci e

musica in tempo reale. E utilizzata un’architettura a 3 livelli: il primo

livello sintetizza i dati ottenuti dalla rete di sensori, il secondo livello e

composto da un sistema intelligente che adatta luci e musica e il terzo

livello traduce le scelte fatte al livello 2 negli appositi segnali alla board

che gestisce le luci e al box di comando audio.

Questa panoramica mostra, dunque, le enormi potenzialita delle BAN.

Lo scopo principale di tutte queste applicazioni e ancora una volta migliorare la

Qualita di Vita dell’utente.

34

Capitolo 2

Tecnologie abilitanti per la

realizzazione di BSN

2.1 Hardware e dispositivi

Una BSN e formata da un numero variabile ed eterogeneo di dispositivi. In prima

approssimazione, e possibile distinguerli in 3 grandi classi:

1. Nodo Sensore: dispositivo che raccoglie dati su parametri vitali della perso-

na, li processa se necessario e trasmette l’informazione via wireless;

2. Nodo Attuatore: dispositivo che agisce in accordo ai dati ricevuti dai sensori

o dall’interazione con l’utente. I componenti di un attuatore sono simili a quelli

di un nodo sensore e spesso i due dispositivi possono coincidere. E composto

dall’ “actuating-hardware” (es. hardware per somministrazione dei farmaci,

inclusa la riserva che raccoglie il farmaco), l’alimentazione, il processore, la

memoria e un ricetrasmettitore;

3. Personal Device (PD): dipositivo che raccoglie i dati da tutti i sensori della

rete e puo trasmetterli a un engine di analisi o a un sistema di visualizzazione

dati. Alternativamente puo esso stesso provvedere al processing dei dati e

35


comandare gli attuatori o comunicare le informazioni con medici, paziente etc.

I compenenti sono la batteria, un processore piu potente rispetto ai nodi sensori

e attuatori, la memoria e il ricetrasmettitore. Questo dispositivo e anche

indicato con il nome di Body Control Unit (BCU) o generico di “aggregatore”.

In alcune implementazioni spesso il ruolo di BCU e svolto da smartphone,

PDA o anche PC locali.

Sensori e attuatori sono i componenti chiave delle BAN. Essi fanno da ponte

tra mondo fisico e i sistemi elettronici. Il loro contatto diretto con le persone e la

presenza di sensori impiantabili pone, pero, dei vincoli sulle dimensioni e sfide per

la biocompatibilita. Questo ha motivato la ricerca e la sintesi di nuovi materiali.

Negli ultimi anni l’interesse in biosensori e sensori chimici e stato notevole e

ha portato allo sviluppo di sensori all’avanguardia. Nelle due sezioni successive

verra innanzitutto data una classificazione dei sensori utilizzabili in BSN, verranno

introdotti alcuni dei tipici sensori corporali sul mercato, e verra data infine una

panoramica sui nodi sensore attualmente disponibili.

2.1.1 Sensori corporali

I sensori impiegati in una rete di sensori wireless riflettono i dati che l’applicazione

necessita di raccogliere. Le esigenze particolare di talune applicazioni in ambiente

medico richiedono l’utilizzo di sensori che vanno oltre quelli tipici utilizzati nelle

tradizionali reti di sensori wireless. Di seguito vengono riportati i tre principali tipi

di sensori con uno sguardo alla loro possibile applicazione nelle BSN:

1. Trasduttori fisici: monitorano fenomini fisici quali luce, movimento, tempe-

ratura. . . ). Ne sono un esempio sensori di pressione, accelerometri, sensori di

luce, sensori acustici. . . Sono sensori non specifici in ambito biomedico ma in

una BSN sono fondamentali per raccogliere informazioni sull’ambiente ester-

no. Sono la categoria utilizzata tipicamente all’interno di WSN tradizionali e

generalmente sono low-power e low-cost.

36


Figura 2.1. (Sinistra) Sensori inseriti in una maglia. (Destra) Grandezza degliaccelerometri MEMS paragonata alla punta di un fiammifero.

2. Sensori chimici: questo tipo di sensori consente di convertire grandezze chi-

miche in grandezze meglio trattabili, come sono quelle elettriche. Un senso-

re chimico e costituito generalmente da una membrana sensibile alle specie

chimiche che si vogliono rilevare e misurare, da una struttura di supporto e

dall’elettronica di controllo. Uno dei vantaggi significativi di questi dispositivi

e la miniaturizzazione, spinta ormai verso dimensioni nanometriche. Utilizzi

comuni sono l’analisi del sudore, saliva, concentrazione di gas nel respiro (che-

toni,aldeidi. . . ) che sono indicatori di alcune malattie quali diabete, ulcere

e cancro allo stomaco. Inoltre sono utilizzati estensivamente per la misu-

razione dell’inquinamento ambientale (aria, acqua. . . ). Nel prossimo futuro,

dunque, i sensori chimici, potranno essere utilizzati all’interno di BSN per rac-

cogliere informazioni eterogenee utili nell’assistenza medica e nel monitoraggio

dell’ambiente in cui il paziente vive.

3. Biosensori: particolari trasduttori costituito da un elemento sensibile biolo-

gicamente attivo (enzimi, cellule, anticorpi ecc.) e da una parte elettronica. Il

principio di funzionamento e molto semplice: l’elemento biologico interagisce

con il substrato da analizzare e un sistema di trasduzione (sensore) converte

la risposta biochimica in un segnale elettrico.

Qui di seguito sono riportati alcuni dei sensori commercialmente disponibili,

diversi dei quali sono gia stati introdotti al Capitolo 1:

37


• Accelerometri e Giroscopi : Accelerometri e giroscopi sono un ottimo esempio

per mostrare i notevoli progressi nella tecnologia MEMS. Alla destra di Fi-

gura 2.1 e mostrata la grandezza di alcuni accelerometri MEMS rispetto alla

punta di un fiammifero. Date le loro ridotte dimensioni sono ormai ampiamen-

te utilizzati nell’Activity Recognition e in applicazioni quali realta virtuale,

giochi elettronici etc.

Nella maggior parte degli accelerometri, il principio di funzionamento e il me-

desimo: si basa sulla rilevazione dell’inerzia di una massa quando viene sotto-

posta ad una accelerazione. La massa viene sospesa ad un elemento elastico,

mentre un qualche tipo di sensore ne rileva lo spostamento rispetto alla strut-

tura fissa del dispositivo. In presenza di un’accelerazione, la massa (che e

dotata di una propria inerzia) si sposta dalla propria posizione di riposo in

modo proporzionale all’accelerazione rilevata. Il sensore trasforma questo spo-

stamento in un segnale elettrico acquisibile dai moderni sistemi di misura. Lo

spostamento puo essere rilevato in diversi modi.

Un accelerometro capacitivo si basa principalmente sulla misura di variazioni

capacitive, indotte dalle accelerazioni cui il sensore e sottoposto. I processi di

microincisione permettono di realizzare condensatori costituiti da piu arma-

ture, che possono oscillare attorno ad una posizione di equilibrio, provocando

variazioni capacitive1. Tali variazioni sono dell’ordine di 10−18÷10−21 F e pos-

sono essere rilevate proprio grazie alla tecnologia costruttiva dei MEMS che

integra l’elettronica all’interno del sensore.

In un accelerometro a ponte piezoresistivo sono utilizzati sensori piezoresistivi2

sull’elemento estensibile rilevandone l’entita della deformazione.

1La capacita elettrica di un condensatore cambia al variare della distanza tra le sue armature2Il sensore piezoresistivo e un tipo di sensore utilizzato per rilevare delle grandezze meccaniche

e trasformarle in un segnale di tipo elettrico. Il sensore funziona sul principio fisico della piezo-resistenza: un particolare elemento resistivo segue le deformazioni della superficie di un elementosensore a cui e fissato; queste deformazioni (tipicamente allungamenti e accorciamenti) causano unavariazione della resistivita elettrica del materiale del resistore, e di conseguenza la sua resistenzaelettrica.

38


Figura 2.2. (Sinistra) Sensore di pressione del sangue indossabile come orologio. (Destra)Fascia elestica contenente sensori EEG

Un altro tipo di accelerometro, meno comune, sfrutta invece il principio della

convezione del calore. E tipicamente costituito da una cavita semisferica al

cui interno e presente un gas. Al centro di questa camera e presente una fonte

di calore e, egualmente distanziati, sono presenti quattro sensori di tempera-

tura (termocoppie). Quando l’accelerazione e nulla il gradiente di tempera-

tura e simmetrico rispetto alla fonte di calore e i quattro sensori misurano lo

stesso valore. Un’accelerazione in qualunque direzione altera il gradiente di

temperatura rendendolo asimmetrico: i sensori rilevano questa perturbazio-

ne e il segnale in uscita dall’accelerometro sara quindi proporzionale a questa

differenza.

Attraverso la combinazione di accelerometri MEMS sensibili a una sola di-

rezione nel piano e possibile ottenere accelerometri biassali (integrando due

dispositivi perpendicolarmente) e triassali.

Lo giroscopio, invece, utilizza il principio di conservazione del momento ango-

lare ed e impiegato per misurare o mantenere stabile l’orientamento.

• Glucometro: Biosensore che fornisce una misura della quantita di glucosio nel

sangue analizzando una goccia di sangue ottenuta con una piccola puntura

su un dito. Recentemente sono stati introdotti sistemi di monitoraggio del

glucosio non invasivi che utilizzano tecnologie a infrarossi e misure ottiche.

39


• Sensore di pressione sanguigna: Sensore non invasivo che permette di ottenere

misure della pressione sanguigna sistolica e diastolica, utilizzando tecniche

oscillometriche. In Figura 2.2 alla destra e mostrato una soluzione commerciale

che integra all’interno un sensore di questo tipo e, indossabile e utilizzabile

anche come orologio, permette di tenere sempre sotto controllo la pressione

sanguigna.

• Sensore di CO2: Misura il livello di anidride carbonica come anche la concen-

trazione di ossigeno durante la respirazione (Figura 2.3 in alto a destra).

• Sensore ECG : Registra l’attivita elettrica del cuore. Per ottenere l’ECG di-

versi elettrodi sono attaccati in posizioni specifiche ed e misurata la differenza

di potenziale tra gli elettrodi. Al centro di Figura 2.3 e mostrata una soluzione

che include un sensore ECG all’interno di un circuito che risulta pieghevole

gazie all’assemblaggio su un substrato di poliammide; degli elettrodi standard

sono utilizzati per essere attaccati al corpo. Questa flessibilita nel materia-

le permette l’inserimento del circuito all’interno di capi d’abbigliamento in

maniera semplice potendo cosı ottenere un sistema non intrusivo capace di

monitorare l’attivita cardiaca quotidiana.

• Sensore EEG : Misura l’attivita elettrica cerebrale attaccando piccoli elettrodi

al cuoio capelluto. I segnali dagli elettrodi vengono poi amplificati per ottenere

infine il tracciamento del segnale. In Figura 2.2 alla destra e mostrata una

persona che indossa una fascia al cui interno sono posti dei sensori EEG. Si

noti ancora una volta l’integrazione dei sensori all’interno di oggetti indossabili.

• Sensore EMG : Misura i segnali elettrici prodotti dai muscoli quando si con-

traggono o si rilassano. Spesso vengono eseguiti insieme studi sulla conduzione

nervosa mentre e monitorata l’attivita dei muscoli poiche i nervi controllano i

muscoli del corpo attraverso impulsi elettrici, che comandano la muscolatura

a reagire in un modo specifico. Problemi nelle terminazioni nervose e nei mu-

40


Figura 2.3. (Sinistra) Sensori EMG. (Centro) Sensore ECG pieghevole (Fonte: IMEC).(Destra-In Alto) Sensore CO2 le cui dimensioni sono paragonabili a un centesimo di euro.(Destra-In basso) Pulsossimetro.

scoli causano reazioni anormali nei movimenti che, dunque, con questa analisi

possono essere studiati. In Figura 2.3 alla sinistra sono mostrati sensori EMG

attaccati a un braccio.

• Pulsossimetro: E uno strumento in grado di rilevare la saturazione in ossige-

no dell’emoglobina. In altre parole misura se nel sangue circola una quantita

sufficiente di ossigeno. E pertanto molto utile per valutare l’efficacia della

respirazione artificiale, dell’ossigenoterapia e delle ventilazioni manuali; rileva

inoltre la frequenza cardiaca. Consiste in una piccola clip (Figura 2.3 - A

destra in basso) con un sensore fissabile a un dito, al lobo dell’orecchio, al

dito del piede. Il sensore emana una luce che attraversa la pelle. In accordo

all’assorbimento di luce dell’emoglobina ossigenata rispetto al totale di emoglo-

bina nel sangue arterioso, la misura e espressa come rapporto tra l’emoglobina

ossigenata e la quantita totale di emoglobina.

• Sensori di temperatura e di umidita: Sono utilizzati per misurazioni del-

la temperatura del corpo umano e/o umidita dell’ambiente che circonda la

persona.

41


Tabella 2.1. Sensori comunemente impiegati in BSN e relativi tassi di trasmissione tipici

Sensori Topologia Data Rate

Accelerometro/Giroscopio Stella Alto

Glucometro Stella Alto

Pressione sanguigna Stella Basso

Sensore CO2 Stella Molto basso

Sensore ECG Stella Alto

Sensore EEG Stella Alto

Sensore EMG Stella Molto Alto

Pulsossimetro Stella Basso

Sensore di umidita Stella Molto Basso

Sensore di temperatura Stella Molto Basso

Immagini/Video P2P Molto Alto

In Tabella 2.1 sono mostrati i sensori comunemente utilizzati in BAN, la topo-

logia tipicamente impiegata e i tassi di trasmissione in gioco.

I progressi nella tecnologia MEMS, nella miniaturizzazione delle sorgenti di ener-

gia e nell’utilizzo di tecniche di energy scavenging, nello sviluppo di biosensori e

sensori chimici, quindi, sta portando a una nuova classe di sensori indossabili e im-

piantabili che rappresentano un potenziale futuro enorme nel monitoraggio pervasivo

del corpo umano. In particolare, mentre i sensori indossabili, come quelli utilizzati

per la misura di caratteristiche vitali, continuano a raggiungere caratteristiche sem-

pre piu spinte, l’area dei sensori impiantabili e dei biosensori e ancora in una fase

embrionale e aperta a nuove sfide. Come illustrato nel Capitolo 1 le potenzialita

applicative di simili dispositivi sono enormi.

2.1.2 Piattaforme

In Figura 2.4 e mostrato un tipico nodo sensore, spesso chiamato anche Mo-

te, con il modulo del sensore vero e proprio e i moduli relativi a radio, memoria e

microprocessore. Il modulo sensore consiste di un sensore, un filtro e convertito-

re analogico-digitale. Il sensore converte il segnale elettrico analogico acquisito, il

quale e prima filtrato da un filtro passa-banda e poi digitalizzato da un ADC. In

42


Figura 2.4. Architettura di un nodo sensore.

seguito verranno discusse le tecnologie wireless attualmente utilizzate in BAN per

la trasmissione del dato acquisito.

La Tabella 2.2 mostra alcune delle piattaforme esistenti sul mercato focalizzan-

dosi sul sitema operativo e la tecnologia wireless utilizzati, il data-rate e la copertura

outdoor massimi raggiungibili e il consumo energetico.

Tutti i nodi elencati raggiungono l’obiettivo di un consumo energetico basso ma

la velocita di trasmissione varia da 38,4 a 720 kbps, insufficiente per BSN su larga

scala e traffico multimediale, come ad esempio il video streaming.

Si puo gia notare, inoltre, l’attuale notevole diffusione della combinazione tra

TinyOS come sistema operativo e l’IEEE 802.15.4 per l’interfaccia radio, mentre solo

alcune soluzioni utilizzano il Bluetooth. Nelle sezioni successive verranno discussi e

confrontati gli standard wireless attualmente utilizzati e data una panoramica sui

sistemi operativi, e in particolare TinyOS.

2.2 Architetture per BSN

Nella scelta della soluzione architetturale da adottare nella progettazione di una

BSN diversi nuovi fattori devono essere tenuti in considerazione, non solo tecnologici

ma anche dettati da norme e leggi regolatrici. In aggiunta non dovrebbe mai essere

dimenticato il seguente principio:

43


Tabella 2.2. Confronto tra nodi sensore utilizzati in BSN.

Nome SistemaOperativo

StandardWireless

Data Rate(kbps)

CoperturaOutdoor(m)

ConsumoEnergetico

BAN node TinyOS IEEE802.15.4

250 50 Basso

BTNode TinyOS Bluetooth – – Basso

eyesIFX TinyOS TDA5250 64 – Basso

iMote TinyOS Bluetooth 720 30 Basso

iMote2 TinyOS.NET

IEEE802.15.4

250 30 Basso

IRIS TinyOS IEEE802.15.4

250 300 Basso

Micaz TinyOS IEEE802.15.4

250 75-100 Basso

Mica2 TinyOS IEEE802.15.4

38,4 >100 Basso

Mulle TCP/IPTinyOS

BluetoothIEEE802.15.4

– >10 Basso

TelOS TinyOS IEEE802.15.4

250 75-100 Basso

ZigBit ZDK IEEE802.15.4

250 3,700 Basso

“Non e un problema ne medico ne tecnologico. Al centro c’e il paziente, non la

tecnologia”.

I seguenti punti rappresentano una possibile metodologia per lo sviluppo di un

sistema basato su BSN per applicazioni mediche:

1. Capire il problema: I requisiti individuati dal personale medico sono tipica-

mente il punto di partenza per gli ingegneri. Il documento dei requisiti clinici

dovrebbe poter rispondere alle seguenti domande:

• Quali sono i dati da raccogliere?

• Quali informazioni, conseguenti all’aggregazione dei dati raccolti e all’a-

nalisi, dovrebbero essere generate dalla rete?

• Quale grado di modificabilita e richiesto dal personale medico?

44


• Come il sistema dovrebbe interagire con il paziente (soggetto), in termini

di “user–interface” e meccanismi di feedback?

2. Capire l’utente finale: La soluzione deve rispettare i requisiti clinici ma deve

essere altrettanto appropriata e accettata dall’utente finale. Le domande da

porsi sono: chi utilizzera il sistema nel lungo termine? Quali sono i suoi vincoli

e priorita?

Diventano fondamentali, dunque, osservazioni etnografiche della “user–dimension”.

3. Capire l’ambiente: Il sistema deve lavorare nell’ambiente per cui e stato pro-

gettato (ambiente domestico, uffico, ospedale), non solo in laboratorio. Le

domande a cui rispondere sono: l’attivita monitorata e ristretta a un solo

ambiente? L’ambiente e indoor, outdoor o entrambi? Sono presenti altre

fonti di onde radio? Le caratteristiche dell’ambiente possono interferire sulla

comunicazione wireless?

4. Selezionare i sensori/attuatori e sceglierne la posizione.

5. Scegliere l’ “aggregatore”.

In Figura 2.5 e mostrata un’architettura a 3 livelli generica di un sistema basato

su BSN per applicazioni nell’assistenza sanitaria. Diversi tipi di sensori inviano

dati al vicino personal–device. Poi, attraverso una connessione Bluetooth/WLAN,

questi dati vengono trasmessi in remoto al personale medico per una diagnosi in

tempo reale oppure a un databese medico o ancora a chi gestisce le emergenze.

Non esiste in letteratura una suddivisione condivisa dell’architettura del siste-

ma di comunicazione in componenti. Per meglio affrontare il problema, in riferi-

mento alla Figura 2.5, distingueremo in comunicazione intra-BAN, comunicazione

inter-BAN e comunicazione beyond-BAN. Un’altra suddivisione spesso utilizzata in

letteratura distingue tra comunicazione intra-body e comunicazione extra-body. La

prima individua la comunicazione tra sensori/attuatori e il PD, la seconda quella tra

45


Figura 2.5. Un’architettura three-tier per un sistema di comunicazione basato su BSNper applicazioni nell’assistenza sanitaria.

PD e la rete esterna. In Figura 2.5 e mostrata la corrispondenza tra quest’ultima

suddivisione e la precedente.

La scelta della topologia di rete e dell’architettura e fortemente legata all’appli-

cazione e i suoi requisiti; alcune applicazioni, ad esempio, potrebbero non prevedere

affatto la comunicazione beyond-BAN o inter-BAN. Customizzando ognuno dei livel-

li individuati, possono essere raggiunti specifici obiettivi (costi, copertura, efficienza,

QoS. . . ).

In particolare nella progettazione i seguenti parametri dovrebbero sempre essere

considerati:

• Costi;

• Scalabilita: la flessibilita di poter utilizzare tanti nodi quanti necessari e un

requisito in diverse applicazioni;

• Fault–tolerance;

• Routing: il routing impatta non solo su affidabilita, fault–tolerance, e sca-

labilita ma anche sul consumo energetico. L’approccio migliore e quello di

46


Figura 2.6. Architettura della comunicazione intra–BAN: (a) wired; (b) direttamenteconnesso all’AP; (c) wireless; (d) ibrida; (e) cluster & wireless

mantenere al minimo il routing e trasmettere solo quando assolutamente ne-

cessario;

• Efficienza nel consumo energetico;

• Norme e vincoli in ambito medico: i requisiti del sistema devono tener conto

della legislazione medica locale;

• Privacy e Sicurezza.

2.2.1 Comunicazioni Intra–BAN

Con questo termine si vuole indicare le comunicazioni wireless che avvengono a

una distanza massima di 2 metri dal corpo umano. In particolare distinguiamo in:

• comunicazione tra nodi sensore;

• comunicazione tra nodi sensore e personal–device.

Vista la relazione diretta tra nodi sensori e il concetto nuovo di BAN, il progetto

della intra–BAN diventa critico. Tuttavia, dato l’utilizzo di batterie e non dell’a-

47


limentazione dalla rete elettrica, di bit-rate bassi per le interfacce radio, resta una

sfida progettare protocolli MAC energy–efficient con servizi di QoS. Per superare

le sfide di una comunicazione wireless alcune soluzioni utilizzano delle connessioni

wired utilizzando cavi che collegano direttamente sensori e PD come mostrato in

Figura 2.6a.

Alternativamente altre soluzioni prevedono la comunicazione diretta con l’AP

senza l’utilizzo di un personal–device, come mostrato in Figura 2.6b. Confrontata

con i due approcci precedenti, Figura 2.6c rappresenta l’architettura tipica nell’uti-

lizzo di una topologia a stella, dove piu sensori trasmettono a un PD e quest’ultimo

periodicamente invia i dati processati, se previsto, a un AP.

Le Figure 2.6d–e presentano una intra–BAN a due livelli. Nel primo livello, i

sensori sono connessi in maniera wired o wireless a un processore centrale che, dopo

la fusione dei dati, trasmette al personal device. In questo modo si riduce la quantita

di dati grezzi da trasmettere e si allunga la durata della batteria. Tuttavia, queste

soluzioni richiedono tecniche avanzate di processing di dati biomedicali che siano

computazionalmente eseguibili su un nodo con limitate risorse.

Un’applicazione BSN puo anche prevedere solo la presenza della rete intra-BAN.

E il caso di rete di sensori corporali stand–alone: nello scenario piu semplice un

nodo centrale raccoglie e memorizza per un periodo di tempo le letture di biosensori

quali ECG, EMG, EEG. . . che poi verrano utilizzati per interpretazioni e analisi

off-line. Utilizzando un personal-device che offre capacita di local-processing dei

dati e un’interfaccia per l’input e output, il paziente e sempre tenuto al corrente

del proprio stato e allertato se il suo stato di salute peggiora. In questo scena-

rio reti con topologia a stella (Figura 2.6a-c) o reti mesh (Figura 2.8–destra) sono

entrambi applicabili nella comunicazione intra-BAN. Una topologia a stella implica

un’architettura centralizzata dove il “core” del sistema e un nodo centrale (svolto ad

esempio da un PDA) con risorse (processore, memoria, alimentazione) superiori ai

sensori periferici. L’altra soluzione e un sistema distribuito con una rete P2P senza

48


coordinatore centrale. Spostando l’intelligenza del sistema verso i nodi sensore, la

BSN sara formata da sensori intelligenti che communicano l’uno con l’altro. Essendo

la rete indipendente da qualsiasi nodo centrale anche se un nodo si guasta le altre

parti del sistema continuano ad operare, ovvero la rete e failure–tolerant. Questo

approccio e da preferire quando i sensori devono comunicare tra loro.

2.2.2 Comunicazioni Inter–BAN

Il Capitolo 1 ha illustrato come l’introduzione delle BSN possa cambiare la Qua-

lita di Vita del paziente/utente migliorando la mobilita, permettendo di avere una

vita normale, riducendo i tempi per fornire assistenza medica, offrendo possibilita di

assistenza anche a pazienti che vivono in aree rurali. Tutto cio evidentemente non

e possibile con una rete stand–alone; la BSN deve poter comunicare con il “mondo

esterno”. Da qui la necessita di comunicazioni inter–BAN prima e beyond–BAN

poi.

Indichiamo con comunicazioni inter–BAN quelle comunicazioni che avvengono

tra il PD e uno o piu AP. Infatti, a differenza delle WSN che normalmente operano

come sistemi autonomi, una BSN raramente lavora sola. Le funzionalita del secondo

livello, come mostrato in Figura 2.5, sono quelle di interconnettere le BAN con le

reti che normalmente vengono accedute nella vita quotidiana, ad esempio Internet e

la rete cellulare. Confrontate con le comunicazioni intra–BAN, le tecnologie wireless

per comunicazioni inter–BAN sono mature e includono WLAN, Bluetooth, ZigBee,

3G. . .

Distinguiamo in particolare il paradigma di comunicazione inter–BAN in due

categorie: modalita infrastruttura (Figura 2.7a) e modalita ad-hoc (Figura 2.7b).

Mentre la prima fornisce banda maggiore con controllo centralizzato e flessibilita,

la seconda facilita lo sviluppo veloce in ambienti dinamici, quali ad esempio campi

base allestiti in situazioni di emergenza.

49


Figura 2.7. Architettura della comunicazione inter–BAN: (Sinistra) Modalitainfrastruttura; (Destra) Modalita ad–hoc.

Modalita infrastruttura

Diverse “applicazioni BSN” usano una modalita infrastruttura quando l’ambiente

in cui lavorano e limitato, ad esempio sale di attesa in ospedale, casa, ufficio, etc.

Confrontata con la soluzione ad–hoc, una rete in modalita infrastruttura offre i

vantaggi di sicurezza e gestione centralizzata. Inoltre, data la struttura centralizzata,

l’access–point lavora anche da server del database in alcune applicazioni.

Modalita ad hoc

In una architettura ad–hoc piu AP sono impiegati per aiutare la rete di senso-

ri corporali a trasmettere informazioni all’interno del centro medico. Il servizio di

copertura, quindi, e intrinsecamente superiore rispetto alla soluzione ad infrastrut-

tura, facilitando l’utente a muoversi all’interno dell’edificio oppure in un punto di

raccolta in missioni di emergenza. In questo modo, mentre la copertura di una BSN

e limitata a circa due metri, la inter–BAN estende il sistema a centinaia di metri;

soluzione che si addice sia a installazione di breve termine sia a installazioni di lungo

termine (es. a casa).

In questa architettura esistono due categorie di nodi: sensori/attuatori all’ “interno”

e “intorno” al corpo umano e nodi router intorno alla BSN. Questa soluzione e in

50


certi aspetti simile a quelle tipicamente adottate per WSN, ed entrambe spesso

impiegano un gateway per l’interfacciamento con il mondo esterno. In una WSN,

tuttavia, ogni nodo e sia sensore che router.

I vari access–point del sistema formano una struttura mesh con le seguenti

caratteristiche:

1. Copertura wireless piu ampia grazie alle topologie multi–hop, che favorisce

migliore supporto alla mobilita;

2. Possibilita di realizzare velocemente e in maniera flessibile una rete wireless

per installazioni di emergenza;

3. La rete puo essere facilmente estesa senza ripercussioni sull’intera rete. La

scalabilita e garantita potendo aggiungere AP quando necessario.

Nella comunicazione inter-BAN rientra l’importante possibilita di poter connet-

tere le BSN a WSN ambientali. Il concetto di monitoraggio pervasivo del paziente

rappresenta certamente l’innovazione piu forte che le BSN hanno reso possibile. Co-

me visto al Capitolo 1 esso non puo prescindere da quello di context-awareness.

Il futuro, dunque, e rappresentato da reti di sensori pervasive che combinano il

“sensing” del corpo a quello dell’ambiente, o in generale del “contesto”. I sensori

ambientali sono tipicamente parte di una WSN statica. Al contrario, una BSN e so-

lidale con gli spostamenti dell’utente. Nel seguito faremo riferimento ai nodi di una

e dell’altra rispettivamente come sensori mobili e sensori ambientali. Per connetter-

si alla WSN , un sensore mobile deve scoprire un sensore ambientale nei dintorni e

fare un “join” con la rete attraverso il sensore appena scoperto. Quando il sensore

mobile si muove, diventa necessario ripetere regolarmente le procedure di discovery

e associazione per restare connessi alla WSN. Applicare questo approccio a tutti

i sensori mobili di una BSN e chiaramente piuttosto inefficiente. Una soluzione e

selezionare uno dei sensori della BSN a lavorare come bridge tra WSN ambientale

51


Figura 2.8. BSN mobile connessa a una WSN ambientale.

e BSN. In questo modo il nodo che funge da bridge sara l’unico a dover avviare le

procedure di associazione e riassociazione quando la BSN e in movimento.

La Figura 2.8 illustra questo approccio sia nel caso di BSN con topologia a stella

(alla sinistra) sia nel caso di BSN con topologia mesh (alla destra). In una rete a

stella il coordinatore funge anche da bridge con la WSN. Il risultato e una rete di

sensori pervasiva con topopogia ibrida star-mesh. In una BSN mesh, invece, uno dei

nodi sensori e selezionato a prendere il ruolo di bridge con la WSN.

2.2.3 Comunicazioni Beyond–BAN

Le comunicazioni beyond–BAN sono intese per l’uso in aree metropolitane. Nel-

l’obiettivo di ottenere un bridge tra le reti inter–BAN e beyond–BAN puo essere

impiegato un gateway, ad esempio un PDA, che crea cosı un link wireless tra i due

network. Come mostrato in Figura 2.5 questo terzo livello puo aumentare i servizi

offerti dall’applicazione creando un sistema di “E–healthcare”, aumentando la co-

pertura e abilitando il personale medico ad accedere in remoto a informazioni sul

paziente utilizzando la rete cellulare o Internet. Un database che mantiene i pro-

fili utente e relativi dati medici storici e un ulteriore componente fondamentale di

52


questo livello. In questo modo il medico puo sempre accedere alle informazioni di

cui ha bisogno e allo stesso tempo possono essere implementati sistemi di notifica

automatici per i familiari che si basano sui dati raccolti.

Il design della comunicazione beyond–BAN e “application–specific” e dovrebbe

sempre adattarsi ai requisiti specifici dell’utente. Se la BSN ha una topologia a

stella, il gateway e tipicamente destinato a essere anche il gateway. In aggiunta,

per ottenere un bridge tra diverse tecnologie, il gateway dovrebbe tradurre i proto-

colli leggeri usati in BSN in standard per la sanita (HL7, DICOM. . . ) in modo da

permettere l’utilizzo dei dati raccolti dai sistemi clinici esistenti.

Un esempio di sistema che realizza quanto descritto e il progetto Healthservice24

[21] dove il cellulare, utilizzato come stazione base mobile per la rete di sensori in-

dossata sul corpo, trasmette le misurazioni via wireless, utilizzando UMTS o GPRS,

a un centro specializzato che agisce come intermediario tra il paziente e il fornitore

dell’assistenza sanitaria. Tre sono i servizi offerti:

1. Data repository: raccolta e memorizzazione dei dati ricevuti;

2. Servizio di streaming: forwarding dei dati al personale medico

3. Servizio di feedback: invio di un allarme o di promemoria alle destinazioni

impostate utilizzando SMS.

2.3 Tecnologie Wireless

In confronto alle esistenti tecnologie, le BSN introducono comunicazioni wireless

all’ “interno” e “intorno” al corpo umano. In Figura 2.9 una WBAN e comparata

con altri tipi di reti wireless, quali reti “personali’ (WPAN), reti locali (WLAN), reti

metropolitane (WMAN) e reti geografiche (WAN). Una WBAN opera, quindi, vicina

al corpo e la sua area di comunicazione si estende su valori tipici di 1–2 metri. Mentre

una WBAN e dedicata all’interconnessione dei nodi sensore impiantati o indossati

53


Figura 2.9. Posizionamento di una Wireless Body Area Network nel mondo delle retiwireless.

dalla persona, una WPAN e una rete nell’ambiente che circonda la persona. Il

campo di comunicazione puo raggiungere la decina di metri, nel caso di applicazioni

high-rate, fino a diverse dozzine di metri per applicazioni low-rate. Una WLAN,

invece, si estende anche oltre i 100 metri. Ogni tipo di rete wireless ha la sua

tipica tecnologia abilitante, definita dall’IEEE. Una WPAN usa l’IEEE 802.15.1

(Bluetooth) o IEEE 802.15.4 (ZigBee), una WLAN usa l’IEEE 802.11 (WiFi) e una

WMAN l’IEEE 802.16 (WiMax). La comunicazione in una WAN puo essere stabilita

con un collegamento via satellite.

In diversi paper scientifici una WBAN e considerata come una particolare WSN o

“Wireless Sensor and Actuator Network” (WSAN) con requisiti specifici. Come gia

visto alla sezione 1.2, tuttavia, le reti di sensori tradizionali non affrontano i requisiti

specifici di una BSN. Una panoramica schematica dei requisiti di una WBAN e il

confronto con le WSN e le WLAN e mostrata in Figura 2.10.

I nuovi requisiti che caratterizzano le BSN hanno spinto l’IEEE 802.15 a creare

nel 2007 un Task Group 6 per sviluppare standard specifici per le emergenti BSN.

Lo scopo e quello di definire uno standard di comunicazione con un protocollo per il

livello fisico e il sotto-livello MAC per applicazioni mediche e non in un range di 3 m.

In accordo ai differenti requisiti delle diverse applicazioni, i data-rate devono coprire

un intervallo che va da decine di kbps a decine di Mbps, il protocollo deve avere

54


Figura 2.10. Caratteristiche di una WBAN confrontate con WSN e WLAN.

bassa complessita ma deve essere robusto a interferenze e permettere associazione e

deassociazione alla rete rapidamente.

In questa sezione verra fornito uno studio delle emergenti e esistenti tecnologie

per BSN e WPAN, che includono Bluetooth, Bluetooth Low Energy, ZigBee e IEEE

802.15.4, UWB e IEEE 802.15.6, evidenziando il contributo di ognuna alle reti di

sensori corporali.

2.3.1 Bluetooth

Bluetooth e una specifica industriale per reti personali senza fili sviluppata da

Ericsson e in seguito formalizzata dalla Bluetooth Special Interest Group (SIG).

Fornisce un metodo standard, economico e sicuro per scambiare informazioni tra

dispositivi diversi attraverso una frequenza radio sicura a corto raggio di azione

(da 1 a 100 metri). Lo standard doveva consentire il collegamento wireless tra

periferiche come stampanti, tastiere, telefoni, microfoni, etc. a computer o PDA o tra

PDA e PDA. Attualmente piu di un miliardo di dispositivi montano un’interfaccia

Bluetooth.

I dispositivi dotati di Bluetooth si dividono in 3 classi. In Tabella 2.3 sono

mostrate le caratteristiche di ogni classe, in particolare potenza massima consentita

55


Tabella 2.3. Classi e rispettive caratteristiche dei dipositivi Bluetooth.

Classe Potenza (mW) Potenza (dBm) Copertura (m)

Classe 1 100 20 100

Classe 2 2,5 4 10

Classe 3 1 0 1

e copertura massima raggiunta.

Il protocollo Bluetooth lavora nelle banda ISM delle frequenze libere a 2,4 GHz

utilizzando lo schema Frequence-Hopping/Time-Division-Duplex. La tecnica di ti-

po spread spectrum Frequence Hopping consiste nel saltare da una frequenza ad

un’altra secondo un pattern casuale: la banda tra 2402–2480 MHz e divisa in 79

canali (ampi ognuno 1 Mhz) e si commuta tra i diversi canali secondo una sequenza

pseudo-casuale. A partire dalla versione Bluetooth 1.2 e stata aggiunta la tecnica

Adaptative Frequence Hopping (AFH) che fornisce maggior resistenza alle interfe-

renze elettromagnetiche, provvedendo a evitare di utilizzare i canali soggetti a forti

interferenze.

Il Bluetooth e un protocollo packet-based con una struttura master-slave. Ogni

dispositivo e in grado di gestire simultaneamente la comunicazione con altri 7 dispo-

sitivi sebbene essendo un collegamento di tipo master-slave solo un dispositivo per

volta puo comunicare con il server. Questa rete minimale viene chiamata piconet. Le

specifiche Bluetooth prevedono 3 tipi di topologie: punto-punto, punto-multipunto

e scatternet. E possibile, infatti, collegare due piconet in modo da espandere la

rete. Tale rete viene chiamata scatternet. In particolare un dispositivo potra essere

master in una piconet e slave nell’altra in modo da assumere il ruolo di bridge.

La tecnologia Bluetooth prevede di sincronizzare la maggior parte delle opera-

zioni con un clock in tempo reale. Esso serve, ad esempio, a sincronizzare gli scambi

di dati tra i dispositivi, distinguere tra pacchetti ritrasmessi o persi, generare una

sequenza pseudo-casuale predicibile e riproducibile. In una piconet tutti i dispositivi

condividono il clock del master. Il clock Bluetooth e realizzato con un contatore a

56


28 bit che viene posto a 0 all’accensione del dispositivo e subito dopo si incrementa

senza fermarsi mai ogni 312,5µs. Due colpi di clock formano uno slot, che dunque

e pari a 625µs. Il ciclo del contatore copre approssimativamente la durata di un

giorno (312,5µs ×228 ≈ 23,3 ore). I dipositivi in una stessa piconet condividono

lo stesso clock. I frequence-hop avvengono ogni slot, ovvero ogni 625µs, offrendo

una frequenza nominale di 1600 hops/s. Il canale e anche time-slotted con la stes-

sa periodicita e gli slot sono utilizzati sia per trasmettere che per ricevere (schema

TDD). Questa divisione nel tempo permette il multiplexing di differenti dipositivi

quando essi condividono lo stesso canale Bluetooth. Nel caso piu semplice di pac-

chetti single-slot il master trasmette negli slot pari e riceve in quelli dispari; lo slave

al contrario trasmette negli slot dispari e riceve in quelle pari. I pacchetti possono

essere lunghi 1, 3, 5 slot ma in tutti i casi il master comincera a trasmettere solo

negli slot pari e lo slave in quelli dispari. Di fatto lo schema TDD fornisce una

comunicazione full-duplex.

I dispositivi in una piconet in accordo possono cambiare ruolo: uno slave puo

diventare master in ogni momento.

In ogni dato momento, i dati possono essere trasferiti tra il master e uno o

piu slave nella piconet (e permessa anche la trasmissione multicast/broadcast). Il

master sceglie a quale slave trasmettere; tipicamente shifta da uno slave all’altro con

un algoritmo round-robin.

Gli slave possono appartenere a piu piconet contemporaneamente, mentre il ma-

ster di una piconet puo al massimo essere lo slave di un’altra. Il limite di tutto cio

sta nel fatto che all’aumentare del numero di piconet aumentano anche il numero di

collisioni dei pacchetti e di conseguenza degradano le prestazioni del collegamento.

Ogni piconet lavora indipendentemente dalle altre sia a livello di clock che a livello di

salti di frequenza. Questo perche ogni piconet ha un proprio master. Un dispositivo

bluetooth puo partecipare sequenzialmente a diverse piconet come slave attraverso

l’uso delle tecniche TDD, ma puo essere master solo in una.

57


I dispositivi Bluetooth possono essere nei tre seguenti stati principali:

• attivo, gli slave partecipano attivamente alla piconet sia in ricezione che in

trasmissione, e sono sincronizzati col master. Possono essere massimo 7;

• standby, lo slave non e connesso e quindi non e coinvolto nelle attivita della

piconet. Si dice anche che e in modalita risparmio energetico, e possono essere

un numero indefinito;

• parked, lo slave non e attivo e non sta comunicando. “Sonnecchia” consumando

poco e, rimanendo sincronizzato alla piconet, ascolta su 32 canali invece dei

79. In questo modo si riesce ad avere piu di 7 dispositivi agganciati al master,

anche se il numero di quelli che possono trasmettere rimane invariato.

Vi sono anche sette stati minori chiamati rispettivamente: page, page scan, inquiry,

inquiry, scan, master response, slave response e inquiry response. Quando il de-

vice non conosce alcuna informazione sul bluetooth remoto esegue rispettivamente

lo stato di inquiry, che permette di fare uno scan e localizzare dispositivi raggiun-

gibili dell’area circostante ottenendo informazioni quali indirizzo bluetooth e clock

del dispositivo remoto. Subito dopo entra in funzione lo stato di inquiry response

per ritrasmettere al dispositivo scoperto informazioni utili sul proprio conto quali

BD ADDR etc. Normalmente dopo lo stato di inquiry una volta ottenuto l’indirizzo

del dispositivo remoto segue lo stato di paging il quale permette di effettuare a tutti

gli effetti un tentativo per stabilire una connessione attiva: l’unita che stabilisce la

connessione diviene cosı automaticamente il master.

E inoltre previsto l’uso di “profili Bluetooth” che sono le definizioni di possibili

applicazioni e specificano i comportamenti generali che il dispositivo Bluetooth usa

per comunicare con altri dispositivi Bluetooth.

La versione 1.1 e 1.2 del Bluetooth gestisce velocita di trasferimento fino a 723,1

kb/s. La versione 2.0 con l’introduzione dell’Exchange Data Rate (EDR) gestisce

una modalita ad alta velocita che consente fino a 3 Mb/s (nella pratica si raggiungono

58


Tabella 2.4. Confronto tra diverse tecnologie wireless.

Tecnologia Data Rate Corrente di Idle Tempo di Startup

802.15.4 250 Kbps 7 mA Basso

Bluetooth 3 Mbps 22 mA Medio

802.11 11 Mbps 160 mA Alto

UWB >100 Mbps 2 mA Basso

velocita di 2,1 Mb/s). La versione 3.0 con l’aggiunta dell’High Speed (HS) permette

di raggiungere anche velocita di 24 Mb/s utilizzando un link 802.11 colocato per il

trasferimento di dati a rate elevato.

Da un punto di vista delle BSN, tuttavia, il Bluetooth mostra diversi limiti. La

formazione automatica di reti non e supportata e quando il master di una piconet

si muove dalla rete l’intera rete cade, cosa che va in conflitto con le caratteristiche

di mobilita richieste dalle applicazioni BSN. Inoltre lo start-up della connessione

e piuttosto lento, fino a 5 secondi. Infine il consumo energetico rispetto ad altre

tecnologie wireless e sensibilmente piu alto (Tabella 2.4).

2.3.2 Bluetooth 4.0: Low Energy

Nel 2001 alcuni ricercatori della Nokia, appurando che le tecnologie wireless

esistenti non erano adatte a diversi nuovi scenari applicativi, cominciarono a lavorare

a una versione adattata del Bluetooth che fornisse consumi e costi piu bassi. Il

risultato fu pubblicato nel 2004 con il nome di “Low End Extension for Bluetooth”.

Dopo alcuni sviluppi con diversi partner all’interno del progetto europeo MIMOSA

la nuova tecnologia fu rilasciata al pubblico nel 2006 col nome Wibree. Nel Giugno

2007 fu raggiunto un accordo con il Bluetooth Special Interest Group (SIG) per

includere Wibree nella futura specifica Bluetooth come una tecnologia “ultra-low-

power” e adesso conosciuta come Bluetooth Low Energy. Nel Dicembre 2009 e stato

annunciato dal Bluetooth SIG l’inserimento della nuova tecnologia come punta di

diamante della Bluetooth Core Specification Version 4.0, andandosi ad aggiungere al

59


“Bluetooth Classic” e il “Bluetooth High-Speed”. I primi dispositivi con Bluetooth

4.0 saranno disponibili sul mercato agli inizi del 2011.

Questi sono i vantaggi del nuovo Bluetooth a basso consumo:

• Consumo minimo di energia in modalita picco, media e stand-by;

• Capacita di funzionare per anni con l’energia di comuni batterie a bottone;

• Basso costo;

• Interoperabilita tra piu vendor;

• Raggio di azione potenziato.

Questo nuovo potenziamento al Core della tecnologia Bluetooth offre due imple-

mentazioni: single-mode e dual-mode. Nell’implementazione single-mode i dispo-

sitivi non sono “Bluetooth-compliant” potendo dunque comunicare solo con altri

dispositivi single-mode o dual-mode. In una implementazione dual-mode, la nuova

funzionalita e integrata all’interno di un controller Bluetooth classico permettendo

cosı la connessione anche con i dipositivi Bluetooth delle specifiche precedenti (v. 2.1

+ EDR o v. 3.0 + HS). Nella pratica piccoli device, come sensori e periferiche, sono

implementati in single-mode; in questo modo e assicuratata connettivita a lungo

termine a componenti miniaturizzati e a basso costo che ad esempio utilizzano le

classiche batterie a bottone. In [27] e mostrata la costruzione di un chip stand-

alone (con memoria RAM, memory management unit, registri. . . ) di dimensioni

pari a 1, 84mm × 2, 53mm, appena 4, 65mm2. Dispositivi dual-mode sono, invece,

dispositivi Bluetooth tradizionali che permettono pero la comunicazione anche con i

nuovi dispositivi stand-alone; un cellulare, un PDA, il personal-device in una BSN,

dovrebbero essere dispositivi dual-mode.

Segue qui un riassunto dei dettagli tecnici:

• Trasferimento dati: Bluetooth low energy supporta pacchetti dati molto corti

(da un minimo di 8 ottetti a un massimo di 27 ottetti) trasmessi a 1 Mbps.

60


Tutte le conessioni utilizzano un avanzato “sniff-subrating3” per raggiungere

un duty-cicle molto basso.

• Frequency Hopping: Bluetooth low energy utilizza il frequence hopping adat-

tativo come tutte le versioni di Bluetooth;

• Latenza: Il tempo di connessione e stato ridotto fino a 3ms, permettendo a

un applicazione di formare una connessione e poi trasferire dati autenticati in

pochi millesecondi per poi chiudere le connessione velocemente (con vantaggi

ulteriori nel consumo energetico);

• Range: L’aumento dell’indice di modulazione da la possibilita di copertura

fino a 100m.

• Robustezza: Bluetooth low energy usa un CRC a 24 bit su tutti i pacchetti

assicurando massima robustezza contro le interferenze.

• Sicurezza: La nuova specifica utilizza una tecnica di crittografia AES-128 con

CCM (Counter con CBC-MAC).

• Topologia: E utilizzato un indirizzo a 32 bit per ogni slave permettendo la con-

nessione di un numero enorme (232) di dispositivi. La tecnologia e ottimizzata

per connessioni uno-a-uno ma permette anche connessioni uno-a-molti utiliz-

zando una topologia a stella. Con l’uso di connessioni e disconnessioni veloci,

i dati possono essere mossi come in una topologia mesh senza la complessita

di dover mantenere una rete mesh.

Confrontato con il Bluetooth classico il nuovo Bluetooth Low Energy sembra

essere molto piu efficiente, anche se la velocita di trasmissione massima e 1 Mbps,

3Una modalita in cui uno slave puo trovarsi e lo sniff-mode. Lo slave che passa in questo stato sitrova in una modalita di risparmio energetico. Per entrare nello sniff mode, master e slave devononegoziare due parametri: uno sniff interval ed uno sniff offset. Con il primo si fissano gli slot disniff, mentre con il secondo si determina l’istante del primo slot di sniff. Quando il collegamentoentra in sniff mode, il master puo inviare pacchetti solamente all’interno degli sniff slot. Quindilo slave ascolta il canale ad intervalli ridotti. Lo sniff subrating abilita i dispositivi a mettersid’accordo sul tempo da aspettare tra l’invio, e quindi ascolto, di messaggi. Questa tecnica puoaumentare significativamente la vita della batteria.

61


soprattutto in termini di latenza e consumo energetico, due requisiti fondamentali

nelle Body Sensor Network. Questo e stato possibile ottimizzando 3 aspetti basi del

Bluetooth:

1. Messaggi di avviso per “connectability” e “discoverability”

Nel Bluetooth classico affinche un dispositivo sia “connectable” e “discovera-

ble”, ovvero ci si possa connettere e sia visibile nella scansione dei dispositivi

disponibili, esso deve accendere il ricevitore sperando che ci sia qualcuno che

voglia effettivamente trasmettergli qualcosa. Questo rende necessario tenere

accesa la radio per un periodo di tempo che e pari a 22 µs visto che un di-

spotivo fara uno scan su 32 differenti frequenze alla ricerca di altri dispositivi

e questo richiede un certo tempo. Con il Bluetooth Low Energy, invece, il

dispositivo che vuole essere visibile deve solo trasmettere 3 brevi pacchetti e

ascoltare se qualcuno desidera effettivamente comunicare. Il tempo per l’invio

dei pacchetti e l’ascolto e di soli 1,4 µs con un’efficienza di circa 17 volte ri-

spetto al Bluetooth classico. Inoltre i tre pacchetti possono anche trasportare

dati da inviare in broadcast.

2. Eventi di connessione e comunicazione

Quando e richiesta una connessione, tutte le informazioni necessarie sono con-

tenute nel pacchetto inviato dal dispositivo master che ha avviato la con-

nessione allo slave. Queste informazioni includono la mappa dei canali per

l’Adaptive Frequence Hopping e l’informazione per la trasmissione negli slot

corretti. Questo invio non rende necessario la negoziazione di altri parame-

tri prima dell’invio dei dati veri e propri. Questo risparmia tempo (minore

latenza) e risparmia energia.

E prevista anche una tecnica di lazy acknowledgement per l’invio di un mes-

saggio di ACK solo quando assolutamente necessario.

62


Figura 2.11. BSN che utilizza Bluetooth + Health Device Profile (Fonte: BluetoothSIG).

3. Pacchetti piu efficienti

Una velocita di 1 Mbps al livello fisico vuol dire che ad esempio l’invio di 4

byte richiede 32 µs. Bisogna pero considerare anche l’overhead aggiunto al

pacchetto rispetto ai dati veri e propri. Con il Bluetooth Low Energy questo

overhead e stato ridotto a circa la meta; il che significa una minore energia

richiesta per la trasmissione della stessa quantita di dati rispetto alle radio

Bluetooth standard.

Bluetooth Low Energy puo essere utilizzato all’interno di BSN in reti intra-BAN

configurate a stella, che non richiedano algoritmi di routing complessi e che coprano

pochi metri. L’aumento della copertura massima, inoltre, permette anche l’utilizzo

in reti inter-BAN utilizzando dispositivi dual-mode come personal-device.

L’utilizzo del Bluetooth Low Energy come possibile tecnologia del futuro per reti

di sensori corporali e forse rappresentato dall’annuncio fatto nel Giugno del 2009 in

cui la “Continua Health Alliance”, formata da industrie leader nel settore sanitario

e tecnologico che cooperano nel tentativo di creare un sistema di dispositivi perso-

nali per la telemedicina interoperabili tra loro, ha dichiarato la selezione della nuova

tecnologia Bluetooth, tra tante altre, come la tecnologia da includere nella seconda

versione delle “Continua Health Alliance Design Guidelines” come soluzione wireless

“low-power”. Il Bluetooth Low Energy, quindi, va ad aggiungersi al Bluetooth Clas-

sic + “Health Device Profile” (HDP) che attualmente e l’unica specifica per la tecno-

63


logia wireless inclusa nella prima versione delle “Guidelines”. D’altronde gli ultimi

anni hanno visto crescere notevolmente l’attenzione verso l’Health Device Profile,

un profilo Bluetooth studiato appositamente per applicazioni mediche e che puo nel

prossimo futuro rappresentare il vero valore aggiunto per il successo del Bluetooth

Low Energy nel mondo delle BSN. L’HDP, inserendo nella sua specifica lo standard

IEEE 11073 (Sezione 2.5.3), fornisce la possibilita a tutti quei dispositivi medicali

che gia utilizzano lo standard IEEE di poter utilizzare facilmente il Bluetooth come

tecnologia wireless. Infatti gia diversi produttori utilizzano il Bluetooth ma defini-

scono un protocollo proprietario per l’incapsulamento dei dati. Lo scopo dell’HDP

e permettere una standardizzazione del formato dati, sulla base dell’IEEE 11073,

incrementando l’interoperabilita dei dispositivi: HDP definisce solo il meccanismo

per la creazione della connessione e lo scambio dei dati su Bluetooth; le procedure

per lo scambio dei dati tra dispositivi medici e il formato dei dati associati si basa

sugli standard della famiglia IEEE 11073, che viceversa sono transport-indipendent

e quindi si affidano a quanto definito dall’HDP per il trasporto. In particolare HDP

specifica un modo per creare un canale di controllo e uno (o due) canali dati (ca-

nale di data-streaming o canale dati affidabile) tra dispositivi. Inoltre fornisce la

sincronizzazione del clock tra dispositivi e l’identificazione dei dispositivi stessi. In

generale il dispositivo e in base al ruolo ricoperto un Source, che rappresenta un

piccolo device che trasmette i dati medici, e/o un Sink, che rappresenta un piccolo

device che raccoglie i dati raccolti da uno o piu Source. In una BSN tipica i Source

sono i vari nodi sensori che raccolgono parametri vitali del paziente (glucometro,

pulsossimetro. . . ) mentre un generico personal-device e il Sink. In Figura 2.11 e

mostrata una BSN che nella comunicazione intra-body utilizza il Bluetooth + HDP.

L’accoppiata Bluetooth Low Energy + HDP rappresenta, quindi, la soluzione forse

del prossimo futuro che garantira, grazie alle caratteristiche della nuova tecnologia

Bluetooth, prestazioni elevate soprattutto in termini di latenza e basso consumo

energetico, e interoperabilita grazie all’HDP e l’utilizzo degli standard IEEE 11073.

64


2.3.3 IEEE 802.15.4 e ZigBee

Attualmente, come gia visto in Tabella 2.2, lo standard wireless piu utilizzato e

l’IEEE 802.15.4 che garantisce consumi energetici molto bassi (Tabella 2.4) e costi

di produzione ridotti.

Il documento IEEE 802.15.4-2003 definisce il livello fisico (PHY) ed il sotto-livello

medium access control (MAC) per reti wireless personali a bassissima complessita,

bassissimo costo e bassissimo consumo di energia.Il livello fisico fornisce due servi-

zi, detti data service e management service. Il data service abilita la trasmissione

e la ricezione di PDU - Protocol Data Unit - di livello fisico sul canale radio fisi-

co. Il management service si occupa, invece, dell’attivazione e disattivazione del

trasmettitore radio, rilevamento dell’energia o ED - Energy Detection e di fornire

un’indicazione della qualita del canale o LQI - Link Quality Indicator. E possibile,

infatti, rendere dinamica la selezione del canale in base a considerazioni su Energy

detection e qualita del canale. La misura dell’ED consiste in una stima della potenza

del segnale ricevuto su un canale; non vengono effettuate operazioni per identificare

o decodificare il segnale. Il LQI intende caratterizzare la potenza e/o la qualita di

un pacchetto ricevuto. La misurazione puo quindi avvenire attraverso una misura

dell’ED e della stima del rumore presente nel segnale.

Le responsabilita del livello MAC dell’IEEE 802.15.4 sono: generare frame di

beacon (coordinatore), sincronizzazione ai beacon, supportare l’associazione e di-

sassociazione, supportare la cifratura MAC, utilizzo del meccanismo CSMA/CA

unslotted/slotted4 per l’accesso al canale, allocazione e gestione di “guarented time

slot” (GTS).

4Il Carrier Sense Multiple Access with Collision Avoidance viene utilizzato per evitare collisionisul canale. Quando un device vuole utilizzare un canale verifica se questo e libero; in caso affer-mativo comunica alle altre stazioni la sua intenzione di trasmettere, aspetta un tempo casuale ese trova il canale ancora libero avvia la trasmissione. Quando il canale e trovato occupato, invece,la stazione aspetta un tempo casuale, detto tempo di backoff, prima di riprovare l’accesso. Se iperiodi di backoff sono allineati agli slot del superframe si parla di slotted CSMA-CA, altrimentidi unslotted CSMA-CA. Quindi nel caso unslotted i periodi di backoff di un dispositivo non sonosincronizzati con quelli di un altro dispositivo.

65


Figura 2.12. Struttura della superframe

IEEE 802.15.4 definisce 4 tipi di frame: beacon frame, data frame, aknowled-

gement frame, MAC command frame. Per il trasferimento dati esistono 3 tipi di

comunicazioni: dal coordinatore al dispositivo, dal dispositivo al coordinatore e tra

due dispositivi “peer”.

Il livello MAC fornisce due schemi per l’accesso al mezzo: modalita “beacon-

enabled” e “non-beacon-enabled”. In modalita beacon-enabled e utilizzata una su-

perframe (Figura 2.12). Una superframe e divisa in due porzioni: attiva e inattiva.

Durante la porzione inattiva, i dispositivi possono entrare in modalita low-power in

accordo ai requisiti dell’applicazione. La porzione attiva consiste di un “contention

free period” (CFP) e un “contention access period” (CAP). Ogni dispositivo che

desidere comunicare durante il CAP deve contendersi l’accesso al mezzo con gli altri

dispositivi utilizzando il meccanisco CSMA/CA slotted, mentre il CFP contiene slot

garantiti e la contesa non e necessaria. Tuttavia, se un coordinatore preferisce non

usare la modalita beacon-enabled, puo fermare la trasmissione delle frame di beacon

e in questo caso verra utilizzato l’algoritmo CSMA/CA unslotted.

Se e il coordinatore a voler inviare dati ad un device, nel caso di rete con beacon

abilitati, il coordinatore indica nei suoi messaggi beacon l’intenzione di trasmettere;

il dispositivo che periodicamente ascolta il canale per rilevare i beacon determina la

presenza di un messaggio in attesa e, utilizzando lo slotted CSMA-CA, lo richiede.

Anche il coordinatore usa slotted CSMA-CA per inviare il messaggio. Ricevuto un

messaggio di ack dal ricevente il messaggio viene eliminato dalla lista degli uscen-

66


ti. Se invece la rete non e beacon-enabled, il coordinatore memorizza i dati per

il dispositivo che deve riceverli e attende di ricevere la richiesta da questo. Il di-

spositivo usa comandi MAC per richiedere i dati, usando unslotted CSMA-CA. Il

coordinatore invia un ack e quindi i dati. Si nota, quindi, che i trasferimenti dati

sono completamente controllati dai dispositivi piuttosto che dal coordinatore. Un

dispositivo puo sia trasferire dati al coordinatore sia interrogare il coordinatore per

ricevere dati, sempre in accordo al rate definito dall’applicazione. Questo consen-

te un efficiente risparmio energetico perche i dispositivi possono “dormire” appena

possibile, piuttosto che mantenere continuamente attivo il ricevitore.

Un altro meccanismo fornito per la robustezza della trasmissione dei dati e quello

di acknowledgement dei frame, il quale consente di avere riscontro della ricezione e

della validazione dei dati. Vengono utilizzati poi meccanismi di data verification,

quali frame check sequence e cyclic redundancy check.

Sia le trasmissioni downlink che uplink competono per la stessa risorsa: nessuno

schema duplex e specificato.

In [28], e mostrato come l’IEEE 802.15.4 possa soffrire la convivenza con altre

trasmissioni WLAN e in particolare con lo standard 802.11. Questo, aggiungen-

dosi alla path loss fortemente variabile dovuta alle comunicazioni in prossimita del

corpo umano, porta a prestazioni non soddisfacenti nell’utilizzo dell’IEEE 802.15.4

come tecnologia wireless in BSN. Inoltre la velocita massima di trasmissione di

250 kbps puo essere inadeguata a fornire dati real-time in alcuni scenari applicativi,

soprattutto in BSN di dimensioni medio-grandi.

ZigBee e una specifica della ZigBee Alliance derivata dallo standard 802.15.4.

Come mostrato in Figura 2.13 ZigBee costruisce il livello Rete e il livello Applica-

zione, sopra il livello PHY e il sotto-livello MAC specificati dallo standard IEEE

802.15.4. Il livello PHY fornisce le capacita di comunicazione base della radio, il

livello MAC fornisce servizi per comunicazioni su link single-hop tra dispositivi, il

livello rete fornisce funzionalita di routing e multi-hop per creare topologie di rete

67


Figura 2.13. Stack di comunicazione ZigBee.

piu complesse e implementa la sicurezza, e il livello applicazione e costituito dai

driver e dal codice, contenuti nella ROM del microcontrollore.

ZigBee, similmente a IEEE 802.15.4, opera dunque alle frequenze radio ISM, ma

ha come scopo quello di ottenere consumi energetici inferiori, di essere piu semplice,

piu economico e piu scalabile. Tale specifica ha un range di funzionamento dai 10

ai 75 metri, con dispositivi che superano anche i 300 metri in ambiente oudoor.

ZigBee/IEEE 802.15.4 puo operare in tre bande ISM: una ad alta frequenza, 2.4

GHz con 16 canali, con data rate di 250kbps, l’altra a bassa frequenza, 915MHz con

10 canali a 40kbps, o 868MHz con un canale a 20kbps.

I dispositivi Iris Mote che utilizzeremo (Capitolo 3) lavorano nella banda di 2450

MHz con canali da 11 a 26 definiti come: Fc = 2405+5(k−11) MHz, k = 11, 12,. . . ,

26 dove k e il numero del canale.

Un dispositivo ZigBee diventa attivo alla ricezione di un pacchetto in circa 15 mil-

lisecondi (mentre un dispositivo Bluetooth richiede circa 3 secondi). Inoltre rispetto

al Bluetooth che supporta solo piccole reti (piconet), ZigBee consente di creare reti

con molti nodi in configurazioni master-slave; in particolare sono supportate tre tipi

di topologie: star, cluster-tree, mesh. ZigBee ha il vantaggio di fornire routing multi-

hop sia in topologie cluster-tree sia in topologie mesh (utilizzando come algoritmi

68


di routing Ad-hoc On-demand Distance Vector (AODV) e Cluster Tree). In questo

modo la copertura di una rete BSN puo essere facilmente estesa. Una rete mesh

ZigBee puo includere sia dispositivi “full-function” (FFD) sia dispositivi “reduced-

function” (RFD) come previsto gia nell’IEEE 802.15.4. Il primo e l’equivalente di

un chip dual-mode nel Bluetooth Low Energy e puo agire da coordinatore oppure

da router5; il RFD e l’equivalente di un chip single-mode in Bluetooth Low Energy

e non puo lavorare come coordinatore ma solo come end-device.

La funzionalita GTS fornita in IEEE 802.15.4 non e accessibile ad applicazioni

ZigBee. Questo e uno svantaggio perche questo meccanismo potrebbe essere utile nel

caso fosse necessaria una bassa latenza e data-rate fissi, per esempio un monitoraggio

dell’ECG, allocando slot della superframe attiva al dispositivo.

Uno dei principali vantaggi di ZigBee rispetto ad altre tecnologie wireless di pros-

simita, e l’elevato livello di sicurezza che viene supportato a livello di collegamento

fra 2 nodi di rete, ma anche a livello rete ed applicativo. E previsto un controllo

degli accessi (ogni dispositivo mantiene una lista di tutti i potenziali trasmettito-

ri), codifica dei dati (i dati sono crittografati con AES-128bit), rinnovo sequenziale

(ogni frame viene confrontato con il precedente per evitare che ci siano ripetizioni),

integrita dei frame (sui bit di tutto il frame viene calcolato un check).

Anche la ZigBee Alliance ha pubblicato un “Health Care Profile” nel Marzo del

2009 per fornire un framework flessibile che sposi le richieste della Continua Health

Alliance nella telemedicina e il “fitness-monitoring” e supporti i dispositivi IEEE

11073. Tuttavia l’attuale notevole successo di ZigBee anche in applicazioni BSN

e probabilmente dovuto all’influenza che le WSN hanno avuto sulle BSN. ZigBee,

infatti, sembra avere opportunita maggiori nel campo della domotica, automazione

e controllo industriale, mentre nell’area delle connessioni tra dispositivi low-power

intorno al corpo umano la nuova tecnologia Bluetooth Low Energy possiede si-

5Un FFD e un router quando partecipa in una rete ZigBee non come coordinatore ma puo agirecome coordinatore nel suo “personal operating space”. Un router e capace di routing dei messaggitra dispositivi.

69


curamente un potenziale maggiore dovuto ai bassi consumi, data-rate piu elevati,

dimensioni dei chip single-mode di pochi mm e costi bassi.

2.3.4 UWB e IEEE 802.15.6

In accordo alla Federal Communication Commision (FCC), Ultra-Wideband si

riferisce a qualsiasi tecnologia radio che ha una elevata larghezza di banda; in parti-

colare che superi almeno i 500Mhz o il 20% della frequenza centrale. La FCC regola

anche l’uso di UWB nelle frequenze libere nel range 3,1 – 10,6 GHz.

Tradizionalmente UWB e una tecnologia sviluppata per trasmettere e ricevere

segnali mediante l’utilizzo di impulsi di energia in radiofrequenza di durata estre-

mamente ridotta (da poche decine di picosecondi a qualche nanosecondo). Questi

impulsi sono rappresentati da pochi cicli d’onda di una portante in radiofrequenza

e quindi lo spettro in frequenza associato a questa forma d’onda e estremamente

ampio (da qui il nome).

La larghezza della banda fa sı che la densita spettrale di potenza sia molto

bassa, questa caratteristica rende le comunicazioni difficilmente intercettabili perche

il segnale ha un’intensita simile al rumore di fondo, inoltre non interferisce con le

tecnologie wireless gia esistenti e permette di realizzare dispositivi con un consumo

energetico molto ridotto (Tabella 2.4).

Questo rende UWB idoneo in applicazioni a breve raggio e ambienti interni o

in ambienti sensibili alle emissioni RF, ad esempio in ospedale, in casa del paziente

etc. I prodotti commerciali che utilizzano UWB forniscono data-rate elevati, ad

esempio dispositivi “Certified Wireless USB” lavorano fino a 480 Mbps, permettendo

applicazioni wireless multimediali su breve distanze, come monitor senza fili, lettori

audio e video wireless. . . Inoltre i produttori affermano che potranno essere raggiunte

velocita di 1 Gbps. Questi livelli di data-rate proposti avvicinano le caratteristiche

di un collegamento wireless alle piu comuni e famose LAN cablate (Fast Ethernet)

70


riuscendo in un futuro non troppo lontano a raggiungere questi risultati con mobilita,

scalabilita, flessibilita proprie di una rete senza fili.

In questo modo e possibile abilitare traffico di tipo multimediale in BSN e ri-

solvere i problemi legati alle velocita di trasmissioni massime troppo basse delle

tecnologie viste finora. UWB e anche una tecnologia ideale per la geo-location: i

sistemi UWB sono in grado di determinare misurazioni su posizionamenti a pochi

centimetri (nell’ordine di 1 cm); questo potra essere utilizzato per il tracking indoor

della persona in BSN.

Allo stesso tempo, le preoccupazioni sull’energia elettrica e magnetica assorbita

dal corpo umano da circuiti RF posizionati in sua prossimita rende necessario l’uti-

lizzo di dispositivi con bassa potenza di trasmissione e basso duty cycle. A questo

proposito UWB sorpassa ampiamente i metodi di trasmissione tradizionali.

In accordo alle recenti proposte e le novita degli ultimi mesi, e molto probabile

che l’IEEE 802.15.6 impieghera l’UWB. UWB infatti e incluso nell’ultimo draft pub-

blicato. Lo standard ha, dunque, intenzione di adottare come soluzione componenti

elettronici di nuova generazione. Tuttavia, attualmente ancora non e dato sape-

re quando potranno vedersi sul mercato i primi dispositivi che incorporano questo

standard.

2.4 Piattaforme Software

Una volta scelto l’hardware da utilizzare, va scelto l’ambiente di sviluppo, il

compilatore, il debugger e deciso se e necessario utilizzare un sistema operativo per

il dispositivo. Alcuni dei processori embedded non supportano sistemi operativi

real-time ma si affidano a un programma in esecuzione in loop continuo e gestione

degli interrupt.

La prima domanda a cui rispondere e se e necessario un sistema operativo real-

time (RTOS) o basta un semplice scheduler. Una piccola applicazione puo non

71


richiedere un sistema operativo real-time completo; un loop continuo che provve-

da “information storage and retrieval” (ISR) puo essere adeguato per molti nodi

sensore. Un RTOS e invece necessario in dispositivi piu grandi, come i gateway.

Per dispositivi molto piccoli una soluzione adeguata puo anche essere uno scheduler

proprietario.

Come visto in Tabella 2.2 tra le numerose piattaforme, progettate soprattutto

nell’ambito delle WSN, TinyOS rappresenta certamente la soluzione attuale piu

adottata. Pertanto qui di seguito ne viene fornita una sua panoramica.

Oltre al software a bordo sensore, poi, sono necessari diversi strumenti software

per la raccolta, la visualizzazione e quindi la memorizzazione, la post-elaborazione

e l’analisi dei dati.

2.4.1 nesC e TinyOS

TinyOS e un sistema operativo free ed open source, scritto in nesC e nato dalla

collaborazione tra Universita di Berkley, Intel Research e Crossbow Technology, con

il fine di creare un sistema operativo ottimizzato per ridurre i consumi di energia,

ridurre il sovraccarico computazionale, minimizzare le dimensioni del sistema opera-

tivo, supportare le richieste di operazioni frequenti e concorrenti con un alto livello

di robustezza ed efficienza.

nesC e un dialetto del C, come definito da uno dei suoi progettisti, David Gay,

creato specificamente per sensori. Per certi versi si tratta di un’estensione del C in

quanto fornisce un modello ad eventi non previsto dal linguaggio base, ma ne perde

le funzionalita relative a puntatori e allocazione dinamica della memoria. Un’ap-

plicazione nesC e un insieme di componenti collegati da interfacce, ognuna delle

quali modella un servizio offerto o utilizzato. In tal modo si ottiene un’astrazione

dei componenti il cui utilizzo e indipendente dall’implementazione. Un componente

che fornisce un’interfaccia deve implementarne i comandi, mentre il comportamento

al verificarsi degli eventi compete a chi li utilizza. In fase di compilazione, co-

72


mandi ed eventi vengono tradotti in normali chiamate a funzione, ma l’astrazione

delle interfacce rende la programmazione piu agevole e favorisce la portabilita delle

applicazioni. L’implementazione di un componente prevede un modulo ed una con-

figurazione; nel primo vengono specificate le interfacce utilizzate e fornite e vengono

implementati gli eventi delle prime e i comandi delle seconde. La configurazione,

invece, specifica quali componenti implementano le interfacce dichiarate nel modulo

stabilendo i collegamenti - o wiring - tra fornitori ed utilizzatori. Il codice nesC

puo essere sia asincrono che sincrono. Comandi ed eventi costituiscono codice asin-

crono, ovvero codice che puo essere raggiunto da almeno un gestore degli interrupt.

nesC fornisce poi task e sezioni atomiche per introdurre codice sincrono. Si tratta

di una collezione di comandi che costituiscono una sequenza indivisibile, ovvero la

cui esecuzione non e interrompibile se non da codice asincrono, ovvero comandi ed

eventi, i quali hanno sempre la priorita. I task sono gestiti da uno scheduler con

politica FIFO. Questo semplice meccanismo di concorrenza risulta sufficiente per

applicazioni incentrate sull’I/O, ma diventa carente all’aumentare del carico per la

CPU. In particolare siccome i task sono non-preemptive allora nessun altro task puo

interrompere il task in esecuzione e quindi non bisogna preoccuparsi delle interferen-

ze tra task. Tuttavia, questo significa anche che un task dovrebbe essere abbastanza

corto per non monopolizzare il controllo del microprocessore e se un componente

deve eseguire lunghe operazioni, quindi, e meglio dividerle in piu task.

TinyOS differisce sostanzialmente dai sistemi operativi tradizionali; innanzitutto

e sprovvisto di un kernel che gestisca le risorse disponibili per cui non consente l’ese-

cuzione di piu applicazioni. Inoltre TinyOS si integra direttamente nel programma

sviluppato, che risulta dunque una collezione di componenti nesC a cui si aggiunge

uno scheduler che ha il compito di gestire l’esecuzione dei task e delle funzioni.

TinyOS esegue un programma usando due soli thread, uno contenente i task, di

cui si e parlato sopra, e un’altro contenente i gestori di eventi hardware, che vengono

eseguiti in risposta a interrupt hardware. La scelta di utilizzare solo due thread e

73


Figura 2.14. Operazione split-phase in TinyOS.

dovuta al fatto che un problema comuno nell’uso dei thread in sistemi operativi

real-time e che richiedono una gran quantita di RAM (ogni thread ha il proprio

stack che va memorizzato quando e in attesa o in idle), spesso non disponibile sulle

piattaforme.

Inoltre, considerate sempre le risorse hardware limitate, TinyOS gestisce in ma-

niera efficiente e flessibile il confine hardware/software: le operazioni hardware sono

eseguite secondo il paradigma split-phase piuttosto che a blocco. In un sistema a

blocchi quando un programma chiama una lunga operazione la chiamata non ritorna

fintanto che l’operazione e completa. In un sistema split-phase, invece, quando un

programma chiama una funzione molto lunga la chiamata ritorna immediatamente

e quando il chiamato ha completato effettuera una callback. In questo modo non

bisogna aspettare necessariamente il completamento dell’operazione (Figura 2.14).

I componenti di TinyOS possono essere raggruppati in tre categorie:

• Astrazioni Hardware, ovvero i componenti che forniscono le interfacce per

accedere all’hardware di sistema; contribuisce alla portabilita del codice;

• Hardware simulato, costituito dai componenti che attraverso le loro interfacce

simulano le prestazioni di hardware piu complesso di quello effettivamente

presente nella piattaforma in uso;

74


Figura 2.15. Architettura di TinyOS.

• Componenti di alto livello che forniscono le funzioni di elaborazione piu com-

plesse prescindendo dal particolare hardware.

In Figura 2.15 e riportata l’architettura di TinyOS. Come si puo vedere si ha una

decomposizione in layer verticali ed orizzontali, dove il livello piu alto e costituito

dal componente Main e il piu basso dall’hardware.

Lo stack di comunicazione e basato sugli Active Message che rappresentano un

semplice paradigma per le comunicazioni basate sullo scambio di messaggi. Ogni

AM contiene un nome di un handler di livello utente che viene invocato sul nodo

target all’arrivo del messaggio, a cui viene passato come argomento il payload del

messaggio. Gli handler ricoprono un duplice ruolo: hanno la funzione di estrarre i

messaggi dalla rete e allo stesso tempo di inoltrarli per una possibile elaborazione,

oppure semplicemente per inviare un messaggio di risposta. In questo modo la rete

viene modellata come una pipeline con un minimo di buffer per la memorizzazione dei

messaggi. Questo modello di invocazione degli handler basato sugli eventi semplifica

75


la realizzazione del codice in quanto:

• elimina molte difficolta dovute all’implementazione di protocolli che prevedono

la gestione dei buffer di invio e ricezione;

• consente di evitare le attese quando e in arrivo un messaggio, permettendo al

sistema di svolgere della azioni contemporaneamente all’invio e ricezione dei

dati.

2.4.2 Raccolta, Storage e Post-Processing dei dati

Per la raccolta, memorizzazione, post-elaborazione e visualizzazione / analisi dei

dati possono essere utilizzati gran parte degli strumenti software gia presenti sul

mercato.

Per i software da utilizzare nella raccolta dei dati dai nodi sensore, fondamentale

e soprattutto il tipo di comunicazione intra-BAN e inter-BAN utilizzato. Si potreb-

be, ad esempio, trasmettere i dati sfruttando la connessione Internet di un PDA

che funziona come personal device oppure prevedere l’utilizzo di una “base station”

connessa a un PC che raccoglie tutti i pacchetti inviati dai nodi sensore (come verra

mostrato al Capitolo 3). La soluzione scelta, e i software necessari, dipendono stret-

tamente dalle funzionalita che l’applicazione deve offrire, come si puo ben intuire.

Nel caso del primo esempio un’applicazione per PDA verra implementata in modo

che i pacchetti raccolti dalla rete vengano letti e i dati di interesse inviati nuovamen-

te sulla connessione Internet. Nel secondo esempio, invece, software quali Matlab,

LabView permettono di eseguire letture dei dati direttamente dalla porta seriale e

processarli in tempo reale. Potrebbe inoltre essere scritto del codice Java ad hoc.

Un’ottima soluzione e quella di implementare un Serial Forwarder che mappa

la comunicazione su porta seriale su una connessione logica TCP/IP, agendo come

proxy. Una soluzione di questo tipo ha il notevole vantaggio di permettere a piu

applicazioni di utilizzare contemporaneamente il flusso dati (solo un’applicazione alla

76


volta puo usare direttamente la porta seriale) e permettere in aggiunta la possibilita

di eseguire applicazioni su calcolatori che non sono fisicamente connessi alla base

station (le applicazioni possono connettersi su una connessione Internet).

Un problema da risolvere e certamente il parsing dei messaggi che arrivano dalla

rete. Se la piattaforma a bordo sensore e TinyOS, un utile tool fornito da TinyOS

e Message Interface Generator (MIG) che permette di generare automaticamente

codice Java, Python o C che, data una sequenza di byte, permetta il parsing au-

tomatico di ogni campo nel pacchetto. Ad esempio il comando seguente, inserito

all’interno del Makefile che permette la compilazione della propria applicazione in

TinyOS, e stato utilizzato per l’applicazione di cui al Capitolo 3 per creare una

classe DataMsg.java che fornisse i metodi per il parsing dei messaggi ricevuti:

mig java -java-classname=tinyos.ReadingAccel.DataMsg /opt/MoteWorks/ \

apps/mine/ReadingAccel/Message.h DataMsg -o DataMsg.java

Per la memorizzazione permanente della grande quantita di dati grezzi generati

dai nodi sensori di una BSN, possono essere utilizzati tutti gli strumenti gia esistenti.

Lo stesso si dica per l’analisi dei dati. Ancora una volta la scelta del software

dipende dal tipo di analisi da condurre sui dati. Per analisi di tipo matemati-

co strumenti molto potenti come LabView, Matlab, Mathematica possono essere

utilizzati.

La scelta del database e dei software di data mining / analisi non verra qui

discussa siccome i tool disponibili non sono specifici del dominio delle BSN.

2.5 Standard e Interoperabilita

Il crescente interesse nelle BSN, in particolare nell’ambiente sanitario, ha por-

tato alla creazione di una serie di piattaforme e applicazioni. I maggiori fornitori

di tecnologie per il mercato dell’assistenza sanitaria hanno promosso nel tempo le

proprie soluzioni proprietarie. Questo ha portato a relazioni commerciali chiuse tra

77


vendor e compratori, permettendo ai produttori di sviluppare le proprie soluzioni

senza tenere in conto delle soluzioni di altri fornitori.

L’esistenza di tante soluzioni proprietarie, tuttavia, manca in interoperabilita;

da qui l’esigenza crescente di standardizzazione sia per favorire l’interoperabilia in

modo da poter utilizzare i diversi dipositivi come una rete omogenea ma anche per

abbattere i costi e permettere a compagnie, che tradizionalmente non apparteneva-

no a questo mercato, di sviluppare le proprie applicazioni. Inoltre, come piu volte

ribadito, una BSN raramente lavora sola e la mancanza di uno standard rende dif-

ficile l’integrazione delle nuove applicazioni BSN con le tecnologie gia esistenti nelle

strutture ospedaliere. E proprio la necessita di dover comunicare con le tecnolo-

gie esistenti che rende necessario l’utilizzo degli standard gia in uso. In aggiunta

nel monitoraggio continuo del paziente un ulteriore contributo potrebbe essere da-

to da tutti quei dispositivi che attualmente vengono ampiamente utilizzati nella

vita quotidiana e che non sono stati necessariamente pensati per applicazioni medi-

che, ad esempio sistemi per l’home fitness. Infine la situazione attuale in cui esiste

una grande eterogeneita di dispositivi rende difficile sostituire qualsiasi dispositi-

vo (perche puo diventare obsoleto oppure perche sensori migliori sono disponibili o

anche perche mancano in usabilita, non funzionano correttamente o sono cambiate

le richieste dell’utente) quando necessario e l’aggiunta di nuovi dispositivi al siste-

ma senza modificare l’intera architettura. Per riuscire in questo e necessario uno

standard globalmente accettato che fornisca operazioni standard, permetta l’inte-

roperabilita e garantisca consistenza semantica. E importante, quindi, condividere

come comunicare (to exchange) ma soprattutto intendere le stesse cose una volta

comunicate (to use).

Il problema dell’interoperabilita puo essere risolto su tre livelli principali. Un

livello piu basso che standardizzi la tecnologia di trasporto delle informazioni. Un

livello superiore dove vanno sviluppati dei profili applicazione che definiscono le ca-

ratteristiche di trasporto che devono essere usate per supportare al meglio i requisiti

78


dell’applicazione. Infine a livello applicazione vanno sviluppati modelli e formato

dei dati.

Attualmente non esiste uno standard che risolva il problema dell’integrazione e

interoperabilita dei dipositivi in casa e nelle strutture ospedaliere ma il settore si

sta muovendo verso questo obiettivo. Nelle sezioni che seguono verra offerta una

panoramica sui piu importanti standard esistenti ed in particolare sullo standard

ISO / IEEE 11073 che attualmente e il migliore standard per l’interoperabilita Plug

and Play di dispositivi per l’assistenza sanitaria e l’unico che ha dato attenzione

specifica a dispositivi per l’assistenza sanitaria personalizzata, in cui rientrano i

dispositivi per BSN, attraverso il gruppo di standard ISO / IEEE 11073 Personal

Health Data (PHD). Nonostante la sua notevole e continua espansione, tuttavia,

la risposta dei fornitori non e stata altrettanto forte. Dato il notevole successo

e la rapida evoluzione di protocolli di comunicazioni multipurpose che sfruttano

TCP / IP e XML, la soluzione forse vedra rimpiazzare l’IEEE 11073 da un protocollo

multipurpose in futuro. Altri standard che, tuttavia, qui non verrano illustrati sono

POCT-1A2 (protocolli di comunicazione tra dispositivi e access point) e EN13606

(per comunicazioni EHR6).

2.5.1 DICOM

Lo standard DICOM (Digital Imaging and Communications in Medicine) defi-

nisce i criteri per la comunicazione, la visualizzazione, l’archiviazione e la stampa di

informazioni di tipo biomedico, quali ad esempio immagini radiologiche, ECG. . . E

pubblico, nel senso che la sua definizione e accessibile a tutti.

Lo standard DICOM si basa su un modello concettuale “Object Oriented” (OO).

Un’entita del mondo reale come un paziente, un ricovero, un’immagine. . . viene mo-

dellata come un oggetto; ogni oggetto ha in se una serie di attributi, per esempio

6Electronic Health Record (Cartelle cliniche integrate) e un insieme di informazioni digitali coni dati sanitari di un singolo individuo. A questi dati appartengono i dati demografici del paziente,la cronologia medica, l’elenco dei medicinali e delle allergie (incluso lo stato di immunizzazione), irisultati dei test di laboratorio, le immagini radiologiche e i consigli terapeutici.

79


l’oggetto paziente conterra gli attributi dati anagrafici, data di ricovero etc. De-

finiti gli oggetti di interesse e tutte le loro caratteristiche, DICOM definisce quali

operazioni possono essere eseguite e su quali oggetti. Tali operazioni sono chiamate

DIMSE service (Dicom Message Service) e vengono generalmente differenziati da

due classi di servizio: composita DIMSE-C e normalizzata DIMSE-N. Le operazioni

comprese nella classe DIMSE-C sono:

• C-Store: L’operazione piu elementare DICOM, altrimenti conosciuta come

“Push DICOM”. Viene utilizzata per inviare le immagini da una modalita al

PACS (Picture archiving and Communication System) o per creare il mecca-

nismo di consegna del C-MOVE;

• C-Move: Serve per ordinare al Service Class Provider il trasferimento dell’og-

getto eventualmente restituito dalla query C-Find;

• C-Get, C-Echo;

Le operazioni comprese nella classe DIMSE-N sono N-Get, N-Action, N-Set, N-

Create, N-Delete, N-Event-Report.

La combinazione di un oggetto ed i corrispondenti DIMSE prende il nome di SOP

(Service Object Pair). L’insieme delle SOP relative ad un unico oggetto formano una

SOP Class, che rappresenta l’unita fondamentale funzionale definita da DICOM. Le

SOP Class rappresentano, quindi, le “capabilities” di DICOM. In particolare tutte

le DICOM SOP Class sono identificate da un identificativo unico (UID) e un nome.

Per quanto concerne lo scambio di informazioni alla base di DICOM esiste un

approccio client–server: ogni volta che due applicazioni decidono di connettersi per

scambiarsi informazioni, una delle due svolge il ruolo di fornitore del servizio, la

Service Class Provider (SCP) mentre l’altra quello di utente, la Service Class User

(SCU). In DICOM, tuttavia, i ruoli di SCP e SCU si riferiscono a un servizio fornito

in quel momento e non in generale. Un’entita DICOM comunemente agisce coin

80


ruoli diversi in diverse service class sia come client che come server, e spesso come

entrambi.

La classe SOP Class definisce le azioni della SCU e della SCP. Di seguito osser-

viamo l’interazione tra SCU e SCP nelle varie Service Class:

• Verification Service Class SCP/SCU: Il Servizio di verifica e semplicemente un

mezzo per determinare se un soggetto DICOM e attivo e puo essere raggiunto

sulla rete. Le richieste SCU verificano che SCP, se attivo, fornisce una risposta.

• Storage Service Class SCP/SCU: Quando SCU richiede che un’immagine ven-

ga memorizzata, chiede semplicemente al SCP di ricevere l’immagine. La SCP

non garantisce alcuna durata o la sicurezza della memorizzazione, ma accetta

semplicemente l’immagine dal mittente.

• Query/Retrieve Service Class SCP/SCU: In questo caso vengono offerti due

servizi distinti, Interrogare e Recuperare, da qui il nome di Query/Retrieve.

Quando l’SCU invia una interrogazione (come il nome del paziente, l’ID di

studio, ecc) relativa alle immagini che il provider ha a disposizione, l’SCP

risponde con le informazioni richieste di cui dispone.

I dati radiologici rappresentabili come immagini o le immagini vere e proprie

che vengono archiviate secondo lo standard DICOM sotto forma di file vengono

comunemente chiamate “immagini DICOM”. L’errore piu comune che viene fatto

nell’interpretazione del termine e che queste siano assimilabili ad altri formati di

compressione dell’immagine (es. JPEG, GIF. . . ). In verita lo standard DICOM

applicato alla codifica dei file non e nient’altro che un metodo per incapsulare i dati

e per definire come questi debbano essere codificati o interpretati, ma non definisce

alcun nuovo algoritmo di compressione. La maggior parte delle volte, l’immagine

viene archiviata in forma non compressa, secondo la codifica con la quale viene

prodotta, ma esistono molti software che sono in grado di produrre o interpretare

file DICOM contenenti dati compressi secondo vari algoritmi (JPEG, JPEG Lossless,

81


JPEG Lossy, vari algoritmi dello standard JPEG2000, etc.). Un file DICOM oltre

all’immagine vera e propria,include anche un “Header”. Le informazione contenute

nell’Header DICOM sono molteplici,per esempio: nome e cognome del paziente,

il tipo di scansione, posizione e dimensione dell’immagine ecc. Le informazioni

dell’Header vengono scritte in XXX byte del file DICOM, la dimensione ovviamente

varia a seconda della quantita di informazioni memorizzate. Tutte le informazioni

memorizzati nell’Header vengono catalogate in gruppi di elementi, detti anche “Tag

DICOM” .

Occorre notare che il DICOM e uno standard industriale, e non uno standard

ISO, quindi universale: cio comporta una certa tolleranza nell’implementazione delle

specifiche, al punto che attualmente forse non esistono apparecchiature che possa-

no definirsi pienamente DICOM compliant, nel senso rigoroso che la definizione di

uno standard imporrebbe. Nella maggior parte dei casi, infatti, un’apparecchiatura

risulta conforme ad una parte dello standard (ad esempio la modalita di archivia-

zione delle immagini), mentre adotta tecnologie proprietarie per altre funzionalita

(ad esempio la gestione delle liste pazienti).

2.5.2 HL7

HL7 nasce nel 1987 per descrivere le modalita per lo scambio in forma elettronica

di dati in ambiente sanitario e risolvere i problemi legati all’interoperabilita nell’am-

biente clinico. Dall’HL7 Mission statement (1987)si legge: “To provide standards for

the exchange, management and integration of data that supports clinical patient care

and the management, delivery and evaluation of healthcare services.”. Attualmente

e probabilmente lo standard piu riconosciuto a livello internazionale per lo scambio

di dati informatici in ambito medico. Lo standard e stato sviluppato inizialmente

per il sistema sanitario degli Stati Uniti ed ha accumulato una notevole esperienza

nell’utilizzo quotidiano nella maggior parte degli ospedali. Lo sviluppo di HL7 ormai

coinvolge l’intera comunita internazionale e l’organizzazione HL7 sta coordinando

82


gli sforzi con altri organismi internazionali di standardizzazione (es. CEN/TC 251,

DICOM, ISO/TC 215, W3C).

Il protocollo HL7 consiste in una grammatica e in un dizionario standardizzato

cosı che i dati clinici e le informazioni sanitarie di un paziente possono essere con-

divise tra tutte le applicazioni sanitarie. Esso definisce il livello di interoperabilita

per lo scambio dei messaggi tra i vari sistemi e le organizzazioni, per il supporto

alle decisioni, i linguaggi di mark-up utilizzati per la definizione dei documenti, le

interfacce tra applicazioni, i metodi per lo sviluppo dei messaggi ed il modello di

rappresentazione dei dati, i tempi e la comunicazione di errori specifici tra le applica-

zioni. HL7, quindi, standardizza l’intero complesso ospedaliero a livello di scambio

di dati clinici tra i vari settori e reparti, rende le varie “entita” del mondo sanita-

rio interoperabili, fornisce interfacce che funzionano a prescindere dal tipo di rete o

protocollo di comunicazione su cui si appoggiano, ha uno standard di messaging che

permette il flusso di dati fra sistemi diversi.

L’HL7 concettualmente viene definito come un’interfaccia application-to-application

inserita nel livello sette della pila ISO / OSI (Open System Interconnection). Lo

standard HL7 si occupa solo del livello 7 o livello applicazione dove vengono de-

finite le specifiche di astrazione del messaggio, i dati da scambiare, l’evento e il

comportamento in caso di errore, e non si occupa dei livelli sottostanti. In questo

modo, in conformita con gli elementi definiti dall’ISO (International Organization

for Standandardization) l’HL7 non si occupa del metodo con cui avverra l’inoltro

del messaggio. Quindi, la dizione “Level 7” fa riferimento proprio al livello piu alto

del modello OSI.

Il paradigma centrale del protocollo per lo scambio dati e lo scambio di messaggi

tra applicazioni che vogliono comunicare. HL7 e un protocollo governato da eventi:

ad eventi nel mondo reale, come situazioni di pericolo per il paziente, corrisponde

l’inizio di una comunicazione tra le applicazioni interessate. L’evento e chiamato

evento trigger. In altre parole, un’applicazione che incontra un evento nel mondo

83


Figura 2.16. Composizione di un messaggio HL7.

reale invia un messaggio ad altre applicazioni che hanno bisogno di essere informate

su tale evento.

Un messaggio e quindi una collezione di dati contenente informazioni inviate a

seguito di un evento in un sistema sanitario. HL7 di conseguenza descrive in maniera

particolareggiata il “layout” dei messaggi che vengono scambiati. Ogni messaggio e

definito da un Message Type che ne identifica la struttura, ovvero le le regole di for-

mattazione utilizzate e la disposizione dei dati. Ad esempio il tipo Messaggio ADT e

utilizzato per trasmettere i dati demografici di un paziente da un sistema a un altro.

Un codice di tre caratteri contenuto in ogni messaggio identifica il suo Message Ty-

pe. I messaggi sono divisi in una sequenza ordinata di Segmenti e identificati con il

nome del paziente. I Segmenti sono costituiti da Campi (Data Field). I Campi pos-

sono contenere Componenti (Data Elements) e Sotto-Componenti (Sub-Sub-Fields).

In particolare HL7 e “order-sensitive”, ovvero i campi dati sono individuati nel mes-

saggio dalla posizione che hanno nel segmento associato. In Figura 2.16 e mostrata

una parte di un messaggio HL7.

L’invio del messaggio segue le seguenti fasi: l’applicazione mittente invia il mes-

saggio principale e riceve un messaggio di riconoscimento, mentre il sistema riceven-

te recepisce il messaggio principale e successivamente invia il messaggio di risposta

(ACK). Il protocollo di riconoscimento dell’HL7 si basa sul fatto che ogni volta

che un’applicazione ricevente accetta un messaggio e ne consuma i dati, invia un

messaggio di riconoscimento all’applicazione mittente. L’applicazione mittente non

aggiorna lo stato del messaggio inviato fino a quando non ha ricevuto un messag-

gio ACK. In altre parole, non e sufficiente sapere che il sistema di comunicazioni

sottostante ha garantito la consegna del messaggio, e anche necessario sapere che

84


Figura 2.17. Conversionde della stringa XML in un messaggio HL7. [22]

l’applicazione ricevente ha trattato i dati con successo (livello logico).

La struttura illustrata e relativa allo standard versione 2.X, il cui compito prin-

cipale e stato appunto la standardizzazione dei messaggi, e che attualmente e ancora

ampiamente utilizzato. Tuttavia, nel tempo ha mostrato diversi limiti e in partico-

lare l’assenza di un supporto esplicito per le nuove tecnologie come Object Techno-

logies, XML e Web Technologies. Per sopperire al problema sono stati sviluppati,

ad esempio, diversi middleware con il compito di mascherare i complessi messaggi

HL7 all’interno di stringhe XML e permettere facilmente l’integrazione verso HL7. Il

sistema Hydra [22], il cui funzionamento e mostrato in Figura 2.17, ne e un esempio.

La complessita dell’HL7 viene mascherata da una mappatura del messaggio in una

corrispondente stringa XML. La stringa XML risultante equivalente al messaggio

HL7 ha sicuramente una struttura molto piu semplice perche scompare la struttura

a segmenti, campi, componenti, e sottocomponenti; i campi sono referenziati da tag

descrittivi.

La versione 3, di cui una prima pubblicazione dello standard e avvenuta nel

2005, cerca di porre rimedio ai limiti della versione 2. Si basa su principi object–

oriented e si pone i seguenti obiettivi: fornire un framework per accoppiare eventi,

85


dati e messaggi, migliorare la chiarezza e la precisione delle specifiche, migliorare

l’adattabilita dello standard ai cambiamenti, andare nella direzione “plug and play”

e sfruttare le tecnologie emergenti come XML.

Se la versione 2.X usa principalmente una codifica testuale basata su delimitatori,

nella versione 3 lo standard per i messaggi definisce una serie di messaggi, chiamati

interazioni, basati sulla sintassi XML. E stato poi introdotto il Reference Information

Model (RIM) che rappresenta un modello OO coerente di tutte le informazioni che

possono essere condivise ed e il punto di partenza per la struttura ed il contenuto

di tutti i messaggi HL7. I modelli sono individuati come collezione di subject,

areas, scenarios, classes, attributes, use cases, actors, trigger events, interactions,

che determinano le informazioni necessarie per specificare i messaggi della versione

HL7. Il RIM cioe esprime il contenuto dei dati richiesti in un determinato contesto

clinico e fornisce una rappresentazione esplicita dei collegamenti semantici e lessicali

che esistono tra le informazioni trasportate nei campi di messaggi HL7. E a partire

dal RIM, infine, che viene generato l’XML Schema associato.

Le applicazioni che seguono le specifiche dell’HL7 e lo adottano come protocollo

di comunicazione standard potranno comunicare liberamente tra di loro senza che

sia necessario avere ulteriori informazioni sul formato dei dati da scambiare. La

compatibilita con lo standard, tuttavia, non implica necessariamente la compatibi-

lita tra i sistemi che lo hanno adottato. Purtroppo nella pratica i fornitori software

non aderiscono strettamente allo standard e un’applicazione progettata per comu-

nicare con l’HL7 non vuol dire che sara capace di comunicare con tutti. Questo

e dovuto alle variazione nel formato dei messaggi; e possibile quindi che una ap-

plicazione possa utilizzare messaggi non costruiti correttamente. In questo caso e

l’applicazione ricevente che deve occuparsi della mancanza di specifici segmenti o di

campi che sono richiesti dallo standard o di segmenti non previsti. In aggiunta a

questo sono attualmente in uso piu versioni dell’HL7 con implementazioni differenti,

con il risultato di complicare ulteriormente il processo di comunicazione. Il risultato

86


e che l’HL7 e stato progettato come protocollo standard in ambito sanitario ma puo

fallire quando le applicazioni non lo implementano nei modi previsti.

2.5.3 ISO / IEEE 11073

Lo standard ISO / IEEE 11073, anche conosciuto come x73, e una famiglia di

standard prodotti da un gruppo di costruttori, istituzioni e l’IEEE in collaborazione

con ISO e CEN. Esso si dedica a differenti livelli del modello ISO / OSI e possiede

modelli di riferimento per l’accesso ai dati, con servizi e protocolli di comunicazione

per l’interoperabilita tra dispositivi medici. In aggiunta il tentativo e quello di

assicurare l’interoperabilita anche con dispositivi che utilizzano altri standard, come

HL7 e POCT-1A.

Gli obiettivi primari dello standard sono:

• Fornire interoperabilita plug-and-play real-time a dispositivi per l’assistenza

sanitaria e per il benessere in generale;

• Facilitare lo scambio efficiente dei dati acquisiti in qualsiasi ambiente di cura.

In particolare “real-time” indica la possibilita di recuperare dati da piu dispositivi,

correlarli e processarli o visualizzarli in una frazione di secondo. “Plug-and-play”

indica, invece, la possibilita che al momento dello startup dell’utente il sistema riveli

automaticamente, configuri e comunichi senza richiedere alcuna interazione umana

diretta. “Scambio efficiente dei dati” significa, infine, che l’informazione catturata

puo essere archiviata, recuperata e processata da diversi tipi di applicazioni senza il

supporto di ulteriori software e soprattutto senza perdita di informazione.

All’interno della famiglia X73 sono consolidati standard precedenti quali il vec-

chio IEEE–1073 Medical Information Bus (MIB) e gli standard CEN (VITAL e

INTERMED). In dettaglio, lo standard 1073 assorbe VITAL per il livello piu alto

(definisce il formato della rappresentazione di parametri vitali), INTERMED per i

livelli intermedi (stabilisce i modelli per l’accesso al dato) e MIB per i livelli piu bassi

87


Figura 2.18. Timeline dello standard ISO /IEEE 11073.

(completa il modello con servizi e protocolli di comunicazione per l’interoperabilita

tra dipositivi medici). L’insieme e stato rinominato 11073-x (per l’ISO) e 1073.x (per

l’IEEE). La corrispondenza tra tra la nomencaltura ISO e IEEE e: ISO11073-xyyzz

/ IEEE 1073.x.y.z, dove x,y,z sono i numeri di ogni sottoparte dello standard. In

Figura 2.18 e mostrata la corripondenza tra i nomi dei documenti dello standard con

i livelli della pila ISO / OSI e le parti che sono state assorbite all’inizio del working

project.

Di seguito verra introdotta la struttura generale dello standard IEEE 11073 e

verra poi trattato piu nel dettaglio l’insieme di standard ISO / IEEE 11073 Personal

Health Data che interessano piu da vicino il mondo delle Body Sensor Network.

Lo standard e diviso nelle seguenti parti principali:

• Parte 1.x.x MDDL (Medical Device Data Language)

Corrisponde alla prima parte dello standard e stabilisce le basi dell’intero

standard definendo la sintassi, la semantica e il Domain Information Model

(DIM).

Il DIM e un modello object-oriented dei dati usato per specificare oggetti,

attributi, gruppi di attributi, servizi di comunicazione, che dovrebbero essere

usati per comunicare i dati dei dispositivi e configurare i dispositivi medici e

le funzionalita. Esso va considerato come un’astrazione dell’entita del mondo

reale nel dominio della comunicazione di parametri vitali.

88


Tabella 2.5. Alcuni degli standard dell’ISO 11073 (stato: P=standard pubblicato,D=draft, N=nuovo progetto)

LivelloOSI

Parte Titolo / Contenuto Stato

00000 Health Informatics - Point-of-care medical device communica-tion - Framework and overview

D

00103 Health Informatics - Personal health device communi-cation - Technical report - Overview

N

71yyzz Data & Information Definitions

10101 Health Informatics - Point-of-care medical device communica-tion - Nomenclature

P

10201 . . . - Domain information model (DIM) P

10300 . . . - Device specialization Framework and overview D

10302 . . . - Vital signs monitor D

10304 . . . - Pulse oximeter D

10306 . . . - ECG monitoring D

10307 . . . - Blood pressure D

10310 . . . - Cardiac output D

10400 Health Informatics - Personal health device communi-cation - Device specialization - Common framework

N

10404 . . . - Pulse oximeter P

10406 . . . - Heart rate monitor D

10407 . . . - Blood pressure monitor P

10408 . . . - Thermometer P

10417 . . . - Glucose meter P

7–52yyzz Application profiles

20101 Health Informatics - Point-of-care medical device communica-tion - Application profiles - Base standard

P

20102 . . . - Mib elements D

20201 . . . - Polling mode profile D

20202 . . . - Baseline profile D

20601 Health Informatics - Personal health device commu-nication - Application profile - Optimized exchangeprotocol

S

4–1 3yyzz Transport and physical profiles

1 4yyzz Physical layer interface

3 5yyzz Internetworking support

4 6yyzz Application gateways

9yyzz Related concepts

89


L’intera parte e formata da Nomenclatura, Dispositivi generici e “Virtual Me-

dic Device Specialization” (VMD) che insieme vanno a formare il MDDL. La

nomenclatura standard (ISO 11073-10101) comprende un set di codici nume-

rici che identificano ogni elemento che e comunicato tra sistemi. La parte

Dispositivi generici corrisponde a una serie di modelli generici di oggetti usa-

ti per differenti applicazioni (es. alarm patterns). I VMD rappresentano le

specializzazioni di diversi dispositivi medici concreti rispetto al DIM generale:

esse forniscono le linee guida su come il DIM dovrebbe essere per uno specifico

tipo di dispositivo, come ad esempio un pulsossimetro, un dispositivo di mo-

nitoraggio dell’ECG etc. In Tabella 2.5 sono mostrate le specializzazioni per

diversi dispositivi (parte 10302, 10304, 10306, 10404, 10406. . . ).

Il DIM proviene direttamente dallo standard CEN VITAL ed e composto in

due parti: modello statico (rappresentato sostanzialmente da un diagramma

delle classi) e modello dinamico. Il modello statico e composto di 6 package

illustrati con le loro relazioni in Figura 2.19. Qui non verranno trattati nel

dettaglio. In particolare le istanze dell’oggetto del DIM che sono disponibili

in uno specifico dispositivo medico costituiscono il Medical Data Information

Base (MDIB) di quel dispositivo.

Il modello dinamico fornisce un modello dei servizi di comunicazione basato

sul paradigma agent-manager. Come mostrato in Figura 2.20, quattro step

sono necessari affinche due dispositivi possano comunicare: Connessione, As-

sociazione, Configurazione, Funzionamento. Si noti lo scambio della MDIB

nella fase di configurazione. Il MIDB caratterizza completamente un disposi-

tivo e, quindi, con questo meccanismo e anche possibile una riconfigurazione

dinamica.

• Parte 2.x.x MDAP (Medical Device Application Profiles)

Fornisce dei “profili applicativi” che danno una serie di restrizioni e vinco-

90


Figura 2.19. Package che compongono il DIM.

91


Figura 2.20. Sequence diagram dell’avvio di comunicazione tra due dispositivi.

li sull’uso di oggetti e servizi definiti dal MDDL adattandoli ai bisogni di

una data classe di comunicazione. I MDAP definiscono la collezioni di ser-

vizi, che saranno usati per comunicare informazioni nella forma di messaggi

MDDL tra dispositivi medici, nei 3 livelli piu alti della pila OSI (applicazione,

presentazione e sessione).

L’intera parte e divisa in 3 sottoparti: Base Standard, Baseline Profile e Pol-

ling mode Profile. La prima definisce la Protocol Data Unit (PDU) con le

definizioni per i diversi servizi, nonche le regole di codifica e le specifiche per il

formato numerico dei dispositivi medici. Il Baseline Profile definisce un gestore

di eventi di sistema con cui il modello dati viene inviato dal dispositivo duran-

te la configurazione del communication link. Tutte le informazioni scambiate

successivamente vengono inviate principalmente come segnalazioni di eventi

quando si verifica un cambiamento nello stato di funzionamento o nuovi dati

sono disponibili. Il Polling Mode profile definisce un insieme di servizi che per-

mettono all’host di interrogare (per fare un “poll” o una esplicita richiesta),

tutti i dati che verranno inviati dal dispositivo; cioe il VMD invia i dati solo

quando l’host li richiede.

• Parte 3.x.x Transport and Physical Profiles

Questa parte specifica i protocolli e i servizi per le connessioni e il trasporto di

92


messaggi utilizzando standard esistenti (TCP/IP, Bluetooth etc.) se possibile.

Attualmente sono disponibili gli standard per la connettivita wired e wireless a

infrarossi (IrDa) ma sono in fase di sviluppo standard per RF WLAN (802.11x)

[11073-30501], WPAN (Bluetooth) [11073-30502] e Zigbee (802.15.4).

• Parte 4.x.x Physical Profiles

Specifica servizi e protocolli richiesti dal livello fisico.

• Parte 5.x.x Internetworking Support

Questa parte include alcuni draft in fase di sviluppo e si riferisce al supporto

di interconnessione tra reti. Un esempio potrebbe essere quello di avere piu

pazienti connessi allo stesso “information system” utilizzando diverse LAN

oppure reti ibride composte da una rete wired e un’altra wireless.

• Parte 6.x.x Application Gateways

Anche questa parte include alcuni draft in fase di sviluppo. Tutti i documenti

che iniziano con il numero IEEE 1073.6 hanno a che fare con l’interoperabilita

con i diversi protocolli a livello applicazione e col tentativo di ottenere traspa-

renza bidirezionale. Un esempio potrebbe essere il caso di un gateway tra HL7

e 11073 (11073.60101).

• Part 9.x.x

Questo documento descrive il collegamento tra x73 e POCT-1A.

ISO / IEEE 11073 Personal Health Data

Gli standard della famiglia x73, ma gli stessi HL7 e Dicom illustrati precedente-

mente, sono stati inizialmente pensati e progettati per applicazioni in ambito ospe-

daliero e con tecnologia wired pertanto si allineano solo in parte con i nuovi requisiti

dei sistemi di telemedicina in generale e in particolare con le applicazioni che uti-

lizzano le BSN. Lo standard, infatti, e attualmente troppo complesso, soprattutto

per i nodi sensore che, alimentati a batteria, richiedono basso consumo energetico

93


Figura 2.21. Standard che compongono la famiglia di standard ISO / IEEE 11073 PHD.

e hanno capacita computazionali basse. Il primo requisito non solo richiede di mi-

nimizzare la potenza di trasmissione ma anche di ridurre i tempi di trasmissione;

questo implica minimizzare l’overhead dei protocolli usati.

In considerazione della crescente attivita nel settore della telemedicina e dei

nuovi requisiti richiesti, e stato istituito il nuovo working group ISO / IEEE 11073

Personal Health Data che basandosi sullo standard IEEE 11073 fino ad ora descritto

si differenzia dai primi lavori per l’attenzione sui dipositivi medici per uso personale,

piuttosto che su dispositivi utilizzati nelle stutture specializzate, e l’introduzione di

un DIM piu snello e di un modello di comunicazione piu semplice. In Tabella 2.5 sono

mostrati in corsivo alcuni degli standard a cui il nuovo gruppo lavora. Essi includono

le specializzazioni di alcuni dispositivi medici personali (pulsossimetro,monitor della

pressione sanguigna, monitor del battito cardiaco. . . ) e un nuovo profilo applicativo

(optimezed exchange protocol) con l’obiettivo di soddisfare i nuovi requisiti esistenti.

Una visualizzazione grafica delle parti a cui lavora l’IEEE 11073 PHD e mostrata in

Figura 2.21. Il gruppo e costantemente al lavoro per l’aggiunta delle specializzazioni

di nuovi dispositivi e per la revisione di passate pubblicazioni.

Gli standard IEEE 11073 PHD sono caratterizzati da una serie di decisioni

architetturali che vengono qui presentate:

• Agente e Manager

Lo standard e basato sul paradigma Agente-Manager. Gli Agenti sono dei

94


“Personal Health Device” (dispositivi per la cura personale) e sono general-

mente piccoli, poco costosi, alimentati a batteria e che offrono poco in ter-

mini di display e altre interfacce utente. I Manager sono tipicamente PC o

smartphone con maggiori risorse.

Lo standard assume che ogni Agente comunica con un solo Manager mentre

un Manager puo comunicare con piu di un Agente.

Facendo un parallelo con le BSN, gli Agenti saranno i nodi sensore mentre il

Manager sara il personal device.

• Transport-Indipendent

La famiglia di standard IEEE 11073 PHD sono “trasporto-agnostici”. Es-

si definiscono i messaggi che viaggiano tra Agenti e Manager ma non come

questi messaggi dovrebbero essere trasmessi, assumendo che un livello di tra-

sporto (Bluetooth, Zigbee. . . ) possa essere stabilito tra Agenti e Manager con

meccanismi che sono al di fuori degli scopi degli standard.

• Object-Oriented

Come gia visto per l’IEEE 11073, l’insieme degli standard e basato sul pa-

radigma object-oriented. Questo approccio assicura flessibilita e permette di

aggiungere facilmente nuove specializzazioni per nuovi dispositivi: tutti gli

Agenti sono istanze di un oggetto “Medical Device System”, che verra illu-

strato successivamente, e contengono un insieme di altri oggetti predefiniti

dall’IEEE 11073-20601 standard framework.

• Auto-descrivente e Estensibile

Un Agente puo sia implementare una o piu configurazioni standard oppure puo

implementare una configurazione personalizzata. Quando un Agente si associa

con un Manager esso dichiara la sua configurazione. Con queste informazioni

generalmente il Manager avra gia informazioni sull’oggetto che modella l’A-

gente – perche gli e stata fornita l’informazione “alla nascita” oppure perche si

95


e associato in precedenza a quell’Agente e ha gia imparato il suo object-model.

Se il Manager non possiede gia “conoscenza” di questa configurazione chiedera

all’Agente di descrivere le sue caratteristiche (ascoltando i suoi oggetti).

L’uso di configurazioni standard e lo scambio di modelli di oggetti quando un

Agente con una nuova configurazione si presenta per la prima volta, riduce

significativamente lo scambio di dati richiesti quando l’Agente si associa con

un Manager.

• Rappresentazione dei dati: ASN.1

Ogni oggetto, e tutti i suoi attributi, sono formalmente definiti usando l’Ab-

stract Syntax Notation One (ASN.1). ASN.1 e una notazione internazional-

mente standardizzata indipendente dall’implementazione, piattaforma e dal

linguaggio (“sintassi locale”), per specificare strutture dati ad alto livello di

astrazione. E supportato da regole che determinano la precisa organizzazione

dei bit, per rappresentare i valori della struttura dati, quando questi devono

essere trasferiti su una rete di computer, usando codifiche non necessariamente

verbose. ASN.1, dunque, fornisce una serie di regole formali per descrivere la

struttura di oggetti in maniera indipendente dalle tecniche di codifica dello

specifico dispositivo.

Gli oggetti in ASN.1 sono convertiti in uno stream di dati binari (“sintassi di

trasferimento”) usando Medical Device Encoding Rules (MDER) che sono un

sottoinsieme delle Basic Encoding Rules (BER)7. L’uso di MDER permette

agli Agenti di memorizzare template predefiniti per la trasmissione (“canned

message”) e modificare soltanto gli “spazi bianchi” prima dell’invio. Questo

evidentemente migliora l’efficienza in comunicazione.

7BER e il nome comune con cui vengono definite le regole di codifica di base, o appunto BasicEncoding Rules, di ASN.1. BER e un insieme di regole per la codifica dei dati ASN.1 in un flusso diottetti che puo essere trasmesso attraverso un collegamento di comunicazione, ovvero mappano lasintassi astratta sulla sintassi di trasferimento. La differenza tra ASN.1 e BER puo essere chiaritacon la seguente similitudine: ASN.1 e come un linguaggio di programmazione, mentre BER e comeun compilatore per quel linguaggio.

96


Si potrebbe pensare di utilizzare anche XML invece di ASN.1; i messag-

gi MDER, tuttavia, sono piu piccoli degli equivalenti messaggi XML e piu

semplici da convertire per le macchine in strutture dati interne.

L’intero system-model della famiglia di standard IEEE 11073 si divide in tre

modelli principali, ognuno dei quali e trattato separatamente in IEEE 11073-20601:

Domain Information Model, Service Model, Communication Model. Vengono a

turno presentati qui di seguito:

1. Domain Information Model

In piena adesione al paradigma object-oriented gli standard x73 rappresentano

un Agente come un insieme di oggetti.

Ogni oggetto ha uno o piu attributi. Gli attributi rappresentano le misurazioni

effettuate o dati di stato dell’Agente, che vanno trasmessi al Manager. Cosı come

gli attributi, gli oggetti possono possedere metodi (come GET e SET) con i qua-

li il Manager puo interagire con l’agente. L’Agente, inoltre, puo generare eventi,

tipicamente per informare il Manager che qualche dato e cambiato.

Il DIM utilizzato da IEEE 11073 PHD e diverso da quello utilizzato da x73 e

mostrato in Figura 2.19. L’IEEE 11073-20601, in particolare, definisce queste classi

(che sono istanziate come oggetti):

• Medical Device System (MDS): ogni Agente ha un oggetto MDS che lo identi-

fica e riferisce il suo stato. Gli attributi dell’oggetto MDS identificano l’Agente

al Manager, rappresentano il tempo e lo stato, e forniscono altre informazioni.

L’MDS poi contiene zero o piu oggetti delle classi presentate ai prossimi punti.

• Metric: e la classe base per tutti gli oggetti che rappresentano le misurazioni,

lo stato e i “context-data”. La classe Metric, tuttavia, non e mai istanziata da

sola ma piuttosto e usata come la classe base per le classe Numeric, Real-Time

Sample Array e la classe Enumeration.

97


Per ogni oggetto ci sono diversi attributi, alcuni obbligatori, altri opzionali.

Questi attributi includono il timestamp, stringhe descrittive, validita e l’unita

di misura.

– Numeric: rappresenta una singola misurazione. Lo standard definisce

due forme di dati in virgola mobile utilizzabili per le misure ottenute –

quella a 32 bit e quella a 16 bit. Un oggetto Numeric puo ritornare i

dati in entrambi i formati e puo farlo sia come solo dato di misura (se il

contesto permette che il tipo di misura possa essere dedotto) sia insieme

all’unita di misura o informazioni di stato. Infine sono possibili sia array

che singoli valori.

– Real-Time Sample Array: rappresenta forme d’onda, che altro non sono

che un insieme di campioni. Un oggetto RTSA contiene informazioni

sull’intervallo tra campioni, il numero di campioni, la risoluzione, la scala

e l’offset applicati a ogni valore dei dati.

– Enumeration: rappresenta informazioni di stato (codici) o annotazioni

(testo). Per esempio, questi oggetti possono essere usati per riportare

informazioni riguardo a cadute, posizione della persona in casa, allarmi

di fumo etc.

• Persistent Metric Store: rappresenta, in maniera gerarchica, grandi quantita

di dati che sono stati acquisiti da un Agente. Ogni oggetto PM-Store contiene

metadati e zero o piu PM-Segment che contengono i dati.

• PM-Segment: ogni oggetto PM-Segment contiene metadati e zero o piu entry:

ogni entry contiene uno o piu elementi che contengono le misurazioni. Questa

organizzazione fornisce grande flessibilita rispetto ai dati che possono essere

memorizzati.

98


Figura 2.22. Class diagram dell’IEEE 11073 PHD Domain Information Model.

• Scanner: gli oggetti Scanner possono osservare l’esecuzione di misurazioni

nell’Agente e generare “eventi” da riportare al Manager. Gli eventi possono

essere dei report regolari, come una misurazione che e stata eseguita, oppure

eventi triggerati da letture che determinano un allarme. Al momento la classe

Scanner, come la classe Metric, non e mai istanziata da sola ma e piuttosto

usata come classe base per la classe Configurable Scanner:

– Configurable Scanner: anch’essa non e mai istanziata da sola. A sua

volta e la classe base per le due classi:

∗ Episodic Configurable Scanner: questi oggetti sono usati per inviare

report di dati o eventi che non sono scanditi da intervalli di tempo

regolari.

∗ Periodic Configurable Scanner: questi oggetti sono usati per invia-

re report di dati o eventi che sono scanditi da intervalli di tempo

regolari.

La Figura 2.22 (basata su una figura dello standard IEEE 11073-20601) mostra

l’IEEE 11073 PHD Domain Information Model attraverso un diagramma UML delle

99


Figura 2.23. Class diagram del DIM di una bilancia pesa persona.

classi. L’oggetto MDS (e gli oggetti che esso contiene) appartengono all’Agente. Il

Manager, tuttavia, puo costruirsi la propria rappresentazione interrogando l’Agente.

Dunque riassumendo, un Agente e rappresentato da un oggetto MDS, che contie-

ne uno o piu oggetti Metric o PM-Store (rappresentanti i dati) e capace di generare

eventi attraverso l’oggetto Scanner.

La Figura 2.23 mostra un esempio pratico. E illustrato il DIM di una bilancia

pesapersona definita dallo standard IEEE 11073-10415. L’esempio mostra che ogni

bilancia ha un oggetto MDS e un oggetto Peso di tipo Numeric. Gli oggetti Altezza

e Indice di Massa Corporea sono ancora di tipo Numeric ma opzionali.

Si ricordi, infine, che ogni oggetto e tutti i suoi attributi sono formalmente definiti

usando ASN.1.

2. Service Model

Il Service Model definisce tutto cio che riguarda il passaggio di messaggi tra

Agente e Manager. Lo standard specifica i messaggi e quando essi si presentano.

I tipi di messaggi sono:

• Messaggi relativi alla creazione e terminazione di un “associazione” tra un

agente e un Manager;

100


• Messaggi che permettono al Manager di accedere alle informazioni nel Do-

main Information Model (DIM) dell’Agente – sia per leggere qualche attributo

dell’Agente, sia per controllare qualche aspetto del suo comportamento;

• Messaggi, che contengono i dati, inviati dall’Agente al Manager. Questi sono

chiamati “Eventi”. I messaggi di evento possono essere provocati dal Ma-

nager o dall’Agente stesso, e sono utilizzati sia per segnalare informazioni di

configurazione, sia per trasferire i valori di misura.

Il Service Model definisce modalita efficienti e flessibili affinche un Agente pos-

sa passare al Manager la propria configurazione. In questo modo il Manager puo

costruirsi una propria immagine degli oggetti che compongono l’Agente.

In particolare, gli Agenti possono “descrivere” se stessi durante la fase di associa-

zione (o “discovery”). Un Agente annuncia che ha una configurazione standard, che

dovrebbe essere gia nota al Manager, oppure una configurazione personalizzata. In

entrambi i casi, il Manager puo chiedere all’Agente di descrivere tutti i suoi oggetti

durante il processo di configurazione in modo da costruirsi una propria mappa degli

oggetti che compongono gli Agenti. Gli Agenti possono essere semplici o comples-

si come richiesto dall’applicazione. Questo meccanismo fornisce un’interoperabilita

plug-and-play.

Il Service Model, infine, fornisce anche modalita efficienti di invio dall’Agente al

Manager di messaggi contenenti i valori di misura.

In Figura 2.24a viene mostrato lo scambio di messaggi tra un Agente (la bilan-

cia di Figura 2.23) e un Manager (uno smarthphone, un PDA. . . ). Se il Manager

non riconosce l’Agente allora quest’ultimo inviera informazioni sulla propria confi-

gurazione contente i dettagli di tutti i suoi oggetti e i loro attributi (in questo caso

Peso, Altezza e Indice di Massa Corporea). Il manager richiede anche i dettagli

dell’oggetto MDS. Tipicamente tutte queste informazioni vengono memorizzate per

rendere la fase di associazione in futuro molto piu snella, riducendo l’overhead e i

tempi necessari per l’operazione. In Figura 2.24b e mostrato il caso in cui il Manager

101


Figura 2.24. Messaggio di rischiesta associazione: (a) Agente non riconosciuto. (b)Agente riconosciuto.

102


riconosce l’Agente. Dopo l’associazione, infine, l’Agente puo inviare i propri dati di

misura.

La classe Scanner e uno strumento potente che permette di raggruppare diversi

oggetti Metric in un singolo payload. Lo Scanner puo essere pensato come un oggetto

che monitora i parametri e invia notifica al Manager come richiesto.

Non tutti gli Agenti hanno oggetti Scanner: la bilancia di Figura 2.23 non ne

possiede.

Un oggetto Pulsossimetro, invece, potrebbe implementare uno scanner di tipo

“Episodic Configurable Scanner” che invia informazioni al Manager ad ogni battito

cardiaco. Oppure potrebbe essere implementato uno scanner di tipo “Periodic Con-

figurable Scanner” che invia dati ogni 5 secondi. In questo contesto i vantaggi della

fase di configurazione, dove vengono negoziate tutte le informazioni, sono i seguenti:

1. Siccome i dati contenuti all’interno del report inviato dallo scanner, come tutti

gli altri oggetti, sono specificati nella fase di configurazione, l’Agente ha piena

flessibilita sulla definizione dei dati che inviera perche qualsiasi configurazione

sara intellegibile al Manager;

2. I report inviati sono progettati per richiedere la minor banda possibile. Le

informazioni “statiche” nei messaggi di evento, infatti, sono state anch’essi

definiti nella configurazione; in questo modo ogni report deve solo passare al

manager i valori dei dati. Cioe, viene effettivamente trasmessa solo l’informa-

zione “dinamica”. Il termine statico si riferisce quin alle informazioni che non

cambiano tra misurazioni e misurazioni e che sono sfruttate per il parsing. Ad

esempio se Agente e Manager si sono accordati sull’unita di misura utilizzata

attraverso un attributo “Unit-value” scambiato in fase di configurazione allora

l’Agente sara abilitato ad inviare solo uno stream di byte che contengono i

valori di misure e il Manager sapra come interpretarli. Questo meccanismo

riduce l’overhead dei messaggi significativamente, permettendo tempi di in-

103


Figura 2.25. (a) Operazioni di un oggetto Scanner. (b) Operazioni per l’accesso alPM-Store.

104


vio piu brevi e riduzione del consumo di potenza in trasmissione; vantaggi di

notevole importanza nei dispositivi che compongono le BSN.

Infine, un Agente puo specificare se richiede o meno un messaggio di ACK e un

Manager puo abilitare e disabilitare dinamicamente uno Scanner, avendo in questo

modo il controllo completo su quali messaggi di evento gli debbano o meno essere

inviati. In Figura 2.25a sono mostrate le operazioni di un oggetto Scanner. Il mana-

ger usa il comando SET per avviare lo Scanner (e successivamente per disattivarlo).

Ad ogni ciclo l’Agente invia messagi di evento contenenti i valori delle misurazioni.

In base a quanto negoziato nella configurazione, puo seguire o meno un messaggio

di ACK.

In Figura 2.25 e mostrato, invece, le operazioni dell’oggetto Persistent Metric

Store che implementa un semplice file system. L’oggetto Bilancia in Figura 2.23

non ne possiede uno; anche gli oggetti PM-Store, dunque, non sono sempre presenti.

Riutilizzando l’esempio del pulsossimetro, uno o piu oggetti PM-Store possono

essere utilizzati per memorizzare il livello di SpO2, il timestamp e la frequenza di

polso. Il dato attuale e contenuto in uno o piu oggetti PM-Store e in questo caso

ogni oggetto PM-Segment contiene i dati di una sessione di monitoraggio continuo.

Gli oggetti PM-Store sono abbastanza semplici in modo da consentire la me-

morizzazione in maniera molto efficiente e abbastanza flessibili per memorizzare

praticamente qualsiasi tipo di dati che il dispositivo e in grado di misurare. Ancora

una volta come per tutti gli oggetti IEEE 11073, l’Agente riporta le informazioni sul

PM-Store e PM-Segment durante la fase di configurazione, in modo che il Manager

non debba conoscere in anticipo il formato di dati.

Lo scambio di messaggi segue queste fasi: l’Agente riempe un oggetto PM-

Segment con i dati rilevati; il Manager interroga l’Agente per recuperare i dati

memorizzati e per ogni oggetto PM-Segment di interesse istruisce l’Agente ad avvia-

re la trasmissione. L’Agente puo dividere il PM-Segment in “chunk” di dimensioni

105


Figura 2.26. Sistema generico di telemedicina che integra sistemi eterogenei.

gestibili e li invia in successione come messaggi di evento. Infine quando il Manager

ha recuperato i dati dall’Agente, puo cancellare i PM-Segment per il riuso.

3. Communication Model

Il Communication Model, come gia anticipato, supporta una topologia in cui uno

o piu Agenti comunicano su una connessione punto-punto a un singolo Manager.

Inoltre l’IEEE 11073 e “transport-indipendent”.

Per ogni connessione punto-punto, il comportamento dinamico del sistema e de-

scritto con uno statechart diagram. Vengono definiti gli stati e sottostati che una

coppia Agente e Manager attraversa, inclusi gli stati relativi alla connessione, asso-

ciazione e funzionamento. Il modello, inoltre, definisce nel dettaglio anche l’entry,

le condizioni di uscita e di errore per ogni stato e le procedure operative per la

trasmissione dei dati di misura.

Infine l’altra funzione del Communication Model e convertire i dati modellati

nel DIM con ASN.1 in una “sintassi di trasferimento” che, come gia visto, avviene

attraverso le MDER.

ISO / IEEE 11073 come middleware

Il paradigma Agente–Manager sul quale si fonda l’intera famiglia di standard x73

offre una soluzione semplice al problema dell’interoperabilita. In conformita con gli

standard 11073, l’interoperabilita a livello locale tra dispositivi differenti per il mo-

nitoraggio che vanno a comporre una BAN, ma anche una PAN o una Home Area

106


Network (HAN), puo essere risolto connettendo tutti i device con un “compute en-

gine” (CE) centrale che agisce come connessione principale con la rete extra-body.

Il CE controlla l’interazione tra diversi dispositivi che formano una BAN, preleva

i dati raccolti e controlla i dispositivi in maniera da consentire il monitoraggio del

paziente. In Figura 2.26 e mostrato un esempio che utilizza questa soluzione. Tra

le connessioni presenti certamente la rete BAN, formata da numerosi dispositivi

eterogenei, necessita di una standardizzazione che renda omogenea l’interfaccia tra

dispositivi e CE. Inoltre l’altra sfida e poter creare sistemi di telemedicina complessi

che fanno capo a server di telemonitoraggio che utilizzano informazioni provenienti

da piu reti BAN, che contengono esse stesse dispositivi e CE di diversi costruttori, e

siano a loro volta connessi a sistemi EHR. In questo scenario l’impiego di tecnologie

di middleware che utilizzino IEEE 11073 fornisce portabilita (differenti sistemi di

telemonitoraggio possono essere connessi a diversi sistemi di telemedicina) e inte-

roperabilita (applicazioni mediche in differenti ambienti clinici possono scambiare

informazioni tra dispositivi connessi al paziente).

107

Analisi di un caso di studio: Il

morbo di Parkinson

La malattia di Parkinson e una malattia degenerativa del sistema nervoso centra-

le, il cui sintomo principale e costituito da un’alterazione del movimento volontario

e automatico che diventa piu lento e difficile; spesso si instaura il caratteristico tre-

more. La persona con Parkinson presenta numerose cause di sofferenza. Oltre la

ridotta mobilita e le cadute, anche, disturbi del sonno, perdita delle abilita, disturbi

dell’affettivita e delle emozioni, difficolta relazionali in ambito familiare e sociale

fino all’isolamento, con una consapevolezza quasi sempre lucida dei cambiamenti.

La malattia costa ogni anno 2 miliardi e 345 milioni di euro allo Stato. Solo la spesa

giornaliera per i farmaci e di un milione di euro.

L’eta media d’insorgenza della malattia di Parkinson e di 62,6 anni, ma nel 10%

dei casi si manifesta prima dei 50. Nel 2009 in Italia si sono registrati circa 200

mila casi e il numero delle persone con Parkinson e destinato a raddoppiare nei

paesi piu popolati nei prossimi 25 anni. Le proiezioni mostrano che nei 15 paesi piu

popolati del mondo, che rappresentano i 2/3 della popolazione mondiale, le persone

affette da malattia di Parkinson sono 4,1–4,6 milioni. Questo numero e destinato a

raggiungere 8,7–9,3 milioni nel 2030.

La valutazione quantitativa del controllo motorio e dei disordini del movimento

e un argomento di grande interesse. Fin dagli anni 60 e stato possibile dotare i

laboratori di strumenti sofisticati in grado di misurare la performance motoria in

108


Tabella 2.6. Comuni disordini del movimento nel morbo di Parkinson.

Bradicinesia Velocita e ampiezza ridotta dei movimenti, difficolta ad iniziare un movi-mento. Nei casi estremi e conosciuta come “ipocinesia”, a sottolineare lariduzione significativa di movimenti spontanei del corpo.

Acinesia Carenza o scomparsa dei movimenti volontari accompagnata dalla totalemancanza di espressioni sul viso.

Episodi di freezing Blocchi motori improvvisi durante l’esecuzione di una sequenza dimovimenti.

Bilanciamentoe controllo dellapostura ridotto

Difficolta a mantenere la posizione eretta in seguito a un movimento delcentro di massa o con gli occhi chiusi; difficolta a mantenere anche lastabilita in posizione seduta o durante il movimento da una posizioneall’altra.

Discinesia Movimento anormale e involontario dei muscoli del corpo.

Tremore Tipicamente tremore a riposo; piu raramente tremore posturale od’azione.

Rigidita Ipertonicita e iperreflessia nei muscoli agonisti e antagonisti in alcuni arti.

maniera accurata e dettagliata. Tuttavia, la sola disponibilita di strumenti avanzati

non e garanzia di successo nell’analisi dei disturbi del movimento in quanto questi si

possono presentare solo in situazioni specifiche, difficili da riprodurre in laboratorio.

Le tecniche di monitoraggio tradizionali hanno limiti di non poco conto: devono

essere effettuate in laboratori specializzati, risultano dispendiose sia in termini di

tempo che di denaro, dal punto di vista psicologico il paziente risulta essere con-

dizionato, in quanto se esso si sente osservato o sotto esame tende a rispondere

diversamente da quanto farebbe in un ambiente a lui congeniale, dal punto di vista

fisico alcune tecniche richiedono molti cavi e elettrodi che condizionano il movimen-

to del paziente, il periodo di osservazione non puo essere troppo lungo, in quanto

non si possono sottoporre i pazienti (tipicamente anziani o con gravi problemi di

deambulazione) a sforzi prolungati e non si possono monitorare i pazienti durante il

sonno.

In tal senso i nuovi vantaggi introdotti dalle BSN possono dare notevoli benefici

alla ricerca. Il morbo di Parkinson, nel caso specifico, e caratterizzato da una varieta

di disturbi motori come il tremore, l’acinesia e la bradicinesia, a cui si possono

aggiungere le discinesie indotte dalla terapia prolungata con levodopa. In Tabella 2.6

sono riassunti i principali “disordini del movimento” che si manifestano in persone

109


affette dal morbo di Parkinson.

La levodopa8 (o L-DOPA) e attualmente il farmaco piu efficace nella terapia

del Parkinson, ma l’utilizzo prolungato porta numerosi effetti collaterali, fra cui

discinesia e acinesia, quest’ultima in modo particolare al risveglio. D’altra parte non

esiste in questo momento un farmaco che possa fermare i progressi della malattia;

la levodopa puo solo limitarne i sintomi.

Allo stato attuale l’unico metodo per misurare le acinesie, consiste nel far com-

pilare al paziente un diario giornaliero in cui annotare ogni disfunzione motoria.

Molto spesso pero il diario risulta essere incompleto o compilato in maniera molto

approssimativa: questo perche i malati di Parkinson sono spesso anziani, a volte con

disfunzioni cerebrali dovute ad altre patologie, senza contare la frustrazione che crea

la rigidita dovuta all’acinesia, a causa della quale la compilazione del diario diventa,

agli occhi del paziente, un inutile ulteriore supplizio.

Alla luce di tutto questo, risulta chiaro che sarebbe estremamente proficua la

possibilita di misurare in maniera quantitativa lo stato motorio di tali pazienti nel

corso della giornata, anche in relazione allo schema di assunzione della levodopa.

Inoltre, data la necessita di valutare nuove terapie farmacologiche e chirurgiche

emerse recentemente, la disponibilita di un metodo di misurazione quantitativo di-

venta sempre piu importante. La tecnica quantitativa piu accurata nella misura del

movimento umano e oggi rappresentata dai sistemi di analisi ottica, che possiedono

una risoluzione superiore a 0,2 mm in un range di 2m3, ma che sono estremamente

costosi e, analogamente alle scale, permettono lo studio del paziente esclusivamente

in laboratorio.

Lo studio e la detection dei disordini del movimento mostrati in Tabella 2.6

puo essere condotto attraverso l’utilizzo di accelerometri e giroscopi (questi ultimi

soprattutto per la “posture recognition”). Al riguardo numerosi sono i lavori gia

8Levodopa: precursore della dopamina che, a differenza di quest’ultima, supera agevolmente labarriera ematoencefalica e per questo utilizzato per correggere il deficit di dopamina del morbo diParkinson.

110


pubblicati. Gli accelerometri rappresentano quindi una nuova frontiera, in via di

evoluzione, nel follow up del morbo di Parkinson, e consentono di integrare utilmente

le scale cliniche, essendo in grado di misurare correttamente sia il tremore sia le

discinesie (classificazione corretta nel 95% dei casi).

E pero importante fare alcune puntualizzazioni. Un metodo di valutazione quan-

titativa applicato ai sintomi del morbo di Parkinson, deve essere in grado di distin-

guere fra numerosi stati motori; in particolare e necessario che possa differenziare

i movimenti volontari dalle discinesie durante la fase on, e l’acinesia dall’immobi-

lita volontaria durante la fase off. Questo pone l’esigenza di individuare specifici

parametri e tecniche di classificazione che procurino ai medici un’oggettiva caratte-

rizzazione di questi sintomi e che abbiano la capacita di riconoscere i diversi disturbi

motori e di distinguerli dai movimenti normali.

2.6 Il tremore nel morbo di Parkinson

I primi effetti collaterali della levodopa emergono in molti pazienti dopo 3-7 anni

di terapia. Si presenta un fenomeno (vacanza DOPA) per il quale i pazienti inco-

minciano a fluttuare fra uno stato “off” (alcune ore dopo l’assunzione del farmaco in

cui riemergono i sintomi tipici della malattia) ed uno stato “on” (in cui il farmaco e

attivo ed i sintomi si attenuano). E proprio durante quest’ultimo stato che si posso-

no manifestare le discinesie, la cui comparsa sembrerebbe dipendere principalmente

dalla distribuzione delle dosi di farmaco nel tempo e dalla loro entita. E possibile,

dunque, individuare tre fasi distinte che caratterizzano l’evoluzione della malattia:

1. Stato OFF : comparsa dei sintomi classici (tremore, movimenti lenti) quando

l’effetto dei medicinali finisce;

2. Stato ON : movimenti normali liberi da tremore quando la terapia e bilanciata;

3. Manifestazione delle discinesie quando la concentrazione del farmaco diventa

elevata.

111


Tabella 2.7. Tipi di tremore e intervalli di frequenze associati.

Tipi di tremore Frequenza (Hz) Note

Normale tremore della mano 9–25 Piccola ampiezza

Tremore essenziale 4–12 Tremore posturale e di azione

Morbo di Parkinson 3–8 Tremore a riposo

Lesioni cerebrali 1,5–4 Bassa frequenza (<4 Hz e unilaterale)

Il tremore negli arti, il primo sintomo evidente del morbo di Parkinson, cambia

tra le diverse fasi. L’estrazione di parametri che lo caratterizzano offre un contributo

fondamentale alla classificazione dei 3 periodi e all’obiettivo finale di osservare gli

effetti della cura sul paziente.

Il tremore e tipicamente tremore a riposo9 alle frequenze tra 4 e 6 Hz e con

ampiezza media. E caratterizzato dal cosiddetto “movimento del confezionatore

di pillole”. Tale tremore e massimo a riposo, diminuisce durante il movimento e

scompare col sonno; aumenta inoltre con le emozioni e la fatica. Generalmente, sono

maggiormente colpite le mani, le braccia e le gambe, secondo tale ordine. Possono

anche essere interessate la mandibola, la lingua, la fronte e le palpebre, mentre la

voce non viene coinvolta.

Meno comunemente e osservabile il tremore di azione, a frequenze tra i 6 e gli

8 Hz, che puo essere osservato durante l’esecuzione dei movimenti oppure tremore

posturale, osservabile quando la persona sostiene un peso con un arto o incontra

resistenza al movimento degli arti, il tronco, la testa o il collo.

Cio che fa variare di piu l’ampiezza del tremore sono le condizioni d’appoggio

e in particolare, nel caso di tremore della mano, il punto d’appoggio della mano

stessa. Il tremore non si manifesta in un’unica direzione ma contiene componenti

nelle tre direzioni, con una direzione provilegiata, e non e sinusoidale: la frequenza

fondamentale F0 e accompagnata da componenti armoniche, principalmente 2F0 e

3F0. La mano che trema passa bruscamente da una posizione estrema all’altra come

se fosse limitata da ostacoli.

9si presenta a un’estremita poggiata su una superficie

112


Diverse sono le tecniche finora utilizzate per l’analisi del tremore. Si e gia ac-

cennato a sistemi di analisi ottica. In [42] lo studio del tremore e condotto at-

traverso l’analisi della scrittura tramite penna su tablet PC. Altri studi utilizzano

l’elettromiografia tramite sensori EMG.

Gli accelerometri hanno il notevole vantaggio di permettere il monitoraggio “eve-

rywhere” e 24 ore su 24. Permettono, inoltre, la detection di altri disordini del

movimento che caratterizzano la malattia (Tabella 2.6), oltre a fornire altre fun-

zionalita come ad esempio il rilevamento di cadute, a cui gli affetti da Parkinson

possono incorrere con maggiori probabilita. Infine e importante associare l’analisi

del tremore alla “posture recognition” siccome la posizione del corpo puo influen-

zare l’entita del tremore e le discinesie. L’utilizzo di accelerometri, il cui utilizzo

nel riconoscimento della postura e delle attivita svolte e fondamentale (insieme ai

giroscopi), rappresenta in tal senso il vero valore aggiunto nello studio del tremore.

L’ampiezza piu grande dell’accelerazione di una mano durante un movimento e

±5g. Accelerazioni superiori (nell’intervallo di ±20g) possono manifestarsi solo in

situazioni eccezionali, quali ad esempio l’atterraggio dopo un salto dovuto alle vibra-

zione nei tessuti. Di conseguenza un dispositivo robusto deve utilizzare accelerometri

che possono resistere a simili accelerazioni.

Qui di seguito e illustrata l’implementazione di un’applicazione in grado di rac-

cogliere dati accelerometrici da un nodo sensore posto sul dorso della mano, e fissato

con una fascia. I dati sono poi utilizzati off-line per l’analisi in frequenza del tremore

a differenti velocita. Questa applicazione, tuttavia, non puo essere utilizzata, con

l’hardware impiegato, per lo studio del tremore nel morbo di Parkinson. Il vero

problema e rappresentato dal peso notevole del sensore che puo influenzare sensibil-

mente il tremore di una persona affetta dal Parkinson. D’altronde il nodo utilizzato

non e stato pensato per questo tipo di impieghi. Tuttavia, l’applicazione e certa-

mente un ottimo esempio per mostrare la possibilita di poter condurre con disposi-

tivi estremamenti economici, rispetto alla strumentazione correntemente utilizzata

113


Figura 2.27. (Sinistra) Sensor board MTS420. (Destra) Iris Mote.

in ambiente ospedaliero, analisi quantitative significative nella caratterizzazione di

alcune malattie croniche estremamente diffuse.

2.7 Hardware e Software Design

Per poter acquisire i dati accelerometrici, effettuare il debug del codice creato,

compilarlo, installarlo sui sensori e quindi testarlo per poi effettuare le sperimenta-

zioni occorrono degli strumenti hardware e software. L’hardware consiste nei sensori

Iris Mote, in una programming board necessaria per poter flashare il codice sui sen-

sori, una sensor board con accelerometro biassale per poter misurare le accelerazioni

e in una base station che rileva i messaggi contenenti le letture inviati dal mote; il

software occorre per interfacciare l’hardware con il PC, per compilare il codice ed

installarlo sui sensori, per leggere i dati rilevati dalla base station.

E stato quindi utilizzato il pacchetto WSN PROFESSIONAL KIT della Cros-

sbow costituito da 7 mote, 6 sensor board, una programming board, una base station,

una data acquisition board ed un cd contenente driver, manuali e dei software di

monitoraggio.

TinyOS e compilatore nesC

Naturalmente per la creazione del codice, per il debugging e la compilazione

e necessario che sulla macchina di sviluppo utilizzata siano installati TinyOS ed

un compilatore nesC. Il sistema operativo TinyOS2.1, cosı come le sue versioni

114


Tabella 2.8. Riassunto delle specifiche dell’ADXL202JE.

Tipo di Sensore Dispositivo Analogico ADXL202JE

Canali X (ADC1), Y (ADC2)

Range ±2 G (1 G = 9,81 m/s2)

Sensibilita 167 mV/G, ±17%

Risoluzione 2 mG (0,002 G) RMS

Offset VBATTERY/2 ±0,4 V

Range operativo 3,6 a 3,0 V

Interfaccia Interfaccia Analogica

precedenti, sono forniti solo per sistemi Linux, per cui in Windows e necessario

l’utilizzo di Cygwin, il quale consente, appunto, il porting di software per sistemi

POSIX su sistemi Microsoft.

In particolare e stata utilizzata la versione 1.1 di TinyOS siccome la Crossbow

ancora non fornisce i driver compatibili con TinyOS2.1 per l’accelerometro sulla

sensor board utilizzata.

Iris Mote

Si tratta di sensori della Crossbow basati su protocollo ZigBee e modulo radio a

2.4 GHz. E caratterizzato da un ampio raggio d’azione del modulo radio, fino a tre

volte quello dei precedenti Mica, e memoria doppia rispetto a questi. Sono dotati

di un processore XM2110CA basato sull’Atmel ATmega1281. E bene osservare che

quello che normalmente viene indicato come sensore e costituito in realta dal modulo

radio e dal processore, al piu con l’aggiunta del modulo per batterie, e prende il nome

di mote board. I veri sensori invece sono su un’ulteriore scheda che prende il nome di

sensor board. In Figura 2.27-destra e mostrato l’Iris e cerchiato in rosso il connettore

al quale collegare la sensor board. In Appendice e possibile leggere il datasheet del

mote.

Sensor board – Accelerometro ADXL202JE

Nel developement kit le mote board sono accompagnate da sensor board MTS400,

le quali sono dotate di accelerometro biassiale, sensore di pressione, sensore luminoso,

115


Figura 2.28. Programming Board MIB520.

sensori di umidita e temperatura, e sono equipaggiabili con modulo GPS; in tal caso

sono indicate come MTS420 (Figura 2.27-sinistra). In Appendice e riportato il

datasheet.

In particolare l’accelerometro e l’ADXL202JE: un accelerometro MEMS biassale,

caratterizzato da un assorbimento di corrente molto basso (<1 mA). Puo essere

utilizzato per il rilevamento di tilt, movimenti, vibrazione e/o misurazioni sismiche.

Le uscite dell’accelerometro sono connesse ai canali dell’ADC (ADC1 e ADC2) sul

mote. Un riassunto delle specifiche dell’ADXL202JE e presentato in Tabella 2.8.

L’accelerometro resiste anche ad accelerazioni improvvise di 1000g e quindi e adatto

a sopportare anche accelerazioni che vadano molto oltre il suo range operativo.

Infine, come scritto sul datasheet dell’accelerometro, la sensibilita e l’offset han-

no un’ampia tolleranza iniziale e una semplice calibrazione puo essere fatta utiliz-

zando come riferimento l’accelerazione di gravita. Nel seguito verra illustrata la

calibrazione fatta con questo metodo.

Programming board

Come detto, si tratta di un dispositivo utilizzato per flashare la ROM dei vari

sensori con il codice necessario all’esecuzione delle istruzioni. Nello specifico, si

utilizza la MIB520 della Crossbow. In Figura 2.28 sono evidenziati i connettori per

il collegamento del mote e la porta USB per il collegamento ad un computer. In fase

di installazione del dispositivo su una macchina la connessione attraverso USB viene

116


Figura 2.29. Base Station.

mappata come su una seriale, per cui viene assegnato un numero di porta COM X.

Utilizzando Cygwin, TinyOS ed il compilatore nesC, il codice implementato viene

compilato e quindi installato sul sensore attraverso il comando da riga di codice:

make <platform> install,<mote_id> <programming_board>,<com>

dove <platform> indica la piattaforma utilizzata e quindi nel nostro caso iris,

<mote id> e, invece, l’identificativo che si vuole assegnare al sensore, si tratta

di un intero da 0 a 65535, avendo visto che nella forma breve gli indirizzi della

specifica 802.15.4 sono a 16 bit, <programming board> e mib520, <com> indica

l’identificativo della seriale su cui e mappata la connessione USB dal sistema opera-

tivo. Supponendo dunque che la programming board e sulla porta COM5 e di voler

assegnare al mote l’id 30, si ha:

make iris install,30 mib520,com5

Base Station

In tale contesto la base station (Figura 2.29) consiste in un dispositivo che riceve

i dati sensibili rilevati dai componenti della rete e li invia ad una macchina cui e

collegato attraverso una porta seriale. Si tratta di un dispositivo costituito da una

programming board con una mote board collegata sulla quale e installato del codice

117


per la rilevazione dei dati. Il codice puo differire a seconda di quali dati prendere e

come prenderli. Nel nostro caso e stato utilizzato come strumento software XSniffer

della Crossbow il quale fornisce anche il codice da flashare sul mote della base station;

in tal modo saranno sniffati tutti i messaggi nel raggio d’azione dell’antenna della

base station, la quale li inviera alla seriale del PC cui e collegata, dove un software

ne consentira la visualizzazione a schermo.

XSniffer

Si tratta di un software realizzato dalla Crossbow e fornito con il Professional

Kit. Si compone di codice per mote e software per PC. Il mote rileva tutti i messaggi

scambiati in una rete di sensori su un determinato canale e li invia alla porta seriale.

Il software per PC rileva tutti i dati che giungono alla porta seriale specificata e li

mostra a video attraverso un’interfaccia user-friendly. Si tratta di un utile strumento

in quanto agevola notevolmente la fase di testing e la fase sperimentale, consentendo

di controllare le operazioni svolte dai sensori. Infatti, programmando questi per

l’invio di messaggi con dati rappresentativi del loro stato, consente di verificare la

correttezza delle operazioni che il mote sta eseguendo.

In particolare XSniffer e stato utilizzato per salvare in file .csv i dati contenuti

nel payload dei pacchetti “sniffati”.

Matlab

Per l’analisi dei dati raccolti e stato utilizzato MATLAB, un ambiente per il calcolo

numerico e l’analisi statistica che comprende anche l’omonimo linguaggio di pro-

grammazione creato dalla MathWorks. MATLAB consente di manipolare matrici,

visualizzare funzioni e dati, implementare algoritmi, creare interfacce utente e in-

terfacciarsi con altri programmi. In particolare e stato utilizzato per la lettura dei

file .csv contenenti le letture inviate dal mote, la trasformazione in unita di misure

ingegneristiche, visualizzazione e analisi dei grafici delle accelerazioni nel tempo e in

frequenza.

118


Figura 2.30. Strumenti hardware e software utilizzati.

In Figura 2.30 sono mostrati gli strumenti hardware e software utilizzati per

l’applicazione.

2.8 Acquisizione delle accelerazioni

Allo scopo di ottenere i dati accelerometrici da poter analizzare e stato scritto il

codice TinyOS per campionare a una certa frequenza le accelerazioni e trasmetterle

via wireless all’interno di un messaggio che contiene anche informazioni di debug,

e stato utilizzato XSniffer per raccogliere e memorizzare i dati inviati dal mote e,

infine, e stato necessario calibrare l’accelerometro e convertire i dati in multipli

dell’accelerazione di gravita (mg). Tutto cio verra analizzato in questa sezione.

2.8.1 Implementazione in TinyOS

Il codice nesC, da compilare e installare sul mote Iris, e organizzato in 4 file: la

configurazione ReadingAccelM.nc, il modulo ReadingAccelM.nc, un file Message.h

e il Makefile per la compilazione.

Message.h

All’interno di Message.h vengono definiti:

• SENSOR BOARD ID: Id della sensor board inserito come informazione di debug

nel messaggio inviato;

119


• TIMER PERIOD: periodo di campionamento in millisecondi. E pari a 16 ms in

modo da avere una frequenza di circa 64Hz che, in base a quanto scritto sul

datasheet dell’accelerometro, permette di ottenere una risoluzione di 2 mg.

• BUFFER SIZE: Numeri di messaggi da bufferizzare prima di inviare il messaggio.

Se il valore posto e pari a 1 allora non sara prevista alcuna bufferizzazione e

ogni messaggio appena pronto verra inviato. La bufferizzazione, riducendo il

numero di pacchetti inviati, riduce sensibilmente il consumo delle batterie;

• AM DATAMSG: Id dell’handler per l’Active Message (verra spiegato successiva-

mente);

• Struttura del payload da inserire all’interno del campo data del TOS Msg, che

rappresenta il messaggio effettivamente inviato dalla radio e la cui struttura

e definita nel file AM.h (definito in /opt/tinyos-1.x/tos/types all’interno

del path di installazione di TinyOS1.1):

typedef struct DataMsg {

uint8_t board_id; //id sensor board

uint8_t node_id; //indirizzo del mote

uint16_t accel_X[BUFFER_SIZE]; //array accelerazioni asse X

uint16_t accel_Y[BUFFER_SIZE]; //array accelerazioni asse Y

}__attribute__ ((packed)) DataMsg;

Configurazione: ReadingAccel.nc

Nella configurazione viene effettuato il wiring delle interfacce. In particolare il

collegamento seguente:

ReadingAccelM.Receive -> Comm.ReceiveMsg[AM_DATAMSG];

ReadingAccelM.Send -> Comm.SendMsg[AM_DATAMSG];

120


mostra l’utilizzo di interfacce parametrizzate. Le interfacce Send e Receive sono col-

legate rispettivamente alle interfacce ReceiveMsg fornite da GenericComm (Comm

e l’alias definito per GenericComm). In generale una freccia verso destra collega

un’interfaccia sulla sinistra a una implementazione sulla destra, ovvero il compo-

nente che usa un’interfaccia e sulla sinistra e il componente che fornisce l’interfaccia

e sulla destra. Il parametro AM DATAMSG definito in Message.h e un’intero sen-

za segno a 8 bit: GenericComm fornisce 28 = 256 differenti istanze di SendMsg

e ReceiveMsg, e AM DATAMSG ne identifica univocamente un’istanza all’interno

di tutto il codice. Questo e il modo in cui gli handler degli Active Message sono

collegati insieme ed e il meccanismo con cui e possibile gestire piu tipi di messagi in

un’applicazione.

I seguenti, invece, sono i collegamenti tra le interfacce utilizzate da ReadingAccel

a quelle fornite da Accel, che rappresenta il componente che permette di utilizzare

l’accelerometro:

ReadingAccelM.AccelControl -> Accel.StdControl;

ReadingAccelM.AccelCmd -> Accel.AccelCmd;

ReadingAccelM.AccelX -> Accel.AccelX;

ReadingAccelM.AccelY -> Accel.AccelY;

Gli altri collegamenti non vengono qui dettagliati ma in Figura 2.31 e possibile

vedere i collegamenti tra i diversi componenti. La figura e stata generata con il

comando:

make iris docs

Modulo: ReadingAccelM.nc

Il modulo rappresenta in un certo senso l’implementazione vera e propria: ven-

gono specificate le interfacce utilizzate e fornite e vengono implementati gli eventi

121


Figura 2.31. (Sopra) Collegamenti tra i componenti del programma ReadingAccel.(Sotto) Sequenza di eventi che caratterizzano il programma.

122


Tabella 2.9. Stato dei LED del mote.

LED Significato

GREEN On Inizializzazione

RED Toggle Colpo di clock

YELLOW Toggle Invio eseguito

GREEN Toggle Invio fallito

delle prime e i comandi delle seconde. In Figura 2.31 e mostrato il flusso di even-

ti dell’applicazione. Dopo l’inizializzazione quando il componente e avviato viene

acceso l’acceloremetro (che stando alle informazioni del datasheet impiega 16 ms)

tramite la funzione PowerSwitch(1). L’operazione di accensione e di tipo split-

phase. Questo significa che la chiamata del comando ritornera immediatamente, ma

un evento, in particolare l’Evento1, effettuera una callback successiva a segnalare

che l’operazione e stata completata. Una volta che il sensore e stato acesso si pos-

sono avviare le letture delle accelerazioni. Bisogna dunque avviare il clock software

che temporizza gli istanti di campionamento. Ad ogni colpo di clock verra genera-

to un Evento2. L’implementazione dell’Evento2 prevedera la chiamata a funzione

che avviera il campionamento dell’accelerazione sull’asse X. Anche questa operazio-

ne e di tipo split-phase. Analogamente a prima, l’implementazione dell’Evento3,

che segnala la disponibilita del dato, prevedera il salvataggio del dato campionato

all’interno dell’array contenente le accelerazioni per l’asse X e la chiamata a funzio-

ne che avviera il campionamento dell’accelerazione sull’asse Y. L’implementazione

dell’Evento4, oltre a salvare ovviamente l’accelerazione campionata, contiene una

chiamata a un task send msg() se il numero di letture bufferizzate e effettivamente

uguale a quello desiderato; questo task si incarichera di inviare in broadcast (ma e

possibile anche inserire direttamente l’indirizzo della base station, che tipicamente

vale 0) il messaggio con i dati campionati.

Nell’implementazione e stato previsto anche un lampeggiamento opportuno dei

LED presenti a bordo del mote Iris da utilizzare come informazione di debug. In

Tabella 2.9 e mostrato lo stato dei LED e i relativi significati da attribuire.

123


Figura 2.32. XSniffer: Sniffing dei messaggi. (Rettangolo rosso) Dati rappresentanti leaccelerazioni; (Rettangolo verde) Interfaccia per selezionare la porta seriale.

2.8.2 Raccolta e memorizzazione dei messaggi

Come gia anticipato, per la raccolta e memorizzazione dei dati accelerometrici

inviati dal mote alla base station e stato utilizzato XSniffer.

Il primo passo e selezionare la porta seriale (Figura 2.32–rettangolo verde), sulla

quale e stata mappata la base station, corrispondente alla lettura dei pacchetti in

arrivo. Sia la programming board che la base station sono mappate ognuna su due

porte seriali del tipo COM x e COM x+1. La porta col numero piu basso va uti-

lizzata per il flash della ROM sul mote, l’altra per la raccolta dei dati. Una volta

selezionata la porta premendo START si avvia lo sniffing dei pacchetti che vengo-

no mostrati a video in tempo reale. In Figura 2.32 e mostrata una schermata di

XSniffer e all’interno del rettangolo rosso sono mostrati i dati rappresentanti le ac-

124


celerazioni. Nella sezione successiva verra spiegato come interpretare correttamente

i dati visualizzati da XSniffer.

E chiaro, tuttavia, che una visualizzazione dei dati in questo modo non risulta

utile per le analisi che si vogliono eseguire. Cio che effettivamente e stata utilizzato

in questo lavoro e la possibilita che XSniffer offre di salvare i dati all’interno di un

file .csv (foglio di calcolo). Tutte le letture effettuate sono state salvate all’interno

di file che verranno poi lavorati da Matlab.

Si e scelta questa soluzione data la semplicita dell’applicazione che richiede sol-

tanto un’analisi off-line dei dati. Come illustrato alla sezione 2.4.2 possono essere

utilizzati numerosi software esistenti o implementare altrettante soluzioni ad hoc.

2.8.3 Calibratura e conversione in mg

Una volta memorizzati i messaggi, e necessario automatizzare l’estrazione delle

letture dell’accelerometro dai file .csv creati da XSniffer, per semplificare e velociz-

zare la successiva analisi dei dati, e convertirle in unita di misura ingegneristiche. I

dati in uscita all’accelerometro, infatti, non sono gia in m/s2 ma occore trasformarli

opportunamente. I valori delle accelerazioni inseriti all’interno del pacchetto, infatti,

sono solo il numero di conteggi in uscita all’ADC.

Entrambe le operazioni vengono fatte all’interno di una function Matlab:

function [Accel_X Accel_Y] = retrieve_accel(testo)

che come parametro di input ha il file .csv da utilizzare.

Per l’estrazione dei dati dal file viene utilizzata la routine Matlab csvread :

-1- %Leggo dal file csv generato da Xsniffer

-2- A = csvread(testo,1,14);

-3- %Estraggo le due accelerazioni

-4- Accel_X = A(:,1:2);

-5- Accel_Y = A(:,3:4);

125


-6- %Converto in unico valore decimale

-7- Accel_X(:,1) = Accel_X(:,2).*256 + Accel_X(:,1);

-8- Accel_Y(:,1) = Accel_Y(:,2).*256 + Accel_Y(:,1);

-9- %Cancello la seconda colonna

-10- Accel_X(:,2) = [ ];

-11- Accel_Y(:,2) = [ ];

Alla riga 2 la routine csvread salva all’interno della matrice A il contenuto del

file testo a partire dalla seconda riga, come indicato dal secondo parametro, e la

quindicesima colonna, come indicato dal terzo parametro (la numerazione di righe

e colonne parte da 0). Questo perche, aprendo con un editor di testo un file .csv

salvato da XSniffer, la sua struttura e la seguente:

ElapsedTime,msec,Addr,RF,Type,Grp,Len,Src,Orgn,SeqNo,Hops,AppId,1,2,3.....

0:00:00,109,Bcast,53,0,125,6,,,,,,134,1,212,1,200,1

0:00:00,109,Bcast,52,0,125,6,,,,,,134,1,212,1,200,1

...

Bisogna quindi ignorare la prima riga e selezionare solo le ultime 4 colonne che

rappresentano le accelerazioni a cui siamo interessati come gia visto in Figura 2.32

(il passaggio da una colonna all’altra e individuato dalla virgola). Il numero 134,

invece, e l’identificativo della sensor board definito in Message.h e 1 e l’id assegnato

al mote in fase di installazione.

XSniffer fa un parsing dei messaggi non interessandosi della struttura logica dei

dati nel payload del pacchetto ma semplicemente convertendo in decimale un byte

alla volta. Siccome le accelerazioni sono ognuna 2 byte allora le prime due colonne

delle 4 selezionate rappresentano l’accelerazione sull’asse X mentre le ultime 2 sono

l’accelerazione sull’asse Y. Ad esempio utilizzando i dati di cui sopra l’accelerazione

X contenuta nel primo pacchetto sniffato, e data dalla coppia (212 , 1) e siccome i

dati sono inviati in formato little-endian il secondo numero individua gli 8 bit piu

significativi. A questo punto e banale la conversione in decimale:

126


accelX = 212 + (1× 28) = 468

Questa operazione e eseguita alle righe 7 e 8.

Memorizzati i dati all’interno di due vettori e necessario ora convertire questi

valori in unita di misure ingegneristiche. In particolare si convertira in un multiplo

dell’accelerazione di gravita e piu precisamente in mg.

La formula seguente, utilizzata per la conversione, e suggerita nella stessa docu-

mentazione fornita dalla Crossbow:

Accelerazione in mg =

(1, 0− calib pos1g − AccelData

scale factor

)× 1000

dove

AccelData = valore in uscita all′ADC

scale factor =calib pos1g − calib neg1g

2

calib pos1g = accelerazione a + 1g

calib neg1g = accelerazione a − 1g

La formula utilizzata, tramite i valori di calib pos1g e calib neg1g, permette

di calibrare l’accelerometro utilizzando l’accelerazione di gravita come riferimen-

to. Questi valori possono variare sensibilmente tra diversi accelerometri e dunque

non esistono valori universali da poter utilizzare; l’unico modo per ottenere una ca-

librazione fine e misurare i valori per il proprio accelerometro e sostituirli all’interno

della formula.

Basta quindi orientare l’accelerometro in modo che un asse sia prima orientato

a +1g e successivamente, dopo una rotazione di 180◦, a -1g e leggere i valori di

conteggio dell’ADC. L’operazione va ripetuta per entrambi gli assi.

Il procedimento di rotazione e mostrato in Figura 2.33. Alla sinistra la sensor

board e orientata in modo da avere l’asse Y dell’accelerometro che punta verso

l’alto. In questa posizione l’asse X e perpendicolare all’accelerazione di gravita

127


Figura 2.33. Rotazione del mote di 180◦ affinche l’asse Y dell’accelerometro sia primaorientato a -1g e poi a +1g.

(AccelX = 0) mentre l’asse Y e a -1g (l’asse Y e parallelo all’accelerazione di gravita

ma ha verso opposto). Ruotando la scheda di 180◦ (in senso orario nel caso in

esempio) l’asse X sara ancora perpendicolare all’accelerazione di gravita mentre

l’asse Y ora e a +1g (l’asse Y e parallelo all’accelerazione di gravita e ha lo stesso

verso).

L’accelerometro, dunque, non solo misura l’accelerazione “dinamica” ma anche

quella “statica”, rappresentata dalle componenti dell’accelerazione di gravita su en-

trambi gli assi. In ogni istante, dunque, a meno che entrambi gli assi non siano

perpendicolari all’accelerazione di gravita, i valori di accelerazione letti terranno

conto anche delle componenti di accelerazione di gravita su ognuno degli assi10.

Gli assi X e Y sono entrambi complanari al piano individuato dall’accelerometro

e quindi a quello individuato dalla sensor board. Orientando dunque la sensor board

in modo che il piano individuato dalla sensor board sia perpendicolare al pavimento

(in poche parole basta prendere il sensore e metterlo con la faccia che mostra la

circuiteria di fronte a noi stessi), come alla sinistra di Figura 2.33, siamo certi che

uno dei due assi dell’accelerometro ha direzione parallela all’accelerazione di gravita.

Che sia l’asse X o l’asse Y dipende dalla posizione della sensor board che puo essere

o con il lato lungo parallelo al pavimento, come nel caso in figura, oppure con il lato

lungo perpendicolare al pavimento (ruotato di 90◦ rispetto alla posizione precedente

10L’accelerometro puo anche essere utilizzato come inclinometro poiche su entrambi gli assisussiste sempre un’accelerazione di gravita, le cui componenti su ogni asse vengono rilevate.

128


– Figura 2.34. N.B.: nella figura e mostrato solo il mote Iris senza sensor board

attaccata; tuttavia la sensor board quando e connessa al mote e parallela al circuito

di quest’ultimo. Parlare, quindi, di piano individuato dalla sensor board o dal mote

e lo stesso).

E chiaro che indicare un asse come asse X piuttosto che asse Y e una scelta com-

pletamente arbitraria. Coerentemente all’implementazione in TinyOS assumeremo

come accelerazione X quella corrispondente ai primi 16 bit mentre con accelerazione

Y quella corrispondente ai restanti 16 bit.

Acquisiamo quindi i valori dal mote prima nella posizione iniziale e poi in quella

ottenuta ruotando di 180◦. Posizionando il mote come in Figura 2.33-sinistra (in

figura e mostata solo la sensor board) e poi ruotando di 180◦, i valori grezzi (conteggi

dell’ADC) ottenuti sono stati:

Posizione iniziale ⇒ Ruotato di 180◦

AccelX = 464 AccelX = 465

AccelY = 512 AccelY = 401

Dalla lettura dei valori si osserva chiaramente che il numero di conteggi per

l’accelerazione X e rimasto sostanzialmente invariato mentre e cambiato il valore

per l’accelerazione Y. Questo significa che con questo orientamento l’asse ad essere

orientato a ±1g e l’asse Y mentre l’asse X, restando sempre perpendicolare all’ac-

celerazione di gravita, rilevera sempre lo stesso valore (AccelX = 0 m/s2), proprio

come mostrato in Figura 2.33.

Dunque la disposizione degli assi rispetto alla sensor board (e al mote) e quel-

la mostrata in Figura 2.33; i valori ottenuti per la conversione dell’accelerazione

sull’asse Y saranno:

calib pos1g = accelerazione a + 1g = 512

129


Figura 2.34. Rotazione del mote di 180◦ affinche l’asse X dell’accelerometro sia primaorientato a -1g e poi a +1g.

calib neg1g = accelerazione a + 1g = 401

Lo stesso procedimento va infine ripetuto per ottenere i valori di calib pos1g e

calib neg1g per l’accelerazione X. In maniera duale in questo caso il lato del mote a

rimanere parallelo al pavimento, prima e dopo la rotazione di 180◦, sara quello corto

(Figura 2.34). In particolare i seguenti sono i valori ottenuti per l’accelerazione X:

calib pos1g = accelerazione a + 1g = 521

calib neg1g = accelerazione a + 1g = 409

In Figura 2.35 e mostrata la corretta calibratura: il mote e posizionato e ruotato

come mostrato in Figura 2.33. Si noti come l’accelerazione Y passi da +1g a -1g

mentre l’accelerazione X rimane nulla, tranne che per nell’intervallo tra i 5 e 5,7

secondi in cui il mote viene ruotato.

2.9 Analisi dei risultati

Effettuata la conversione in mg, i segnali accelerometrici sono stati innanzitutto

graficati nel tempo e poi studiati in frequenza utilizzando Matlab.

Il carattere oscillatorio del tremore, infatti, si presta bene all’analisi in frequenza.

130


Figura 2.35. Grafici delle accelerazioni sull’asse X e sull’asse Y quando il mote vieneruotato come mostrato in Figura 2.33.

I parametri tipicamente utilizzati nella caratterizzazione del tremore sono il picco

di frequenza principale e il valore efficace (RMS) del segnale. Si e scelto, dunque, di

derivare questi stessi parametri nell’analisi condotta.

In laboratorio sono state eseguite numerose prove. Sono stati acquisiti segnali di

tremore simulato a diverse intensita mentre si era fermi o in movimento e ne e stata

fatta l’analisi in frequenza utilizzando la FFT11.

In Figura 2.36 sono mostrate le accelerazioni e i rispettivi moduli dello spettro nel

caso di simulazione di tremore di bassa intensita. In Figura 2.37, invece, il tremore

simulato e di forte intensita. Si noti come la frequenza della armonica fondamentale

nel primo caso sia intorno ai 5 Hz per entrambe le accelerazioni mentre nel secondo

11La trasformata di Fourier veloce (indicata come FFT, dall’inglese Fast Fourier Transform) eun algoritmo ottimizzato per calcolare la trasformata discreta di Fourier (DFT) e la sua inversa.Calcolare direttamente le somme della DFT richiede una quantita di operazioni aritmetiche O(n2).Un algoritmo FFT ottiene lo stesso risultato con un numero di operazioni O(n× log n)

131


caso il valore sale fino a 7,5 Hz.

Utilizzando il sensore con persone affette dal Parkinson e possibile quantificare

i valori che caratterizzano il tremore nelle 3 fasi. E possibile, inoltre, analizzare

il legame tra tremore e somministrazione della levodopa per studiare e limitare gli

effetti collaterali del farmaco.

132


Figura 2.36. Grafici delle accelerazioni sull’asse X e sull’asse Y quando e simulato untremore di bassa intensita e i rispettivi grafici dei moduli dello spettro.

133


Figura 2.37. Grafici delle accelerazioni sull’asse X e sull’asse Y quando e simulato untremore di forte intensita e i rispettivi grafici dei moduli dello spettro.

134

Conclusioni

In una popolazione con un mumero crescente di persone anziane e con malattie

croniche, la necessita di fornire assistenza sanitaria personalizzata e la prima moti-

vazione nello sviluppo delle Body Sensor Network. Siccome gli sviluppi tecnologici

in dispositivi per il “sensing” e il “monitoring” non solo cambieranno la gestione

di malattie croniche in casa e nell’ambiente quotidiano ma rimodelleranno le tecni-

che tradizionali di medicina clinica, il concetto di BSN e un ingrediente importante

nell’obiettivo di garantire assistenza sanitaria pervasiva

Anche se misurazioni estensive di informazioni biomeccaniche e biochimiche sono

gia disponibile in tutti gli ospedali, queste pratiche di diagnostica e monitoraggio

sono generalmente limitate a brevi intervalli di tempo e condizionate da uno stato del

paziente “artificiale”, che non rispecchia le abitudini quotidiane reali della persona.

Fenomeni transitori, in questo modo, non possono essere sempre catturati. Per

esempio, molti disturbi cardiaci sono associati ad episodi sporadici piuttosto che

continui. Questi episodi sono importanti ma il momento in cui si presenteranno non

puo essere predetto e attualmente si perde molto tempo nel tentare di catturare

“episodi” durante un monitoraggio controllato. Soltanto il monitoraggio continuo

garantito dalle BSN puo essere la svolta a questo problema. Con i notevoli sviluppi

raggiunti nella miniaturizzazione dei circuiti e nello sviluppo di sensori chimici e

biosensori oggi e possibile sviluppare piattaforme di monitoraggio complesse a costi

davvero bassi rispetto alla strumentazione medica attuale.

L’ultimo obiettivo delle BSN e fornire soluzioni di monitoraggio personalizzato,

135


intelligente, context-aware e invisibile al paziente, evitando restrizioni nelle attivita

svolte o modifiche nelle abitudini.

Il concetto di BSN attrae un insieme enorme di applicazioni, dal monitorag-

gio dei pazienti con disagi cronici alla cura di persone anziane, alla valutazione di

performance di gesti atletici, fino al settore videoludico e il social sharing.

Tuttavia, numerose sono le sfide tecnologiche, e sociali, ancora aperte. Alcune

tra queste vengono analizzate qui di seguito:

• Progettazione di biosensori e integrazione MEMS

I recenti progressi in sensori biologici, chimici, elettrici e meccanici ha per-

messo lo sviluppo di un ampio insieme di sensori impiantabili e indossabili

utilizzabili per il monitoraggio continuo. Gia sono realta glucometri, sensori

della pressione sanguigna etc. impiantabili.

Soprattutto in sensori impiantabili il requisito di biocompatibilita e fondamen-

tale nella progettazione. I biosensori devono essere costituiti da materiali

biocompatibili che evitano irritazione e reazioni allergiche. Per sensori im-

piantabili questo e essenziale per scongiurare il pericolo di infiammazioni e

risposte avverse del sistema immunitario. Tuttavia, le stesse tecniche costrut-

tive che garantiscono la biocompatibilita possono essere fonte, talvolta, del

fallimento del sensore stesso. I biosensori, inoltre, sono spesso affetti da rumo-

re dovuto ai movimenti e a interferenze. Tutto cio crea diversi problemi nel

monitoraggio continuo della persona.

Per migliorare l’affidabilita del sensore possono essere utilizzati approcci che

prevedano l’utilizzo di array di sensori o tecniche che prevedano la “fusione”

dei segnali provenienti da piu sensori. Il multi-sensor fusion puo ad esempio

essere utilizzato nell’acquisizione dell’ECG: quando il segnale proveniente da

un sensore ECG e degradato, sia per problemi nella connessione degli elettrodi

o per il movimento del paziente, l’analisi congiunta di sensori addizionali, che

ad esempio misurano la pressione ventricolare, puo continuare ad assicurare

136


il monitoraggio del ritmo cardiaco. Utilizzando, invece, array di microsensori

l’affidabilita risulta superiore data l’improbabilita che piu sensori falliscano

contemporaneamente. Fondendo le letture provenienti da piu sensori, possono

essere ottenute misurazioni piu affidabili.

Tuttavia, l’introduzione di ridondanza che aumenta il numero di sensori, pur

migliorando le performance dell’intero sistema puo aumentare notevolmente la

complessita del sistema e avere effetti sullo sviluppo pratico del sistema stesso.

Inoltre un numero grande di sensori puo minare alla “trasparenza” della BSN

percepita dal paziente che la utilizza. La necessita di minimizzare il numero

di sensori lancia nuove sfide alle tecniche di feature-selection da impiegare per

identificare il numero di sensori da utilizzare necessario e la loro posizione, e

alle tecniche di classificazione che utilizzano i segnali provenienti da piu sensori.

Infine, i notevoli progressi nella tecnologia MEMS stanno facilitando lo svilup-

po di sensori fisiologici e attuatori miniaturizzati, quali ad esempio sommini-

stratori di farmaci. Continuare a muoversi in questa direzione sara fondamen-

tale per permettere lo sviluppo di sistemi affidabili, “discreti” e con funzioni

sempre piu complesse.

• Miniaturizzazione dell’alimentazione, Power Scavenging e Signal-processing a

bordo sensore

L’alimentazione e uno degli elementi chiavi per garantire il monitoraggio per-

vasivo. Le sfide piu difficili riguardano le dimensioni e la durata delle batterie,

che attualmente sono la fonte di energia principale per i nodi. Normali bat-

terie a litio permettono una durata che va da mesi ad anni (dipendendo dal

duty-cycle). Batterie a idrocarburi possono fornire durate fino a 6 volte su-

periori a quelle di una batteria a litio e in dimensioni piu piccole. I progressi

in queste nuove tecnologie permetteranno la completa sostituzione delle bat-

terie esistenti. Recenti ricerche hanno anche proposto l’utilizzo di celle che ad

137


Figura 2.38. Consumo di potenza medio di trasmettitori wireless (in arancione) emicroprocessori (in blu) in tipiche piattaforme BSN.

esempio utilizzano il glucosio per fornire potenza a sensori impiantabili.

Con l’obiettivo di allungare quanto piu possibile la vita delle batterie la ricerca

in tecniche di power harvesting e fondamentale. Gli studi sull’argomento, tut-

tavia, sono ancora agli inizi ma gli sviluppi che seguiranno saranno certamente

una chiave fondamentale nello sviluppo di sistemi di monitoraggio pervasivo

“discreti”.

La riduzione del consumo energetico, inoltre, puo essere raggiunta anche con

un’accurata progettazione del sistema. Le comunicazioni wireless sono certa-

mente la causa maggiore di dissipazione di energia. La progettazione di una

soluzione che riduca notevolmente il numero di messaggi inviati sulla rete puo

migliorare sensibilmente le prestazioni dell’intero sistema. In tal senso una

sfida ancora aperta e rappresentata dalla possibilita di effettuare elaborazione

complessa dei segnali direttamente a bordo sensore, riducendo sensibilmente

il numero di dati trasmessi. La Figura 2.38 mostra il consumo di potenza

di trasmettitori wireless e microprocessori in tipiche piattaforme BSN. Essa

sottolinea due importanti caratteristiche delle tecnologie embedded esistenti:

processare i dati a una data velocita consuma meno potenza in media del tra-

smettere i dati via wireless, e riducendo il data-rate diminuira anche il consumo

138


energetico sia del microprocessore che della radio. Questa caratteristica crea

un trade-off tra elaborazione e invio del segnale: il signal-processing eseguito

dal nodo consumera potenza per estrarre informazioni, ma esso ridurra anche

il data-rate nella rete e quindi il consumo di energia totale. Inoltre il proces-

sing in situ risolve anche i problemi di errate classificazioni dovute a errori nel

pacchetto.

I vantaggi dell’elaborazione dei segnali direttamente a bordo sensore introdu-

cono nuove sfide da superare. Gli algoritmi di classificazione di attivita, di

rilevamento di specifici eventi e in generale algoritmi che rendono il sistema

context-aware dovrebbero essere robusti per garantire affidabilita dei risulta-

ti ottenuti ma altrettanto semplici computazionalmente in maniera da essere

eseguiti da nodi con risorse limitate e in tempi che assicurano che il sistema

sia ancora un sistema real-time.

Questo, dunque, aggiunge ulteriori “challenges” alla realizzazione di un siste-

ma che sia context-aware, ovvero un sistema che a dati fisiologici associ anche

informazioni del contesto in modo da capire lo stato sotto cui alcuni eventi av-

versi si presentano. Nel corso degli ultimi anni diversi meccanismi di inferenza

sono gia stati proposti per applicazioni context-aware. L’utilizzo di tecniche di

“data fusion” di segnali provenienti da piu sensori (multi-sensor data fusion)

puo migliorare la capacita di inferenza del classificatore. In questo caso i clas-

sificatori sono progettati per ottenere risultati ottimi basandosi sulla fusione di

tutte le letture dei sensori. All’interno di BSN, dunque, l’obiettivo principale

della fusione di dati e quella di combinare informazione provenienti da diversi

sensori per catturare dati con migliore affidabilita, precisione, fault tolerance

e potere inferente in un modo che va oltre le capacita di un singolo sensore.

• Autonomic Sensing

Quando i sistemi BSN diventano “ubiquitous” , gestire il grande numero di

139


Tabella 2.10. Le 8 caratteristiche che definiscono un sistema autonomico (adattate da[48])

Caratteristiche di un Sistema Autonomico

Self-management

Un sistema autonomico necessita di avere dettagliata conoscenza dei suoi com-ponenti, stato corrente, capacita, e tutte le connessioni ad altri sistemi pergestire se stesso.

Self-configuration

Un sistema autonomico puo automaticamente e dinamicamente configurare ericonfigurare se stesso sotto diverse condizioni e cambiamenti dell’ambiente.

Self-optimisation

Un sistema autonomico puo costantemente ottimizzare le sue performance el’utilizzo delle risorse attraverso il monitoraggio dei suoi componenti al fine diraggiungere predeterminate performance e utilizzo delle risorse.

Self-healing Un sistema autonomico puo recuperare da routine e eventi straordinari checausano il malfunzionamento dei componenti. E capace di scoprire problemie utilizzare risorse e/o configurazioni alternative per assicurare le funzionalitadel sistema.

Self-protection Un sistema autonomico deve essere capace di identificare differenti tipi diattacco per assicurare integrita e sicurezza totale del sistema.

Self-adaptation

Un sistema autonomico deve essere context-aware e adattare se stesso per mi-gliorare l’interazione e le performance in seguito a cambiamenti dell’ambientedi lavoro e dei requisiti utente.

Self-integration

Un sistema autonomico puo funzionare normalmente con infrastrutture ete-rogenee ed essere integrato perfettamente e in maniera sicura con altrisistemi.

Self-scaling Un sistema autonomico anticipera l’ottimizzazione delle risorse richieste e sca-lera le sue funzionalita mantenendo comunque nascosta la sua complessitaall’utente.

micro sensori che li compongono diventa un compito difficile. Questo pro-

blema puo essere risolto attraverso il concetto di autonomic sensing. L’au-

tonomic sensing, che segue il concetto di autonomic computing12, puo essere

caratterizzato dalle 8 proprieta illustrate in Tabella 2.10.

Data la potenza ed i vincoli computazionali dei nodi sensore, sviluppare un

vero sistema autonomico rimane ancora un argomento attivo di ricerca.

• Storage

Memorie di dimensioni maggiori ma a basso consumo sono fondamentali per

12L’Autonomic Computing e un’iniziativa avviata dall’IBM nel 2001. Il suo scopo e quello difornire ai computer gli strumenti necessari per auto-gestirsi senza l’intervento umano. In un sistemaauto-amministrato, l’operatore umano non deve controllare il sistema direttamente ma definiscepolitiche generali a regole date in input al processo di auto-gestione.

140


garantire funzionalita di storage a lungo termine in applicazioni che non richie-

dono analisi real-time dei dati o i cui dati debbano essere utilizzati da algoritmi

di classificazione implementati direttamente a bordo sensore. Lo storage sul

sensore riduce anche le trasmissioni, incrementando l’autonomia della batte-

ria. L’industria della microelettronica sta sviluppando memorie non volatili a

basso consumo come le MRAM e RRAM.

Le sfide ancora aperte includono, dunque, la necessita di migliorare il design dei

sensori, l’integrazione dei circuiti MEMS, la biocompatibilita, la miniaturizzazione

dell’alimentazione, tecniche di power harvesting, tecniche per il context-awareness. . .

A queste si aggiungono il trasferimento dati sicuro, la tutela della privacy e piu

in generale la dependability del sistema, l’usabilita e la necessita di utilizzare uno

standard che garantisca l’interoperabilita tra dispositivi (problematiche illustrate

alle sezioni 1.2 e 2.5).

I sistemi BSN, una volta sviluppati, dovranno essere utilizzati da una complessa

rete di stakeholder (utenti, servizi di emergenza, medici, parenti, ricercatori. . . ).

Soluzioni ai problemi tecnologici ancora irrisolti contribuiranno ad aumentare il

“livello di trust” nelle Body Sensor Network sia per i pazienti sia per i medici, ed in

definitiva miglioreranno il “valore percepito”.

Affinche il successo delle BSN sia garantito un requisito su tutti deve essere

rispettato: le BSN devono migliorare la Qualita di Vita dell’utente, dove l’utente

non e solo il paziente o il medico ma tutti coloro che ne possono beneficiare. Questo

requisito racchiude in se tutte le sfide tecnologiche e sociali che le BSN devono

affrontare.

141

Appendice A

Datasheet

Iris mote – MTS400/420

Di seguito sono forniti i datasheet del mote Iris e della sensor board MTS400

utilizzati. Per informazioni relative ad altri componenti hardware mensionati in tale

lavoro si faccia riferimento alla bibliografia ed al sito del produttore, www.xbow.com.

142


P h o n e : 4 0 8 . 9 6 5 . 3 3 0 0 F a x : 4 0 8 . 3 2 4 . 4 8 4 0 E - m a i l : i n f o @ x b o w . c o m W e b : w w w . x b o w . c o m

WIRELESS MEASUREMENT SYSTEM

IRIS

• 2.4GHzIEEE802.15.4,TinyWirelessMeasurementSystem

• DesignedSpecificallyforDeeplyEmbeddedSensorNetworks

• 250kbps,HighDataRateRadio

• WirelessCommunicationswithEveryNodeasRouterCapability

• ExpansionConnectorforLight,Temperature,RH,BarometricPressure,Acceleration/Seismic,Acoustic,MagneticandotherCrossbowSensorBoards

Applications• IndoorBuildingMonitoringand

Security

• Acoustic,Video,VibrationandOtherHighSpeedSensorData

• LargeScaleSensorNetworks(1000+Points)

XM2110CABlockDiagram

Document Part Number: 6020-0124-01 Rev A

TheIRISisa2.4GHzMotemoduleusedforenablinglow-power,wirelesssensornetworks.TheIRISMotefeaturesseveralnewcapabilitiesthatenhancetheoverallfunctionalityofCrossbow’swirelesssensornetworkingproducts.

Product features include:

• UptothreetimesimprovedradiorangeandtwicetheprogrammemoryoverpreviousMICAMotes

• Outdoorline-of-sighttestshaveyeildedrangesasfaras500metersbetweennodeswithoutamplification

• IEEE802.15.4compliantRFtransceiver

• 2.4to2.48GHz,agloballycompatibleISMband

• DirectsequencespreadspectrumradiowhichisresistanttoRFinterferenceandprovidesinherentdatasecurity

• 250kbpsdatarate• SupportedbyMoteWorks™wireless

sensornetworkplatformforreliable,ad-hocmeshnetworking

• PlugandplaywithCrossbow’ssensorboards,dataacquisitionboards,gateways,andsoftware

MoteWorks™enablesthedevelopmentofcustomsensorapplicationsandisspecificallyoptimizedforlow-power,

battery-operatednetworks.MoteWorksisbasedontheopen-sourceTinyOSoperatingsystemandprovidesreliable,ad-hocmeshnetworking,over-the-air-programmingcapabilities,crossdevelopmenttools,servermiddlewareforenterprisenetworkintegrationandclientuserinterfaceforanalysisandconfiguration.

Processor & Radio Platform TheXM2110CAisbasedontheAtmelATmega1281.TheATmega1281isalow-powermicrocontrollerwhichrunsMoteWorksfromitsinternalflashmemory.Asingleprocessorboard(XM2110)canbeconfiguredtorunyoursensorapplication/processingandthenetwork/radiocommunicationsstacksimultaneously.TheIRIS51-pinexpansionconnectorsupportsAnalogInputs,DigitalI/O,I2C,SPIandUARTinterfaces.Theseinterfacesmakeiteasytoconnecttoawidevarietyofexternalperipherals.

Sensor BoardsCrossbowoffersavarietyofsensoranddataacquisitionboardsfortheIRISMote.AlloftheseboardsconnecttotheIRISviathestandard51-pinexpansionconnector.Customsensoranddataacquisitionboardsarealsoavailable.PleasecontactCrossbowforadditionalinformation.

IRIS

RoHS COMPLIANT

143


C r o s s b o w Te c h n o l o g y , I n c . 4 1 4 5 N o r t h F i r s t S t r e e t S a n J o s e , C a l i f o r n i a 9 5 1 3 4 - 2 1 0 9

Ordering InformationModel Description

XM2110CA 2.4GHzIRISOEMReferenceBoard

MIB520CAMoteInterfaceBoard


Notes15MHzstepsforcompliancewithIEEE802.15.4/D18-2003.

Specificationssubjecttochangewithoutnotice

Processor/RadioBoard XM2110CA Remarks

Processor Performance

ProgramFlashMemory 128Kbytes

Measurement(Serial)Flash 512Kbytes >100,000Measurements

RAM 8Kbytes

ConfigurationEEPROM 4Kbytes

SerialCommunications UART 0-3Vtransmissionlevels

AnalogtoDigitalConverter 10bitADC 8channel,0-3Vinput

OtherInterfaces DigitalI/O,I2C,SPI

CurrentDraw 8mA Activemode

8µA Sleepmode(total)

RF Transceiver

Frequencyband1 2405MHzto2480MHz ISMband,programmablein1MHzsteps

Transmit(TX)datarate 250kbps

RFpower 3dBm(typ)

ReceiveSensitivity -101dBm(typ)

Adjacentchannelrejection 36dB +5MHzchannelspacing

34dB -5MHzchannelspacing

OutdoorRange >300m 1/4wavedipoleantenna,LOS

IndoorRange >50m 1/4wavedipoleantenna,LOS

CurrentDraw 16mA Receivemode

10mA TX,-17dBm

13mA TX,-3dBm

17mA TX,3dBm

Electromechanical

Battery 2XAAbatteries Attachedpack

ExternalPower 2.7V-3.3V Molexconnectorprovided

UserInterface 3LEDs Red,greenandyellow

Size(in) 2.25x1.25x0.25 Excludingbatterypack

(mm) 58x32x7 Excludingbatterypack

Weight(oz) 0.7 Excludingbatteries

(grams) 18 Excludingbatteries

ExpansionConnector 51-pin AllmajorI/Osignals

Base StationsAbasestationallowstheaggregationofsensornetworkdataontoaPCorothercomputerplatform.AnyIRISMotecanfunctionasabasestationwhenitisconnectedtoastandardPCinterfaceorgatewayboard.TheMIB510orMIB520providesaserial/USBinterfaceforbothprogramminganddatacommunications.Crossbowalsooffersastand-alonegatewaysolution,theMIB600forTCP/IP-basedEthernetnetworks.

IRISMote(bottomview)

144


P h o n e : 4 0 8 . 9 6 5 . 3 3 0 0 F a x : 4 0 8 . 3 2 4 . 4 8 4 0 E - m a i l : i n f o @ x b o w . c o m W e b : w w w . x b o w . c o m

MTS420/400Developed in conjunction with UC Berkeley and Intel Research Labs, the MTS400 and MTS420 offer five basic environmental sensing parameters and an optional GPS module (MTS420).

These sensor boards utilize the latest generation of IC-based surface mount sensors. These energy-efficient digital devices in turn provide extended bat-tery life and performance wherever low maintenance field-deployed sensor nodes are required.

These versatile sensor boards are intended for a wide variety of applica-tions ranging from a simple wireless weather station to a full mesh network of environmental monitoring nodes. Applicable industries include Agricul-tural, Industrial, Forestry, HVAC and more.

Specifications:Board

• Operating temp. range: -10°C to +60°C

• Operating humidity range 0% RH to 90% RH non-condensing

ENVIRONMENTAL SENSOR BOARD

MTS420/400


• Compatible with MICAz/MICA2 Processor/ Radio Boards

• Onboard Temperature & Humidity, Barometric Pressure and Ambient Light Sensors

• Dual-Axis Accelerometer

• 64K EEPROM for User Configuration Data

• Optional GPS Module

Applications• Agricultural Monitoring

• Art Preservation

• Environmental Monitoring

• Sensor Location Mapping* (*GPS Equipped)

MTS400CB

Model Description

MTS400CB MICA2 Weather Sensor Board with Light, Temperature, Humidity, Barometric Pressure and Seismic

MTS420CC MICA2 Weather Sensor Board Light, Temperature, Humidity, Barometric Pressure, Seismic and GPS

Ordering Information

Dual-axis Accelerometer

• Analog Devices ADXL202JE

• Acceleration range; resolution: ±2 g; 2 mg at 60 Hz

• Nonlinearity: 0.2% of full scale

• Zero g bias level: 2.0 mg/°C from 25°C

Barometric Pressure Sensor

• Intersema MS5534AM

• Pressure range; resolution: 300-1100 mbar; 0.01 mbar

• Accuracy: ± 1.5% at 25°C

Ambient Light Sensor

• TAOS TSL2550D

• Spectral responsivity: 400-1000 nm,

similar to human eye

Relative Humidity & Temperature Sensor

• Sensirion SHT11

• Humidity range; resolution: 0-100% RH; 0.03% RH

• Absolute RH accuracy: ± 3.5% RH

• Temp. accuracy: ± 0.5°C @ 25°C

GPS Module (MTS420CC only)

• ublox LEA-4A

• Tracking channels: 16

• L1 frequency: 1575.42 MHz C/A code

• Position accuracy: 10 m, 2D

• Reacquisition time: < 1 sec. (typ.);

(<30 sec. max. blockage)

MTS420CC (with GPS Module)

145

Bibliografia

[1] Lo BPL, Yang GZ. – Key technical challenges and current implementations of

body sensor networks. In: Proceedings of the Second International Workshop. on

Wearable and Implantable Body Sensor Networks 2005; 1-5.

[2] Guang-Zhong Yang – Body Sensor Networks.

[3] Terrance J. Dishongh Michael McGrath – Wireless Sensor Networks for

Healthcare Applications.

[4] Allen MG. – Implantable micromachined wireless pressure sensors: approachand

clinical demonstration. In: Proceedings of the Second International Workshop

on Wearable and Implantable Body Sensor Networks 2005; 40-43.

[5] OECD – Country statistical profiles 2010: Italy.

[6] International Diabetes Federation (IDF) [Online] – http://www.idf.org/

[7] World Health Organization [Online] – http://www.who.int

[8] Schilit B, Adams N, Want R. – Context-aware computing applications. In: Pro-

ceedings of the Workshop on Mobile Computing Systems and Applications 1994;

85-90.

[9] Dey AK, Abowd G. – Towards a better understanding of context and contex-

tawareness. In: Proceedings of the CHI 2000 Workshop on The What, Who,

Where, When, and How of Context-Awareness 2000.

146


[10] A.R. Guraliuc, A.A. Serra, P. Nepa, G. Manara, F. Potortı – Detection and

Classification of Human Arm Movements for Physical Rehabilitation.

[11] Picard RW, Vyzas E, Healey J. – Toward machine emotional intelligence: ana-

lysis of affective physiological state. IEEE Transactions on Pattern Analysis and

Machine Intelligence 2001; 23(10):1175-1191.

[12] Bardram JE. – Applications of context-aware computing in hospital work: exam-

ples and design principles. In: Proceedings of the 2004 ACM Symposium on

Applied Computing, Nicosia, Cyprus, 2004; 1574-1579.

[13] Ryan Burchfield and S. Venkatesan – A Framework for Golf Training Using

Low-Cost Inertial Sensors. In: 2010 International Conference on Body Sensor

Networks.

[14] Julien Pansiot, Benny Lo, and Guang-Zhong Yang – Swimming Stroke Kine-

matic Analysis with BSN In: 2010 International Conference on Body Sensor

Networks.

[15] Reed W. Hoyt, Biophysics and Biomedical Modeling Division, U.S.

Army Research Institute of Environmental Medicine (USARIEM) –

SPARNET: Spartan Sensor Network to Improve Medical And Situatio-

nal Awareness Of Foot Soldiers During Field Training. Disponibile a:

http://mobisensors.cs.pitt.edu/files/papers/hoyt.pdf

[16] El-Nasr M, Vasilakos A (2008) – DigitalBeing: using the environment as an

expressive medium for dance.

[17] Benoit Latre, Bart Braem, Ingrid Moerman, Chris Blondia, Piet Demeester –

A Survey on Wireless Body Area Networks.

[18] Min Chen, Sergio Gonzalez, Athanasios Vasilakos, Huasong Cao, Victor C. M.

Leung – Body Area Networks: A Survey.

147


[19] T. Penzel, B. Kemp, G. Klosch, A. Schlogl, J. Hasan, A. Varri, and I. Korhonen

– Acquisition of biomedical signals databases. In: IEEE Engineering in Medicine

and Biology Magazine, vol. 20, no. 3, pp. 2532, May/Jun. 2001.

[20] S. Arnon, D. Bhastekar, D. Kedar, and A. Tauber – A comparative study

of wireless communication network configurations for medical applications In:

IEEE [see also IEEE Personal Communications] Wireless Communications, vol.

10, no. 1, pp. 56-61, Feb. 2003.

[21] Healthservice24 – http://www.healthservice24.com

[22] Omnicom Hydra – http://www.omnicom.bs.it/hydra.html

[23] DICOM – http://medical.nema.org/

[24] L. Schmitt, T. Falck, F. Wartena, and D. Simons – Novel ISO/IEEE 11073

Standards for Personal Telehealth Systems Interoperability.

[25] Miguel GALARRAGA, Luis SERRANO, Ignacio MARTINEZ, Paula de

TOLEDO – Standards for Medical Device Communication: X73 PoC–MDC.

[26] M. Galarraga, L. Serrano, I. Martinez, P. de Toledo and Melvin Rey-

nolds – Telemonitoring Systems Interoperability Challenge: An Updated Re-

view of the Applicability of ISO/IEEE 11073 Standards for Interoperability in

Telemonitoring.

[27] Mauri Honkanen, Antti Lappetelainen, and Kalle Kivekas – Low End Extension

for Bluetooth.

[28] Axel Sikora, Voicu F. Groza - Coexistence of IEEE802.15.4 with other Systems

in the 2.4 GHz-ISM-Band.

[29] Cheolhyo Lee, Jaehwan Kim, Hyung Soo Lee, and Jaeyoung Kim – Physical

Layer Designs for WBAN Systems in IEEE 802.15.6 Proposals.

148


[30] Salim A. Hanna – Regulations and Standards for Wireless Medical Applications.

[31] Flavio Frattini – Localizzazione di sensori in reti WSN mediante la metrica

RSSI.

[32] nesC e TinyOS – http://www.tinyos.net/ – http://www.tinyos.net/tinyos-

1.x/doc/tutorial/

[33] Bluetooth Low Energy – http://www.bluetooth.com

[34] Rudi Latuske, ARS Software GmbH – Bluetooth Health Device Profile and the

IEEE 11073 Medical Device Framework.

[35] Bluetooth SIG – Health Device Profile Specification 1.0

[36] Tia Gao, Tammara Massey, Leo Selavo, David Crawford, Bor-rong Chen, Kon-

rad Lorincz, Victor Shnayder, Logan Hauenstein, Foad Dabiri, James Jeng, Ar-

jun Chanmugam, David White, Majid Sarrafzadeh, Fellow, IEEE, and Matt

Welsh – The Advanced Health and Disaster Aid Network: A Light-Weight

Wireless Medical System for Triage.

[37] Shanshan Jiang, Yanchuan Cao, Sameer Iyengar, Philip Kuryloski, Roozbeh

Jafari Yuan Xue, Ruzena Bajcsy, Stephen Wicker – CareNet: An Integrated

Wireless Sensor Networking Environment for Remote Healthcare.

[38] Orlando R. E. Pereira, Joel J. P. C. Rodrigues, Abel J. P. Gomes –

Contributions of Sensor Networks to Improve Gaming Experience.

[39] Steve Warren1, Jeffrey Lebak, Jianchu Yao, Jonathan Creekmore, Aleksandar

Milenkovic, and Emil Jovanov – Interoperability and Security in Wireless Body

Area Network Infrastructures.

[40] HL7 – http://www.hl7.org

[41] www.parkidee.it – Il mio tremore parkinsoniano.

149


[42] N. M. Aly, J. R. Playfer, S. L. Smith, D. M. Halliday – A novel computer-based

technique for the assessment of tremor in Parkinson’s disease.

[43] Mehmet Engin – A recording and analysis system for human tremor.

[44] George Rigas, Alexandros T. Tzallas, Dimitrios G. Tsalikakis, Spiros Konitsio-

tis and Dimitrios I. Fotiadis – Real-Time Quantification of Resting Tremor in

the Parkinson’s Disease.

[45] Robert LeMoyne, Timothy Mastroianni, Michael Cozza, Cristian Coroian, and

Warren Grundfest – Implementation of an iPhone for characterizing Parkinson’s

disease tremor through a wireless accelerometer application.

[46] Joshua A. Weaver – A Wearable Health Monitor To Aid Parkinson Disease

Treatment.

[47] Yeatman E.M. 2004 – Proceedings of the 1st International Workshop on

Wearable and Implantable Body Sensor Networks.

[48] Autonomic Computing – http://www.research.ibm.com/autonomic/

[49] Mark A. Hanson, Harry C. Powell Jr., Adam T. Barth, Kyle Ringgenberg,

Benton H. Calhoun, James H. Aylor, John Lach (University of Virginia) – Body

Area Sensor Networks: Challenges and Opportunities.

[50] Benny P L Lo and Guang-Zhong Yang – Key Technical Challenges and Current

Implementations of Body Sensor Networks.

150

Body Sensor Networks: Applicazioni, Tecnologie e Sfide aperte · Facoltà di Ingegneria Corso di...

Documents

Transcript of Body Sensor Networks: Applicazioni, Tecnologie e Sfide aperte · Facoltà di Ingegneria Corso di...