De verwerking van IoT-data

Door: Laurent Marlein

Het Internet of Things (IoT) belooft ons een wereld waarin alledaagse voorwerpen zoals koelkasten en thermostaten met het internet zijn verbonden en gegevens of acties uitwisselen. In heel veel huizen zijn de eerste IoT-toestellen inmiddels geïnstalleerd, maar ook in moderne kantoren zijn reeds heel wat HVAC-installaties en -sensoren verbonden met een netwerk. We behandelen in dit artikel kort de structuur en de opslag van de data die deze IoT's uitwisselen met de cloud.

Welke data?
1. Events

Wanneer we denken aan IoT, denken we aan data die in continue mate tussen een IoT-toestel en het internet stroomt. Deze data bestaan meestal uit eventdata die de status van een functie van het toestel weergeven en naar de cloud worden doorgestuurd voor opslag en verwerking. Nemen we het voorbeeld van een weerstation, dan kan dit een temperatuurmeting zijn, maar evengoed de vochtigheid of windsnelheid. Nemen we een 'wearable', dan kan dit een positie zijn, maar ook een hartslag of andere lichaamsfunctie.

Wat kenmerkt deze events?

1. Ze zijn eenvoudig van structuur en hebben minimaal een tijdstip en waarde.
2. De waarde is in de meeste gevallen een numeriek gegeven, maar kan ook een positie zijn of een ander gegeven dat wijzigt in de tijd.
3. Ze geven die waarde in een bepaalde unit. Temperatuur wordt bijvoorbeeld gegeven in °Celsius.
4. Nieuwe waardes worden doorgestuurd met een vaste of variabele frequentie, wat over een bepaalde periode resulteert in een tijdserie.
5. De waarde kan de status zijn op een bepaald moment, of op een wijziging (bijvoorbeeld het verbruik) over een bepaalde periode.
6. De waardes hebben meestal een statistisch patroon.
7. Het zijn ontzettend veel events; als een temperatuursensor om de 5 seconden een status zou doorsturen, betekent dit 17.280 events per dag of 6 miljoen events per jaar, en dit per sensor. Meten we de temperatuur in een gebouw op verschillende plaatsen, dan spreken we al snel over ettelijke miljoenen!

Welke events sturen we door en slaan we op?

Niettegenstaande de eenvoudige structuur van deze events, noopt de grote hoeveelheid aan events ons ertoe om goed na te denken over wat we met deze eventdata beogen, want anders gebruiken we veel netwerkbandbreedte en/of opslag voor data waar we niets mee aanvangen. Het is niet zinvol om elke wijziging door te sturen en op te slaan. Meestal volstaat het om af en toe een waarde door te sturen. Bij welke afwijking we een waarde doorsturen, zal afhangen van de precisie die is vereist door de processen die deze data gebruiken.

Hoe gaan we om met tijd?

Wanneer we praten over tijd, hebben we het meestal over lokale tijd. Maar wanneer we data over meerdere locaties willen opslaan, dienen we tevens rekening te houden met tijdszones en is het gebruik van zogenaamde UTC-tijd (in het Nederlands ook aangeduid als gecoördineerde wereldtijd) aangewezen.

Wat doen we met de events?

Wanneer we beslist hebben om een event door te sturen, dienen we ze tevens te analyseren, zodat we kunnen beslissen wat we ermee doen. Een lagere temperatuur kan dan resulteren in de actie 'opstarten van de verwarming'. Deze beslissingslogica kan ingebouwd worden in de software van de cloudserver, gebruikmaken van een rule engine of gebaseerd zijn op externe services als IFTTT en Zapier.

Anomalieën: hoe detecteren we ze en wat doen we ermee?

We dienen tevens rekening te houden met het feit dat de doorgestuurde waardes foutief kunnen zijn. Zo kunnen energiemeters sporadisch foutieve pieken doorsturen. Om deze te onderkennen, kunnen we gebruikmaken van minimale en maximale waardes, rekening houden met een normale verdeling en deviaties, of andere complexere algoritmes gebruiken.

2. Masterdata

Als we praten over IoT-'things', dan hebben we het over masterdata. Waar masterdata in veel bedrijven gaan over klanten (CDI) of producten (PIM), gaat het in het geval van IoT over 'assets' en toestellen. In veel gevallen willen we deze echter wel koppelen aan de andere masterdata van de organisatie om ze aldus meer context en betekenis te geven. Zo zul je van een toestel willen weten waar het zich bevindt (locatie), in welk gebouw (facility) en aan wie het toebehoort (party, customer).
Met IoT groeit niet alleen onze hoeveelheid masterdata, maar ook de hoeveelheid relaties tussen de diverse objecten.

Waar we traditioneel (relationele databases) masterdata modelleerden in een ERD-diagram, maakt de veelheid aan entiteiten en vooral relaties het nodig om te denken aan nieuwe representaties van masterdata. Het gebruik van graph-oriented modellen biedt hierbij mogelijk een uitkomst.

3. Referentiedata

Referentiedata bepalen de toelaatbare waardes die de attributen van masterdata kunnen gebruiken, en bepalen dus ook de taal waarin de masterdata worden uitgedrukt. Ze kunnen permanent  van aard zijn (zoals enumeraties opgeslagen in de software) of als aparte tabellen beheerd worden.

Enkele voorbeelden:

Voor landen zullen we gebruikmaken van ISO-landcodes, voor eenheden gebruiken we eenheden als Celsius (°C), voor functies gebruiken we afgesproken classificaties (temperatuur, energie, vochtigheid). Wil je data tussen meerdere systemen kunnen uitwisselen, dan is het uiterst belangrijk om deze referentiedata te standaardiseren zodat er bij de uitwisseling van data geen 'vertaling' dient te gebeuren.

Hoe slaan we de data op?
Dataopslag is in veel bedrijven nog een synoniem voor een relationele database. Relationele databases (bijvoorbeeld Oracle, MySQL, PostgreSQL, SQL Server en andere) slaan hun data op in tabellen en rijen, zijn meestal sterk genormaliseerd (geen duplicatie van velden en hun waardes) en maken gebruik van SQL (Structured Querying Language) voor het bevragen en beheren van de data. Ze blijven een goede keuze als de hoeveelheid aan data en relaties beheersbaar blijft.

Maar wanneer de hoeveelheid data te groot wordt, zijn er ook andere oplossingen voorhanden en kunnen we tevens gebruikmaken van een zogenaamde NoSQL-database. Deze databases slaan hun data meestal meer gedenormaliseerd op, zodat het queryen over grote hoeveelheden data kan gebeuren zonder zware joins en dus sneller verloopt, en kunnen ook sneller worden uitgebreid (we spreken van horizontaal groeien), maar garanderen evenwel minder de data-integriteit.
NoSQL kan gebaseerd zijn op verschillende opslagmethodes:

1. Documentgebaseerd: de data worden opgeslagen in XML, JSON-formaat en de attributen kunnen dynamisch wijzigen.
2. Graph-gebaseerd: de data worden opgeslagen als nodes (knopen) en edges (relaties). In vergelijking met relationele databases is dit type database veel sneller omdat er minder joins moeten worden uitgevoerd.
3. Key-value databases: de data worden opgeslagen als een sleutel met zijn waarde, waarbij die waarde ook een object kan zijn. Key-values zijn vergelijkbaar met een hashmap, waarvan de werking berust op een hashfunctie die een sleutel omzet in een hashwaarde, gebruikt om de (key-value)combinatie efficiënt te vinden.

Tag

Onderwerp

IoT


Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag