Body Sensor Network pdfauthor=Giovanni Giacco

Transcript

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
1.1 Il contesto demografico . . . . . . . . . . . . . . . . . . . .
1.2 Dalle Wireless Sensor Networks alle Body Sensor Networks
1.3 Monitoraggio pervasivo del paziente . . . . . . . . . . . . .
1.3.1 Context-Aware Sensing e Activity Recognition . . .
1.3.2 Monitoraggio nell’ambiente ospedaliero . . . . . . .
1.3.3 Monitoraggio nell’ambiente domestico . . . . . . . .
1.3.4 Monitoraggio di pazienti con malattie croniche . . .
1.3.5 Assistenza sanitaria personalizzata . . . . . . . . .
1.4 Oltre l’assistenza sanitaria . . . . . . . . . . . . . . . . . .
2 Tecnologie abilitanti per la realizzazione di BSN
2.1 Hardware e dispositivi . . . . . . . . . . . . . . .
2.1.1 Sensori corporali . . . . . . . . . . . . . .
2.1.2 Piattaforme . . . . . . . . . . . . . . . . .
2.2 Architetture per BSN . . . . . . . . . . . . . . . .
2.2.1 Comunicazioni Intra–BAN . . . . . . . . .
2.2.2 Comunicazioni Inter–BAN . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
6
13
17
22
23
25
28
29
.
.
.
.
.
.
35
35
36
42
43
47
49
i
Indice
2.3
2.4
2.5
2.2.3 Comunicazioni Beyond–BAN . . .
Tecnologie Wireless . . . . . . . . . . . . .
2.3.1 Bluetooth . . . . . . . . . . . . . .
2.3.2 Bluetooth 4.0: Low Energy . . . .
2.3.3 IEEE 802.15.4 e ZigBee . . . . . .
2.3.4 UWB e IEEE 802.15.6 . . . . . . .
Piattaforme Software . . . . . . . . . . . .
2.4.1 nesC e TinyOS . . . . . . . . . . .
2.4.2 Raccolta, Storage e Post-Processing
Standard e Interoperabilità . . . . . . . . .
2.5.1 DICOM . . . . . . . . . . . . . . .
2.5.2 HL7 . . . . . . . . . . . . . . . . .
2.5.3 ISO / IEEE 11073 . . . . . . . . . .
Personal Health Data . . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
dei
. .
. .
. .
. .
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
dati
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Analisi di un caso di studio: Il morbo di Parkinson
2.6 Il tremore nel morbo di Parkinson . . . . . . . . . . .
2.7 Hardware e Software Design . . . . . . . . . . . . . .
2.8 Acquisizione delle accelerazioni . . . . . . . . . . . .
2.8.1 Implementazione in TinyOS . . . . . . . . . .
2.8.2 Raccolta e memorizzazione dei messaggi . . .
2.8.3 Calibratura e conversione in mg . . . . . . . .
2.9 Analisi dei risultati . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
55
59
65
70
71
72
76
77
79
82
87
93
.
.
.
.
.
.
.
108
. 111
. 114
. 119
. 119
. 124
. 125
. 130
Conclusioni
135
A Datasheet
Iris mote – MTS400/420
142
Bibliografia
146
ii
Elenco delle figure
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
2.1
2.2
2.3
2.4
2.5
2.6
Distribuzione dell’età media della popolazione europea . . . . . . .
Trend della spesa sanitaria in Italia (Fonte: OECD) . . . . . . . . .
Rappresentazione schematica dell’architettura di una BSN . . . . .
Piattaforme per WSN sviluppate fino al 2005 . . . . . . . . . . . . .
Requisiti minimi e ottimali per polisonnografia digitale. . . . . . . .
Data-rate di misurazioni biomediche . . . . . . . . . . . . . . . . . .
CardioNET (sinistra) - Sensore in un anello (destra) . . . . . . . . .
Code Blue (Harvard University) . . . . . . . . . . . . . . . . . . . .
CardioMEMS: sensore di pressione utilizzato per la rilevazione di
aneurismi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Legame tra i costi dell’assistenza sanitaria, la Qualità della Vita e
l’ambiente in cui le cure avvengono (Fonte: Intel) . . . . . . . . . .
(Sinistra) Giocatore che utilizza il Wii Remote. (Destra) Playstation
Move. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accelerometro sugli occhialini del nuotatore - Sistemi di coordinate e
angoli utilizzati nello studio . . . . . . . . . . . . . . . . . . . . . .
Nike + Ipod Sports Kit . . . . . . . . . . . . . . . . . . . . . . . . .
. 5
. 6
. 7
. 8
. 9
. 10
. 15
. 16
. 22
. 23
. 29
. 30
. 31
Sensori inseriti in una maglia - Accelerometro MEMS . . . . . . . . .
Sensore di pressione del sangue - Fascia elestica contenente sensori EEG
Sensore EMG - Sensore ECG - Sensore CO2 - Pulsossimetro . . . . .
Architettura di un nodo sensore. . . . . . . . . . . . . . . . . . . . . .
Un’architettura three-tier per un sistema di comunicazione basato su
BSN per applicazioni nell’assistenza sanitaria. . . . . . . . . . . . . .
Architettura della comunicazione intra–BAN . . . . . . . . . . . . . .
37
39
41
43
46
47
iii
Elenco delle figure
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.31
2.32
Architettura della comunicazione inter–BAN . . . . . . . . . . . . .
BSN mobile connessa a una WSN ambientale. . . . . . . . . . . . .
Posizionamento di una Wireless Body Area Network nel mondo delle
reti wireless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caratteristiche di una WBAN confrontate con WSN e WLAN. . . .
BSN che utilizza Bluetooth + Health Device Profile (Fonte: Bluetooth
SIG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Struttura della superframe . . . . . . . . . . . . . . . . . . . . . . .
Stack di comunicazione ZigBee. . . . . . . . . . . . . . . . . . . . .
Operazione split-phase in TinyOS. . . . . . . . . . . . . . . . . . . .
Architettura di TinyOS. . . . . . . . . . . . . . . . . . . . . . . . .
Composizione di un messaggio HL7. . . . . . . . . . . . . . . . . . .
Conversionde della stringa XML in un messaggio HL7. [22] . . . . .
Timeline dello standard ISO /IEEE 11073. . . . . . . . . . . . . . .
Package che compongono il DIM. . . . . . . . . . . . . . . . . . . .
Sequence diagram dell’avvio di comunicazione tra due dispositivi. .
Standard che compongono la famiglia di standard ISO / IEEE 11073
PHD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class diagram dell’IEEE 11073 PHD Domain Information Model. .
Class diagram del DIM di una bilancia pesa persona. . . . . . . . .
Messaggio di rischiesta associazione: (a) Agente non riconosciuto.
(b) Agente riconosciuto. . . . . . . . . . . . . . . . . . . . . . . . .
(a) Operazioni di un oggetto Scanner. (b) Operazioni per l’accesso
al PM-Store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistema generico di telemedicina che integra sistemi eterogenei. . . .
(Sinistra) Sensor board MTS420. (Destra) Iris Mote. . . . . . . . .
Programming Board MIB520. . . . . . . . . . . . . . . . . . . . . .
Base Station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strumenti hardware e software utilizzati. . . . . . . . . . . . . . . .
(Sopra) Collegamenti tra i componenti del programma ReadingAccel.
(Sotto) Sequenza di eventi che caratterizzano il programma. . . . .
XSniffer: Sniffing dei messaggi . . . . . . . . . . . . . . . . . . . . .
. 50
. 52
. 54
. 55
.
.
.
.
.
.
.
.
.
.
63
66
68
74
75
84
85
88
91
92
. 94
. 99
. 100
. 102
.
.
.
.
.
.
104
106
114
116
117
119
. 122
. 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. . . . . . . . . . . . . . . . . . . .
2.34 Rotazione del mote di 180◦ affinché l’asse X dell’accelerometro sia
prima orientato a -1g e poi a +1g. . . . . . . . . . . . . . . . . . . .
2.35 Grafici delle accelerazioni sull’asse X e sull’asse Y quando il mote
viene ruotato come mostrato in Figura 2.33. . . . . . . . . . . . . .
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.38 Consumo di potenza medio di trasmettitori wireless (in arancione) e
microprocessori (in blu) in tipiche piattaforme BSN. . . . . . . . . .
. 128
. 130
. 131
. 133
. 134
. 138
v
Elenco delle tabelle
1.1
1.2
1.3
1.4
Differenze tra WSN e BSN. . . . . . . . . . . . . . . . . . . . . . . .
Considerazioni su sistemi context-aware. . . . . . . . . . . . . . . . .
Stato dell’arte sul riconoscimento di attività motorie con sensori inerziali
Malattie croniche e i parametri comunemente usati per monitorarle .
Sensori comunemente impiegati in BSN e relativi tassi di trasmissione
tipici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Confronto tra nodi sensore utilizzati in BSN. . . . . . . . . . . . . .
2.3 Classi e rispettive caratteristiche dei dipositivi Bluetooth. . . . . . .
2.4 Confronto tra diverse tecnologie wireless. . . . . . . . . . . . . . . .
2.5 Alcuni degli standard dell’ISO 11073. . . . . . . . . . . . . . . . . .
2.6 Comuni disordini del movimento nel morbo di Parkinson. . . . . . .
2.7 Tipi di tremore e intervalli di frequenze associati. . . . . . . . . . .
2.8 Riassunto delle specifiche dell’ADXL202JE. . . . . . . . . . . . . . .
2.9 Stato dei LED del mote. . . . . . . . . . . . . . . . . . . . . . . . .
2.10 Le 8 caratteristiche che definiscono un sistema autonomico (adattate
da [48]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
18
20
27
2.1
.
.
.
.
.
.
.
.
.
42
44
56
59
89
109
112
115
123
. 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
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 visto 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 intermittente 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̀ offerte 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 domestico, 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 tecnologie 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 differenze del tremore parkinsionano rispetto ad altri tipi di tremore. Verrà poi proposta
l’implementazione di una soluzione che, mediante l’utilizzo di un accelerometro biassale, permetterà di studiare in frequenza i segnali accelerometrici raccolti durante
la simulazione di tremore a differenti velocità. In particolare la frequenza dell’armonica fondamentale del segnale accelerometrico verrà utilizzata come parametro
caratterizzante il tipo di tremore.
Le Conclusioni ripercorreranno le potenzialità delle BSN e le sfide ancora aperte. 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 aumentare 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 vivono 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, cancro, 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 mo4
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 malattie 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 Sensor 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 testuali 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 essere 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 associate 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 impianta6
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 “sistema BSN(BAN)” ad indicare applicazioni e sistemi che utilizzano le Body Sensor
Network.
Lo sviluppo delle BSN, comunque, ha fortemente beneficiato dei notevoli progressi 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’abbigliamento 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 sono 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 è
scelta 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 umano, che presentano in genere un andamento più periodico, e che porta a rate
più stabili per le applicazioni. La grande eterogeneità di dispositivi che compongono 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 trasmissione 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’affidabilità dipende dal data-rate. Con un dispositivo con data-rate basso si
1
Bit 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) Inf ormationRate =
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 interferenze e scongiurare danni alla salute. Bisogna, inoltre, tener conto della
propagazione delle onde nel corpo umano in termini di attenuazione del segnale: 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 richiede 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 dispositivi 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 potenze 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 corpo. 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
2
Energy harvesting (o scavenging) : conversione dell’energia dispersa nell’ambiente, come sottoprodotto di processi artificiali e naturali, in energia elettrica. L’energia inutilizzata o di scarto è
presente ovunque nell’ambiente che ci circonda: luce, vento, differenze di temperatura, onde a
radiofrequenze, energia cinetica dalle onde del mare, dalle vibrazioni meccaniche e dal movimento
umano.
3
Tasso di assorbimento specifico: misura la quantità di potenza da radio frequenze assorbita
dal corpo quando questo è esposto ad un campo elettromagnetico. É definito come la quantità di
energia elettromagnetica che viene assorbita nell’unità di tempo da un elemento di massa unitaria
di 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 manutenersi 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 medici, 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 “ubiquitous” e “pervasive monitoring” 4 di parametri fisici, fisiologici e biochimici in
qualsiasi ambiente e senza vincoli sulle attività che il paziente può compiere è diventato 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
4
Lo ubiquitous computing (o ubicomp) è un modello post-desktop di interazione uomo-macchina
in cui l’elaborazione delle informazioni è stata interamente integrata all’interno di oggetti e attività
di tutti i giorni. Opposto al paradigma del “desktop”, in cui un utente aziona consciamente una
singola apparecchiatura per uno scopo specifico, chi utilizza lo ubiquitous computing aziona diversi
sistemi e apparecchiature di calcolo simultaneamente, nel corso di normali attività, e può anche
non essere cosciente del fatto che questi macchinari stiano compiendo le proprie azioni e operazioni.
13
WSN
Grande tanto quanto l’ambiente da monitorare (metri/chilometri)
Il più grande numero di nodi richiesto per elevata accuratezza e
area di copertura estesa
Sensori multipli, ognuno esegue il proprio compito
Un numero elevato di nodi (ridondanza) compensa l’accuratezza e
permette la validazione dei risultati
Dimensioni piccole preferibili ma non sono una limitazione
stringente in molti casi
Esposti a condizioni ambientali estreme e rumore
Riconoscimento di eventi avversi desiderabile; il fallimento spesso è
reversibile
Maggiori probabilità di avere una struttura fissa
Livello più basso di sicurezza del trasferimento dati senza fili
richiesto
Accessibile e possibilità di essere cambiata più facilmente e
frequentemente
Può essere maggiore in quanto l’alimentazione può essere sostituita
più facilmente
Energia solare ed eolica sono i maggiori candidati
Sensori più facilmente sostituibili o anche usa e getta
Non considerata nella maggioranza delle applicazioni
Non cosı̀ importante in ambienti ben definiti
Bluetooth, ZigBee, GPRS, WLAN. . .
La perdita di dati durante il trasferimento wireless può essere
compensato da ridondanza dei nodi sensori
Differenze
Scala
Numero di nodi
Funzione dei nodi
Accuratezza dei nodi
Dimensioni dei nodi
Dinamica
Detection di eventi
Variabilità
Protezione dei dati
Alimentazione
Potenza richiesta
Energy Scavenging
Accesso
Biocompatibilità
Context Awareness
Tecnologie wireless
Trasferimento dati
Tabella 1.1. Differenze tra WSN e BSN.
del
corpo
umano
Ogni nodo deve
Perdita di dati maggiore (non c’è ridondanza), può richiedere misurazioni addizionali per assicurare QoS e capacità di monitoraggio
real-time
Tecnologie wireless a basso consumo energetico richieste
Molto importante perché i parametri fisiologici sono fortemente
dipendenti da cambiamenti nel contesto
Requisito fondamentale da rispettare sia per sensori esterni che
impiantabili. Può aumentare i costi
Il rimpiazzamento di sensori impiantabili è complesso e richiede
biodegradabilità
Movimenti (vibrazioni) e calore corporeo sono i maggiori candidati
Dovrebbe essere la più bassa possibile siccome l’alimentazione è
poco accessibile
Inaccessibile e difficoltà nella sostituzione per sensori impiantabili
Livello di sicurezza richiesto alto per garantira la privacy del
paziente
Variazioni biologiche implicano una struttura più variabile
Il riconoscimento di eventi avversi è di importanza vitale; il
fallimento è irreversibile
Esposti a un ambiente più prevedibile ma sussiste il problema dei
movimenti corporei
Il monitoraggio pervasivo necessità di miniaturizzazione
Numero di nodi limitato (nessuna ridondaza).
essere robusto e accurato
Sensori singoli, ognuno esegue più compiti
Il più piccolo possibile (limitati dallo spazio) ⇒ richiesti nodi sensori
più accurati
Grande
quanto
le
parti
(millimetri/centrimetri/pochi metri)
BSN
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 paziente, 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’evento 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̀ eccitante 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 utiliz5
dispositivo 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 considerevole 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 comportamento 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 rilevante 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 contextaware.
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 di
voce 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 indossabili 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̀ svolte dall’utente, la temperatura corrente dell’ambiente esterno, ora del giorno,etc.
Più precisamente potremmo distinguere l’informazione contestuale in quella “usercentred”, 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 informazioni “importanti” e “non importanti” nella grande quantita di dati acquisita.
18
Ad esempio, la causa di un rapido incremento del battito cardiaco osservato nell’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 detection 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 rilevamento di movimenti. In questo modo è possibile registrare le attività quotidiane
della persona e utilizzare questa informazione come indicatore del suo stato di salute oppure, come nel caso dell’esempio appena descritto, per contestualizzare i dati
fisiologici acquisiti. D’altra parte le attività fisiche svolte rappresentano un’informazione 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 riconoscimento di 3 attività motorie e, tramite analisi in frequenza, della velocità di esecuzione, 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 classificazione tramite dati raccolti da accelerometri e giroscopi. Le problematiche chiave
affrontate in tali studi riguardano in particolare:
6
Misura della potenza del segnale alla ricevente
19
Attività riconosciute
8: stare in piedi, camminare, correre, salire/scendere le
scale, lavarsi i denti, alzarsi,
usare l’aspirapolvere.
20: camminare, sedersi, leggere, lavorare al Pc, usare
l’aspirapolvere ecc.
8: sedersi, correre, accucciarsi, camminare, stare in piedi, avanzare gattoni, sdraiarsi,
muovere la mano.
Diverse attività per diverse
configurazioni del nodo.
4: statiche (riposare, sedere, stare in piedi), dinamiche
(camminare).
4: inizio moto, fine moto,
camminare, salire le scale.
Riferimento in letteratura
Ravi, Dandekar, Activity Recognition from Accelerometer Data, Rutgers University,
2005
Bao, Intille, Activity Recognition from User Annotated
Data, MIT, 2004
Olguin, Pentland, Human Activity Recognition: Accuracy
across Common Locations for
Wearable Sensors, MIT, 2006
Foerster, Motion Pattern and
Postures, Assessed by Calibrated Accelerometers, Freiburg University, 2000
Aminian, Capturing Human
Motion Using Bodyfixed Sensors: Outdoor Measurement
and Clinical Applications,
Swiss Institute of Technology,
2004
Mantyjarvi et al., Recognizing
Human Motion with Multiple Acceleration Sensors, Oulu University, Finland (Nokia
lab), 2001
Markov
Reti neurali
Patter
motori,
transizione
di
postura
Analisi delle transizioni tra stati
Hidden
Models
Albero di decisione
Meta Classifiers
with
Plurality
Voting
Metodo di classificazione
2: anca.
1: busto.
Diverse possibilità
analizzate.
3: polso destro,
coscia sinistra, busto.
3: coscia, anca,
polso.
1: posizionato in
zona pelvica.
Nr. dispositivi
indossati
Tabella 1.3. Stato dell’arte sul riconoscimento di attività motorie con sensori inerziali
PCA, ICA per
la
generazione
del vettore delle
feature
Accelerazione verticale.
Accelerazioni pure.
Media, varianza,
accelerazioni pure.
Media, energy, entropia, correlazione.
Media, deviazione, standard, correlazione, energia.
Attributi
dei dati per
classificare
Dispositivi collegati con cavi.
Singolo dispositivo con accelerometro e giroscopio collegato via cavo a un dispositivo
di salvataggio dati (Physilog
Data Logger) per successiva
analisi.
Accelerometri collegati con un
dispositivo di salvataggio di
tipo Vitaport2.
Dispositivi ad hoc chiamati
MITes.
Dispositivo ad hoc con funzionalità di comunicazione radio e di salvataggio su memoria CompactFlash. Integra un
accelerometro biassiale.
Dispositivo ad hoc con capacità di comunicazione senza
fili tramite Bluetooth.
Specifiche dei dispositivi
utilizzati
20
• la quantità e la posizione dei sensori indossati;
• la definizione del processo necessario per trasformare delle primitive informazioni riguardanti l’accelerazione in classi di movimento.
La Tabella 1.3 offre una panoramica su alcune delle applicazioni sviluppate riguardanti 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 sviluppare 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 memoria. 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.
7
L’elettromiografia misura i potenziali elettrici che si formano in un muscolo durante la sua
contrazione 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 livello 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. Automatizzare 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
8
In informatica si distingue tra tecnologie wired e wireless. Nelle prime i dispositivi comunicano
tramite cavi, nelle seconde con trasmissioni RF
9
Un aneurisma è una dilatazione progressiva di forma varia, generalmente sacculare, di un
segmento 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’ambiente
in 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 popolazione “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 assistenza 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 sviluppo
lento o nullo e senza alcuna manifestazione clinica. I sintomi quindi sono nella grande maggioranza dei casi associati alla rottura della sacca aneurismatica, che generalmente avviene in modo
improvviso 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 paziente 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’individuo. 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 membri della famiglia sono geograficamenti lontani dall’anziano, permette ancora ai familiari 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’assistenza 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 apprezzata 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 accordo 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’ipertensione 10 .
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 trattamenti. 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 numerose volte. Si può facilmente immaginare quanto “labour-intensive” possa essere
10
L’ipertensione arteriosa è un aumento a carattere stabile della pressione arteriosa nella
circolazione
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 abitudini 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 pazienti 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 biochimico 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 sono 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.
11
12
Valore della concentrazione di glucosio nel sangue.
Strumento per la misurazione del tasso di glicemia nel sangue
26
Pressione
sanguigna
impiantabile / indossabile)
Elettrocardiogramma (sensore ECG impiantabile /indossabile)
Frequenza di battito, pressione sanguigna, ECG (meccanorecettore impiantabile /indossabile e sensore ECG)
Perdita di peso (sensore di grasso corporeo) (meccanorecettore
impiantabile / indossabile)
Respirazione, picco del flusso respiratorio, saturazione ossigeno
(meccanorecettore impiantabile / indossabile)
Andatura, tremore, tono muscolare, attività (EEG indossabile,
accelerometro, giroscopio)
Attività, memoria, orientamento,
tro / giroscopio indossabile)
Andatura, tono muscolare, attività, disturbi del linguaggio,
memoria (EEG indossabile, accelerometro, giroscopio)
Riduzione
della
vista,
disturbi
(accelerometro / giroscopio indossabile)
Rigidità comune, funzioni ridotte,
giroscopio, termistore indossabile)
Urina (sensore di pressione e di volume della vescica impiantabile)
Perfusione periferica, pressione sanguigna, pressione della sacca
aneurismatica (sensore impiantabile /indossabile)
Temperatura corporea (termistore indossabile)
Frequenza cardiaca, pressione sanguigna, ECG, saturazione
ossigeno, febbre (sensore impiantabile / indossabile e sensore
ECG)
Ipertensione
Cardiopatia ischemica
Aritmia
Cardiaca / Insufficienza
cardiaca
Cancro (seno, prostata,
polmoni, colon)
Asma
Morbo di Parkinson
Morbo di Alzheimer
Ictus
Diabete
Artrite reumatoide
Insufficienza renale
Malattia vascolare (periferica e aneurismi)
Malattie infettive
Monitoraggio
post-operazione
sensoriali
(accelerome-
febbre (accelerometro,
cognizione
(meccanorecettore
Parametri fisiologici (Tipo di sensore BSN)
Patologie
metaboliti
Emoglobina, glucosio nel sangue, monitoraggio nella parte
interessata dalla operazione
Marker infiammatori, numero globuli bianchi,
patogeni (biosensore impiantabile)
Livello di emoglobina (biosensore impiantabile)
Urea, creatinina, potassio (biosensore impiantabile)
Fattore reumatoide, marker infiammatori (sensore impiantabile)
Glucosio nel sangue, emoglobina glicata (biosensore impiantabile)
Diffusione di betamiloide (cervello) (biosensore impiantabile / EEG)
Livello di dopamina nel cervello (biosensore impiantabile)
Pressione parziale dell’ossigeno ((sensore ottico impiantabile / indossabile, sensore impiantabile)
Marker tumorali, rilevamento di sangue (urina,feci,saliva)
(biosensori impiantabili)
Troponina, creatinina chinasi (biosensore impiantabile)
Troponina, creatinina chinasi (biosensore impiantabile)
Adrenocorticosteroidei (biosensore impiantabile)
Parametri biochimici (Tipo di sensore BSN)
Tabella 1.4. Malattie croniche e i parametri comunemente usati per monitorarle. I tipi di sensori suggeriti per la misurazione di questi
parametri sono elencati tra parentesi. Tutte queste patologie attualmente rappresentano un peso economico elevato per il Sistema Sanitario,
peso che potrebbe essere ridotto se queste malattie fossero prontamente diagnosticate.
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 significa 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 sanitaria. Accanto alle applicazioni mediche una WBAN può essere utilizzata in applicazioni 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 videogiocatore 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 “WiiMote”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
13
Il controller del Nintendo Wii, console per videogiochi prodotta da Nintendo.
29
Figura 1.12. (Sinistra) Accelerometro, reso impermeabile, montato sugli occhialini del
nuotatore. (Destra) Sistema di coordinate geocentriche (X, Y, Z), sistema di coordinate
per 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’accelerometro posizionato in differente aree del corpo per rilevare posture specifiche.
Con questa tecnologia, atleti che praticano gli sport più svariati possono facilmente migliorare le loro performance ed evitare infortuni dovuti a posture
scorrette assunte durante i movimenti. In [13], una BAN è usata per determinare 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 dell’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 accelerometro 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 nella scarpa. (Destra) Accelerometro sulla sinistra e ricevente da connettere all’Ipod sulla
destra.
e “split-times” possono essere derivati.
Diverse sono anche le soluzioni commerciali già proposte nel mercato dell’hightech. 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 fornisce 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: informazioni 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 Soldiers During Field Training. Nell’addestramento sul campo dei soldati, e in
situazioni reali, restrizioni sul cibo e condizioni ambientali estreme sono comuni. Una rete di sensori wireless è necessaria per monitorare in ogni momento
la situazione corrente. Questo scopo è raggiunto da SPARNET attraverso l’utilizzo 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, ridurre 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 riconoscimento biometrici che utilizzano caratteristiche biologiche e/o comportamentali quali il riconoscimento facciale, vocale, impronte digitali, riconoscimento dell’iride etc. Il problema potenziale di falsificazione e duplicabilità
ha, tuttavia, portato ad investigare sull’utilizzo di nuove caratteristiche fisicocomportamentali del corpo umano, come ad esempio l’EEG14 unito all’impiego
14
L’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 guidatore come ad esempio l’espressione facciale (tempo di battito delle ciglia,
sbadigli, movimenti della testa, flessione del mento. . . ). Anche dati fisiologici come variabilità del battito cardiaco, EEG, possono essere utilizzati
per determinare il livello di attenzione del guidatore. Altri segnali fisiologici 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 progettare, 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 diventa 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 variazioni
del voltaggio nel tempo.
15
Per aumentare la sicurezza del sistema di riconoscimento si possono utilizzare più tecniche
biometriche. Questi sistemi permettono un riconoscimento più preciso e diminuiscono il tasso di
errore.
16
L’elettrooculografia è un esame che utilizza degli elettrodi applicati intorno agli occhi che
rilevano 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 biosensori 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 stato 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 momento 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 sensori 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 persona, 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, temperatura. . . ). 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 esterno. 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 degli
accelerometri MEMS paragonata alla punta di un fiammifero.
2. Sensori chimici: questo tipo di sensori consente di convertire grandezze chimiche in grandezze meglio trattabili, come sono quelle elettriche. Un sensore 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 (chetoni,aldeidi. . . ) che sono indicatori di alcune malattie quali diabete, ulcere
e cancro allo stomaco. Inoltre sono utilizzati estensivamente per la misurazione dell’inquinamento ambientale (aria, acqua. . . ). Nel prossimo futuro,
dunque, i sensori chimici, potranno essere utilizzati all’interno di BSN per raccogliere 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 biologicamente 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 Figura 2.1 è mostrata la grandezza di alcuni accelerometri MEMS rispetto alla
punta di un fiammifero. Date le loro ridotte dimensioni sono ormai ampiamente utilizzati nell’Activity Recognition e in applicazioni quali realtà virtuale,
giochi elettronici etc.
Nella maggior parte degli accelerometri, il principio di funzionamento è il medesimo: si basa sulla rilevazione dell’inerzia di una massa quando viene sottoposta ad una accelerazione. La massa viene sospesa ad un elemento elastico,
mentre un qualche tipo di sensore ne rileva lo spostamento rispetto alla struttura 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 spostamento 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̀ armature, che possono oscillare attorno ad una posizione di equilibrio, provocando
variazioni capacitive1 . Tali variazioni sono dell’ordine di 10−18 ÷ 10−21 F e possono 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.
1
La capacità elettrica di un condensatore cambia al variare della distanza tra le sue armature
Il 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 piezoresistenza: un particolare elemento resistivo segue le deformazioni della superficie di un elemento
sensore a cui è fissato; queste deformazioni (tipicamente allungamenti e accorciamenti) causano una
variazione della resistività elettrica del materiale del resistore, e di conseguenza la sua resistenza
elettrica.
2
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 temperatura (termocoppie). Quando l’accelerazione è nulla il gradiente di temperatura 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 perturbazione e il segnale in uscita dall’accelerometro sarà quindi proporzionale a questa
differenza.
Attraverso la combinazione di accelerometri MEMS sensibili a una sola direzione nel piano è possibile ottenere accelerometri biassali (integrando due
dispositivi perpendicolarmente) e triassali.
Lo giroscopio, invece, utilizza il principio di conservazione del momento angolare 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 concentrazione di ossigeno durante la respirazione (Figura 2.3 in alto a destra).
• Sensore ECG: Registra l’attività elettrica del cuore. Per ottenere l’ECG diversi 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 materiale 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 contraggono 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 mu40
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 ossigeno 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 emoglobina 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 della 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
Glucometro
Pressione sanguigna
Sensore CO2
Sensore ECG
Sensore EEG
Sensore EMG
Pulsossimetro
Sensore di umidità
Sensore di temperatura
Immagini/Video
Stella
Stella
Stella
Stella
Stella
Stella
Stella
Stella
Stella
Stella
P2P
Alto
Alto
Basso
Molto
Alto
Alto
Molto
Basso
Molto
Molto
Molto
basso
Alto
Basso
Basso
Alto
In Tabella 2.1 sono mostrati i sensori comunemente utilizzati in BAN, la topologia tipicamente impiegata e i tassi di trasmissione in gioco.
I progressi nella tecnologia MEMS, nella miniaturizzazione delle sorgenti di energia 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 impiantabili 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 sempre 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 Mote, 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 convertitore 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 focalizzandosi 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
Sistema
Operativo
Standard
Wireless
Data Rate
(kbps)
Copertura
Outdoor
(m)
Consumo
Energetico
BAN node
TinyOS
250
50
Basso
BTNode
eyesIFX
iMote
iMote2
–
64
720
250
–
–
30
30
Basso
Basso
Basso
Basso
IRIS
TinyOS
TinyOS
TinyOS
TinyOS
.NET
TinyOS
250
300
Basso
Micaz
TinyOS
250
75-100
Basso
Mica2
TinyOS
38,4
>100
Basso
Mulle
TCP/IP
TinyOS
–
>10
Basso
TelOS
TinyOS
250
75-100
Basso
ZigBit
ZDK
IEEE
802.15.4
Bluetooth
TDA5250
Bluetooth
IEEE
802.15.4
IEEE
802.15.4
IEEE
802.15.4
IEEE
802.15.4
Bluetooth
IEEE
802.15.4
IEEE
802.15.4
IEEE
802.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 tipicamente 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’analisi, 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 progettato (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 sistema di comunicazione in componenti. Per meglio affrontare il problema, in riferimento 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 BSN
per 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’applicazione e i suoi requisiti; alcune applicazioni, ad esempio, potrebbero non prevedere
affatto la comunicazione beyond-BAN o inter-BAN. Customizzando ognuno dei livelli 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 scalabilità ma anche sul consumo energetico. L’approccio migliore è quello di
46
Figura 2.6. Architettura della comunicazione intra–BAN: (a) wired; (b) direttamente
connesso all’AP; (c) wireless; (d) ibrida; (e) cluster & wireless
mantenere al minimo il routing e trasmettere solo quando assolutamente necessario;
• 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’a47
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’utilizzo 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 scenario 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 Qualità 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) Modalità
infrastruttura; (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 sensori corporali a trasmettere informazioni all’interno del centro medico. Il servizio di
copertura, quindi, è intrinsecamente superiore rispetto alla soluzione ad infrastruttura, 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 connettere le BSN a WSN ambientali. Il concetto di monitoraggio pervasivo del paziente
rappresenta certamente l’innovazione più forte che le BSN hanno reso possibile. Come 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̀ solidale con gli spostamenti dell’utente. Nel seguito faremo riferimento ai nodi di una
e dell’altra rispettivamente come sensori mobili e sensori ambientali. Per connettersi 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. Nell’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 copertura e abilitando il personale medico ad accedere in remoto a informazioni sul
paziente utilizzando la rete cellulare o Internet. Un database che mantiene i profili 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 protocolli 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 indossata 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 reti
wireless.
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
Classe 1
Classe 2
Classe 3
Potenza (mW)
Potenza (dBm)
Copertura (m)
100
2,5
1
20
4
0
100
10
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 tipo 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 interferenze 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 dispositivi 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 operazioni 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 stessa 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 pacchetti 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 master 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 device non conosce alcuna informazione sul bluetooth remoto esegue rispettivamente
lo stato di inquiry, che permette di fare uno scan e localizzare dispositivi raggiungibili 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
Bluetooth
802.11
UWB
250 Kbps
3 Mbps
11 Mbps
>100 Mbps
7 mA
22 mA
160 mA
2 mA
Basso
Medio
Alto
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-lowpower” 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 implementazioni: single-mode e dual-mode. Nell’implementazione single-mode i dispositivi 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 standalone (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 adattativo 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 connessione di un numero enorme (232 ) di dispositivi. La tecnologia è ottimizzata
per connessioni uno-a-uno ma permette anche connessioni uno-a-molti utilizzando 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,
3
Una modalità in cui uno slave può trovarsi è lo sniff-mode. Lo slave che passa in questo stato si
trova in una modalità di risparmio energetico. Per entrare nello sniff mode, master e slave devono
negoziare due parametri: uno sniff interval ed uno sniff offset. Con il primo si fissano gli slot di
sniff, mentre con il secondo si determina l’istante del primo slot di sniff. Quando il collegamento
entra in sniff mode, il master può inviare pacchetti solamente all’interno degli sniff slot. Quindi
lo slave ascolta il canale ad intervalli ridotti. Lo sniff subrating abilita i dispositivi a mettersi
d’accordo sul tempo da aspettare tra l’invio, e quindi ascolto, di messaggi. Questa tecnica può
aumentare 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 “discoverable”, 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 dispotivo 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 rispetto 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 contenute nel pacchetto inviato dal dispositivo master che ha avviato la connessione 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 parametri 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 messaggio di ACK solo quando assolutamente necessario.
62
Figura 2.11. BSN che utilizza Bluetooth + Health Device Profile (Fonte: Bluetooth
SIG).
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 personali 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 Classic + “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 definiscono 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 (canale 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 servizi, 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 fisico. 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 disassociazione, supportare la cifratura MAC, utilizzo del meccanismo CSMA/CA
unslotted/slotted4 per l’accesso al canale, allocazione e gestione di “guarented time
slot” (GTS).
4
Il Carrier Sense Multiple Access with Collision Avoidance viene utilizzato per evitare collisioni
sul canale. Quando un device vuole utilizzare un canale verifica se questo è libero; in caso affermativo comunica alle altre stazioni la sua intenzione di trasmettere, aspetta un tempo casuale e
se 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 i
periodi di backoff sono allineati agli slot del superframe si parla di slotted CSMA-CA, altrimenti
di unslotted CSMA-CA. Quindi nel caso unslotted i periodi di backoff di un dispositivo non sono
sincronizzati 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, aknowledgement 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̀ “beaconenabled” e “non-beacon-enabled”. In modalità beacon-enabled è utilizzata una superframe (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 uscen66
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 dispositivo 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 consente 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, aggiungendosi 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 Applicazione, 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 millisecondi (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 multihop 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 “reducedfunction” (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 prossimità, 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 trasmettitori), 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 si5
Un FFD è un router quando partecipa in una rete ZigBee non come coordinatore ma può agire
come coordinatore nel suo “personal operating space”. Un router è capace di routing dei messaggi
tra 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 particolare 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 estremamente 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 risolvere 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’utilizzo 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 pubblicato. Lo standard ha, dunque, intenzione di adottare come soluzione componenti
elettronici di nuova generazione. Tuttavia, attualmente ancora non è dato sapere 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 realtime (RTOS) o basta un semplice scheduler. Una piccola applicazione può non
71
richiedere un sistema operativo real-time completo; un loop continuo che provveda “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 operativo, 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’applicazione 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, co72
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 configurazione; 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 asincrono, 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 interferenze 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’esecuzione 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 maniera 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̀ complesse 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 potrebbe, 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 strettamente 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 nuovamente 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 automatico 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 matematico 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 portato 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 appartenevano 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 difficile l’integrazione delle nuove applicazioni BSN con le tecnologie già esistenti nelle
strutture ospedaliere. É proprio la necessità di dover comunicare con le tecnologie esistenti che rende necessario l’utilizzo degli standard già in uso. In aggiunta
nel monitoraggio continuo del paziente un ulteriore contributo potrebbe essere dato da tutti quei dispositivi che attualmente vengono ampiamente utilizzati nella
vita quotidiana e che non sono stati necessariamente pensati per applicazioni mediche, ad esempio sistemi per l’home fitness. Infine la situazione attuale in cui esiste
una grande eterogeneità di dispositivi rende difficile sostituire qualsiasi dispositivo (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 sistema senza modificare l’intera architettura. Per riuscire in questo è necessario uno
standard globalmente accettato che fornisca operazioni standard, permetta l’interoperabilità 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 caratteristiche 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) definisce 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 modellata come un oggetto; ogni oggetto ha in sé una serie di attributi, per esempio
6
Electronic Health Record (Cartelle cliniche integrate) è un insieme di informazioni digitali con
i 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), i
risultati dei test di laboratorio, le immagini radiologiche e i consigli terapeutici.
79
l’oggetto paziente conterrà gli attributi dati anagrafici, data di ricovero etc. Definiti 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 meccanismo di consegna del C-MOVE;
• C-Move: Serve per ordinare al Service Class Provider il trasferimento dell’oggetto eventualmente restituito dalla query C-Find;
• C-Get, C-Echo;
Le operazioni comprese nella classe DIMSE-N sono N-Get, N-Action, N-Set, NCreate, 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 osserviamo 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 venga 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 possano 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 archiviazione 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’ambiente 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 condivise 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 applicazioni. 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 sanitario 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 definite 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 formattazione 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 Type. 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 possono contenere Componenti (Data Elements) e Sotto-Componenti (Sub-Sub-Fields).
In particolare HL7 è “order-sensitive”, ovvero i campi dati sono individuati nel messaggio 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 messaggio principale e riceve un messaggio di riconoscimento, mentre il sistema ricevente 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 messaggio 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 principale è stato appunto la standardizzazione dei messaggi, e che attualmente è ancora
ampiamente utilizzato. Tuttavia, nel tempo ha mostrato diversi limiti e in particolare l’assenza di un supporto esplicito per le nuove tecnologie come Object Technologies, 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 compatibilità tra i sistemi che lo hanno adottato. Purtroppo nella pratica i fornitori software
non aderiscono strettamente allo standard e un’applicazione progettata per comunicare 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 applicazione 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 vecchio 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)
Livello
OSI
Parte
Titolo / Contenuto
00000
Health Informatics - Point-of-care medical device communication - Framework and overview
Health Informatics - Personal health device communication - Technical report - Overview
00103
7
1yyzz
10101
10201
10300
10302
10304
10306
10307
10310
10400
10404
10406
10407
10408
10417
7–5
2yyzz
20101
20102
20201
20202
20601
Data & Information Definitions
Health Informatics - Point-of-care medical device communication - Nomenclature
. . . - Domain information model (DIM)
. . . - Device specialization Framework and overview
. . . - Vital signs monitor
. . . - Pulse oximeter
. . . - ECG monitoring
. . . - Blood pressure
. . . - Cardiac output
Health Informatics - Personal health device communication - Device specialization - Common framework
. . . - Pulse oximeter
. . . - Heart rate monitor
. . . - Blood pressure monitor
. . . - Thermometer
. . . - Glucose meter
Application profiles
Health Informatics - Point-of-care medical device communication - Application profiles - Base standard
. . . - Mib elements
. . . - Polling mode profile
. . . - Baseline profile
Health Informatics - Personal health device communication - Application profile - Optimized exchange
protocol
4–1
3yyzz
Transport and physical profiles
1
4yyzz
Physical layer interface
3
5yyzz
Internetworking support
4
6yyzz
Application gateways
9yyzz
Related concepts
Stato
D
N
P
P
D
D
D
D
D
D
N
P
D
P
P
P
P
D
D
D
S
89
L’intera parte è formata da Nomenclatura, Dispositivi generici e “Virtual Medic Device Specialization” (VMD) che insieme vanno a formare il MDDL. La
nomenclatura standard (ISO 11073-10101) comprende un set di codici numerici che identificano ogni elemento che è comunicato tra sistemi. La parte
Dispositivi generici corrisponde a una serie di modelli generici di oggetti usati 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 monitoraggio 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, Associazione, Configurazione, Funzionamento. Si noti lo scambio della MDIB
nella fase di configurazione. Il MIDB caratterizza completamente un dispositivo 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 servizi, 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 Polling 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 durante 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 permettono 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 trasparenza 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 precedentemente, sono stati inizialmente pensati e progettati per applicazioni in ambito ospedaliero 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 utilizzano 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 minimizzare 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 generalmente piccoli, poco costosi, alimentati a batteria e che offrono poco in termini 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”. Essi definiscono i messaggi che viaggiano tra Agenti e Manager ma non come
questi messaggi dovrebbero essere trasmessi, assumendo che un livello di trasporto (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 paradigma 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̀ illustrato 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’Agente – 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’Abstract Syntax Notation One (ASN.1). ASN.1 è una notazione internazionalmente 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.
7
BER è il nome comune con cui vengono definite le regole di codifica di base, o appunto Basic
Encoding Rules, di ASN.1. BER è un insieme di regole per la codifica dei dati ASN.1 in un flusso di
ottetti che può essere trasmesso attraverso un collegamento di comunicazione, ovvero mappano la
sintassi astratta sulla sintassi di trasferimento. La differenza tra ASN.1 e BER può essere chiarita
con la seguente similitudine: ASN.1 è come un linguaggio di programmazione, mentre BER è come
un compilatore per quel linguaggio.
96
Si potrebbe pensare di utilizzare anche XML invece di ASN.1; i messaggi 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 quali 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 identifica 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 inviare 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 contiene 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 Domain 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 Manager 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 possa 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 associazione (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 complessi 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 bilancia 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 configurazione 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 Configurable 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’informazione “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 al
PM-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 manager 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 memorizzazione 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 PMSegment 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 avviare 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̀ descritto con uno statechart diagram. Vengono definiti gli stati e sottostati che una
coppia Agente e Manager attraversa, inclusi gli stati relativi alla connessione, associazione 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 monitoraggio 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 engine” (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 interoperabilità (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 centrale, 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 tremore. 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
Acinesia
Episodi di freezing
Bilanciamento
e controllo della
postura ridotto
Discinesia
Tremore
Rigidità
Velocità e ampiezza ridotta dei movimenti, difficoltà ad iniziare un movimento. Nei casi estremi è conosciuta come “ipocinesia”, a sottolineare la
riduzione significativa di movimenti spontanei del corpo.
Carenza o scomparsa dei movimenti volontari accompagnata dalla totale
mancanza di espressioni sul viso.
Blocchi motori improvvisi durante l’esecuzione di una sequenza di
movimenti.
Difficoltà a mantenere la posizione eretta in seguito a un movimento del
centro di massa o con gli occhi chiusi; difficoltà a mantenere anche la
stabilità in posizione seduta o durante il movimento da una posizione
all’altra.
Movimento anormale e involontario dei muscoli del corpo.
Tipicamente tremore a riposo; più raramente tremore posturale o
d’azione.
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 condizionato, 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 movimento 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 compilare 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 diventa 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 2 m3 , 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̀
8
Levodopa: precursore della dopamina che, a differenza di quest’ultima, supera agevolmente la
barriera ematoencefalica e per questo utilizzato per correggere il deficit di dopamina del morbo di
Parkinson.
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 quantitativa applicato ai sintomi del morbo di Parkinson, deve essere in grado di distinguere fra numerosi stati motori; in particolare è necessario che possa differenziare
i movimenti volontari dalle discinesie durante la fase on, e l’acinesia dall’immobilità volontaria durante la fase off. Questo pone l’esigenza di individuare specifici
parametri e tecniche di classificazione che procurino ai medici un’oggettiva caratterizzazione 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 incominciano 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 possono 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)
Normale tremore della mano
Tremore essenziale
Morbo di Parkinson
Lesioni cerebrali
9–25
4–12
3–8
1,5–4
Note
Piccola ampiezza
Tremore posturale e di azione
Tremore a riposo
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 riposo 9 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.
9
si presenta a un’estremità poggiata su una superficie
112
Diverse sono le tecniche finora utilizzate per l’analisi del tremore. Si è già accennato a sistemi di analisi ottica. In [42] lo studio del tremore è condotto attraverso 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 “everywhere” 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 funzionalità 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̀ influenzare 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 vibrazione 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 raccogliere 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 sensibilmente 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̀ certamente un ottimo esempio per mostrare la possibilità di poter condurre con dispositivi 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 sperimentazioni occorrono degli strumenti hardware e software. L’hardware consiste nei sensori
Iris Mote, in una programming board necessaria per poter flashare il codice sui sensori, 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 Crossbow 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
Range
Sensibilità
Risoluzione
Offset
Range operativo
Interfaccia
X (ADC1), Y (ADC2)
±2 G (1 G = 9,81 m/s2 )
167 mV/G, ±17%
2 mG (0,002 G) RMS
VBATTERY/2 ±0,4 V
3,6 a 3,0 V
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 hanno un’ampia tolleranza iniziale e una semplice calibrazione può essere fatta utilizzando 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 operativo. 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 programmazione creato dalla MathWorks. MATLAB consente di manipolare matrici,
visualizzare funzioni e dati, implementare algoritmi, creare interfacce utente e interfacciarsi 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 successivamente);
• 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 collegate 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 componente 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 senza 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: vengono 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
GREEN On
RED Toggle
YELLOW Toggle
GREEN Toggle
Significato
Inizializzazione
Colpo di clock
Invio eseguito
Invio fallito
delle prime e i comandi delle seconde. In Figura 2.31 è mostrato il flusso di eventi 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 splitphase. 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 possono avviare le letture delle accelerazioni. Bisogna dunque avviare il clock software
che temporizza gli istanti di campionamento. Ad ogni colpo di clock verrà generato un Evento2. L’implementazione dell’Evento2 prevederà la chiamata a funzione
che avvierà il campionamento dell’accelerazione sull’asse X. Anche questa operazione 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 funzione 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 le
accelerazioni; (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 utilizzata 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 vengono 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 soltanto 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 velocizzare 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 documentazione fornita dalla Crossbow:
Accelerazione in mg =
calib pos1g − AccelData
1, 0 −
scale f actor
× 1000
dove
AccelData = valore in uscita all0 ADC
scale f actor =
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 riferimento. Questi valori possono variare sensibilmente tra diversi accelerometri e dunque
non esistono valori universali da poter utilizzare; l’unico modo per ottenere una calibrazione 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 prima
orientato 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 entrambi 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
10
L’accelerometro può anche essere utilizzato come inclinometro poiché su entrambi gli assi
sussiste 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 completamente 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’accelerazione 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̀ quella 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 prima
orientato 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 viene
ruotato 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
11
La trasformata di Fourier veloce (indicata come FFT, dall’inglese Fast Fourier Transform) è
un 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 un
tremore 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 un
tremore 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 motivazione 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 tecniche 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 monitoraggio 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 permesso 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̀ fondamentale nella progettazione. I biosensori devono essere costituiti da materiali
biocompatibili che evitano irritazione e reazioni allergiche. Per sensori impiantabili questo è essenziale per scongiurare il pericolo di infiammazioni e
risposte avverse del sistema immunitario. Tuttavia, le stesse tecniche costruttive che garantiscono la biocompatibilità possono essere fonte, talvolta, del
fallimento del sensore stesso. I biosensori, inoltre, sono spesso affetti da rumore 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 sviluppo di sensori fisiologici e attuatori miniaturizzati, quali ad esempio somministratori di farmaci. Continuare a muoversi in questa direzione sarà fondamentale 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 pervasivo. Le sfide più difficili riguardano le dimensioni e la durata delle batterie,
che attualmente sono la fonte di energia principale per i nodi. Normali batterie 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 superiori a quelle di una batteria a litio e in dimensioni più piccole. I progressi
in queste nuove tecnologie permetteranno la completa sostituzione delle batterie 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) e
microprocessori (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, tuttavia, 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 certamente 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 trasmettere 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 processing in situ risolve anche i problemi di errate classificazioni dovute a errori nel
pacchetto.
I vantaggi dell’elaborazione dei segnali direttamente a bordo sensore introducono 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 risultati 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 sistema 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 avversi 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 classificatori 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
Selfmanagement
Un sistema autonomico necessita di avere dettagliata conoscenza dei suoi componenti, stato corrente, capacità, e tutte le connessioni ad altri sistemi per
gestire se stesso.
Selfconfiguration
Un sistema autonomico può automaticamente e dinamicamente configurare e
riconfigurare se stesso sotto diverse condizioni e cambiamenti dell’ambiente.
Selfoptimisation
Un sistema autonomico può costantemente ottimizzare le sue performance e
l’utilizzo delle risorse attraverso il monitoraggio dei suoi componenti al fine di
raggiungere predeterminate performance e utilizzo delle risorse.
Self-healing
Un sistema autonomico può recuperare da routine e eventi straordinari che
causano il malfunzionamento dei componenti. É capace di scoprire problemi
e utilizzare risorse e/o configurazioni alternative per assicurare le funzionalità
del sistema.
Self-protection
Un sistema autonomico deve essere capace di identificare differenti tipi di
attacco per assicurare integrità e sicurezza totale del sistema.
Selfadaptation
Un sistema autonomico deve essere context-aware e adattare se stesso per migliorare l’interazione e le performance in seguito a cambiamenti dell’ambiente
di lavoro e dei requisiti utente.
Selfintegration
Un sistema autonomico può funzionare normalmente con infrastrutture eterogenee ed essere integrato perfettamente e in maniera sicura con altri
sistemi.
Self-scaling
Un sistema autonomico anticiperà l’ottimizzazione delle risorse richieste e scalerà le sue funzionalità mantenendo comunque nascosta la sua complessità
all’utente.
micro sensori che li compongono diventa un compito difficile. Questo problema può essere risolto attraverso il concetto di autonomic sensing. L’autonomic 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
12
L’Autonomic Computing è un’iniziativa avviata dall’IBM nel 2001. Il suo scopo è quello di
fornire ai computer gli strumenti necessari per auto-gestirsi senza l’intervento umano. In un sistema
auto-amministrato, l’operatore umano non deve controllare il sistema direttamente ma definisce
politiche generali a regole date in input al processo di auto-gestione.
140
garantire funzionalità di storage a lungo termine in applicazioni che non richiedono 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 batteria. 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
IRIS
WIRELESS MEASUREMENT SYSTEM
• 2.4 GHz IEEE 802.15.4, Tiny
Wireless Measurement System
• Designed Specifically for Deeply
Embedded Sensor Networks
• 250 kbps, High Data Rate Radio
RoHS
COMPLIANT
• Wireless Communications with
Every Node as Router Capability
• Expansion Connector for Light,
Temperature, RH, Barometric Pressure, Acceleration/Seismic,
Acoustic, Magnetic and other
Crossbow Sensor Boards
IRIS
The IRIS is a 2.4 GHz Mote module
used for enabling low-power, wireless
sensor networks. The IRIS Mote
features several new capabilities that
enhance the overall functionality of
Crossbow’s wireless sensor networking
products.
Applications
• Indoor Building Monitoring and
Security
• Acoustic, Video, Vibration and
Other High Speed Sensor Data
Product features include:
• Up to three times improved radio
range and twice the program
memory over previous MICA Motes
• Large Scale Sensor Networks
(1000+ Points)
• Outdoor line-of-sight tests have
yeilded ranges as far as 500
meters between nodes without
amplification
• IEEE 802.15.4 compliant RF
transceiver
• 2.4 to 2.48 GHz, a globally
compatible ISM band
• Direct sequence spread spectrum
radio which is resistant to RF
interference and provides inherent
data security
• 250 kbps data rate
• Supported by MoteWorks™ wireless sensor network platform for reliable,
ad-hoc mesh networking
• Plug and play with Crossbow’s
sensor boards, data acquisition
boards, gateways, and software
MoteWorks™ enables the development
of custom sensor applications and is
specifically optimized for low-power,
XM2110CA Block Diagram
battery-operated networks. MoteWorks
is based on the open-source TinyOS
operating system and provides reliable,
ad-hoc mesh networking, over-theair-programming capabilities, cross
development tools, server middleware
for enterprise network integration and
client user interface for analysis and
configuration.
Processor & Radio
Platform The XM2110CA is based on the Atmel
ATmega1281. The ATmega1281 is a
low-power microcontroller which runs
MoteWorks from its internal flash
memory. A single processor board
(XM2110) can be configured to run
your sensor application/processing and
the network/radio communications
stack simultaneously. The IRIS 51-pin
expansion connector supports Analog
Inputs, Digital I/O, I2C, SPI and UART
interfaces. These interfaces make it
easy to connect to a wide variety of
external peripherals.
Sensor Boards
Crossbow offers a variety of sensor
and data acquisition boards for the
IRIS Mote. All of these boards connect
to the IRIS via the standard 51-pin
expansion connector. Custom sensor
and data acquisition boards are also
available. Please contact Crossbow for
additional information.
Document Part Number: 6020-0124-01 Rev A
Phone: 408.965.3300
Fax: 408.324.4840
E - m a i l : i n f o @ x b o w. c o m
We b : w w w. x b o w. c o m
143
Processor/Radio Board
XM2110CA
Remarks
Processor Performance
Program Flash Memory
128K bytes
Measurement (Serial) Flash
512K bytes
RAM
8K bytes
> 100,000 Measurements
Configuration EEPROM
4K bytes
Serial Communications
UART
0-3V transmission levels
Analog to Digital Converter
10 bit ADC
8 channel, 0-3V input
Other Interfaces
Digital I/O,I2C,SPI
Current Draw
8 mA
Active mode
8 µA
Sleep mode (total)
Frequency band1
2405 MHz to 2480 MHz
ISM band, programmable in 1 MHz steps
Transmit (TX) data rate
250 kbps
RF power
3 dBm (typ)
Receive Sensitivity
-101 dBm (typ)
Adjacent channel rejection
36 dB
+ 5 MHz channel spacing
34 dB
- 5 MHz channel spacing
Outdoor Range
> 300 m
1/4 wave dipole antenna, LOS
Indoor Range
> 50 m
1/4 wave dipole antenna, LOS
Current Draw
16 mA
Receive mode
10 mA
TX, -17 dBm
13 mA
TX, -3 dBm
17 mA
TX, 3 dBm
Battery
2X AA batteries
Attached pack
External Power
2.7 V - 3.3 V
Molex connector provided
User Interface
3 LEDs
Red, green and yellow
Size (in)
2.25 x 1.25 x 0.25
Excluding battery pack
(mm)
58 x 32 x 7
Excluding battery pack
Weight (oz)
0.7
Excluding batteries
(grams)
18
Excluding batteries
Expansion Connector
51-pin
All major I/O signals
IRIS Mote (bottom view)
RF Transceiver
Electromechanical
Notes
5 MHz steps for compliance with IEEE 802.15.4/D18-2003.
Specifications subject to change without notice
1
MIB520CA Mote Interface Board
Base Stations
A base station allows the aggregation of sensor network data onto a PC or other computer platform. Any IRIS Mote can
function as a base station when it is connected to a standard PC interface or gateway board. The MIB510 or MIB520 provides
a serial/USB interface for both programming and data communications. Crossbow also offers a stand-alone gateway solution,
the MIB600 for TCP/IP-based Ethernet networks.
Ordering Information
Model
Description
XM2110CA
2.4 GHz IRIS OEM Reference Board
C r o s s b o w Te c h n o l o g y, I n c .
4145 North First Street
San Jose, California 95134-2109
144
MTS420/400
ENVIRONMENTAL SENSOR BOARD
• 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)
MTS420/400
Developed 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 battery life and performance wherever
low maintenance field-deployed sensor
nodes are required.
MTS420CC (with GPS Module)
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
MTS400CB
These versatile sensor boards are
intended for a wide variety of applications ranging from a simple wireless
weather station to a full mesh network
of environmental monitoring nodes.
Applicable industries include Agricultural, Industrial, Forestry, HVAC
and more.
• TAOS TSL2550D
Specifications:
• Absolute RH accuracy: ± 3.5% RH
Board
• Spectral responsivity: 400-1000 nm,
similar to human eye
Relative Humidity & Temperature
Sensor
• Sensirion SHT11
• Humidity range; resolution: 0-100%
RH; 0.03% RH
• Temp. accuracy: ± 0.5°C @ 25°C
• Operating temp. range: -10°C to
+60°C
GPS Module (MTS420CC only)
• Operating humidity range 0% RH to
90% RH non-condensing
• Tracking channels: 16
• ublox LEA-4A
• L1 frequency: 1575.42 MHz
C/A code
• Position accuracy: 10 m, 2D
• Reacquisition time: < 1 sec. (typ.);
(<30 sec. max. blockage)
Ordering Information
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
Phone: 408.965.3300
Fax: 408.324.4840
E - m a i l : i n f o @ x b o w. c o m
We b : w w w. x b o w. c o m
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: Proceedings of the Workshop on Mobile Computing Systems and Applications 1994;
85-90.
[9] Dey AK, Abowd G. – Towards a better understanding of context and contextawareness. 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: analysis 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: examples 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 Kinematic Analysis with BSN In: 2010 International Conference on Body Sensor
Networks.
[15] Reed W. Hoyt,
Army
Research
Biophysics and Biomedical Modeling Division,
Institute
of
Environmental
Medicine
U.S.
(USARIEM)
–
SPARNET: Spartan Sensor Network to Improve Medical And Situational 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 MARTÍNEZ, Paula de
TOLEDO – Standards for Medical Device Communication: X73 PoC–MDC.
[26] M. Galarraga, L. Serrano, I. Martinez, P. de Toledo and Melvin Reynolds – Telemonitoring Systems Interoperability Challenge: An Updated Review of the Applicability of ISO/IEEE 11073 Standards for Interoperability in
Telemonitoring.
[27] Mauri Honkanen, Antti Lappeteläinen, and Kalle Kivekäs – 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/tinyos1.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, Konrad Lorincz, Victor Shnayder, Logan Hauenstein, Foad Dabiri, James Jeng, Arjun 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 Konitsiotis 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 Network pdfauthor=Giovanni Giacco

Transcript

Documenti analoghi

HUMANGLOVE

Meeting with Magneti Marelli PowerTrain 16 Giugno 14.30, Aula di

SvH042 - Intea Engineering

quantum 4 - goclever

Assistenza anziani

FORD Galaxy 2.0 TDCi 163CV Pow. Titanium Bs.

IT Distribuzione presenta WZZARD Intelligent Sensing Platform

PCTPRxxx Barometric pressure sensor Sensore di pressione

SSA Sensore stato manto stradale / Sensor of state of the