Verfahren zur Steuerung/Regelung wenigstens einer Task

Die vorliegende Erfindung betrifft ein Verfahren zur Steuerung/Regelung wenigstens einer Task nach dem Oberbegriff des Patentanspruchs 1, eine entsprechende Recheneinheit, ein entsprechendes Kraftfahrzeug, ein entsprechendes Computerprogramm sowie ein entsprechendes Computerprogrammprodukt.

Stand der Technik

In jedem periodisch ablaufenden System, werden Zyklus für Zyklus, nacheinander Programmabschnitte (Prozesse, Tasks) abgearbeitet. Bei Programmen mit einem OS E K- Betriebssystem (Betriebssystem, welches hauptsächlich bei Mik- rocontrollersystemen Anwendung findet) wird beispielsweise ein monolithischer Kernel aus Betriebssystem und Anwendung generiert. Die Anwendung wird in mehrere Tasks eingeteilt. Diese haben eine Priorität und können vom Status kooperativ oder preemptiv sein. Preemptive Tasks können nach Priorität niedri- gere Tasks an jeder Stelle aktiv unterbrechen. Unterbrochene Tasks setzen ihre

Bearbeitung nach Beendigung der Abarbeitung der preemptiven Task fort. Kooperative Tasks können andere Tasks nicht unterbrechen. Sie beginnen nach Ablauf einer Task. Es beginnt die wartende Task mit der höchsten Priorität. Das zeitliche Ende einer Task erfolgt somit abhängig von ihrer Priorität unterschied- lieh schnell nach ihrer Aktivierung.

In einer Task werden einer oder mehrere Prozesse definiert. Ein Prozess ist eine Folge von Anweisungen, die je nach Scheduling-Strategie unterbrechbar (durch preemptive Tasks) oder nicht sind (durch kooperativ Tasks). Alle Prozesse einer Task werden sequentiell ausgeführt.

Ist die summierte Laufzeit der Tasks größer als die Zyklusdauer (Systemzyklusdauer), wird dies als überlauf bezeichnet. Die zur Verfügung gestellte Zeit war somit nicht ausreichend, um sämtliche Tasks abzuarbeiten. Ein Programmierer sollte beim Entwurf der Software darauf achten, dass ein solcher Fall nicht ein- treten kann. In der Praxis wird die Zyklusdauer so groß gewählt, dass den Tasks genügend Laufzeit zur Verfügung steht. Problematisch ist es jedoch, wenn die Laufzeit der einzelnen Tasks variabel ist.

Neben einer rechenzeitbedingten Verlängerung der Tasklaufzeit, kann diese auch durch einen unvorhergesehenen Zustand hervorgerufen werden. Ist die Task nicht in der Lage, diesen Zustand selbständig zu verlassen, wird das als "Aufhängen" bezeichnet. Ein Beispiel dafür ist eine Endlosschleife. Ein weiteres Abarbeiten der Task ist dann nicht mehr möglich. Durch ein solches Aufhängen ist nicht nur der Ablauf der Task, sondern evtl. auch der gesamte Programmab- lauf gestört. Abhängig von der Priorität der Task kann dies sogar ein Aufhängen des Programms bedeuten.

Nachfolgend wird im wesentlichen auf den Kraftfahrzeugbau Bezug genommen, ohne dass das Verfahren auf diese Anwendung beschränkt ist.

Anwendungen in der Kraftfahrzeug(Kfz)-Rundumsicht basieren üblicherweise auf Signalverarbeitungssoftware, die Aussagen über das Umfeld des Kfz ermöglichen. Es wird eine Beobachtung des Kfz-Umfelds mit Sensoren, wie z.B. Video-, Ultraschall- oder Radarsensoren durchgeführt. Die Signale dieser Sensoren werden an eine zentrale Recheneinheit, typischerweise ein Steuergerät, weitergeleitet, wo diese Signale für Anwendungen wie z.B. Einparkhilfen, Airbag-

Auslösung, ACC (Adaptive Cruise Control, "intelligenter Tempomat") usw. aufbereitet werden.

Die Signalverarbeitungsalgorithmen sind rechenintensiv und in der Bearbei- tungszeit direkt von dem zu beobachtenden Umfeld abhängig. Somit haben rechenintensive Umfeldszenarien, Temperaturschwankungen oder Sensormessausfälle eventuell eine Auslastung des M ikro- Prozessors zur Folge, in der andere Rechenaufgaben nicht mehr ausgeführt werden können.

Allgemeines Ziel einer Laufzeitüberwachung ist es, Abfangmechanismen in Abhängigkeit von der Bearbeitungszeit der Signalverarbeitung bereitzustellen, um sicherheitskritische Systeme zuverlässig gestalten zu können.

Es existieren Laufzeitüberwachungen, in der Softwaretechnologie als "Watch- dog" bekannt, die mit einem Neustart des Systems bei einer Laufzeitverletzung reagieren. Es handelt sich dabei typischerweise um eine Vorrichtung bzw. Softwarefunktionalität in mikrocontrollergesteuerten elektrischen Geräten, welche verhindert, dass eine Laufzeitverletzung der Software zu einem Komplettausfall des Gerätes führt.

Dies wird typischerweise erreicht, indem die Software in regelmäßigen Abständen dem Watchdog mitteilt, dass sie noch ordnungsgemäß arbeitet. Kommt es durch einen Fehler dazu, dass die Abarbeitung des Programms nicht weiter erfolgt (Abstürzen bzw. Aufhängen des Programms), bleibt diese Meldung aus. Der Watchdog setzt daraufhin das Gerät durch Rücksetzen (Reset) in einen definierten Ausgangszustand zurück.

Das Gerät ist für die Zeit des Resets nicht einsatzfähig und kann somit keine Daten verarbeiten oder auf Anfragen reagieren. Dies ist insbesondere für sicher- heitsrelevante Applikationen nachteilig. Beispielsweise versucht eine Anwendung "Precrash", Kollisionen mit anderen Objekten vorauszuerkennen und er-

- A -

greift geeignete Maßnahmen (Gurtstraffer, Airbag, ...), um ggf. das Leben der Insassen zu schützen. Es ist deswegen wichtig und erwünscht, dass derartige Systeme ständig funktionsfähig sind.

Es stellt sich daher das Problem, ein Verfahren und eine Vorrichtung anzugeben, um den Betrieb von Mikroprozessor-Systemen zu verbessern.

Erfindungsgemäß werden ein Verfahren mit den Merkmalen des Patentanspruchs 1, eine Recheneinheit mit den Merkmalen des Patentanspruchs 13, ein Kraftfahrzeug mit den Merkmalen des Patentanspruchs 15 sowie ein entsprechendes Computerprogramm und Computerprogrammprodukt mit den Merkmalen der Patentansprüche 16 bzw. 16 vorgeschlagen. Vorteilhafte Ausgestaltungen ergeben sich jeweils aus den Unteransprüchen und der nachfolgenden Beschreibung.

Vorteile der Erfindung

Bei dem erfindungsgemäßen Verfahren zur Steuerung/Regelung wenigstens einer Task mit Hilfe eines Steuerprogramms, das eine Laufzeit der wenigstens einen Task überwacht, beendet das Steuerprogramm die wenigstens eine Task, wenn die Laufzeit der wenigstens einen Task eine vorbestimmte Zeitdauer überschreitet.

Die hier vorgestellte Laufzeitüberwachung kann intelligent über eine interne Auswertung des Signalflusses entscheiden, welchem Teil der Software Rechenzeit abgezogen werden kann, um einen kritischen Anweisungsblock auszuführen. Es kann situationsabhängig ein betroffener Softwareanteil überbrückt werden, so dass z.B. eine Fehlerroutine initiiert werden kann und das Gesamtsystem funktionstüchtig bleibt. Bei harten Verletzungen der Laufzeit können einzel- ne Teile des Programms terminiert und neu initialisiert werden.

Um dies zu gewährleisten, wurde eine Laufzeitüberwachung erstellt, die auftretende Fehler im Programm erkennt und versucht, diese zu beheben. Dabei werden die Kommunikation, die Funktionsfähigkeit der Sensoren, und das ordnungsgemäße, zyklische Ablaufen der einzelnen Tasks überwacht.

Gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird eine effektive Laufzeit der wenigstens einen Task überwacht. Die effektive Laufzeit, wie weiter unten erläutert, ist eine aussagekräftige Größe, die für das Verfahren verwendet werden kann. Es versteht sich, dass ebenso eine gesamte Laufzeit überwacht werden kann.

Vorteilhafterweise wird bei dem erfindungsgemäßen Verfahren die vorbestimmte Zeitdauer in Abhängigkeit von einer maximalen Laufzeit und/oder minimalen Laufzeit bestimmt. Die minimale Laufzeit gibt eine untere Grenze für die erwarte- te Tasklaufzeit an. Die maximale Laufzeit gibt eine obere Grenze für die erwartete Tasklaufzeit an. Die Verwendung einer minimalen und einer maximalen Laufzeit ermöglicht die einfache Berechnung einer Zeitspanne, innerhalb der die Tasklaufzeit erwartet wird. Die maximale Laufzeit kann zusätzlich vorteilhaft zur Abschätzung einer voraussichtlichen Restlaufzeit verwendet werden.

Es ist zweckmäßig, wenn bei dem erfindungsgemäßen Verfahren die minimale Laufzeit und/oder die maximale Laufzeit in Abhängigkeit von einer Untergrenze und/oder in Abhängigkeit von einer Obergrenze bestimmt werden. Dies ermöglicht auf einfache Weise, die oben genannte Zeitspanne in feinen Schritten zu bestimmen.

Bei einem besonders bevorzugten Ausführungsbeispiel des erfindungsgemäßen Verfahrens wird ein Qualitätswert bzw. -faktor bestimmt, der von einer Wahrscheinlichkeit, mit der die Laufzeit der wenigstens einen Task zwischen der mi- nimalen Laufzeit und der maximalen Laufzeit um die vorbestimmte Zeitdauer liegt, abhängt. Dadurch ist es möglich, über ein internes Qualitätsmaß zu ent-

scheiden, ob eine Zeitspanne hinreichend genug berechnet wurde, um mit kritischen Softwarekomponenten fortzufahren. In einer einfacheren Ausgestaltung ist es möglich, nur eine der beiden Grenzen zu verwenden. Der Qualitätsfaktor kann bspw. dann in Abhängigkeit davon bestimmt werden, ob eine Tasklaufzeit kleiner als die maximale Laufzeit oder größer als die minimale Laufzeit ist oder umgekehrt.

Zweckmäßigerweise läuft bei dem erfindungsgemäßen Verfahren die wenigstens eine Task in aufeinander folgenden Zyklen, die eine Zykluszeit aufweisen, ab. Das Verfahren ist besonders vorteilhaft bei zyklischen Programmen anzuwenden.

Es ist von Vorteil, wenn bei dem erfindungsgemäßen Verfahren das Steuerprogramm eine freie Zykluszeit als Differenz der Zykluszeit und der Laufzeit der we- nigstens einen Task bestimmt. Darunter ist insbesondere die Zeit eines Zyklus zu verstehen, währenddessen keine Tasks ablaufen.

Es ist weiterhin besonders vorteilhaft, wenn bei dem erfindungsgemäßen Verfahren die vorbestimmte Zeitdauer in Abhängigkeit von der freien Zykluszeit be- stimmt wird. Damit kann vorteilhaft eine vorhandener Zeitpuffer für Tasklaufzei- ten abgeschätzt und somit gewährleistet werden, dass eine ausreichende Restlaufzeit für weitere Tasks zur Verfügung gestellt wird.

Gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird eine weitere Task vorgesehen, die von dem Steuerprogramm nicht beendbar ist. Damit können kritische Bereiche vorteilhaft geschützt werden, wie weiter unten ausführlich dargestellt wird.

Es ist von Vorteil, wenn bei dem erfindungsgemäßen Verfahren ein Watchdog verwendet wird. Er kann als Steuerprogramm oder zusätzlich zu einem weiteren

Steuerprogramm verwendet werden. Der Watchdog kann gemäß der beschrie-

benen Ausführungsformen vorteilhafterweise einzelne Tasks beenden oder auch tiefergehende Aktionen wie z.B. einen System- Neustart durchführen.

Es ist bevorzugt, wenn bei dem erfindungsgemäßen Verfahren eine CAN- Kommunikation (Controller Area Network) überwacht wird.

Vorteilhafterweise wird bei dem erfindungsgemäßen Verfahren eine Lösungsliste verwendet. Damit kann auf einfache Weise ein wiederholtes Ausführen identischer Lösungen bzw. Funktionen vermieden werden.

Erfindungsgemäß wird ein erfindungsgemäß Verfahren in einem Kraftfahrzeug verwendet. In einem Kfz können somit insbesondere sicherheitsrelevante Funktionen verbessert werden.

Eine erfindungsgemäße Recheneinheit weist Berechnungsmittel auf, um die Schritte eines erfindungsgemäßen Verfahrens durchzuführen. Sie kann insbesondere als Steuergerät in einem Kfz ausgebildet sein.

Ein erfindungsgemäßes Kraftfahrzeug ist mit einer erfindungsgemäßen Rechen- einheit ausgestattet.

Ein erfindungsgemäßes Computer- bzw. Mikroprozessorprogramm enthält Programmcodemittel, um das erfindungsgemäße Verfahren durchzuführen, wenn das Programm auf einem Computer, einem Mikroprozessor oder einer entspre- chenden Recheneinheit, insbesondere der erfindungsgemäßen Recheneinheit, ausgeführt wird.

Ein erfindungsgemäßes Computer- bzw. Mikroprozessorprogrammprodukt beinhaltet Programmcodemittel, die auf einem maschinen- bzw. computerlesbaren Datenträger gespeichert sind, um ein erfindungsgemäßes Verfahren durchzuführen, wenn das Programmprodukt auf einem Computer, einem Mikroprozessor

oder auf einer entsprechenden Recheneinheit, insbesondere der erfindungsgemäßen Recheneinheit, ausgeführt wird. Geeignete Datenträger sind insbesondere Disketten, Festplatten, Flash-Speicher, EEPROMs, CD-ROMs, u. a. m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) und Fahrzeugnetze (Body-Bus, Infotaiment-Bus etc.) ist möglich.

Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.

Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen. Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schema- tisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.

Figurenbeschreibung

Figur Ia zeigt eine schematische Darstellung der zeitlichen Zusammenhänge einer Minimal- und Maximallaufzeit und der Unter- und Obergrenzen;

Figur Ib zeigt ein Flussdiagramm einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zur Bestimmung der Minimallaufzeit;

Figur Ic zeigt ein Flussdiagramm einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zur Bestimmung der Maximallauf- zeit;

Figur 2 zeigt ein Flussdiagramm einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zur Bestimmung eines Qualitätsfaktors;

Figur 3a zeigt eine schematische Darstellung der zeitlichen Zusammenhänge einer normal ablaufenden Task;

Figur 3a zeigt eine schematische Darstellung der zeitlichen Zusammenhänge einer aufgehängten Task; und

Figur 3c zeigt eine schematische Darstellung der zeitlichen Zusammenhänge einer aufgehängten Task, die gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens von einem Steuerprogramm beendet wird.

In den folgenden Abschnitten werden bevorzugte Ausführungsformen des erfindungsgemäßen Verfahrens übergreifend und beispielhaft beschrieben. Dabei werden auch allgemeine Beschreibungen ohne Bezugnahme auf Figuren gegeben. Es versteht sich, dass daneben auch andere Ausführungen für den Fach- mann möglich sind.

Eine vorbestimmte Zeitspanne, eine minimale und eine maximale Laufzeit und eine Ober- und eine Untergrenze können vorteilhaft mittels so genannter Analy- sis- Funktionen berechnet werden. Damit wird ein Zeitbereich gebildet, in dem sich mit einer berechenbaren Wahrscheinlichkeit (Qualitätsfaktor) die Laufzeit der Task befindet.

Es kann zwischen einer effektiven und einer gesamten (total) Tasklaufzeit unterschieden werden. Die effektive Dauer einer Task beinhaltet die Zeit, in der sich die Task im laufenden Zustand (bspw. "running" bei einem OSEK Betriebssystem) befindet. Die totale Laufzeit wird von dem Zeitpunkt an gemessen, an

dem die Task aus dem Ruhezustand (bspw. "suspended" bei einem OSEK Betriebssystem) in den laufenden Zustand gehoben wird, bis zu dem Augenblick, an dem sie wieder in den Ruhezustand wechselt. Hier werden Zwischenzustände mit berücksichtigt (bspw. "ready", "waiting" bei einem OSEK Betriebssys- tem).

In der vorgestellten Ausführungsform verwenden die Analysis Funktionen die effektiven Laufzeiten. Es versteht sich, dass ebenso die Gesamtlaufzeiten verwendet werden können.

Der Ablauf der Analysis Funktionen wird in zwei Phasen eingeteilt. Während einer ersten Phase wird ein Durchschnittswert über eine vorbestimmte Anzahl, z. B. 100, vorhergehender Tasklaufzeiten gebildet. Der errechnete Durchschnittswert wird einer minimalen Laufzeit und einer maximalen Laufzeit zuge- wiesen.

In einer zweiten Phase werden diese Laufzeiten in jedem Zyklus aktualisiert. Ist die effektive Laufzeit größer als die derzeitige maximale Laufzeit, wird diese vergrößert. Die Schrittweite der Vergrößerung ist vorteilhaft gedämpft, d.h. die maximale Laufzeit kann maximal um eine definierte Schrittweite verschoben werden. Analog dazu wird bei einer Unterschreitung der minimalen Laufzeit diese schrittweise und gedämpft verringert.

Die Schrittweite ist vorteilhafterweise zur Kompilierzeit festzulegen. Dabei sollte beachtet werden, dass durch eine große Schrittweite der entsprechende Endwert schneller erreicht wird, jedoch Abnormalitäten in Form von ungewöhnlich langen oder kurzen Tasklaufzeiten einen größeren Einfluss auf das Ergebnis haben. Eine kleine Schrittweite nähert sich dem Endwert langsam, wobei die Gefahr eines überschwingens wesentlich geringer ist.

Werden die maximale und minimale Laufzeit innerhalb einer vorbestimmten Zykluszahl nicht mehr erreicht, wird die jeweilige Grenze um eine Schrittweite zurück verschoben. Damit ist gewährleistet, dass die Extrem laufzeiten immer den aktuellen Charakteristika der Task entsprechen. Aufschluss über die Genauig- 5 keit der Grenzen gibt ein Qualitätswert. Je größer der Qualitätswert, desto höher ist die Wahrscheinlichkeit, dass sich die Laufzeit der Task zwischen der maximalen und der minimalen Laufzeit befindet.

Die Analysis- Funktionen errechnen ebenfalls die verbleibende freie Zykluszeit. 0 Darunter versteht sich der ungenutzte Zeitraum, der bis zum nächsten Zyklusbeginn verbleibt, nachdem alle Tasks abgearbeitet wurden. Die freie Zykluszeit ist erst nach dem Ablaufen aller Tasks exakt berechenbar, allerdings kann sie durch die ermittelten maximalen Laufzeiten gut vorausbestimmt werden.

5 Der OSEIVVDX Standart stellt so genannte Hook-Routinen zur Verfügung. Bevor das Betriebssystem (OS) eine Task in den laufenden Zustand hebt, wird die PreTaskHook ausgeführt. Verlässt die Task diesen Zustand wieder, ruft das OS die PostTaskHook auf. OSEK stellt von jeder Hook nur eine Routine zur Verfügung, d.h. jede Task wird von derselben Hook-Routine eingeleitet bzw. abge- O schlössen. Innerhalb einer Hook muss deshalb überprüft werden, durch welche

Task diese aktiviert wurde.

Die effektive Tasklaufzeit kann beispielsweise durch eine Zeitmessung zwischen der PreTask- und der PostTaskHook ermittelt werden. Die Zeitmessung ist mit 5 der Zeitstempelfunktion "Timestamp" (OSEK-Layer) realisierbar und liefert dann die Zeitangabe in einer Auflösung von I μs.

Die Tasklaufzeit wird beispielsweise in einer globalen Variablen gesichert. Zu Beginn der Task muss diese Variable auf Null zurückgesetzt werden. Die Lauf- O zeiten der folgenden Taskabschnitte werden anschließend bei jeder

PostTaskHook auf die Variable addiert. Wurde die Hook-Routine durch den OS-

Befehl TerminateTask aufgerufen, ist nach der Addition die effektive Laufzeit der Task erreicht.

Um festzustellen, aus welchem Taskabschnitt die Routinen aufgerufen wurden, bietet es sich an, eine Start- und Stopmarkierung in Form eines Statusbits in jede Task einzubinden. Zu Beginn einer Task setzt eine erste Funktion das Startbit. Eine zweite Funktion kennzeichnet das Taskende und wird vor TerminateTask platziert. Die Statusbits werden nach jedem Zyklus durch einen Watch- dog wieder gelöscht.

In Abhängigkeit der Markierungen kann somit die Zustandsänderung innerhalb der Hook- Routinen erkannt werden, wie es die nachfolgende Tabelle erläutert.

Zur Fehlervorbeugung sollten die Minimal- und Maximallaufzeiten nur dann verschoben werden, wenn kein Fehler im aktuellen Zyklus aufgetreten ist.

Durch die Schrittweite werden die Ober- und Untergrenzen der Extremlaufzeiten bestimmt. Die Schrittweite kann prozentual durch eine Konstante errechnet werden. Dabei ist zu berücksichtigen, dass sie größer als Null sein muss, um eine Verschiebung des Grenzwertes zu ermöglichen.

Die Bestimmung der minimalen und der maximalen Laufzeit wird nun anhand der Figuren Ia, Ib und Ic erläutert.

Das Verfahren startet in Figur Ib in einem Schritt 150. In einem Schritt 151 wird überprüft, ob ein Fehler aufgetreten ist (ERROR?). Ist ein Fehler aufgetreten, wird das Verfahren in einem Schritt 152 beendet. Ist kein Fehler aufgetreten, wird in einen Schritt 153 verzweigt.

In Schritt 153 werden zu der Minimallaufzeit T min die zugehörige Ober- und Untergrenze T_min> bzw. T_min< berechnet. Dies geschieht anhand der oben erwähnten Schrittweite. Anschließend wird in Schritt 154 die Tasklaufzeit T mit der Minimallaufzeit T_min verglichen. Ist die Tasklaufzeit T kleiner oder gleich der Minimallaufzeit T_min, wird mit Schritt 155 fortgefahren. Andernfalls wird zu einem Schritt 159 verzweigt.

In Verfahrensschritt 155 wird die Tasklaufzeit T mit der Untergrenze T_min< verglichen. Ist Tasklaufzeit T kleiner als die Untergrenze T_min<, wird mit Schritt 156 fortgefahren. Ansonsten wird zu Schritt 157 verzweigt.

In Schritt 156 wird die Minimallaufzeit T min gleich der Untergrenze T_min< gesetzt. In Schritt 157 wird die Minimallaufzeit T_min gleich der Tasklaufzeit T gesetzt. In beiden Fällen wird anschließend zu Schritt 159 verzweigt.

In Schritt 159 wird die Tasklaufzeit T mit der Obergrenze T_min> verglichen. Ist die Tasklaufzeit T größer als die Obergrenze T_min>, wird zu Schritt 161 verzweigt. Ist die Tasklaufzeit kleiner oder gleich der Obergrenze 12, wird zu Schritt 160 verzweigt.

Im Schritt 160 wird ein Zähler zl = 0 gesetzt. Nach Schritt 160 wird das Verfahren mit Schritt 152 beendet.

In Schritt 161 wird der Zähler zl um 1 erhöht. Nach Schritt 161 wird zu Schritt 162 verzweigt.

In Verfahrensschritt 162 wird der Zähler zl mit einem vorgebbaren Maximalwert Zl verglichen. Ist der Zähler zl größer oder gleich dem Maximalwert Zl, wird mit Schritt 163 fortgefahren. Ist der Zähler zl hingegen kleiner als der Maximalwert Zl, wird das Verfahren in Schritt 152 beendet.

In Schritt 163 wird der Zähler zl - 0 gesetzt. Anschließend wird in einem Schritt 164 die Minimallaufzeit T_min gleich der Obergrenze T_min> gesetzt.

Das Verfahren wird anschließend mit Schritt 152 beendet.

Die Auswirkungen des beschriebenen Verfahrens können anhand Figur Ia erläutert werden. In Figur Ia ist der Verlauf der Zeit t nach rechts aufgetragen. Befindet sich die effektive Tasklaufzeit T in einem Bereich 13, d.h. T < T_min, wird die Minimallaufzeit T min auf diese Zeit verringert. Allerdings ist der kleins- te Wert, den die Minimallaufzeit T_min dabei annehmen kann, durch die Untergrenze T_min< eingeschränkt. Tritt die Tasklaufzeit T eine definierte Anzahl (vorgebbarer Maximalwert Zl) in Folge im Bereich 14, d.h. T > T min, auf, wird die Minimallaufzeit T_min in positiver Achsenrichtung zur Obergrenze T_min> hin verschoben.

Die Maximallaufzeitberechnung ist nach dem gleichen Prinzip umgesetzt wie die Berechnung der Minimallaufzeit. Befindet sich die Tasklaufzeit T innerhalb eines Bereiches 24, d.h. T > T_max, wird die Maximallaufzeit T_max erhöht. Auch hier ist das Verschieben der Maximallaufzeit T_max durch die Schrittweite auf eine Obergrenze T_max> eingeengt. Ein aufeinander folgendes Auftreten der Laufzeit in einem Bereich 23, d.h. T < T_max<, setzt die Maximallaufzeit T_max auf die Untergrenze T_max< zurück. Ein zugehöriges Flussdiagramm ist in Figur Ic abgebildet.

Das Verfahren startet in einem Schritt 170. In einem Schritt 171 wird überprüft, ob ein Fehler aufgetreten ist (ERROR?). Ist ein Fehler aufgetreten, wird das

Verfahren in einem Schritt 172 beendet. Ist kein Fehler aufgetreten, wird in einen Schritt 173 verzweigt.

In Schritt 173 werden zu der Maximallaufzeit T_max die zugehörige Ober- und Untergrenze T_max> bzw. T_max< berechnet. Dies geschieht anhand der oben erwähnten Schrittweite. Anschließend wird in Schritt 174 die Tasklaufzeit T mit der Maximallaufzeit T_max verglichen. Ist die Tasklaufzeit größer oder gleich der Maximallaufzeit T_max, wird mit Schritt 175 fortgefahren. Andernfalls wird zu einem Schritt 179 verzweigt.

Im Verfahrensschritt 175 wird die Tasklaufzeit mit der Obergrenze T_max> verglichen. Ist die Tasklaufzeit kleiner oder gleich der Obergrenze T_max>, wird mit Schritt 176 fortgefahren. Ansonsten wird zu Schritt 177 verzweigt.

In Schritt 176 wird die Maximallaufzeit T_max gleich der Tasklaufzeit T gesetzt. In Schritt 177 wird die Maximallaufzeit T gleich der Obergrenze T_max> gesetzt. In beiden Fällen wird anschließend zu Schritt 179 verzweigt.

In Schritt 159 wird die Tasklaufzeit T mit der Untergrenze T_max< verglichen. Ist die Tasklaufzeit T größer oder gleich der Untergrenze T_max<, wird zu

Schritt 180 verzweigt. Ist die Tasklaufzeit T kleiner als die Untergrenze T_max<, wird zu Schritt 181 verzweigt.

In Schritt 180 wird ein Zähler z2 = 0 gesetzt. Nach Schritt 180 wird das Verfah- ren mit Schritt 172 beendet.

In Schritt 181 wird der Zähler z2 um 1 erhöht. Nach Schritt 181 wird zu Schritt 182 verzweigt.

In Verfahrensschritt 182 wird der Zähler z2 mit einem vorgebbaren Maximalwert

Z2 verglichen. Ist der Zähler z2 größer oder gleich dem Maximalwert Z2, wird

mit Schritt 183 fortgefahren. Ist der Zähler z2 hingegen kleiner als der Maximalwert Z2, wird das Verfahren in Schritt 172 beendet.

In Schritt 183 wird der Zähler z2 = 0 gesetzt. Anschließend wird in einem Schritt 184 die Maximallaufzeit T_max gleich der Untergrenze T_max< gesetzt. Das Verfahren wird anschließend mit dem Schritt 172 beendet.

Figur 2 ist ein Flussdiagramm, das die Berechnung eines Qualitätswerts gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zeigt.

Das Verfahren startet in einem Verfahrensschritt 200. In einem Verfahrensschritt 201 wird die effektive Tasklaufzeit T mit einer Minimallaufzeit T_min und einer Maximallaufzeit T_max verglichen. Liegt die effektive Tasklaufzeit innerhalb der genannten Zeiten, wird mit Schritt 202 fortgefahren. Liegt die effektive Tasklauf- zeit außerhalb des Zeitbereichs, wird zu Verfahrensschritt 208 verzweigt.

In Schritt 202 wird ein Zähler z3 um 1 erhöht. Anschließend wird in Schritt 203 der Zähler z3 mit einer vorgebbaren Qualitätshärte QH verglichen. Ist der Zähler z3 größer oder gleich der Qualitätshärte QH, wird mit Schritt 204 fortgefahren. Ansonsten wird zu einem Schritt 207 verzweigt, mit dem das Verfahren beendet wird.

In Schritt 204 wird der Zähler z3 = 0 gesetzt. In einem Verfahrensschritt 205 wird anschließend der Qualitätswert q mit einem vorgebbaren Maximalwert Q vergli- chen. Ist der Qualitätswert q kleiner als der Maximalwert Q, wird in einem Verfahrensschritt 206 der Qualitätswert um 1 erhöht. Anschließend wird das Verfahren in Schritt 207 beendet. Ist der Qualitätswert größer als der Maximalwert, wird das Verfahren im Anschluss an Schritt 205 unmittelbar mit Schritt 207 beendet.

In Verfahrensschritt 208 wird geprüft, ob der Zähler z3 größer 0 ist. Ist dies der Fall, wird der Zähler z3 in Verfahrensschritt 209 um 1 erniedrigt. Ist dies nicht der Fall, wird zu Verfahrensschritt 210 verzweigt.

Im Verfahrensschritt 210 wird überprüft, ob der Qualitätswert q größer 0 ist. Ist dies der Fall, wird der Qualitätswert q im Verfahrensschritt 211 um 1 erniedrigt. Anschließend wird das Verfahren in Schritt 207 beendet. Ist dies nicht der Fall, wird das Verfahren im Anschluss an Schritt 210 im Schritt 207 beendet.

Die Qualitätshärte QH gibt Aufschluss über die Genauigkeit der Minimal- und Maximallaufzeiten. Befindet sich die Tasklaufzeit zwischen diesen beiden Grenzwerten, wird der Zähler z3 erhöht. Der Zähler z3 ist global für jede Task angelegt und hat somit ein Gedächtnis, das über die Funktion hinaus besteht. Läuft dieser Zähler über den Wert der Qualitätshärte, wird die Qualität q (Quali- tätswert) um eins erhöht. Die Qualitätshärte ist für jede Task festlegbar. Sie kann als Multiplikationsfaktor der Qualität beschrieben werden. Liegt die Tasklaufzeit außerhalb der Grenzwerte, wird die Qualität um eins verringert.

Gemäß einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahren wird eine verbleibende, freie Zykluszeit berechnet. Dazu muss bekannt sein, welche Tasks im derzeitigen Zyklus aktiviert werden (enabled Task). Die Start- und Stopbits geben dabei Aufschluss über den aktuellen Status der Tasks.

Die freie Zykluszeit errechnet sich zu jedem Zeitpunkt beispielsweise nach folgender Gleichung:

Tfree ⁼ Tcyc " (T _a ct ⁺ Tf _u || + T _pre )

T _free : freie Zykluszeit

Tc _yc : Zykluszeit (z. B. 20000 μs)

T _act : aktueller Zeitstempel

T _fu ii: Summe(Maximallaufzeiten noch nicht aktivierter Task), [Startbit =

0]

T _pre : Summe(Restlaufzeiten, der preempted Tasks), [Startbit = 1, Stopbit = 0]

Um die Restlaufzeit der unterbrochenen (preempted) Task zu ermitteln, wird neben der Maximallaufzeit (T _Ma χ) die bisherige Tasklaufzeit (T _Leff ) benötigt. Diese ist vorzugsweise global in einer Variablen gesichert. Demnach ergibt sich die Restlaufzeit wie folgt:

Tpre = Summe(T _Ma χ - TW)

Da die freie Zykluszeit durch die Maximalwerte errechnet wird, ist T _free ein ge- schätzter „worst case"-Wert. Es steht folglich mindestens noch die errechnete freie Zykluszeit zur Verfügung.

Das Steuerprogramm (sog. Guardian) ist dafür vorgesehen, einer Task eine bestimmte Laufzeit zur Verfügung zu stellen. Wird diese überschritten, beendet es die Task. Ziel des Steuerprogramms ist es dabei, dass allen weiteren Tasks noch genügend Restlaufzeit zur Verfügung steht, um ordnungsgemäß abzulaufen.

Diese Restlaufzeit setzt sich zusammen aus der maximalen Tasklaufzeit (T _Max ) und der freien Zykluszeit. Die freie Zykluszeit (T _free ) kann dabei als Puffer verstanden werden, den das Steuerprogramm mit berücksichtigt. Die vom Steuerprogramm zur Verfügung gestellte Laufzeit (T _Guar d) errechnet sich gemäß des erläuterten Beispiels zu:

T _Guard (TASK) = T _Max (TASK) + T _free (TASK)

Da es sich bei der maximalen Tasklaufzeit um einen Erfahrungswert handelt, weist die Analysis- Funktion dieser einen Qualitätswert zu. Anhand der Qualität wird die Wahrscheinlichkeit verdeutlicht, mit welcher sich die Laufzeit der Task zwischen der minimalen und maximalen Laufzeit befindet. Um Fehlentscheidun- gen des Guardian zu unterbinden, kann dieser in einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens erst aktiviert werden, wenn die Qualität einen vorbestimmten Wert erreicht hat. Dieser Wert ist für jede Task festlegbar.

In einem periodischen System müssen die einzelnen Tasks innerhalb der festgelegten Zyklusdauer abgearbeitet sein. In Figur 3 sind beispielhafte Zyklen abgebildet. Figur 3a zeigt einen Zyklusverlauf, in dem die Tasks A, B, C und D nacheinander ausgeführt werden und bis zum nächsten Zyklusbeginn 300 noch eine freie, ungenutzte Zeit 310 verbleibt.

In Figur 3b hat sich Task C aufgehängt und der weitere Programmablauf ist nicht mehr möglich. Die Priorität der Task C ist hier so hoch, dass auch die Tasks A und B in einem nachfolgenden Zyklus nicht mehr ausführbar sind.

Figur 3c beschreibt den gleichen Zustand, jedoch unter Einsatz des Guardian bzw. Steuerprogramms. Der Guardian bricht Task C ab, nachdem die Task die vorbestimmte Zeitdauer 311 überschritten hat. Die übrige Laufzeit 312 reicht aus, um Task D erfolgreich auszuführen.

In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist eine weitere Task vorgesehen, die von dem Steuerprogramm nicht beendbar ist. Eine derartige Task wird im folgenden auch als kritischer Bereich bezeichnet. Kritische Bereiche können vor Abbruch durch den Guardian geschützt werden. Dazu sind beispielsweise bestimmte Funktionen vorgesehen, die eine kritische Sektion einleiten und abschließen. Die Funktionen werden z.B. bei dem Schreiben in globale Variablen genutzt.

Der Datenaustausch zwischen Tasks wird, neben Messages, bei größeren Datenmengen über globale Variablen realisiert. Dabei sollte beachtet werden, dass dies in einem einzigen Bereich geschieht und dieser gegen Unterbrechung durch den Guardian geschützt ist.

Wird das Schreiben globaler Daten auf mehrere Bereiche verteilt, kann die Abhängigkeit der Variablen untereinander durch den Abbruch der Task verletzt werden.

Der Guardian ist nicht in der Lage, die durch einen Abbruch verloren gegangenen Daten zu ersetzen.

In den folgenden Abschnitten wird nun beispielhaft dargestellt, wie diese Ausfüh- rungsform des erfindungsgemäßen Verfahrens auf einer Recheneinheit mit einem OSEK Betriebssystem implementiert werden kann.

Eine laufende Task kann nur durch eine Task von höherer Priorität oder durch eine ISR unterbrochen werden. Dabei wird vorteilhafterweise eine Unterbre- chung per Interrupt gewählt, da eine Unterbrechung per Alarm nicht mit einer Genauigkeit von Mikrosekunden möglich ist.

Es bietet sich an, einen Real-Time-Interrupt RTI zu verwenden. Der freilaufende Zähler verfügt beispielsweise beim TMS470 über zwei Vergleichsregister. Das CMPl-Register ist von OSEK für den System-Counter belegt. Das CMP2-

Register ist noch unbenutzt und kann verwendet werden. Da bereits Funktionen zur Ansteuerung des RTI-Zählers implementiert wurden, muss der OSEK-Layer vorteilhaft nur noch um Services zur Verwendung des zweiten Vergleichsregister ergänzt werden.

Der Guardian wird bevorzugt in der PreTaskHook- Routine der jeweiligen Task aufgerufen. Er legt eine so genannte Deadline (Abbruchzeitpunkt, vorbestimmte Zeitdauer) fest. Läuft die Task innerhalb der zur Verfügung gestellten Zeit ab, wird in deren PostTaskHook- Routine der Guardian wieder deaktiviert.

überschreitet eine Task X die Deadline, löst der RTI einen Interrupt aus und führt die im Oil-Konfiguartor definierte ISR (Guardian) aus. Damit der IRQ nicht erneut auftritt, muss der Guardian ebenfalls in der ISR deaktiviert werden.

Als Problem stellt sich jedoch dar, dass z. B. bei OSElVVDX eine Task nur in der Lage ist, sich selbst zu beenden. Ein Ausführen des Befehls TerminateTask innerhalb der ISR ist demnach nicht möglich. Das Betriebssystem muss sich in der laufenden Task X befinden um diese beenden zu können.

Der Befehl SUBS PC, LR, #4 dient als Rücksprung zur laufenden Task. Vor diesen Befehl wird vorteilhaft eine Umleitung eingeschoben. Da sich das Programm hier auf Assembler- Ebene befindet, müssen sämtliche Register, die das Programm im weiteren Ablauf ändert, gesichert und später wiederhergestellt werden. Die Register werden bevorzugt auf einen eigenen Stack gesichert. Das Link-Register des IRQ-Modus sollte dabei als letztes gespeichert werden, da dieses die Rücksprungadresse zur laufenden Task enthält.

Die eigentliche Umleitung wird realisiert, indem das LR(IRQ) mit der Adresse einer Funktion Kill Task zuzüglich einem Offset von vier Bytes geladen wird. Der Rücksprung durch den Befehl SLIBS PC, LR, #4 lädt den Inhalt des Link- Registers unter Subtraktion von vier Bytes in den Programmzähler und das Programm setzt den Ablauf mit der Funktion Kill Task fort. Der Rücksprungbefehl stellt ebenfalls das gesicherte CPSR-Register wieder her und der Prozessor befindet sich somit im Modus System.

Durch diese Maßnahme wird das Betriebssystem bzw. die Recheneinheit derart konfiguriert, dass es sich scheinbar in der Task X befindet. Die Funktion Termi- nateTask kann dadurch ausgeführt werden und die Task X beendet sich selbst.

Die Funktion Kill Task stellt zuerst fest, welche Task sich aktuell im laufenden Zustand befindet. Anhand des kritischen Bereichs wird geprüft, ob die Task beendet wird, oder der Ablauf in TASK X fortgesetzt werden soll. Bei einem Rücksprung zur laufenden Task müssen die gesicherten Register wiederhergestellt werden.

Gemäß einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens kann zusätzlich ein Watchdog vorgesehen sein. Der Watchdog ist ebenfalls, wie der Guardian, in der Lage, eine laufende Task zu beenden. Zusätzlich verfügt er über die Möglichkeit, einen Neustart des gesamten Systems durchzuführen. Im vorliegenden Beispiel überwacht er die Kommunikation der externen CAN-

Controller und erhält dadurch Aufschluss über die Funktionalität der Sensoren.

Das Betriebssystem versetzt TASK(System) z.B. periodisch alle 20 ms in den laufenden Zustand. Da diese Task die höchste Priorität im System besitzt, wird sie auch dann gestartet, wenn sich andere Tasks noch im Zustand RUNNING befinden.

Die Möglichkeit, eine Task durch den Watchdog zu beenden, kann als Ergänzung zum Guardian, oder als ein unabhängige Funktionalität verwendet werden. Während der Guardian als Prophylaxe fungiert und versucht den überlauf einer

Task zu vermeiden, ist der Watchdog für Tasks zuständig, die bereits übergelaufen sind. Er dient somit als Therapie bereits aufgetretener Fehler.

Der Watchdog ist damit die letzte Instanz, um eine Task zu beenden. Falls der Guardian die Task nicht beenden konnte (geschützter Bereich), versucht der

Watchdog dies erneut. Auch hier hat der kritische Bereich die höhere Priorität

und eine Task kann somit nur außerhalb eines solchen Bereichs, beendet werden.

Der Watchdog funktioniert unabhängig vom Guardian und ist nicht auf die Laufzeituntersuchung der Analysis Funktionen angewiesen. Der überlauf einer Task ist hier durch die Start- und Stopbits und dem aktuellen Taskzustand überprüfbar, wie es die nachfolgende Tabelle zeigt.

Auch hier besteht das Problem, dass OSEK keine Möglichkeit bietet, eine Task durch eine andere Task zu beenden.

Der Watchdog befindet sich in TASK(System). Diese Task besitzt die höchste Priorität und hat somit Vorrang vor jeder weiteren Task. Läuft eine TASK(Forever) über das Zyklusende hinaus, wird diese durch den periodischen Weckalarm von TASK(System) unterbrochen. Nach dem Beenden von TASK(System) würde die unterbrochene TASK(Forever) wieder in den Zustand RUNNING gehoben werden. Ziel ist es, diese Task nicht in den laufenden, sondern in den Zustand SUSPENDED zu überführen.

Während des Hochfahrens des Betriebssystems initialisiert dieses sämtliche Tasks mit einer Grundkonfiguration. Eine erste OS-Funktion weist dabei allen Tasks den Zustand SUSPENDED zu.

Eine weitere Funktion ist dieser ersten Funktion nachempfunden. Sie löscht die übergebene Task aus der Schlange der READY-Task und weist ihr den Zustand SUSPENDED zu.

Bei einem Aufruf des Scheduler überprüft dieser, welche Tasks sich im Zustand READY befinden. Die Task, die davon die höchste Priorität besitzt, wird in den laufenden Zustand gehoben.

Da der Stack jeder Task durch eine Funktion ActivateTask zur Verfügung ge- stellt wird, muss der Stackpointer beim Beenden der Task nicht zurück gesetzt werden.

Ein wichtiger Bestandteil des System stellt die CAN Kommunikation dar. Der CAN dient als Schnittstelle zwischen Sensoren sowie als Schnittstelle der Akto- ren und weiterer Steuergeräte. Die Kommunikation wird beispielsweise durch einen externen CAN-Controller realisiert. Der Watchdog überwacht ebenfalls diesen Bereich des Systems.

Bei der CAN Kommunikation können verschiedene Fehler auftreten. Funktions- Störung des CAN-Controllers, des Bus-Treibers oder der Sensoren können neben physikalischen Störeinflüssen auf den Leitungen die Kommunikation beeinträchtigen oder sogar zum Erliegen bringen. Jeder CAN-Controller verfügt über einen internen Fehlerzähler, der nach einer gewissen Fehleranzahl diesen vom Bus trennen kann (CAN wird hochohmig).

Seitens der Software besteht die Möglichkeit den CAN-Controller neu zu konfigurieren oder einen Warmreset durchzuführen. Durch einen solchen Reset wird ein vom Bus getrennter Controller wieder aktiviert.

Der CAN-Controller ist mit so genannten Mailboxen ausgestattet. Eine Mailbox kann zum Senden oder zum Empfangen konfiguriert sein. Weiterhin ist ihr ein

Identifier als Adresse zur Identifizierung zugeordnet. Um eine Nachricht zu versenden, wird diese in der Sendemailbox abgelegt und ein Sendebit gesetzt. Sämtliche Knoten am Bus sind in der Lage, die Nachricht zu empfangen. Der erfolgreiche Empfang einer Nachricht wird durch einen Acknowledgement- Mechanismus (ACK-Mechanismus) quittiert.

Innerhalb der CAN-Nachricht befindet sich der ACK-Slot. Es handelt sich dabei um ein Bitfeld, das vom Sender mit einem rezessiven Buspegel (high) belegt wird. Ein Netzknoten bestätigt den fehlerfreien Empfang einer Nachricht, indem er dieses Bitfeld mit einem dominanten Buspegel (low) überlagert. Erkennt ein Sender innerhalb dieses ACK-Slots einen dominanten Pegel, kann er erkennen, dass zumindest ein Empfänger die Nachricht richtig empfangen hat.

Ein AC K- Fehler liegt dann vor, wenn der Acknowledgement-Slot rezessiv belegt ist. Dieser Fall kann auftreten, wenn kein Empfänger die Nachricht richtig empfangen hat, oder wenn sich keine weiteren Netzknoten am Bus befinden. Als Reaktion auf einen solchen erkannten Fehler überträgt der Sender eine Error- Frame. Bei einer "Punkt zu Punkt"- übertragung kann der ACK-Mechanismus somit als Ausfallerkennung verwendet werden.

Das erfolgreiche Versenden einer Nachricht wird im Statusregister des CAN- Controllers durch ein Transmission-OK- Bit (TXOK) signalisiert. Den fehlerfreien Empfang einer Nachricht zeigt ein Receive-OK-Bit (RXOK) an.

In der Senderoutine wartet eine Funktion so lange, bis das TXOK-Bit gesetzt ist. Ist das Flag innerhalb einer maximalen Wartezeit nicht gesetzt, gibt die Funktion einen Fehler (Error ungleich Null) zurück. Analog dazu wartet eine Empfangsroutine auf das RXOK-Bit und gibt bei einem überschreiten der Wartezeit ebenfalls einen Fehler zurück.

Ein Fehler in der Sende- oder Empfangsroutine wird in entsprechenden Variablen dokumentiert und durch den Watchdog ausgewertet. Nach der Auswertung setzt dieser die Flags wieder zurück. Der Watchdog überprüft die Error-Flags der Variablen und ergreift ggf. Maßnahmen, um die CAN Kommunikation auf- recht zu erhalten. Dabei wird zwischen Sensor-CANs (CAN1-4) und CAN- Controllern, die mit Steuergeräten verbunden sind (CAN5-6), unterschieden. Während bei CAN5-6 Fehler durch die Senderoutine erkannt werden, ist bei CAN-Controllern, die mit den Sensoren kommunizieren, nur dann ein Fehler aufgetreten, wenn die Empfangsroutine mit einem Fehler abgebrochen hat. Hat die Empfangsroutine erfolgreich Daten empfangen, muss somit auch die Senderoutine fehlerfrei abgelaufen sein, da die Sensoren keine Nachrichten ohne einen Sendefehl verschicken.

In einem Fehlerfall versucht der Watchdog zunächst, diesen durch eine erneute Konfiguration des CAN-Controllers zu beheben. Besteht der Fehler weiterhin, wird ein Warmreset (Rescue CAN Reset) des CAN-Controllers durchgeführt. Tritt der Fehler bei einem Sensor-CAN auch künftig auf, kann davon ausgegangen werden, dass der entsprechende Sensor nicht mehr funktionsfähig ist. Der Watchdog versucht in diesem Fall, den defekten Sensor softwareseitig vom System zu trennen. Da z. B. das 2D-Tracking mindestens zwei Sensoren zur

Triangulation benötigt, überprüft eine Funktion Rescue_CAN_Off zunächst, ob aktuell mehr als zwei Sensoren aktiv sind. Ist dies der Fall, entfernt sie den entsprechenden Sensor aus einem Feld Sensor_aktiv. Sind jedoch nicht genügend Sensoren angeschlossen, wird ein Reset ausgeführt.

Erkennt der Watchdog einen Fehler bei einem CAN-Controller, wird ein zugeordneter Fehlerzähler des jeweiligen CAN (errorCANCntg) erhöht. Die aktuelle Zahl des Fehlerzählers entscheidet, ob der Watchdog eine Konfiguration, einen Reset, oder das Abschalten des CAN als Lösung versucht. Es können dazu ent- sprechende Grenzen zur Kompilationszeit bestimmt werden. Der Fehlerzähler

des CAN wird nach einer bestimmten Anzahl von fehlerfreien Zyklen auf Null gesetzt.

Als weiterer Fehlerzähler kann ein watching.Error_counter vorgesehen sein. Der globale Fehlerzähler des Watchdog registriert sämtliche Fehler, die im System auftreten. Auch er wird erst nach mehreren fehlerfreien Zyklen in Folge zurückgesetzt. überschreitet der Zähler eine festgelegte Anzahl von Fehlern, ist das System als nicht mehr lauffähig zu beurteilen. Der Watchdog führt dann einen Neustart des Systems aus.

Der Neustart ist z. B. in der Hook- Routine ShutdownHook implementiert. Der Vorteil besteht darin, dass bei einem fehlerbedingten Herunterfahren des Betriebssystems ebenfalls diese Routine aufgerufen wird und das System von neuem anläuft. Die Fehlerbehandlung des OS ist somit ebenfalls berücksichtigt.

Ein Neustart wird durch einen Sprung zum Startvektor des Prozessors realisiert. Der Startvektor ist die Adresse, die z. B. nach einem Hardwarereset des TMS470 in den Programmzähler geladen wird.

Gemäß einer weiteren bevorzugten Ausgestaltung kann eine Lösungsliste vorgesehen sein. Erkennt der Watchdog einen Fehler, führt er die Lösung nicht sofort aus, sondern fügt diese in eine Lösungsliste ein. Dabei bekommt die Lösung einen Wert sowie einen übergabeparameter zugeordnet. Die Lösung ist somit eindeutig identifizierbar.

Der Vorteil des Einsatzes einer Lösungsliste besteht darin, dass erst sämtliche Lösungen bekannt sind, bevor diese ausgeführt werden. Dadurch lässt sich z.B. ein mehrfaches Ausführen derselben Lösung verhindern.

Eine Funktion addSolution fügt eine Lösung der Liste hinzu. Dabei überprüft sie, ob diese bereits in der Liste enthalten ist. Ist das der Fall, braucht sie nicht er-

neut in die Liste eingetragen zu werden. Bei bestimmten Lösungen (CAN konfigurieren, CAN Reset) wird zu einer bestehenden Lösung der Parameter ergänzt. Da eine Konfiguration oder ein Reset mehrerer CAN-Controller gleichzeitig durchgeführt werden kann, werden in der Lösung nur noch die entsprechenden CAN als Parameter hinzugefügt (logisches oder).

Sind alle Fehlermöglichkeiten durch den Watchdog ausgewertet, wird die gefüllte Lösungsliste abgearbeitet. Bevor eine Lösung ausgeführt wird, überprüft eine ausführende Funktion execSolution, ob die freie Zeit noch ausreichend ist, um die Lösung abzuarbeiten. Eine weitere Liste dur_solution mit den Ausführungszeiten der einzelnen Lösungen kann dazu vorteilhaft verwendet werden. Diese ist mit den Laufzeiten zu füllen.

Es versteht sich, dass die vorstehend erläuterten bevorzugten Ausführungsfor- men des erfindungsgemäßen Verfahrens nur beispielhaft zu verstehen sind. Daneben sind für einen Fachmann weitere Lösungen denkbar, ohne den Rahmen der vorliegenden Erfindung zu verlassen.