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.