TIETOTEKNIIKAN OSASTO

Tero Puhakka

DYNAAMISESTI KONFIGUROITAVAN SENSORISOLMUN PERUSRATKAISU REST-

ARKKITEHTUURILLA

DiplomityöTietotekniikan koulutusohjelma

Huhtikuu 2014

Puhakka T. (2014) Dynaamisesti konfiguroitavan sensorisolmun perusratkaisuREST-arkkitehtuurilla. Oulun yliopisto, sähkö- ja tietotekniikan osasto. Diplomityö,59 s.

TIIVISTELMÄ

Sensoriverkot koostuvat yleensä useista sulautetuista laitteista (sensorisolmuista).Tyypillinen sensorisolmu koostuu pienestä mikroprosessorista, lähetin-vastaanot-timesta (radiosta), sensoreista sekä lähtökohtaisesti paristoilla toimivasta virran-syötöstä.

6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) ja IPv6(Internet Protocol version 6) ovat kiihdyttäneet langattomien sensoriverkkojenja älykkäiden laitteiden integraatiota Internetiin. Samaan aikaan CoAP (Con-strained Application Protocol) on mahdollistanut resurssirajoitteisille laitteilleRESTful-web-palvelut (Representational State Transfer). Internet protokollien(Internet Protocol, IP) käyttö on myös perusedellytys esineiden ja asioiden In-ternetin (Internet of Things, IoT) näkemykselle, minkä tulevaisuudessa voitaisiinInternetiin yhdistää lähestulkoon mitä vain.

Tässä työssä käydään läpi erilaisia näkemyksiä tulevaisuuden teknologiasuun-tauksista. Esitellään vähävirtaisille ja vähäresurssisille langattomille sensoriver-koille soveltuvia verkon yli toteutettavia dynaamiseen konfiguraatioon keskittyviäratkaisuja. Sekä pohditaan missä RESTful-arkkitehtuuria on järkevä hyödyntää.

Työssä esitellään perusratkaisu dynaamiselle konfiguraatiolle langattomassasensorisolmussa, ja käydään toteutus sekä testaus vaihe vaiheelta läpi.

Avainsanat: dynaaminen konfiguraatio, REST-arkkitehtuuri, CoAP, sensoriver-kot

Puhakka T. (2014) Basic solution for dynamically re-configurable sensor nodeusing REST architecture. Department of Electrical and Information Engineering,University of Oulu, Oulu, Finland. Master’s thesis, 59 p.

ABSTRACT

Sensor networks usually consists variety of embedded devices (sensor nodes).Typical sensor node consists a small microprocessor, transceiver (radio), sensorsand an energy source (battery).

6LoWPAN and IPv6 have accelerated the integration between the Internet andwireless sensor networks of smart objects. At the same time CoAP has made itpossible for constrained devices to use RESTful web applications. The use of IPis also a prerequisite for the realization of IoT, which suggests that in the futurewe could connect almost anything to the Internet.

In this thesis we go through different kinds of perspectives of future technolo-gies. Present dynamically re-configurable methods for low power and constrainedwireless sensor networks. And will take a look where it is smart to use RESTfularchitecture.

This thesis also includes basic solution for re-configurable wireless sensor nodeusing REST architecture. And step by step we go through implementation andtesting.

Keywords: dynamic re-configuration, REST architecture, CoAP, sensor net-works

SISÄLLYSLUETTELO

TIIVISTELMÄ

ABSTRACT

SISÄLLYSLUETTELO

ALKULAUSE

LYHENTEIDEN JA MERKKIEN SELITYKSET

1. JOHDANTO 10

2. TAUSTA 112.1. Internet protokolla . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1. Internet protokollan tiedonsiirto . . . . . . . . . . . . . . . . 122.1.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.3. µIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Esineiden ja asioiden Internet . . . . . . . . . . . . . . . . . . . . . . 142.2.1. Internet protokolla on kaikkialla . . . . . . . . . . . . . . . . 152.2.2. WoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3. IP:n skaalautuvuus . . . . . . . . . . . . . . . . . . . . . . . 16

2.3. Langaton sensoriverkko . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1. Sensorisolmu . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.3. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.4. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.5. REST-arkkitehtuurin käyttöaste . . . . . . . . . . . . . . . . 212.3.6. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.7. CoRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3. CONTIKI-KÄYTTÖJÄRJESTELMÄ 253.1. Käyttöjärjestelmäydin . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2. Prosessit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3. Protosäikeet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4. Erbium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5. RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6. SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7. Vähävirtaiset MAC-protokollat . . . . . . . . . . . . . . . . . . . . . 28

3.7.1. ContikiMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7.2. X-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.8. Cooja-simulaattori . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. SENSORIVERKKOJEN WEB-PALVELUTUET 324.1. Mobiili web-palvelut . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.2. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.1. WOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4. RESTful-web-palvelu . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4.1. HATEOAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4.2. Välimuistitus . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4.3. Ylläpito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4.4. Turvallisuus ja yksityisyys . . . . . . . . . . . . . . . . . . . 38

4.5. RESTful ja muita web-palveluratkaisuja . . . . . . . . . . . . . . . . 39

5. OHJELMATOTEUTUS 405.1. Ohjelmakoodin suoritusmalleja ja uudelleenohjelmointi . . . . . . . . 40

5.1.1. Skriptauskielet . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.2. Virtuaalikoneet . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.3. Natiivikoodi . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.4. Erilaisuuksiin perustuva lähestymistapa . . . . . . . . . . . . 41

5.2. Ladattava moduuli . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.1. Esilinkitetty moduuli . . . . . . . . . . . . . . . . . . . . . . 435.2.2. Dynaaminen linkitys . . . . . . . . . . . . . . . . . . . . . . 43

5.3. REST-moottori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.1. Resurssi ja resurssin käsittelijäfunktio . . . . . . . . . . . . . 455.3.2. CoAP-viesti . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.3. Blockwise-siirto . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4. Toteutusalustan toimintamalli . . . . . . . . . . . . . . . . . . . . . . 465.4.1. CoAP-agentti . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4.2. RPL-reititin . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.4.3. Sensorisolmu . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6. OHJELMATOTEUTUKSEN TESTAUS 496.1. Testauksen jälkipyykki . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1. Onko REST valmis yrityskäyttöön? . . . . . . . . . . . . . . 50

7. YHTEENVETO 51

8. LÄHTEET 52

ALKULAUSE

Työssä tullaan räjäyttämään lukijan tajunta kirkkain ja kuuluvin värein. Se mitä oli, eiole ja se mitä tulee, on tässä; rajoja rikkovassa diplomityössä.

Haluan kiittää visionääriseltä johtoportaalta saamaani tukea, ja tästä tietysti erityis-kiitokset Ollille sekä Teemulle. Yläfemmat myös pappa Hautalalle (TS318 - Neverforget), Timbelle, Puputille, Alexille ja Kytsille.

Kiitän ja kumarran!

Prison is a state of mind

http://kindofnormal.com/wumo/ - Tekijät: Mikael Wulff ja Anders Morgenthaler -Kuvan käyttöoikeuden on myöntänyt Dennis Krogsgaard Højlund - Manager of

content and social media in Wulffmorgenthaler.

LYHENTEIDEN JA MERKKIEN SELITYKSET

6LoWPAN IPv6 over Low power Wireless Personal Area Networks,Internet-protokollan versio 6 vähävirtaisille langattomilleverkoille

ACK Acknowledgement message, hyväksyntäviestiAjax Asynchronous JavaScript and XML, asynkroninen JavaScript

ja XMLAPI Application Protocol Interface, sovellusrajapintaASP Active Server Page, aktiivinen palvelinsivuBASIC Beginner’s All-purpose Symbolic Instruction Code,

ohjelmointikieliB-MAC Minimalistic MAC protocol, minimalistinen MAC-protokollaBoX-MAC MAC protocol for ultra low power wireless networks, erittäin

vähävirtainen MAC-protokolla langattomille verkoilleBroadcast Distribution of audio and video content to a dispersed

audience via any audio or visual mass communications medium,äänen ja kuvan jakamista välikerroksessa

BSD Berkeley Software Distribution, avoimen lähdekoodin lisenssiCoAP Constrained Application Protocol, rajoitettu sovellusprotokollaContikiMAC Contikille kehitetty erittäin vähävirtainen MAC-protokollaCoRE Constrained RESTful Environment, rajoitettu REST-ympäristöCRUD Create Retrieve Update Delete, luoda, hakea, päivittää, poistaaCSMA/CA Carrier sense multiple access with collision avoidance,

CSMA-tekniikka datapakettien yhteentörmäysestollaDeluge Reliable data dissemination protocol for large objects,

luotettava tiedon levitys protokolla suurille tiedostoilleDLNA Digital Living Network Alliance, digitaalinen verkkoallianssiDS Differentiated services, protokolla verkkoliikenteen määrittelyyn

sekä kontrollointiin priorisoinnillaDuty cycle Refers to the time that a machine spends in an active state as

a fraction of the total time under consideration, aika minkä laiteon päällä verraten siihen minkä se on pois päältä tietyssäaikaikkunassa

DSLw Data-Link Switching, tietoyhteyden ohjausDSP Digital Signal Processing, digitaalinen signaalinkäsittelyDTLS Datagram Transport Layer Security, datagrammin

siirtokerrosturvallisuusECMAScript Scripting language standardized by Ecma International,

skriptauskieliELF Executable and Linkable Format, suorittuva sekä linkittyvä

formaattiErbium Low-power REST Engine for Contiki, vähävirtainen

REST-moottori Contiki-käyttöjärjestelmälleGCC GNU Compiler Collection, GNU-kääntäjäHATEOAS Hypermedia as the Engine of Application State, sovellustilan

hypermediamoottoriHTML Hyper Text Markup Language, hyperteksti merkkikieliHTTP Hyper Text Transfer Protocol, hyperteksti siirto protokollaHTTPS Hypertext Transfer Protocol Secure, turvallinen HTTPICMP Internet Control Message Protocol, Internetin

viestikontrolliprotokollaIEEE Institute of Electrical and Electronics Engineers, kansainvälinen

tekniikan alan järjestöIEEE 802.15.4 Standard for low-rate wireless personal area networks,

standardi vähäkuormitteisille langattomille henkilökohtaisillealueverkoille

IETF Internet Engineering Task Force, Internet-protokollienstandardoinnista vastaava organisaatio

IoT Internet of Things, Esineiden ja asioiden InternetIP Internet Protocol, Internet protokollaIPv4 Internet Protocol version 4, Internet-protokolla versio 4IPv6 Internet Protocol version 6, Internet-protokolla versio 6IPX Internetwork Packet Exchange, verkonsisäinen paketinvaihtoJavaScript Interpreted web programming language, Web-ympäristössä

käytettävä komentosarjakieliJSON JavaScript Object Notation, yksinkertainen tiedonsiirtomuotoJINI Network architecture for the construction of distributed systems

in the form of modular co-operating services, verkkoarkkitehtuurihajautetuille palveluille

LLN Low power Lossy Networks, vähävirtaiset ja häviölliset verkotLPP Low Power Probing, vähävirtainen kyselyLR-WPAN Low-Rate Wireless Personal Area Network, vähäkuormitteinen

WPANM2M Machine-to-Machine, kahden laitteen välinen interaktioMAC Media/Medium access control, linkkikerroksen kommunikaatio

protokollaMCU Microcontroller Unit, mikrokontrolleriyksikköMicro IP/µIP Open TCP/IP stack utilized in tiny microcontrollers,

mikro-Internet-protokolla pienille mikrokontrollereilleMIME Multipurpose Internet Mail Extensions, standardi joka laajentaa

tukea sähköpostiinPC Personal Computer, henkilökohtainen tietokoneNULLMAC MAC protocol which does nothing, tyhjä MAC-protokolla, joka

ei tee mitäänPDA Personal Digital Assistant, kämmentietokonePHP Server-side scripting language, palvelinpuolen komentosarjakieliPPP Point-to-Point Protocol, päästä-päähän-protokollaProtothread Extremely lightweight stackless thread designed for severely

memory constrained systems, erittäin kevyt pinoton säiemuistirajoitetuille järjestelmille

Python General-purpose high-level programming language, yleinenkorkean tason ohjelmointikieli

QoS Quality of Service, palvelun laatuRAM Random Access Memory, keskusmuistiRDC Radio Duty Cycling Protocol, RDC-protokollaRDF Resource Description Framework, resurssien kuvauskehysReLL Resource Linking Language, resurssien linkitysprotokollaREST/RESTful Representational State Transfer, ohjelmasovellus-

arkkitehtuurimalliRFC Request for Comments, IETF-organisaation julkaisemia

Internetiä koskevia standardeja teknisille laitteilleRIME A Lightweight Layered Communication Stack for Sensor

Networks, kevyt kerroksittainen kommunikaatiopinosensoriverkoille

RIPL Remote Initial Program Load, etäohjain ohjelman alustamiseenRMM Richardson Maturity Model, Richardsonin kypsyysmalliROA Resource-Oriented Architecture, resurssiorientoitunut

arkkitehtuuriROM Read Only Memory, pysyväismuistiRPC Remote Procedure Call, etäproseduurikutsuRPL IPv6 Routing Protocol for Low power and Lossy Networks,

IPv6 reititysprotokolla vähävirtaisille sekä häviöllisille verkoilleSICS Swedish Institute of Computer Science, Ruotsin tietotekniikan

osastoSLIP Serial Line Internet Protocol, sarjaväyläinen IPSNA System Network Architecture, järjestelmäverkkoarkkitehtuuriSOA Service-Oriented Architecture, palveluorientoitunut arkkitehtuuriSOAP Simple Object Access Protocol, yksinkertainen objektinhallinta-

protokollaTCP Transmission Control Protocol, siirron kontrolliprotokollaTCL Tool Command Language, työkalukomentokieliUDDI Universal Description Discovery Integration, alustariippumaton

ja avoin palvelurekisteristandardiUDP User Datagram Protocol, yhteydetön protokollaUnicode Tietokonejärjestelmiä varten kehitetty merkistöstandardiUnix Laitteistoriippumaton käyttöjärjestelmäUPnP Universal Plug and Play, valmistajariippumaton protokollajoukkoURI Uniform Resource Identifier, yhtenäinen resurssi-indentifioijaURL Uniform Resource Locator, yhtenäinen resurssipaikanninURN Uniform Resource Name, yhtenäinen resurssinimiUSB Universal Serial Bus, universaali sarjaväyläVINES Virtual Integrated Network Service, integroitu virtuaalinen

verkkopalveluVPN Virtual Private Network, virtuaalinen yksityisverkkoWADL Web Application Description Language, web-applikaation

kuvauskieliWEB World Wide Web, maailmanverkkoWOA Web Oriented Architecture, web-orientoitunut arkkitehtuuriWoT Web of Things, asioiden verkko

WS Web Services, web-palvelutWSDL Web Service Description Language, web-palveluiden kuvauskieliWSN Wireless Sensor Network, langaton sensoriverkkoWSS Web Service Security, web-palveluiden turvallisuusWPAN Wireless Personal Area Network, langaton henkilökohtainen

alueverkkoWWW World Wide Web, maailmanlaajuinen verkkoXNP TinyOS software for network programming, verkko-ohjelmoinnin

toteutus TinyOS:lleX-MAC A low power MAC protocol for WSN, vähävirtainen MAC-

protokolla WSN:lleXML Extensive Markup Language, laaja merkintäkieliXOT X.25 Over TCP, X.25-pakettin välitys TCP:n yli

1. JOHDANTO

Langattomia sensoriverkkoja (Wireless sensor network, WSN) hyödynnetään monen-laisissa mittausta vaativissa tilanteissa; kuten ympäristöön kohdistuvissa monitoroin-neissa [1, 2], rakennusten automaatiossa [2, 3], elinolosuhteiden seurannassa [2, 4, 5],älykkäissä kaupungeissa[2], kulkuvälineissä [2] sekä terveydenhoidossa [2, 6]. Tällai-set verkot koostuvat yleensä useista sulautetuista laitteista (sensorisolmuista), ja näi-den resurssit pyritään pitämään kustannustehokkaina. Tyypillinen sensorisolmu koos-tuu pienestä mikroprosessorista (8-, 16-, 32-bittinen), lähetin-vastaanottimesta, senso-reista sekä lähtökohtaisesti paristoilla toimivasta virransyötöstä. Kun työskennelläänrajallisten resurssien parissa, tulee eteen väistämättä haasteellisia tilanteita, joissa jou-dutaan ratkomaan resurssipula mitä erilaisin keinoin.

Ohjelmat ja ohjelmistot ovat sensoridatan pääkäyttäjiä, jolloin tarvitaan tehokas se-kä helppo lähestymistapa langattomien sensoriverkkojen käyttöön. Kun sensoriverkotsiirtyvät kohti Internet-protokollaa, yksi vaihtoehto on integroida sensorit web:iin. Täl-löin pystytään saamaan yhteys sensoriverkkoon Internetin kautta. [2]

Yksi lähestymistapa resurssien optimaalisempaan käyttöön on REST. REST on oh-jelmistoarkkitehtuurimalli hajautetuille hypermediajärjestelmille, kuten WWW (WorldWide Web). REST-periaatteen pyrkimys on hyödyntää ja käyttää HTTP:ta (Hyper TextTransfer Protocol) sekä muita samankaltaisia protokollia rajoittamalla rajapinnan hy-vin jo entuudestaan tunnettuihin standardi/geneerisiin operaatioihin. [7, 8, 9, 10]

Tässä työssä keskitytään CoAP-viestien, UDP-datagrammin (User Datagram Pro-tocol), REST-periaatteen sekä µIPv6-rakenteen avulla tapahtuvan kommunikaationhyödyntämiseen sensorisolmujen ja päätelaitteen välillä. Päätelaite (Personal compu-ter, PC) toteuttaa CoAP-rakennetta kommunikoidessaan Zolertia Z1-sensorisolmujenkanssa. Käyttäjät ja sensorisolmut pystyvät interaktiiviseen kommunikaatioon keske-nään, samalla tavalla kuin palvelimen kanssa ilman, että käyttäjät tiedostaisivat kom-munikoivansa hyvin resurssirajoitteisten sensorisolmujen kanssa.

Ideana on käyttää perinteisiä web-työkaluja (verkkoselain, syötelukija), kun halu-taan päästä käsiksi sensorisolmujen toiminnallisuuksiin sekä kerättyyn dataan. Asioi-ta ja esineitä voidaan jo nyt sulauttaa fyysiseen maailmaan, mutta jos nämä laitteetpystytään vielä kytkemään web:iin; saadaan valtava määrä dataa käyttäjien ulottuville.Näiden tekniikoiden yhdistäminen yhdeksi kokonaisuudeksi tuo uudenlaisia applikaa-tioita, menetelmiä sekä toteutuksia joihin emme ole vielä tämän päivän sovelluksissatörmänneet.

Työn konkreettisena tavoitteena on ladata sovellus sensorisolmuun ja tuoda haluttutieto solmusta web-tekniikoilla.

Tässä työssä käydään läpi tekniikoita, menetelmiä, arkkitehtuureja sekä pohditaanmitä voisivat olla ne seuraavat tulevaisuuden suuntaukset sensoriverkkojen saralla.

11

2. TAUSTA

Älykkäät laitteet sisältävät prosessorin ja radion lisäksi joko sensorin tai aktuaatto-rin. Sensorit puolestaan ovat laitteita, jotka pystyvät operoimaan sekä monitoroimaanympärillä olevaa ympäristöä. Esimerkkinä voidaan mainita lämpötilasensori ja gyros-kooppi. Miten tällaista tietoa voidaan kerätä? Tähän tarvitaan kommunikaatiota sekäyhteistyötä, jotta dataa voidaan kerätä että hyödyntää. [11, 12]

Kun toimitaan rajallisten resurssien kanssa on väistämätöntä, että haasteita ilme-nee [2, 13]. Ja täten, erityistä huomiota on käytettävä resurssien jaossa [2]. Resurs-sit tulisi hyödyntää mahdollisimman tehokkaasti ilman hukkakäyttöä [2]. Tällä het-kellä kuitenkin monet langattomat sensoriverkot perustuvat erikoisohjelmistoihin sekä-laitteistoihin [2].

Kun tavoitellaan optimoitua suorituskykyä, tarvitaan mukautettuja protokollia sekärajapintoja. Nämä ovat itsessään riittäviä toimimaan ad hoc-ympäristössä, mutta tuovatmukanaan raskaita toimintamalleja, virhealtista kommunikaatiota sekä sisältävät isonoppimiskynnyksen. Kun luodaan standardoimattomia mekanismeja, rajoitetaan käyttö-mahdollisuuksia sekä yhteentoimivuutta muiden sensorisolmujen kanssa. Tämä omaltaosaltaan estää uusien applikaatioiden sekä toiminnallisuuksien luomisen. [14]

IEEE 802.15.4 standardi tukee WSN:n käyttämiä fyysisen kerroksen ja MAC (Me-dium access control)-kerroksen ohjausta sensorisolmuissa [2]. LPP (Low Power Pro-bing) [15] ja X-MAC [16] ovat MAC-protokollan vähävirtaisia menetelmiä.

Langattomissa sensoriverkoissa törmätään monesti käsitteeseen "mote"eli sensori-solmu. Yksi esimerkki sensorisolmusta on Zolertian Z1, joka on vain yksi monista.ContikiOS ja TinyOS ovat sensorisolmuille kohdennettuja käyttöjärjestelmiä.

2.1. Internet protokolla

Sensorien sekä vähävirtaisten kommunikaatioteknologioiden, kuten IEEE 802.15.4 ke-hitys on ollut huimaa [17]. Tästä kuitenkin poiketen älykkäiden applikaatioiden kehi-tys ei ole ollut yhtä nopeaa taikka helppoa [2] . Syy tähän on suljettujen järjestelmienjoko osittainen tai täydellinen yhteensopimattomuus [2]. Tämänhetkinen tilanne onsamankaltainen, mitä se oli tietokoneverkoilla parikymmentä vuotta sitten [2]. Sillointietokoneet kommunikoivat keskenään valmistajien omilla protokolleilla [2]. Nykyäänkäytössä olevat verkot operoivat täysin IP-pohjaisella päästä-päähän (end-to-end) me-nettelytavalla [2].

Monet tämän päivän IP-protokollattomat sensoriarkkitehtuurit kehittyvät kohti pro-tokollamaisempia ohjausmalleja. Protokollayhdyskäytävät ovat luonnostaan monimut-kaisia suunnitella, hallita sekä rakentaa. Verkon pilkkoutumisesta seuraa tehottomiatietoverkkoja. Tämä on seurausta johdonmukaisettomasta reitityksestä, palvelun laa-dusta, tiedon siirrosta sekä verkon palautumistekniikasta. [2]

Toisaalta päästä-päähän IP-arkkitehtuurit ovat laajalti hyväksytty vaihtoehto suun-niteltaessa skaalautuvaa sekä tehokasta verkkoa suurelle määrälle kommunikaatiosol-muja. [2]

12

2.1.1. Internet protokollan tiedonsiirto

IP-kerros on vastuussa paketin toimittamisesta verkon sisällä, päätelaitteiden osoitteis-tuksesta, pakettien uudelleenohjauksesta sekä reitityksestä. Jokainen IP-paketti kan-taa mukanaan päätepisteensä osoitetta, ja jokainen paketti IP-verkossa ohjautuu tie-toverkon läpi reititysmekanismin määrittelemän päätepisteensä perusteella. IP tukeemyöskin palveluita, kuten DS (differentiated services), missä IP-paketit voivat tu-kea kirjon erilaisia luokituspalveluita. Tavanomaisesti IP-paketit merkitään verkon ää-ripäissä. Ruuhkautumisen varalle on kehitetty ruuhkautumisenestomekanismi QoS-standardivaatimusten (Quality of Service) mukaan. [2]

IP-paketti koostuu siirrettävästä datasta sekä erilaisista otsikkokentistä. Tiedonsiirto-paketin otsikkokentät sisältävät protokolladataa, kuten osoitteita, sekvenssinumeroin-nin ja lippuja (flags). Jokainen protokolla pinossa lisää oman otsikkokentän pakettiin.[2]

Vähävirtaisille ja hitaammille yhteyksille on olemassa menetelmiä, joilla saadaanpakattua otsikkokentät tiiviimmin [2]. Toiminnalle ominaiset bitit säilytetään ja yli-määräiset jätetään datapaketista pois [2]. Viimeisimpiä esimerkkejä, missä on otettuhuomioon otsikkokentän pakkaus sekä vähävirtaiset operaatiot on 6LoWPAN [18].Tässä osoitteistus tapahtuu vähävirtaisen IEEE 802.15.4 radioprotokollan yli [18].Yleisimmissä tapauksissa 6LoWPAN-tekniikka kykenee pakkaamaan 48-tavuisen IPv6:nja UDP:n otsikkokentän 6 tavun sisälle [18].

ICMP

ICMP toteuttaa IP:n puolesta virheraportointia. IPv6:ssa ICMP:tä käytetään myös au-tomaattisten konfiguraatioiden osoitteistuksessa sekä naapurisolmujen etsinnässä. [19]

UDP

UDP tarjoaa parhaan yhteydettömän datagrammipalvelun, missä ohjelma lähettää tie-topalasen toiselle ohjelmalle ilman lähetyksen varmistuksia taikka tiedonvirtakont-rollia (stream control) [2, 20]. Ohjelmat, jotka vaativat 100% lähetysvarmuuden; onhavaittava hävinneet datapaketit ja vaadittava uudelleenlähetystä tai palautusta [2].UDP:ta käytetään yleensä sellaisissa ohjelmissa, joissa välitön lähetys on tärkeämpääkuin täydellinen luotettavuus [2]. Tällaisia voi olla esimerkiksi IP-puhelinyhteys taireaaliaikadatan suoratoisto [2].

TCP

TCP (Transmission Control Protocol) puolestaan tarjoaa luotettavan tiedonsiirtoker-roksen. Tieto siirtyy turvallisesti sekä varmasti päätelaitteesta toiseen, kunhan näidenpäätepisteiden välillä on verkkopolku. Adaptiivisen ikkunointitekniikan (adaptive win-dowing) puolesta TCP tukee kehittynyttä tietovirtakontrollimekanismia (congestioncontrol mechanism). [2]

13

2.1.2. IEEE 802.15.4

IEEE 802.15.4-standardi kehitettiin täyttämään energiatehokkuusvaatimukset nopeissalangattomissa tiedonsiirtolaitteissa. Se määrittää fyysisen- ja MAC-kerroksen standar-divaatimukset vähäkuormitteisille WPAN-verkoille (Wireless Personal Area Network).IEEE 802.15.4-standardi tarjoaa perustan alemmille verkkokerroksille, joiden kohtee-na on tuottaa laitteiden välille vähäkustanteista ja pieninopeuksista kaikkialle yltävääkommunikaatiota. [17]

Perinteinen IEEE 802.15.4-standardin viitekehys antaa 10 metrin kantomatkan sekä250 Kbps tiedonsiirtonopeuden. Standardin ominaispiirteisiin kuuluu pienten tuotanto-sekä operaatiokustannusten saavuttaminen ilman joustavuuden tai yleistettävyydenpoissulkemista. [17]

Yksi standardin tärkeimpiä piirteitä on reaaliaikatoimivuus. Tätä tuetaan taattujenaikaikkunoiden varauksella, yhteentörmäyksen estolla CSMA/CA-tekniikalla (Carriersense multiple access with collision avoidance) sekä integroidulla suojatulla kommu-nikaatiolla. IEEE 802.15.4-standardin omaavat laitteet voidaan jakaa kolmeen eri taa-juusalueeseen [17]:

• 868.0-868.6 MHz: Eurooppa, kykenee käyttämään kolmea eri taajuuskanavaa,

• 902-928 MHz: Pohjois-Amerikka, pystyy 30 eri taajuuskanavan hyödyntämi-seen ja

• 2400-2483.5 MHz: maailman laajuisessa käytössä, jopa 16 taajuuskanavan käyt-tömahdollisuus.

6LoWPAN

6LoWPAN rikkoo rajoja luomalla mahdollisuuden käyttää IPv6-osoitteistusta vähä-virtaisissa prosessointitehoissaan rajoitetuissa sulautetuissa laitteissa kapeakaistaisenlangattoman verkon yli. 6LoWPAN kehitettiin vastaamaan sulautettujen langattomienlaitteiden Internetiä yksinkertaistamalla IPv6 toiminnallisuutta, määrittelemällä hyvinkompakti otsikkomuoto ja ottamalla huomioon langattomien verkkojen ominaisuudet.[21]

2.1.3. µIP

µIP on avoimen lähteen TCP/IP:tä mukaileva pienille (8- ja 16-bittisille) mikrokont-rollereille suunniteltu protokolla. Adam Dunkels on alkuperäisen µIP-protokollan ke-hittäjä, ja protokolla toimii BSD-lisenssin (Berkeley Software Distribution) alla. [22]µIP voi olla hyvinkin kätevä sulautetuissa järjestelmissä, koska se vaatii hyvin vähän

ohjelmakoodia ja RAM-muistia (Random Access Memory). µIP on portattu useille erialustoille, mukaan lukien DSP-alustat (Digital Signal Processing). [22]

µIPv6

Vuonna 2008, Cisco, Atmel ja SICS (Swedish Institute of Computer Science) julkai-sivat täyden IPv6-laajennuksen µIP:hen, µIPv6 [23]. Kun µIPv6 julkistettiin, siitä tuli

14

yksi maailman pienimmistä avoimen lähdekoodin omaavista IPv6-valmiuksista proto-kollapinoista [23]. µIPv6 on ohjelmakoodiltaan vain 11,5 kilotavua ja vaatii vajaat 2kilotavua RAM-muistia [24]. Tämän tarkoitti sitä, että kaikki mitä pienimmät, vähä-virtaisimmat ja muistirajoitetuimmatkin laitteet voivat saada IP-osoitteen [23].

2.2. Esineiden ja asioiden Internet

Älykkäille laitteille laajentuva applikaatiovalikoima vaatii skaalautuvia sekä yhteenso-pivia kommunikaatiomekanismeja, jotka tukevat tulevaisuuden innovaatioita ohjelmis-tojen lisääntyessä. Erilaiset applikaatiot ovat useasti sensoridatan pääkäyttäjiä. Niitävarten tarvitaan helppo sekä käytännöllinen mekanismi langattomien sensoriverkko-jen tiedonkäsittelyyn. Kun langattomat sensoriverkot siirtyvät entistä enemmän IP-painotteisimmiksi, on yksi varteenotettavista vaihtoehdoista integroida applikaatiotweb:iin ja täten tuoda ohjaus Internetin yli. IP on todennetusti vakiinnuttanut paik-kansa pitkäikäisten, vakaiden sekä helposti skaalautuvien järjestelmien verkkotekno-logiana. [25]

Esineiden ja asioiden Internet yhdistää fyysisen (analogisen) ympäristön (digitaali-seen) Internetiin, joka puolestaan avaa mahdollisuuksia erilaisten sovellusalueiden pa-rista; kuten älykkäät mittaukset, logistiikka, koti- ja taloautomaatio (kuva 1.). [21, 25]

Rakennusten

automaatio

Puhelimet

Henkilökohtaiset

sensorit

Kuva 1. IoT:n sovellusmahdollisuudet

Kerroksittainen IP-arkkitehtuuri antaa tilaa innovaatioille muokkautumiskykynsäpuolesta. Nykyään IP tukee jo valtavaa määrää applikaatioita, kuten sähköpostia,WWW:tä, Internet-puhelua sekä videon suoratoistoa. Muutaman viime vuosikymme-nen aikana IP on kehittynyt tukemaan uudenlaisia mekanismeja [2]:

15

• helppoa saatavuutta,

• parannettua turvallisuutta,

• palvelun laatua (QoS),

• reaaliaikaista tiedonsiirtoa sekä

• virtuaalisia yksityisverkkoja (Virtual Private Networks, VPNs).

IP:llä on pitkä historia tietokoneiden sekä palvelinverkkojen yleisenä kommunikaa-tiomekanismina. Siksi onkin ajateltu, että IP on aivan liian raskas toimimaan vähä-resurssisissa laitteissa. Muutamat viimeaikaiset kevyet IP-rakenteet, kuten µIP ovatnäyttäneet, että IP-rakenne voidaan suunnitella kohtaamaan vähäresurssisten laitteidenvaatimukset. Tämä tarkoittaa muutamaa kilotavua RAM- ja ROM-muistia, rajoitettuaprosessointitehoa sekä rajallista energiankulutusta. [2]

Internet-protokolla tarjoaa standardisoidun, kevyen sekä alustariippumattoman verk-koyhteyden älykkäille sekä sulautetuille verkkolaitteille. IP:n avulla voidaan luoda yh-teys laitteisiin paikasta ja laitteesta riippumattomasti; tietokoneiden, matkapuhelimien,PDA-laitteiden, verkkokeskusten ja myös muiden automatisoitujen laitteiden sekä lait-teistojen, kuten esimerkiksi lämpötilasensorin tai hehkulampun. [2]

Kehitys huokeahintaisemmissa sulautetuissa laitteissa on tuomassa IoT:n nopeaavauhtia kuluttajien ulottuville. Tämän toteutuminen vaatii kuitenkin sen, että on opit-tava aikaisemmasta ja otettava käyttöön joustavia, skaalautuvia ja avoimeen lähde-koodiin perustuvia verkkoteknologioita. IP on yksi parhaista vaihtoehdoista, koska sepystyy täyttämään tiukimmatkin vaatimukset älykkäiden laitteiden sekä järjestelmienosalta. [2]

2.2.1. Internet protokolla on kaikkialla

IP on mahdollista toteuttaa lähestulkoon kaikkiin käyttö- sekä sulautettuihin järjestel-miin [2]. Lisensoituja sekä avoimen lähdekoodin toteutuksia on tarjolla tunnetuimmillekäyttöjärjestelmille, kuten Microsoftin Windows ja Linux, mutta myös mikrokontrol-lerikäyttöjärjestelmille, kuten:

• ContikiOS [2],

• TinyOS [2],

• Nut/OS [26],

• LiteOS [27] ja

• FreeRTOS [2].

Älykkäät laitteet pystyvät periaatteessa hyödyntämään laajan valikoiman applikaa-tioita, joskin niiden resurssit ovat rajoite. Näin eri laitteiden yhdistäväksi tekijäksimuodostuu virrankulutus.

16

2.2.2. WoT

IoT keskittyy pääasiassa yhteyksien luomiseen erilaisissa rajoitetuissa ympäristöissä,ja seuraava looginen eteneminen tässä on rakentaa verkkoyhteyksien päälle toteus so-velluksille. WoT käsittelee älykkäitä asioita verkon ykkösluokan kansalaisina. WoT(Web of Things) pyrkii olemaan IoT:n hiottu versio missä älykkäät asiat yhdistetäänInternetin (verkon) lisäksi myös web:iin (sovelluskerrokseen). [10]

WoT perustuu web:ssä yleisesti käytettyjen menetelmien uudelleenkäyttöön sekäsopeuttamiseen. Näin pystytään rakentamaan web-sovelluksia olemassa olevien arkki-tehtuurien päälle hyvin tunnetuilla web-kielillä sekä teknologioilla, kuten HTTP, Ja-vaScript, Ajax (Asynchronous JavaScript and XML), PHP ja Python. Web-palvelimetsulautetaan älykkäisiin laitteisiin ja REST-arkkitehtuuri-mallia hyödynnetään fyysises-sä ympäristössä. REST:n avulla pyritään siten saavuttamaan web:ssä irtonainen palve-lukytkentä, jotta palveluita voitaisiin helposti uudelleenkäyttää. [10]

Älykkäille laitteille on esitetty monenlaisia vaihtoehtoisia ratkaisuja, joilla pystyt-täisiin tuomaan esiin funktionaalisuuksia. Funktionaalisuuksia lisäämällä päästään lä-hemmäksi pro-aktiivisia, että uudelleenkäytettäviä web-palveluita. Näitä toteutuksiaovat muun muassa JINI, UPnP (Universal Plug and Play) ja DLNA (Digital LivingNetwork Alliance). Nämä kuitenkin ovat hyvin raskaita pyöritettäviä resurssirajoittei-silla laitteilla. Myös REST-arkkitehtuurin mukainen suora laitteiden funktionaalisuuk-sien kohdistus web:iin ei toteudu eikä todellista irtonaista liitettävyyttä ole. [10]

2.2.3. IP:n skaalautuvuus

Internet-protokolla on globaalin Internetin kautta todistanut olevansa periytyvästi skaa-lautuva. Laitetasolla mitään muuta verkkoteknologiaa ei ole tutkittu, testattu taikka to-teutettu näissä mittakaavoissa. Kun enemmän ja enemmän älykkäitä laitteita yhdistyyverkkojen välityksellä Internetiin, tulee skaalautuvuudesta prioriteetti numero yksi. [2]

IPv6-generaation tuoma 2128 osoitteen IP-osoiteavaruus takaa sen, että osoitteet tu-

levat riittämään jokaiselle laitteelle ja käyttäjälle läpi sukupolvien. Spesifit protokollatkuten RPL (IPv6 Routing Protocol for Low power and Lossy Networks) on suunniteltureitittämään suuria määriä päätelaitteita IP-verkoissa. [2]

2.3. Langaton sensoriverkko

WSN on langattoman verkon luokka, joka koostuu suuresta määrästä pieniä sulautet-tuja laitteita, joita kutsutaan sensorisolmuiksi. Ne sisältävät sensoreita ja kommuni-kaatiovälineitä; joilla voidaan havainnollistaa fyysisiä tiloja, kuten liikettä, lämpötilaa,ilmanlaatua, valoa, tärinää ja monia muita elementtejä. Tämän kaltaiset verkot voivatolla käytössä monenlaisissa elementeissä; kuten sotilaallisissa-, koti-, luonto- ja kau-punkiympäristöissä. [2]

IP-pohjaisen WSN:n eduksi muodostuu REST-arkkitehtuuri. Tämä mahdollistaapalveluiden välille irtonaiset kytkennät sekä palveluiden jaon että uudelleenkäytön.REST-arkkitehtuurissa resurssi on abstraktio. Sitä ohjaa palvelin ja identifioi URI (Uni-form Resource Identifier). Resurssit ovat irtonaisia palveluista ja siten ne voidaan esit-

17

tää erilaisissa muodoissa; kuten XML (Extensive Markup Language) ja JSON (Ja-vaScript Object Notation). Resursseja voidaan muokata sovellusprotokollan kautta. Tä-mä perustuu käyttäjä/palvelin- ja pyyntö/vastaus-periaatteeseen. REST ei ole sidoksis-sa tiettyyn sovellusprotokollaan. Kuitenkin suurin osa REST-arkkitehtuureista käyttääHTTP:ta. [28]

2.3.1. Sensorisolmu

Sensorisolmu on langaton sensorilaite, joka toimii WSN:ssä solmukohtana. Sensori-solmun pääkomponentteja ovat [2]:

• mikrokontrolleri,

• lähetin-vastaanotin (radio),

• ulkoinen muisti,

• virtalähde ja

• sensorit.

Sensorisolmut kykenevät tunnistamaan, havaitsemaan ja monitoroimaan ympäris-tössä tapahtuvia fyysisiä muutoksia. Käyttämällä sensoreita ja mikrokontrollerin pro-sessoitua dataa, pystyy laite kommunikoimaan ympärillä olevien naapurisolmujenkanssa lähetin-vastaanottimen avulla. [2]

Paristot ovat virran pääasiallinen lähde sensorisolmuissa, ja radio on yleensä laitteensuurin energiasyöppö. [2]

Flash-muistin yksikkökohtaisen kapasiteetin halpuus on edesauttanut sen suosiotapienissä vähävirtaisissa laitteissa. [2]

Kaupallisia ja tutkimus käyttöön suunniteltuja alustoja ovat muun muassa: BTnode,G-Node, Sun SPOT, MICAz motes, TMote Sky, SensiNet Smart Sensors ja ZolertiaZ1. [29]

Zolertia Z1

Zolertia Z1 (kuva 2.) on vähävirtainen langaton sensorisolmu, joka toimii IEEE 802.15.4-ja Zigbee-protokollilla. [30]

Zolertia Z1 ydin koostuu Texas Instrumentsin MSP430-mikrokontrollerista ja CC2420-lähetin-vastaanottimesta. [30]

Työssä käytettävän Zolertia Z1 tuoteominaisuudet ovat [30]:

• toimintaympäristö (-40◦C:stä +85◦C:een),

• vähävirtainen 16-bittinen MSP430, 16MHz kellonopeuksinen MCU (Microcont-roller Unit), 8KB RAM ja 92KB flash-muistia,

• 2.4GHz IEEE 802.15.4, 6LoWPAN yhteensopiva, joka yltää 250Kbps tiedon-siirtonopeuteen,

18

Kuva 2. Zolertia Z1-sensorisolmu

• 3-suuntainen kiihtyvyysanturi,

• vähävirtainen lämpötilasensori puolen asteen tarkkuudella (-25◦C ∼ 85◦C),

• lisäantenni mahdollisuus ja

• Mikro-USB (Universal Serial Bus), virralle sekä tiedonsiirtoon.

2.3.2. URI

URI tarjoaa yksinkertaiset ja mittavat keinot resurssien tunnistamiseen, kuvan 3. mu-kaisesti. Tällainen tunnistaminen antaa mahdollisuuden verkon yli kantavaan inte-raktioon web-resurssien kanssa, käyttäen apuna tiettyjä protokollia kuten HTTP:ta.[31, 32]

http://esimerkki.fi:8080/elain/lintu?laji=joutsen#muuttolintu

Skeema Palvelin Portti Polku Kysely Osanen

Kuva 3. URI-skeema

Järjestelmä pystyy suorittamaan määritteiden avulla erilaisia toimintoja resursseissa;kuten avata, kopioida, päivittää, korvata, tuhota tai etsiä. [31, 32]

URI voidaan vielä jakaa kahteen luokkaan: lokaattoriin (Uniform Resource Locator,URL), nimeen (Uniform Resource Name, URN) tai molempiin. [31]

Yhtenäinen

URI:n yhtenäisyys mahdollistaa useita toiminnallisuuksia [31]:

19

• erilaisten resurssi-identifioijien käyttöä samassa kontekstissa, jopa silloinkin kunkäytetty mekanismi eroaa resursseista,

• yhtenäisen sematiikkatulkkauksen yleissyntaktisille sovituksille erilaisten resurssi-identifioijien yli,

• uuden tyyppisten resurssi-identifioijien esittelyn ilman, että nämä häiritsevät joolemassa olevien identifioijien toimintaa ja

• identifioijien uudelleenkäyttöä monissa eri konteksteissa.

Resurssit

Resurssit voivat olla mitä tahansa millä on identiteetti; esimerkiksi elektroniset doku-mentit, kuvat, palvelut ja resurssikollaasit. Kaikki resurssit eivät ole kuitenkaan säh-köisesti haettavissa, kuten ihmiset, yritykset ja muut fyysiset elementit. Resurssi onkonseptinen kartoitus entiteettiin tai entiteetteihin. [31, 32]

Identifioija

Identifioija on objekti joka voi toimia referenssinä jollekin missä on identiteetti. URI:ntapauksessa objekti on merkkien sekvenssi rajoitetulla syntaksilla. [31]

2.3.3. HTTP

HTTP on sovelluskerroksen protokolla hajautetuille-, yhtenäisille- ja hypermedia in-formaatiojärjestelmille. HTTP on geneerinen ja tilaton protokolla, jota voidaan käyttääerilaisiin tehtäviin kuin pelkästään hypertekstinä; kuten nimipalvelimissa ja hajautettu-jen objektien hallintajärjestelmissä HTTP:lle ominaisten komentojen, virheilmoitustensekä otsikkokenttien (kuva 4.) avulla. [33]

HTTP:tä on käytetty lähtökohtaisesti WWW:ssä vuodesta 1990 asti. [33]

HTTP/1.0 200 OK

Date: Wed, 30 Oct 2013 12:15:54 GMT

Server: Apache

X-Content-Type-Options: nosniff

Cache-Control: s-maxage=3600, must-revalidate, max-age=0

Last-Modified: Thu, 19 Sep 2013 20:20:54 GMT

Vary: Accept-Encoding

Content-Length: 6136

Content-Type: text/html; charset=utf-8

Kuva 4. HTTP-viestin perusotsikkokentät

20

2.3.4. REST

REST tai RESTful on Dr. Roy Fieldingin [7] esittämä ohjelmistoarkkitehtuurimallihajautetuille hypermediajärjestelmille, kuten WWW. Se on yksi tapa web-palveluidenkäytölle. REST-periaatteen pyrkimys on hyödyntää ja käyttää HTTP:ta sekä muitasamankaltaisia protokollia rajoittamalla rajapinnan hyvin jo entuudestaan tunnettui-hin standardi/geneerisiin operaatioihin; kuten "GET", "POST", "PUT", "DELETE".[7, 8, 9, 10]

REST keskittyy tilaresurssien välittömään kanssakäymiseen, enemmän kuin vies-tien ja operaatioiden tuomaan interaktioon. On mahdollista, että on samalle resurssillelöytyy erilaisia esitysmuotoja. Tämä on erittäin tehokas konsepti; esimerkiksi palve-lin voi toimittaa HTML-sisältöä (Hyper Text Markup Language) visuaalisesti näytönvälityksellä ihmisille ja XML- tai JSON-materiaalia koneille. [7, 8, 9, 10]

RESTful-arkkitehtuuri tarjoaa hyviä, joustavia sekä keveitä web-palveluratkaisuja.[7, 8, 9, 10]

Resurssi-identifikaatio

Kaikki sovellukselle ja sen tilalle relevantit resurssit pitäisi antaa uniikilla ja muut-tumattomalla identifikaatiolla. Näiden identifikaatioiden pitäisi olla globaaleja, jottatarvittaessa niiden referenssit pystytään nollaamaan yksittäin kontekstista. On tärkeää,että resurssikonseptia, joka on kanssakäymisessä sovelluksen kanssa ei rajoiteta staat-tisiin asioihin. Sen sijaan konseptin on määriteltävä kaikki tiedot, mitä näiden asioi-den käsittelyyn tarvitaan, kuten esimerkiksi liiketoiminnalliset dokumentit (tilaukset).[8, 10]

Yhtenäinen rajapinta

Kaikki interaktiot pitäisi rakentaa yhtenäisen rajapinnan ympärille, joka tukee jokaistaresurssien välistä kanssakäymistä antamalla yleisen ja funktionaalisesti riittävän mää-rän metodeja kokonaisvaltaiseen toiminnallisuuteen. Tällainen määrittely on täydessäristiriidassa RPC:n (Remote Procedure Call) funktionaalisuuden kanssa, missä toimin-nallisuuksien pääohjeistus on määritellä valikoima herätettäviä etämetodeja. REST eiRPC:hen verrattuna hyödynnä tällaista toiminnallisuutta missä metodeja kutsutaan/-herätetään. Sen sijaan RESTful-palveluissa resurssit on vapaasti nähtävissä, ja niidenväliset toiminnallisuudet toteutuvat yhtenäisen rajapinnan kautta, tai sen alaisen toi-minnallisuuskerroksen avulla. [8, 10]

Itseselkoiset viestit

Itseselkoisia viestejä tarvitaan yhtenäisen rajapinnan kautta tapahtuvaan resurssien vä-liseen interaktioon. REST vaatii käytettävän resurssien esittelyä, joka puolestaan pai-nottaa resurssien esittelyn tärkeyttä. Esitysmuodon täytyy olla suunniteltu siten, ettäottavat osapuolet saavat täyden ymmärryksen resursseista tai relevantista tilasta pelkäs-tään tarkastelemalla esitysmuotoa. Muutokset resursseihin tai tiloihin hoidetaan vaih-tamalla esittelyjä yhtenäisen rajapinnan kautta. [8, 10]

Tämän vaatimuksen mukaisen; yhtenäisen rajapinnan täytyy luoda toiminto, mil-lä tiedonsiirrot pystyvät merkitsemään esittelyjä siten, ettei lisätietoa tai aiempia so-

21

pimuksia tarvita vastaanotettavien esittelyjen ymmärtämiseen. Itseselkoisuus ei tässätapauksessa referoi itseään semanttisessa merkityksessä, vaan se kuvaa kykyä proses-soida yhtenäisen rajapinnan välityksellä vaihdettua esittelyä. Mitään ylimääräistä in-formaatiota ei siten tarvita. [8, 10]

Hypermedian muokkaama sovellustila

Esittelyt, joita vaihdetaan laitteiden välisessä kommunikaatiossa, oletetaan olevan lin-kitettyjä. Sovellus, joka ymmärtää esittelyjä, pystyy löytämään yhteydet ja ymmärtä-mään niitä, koska niiden semantiikka on määritelty esittelyssä. Se osaa käyttää niitä,koska ne johtavat muihin identifioituihin resursseihin, joita voidaan hyödyntää yhtenäi-sen rajapinnan kautta. Ilman resurssien välisiä linkkejä olisi mahdotonta löytää uusiaresursseja tai luoda sovelluksille mahdollisuus tiettyihin tilasiirtoihin. Hypermediavaa-timus on luultavasti yksi tärkeimpiä irtonaisten kytkösten tukijoita, koska identifioijatpystytään löytämään ajon aikana ja käyttämään yhtenäisen rajapinnan kautta ilman ai-kaisempia sopimuksia osajoukkojen välillä. [8, 10]

Tilaton interaktio

Tilaton interaktio tarkoittaa palvelimen ja asiakasohjelman välistä kanssakäymistä,missä palvelin ja asiakas ovat täysin itsenäisiä. Tilattomassa interaktiossa palvelinei saa sisältää asiakastilan hallintaa, koska tällainen mahdollistaa interaktion tapah-tuessa muutoksia molempien osapuolien tilaesittelyihin sekä palvelimen asiakasistun-toon. Kaikki kanssakäyminen voi tietenkin vaikuttaa muutoksiin resursseissa, missätapauksessa seuraava interaktio resurssin kanssa peilaa muutoksia myös resurssin ti-lassa. [8, 10]

Muutos resurssin tilassa on eri kuin mitä palvelin ylläpitää asiakasistunnossa, kos-ka palvelin tarvitsee ainoastaan tiedon resurssien tiloista, ei itse asiakasistunnoista. Ontärkeää hyödyntää tätä vaatimusta, jotta palvelimen skaalautuvuus rajoitetaan ainoas-taan sen hetkisillä asiakaspyynnöillä eikä asiakasohjelmilla. [8, 10]

Yleinen väittämä, mitä käytetään RESTful-järjestelmien puolustamiseen, on erittäinhyvä skaalautuvuus. Itseselkoisten sisäisten linkityksien esittelyformaatit mahdollista-vat REST-järjestelmien luonnollisen sekä hajautetun kasvun. [8]

Web on vakuuttava demonstraatio tällaisen arkkitehtuurin ja ominaisuuksien hyö-dyntämisestä. Niissä kohdin missä web-komponentit ovat rikkoneet näitä vaatimuk-sia skaalautuvuus on kärsinyt. Esimerkkinä on pahamaineinen istunto-objekti (sessionobject), jota käytetään web-orientoituneessa ikkunoinnissa. Seurauksena on helpostipalvelimen ylikuormittuminen. [8]

2.3.5. REST-arkkitehtuurin käyttöaste

Yllä mainittuja REST-vaatimuksia tarkastelemalla voidaan helposti nähdä onko suun-nitelma RESTful vai ei. REST:stä on tullut sen verran suosittu, että ihmiset yhdistävätsen hyvin toimivaan web-palveluun. Monet ohjelmistorajapinnat sekä palvelut käyt-tävät itsestään RESTful-ilmaisua vaikka ne eivät täytä siihen vaadittavia kriteereitä.[32]

22

Yksi suosituimmista palvelujen analyysimalleista on RMM (Richardson MaturityModel), jonka on kehittänyt Leonard Richardson. Tässä RESTful-ominaisuuden ku-vaaminen tapahtuu neljäkerroksisella "0-"3"olevalla vaiheistuksella [34, 35]:

Kerros 0: palvelut, jotka pelkästään vaihtavat XML-dokumentteja HTTP:n yli, kutenXML-RPC. Tässä tapauksessa REST:iä ei käytetä missään vaiheessa, ja ainoa syymiksi tällainen palvelu leimaa itsensä RESTful:ksi on se, että ne eivät käytä WS-standardeja (Web Services). Ne siltikin (väärin)käyttävät HTTP:ta tunnelointiproto-kollana.

Kerros 1: palvelut, jotka käyttävät resurssi-identifiointia ja rakentavat interaktioita näi-den tunnistettujen resurssien päälle. Tässä tapauksessa vähintäänkin hallinnoidut re-surssit kuvataan identifioitaviksi resursseiksi siten, että asiakasohjelma voi käyttääsuoraan niitä. Monissa tapauksissa URI:en resurssit 1-kerroksen palveluissa vastaavatmetodi-identifioihin ja niitä käytetään myös parametrien siirtoon. Kuitenkin, tämäkinhyödyntää vain pienen määrän HTTP:n kuvausvoimasta.

Kerros 2: tarkoittaa hyvin tarkan resurssiosoitteistuksen lisäksi HTTP-metodien hyö-dyntämistä oikein, kuten REST:n yhtenäinen rajapinta tämän määrittelee. Resurssienväliset interaktiot on siten määritelty sulautumaan näihin vaatimuksiin. Tämä ei pel-kästään tarkoita sitä, että HTTP:n metodit ovat asianmukaisesti käytettyjä, vaan myösHTTP:n oikeiden statuskoodien käyttöä vastauksien ilmaisussa. Kun HTTP-metodejakäytetään oikein; HTTP:n luokittelumetodien avulla voidaan optimoida järjestelmäävälikäsien avulla.

Kerros 3: lisää hypermediakontrollit resurssiesityksille siten, että asiakasohjelma pys-tyy käymään kommunikaatiota resurssien kanssa seuraamalla linkkien välityksiä. Näi-den linkkien täytyy monissa tapauksissa olla selväkielisiä, jotta asiakasohjelma voiymmärtää linkin semantiikan, mutta tärkein huomio on kuitenkin asiakasohjelman ky-ky selata avointa resurssiallasta tietämättä mitään edeltäkäsin.

Edellä mainittujen käyttöasteiden perusteella voidaan todeta, että monien RESTful-palveluiden todellista RESTful-ominaisuutta pitäisi tarkastella uudestaan ja tarkemminnäitä määrityksiä vasten. Sen jälkeen voidaan todeta niiden todellinen RESTful-aste.[36]

2.3.6. CoAP

CoAP-protokollan päämääristä tärkeimmäksi nousee geneerisen web-protokollan ra-kentaminen vastaamaan resurssirajoitetun laiteympäristön erikoisvaatimuksia; ja erito-ten silmällä pitäen virrankulutusta, rakennusautomaatiota ja muita M2M-applikaatioita(Machine-to-Machine). CoAP:n ei ole täysin tarkoitus olla vain tiivistetty versio HTTP:sta,vaan paremminkin REST-arkkitehtuurin ja HTTP:n ominaisuuksia silmällä pitäenmuotoiltu konsepti M2M-applikaatioille. CoAP tarjoaa M2M-interaktiota varten si-säänrakennettuja ominaisuuksia, kuten naapurisolmujen havainnoinnin, monikanava-tuen sekä asynkronisen viestinvaihdon. [37]

23

CoAP:n ominaisuudet [37]:

• M2M-vaatimukset täyttävä rajoitettu web-protokolla,

• UDP-sidos; jossa mahdollisuus luotettavaan yksittäiseen tai moninaiseen viestit-tämiseen,

• asynkroninen viestien vaihto,

• vähäiset kiinteät kulut otsikkokentässä sekä jäsentelyn helppous,

• URI:n ja sisältötyypin tuki,

• yksinkertainen välipalvelimen sekä välimuistin käyttö,

• tilaton HTTP:n kytkeminen; antaen mahdollisuuden käyttää CoAP-resurssejayhtenäisesti HTTP:n kautta välipalvelimia apuna käyttäen tai toisinpäin ja

• mahdollisuus toteuttaa turvallinen kytkentä DTLS:n (Datagram Transport LayerSecurity) avulla.

CoAP toimintamalli on hyvin pitkälti verrattavissa HTTP-protokollan asiakasohjel-ma/palvelin-malliin. M2M-toteutus johtaa CoAP-mallissa tyypillisesti rakenteeseen,missä molemmat toimivat sekä asiakas- että palvelinrooleissa. CoAP-kyselypyyntö(kuva 5.) on ekvivalentti HTTP-kyselypyynnön kanssa. Tämän lähettää asiakasohjel-ma, joka pyytää resurssin toimintoa URI:n avulla palvelimelta. Sen jälkeen palvelinlähettää pyyntöön vastauksen; tämä voi sisältää resurssin esitysmuodon. [37]

coap://[aaaa::c30c:0000:0000:3292]:5683/sensori/radio?p=rssi

Skeema Sensorisolmun

IPv6-osoite

Portti Polku Kysely

Kuva 5. CoAP-skeema

Toisin kuin HTTP, CoAP:n toiminta perustana on asynkronisten viestien kaksisuun-tainen välittäminen datagrammi-orientoituneen siirtomekanismia hyödyntäminen, ku-ten UDP:ssa. Tämä tapahtuu loogisesti käyttämällä viestejä, jotka tukevat vaihtoehtoi-sesti myös luotettavaa viestintää. CoAP määrittelee neljä eri viestityyppiä [37]:

• vahvistettavissa (confirmable),

• ei-vahvistettavissa (non-confirmable),

• kuittaus (acknowledgement, ACK) sekä

• uudelleenkäynnistys (reset).

Näiden neljän viestinvaihto tapahtuu hyvin suoraan samalla tavalla kuin pyyntö- javastausinteraktiossa. Pyyntöjä voidaan kuljettaa vahvistettavissa ja ei-vahvistettavissaviestien kanssa, ja vastauksia pystytään kantamaan samoissa viesteissä sekä liittämäänkuittausviesteihin. [37]

24

2.3.7. CoRE

CoRE (Constrained RESTful Environment) suuntaa tavoitteensa REST-arkkitehtuurinmukautumiskykyyn vähäresurssisissa sensorisolmuissa sekä verkoissa. Tyypilliset sen-sorisolmut ovat 8- tai 16-bittisiä mikrokontrollereita, joiden RAM- ja ROM-muistitovat pieniä. 6LoWPAN tukee IPv6-paketin pilkkomista pienempiin linkkikerroksendataikkunoihin, josta seuraa merkittävä pakettien läpiviennin todennäköisyyden las-ku. Yksi CoAP-protokollan suunnittelun kannalta tärkeimmistä kohdista on ollut pitääviestin kiinteät kustannukset pienenä ja rajoittaa liiallista viestin pilkkomista. [37]

25

3. CONTIKI-KÄYTTÖJÄRJESTELMÄ

Contiki on kevyt avoimen lähdekoodin käyttöjärjestelmä; erityisesti suunniteltu vastaa-maan resurssitehokkaiden sulautettujen verkkolaitteiden ja langattomia sensoriverkko-jen tarpeita. [38]

Contikin käyttöjärjestelmäydin on tapahtumapohjainen (event-driven), mutta järjes-telmä tukee ennalta ehkäisevää (preemptive) monisäikeistystä. Ennalta ehkäisevä mo-nisäikeistys on toteutettu kirjastolla. [38]

Contiki on toteutettu C-kielellä (listaus 3.1.) ja sitä on siirretty mikrokontrolleriark-kitehtuureille, kuten Texas Instrumentsin MSP430 ja Atmelin AVR. [38]

Listaus 3.1. Yksinkertaisen Contiki-ohjelman rakenne Z1-sensorisolmulle

#include "contiki.h" /* Contikin järjestelmätiedosto */

#include "stdio.h"

/* Prosessin määritys sekä referenssinimi testausta varten */

PROCESS(hello_world_process, "Hello world");

/* Ladataan prosessi käynnistämisen yhteydessä */

AUTOSTART_PROCESSES(&hello_world_process);

/* Prosessin sisältö */

PROCESS_THREAD(hello_world_process, ev, data)

{

PROCESS_BEGIN(); /* Määritellään prosessin käynnistys */

/*

** Tässä määritellään muuttujia sekä ohjelman toteutus

*/

printf("Hello, world\n");

PROCESS_END(); /* Määrittelee prosessin loppumisen */

}

Contiki tarjoaa täyden IP-verkon ja vähävirtaisten radiokommunikaatiomekanis-mien tuen kolmen kommunikaatiopinon kautta:

• Rime; kevyt kerroksittainen kommunikaatiopino, joka antaa alkeelliset kommu-nikaatio mahdollisuudet monimutkaisempien protokollien päälle [39, 40],

• µIP; minimalistinen täysin RFC (Request for Comments) yhteensopiva TCP/IPv4-pino [40, 41] ja

• µIPv6; pienin täysin RFC yhteensopiva TCP/IPv6-pino [24, 40].

Tällä hetkellä Contiki tukee neljää eri MAC-protokollaa. Sen "natiiviratkaisu"onContikiMAC ja muita tunnettuja ovat NULLMAC, X-MAC ja LPP. NULLMAC onnäistä yksinkertaisin ja siinä lähetin-vastaanotin on aina päällä. ContikiMAC, X-MACja LPP tarjoavat erilaisia energiaa säästäviä menettelyjä. [40]

3.1. Käyttöjärjestelmäydin

Contikin ydin (kernel) koostuu tapahtumaskedulerista. Se jakaa tapahtumia ajopro-sesseihin ja kutsuu jaksollisesti prosessien kiertokyselykäsittelijöitä (processes polling

26

handlers). Kaikki ohjelmasuoritus käynnistetään, joko ytimen tai kiertokyselymeka-nismin toimesta. [42]

On olemassa kahdenlaisia tapahtumia: asynkronisia tai synkronisia. Asynkronisettapahtumat jonottavat kernelissä ja ne jaetaan kohdeprosesseille jossain vaiheessa.Synkroniset tapahtumat puolestaan skeduloidaan heti. [42]

Kiertokyselymekanismi (polling mechanism) nähdään korkean prioriteetin tapahtu-mana. Se skeduloidaan jokaisen asynkronisen tapahtuman välissä, ja kutsutaan ainaprioriteetin mukaan. [42]

Contiki käyttää yhtä jaettua pinoa kaikkien prosessien suorituksessa. Asynkronistentapahtumien käyttö vähentää pinotilan vaatimuksia, koska pino uudelleen rakennetaanjokaisen tapahtumakäsittelijän välissä. [42]

3.2. Prosessit

Contikin koodi toimii kahdessa eri kontekstissa (kuva 6.): co-operatiivisessa tai pre-emptiivisessä [42]. Tätä prosessimallia kutsutaan myös nimellä "yksipinoinen"järjestely.

Co-operatiivinen koodi toimii sekventiaalisesti, ottaen huomioon muun co-operatiivi-sen ohjelmakoodin. Co-operatiivinen koodi täytyy suorittaa loppuun ennen kuin toi-nen ajoitettu co-operatiivinen koodi voidaan ajaa. Pre-emptiivinen ohjelmakoodi voipysäyttää co-operatiivisen koodin milloin tahansa, ja tällöin co-operatiivinen koodi eivoi jatkaa toimintaansa ennen pre-emptiivisen koodin suorituksen lopetusta. Contikinprosessit toimivat co-operatiivisella periaatteella, missä keskeytykset ja reaaliaikaisetajastimet toimivat pre-emptiivisesti. [42]

Kaikki Contikin ohjelmat ovat prosesseja. Prosessi on pieni pätkä koodia, joka suo-ritetaan säännöllisesti Contiki-käyttöjärjestelmän toimesta. Contikissa prosessit käyn-nistyvät, kun järjestelmä käynnistyy, tai silloin, kun moduuli joka sisältää kaikki pro-sessit ladataan järjestelmään. Prosessit menevät ajoon herätteillä (ajastin, ulkoinen ta-pahtuma). [42]

Konteksti

Pre-emptiivinen

Co-operatiivinen

keskeytys reaaliaikainen ajastin

Prosessi A Prosessi B Prosessi C

Aika

Kuva 6. Prosessien skedulointi Contikissa

27

3.3. Protosäikeet

Protosäikeet (protothreads) ovat erittäin keveitä pinottomia säikeitä muistirajoitteisillejärjestelmille, kuten pienille sulautetuille järjestelmille tai langattomille sensoriverkonsolmuille. Säikeet mahdollistavat lineaarisen ohjelmakoodin suorituksen C-kielisilletapahtumapohjaisille järjestelmille. Säikeille ominaista on sekventiaalinen kontrolli-vuo ilman monimutkaisia tilakoneita tai täysimittaista monisäikeistystä. Protosäikeetkäyttävät vain 2 tavua muistia per säie. [43]

Protosäiemekanismi ei itsessään määrittele mitään spesifistä menettelytapaa proto-säikeen herätykselle tai skeduloinnille. Nämä tapahtuvat Contikissa käyttämällä proto-säikeitä. Protosäiettä ohjaa se funktio, missä se itse on määritelty. Joka kerta, kun funk-tiota kutsutaan; protosäie käynnistyy ja ajaa itseään niin kauan kunnes tulee keskeytys(blocking) tai se saa lopetuskomennon. Tämän vuoksi protosäikeiden jaksottaminentehdään itse prosessissa. [43]

Protosäikeet eivät tallenna muistipinon sisältöä keskeytyksien välillä, ja näin ollenpaikalliset muuttujatkaan eivät säily. [43]

3.4. Erbium

Erbium on vähävirtainen REST-moottori Contiki-käyttöjärjestelmälle. Se on kehitettyyhteistyössä Matthias Kovatschin, Simon Duquennoynin, Adam Dunkelsin ja SICS:nkanssa. [44]

Kerros ProtokollaSovellus IETF CoAP/REST-moottoriKuljetus UDPVerkko IPv6/RPLSovitus 6LoWPANMAC CSMA/linkkikerros purskeetRDC ContikiMACFyysinen IEEE 802.15.4

Erbium on sovelluskerroksen näkökulmasta täysimittainen IoT-ratkaisu. Contikis-sa vähävirtaiset operaatiot tehdään ainoastaan RDC-kerroksessa (Radio Duty CyclingProtocol), tällä erotetaan vähävirtaiset operaatiot sovelluskerroksesta. Näin saadaanvähennettyä monimutkaisuutta, samalla pystytään seuraamaan kerroksittaista arkkiteh-tuuria, jonka avulla myös Internet on pystynyt aikanaan kehittymään. [44]

3.5. RPL

LLN-verkot (Low power Lossy Networks) rakentuvat useasti resurssirajoitteisista sen-sorisolmuista. Niiden reititykset on muodostettu häviöllisistä, tyypillisesti kaistarajoit-teisista datayhteyksistä; missä datapakettien läpivienti on säännöllisen epäsäännöllistä.Toinen ominaispiirre näille verkoille on niiden datansiirtomallit, jotka eivät ole pelkäs-tään päästä-päähän, vaan monissa tapauksissa päästä useaan päähän tai useasta yhteen

28

päähän olevia yhteyksiä. Tällaiset verkot voivat potentiaalisesti kasvaa jopa tuhansiksisensorisolmuiksi. [45]

Jotta RPL voi olla hyödyksi laajalle kirjolle LLN-applikaatioaltaita, se erottaa paket-tiprosessoinnin ja uudelleenohjauksen reitityksen optimoinnista. Tällaisia optimointejaovat esimerkiksi energiankulutuksen minimointi, viiveen vähentäminen tai rajoitteidentoteuttaminen. [45]

3.6. SLIP

SLIP (Serial Line Internet Protocol) on IP:tä varten sarjaväylälle toteutettu kapseloin-timenetelmä. SLIP on erittäin yksinkertainen menetelmä, joka ikkunoi datagramme-ja ja lähettää ne sarjaväylän yli. SLIP on tullut korvatuksi suurimaksi osaksi PPP:llä(Point-to-Point Protocol). Se on vielä käytössä sille ominaisten pienten kiinteiden kus-tannusten takia resurssirajallisissa sulautetuissa laitteissa. Contiki hyödyntää juurikintästä syystä SLIP-protokollaa IP-pakettien siirrossa. [46]

3.7. Vähävirtaiset MAC-protokollat

Langattomille sensoriverkoille kehitetyt “duty cycling”-menetelmät voidaan kategori-soida kolmeen MAC-luokkaan: synkroniset, asynkroniset sekä hybridit [16]. Näidenmenettelyjen motivaationa on ollut vähentää laitteen kuuntelun tyhjäkäyntiaikaa, mis-sä solmu on hereillä, mutta mitään liikettä ei tapahdu tiedonsiirtokerroksissa solmunsuuntaan [16]. 802.11-protokollissa on havaittu laitteen kuuntelun aikana tapahtuvaatyhjäkäyntiä [47, 48]. Tyhjäkäynti käyttää merkittävän määrän energiaa, ja siksi tätäon vältettävä [47, 48].

3.7.1. ContikiMAC

Vähävirtaisten langattomien sensorisolmujen täytyy rajoittaa energian kulutusta saa-vuttaakseen vuosien elinkaaren. Lähetin-vastaanotin on yleensä kaikista vähävirtaisenlaitteen osista suurikulutuksellisin. Langaton lähetin-vastaanotin käyttää suunnilleenyhtä paljon virtaa passiivisessa kuuntelussa, kuin aktiivisessa lähetyksessä. Se onkinsuljettava jotta säästettäisiin energiaa. Ja koska laite ei voi vastaanottaa mitään, kunlähetin-vastaanotin on pois päältä, täytyy ottaa käyttöön “duty cycling”. Tämän avullalaite käyttää lähetin-vastaanotinta päällä ja pois, aina silloin tällöin. [49]

Monenlaisia “duty cycling”-mekanismeja on esitetty. Contiki käyttää aloituskokoon-panossaan sen omaa ContikiMAC. Se käyttää ainoastaan asynkronisia mekanismejailman signaaliviestejä ja ylimääräisiä pakettiotsikkoja. ContikiMAC-paketit ovat nor-maaleja linkkikerroksen viestejä. [49]

ContikiMAC:llä on selkeästi energiatehokkaampi herätysmekanismi kuin aikaisem-milla “duty cycling”-mekanismeilla. Tämä on saavutettu täsmällisillä aikarajoitteilla.Lisäksi se käyttää [49]:

29

• nopeaa nukkumisoptimointia (sleep optimization); jotta vastaanottava osapuolivoi nopeasti huomata virheelliset herätysviestit ja

• siirron vaihelukko-optimointia (phase-lock optimization); että ajonaikaista siir-ron energiatehokkuuden optimointia voitaisiin hyödyntää.

ContikiMAC on saanut inspiraationsa jo olemassa olevista “duty cycling”-protokol-lista [49]. Periodisia herätteitä on käytetty muun muassa: B-MAC [50], X-MAC [16]ja BoX-MAC [51] protokollissa. Vaihelukko-optimisointia on ehdotettu aikaisemminWiseMAC:n [52] ja muiden protokollien yhteydessä [53]. Useiden datapakettien herä-tysmekanismia on käytetty ainakin TinyOS:n BoX-MAC-protokollassa [51].

ContikiMAC on “duty cycling”-protokolla, joka käyttää periodisia herätteitä kuun-nellakseen naapureiden pakettilähetyksiä. Jos hereilläoloaikana havaitaan paketin lä-hetys; jätetään vastaanottava laite päälle vastaanottamaan pakettia. Kun paketti on ko-konaisuudessaan vastaanotettu; vastaanottaja lähettää tästä linkkikerroksen hyväksyn-täviestin (ACK-viestin). Paketin lähetystä varten lähettäjä lähettää pakettia kunnes sevastaanottaa linkkikerroksen hyväksyntäviestin paketin vastaanottajalta (kuva 7.). [49]

Paketit, jotka lähetetään yleislähetysviesteinä eivät tuota linkkikerroksen hyväksyn-täviestiä. Sen sijaan lähettäjä lähettää jatkuvasti pakettia (burst effect) täyden aikaik-kunan ajan varmistaakseen, että jokainen naapurisolmu saa paketin (kuva 8.). [49]

Lähettää datapaketteja kunnes ACK-viesti on vastaanotettu

Lähettäjä

Vastaanottaja A

D

A

Datasiirtoa havaittu

Vastaanottoikkuna

Datapaketti

ACK-paketti

Kuva 7. ContikiMAC toteuttaa jaksollista herätystä

3.7.2. X-MAC

X-MAC on vähävirtainen MAC-protokolla, joka hyödyntää esikyselyitä herättääk-seen vastaanottajan kuvan 9. mukaisesti. “Duty cycling” on yksi tärkeimmistä me-kanismeista, kun halutaan saavuttaa vähäkulutuksellinen toimintamalli langattomissaenergiarajoitteisissa sensoriverkoissa. X-MAC käyttää lyhennettyä esitoimintoa (shortpreamble), joka säilyttää vähävirtaisen kuuntelun, kommunikaation, yksinkertaisuu-den sekä irtokytkennän hyödyt (loose coupling) lähettimen ja vastaanottimen välillä.[16]

X-MAC-protokolla koostuu seuraavista ominaisuuksista [16]:

30

D D D D

Lähettää datapaketteja koko aikaikkunan ajan

Lähettäjä

Vastaanottaja

D

Datasiirtoa havaittu

Vastaanottoikkuna

Datapaketti

D D

Kuva 8. Contikin yleislähetys

Datan

lähetys

Lähettäjän osoitetiedot

LPP

Lähettäjä (L)

Datan

vastaan-

otto

Aika

Aika

LPP

Vastaanottaja (V)

V herää Kuuntelee jonottavia paketteja

Pidennetty odotusaika

X-MAC

Lähettäjä (L)

Heräteviestejä, joissa

lähettäjän tiedot

Vastaanotetaan

ACK-viesti

Datan

lähetys

Aika

X-MAC

Vastaanottaja (V)

A

C

K

Datan

vastaan-

otto

V herää ACK-viesti lähettäjälle

Säästetty aika ja

energia L & V:lla

Aika

Kuva 9. X-MAC-protokollan toimintaperiaate verraten LPP-protokollaan

• energiatehokkuudesta,

• yksinkertaisuudesta,

• vähäisistä kiinteistä kustannuksista,

31

• hajautetusta implementaatiosta,

• vähäisestä tiedon käsittelyajasta,

• datan maksimaalisesta läpiviennistä sekä

• erilaisten pakettien että bittivirtojen hallinnasta.

3.8. Cooja-simulaattori

Contiki-järjestelmä sisältää verkkosimulointiohjelman Cooja, jolla pystytään simuloi-maan sensorisolmuverkkoja [54]. Sensorisolmut voidaan jakaa kolmeen luokkaan [55]:

• emuloitaviin solmuihin; missä koko sensorisolmun laitteisto emuloidaan,

• Cooja-solmuihin; missä Contiki-koodi käännetään ja suoritetaan simulaatiopäät-teessä tai

• Java-solmuihin; jossa solmun käyttäytyminen pitää uudelleentoteuttaa Java-luokalla.

Yksittäinen Cooja-simulointi voi sisältää sekoituksen kaikkia näitä edellä mainit-tua kolmea simulointiluokkaa. Muitakin emuloituja sensorisolmuja voidaan käyttääCooja-simulointiympäristössä. [55]

Tällä hetkellä Contiki 2.7 tukee Texas Instrumentsin MSP430 ja Atmelin AVR mik-rokontrollereiden emulointia.

32

4. SENSORIVERKKOJEN WEB-PALVELUTUET

Web-palvelut ovat tuoneet uuden kerroksen toiminnallisuuksia tämän päivän web:iin[56]. Hyödyntämällä jo olemassa olevia web-standardeja ja täten ottamalla ensim-mäisen askeleen kohti saumatonta hajautettujen ohjelmakomponenttien integraatio-ta [56, 57]. Web-palveluiden avulla saavutetaan riippumattomia teknologiaratkaisuja;hyvin määriteltyjä rajapintoja laitteisto-, ohjelmisto- ja ohjelmointikielestä riippumat-tomille funktionaalisuuksille [57]. Hajautetut funktionaalisuudet ja palvelut pystyvätkommunikoimaan web-palvelurajapintojen kautta ilman huolta siitä mitä laitteistoa,käyttöjärjestelmää tai ohjelmointikieltä käytetään [57].

Web-palveluteknologioista on tullut toimialastandardi. Kytkettäessä etäresurssejasekä heterogeenisiä resursseja, on mobiililaitteista kehittynyt elintärkeä osa ihmistenelämää. Ihmiset käyttävät mobiililaitteita ajasta sekä paikasta riippumatta. Käytämmelaitteita; sähköpostin tarkastamiseen, Internetin selaukseen tai muiden applikaatioidenajoon. [57]

Web-palveluteknologiat ovat huomanneet mobiilitiedonkäsittelyn yhtenä uutena suun-tana web-palveluille. Laitteiden ja palveluiden yhdistäminen mahdollistaa web-palve-luiden tiedonkäsittelylle mobiliteettiin ilman fyysisiä taikka laitteistollisia rajoitteita.Mobiilitiedonkäsittely tarvitsee teknologian mikä yhdistää mobiilijärjestelmät perin-teisiin hajautettuihin tiedonkäsittelyjärjestelmiin. Web-palvelut on yksi mahdollisistaratkaisuista; koska se kykenee tarjoamaan vahvat yhteensopivuusominaisuudet. [57]

Vaikka viime aikoina mobiililaitteiden kapasiteetit ovat kasvaneet selkeästi; ovat nekuitenkin vielä liian vähäresurssisia pyörittämään tämän hetkisiä web-palvelusovellus-malleja, ja johtaen toiminnallisuuksien vajavaisuuteen. Tämä ongelma kumuloituu sel-keästi kahdesta muuttujasta. Ensinnäkin siitä, että runsassanaisten XML-pohjaistenSOAP-viestien (Simple Object Access Protocol) koodaus ja dekoodaus tarvitsee koh-tuuttoman määrän resursseja laitteelta. Tämän johtaa siihen, että web-palveluita käyt-tävät laitteet, varsinkin mobiililaitteet, kärsivät huonosta suorituskyvystä. Toiseksi toi-minnallisuus ja laatuero, langattomien ja langallisten kommunikaatioiden välillä ei tu-le kaventumaan nopeasti. Tämä selittyy mobiiliympäristön rajoitteilla, ja tarkemminrajoitetusta prosessointitehosta, patterin käyttöiästä ja hitaista epäluotettavista yhteyk-sistä. [57]

4.1. Mobiili web-palvelut

Mobiili web-palvelut on avoin tutkimusala [58, 59]. On esitetty useita mobiililait-teille suunnattuja optimointimenetelmiä viestin kiinteiden kustannusten tehostamiselle[60, 61, 62]. Kuten jo mainittu aikaisemmin, jos käytetään nykyisiä web-palveluidenkommunikaatiomalleja mobiilitiedonkäsittelyyn törmätään melkeinpä tapauksetta hy-väksymiskelvottomiin performanssikuluihin [57]. Sensoriverkkojen kannalta tyypilli-nen web-sovelluksen implementointi web-palveluna vaatii neljä-viisi kertaa enemmäntiedonsiirtoa kuin se mitä saman palvelun rakentaminen dynaamisena ohjelmana vie,kuten ASP:ssa (Active Server Page) [63].

33

4.1.1. XML

XML tulee sanoista ekstensiivinen merkintäkieli, ja se kuvaa XML-dokumenttiluokandataobjekteja sekä osittain tietokoneohjelmien käyttäytymistä missä sitä suoritetaan.[64]

XML-dokumentit rakentuu entiteettirakenneyksiköistä, jotka sisältävät joko eritel-tyä tai erittelemätöntä dataa. Eritelty data koostuu merkeistä, jossa osa muodostaamerkkidataa ja osa merkkauksen. Merkkaus enkoodaa kuvauksen dokumentin varas-tointisuunnittelusta sekä loogisesta rakenteesta. XML luo mekanismin kohdata varas-tointisuunnittelun ja loogisen rakenteen rajoja. [64]

Ohjelmamoduuli; XML-prosessoria käytetään XML-dokumenttien lukemiseen, se-kä päästäkseen käsiksi sisältöön että rakenteeseen. Oletetaan, että XML-prosessoritekee toisen moduulin (sovelluksen) puolesta työtä. Tämä spesifikaatio määritteleeXML-prosessorille vaadittavan käyttäytymisen eli esitysmuodon (kuva 10.) missäXML-data ja informaatio täytyy esittää/välittää sovellukselle. [64]

<Sensorit>

<Zolertia Z1>

<Toiminta>Lämpötila</Toiminta>

<Arvo>17.8</Arvo>

</Zolertia Z1>

</Sensorit>

Kuva 10. Yksinkertainen XML-dokumentti

4.1.2. JSON

JSON (JavaScript Object Notation) on kevyt, tekstipohjainen, kieliriippumaton data-siirtomuoto rakenteellisen tiedon sarjoittamiseen. JSON periytyy sananmukaisesti Ja-vaScriptista, kuten se on määritelty ECMAScript-ohjelmointikielistandardissa. [65]

JSON esittää neljä primitiivistä tietotyyppiä (merkkijonot, numerot, totuusarvot jatyhjän) ja kaksi rakennetyyppiä (objektit ja listat) [65]:

• merkkijono; on nollan sekvenssi tai sekvenssi Unicode-merkkejä,

• objekti; on nollan järjestelemätön kokoelma tai kokoelma nimi/arvopareja, missänimi on merkkijono ja arvo on merkkijono, numero, totuusarvo, tyhjä, objekti tailista,

• lista; on järjestyksellinen sekvenssi nollaa tai muita arvoja ja

• totuusarvo; on tietotyyppi, jonka arvo on joko tosi tai epätosi.

JSON suunnittelutavoite oli kyetä olemaan minimaalinen, portattava, tekstuaalinensekä aliosa JavaScriptia. [65]

34

JSON tarjoaa paremman ratkaisun kuin XML ainakin JavaScript-ympäristöön, kos-ka parsimisen sijaan kuten XML:ssä JSON on suoraan sovitettu kunnolliseen datara-kenteeseen. Sen puolesta JSON on tärkeä ja varteenotettava vaihtoehto Web 2.0 sovel-luksissa. JSON-parseri on tarjolla lähestulkoon kaikille ohjelmointikielille. Kuvassa11. on esimerkki JSON-objektista. [14]

{"Zolertia Z1": {

"Toiminnallisuus": [

{"nimi": "RSSI", "arvo": 2301.9},

{"nimi": "Valo", "arvo": 87.0}

]}}

Kuva 11. Yksinkertainen JSON-objekti

4.2. SOAP

Web-palveluiden yhteentoimivuus kumpuaa XML-kielen luomista avoimista standar-deista [57]. SOAP [66] on määritelty XML:n avulla. Koska SOAP-viestit ovat teksti-pohjaisia ja itseselkoisia, ne voivat kuljettaa heterogeenisissä tietoympäristöissä infor-maatiota ilman konversio-huolia [57]. On olemassa myös monia muita web-palvelu-spesifikaatioita, jotka perustuvat XML, kuten WSDL (Web Service Description Lan-guage) [67] ja UDDI (Universal Description Discovery Integration) [68]. WSDL mää-rittelee menettelystandardin web-palveluille ja sen mahdollisuuksille [57]. WADL(Web Application Description Language) UDDI puolestaan määrittelee XML-pohjaisetsäännöt web-palveluinformaation julkaisulle [57]. Viestien vaihto tapahtuu SOAP-protokollan läpi [57]. SOAP-protokollan periaate perustuu viestinvaihtoon HTTP-protokollan yli; GET/POST-viestien välityksellä [57].

4.3. ROA

Resurssiorientoitunut arkkitehtuuri (Resource-Oriented Architecture, ROA) on keinokääntää ongelma RESTful-web-palveluksi [32]. Asetelma, missä URI, HTTP ja XMLtoimivat yhteen, kuten muuallakin web:ssä [32]. Ja mitä myös ohjelmoijat käyttävätmielellään [32]. Toisenlainen nimitys tällaiselle toimintamallille on WOA (Web Orien-ted Architecture) [69].

ROA:n konseptirakenne on seuraavana [32]:

1. resurssit,

2. resurssien nimet (URI:t),

3. resurssien esittely ja

4. resurssien väliset yhteydet.

35

Neljä ominaisuutta [32]:

1. osoitettavuus,

2. tilattomuus,

3. yhtenäisyys ja

4. yhtenäinen rajapinta.

On käynyt hiljattain selväksi, että osa näistä lähestymistavoista ei ole noudattanutkaikkia REST:n määrittelemiä vaatimuksia, jolloin on alettu käymään keskustelua siitämiten rajoitteita pitäisi noudattaa ja onko kaikille edes tarvetta. [70]

Kun seurataan hypermediavaatimuksia, ROA-arkkitehtuuri on itseasiassa huonom-min skaalautuva että muokattava, kuin ne arkkitehtuurit jotka mukailevat REST-periaat-teita. Kuitenkaan ei tiedetä tarkalleen, kuinka paljon skaalautuvuus tai muokattavuusovat kärsineet. [70]

4.3.1. WOA

WOA on palveluarkkitehtuurimalli, joka integroi järjestelmän ja käyttäjän web-arkkiteh-tuuriin hypermediakytkennöillä. Tämä arkkitehtuuri korostaa käyttäjä- sekä sovellus-rajapintojen geneerisyyttä saavuttaakseen maailmanlaajuisen verkkovaikutuksen käyt-täen viittä rajapintaperiaatetta [71]:

1. resurssien identifiointi,

2. resurssien käsittelyä esitysten välityksellä,

3. itseselkoiset viestit,

4. hypermedia sovellustilan moottorina ja

5. sovellus neutraalisuus.

4.4. RESTful-web-palvelu

REST on sovellusarkkitehtuuri, joka mallintuu siitä miten tietoa esitellään, käytetäänja muutetaan verkossa. REST-arkkitehtuurissa tietoa ja toiminnallisuuksia käsitelläänresursseina. Resursseihin päästään käsiksi käyttämällä URI-identifioijaa, joka monessatapauksessa on verkkolinkki. [7, 8, 32]

Resursseja pystytään käsittelemään selkeästi määritellyillä operaattoreilla. REST-arkkitehtuurin filosofia on käyttäjän ja palvelimen välinen interaktio. Kommunikaa-tiomekanismina REST:ssä käytetään tyypillisesti tilatonta kommunikaatioprotokollaa;kuten HTTP:ta. REST-arkkitehtuurissa käyttäjä ja palvelin vaihtavat resurssien esitte-lyjä; hyödyntämällä standardisoitua rajapintaa sekä protokollaa. [7, 8, 32]

Nämä periaatteet rohkaisevat REST-sovelluksia olemaan yksinkertaisia, keveitä jatehokkaita toiminnallisuuksiltaan. [7, 8, 32]

36

REST-pohjaiset web-palvelut tähtäävät yksinkertaisuuteen, ja tämä saavutetaan ra-jaamalla resurssioperaatioita. REST:n kehittäjät väittävät, että se [7]:

• välimuistin tukemisen ansiosta se tarjoaa paremman vasteen ja palvelimen la-tausajan,

• parantaa palvelimen skaalautuvuutta; vähentämällä kommunikaatiotilojen säily-tystarvetta,

• tarvitsee vähemmän asiakasohjelmapuolen koodia verraten muihin lähestymis-tapoihin, koska yksi selain pystyy käyttämään mitä tahansa sovellusta tai resurs-sia,

• on vähemmän riippuvainen toimittajan ohjelmasta, kuin mekanismi; joka raken-taa viesti-ikkunakerroksen HTTP:n päälle,

• luo samat funktionaalisuudet, kun verrataan vaihtoehtoisiin kommunikoinnin lä-hestymistapoihin,

• hyperlinkkien ansiosta se ei tarvitse erilaista resurssien etsintämekanismia,

• antaa paremman pitkäntähtäimen yhteentoimivuuden sekä kehittymismahdolli-suudet kuin RPC, tämä puolestaan mahdollistaa:

– HTML-dokumenttityyppien kehityksen taakse- että eteenpäin ilman, ettäne menettäisivät toimintakykyään sekä

– resursseille kyvyn lisätä uusille sisältötyypeille tukea ilman vanhempiensisältötyyppien poistamista taikka vähentämistä (MIME-tyypit, Multipur-pose Internet Mail Extensions).

RESTful-web-palvelut ovat REST-arkkitehtuuria hyödyntäviä web-sovelluksia. Nii-den resurssit on saatavilla URI-identifioijan välityksellä käyttäen neljää HTTP-protokol-lan sisäistä resurssimetodia; luonti, hakeminen, päivitys ja poisto. [7, 8, 32]

HTTP-metodi CRUD-toimintoGET Resurssin hakuPOST Resurssin luontiPUT Resurssin päivitysDELETE Resurssin poisto

Yksi suosituimmista lähestymistavoista on WADL (Web Application DescriptionLanguage). WADL määrittelee resurssit perustuen URI-polkurakenteeseen. WADL:nheikkoutena on kuitenkin RESTful-hypermediapalveluiden tuen uupuminen. [72]

ReLL (Resource Linking Language) on toisenlainen yritys ylittää WADL:n tuomatrajoitteet, sillä se määrittelee itsensä resurssien ja linkkien kautta ja antaa näille suu-rimman painoarvon [73]. Myös WSDL 2.0 tarjoaa eksplisiittisen HTTP-sidoksen [72].

Vielä ei ole ohjelmointi(prosessointi)kieltä kuvaamaan RESTful-palveluita. Myös-kään yhteisymmärrystä olisiko se edes hyödyllinen taikka vaadittava. Mitä kuvattaisiinja mitä jätettäisiin kuvaamatta, jotta säilytettäisiin irtonaiset liitokset? Monet tämänhet-kiset RESTful-rajapinnat luottavat HTML-dokumentaatioon. [74]

37

Sen lisäksi, miten perus RESTful-palvelurakenne kuvataan (resurssien, esittelymuo-don, yhtenäisen rajapinnan ja linkitysten avulla), on herännyt kysymyksiä, miten pal-veluita voidaan kuvataan semanttisella tasolla. Pääperiaate tässä on, että pyritään etsi-mään/löytämään palvelu pelkästään tarkastelemalla semanttista tasoa. [75]

Näin semanttiset web-palvelut ovat saaneet tutkijoiden huomiota. Erityisesti semant-tinen web ja linkitetty data ovat olleet erityisen tarkkailun alla. Moni lähestymistapapohjautuu edeltävän palvelurajapinnan kuvauskieleen, jossa tarkastellaan lähemminsen semantiikkaa, ja usein palvelukuvaukseen sulautetulla RDF-esityksellä (ResourceDescription Framework). Tällaisessa skenaariossa on mahdollista kerätä RDF-esitysannetuista palvelukuvauksista ja sen jälkeen soveltaa semanttisia web-metodeja RDF-dataan. [75]

4.4.1. HATEOAS

HATEOAS:ssa asiakasohjelman taikka palvelimen ei tarvitse pitää istunnon aika-na tilatietoja muistissa, koska kaikki tarvittava tieto on sidottu vaihdettaviin HTTP-viesteihin (URI:n ja HTTP-otsakkeihin sekä -rakenteeseen). Itseselkoisten yhteyksienmäärittely on erittäin tärkeää RESTful-web-palveluille, koska näiden yhteyksien avul-la on mahdollista siirtyä, löytää ja yhdistää muita palveluja sekä sovelluksia. [76]

Tämä on kuitenkin erittäin haastavaa, koska monimutkaiset interaktiot muuntuvatmonimutkaisiksi URI:ksi. Laajoilla sovelluksilla on monia eri tiloja, joista asiakas-ohjelman täytyy olla tietoinen. HATEOAS pakottaa web-palvelut paljastamaan nämätilat yhteyksinä, joka puolestaan duplikoi palveluiden sisäisen toteutuksen. Välttääk-seen tällaisen duplikoinnin, jotkin RESTful-web-palvelut uudelleenjärjestelevät sovel-luksen paljastaakseen alikerroksen palvelurajapinnan, vaikka tämän tiedetään olevanväärin. [76]

Monet palvelut vaativat asiakasohjelmaa lähettämään käyttäjäspesifistä informaa-tiota (käyttäjä-ID) jokaisen URI-pyynnön yhteydessä. Tällöin saadaan kaksi täysin sa-maa pyyntöä näkymään uniikkeina tapauksina web-välimuistille. Välimuistit käyttävätURI-osoitteita tiedon avaimena. Yleensä käyttäjäspesifisen tiedon lähettäminen on tar-peetonta, erityisesti silloin, kun käyttäjä lähettää geneerisen pyynnön. [76]

Suurin osa web-palveluiden tuottajista kuitenkin käyttää spesifisiä viestejä rajoit-taakseen saman asiakasohjelman yhteydenottoja palvelussa. [76]

Koska HTTP-välipalvelinta ei voida käyttää HATEOAS-menetelmän kanssa (paitsitilanteessa missä sama käyttäjä pyytää saman resurssin uudestaan), täytyy palvelimenkäsitellä enemmän pyyntöjä, joka puolestaan sotii pyyntömäärien rajoittamista vas-taan. Tämä vastakkainasettelu rikkoo kahta periaatetta; resurssien identifiointia sekäHATEOAS:ia, koska muut käyttäjät eivät voi käyttää URI:n esittämää tilaa. [76]

4.4.2. Välimuistitus

Yksi monista suorituskyvyn ominaisuuksista on välimuistitus, se on yksi parhaista esi-merkeistä, kun tarkastellaan, miksi kannattaa käyttää HTTP:tä oikein [77]. Asiakas-ohjelma, palvelin tai välikädet voivat välimuistittaa dataa, samalla tavalla kuin web-reititin [77]. Alkuaikoina oli mahdollista välimuistittaa 24-45%-osuus tyypillisestä

38

web-liikenteestä, joka oli suurelta osin staattista sisältöä [77]. Nykyään osuus on ar-violta 20-30%, joka on erittäin vakuuttavaa, kun otetaan huomioon se kuinka dynaa-mista web-sisältö on [78].

Valitettavasti suurin osa RESTful-palveluista ei hyödy välimuistituksesta. Monet ra-kenteet eivät tue välimuistitusta. Tyypillisesti URI:t eivät siihen pysty, koska RESTful-web-palvelut tarvitsevat käyttäjätietoja jokaisessa pyynnössä. On myös epätodennä-köistä, että web-palvelut luopuvat käyttäjä-ID:n käytöstä. Onkin ehkä aika jo uudistaamalleja, ja lähteä katsomaan välimuistitus ratkaisuja RESTful-sovelluksiin spesifisis-ten URI-sidoksien ulkopuolelta. [76]

Yleisesti halutaan web-välimuistitus, mutta yksi selkeä yhtenäinen välimuistitus-malli kuitenkin puuttuu. [76]

4.4.3. Ylläpito

Web-palveluiden normaalit huoltopäivitykset (uusien ominaisuuksien lisäys, palvelu-rajapintojen korjaus) vaikuttavat web-palveluihin itseensä, niiden dokumentaatioon,asiakasohjelman koodiosuuteen ja jopa kehitystyökaluihin. Koska RESTful-web-palve-lut ovat edelleen virhealttiita kokonaisvaltaisille muutoksille, on näissä siten aihetta lä-hempään tarkkailuun. [76]

Muutokset web-palvelumäärityksiin johtavat välttämättömiin uudistuksiin asiakas-ohjelman koodiosiossa. Kun palvelun uusi versio julkaistaan, asiakasohjelmien täytyysopeuttaa niiden koodia.

WS- eivätkä RESTful-palvelujen tarjoajat tee päivittämisestä helppoa. Heidän väit-tämänsä on, että rajapintoja tulee aina olemaan ja sen puolesta asiakasohjelman ei tar-vitse päivittyä. Ideaalitilanteessa tämä olisi tosiaan mahdollista, koska hyvin määritel-tyjen resurssien ei tarvitse muuttua. Uusilla web-palveluilla on mahdollista säilyttääedellisetkin rajapinnat, mutta useiden rajapintojen ylläpito ei ole realistista, jos palveluaikoo kehittyä. [79]

4.4.4. Turvallisuus ja yksityisyys

RESTful-web-palvelujen turvaaminen on monitasoinen haaste; se tarkoittaa datan sekäkoko kommunikaation turvaamista. Turvaaminen vaatii datan tietosuojausta sekä senkoskemattomuutta. Siirretty data on aina tarkistettava virheellisyyksien varalta. Kom-munikaatiomenetelmän täytyy tukea autentikointia sekä datan käsittelykontrollia. Onmyös varmistettava, että kommunikaatio-osapuolten yksityisyyttä ei rikota missään in-teraktion vaiheessa. [76]

Verrattuna WS-turvallisuusrakenteeseen (Web Service), RESTful-palvelut luottavaterinäisiin lisäosiin, jotka toimivat HTTP:n päällä [80]. HTTPS (Hypertext TransferProtocol Secure) on laajalti käytetty luottamuksellisen tiedonsiirron yhteydessä, muttase tarjoaa kuitenkin vain “hop-by-hop”-turvallisuuden [81]. Tarvitaan viestikerroksensopeuttamista HTTP:n turvallisuusmekanismiin [76].

Toisin kuin WS-palveluiden kanssa, RESTful-palveluille ei ole standardeja mitä seu-rata REST-arkkitehtuurin kehittäjät ottavat mallia käytössä olevista arkkitehtuureista,kuten esimerkiksi Amazon S3-palvelusta [82]. Amazon S3 hyödyntää aikaleimaus-

39

ta, jolla ehkäistään pyyntöjen uudelleenlähetykset [82]. Erilaisia asiakasohjelman japalvelimen puoleisia suodattimia täytyy toteuttaa näiden vaatimusten saavuttamiseksi[76].

Uusia HTTP-palveluille tarkoitettuja turvallisuusteknologioita tulee vähitellen. Näi-tä ovat esimerkiksi OpenId [83] ja OAuth 1.0 [84]. OpenId keskittyy identiteetin tur-vaamiseen ja OAuth autentikaatioon sekä tiedonsiirron turvaamiseen.

4.5. RESTful ja muita web-palveluratkaisuja

REST-pohjaiset web-palvelut jakavat monia ominaispiirteitä muiden web-palveluidenkanssa, kuten SOAP-pohjaisten RPC:n ja dokumentti-web-palveluiden kanssa. Nemyös eroavat monella tärkeällä piirteellä. RPC ja dokumenttipohjaiset web-palvelutkuten REST-pohjaiset web-palvelut ovat suunniteltu olemaan keveitä, URI-käyttöisiäja jotka tyypillisesti tukeutuvat HTTP:hen. REST- ja SOAP-pohjaiset web-palvelutovat myös alustaltaan sekä ohjelmointikieleltään riippumattomia, ja molemmissa ark-kitehtuureissa käyttäjä sekä palvelin ovat irtonaisia kytköksiä. Näin ollen käyttäjä japalvelin eivät tiedosta toisiaan juuri lainkaan, ainoastaan rajallisella määrällä oletta-muksia. [7]

REST-pohjaisia web-palveluja kehitetään monesti korvaamaan SOAP-pohjaisia web-palveluita sen heikkouksien vuoksi. SOAP-protokolla kehitettiin ajatuksena luodaRPC-kutsuja HTTP:n välityksellä, käyttäen XML-merkintäkieltä dataformaattina sekäXML:n standardoimia tietotyyppejä. Lopulta SOAP-pohjaisten web-palveluiden RPC-aspektia laajennettiin dokumenttipohjaisella arkkitehtuurilla, missä käyttäjät ja palve-limet vaihtoivat XML-dokumentteja saadakseen muutosta käyttäjän tai palvelimen so-velluksissa. Kun SOAP-pohjaisten web-palvelut kehittyivät niiden arkkitehtuuri laa-jentui vastaamaan entistä monimutkaisempien sovellusten toiminnallisuuksia; kutenturvallisuuteen ja viestien luotettavuuteen. Lopulta SOAP-pohjaisten web-palveluidenkehittämisestä tuli entistäkin monimutkaisempaa. [57]

40

5. OHJELMATOTEUTUS

Langattomat sensoriverkot koostuvat monista erilaisista ohjelmoitavista radiollisistasulautetuista laitteista. Verkon käyttäytyminen on yleensä koodattu sensoreihin ohjel-malatauksen aikana.

Monesti laitteistoissa olevaa ohjelmaa on muokattava toiminnallisuuden parantami-seksi tai uusimiseksi [85]. Dynaaminen uudelleenkonfigurointi mahdollistaa juuri tä-mänkaltaisen toiminnan sensoriverkoissa. Rakennettaessa ohjelmistoa langattomallesensoriverkolle on myös sen kehitysajan kannalta suosiollista kyetä päivittämään jokäytössä olevaa toteutusta.

Toimivassa sensoriverkossa voidaan myös joutua uudelleenkonfiguroimaan ohjel-mistoa [5]. Tämä voi olla esimerkiksi parametrien uudelleenmääritystä tai absoluut-tisten arvojen muokkaamista [5]. Vaikka uudelleenkonfiguraatio ei välttämättä tarkoi-ta ohjelmistopäivitystä, voidaan uudelleenkonfiguraatiot suorittaa uudelleenohjelmoin-nilla [86]. Näin ollen voidaan ajatella ohjelmistopäivitysten olevan ohjelmiston uudel-leenkonfiguraatioskenaarioita [42].

Tiedonsiirtokaistan kapeus, rajallinen sensorisolmun energia, muistin vähyys (useinvain muutamien kilotavujen kokoinen) sekä rajallinen prosessointiteho tekee sensori-verkon solmujen uudelleenohjelmoinnista haastavaa.

5.1. Ohjelmakoodin suoritusmalleja ja uudelleenohjelmointi

Viime vuosikymmenen aikana on dynaamiselle uudelleenkonfiguraatiolle esitetty mo-nia erilaisia ratkaisumalleja; kuten täydellinen järjestelmän korvaaminen [87, 88], bi-näärieroihin perustuva lähestymistapa [89, 90], virtuaalikoneet [91, 92, 93] sekä ladat-tava natiivikoodimoduuli (Contikin ensimmäisessä versiossa) [38]. Lähestymistavanvalinta vaikuttaa oleellisesti sensorisolmulle siirrettävän datan muotoon sekä kokoon[42].

5.1.1. Skriptauskielet

Sulautetuille järjestelmille löytyy paljon erilaisia esimerkkejä skriptauskielten käy-töstä, kuten BASIC:n (Beginner’s All-purpose Symbolic Instruction Code) variaatiot,Python-tulkkaukset [42] ja TCL-skriptaus (Tool Command Language) [94]. Kuiten-kin monet tulkkaukset kohdentuvat enimmäkseen alustoille, joissa on huomattavastienemmän resursseja, kuin tässä työssä käytettävän Zolertia Z1.

5.1.2. Virtuaalikoneet

Virtuaalikoneita käytetään yleensä silloin, kun halutaan vähentää ohjelmakoodin so-vittamisesta syntyviä kuluja. Yleensä virtuaalikoneiden ohjelmakoodi voidaan tehdäkompaktimmaksi kuin suoraan laitteistolle ohjelmoitava koodi. Juuri tämän vuoksi vir-tuaalikoneita käytetään sensoriverkkojen ohjelmoinnissa. [92, 93, 95, 96]

41

Java-pohjaiset virtuaalikoneet ovat itsessään jo hyvin geneerisiä. Niille voidaan tuot-taa kirjo eri tyyppisiä sulautetuille järjestelmille suunnattuja ohjelmistoja. Sensoriver-koille suunnatut virtuaalikoneet ovat puolestaan suunniteltu erittäin muokkautumisky-kyisiksi, tukeakseen laitespesifistä ohjelmistototeutusta. Käytännössä tämä tarkoittaa,että osa ohjelmistokoodista on implementoitu virtuaalikonetoteutuksella ja osa natiivi-koodilla. [42]

5.1.3. Natiivikoodi

Suorin tapa ajaa ohjelmakoodia sensorisolmussa on suorittaa natiivikoodia, jonka ajaasuoraan sensorisolmun mikrokontrolleri. Uuden natiivikoodin asennus sensorisolmulleon haasteellisempaa kuin virtuaalikoneeseen asennus. Tämä johtuu siitä, että natiivi-koodi käyttää fyysisiä osoitteita, joka yleensä vaatii osoitteiden päivittämisen ennenkuin ohjelma voidaan suorittaa. [42]

Kokonaisen levykuvan korvaaminen

Yleisin menetelmä uuden ohjelman asennukseen sulautetuissa järjestelmissä on kään-tää ohjelmasta täysin uusi binäärilevykuva käyttöjärjestelmän kanssa, ja ylikirjoittaatämä sensorisolmussa olevan järjestelmälevykuvan päälle. Se on myös TinyOS:ssa ole-vien verkkototeutuksien XNP:n ja Deluge:n käyttämä oletusmenetelmä. [97]

Levykuvan kokonaan korvaamiseen ei tarvita ladatulta järjestelmälevykuvalta lisä-prosessointia ennen kuin se on täysin ladattu uuteen järjestelmään. Uusi levykuva ni-mittäin sijaitsee samassa fyysisessä osoitteistuksessa kuin edellinenkin. [42]

Esimerkiksi Scatterweb-järjestelmäkoodi sisältää käyttöjärjestelmälevykuvan sekäpienen määrän funktioita, joilla se pystyy lataamaan uuden käyttöjärjestelmälevyku-van. Funktionaalisuuksien avulla uusi käyttöjärjestelmälevykuva voidaan ylikirjoittaaolemassa olevan levykuvan päälle ilman, että latausfunktiot ylikirjautuisivat. Lataus-funktioiden osoitteet on kiinteäkoodattu järjestelmän levykuvaan. [98]

5.1.4. Erilaisuuksiin perustuva lähestymistapa

Järjestelmään tehtävä pieni päivitys, kuten ohjelmointivirheen korjaaminen, harvointekee kovinkaan isoa eroa uuden ja vanhan järjestelmälevykuvan välille. Näin ollen il-man, että vaihdettaisiin koko järjestelmälevykuva, vaihdetaan vain binäärierosta saata-vat deltat (muuttujat). Tämä vähentää huomattavasti siirrettävän datan määrää verratenkoko järjestelmälevykuvan korvaamiseen. [89, 90, 99]

5.2. Ladattava moduuli

Vähemmän tunnettu lähestymistapa on käyttää ladattavaa moduulia uudelleenohjel-moinnin mekanismina. Käytettäessä ladattavia moduuleja vain tiettyä osaa järjestel-mästä muokataan, kun yksittäiseen osaan tehdään korjauksia. Yleensä ladattava mo-

42

duuli tarvitsee tukea käyttöjärjestelmältä. Contiki ja SOS ovat esimerkkejä käyttöjär-jestelmistä, jotka tukevat ladattavia moduuleja. [42]

Ladattava moduuli sisältää myös ohjelman lisäksi järjestelmän natiivia konekoodia.Moduulissa oleva konekoodi sisältää yleensä viittauksia järjestelmän funktioihin taimuuttujiin. Nämä viittaukset täytyy kääntää funktioiden tai muuttujien osoitteiksi en-nen kuin konekoodia voidaan suorittaa. Tätä prosessia sanotaan linkitykseksi. [42]

Linkitys voidaan tehdä joko kun moduuli on käännetty tai ladattu. Käännösvaiheenjälkeistä linkitystä sanotaan esilinkitykseksi (pre-linking) ja latauksen jälkeistä dynaa-miseksi linkitykseksi (dynamic linking). Esilinkitetty moduuli sisältää viitattujen funk-tioiden tai muuttujien absoluuttisia osoitteita, missä dynaaminen linkitys puolestaanhyödyntää symbolisia nimiä, joka myös puolestaan kasvattaa dynaamisen linkitysmo-duulin kokoa (kuva 12.). [42]

Ydin

0x0238

0x1320

int memcpy() {

/* ... */

}

double temp_get() {

/* ... */

}

Esilinkitetty moduuli

memcpy(); call 0x0238

call 0x1320temp_get();

Dynaamisen linkityksen moduuli

memcpy();

temp_get();

call 0x0000

call 0x0000

temp_get

memcpy

call instruction

call instruction

Kuva 12. Esilinkkerin ja dynaamisen linkkerin ero

Konekoodi sisältää yleensä myös moduulin sisäisten funktioiden ja muuttujien re-ferenssitietoja. Funktioiden fyysiset osoitteet muuttuvat riippuen siitä minne ladattavamoduuli järjestelmässä sijoittuu. Viittausten osoitteet täytyy siten päivittää fyysisiksiosoitteiksi. Viittausten päivittämisestä käytetään nimeä uudelleensijoittaminen. Kutenlinkittäminen, myös uudelleensijoittaminen voidaan suorittaa joko käännön tai ajonaikana. [42]

43

Kun moduuli on linkitetty ja uudelleen sijoitettu; ohjelmalataaja lataa moduulin jär-jestelmään kopioimalla linkitetyn ja uudelleen sijoitetun natiivikoodin muistipaikkaan,missä sen ajaminen on mahdollista. [42]

5.2.1. Esilinkitetty moduuli

Esilinkitetyn moduulin järjestelmäkoodissa sijaitseva konekieli sisältää kaikkien funk-tioiden ja muuttujien absoluuttiset osoitteet. Moduulin linkitys tapahtuu käännösvai-heessa ja vain uudelleensijoittaminen tapahtuu ajon aikana. Esilinkitetyssä tieto kaik-kien järjestelmässä olevien funktioiden ja muuttujien fyysisistä osoitteista täytyy ollatarjolla. [42]

Esilinkitetyllä moduulilla on kaksi etua verrattuna dynaamisesti linkitettyyn moduu-liin. Ensimmäiseksi, esilinkitetyt moduulit ovat pienempiä kooltaan kuin dynaamiset,jolloin dataa siirretään vähemmän. Toiseksi, esilinkitetyn moduulin lataamisprosession yksinkertaisempi kuin dynaamisesti linkitettävän moduulin. [42]

Tosiasia on kuitenkin se, että kaikki järjestelmäytimen fyysiset osoitteet on kiinteä-koodattu esilinkitetyssä moduulissa. Tämä on erittäin jäykkä menettely, koska esilinki-tetty moduuli voidaan ladata järjestelmään ainoastaan samoilla linkityksen yhteydessägeneroiduilla osoitteilla. [42]

Alkuperäisessä Contiki-järjestelmässä dynaamiseen lataukseen käytettiin esilinki-tettyjä binäärimoduuleita [38]. Kun Contikin järjestelmäydintä käännetään, kääntäjägeneroi kartoitustiedoston, joka sisältää järjestelmäytimen globaalisti näkyvien funk-tioiden ja muuttujien osoitteet [42]. Tätä osoitteiden listaa käytetään esilinkittämäänContiki-moduuleja [42].

5.2.2. Dynaaminen linkitys

Dynaamisen linkityksen objektitiedosto sisältää koodin ja datan lisäksi järjestelmäy-timen funktionimet. Objektitiedoston koodia ei voi suorittaa ennen kuin viitattujenmuuttujien ja funktioiden fyysiset osoitteet on täytetty. Tämä prosessi tehdään ajonaikana dynaamisen linkkerin toimesta. [42]

Contikin dynaaminen linkkeri käyttää kahta tiedostoformaattia; ELF (Executableand Linkable Format) ja CELF (Compact Executable and Linkable Format). [42]

ELF

Yksi tunnetuimmista objektikoodiformaateista dynaamiselle linkitykselle on ELF-tiedostoformaatti [100]. Se on standardisoitu formaatti objekti- sekä suoritustiedostoil-le [42]. Sitä käytetään useimmissa moderneissa Unix-pohjaisissa järjestelmissä, kutenLinux, Solaris ja FreeBSN, mutta myös monissa sulautetuissa järjestelmissä [42]. ELF-tiedosto sisältää sekä ohjelmakoodin, että datan lisäksi myös symbolitaulun, selvittä-mättömien ulkoisten symbolien nimet ja uudelleenohjaustaulut [42]. Uudelleenohjaus-tauluja käytetään ohjelmakoodin ja muualla olevan alkuperäisdatan paikantamiseen[42]. Lisäksi ELF-tiedosto voi pitää sisällään testaustietoja; kuten tiettyjä konekoo-diohjeistuksien rivinumeroita ja lähdetiedostonimiä [42].

44

ELF on myös GCC:n (GNU Compiler Collection) oletusobjektitiedostoformaatti.Tämän vuoksi ELF-tiedostolle löytyy erittäin hyvin työkaluja, kuten virheiden jäljittäjä(debugger), linkkereitä, konverttereitä ja laskentaohjelmia ohjelmakoodidatalle sekädatamuistille. [42]

ELF-tiedosto sisältää otsikon, jonka jälkeen tyypillisesti seuraa ainakin binäärikoo-dille varattu alue (.text), alue staattisesti allokoidulle alustetulle datalle (.data), ja aluenolla-alustetulle datalle (.bss). Lisäksi jokainen muuttuja on esitetty symbolitaulussa(.symtab), ja merkkijonot lajiteltu merkkijonotauluun (.strtab). Jotta Contikin ELF-lataaja pystyy hyväksymään ELF-tiedoston, on siitä löydyttävä edellä mainitut osiot.[101]

CELF

ELF-tiedostoformaatissa on yksi selkeä ongelma: sen kiinteät kustannukset (over-head), verrattuna esilinkitettyyn moduuliin. Tälle on useita syitä. Ensimmäiseksi ELF,kuten muutkin dynaamisesti uudelleenohjattavat tiedostoformaatit, sisältää kaikkienajon aikana linkitettävien funktioiden ja muuttujien symboliset nimet. Toiseksi, ELF-formaatti on suunniteltu toimimaan 32- ja 64-bittisissä arkkitehtuureissa. Näin joudu-taan määrittelemään 32-bittinen datatyyppi kaikille ELF-datarakenteille. Tämä on tuh-lausta 8- tai 16-bittisille alustoille, sillä ylimmät 16-bittiä ovat käyttämättömiä. [42]

Vähentääkseen kiinteitä kuluja Contiki on kehittänyt ELF:n rinnalle oman CELF-tiedostoformaatin, joka mukailee alkuperäistä ELF-tiedostoformaattia sillä erolla, ettäCELF esitetään 8- ja 16-bittisillä datatyypeillä. CELF-tiedosto on kooltaan tyypilli-sesti puolet vastaavasta ELF-tiedostosta. Contikin dynaaminen lataaja osaa käsitelläCELF-tiedostoja. ELF-tiedoston konvertointi onnistuu työkaluohjelman avulla CELF-tiedostoksi. [42]

5.3. REST-moottori

Contiki OS tarjoaa paljon jatkomahdollisuuksia sen omien teknologiatoteutuksienpäälle. Tässä diplomityössä tärkein on Contikin toteuttama REST-moottori. Tämämahdollistaa CoAP-yhteyksien luonnin applikaatiorajapintojen kanssa. Näin voidaantoteuttaa sensorisolmun ja päätelaiteiden välille CoAP-yhteyteen perustuva kommu-nikaatio. Tässä työssä käytetään päätelaitteen selaimeen asennettavaa lisäosaa Copper(CoAP-rajapinta). Tällä hetkellä Copperin saa vain Mozilla Firefoxiin.

Työssä hyödynnetään REST-moottorissa olevia RESOURCE-makroja (listaus 5.1.)joilla voidaan automaattisesti toteuttaa sekä alustaa RESTful-webpalveluresursseja.Näin saadaan kerroksittainen yhteys mukailemaan täsmällisesti Contikin määrittele-mää verkkorakennetta.

Listaus 5.1. Makro REST-webpalveluresurssin luomiseen

/*

* Makro RESTful-resurssin määritykseen

* Resurssit määritellään staattisesti; tehokkuuden sekä paremman

* muistihallinan saavuttamiseksi.

*/

#define RESOURCE(name, flags, url, attributes) \

45

void name##_handler(void*, void*, uint8_t*, uint16_t, int32_t*);\

resource_t resource_##name = {NULL, flags, url, attributes,

name##_handler, NULL, NULL, NULL}

5.3.1. Resurssi ja resurssin käsittelijäfunktio

RESOURCE on REST-resurssi, joka määritellään URI-polulla, käytettävillä metodeil-la sekä merkkijonolla. Jokaista resurssia vasten applikaatiolla on oltava resurssin kä-sittelijäfunktio, joka vastaanottaa kyselyitä ja generoi saaduista tiedoista tälle resurs-sille ominaisen vastauksen. Molemmat viestitykset käyttävät REST-moottorin luomaarajapintaa, joka piilottaa sisälleen todellisen toimintamallin.

5.3.2. CoAP-viesti

CoAP hyödyntää HTTP:n resurssiabstraktion, URI:ja, RESTful:n toimintaperiaatet-ta sekä laajoja otsikkokenttiä. CoAP käyttää myös kompaktia binääriesitystä; joka onsuunniteltu olemaan helposti jäsennettävä. Toisin kuten HTTP, joka käyttää TCP:tä,CoAP hyödyntää UDP:ta (listaus 5.2. ja 5.3.). Tämä mahdollistaa CoAP:n käytön mo-nisuuntaisissa kommunikaatiomalleissa kuten yksi-monen ja moni-yhden kanssa.

• Applikaatio voi lähettää CoAP-viestejä luotettavasti (confirmable) tai epäluotet-tavasti (non-confirmable). Lähettäessä luotettavia viestejä, viestit uudelleenlä-hetetään kunnes vastaanottaja on hyväksynyt viestin vasten tiettyä aikarajaa taiyltäessään ennalta määriteltyyn uudelleenlähetysrajaan.

• CoAP tarjoaa natiivina resurssien seurantamekanismin, missä käyttäjä voi lä-hettää pyynnön seurantaotsikolla CoAP-resurssille. Tällöin palvelin pitää kirjaaresurssin muutoksista ja lähettää tilapäivityksiä aina resurssien muuttuessa.

• Resurssien havainnoinnissa CoAP seuraa RFC 6690, missä “/.well-known/core”-polku määrittelee resurssin CoRE-linkkimuodossa. Tällä myös määritellään att-ribuutteja, kuten "rt"(semanttinen tyyppi), "if"(käyttäjärajapinta), "ct"(sisältötyyppi)ja "sz"(resurssin maksimi koko).

Listaus 5.2. CoAP-viestin rakenne: lähettäminen

/* Alustetaan viesti */

void coap_init_message(void *packet, coap_message_type_t type,

uint8_t code, uint16_t mid);

/* Lähetetään viesti */

void coap_send_message(uip_ipaddr_t *addr, uint16_t port,

uint8_t *data, uint16_t length);

Listaus 5.3. CoAP-viestin rakenne: vastaanottaminen

/* CoAP-viestin vastaanottaminen */

int coap_get_payload(void *packet, const uint8_t **payload);

46

5.3.3. Blockwise-siirto

Contikin CoAP-implementaatio tukee lohkosiirtoa. Paketin ylittäessä tietyn koon,REST-moottori jakaa sen pienempiin osiin automaattisesti ilman käsittelijäfunktiota.Resurssi voi myös prosessoida suurta määrää dataa chunkwise-menetelmällä (listaus5.4.). Tätä varten on ilmoitettava tavuviittaus sekä haluttu lohkokoko käsittelijäfunk-tiolle ja ohjata nämä lohkot blockwise-siirtofunktiolle.

Listaus 5.4. Chunkwise-menetelmän perustoteutus

#define CHUNKS_TOTAL 2050

void chunks_handler(void* request, void* response, uint8_t *buffer,

uint16_t preferred_size, int32_t *offset) {

int32_t strpos = 0;

/* Generoidaan dataa kunnes saavutetaan CHUNKS_TOTAL */

while (strpos<preferred_size)

{

strpos += snprintf((char *)buffer+strpos, preferred_size

-strpos+1, "|%ld|", *offset);

}

/* Asettaa vastausviestin */

REST.set_response_payload(response, buffer, strpos);

/* Indikoi REST-moottorille chunk-wise-toiminnosta */

*offset += strpos;

/* Lopettaa resurssin toiminnan */

if (*offset>=CHUNKS_TOTAL)

{

*offset = -1;

}

}

5.4. Toteutusalustan toimintamalli

Diplomityön laitteistoksi valittiin Zolertian Z1 ja käyttöjärjestelmäksi Contiki OS. Tä-mä valinta perustui useiden mahdollisten laitteiden ja käyttöjärjestelmien yhdistelmienvertailuun. Alustoista mielenkiintoisin oli täysin valmis 6LowPAN tekniikalla varustet-tu Zolertia Z1. Siinä yhdistyvät tämän hetken vähävirtaiset, että nopeat verkkotekniikatsekä integroidut sensorit ja näiden tuomat sovellusmahdollisuudet. Contiki puolestaanon erittäin hyvin toimiva ja Z1:n ominaisuuksia tukeva käyttöjärjestelmä. Contikissaon paljon ratkaisuja vähävirtaiselle kokonaistoteutukselle ja täysi REST + CoAP tuki.Näiden varassa tutkittiin dynaamista verkon yli toteutettavaa perusratkaisua konfigu-roitavalle sensorisolmulle.

Perustavoite oli hyvin yksinkertainen: web-sovellus, reititin ja sensorisolmu (kuva13. ja 14.). Web-sovellus on selaimessa toimiva CoAP-agentti (Mozilla Firefoxin Cop-

47

per), reititin on IPv6-reititin RPL-periaatteella (Zolertia Z1) ja sensorisolmu (ZolertiaZ1), missä toimii REST-moottori CoAP-ominaisuuksilla.

Web-applikaatio Välipalvelin Reititin Sensorisolmu

GET coap://[ip_ipaddr]/

.well-known/core?rt=core.rd

2.05 Content "</rd>"; rt="core.rd"

POST coap://[rd_ipaddr]/rd?ep=

obj_ipaddr </temp>;rt=

"Temperature"

2.01 Created Location:

/rd/obj_ipaddrGET http://proxy_ipaddr/well-know/

core/coap://rd_ipaddr/rd-lookup/

res?rt=Temperature

200 OK

"<coap://obj_ipaddr/temp>";

rt="Temperature""

GET http://proxy_ipaddr/

.well-known/core/

coap://obj_ipaddr/temp

GET coap://[obj_ipaddr]/temp

2.05 Content "temp value"

200 OK "temp value"

GET coap://rd_ipaddr/rd-lookup/

res?rt=Temperature

2.05 Content

"<coap://[obj_ipaddr]/temp>;

rt="Temperature""

Aika

Kuva 13. IoT ja web-integraatio

Web-sovellus

REST / HTTP REST / CoAP

IPv4 / IPv6

IPv6

Kuva 14. Yhteensopivuus sekä skaalautuminen

5.4.1. CoAP-agentti

Selaimessa toimivan CoAP-agentin tehtävä tässä työssä on toimia rajapintana sen-sorisolmun toiminnallisuuksien ja käyttäjän välillä. Sen avulla pystytään tunnista-

48

maan resurssit (RESOURCEs) ja tätä kautta lähettämään sekä vastaanottamaan CoAP-viestejä. Dynaaminen_lataus_resurssi mahdollistaa tässä työssä täten käyttäjän halua-man ELF-tiedoston lähettämisen tietosisältöominaisuudella (payload) sensorisolmulleblockwise-menettelyn avustamana.

5.4.2. RPL-reititin

Reititin toimii rajapintana Internetille ja sensoriverkolle. Sen tehtävänä on löytää, tun-nistaa ja reitittää sen alla olevat sensorit, ja mahdollistaa resurssien käytön muulle In-ternetille (tässä tapauksessa päätelaitteen CoAP-agentille). Sen toimii REST/HTTP-periaatteella muulle Internetille ja sensoriverkolle REST/CoAP-toteutuksella.

5.4.3. Sensorisolmu

Z1-sensorisolmussa toimii dynaamista latausta varten suunniteltu ja toteutettu sovel-lus. Se perustuu kuuteen vaiheeseen:

• alustus; REST-moottori, flash-toiminnot sekä ELF-funktionaalisuudet,

• REST-resurssien aktivointi:

– lisätään resource_dynaaminen_lataus aktiivisten resurssien listaan sekä

– mahdollistetaan sen näkyvyys muille sovelluksille (aktivoidaan URL),

• dynaaminen_lataus_handler_resurssikäsittelijän toimintaan:

– paketille/tiedostolle määriteltyjen rajoitteiden tarkistaminen,

– PUT-metodin toiminnallisuus; ohjataan sekä tallennetaan ELF-tiedosto pus-kurin kautta ROM muistiin cfs-kirjaston avulla ja

– GET-metodin toiminnallisuus; pystytään tarkistamaan sekä varmistamaansaadun tiedoston oikeellisuus.

• tallennetun tiedoston lataaminen sensorisolmussa; loader-kirjaston avulla,

• dynaamisesti linkitetyn tiedoston ajaminen; automatisoidulla autostart_start-prosessi-komennolla ja

• loppuun tehtäviin viimeistelyihin avoimille tiedostokahvoille sekä koko proses-sille.

49

6. OHJELMATOTEUTUKSEN TESTAUS

Työn toteutusta suoritettiin kahdella Zolertia Z1-alustalla, joiden toiminnallisuuksiensuoritusta seurattiin Linux-terminaaliemulaattoreista. Yksi näistä solmuista toimi koh-delaitteena ja toinen reitittimenä. Copper toimii käyttäjän ja sensorisolmun rajapinta-na.

Sensoriin saadaan yhteys laittamalla Copper-agenttiin sensorisolmun URL:“coap://[aaaa::c30c:0000:0000:0cdc]:5683/”. Solmun funktionaalisuudet saadaan nä-kyviin “discover”-toiminnolla.

Aktivoidaan dynaaminen_lataus-resurssi ja tehdään tätä toteutusta varten vaadittavattoimenpiteet:

• valitaan “payload”-tiedostoksi ELF-tiedosto (hello_world.ce),

• tämän jälkeen otetaan käyttöön lisävalinnat (debug option);

– missä sisältötyypiksi valitaan large_update_ct,

– Block1:n viittaus asetetaan nollaksi ja automaattinen kierrätys päällä (au-to).

Tämän jälkeen, kun kaikki asetukset on määritelty oikein voidaan lähettää tiedos-to tallennettavaksi sensorisolmulle PUT-metodilla. Terminaaliemulaattoreista nähdääntoteutuksen suoritusta sensorisolmussa; joka paketin/lohkon (block) jälkeen ohjelmakirjoittaa ulosmenopuskuriin onnistuneesti flash-muistiin (ROM-muistiin) tallennetunbinäärin kirjaisinmuodon.

Solmulle saadaan onnistuneesti tallennettua 1140 kilotavun kokoinen ELF-tiedosto.Aktivoidaan ohjelmakoodista load_elf-funktio, mikä pitää sisällään loader-kirjaston

elfloader_load-funktion. Sen tarkoitus on linkittää eri muistiosiot vastaamaan Contikinomia, allokoida tietotyypeille tarkoitetusti joko RAM- tai ROM-muistia sekä käynnis-tää ladattu tiedosto prosessina.

Kun ohjelmaa yrittää kääntää, kääntäjä ilmoittaa, että RAM-muistissa ylivuotoja 2kilotavun verran. Ohjelmana toteutus ei siis näillä menettelyillä ole toimiva.

6.1. Testauksen jälkipyykki

Lähdin kuitenkin purkamaan muistivuoto-ongelmaa ilman sen suurempaa huolta, ettei-kö tämä olisi mahdollista. Kului viikkoja ja olin saanut vähennettyä omin avuin muis-tiylivuotoa noin 1,3 kilotavua 756 tavuun. Oli siis vieläkin paljon matkaa siihen, ettäsaisi ohjelman menemään kääntäjästä läpi. Ja se mitä koko ohjelman sulava toimintavaatii on vaikea tarkasti määrittää, mutta oman arvioni perusteella ainakaan 756 tavunvähennys ei tule olemaan vielä riittävä.

Kyselyistä huolimatta en ole saanut mitään vastausta Contiki-postituslistalta taik-ka Contikin kehitykseen osallistuneilta tekijöiltä. Ratkaisua etsiessäni törmäsin myösesimerkkiin missä periaatteessa on samankaltainen idea, mutta tässäkin oltiin tör-mätty muistiongelmiin, eikä jatkokehityksen toteutuksista ollut mainintaa. Huomasin

50

myös Zolertian kehityssivustolle tulleen ilmoituksen lähiaikoina tulevasta “over-the-air-programming” (verkon yli ohjelmointi), mikä luultavasti tulee ratkaisemaan myöstässä työssä havaitun ongelman.

Kävin vielä simuloinnin muodossa läpi alustoja, kuten MSP-EXP430F5438 ja Wis-mote. Näissä törmättiin käännösvaiheessa puolestaan ROM ylivuotoihin. Mielestäninämä eivät ole niin huolestuttavia kuin RAM ylivuoto ja asiaan syventymällä varmastiratkaistavissa.

Juuri näillä laitteilla ja tämän hetkisillä menettelyillä, että taidoilla ei ole mahdol-lista toteuttaa määrittelyä vastaavaa toteutusta. On kuitenkin selvää, että lähiaikoinakun, Zolertian tai Contikin puolelta saadaan enemmän tukea; tulee tämäkin ongelmaselviämään ohjelmistoratkaisulla.

Työn toteutuksessa törmättiin siis RAM-muistin vähyyteen. Tämä voidaan ohittaatekemällä laitteistoratkaisu eli lisäämällä RAM-muistia. Se voisi tarkoittaa spesifikaa-tioiden muokkaamista sellaiseen suuntaan missä seuraava Zolertia Z1 tarjoaa RAM-muistia 16 kilotavun verran. Käytännössä MSP430-F2617-mikrokontrollerin vaihta-mista uuteen, esimerkiksi MSP430-F543xA-sarjalaiseen; missä näitä muistiongelmiaei pitäisi ilmetä.

On kuitenkin selkeää, että dynaamisen latauksen tuomat toiminnallisuudet mahdol-listavat jo nyt aivan uudenlaisia sensoriverkkototeutuksia. Myös Internetin, älykkäidenasioiden ja esineiden yhdistäminen tulee olemaan enemmän ja enemmän arkipäivää.Tämän voi huomata myös vähävirtaisille alustoille suunnitelluista verkkotekniikoista,kuten 6LoWPAN ja CoAP. Näitä hyödyntämällä pystytään toteuttamaan laitteiden jaweb-palveluiden välille täysin IPv6-pohjainen yhteys.

6.1.1. Onko REST valmis yrityskäyttöön?

REST-rakenne mahdollistaa isompien web-palveluiden rakentamisen ja näiden omi-naisuudet kasvavat jatkuvasti. Tämä ei välttämättä riitä vakuuttamaan yritysten järjes-telmäarkkitehtejä RESTful-web-palveluiden toteutusmahdollisuuksista. Pautasso lis-taa kirjassaan RESTful ja WS-palveluiden välisiksi eroavaisuuksiksi; turvallisuuden,viestien luotettavuuden ja osapuolten väliset interaktiot. Jotta RESTful-web-palveluillaolisi mahdollisuus toimia rakenteena yrityskäytössä, sen täytyy pystyä tukemaan näitäsille ominaisia vajavaisuuksia tulevaisuudessa. [102]

Viestikerroksen turvallisuudelle riittää HTTPS:n käyttö [32]. Mutta muille moni-mutkaisemmille ominaisuuksille, kuten signeeraus, salaus, taikka antaa lupa kolman-nelle osapuolelle tietokantaan ei voida toteuttaa pelkästään HTTP:tä käyttämällä [32].Tämä tarvitsee vielä paljon tutkimusta, jotta tällaista voidaan hyvällä omatunnollaimplementoida isompiin kokonaisuuksiin [32]. Tämän päivän rakenteet eivät ole vielävalmiita tukemaan yrityskäytön tarpeita, koska niissä ei ole kehittyneitä turvallisuuso-minaisuuksia. [76]

51

7. YHTEENVETO

Työn tarkoituksena oli suunnitella dynaamista konfiguraatiota mukaileva ratkaisu lan-gattomalle sensorisolmulle (Zolertia Z1) REST-arkkitehtuuria hyödyntäen. Tavoittee-na oli lähettää sensorisolmulle uudelleen konfiguraatiota varten tarvittava ELF-tiedostokäyttäen HTTP/(REST + CoAP) verkkotekniikoita.

Työssä esiteltiin vähävirtaisille langattomille laitteille kohdennettuja protokolleja,kuten µIP ja 6LoWPAN. Käytiin läpi Internetin tulevaisuutta sekä sitä millä tavalla setulee kehittymään ja laajentumaan.

Käytiin yksityiskohtaisesti läpi mitä ovat sensorit ja sensoriverkot. Mitä näihin fyysi-sesti kuuluu ja mitä näillä voidaan tehdä. Sekä esiteltiin sensoriverkkoja silmällä pitäenolennaisimmat protokollat sekä tekniikat. Työn kannalta tärkeimmät luvut käsittelevätREST-arkkitehtuuria. Näissä käydään läpi REST:n vahvuuksia, käyttömahdollisuuk-sia, toteutuksia sekä paneudutaan tulevaisuuden näkymiin.

Contiki-käyttöjärjestelmä oli isossa roolissa. Työssä käytiin siten hyvin yksityiskoh-taisesti läpi Contikiin kuuluvat eri ominaisuudet verkko-, reititys- ja toteutustasolla.Erityistä huomioita käytettiin kuvatessa Contikille ominaisia prosessi- ja protothread-toteutuksia.

Käytiin myös yleisellä tasolla läpi miten sensoriverkkojen web-palvelut toteutuvat,sekä tutkittiin onko näille jotain tiettyä yhteistä kehityksen suuntaa.

Ohjelmatoteutus käytiin vaihe vaiheelta läpi. Sitä ennen kuitenkin esiteltiin erilaisiatoteutusvaihtoehtoja dynaamiselle konfiguraatiolle/lataukselle. Tutustuttiin tarkemmintässä työssä käytettyihin Contikin omiin toteutuksiin sekä esiteltiin tärkeimpiä perus-ratkaisuja verkkoviestityksen, web-resurssin ja toteutuksen kannalta.

Viimeistä edeltävässä luvussa toteutettiin järjestelmällinen testaus, missä lopuksijouduttiin toteamaan, että sensorisolmun resurssit eivät riitä tässä työssä määritellyn to-teutuksen saavuttamiseen. Tämän jälkeen käytiin läpi ratkaisuvaihtoehdot resurssion-gelmaan, sekä pohdittiin missä ja miten REST:iä tullaan näkemään tulevaisuudessa.

52

8. LÄHTEET

[1] Laffea L., Monson R., Han R., Manning R., Glasser A., Oncley S., Sun J., BurnsS., Semmer S. & Militzer J. (2006) Comprehensive monitoring of co 2 seque-stration in subalpine forest ecosystems and its relation to global warming. In:Proceedings of the 4th international conference on Embedded networked sensorsystems, ACM, pp. 423–424.

[2] Vasseur J.P. & Dunkels A. (2010) Interconnecting smart objects with ip: Thenext internet. Morgan Kaufmann.

[3] Singhvi V., Krause A., Guestrin C., Garrett Jr J.H. & Matthews H.S. (2005) In-telligent light control using sensor networks. In: Proceedings of the 3rd interna-tional conference on Embedded networked sensor systems, ACM, pp. 218–229.

[4] Juang P., Oki H., Wang Y., Martonosi M., Peh L.S. & Rubenstein D. (2002)Energy-efficient computing for wildlife tracking: Design tradeoffs and early ex-periences with zebranet. In: ACM Sigplan Notices, vol. 37, ACM, vol. 37, pp.96–107.

[5] Mainwaring A., Culler D., Polastre J., Szewczyk R. & Anderson J. (2002) Wi-reless sensor networks for habitat monitoring. In: Proceedings of the 1st ACMinternational workshop on Wireless sensor networks and applications, ACM, pp.88–97.

[6] Kroc S. & Delic V. (2003) Personal wireless sensor network for mobilehealth care monitoring. In: Telecommunications in Modern Satellite, Cable andBroadcasting Service, 2003. TELSIKS 2003. 6th International Conference on,vol. 2, IEEE, vol. 2, pp. 471–474.

[7] Fielding R.T. (2000) Architectural styles and the design of network-basedsoftware architectures. Ph.D. thesis, University of California.

[8] Wilde E. & Pautasso C. (2011) REST: from research to practice. Springer.

[9] Romero D., Hermosillo G., Taherkordi A., Nzekwa R., Rouvoy R. & Eliassen F.(2010) Restful integration of heterogeneous devices in pervasive environments.In: Distributed Applications and Interoperable Systems, Springer, pp. 1–14.

[10] Guinard D., Trifa V. & Wilde E. (2010) A resource oriented architecture for theweb of things. In: Internet of Things (IOT), 2010, IEEE, pp. 1–8.

[11] Bose S. & Liu R. (2011) Cloud computing complements wireless sensornetworks to connect the physical world. IQ Magazine 10, pp. 10–11.

[12] Dunkels A. et al. (2009) Efficient application integration in ip-based sensornetworks. In: Proceedings of the First ACM Workshop on Embedded SensingSystems for Energy-Efficiency in Buildings, ACM, pp. 43–48.

53

[13] da Silva A.P.R., Martins M.H., Rocha B.P., Loureiro A.A., Ruiz L.B. & WongH.C. (2005) Decentralized intrusion detection in wireless sensor networks. In:Proceedings of the 1st ACM international workshop on Quality of service &security in wireless and mobile networks, ACM, pp. 16–23.

[14] Yazar D. (2009) Restful wireless sensor networks. Ph.D. thesis, Master’s thesis,Uppsala University.

[15] Liang C.J.M., Terzis A. et al. (2008) Koala: Ultra-low power data retrieval inwireless sensor networks. In: Proceedings of the 7th international conference onInformation processing in sensor networks, IEEE Computer Society, pp. 421–432.

[16] Buettner M., Yee G.V., Anderson E. & Han R. (2006) X-mac: a short preamblemac protocol for duty-cycled wireless sensor networks. In: Proceedings of the4th international conference on Embedded networked sensor systems, ACM, pp.307–320.

[17] Shih B.Y., Chen C.Y., Shih C.H. & Tseng J.Y. (2010) The development of en-hancing mechanisms for improving the performance of ieee 802.15. 4. Interna-tional Journal of the Physical Sciences 5, pp. 884–897.

[18] Hui J. & Thubert P. (2011) Compression format for ipv6 datagrams over ieee802.15. 4-based networks .

[19] Deering S.E. (1998) Internet protocol, version 6 (ipv6) specification .

[20] Reynders D. & Wright E. (2003) Practical TCP/IP and Ethernet networking.Access Online via Elsevier.

[21] Shelby Z. & Bormann C. (2011) 6LoWPAN: The wireless embedded Internet,vol. 43. Wiley. com.

[22] Openid (käyty: 11.03.2014). URL: http://en.wikipedia.org/wiki/UIP_%28micro_IP%29.

[23] Newswire P. (2008) Cisco, atmel and the swedish institute of computer science(sics) collaborate to support a future where any device can be connected to theinternet) .

[24] Durvy M., Abeillé J., Wetterwald P., O’Flynn C., Leverett B., Gnoske E., Vida-les M., Mulligan G., Tsiftes N., Finne N. et al. (2008) Making sensor networksipv6 ready. In: Proceedings of the 6th ACM conference on Embedded networksensor systems, ACM, pp. 421–422.

[25] Colitti W., Steenhaut K. & De Caro N. (2011) Integrating wireless sen-sor networks with the web. Extending the Internet to Low powerand LossyNetworks (IP+ SN 2011) .

[26] Btnode platform (käyty: 08.11.2013). URL: http://www.btnode.ethz.ch/.

54

[27] Linux lite - linux lite free operating system (käyty: 08.11.2013). URL: https://www.linuxliteos.com/.

[28] Colitti W., Steenhaut K., De Caro N., Buta B. & Dobrota V. (2011) Rest enabledwireless sensor networks for seamless integration with web applications. In:Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Con-ference on, IEEE, pp. 867–872.

[29] Wsn platforms (käyty: 21.10.2013). URL: http://wsn.oversigma.

com/wiki/index.php?title=WSN_Platforms.

[30] Zolertia z1 (käyty: 19.04.2014). URL: http://zolertia.com/sites/default/files/Zolertia-Z1-Brochure.pdf.

[31] Masinter L., Berners-Lee T. & Fielding R.T. (2005) Uniform resource identifier(uri): Generic syntax .

[32] Richardson L. & Ruby S. (2008) RESTful web services. O’Reilly.

[33] Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P. & Berners-Lee T. (1999), Hypertext transfer protocol–http/1.1.

[34] Steiner T. & Algermissen J. (2011) Fulfilling the hypermedia constraint via httpoptions, the http vocabulary in rdf, and link headers. In: Proceedings of thesecond international workshop on RESTful design, ACM, pp. 11–14.

[35] Richardson maturity model (käyty: 06.11.2013). URL: http:

//martinfowler.com/articles/richardsonMaturityModel.

html.

[36] Maleshkova M., Pedrinaci C. & Domingue J. (2010) Investigating web apis onthe world wide web. In: Web Services (ECOWS), 2010 IEEE 8th EuropeanConference on, IEEE, pp. 107–114.

[37] Shelby Z., Hartke K. & Bormann C. (2013) Constrained application protocol(coap) .

[38] Dunkels A., Gronvall B. & Voigt T. (2004) Contiki-a lightweight and flexibleoperating system for tiny networked sensors. In: Local Computer Networks,2004. 29th Annual IEEE International Conference on, IEEE, pp. 455–462.

[39] Dunkels A., Österlind F. & He Z. (2007) An adaptive communication archi-tecture for wireless sensor networks. In: Proceedings of the 5th internationalconference on Embedded networked sensor systems, ACM, pp. 335–349.

[40] Boano C.A., Voigt T., Tsiftes N., Mottola L., Römer K. & Zúñiga M.A. (2010)Making sensornet mac protocols robust against interference. In: Wireless SensorNetworks, Springer, pp. 272–288.

[41] Dunkels A. (2003) Full tcp/ip for 8-bit architectures. In: Proceedings of the 1stinternational conference on Mobile systems, applications and services, ACM,pp. 85–98.

55

[42] Dunkels A., Finne N., Eriksson J. & Voigt T. (2006) Run-time dynamic linkingfor reprogramming wireless sensor networks. In: Proceedings of the 4th inter-national conference on Embedded networked sensor systems, ACM, pp. 15–28.

[43] Dunkels A., Schmidt O., Voigt T. & Ali M. (2006) Protothreads: simpli-fying event-driven programming of memory-constrained embedded systems. In:Proceedings of the 4th international conference on Embedded networked sensorsystems, Acm, pp. 29–42.

[44] Kovatsch M., Duquennoy S. & Dunkels A. (2011) A low-power coap for contiki.In: Proceedings of the 8th IEEE International Conference on Mobile Ad-hoc andSensor Systems (MASS 2011), Valencia, Spain.

[45] Ko J., Eriksson J., Tsiftes N., Dawson-haggerty S., Durvy M., Terzis A., Dun-kels A. & Culler D. (2011) Beyond interoperability: Pushing the performanceof sensornet ip stacks. In: In Proceedings of the International Conference onEmbedded Networked Sensor Systems (ACM SenSys, Citeseer.

[46] Romkey J. (1988) Nonstandard for transmission of ip datagrams over serial li-nes: Slip .

[47] Feeney L.M. & Nilsson M. (2001) Investigating the energy consumption of a wi-reless network interface in an ad hoc networking environment. In: INFOCOM2001. Twentieth Annual Joint Conference of the IEEE Computer and Commu-nications Societies. Proceedings. IEEE, vol. 3, IEEE, vol. 3, pp. 1548–1557.

[48] Shih E., Bahl P. & Sinclair M.J. (2002) Wake on wireless: an event driven energysaving strategy for battery operated devices. In: Proceedings of the 8th annualinternational conference on Mobile computing and networking, ACM, pp. 160–171.

[49] Dunkels A. (2011) The contikimac radio duty cycling protocol .

[50] Polastre J., Hill J. & Culler D. (2004) Versatile low power media access forwireless sensor networks. In: Proceedings of the 2nd international conferenceon Embedded networked sensor systems, ACM, pp. 95–107.

[51] Moss D. & Levis P. (2008) Box-macs: Exploiting physical and link layer boun-daries in low-power networking. Computer Systems Laboratory Stanford Uni-versity .

[52] El-Hoiydi A., Decotignie J.D., Enz C. & Le Roux E. (2003) Wisemac, an ultralow power mac protocol for the wisenet wireless sensor network. In: Procee-dings of the 1st international conference on Embedded networked sensor sys-tems, ACM, pp. 302–303.

[53] Hui J.W. & Culler D.E. (2008) Ip is dead, long live ip for wireless sensornetworks. In: Proceedings of the 6th ACM conference on Embedded networksensor systems, ACM, pp. 15–28.

56

[54] Get started with contiki (käyty: 24.10.2013). URL: http://wsn.

oversigma.com/wiki/index.php?title=WSN_Platforms.

[55] Landsiedel O. (2010), Tinyos and cooja.

[56] Alonso G., Casati F., Kuno H. & Machiraju V. (2004) Web services. Springer.

[57] Hamad H., Saad M. & Abed R. (2010) Performance evaluation of restful webservices for mobile devices. Int. Arab J. e-Technol. 1, pp. 72–78.

[58] Berger S., McFaddin S., Narayanaswami C. & Raghunath M. (2003) Web ser-vices on mobile devices-implementation and experience. In: Mobile ComputingSystems and Applications, 2003. Proceedings. Fifth IEEE Workshop on, IEEE,pp. 100–109.

[59] Cheng S.T., Liu J.P., Kao J.L. & Chen C.M. (2002) A new framework for mo-bile web services. In: Applications and the Internet (SAINT) Workshops, 2002.Proceedings. 2002 Symposium on, IEEE, pp. 218–222.

[60] Sosnoski D. (2004) Improve xml transport performance part 1 and 2.IBM developersWork Article, June 2004. http://www-128. ibm. com/develo-perworks/xml/library/xtrans1. html .

[61] Xbis xml information set encoding (käyty: 28.10.2013). URL: http://

xbis.sourceforge.net/.

[62] Xmlbeans (käyty: 28.10.2013). URL: http://xmlbeans.apache.org/.

[63] Tian M., Voigt T., Naumowicz T., Ritter H. & Schiller J. (2004) Performanceconsiderations for mobile web services. Computer communications 27, pp.1097–1105.

[64] Paoli J., Sperberg-McQueen C., Yergeau F., Maler E. & Bray T. (2004) Exten-sible markup language (xml) 1.0. W3C recommendation .

[65] Crockford D. (2006) The application/json media type for javascript object nota-tion (json) .

[66] Hadley M., Mendelsohn N., Moreau J., Nielsen H. & Gudgin M. (2003)Soap version 1.2 part 1: Messaging framework. W3C REC REC-soap12-part1-20030624, June , pp. 240–8491.

[67] Chinnici R., Moreau J.J., Ryman A. & Weerawarana S. (2007) Web servicesdescription language (wsdl) version 2.0 part 1: Core language. W3C Recom-mendation 26.

[68] Uddi oasis standard (käyty: 28.10.2013). URL: http://uddi.xml.org/.

[69] Hinchcliffe D. (2008) What is woa? it’s the future of service-oriented architectu-re (soa). Dion Hinchcliffe’s Blog–Musings and Ruminations on Building GreatSystems .

57

[70] Fernandez F. & Navón J. (2010) Towards a practical model to facilitate reaso-ning about rest extensions and reuse. In: Proceedings of the First InternationalWorkshop on RESTful Design, ACM, pp. 31–38.

[71] Woa: Putting the web back in web services (käyty: 08.11.2013).URL: http://blogs.gartner.com/nick_gall/2008/

11/19/woa-putting-the-web-back-in-web-services/

.

[72] Hadley M.J. (2006) Web application description language (wadl) .

[73] Alarcón R. & Wilde E. (2010) Restler: crawling restful services. In: Proceedingsof the 19th international conference on World wide web, ACM, pp. 1051–1052.

[74] Pautasso C. & Wilde E. (2009) Why is the web loosely coupled?: a multi-facetedmetric for service design. In: Proceedings of the 18th international conferenceon World wide web, ACM, pp. 911–920.

[75] Alarcon R. & Wilde E. (2010) From restful services to rdf: Connecting the weband the semantic web. arXiv preprint arXiv:1006.2718 .

[76] Adamczyk P., Hafiz M. & Johnson R.E. Non-compliant and proud: A case studyof http compliance. Urbana 51, pp. 61801–2302.

[77] Duska B.M., Marwood D. & Feeley M.J. (1997) The measured access charac-teristics of world-wide-web client proxy caches. In: USENIX Symposium onInternet Technologies and Systems, vol. 997, vol. 997.

[78] Http status report. M. Nottingham, In QCon, Apr. 2009.

[79] Cool uris don’t change (käyty: 14.11.2013). URL: http://www.w3.org/Provider/Style/URI.html.en.

[80] Lawrence K., Kaler C., Nadalin A., Monzillo R. & Hallam-Baker P. (2006) Webservices security: Soap message security 1.1 (ws-security 2004). OASIS, OASISStandard, Feb .

[81] Rescorla E. (2000) Http over tls .

[82] Amazon simple storage service: Api reference (käyty: 15.11.2013). URL:http://awsdocs.s3.amazonaws.com/S3/latest/s3-api.pdf.

[83] Openid (käyty: 15.11.2013). URL: http://openid.net.

[84] Hammer-Lahav E. (2010) The oauth 1.0 protocol .

[85] Estrin D. (2001) Embedded everywhere: A research agenda for networked sys-tems of embedded computers. National Academy Press.

[86] G. Mainland L. Kang S.L.D.C.P. & Welsh M. (2004) Wireless sensor networksfor habitat monitoring. In: Using virtual markets to program global behavior insensor networks, SIGOPS.

58

[87] Hui J.W. & Culler D. (2004) The dynamic behavior of a data dissemination pro-tocol for network programming at scale. In: Proceedings of the 2nd internationalconference on Embedded networked sensor systems, ACM, pp. 81–94.

[88] Tsiftes N., Dunkels A. & Voigt T. (2008) Efficient sensor network reprogram-ming through compression of executable modules. In: Sensor, Mesh and Ad HocCommunications and Networks, 2008. SECON’08. 5th Annual IEEE Commu-nications Society Conference on, IEEE, pp. 359–367.

[89] Jeong J. & Culler D. (2004) Incremental network programming for wirelesssensors. In: Sensor and Ad Hoc Communications and Networks, 2004. IEEESECON 2004. 2004 First Annual IEEE Communications Society Conferenceon, IEEE, pp. 25–33.

[90] Reijers N. & Langendoen K. (2003) Efficient code distribution in wireless sen-sor networks. In: Proceedings of the 2nd ACM international conference on Wi-reless sensor networks and applications, ACM, pp. 60–67.

[91] Koshy J. & Pandey R. (2005) Vmstar: synthesizing scalable runtime environ-ments for sensor networks. In: Proceedings of the 3rd international conferenceon Embedded networked sensor systems, ACM, pp. 243–254.

[92] Levis P. & Culler D. (2002) Maté: A tiny virtual machine for sensor networks.In: ACM Sigplan Notices, vol. 37, ACM, vol. 37, pp. 85–95.

[93] Levis P., Gay D. & Culler D. (2005) Active sensor networks. In: Procee-dings of the 2nd conference on Symposium on Networked Systems Design &Implementation-Volume 2, USENIX Association, pp. 343–356.

[94] Boulis A., Han C.C. & Srivastava M.B. (2003) Design and implementation of aframework for efficient and programmable sensor networks. In: Proceedings ofthe 1st international conference on Mobile systems, applications and services,ACM, pp. 187–200.

[95] Koshy J. & Pandey R. (2005) Synthesizing scalable runtime environments forsensor networks. In: Proceedings of the Third International Conference on Em-bedded Networked Sensor Systems (SenSys), pp. 243–254.

[96] Liu H., Roeder T., Walsh K., Barr R. & Sirer E.G. (2005) Design and imple-mentation of a single system image operating system for ad hoc networks. In:Proceedings of the 3rd international conference on Mobile systems, applica-tions, and services, ACM, pp. 149–162.

[97] Hill J., Szewczyk R., Woo A., Hollar S., Culler D. & Pister K. (2000) Systemarchitecture directions for networked sensors. In: ACM SIGOPS operating sys-tems review, vol. 34, ACM, vol. 34, pp. 93–104.

[98] Schiller J., Liers A., Ritter H., Winter R. & Voigt T. (2005) Scatterweb-lowpower sensor nodes and energy aware routing. In: System Sciences, 2005.HICSS’05. Proceedings of the 38th Annual Hawaii International Conferenceon, IEEE, pp. 286c–286c.

59

[99] Koshy J. & Pandey R. (2005) Remote incremental linking for energy-efficientreprogramming of sensor networks. In: Wireless Sensor Networks, 2005.Proceeedings of the Second European Workshop on, IEEE, pp. 354–365.

[100] Committee T. (1995) Tool interface standard (tis) executable and linking format(elf) specification version 1.2. TIS Committee.

[101] The dynamic loader (käyty: 21.04.2014). URL: https://github.com/contiki-os/contiki/wiki/The-dynamic-loader.

[102] Pautasso C., Zimmermann O. & Leymann F. (2008) Restful web services vs.big’web services: making the right architectural decision. In: Proceedings of the17th international conference on World Wide Web, ACM, pp. 805–814.