Wireless Sensor Networks: Sensor Network Platforms & Tools

Marko Wallin, TiTe 4

Jani Kaminen, TiTe 4

Sensorisolmujen laitteisto Yleiskäyttöiset tietokoneet

Sulautetut PC:t, custom-design PC:t, PDA:t WIN CE, Linux; Bluetooth, WLAN Prosessointikyky, laaja sensorivalikoima, sähkönkulutus

Sulautetut sensorisolmut Berkeley motes, UCLA Medusa, MIT mikroAMP Kaupallisia piirejä, tuki C-kielelle (tai vastaava) Rautataso, ei juurikaan käyttöjärjestelmän tukea TinyOS ja nesC

System-on-chip (SoC) solmut Smart Dust, BWRC picoradio solmu, PASTA solmu Uudelleenajateltu laitteistoarkkitehtuuri Uusia tapoja integroida CMOS, MEMS ja RF tekniikat Kehitysasteella

Berkeley Motes

Sulautettujen sensorisolmujen –perhe Jakaa suunnilleen saman arkkitehtuurin

MICA mote arkkitehtuuri 512KB flash ja 4KB data muisti,

Lisäksi erillinen 512KB flash-muisti

40kbps datarate, 300 jalkaa (~100m) kantama, I/O liitäntä

Sensorit, ”actors”, sarja- ja rinnakkais I/O kortit

Huomattavat erot aktiivisen, idlen ja suspend tilojen välillä -> suspendiin aina kun mahdollista

SN:n ohjelmoinnin haasteet

SN-sovelluksen ohjelmointi eroaa hajaute-tusta systeemi- tai tietokantaohjelmoinnista

Otettava huomioon useita tekijöitä: Energian kulutus, kaistanleveys, laskenta,

tallennustila ja reaaliaikaisuus Infrastruktuurin (epä)luotettavuus

Suunnittelussa huomioitava epävarmuus: Signaalien kohina, yhtäaikaiset tapahtumat,

kommunikointi- ja laskenta-aika, epäluotettava kommunikointi jne.

SN:n ohjelmoinnin haasteet

perinteiset ohjelmointiteknologiat luottavat käyttöjärjestelmän tarjoamiin palveluihin Prosessointi, I/O, verkkotoiminnat, käyttäjän

interaktio laitteiston kanssa sensoriverkoissa sovellusohjelmoijien pitää

tarkasti käsitellä: Viestien liikkuminen, tapahtumien synkronointi,

keskeytysten hallinta, sensorien lukeminen sulautettu käyttöjärjestelmä paljastaa yleensä

ohjelmoijalle enemmän laitteistotasoa Ei sovellu sensoriverkkojen ohjelmointiin

SN:n ohjelmoinnin haasteet

Sensoriverkot ovat hajautettuja järjestelmiä Hajautetut algoritmit vaikeita toteuttaa Rajatut ominaisuudet (virta, muisti, kaista)

Vastetarve useisiin samanaikaisiin virikkeisiin

Ei yleistä suunnittelumetodia sovelluksille Erilaiset tehtävät ja sensorien organisointi

vaikuttavat metodien ja alustojen paremmuuteen Client-server malli, puu-rakenne, liikkuva kohde...

parempia suunnittelumalleja tarvitaan

Solmutason ohjelmistoalustat

Tyypilliset käyttöjärjestelmät tarjoavat palveluita sovelluksille Tiedostonhallinta, muistinvaraus, tehtävien

ajoitus, laiteajurit ja verkkotoiminnot Sulautetuissa järjestelmissä kompromissejä

palveluiden tarpeen mukaan Jos tiedostonhallintaa ei tarvita, sitä ei ole Jos dynaamista muistinvarausta ei tarvita,

voidaan muistinvarausta yksinkertaistaa

Käyttöjärjestelmä: TinyOS

Tukee SN-sovelluksia resurssirajatussa laitteistoympäristössä (Berkeley motes)

Rajatut ominaisuudet Ei tiedostojärjestelmää, staattinen muistinhallinta,

yksinkertainen tehtävä-malli, minimaaliset laite- ja verkkotoiminnot

komponenttien kerrostus ja uniikki komponenttiarkkitehtuuri

Useimmat komponentit: Koteloivat ohjelmatoimintoja Ohut pinta laitteistotason päällä

Käyttöjärjestelmä: TinyOS Sovelluksella on kaksi kontekstia: tehtävä ja

tapahtuma Tehtävien suoritus lisäysjärjestyksessä

Tehtävät ovat keskeytyksemättömiä (nonpreemptive) CPU uni-tilaan jos jono tyhjä

Tapahtumat voivat keskeyttää tehtäviä ja muita tapahtumia Tapahtumien jako pieniin suoritusosiin

Split-phase operaatiot Metodin kutsu palautuu takaisin, toiminto ajoitetaan

suoritettavaksi myöhemmin

TinyOS:n suunnittelu pohjautuu erittäin kevyeen järjestelmään

Kompromissit jäävät sovellusohjelmoijan huoleksi

Imperative Language: nesC

Laajennus C-kieleen Tukemaan ja kuvaamaan TinyOS v.1.0:n

suunnittelua Tarjoaa kielirakenteita ja rajoitteita TinyOS:n

komponenttien ja sovellusten toteuttamiseen nesC komponentit luokiteltu rajapintoihin:

”tarjoaa”: metodeja ylemmälle kerrokselle ”käyttää”: piilottaa alemman kerroksen

Rajapintojen välillä: ”tapahtuma” ja ”käsky” -kutsut

Imperative Language: nesC

Kaksi komponettia riippuen käytöstä: Moduulit: käytetään sovelluskoodissa

käsky / tapahtuma ”bar” rajapinnassa ”foo”; foo.bar Konfiguraatiot: rajapintojen yhdistäminen

olemassaoleviin komponentteihin kilpailutilanteen estämiseksi koodi voi olla

Asynkroninen koodi (AC): saavutettavissa vähintään yhdestä keskeytyksen

käsittelijästä Synkroninen koodi (SC):

koodi on saavutettavissa vain tehtävistä

Dataflow-Style Language: TinyGALS

Datavirtakielet omiaan kuvaamaan toisiinsa liittyvien datayksikköjen laskentaa

Globaalisti asynkroninen ja paikallisesti synkroninen (GALS) mekanismi Keino toteuttaa tapahtumasta-laukeava

samanaikainen tehtävänsuoritus TinyGALS on tälläinen kieli TinyOS:lle Vastaa samanaikaisuuteen systeemitasolla

nesC komponenttitasolla