Blog

Intercept of Things - deel 2: Plan je IoT Solution

Je bent eruit, IoT is wat je nodig hebt en je weet zo ongeveer wat je gaat bouwen. Maar voordat je begint is het een goed idee om even een stapje terug te doen en goed na te denken over de architectuur. Je hebt een device, je hebt een cloud en je hebt een use case. Hoe gaat dit samenwerken? Als je hier van te voren niet goed over nadenkt, loop je het risico om in een later stadium geconfronteerd te worden met een omgeving die je moet aanpassen. En juist dat willen we voorkomen.

Het device

Belangrijk puntje.. Het apparaat zelf. Wat voor IoT oplossing ga je bieden? Hebben we het over simple telemetrie zoals temperatuur, luchtvochtigheid, misschien bewegingen? Of ga je iets doen met object herkenning en gezichtsherkenning? Misschien wil je wel machines aansluiten op de cloud en deze vanuit Azure gaan beheren.

Dat zijn veel vragen en voor alles is een use case. Het is echter belangrijk om van te voren te weten wat jouw oplossing gaat doen, hoeveel data deze gaat genereren en en hoeveel verwerking van data er lokaal en in de cloud gaan plaatsvinden. De antwoorden op deze vragen bepalen namelijk wat voor IoT configuratie je in Azure nodig hebt en wat je op het device moet gaan configureren en bouwen. Deze fundamentele vragen moeten worden beantwoord voordat je start met Implementatie. Het is namelijk nogal een verschil of je lokaal de temperatuur gaat meten of dat je video gaat analyseren, de capaciteit van het apparaat waar je voor ontwikkelt is hier de sleutel.

Data

Deze devices gaan data generen en deze data moet ergens heen. Als we kijken naar Azure IoT Hub dan kan IoT Hub veel (en ik bedoel heel veel) data verwerken en naar bijna iedere relevante Azure Service versturen met built-in connectors of het gebruik van Logic Apps en Azure Functions.

Het bouwen van een proof of concept wordt doorgaans aangeraden maar ook hier moet je rekening houden met de schaalbaarheid van je oplossing. Éen enkel device genereert niet heel veel data, maar wat als je duizenden sensoren gebruikt?

Wat als je een oplossing ontwikkelt waarbij je data verzamelt van verschillende sensors als temperatuur, luchtvochtigheid en bewegingen maar daarnaast ook de mogelijkheid wil bieden om lichten aan het uit te zetten. Als je dit voor een enkel kantoortje ontwikkelt dan valt de data wel mee. Maar wat als de klant aangeeft dit in ieder kantoor te willen in het gehele gebouw? Dat is nogal een verschil en heel wat data wat verstuurd moet worden. Daarbij komt dan de volgende vraag; hoe vaak en welke data wel je precies ontvangen? Real-time? Batches? Dit is waar connectiviteit een rol gaat spelen.

 

Connectiviteit

Zodra je weet wat voor data je gaat generen en hoe veel dan moet er gekeken worden naar de connectiviteit. Wat voor protocollen ga je gebruiken? Hoe groot zijn de pakketjes? Heeft een gemiddeld kantoor wel de benodigde internetverbinding? Er zijn een aantal factoren waar we rekening mee moeten houden:

  • De locatie en de internet connectiviteit
  • De hoeveelheid data welke je naar IoT Hub wil gaan versturen
  • De interval (wanneer en hoe vaak wil je data gaan versturen)
  • Moet het apparaat alleen versturen of ook instructies kunnen ontvangen vanuit de cloud?

We moeten dus wat keuzes gaan maken. Belangrijkste hier is het protocol. We hebben dan doorgaans de volgende opties als we het hebben over Azure IoT Hub:

  • AMQP
  • MQTT
  • HTTPS

Voor zowel AMQP als MQTT ondersteunt IoT Hub ook Web Sockets (poort 443)

AMQP

MQTT

HTTPS

Supports multiple devices per (TLS) connection)

Supports a single device per connection

Support a single device per connection

Supports Cloud to Device messages

Supports Cloud to Device messages

Does not support Cloud to Device messages but polls instead

Usually used for gateways (connect multiple devices to the gateway, connect the gateway to IoT Hub)

Used for devices with limited resources and connected directly to IoT Hub

Used for devices with limited connectivity

 

En dan hebben we nog de uitdaging: Wat als mijn apparaat geen van deze protocollen gebruikt en ik iets gebruik als ModBus of een eigen geschreven binary protocol? Ook dat kan maar dan kijken we al snel naar een oplossing als IoT Edge Gateway om de nodige vertaling van de protocollen naar een IoT Hub supported protocol te vertalen zoals hierboven is beschreven in de tabel.

Wat hierin wel belangrijk is, is dat de devices dan via een gateway verbinding. De Gateway wordt door Iot Hub gezien als het apparaat. In je data moet je dus mee gaan geven welke data van welk apparaat (identifier) afkomstig is.

Deze gateway configuratie wordt ook gebruikt als je meer de kant van batch processing / intervals op gaat. De gateway stuurt dan periodiek berichten/data sets naar IoT Hub.

Je kunt uren discussiëren over welk protocol het beste bij jouw oplossing past maar deze informatie geeft je op hoofdlijnen de opties. Denk overigens ook aan de quota’s en limieten van IoT Hub.

Verwerken van de data

Dan het volgende: waar wordt de data verwerkt? Je hebt hier twee mogelijkheden; het apparaat verbindt direct met IoT Hub en alle data wordt verzonden en daar verwerkt of je verwerkt data (deels) op het apparaat zelf. Voor de eerste optie kun je de al beschikbare SDKs gebruiken om direct naar IoT Hub te verbinden vanuit je code. Voor de tweede optie moeten we kijken naar Azure IoT Edge. We gaan hier in een later artikel specifiek op in maar het is belangrijk om het concept te snappen voordat je een keuze maakt. IoT Edge bestaat uit een runtime dat op het device aanwezig is en deze beheert meerdere docker compatible containers. Dit noemen we “modules”. Deze modules bevatten jouw oplossing. Als we kijken naar het voorbeeld van het kantoorgebouw en je zou iets doen met gezichtsherkenning dan zie je doorgaans een module met bijvoorbeeld een PyTorch model dat je hebt getraind en een module om de camera feed op te nemen. Deze tweede module stuurt de data naar de module met het PyTorch model en de resultaten worden via de Cloud Interface van IoT Edge vervolgens naar IoT Hub gestuurd.

Je begrijpt dat dit aanzienlijk meer processing power kost op het apparaat dan wanneer je een temperatuur sensor uitleest.

Het is dus belangrijk dat je van te voren weet welke oplossing het beste bij jouw use case past, maar voor bijna iedere use case is wel een technische oplossing met IoT Hub.

 

Provisioning

De apparaten moeten natuurlijk ook geïnstalleerd worden. Één manier om dat te doen is het gebruik van de SDKs zoals we eerder hebben beschreven. Je vult de connection string in, installeert eventueel de benodigde certificaten en je apparaat is good to go. Maar even terug naar dat schalen.. Wat als we duizenden apparaten hebben? Gaan we dit dan ook handmatig in code doen? Een device kan immers een eigen identifier hebben wanneer we direct met IoT Hub verbinding, dat betekent een eigen connection string en dus duizenden apparaten handmatig configureren met allemaal een kleine afwijking (de connection string). Yup, een hoop werk..  Azure IoT Hub Device Provisioning Service is hier de redder in nood.

Met DPS kun je een zogenaamde enrollment configureren. Het enige wat je hoeft te doen is het device naar het juist endpoint te wijzen en alles wordt automatisch geconfigureerd. Hierdoor hoef je dus niet handmatig die die duizenden apparaten te configureren.

 

Wat volgt?

In het volgende artikel kaan we kijken naar het daadwerkelijk dataverkeer ofwel: device messaging. Hoe communiceer je met de cloud en weer terug naar je apparaat en hoe routeer je naar de juiste endpoints in Azure? Wordt vervolgd!

 

Dit artikel is onderdeel van een reeks 

Lees de introductie over IoT hier.