Bachelor Informatica
"Smart Building" Sensornetwerk
Matthijs Thoolen
November 2016 - 2017
Supervisor(s): Robert Belleman
Inf
orma
tica
—
Universiteit
v
an
Amsterd
am
Samenvatting
Met de opkomst van het Internet of Things worden op steeds meer locaties sensornet-werken aangelegd. Alle data die verzameld wordt door het sensornetwerk moet worden opgeslagen en verwerkt.
Het doel van dit onderzoek is om te achterhalen wat de beste manier is om de data van een sensornetwerk op te slaan en te verwerken. Hiervoor is de volgende onderzoeksvraag opgesteld: Wat is de meest efficiënte methode om van een groot aantal sensor nodes data te ontvangen en te verwerken?
Om een antwoord te kunnen geven op de onderzoeksvraag is een test-case geselecteerd waarvoor een proof-of-concept sensornetwerk is gebouwd. Met het proof-of-concept sen-sornetwerk zijn verschillende experimenten gedaan om te bepalen wat de meest efficiënte methode is om de data naar de sensor toe te sturen. Ook is getest met twee verschillende soorten databases om te bepalen wat de beste oplossing was voor deze specifieke test-case. Uit de experimenten is gebleken dat er meerdere veelbelovende optimalisaties mogelijk waren voor het sensornetwerk.
Eventueel vervolgonderzoek zou de besproken optimalisaties kunnen toepassen op een sensornetwerk om te kijken of de optimalisaties inderdaad het verwachte effect hebben.
Inhoudsopgave
1 Introductie 7 1.1 Context . . . 7 1.2 Scope . . . 7 1.3 Onderzoeksvraag . . . 7 1.4 Indeling thesis . . . 8 2 Achtergrond 11 2.1 Bestaande (sensor)netwerken . . . 11 2.1.1 Smart buildings . . . 11 2.1.2 Intelligente infrastructuur . . . 122.1.3 Internet of Things (IoT) . . . 13
2.1.4 Multiplayer games . . . 13
2.1.5 Gedistribueerde systemen en netwerken . . . 13
2.2 Bestaande netwerken en oplossingen . . . 14
2.2.1 Bekabeld en WiFi (Transport) . . . 15
2.2.2 KPN M2M (Transport) . . . 15
2.2.3 KPN LoRa (Transport + message protocol) . . . 15
2.2.4 The Things Network (Transport + message protocol) . . . 15
2.2.5 Crossbar.io (Message protocol) . . . 16
2.2.6 Socket.io (Message protocol) . . . 16
2.2.7 Microsoft Azure IoT Hub (Message protocol + Opslag) . . . 16
2.2.8 Amazon AWS IoT (Message protocol + Opslag) . . . 16
2.2.9 Intel IoT platform (Message protocol + Opslag) . . . 16
2.2.10 Kaa IoT Platform (Message protocol + Opslag) . . . 16
2.2.11 MySQL (Opslag) . . . 17
2.2.12 InfluxDB (Opslag) . . . 17
2.3 Samenvatting . . . 17
3 Structuur sensornetwerk 19 3.1 Transport en opslag . . . 20
3.1.1 Stap 1: wat is een geschikt transport protocol? . . . 20
3.1.2 Stap 2: Wat is een geschikt message protocol? . . . 21
3.1.3 Stap 3: Wat is een geschikte opslag methode? . . . 24
3.2 Test-case: Nieuwe Universiteitsgebouw . . . 25
3.3 Proof of concept . . . 27
3.3.1 Server software . . . 27
3.3.2 Sensor node software . . . 28
3.4 Test framework . . . 35
3.4.1 Virtual sensor nodes . . . 35
3.4.2 Testen met Raspberries . . . 35
4 Experimenten 39
4.1 Verzend methode data . . . 39
4.1.1 Sensordata verspreid versturen . . . 40
4.2 Opstellingen testen . . . 41
4.2.1 Centrale server (centralized) . . . 41
4.2.2 Tree netwerk (Decentralized) . . . 42
4.2.3 Distributed netwerk . . . 43 4.3 Data opslag . . . 43 5 Resultaten 45 5.0.1 Eerste subvraag . . . 45 5.0.2 Tweede subvraag . . . 45 6 Conclusie 49 7 Discussie 51 Appendices 53 A Appendix 55 A.1 Test resultaten experimenten . . . 55
HOOFDSTUK 1
Introductie
1.1
Context
Steeds meer huizen en kantoren krijgen Internet of Things apparaten om het gebouw te trans-formeren tot een zogenaamd smart building. Dat kan verschillende redenen hebben. Doordat verschillende Internet of Things (IoT) apparaten met elkaar kunnen communiceren is het mo-gelijk om alles in een gebouw op een slimme manier te laten samenwerken. Door met sensoren data te verzamelen over het gebouw en de mensen die zich in het gebouw bevinden kunnen er steeds geavanceerdere toepassingen bedacht worden.
Voor verschillende doeleinden zijn verschillende oplossingen mogelijk. In dit onderzoek zullen bestaande oplossingen worden bekeken en zullen andere onderzoeken worden besproken om zo een goed beeld te geven van de mogelijkheden van sensornetwerken en de achterliggende architectuur. Voor de experimenten zal worden gekeken naar een specifiek praktijkvoorbeeld, het "Nieuwe Universiteitsgebouw"(NU gebouw). Voor het in aanbouw zijnde NU gebouw is het de bedoeling om een geavanceerd sensornetwerk aan te leggen op alle verdiepingen. Met behulp van deze sen-soren kunnen allerhande gegevens worden verzameld over het gebouw zoals de temperatuur, de luchtdruk, de hoeveelheid (fijn)stof en passerende bluetooth apparaten. Door al deze gegevens centraal te verzamelen en beschikbaar te stellen via een publiekelijk toegankelijke Application Programming Interface (API) ontstaat één groot IT Lab waar onderzoekers en studenten inte-ressant onderzoek aan en mee kunnen doen.
1.2
Scope
Sensornetwerken zijn er in vele soorten en maten: van kleine netwerken in een enkel gebouw
tot netwerken verspreid over alle dijken in Nederland[1]. In deze thesis zullen verschillende
soorten sensornetwerken worden besproken. De focus zal liggen op sensornetwerken voor Smart Buildings.
Voor de experimenten met als test-case het NU gebouw is gekozen om het experiment te beperken tot de connectie tussen de sensor nodes en de server en het opslaan van de data. Het verwerken en analyseren van de data, het distribueren van de data via APIs en het beveiligen van de data zullen niet uitgebreid worden behandeld.
1.3
Onderzoeksvraag
De data verwerken van één enkele sensor node is relatief eenvoudig. Op het moment dat grote aantallen sensor nodes gelijktijdig sensordata doorsturen naar een server, wordt het een stuk lastiger om alles zo efficiënt mogelijk te verwerken. Grote aantallen sensor nodes stellen hele andere eisen aan de netwerkinfrastructuur en opslag infrastructuur dan een enkele sensor node. In deze thesis worden alle stappen besproken die nodig zijn om de data zo efficiënt mogelijk
Figuur 1.1: Een artist impression van het toekomstige "Nieuwe Universiteitsgebouw"bij de Boelelaan in Amsterdam.
van sensor naar de eindgebruiker te krijgen. De nadruk zal liggen op de communicatie tussen de sensor node en de (centrale) server. De hoofd onderzoeksvraag van dit project is: Wat is de meest
efficiënte methode om van een groot aantal sensor nodes data te ontvangen en te verwerken?
Tijdens het beantwoorden van deze onderzoeksvraag zullen enkele kleinere vragen beantwoord moeten worden. De eerste sub-vraag is: Wat zijn de verschillen tussen enkele veel gebruikte
fra-meworks en softwarelibraries voor sensornetwerken? Om deze vraag te kunnen beantwoorden zal
worden gekeken naar enkele veel gebruikte frameworks en software libraries in bestaande sensor-netwerken. Met deze frameworks en libraries zal een keuzehulp worden gebouwd om eenvoudig de juiste libraries te vinden voor een sensornetwerk.
De wensen ten aanzien van sensornetwerken in gebouwen zijn verwant aan de uitdagingen waar Internet of Things netwerken mee te maken hebben. In deze scriptie zal daarom ook gekeken worden naar de oplossingen die daar zijn gevonden.
De tweede subvraag is: welke optimalisaties kunnen er worden doorgevoerd aan het
sensor-netwerk om van zoveel mogelijk sensor nodes de data te kunnen verwerken? Alle sensor nodes
verzamelen continue heel veel data, al deze data moet naar de centrale server worden verstuurd. Op welke manieren kan het transport van de data, en de opslag van de data zo efficiënt mogelijk worden gedaan? In de thesis zal worden gekeken welke mogelijkheden er zijn om een sensor-netwerk efficiënter te maken. In de experimenten zal een gedeelte van de optimalisaties worden getest.
1.4
Indeling thesis
De thesis is opgedeeld in zeven hoofdstukken. Het eerste hoofdstuk is de introductie voor de the-sis, vervolgens zal in het tweede hoofdstuk de achtergrond verder worden belicht. De geschiedenis van het Internet of Things zal worden uitgelegd en bestaande netwerk oplossingen en projecten worden besproken.
In het derde hoofdstuk worden verschillende implementatie mogelijkheden besproken en zal worden gekozen welk Internet of Things protocol gebruikt zal worden voor de Proof of Con-cept. Met behulp van het gebouwde Proof of Concept sensornetwerk zullen enkele tests worden uitgevoerd om de verschillen tussen de verschillende opstellingen te testen.
Concept, de gemaakte keuzes en vervolgens een conclusie te trekken voor de onderzoeksvragen. Ook zal worden besproken welke mogelijkheden er zijn om het project verder door te ontwikkelen en de Proof of Concept implementatie verder uit te breiden tot een applicatie die in de praktijk te gebruiken is.
HOOFDSTUK 2
Achtergrond
2.1
Bestaande (sensor)netwerken
Er zijn veel verschillende sensornetwerken. Vaak wordt een sensornetwerk gebruikt om een ander systeem te ondersteunen. Bijvoorbeeld in Smart Buildings waar de gegevens van sensornetwerken gebruikt worden om bepaalde aspecten van het gebouw te kunnen controleren en beheren.
Sensornetwerken hebben veel overeenkomsten met andere soorten netwerken, enkele van deze netwerken zullen hieronder worden besproken.
2.1.1
Smart buildings
Cisco en Ericsson voorspelden beiden dat er 50 miljard Internet of Things devices zouden zijn tegen 2020 [2, 9]. Die voorspelling blijkt nu te rooskleurig te zijn geweest [23]. Toch wordt verwacht dat er in 2021 30 miljard verbonden apparaten zijn. Op dit moment zijn dat er ergens tussen de 6,4 miljard (schatting van Gartner met smartphones, tablets en computer niet meege-rekend) en 17,6 miljard (schatting van IHS met alle apparaten meegemeege-rekend) [20]. Dat betekent dat er nog een gigantisch groeipotentieel is de aankomende jaren.
Eén van de redenen dat er steeds meer connected devices komen, is de opkomst van zoge-naamde smart buildings. Er komen in gebouwen steeds meer sensoren die allemaal informatie bijhouden. Waar nu nog vaak twee afdelingen zijn, de facilitaire ICT (gebouwmanagement) en de (kantoor)automatisering, worden deze twee afdelingen steeds meer gecombineerd. Door de verzamelde gegevens slim te gebruiken, kan bijvoorbeeld geld worden bespaard door op een efficiëntere manier te verwarmen.
De mogelijkheden voor Smart Buildings zijn groot, in de praktijk zijn er al enkele gebouwen die gebruik maken techniek om het gebouw te beheren. Hieronder worden enkele Smart Building gebouwen besproken.
2.1.1.1 The Edge Amsterdam
The Edge in Amsterdam van Deloitte & AKD is "het slimste en duurzaamste gebouw ter we-reld"[10]. Met behulp van 28.000 sensoren en een app op de mobiel van de gebruiker weet The Edge precies wie je bent en wat je gaat doen. Aan de hand van de afspraken uit de agenda wordt automatisch de juiste ruimte gereserveerd en worden de lampen en de temperatuur ingesteld aan de hand van persoonlijke voorkeuren. Door handig gebruik te maken van alle verzamelde gegevens en de nieuwste duurzame technieken is The Edge ook nog eens het meest duurzame gebouw ter wereld met een een duurzaamheidsscore van 98,4 procent van BREAAM [10].
Een groot deel van de sensoren zit verwerkt in speciale lichtbakken ontworpen door Philips, allemaal verbonden via ethernet kabels. Ook zitten sensoren in bijvoorbeeld de koffiezetapparaten en maken camera’s in de garage gebruik van beeld herkenning om te herkennen welke auto’s binnen komen.
Figuur 2.1: Voorbeeld van een dashboard met alle verzamelde data uit The Edge. Alle verzamelde data van de sensoren, koffiezetapparaten, gebouwbeheer, kenteken scanner en meer komen samen in één dashboard, zoals te zien is in afbeelding 2.1. Door slim gebruik te maken van alle informatie die is verzameld, kan er voor worden gezorgd dat toiletten worden schoongemaakt als die vaker worden gebruikt, koffiezetapparaten worden bijgevuld als ze bijna op zijn, of gedeeltes van het pand tijdelijk worden afgesloten als er minder mensen aanwezig zijn. Hoe intelligent een systeem ook is, uiteindelijk is het afhankelijk van de gebruikers of het systeem ook daadwerkelijk een succes wordt. Bij the Edge was het de bedoeling dat iedereen zou inchecken via een mobiele applicatie om vervolgens aan de hand van de agenda en voorkeuren automatisch een plek toegewezen te krijgen. De techniek werkte, alleen de mensen waren te erg gehecht aan een vaste plek en kozen zelf een werkplek zonder het systeem te gebruiken. In het begin gebruikte 20% van de werknemers de app maar dat daalde al snel naar 1%[26].
2.1.1.2 Arena Amsterdam
De Amsterdam Arena is in 2017 een samenwerking aangegaan met BAM Bouw en Techniek en Honeywell [30] voor alle techniek van het gebouw. Eén van de onderdelen van het project is het vervangen van het gebouw managementsysteem. Het nieuwe systeem verzamelt allerlei informatie met behulp van sensoren die verspreid door het hele gebouw worden geplaatst. Met behulp van data-analyse moeten storingen vroegtijdig worden opgemerkt om zo te voorkomen dat er overlast ontstaat.
Bij de Arena zal gebruik worden gemaakt van een systeem ontwikkeld door Honeywell, het Outcome Based Services (OBS-)platform.
2.1.2
Intelligente infrastructuur
Ook de overheid en het bedrijfsleven maken steeds vaker gebruik van sensoren en andere meet-gegevens. In 2015 heeft de overheid 70 miljoen euro uitgetrokken om een intelligent
transport-systeem te ontwikkelen. Met dit systeem is het de bedoeling om reizigers te bedienen met
persoonlijke, real time en locatie-afhankelijke adviezen. Door gebruik te maken van data over actuele files, werkzaamheden, grote evenementen etc. kunnen verkeersstromen efficiënter worden verspreid over het land om zo de filedruk te verlichten. Bij een landelijk dekkend netwerk kan dit een file reductie van 2,5% opleveren[12].
Een ander voorbeeld is het automatisch monitoren van de stabiliteit van een dijk[21]. Met behulp van sensoren wordt onder andere de hoeveelheid water die door een afvoer stroomt ge-meten. Deze data wordt verzameld en automatisch verstuurd naar het Waterschap. Door alles continu te monitoren worden problemen vroegtijdig opgemerkt en kan op tijd worden ingegrepen om extra kosten en hinder te voorkomen.
2.1.3
Internet of Things (IoT)
The Internet of Things (IoT), of in het Nederlands het Internet der Dingen, refereert aan de situatie dat door mensen bediende computers (desktops, tablets, smartphones) in de minderheid zullen zijn op het internet[33]. De meerderheid van de internetgebruikers zal in deze visie bestaan uit semi-intelligente apparaten, zogenaamde embedded systems. Alledaagse voorwerpen worden hierdoor een entiteit op het internet, die kunnen communiceren met personen en met andere objecten, en die op grond hiervan autonome beslissingen kunnen nemen [33].
Welke apparaten wel en niet onder de noemer IoT vallen is nog een punt van discussie. In 2013 heeft het Global Standards Initiative on Internet of Things (IoT-GSI) het Internet of Things gedefinieerd als "the infrastructure of the information society"[4].
2.1.4
Multiplayer games
Op het eerste gezicht lijkt het dat multiplayer games en sensornetwerken niet heel veel over-eenkomsten hebben. Toch zijn er veel technische overover-eenkomsten tussen multiplayer games en sensornetwerken.
De grootste overeenkomst is de connectie die nodig is om gegevens bij een andere partij te krijgen. Bij games gaat de data afhankelijk van de opstelling direct naar de tegenstander(s) of eerst via de server, bij een sensor gaat de data via een server of direct naar een opslag of eindgebruiker. De technieken die hiervoor gebruikt kunnen worden, tonen grote overeenkomsten. Bij beiden is het van belang dat er gegevens verstuurd en ontvangen kunnen worden. Het grote verschil is dat het bij een multiplayer game van groot belang is dat de data zo snel mogelijk bij de andere spelers aan komt. Als de data te laat komt, is de data waarschijnlijk al niet meer van belang. Bij een sensornetwerk is het in de meeste gevallen niet van belang of de data binnen 10ms of binnen een minuut aan komt op de server.
De verstuurde data lijkt tot op bepaalde hoogte op elkaar, bij beide systemen wordt informatie over een omgeving doorgestuurd. Het type datatransport is gelijk, maar er is een verschil in de vereiste overdracht snelheid. Door te kijken naar hoe de dataoverdracht bij multiplayer games wordt opgelost. Is het mogelijk om bepaalde ideeën over te nemen, en andere aan te passen aan de specifieke eisen van een sensornetwerk.
2.1.5
Gedistribueerde systemen en netwerken
’Distributed computing’ is een techniek waarbij rekentaken niet door één enkele computer, maar door een verzameling computers verbonden in een computernetwerk worden uitgevoerd[32]. Daarbij is het van belang dat een taak opgesplitst kan worden in verschillende kleinere taken die parallel aan elkaar kunnen worden uitgevoerd.
Bij een sensornetwerk dat gebruik maakt van sensor nodes met (relatief) veel rekenkracht, kan met behulp van een gedistribueerd netwerk een gedeelte of zelfs alle berekeningen worden gedaan op de nodes. Afhankelijk van hoe het netwerk precies wordt ingericht, kan de centrale server volledig worden vervangen. Door het systeem niet volledig afhankelijk te laten zijn van één centrale server is er niet een single point-of-failure in het netwerk.
Met een gedistribueerd netwerk is de infrastructuur er achter wel ingewikkelder. In plaats van dat iedere sensor alle data direct naar één centrale server stuurt, moet de data naar één of enkele andere nodes worden gestuurd. Alle data moet verspreid worden opgeslagen over de nodes, en bij een data request moet al die data weer verzameld worden. Dit zorgt voor een hoop extra ’administratie’, maar zorgt er ook voor dat het netwerk redundant is, en zelfs nog blijft werken als er meerdere nodes uitvallen.
Een tussen-oplossing is een tree based netwerk zoals weergegeven in 2.2. Bij een tree based netwerk-structuur stuurt iedere node de data naar een steeds ’hogere’ node in de netwerk struc-tuur, uiteindelijk komt de data terecht bij één of eventueel enkele centrale root nodes. Als één van de nodes uitvalt kan een andere node die taak direct overnemen. Als de root node uitvalt kan dat wel nog steeds voor problemen zorgen, maar doordat alle nodes daaronder nog wel ge-woon door blijven werken, kan de data verzameling wel door blijven gaan. Als de root node weer online komt, kan alle data alsnog worden verstuurd. Andere oplossingen kunnen zijn dat de root node redundant wordt uitgevoerd of dat de taak eenvoudig door één of enkele andere nodes overgenomen kan worden. Hoe redundant het hele systeem moet worden uitgevoerd, is afhankelijk van de gewenste uptime en hoe erg het is als er een tijdelijke storing is.
Figuur 2.2: Binary tree netwerk model
2.2
Bestaande netwerken en oplossingen
Om een sensornetwerk op te zetten zijn er verschillende onderdelen nodig. Onderstaande lijst geeft een overzicht van enkele basis onderdelen, naast de sensor node zelf, om een standaard sensornetwerk op te zetten. De verschillende onderdelen zijn:
• Transport mogelijkheid voor de data. • Message protocol.
• Opslag van de data.
Figuur 2.3: Een overzicht van de besproken libraries en frameworks. Per framework is aangegeven welke functionaliteiten er worden aangeboden.
In figuur 2.3 zijn 12 verschillende libraries en protocollen weergegeven die onderdeel uit kun-nen maken van een sensornetwerk. Om een volledig netwerk op te zetten is het van belang dat uit iedere laag één optie wordt gekozen.
De 12 opties uit figuur 2.3 zullen eerst hieronder worden geïntroduceerd. In het volgende hoofdstuk zal een vergelijking worden gemaakt om te kijken welke optie het meest geschikt is voor de specifieke eisen van een sensornetwerk.
Alle 12 opties uit figuur 2.3 zullen nu kort worden besproken.
2.2.1
Bekabeld en WiFi (Transport)
Kabels en WiFi kunnen beide gebruikt worden om gegevens te versturen over een netwerk naar andere apparaten die aangesloten zijn op hetzelfde netwerk. WiFi en kabels leveren alleen het transport medium. Om ook gegevens te kunnen versturen, is het nodig om een netwerkstandaard te hebben, zodat de apparaten op het netwerk kunnen communiceren. In dit geval zal er van worden uitgegaan dat er gebruik wordt gemaakt van de Ethernet (IEEE 802.3) standaard.
2.2.2
KPN M2M (Transport)
Het KPN Machine-to-Machine (M2M) netwerk maakt gebruik van een simkaart en het 2G, 3G en/of 4G netwerk. KPN M2M ondersteunt realtime verbindingen en is het niet bedoeld voor energiezuinige apparaten. Doordat er gebruik wordt gemaakt van al bestaande netwerken, kan KPN wereldwijde dekking garanderen. KPN’s M2M oplossing is vooral gericht op bewegende producten zoals auto’s, koffers en containers.[28]
2.2.3
KPN LoRa (Transport + message protocol)
KPN LoRa (Long Range, Low Power) is een apart landelijk dekkend netwerk van KPN dat is bedoeld voor eenvoudige, incidentele data-uitwisseling. Zoals aan/uit, bezet/vrij etc. Een LoRa accu kan tot wel 15 jaar lang data verzenden en ontvangen op 2 penlite-batterijen[27]. Daarmee is het vooral geschikt voor apparaten die op afgelegen plaatsen gedurende langere tijd kleine hoeveelheden data versturen.
Via het KPN LoRa netwerk wordt de data verstuurd naar servers van KPN, vervolgens wordt de data doorgestuurd naar de ingestelde applicatie server waar de data kan worden opgeslagen.
2.2.4
The Things Network (Transport + message protocol)
’The Things Network’ bestaat uit een open-source community van meer dan 6000 mensen die wereldwijd in 60 landen een Internet of Things netwerk willen opzetten[29]. Daarbij wordt gebruik gemaakt van LoRaWAN voor grotere afstanden en Bluetooth 4.2 voor kleinere afstanden[29]. The Things Network is een open-source netwerk. Doordat het netwerk wordt opgezet door personen die één of enkele gateways neerzetten in plaats van één groot bedrijf die een netwerk bouwt, kunnen de kosten zo laag mogelijk worden gehouden. Op dit moment is het gebruik van het netwerk volledig grati. Wel zitten er enkele beperkingen aan het aantal berichten dat kan worden verstuurd. De beperkingen zijn afhankelijk van een Fair Access Policy. Die zijn op dit moment als volgt[14]:
• Gemiddeld 30 seconden uplink naar de gateway, per dag, per device.
• Maximaal 10 downlink berichten per dag, inclusief ACKs for uplink confirmations
Net als bij KPN LoRa wordt de data door het ’The Things Network’ getransporteerd van de sensor node naar de servers van The Things Network, waarna de data automatisch wordt verstuurd naar de ingestelde applicatie server. ’The Things Network’ biedt wel een mogelijkheid om 7 dagen lang de gegevens op te slaan, maar daarna moet de data worden opgeslagen op een ander systeem.
2.2.5
Crossbar.io (Message protocol)
Crossbar.io biedt een open-source implementatie voor het websocket Protocol en WAMP proto-col. Verder zijn enkele extra functionaliteiten toegevoegd zoals routing, geïntegreerde Web server en authenticatie [16].
Doordat Crossbar.io gebruik maakt van het bestaande WAMP protocol, is het eenvoudig om ook andere WAMP compatible software en hardware toe te voegen.
2.2.6
Socket.io (Message protocol)
Socket.io is een real-time engine die bidirectionele event gebaseerde communicatie mogelijk maakt tussen een client en server. Socket.io is platform onafhankelijk en werkt in iedere browser en op alle devices[19]. Intern maakt socket.io gebruik van engine.io voor de communicatie layer [17], socket.io voegt daar enkele handige functies aan toe zoals automatische reconnecting, event emitting en message namespacing.
2.2.7
Microsoft Azure IoT Hub (Message protocol + Opslag)
De Azure IoT Hub is de oplossing van Microsoft voor een Internet of Things platform. Ap-paraten kunnen eenvoudig worden verbonden met het platform, de communicatie kan worden geregeld met open-source apparaat-SDK’s. Alle apparaten kunnen eenvoudig worden beheerd en geüpdatet vanaf het dashboard.
Het Microsoft platform biedt het message protocol aan om de data van de sensor node naar de server te krijgen, alsmede de opslag van de data in een database. Met behulp van andere diensten van Microsoft kunnen eenvoudig extra functionaliteiten worden toegevoegd. Zo kan met ’Stream Analytics’ eenvoudig een realtime analyse worden gemaakt van alle binnenkomende data van de sensoren. [22]
2.2.8
Amazon AWS IoT (Message protocol + Opslag)
Net als het platform van Microsoft biedt ook Amazon een bijna totaalpakket. Alleen voor het transport van de data moet nog een andere oplossing worden gezocht buiten Amazon om.
Amazon AWS IoT is het Internet of Things platform van Amazon dat eenvoudig te integreren is met andere Amazon services zoals Amazon S3, Amazon Machine Learning, Amazon Elastic search Service. Het platform kan met miljarden apparaten gelijktijdig een connectie hebben en alle berichten routen naar AWS endpoints of andere apparaten. Zelfs als apparaten tijdelijk niet verbonden zijn, kan er nog mee worden gecommuniceerd. Amazon ondersteunt meerdere standaard communicatie protocollen, maar ook custom protocollen zijn mogelijk. [13]
2.2.9
Intel IoT platform (Message protocol + Opslag)
Met het Intel IoT platform kunnen de sensor nodes via gateways worden verbonden en kan de data eenvoudig opgeslagen en gevisualiseerd worden. Verschillende tools en SDKs worden aangeleverd waardoor er makkelijk ontwikkeld kan worden. Doordat alles draait in een Data Center in de Cloud is het makkelijk schaalbaar tot miljoenen endpoints. De data kan ook beschikbaar worden gesteld aan derden via APIs en Cloud connecties.
2.2.10
Kaa IoT Platform (Message protocol + Opslag)
Waar de oplossingen van Microsoft, Amazon en Intel closed-source zijn, is het IoT platform van Kaa open-source. Open-source kan een voordeel zijn als er bijvoorbeeld aanpassingen nodig zijn aan het framework. Doordat de code vrij toegankelijk is en de software draait op eigen servers, kunnen eenvoudig aanpassingen worden gedaan aan de code. Bij closed-source producten die worden gehost op servers van een externe partij is dat vaak vrijwel onmogelijk.
Het Kaa platform biedt een open en uitgebreide toolkit for het ontwikkelen van een IoT product. Doordat Kaa hardware-agnostic is, is er geen beperking in de te gebruiken hardware [18].
Het platform biedt verder vele opties zoals integratie van analytics, real-time device monitoring, collectie en analyse van sensor data.
2.2.11
MySQL (Opslag)
MySQL is een relationele database. SQL is de taal die wordt gebruikt om de queries voor deze database te schrijven.
MySQL wordt vooral veel gebruikt voor internettoepassingen [31], maar kan ook gebruik worden voor andere type applicaties.
2.2.12
InfluxDB (Opslag)
InfluxDB is een Time Series Database. Time series databases worden gebruikt voor data die worden geïndexeerd door tijd. InfluxDB komt in verschillende onderzoeken naar voren als één
van de snelste en meest efficiënte time series databases. De compressie is bij InfluxDB tot
9.3x beter dan bij een andere time series database, Cassandra[24]. By query performance was InfluxDB zelfs tot 168x sneller dan Cassandra. Deze benchmarks zijn ook gecontroleerd door externe partijen[25].
2.3
Samenvatting
In het eerste deel van dit hoofdstuk zijn enkele bestaande senso netwerken besproken mede als enkele netwerken die veel overeenkomsten vertonen met sensornetwerken.
In het tweede deel van dit hoofdstuk is gekeken naar enkele frameworks en libraries waarmee een sensornetwerk kan worden opgebouwd. Hierin werd een onderscheid gemaakt uit 3 verschil-lende onderdelen die nodig zijn om een sensor de data te laten versturen en vervolgens op een server centraal op te slaan. Per onderdeel zijn de opties besproken die de benodigde functiona-liteiten aanbieden. Opvallend is dat er geen enkel framework of library is die een totaal pakket kan aanbieden van transport, message protocol en opslag.
HOOFDSTUK 3
Structuur sensornetwerk
Het sensornetwerk bestaat uit drie hoofd onderdelen:
• Sensor nodes (sensor laag) • Transport (netwerk laag)
• Centrale Server (opslag laag en api laag)
In figuur 3.1 zijn de verbindingen tussen bovenstaande hoofd onderdelen visueel weergegeven.
Figuur 3.1: De drie hoofd onderdelen van een sensor netwerk.
Ieder sensornetwerk is uniek en heeft andere eisen. Om die reden is er niet één standaard oplossing. Voor ieder sensornetwerk is een andere combinatie van libraries en frameworks nodig.
In dit hoofdstuk zal een keuzehulp worden samengesteld voor de netwerk laag en de opslag laag. De vragen die daarbij worden gebruikt zijn gebaseerd op een aantal punten waar de verschillende frameworks en libraries zich van elkaar onderscheiden.
3.1
Transport en opslag
In het vorige hoofdstuk zijn een aantal frameworks en libraries voorgesteld. Onderstaande keu-zehulp kan helpen om de juiste onderdelen te kiezen voor een sensornetwerk. Zoals in figuur 2.3 op pagina 14 is weergegeven zijn er drie onderdelen: transport, message protocol en opslag. Een gedeelte van de libraries en frameworks bieden twee onderdelen aan, andere libraries bieden maar één van de onderdelen aan. Om een volledig sensornetwerk te hebben is het nodig om voor alle drie de onderdelen een keuze te maken.
Bij het doorlopen van de volgende keuzehulp kan door het beantwoorden van de vragen uit de keuzehulp een combinatie worden gemaakt voor een sensornetwerk. De eerste stap van de keuzehulp is voor het bepalen van de te gebruiken transport methode.
Bij iedere vraag is er één of zijn er enkele subvragen, deze subvragen zijn vergezeld met een tabel waarin per library is aangegeven hoe geschikt die is voor de geschetste situatie. Dit wordt in de tabel aangegeven op de volgende manier:
• ++ = Zeer geschikt • + = Geschikt • 0 = Niet optimaal
• - = Ongeschikt, optie valt af
Als er geen bepaalde voorkeur is voor de vraag kan de vraag ook worden overgeslagen.
3.1.1
Stap 1: wat is een geschikt transport protocol?
Het te gebruiken transport protocol is afhankelijk van een aantal factoren. De belangrijkste factoren zijn:
• Waar worden de sensor nodes geplaatst? • Hoe vaak wordt data verstuurd?
• Hoeveel data wordt verstuurd?
Verschillende omgevingen vragen om verschillende oplossingen voor het type sensoren en de te gebruiken verbindings mogelijkheden. In open vlaktes, bijvoorbeeld op dijken, zijn andere technieken nodig dan in een stedelijk gebied of binnenin een gebouw.
Tabel 1: Waar worden de sensor nodes geplaatst?
Locatie sensoren KPN LoRa KPN M2M The Things Net w ork LAN WiFi Binnen + + ++ ++ ++ Buiten ++ ++ ++ 01 01 Gecombineerd ++ ++ ++ 0 0
1LAN en WiFi buiten is mogelijk maar niet de
meeste geschikte optie als de afstand tussen de sensor nodes groot is.
Niet alle transport opties zijn geschikt om heel frequent data te versturen. In onderstaande tabel is weergegeven welke opties het meest geschikt zijn bij de verwachte send frequentie.
Tabel 2: Hoe vaak wordt de data verstuurd naar een centrale ser-ver? Send frequentie KPN LoRa KPN M2M The Things Net w ork LAN WiFi
Vaak (Iedere X seconde) -1 + -1 ++ ++
Regelmatig (Iedere X minuten) + ++ + ++ ++
Soms (Iedere X uur) ++ ++ ++ ++ ++
1De LoRa band heeft beperkingen[14] op hoeveel procent van de
tijd er verstuurd mag worden.
De hoeveelheid data die verstuurd kan worden, verschilt flink per transport optie. Bij KPN LoRa en The Things Network is de hoeveelheid te versturen data afhankelijk van factoren zoals de afstand tot de zendmast en hoe vaak de data verstuurd wordt. Dit komt door beperkingen van LoRa in hoe lang één sensor node data mag versturen. Bij WiFi en LAN zijn er weinig beperkingen, bij M2M zitten de beperkingen vooral in de grootte van de databundel.
Tabel 3: Hoeveel data wordt verstuurd?
Data per keer KPN
LoRa KPN M2M The Things Net w ork LAN WiFi
Veel (Enkele MegaBytes) -1 + -1 ++ ++
Gemiddeld (Enkele KiloBytes) 02 ++ 02 ++ ++
Weinig (Enkele bytes) ++ ++ ++ ++ ++
1Door de beperkingen van LoRa kan maar een beperkte
hoe-veelheid data verstuurd worden.
2Gemiddelde hoeveelheid data door de LoRa beperkingen alleen
mogelijk bij een lage send frequentie.
De meest geschikte transport optie kan worden bepaald door op te tellen hoeveel plusjes iedere optie heeft behaald. Als een optie een minnetje heeft gekregen bij één van de vragen valt die direct af.
Is de keuze gevallen voor KPN LoRa of The Things Network? Die bieden beiden zowel transport als een message protocol aan. Er kan meteen worden doorgegaan naar de 3e stap voor het kiezen van de opslag library.
3.1.2
Stap 2: Wat is een geschikt message protocol?
Een message protocol zorgt ervoor dat de data kan worden verstuurt over een transport medium en bij de correcte ontvanger terecht komt. Verder is een message protocol ook belangrijk om afspraken te maken over hoe de data wordt verstuurd zodat de ontvanger en de verzender elkaar begrijpen.
KPN LoRa en The Things Network bieden deze optie aan samen met een transport laag. Deze twee opties zullen hier daarom niet meer worden meegenomen in de vergelijking.
De keuze tussen open-source of closed-source software is vaak een kwestie van voorkeuren. Beide soorten hebben voor-en nadelen. Ook zijn niet alle open-source producten aan elkaar
gelijk. Sommige open-source producten worden volledig beheerd door de community, terwijl andere open-source producten ook worden onderhouden door bedrijven die geld verdienen aan de ondersteuning.
Tabel 4: Open-source of closed-source software
Code Intel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io Open-source - - - ++ ++ ++ Closed-source ++ ++ ++ - -
-Bij een gedeelte van de oplossingen wordt de service extern beheerd. Er wordt per maand een bedrag betaalt om de dienst af te nemen. Er hoeven zelf geen servers aangeschaft en beheerd te worden. Als de kennis om server te beheren al in de organisatie aanwezig is kan dat een grote kostenpost schelen.
Hosted en self-hosted hebben verschillende voor-en nadelen. Bij een hosted versie is het voordeel dat alle infrastructuur uit handen wordt genomen en het (meestal) heel eenvoudig schaalbaar is. Met het uit handen geven van het serverbeheer wordt ook een gedeelte van de flexibiliteit en aanpasbaarheid weg gegeven, het is niet zomaar mogelijk om zelf aanpassingen aan het systeem te doen.
Bij self-hosting is al het beheer in eigen handen. Om alles stabiel te laten draaien is het van belang dat er voldoende expertise in huis is. Schaalbaarheid is een stuk lastiger en duurder, indien gebruik kan worden gemaakt van bestaande infrastructuur die beschikbaar is binnen de organisatie kan dat wel al een stuk eenvoudiger zijn.
Tabel 5: Hosting extern of intern beheerd?
In tel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io Extern ++ ++ ++ 01 - -Intern - - - ++ ++ ++
1Kaa biedt verschillende soorten service aan,
eventueel kan ook betaald worden voor be-heer.
In sommige gevallen zijn de standaard aangeboden functionaliteiten niet toereikend. Het kan dan nodig zijn om zelf nog aanpassingen te doen. Niet alle besproken opties bieden de mogelijkheid om zelf aanpassingen te maken aan de code. Men is beperkt tot de standaard configuratie opties.
Als de standaard opties voldoende zijn voor de gestelde eisen is dat vaak een goedkopere oplossing. Zelf aanpassingen maken aan software is vaak veel werk. Bij producten zoals die van Amazon, kunnen de kosten worden verdeeld over heel veel gebruikers waardoor de prijs een stuk lager is.
verstan-maken.
Tabel 6: Mogelijkheid aanwezig voor maatwerk in de software? Maatwerk Intel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io Ja - - - ++1 ++ ++ Nee ++ ++ ++ ++1 -2 -2
1Kaa IoT platform is standaard al een compleet
platform. Er hoeft geen maatwerk aan te pas te komen. Door het open-source karakter van de software kan het wel volledig naar wens worden aangepast. Ook biedt Kaa tegen betaling aan om aanpassingen te doen aan de software.
2Zowel Socket.io en Crossbar.io zijn standaard
geen complete oplossingen. Er moeten nog aan-passingen gemaakt worden om bijvoorbeeld de opslag laag te verbinden.
Afhankelijk van het sensornetwerk is het aantal sensor nodes altijd gelijk of kan het voorkomen dat het sensornetwerk wordt vergroot of verkleind. Bij de grote cloud aanbieders zoals Amazon kunnen eenvoudig sensor nodes worden verwijderd of toegevoegd, Amazon geeft bijvoorbeeld geen limiet aan op het aantal verbonden sensor nodes. Bij de oplossingen die op eigen servers draaien zoals Socket.io, Kaa IoT en Crossbar.io, is het lastiger om een variabel aantal nodes te hebben. De servercapaciteit is niet zo eenvoudig schaalbaar als bij de cloud aanbieders.
Tabel 7: Schaalbaarheid van aantal nodes?
Wisselend aantal nodes In
tel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io
Nee, vast aantal ++ ++ ++ ++ ++ ++
Ja, maar niet regelmatig ++ ++ ++ +1 +1 +1
Ja, regelmatig ++ ++ ++ 01 02 02
1Afhankelijk van de capaciteit van de al aanwezige hardware
kunnen sensor nodes worden toegevoegd zonder veel aanpas-singen. Als het aantal sensor nodes echter over de beschikbare capaciteit gaat, kan het nodig zijn om bijvoorbeeld nieuwe ser-vers te kopen.
2Als het aantal nodes regelmatig wisselt moet ook de
aanwe-zige server capaciteit regelmatig worden aangepast. Daardoor kan overcapaciteit ontstaan of zijn grote investeringen nodig in nieuwe hardware.
opzetten en een budget voor de jaarlijkse kosten. Bij de opties die een compleet pakket leveren zoals die van Amazon, Intel, Kaa en Microsoft zijn de opzetkosten veel lager. Men neemt een abonnement op een al bestaande dienst, alle software is al geschreven en alles draait in de cloud. Bij Socket.io en Crossbar.io en in mindere mate Kaa IoT moet er nog zelf code worden geschreven om de verschillende lagen goed met elkaar samen te laten werken. Ook moet nog een server worden opgezet en eventueel zelfs worden aangeschaft. Afhankelijk van wat de exacte wensen zijn en of er bijvoorbeeld programmeurs in dienst zijn kunnen de kosten hoog oplopen.
Daar tegenover staat vaak een lagere maandelijkse kostenpost en meer flexibiliteit als extra functionaliteit nodig is.
Tabel 8: Tijdsinvestering voor opzetten van netwerk?
Tijdsinvestering Intel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io Zo min mogelijk ++ ++ ++ + -
-Niet van belang 0 0 0 0 0 0
Tabel 9: Wat is het budget voor de periodieke kosten?
Budget In tel IoT Platform Microsoft Azure IoT Hub Amazon A WS IoT Kaa IoT So ck et.io Crossbar.io Laag - - - ++ ++ ++
Niet van belang 0 0 0 0 0 0
Alle vragen voor het bepalen van de te gebruiken software voor de netwerk laag zijn nu beantwoord. Tel nu voor alle opties de plusjes op om de winnaar te bepalen.
Als de keuze gevallen is op Amazon, Microsoft, Kaa of Intel is de keuzehulp nu afgerond. Anders kan de volgende stap worden gedaan om de opslag methode te kiezen.
3.1.3
Stap 3: Wat is een geschikte opslag methode?
Een belangrijk onderdeel van een sensor netwerk is de database. Gegevens die zijn verzameld door de sensoren moeten worden bewaard. Afhankelijk van het aantal sensoren en de frequentie van de metingen kan het aantal database entries al snel in de vele honderden miljoenen per jaar lopen.
Er zijn veel verschillende soorten databases, de twee databases die hier worden besproken zijn InfluxDB en MySQL. InfluxDB is een zogenaamde time-series database, zoals de naam al aangeeft zijn deze databases specifiek gericht op time-serie data. Voorbeelden van time-serie data zijn log-entries en sensor data.
MySQL valt onder de relationele databases (RDBMS), één van de nadelen van dit type databases is dat de database zeer snel groeit in grootte[6].
De meest voor de hand liggende keuze zou InfluxDB kunnen zijn, aangezien die specifiek bedoeld is voor time-serie data zoals bijvoorbeeld data van sensor netwerken. Echter, er zijn
• Specifieke voorkeuren voor een database door aanwezige kennis binnen de organisatie. • Keuze voor een database die zich al heeft bewezen. MySQL (1995[34]) bestaat al veel
langer dan InfluxDB (2013[5]).
Zeker voor sensornetwerken met een relatief klein aantal nodes zijn beide databases vergelijk-baar. MySQL kan miljoenen queries per seconde verwerken[3], meer dan genoeg voor de meeste sensornetwerken.
De keuze zal daarom vooral afhankelijk zijn van de persoonlijke voorkeuren. De verschillen zullen bij de meeste sensornetwerken waarschijnlijk relatief klein zijn. Echter om het zeker te weten voor een specifiek sensornetwerk kan het nodig zijn om enkele experimenten te doen met verschillende databases. In deze thesis zal ook een experiment worden gedaan om de verschillen te testen tussen MySQL en InfluxDB.
3.2
Test-case: Nieuwe Universiteitsgebouw
Voor de experimenten zal er één specifieke case verder worden uitgelicht. Er is gekozen om daarvoor het Nieuwe Universiteitsgebouw (NU-gebouw) te nemen. Het NU-gebouw is een nieuwe universiteits locatie op de VU campus in Amsterdam, het was de bedoeling dat in deze faculteit de Informatica afdelingen van de UvA en VU samen zouden komen. In het NU Smart Infrastructure document[15] zijn de doelen voor dit project vastgesteld.
Voor de experimenten zal een proof of concept sensor-netwerk worden gebouwd. Aangezien er nog geen sensor nodes beschikbaar zijn, zal de proof of concept worden getest met virtuele sensor nodes.
Om te bepalen welke libraries gebruikt worden om de proof of concept voor deze test-case te bouwen zal gebruik worden gemaakt van de keuzehulp uit de vorige sectie. De keuzehulp zal worden ingevuld aan de hand van de in het NuSmartInfrastructure document genoemde voorwaarden.
In het NuSmartInfrastructure document zijn een aantal criteria gesteld aan het sensornetwerk:
• Ongeveer 1600 sensor nodes met per node +/- 10 sensoren. • Voorkeur voor open-source.
• Weinig vaste kosten. • Geen vendor lock-in.
• Zelf de controle over de opgeslagen data. • Privacy goed waarborgen.
• Stabiel netwerk.
• Eenvoudig uit te breiden en aan te passen aan de eigen wensen.
De transport methode
Voor het kiezen van de transport methode is het belangrijk om te weten welke verbindings mogelijkheden in het gebouw aanwezig zijn en hoeveel data verstuurd wordt door de sensor nodes.
“Part of the sensor nodes will be wired (using ethernet, preferably using Power-over-Ethernet to simplify installation since a single cable is then sufficient) . . . Some sensor nodes will have a WiFi interface, or employ another networking technology (e.g., Bluetooth Low Energy, or LoRaWAN, to support low-powered sensors both in and around the building). . . . at VU campus a LoRaWAN gateway is already active, and is being used in several projects, with various sensor types.” Geciteerd uit NuSmartInfrastructure [15, pp. 3]
In het NuSmartInfrastructure wordt er vanuit gegaan dat per sensor node per dag 312,5 Kilobytes wordt verzameld. Dit komt neer op zo’n 500mb[15, pp. 6] totaal per dag voor alle 1600 sensor nodes samen. Het is de bedoeling om een live weergave te hebben van de sensorinformatie zodat ook systemen in het gebouw aangestuurd kunnen worden.
Als de keuzehulp wordt gedaan met bovenstaande informatie is de keuze uit twee opties, LAN en WiFi.
Het message protocol
“An important overall requirement is that this equipment and the corresponding backend services (e.g., storing the sensor data and making it available for analysis) are to be considered a research infrastructure which is under control of ADI. They should specifically not be just part of a fixed closed system that is managed by someone else.” [15, pp. 2]
Uit bovenstaand citaat uit het NuSmartInfrastructure document blijkt dat de keuze voor het message protocol wordt beperkt tot open-source systemen. In tabel 4 en 5 uit de keuzehulp op pagina 22 is af te lezen dat de oplossingen van Amazon, Intel en Microsoft al meteen afvallen. Kaa IoT blijft nu over als enige ’complete oplossing’ samen met Socket.io en Crossbar.io die alleen een message protocol aanbieden.
“Not only does this infrastructure provide plenty of potential for research projects once it is finished, there are also many opportunities for students and researchers to help in the design of this infrastructure before it is constructed” [15, pp. 2]
Het is de bedoeling dat onderzoekers en studenten helpen met het opzetten en onderhouden van het sensornetwerk, blijkt uit bovenstaand citaat. Dat zorgt er voor dat de ontwikkelkosten relatief laag gehouden kunnen worden. Wel is het van belang dat de periodieke kosten voor de serverkosten zo laag mogelijk blijven. In het NuSmartInfrastructure document wordt gesproken over geschatte kosten van ongeveer 300 euro per jaar bij gebruik van intern aanwezige servers.
Als met deze informatie ook de laatste tabellen uit de keuzehulp worden ingevuld, is er een gelijke stand voor Kaa IoT, Socket.io en Crossbar.io.
Kaa IoT is een complete oplossing die zowel het message protocol als de database als functi-onaliteit aanbiedt. Om tot een definitieve keuze te komen, kan worden gekeken naar de support in de open-source community. Hoe groter en actiever de community is, hoe groter de kans is dat de software de komende jaren nog ondersteunt zal worden. Door te kijken naar het aantal stars en forks op Github is dit relatief goed in te schatten.
Tabel 10: Door te kijken naar het aantal stars, forks en open/gesloten issues op GitHub is de activiteit van de community in te schatten. Peildatum: 19 januari 2017
Naam Stars Forks Issues (Open/ Closed)
Kaa 561 213 8/1433
Crossbar 1.122 149 144/514
Socket.io 30.040 5.763 100/2085
Socket.io komt hier duidelijk uit als het framework met de grootste community support. Dit geeft uiteraard niet de garantie dat dit framework in de toekomst ook nog lang onderhouden zal worden, maar de kans is wel groter als een actieve community aanwezig is. Bijkomend voordeel is dat er voor Socket.io heel veel aanpassingen en extensies zijn geschreven om de werking aan te passen of uit te breiden. Zo is het bijvoorbeeld mogelijk om ’private rooms’[8] op te starten. Nadat de cliënt verbonden is met de algemene server, kan er samen met een andere cliënt een directe verbinding worden gelegd. De communicatie gaat daarna niet meer via de centrale server. In het geval van het sensornetwerk zou dit gebruikt kunnen worden om te werken met een zogenaamde boomstructuur opstelling.
De database
De proof of concept zal modulair worden gebouwd zodat losse onderdelen eenvoudig te verwisselen zijn voor andere oplossingen. Voor de database zal daarom nu nog geen definitieve keuze worden gemaakt. In de experimenten zullen zowel MySQL als InfluxDB worden getest.
Samenvatting
In figuur 3.2 zijn de onderdelen weergegeven die gebruikt zullen worden om de proof of concept te gaan bouwen.
Figuur 3.2: In rood gearceerd zijn de onderdelen weergegeven die uit de keuzehulp naar voren zijn gekomen
3.3
Proof of concept
Om de experimenten te kunnen uitvoeren is een proof of concept nodig van het sensornetwerk. Het is voor deze proof of concept niet mogelijk om 1600 sensor nodes op te zetten. Om toch te kunnen testen met een groot aantal sensor nodes tegelijkertijd zal een virtueel sensornetwerk worden gebouwd.
De proof of concept zal bestaan uit code voor de centrale server en code voor de sensor nodes. Beide zullen worden geschreven in de programmeertaal Node.js. Node.js staat bekend om zijn snelheid, schaalbaarheid en efficiëntie waardoor het een goede taal is voor het ontwikkelen van data intensieve, real-time applicaties [7].
De opbouw van de server software en de sensor node software zal in de volgende twee secties worden behandeld.
3.3.1
Server software
De centrale server heeft als belangrijkste taak om de data van alle sensor nodes op te slaan en eventueel te verwerken. Vervolgens kan de opgeslagen data worden gebruikt voor bijvoorbeeld analyses.
Als meer sensor nodes met de server verbinden, krijgt de server steeds meer werk om alles goed af te handelen. Om het hele systseem toch schaalbaar te houden, kan er voor worden gekozen om de taken van de server op te delen in kleinere subtaken. Op die manier kan alleen de subtaak die een bottleneck vormt op een krachtigere server of op meerdere servers tegelijkertijd worden gezet. Het opdelen van verschillende processen in losse applicaties wordt ook wel het microservice architectuur schema genoemd[11].
“Applications with a microservice architecture consist of a set of narrowly focused, independently deployable services.” - Chris Richardson
[11]
Mogelijke opdelingen zouden zijn:
• De sensor nodes connector
• Data processor van binnenkomende data • Een message broker, bijvoorbeeld MQTT • De databaselayer
• Een API
• Realtime event stream API • (Long time) Data analyse • Visualisatie
In figuur 3.3 op pagina 29 is een voorbeeld van de architectuur te zien waarin bovenstaande opdelingen zijn verwerkt. Voor de proof-of-concept is de architectuur uit figuur 3.3 gevolgd. Echter, de stream API en de Public API zijn niet gebouwd, dat viel buiten de scope van deze thesis.
In figuur 3.3 is een gedeelte van de Micro services in een cloud geplaatst. Deze Micro Services draaien gezamenlijk op een server en kunnen op drie manieren benaderd worden:
1. Via de Node connector: de Node connector maakt met behulp van Socket.io verbinding met de verschillende Sensor Nodes. Alle data komt hier binnen, en alle commando’s worden vanaf hier verstuurd.
2. Via de stream API: externe applicaties kunnen zich via de stream API aanmelden om op de hoogte gehouden te worden van bepaalde live events. Bijvoorbeeld alle data van sensor X wordt automatisch doorgestuurd naar de externe applicatie.
3. Via de Public API: via de public API kan alle data worden benaderd. Waar via de stream API alleen data die net binnen komt wordt doorgestuurd, kan via de API data uit het ver-leden worden opgevraagd. De API zorgt voor de bescherming van de data, alleen personen met rechten hebben toegang tot de data. Bepaalde data kan op die manier beperkt worden tot een selecte groep.
3.3.2
Sensor node software
Het sensornetwerk zal met virtuele sensor nodes worden getest. Dat heeft als gevolg dat er geen echte sensor data wordt gegenereerd. Alle sensordata wordt gegenereerd met een random generator. Deze random generator houdt zoveel mogelijk rekening met het type sensor om de data zo realistisch mogelijk te houden.
In de flowchart in figuur 3.4 op pagina 30 zijn alle verschillende acties te zien die in een sensor node zitten. Bij tests waar het vooral gaat om de betrouwbaarheid van de socket.io verbinding, de capaciteit van de server of de ideale grootte van een package is het niet nodig om alles te simuleren. Het kan dan voldoende zijn om enkel de ’Socket Handler Client Side’ te simuleren en een standaard response object te versturen. Op die manier kunnen meer sensor nodes tegelijkertijd gesimuleerd worden op dezelfde hardware.
De architectuur van een sensor node is te zien in figuur 3.4. In deze flowchart zijn twee grote continue processen te zien, het verzamelen van data en het verzenden van de data.
Nadat de sensor bij de ’Start process’ actie is opgestart, wordt de scheduler ingesteld aan de hand van configuratie settings die in een lokale database zijn opgeslagen. De scheduler zorgt er voor dat de juiste acties op de juiste intervallen kunnen worden uitgevoerd. In de Proof of
Figuur 3.3: Een voorbeeld van de architectuur van de server met verschillende processen opge-deeld
Figuur 3.4: De flowchart van de sensor node in de proof-of-concept. In de flowchart zijn verschil-lende processen opgedeeld in losse stukken.
• Verzamel intervallen voor de sensoren:
– Lage frequency sensorcheck (iedere 10 seconden) – Middel frequency sensorcheck (iedere 5 seconden) – Hoge frequency sensorcheck (iedere seconde)
• Verzend interval. (iedere 10 seconden)
Verzamelen van sensor data
De verschillende interval frequenties voor de sensorcheck zijn er voor de verschillende type sen-soren. Sommige sensoren zoals de temperatuursensor genereren data die niet snel verandert, en kunnen af met een lage frequentie. Voor bijvoorbeeld een geluidsensor is het van belang dat deze veel vaker gecontroleerd wordt, het aantal decibellen kan van seconde tot seconde flink verschil-len. De sensoren met een hoge frequentie genereren een in verhouding veel grotere hoeveelheid data. Een mogelijkheid om dit te beperken is door de data direct te analyseren en bijvoorbeeld een gemiddelde en maximum/minimum te berekenen.
Tijdens het maken van deze thesis waren nog geen sensoren beschikbaar om mee te kunnen experimenteren. Om toch sensor data te kunnen simuleren is een script geschreven in Node.js die data van sensoren simuleert. Voor de uiteindelijke implementatie zal dit script vervangen moeten worden door sensor specifieke code om de data uit de sensor te kunnen lezen.
De volgende actie is het opslaan van de data in de database, voor deze functie moet het niet uitmaken welk type database wordt gebruikt. Dit kan worden bereikt door een (zelfgemaakte) Object-Relational Mapping Library (ORM Library) te gebruiken. De data wordt opgeslagen met de tijd, sensortype en gemeten waarde of waarden.
Verzenden van sensor data
Alle lokaal opgeslagen informatie wordt geregeld verstuurt naar een centrale server. De frequentie waarin dit gebeurd is in te stellen en eventueel ook door de server te wijzigen als het bijvoorbeeld te druk is.
Als het tijd is om de data te verzenden wordt alle data uit de lokale database gehaald. Ook dit kan worden gedaan met een ORM Library. Al deze data zal worden verstuurd in een message object. Een message object is een custom object speciaal voor het versturen van informatie tussen de sensor node en de server.
In listing 1 is een voorbeeld te zien van hoe een message object er uit zou kunnen zien als data van zes verschillende sensoren wordt verstuurd. Standaard worden vier verschillende velden meegestuurd: name, start, end en data.
{ "name": "Lokaal B1.10", "start": "1485706671", "end": "1485706681", "data": { "temperature": { "1485706671": "20,5" }, "light": { "1485706671": "44", "1485706676": "40" }, "decibel": { "1485706671": "30", "1485706672": "34", "1485706673": "29", "1485706674": "45", "1485706675": "28", "1485706676": "35", "1485706677": "65", "1485706678": "44", "1485706679": "32", "1485706680": "78", "1485706681": "76" }, "peopleWalkedBy": "10", "macAddresses": { "0": "00:0C:6E:D2:11:E6", "1": "00:1C:6F:A2:B1:C6", "2": "10:1C:7E:E2:F1:E2" }, "bluetoothDevices": { "0": "iPhoneJaap", "1": "MacLinda", "2": "Galaxy S8", "3": "S3cr37 08@ma" } } }
Listing 1: JSON Message object voorbeeld
In het ’name’ veld wordt de naam van de sensor gezet zoals die bekend is bij de server. Meer informatie over de node hoeft niet iedere keer meegestuurd te worden aangezien deze data al verstuurd is tijdens de ’greeting’ en gekoppeld is aan de socket verbinding.
Het ’start’ en ’end’ veld geven de BREAAMs mee waarbinnen alle data is verzameld. Iedere interval kan maar één keer verstuurd worden, dus ieder verstuurd interval is uniek. Mocht een bepaald interval missen op de server dan kan de server een ’request’ sturen naar de cliënt om te vragen om data te sturen uit die interval. Een interval kan bijvoorbeeld missen als een bericht niet juist is binnen gekomen. In figuur 3.5 is een voorbeeld te zien van 5 intervallen die vanaf de cliënt naar de server worden verstuurd. Interval 1 en 2 worden correct ontvangen en krijgen succesvol een BREAAM terug van de server. Bij het 3e interval gaat tijdens het versturen wat mis, het bericht komt nooit aan op de server. Als de server de data ontvangt van het vierde interval wordt gekeken naar de eindtijd van het laatst ontvangen interval. Dat is in dit geval de ’end’ BREAAM van interval T=2, de ’start’ interval van T=4 sluit daar niet bij aan. Daarom
Figuur 3.5: Overzicht van 5 timestamp intervallen die worden verstuurd waarvan eentje niet correct aankomt.
Voor de BREAAM berichten wordt gebruik gemaakt van een custom BREAAM, in listing 2 is een voorbeeld te zien. Doordat gebruik wordt gemaakt van de socket.io BREAAM callback hoeft er geen unique ID mee gestuurd te worden. Socket.io zorgt er voor dat het bij de juiste callback terecht komt bij de client. De data die wel wordt mee gestuurd is data die vooral van belang is bij het meten van de performance van het netwerk. De client slaat in een lokale database de tijd op wanneer de berichten worden verstuurd. De server geeft vervolgens de tijd terug wanneer het bericht is aangekomen en wanneer de data is verwerkt. Met alle gemeten tijden kunnen van de volgende acties de performance worden gemeten:
1. Tijd van client -> server 2. Tijd van server -> client
3. Tijd die nodig is om de data op de server te verwerken 4. Roundtrip tijd (client -> server -> client)
{
"received": "1485706684", "returned": "1485706686"
}
Listing 2: Custom JSON ACK object voorbeeld
Socket handler
De connectie met de ’buitenwereld’ gaat allemaal via de Socket Handler, de socket handler maakt gebruik van Socket.io. Met behulp van Socket.io kunnen berichten zowel worden verstuurd als ontvangen. Als een bericht binnen komt wordt gecontroleerd of het een BREAAM is van een eerder verzonden bericht of dat het een update van de configuratie is. Een configuratie bericht kan door de server worden verstuurd als een beheerder de instellingen aanpast voor één of meerder sensor nodes. Ook de server kan een configuratie bericht sturen om bijvoorbeeld de frequentie te wijzigen om druk wat beter te spreiden.
Figuur 3.6: Overzicht verzenden van data naar de server via de socket handlers
Een speciaal bericht is de ’greeting’ (zie listing 3), als een sensor node verbinding maakt met de server wordt een bericht verstuurd naar de server met informatie over de sensor node. De server stuurt vervolgens een bericht terug met informatie over wanneer de sensor node mag beginnen met het versturen van informatie. In listing 4 is een voorbeeld greeting response te zien. De server bepaalt een tijd waarop de cliënt mag beginnen met versturen van data, de server bepaalt dit aan de hand van alle andere verbonden sensoren. De server deelt alle nodes in zodat de binnenkomende berichten gelijkmatig verdeeld zijn. De send frequentie kan worden ingesteld op een standaard waarde of het kan zo worden ingesteld dat de server zelf de beste waarde uit kiest. Als de server zelf de beste frequentie uit kiest zal worden gekeken naar het aantal verbonden sensor nodes en het ideale aantal te ontvangen berichten per seconde.
{
"name": "Sensor1587", "location": "Kamer456"
}
{
"sendStart": "1485706684", "sendFreq": "10"
}
Listing 4: Server greeting response
3.4
Test framework
3.4.1
Virtual sensor nodes
Tijdens het schrijven van de thesis was er niet de beschikking over een Raspberry Pi met sensoren. Om toch de data te kunnen verwerken is een script gebruikt die gesimuleerde sensordata terug geeft. De gesimuleerde data lijkt zoveel mogelijk op echte sensordata. Voor bijvoorbeeld de temperatuursensor wijzigt de temperatuur alleen heel geleidelijk.
3.4.2
Testen met Raspberries
Aangezien nog geen live test omgeving is en het aantal beschikbare test nodes beperkt is, is het nodig om een andere manier te vinden om toch op grotere schaal te kunnen testen. Via Amazon kunnen er tijdelijk grote aantallen virtual nodes worden opgezet, alleen kost dat veel geld. Dat is op dit moment geen mogelijkheid.
Daarom is er voor gekozen om een kleine testopstelling te maken zoals in afbeelding 3.7 te zien is. Hiermee kan op kleine schaal worden getest. Afhankelijk van de test kan op iedere node een enkele of meerdere sensor nodes gesimuleerd worden.
Figuur 3.7: Opstelling Raspberry Pi sensor nodes
3.4.3
Test suite
Om de testresultaten van het sensornetwerk op een eenvoudige manier te kunnen verzamelen is er een test suite gemaakt. Deze test suite heeft enkele handige opties om snel een sensornetwerk op te starten met de gewenste instellingen en de test resultaten direct te verzamelen.
• Gemiddelde roundtrip time van de data. De tijd die het kost om de data te versturen, te
verwerken en een reactie terug te krijgen.
• Verwerkingstijd op de server. De tijd gemeten vanaf aankomst op de server tot het moment
dat de data is verwerkt. Onder verwerken valt het controleren van de data en opslaan in de database.
• Memory gebruik van de server.
Via de instellingen kunnen onder andere de volgende opties worden gewijzigd:
• (Serverside): Database actief [True/false] • (Serverside): Type database [InfluxDB/MYSQL] • (Serverside): Request data [True/false]
• (Clientside): Simuleer meerdere sensor nodes [True/false] • (Clientside): Frequentie van sensor polling
• (Clientside): Combineer data van virtuele sensor nodes [True/false]
HOOFDSTUK 4
Experimenten
Met behulp van het gebouwde proof-of-concept (virtuele) sensornetwerk zullen enkele experi-menten worden uitgevoerd. De experiexperi-menten hebben als doel om verschillende opstellingen en optimalisaties te testen.
Voor de experimenten is een test opstelling gebruikte bestaande uit:
• 6x raspberry pi 2 als sensor nodes
• 1x laptop met ubuntu voor de centrale server
Alle apparaten waren met een LAN kabel aangesloten op hetzelfde lokale netwerk. Zowel de Raspberry Pi’s als de laptop hadden op het moment van de experimenten niks anders draaien dan de software voor de experimenten.
4.1
Verzend methode data
Alle sensor nodes sturen de data op een vast interval naar de centrale server toe. Dit kan zorgen voor een ophoping van data aan de server kant op het moment dat alle sensor nodes tegelijkertijd de data versturen. Op het moment dat de sensor nodes geen data versturen is de server juist helemaal niks aan het doen.
Figuur 4.1: De sensor nodes sturen iedere X seconden de data naar de server. X kan worden ingesteld door de beheerder. De sensor nodes starten met versturen als de verbinding is opgezet. In figuur 4.2 is op een tijdlijn weergegeven hoe druk de server het heeft tijdens een cycli. Alle sensor nodes sturen de data iedere 10 seconden naar de server. Het verzend proces is weergegeven in figuur 4.1.
Figuur 4.2: De sensor nodes versturen de data allemaal aan het begin van de cycli. Dit zorgt ervoor dat er de eerste paar seconde van de cycli heel veel data binnen komt die verwerkt en opgeslagen moet worden. De rest van de cycli komt er geen nieuwe data binnen en hoeft de server niks te verwerken.
Om de server gelijkmatiger te belasten kunnen er verschillende aanpassingen worden gemaakt: 1. De server geeft alle sensor nodes een tijd waarop de data verstuurd mag worden. Door aan
iedere sensor een andere tijd te geven kunnen de requests gespreid worden.
2. De sensor nodes bepalen zelf een random tijd binnen een bepaalde limiet wanneer de data verstuurd wordt. Bij een goede random number generator zijn de sensor node verzendtijden nu evenredig verdeeld over de tijd.
3. De server vraagt de data op bij de sensor nodes, in figuur 4.3 is de nieuwe werkwijze te zien.
Figuur 4.3: Opstelling Raspberry Pi sensor nodes
Om te kijken wat de verbetering is als de data beter wordt gespreid, wordt de tweede optie getest. Ook wordt de standaard opstelling getest waarbij er geen controle is over wanneer de sensor nodes de data versturen. Door de standaard opstelling als beginpunt te kiezen, kan bij de andere twee opties worden gekeken welke optimalisatie de grootste performance verbetering laat zien.
4.1.1
Sensordata verspreid versturen
Om de piek die ontstaat aan het begin van iedere cycli op te vangen zal de server iedere sensor node een starttijd mee geven wanneer er begonnen moet worden met versturen. De starttijd zal worden bepaald door de server aan de hand van het aantal verbonden sensor nodes. Als de sensor nodes iedere 10 seconde data verstuurt, en er 1000 nodes zijn, zal de server de 1000 nodes evenredig verdelen over de 10 seconde. Op die manier komt er iedere 0.01 seconde (10 seconden /1000) een data package binnen van een sensor node.
De verwachting is dat de server geen piek meer heeft in ontvangen sensordata packets. In plaats daarvan zouden de packages gelijkmatig binnen moeten komen bij de server. In figuur 4.4 is de verwachtte spreiding te zien op de server, de server heeft het gedurende de hele cycli even
Figuur 4.4: De verwachte spreiding van de drukte op de server na het gespreid verzenden van de data packages vanaf de sensor nodes.
De experimenten om het effect van de spreiding te testen zullen worden gedaan op een ’fake’ database. Deze ’fake’ database voert niet de daadwerkelijke query uit om de data op te slaan in de database. Op die manier wordt enkel de tijdswinst berekend die is bereikt door de ’wachtrij’ bij de server te verkleinen.
4.2
Opstellingen testen
Er zijn meerdere netwerk opstellingen mogelijk voor de sensor nodes. Het meest eenvoudige sensornetwerk om op te zetten is een netwerk met één centrale server waar alle sensor nodes de data naar toe sturen. Echter, een enkele centrale server heeft als groot nadeel dat er een single point of failure is.
In de volgende experimenten zullen er twee opstellingen worden getest. De centrale server en een tree netwerk waarbij alleen een aantal sensor nodes data direct naar de server toe stuurt.
4.2.1
Centrale server (centralized)
Bij een centralized network is er één server waarmee alle sensoren zijn verbonden. Alle sensor nodes sturen de data direct naar de centrale server. De centrale server verwerkt deze data en slaat het op in de database. In figuur 4.5 is een overzicht te zien van een gecentraliseerd sensor netwerk.
Figuur 4.5: Een voorbeeld van een gecentraliseerd netwerk diagram.
In het experiment zal er worden getest wat de gemiddelde response tijd is van de server. De metingen zullen worden gedaan met de standaard test suite. Er zal worden gemeten met en zonder database om te controleren of de bottleneck ligt bij het aantal socket verbindingen of bij de database.
4.2.2
Tree netwerk (Decentralized)
De sensor nodes zijn door middel van een tree netwerk opstelling verbonden met de centrale server. De data werkt zichzelf steeds verder omhoog in de tree, de tussenliggende nodes zijn normale sensor nodes. Als extra functie verzamelen ze de data van de sensors die lager zitten in de tree en geven die data door aan de centrale server. Een overzicht is te zien in 2.2.
Een voordeel van deze opstelling is het verminderde aantal sockets die tegelijkertijd zijn geopend bij de centrale server. Alleen de laatste rij sensor nodes (in figuur 2.2 rij D = 1) heeft een open socket met de centrale server.
Figuur 4.6: Een voorbeeld van een Tree Netwerk Diagram.
Om te testen of dit andere resultaten geeft dan bij de centrale server zullen dezelfde experi-menten worden uitgevoerd.
De server kan alle data die binnen komt van de sensor nodes combineren en in één enkele query in de database opslaan om extra tijd te besparen.
Aangezien het test sensornetwerk alleen bestaat uit virtuele nodes is het lastig om de onder-linge sockets op te zetten. In plaats daarvan zullen alle virtuele sensor nodes die draaien op één enkele Raspberry Pi alle data verzamelen en door één socket sturen. Voor de testresultaten heeft dit verder geen invloed, het aantal sockets en de data die binnen komt bij de centrale server is gelijk. Alleen de onderlinge verbindingen tussen de sensor nodes worden niet gesimuleerd.
De verwachting is dat de gemiddelde response tijd van de server significant sneller is en de standaard deviatie ook een stuk kleiner.
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.
