Wie überwacht der Hardware-Watchdog den Echtzeitstatus des 4G-Moduls?

Ich habe zu viele ferngesteuerte Solar-PTZ-Kameras gesehen, die dunkel wurden, weil 4G-Modul¹ eingefroren sind – und niemand da war, um den Reset-Knopf zu drücken.

Ein Hardware-Watchdog überwacht nicht direkt den Echtzeitstatus des 4G-Moduls. Er überwacht den Herzschlag des Hauptsystems. Wenn die Haupt-CPU oder das Betriebssystem abstürzt – einschließlich Abstürzen, die durch Fehler im 4G-Stack verursacht werden –, erzwingt der Watchdog einen vollständigen Hardware-Reset. Die eigentliche Überwachung des 4G-Status (Signalstärke, Netzwerkregistrierung, Datenverbindungszustand) wird von Software-Daemons übernommen, die auf dem Hauptprozessor laufen, nicht vom Watchdog-Chip selbst.

Hardware-Watchdog-Überwachung des 4G-Modulstatus in PTZ-Kameras

Die meisten Käufer gehen davon aus, dass der Hardware-Watchdog alles überwacht. Das tut er nicht. Das Verständnis dieser Lücke ist entscheidend, wenn Sie PTZ-Kameras an Orten einsetzen, an denen niemand hinfahren kann, um sie neu zu starten. Lassen Sie mich genau aufschlüsseln, wie jede Ebene funktioniert, was der Watchdog tatsächlich tut und was Sie von Ihrem Lieferanten verlangen sollten.

Inhaltsübersicht

Überprüft der Watchdog jede Sekunde die Antwort auf den “AT-Befehl” vom Modem?

Ich dachte früher, der Hardware-Watchdog würde selbstständig AT-Befehle an das Modem senden. So funktioniert es nicht.

Der Hardware-Watchdog selbst sendet keine AT-Befehle. Es ist eine einfache Timer-Schaltung. Ein Software-Daemon auf dem Hauptprozessor sendet AT-Befehle wie AT, AT+CREG?, oder AT+CSQ in regelmäßigen Abständen an das Modem. Wenn das Modem nicht mehr antwortet, hört die Software auf, den Watchdog zu füttern, und der Watchdog löst dann einen Hardware-Reset aus.

Watchdog-AT-Befehlsverifizierungsprozess für 4G-Modem

Wie die Software-Hardware-Kette tatsächlich funktioniert

Lassen Sie mich Sie durch die tatsächliche Sequenz führen. Der Hardware-Watchdog ist ein sehr einfaches Gerät. Er hat einen Zähler. Der Zähler zählt hoch. Wenn die Software den Zähler zurücksetzt, bevor er überläuft, passiert nichts. Wenn der Zähler überläuft, zieht der Watchdog die Reset-Leitung auf LOW und startet das gesamte System neu.

Der Watchdog hat keinen UART-Port. Er hat keine Möglichkeit, AT-Befehle zu parsen. Er weiß nicht, was AT+CREG? bedeutet. Es weiß nicht, was ein Modem ist.

Wer sendet also die AT-Befehle? Ein Softwareprozess – normalerweise ein Linux-Daemon⁵ oder ein dedizierter Überwachungsthread – läuft auf dem Haupt-SoC. Dieser Prozess tut Folgendes:

Öffnet den seriellen Port, der mit dem 4G-Modem verbunden ist (normalerweise /dev/ttyUSB0 oder ähnlich).
Sendet AT und wartet auf OK.
Wenn OK zurückkommt, ist die Modem-Firmware aktiv.
Sendet AT+CREG? um die Netzwerkregistrierung zu überprüfen.
Sendet AT+CSQ um die Signalstärke zu überprüfen.
Wenn alle Prüfungen bestanden sind, füttert der Daemon den Watchdog (schreibt in /dev/watchdog oder schaltet einen GPIO-Pin um).

Was passiert, wenn das Modem einfriert

Wenn die Modem-Firmware abstürzt, erhält der AT-Befehl keine Antwort. Der Daemon erkennt dies. Er kann es 3 Mal erneut versuchen. Wenn alle Wiederholungsversuche fehlschlagen, hat der Daemon zwei Möglichkeiten:

Fehlertyp	Software-Antwort	Rolle der Überwachungseinheit (Watchdog)
AT-Befehls-Timeout (Modem-Firmware-Einfrieren)	Daemon versucht, das Modem über GPIO-Stromsteuerung zurückzusetzen	Die Überwachungseinheit ist noch nicht involviert
Modem-Reset schlägt fehl, Daemon stürzt selbst ab	Daemon hört auf, die Überwachungseinheit zu füttern	Überwachungseinheit-Timer läuft über → vollständiger Systemneustart
Haupt-OS-Kernel-Panic verursacht durch USB-Modemtreiber	Kein Prozess kann die Überwachungseinheit füttern	Überwachungseinheit-Timer läuft über → vollständiger Systemneustart

Der springende Punkt: Die Überwachungseinheit ist die letzte Verteidigungslinie, nicht der Ersthelfer. Der Software-Daemon leistet die intelligente Arbeit. Die Überwachungseinheit leistet die Brute-Force-Arbeit.

Die 60-Sekunden-Frage

Passiert das alle 60 Sekunden? Das hängt vom Firmware-Design ab. Bei den meisten industriellen 4G-Routern und PTZ-Kameras, mit denen ich gearbeitet habe, ist das Abfrageintervall konfigurierbar – typischerweise zwischen 30 Sekunden und 5 Minuten. Das Timeout der Überwachungseinheit⁴ wird normalerweise auf einen längeren Zeitraum (wie 90–120 Sekunden) eingestellt, um Fehlstarts während vorübergehender Netzwerkprobleme zu vermeiden.

Wenn Ihr Lieferant sagt: “Die Überwachungseinheit prüft AT-Befehle alle 60 Sekunden”, bitten Sie ihn um Klärung: Ist es der Software-Daemon , der alle 60 Sekunden abfragt, oder ist es die Watchdog-Timer auf 60 Sekunden eingestellt? Das sind zwei sehr unterschiedliche Dinge.

Kann die Hardware das Modem unabhängig vom Hauptbetriebssystem zurücksetzen, wenn der Mobilfunk-Stack einfriert?

Das ist die Frage, die mich nachts wach hält. Wenn der Linux-Kernel abstürzt, kann dann noch etwas die 4G-Verbindung retten?

Ja – aber nur, wenn das Hardwaredesign einen dedizierten Reset-Pfad vorsieht. Ein richtig ausgelegtes System gibt dem Hardware-Watchdog die direkte Kontrolle über die Stromversorgung oder den Reset-Pin des Modems, unabhängig vom Hauptbetriebssystem. Wenn der Watchdog-Timer überläuft, kann er die Stromversorgung des Modems über einen MOSFET-Schalter unterbrechen oder den RESET_N-Pin des Modems auf LOW ziehen, ohne dass Software laufen muss.

Hardware-Watchdog unabhängige Modem-Reset-Schaltung

Zwei Stufen von Hardware-Resets

Nicht alle Watchdog-Implementierungen sind gleich. Es gibt einen großen Unterschied zwischen einem einfachen Watchdog und einem richtig ausgelegten industriellen Watchdog.

Stufe 1: Systemweiter Reset (Einfach)

In den meisten billigen PTZ-Kameras kann der Watchdog nur eines tun: das gesamte System neu starten. Das Modem, der Haupt-SoC, der Video-Encoder – alles startet neu. Das funktioniert, ist aber langsam. Ein vollständiger Systemstart kann 60–90 Sekunden dauern. Während dieser Zeit haben Sie null Video und null Konnektivität.

Stufe 2: Unabhängiger Modem-Reset (Fortgeschritten)

Bei besseren Designs – insbesondere bei industriellen 4G-Gateways und High-End-Solar-PTZ-Systemen – verfügt die Watchdog-MCU über eine separate GPIO-Leitung, die mit der Stromsteuerungs-Schaltung des 4G-Modems verbunden ist. Dies ermöglicht eine gestufte Wiederherstellung:

Reset-Stufe	Aktion	Wiederherstellungszeit	Systemauswirkungen
Stufe 1: Soft-Reset	Software sendet `AT+CFUN=1,1` zum Neustart des Modems	10–15 Sekunden	Keine Systemunterbrechung
Stufe 2: Hard-Reset	Watchdog-MCU zieht RESET_N-Pin für 500 ms auf LOW	15–20 Sekunden	Hauptsystem läuft weiter
Stufe 3: Stromunterbrechung	Watchdog-MCU schaltet MOSFET ab, unterbricht Modem-VCC für 3–5 Sekunden	20-30 Sekunden	Hauptsystem läuft weiter
Stufe 4: Vollständiger Neustart	Watchdog läuft über, setzt die gesamte Systemleistung zurück	60-90 Sekunden	Alles startet neu

Warum das für entfernte Solaranlagen wichtig ist

Bei einer solarbetriebenen Bereitstellung³, kostet jeder Neustart Energie. Ein vollständiger Systemneustart zieht Spitzenstrom aus der Batterie. Wenn die Batterie bereits niedrig ist (bewölkter Tag, Winter), kann ein vollständiger Neustart die Spannung unter den minimalen Betriebsschwellenwert des Modems fallen lassen und eine Boot-Schleife verursachen.

Ein gut konzipierter Watchdog mit unabhängigem Modem-Reset kann 80% der 4G-Probleme beheben, ohne das Hauptsystem zu berühren. Der Videokodierer läuft weiter. Der PTZ-Motorcontroller bleibt initialisiert. Nur das Modem startet neu.

Was Sie Ihren Lieferanten fragen sollten

Wenn Sie eine PTZ-Kamera oder ein Solar-4G-System aus China bewerten, stellen Sie diese spezifischen Fragen:

Hat der Watchdog-MCU einen separaten GPIO , der mit der Stromversorgung des 4G-Modems verbunden ist?
Kann der Watchdog nur das Modem zurücksetzen, ohne den gesamten SoC neu zu starten?
Wie lange dauert der Power-Cycle für das Modem (wie lange ist VCC unterbrochen)?
Wird die Modem-Stromversorgung über einen MOSFET-Schalter⁶ oder nur über den GPIO des SoC gesteuert (was nicht funktioniert, wenn der SoC eingefroren ist)?

Wenn der Lieferant diese Fragen nicht beantworten kann, führt der Watchdog wahrscheinlich nur System-Resets durch. Das ist für viele Projekte akzeptabel, aber nicht ideal für netzunabhängige Solaranlagen, bei denen jedes Watt zählt.

Zeichnet der Watchdog die “Signalstärke” und die “Cell ID” auf, bevor er einen erzwungenen Neustart auslöst?

Ich hatte Standorte, die 5 Mal in einer Nacht neu gestartet sind. Ohne Protokolle hatte ich keine Ahnung, ob es sich um ein Signalproblem, ein Hardwareproblem oder ein Stromproblem handelte.

Ein einfacher Hardware-Watchdog zeichnet keine Daten auf – er hat keinen Speicher für Protokolle. Ein fortschrittliches Watchdog-System mit einem dedizierten MCU und nichtflüchtigem Speicher (EEPROM oder Flash) kann jedoch die zuletzt bekannte Signalstärke (RSSI/RSRP), Cell ID, den Neustartgrund und die Batteriespannung protokollieren, bevor ein Reset ausgelöst wird. Diese Daten sind entscheidend für die Fernwartung.

Watchdog protokolliert Signalstärke und Cell ID vor dem Neustart

Warum Pre-Reboot-Logging alles verändert

Ohne Protokolle ist jeder Neustart ein Rätsel. Sie wissen, dass das Gerät offline gegangen und wieder online gekommen ist. Aber Sie wissen nicht warum. War es ein Absturz der Modem-Firmware? Ein schwaches Signal, das das Modem dazu veranlasst, endlos nach einem Sendemast zu suchen? Eine niedrige Batteriespannung, die dazu führt, dass das Modem ausfällt?

Mit Pre-Reboot-Logging erhalten Sie eine forensische Spur. Hier ist, was ein gutes System aufzeichnen sollte:

Was sollte protokolliert werden?

Ein gut konzipierter Monitoring-Daemon sollte die folgenden Daten im nichtflüchtigen Speicher speichern bevor er hört auf, den Watchdog zu füttern:

Zeitstempel der letzten erfolgreichen Netzwerkverbindung
RSSI / RSRP / SINR – Signalqualitätsmetriken von AT+CSQ oder AT+QENG
Cell ID und LAC — mit welchem Mobilfunkmast das Modem verbunden war (von AT+CREG? oder AT+CEREG?)
Neustart-Grundcode — war es ein AT-Timeout, ein Fehler bei der Netzwerkregistrierung, ein Datenverbindungs-Timeout oder eine niedrige Spannung?
Batteriespannung zum Zeitpunkt des Fehlers
Modemtemperatur (falls über AT-Befehl verfügbar)
Anzahl aufeinanderfolgender Neustartversuche

Wo werden diese Daten gespeichert?

Der Hardware-Watchdog-Chip selbst (wie ein TPS3823 oder MAX6369) hat keinen Speicher. Es ist nur ein Timer und ein Reset-Ausgang. Die Protokollierung muss entweder erfolgen durch:

Der Software-Daemon — schreibt in eine Datei auf dem Flash-Speicher des Hauptsystems, bevor ein Neustart ausgelöst wird. Risiko: Wenn der Kernel abgestürzt ist, kann der Daemon nichts schreiben.
Das Watchdog-MCU — wenn der Watchdog als separater Mikrocontroller (wie ein STM32 oder ATtiny) implementiert ist, kann dieser einen eigenen EEPROM haben. Das Hauptsystem sendet periodisch Statusdaten über I2C oder UART an das MCU. Das MCU speichert den letzten bekannten Zustand. Selbst wenn das Hauptsystem abstürzt, hat das MCU die Daten immer noch.

Wie man auf die Protokolle remote zugreift

Nachdem das System neu gestartet wurde und sich wieder mit 4G verbunden hat, sollte die Überwachungssoftware:

Die gespeicherten Neustartprotokolle aus dem EEPROM oder Flash lesen.
Diese auf Ihren Cloud-Server oder Ihre VMS-Plattform hochladen.
Sie per E-Mail oder Push-Benachrichtigung mit dem Neustartgrund und den Signal-Daten alarmieren.

Dies verwandelt einen blinden Neustart in umsetzbare Erkenntnisse. Wenn Sie sehen, dass jeder Neustart stattfindet, wenn die RSRP unter -110 dBm fällt, wissen Sie, dass Sie eine bessere Antenne oder einen anderen Mast benötigen. Wenn jeder Neustart stattfindet, wenn die Batteriespannung unter 11,2 V fällt, wissen Sie, dass Sie eine größere Batterie oder ein Solarpanel benötigen.

Log-Feld	Quellbefehl	Diagnosewert
RSRP / RSSI	`AT+CSQ` oder `AT+QENG="servingcell"`	Identifiziert schwaches Signal als Ursache
Cell ID / LAC	`AT+CEREG?`	Erkennt Probleme beim Tower-Handover
Batteriespannung	ADC-Messwert vom Watchdog-MCU	Identifiziert boot-Schleifen, die mit Strom zusammenhängen
Neustartgrund	Statusflag des Software-Daemons	Unterscheidet Modemabsturz von OS-Absturz
Aufeinanderfolgende Neustarts	Zähler im EEPROM	Löst Tiefschlaf-Schutzmodus aus

Wie verhindere ich, dass der Watchdog während eines legitimen Firmware-Updates neu startet?

Ich habe einmal eine Kamera gebrickt, weil der Watchdog sie mitten im Firmware-Update neu gestartet hat. Der Flash war halb geschrieben. Das Gerät kam nie wieder zurück.

Bevor ein Firmware-Update², gestartet wird, muss die Software entweder den Watchdog-Timer deaktivieren oder dessen Timeout auf einen Wert verlängern, der länger als die Update-Dauer ist. Die meisten Linux-Systeme unterstützen dies über die /dev/watchdog Schnittstelle unter Verwendung des WDIOC_SETTIMEOUT ioctl-Aufruf. Bei Hardware-Watchdogs ohne Softwaresteuerung muss der Update-Prozess den Watchdog während des gesamten Updates in regelmäßigen Abständen weiter füttern.

Verhindern eines Watchdog-Neustarts während eines Firmware-OTA-Updates

Das Problem mit Firmware-Updates

Ein Firmware-Update (insbesondere ein OTA-Update⁷ über 4G) kann je nach Dateigröße und Verbindungsgeschwindigkeit 5–30 Minuten dauern. Während dieser Zeit ist das System mit dem Schreiben in den Flash-Speicher beschäftigt. Es führt möglicherweise nicht seine normalen Überwachungsaufgaben aus. Es füttert möglicherweise nicht den Watchdog.

Wenn die Watchdog-Timeout auf 120 Sekunden eingestellt ist und das Firmware-Schreiben 10 Minuten dauert, startet der Watchdog das System nach 2 Minuten neu. Der Flash ist halb beschrieben. Der Bootloader kann kein gültiges Image finden. Das Gerät ist gebrickt. Sie müssen nun jemanden mit einem JTAG-Programmierer oder einer seriellen Konsole zum Standort schicken.

Dies ist kein theoretisches Risiko. Ich habe es in der Praxis erlebt.

Drei Strategien, um dies zu verhindern

Strategie 1: Watchdog während des Updates deaktivieren

Unter Linux können Sie den Watchdog deaktivieren, indem Sie das magische Zeichen schreiben V zu /dev/watchdog und dann den Dateideskriptor schließen. Dies weist den Watchdog-Treiber an, den Timer zu stoppen.

Risiko: Wenn der Update-Prozess selbst abstürzt, gibt es keinen Watchdog, der das System wiederherstellen kann. Sie fliegen ohne Sicherheitsnetz.

Strategie 2: Watchdog-Timeout verlängern

Ein besserer Ansatz ist, das Watchdog-Timeout auf einen Wert zu verlängern, der länger ist als die maximal erwartete Update-Dauer. Stellen Sie es beispielsweise vor Beginn des Updates auf 30 Minuten ein und setzen Sie es nach Abschluss des Updates wieder auf 120 Sekunden zurück.

Risiko: Wenn das System während des Updates aus einem anderen Grund als dem Update selbst abstürzt, warten Sie 30 Minuten, bevor der Watchdog neu startet. Aber zumindest ist der Watchdog noch aktiv.

Strategie 3: Watchdog aus dem Update-Prozess füttern

Der robusteste Ansatz ist, dass der Firmware-Update-Prozess selbst den Watchdog in regelmäßigen Abständen füttert. Nach jedem geschriebenen Datenblock in den Flash schreibt der Update-Prozess in /dev/watchdog um den Timer zurückzusetzen.

Risiko: Minimal. Der Watchdog bleibt mit seinem normalen Timeout aktiv. Wenn der Update-Prozess hängen bleibt, startet der Watchdog das System neu. Die wichtigste Anforderung ist, dass Ihr Bootloader A/B-Partitionen⁸ unterstützt oder über einen Rollback-Mechanismus verfügt, sodass ein teilweises Schreiben das Gerät nicht unbrauchbar macht.

Was Sie von Ihrem Lieferanten verlangen sollten

Wenn Ihre PTZ-Kamera OTA-Firmware-Updates über 4G unterstützt (und das sollte sie für Remote-Bereitstellungen), fragen Sie Ihren Lieferanten:

Was passiert mit dem Watchdog während eines Firmware-Updates?
Füttert der Update-Prozess den Watchdog oder deaktiviert er ihn?
Unterstützt der Bootloader A/B-Partitionen oder Rollback bei fehlgeschlagenem Update?
Hat der Lieferant einen Stromausfall während des Firmware-Updates getestet? Erholt sich das Gerät?

Diese Fragen trennen ernsthafte Hersteller von Assemblierern, die nur Komponenten auf eine Platine setzen. Eine unbrauchbar gewordene Kamera an einem entfernten Solarmast kann Sie 500–2.000 US-Dollar an Kosten für den Einsatz vor Ort kosten – weit mehr als die Kamera selbst.

Schlussfolgerung

Der Hardware-Watchdog ist Ihre letzte Verteidigungslinie, nicht Ihre erste. Er startet das System neu, wenn alles andere fehlschlägt. Für echte 4G-Überwachung – Signalprüfungen, Modem-Resets und Protokollierung vor dem Neustart – benötigen Sie Software-Daemons, die mit dem Watchdog zusammenarbeiten. Verlangen Sie beides von Ihrem Lieferanten.

1. Überblick über 4G-Mobilfunktechnologie und Modulstandards. ︎↩︎ 2. Allgemeine Informationen zu Firmware und Update-Verfahren. ︎↩︎ 3. Grundlagen von Solarenergiesystemen für entfernte Geräte. ︎↩︎ 4. Technisches Anwendungshinweis zu Watchdog-Timern in eingebetteten Systemen. ︎↩︎ 5. Erklärung von Hintergrundprozessen in Unix-ähnlichen Systemen. ︎↩︎ 6. Wie MOSFETs für die Leistungsverschaltung in Schaltungen verwendet werden. ︎↩︎ 7. Definition von Over-the-Air-Firmware-Updates für vernetzte Geräte. ︎↩︎ 8. Erklärung von A/B-System-Updates für einen zuverlässigen Boot nach fehlgeschlagenen Updates. ︎↩︎