Composants pour les mises à jour logicielles basées sur le cloud dans l'IoT

La mise à jour du logiciel (composants) sur des appareils de périphérie contraints ainsi que sur des contrôleurs et des passerelles plus puissants est une exigence courante dans la plupart des scénarios IoT.

Disposer de capacités de mise à jour logicielle assure un IoT sécurisé en donnant aux projets IoT une chance de se battre contre la boîte de Pandore, ils ont ouvert dès que leurs appareils ont été connectés . À partir de ce moment, les appareils sont à la pointe des menaces de sécurité informatique, auxquelles, historiquement, de nombreux développeurs de logiciels embarqués n'ont jamais eu à faire face. De nos jours, expédier, par exemple, un appareil alimenté par Linux et connecté au Web sans qu'aucune mise à jour de sécurité n'ait été appliquée au cours de sa durée de vie s'apparente à un suicide.

Un argument plus séduisant en faveur des mises à jour logicielles est qu'elles permettent un développement agile du matériel et des composants liés au matériel. Des concepts tels que le produit minimum viable peuvent être appliqués aux appareils, car toutes les fonctionnalités n'ont pas besoin d'être prêtes au moment de la fabrication. Les modifications du côté cloud de la solution IoT peuvent également être appliquées aux appareils lors de l'exécution.

Parfois, la mise à jour du logiciel est un modèle commercial à part entière, car les appareils sont beaucoup plus attrayants pour le client s'ils peuvent être mis à jour. En d'autres termes, les consommateurs savent qu'ils bénéficient non seulement d'un ensemble fixe de fonctionnalités, mais qu'ils peuvent également s'attendre à bénéficier des futures mises à jour des produits. En outre, de nouvelles sources de revenus peuvent découler de la monétisation potentielle d'extensions de fonctionnalités (par exemple, applications ) sans qu'il soit nécessaire de concevoir, fabriquer et expédier un nouvel appareil (révision).

Connectivité de l'appareil

Il existe différentes options pour connecter un appareil à un service cloud. D'un point de vue architectural, il faut décider si les appareils doivent se connecter directement au service de mise à jour logicielle ou indirectement via une couche de connectivité d'appareil (par exemple, Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub, etc.), qui elle-même pourrait également être un service de solution IoT. Je suis moi-même un fervent partisan de l'approche directe, et mon produit Bosch IoT Rollouts prend en charge les deux. Je vais vous expliquer pourquoi ci-dessous.

Commençons donc :la connectivité directe permettra aux solutions IoT d'avoir une séparation des préoccupations en ayant des canaux distincts pour les mises à jour logicielles en plus de leur propre canal que les solutions IoT utilisent pour les flux d'événements et les commandes des appareils.

Il s'agit d'une approche intéressante pour deux raisons :tout d'abord, cela facilite beaucoup la stabilité de l'API du canal de mise à jour logicielle si vous n'avez pas à vous soucier de toutes les exigences commerciales de l'autre canal . Nous ne devons pas oublier qu'il existe des scénarios dans l'IoT dans lesquels les appareils connectés peuvent rester pendant de longues périodes sans contact avec le backend. Dans certains cas, cela peut prendre des années, en particulier entre la fabrication et la connectivité initiale. Maintenir une couche de transport stable pendant ce laps de temps est facile, mais ce n'est certainement pas le cas pour la couche métier. Cela est particulièrement vrai dans l'IoT, où de nombreuses solutions cloud en sont encore aux premières phases de maturité.

Deuxièmement, le fait d'avoir un canal séparé vous permet également d'avoir une fonctionnalité de séparation des activités et de mise à jour sur l'appareil lui-même . Surtout dans une pile complexe (par exemple sur une passerelle IoT), voulez-vous vraiment risquer qu'une pile potentiellement cassée doive se mettre à jour pour résoudre le problème ? Et peut-on garantir qu'il pourra toujours le faire ? Imaginez un scénario dans lequel vous avez un runtime OSGi sur votre passerelle avec un ensemble qui provoque des exceptions de mémoire insuffisante et votre client de mise à jour logicielle s'exécute dans le même runtime. Il pourrait être très difficile de prédire le résultat.

Cependant, la séparation a un prix :deux canaux signifient généralement un effort de mise en œuvre plus important du côté de l'appareil, et dans certains scénarios, cela peut également augmenter la consommation de votre budget de trafic ou la durée de vie de la batterie.

La deuxième option consiste à combiner les cas d'utilisation dans un seul canal. Nous appelons cela indirect l'intégration avec le service de mise à jour logicielle, car la couche de connectivité cloud est en fait connectée à l'appareil et doit séparer la solution du trafic de mise à jour dans le cloud.

Cela présente le grand avantage d'une architecture de connectivité simplifiée. Il permet également de tirer parti des normes de protocole de gestion de périphériques à usage général (par exemple, LWM2M, OMA-DM, TR-069), qui incluent généralement les mises à jour logicielles uniquement en tant que sous-section de leurs normes. De plus, il permet l'utilisation de protocoles propriétaires définis par l'appareil (fabricant) lui-même.

En fin de compte, l'ingénieur solution IoT a un choix à faire :séparation des préoccupations vs simplicité. Avec nos déploiements IoT Bosch, nous avons décidé de prendre en charge les deux options, et nous avons des clients qui utilisent les deux. La connectivité directe s'est avérée beaucoup plus facile à maintenir pour la solution IoT, tandis que la connectivité indirecte ajoute beaucoup de complexité à l'architecture globale.

Cependant, la plupart des ingénieurs IoT incluent des problèmes de mise à jour logicielle dans leur processus de conception très tard dans le projet, car dans la plupart des cas, cela ne fait pas partie de la fonction principale de l'entreprise, et lorsqu'ils y viennent, ils ne veulent plus apporter de modifications. à leur architecture. En conséquence, la plupart des solutions adoptent l'approche indirecte, en subissant potentiellement les conséquences après la mise en service.

La deuxième décision pour les mises à jour logicielles basées sur le cloud dans l'IoT concerne le protocole. Dois-je utiliser un protocole de gestion des appareils standard ou en concevoir un personnalisé ? De nos jours, de nombreuses solutions IoT privilégient MQTT avec un protocole personnalisé en plus. En outre, de nombreuses couches de connectivité IoT sur le marché offrent également un protocole propriétaire en plus de HTTP, MQTT ou AMQP.

Personnellement, je crois que certaines des normes ont de la valeur et devraient au moins être prises en compte. OMA-DM v2 semble prometteur et nous avons également une certaine expérience avec LWM2M. Comme toujours, les normes offrent un bon cadre, mais elles s'accompagnent généralement d'un ensemble de contraintes; en particulier dans les premières étapes d'un projet IoT, cela peut ajouter beaucoup de complexité. Cependant, une bonne norme couvrant les mises à jour logicielles permettra à la solution IoT d'avoir des mises à jour logicielles en tant que fonction sans avoir besoin d'écrire ne serait-ce qu'une seule ligne de code si l'appareil et le service de mise à jour logicielle le prennent en charge immédiatement.

Enfin, il y a la question de l'authentification des appareils. Il s'agit bien sûr d'une question générale pour chaque solution IoT. Mais surtout pour le chemin d'intégration directe, il faut choisir si le même mécanisme d'authentification peut être utilisé pour les mises à jour logicielles et le canal de la solution IoT. Je plaide généralement pour l'utilisation du même mécanisme. C'est en fait facile à mettre en œuvre avec une authentification asymétrique (par exemple, un certificat X.509). Bosch IoT Rollouts prend en charge cela pour son API Direct Device Integration ainsi que la plupart des couches de connectivité généralement utilisées dans l'IoT. Si l'asymétrie n'est pas une option (ce qui est souvent le cas avec les périphériques embarqués contraints), je recommanderais d'opter pour un magasin de clés central (symétrique) qui peut être utilisé par les différents canaux.

Comme indiqué ci-dessus, il y a des choix à faire et des questions auxquelles il faut répondre. Malheureusement, l'IoT n'est pas encore dans un état où nous avons trouvé une architecture qui correspond au moins à la majorité des scénarios. La bonne nouvelle, cependant, est qu'il existe des options et qu'elles fonctionnent.