Traçage de logiciels dans les appareils déployés sur le terrain

Le traçage logiciel est un outil important dans la boîte à outils de chaque développeur embarqué, en particulier lorsqu'il est combiné à une visualisation avancée. La plupart des systèmes embarqués ont de nombreux modèles cycliques, où la même séquence se répète encore et encore. Lors du débogage, vous voulez souvent trouver les anomalies, c'est-à-dire les écarts par rapport au comportement cyclique normal où quelque chose d'inhabituel s'est produit.

Cependant, le traçage logiciel en soi n'est qu'une forme de collecte de données. La recherche d'un problème dans une mine de données textuelles ou numériques s'apparente à la recherche d'une aiguille dans une botte de foin, mais avec une bonne visualisation, la recherche se transforme en un problème de reconnaissance visuelle des formes, ce pour quoi le cerveau humain est particulièrement bien équipé. . Graphiques interactifs montrant les temps d'exécution, les temps de réponse, les changements de tâches, le transfert de messages entre les tâches : tout cela permet à un développeur de repérer rapidement les anomalies dans l'exécution de son micrologiciel, où approfondir.

Les outils de diagnostic visuel des traces existent depuis au moins une décennie et se sont avérés utiles pour le développement et le débogage en laboratoire. Avec de plus en plus de développeurs de logiciels embarqués ajoutant une connectivité cloud sécurisée pour l'« Internet des objets », il est tout à fait naturel d'envisager l'utilisation du traçage dans les appareils déployés sur le terrain, afin de capturer les problèmes du monde réel qui avaient été manqués lors des tests. Après tout, le traçage logiciel ne nécessite aucun matériel supplémentaire et un appareil IoT connecté est évidemment capable de télécharger des données de traçage de diagnostic, de la même manière que les données d'application classiques. De cette façon, les développeurs peuvent rapidement prendre conscience de tous les problèmes logiciels restants qui causent des problèmes lors du fonctionnement réel et également obtenir des diagnostics détaillés pour comprendre la cause.

Dans ce scénario, le traçage logiciel est comparable à un « enregistreur de vol » virtuel, comme ceux utilisés dans les avions de ligne en cas d'accident. C'est une partie intégrée du produit qui enregistre toujours, fournissant des informations vitales en cas de problème. Mais contrairement aux vrais boîtiers d'enregistreurs de vol, il s'agit d'une solution logicielle et destinée aux problèmes logiciels.

Une solution pour ce type de surveillance des appareils IoT est DevAlert de Percepio (figure 1), qui se compose de trois parties :un moniteur de micrologiciel, une petite bibliothèque que vous ajoutez à votre micrologiciel pour permettre le traçage et le téléchargement des alertes ; notre outil Tracealyzer pour le diagnostic visuel des traces ; et un service cloud, responsable de la catégorisation et du stockage des alertes, de la notification des développeurs, du filtrage des alertes en double, etc.

Figure 1. Percepio DevAlert fournit aux développeurs IoT un retour instantané sur les erreurs de leurs appareils connectés au cloud, permettant une amélioration continue et rapide du logiciel de l'appareil.
(Cliquez sur l'image pour l'agrandir)

La version initiale s'exécute sur AWS et est destinée aux applications RTOS utilisant AWS IoT core, mais la solution peut être adaptée pour d'autres plateformes cloud.

Traçage des logiciels et connectivité cloud
Le traçage dans le laboratoire de développement et le traçage des appareils déployés sont deux choses différentes. Si vous utilisez aujourd'hui le diagnostic de trace visuelle en laboratoire et que vous cherchez à l'étendre sur le terrain, vous devez réfléchir à quelques points.

Par rapport à une connexion physique directe comme USB ou Ethernet, une connexion cloud offre à la fois une bande passante limitée et des temps de réponse beaucoup plus longs. Le téléchargement, disons, 5 Ko de données peut nécessiter des dizaines ou des centaines de millisecondes sur une interface sans fil. Cependant, dans cette approche, les traces ne sont pas transmises en continu, mais uniquement lorsqu'une alerte est générée et seulement une petite trace des événements les plus récents. Les alertes ne sont destinées qu'à des choses inhabituelles mais importantes, par exemple si une erreur a été détectée dans le code de l'application, comme un échec du contrôle de cohérence, une panne matérielle ou une réinitialisation du chien de garde.

Tout appareil connecté à Internet doit être sécurisé. Il est donc important de ne pas introduire de nouveaux vecteurs d'attaque. Nous résolvons ce problème dans DevAlert en nous appuyant sur la connectivité cloud existante plutôt que d'introduire une nouvelle connexion. Cela tire parti de la sécurité d'AWS et d'autres principaux fournisseurs IoT/cloud, qui offrent des SDK vérifiés pour la connectivité cloud qui sont sécurisés conformément aux meilleures pratiques, telles que l'authentification des appareils à l'aide de certificats X.509 et la communication cryptée à l'aide de TLS. Cela rendrait alors les téléchargements DevAlert aussi sécurisés que les données d'application IoT classiques, et pour plus de sécurité, il n'a besoin que d'une communication unidirectionnelle :il n'écoute jamais les messages entrants.

Dans cette approche, les alertes sont téléchargées sur le même compte cloud que celui normalement utilisé par l'appareil, et avec le même niveau de sécurité. Une fois dans le cloud, une petite partie des données est fournie au service cloud. Cela n'inclut pas les données de trace réelles, qui peuvent être considérées comme des informations sensibles et restent donc dans le compte cloud de l'appareil. Les figures 2a et 2b montrent plus en détail le flux de données et les barrières de sécurité.

Figure 2a. Le flux de données commence dans le logiciel de l'appareil, où les développeurs ajoutent des alertes au code source. Chaque alerte téléchargée sur le compte cloud de l'appareil comprend une courte trace avec les événements les plus récents précédant l'alerte. Enfin, une signature de métadonnées est transmise au service cloud DevAlert. (Cliquez sur l'image pour l'agrandir)

Figure 2b. Le service cloud compare les alertes entrantes aux alertes précédentes de l'ensemble du parc d'appareils du client et informe les développeurs de tout nouveau problème. Les alertes en double sont comptées et stockées, mais aucune notification n'est envoyée. De cette façon, les boîtes de réception des développeurs ne sont pas inondées si la même alerte est déclenchée sur plusieurs appareils. (Cliquez sur l'image pour l'agrandir)

Les coûts opérationnels pour recevoir des alertes sur un compte cloud sont généralement faibles, bien que cela dépende naturellement du volume. Pour commencer, tant qu'aucun problème n'est détecté, aucune alerte n'est envoyée. En général, les fournisseurs de cloud facturent également très peu pour l'envoi et le stockage de messages d'alerte occasionnels. La plupart des applications IoT génèrent beaucoup plus de données, ce qui se reflète dans la tarification des services IoT/cloud. Par exemple, l'envoi d'un million de messages MQTT à AWS IoT core coûte 1 USD.

La plupart du traitement des alertes est effectué dans le service cloud, un service entièrement géré hébergé par Percepio. Seul le traitement initial est effectué dans le compte cloud du développeur de l'appareil, ce qui réduit les coûts du cloud et simplifie l'intégration.

L'envoi de mises à jour en direct pour corriger les erreurs signalées peut potentiellement coûter un peu plus cher, car vous devez transférer beaucoup plus de données et vers tous les appareils. AWS fournit un exemple de tarification où le coût de mise à jour d'une flotte de 600 000 appareils est de 1 275 USD. Cependant, ce n'est pas très cher par rapport au coût de laisser un bogue non corrigé - expérience client endommagée, notes d'évaluation de produit inférieures, ventes inférieures, voire accidents et poursuites judiciaires.

DevOps pour le développement embarqué
Permettre à vos appareils IoT de « téléphoner à la maison » en cas de problèmes logiciels présente un avantage important. La prise de conscience directe des erreurs et les diagnostics détaillés créent une boucle de rétroaction entre les développeurs et le code déployé, permettant aux développeurs de corriger les bogues plus rapidement et de sortir le firmware mis à jour plus rapidement - voir Figure 3. Cette soi-disant philosophie DevOps a longtemps été la norme dans le développement de mobiles et les applications cloud, et avec l'introduction de plates-formes IoT sécurisées basées sur le cloud, il est devenu possible pour le développement intégré de fonctionner de cette manière également.

Figure 3. Le tableau de bord DevAlert de Tracealyzer répertorie les alertes et les traces signalées les plus récentes.
(Cliquez sur l'image pour l'agrandir)

D'un point de vue commercial, cette surveillance de style DevOps se traduit par moins de clients insatisfaits, car moins d'utilisateurs finaux seront affectés par des bogues dans le code de production. La plupart des logiciels embarqués contiennent des bogues manqués à la sortie, malgré tous les efforts de vérification, mais ils ne s'affichent généralement pas directement pour tout le monde. Il y a souvent un certain temps pour résoudre le problème avant que de nombreux clients ne soient affectés, si vous le savez tôt. Idéalement, les développeurs doivent être avertis dans les secondes qui suivent la toute première alerte et les diagnostics de trace fournis permettent une analyse et une correction rapides. Les développeurs peuvent ensuite envoyer une mise à jour automatique en direct pour résoudre le problème. La détection instantanée et les diagnostics de trace peuvent réduire considérablement le délai de réparation et minimiser le nombre de clients concernés.

L'amélioration de la fiabilité des appareils réduit les risques de responsabilité et réduit également les coûts de support client, de retours et de débogage. Les diagnostics fournis permettent aux développeurs de reproduire beaucoup plus facilement les problèmes des clients, car ils obtiennent des informations directement à partir de l'appareil et n'ont pas à se fier à l'utilisateur pour décrire les circonstances. Sans retour automatique, vous comptez sur vos utilisateurs finaux pour signaler tout problème et fournir des informations suffisamment détaillées. Un rapport d'erreur vague comme "le système cesse de répondre" n'est pas très utile, et cela peut prendre des semaines pour trouver une cause probable. Et même dans ce cas, ce n'est que votre meilleure estimation - vous ne pouvez pas vraiment savoir si vous avez résolu le bon problème.

Pas seulement des bogues
Une chose à noter est que les alertes ne doivent pas nécessairement concerner les bogues manqués et les erreurs qui en résultent. Étant donné que les développeurs sont libres de décider où et pourquoi les alertes doivent être générées, ils peuvent également les utiliser pour surveiller les mesures de performance clés de l'application et voir la raison des problèmes de performances occasionnels.

La surveillance de l'interface utilisateur peut également révéler des informations intéressantes. Disons que vous avez une situation où l'utilisateur ouvre un menu sur un écran tactile, par ex. dans les systèmes d'infodivertissement d'une voiture, puis hésite sur la marche à suivre. Pour détecter de tels problèmes, le développeur d'applications peut démarrer une minuterie après chaque événement d'entrée et générer une alerte si aucune entrée n'est reçue dans les 5 secondes environ. Si de nombreuses alertes sont ensuite reçues concernant la même partie de l'interface utilisateur, cela peut être un retour important qui peut aider votre organisation à créer de meilleurs produits.

Dans l'ensemble, tirer parti du traçage des logiciels et des alertes basées sur le cloud dans les appareils déployés présente des avantages majeurs et n'est pas compliqué. Cependant, pour adopter pleinement un flux de travail de style DevOps, il faut une capacité de mises à jour en direct et une organisation de développement réactive qui comprend les limites des tests logiciels et l'importance de l'amélioration continue, même après la publication.