Mises à jour en direct avec AWS et FreeRTOS

La mise à jour du micrologiciel sur le terrain a toujours été un élément essentiel, même des tout premiers systèmes embarqués. L’accès à des outils d’interfaçage matériel comme un programmeur JTAG ou SWD fournit un accès physique aux ports de programmation du système embarqué. D’autres méthodes d’accès pour les mises à jour du micrologiciel incluent des interfaces telles que USB, CAN automobile, un port série, etc. La connectivité des ports sans fil a pris de l’importance à mesure que de plus en plus d’appareils intégrés font partie de l’IoT. Dans l’article d’aujourd’hui, nous explorerons de telles communications sans fil et sans fil (OTA) à l’aide d’Amazon Web Services (AWS) et de FreeRTOS.

Présentation de l’OTA à l’aide d’AWS

Les mises à jour OTA peuvent être un peu intimidantes la première fois qu’un développeur les rencontre. Bien que le processus soit quelque peu complexe, il peut être décomposé en éléments assez simples.

Groupe Beningo Embarqué

Décomposer le processus OTA en éléments simples.

La mise à jour du firmware comporte trois éléments principaux :

1. Un OEM qui publie une nouvelle mise à jour du firmware.
2. L’AWS qui stocke l’image du firmware et facilite la mise à jour.
3. Appareils déployés qui reçoivent la mise à jour du micrologiciel.

L’AWS joue un rôle assez important dans l’ensemble du processus. La nouvelle image du micrologiciel est téléchargée dans un compartiment Simple Storage Service (S3) qui est utilisé pour stocker les images du micrologiciel. Ensuite, l’OEM utilise IoT Core pour planifier une tâche qui informera les appareils déployés qu’une mise à jour du micrologiciel est disponible. Enfin, les appareils déployés téléchargent la nouvelle image, la valident, puis mettent à jour leur code d’application. À ce stade, les appareils sont mis à jour et exécutent le nouveau code d’application jusqu’à ce que le processus redémarre et qu’une nouvelle mise à jour soit disponible.

Prise en charge OTA dans les microcontrôleurs

L’aperçu rend honnêtement les mises à jour OTA simples et c’est parce que tout le gros du travail est déjà fait pour les développeurs. Si une équipe décidait qu’elle voulait créer sa propre solution à partir de zéro, elle découvrirait qu’elle aurait à faire un gros effort de développement. Les équipes ne veulent vraiment pas créer leurs propres solutions OTA, mais plutôt tirer parti des solutions existantes afin de pouvoir se concentrer sur leurs propres fonctionnalités et différenciateurs. Pour les équipes qui envisagent d’utiliser FreeRTOS, elles peuvent tirer parti des bibliothèques FreeRTOS d’Amazon et de l’exemple OTA pour être opérationnelles avec une solution OTA extrêmement rapidement.

Une bonne chose à propos de la solution AWS OTA est qu’elle est prise en charge par un certain nombre de fournisseurs de microcontrôleurs. Par exemple, si vous deviez visiter le catalogue d’appareils des partenaires AWS, vous constateriez qu’il existe près de trois douzaines de partenaires fournisseurs de silicium avec près de 60 cartes de développement différentes prises en charge ! Maintenant, tous ne prennent pas en charge la solution OTA, mais bon nombre le font. Cela donne aux développeurs une assez large gamme de périphériques parmi lesquels choisir et rien n’empêche vraiment un développeur de porter les exemples sur un processeur qui n’est pas pris en charge.

Fonctionnalités et capacités OTA

Au cours des dernières semaines, j’ai spécifiquement essayé le code de démonstration AWS OTA avec FreeRTOS sur un Infineon/Cypress PSoC 64 Standard Secure – AWS Wi-Fi BT Pioneer Kit pour un cours que je vais enseigner. Je mentionne ce kit parce que je le trouve particulièrement intéressant du point de vue de la sécurité dans la mesure où ils ne prennent pas seulement en charge les OTA ou les chargeurs de démarrage «traditionnels», mais se sont donné beaucoup de mal pour garantir que non seulement la mise à jour du micrologiciel peut être sécurisée, mais que le démarrage sur le microcontrôleur établit une racine de confiance sécurisée.

Cela m’amène au point que toutes les solutions OTA ou bootloader ne sont pas créées égales et, dans de nombreuses circonstances, il y a de la place pour la personnalisation et la configuration. Par exemple, la démo PSoC 64 OTA par défaut est configurée pour fournir une sortie de fichier binaire standard pour le micrologiciel qui est poussé vers le compartiment S3. Cependant, dans la chaîne d’outils Cypress, il existe un outil SDK sécurisé qui inclut plusieurs stratégies pouvant être utilisées pour chiffrer l’image du micrologiciel. Les appareils à bord d’un chargeur de démarrage sécurisé décryptent et authentifient ensuite la nouvelle image du micrologiciel avant de l’écrire dans la mémoire flash.

Lorsque vous examinez des solutions OTA potentielles fonctionnant avec des microcontrôleurs, il convient de garder à l’esprit plusieurs caractéristiques, telles que :

• Le microcontrôleur établit une racine de confiance
• Le microcontrôleur comprend un chargeur de démarrage sécurisé (qui vérifie l’intégrité, authentifie et décrypte l’image)
• Les images du firmware peuvent être cryptées
• Facilité de génération d’une tâche de mise à jour du firmware
• Facilité de gestion des flottes d’appareils déployés

Conclusion

Les mises à jour OTA deviennent rapidement une exigence pour presque tous les appareils IoT. Ces solutions aident les développeurs à mettre à jour leur micrologiciel sur le terrain avec un effort minimal, ce qui leur permet de se concentrer davantage sur le produit que sur les éléments de conception de périphériques courants tels que le chargeur de démarrage et l’OTA. Lors de l’expérimentation de ma carte de développement Cypress PSoC 64 et de la démo AWS OTA, j’ai découvert que j’étais capable de configurer AWS et ma carte de développement pour effectuer une mise à jour du micrologiciel en environ une heure la première fois que je l’ai fait. Ce n’est vraiment pas si mal étant donné que démarrer une telle solution à partir de zéro prendrait normalement plusieurs mois.