DE4410775A1 - Steuergerät und Betriebssystem für dieses Steuergerät - Google Patents

Description

Die Erfindung betrifft ein Steuergerät nach dem Oberbegriff von Patentanspruch 1 und ein Betriebssystem nach dem Oberbe­ griff von Anspruch 2.

Bei einer bekannten Motorsteuerung (DE 38 26 526 A1) laufen Programme unterschiedlicher zeitlicher Priorität ab. Dabei sind Programme prioritätshoch, mit denen bei einem vorgegebe­ nen Kurbelwinkel ein Motorsteuervorgang ausgelöst wird, z. B. Kraftstoff eingespritzt oder das Kraftstoff-Luft-Gemisch ge­ zündet wird. Mit niedriger Priorität laufen sogenannte Hin­ tergrundprogramme ab.

Bei dem Entwurf von Steuerungen wird die von dem Steuergerät zu erledigende Steuerungsaufgabe üblicherweise in Teilaufga­ ben gegliedert und jede Teilaufgabe als ein in sich abge­ schlossenes Programm realisiert. Ein solches Programm wird als Task - oder auch als Prozeß oder Teilaufgabe - bezeich­ net. Betriebssysteme die mehrere Tasks verwalten können, wer­ den als Multitasking-Betriebssysteme bezeichnet.

Bei der Durchführung der Steuerungsaufgaben tritt häufig eine Situation auf, bei der sich mehrere Tasks um die Benutzung der zentralen Rechnereinheit, der CPU, bemühen. Die Aufgabe des Multitasking-Betriebssystems besteht darin, der CPU im­ mer nur eine von mehreren Tasks zuzuteilen. Der Teil des Be­ triebssystems, der die Taskwechsel vollzieht, wird als Dispatcher bezeichnet. Derjenige Teil des Betriebssystems, der entscheidet, welcher Task die CPU zugeteilt wird, wird als Scheduler bezeichnet.

Ein Taskwechsel kann von dem Betriebssystem grundsätzlich auf zwei verschiedene Arten durchgeführt werden:

• - nach einer Verdrängungsmethode - im folgenden als "preemptive scheduling" bezeichnet -, bei der die Abarbei­ tung einer Task von dem Betriebssystem unterbrochen und die CPU einer anderen wartenden Task zugeteilt werden kann, und
• - nach einer Stapelverarbeitungsmethode - im folgenden: "non-preemp­ tive scheduling" -, bei der eine laufende, d. h. der­ zeitig abgearbeitete Task nicht durch eine andere Task ver­ drängt werden kann.

Bei dem preemptive scheduling benötigt das Betriebssystem zu­ sätzliche Rechnerzeit und Arbeitsspeicherkapazität, um die Daten der Task zu sichern, die unterbrochen wird und später weiter bearbeitet werden muß. Bei dem non-preemptive schedu­ ling muß beim Entwickeln der Programme für das Steuergerät darauf geachtet werden, daß die Laufzeiten der einzelnen Tasks nicht die Echtzeitbedingungen des Systems verletzen. Es kann deshalb erforderlich sein, daß eine zusammenhängende Teilaufgabe in mehrere Tasks aufgeteilt werden muß.

Beim Entwickeln und Programmieren von Steuergeräten muß man sich bislang für eine der Betriebssystemarten entscheiden. Entweder entscheidet sich der Entwickler für ein non-preemp­ tive Betriebssystem, für das kein zusätzlicher Arbeitsspei­ cherplatz erforderlich ist, der Aufwand für die Programmer­ stellung aber höher ist, oder er entscheidet sich für ein preemptive Betriebssystem, das zwar zusätzlichen Speicher be­ nötigt, die Programmerstellung aber vereinfacht.

Der Erfindung liegt die Aufgabe zugrunde, ein Steuergerät und ein Betriebssystem für ein solches Steuergerät zu schaffen, das den Aufwand für Hardware und Software verringert und die Verarbeitungskapazität des Steuergeräts möglichst gut aus­ nutzt.

Diese Aufgabe wird erfindungsgemäß durch das Steuergerät nach Anspruch 1 und das Betriebssystem nach Anspruch 2 gelöst.

Ein Ausführungsbeispiel der Erfindung wird im folgenden an­ hand der Zeichnung erläutert. Es zeigen:

Fig. 1 ein Steuergerät gemäß der Erfindung in Blockdiagramm­ darstellung,

Fig. 2 die verschiedenen Zustände, die eine in dem Steuerge­ rät nach Fig. 1 abzuarbeitende Task einnehmen kann,

Fig. 3 eine Taskfolge bei einem Betriebssystem mit preemp­ tive scheduling,

Fig. 4 eine Taskfolge bei einem Betriebssystem mit non-preemp­ tive scheduling, und

Fig. 5 eine Taskfolge bei einem erfindungsgemäßen Betriebs­ system mit mixed-preemptive scheduling.

Ein Steuergerät 1 (Fig. 1) weist einen Zentralprozessor oder CPU 2, einen Arbeitsspeicher oder RAM 3, einen Festwertspei­ cher oder EPROM 4 sowie Ein- und Ausgabeschaltungen oder I/O- Ports 6 auf. Diese Schaltungsbestandteile sind durch Daten- und Signalleitungen 7 bis 10 und ein Bussystem 11 untereinan­ der verbunden. An den I/O-Port 6 sind eine Eingangsleitung 12 und Ausgangsleitung 13 angeschlossen, über die das Steuer­ gerät 1 mit dem zu steuernden System, z. B. mit der Einspritz­ anlage, der Zündsteuerung, der Getriebesteuerung usw. des Kraftfahrzeugs verbunden ist. Über die Eingangsleitung 12 gelangen die von hier nicht dargestellten Sensoren geliefer­ ten Meßwerte zu dem Steuergerät, über die Leitung 13 werden von diesem Steuersignale an eine ebenfalls nicht dargestellte Einrichtung, z. B. eine Motorsteuerung, ausgegeben.

Eine in dem Steuergerät 1 abzuarbeitende Task kann vier ver­ schiedene Zustände (Taskzustände) einnehmen, die aus Fig. 2 ersichtlich sind:

• - Ruhend: Die Task belegt keine Betriebsmittel; sie bleibt in diesem Zustand, bis sie von einer anderen Task oder dem Be­ triebssystem gestartet wird.
• - Bereit: Die Task bewirbt sich um die Zuteilung der CPU 2.
• - Laufend (oder Aktiv): Die Task hat die CPU 2 zugeteilt be­ kommen und wird von dieser abgearbeitet.
• - Wartend: Die Task wartet auf ein Ereignis, z. B. auf das Er­ gebnis einer anderen Task. Tritt dieses Ereignis ein, so wird die Task freigegeben und gelangt in den Zustand Be­ reit.

Der Taskwechselmechanismus kann nach einer der eingangs ange­ gebenen Methoden, der Stapelverarbeitung oder der Verdrän­ gungsmethode, erfolgen.

Bei der Verdrängungsmethode oder preemptive scheduling kann eine laufende Task (z. B. durch einen Interrupt) von dem Be­ triebssystem unterbrochen und die CPU 2 einer anderen warten­ den Task zugeteilt werden, wie nun anhand von Fig. 3 erläu­ tert wird.

In dem dargestellten Beispiel werden drei Tasks a, b und c betrachtet, wobei die Task a eine höhere Priorität als die Tasks b und c und die Task b eine höhere Priorität als die Task c hat. Zu einem Zeitpunkt t₀ warten die höherprioren Task a und b auf ein Ereignis, während die Task c läuft, d. h. abgearbeitet wird.

Zu einem Zeitpunkt t₁ tritt ein Ereignis - ein Interrupt - für die Task b ein. Der Dispatcher und der Scheduler werden gestartet. Da außer der Task c eine höherpriore Task bereit ist, wird die Task c unterbrochen und ihr Taskkontext geret­ tet.

Unter dem Taskkontext wird hier die Datengesamtheit ver­ standen, die erforderlich ist, um die unterbrochene Task später fortzusetzen. Im wesentlichen besteht der Taskkon­ text aus dem Inhalt der - hier nicht dargestellten, da all­ gemein bekannt - Register der CPU 2.

Die Task b wird gestartet.

Zu einem Zeitpunkt t₂ tritt ein Ereignis (Interrupt) für die Task a ein. Der Dispatcher und der Scheduler werden gestar­ tet. Da neben der Tasks b und c die höherpriore Task a bereit ist, wird die Task b unterbrochen und ihr Taskkontext geret­ tet. Die Task a wird gestartet.

Zu einem Zeitpunkt t₃ ist die Task a beendet. Der Dispatcher und der Scheduler werden gestartet. Von den dann bereiten Tasks hat die Task b die höchste Priorität. Da diese unter­ brochen worden ist, restauriert der Dispatcher ihren Kontext. Anschließend kann die Task fortgesetzt werden, d. h. ihre noch nicht abgearbeiteten Befehle werden nun abgearbeitet.

Zu einem Zeitpunkt t₄ ist die Task b beendet. Der Dispatcher und der Scheduler werden gestartet. Zu diesem Zeitpunkt ist nur noch die Task c bereit. Da diese unterbrochen worden war, restauriert der Dispatcher ihren Kontext. Anschließend kann die Task b mit ihrer Befehlsfolge weiter durchgeführt werden.

Da die Tasks mitten in ihrer Befehlsfolge von höherprioren Tasks unterbrochen werden können, muß im Falle einer Unter­ brechung der Dispatcher den Taskkontext retten. Dazu wird der Taskkontext temporär in einem Bereich des RAM-Speichers 3 zwischengespeichert. Wenn nach einem Taskwechsel die unter­ brochene Task die CPU wieder zugeteilt bekommt, wie z. B. die Task b zu dem Zeitpunkt t₃, muß der Dispatcher zuerst den Taskkontext wieder restaurieren.

Da die Tasks hier von "wichtigeren" Tasks verdrängt werden können, braucht bei der Entwicklung des Programms die Länge einer Task nicht berücksichtigt zu werden. Da in dem Beispiel die Task c von höherprioren Task unterbrochen werden kann, kann diese Task beliebig lang sein, ohne daß Echtzeitverhal­ ten für höherpriorer Tasks und damit das Echtzeitverhalten des Steuergeräts zu gefährden. Allerdings benötigt das Steuergerät für die Rettung des Taskkontextes wie erwähnt zusätzliche Rechenzeit und RAM-Speicherplatz, und zwar in Abhängigkeit von dem Umfang des Kontextes und der Gesamtzahl der Tasks.

Bei der non-preemptive scheduling oder Stapelverarbeitungsme­ thode kann eine laufende Task nicht durch eine andere Task verdrängt, d. h. unterbrochen werden. Dies ist in Fig. 4 dar­ gestellt.

Auch in diesem Beispiel stehen drei Tasks a, b und c an, von denen die Task a eine höhere Priorität als die Tasks b und c und die Task b eine höhere Priorität als die Task c hat. Zu einem Zeitpunkt t₀ warten die höherprioren Tasks a und b auf ein Ereignis, während die Task c läuft, d. h. abgearbeitet wird.

Zu einem Zeitpunkt t₁ tritt ein Ereignis (Interrupt) für die Task b ein. Die Task b gelangt deshalb in den Zustand Bereit. Da laufende Tasks nicht unterbrochen werden können, muß die Task b bis zu einem Zeitpunkt t₂ warten, zu dem die Task c beendet worden ist und die Task b gestartet werden kann.

Zu einem Zeitpunkt t₃ tritt ein Ereignis (Interrupt) für die Task a ein. Die Task gelangt deshalb in den Zustand Bereit. Da laufende Tasks nicht unterbrochen werden können, muß die Task a bis zu einem Zeitpunkt t₄ warten. Zu diesem Zeitpunkt ist die Task b beendet und die Task a kann gestartet werden.

Da die Tasks hier nicht von höherprioren Tasks unterbrochen werden können, muß der Dispatcher den Taskkontext weder ret­ ten noch restaurieren. Es wird kein Speicherplatz in dem RAM- Speicher 3 belegt. Da die Tasks nicht unterbrochen werden können, muß andererseits der Entwickler des Programms darauf achten, daß die Laufzeit einer Task nicht die Echtzeitbedin­ gungen verletzt. Dabei kann zusätzlicher Programmieraufwand erforderlich werden.

Die Art des Taskwechselmechanismus wird deshalb hier einer Task als Attribut "preemptive scheduling" oder "non-preemp­ tive scheduling" zugeordnet. Damit ergibt sich eine Abarbei­ tung der Taskfolge nach einem "mixed-preemptive scheduling", das aus Fig. 5 ersichtlich ist. Auch hier liegen drei Tasks a, b und c vor, wobei die Task a eine höhere Priorität als die Tasks b und c und die Task b eine höhere Priorität als die Task c haben. Die Task c ist als eine preemptive Task und die Tasks a und b als eine non-preemptive Tasks deklariert.

Zu einem Zeitpunkt t₀ warten die höherprioren Tasks a und b auf ein Ereignis; die Task c läuft.

Zu einem Zeitpunkt t₁ tritt ein Ereignis (Interrupt) für die Task b ein. Der Dispatcher und der Scheduler des Betriebssy­ stems werden gestartet. Da neben der Task c eine höherpriore Task bereit ist und außerdem die Task c als eine preemptive Task deklariert ist, wird die Task c unterbrochen und ihr Taskkontext gerettet. Die Task b wird gestartet.

Zu einem Zeitpunkt t₂ tritt ein Ereignis (Interrupt) für die Task a ein. Die Task gelangt deshalb in den Zustand bereit. Da die laufende Task b als non-preemptive deklariert ist, kann sie nicht unterbrochen werden: Die Task a muß bis zu ei­ nem Zeitpunkt t3 warten, zu dem die Task b beendet worden ist und die Task a gestartet werden kann.

Zu einem Zeitpunkt t₄ ist die Task a beendet. Der Dispatcher und der Scheduler des Betriebssystems werden gestartet. Zu diesem Zeitpunkt ist nur noch die Task c bereit. Da diese un­ terbrochen wurde, restauriert der Dispatcher ihren Kontext. Anschließend kann die Task mit ihrer Befehlsfolge weiter ver­ arbeitet werden. Da als "preemptive" deklarierte Tasks mitten in der Befehlsfolge von höherprioren Tasks unterbrochen wer­ den können, muß der Dispatcher nur für diese Tasks den Task­ kontext, d. h. z. B. den Inhalt der CPU-Register retten.

Das hier beschriebene mixed-preemptive scheduling oder kombi­ nierte Multitasking-Betriebssystem ermöglicht es, bei der Entwicklung eines Steuerungssystems Tasks entweder als preemptive oder non-preemptive zu deklarieren: Nur für die als preemptive deklarierten Tasks muß Rechenzeit und RAM- Speicherbereich bereitgestellt werden, und nur bei den als non-preemptive deklarierten Tasks muß der Entwickler darauf achten, daß die Länge der Tasks nicht die Echtzeitbedingungen für das Steuerungssystem verletzt. Unter Inkaufnahme eines geringen Zusatzaufwands werden die Vorteile der beiden be­ kannten Betriebssysteme genutzt.

Claims (2)

1. Steuergerät (1), insbesondere zum Steuern von Funktionen in Kraftfahrzeugen, das mit einem Prozessor (2), mit Daten­ speichern (3, 4), mit Ein- und Ausgabeschaltungen (6) sowie mit einem Betriebssystem versehen ist, durch das die Abar­ beitung von Tasks zeitlich koordiniert und gesteuert wird, dadurch gekennzeichnet,

• - daß das Betriebssystem eingerichtet ist sowohl für die Be­ arbeitung von Tasks nach einer Stapelverarbeitungsmethode (non-preemptive scheduling), bei der die Abarbeitung einer Task nicht unterbrochen werden kann, als auch für die Bear­ beitung von Tasks nach einer Verdrängungsmethode (preempti­ ve scheduling), bei der die Abarbeitung einer Task zum Ab­ arbeiten einer anderen Task unterbrochen werden kann, und
• - daß die Art der Abarbeitung jeder Task als Attribut zuge­ ordnet ist, durch das die jeweilige Bearbeitungsmethode festgelegt wird.

2. Betriebssystem für ein Steuergerät (1), insbesondere zum Steuern von Funktionen in Kraftfahrzeugen, durch das die Ab­ arbeitung von Tasks durch das Steuergerät zeitlich koordi­ niert und gesteuert wird, dadurch gekennzeichnet,

• - daß Tasks bearbeitet werden sowohl nach einer Stapelverar­ beitungsmethode (non-preemptive scheduling), bei der das Abarbeiten einer Task nicht unterbrochen werden kann, als auch nach einer Verdrängungsmethode, bei der das Abarbeiten einer Task zum Abarbeiten einer anderen Task unterbrochen werden kann (preemptive scheduling), und
• - daß die Art der Verarbeitung jeder Task als Attribut zuge­ ordnet wird, durch das die jeweilige Abarbeitungsmethode festgelegt wird.