IoT : les trois architectures de mise à jour OTA à considérer

Les mises à jour Edge vers le cloud

Avec une architecture Edge vers le cloud, c’est l’objet connecté à internet qui reçoit directement une mise à jour logicielle ou firmware depuis le cloud. Le cloud joue le rôle de répartiteur vers les appareils dotés d’un microcontrôleur dédié à cette opération.

Avantages : L’architecture OTA « edge-to-cloud » permet aux appareils de recevoir des mises à jour séparément. Cela permet d’éviter que les mises à jour défectueuses n’affectent l’ensemble du parc IoT. Cette méthode est recommandée dans les environnements critiques comme les hôpitaux. L’équipe IT peut ainsi programmer des mises à jour pendant les temps d’arrêt des équipements. Cela permet de limiter les baisses de performance ou les erreurs de collecte de données en production lors de l’opération.

Inconvénients : Ne pas mettre à jour tous les équipements en même temps fait apparaître de nouveaux risques. Certains d’entre eux peuvent être exposés aux « cyber-mécréants » ou bien subir des plantages logiciels ou matériels, parce qu’ils ont n’ont pas reçu le nouveau patch à temps. Le SI doit également avoir une bonne compréhension des appareils qui seront affectés lors de chaque mise à jour afin de pouvoir informer les responsables d’activité en amont. Traiter individuellement chaque objet peut mener à des blocages à moins que celui puisse se rétablir automatiquement en cas d’interruption ou d’échec de la mise à jour.

Les mises à jour Gateway vers le cloud

L’architecture « gateway-to-cloud » consiste à mettre à jour uniquement la passerelle IoT qui gère une flotte d’objets connectés. La gateway, connectée via le réseau au cloud, reçoit les nouvelles versions logicielles et firmwares depuis le nuage.

Avantages : De la sorte, les objets connectés ne reçoivent pas directement les modifications via la norme OTA. En revanche, les transmissions de données sont sécurisées et effectives parce que la passerelle est maintenue à jour. De même, une gateway IoT peut faire lien avec des appareils qui ne supportent pas des protocoles de communication capables de communiquer « directement » avec le cloud. D’autres équipements n’ont pas les capacités de calcul nécessaire pour gérer les mises à jour ou ne sont tout simplement pas conçus pour supporter des logiciels.

Inconvénients : Mettre à jour uniquement la passerelle IoT introduit un SPOC, un point de défaillance unique pour toute la flotte de dispositifs. Si la mise à jour de la passerelle échoue ou est interrompue, tous les processus traités sont menacés. Les transmissions de données deviennent caduques. Si la passerelle ne dispose pas d’un système de récupération automatique après un tel échec, elle peut tomber en panne totale. Cela peut couper l’ensemble du parc et réduire la productivité. La situation pourrait s’aggraver si plusieurs passerelles ont le même problème et qu’il n’est pas traité à temps.

Selon la passerelle mise à jour et le rôle des objets connectés, il se peut qu’il n’y ait pas de moment propice pour effectuer l’opération. Il faut donc veiller à trouver le moment pour la planifier. Cela demande là encore d’avertir les responsables métiers pour éviter les coupures de service inopportunes.

Les mises à jour Edge vers la gateway vers le cloud

Avec cette troisième architecture, la gateway IoT joue le rôle de répartiteur de paquets de mise à jour vers les objets connectés compris dans sa flotte.

Avantages : Cette architecture met toujours à jour les appareils individuellement. Cela diminue les risques de sécurité et maintient des performances élevées. Elle réduit également le risque pour l’ensemble de la flotte en cas d’échec ou d’interruption de la mise à jour. Le reste de la flotte en est isolé. Les appareils n’ont pas besoin de disposer d’un microcontrôleur pour gérer la mise à jour ni d’être connectés à l’Internet. Ils obtiennent les mises à jour par le biais d’une connexion directe à la passerelle par câble, par Bluetooth ou LPWAN (Low-Power WAN, ou réseau bas débit sans fil) – par exemple.

Inconvénients : L’architecture OTA « Edge to gateway to cloud » est utile dans les cas où les connexions à Internet sont mauvaises ou les restrictions budgétaires empêchent l’utilisation d’équipements sophistiqués. Toutefois, elle n’est pas sans défaut. Elle crée un point de défaillance unique si la passerelle ne reçoit pas correctement la mise à jour, qui ne sera alors pas capable d’effectuer le relais vers les dispositifs IoT. Des défaillances de connexions entre la passerelle et les objets pourraient empêcher ou interrompre le processus. Les dispositifs peuvent ne pas être en mesure d’indiquer quand une mise à jour a échoué. La passerelle peut ne pas être configurée pour identifier les échecs ou les bridages après mise à jour.

Bref, pour chacune des méthodes exposées dans cet article il faut évaluer leurs caractéristiques et prévoir la bonne réponse aux risques évoqués. La récupération automatique, vérifier la compatibilité des nouvelles versions avec les équipements, le déploiement d’outils de monitoring, de protocoles de chiffrement sont quelques-unes des mesures à prendre pour faciliter l’utilisation de la norme OTA.