• No results found

Distributed netwerk

In document "Smart Building" Sensornetwork (pagina 43-62)

4.2 Opstellingen testen

4.2.3 Distributed netwerk

Om het single point of failure uit het sensornetwerk te verwijderen kan de centrale server worden vervangen door een andere oplossing. Eén van de mogelijke oplossingen is om geen centrale server meer te hebben, maar de taken van de centrale servers te verdelen over de losse sensor nodes. Alle sensor nodes nemen dan een gedeelte van de taken opzich. De sensor nodes moeten er bijvoorbeeld voor zorgen dat alle data wordt opgeslagen. De grootste uitdaging daarmee is om te zorgen dat de data ook nog beschikbaar is als er één of meerdere sensor nodes onbereikbaar zijn.

Deze oplossing is vooral geschikt als de sensor nodes zelf relatief veel rekenkracht hebben. Een voorbeeld daarvan zou een Raspberry Pi kunnen zijn. Die hebben voldoende rekenkracht om kleinere taken uit te kunnen voeren.

Voor de proof-of-concept was het niet mogelijk om dit idee verder uit te werken. Er moet met teveel punten rekening worden gehouden om het goed te laten draaien. Een distributed network is erg ingewikkeld om zelf op te zetten.

4.3

Data opslag

Alle sensordata die worden gemeten worden opgeslagen op de centrale server. Bij de testcase

worden er per minuut al 1920001entries toegevoegd aan de database. Per dag gaat dan om een

ruim 250 miljoen entries.

Deze aantallen kunnen worden verwerkt door een database, echter is het wel van belang om na te denken bij het opzetten van de database. Het is belangrijk om het juiste type database te kiezen en efficiënt om te gaan met de queries.

In de experimenten zal er worden getest met twee verschillende databases om te kijken welke database de beste performance heeft. Hiervoor zal de al eerder genoemde test suite worden gebruikt.

Eerst zal er een test worden gedaan waar de data niet wordt opgeslagen in databases, om te zien wat de effecten zijn van een database. Vervolgens zal er worden getest met InfluxDB en MySQL.

De verwachting is dat zeker bij kleinere hoeveelheden sensor nodes het verschil minimaal zal zijn. Als er meer sensor nodes tegelijkertijd verbinding maken, is de verwachting dat InfluxDB iets sneller zal zijn dan MySQL.

HOOFDSTUK 5

Resultaten

5.0.1

Eerste subvraag

De eerste subvraag is: Wat zijn de verschillen tussen enkele veel gebruikte frameworks en softwa-

relibraries voor sensornetwerken? Voor het beantwoorden van deze vraag kan er gekeken worden

naar de keuzehulp in hoofdstuk 3.1 op pagina 20. Het eerste grote verschil tussen de besproken libraries en frameworks is de aangeboden functionaliteiten. Zoals in afbeelding 2.3 op pagina 14 is weergegeven richten de besproken libraries zich allemaal op andere functionaliteiten. Enkele libraries bieden meerdere functionaliteiten aan om zo een completer pakket aan te bieden. De andere libraries bieden enkel een gedeelte van de functionaliteiten aan. De gebruiker kan ver- volgens zelf de functionaliteiten aanvullen door nog een andere library te gebruiken of zelf de functionaliteiten te ontwikkelen.

Er kunnen verschillende redenen zijn om te kiezen voor een compleet pakket of voor verschil- lende losse onderdelen. Sommige organisaties hebben een voorkeur voor open-source software, bijvoorbeeld omdat ze graag zelf nog wijzigingen kunnen maken aan de software. Ook bij de test- case in het NU-gebouw wordt specifiek gevraagd naar open-source software waar onderzoekers en studenten zelf aanpassingen aan kunnen maken.

Een ander groot verschil zit in de aangeboden service vorm. In tabel 5 op pagina 22 is vergeleken welke service vorm er wordt aangeboden. Een gedeelte van de oplossingen biedt een volledig pakket aan inclusief beheer en hosting van het netwerk. De andere oplossingen leveren alleen de software, de gebruiker kan vervolgens zelf het beheer en de hosting regelen.

Het verschil tussen enkele veel gebruikte frameworks en softwarelibraries voor sensornetwerken zit in de aangeboden functionaliteiten en de aangeboden service vorm.

5.0.2

Tweede subvraag

De tweede deelvraag is gericht op het efficiënt verwerken van alle sensordata. De vraag is: Welke

optimalisaties kunnen er worden doorgevoerd aan het sensornetwerk om van zoveel mogelijk sen- sor nodes de data te kunnen verwerken? Om deze vraag te beantwoorden zijn er enkele moge-

lijkheden bekeken. De optimalisaties waarnaar is gekeken hadden invloed op de communicatie tussen de sensor node en de server en op de opslag in de database.

Om de communicatie te optimaliseren is er in het eerste experiment in hoofdstuk 4.1.1 op pagina 40 gekeken naar spreiding van de binnenkomende data. Door de sensor nodes niet te- gelijkertijd te laten sturen maar evenredig verdeeld over één cycli is de response tijd van de server aanzienlijk afgenomen. In figuur 5.1 zijn de resultaten weergegeven van het experiment. Het gespreid versturen van de sensordata naar de centrale server heeft een duidelijk effect op de

performance. Bij 100 sensor nodes is er een snelheidswinst van ruim 400%1

Het effect is pas zichtbaar als er meerdere sensor nodes verbonden zijn, pas na 12 sensor nodes is het effect zichtbaar. Bij een klein aantal sensor nodes kan de server nog eenvoudig alle

1Zonder spreiding een gemiddelde round trip time van 720 milliseconde. Met spreiding is de round trip time 173 milliseconde.

binnenkomende data tegelijkertijd verwerken. Als het aantal sensor nodes toe neemt komt teveel data tegelijkertijd binnen waardoor de gemiddelde verwerkingstijd, en daarmee de round trip tijd flink toe neemt. Door de data te spreiden is dit effect te voorkomen.

Vanaf 400 sensor nodes die gelijktijdig verbonden zijn neemt de round trip tijd flink toe. De resultaten zijn ook minder betrouwbaar, doordat de sensor nodes virtueel zijn worden teveel sockets vanaf één Raspberry Pi naar de server verstuurd. Op sommige momenten wordt dit wat instabieler waardoor sockets tijdelijk wegvallen.

Opvallend is dat de round trip tijd bij 6 en 12 sensor nodes hoger ligt dan bij 25 sensor nodes. De verklaring hiervoor is niet gevonden, een mogelijke verklaring zou bij socket.io kunnen zitten. Als er minder sockets verbonden zijn zit er wellicht een iets langere vertraging in, doordat socket.io minder vaak controleert op nieuwe berichten.

Figuur 5.1: Grafiek met resultaten experiment 1 - effect van betere spreiding op de round trip time. Volledige testresultaten in appendix A.1 in figuur A.1 en figuur A.2.

Bij het tweede experiment zijn geen betrouwbare resultaten gekomen uit de experimenten. Helaas kunnen die hier nu niet worden behandeld. Wel kan er een conclusie worden getrokken door te kijken naar de andere experimenten. Als de sensor nodes in een tree network worden geplaatst zullen alleen de bovenste sensor nodes direct in verbinding staan met de centrale server. Het aantal sensor nodes wat direct in verbinding staat met de centrale server is afhankelijk van het totaal aantal sensor nodes maar ook van de indeling van het tree network. Uit het derde experiment blijkt dat de server process tijd om alle data te verwerken en op te slaan in de database weinig tijd in neemt. De meeste tijd zit in het transport tussen de sensor node en de server. Als er in één keer meer data binnen komt van meerdere sensoren tegelijkertijd zal de process tijd toe nemen, maar in totaal blijft het maar een klein gedeelte van de round trip tijd. Als de queries op een dusdanige manier worden geschreven dat alle binnen gekomen data gecombineerd wordt in één of enkele queries is de verhoging van de process time te beperken.

Figuur 5.2: Grafiek met resultaten experiment 3 - round trip time centrale server bij gebruik van respectievelijk InfluxDB en MySQL. Volledige testresultaten in appendix A.1 in figuur A.3 en figuur A.4.

Figuur 5.3: Grafiek met resultaten experiment 3 - process time centrale server bij gebruik van respectievelijk InfluxDB en MySQL.. Volledige testresultaten in appendix A.1 in figuur A.3 en figuur A.4.

Voor het derde experiment is gekeken naar het effect van de database op de totale tijd en het verschil tussen InfluxDB en MySQL. De resultaten zijn te vinden in twee grafieken in figuur

A.4 en A.3. De onderlinge verschillen zijn heel erg klein en niet groot genoeg om de snelste of beste database aan te wijzen voor sensornetwerken. Gedeeltelijk komt dit door het kleine aantal sensor nodes waarmee getest kon worden.

Er zijn 3 verschillende optimalisaties getest om het sensornetwerk efficiënter te maken. Bij één experiment is er duidelijk resultaat te zien en wordt de verwerking op de centrale server van het sensornetwerk aanmerkelijk sneller. Het tweede experiment kon niet goed getest worden. Echter, door te kijken naar de twee andere experimenten is te verwachten dat een tree network aanzienlijke verbeteringen in termen van performance kan worden verwacht.

Welke optimalisaties kunnen er worden doorgevoerd aan het sensornetwerk om van zoveel mo- gelijk sensor nodes de data te kunnen verwerken? Het spreiden van de binnenkomende sensordata

op de centrale server levert een direct resultaat op. Een andere optimalisatie die waarschijnlijk een groot effect heeft is om de sensor nodes in een tree network te plaatsen.

HOOFDSTUK 6

Conclusie

Bij het opzetten van een sensornetwerk is het belangrijk om in kaart te brengen wat het doel van het sensornetwerk is en in wat voor omgeving het sensornetwerk geplaatst wordt. Aan de hand van de verzamelde informatie kunnen er voorwaarden worden opgesteld waaraan het sensornetwerk moet voldoen.

Aan de hand van deze gestelde voorwaarden kan met behulp van de in deze thesis opgestelde keuzehulp voor sensornetwerken de juiste libraries worden gevonden. Door de juiste software te gebruiken voor het beoogde doel van het sensornetwerk kan er een efficiënt werkend sensornetwerk worden opgezet.

Uit de resultaten van de experimenten zijn enkele optimalisaties naar voren gekomen waarmee sensornetwerken geoptimaliseerd kunnen worden. Als deze optimalisaties worden verwerkt in de software van het sensornetwerk, ontstaat een sensornetwerk die op een efficiënte manier de data van een groot aantal sensor nodes kan verwerken.

HOOFDSTUK 7

Discussie

Voor dit onderzoek is er een keuzehulp opgezet om te helpen bij het opzetten van een sensornet- werk. Daarvoor is er gekeken naar enkele bestaande sensornetwerken en naar enkele veelgebruikte libraries en frameworks. Door vervolgens aan de hand van een test-case voor het Nieuwe Uni- versiteitsgebouw zelf een proof-of-concept sensornetwerk te bouwen is gekeken of de keuzehulp in de praktijk gebruikt kon worden.

In de experimenten is verder gezocht naar verbeteringen om een efficiënt sensornetwerk op te kunnen zetten. Hierbij moet wel rekening gehouden worden dat de experimenten zich vooral richten op de gekozen test-case.

De experimenten zijn uitgevoerd op een test opstelling bestaande uit 6 raspberry pi’s. Om toch grotere hoeveelheden sensor nodes te kunnen testen is er besloten om die te simuleren. Tijdens de experimenten bleek dat de resultaten steeds meer afweken naarmate er meer sensor nodes op één raspberry pi werden gesimuleerd. Een oorzaak hiervan was het wegvallen van de socket verbindignen tussen de sensornode en de centrale server. Om toch betrouwbare resultaten te krijgen is er voor gekozen om meer experimenten te doen met een kleiner aantal sensornodes. Het advies voor vervolgonderzoek is dan ook om een soortgelijk onderzoek uit te voeren om te achterhalen of de in dit onderzoek besproken optimalisaties ook effect hebben als er meer sensornodes verbonden zijn.

BIJLAGE A

Appendix

A.1

Test resultaten experimenten

Figuur A.1: Resultaten experiment 1 - test round trip time tussen sensor node en server zonder spreiding over de cycli.

Figuur A.2: Resultaten experiment 1 - test round trip time tussen sensor node en server met spreiding over de cycli.

Figuur A.3: Resultaten experiment 3 - test round trip time en process time in combinatie met InfluxDB.

Figuur A.4: Resultaten experiment 3 - test round trip time en process time in combinatie met MySQL.

Woordenlijst

ACK Een ACK of Acknowledgment is een bericht die kan worden gebruikt in een communica- tieprotocol om aan te geven dat een bericht (succesvol) is ontvangen.. 15, 56

API Application Programming Interface. 7, 16, 56

Application Programming Interface Een application programming interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken). Vaak vormen API’s de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma’s. Bron: Wikipedia. 56

BREAAM . 11, 32–34, 56

Eclipse foundation De Eclipse Foundation is een non-profitorganisatie die de leiding heeft over de ontwikkeling van Eclipse, een open-source IDE voor Java.. 56

endpoint . 16, 56

Fair Use Policy Om excessief gebruik van het netwerk te kunnen beheren, hanteren veel pro- viders een fair use policy (FUP). In deze FUP’s staat dat oneigenlijk en excessief gebruik niet wordt toegestaan: elke abonnee heeft immers een evenredig recht op capaciteit. Als een bepaalde gebruiker(sgroep) een andere gebruiker(sgroep) hindert dan mag de provi- der bijvoorbeeld het gebruik inperken, de gebruiker afsluiten, of laten betalen naar ratio. De policy verschilt per provider en wordt niet altijd even duidelijk gepubliceerd. Bron: Wikipedia. 56

framework Een framework is een verzameling van verschillende functies waar een applicatie gebruik van kan maken.. 56

FUP Fair Use Policy. 56

gateway Een gateway is een netwerkpunt dat dienstdoet als "toegang"tot een ander netwerk. De gateway is dan een netwerkconfiguratie-eigenschap die aangeeft welk netwerkadres de computer mag gebruiken als hij naar een bestemming moet die niet op het lokale netwerk gelegen is. Bron: wikipedia. 15, 16, 56

hardware-agnostic . 16, 56 HTTP . 56

Internet of Things Het Internet of Things is een naam voor alle smart devices die verbonden zijn met het internet.. 7, 8, 16, 56

kB kilobyte. 56 kb kilobit. 56

kilobit Een kilobit, afgekort kb, is 1000 bit (bron: Wikipedia).. 56

kilobyte Een kilobyte, afgekort kB, is 1000 bytes. 1024 bytes is KiB (bron: Wikipedia). 56 LoRa LoRa staat voor ’Long Range Low Power’. Deze technologie kan kleine hoeveelheden in-

formatie uitwisselen tussen objecten en systemen bij een ultralaag stroomverbruik. Hiermee is LoRa de optimale ondersteuning van Internet of Things en tegelijkertijd een energiezui- nige oplossing.. 15, 56

LoRa WAN . 56

M2M Machine-to-Machine. 15, 56

Machine-to-Machine M2M oftewel Machine-to-Machine communicatie is het draadloos uit- wisselen van informatie tussen machines en apparaten.. 56

MQTT . 56

node De term ’node’ betekent in de context van computernetwerken een computer of ander apparaat dat is aangesloten op een bepaald netwerk. Ook netwerkapparaten zelf worden aangeduid als nodes. Een aantal voorbeelden van nodes in computernetwerken zijn com- puters, laptops, routers, switches, hubs en draadloze apparatuur zoals draadloze printers, draadloze betaalautomaten en telefoons. Bron: Wikipedia. 56

Object-Relational Mapping Library ORM staat voor Object-Relational Mapping en is een techniek die er voor zorgt dat je data uit een database direct kan zoeken, wijzigen en toevoegen met behulp van een object-georiënteerde paradigm. Meestal wordt met ORM de library bedoelt die dit implementeert. Een ORM Library omsluit de code die nodig is om de data in een database te manipuleren, query talen als SQL zijn daardoor niet meer nodig. In plaats daarvan wordt gebruik gemaakt van een object in dezelfde programmeertaal als die gebruikt wordt. Alle achterliggende queries worden afgehandeld door de ORM Library.. 56

ORM Library Object-Relational Mapping Library. 31, 56

Payload Met payload wordt in de informatica de informatie bedoeld die over een computer- netwerk getransporteerd dient te worden en het doel van het transport vormt. Dit in tegenstelling tot het gehele pakket aan data dat uiteindelijk getransporteerd wordt. Dit pakket omvat zowel de payload als de informatie om het transport mogelijk te maken, zoals metadata en headers. Bron: Wikipedia. 56

SDK . 16, 56

sensor node Een sensor node is de verzameling van de verschillende sensoren. Alle sensoren zijn verbonden met bijvoorbeeld een Raspberry Pi. De Sensor node zorgt voor het verwerken van de data en verstuurd dit vervolgens naar een centrale opslag.. 3, 7, 8, 56

smart building Een smart building is door het gebruik van bijvoorbeeld Internet of Things devices eenvoudig te bedienen door personen en zorgt er voor dat bijvoorbeeld lampen automatisch op de juiste manier worden ingesteld.. 7, 56

stream API Zie API voor een uitleg over APIs. Een stream API is een speciale API doordat alle data direct wordt doorgestuurd naar de aangemelde clients. Waar bij een normale API meestal een ’vraag’ wordt gesteld aan de API met welke actie moet worden uitgevoerd, blijft de verbinding bij een stream API continue aan. De API geeft nieuwe data door op

vermaasd netwerk Een vermaasd netwerk (Engels: Meshed Network) is een opstelling waarbij iedere node is verbonden met tenminste twee andere nodes (en in potentie zelfs met alle andere netwerk-nodes; dan spreken we van ’fully connected’). Dat betekent meer bekabe- ling (of meer draadloze apparatuur) en een hogere overhead, maar het leidt ook tot een netwerk dat zichzelf automatisch herstelt als ergens een verbinding verbroken wordt, zodat de services op alle nodes gewoon blijven doordraaien.. 56

WAMP . 16, 56 websocket . 16, 56

Bibliografie

[1] M Van der Geest en S Kok. „Draadloos sensornetwerk in dijken”. Tu Delft, 24 jun 2009.

url: http://repository.tudelft.nl/islandora/object/uuid:f6dfdde5-2b6a-4721-

ab72-cd11bfc5086b?collection=education.

[2] Stacey Higginbotham. Ericsson CEO Predicts 50 Billion Internet Connected Devices by

2020. 2010. url: https://gigaom.com/2010/04/14/ericsson-sees-the-internet-of-

things-by-2020/.

[3] Todd Hoff. Facebook At 13 Million Queries Per Second Recommends: Minimize Request

Variance. 2010. url: http://highscalability.com/blog/2010/11/4/facebook- at-

13-million-queries-per-second-recommends-minimiz.html.

[4] Internet of Things Global Standards Initiative. ITU-T Y.2060. 2013. url: http://www.

itu.int/en/ITU-T/gsi/iot/Pages/default.aspx.

[5] Ron Miller. Errplane Snags $8.1M To Continue Building Open Source InfluxDB Time

Series Database. 2014. url: https://techcrunch.com/2014/12/08/errplane-snags-8-

1m-to-continue-building-open-source-influxdb-time-database/.

[6] Xose Pérez. Storing and publishing sensor data. 2014. url: http : / / tinkerman . cat /

storing-and-publishing-sensor-data/.

[7] Matt Robinson. Why Node.js is Ideal for the Internet of Things. 2014. url: https://www.

programmableweb.com/news/why- node.js- ideal- internet- things/analysis/2014/ 07/31.

[8] Tom Cartwright. Socket.io P2P. 2015. url: http://socket.io/blog/socket-io-p2p/.

[9] Cisco. Internet Of Things Will Deliver $1.9 Trillion Boost To Supply Chain And Logis-

tics Operations. 2015. url: https://newsroom.cisco.com/press- release- content?

articleId=1621819.

[10] Tom Randall. The Edge the Worlds Greenest Building. Red. door Bloomberg Businessweek.

2015. url: https : / / www . bloomberg . com / features / 2015 - the - edge - the - worlds - greenest-building/.

[11] Chris Richardson. Introduction to Microservices. 2015. url: https://www.nginx.com/

blog/introduction-to-microservices/.

[12] Rijksoverheid. Overheden investeren 70 miljoen in intelligente transportsystemen. 2015.

url: https : / / www . rijksoverheid . nl / actueel / nieuws / 2015 / 12 / 01 / overheden - investeren-70-miljoen-in-intelligente-transportsystemen.

[13] Amazon. AWS IoT. 2016. url: https://aws.amazon.com/iot (bezocht op 27-11-2016).

[14] Arjan van B. Limitations: data rate, packet size, 30 seconds uplink and 10 messages down-

link per day Fair Access Policy. 2016. url: https://www.thethingsnetwork.org/forum/

t / limitations - data - rate - packet - size - 30 - seconds - uplink - and - 10 - messages - downlink-per-day-fair-access-policy/1300 (bezocht op 23-11-2016).

[15] Robert Belleman en Kees Verstoep. The New University Smart Infrastructure. Versie 0.6a.

[16] Crossbar Community. What is Crossbar. 2016. url: http://crossbar.io/ (bezocht op 27-11-2016).

[17] Engine.io Community. Engine.io Github. 2016. url: https : / / github . com / socketio /

engine.io (bezocht op 27-11-2016).

[18] Kaa Community. Key Capabilities of the Kaa IoT Platform: Connectivity, Integration,

and Data Processing. 2016. url: https://www.kaaproject.org/platform/ (bezocht op

27-11-2016).

[19] Socket.io Community. Socket.io Homepage. 2016. url: http://socket.io/ (bezocht op

27-11-2016).

[20] Edwin Feldmann. De kracht van een smart building zit in de data aldus Forehand. 2016.

In document "Smart Building" Sensornetwork (pagina 43-62)

GERELATEERDE DOCUMENTEN