Natuurlijke energiebronnen voor draadloze sensornetwerken Ruben Catteeuw

Natuurlijke energiebronnen voor draadloze sensornetwerken Ruben Catteeuw

Promotor: prof. dr. ir. Ingrid Moerman Begeleider: lic. ing. Pieter De Mil Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2008–2009

Natuurlijke energiebronnen voor draadloze sensornetwerken Ruben Catteeuw

Promotor: prof. dr. ir. Ingrid Moerman Begeleider: lic. ing. Pieter De Mil Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2008–2009

VOORWOORD

i

Voorwoord Dit werk zou niet geworden zijn wat het is zonder de hulp van enkele mensen. Mensen die in mij geloofden, mij zijn blijven steunen en altijd voor me klaarstonden. In de eerste plaats zou ik graag mijn begeleider Pieter De Mil willen bedanken voor de tijd en energie die hij in mij en dit werk heeft gestoken. Steeds kon ik voor vragen, goede tips, zijn visie en motivatie bij hem terecht en stuurde hij me geduldig daar waar nodig bij. Ook Bart Jooris wil ik hier bedanken, voor het geduld bij de vele e-mails, zijn klaarheldere kijk op de dingen, het snel en correct oplossen van problemen, zijn expertise met het testbed en zijn tips zonder dat ik erom vroeg. Mijn promotor professor Ingrid Moerman bedank ik voor haar enthousiasme en het aanbieden van deze unieke kans. Ditzelfde geldt voor GreenPeak, waar ik eerder stage liep en in het bijzonder Tim Allemeersch. Verder had ik ook graag mijn vriendin Tine, mama, papa, vrienden en kat Tijger bedankt er altijd voor me te zijn en als één man/vrouw/kat achter me te staan, bij elke keuze die ik maak.

Ruben Catteeuw, juni 2009

TOELATING TOT BRUIKLEEN

ii

Toelating tot bruikleen

“De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”

Ruben Catteeuw, juni 2009

Natuurlijke energiebronnen voor draadloze sensornetwerken Ruben Catteeuw Promotor: prof. dr. ir. Ingrid Moerman Begeleider: lic. ing. Pieter De Mil Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2008–2009 Universiteit Gent

Samenvatting In deze masterproef worden de mogelijkheden onderzocht om gebruik makend van natuurlijke energiebronnen draadloze sensor- (en actuator-)netwerken (WS(A)Ns) van energie te voorzien. Energy harvesters laten toe energie uit hun omgeving op te nemen en om te zetten naar elektrische energie die bruikbaar is als voedingsbron voor de nodes in een dergelijk netwerk. Een algemeen bruikbaar energieprofiel voor energy harvesting (EH) wordt in dit werk voorgesteld en ge¨ımplementeerd in zowel een WSN-simulator als op een real-life testbed. Deze implementaties en ontwikkelplatformen worden vervolgens gebruikt om enkele EH WSN toepassingen te evalueren en in meer detail te benaderen. Door dit in de vorm van case studies aan te pakken wordt het mogelijk de uitdagingen van deze toepassingen maximaal te onderzoeken. In een eerste case study wordt dieper ingegaan op een eenvoudig Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) protocol als basis van een EH Electronic Shelf Labeling (EHESL) systeem opgevat als WSN. De schaalbaarheid, invloedsfactoren en EH-werking van een dergelijk systeem worden geëvalueerd. Een tweede case study bespreekt een draadloze schakelaar met EH als bediening van een actuator, wiens controller deel uitmaakt van een building automation achtergrondnetwerk. Er wordt gezocht naar een maximale externe belasting terwijl toch wordt voldaan aan de Quality of Service (QoS) vereisten van de schakelaar-actuator combinatie.

Trefwoorden Natuurlijke energiebronnen, draadloos sensornetwerk, simulatie, real-life testbed, ESL

Power scavenging for Wireless Sensor Networks Ruben Catteeuw Supervisor(s): Ingrid Moerman, Pieter De Mil Abstract—This article explores the use of energy harvesters to scavenge power for nodes in a wireless sensor (actuator) network (WS(A)N). A generic energy harvesting (EH) framework and energy profile suited for a WSN simulator as well as a real life testbed are proposed. Those mechanisms are used to evaluate an energy harvesting electronic shelf label (EHESL) system. Keywords— energy harvesting/power scavenging, wireless sensor (actuator) network (WS(A)N), real life testbed, simulation, electronic shelf labeling (ESL)

I. I NTRODUCTION

W

IRELESS sensor (actuator) networks (WS(A)Ns) have become increasingly popular during the last decade. Ever-advancing applications such as industrial automation, health care and environmental monitoring for these smart networks keep pushing the limits of technology in a growing number of fields. One of these limits is the demand from some innovative applications for sensor nodes to have a very long lifetime. Since most of the current WSNs are battery-powered, the lifetime of the node is limited to the lifetime of the battery it uses. Changing the batteries of hundreds or even thousands of nodes is cumbersome or even impossible. The cost of changing the batteries of a node deployed at a remote location can outweigh the cost of the node itself. Battery technology has not improved in terms of energy density and size over the last decade, especially for low power applications such as sensor networks [1]. Therefore recent research focused on the development of energy-efficient or energy-aware MAC (Medium Access Control) and NWK (network) protocols to guarantee a lifetime of at least a couple of years with a single battery. A new trend however is visible: instead of using batteries energy harvesting (EH) systems scavenge light, thermal or mechanical energy from the ambient environment and convert it into electrical energy to power the nodes. In this way an unlimited energy resource is available to the nodes and their lifetime can be extended by a large factor. Energy harvesters behave fundamentally different from energy reservoirs such as batteries. Where the latter can be characterized by their energy density, the former tend to provide highly fluctuating amounts of energy and therefore their primary metric for comparison is power density. Table 1 shows some of the harvesting methods with their power generation capability and is a summary of numbers found in recent literature. Harvesting technology Solar cell (outdoor) Solar cell (indoor) Piezoelectric Vibration Thermoelectric

Power density 15 mW/cm2 10 − 100 µW/cm2 300 − 1000 µW/cm3 100 − 500 µW/cm3 40 − 60 µW/cm3

Table 1 Power densities of energy harvesting technologies

A rising number of articles address EH and EH sensor nodes, but most focus on a single application with the most convenient harvester or just give an overview of different applications and technologies. Few or none however provide a generic and useful energy profile for EH systems that can be used in WSN evaluation tools such as a real life testbed or WSN simulator, used in WSN research. This article provides such

a profile and uses it to evaluate an EH electronic shelf label (EHESL) system and in less extend an EH wireless switch for actuator control. II. G ENERIC EH ENERGY PROFILE / FRAMEWORK AND IMPLEMENTATION IN A WSN SIMULATOR AND ON A REAL LIFE TESTBED A. Abstraction of conversion circuitry Although some energy harvesters provide a stable DC output (solar cells for example), the power output of most energy harvesters is inherently AC or unstable DC. Since only a stable DC output is able to power a sensor node directly, additional conversion circuitry may be needed to provide a useful energy source. To make abstraction of these circuits this article assumes that they are part of the energy harvester itself whose output is as a consequence a variable DC current IDC . The energy harvesting circuits in [2] show that this assumption is realistic. Since these circuits have a finite efficiency and also consume power however, this has to be taken into account when designing an EH system. B. Generation, storage and usage of energy Ambient energy sources are typically low grade and their power output is highly nonlinear in nature depending upon a variety of factors. Hence energy harvesters provide low, variable and sometimes unpredictable levels of power. EH energy profiles seldom match the energy profile of the wanted application (application profile). Fig. 1 illustrates this behavior. The application profile (A) of a typical monitoring (sense

Fig. 1. Energy profiles and their averages of a typical application and energy harvester.

and transmit) application is relatively flat but exhibits periodical current spikes when the radio is turned on. The energy profile (B) of the energy harvester on the other hand has a totally different shape: one day (astronomical model) - night (electrical light source) cycle of a solar cell is shown. To make it possible for B to power A, an additional storage element is required. This intermediate rechargeable battery or (super)capacitor is needed to catch temporal fluctuations on or discrepancies between both the application’s and energy harvester’s energy profile. The storage element is charged with the DC current IDC from the energy harvester. Once the energy is stored a minimal condition for an application to work is that the average energy consumed is lower than the average energy harvested. C. Harvest-consume interworking All the elements needed to construct a generic EH framework are now present : a variable current IDC (a) to charge an intermediate

storage element (b) and an energy-consuming application (c). The framework’s task is to regulate a realistic balance between these elements. This is possible by virtualizing (b) and adjusting the (virtual) voltage potential over this element according to (a) en (c). For a (super)capacitor (according to [2] most suited here due to higher charge/discharge efficiency) the integral form of the capacitor equation states Z t q(t) 1 v(t) = = i(τ )dτ + v(t0 ), (1) C C t0

where i(τ ) in this case is the difference between the harvested current and the consumed current. This equation can be used to keep a record of the available energy on the capacitor at all times. For rechargeable batteries another voltage law is needed, but the principles remain the same. D. Implementation The functionality described above is implemented on the Environment Emulators (EE) of the sensor nodes in the IBBT real life testbed [3]. These EEs are modules able to actively emulate certain scenarios using events (power or sensing related) on the sensor node they are connected to. In this case the EE disables the node’s USB power connection and powers it with its own LDO voltage source. Making use of (1) the voltage potential over a virtual capacitor is altered and its value is used to configure the LDO. The current term i(τ ) in (1) is evaluated by using a configurable IDC and measuring the node’s current consumption. A similar approach is taken to implement the functionality in Castalia, a WSN-simulator. It’s resource-manager module is extended with a virtual capacitor and by providing harvest-consume functions (alter the virtual voltage) and message-passing to the application (power node up and down) the needed behavior is realized. III. E NERGY H ARVESTING E LECTRONIC S HELF L ABELING A. Overview Electronic Shelf Labeling (ESL), is a system used by retailers for displaying product pricing on shelves. In the research for this part of the article (which builds on earlier theoretical results in [4]) a WSN is used to represent such a smart ESL system. Since the sensor/actuator nodes of the WSN are powered with the implemented EH functionality the resulting system technology can be called EHESL. A typical EHESL system would consist of several thousands (16k is used as a reference) indoor solar cell powered label nodes in star topology with a central mains powered controller connected to a database and other peripherals. Each label node initiates a transceive cycle by sending a request (that may contain a sensor reading) to the controller at a random time in a periodical time interval (300 s is used as a reference). The controller upon receiving the request sends back a reply (that may contain actuator instructions if needed) after a fixed time to minimize the on-time of the label node. In [4] it is stated that due to the EH behavior a critical network operation condition occurs when all end nodes have to be (re)started around the same time, e.g. after a period without operation, or at initial system start-up. In this situation, all label nodes need an update and the level of network activity will be very high. B. Implementation and experiments The functionality described above is implemented on the testbed and, to make backtracking of the achieved results possible, in the simulator as well. As theoretically assumed in [4] a simple CSMA-CA (Carrier Sense Multiple access with Collision Avoidance) scheme is suited and sufficient to minimize collisions between the subsequent frames of the different nodes. In this implementation a MAC protocol based

on BMAC [5] is used. To cope with the limited number of available nodes in the test-setup (around 50) the frequency of transceive cycles per label node is scaled up in such a way that the workload λ for the controller (request arrivals/s) is similar to a situation with more nodes transceiving at a lower frequency. That this scaling can be justified has been shown in the simulator. A wide spectrum of experiments has been carried out to retrieve the maximal success rate and to identify the factors with the strongest influence on it. C. Results Both the simulator and the testbed yield an experimental average success rate up to 92% with a controller arrival rate λ of 40 transceive cycles per second. The maximal allowed λ has been found to be strongly platform dependent and is the most severe restriction to the number of label nodes allowed in the system. The success rate follows a downwards linear slope of about 0.2% per unit when λ increases from 1 to 40, due to increased traffic and collisions. Although the average success rate is relative stable, individual rates are not: temporal (interferance) and spatial (controller position) fluctuations tend to have a huge impact and can exclude certain nodes from the network temporaliry or permanently. Procentual deviations from the mean (good positioned controller) for the individual label nodes, measured on both the testbed and the simulator are much alike and vary between minus and plus 10%. Since the collision probability is high, omitting Clear Channel Assessments (CCAs) in the CSMA-CA scheme results in a substantial success rate drop of about 20%. The impact of other CSMA-CA parameters however is little. Backoff window sizes don’t really matter because although the collision probability is high, the probability of multiple nodes to collide at the same time is low. Also the transceive cycles of the different nodes are already randomized. Acknowledgements (ACKs) are possible, but retries in case of ACKs not responded to don’t improve the system. Increased traffic (and as a consequence collisions) when using retries and (sometimes mutual) hidden nodes cancel out the benefits. To emphasize the real-time interworking of the EH functionality Fig. 2 shows the voltage over the virtual capacitor in function of time. Each voltage drop corresponds to a transceive cycle of the ESL application.

Fig. 2. Voltage over the virtual capacitor (measured on testbed) in function of time.

IV. C ONCLUSION A generic EH energy profile and framework suited for a WSN simulator and real life testbed have been presented. These mechanisms can be successfully used to emulate or simulate EH applications and protocols for WS(A)Ns. This has been demonstrated with the EHESL case study. R EFERENCES [1] J. Paradiso, T. Starner, Energy scavenging for mobile and wireless electronics, IEEE Pervasive Computing 4 (2005) 18-27. [2] M. Guan, W. Liao, Characteristics of Energy Storage Devices in Piezoelectric Energy Harvesting Systems, Journal of Intelligent Material Systems and Structures 19 (2008) 671-680. [3] L. Tytgat, B. Jooris, P. De Mil, B. Latre, I. Moerman, P. Demeester, Demo Abstract: WiLab, a real-life Wireless Sensor Testbed with Environment Emulation, Ghent University, IBBT, INTEC (2009). [4] K. Steenbergen, A. Kamerman, Scalable Wireless Sensor Networks Based on Green Energy, GreenPeak Technologies BV (2008). [5] J. Polastre, J. Hill, D. Culler, Versatile Low Power Media Access for Wireless Sensor Networks, SenSys’04 (2004).

INHOUDSOPGAVE

vi

Inhoudsopgave Voorwoord

i

Toelating tot bruikleen

ii

Overzicht

iii

Extended abstract

iv

Inhoudsopgave

vi

Gebruikte afkortingen

ix

1 Inleiding 1.1 Situering van het onderwerp . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Probleem- en doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Overzicht masterproef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Karakterisatie en eigenschappen van energy harvesters voor systemen 2.1 Natuurlijke energiebronnen en soorten energy harvesters . . . . 2.1.1 Zonne- en lichtenergie . . . . . . . . . . . . . . . . . . . 2.1.2 Mechanische energie (vibraties) . . . . . . . . . . . . . . 2.1.3 Thermische energie . . . . . . . . . . . . . . . . . . . . . 2.1.4 Overige energiebronnen . . . . . . . . . . . . . . . . . . . 2.2 Opslag en verbruik van de verzamelde energie . . . . . . . . . . 2.2.1 Energieprofiel van de applicatie en energy harvester . . . 2.2.2 Conversie naar een bruikbare energievorm . . . . . . . . 2.2.3 Opslag van de geharveste energie . . . . . . . . . . . . . 2.3 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3

ingebedde . . . . . . . . . .

5 5 5 7 9 11 11 11 12 12 14

3 Basistechnologie¨ en en ontwikkelomgeving 3.1 Experimentele testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . .

15 16

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

INHOUDSOPGAVE

3.2

3.3

3.1.1 Het WiLab testbed . . . . . . . 3.1.2 TinyOS . . . . . . . . . . . . . Simulator . . . . . . . . . . . . . . . . 3.2.1 Traditionele netwerksimulators . 3.2.2 WSN-simulators . . . . . . . . . 3.2.3 Castalia . . . . . . . . . . . . . Conclusie . . . . . . . . . . . . . . . .

vii . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 Implementatie van een generiek energy harvesting energieprofiel ontwikkelomgevingen 4.1 Generiek EH energieprofiel . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Energy harvesting op het testbed . . . . . . . . . . . . . . . . . . . . 4.2.1 Energieverbruik en virtuele energy harvester . . . . . . . . . . 4.2.2 Dynamische spanning en virtuele condensator . . . . . . . . . 4.3 Energy harvesting in de simulator . . . . . . . . . . . . . . . . . . . . 4.3.1 Resource manager . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 De resource manager uitbreiden . . . . . . . . . . . . . . . . . 4.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

16 18 19 19 20 21 24

op de . . . . . . . .

. . . . . . . .

. . . . . . . .

25 25 26 26 27 29 29 30 35

5 Case study: Energy Harvesting Electronic Shelf Labeling 5.1 Electronic Shelf Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 ESL-systeem als WSN-applicatie . . . . . . . . . . . . . . . . . 5.1.2 Energy Harvesting ESL . . . . . . . . . . . . . . . . . . . . . . . 5.2 Beschrijving en implementatie van de applicatie . . . . . . . . . . . . . 5.2.1 Beschrijving van de ESL-label functionaliteit . . . . . . . . . . 5.2.2 Beschrijving van de ESL-controller functionaliteit . . . . . . . . 5.2.3 Implementatie van het ESL-systeem . . . . . . . . . . . . . . . . 5.3 Experimenten, resultaten en analyse . . . . . . . . . . . . . . . . . . . 5.3.1 RFU/U throughput van de controller . . . . . . . . . . . . . . . 5.3.2 Mapping van het testbed op de simulator . . . . . . . . . . . . . 5.3.3 ESL-systeem met 40 nodes . . . . . . . . . . . . . . . . . . . . . 5.3.4 Invloedsfactoren op de succesrate . . . . . . . . . . . . . . . . . 5.3.5 Nagaan van de correctheid van de emulatie m.b.v. de simulator 5.4 Energy Harvesting ESL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Aanpassingen ESL-applicatie tot EHESL-applicatie . . . . . . . 5.4.2 Resultaten met de EHESL-applicatie . . . . . . . . . . . . . . . 5.4.3 Keuze energy harvester voor ESL . . . . . . . . . . . . . . . . . 5.4.4 Energieverbruik van de testbed-implementatie . . . . . . . . . . 5.4.5 EHESL op het testbed . . . . . . . . . . . . . . . . . . . . . . . 5.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

36 37 37 39 39 40 40 42 42 43 44 46 50 65 66 67 67 69 70 74 78

INHOUDSOPGAVE

viii

6 Case study: EH draadloze schakelaar ter bediening van een 6.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Draadloze RF-schakelaar . . . . . . . . . . . . . . . . . 6.1.2 Keuze van een geschikte energy harvester . . . . . . . . 6.2 Eigenschappen en randvoorwaarden . . . . . . . . . . . . . . . 6.2.1 Achtergrondverkeer . . . . . . . . . . . . . . . . . . . . 6.2.2 Energiebeperking . . . . . . . . . . . . . . . . . . . . . 6.3 Beschrijving en implementatie van de applicatie . . . . . . . . 6.3.1 Implementatie . . . . . . . . . . . . . . . . . . . . . . . 6.4 Experimenten, resultaten en analyse . . . . . . . . . . . . . . 6.4.1 Opstelling met 1 schakelaar . . . . . . . . . . . . . . . 6.4.2 Opstelling met meerdere schakelaars . . . . . . . . . . 6.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

actuator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

79 79 80 80 80 81 81 82 83 85 85 86 90

7 Besluit

91

A Cd-rom A.1 Broncode . . . . A.1.1 Testbed . A.1.2 Simulator A.2 Digitale vorm . .

92 92 92 93 93

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

B Figuren

94

C Gedetailleerde meetresultaten

97

Bibliografie

116

GEBRUIKTE AFKORTINGEN

ix

Gebruikte afkortingen ACK

Acknowledgement

CA

Collision Avoidance

CBW

Congestion Backoff Window

CCA

Clear Channel Assessment

CSMA

Carrier Sense Multiple Access

DUT

Device Under Test

EE

Environment Emulator

EH

Energy Harvesting

ESL

Electronic Shelf Labeling

IBW

Initial Backoff Window

IR

Infra Red

LAN

Local Area Network

LCD

Liquid Crystal Display

LPL

Low Power Listening

MAC

Medium Access Control

MCU

Micro Controller Unit

PRR

Packet Reception Ratio

QoS

Quality of Service

RF

Radio Frequency

RFU

Request For Update

RM

Resource Manager

GEBRUIKTE AFKORTINGEN

x

RSSI

Received Signal Strength Indication

U

Update

USB

Universal Serial Bus

WSN

Wireless Sensor Network

INLEIDING

1

Hoofdstuk 1 Inleiding De bedoeling van dit inleidende hoofdstuk is om, naast de situering van het onderwerp, een duidelijk overzicht te geven van deze masterproef. De probleem- en doelstelling worden uiteengezet, waarna wordt ingegaan op de opbouw en structuur van het verdere verloop van deze tekst.

1.1

Situering van het onderwerp

Draadloze sensornetwerken (WSNs) winnen de laatste jaren erg aan populariteit. Ze zijn het onderwerp van menig onderzoek in een steeds maar toenemend aantal vakgebieden. Sensoren worden ge¨ıntegreerd in gebouwen, machines, ons lichaam en onze omgeving. Een WSN integreert meerdere dergelijke sensornodes, laat ze via een draadloos kanaal met elkaar communiceren en bouwt zo een intelligent netwerk op. Op deze manier kan een spatiaal en temporeel beeld van de omgeving van het netwerk worden bekomen. Deze gegevens kunnen enorme voordelen bieden aan ons en onze maatschappij. Behoud en bescherming van het leefmilieu, verhoging van de productiviteit bij productieprocessen, een verhoogde veiligheid, minder rampen met tragische gevolgen en een verbeterde ziekenzorg zijn maar enkele van de voordelen die sensornetwerken kunnen bieden. Indien naast sensoren ook actuatoren aan het netwerk worden toegevoegd, neemt de veelheid aan mogelijkheden enkel maar toe. Traditioneel worden elektrochemische batterijen gebruikt om de nodes in een WSN te voeden. Wegens de beperkte levensduur van dergelijke batterijen is het nodig ze op geregelde

1.2 Probleem- en doelstelling

2

tijdstippen te vervangen. Dit is erg onpraktisch en de kost en werkuren om honderden of zelfs duizenden batterijen te vervangen wordt snel moeilijk haalbaar. In veel gevallen is het zelfs zo dat WSNs worden uitgerold in moeilijk toegankelijke gebieden (bijvoorbeeld monitoring van een vulkaan) wat het vervangen van de batterijen bemoeilijkt of onmogelijk maakt. De levensduur van het netwerk is dan beperkt tot de levensduur van de batterijen. Daarom is het erg interessant als WSNs energie kunnen recupereren uit hun omgeving om op deze manier een altijddurende en quasi onuitputtelijke energiebron te bekomen. Wanneer een WSN dat de toestand van een brug bijhoudt zijn energie kan halen uit een resonante trilling aanwezig op diezelfde brug dan is dit een dankbare manier om het netwerk te voeden, zeker naar onderhoud toe. Het proces waarin nodes natuurlijke energie uit hun omgeving halen en omzetten naar een bruikbare elektrische vorm, staat bekend onder de naam energy harvesting (EH) of power scavening. De meest courante natuurlijke energiebronnen zijn licht, mechanische energie en thermische energie. Afhankelijk van de toepassing zijn echter talloze andere scenario’s denkbaar.

1.2

Probleem- en doelstelling

Energy harvesters gedragen zich fundamenteel verschillend van batterijen. Batterijen beschikken over een bepaalde hoeveelheid energie die in de loop van de tijd en afhankelijk van het verbruik afneemt. Typisch slaagt een batterij erin gedurende een bepaalde tijd een vrij constante (of lichtjes dalende) spanning te leveren. Dit tot op een gegeven moment de spanning heel snel daalt en de resterende energie niet meer bruikbaar is. Zolang dit echter niet zo is, kan de batterij voldoen aan de energievereisten van de node die wordt gevoed. Het is dan ook de node zelf die bepaalt hoeveel en wanneer energie wordt verbruikt. De door een energy harvester geleverde energie is tijds- en omgevingsafhankelijk. Het zijn nu deze afhankelijkheden die bepalen hoeveel en wanneer energie beschikbaar is. De node die dient te worden gevoed kan dit dus niet meer zelf bepalen zoals bij een batterij het geval was. Energy harvesters worden bijgevolg eerder gekarakteriseerd door hun vermogensdensiteit dan door hun energiedensiteit. Zowel in systemen met een energiereservoir zoals een batterij als in systemen met energy harvesters is een energiezuinige aanpak belangrijk. In het eerste geval is dit om de levensduur van het systeem te maximaliseren, maar in het tweede geval is deze beperkende factor veel dominanter aanwezig. Een applica-

1.3 Overzicht masterproef

3

tie moet energiezuinig zijn alleen al omdat ze zou kunnen werken. Wanneer een applicatie meer energie nodig heeft dan de energy harvester kan leveren (niet gemiddeld, maar op elk ogenblik tenzij een intermediair opslagmedium aanwezig is), dan is ze op voorhand al niet realiseerbaar. Met deze beperking dient bij het ontwikkelen van applicaties en protocollen rekening te worden gehouden. Applicaties en protocollen kunnen worden getest in een simulatoromgeving of op een reallife testopstelling. Geen of weinig van deze ontwikkelplatformen beschikken over een energieprofiel aangepast aan het gedrag van energy harvesters. Een doelstelling van deze thesis is om energy harvesters te karakteriseren en hun gedrag en eigenschappen om te zetten tot een generiek voor de ontwikkelplatformen geschikt profiel. Vervolgens kunnen de uitgebreide ontwikkelplatformen worden gebruikt om een applicatie of protocol in meer detail te gaan onderzoeken, rekening houdend met de beperkingen opgelegd door het gebruik van energy harvesting. In dit werk is ervoor gekozen om dit verdere onderzoek te doen onder de vorm van meer in detail uitgewerkte case studies. Deze manier van werken laat toe bepaalde keuzes te maken en de aandacht beter te vestigen. Het is immers zo dat het gebruik van energy harvesters en de beperkingen ervan zeer sterk verweven zijn met de applicatie en het doel voor ogen. Door uit te gaan van een specifieke case wordt dan ook direct vanuit een mogelijke toepassing gestart, wat andere boeiende uitdagingen en meerwaarden met zich meebrengt. Een nadeel is eventueel dat door de meer gedetailleerde aanpak minder zaken kunnen worden behandeld, maar er is getracht toch naar een vorm van algemeenheid te streven.

1.3

Overzicht masterproef

Deze sectie sluit dit inleidende hoofdstuk af en geeft een overzicht van de verdere opbouw van deze tekst. Dit werk bevat na dit eerste hoofdstuk nog vijf andere hoofdstukken: Hoofdstuk 2 geeft een inleiding over het gebruik van energy harvesters als energiebron

voor ingebedde systemen en meer specifiek draadloze sensornodes. Een overzicht van enkele types energy harvesters en hun kenmerken wordt daar gegeven, alsook hun toepasbaarheid in WSNs.

1.3 Overzicht masterproef

4

Hoofdstuk 3 geeft een overzicht van de in deze masterproef gebruikte basistechnolo-

gieën en ontwikkelomgevingen. De vermelde tools worden kort ingeleid en gesitueerd in een meer algemeen kader. De beschikbare technologieën worden in hoofdstuk 4 aangepast en uitgebreid zodat

ze geschikt worden voor de vereisten die EH-WSNs stellen. Dit hoofdstuk behandelt de implementatie van het EH energieprofiel op de gebruikte platformen. De in hoofdstukken 3 en 4 aangeboden tools worden dan in de twee laatste hoofd-

stukken als basis gebruikt voor het verdere onderzoek in de vorm van twee case studies. Een eerste case study behandelt de mogelijkheden van een Energy Harvesting Electronic Shelf Labeling (EHESL) systeem, de tweede die van een EH draadloze schakelaar als bediening van een actuator.

Bij dit werk hoort ook een cd-rom die achteraan dit werk is bijgevoegd. Hierop is de sourcecode van de in de masterproef geschreven software opgenomen. Deze code is om dit werk niet nodeloos te belasten enkel daar terug te vinden. Waar nodig wordt in de tekst naar deze cd-rom verwezen. Dit geldt ook voor gedetailleerde resultaten die in de vorm van tabellen in de appendix zijn terug te vinden. Aan het begin van ieder hierna volgend hoofdstuk wordt, net zoals in deze inleiding, een overzicht gegeven van het desbetreffende onderdeel. Ook is op het einde waar nodig een bespreking van de daar bekomen resultaten opgenomen.

KARAKTERISATIE EN EIGENSCHAPPEN VAN ENERGY HARVESTERS VOOR INGEBEDDE SYSTEMEN

5

Hoofdstuk 2 Karakterisatie en eigenschappen van energy harvesters voor ingebedde systemen 2.1

Natuurlijke energiebronnen en soorten energy harvesters

Energy harvesters kunnen in verschillende categorieën worden ingedeeld. Dit op basis van de energiesoort die ze gebruiken voor de conversie naar elektrische energie. De hierna volgende subsecties maken deze opdeling en geven een korte introductie over de werking en karakteristieken van de meest courante energy harvesters. Daarnaast wordt ook een idee gegeven van de vermogensdensiteit van de verschillende energy harvesters. Aangezien [1], [2], [3] en [4] hierover een recent en volledig overzicht geven, zijn ze de voornamelijkste referentiebronnen voor deze sectie. Meer gedetailleerde informatie is dan ook in deze teksten en hun referentielijsten terug te vinden.

2.1.1

Zonne- en lichtenergie

Een zonnecel zet lichtenergie om naar elektrische energie. Naast de meest gekende fotovolta¨ısche cellen die dit doen via het fotovolta¨ısch effect bestaan ook foto-elektrochemische cellen. Deze laatste worden hier niet verder behandeld. De te converteren lichtenergie

2.1 Natuurlijke energiebronnen en soorten energy harvesters

6

is vaak rechtstreeks afkomstig van de zon, de meest evidente energie- en lichtbron, maar kan ook komen van een elektrische verlichtingsbron binnen. Beide lichtbronnen verschillen fundamenteel. De lichtintensiteit onder kunstverlichting zoals in kantoren en hospitalen bedraagt minder dan 10 W/m2 in vergelijking met 100 − 1000 W/m2 in een buitenomgeving [5]. Aangezien ook de gebruikte zonnecel-technologie verschilt wordt in volgende onderdelen een onderscheid gemaakt tussen de twee. Fotovolta¨ısche cellen leveren een vrij stabiele DC-spanning en kunnen daardoor rechtstreeks als voedingsbron worden gebruikt, maar meestal wordt toch geopteerd voor een vorm van opslagmedium. Zonlicht als voornaamste energiebron Monochristalijne fotovolta¨ısche cellen zijn meer geschikt in omstandigheden met sterke belichting en het spectrum van het (zon)licht in een buitensituatie. Met de huidige technologie halen dergelijke cellen bij rechtstreeks invallend zonlicht (middag) een vermogensdichtheid van 15 mW/cm2 [2] en [5]. Deze waarde wordt echter enkel gehaald onder vrij optimale omstandigheden. Extra factoren zoals het beschikbare daglicht op een bepaalde dag van het jaar, breedtegraad, invalshoek van het licht (tijdstip) en schaduwperiodes door wolken, sneeuw of andere obstakels dienen in rekening te worden gebracht. Een interessant artikel waarin dit uitdrukkelijk ter sprake komt is [6]. Figuur 2.1 is overgenomen uit dit artikel en toont het verloop van de uitgangsstroom (de uitgangsspanning is nagenoeg constant) van een zonnepaneel op twee verschillende nodeposities op een zonnige dag in een stadsomgeving. Afhankelijk van de individuele positionering en oriëntatie van de node blijft het zonnepaneel langer of minder lang belicht en treden afwijkingen op t.o.v. het theoretische astronomische model van IBM in [7]. Wanneer dezelfde meting wordt herhaald op een bewolkte dag of in een bosomgeving, zijn de afwijkingen nog drastischer. Elektrische verlichting als voornaamste energiebron Dunne film amorfe silicium of cadmium telluride cellen behalen een betere efficiëntie in een binnenomgeving dan hun monochristalijne tegenhangers. Dit omdat de spectrale gevoeligheid ervan beter aanleunt tegen die van de gebruikte elektrische lichtbron [4]. Toch slagen deze cellen er slechts in een efficiëntie van zo’n 10% te halen waardoor de vermogensdensiteit slechts 10 [4] - 100 [8] en [9] µW/cm2 bedraagt. Natuurlijk hangen deze waarden sterk


7

Figuur 2.1: Uitgangsstroom van een zonnepaneel op een zonnige dag in een stadsomgeving op twee verschillende nodes. Individuele verschillen in positionering leiden tot een verschillend verloop en afwijking t.o.v. het theoretische astronomische model.

af van de afstand tot de lichtbron. Ook loopt wanneer een raam in de omgeving van de energy harvester aanwezig is waarlangs zonlicht kan binnenvallen de vermogensdensiteit op tot zo’n 1000 µW/cm2 [8]. Verder kunnen ook tijdelijke of vrij permanente (zoals stof) obstakels de efficiëntie nog verlagen.

2.1.2

Mechanische energie (vibraties)

Mechanische trillingen zijn aanwezig in heel wat omgevingen zoals op voertuigen (auto, trein, vliegtuigen), bruggen, ramen, machines en huishoudtoestellen. Vibrationele harvesters zijn meestal opgebouwd als een aan een veer verbonden proefmassa die beweegt relatief t.o.v. het kaderwerk waaraan het is opgespannen. De kracht kan direct op de proefmassa worden uitgeoefend, maar kan ook een schijnkracht zijn ten gevolge van de inertie van de proefmassa. Afhankelijk van de omgeving is een bepaalde trillingsfrequentie dominant en krijgt de proefmassa een bepaalde versnelling. De resonantiefrequentie van de meeste toepassingen varieert tussen 60 and 200 Hz, terwijl de amplitude van de versnelling meestal 1 − 10 m/s2 bedraagt [4]. Vibrationele energy harvesters vereisen een resonante werkingsfrequentie in de buurt van de dominantie frequentie van de vibraties. Bij de meeste toepassingen is deze frequentie gekend, zodat de energy harvester dusdanig


8

kan worden ontwikkeld. In sommige applicaties echter is dit niet zo en daar zijn bijgevolg breedbandige systemen nodig (self-tuning). Wegens de aanwezigheid van mechanische onderdelen zijn mechanische energy harvesters blootgesteld aan mogelijke falingen van deze onderdelen. De vermogensdichtheid van de energy harvesters is afhankelijk van de werkfrequentie en de versnelling. De technologie is erg competitief in vergelijking met andere types. Vermogensdichtheden van 45 [8], 120 [5], 200 [4] en 800 [9] µW/cm3 zijn haalbaar. De beweging van de proefmassa kan worden omgezet naar elektrische energie via verschillende transductiemechanismes. De in de literatuur meest dominante zijn piëzoelektrisch, elektrostatisch en elektromagnetisch. Deze mechanismes worden in de volgende onderdelen kort toegelicht. Pi¨ ezoelektrisch Over bepaalde materialen (bijvoorbeeld kwarts of PZT) wordt een elektrisch veld opgewekt wanneer er een druk-, trek- of buigspanning op wordt uitgeoefend (en omgekeerd), dit wordt het piëzoelektrisch effect genoemd. De spanning en energie die op deze manier ontstaan kunnen mits de nodige aanpassingen worden opgeslagen. Elektrostatisch Tegengestelde ladingen trekken elkaar aan. Dit is ook het geval wanneer deze tegengestelde ladingen zich bevinden op de platen van een condensator. Wanneer één van de platen van een initieel opgeladen condensator (varactor) wordt verplaatst (de proefmassa), dan wordt deze aantrekkingskracht tegengewerkt, waardoor ket elektrisch veld ertussen wijzigt. Hierdoor verplaatsen de ladingen zich, wat met een stroom correspondeert. Deze stroom kan worden gebruikt om een extern opslagmedium op te laden. Een nadeel van deze methode is dat een exerne spanningsbron nodig is om de condensator initieel op te laden. Elektromagnetisch Wanneer een spoel beweegt in een magnetisch veld wordt een spanning ge¨ınduceerd, conform met de wet van Faraday. Door dus een spoel of magneet aan de proefmassa te bevestigen kan op deze manier eveneens de conversie van mechanische naar elektrische energie gebeuren.


9

Vereiste nevencircuits Alvorens het opgewekte vermogen van de vermelde harvesters geschikt is voor draadloze elektronica zijn enkele nevencircuits vereist. De convertors produceren immers een ACspanning die nog door een gelijkrichter moet worden omgezet tot een bruikbare DC-vorm. Bovendien is de AC-spanning sterk afhankelijk van de magnitude van de ingangstrillingen en dus niet erg stabiel. Figuur 2.2 illustreert dit, gedurende een halve seconde wordt het verloop van de gemiddelde vervorming van een piëzoelektrische energy harvester, verwerkt in een autoband, weergegeven samen met de resulterende AC-spanning. Een DC-DC convertor is dus eveneens vereist alvorens de energie kan worden opgeslagen. Afhankelijk van de toepassing is dit reeds mogelijk op en kleine condensator van enkele µF.

2.1.3

Thermische energie

Een verschil in temperatuur bestaat ongeveer tussen elk object dat een arbeid levert en zijn omgeving. Uit elementaire thermodynamica volgt dat elke temperatuursgradiënt een vermogensdissipatie als gevolg heeft. Dit betekent dat in theorie elk warm oppervlak gebruikt kan worden om electriciteit te produceren. Productieprocessen waar warmte een bijproduct is, zijn bijgevolg ideale toepassingen voor thermische energy harvesting. De conversie van warmte naar electriciteit en omgekeerd kan gebeuren door het benutten van thermo-elektrische effecten, waarvan de belangrijkste de gelijkaardige Seebeck en Peltier effecten zijn [4]. Bepaalde metalen en halfgeleiders (meestal bismuth telluride) bezitten thermo-elektrische eigenschappen en kunnen gebruikt worden om warmte te converteren. Wanneer er een temperatuursverschil is tussen de twee uiteinden van een staafje gemaakt uit een thermo-elektrisch materiaal, dan bouwt zich een spanning op over het staafje, dit door het Seebeck effect. Door dergelijke staafjes in serie te plaatsen kan een spanning bekomen worden die de som is van de individuele Seebeck-spanningen. Het geleverde vermogen is naast het volume van de thermo-elektrische generator afhankelijk van het verschil in temperatuur en de Seebeck-coëfficiënt van het gebruikte materiaal. Thermo-elektrische elementen genereren net als zonnecellen DC-vermogen. In tegenstelling tot zonnecellen echter is DC-DC conversie vereist om een stabiele spanning te bekomen. Verder is ook een koelvinblok nodig om het temperatuursverschil tussen het warme oppervlak en de omgeving te maximaliseren. Dit koelvinblok zorgt ervoor dat deze energy


10

Figuur 2.2: Verloop van de gemiddelde vervorming van een piëzoelektrische energy harvester verwerkt in een autoband. De resulterende AC-spanning over de harvester wordt eveneens weergegeven.

2.2 Opslag en verbruik van de verzamelde energie

11

harvesters vrij groot uitvallen. Een ander nadeel is de vrij lage thermo-elektrische efficiëntie die wordt gehaald (systemen met hogere efficiëntie zijn volgens [1] op komst). Thermoelektrische harvesters bevatten geen bewegende delen en zijn bijgevolg erg robuust. Een lange levensduur en een hoge betrouwbaarheid zijn enkele andere voordelen. Thermo-elektrisch gevoede systemen dienen te beschikken over een voldoende hoge temperatuursgradiënt die voldoende lang aanhoudt. De meeste industriële processen die een temperatuur halen die voldoende is voldoen hieraan en wanneer het systeem niet operatief is, zijn metingen meestal overbodig. In [2] en [4] wordt een vermogensdensiteit 40 µW/cm3 vermeld bij een ∆T van 5°C (in [5] bij een ∆T van 10°C). In [9] wordt bij een ∆T van 10°C 60 µW/cm3 vermeld.

2.1.4

Overige energiebronnen

Naast de meest courante energiebronnen die besproken werden in de vorige subsecties zijn er nog heel wat andere mogelijkheden. Deze omvatten geluid (1 µW/cm3 [5] en [8]), wind (380 µW/cm3 [4]), drukvariaties (17 µW/cm3 [4]), radioactiviteit (0.52 µW/cm3 [4]), RF (< 1 µW/cm3 [9], 10 µW/cm3 [8]) en menselijke interactie (piëzoelektrisch materiaal in drukknop of schoen: 300 µW/cm3 ).

2.2

Opslag en verbruik van de verzamelde energie

De door een energy harvester opgewekte energie is vaak niet geschikt om rechtstreeks een sensornode te voeden. Deze energie heeft immers vaak een onstabiel verloop en dient dus eerst door een AC-DC of zelfs DC-DC convertor te worden omgezet in een bruikbare vorm. Bovendien is het bij een rechtstreekse voeding nodig dat de opgewekte energie ten allen tijde aan de energievereisten van de sensornode kan voldoen, wat moeilijk haalbaar is.

2.2.1

Energieprofiel van de applicatie en energy harvester

Typisch heeft een applicatie een energieprofiel waar een duidelijk onderscheid kan worden gemaakt tussen de energie nodig in actieve modus en in slaapmodus. Het applicatieprofiel is dan een (vaak periodieke) afwisseling tussen beide modi. Ook de gebruikte energy harvester heeft een bepaald energieprofiel. Dit profiel kan (na de nodige conversie) vrij


12

binair zijn: een bepaalde energie (met lichte fluctuaties) in de periodes waar de harvester actief is (of de natuurlijke energiebron nodig voor de harvester aanwezig is) en geen energie wanneer de harvester inactief is. Een meer tijdsafhankelijk verloop zoals dat van het astronomische model bij een zonnecel is echter ook mogelijk. Het energieprofiel van de applicatie en dat van de energy harvester komen zelden volledig overeen. Daarom is het nodig de geharveste energie op te slaan zodat die dan later door de sensornode (wanneer de harvester bijvoorbeeld niet meer actief is) kan worden gebruikt. Een vereiste om een applicatie te kunnen voeden is dan dat de totale hoeveelheid geharveste energie (mits die volledig kan worden opgeslagen) groter is dan de totale energie verbruikt door de applicatie. M.a.w. dat het gemiddelde verbruik kleiner is dan de gemiddelde generatie. Figuur 2.3 vat dit samen en toont een mogelijk verloop van de energieprofielen van de applicatie en de energy harvester, de gemiddelden worden ook weergegeven.

2.2.2

Conversie naar een bruikbare energievorm

Een schematische voorstelling van een energy harvesting circuit wordt weergegeven op Figuur 2.4 [10]. De als een sinus te modelleren AC-uitgangsstroom van de energy harvester ip wordt geconverteerd naar een variabele DC-stroom iesd bij een spanning Vrect (hiervoor bestaat een optimale waarde, waardoor eventueel na deze trap nog een tweede nodig is om de gewenste spanning over het opslagmedium te bekomen). Deze stroom laadt het opslagmedium op. Het is deze stroom (of eventueel het gemiddelde ervan) waarnaar in deze masterproef verder wordt verwezen als door de energy harvester gegenereerde stroom. Aangezien conversiecircuits slechts een beperkte efficiëntie halen en zelf ook energie gebruiken dient hier eventueel mee rekening gehouden te worden wanneer een bepaalde energy harvester wordt gekozen voor een applicatie.

2.2.3

Opslag van de geharveste energie

De bekomen DC-stroom wordt vervolgens gebruikt om een opslagmedium op te laden. Verschillende systemen bestaan hiervoor, maar meestal wordt gekozen voor ofwel een heroplaadbare batterij ofwel een condensator. Batterijen hebben een energiedensiteit die veel hoger is dan die van condensatoren (supercondensatoren hebben een energiedensiteit die vele malen hoger is dan die van gewone condensatoren), de levensduur en het maximaal aantal herlaadcycli ervan is echter 10-100 maal lager. Het oplaadmechanisme voor bat-


13

Figuur 2.3: Vereenvoudigd tijdsverloop van de energie opgewekt door een energy harvester en de energie verbruikt door een sensornode. De gemiddelde waarden worden eveneens weergegeven.

Figuur 2.4: Schematische voorstelling van een energy harvesting circuit. De geharveste ACenergie is na een AC-DC conversie geschikt om te worden opgeslagen op bijvoorbeeld een condensator.

2.3 Conclusie

14

terijen is meer complex dan dat van een condensator aangezien in het eerste geval een beveiliging tegen overladen dient te worden ingebouwd. Volgens [10] is bij condensatoren de laad/ontlaad-efficiëntie hoger wegens een hogere lekweerstand, batterijen zijn dan wel weer minder gevoelig voor zelfontlading. Naast de vermelde verschillen is ook het spanningsverloop tijdens het laden of ontladen van batterijen en condensatoren verschillend. Figuur 2.5 geeft een typisch verloop. Bij een batterij is het verloop gedurende het grootste deel van de tijd vrij constant met een vrij steile spanningsval aan het begin- en einde van de laad/ontlaad-cyclus. Dit verloop is bij een condensator lineair en de helling is afhankelijk van de capaciteitswaarde.

Figuur 2.5: Spanningsverloop bij het open ontladen van respectievelijk een batterij en een (super)condensator.

2.3

Conclusie

Er bestaat geen optimale energy harvester die beter is dan de andere. Het is de toepassing of de omgeving ervan die bepaalt welke harvesters kunnen worden gebruikt. De verschillende types kunnen door elkaar en zelfs samen worden gebruikt. Per toepassing moet dan worden geëvalueerd of de beschikbare harvester voldoende (en snel genoeg) energie kan leveren om aan de desbetreffende energievereisten te kunnen voldoen. Meestal zijn conversiecircuits en een intermediair opslagmedium vereist om een bruikbare energievorm te bekomen die op de correcte tijdstippen beschikbaar is. Van de conversiecircuits kan abstractie worden gemaakt tot op het niveau van een variabele DC-stroom die dan een generieke energy harvester voorstelt. Aangezien de conversiecircuits zelf ook energie verbruiken en slechts een eindige efficiëntie hebben dient hiermee rekening te worden gehouden. Deze stroom wordt dan gebruikt om het opslagmedium (oplaadbare batterij of condensator) op te laden.

¨ EN ONTWIKKELOMGEVING BASISTECHNOLOGIEEN

15

Hoofdstuk 3 Basistechnologie¨ en en ontwikkelomgeving Samen met de stijgende hoeveelheid onderzoek naar draadloze sensornetwerken de laatste jaren is tijdens deze periode logischerwijze de interesse voor geschikte ontwikkelplatformen gegroeid. Zo’n platform kan een real-life experimentele opstelling zijn, maar vaak opteert men (zeker in de initiële fases van het onderzoek) voor een goedkopere softwareoplossing. Een netwerksimulator is een softwarepakket dat de werking van een communicatienetwerk (een WSN in deze context) zo betrouwbaar mogelijk tracht na te bootsen, dit aan de hand van enkele (eventueel empirisch bekomen) modellen. Des te beter deze modellen zijn, des te nauwkeuriger zijn de resultaten. Met een simulator is het bijgevolg mogelijk een idee te krijgen van hoe het werkelijke gedrag van de applicatie op een sensornode en in een WSN er zal gaan uitzien. Een WSN-simulatieomgeving is een handig hulpmiddel bij het snel ontwikkelen, debuggen of testen van nieuwe applicaties en protocollen, maar heeft zijn beperkingen. Ook al zijn de meest recente simulators vrij nauwkeurig (of claimen ze dat toch te zijn) en blijven de gebruikte modellen evolueren, de resultaten zijn steeds een benadering van de werkelijkheid. Simulators slagen er vaak niet in significante details van de nodewerking of draadloze communicatie aan het licht te brengen [11]. Een nieuw protocol wordt daarom meestal slechts aanvaard wanneer het ook in een real-life opstelling in voldoende mate haar werking heeft bewezen. Een volgende stap bij het ontwikkelen is dus de correcte werking van het systeem nagaan met behulp van een testopstelling.

3.1 Experimentele testopstelling

16

Real-life systemen en simulatieomgevingen kunnen samen gebruikt worden om resultaten en conclusies op het ene platform te vergelijken met die op het andere platform. Het is net deze backtracking tussen beide systemen die interessante resultaten kan opleveren. In deze masterproef is er dan ook voor gekozen om deze weg te volgen. Het onderzoek is waar mogelijk in parallel gebeurd op zowel een experimentele opstelling als een simulatieomgeving. Dit hoofdstuk geeft meer informatie over de in de volgende hoofstukken van deze masterproef gebruikte technologieën. Een eerste sectie beschrijft de gebruikte experimentele opstelling en daaraan verbonden technologieën, de tweede sectie beschrijft de simulator.

3.1

Experimentele testopstelling

Een experimentele testopstelling kan bestaan uit een klein aantal sensornodes verspreid in een enkele ruimte, maar in een realistisch scenario kan het benodigde aantal motes snel de hoogte ingaan. Schaalbaarheid is een belangrijke factor in alle types netwerken en dus ook in WSNs. Dit maakt het uitbouwen van een testopstelling van een bruikbaar formaat een stuk ingewikkelder. Naast de benodigde hardware (een groot aantal motes) dient ook rekening gehouden te worden met het gebruiksgemak van het geheel. Het is immers niet haalbaar alle motes telkens opnieuw te gaan herprogrammeren en herpositioneren. Recent werd in het IBBT-gebouw aan de Zuiderpoort te Gent het WiLab testbed uitgerold. Dit is het testnetwerk waarop in deze masterproef is gewerkt.

3.1.1

Het WiLab testbed

WiLab [12] is een WSN-testnetwerk bestaande uit ongeveer 200 sensornodes verspreid over drie verdiepingen binnen een bedrijfsomgeving van 80 m op 12 m. Gebruikers kunnen hun applicaties testen en ontwikkelen met behulp van een webgebaseerde interface. De kern van het netwerk is gebaseerd op MoteLab [11]. Door de sensornodes te verbinden met een interne high-datarate backbone wordt het mogelijk gegevens centraal te gaan verwerken en opslaan. Elk WiLab knooppunt is opgebouwd uit verschillende elementen, die hierna kort worden toegelicht.


17

Sensornode De gebruikte sensornode is de Tmote Sky, een compact en veelzijdig moteplatform voor ultra-low-power (standby: 5-25 µA , idle: 50-1000 µA , TX/RX: 20-25 mA) WSN-toepassingen met hoge vereisten qua datasnelheid (250 kbps). De module bestaat uit een enkele PCB en beschikt over ge¨ıntegreerde sensoren (vochtigheid, temperatuur en licht), radio (Chipcon CC2420), antenne (onboard), MCU (TI MSP430), ADC, DAC en programmeervoorzieningen. Verder omsluit de Tmote Sky industriestandaarden zoals USB en IEEE 802.15.4, waardoor communicatie met nevenapparatuur mogelijk is. De Tmote Sky wordt bovendien door TinyOS ondersteund [13]. Environment Emulator In een testnetwerk van deze schaal is het belangrijk het geheel op een eenvoudige manier te kunnen aansturen. Bij MoteLab was het reeds mogelijk om elke mote individueel te voeden en remote te programmeren. Ook kan informatie (loggen/controle) remote tijdens het uitvoeren van een applicatie met de mote worden uitgewisseld (via de backbone). Dit alles is mogelijk door het correct aansturen van de USB-poort op de module. Deze zaken zijn echter allen passief van aard, de werkelijke waarnemingen van de mote kunnen niet echt be¨ınvloed worden. Bij het WiLab-netwerk is men een stap verder gegaan. Een extra hardwarecomponent, de Environment Emulator (EE), maakt het mogelijk actief de motes te gaan aansturen. Deze EE wordt aan de sensornode gekoppeld en laat toe verschillende scenario’s aan de hand van events te definiëren. Enkele voorbeelden zijn: lege of bijna lege batterij, energy harvesters, defecte nodes, sensor events (zonder dat deze sensorhardware effectief aanwezig moet zijn), actuator events, audio streams, enz. Op deze manier kunnen nieuwe WSNnetwerkarchitecturen en protocollen worden geëvalueerd in een real-life omgeving onder realistische omstandigheden. Ook laat de EE monitoring van het energieverbruik van de sensornodes toe, wat belangrijk is in deze masterproef en andere energiekritische toepassingen [12]. Het is dan ook de EE die in deze masterproef gebruikt wordt om de EH-functionaliteit op het testbed te realiseren. Hiervoor wordt verwezen naar sectie 4.2.


18

Intermediate node De verbinding tussen de mote/EE combinatie en de management-backbone wordt verwezenlijkt door zogenaamde iNodes. Deze mini-computers zijn uitgerust met Ethernet, USB, seriële poort, vga, audio en twee 802.11-interfaces [12]. Via de iNode komt de verzamelde data op de MoteLab-database van de backbone terecht die de gebruiker aan de hand van een webinterface en MySQL-statements kan raadplegen, analyseren en visualiseren.

3.1.2

TinyOS

De WiLab webinterface laat toe de Tmotes individueel of groepsgewijs te gaan programmeren. Dit gedurende een te kiezen tijdsperiode, rekening houdend met gebruikersquota en schedule. Standaard gebeurt dit programmeren door de verschillende .exe en .class up te loaden en aan de betreffende nodes toe te wijzen. Meestal wordt de programmacode vanuit TinyOS gegenereerd, al is dit natuurlijk niet de enige manier. Rechtstreeks vanuit C-code de hardware aanspreken behoort ook tot de mogelijkheden. Dit is trouwens de weg die de industrie eerder geneigd is te volgen, wegens de overhead geassocieerd met TinyOS. In deze masterproef wordt steeds gebruik gemaakt van TinyOS, wat in seze subsectie wordt toegelicht. TinyOS is een ingebed besturingssysteem met draadloze sensornetwerken als doelplatform. Dit besturingssysteem, geschreven in de nesC-programmeertaal (een C-dialect) is een open-source project en wordt beschouwd als de de facto standaard van dergelijke besturingssystemen. In tegenstelling tot de meeste andere besturingssystemen is TinyOS gebaseerd op een eventgedreven programmeermodel in plaats van multithreading. TinyOS programma’s worden samengesteld uit event-handlers en taken met run- to-completion semantiek. Wanneer een externe gebeurtenis zoals het ontvangen van een datapakket of een sensormeting plaatsvindt, roept TinyOS de geschikte event-handler op. Event-handlers kunnen taken posten die door de TinyOS kernel worden gescheduled (FIFO) om later te worden uitgevoerd. Op deze manier kan TinyOS als een enkele stack worden opgebouwd en aangezien alles via events (callbacks) gebeurt is het geheel volledig non-blocking [14][15]. TinyOS componenten worden (afhankelijk van hun interface) met elkaar verbonden en op deze manier kan een complex geheel (protocol of applicatie) worden samengesteld. De TinyOS bibliotheek bevat heel wat softwaremodules met een eventuele hardware-abstractie

3.2 Simulator

19

(afhankelijk van de verschillende platformen), de gebruiker kan natuurlijk zelf nieuwe componenten gaan definiëren. In deze masterproef wordt gebruik gemaakt van TinyOS 2.1, voor meer gedetailleerde informatie wordt verwezen naar [16] en [17]. TinyOS MAC met CSMA/CA Aangezien dit relevant is voor de ESL case study uit hoofdstuk 5 wordt in dit onderdeel kort een overzicht gegeven van het standaard MAC-protocol gebruikt in TinyOS. De standaard MAC-implementatie in TinyOS voor de CC2420-radiostack is voornamelijk gebaseerd op B-MAC [18], dit samen met enkele eigenschappen van X-MAC. B-MAC is een asynchroon CSMA-protocol voor draadloze sensornetwerken met als hoofddoel het aanbieden van een flexibele ultra-low-power interface. De belangrijkste karakteristieken zijn: Asynchrone werking wat de overhead (o.a. energieverbruik) ten gevolge van synchro-

nisatie vermijdt. Effectieve collision avoidance (CA) via CCA en backoffwindows. Efficiënt kanaalgebruik. Schaalbaar, eenvoudig en herconfigureerbaar.

3.2

Simulator

In het kader van deze masterproef (en vooral van de ESL case study uit hoofdstuk 5) werd een WSN-simulator geselecteerd uit een vrij groot aanbod aan dergelijke simulators. Deze sectie situeert de gekozen simulator (Castalia) en geeft meer gedetailleerde informatie.

3.2.1

Traditionele netwerksimulators

Ook bij traditionele netwerken (draadloos of bedraad) bieden netwerksimulators de mogelijkheid om applicaties en protocollen op een relatief goedkope manier te testen en te ontwikkelen. Reeds voor de opgang van draadloze sensornetwerken waren verschillende netwerksimulators populair, gekende en vaak gebruikte voorbeelden zijn ns-2 [19], OPNET

3.2 Simulator

20

[20] en QualNet [21]. In principe kunnen deze simulators worden uitgebreid zodat ze ook geschikt worden voor WSNs. Dergelijk onderzoek is dan ook gebeurd, bijvoorbeeld door [22] en [23]. Het blijkt echter dat alhoewel deze simulators erg geschikt zijn voor de traditionele netwerken, ze heel wat minder presteren op het vlak van sensornetwerken. Waar traditionele netwerken voornamelijk gebruik maken van dominante protocollen (Ethernet voor wired LAN, IEEE 802.11 voor wireless LAN), is dit niet het geval bij sensornetwerken. Daar bestaan geen dominante protocollen of algoritmes, aangezien sensornetwerken vrij applicatiespecifiek worden opgebouwd en het onwaarschijnlijk is dat een enkel algoritme altijd optimaal kan zijn. Sensornetwerken hebben dus behoefte aan simulators die in sterke mate aanpasbaar en uitbreidbaar zijn. De traditionele simulators hebben deze eigenschap vaak niet. Door het objectgeoriënteerd design van ns-2 bijvoorbeeld, ontstaan heel wat onnodige afhankelijkheden tussen de modules. Zulke afhankelijkheden maken het uitbreiden van de simulator met nieuwe protocollen extreem moeilijk [24].

3.2.2

WSN-simulators

Hierdoor ontstond de nood aan efficiënte en krachtige WSN-simulators, waarvan de componenten makkelijk hergebruikt en uitgebreid kunnen worden. Voorbeelden hiervan zijn Castalia [25], SENSE [24], J-Sim [26], Avrora [27], TOSSIM [28], EMSim [29], Atemu [30], EmStar [31] en nog heel wat andere. TOSSIM (TinyOS) en EmSim (StrongARM microprocessor met Linux OS) zijn WSN-specifiek en focussen zich dan ook op de effectieve targetcode die dan wordt gelinkt met de simulatie-bibliotheken om te worden uitgevoerd op een host-pc voor de simulatie. Avrora en Atemu zijn platformspecifieke simulators voor AVR-processor gebaseerde systemen. Castalia, SENSE, EmStar en J-Sim daarentegen zijn platformonafhankelijk en daarom beter geschikt binnen het kader van deze masterproef. J-Sim (voormalig Java-Sim) is een Java-gebaseerde simulatieomgeving en boet daarom in aan performantie [24]. De laatste release van EmStar dateert van 2005, terwijl zowel Castalia en SENSE in 2008 nog een nieuwe versie uitbrachten. Deze twee simulators zijn C/C++ gebaseerd. SENSE is gebouwd bovenop de COST dicrete-event simulator, terwijl Castalia gebruik maakt van OMNet++ als basis. Volgens [32] beschikt Castalia over het meest accurate wireless channel- en radiomodel beschikbaar in de literatuur. Verder wordt in dit schrijven met de term simulator enkel nog maar naar Castalia verwezen.

3.2 Simulator

3.2.3

21

Castalia

Castalia is een WSN-simulator gebaseerd op (of gebouwd bovenop) het OMNet++ platform, een open-source modulaire discrete-event simulator. Het hoofddoel van Castalia is (vaak in tegenstelling tot andere WSN-simulators) om de gebruiker te voorzien van een realistisch wireless channel- en radiomodel (gebaseerd op empirische data), dit samen met een realistisch node-gedrag (bijv. radio access). Castalia is platformonafhankelijk, eenvoudig aan te passen en uit te breiden. Enkele andere eigenschappen zijn: Gedetaileerd state-transitiemodel voor de radio (verschillende TX-powerlevels). Node clock drift, CPU power consumption (in een volgende release). Resource-monitoring van energieverbruik, geheugen en CPU-tijd. Medium Access Control protocol met een groot aantal aanpasbare parameters.

Een ander voordeel aan Castalia is dat platformafhankelijke zaken (zoals TX-levels en stroomverbruik van de radio) als parameters kunnen worden ingegeven. Standaard zijn deze waarden gebaseerd op het Tmote Sky platform, dezelfde hardware die op het testbed wordt gebruikt. Bovenstaande (en verdere) informatie is te vinden in [33]. OMNet++ De basisbouwblokken van OMNet++ zijn modules die met elkaar communiceren door het uitwisselen van berichten. Modules ontvangen berichten en reageren hierop door een gepast stuk code uit te voeren, zoals een toestandstransitie of het terugsturen van een bericht. Verder voert elke module een stuk initialisatie- en exit-code uit bij het respectievelijk opstarten en afsluiten. Elke module wordt beschreven in een .ned bestand waarin parameters, gates (in en uit), submodules en connecties worden gedefinieerd. Castalia is eigenlijk een framework die enkele van deze modules definieert en op een bepaalde manier met elkaar verbindt. Structuur De modulestructuur van Castalia wordt weergegeven op Figuur 3.1 (boven). Nodes die met elkaar willen communiceren doen dit niet rechtstreeks, het bericht wordt doorgestuurd

3.2 Simulator

22

Figuur 3.1: De modules waaruit Castalia is opgebouwd en hun onderlinge connecties (boven). Detailstructuur van een enkele node (onder).

3.2 Simulator

23

naar de Wireless Channel module die er verder over beslist. De Physical Process module bevat een generiek fysisch model die de nodes voorziet van realistische spatiaal verdeelde meetwaarden. De structuur van Castalia is erg modulair, de modules zijn m.a.w. van elkaar afgeschermd. Deze gelaagde structuur is ook terug te vinden binnen een enkele node die is opgebouwd als een hiërachische structuur van modules. De detailstructuur van een enkele node is eveneens te zien op Figuur 3.1 (onder). De belangrijkste module is de communicatiemodule die samengesteld is uit drie deelmodules: de radiomodule, de MACmodule en de netwerkmodule. De functies van deze modules spreken voor zich. Een andere cruciale module is de Resource Manager, die de resources van een node beheert. Deze module is in de context van EH erg belangrijk en wordt daarom in meer detail besproken in subsectie 4.3.1. Aan de functionaliteit van de basismodules moet door de gebruiker in principe weinig of niks worden gewijzigd. De basismodules zijn het referentieplatform waarmee wordt gewerkt (zoals de mote-hardware), de gebruiker stelt enkel de parameters in. Om user-functionaliteit te kunnen definiëren voorziet Castalia de Application-module. Voor elke nieuwe applicatie kan de gebruiker zo’n nieuwe module aanmaken en van C-code voorzien. Simulatie Het belangrijkste element in een Castalia-simulatie (en in alle OMNet++ simulaties) is het omnetpp.ini configuratiebestand. Dit configuratiebestand definieert de volledige simulatie. Eerst en vooral wordt hier bepaald welk type netwerk (ook een .ned en dus ook een module) wordt gesimuleerd en hoe lang deze simulatie duurt (gesimuleerde tijd). Vervolgens worden de parameters van alle submodules (en de submodules daarvan) van de netwerkmodule vastgelegd. Een belangrijke parameter van de netwerkmodule is bijvoorbeeld het aantal nodes in het netwerk. Om het geheel overzichtelijk te houden, kan het bepalen van die parameters hiërarchisch gebeuren door het includeren van andere .ini configuratiebestanden. Meestal wordt de structuur van de modules hierbij aangehouden. Door verschillende versies van bepaalde .ini bestanden bij te houden, kan van configuratie worden veranderd door het simpelweg includeren van een andere .ini. Eenmaal alle parameters zijn vastgelegd wordt opgegeven welke nodes welke applicatie dienen te draaien. De simulatie zelf wordt gestart door het runnen van een script en de output wordt naar een file naar keuze weggeschreven.

3.3 Conclusie

24

In deze masterproef wordt gebruik gemaakt van Castalia 1.3 (OMNet 3.3). Op 11 mei 2009 werd Castalia 2.0 gereleased, maar aangezien deze datum erg op het einde van de masterproef viel is van deze nieuwe versie geen gebruik gemaakt. Wel worden nieuwe of verbeterde features daar waar relevant vermeld.

3.3

Conclusie

Zowel WSN-simulators als een real-life testbed zijn geschikt om WSN-applicaties en protocollen te ontwikkelen en te evalueren. Simulators zijn vaak te beperkt wegens de te lage nauwkeurigheid van de gebruikte modellen. Een testbed heeft deze beperking minder, maar is minder generiek. De EEs in het WiLab bieden hiervoor een oplossing door op een actieve manier de waarnemingen en het gedrag van de sensornodes te gaan sturen. Toch is het interessant ook simulators te gebruiken in een ontwikkelproces om een backtracking tussen de resultaten mogelijk te maken.

IMPLEMENTATIE VAN EEN GENERIEK ENERGY HARVESTING ENERGIEPROFIEL OP DE ONTWIKKELOMGEVINGEN 25

Hoofdstuk 4 Implementatie van een generiek energy harvesting energieprofiel op de ontwikkelomgevingen De in het vorige hoofdstuk beschreven ontwikkelplatformen beschikken standaard niet over een mechanisme dat energy harvesting ondersteunt of toelaat. Eén van de doelstellingen van deze masterproef was om dit wel mogelijk te maken. De volgende secties bespreken een generiek energieprofiel voor energy harvesters en de uiteindelijke implementatie van deze EH-functionaliteit op zowel het testbed als in de simulator. Deze implementaties kunnen dan verder in de masterproef worden gebruikt.

4.1

Generiek EH energieprofiel

Zoals in sectie 2.3 wordt vermeld kan elke energy harvester na de nodige conversie worden geabstraheerd tot een variabele DC-stroom waarmee een intermediair opslagmedium kan worden opgeladen. Het tijdsverloop van deze stroom bepaalt het energieprofiel van de energy harvester en kan binair of geleidelijk variëren in functie van de tijd. Door dit profiel ten alle tijde te vergelijken met het energieprofiel van de applicatie kan de beschikbare energie op het opslagmedium elk moment worden geëvalueerd. De integraalvorm van de condensatorwet is q(t) 1 v(t) = = C C

Z

t

t0

i(τ )dτ + v(t0 ),

4.2 Energy harvesting op het testbed

26

waarbij i(τ ) in deze context het verschil is tussen de door de harvester geleverde en door de applicatie verbruikte stroom. De huidige spanning over de condensator v(t) wordt bepaald aan de hand van de spanning v(t0 ) op tijdstip t0 en de integraal van i(τ ) over een tijdsinterval [t0 , t] geschaald met de capaciteit C van de condensator. Door deze condensator te virtualiseren en de (virtuele) spanning erover bij te houden ontstaat een dynamisch geheel: door het stroomverbruik van de applicatie daalt de spanning en door de door de energy harvester geleverde stroom stijgt ze opnieuw. Vervolgens dient een mechanisme te worden voorzien dat ervoor zorgt dat wanneer de spanning onder een bepaalde drempelwaarde daalt de sensornode wordt uitgeschakeld en wanneer ze opnieuw de drempelwaarde bereikt weer wordt ingeschakeld. Dit is immers hoe een opstelling met een echte energy harvester en condensator zich zou gedragen. Eenmaal dit zo is kan in principe elke EH-applicatie worden beschreven. Wanneer een oplaadbare batterij als opslagmedium wordt gebruikt is uiteraard een andere spanningswet nodig, maar het principe blijft gelijk.

4.2

Energy harvesting op het testbed

Deze sectie geeft een beschrijving van de in de loop van deze masterproef bekomen en gebruikte EH-functionaliteit op het testbed. Deze functionaliteit werd volledig door Bart Jooris ge¨ımplementeerd, waarvoor nogmaals dank. De bijdrage van de auteur van deze tekst aan dit onderdeel beperkt zich tot het testen, geven van gedetailleerde feedback en het bepalen van de equivalente capaciteit.

4.2.1

Energieverbruik en virtuele energy harvester

Zoals in de vorige sectie wordt beschreven is het nodig het stroomverbruik van de applicatie en de stroomgeneratie van de (virtuele) energy harvester in rekening te brengen. De volgende onderdelen bespreken hoe dit op het testbed wordt aangepakt. Op de webinterface van het testbed kunnen scenario’s (hier dus een EH scenario) worden gedefinieerd door de gebruiker. Deze worden opgebouwd aan de hand van verschillende events op de EE, waarnaar in deze subsectie wordt verwezen.


27

Stroommetingen De EE laat toe het stroomverbruik van de aangesloten Tmote (en dus de applicatie) te samplen aan een frequentie tot 10 kHz, wat dus neerkomt op een minimale sampleperiode van 100 µs. Dit gebeurt aan de hand van een sampler-event. Energy harvester Op het testbed kan een waarde worden opgeven die de energy harvester voorstelt in de vorm van een stroom. De parameter harvester wordt in een streamer-event ingegeven in een 4096-delige schaal, 4095 komt overeen met 70 mA.

4.2.2

Dynamische spanning en virtuele condensator

De EE verbonden aan de Tmote laat toe een variabele spanning aan te leggen aan de sensornode. Standaard wordt de Tmote via USB gevoed en dus dient deze USB-connectie door de EE te worden verbroken om deze dynamische spanning toe te laten (IO-event). Een streamer-event bepaalt welke spanning aan de Vcc-pin van de expansion connector op de Tmote wordt aangelegd. Virtuele condensator De spanning wordt opgebouwd op een virtuele condensator, waarover de initiële spanning wordt gegeven door de parameter value 0 in het streamer-event. De spanning over de condensator wordt dynamisch aangepast aan de hand van de ingestelde harvester waarde en het real-time stroomverbruik van de node. Bij elke volle samplebuffer van 50 samples wordt de aangelegde spanning Vn opnieuw geëvalueerd. Aangezien de stroom elke 250 µs wordt gesampled (op deze manier lukt het continu te samplen), gebeurt dit dus elke 12.5 ms (250 µs · 50). Er geldt 0

Vn = Vn−1 + ∆V = Vn−1 +

P50

i=1

harvester − sampleBuf f er[i] . harvestM ultiplier

Hierbij is Vn de nieuwe DAC-spanning (4096-delige schaal waarbij 4095 mapt op 3.48 V), Vn−1 de vorige spanning en ∆V 0 de verschilspanning die wordt bepaald uit de som van de geharveste stroom en de verbruikte stroom, geschaald met harvestMultiplier. Deze laatste waarde wordt in volgend onderdeel in meer detail besproken.


28

Equivalente capaciteit van de virtuele condensator De waarde van harvestMultiplier komt bij een bepaalde samplefrequentie van de stroom overeen met een condensator met capaciteit C. Om deze waarde te bepalen wordt uitgegaan van de discrete vorm van de condensatorwet ∆Q = C · ∆V = ∆I · ∆t. Hierbij is ∆Q het ladingsverschil in Coulomb, ∆V de spanningsval over de condensator in Volt en ∆I het verschil tussen geharveste stroom en verbruikte stroom in Ampère per sampleperiode van ∆t seconden. In een herschreven vorm wordt de wet: ∆I C = ∆V ∆t Het algoritme op het testbed berekent ∆V 0 =

∆I 0 , harvestM ultiplier

waarbij ∆V 0 de spanningsval over de virtuele condensator is in de 4096-delige DACspanningsschaal en ∆I 0 het verschil tussen geharveste stroom en verbruikte stroom in de 4096-delige ADC-stroomschaal. Anders geschreven geeft dit ∆I 0 harvestM ultiplier = . ∆V 0

(4.1)

Volgende conversies tussen de stroom- en spanningsschaal gelden: 3.48 4095 0.070 ∆I = ∆I 0 · . 4095

∆V = ∆V 0 ·

Hieruit volgt dat 50 ·

∆I ∆I 0 = . ∆V ∆V 0

(4.2)

Uit (4.1), (4.2) en (4.3) volgt 50 ·

C = harvestM ultiplier. ∆t

Bij een stroomsampleperiode van 250 µs en harvestM ultiplier = 1 geldt dan C=

250 = 5 µF. 50

Elke eenheid van harvestMultiplier komt bij een sampleperiode van 250 µs bijgevolg overeen met een virtuele condensator van 5 µF.

4.3 Energy harvesting in de simulator

4.3

29

Energy harvesting in de simulator

Deze sectie zet het generieke EH energieprofiel om naar een framework geschikt voor de Castalia-simulator. Naast het uiteenzetten van de verschillende implementatiestappen heeft deze sectie ook de bedoeling een vorm van handleiding te zijn bij de functionaliteit van het bekomen framework.

4.3.1

Resource manager

Zoals eerder vermeld bij de bespreking van Figuur 3.1, beschikt Castalia over een eerder bijzondere module: de resource manager (RM). Deze module heeft als doel de beschikbare resources van het gesimuleerde sensorplatform te beheren. Dergelijke resources worden vaak genegeerd bij simulaties, maar omvatten belangrijke aspecten zoals geheugengebruik, CPU-tijd en energieverbruik. De RM van Castalia is momenteel nog in ontwikkeling en bevat standaard slechts een eenvoudig lineair energiemodel (2 AA-batterijen) en houdt geheugenstatistieken bij. Volgens de ontwikkelaars komen in de nabije toekomst meer accurate batterijmodellen beschikbaar en functionaliteit die o.a. ook het CPU-energieverbruik in rekening brengt. In het standaard energiemodel wordt bij het starten van een simulatie de initiële energievooraad (in Joules) als parameter meegegeven. Voor een enkele AA-batterij kan dit eenvoudig berekend worden: 1.5 V · 2700 mAh = 4050 mWh en dus s 1 · = 14580 W · s = 14580 J. h 1000 Twee AA-batterijen corresponderen dan met 29160 J. Het energiemodel is lineair en de 4050 mWh · 3600

modules kunnen energie consumeren tot de beschikbare energie nul wordt, waarop de RM een bericht (Resource Mgr Out Of Energy) naar de modules stuurt, waardoor deze geen verdere berichten meer afhandelen. Echte batterijen gedragen zich niet lineair, de geleverde spanning neemt op een gegeven moment af waardoor ze er niet meer in slagen om de sensornode te voeden.


30

In tegenstelling tot communicatie tussen andere modules, wordt met de RM niet gecommuniceerd via berichtuitwisseling. Omdat de meeste andere modules met de RM dienen te communiceren (energie verbruiken, geheugen innemen) is het efficiënter om rechtstreeks functies van de RM uit te voeren. Wat het energieverbruik betreft, is standaard een enkele functie consumeEnergy(double amount) aanwezig. Bij het oproepen van deze functie wordt de als argument meegegeven hoeveelheid energie van de nog beschikbare energiehoeveelheid afgetrokken.

4.3.2

De resource manager uitbreiden

De RM is de meest logische plek binnen de modulestructuur van de simulator om de EHwerking te implementeren. Deze werkwijze is dan ook gekozen en het uiteindelijke doel is om met het includeren van een enkele .ini het EH-energiemodel te activeren, net zoals het geval is bij het AA-batterijmodel. Harvest-consume model In een eerste poging om de simulator met EH-functionaliteit te voorzien, wordt de RM uitgebreid met een tweede energiefunctie harvestEnergy(double amount). Deze functie is analoog aan consumeEnergy(double amount), maar in plaats van de beschikbare energiehoeveelheid met amount te verlagen, wordt die ermee verhoogd. In de gebruikte versie van Castalia wordt consumeEnergy enkel opgeroepen door de radio- en de sensormodule. De sensormodule roept de functie op telkens de sensor een meting doet, de radiomodule doet dit bij elke radiotransitie. Voor harvestEnergy kunnen volgende opties overwogen worden: De RM roept periodisch bij zichzelf de harvestEnergy-functie op. De radiomodule roept de harvestEnergy-functie op bij elke radiotransitie en dit vlak

voor het oproepen van de consumeEnergy-functie.

De eerste optie leunt het dichtst aan bij hoe een echte harvester zich gedraagt (continue werking), maar heeft zijn beperkingen qua geschiktheid voor de simulator. Timers in Castalia zijn controleberichten die op de gepaste ogenblikken door de module naar zichzelf worden gestuurd. Om een continue harvest-werking te bekomen moet de timerperiode


31

voldoende klein zijn (bijv. elke 1 ms), wat resulteert in een grote overhead aan controleberichten. Bovendien zijn de harvestwaarden dan zodanig klein dat dit problemen kan geven bij de precisie. De tweede optie sluit aan bij de in Castalia reeds beschikbare functionaliteit. Bij elke radiotransitie wordt eerst de opgewekte energie in de vorige toestand geëvalueerd, waarna ook de verbruikte energie in die toestand wordt bepaald. Met deze informatie kan dan een nieuwe energietoestand worden bepaald. Het onderdeel over het definitieve framework die later volgt, gaat hier dieper op in. Tekortkomingen van het harvest-consume model Het hierboven beschreven harvest-consume systeem heeft enkele gebreken. Een eerste probleem is dat de oproepende module (de radiomodule) van de harvestEnergy-functie verantwoordelijk is voor het bepalen van de hoeveelheid op te wekken energie (het argument amount). De oproepende module heeft met het hele harvestgebeuren niks te maken waardoor dit geen goede manier van werken is. De RM zou hiervoor verantwoordelijk voor moeten zijn, zeker wanneer gezocht wordt naar een zo generiek mogelijke implementatie die alle types van EH toelaat. Bij de consumeEnergy-functie is het ook zo dat de oproepende module de verbruikte energie vastlegt, maar daar vormt dit geen probleem aangezien het weldegelijk die module is die de energie verbruikt. Een tweede probleem is het onrealistische gedrag van het systeem. Het model gaat ervan uit dat de energiebron een oplaadbare batterij is die altijd een constante stroom/spanning levert, lineair open ontlaadt en alle opgewekte energie kan opslaan. Zo’n ideale energiebron bestaat niet en enkele aanpassingen zijn nodig. Een realistisch systeem zal bijvoorbeeld bij een onvoldoende hoge spanning niet meer reageren en wanneer de spanning weer stijgt opnieuw opstarten. Om een zo generiek en algemeen bruikbaar mogelijk geheel te bekomen en om een oplossing te bieden aan de vermelde gebreken, wordt het model verder aangepast tot het in het volgende onderdeel besproken framework. Het uiteindelijke Castalia EH-framework Het uiteindelijk bekomen EH-framework voor de simulator bestaat uit volgende componenten:


32

Een configuratiebestand resourceMgr EnergyHarvester.ini, waarin volgende parame-

ters worden vastgelegd (per node of bereik van nodes instelbaar via de nodeID): – SN.node[nodeID].nodeResourceMgr.harvestLevel i, waarbij i varieert van 1 tot 20. Deze parameters bepalen de opeenvolgende levels van het door de harvester geleverde stroom (in Ampère). – SN.node[nodeID].nodeResourceMgr.harvestIntervalTime bepaalt hoelang elk harvestLevel actief is. Van t = 0 tot t = harvestIntervalTime is dit harvestLevel 1, van t = harvestIntervalTime tot t = 2 · harvestIntervalTime is dit harvestLevel 2 enzovoort. Het geheel is cyclisch in die zin dat na harvestLevel 20 harvestLevel 1 opnieuw actief wordt. In de lamp-schakelaar case in hoofdstuk 6 wordt een wijziging voorgesteld waarbij ook de intervaltijden per harvestLevel in te stellen zijn. Deze wijziging werd wegens tijdsgebrek niet doorgevoerd. – SN.node[nodeID].nodeResourceMgr.capacitor bepaalt de capaciteit van de virtuele condensator (in Fahrad). – SN.node[nodeID].nodeResourceMgr.harvester activeert of deactiveert harvesting(true of false). – SN.node[nodeID].nodeResourceMgr.initialEnergy legt de initiële spanning op de virtuele condensator vast (in Volt). De functie evaluateEnergy(double startTime, double amount) evalueert bij het oproe-

pen ervan de energietoestand van de node. De periode waarover deze evaluatie loopt start op startTime en eindigt op de huidige simulatietijd simTime(). De variabele amount stelt de verbruikte lading in Coulomb (I · ∆t) voor. Zoals eerder vermeld is het aangewezen de evaluateEnergy-functie op te roepen vanuit de radiomodule bij elke radiotransitie, net zoals standaard in Castalia het geval was bij de consumeEnergy-functie. Bij een verstandige keuze van harvestIntervalTime en de harvestLevels kunnen op een generieke manier heel wat harvesters en hun energieprofiel worden benaderd, dit op een stuksgewijs constante wijze. Figuur 4.1 toont hoe het eerder vermelde astronomische model er stuksgewijs zou kunnen uitzien met een harvestIntervalTime van 1.20 uur. Om de werking te illustreren wordt verwezen naar Figuren 4.2 en 4.3. Op tijdstip t1 (=de huidige simulatietijd simTime()) maakt de radio een transitie van toestand RS0


33

Figuur 4.1: Stuksgewijs constante benadering van het astronomische model. Door de harvestLevels en harvestIntervalTime verstandig te kiezen kan een energieprofiel goed worden benaderd.

Figuur 4.2: De energie wordt bij elke radiotransitie geëvalueerd en dit over een periode D waarin de radio zich in de vorige toestand bevond.

Figuur 4.3: Deze evaluatie gebeurt aan de hand van de ingestelde harvestLevels en de verbruikte energie.


34

naar RS1 , dit na zich gedurende een tijdsduur D in toestand RS0 te hebben bevonden. Tijdstip t0 waar de radio de transitie van RS−1 naar RS0 maakte, wordt bijgehouden in de radiomodule. Aangezien evaluateEnergy bij elke radiotransitie wordt opgeroepen is op t1 de energietoestand reeds geëvalueerd tot t0 , aangezien op dat tijdstip de vorige radiotransitie plaatsvond. Op t1 moet dus de energie over de periode [t0 , t0 + D = t1 ] worden geëvalueerd. Dit gebeurt door oproepen van evaluateEnergy(t0 ,U ), waarbij t0 het tijdstip is van de vorige radiotransitie en U het product van het stroomverbruik iRS0 in de vorige radiotoestand en de duurtijd D: U = D · iRS0 . U wordt reeds in de radiomodule zelf bepaald, aangezien dit bij de consumeEnergy-functie ook reeds zo was. Om i.p.v. een waarde in Joule een waarde in Coulomb te bekomen is het wel nodig in het .ini -configuratiebestand van de radio het verbruik in de verschillende toestanden op te geven in Ampère en niet in Watt. D wordt bepaald als het verschil tussen de huidige simulatietijd en het tijdstip van de vorige radiotransitie. Vervolgens wordt bepaald welke harvestLevels er sinds t0 gedurende een periode D gedeeltelijk of volledig worden doorlopen. Op Figuur 4.3 wordt dit: D = t1 − t0 = simTime() − t0 = δa + 2 · I + δb . Met deze gegevens kan de geharveste energie in [t0 , t1 ] worden bepaald als: H = δa · HLi + I · HLi+1 + I · HLi+2 + δb · HLc . De eenheid van zowel H als U is coulomb en om het spanningsverschil over de virtuele condensator te vinden, moet er dus geschaald worden met de capaciteit C. Door de vorige spanning over de condensator, de geharveste energie en de verbruikte energie samen in rekening te brengen kan de nieuwe spanning bepaald worden als: H −U Vn = Vo + . C Wanneer de spanning over de condensator daalt onder een bepaalde drempel, wordt een bericht (Resource Mgr Out Of Energy) naar de modules gestuurd, waardoor deze geen verdere berichten meer afhandelen. Aangezien de evaluateEnergy-functie dan niet meer wordt opgeroepen moet de RM tijdelijk deze taak op zich nemen. Periodiek roept de RM de functie bij zichzelf op, de verbruikte energie is dan uiteraard nul. Dit tot de spanning weer is opgebouwd, waarna een bericht (Node Start Up) wordt verstuurd die de nodes weer activeert.

4.4 Conclusie

4.4

35

Conclusie

Een generiek EH energieprofiel werd uiteengezet en de implementatie en functionaliteit ervan op het testbed en in de simulator werd toegelicht. De harvest-consume werking die een virtuele spanning over een virtuele condensator wijzigt staat hierbij centraal. Op het testbed wordt deze virtuele spanning effectief aangelegd aan de sensornode door de reguleerbare spanningsbron van de EE. Op deze manier beschikt de aangesloten sensornode op een real-time manier al dan niet over voldoende energie om te kunnen werken. Om een gelijkaardig gedrag te bekomen in een WSN-simulator wordt gebruik gemaakt van berichtuitwisseling met een speciale module: de resource manager. Deze activeert of desactiveert afhankelijk van de waarde van de virtuele spanning de desbetreffende applicatiemodule.

CASE STUDY: ENERGY HARVESTING ELECTRONIC SHELF LABELING

36

Hoofdstuk 5 Case study: Energy Harvesting Electronic Shelf Labeling De eerste en in deze masterproef meest in detail uitgewerkte case study bestudeert de mogelijkheden om een draadloos sensornetwerk in te schakelen als ESL-systeem. De modules in een ESL-systeem kunnen worden uitgerust met energy harvesters, waarna men spreekt van Energy Harvesting ESL (EHESL). Deze case study werd deels uitgevoerd in samenwerking met GreenPeak [35], een bedrijf gespecialiseerd in draadloze ultra-low-power communicatietechnologie. De vraag van GreenPeak om een door hen uitgevoerde theoretische studie [36] empirisch te bevestigen lag dan ook aan de basis van dit onderwerp. De eerste sectie van dit hoofdstuk geeft een korte inleiding over (EH)ESL en de situering ervan binnen WSNs en EH. De tweede sectie bespreekt de implementatie van een ESL-systeem op zowel het testbed als in een WSN-simulator, dit met behulp van de in hoofdstukken 3 en 4 besproken tools. Vervolgens gaat de derde sectie de werking na van het systeem en de invloed erop door verschillende parameters en factoren. Waar nodig worden de resultaten vergeleken met de theoretische studie. De laatste sectie tenslotte onderzoekt de mogelijkheden van EHESL en de aanpassingen aan het systeem die daarvoor nodig zijn.

5.1 Electronic Shelf Labeling

5.1

37

Electronic Shelf Labeling

Electronic Shelf Labeling of ESL is een systeem dat gebruikt wordt door detailhandelaars om productprijzen weer te geven op de winkelrekken. Elektronische beeldschermmodules worden aan de voorkant van de winkelschappen bevestigd en gebruiken een beeldschermtechnologie zoals LCD of bistabiele dotmatrix om de huidige productprijs te tonen aan de klant [34]. Een communicatienetwerk laat toe de weergegeven prijs automatisch up te daten, periodisch of wanneer een prijs wijzigt. Op deze manier kunnen de hieraan verbonden kosten (werkuren en materiaal wanneer alles manueel moet gebeuren) drastisch worden verminderd en wordt het geheel nauwkeuriger. Ook wordt het aanbieden van een tijdelijke promotie hierdoor eenvoudiger. Op Figuur 5.1 zijn enkele afbeeldingen van ESL-labels te zien.

5.1.1

ESL-systeem als WSN-applicatie

Een ESL-systeem bestaat minstens uit volgende onderdelen: Een centrale controller, verbonden met het vaste stroomnet, die alle aspecten van

het netwerk bestuurt. Deze controller beheert de prijzen en promoties en stuurt de nodige informatie naar de labels en eventuele andere ontvangers. Verder voorziet de controller de netwerkbeheerder van cruciale informatie over het netwerk (bijvoorbeeld defecte of onbereikbare labels) zodat die waar nodig kan ingrijpen. De ESL-labels die om praktische redenen met een individuele energiebron van stroom

moeten worden voorzien. Natuurlijk kan daar waar nodig randapparatuur, zoals een database of access-points tussen labels en controller, aan het netwerk worden toegevoegd . Een schematische figuur van een ESL-netwerk is te zien op Figuur 5.2. Oudere ESL-systemen maken gebruik van infrarood (IR) eenrichtingscommunicatie. Aangezien communicatie hier enkel mogelijk is van de controller naar de labels en niet omgekeerd, zijn deze systemen minder betrouwbaar dan de meer recente radio frequency (RF) systemen. RF maakt het eenvoudiger om tweerichtingsverkeer toe te laten in ESLsystemen, zodat de labels ook statusinformatie (bijvoorbeeld problemen of energiestatus)

5.1 Electronic Shelf Labeling

38

Figuur 5.1: Enkele ESL-labels, zoals ze worden gebruikt binnen een winkel of warenhuis. De modules worden aan de winkelrekken bevestigd en dicht tegen elkaar opgehangen.

Figuur 5.2: Schematische voorstelling van een ESL-netwerk en de verschillende componenten nodig in een dergelijk netwerk. De eindpunten zijn de ESL-labels, de ESL-controller is het geheel van database, user-interface en access-point.

5.2 Beschrijving en implementatie van de applicatie

39

naar de controller kunnen sturen. Naast het weergeven van de productprijs kunnen ESLlabels ook gebruikt worden om periodisch omgevingsfactoren op te meten en deze informatie door te geven aan de controller. Een voor de hand liggend voorbeeld is het meten van de temperatuur in de koelafdeling. De stap van een ESL-netwerk naar een WSN is dus bijzonder klein. Het systeem in deze case voor ogen is een stertopologie waarin de labels beslissen wanneer ze hun prijs willen updaten. Dit doen ze door een request (Request For Update of RFU) naar de controller te sturen die dan een reply (Update of U) met de prijs terugstuurt. Dit ESL-systeem kan model staan voor heel wat sensor/actuator netwerken met een stertopologie waar een centrale controller request-berichten van eindknopen ontvangt en hen reply-berichten terugstuurt. Een request-bericht kan bijvoorbeeld ook een meetwaarde van een sensor bevatten en een reply-bericht de gepaste instructie voor een bepaalde actuator van de eindknoop.

5.1.2

Energy Harvesting ESL

De ESL case study is erg bruikbaar als basis voor het onderzoek naar natuurlijke energiebronnen voor WSNs. De labels kunnen uitgerust worden met een energy harvester en kunnen zo zelf energie gaan verzamelen. Aangezien een ESL-netwerk een eenvoudige stertopologie heeft is dit een goede startpositie. Multihop-netwerken maken het geheel, zeker op vlak van energieverbruik, complexer door de toegenomen hoeveelheid overhead. De EHESL-case kan qua energieverbruik model staan voor heel wat (maar niet alle) singlehop WSN-toepassingen.

5.2

Beschrijving en implementatie van de applicatie

Van het in sectie 5.1 beschreven ESL-systeem moet een abstractie worden gemaakt. Het is immers niet de bedoeling een volledig systeem met zaken zoals user-interface en database te gaan ontwikkelen. Het netwerken communicatieaspect staan hier centraal. Op dat vlak bestaat een ESL-systeem duidelijk uit twee communicerende entiteiten: de labels en de controller. De applicatie wordt daarom ook opgesplitst in twee deelapplicaties, die in de twee volgende subsecties meer gedetailleerd worden besproken.


5.2.1

40

Beschrijving van de ESL-label functionaliteit

De ESL-label applicatie is de software bedoeld voor de nodes die de ESL-labels voorstellen. Deze nodes vragen elke updateperiode UI een update aan de controller. Dit doen ze door een RFU-bericht van 20 bytes naar de controller te sturen. Om contention tussen de verschillende ESL-labels mogelijk te maken, wordt het tijdstip waarop de RFU naar de controller wordt gestuurd random gekozen binnen UI . Op Figuur 5.3 (links) wordt een toestandsdiagramma weergegeven van wat er in een ESL-knoop gebeurt. Het label start een random-timer (het bereik is 0 tot UI ) en wanneer deze timer verloopt, wordt geprobeerd de RFU te verzenden. Daarna wordt een nieuwe timer gestart die wacht tot het einde van het UI -interval, waarna het proces weer opnieuw start. In eerste instantie zijn de labels always-on, waarmee bedoeld wordt dat ze continu luisteren naar het kanaal om te weten wanneer een U-bericht naar hen wordt gestuurd.

5.2.2

Beschrijving van de ESL-controller functionaliteit

De ESL-controller applicatie is de software die draait op één enkele node van het netwerk, de centrale controller. Figuur 5.3 (rechts) toont opnieuw een toestandsdiagramma. De controller wacht op RFUs van de labels en bij het ontvangen van een RFU wordt een 200ms-timer gestart. Wanneer deze timer verloopt, stuurt de controller een U-bericht van 120 bytes terug naar het label die de RFU verstuurde, waarmee de weergegeven prijs kan worden aangepast. Hoe kleiner UI of hoe meer labels in het netwerk aanwezig zijn, hoe groter de kans dat de controller tijdens de 200 ms tussen het ontvangen van een RFU en het zender van de U nog RFUs van andere labels ontvangt. Daarom is het nodig om een wachtrij te voorzien die bijhoudt naar welke labels en ik welke volgorde de Us dienen te worden verstuurd. Ook kan het voorvallen, wanneer twee RFUs vlak na elkaar door de controller worden ontvangen, dat wanneer de 200 ms timer van de tweede RFU verloopt, de controller nog bezig is met het versturen van de U naar het eerste label. Wanneer dit voorvalt en de radio dus nog bezet is, stelt de controller het versturen van de tweede RFU nog eens 200 ms uit. Het vaste tijdsinterval tussen het ontvangen van een RFU en het versturen van een U laat later toe (EHESL) om de slaaptijd van de labels te maximaliseren.


41

Figuur 5.3: Vereenvoudigd toestandsdiagramma van de ESL-label applicatie (links) en ESLcontroller applicatie (rechts). Labels sturen elke UI een RFU naar de controller. De controller stuurt na 200 ms een U terug, tenzij de radio bezet is. Wanneer dat het geval is wordt na opnieuw 200 ms een nieuwe poging ondernomen.

5.3 Experimenten, resultaten en analyse

5.2.3

42

Implementatie van het ESL-systeem

De in de subsecties 5.2.1 en 5.2.2 beschreven functionaliteit wordt omgezet tot code geschikt voor het testbed en code geschikt voor de simulator. Deze code is terug te vinden op de cd-rom onder respectievelijk /Testbed/ESL en /Simulator/ESL. De code is waar nodig voorzien van commentaar. Subsecties A.1 en A.1.2 in bijlage geven een overzicht.

5.3

Experimenten, resultaten en analyse

Eenmaal de implementaties van de ESL-applicatie beschikbaar zijn, kunnen ze gebruikt worden om de werking en eigenschappen van het systeem na te gaan. Een aantal experimenten kunnen worden uitgevoerd waarin de invloed van verschillende parameters wordt onderzocht. In de loop van deze masterproef werden talrijke metingen uitgevoerd. Het is wegens de omvang niet mogelijk alle experimenten hier te vermelden, er is echter getracht een zo volledig mogelijk beeld te geven. Deze sectie heeft als doel de kenmerken, gebreken en mogelijkheden van een ESL-systeem met één enkele controller te onderzoeken. De uitgangssituatie is de vraag van GreenPeak om het gedrag van een dergelijk systeem na te gaan, wanneer gebruik gemaakt wordt van een eenvoudig Medium Access Control (MAC) protocol en een enkele zendfrequentie. De schaalbaarheid waarnaar wordt gestreefd is een systeem met één ESL-controller en 16000 ESL-labels. Door dit grote aantal labels ontstaat een kritische netwerksituatie wanneer alle labels een update nodig hebben. Dit is bijvoorbeeld zo bij het opstarten van het netwerk of een lange periode van inactiviteit. Het is immers enkel dan dat de U berichten van de controllers effectief 120 bytes groot zijn. In de studie van GreenPeak wordt theoretisch verondersteld dat een Carrier Sense Multiple Access with Collision Avoidance (CSMACA) schema geschikt is om de mogelijke botsingen tussen de verschillende pakketten in voldoende mate te vermijden. Dit wordt hier experimenteel nagegaan gebruik makend van het CSMA-CA mechanisme in de TinyOS MAC. Experimenten worden uitgevoerd op het testbed, in de simulator of op beide platformen. De tekst schept daarover duidelijkheid en waar mogelijk zijn de experimenten per thema gegroepeerd. Voor in detail getabelleerde resultaten wordt verwezen naar Bijlage C.


5.3.1

43

RFU/U throughput van de controller

Een belangrijke limiet van het ESL-systeem in de hier beschreven vorm is het aantal RFUs per seconde die de controller kan verwerken en met een U beantwoorden. Aangezien met een enkele controller wordt gewerkt zal deze limiet immers bepalen hoeveel ESL-labels er bij een vooropgestelde updateperiode UI maximaal in het systeem aanwezig kunnen zijn. De limiet is sterk afhankelijk van de gebruikte hardware, in het testbed dus de Tmote Sky en meer specifiek de CC2420-radiochip en MSP430-microcontroller. De radiochip heeft een transmissiesnelheid van 250 kbps, maar het is niet deze bitrate die de beperking vormt. De vertraging tussen het posten van een taak en het uitvoeren van die taak [16] en de delays bij de toestandstransities van de radio zullen de factoren met de sterkste invloed zijn. Het doel dat GreenPeak voor ogen heeft is 16000 labels die éénmaal per vijf minuten (300 seconden) een update vragen aan de controller. Dit komt neer op een gemiddelde workload (of arrival rate) voor de controller van 16000 RFU/U RFU/U = 53.3 . 300 s s De vraag is nu in welke mate de hardware van het testbed in staat is deze waarde te halen. Om een idee te krijgen van de RFU/U throughput wordt een eenvoudig experiment met twee nodes opgezet. Node één (label) probeert elke vijf ms een RFU te sturen naar node twee (controller) die dan een U terugstuurt. Dit gebeurt gedurende één minuut en daarna wordt het aantal succesvol beantwoorde RFUs op node twee geëvalueerd (niet het aantal ontvangen U-berichten bij node één aangezien dan ook het padverlies in rekening wordt gebracht), waaruit de throughput volgt: 2952 RFU/U RFU/U = 49.2 . 60 s s Om volledig correct te zijn, moet worden vermeld dat hier eigenlijk de verwerkingssnelheid tussen twee communicerende nodes gemeten wordt. Node één zal nooit 200 RFUs per seconde halen en moet ook telkens de U ontvangen. Toch is het zo dat de controller meer RFUs heeft ontvangen dan dat hij Us heeft teruggestuurd. De limiet ligt blijkbaar eerder bij het verzenden dan bij het ontvangen (o.a. ook omdat Us groter zijn dan RFUs). Dit toont aan dat de gevonden waarde toch als verwerkingssnelheid van de controller mag dienen. Door slechts twee nodes te gebruiken worden botsingen tussen pakketten bovendien vermeden. Wanneer meerdere RFU-zenders worden gebruikt treden meer botsingen op wat


44

de throughput dan weer naar beneden haalt, wat in metingen met meerdere motes wordt bevestigd (een iets lagere throughput). In verdere tests op het testbed wordt de maximale verwerkingsrate van de controller beperkt tot 40 RFU/U per seconde, dit om niet op de limiet van de hardware te werken. Het is bovendien zo dat 40 RFU/U slechts een gemiddelde verwerkingsrate voor de controller is. Wegens het random zendmoment binnen UI kan de workload tijdelijk hoger zijn, zodat enige marge zeker nodig is. De 40 RFU/U per seconde komt overeen met 12000 labels met een UI van 300s. Dit aantal is dus 25% lager dan de 16000 die was vooropgesteld, maar toch een aanvaardbaar resultaat. Om toch 16000 labels te kunnen voorstellen volstaat het de UI te doen toenemen tot 400 s. Uiteraard zal een ander hard- en software platform een andere limiet hebben.

5.3.2

Mapping van het testbed op de simulator

Zoals eerder vermeld, kan een backtracking tussen resultaten op het testbed en die in een simulator interessant zijn. Dit om conclusies op het ene platform te verifiëren en eventueel bij te sturen met conclusies op het andere platform. Om een dergelijke vergelijking tussen de gegevens op een correcte manier te kunnen maken, is het van belang de simulator af te stellen op het testbed en de situatie daar in de mate van het mogelijke te benaderen. Dit afstellen van de simulator gebeurt door omgevingsfactoren van het testbed op te meten en deze in te geven in de simulator. Een nadeel van deze werkwijze is dat de opgemeten data slechts een momentopname is van het werkelijke gedrag van het testbed. Posities van de nodes Aangezien de positionering van de verschillende nodes in het ESL-scenario een sterke invloed kan hebben op de werking (linkkwaliteit tussen de nodes onderling) van het geheel is het belangrijk deze posities verstandig te kiezen. Castalia biedt volgende mogelijkheden om de nodeposities vast te leggen (SN.deploymentType in omnetpp.ini ): Uniforme randomverdeling binnen een vooraf gedefinieerde rechthoek

(SN.deploymentType = 0) De nodes worden in een grid geplaatst, waarbij het gebied een vierkant moet zijn

(SN.deploymentType = 1)


45

Idem als vorige, maar er komt een random ruisafwijking op de posities

(SN.deploymentType = 2) Manueel ingeven van de (x,y)-co¨ ordinaten van alle nodes in node locations.ini

(SN.deploymentType = 3) De eerste drie opties kunnen in deze case interessant zijn wanneer het aantal nodes wordt opgedreven om een echte ESL-opstelling te gaan benaderen, hierop wordt in subsectie 5.3.5 teruggekomen. Hier is echter de vierde optie van belang om de mapping van het testbed op de simulator te kunnen maken. De nodeposities van de motes op de derde verdieping van het testbed (80 m op 12 m) zijn daarom uitgezet op een (x,y)-diagram dat terug te vinden is op Figuur B.2. Connectiviteit Het draadloos kanaalmodel in Castalia kan worden bijgestuurd door het manueel ingeven van Received Signal Strength Indication (RSSI) en Packet Reception Ratio (PRR) waarden op bepaalde links. Deze indicatoren voor linkkwaliteit kunnen worden opgemeten in het echte testbed en dienen dan als input voor de simulator (rxSignal ConnectivityMap en PRR ConnectivityMap in de .ini van het draadloos kanaal), wat hier erg handig is. Links waarvoor geen dergelijke waarde wordt ingegeven worden geëvalueerd aan de hand van het standaard parametrische model. De waarden worden in een string ingegeven als door komma’s gescheiden statements van de vorm node1->node2(txlevel)=value. De meest nauwkeurige oplossing zou er hier uit bestaan de RSSI van alle links (elk label naar de controller, de controller naar elk label, de labels onderling) in het ESL-netwerk op te meten. Een probleem hier is de erg beperkte maximale lengte van de string, want 40 links ingeven blijkt hier al teveel (bidirectionele links, dus 80 RSSI-waarden). De oplossing is om de 40 links van de controller naar de labels in te geven met RSSI-waarde en de 40 links van de labels naar de controller als PRR-waarde. De links tussen de labels onderling, die vooral hun belang hebben bij de al dan niet correcte CSMA-CA werking worden niet manueel ingegeven. Hier wordt nog opgemerkt dat in Castalia 2.0 de PRR- en RSSI-waarden niet meer in een string, maar in een individuele inputfile dienen te worden ingegeven. Dit lost de eerder vermelde beperking op het aantal links op.


46

Om de RSSI-waarden in het testbed op te meten wordt gebruik gemaakt van RadioPerf, een Java-applicatie met GUI ontwikkeld binnen IBCN. Deze applicatie laat o.a. toe continu pakketten met een bepaalde pakketgroote (hier een U van 120 bytes) te versturen tussen nodes naar keuze en de minimale, gemiddelde en maximale RSSI gemeten bij de ontvangers aan de hand van rapporteringsberichten in een grafiek te plotten. Mote 3A-27 wordt geconfigureerd als zender en de corresponderende gemiddelde RSSI wordt uitgelezen op de andere motes. Tabel C.1 geeft de resultaten van deze metingen weer. De alfanumerieke naam van de geselecteerde motes (verspreid over de ganse derde verdieping) en de nodeID van de node in de simulator waarop ze worden gemapt worden eveneens weergegeven. Om de PRR op de links van de labels naar de controller te bepalen, stuurt elk label achtereenvolgens 500 pakketten (RFU van 20 bytes) naar de controller. Wanneer het aantal pakketten door de controller ontvangen gegeven wordt door Rctrl volgt de PRR meteen: Rctrl . 500 Ook deze PRR waarden zijn terug te vinden in Tabel C.1. PRR =

5.3.3

ESL-systeem met 40 nodes

Eenmaal het testbed en de simulator op elkaar zijn afgesteld, kunnen enkele tests op beide platformen worden uitgevoerd en vergeleken. Bij een eerste experiment wordt de in subsectie 5.3.2 bekomen testen simulatieopstelling gebruikt om de werking van een ESLsysteem na te gaan. Deze opstelling beschikt slechts over een beperkt aantal netwerkknopen (40), wat veel minder is dan bij een realistisch ESL-systeem (duizenden). Dit kan in eerste instantie worden verholpen door de UI -updateperiode per node in de testopstelling op te drijven. Een enkele node in de testopstelling stelt dan meerdere nodes van het reële netwerk voor. Wanneer de updateperiode van een reëel netwerk op 300 seconden wordt vastgelegd, komt een node uit de testopstelling met een RFU/U-periode UI overeen met

300 UI

geëmuleerde nodes. Een interessante vraag is hier of deze werkwijze correct is,

m.a.w. zullen de resultaten bekomen met de testopstelling (weinig nodes met hoge RFU/Ufrequentie) overeenkomen met de resultaten die zouden gevonden worden in een echt ESLsysteem (veel nodes met lage RFU/U-frequentie). Hiervoor wordt vewezen naar subsectie 5.3.5.


47

In dit experiment wordt een UI van één seconde gekozen. Aangezien de opstelling 40 labels bevat, is de gemiddelde workload voor de controller 40 RFU/U per seconde. Dit is de maximale waarde gekozen in subsectie 5.3.1 en deze workload komt overeen met die bij 12000 labels met een UI van 300 s. Elk ESL-label stuurt (of probeert dat in ieder geval) 200 RFUs naar de controller, dit dus in een tijdspanne van 200 seconden. Nadien wordt het aantal succesvol ontvangen Us per label geëvalueerd. Volgende relevante MAC-parameters worden geselecteerd: ACKs zijn niet actief Geen retries na wegblijven ACK (zonder ACKs is dit trouwens niet mogelijk) IBWlabel = IBWcontroller = 0 CBWlabel = 250, CBWcontroller = 0.

Dat de keuze van deze parameters terecht is, wordt later in meer detail aangetoond. In Tabel C.3 zijn de gedetailleerde resultaten van dit experiment te zien. Naast de alfanumerieke naam (testbed) van elke node wordt het aantal correct afgehandelde (een U werd ontvangen) RFUs weergegeven, dit zowel voor het testbed als de simulator. Deze resultaten worden in de hierna volgende onderdelen geanalyseerd. Gemiddelde succesrate Om van een goed ESL-systeem te kunnen spreken, is een voldoende hoge gemiddelde succesrate (GS ) vereist. De gemiddelde succesrate hier behaald, bedraagt op het testbed 91.0% en in de simulator 91.5% (er wordt hier en in het vervolg afgerond tot op het dichtstbijzijnde halve %). Deze waarden leunen bijzonder dicht bij elkaar aan, wat wijst op een correcte werking van beide implementaties en betrouwbare resultaten. Alhoewel testbed en simulatie qua gemiddelde succesrate goed overeenkomen, is dit niet altijd zo bij de succesrates van de individuele nodes. De gemiddelde en maximale afwijking is respectievelijk 3.5% en 12.5%. Deze verschillen tonen aan dat de implementaties op de twee verschillende platformen niet louter een kopie zijn van elkaar. Ondanks verschillen tussen de individuele nodes wordt uiteindelijk toch een gelijkaardig gemiddelde gevonden, wat de betrouwbaarheid nog eens bevestigt.


48

Afwijking van de succesrate t.o.v. het gemiddelde bij individuele nodes Een interessante en belangrijke factor bij het bestuderen van de succesrate van het ESLsysteem is de afwijking bij individuele labels t.o.v. het gemiddelde. Deze afwijking speelt een niet te onderschatten rol bij het evalueren van de bruikbaarheid van het ESL-systeem als geheel. Een hoge GS is vereist voor een goed werkend systeem, maar het is minstens even belangrijk dat niet enkel de gemiddelde maar ook de individuele succesrates (IS ) van de verschillende ESL-labels voldoende hoog zijn. Een systeem met hoge GS waar labels (al zij het een klein percentage) een erg lage IS hebben kan minder goed zijn dan een systeem met een iets lagere GS , maar waar de IS van de labels onderling slechts weinig verschilt. Een afweging dient hier dus wat worden gemaakt bij het definiëren van evaluatiecriteria. Figuur 5.4 geeft per node de procentuele afwijking t.o.v. de gemiddelde succesrate grafisch weer, dit opnieuw voor de waarden gevonden in de simulator en op het testbed. Hierbij dient te worden opgemerkt dat afwijkingen geordend zijn van laag naar hoog en dat deze ordening verschilt tussen simulator en testbed (wegens de eerder opgemerkte verschillen tussen individuele nodes). Het verloop van de resultaten bij simulator en testbed komt opnieuw erg goed overeen. Tabel 5.1 geeft enkele statistieken weer. Ondanks de vrij hoge maximale negatieve afwijking bedraagt de gemiddelde negatieve afwijking slechts -3% op het testbed en -3.5% in de simulator. Slechts twee nodes vertonen een negatieve afwijking van meer dan 5%. Spatiale verdeling van de succesrate Uit de gegevens blijkt dat de IS varieert tussen 80% en 100%. Het is interessant om een verklaring voor deze variatie te zoeken. In een poging hiertoe worden de waarden in Tabel C.3 gerelateerd aan hun positie binnen de testopstelling, dit gebeurt eens voor de simulator en eens voor het testbed (de posities zijn wegens de mapping uiteraard gelijk). De resultaten worden telkens in vier categorieën (bij benadering even groot) onderverdeeld: Max. neg. (S)

Max. neg. (T)

Max. pos. (S)

Max. pos. (T)

-12%

-11.5%

8%

8%

Tabel 5.1: Maximale negatieve en positieve afwijking van de individuele succesrates (IS ) t.o.v. de gemiddelde succesrate (GS ) in de simulator (S) en op het testbed (T).


49

Figuur 5.4: Procentuele afwijking van de 40 individuele succesrates (IS ) t.o.v. de gemiddelde succesrate (GS ) in de simulator en op het testbed.

zeer goed (10 beste waarden), goed, gemiddeld en matig (10 minst goede waarden). Er dient te worden opgemerkt dat met deze categorieën slechts een ruwe opdeling wordt gemaakt en dat het verschil tussen categorieën (vooral aan de grenzen ertussen) soms vrij marginaal is. Op Figuur 5.5 worden op het grondplan van de testopstelling de nodes behorende tot de verschillende categorieën aan de hand van een kleurcode aangeduid (simulator links, testbed rechts), dit op de locatie van de nodes. De kleurcodes horende bij de verschillende categorieën zijn respectievelijk groen, geel, oranje en rood. Uit de twee deelfiguren blijkt dat de nodes behorende tot de verschillende groepen niet volledig willekeurig door elkaar verspreid liggen. Een vorm van groepering in zones is te zien. Deze zones zijn vaak een enkele ruimte (kamer, gang) of een aanéénschakeling van enkele nabijgelegen ruimtes. Een erg duidelijke zone is de centrale groene zone in de buurt van de controller, de nodes in deze zone halen de hoogste succesrate. Ook valt het op dat nodes aan de uiteinden en in de hoeken van het netwerk duidelijk minder goede resultaten behalen. Bij de overige nodes zijn de zones wat minder afgebakend, maar algemeen kan op wat uitzonderingen na worden gesteld dat de meer centraal gelegen nodes een betere succesrate halen dan de nodes in de buurt van de randen. Twee verklaringen kunnen hier worden voorgesteld:


50

Bij een toenemende afstand tussen label en controller gaan door het padverlies meer

pakketten verloren. Naast de afstand hebben ook diverse obstakels hun invloed op de linkkwaliteit tussen bepaalde labels en de controller. Niet centraal gelegen nodes kunnen de controller wel bereiken, maar naarmate ze

meer aan de uiteinden van het netwerk liggen, vermindert de connectiviteit met de andere nodes in het netwerk. Deze nodes zijn dan meer blootgesteld aan het hiddennode-problem (nodes die elkaars signaal niet kunnen detecteren, wat tot een niet correcte CSMA-CA werking leidt). Centrale nodes hebben een betere connectiviteit met de andere nodes in het netwerk en zijn dus minder gevoelig voor dit probleem. Beide vaststellingen zijn conform met het feit dat de zones vaak bestaan uit één of meerdere nabijgelegen ruimtes. Het is uiteraard logisch dat bepaalde van die zones in het netwerk een minder goede ontvangst hebben of meer aan interferentie zijn blootgesteld.

5.3.4

Invloedsfactoren op de succesrate

In deze subsectie wordt onderzocht van welke factoren de succesrate bekomen in subsectie 5.3.3 afhankelijk is. Hiervoor worden enkele experimenten met telkens opnieuw 40 labelnodes uitgevoerd. Het is echter niet zo dat deze metingen altijd op dezelfde nodes gebeuren. De webinterface van het testbed is zo geconfigureerd dat motes waarmee iets mis is tijdelijk uitgeschakeld worden. Niet alle motes zijn dus op elk moment beschikbaar, wat voor enige variatie in de 40-knopen testopstelling heeft gezorgd. Deze variatie maakt vergelijken soms iets moeilijker, maar is zeker niet slecht aangezien op deze manier meer netwerksituaties worden onderzocht en niet enkel de opstelling uit subsectie 5.3.3. Omgeving Het testbed heeft de omgeving waarin het is opgebouwd als beperking. Deze beperking uit zich op twee vlakken: Het testbed is uitgerold binnen een office-omgeving. Alhoewel een dergelijke om-

geving als vrij allround kan worden beschouwd, is het toch niet voorspelbaar of het netwerk zich in een andere omgeving (zoals een warenhuis in deze context) op dezelfde manier zal gaan gedragen.


51

Figuur 5.5: Spatiale verdeling van de succesrate: simulator (links), testbed (rechts). De resultaten worden afhankelijk van de succesrate opgedeeld in vier categorieën met kleurcodes groen (best), geel, oranje en rood (minst goed).


52

Naast omgevingsfactoren speelt de ruimte en vooral de afmetingen ervan waarbinnen

het testbed is opgesteld een rol. De testopstelling is vrij rechthoekig van vorm en het is niet uit de sluiten dat een andere geometrie andere effecten teweegbrengt. Aan deze beperkingen valt weinig te veranderen, aangezien het testbed statisch is. De simulator is niet verbonden aan een bepaalde omgeving en de geometrie van het netwerk ligt ook niet vast. Om de afhankelijkheid van het testbed (die er is door de mapping) te vermijden wordt eerst onderzocht wat de succesrate is wanneer de ingegeven PRR- en RSSI- waarden op de links buiten beschouwing worden gelaten. De nodeposities blijven die van de mapping. De belangrijkste parameter van het draadloos kanaal is nu het padverlies P L(d0 ) in dBm op een afstand d0 van een zender. Standaard is deze 55 dBm (1 m). Tabel C.5 (eerste kolom) toont aan dat bij dit padverlies een achttal labels geen connectie met de controller kunnen opzetten. Wanneer het padverlies tot 50 dBm wordt verlaagd (tweede kolom) is dit maar één label meer. De gemiddelde succesrate bedraagt zonder dit label 96.5%. Het verschil met de eerder gevonden GS van 91.5% toont aan dat de omgeving (die zich uit als het padverlies en variaties erop) dus weldegelijk een invloed heeft. Wanneer het padverlies te hoog wordt zullen nodes op een te grote afstand van de controller geen connectiviteit meer hebben. Propagatie-effecten in de gangen van het testbed kunnen dan weer zorgen voor een hogere connectiviteit met bepaalde labels. Deze zaken tonen aan dat een draadloos kanaal vrij moeilijk te parametriseren valt. Om de invloed van de geometrie van het netwerk na te gaan wordt in plaats van de nodeposities van de mapping (70 m op 9 m), een uniforme gridopstelling binnen een vierkant van 30 m op 30 m wordt gebruikt. De resultaten zijn opnieuw terug te vinden in Tabel C.5 (kolommen drie tot vijf). Bij een P L(1m) van 50 dBm bedraagt GS opnieuw 97.5%. Bij 55 dBm is dit 96.5% en bij een ideaal draadloos kanaal 99%. Uit deze gegevens blijkt opnieuw de invloed van het padverlies op de succesrate. De geometrie heeft hier ook een invloed, wat kan worden toegeschreven aan de afgenomen afstanden binnen de nieuwe opstelling. De twee voorgaande zaken benadrukken de invloed van de locatie van de netwerkuitrol op de resultaten. Als afsluiter van dit onderdeel nog de opmerking dat de nodes in deze masterproef steeds in het (x,y)-vlak zijn opgesteld. Dit is zo in het testbed en in de simulator. Castalia 2.0 laat in tegenstelling tot versie 1.3 toe ook z-coördinaten toe te voegen. Dit kan een bijkomende


53

factor zijn die het onderzoeken waard is. In een echte ESL-opstelling zullen labels immers ook boven elkaar worden opgehangen. Ook kan het zijn dat de positie van de controller wel centraal in het (x,y)-vlak kan worden gekozen, maar dat dit om praktische redenen niet mogelijk is voor z. Dit kan een extra beperking zijn, o.a. door afstanden die hierdoor toenemen. Positie van de controller Vorige onderdelen toonden reeds aan dat afstanden tot de controller een rol spelen bij de succesrate van een label. Meer nabijgelegen nodes halen een betere succesrate en nodes die te ver van de controller verwijderd zijn een lagere (of zelf geen). Het is dus zo dat onafhankelijk van de opbouw van het netwerk de connectiviteit tussen de labels en de controller gegarandeerd moet blijven. Het lijkt logisch de positie van de controller centraal in het netwerk te kiezen, wat de geometrie ervan ook is. Om de invloed van de positionering van de controller binnen het netwerk te onderzoeken wordt een nieuwe test opgezet. Opnieuw worden 40 motes voorzien van de labelapplicatie en één mote met de controllerapplicatie, zoals ook het geval was in sectie 5.3.3. De instellingen van de applicaties blijven ongewijzigd. De labelposities worden nu wat minder mooi over de verdieping verdeeld, deze posities kunnen in een echte opstelling ook niet altijd vrij worden gekozen. Zo goed als alle nodes van 3A worden als label ingeschakeld, in 3B een tiental nodes in het bereik 3B-1 tot 3B-15. De meting wordt vijf maal herhaald, telkens met een andere positie voor de controller. Deze posities, allen centraal gelegen, zijn achtereenvolgens 3A-15, 3A-21, 3A-27, 3A-29 en 3A-31. Tabel C.7 geeft een gedetailleerd overzicht van de resultaten. Uit de tabel blijkt dat enkel bij de meting met mote 3A-27 als controller alle labels erin slagen bidirectioneel met de controller te communiceren. In de vier andere gevallen haalt minstens één label een wel erg lage succesrate, wat wijst op een slechte communicatielink (eventueel tijdelijk) tussen de desbetreffende node en de controller. In een echte opstelling zal het typisch zo zijn dat labels erg dicht naast elkaar worden opgehangen (zie bijvoorbeeld Figuur 5.1). In zo’n opstelling zou zo’n slechte communicatielink dan eerder een groepering van nabijgelegen nodes kunnen be¨ınvloeden i.p.v. een enkele node zoals hier het geval is. Het is niet zo dat de succesrate ofwel hoog ofwel erg laag is zoals bovenstaande bespreking zou kunnen doen vermoeden. Een geleidelijke degradatie treedt weldegelijk op en is in de tabel bijvoorbeeld


54

te zien aan de waarden voor node 3B-15 (node 39 in de tabel) wanneer de afstand tot de controller toeneemt door deze laatste te verplaatsen van 3A-27 via 3A-21 naar 3A-15. De afstand tot de controller heeft dus zoals eerder opgemerkt een invloed op de succesrate bij de labels. In de tabel is het ook duidelijk dat wanneer 3A-27 als controller fungeert de relatief verafgelegen nodes 29-34 (3B-2 tot 3B-7) een eerder lage succesrate halen. Naast de afstand spelen ook eerder toevallige (omgevings)factoren een rol, want uit de tabel blijkt dat de succesrate niet altijd omgekeerd evenredig is met de afstand. Deze toevallige factoren zijn tijdsafhankelijk wat bevestigd wordt in de bespreking van de tijd als invloedsfactor hierna. De invloed van de controllerkeuze uit zich hier niet echt op vlak van de GS , maar eerder op de connectiviteit met bepaalde nodes die wegvalt. Een interessant verder onderzoeksitem kan zijn om de optimale controllerpositie binnen een netwerk te bepalen zonder dat sommige nodes worden uitgesloten. Een eventuele vereiste opdeling in zones met elk hun eigen controller kan hier worden overwogen. Tijd In de loop van deze masterproef werden heel wat succesrate-metingen op het testbed uitgevoerd. Veel van deze tests vonden plaats in de ontwikkelfase van de applicaties en zijn daarom niet altijd het vermelden waard. Wel is het zo dat deze metingen een idee geven over het al dan niet constant zijn van de resultaten in de loop van de tijd. In tests met 40 labels (aan 1 RFU/U per seconde) bleek de succesrate tussen 89% en 92% te variëren (wanneer nodes die nagenoeg niks ontvangen buiten beschouwing worden gelaten). Deze variatie is deels te wijten aan het niet steeds gelijk zijn van de gebruikte nodes. Verder is het zo dat fluctuaties ervoor zorgen dat bepaalde nodes tijdelijk niet bereikbaar zijn. Om dit gedrag meer in detail te onderzoeken geeft Tabel C.9 de resultaten weer van vijf identieke metingen op verschillende tijdstippen: een eerste meting, dezelfde meting een maand later en drie metingen vlak na elkaar nog eens twee dagen later. De GS in deze metingen schommelt telkens rond de 91% en de opstelling is gelijkaardig aan die uit subsectie 5.3.3. Op tijdstip t2 blijken twee knopen uit de testopstelling heel slecht te presteren. De desbetreffende knopen zijn 3B-3 en 3B-6, twee nabijgelegen nodes in een hoek van het netwerk. Dergelijk gedrag werd in de loop van de tijd bijvoorbeeld ook


55

vastgesteld op node 3A-16, een meer centraal gelegen node. Uit de metingen op tijdstip t3 blijkt dat het gedrag in een korte tijdspanne vrij stabiel is, maar dat toch fluctuaties optreden. De gemiddelde succesrates zijn hier echter vrij ongevoelig voor. Uit deze vaststellingen blijkt dat tijdelijke fluctuaties in het netwerk ervoor zorgen dat bepaalde nodes er niet in slagen tweerichtingscommunicatie met de controller op te zetten (het probleem kan dus liggen in de link van label naar controller, maar ook omgekeerd). Deze tijdelijke fluctuaties kunnen bijvoorbeeld veroorzaakt worden door externe interferentie of obstakels in de buurt van deze nodes. Het is vrij evident dat nodes aan de uiteinden van het netwerk hier meer gevoelig voor zullen zijn wegens hun in verhouding zwakkere links met de controller. Ook interne factoren spelen hier een rol. De nodes worden door de testbed-interface niet altijd op exact hetzelfde moment geactiveerd (dit is ook zo in een EHESL-situatie door randomeffecten door de energy harvesters). Dit verschil in timing kan leiden tot meer of minder botsingen. Dit gedrag is voor geen van de nodes in het netwerk uit te sluiten, dus ook niet voor de controller. Voor de labels is dit mits de periodes waar er geen connectiviteit is niet te lang duren aanvaardbaar, maar voor de controller is dit niet zo. Dit heeft als gevolg dat het moeilijk wordt dezelfde hardware te gebruiken voor de controller als voor de labels. Aangezien de controller toch over een vaste energiebron kan beschikken, kan hier dus beter voor een variant met een hoger zendvermogen worden gekozen. Een andere optie is het inzetten van een reservecontroller, maar wegens de vereiste centrale ligging zit er niet heel veel speling op de positionering van deze tweede controller. Dit verhoogt de kans dat ook de connectiviteit met de reservecontroller niet optimaal is. Uit de resultaten van tijd en positie van de controller kunnen enkele conclusies worden getrokken: De afstand label-controller moet worden beperkt om de linkkwaliteit voldoende hoog

te houden. Daarom is een centrale positionering van de controller aangewezen. Een slechte positionering leidt tot een daling van de succesrate of verlies van connectie bij bepaalde nodes. Obstakels en andere vrij onvoorspelbare factoren zorgen ook voor een lagere suc-

cesrate of een verlies van connectiviteit. Deze fluctuaties treden niet enkel op bij


56

nodes aan de uiteinden van het netwerk, maar ook bij relatief kleine label-controller afstanden. De hierboven vermelde fluctuaties blijken van een tijdelijke aard te zijn in de testop-

stelling. De beperking op de afstand tussen label-controller bepaalt de maximale grootte van de ruimte waarbinnen een ESL-systeem kan worden uitgerold met een enkele controller. De gebruikte testopstelling blijkt dit maximum te benaderen wegens de soms slechtere resultaten aan de uiteinden van het netwerk. De aard en tijdspanne van bepaalde fluctuaties is afhankelijk van de omgeving waarin het systeem wordt uitgerold. Een tijdelijk verlies van connectiviteit met bepaalde labels kan aanvaardbaar zijn op voorwaarde dat dit niet te lang duurt. Aangezien deze tijdsduur vrij onvoorspelbaar kan zijn, is het niet slecht hier een andere optie te overwegen. Een idee is om het netwerk van twee controllers te voorzien in plaats van één. Voor het sturen van een RFU kiest het label dan random één van de twee controllers, zodat het risico van slechte connectiviteit wat over deze controllers wordt gespreid. Tabel C.11 vergelijkt de resultaten wanneer 3A-25 en 3A-29 gebruikt worden (tweede kolom) als controllers i.p.v. 3A-27 (eerste kolom). Uit de tabel blijkt dat het gewenste resultaat niet bekomen wordt, integendeel waar eerst geen enkele node een slechte connectiviteit had zijn dit er nu twee geworden, zonder dat de gemiddelde succesrate stijgt. Dit kan worden toegeschreven aan de minder optimale ligging van de twee controllers. In deze implementatie is het zo dat de kans waarbij de RFU naar 3A-25 wordt gestuurd, gelijk is aan de kans dat de RFU naar 3A-29 wordt gestuurd. Wanneer dus een node met één van de twee controllers een slechte connectie heeft en met de andere een goede zal toch ongeveer 50% van de RFUs verloren gaan. Een betere oplossing zou zijn om de labels nog een stuk intelligenter te maken. Het vorige probleem kan worden vermeden door de labels van controller te laten switchen wanneer drie opeenvolgende RFUs niet worden beantwoord met een U, dit als vervanging van het randommechanisme bij de controllerkeuze. Een voorstel hier is om twee controllers te gebruiken, waarvan de eerste zich op de optimale positie bevindt (hier dus 3A-27) en de tweede op een andere positie. Deze tweede positie moet enerzijds voldoende ver van de eerste zijn verwijderd (om de kans dat de connectiviteit met beide controllers slecht is te doen dalen), maar anderzijds ook centraal genoeg gelegen zijn (wegens het belang van die centrale ligging). Standaard sturen de labels hun RFUs naar de eerste controller, maar


57

na x aantal onbeantwoorde RFUs wordt overgeschakeld naar de tweede. Op deze manier wordt de optimale positie van de controller toch benut, maar is er bij een slechte connectie met deze controller toch nog een backupcontroller beschikbaar. Eventueel kan ook op een ander kanaal met de reservecontroller worden gecommuniceerd. Dit voorstel werd binnen het kader van deze masterproef niet verder onderzocht. Mediumbezetting Dit onderdeel wijkt wat af van de andere in deze subsectie. Waar anders steeds 40 labelnodes per experiment worden gebruikt, wordt hier net de invloed van het aantal RFU/U-cycli per seconde (in het ganse netwerk) onderzocht. Hoe meer berichten worden verstuurd, hoe hoger de bezetting van het medium is en hoe groter de kans wordt dat botsingen tussen pakketten optreden. Het aantal RFU/U-cycli per seconde kan op twee manieren worden be¨ınvloed: UI bepaalt hoe vaak elk label een RFU verstuurt. Door UI te verkleinen vergroot

het aantal RFU/U per seconde. Bij een vaste UI bepaalt het totaal aantal labels in het netwerk het aantal RFU/U

per seconde. Meer nodes betekenen meer RFU/U per seconde. Beide methodes worden onderzocht. Op Figuur 5.6 wordt het verloop weergegeven van GS i.f.v. het aantal RFU/U per seconde in een opstelling met 40 labels met een variabele UI (experiment 1). Figuur 5.7 toont ditzelfde verloop, maar dan in de simulator (experiment 2). Beide figuren tonen een vrij lineair verband tussen de succesrate en het aantal RFU/U per seconde. Dit lineaire verband wordt bevestigd in Figuur 5.8, waar met een vaste UI van één seconde, het aantal labels varieert van één tot 40 (experiment 3). Hierbij dient te worden opgemerkt dat de testopstelling (testbed) van figuren 5.6 en 5.8 niet dezelfde is (gedeeltelijk andere nodes). De GS bij 40 RFU/U per seconde bedraagt respectievelijk 89% en 91%. Verder komen de resultaten van beide experimenten vrij goed overeen. De variatie tussen één en 40 nodes bedraagt 9%. De variatie tussen UI = 1 s en UI = 40 s is 8%. Hier zijn twee zaken voor verantwoordelijk: De 40 uiteindelijk gebruikte labelnodes in experiment 1 en 3 zijn niet gelijk. Expe-

riment 3 haalt bij 40 RFU/U per seconde een hogere GS .


58

In experiment 3 worden de labels één voor één toegevoegd. Dit niet willekeurig, maar

van het centrum van het netwerk uit. Eerst dus de labels dichts bij de controller gelegen (deze hebben een hogere succesrate). Dit verklaart ook de iets sneller dan lineaire daling. In experiment 1 zijn de gebruikte labels altijd dezelfde. Het is logisch dat wanneer de mediumbezetting stijgt er kans op botsingen toeneemt. Botsingen kunnen als volgt optreden: Twee labels voeren hun Clear Channel Assessment (CCA) ongeveer op het zelfde

moment uit, merken dat het medium vrij is en beginnen tegelijkertijd te sturen. Twee labels kunnen elkaars signaal niet detecteren, waardoor hun CCA leidt tot een

foutieve beslissing. Hoe groter het aantal labels, hoe groter de kans één van bovenstaande situaties zich voordoet. De helling van de trendlijn in experiment 2 (simulator) is lager dan bij de twee andere experimenten (testbed). Een eventuele verklaring kan de sterkere afhankelijkheid van het padverlies zijn. Initial backoff Een radiobackoff is een tijdsperiode waarin de radio pauzeert alvorens een poging te ondernemen om een pakket te versturen [37]. In de B-MAC implementatie van TinyOS zijn drie backofftypes voorzien: initial, congestion en (Low Power Listening) LPL. Deze laatste is enkel van belang wanneer LPL wordt geactiveerd, wat in deze case niet het geval is. De andere twee backofftypes zijn hier wel van toepassing. De initial backoff is de radiobackoff bij de eerste poging om het pakket te versturen, m.a.w. de tijdspanne tussen de opdracht een bericht te verzenden en het moment waarop de radio het pakket effectief probeert te versturen. Deze initial backoff heeft als doel de kans te verkleinen dat twee zenders op hetzelfde ogenblik een pakket proberen te zenden. Dit kan door de initial backoff voldoende random te kiezen. De initial backoff window (IBW) bepaalt het bereik waarbinnen een randomwaarde wordt gekozen. Hoe kleiner dit bereik hoe groter de kans op botsingen, maar hoe hoger de throughput (er moet immers per pakket minder lang worden gewacht). In deze case heeft het echter geen zin een initial backoff te gebruiken en bijgevolg wordt


59

Figuur 5.6: Gemiddelde succesrate i.f.v. het aantal RFUs per seconde. Door in een opstelling met 40 nodes de RFU/U-periode UI te variëren wordt deze arrivalrate be¨ınvloed.

Figuur 5.7: Gemiddelde succesrate i.f.v. het aantal RFUs per seconde. Door in een opstelling met 40 nodes de RFU/U-periode UI te variëren wordt deze arrivalrate be¨ınvloed.


60

Figuur 5.8: Gemiddelde succesrate i.f.v. het aantal RFUs per seconde. Het aantal label-nodes wordt opgedreven van 1 tot 40.

een IBW van nul gekozen. Het weglaten van de initial backoff heeft niet als gevolg dat het aantal botsingen toeneemt. Het is immers zo dat reeds op applicatieniveau de momenten waarop de RFUs worden gestuurd random gekozen zijn binnen de update-intervallen, hier nog eens een random initial backoff aan toevoegen heeft dus weinig zin. Congestion backoff Het tweede type van radiobackoff is de congestion backoff. Deze backoff bepaalt de tijdspanne tussen een nieuwe zendpoging van de radio en een eerder niet-geslaagde poging (negatieve CCA). Ook hier wordt per pakket een random congestion backoff gekozen uit de congestion backoff window (CBW). Deze randomkeuze zorgt ervoor dat wanneer verschillende zenders vaststellen dat het medium in gebruik is (een andere zender is iets aan het sturen) ze niet op hetzelfde ogenblik een nieuwe poging ondernemen, wat de kans op een botsing zou verhogen. Door een lage CBW aan een bepaalde node toe te kennen krijgen pakketten van deze node een vorm van prioriteit t.o.v. pakketten van andere zenders, hoe lager de congestion backoff immers is hoe sneller een nieuwe zendpoging wordt ondernomen en hoe hoger de kans is dat de node als volgende het medium kan bezetten. Wanneer vele


61

zenders met elkaar in contention treden (zoals in deze case het geval is met de labels) moet een te lage CBW worden vermeden, aangezien de nodes dan de neiging zouden krijgen het kannaal te blokkeren. Een geschikte CBW is voldoende groot t.o.v. de transmissietijd van een pakket. In sectie 5.3.3 werd voor de labels een CBW van 250 gekozen. Van de uitgewisselde berichten is de U van 120 bytes de grootste. Aan een transmissiesnelheid van 250 kbps doet de conroller er ongeveer 4 ms over om een U te versturen. Als nu een CBW van twee keer deze tijd wordt vooropgesteld dan geldt: 8 ms ≈ 250 ·

1 s 32768

Aangezien de CBW dient te worden ingegeven als een gehaal aantal ticks van een binaire 32 kHz klok, verklaart dit de gekozen 250. Voor de controller is het niet aangewezen een CBW te gebruiken aangezien het tijdstip waarop de U een label bereikt dan vrij onvoorspelbaar wordt. Om de invloed van de gekozen CBW op de succesrate na te gaan toont Tabel C.13 de bekomen resultaten bij verschillende CBW-waarden. In tegenstelling tot wat werd verwacht, schommelt GS steeds rond de 88% en 89%. Er is niet echt een trend tussen de CBW en de succesrate te zien en de afwijkingen zijn eerder te wijten aan fluctuaties. Op de verklaring hiervoor werd een hele tijd gezocht, maar uiteindelijk werd een oplossing vooropgesteld. Volgende factoren spelen een rol: Zoals later zal worden aangetoond bedraagt de maximaal mogelijke mediumbezetting

in deze case zo’n 17.5% wanneer alle labels op een ander moment binnen UI sturen en geen botsingen optreden. De echte mediumbezetting zal lager zijn aangezien niet alle labels erin slagen botsingen te vermijden. De grootte van de CBW speelt enkel een rol wanneer meerdere labels op hetzelfde moment een bezet medium waarnemen. De kans dat een label een bezet medium treft is vrij groot, maar de kans dat meerdere labels op hetzelfde moment een bezet medium treffen is minstens een grootteorde kleiner. Figuur 5.9 geeft een mogelijk verloop van de mediumbezetting weer. Voor de vereenvoudiging wordt de opeenvolging van RFU en U als een aaneensluitende puls van 5 ms voorgesteld (geen 200 ms ertussen). Om deze figuur op te stellen werden 40 randomwaardes tussen 0 en 1000 gegenereerd. Op elk randomtijdstip werd dan een puls van 5 ms gestart. Overlappende pulsen werden verschoven tot ze net naast elkaar liggen (net alsof er continu een CCA gebeurt tot het medium vrij is). Uiteindelijk worden drie pulsen van 15 ms bekomen, twee van 10 ms en 35 van 5 ms. De drie


62

driedubbele pulsen ontstonden hier telkens door het opschuiven van de tweede puls. Dus in geen van de gavallen is er contention tussen meerdere labels. Dit illustreert hoe klein de kans hiervoor is. Een hoge CBW vermijdt enkel botsingen wanneer de CCA correct werkt. Wanneer

veel hidden nodes in het netwerk aanwezig zijn, zal dat eerder de beperkende factor zijn. Een lage CBW leidt niet zeker tot botsingen, maar verhoogt de kans enkel.

Deze factoren leiden samen tot het feit dat de GS onafhankelijk is van de CBW. De volgende drie puntjes onderzoeken de invloed van CCA, ACK en retries op de succesrate. Deze experimenten zijn aan elkaar gerelateerd en werden in opeenvolgende metingen uitgevoerd. Daarom combineert Tabel C.15 de resultaten, kolom A is steeds de referentie. Clear Channel Assessment De succesrate is zoals aangetoond onafhankelijk van de IBW en CBW. Het is interessant na te gaan of het dan wel nog effectief nodig is een CCA uit te voeren alvorens een pakket te versturen. Deze CCA verhoogt immers het energieverbruik van de labels en kan wanneer overbodig beter worden weggelaten. Kolom B in de tabel toont de resultaten wanneer een CCA bij de labels achterwege wordt gelaten. De GS bedraagt hier 74.5%, heel wat lager dan de referentie van 92%. Ook de simulator bevestigt het belang van de CCA, de succesrate zonder bedraagt 67%. In de meting met de simulator laat ook de controller de CCAs achterwege, wat het verschil kan verklaren. Dit verlies (of toch een minimumgrens) valt theoretisch te verklaren. De labels kiezen een randomtijdstip in elk UI -interval om hun RFU te versturen. Wanneer er even van uit gegaan wordt dat 39 labels erin slagen

Figuur 5.9: Mogelijk verloop van de mediumbezetting bij 40 RFU/U per seconde en UI = 1 s. De combinatie van RFU en U wordt ter vereenvoudiging als een enkele puls van 5 ms voorgesteld.


63

hun RFU te versturen en een U kunnen ontvangen, dan bedraagt de mediumbezetting: 39 ·

(120 + 20) · 8 bits = 0.175 s 250 kbps

Met een UI van één seconde wil dit dus zeggen dat het 40ste label 17.5% kans heeft dat het medium bezet is, wat zonder CCA tot verlies van de RFU leidt. De succesrate zonder CCA is dan 82.5%. De veronderstelling dat de andere 39 labels er in slagen botsingen te vermijden is echter niet correct, zodat dit percentage slechts een maximum is (voor een enkele node onder de gemaakte veronderstellingen). Het is bovendien zo dat aangezien per RFU/U-cyclus twee pakketten worden verstuurd, de snelheid zal nooit effectief 250 kbps halen wat de werkelijke mediumbezetting nog wat hoger maakt. Gebruik van Acknowledgements Een ACK is een klein datapakket dat bij het correct ontvangen van een pakket ter bevestiging naar de zender ervan wordt teruggestuurd. De CC2420-radio op de Tmote Sky ondersteunt naast software-ACKs eveneens hardware-ACKs. Software-ACKs vermijden zogenaamde false-ACKs waar de radio een pakket ontvangt en een ACK verstuurt, maar de MCU zelf het pakket nooit ontvangt. Wel is het zo dat meer software-ACKs verloren gaan, maar dit is meestal meer wenselijk dan false-ACKs. Tot nu toe werden in de experimenten geen ACKs gebruikt. ACKs zijn van belang wanneer label of controller met zekerheid willen weten of een RFU of U correct werden ontvangen. Aan deze informatie kan dan een gepaste actie worden gekoppeld. Kolom C uit de tabel toont aan dat het gebruik van ACKs een lichte daling van GS tot 91% als gevolg heeft. De mediumbezetting is door de extra pakketten lichtjes gestegen, wat hiervan de oorzaak kan zijn. Aantal retries De informatie bekomen bij het gebruik van ACKs kan worden gebruikt om berichten die verloren gegaan zijn (geen ACK ontvangen) opnieuw te versturen. De TinyOS MAC laat toe het aantal retries op te geven, alsook de tijd in ms tussen de verschillende pogingen. Dit kan gebeuren bij zowel de controller als de labels. In het huidige scenario zijn de labels always-on. Daarom doet het er in principe niet toe wanneer de controller de U terugstuurt, de labels luisteren altijd. In een EH-scenario kan daar echter niet van uit gegaan worden. Daarom is het beter om voor de controller geen retries toe te laten aangezien hiervoor extra ontvangpogingen bij de labels vereist zijn.


64

Kolommen D, E, F en G tonen de resultaten bij respectievelijk één retry (10 ms), één retry (50 ms), twee retries (10 ms) en drie retries (10 ms). De gemiddelde succesrates zijn 90.5%, 91%, 91.5% en 90%. De verschillen in succesrate zijn niet voldoende om van een significante invloed te kunnen spreken. Op Figuur B.1 uit de theoretische studie van GreenPeak is te zien dat voor arrival rates onder de 50 het verschil tussen de curves vrij marginaal is. Uit de figuur valt ook af te leiden dat door het invoeren van retries nooit een invloed van meer dan 5% op de succesrate wordt verwacht (van 50 naar 55 bij een arrival rate van 100/s). Een aanneembare verklaring voor deze vrij zwakke invloed is dat door retries in te voeren niet enkel de kans verhoogt dat een bericht uiteindelijk zijn bestemming bereikt. Zoals in subsectie eerder is aangetoond, schaalt GS mee met het aantal RFU/U-cycli per seconde en dus met de mediumbezetting. Door retries in te voeren worden per label gemiddeld meer RFUs verstuurd en stijgt de bezetting van het medium. Hierdoor daalt GS dan weer, wat de eerdere stijging geheel of gedeeltelijk teniet doet. In de MAC-implementatie van de simulator worden geen ACKs gebruikt, wat het gebruik van retries daar niet toelaat. Wel is het mogelijk vast te leggen hoeveel keer elk pakket wordt verstuurd. Deze primitieve manier van werken lijkt hier niet geschikt en wordt daarom ook niet gebruikt. De resultaten uit Tabel C.15 illustreren de tijdsafhankelijkheid van de succesrate op bepaalde nodes nog eens. De metingen werden relatief snel na elkaar uitgevoerd. Aan de waarden bij 3A-7 en 3A-16 valt het tijdelijk onbereikbaar zijn van een node mooi te zien. Workload van de controller Het kan voorvallen dat de controller twee RFUs van twee verschillende labels vlak na elkaar ontvangt. Aangezien elke RFU na 200 ms wordt beantwoord met een U, kan het dus gebeuren dat wanneer de controller de tweede update wil sturen, nog bezig is met het versturen van de eerste. De radio is op dat moment bezet. Kolom H van Tabel C.15 toont aan dat deze situatie zich vrij vaak stelt en dat het droppen van de tweede U geen optie is. De GS daalt immers van 92% naar 76%. Daarom wordt een extra buffer voor deze Us voorzien en wordt na 200 ms een nieuwe poging ondernomen. In kolom I stijgt GS tot 83%, wat aantoont dat zelfs een tweede poging vaak niet voldoende is. In het always-on


65

scenario is het moment waarop de U wordt ontvangen voor de labels niet van belang, in het EHESL-scenario zal dat wel zo zijn en wordt hier nog in meer detail op ingegaan.

5.3.5

Nagaan van de correctheid van de emulatie m.b.v. de simulator

Het aantal nodes beschikbaar in het testbed is vrij beperkt. Tot nu toe werden 40 motes gebruikt in plaats van de enkele duizenden labels aanwezig in een realistisch ESL-netwerk. Dit gebeurde door UI te schalen zodat het aantal RFU/U-cycli per seconde in beide netwerken ongeveer gelijk is. Elke testbednode stelt meerdere ESL-labels voor zoals reeds in subsectie 5.3.3 is vermeld. In deze subsectie wordt onderzocht of deze werkwijze correct is, m.a.w. of een netwerk met n1 knopen en een RFU/U-periode UI zich hetzelfde gedraagt als een netwerk met n2 knopen en een RFU/U-periode

UI n1 n2

.

In subsectie 5.3.4 werd bij het onderdeel Mediumbezetting de invloed van het aantal RFU/U-cycli per seconde op GS onderzocht. Dit gebeurde op twee manieren: Een toename van het aantal labelnodes van 1 tot 40 bij een vaste UI van 1 s. 40 labelnodes met een variabele UI tussen 1 en 16 s.

Het verloop van GS was in beide experimenten gelijkaardig (mits het in acht nemen van de daar gemaakte opmerkingen). Dit is een eerste aanwijzing dat de in deze subsectie onderzochte stelling inderdaad correct is. Om dit verder te onderzoeken wordt de simulator gebruikt aangezien die een veel minder drastische beperking op het aantal nodes heeft. In praktijk lukt het om (met deze applicatie en de gebruikte PC) een netwerk tot 900 nodes te simuleren. Simulaties met volgende kenmerken worden uitgevoerd: Het aantal labelnodes is achtereenvolgens 36, 100, 225, 400 en 900. De labels worden in een uniform grid opgesteld binnen een ruimte van 30 op 30 meter.

De controller bevindt zich steeds in het centrum van deze ruimte. Castalia laat niet toe om de positie van één node vast te leggen (de controller) en de andere uniform te kiezen (de labels). Daarom worden alle posities via een algoritme bepaald en via node locations.ini aan de simulator meegegeven. Dit algoritme is opgenomen in het excelbestand nodepositions, terug te vinden op de cd-rom. Het bestand laat toe een

5.4 Energy Harvesting ESL

66

aantal (een kwadraat) labels in te geven en de grid-posities van de verschillende nodes te bepalen en weer te geven in de vorm vereist voor het Castalia-configuratiebestand. De gemiddelde arrivalrate bij de controller bedraagt steeds 36 per seconde. Dit komt

neer op een UI van respectievelijk 1, 2.78, 6.25, 11.11 en 25 seconden. Het padverlies bedraagt 50 dBm (1 m) en er worden verder geen PRR- of RSSI-

waarden ingegeven. Tabel 5.2 vat deze gegevens samen en geeft de gevonden succesrates weer. De waarden liggen voldoende dicht bij elkaar om te concluderen dat de netwerken zich inderdaad op dezelfde manier gedragen. Aangezien er geen trend zit in deze cijfers wordt verwacht dat dit ook zo zal zijn bij een nog groter aantal nodes (met uiteraard een herschaalde UI ). De resultaten, analyse en conclusies bij 40 nodes uit vorige secties en subsecties kunnen dus worden gebruikt bij de modellering van een realistisch ESL-netwerk.

5.4

Energy Harvesting ESL

De vorige secties richtten zich vooral op de werking en mogelijkheden van een ESL-systeem op zich. Met de energiebeperkingen eigen aan een EH-systeem zelf werd niet specifiek rekening gehouden. Dit is dan ook het onderwerp van deze sectie waar de mogelijkheden en beperkingen van EHESL in meer detail worden behandeld. # labels

UI (s)

GS (%)

36

1

97.7

100

2.78

97.4

225

6.25

97.6

400

11.11

97.5

900

25

97.7

Tabel 5.2: Gemiddelde succesrates i.f.v. het aantal labelnodes wanneer de gemiddelde arrivalrate bij de controller constant gehouden wordt door UI te variëren.


5.4.1

67

Aanpassingen ESL-applicatie tot EHESL-applicatie

Tot nu toe werd er in deze case van uitgegaan dat zowel de controller als de labels over een permanente energiebron kunnen beschikken. De nodes zijn dan always-on, wat wil zeggen dat de radio zich altijd in Listen-toestand bevindt en niet wordt uitgeschakeld. Wanneer iets verstuurd of ontvangen moet worden, maakt de radio een transitie naar respectievelijk een TX- of RX-toestand. Wegens het grote aantal aanvragen per seconde is een always-on scenario vereist voor de controller. Aangezien er slechts één controller is per netwerk (of toch een klein aantal), is dit haalbaar. Voor de labels is een always-on scenario echter niet erg realistisch. Batterijen hebben een te beperkte levensduur en energy harvesters kunnen niet voldoende energie opwekken om dit toe te laten. Door de applicatie permanent in Listen-toestand te laten terwijl dit niet nodig is, gaat heel wat energie verloren. Toestandstransities van de radio Daarom moet de applicatie worden aangepast om ook met deze energiebronnen te kunnen functioneren. Dit kan door de radio op de gepaste ogenblikken aan- en uit te schakelen. Een overzicht van de radiotransities in de vernieuwde applicatie is te zien op Figuur 5.10. De radio start in de uit-toestand (S IDLE ), om even aan te gaan op het moment dat een RFU verstuurd moet worden (S TX RFU ). Na het versturen van de RFU gaat de radio opnieuw uit (S RFU SENT ). Na 200 ms stuurt de controller een U terug en daarom moet de radio van het label op dat moment ook aanstaan. Drie pogingen worden ondernomen om de update te ontvangen (S ATTEMPT i waarbij i varieert van 1 tot 3). Deze pogingen zijn zoals eerder vermeld vereist wanneer de controller bij een poging tot zenden van een U merkt dat de radio nog bezet wordt door een eerdere U. De U van de controller kan natuurlijk verloren gaan (of wanneer de RFU verloren gaat zelfs nooit worden gestuurd), waardoor het label tevergeefs op een update wacht. Daarom wordt bij het inschakelen van de radio telkens een timeout-timer (duur TO) geactiveerd die de radio na enige tijd terug uitschakelt. Eenmaal een U is ontvangen of na drie tevergeefse ontvangpogingen, wordt de radio opnieuw uitgeschakeld (S IDLE ).

5.4.2

Resultaten met de EHESL-applicatie

Aangezien de klemtoon van deze sectie eerder op de energieaspecten dan op de ESL-werking ligt, wordt niet gezocht naar de meest optimale parameterkeuzes van de applicatie. Wel


68

Figuur 5.10: Opeenvolgende toestanden en toestandstransities van de radio in de EHESLapplicatie. Na het zenden van de RFU worden drie ontvangpogingen ondernomen (eens per 200 ms). Dit telkens gedurende een bepaalde timeout-tijd.

kan worden opgemerkt dat de succesrate vrij sterk afhankelijk is van zowel de gekozen timeout als van de timing van de verschillende ontvangpogingen. Door deze ontvangpogingen verstandig te timen (eventueel met empirisch bekomen data) kan een zo kort mogelijke time-out worden gekozen die resulteert in een zo goede mogelijke succesrate. Een keuze van de optimale waarden kan een aanzet tot verder onderzoek zijn. GS met enkele goedgekozen parameters Een time-out van 20 ms wordt in deze masterproef gekozen en blijkt zowel op het testbed als in de simulator goed te werken. Verder is het zo dat vooral bij de simulator deze zaken erg kritisch zijn. Dit komt omdat de simulator niet met events werkt zoals TinyOS. De functionaliteit in de verschillende lagen (applicatie, MAC, radio) van de simulator zijn sterk van elkaar afgeschermd en het is bijvoorbeeld moeilijk om het precieze tijdstip waarop een RFU wordt verstuurd te achterhalen. Met de geselecteerde parameters bedraagt de gemiddelde succesrate op het testbed 87% en in de simulator 85%, maar het moet mogelijk zijn om wanneer de parameters worden bijgetuned ongeveer dezelfe succesrates te halen als in het ESL-geval (iets lager aangezien het aantal ontvangpogingen tot drie wordt beperkt). Invloed van de verschillende ontvangpogingen Om de invloed van de verschillende ontvangpogingen in meer detail te kunnen onderzoeken wordt een nieuw experiment opgezet met 40 nodes waarbij de labels 200 RFUs versturen en


69

registreren bij welke ontvangpoging ze de corresponderende U ontvangen. Tabel C.17 toont de gedetailleerde resultaten. Het totaal aantal ontvangen updates T wordt onderverdeeld in drie categorieën: P1 (U ontvangen bij eerste poging), P2 (U ontvangen bij tweede poging) en P3 (U ontvangen bij derde poging). Deze waarden worden ook procentueel t.o.v. het totaal aantal aantal ontvangen updates weergegeven. Gemiddeld gezien worden 70.6% van de updates ontvangen tijdens de eerste poging, 13.3% tijdens de tweede en 3.3% tijdens de derde. Vooral tijdens de derde poging worden in verhouding vrij weinig updates ontvangen. Een afweging kan worden gemaakt tussen de energie nodig voor deze extra poging en de stijging in succesrate die er het gevolg van is. In de simulator wordt dit experiment niet in evenveel detail behandeld, maar daar is de invloed van het wegblijven van de herhaalde ontvangpogingen veel geringer. Het is effectief zo dat tijdens de derde poging zo goed als geen updates meer worden ontvangen aangezien in de simulator de radiomodule minder lang bezet blijft tijdens het versturen van een update. Twee pogingen zijn daar dus voldoende. Opnieuw is de snelheid waarmee TinyOS/Tmote berichten verzendt de beperkende factor aangezien de radio langer bezet gehouden wordt. Met andere hardware/software wordt verwacht dat de derde ontvangpoging zonder veel gevolgen achterwege kan gelaten worden, wat het energieverbruik reduceert.

5.4.3

Keuze energy harvester voor ESL

De ESL-applicatie biedt niet erg veel mogelijkheden wat de keuze van energy harvester betreft. Het ligt voor de hand een zonnecel te gebruiken die aan één of beide kanten van het display wordt bevestigd. Eventueel kan onder het display zelf een zonnecel worden geplaatst indien het voldoende licht doorlaat. In een worst-case scenario moet ervan uit gegaan worden dat geen dag- of zonnelicht op de ESL-labels invalt, wat betekent dat enkel indoor-zonneceltechnologie (en de lagere beschikbare energie die daarbij hoort) mogelijk is. Over een eventueel aanwezige resonante trilling op de winkelrekken zijn geen gegevens beschikbaar. Bovendien lijkt het dat de resonantiefrequentie sterk afhankelijk zal zijn van de hoeveelheid en soort producten aanwezig in de rekken, wat een erg breedbandige harvester vereist.


5.4.4

70

Energieverbruik van de testbed-implementatie

Om de EH-functionaliteit op het testbed optimaal te kunnen gebruiken is het nodig om eerst een goed beeld van het energieverbruik van de applicatie te krijgen. Aan de hand van deze gegevens kan dan een geschikte harvester-waarde worden gekozen. Stroommetingen met de EE Op Figuur 5.11 is een EE-stroommeting te zien van een enkele RFU/U-cyclus zoals die van op Figuur 5.10. De gebruikte samplefrequentie is op deze figuur 4 kHz (250 µs per sample). Er is geen controller actief en het label onderneemt na het zenden van de RFU dus tevergeefs drie ontvangpogingen. Het stroomverbruik in TX/RX/Listen-toestand schommelt rond de 20 mA, wat in overeenstemming is met de in de datasheet van de Tmote vermelde waarden [13]. Minstens even belangrijk is het stroomverbruik van de applicatie wanneer de radio is uitgeschakeld, bij een UI van 300 s bevindt de mote zich immers 99.99% van de tijd in deze toestand. Om een idee te krijgen van dit stroomverbruik wordt op Figuur 5.12 ingezoomd op een zone waar de radio is uitgeschakeld. De schaal op de y-as is niet langer mA, maar een rechtstreekse aflezing van de 12-bit ADC. Deze schaal kent 4096 waarden (212 ), van 0 tot 4095. Hierbij mapt 4095 op ongeveer 70 mA, waardoor een eenheid in deze schaal overeenkomt met 70 mA = 17 µA. 4095 Deze 17 µA bepaalt dan tevens de maximale resolutie die bij de stroommetingen op het

Figuur 5.11: Stroommeting met de EE van een enkele RFU/U-cyclus.


71

Figuur 5.12: Detailbeeld van het stroomverbruik van de EHESL-applicatie wanneer de radio is uitgeschakeld.

Figuur 5.13: Dezelfde meting als bij Figuur 5.12, maar dan op mote 3A-23.

Figuur 5.14: Stroomverbruik van een dummy-applicatie.


72

testbed mogelijk is. Op de figuur valt af te lezen dat het stroomverbruik gemiddeld zo’n 170 µA bedraagt en niet zo vlak is als verwacht. Verschillende pieken tot zo’n 1.2 mA verstoren het vlakke verloop, hierover later meer. Het verloop van dit stroomverbruik blijkt bovendien afhankelijk te zijn van de mote waarop de meting wordt uitgevoerd. Op Figuur 5.13 wordt de meting van op Figuur 5.12 herhaald, maar dan op mote 3A-23 (de beste metingen werden op deze mote bekomen). De stroompieken blijven aanwezig, maar verder is het verloop hier heel wat vlakker. Niet enkel het niet vlakke verloop, maar ook het stroomverbruik van de applicatie is vreemd, 170 µA ligt immers aan de hoge kant. Wanneer de radio is uitgeschakeld doet de applicatie niks, op één of twee timers na. In [38] wordt vermeld dat TinyOS continu de laagst mogelijke energietoestand voor de microcontroller (MCU) bepaalt. In de datasheet van de MSP430 [39] worden de energietoestanden LPM0 (actief) tot LPM4 (alles uitgeschakeld) vermeld. Wanneer geen taken dienen uitgevoerd te worden schakelt TinyOS de MCU in LPM3 (32 kHz klok blijft actief), dit is echter enkel mogelijk wanneer geen timers actief zijn. In het andere geval is de energietoestand LPM1, die volgens [40] tot 50 µA verbruikt. Om hier over een vorm van referentie te beschikken, wordt het stroomverbruik van een dummy-applicatie gemeten. De applicatie doet naast opstarten helemaal niks. Een stroommeting (op mote 3A-23) is te zien op Figuur 5.14. Deze meting bevestigt het hoge stroomverbruik en de pieken, al zijn deze laatste wel minder frequent. Stroommetingen met de scope Om een sluitend beeld van het stroomverbruik van de applicaties en de Tmote te kennen, worden enkele metingen met een scope en multimeter uitgevoerd. Figuur 5.15 toont een schema van de hiervoor gebruikte meetopstelling. Een weerstand R wordt in serie met het device under test (DUT) (de Tmote) en de spanningsbron B geschakeld. De stroom I die door R loopt is dan de (te meten) stroom die door het DUT wordt verbruikt. Door met de scope S de spanning V over R te meten volgt I uit de wet van Ohm I=

V . R

Een multimeter M in serie meet eveneens de stroom. Op deze manier wordt voor de


73

Figuur 5.15: Opstelling voor stroommeting met de scope en multimeter

EHESL-applicatie (met de radio uitgeschakeld) 160 µA gemeten. Het stroomverbruik van de dummy-applicatie bedraagt echter slechts 25 µA. Verder zijn de stroompieken niet aanwezig op de scope, ondanks de hogere samplefrequentie dan op het testbed. Beide vaststellingen doen vermoeden dat er iets foutloopt op de EE met de gemeten stroomwaarden. Dit vermoeden wordt bevestigd wanneer blijkt dat ook de EHESL-applicatie slechts 25 µA verbruikt. De eerder gemeten 160 µA is te wijten aan een ontvanger voor seriële berichten in de applicatie die gebruikt werd voor het dynamisch aanpassen van parameters. Hierbij wordt nog even opgemerkt dat wanneer het seriële circuit op de Tmote actief is en effectief berichten verstuurt (zoals printf-statements) het verbruik zelfs oploopt tot 2 mA. Wanneer het gebruik van de seriële interface wordt vermeden, blijven de stroommetingen op het testbed gelijk (zo’n 170 µA i.p.v. 25 µA met de EHESL- en dummy-applicatie), wat op een aanwezige lekstroom wijst. Ook de stroompieken lijken eerder EE-gerelateerd te zijn (aangezien ze niet op de scope te zien zijn), alhoewel niet kan worden verklaard waarom ze hoogfrequenter zijn bij de EHESL-applicatie dan bij de dummy-applicatie. Pogingen tot het verklaren van de lek- en piekstroom op de EE Om na te gaan of de lekstroom te wijten is aan de gekozen LDO-chip op de EE, wordt de stroommeting (dummy-applicatie) op een met een andere LDO-chip uitgeruste EE her-


74

haald. De resultaten blijven echter volkomen analoog, zowel qua stroomverbruik als qua stroompieken. Verder worden nog enkele metingen uitgevoerd om de stabiliteit van de door de EE aan de Tmote aangelegde voedingsspanning na te gaan. Een instabiele voedingsspanning zou immers voor de pieken kunnen zorgen. Bij een in de streamer ingestelde waarde van 3200 (2.719V), wordt de aan de Tmote aangelegde spanning gedurende 100000 samples gesampled aan 100 Hz. De spanning varieert tussen 2.7415 V en 2.7598 V. Het exacte spanningsverloop is niet gekend, maar een ripple van zo’n 0.02 V wordt ook vastgesteld wanneer de mote via USB wordt gevoed. Op het eerste zicht is dit dus ook niet de oorzaak. Verder onderzoek zal dit moeten uitwijzen.

5.4.5

EHESL op het testbed

De stroommetingen uit subsectie 5.4.4 tonen aan dat de lekstroom op het testbed zo’n 130 − 150 µA bedraagt. Wanneer de pieken in rekening worden gebracht wordt daardoor gemiddeld 170 µA gemeten wanneer het label niks zendt of ontvangt. Dit is een relatief hoge waarde die moeilijk te halen is met indoor zonneceltechnologie. Een meer realistische waarde is 20 µA, terwijl GreenPeak uitgaat van slechts 10 µA. Het is niet zo dat de lekstroom L lineair optelt bij de door de applicatie verbruikte stroom. Het is eerder zo dat de EE een stroom L meet voor applicaties met een stroomverbruik kleiner dan L (en niet L + het werkelijke stroomverbruik). Wanneer het stroomverbruik groter is dan L wordt de stroom wel correct gemeten door de EE. Deze vaststellingen willen echter niet zeggen dat het EH-systeem van het testbed niet bruikbaar is. Volgend onderdeel bespreekt een op het testbed uitgevoerde meting. Spanningsverloop over de virtuele condensator Zoals in sectie 4.2 reeds werd uiteengezet dienen voor de harvestwerking op het testbed drie parameters te worden bepaald: Er wordt uitgegaan van een condensator die initieel volledig leeg is, dus value 0 =0. Als harvester -waarde wordt 11 gekozen, wat overeenkomt met 187 µA. Dit is de

kleinst mogelijke waarde aangezien de gemiddelde gemeten waarde 10 (170 µA) bedraagt.


75

Een harvestMultiplier van 200 wordt gekozen, wat correspondeert met een conden-

sator van 1 mF. Bovenop het gemeten verbruik wordt 17 µA geharvest. Deze waarde is vrij hoog (als de harvester bijvoorbeeld slechts 20 µA haalt, mag de mote maar 3 µA verbruiken), maar beter kan wegens de DAC-resolutie van de EE niet. Figuur 5.16 toont het verloop van de spanning over de virtuele condensator (of dus de spanning die de EE aanlegt aan de mote) tijdens de werking van de EHESL-applicatie. Een updateperiode UI van 60 s (i.p.v. 300 s) is gebruikt om een mooiere figuur te bekomen. Er vallen duidelijk drie fasen te onderscheiden: Fase I: Initieel is de spanning onvoldoende om de mote te voeden. De minimale voe-

dingsspanning van de Tmote bedraagt immers 2.1 V. De spanning op de condensator bouwt zich nagenoeg lineair op in deze fase. Fase II: Op een gegeven moment bereikt de spanning 2.1 V waardoor de mote in

werking treedt. De condensator is echter nog niet volledig opgeladen. Wanneer de eerste RFU wordt verstuurd is de spanning 3 V waarna ze terugvalt tot 2 V. Fase III: De spanning stijgt weer lineair tot de maximale spanning wordt bereikt.

Vanaf nu bevindt het systeem zich in een regimetoestand. Bij het zenden van een RFU en de ontvangpogingen valt de spanning terug, maar niet onder de 2.1 V drempel zodat de mote aangeschakeld blijft. Fase I vindt plaats telkens wanneer de mote een voldoende lange tijd geen energie krijgt toegevoerd (bijvoorbeeld na een nacht). Fase II is ongewenst: het label doorloopt een RFU/U-cyclus terwijl daar nog niet voldoende energie voor is. Aangezien UI hier slechts 60 seconden is, wordt de kans dat dit gebeurt groter dan wanneer UI 300 seconden is. Het is echter niet uit te sluiten dat een label reeds helemaal in het begin van het UI -interval een RFU probeert te versturen. Wat dan kan gebeuren is dat de spanning 2.1 V bereikt, de mote wordt ingeschakeld en meteen de radio aanzet. Bij het aanschakelen van de radio daalt de spanning opnieuw tot een te lage waarde en functioneert de mote niet meer. Na een tijd wordt de spanning weer 2.1 V en herhaalt de cyclus zich. Op deze manier komt de mote in een situatie terecht waar nooit een regimetoestand wordt bereikt en geen updates worden ontvangen. Dit moet worden vermeden.


76

Figuur 5.16: Verloop van de spanning over de virtuele condensator. Drie fases zijn duidelijk te onderscheiden: opbouw van de spanning, terugval en regime.

Een mogelijke oplossing is te verhinderen dat de mote de radio inschakelt wanneer de voedingsspanning een bepaalde treshholdwaarde nog niet heeft bereikt. De MSP430 beschikt over een interne spanningsmeter. Deze kan in TinyOS worden gebruikt door de VoltageC component (Msp430InternalVoltageC voltage sensor) mee te compileren en het commando error t read() via de Read interface op te roepen. De spanning wordt dan via een readDone(error t result, val t val) event aan de gebruiker meegegeven. Eenmaal in Fase III gedraagt de mote zich vrij stabiel. De spanning is maximaal (Vmax ) tot een RFU/U-cyclus plaatsvindt, waarop de spanning daalt tot Vlow = Vmax − ∆V . Het kan gebeuren dat een mote in Fase III terugvalt tot Fase II. Dit wanneer de energy harvester tijdelijk geen of weinig energie levert, waardoor de opgebouwde spanning afneemt. Ook kan het gebeuren dat een RFU te snel na een andere wordt verstuurd, waardoor de spanning nog niet voldoende terug is opgebouwd. Aan de eerste situatie valt vrij weinig te doen, maar de tweede kan worden opgelost door opnieuw een spanningscheck te doen alvorens een RFU te versturen.


77

De spanningsval ∆V is afhankelijk van verschillende factoren. De belangrijkste zijn: Hoe meer energie de harvester levert, hoe meer dit het verbruik compenseert. De capaciteit van de gebruikte condensator bepaalt hoe gevoelig de spanning is voor

variaties. Hoe hoger de capaciteit hoe minder variatiegevoelig. Na het versturen van elke RFU wordt drie keer (worst case) 20 ms gewacht op een

RFU. Hoe minder lang wordt geluisterd, hoe minder lang de radio veel stroom verbruikt. Aan de harvester kan meestal niet veel worden gewijzigd aangezien het de gebruikte technologie is die de beperking vormt. De andere twee factoren kunnen echter wel worden be¨ınvloed. Hoe hoger de capaciteit van de gebruikte condensator hoe trager de spanning erover wijzigt (overeenkomstig met Q = C · V = I · t). Hogere capaciteiten (en zeker superof ultracondensatoren) zijn duurder, maar de spanning erover is meer constant. Natuurlijk neemt de tijd nodig om een bepaalde spanning op te bouwen lineair toe met de capaciteit, zodat condensatoren met een lage capaciteit meer geschikt zijn om heel snel een spanning op te bouwen. De capaciteit van de gebruikte condensator moet in staat zijn de pieken van het energieverbruik op te vangen. M.a.w. de spanning moet wanneer plots veel energie wordt verbruikt (de radio die wordt aangezet voor de RFU/U) voldoende hoog blijven om de mote te kunnen voeden. Het is echter geen must dat de spanning boven 2.1 V moet blijven. Een EH-applicatie kan ook louter een maximale spanning over een condensator opbouwen en eenmaal die bereikt is een bepaalde activiteit uitvoeren tot de node uitvalt. Op deze manier manier wordt enkel energie verbruikt in de actieve periodes en niet in een standby periode. In een realistisch EHESL-netwerk zou deze manier van werken echter resulteren in een moeilijker te controleren UI periode. GreenPeak gebruikt voor de ESL-applicatie een condensator van 600 µF, iets meer dan de helft van de waarde de 1 mF die hier wordt gebruikt. Zoals op Figuur 5.16 te zien is zou een dergelijke capaciteit hier resulteren in een spanningsval tot onder de drempelspanning van 2.1 V. Om toch een lagere capaciteit te kunnen gebruiken is het dus nodig het energieverbruik van een RFU/U-cyclus verder te beperken. Uit eerdere opmerkingen bleek dat dit mogelijk is door bijvoorbeeld een ontvangpoging achterwege te laten of de time-out tijd

5.5 Conclusie

78

ervan te beperken (mits een betere timing). Opnieuw dient dus een afweging te worden gemaakt.

5.5

Conclusie

De EHESL case is een boeiende case study zowel op vlak van schaalbaarheid (duizenden nodes) als op vlak van EH-energierestricties. Zowel in de simulator als op het testbed wordt een experimentele gemiddelde succesrate tot 92% (individuele afwijkingen tot 10 %) gehaald bij een workload van 40 RFU/U per seconde voor de controller. Dit bevestigt de theoretische studie van GreenPeak die stelde dat een eenvoudig CSMA-CA mechanisme kan gebruikt worden om voldoende botsingen in het netwerk te vermijden. Het maximaal aantal nodes mogelijk in een EHESL-netwerk blijkt eerder platformafhankelijk te zijn en te worden gelimiteerd door de verwerkingssnelheid van de controller. Alhoewel de gemiddelde succesrate vrij stabiel is, geldt dit niet voor de individuele succesrates. Temporele (bijv. interferentie) en spatiale (bijv. controllerpositie) fluctuaties hebben een grote impact en sluiten bepaalde nodes tijdelijk of permanent uit van het netwerk. Aangezien de kans op botsingen vrij hoog is, zorgt het weglaten van CCAs in het CSMA-CA schema voor een sterke daling van de succesrate van zo’n 20%. De impact van andere CSMA-CA parameters is echter klein. De grootte van de backoffwindows heeft bijvoorbeeld weinig invloed. Ondanks de hoge kans op botsingen is de kans dat pakketten van meer dan twee nodes tegelijk met elkaar botsen vrij klein. Het gebruik van ACKs is mogelijk, maar eventuele retries (bij het wegblijven van een ACK) hebben weinig effect door de verhoogde mediumbezetting (en het hogere aantal botsingen). Het zijn vooral de totale mediumbezetting en de onderlinge positionering van de verschillende nodes die een effect hebben op de gemiddelde succesrate. Aan de hand van het generieke EH-energieprofiel wordt het energieverbruik van de EHESLapplicatie geëvalueerd. Elke RFU/U-cyclus zorgt voor een spanningsdaling over de virtuele condensator. Door de gebruikte energy harvester en condensator goed te dimensioneren kan een systeem in regime worden bekomen. Verder is het maximaliseren van de tijd waarin een sensornode zich in slaaptoestand bevindt van cruciaal belang. Een afweging dient te worden gemaakt tussen dit energieverbruik en timingaspecten belangrijk bij het ontvangen van een update.

CASE STUDY: EH DRAADLOZE SCHAKELAAR TER BEDIENING VAN EEN ACTUATOR 79

Hoofdstuk 6 Case study: EH draadloze schakelaar ter bediening van een actuator De tweede case study in deze masterproef onderzoekt de mogelijkheden van een energy harvesting WSN-systeem bestaande uit een controller en verschillende draadloze schakelaars. De controller is voor de eenvoud verbonden met een lamp die door de schakelaars kan worden bediend. Uiteraard is een dergelijke opstelling niet de enige mogelijkheid, ook andere actuatoren zoals de motor van een automatisch rolluik kunnen op deze manier worden aangestuurd. De mate waarin de controller erin slaagt aan de Quality of Service (QoS) vereisten van de schakelaar-lamp combinatie te voldoen en toch nog voor andere WSN-toepassingen (bijv. een building-automation netwerk) kan worden ingeschakeld, wordt onderzocht. Deze case study werd naar het einde van de masterproef toe behandeld en is wegens tijdsgebrek niet in evenveel detail uitgewerkt als de ESL case study.

6.1

Situering

Traditionele systemen voor het bedienen van de verlichting gebeuren volledig bedraad. Tussen de lamp en elke schakelaar dient een elektrische verbinding te worden gelegd. Het trekken van de benodigde bedrading is onpraktisch en relatief duur. Bovendien vormt deze manier van werken een vrij grote beperking op de mogelijke posities van de schakelaars.

6.2 Eigenschappen en randvoorwaarden

80

Niet alle plaatsen zijn even eenvoudig te bereiken (bijvoorbeeld de omkadering van een raam) en daarom is de uiteindelijke positie van de schakelaars niet steeds de meest optimale.

6.1.1

Draadloze RF-schakelaar

Een draadloze RF-module is hiervoor een ideale oplossing. Wanneer een schakelaar wordt ingedrukt stuurt deze één of meerdere pakketten naar een aan de lamp verbonden controller die de toestand van de lamp wijzigt. Op deze manier is geen enkele vorm van bedrading meer nodig (voor de lamp zelf uiteraard wel) en valt de beperking op de positionering van de schakelaars weg. Ook kunnen schakelaars eenvoudig worden verplaatst of aan het systeem worden toegevoegd.

6.1.2

Keuze van een geschikte energy harvester

Wanneer een dergelijke RF-module met behulp van een batterij wordt gevoed vormt dit een kritisch onderdeel van het systeem. Naast de lampen zelf dient dan ook de batterij van de schakelaar af en toe te worden vervangen, wat vervelend is. Dit systeem leent zich goed voor energy harvesting. De meest aangewezen harvesters zijn: Bij het bedienen van een schakelaar oefent de de gebruiker er een kracht op uit.

Dit kan zowel het indrukken van een knop of schakelaar zijn als het draaien aan een draaiknop. Deze energie kan worden gebruikt om pakketten te versturen en een condensator op te laden. De schakelaar kan ook bestaan uit een lichtsensor ge¨ıntegreerd met een zonnecel.

Het probleem hierbij is dat de lamp wordt gebruikt net wanneer het donker is en de harvester weinig energie levert. Om de lange donkere tijdszones te kunnen opvangen is een condensator met voldoende hoge capaciteit nodig of zelfs een supercapaciteit nodig. De hiermee verbonden kosten zijn relatief hoog.

6.2

Eigenschappen en randvoorwaarden

Net zoals in de vorige case wordt het netwerk van schakelaars en controller beperkt tot een single-hop stertopologie. Opnieuw is de controller always-on en verbonden met het vaste stroomnet. Volgende verschillen zijn cruciaal:

6.2 Eigenschappen en randvoorwaarden

81

De vereisten op vlak van de succesrate zijn veel strenger. Het indrukken van de

schakelaar zonder dat de toestand van de lamp wijzigt is onaanvaardbaar. Daarom moeten de schakelaars erin slagen in 99.99% van de gevallen hun instructie tot bij de controller zien te krijgen. Ook mag er geen te grote vertraging zitten tussen het drukken op de schakelaar en het reageren van de lamp. De instuctie dient binnen een bepaalde tijd, bijvoorbeeld 100 ms te worden uitgevoerd. Het dataverkeer (naast het achtergrondverkeer) in deze case beperkt zich tot com-

municatie van schakelaar naar controller en dit aan een erg lage frequentie.

6.2.1

Achtergrondverkeer

De frequentie waaraan de schakelaars instructies naar de controller sturen is erg laag. Indien de controller enkel wordt gebruikt voor de lamp-schakelaar combinatie resulteert dit tot een vrij onefficiënt gebruik van resources. Een idee is om de controller ook te gebruiken voor het routeren van andere pakketten. Het hier gebruikte systeem maakt dan deel uit van een groter WSN-netwerk. Dit is niet onrealistisch aangezien domotica en smart-building systemen steeds meer hun ingang vinden. Een voorbeeld van een mogelijke situatie wordt afgebeeld op Figuur 6.1.

6.2.2

Energiebeperking

De hoeveelheid energie en de tijdsperiode waarin die energie beschikbaar is, is erg beperkt. De beschikbare informatie hierover is wegens het erg applicatiespecifieke karakter ervan vrij beperkt. In deze case worden gegevens van twee bedrijven met een dergelijke technologie gebruikt: De EnOcean [41] ECO 100 energy module [42] laat toe bij elke druk op de schakelaar

drie pakketten te versturen met hun PTM 230 radio module. De uitgeoefende kracht bedraagt 2.1 ± 0.4 N bij een verplaatsing van 2 mm. Figuur 6.3 (boven) toont het verloop van de spanningspuls gemeten met het circuit onderaan de figuur. Hierbij bedraagt T typisch 1.4 ms en Uend 5 V ± 25%. GreenPeak gebruikt in een demo een draaischakelaar om een 10 µF condensator op

te laden. Deze capaciteit is in principe niet voldoende om alle energie op te slaan,


82

Figuur 6.1: Mogelijke opstelling waarin EH-schakelaars (draaiknop of gewoon) communiceren met een centrale controller die een actuator aanstuurt. De controller fungeert ook als router voor achtergronds informatie.

maar laat toe zeer snel de nodige spanning op te bouwen. Bovendien wordt de condensator tijdens het ontladen opgeladen, aangezien het versturen van pakketten sneller gaat dan het draaien aan de knop. Met de beschikbare energie is het volgens hun gegevens (en de door hen gebruikte hardware) mogelijk om 1 pakket te versturen met CCA/CSMA-CA/ACK en 3 zonder.

6.3

Beschrijving en implementatie van de applicatie

Om de kans dat de controller een instructie van een schakelaar ontvangt te maximaliseren, kunnen volgende twee methodes worden gebruikt: De schakelaar stuurt een burst van opéénvolgende pakketten naar de controller. Als

de controller minstens één van deze berichten ontvangt, dan kan de instructie worden uitgevoerd. De kans dat alle pakketten verloren gaan of botsen is veel kleiner dan wanneer slechts een enkel pakket wordt verstuurd. De controller houdt periodisch een tijdslot vrij (minstens éénmaal gedurende de maxi-


83

Figuur 6.2: Opbouw van de spanning over een condensator tijdens het drukken op een schakelaar met piëzoelektrische energy harvester.

male reactietijd van 100 ms) waarin geen achtergronds-gegevens worden gerouteerd. In dit tijdslot kunnen enkel de schakelaars van de controller gebruik maken. De controller maakt dit tijdslot kenbaar aan de schakelaars door hen een bericht te sturen. Eventueel kan in dit tijdslot op een ander kanaal (frequentie) met de schakelaars worden gecommuniceerd, wat de kans op interferentie door het achtergrondsverkeer minimaliseert. Het probleem bij deze tweede werkwijze is dat wanneer de controller slechts één dergelijk tijdslot per 100 ms voorziet, de schakelaar in het slechtste geval 100 ms moet wachten. Een aanperiode van zo lang is niet haalbaar met de geharveste energie die voorhanden is. Oplossingen hiervoor zijn een hogere frequentie aan vrije tijdsloten of LPL bij de schakelaars, maar in beide gevallen wordt de controller dan sterk belast, wat een vrij drastische beperking vormt voor het mogelijke achtergrondsverkeer. Deze methode leent zich bijgevolg meer tot toepassingen waar een zonnecel als energy harvester beschikbaar is. De burstmethode lijkt hier dus aangewezen.

6.3.1

Implementatie

Uit de gegevens in subsectie 6.2.2 volgt dat de maximale pakketburst slechts 3 berichten lang (zonder CCA) kan zijn. Een enkel bericht met CCA/CSMA-CA is mogelijk, maar


84

aangezien de controller op een enkele frequentie werkt en er geen info is over de positie van de achtergrondsnodes, is het systeem blootgesteld aan het hidden-node probleem. Een foutieve CCA-beslissing op het enige bericht impliceert dan meteen het falen van de instructie. Om deze reden wordt gekozen om drie berichten zonder CCA te versturen. Achtergrondsverkeer Het achtergrondsverkeer wordt voorgesteld door twee motes die de RadioPerf-toepassing draaien. Mote 1 stuurt periodiek (configureerbare periode ∆T ) een pakket van 120 bytes naar mote 2 met de controller als router. Beperkingen op de EH-werking van het testbed De meest realistische manier om een schakelcyclus te implementeren op het testbed zou zijn om opnieuw de EH-functionaliteit ervan te gebruiken. M.a.w. door gebruik te maken van de sampler- en streamer-events zoals in de ESL-case. Een streamer-event op het testbed laat toe de voedingsspanning dynamisch aan te passen met een periode van 12.5 ms. Wanneer pakketten erg snel na elkaar worden verstuurd is deze resolutie aan de lage kant en daarom niet echt bruikbaar voor de sampler-streamer werking. Deze aanpak zou in de simulator wel haalbaar zijn door de harvest-werking correct te configureren. Het grootste gebrek aan het huidige EH-framework is het feit dat slechts één intervaltijd kan worden ingesteld. Hier is een korte energiepiek en dus een korte intervaltijd nodig. De andere niveaus zullen dan echter ook van korte duur zijn en aangezien het geheel periodiek is volgen de pieken elkaar te snel op. Door elk interval ook individueel als parameter op te geven kan dit worden opgelost. Wegens tijdsgebrek is een implementatie in de simulator echter niet haalbaar. Een tweede implementatiemogelijkheid zou zijn om periodiek een streamer te activeren die de mote gedurende een korte tijd aanschakelt. Eenmaal de mote is opgestart stuurt hij pakketten in een burst tot de mote weer wordt uitgeschakeld door een streamer-event. Deze methode benadert ook in voldoende mate het werkelijke gedrag van de schakelaar. Zoals eerder werd opgemerkt wordt de condensator tijdens het ontladen immers ook opgeladen door de schakelbeweging die langer duurt dan het versturen van een pakket. Elke druk op de schakelaar en bijhorende pakketburst correspondeert dan met twee streamer-events. Twee problemen stellen zich hier. Eerst en vooral wordt als resolutie voor opeenvolgende streamer-events 100 ms vooropgesteld, wat te hoog is voor


85

het doel voor ogen. Ten tweede is het instellen van twee events per pakketburst niet echt schaalbaar met de vele schakelpogingen die nodig zijn voor de statistieken (succesrate) die gezocht worden. Om deze redenen wordt de schakelwerking beperkt tot het periodiek zenden van telkens drie pakketten. Om de kans te maximaliseren dat minstens één van de drie berichten de controller bereikt moeten ze over een voldoende lang tijdsinterval worden gespreid. Op deze manier wordt vermeden dat ze allen botsen met hetzelfde achtergrondspakket. De maximale lengte van dit tijdsinterval wordt uiteraard beperkt door de tijdsperiode waarin er een voldoende hoge spanning over de condensator staat (de duur van de schakelbeweging en het afbouwen van de spanning). De TinyOS stack op de Tmote slaagt er echter niet in om sneller dan eens per ±10 ms een pakket te versturen, zodat aan de timingvoorwaarde wordt voldaan. Eventueel kan het interessant zijn de invloed van de tijdspanne tussen de verschillende pakketten verder te onderzoeken. Dit zowel op vlak van succesrate als op vlak van energie.

6.4 6.4.1

Experimenten, resultaten en analyse Opstelling met 1 schakelaar

In het eenvoudigste scenario is er slechts een enkele schakelaar in het systeem aanwezig. Wegens de lage schakelfrequentie is dit echter ook de situatie wanneer meerdere schakelaars aanwezig zijn. De kans is immers zeer klein (maar toch niet onbestaande) dat meerdere schakelaars tegelijkertijd worden ingedrukt. Daarom kan een systeem met meerdere schakelaars wanneer er maar één zender actief is worden herleid tot een systeem met een enkele schakelaar. Invloed van de interarrivaltijd van het achtergrondverkeer op de succesrate Een eerste experiment onderzoekt de invloed op de succesrate van de tijd ∆T tussen opeenvolgende pakketten van het achtergrondverkeer. De switch maakt vijf transities per seconde (wat dus neerkomt op 15 pakketten per seconde) en een totaal van 1000 transities wordt geëvalueerd. Figuur 6.3 toont het procentuele verloop van zowel het aantal succesvol ontvangen pakketten als het aantal succesvol ontvangen instructies (minstens één van de drie pakketten succesvol ontvangen) wanneer ∆T varieert tussen 20 ms en 100 ms. Terwijl


86

het percentage succesvol ontvangen pakketten afneemt van 96.0% tot 85.9%, slaagt het systeem er toch in tot ∆T = 30 ms alle transities te registreren. Bij ∆T = 25 ms en ∆T = 20 ms zijn de succesrates respectievelijk 99.9% en 99.8%. Hier dient te worden opgemerkt dat voor ∆T = 40 ms en lager de controller er niet meer in slaagt alles achtergrondpakketten door te routeren. De workload van de controller wordt te hoog en alhoewel de pakketten wel nog worden ontvangen, kan de TX-buffer niet volgen. Het heeft dus weinig nut om een ∆T kleiner dan 40 te gebruiken. Wanneer de controller i.p.v. als router te fungeren enkel achtergrondpakketten broadcast is opnieuw de workload van de controller de meest beperkende factor. Tot een ∆T = 25 ms slaagt de controller erin alle transities (10 per seconde, 2000 in totaal) te registreren en de geconfigureerde zendrate te halen. Vanaf ∆T = 20 ms lukt het de controller niet meer de vooropgestelde zendrate (50 per seconde) te halen. Dit is conform met de in de ESL-case gevonden limiet op de workload van de controller. Randommechanisme voor de periodieke schakeltransities Aangezien het achtergrondverkeer in deze case periodiek verondersteld wordt, is het niet volledig te verantwoorden dat de transities van de schakelaar ook periodiek gebeuren. In principe moet de transitie op een willekeurig ogenblik binnen elk ∆T -interval gebeuren. De applicatie wordt daarom aangepast. Elke schakelaar maakt slechts één transitie per twee seconden meer, en dit op een random tijdstip binnen elke periode. Uit metingen blijkt dat dit randommechanisme (het werkelijke gedrag) weldegelijk een negatief effect heeft op de toelaatbare ∆T . Tot ∆T = 40 ms registreert de controller alle transities, vanaf ∆T = 35 ms is dit niet meer zo (99.9%), al blijft het percentage van totaal aantal ontvangen pakketten nog steeds ongeveer 89%. Periodieke transities geven bijgevolg een overschatting van de werkelijke succesrate.

6.4.2

Opstelling met meerdere schakelaars

Een systeem met meerdere schakelaars valt wegens de erg lage schakelfrequentie vaak te herleiden tot een systeem met een enkele schakelaar. Toch is het interessant om te onderzoeken hoe een systeem met meerdere schakelaars zich gedraagt.


87

Figuur 6.3: Percentage succesvol ontvangen pakketten/instructies i.f.v. de tijdsduur ∆T tussen opeenvolgende achtergrondpakketten.

Periodieke schakeltransities Wanneer de schakeltransities periodiek zijn (zonder het randommechanisme) en de controller enkel achtergronds-pakketten broadcast dan lukt het met twee schakelaars (die elk 5 keer per seconde schakelen) eveneens om een succesrate van 100% te behouden tot een ∆T van 25 ms. In Tabel 6.1 wordt het percentage succesvol ontvangen pakketten (in totaal worden 6000 pakketten verstuurd, corresponderend met 2000 transities) weergegeven i.f.v. de interarrivaltijd ∆T van de achtergronds-pakketten. Dit eens voor een opstelling met één schakelaar (10 transities per seconde) en een opstelling met twee schakelaars (5 transities per seconde per schakelaar). In alle gevallen worden alle transities door de controller geregistreerd. Randomperiodieke schakeltransities De invloed van meerdere schakelaars wordt duidelijker wanneer het randommechanisme weer wordt ingeschakeld en er slechts één transitie per twee seconden plaatsvindt. Waar het met een enkele schakelaar mogelijk was alle transities te registreren tot ∆T = 40 ms (controller als router) is dit met twee schakelaars nog maar zo tot ∆T = 48 ms. Bij drie schakelaars lukt het zelfs bij ∆T = 150 ms niet om een succesrate hoger dan 99.9% te

6.4 Experimenten, resultaten en analyse ∆T (ms) 1 schakelaar (@10/s)

88 2 schakelaars (@5/s)

50

100

96.28

40

99.98

95.28

35

93.87

94.40

30

93.38

93.13

25

94.78

92.78

Tabel 6.1: Percentage door de controller ontvangen pakketten i.f.v. de interarrivaltijd ∆T van de achtergronds-pakketten. Dit eens voor een opstelling met één schakelaar (10 keer per seconde) en eens voor een opstelling met twee schakelaars (elk 5 keer per seconde).

bekomen. Uit deze vaststelling blijken twee zaken: Meerdere schakelaars maken het halen van de 99.99% succesrate heel wat moeilij-

ker. Botsingen tussen de pakketten van de schakelaars onderling liggen hier aan de oorzaak. De gegevens bevestigen nogmaals de overschatting van de succesrate bij periodieke

schakeltransities zonder het randommechanisme. Botsingen tussen de pakketten van de verschillende schakelaars treden dan minder vaak op aangezien de schakelaars met dezelfde frequentie schakelen en een quasi-constante offset t.o.v. elkaar hebben. Botsingen tussen verschillende schakelaars minimaliseren De prestatiedaling bij meerdere schakelaars is vooral te wijten aan botsingen tussen de pakketten van de schakelaars onderling. Om een betere succesrate te bekomen moet de kans dat deze pakketten botsen worden geminimaliseerd. In deze masterproef wordt een eerste poging hiertoe ondernomen. Figuur 6.4 (boven) toont een mogelijke situatie waar de drie pakketten horende bij een bepaalde schakeltransitie botsen met de drie pakketten van een andere schakelaar. Uiteraard is dit een worst-case scenario aangezien alle pakketten op deze manier verloren gaan. Wanneer elke schakelaar nu random één van de drie pakketten achterwege laat, dan toont Figuur 6.4 (onder) één van de mogelijke resulterende situaties. Waar eerst geen van de schakelaars erin slaagde een pakket zonder botsing te versturen, is dit nu wel zo. Wanneer


89

we elke zendpoging als een mini-tijdslot beschouwen, dan kan de eerste schakelaar in het derde minislot een pakket versturen en de tweede schakelaar in het tweede minislot. Dit mechanisme werd eveneens ge¨ımplementeerd, maar slaagt er niet in om de succesrate in voldoende mate omhoog te krijgen. Met drie schakelaars en ∆T = 100 ms blijft de succesrate 99.9%. Het is zelfs zo dat bij twee schakelaars de succesrate lichtjes daalt. Een nadeel van het hier gebruikte minislotmechanisme is dat telkens slechts twee pakketten per transitie worden verstuurd, terwijl er eigenlijk energie is voor drie. Minder pakketten versturen verlaagt de kans dat minstens 1 pakket per transitie door de controller wordt ontvangen. Mogelijke wijzigingen aan het minislot-mechanisme Een eerste wijziging aan het mechanisme kan eruit bestaan de drie pakketten op een random manier te verdelen over vier minislots. Op deze manier worden toch drie pakketten per transitie verstuurd. Een vereiste hiervoor is natuurlijk dat de spanning over de condensator gedurende deze vier minislots voldoende hoog blijft om het versturen van de pakketten toe te laten. Het minislot-mechanisme gaat ervan uit dat de drie pogingen per transitie equidistant van elkaar gebeuren (de minislots). Het kan interessant zijn om te onderzoeken in welke mate hier verbeteringen mogelijk zijn. I.p.v. het random weglaten van één van de pakketten zouden de pakketten random binnen de tijdsperiode van drie minislots kunnen worden verschoven. Uiteraard dient dan rekening te worden gehouden met het feit dat wanneer twee pakketten te snel na elkaar worden verstuurd de kans stijgt dat ze botsen met hetzelfde achtergrondpakket. Zoals eerder vermeld licht is de TinyOS en Tmote Sky combinatie vrij traag als het op het snel na elkaar versturen van pakketten aankomt. Een implementatie in de simulator kan voor dit onderzoek meer geschikt zijn. Beide voorstellen werden in het kader van deze masterproef niet verder onderzocht, maar kunnen het onderwerp vormen van verder onderzoek op dit gebied.

6.5 Conclusie

90

Figuur 6.4: Minislot-mechanisme waarbij elke schakelaar random één van de drie pakketten achterwege laat om de kans op botsingen te minimaliseren.

6.5

Conclusie

Het huidige EH framework op het testbed is voorlopig onvoldoende geschikt om de EH werking van een schakelaar (met piëzoelektrische energy harvester) te benaderen. De spanning door de EE aan de Tmote aangelegd wordt elke 12.5 ms geëvalueerd, wat te traag is bij het snel na elkaar versturen van pakketten. In een streamer-event kan bovendien slechts een enkele stroomwaarde worden ingesteld die de harvester voorstelt. Een situatie waar een stuksgewijs constant energieprofiel kan worden opgebouwd (zoals in het EH framework van de simulator) is meer schaalbaar naar statistische metingen toe. In het EH-framework van de simulator is het aangewezen om ook de tijdsintervallen waarmee het energieprofiel kan worden opgebouwd instelbaar te maken. Het halen van de QoS vereisten bij aanwezig achtergrondverkeer is vooral een uitdaging wanneer meerdere schakelaars in het systeem aanwezig zijn en met elkaar in contention treden. Met een enkele schakelaar is de zendfrequentie erg laag, waardoor alle achtergrondverkeer kan worden doorgerouteerd (tot de limiet van de TinyOS/Tmote combinatie). Aangezien pakketten van verschillende schakelaars met elkaar kunnen botsen dient hiervoor een mechanisme te worden voorzien. Een eerste mechanisme met minislots was weinig succesvol, maar enkele wijzigingen worden voorgesteld.

BESLUIT

91

Hoofdstuk 7 Besluit Energy harvesting zorgt voor een brede waaier aan innovatieve applicaties en mogelijkheden. De beschikbare energie is meestal erg schaars wat de implementatie van deze applicaties uitdagender maakt. Een generiek EH-energieprofiel geschikt voor WSN-simulators en een real-life testbed werd in deze masterproef voorgesteld en ge¨ımplementeerd. De bekomen ontwikkelplatformen werden succesvol gebruikt om een EHESL-systeem en in minder detail een EH draadloze schakelaar te onderzoeken en te evalueren. Beide toepassingen zijn single-hop. Multi-hop applicaties blijven een uitdaging en kunnen het onderwerp vormen van verder onderzoek met behulp van de aangeboden tools.

CD-ROM

92

Bijlage A Cd-rom A.1 A.1.1

Broncode Testbed

ESL-label De map /Testbed/ESL/ESL label bevat de applicatiemodule geschikt voor een ESL-label mote. Volgende bestanden zijn van belang: ESLlabelAppC.nc

Bepaalt de componenten waaruit de ESLlabelC -module is opgebouwd. De connecties tussen de deelmodules onderling worden ook hier gemaakt. Commentaar in de code verklaart de gebruikte componenten. ESLlabelC.nc

Bevat de eigenlijke implementatie van de ESL-label functionaliteit. ESL.h

Definieert de structuur van de gebruikte berichttypes. ReportMsg.java

Gebruikt de structuur in ESL.h om rapporteringsberichten te kunnen interpreteren vanuit een Java-applicatie. Deze rapporteringsberichten kunnen bijvoorbeeld het aantal succesvol ontvangen updates bevatten. Het doel van deze .java en de bijhorende .class was louter om de werking van het geheel te kunnen analyseren.

A.2 Digitale vorm

93

ESL-controller Een analoge structuur is te vinden voor de ESL-controller in /Testbed/ESL/ESL controller. EHESL De EHESL-variant van de bovenvermelde code is te vinden in /Testbed/EHESL.

A.1.2

Simulator

Wegens de herbruikbaarheid van het EH-framework is de volledige Castalia installatiemap terug te vinden op de cd-rom onder /Simulator/Castalia. Het bestand /Simulator/ReadMe.txt geeft een overzicht van het geheel.

A.2

Digitale vorm

De digitale vorm van dit werk en de gebruikte Latex-files zijn eveneens op de cd-rom terug te vinden.

FIGUREN

Bijlage B Figuren

94

FIGUREN

95

Figuur B.1: Completionrate i.f.v. het aantal CCAs en retries en de arrivalrate aan RFUs bij de controller. Deze figuur maakt deel uit van de theoretische studie van GreenPeak.

FIGUREN

96

Figuur B.2: (x,y)-posities van de motes in het testbed op de 3de verdieping. Deze coördinaten worden gebruikt bij de mapping tussen testbed en simulator.

GEDETAILLEERDE MEETRESULTATEN

Bijlage C Gedetailleerde meetresultaten

97


98

NodeID

RSSI (dBm)

PRR

3A-27

0

n.v.t.

n.v.t.

3A-1

1

-76

0.96

3A-2

2

-74

0.96

3A-3

3

-81

0.96

3A-4

4

-72

0.97

3A-6

5

-80

0.95

3A-7

6

-69

0.96

3A-8

7

-71

0.98

3A-9

8

-80

0.99

3A-10

9

-82

0.94

3A-11

10

-62

0.97

3A-14

11

-74

0.98

3A-15

12

-63

0.98

3A-16

13

-88

0.97

3A-18

14

-64

0.98

3A-19

15

-57

0.98

3A-20

16

-67

0.96

3A-21

17

-57

0.99

3A-22

18

-60

0.98

3A-23

19

-47

1.00

3A-26

20

-50

1.00

Tabel C.1: Mapping van het testbed op de simulator aan de hand van RSSI-waarden op de links van controller naar labels en PRR-waarden op de links van labels naar controller.


99

NodeID

RSSI (dBm)

PRR

3A-28

21

-58

0.99

3A-31

22

-53

1.00

3B-2

23

-76

0.99

3B-3

24

-76

0.98

3B-4

25

-73

0.96

3B-5

26

-82

0.98

3B-6

27

-75

0.98

3B-9

28

-56

0.97

3B-11

29

-80

0.97

3B-13

30

-64

0.98

3B-14

31

-61

0.98

3B-15

32

-76

0.99

3B-16

33

-64

0.98

3B-17

34

-52

0.99

3B-18

35

-72

0.96

3B-20

36

-64

0.98

3B-21

37

-62

0.98

3B-22

38

-57

0.99

3B-23

39

-68

0.96

3B-24

40

-84

0.95

Tabel C.2: Mapping van het testbed op de simulator aan de hand van RSSI-waarden op de links van controller naar labels en PRR-waarden op de links van labels naar controller (vervolg).


100

Simulator

Testbed

3A-1

175

176

3A-2

174

183

3A-3

173

178

3A-4

177

180

3A-6

173

177

3A-7

177

184

3A-8

182

188

3A-9

190

177

3A-10

159

184

3A-11

178

178

3A-14

183

181

3A-15

187

182

3A-16

180

159

3A-18

184

179

3A-19

190

184

3A-20

174

187

3A-21

188

191

3A-22

187

183

3A-23

198

186

3A-26

199

194

Tabel C.3: Aantal RFUs (op een totaal van 200) die correct met een U worden beantwoord. De opstelling in zowel simulator en testbed (mapping) bevat 40 labelnodes.


101

Simulator

Testbed

3A-28

190

198

3A-31

199

184

3B-2

190

172

3B-3

185

184

3B-4

178

176

3B-5

180

174

3B-6

187

174

3B-9

184

191

3B-11

168

177

3B-13

191

185

3B-14

188

185

3B-15

189

179

3B-16

183

183

3B-17

194

194

3B-18

180

184

3B-20

191

180

3B-21

187

184

3B-22

188

189

3B-23

174

186

3B-24

173

169

Tabel C.4: Aantal RFUs (op een totaal van 200) die correct met een U worden beantwoord. De opstelling in zowel simulator en testbed (mapping) bevat 40 labelnodes (vervolg).


50 dBm

102

55 dBm 50 dBm

55 dBm

Ideaal

1

177

0

197

195

199

2

179

0

195

193

198

3

193

0

193

190

196

4

191

177

193

190

198

5

194

180

192

198

199

6

193

28

195

186

200

7

195

194

193

197

199

8

3

0

191

123

199

9

196

179

191

197

198

10

196

171

196

196

199

11

194

185

197

194

200

12

193

77

194

194

197

13

193

193

198

188

198

14

193

187

194

192

197

15

194

189

197

196

198

16

192

120

192

199

195

17

194

195

196

193

197

18

196

194

198

197

199

19

196

197

192

194

198

20

198

199

194

193

198

Tabel C.5: Invloed van het padverlies op het aantal ontvangen Us in de simulator. Bij de eerste twee kolommen is de geometrie van het netwerk die van het testbed, bij de laatste drie een vierkant van 30 m op 30 m.


50 dBm

103

55 dBm 50 dBm

55 dBm

Ideaal

21

197

196

196

199

197

22

196

196

196

190

199

23

185

0

196

197

197

24

185

0

200

199

196

25

192

180

199

198

198

26

195

185

196

196

200

27

193

186

197

194

200

28

197

190

191

195

198

29

190

74

197

197

199

30

193

191

195

198

198

31

195

189

195

198

196

32

192

195

197

197

197

33

194

182

194

195

198

34

194

185

191

193

200

35

193

195

194

197

200

36

194

193

194

198

197

37

197

194

189

193

199

38

198

192

196

195

199

39

191

197

195

195

199

40

192

190

192

193

197

Tabel C.6: Invloed van het padverlies op het aantal ontvangen Us in de simulator. Bij de eerste twee kolommen is de geometrie van het netwerk die van het testbed, bij de laatste drie een vierkant van 30 m op 30 m (vervolg).


104

3A-15

3A-21

3A-27

3A-29

3A-31

1

185

189

189

184

184

2

194

184

182

186

185

3

186

189

181

187

179

4

180

182

183

184

180

5

188

191

182

181

181

6

188

187

182

168

64

7

181

0

183

177

182

8

188

194

183

182

185

9

186

171

148

0

178

10

186

176

175

184

158

11

183

181

189

172

178

12

193

197

192

188

189

13

196

193

181

184

184

14

183

180

191

188

187

15

193

191

190

186

180

16

191

184

182

184

178

17

180

190

185

190

185

18

77

181

185

192

191

19

191

182

190

189

182

20

194

198

182

185

195

Tabel C.7: Invloed van de controllerkeuze op het aantal succesvol ontvangen Us.


105

3A-15

3A-21

3A-27

3A-29

3A-31

21

186

192

193

186

187

22

185

187

185

190

181

23

187

189

193

195

196

24

188

192

193

192

194

25

184

185

191

196

195

26

175

187

194

192

180

27

179

179

190

189

195

28

180

186

188

194

193

29

143

156

145

153

162

30

142

158

152

149

147

31

3

150

154

185

188

32

152

150

153

150

153

33

144

147

151

141

154

34

149

147

147

152

149

35

176

186

192

186

187

36

111

110

156

189

181

37

183

184

195

193

193

38

190

166

183

191

156

39

100

119

179

142

189

40

159

158

190

193

189

Tabel C.8: Invloed van de controllerkeuze op het aantal succesvol ontvangen Us (vervolg).


106

t1

t2

t3

t3

t3

1

176

185

172

178

179

2

183

185

184

181

180

3

178

181

184

180

188

4

180

183

174

175

180

5

177

185

177

176

175

6

184

182

172

164

170

7

188

181

187

194

193

8

177

172

180

167

175

9

184

168

188

182

181

10 178

190

192

187

187

11 181

192

193

190

189

12 182

179

181

182

186

13 159

186

178

184

176

14 179

181

191

194

191

15 184

189

191

190

187

16 187

184

183

184

179

17 191

191

184

197

195

18 183

183

179

182

180

19 186

193

193

190

193

20 194

197

178

177

182

Tabel C.9: Invloed van de tijd op het aantal succesvol ontvangen Us. De tabel toont de resultaten van hetzelfde experiment, gemeten op drie verschillende tijdstippen: t1 , t2 = t1 + 1 maand, t3 = t2 + 2 dagen. Op t3 worden drie metingen vlak na elkaar uitgevoerd.


t1

107

t2

t3

t3

t3

21 198

197

188

194

192

22 184

195

176

178

177

23 172

186

179

175

169

24 184

65

186

184

173

25 176

158

171

161

163

26 174

181

177

179

185

27 174

1

186

183

174

28 191

178

181

178

171

29 177

175

176

178

183

30 185

180

176

178

184

31 185

173

198

183

188

32 179

178

186

180

183

33 183

192

173

172

179

34 194

190

193

197

192

35 184

179

170

187

178

36 180

174

185

184

185

37 184

177

188

195

187

38 189

189

191

195

186

39 186

184

180

183

180

40 169

178

168

159

156

Tabel C.10: Invloed van de tijd op het aantal succesvol ontvangen Us. De tabel toont de resultaten van hetzelfde experiment, gemeten op drie verschillende tijdstippen: t1 , t2 = t1 + 1 maand, t3 = t2 + 2 dagen. Op t3 worden drie metingen vlak na elkaar uitgevoerd (vervolg).


108

3A-27

3A-25 & 3A-29

1

178

137

2

181

188

3

180

187

4

175

170

5

176

180

6

164

113

7

194

177

8

167

78

9

182

187

10

187

187

11

190

183

12

182

182

13

184

189

14

194

182

15

190

180

16

184

190

17

197

188

18

182

184

19

190

190

20

177

196

Tabel C.11: Vergelijking tussen het aantal succesvol ontvangen Us bij een experiment met één centrale controller (3A-27) en een experiment met twee iets minder centrale controllers (3A-25 en 3A-29).


109

3A-27

3A-25 & 3A-29

21

194

178

22

178

199

23

175

184

24

184

142

25

161

172

26

179

186

27

183

179

28

178

190

29

178

173

30

178

184

31

183

190

32

180

94

33

172

176

34

197

192

35

187

181

36

184

193

37

195

193

38

195

191

39

183

182

40

159

178

Tabel C.12: Vergelijking tussen het aantal succesvol ontvangen Us bij een experiment met één centrale controller (3A-27) en een experiment met twee iets minder centrale controllers (3A-25 en 3A-29) (vervolg).


110

300

300

300

200

200

200

100

100

100

50

50

50

5

5

5

3A-1

190

184

184

174

186

181

186

187

184

179

181

174

181

182

178

3A-2

182

187

187

187

185

190

185

189

191

184

193

186

185

188

181

3A-3

182

182

182

175

174

184

179

184

177

181

177

183

181

177

178

3A-4

183

180

180

175

180

180

178

177

182

182

175

181

178

184

184

3A-5

188

185

185

182

192

186

189

189

179

186

194

181

181

182

178

3A-6

175

176

176

172

172

176

180

175

171

174

174

171

174

182

177

3A-7

180

185

185

183

179

178

192

178

178

177

179

176

181

176

182

3A-8

181

186

186

178

187

186

181

185

185

186

188

188

174

189

180

3A-9

176

167

167

169

170

179

176

181

186

177

178

180

171

165

168

3A-10 145

146

146

130

145

148

155

145

141

138

136

144

140

145

142

3A-11 191

183

183

173

188

193

186

181

180

185

192

183

186

181

188

3A-12 188

192

192

185

191

194

189

189

190

192

183

193

183

185

188

3A-13 183

179

179

175

185

188

182

177

180

185

173

186

175

176

182

3A-14 195

189

189

177

191

188

193

187

187

192

188

192

187

196

185

3A-15 194

192

192

184

196

185

193

192

185

192

195

194

184

193

193

3A-16 189

181

181

181

190

182

182

180

186

184

182

182

183

176

184

3A-17 189

192

192

187

191

191

190

189

184

188

194

187

186

186

188

3A-18 170

176

176

173

173

179

173

173

164

166

176

173

171

176

174

3A-19 166

175

175

169

172

181

169

174

168

170

175

167

175

174

165

3A-20 179

187

187

183

181

186

182

187

175

182

186

184

184

188

181

Tabel C.13: Invloed CBW


111

300

300

300

200

200

200

100

100

100

50

50

50

5

5

5

3A-21 192

188

188

191

194

191

196

192

192

188

192

189

191

192

193

3A-22 170

173

173

170

179

171

179

176

180

169

167

174

174

167

172

3A-23 184

183

183

176

184

185

187

189

183

182

191

176

186

179

188

3A-26 192

192

192

188

195

185

193

186

193

187

196

192

190

193

193

3A-28 194

193

193

189

194

192

196

193

195

192

194

191

195

193

192

3A-29 192

190

190

190

193

193

190

192

190

195

194

191

191

195

195

3A-30 190

179

179

187

187

187

192

191

185

186

196

184

194

189

186

3A-31 185

187

187

187

186

190

190

188

182

193

191

190

193

194

185

3B-2

142

142

142

146

143

143

150

149

147

142

150

141

134

155

150

3B-3

153

158

158

151

147

155

154

154

154

154

162

161

156

155

148

3B-4

149

161

161

155

159

148

146

156

154

149

155

147

151

154

150

3B-5

152

154

154

156

152

151

146

160

149

164

156

153

153

150

154

3B-6

152

151

151

157

162

150

158

153

160

149

162

152

158

155

158

3B-7

155

160

160

151

157

143

147

147

142

141

157

156

149

146

141

3B-9

189

188

188

185

185

188

193

191

196

189

193

187

191

191

192

3B-11

152

159

159

152

154

149

148

163

153

157

156

153

161

152

156

3B-13

191

193

193

184

193

193

191

189

193

188

192

188

189

191

187

3B-14

186

181

181

179

176

182

189

182

185

186

185

189

179

181

177

3B-15

154

159

159

156

158

171

162

168

164

170

170

166

171

171

160

3B-16

188

193

193

183

188

189

188

184

192

186

185

186

193

190

185

Tabel C.14: Invloed CBW


A

B

C

112

D

E

F

G

H

I

3A-1

171 141 162

176

177

167

133 143

168

3A-2

189 130 184

182

178

185

186 152

168

3A-3

168 133 162

146

156

156

162 161

138

3A-4

181 147 181

175

173

185

181 145

155

3A-5

188 148 188

177

186

185

185 148

174

3A-6

181 138 171

171

171

176

177 145

157

173

171

180

179

171 140

163

3A-10 181 152 177

173

183

186

175 146

163

3A-12 175 139 192

181

183

180

189 154

168

3A-13 180 149 176

181

183

180

181 157

161

3A-14 179 157 185

181

185

191

186 156

173

3A-15 188 157 188

185

186

190

185 163

164

0

0

2

3A-17 186 156 186

190

187

186

183 143

166

3A-18 183 153 181

186

182

190

182 152

173

3A-19 190 159 188

179

177

184

186 152

158

3A-21 190 162 190

189

191

189

185 156

172

3A-22 183 140 184

189

181

187

189 154

167

3A-23 191 160 191

185

191

192

197 168

176

3A-24 191 139 186

197

187

187

195 148

174

3A-7

6

6

3A-16 185 135

77

0

0

10

Tabel C.15: Experiment met 40 labels waarin: (B) geen CCA wordt gebruikt, (C) 1 retry (10 ms), (D) 1 retry (50 ms), (E) 2 retries (10 ms), (F) 3 retries (10 ms), (G) de controller geen nieuwe pogingen onderneemt bij een bezette radio, (H) de controller één poging onderneemt.


A

B

C

113

D

E

F

G

H

I

3A-25 193 166 189

191

189

197

196 146

178

3A-26 190 170 198

190

193

189

190 160

177

3A-28 193 164 191

191

195

192

191 155

176

3A-29 193 163 196

193

190

197

197 164

181

3A-30 185 148 176

169

165

172

148 137

113

3A-31 183 152 183

169

169

135

152 159

146

3B-2

180 144 169

174

173

173

183 138

165

3B-3

175 144 174

186

181

184

167 160

161

3B-5

182 153 174

178

182

184

175 159

169

3B-6

176 137 180

174

178

180

177 152

157

3B-7

182 149 171

179

178

180

175 160

164

3B-8

185 150 186

185

187

189

174 147

172

3B-9

184 156 186

185

188

191

185 150

169

3B-10

188 150 184

185

185

189

184 156

176

3B-11

180 138 170

179

184

175

184 136

160

3B-12

185 154 184

183

181

181

179 157

172

3B-13

185 141 184

185

189

190

190 156

169

3B-15

177 136 178

180

178

167

183 146

175

3B-16

187 148 184

182

188

186

187 156

175

3B-17

192 171 190

189

191

191

191 163

177

Tabel C.16: Experiment met 40 labels waarin: (B) geen CCA wordt gebruikt, (C) 1 retry (10 ms), (D) 1 retry (50 ms), (E) 2 retries (10 ms), (F) 3 retries (10 ms), (G) de controller geen nieuwe pogingen onderneemt bij een bezette radio, (H) de controller één poging onderneemt. (vervolg)


114

T

P1

P2

P3

P1 (%) P2 (%) P3 (%)

166

122

34

10

61

17

5

171

143

22

6

71.5

11

3

164

131

23

10

65.5

11.5

5

172

134

29

9

67

14.5

4.5

168

132

29

7

66

14.5

3.5

155

125

29

1

62.5

14.5

0.5

168

131

32

5

65.5

16

2.5

166

135

26

5

67.5

13

2.5

170

136

29

5

68

14.5

2.5

176

148

25

3

74

12.5

1.5

184

156

23

5

78

11.5

2.5

165

130

26

9

65

13

4.5

173

148

18

7

74

9

3.5

175

154

15

6

77

7.5

3

174

136

26

12

68

13

6

186

147

31

8

73.5

15.5

4

179

151

21

7

75.5

10.5

3.5

182

144

30

8

72

15

4

182

150

29

3

75

14.5

1.5

182

149

25

8

74.5

12.5

4

Tabel C.17: Verdeling van het totaal aantal ontvangen Us (T ) over de verschillende ontvangpogingen (P1 , P2 en P3 ). Dit ook procentueel.


115

T

P1

P2

P3

P1 (%) P2 (%) P3 (%)

184

152

29

3

76

14.5

1.5

188

141

40

7

70.5

20

3.5

194

160

26

8

80

13

4

176

144

24

8

72

12

4

169

136

28

5

68

14

2.5

166

128

31

7

64

15.5

3.5

176

148

19

9

74

9.5

4.5

164

135

24

5

67.5

12

2.5

175

142

26

7

71

13

3.5

167

140

19

8

70

9.5

4

178

141

30

7

70.5

15

3.5

186

146

33

7

73

16.5

3.5

169

133

29

7

66.5

14.5

3.5

165

137

23

5

68.5

11.5

2.5

174

146

27

1

73

13.5

0.5

175

143

24

8

71.5

12

4

166

134

26

6

67

13

3

182

146

32

4

73

16

2

190

157

25

8

78.5

12.5

4

173

140

26

7

70

13

3.5

Tabel C.18: Verdeling van het totaal aantal ontvangen Us (T ) over de verschillende ontvangpogingen (P1 , P2 en P3 ). Dit ook procentueel. (vervolg)

BIBLIOGRAFIE

116

Bibliografie [1] C. Kompis; S. Aliwell. Energy Harvesting Technologies to Enable Remote and Wireless Sensing. 2008. [2] S. Chalasani. A Survey of Energy Harvesting Sources for Embedded Systems. 2008. [3] D. Steingart; J. Polastre. Energy Harvesting White Paper. 2008. [4] S. Roundy; M. Strasser; P. Wright. Powering Ambient Intelligent Networks. 2004. [5] A. Hande; T. Polk; W. Walker; D. Bhatia. Indoor solar energy harvesting for sensor network router nodes. 2007. [6] J. Taneja; J. Jeong; D. Culler. Design, Modeling, and Capacity Planning for MicroSolar Power Sensor Networks. 2008. [7] J. Dave; P. Halpern; H. Myers. Computation of Incident Solar Energy. 1975. [8] J. Randall. Designing Indoor Solar Products. 2005. [9] J. Paradiso; T. Starner. Energy Scavenging for Mobile and Wireless Electronics. 2005. [10] M. Guan; W. Liao. Characteristics of Energy Storage Devices in Piezoelectric Energy Harvesting Systems. 2008. [11] G. Werner-Allen; P. Swieskowski; M. Welsh. MoteLab: A Wireless Sensor Network Testbed. 2005. [12] L. Tytgat; B. Jooris; P. De Mil; B. Latré; I. Moerman; P. Demeester. WiLab, a real-life Wireless Sensor Testbed with Environment Emulation. 2009. [13] Moteiv Corporation (nu Sentilla). Tmote Sky Datasheet. 2006.

BIBLIOGRAFIE [14] Wikipedia, the free encyclopedia:

117 TinyOS.

http://en.wikipedia.org/wiki/

TinyOS. [15] Wikipedia, the free encyclopedia: Wireless Sensor Networks. http://en.wikipedia. org/wiki/Wireless_Sensor_Networks. [16] P. Levis. TinyOS Programming. 2006. [17] TinyOS Alliance. TinyOS Community Forum - An open-source OS for the networked sensor regime. http://www.tinyos.net/. [18] J. Polastre; J. Hill; D. Culler. Versatile Low Power Media Access for Wireless Sensor Networks. 2004. [19] Information Sciences Institute The University of Southern California. The network simulator - ns-2. http://www.isi.edu/nsnam/ns/. [20] OPNET Technologies Inc. Opnet. http://www.opnet.com/. [21] Scalable Network Technologies. Scalable network technologies: Products. http:// www.scalable-networks.com/products/. [22] T. Sriporamanont; G. Liming. Wireless sensor network simulator. 2006. [23] Y. Huang; J. Huang; L. Hester; A. Allen; O. Andric; P. Chen. Opnet simulation of a multi-hop self-organizing wireless sensor network. 2002. [24] G. Chen; J. Branch; M. Pflug; L. Zhu en B. Szymanski. SENSE: A Sensor Network Simulator. 2004. [25] National ICT Australia. National ict australia - castalia [home]. http://castalia. npc.nicta.com.au/. [26] Ohio State University. Home (J-Sim Official). http://sites.google.com/site/ jsimofficial/. [27] UCLA Compilers Group. Avrora - The AVR Simulation and Analysis Framework. http://compilers.cs.ucla.edu/avrora/. [28] P. Levis; N. Lee. TOSSIM: A Simulator for TinyOS Networks. 2003.

BIBLIOGRAFIE

118

[29] Princeton University. EMSIM-2.0: Embedded StrongARM Energy Simulator. http: //www.princeton.edu/~cad/emsim/. [30] University Of Maryland. atemu - Sensor Network Emulator / Simulator / Debugger. http://www.hynet.umd.edu/research/atemu/. [31] Center for Embedded Network Sensing. EmStar: Software for Wireless Sensor Networks. http://cvs.cens.ucla.edu/emstar/. [32] P. Hai; D. Pediaditakis; A. Boulis. From simulation to real deployments in wsn and back. 2007. [33] A. Boulis. Castalia A simulator for Wireless Sensor Networks. 2008. [34] Wikipedia, the free encyclopedia: Electronic Shelf Label. http://en.wikipedia. org/wiki/Electronic_Shelf_Label. [35] GreenPeak Technologies BV. GreenPeak Technologies - Ultra Low Power Wireless Control Networks. http://www.greenpeak.com/. [36] K. Steenbergen; A. Kamerman. Scalable Wireless Sensor Networks Based on Green Energy. 2008. [37] D. Moss; J. Hui; P. Levis; J. Il Choi. TEP126: CC2420 Radio Stack. 2007. [38] R. Szewczyk; P. Levis; M. Turon; L. Nachman; P. Buonadonna; V. Handziski. TEP112: Microcontroller Power Management. 2007. [39] Texas Instruments Inc. MSP430 Mixed Signal Microcontroller. 2000. [40] Texas Instruments Inc. MSP430 Ultra-low-power Microcontrollers. 1999. [41] EnOcean GmbH. EnOcean - Self-powered Wireless Sensors. http://www.enocean. com/. [42] EnOcean GmbH. Energy harvester ECO100 Datasheet. 2007.

Natuurlijke energiebronnen voor draadloze sensornetwerken Ruben Catteeuw

Recommend Documents