Internet of Things code deployment metrics

Transcriptie

1 Internet of Things code deployment metrics Ward Schodts Xavier Goás Aguililla Abstract Wireless sensor networks zijn netwerken die bestaan uit motes: kleine, vaak van een batterij voorziene embedded apparaten uitgerust sensoren die in grote getale worden uitgezet om data over hun omgeving te vergaren waar mensen dat niet willen of kunnen. In dergelijke netwerken wordt vaak veel rekenwerk gedelegeerd aan back end computers om de rekenkracht en energievoorraad van de motes niet te taxeren. In deze paper wordt onderzocht of dit wel een goede strategie is. We stellen hiertoe een simpele vuistregel voor. Deze kan dienen om te beslissen of een bepaald stuk applicatielogica lokaal op een mote kan draaien. Dit zonder meer energie te verbruiken of een minder goede performantie te bekomen dan als het op een back end zou uitgevoerd worden. Er wordt ook een tool getoond die deze vuistregel kan toepassen. Deze gebruikt de kennis van de programmeur en een aantal basiseigenschappen van het te draaien programma om deze beslissing te maken. We geven ook een aanzet tot het breder en preciezer toepassen van de technieken waarmee de vuistregel tot stand is gekomen. 1 Situering & probleemstelling In deze sectie wordt een breder beeld gegeven van aspecten van wireless sensor networks die voor ons belangrijk zijn en wordt dieper ingegaan op de onderzoeksvraag. 1.1 Onderzoeksvraag Wireless sensor networks (kortweg WSNs) zijn netwerken bestaande uit kleine embedded apparaten (motes), die worden geplaatst op moeilijk bereikbare plekken om observaties te doen via sensoren. (Voor een breder overzicht van WSNs, zie [Akyildiz et al., 22].) Een typische mote heeft erg beperkte reken- en opslagcapaciteit, wat efficiënte multiprogrammatie verhindert. In het algemeen gaat men daarom een simpele strategie toepassen voor dataverwerking, waarbij de mote één enkele verantwoordelijkheid heeft, het zgn. sense and send. Sensordata wordt op de motes niet bewerkt, maar meteen doorgestuurd naar de back end voor verdere verwerking, waardoor de rol van de motes bij het verwerken van de data geminimaliseerd wordt. Dit is de naïefste aanpak die men kan gebruiken en steunt net op het deel van mote dat het gulzigst is met energie: de antenne. De vraag dringt zich op: is er geen manier om van de weliswaar beperkte rekenkracht van de motes gebruik te maken om efficiënter om te springen met de antenne? En is het mogelijk een simpele, algemene maatstaf te gebruiken om te beslissen of dit in een specifiek deployment scenario al dan niet kan? Energie-efficiëntie is een cruciale factor op alle niveaus bij het ontwikkelen van wireless sensor networks: een typische mote heeft geen toegang tot een onbeperkte stroombron en moet het doen met een batterij. Deze batterij kan in veel scenario s waarin WSNs worden gebruikt ook niet hernieuwd worden. Een scenario waarin deze constraint geldt, vindt men bij [Mainwaring et al., 22]: daar wordt een experiment beschreven op afgelegen vogelbroedplaatsen, waarbij motes gebruikt worden om de dieren zo weinig mogelijk te storen (batterijen gaan vervangen is dan uiteraard uit den boze). De levensduur van een mote is dus vaak afhankelijk van hoe zuinig hij omspringt met energie. Het is dan ook geen wonder dat veel research in het gebied rechtstreeks wordt beïnvloed door deze kwestie: van de ontwikkeling van besturingssystemen voor motes over netwerkprotocollen tot studies van netwerktopologieën. Daarom is het interessant om te proberen wat meer applicatielogica op de motes zelf te draaien, die dan slimmer omgaat met de data en zo probeert energie uit te sparen. Bij een eenvoudig temperatuurmetingsscenario zou men kunnen proberen om in plaats van voortdurend temperaturen door te sturen verschillende metingen te bundelen of er het gemiddelde van te nemen. Daarbij moeten we natuurlijk op onze hoede zijn dat we geen te zware berekeningen uitvoeren Het ontwikkelen van een eenvoudige metric die een programmeur toelaat om snel en efficiënt te evalueren of een bepaalde applicatie op een mote kan gedeployed worden of niet, zou interessant zijn voor het ontwikkelen van energieefficiënte IoT-systemen. Bovendien zou daarmee een waardevolle bijdrage kunnen geleverd worden aan het ontwikkelen van IoT-architecturen in het algemeen.

2 1.2 Onderzoeksopgave Een eenvoudige vuistregel, die bepaalt of een stuk applicatielogica al dan niet op een mote thuishoort en bovendien voldoet aan volgende eigenschappen: In de grote meerderheid van de gevallen een juiste beslissing maken; eenvoudig te integreren in de ontwikkelingscyclus; semi-automatisch werkt. 2 Voorgestelde oplossing De opzet is simpel: vertrek vanuit de veronderstelling dat de ontwikkelaar een stuk applicatielogica rechtstreeks op de motes wilt deployen. Vanuit deze optiek kan men abstractie maken van de low-level details van simulatie e.d. en in de plaats daarvan een eenvoudige vuistregel gebruiken (een code deployment metric). Deze geeft een makkelijke ja/neebeslissing die zegt of we kunnen deployen of niet. Beschouw een functie h (waarbij h staat voor heuristiek ) voor deze vuistregel als volgt: { 1, als C(tr(x)) C(red(x)) C(tr(red(x))) > h(x) =, in alle andere gevallen Waarbij: C de energiekostfunctie is, die de energiekost in millijoule van een operatie bepaalt; red de reductiefunctie is, die een reductie toepast op zijn input (m.a.w. zijn input transformeert van een string van n bytes naar een string van m bytes); tr de transferfunctie is, die zijn input over het netwerk verzendt. Wat deze ongelijkheid afweegt is: gegeven een reductie van de sensordata van n naar m bytes, is de som van de kost van deze reductie op een input van een bepaalde grootte en de kost van het verzenden van de output van deze reductie kleiner dan de kost van het verzenden van de originele input? De aard van deze reductie ligt niet vast. In eerste instantie zou men kunnen denken aan een louter computationeel proces dat het aantal over te dragen bytes reduceert en dan meteen overdraagt. Zo n voorbeeld is een filter: we sturen een meting pas door als die verschilt van de vorige verstuurde meting. Maar we kunnen evengoed de sensordata aggregeren in het geheugen, zodat de transferkost wanneer een meting binnenkomt nul wordt, behalve als de buffer waarin data wordt opgeslagen vol is. 1 Ook een combinatie van beide is mogelijk: men kan bijvoorbeeld de buffer comprimeren door reeksen identieke metingen samen te nemen (filter + aggregator). Dit zou theoretisch gezien een grotere winst in energie moeten opleveren. 1 Merk ook op dat de kost van het verzenden van gegevens niet lineair is er is geen garantie dat cost(trans f er(x)) + cost(trans f er(y)) = cost(trans f er(x + y)). In een keer x + y bytes versturen kan dus voordeliger uitkomen dan x en y bytes apart te verzenden. Let wel: trans f er is wel lineair in de zin dat als we de kost ervan plotten, we een rechte lijn te zien krijgen. De aandachtige lezer stelt zich meteen de vraag: hoe kan men de kost van zo n reductie in het algemeen schatten? Laat de programmeur, die zijn programma goed kent, ingrijpen. Als input voor de vuistregel is er dan niet enkel het gecompileerde programma, maar ook een aantal parameters. Deze zijn bijvoorbeeld: Sensordata. Hoe groot is de sensordata? Hoe vaak komt er sensordata binnen? Geheugenverbruik. Worden er gegevens bijgehouden in een buffer? Hoeveel? Hoe vaak wordt er naar die buffer geschreven? Nauwkeurigheid. Wat is de gewenste granulariteit van de metingen, d.w.z. hoe groot mag het interval tussen twee doorgestuurde metingen zijn? Frequentie. Hoe vaak wordt er data verzonden? Rekenkostfunctie. Hoeveel kost de reductie aan CPUtijd? Reductiefactor. Hoe sterk verkleint de reductie het aantal te verzenden bytes? 3 Methodologie De kwestie is nu om deze theorie in te vullen met empirische data: hoe berekent men de kost van het verzenden en verwerken van gegevens concreet? Men gaat dan best het kostenplaatje atomisch berekenen, door het kiezen van bepaalde kosteenheden voor de drie componenten van het energieverbruik die een programmeur kan beïnvloeden: opslag: hoeveel kost het om n bytes op te slaan in het RAM? (In heel de paper mag men geheugen interpreteren als RAM. 2 ) berekeningen: hoeveel kosten n seconden CPU-tijd? overdracht: hoeveel kost het om n bytes te verzenden; hoeveel kost het om de antenne aan en uit te zetten? Een eerste reflex is om naar de technische fiche van de motes te grijpen. Die zijn dan wel vrij betrouwbaar, maar geven metingen weer die als het ware in een vacuüm zijn gedaan: de kost van het draaien van het OS, van het op laten staan van de antenne in low power listening modus, enz. worden hierin niet meegerekend. Het is daarom beter om experimenteel uit te zoeken wat de kost is van elk van deze types operatie. 3.1 Meetopstelling en materialen Voor de metingen werd gebruik gemaakt van de AVR Zigduino. Deze werd aangesloten op een circuit met spanning 6V en stroom.4a. Op deze Zigduino draaide een kale versie van Contiki (versie 2.7, zie [Dunkels et al., 24] en De meetmethode is ontleend aan [Hughes et al., 213]. Voor het meten van het energieverbruik gedurende een bepaalde periode is gebruik gemaakt van het volgende circuit: 2 Men zou ook geneigd zijn om data op te slaan op het EEPROM. In dit onderzoek is dat echter achterwege gelaten aangezien dit een hoge kost qua energieverbruik blijkt te hebben ten opzichte van opslag in het RAM. Hetzelfde kan ook gezegd worden over oplsag naar het FLASH-geheugen.

3 / / i n i t i a l i s e e r p i n DDRE = BV ( PE6 ) ; / / p i n hoog PORTE = BV ( PE6 ) ; / / t e meten code h i e r / / p i n laag PORTE &= ( BV ( PE6 ) ) ; Figuur 3: Werken met de pin. Figuur 1: De meetopstelling De oscilloscoop meet de spanning in de circuits gaande door oscilloscoopkanalen P1 en P2. Er wordt een shuntweerstand in serie geschakeld met de stroombron van de mote (circuit aangesloten aan P1 op de oscilloscoop). Door naar de spanningsval over de weerstand te kijken, kan men de wet van Ohm gebruiken om het stroomverbruik te meten. Omdat de te meten intervallen zo klein zijn, moeten metingen met de oscilloscoop softwarematig worden gestart en gestopt. Dat wordt gedaan door middel van de digitale outputpin (D1 op de mote). Die kan men een hoog of een laag signaal (5V of V) laten uitzenden. Als een meting moet beginnen, zet men de pin op hoog, waardoor de oscilloscoop getriggerd wordt en begint met meten. Wanneer de meting moet stoppen, komt de pin terug op laag voltage, en stopt de oscilloscoop met meten. Op deze manier kan men met goede precisie meten hoeveel energie een bepaald stuk code verbruikt. Figuur 2: Output van de oscilloscoop. In het blauw: het signaal van de pin-out. In het geel: de spanningsval over de weerstand R. De punten waar de blauwe grafiek plots stijgt of daalt corresponderen aan de momenten waarop het pinoutsignaal geflipt wordt. Dit levert een CSV-bestand op dat een beschrijving geeft van de spanningsval in beide circuits gedurende een vastgelegde tijdsperiode vanaf een trigger, dat dan ingelezen en geparsed wordt. Integreren over de intervallen waar het pinoutsignaal op hoog staat, levert een nauwkeurige schatting van het stroomverbruik tijdens die intervallen. 3.2 De tool Om de toepassing van de vuistregel te vergemakkelijken, hebben we een kleine tool geschreven die toelaat om hem op efficiënte wijze toe te passen. We gaan in de volgende paragrafen wat dieper in op invoer en werking van deze tool. Input voor de tool De tool is geschreven in Python en volgt een simpel stramien: in de directory waarin het Contikiprogramma staat, moet een parameterbestand in Pythonconfiguratieformaat worden opgeslagen. Dat zal er ongeveer als volgt uitzien: sensor_data_size = <int n> sensor_data_frequency = <float f> buffer_used = <bool b> buffer_size = <int n> buffer_write_freq = <int n> [precision] interval_granularity = <float f> data_granularity = <float f> reduction_frequency = <float f> transmission_frequency = <float f> reduction_cpu_time = <int n> from = <int n> to = <int m> 3.3 Parameters schatten. Sommige van deze parameters liggen niet meteen voor de hand. Bij deze een aantal manieren die gebruikt kunnen worden om deze parameters te schatten: Kost van de reductie: CPU-tijd. Momenteel wordt er gewerkt aan een methode om bijna volledig automatisch te bepalen hoeveel CPU-tijd het uitvoeren

4 van de reductie ongeveer kost. Deze is echter nog niet volledig op punt. Een andere methode is het gebruik van een fysiek meetapparaat om op een soortgelijke wijze als bij de energiemetingen te kijken hoelang het duurt voor de reductie uitgevoerd is. Dit geeft een harde bovengrens voor de gebruikte CPU-cycli: we hoeven slechts deze tijd te vermenigvuldigen met de klokfrequentie van de CPU. Bij de Zigduino is dit 16MHz. Reductiefactor. De reductiefactor is vaak niet op het eerste zicht in te schatten. Een voorbeeld: neem dat er een temperatuur- en vochtigheidssensor aanwezig is en dat de programmeur op elk mogelijk moment wil weten of het aangenaam of niet aangenaam is waar de mote staat en die data in juist één byte past. Dan is de data met betrekking tot de temperatuur (bijv. twee bytes) en de vochtigheidsgraad (bijv. ook twee bytes) gereduceerd naar één byte. Dit kunnen we zeer gemakkelijk uitwerken. Maar als men bijvoorbeeld een filter toepast op de gegevens en enkel data verzendt wanneer een significant ander resultaat bekomen wordt dan bij de vorige meting, dan wordt de situatie complexer: dan hangt de reductiefactor af van bv. hoeveel het resultaat van de vorige metingen moet verschillen om doorgestuurd te worden, hoe vaak de temperatuur en vochtigheidsgraad schommelen op die plek (wat op zich weer afhangt van allerlei factoren in de omgeving), enzoverder. In zo n situatie is het aangewezen om een slimmere schatting te maken. Een optie is om via sense and send een steekproef te doen van de temperatuur en vochtigheidsgraad om dan hieruit af te leiden hoe sterk de temperatuur en vochtigheidsgraad zullen oscilleren. Een andere mogelijkheid is het afschatten van de reductiefactor door de worst-case reductiefactor te bekijken. Frequentie. Merk op dat in het zonet vermelde geval ook de frequentie op een gelijkaardige manier moet worden afgeleid. De frequentie waarop sensordata binnenkomt kan men makkelijk vinden, de frequentie waarmee die data verzonden wordt soms niet. Geheugenverbruik, sensoren, precisie. Deze liggen geheel in de hand van de programmeur. Er zijn echter een aantal edge cases: bijvoorbeeld, als er een combinatie van filtering en aggregatie wordt gebruikt (zie beneden); dan is het immers moeilijk op voorhand te voorspellen hoeveel geheugen zal ingenomen worden. 3.4 Een concreet stappenplan voor Contiki-programmeurs We mikken erop om het beslissingsproces zo goed mogelijk te integreren in de ontwikkelingsomgeving van Contiki. Men werkt daar voornamelijk met make-bestanden. Een typische workflow zou er als volgt moeten uitzien. 1. Schrijf het gewenste programma. 2. Maak een parameterbestand aan. Schat de parameters zoals hierboven aangegeven en verwerk ze hierin. 3. Voer het commando make eval-metric uit. Dit brengt een evaluatie van de metric op gang door middel van de gegeven parameters. 3.5 Een voorbeeldscenario: temperatuurmetingen Stel dat we een opstelling hebben waarbij de mote temperatuurmetingen moet uitvoeren. Dit gebeurt elke seconde; elke meting is twee bytes groot. De back-end hoeft echter niet in real time op de hoogte te worden gebracht van deze metingen, maar heeft genoeg aan één stuk temperatuurdata per minuut. Verschillende strategieën bieden zich aan, ze worden telkens getoond met de bijhorende parameters en voor evaluatie werd de tool gebruikt. Voor de exacte berekening hebben we onze tool gebruikt. 1. Sense and send. Van zodra een meting binnenkomt wordt hij doorgestuurd. We hanteren volgende parameters: sensor_data_size = 2 sensor_data_frequency = 6 buffer_used = False reduction_frequency = transmission_frequency = 6 reduction_cpu_time = transmit_reduction = 1 data_reduction = 1 Evaluatie metric. 1639mJ per tijdseenheid. Dit wordt gebruikt als ijkpunt voor andere strategieën. 2. Filter. Men stuurt een meting pas door als die significant verschilt van de vorige. (Wat significant verschillend inhoudt bepaalt men op voorhand.) In dit scenario gaan we ervan uit dat dit gemiddeld bij één op twee metingen gebeurt. We hanteren volgende parameters: sensor_data_size = 2 sensor_data_frequency = 6 buffer_used = True buffer_size = 1 buffer_write_frequency = 3 reduction_frequency = 6 transmission_frequency = 1 reduction_cpu_time = praktisch transmit_reduction = 2 data_reduction = 2 Evaluatie metric mJ per tijdseenheid i.p.v. 1639mJ per tijdseenheid. Beslissing: deze aanpak bespaart energie ten opzichte van de naïeve strategie. We kunnen de applicatielogica lokaal op de mote laten draaien.

5 3. Aggregator. We houden de metingen bij in een buffer en sturen elke minuut alles in één keer door. We hanteren volgende parameters: sensor_data_size = 2 sensor_data_frequency = 6 buffer_used = True buffer_size = 12 buffer_write_frequency = 6 reduction_frequency = 6 transmission_frequency = 1 reduction_cpu_time = praktisch transmit_reduction = 6 data_reduction = 1 Evaluatie metric mJ per tijdseenheid i.p.v. 1639mJ per tijdseenheid. Beslissing: deze aanpak bespaart energie ten opzichte van de naïeve strategie. We kunnen de applicatielogica lokaal op de mote laten draaien. 4. Gemiddelde. Houd de metingen bij in een buffer en bereken het gemiddelde hiervan elke minuut. We hanteren volgende parameters: sensor_data_size = 2 sensor_data_frequency = 6 buffer_used = True buffer_size = 12 buffer_write_frequency = 6 reduction_frequency = 6 transmission_frequency = 1 reduction_cpu_time = max. 12 cycli transmit_reduction = 6 data_reduction = 6 Evaluatie metric mJ per tijdseenheid i.p.v. 1639mJ per tijdseenheid. Beslissing: deze aanpak bespaart energie ten opzichte van de naïeve strategie. We kunnen de applicatielogica lokaal op de mote laten draaien. Merk op dat in veel praktische scenario s er niet de mogelijkheid bestaat om 6 keer minder vaak uit te zenden zoals hier het geval is. 4 Resultaten 4.1 Kostmetingen Voor kostmetingen werd er als volgt te werk gegaan: 1. Een ruwe meting: schrijf een programma dat beroep doet op een deel van de mote waarvan we het energieverbruik willen berekenen. Bijvoorbeeld: een pro Energie in functie van bytes 2, 4, 6, 8, Bytes Figuur 4: Energieverbruik schrijven naar RAM gramma dat herhaaldelijk bytes naar een buffer in het RAM wil schrijven. 2. De meting wordt door een speciaal script verwerkt, dat ons het stroomverbruik geeft voor de stukken afgebakende code. 3. Maak een inferentie, zodat we de atomische kost kunnen berekenen. Die extrapoleren we vervolgens. Schrijven naar RAM Schrijven naar RAM is haast gratis en is daarom een zeer goede reductiestrategie. De resultaten zijn te zien op figuur 4. De reden hiervoor is de aard van RAM. Het is volatiel geheugen, dat voortdurend moet worden gerefreshed. Schrijfoperaties worden in deze refresh-cycli geïntegreerd zodat ze haast gratis zijn. Als bewijs hiervan hebben we het energieverbruik vergeleken met dat van het in low-power listening. De vergelijking kan gezien worden op figuur 6. De x-as geeft aan hoelang dat de mote idle is of hoelang er bytes geschreven worden naar het RAM geheugen. Aan de hand van figuur 5 hebben we kunnen berekenen hoeveel bytes er in een bepaalde tijdsduur worden weggeschreven. Voor 1ms is dit ongeveer al 3 bytes. Vandaar dat, hoewel het misschien lijkt dat naar RAM schrijven een kost heeft, deze kost nooit wordt gehaald aangezien er nooit zoveel bytes ineens worden geschreven. Het grote aantal bytes dat zou geschreven worden staat op de tweede x-as bovenaan op figuur 6. Low-power listening Dit is de staat waarin de mote zich het meeste bevindt. Hier gaat hij aan 8Hz kijken of er niet gecommuniceerd moet worden met andere motes - en elke keer wordt de antenne aangezet. Om deze toestand te meten heeft men dus enkel een lege component nodig die de pin aan en uit zet op een vast interval.

6 1 3 Tijd in functie van bytes Bytes geschreven Tijd (s) , 4, 6, 8, Bytes Figuur 5: Tijdsduur schrijven naar RAM Tijd (ms) Schrijven naar RAM Idle Voor het verbruik in deze toestand werd 224.2mJ gevonden. Dit kan ook geverifieerd worden in figuur 9. Verzenden en ontvangen De kost van het verzenden en ontvangen via het netwerk is relatief groot. Dit is vooral te wijten aan het aanzetten van de antenne, dat enorm veel energie opslorpt ten opzichte van al het andere. Het eigenlijke verzenden kost ook meer dan bijv. CPU of RAM (stroomverbruik 18 á 22 ma voor verzenden vs. 13 á 2 ma voor ontvangen, zie [Atmel Corporation, 214]), maar als we de overhead van het opstarten buiten beschouwing laten, is het nog redelijk. Daardoor is het interessant om de antenne zo min mogelijk aan te zetten, en te proberen zoveel mogelijk data te bundelen voor verzending om de overhead tot een minimum te beperken. Een ander aandachtspunt is dat het niet evenveel kost om te zenden als om te ontvangen. Hierover moeten nog een aantal experimenten op punt worden gesteld. Basisverbruik Het complete basisverbruik is makkelijk te meten. De component op de mote hoeft niets doen, net zoals bij low-power listening. Het enige verschil nu is dat er expliciet moet gezegd worden dat de antenne uit staat. De metingen voor dit verbruik zijn te vinden op figuur 7. CPU-cycli Onze eerste aanpak was het gebruiken van de AVR-simulator Avrora [Titzer et al., 25] om het aantal CPU-cycli exact te meten en te vermenigvuldigen met de kost voor CPU-cycli zoals vermeld in de technische fiche. Dit is technisch echter lastiger dan het op het eerste zicht lijkt. Om dit op te lossen gebruiken we een bovengrens op de CPU kost. We gaan de uitvoertijd van de component Figuur 6: Energieverbruik idle vs. verbruik RAM meten en daarna voor de gegeven duur de maximale CPU kracht aanrekenen. Met deze bovengrens wordt er nooit te weinig energie aangerekend, maar ook niet excessief veel. Dit komt doordat het verbruik van de microcontroller op zich relatief laag is. Vanaf dat we de duur van de component hebben, kunnen we theoretisch aan de hand van de datasheet afleiden wat het verbruik van de CPU is, dit is zoals te verwachten ook linear (zie figuur 8). Merk op dat het praktisch niet mogelijk is om dit verbruik met de oscilloscoop te meten. Dit komt doordat een component bijna nooit zuiver alleen CPU gaat gebruiken maar ook nog geheugentoegang, pins, etc. 4.2 Toetsing van de metric Om de juistheid van onze metric te controleren hebben we het scenario van de temperatuurmetingen bestudeerd. Dit scenario hebben we door de tool laten berekenen om te kijken of het resultaat hiervan overeen kwam met het energieverbruik volgens de oscilloscoop. Wat hier wel buiten beschouwing wordt gelaten is het verbruik door de antenne, dit omdat het door tijdsgebrek niet op punt kon worden gesteld. In volgende tabel tonen we het temperatuurscenario waarbij het gemiddelde wordt berekend voor een bepaalde hoeveelheid metingen. De twee daarop volgende kolommen tonen respectievelijk het verbruik gemeten door de oscilloscoop en de hoeveelheid energie die geschat zou worden door de tool. Zoals eerder gezegd toont dit niet de hoeveelheid energie verbruikt door de antenne. Hiervan is er abstractie gemaakt.

7 3 Energie in functie van tijd 1 3 Energie in functie van tijd Tijd (ms) Figuur 7: Energieverbruik met antenne volledig uit Aantal bytes Oscilloscoop Metric Overschatting mJ.261mJ.6283% mJ.5113mJ 2.832% 3.766mJ.7642mJ.4739% mJ 1.17mJ 1.252% Figuur 11: Toetsing van de metric De laatste kolom geeft de afwijking van onze metric weer. Ze toont dus een lichte overschatting van de hoeveelheid energie die verbruikt wordt. Dit is geenszins een probleem, aangezien onze metric dan nooit te snel gaat voorspellen dat een bepaalde berekening beter kan worden uitgevoerd op de mote. 5 Verder werk. Er zijn al een aantal fundamentele zaken behandeld in deze paper. Er kan echter nog verder gegaan worden. Volledige netwerktopologieën. Stel dat de vuistregel voor een bepaald stuk applicatielogica beslist dat het best niet op een mote wordt gedeployed. Dan kan het zijn dat deze beslissing met een krappe marge is genomen. Bijvoorbeeld: we zitten met sensordata van telkens twintig bytes, sturen met dezelfde frequentie als sense and send data door, maar passen telkens een reductie toe waardoor we 1B winnen. De reductie is betrekkelijk duur, duurder dan het verzenden van 1B, waardoor de heuristiek aangeeft dat dit stuk applicatielogica op de mote draaien geen goed idee is. Als we echter kennis hebben van de topologie van het netwerk, kunnen we verder redeneren. Die twintig bytes die we verzenden als we het advies van de metric volgen moeten immers via een aantal hops de back end bereiken en bij elke hop moeten die twintig bytes opnieuw doorgestuurd worden. Dat betekent dat we als we globaal over heel het netwerk kijken, het kleine energieverlies dat we boeken bij het reduceren van Tijd (ms) Figuur 8: Energieverbruik CPU-cycli twintig bytes naar tien bytes mogelijk gecompenseerd wordt door wat men wint aan verzendkosten over alle hops. Wat zich hier aanbiedt is een manier om uit onze eenvoudige metric een nieuwe metric te induceren die de topologie exploiteert om lokale energieverliezen om te zetten in globale energiewinst. Verdere formalisatie van deze intuïtie en experimenten zijn aangewezen. Een pessimistische metric. Zoals het er nu voor staat hebben we een metric die erg eenvoudig is. Daarin berust zijn nut, maar stelt hij de zaak niet te simpel voor? Kunnen we de metric verfijnen en onverwachte overhead in rekening brengen? De sweet spot vinden met behulp van kostfuncties. Het is eenvoudig in te zien dat in het algemeen er een trade-off optreedt bij het reduceren van data: verzenden wordt goedkoper, maar we betalen een kost in de vorm van CPU-cycli. Een interessante vraag is dan: kunnen we een sweet spot vinden, waar de gecombineerde kost van verzending en datareductie minimaal is? In volgende grafiek (figuur 12) tonen we een hypothetische verloop van deze trade-off. Op de x-as staat de hoeveelheid data die nog verzonden moet worden na de bewerking ervan (bijvoorbeeld door compressie). Dit wordt weergeven door n x waarbij n de orginele hoeveelheid data is en x de factor waarmee deze verminderd wordt. Op de y-as staat de hoeveelheid energie die nodig is om een bepaalde actie uit te voeren. De oranje lijn staat voor de energie die nodig is om het aantal bytes na reductie te verzenden. Deze is dalend aangezien een kleinere hoeveelheid bytes om te verzenden natuurlijk minder energie vergt. Ze convergeert niet naar nul maar naar de vaste kost die nodig is om de antenne aan te zetten. De blauwe lijn staat voor de energiekost van de reductie. In deze hypothese wordt er van

8 Energie in functie van tijd Energie in functie van hoeveelheid bytes Tijd (ms) Figuur 9: Energieverbruik low-power listening uitgegaan dat de moeilijkheid om een grotere reductie te krijgen telkens stijgt (wat ook meestal het geval is bij compressie). Dit brengt ook een steeds stijgende energiekost met zich mee, vandaar het stijgend verloop. De groene lijn stelt dan de som voor van de blauwe en oranje lijn. Het minimum van deze kromme is aangeduid in het rood en is de zogenaamde sweet spot Bytes Figuur 1: Energieverbruik verzenden data (bytes) allemaal geïntegreerd in een tool. We hebben ook aangetoond dat het vaak mogelijk is om energiewinst te boeken ten opzichte van sense and send en dat deze winst enigszins kwantificeerbaar is met behulp van de metric. We ontwikkelden een eenvoudig formalisme om de winstpunten ten opzichte van sense and send te duiden, dit in de vorm van de parametrisatie die we hebben aangewend voor het configureren van de tool. Tenslotte hebben we een aanzet gegeven tot verdere ontwikkeling van de ideeën die in deze paper zijn voorgesteld. We beschouwen onze oorspronkelijke opzet als geslaagd, maar werken nog naarstig door aan verfijningen. Voor alle datasets, code en presentaties kan men terecht op: 7 Dankwoord We zouden graag onze begeleiders prof. Danny Hughes en Klaas Thoelen bedanken voor hun uitstekende begeleiding, en ook Gowri Sankar Ramachandran en Wilfried Daniëls voor hun technische hulp. 6 Conclusie Figuur 12: Een sweet spot vinden We hebben een metric voorgesteld die voldoet aan onze eisen; we hebben ook een overzicht gegeven van manieren om de kosten die we in de metric gebruiken te berekenen. Dit wordt Referenties [Akyildiz et al., 22] Ian F. Akyildiz, Weilian Su, Yogesh Sankarasubramaniam, and Erdal Cayirci. Wireless sensor networks: a survey. Computer networks, 38(4): , 22. [Atmel Corporation, 214] Atmel Corporation. Atmega128rfa1 datasheet. atmel.com/images/atmel-8266-mcu_ Wireless-ATmega128RFA1_Datasheet.pdf, 214. [Dunkels et al., 24] Adam Dunkels, Bjorn Gronvall, and Thiemo Voigt. Contiki-a lightweight and flexible operating system for tiny networked sensors. In Local Computer Networks, th Annual IEEE International Conference on, pages IEEE, 24.

9 [Hughes et al., 213] Danny Hughes, Eduardo Canete, Wilfried Daniels, R Gowri Sankar, James Meneghello, Nelson Matthys, Jef Maerien, Sam Michiels, Christophe Huygens, Wouter Joosen, et al. Energy aware software evolution for wireless sensor networks. In World of Wireless, Mobile and Multimedia Networks (WoWMoM), 213 IEEE 14th International Symposium and Workshops on a, pages 1 9. IEEE, 213. [Mainwaring et al., 22] Alan Mainwaring, David Culler, Joseph Polastre, Robert Szewczyk, and John Anderson. Wireless sensor networks for habitat monitoring. In Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications, pages ACM, 22. [Titzer et al., 25] Ben L Titzer, Daniel K Lee, and Jens Palsberg. Avrora: Scalable sensor network simulation with precise timing. In Proceedings of the 4th international symposium on Information processing in sensor networks, page 67. IEEE Press, 25.