blog

adesso Blog

Les logiciels sont partout. Les appareils embarqués, par exemple, contiennent beaucoup de logiciels. Malheureusement, les erreurs ne sont généralement découvertes qu’une fois que le logiciel est déjà en service. Pour éviter cela, nous vous recommandons d'adopter le concept FOTA First (Firmware Over-the-Air).

Dans cet article de blog, je vous présente l'un des frameworks les plus répandus pour les mises à jour de firmware sous Linux : SWUpdate. Ce cadre est maintenu par Stefano Babic et est accessible au public sur GitHub. Il est utilisé dans le cadre du projet Yocto et permet à votre équipe de développer facilement une stratégie de mise à jour de firmware pour votre produit.

Si vous voulez savoir pourquoi le projet Yocto est une solution forte, lisez l'article de blog de mon collègue. Vous le trouverez ici (en anglais).

Vous pourriez également être intéressé par notre page sur les solutions logicielles embarquées d'adesso.

En savoir plus (en anglais)

Dans les standards de bonne pratique, cette fonction est l'une des premières (si ce n'est la première) que votre produit devrait avoir, d'où le terme FOTA-first. De cette manière, votre équipe a la possibilité de mettre à jour le dispositif avec de nouvelles versions pendant le développement. Votre service d'assurance qualité reste informé des derniers développements ou des versions publiées qu'il doit vérifier et, accessoirement, vous avez la possibilité de tester le processus de mise à jour lui-même à plusieurs reprises, dès les premières phases et tout au long du développement du produit.

Dans la pratique, la mise à jour du logiciel de l'appareil signifie qu'une nouvelle version du logiciel est installée sur l'appareil. Dans le passé, cette tâche était effectuée par des techniciens de service. J'ai moi-même effectué plusieurs mises à jour de logiciels sur de grandes installations de production en remplaçant manuellement l’intégralité du disque dur contenant l'ancien logiciel par la nouvelle version. Dans les cas plus petits, par exemple pour les distributeurs automatiques, il était courant de brancher la clé USB contenant le nouveau logiciel et de redémarrer l’automate. Une procédure prédéfinie pendant le processus de démarrage vérifiait si de nouvelles mises à jour du logiciel étaient disponibles sur la clé USB insérée. Le cas échéant, quand la mémoire permanente installée dans l'appareil reste inchangée, différentes stratégies de mise à jour sont appliquées. Nous nous concentrons ici sur la stratégie de double copie, que nous recommandons si l'appareil dispose de suffisamment de mémoire.

Avec l'avènement de l'IdO, cette procédure a reçu le nom de mise à jour « Over-The-Air », ce qui signifie que les informations sur la nouvelle version du logiciel et le nouveau progiciel lui-même sont partagés avec l'appareil via Internet (c'est-à-dire sans avoir besoin d'aucune intervention sur place). Bien que le déclencheur et le mode de transmission de l'information aient quelque peu changé, la base des stratégies disponibles restent identiques. Examinons ensemble l'une d'entre elles.

La stratégie de la double copie

Dans cette configuration, la mémoire existante est suffisante pour avoir deux copies (presque) identiques, ce qui vous permet d'avoir toujours une copie fonctionnelle du logiciel sur votre appareil. En cas d'événement indésirable pendant la mise à jour (par exemple une panne de courant), vous pouvez toujours revenir à la version originale (c'est-à-dire à la partition à partir de laquelle vous avez lancé la mise à jour).

Pour offrir cette garantie à vos utilisateurs, la copie du logiciel de mise à jour devrait

  • toujours être livrée avec toutes les versions du logiciel
  • toujours pouvoir fonctionner
  • également disposer d’une procédure permettant de savoir quelle partition est en cours d'exécution.

Ces informations peuvent être fournies par le chargeur de démarrage, qui est chargé de lancer le bon logiciel et éventuellement de récupérer une situation dans laquelle la procédure de mise à jour du logiciel aurait échoué.

Remarque à ce sujet : Pour minimiser drastiquement le potentiel d’endommagement du système de fichiers, nous recommandons généralement d'utiliser un système de fichiers en lecture seule sur la copie de travail du logiciel. C'est la principale raison pour laquelle la figure 1 illustre une partition de données en plus des deux partitions d'application et du chargeur de démarrage. C'est la seule partition sur laquelle les applications peuvent écrire et c'est le bon endroit pour stocker la configuration personnalisée de l'appareil. Cela a pour effet secondaire de vous permettre de configurer le firmware de manière à ce que vous puissiez réinitialiser votre appareil à son état de fabrication (c'est-à-dire aux paramètres d'usine) en supprimant simplement cette partition de données.

SWUpdate et le Yocto Project

SWUpdate fournit une méthode fiable pour mettre à jour le logiciel d'un système embarqué. Le framework prend automatiquement en charge la stratégie de double copie. Le dispositif qui en résulte présente en revanche une caractéristique importante, à savoir : la copie non actuelle peut toujours être mise à jour par le logiciel. Le responsable de la maintenance du framework a publié une méta-couche spéciale compatible avec le projet Yocto, qui rend encore plus facile l'intégration des outils nécessaires dans votre image de firmware : meta-swupdate. Afin d'aider davantage de développeurs, en particulier ceux qui doivent intégrer ces outils dans les solutions de firmware des appareils, une autre méta-couche a été publiée, les meta-swupdate-boards. Cette dernière méta-couche contient la configuration nécessaire à la stratégie de double copie pour la machine raspberripi3, que j'ai utilisée pour la validation et l'écriture de cet article. Si vous souhaitez en savoir plus, cliquez ici ou prenez contact avec moi et mon équipe chez adesso Suisse SA.

Avec tous ces méta-niveaux mis à disposition par les contributeurs du framework, créer une démo pour une mise à jour du firmware est désormais très simple. En pratique, en copiant en toute sécurité l'image mise à jour dans la partition inscriptible (c'est-à-dire dans les dossiers /tmp ou /data), vous pouvez utiliser le déclencheur fourni par votre fournisseur de cloud (par exemple la notification de changement de jumeau d'appareil dans Azure IoT Hub) et simuler le téléchargement du nouveau firmware dans un dossier spécifique (cela n'était pas pertinent pour cette démonstration). Une fois la nouvelle version du firmware enregistrée quelque part sur le périphérique, vous pouvez utiliser le client swupdate pour demander la mise à jour de Daemon, et rien d'autre. SWUpdate conserve la copie réelle du micrologiciel dans la partition correcte et le redémarrage dans la bonne partition de copie mise à jour.

En conclusion

La création d'une image de firmware n'a jamais été aussi simple. Afin d'éviter les difficultés liées à la mise en œuvre d'une procédure de mise à jour logicielle personnalisée, de faciliter la vie des développeurs et de gagner du temps pour se concentrer sur la logique commerciale de l'application, il est indispensable de lancer le prochain développement de produit avec la mise en œuvre de la stratégie de mise à jour logicielle choisie. Tirer parti de toutes ces implémentations de meilleures pratiques soutenues par la communauté aidera votre équipe à commercialiser des produits plus sûrs et plus faciles à maintenir dans les délais. Si vous souhaitez profiter d’une démonstration en direct ou d’un workshop, n'hésitez pas à nous contacter.


Photo Stefano Fiorentino

Auteur Stefano Fiorentino

Sauvegarder cette page. Supprimer cette page.