Priorität: Watchdog Trigger Task

Andreas Gast #829096
Lesenswert?
• ▲
▼ 
Hallo allerseits

Ich arbeite zur Zeit an einer grösseren uC-Software mit einem 
kommerziellen RealTimeOS. (ca. 2000 Sourcedateien, Binary-Executable ca. 
3 MByte) Die Software besteht aus zahlreichen Tasks unterschiedlicher 
Priorität. Einer der Task ist der WatchdogTriggerTask WDT(), welcher den 
Watchdog  alle 250ms triggern soll, der Watchdog-Timeout liegt bei ca. 
2.5 Sekunden.

Die Software muss beim Kunden über Wochen zuverlässig laufen, ohne 
Ausfälle oder Restarts. Die Rechenleistung des Prozessors ist 
ausreichend bemessen, die CPU-Belasung liegt ca. zwischen 10..40%

Bisher lief die SW stabil auch mit einer beliebig tiefen WDT()-Prio. 
Kürzlich ist jedoch ein neuer Task hinzugekommen, welcher in gewissen 
Situationen den WDT() für >2.5 Sekunden nicht mehr zu Zug kommen lässt, 
wenn die WDT()-Prio tiefer ist. => Restart

Nun wurde bei uns im Geschäft eine Diskussion entfacht, über die Frage, 
welche Priorität der WatchdogTriggerTask haben soll.

Es gibt da unterschiedliche Ansichten:
______________________________________________________

Der WDT() soll die höchste Priorität haben:
=> Kein Reset solange der Task-Scheduler überhaupt noch läuft.
=> Keine Kontrolle ob alle Tasks genügend Rechnleistung abkriegen,
   bzw. ob niedrig priorisierte Task längere Zeit blockiert werden.

Der WDT() soll die gleiche Priorität haben, wie der Task mit der 
niedrigsten Priorität (ausgenommen IdleTask)
=> Kein Reset, solange auch Tasks mit niedriger Prio regelmässig
   Rechenzeit abkriegen.
=> Risiko, dass auch Task mit tiefer Prio bei Überlast den WDT()
   zu lange blockieren und ein SW-Restart auftritt.

Der WDT() soll die niedrigste Priorität haben (ausgenommen IdleTask)
=> kein Reset, solange auch noch regelässig IdleTime verfügbar ist.
=> Risiko, dass auch Task mit tiefer Prio bei Überlast den WDT() zu
   lange blockieren und ein SW-Restart auftritt.

Weitere Möglichkeiten...???
______________________________________________________

Ich bin einfach an verschieden Meinungen und Ansichten interessiert, 
bzw. möchte wissen, wie ihr dies bei euch so macht.

Oder wäre es sogar sinnvoll, die WDT() Priorität für Test und Messungen 
anders zu wählen, als für die SW die an den Kunden geliefert wird?

Bin gespannt auf eure Ansichten.

Andy
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter D. #829214
Lesenswert?
• ▲
▼ 
Andreas wrote:

> Der WDT() soll die höchste Priorität haben:
> => Kein Reset solange der Task-Scheduler überhaupt noch läuft.
> => Keine Kontrolle ob alle Tasks genügend Rechnleistung abkriegen,
>    bzw. ob niedrig priorisierte Task längere Zeit blockiert werden.

Das ist Quatsch.
Dann schalte doch den Watchdog gleich aus, kommt auf selbe raus.

Der Watchdogtask muß natürlich alle wichtigen Prozesse überwachen, ob 
sie in einem bestimmten Intervall ausgeführt werden.
Dazu hat er entsprechende Timeout-Counter und wenn einer davon 
abgelaufen ist, bleibt er einfach stehen, bis der Watchdog zuschlägt.
Damit kann man dann auch Prozesse überwachen, die z.B. nur alle 1h 
ausgeführt werden müssen.


Er darf nicht die höchste Priorität haben, damit er nicht die eiligen 
Sachen verzögert.
Er muß ne mittlere Priorität haben.


Peter
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Drinverter Gast #829260
Lesenswert?
• ▲
▼ 
Wenn deine Software "beim Kunden über Wochen zuverlässig laufen, ohne
Ausfälle oder Restarts" dann bringt dein Watchdog gar nichts denn wenn 
er zuschlägt ist das Kind schon im Brunnen (deadlock). Dann hast du ja 
dein Ziel schon verfehlt. Ein Watchdog macht nur Sinn
- wenn man erstens ein Sicherheitskritisches System am durchdrehen 
hindern will/muss (ist vorgeschrieben)
- wenn man dem Benutzer das lästige drücken des Reset-Schalters ersparen 
will

Wenn du ein zuverlässiges System brauchst hilft nur eins: Fehlerfreier 
Code
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas Gast #829359
Lesenswert?
• ▲
▼ 
Danke für die bisherigen Inputs

>Er darf nicht die höchste Priorität haben, damit er nicht die eiligen
>Sachen verzögert.
Der WDT braucht kaum CPU-Zeit, nebst dem RTOS Context-Switching werden 
bloss zwei drei uC-Register beschrieben.

>Wenn du ein zuverlässiges System brauchst hilft nur eins: Fehlerfreier
>Code
Das wäre auch mein Wunsch, aber nicht ganz realistisch. Wenn Du ein 
Projekt dieser Grösse (C und C++ gemischt, seit 10 Jahren haben 
zahlreiche Firmen und Programmierer die ihren Input beigetragen haben) 
fehlerfrei hinkriegst, wirst Du sofort angestellt. ;o))

>-wenn man dem Benutzer das lästige drücken des Reset-Schalters ersparen
>will
Ja, das will man. Normalerweise ist kein "Operator" vor Ort, dann ist es 
immer noch besser das System bootet selbständig mit einem 
Funktions-Unterbruch von einigen 10 Sekunden
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Kanzler Gorkon Gast #829370
Lesenswert?
• ▲
▼ 
Also wir machen das hier so:
1. Unterscheidung Runtimeüberwachung <-> Watchdog:
Die Runtimeüberwachung übernimmt der Scheduler, ist also quasi ein 
Softwarewatchdog.
2. Die Peripherie/Hardware, die dran hängt hat einen eigenen 
Hardwarewatchdog der beisst, wenn die CPU für "längere" Zeit nichts tut.
Sinnvollerweise wird dieser Peripheriewatchdog in einem Task getriggert, 
der prüfen kann, ob die IOs noch bedient werden, also im einfachsten 
Fall er selbst. Mit einer höheren Priorität triggern hat meiner Meinung 
nach nur einen Sinn, wenn der höher priorisierte Task entsprechende 
Überprüfungen vornimmt, bevor er triggert.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren