Componenten voor cloudgebaseerde software-updates in het IoT

Het updaten van software (componenten) op apparaten met beperkte rand, evenals op krachtigere controllers en gateways is een veelvoorkomende vereiste in de meeste IoT-scenario's.

Mogelijkheden voor software-updates zorgt voor een veilig IoT door IoT-projecten een gevechtskans te geven tegen de doos van Pandora die ze openden op het moment dat hun apparaten verbonden werden . Vanaf dat moment lopen de apparaten voorop bij IT-beveiligingsbedreigingen, waar veel ontwikkelaars van embedded software in het verleden nooit mee te maken hebben gehad. Tegenwoordig is het verzenden van bijvoorbeeld een door Linux aangedreven apparaat met internetverbinding zonder dat er tijdens zijn levensduur ooit beveiligingsupdates zijn toegepast, hetzelfde als zelfmoord.

Een charmanter argument voor software-updates is dat ze een flexibele ontwikkeling van hardware en hardwaregerelateerde componenten mogelijk maken. Concepten zoals het minimaal levensvatbare product kunnen op apparaten worden toegepast, omdat niet alle functies tijdens de productie gereed hoeven te zijn. Wijzigingen aan de cloudkant van de IoT-oplossing kunnen ook tijdens runtime op apparaten worden toegepast.

Soms is het updaten van software een bedrijfsmodel op zich, omdat apparaten veel aantrekkelijker zijn voor de klant als ze kunnen worden bijgewerkt. Met andere woorden, consumenten weten dat ze niet alleen een vaste set functies krijgen, maar ook kunnen profiteren van toekomstige productupdates. Daarnaast kunnen er nieuwe inkomstenstromen ontstaan ​​door het potentieel genereren van inkomsten met functie-extensies (bijv. apps ) zonder dat u een nieuw apparaat hoeft te ontwerpen, vervaardigen en verzenden (revisie).

Apparaatconnectiviteit

Er zijn verschillende mogelijkheden om een ​​toestel te koppelen aan een clouddienst. Vanuit architectonisch oogpunt moet worden besloten of apparaten rechtstreeks moeten aansluiten naar de software-updateservice of indirect via een apparaatconnectiviteitslaag (bijv. Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub, enz.), die zelf ook een IoT-oplossingsservice zou kunnen zijn. Ik ben zelf een groot voorstander van de directe aanpak en mijn product Bosch IoT Rollouts ondersteunt beide. Ik zal hieronder uitleggen waarom.

Dus laten we aan de slag gaan:met directe connectiviteit kunnen IoT-oplossingen zorgen voor een scheiding van zorgen door aparte kanalen voor software-updates te hebben naast hun eigen kanaal dat de IoT-oplossingen gebruiken voor streams en commando's van apparaatgebeurtenissen.

Dit is om twee redenen een interessante benadering:ten eerste maakt het het veel gemakkelijker om de API van het software-updatekanaal stabiel te houden als u zich niet bezig hoeft te houden met alle zakelijke vereisten van het andere kanaal . We mogen niet vergeten dat er in het IoT scenario's zijn waarin aangesloten apparaten voor langere tijd zonder contact met de backend kunnen gaan. In sommige gevallen kan het jaren duren, vooral tussen fabricage en initiële connectiviteit. Een transportlaag gedurende die tijd stabiel houden is eenvoudig, maar dat geldt zeker niet voor de bedrijfslaag. Dit geldt met name in het IoT, waar veel cloudoplossingen zich nog in de beginfase van volwassenheid bevinden.

Ten tweede stelt het hebben van een apart kanaal u ook in staat om zakelijke en updatefunctionaliteit op het apparaat zelf te scheiden . Vooral in een complexe stack (bijvoorbeeld op een IoT-gateway), wil je echt het risico lopen dat een mogelijk kapotte stack zichzelf moet updaten om het probleem op te lossen? En kan worden gegarandeerd dat het dat altijd zal kunnen? Stelt u zich een scenario voor waarin u een OSGi-runtime op uw gateway hebt met één bundel die uitzonderingen voor onvoldoende geheugen veroorzaakt en uw software-updateclient in dezelfde runtime draait. Het kan erg moeilijk zijn om de uitkomst te voorspellen.

De scheiding heeft echter een prijs:twee kanalen betekenen meestal meer implementatie-inspanningen aan de kant van het apparaat, en in sommige scenario's kan dit ook leiden tot een grotere belasting van uw verkeersbudget of batterijduur.

De tweede optie is om de use cases te combineren in één kanaal. We noemen dit indirecte integratie met de software-updateservice, omdat de cloudconnectiviteitslaag daadwerkelijk is verbonden met het apparaat en de oplossing moet splitsen van het updateverkeer in de cloud.

Dit heeft het grote voordeel van een vereenvoudigde connectiviteitsarchitectuur. Het maakt het ook mogelijk gebruik te maken van algemene protocolstandaarden voor apparaatbeheer (bijv. LWM2M, OMA-DM, TR-069), die meestal alleen software-updates bevatten als een onderafdeling van hun standaarden. Bovendien maakt het het gebruik van propriëtaire protocollen mogelijk die door het apparaat (fabrikant) zelf worden gedefinieerd.

Aan het eind van de dag moet de IoT-oplossingsingenieur een keuze maken:scheiding van zorgen versus eenvoud. Met onze Bosch IoT-implementaties hebben we besloten om beide opties te ondersteunen, en we hebben klanten die beide gebruiken. Directe connectiviteit bleek veel gemakkelijker te onderhouden voor de IoT-oplossing, terwijl indirecte connectiviteit veel complexiteit toevoegt aan de algehele architectuur.

De meeste IoT-technici nemen problemen met software-updates echter zeer laat in het project op in hun ontwerpproces, omdat het in de meeste gevallen geen deel uitmaakt van de kerntaak van het bedrijf, en als ze er toch aan komen, willen ze geen wijzigingen meer aanbrengen aan hun architectuur. Als gevolg hiervan volgen de meeste oplossingen de indirecte benadering, met mogelijk de gevolgen na de livegang.

De tweede beslissing voor cloudgebaseerde software-updates in het IoT heeft betrekking op het protocol. Moet ik kiezen voor een standaard apparaatbeheerprotocol of een aangepast protocol ontwerpen? Veel IoT-oplossingen geven tegenwoordig de voorkeur aan MQTT met een aangepast protocol er bovenop. Bovendien bieden veel van de IoT-connectiviteitslagen op de markt ook een eigen protocol bovenop HTTP, MQTT of AMQP.

Persoonlijk ben ik van mening dat sommige normen waarde hebben en op zijn minst moeten worden overwogen. OMA-DM v2 ziet er veelbelovend uit en we hebben ook enige ervaring met LWM2M. Zoals altijd bieden standaarden een goed kader, maar ze komen meestal met een reeks beperkingen; vooral in de vroege stadia van een IoT-project kan dit veel complexiteit toevoegen. Een goede standaard die software-updates dekt, stelt de IoT-oplossing echter in staat om software-updates als functie te hebben zonder dat er ook maar één regel code hoeft te worden geschreven, als zowel het apparaat als de software-updateservice dit standaard ondersteunen.

Last but not least is er de kwestie van apparaatauthenticatie. Dit is natuurlijk een algemene vraag voor elke IoT-oplossing. Maar vooral voor het directe integratiepad moet de keuze worden gemaakt of hetzelfde authenticatiemechanisme kan worden gebruikt voor software-updates en het IoT-oplossingskanaal. Ik pleit meestal voor het gebruik van hetzelfde mechanisme. Dit is eigenlijk eenvoudig te implementeren met asymmetrische authenticatie (bijv. X.509-certificaat). Bosch IoT Rollouts ondersteunt dit voor zijn Direct Device Integration API en voor de meeste connectiviteitslagen die doorgaans in het IoT worden gebruikt. Als asymmetrisch geen optie is (wat vaak het geval is bij ingebedde apparaten met beperkingen), raad ik aan om voor een centrale (symmetrische) sleutelopslag te gaan die door de verschillende kanalen kan worden gebruikt.

Zoals hierboven aangegeven, zijn er keuzes die gemaakt moeten worden en vragen die beantwoord moeten worden. Helaas bevindt het IoT zich nog niet in een staat waarin we één architectuur hebben gevonden die in ieder geval bij de meeste scenario's past. Het goede nieuws is echter dat er opties zijn en dat ze werken.