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:
Wird das RTOS noch korrekt ausgeführt?
Gibt es hochpriore Threads, die zuviel Rechenzeit verbrauchen und damit verhindern, dass niedrigpriore Threads ausgeführt werden?
Verhindert ein Deadlock die Ausführung einzelner Threads?
Werden alle Threads vollständig und korrekt ausgeführt?
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.
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.
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?
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.
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.
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.
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.
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 ;-).
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!
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.
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"
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. :)
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?
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 :-).
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.
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
Ä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.
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 ;-).
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
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...
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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)
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.
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 ;-) ).
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.
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.
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.
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?
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.
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.
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 ;)
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.jpghttps://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.
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.
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 ;)
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.
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.
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 ...
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.
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! ?
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.