SpotSim: Test gedreven ontwikkeling van sensornetwerk applicaties Nick Dijkshoorn (ndijksho@science.uva.nl) 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 3 1.1 Probleemstelling...................................... 5 1.2 Doelstellingen........................................ 5 2 Test gedreven ontwikkeling 7 2.1 Test gedreven ontwikkeling................................ 8 2.1.1 Cyclus........................................ 8 2.1.2 Soorten testen................................... 9 2.2 Test gedreven ontwikkeling voor sensornetwerken.................... 10 2.2.1 State of the art sensornetwerk simulators.................... 10 3 Sun SPOT 12 3.1 Functionaliteiten van Solarium.............................. 12 3.2 Architectuur van Solarium................................. 13 3.3 Solarium designkeuzes................................... 14 4 SpotSim simulator voor Sun SPOT 16 4.1 Gewenste functionaliteiten................................. 16 4.2 Beschrijving......................................... 16 4.3 Implementatie van het framework............................. 19 4.4 Problemen en oplossingen................................. 22 4.4.1 Bug in de multihop code van de SPOT bibliotheek............... 22 4.4.2 Initialisatietijd per SPOT............................. 23 5 SpotSim toepassingen 25 5.1 Sun SPOT in het onderwijs................................ 26 5.2 Implementeren van proofs of concepts.......................... 27 5.3 SPOT Bounce demo.................................... 27 6 Kwantitatieve analyse 29 6.1 Resource gebruik...................................... 30 6.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. 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 sen- 10
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 SPOT library Emulator Squawk VM User application SPOT library Emulator Squawk VM User application SPOT library Emulator 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 NC Applicatie NC Om een bepaalde handeling te verrichten en daarbij aan te passen aan de omgeving NE NE AC AC Scenario 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 SpotSim Emulator SpotSim Emulator SpotSim Multihop whitelist nnnn.nnnn.nnnn.nnnn nnnn.nnnn.nnnn.nnnn Squawk VM Squawk VM Squawk VM 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 1 2 3 whitelist 1 3 whitelist 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 SPOT library Emulator SpotSim Squawk VM User application SPOT library Emulator SpotSim Squawk VM User application SPOT library Emulator SpotSim 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. 150 Initialisatietijd in seconden 112,5 75 37,5 10 20 30 Ge Win Orig 27,5 SP 63,1 SP SP 117 69,0 mid 0,0% st inee Gem 8,96 17,9 30,9 19,3 72,1% OTS OTs OTs deld l odifi 0 Depl ceer 10 SPOTS 20 SPOTs 30 SPOTs Aantal SPOTs 1 Originele initialisatietijd (Solarium) 2 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. t Solarium = 1.95671 N + 0.0637037 N 2 (4.1) t framework = 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