Bachelor Thesis: Bachelor of Computer Science

Supervisors: Rudolf J. Strijkers, Robert J. Meijer, Dick van Albada

Signed:

SpotSim: Test gedreven ontwikkeling van sensornetwerk applicaties

Nick Dijkshoorn (ndijksho@science.uva.nl)

17 augustus 2009 (herziene versie)

Samenvatting

Deze scriptie is een studie naar het test gedreven ontwikkelen van sensornetwerk applicaties. Erwordt verkend wat test gedreven ontwikkeling inhoudt en hoe deze techniek kan worden gebruiktom de kwaliteit van sensornetwerk applicaties te verbeteren. Daarvoor worden een aantal testmethodieken onder de loep genomen, zoals JUnit en simulatie. Daarnaast beschrijft deze scriptieeen Java framework dat test gedreven ontwikkeling van sensornetwerk applicaties voor de Sun SPOTomgeving mogelijk maakt.

Inhoudsopgave

1 Introductie 31.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Test gedreven ontwikkeling 72.1 Test gedreven ontwikkeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Cyclus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Soorten testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Test gedreven ontwikkeling voor sensornetwerken . . . . . . . . . . . . . . . . . . . . 102.2.1 State of the art sensornetwerk simulators . . . . . . . . . . . . . . . . . . . . 10

3 Sun SPOT 123.1 Functionaliteiten van Solarium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Architectuur van Solarium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Solarium designkeuzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 SpotSim simulator voor Sun SPOT 164.1 Gewenste functionaliteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Implementatie van het framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Problemen en oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4.1 Bug in de multihop code van de SPOT bibliotheek . . . . . . . . . . . . . . . 224.4.2 Initialisatietijd per SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 SpotSim toepassingen 255.1 Sun SPOT in het onderwijs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2 Implementeren van proofs of concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 SPOT Bounce demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Kwantitatieve analyse 296.1 Resource gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2 Communicatievertragingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Doorsensoren te voorzien van reken- en communicatiemogelijkheden, wordt het mogelijk om de reelewereld te koppelen aan een computersysteem. De nuttige toepassingen zijn legio, bijvoorbeeld hetmonitoren van fysieke- of omgevingsfactoren. Draadloze sensornetwerken worden geıntegreerd in debestaande computerinfrastructuur om eindgebruikerapplicaties mogelijk te maken. Deze applicatiescommuniceren met de software op een of meerdere sensornetwerken om gebruik te maken van dediensten 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 varieren van die van een zandkorreltot die van een schoenendoos. Het aantal sensorknopen in een draadloos sensornetwerk kan gaanvan 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 technologieen 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 ondanksde schaal toch efficient kunnen functioneren.

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

1.1 Probleemstelling

Aan de Universiteit van Amsterdam wordt onderzoek gedaan op het gebied van sensornetwerkenmet behulp van Sun SPOT [4] (Sun Small Programmable Object Technology), een draadloze sensor-netwerk platform ontwikkeld bij Sun Microsystems. De Universiteit van Amsterdam heeft voor ditplatform gekozen omdat het de mogelijkheid biedt om het netwerk te programmeren. Hierdoor ishet 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 omSPOT applicaties op een desktop computer te kunnen draaien. Hierdoor is het mogelijk om SPOTapplicaties eenvoudig te testen zonder de hardware zelf of scenario’s te testen die in de echte wereldlastig zijn te beheersen.

De mogelijkheden van Solarium zijn echter te beperkt om SPOT applicaties op realistische wijze meete testen. Het nabootsen van realistische scenario’s vereist een hoop handelingen en is te complexom handmatig uit te voeren. Momenteel is het met Solarium alleen mogelijk om handmatig vir-tuele SPOTs te instantieren, te configureren en sensorwaarden in te voeren. Daardoor is Solariumniet in staat om realistische scenario’s na te bootsen. Verder is de communicatie tussen virtueleSPOTs beperkt tot single-hop: alle virtuele SPOTs kunnen met elkaar communiceren en kennengeen (dynamische) netwerktopologie. Dit terwijl een dynamische netwerktopologie juist een pro-minent kenmerk is van sensornetwerken. Multihop communicatieprotocollen vormen daarom eenbelangrijk onderzoeksgebied van sensornetwerken, maar kunnen niet worden getest met Solarium.De simulatiemogelijkheden voor het SPOT platform zijn dus te beperkt om SPOT applicaties optest gedreven wijze te ontwikkelen.

1.2 Doelstellingen

Het doel van dit onderzoek is om een simulatie framework voor het Sun SPOT platform te ont-wikkelen. Met behulp van dit framework kunnen de sensoren vanuit een applicatie worden ge-programmeerd en wordt multihop communicatie mogelijk gemaakt. Het framework zorgt ervoor

5

dat de tekortkomingen van Solarium worden opgeheven waardoor het mogelijk wordt om het SunSPOT platform te gebruiken voor test gedreven ontwikkeling van sensornetwerk applicaties. Multi-hop communicatieprotocollen zijn hierin een belangrijk test onderdeel. Bij het ontwikkelen van eensoftware architectuur moet er rekening worden gehouden met het eenvoudig kunnen uitbreiden enimplementeren 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 wordtontwikkeld door het schrijven van testen. Dit leidt tot een hogere productiviteit en kwaliteit [5]. Detechniek maakt gebruik van korte ontwikkel-iteraties die zijn gebaseerd op vooraf geschreven testen.Deze testen definieren nieuwe functionaliteiten of gewenste verbeteringen. Elke iteratie produceertde code die nodig is om de testen van die iteratie te laten slagen. Uiteindelijk herstructureert deprogrammeur de code zonder de werking ervan te veranderen. Een belangrijk TDD sleutelconceptis dat de testen worden opgesteld voordat de code wordt geschreven. Hierdoor wordt er tijdens hetschrijven van de programmacode al feedback verkregen.

2.1.1 Cyclus

Test(en) toevoegen

Testenuitvoeren

Kleine aanpassing

Testen uitvoeren

Code opschonen

ontwikkeling gaat verder

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

1. Test(en) toevoegenIn 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 isgeımplementeerd. Om een test te schrijven moet de ontwikkelaar de specificaties en eisen vande te ontwikkelen software goed begrijpen.

2. Alle testen uitvoeren en controleer of nieuwe testen falenDeze stap valideert of de testen correct werken en of nieuwe testen falen. Nieuwe testen moetennamelijk falen zolang er nog geen nieuwe code is geschreven, er is immers nog geen code omde test te laten slagen.

3. Code schrijvenIn deze stap wordt nieuwe code geschreven met als doel de test te laten slagen. De nieuwecode hoeft in deze stap nog niet perfect te zijn, zolang de test maar slaagt. Dit is acceptabelomdat de code later wordt opgeschoond. Het is wel belangrijk dat de nieuwe code alleen alsdoel heeft om de test te laten slagen. Verdere (en niet-geteste) functionaliteiten mogen nietworden voorspeld en zijn dus niet toegestaan.

8

4. Voer het geautomatiseerd testen uit en controleer of alle testen slagenAls alle testen slagen is de programmeur verzekerd dat de code aan de geteste eisen voldoet.

5. Code opschonenNu kan de code worden opgeschoond. Door de testen opnieuw uit te voeren is de ontwikkelaarverzekerd dat het opschonen van de code geen functionaliteiten heeft beschadigd. Het verwij-deren van duplicaties is een belangrijk aspect van software design. In dit geval is dit ook vantoepassing op het verwijderen van duplicaties tussen de testcode en de programmacode.

6. HerhalenDe 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 soorttest wordt in een bepaalde fase van het ontwikkelproces toegepast.

1. UnittestenEen 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 stukjescode (units) afzonderlijk te testen op een correcte werking. Bij unittesten zal voor iedere uniteen test ontwikkeld worden, een unittest. Deze testen bevatten beweringen (assertions) diewaar of onwaar zijn. De Unit Testen worden geautomatiseerd uitgevoerd en blijven gedurendehet hele ontwikkelproces bestaan. Dit betekent dat na aanpassingen van de code alle testennog moeten werken. Doordat alle testen iedere keer worden uitgevoerd, worden functionelewijzigingen direct opgemerkt.

Om Unit Testen te definieren en op geautomatiseerd wijze uit te voeren is een zogenaamd xUnitframework vereist. Er zijn verscheidene xUnit frameworks beschikbaar waarbij elk frameworkop een specifieke programmeertaal is gericht. Op Wikipedia is een uitgebreide lijst met dezeframeworks te vinden [6].

2. IntegratietestenNa het unittesten volgt het integratietesten. Daarbij worden individuele softwarecomponententot een groep gecombineerd en getest. Het doel van integratietesten is om te controleren of aande functionele, prestatie en betrouwbaarheidseisen van de groepen wordt voldaan. De testenzijn zo geconstrueerd dat kan worden bepaald of alle componenten binnen de groep op de juistewijze met elkaar interacteren. Via de interfaces worden passende parameters en invoerdataaan de groepen aangeboden.

3. SysteemtestenNa het integratietesten volgt het systeemtesten. De groepen van de integratietesten wordengecombineerd tot een geheel systeem en vervolgens als geheel getest. Daarbij wordt getest opgebreken tussen zowel gekoppelde groepen alsmede het gehele systeem. Systeemtesten wordendoor middel van blackboxtesten getest. Voor deze testmethode is geen kennis van het designof de onderliggende code vereist.

4. Systeem integratietestenNa het uitvoeren van systeemtesten kunnen systeem integratietesten worden uitgevoerd. Daar-bij 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 wordentoegepast. De eigenschappen van sensornetwerken zorgen er voor dat het testen van sensornetwerkapplicaties complexer is dan het testen van reguliere applicaties.

De beperkte hulpbronnen van sensorknopen zorgen ervoor dat reguliere programmeertalen en mo-dellen slecht bruikbaar zijn voor sensornetwerken. Daarom zijn er nieuwe programmeertalen en mo-dellen specifiek voor sensornetwerken ontwikkeld. De reguliere xUnit test frameworks zijn daaromonbruikbaar voor de meeste sensornetwerken. Daarnaast speelt de interactie tussen sensorknopeneen belangrijke rol binnen sensornetwerken. Om het gedrag van een sensornetwerk applicatie tetesten is het juist belangrijk om de interactie tussen sensorknopen te testen.

De meest gebruikte testplatformen voor de ontwikkeling van sensornetwerken zijn daarom sensor-netwerk simulators en sensornetwerk testbedden. Het gebruik van een echte sensornetwerk testbedbiedt de meest realistische testomgeving waardoor er nauwkeurige testresultaten kunnen wordenverzameld. Er kleven echter twee serieuze beperkingen aan deze aanpak. Ten eerste brengt de groteschaal van een testbed hoge kosten met zich mee, die voor academici vaak onacceptabel zijn. Tentweede is het met een testbed lastig om een reproduceerbare omgeving te creeren. Voor sommigetoepassingen, bijvoorbeeld het monitoren van een vulkaanuitbarsting, is het gebruik van een testbedongewenst omdat er schade aan de apparatuur kan ontstaan. Voor het gebruik van een sensornetwerksimulator gelden deze beperkingen niet. Sensornetwerk simulators imiteren echte sensornetwerkendoor middel van een computerprogramma. Om de werkelijkheid na te bootsen worden vereenvou-digde modellen van de werkelijkheid gebruikt. Daardoor is simulatie minder volledig en nauwkeurigdan 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 simu-lators zijn gebaseerd op reguliere (netwerk) simulators, anderen zijn volledig opnieuw opgebouwd.De doelstellingen van de sensornetwerk simulators lopen behoorlijk uiteen. Sommige simulators pro-beren een sensornetwerk op een zo laag mogelijk niveau te imiteren om een zo realistisch mogelijkesimulatie mogelijk te maken. Andere simulators, waaronder SHAWN [9], imiteren een sensornetwerkop 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 sensor-netwerk applicatie ook daadwerkelijk wordt getest door middel van de simulatie. De code van desensornetwerk applicatie wordt gebruikt om het gedrag van een sensorknoop te emuleren. Een ge-modificeerde versie of een formele beschrijving van de applicatie is ongeschikt omdat daarmee nietde applicatiecode zelf wordt getest. Dit is niet in overeenstemming met de gedachtegang van testgedreven ontwikkeling.

Geschikte sensornetwerk simulators kunnen in context met dit onderzoek in grofweg twee categorieenworden onderverdeeld.

1. Generieke sensornetwerk simulatorsGenerieke sensornetwerk simulators zijn niet aan een specifiek sensornetwerk platform gebon-den. Deze simulators maken gebruik van generieke modellen om het gedrag van een sen-

10

sornetwerk te beschrijven. De generieke modellen zullen afwijken van die van een specifieksensornetwerk platform waardoor de simulaties minder realistisch zullen zijn. Door middelvan uitbreidingen, vaak in de vorm van modules, kunnen platform-specifieke eigenschappenaan de simulator worden toegevoegd. De ontwikkeling van deze modules vereist kennis vanzowel de simulator als het sensornetwerk platform.

2. Platform specifieke sensornetwerk simulatorsSpecifieke sensornetwerk simulators zijn beperkt tot een bepaald sensornetwerk platform enbieden out-of-the-box de meest realistische simulatie van het specifieke platform. De imple-mentaties binnen de simulator komen overeen met de implementaties op echte sensorknopen.Deze simulators zijn beperkt tot een bepaald platform en hebben daarom vaak minder uitbrei-dingsmogelijkheden.

In state of the art sensornetwerk simulators wordt steeds vaker de component gebaseerde architec-tuur 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 hetcomponent-port model [10] [13] communiceert een component met andere componenten via inportsen 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 hetvan anderen verwacht.

Het fundamentele verschil tussen een object en een component in het component-port model is dat deinteracties 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 objectaanroepen zolang het een pointer of referentie naar dat object heeft. Dergelijke communicatie isechter niet weerspiegeld in de interface of declaratie van het object en wordt alleen zichtbaar doorde geımplementeerde code te onderzoeken. Het resulterende probleem is dat elke functie aanroepnaar een extern object een impliciete onderlinge afhankelijkheid introduceert tussen objecten. Doordeze impliciete onderlinge afhankelijkheden zijn objecten slecht herbruikbaar.

Dankzij outports onderscheiden componenten zich van objecten. Outports leggen restricties op deruntime interacties tussen componenten. Het belangrijke gevolg van outports is dat de ontwikkelingvan een onderdeel nu volledig gescheiden kan worden van de context waarin het onderdeel gebruikt zalworden. Dit leidt tot echte herbruikbare componenten. Daarnaast zijn componenten eenvoudiger uitte breiden. Elk component kan door een ander component worden vervangen, zolang de componentde benodigde functionaliteiten levert.

Vrijwel alle sensornetwerk simulators maken gebruik van discrete-event simulatie. Hierbij is de tijdopgedeeld in kleine blokjes. De toestand van het systeem wordt op basis hiervan stapsgewijs bere-kend, door middel van iteratie. De gebeurtenissen die de veranderingen van het systeem veroorzakenworden beschreven met een lijst van chronologische gebeurtenissen. Een gebeurtenis kan bijvoor-beeld 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 deechte 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 sensor-netwerk technologie. Sun SPOT bestaat uit een combinatie van hardware en software dat bij SunMicrosystems is ontwikkeld. Sun SPOT onderscheidt zich van andere sensornetwerken doordat hetis gebouwd op de Squawk Java Virtual Machine [7]. Applicaties voor SPOTs worden daarom in deJava 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 denkendan toetsenbord, muis en scherm. De programma’s die ze schrijven gaan op compleet nieuwe wijzeinteractie 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 USBbasisstation worden SPOTs op draadloze wijze gedetecteerd. Alle gedetecteerde SPOTs wordenbinnen de Solarium applicatie visueel getoond middels de weergave methode naar keuze (boom-en/of rooster-weergave). Solarium biedt voor elke SPOT een aantal acties, waaronder het uploadenvan 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 desktopcomputer te draaien. Hierdoor kan een SPOT applicatie worden getest zonder het op een echteSPOT te moeten laden of zonder de hardware zelf. Anders dan discrete-event simulatoren is Solariumeen emulator, die kan worden gebruikt om een deel van de omgeving te simuleren. Binnen Solariumwordt een geemuleerde SPOT uitgedrukt als een virtuele SPOT. Elke virtuele SPOT dient handmatigdoor de gebruiker te worden aangemaakt en te worden voorzien van een SPOT applicatie. Eenvirtuele SPOT wordt dan visueel binnen Solarium weergegeven, inclusief LEDs en twee switchesdie 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 metelkaar communiceren door radioverbindingen te openen. Hiervoor kunnen broadcast en point-to-point verbindingen worden gebruikt. Deze virtuele radioverbindingen vinden plaats via reguliere enmulticast sockets. Virtuele SPOTs kunnen ook met echte SPOTs communiceren. Het basisstationfungeert dan als extra hop.

De functionaliteiten van de Solarium applicatie zijn echter te beperkt om simulaties gebaseerd opeen scenario uit te voeren. Het nabootsen van realistische scenario’s vereist een hoop handelingenen is te complex om handmatig uit te voeren. Momenteel is het met Solarium alleen mogelijk omhandmatig virtuele SPOTs te instantieren, te configureren en sensorwaarden in te voeren. Daardooris Solarium niet in staat om realistische scenario’s na te bootsen. Verder is de communicatie tussenvirtuele SPOTs beperkt tot single-hop: alle virtuele SPOTs kunnen met elkaar communiceren enkennen geen (dynamische) netwerktopologie. Dit terwijl een dynamische netwerktopologie juist eenprominent kenmerk is van sensornetwerken. Multihop communicatieprotocollen vormen daarom eenbelangrijk onderzoeksgebied van sensornetwerken, maar kunnen niet worden getest met Solarium.De simulatiemogelijkheden voor het SPOT platform zijn dus te beperkt om SPOT applicaties optest gedreven wijze te ontwikkelen.

3.2 Architectuur van Solarium

Sun SPOT is geheel open source. Echter, de architectuur van Solarium en bijbehorende emulator isamper gedocumenteerd. Ook de broncode is amper voorzien van uitleg, waardoor het onnodig lastigis om met de code aan de slag te gaan. Door de broncode te bestuderen heb ik de nodige kennisopgedaan over de architectuur van Solarium.

Solarium

vSpot 1 vSpot 2 ... vSpot n

Squawk VM

Emulator

SPOT library

User application

Squawk VM

Emulator

SPOT library

User application

Squawk VM

Emulator

SPOT library

User application

Figuur 3.2: Solarium architectuur

Binnen Solarium worden zowel echte SPOTs als virtuele SPOTs (vSpot) gerepresenteerd door eenvirtueel object. Voor elke virtuele SPOT start Solarium een nieuw proces dat verantwoordelijk isvoor de emulatie van een 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. Devirtuele machine interpreteert code en voert vervolgens de bijbehorende taken uit.

2. EmulatorDe emulator bootst de interactie met de omgeving na door gebruik te maken van een simpelmodel. Daardoor moet de gebruiker de sensorwaarden expliciet instellen.

3. SPOT libraryDe SPOT bibliotheek bevat functionaliteiten voor de SPOT.

4. User applicationDe SPOT applicatie die door de gebruiker is geschreven.

De emulator laag van elke virtuele SPOT interacteert met Solarium middels een eigen socket ver-binding (zwarte pijlen in Figuur 3.2). Over deze verbinding wordt onder andere de uitvoer vande virtuele SPOT naar Solarium gecommuniceerd. Een voorbeeld daarvan is het doorgeven aanSolarium dat de eerste LED moet gaan branden. Solarium verwerkt de ontvangen opdracht vande emulator en zorgt ervoor dat de betreffende LED binnen de GUI gaat branden. Maar Solariumstuurt ook opdrachten naar de virtuele SPOT. Dit gebeurt bijvoorbeeld als de gebruiker met demuis op een van de twee switches drukt. De emulator ontvangt van Solarium een melding dat eenswitch 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 doorsocket verbindingen met de emulator van andere virtuele SPOTs te maken (witte pijlen). Daarnaastontvangt elke emulator via een gedeeld multicast adres broadcast pakketten van andere virtueleSPOTs.

3.3 Solarium designkeuzes

Uit de architectuur van Solarium kunnen een aantal designkeuzes worden afgeleid. Het was voor mijnonderzoek interessant om deze designkeuzes te verkennen en daarmee te bepalen wat de doelstellingenvan Sun zijn geweest.

Er zijn verschillende manieren om meerdere virtuele sensorknopen op een fysieke computer te emu-leren [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 bibliotheekzonder modificaties kunnen worden gebruikt voor het emuleren van virtuele SPOTs. Daardoor le-vert deze methode transparantie met betrekking tot de software die wordt getest. Deze aanpak heeftechter ook nadelen. Elke Virtual Machine gebruikt de nodige hoeveelheid geheugen. Hierdoor is hetaantal virtuele SPOTs dat op een computer geemuleerd kan worden beperkt. Een ander nadeel isdat de performance wordt gedrukt. Elke Virtual Machine is een eigen proces. Het besturingssysteemzal door middel van context switches elk proces afwisselend toegang geven tot de processor. Dezecontext switches leveren een bepaalde overhead op.

Elke virtuele SPOT is een proces. Om de draadloze communicatie tussen virtuele SPOTs te emu-leren is er interprocescommunicatie (IPC) nodig. IPC technieken zijn grofweg te verdelen in viercategorieen: message passing, synchronisatie, shared memory en remote procedure calls (RPC). Sunheeft ervoor gekozen om IPC door middel van sockets (message passing) te implementeren. Eengroot 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 mul-ticast 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. Eenproces op computer A kan communiceren met een proces op computer B. Dit kan worden gebruiktom Solarium gedistribueerd te maken. De vraag blijft natuurlijk of Sun dit voordeel heeft latenmeewegen in hun keuze.

Het ontbreken van realistische vormen van communicatie is waarschijnlijk een afweging geweest tus-sen functionaliteiten en het tijdsbestek waarin Solarium ontwikkeld moest worden. In de Sun SPOTEmulator handleiding [17] wordt beschreven dat realistische simulatie van de draadloze radiocom-municatie wellicht een uitdagende uitbreiding voor de toekomst is.

Virtuele SPOTs worden handmatig aangemaakt en de sensorwaarden moeten handmatig door degebruiker worden ingesteld. Hierdoor wordt duidelijk dat Sun er voor heeft gekozen om Solarium terichten op kleinschalig testen van SPOT applicaties.

Uit de bovenstaande designkeuzes kan worden geconcludeerd dat de huidige versie van Solarium isontwikkeld om SPOT applicaties op kleine schaal te testen. Flexibiliteit van het programma, omhet bijvoorbeeld uit te breiden of aan te passen, speelt een belangrijke rol terwijl schaalbaarheid eenondergeschikte rol speelt.

15

4

SpotSim simulator voor Sun SPOT

Uit hoofdstuk 3 blijkt dat de Solarium applicatie te weinig functionaliteiten heeft om test gedrevenontwikkeling van SPOT applicaties mogelijk te maken. De oplossing die ik hiervoor presenteer iseen Java framework met de naam SpotSim. Dit framework breidt de functionaliteiten van Solariumuit 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 hoeftniet alles opnieuw geschreven te worden. Solarium bevat immers een solide basis die al redelijk watfunctionaliteiten bevat. Solarium is open source en heeft een heldere objectgeorienteerde structuuren 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 temaken. Realistische netwerk simulatie is een complex probleem, daarom is het framework beperkt toteen aanzet om realistische netwerk simulaties te kunnen doen. De onderstaande functionaliteitenzijn in het framework geımplementeerd. Deze functionaliteiten zijn tot stand gekomen door deliteratuurstudie 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.

– Netwerktopologieen programmeren.

• Uitvoer van de simulatie. Deze uitvoer kan onder andere worden gebruikt om testen te vali-deren.

– 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 gebruikergeschreven programma dat een bepaald scenario nabootst. De gebruiker doet dit door de sensorenvan SPOTs met behulp van een sequentieel programma te programmeren. Vanuit het scenario

16

programma kan het netwerk ook worden geprogrammeerd zodat de gewenste netwerktopologie wordtgevormd.

Het framework is gebaseerd op het algemene UPVN concept [12] waarbij er op een andere maniernaar netwerken wordt gekeken. Het doel van UPVN is om de applicatie meer controle over hetnetwerk te geven. In het UPVN concept kan de applicatie invloed uitoefenen op het netwerk doormiddel van een applicatiecomponent (AC) die draait op een netwerkelement (NE). De applicatiezal virtuele netwerkelementen (VNE’s) aanmaken en via deze virtuele netwerkelementen de echtenetwerkelementen (NE’s) besturen.

Scenario VNE

NE

AC

Applicatie

NC

VNE

NE

AC

Applicatie

NC

Om erachter te komen wat het netwerk doet in bepaalde omstandigheden

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

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 moge-lijk om het netwerk te programmeren en een netwerktopologie te vormen. Dit is een vereiste ommultihop communicatie mogelijk te maken. Het UPVN concept kan vrij eenvoudig worden toege-past op de bestaande architectuur van Solarium. Solarium maakt namelijk al gebruik van virtuelenetwerkelementen (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 denetwerkfunctionaliteiten en is dus gelijk aan een netwerkelement (NE). De SPOT bibliotheek leverthet netwerkcomponent (NC) zodat de SPOT applicatie gebruik kan maken van de functionalitei-ten 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 netwerkelemen-ten (NE’s) worden uitgeoefend. Het netwerk kan dus niet worden geprogrammeerd en er kan geennetwerktopologie worden gevormd. Door het applicatiecomponent (AC) aan de architectuur toe tevoegen kan het netwerk wel worden geprogrammeerd. Door het netwerk te programmeren kan eennetwerktopologie 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). Hetnetwerkelement (NE) levert de benodigde netwerkfunctionaliteiten zoals het verzenden en ontvangenvan pakketten. Vanuit een SPOT applicatie wordt het netwerkcomponent (NC) gebruikt om met hetnetwerkelement (NE) te communiceren. Het scenario programma kan via een virtueel netwerkele-ment (VNE) communiceren met de applicatie. Op deze wijze kan er vanuit het scenario programmamet 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 sensornet-werk applicatie uit. Een scenario probeert er achter te komen wat het netwerk doet in bepaaldeomstandigheden. Het netwerk reageert op de acties uit het scenario en weerspiegelt daarmee hetscenario. Door de weerspiegeling op te vangen (de uitvoer van de sensornetwerk applicatie) kanworden bepaald of het netwerk op de gewenste manier op een scenario reageert. Daarmee wordt testgedreven ontwikkeling van sensornetwerk applicaties mogelijk.

Deze architectuur heeft echter ook een beperking. Het is het vrijwel onmogelijk om unittesten op dekleinste softwarecomponenten uit te voeren. Door vanuit een scenario alleen de omgeving (sensorenen de netwerktopologie) te programmeren is het vrijwel onmogelijk om specifieke modulen of kleinestukjes code van de sensornetwerk applicatie afzonderlijk te testen. Deze componenten zijn namelijkniet afzonderlijk te benaderen vanuit het framework. De overige soorten testen (integratietesten,systeemtesten en systeem integratietesten) vinden plaats op een hoger abstractieniveau en zijn daar-door wel te benaderen door de omgeving te programmeren. Via de omgeving worden parameters aande sensornetwerk applicatie aangeboden. De sensoren en netwerktopologie treden op als interfacevan de sensornetwerk applicatie.

18

4.3 Implementatie van het framework

Solarium

SpotSim

vSpot 1 vSpot 2 ... vSpot n

Squawk VM

Emulator

SPOT library

User application

SpotSim

Squawk VM

Emulator

SPOT library

User application

SpotSim

Squawk VM

Emulator

SPOT library

User application

SpotSim

Multihop whitelistnnnn.nnnn.nnnn.nnnnnnnn.nnnn.nnnn.nnnn

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 centralecomponent bestaat uit een aantal Java klassen en functioneert als centrale coordinator voor Solarium.

Een virtuele SPOT wordt binnen SpotSim gerepresenteerd door een instantie van het SpotSimNodeobject. Dit object levert een interface voor een virtuele SPOT. Voor elke virtuele SPOT binnenSpotSim wordt een bijbehorende virtuele SPOT (vSpot) binnen Solarium aangemaakt. Tussenbeide virtuele SPOT objecten vindt interactie plaats. Op deze wijze kan SpotSim een virtueleSPOT binnen Solarium aansturen.

Deze aanpak brengt een groot voordeel met zich mee. Door virtuele SPOTs binnen Solarium tebehouden hoeft er maar weinig code aan het framework te worden toegevoegd, veel functionalitei-ten (sensorwaarden, communicatie met de emulator laag, etc) worden immers al aangeboden doorvSPOTs binnen Solarium. Het framework benut deze reeds bestaande functionaliteiten.

Om multihop communicatie te realiseren is de emulator uitgebreid. Binnen de emulator is eenSpotSim component toegevoegd dat fungeert als een firewall. De component bepaalt of een inkomendof uitgaand bericht (afkomstig van andere SPOTs) ontvangen of verzonden mag worden. Daarvoorgebruikt het SpotSim component een whitelist, een lijst met adressen van SPOTs waarmee eenSPOT mag communiceren. Een network topologie wordt gevormd door elke emulator van de juistewhitelist te voorzien. Figuur 3.3 zal dit verduidelijken. De centrale SpotSim component zorgt voorde distributie (pushen) van de whitelisten naar de emulators. Hiervoor maakt SpotSim gebruik vande bestaande socket verbinding (zwarte lijnen) tussen Solarium en elk SPOT proces (emulator). Deemulator 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

1 2

3

4

whitelist13

whitelist23

whitelist124

whitelist3

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 nietgecommuniceerd mag worden. Er zijn verschillende methoden om dit te realiseren. De pull-methodeis ongeschikt. Bij de pull-methode vraagt de emulator bij elk binnenkomend of uitgaand bericht aanSpotSim of dit is toegestaan. Deze methode zorgt voor vertragingen doordat er telkens toestemminggevraagd moet worden. Dit zorgt tevens voor een hoge belasting op SpotSim, zeker wanneer elkeemulator opvraagt of een binnenkomend broadcastbericht geaccepteerd moet worden.

De push-methode is een betere oplossing. Bij de push-methode stuurt SpotSim informatie naar deemulators. Op basis van deze informatie kan elke emulator bepalen of een inkomend of uitgaand be-richt wel of niet ontvangen of verzonden mag worden. Veranderingen in de netwerktopologie wordendirect naar desbetreffende emulators gesynchroniseerd waardoor de informatie in de emulators altijdup-to-date is.In de meest voorkomende sensornetwerk topologieen kan elke sensorknoop maar met een beperktaantal buren communiceren. Het aantal buren waarmee wel gecommuniceerd kan worden is daardoorveel kleiner dan het aantal buren waarmee niet gecommuniceerd kan worden. Het pushen van lijstenwaarmee wel gecommuniceerd mag worden (whitelisten) is daardoor een efficientere methode dat hetpushen van lijsten waarmee niet gecommuniceerd mag worden (blacklisten).

Gedistribueerde implementatie

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

20

Solarium

SpotSim

vSpot 1 vSpot 2 ...vSpot n

Squawk VM

Emulator

SPOT library

User application

SpotSim

SpotSimHost1 SpotSimHost2vSpot 2 vSpot n

Squawk VM

Emulator

SPOT library

User application

SpotSim

Squawk VM

Emulator

SPOT library

User application

SpotSim

pc1 pc2 pc3

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

mework.

Net als bij de niet-gedistribueerde versie van SpotSim draait er op een computer (pc1) het centralecomponent. Vanuit dit component worden alle virtuele SPOT processen, die zijn verspreid overmeerdere computers, aangestuurd. De overige computers (hosts) zijn voorzien van een SpotSimapplicatie met de naam SpotSimHost. Al deze hosts zijn middels een socket verbinding met decentrale SpotSim component verbonden. Deze architectuur is gebaseerde op het master-slave modelwaarbij Solarium als master optreedt. Omdat een computer een gecentraliseerde rol vervult is deimplementatie tot bepaalde hoogte schaalbaar.

De virtuele SPOT processen die normaliter op een computer draaien komen nu verspreid over meer-dere computers te draaien. SpotSim zorgt ervoor dat er een virtuele verbinding tussen Solarium enelk SPOT proces ontstaat. Dankzij deze virtuele verbinding maakt het voor Solarium geen verschilof een SPOT proces lokaal of op een andere computer draait.

De beperking in de niet-gedistribueerde versie van Solarium wordt veroorzaakt doordat het aantalSPOT processen dat op een computer kan draaien beperkt is. Deze beperking wordt niet zozeerveroorzaakt door de Solarium applicatie zelf. Het is daardoor een voor de hand liggende keuze omalleen de SPOT processen gedistribueerd te maken. Hierdoor hoeft de architectuur van Solariumniet te worden veranderd, waardoor de implementatie relatief eenvoudig is. Het introduceren vande SpotSimHost applicatie is een vereiste om de virtuele verbindingen tussen Solarium en de SPOTprocessen 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 afkomstigvan de centrale SpotSim component.

• Virtuele verbinding tussen Solarium en elk SPOT proces. Over deze verbinding worden onderandere sensorwaarden verzonden.

Het feit dat de SPOT processen nu verspreid over meerdere computers draaien, brengt een extracomplicatie met zich mee. Om een virtuele SPOT met een andere virtuele SPOT te laten com-municeren moet bekend zijn op welke computer (ip-adres) een virtuele SPOT zich bevindt. Voorelke virtuele SPOT moet dus bepaald kunnen worden op welk ip-adres het bijbehorende procesbereikbaar 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 inSolarium. In de standaard implementatie van Solarium wordt het lokale ip-adres in de voorste 32bits geplaatst, waardoor er nog 32 bits overblijven om elke SPOT uniek te identificeren. Tijdenshet toevoegen van een nieuwe virtuele SPOT weet SpotSim al op welke computer en bijbehorendip-adres het SPOT proces komt te draaien. Deze informatie wordt aan Solarium doorgespeeld zodatniet het lokale, maar het correcte externe ip-adres in het MAC adres wordt ingekapseld. De emulatorlaag kan daardoor aan de hand van een MAC adres van een SPOT achterhalen op welk ip-adres debetreffende 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 kanworden gemonitord. Op elke computer komt een SPOT te draaien die is voorzien van de SPOTBounce demo applicatie. Deze applicatie laat een bal langs alle SPOTs rollen en zorgt er voor dater op voorspelbare wijze communicatie tussen SPOTs plaatsvindt. De packet sniffer weerspiegeldedeze voorspelbare communicatie tussen de computers en bevestigde dat de implementatie correctfunctioneerde.

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-count15 was. Dit houdt in dat pakketten die over een route van meer van 15 hops gaan niet wordenverzonden. Na enig onderzoek werd duidelijk dat de maximale hop-count kon worden opgehoogddoor de NET_DIAMETER constante in de SPOT bibliotheek aan te passen. De aanpassing resulteerdein 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 payloadvan het pakket toegevoegd. Dit ongewenste verschijnsel zorgt er onder andere voor dat ontvangenstrings onjuist worden uitgelezen. De oorzaak van dit verschijnsel ligt aan het feit dat pakkettenmet een hop-count van meer dan 14 op afwijkende wijze worden behandeld. Er wordt onder andereeen extra byte aan de pakket header toegevoegd.

22

Bovenstaande constateringen wijzen op een fout in de multihop code van de SPOT bibliotheek. Hetoplossen van deze mogelijke bug valt niet binnen de scope van dit onderzoek en is niet noodzakelijkvoor 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 Sunheeft de bug bevestigd en toegevoegd aan de Sun SPOT bug database. De ontdekking van dezemultihop bug bevestigt dat mijn onderzoek uniek is. Voorheen was het met Solarium niet mogelijkom 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 tweetaloperaties die de nodige tijd en processorcapaciteit vergen. De applicatie voor op de SPOT wordtallereerst gecompileerd tot een JAR bestand. Daarna worden alle JAR bestanden (eventueel vanmeerdere programma’s) gecombineerd tot een SUITE bestand. Door meerdere SPOT programma’stot een SUITE bestand te combineren zijn de programma’s beter in staat om externe bronnen tedelen. Beide stappen worden voor elke virtuele SPOT opnieuw uitgevoerd en nemen ongeveer drieseconden in beslag.

De initialisatietijd kan drastisch worden teruggedrongen door de herhalingen van beide stappen teelimineren. De eerste stap, het compileren van een JAR bestand, kan volledig worden overgeslagendoor dit eenmalig uit te voeren. De locatie van het JAR bestand kan daarna als parameter voor deapplicatie worden gebruikt. De stap waarin het SUITE bestand wordt gegenereerd wordt eenmaliguitgevoerd. Daarna wordt hetzelfde SUITE bestand gebruikt voor alle SPOTs. Beide verbeteringenzijn in het framework geımplementeerd. De verbeterde initialisatietijd is in Figuur 4.5 weergegevenmet grafiek 2.

Originele initialisatietijd (Solarium)Verbeterde initialisatietijd (framework)

10 SP

OTS

20 SP

OTs

30 SP

OTs

Gemiddeld

WinstOrig

ineel Depl

Gemodificeer

27,5 63,1 117 69,0 0,0%8,96 17,9 30,9 19,3 72,1%

0

37,5

75

112,5

150

10 SPOTS 20 SPOTs 30 SPOTs

Initialisatietijd in secon

den

Aantal SPOTs

1

2

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

Zowel de originele als de efficientere implementatie laten een groei zien die wat sneller is dan lineairmet het aantal SPOTs. Het aanmaken van elke SPOT vereist dezelfde operaties en dus dezelfdetijd. Maar naarmate er meer SPOTs zijn toegevoegd neemt de processorbelasting toe. Daardoor iser 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 SPOTstoeneemt.

Met de Fit[] functie van Mathematica [24] zijn de volgende twee formules voor de meetresultatenopgesteld.

tSolarium = 1.95671 ∗N + 0.0637037 ∗N2 (4.1)

tframework = 0.738334 ∗N + 0.00949395 ∗N2 (4.2)

De eerste term verklaart de lineaire groei. De tweede term verklaart de additionele groei die afhan-kelijk is van de N SPOTs die reeds zijn toegevoegd (processorcapaciteit). Deze term laat zien datde initialisatietijd van het framework minder afhankelijk is van het aantal toegevoegde SPOTs danbij 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 deJava programmeertaal. De Java programmeertaal is populair in het onderwijs [18]. Daardoor ishet programmeren van Sun SPOTs relatief eenvoudig voor studenten. Dit maakt het Sun SPOTplatform interessant voor het onderwijs.

Colleges

Sun SPOTs worden reeds gebruikt voor colleges op Universiteiten [19] [20]. Door SPOT applicatieste schrijven en te testen maken studenten kennis met draadloze sensornetwerken. Het testen op echteSPOTs is niet altijd een optie. Vaak is het aantal beschikbare SPOTs beperkt en is het dus lastig omstudenten de gewenste testopstellingen te laten realiseren. Daarnaast is het met echte SPOTs lastigom een reproduceerbare omgeving te creeren. Simulatie is een beter alternatief. Door te simulerenkunnen reproduceerbare omgevingen worden gecreeerd en worden echte SPOTs overbodig.

Onderzoek

UPVN op de SPOTRobin Fidder is een student aan de Universiteit van Amsterdam die onderzoek doet met behulpvan 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 deSPOT worden beınvloed vanuit een SPOT applicatie. Hierdoor wordt het mogelijk om bijvoorbeeldroutes met daarin de warmste sensorknoop te mijden.

Door middel van experimenten wordt bepaald of de implementatie correct functioneert. Tijdensdeze experimenten is het belangrijk dat de netwerktopologie kan worden beheerst, zodat kan wordenvastgesteld of een pakket de juist route neemt. Tijdens experimenten met echte SPOTs kwam Robintot 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 SPOTste hebben. Deze invloed is groot genoeg om de netwerktopologie te laten veranderen. Daardoor kanniet 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 netwerk-topologieen door middel van simulatie. De door Robin gemodificeerde SPOT code kan rechtstreeksdoor de simulator worden gebruikt. Het ontbreken van packet-loss en signaalsterkte in de simula-tie vormt geen beperking. Deze variabele factoren zijn namelijk met echte SPOTs onmogelijk tecontroleren wat zal resulteren in een onbeheersbare testomgeving.

26

Genetische programmering van een sensornetwerk applicatieGenetische programmering (GP) is een geautomatiseerde methode om een computerprogramma temaken. Genetische programmering begint met een hoog niveau statement of probleem. Aan dehand daarvan wordt bepaald wat er gedaan moet worden. Daarna wordt er op geautomatiseerdewijze een programma gecreeerd dat het probleem zal oplossen. Door een sensornetwerk applicatiemet genetische programmering te creeren ontstaat er een interessant onderzoek. Met behulp van hetSpotSim framework kan de omgeving worden geprogrammeerd. Het genetische programma zal op deomgeving 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. Dezemethode om sensornetwerk applicaties te ontwikkelen is interessant voor complexe scenario’s waarbijhet 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 aantrekkelijkplatform om proofs of concepts mee te implementeren. Met het SpotSim framework is het mogelijkom testen op het geımplementeerde concept uit te voeren. Hiervoor is geen SPOT hardware vereistwat het platform ook financieel aantrekkelijk maakt.

5.3 SPOT Bounce demo

De SPOT Developer Kit wordt geleverd inclusief de SPOT Bounce demo applicatie. Deze demoapplicatie 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 tedemonstreren.

Een blauwe LED stelt een rollende bal voor. Deze bal reageert op de bewegingen van de SPOT. Doorde SPOT naar links te bewegen zal de bal naar links rollen en door de SPOT naar rechts te bewegenzal de bal naar rechts rollen. De bal zal standaard binnen de 8 LEDs (speelveld) blijven rollen. Opeen tweede SPOT die is voorzien van hetzelfde programma zal ook een bal worden getoond, maarin een andere kleur. De SPOTs zijn dus op de hoogte van elkaars aanwezigheid. De SPOTs kunnenworden samengevoegd tot een speelveld dat over meerdere SPOTs is verspreid. Hiervoor dient opeen switch knop van een SPOT te worden gedrukt. Een LED zal rood gaan knipperen. Nu moet erop een switch knop van een andere SPOT worden gedrukt. De SPOTs worden nu gekoppeld en demuur tussen de beide speelvelden wordt weggehaald. Dit koppelproces kan met meerdere SPOTsworden uitgevoerd waardoor een groter speelveld zal ontstaan. De ballen kunnen nu over meerdereSPOTs heen en weer bewegen.

De SPOT Bounce applicatie kan worden getest door bijvoorbeeld de volgende handelingen uit tevoeren:

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 een speelveld.

27

4. Beweeg alle SPOTs gedurende vijf seconden langzaam naar links. Alle ballen zullen nu naarlinks rollen.

5. Beweeg alle SPOTS gedurende vijf seconden langzaam naar rechts. Alle ballen zullen nu naarrechts rollen.

6. Ga naar stap 4 (herhaal het bewegen).

Bovenstaande handelingen kunnen worden vertaald in een scenario code. Daardoor kunnen dehandelingen autonoom worden uitgevoerd door het SpotSim framework. Het framework zal dus eenomgeving simuleren. Door een test te schrijven kan systematisch worden vastgesteld of de SPOTBounce applicatie op de gewenste wijze functioneert. Een voorbeeld test kan worden opgesteld doorte valideren of de bal van een kant naar de andere kant rolt en daarbij de LEDs in de juiste volgordegaan branden. De code hiervoor is uitgewerkt in Bijlage A. Een vergelijking tussen resultaat van desimulatie 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 eenaantal experimenten. Uit de resultaten kan worden geconcludeerd hoeveel virtuele SPOTs er opeen computer gesimuleerd kunnen worden. De kwantitatieve aspecten die in dit experiment wordengemeten zijn de initialisatietijd (wachttijd voordat de simulatie kan worden gevoerd), de proces-sorbelasting (%) en het geheugengebruik (MB). Deze aspecten zijn uitgezet tegenover het aantalvirtuele SPOTs dat wordt gesimuleerd.

De machine waarop de experimenten zijn uitgevoerd is een MacBook Pro met een 2,2 Ghz Core 2Duo processor, 4GB ram geheugen, 5400 RPM harde schijf en draait het Mac OS X 10.5.6 bestu-ringssysteem.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 additioneleprocessing introduceert.

0 20 60 100 120 140Fysiek geheuge

Swap geheSolarium 

765 1400 2600 3850 3990 39900 0 0 1 725 2039

37 85 94 106 80 67

0

1000

2000

3000

4000

0 20 60 100 120 140

Geheugengebruik tijdens simulatie

Geheugeng

ebruik (M

B)

Aantal virtuele SPOTs

Fysiek geheugen (MB) Swap geheugen (MB)Solarium geheugen (MB)

1

2

3

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. Ditzorgt voor een lineaire toename van het geheugengebruik. Een ander component dat bijdraagt aanhet totale geheugengebruik is het Solarium proces. Het geheugengebruik van het Solarium procesneemt licht toe naarmate het aantal gesimuleerde SPOTs hoger wordt. Dit kan worden verklaarddoordat Solarium datastructuren voor elke virtuele SPOT bijhoudt. Daarnaast zorgen de commu-nicatiestructuren 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 metelkaar kunnen communiceren doordat er sprake is van een netwerktopologie. Het werkelijke aantalcommunicatiestructuren zal daarom lager dan N2 uitvallen. Elke communicatiestructuur zal eenkleine hoeveelheid geheugen gebruiken waardoor het geheugengebruik ook zal toenemen naarmatehet aantal SPOTs toeneemt. Er kan worden geconcludeerd dat het geheugengebruik iets sneller danlineair groeit met het aantal SPOTs.

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

0 20 60 100 120 140Initialis

0 13 39 74 123 229

0

75

150

225

300

0 20 60 100 120 140

Initialisatietijd van simulatie

Initialisatietijd (s)

Aantal virtuele SPOTs

Initialisatietijd (s)1

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 perSPOT blijkt toe te nemen naarmate er meer SPOTs worden gesimuleerd. Dit kan worden verklaarddoordat de processorbelasting toeneemt naarmate het aantal virtuele SPOTs hoger wordt. Hierdoorblijft er minder rekencapaciteit over waardoor het instantieren van nieuwe SPOTs meer tijd in beslagneemt. Vanaf ongeveer 110 SPOTs neemt de initialisatietijd per SPOT explosief toe. Doordat hetfysieke geheugen rond deze grens vol is, gaat het besturingssysteem gebruik maken van swapgeheugenwaardoor de performance inzakt.

31

0 20 60 100 120 140Proces

5 12 35 52 67 80

0

20

40

60

80

0 20 60 100 120 140

Processor belasting tijdens simulatie

Processor belasting (%

)

Aantal virtuele SPOTs

Processor belasting (%)1

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 deprocessor blijft per SPOT proces vrijwel constant, dus de belasting van de processor stijgt evenredigmet het aantal SPOTs dat wordt gesimuleerd. De belasting door het Solarium proces blijft voor allegeteste aantallen SPOTs rond de 3% steken en is dus vrijwel verwaarloosbaar.

Uit bovenstaande resultaten kan worden geconcludeerd dat het aantal SPOTs dat op een computerkan worden gesimuleerd wordt gelimiteerd door de capaciteit van de processor en de hoeveelheidfysiek geheugen. Zodra al het fysieke geheugen is gebruikt of als de processor volledig wordt belastzal de performance van de simulatie (drastisch) gaan afnemen. Er kan daarbij worden afgevraagdin hoeverre heeft het systeem waarop wordt gesimuleerd invloed heeft op de simulaties. Zolang hetsysteem de simulatie kan bijbenen zal de simulatie real-time zijn. Als dit niet het geval is, zal desimulatie afwijkingen gaan vertonen waardoor de simulatie minder nauwkeurig wordt.

Bij de gebruikte testopstelling bleek het geheugen de beperkende factor te zijn, terwijl de processornog enige marge vertoonde. Een verdubbeling van de geheugencapaciteit zal er juist voor zorgen datde processor de beperkende factor zal worden. Daarnaast kan op basis van het geringe geheugen-en processorgebruik van het Solarium proces worden geconstateerd dat de simulator de potentieheeft om veel meer SPOTs te simuleren. Deze constatering is de aanleiding geweest om het SpotSimframework gedistribueerd te maken.

6.2 Communicatievertragingen

Bovenstaande analyse geeft een indicatie van het resource gebruik van de simulator, maar verteltniks over de eventuele vertragingen in de communicatie tussen virtuele SPOTs. Mijn hypothese isdat een hogere CPU belasting zal zorgen voor een grotere communicatievertraging.

De eerder besproken SPOT Bounce demo applicatie kan worden gebruikt om communicatievertra-gingen te meten. De bal rolt van een uiterste zijde naar de andere uiterste zijde. Bij elke metinglegt de bal dus dezelfde afstand af. Deze afstand is lineair aan het aantal SPOTs. Een dubbel aantalSPOTs 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 nietconstant. Daarom heb ik een kleine modificatie in de Bounce applicatie aangebracht om de bal meteen constante snelheid te laten rollen. De roltijd is daardoor idealiter lineair aan het aantal virtueleSPOTs. Om een bal van SPOT A naar SPOT B te verplaatsen, zal communicatie tussen beideSPOTs plaatsvinden. Deze communicatie zal een vertraging (communicatievertraging) introducerenwaardoor de bal er langer over zal doen om de bestemming te bereiken. Voor N SPOTs zal N − 1keer communicatie plaatsvinden om een bal naar de andere kant te laten rollen. Hierdoor wordtN − 1 keer een communicatievertraging geıntroduceerd.

0

10000

20000

30000

40000

10 20 30 40 50

Communicatietijd van SPOT Bounce applicatie

Roltijd (m

s)

Aantal virtuele SPOTs

Roltijd van één bal (ms)Roltijd van alle ballen (ms)Roltijd van alle ballen in headless modus (ms)

1

2

3

Figuur 6.4: Communicatievertragingen gemeten met de SPOT Bounce applicatie. De bal rolt met een con-

stante snelheid van een uiterste kant naar de andere uiterste kant.

Grafiek 1 van Figuur 6.4 laat zien dat de roltijd van een bal iets sneller dan lineair groeit aan hetaantal 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 ballenworden gebruikt. Nu rollen er N ballen langs alle SPOTs waardoor de communicatievertraging N

keer worden geıntroduceerd. De communicatievertragingen spelen nu een significante rol. Daarnaastzorgt de simulatie van meerdere ballen voor een flinke processorbelasting van 100%. Daardoor gaande processen langzamer draaien waardoor ook de communicatievertragingen toenemen.

Doordat er meerdere ballen worden gesimuleerd neemt de activiteit van de grafische interface ooktoe. Om de invloed van de grafische interface op de vertragingen vast te stellen is het experimentmet meerdere ballen ook zonder grafische interface (headless modus) uitgevoerd. Deze modus kanworden geactiveerd door Solarium met het -headless argument te starten. Solarium maakt dangeen instantie van de grafische interface aan. Grafiek 3 van Figuur 6.4 geeft de resultaten van ditexperiment in headless modus aan. Hieruit blijkt dat de grafische interface ook een zekere vertragingintroduceert.

De hoge processorbelasting wordt veroorzaakt door de SPOT processen. Om te bepalen of dezebelasting wordt veroorzaakt door communicatie (emulator) of door een aspect van de Bounce ap-plicatie 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.

0

1500

3000

4500

6000

10 20 30 40 50

Communicatietijd van flooding applicatie

Roltijd (m

s)

Aantal virtuele SPOTs

Communicatietijd met één computer (ms)Communicatietijd met twee externe hosts (ms)

1

2

Figuur 6.5: Communicatievertragingen gemeten met de flooding applicatie.

Grafiek 1 van Figuur 6.5 laat de communicatievertragingen van de flooding applicatie zien. Degrafiek vertoont dezelfde supralineaire groei als Figuur 6.4. Hieruit kan worden geconcludeerd datde 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 hetexperiment met de flooding applicatie nogmaals uitgevoerd. Dit keer met twee externe hosts waarbijop elke host een virtuele SPOT wordt gedraaid. Schematisch ziet het er als volgt uit:

vSpot 1 vSpot 2 ... vSpot n-2

pc1 pc2 pc3

vSpot n-1 vSpot n

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 isde communicatietijd iets langer ten opzichte van hetzelfde experiment zonder externe hosts. Hetgebruik van externe hosts introduceert een minimale extra vertraging. Naarmate het aantal SPOTsgroeit, neemt de totale communicatietijd toe. De invloed van de twee SPOTs op externe hostsneemt daardoor af. Vanaf ongeveer 15 SPOTs is de communicatietijd met het gebruik van externehosts zelfs korter dan de communicatietijd zonder externe hosts. De distributie van SPOT processenzorgt ervoor dat de processor van pc1 wordt ontlast waardoor de communicatie tussen SPOTs snellerverloopt.

Uit de experimenten kan worden geconcludeerd dat communicatie tussen SPOTs zorgt voor eenzekere processorbelasting. Dit resulteert in communicatievertragingen tussen SPOTs. Voor eenrealistische simulatie is het van belang dat deze communicatievertragingen overeenkomen met decommunicatievertragingen bij echte SPOTs. Deze vergelijking valt echter buiten de scope van mijnonderzoek.

34

35

7

Toekomstig werk

Het framework biedt momenteel de elementaire componenten die nodig zijn om SPOT applicatiesop test gedreven wijze te ontwikkelen. Het framework biedt nog veel uitbreidingsmogelijkhedenwaardoor simulaties realistischer worden en het eenvoudiger wordt om testen uit te voeren.

Het framework biedt realistische communicatie in de vorm multihop communicatie. Aspecten als sig-naalsterkte en packet-loss worden niet geemuleerd, terwijl deze wel in een groot aantal sensornetwerksimulators aanwezig zijn. Het implementeren van deze aspecten vormt een uitdagende opdracht. Deemulator van de Sun SPOT moet daarvoor worden gemodificeerd en er moet rekening worden gehou-den met een groot aantal factoren die bij draadloze communicatie een rol spelen. Daarvoor kunnenmogelijk bestaande modellen van de IEEE 802.15.4 [22] standaard worden gebruikt.

Het framework maakt gebruik van de Solarium grafische gebruikersinterface om virtuele SPOTs ophet scherm te tonen. Dezelfde gebruikersinterface kan op redelijk eenvoudige wijze worden gebruiktom 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 vali-deren. De testen zelf moeten volledig door de gebruiker worden geprogrammeerd wat een tijdrovendproces is. Het schrijven van testen kan worden vereenvoudigd door het framework te combinerenmet een test framework. Het test framework levert dan bepaalde functionaliteiten waarmee heteenvoudiger wordt om testen te schrijven.

36

37

8

Conclusie

Het Sun SPOT platform bood te weinig mogelijkheden om SPOTs te simuleren. Hierdoor was hetonmogelijk om SPOT applicaties op test gedreven wijze te ontwikkelen. Het gepresenteerde SpotSimframework biedt wel genoeg mogelijkheden om SPOTs te simuleren waardoor het nu mogelijk is omSPOT applicaties op test gedreven wijze te ontwikkelen.

Het framework is gebaseerd op het UPVN concept. Hierdoor is het mogelijk om vanuit een scenarioprogramma het netwerk te configureren en het sensornetwerk te laten reageren op een bepaaldscenario. Met behulp van virtuele netwerkelementen (VNE’s) is het mogelijk om de response van hetsensornetwerk op te vangen. Door een scenario uit te voeren en bijbehorende response te validerenis 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 gewensteelementaire componenten worden geleverd. Deze elementaire componenten kunnen worden gebruiktom een uitgebreider framework te realiseren waarmee het bijvoorbeeld eenvoudiger wordt om testente 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 presentatieover het werk bijgewoond en hebben enthousiast gereageerd. Studenten aan de Universiteit vanAntwerpen gaan het framework doorontwikkelen om bijvoorbeeld emulatie van signaalsterkte enpacket-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 * Project: SpotSim for Sun SPOT Solarium3 * Description: Simulation framework for Sun SPOT Solarium4 *5 * @author Nick Dijkshoorn, Universiteit van Amsterdam6 * @license: The source code is released under the GNU GPL version 27 */8

9 public class SpotSimScenario {10

11 private static SpotSimScenario scenarioInstance;12 private static SpotSim sim;13 public static SpotSimNode nodes[] = new SpotSimNode[3];14

15 public SpotSimScenario () {16 if (scenarioInstance != null) {17 throw new RuntimeException("SpotSim: There already is a SpotSimScenario instance");18 }19 scenarioInstance = this;20 this.sim = SpotSim.getInstance ();21

22 init (); /* initialiseer scenario instellingen */23 run (); /* scenario uitvoeren */24 }25

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

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

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

39 if (i > 0)40 nodes[i].connectedWith (nodes[i - 1]); /* lijn topologie vormen */41 }42

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

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

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

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

57 while (true) { /* blijft de bewegingen herhalen */58 if (!dir)59 accel = -0.1; /* acceleratie naar links */60 else61 accel = 0.1; /* acceleratie naar rechts */62

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

42

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

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

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

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

74 dir = !dir; /* draai de acceleratie richting om */75 }76 }77

78

79 public boolean testResultsAllNodes () {80 boolean testSucces = true;81

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

87 return (testSucces);88 }89

90

91 public void wait (int time) {92 try {93 Thread.sleep (time);94 } catch (InterruptedException e) { }95 }96 }

Listing A.2: Code van het SPOT Bounce scenario (SpotSimNode.java)

1 /*2 * Project: SpotSim for Sun SPOT Solarium3 * Description: Simulation framework for Sun SPOT Solarium4 *5 * @author Nick Dijkshoorn, Universiteit van Amsterdam6 * @license: The source code is released under the GNU GPL version 27 */8

9 public class SpotSimNode {10

11 private SpotSim sim;12 private EmulatedSunSPOT spot;13 private String address;14

15 /* test variables */16 boolean testComplete = false;17 boolean testFailed = false;18 boolean ballDirection = false; // right to left19 int ledPosition = 7;20

21

22 /* Public methods */23 public SpotSimNode () {24 sim = SpotSim.getInstance ();25 spot = sim.addNode (this);26 address = spot.getAddress ().toUpperCase ();27 }28

29

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

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

39 if (index == 1)

43

40 testComplete = true;41 }42

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

47 if (index == 7)48 testComplete = true;49 }50 }51 }52

53 public void resetBallTest (boolean direction) {54 testComplete = false;55 testFailed = false;56

57 ballDirection = direction;58

59 if (!direction)60 ledPosition = 7;61 else62 ledPosition = 0;63 }64

65 public boolean BallTestPassed () {66 return (testComplete && !testFailed);67 }68 }

44

45

B

E-mail van de Universiteit van Antwerpen

Beste,

Wij vermoeden dat u de auteur bent vanhttps://www.sunspotworld.com/forums/viewtopic.php?f=38&t=2466 en wij hebben interesse in watu daar post.Wij zijn namelijk onderzoekers van de Universiteit Antwerpen die werken met SunSPOTs voornetwerk onderzoek en lesgeven.

Nu hadden we een eindwerk in gedachten dat ook rond het simuleren van multihop omgevingen inSolarium draait, en we vragen ons af in hoeverre dat verschilt van uw werk. We willen vermijdendat onze studenten hetzelfde doen als u, dubbel werk proberen we te vermijden want dat is nooitinteressant.Is het mogelijk om uw eindwerk meer te beschrijven? Hoe specificeert u bijvoorbeeld multihopnetwerken? Welk deel van de SunSPOT code past u aan zodat SPOTs denken dat zij in eenmultihop omgeving werken? Indien u de opgave van uw eindwerk in digitale vorm heeft dan mag udat ook sturen, dat is misschien sneller.

Mvg,Bart Braem en Kurt Smolderen–Bart BraemPATS research group - IBBTDept. of Mathematics and Computer SciencesUniversity of AntwerpCampus Middelheim, G3.27Middelheimlaan 1B-2020 Antwerpen, BelgiumPhone: +32 (0)3 265.38.82Fax: +32 (0)3 265.37.77Web: 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 Defect-Reduction 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 toProgramming”, Software Engineering, IEEE Transactions on Volume 31, Issue 3, March 2005Page(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: Beyondsimulator 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 sensornetwork simulator”, Networked Sensing Systems, 2007, INSS apos; 07, Fourth InternationalConference 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-YingTyan, Hyuk Lim ”J-Sim: A Simulation and Emulation Environment for Wireless Sensor Net-works”, 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) REGISTRA-TION 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 August2009, https://www.sunspotworld.com/forums/viewtopic.php?f=38&t=2466

[16] Roberto Canonico, Pasquale Di Gennaro, Vittorio Manetti, Giorgio Ventre, ”On Node Virtu-alization for Scalable Network Emulation”, Virtualization Techniques in Network EmulationSystems, 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 Inte-grating Technology into Computer Science Education, Proceedings of the 2nd conference onIntegrating 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 Sci-ence 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, July2003, 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