News Der Watchdog – oder wie strande ich nicht im Weltall?


von Til S. (Firma: SEGGER) (til_s)


Angehängte Dateien:

Lesenswert?

Clementine war ein Satellit der NASA, mit dem Sensoren und andere Komponenten einem Dauertest im Weltall unterzogen werden sollten. Der Satellit wurde am 25. Januar 1994 gestartet und ging aufgrund technischer Schwierigkeiten am 7. May 1994 verloren. Wie sich später herausstellte, hätten ein paar Zeilen Code für einen Watchdog die Mission retten können.

Clementine hatte für rund zwei Monate erfolgreich den Mond vermessen. Sie verließ den Mondorbit, um zum nächsten Ziel, dem erdnahen Asteroiden Geopgraphos zu navigieren. Kurz darauf trat ein Fehler in einem der Boardcomputer auf, der die Steuerung des Satelliten behinderte, während eines der Triebwerke aktiv war. Die NASA versuchte 20 Minuten lang, die Kontrolle wieder zu erlangen, was aber erst durch einen Hardware-Reset erreicht wurde. Aber es war zu spät: Der Satellit hatte bereits seinen ganzen Treibstoff verbraucht und die Mission konnte nicht weitergeführt werden.

Wie hätte ein Watchdog helfen können?

Ein Watchdog ist ein Stück Hardware, welches entweder direkt in den Mikrocontroller integriert oder als eigenständiges Bauteil extern mit dem Mikrocontroller verbunden ist. Seine Aufgabe ist die Fehlerbehandlung (üblicherweise ein Hardware-Reset) wenn sicher angenommen werden kann, dass das System nicht mehr wie gewünscht ausgeführt wird. Die Hauptkomponente eines Watchdogs ist ein Zähler, der mit einem bestimmten Wert initialisiert wird und in Richtung 0 zählt. Anschließend ist die Software dafür verantwortlich, diesen Zähler immer wieder auf den Startwert zurückzusetzen. Sobald der Zähler den Wert 0 erreicht, wird ein Fehlerzustand angenommen und üblicherweise ein Reset durchgeführt. Der Watchdog ist damit die letzte Rettung wenn alles andere schief gelaufen ist. Es wäre auch die Rettung für Clementine gewesen.

Wie wird der Watchdog gefüttert?

Es ist nicht immer einfach, zu entscheiden, an welchen Stellen in der eigenen Software der Zähler zurückgesetzt werden muss (oft auch "Watchdog füttern" genannt). Entwickler müssen den Startwert des Watchdog-Zählers sehr genau wählen, damit der Watchdog bereits zuschlagen kann, bevor das System Schaden nimmt. In einfachen Applikationen ohne RTOS füttern Entwickler den Watchdog gerne in der main() Schleife. Das setzt voraus, dass der initiale Watchdog-Zählerwert größer ist, als die maximale Ausführungszeit der main() Schleife. Das ist meistens ausreichend: Während es für manche Systeme wichtig ist, dass sie sich sofort von einer Fehlersituation erholen, reicht es für andere System aus, dass sie nicht unendlich lang in dem Fehlerzustand verharren - und dieser Ansatz erfüllt die Aufgabe.

Und wie funktioniert das mit einem RTOS?

In einer komplexen Applikation mit einem RTOS kann es passieren, dass einzelne Threads nicht mehr ordnungsgemäß ausgeführt werden, während andere Threads noch laufen. Es kann aber auch Threads geben, für die es korrekt ist, wenn sie für längere Zeit nicht ausgeführt werden. Ein Netzwerk-Thread könnte z.B. für längere Zeit auf neue Nachrichten warten und bis zu deren Eintreffen nicht ausgeführt werden. Die Herausforderung besteht darin, eine Methode zu entwickeln, mit welcher der Watchdog gefüttert wird, sodass sichergestellt ist, dass jeder einzelne Thread noch korrekt ausgeführt wird. Dabei müssen die folgenden Anforderungen erfüllt werden:

  1. Wird das RTOS noch korrekt ausgeführt?
  2. Gibt es hochpriore Threads, die zuviel Rechenzeit verbrauchen und damit verhindern, dass niedrigpriore Threads ausgeführt werden?
  3. Verhindert ein Deadlock die Ausführung einzelner Threads?
  4. Werden alle Threads vollständig und korrekt ausgeführt?
  5. Die Implementierung und die nötigen Änderungen an der Applikation müssen Ressourcen sparend und möglichst wenig intrusiv sein.

Eine Methode zur Lösung dieser Aufgabe muss also jeden Thread einzeln überwachen. Wird festgestellt, dass ein Thread nicht mehr korrekt ausgeführt wird, können verschiedene Aktionen ausgeführt werden: Manche Applikation müssen, bevor ein Reset durchgeführt wird, das System in einen sicheren Zustand bringen. Das kann z.B. bedeuten, dass ein Ausgang gesetzt wird, um ein Ventil zu schließen. Anschließend kann der eigentliche Reset durchgeführt werden, der durch das Ablaufen des Watchdog-Zählers oder manuell ausgelöst werden kann. Für Letzteres besitzen viele Mikrocontroller ein dediziertes Register.

Eine einfache Implementierung könnte ein Bitarray vorsehen, mit je einem Bit für jeden Thread. In einem festen Zeitintervall wird geprüft, ob alle Bits gesetzt sind. Falls ja, werden alle Bits gelöscht und der Watchdog gefüttert. Andernfalls wird ein Reset durchgeführt. Ein laufender Thread setzt hierzu sein Bit in dem Bitarray. Damit weiß das System, ob in einem Zeitintervall alle Threads mindestens einmal ausgeführt worden sind.

#define THREAD1     (1u << 0)
#define THREAD2     (1u << 1)
#define THREAD_ALL  (THREAD1 | THREAD2)

char WatchdogFlag;

void Thread1(void) {
  while (1) {
    WatchdogFlag |= THREAD1;
    DoSomething()
    Delay(50);
  }
}

void Thread2(void) {
  while (1) {
    WatchdogFlag |= THREAD2;
    DoSomethingElse()
    Delay(200);
  }
}

__interrupt void TimerInt(void) {
  if (WatchdogFlag != THREAD_ALL) {
    PerformCPUReset();
  } else {
    WatchdogFlag = 0u;
    FeedWatchdog();
  }
}

Diese Methode hat den Nachteil, dass das Zeitintervall auf die maximale Ausführungszeit des längsten Threads eingestellt werden muss. Aus diesem Grund bieten moderne Betriebsysteme, wie etwa SEGGER RTOS embOS, die Möglichkeit, über eine einfache Watchdog-API für jeden Thread eine spezifische Ausführungszeit zu definieren.

void Thread1(void) {
  OS_WD_Add(&WatchdogHP, 50);
  while (1) {
    OS_WD_Trigger(&WatchdogHP);
    DoSomething()
    OS_Delay(50);
  }
}

void Thread2(void) {
  OS_WD_Add(&WatchdogLP, 200);
  while (1) {
    OS_WD_Trigger(&WatchdogLP);
    DoSomethingElse()
    OS_Delay(200);
  }
}

__interrupt void TimerInt(void) {
   OS_WD_Check();
}

Schlussfolgerung

Schon in der Anfangsphase eines Projektes sollte ein Watchdog in Betracht gezogen werden - und die Werkzeuge, die einem bei dieser Aufgabe helfen können. Denn wer will schon im Weltall verloren gehen?


: Bearbeitet durch Admin
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Til S. schrieb:
> Schon in der Anfangsphase eines Projektes sollte ein Watchdog in
> Betracht gezogen werden
Man sollte nach einem Reset dann aber auch auf den Watchdog-Reset 
reagieren. Und nicht erwarten, dass der Watchdog den Fehler schon 
irgendwie beheben und der "bellende Wachhund den Einbrecher vertreiben" 
wird. Denn allein durch den beherzten Eingriff des Watchdogs ist der 
eigentliche Fehler im Programmablauf ja nicht behoben.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Vollkommen richtig! Eigentlich sogar noch besser vor dem Reset, weil man 
dort evtl. noch mehr Informationen über das System hat. Das ist mit 
einem Hardware Watchdog möglich, wenn es in dem Device einen Watchdog 
Interrupt gibt. Bei einem RTOS wie embOS gibt es dafür eine Callback 
Funktion, die vor dem eigentlich Reset aufgerufen wird. Dort kann das 
System in einen sicheren Zustand gebracht und z.B. Daten in eine 
Logdatei geschrieben werden. Was man konkret macht, ist natürlich von 
der Applikation abhängig.

von Martin S. (strubi)


Lesenswert?

Ziemlich dreiste Schleichwerbung, mit Verlaub. Dass damit auch noch 
quasi suggeriert wird, das betr. RTOS sei für höhere Anforderungen an 
Zuverlässigkeit geeignet, oder hätte gar das Clementine-Problem gelöst, 
ist schon etwas plump bis voll daneben.
Erinnert irgendwie an die immer dreisteren Machenschaften an der 
Embedded World Conference: da dürfen jedes Jahr die üblichen 
Verdächtigen, die auf der Sponsorenliste stehen, ihren alten Kaffee 
'akademisch' neu verpackt anbieten.

von Nils P. (torus)


Lesenswert?

Das erste Codebeispiel hat eine üble Race-Condition auf der Variable 
WatchdogFlag.

Just saying.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Martin S. schrieb:
> Ziemlich dreiste Schleichwerbung, mit Verlaub.

ACK

Übrigens hat Clementine ihre primäre Mission voll erfüllt. Es ist 
ausserdem zu bezweifeln, daß das US Verteidigungsministerium ein damals 
gerade mal 2 Jahre auf dem Markt befindliches Unternehmen aus DE 
beauftragt hätte, ihnen die Software zu schreiben. Deswegen von mir -1.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Martin S. schrieb:
> Dass damit auch noch
> quasi suggeriert wird, das betr. RTOS sei für höhere Anforderungen an
> Zuverlässigkeit geeignet, oder hätte gar das Clementine-Problem gelöst,
> ist schon etwas plump bis voll daneben.

Nein, in dem Artikel geht es um den Watchdog im Allgemeinen (und, das 
man sich bei einem RTOS noch ein paar mehr Gedanken machen muss). Und 
wenn ich aus der Quelle zitieren darf:
> The 1750's built-in watchdog timer hardware was not used, over the
> objections of the lead software designer. With no automatic "reset"
> button, success of the mission rested in the abilities of the controllers
> on Earth to detect problems quickly and send a hardware reset. For the
> lack of a few lines of watchdog code the mission was lost.

Ein Watchdog hätte also die weitere Mission retten können, nicht ein 
RTOS.
Ein RTOS kann aber ein Werkzeug von vielen sein, dass einem dabei hilft.

Und btw. nicht der Artikel suggeriert das embOS für höhere Anforderungen 
an Zuverlässigkeit geeignet ist, sondern das IEC 61508 Zertifikat ;-).

Jetzt mal im Ernst: Ich möchte in diesen Artikeln gerne über technische 
Aspekte von RTOS sprechen. Das ich mich dabei auf embOS beziehe, liegt 
daran, dass ich mich damit am besten auskenne. Und natürlich ist das 
dann indirekt auch ein bisschen Marketing. Über konstruktive Kritik 
freue ich mich immer aber ansonsten ist ja keiner gezwungen, die Artikel 
zu lesen ;-).

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Martin S. schrieb:
> Ziemlich dreiste Schleichwerbung, mit Verlaub.
Naja, von "schleichen" sehe ich da keine Spur.

Nils P. schrieb:
> Das erste Codebeispiel hat eine üble Race-Condition auf der Variable
> WatchdogFlag.
Ja, da könnte es bei einer Unterbrechung des VerODERns tatsächlich dazu 
kommen, dass fälschlicherweise das Bit des anderen Threads mit einer 1 
zurückgeschrieben wird.
In der Praxis wird sich dieser Fehler aber mit vermutlich nicht 
auswirken, denn beim nächsten Watchdogzyklus wird das mit an Sicherheit 
grenzender Wahrscheinlichkeit wieder geradegezogen.
Zum Glück...

Til S. schrieb:
> Aus diesem Grund bieten moderne Betriebsysteme, wie etwa SEGGER RTOS
> embOS, die Möglichkeit, über eine einfache Watchdog-API für jeden Thread
> eine spezifische Ausführungszeit zu definieren.
Im Allgemeinen sollte es beim Watchdog nicht auf die Millisekunde 
ankommen. Ob der Watchdog nach 50ms oder nach 500ms kommt, ist 
prinzipiell egal, denn ein Programmierer sollte sich niemals auch nur in 
Gedanken auf den Watchdog als letzten Notnagel "verlassen".
Das ist wie wenn man fährt wie Henker und sagt: im Notfall gibt es ja 
die Leitplanke!

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Lothar M. schrieb:
>> Das erste Codebeispiel hat eine üble Race-Condition auf der Variable
>> WatchdogFlag.
> Ja, da könnte es bei einer Unterbrechung des VerODERns tatsächlich dazu
> kommen, dass fälschlicherweise das Bit des anderen Threads mit einer 1
> zurückgeschrieben wird.

Stimmt, danke! Aber deswegen ist es ja auch nur ein Beispiel, um den 
Sachverhalt zu erläutern. Ich denke, die meisten Leser verstehen, was 
damit gemeint ist. Ich hoffe es kommt nicht der Nächste an, um zu sagen, 
dass es ja gar nicht linkt, weil DoSomethingElse() nicht implementiert 
ist... ;-).

Lothar M. schrieb:
> Im Allgemeinen sollte es beim Watchdog nicht auf die Millisekunde
> ankommen. Ob der Watchdog nach 50ms oder nach 500ms kommt, ist
> prinzipiell egal, denn ein Programmierer sollte sich niemals auch nur in
> Gedanken auf den Watchdog als letzten Notnagel "verlassen".
> Das ist wie wenn man fährt wie Henker und sagt: im Notfall gibt es ja
> die Leitplanke!

Jain, bei einem reinen Watchdog, bei dem es nur darum geht, dass System 
zu reseten, damit es nicht unendlich hängt, hast du natürlich völlig 
Recht. Es kann aber durchaus entscheidend sein, dies zeitnah zu 
erkennen, weil das System ansonsten in einem unsicheren Zustand ist. 
Wenn ich also weiß, dass eine Task immer alle 10 msec ausgeführt werden 
muss, und alle Zeiten über z.B. 11 msec für mich kritisch sind und einen 
Fehler bedeuten, kann ich einen Software Watchdog entsprechend 
konfigurieren. Bei Safety Critical Applikation muss man z.B. 
sicherstellen, dass alle Anwendungsteile noch ordnungsgemäß ausgeführt 
werden. Das hat dann nicht mehr direkt etwas mit dem Hardware Watchdog 
zu tun aber auch dafür könnte man solche "Software Watchdogs" benutzen. 
Aber das ist ein anderes Thema und führt hier zu weit.

von Martin S. (strubi)


Lesenswert?

Lothar M. schrieb:
> Naja, von "schleichen" sehe ich da keine Spur.

Dann würde die Randnotiz "Sponsored content" das ganze etwas treffender 
kennzeichnen. Sonst läufts wie beim Google-Search: Die ersten drei 
Treffer kann man überspringen.

Til S. schrieb:
> Ein Watchdog hätte also die weitere Mission retten können, nicht ein
> RTOS.
> Ein RTOS kann aber ein Werkzeug von vielen sein, dass einem dabei hilft.

Ich sehe das anders: die meisten RTOS sind da eher hinderlich.
Und es gibt eine Menge Watchdog-Architekturen, die sich per 
Glitch-Attacken zum Aufhängen bringen lassen. Und im All gibt's eine 
Menge natürlicher Glitches..

Til S. schrieb:
> Jetzt mal im Ernst: Ich möchte in diesen Artikeln gerne über technische
> Aspekte von RTOS sprechen. Das ich mich dabei auf embOS beziehe, liegt
> daran, dass ich mich damit am besten auskenne. Und natürlich ist das
> dann indirekt auch ein bisschen Marketing. Über konstruktive Kritik
> freue ich mich immer aber ansonsten ist ja keiner gezwungen, die Artikel
> zu lesen ;-).

Ja, auch im Ernst: Ich würde in diesem Falle deutlich mehr 
Beitragsqualität erwarten, oder wenigstens etwas Innovation. Und v.a. 
ein Fokus auf eine failsafe-Architektur, immerhin hat Herr Ganssle den 
Aspekt auf CPU-Ebene angesprochen.
Die Brücke vom Fall Clementine zum proprietären RTOS steht diesbezüglich 
auf etwas schwachen Füssen und die Darbietung von oben hinterlässt dann 
eben ein Gschmäckle.

Sinnvoll und konstruktiv finde ich Diskussionen wie diese hier:
Beitrag "Microcontroller-Sicherheit in MIL-Systemen durch FPGAs erhöhen"

von batman (Gast)


Lesenswert?

Til S. schrieb:
> Stimmt, danke! Aber deswegen ist es ja auch nur ein Beispiel, um den
> Sachverhalt zu erläutern. Ich denke, die meisten Leser verstehen, was
> damit gemeint ist. Ich hoffe es kommt nicht der Nächste an, um zu sagen,

Ja, sie verstehen, daß jemand einen Fehler gebaut hat und ihn dann 
runterspielen will. :)

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Martin S. schrieb:
> Dann würde die Randnotiz "Sponsored content" das ganze etwas treffender
> kennzeichnen. Sonst läufts wie beim Google-Search: Die ersten drei
> Treffer kann man überspringen.

Könnte man machen, wenn es gesponsert wäre...ist es aber nicht. Andreas 
hat mir kein Geld gezahlt und ich ihm auch nicht ;-).

Martin S. schrieb:
> Ich sehe das anders: die meisten RTOS sind da eher hinderlich.
> Und es gibt eine Menge Watchdog-Architekturen, die sich per
> Glitch-Attacken zum Aufhängen bringen lassen. Und im All gibt's eine
> Menge natürlicher Glitches..

Ok, dann lass gerne darüber diskutieren. Freut mich, dass du dir über 
die Thematik Gedanken machst. Letztlich geht es ja auch darum, eine 
Diskussion anzuregen. Inwieweit siehst du ein RTOS anstelle einer 
Superloop bezüglich eines Watchdogs hinderlich?

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

batman schrieb:
> Ja, sie verstehen, daß jemand einen Fehler gebaut hat und ihn dann
> runterspielen will. :)

Mit sie und jemand meinst du mich und du darfst das auch gerne so sagen 
;-). Ich habe das beim Erstellen des Artikels nicht beachtet. Da dieser 
"Fehler" für die Thematik aber völlig irrelevant ist, spiele ich ihn 
nicht herunter, sondern nehme ihn wie dein Kommentar mit Humor :-).

von bitwurschtler (Gast)


Lesenswert?

Til S. schrieb:
> Wie sich später herausstellte, hätten ein paar Zeilen Code für einen
> Watchdog die Mission retten können.

Das ist komplett falsch, bzw. findet sich nicht so in dem verlinkten 
Artikel. Dort wird beschrieben, das es den Watchdog code sehr wohl gab, 
aber da der Processor eine malfunction erlitt, wurde der Code nicht 
aktiv. Geholfen hätte ein externer Watchdog wie dieser: 
http://www.st.com/content/ccc/resource/technical/document/datasheet/06/6a/b3/83/9a/c7/4f/22/CD00176077.pdf/files/CD00176077.pdf/jcr:content/translations/en.CD00176077.pdf 
aber kein Timer, der auf einem Prozessor mit "Schluckauf" läuft.

Nichdestotrotz ist der Hinweis auf den Nutzen eines überwachenden 
Timeouts richtig.

von Rolf H. (b0d0)


Lesenswert?

bitwurschtler schrieb:
> Geholfen hätte ein externer Watchdog wie dieser:

Genau aus diesem Grund müssen in sicherheitsrelevanten Systemen die 
Watchdogs immer unabhängig vom Prozessor sein.

: Bearbeitet durch User
von Stefan K. (stefan64)


Lesenswert?

bitwurschtler schrieb:
> Geholfen hätte ein externer Watchdog wie dieser:

Es hätte schon genügt, den internen Hardware-Watchdog zu benutzen. Dies 
wurde aber nicht gemacht:

Aus http://www.ganssle.com/watchdogs.htm:
> The 1750's built-in watchdog timer hardware was not used

Ich sehe (bei den meisten mc) heute keine Notwendigkeit mehr, einen 
externen Watchdog zu benutzen. Das ungewollte Nachtriggern eines 
internen Watchdog-Registers ist mindestens ebenso unwahrscheinlich wie 
das ungewollte Triggern des externen Wdogs über einen Pin.

Aus http://www.ganssle.com/watchdogs.htm:
> Designers had worried about this sort of problem and implemented a
> software thruster timeout. That, of course, failed when the firmware hung.

Ich nehme an, die Entwickler haben sich sehr wohl Gedanken über die 
Watchdog gemacht. Eine Watchdog über die Hardware hat in einigen Fällen 
auch Nachteile. Ein System, das falsch konfiguriert ist, könnte z.B. 
kurz nach dem Hochlaufen einen Watchdog erhalten und in dieser Scheife 
gefangen bleiben. Damit wäre der Aufbau einer Verbindung zur 
Bodenstation dauerhaft unterbunden. Dieses Problem wollten die 
Entwickler wohl mit einer Pseudo-Software-Watchdog unterbinden, die dann 
leider fehlerhaft implementiert war.
Der Vorteil dieser Implementierung war aber immerhin, dass die Sonde 
sich noch melden konnte und wir heute wenigstens wissen, warum das 
Projekt gescheitert ist.

Viele Grüße, Stefan

von Alex G. (dragongamer)


Lesenswert?

Äußerst interessanter Artikel.
Hab das Stichwort Watchdog öfters hier gehört, aber da ich mehr im 
Desktop und Raspberry bereich bin, nie tiefer danach gegraben.

Wobei mir auch auffällt dass Windows seit Win 7 sowas ja auch hat. Wenn 
auch in einer rabiaten Umsetzung.

: Bearbeitet durch User
von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

bitwurschtler schrieb:
> Das ist komplett falsch, bzw. findet sich nicht so in dem verlinkten
> Artikel. Dort wird beschrieben, das es den Watchdog code sehr wohl gab,
> aber da der Processor eine malfunction erlitt, wurde der Code nicht
> aktiv

Aus der Quelle:
>The 1750's built-in watchdog timer hardware was not used, over the >objections of 
the lead software designer.

Unser Artikel stellt das sicherlich etwas vereinfacht dar und sollte nur 
ein netter Aufhänger sein aber ich verstehe das so, dass es die Hardware 
zwar gab, aber sie nicht genutzt wurde. Aber wie gesagt, ich baue 
Embedded Betriebssysteme und keine Satelliten ;-).

von ST User (Gast)


Lesenswert?

Til S. schrieb:
> Til S

Hallo Til,
von meiner Seite vielen Dank für den kurzen Beitrag. Ich denke das 
dieser besonders Einsteiger dazu ermutigt, sich weiter mit dem Thema zu 
beschäftigen.

Viele Grüße und gutes Mittag!
Mahlzeit

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Alex G. schrieb:
> Wobei mir auch auffällt dass Windows seit Win 7 sowas ja auch hat.
Nein, hat es nicht.
Denn es geht genau nicht um solche simplen Timeouts irgendeiner 
Softwareebene, sondern um einen Watchdog als Hardwarekomponente, der 
"von aussen" am Resetpin zupft wenn die Software nicht mehr reagiert. 
Also dann, wenn der genervte User angesichts des Stillstands auf dem 
Bildschirm lange auf den Power-Knopf drückt oder den Stecker zieht...

: Bearbeitet durch Moderator
von Alex G. (dragongamer)


Lesenswert?

Lothar M. schrieb:
> Alex G. schrieb:
>> Wobei mir auch auffällt dass Windows seit Win 7 sowas ja auch hat.
> Nein, hat es nicht.
> Denn es geht genau nicht um solche simplen Timeouts irgendeiner
> Softwareebene, sondern um einen Watchdog als Hardwarekomponente, der
> "von aussen" am Resetpin zupft wenn die Software nicht mehr reagiert.
> Also dann, wenn der genervte User angesichts des Stillstands auf dem
> Bildschirm lange auf den Power-Knopf drückt oder den Stecker zieht...

Na gut, nicht die Selbe technische Umsetzung, aber das Prinzip ist 
ähnlich: Funktioniert etwas nicht wie es soll, wird es gekillt und 
potenziell neu gestartet.
Das "es" bezieht sich (glücklicherweise) auf ein Programm/Prozess und 
nicht aufs ganze System.

: Bearbeitet durch User
von Stefan K. (stefan64)


Lesenswert?

Das Problem ist, dass die Forderung nach einer "harten Watchdog" zwar 
gerne erhoben wird, aber oft nicht umsetzbar ist.
Ein Roboterarm, der in voller Fahrt einen Watchdog erhält, wird 
unvermittelt stoppen und seine Transportlast dadurch quer durch die 
Halle fliegen.
Eine bemannte Drohne wird bei einem Watchdogreset auch bei kurzer 
Bootzeit dutzende Meter an Höhe verlieren, bis sie sich wieder 
abgefangen hat.

Zumindest im Fall der Clementine Mission glaube ich nicht daran, dass 
"ein paar Zeilen Code" genügt hätten, um das Problem zu lösen 
(jedenfalls nicht, ohne gleichzeitig andere schwerwiegende 
Sicherheitsprobleme zu implizieren).

Viele Grüße, Stefan

von batman (Gast)


Lesenswert?

Stefan K. schrieb:
> Ein Roboterarm, der in voller Fahrt einen Watchdog erhält, wird
> unvermittelt stoppen und seine Transportlast dadurch quer durch die

Nö, das ist nicht zwingend so und wird sicher auch nicht so dämlich 
umgesetzt. Wenn der Controller (neu)startet, kann er ja den 
Betriebszustand (inkl. Geschwindigkeit) der Aktoren erkennen und sicher 
runterfahren.

von bitwurschtler (Gast)


Lesenswert?

Stefan K. schrieb:
> bitwurschtler schrieb:
>> Geholfen hätte ein externer Watchdog wie dieser:
>
> Es hätte schon genügt, den internen Hardware-Watchdog zu benutzen. Dies
> wurde aber nicht gemacht:
>
> Aus http://www.ganssle.com/watchdogs.htm:
>> The 1750's built-in watchdog timer hardware was not used


Da gehen die Darstellungen auseinander. Falls es nur ein 
Software-Failure gewesen wäre, hätte der interne Watchdog was gebracht, 
es wird aber auch von 'a computer failure' gesprochen, was auch den WDT 
resp eine zentrale Ressource (bspw PLL -interne Taktgenerierung, 
Speicherinterface) in Mitleidenschaft gezogen haben könnte. Dann wäre 
ein backup-processor die Lösung gewesen, der interne WDT wäre in solchen 
Fällen keine sichere Lösung. Ein externe WDT hätte einen vollen 
Kaltstart (inklusive bootloader/Memory check) auslösen können und damit 
mehr Failure-szenarios behoben als der interne WDT, der üblicherweise 
nur einen Warmstart (ohne bootloader) initiert.

Und letzlich wurde das Problem wohl erst durch einen Hardware reset 
behoben, was IMHO eher in Richtung Kaltstart klingt, als nach einem 
Software-Restart was m.E. bei einem internen WDT erwartbar wäre.

Aber in jedem Fall ist ein HW-watchdog, egal ob intern oder extern, ein 
besserer "Not-Anker" als ein SW- oder gar kein watchdog.




Interessant finde ich auch: 
https://www.embedded.com/electronics-blogs/break-points/4024495/Born-to-Fail

danach war es wohl ganz normal war das die Software in eine exception 
lief, fast klingt es als ob der Software WD essential für den 
Normalbetrieb wurde.

von Martin S. (strubi)


Lesenswert?

Til S. schrieb:
> Inwieweit siehst du ein RTOS anstelle einer
> Superloop bezüglich eines Watchdogs hinderlich?

z.B. das hier:

Til S. schrieb:
> Bei einem RTOS wie embOS gibt es dafür eine Callback
> Funktion, die vor dem eigentlich Reset aufgerufen wird

Für einen SW-Watchdog a la Linux ist das ok, aber für einen HW-WDOG
eine unnötige Verkomplizierung, sprich: no-go. Was ist, wenn sich der 
Callback aufhängt?

Wenn ich anfangen muss, zu beweisen, dass der WD alle erdachten 
Szenarien abdeckt, macht mir ein RTOS nur unnötig Bauchweh, bis die 
Mechanismen durchschaut und von Coverage-Tests abgedeckt sind. In dem 
Fall einer funktionalen SW-Fehlfunktion (durch ein nicht logisch 
abgedecktes Szenario) will ich nur noch eine mehr oder weniger 
fehlersichere init und cleanup section ohne dazwischenfunken eines 
Schedulers und allenfalls HW, die mir dabei hilft, wie 
Call-Stack-Wächter in kritischen Routinen.
Die HW soll als späteste Instanz DANN zuschlagen, wenn sie feststellt, 
dass die CPU/SW nicht mehr richtig tut.
Aber auch nicht - man verzeihe mir den Seitenhieb - inflationär das 
System neustarten wie der ESP8266 Radio-Watchdog.

Und, auch wenn sich die Beispiele vom Satellit bis zum proprietären RTOS 
als 'kleiner Aufhänger' nett lesen: Wenn eine seriöse Diskussion bei 
rumkommen soll, ist das unverhohlene Marketing hier absolut deplaziert 
bzw. eher kontraproduktiv, denn jeder, der hier solche Sachen mal 
implementiert hat, weiss genau, dass ihm ein RTOS das eigentliche 
Problem nicht abnimmt.

von Felix F. (wiesel8)


Lesenswert?

Stefan K. schrieb:
> Eine bemannte Drohne wird bei einem Watchdogreset auch bei kurzer
> Bootzeit dutzende Meter an Höhe verlieren, bis sie sich wieder
> abgefangen hat.
Deswegen verwendet man bei solchen kritischen Systemen auch einen 2t 
oder 3t Controller, der dann die Steuerung übernimmt.

mfg

von batman (Gast)


Lesenswert?

Das RTOS soll einem ja auch ganz andere Probleme abnehmen. Die Bedienung 
des WD wird durch Einsatz eines RTOS nicht einfacher, das ist wohl klar.

Vor dem Reset noch einen Callback in dem fehlerhaften Prozeßkontext 
laufen zu lassen, halte ich aber auch nicht für sehr sinnvoll. Das kann 
dann ebenso fehlschlagen und den Reset vereiteln.

Die Funktionalität kann imo besser nach Reset und Initialisierung 
ausgeführt werden, in einem definierten Startkontext.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Martin S. schrieb:
> Für einen SW-Watchdog a la Linux ist das ok, aber für einen HW-WDOG
> eine unnötige Verkomplizierung, sprich: no-go. Was ist, wenn sich der
> Callback aufhängt?

Um das zu diskutieren wäre es hilfreich zu wissen, ob du verstanden 
hast, worum es bei dem embOS Watchdog Support geht bzw. bei dem Konzept, 
was dahinter steckt. Das ist auch nichts besonderes und keiner 
behauptet, dies löst alle Probleme dieser Welt. Das ist eher daraus 
entstanden, dass viele Kunden gefragt haben, wo soll ich denn meine HW 
Watchdog mit einem RTOS triggern? In einer Task, in allen Tasks? Und wie 
kann ich das effizient bewerkstelligen? Daraus ist unser Watchdog 
Support und dieser Artikel entstanden.
Es ist also weder eine Verkomplizierung noch ein no-go sondern ein 
simpler generischer Ansatz, mit dem vielen Kunden geholfen ist. Um deine 
Frage zu beantworten: Wenn die Callback sich aufhängt schlägt der HW 
Watchdog zu. Das kann ein interner oder genauso gut ein externer HW 
Watchdog sein.

batman schrieb:
> Vor dem Reset noch einen Callback in dem fehlerhaften Prozeßkontext
> laufen zu lassen, halte ich aber auch nicht für sehr sinnvoll. Das kann
> dann ebenso fehlschlagen und den Reset vereiteln.
>
> Die Funktionalität kann imo besser nach Reset und Initialisierung
> ausgeführt werden, in einem definierten Startkontext.

Ich würde sagen, dass hängt von der Applikation und davon ab, was den 
Software Watchdog ausgelöst hat. Die Callback wird aber auch nicht im 
Prozesskontext ausgeführt. Was man aber machen kann ist sofort ein Reset 
ausführen und muss nicht erst auf den HW Watchdog warten. Ich gebe dir 
aber vollkommen Recht, es gibt Situation, in denen das keine gute Idee 
ist.

Wie gesagt, das Thema war, wie benutze ich einen HW Watchdog mit einem 
RTOS. Das der Ansatz, ich trigger den Watchdog nur einer Task, falsch 
ist, ist jedem sofort klar. Ich brauche also etwas, um zu testen, ob 
alle Tasks noch so laufen, wie erwartet.

von batman (Gast)


Lesenswert?

Beim AVR gibts in der Hardware ja eine Art "WD-Reset mit Vorwarnung", 
d.h. es wird in der ersten Stufe eine userdefinierte Interruptroutine 
ausgeführt und wenn diese im Zeitlimit nicht interveniert, führt er 
automatisch den Hardreset aus.

Wenn diese Hardware-Funktionalität so vom RTOS unterstützt wird, wäre 
das natürlich eine gute Sache.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

batman schrieb:
> Wenn diese Hardware-Funktionalität so vom RTOS unterstützt wird, wäre
> das natürlich eine gute Sache.

Unser Konzept setzt kein solches AVR spezifische Feature voraus aber es 
spricht nichts dagegen, dies auch zu benutzen.
Wir setzen nur einen Hardware Watchdog, der irgendwann abläuft und den 
man triggern kann, voraus. Also eigentlich nichts besonderes.
Es ist dann jedem selbst überlassen, ob man in unserer Callback das 
System in einen sicheren Zustand bringt und einen Reset durchführt oder 
das in der WD Interrupt Routine durchführt.

von Markus F. (mfro)


Lesenswert?

Was man in der Raumfahrt nun mal gar nicht gebrauchen kann ist eine 
Situation, wo ein Watchdog versucht, ein (aus welchem Grund auch immer) 
hängendes Programm neu zu starten und das kommt dann gar nicht mehr 
hoch.

Mal eben den Debugger anstecken und/oder neu Flashen ist da nicht.

Dann steht man u.U. völlig ohne Remote-Diagnose- und 
-Rettungsmöglichkeit da  (während ohne Watchdog vielleicht noch 
wenigstens irgendwas zu machen gewesen wäre) und weiss noch nicht mal 
ungefähr, woran's lag, um es nächstes Mal besser zu machen.

Automatische Watchdogs werden deswegen dort nur sehr ungern 
eingesetzt.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

batman schrieb:
> Beim AVR gibts in der Hardware ja eine Art "WD-Reset mit Vorwarnung",
> d.h. es wird in der ersten Stufe eine userdefinierte Interruptroutine
> ausgeführt und wenn diese im Zeitlimit nicht interveniert, führt er
> automatisch den Hardreset aus.
Ist das neu?

von HildeK (Gast)


Lesenswert?

Lothar M. schrieb:
> Ist das neu?

Ob neu - k.A.
Ich kenne es vom TinyX5 auch so. Wenn sowohl WD-Reset als auch 
WD-Interrupt verwendet werden sollen, dann wird der erste Event den IRQ 
bedienen und wenn danach der WD-IE nicht wieder aktiviert wird, kommt 
beim nächsten WD-Event der WD-Reset.
Geht aber so wohl nicht mit der WD-Fuse.

von BFQ (Gast)


Lesenswert?

Ob RTOS oder nicht, es kann immer Threads/Prozesse geben, die im 
Hinterland enden. Der Sinn eines RTOS, und ich meine Harte Echtzeit, ist 
doch der, daß pro Kern/CPU (ist ja inzwischen etwas Komplex geworden) 
nur 1, und wirklich nur für einen Thread/Prozess die Anforderung erfüllt 
werden kann. Es kann sein, daß zig andere auch eingehalten werden, aber 
das hängt doch davon ab, wie die Anforderungen sind.
Man kann das nicht pauschalisieren, War es nicht bei Apollo 13, wo es 
mit einem RTOS Probleme gab? Das hatte nichts mit der Überwachung 
sämtlicher Prozesse zu tun.

Sobald man bei einem RTOS, andere Threads/Prozesse explizit zum laufen 
zu bringen mus, weil sie von anderen ausgebremst werden, ist das Design 
falsch, zumindest in der hier angegebenen generalisierung.

von BFQ (Gast)


Lesenswert?

Noch ein Beispiel.

Wenn ich auf ein Ereignis (Taster gedrückt) innerhalb 10-12 ms Reagieren 
muss (LED Schalten) und die Codeausführung dauert 10 ms, dann bleiben 
2ms für alles andere übrig wenn alle 10ms die taste gedrückt wird.

Und im den Falle dürften die 2ms darauf verschwendet werden, zwischen 
den threads umzuschalten, und gleich wieder zurueck. (grob gesehen)

von Martin S. (strubi)


Lesenswert?

Til S. schrieb:
> Das ist eher daraus
> entstanden, dass viele Kunden gefragt haben, wo soll ich denn meine HW
> Watchdog mit einem RTOS triggern? In einer Task, in allen Tasks? Und wie
> kann ich das effizient bewerkstelligen? Daraus ist unser Watchdog
> Support und dieser Artikel entstanden.

Ich habe dann nach wie vor den Wert des Artikels offenbar nicht 
verstanden.
Auf die Stolperfallen im ersten Codeschnipsel, aus denen der Anfänger 
lernen könnte (Stichwort atomic/non-atomic) bist du gar nicht 
eingegangen, und die zwei Funktionen 'OS_WD*' demonstrieren jetzt keine 
API, die andere Systeme nicht hätten.
Muss man denn so um Innovationen betteln?


Til S. schrieb:
> Das der Ansatz, ich trigger den Watchdog nur einer Task, falsch
> ist, ist jedem sofort klar

Das ist eben nicht klar, und auch nicht falsch, es gibt Anwendungen, die 
genau das erfordern, um allfällige Race-Conditions zu vermeiden, die 
mal eben bei der einen Architektur zB einmal pro Woche auftreten, bei 
der anderen nie. Dabei gibt's dann genau einen Control-Thread 
(meinetwegen der Scheduler), der die anderen (gerne mit 
Hardware-basierten Latency-Timern) beaufsichtigt. Das ist aber nach wie 
vor ein SW-Watchdog und sollte auch einer bleiben. Die Aufgabe eines 
robusten RT-Kernel ist schliesslich, zu garantieren, dass die Threads 
regelmässig und einigermassen deterministisch drankommen, alles 
Funktionale ist Aufgabe des Programmierers.

Til S. schrieb:
> Es ist also weder eine Verkomplizierung noch ein no-go sondern ein
> simpler generischer Ansatz, mit dem vielen Kunden geholfen ist. Um deine
> Frage zu beantworten: Wenn die Callback sich aufhängt schlägt der HW
> Watchdog zu. Das kann ein interner oder genauso gut ein externer HW
> Watchdog sein.

No-go ist in einen komprimittierten Kontext zu springen..
Wer garantiert mir, dass das nicht in einer Boot-Endlosschleife endet, 
oder irgendwas anderes zerschiesst?

Wenn die Integrität des Schedulers verletzt ist und der HW-WD zuschlägt, 
gibt's eigentlich nur wenige wirklich robuste Szenarien:

- harte failsafe-Logik macht den sauberen Shutdown/Recovery der 
kritischen Peripherie
- komplexere Systeme prüfen nach dem Reset den Reboot-Status (wdog/warm, 
kalt) und versuchen die Peripherie-Recovery erst nach Verifikation der 
Systemintegrität (die nicht zu lange dauern sollte..)

Dieser Mischmasch von Callback bis Hardware-Watchdog klingt mir - sorry 
für die vernichtende Kritik - nach wie vor nach altbekanntem Murks.

Das Spiel mal weitergespielt: Wenn im All dank der deftigeren 
Gammastrahlung die Bits anfangen zu kippen, kann eine defekter 
Control-Thread wunderbar weiter laufen und die obigen WD ruhigstellen, 
aber gewisse Fehlerkonditionen nicht mehr erkennen. Da kämen dann 
eigentlich die spannenden Fragen zum Zuge: Wie entwerfe ich einen 
Watchdog bzw. Architektur, damit sie möglichst einfach mit 
randomisierten Fehlerszenarien simulierbar wird. Oder welche 
Möglichkeiten bietet mein OS beweisbar und ohne riesen SW-Overhead die 
Systemintegrität zu prüfen.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Martin S. schrieb:
> Auf die Stolperfallen im ersten Codeschnipsel, aus denen der Anfänger
> lernen könnte (Stichwort atomic/non-atomic) bist du gar nicht
> eingegangen,
Richtig, weil das nur ein dummer "Fehler" meinerseits war aber nichts 
mit dem eigentlich Thema zu tun hat. Wie wäre es, wenn du einen 
Artikel/Beitrag dazu schreiben würdest, wenn dich das so beschäftigt? Da 
könnten Anfänger noch mehr von lernen.

Martin S. schrieb:
> und die zwei Funktionen 'OS_WD*' demonstrieren jetzt keine
> API, die andere Systeme nicht hätten.
Und? Hat ja auch keiner behauptet, das es ähnliches nicht auch woanders 
geben kann. Mir ist zwar gerade keines bekannt aber ich würde mich 
freuen, wenn du uns aufzeigst, wie dieses Problem woanders gelöst wurde.

Martin S. schrieb:
> Das ist eben nicht klar, und auch nicht falsch, es gibt Anwendungen, die
> genau das erfordern, um allfällige Race-Conditions zu vermeiden, die
> mal eben bei der einen Architektur zB einmal pro Woche auftreten, bei
> der anderen nie.

Es gibt zwei Fehlerbilder: In dem einem "hängt" die CPU in einer Task 
und nichts anderes läuft mehr. Hierbei greift dein einfacher Ansatz. 
Kein Einspruch. Aber der ungünstige Fall ist, dass die Task, die den WD 
triggert, noch läuft, aber alle anderen Tasks laufen nicht mehr. In dem 
Fall würde der Watchdog nie auslösen, obwohl das System nicht mehr wie 
gewünscht funktioniert.

Martin S. schrieb:
> No-go ist in einen komprimittierten Kontext zu springen..
> Wer garantiert mir, dass das nicht in einer Boot-Endlosschleife endet,
> oder irgendwas anderes zerschiesst?

Da stimme ich dir voll und ganz zu. Gut, das wir so etwas nicht machen 
;-).

Martin S. schrieb:
> Wenn die Integrität des Schedulers verletzt ist und der HW-WD zuschlägt,
> gibt's eigentlich nur wenige wirklich robuste Szenarien:

Auch hier stimme ich hier zu. Oft kann man nicht mehr viel machen außer 
einen Reset durchzuführen.

Martin S. schrieb:
> Dieser Mischmasch von Callback bis Hardware-Watchdog klingt mir - sorry
> für die vernichtende Kritik - nach wie vor nach altbekanntem Murks.

Kein Problem, ich freue mich über konstruktive Diskussionen (ich bin mir 
nur nicht sicher, ob das gerade eine ist ;-) ).

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

BFQ schrieb:
> War es nicht bei Apollo 13, wo es
> mit einem RTOS Probleme gab?

Nein. Bei Apollo 13 führte ein abfackelnder Sensor in einem 
Sauerstofftank zur Explosion desselben.
Du meinst wahrscheinlich den Überlauf beim Rechner des LEM, der zu einer 
Fehlermeldung führte, die man etwa mit 'Zu viel Input' übersetzen 
könnte. Das war aber kein RTOS, sondern ein besserer Taschenrechner.

von C. A. Rotwang (Gast)


Lesenswert?

Matthias S. schrieb:
> BFQ schrieb:
>> War es nicht bei Apollo 13, wo es
>> mit einem RTOS Probleme gab?
>
> Nein. Bei Apollo 13 führte ein abfackelnder Sensor in einem
> Sauerstofftank zur Explosion desselben.

Hm, IMHO war es kein Sensor, sondern ein BiMetallschalter der 
festschmorte, weil er auf 28V ausgelegt war, aber die Heizung (bis auf 
den Bimetallschalter) auf 65V umgerüstet wurde. Und der Bimetall 
zündetet auch nicht die Explosion sondern durch den festgeschmolzenen 
Bimetal wurde beim Ausgasen des Behälter am Boden die Heizung 
stundenlang mit Überstrom betrieben so dass die Isolation wegbrannte. Im 
All gabs dann wegen der verbrannten Isolation Funken an der falschen 
Stelle. http://www.zummondfliegen.de/apollo-13/

> Du meinst wahrscheinlich den Überlauf beim Rechner des LEM, der zu einer
> Fehlermeldung führte, die man etwa mit 'Zu viel Input' übersetzen
> könnte. Das war aber kein RTOS, sondern ein besserer Taschenrechner.

Eher Niveau AVR am unteren Leistungsende: (1MHz, 12k ROM, 1k RAM), OS 
ist auf solchen Zwergen Verschwendung.

von Wolfgang (Gast)


Lesenswert?

Til S. schrieb:
> Ein Watchdog hätte also die weitere Mission retten können, nicht ein
> RTOS.

Schon ein (Hardware)-Monoflop in der Ansteuerung vom Treibstoffventil 
hätte vermutlich gereicht, damit Clementine nicht unkontrolliert ihren 
ganzen Treibstoff auf einmal verballert. Das ist gute Praxis für 
Aktuatoren, die keine 100%-ED vertragen.

von C. A. Rotwang (Gast)


Lesenswert?

Wolfgang schrieb:
> Schon ein (Hardware)-Monoflop in der Ansteuerung vom Treibstoffventil
> hätte vermutlich gereicht, damit Clementine nicht unkontrolliert ihren
> ganzen Treibstoff auf einmal verballert. Das ist gute Praxis für
> Aktuatoren, die keine 100%-ED vertragen.


ED steht für Einschaltdauer? Also der Schutz besteht zu einem, das nicht 
der Pegel sondern die Schaltflanke die Aktion auslöst und zum anderen 
das die Aktion sich selbst beendet?
Klingt hier vernünftig, an anderer Stelle hat eine automatische 
Triebwerksabschaltung in der Höhenkontrolle gerade in die Katastrophe 
geführt.
https://de.wikipedia.org/wiki/Schiaparelli_(Marslander)#Missionsablauf

Vielleicht hat sich der Systemarchitekt bewusst gegen selbstlimitierende 
Triebwerke entschieden, weil er die unwahrscheinlichsten fehlerszenarion 
höher priotisierte?

von Markus F. (mfro)


Lesenswert?

C. A. Rotwang schrieb:
>> Du meinst wahrscheinlich den Überlauf beim Rechner des LEM, der zu einer
>> Fehlermeldung führte, die man etwa mit 'Zu viel Input' übersetzen
>> könnte. Das war aber kein RTOS, sondern ein besserer Taschenrechner.
>
> Eher Niveau AVR am unteren Leistungsende: (1MHz, 12k ROM, 1k RAM), OS
> ist auf solchen Zwergen Verschwendung.

Das beschriebene Problem mit dem "Apollo Guidance Computer" (Fehler 
1202/1201 - Overload) trat bei Apollo 11 auf, nicht 13 (die flog nach 
der Explosion auf dem schnellsten Weg wieder heim). Und das Ding hatte 
durchaus so was wie ein RTOS ("EXEX") und konnte 7 parallele 
Rechen-Tasks (+eine Watchdog-ähnliche Control-Task) ausführen. Die 
Hardware hatte 2K 15-Bit Worte RAM und 36K x 15 Bit ROM.

Der "Overload" (das, was man heute überall als "Computerfehler" lesen 
kann) kam dadurch zustande, dass sich die 7 Tasks um die 5 "VAC" (Vector 
Accumulator) Recheneinheiten stritten, die aber (durch falsche 
Programmierung/Schalterstellung) bereits für eine (zu diesem Zeitpunkt 
überhaupt nicht gebrauchte) Rendezvous-"Wiederandock"-Task reserviert 
waren.

Der Fehler hockte (bzw. stand) also (wie heutzutage auch oft) vor dem 
Gerät.

Der 1201/1202 Fehler wurde übrigens durch die 8. Task bemerkt, die einen 
Restart auslöste und anschliessend die fehlerhaften Rendezvous-Schalter 
ignorierte. Womit wir wieder beim Watchdog wären.

Wer das Ding programmieren (oder einfach nur vorbereitet sein will, 
falls er mal plötzlich in eine Apollo-Landefähre gerät), hier: 
https://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/public/archive/1689.pdf 
ist das Manual dazu.

: Bearbeitet durch User
von C. A. Rotwang (Gast)


Lesenswert?

Markus F. schrieb:
> Das beschriebene Problem mit dem "Apollo Guidance Computer" (Fehler
> 1202/1201 - Overload) trat bei Apollo 11 auf, nicht 13 (die flog nach
> der Explosion auf dem schnellsten Weg wieder heim).

Nein, Apollo 13 flog nicht auf dem schnellste Weg heim, weil man das 
Haupttriebwerk wegen Explosionsgefahr nicht benutzen wollte, sondern man 
gondelte weiter auf der "free return trajectorie".


https://youtu.be/XLMDSjCzEx8?t=20


Und der Navigationscomputer spielte bei 13 eine geringerer Rolle, weil 
er aus Stromspargründen zeitweise abgeschaltet wurde und deshalb einige 
Kurskorrekturen ohne Comuter gesteuert worden. Dennoch musste man seine 
Daten erhalten weshalb man vor der Abschaltung diese in den zweiten 
Computer im LEM transferierte.

Interessantes Thema, aber vielleicht ist das in einem anderen thread 
besser aufgehoben.

von Markus F. (mfro)


Lesenswert?

C. A. Rotwang schrieb:
> Nein, Apollo 13 flog nicht auf dem schnellste Weg heim, weil man das
> Haupttriebwerk wegen Explosionsgefahr nicht benutzen wollte, sondern man
> gondelte weiter auf der "free return trajectorie".

was für ein auf über 40000 km/h beschleunigtes Raumfahrzeug mit 
beschränkten Treibstoffvorräten üblicherweise der schnellste (bzw. 
einzige) Weg ist. Schnell mal Anhalten und Umdrehen ist da nicht.

Raumfahrt funktioniert nur, weil es da draussen Sachen gibt, um die 
man rumfliegen kann ;)

: Bearbeitet durch User
von C. A. Rotwang (Gast)


Lesenswert?

Markus F. schrieb:
> was für ein auf über 40000 km/h beschleunigtes Raumfahrzeug mit
> beschränkten Treibstoffvorräten üblicherweise der schnellste (bzw.
> einzige) Weg ist. Schnell mal Anhalten und Umdrehen ist da nicht.

Nein, man macht es in vertauschter Reihenfolge, erst umdrehen, dann 
Anhalten. Der direct return war schon als Notfallvariante im Vorfeld 
durchgeplant, man hat sich aber dann im Notfall dagegen entschieden.

https://en.wikipedia.org/wiki/Apollo_13#/media/File:Direct_Abort_Trajectory_-_Lunar_Landing_Symposium,_MSC_Jun66.jpg

https://en.wikipedia.org/wiki/Apollo_13#Crew_survival_and_return_journey

Wird auch im oben verlinkten Video so dargestellt.

PS:
Danke für deine Darstellung zum Navicomputer grad drüber, kannte ich 
noch nicht, sehr interessant, scheint ja doch ein Mini-OS zur 
Allokierung/Verwaltung gesharter Ressourcen für mehrere Tasks drauf 
gewesen zu sein.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

C. A. Rotwang schrieb:
> Hm, IMHO war es kein Sensor, sondern ein BiMetallschalter

Auch ein Bimetall ist ein Sensor, wenn auch ein grober. Das sollte jetzt 
aber auch keine detaillierte Erklärung von Apollo 13 werden, sondern nur 
ein kurzer Abriss. Jedenfalls war bei Apollo 13 kein RTOS im Spiel und 
auch kein Watchdog.

: Bearbeitet durch User
von Markus F. (mfro)


Lesenswert?

C. A. Rotwang schrieb:
> Danke für deine Darstellung zum Navicomputer grad drüber, kannte ich
> noch nicht, sehr interessant, scheint ja doch ein Mini-OS zur
> Allokierung/Verwaltung gesharter Ressourcen für mehrere Tasks drauf
> gewesen zu sein.

Angesichts der 15 Bit-Worte und der Tatsache, dass das Ding mit 
Einerkomplement-Darstellung arbeitete, war es wahrscheinlich ein Glück 
für die Astronauten, dass der C-Compiler noch nicht erfunden war ;)

von chris (Gast)


Lesenswert?

Soweit mir bekannt waren die resultate zu ungenau und man verwendete die 
berechnungen vom Boden uber funk.
Al's backuplosung ging es, und der Rechner verbrauchte such zuviel 
Strom.

von Markus F. (mfro)


Lesenswert?

chris schrieb:
> Soweit mir bekannt waren die resultate zu ungenau und man verwendete die
> berechnungen vom Boden uber funk.
> Al's backuplosung ging es, und der Rechner verbrauchte such zuviel
> Strom.

Du redest (wahrscheinlich) über die Bahnkorrektur(en) der Apollo-13 
Mission nach der Sauerstofftank-Explosion?

Wir nämlich (eigentlich) nicht. Diese Bahnkorrekturen/Brenndauern wurden 
tatsächlich am Boden berechnet. Wir reden von der "Computerpanne" bei 
Apollo 11.

Der "Apollo Guidance Computer" (AGC), der den "Fehler 1201" bzw. "Fehler 
1202" zeigte (den ein durch die Control-Task ausgelöster Restart behoben 
hat - deswegen passt das wenigstens halbwegs zum Thema "Watchdog") war 
für die Steuerung des Abstiegs der Landefähre vorgesehen (das war vom 
Boden aus wegen der Signalübertragungsdauer nicht möglich). Neil 
Armstrong, der nach der Fehlermeldung die automatische Steuerung 
abgeschaltet und die Landefähre mit den letzten Treibstoffreserven von 
Hand und nach Augenmass (durch ein "Mini-Guckloch") per Handsteuerung 
auf den Boden gebracht hat, wird dafür als Held gefeiert.


Hätte er den Schalter, der die Reservierung der "VAC"-Speicher für 
Radar-Sensordaten beim Rendezvous-Manöver kontrollierte und falsch 
stand, vorher richtig eingestellt, wäre das (wahrscheinlich) gar nicht 
notwendig gewesen.

: Bearbeitet durch User
von bitwurschtler (Gast)


Lesenswert?

Markus F. schrieb:
> Angesichts der 15 Bit-Worte und der Tatsache, dass das Ding mit
> Einerkomplement-Darstellung arbeitete, war es wahrscheinlich ein Glück
> für die Astronauten, dass der C-Compiler noch nicht erfunden war ;)

würde mich nicht wundern wenn die NASA C verboten hat und alles in ADA 
oder FORTRAN schreiben lässt ...

von Markus F. (mfro)


Lesenswert?

C. A. Rotwang schrieb:
> Nein, Apollo 13 flog nicht auf dem schnellste Weg heim, weil man das
> Haupttriebwerk wegen Explosionsgefahr nicht benutzen wollte, sondern man
> gondelte weiter auf der "free return trajectorie".

Die "free return trajectory"-Bahn musste auch erst erreicht werden.

Apollo 11 war nach meiner Information die letzte Mission, die diese 
(längere) Bahn von Anfang an einschlug und - nachdem alles funktionierte 
- in die Umlaufbahn einschwenkte. Die späteren Missionen "zielten" 
direkt dahin und mussten (bzw. hätten gemusst) für das swing-by erst 
ihren Kurs ändern.

Nach meinen Informationen gab es bei Apollo 13 gar nicht mehr die Wahl 
zwischen "early return" und "swing-by" (auch wenn im Film der Eindruck 
erweckt wird). Als es knallte, war die Kapsel bereits etwa 320000 km von 
der Erde entfernt (Entfernung Erde <-> Mond = 382 - 384000 km) und flog 
längst antriebslos. Meiner Ansicht nach viel zu nah dran, um noch 
umkehren zu können.

von mitleser (Gast)


Lesenswert?

Also was jetzt? Mit embos wäre das alles nicht passiert? Und ein 
watchdog kann nur sinnvoll mit embos funktionieren?
?
Der Artikel hätte wirklich interessant werden können, wenn man beim 
Thema der Überschrift geblieben wäre. Hier wurde aber das embos in den 
Fordergrund gestellt und erwähnt das es auch mit einem watchdog kann.
???
Kann jemand die Überschrift ändern: RTOS in sicheren oder 
hochverfügbaren Systemen.
Danke! ?

von Jens G. (jensg)


Lesenswert?

Jede Waschmaschine hat einen Hardware-Watchdog nach dem oben 
beschriebenem Prinzip. Ein Pin wird getoggelt - fällt das aus, wird nach 
einer bestimmten Zeit der Reset ausgelöst (ein Monoflop in Hardware).

Warum das Ganze? - Funktional Safty - die Waschmaschine geht bei Fehlern 
in den sicheren Zustand. Kein System ist Fehlerfrei (Menschen haben es 
entwickelt) und Fehlbedienung (Faktor Mensch) ist nicht auszuschließen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.