Methoden zum Erkennen einer Fehlerbedingung in Microcontroller-Systemen

[i_make_it]

Die Ausfallwahrscheinlichkeit eines Systems steigt mit dessen Komplexität.

Das ist ja überall so. Hat man z.B. eine Festplatte mit einer MTBF von 100.000 Stunden, hat man im Schnitt alle 11 Jahre einen Ausfall.

Hat man 450 Server mit je 9 Festplatten und einer MTBF von 100.000 Stunden, hat man statistisch jeden Tag einen Ausfall.
Beim ENIAC wurde aber schon gezeigt mit welchen Gegenmaßnahmen man das Problems des Bauteilausfalls minimieren kann.
Wegen des häufigen Ausfalls der über 17.000 Elektronenröhren wurden stärkere Röhren benutzt und nur mit 10% ihrer Nennleistung betrieben.

In der Raumfahrt werden auch heute noch Halbleiterbauteile mit Strukturbreiten genutzt die viel größer sind als bei terrestrischem Einsatz.

z.B. ist jede Lötstelle eine potentielle Fehlerquelle. Je mehr Lötstellen um so eher ist kommt es zu einem Ausfall.

Lötstellen stellen in der militärischen Luftfahrt und in der Raumfahrt wegen Vibrationen etc. sowieso Probleme da.
Eine Möglichkeit ist das Hartlöten z.B. Mit Laser (um die thermische Belastung der Bauteile gering zu halten)
und das Schweißen wie es auch beim Verbinden eines Die mit den Pins genutzt wird.

Ein prozessicheres Lötverfahren anstelle von Handlötung ist üblicherweise der erste Schritt da die Fehlerträchtigkeit zu verringern.

Ein wichtiger Punkt fehlt noch:
5) Kann das System im Fehlerfall einfach abgeschaltet werden?

Ja und nein. Das sollte unbedingt ein Punkt sein der wo auch immer es geht konstruktiv gelöst werden soll und nicht in Software.
Denn bei einem Fehlerfall der zu einem Spannungsverlust führt, kann die Software nichts mehr machen.
Bei Kernreaktoren, werden die Steuerstäbe z.B. durch elektromagnetisch, gegen Federkraft geschlossene klauen gehalten.
Bei Spannungsausfall öffnen die Federn die Klauen und den Rest erledigt die Schwerkraft.
Bei allen Reaktortypen die diese Feature nicht haben, kam es bisher schon zu mindestens einem GAU
Z.B. Fukushima hat motorisch angetrieben Steuerstäbe die von unten eingefahren werden.
Nach dem der Notstromdiesel, der ebenerdig zwichen Meer und Reaktorgebäude Stand, genauso wie das Trafohaus abgesoffen war, konnte keine Software mehr auf Fehler reagieren.
Die Notakkus reichten nicht aus um die Motoren der Steuerstäbe zu betreiben, nur um die Sensorik am laufen zu halten.
Und die Fehlkonstruktion des Reaktortyps hat den Rest verhindert.
Tschernobyl hatte zwar die richtige Bauweise der Steuerstabhalterung, aber aus welchem Irrsinn auch immer waren die Spitzen aus Graphit, was als Moderator genau das Gegenteil eines Steuerstabes bewirkt.
Das gleichzeitige Abwerfen aller Steuerstäbe löste also die Kernschmelze aus, da das Graphit den Reaktor so hoch fuhr, das die Steuerstäbe mit ihrem dämpfenden Effekt zu spät kamen.
Das Beispiel ist jetzt zwar weit hergeholt, zeigt aber das Fehlervermeidung und Fehlertolleranz ein sehr weites Thema sind.


Vom "einfachen" Watchdog in einem µC über Multitasking mit Diagnosetasks, spezieller Hardware um Speicherfehler und Rechenfehler zu vermeiden/erkennen, bis hin zur sicheren Abschaltung von kompletten Systemen und Anlagen ist halt eine Menge möglich und vieles muß individuell der Aufgabenstellung entsprechend ausgeführt werden.

[Peter(TOO)]

Hallo,

Nachdem wir den TE erfolgreich vertrieben haben
Noch ein praktischer Tipp:

Bei allen Daten die von Aussen kommen (Datenpakete, Eingaben, Sensoren) zuerst eine Plausibilitätsprüfung machen. Sind die Daten ausserhalb des gültigen Bereichs muss man gar nicht erst rechnen und Unter/Überläufe oder Divisionen mit 0 riskieren, welche dann zu komplett falschen Resultaten führen können.
(Dies war der Trick von SASSER, da wurde ein zu grosser Datenblock gesendet, welcher dann, ohne Grössenüberprüfung in einen zu kleinen Puffer kopiert wurde.)
Entsprechend kann es auch sinnvoll sein, die Resultate einer Berechnung zu Überprüfen.

Eine entsprechende Prüfung sollte auch an den Grenzen von Modulen stattfinden.

Traue keinen Daten, auch wenn du dich selbst verrechnet hast!

Wichtig ist auch Unter/Überläufe schon bei der Entwicklung zu erkennen. Dies wird gerne bei Ausdrücken wie
(a*b)/c
übersehen. Das Resultat liegt im Bereich der Variablen, aber das Produkt a*b kann den Bereich überschreiten.
Hier hilft eben auch der Rangecheck. welcher überprüfen kann, dass a und b keine zu grossen Werte annehmen können.

Damit bekommt man schon einmal relativ stabile Software hin, welche nicht blöd rumrechnet und dadurch zu Abstürzen führt.

MfG Peter(TOO)

[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).

[schorsch_76]

Der mars Rover wurde bsp. viel in C++ Programmiert. Hier ein Vortrag des Programmierers auf Youtube
https://www.youtube.com/watch?v=3SdSKZFoUa8

[Dirk]

Hallo Leute,

... ja, die Fragen, die sich stellen, sind doch:
1) ist es nur eine Spielerei oder ein kommerzielles Produkt (Ausschluss-Kriterium!)?
2) können unabhängig davon beim Betrieb Menschen oder andere Lebewesen gefährdet oder geschädigt werden?
(direkt oder indirekt, z.B. auch im Straßenverkehr, auf öffentlichen Wegen und Plätzen)
3) können erhebliche Schäden an fremden Gegenständen auftreten (Betrieb in und außer Haus)?
4) besteht ggf generell eine Gefährdungshaftung, sodass eine Haftpflichtversicherung abgeschlossen werden muss?
Ein wichtiger Punkt fehlt noch:
5) Kann das System im Fehlerfall einfach abgeschaltet werden?

danke für die vielen Infos.

Ich ersuche es mal mit Antworten:
1) Nein, es ist nicht ein kommerzielles Produkt, sondern ein autonomer Roboter mit 2 µC-Systemen.
2) Ja, das Ding wiegt ca. 18 kg und fährt durch eine Glasscheibe, wenn im Weg.
3) Ja, möglich.
4) Nein.
5) Ja, das wäre nicht das Ziel! Es müßten stattdessen alle 6 Motoren (gesteuert vom 2. System) abgebremst bzw. gestoppt werden. Danach müßte gecheckt werden, ob das 2. System wieder hochgefahren werden kann und anschließend sollte es auf Kommandos des Hauptsystems (1.) wieder reagieren oder -falls das nicht möglich ist- ein Notprogramm fahren.

[i_make_it]

Hallo,
5) Kann das System im Fehlerfall einfach abgeschaltet werden?

5) Ja, das wäre nicht das Ziel! Es müßten stattdessen alle 6 Motoren (gesteuert vom 2. System) abgebremst bzw. gestoppt werden. Danach müßte gecheckt werden, ob das 2. System wieder hochgefahren werden kann und anschließend sollte es auf Kommandos des Hauptsystems (1.) wieder reagieren oder -falls das nicht möglich ist- ein Notprogramm fahren.

Ui, Königsdisziplin.

Fall I: µC A hat einen Fehler
Wie verhindert µC B das von µC A noch Steuersignale an die Motortreiber gesand werden die zusammen mit den Signalen von µC B komplett falsche Steuerbefehle ergeben.

Fall II: µC A Funktioniert aber µC B hat ein Problem.
µC B trennt µC A von den Motortreibern und schickt falsche Signale. Wie kann µC A µC B von den Motortreibern trennen?

Fall III: Wie Fall (I)
Aber µC A kommt durch Summierung mehrere Fehler zu dem Schluß das er derjenige ist, der richtig funktioniert. Infolge dessen trennt er µC B von den Motortreibern und es kommt zum Crash.

Damit kommt man bei dem in der Luftfahrt angewandtem System der Mehrheitsentscheidung an.
Also 3 Steuerungen und annehmen , das immer nur eine auf einmal falsch liegt. (hat bei dem Air France Absturz über dem Südatlanktik nicht funktioniert, da die 2 vereisten Pivotrohre 2 Systemen den selben fehlerhaften Messwert geliefert haben und so die Entscheidung zu ungunsten des einzig richtig funktionierenden Sensors viel.)
In der überwiegenden Mehrheit der Fälle hat sich das System aber bewährt.

[schorsch_76]

Was machen µC A und B? Sind die schon redundant oder haben die verschiedene Aufgaben?

EDIT: Ok, System B hat die Regelungsaufgabe der Motoren. A nicht.

Was du willst ist praktisch SS1. Siehe
https://de.wikipedia.org/wiki/Sicherheitsfunktion

Siehe Siemens
http://www.industry.siemens.com/topi...name=functions

- - - Aktualisiert - - -

Eine halbwegs einfache Idee:
Wenn es sich bei den Motoren um Gleichstrommotoren handelt, kann durch Kurzschließen der Spule eine Bremswirkung erzeugt werden. (Generatorbetrieb)
Ist alles in Ordnung, verbinden die Relais die Motoren mit der Antriebsendstufe. Im Fehlerfall ist der Motor kurzgeschlossen. Das lässt sich auch redundant machen.

Die Erkennung des Betriebszustandes der Steuerung und damit die Ansteuerung der Relais müsste dann das folgende machen:
* Jeder µC Watchdog. (Ausgang "alive" setzen, bzw Toggeln. Die Toggelfrequenz durch externe einfache Logikbausteine abfragen. Toggelt der Ausgang nicht regelmässig => µC hat ein Problem
* Prüfen des Status der benötigten Komponenten. Navigation etc pp.
* Ist der andere µC i.O? Heartbeat und andere Kontrollalgorithmen. Bsp: IMU + GPS: Stimmen die Werte beider CPUs überein?
*

Diese Bedingungen über Hardwaregatter "verunden" und die Freigabe der Endstufen steuern.

[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)