Methoden zum Erkennen einer Fehlerbedingung in Microcontroller-Systemen

[Dirk]

Hi schorsch_76,

leider sind µC 1 und µC 2 nicht redundant.

1:
Main Prozessor für Hauptprogramm, Sensoren/Aktoren sind auch: Navigationssensoren (Lage, Magnet, GPS, Helligkeit, Bumper, ACS, Temperatur, ...), Kommunikation (Funk, IR), Batterieüberwachung (Temperatur, Spannung).

2:
Second Prozessor für Motoransteuerungen (6 H-Brücken) mit Fehlersignal, Motorstrom, Temperatur.

Beide Systeme sind über I2C verbunden (2 I/O-Leitungen), möglich wäre noch eine weitere Direkt-Verbindung.

Natürlich können beide Systeme in eine Fehlerbedingung kommen. Ich würde auch nicht so weit gehen, jedes System zweifach vorzusehen.
Mir würde genügen, wenn jedes System erkennt, ob es selbst und sein Partner arbeitet. µC 2 soll im Fehlerfall die H-Brücken sicher in die Kurzschlußposition (Bremsen) bringen, anschließend wieder versuchen hochzufahren und auf Reaktion von µC 1 zu warten.
µC 1 soll im eigenen Fehlerfall den Bremsbefehl an µC 2 noch absetzen und ggf. über die Kommunikation den Fehlerstatus melden (interner Fehler oder z.B. Lagesensor: umgekippt!). Im Fehlerfall von µC 2 soll er das auch melden und regelmäßig versuchen, die I2C-Kommunikation wieder aufzunehmen.

Klingt einfach, macht mir doch aber einiges Kopfzerbrechen.

Die Hauptfrage ist: Wie erkennt jeder µC einen gestörten Programmablauf, z.B. eine (falsche) Programmschleife, die eine Rückkehr in die Hauptschleife verhindert.
Kann man z.B. einen Zähler in jeder regelhaft aktiven Funktion hochzählen und in einem Interrupt den Stand dieses Zählers abfragen: Wenn er außerhalb eines festgelegten Fensters ist: Fehler und ggf. Reboot!
Aber auch damit wird man nicht alle Fehlerbedingungen erfassen.

[Peter(TOO)]

Die Hauptfrage ist: Wie erkennt jeder µC einen gestörten Programmablauf, z.B. eine (falsche) Programmschleife, die eine Rückkehr in die Hauptschleife verhindert.
Kann man z.B. einen Zähler in jeder regelhaft aktiven Funktion hochzählen und in einem Interrupt den Stand dieses Zählers abfragen: Wenn er außerhalb eines festgelegten Fensters ist: Fehler und ggf. Reboot!

Das geht mit dem Watchdog.
Dieser wird in der Hauptschleife zurückgesetzt.
Wenn da ein Unterprogramm hängen bleibt, läuft der Watchdog ab --> Reset.

Das mit dem Interrupts ist so eine Sache.
Geht eigentlich nur mit einem NMI. Durch einen Stack oder Programmfehler können alle anderen Interrupts disabled werden.

Wenn deine Regelfunktion spinnt, weisst du nicht ob dieser Zähler noch bedient wird. Bleibt der Wert innerhalb des Fensters ....
Auch ein Counter innerhalb deines Interrupts kann z.B. durch einen falschen Zeiger überschrieben werden.

MfG Peter(TOO)

[damfino]

Die Motorsteuerung kannst auf die 2 µC aufteilen:
C2 übernimmt Steuerung der Motoren
C1 schaltet zB die Stromversorgung der Motoren frei.

Wenn jetzt der I2C Bus ausfällt kann C1 einfach alle Motoren abschalten.

Als Erkennung ob 2 µC arbeiten hatte ich mal folgendes im Einsatz: C1 schickt eine Zufallszahl an C2, C2 macht eine einfache Rechenoperation damit und schickt das Ergebnis wieder zu C1. C1 rechnet gleichzeitig das selbe und vergleicht die Ergebnisse.
Damit kann man meistens den Fall abfangen wenn C2 einen Stack Überlauf hat und nur mehr Mist rechnet.

[schorsch_76]

SS1.pdf

So hab ich mir das vorgestellt ...

Das untere AND sorgt dafür dass erst bei allen Bedingungen die Motoren eingeschalten werden können ... und zwar in Hardware. Wenn das einmal läuft, dann läuft es

Erklärung:
Das nachtriggerbare Monoflop und die Zwei Flankenerkennungen prüfen in Hardware, das der µC sein Togglebit von sich gibt.

Bsp. kann man so auch den Heartbeat von A->B auf so eine Abfrage setzen -> Zentral AND
Bsp. kann man so auch den Heartbeat von B->A auf so eine Abfrage setzen -> Zentral AND
Navigation von µC A ok: -> Ausgang zum Zentral AND
Endstufenlogik von µC B ok: -> Ausgang zum Zentral AND

Auch wie Peter schon sagte, watchdog zum neustarten wenn was schief läuft. Damit fallen dann die Eingänge des Zentral AND weg (Heartbeat A oder B) und egal was der andere µC macht, die Motoren stehen. Wenn das Zentral AND gefallen ist, kann man auch in Hardware dafür sorgen, dass beide µC verzögert einen Reset bekommen um neu anzufangen.

EDIT: Ok, ich seh gerade am Ausgang der Steigenden Flanke muss noch ein Inverter hin

Gruß
Georg

[Peter(TOO)]

Hallo Georg,

SS1.pdf

So hab ich mir das vorgestellt ...

Das untere AND sorgt dafür dass erst bei allen Bedingungen die Motoren eingeschalten werden können ... und zwar in Hardware. Wenn das einmal läuft, dann läuft es

Erklärung:
Das nachtriggerbare Monoflop und die Zwei Flankenerkennungen prüfen in Hardware, das der µC sein Togglebit von sich gibt.

Die Schaltung ist alt bekannt und hat aber einen Haken!

Wenn der µP durchdreht und nur noch das Bit toggelt, merkt keiner etwas!
Praktisch sollte man zweit Zeiten messen, eine Minimale und eine Maximale, entsprechend ergibt sich ein Frequenzbereich innerhalb dessen die Toggle-Frequenz liegen muss.

Die einfachen Watchdogs, also nur eine maximale Zeit, gibt es als fertiges IC, meistens zusammen mit eine Spannungsüberwachung als externer Reset-Generator.

Der TPS3813 hat sogar eine Fenster-Watchdog:
http://www.ti.com/lit/ds/symlink/tps3813k33.pdf

MfG Peter(TOO)

[Dirk]

Leute,

danke für alle Anregungen!

Ich denke, ich werde 3 Sachen machen:
1. Der Motorstrom wird zusätzlich auch noch durch µC 1 abschaltbar.
2. Beide µCs werden zusätzlich (zu I2C) noch mit 2 I/O-Pins verbunden und jeder µC toggelt ständig einen der Pins und wertet am anderen Pin das Toggeln des anderen µCs aus. Dabei wird eine untere und obere Grenzfrequenz definiert.
3. Beide µCs überwachen sich selbst per Watchdog.

So weit so gut, jetzt muss ich nur noch definieren, was ich in welchem Fehlerfall tun will und wie ich ggf. wieder zum Normalbetrieb zurückkommen kann und welche Fehlerbedingung zum kompletten OFF führt. Uff, viel Arbeit.