DE10231668A1

DE10231668A1 - Multitaskingbetriebssystem zur Verringerung des Stromverbrauchs und elektronische Steuerung im Fahrzeug, die selbiges benutzt

Info

Publication number: DE10231668A1
Application number: DE10231668A
Authority: DE
Inventors: Kiichiro Hanzawa
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2001-07-12
Filing date: 2002-07-12
Publication date: 2003-01-30
Anticipated expiration: 2022-07-13
Also published as: US20030014467A1; JP2003029886A; DE10231668B4; US7386853B2; JP3610930B2

Abstract

Ein Echtzeitbetriebssystem (RTOS) für eine elektronische Steuereinheit (ECU) (10) im Fahrzeug schaltet (120-140) die CPU (12) der Fahrzeug-ECU in einen Modus mit niedrigem Stromverbrauch (LPC-Modus), wenn es keine Task in einem Betriebszustand und in einem Betriebsklarzustand gibt, und ferner die verbleibende Zeit, bevor eine Task in einem Aussetzzustand in den Betriebsklarzustand geschaltet wird, länger als eine vorbestimmte zulässige Minimaldauer des LPC-Modus ist. Die Dauer des LPC-Modus wird auf eine Länge eingestellt, die kürzer als die verbleibende Zeit ist, bevor eine Task in dem Aussetzzustand in den Betriebsklarzustand geschaltet wird. Wenn ein Interrupt auftritt, oder die Dauer des LPC-Modus abläuft, wird die CPU in einen normalen Modus geschaltet und das temporäre Aussetzen der Systemuhr während des LPC-Modus wird unter Verwendung der Dauer des LPC-Modus kompensiert (170, 180).

Description

Die vorliegende Erfindung bezieht sich auf ein Multitaskingbetriebssystem.
In manchen Computersystemen läuft die CPU eines Mikrocomputers in einem normalen Modus und einem Modus mit niedrigem Stromverbrauch (bzw. low-power-consumption mode oder LPC-Modus). Bei dem LPC-Modus läuft die CPU mit niedrigeren Taktfrequenz, oder das Takten wird zur Verringerung des Stromverbrauches abgestellt. Wenn die CPU von dem normalen Modus in den LPC-Modus wechselt, wird die Ausführung einiger Programme beendet. Daher enthält das Computersystem ein geeignetes Programm, das die geeignete Zeit zum Wechseln von dem normalen Modus in den LPC-Modus, und die geeignete Dauer des LPC-Modus bestimmt. Dadurch wird die CPU zwischen dem normalen Modus und dem LPC-Modus so umgeschaltet, dass der Betrieb des Computersystems nicht unterbrochen wird.
Eine elektronische Steuerung (bzw. electronic control unit oder ECU) für eine Tür (bzw. Tür-ECU), die ein Computersystem mit einem Mikrocomputer darstellt, steuert das Türschloss in einem Fahrzeug, wobei sie zwischen einem normalen Modus und einem aussetzenden Modus (d. h. LPC-Modus) wechselt. Bezugnehmend auf Fig. 8 führt die Tür-ECU im normalen Modus die Prozesse A, B, C, . . ., n z. B. alle 5 ms aus. Jeder der Prozesse A, B, C, . . ., n ist ein Anwendungsprogramm, das eine vorbestimmte Funktion umsetzt. Z. B. setzt der Prozess A ein schlüsselloses Schlosssystem (bzw. keyless entry system) in Gang, während der Prozess B ein Türenschließsystem (bzw. door lock system) in Gang setzt.
Jeder dieser Prozesse A, B, C, . . ., n setzt ein Flag, das anzeigt, ob der LPC-Modus während der Ausführung akzeptabel ist, oder nicht. Der Prozess B setzt das Flag zum Anzeigen, dass der Prozess B den LPC-Modus akzeptieren kann, wenn die verstrichene Zeit, nachdem die Türen verriegelt wurden, mindestens zehn Minuten ist.
Nachdem die Ausführung der Prozesse A, B, C, . . ., n beendet ist, bestimmt ein Manager-Prozess auf der Grundlage der Flags, ob die CPU in dem normalen Modus oder dem LPC-Modus laufen soll. Wenn alle Flags gesetzt sind, d. h. alle Prozesse A, B, C, . . ., n den LPC-Modus akzeptieren können, setzt der Manager die CPU auf den LPC-Modus. Wenn mindestens ein Flag nicht gesetzt ist, setzt der Manager die CPU auf den normalen Modus.
Bezugnehmend auf Fig. 9 führt in dem normalen Modus die CPU die Prozesse A, B, C, . . ., n alle 5 ms (T1) aus, wie oben beschrieben. Aber die CPU kann die Prozesse A, B, C, . . ., n alle 300 ms (T2) ausführen, und dann wird die CPU auf den LPC-Modus gesetzt, während eines Zeitintervalls T3 zwischen der Beendigung der Ausführung der Prozesse A, B, C, . . ., n und dem Beginn der nächsten Ausführung der Prozesse A, B, C, . . ., n. Somit wird die CPU zwischen dem normalen Modus und dem LPC-Modus so umgeschaltet, dass die Ausführung der Prozesse A, B, C, . . ., n nicht unterbrochen wird.
Allerdings ist eine Serie von Prozessen A, B, C, . . ., n, die in regelmäßigen Intervallen wiederholt ausgeführt werden soll, in einem großem Umfang schwer zu programmieren. Ferner kann die Zeit, die zur Ausführung der Serie von Prozessen A, B, C, . . ., n benötigt wird (T0 in Fig. 9), manchmal lang sein, so dass die Ansprechempfindlichkeit des Systems in diesem Fall verringert wird. Um dieses Problem zu lösen, wird ein Multitaskingbetriebssystem, wie z. B. ein Echtzeitbetriebssystem (bzw. real time operating system oder RTOS) verwendet. Das Multitaskingbetriebssystem behandelt mehrere Prozesse eines Programms als Tasks, und führt das Programm durch wechseln der Tasks aus. Somit enthält das Multitaskingbetriebssystem nicht nur einen Mechanismus zum regulären Ausführen eines Programmes, sondern auch einen Mechanismus zum Ausführen eines Programmes durch umständliches Wechseln von Tasks.
Wenn das Multitaskingbetriebssystem ein Programm durch wechseln von Tasks ausführt, verändern sich die Zustände der Tasks ständig entsprechend der Priorität, und abhängig vom Auftreten von Interrupts und der Ausgabe von Systemaufrufen. Dementsprechend kann ein Zeitintervall zwischen der Beendigung der Ausführung der Tasks und dem Beginn der nächsten Ausführung der Tasks nicht einfach berechnet werden. Ferner kann die angemessene Zeit zum Umschalten der CPU in den LPC-Modus nicht einfach bestimmt werden.
Es ist daher die Aufgabe der vorliegenden Erfindung ein Multitaskingbetriebssystem bereitzustellen, das die CPU eines Mikrocomputers zwischen einem normalen Modus und einem Modus mit niedrigem Stromverbrauch (LPC-Modus) schaltet, so dass die Ausführung von Programmen nicht unterbrochen wird.
Diese Aufgabe wird mit den in Anspruch 1 angegebenen Maßnahmen gelöst. Weitere vorteilhafte Ausgestaltungen der vorliegenden Erfindung sind Gegenstand der abhängigen Ansprüche.
Ein Betriebssystem gemäß der vorliegenden Erfindung steuert den Betrieb der CPU eines Mikrocomputers. Das Betriebssystem enthält eine erste Einrichtung zum Verwalten mehrerer Tasks, und eine zweite Einrichtung zum Umschalten der CPU in einen LPC-Modus. Die Vielzahl der Tasks werden zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand geschaltet. Die zweite Einrichtung schaltet die CPU in den LPC-Modus, wenn es im Betriebszustand und im Betriebsklarzustand keine Task gibt. Die Dauer des LPC-Modus wird auf der Grundlage der minimalst verbleibenden Zeit bestimmt, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, wenn es eine Task in dem dritten Zustand gibt, und die verbleibende Zeit, bevor die Task in den Betriebsklarzustand geschaltet wird, bekannt ist.
Vorzugsweise schaltet das Betriebssystem die CPU nur in den LPC-Modus, wenn das Minimum der verbleibenden Zeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, länger als eine vorbestimmte zulässige Minimaldauer des LPC-Modus ist. Ferner setzt das Betriebssystem die Dauer des LPC-Modus auf eine Länge, die kürzer als das Minimum der verbleibenden Zeit ist, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird. Weitere Einzelheiten, Aspekte und Vorteile der vorliegenden Erfindung ergeben sich aus der illustrativ und nicht einschränkend zu verstehenden Beschreibung vorteilhafter Ausführungsformen der Erfindung anhand der Zeichnung.
Fig. 1 ist ein Blockdiagramm, das ein Karosseriesystem zeigt, das eine Karosserie-ECU (bzw. eine elektronische Steuerung für die Karosserie) enthält, auf der ein Echtzeitbetriebssystem (RTOS) gemäß einer Ausführungsform der vorliegenden Erfindung installiert ist;
Fig. 2 ist ein schematisches Diagramm, das zeigt wie ein normaler Modus und ein Modus mit niedrigem Stromverbrauch (LPC-Modus) in der CPU der Karosserie-ECU umgesetzt werden;
Fig. 3 ist ein Zustandsfolgediagramm von Tasks, die ein Programm bilden, das von der CPU der Karosserie-ECU ausgeführt wird;
Fig. 4 ist ein Graph, der darstellt wie das RTOS eine Vielzahl von Tasks sendet und die CPU zwischen einem normalen Modus und einem LPC-Modus umschaltet;
Fig. 5 ist ein Flussdiagramm eines Prozesses zum Verwalten der Betriebsart der CPU;
Fig. 6 ist ein schematisches Diagramm, das darstellt wie Alarme entsprechend der jeweiligen Tasks dekrementiert werden;
Fig. 7 ist ein Graph, der darstellt, wie der Alarm auf Grundlage des Wertes des Systemtaktes zu Ende geht, und wie die Verzögerung des zu Ende gehens gemäß einer Modifikation der vorliegenden Erfindung verhindert wird;
Fig. 8 ist ein Flussdiagramm eines Prozesses zum Verwalten der Betriebsart der CPU entsprechend dem Stand der Technik; und
Fig. 9 ist ein Graph, der darstellt, wie ein Betriebssystem entsprechend dem Stand der Technik die CPU zwischen einem normalen Modus und einem LPC-Modus schaltet.
Die vorliegende Erfindung wird mit Bezug auf eine Ausführungsform und Modifikationen beschrieben werden. Ein Betriebssystem gemäß einer Ausführungsform der vorliegenden Erfindung ist auf der Karosserie-ECU des Karosseriesystems eines Fahrzeugs installiert. Bezugnehmend auf Fig. 1 enthält das Karosseriesystem 100 eine Karosserie-ECU 10 und andere ECUs 20, die da sind, eine Fahrertür-ECU 20a, eine Beifahrertür-ECU 20b und eine Armaturenbrett-ECU 20c. Die ECUs 10 und 20 sind an das Fahrzeug-LAN 50 angeschlossen, und deshalb kann die Karosserie-ECU 10 mit jedem anderen der ECUs 20 über das Fahrzeug-LAN 50 kommunizieren. Jedes der ECUs 10 und 20 ist ein Computersystem, das eine Zentraleinheit (CPU), einen ROM-Speicher (ROM), einen RAM-Speicher (RAM) und ein I/O Subsystem (I/O) enthält. Die Karosserie-ECU 10 ist an das Fahrzeug-LAN 50 durch das I/O Subsystem 18 angeschlossen. Jedes der ECUs 20 ist an eine Eingabevorrichtung 30, Ausgabevorrichtungen 40 und an das Fahrzeug-LAN 50 durch das I/O Subsystem angeschlossen.
Jedes der ECUs 20 erfasst den Zustand der Eingabevorrichtung 30, und sendet über das Fahrzeug-LAN 50 ein Paketsignal, das die Information über den erfassten Zustand der Eingabevorrichtung 30 an die Karosserie-ECU 10 enthält. Ferner empfängt jedes der ECUs 20 ein Paketsignal über das Fahrzeug-LAN 50, das Steuerungsinformation von der Karosserie-ECU 10 enthält, und steuert die Ausgabevorrichtung 40 auf der Grundlage der empfangenen Steuerungsinformation.
Die Fahrertür-ECU 20a ist in der Tür auf der Fahrerseite angeordnet. Ein Fahrertürsteuerungsschalter 30a ist als eine Eingabevorrichtung 30 an die Fahrertür-ECU 20a angeschlossen. Ein Motor 40a, der für ein Fahrertürschloss verwendet wird, und ein Motor, der für einen elektrischen Fensterheber in der Fahrertür benutzt wird, werden an die Fahrertür-ECU 20a als Ausgabevorrichtungen 40 angeschlossen. Die Beifahrertür-ECU 20b ist in der Tür auf der Beifahrerseite angeordnet. Ein Beifahrertürsteuerungsschalter 30b ist an die Beifahrertür-ECU 20b als eine Eingabevorrichtung 30 angeschlossen. Ein Motor 40b, der für ein Beifahrertürschloss benutzt wird, und ein Motor, der für einen elektrischen Fensterheber auf der Beifahrerseite benutzt wird, werden an die Beifahrertür-ECU 20b als Ausgabevorrichtungen 40 angeschlossen. Die Amaturenbrett-ECU 20c ist in dem Amaturenbrett angeordnet. Ein Summer 40c und eine Lampe 40d sind an die Amaturenbrett-ECU 20c als Ausgabevorrichtungen 40 angeschlossen.
Die Karosserie-ECU 10 empfängt Paketsignale von den anderen ECUs 20, und überwacht den Zustand der Eingabevorrichtungen 30 auf der Grundlage der Information, die in den Paketsignalen enthalten ist. Die Karosserie-ECU 10 sendet Paketsignale, die Steuerinformation zum Anweisen der ECUs 20 enthält, um die Ausgabevorrichtungen 40 zu steuern.
Das Echtzeitbetriebssystem (RTOS) gemäß der vorliegenden Ausführungsform ist in dem ROM-Speicher 14 der Karosserie-ECU 10 gespeichert, und wird von der CPU 12 zum Verwalten der Ausführung eines Anwendungsprogramms ausgeführt, das in dem ROM-Speicher 14 gespeichert ist. Das RTOS behandelt Prozesse des Anwendungsprogramms als Tasks, und führt das Anwendungsprogramm durch wechseln der Tasks aus. Demzufolge funktioniert die Karosserie-ECU 10 in oben beschriebener Weise, während sie den RAM- Speicher 16 und das I/O Subsystem 18 steuert, das an das Fahrzeug-LAN 50 angeschlossen ist. Ferner verwaltet das RTOS verschiedene Resourcen. Z. B. verwaltet das RTOS die Betriebsart, wie z. B. einen Stromverbrauchsmodus.
Bezugnehmend auf Fig. 2 läuft die CPU 12 der Karosserie-ECU 10 in zwei Betriebsarten, d. h. einem normalen Modus und einem Modus mit niedrigem Stromverbrauch (LPC- Modus) (d. h. Ruhemodus). Im normalen Modus läuft die CPU 12 entsprechend eines Rechnertaktes bei einer Frequenz von 16 MHz (4 MHz × 4), und führt dadurch das in dem ROM- Speicher 14 gespeicherte Programm aus. Im LPC-Modus ist das Takten der CPU 12 abgestellt, so dass der Stromverbrauch verringert wird.
Wenn die CPU 12 in den LPC-Modus wechselt, setzt sie zunächst einen Weck-Timer auf eine vorbestimmte Dauer des LPC-Modus (d. h. Ruhedauer) und führt danach einen Ruhe- Befehl aus. Die CPU 12 wechselt von dem LPC-Modus in einen normalen Modus, wenn die aktuelle Dauer des LPC-Modus die vorbestimmte Ruhedauer erreicht. Ferner wechselt die CPU 12 von dem LPC-Modus in den normalen Modus, wenn ein Interrupt auftritt, selbst wenn die aktuelle Dauer des LPC-Modus noch nicht die vorbestimmte Ruhedauer erreicht hat.
Das RTOS verwaltet die Tasks wie folgt. Bezugnehmend auf Fig. 3 schaltet das RTOS jeden der Tasks zwischen vier Zuständen, d. h. "Betrieb", "Betriebsklar", "Wartet", und "Ausgesetzt". Eine Task in Ausführung ist im "Betrieb"-Zustand (bzw. Betriebszustand). Eine Task, die wartet ausgeführt zu werden, ist im "Betriebsklar"- Zustand (bzw. Betriebsklarzustand). Eine Task, die auf ein Ereignis wartet, das eintritt, zum Auslösen der Ausführung der Task, ist im "Wartet"-Zustand (bzw. Wartezustand). Eine ausgesetzte Task ist im "ausgesetzt" Zustand (bzw. Aussetzzustand).
Die maximale Anzahl von Tasks im Betriebszustand ist gleich der Anzahl der Tasks, die die Karosserie-ECU 10 gleichzeitig ausführen kann. Daher ist die maximale Anzahl der Tasks im Betriebszustand in der vorliegenden Ausführungsform 1, da die Karosserie-ECU 10 die Einzel- CPU (bzw. Single-CPU) enthält. Im Gegensatz dazu ist die maximale Anzahl der gleichzeitig ausführbaren Tasks in jedem der anderen Zustände größer.
Wenn die Ausführung eines Tasks im Betriebszustand fertiggestellt ist, gibt die Task einen Beende-Task- Systemaufruf an das RTOS aus. Im Ansprechen auf den Beende-Task-Stemaufruf schaltet das RTOS die Task im Betriebszustand in den Aussetzzustand. Wenn eine Task im Betriebszustand auf ein vorbestimmtes Ereignis warten soll, gibt die Task einen Warte-auf-Ereignis-Systemaufruf an das RTOS aus. Im Ansprechen auf den Warte-auf- Ereignis-Systemaufruf schaltet das RTOS die Task in den Wartezustand.
Wenn eine Task im Betriebszustand in einen anderen Zustand umgeschaltet wird, kann das RTOS von neuem beginnen eine Task auszuführen. Dann wählt das RTOS eine Task mit der höchsten Priorität von den Tasks aus, die in dem Betriebsklarzustand sind, und schaltet das ausgewählte Task in den Betriebszustand. Dann wird das ausgewählte Task abgesendet und ausgeführt.
Wenn eine Task höhere Priorität als eine Task im Betriebszustand in den Betriebsklarzustand geschaltet wird, schaltet das RTOS die Task im Betriebszustand in den Betriebsklarzustand und schaltet dann die Task höherer Priorität in den Betriebszustand. Somit preemptiert das RTOS bzw. entzieht der Task die CPU. D. h. das RTOS gemäß der vorliegenden Ausführungsform ist ein preemptives Multitaskingbetriebssystem.
Eine Task im Aussetzzustand wird in den Betriebsklarzustand geschaltet, wenn eine vorbestimmte Bedingung erfüllt ist. Die Bedingung für das Schalten wird für jede Task bestimmt. Die Bedingung ist, dass (1) ein Timer (Alarm) abläuft (d. h. der Timer zeigt an, dass eine eingestellte Zeit verstrichen ist), (2) einer der vorbestimmten Interrupts auftritt, oder (3) die Ausführung einer Task, an die die Task im Aussetzzustand gekettet ist, fertiggestellt ist.
Eine Task im Aussetzzustand wird in den Betriebsklarzustand auf der Grundlage der Bedingung (1) wie folgt geschaltet. Der Timer (Alarm) ist für jedes Task bereitgestellt. Durch herausgeben eines Systemaufrufs weist die Task im Betriebszustand das RTOS an, eine vorbestimmte Task nach einem Intervall mit vorbestimmter Zeitlänge (z. B. 100 ms) zu aktivieren. Das RTOS stellt den Timer auf die vorbestimmte Zeitlänge ein, und überwacht danach den Timer. Wenn eine vorbestimmten Zeitdauer verstrichen ist, d. h. wenn der Timer abläuft, schaltet das RTOS die Task im Aussetzzustand in den Betriebsklarzustand.
Wenn ein Interrupt auftritt, wird ein zu schaltendes Task entsprechend dem Typ des Interrupts ausgewählt, und dann in den Betriebsklarzustand geschaltet. Somit wird eine Task im Aussetzzustand in den Betriebsklarzustand auf Grundlage der Bedingung (2) geschaltet.
Eine Task im Aussetzzustand wird in den Betriebsklarzustand auf Grundlage der Bedingung (3) wie folgt geschaltet. Wenn die Karosserie-ECU 10 Information über den Zustand des Türschlosses erhalten soll, überprüft die Karosserie-ECU 10 zunächst den Zustand des Türschlosses im Innern und danach den Zustand des Türschlosses außen. In diesem Fall wird zuvor eine Task B zum Überprüfen des Zustandes des Türschlosses außen an eine Task zum Überprüfen des Zustandes des Türschlosses im Innern gekettet, so dass diese Tasks A, B aufeinanderfolgend ausgeführt werden. Wenn die Tasks A, B so gesetzt sind, wird die Task B von dem Aussetzzustand in den Betriebsklarzustand geschaltet, wenn die Ausführung der Task A fertiggestellt ist.
Wenn eine Task im Betriebszustand einen Setze-Ereignis-Systemaufruf ausgibt, wird eine Task in Übereinstimmung mit einem Ereignis, das durch den Setze-Ereignis-Systemaufruf spezifiziert ist, von dem Wartezustand in den Betriebsklarzustand geschaltet.
Auf diese Weise verändern sich die Zustände der Tasks laufend abhängig vom Auftreten von Interrupts und der Herausgabe von Systemaufrufen. Bezugnehmend auf Fig. 4, werden z. B. Tasks A, B, n in rascher Folge ausgeführt und danach wird die Task B nach einer relativ langen Zeitspanne ausgeführt. In diesem Fall ist, wenn die Ausführung der Task A fertiggestellt ist, d. h. wenn die Task A vom Betriebszustand in den Aussetzzustand oder Wartezustand geschaltet wird, die Task B im Betriebsklarzustand. Daher beginnt das RTOS die Ausführung der Task B unmittelbar nachdem die Ausführung der Task A fertigge stellt ist. Demgegenüber ist, wenn die Ausführung der Task n fertiggestellt ist, d. h. wenn die Task n von dem Betriebszustand in einen anderen Zustand geschaltet wird, keine Task im Betriebsklarzustand. Daher wird für eine Weile keine Task ausgeführt. Danach wird die Task B in den Betriebsklarzustand geschaltet. Dann wird die Task von dem Betriebsklarzustand in den Betriebszustand geschaltet und ausgeführt.
Das RTOS verwaltet die Betriebsart der CPU 12 wie folgt. Bezugnehmend auf Fig. 5 werden die Tasks bei Schritt 110 geplant, und danach wird bei Schritt 120 bestimmt, ob es eine Task im Betriebsklarzustand oder eine Task im Betriebszustand gibt. Wenn ja kehrt der Prozess zu Schritt 110 zurück, um die Tasks abermals zu planen. Wenn nicht (d. h. es gibt keine Tasks im Betriebsklarzustand und keine Task im Betriebszustand) fährt der Prozess mit Schritt 130 fort.
Bei Schritt 130 wird bestimmt, ob die verbleibende Zeit, bevor eine Task im Aussetzzustand in einen Betriebsklarzustand basierend auf obiger Bedingung (1) geschaltet wird (d. h. die verfügbare Zeit für den LPC- Modus) größer ist als eine vorbestimmte Zeitdauer. Die vorbestimmte Zeitdauer ist gleich der zulässigen Minimaldauer (bzw. allowable minimal duration oder AMD) des LPC- Modus. Die verbleibende Zeit, bevor eine Task im Aussetzzustand in den Betriebsklarzustand basierend auf obiger Bedingung (2) oder (3) geschaltet wird, ist nicht vorhersehbar. Wenn eine Task im Aussetzzustand, basierend auf der obigen Bedingung (2) oder (3), in den Betriebsklarzustand geschaltet wird, wird bei Schritt 120 bestimmt, dass es eine Tasks im Betriebsklarzustand gibt, und danach werden die Tasks bei Schritt 110 geplant.
Für die jeweiligen Tasks werden, wie oben beschrieben, Alarme vorbereitet. Jeder der Alarme ist ein Zähler, der basierend auf dem Wert des Systemtaktes rückwärts zählt. Der Systemtakt wird durch im RTOS enthaltener Software umgesetzt. Das RTOS dekrementiert den Zähler um eins, wenn immer der Systemtakt z. B. um fünf weiterzählt. Wenn der Wert des Zählers gegen null geht, d. h. der Alarm abläuft, schaltet das RTOS die Task entsprechend dem Zähler von dem Aussetzzustand in den Betriebsklarzustand.
Z. B. wird bezugnehmend auf Fig. 6 der Alarm A entsprechend der Task A auf 100 gesetzt, der Alarm B entsprechend der Task B auf 10, und der Alarm C entsprechend der Task C auf 120. Angenommen, dass der Systemtakt mit 1 ms zählt, dekrementiert das RTOS die Alarme A, B, C alle 5 ms um eins. D. h. die Einheitszeit ist in diesem Fall 5 ms. Das RTOS wählt den Alarm aus, der zuerst ablaufen soll, und vergleicht die verbleibende Zeit, bevor der ausgewählte Alarm abläuft, mit der AMD des LPC- Modus bei Schritt 130. Wenn bei Schritt 130 bestimmt wird, dass der Wert des ausgewählten Alarms größer ist als die zulässige Minimalzeit bzw. AMD des LPC-Modus, fährt der Prozess mit Schritt 140 fort, in dem die CPU 12 auf den LPC-Modus geschaltet wird. Wenn bei Schritt 130 bestimmt wird, dass der Wert des ausgewählten Alarms gleich oder kleiner als die AMD des LPC-Modus ist, kehrt der Prozess zu Schritt 110 zurück.
In dem in Fig. 6 gezeigten Beispiel wird, unter der Annahme, dass t1 den Zeitpunkt anzeigt bei dem Schritt 130 durchgeführt wird, der Alarm B ausgewählt und bei Schritt 130 verwendet. Die Zeit, die verbleibt, bevor der Alarm B abläuft, ist in diesem Fall 5 ms × 10 = 50 ms. Angenommen die AMD des LPC-Modus ist 300 ms, dann wird bei Schritt 130 bestimmt, dass die verbleibende Zeit bevor der Alarm B abläuft kleiner als die AMD des LPC- Modus ist. Daher kehrt in diesem Fall der Prozess zu dem Schritt 110 zurück, ohne die CPU 12 in den LPC-Modus zu schalten.
Angenommen t3 zeigt den Zeitpunkt an, bei dem Schritt 130, in dem in Fig. 6 gezeigten Beispiel, durchgeführt wird, dann wird der Alarm A ausgewählt und bei Schritt 130 verwendet. Die verbleibende Zeit, bevor der Alarm A abläuft, ist in diesem Fall 5 ms × 89 = 445 ms. Es wird bei Schritt 130 bestimmt, dass die verbleibende Zeit, bevor der Alarm A abläuft, größer als die AMD (300 ms) des LPC-Modus ist. Daher fährt der Prozess in diesem Fall mit Schritt 140 fort.
Die AMD des LPC-Modus wird angesichts der Art der auszuführenden Aufgaben und der Hardwareeinschränkungen auf die zulässige Dauer des LPC-Modus bestimmt. Ferner können eine Vielzahl von Muster (verschiedene Zeitdauern) für die AMD des LPC-Modus vorbereitet werden. In diesem Fall wird eins von den Mustern bei Schritt 130 als die aktuell verwendete AMD entsprechend dem gemessenen Stromverbrauch und der gemessenen Verarbeitungsleistung ausgewählt. In dem Fall, dass vier Muster (d. h. 2 ms, 8 ms, 32 ms und 256 ms) als Ruhedauern bereitgestellt werden, wie in Fig. 2 gezeigt, können diese vier Muster als die Muster für die AMD verwendet werden. D. h. ein entsprechend ausgewähltes der vier Muster kann als die AMD des LPC-Modus bei Schritt 130 verwendet werden.
Bei Schritt 140 setzt das RTOS den Weck-Timer auf eine Zeit kürzer als die verbleibende Zeit, bevor der Alarm zuerst abläuft, und schaltet dann die CPU 12 in den LPC- Modus (d. h. Ruhemodus) durch Ausführen einer Ruheanweisung. In obigem Beispiel setzt, unter der Annahme, dass der Weck-Timer auf eines der vier Muster (d. h. 2 ms, 8 ms, 32 ms, 256 ms), wie in Fig. 2 gezeigt, gesetzt werden kann, das RTOS den Weck-Timer auf 256 ms, da die verbleibende Zeit, bevor der Alarm A abläuft, 445 ms ist. Aber wenn der Weck-Timer auf eine beliebige Zeitdauer gesetzt werden kann, kann das RTOS den Weck-Timer z. B. auf 440 ms setzen.
Im LPC-Modus wird das Takten der CPU 12 abgestellt, und der Weck-Timer zählt die Ruhedauer bei Schritt 150 rückwärts. Um den Stromverbrauch weiter zu reduzieren, kann das Takten der Peripherie abgestellt werden. Das Abstellen des Taktens der CPU 12 beinhaltet zeitweises Aussetzen des Systemuhr. Wenn der Weck-Timer abläuft, oder ein Interrupt auftritt, wird das Takten der CPU 12 wieder aufgenommen, und die CPU 12 wird in den normalen Modus geschaltet. Dann wird bei Schritt 160 bestimmt, ob die CPU 12 im Ansprechen auf den Ablauf des Weck-Timers oder im Ansprechen auf das Auftreten eines Interrupts in den normalen Modus geschaltet wird.
Wenn bei Schritt 160 bestimmt wird, dass die CPU 12 im Ansprechen auf das Auftreten eines Interrupts in den normalen Modus geschaltet wird, fährt der Prozess mit Schritt 180 fort, in dem der Wert gleich der Hälfte der Ruhedauer dem Wert der Systemuhr zugefügt wird. Dann kehrt der Prozess zu Schritt 110 zurück. Wenn andererseits bei Schritt 160 bestimmt wird, dass die CPU 12 im Ansprechen auf den Ablauf des Weck-Timers in den normalen Modus geschaltet wird, fährt der Prozess mit Schritt 170 fort, in dem der Wert gleich der Ruhedauer dem Wert der Systemuhr zugefügt wird. Dann kehrt der Prozess zu Schritt 110 zurück. Somit kompensiert das RTOS das temporäre aussetzen der Systemuhr während des LPC-Modus. Dadurch behalten die Alarme A, B, C ebenso korrekte Werte.
Das Betriebssystem entsprechend der vorliegenden Ausführungsform kann mittels Hardware umgesetzt werden. Aber es kann auch in Form eines vom Computer ausführbaren Programmes bereitgestellt werden. Ein solches Programm kann in einem computerlesbaren Medium, wie z. B. einer Floppy Disk, einer magnetoptischen Disk, einer CD-ROM, einer Festplatte, einem ROM-Speicher oder einem RAM- Speicher gespeichert werden, und kann, wenn notwendig, geladen werden. Alternativ kann das Programm über ein Netzwerk geladen werden.
Gemäß der vorliegenden Erfindung werden folgende Vorteile erzielt. Das RTOS schaltet die CPU 12 in den LPC- Modus, nur wenn es keine Task im Betriebszustand oder Betriebsklarzustand gibt. Daher wird das RTOS niemals die CPU 12 in den LPC-Modus schalten, wenn die Task ausgeführt wird. Ferner wird die Ausführung der Tasks im Betriebsklarzustands nicht verzögert werden, da das RTOS die CPU 12 nicht in den LPC-Modus schaltet, wenn es eine Task im Betriebsklarzustand gibt.
Die Tasks im Aussetzzustand werden nicht am Schalten in den Betriebsklarzustand gehindert werden, da das RTOS die Dauer des LPC-Modus bestimmt, so dass sie kürzer ist, als die verbleibende Zeit bevor der Alarm zum Wecken einer Task von dem Aussetzzustand abläuft. Ferner schaltet das RTOS die CPU 12 von dem LPC-Modus in den normalen Modus, wenn ein Interrupt auftritt. Daher wird die Task im Aussetzzustand im Ansprechen auf das Auftreten eines unvorhersehbaren Interrupts nicht vom Schalten in den Betriebsklarzustand gehindert.
Somit wird der Stromverbrauch in der Karosserie-ECU 10 verringert, ohne die Ausführung der Task im Betriebszustand, der Tasks im Betriebsklarzustand und der durch die Alarme zu weckenden Tasks zu unterbrechen. Ferner müssen Entwickler die Betriebsart der CPU 12 nicht in Betracht ziehen, wenn sie ein Anwendungsprogramm entwickeln, das aus Tasks besteht. Daher können sie das Anwendungsprogramm einfach entwickeln.
Zusammenfassend läßt sich die vorliegende Erfindung wie folgt darstellen. Ein Echtzeitbetriebssystem (RTOS) für eine elektronische Steuereinheit (ECU) (10) im Fahrzeug schaltet (120-140) die CPU (12) der Fahrzeug-ECU in einen Modus mit niedrigem Stromverbrauch (LPC-Modus), wenn es keine Task in einem Betriebszustand und in einem Betriebsklarzustand gibt, und ferner die verbleibende Zeit, bevor eine Task in einem Aussetzzustand in den Betriebsklarzustand geschaltet wird, länger als eine vorbestimmte zulässige Minimaldauer des LPC-Modus ist. Die Dauer des LPC-Modus wird auf eine Länge eingestellt, die kürzer als die verbleibende Zeit ist, bevor eine Task in dem Aussetzzustand in den Betriebsklarzustand geschaltet wird. Wenn ein Interrupt auftritt, oder die Dauer des LPC-Modus abläuft, wird die CPU in einen normalen Modus geschaltet, und das temporäre Aussetzen der Systemuhr während des LPC-Modus wird unter Verwendung der Dauer des LPC-Modus kompensiert (170, 180).
In obiger Ausführungsform kann das RTOS den Alarm so einstellen, dass der Alarm abläuft, wenn die Systemuhr die vorbestimmte absolute Zeit anzeigt. Z. B. ist der Alarm so eingestellt, dass er bei 10300 absoluter Zeit abläuft, wie in der obersten Zeile von Fig. 7 gezeigt. In diesem Fall wird, wenn Schritt 170 oder 180 weggelassen wird, nachdem der vorherige LPC-Modus einer Dauer von 130 ms beendet ist, der Ablauf des Alarms bei 10300 absoluter Zeit verzögert, wie in der mittleren Zeile von Figur. 7 gezeigt. Wenn Schritt 170 oder 180 nach dem vorherigen LPC-Modus ausgeführt wird, wird der Ablauf des Alarms bei 10300 absoluter Zeit nicht verzögert, wie in der unteren Zeile von Fig. 7 gezeigt, da die Ausfallzeit von 130 ms bei Schritt 170 oder 180 kompensiert wird. Dementsprechend sollte Schritt 170 oder 180 ausgeführt werden, nachdem der LPC-Modus beendet ist, damit der Alarm zu der genauen Zeit abläuft. Ferner kann das RTOS den Alarm zunächst auf 0 setzen und danach den Alarm entsprechend der Systemuhr inkrementieren. In diesem Fall läuft der Alarm ab, wenn der Wert des Alarms einen vorbestimmten Wert erreicht.
In obiger Ausführungsform kann das RTOS die Tasks zwischen drei Zuständen schalten, oder zwischen mehr als vier Zuständen. Z. B. kann das RTOS die Tasks zwischen Zuständen schalten, die einen Taskerzeugungszustand oder einen Anomaliestopzustand enthalten, oder zwischen dem Betriebszustand, Betriebsklarzustand und Aussetzzustand. Ferner kann das RTOS ein nicht preemptives Multitaskingbetriebssystem sein anstatt eines preemptiven Multitaskingbetriebssystems.
Das Betriebssystem der vorliegenden Erfindung kann für verschiedene Vorrichtungen außer der Karosserie-ECU 10 des Karosseriesystems 100 verwendet werden. Z. B. kann das Betriebssystem der vorliegenden Erfindung für eine batteriebetriebene Vorrichtung oder die ECUs 20 verwendet werden, die an die Karosserie-ECU 10 in Fig. 1 angeschlossen sind. Das Betriebssystem der vorliegenden Erfindung kann die Betriebsart so steuern, dass der Stromverbrauch verringert wird, ohne die Ausführung von Programmen zu unterbrechen. Daher ist es in einer Vorrichtung nutzbar, in der Verringerung des Stromverbrauchs in höchstem Maße gefordert ist.
Die vorliegende Erfindung ist nicht auf obige Ausführungsform und Modifikationen begrenzt, sondern kann innerhalb des Bereiches der Erfindung verschieden ausgeführt werden.

Claims

1. Ein Betriebssystem mit einer ersten Einrichtung zum Verwalten mehrerer Tasks zum Steuern des Betriebs einer Zentraleinheit (CPU) (12) eines Mikrocomputers (10), dadurch gekennzeichnet, dass
die Vielzahl von Tasks zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand geschaltet werden (110),
das Betriebssystem eine zweite Einrichtung (120, 140) zum Schalten der CPU (12) in einen Modus mit niedrigem Stromverbrauch (LPC-Modus), wenn es keine Task in dem Betriebszustand und in dem Betriebsklarzustand gibt, aufweist.

2. Ein Betriebssystem mit einer ersten Einrichtung zum Verwalten mehrerer Tasks zum Steuern des Betriebes einer Zentraleinheit (CPU) (12) eines Mikrocomputers (10), dadurch gekennzeichnet, dass
die Vielzahl von Tasks zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand geschaltet werden (110),
das Betriebssystem eine zweite Einrichtung (120-140) zum Schalten der CPU (12) in einen LPC-Modus, wenn es keine Task in dem Betriebszustand und in dem Betriebsklarzustand gibt, aufweist;
die Dauer des LPC-Modus auf der Grundlage einer verbleibenden Mindestzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, bestimmt wird, wenn es eine Task in dem dritten Zustand gibt, und die verbleibende Zeit bevor die Task in den Betriebsklarzustand geschaltet wird bekannt ist.

3. Ein Betriebssystem nach Anspruch 2, dadurch gekennzeichnet, dass die Dauer des LPC-Modus so bestimmt ist, dass sie kürzer als die verbleibende Minimalzeit ist, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird.

4. Ein Betriebssystem nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die CPU (12) nur in den LPC-Modus geschaltet wird (130, 140), wenn die verbleibende Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, länger ist als eine vorbestimmte erlaubte Minimaldauer des LPC-Modus.

5. Ein Betriebssystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass eine Task in dem dritten Zustand in einen der anderen Zustände geschaltet wird, wenn eine vorbestimmte Bedingung erfüllt ist.

6. Ein Betriebssystem nach Anspruch 5, dadurch gekennzeichnet, dass
auf Grundlage eines Wertes eines Alarms, der zum Wecken der Task von dem dritten Zustand bereitgestellt ist, bestimmt wird, ob die vorbestimmte Bedingung erfüllt ist; und
der Wert des Alarms als die verbleibende Zeit verwendet wird, bevor die Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird (130).

7. Ein Betriebssystem nach einem der Ansprüche 2 bis 6, dadurch gekennzeichnet, dass das temporäre Aussetzen eines während des LPC-Modus temporär ausgesetzten Timers auf der Grundlage der Dauer des LPC-Modus kompensiert wird (170, 180).

8. Ein Computerprogramm zum Umsetzen eines Betriebssystems auf einem Mikrocomputer (10), dadurch gekennzeichnet, dass
das Computerprogramm eine CPU (12) des Mikrocomputers (10) veranlasst folgendes Verfahren durchzuführen:
Verwalten einer Vielzahl von Tasks durch schalten (110) der Vielzahl von Tasks zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand; und
Schalten (120, 140) der CPU (12) in einen LPC-Modus, wenn es keine Task in dem Betriebszustand und in dem Betriebsklarzustand gibt.

9. Ein Computerprogramm nach Anspruch 8, dadurch gekennzeichnet, dass die Dauer des LPC-Modus basierend auf einer verbleibenden Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, bestimmt wird, wenn es eine Task in dem dritten Zustand gibt, und die verbleibende Zeit, bevor die Task in den Betriebsklarzustand geschaltet wird, bekannt ist.

10. Eine elektronische Steuerung (10) für ein Fahrzeug, mit:
einer Zentraleinheit (CPU) (12); und
einem Betriebssystem, mit einer ersten Einrichtung zum Verwalten einer Vielzahl von Tasks, zum Steuern des Betriebs einer CPU (12), dadurch gekennzeichnet, dass
die Vielzahl von Tasks zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand geschaltet werden (110); und
das Betriebssystem eine zweite Einrichtung (120, 140) zum Schalten der CPU (12) in einen LPC-Modus, wenn es keine Task in dem Betriebszustand und in dem Betriebsklarzustand gibt, enthält.

11. Eine elektronische Steuereinheit (10) nach Anspruch 10, dadurch gekennzeichnet, dass die Dauer des LPC-Modus auf der Grundlage einer verbleibenden Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, bestimmt wird, wenn es eine Task in dem dritten Zustand gibt, und die verbleibende Zeit, bevor die Task in den Betriebsklarzustand geschaltet wird, bekannt ist.

12. Ein Verfahren zum Schalten einer CPU (12) eines Mikrocomputers (10), in dem die CPU (12) ein Programm ausführt, das eine Vielzahl von Tasks enthält, in einen LPC-Modus, gekennzeichnet ist durch die Schritte:
Planen (110) der Vielzahl von Tasks durch schalten der Vielzahl von Tasks zwischen einem Betriebszustand, einem Betriebsklarzustand und einem dritten Zustand; und
Schalten (120, 140) der CPU (12) in den LPC-Modus, wenn es keine Task in dem Betriebszustand und dem Betriebsklarzustand gibt.

13. Ein Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Schaltschritt (120, 140) den Schritt des bestimmens der Dauer des LPC-Modus auf der Grundlage einer verbliebenen Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, enthält, wenn es in dem dritten Zustand eine Task gibt, und die verbleibende Zeit, bevor die Task in den Betriebsklarzustand geschaltet wird, bekannt ist.

14. Ein Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Dauer des LPC-Modus bei dem Bestimmungsschritt so bestimmt wird, dass sie kürzer ist als die verbleibende Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird.

15. Ein Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass der Schaltschritt (130, 140) nur durchgeführt wird, wenn die verbleibende Minimalzeit, bevor eine Task in dem dritten Zustand in den Betriebsklarzustand geschaltet wird, länger als eine vorbestimmte zulässige Minimaldauer des LPC-Modus ist.