Stel, je hebt een IoT-oplossing voor het lokaal bewerken van content (voordat je dit wegzet in de cloud). Je hebt bijvoorbeeld een oplossing voor beeldherkenning en -verwerking van videostreams met behulp van machine learning. Om een grote hoeveelheid dataverkeer te voorkomen, wil je niet dat allerlei apparaten al deze streams naar de cloud sturen om ze vervolgens daar te verwerken. Bovendien heb je daarvoor kostbare (Azure) cloudservices nodig. In plaats daarvan wil je dat je oplossing dit lokaal doet en hier komt IoT Edge om de hoek kijken.
Als je hiermee aan de slag wilt raad ik je aan om te beginnen met een Raspberry Pi. Als je wat verder gevorderd bent en écht aan de slag wilt met AI en machine learning kun je ook kiezen voor een Nvidia Jetson Nano Developer Kit.
IoT Edge onderdelen
Allereerst moet je IoT Edge op je apparaat installeren. Je kunt het eventueel ook eerst op je lokale PC installeren en testen. Na installatie heb je grofweg 3 componenten:
- IoT Edge modules: containers die jouw eigen of third-party oplossingen uitvoeren
- IoT Edge Runtime: hiermee bestuur je de modules
- Een interface in de cloud om je apparaten op afstand te monitoren en te besturen
Alle componenten worden uitgevoerd in containers op het IoT Edge-apparaat. Net zoals bij de standaard IoT-apparaten die we in de vorige blogs hebben besproken, kun je IoT Edge-apparaten direct verbinden met IoT Hub en kun je ze zowel individueel als groepsgewijs managen.
IoT Edge modules
In de modules gebeurt het allemaal echt. Deze containers bevatten jouw code, machine learning modellen en andere logica die nodig is voor dataverwerking. Je kunt de modules zo instellen dat ze met elkaar communiceren. Mijn testconfiguratie bestaat bijvoorbeeld uit een Nvidia Jetson Nano die een module bestuurt die vervolgens een RTSP-stream van een camera vastlegt. Weer een andere module bevat het machine learning model om de data te classificeren en naar IoT Hub te sturen.
Als je apparaat er eenmaal mee verbonden is, kun je vanuit IoT Hub zelf de modules besturen (zoals hier uitgelegd). Je kunt zelfs modules op schaal over al je apparaten implementeren. Hiervoor heb je tags en Device Twins nodig, waar we je in het volgende artikel meer over vertellen.
Misschien heb je niet alles zelf gebouwd en wil je gebruikmaken van third-party oplossingen. Op de Azure Market Place vind je heel wat kant-en-klare third-party modules, van modules voor realtime videoanalyse tot de gesimuleerde temperatuurmeter van Microsoft zelf. Ook als je laatstgenoemde module zelf niet nodig hebt kan het geen kwaad het uit te proberen om te kijken of je er wellicht op kunt voortborduren.
IoT Edge als gateway gebruiken
In de vorige blogs hadden we het ook over gebruikmaken van een IoT Edge gateway. Hier zijn veel use cases voor, bijvoorbeeld als je apparaten gebruikt die niet worden ondersteund door IoT Hub (want IoT Hub ondersteunt alleen MQTT, AMQP en HTTP). Stel, je hebt apparaten die het Modbus-protocol gebruiken en je wilt toch gebruikmaken van Azure IoT Hub. Je kunt dan zelf een module schrijven die alle types data accepteert van je lokale netwerk, dit vervolgens verwerkt en naar IoT Hub stuurt. Eigenlijk is alles mogelijk!
Voor het Modbus-protocol is er bijv. al een module kant-en-klaar beschikbaar: Azure/iot-edge-modbus: Modbus protocol module for use with the Azure IoT Edge (github.com). Deze module doet grofweg het volgende: een container (module) wordt opgestart, leest de data van de Modbus-apparaten en converteert dit naar het ondersteunde AMQP-format. Eventueel kun je de image uit elkaar halen en naar wens aanpassen.
Daarbij komt dat je IoT Edge ook kunt inzetten als gateway voor apparaten die hiërarchisch geconfigureerd moeten worden. Stel dat je één IoT Edge-apparaat hebt dat direct is verbonden met IoT Hub en meerdere apparaten die telemetriedata verzamelen. Je kunt deze apparaten zo instellen dat ze de telemetriedata naar het apparaat dat verbonden is met IoT Hub sturen (een zogenaamde parent-child configuratie). Heb je daarna eenmaal je PKI-certificaten en downstreamapparaten geconfigureerd, dan heb je een redelijk solide en makkelijk onderhoudbare oplossing. Check deze tutorial om hiermee te testen.
Confidential computing met IoT Edge
Je kunt de beveiliging van IoT Edge op veel vlakken configureren, denk aan certificaten, beveiligde verbindingen en goede routering van je berichten in zijn algemeen. Daarbovenop ondersteunt IoT Edge een hele gave feature genaamd Confidential Computing. De technologie hierachter is niet heel makkelijk te begrijpen maar het biedt in ieder geval heel goede beveiliging. Naast de IoT Security Manager die een Hardware Security Module (HSM) gebruikt om workloads en processen te beveiligen, wordt ook de data beschermd gedurende de runtime. Hiervoor wordt nameklijk een Trusted Execution Environment gebruikt, een geïsoleerde omgeving in de processor. Jouw app (een confidential app) wordt dus uitgevoerd in een omgeving die geïsoleerd is van alle andere lopende processen.
Om dit te bereiken is er wel wat ontwikkelinspanning nodig. Om een confidential app te bouwen ben je deze eigenlijk aan het encrypten. De app wordt nu zowel on-the-fly als in rust geencrypt, zelfs in het Azure Container Registry (we hebben het nog steeds over modules). Alleen na deployment en tijdens het opstarten wordt de app gedecrypt binnen de Trusted Execution Environment, waar het compleet veilig en geïsoleerd is van andere processen.
Confidential computing is trouwens niet iets van IoT Edge zelf, maar veel breder dan dit. Wil je meer weten over confidential computing in Azure in zijn algemeen, check dan dit artikel van Microsoft.
What’s next?
In het volgende artikel gaan we verder in op het gebruik van Device Twins om je apparaten te managen. Stay tuned!
Dit artikel is onderdeel van een reeks
Artikel 1: Intercept of Things - deel 1: Introductie
Artikel 2: Intercept of Things - deel 2: Plan je IoT Solution