Methoden zum Erkennen einer Fehlerbedingung in Microcontroller-Systemen

[damfino]

Ein Buffer (Array) wird permanent mit Werten gefüllt. Durch falsche Berechnungen, Abweichungen etc. wird dieser über den reservierten Bereich beschrieben.
Wenn nach dem reservierten Bereich wichtige Variablen stehen die dann einfach überschrieben/gelöscht werden, kann es unter Umständen zu den kuriosesten Fehler kommen die man sich vorstellen kann...
Ein Watchdog wird in dieser Hinsicht seine Grenzen haben - vielleicht ist es in diesem Fall sogar notwendig nicht mehrere Systeme parallel zu fahren, sondern abweichende, oder kontrollierende Systeme aufzusetzen.
Wenn 3 identische Systeme parallel laufen ist immernoch nicht garantiert, dass sie nicht alle drei den gleichen Fehler verursachen können... (der damit nicht erkannt wird)

Das mit dem Array Überlauf und dadurch nicht mehr funktionierendem Watchdog kann ich bestätigen...

Man nimmt auch nicht 3 identische Systeme, zumindest eines davon muss auf einer anderen Hardware und Software Umgebung laufen, idealerweise von einem komplett anderem Team entwickelt.
Space Shuttle hatte 5x identische Hardware + 4x identische Software, aber auf einem eine andere Software die übernehmen sollte wenn die anderen 4 ausfallen.

[HaWe]

und für Datentransmission hat sich auf µCs das Bitbusprotokoll bewährt. Es ist - einfach ausgedrückt - ein Teil des TCP/IP-Protokolls und schützt v.a. auch davor, dass Daten schneller gesendet werden als die vorherigen bislang verarbeitet werden konnten. Damit wird quasi verhindert, dass die Datenleitungen verstopfen. Denn was will man bei allen Plausibilitätschecks und Checksums und Heartbeats mit den Daten anfangen, wenn die verbindung steht, aber die Daten, die man gerade beim Empfänger verarbeitet, bereits eine halbe Stunde alt sind

Es wird erfolgleich von leJOS/JAVA auf dem Lego NXT für Bluetooth und RS485 eingesetzt (ob ebenfalls auf dem EV3, weiß ich nicht, da habe ich es nicht mehr verwendet).