Partager via

Suggestions de conception d’applications principales de haut niveau

  • Article

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

Pour créer une application principale (HL) de haut niveau sur des bases solides, vous devez utiliser les meilleures pratiques fondamentales. Voici les éléments les plus pertinents :

Les applications principales (HL) de haut niveau s’exécutent en conteneur sur le système d’exploitation Azure Sphere. Pendant les révisions de code et de conception des solutions clients, nous avons détecté plusieurs problèmes typiques avec les applications HL-core. Cette rubrique décrit les suggestions d’améliorations apportées à la conception pour résoudre ces problèmes.

Notions de base générales

Pour créer une application HL-core sur des bases solides, vous devez utiliser les meilleures pratiques fondamentales. Voici les éléments les plus pertinents :

  • Initialisation et arrêt : veillez toujours à gérer le signal SIGTERM du système d’exploitation Azure Sphere, puis à initialiser et détruire correctement tous les gestionnaires (tels que ceux pour les périphériques) lors du blocage ou de l’erreur. Pour plus d’informations, consultez la documentation d’initialisation et de terminaison de GNU sur les signaux d’arrêt.
  • Utilisez toujours des codes de sortie : assurez-vous que l’application HL-core fournit toujours un code de retour significatif lors de la sortie ou du blocage (par exemple, à l’aide du gestionnaire SIGTERM) est essentiel pour diagnostiquer correctement le comportement de l’appareil, en particulier à partir de la télémétrie de vidage sur incident de l’appareil. Pour plus d’informations, consultez Codes de sortie et Collecter et interpréter les données d’erreur.
  • Assurez-vous que les cas d’échec entraînent toujours une sortie ou un blocage de l’application plutôt que dans un état d’interblocage : une logique de récupération d’échec élaborée peut être contre-productive, car elle peut introduire des bogues ou des comportements entraînant un blocage ou un état difficile à diagnostiquer. Une application Azure Sphere bien conçue doit toujours préférer le blocage ou la sortie (avec un code de sortie différent de zéro) à une situation potentielle d’interblocage, car cela entraîne les deux :
    • Télémétrie d’erreur, activation des diagnostics pour ce problème
    • Une chance de récupération immédiate dans un état de travail, car le système d’exploitation Azure Sphere redémarre l’application
  • Gestion et journalisation des erreurs : la gestion et la journalisation précises des erreurs sont au cœur du développement d’applications de qualité. Les implémentations rapides de fonctionnalités peuvent rester enterrées dans des couches de code, puis intégrées à mesure que l’application développe jusqu’à une mise à l’échelle complète. Pour plus d’informations sur les meilleures pratiques, consultez Gestion des erreurs et journalisation.
  • Utilisez un minuteur système comme agent de surveillance : l’une des meilleures pratiques les plus cruciales consiste à implémenter un rappel « minuteur de surveillance » (tout comme le matériel disponible dans les mcu nues) qui suit les états d’application critiques, détectant le blocage et agissant en conséquence (par exemple, quitter et envoyer des données de télémétrie). Pour plus d’informations, consultez Utiliser un minuteur système comme agent de surveillance.
  • Ne déployez jamais d’applications de production qui ont été créées ciblant un ensemble d’outils de version bêta : l’utilisation d’ensembles d’outils de version bêta n’est pas recommandée, car il ne peut pas être garanti que le sous-ensemble bêta ne change pas dans les versions ultérieures du système d’exploitation. Les ensembles d’outils bêta sont publiés uniquement pour tester de nouvelles fonctionnalités à l’avance d’une version officielle du SDK.

Gestion de l’accès concurrentiel

  • Utilisez EventLoop dans la mesure du possible : les threads et les objets de synchronisation (autrement dit, mutexes, sémaphores, et ainsi de suite) sont utilisés pour accomplir des tâches presque simultanées, mais dans les systèmes incorporés, ils sont coûteux en termes d’utilisation des ressources système. Par conséquent, pour améliorer les performances, envisagez d’utiliser des epolls au lieu de threads, pour ces tâches qui ne sont pas strictement critiques et qui ne sont pas sensibles au blocage mutuel. Consultez Applibs eventloop.h pour plus d’informations sur la façon de surveiller et de distribuer des événements avec EventLoop, y compris des exemples connexes.
  • Recherchez une efficacité sur les tâches simultanées : il est important de s’assurer que les opérations de blocage et les délais d’attente sont conservés au minimum dans les rappels epoll, sinon tous les autres rappels d’epoll seront affectés.
  • Quand utiliser des threads (pthread) : pour des scénarios spécifiques, comme lorsque les appels bloquants sont inévitables, l’utilisation de threads peut être bénéfique, bien que ces scénarios aient généralement une durée de vie limitée et doivent être limités à des tâches spécifiques. Par exemple, étant donné que le système d’exploitation Azure Sphere (exécutant Linux) n’expose pas les questions irQs aux applications HL-core (cela est disponible uniquement pour les applications RT-core), l’utilisation d’une combinaison de tâches époll et pthread peut être optimale dans la gestion, par exemple, d’une communication série en aval lors du téléchargement de données à partir d’Internet.

Important

Le système d’exploitation Azure Sphere peut interrompre les opérations en temps opportun, en particulier lorsqu’il effectue une attestation d’appareil, vérifie les mises à jour ou charge les données de télémétrie. Pour les tâches de contrôle critiques, envisagez de les déplacer vers les cœurs M4 et de les coordonner avec un protocole approprié via la boîte aux lettres inter-cœurs. Pour plus d’informations, consultez l’exemple de communication inter-cœurs.

En plus de ces suggestions, consultez la documentation Azure Sphere sur les événements asynchrones et la concurrence.

Surveillance de la connectivité

Une application principale (HL) bien conçue doit implémenter une tâche de vérification de l’intégrité de la connectivité appropriée, qui doit être basée sur un ordinateur à état robuste qui vérifie régulièrement l’état de la connexion Internet (par exemple, à l’aide d’un minuteur epoll) en tirant parti de l’API Networking_IsNetworkingReady. Dans certains cas, vous pouvez utiliser la fonction Networking_GetInterfaceConnectionStatus, car elle fournit un état plus approfondi de l’état de connectivité lié à une interface réseau spécifique que l’application HL-core peut utiliser pour mieux répondre à son état, bien qu’il s’agit d’un coût, car il n’est pas recommandé de l’appeler plus fréquemment que toutes les 90 secondes.

Le rappel de l’ordinateur d’état doit généralement avoir les attributs suivants :

  • Exécutez aussi rapidement que possible.
  • Son intervalle d’interrogation doit être soigneusement conçu, en fonction du scénario d’application spécifique et des exigences globales de la solution (par exemple, temps constant, retard incrémentiel, etc.).
  • Une fois qu’une déconnexion est détectée, il peut être utile d’appeler Networking_GetInterfaceConnectionStatus une fois pour journaliser l’état de l’interface réseau spécifique, qui peut être utilisé pour diagnostiquer le problème et avertir l’utilisateur par le biais d’une interface utilisateur (comme les LED, l’affichage, le terminal). Vous trouverez un exemple de cette approche dans le code principal de l’exemple DHCP Azure Sphere.
  • Activez un mécanisme (par exemple, via une variable globale) qui interrompt toutes les autres tâches de l’application HL-core qui effectuent (ou sont liés) des communications réseau pour optimiser la consommation des ressources jusqu’à ce qu’une connexion soit rétablie.
  • cURL a récemment mis à jour le comportement de rappel et les meilleures pratiques. Bien qu’Azure Sphere ait pris des mesures pour garantir que les versions antérieures du comportement cURL continuent de fonctionner comme prévu, il est recommandé de suivre les dernières instructions pour la sécurité et la fiabilité lors de l’utilisation de curl_multi, car l’utilisation de rappels récursifs peut entraîner des incidents inattendus, des pannes de connectivité et des vulnérabilités de sécurité potentielles. Si un TimerCallback se déclenche avec un délai d’expiration de 0 ms, traitez-le comme un délai d’expiration de 1 ms pour éviter les rappels récursifs. Veillez également à appeler curl_multi_socket_action explicitement au moins une fois après les appels à curl_multi_add_handle.

Outre les suggestions précédentes, vous devez prendre en compte les scénarios suivants pour la gestion de l’alimentation :

  • Arrêtez la puce Azure Sphere après l’envoi de données. Pour plus d’informations, consultez Gérer l’état de power down pour les appareils Azure Sphere.
  • Étant donné que plusieurs problèmes peuvent provenir de délais d’arrêt exponentiels longs, il est essentiel de suivre le temps de fonctionnement total et de définir un minuteur d’arrêt sur une limite raisonnable afin de ne pas vider la batterie dans des conditions où la connectivité n’est plus possible en raison de pannes externes ou d’autres facteurs au-delà du contrôle de l’application.
  • Dans le contrôle de la surveillance de la connectivité pendant les pannes, le transceiveur Wi-Fi peut être désactivé en désactivant l’interface wlan0 réseau (voir Networking_SetInterfaceState) et en attendant la prochaine vérification de la connectivité, ce qui permet d’économiser environ 100 mW.

Gestion et utilisation de la mémoire

Sur les plateformes contraintes en mémoire, les applications qui effectuent des allocations de mémoire fréquentes et des désaffectations peuvent entraîner la gestion de la mémoire du système d’exploitation à lutter contre l’efficacité, ce qui entraîne une fragmentation excessive et un dépassement de mémoire. Plus précisément sur Azure Sphere MT3620, cela peut entraîner des conditions d’absence de mémoire qui pourraient déclencher le tueur OOM du système d’exploitation Azure Sphere à lancer.

De façon compréhensible, les applications sont souvent développées à partir d’une preuve de concept initiale, qui devient plus complète avec les fonctionnalités requises pour les versions progressives, négligeant finalement les fonctionnalités mineures qui ont été initialement incluses. Voici des suggestions et des optimisations qui se sont avérées efficaces pour de nombreux scénarios analysés dans le champ :

  • En particulier dans les applications HL-core qui utilisent beaucoup de mémoire, il est essentiel de suivre l’utilisation de la mémoire de l’application via l’API Azure Sphere, décrite dans Déterminer l’utilisation de la RAM de l’application au moment de l’exécution. En règle générale, cela est implémenté dans un chien de surveillance epoll-timer et l’application réagit en conséquence à une utilisation inattendue de la mémoire afin de redémarrer de manière raisonnable ; par exemple, en utilisant le code de sortie approprié.

    Plusieurs clients et partenaires ont trouvé utile d’utiliser l’utilitaire de suivi de mémoire Heap Tracker , qui est publié dans la galerie Azure Sphere. Cette bibliothèque établit des liens transparents vers une application HL-core existante et effectue le suivi des allocations de mémoire et de leurs pointeurs associés, ce qui simplifie la détection de la plupart des cas de fuites de mémoire et d’utilisation incorrecte des pointeurs.

Important

Cette pratique peut réduire l’absence de réponse ou d’échecs de l’appareil apparemment inexpliqués du champ. Ces défaillances sont généralement causées par des fuites de mémoire ou des dépassements qui ne sont pas gérés correctement par l’application HL-core et mènent le tueur OOM à arrêter le processus de l’application. Cela, ainsi que la faible connectivité qui empêche le système d’exploitation Azure Sphere d’envoyer des données de télémétrie, peut entraîner des incidents de champ potentiels, car le diagnostic ne peut être détecté qu’en extrayant les journaux de diagnostic du système d’exploitation Azure Sphere.

  • Sur les plateformes contraintes en mémoire, il est généralement préférable d’éviter l’allocation de mémoire dynamique dans la mesure du possible, en particulier dans les fonctions fréquemment appelées. Cela réduit considérablement la fragmentation de la mémoire du tas et la probabilité d’échecs d’allocation de tas suivants. Considérez également un changement de paradigme de l’allocation répétitive de tampons de travail temporaires à l’accès direct à la pile (pour les variables de tailles raisonnables) ou des mémoires tampons allouées globalement, ce qui augmente la taille (via realloc) en cas de dépassement (voir conteneurs dynamiques et mémoires tampons). S’il est nécessaire de décharger la mémoire, envisagez de tirer parti de la mémoire inutilisée sur les cœurs M4 (voir Mémoire disponible sur Azure Sphere), qui ont chacun 256KiB, avec une application rt-core légère pour la mise en cache des données. Vous pouvez éventuellement utiliser des cartes SD externes ou flash. Vous trouverez des exemples dans les dépôts suivants :

En suivant les suggestions ci-dessus, vous pouvez également estimer et réserver la mémoire nécessaire pour que l’application HL-core fonctionne à pleine capacité tout au long de son cycle de vie tout en vous permettant d’estimer mieux l’empreinte mémoire globale de l’application pour des optimisations ultérieures de la conception. Pour plus d’informations sur l’optimisation de l’utilisation de la mémoire dans les applications HL-core, notamment les fonctionnalités du système d’exploitation Azure Sphere et de Visual Studio, consultez les articles suivants :