Comment le Watchdog matériel surveille-t-il l'état en temps réel du module 4G ?

J'ai vu trop de caméras PTZ solaires à distance devenir inactives parce que module 4G¹ se sont bloquées — et personne n'était là pour appuyer sur le bouton de réinitialisation.

Un watchdog matériel ne surveille pas directement l'état en temps réel du module 4G. Il surveille le battement de cœur du système principal. Si le CPU principal ou l'OS plante — y compris les plantages causés par des échecs de la pile 4G — le watchdog force une réinitialisation matérielle complète. La surveillance réelle de l'état 4G (force du signal, enregistrement réseau, santé de la liaison de données) est gérée par des démons logiciels s'exécutant sur le processeur principal, et non par la puce watchdog elle-même.

Surveillance de l'état du module 4G par watchdog matériel dans une caméra PTZ

La plupart des acheteurs supposent que le watchdog matériel surveille tout. Ce n'est pas le cas. Comprendre cette lacune est essentiel si vous déployez des caméras PTZ dans des endroits où personne ne peut se rendre pour les redémarrer. Je vais vous expliquer exactement comment chaque couche fonctionne, ce que fait réellement le watchdog, et ce que vous devriez exiger de votre fournisseur.

Le Watchdog vérifie-t-il la réponse “AT Command” du modem toutes les 60 secondes ?

Je pensais que le watchdog matériel envoyait lui-même des commandes AT au modem. Ça ne fonctionne pas comme ça.

Le watchdog matériel n'envoie pas lui-même de commandes AT. C'est un simple circuit de temporisation. Un démon logiciel sur le processeur principal envoie des commandes AT comme AT, AT+CREG?, ou AT+CSQ au modem à intervalles réguliers. Si le modem cesse de répondre, le logiciel cesse d'alimenter le watchdog, et le watchdog déclenche alors une réinitialisation matérielle.

Processus de vérification des commandes AT du Watchdog pour le modem 4G

Comment la chaîne logiciel-matériel fonctionne réellement

Laissez-moi vous expliquer la séquence réelle. Le watchdog matériel est un appareil très simple. Il a un compteur. Le compteur compte. Si le logiciel réinitialise le compteur avant qu'il ne déborde, rien ne se passe. Si le compteur déborde, le watchdog tire la ligne de réinitialisation vers le bas et redémarre tout le système.

Le watchdog n'a pas de port UART. Il n'a aucune capacité à analyser les commandes AT. Il ne sait pas ce que AT+CREG? signifie. Il ne sait pas ce qu'est un modem.

Alors, qui envoie les commandes AT ? Un processus logiciel — généralement un démon Linux⁵ ou un thread de surveillance dédié — s'exécute sur le SoC principal. Ce processus fait ce qui suit :

1. Ouvre le port série connecté au modem 4G (généralement /dev/ttyUSB0 ou similaire).
2. Envoie AT et attend OK.
3. Si OK revient, le firmware du modem est actif.
4. Envoie AT+CREG? pour vérifier l'enregistrement du réseau.
5. Envoie AT+CSQ pour vérifier la force du signal.
6. Si toutes les vérifications réussissent, le démon alimente le chien de garde (écrit dans /dev/watchdog ou bascule une broche GPIO).

Ce qui se passe lorsque le modem se bloque

Si le firmware du modem se bloque, la commande AT ne reçoit aucune réponse. Le démon le détecte. Il peut réessayer 3 fois. Si toutes les tentatives échouent, le démon a deux choix :

Type de défaillance	Réponse logicielle	Rôle du chien de garde
Délai d'attente de la commande AT (gel du firmware du modem)	Le démon tente de réinitialiser le modem via le contrôle d'alimentation GPIO	Le chien de garde n'est pas encore impliqué
La réinitialisation du modem échoue, le démon lui-même plante	Le démon arrête d'alimenter le chien de garde	Le minuteur du chien de garde déborde → redémarrage complet du système
Panique du noyau du système d'exploitation principal causée par le pilote du modem USB	Aucun processus ne peut alimenter le chien de garde	Le minuteur du chien de garde déborde → redémarrage complet du système

Le point clé : le chien de garde est la dernière ligne de défense, pas le premier intervenant. Le démon logiciel fait le travail intelligent. Le chien de garde fait le travail brutal.

La question des 60 secondes

Cela se produit-il toutes les 60 secondes ? Cela dépend de la conception du firmware. Dans la plupart des routeurs 4G industriels et des caméras PTZ avec lesquels j'ai travaillé, l'intervalle d'interrogation est configurable — généralement entre 30 secondes et 5 minutes. Le délai d'attente du chien de garde⁴ est généralement défini sur une période plus longue (comme 90–120 secondes) pour éviter les faux redémarrages lors de problèmes réseau temporaires.

Si votre fournisseur dit “ le chien de garde vérifie les commandes AT toutes les 60 secondes ”, demandez-lui de clarifier : est-ce le démon logiciel qui interroge toutes les 60 secondes, ou est-ce le temporisateur de surveillance réglé sur 60 secondes ? Ce sont deux choses très différentes.

Le matériel peut-il réinitialiser le modem indépendamment de l'OS principal si la pile cellulaire se bloque ?

C'est la question qui me tient éveillé la nuit. Si le noyau Linux plante, quelque chose peut-il encore sauver la connexion 4G ?

Oui — mais seulement si la conception matérielle inclut un chemin de réinitialisation dédié. Un système correctement conçu donne au chien de garde matériel un contrôle direct sur l'alimentation ou la broche de réinitialisation du modem, indépendamment du système d'exploitation principal. Lorsque le temporisateur de surveillance déborde, il peut couper l'alimentation du modem via un interrupteur MOSFET ou ramener la broche RESET_N du modem à l'état bas, sans nécessiter de logiciel en cours d'exécution.

Circuit de réinitialisation indépendant du modem par chien de garde matériel

Deux niveaux de réinitialisation matérielle

Toutes les implémentations de chiens de garde ne sont pas égales. Il y a une grande différence entre un chien de garde de base et un chien de garde industriel correctement conçu.

Niveau 1 : Réinitialisation du système entier (de base)

Dans la plupart des caméras PTZ bon marché, le chien de garde ne peut faire qu'une chose : réinitialiser l'ensemble du système. Le modem, le SoC principal, l'encodeur vidéo — tout redémarre ensemble. Cela fonctionne, mais c'est lent. Un démarrage complet du système peut prendre 60 à 90 secondes. Pendant ce temps, vous n'avez aucune vidéo et aucune connectivité.

Niveau 2 : Réinitialisation indépendante du modem (avancé)

Dans les meilleures conceptions — en particulier dans les passerelles 4G industrielles et les systèmes PTZ solaires haut de gamme — le microcontrôleur du chien de garde dispose d'une ligne GPIO séparée connectée au circuit de contrôle d'alimentation du modem 4G. Cela permet une récupération progressive :

Phase de réinitialisation	Action	Temps de récupération	Impact sur le système
Phase 1 : Réinitialisation logicielle	Le logiciel envoie AT+CFUN=1,1 pour redémarrer le modem	10–15 secondes	Aucune interruption du système
Phase 2 : Réinitialisation matérielle	Le microcontrôleur de surveillance ramène la broche RESET_N à l'état bas pendant 500 ms	15–20 secondes	Le système principal continue de fonctionner
Étape 3 : Cycle d'alimentation	Le microcontrôleur de surveillance coupe le MOSFET, coupe l'alimentation VCC du modem pendant 3 à 5 secondes	20-30 secondes	Le système principal continue de fonctionner
Étape 4 : Redémarrage complet	Le chien de garde déborde, réinitialise toute l'alimentation du système	60-90 secondes	Tout redémarre

Pourquoi c'est important pour les sites solaires distants

Dans un déploiement alimenté à l'énergie solaire³, chaque redémarrage coûte de l'énergie. Un redémarrage complet du système tire un courant de pointe de la batterie. Si la batterie est déjà faible (jour nuageux, hiver), un redémarrage complet pourrait faire chuter la tension en dessous du seuil de fonctionnement minimum du modem, provoquant une boucle de démarrage.

Un chien de garde bien conçu avec une réinitialisation indépendante du modem peut résoudre 80% des problèmes 4G sans toucher au système principal. L'encodeur vidéo continue de fonctionner. Le contrôleur de moteur PTZ reste initialisé. Seul le modem redémarre.

Ce qu'il faut demander à votre fournisseur

Lorsque vous évaluez une caméra PTZ ou un système solaire 4G en provenance de Chine, posez ces questions spécifiques :

• Le microcontrôleur de surveillance dispose-t-il d'un GPIO séparé connecté au contrôle d'alimentation du modem 4G ?
• Le chien de garde peut-il réinitialiser uniquement le modem sans redémarrer tout le SoC ?
• Quelle est la durée du cycle d'alimentation du modem (combien de temps le VCC est-il coupé) ?
• L'alimentation du modem est-elle contrôlée par un commutateur MOSFET⁶ ou simplement par le GPIO du SoC (qui ne fonctionnera pas si le SoC est bloqué) ?

Si le fournisseur ne peut pas répondre à ces questions, le watchdog ne fera probablement que des réinitialisations de tout le système. C'est acceptable pour de nombreux projets, mais ce n'est pas idéal pour les déploiements solaires hors réseau où chaque watt compte.

Le Watchdog enregistrera-t-il la “Force du Signal” et l“”ID Cellulaire" avant de déclencher un redémarrage forcé ?

J'ai eu des sites qui ont redémarré 5 fois en une nuit. Sans journaux, je n'avais aucune idée s'il s'agissait d'un problème de signal, d'un problème matériel ou d'un problème d'alimentation.

Un watchdog matériel de base n'enregistre aucune donnée — il n'a pas de mémoire pour les journaux. Cependant, un système watchdog avancé avec un MCU dédié et un stockage non volatile (EEPROM ou flash) peut enregistrer la dernière intensité de signal connue (RSSI/RSRP), l'identifiant de cellule, la raison du redémarrage et la tension de la batterie avant de déclencher une réinitialisation. Ces données sont essentielles pour le diagnostic à distance.

Le watchdog enregistre l'intensité du signal et l'identifiant de cellule avant le redémarrage

Pourquoi la journalisation avant redémarrage change tout

Sans journaux, chaque redémarrage est un mystère. Vous savez que l'appareil s'est déconnecté et est revenu. Mais vous ne savez pas pourquoi. Était-ce un crash du firmware du modem ? Un signal faible qui a amené le modem à chercher indéfiniment une antenne ? Une faible tension de batterie qui a provoqué une baisse de tension du modem ?

Avec la journalisation avant redémarrage, vous obtenez une piste d'investigation. Voici ce qu'un bon système devrait enregistrer :

Ce qui doit être enregistré

Un démon de surveillance bien conçu devrait écrire les données suivantes dans un stockage non volatile avant il arrête d'alimenter le watchdog :

• Horodatage de la dernière connexion réseau réussie
• RSSI / RSRP / SINR — métriques de qualité du signal de AT+CSQ ou AT+QENG
• Identifiant de cellule et LAC — à quelle antenne relais le modem était connecté (depuis AT+CREG? ou AT+CEREG ?)
• Code de raison du redémarrage — s'agissait-il d'un délai d'attente AT, d'un échec d'enregistrement réseau, d'un délai d'attente de liaison de données ou d'une basse tension ?
• Tension de la batterie au moment de la défaillance
• Température du modem (si disponible via commande AT)
• Nombre de tentatives de redémarrage consécutives

Où ces données sont-elles stockées ?

La puce de surveillance matérielle elle-même (comme une TPS3823 ou MAX6369) n'a pas de stockage. C'est juste une minuterie et une sortie de réinitialisation. La journalisation doit être effectuée par l'un des éléments suivants :

1. Le démon logiciel — écrit dans un fichier sur le stockage flash du système principal avant de déclencher un redémarrage. Risque : si le noyau s'est bloqué, le démon ne peut rien écrire.
2. Le MCU de surveillance — si la surveillance est implémentée comme un microcontrôleur séparé (comme un STM32 ou ATtiny), il peut avoir sa propre EEPROM. Le système principal envoie périodiquement des données d'état au MCU via I2C ou UART. Le MCU stocke le dernier état connu. Même si le système principal plante, le MCU dispose toujours des données.

Comment accéder aux journaux à distance

Une fois le système redémarré et reconnecté à la 4G, le logiciel de surveillance doit :

1. Lire les journaux de redémarrage stockés depuis l'EEPROM ou la mémoire flash.
2. Les télécharger sur votre serveur cloud ou votre plateforme VMS.
3. Vous alerter par e-mail ou notification push avec la raison du redémarrage et les données du signal.

Cela transforme un redémarrage aveugle en renseignements exploitables. Si vous constatez que chaque redémarrage se produit lorsque le RSRP tombe en dessous de -110 dBm, vous savez que vous avez besoin d'une meilleure antenne ou d'une antenne relais différente. Si chaque redémarrage se produit lorsque la tension de la batterie tombe en dessous de 11,2 V, vous savez que vous avez besoin d'une batterie plus grande ou d'un panneau solaire.

Champ de journal	Commande source	Valeur de diagnostic
RSRP / RSSI	AT+CSQ ou AT+QENG="servingcell" (cellule de service)"	Identifie un signal faible comme cause première
Cell ID / LAC	AT+CEREG ?	Détecte les problèmes de transfert de cellule
Tension de la batterie	Lecture ADC du MCU de surveillance	Identifie les boucles de démarrage liées à l'alimentation
Raison du redémarrage	Indicateur d'état du démon logiciel	Permet de distinguer un crash du modem d'un crash du système d'exploitation
Redémarrages consécutifs	Compteur dans l'EEPROM	Déclenche le mode de protection de veille profonde

Comment puis-je empêcher le Watchdog de redémarrer pendant une mise à jour légitime du firmware ?

J'ai une fois rendu une caméra inutilisable car le chien de garde l'a redémarrée en plein milieu d'une mise à jour du firmware. La mémoire flash était à moitié écrite. L'appareil n'est jamais revenu.

Avant de démarrer une mise à jour du micrologiciel², le logiciel doit soit désactiver le chien de garde, soit prolonger son délai d'attente à une valeur supérieure à la durée de la mise à jour. La plupart des systèmes Linux prennent en charge cela via l'interface /dev/watchdog en utilisant le WDIOC_SETTIMEOUT Appel ioctl. Pour les watchdogs matériels sans contrôle logiciel, le processus de mise à jour doit continuer à alimenter le watchdog à intervalles réguliers tout au long de la mise à jour.

Empêcher le redémarrage du watchdog pendant la mise à jour OTA du firmware

Le problème de la mise à jour du firmware

Une mise à jour du firmware (en particulier une mise à jour OTA⁷ sur 4G) peut prendre 5 à 30 minutes selon la taille du fichier et la vitesse de connexion. Pendant ce temps, le système est occupé à écrire dans la mémoire flash. Il peut ne pas exécuter ses tâches de surveillance normales. Il peut ne pas alimenter le watchdog.

Si le délai d'attente du watchdog est réglé sur 120 secondes et que l'écriture du firmware prend 10 minutes, le watchdog redémarrera le système à la marque des 2 minutes. La flash est à moitié écrite. Le bootloader ne trouve pas d'image valide. L'appareil est briqué. Vous devez maintenant envoyer quelqu'un sur le site avec un programmeur JTAG ou une console série.

Ce n'est pas un risque théorique. Je l'ai vu se produire sur le terrain.

Trois stratégies pour éviter cela

Stratégie 1 : Désactiver le watchdog pendant la mise à jour

Sur les systèmes Linux, vous pouvez désactiver le watchdog en écrivant le caractère magique V à /dev/watchdog puis en fermant le descripteur de fichier. Cela indique au pilote du watchdog d'arrêter le minuteur.

Risque : Si le processus de mise à jour lui-même plante, il n'y a pas de watchdog pour récupérer le système. Vous volez sans filet de sécurité.

Stratégie 2 : Étendre le délai d'attente du watchdog

Une meilleure approche consiste à étendre le délai d'attente du watchdog à une valeur supérieure à la durée maximale prévue de la mise à jour. Par exemple, réglez-le sur 30 minutes avant de commencer la mise à jour, puis réinitialisez-le à 120 secondes une fois la mise à jour terminée.

Risque : Si le système plante pendant la mise à jour pour une raison non liée à la mise à jour elle-même, vous attendrez 30 minutes avant que le watchdog ne redémarre. Mais au moins le watchdog est toujours actif.

Stratégie 3 : Alimenter le watchdog depuis le processus de mise à jour

L'approche la plus robuste consiste à faire en sorte que le processus de mise à jour du firmware alimente lui-même le watchdog à intervalles réguliers. Après chaque bloc de données écrit dans la flash, le processus de mise à jour écrit dans /dev/watchdog pour réinitialiser le minuteur.

Risque : Minimal. Le chien de garde reste actif avec son délai d'attente normal. Si le processus de mise à jour se bloque, le chien de garde redémarrera le système. L'exigence clé est que votre chargeur de démarrage prenne en charge la partition A/B⁸ la commutation ou dispose d'un mécanisme de retour arrière, de sorte qu'une écriture partielle ne bloque pas l'appareil.

Ce qu'il faut exiger de votre fournisseur

Si votre caméra PTZ prend en charge les mises à jour de firmware OTA sur 4G (et elle devrait le faire pour les déploiements à distance), demandez à votre fournisseur :

• Que se passe-t-il pour le chien de garde pendant une mise à jour du firmware ?
• Le processus de mise à jour alimente-t-il le chien de garde, ou le désactive-t-il ?
• Le chargeur de démarrage prend-il en charge les partitions A/B ou le retour arrière en cas de mise à jour échouée ?
• Le fournisseur a-t-il testé une panne de courant pendant la mise à jour du firmware ? L'appareil récupère-t-il ?

Ces questions distinguent les fabricants sérieux des assembleurs qui se contentent de placer des composants sur une carte. Une caméra bloquée sur un site solaire distant peut vous coûter entre 500 et 2 000 dollars en frais de déplacement — bien plus que la caméra elle-même.

Conclusion

Le chien de garde matériel est votre dernière ligne de défense, pas votre première. Il redémarre le système lorsque tout le reste échoue. Pour une véritable surveillance 4G — vérifications du signal, réinitialisations du modem et journalisation avant redémarrage — vous avez besoin de démons logiciels travaillant de concert avec le chien de garde. Exigez les deux de votre fournisseur.

---

1. Aperçu de la technologie cellulaire 4G et des normes de modules. ︎↩︎ 2. Informations générales sur le firmware et les procédures de mise à jour. ︎↩︎ 3. Bases des systèmes d'énergie solaire pour équipements distants. ︎↩︎ 4. Note d'application technique sur les minuteurs chien de garde dans les systèmes embarqués. ︎↩︎ 5. Explication des processus d'arrière-plan dans les systèmes de type Unix. ︎↩︎ 6. Comment les MOSFET sont utilisés pour la commutation d'alimentation dans les circuits. ︎↩︎ 7. Définition des mises à jour de firmware par voie aérienne pour les appareils connectés. ︎↩︎ 8. Explication des mises à jour système A/B pour un démarrage fiable après des mises à jour échouées. ︎↩︎