kablosuz sensor aglarinin micaz tabanli biyomedikal uygulamasi
Transkript
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