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.