Methoden zum Erkennen einer Fehlerbedingung in Microcontroller-Systemen

Hi Spezialisten,

beim Bau von autonomen Robotern gibt es ab und zu das Problem, dass in einem Programm eine Fehlerbdingung auftritt. Das sollte es natürlich bei guter Programmierung nicht geben, aber auch Hardware-Probleme oder Ereignisse von außen könnten ein Programm z.B. zum "Absturz" bringen.

Ich habe derzeit ein Doppel-Prozessor-System, das via I2C verbunden ist. Das System soll wechselseitig feststellen, ob auf der jeweils anderen Seite alles ok ist und ob das Programm dort läuft.
Das habe ich schon umgesetzt durch einen "Heartbeat"-Prozeß, der Alarm gibt, wenn ein "Herzschlag" der anderen Seite nicht mehr bemerkt wird. Das setzt aber z.B. zumindest eine funktionierende I2C-Verbindung voraus, was auch gestört sein könnte.

Wenn z.B. ein Mars-Rover auf dem Mars herumfährt, muss er ja auch merken, wenn sich z.B. ein internes Teilsystem "aufhängt" und muss dann sicher stellen, dass z.B. die Kommunikation mit der Basisstation auf der Erde noch klappt oder Solarzellen zum Licht gedreht werden. Dann müßte er auch versuchen, das 1. System probeweise wieder "hochzufahren", um zu merken, ob es noch funktioniert.

Fragen über Fragen:
Was sind Methoden und Konzepte für so ein Sicherheitskonzept?
Braucht man immer dafür mind. ein ZWEITES Controller System oder gibt es auch eine Sicherheitsmethode für ein EINZELNES Controllersystem, damit es sich selbst überwacht?
Wie würdet ihr sowas programmieren?
Hat jemand das schon einmal gemacht?

Hallo Dirk,

Das einfachste ist ein Watchdog. Hat heute fast jeder µC mit drauf.

Bei der einfachsten Variante darf der Timer einfach nie ablaufen, andernfalls wird ein Hardware-Reset ausgelöst.

Nun kann aber das Programm so durchdrehen, dass es nur noch dauernd den Watchdog zurücksetzt :-(
Für diesen Fall gibt es eine verbesserte Variante, bei welcher das zurücksetzen innerhalb eines bestimmten Zeitfensters erfolgen muss.
Wird zu früh oder zu spät zurückgesetzt gibt es einen Reset.

Ein Problem ist natürlich der Aufwand und die Komplexität der ganzen Überwachung. Wird das System zu kompliziert, führt alleine dieses schon zu vermehrten Ausfällen.

Bei kritischen Systemen (z.B. Flugzeug) baut man alles 3-fach auf, hier liegt das Optimum.
Bei 3 System geht man dann davon aus, dass die Mehrheit recht hat. Auch die Aktoren sind 3-fach vorhanden, wobei jeder Aktor die nötigen Kräfte alleine aufbringen kann. Im Fehlerfall arbeiten dann zwei Aktoren gegeneinander und kompensieren sich Kräftemässig, der Dritte hat dann die eigentliche Arbeit!
Bei der Zivilluftfahrt hat man dann auch noch an mögliche Systematische Fehler gedacht. Jeder der 3 Rechner benutzt eine andere CPU-Architektur eines anderen Herstellers. Zudem wird alles von 3 unabhängigen Teams entwickelt, auch die Software. Damit versucht man zu verhindern, dass Architektur- oder Herstellungsfehler, auch der CPU, nicht auf allen 3 Systemen gleichzeitig auftreten können. z.B. hatte der 80386 anfänglich mehrere, temperaturabhängige Rechenfehler im 32-Bit Teil.

Das Spaceshuttle hatte 3 identische Rechner und einen Backuprechner zur Überwachung. die ersten 1 oder 2 Starts wurden verhindert, weil die Rechner nicht ganz synchron liefen und deshalb dauernd eine fehlerhafte Datenverarbeitung gemeldet wurde.

Die Leitstelle der BVB (Basler Verkehrs Betriebe) bestand in den 70er Jahren aus zwei PDP11. Einer kleineren, welche normalerweise die Arbeit machte und einer grösseren, welche die erste überwachte und im Fehlerfall die Arbeit der ersten übernahm.

Beim Mars-Rover wird natürlich Verschiedenes verwendet.
Wichtige Systeme sind, wenn möglich, mehrfach vorhanden, Ist auch eine Gewichts und Kostenfrage, weshalb man auch nicht alle Experimente doppelt mitnehmen kann.
Im Fehlerfall stoppt das Teil erst mal und fährt unwichtiges runter.
Das wichtigste ist dann die Funkverbindung, wenn die unterbrochen ist, werden erst mal die Antennen in die Grundposition gefahren und ausgerichtet.
Dann kann das Teil eine Menge an internen Spannungen, Strömen, Temperaturen, Positionen usw. messen und zwecks Analyse Richtung Erde funken.
Auch hat man verschieden Versorgungsspannungs-Busse und die Geräte können da unterschiedlich um- und abgekoppelt werden.
Festverdrahtet ist dann noch ein Monitorprogramm um das ganze Teil notfalls wieder hoch zu bekommen.
Für den Mars-Rover gab es übrigens zwei unterschiedliche Programme. Eines für den ganzen Flugbetrieb und eines für die Mission. Dasjenige für die Mission war irgendwo versteckt und komprimiert abgelegt. Nach der Landung wurde dann das Flugprogramm gelöscht und durch das eigentliche Missionsprogramm ersetzt.

MfG Peter(TOO)

Leider kenne ich mich auf dem Gebiet nicht so gut wie mein Vorredner (Vorschreiber) aus.
Aber: solange ein Mensch im Spiel ist können immer Fehler passieren - spätestens durch die Komplexität des Programms und der fehlenden Übersicht/Verständnis!
Ein Fehler, der mir nicht nur einmal unter gekommen ist:

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)

Apropos: ein schönes Beispiel für Menschliches Versagen - In den USA gab es mal ein Gerät names Therac 25 welches die Strahlendosis für die Bestrahlung von Menschen berechnen sollte - mindestens 3 Patienten starben durch einen Fehler im Programm (vom Mensch verursacht)...


Jetzt fällt mir doch noch so ein Unwort dazu ein: FMEA - Fehler Möglichkeiten Einfluss Analyse. Ein "Brainstorming" zur Betrachtung möglicher eintretender Fehler und dem Vorbeugen dieser.

Ansätze gibt es da ja einige, je nach Anforderung.
Bei Aktiv-Passiv Clustern, wird ein Heartbeat überwacht und wenn der Node mit dem Lead nicht mehr den Anforderungen genügt, bekommt die Software einen Reset verpasst, und ein anderer Node übernimmt den Lead.
Bei Aktiv-Aktiv Clustern kann entweder Synchon gearbeitet werden und die mehrheitlich identischen Ergebnisse entscheiden darüber welches Ergebniss als Fehlerhaft angesehen wird (Luftfahrt). oder es wird Lastverteilend je Node eine andere Aufgabe duchgeführt und pro Node laufen Watchdogs und Selbsttestroutinen.

Bei Raumfahrttauglichen Systemen, wird es noch mal ungleich schwieriger.
Da steht ja nur eine begrenzte Teileauswahl zur Verfügung.
Da fängt man schon an beim Schaltungsdesign Fehler zu vermeiden.
Elkos fallen flach, da im Vakuum das Elektrolyt per Dampfexplosion den Elko zerstören würde.
Alle Bautele werden auf Strahlungsfestigkeit ausgewählt (Abschirmung, Sruckturgröße und Werkstofftechnologie https://de.wikipedia.org/wiki/Silicon-on-Sapphire )
Und die Bauteile müssen in einem erweiterten Temperaturspektrum funktionsfähig sein (oft -55°C bis +150°C)
Es gibt sowohl von der NASA als auch von der ESA PDF Dokumente für freigegebene Bauteile.

Bei Speichern werden selbstkorrektur Möglichkeiten vorgesehen.
Auf Byte Ebene Paritätsbits, Dann ECC Hash für 2 Bit Fehler, Memory RAID (5) für größere Blöcke und doppelte Ausführung, (mirroring) um defekte Bits ersetzen zu können.
Als Backup System kommen auch teilweise diskret aufgebaute Command Sequenzer zum Einsatz, die festverdrahtete Programme abspulen.

Die NASA hat mit HAL/S dann noch eine eigene echtzeitfähige Programmiersprache.
http://www.brouhaha.com/~eric/nasa/h...g_in_hal-s.pdf

Zitat:

---

.. Die NASA hat mit HAL/S dann noch eine eigene echtzeitfähige Programmiersprache ..

---

HAL ? ? Gibts da ne Verbindung zum HAL auf der Discovery One (Kubrik bzw. Arthur C. Clarke) ? Hmmm, muss ich mal googeln.

Total OT: Seh' grad dass dies hier nicht mein 2001tes Posting, aber das siebentausendste ist. Oh Himmel wieviel Mist da dabei ist :-/
Da fällt mir zu HAL und IBM ein, dass man von letzteren auch nicht mehr viel hört.

Laut meiner Info nicht.

2001 - HAL9000 => IBM

I-1 = H
B-1 = A
M-1 = L

Hallo i_make_it,

HAL/S = High-order Assembly Language/Shuttle

Irgendwo in deinem NASA-Text, steht, dass ein verstorbener Freund Hal irgendwas Pate stand und das auch an HAL aus 2001 gedacht wurde ....

Sehr erfolgreich war HAL/S aber nicht.
Die On-Board Software des Space Shuttles ist ausschliesslich in HALL/S ausgeführt worden.
Das einzige andere Projekt ist die Höhenregelung des Galileo-System, welches teilweise HAL/S verwendet.
Das Deep Space Network verwendet teilweise HAL/S, aber nur am Boden.

Scheinbar wurde dann 1985 HAL/S von Ada überrannt.
Ada wurde da die Pflichtsprache für alle Aufträge des DoD.
Mittlerweile scheint auch bei der NASA alles in Ada programmiert zu sein. Macht im Prinzip auch Sinn, da DoD und NASA gemeinsame Ressourcen nutzen.

MfG Peter(TOO)

Zitat:

---

Zitat von Dirk

Was sind Methoden und Konzepte für so ein Sicherheitskonzept?

---

Bei modernen Controllern sind einige Sicherheitsfunktionen schon Build in.
Man muß sie nur einschalten/sinnvoll konfigurieren/nutzen.
Brown Out detection, damit bei Unterspannung keine falschen Ergebnisse oder Schaltzustände entstehen wird ein Reset ausgeführt.
Watchdog, damit bei Endlosschleifen/hängern ein Reset ausgeführt wird.
ECC memory, damit man erkennen kann das die Speicherzelle die man grade liest fehlerhafte Daten enthällt.

Will man mehr, muß man schon beim Hardare Design der Cotrollerkarte anfangen.
Man kann bestimmte Reaktionen in Hardware diskret implementieren und das Ergebniss als Digitalsignal auf einen Interrupteingang legen.
Damit kann das Programm im Interruptfall in eine ISR gezwungen werden, die prüft ob die internen Zustände zum externen Signal passend sind oder nicht.

Memory RAID geht halt nicht mit dem internen Speicher von µCs. Da muß man dann also ein Modell suchen, bei dem man vollständig auf externen Speicher wechseln kann.
Und diesen muß man dann mit allen Funktionen bauen. (addressierung, refresh, RAID Logik, etc.)

Zitat:

---

Zitat von Dirk

Braucht man immer dafür mind. ein ZWEITES Controller System oder gibt es auch eine Sicherheitsmethode für ein EINZELNES Controllersystem, damit es sich selbst überwacht?

---

Nicht zwingend.
Interne Softwarelösungen gehen aber immer auf die Systemperformance.
Ein zweites oder drittes externes System kann parallel zum ersten arbeiten und so die Systemzykluszeit kurz halten.

Zitat:

---

Zitat von Dirk

Wie würdet ihr sowas programmieren?

---

Gar nicht.
Da holt man eine zweiter Person, damit man den Denkfehler den man beim ersten System eingebaut hat und der später mal den Fehler verursachen wird, nicht auch in das Sicherheitssystem einbaut.
solche Sicherheitssysteme werden gerne von getrennten Teams entweickelt, die auch nicht direkt miteinander komunizieren, damit sie sich nicht gegenseitig beeinflussen können.

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?

wenn 1-4 ausgechlossen werden können, dann würde ich so vorgehen wie du (und mache es auch bereits so):
a) Multitasking-Betriebssystem, pre-emptiv (!!), mit hochrangigem Emergency-Stop-Task (bei mir: Raspberry Pi mit hochrangigem pthread-Task)
b) bei Fernsteuerung Heartbeat und für jede einzelne Fernsteuer-Message Checksum + acknowledge
c) bei Verbindungsproblemen sofortiger Notstopp
d) bei Kommunikationsproblemen nach 2 sek. Notstopp (hängt ntl. vom genauen Einsatzgebiet ab)
e) bei Battery-Low sofortiger Notstopp
f) bei Emergency-Button-Press sofortiger Notstopp
g) bei Anstoßen mit > 2G (hängt auch vom genauen Einsatzgebiet ab) in 3 Dimensionen (Accelerometer): sofortiger Notstopp
h) ein 2. Pi oder Arduino, der nur die internen Notstoppbedingungen parallel per Endlos-Loop überwacht sowie als Zusatzinput auch Heartbeat und Kommunikationsfehler übermittelt bekommt und dann direkt die Haupt-Spannungsversorgung z.B. mit 3 sek. delay per Relais kappt (Zeit hängt auch wieder vom genauen Einsatzgebiet ab).

Das aber auch nur, wenn selbst im schlimmsten Fall keine Gefährdung Dritter möglich ist, also nur im eigenen Haus oder eigenem, abgegrenztem, nicht öffentlich zugänglichem Grundstück (ich denke da an meinen Rasenmäher-Robot, den ich z.B. niemals beim Nachbarn einsetzen würde).

Ansonsten Finger weg von solchen Projekten.

Hallo,

Zitat:

---

Zitat von HaWe

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?

In diesen Fall, kann man meist relativ einfach Parameter überwachen und im Störungsfall alles blockieren.
z.B. eine Hausheizung geht einfach auf Störung und die Bude wird kalt. Einer merkt dies dann und bestellt den Techniker. Bei einem nur zeitweise bewohnten Ferienhaus sieht es schon etwas anders aus. Wenn da gerade keiner wohnt, wird die Störung nicht bemerkt und es können dann Wasserleitungen einfrieren und platzen. Hier kann man mit unabhängigen Sekundärsystemen, wie z.B. Rohrheizung, arbeiten.

Bei einem Flugzeug kann man aber nicht einfach rechts ranfahren und den ADAC verständigen.

MfG Peter(TOO)

- - - Aktualisiert - - -

Zitat:

---

Zitat von i_make_it

Will man mehr, muß man schon beim Hardare Design der Cotrollerkarte anfangen.

---

Hier steckt da ein weiteres Problem:
Die Ausfallwahrscheinlichkeit eines Systems steigt mit dessen Komplexität.
z.B. ist jede Lötstelle eine potentielle Fehlerquelle. Je mehr Lötstellen um so eher ist kommt es zu einem Ausfall.
Irgendwann wird dann das System so Komplex, dass die zusätzliche Sicherheit es unsicher macht.

Zitat:

---

Zitat von i_make_it

Memory RAID geht halt nicht mit dem internen Speicher von µCs. Da muß man dann also ein Modell suchen, bei dem man vollständig auf externen Speicher wechseln kann.
Und diesen muß man dann mit allen Funktionen bauen. (addressierung, refresh, RAID Logik, etc.)

---

... und schon spielen die Lötstellen eine grössere Rolle, wie auch jedes zusätzliche Bauteil :-(.

Zitat:

---

Zitat von i_make_it

Da holt man eine zweiter Person, damit man den Denkfehler den man beim ersten System eingebaut hat und der später mal den Fehler verursachen wird, nicht auch in das Sicherheitssystem einbaut.
solche Sicherheitssysteme werden gerne von getrennten Teams entweickelt, die auch nicht direkt miteinander komunizieren, damit sie sich nicht gegenseitig beeinflussen können.

---

Diesen Fehler hatte Micro Soft bei Windows NT gemacht.
NT sollte eines der sichersten Betriebssysteme werden, weshalb man sich David N. Cutler als Chef holte. Eigentlich erreichte der Kernel auch alle Sicherheitsanforderungen, nur haben die MS-Programmierer dann, wie bei MS üblich, direkte Kernelaufrufe in ihren Programmen verwendet und so alles zu Nichte gemacht, worauf Cutler das Handtuch warf.
Bis etwa Win95 konnten MS-Programme Dinge, welche über das offizielle API gar nicht möglich waren. Es gab dazu eine Menge undokumentierte API-Aufrufe, teilweise auch direkt in den Kernel. Teilweise wurde auch direkt auf undokumentierte interne Datenstrukturen zugegriffen. Damals gab es auch Programme, welche Programme auf solche undokumentierte Aufrufe untersucht haben. Deswegen gab es auch einen Rechtsstreit mit MS.

Manche offiziellen Bugfixes von MS funktionierten auch nach dieser Art. z.B. gab es bei Win3.x einen Fehler im COM-Treiber: Die Abfrage auf Veränderung der Statusleitungen funktionierte nicht. Dadurch wurden auch keine Interrupts in einem solchen Fall ausgelöst. Der Bugfix bestand darin, direkt auf die interne Datenstruktur zuzugreifen und zwar einige Bytes hinter des offiziellen Struktur. MS garantierte auch, dass dies auch in späteren Win-Versionen funktioniert, was auch eingehalten wurde.
Im Win DDK war der Assembler Source-Code des Treiber vorhanden. Der Bug bestand in der Verwechslung zweier UART-Register, davon waren total 4 Source-Zeilen betroffen. Von MS gab es aber nie ein Update dieses Treibers :-( Und wenn ich mich richtig erinnere, war der Bug auch in Win95 noch enthalten.

MfG Peter(TOO)

Zitat:

---

Zitat von Peter(TOO)

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.

Zitat:

---

Zitat von Peter(TOO)

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.

Zitat:

---

Zitat von Peter(TOO)

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.

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)

Zitat:

---

Zitat von erik_wolfram

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.

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

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

Hallo Leute,

Zitat:

---

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

Zitat:

---

Zitat von Peter(TOO)

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

---

Zitat:

---

Zitat von Dirk

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.

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.

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.

Zitat:

---

Zitat von Dirk

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)

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.

Anhang 31458

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

Hallo Georg,

Zitat:

---

Zitat von schorsch_76

Anhang 31458

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)

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.