Le chien de garde (watchdog) est un compteur, le plus souvent matériel et cadencé par une horloge indépendante, que le firmware doit réinitialiser à intervalles réguliers. S’il atteint zéro, il en déduit que le programme ne tourne plus et il force un redémarrage. L’état de repli est le comportement défini à l’avance pour qu’une fonction qui échoue n’entraîne pas l’arrêt du reste. Le premier traite le blocage total, le second les défaillances partielles. Sur un firmware de terrain, je les pose dans cet ordre.
Le chien de garde relance automatiquement un objet figé quand il cesse de donner signe de vie ; les états de repli le laissent continuer en mode dégradé au lieu de se planter — deux mécanismes qui ne valent qu’à condition de tracer ce qu’ils compensent.
1. Câbler le watchdog matériel, pas le logiciel. Beaucoup de SDK proposent un watchdog applicatif bien commode. Il a un défaut : il dépend du même code que celui qu’il surveille. L’ordonnanceur (la brique qui répartit le temps de calcul entre les tâches) se fige, lui aussi. Sur un parc de capteurs déployé sans watchdog matériel actif (l’option existait, personne ne l’avait câblée), le taux d’objets « morts sur site » au bout d’un an tournait autour de 3 à 5 %. Chacun demandait une intervention physique. Activez l’IWDG du microcontrôleur, sur son horloge propre.
2. Régler la fenêtre sur votre boucle, pas sur une valeur magique. Mesurez le pire temps de cycle normal de votre boucle principale, puis donnez-vous une marge confortable au-dessus, de l’ordre du double. Trop court, vous relancez l’objet en plein traitement légitime. Trop long, un vrai blocage vous coûte des minutes avant relance.
3. Suspendre le compteur pendant les opérations longues. C’est le détail qui mord. Si vous réarmez toutes les secondes mais qu’une mise à jour OTA prend trente secondes en flash bloquant, le watchdog vous redémarre au milieu de l’écriture et vous briquez l’objet. Il devient inerte, irrécupérable à distance. Avant ce genre d’opération, rallongez la fenêtre ou suspendez le compteur, proprement, et réactivez-le après.
4. Définir un repli par dépendance. Prenez chaque ressource externe et posez la question : que fait l’objet si elle lâche ? Et « il se bloque » ne fait jamais partie des réponses acceptées. Le capteur principal ne répond plus, vous le marquez défaillant et continuez avec les autres voies. La config distante est injoignable, vous repartez sur la dernière valide en mémoire. Un sous-système entier tombe, vous désactivez sa fonction et gardez l’objet joignable pour le reste. Le module radio sature, vous mettez les données en file d’attente locale et retentez plus tard au lieu de bloquer le fil d’exécution.
5. Journaliser et remonter ce que ces mécanismes compensent. Cette étape passe presque toujours à la trappe, et c’est elle qui change tout. Un objet qui se relance dix fois par jour grâce au watchdog a l’air de fonctionner, mais il traîne un bug bien réel. Coincé en repli permanent, il rend un service amputé que personne ne voit passer. Horodatez chaque redémarrage watchdog et chaque bascule en repli en local, puis poussez-les par télémétrie (les indicateurs d’état que l’objet remonte au serveur de supervision). Le rétablissement automatique vous sauve sur l’instant ; la remontée vous évite de laisser pourrir la cause pendant des mois. Sans elle, vous pilotez une flotte qui vous ment sur son propre état.
Sur le terrain, ces cinq points tiennent dans une posture : supposer que ça va casser et faire en sorte que l’objet s’en remette seul. Le reste est une affaire de discipline au moment d’écrire le code de démarrage, là où on a toujours envie d’aller vite. Le registre de cause de reset, lui, vous attend dès la première ligne du main.