SpotSim: Test gedreven ontwikkeling van sensornetwerk applicaties

SpotSim: Test gedreven ontwikkeling van sensornetwerk applicaties Nick Dijkshoorn ([email protected]) 17 augustus 2009 (herziene versie)

Bachelor Thesis: Bachelor of Computer Science Supervisors: Rudolf J. Strijkers, Robert J. Meijer, Dick van Albada Signed:

Samenvatting Deze scriptie is een studie naar het test gedreven ontwikkelen van sensornetwerk applicaties. Er wordt verkend wat test gedreven ontwikkeling inhoudt en hoe deze techniek kan worden gebruikt om de kwaliteit van sensornetwerk applicaties te verbeteren. Daarvoor worden een aantal test methodieken onder de loep genomen, zoals JUnit en simulatie. Daarnaast beschrijft deze scriptie een Java framework dat test gedreven ontwikkeling van sensornetwerk applicaties voor de Sun SPOT omgeving mogelijk maakt.

Inhoudsopgave 1 Introductie 1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Test gedreven ontwikkeling 2.1 Test gedreven ontwikkeling . . . . . . . . . . . . 2.1.1 Cyclus . . . . . . . . . . . . . . . . . . . . 2.1.2 Soorten testen . . . . . . . . . . . . . . . 2.2 Test gedreven ontwikkeling voor sensornetwerken 2.2.1 State of the art sensornetwerk simulators 3 Sun 3.1 3.2 3.3

3 5 5

. . . . .

7 8 8 9 10 10

SPOT Functionaliteiten van Solarium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architectuur van Solarium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solarium designkeuzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 12 13 14

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4 SpotSim simulator voor Sun SPOT 4.1 Gewenste functionaliteiten . . . . . . . . . . . . . . . . . . 4.2 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Implementatie van het framework . . . . . . . . . . . . . . 4.4 Problemen en oplossingen . . . . . . . . . . . . . . . . . . 4.4.1 Bug in de multihop code van de SPOT bibliotheek 4.4.2 Initialisatietijd per SPOT . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

16 16 16 19 22 22 23

5 SpotSim toepassingen 5.1 Sun SPOT in het onderwijs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Implementeren van proofs of concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 SPOT Bounce demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 26 27 27

6 Kwantitatieve analyse 6.1 Resource gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Communicatievertragingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 30 32

7 Toekomstig werk

35

8 Conclusie

37

Bijlagen:

38

Lijst met afkortingen

40

A SPOT Bounce demo code

41

B E-mail van de Universiteit van Antwerpen

45

2

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3

1 Introductie Draadloze sensornetwerken (WSN) is een zeer boeiend en snel evoluerend onderzoeksdomein. Door sensoren te voorzien van reken- en communicatiemogelijkheden, wordt het mogelijk om de reële wereld te koppelen aan een computersysteem. De nuttige toepassingen zijn legio, bijvoorbeeld het monitoren van fysieke- of omgevingsfactoren. Draadloze sensornetwerken worden ge¨ıntegreerd in de bestaande computerinfrastructuur om eindgebruikerapplicaties mogelijk te maken. Deze applicaties communiceren met de software op één of meerdere sensornetwerken om gebruik te maken van de diensten die de sensornetwerken aanbieden. Een draadloos sensornetwerk bestaat uit ruimtelijk verspreide autonome apparaatjes (sensorknopen) die zijn voorzien van sensoren. De grootte van deze apparaten kan variëren van die van een zandkorrel tot die van een schoenendoos. Het aantal sensorknopen in een draadloos sensornetwerk kan gaan van enkele apparaatjes tot enkele duizenden.

Figuur 1.1: ”Monitoring Volcanic Eruptions with a Wireless Sensor Network”[3] Voorbeeld van een sensornetwerk dat de activiteiten van een vulkaan in de gaten houdt. Elke sensorknoop meet seismische activiteiten en stuurt de meetresultaten door naar het basisstation waar de metingen door een computer worden verwerkt.

Het programmeren van sensornetwerken is met de huidige staat van ontwikkeling een uitdagende taak [1]. De eigenschappen van sensornetwerken staan loodrecht tegenover de aannames van het internet. Traditionele netwerk concepten en technologieën zijn daarom niet toepasbaar op sensornetwerken. Enkele uitdagingen van sensornetwerken zijn:

• Beperkte rekenkracht en geheugencapaciteit. • Dynamische netwerktopologie (uitval of verplaatsing van knopen). 4

• Intermitterende connectiviteit: er is niet altijd een eind-naar-eind route. • Lange of variabele vertragingen. • Hoge error-rates. • Grote schaal (een sensornetwerk kan uit veel knopen bestaan). Algoritmen moeten ondanks de schaal toch efficiënt kunnen functioneren.

Tijdens de ontwikkeling van sensornetwerk applicaties kan test gedreven ontwikkeling (TDD) helpen om de kwaliteit van de sensornetwerk applicatie te verbeteren [2]. Door een sensornetwerk te simuleren kunnen specifieke testen op de programmatuur worden uitgevoerd. Een simulator kan bijvoorbeeld extreme omgevingen nabootsen waarin sensornetwerken worden toegepast. Denk hierbij aan omgevingen als dijken, bergen en militaire operaties. Door deze situaties na te bootsen kan een sensornetwerk applicatie grondig worden getest.

1.1 Probleemstelling Aan de Universiteit van Amsterdam wordt onderzoek gedaan op het gebied van sensornetwerken met behulp van Sun SPOT [4] (Sun Small Programmable Object Technology), een draadloze sensornetwerk platform ontwikkeld bij Sun Microsystems. De Universiteit van Amsterdam heeft voor dit platform gekozen omdat het de mogelijkheid biedt om het netwerk te programmeren. Hierdoor is het bijvoorbeeld mogelijk om met behulp van Sun SPOT onderzoek te doen naar het UPVN concept [12], waarbij een applicatie het netwerk programmeert. Sun heeft voor het Sun SPOT platform ook een emulator met de naam Solarium ontwikkeld om SPOT applicaties op een desktop computer te kunnen draaien. Hierdoor is het mogelijk om SPOT applicaties eenvoudig te testen zonder de hardware zelf of scenario’s te testen die in de echte wereld lastig zijn te beheersen. De mogelijkheden van Solarium zijn echter te beperkt om SPOT applicaties op realistische wijze mee te testen. Het nabootsen van realistische scenario’s vereist een hoop handelingen en is te complex om handmatig uit te voeren. Momenteel is het met Solarium alleen mogelijk om handmatig virtuele SPOTs te instantiëren, te configureren en sensorwaarden in te voeren. Daardoor is Solarium niet in staat om realistische scenario’s na te bootsen. Verder is de communicatie tussen virtuele SPOTs beperkt tot single-hop: alle virtuele SPOTs kunnen met elkaar communiceren en kennen geen (dynamische) netwerktopologie. Dit terwijl een dynamische netwerktopologie juist een prominent kenmerk is van sensornetwerken. Multihop communicatieprotocollen vormen daarom een belangrijk onderzoeksgebied van sensornetwerken, maar kunnen niet worden getest met Solarium. De simulatiemogelijkheden voor het SPOT platform zijn dus te beperkt om SPOT applicaties op test gedreven wijze te ontwikkelen.

1.2 Doelstellingen Het doel van dit onderzoek is om een simulatie framework voor het Sun SPOT platform te ontwikkelen. Met behulp van dit framework kunnen de sensoren vanuit een applicatie worden geprogrammeerd en wordt multihop communicatie mogelijk gemaakt. Het framework zorgt ervoor 5

dat de tekortkomingen van Solarium worden opgeheven waardoor het mogelijk wordt om het Sun SPOT platform te gebruiken voor test gedreven ontwikkeling van sensornetwerk applicaties. Multihop communicatieprotocollen zijn hierin een belangrijk test onderdeel. Bij het ontwikkelen van een software architectuur moet er rekening worden gehouden met het eenvoudig kunnen uitbreiden en implementeren van nieuwe functionaliteiten.

6

7

2 Test gedreven ontwikkeling 2.1 Test gedreven ontwikkeling Test gedreven ontwikkeling (TDD) is een software ontwikkeling techniek waarbij software wordt ontwikkeld door het schrijven van testen. Dit leidt tot een hogere productiviteit en kwaliteit [5]. De techniek maakt gebruik van korte ontwikkel-iteraties die zijn gebaseerd op vooraf geschreven testen. Deze testen definiëren nieuwe functionaliteiten of gewenste verbeteringen. Elke iteratie produceert de code die nodig is om de testen van die iteratie te laten slagen. Uiteindelijk herstructureert de programmeur de code zonder de werking ervan te veranderen. Een belangrijk TDD sleutelconcept is dat de testen worden opgesteld voordat de code wordt geschreven. Hierdoor wordt er tijdens het schrijven van de programmacode al feedback verkregen.

2.1.1 Cyclus

Test(en) toevoegen

Testen uitvoeren

Kleine aanpassing

Testen uitvoeren

Code opschonen

ontwikkeling gaat verder

Figuur 2.1: Schematische weergave van de Test Gedreven Ontwikkeling cyclus.

1. Test(en) toevoegen In test gedreven ontwikkeling begint elke nieuwe functionaliteit met het schrijven van een test. Elke nieuwe test moet in het begin falen omdat die is geschreven voordat de functionaliteit is ge¨ımplementeerd. Om een test te schrijven moet de ontwikkelaar de specificaties en eisen van de te ontwikkelen software goed begrijpen. 2. Alle testen uitvoeren en controleer of nieuwe testen falen Deze stap valideert of de testen correct werken en of nieuwe testen falen. Nieuwe testen moeten namelijk falen zolang er nog geen nieuwe code is geschreven, er is immers nog geen code om de test te laten slagen. 3. Code schrijven In deze stap wordt nieuwe code geschreven met als doel de test te laten slagen. De nieuwe code hoeft in deze stap nog niet perfect te zijn, zolang de test maar slaagt. Dit is acceptabel omdat de code later wordt opgeschoond. Het is wel belangrijk dat de nieuwe code alleen als doel heeft om de test te laten slagen. Verdere (en niet-geteste) functionaliteiten mogen niet worden voorspeld en zijn dus niet toegestaan. 8

4. Voer het geautomatiseerd testen uit en controleer of alle testen slagen Als alle testen slagen is de programmeur verzekerd dat de code aan de geteste eisen voldoet. 5. Code opschonen Nu kan de code worden opgeschoond. Door de testen opnieuw uit te voeren is de ontwikkelaar verzekerd dat het opschonen van de code geen functionaliteiten heeft beschadigd. Het verwijderen van duplicaties is een belangrijk aspect van software design. In dit geval is dit ook van toepassing op het verwijderen van duplicaties tussen de testcode en de programmacode. 6. Herhalen De gehele cyclus kan worden herhaald om nieuwe functionaliteiten toe te voegen.

2.1.2 Soorten testen Test gedreven ontwikkeling kan worden onderverdeeld in verschillende soorten testen. Elke soort test wordt in een bepaalde fase van het ontwikkelproces toegepast.

1. Unittesten Een zeer belangrijk onderdeel van test gedreven ontwikkeling is het schrijven van Unit Testen, ook wel unittesten genoemd. Unittesten is een methode om softwaremodulen of kleine stukjes code (units) afzonderlijk te testen op een correcte werking. Bij unittesten zal voor iedere unit een test ontwikkeld worden, een unittest. Deze testen bevatten beweringen (assertions) die waar of onwaar zijn. De Unit Testen worden geautomatiseerd uitgevoerd en blijven gedurende het hele ontwikkelproces bestaan. Dit betekent dat na aanpassingen van de code alle testen nog moeten werken. Doordat alle testen iedere keer worden uitgevoerd, worden functionele wijzigingen direct opgemerkt. Om Unit Testen te definiëren en op geautomatiseerd wijze uit te voeren is een zogenaamd xUnit framework vereist. Er zijn verscheidene xUnit frameworks beschikbaar waarbij elk framework op een specifieke programmeertaal is gericht. Op Wikipedia is een uitgebreide lijst met deze frameworks te vinden [6]. 2. Integratietesten Na het unittesten volgt het integratietesten. Daarbij worden individuele softwarecomponenten tot een groep gecombineerd en getest. Het doel van integratietesten is om te controleren of aan de functionele, prestatie en betrouwbaarheidseisen van de groepen wordt voldaan. De testen zijn zo geconstrueerd dat kan worden bepaald of alle componenten binnen de groep op de juiste wijze met elkaar interacteren. Via de interfaces worden passende parameters en invoerdata aan de groepen aangeboden. 3. Systeemtesten Na het integratietesten volgt het systeemtesten. De groepen van de integratietesten worden gecombineerd tot een geheel systeem en vervolgens als geheel getest. Daarbij wordt getest op gebreken tussen zowel gekoppelde groepen alsmede het gehele systeem. Systeemtesten worden door middel van blackboxtesten getest. Voor deze testmethode is geen kennis van het design of de onderliggende code vereist. 4. Systeem integratietesten Na het uitvoeren van systeemtesten kunnen systeem integratietesten worden uitgevoerd. Daarbij wordt getest of meerdere ge¨ıntegreerde systemen op juiste wijze samenwerken. 9

2.2 Test gedreven ontwikkeling voor sensornetwerken Test gedreven ontwikkeling kan ook voor de ontwikkeling van sensornetwerk applicaties worden toegepast. De eigenschappen van sensornetwerken zorgen er voor dat het testen van sensornetwerk applicaties complexer is dan het testen van reguliere applicaties. De beperkte hulpbronnen van sensorknopen zorgen ervoor dat reguliere programmeertalen en modellen slecht bruikbaar zijn voor sensornetwerken. Daarom zijn er nieuwe programmeertalen en modellen specifiek voor sensornetwerken ontwikkeld. De reguliere xUnit test frameworks zijn daarom onbruikbaar voor de meeste sensornetwerken. Daarnaast speelt de interactie tussen sensorknopen een belangrijke rol binnen sensornetwerken. Om het gedrag van een sensornetwerk applicatie te testen is het juist belangrijk om de interactie tussen sensorknopen te testen. De meest gebruikte testplatformen voor de ontwikkeling van sensornetwerken zijn daarom sensornetwerk simulators en sensornetwerk testbedden. Het gebruik van een echte sensornetwerk testbed biedt de meest realistische testomgeving waardoor er nauwkeurige testresultaten kunnen worden verzameld. Er kleven echter twee serieuze beperkingen aan deze aanpak. Ten eerste brengt de grote schaal van een testbed hoge kosten met zich mee, die voor academici vaak onacceptabel zijn. Ten tweede is het met een testbed lastig om een reproduceerbare omgeving te creëren. Voor sommige toepassingen, bijvoorbeeld het monitoren van een vulkaanuitbarsting, is het gebruik van een testbed ongewenst omdat er schade aan de apparatuur kan ontstaan. Voor het gebruik van een sensornetwerk simulator gelden deze beperkingen niet. Sensornetwerk simulators imiteren echte sensornetwerken door middel van een computerprogramma. Om de werkelijkheid na te bootsen worden vereenvoudigde modellen van de werkelijkheid gebruikt. Daardoor is simulatie minder volledig en nauwkeurig dan het testen met fysieke hardware.

2.2.1 State of the art sensornetwerk simulators De afgelopen jaren zijn er meerdere sensornetwerk simulators ontwikkeld. Sommige van deze simulators zijn gebaseerd op reguliere (netwerk) simulators, anderen zijn volledig opnieuw opgebouwd. De doelstellingen van de sensornetwerk simulators lopen behoorlijk uiteen. Sommige simulators proberen een sensornetwerk op een zo laag mogelijk niveau te imiteren om een zo realistisch mogelijke simulatie mogelijk te maken. Andere simulators, waaronder SHAWN [9], imiteren een sensornetwerk op een hoger niveau om bijvoorbeeld een specifiek probleem of effect te onderzoeken. Een simulator is bruikbaar voor test gedreven ontwikkeling als de programmacode van een sensornetwerk applicatie ook daadwerkelijk wordt getest door middel van de simulatie. De code van de sensornetwerk applicatie wordt gebruikt om het gedrag van een sensorknoop te emuleren. Een gemodificeerde versie of een formele beschrijving van de applicatie is ongeschikt omdat daarmee niet de applicatiecode zelf wordt getest. Dit is niet in overeenstemming met de gedachtegang van test gedreven ontwikkeling. Geschikte sensornetwerk simulators kunnen in context met dit onderzoek in grofweg twee categorieën worden onderverdeeld.

1. Generieke sensornetwerk simulators Generieke sensornetwerk simulators zijn niet aan een specifiek sensornetwerk platform gebonden. Deze simulators maken gebruik van generieke modellen om het gedrag van een sen10

sornetwerk te beschrijven. De generieke modellen zullen afwijken van die van een specifiek sensornetwerk platform waardoor de simulaties minder realistisch zullen zijn. Door middel van uitbreidingen, vaak in de vorm van modules, kunnen platform-specifieke eigenschappen aan de simulator worden toegevoegd. De ontwikkeling van deze modules vereist kennis van zowel de simulator als het sensornetwerk platform. 2. Platform specifieke sensornetwerk simulators Specifieke sensornetwerk simulators zijn beperkt tot een bepaald sensornetwerk platform en bieden out-of-the-box de meest realistische simulatie van het specifieke platform. De implementaties binnen de simulator komen overeen met de implementaties op echte sensorknopen. Deze simulators zijn beperkt tot een bepaald platform en hebben daarom vaak minder uitbreidingsmogelijkheden.

In state of the art sensornetwerk simulators wordt steeds vaker de component gebaseerde architectuur gebruikt om modulaire uitbreidingen mogelijk te maken. Onder andere J-Sim [11] en SENSE [10] maken gebruik van deze architectuur die is gebaseerd op het component-port model. In het component-port model [10] [13] communiceert een component met andere componenten via inports en outports. Een inport implementeert een bepaalde functionaliteit en is dus gelijk aan een functie. Een outport dient als een abstractie van een functie pointer: het definieert welke functionaliteit het van anderen verwacht. Het fundamentele verschil tussen een object en een component in het component-port model is dat de interacties van een componenten met anderen volledig kunnen worden opgevangen door de interface. Voor een object is dit niet het geval. Een object kan bijvoorbeeld een functie van elk ander object aanroepen zolang het een pointer of referentie naar dat object heeft. Dergelijke communicatie is echter niet weerspiegeld in de interface of declaratie van het object en wordt alleen zichtbaar door de ge¨ımplementeerde code te onderzoeken. Het resulterende probleem is dat elke functie aanroep naar een extern object een impliciete onderlinge afhankelijkheid introduceert tussen objecten. Door deze impliciete onderlinge afhankelijkheden zijn objecten slecht herbruikbaar. Dankzij outports onderscheiden componenten zich van objecten. Outports leggen restricties op de runtime interacties tussen componenten. Het belangrijke gevolg van outports is dat de ontwikkeling van een onderdeel nu volledig gescheiden kan worden van de context waarin het onderdeel gebruikt zal worden. Dit leidt tot echte herbruikbare componenten. Daarnaast zijn componenten eenvoudiger uit te breiden. Elk component kan door een ander component worden vervangen, zolang de component de benodigde functionaliteiten levert. Vrijwel alle sensornetwerk simulators maken gebruik van discrete-event simulatie. Hierbij is de tijd opgedeeld in kleine blokjes. De toestand van het systeem wordt op basis hiervan stapsgewijs berekend, door middel van iteratie. De gebeurtenissen die de veranderingen van het systeem veroorzaken worden beschreven met een lijst van chronologische gebeurtenissen. Een gebeurtenis kan bijvoorbeeld een verandering van een sensorwaarde zijn. Alle gebeurtenissen samen vormen een scenario, wat als een test kan worden beschouwd. De virtuele tijd binnen de simulatie kan relatief aan de echte tijd worden gekozen, zo is het mogelijk om simulaties versneld of vertraagd te laten uitvoeren.

11

3 Sun SPOT Sun SPOT [4] (Sun Small Programmable Object Technology) is een open source draadloze sensornetwerk technologie. Sun SPOT bestaat uit een combinatie van hardware en software dat bij Sun Microsystems is ontwikkeld. Sun SPOT onderscheidt zich van andere sensornetwerken doordat het is gebouwd op de Squawk Java Virtual Machine [7]. Applicaties voor SPOTs worden daarom in de Java programmeertaal geschreven. Daarvoor kunnen standaard Java IDEs worden gebruikt. Sun SPOT is ontwikkeld om de ontwikkeling van nieuwe toepassingen en apparaten te bevorderen. Programmeurs die nog nooit met embedded apparaten hebben gewerkt, kunnen nu verder denken dan toetsenbord, muis en scherm. De programma’s die ze schrijven gaan op compleet nieuwe wijze interactie met elkaar, met de omgeving en met gebruikers aan.

3.1 Functionaliteiten van Solarium Solarium is een desktop applicatie om de software op Sun SPOTs te beheren. Middels een USB basisstation worden SPOTs op draadloze wijze gedetecteerd. Alle gedetecteerde SPOTs worden binnen de Solarium applicatie visueel getoond middels de weergave methode naar keuze (boomen/of rooster-weergave). Solarium biedt voor elke SPOT een aantal acties, waaronder het uploaden van een applicatie naar de SPOT.

Figuur 3.1: Een virtuele SPOT met controle paneel om de sensoren te beheren.

Solarium bevat een emulator die het mogelijk maakt om Sun SPOT applicaties op een desktop computer te draaien. Hierdoor kan een SPOT applicatie worden getest zonder het op een echte SPOT te moeten laden of zonder de hardware zelf. Anders dan discrete-event simulatoren is Solarium een emulator, die kan worden gebruikt om een deel van de omgeving te simuleren. Binnen Solarium wordt een geëmuleerde SPOT uitgedrukt als een virtuele SPOT. Elke virtuele SPOT dient handmatig door de gebruiker te worden aangemaakt en te worden voorzien van een SPOT applicatie. Een virtuele SPOT wordt dan visueel binnen Solarium weergegeven, inclusief LEDs en twee switches die op echte SPOTs aanwezig zijn. Alle sensoren worden handmatig beheerd met een controle 12

paneel (Figuur 3.1). Daarnaast kan Solarium de (tekstuele) uitvoer van een SPOT applicatie tonen, zodat er debug informatie kan worden gebruikt tijdens het testen. Virtuele SPOTs kunnen met elkaar communiceren door radioverbindingen te openen. Hiervoor kunnen broadcast en point-topoint verbindingen worden gebruikt. Deze virtuele radioverbindingen vinden plaats via reguliere en multicast sockets. Virtuele SPOTs kunnen ook met echte SPOTs communiceren. Het basisstation fungeert dan als extra hop. De functionaliteiten van de Solarium applicatie zijn echter te beperkt om simulaties gebaseerd op een scenario uit te voeren. Het nabootsen van realistische scenario’s vereist een hoop handelingen en is te complex om handmatig uit te voeren. Momenteel is het met Solarium alleen mogelijk om handmatig virtuele SPOTs te instantiëren, te configureren en sensorwaarden in te voeren. Daardoor is Solarium niet in staat om realistische scenario’s na te bootsen. Verder is de communicatie tussen virtuele SPOTs beperkt tot single-hop: alle virtuele SPOTs kunnen met elkaar communiceren en kennen geen (dynamische) netwerktopologie. Dit terwijl een dynamische netwerktopologie juist een prominent kenmerk is van sensornetwerken. Multihop communicatieprotocollen vormen daarom een belangrijk onderzoeksgebied van sensornetwerken, maar kunnen niet worden getest met Solarium. De simulatiemogelijkheden voor het SPOT platform zijn dus te beperkt om SPOT applicaties op test gedreven wijze te ontwikkelen.

3.2 Architectuur van Solarium Sun SPOT is geheel open source. Echter, de architectuur van Solarium en bijbehorende emulator is amper gedocumenteerd. Ook de broncode is amper voorzien van uitleg, waardoor het onnodig lastig is om met de code aan de slag te gaan. Door de broncode te bestuderen heb ik de nodige kennis opgedaan over de architectuur van Solarium. User application

User application

User application

SPOT library

SPOT library

SPOT library

Emulator

Emulator

Emulator

Squawk VM

Squawk VM

Squawk VM

Solarium vSpot 1

vSpot 2

...

vSpot n

Figuur 3.2: Solarium architectuur

Binnen Solarium worden zowel echte SPOTs als virtuele SPOTs (vSpot) gerepresenteerd door een virtueel object. Voor elke virtuele SPOT start Solarium een nieuw proces dat verantwoordelijk is voor de emulatie van één virtuele SPOT. Dit proces is opgebouwd uit vier lagen. 1. Squawk VM 13

Squawk is een micro Java virtuele machine voor embedded systemen en kleine apparaten. De virtuele machine interpreteert code en voert vervolgens de bijbehorende taken uit. 2. Emulator De emulator bootst de interactie met de omgeving na door gebruik te maken van een simpel model. Daardoor moet de gebruiker de sensorwaarden expliciet instellen. 3. SPOT library De SPOT bibliotheek bevat functionaliteiten voor de SPOT. 4. User application De SPOT applicatie die door de gebruiker is geschreven.

De emulator laag van elke virtuele SPOT interacteert met Solarium middels een eigen socket verbinding (zwarte pijlen in Figuur 3.2). Over deze verbinding wordt onder andere de uitvoer van de virtuele SPOT naar Solarium gecommuniceerd. Een voorbeeld daarvan is het doorgeven aan Solarium dat de eerste LED moet gaan branden. Solarium verwerkt de ontvangen opdracht van de emulator en zorgt ervoor dat de betreffende LED binnen de GUI gaat branden. Maar Solarium stuurt ook opdrachten naar de virtuele SPOT. Dit gebeurt bijvoorbeeld als de gebruiker met de muis op één van de twee switches drukt. De emulator ontvangt van Solarium een melding dat een switch is ingedrukt en zorgt ervoor dat dit door de SPOT applicatie wordt opgemerkt. Alle virtuele SPOTs kunnen onderling met elkaar communiceren. De emulator realiseert dit door socket verbindingen met de emulator van andere virtuele SPOTs te maken (witte pijlen). Daarnaast ontvangt elke emulator via een gedeeld multicast adres broadcast pakketten van andere virtuele SPOTs.

3.3 Solarium designkeuzes Uit de architectuur van Solarium kunnen een aantal designkeuzes worden afgeleid. Het was voor mijn onderzoek interessant om deze designkeuzes te verkennen en daarmee te bepalen wat de doelstellingen van Sun zijn geweest. Er zijn verschillende manieren om meerdere virtuele sensorknopen op een fysieke computer te emuleren [16]. Sun heeft ervoor gekozen om elke virtuele SPOT in een lichtgewicht Virtual Machine (Squawk) te draaien. Deze methode heeft als voordeel dat de SPOT applicatie en SPOT bibliotheek zonder modificaties kunnen worden gebruikt voor het emuleren van virtuele SPOTs. Daardoor levert deze methode transparantie met betrekking tot de software die wordt getest. Deze aanpak heeft echter ook nadelen. Elke Virtual Machine gebruikt de nodige hoeveelheid geheugen. Hierdoor is het aantal virtuele SPOTs dat op een computer geëmuleerd kan worden beperkt. Een ander nadeel is dat de performance wordt gedrukt. Elke Virtual Machine is een eigen proces. Het besturingssysteem zal door middel van context switches elk proces afwisselend toegang geven tot de processor. Deze context switches leveren een bepaalde overhead op. Elke virtuele SPOT is een proces. Om de draadloze communicatie tussen virtuele SPOTs te emuleren is er interprocescommunicatie (IPC) nodig. IPC technieken zijn grofweg te verdelen in vier categorieën: message passing, synchronisatie, shared memory en remote procedure calls (RPC). Sun heeft ervoor gekozen om IPC door middel van sockets (message passing) te implementeren. Een groot voordeel van sockets is dat het op de meeste besturingssysteem aanwezig is. Hierdoor hoeft 14

Sun alleen de API’s aan te roepen en geen eigen implementatie te schrijven. Daarnaast kan een multicast socket worden gebruikt om SPOT broadcastberichten op alle virtuele SPOTs af te leveren. Een ander bijkomend voordeel van sockets is dat IPC tussen meerdere computers mogelijk is. Een proces op computer A kan communiceren met een proces op computer B. Dit kan worden gebruikt om Solarium gedistribueerd te maken. De vraag blijft natuurlijk of Sun dit voordeel heeft laten meewegen in hun keuze. Het ontbreken van realistische vormen van communicatie is waarschijnlijk een afweging geweest tussen functionaliteiten en het tijdsbestek waarin Solarium ontwikkeld moest worden. In de Sun SPOT Emulator handleiding [17] wordt beschreven dat realistische simulatie van de draadloze radiocommunicatie wellicht een uitdagende uitbreiding voor de toekomst is. Virtuele SPOTs worden handmatig aangemaakt en de sensorwaarden moeten handmatig door de gebruiker worden ingesteld. Hierdoor wordt duidelijk dat Sun er voor heeft gekozen om Solarium te richten op kleinschalig testen van SPOT applicaties. Uit de bovenstaande designkeuzes kan worden geconcludeerd dat de huidige versie van Solarium is ontwikkeld om SPOT applicaties op kleine schaal te testen. Flexibiliteit van het programma, om het bijvoorbeeld uit te breiden of aan te passen, speelt een belangrijke rol terwijl schaalbaarheid een ondergeschikte rol speelt.

15

4 SpotSim simulator voor Sun SPOT Uit hoofdstuk 3 blijkt dat de Solarium applicatie te weinig functionaliteiten heeft om test gedreven ontwikkeling van SPOT applicaties mogelijk te maken. De oplossing die ik hiervoor presenteer is een Java framework met de naam SpotSim. Dit framework breidt de functionaliteiten van Solarium uit zodat het mogelijk wordt om SPOT applicaties op test gedreven wijze te ontwikkelen. Ik heb ervoor gekozen om de Solarium code als basis voor het framework te gebruiken. Hierdoor hoeft niet alles opnieuw geschreven te worden. Solarium bevat immers een solide basis die al redelijk wat functionaliteiten bevat. Solarium is open source en heeft een heldere objectgeoriënteerde structuur en is daardoor vrij eenvoudig aan te passen.

4.1 Gewenste functionaliteiten Met het framework wil ik de basis leggen om simulaties voor het Sun SPOT platform mogelijk te maken. Realistische netwerk simulatie is een complex probleem, daarom is het framework beperkt tot een aanzet om realistische netwerk simulaties te kunnen doen. De onderstaande functionaliteiten zijn in het framework ge¨ımplementeerd. Deze functionaliteiten zijn tot stand gekomen door de literatuurstudie van hoofdstuk 2 en door te redeneren vanuit de gebreken van Solarium.

• Multihop communicatie tussen virtuele SPOTs. • Simulatie scenario programmeren vanuit een programma. – Aantal sensorknopen programmeren. – Sensoren programmeren. – Netwerktopologieën programmeren. • Uitvoer van de simulatie. Deze uitvoer kan onder andere worden gebruikt om testen te valideren. – Visuele weergave van SPOTs. – Applicatie uitvoer (tekst). • Schaalbaar (gedistribueerde opzet).

4.2 Beschrijving Een scenario vormt het hart van het framework. Een scenario bestaat uit een door de gebruiker geschreven programma dat een bepaald scenario nabootst. De gebruiker doet dit door de sensoren van SPOTs met behulp van een sequentieel programma te programmeren. Vanuit het scenario 16

programma kan het netwerk ook worden geprogrammeerd zodat de gewenste netwerktopologie wordt gevormd. Het framework is gebaseerd op het algemene UPVN concept [12] waarbij er op een andere manier naar netwerken wordt gekeken. Het doel van UPVN is om de applicatie meer controle over het netwerk te geven. In het UPVN concept kan de applicatie invloed uitoefenen op het netwerk door middel van een applicatiecomponent (AC) die draait op een netwerkelement (NE). De applicatie zal virtuele netwerkelementen (VNE’s) aanmaken en via deze virtuele netwerkelementen de echte netwerkelementen (NE’s) besturen.

Applicatie

Applicatie

NC

NC

NE

Scenario

Om een bepaalde handeling te verrichten en daarbij aan te passen aan de omgeving

NE

AC

AC

VNE

VNE

Om erachter te komen wat het netwerk doet in bepaalde omstandigheden

Figuur 4.1: Schematische beschrijving van het framework op basis van het UPVN concept.

Door het UPVN concept op de bestaande Solarium architectuur toe te passen wordt het mogelijk om het netwerk te programmeren en een netwerktopologie te vormen. Dit is een vereiste om multihop communicatie mogelijk te maken. Het UPVN concept kan vrij eenvoudig worden toegepast op de bestaande architectuur van Solarium. Solarium maakt namelijk al gebruik van virtuele netwerkelementen (in de vorm van virtuele SPOTs) om invloed uit te oefenen op de applicatie. Solarium doet dit door sensorwaarden met de emulator uit te wisselen. De emulator zorgt voor de netwerkfunctionaliteiten en is dus gelijk aan een netwerkelement (NE). De SPOT bibliotheek levert het netwerkcomponent (NC) zodat de SPOT applicatie gebruik kan maken van de functionaliteiten die het netwerk levert. In de Solarium architectuur ontbreekt echter het applicatiecomponent (AC). Daardoor kan er via virtuele netwerkelementen (VNE’s) geen invloed op de netwerkelementen (NE’s) worden uitgeoefend. Het netwerk kan dus niet worden geprogrammeerd en er kan geen netwerktopologie worden gevormd. Door het applicatiecomponent (AC) aan de architectuur toe te voegen kan het netwerk wel worden geprogrammeerd. Door het netwerk te programmeren kan een netwerktopologie worden gevormd en wordt multihop communicatie mogelijk gemaakt. In een scenario wordt elke sensorknoop dus gerepresenteerd door een virtueel netwerkelement (VNE). Elke sensorknoop bestaat weer uit een sensornetwerk applicatie en een netwerkelement (NE). Het netwerkelement (NE) levert de benodigde netwerkfunctionaliteiten zoals het verzenden en ontvangen van pakketten. Vanuit een SPOT applicatie wordt het netwerkcomponent (NC) gebruikt om met het netwerkelement (NE) te communiceren. Het scenario programma kan via een virtueel netwerkelement (VNE) communiceren met de applicatie. Op deze wijze kan er vanuit het scenario programma met een SPOT applicatie worden gecommuniceerd. Een voorbeeld daarvan is het programmeren 17

van sensoren vanuit een scenario. De verticale zwarte pijl van Figuur 4.1 drukt de wisselwerking tussen een scenario en de sensornetwerk applicatie uit. Een scenario probeert er achter te komen wat het netwerk doet in bepaalde omstandigheden. Het netwerk reageert op de acties uit het scenario en weerspiegelt daarmee het scenario. Door de weerspiegeling op te vangen (de uitvoer van de sensornetwerk applicatie) kan worden bepaald of het netwerk op de gewenste manier op een scenario reageert. Daarmee wordt test gedreven ontwikkeling van sensornetwerk applicaties mogelijk. Deze architectuur heeft echter ook een beperking. Het is het vrijwel onmogelijk om unittesten op de kleinste softwarecomponenten uit te voeren. Door vanuit een scenario alleen de omgeving (sensoren en de netwerktopologie) te programmeren is het vrijwel onmogelijk om specifieke modulen of kleine stukjes code van de sensornetwerk applicatie afzonderlijk te testen. Deze componenten zijn namelijk niet afzonderlijk te benaderen vanuit het framework. De overige soorten testen (integratietesten, systeemtesten en systeem integratietesten) vinden plaats op een hoger abstractieniveau en zijn daardoor wel te benaderen door de omgeving te programmeren. Via de omgeving worden parameters aan de sensornetwerk applicatie aangeboden. De sensoren en netwerktopologie treden op als interface van de sensornetwerk applicatie.

18

4.3 Implementatie van het framework

User application

User application

User application

SPOT library

SPOT library

SPOT library

Emulator

Emulator

Emulator

SpotSim

SpotSim

SpotSim

Squawk VM

Squawk VM

Squawk VM

Multihop whitelist nnnn.nnnn.nnnn.nnnn nnnn.nnnn.nnnn.nnnn

Solarium vSpot 1

vSpot 2

...

vSpot n

SpotSim

Figuur 4.2: SpotSim architectuur. De grijs gearceerde vlakken zijn onderdelen van het framework die aan Solarium zijn toegevoegd.

Het centrale component van het SpotSim framework bevindt zich binnen Solarium. Het centrale component bestaat uit een aantal Java klassen en functioneert als centrale coördinator voor Solarium. Een virtuele SPOT wordt binnen SpotSim gerepresenteerd door een instantie van het SpotSimNode object. Dit object levert een interface voor een virtuele SPOT. Voor elke virtuele SPOT binnen SpotSim wordt een bijbehorende virtuele SPOT (vSpot) binnen Solarium aangemaakt. Tussen beide virtuele SPOT objecten vindt interactie plaats. Op deze wijze kan SpotSim een virtuele SPOT binnen Solarium aansturen. Deze aanpak brengt een groot voordeel met zich mee. Door virtuele SPOTs binnen Solarium te behouden hoeft er maar weinig code aan het framework te worden toegevoegd, veel functionaliteiten (sensorwaarden, communicatie met de emulator laag, etc) worden immers al aangeboden door vSPOTs binnen Solarium. Het framework benut deze reeds bestaande functionaliteiten. Om multihop communicatie te realiseren is de emulator uitgebreid. Binnen de emulator is een SpotSim component toegevoegd dat fungeert als een firewall. De component bepaalt of een inkomend of uitgaand bericht (afkomstig van andere SPOTs) ontvangen of verzonden mag worden. Daarvoor gebruikt het SpotSim component een whitelist, een lijst met adressen van SPOTs waarmee een SPOT mag communiceren. Een network topologie wordt gevormd door elke emulator van de juiste whitelist te voorzien. Figuur 3.3 zal dit verduidelijken. De centrale SpotSim component zorgt voor de distributie (pushen) van de whitelisten naar de emulators. Hiervoor maakt SpotSim gebruik van de bestaande socket verbinding (zwarte lijnen) tussen Solarium en elk SPOT proces (emulator). De emulator herkent berichten die afkomstig zijn van SpotSim aan de hand van de ”SpotSim”prefix. Deze berichten worden dan doorgestuurd naar het SpotSim component binnen de emulator (firewall). 19

whitelist 2 3 whitelist 1 2 4

whitelist 3

1

2

whitelist 1 3

3

4

Figuur 4.3: Voorbeeld van een network topologie op basis van whitelisten.

Om multihop communicatie te realiseren moet elke emulator dus weten met welke SPOTs wel en niet gecommuniceerd mag worden. Er zijn verschillende methoden om dit te realiseren. De pull-methode is ongeschikt. Bij de pull-methode vraagt de emulator bij elk binnenkomend of uitgaand bericht aan SpotSim of dit is toegestaan. Deze methode zorgt voor vertragingen doordat er telkens toestemming gevraagd moet worden. Dit zorgt tevens voor een hoge belasting op SpotSim, zeker wanneer elke emulator opvraagt of een binnenkomend broadcastbericht geaccepteerd moet worden.

De push-methode is een betere oplossing. Bij de push-methode stuurt SpotSim informatie naar de emulators. Op basis van deze informatie kan elke emulator bepalen of een inkomend of uitgaand bericht wel of niet ontvangen of verzonden mag worden. Veranderingen in de netwerktopologie worden direct naar desbetreffende emulators gesynchroniseerd waardoor de informatie in de emulators altijd up-to-date is. In de meest voorkomende sensornetwerk topologieën kan elke sensorknoop maar met een beperkt aantal buren communiceren. Het aantal buren waarmee wel gecommuniceerd kan worden is daardoor veel kleiner dan het aantal buren waarmee niet gecommuniceerd kan worden. Het pushen van lijsten waarmee wel gecommuniceerd mag worden (whitelisten) is daardoor een efficiëntere methode dat het pushen van lijsten waarmee niet gecommuniceerd mag worden (blacklisten).

Gedistribueerde implementatie

De beschreven implementatie maakt het mogelijk om op eenvoudige wijze een groot aan virtuele SPOTs aan te maken. Maar het experiment dat in hoofdstuk 6.1 wordt beschreven toont aan dat het maximum aantal virtuele SPOTs dat gesimuleerd kan worden in grote mate afhankelijk is van de hoeveelheid geheugen van de computer. Het proces van een virtuele SPOT gebruikt namelijk ongeveer 38MB aan geheugen. Een haalbare oplossing voor dit probleem is een gedistribueerde aanpak waarbij de virtuele SPOT processen over meerdere computers worden verdeeld. 20

User application

User application

User application

SPOT library

SPOT library

SPOT library

Emulator

Emulator

Emulator

SpotSim

SpotSim

SpotSim

Squawk VM

Squawk VM

Squawk VM

Solarium vSpot 1

vSpot 2

... vSpot n

SpotSimHost1

vSpot 2

SpotSimHost2

vSpot n

SpotSim

pc1

pc2

pc3

Figuur 4.4: SpotSim gedistribueerde architectuur. De grijs gearceerde vlakken zijn onderdelen van het framework.

Net als bij de niet-gedistribueerde versie van SpotSim draait er op één computer (pc1) het centrale component. Vanuit dit component worden alle virtuele SPOT processen, die zijn verspreid over meerdere computers, aangestuurd. De overige computers (hosts) zijn voorzien van een SpotSim applicatie met de naam SpotSimHost. Al deze hosts zijn middels een socket verbinding met de centrale SpotSim component verbonden. Deze architectuur is gebaseerde op het master-slave model waarbij Solarium als master optreedt. Omdat één computer een gecentraliseerde rol vervult is de implementatie tot bepaalde hoogte schaalbaar. De virtuele SPOT processen die normaliter op één computer draaien komen nu verspreid over meerdere computers te draaien. SpotSim zorgt ervoor dat er een virtuele verbinding tussen Solarium en elk SPOT proces ontstaat. Dankzij deze virtuele verbinding maakt het voor Solarium geen verschil of een SPOT proces lokaal of op een andere computer draait. De beperking in de niet-gedistribueerde versie van Solarium wordt veroorzaakt doordat het aantal SPOT processen dat op één computer kan draaien beperkt is. Deze beperking wordt niet zozeer veroorzaakt door de Solarium applicatie zelf. Het is daardoor een voor de hand liggende keuze om alleen de SPOT processen gedistribueerd te maken. Hierdoor hoeft de architectuur van Solarium niet te worden veranderd, waardoor de implementatie relatief eenvoudig is. Het introduceren van de SpotSimHost applicatie is een vereiste om de virtuele verbindingen tussen Solarium en de SPOT processen op andere computers te realiseren. De SpotSimHost applicatie is verantwoordelijk voor de volgende functionaliteiten: • Starten van een virtueel SPOT proces. De opdracht (inclusief parameters) om een virtueel 21

SPOT proces te starten is altijd afkomstig van de centrale SpotSim component. • Stoppen en opschonen van een virtueel SPOT proces. Ook deze opdracht is altijd afkomstig van de centrale SpotSim component. • Virtuele verbinding tussen Solarium en elk SPOT proces. Over deze verbinding worden onder andere sensorwaarden verzonden.

Het feit dat de SPOT processen nu verspreid over meerdere computers draaien, brengt een extra complicatie met zich mee. Om een virtuele SPOT met een andere virtuele SPOT te laten communiceren moet bekend zijn op welke computer (ip-adres) een virtuele SPOT zich bevindt. Voor elke virtuele SPOT moet dus bepaald kunnen worden op welk ip-adres het bijbehorende proces bereikbaar is. Deze mapping gebeurt op basis van het unieke 64-bit IEEE extended MAC adres [14] dat elke virtuele SPOT krijgt toegekend door Solarium. Deze mapping is reeds ingebouwd in Solarium. In de standaard implementatie van Solarium wordt het lokale ip-adres in de voorste 32 bits geplaatst, waardoor er nog 32 bits overblijven om elke SPOT uniek te identificeren. Tijdens het toevoegen van een nieuwe virtuele SPOT weet SpotSim al op welke computer en bijbehorend ip-adres het SPOT proces komt te draaien. Deze informatie wordt aan Solarium doorgespeeld zodat niet het lokale, maar het correcte externe ip-adres in het MAC adres wordt ingekapseld. De emulator laag kan daardoor aan de hand van een MAC adres van een SPOT achterhalen op welk ip-adres de betreffende virtuele SPOT draait. Om te controleren of de implementatie werkt, heb ik een experiment met drie computers uitgevoerd. Elke computer is voorzien van een packet sniffer zodat het netwerk verkeer tussen computers kan worden gemonitord. Op elke computer komt één SPOT te draaien die is voorzien van de SPOT Bounce demo applicatie. Deze applicatie laat één bal langs alle SPOTs rollen en zorgt er voor dat er op voorspelbare wijze communicatie tussen SPOTs plaatsvindt. De packet sniffer weerspiegelde deze voorspelbare communicatie tussen de computers en bevestigde dat de implementatie correct functioneerde.

4.4 Problemen en oplossingen Tijdens de ontwikkeling van het framework deden zich een aantal significante problemen voor.

4.4.1 Bug in de multihop code van de SPOT bibliotheek Tijdens het testen van mijn multihop implementatie werd duidelijk dat de maximale hop-count 15 was. Dit houdt in dat pakketten die over een route van meer van 15 hops gaan niet worden verzonden. Na enig onderzoek werd duidelijk dat de maximale hop-count kon worden opgehoogd door de NET_DIAMETER constante in de SPOT bibliotheek aan te passen. De aanpassing resulteerde in het gewenste effect en pakketten konden nu over routes met meer dan 15 hops worden verzonden. Echter, bij pakketten met een hop-count van meer dan 14 wordt een extra byte achteraan de payload van het pakket toegevoegd. Dit ongewenste verschijnsel zorgt er onder andere voor dat ontvangen strings onjuist worden uitgelezen. De oorzaak van dit verschijnsel ligt aan het feit dat pakketten met een hop-count van meer dan 14 op afwijkende wijze worden behandeld. Er wordt onder andere een extra byte aan de pakket header toegevoegd. 22

Bovenstaande constateringen wijzen op een fout in de multihop code van de SPOT bibliotheek. Het oplossen van deze mogelijke bug valt niet binnen de scope van dit onderzoek en is niet noodzakelijk voor de werking van het framework. Daarom heb ik deze bug niet zelf opgelost, maar gedeeld [15] met de Sun SPOT community op het SunSpotWorld.com forum. Een software reseacher van Sun heeft de bug bevestigd en toegevoegd aan de Sun SPOT bug database. De ontdekking van deze multihop bug bevestigt dat mijn onderzoek uniek is. Voorheen was het met Solarium niet mogelijk om multihop communicatie te simuleren waardoor de bug niet eerder is ontdekt.

4.4.2 Initialisatietijd per SPOT Het starten van een applicatie op een virtuele SPOT gaat in Solarium gepaard met een tweetal operaties die de nodige tijd en processorcapaciteit vergen. De applicatie voor op de SPOT wordt allereerst gecompileerd tot een JAR bestand. Daarna worden alle JAR bestanden (eventueel van meerdere programma’s) gecombineerd tot één SUITE bestand. Door meerdere SPOT programma’s tot één SUITE bestand te combineren zijn de programma’s beter in staat om externe bronnen te delen. Beide stappen worden voor elke virtuele SPOT opnieuw uitgevoerd en nemen ongeveer drie seconden in beslag. De initialisatietijd kan drastisch worden teruggedrongen door de herhalingen van beide stappen te elimineren. De eerste stap, het compileren van een JAR bestand, kan volledig worden overgeslagen door dit eenmalig uit te voeren. De locatie van het JAR bestand kan daarna als parameter voor de applicatie worden gebruikt. De stap waarin het SUITE bestand wordt gegenereerd wordt eenmalig uitgevoerd. Daarna wordt hetzelfde SUITE bestand gebruikt voor alle SPOTs. Beide verbeteringen zijn in het framework ge¨ımplementeerd. De verbeterde initialisatietijd is in Figuur 4.5 weergegeven met grafiek 2 .

Initialisatietijd in seconden

150

112,5

75

37,5 10 20 30 Ge Win Orig 27,5 117 69,0 SP 63,1 SP 30,9 SP mid 0,0% st Gem 8,96 17,9 19,3 72,1% inee OTS OTs OTs deld odifi l ceer Depl 20 SPOTs

0 10 SPOTS

30 SPOTs

Aantal SPOTs 1 2

Originele initialisatietijd (Solarium) Verbeterde initialisatietijd (framework)

Figuur 4.5: Initialisatietijd van SPOTs. De Solarium methode vergeleken met de methode van het framework.

Zowel de originele als de efficiëntere implementatie laten een groei zien die wat sneller is dan lineair met het aantal SPOTs. Het aanmaken van elke SPOT vereist dezelfde operaties en dus dezelfde tijd. Maar naarmate er meer SPOTs zijn toegevoegd neemt de processorbelasting toe. Daardoor is er minder processorcapaciteit beschikbaar om een nieuwe SPOT aan te maken. Het aanmaken van 23

een SPOT zal dus steeds meer tijd in beslag nemen naarmate het aantal reeds aangemaakte SPOTs toeneemt. Met de Fit[] functie van Mathematica [24] zijn de volgende twee formules voor de meetresultaten opgesteld. tSolarium = 1.95671 ∗ N + 0.0637037 ∗ N 2 (4.1) tf ramework = 0.738334 ∗ N + 0.00949395 ∗ N 2

(4.2)

De eerste term verklaart de lineaire groei. De tweede term verklaart de additionele groei die afhankelijk is van de N SPOTs die reeds zijn toegevoegd (processorcapaciteit). Deze term laat zien dat de initialisatietijd van het framework minder afhankelijk is van het aantal toegevoegde SPOTs dan bij Solarium het geval is.

24

25

5 SpotSim toepassingen 5.1 Sun SPOT in het onderwijs In tegenstelling tot de meeste sensornetwerk platformen worden Sun SPOTs geprogrammeerd in de Java programmeertaal. De Java programmeertaal is populair in het onderwijs [18]. Daardoor is het programmeren van Sun SPOTs relatief eenvoudig voor studenten. Dit maakt het Sun SPOT platform interessant voor het onderwijs.

Colleges

Sun SPOTs worden reeds gebruikt voor colleges op Universiteiten [19] [20]. Door SPOT applicaties te schrijven en te testen maken studenten kennis met draadloze sensornetwerken. Het testen op echte SPOTs is niet altijd een optie. Vaak is het aantal beschikbare SPOTs beperkt en is het dus lastig om studenten de gewenste testopstellingen te laten realiseren. Daarnaast is het met echte SPOTs lastig om een reproduceerbare omgeving te creëren. Simulatie is een beter alternatief. Door te simuleren kunnen reproduceerbare omgevingen worden gecreëerd en worden echte SPOTs overbodig.

Onderzoek

UPVN op de SPOT Robin Fidder is een student aan de Universiteit van Amsterdam die onderzoek doet met behulp van het Sun SPOT platform. Robin heeft het UPVN (User Programmable Virtualized Network) concept op de SPOT ge¨ımplementeerd. Daarmee kan de AODV [21] routerings manager van de SPOT worden be¨ınvloed vanuit een SPOT applicatie. Hierdoor wordt het mogelijk om bijvoorbeeld routes met daarin de warmste sensorknoop te mijden. Door middel van experimenten wordt bepaald of de implementatie correct functioneert. Tijdens deze experimenten is het belangrijk dat de netwerktopologie kan worden beheerst, zodat kan worden vastgesteld of een pakket de juist route neemt. Tijdens experimenten met echte SPOTs kwam Robin tot de conclusie dat het onmogelijk is om de netwerktopologie te beheersen. Factoren van buitenaf, zoals bijvoorbeeld een hand, blijken een grote invloed op de draadloze communicatie tussen SPOTs te hebben. Deze invloed is groot genoeg om de netwerktopologie te laten veranderen. Daardoor kan niet met zekerheid worden vastgesteld of een pakket de gewenste route heeft genomen. Simulatie biedt de uitkomst. SpotSim biedt de mogelijkheid om te experimenten met vaste netwerktopologieën door middel van simulatie. De door Robin gemodificeerde SPOT code kan rechtstreeks door de simulator worden gebruikt. Het ontbreken van packet-loss en signaalsterkte in de simulatie vormt geen beperking. Deze variabele factoren zijn namelijk met echte SPOTs onmogelijk te controleren wat zal resulteren in een onbeheersbare testomgeving. 26

Genetische programmering van een sensornetwerk applicatie Genetische programmering (GP) is een geautomatiseerde methode om een computerprogramma te maken. Genetische programmering begint met een hoog niveau statement of probleem. Aan de hand daarvan wordt bepaald wat er gedaan moet worden. Daarna wordt er op geautomatiseerde wijze een programma gecreëerd dat het probleem zal oplossen. Door een sensornetwerk applicatie met genetische programmering te creëren ontstaat er een interessant onderzoek. Met behulp van het SpotSim framework kan de omgeving worden geprogrammeerd. Het genetische programma zal op de omgeving reageren en zich aanpassen, zodat het programma zal gaan functioneren in de omgeving. Hierdoor ontstaat er een wisselwerking tussen de sensornetwerk applicatie en de omgeving. Deze methode om sensornetwerk applicaties te ontwikkelen is interessant voor complexe scenario’s waarbij het moeilijk is om een optimaal programma te schrijven.

5.2 Implementeren van proofs of concepts Sun SPOT is een eenvoudig te programmeren sensornetwerk platform en is daarom een aantrekkelijk platform om proofs of concepts mee te implementeren. Met het SpotSim framework is het mogelijk om testen op het ge¨ımplementeerde concept uit te voeren. Hiervoor is geen SPOT hardware vereist wat het platform ook financieel aantrekkelijk maakt.

5.3 SPOT Bounce demo De SPOT Developer Kit wordt geleverd inclusief de SPOT Bounce demo applicatie. Deze demo applicatie maakt gebruikt van de 3-as versnellingsmeter (sensor) en de acht LEDs van de SPOT. De interactie tussen de gebruiker en de applicatie maakt deze SPOT applicatie aantrekkelijk om te demonstreren. Een blauwe LED stelt een rollende bal voor. Deze bal reageert op de bewegingen van de SPOT. Door de SPOT naar links te bewegen zal de bal naar links rollen en door de SPOT naar rechts te bewegen zal de bal naar rechts rollen. De bal zal standaard binnen de 8 LEDs (speelveld) blijven rollen. Op een tweede SPOT die is voorzien van hetzelfde programma zal ook een bal worden getoond, maar in een andere kleur. De SPOTs zijn dus op de hoogte van elkaars aanwezigheid. De SPOTs kunnen worden samengevoegd tot één speelveld dat over meerdere SPOTs is verspreid. Hiervoor dient op een switch knop van een SPOT te worden gedrukt. Een LED zal rood gaan knipperen. Nu moet er op een switch knop van een andere SPOT worden gedrukt. De SPOTs worden nu gekoppeld en de muur tussen de beide speelvelden wordt weggehaald. Dit koppelproces kan met meerdere SPOTs worden uitgevoerd waardoor een groter speelveld zal ontstaan. De ballen kunnen nu over meerdere SPOTs heen en weer bewegen. De SPOT Bounce applicatie kan worden getest door bijvoorbeeld de volgende handelingen uit te voeren:

1. Start drie SPOTs met het SPOT Bounce programma. 2. Koppel de eerste en tweede SPOT met elkaar. 3. Koppel de tweede en derde SPOT met elkaar. Nu vormen alle SPOTs één speelveld. 27

4. Beweeg alle SPOTs gedurende vijf seconden langzaam naar links. Alle ballen zullen nu naar links rollen. 5. Beweeg alle SPOTS gedurende vijf seconden langzaam naar rechts. Alle ballen zullen nu naar rechts rollen. 6. Ga naar stap 4 (herhaal het bewegen).

Bovenstaande handelingen kunnen worden vertaald in een scenario code. Daardoor kunnen de handelingen autonoom worden uitgevoerd door het SpotSim framework. Het framework zal dus een omgeving simuleren. Door een test te schrijven kan systematisch worden vastgesteld of de SPOT Bounce applicatie op de gewenste wijze functioneert. Een voorbeeld test kan worden opgesteld door te valideren of de bal van een kant naar de andere kant rolt en daarbij de LEDs in de juiste volgorde gaan branden. De code hiervoor is uitgewerkt in Bijlage A. Een vergelijking tussen resultaat van de simulatie en de Bounce applicatie op echte SPOTs laat zien dat de simulatie realistisch is.

28

29

6 Kwantitatieve analyse 6.1 Resource gebruik In dit hoofdstuk worden de kwantitatieve limieten van het SpotSim framework verkend met een aantal experimenten. Uit de resultaten kan worden geconcludeerd hoeveel virtuele SPOTs er op één computer gesimuleerd kunnen worden. De kwantitatieve aspecten die in dit experiment worden gemeten zijn de initialisatietijd (wachttijd voordat de simulatie kan worden gevoerd), de processorbelasting (%) en het geheugengebruik (MB). Deze aspecten zijn uitgezet tegenover het aantal virtuele SPOTs dat wordt gesimuleerd. De machine waarop de experimenten zijn uitgevoerd is een MacBook Pro met een 2,2 Ghz Core 2 Duo processor, 4GB ram geheugen, 5400 RPM harde schijf en draait het Mac OS X 10.5.6 besturingssysteem. Elke meting is minimaal dubbel uitgevoerd en de gemiddelden zijn gebruikt in dit onderzoek. Elke virtuele SPOT is voorzien van een eenvoudige broadcast listener applicatie die weinig additionele processing introduceert. Geheugengebruik tijdens simulatie

Geheugengebruik (MB)

4000

3000 Fysi ek Swa gehe p Sola uge gehe rium

2000

0 20 60 100 120 140 765 1400 2600 3850 3990 3990 0 0 0 1 725 2039 37 85 94 106 80 67

1000

0

0

20

60

100

120

140

Aantal virtuele SPOTs 1

Fysiek geheugen (MB)

2 Solarium geheugen (MB)

3

Swap geheugen (MB)

Figuur 6.1: Het geheugengebruik uitgezet tegenover het aantal virtuele SPOTs.

Elke virtuele SPOT draait in een eigen proces dat ongeveer 38MB aan geheugen gebruikt. Dit zorgt voor een lineaire toename van het geheugengebruik. Een ander component dat bijdraagt aan het totale geheugengebruik is het Solarium proces. Het geheugengebruik van het Solarium proces neemt licht toe naarmate het aantal gesimuleerde SPOTs hoger wordt. Dit kan worden verklaard doordat Solarium datastructuren voor elke virtuele SPOT bijhoudt. Daarnaast zorgen de communicatiestructuren voor een toename van het totale geheugengebruik. Het maximale aantal mogelijke 30

communicatiestructuren is gelijk aan N ∗ N . In de praktijk zullen niet alle SPOTs rechtstreeks met elkaar kunnen communiceren doordat er sprake is van een netwerktopologie. Het werkelijke aantal communicatiestructuren zal daarom lager dan N 2 uitvallen. Elke communicatiestructuur zal een kleine hoeveelheid geheugen gebruiken waardoor het geheugengebruik ook zal toenemen naarmate het aantal SPOTs toeneemt. Er kan worden geconcludeerd dat het geheugengebruik iets sneller dan lineair groeit met het aantal SPOTs.

Zodra al het fysieke geheugen volledig is benut zal het besturingssysteem virtueel swapgeheugen gaan gebruiken om het geheugentekort aan te vullen. Grafiek 1 van Figuur 6.1 laat zien dat bij de testopstelling dit punt rond 100 SPOTs wordt bereikt. Virtueel swapgeheugen is veel trager dan fysiek geheugen. De performance van de emulatie zal vanaf dit punt dan ook drastisch afnemen. Dit heeft gevolgen voor de nauwkeurigheid van de emulatie. Swapping ontbreekt bij echte Sun SPOTs en is een factor die is ge¨ıntroduceerd door de emulatie omgeving. Er moet dus worden afgevraagd hoe realistisch emulatie is indien er gebruik wordt gemaakt van swapgeheugen.

Initialisatietijd van simulatie 300

Initialisatietijd (s)

225 Initi alis

0

0

20 60 100 120 140 13 39 74 123 229

150

75

0

0

20

60

100

120

140


Initialisatietijd (s)

Figuur 6.2: De Initialisatietijd uitgezet tegenover het aantal virtuele SPOTs.

Het verband tussen de initialisatietijd en het aantal SPOTs is niet lineair. De initialisatietijd per SPOT blijkt toe te nemen naarmate er meer SPOTs worden gesimuleerd. Dit kan worden verklaard doordat de processorbelasting toeneemt naarmate het aantal virtuele SPOTs hoger wordt. Hierdoor blijft er minder rekencapaciteit over waardoor het instantiëren van nieuwe SPOTs meer tijd in beslag neemt. Vanaf ongeveer 110 SPOTs neemt de initialisatietijd per SPOT explosief toe. Doordat het fysieke geheugen rond deze grens vol is, gaat het besturingssysteem gebruik maken van swapgeheugen waardoor de performance inzakt. 31

Processor belasting tijdens simulatie

Processor belasting (%)

80

60

Pro ces

40

0

5

20 60 100 120 140 12 35 52 67 80

20

0

0

20

60

100

120

140

Aantal virtuele SPOTs 1 Processor belasting (%)

Figuur 6.3: De processorbelasting uitgezet tegenover het aantal virtuele SPOTs.

Het verband tussen de belasting van de processor en het aantal SPOTs is lineair. De belasting van de processor blijft per SPOT proces vrijwel constant, dus de belasting van de processor stijgt evenredig met het aantal SPOTs dat wordt gesimuleerd. De belasting door het Solarium proces blijft voor alle geteste aantallen SPOTs rond de 3% steken en is dus vrijwel verwaarloosbaar. Uit bovenstaande resultaten kan worden geconcludeerd dat het aantal SPOTs dat op één computer kan worden gesimuleerd wordt gelimiteerd door de capaciteit van de processor en de hoeveelheid fysiek geheugen. Zodra al het fysieke geheugen is gebruikt of als de processor volledig wordt belast zal de performance van de simulatie (drastisch) gaan afnemen. Er kan daarbij worden afgevraagd in hoeverre heeft het systeem waarop wordt gesimuleerd invloed heeft op de simulaties. Zolang het systeem de simulatie kan bijbenen zal de simulatie real-time zijn. Als dit niet het geval is, zal de simulatie afwijkingen gaan vertonen waardoor de simulatie minder nauwkeurig wordt. Bij de gebruikte testopstelling bleek het geheugen de beperkende factor te zijn, terwijl de processor nog enige marge vertoonde. Een verdubbeling van de geheugencapaciteit zal er juist voor zorgen dat de processor de beperkende factor zal worden. Daarnaast kan op basis van het geringe geheugenen processorgebruik van het Solarium proces worden geconstateerd dat de simulator de potentie heeft om veel meer SPOTs te simuleren. Deze constatering is de aanleiding geweest om het SpotSim framework gedistribueerd te maken.

6.2 Communicatievertragingen Bovenstaande analyse geeft een indicatie van het resource gebruik van de simulator, maar vertelt niks over de eventuele vertragingen in de communicatie tussen virtuele SPOTs. Mijn hypothese is dat een hogere CPU belasting zal zorgen voor een grotere communicatievertraging. De eerder besproken SPOT Bounce demo applicatie kan worden gebruikt om communicatievertragingen te meten. De bal rolt van een uiterste zijde naar de andere uiterste zijde. Bij elke meting legt de bal dus dezelfde afstand af. Deze afstand is lineair aan het aantal SPOTs. Een dubbel aantal SPOTs zorgt voor een dubbele afstand die de bal moet afleggen. De snelheid van de bal is bij de 32

reguliere SPOT Bounce applicatie afhankelijk van de versnellingsmeter (sensor) en is daardoor niet constant. Daarom heb ik een kleine modificatie in de Bounce applicatie aangebracht om de bal met een constante snelheid te laten rollen. De roltijd is daardoor idealiter lineair aan het aantal virtuele SPOTs. Om een bal van SPOT A naar SPOT B te verplaatsen, zal communicatie tussen beide SPOTs plaatsvinden. Deze communicatie zal een vertraging (communicatievertraging) introduceren waardoor de bal er langer over zal doen om de bestemming te bereiken. Voor N SPOTs zal N − 1 keer communicatie plaatsvinden om een bal naar de andere kant te laten rollen. Hierdoor wordt N − 1 keer een communicatievertraging ge¨ıntroduceerd. Communicatietijd van SPOT Bounce applicatie 40000

Roltijd (ms)

30000

20000

10000

0

10

20

30

40

50


Roltijd van één bal (ms)

2 Roltijd van alle ballen (ms) 3 Roltijd van alle ballen in headless modus (ms)

Figuur 6.4: Communicatievertragingen gemeten met de SPOT Bounce applicatie. De bal rolt met een constante snelheid van een uiterste kant naar de andere uiterste kant.

Grafiek 1 van Figuur 6.4 laat zien dat de roltijd van één bal iets sneller dan lineair groeit aan het aantal SPOTs. Dit betekent dat de communicatie tussen SPOTs een geringe vertraging introduceert. Doordat deze geringe vertraging N − 1 wordt ge¨ıntroduceerd is de groei iets sneller dan lineair. Grafiek 2 van Figuur 6.4 laat zien dat de roltijd supralineair toeneemt wanneer er meerdere ballen worden gebruikt. Nu rollen er N ballen langs alle SPOTs waardoor de communicatievertraging N keer worden ge¨ıntroduceerd. De communicatievertragingen spelen nu een significante rol. Daarnaast zorgt de simulatie van meerdere ballen voor een flinke processorbelasting van 100%. Daardoor gaan de processen langzamer draaien waardoor ook de communicatievertragingen toenemen. Doordat er meerdere ballen worden gesimuleerd neemt de activiteit van de grafische interface ook toe. Om de invloed van de grafische interface op de vertragingen vast te stellen is het experiment met meerdere ballen ook zonder grafische interface (headless modus) uitgevoerd. Deze modus kan worden geactiveerd door Solarium met het -headless argument te starten. Solarium maakt dan geen instantie van de grafische interface aan. Grafiek 3 van Figuur 6.4 geeft de resultaten van dit experiment in headless modus aan. Hieruit blijkt dat de grafische interface ook een zekere vertraging introduceert. De hoge processorbelasting wordt veroorzaakt door de SPOT processen. Om te bepalen of deze belasting wordt veroorzaakt door communicatie (emulator) of door een aspect van de Bounce applicatie is het nodig om de Bounce applicatie te elimineren. Daarom heb ik een flooding applicatie 33

geschreven die N packets langs alle SPOTs verstuurt, net als de SPOT Bounce applicatie. Communicatietijd van flooding applicatie 6000

Roltijd (ms)

4500

3000

1500

0

10

20

30

40

50

Aantal virtuele SPOTs 1 Communicatietijd met één computer (ms)

2 Communicatietijd met twee externe hosts (ms)

Figuur 6.5: Communicatievertragingen gemeten met de flooding applicatie.

Grafiek 1 van Figuur 6.5 laat de communicatievertragingen van de flooding applicatie zien. De grafiek vertoont dezelfde supralineaire groei als Figuur 6.4. Hieruit kan worden geconcludeerd dat de communicatie tussen SPOTs de oorzaak is van de hoge processorbelasting en de vertragingen. Om de invloed van het gebruik van externe hosts op de communicatievertragingen te bepalen is het experiment met de flooding applicatie nogmaals uitgevoerd. Dit keer met twee externe hosts waarbij op elke host één virtuele SPOT wordt gedraaid. Schematisch ziet het er als volgt uit:

vSpot 1

vSpot 2

...

vSpot n-2

pc1

vSpot n-1

vSpot n

pc2

pc3

Figuur 6.6: Schematische weergave van de SPOT opstelling met twee SPOTs op externe hosts.

De resultaten zijn uitgedrukt met Grafiek 2 van van Figuur 6.5. Bij het gebruik van 10 SPOTs is de communicatietijd iets langer ten opzichte van hetzelfde experiment zonder externe hosts. Het gebruik van externe hosts introduceert een minimale extra vertraging. Naarmate het aantal SPOTs groeit, neemt de totale communicatietijd toe. De invloed van de twee SPOTs op externe hosts neemt daardoor af. Vanaf ongeveer 15 SPOTs is de communicatietijd met het gebruik van externe hosts zelfs korter dan de communicatietijd zonder externe hosts. De distributie van SPOT processen zorgt ervoor dat de processor van pc1 wordt ontlast waardoor de communicatie tussen SPOTs sneller verloopt. Uit de experimenten kan worden geconcludeerd dat communicatie tussen SPOTs zorgt voor een zekere processorbelasting. Dit resulteert in communicatievertragingen tussen SPOTs. Voor een realistische simulatie is het van belang dat deze communicatievertragingen overeenkomen met de communicatievertragingen bij echte SPOTs. Deze vergelijking valt echter buiten de scope van mijn onderzoek. 34

35

7 Toekomstig werk Het framework biedt momenteel de elementaire componenten die nodig zijn om SPOT applicaties op test gedreven wijze te ontwikkelen. Het framework biedt nog veel uitbreidingsmogelijkheden waardoor simulaties realistischer worden en het eenvoudiger wordt om testen uit te voeren. Het framework biedt realistische communicatie in de vorm multihop communicatie. Aspecten als signaalsterkte en packet-loss worden niet geëmuleerd, terwijl deze wel in een groot aantal sensornetwerk simulators aanwezig zijn. Het implementeren van deze aspecten vormt een uitdagende opdracht. De emulator van de Sun SPOT moet daarvoor worden gemodificeerd en er moet rekening worden gehouden met een groot aantal factoren die bij draadloze communicatie een rol spelen. Daarvoor kunnen mogelijk bestaande modellen van de IEEE 802.15.4 [22] standaard worden gebruikt. Het framework maakt gebruik van de Solarium grafische gebruikersinterface om virtuele SPOTs op het scherm te tonen. Dezelfde gebruikersinterface kan op redelijk eenvoudige wijze worden gebruikt om aanvullende simulatie informatie op het scherm te tonen. Interessante uitbreidingen zijn: • Virtuele SPOTs structureren op basis van netwerktopologie of fysieke locatie. • Netwerktopologie visueel weergeven tussen virtuele SPOTs. • Draadloze communicatie zichtbaar maken tussen virtuele SPOTs.

Het framework levert de elementaire componenten die nodig zijn om testen te schrijven en te valideren. De testen zelf moeten volledig door de gebruiker worden geprogrammeerd wat een tijdrovend proces is. Het schrijven van testen kan worden vereenvoudigd door het framework te combineren met een test framework. Het test framework levert dan bepaalde functionaliteiten waarmee het eenvoudiger wordt om testen te schrijven.

36

37

8 Conclusie Het Sun SPOT platform bood te weinig mogelijkheden om SPOTs te simuleren. Hierdoor was het onmogelijk om SPOT applicaties op test gedreven wijze te ontwikkelen. Het gepresenteerde SpotSim framework biedt wel genoeg mogelijkheden om SPOTs te simuleren waardoor het nu mogelijk is om SPOT applicaties op test gedreven wijze te ontwikkelen. Het framework is gebaseerd op het UPVN concept. Hierdoor is het mogelijk om vanuit een scenario programma het netwerk te configureren en het sensornetwerk te laten reageren op een bepaald scenario. Met behulp van virtuele netwerkelementen (VNE’s) is het mogelijk om de response van het sensornetwerk op te vangen. Door een scenario uit te voeren en bijbehorende response te valideren is het mogelijk om testen op het sensornetwerk uit te voeren. De gepresenteerde implementatie, die is gebaseerd op de Solarium applicatie, toont aan dat het framework werkt en dat de gewenste elementaire componenten worden geleverd. Deze elementaire componenten kunnen worden gebruikt om een uitgebreider framework te realiseren waarmee het bijvoorbeeld eenvoudiger wordt om testen te schrijven. Het werk dat in deze scriptie werd besproken is uniek en heeft nieuwe mogelijkheden ge¨ıntroduceerd. Dit heeft onder andere geresulteerd in de ontdekking van een multihop bug in de SPOT bibliotheek. Daarnaast hebben Hanze Institute of Technology [23] en de Universiteit van Antwerpen (Bijlage B) interesse getoond in mijn werk. Docenten van de Universiteit van Antwerpen hebben een presentatie over het werk bijgewoond en hebben enthousiast gereageerd. Studenten aan de Universiteit van Antwerpen gaan het framework doorontwikkelen om bijvoorbeeld emulatie van signaalsterkte en packet-loss mogelijk te maken.

38

39

Lijst met afkortingen AC

Applicatiecomponent

AODV Ad hoc On-Demand Distance Vector Routing API

Application Programming Interface

GB

Gigabyte

Ghz

Gigahertz

GP

Genetic Programming

GUI

Graphical User Interface

IPC

Interprocescommunicatie

JAR

Java ARchive

LED

Light-Emitting Diode

MAC Media Access Control MB

Megabyte

NC

Netwerkcomponent

NE

Netwerkelement

RPC

Remote Procedure Calls

RPM

Omwentelingen per minuut

SENSE SEnsor Network Simulator and Emulator SPOT Sun Small Programmable Object Technology TDD

Test-Driven Development

UPVN User Programmable Virtualized Network USB

Universal Serial Bus

VM

Virtuele Machine

VNE

Virtueel Netwerkelement

vSpot Virtuele SPOT WSN

Wireless sensor network

40

41

A SPOT Bounce demo code Listing A.1: Code van het SPOT Bounce scenario (SpotSimScenario.java) 1 2 3 4 5 6 7

/* * Project: SpotSim for Sun SPOT Solarium * Description: Simulation framework for Sun SPOT Solarium * * @author Nick Dijkshoorn, Universiteit van Amsterdam * @license: The source code is released under the GNU GPL version 2 */

8 9

public class SpotSimScenario {

10 11 12 13

private static SpotSimScenario scenarioInstance; private static SpotSim sim; public static SpotSimNode nodes[] = new SpotSimNode[3];

14 15 16 17 18 19 20

public SpotSimScenario () { if (scenarioInstance != null) { throw new RuntimeException("SpotSim: There already is a SpotSimScenario instance"); } scenarioInstance = this; this.sim = SpotSim.getInstance ();

21

init (); /* initialiseer scenario instellingen */ run (); /* scenario uitvoeren */

22 23 24

}

25 26 27

private void init () { sim.buildSuiteOnce (true); /* applicatie SUITE eenmalig genereren */

28

/* SPOT Bounce applicatie gebruiken op de virtuele SPOTs */ sim.setJarFile ("Demos/BounceDemo/BounceDemo-OnSPOT/suite/eSPOT Bounce Demo-OnSPOT_1.0.0.jar"); sim.setMidlet ("org.sunspotworld.demo.SPOTBounce");

29 30 31 32

}

33 34 35 36 37

private void run () { /* 3 virtuele SPOTs toevoegen */ for (int i = 0; i < 3; i++) { nodes[i] = new SpotSimNode (); /* virtuele SPOT toevoegen */

38

if (i > 0) nodes[i].connectedWith (nodes[i - 1]); /* lijn topologie vormen */

39 40 41

}

42 43 44 45

/* verbind eerste met tweede SPOT door op de switches te drukken */ nodes[0].pressSwitch (1); nodes[1].pressSwitch (0);

46 47

wait (1000); /* wacht een seconde en laat de verbinding tot stand komen */

48 49 50 51

/* verbind tweede met derde SPOT door op de switches te drukken */ nodes[2].pressSwitch (0); nodes[1].pressSwitch (1);

52 53 54 55

boolean dir = false; /* zet de richting naar links */ double accel = 0.0; /* declareer acceleratie variabele */ boolean testSucces = true; /* resultaat van de test */

56 57 58 59 60 61

while (true) { /* blijft de bewegingen herhalen */ if (!dir) accel = -0.1; /* acceleratie naar links */ else accel = 0.1; /* acceleratie naar rechts */

62 63

for (int i = 0; i < 3; i++) { /* sensor waarde voor alle SPOTs instellen */

42

nodes[i].resetBallTest (dir); // reset test voor elke SPOT

64 65

nodes[i].setAccelerometer (accel, 0.0, 0.0); /* stel de acceleratie sensor waarde in */

66

}

67 68

wait (5000); /* laat een beweging 5 seconden duren */

69 70

testSucces = testResultsAllNodes (); // test result ophalen System.out.println (" - result: " + testSucces + "\n");

71 72 73

dir = !dir; /* draai de acceleratie richting om */

74

}

75

}

76 77 78

public boolean testResultsAllNodes () { boolean testSucces = true;

79 80 81

for (int i = 0; i < x; i++) { /* test resultaat voor elke SPOT ophalen */ if (!nodes[i].BallTestPassed ()) testSucces = false; }

82 83 84 85 86

return (testSucces);

87

}

88 89 90

public void wait (int time) { try { Thread.sleep (time); } catch (InterruptedException e) { } }

91 92 93 94 95 96

}

Listing A.2: Code van het SPOT Bounce scenario (SpotSimNode.java) 1 2 3 4 5 6 7

/* * Project: SpotSim for Sun SPOT Solarium * Description: Simulation framework for Sun SPOT Solarium * * @author Nick Dijkshoorn, Universiteit van Amsterdam * @license: The source code is released under the GNU GPL version 2 */

8 9

public class SpotSimNode {

10 11 12 13

private SpotSim sim; private EmulatedSunSPOT spot; private String address;

14 15 16 17 18 19

/* test variables */ boolean testComplete boolean testFailed boolean ballDirection int ledPosition =

= false; = false; = false; // right to left 7;

20 21 22 23 24 25 26 27

/* Public methods */ public SpotSimNode () { sim = SpotSim.getInstance (); spot = sim.addNode (this); address = spot.getAddress ().toUpperCase (); }

28 29 30 31 32 33

/* test methods */ public void handleLED (int index, int color) { if (testComplete || testFailed) /* test completed or failed: nothing to do */ return;

34 35 36 37

if (!ballDirection) { /* ball from right to left */ if (index == ledPosition || index == ledPosition-1) { ledPosition = index;

38 39

if (index == 1)

43

testComplete = true;

40

}

41 42

} else if (ballDirection && index == ledPosition+1) { /* ball from left to right */ if (index == ledPosition || index == ledPosition+1) { ledPosition = index;

43 44 45 46

if (index == 7) testComplete = true;

47 48

}

49

}

50

}

51 52

public void resetBallTest (boolean direction) { testComplete = false; testFailed = false;

53 54 55 56

ballDirection = direction;

57 58

if (!direction) ledPosition = 7; else ledPosition = 0;

59 60 61 62

}

63 64

public boolean BallTestPassed () { return (testComplete && !testFailed); }

65 66 67 68

}

44

45

B E-mail van de Universiteit van Antwerpen Beste, Wij vermoeden dat u de auteur bent van https://www.sunspotworld.com/forums/viewtopic.php?f=38&t=2466 en wij hebben interesse in wat u daar post. Wij zijn namelijk onderzoekers van de Universiteit Antwerpen die werken met SunSPOTs voor netwerk onderzoek en lesgeven. Nu hadden we een eindwerk in gedachten dat ook rond het simuleren van multihop omgevingen in Solarium draait, en we vragen ons af in hoeverre dat verschilt van uw werk. We willen vermijden dat onze studenten hetzelfde doen als u, dubbel werk proberen we te vermijden want dat is nooit interessant. Is het mogelijk om uw eindwerk meer te beschrijven? Hoe specificeert u bijvoorbeeld multihop netwerken? Welk deel van de SunSPOT code past u aan zodat SPOTs denken dat zij in een multihop omgeving werken? Indien u de opgave van uw eindwerk in digitale vorm heeft dan mag u dat ook sturen, dat is misschien sneller. Mvg, Bart Braem en Kurt Smolderen – Bart Braem PATS research group - IBBT Dept. of Mathematics and Computer Sciences University of Antwerp Campus Middelheim, G3.27 Middelheimlaan 1 B-2020 Antwerpen, Belgium Phone: +32 (0)3 265.38.82 Fax: +32 (0)3 265.37.77 Web: www.pats.ua.ac.be

46

47

Bibliografie [1] Chee-yee Chong, S. P. Kumar, ”Sensor networks: evolution, opportunities, and challenges”, Proc IEEE, August 2003 [2] Laurie Williams, E. Michael Maximilien, Mladen Vouk, ”Test-Driven Development as a DefectReduction Practice”, IBM Corporation en North Carolina State University, 2003 [3] Harvard Sensor Networks Lab: Vulcano monitoring, Matt Welsh, Harvard University, 2006, http://fiji.eecs.harvard.edu/Volcano [4] Sun SPOT World, 1 August 2009 http://www.sunspotworld.com [5] Erdogmus, H., Morisio, M., Torchiano, M., ”On the Effectiveness of Test-first Approach to Programming”, Software Engineering, IEEE Transactions on Volume 31, Issue 3, March 2005 Page(s): 226 - 237 [6] Wikipedia.org: List of unit testing frameworks, 1 August 2009 http://en.wikipedia.org/ wiki/List_of_unit_testing_frameworks [7] Sun Microsystems: The Squawk Project, 1 August 2009 http://research.sun.com/ projects/squawk/ [8] Lei Shu, Chun Wu, Yan Zhang, Jiming Chen, Lei Wang, Manfred Hauswirth, ”NetTopo: Beyond simulator and Visualizer for Wireless Sensor Networks”, ACM SIGBED Review, Volume 5, Issue 3, October 2008 [9] Fekete, S.P., Kroller, A., Fischer, S., Pfisterer, D., ”Shawn: The fast, highly customizable sensor network simulator”, Networked Sensing Systems, 2007, INSS apos; 07, Fourth International Conference on Volume, Issue, 6-8 June 2007 Page(s): 299 - 299 [10] Gilbert Chen, Joel Branch, Michael J. Pug, Lijuan Zhu, and Boleslaw, K. Szymanski, ”Sense: A Wireless Sensor Network Simulator”, Advances in Pervasive Computing and Networking, Springer US, 2005, Page(s): 249-267 [11] A. Sobeih, J.C. Hou, Lu-Chuan Kung, Ning Li, Honghai Zhang, Wei-Peng Chen, Hung-Ying Tyan, Hyuk Lim ”J-Sim: A Simulation and Emulation Environment for Wireless Sensor Networks”, Wireless Communications, IEEE, Volume: 13, Issue 4, August 2006, Page(s): 104-119 [12] Rudolf J. Strijkers, ”The Network is in the Computer”, University of Amsterdam, March 2007 [13] J-Sim: Component-port model, 1 August 2009, http://www.j-sim.org/whitepapers/ aca.html [14] IEEE standards: GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY, 1 August 2009, http://standards.ieee.org/regauth/oui/ tutorials/EUI64.html [15] Sun SPOT World Discussions, ”Possible multihop bug when packet hop count > 14”, 1 August 2009, https://www.sunspotworld.com/forums/viewtopic.php?f=38&t=2466 [16] Roberto Canonico, Pasquale Di Gennaro, Vittorio Manetti, Giorgio Ventre, ”On Node Virtualization for Scalable Network Emulation”, Virtualization Techniques in Network Emulation Systems, Springer Berlin / Heidelberg, March 2008, Page(s): 144-153 48

[17] Using the SPOT Emulator in Solarium, June 2008, https://www.sunspotworld.com/ docs/Blue/SunSPOT-Emulator.pdf [18] Nan C. Schaller, Michael Berman, Judith Bishop, Paddy Nixon, Evelyn Rozanski, Peter Welch, ”Panel Report: Using Java in Computer Science Education”, Annual Joint Conference Integrating Technology into Computer Science Education, Proceedings of the 2nd conference on Integrating technology into computer science education, 1997, Page(s): 140-142 [19] Master course Network Programming, in block 1 of semester 2 of the Master Computer Science at the University of Amsterdam, 1 August 2009, http://staff.science.uva.nl/ ˜rjstrijk/Teaching.html [20] Portland College: Lab 1: Becoming familiar with the Java-programmable Sun SPOT technology, 1 August 2009, http://web.pdx.edu/˜damont/labs/SPOT_lab1.htm [21] C. Perkins, E. Belding-Royer, S. Das, ”Ad hoc On-Demand Distance Vector (AODV) Routing”, Nokia Research Center, University of California, Santa Barbara, University of Cincinnati, July 2003, http://www.ietf.org/rfc/rfc3561.txt [22] Wikipedia.org: IEEE 802.15.4-2006, 1 August 2009, http://en.wikipedia.org/wiki/ IEEE_802.15.4-2006 [23] Hanze Institute of Technology (Hanzehogeschool), http://hit.hanze.nl [24] Mathematica, http://www.wolfram.com

49

SpotSim: Test gedreven ontwikkeling van sensornetwerk applicaties

Recommend Documents