Internet of Things/Architectuur

Een voorbeeld-architectuur voor het Internet of Things

In deze voorbeeld-architectuur geven we de verschillende onderdelen van het internet of things aan: wat is hun rol in het geheel, hoe zijn de verschillende onderdelen verbonden, waar kun je deze plaatsen? We bespreken 3 varianten van deze architectuur, in volgorde van toenemende complexiteit. Deze architectuur is in het bijzonder bedoeld voor toepassingen van het IoT thuis en op school.

Deze architectuur is bedoeld als voorbeeld, niet als norm: er zijn zeer veel verschillende mogelijkheden. Voor andere omgevingen, zoals industriële toepassingen van het IoT, zijn andere keuzes mogelijk beter.

Waar ie belangrijk bij IoT-toepassingen?

IoT-toepassingen verschillen in een aantal opzichten van web-toepassingen en andere internet-toepassingen. Bij het web is er bijvoorbeeld steeds meer sprake van beeld en geluid: toepassingen die veel bandbreedte vragen. Soms is de latency daarbij minder van belang. Een handige keuze is dan het gebruik van erg grote pakketten. Bij IoT-toepassingen heb je te maken met andere aspecten.

Op welke aspecten beoordelen we een IoT-architectuur?

• eenvoud
• kosten
• betrouwbaarheid
• veiligheid (security) en privacy
• snelheid (latency)
• ... (bandbreedte, als het om veel sensoren/nodes/data gaat)
• energieverbruik van de sensor-nodes
• open of gesloten?
• gemak van installeren

Componenten

Things: Sensoren, actuatoren, nodes

Het internet of things begint met "things": dit zijn fysieke objecten die we op de een of andere manier vanuit het internet willen observeren (met sensoren) en besturen (met actuatoren). Deze sensoren en actuatoren zijn verbonden met een sensornode, of kortwet node. Deze node zorgt voor de eerste bewerking van de sensorsignalen, en stuurt deze vervolgens door naar het internet. Een sensornode bestaat uit de volgende onderdelen:

• • sensoren en actuatoren;
  • processor, voor het rekenwerk, de lokale besturing, en allerlei protocollen;
  • communicatie, bijvoorbeeld in de vorm van een radio of een ethernet-interface;
  • energievoorziening, bijvoorbeeld in de vorm van een batterij.

We gaan elders dieper in op deze nodes.

MQTT broker

Een MQTT broker zorgt voor een eerst laag in het afleveren van de sensor-berichten naar het IoT-backend.

Door een MQTT broker in het publieke internet kunnen lokale nodes in twee richtingen communiceren met de rest van het internet.

NodeRed server

We gebruiken NodeRed als het schakelstation in het Internet of Things: we kunnen hiermee de verschillende sensor-stromen koppelen aan web-diensten en andere backend-diensten (bijvoorbeeld voor de opslag van gegevens in een database, en voor Data Analytics). We kunnen NodeRed bovendien gebruiken als webserver voor eenvoudige web-toepassingen, die we kunnen verbinden aan de sensornodes.

Database

In veel gevallen moeten we de sensor-gegevens op kunnen slaan. Dit kan bijvoorbeeld met een database verbonden aan een NodeRed server.

Architectuur - versie 1

De volgende figuur geeft aan hoe we deze verschillende onderdelen kunnen plaatsen, en hoe we deze onderling kunnen verbinden.

Toelichting:

• in deze figuur staat een wolk voor het publieke internet;
  • de communicatie tussen de sensoren en de sensornodes vindt lokaal plaats, en de communicatie van de sensornodes naar de broker via het publieke internet;
• de sensornodes communiceren via MQTT (over IP) met de MQTT-broker in het publieke internet.
  • deze MQTT-verbinding werkt in twee richtingen: een lokale client kan zowel "publish" als "subscribe"-interactie met de MQTT-broker hebben.
• de NodeRed-server fungeert als IoT-schakelbord, op een hoger niveau:
  • de NodeRed-server communiceert met de MQTT-broker (zowel "publish" als "subscribe").
  • de NoderRed-server communiceert met andere webdiensten, Data Analytics diensten, enz.
  • en heeft uitgebreide mogelijkheden voor opslag (database)
• een web-toepassing op een laptop of mobiel apparaat communiceert met een NodeRed-webserver
  • voor de "push" van bijvoorbeeld sensordata vanuit NodeRed naar de laptop gebruiken we het websockets-protocol.

Evaluatie van deze architectuur

• Een groot voordeel van deze architectuur is de eenvoud: je gebruikt relatief weinig componenten;
• De betrouwbaarheid van de IoT-toepassingen hangt af van de hele keten
  • Als je dit bijvoorbeeld gebruikt om in je huis een lamp aan te zetten, werkt dit alleen als de hele keten via het internet werkt.
• De veiligheid (security) is beperkt:
  • Veel nodes (zoals Arduino's e.d.) hebben te weinig rekenkracht voor een beveiligde (SSL) verbinding naar de broker
  • (dit kan in de toekomst veranderen: nodes worden steeds krachtiger; maar dat vraagt altijd extra energie)
• Doordat er weinig schakels in de keten zitten, kan deze snel zijn (lage latency)
  • NB: dat is niet helemaal waar: je moet wel altijd de hele keten gebruiken, waarbij de latency naar externe servers (MQTT broker, NodeRed server) veel groter is dan de lokale latency.)

Architectuur - versie 2

Figuur:

We voegen in dit geval een lokale MQTT-broker en NodeRed-server toe. Dit heeft de volgende voordelen:

• lokale IoT-toepassingen kunnen ook werken als er geen verbinding met het publieke internet is;
• de snelheid (latency) van lokale IoT-toepassingen wordt bepaald door de lokale vertragingen, niet door de vertraging via het publieke internet;
• de minder goed beschermde communicatie tussen de nodes en de MQTT-broker vinden plaats in het lokale netwerk, niet

Architectuur - versie 3

Figuur:

We kunnen de lokale hub ook voor andere doeleinden gebruiken: we kunnen deze gebruiken als een lokale gateway voor andere protocollen. Voor de communicatie tussen de nodes en de hub/gateway kunnen we dan gebruik maken van protocollen zoals ZigBee of Bluetooth, die niet gebaseerd zijn op het internet protocol (IP).

Evaluatie van deze architectuur

• evolutie van de communicatie-architectuur (o.a. radio) mogelijk, door upgrade van de hub.
• (net als bij V.2) de onversleutelde communicatie tussen de nodes en de hub/gateway is alleen lokaal; de verbinding over het publieke internet is goed te beveiligen (o.a. door de grotere rekenkracht van de Raspberry Pi.)
• net als V.2 is lokale communicatie voldoende voor lokale toepassingen: je hebt dan geen extra latency door een internet-verbinding.
• je kunt een combinatie van verschillende soorten radio's (en andere verbindingen) gebruiken, bijvoorbeeld:
  • WiFi
  • RFM69 (868 MHz, groter bereik dan WiFi, low power)

Evolutie van de (lokale) communicatie

Door het gebruik van een hub (ster-netwerk) kun je het netwerk goed aanpassen aan nieuwe ontwikkelingen. Als je een nieuwe of andere radio wilt toevoegen aan het netwerk, dan hoef je daarvoor alleen de hub uit te breiden. De bestaande nodes kunnen de bestaande radio('s) van de hub blijven gebruiken.

Dit is ook de manier waarop WiFi netwerken evolueren: hier is sprake van een ster-netwerk met het WiFi base station als hub. (Soms is dit een multi-ster-netwerk, met meerdere base stations). Als je dit base station vernieuwt, dan kunnen de apparaten die deze nieuwere WiFi-versie ondersteunen deze direct gebruiken, terwijl de oude versies gewoon beschikbaar blijven.

In een maas-netwerk is het veel lastiger om nieuwe radio's in te voeren: eigenlijk moet je dan alle nodes van een nieuwe radio voorzien, of je moet een aantal uitzonderlijke nodes (gateways?) toevoegen.

Node-architectuur

De architectuur van een node, en de keuzemogelijkheden die je daarvoor hebt, hangen nauw samen met de lokale IoT-architectuur. (Het niet-lokale deel is - door het gebruik van de juiste interfaces en protocollen - niet hard gekoppeld aan de node-architectuur.

Voorbeeld: Arduino Uno met Ethernet

Het eerste voorbeeld van een node is een Arduino Uno met een Ethernet-verbinding, bijvoorbeeld in de vorm van een Ethernet-shield.

• In dit geval gebruik je voor de communicatie met het internet een bedrade verbinding (Ethernet). Deze kun je eventueel ook gebruiken voor de energievoorziening van de node, via "Power over Ethernet" (PoE). Hiervoor heb je extra onderdelen nodig, zowel aan de kant van de router/switch (voor het toevoegen van de power) als aan de kant van de node (voor het gebruik van de power).
• Het officiële Arduino Ethernet-shield is nogal duur; je kunt er ook voor kiezen om hiervoor een goedkopere (Chinese) variant te gebruiken.

• processor: Atmega328 (32 kbyte programmageheugen; 2 kbyte RAM)
• communicatie: Ethernet (via Ethernet shield)
• energie: bedraad (bijv. via USB; eventueel: Power over Ethernet)

Voorbeeld: NodeMCU met WiFi

De NodeMCU-bordjes zijn gebaseerd op de ESP8266, waarin een WiFi-radio gecombineerd wordt met een redelijk krachtige processor. Ten opzichte van een Arduino UNO heb je veel meer rekenkracht en geheugen tot je beschikking (maar iets minder I/O pinnen). Je kunt deze bordjes gewoon via de Arduino-IDE programmeren. Bovendien zijn deze bordjes goedkoop (vergeleken met een Arduino): -12 Euro, afhankelijk van de leverancier.

• processor:
  • 4 MByte programmageheugen/Flash storage
  • 128 kbyte RAM
• communicatie: WiFi (ingebouwd in ESP8266-module)
• energie: via USB

De WiFi-communicatie vraagt de nodige energie (???); het ligt daarom niet voor de hand om hiervoor een batterij te gebruiken.

Een variant van de NodeMCU is de xxx. Deze is iets kleiner en heeft minder pinnen beschikbaar, maar is voor het overige te vergelijken met de NodeMCU-bordjes. Deze zijn nog goedkoper dan de NodeMCU-bordjes.

Je gebruikt deze bordjes vaak in combinatie met een breadboard waarop je de sensoren e.d. kunt monteren.

• https://learn.sparkfun.com/tutorials/esp8266-thing-hookup-guide/example-sketch-goodnight-thing-sleep-mode

Voorbeeld: Raspberry Pi als node

We kunnen sensoren e.d. ook direct aansluiten op een Raspberry Pi: we kunnen deze ook gebruiken als IoT-node.

Voor het aansturen en uitlezen van de sensoren en actuatoren kunnen we NodeRed gebruiken: de NodeRed-versie van de Raspberry Pi heeft speciale nodes voor de toegang tot de de GPIO-poorten van de Raspberry Pi. NodeRed kan ook optreden als MQTT-client, zowel voor uitgaande berichten (publish) als voor binnenkomende berichten (subscribe).

Een alternatief is het gebruik van Python. Vanuit Python hebben we toegang tot de GPIO-poorten. We hebben in dit geval een MQTT-library nodig, om de Raspberry Pi als MQTT-client te kunnen gebruiken. De Paho-library is hiervoor geschikt.

• documentatie van Paho-library: https://eclipse.org/paho/clients/python/
• installeren van Paho-library: pip install paho-mqtt
• gebruik van Paho-library in Python: import paho.mqtt.client as mqtt
  • zie verder de Paho-documentatie.

Voorbeeld: Arduino (enz.) met RFM69

We gebruiken in dit geval een andere radio: de RFM69 gebruikt de 868 MHz-band. Hierdoor heeft deze een groter bereik dan het normale WiFI-bereik; bovendien is er minder kans op storing: op veel plaatsen is de WiFi-band nogal druk bezet, door WiFi, Bluetooth (en magnetrons;-). Deze radio is bovendien energie-zuinig (ten opzichte van WiFi).

De radio-module sluiten we door middel van een speciaal bordje aan op de Arduino: dit zorgt voor de mechanische en elektrische aanpassing. De radio gebruikt 3.3V, waar een normale Arduino 5V gebruikt.

Evaluatie

Als je het energieverbruik van een node erg klein wilt maken, bijvoorbeeld om een kleinere batterij te gebruiken, of om minder vaak de batterij te vervangen, dan kun je de volgende maatregelen nemen:

• beperk het gebruik van de radio;
  • hoewel zenden meer energie kost dan ontvangen, vraagt ook het ontvangen de nodige energie. Een ontvanger die continu aanstaat vraagt dan uiteindelijk veel meer energie dan een zender die maar even actief is.
• zet de node zoveel mogelijk in de "sleep" toestand;