DE4410775C2 - Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät - Google Patents

Description

Die Erfindung betrifft ein Steuergerät nach dem Oberbegriff von Patentanspruch 1 und ein Arbeitsverfahren 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 Recheneinheit, der CPU, bemühen. Die Aufgabe des Multitasking-Betriebssystems besteht darin, der CPU immer 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 "preemp­ tive scheduling" bezeichnet -, bei der die Abarbeitung ei­ ner Task von dem Betriebssystem unterbrochen und die CPU einer anderen wartenden Task zugeteilt werden kann, und
• - nach einer Stapelverarbeitungsmethode - im folgenden: "non- preemptive 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ß.

Bekannt sind auch ein gattungsgemäßes Steuergerät und ein Ar­ beitsverfahren eines Betriebssystems für ein solches Steuer­ gerät (DE 30 33 526 C2), bei dem die Betriebsparameter des Motors erfaßt, Steuergrößen unter Aufgliederung in einzelne Verarbeitungen berechnet, die Verarbeitungen in Prioritäts­ grade je nach der Dringlichkeit der Steuergröße klassifiziert und motordrehzahlunabhängige Unterbrechungssignalfolgen er­ zeugt werden, die je einem Piroritätsgrad zugeordnet sind. Durch diese Signalfolgen wird eine Verarbeitung niedriger Priorität beim Starten einer anderen Verarbeitung nur dann unterbrochen, wenn diese eine höhere Priorität aufweist. In­ nerhalb eines Prioritätsgrades ist die Reihenfolge der Verar­ beitungen durch die Perioden der jeweiligen Unterbrechungs­ signalfolgen in ganz genau angegebener Weise festgelegt, und zwar in Abhängigkeit von den zu steuernden Vorgängen.

Hierzu ist jeder Task ein Attribut zugeordnet, welches an­ gibt, welcher Prioritätsebene und welcher Priorität die Task innerhalb der Prioritätsebene angehört. Zur zeitlichen Koor­ dinierung der Tasks ist das Betriebssystem so eingerichtet, daß sich innerhalb einer Prioritätsebene die jeweiligen Tasks nicht unterbrechen können (Stapelbetrieb), daß aber eine Task einer höheren Prioritätsebene Tasks einer niedrigeren Priori­ tätsebene unterbrechen kann (Verdrängungsmethode). Damit ist zwar ein mixed-preemptive-scheduling möglich, aber die Unter­ brechbarkeit einer Task hängt von ihrer Prioritätszuteilung ab. Von keiner anderen Task unterbrechbar sind nur Tasks der höchsten Prioritätsebene.

Aus dem Fachbuch "Datenverarbeitung im Realzeitbetrieb" von M. Graef, R. Greiller und G. Hecht, erschienen im Oldenbourg Verlag München-Wien 1970, Seiten 86, 87 und 130 ist bekannt, daß eine reibungslose Zusammenarbeit von Realzeit- und Sta­ pel-Anwenderprogrammen erforderlich ist, um den Speicherplatz und die Rechenzeit eines Computers möglichst gut auszunutzen. Eine ebenfalls bekannte Steuervorrichtung für Funktionen im Kraftfahrzeug weist einen Rechner, einen Festwertspeicher, einen variablen Speicher und einen zusteckbaren zusätzlichen Festwertspeicher zum Ändern von Daten und Programmen auf. Dieser zusätzliche Festwertspeicher wird dabei vom Rechner erkannt. Die Funktionsabläufe sind modular im Festwertspei­ cher abgelegt, werden nach Organisationsprogrammen abgearbei­ tet und bei zugestecktem Festwertspeicher nach dessen Organi­ sationsprogramm (DE 34 19 559 A1).

Der Erfindung liegt die Aufgabe zugrunde, ein Steuergerät und ein Arbeitsverfahren eines Betriebssystems 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 Arbeitsverfahren eines Betriebssystems 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- preemptive 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 Abarbei­ tung von Tasks zeitlich koordiniert und gesteuert wird und das eingerichtet ist sowohl für die Bearbeitung von Tasks nach einer Stapelverarbeitungsmethode, bei der die Abarbei­ tung einer Task nicht unterbrochen werden kann, als auch für die Bearbeitung von Tasks nach einer Verdrängungsmethode, bei der die Abarbeitung einer Task zum Abarbeiten einer anderen Task mit höherer Priorität unterbrochen werden kann, dadurch gekennzeichnet, daß jeder Task ein Attribut zugeordnet ist, durch das festgelegt ist, ob die Task nach der Verdrängungs­ methode bearbeitet wird.

2. Arbeitsverfahren eines Betriebssystems für ein Steuergerät (1), insbesondere zum Steuern von Funktionen in Kraftfahrzeu­ gen, durch das die Abarbeitung von Tasks durch das Steuerge­ rät zeitlich koordiniert und gesteuert wird, und durch das Tasks bearbeitet werden sowohl nach einer Stapelverarbei­ tungsmethode (non-preemptive scheduling), bei der das Abar­ beiten einer Task nicht unterbrochen werden kann, als auch nach einer Verdrängungsmethode, bei der das Abarbeiten einer Task zum Abarbeiten einer anderen Task mit höherer Priorität unterbrochen werden kann (preemptive scheduling), dadurch ge­ kennzeichnet, daß jeder Task ein Attribut zugeordnet ist, durch das festgelegt ist, ob die Task nach der Verdrängungs­ methode bearbeitet wird.