kablosuz sensor aglarinin micaz tabanli biyomedikal uygulamasi

kablosuz sensor aglarinin micaz tabanli biyomedikal uygulamasi

EGE ÜNĐVERSĐTESĐ FEN BĐLĐMLERĐ ENSTĐTÜSÜ
(YÜKSEK LĐSANS TEZĐ)
KABLOSUZ SENSÖR AĞLARININ
MicaZ TABANLI BĐYOMEDĐKAL UYGULAMASI
Hüseyin Ertürk ÇETĐN
Elektrik-Elektronik Mühendisliği Anabilim Dalı
Bilim Dalı Kodu: 609.02.00
Sunuş Tarihi: 24.08.2009
Tez Danışmanı: Yrd. Doç.Dr. Radosveta SOKULLU
Bornova – ĐZMĐR
II
III
Hüseyin Ertürk Çetin tarafından YÜKSEK LĐSANS TEZĐ olarak sunulan
“Kablosuz Sensör Ağlarının MicaZ Tabanlı Biyomedikal Uygulaması”
başlıklı bu çalışma E.Ü. Fen Bilimleri Enstitüsü Eğitim ve Öğretim
Yönergesi’nin ilgili hükümleri uyarınca tarafımızdan değerlendirilerek
savunmaya değer bulunmuş ve 24.08.2009 tarihinde yapılan tez savunma
sınavında aday oybirliği/oyçokluğu ile başarılı bulunmuştur.
Jüri Üyeleri:
Đmza:
Jüri Başkanı: Yrd.Doç.Dr. Radosveta SOKULLU
.......................
Raportör Üye: Yrd.Doç.Dr. Mehmet ENGĐN
.......................
Üye: Prof. Dr. Tayfun DALBASTI
.......................
IV
V
ÖZET
KABLOSUZ SENSÖR AĞLARININ
MicaZ TABANLI BĐYOMEDĐKAL UYGULAMASI
ÇETĐN, Hüseyin Ertürk
Yüksek Lisans Tezi, Elektrik-Elektronik Mühendisliği Bölümü
Tez Yöneticisi: Yrd.Doç.Dr. Radosveta SOKULLU
Ağustos 2009, 73 sayfa
Gelişen teknoloji ve düşen maliyetler sayesinde kablosuz
haberleşme günümüzde çok çeşitli uygulama alanlarına sahip olmuştur.
Özellikle kablosuz sensör ağları konusunda çok sayıda çalışma
yapılmaktadır.
Bu tez çalışmasında kablosuz sensör ağlarının biyomedikal bir
uygulaması gerçeklenmiş ve geliştirilen sistem Ege Üniversitesi
Hastanesi’nde denenmiştir. Kablosuz modüller (mote) nesC diliyle
programlanmış, pulse oximeter sensörler bu modüllere bağlanarak
hastaların nabız, pletismogram ve kandaki oksijen oranı verileri ZigBee
standardı kullanılarak kablosuz ağ üzerinden merkezi veritabanına
aktarılmıştır. Sistemin performansı,
değişik ağ topolojilerinde, paket
kaybı yüzdesi olarak ölçülmüştür.
Anahtar Sözcükler: WSN, nesC, TinyOS, MicaZ, pulse oximeter, mote,
ZigBee, kablosuz sensör ağı, mesh network.
VI
VII
ABSTRACT
A MicaZ-BASED BIOMEDICAL APPLICATION OF
WIRELESS SENSOR NETWORKS
ÇETĐN, Hüseyin Ertürk
MSc in Electrical and Electronics Engineering
Supervisor: Asst. Prof.Dr. Radosveta SOKULLU
August 2009, 73 pages
Wireless communication has been used in lots of different
applications due to advances in technology and reduction in hardware
cost. In particular, wireless sensor networks subject is being studied
extensively.
In this thesis work, a practical application of wireless sensor
networks has been realized and the resulting system has been tried in Ege
University Hospital. Wireless modules (motes) have been programmed in
nesC language, pulse oximeter boards have been connected to motes,
heart rate, plethysmogram, and blood oxygen saturation data of patients
have been transferred to a central database over the wireless network
using the ZigBee standard. The performance of the system has been
evaluated in terms of packet loss in different network topologies.
Keywords: wireless sensor network, WSN, nesC, TinyOS, MicaZ, pulse
oximeter, mote, ZigBee, mesh network.
VIII
IX
TEŞEKKÜR
Yüksek lisans çalışmamın başından bu yana bana her zaman yardımcı
olan ve bu tezi hazırlamamda değerli katkılarını esirgemeyen danışman
hocam Yrd. Doç.Dr. Radosveta SOKULLU’ya;
Tez çalışmamla ilgilenen ve sistemimizi hastanede denememize imkan
sağlayan Ege Üniversitesi Tıp Fakültesi Nöroşirurji Anabilim Dalı
Öğretim Üyesi Prof. Dr. Tayfun DALBASTI’ya;
Cihaz alımlarımızda bize maddi destek veren TÜBĐTAK’a;
Çalışırken bana yüksek lisans yapma imkanı sağlayan Vestel Elektronik
A.Ş.’ye ve Aselsan A.Ş.’ye;
Yoğun iş, ders ve tez çalışmalarımda bana her zaman destek olan sevgili
eşim Funda’ya ve varlıklarıyla hayatımızı çok daha güzel hale getiren
sevgili oğlum Musa Onur ile sevgili kızım Hilal’e teşekkürlerimi sunarım.
X
XI
ĐÇĐNDEKĐLER
Sayfa
ÖZET ……………………………………………………………………V
ABSTRACT …………………………………………………………..VII
TEŞEKKÜR ……………………………………………………………IX
ĐÇĐNDEKĐLER ………………………………………………………...XI
ŞEKĐLLER DĐZĐNĐ ………………………….......................…..…….XIII
ÇĐZELGELER DĐZĐNĐ ……………………...................……….....….XV
KISALTMALAR DĐZĐNĐ ……………………….....................……...XVI
1
GĐRĐŞ ………...………………………………………………….1
2
SĐSTEM MĐMARĐSĐ …………………….....................................5
2.1
HABERLEŞME STANDARDI (ZIGBEE)……………...5
2.2
KABLOSUZ MODÜL (MicaZ MOTE) ………...............8
2.3
PULSE OXIMETER SENSOR …...................................10
2.4
YAZILIM …………........................................................17
2.5
YÖNLENDĐRME PROTOKOLÜ (XMESH) .................21
2.6
KULLANICI ARAYÜZÜ (MOTEVIEW) .....................30
3
BULGULAR …………...............................................................36
4
SONUÇ ………...........................................................................52
KAYNAKLAR DĐZĐNĐ ……………......................................................54
EKLER ………………………................................................................56
Ek 1
“Makefile” Dosyası ………………………….......……..57
XII
Ek 2
“Makefile.component” Dosyası …......................………58
Ek 3
“XMTS400.nc” Dosyası …………............................…..59
Ek 4
“XMTS400M.nc” Dosyası ……..........................………61
Ek 5
“appFeatures.h” Dosyası …….............................………68
Ek 6
“appPacket.h” Dosyası …...….............................………69
Ek 7
“sensorboardApp.h” Dosyası ……......................………70
ÖZGEÇMĐŞ …………..........................................................…………..73
XIII
ŞEKĐLLER DĐZĐNĐ
Sayfa
Şekil 2.2.1 MicaZ kablosuz modül kartı…………………………………8
Şekil 2.2.2 MicaZ blok diyagramı………….............................................9
Şekil 2.3.1 Pulse oximeter sensörlerin modüllere bağlı hali ...................16
Şekil 2.3.2 Pulse oximeter sensörlerin kullanım şekli ............................17
Şekil 2.4.1 Programmer’s Notepad ile ilgili dosyaların açılması ...........21
Şekil 2.5.1 XMesh ağ yapısı ...................................................................24
Şekil 2.5.2 XMesh sistem genel mimarisi ...............................................25
Şekil 2.6.1 Moteview ile sensör ağına bağlantı kurulması – Mode ........31
Şekil 2.6.2 Moteview ile sensör ağına bağlantı kurulması – Gateway ...32
Şekil 2.6.3 Moteview ile sensör ağına bağlantı kurulması – Database ...33
Şekil 2.6.4 Moteview ile sensör ağına bağlantı kurulması,Sensorboard.33
Şekil 2.6.5 Moteview genel görünüm .....................................................34
Şekil 2.6.6 Moteview uyarı penceresi .....................................................35
Şekil 2.6.7 Moteview e-mail uyarı ayarları .............................................35
Şekil 3.1 Senaryo A ağ topolojisi ............................................................37
Şekil 3.2 Senaryo B ağ topolojisi ............................................................38
Şekil 3.3 Senaryo B ağ topolojisi – son durum .......................................38
Şekil 3.4 Senaryo C ağ topolojisi ............................................................39
Şekil 3.5 Senaryo D ağ topolojisi ............................................................39
Şekil 3.6 Senaryo E ağ topolojisi ............................................................40
XIV
Şekil 3.7 Senaryo F ağ topolojisi ............................................................40
Şekil 3.8 Senaryo A paket bilgileri .........................................................41
Şekil 3.9 Senaryo B paket bilgileri .........................................................41
Şekil 3.10 Senaryo C paket bilgileri .......................................................41
Şekil 3.11 Senaryo D paket bilgileri .......................................................42
Şekil 3.12 Senaryo E paket bilgileri ........................................................42
Şekil 3.13 Senaryo F paket bilgileri ........................................................42
Şekil 3.14 Normalize edilmiş performans bulguları ...............................43
Şekil 3.15 Ağ oluşum süresi ………………………...............................45
Şekil 3.16 Ağ kararlılığı ……………………………..............................46
Şekil 3.17 Efektif bölge menzili …………………….............................47
Şekil 3.18 Senaryo A ölçümlerin veritabanına aktarılmış hali................48
Şekil 3.19 Senaryo B ölçümlerin veritabanına aktarılmış hali.................49
Şekil 3.20 Senaryo D veri grafiği.............................................................49
Şekil 3.21 Senaryo E veri grafiği.............................................................50
Şekil 3.22 Mote + Sensör akım grafiği ...................................................51
XV
ÇĐZELGELER DĐZĐNĐ
Sayfa
Çizelge 3.1 Senaryolar….................………………........………………37
Çizelge 3.2 Performans bulguları…………………........………………43
XVI
KISALTMALAR
ADC
Analog-to-Digital Converter
ADMR
Adaptive Demand-driven Multicast Routing
AES
Advanced Encryption Standard
BS
Base Station
BSN
Body Sensor Network
DSSS
Direct Sequence Spread Spectrum
ECG
Electrocardiogram
EU
European Union
EWMA
Exponentially Weighted Moving Average
FFD
Full Function Device (ZigBee)
FIFO
First In First Out
GUI
Graphical User Interface
I2C
Inter – Integrated Circuit
I/O
Input / Output
IEEE
Institute of Electrical and Electronics Engineers
ISM
Industrial – Scientific - Medical
kbps
Kilo bits per second
MAC
Medium Access Control
Mbps
Mega bits per second
nesC
Network Embedded System C
NSF
National Science Foundation
OSI
Open Systems Interconnection
OTAP
Over-The-Air Programming
XVII
PC
Personal Computer
PDA
Personal Digital Assistant
PHY
Physical Layer
QoS
Quality of Service
RAM
Random Access Memory
RF
Radio Frequency
RFD
Reduced Function Device (ZigBee)
ROM
Read-Only Memory
RUI
Route Update Interval
SPI
Serial Peripheral Interface
SpO2
Pulse Oximetry
TinyOS
Tiny Operating System
UART
Universal Asynchronous Receiver - Transmitter
WSN
Wireless Sensor Network
XVIII
1
1
GĐRĐŞ
Günümüzde hızla ilerleyen teknoloji sayesinde elektronik devreler
daha az güç tüketerek daha çok işlem yapabilmektedir. Daha az güç
tüketimi, devrenin fiziksel boyutlarının da küçülmesini de beraberinde
getirmektedir. Bu küçülmeye paralel olarak maliyetler de azalmakta ve
böylece elektronik devrelerin uygulama alanları artmaktadır.
Haberleşme yöntemlerinde görülen gelişme ve özelleşmeyle de
birlikte düşünüldüğünde elektronik devreler ve mikroişlemciler artık
hayatın her alanında faydalı çözümler sunar hale gelmiştir. Bir sensör, bir
mikroişlemci ve bir haberleşme çipinden oluşan küçük boyutlu elektronik
devrelerden oluşan bir sistem ile bir kablosuz sensör ağı (wireless sensor
network, WSN) oluşturulmakta ve örneğin tarımda otomatik sulama
yapılabilmekte, orman yangınları daha etkin biçimde gözetlenebilmekte
veya büyük çiftliklerde hayvanların takibi çok daha iyi şekilde
yapılabilmektedir. Sağlık alanında da son yıllarda giderek artan sayıda
WSN çalışmaları mevcuttur.
UbiMon [Ubiquitous Monitoring Environment for Wearable and
Implantable Sensors] projesi, aritmik kalp hastalıklarını ölçmek gibi
uygulamalara yönelik, giyilebilir veya taşınabilir sensörlerden oluşan
mobil sistemlerin genel özelliklerini belirlemek amacıyla yürütülmüştür.
Bu sistem beş ana parçadan oluşmaktadır: Body Sensor Network (BSN)
düğümleri (nodes), işlemci, merkezi sunumcu, hasta veritabanı ve PC.
Kablosuz elektrokardiyogram (ECG) ve pulse oximeter (SpO2) sensörler
tasarlanmış ve bunlar ivmeölçer, sıcaklık ve deri iletkenliğini ölçen
sensörlerle birlikte BSN düğümünü oluşturmuştur. PDA cihazları için
Compact Flash kartı geliştirilmiş ve bu kartta sensör sinyalleri toplanmış,
2
izlenmiş ve analiz edilmiştir. PDA aynı zamanda BSN düğümü ile
merkezi sunucu arasında Wi-Fi/GPRS vasıtasıyla router görevi
görmektedir. PC’de ise sensör verilerini görebilmek amacıyla kullanıcı
arayüzü tasarlanmıştır.
Harvard Üniversitesi tarafından geliştirilen CodeBlue projesinde,
özellikle büyük ölçekli afetler sonrasında arama kurtarma faaliyetlerini
kolaylaştırmak amaçlanmış ve Adaptive Demand-Driven Multicast
Routing (ADMR) protokolünü baz alan bir protokol Mica2, MicaZ ve
Telos mote’larda kullanılmıştır. CodeBlue yazılımı, cihaz yer tespiti,
yayın-abonelik tabanlı çok atlamalı yönlendirme (publish-subscribe
multihop routing) ve hasta sorgu arayüzü sağlayan protokoller
sunmaktadır. RF tabanlı konum belirleme özelliği ile hastaların ve sağlık
personelinin yer tespitine de imkan vermektedir.
Valdastri (2007) çalışmasında ZigBee uyumlu yazılım ile noktadan
noktaya (point-to-point) kablosuz haberleşme yöntemiyle domuzlara
implante edilmiş olan sensörlerden aortik ve ventriküler basınç ve
sıcaklık verileri okunmuştur. Kullanılan haberleşme protokolü yazılımı
ile IEEE 802.15.4 standardının alt seviye özellikleri in-vivo izleme
uygulamasında doğrulanmış ve böylece ZigBee’nin daha basit bir türevi
elde edilmiştir. Aynı işlem, ZigBee standardında 32 kB yer tutarken,
implante edilen cihazın tüm yazılım boyutu 12.5 kB yer tutmaktadır.
Dağtaş (2007) çalışmasında ECG verisini ölçen ve bunu bir
veritabanına aktaran bir sistem önerilmiştir. Sayısala çevrilen ECG datası
sürekli olarak ZigBee vasıtasıyla merkezi sunucuya gönderilmektedir.
Merkezi sunucuda tutulan veri daha sonra sağlık personeli tarafından
incelenebilmektedir. ECG ölçümleri pulse oximeter ölçümlerinden çok
daha yüksek veri hızı gerektirmektedir.
3
ZigBee sistemine oranla çok daha fazla güç tüketen IEEE 802.11
tabanlı bir sistem de kablosuz hasta izleme işlemi için önerilmiştir (Yu
and Tseng, 2007).
Hastanın adım sayısını ve ECG verisini ölçmek amacıyla noktadan
noktaya ZigBee tabanlı bir sistem tasarlanmıştır (Hong et.al, 2006). Bu
sistemde göndermeç (transmitter) hastanın boynuna asılan bir kolyede,
almaç (receiver) ise sağlık personelindeki PDA cihazında yer almaktadır.
Maxstream firmasının kablosuz modülü ve temas tipli (contacttype) bir mikrofondan oluşan sistem ile hastanın kalp sesi ZigBee tabanlı
bir ağda merkezi veritabanına gönderilmiştir (Park et.al, 2007). Merkezi
veritabanından yapılan sorgu ile çalışan bu sistemde ortalama hata
oranı % 5.97 olarak ölçülmüştür.
Yukarıda bahsi geçen projeler sınırlı esnekliğe sahiptir ve yeniden
yapılandırılmaları çok zordur. Hepsinde piyasada mevcut donanım
kullanılmadığı için de bunlar, az güç tüketecek ve iyi bir kullanıcı
arayüzü sağlayacak bir kablosuz sensör ağı uygulaması için pahalı
çözümler olarak görülmektedir.
Bu tez çalışmasının amacı, kablosuz sensör ağlarının sağlık
alanındaki bir uygulamasını tasarlamak, sistemi uygulamak ve elde
edilen sonuçları analiz etmektir. Hastalardaki pulse oximeter sensörler
kablosuz modüllere bağlanarak kablosuz bir ağ oluşturulmuş ve hastanın
nabız ve kandaki oksijen oranı verileri merkezi bir veritabanına
aktarılmıştır. Geliştirilen sistemin performansı değişik ağ topolojilerinde
incelenmiştir. Diğer sistemlere göre daha fazla ölçeklenebilirlik
4
(scalability) ve hareket (mobility) imkanı sağlanmaktadır. Piyasada
mevcut donanımlar kullanıldığı için sistem maliyeti de düşüktür.
Her bir düğümdeki yeniden gönderme denemesi (retry) ve toplam
paket kaybı açısından incelendiğinde, önerilen sistemin performansı,
ameliyat sonrası veya rehabilitasyon fazlarında hastanın kablosuz olarak
izlenmesine uygundur. Ayrıca bu sistemde, kullanıcı arayüzünde kolayca
yapılabilecek şekilde uyarı özelliği de mevcuttur: herhangi bir hastanın
nabız veya kandaki oksijen oranı değerinde belirlenen bir eşiğin altında
veya üstünde ölçüm sonucu alındığında ekrana uyarı mesajı
verilebilmekte veya sağlık personelindeki PDA cihazına e-posta
gönderilebilmektedir.
5
2
SĐSTEM MĐMARĐSĐ
Kablosuz sensör ağlarının sistem mimarisi genel olarak altı
kısımdan oluşmaktadır: kablosuz haberleşme standardı, kablosuz modül,
sensör, yazılım, yönlendirme algoritması ve kullanıcı arayüzü . Kablosuz
haberleşme standardı, kablosuz modüllerin kendi arasında ve baz
istasyonu ile olan haberleşmelerinde kullanılan standarttır. Uygulamaya
göre standart seçimi yapılır, örneğin ses ve video aktarımı gibi yüksek
hızda veri transferi yapılacaksa Wi-Fi seçilmesi uygun olacaktır. Yazılım
kablosuz modül üzerinde koşar ve sensörden verileri okuyup kendi
hafızasına alıp, gerektiğinde bu veriyi diğer modüllere veya baz
istasyonuna yönlendirme algoritmasına uygun olarak aktarır. Sistem
topolojisi ve ölçüm sonuçları kullanıcı arayüzü ile izlenir.
2.1
Kablosuz Haberleşme Standardı (ZigBee)
ZigBee standardı, ZigBee Alliance tarafından geliştirilen, düşük
veri hızında, düşük güç tüketimi gerektiren, maliyeti düşük, otomasyon
ve uzaktan kontrol gibi uygulamalara sahip kablosuz sistemlerde
kullanılan bir haberleşme standardıdır.
ZigBee uygulamalarında Bluetooth uygulamalarındaki kadar
yüksek veri hızı gerekmediğinden, düşük maliyetli ve bir pille aylarca
hatta yıllarca çalışması gereken, düşük güç tüketen sistemlerde ZigBee
tercih edilir. Ayrıca ZigBee, Bluetooth’a oranla daha fazla sayıda düğüm
sayısına sahip olabilir. ZigBee uyumlu cihazlar, anten gücüne ve ortama
bağlı olarak 10 ila 75 metre mesafeye kadar gönderim yapabilir ve dünya
çapında lisanssız kullanıma imkan veren 2.4 GHz frekans bandında
6
çalışabildikleri gibi, Amerika’da 915 MHz ve Avrupa’da 868 MHz
bandında da çalışabilirler (Ergen, 2004). Veri hızları 2.4GHz bandında
250 kbps; 915 MHz bandında 40 kbps ve 868 MHz bandında 20 kbps’dir.
ZigBee standardı, IEEE 802.15.4 standardını baz almıştır. IEEE
802.15.4 standardı OSI katmanlarının en alt iki seviyesini
tanımlamaktadır: fiziksel katman ve veri bağı katmanı (physical and data
link layers). ZigBee standardı ise daha yukardaki (ağ katmanından
uygulama katmanına kadar) katmanları tanımlamaktadır.
ZigBee’de ağ yönlendirme yapısı, güç tasarrufunu ve garanti
edilmiş zaman dilimleri vasıtasıyla düşük gecikme miktarını sağlayacak
şekilde tasarlanmıştır. ZigBee’nin kendine has bir özelliği de ağdaki
noktasal hataları giderebilecek haberleşme yöntemidir. Fiziksel katmanın
önemli özellikleri ise enerji ve bağ kalitesi tespiti ile temiz kanal
değerlendirme yeteneğidir ki bu sayede diğer kablosuz ağlarla birlikte
karışım olmadan çalışma imkanı sunar.
Fizyolojik verilerin kablosuz aktarımında ZigBee standardı yeterli
ve uygundur (Hofmann et.al, 2006). Örnekleme hızı bakımından en
talepkar olan sürekli ECG izleme işlemi bile ZigBee kullanılarak güvenli
biçimde gerçekleştirilmiştir. Veri gönderimi esnasındaki güç tüketimi
Bluetooth standardındaki değere yakındır fakat uyku modundaki çok
düşük güç tüketimi ve yüksek uyku oranı sayesinde ZigBee, yıllarca tek
bir pille çalışma imkanı sunmaktadır. Ayrıca, Bluetooth sisteminde bir
ağda en fazla 7 cihaz bulunabilirken, bu sayı ZigBee için 65536’dır (216).
Yukarıda belirtilen tüm bu özellikler sebebiyle, geliştirilen
uygulama için kablosuz haberleşme standardı olarak ZigBee seçilmiştir.
7
Sağlık alanında bir uygulama gerçekleştirilirken işin güvenlik
boyutu da büyük önem taşımaktadır. Güvenlik açısından incelendiğinde,
kablosuz sensör ağlarına karşı yapılan güvenlik saldırıları, saldırının
yapıldığı OSI katmanına göre sınıflandırılabilir (Sokullu vd, 2009):
fiziksel katman atakları (frekans karıştırma, radio jamming), MAC
katmanı atakları (packet jamming, backoff manipulation, GTS attack),
yönlendirme katmanı atakları (flood attack, fake route information
attack), iletim katmanı atakları (desynchronization attack) ve uygulama
katmanı atakları (overwhelming attack).
IEEE 802.15.4 PHY ve MAC katmanlarını kullanan ZigBee’de
IEEE 802.15.4’te tanımlı MAC güvenlik özellikleri mevcuttur. IEEE
802.15.4’te kriptolama algortiması (AES-128) belirtilmiştir fakat
anahtarların nasıl yönetileceği ve ne tür doğrulama işlemleri yapılacağı
belirtilmemiştir. Anahtar yönetimi ve doğrulama işlemleri ZigBee gibi
daha üst katmanlara bırakılmıştır. ZigBee’de ise ağ katmanı ve uygulama
katmanında güvenlik özellikleri mevcuttur. Trust center kavramı vardır
ve üç tür anahtar tanımlıdır: master key, link key ve network key. Bir
node bir ağa katılmak istediğinde network key vasıtasıyla önce ağa kabul
edilmelidir. Herhangi iki node arasında ise link key kullanılabilir.
Anahtar iletimi ve güncellemesi gibi işlemlerden Trust Center
sorumludur (Reddy, 2004). Düşük güç tüketen cihazlar için
tasarlandığından ZigBee’deki güvenlik özellikleri diğer kablosuz
haberleşme standartlarındaki kadar güçlü değildir.
Bu tez çalışmasında IEEE 802.15.4’te ve ZigBee’de sağlanan
güvenlik özellikleri kullanılmış ve güvenlik için ilave bir çalışma
yapılmamıştır.
8
2.2
Kablosuz Modül (MicaZ Mote)
Geliştirilen sistemde kablosuz modül olarak MicaZ kartlar
kullanılmıştır. MicaZ donanımı, Crossbow firmasınca üretilen, 2.4 GHz
frekansında haberleşme yapan, IEEE 802.15.4 standardına uyumlu,
kablosuz sensör ağları için geliştirilmiş bir elektronik karttır. Bu
modüllerin temel özellikleri şunlardır:
•
IEEE 802.15.4/ZigBee uyumlu
•
•
•
2.4 GHz, ISM bandında çalışma
Direct sequence spread spectrum (DSSS)
Güvenlik (AES-128)
•
•
•
250 kbps veri hızı
TinyOS 1.1.7 veya daha üst versiyon işletim sistemi
UART, I2C, SPI, ADC ve I/O bağlantıları
Şekil 2.2.1 MicaZ kablosuz modül kartı
9
Şekil 2.2.2 MicaZ blok diyagramı
TinyOS, UC Berkeley tarafından geliştirilmiş olan, büyük ölçekli
ve kendi kendini yapılandırabilen (self-configuring) ağları destekleyen,
küçük boyutlu, enerji verimliliği yüksek ve açık kaynak bir işletim
sistemidir.
MicaZ kartının temel yapıtaşları şunlardır:
•
Atmel Atmega128L mikroişlemci
•
51 pinli sensör bağlantı soketi
•
ChipCon CC2420 RF verici/alıcı çipi
•
Anten
•
3 adet LED (kırmızı, sarı ve yeşil)
10
2.3
Pulse Oximeter (SpO2) Sensör
SpO2 sensör oksimetre kartları kandaki oksijen oranını ve nabız
değerini hastayı rahatsız etmeden ölçmeye imkan tanıyan cihazlardır.
Oksimetre geliştirme kartı Smiths Medical firmasınca üretilmiştir ve iki
kısımdan oluşmaktadır:
•
31392B1: Bir tarafı PC’ye diğer tarafı sensöre bağlı olan ve
içinde voltaj dönüştürücü / haberleşme arayüzü bulunduran kart.
•
3044: El parmaklarına takılabilen oksimetre sensörü.
Sensör oksimetre kartı, hastanın kanındaki oksijen yüzdesini ve
nabız değerini ölçmek amacıyla tasarlanmıştır. Çok düşük güç
tüketimiyle çalıştığı için mobil uygulamalarda idealdir. Kritik hasta
gözlem amacıyla kullanılması doğru değildir. Ortalama oksijen
yüzdesinden başka anlık oksijen değerini de gönderdiği için uyku gözlem
çalışmalarında faydalıdır. Bu kart tüm BCI sensörleriyle uyumludur ve
neonatal, pediyatrik ve yetişkin hastalarda kullanılabilir.
660 nm (kırmızı, 2.0mW) ve 905 nm (kızılötesi, 2.0 – 2.4mW)
dalgaboylarında iki tür ışık gönderen cihaz karşı yüzdeki foto sensör
vasıtasıyla parmak dokusundan geçen ışıkları ölçer ve buradan yaptığı
hesapla %SpO2 değerini bulur. Ölçüm sırasında, her bir ışık kaynağından
elde edilen sinyal gücü, parmak dokusunun renk ve kalınlığına, sensör
yerleşimine, ışık kaynaklarının yoğunluğuna ve parmak dokusunda
emilen (nabzın zamana bağlı parametrelerini de içeren) arterial ve venous
11
kana bağlıdır. Oksimetre kartı bu sinyalleri işleyerek zamandan bağımsız
parametreleri (arterial hacmi ve %SpO2 değeri) ayırır ve nabız oranını ve
kandaki oksijen doygunluğunu hesap eder. Oksijence yoğun kan,
oksijence fakir kana oranla kırmızı ışığı daha çok soğurur, böylece
kandaki oksijen yüzdesi hesabı oksimetre kartı tarafından yapılabilir.
Pulse oximeter sensör kartının teknik özellikleri şunlardır:
SpO2:
Skala:
%0 - %99 SpO2 (1% adımlarla)
Hassasiyet:
Yetişkin:
±2 (%70-99 SpO2 aralığında)
Neonate:
±3 (%70-99 SpO2 aralığında)
Ortalama:
8 kalp atışının ortalaması ve anlık değer
Nabız Oranı (Pulse Rate):
Skala:
dakikada 30-254 atış (1 atışlık adımlarla)
Hassasiyet:
±2 atış veya ±2% (hangisi büyükse)
Ortalama:
8 saniyenin ortalaması
Sinyal Gücü (Signal Strength):
0-8 arasındaki değerler logaritmik sinyal gücünü gösterir.
Bar Grafik (Bargraph):
12
0-15 segment
Plethysmogram:
0-100, en yüksek çözünürlük için otomatik kazanç ayarı yapılır.
Ebatlar:
Uzunluk:
39 mm
Genişlik:
20 mm
Yükseklik:
5.6 mm
Sistem Đşaretleri (Flags):
Kalp atışında ses (Pulse Beep)
Parmak yok (No Finger in Sensor)
Sensör bağlı değil (Sensor Unplugged)
Nabız arıyor (Searching for Pulse)
Arama çok uzadı (Searching Too Long)
Nabız kaybedildi (Lost Pulse)
Yazılım Numarası (Software Revision):
X.XX formatındaki yazılım numarası reset’ten sonra veya ilk güç
verildiğinde UART’tan gönderilir.
13
UART Voltaj Seviyeleri (Serial Communication Logic Levels):
CMOS 3.3V
Đki Arıza Arasındaki Ortalama Süre (Mean Time Between Failures):
100,000 saat’ten büyük
Güç Đhtiyacı (Power Requirements):
6.6mA / 3.3V DC (22mW ortalama güç tüketimi)
Seri Haberleşme (Serial Communications):
Oksimetre kartı, verileri UART üzerinden saniyede 60 paket
hızında gönderir. Veriler 4 byte’lık paketler olarak biçimlendirilir. 4800
baud, 1 başlangıç biti, 8 veri biti, 1 bitiş biti kullanılır ve parity bit
kullanılmaz.
Oksimetre kartı mote ile tek bir UART hattı üzerinden ve 0 - 3.3V
seviyesinde asenkron olarak haberleşir. Bu haberleşmede gönderilen
veriler %SpO2 değeri (8 kalp atışında ortalama ve anlık değer), nabız
oranı, sinyal gücü bar grafiği, plethysmogram ve status bit verileridir.
Mote plethysmogram dalga şeklini senkronize edebilir. Oksimetre
14
kartının sunduğu anlık SpO2 değerleri kullanılarak mote tarafından da
ayrı bir ortalama hesabı yapılabilir.
4 Byte’tan oluşan paketlerin anlamları şöyledir:
Byte 0:
1
da/sw 0
0
A2
A1
A0
Beep
P6
P5
P4
P3
P2
P1
P0
N7
0
0
B3
B2
B1
B0
x
x
x
x
x
x
x
Byte 1:
0
Byte 2:
0
Byte 3:
0
Burada:
A[2-0]:Adres. Byte 3 bit [6-0] bu adres değerine göre 8 farklı anlam
taşıyabilir:
000:
Sp02[6-0]. [0-99] aralığında. 127: geçersiz Sp02 değeri.
001:
Nabız[6-0]. Bit7 Byte 2’de. [30-254] aralığında. 255:
geçersiz nabız değeri
010:
Sinyal gücü[6-0]. [0-8] aralığında.
011:
Alarm / Uyarı
15
0: alarm/uyarı yok
1: sensör bağlı değil
2: parmak yok veya sensör arızalı
3: nabız arıyor
4: uzun zamandır arama yapılıyor
5: nabız kaybedildi
100:
Anlık SpO2. Her kalp atışı esnasında gönderilir. Kalp
atışları arasındaki zamanda değeri sıfırdır. Mote, bu veriyi
kullanarak, uygulamaya bağlı olarak kendi ortalama değer
bulma algoritmasını uygulayabilir.
101:
Kırmızı sistem kazanç endeksi. Yazılımın servo kısmında
tanımlıdır.
110:
Kızılötesi sistem kazanç endeksi. Yazılımın servo
kısmında tanımlıdır. Sensörde parmak olmadığını anlamak
için kullanılır.
111:
Üretim testlerinde kullanılır.
B: Bar grafik [0-15]
P: Pletismogram [0-100]
N: Nabız (pulse rate)
da/sw: data / software seçimi
0: Byte 1,2,3’te oksimetre verisi var
1: Byte 1,2,3’te yazılım versiyon numarası var
16
Şekil 2.3.1 Pulse oximeter sensörlerin modüllere bağlı hali
17
Şekil 2.3.2 Pulse oximeter sensörlerin kullanım şekli
2.4
Yazılım
MicaZ modüller, TinyOS isminde çok küçük bir işletim sistemi ile
çalışmaktadır (Moteworks User Manual, 2007). TinyOS işletim sistemi,
California Berkeley Üniversitesi tarafından, gömülü kablosuz sensör
ağları için geliştirilmiş olan açık kaynak bir işletim sistemidir. Sensör
ağlarının en büyük kısıtlarından olan düşük hafıza boyutu sorunu için
uygun bir çözüm sunan, geliştirmeye ve uygulamaya elverişli, düşük
miktarda hafıza gerektiren komponent bazlı bir mimariye sahiptir.
TinyOS’un komponent kütüphanesinde ağ protokolleri, dağıtılmış
hizmetler (distributed services), sensör sürücüleri ve veri toplama (data
18
acquisition) araçları bulunmaktadır. TinyOS’un olay bazlı (event-driven)
işletim modeli daha detaylı güç yönetimine imkan sunduğu için de sensör
ağlarının bir başka büyük kısıtı olan pil ömrünü uzatmaktadır.
TinyOS, klasik bir işletim sisteminden ziyade, gömülü sensör
sistemleri için geliştirilmiş bir programlama çerçevesi ve her bir
uygulamaya özel işletim sistemi oluşturmaya imkan tanıyan bir
komponentler kümesi olarak düşünülebilir. Bunun sebebi, bu işletim
sisteminin
çok
düşük
boyutlardaki
hafıza
birimlerine
sığma
zorunluluğudur. Ayrıca, TinyOS’ta bir dosya sistemi (file system)
mevcut değildir, sadece statik hafıza tahsisine (static memory allocation)
izin verilir, basit bir görev (task) modeli çalıştırılır; cihaz ve ağ
soyutlamaları (device and networking abstraction) asgari seviyede tutulur.
TinyOS’ta nesC programlama dili ile yazılan komponent bazlı bir
programlama modeli mevcuttur. Diğer işletim sistemleri gibi, TinyOS da
kendi yazılım komponentlerini değişik katmanlara ayırır. Katmanlarda
alta gidildikçe donanım seviyesine, üste çıkıldıkça ise uygulama
seviyesine yaklaşılır. Bir TinyOS uygulaması aslında bağımsız
komponentlerden oluşan bir sistemdir.
Komponentler üç farklı konsepte sahiptir: komutlar (commands),
olaylar (events) ve görevler (tasks). Komut ve olaylar komponentler arası
haberleşmede kullanılırken, görevler bir komponentin aynı anda yapması
gereken işleri yönetmek için kullanılır. Bir komponentten bir hizmet
alabilmek için komutlar kullanılır. Örneğin bir sensörü okurken ilgili
19
komponente komut gönderilir. Olay ise bir hizmetin verildiğini, hizmeti
isteyen komponente geri bildirirken kullanılır. Donanım interrupt’ları
veye mesaj alımı gibi durumlarda olaylar asenkron olarak geri
bildirilebilir. Komut ve olaylar birbirini bloke edemez. Belli bir hizmet
için gönderilen komut hemen sonlanırken bu hizmetin yerine getirildiğini
belirtilen olay sinyali bir müddet sonra yayınlanır.
Komut veya olay sinyali alan bir komponent, hesaplamayı hemen
yapmak yerine bunu TinyOS scheduler’a daha sonra hesaplanmak üzere
bir görev şeklinde gönderebilir. Böylece komut ve olaylara hemen cevap
verilmiş olur. Görevlerde karmaşık hesaplamalar yapılabilmekle birlikte,
bunların çalışma şekilleri “run indefinitely” şekinde değil; “run-tocompletion” şeklindedir, böylece “thread”lere oranla çok daha az yer
kaplarlar. Görevler, bir komponent içindeki eş zamanlı uygulamaları
temsil eder ve sadece kendi komponentinin durum bilgisine erişebilirler.
TinyOS scheduler’da herhangi bir öncelik özelliği olmayan “ilk giren ilk
çıkar” (FIFO, first in first out) düzenleme yapısı vardır.
Kablosuz modüller, nesC programlama dili kullanılarak TinyOS
koduyla programlanır. Bu tez çalışmasında, mesh network özelliklerini
desteklemek için Crossbow firmasının ürettiği XMesh yönlendirme
protokolü kullanılmıştır. Kullanıcı arayüzü programı olarak yine
Crossbow firmasının ürettiği Moteview programı kullanılmıştır.
20
Geliştirilen TinyOS kodu sayesinde kablosuz modüller, pulse
oximeter sensörlerin UART çıkışından şu verileri okumuş ve bunları
merkezi veritabanına (BS) aktarmıştır:
•
Kandaki oksijen yüzdesi, [0-99] aralığında, 127: geçersiz
okuma
•
Nabız değeri, [30-126] arasında, 127: geçersiz okuma
Geliştirilen TinyOS kodunun işletilebilir dosyası (executable file)
ROM bellekte 40602 Byte; RAM bellekte ise 2692 Byte yer tutmaktadır.
RAM kullanımı başarılı olarak değerlendirilebilir, 4096 Byte’lık toplam
RAM alanının % 65.7’lik kısmı kullanılmış, böylece hafıza taşma
sorunundan uzak kalınmıştır.
Kablosuz modüllere nesC dilinde yazılan TinyOS kodları Ek 1, Ek
2, Ek 3, Ek 4, Ek5, Ek6 ve Ek7’de verilmiştir.
Moteview programında sadece belli tip sensör kartları (XMTS400
gibi) tanımlı olduğu için kullanılan üçüncü parti pulse oximeter sensör
verileri bu sensör verileri gibi isimlendirilmiştir, örneğin “voltage” kısmı
kandaki oksijen oranını; “humidity” kısmı nabzı; “”humtemp” kısmı ise
plethysmogram verisini göstermektedir.
Kablosuz modülleri pulse oximeter sensörlerle UART üzerinden
haberleştirebilmek için
“tos\platform\micaz\hardware.h” dosyasında
21
“TOS_UART0_ BAUDRATE
=
4800u” ve “TOS_UART1_
BAUDRATE = 4800u” yazılmıştır.
Derleyici olarak Programmer’s Notepad 2 programı kullanılmıştır,
aşağıdaki resimde programın arayüzü gösterilmiştir.
Şekil 2.4.1 Programmer’s Notepad ile ilgili dosyaların açılması
2.5
Yönlendirme Protokolü (XMesh)
Kablosuz sensör ağları, değişik önceliklere göre birden fazla
şekilde
tasarlanabilir
ve
uygulamanın
ihtiyacına
göre
gerekli
parametreleri ayarlanabilir. Bu parametrelerden belki de en önemlisi
yönlendirme protokolüdür (routing protocol). Çünkü bir bilgi paketinin
kaynak düğümden hedef düğüme kadar ulaşması esnasında hangi yolu
22
izleyeceğini yönlendirme protokolü belirler. Tüm kablosuz mesh ağların
ortak ihtiyaçları şu şekilde sıralanabilir:
•
Düşük güç tüketimi: Saat pili gibi küçük bir pille aylarca
hatta yıllarca çalışabilmek için radyo haberleşmesi için
harcanan güç asgari seviyeye indirilmelidir.
•
Kullanım kolaylığı: Ağ yönlendirme protokolü sayesinde
sensör ağı kendi kendini başlatıp ad-hoc yapıda kendini
yapılandırabilmelidir.
•
Ölçeklenebilirlik: Ağdaki düğüm sayısı arttığında sistem
performansında önemli bir düşüş görülmemelidir.
•
Hızlı tepki süresi: Hareketli düğümlerin olduğu bir ağda
toploji her an değişebilmektedir. Bu topoloji değişimlerine
karşı yönlendirme algoritması hızlı ve etkin biçimde ağ
yapısını güncellemeli ve ağdaki veri trafiğinin kesintiye
uğramasını engellemelidir.
•
Mesafe: Güç tüketimi açısından, yakın mesafeye iletim
yapmak için düşük RF güç kullanmak, uzak mesafeye
iletim yapmak için yüksek RF güç kullanmaktan daha
verimlidir. Bu yüzden uzaktaki bir düğümün baz
istasyonuna veriyi birden çok düğüm üzerinden aktarması
gerekmektedir.
•
Çift yönlü haberleşme: Sensörler ve bağlı olduğu
düğümler baz istasyonuna veri gönderebileceği gibi baz
istasyonu da herhangi bir düğüme ve dolayısıyla sensöre
komut gönderebilmelidir.
23
•
Güvenilirlik: Güvenilirlik her ağ için önemlidir fakat
özellikle hasta verilerinin takip ve kayıt edildiği sağlık
uygulamaları için çok daha önemlidir.
•
Küçük ebat: Düğüm ve sensörler fiziksel olarak ölçüm
yapılan kişiyi veya mekanı rahatsız etmeyecek küçüklükte
ve hafiflikte olmaldır.
Tüm bu kablosuz ağ ihtiyaçlarını karşılamak için sağlam ve
güvenilir bir yönlendirme protokolüne ihtiyaç duyulmaktadır. Bu tez
çalışmasında yönlendirme algoritması olarak Crossbow firmasının
geliştirdiği Xmesh yönlendirme protokolü kullanılmıştır.
Xmesh, çok atlamalı (multi-hop) ve ad-hoc yapıdaki mesh ağlar
için geliştirilmiştir. Atlama (hopping) özelliği sayesinde RF kapsama
alanı ve güvenilirlik arttırılmış olur. Başka bir deyişle, iki düğüm
arasında haberleşme yapmak için bunların birbirinin RF kapsama alanı
içinde olmaları gerekmez; başka bir düğüm üzerinden veri aktarımı
yapabilirler. Ayrıca ağdaki herhangi bir düğümde sorun (pilin bitmesi
veya fiziksel başka bir hasar gibi) oluşsa dahi veri trafiği başka bir
düğüm üzerinden tekrar otomatik olarak kurulur.
Xmesh ağında şu bileşenler bulunur (Şekil 2.5.1):
1. Bir veya daha fazla sayıda düğüm (mote)
24
2. Baz
istasyonu.
Baz
istasyonu
aslında,
üzerinde
“XmeshBase” yazılımı yüklü olan ve PC’ye MIB520
programlama arayüz kartı ile bağlı olan bir mote’tur.
3. Bir
PC.
Ağdaki
düğümlerden
gelen
verileri
baz
istasyonundan alıp bunu kullanıcı arayüzü programında
gösterir ve düğümlere komut göndermekte kullanılır.
Şekil 2.5.1 XMesh ağ yapısı
Hizmet kalitesi (Quality of Service, QoS) link seviyesinde onay
(link level acknowledgement) ile “best effort” şeklinde veya uçtan uca
onay (end-to-end acknowledgement) ile “guaranteed delivery” şeklinde
sağlanır. “Best effort” yönteminde düğüm mesajını komşusuna iletmek
için bir kaç kez teşebbüste bulunur fakat mesajın komşusuna iletildiğine
dair herhangi bir geri bildirim almaz. “Guaranteed delivery” yönteminde
25
ise mesaj baz istasyonuna ulaştığında baz istasyonundan mesajı oluşturan
düğüme de mesajın alındığına dair bir mesaj gönderilir.
Şekil 2.5.2’de ise Xmesh kullanan bir sistemin genel mimarisi
gösterilmiştir.
Şekil 2.5.2 XMesh sistem genel mimarisi
Burada yazılım ana çerçevesi üç katmanda gösterilmektedir. Mote
katmanında düğümler ve baz istasyonu yer alır. Sunumcu (server)
katmanında PC düşünülebilir. Kullanıcı katmanında ise arayüz programı
(Moteview) mevcuttur. Bu tez çalışmasında mote katmanı ile sunumcu
katmanı arasındaki haberleşme için yazılım geliştirilmiş ve bu sayede
kullanıcı arayüzünde okunan veriler izlenip saklanabilmiştir.
Xmesh yazılımında üç ayrı güç konumu seçilebilmektedir:
26
1. Yüksek güç (high power, HP)
•
Her düğüm paket aktarımı yapabilir. (FFD özelliği)
•
Yüksek bant genişliği, düşük gecikme değerlerine sahiptir.
•
Radyo sürekli aktiftir.
2. Düşük güç (low power, LP)
•
Her düğüm paket aktarımı yapabilir. (FFD özelliği)
•
Düşük bant genişliği, yüksek gecikme değerlerine sahiptir.
•
Radyo normalde kapalıdır, periyodik olarak aktif yapılarak
havadaki trafik kontrol edilir.
3. Çok düşük güç (extended low power, ELP)
•
Düğümler paket aktarımı yapamaz. (RFD özelliği)
•
Ağaç
yapısında
yaprak düğümler (leaf nodes) için
kullanılabilir.
Geliştirilen sistemde yüksek güç seçilmiş ve böylece gecikme
değerleri asgari seviyede tutulmuştur.
Xmesh
ayrıca
düğümlerin
havadan
yazılım
güncellemesi
yapmalarına da imkan vermektedir (over-the-air-programming, OTAP).
Bu
özelliğin
çalışabilmesi
için
kablosuz
modül
ilk
defa
programlanıyorken MoteConfig penceresinde “Xotap enabled” seçilmesi
gerekir. Geliştirilen sistemde çalışma anında yazılım güncellemesi
yapılmadığından OTAP özelliği kullanılmamıştır fakat olası gelecek
çalışmalar için “Xotap enable” seçeneği şeçilmiştir.
27
Xmesh’te ağ oluşumu, paralel yürütülen iki işlemle gerçekleştirilir:
bağlantı tahmini (link estimation) ve parent seçimi (parent selection).
Her düğüm, çevresindeki radyo trafiğini dinler ve bir komşuluk
tablosu (neighborhood table) tutar. Tablodaki komşu sayısının varsayılan
değeri 16’dır. Eğer bir düğüm 16’dan fazla komşuya sahipse sinyal
seviyesini en düşük aldığı komşularını listeden siler. Baz istasyonu için
bu sayı 16 yerine 40’tır. Baz istasyonu diğer düğümler gibi uygulama
çalıştırmadığından hafızasının daha büyük bir kısmı komşuluk tablosuna
ayrılmıştır. Bu tez çalışmasında toplam bir baz istasyonu ve 6 düğüm
kullanıldığı
için
komşuluk
tablosunun
varsayılan
değerleri
değiştirilmemiştir.
Komşuluk tablosu oluşturulduktan sonra her düğüm kendi
tablosunu inceler ve baz istasyonuna gönderim yapmak için en az enerji
gerektiren komşusunu parent olarak seçer. Bir komşunun parent
seçilebilmesi için şu kriterlere uygun olması gerekir:
•
Ağa katılmış olmalı
•
Son üç RUI süresince bu düğümü parent seçmemiş olmalı
(kısır döngüleri önlemek için)
•
ELP modunda olmamalı (aksi takdirde mesajı aktaramaz)
Ağ oluşumu için her bir düğüm Rota Güncelleme (Route Update)
mesajı yayınlar (broadcast). Bu mesajda şu bilgiler bulunur:
28
•
Parent kimliği (parent ID): Eğer düğüm henüz ağa
katılmamışsa bu değer $FFFF olur.
•
Maliyet (cost): Baz istasyonuna kadar olan rotada toplam
enerji maliyetini gösterir.
•
Atlama sayısı (hop count): Baz istasyonuna kadar olan
atlama sayısını gösterir.
•
Seçilmiş komşuluk (qualified neighbor) listesi: TinyOS
paket
büyüklüğü
kısıtı
nedeniyle
rota
güncelleme
mesajlarında en fazla 5 adet komşu ismi gönderilir. Bir
komşunun seçilmiş komşu olabilmesi için RE (receive
estimate) değerinin (tanımı aşağıda açıklanacaktır) belli bir
eşik değerinden yüksek olması gerekmektedir (HP modu
için 100; LP modu için 10). Eğer seçilmiş komşu sayısı
beşten büyükse düğüm, bunları sırayla her bir rota
güncelleme mesajına 5 tane ekleyecek şekilde işler.
Rota güncelleme mesajının periyodunu “Multihop.h” dosyasındaki
RUI değişkeni belirler. Bu değer HP mod için yaklaşık 36 s; LP mod
içinse yaklaşık 360 s’dir. Tam değer ise her düğümde bu yaklaşık
değerlerin 0.9 ila 1.1 arasında seçilen rasgele bir sayıyla çarpılması ile
bulunur. Yani aslında tam değer HP mod için 32.4 s ile 39.6 s arasında
değişim gösterir; tez çalışmasında da bu değerler kullanılmıştır.
Enerji maliyeti hesabı ise aşağıda belirtilen ölçütler kullanılarak
yapılır:
29
•
RE (Receive Estimate): Belli bir komşudan alınan sinyal
kalitesini
gösterir.
Alınan
paket
yüzdesine
EWMA
(exponentially weighted moving average) algoritması
uygulanarak hesap edilir.
New_Estimate = 255 * received / (received+missed)
RE = (1-alpha) * RE + alpha * New_Estimate
Burada alpha, 0 ila 1 arasında değişen EWMA faktörüdür.
•
SE (Send Estimate): Belli bir komşuya gönderilen sinyal
kalitesini gösterir. Đlgili komşunun rota güncelleme
mesajlarından elde edilir. Bir düğümün rota güncelleme
mesajında komşuların RE değerleri de bulunduğundan, bu
düğümün komşuları kendilerinde bu düğüme olan SE
değerini de öğrenmiş olur. SE ve RE değerleri 0 ila 255
arasında normalize edilmiş değerlerdir; 255 mükemmel
kalitede haberleşme olduğunu gösterir.
•
LC (Link Cost): Belli bir komşuya olan bağlantı maliyetini
gösterir. Şu şekilde hesaplanır: LC = (1<<18) / (SE * RE).
Link kalitesi mükemmel ise, yani RE ve SE değerleri 255
ise, LC bu durumda 4 olur.
•
NC (Neighbor’s Cost): Đlgili komşunun rota güncelleme
mesajından öğrenilir ve o komşunun baz istasyonuna kadar
olan rotası için gerekli enerji maliyetini gösterir.
•
OC
(overall
cost):
Bir
mesajı
baz
istasyonuna
gönderebilmek için harcanacak toplam enerjiyi gösterir. OC
= LC + NC. En düşük OC değerine sahip komşu parent
seçilir. Yani Xmesh yönlendirme algoritması parent
30
seçimini minimum enerji ilkesine göre yapar; bu da pil
ömrünü uzatmayı amaçlamaktadır.
Ağdaki her düğüm rota güncelleme mesajı yayınladığında kendi
maliyetini de bu mesajın içinde gönderir, bu değer baz istasyonu için
sıfırdır. Her 8 RUI süresi sonunda parent seçimi işlemi yapılır. 8 RUI
boyunca bir düğümün komşularından yeteri kadar bilgi topladığı
varsayılır. Ağ oluşumunu hızlandırmak için bir de hızlı oluşum modu
vardır. Bu modda bir düğüm hızlıca bir parent edinir ve bu sayede ağa
girmiş olur, ideal parent seçimini daha sonraya bırakır. Bir düğümün ağa
katılma süresi RUI değerine ve atlama sayısına bağldır. Genel olarak baz
istasyonundan bir atlama uzaklıktaki düğümler için ağa katılma süresi 1
RUI; iki atlama uzaklıktaki düğümler için 2 RUI vd. düşünülebilir. Ağın
stabil hale gelmesi ise yaklaşık 8 RUI gibi bir zaman alır. Tez
çalışmasında bu süre yaklaşık 8 * 36 = 288 s’dir. Bu da 4.8 dakikaya
tekabül etmektedir.
2.6
Kullanıcı Arayüzü (Moteview)
Bu tez çalışmasında sensörlerden okunan verilerin saklandığı ve
görüntülendiği arayüz olarak Moteview programı kullanılmıştır. Şekil
2.5.2’de görüldüğü gibi, mote’lar TinyOS kodu ile programlanır ve
sunumcu katmanında veritabanı işlemleri gerçekleştirilir. Moteview
programında sadece Xmesh uygulamaları görüntülenebilmektedir.
31
Bu tezin yazım aşamasında programın Microsoft Vista işletim
sistemi desteği bulunmadığından, işletim sistemi olarak Windows XP
kullanılmıştır. Programın çalışabilmesi için ilaveten şu programların da
bilgisayara kurulması gereklidir:
•
PostgreSQL 8.0 database service
•
PostgreSQL ODBC driver
•
Microsoft .NET 1.1 framework
Kablosuz sensör ağı kurulurken, XmeshBase yazılımı yüklü baz
istasyonu PC’ye bağlanır. Moteview penceresi açılır ve File -> Connect
to WSN seçilir:
Şekil 2.6.1 Moteview ile sensör ağına bağlantı kurulması - Mode
32
“Gateway” tab’ında arayüz kartı olarak MIB520; ilgili port ve
57600 baud rate seçeneği birlikte seçilir:
Şekil 2.6.2 Moteview ile sensör ağına bağlantı kurulması - Gateway
“Database” tab’ında localhost yazısı ilgili parametrelerle birlikte
görülür:
33
Şekil 2.6.3 Moteview ile sensör ağına bağlantı kurulması - Database
“Sensorboard” tab’ında XMTS400 seçilir:
Şekil 2.6.4 Moteview ile sensör ağına bağlantı kurulması - Sensorboard
34
Sensör ağına yeni bir düğüm eklendiğinde bu düğüm de topoloji
ekranında otomatik olarak belirir. Moteview ana penceresi görünümü şu
şekildedir:
Şekil 2.6.5 Moteview genel görünüm
“Visualization Tabs” kısmında “Charts” sekmesi tıklanarak her bir
düğümün sensör verileri grafik olarak görülebilir ve her bir düğümün
grafiğine istenen bir renk atanabilir. Ayrıca bu ekranda zoom ve pan
yapılabilir. En fazla 3 adet grafik ekranda gösterilebilir. Bu tez
çalışmasında kandaki oksijen yüzdesi ve nabız bilgileri sensörlerden
okunduğu için iki adet grafik kullanılmıştır. En fazla 24 düğüm grafiğe
yansıtılabilir. Grafiklerde yatay eksen zamanı; dikey eksen ise sensör
verisini gösterir.
35
Ölçümler alındıktan sonra tüm veriler bir notepad veya excel
tablosu halinde saklanabilir. Ayrıca ölçüm esnasında herhangi bir
sensörden belirlenen eşik değerinin altında veya üstünde bir değer
okunduğunda eş zamanlı olarak uyarı verilmesi sağlanabilir. Uyarılar, email gönderimi ve ekrana pop-up menü çıkarılması olmak üzere iki
çeşittir:
Şekil 2.6.6 Moteview uyarı penceresi
E-mail uyarıları aşağıdaki şekilde görüldüğü gibi ilgili parametreler
girilerek etkinleştirilir:
Şekil 2.6.7 Moteview e-mail uyarı ayarları
36
3
BULGULAR
Geliştirilen sistem Ege Üniversitesi Tıp Fakültesi Hastanesi
Nöroşirurji
Bölümünde,
Prof.
Dr.
Tayfun
Dalbastı
nezaretinde
denenmiştir. 6 node , 6 sensör ve 1 baz istasyonundan oluşan sistem şu
parametrelerle kurulmuştur:
•
RUI (Route Update Interval): 36 s
•
RF kanal: 25 (2475 MHz)
RF kanal 25 (2475 MHz) seçilerek Wi-Fi cihazlarla olan etkileşim
minimuma indirilmiştir. Bu ZigBee kanalı için Wi-Fi sinyalleri geniş
bantlı gürültü olarak algılanmaktadır. Benzer şekilde, Wi-Fi cihazlar için
de bu ZigBee sinyalleri dar bantlı gürültü olarak algılanmaktadır.
Sistemi test etmek için 6 farklı senaryo düşünülmüştür. Senaryo
A’da tüm hastalar farklı odalarda sabitken ölçümler alınmış, senaryo
B’de hastalardan birinin poliklinik içinde dolaştığı durum ölçülmüştür.
Senaryo C, D, E, ve F’de ise hastalar ve baz istasyonu aynı oda içindedir
fakat node’ların RF çıkış gücü ve sensörü okuma periyotları kontrollü
olarak değiştirilmiştir. Çizelge 3.1’de senaryolar özetlenmiştir.
37
Çizelge 3.1 Senaryolar
RF güç
Sensör okuma
peiyodu
Node yerleşimi
Hareketli node
Senaryo A
0 dBm
5s
Farklı odalarda
Yok
Senaryo B
0 dBm
5s
Farklı odalarda
Var
Senaryo C
0 dBm
5s
Aynı odada
Yok
Senaryo D
-25 dBm
5s
Aynı odada
Yok
Senaryo E
-25 dBm
0.5 s
Aynı odada
Yok
Senaryo F
0 dBm
0.5 s
Aynı odada
Yok
Đlgili ağ toplojileri aşağıdaki resimlerde gösterilmiştir.
Şekil 3.1 Senaryo A ağ topolojisi
38
Şekil 3.2 Senaryo B ağ topolojisi, ilk durum
Şekil 3.3 Senaryo B ağ topolojisi, son durum
39
Şekil 3.4 Senaryo C ağ topolojisi
Şekil 3.5 Senaryo D ağ topolojisi
40
Şekil 3.6 Senaryo E ağ topolojisi
Şekil 3.7 Senaryo F ağ topolojisi
41
Senaryo A’da toplam 11 dk boyunca, senaryo B’de ise toplam 19
dk boyunca ölçüm alınmıştır. Senaryo C, D, E ve F’de ise ölçümler 5
dakika boyunca alınmıştır. Bu süreler sonundaki sistemde oluşan toplam
paket sayısı, iletilen paket sayısı, kaybedilen paket sayısı ve yeniden
deneme sayısı bilgileri not edilmiştir. Bu bilgilerin görüldüğü Moteview
pencereleri aşağıdaki resimlerde gösterilmiştir.
Şekil 3.8 Senaryo A paket bilgileri
Şekil 3.9 Senaryo B paket bilgileri
Şekil 3.10 Senaryo C paket bilgileri
42
Şekil 3.11 Senaryo D paket bilgileri
Şekil 3.12 Senaryo E paket bilgileri
Şekil 3.13 Senaryo F paket bilgileri
Senaryoların performans özeti Çizelge 3.2’de gösterilmiştir. Bu
sonuçlara göre sistemdeki paket kaybı, oksimetre sensör okuma
periyodunun 5 sn gibi kısa bir süre olmasına rağmen, kabul edilebilir
seviyede değerlendirilmiştir. Sensör okuma periyodu arttıkça toplam
paket sayısı azalacak ve böylece sistem trafik yoğunluğu azalacaktır. Bu
da iletilen ve kaybedilen paket sayısının daha da azalacağına işaret
etmektedir.
43
Çizelge 3.2 Performans bulguları
Senaryo
Senaryo
Senaryo
Senaryo
Senaryo
Senaryo
A
B
C
D
E
F
735
1180
396
362
3396
3396
151 (%
577 (%
0
147 (%
0
0
(forwarded)
20.5)
48.9)
Kaybedilen
77 (%
261 (%
(dropped)
10.5)
22.1)
Toplam paket
Đletilen
Yeniden
2322
deneme
711 (%
(%
(retries)
96.7)
196.8)
3.14’te
Çizelge
Şekil
40.6)
0
0
0
0
0
8 (%
382 (%
316 (%
2.2)
11.2)
9.3)
3.2’deki
değerler
grafiksel
olarak
sunulmuştur:
Performans Bulguları
200
180
160
140
120
Paket %
100
(normalize)
80
60
40
20
0
Toplam Paket (normalize)
Paket Kaybı %
Forwarded %
Retry %
A
B
C
D
E
F
Senaryo
Şekil 3.14 Normalize edilmiş performans bulguları
44
Her bir senaryoda üretilen toplam paket sayısı 100’e normalize
edilirse paket kaybı olarak en iyi sonucu Senaryo C,D,E ve F vermektedir
(% 0 paket kaybı). Bu beklenen bir durumdur çünkü bu senaryolarda tüm
node’lar aynı oda içindedir ve baz istasyonuna kadar olan atlama sayısı
minimumdur. Paket kaybı açısından en kötü performans ise Senaryo
B’de görülmüştür. Bu da beklenen bir durumdur çünkü hem node’lar
farklı odalara yerleştirilmiş, hem de hastalardan biri poliklinik içinde
bazen kapsama alanından çıkacak şekilde hareket etmiştir.
Aktarım yapılan (forwarded) paket sayısında ise Senaryo C,E ve F
en iyi performansa sahiptir çünkü bunlarda ağ topolojilerinden de
görüleceği üzere tüm node’lar baz istasyonunu doğrudan görmektedir.
Atlama sayısının çok olduğu Senaryo A ve B’de ise aktarım yapılan
paket sayısı diğer senaryolardan çok daha fazladır. Atlama sayısının
artması paket kaybı riskini de arttırmaktadır.
Benzer şekilde yeniden deneme sayıları (number of retries)
incelendiğinde de Senaryo B’nin en düşük performansa, Senaryo C’nin
ise en yüksek performansa sahip olduğu görülmüştür. Aynı oda içinde
ölçüm alınan senaryolar kendi aralarında kıyaslandığında Senaryo C ve
D’nin Senaryo E ve F’ye göre daha az sayıda yeniden gönderme yaptığı
görülmektedir çünkü C ve D’deki paket gönderme periyodu E ve F’ye
göre daha uzundur.
45
Paket kaybı yüzdesi, iletilen paket yüzdesi ve yeniden deneme
sayısına ilaveten sistem performansı ağ oluşum süresi, ağ kararlılığı ve
efektif bölge menzili cinsinden de ölçülmüştür.
Ağ oluşum süresi modül kartların enerji tüketmeye başladıkları ilk
andan ağa dahil oldukları ana kadar geçen süre olarak ölçülmüştür.
Xmesh kullanan benzer çalışmalardan birinde (Casias, 2007) Mica2
modül kart (916 MHz radyo frekansı) kullanılmıştır ve bu sistemde ağ
oluşum süresi 1 ila 6 dakika arasında değişmektedir. Bu süreler, bu tez
çalışmasında gerçeklenen sistemde 32 saniye ile 3.5 dakika arasında
değişmektedir. Baz istasyonuna en yakın node için bu süre 1 RUI kadar
ölçülmüştür. (Ortalama 36 s; en iyi durumda 32 saniye). Baz
istasyonundan en uzak node için atlama sayısı 6 olmuş ve bu süre 6 RUI
= 216 saniye = 3.5 dakika ölçülmüştür. Đki çalışmanın kıyaslandığı grafik
Şekil 3.15’de gösterilmiştir.
Ağ Oluşum Süresi
6
5
4
En Đyi Durum
süre (sn) 3
En Kötü Durum
2
1
0
Casias, 2007
Çetin, 2009
Çalışma
Şekil 3.15 Ağ oluşum süresi
46
Ağ kararlılığı ortalama parent değişim sayısı cinsinden ifade
edilmiştir: (Casias, 2007) çalışmasında node’lar sabitken parent değişim
sayısı 1 ila 5 arasında değişmektedir. Parent değişimi ile ağ kararlılığı
ters orantılıdır. Đdeal kararlılıktaki bir ağda parent değişim sayısı sıfır
olmalıdır. Bu tez çalışmasında gerçeklenen sistemde ise node’lar sabitken
bir node için en fazla 2 parent değişimi olduğu gözlemlenmiştir.
Normalize
edilmiş
kararlılık
kıyaslama
grafiği
Şekil
3.16’da
gösterilmiştir.
Ağ Kararlılığı (normalize)
100
90
80
70
60
Kararlılık (normalize)
50
Ağ kararlılığı
40
30
20
10
0
Casias, 2007
Çetin, 2009
Çalışma
Şekil 3.16 Ağ kararlılığı
Efektif bölge menzili, iki node arasında haberleşmenin kesilmediği
maksimum uzaklığı ifade etmektedir. Xmesh kullanan bir başka
çalışmada Mica2 modül kartlarıyla değişik güç modlarında ölçümler
47
alınarak üç farklı bölge tanımlanmıştır: link kalitesinin % 80’den yüksek
olduğu efektif bölge (effective region), link kalitesinin % 80’den küçük
olduğu fakat node’ların yine de haberleşebildiği geçiş bölgesi
(transitional region) ve node’lar arasında haberleşmenin koptuğu
güvensiz bölge (unreliable region) (Cheng, 2007). 0 dBm (1 mW) RF
çıkış gücünde efektif bölge mesafesi fiziksel engel olmayan bir bölgede
24 metre; güvensiz bölge mesafesi ise 34 metre olarak ölçülmüştür. Yani
1 mW RF çıkış gücündeki iki node arasındaki mesafe 34 metreyi
geçtiğinde bu node’lar birbirleriyle haberleşememişlerdir. Bu tez
çalışmasında kullanılan MicaZ modül kartlarıyla 1 mW RF çıkış gücünde
node’ların birbirleriyle 85 metre mesafeye kadar haberleşebildikleri
gözlemlenmiştir. Đki çalışmanın kıyaslandığı grafik Şekil 3.17’de
gösterilmiştir.
Efektif Bölge Menzili
90
80
70
60
50
Menzil (m)
Efektif Bölge Menzili
40
30
20
10
0
Cheng, 2007
Çetin, 2009
Çalışma
Şekil 3.17 Efektif bölge menzili
48
Her hastanın ölçüm sonuçları merkezi veritabanında aşağıdaki
resimlerde gösterildiği gibi toplanmaktadır. Burada her bir hastanın tüm
verileri, son 1 saatlik verileri veya son 1 günlük verileri ayrı ayrı
görülebildiği için sağlık personeline büyük kolaylık sağlamaktadır.
Şekil 3.18 Senaryo A, ölçümlerin veritabanına aktarılmış hali
49
Şekil 3.19 Senaryo B, ölçümlerin veritabanına aktarılmış hali
Şekil 3.20 Senaryo D veri grafiği, plethysmogram anlamsız, okuma periyodu: 5s
50
Şekil 3.21 Senaryo E veri grafiği, plethysmogram anlamlı, okuma periyodu: 0.5s
Şekil 3.20 ve 3.21’de görüldüğü gibi plethysmogram dalga şeklinin
anlamlı olabilmesi için sensör okuma periyodunun 500 ms veya daha
küçük olması gerekmektedir. 5 saniyelik okuma periyodunda nabız ve
SpO2 anlamlı iken plethysmogram anlamlı değildir.
Geliştirilen sistemin akım grafiği aşağıdaki resimde gösterilmiştir.
Yüksek güç modunda programlanan kablosuz modüllerin RF almagönderme birimleri sürekli açık olduğu halde ortalama akım tüketimi 31
mA ölçülmüştür. Bu da 2500 mAh kapasiteli bir çift kalem pil ile
kablosuz modül ve sensör sisteminin 2500 / 31 = 80.6 saat = 3.4 gün
boyunca çalışacabileceği anlamına gelmektedir.
51
Şekil 3.22 Mote+sensör akım grafiği
52
4
SONUÇ
Günümüzde kablosuz sensör ağlarının pek çok uygulaması
bulunmaktadır. Düşük güç tüketimi gereksinimi sebebiyle yönlendirme
algoritması, anten gücü, örnekleme hızı gibi birçok tasarım parametresi
uygulamaya özel geliştirilmektedir.
Bu tez çalışmasında kablosuz sensör ağlarının MicaZ tabanlı
biyomedikal bir uygulaması geliştirilmiş ve tasarlanan sistem Ege
Üniversitesi Hastanesi’nde test edilmiştir.
Düşük güç tüketimi desteği ve lisans gerektirmemesi sebebiyle
kablosuz haberleşme standardı olarak ZigBee seçilmiş ve bunun için
Crossbow firmasının ürettiği MicaZ kablosuz modülleri kullanılmıştır.
Pulse oximeter sensörlere bağlanan bu modüller nesC dilinde
programlanmış ve 1 baz istasyonu ile 6 adet düğümden oluşan bir
kablosuz ağ oluşturulmuştur. Hastaların nabız, pletismogram ve kandaki
oksijen oranı bilgileri kablosuz olarak merkezi veritabanına aktarılmış ve
her hasta için kişisel kayıt dosyaları oluşturulmuştur. Gerekli görülen
durumlarda her bir hasta için eşik değerleri belirlenerek bu değerlerin
aşıldığı durumlarda merkezi PC’ye görsel uyarı veya istenen adrese eposta uyarısı gönderilmiştir.
Test sonuçları, sistemin güvenilir, ölçeklenebilir ve kendi kendini
yapılandırabilir olduğunu göstermiştir. Kablolu sistemle kıyaslandığında
veri doğruluğunun istenen seviyede olduğu görülmüştür. Bluetooth ve
53
Wi-Fi gibi 2.4 GHz’de çalışan diğer sistemlerle karışım problemi
görülmemiştir.
Benzer çalışmalarla kıyaslandığında ağ oluşum süresi, ağ kararlığı
ve enerji verimliliği açısından önerilen sistemin daha yüksek performans
sağladığı görülmüştür (Casias, 2007) & (Cheng, 2005).
Đleri çalışma olarak sistemin düğüm sayıları arttırılabilir ve böylece
ölçeklenebilirliği (scalability) test edilmiş olur. Sensör veri okuma hızı
adaptif hale getirilebilir, böylece haberleşme trafiği yoğunluğu azaltılırak
paket kayıpları azaltılabilir. Örneğin bir hastadaki verilerin tümünü
göndermek yerine sadece önceden belirlenen bir değer aralığının
dışındaki
ölçüm
sonuçları
baz
istasyonuna
gönderilebilir
(data
aggregation). Bu yöntemle enerji tüketiminin ve dolayısıyla pil ömrünün
nasıl değiştiği incelenebilir. Ayrıca, pulse oximeter haricindeki
sensörlerle daha farklı türde veri ölçümü yapılabilir. Örneğin güneş
enerjisi panellerinin adaptif olarak güneşi takip etmesini sağlamak için bu
sensör
ağı
,
fotosensör
bağlanarak
kullanılabilir.
Yönlendirme
mekanizması için yapay zeka kullanılabilir (Chang et.al., 2004): ağın
geçmiş bilgileri kullanılarak yönlendirme algoritması dinamik biçimde
değiştirilebilir.
54
KAYNAKLAR DĐZĐNĐ
Casias, J.F, 2007, “Performance of Wireless Unattended Sensor
Network in Maritime Applications”, Master Thesis, Naval Postgraduate
School, Monterey, California
Chang, Y.H., Ho, T., Kaelbling, L.P., 2004, “Multi-agent Learning in
Mobilized Ad-hoc Networks”, AAAI Symposium.
Cheng Kiat Amos, T., 2005, “Performance Evaluation of a Ruting
Protocol in Wireless Sensor Networks”, Master Thesis, Naval
Postgraduate School, Monterey, California
CodeBlue Project, http://fiji.eecs.harvard.edu/CodeBlue
Cvrcek, D., Lewis, M., Stajano, F., 2008, “Security of Mica-Based /
ZigBee Wireless Sensor Networks”, Cambridge University Computer
Lab & Brno University of Technology.
Dagtas, S., Pekhteryev, G., and Sahinoglu, Z., 2007, “Multi-stage real
time health monitoring via ZigBee in smart homes”, Mitsubishi
Electric Research Laboratories.
Ergen, S.C., 2004, “ZigBee/IEEE 802.15.4 summary”.
Hofmann, C., Weigand, C., and Bernhard, J., 2006, “Evaluation of
ZigBee for medical sensor networks”, WSEAS Trans. Electr.,
pp.121– 125.
Hong, J.H., Kim, N.J., Cha, E.J., and Lee, T.S., 2006, “Development
of ZigBee-based mobile healthcare system”, IFMBE Proceedings,
Volume 6, JC27.
Moteview User Manual, May 2007, Revision A, Crossbow Inc.
MoteWorks Getting Started Guide, 2007, Revision E, Crossbow Inc.
55
Park, J., Cho, J., Choi, J., and Nam, T., 2007, “A ZigBee networkbased multi-channel heart rate monitoring system for exercising
rehabilitation patients”, IEEE.
Reddy, J.S., 2004, ZigBee Security, www.zigbee.org
Sokullu, R., Korkmaz, Đ., Dağdeviren, O., 2009, “GTS Attack: An
IEEE 802.15.4 MAC Layer Attack in Wireless Sensor Networks”,
IARIA Journal.
Ubimon Project, http://www.doc.ic.ac.uk/vip/ubimon/home/index.html
Valdastri, P., Rossi, S., Menciassi, A., Lionetti, V., Bernini, F.,
Recchia, F.A., and Dario, P., 2007, “An implantable ZigBeeready telemetric platform for in-vivo monitoring of physiological
parameters”, Elsevier.
XMesh User Manual, April 2007, Revision D, Crossbow Inc.
Yu, H.C., and Tseng, S.M., 2007, “A wireless based sensor for patient
monitoring system with remote diagnostic”, 3rd International
Conference on Networking and Services.
ZigBee Alliance, http://www.zigbee.org
56
EKLER
Ek 1 “Makefile” Dosyası
Ek 2 “Makefile.component” Dosyası
Ek 3 “XMTS400.nc” Dosyası
Ek 4 “XMTS400M.nc” Dosyası
Ek 5 “appFeatures.h” Dosyası
Ek 6 “appPacket.h” Dosyası
Ek 7 “sensorboardApp.h” Dosyası
57
Ek 1 “Makefile” Dosyası
# $Id: Makefile,v 1.1.2.1 2006/09/29 08:28:32 chenrl Exp $
include Makefile.component
include ../../MakeXbowlocal
GOALS += binlink
include $(MAKERULES)
58
Ek 2 “Makefile.component” Dosyası
# $Id: Makefile.component,v 1.1.2.1 2006/09/29 08:28:33 chenrl Exp $
COMPONENT=XMTS400
SENSORBOARD=mts400
MSG_SIZE=55
59
Ek 3 “XMTS400.nc” Dosyası
// Receive UART data from pulse oximeter sensor
// and send it to Base Station using XMesh
#include "appFeatures.h"
includes sensorboardApp;
configuration XMTS400 {
// this module does not provide any interface
}
implementation {
components Main, MicaWbSwitch,
GenericCommPromiscuous as Comm,
MULTIHOPROUTER,XMTS400M, QueuedSend,
UART, TimerC, LedsC, Bcast;
Main.StdControl -> XMTS400M;
Main.StdControl -> QueuedSend.StdControl;
Main.StdControl -> MULTIHOPROUTER.StdControl;
Main.StdControl -> Comm;
Main.StdControl -> TimerC.StdControl;
XMTS400M.UARTControl -> UART;
XMTS400M.ByteComm -> UART.ByteComm;
60
XMTS400M.RouteControl -> MULTIHOPROUTER;
XMTS400M.Send ->
MULTIHOPROUTER.MhopSend[AM_XMULTIHOP_MSG];
XMTS400M.Timer -> TimerC.Timer[unique("Timer")];
XMTS400M.Leds -> LedsC.Leds;
MULTIHOPROUTER.ReceiveMsg[AM_XMULTIHOP_MSG] ->
Comm.ReceiveMsg[AM_XMULTIHOP_MSG];
XMTS400M.HealthMsgGet -> MULTIHOPROUTER;
XMTS400M.health_packet -> MULTIHOPROUTER.health_packet;
}
61
Ek 4 “XMTS400M.nc” Dosyası
#include "appFeatures.h"
module XMTS400M {
provides interface StdControl;
uses
{
interface MhopSend as Send;
interface RouteControl;
interface StdControl as UARTControl;
interface ByteComm;
interface Timer;
interface Leds;
command void health_packet(bool enable, uint16_t intv);
command HealthMsg* HealthMsgGet();
}
}
implementation
{
enum {START, BUSY};
norace uint8_t main_state;
// main state of the schedule
norace uint8_t counter;
norace uint8_t select;
norace bool sending_packet;
norace bool timer_busy;
norace bool oxygen;
// decodes bit 1 of Byte 0.
62
norace bool heart_rate;
TOS_Msg msg_buf_radio;
TOS_MsgPtr msg_radio;
norace XDataMsg readings;
HealthMsg *h_msg;
task void send_radio_msg() {
uint8_t i;
uint16_t len;
XDataMsg *data;
// Fill the given data buffer.
data = (XDataMsg *)call Send.getBuffer(msg_radio, &len);
for (i = 0; i < sizeof(XDataMsg); i++)
((uint8_t*)data)[i] = ((uint8_t*)&readings)[i];
data->xmeshHeader.board_id = SENSOR_BOARD_ID;
data->xmeshHeader.packet_id = 6;
data->xmeshHeader.parent = call RouteControl.getParent();
data->xmeshHeader.packet_id = data->xmeshHeader.packet_id |
0x80;
if (call
Send.send(BASE_STATION_ADDRESS,MODE_UPSTREAM,
msg_radio, sizeof(XDataMsg)) != SUCCESS) {
atomic {
sending_packet = FALSE;
main_state = START;
63
}
}
return;
}
command result_t StdControl.init() {
atomic {
msg_radio = &msg_buf_radio;
sending_packet = FALSE;
timer_busy = FALSE;
oxygen = FALSE;
heart_rate = FALSE;
counter = 100;
select = 100;
}
call UARTControl.init();
call Leds.init();
return SUCCESS;
}
command result_t StdControl.start() {
atomic main_state = START;
h_msg = call HealthMsgGet();
h_msg->rsvd_app_type = SENSOR_BOARD_ID;
call health_packet(TRUE,TOS_HEALTH_UPDATE);
call UARTControl.start();
64
return SUCCESS;
}
command result_t StdControl.stop() {
call UARTControl.stop();
return SUCCESS;
}
async event result_t ByteComm.rxByteReady(uint8_t data, bool
error, uint16_t strength) {
if(timer_busy)
return SUCCESS;
if((data & 0xFE) == 0x80) { // Byte3 is oxygen
atomic counter = 0;
atomic select = 0;
call Leds.redToggle();
return SUCCESS;
}
if((data & 0xFE) == 0x82) { // Byte3 is heart rate
atomic counter = 0;
atomic select = 2;
call Leds.redToggle();
return SUCCESS;
}
counter++;
if(counter = = 1) {
// Byte 1 gives plethysmogram
65
readings.xData.data6.temp = data;
// humtemp in MoteView shows
// plethysmogram data [0-100]
// 50: no finger in sensor
}
if(counter = = 3) {
if (select = = 0) {
readings.xData.data6.vref = data; // vref
//(voltage) in MoteView shows oxygen
//percentage [0-99], 127: invalid
atomic oxygen = TRUE;
}
if (select = = 2) {
readings.xData.data6.humidity = data;
//humidity in MoteView shows heart rate
//[30-126], 127: invalid
atomic heart_rate = TRUE;
}
if ((oxygen) & (heart_rate)) {
atomic main_state = BUSY;
if(!sending_packet) {
sending_packet = TRUE;
post send_radio_msg();
}
call Timer.start(TIMER_ONE_SHOT,
5000);
66
atomic timer_busy = TRUE;
atomic counter = 100; // set counter to
//invalid
atomic select = 100;
atomic oxygen = FALSE;
atomic heart_rate = FALSE;
return SUCCESS;
}
}
return SUCCESS;
}
event result_t Timer.fired() {
call Leds.yellowToggle();
atomic timer_busy = FALSE;
return SUCCESS;
}
async event result_t ByteComm.txDone() {
return SUCCESS;
}
async event result_t ByteComm.txByteReady(bool success) {
return SUCCESS;
}
67
event result_t Send.sendDone(TOS_MsgPtr msg, result_t success)
{
atomic {
msg_radio = msg;
sending_packet = FALSE;
}
atomic main_state = START;
call Leds.greenToggle();
return SUCCESS;
}
}
68
Ek 5 “appFeatures.h” Dosyası
// FEATURE_LEDS -- powers up the LEDs for debugging purposes
#ifndef FEATURE_LEDS
#define FEATURE_LEDS
0
#endif
#define SENSOR_BOARD_ID 0x85
//MTS400 sensor board id
/** FEATURE_LEDS will enable debugging Leds when set to 1. */
#if FEATURE_LEDS
#define LEDS_COMPONENT
#define LEDS_WIRING(X)
LedsC,
X.Leds -> LedsC;
#else
#define LEDS_COMPONENT
#define LEDS_WIRING(X)
#endif
NoLeds,
X.Leds -> NoLeds;
69
Ek 6 “appPacket.h” Dosyası
#ifndef __APP_PACKET_H__
#define __APP_PACKET_H__
#include "XPacket.h"
#include "sensorboardApp.h"
enum { AM_APPPACKET = AM_XMULTIHOP_MSG };
typedef struct AppPacket {
TosHeader_t
am;
XMeshHeader_t xmesh;
XDataMsg
} AppPacket;
#endif
data;
70
Ek 7 “sensorboardApp.h” Dosyası
// controls for the voltage reference monitor
#define MAKE_BAT_MONITOR_OUTPUT() sbi(DDRA, 5)
#define MAKE_ADC_INPUT() cbi(DDRF, 7)
#define SET_BAT_MONITOR() sbi(PORTA, 5)
#define CLEAR_BAT_MONITOR() cbi(PORTA, 5)
typedef struct XMeshHeader{
uint8_t board_id;
uint8_t packet_id; // 3
uint16_t parent;
}__attribute__ ((packed)) XMeshHeader;
typedef struct Pmts400 {
// packet 3
uint16_t vref;
uint16_t humidity;
uint16_t temp;
uint16_t cal_word1;
//!< Pressure calibration word 1
uint16_t cal_word2;
//!< Pressure calibration word 2
uint16_t cal_word3;
//!< Pressure calibration word 3
uint16_t cal_word4;
//!< Pressure calibration word 4
uint16_t intersematemp;
uint16_t intersemapressure;
71
uint16_t taosch0;
uint16_t taosch1;
uint16_t accel_x;
uint16_t accel_y;
} __attribute__ ((packed))Pmts400;
typedef struct XDataMsg {
XMeshHeader xmeshHeader;
union {
Pmts400
data6; //mts400
}xData;
} __attribute__ ((packed))XDataMsg;
enum {
BATT_TEMP_PORT = 7,
//adc port for battery voltage
};
enum {
AM_XDEBUG_MSG
= 49,
AM_XSENSOR_MSG = 50,
AM_XMULTIHOP_MSG = 51,
};
// xsensor multihop
72
// Zero out the accelerometer, chrl@20061206
#define ACCEL_AVERAGE_POINTS 3
#ifdef APP_RATE
uint32_t XSENSOR_SAMPLE_RATE = APP_RATE;
#else
#ifdef USE_LOW_POWER
uint32_t XSENSOR_SAMPLE_RATE = 184320;
#else
uint32_t XSENSOR_SAMPLE_RATE = 7680; // 7.5 sec
#endif
#endif
uint32_t timer_rate;
73
ÖZGEÇMĐŞ
Kişisel Bilgiler:
Adı Soyadı
Hüseyin Ertürk ÇETĐN
Uyruğu
T.C.
Doğum Tarihi
21.12.1980
Medeni Hali
Evli
Eğitim Durumu:
2005 – 2009
Yüksek Lisans, Ege Üniversitesi
Elektrik-Elektronik Mühendisliği
1998 – 2003
Lisans, Orta Doğu Teknik Üniversitesi
Elektrik-Elektronik Mühendisliği
Đş Deneyimi:
2009 -
Uzman Sistem Mühendisi, Haberleşme
Cihazları, Aselsan A.Ş., Ankara
2004 – 2009
Kıdemli Sistem Tasarım Mühendisi, LCDTV Ar-Ge, Vestel Elektronik A.Ş., Manisa