14.2. Livrer l’application

Un script fonctionnel sur l’établi et un produit livré ne sont pas la même chose. Une caméra qui part sur le terrain doit fonctionner toute seule aussi longtemps que le produit est installé – des mois, des années – sans opérateur à la console, sans IDE connecté et sans expert Python à proximité quand quelque chose cesse de fonctionner. Les pages de cette section couvrent ce qui change pour l’application lorsque l’objectif est un produit livré plutôt qu’une démo de bureau.

14.2.1. Une liste de contrôle préalable

Avant qu’une caméra ne quitte l’établi, voici la courte liste des choses qui devraient être vraies :

  • Le code de l’application est dans la compilation, pas sur le système de fichiers. Les modules gelés et une image ROMFS couvrent le code et les ressources. Le stockage en mémoire flash et sur carte SD ne sert qu’à l’état d’exécution et aux fichiers journaux. L’utilisateur final ne peut pas modifier, supprimer ni remplacer l’application sans reflasher.

  • Un chien de garde fonctionne en permanence. machine.WDT est démarré en tête de main.py et alimenté une fois par itération de la boucle principale. Tout blocage plus long que le délai d’expiration configuré provoque une réinitialisation matérielle et la caméra redémarre.

  • L’application journalise vers une destination récupérable. La bibliothèque logging écrit des enregistrements assortis d’un niveau, d’un horodatage et d’une destination que le terrain peut récupérer depuis la carte SD. print() n’est utile qu’en phase de développement – sa destination par défaut est la sortie standard USB, qu’aucun produit livré ne lit.

  • La mémoire flash et la carte SD sont traitées comme susceptibles d’échouer. La mémoire flash interne contient de petits enregistrements de taille fixe (configuration, dernier étalonnage connu) ; la carte SD contient des fichiers volumineux de taille variable (captures d’image, fichiers journaux) ; les opérations sur l’une ou l’autre sont encadrées par une gestion des erreurs, et l’application dispose d’une solution de repli définie lorsque l’une ou l’autre est indisponible.

14.2.2. Intégrer l’application dans la compilation

Deux mécanismes complémentaires placent des fichiers dans l’image du micrologiciel :