DE10206865C1 - Reaktionszeit-Beschränkung eines Software-Prozesses - Google Patents
Reaktionszeit-Beschränkung eines Software-ProzessesInfo
- Publication number
- DE10206865C1 DE10206865C1 DE10206865A DE10206865A DE10206865C1 DE 10206865 C1 DE10206865 C1 DE 10206865C1 DE 10206865 A DE10206865 A DE 10206865A DE 10206865 A DE10206865 A DE 10206865A DE 10206865 C1 DE10206865 C1 DE 10206865C1
- Authority
- DE
- Germany
- Prior art keywords
- software process
- result
- execution
- sub
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/348—Circuit details, i.e. tracer hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
Die Erfindung betrifft ein Verfahren und eine Vorrichtung, durch welche die Reaktionszeit eines Software-Prozesses auf eine vorgegebene maximale Reaktionszeit beschränkt wird. Unter Reaktionszeit wird die Summe aus Latenzzeit (Zeitspanne zwischen auslösendem Ereignis und Start des Prozesses) und Ausführungszeit verstanden. Der Software-Prozeß ist beispielsweise ein Unterbrechungsbehandlungs-Programm, das durch ein Unterbrechungssignal (Interrupt) ausgelöst wird. Erfindungsgemäß ist der Software-Prozeß in mehrere Teilprozesse unterteilt, die jeweils ein Ergebnis liefern. Wird der Software-Prozeß abgebrochen, weil die maximale Reaktionszeit erreicht ist, so wird als Endergebnis des Prozesses das Ergebnis eines zuvor ausgewählten Teilprozesses verwendet. Dieser Teilprozeß ist beispielsweise der als letzter vollständig ausgeführte.
Description
Die Erfindung betrifft ein Verfahren und eine Vorrichtung,
durch welche die Reaktionszeit eines Software-Prozesses auf
eine vorgegebene maximale Reaktionszeit beschränkt wird.
Unter einem Software-Prozeß wird ein Vorgang verstanden, der
von einer datenverarbeitenden Vorrichtung ausgeführt wird und
ein Endergebnis erbringt. Die datenverarbeitende Vorrichtung
ist beispielsweise ein Arbeitsplatzrechner, ein Regler oder ein
Steuergerät in einem Kraftfahrzeug, sie umfaßt mindestens einen
Prozessor zur Ausführung von Programmbefehlen. Ein solcher
Software-Prozeß berechnet beispielsweise Ausgangssignale in
Abhängigkeit von Eingangssignalen, aktiviert oder deaktiviert
Geräte, erzeugt eine Ausgabe auf einem Peripheriegerät, z. B.
einem Drucker oder einen Bildschirm, oder liest Daten aus einer
Datei oder von einem Datenbus in einen temporären Speicher des
Prozesses ein. Beim Ablauf eines Software-Programms werden oft
mehrere Software-Prozesse gestartet. Der Software-Prozeß kann
gemeinsam mit anderen Software-Prozessen in einem
mehrprozeßfähigen Betriebssystem, z. B. UNIX, und/oder einer
mehrprozeßfähigen Ablaufumgebung, z. B. Java, ausgeführt
werden. Eine solche Abarbeitung mehrerer Prozesse wird oft als
"preemptive multi-tasking" bezeichnet. Manche derartigen
Software-Prozesse heißen dann "processes", andere "threads".
Als Oberbegriff für "processes" und "threads" wird manchmal
"tasks" verwendet. Der Begriff "Software-Prozeß" umfaßt im
folgenden "processes", "threads" und "tasks".
Eine besondere Art von Software-Prozessen wird durch bestimmte
Unterbrechungssignale, oft "interrupt requests", IRQs oder kurz
Interrupts genannt, ausgelöst. Ein solcher Software-Prozeß
bewirkt eine vordefinierte Reaktion auf ein auslösendes
Ereignis, z. B. Auftreten eines Gerätefehlers oder eine
Anforderung zum sofortigen Abbruch aller aktuell unwichtigen
weiteren Software-Prozesse und sonstigen Abläufe auf der
datenverarbeitenden Vorrichtung. Dieses plötzliche Ereignis
wirkt meistens von außen und plötzlich auf die
datenverarbeitende Vorrichtung ein. Ein Beispiel für ein
Ereignis, das nicht von außen einwirkt, ist eine Division durch
Null - auf sie wird bevorzugt durch ein Ausnahmebehandlungs-,
aber nicht durch ein Unterbrechungsbehandlungs-Programm
reagiert. Ein durch ein Unterbrechungssignal ausgelöster
Software-Prozeß wird im folgenden als
Unterbrechungsbehandlungs-Programm (Interrupt-Programm,
"interrupt service routine", ISR) bezeichnet. Typischerweise
ist jedem der vorgesehenen Unterbrechungssignale ein
Unterbrechungsbehandlungs-Programm zugeordnet.
Unter der Latenzzeit eines Software-Prozesses wird die
Zeitspanne verstanden, die zwischen dem Ereignis, das den
Software-Prozeß auslöst, und dem Beginn der Ausführung des
Software-Prozesses verstanden. Im Falle eines
Unterbrechungsbehandlungs-Programms ist die Latenzzeit die
Zeitspanne zwischen Eintreffen des Unterbrechungssignals bei
der datenverarbeitenden Vorrichtung und dem Start des
Unterbrechungsbehandlungs-Programms, das dem
Unterbrechungssignal zugeordnet ist. Die Zeitspanne zwischen
Beginn und Ende der Ausführung des Software-Prozesses wird als
Ausführungszeit bezeichnet. Die Summe aus Latenzzeit und
Ausführungszeit wird als Reaktionszeit des Software-Prozesses
bezeichnet. Bei bekannter Arbeitsgeschwindigkeit der
datenverarbeitenden Vorrichtung und Aufbau des Software-
Prozesses läßt sich eine obere Schranke für die Reaktionszeit
des Prozesses für den Fall angeben, daß die Ausführung nicht z. B.
durch unvorhergesehene Ereignisse unterbrochen wird.
Jedoch ist in der Praxis jederzeit mit derartigen Ereignissen
zu rechnen, die bei bekannten Vorrichtungen und Verfahren die
Reaktionszeit in nicht vorhersehbarer Weise verlängern oder
dazu führen, daß der Software-Prozeß ohne Ergebnis abgebrochen
wird. Insbesondere bei sicherheitskritischen Anwendungen, z. B.
in Verkehrsmitteln oder bei der Überwachung von
Fertigungsprozessen, wird verlangt, daß die datenverarbeitende
Vorrichtung bestimmte Software-Prozesse in Echtzeit ("real
time") ausführen kann. Diese Anforderung bedeutet, daß die
Reaktionszeit eines Software-Prozesses eine vorgegebene obere
Schranke auch dann nicht übersteigt, wenn unvorhergesehene
Ereignisse auftreten. Diese vorgegebene obere Schranke wird im
folgenden als maximale Reaktionszeit bezeichnet. Die Einhaltung
der maximalen Reaktionszeit ist insbesondere dann wichtig, wenn
der Software-Prozeß ein Unterbrechungsbehandlungs-Programm ist,
mit dem auf ein Unterbrechungssignal als Folge eines
sicherheitskritischen plötzlich aufgetretenen Ereignisses
reagiert wird.
Unter responsiven Systemen werden echtzeitfähige Systeme
verstanden, die nach Ablauf der vorgegebenen maximalen
Reaktionszeit ein Ergebnis ("response") erbringen. Gewünscht
werden insbesondere ein Verfahren und eine Einrichtung, um
einen Software-Prozeß zu einem Bestandteil eines responsiven
Systems zu machen.
Aus DE 32 43 760 C2 ist eine Einrichtung zur Überwachung eines
Programmlaufs mit Hilfe einer Zeitüberwachungseinrichtung
bekannt. Die Zeitüberwachungseinrichtung löst eine abgestufte
Reaktion aus, wenn eine vorgegebene erste Zeitspanne
verstrichen ist, ohne daß eine Meldung von einem Prozessor über
die vollständige Abarbeitung des Programms eingetroffen ist.
Zuerst wird ein Signal generiert, das eine Unterbrechung der
Ausführung des Programms (Software-Interrupt) auslöst und das
Programm erneut startet oder an einer definierten Stelle
fortsetzt. Nach Ablauf einer zweiten Zeitspanne wird ein
Hardware-Reset ausgelöst, der einen Neustart des
Programmablaufs bewirkt. Nach Ablauf einer dritten Zeitspanne
wird der Prozessor inaktiv geschaltet, und/oder ein Alarm
wird ausgelöst.
In DE 32 43 760 C2 wird nicht offenbart, welches Ergebnis das
Programm nach Auslösen einer der möglichen abgestuften Reak
tionen erbringt. Wird ein Neustart ausgelöst, so liefert der
abgebrochene Programmlauf überhaupt kein definiertes Ergeb
nis. Möglich ist, daß die Abarbeitung an einer definierten
Stelle des Programms fortgesetzt wird. Bei dieser Ausgestal
tung kann keine maximale Reaktionszeit des Programms garan
tiert werden.
In DE 44 46 286 C1 wird ein responsives und damit echtzeitfähi
ges und fehlertolerantes System mit Funktionsbausteinen of
fenbart. Jedem Funktionsbaustein ist eine maximale Bearbei
tungszeit zugeordnet. Ein Modul für zeitliche Planung ("Ti
ming-Modul") bestimmt die maximale Reaktionszeit des Systems
auf ein Eingangssignal. Bereits vor Inbetriebnahme eines Sy
stems, das mit derartigen Funktionsbausteinen aufgebaut ist,
läßt sich dessen maximale Reaktionszeit vorhersagen.
Nicht offenbart wird in DE 44 46 286 C1, wie die Einhaltung
dieser Reaktionszeit auch im Fall von Störungen und sonstigen
unvorhergesehenen Ereignissen eingehalten wird. Solche Erei
gnisse, z. B. Ausfall eines Prozesses, können nämlich dazu
führen, daß ein Funktionsbaustein nicht wie spezifiziert bin
nen der zugeordneten maximalen Bearbeitungszeit ein Ergebnis
liefert und andere Funktionsbausteine, die dieses Ergebnis
benötigen, ihre Arbeit nicht beginnen können. Aber gerade si
cherheitskritische Systeme müssen auch bei einem Ausfall bin
nen einer vorgegebenen Reaktionszeit ein brauchbares Ergebnis
liefern.
In DE 43 29 872 A1 wird eine Überwachungseinrichtung für einen
Prozessor, der ein Software-Programm ausführt, offenbart. Der
Prozessor kann vom Aktiv-Modus in einen Ruhe-Modus und umge
kehrt umgeschaltet werden. Die Ausführung des Programms wird
nach einer Unterbrechung infolge Umschaltens in den Ruhe-
Modus und späterer Umschaltung in den Aktiv-Modus an der
Stelle fortgesetzt, an der die Ausführung unterbrochen wurde.
Die Überwachungseinrichtung sendet ein Unterbrechungssignal
an den Prozessor, um diesen in den Aktiv-Modus umzuschalten.
Sie wird durch ein Trigger-Signal über die Fortsetzung der
Programm-Ausführung informiert. Falls die Ausführung des Pro
gramms nicht nach einer vorgegebenen Zeitspanne beendet ist,
wird die Ausführung abgebrochen und der Prozessor erneut ge
startet ("Reset"). Auch durch diese Überwachungseinrichtung
kann nicht vorhergesagt werden, welches Ergebnis das Programm
dann erbringt, wenn dessen Ausführung infolge Überschreitens
der Zeitspanne abgebrochen wird.
Aus DE 35 44 079 C2 ist ein Verfahren zur Verarbeitung von Un
terbrechungssignalen bekannt, aus DE 35 44 079 A1 ein Rechner
mit mindestens einem vordefinierten Unterbrechungsbehand
lungs-Programm (Interrupt-Programm). Sobald ein Unterbre
chungssignal registriert wird, wird das gerade ablaufende
Hauptprogramm unterbrochen und statt dessen das Unterbre
chungsbehandlungs-Programm gestartet. Weitere Anforderungen
durch zusätzliche Unterbrechungssignale werden für eine defi
nierte Zeitspanne gesperrt, d. h. weitere Unterbrechungsbe
handlungs-Programme
z. B. von derselben Quelle von Unterbrechungssignalen können im
definierten Zeitraum nicht ausgeführt werden. Nach Ablauf der
Zeitspanne wird die Sperrung der Anforderungen durch
Unterbrechungssignale aufgehoben. Ein Verfahren mit diesen
Schritten wird im Anspruch 1 von DE 35 44 079 C2 beschrieben. Die
Sperrung für eine definierte Zeitspanne wird in DE 35 44 079 C2
mit Hilfe eines Zeitzählers realisiert, der gemeinsam mit dem
Unterbrechungsbehandlungs-Programm gestartet wird. Gemäß einer
Ausgestaltung ist vorgesehen, daß weitere Anforderungen durch
zusätzliche Unterbrechungssignale, die während der Zeitspanne
eintreffen, gelöscht werden.
Durch das in DE 35 44 079 C2 offenbarte Verfahren wird
sichergestellt, daß in der vorgegebenen Zeitspanne kein
weiteres Unterbrechungssignal dazu führen kann, daß die
Ausführung des Unterbrechungsbehandlungs-Programms unterbrochen
oder verzögert wird. Nicht sichergestellt werden kann aber, daß
das Unterbrechungsbehandlungs-Programm nach Ablauf der
Zeitspanne mit einem brauchbaren Ergebnis beendet wird.
In US 5,257,357 wird eine datenverarbeitende Vorrichtung mit
mehreren Modulen offenbart, die Unterbrechungssignale
produzieren. Eine Auswahllogik erhält Unterbrechungssignale als
Eingangssignale und vermag den Unterbrechungssignalen geänderte
Prioritäten zuzuordnen, und zwar in Abhängigkeit von
entsprechenden Anpassungs-Signalen. Ein Benutzer kann mit Hilfe
dieser Auswahllogik bestimmten Unterbrechungssignalen eine
höhere Priorität zuordnen. Eine Verarbeitungslogik erzeugt aus
den bei Bedarf veränderten Signalen einen Vektor von
Unterbrechungssignalen, der z. B. an einen Prozessor zur
Ausführung von Unterbrechungsbehandlungs-Programmen gesandt
wird. Dadurch wird der Prozessor davon entlastet, selber
Unterbrechungssignale zu identifizieren und hinsichtlich ihrer
Prioritäten zu unterscheiden oder zu klassifizieren. Nicht
offengelegt wird, wie die Bearbeitung eines ersten
Unterbrechungsbehandlungs-Programms mit niedrigerer Priorität
fortgesetzt wird, wenn ein zweites Signal mit höherer Priorität
eintrifft und deswegen das erste Unterbrechungsbehandlungs-
Programm unterbrochen oder abgebrochen wird.
In DE 199 27 657 A1 wird ein Verfahren offenbart, um die
unkontrollierte Ausbreitung von Softwarefehlern zu verhindern
und den Ablauf mehrerer Software-Prozesse unabhängig
voneinander auf einem Prozessor zu ermöglichen. Gemäß dem
offenbarten Verfahren wird ein Programmspeicher in einzelne
Speicherbereiche unterteilt. Diesen Speicherbereichen werden
fest einzelne Speichermodule zugeordnet, die Zuordnung läßt
sich auch im Fehlerfall nicht ändern. Den Programm-Modulen
werden feste maximale Ausführungszeiten zugeordnet, deren
Einhaltung überwacht wird. Das laufende Programm kann weiterhin
die Zeitüberwachung auch im Fehlerfall nicht beeinflussen. Im
Fehlerfall löst ein dann erzeugtes Unterbrechungssignal ein
Notprogramm (Interrupt Service Routine) für die
Fehlerbehandlung aus.
Das in DE 199 27 657 A1 offenbarte Verfahren erfordert, feste
maximale Verarbeitungszeiten für die Programm-Module vorab
festzulegen und in einer Zuordnungstabelle abzuspeichern. Dies
erfordert eine gute Kenntnis der Programm-Module, ihrer
Wirkungsweise und der zu erwartenden Ausführungszeit. Weiterhin
sind zusätzliche Speicher- und Rechenkapazitäten für die
Zuordnungstabelle und deren Auswertung bereitzustellen.
Offenbart wird weiterhin eine Reaktion auf das Auftreten eines
internen Fehlers im Software-Prozeß, z. B. auf ein
Überschreiten eines verfügbaren Speicherbereichs, auf eine
Endlosschleife oder auf eine Division durch 0. Hingegen wird
nicht offenbart, wie die Reaktionszeit des Software-Prozesses
beim Auftreten äußerer Ereignisse, also solchen, die nicht
durch die Ausführung des Software-Prozesses selber verursacht
werden, eingehalten wird.
In EP 0717361 A2 wird eine Vorgehensweise offenbart, um die
Reaktionszeit eines Unterbrechungsbehandlungs-Programms
vorhersagbar zu machen. Eine Menge von möglichen Ereignissen
wird vorab identifiziert, welche die Ausführung eines
Unterbrechungsbehandlungs-Programms verzögern können. Mit Hilfe
von zwei Zeitgliedern werden zwei periodisch wiederkehrende
Zeitintervalle realisiert: ein erstes Zeitintervall, in dem die
Ausführung eines Unterbrechungsbehandlungs-Programms durch
Ereignisse verzögert werden kann, und ein zweites
Zeitinterwall, in der das Unterbrechungsbehandlungs-Programm
unterbrechungsfrei ausgeführt wird. Während des zweiten
Zeitintervalls werden alle eintreffenden Ereignisse, die die
Ausführung verzögern können, unterbunden und erst nach
vollständiger Ausführung des Unterbrechungsbehandlungs-
Programms wieder zugelassen.
Die in EP 0717361 A2 offenbarte Vorgehensweise garantiert die
Einhaltung einer maximalen Reaktionszeit nur im zweiten
Zeitintervall, nicht aber während der gesamten Arbeitszeit der
datenverarbeitenden Vorrichtung. Außerdem müssen vorab alle
möglicherweise verzögernden Ereignisse identifiziert werden.
Dies ist mit Aufwand verbunden. Falls ein Ereignis übersehen
wird oder unvorhergesehen oder in abweichender Form oder
unvollständig auftritt, tritt der gewünschte Effekt
möglicherweise nicht ein.
In US 6,085,218 wird ein Verfahren offenbart, um in einer
Mehrprozeß-Ablaufumgebung die Ausführungszeit eines Software-
Prozesses zu überwachen. Diejenigen Ausführungs-Zeitspannen
("execution cycles"), in denen ein einzelner Prozessor den
Software-Prozeß ausführt, werden gezählt. Deren Längen hängen
von der Taktzeit des Prozessors ab. Wenn die Anzahl der
Ausführungs-Zeitspannen eine vorgegeben obere Schranke
erreicht, wird vorzugsweise die Ausführung des Software-
Prozesses abgebrochen. Die Zählung der Ausführungs-Zeitspannen
wird unterbrochen, wenn ein Unterbrechungssignal ein
Unterbrechungsbehandlungs-Programm mit höherer Priorität
auslöst. Vorzugsweise wird die erreichte Anzahl von
Ausführungs-Zeitspannen gespeichert, und die Ausführung des
Software-Prozesses wird fortgesetzt, nachdem das
Unterbrechungsbehandlungs-Programm vollständig ausgeführt
wurde.
Nicht offenbart wird in US 6,085,218, mit welchem Resultat des
Software-Prozesses gearbeitet wird, wenn dessen Ausführung
z. B. wegen Erreichens der vorgegebenen oberen Schranke
abgebrochen wird. Es bleibt nur der Ausweg, ohne ein Resultat
des Software-Prozesses zu arbeiten, was oft unbefriedigend ist
oder zu nicht vorhersagbaren Ergebnissen eines übergeordneten
Software-Systems führen kann.
Der Erfindung liegt die Aufgabe zugrunde sicherzustellen, daß
der Software-Prozeß spätestens nach einer vorgegebenen
Reaktionszeit endet und auch bei einem Abbruch ein Ergebnis
erbringt, das trotz des Abbruchs brauchbar ist. Weiterhin soll
die Sicherstellung wenig zusätzlichen Aufwand erfordern.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine
Vorrichtung nach Anspruch 18 gelöst.
Durch die Erfindung wird garantiert, daß die Ausführung des
Software-Prozesses unter allen Umständen nach Ablauf der
maximalen Reaktionszeit beendet ist. Auch dann, wenn die
Ausführung des Software-Prozesses abgebrochen wird, erbringt er
noch ein vorhersagbares und unter den Umständen bestmögliches
Endergebnis.
Echtzeitfähige Verfahren nach dem Stand der Technik erfordern
oft aufwendige Berechnungen, bei denen vom ungünstigsten Fall
ausgegangen wird (Worst-Case-Berechnungen). Neben dem Aufwand
für die erforderliche Modellbildung und die Berechnungen ist
hierbei von Nachteil, daß die garantierte Reaktionszeit oft
sehr hoch ist. Das erfindungsgemäße Verfahren erfordert keine
Worst-Case-Berechnungen. Es genügt, die Reaktionszeiten der
Teilprozesse beim Ausbleiben von Unterbrechungen zu bestimmen.
Die Erfindung garantiert eine kürzere Reaktionszeit, innerhalb
derer das Endergebnis bei vollständiger Ausführung des
Software-Prozesses oder das Ergebnis des ausgewählten
Teilprozesses erbracht wird. Deshalb ist das Verfahren für
responsive Systeme geeignet.
Weiterhin ist es dank der Erfindung nicht erforderlich, eigens
zur Einhaltung der vorgegebenen maximalen Reaktionszeit die
datenverarbeitende Vorrichtung erheblich überzudimensionieren
und z. B. zusätzliche Prozessoren für
Unterbrechungsbehandlungen vorzusehen.
Ein weiterer Vorteil der Erfindung macht sich bemerkbar, wenn
die maximale Reaktionszeit abgelaufen ist, ohne daß der
Software-Prozeß vollständig bis zum Ende ausgeführt worden ist.
Verfahren nach dem Stande der Technik erbringen in dieser
Situation entweder gar kein Ergebnis, setzen die Ausführung zu
einem späteren Zeitpunkt fort oder beginnen erst zu diesem
zeitaufwendig, und gerade nach Ablauf der maximalen
Reaktionszeit steht kaum Rechenzeit zur Verfügung.
Im Gegensatz zu bekannten Verfahren und Vorrichtungen ist es
dank der Erfindung zwar möglich, aber nicht erforderlich, die
Ausführung weiterer gleichartiger Software-Prozesse für eine
definierte Zeitspanne zu sperren.
Die Erfindung spart weiterhin Arbeitsaufwand bei der
Implementierung sowie Rechenaufwand für die Ausführung des
Software-Prozesses und für Kommunikation mit anderen Prozessen
ein. Im Software-Prozeß selber brauchen weniger oder gar keine
Sonderbehandlungen und Reaktionen auf externe Ereignisse
vorhergesehen zu sein, und entsprechende Bedingungen und
Fallunterscheidungen brauchen zur Ausführungszeit nicht geprüft
zu werden. Vielmehr wird in einer bevorzugten Ausführungsform
(Anspruch 14) automatisch auf externe Ereignisse effizient
reagiert. Bestimmte Ereignisse lösen vordefinierte
Unterbrechungssignale mit zugeordneten
Unterbrechungsbehandlungs-Programmen aus. Tritt während der
Ausführung des Software-Prozesses ein solches Ereignis ein, so
wird der Software-Prozeß unterbrochen und das dem Ereignis
zugeordnete Unterbrechungsbehandlungs-Programm gestartet. Die
Reaktionszeit des Unterbrechungsbehandlungs-Programms wird zur
Reaktionszeit des Software-Prozesses addiert. Ein Zeitglied für
die Überwachung der maximalen Reaktionszeit läuft weiter. Wird
die maximale Reaktionszeit des Software-Prozesses infolge der
Ausführung des Unterbrechungsbehandlungs-Programms
überschritten, so wird automatisch und ohne Sonderbehandlung
das Ergebnis des erfindungsgemäß ausgewählten Teilprozesses als
Endergebnis verwendet. Diese Unterbrechungsbehandlung braucht
weiterhin nicht bei der Implementierung des Software-Prozesses
berücksichtigt zu werden.
In einer alternativen Ausführungsform wird die Reaktionszeit
des Unterbrechungsbehandlungs-Programms dann nicht zur
Reaktionszeit des Software-Prozesses addiert, wenn das
Unterbrechungsbehandlungs-Programm eine höhere Priorität als
der Software-Prozeß hat. Ein Zeitglied für die Überwachung der
maximalen Reaktionszeit wird angehalten. In diesem Fall kann
die maximale Reaktionszeit des Software-Prozesses überschritten
werden. In manchen Anwendungen ist dies zulässig. Ein weiterer
Vorzug der Erfindung ist es, daß man einfach diese beiden
unterschiedlichen Verhaltensweisen, nämlich Abbruch oder
Fortsetzung bei Zeitüberschreitung infolge eines
Unterbrechungsbehandlungs-Programms, sehr einfach konfigurieren
kann, nämlich z. B. durch entsprechende Konfiguration des
überwachenden Zeitgliedes.
Bei der Ausführung des Software-Prozesses wird das Endergebnis
beispielsweise iterativ, d. h. schrittweise, durch den
Software-Prozeß erbracht (Anspruch 5). Jeder Teilprozeß
erbringt ein Näherungsergebnis für das Endergebnis. Nach einem
Abbruch wird derjenige Teilprozeß ausgewählt, der als letzter
vor dem Abbruch vollständig ausgeführt wurde. Das
Näherungsergebnis dieses Teilprozesses wird im Falle des
Abbruchs als Endergebnis des Software-Prozesses verwendet.
Beispielsweise unterscheidet sich das Näherungsergebnis jedes
Teilprozesses vom Endergebnis um höchstens eine vorgegebene
Schranke, z. B. 1 mm, und jedes Näherungsergebnis liegt näher
am Endergebnis als das vorige. Bei dieser Ausgestaltung ist
automatisch und ohne zusätzlichen Aufwand eine obere Schranke
für die Abweichung zwischen dem Näherungsergebnis nach Abbruch
und dem Endergebnis, das bei vollständiger Ausführung des
Software-Prozesses berechnet worden wäre, bekannt.
Insbesondere bei iterativer Erbringung des Endergebnisses
verwendet vorzugsweise jeder Prozeß das Ergebnis des zuvor
ausgeführten Teilprozesses, also des Vorgänger-Teilprozesses,
als Eingangswert. Der Teilprozeß erbringt bevorzugt ein
besseres Näherungsergebnis als der Vorgänger-Teilprozeß, d. h.
eine mit geringerer Abweichung zum Endergebnis. In einer
Ausführungsform werden die berechneten Näherungsergebnisse
nacheinander in demselben Speicher abgespeichert (Anspruch 6).
Ein Näherungsergebnis überschreibt dabei das des zuvor
berechneten Näherungsergebnisses. Nach einem Abbruch wird
dieser Speicher ausgelesen, und sein Inhalt wird als
Endergebnis verwendet (Anspruch 20). Diese Ausgestaltung ist
fehlertolerant z. B. gegen plötzliche Ausfälle eines
Prozessors, der die Teilprozesse ausführt, und erfordert nur
einen einzigen zusätzlichen Speicher.
Vorzugsweise wird vorab ein Standardwert für das Endergebnis
des Software-Prozesses bestimmt oder eine schnell
durchzuführenden Handlung, z. B. Abschalten von Geräten oder
Beenden weiterer Software-Prozesse, ausgeführt. Dieser
Standardwert ("default value") ist beispielsweise eine
Konstante oder ein schnell zu berechnender Wert, der von einem
vor dem Start des Software-Prozesses feststehenden Parameter
abhängt. Der Standardwert kann ein Vorzugswert, ein Startwert
für eine Iteration oder eine sinnvolle Voreinstellung sein.
Gemäß Anspruch 7 umfaßt ein Standardwert-Ermittlungs-Teilprozeß
das Auslösen der schnell durchzuführenden Handlung oder die
Ermittlung dieses Standardwertes, beispielsweise durch schnelle
Berechnung oder Auslesen eines Speichers, in dem die Konstante
abgespeichert ist. Beispielsweise wird dieser Standardwert-
Ermittlungs-Teilprozeß als erster ausgeführt (Anspruch 9).
Diese Ausführungsform hat den Vorzug, daß in der Regel sehr
schnell ein Ergebnis eines Teilprozesses vorliegt, nämlich
dann, wenn die Ermittlung des Standardwertes bzw. Auslösen der
Handlung wenig Zeit im Vergleich zur Ausführungszeit anderer
Teilprozesse erfordert. Dadurch wird auch bei einem sehr
frühzeitigen Abbruch des Software-Prozesses ein gutes
Endergebnis erbracht. Diese Ausgestaltung ist insbesondere dann
von Vorteil, wenn neben der maximalen Reaktionszeit zusätzlich
eine maximale Notreaktionszeit vorgegeben ist. Während die
maximale Reaktionszeit die Zeitspanne bis zur vollständigen
Ausführung des Software-Prozesses ist, beschreibt die maximale
Notreaktionszeit die Latenzzeit zuzüglich der Zeitspanne, in
der mindestens eine erste Notreaktion vollständig ausgeführt
ist. Vorzugsweise wird der Standardwert-Ermittlungs-Teilprozeß
als Notreaktion so definiert, daß er innerhalb der maximalen
Notreaktionszeit abgeschlossen ist.
Die Ausführungsform nach Anspruch 11 sieht hingegen vor, daß
der erste Teilprozeß dann ausgeführt wird, wenn der Software-
Prozeß abgebrochen wird, weil die maximale Reaktionszeit
beinahe verstrichen ist. Der Abbruch wird noch so rechtzeitig
durchgeführt, daß nach dem Abbruch der erste Teilprozeß
ausgeführt werden kann. Nach dem Abbruch liefert der erste
Teilprozeß den Standardwert, der als Endergebnis des Software-
Prozesses verwendet wird.
Die Einhaltung der maximalen Reaktionszeit kann mit Hardware
oder Software überwacht werden. Bevorzugt wird mindestens ein
Hardware-Bauteil verwendet (Anspruch 2), z. B. ein durch
einfache Hardware-Komponenten realisierbares Zeitglied
verwendet (Anspruch 21). Die Erfindung hat dann den
zusätzlichen Vorzug, daß die Überwachung wenig zusätzliche
Hardware erfordert.
Die Realisierung durch Hardware, insbesondere durch ein
Zeitglied, ist der bevorzugte Weg, um sicherzustellen, daß
tatsächlich die gesamte Reaktionszeit überwacht und begrenzt
wird und nicht etwa nur die Ausführungszeit. Bevorzugt beginnt
die Zeitspanne mit dem Eintreffen eines Signals, das den
Software-Prozeß auslöst, z. B. eines Unterbrechungssignals.
Falls die Reaktionszeit hingegen mit Hilfe von Befehlen eines
Betriebssystems überwacht wird, so vergeht ein gewisser
Zeitverzug, bis das Betriebssystem die Anforderung nach
Auslösen des Software-Prozesses registriert und in seine
Prioritätenliste aufgenommen hat. Dieser Zeitverzug kann nicht
überwacht und damit berücksichtigt und begrenzt werden. Falls
erst der ausgelöste Software-Prozeß die Zeitspanne beginnen
läßt, läßt sich nur die Ausführungszeit, nicht aber die
Latenzzeit, überwachen und begrenzen. Die Latenzzeit kann z. B.
durch das Auftreten anderer Software-Prozesse mit höherer
Priorität unvorhersehbar lang sein.
Im folgenden wird die Erfindung anhand von zwei in den
Zeichnungen dargestellten Ausführungsbeispielen erläutert;
dabei veranschaulichen:
Fig. 1 den Aufbau eines Motorsteuergeräts, das den
Zündzeitpunkt berechnet;
Fig. 2 den Aufbau einer Überwachungseinrichtung für eine
Unterbrechungsbehandlung.
Die Erfindung wird zunächst am Beispiel eines
Motorsteuergeräts 10 erläutert. Dieses Motorsteuergerät 10
berechnet während jeder Umdrehung, also während jedes
vollständigen Arbeitstaktes des Motors, erneut den Zeitpunkt
der Zündung. Den richtigen Zündzeitpunkt zu treffen senkt den
Benzinverbrauch und den Ausstoß an Schadstoffen. Der richtige
Zündzeitpunkt trägt damit u. U. dazu bei, gesetzliche Auflagen
hinsichtlich der Umweltverträglichkeit zu erfüllen, und
steigert die Wirtschaftlichkeit des Kraftfahrzeuges und damit
die Wettbewerbsfähigkeit des Herstellers.
Verfahren nach dem Stand der Technik berechnen nur bis zu einer
bestimmten, vorgegebenen Motor-Drehzahl den Zündzeitpunkt
während jeder Umdrehung neu. Steigt die Motor-Drehzahl über die
vorgegebene Grenze, wird nur noch während jeder zweiten
Umdrehung der Zündzeitpunkt erneut berechnet. Für die
dazwischenliegenden Umdrehungen wird der zuletzt berechnete
Wert wiederverwendet. Dadurch wird u. U. der optimale
Zündzeitpunkt nicht getroffen. Wird eine zu niedrige Schranke
für die Motor-Drehzahl vorgegeben, so wird eine erneute
Berechnung nicht durchgeführt, obwohl noch Rechenzeit zur
Verfügung steht. Wird eine zu große Schranke vorgegeben, so muß
die Berechnung u. U. abgebrochen werden, weil keine Rechenzeit
mehr zur Verfügung steht.
Fig. 1. zeigt einen Aufbau eines Motorsteuergeräts 10, in dem
die Erfindung angewendet wird. Das Motorsteuergerät 10 umfaßt
einen Ausführungs-Prozessor 20, der u. a. während jeder
Umdrehung den Zündzeitpunkt erneut bestimmt. Die hierfür
erforderlichen Daten über den aktuellen Zustand des Fahrzeugs,
z. B. die Motordrehzahl und die Fahrgeschwindigkeit, beschafft
der Ausführungs-Prozessor 20 sich bei Bedarf aus einem internen
Datenspeicher 80 oder über eine Schnittstelle 90 zu einem
Datenbus im Fahrzeug, der das Motorsteuergerät 10 u. a. mit
weiteren Steuergeräten verbindet. Die Berechnung des
Zündzeitpunkts besteht im wesentlichen daraus, daß ein
Berechnungsprogramm ausgeführt wird. Der ausführende Software-
Prozeß umfaßt also die Ausführung dieses Berechnungsprogramms.
Das Berechnungsprogramm ist in einem ersten Programmspeicher 40
für Berechnungsprogramme abgespeichert.
In Fig. 1. sind Daten- und Signalflüsse durch dünne Pfeile und
schreibende oder Stelleingriffe durch dicke Pfeile dargestellt.
Weiterhin umfaßt das Motorsteuergerät 10 einen
Ergebnisspeicher 70, das ist ein Datenspeicher, in dem das
Endergebnis, also der berechnete Zündzeitpunkt, abgespeichert
wird. Dieser Ergebnisspeicher 70 ist in zwei Daten-Teilspeicher
unterteilt. Im ersten Daten-Teilspeicher 71 wird das berechnete
Endergebnis abgespeichert. Im zweiten Daten-Teilspeicher 72 ist
das Endergebnis der Berechnung während der vorigen Umdrehung,
also der zuletzt verwendete Zündzeitpunkt, abgespeichert.
Der Ausführungs-Prozessor 20 führt nacheinander die
Teilprozesse aus. Jeder Teilprozeß erbringt nach seiner
Ausführung ein Ergebnis. Dieses Ergebnis schreibt der
Ausführungs-Prozessor 20 in den ersten Daten-Teilspeicher 71,
wobei ein zuvor abgespeichertes Ergebnis bevorzugt
überschrieben wird.
Der Ausführungs-Prozessor 20 bestimmt vorzugsweise iterativ,
d. h. schrittweise, den richtigen Zündzeitpunkt. Der erste
Teilprozeß berechnen einen Startwert für die Iteration. Dieser
Startwert ist z. B. ein allgemeingültiger Vorzugswert oder auch
das Endergebnis der vorigen Berechnung, also der letzte
Zündzeitpunkt. Jeder Berechnungsschritt ist ein Teilprozeß des
Software-Prozesses. Die Berechnungsschritte und damit die
Teilprozesse werden nacheinander ausgeführt. Jeder
Berechnungsschritt erbringt ein Ergebnis, das genauer als das
Ergebnis des vorigen Berechnungsschrittes ist. Für die
Ausführung eines Berechnungsschrittes - außer für die des
ersten Berechnungsschrittes - wird bevorzugt das Ergebnis des
vorigen Berechnungsschrittes verwendet. Für den ersten
Berechnungsschritt kann der vom ersten Teilprozeß berechnete
Startwert als Eingangsgröße verwendet werden. In Fig. 1. sind
im ersten Programmspeicher 40 für Berechnungsprogramme ein
erster Programm-Teilspeicher 41 für den ersten Teilprozeß,
durch den der Startwert berechnet wird, und ein zweiter
Programm-Teilspeicher 42 für den Berechnungsschritt, der
mehrfach ausgeführt wird, dargestellt. Das Ergebnis jedes
Berechnungsschrittes wird im ersten Daten-Teilspeicher 71
abgespeichert.
Vorzugsweise umfaßt der Software-Prozeß selber ein
Abbruchkriterium, z. B. Anzahl der Berechnungsschritte. Am Ende
der Berechnung ist das Endergebnis, nämlich der Zündzeitpunkt,
im Ergebnisspeicher 70 abgespeichert und wird für nachfolgende
Arbeitsschritte des Motorsteuergeräts 10 verwendet. Diese
nachfolgenden Arbeitsschritte und die Vorrichtungen für diese
sind in Fig. 1. nicht dargestellt. Möglich ist aber auch, daß
die Ausführung des Software-Prozesses stets die vorgegebene
Reaktionszeit vollständig beansprucht und erst durch die
Überwachungseinrichtung 30 auf die Weise abgebrochen wird, die
im folgenden beschrieben wird.
Die Überwachungseinrichtung sorgt erfindungsgemäß dafür, daß
die vorgegebene Reaktionszeit eingehalten wird. Die
Überwachungseinrichtung umfaßt ein Zeitglied. In dem Moment, zu
dem die Latenzzeit für die Berechnung des Zündzeitpunktes
beginnt, wird ein Zähler des Zeitgliedes auf einen
vordefinierten Wert gesetzt. Der Beginn der Latenzzeit ist
z. B. der Zeitpunkt, zu dem das Motorsteuergerät 10 den Befehl
zum Berechnen des Zündzeitpunktes erzeugt. Der vordefinierte
Wert ist bevorzugt umgekehrt proportional zur Motor-Drehzahl.
Bevorzugt mit jedem Takt, den z. B. eine Systemuhr 200 des
Motorsteuergeräts 10 erzeugt, wird der Zähler um einen Wert von
1 verkleinert. Die Arbeit des Zeitgliedes wird abgebrochen,
sobald die Ausführung des Software-Prozesses abgeschlossen und
das berechnete Endergebnis im ersten Teil-Datenspeicher
abgespeichert ist. Bevorzugt übermittelt der Ausführungs-
Prozessor 20 hierfür ein entsprechendes Ende-Signal an die
Überwachungseinrichtung.
In dem Moment, in dem der Zähler des Zeitgliedes den Wert 0
erreicht, ohne daß die Überwachungseinrichtung das Ende-Signal
vom Ausführungs-Prozessor 20 erhalten hat, steht fest, daß die
vorgegebene Zeitspanne verstrichen ist. Dies kann z. B. deshalb
eingetreten sein, weil andere Prozesse mit höherer Priorität
einen erheblichen Anteil der Rechenzeit des Ausführungs-
Prozessors 20 beanspruchten oder weil vorgesehen ist, daß der
Teilprozeß die vorgegebene Reaktionszeit vollständig ausnutzt.
Erfindungsgemäß löst die Überwachungseinrichtung dann, wenn der
Zähler den Wert 0 erreicht, eine Unterbrechungsbehandlung aus.
Hierfür ruft die ein Unterbrechungsbehandlungs-Programm auf,
das in einem zweiten Programmspeicher 50 für
Unterbrechungsbehandlungs-Programme abgespeichert ist.
Dieses Unterbrechungsbehandlungs-Programm entscheidet bevorzugt
zuerst, auf welche Weise der nunmehr als Zündzeitpunkt
verwendete Wert berechnet wird. Hierfür wird bevorzugt eine
Entscheidung zwischen folgenden Alternativen getroffen:
- - Das Ergebnis des Teilprozesses, der als letzter ausgeführt wurde, wird als aktueller Zündzeitpunkt verwendet. Dieses Ergebnis ist im ersten Teil-Datenspeicher 71 des Ergebnisspeichers 70 abgespeichert.
- - Der vorige Zündzeitpunkt wird bestimmt und als aktueller Zündzeitpunkt wiederverwendet.
- - Ein Vorzugswert für den Zündzeitpunkt wird bestimmt und als aktueller Zündzeitpunkt verwendet.
Bereits bei der Konstruktion des Motorsteuergeräts 10 kann
vorgesehen sein, daß stets eine dieser drei Alternativen
ausgeführt wird. Bevorzugt wird die Entscheidung aber erst zum
Zeitpunkt der Unterbrechungsbehandlung getroffen. Eine
Ausführungsform sieht vor, daß der Ausführungs-Prozessor 20 ein
Zwischen-Signal an die Überwachungseinrichtung übermittelt,
sobald er eine vorab festgelegte Anzahl von Teilprozessen
ausgeführt hat und das Ergebnis des als letzten ausgeführten
Teilprozesses in den ersten Daten-Teilspeicher 71 abgespeichert
hat. Beispielsweise wird das Zwischen-Signal übermittelt,
sobald der Ausführungs-Prozessor 20 den ersten Teilprozeß
ausgeführt und den Startwert in den ersten Daten-Teilspeicher
71 abgespeichert hat oder sobald er den dritten Teilprozeß
ausgeführt und damit den Startwert berechnet und anschließend
zwei Berechnungsschritte ausgeführt hat. Falls dieses Zwischen-
Signal bei der Überwachungseinrichtung eingetroffen ist, bevor
die Unterbrechungsbehandlung begonnen wurde, so wird das im
ersten Daten-Teilspeicher 71 abgespeicherte Ergebnis als
Endergebnis, also als aktueller Zündzeitpunkt, verwendet,
ansonsten das im zweiten Daten-Teilspeicher 72 abgespeicherte
Ergebnis, also der vorige Zündzeitpunkt. Eine Fortbildung
dieser Ausführungsform sieht vor, daß dann, wenn das Zwischen-
Signal nicht vorliegt, eine Entscheidung gefällt wird, ob der
vorige Zündzeitpunkt wiederverwendet wird oder statt dessen ein
Vorzugswert bestimmt und als aktueller Zündzeitpunkt verwendet
wird. Diese Entscheidung kann davon abhängen, ob sich seit der
Berechnung des vorigen Zündzeitpunktes wesentliche
Umgebungsbedingungen, z. B. die Motordrehzahl, geändert haben
oder nicht.
Alle diese Ausführungsformen sehen vor, daß schnell und auf
vorhersagbare Weise ein brauchbarer Zündzeitpunkt berechnet
wird. Im Berechnungsprogramm für den Zündzeitpunkt brauchen
externe Ereignisse, die die Berechnung des Zündzeitpunktes
verzögern können, nicht berücksichtigt zu werden. Weiterhin
braucht im Berechnungsprogramm nicht die Wiederverwendung des
vorigen Zündzeitpunktes bei hohen Motor-Drehzahlen oder bei
hoher Prozessor-Belastung vorgesehen zu werden.
Beim zweiten Ausführungsbeispiel ist der Software-Prozeß,
dessen Reaktionszeit begrenzt wird, selber ein
Unterbrechungsbehandlungs-Programm (Interrupt Service Routine),
das einem vordefinierten Unterbrechungssignal-Typ (Interrupt
Request) zugeordnet ist. Der Unterbrechungssignal-Typ ist eines
von M vordefinierten Unterbrechungssignal-Typen, wobei M eine
natürliche Zahl ist. Bevorzugt durch die Kennung werden die M
Unterbrechungssignal-Typen voneinander unterschieden. Jedem
Unterbrechungssignal-Typ ist weiterhin eines von M
Unterbrechungsbehandlungs-Programmen zugeordnet. Ein
Unterbrechungssignal desselben Typs kann mehrmals zu
verschiedenen Zeitpunkten eintreffen.
Bevorzugt umfaßt jedes Unterbrechungsbehandlungs-Programm je
einen Standardwert-Ermittlungs-Teilprozeß, der einen
Standardwert wie oben beschrieben ermittelt oder eine schnell
durchzuführende Handlung auslöst. Vorzugsweise ist für jedes
Unterbrechungsbehandlungs-Programm zusätzlich eine maximale
Notreaktionszeit vorgegeben. Der Standardwert-Ermittlungs-
Teilprozeß wird so ausgelegt, daß er innerhalb der maximalen
Notreaktionszeit ausgeführt werden kann. Weiterhin sind
bevorzugt für jedes Unterbrechungsbehandlungs-Programm eine
minimale Wiederholzeit oder eine maximale Wiederholfrequenz
vorgegeben. Die minimale Wiederholzeit ist der reziproke Wert
der maximalen Wiederholfrequenz.
Bevorzugt wird vorab die im folgenden beschriebene Prüfung
durchgeführt. Seien UBP_1, . . ., UBP_M die M vordefinierten
Unterbrechungsbehandlungs-Programme. Seien NRZ(UBP_i) und
WZ(UBP_i) die maximale Notreaktionszeit bzw. die minimale
Wiederholzeit von UBP_i (i = 1, . . ., N). Diese Zeiten werden
vorzugsweise als Vielfache einer vorgegebenen Bezugs-
Zeiteinheit, z. B. des Reziproken des Prozessor- oder
Systemtakts, angegeben. Dann darf
NRZ(UBP_1)/WZ(UBP_1) + . . . + NRZ(UBP_N)/WZ(UBP_N)
eine vorgegebene obere Schranke nicht übersteigen. Oft hat
diese Schranke den Wert T.ln 2, ln bezeichnet hierbei den
natürlichen Logarithmus. T bezeichnet hierbei vorzugsweise die
gesamte verfügbare Rechenzeit des Prozessors. Möglich ist auch,
T selber als obere Schranke zu verwenden.
Jedem Unterbrechungssignal-Typ ist eine von N verschiedenen
Prioritäten zugeordnet, wobei N <= M ebenfalls eine natürliche
Zahl ist. Damit hat auch jedes Unterbrechungsbehandlungs-
Programm eine von N Prioritäten. Vorzugsweise hängt die
zugeordnete Priorität von der Bedeutung des
Unterbrechungsbehandlungs-Programms und der maximalen
Notreaktionszeit ab - je geringer die maximale
Notreaktionszeit, desto höher die Priorität.
In einer Fortbildung der Ausführungsform ist vorgesehen,
einzelnen Teilprozessen eines Unterbrechungsbehandlungs-
Programms unterschiedliche Prioritäten zuzuordnen. Notwendige
Teilprozesse erhalten z. B. die Priorität des
Unterbrechungssignals, weitere Teilprozesse eine niedrigere
Priorität.
Die Unterbrechungsbehandlungs-Programme werden erfindungsgemäß
in Teilprozesse unterteilt. Einer davon ist der Standardwert-
Ermittlungs-Teilprozeß. Die einzelnen Teilprozesse werden
bevorzugt so definiert, daß ihre Ausführung nicht durch
Unterbrechungssignale unterbrochen oder abgebrochen werden
kann.
Fig. 2. zeigt beispielhaft den Aufbau einer
Überwachungseinrichtung 30, die die Reaktionszeit von
Unterbrechungsbehandlungs-Programmen begrenzt. Die
Unterbrechungsbehandlungs-Programme werden von einem
Ausführungs-Prozessor 20 ausgeführt. Hierfür greift der
Ausführungs-Prozessor 20 lesend auf mindestens einen
Programmspeicher 50 für die Unterbrechungsbehandlungs-Programme
zu. Die Unterbrechungsbehandlungs-Programme sind wiederum
erfindungsgemäß in Teilprozesse unterteilt, die bevorzugt
jeweils nacheinander ausgeführt werden. Beispielsweise ist das
Quellprogramm für jeden Teilprozeß in einem separaten Programm-
Teilspeicher so abgespeichert, daß Teilprozesse nicht Programm-
Teilspeicher oder Datenspeicher anderer Teilprozesse
überschreiben können. Das Ergebnis jedes Teilprozesses
speichert der Ausführungs-Prozessor wie oben beschrieben in
einem Ergebnisspeicher 70 ab, der in Fig. 2. nicht gezeigt
wird.
Die erfindungsgemäße Einhaltung der vorgegebenen Reaktionszeit
wird durch eine Überwachungseinrichtung 30 überwacht. Diese
Überwachungseinrichtung 30 steuert weiterhin die zeitliche
Reihenfolge, in der die eintreffenden Unterbrechungssignale
abgearbeitet werden. Sie umfaßt bevorzugt einen
Unterbrechungssignal-Prozessor 100 (Interrupt Request
Controller), einen Speicher 110 für Unterbrechungssignale, M
Sperr-Zeitglieder 130 und M Reaktionszeit-Zeitglieder 140. Alle
2.M Zeitglieder sind mit dem Unterbrechungssignal-Prozessor 100
verbunden; in Fig. 2. ist nur die Verbindung zwischen dem
Unterbrechungssignal-Prozessor 100 und zwei Zeitgliedern
gezeigt.
Für jeden der M Unterbrechungssignal-Typen sind je ein Sperr-
Zeitglied 130 und ein Reaktionszeit-Zeitglied 140 vorgesehen.
Bevorzugt arbeiten diese 2.M Zeitglieder so wie oben
beschrieben. Bis zu 2.M verschiedene Zeitspannen können
vorgegeben sein und durch bloße Änderung eines Zeitgliedes
verändert werden.
Das Sperr-Zeitglied 130.i für den Unterbrechungssignal-Typ i
sperrt die Ausführung eines Unterbrechungssignals des Typs i
für eine vordefinierte Sperrzeit und stellt damit sicher, daß
zwei Unterbrechungssignale gleichen Typs höchstens mit einer
vorgegebenen Wiederholfrequenz abgearbeitet werden, aber nicht
häufiger. Anders formuliert: Sichergestellt wird, daß zwischen
zwei Aufrufen des Unterbrechungsbehandlungs-Programms für den
Typ i mindestens eine vorgegebene Wiederholungszeit als
Sperrzeit verstreicht. Der reziproke Wert ist die maximale
Wiederholfrequenz. Während dieser Zeitspanne ist das Sperr-
Zeitglied 130.i entweder im Zustand "sperren_speichern" oder im
Zustand "sperren_ignorieren", ansonsten im Zustand
"durchlassen". Die drei Zustände werden beispielsweise mit
Hilfe eines Zählers und eines zusätzlichen 1-Bit-Registers
realisiert. Der Zähler wird bei Überführung in einen der
Zustände "sperren_speichern" oder "sperren_ignorieren" auf
einen vordefinierten Wert größer 0 gesetzt und wird in einem
durch eine Systemuhr 200 vorgegebenen Systemtakt jeweils um 1
verringert. Wenn der Zähler den Wert 0 annimmt, ist das Sperr-
Zeitglied 130.i im Zustand "durchlassen". Durch das 1-Bit-
Register werden die Zustände "sperren_speichern" oder
"sperren_ignorieren" unterschieden.
Das Reaktionszeit-Zeitglied 140.i für den Unterbrechungssignal-
Typ i begrenzt die Latenzzeit zuzüglich der Ausführungszeit
eines Unterbrechungssignals des Typs i auf eine vordefinierte
maximale Reaktionszeit. Wenn der Ausführungs-Prozessor 20 das
dem Typ i zugeordnete Unterbrechungsbehandlungs-Programm
ausführt und die vorgegebene Zeitspanne für die Reaktionszeit
noch nicht verstrichen ist, ist das Reaktionszeit-Zeitglied
140.i in Zustand "aktiv", ansonsten im Zustand "inaktiv".
Weiterhin umfaßt der Unterbrechungssignal-Prozessor 100
bevorzugt einen Prioritäts-Speicher 120, in dem die höchste
Priorität aller Unterbrechungsbehandlungs-Programme, die der
Ausführungs-Prozessor 20 aktuell ausführt, abgespeichert ist.
Wenn ein Unterbrechungssignal z. B. an einer Schnittstelle 80
zum Datenbus eintrifft, identifiziert der Unterbrechungssignal-
Prozessor 100 den Typ dieses Unterbrechungssignals und die dem
Typ zugeordnete Priorität und führt mindestens einen der
folgenden Schritte durch:
- - Er leitet das Unterbrechungssignal an den Ausführungs- Prozessor 20 weiter.
- - Er unterbricht Unterbrechungsbehandlungs-Programme, die der Ausführungs-Prozessor 20 gerade ausführt.
- - Er speichert die Kennung und den Eintreffens-Zeitpunkt des Unterbrechungssignals in dem Unterbrechungssignal-Speicher 110 ab.
- - Er ignoriert das Unterbrechungssignal.
Welchen oder welche dieser vier Schritte der
Unterbrechungssignal-Prozessor 100 durchführt, hängt von der
Priorität des Unterbrechungssignals und von den aktuellen
Zuständen der beiden Zeitglieder, die für den
Unterbrechungssignal-Typ vorgesehen sind, ab.
Seien i der Typ des Unterbrechungssignals und j die dem Typ i
zugeordnete Priorität. Folgende Fallunterscheidungen nimmt der
Unterbrechungssignal-Prozessor 100 vor:
- - Wenn das Sperr-Zeitglied 130.i für den Typ i sich im Zustand "sperren_ignorieren" befindet, ignoriert er das Unterbrechungssignal.
- - Wenn das Sperr-Zeitglied 130.i für den Typ i sich im Zustand "sperren_speichern" befindet, speichert er den durch die Kennung gekennzeichneten Typ i und den Eintreffens-Zeitpunkt des Unterbrechungssignals im Unterbrechungssignal-Speicher 110 ab.
- - Wenn das Sperr-Zeitglied 130.i für den Typ i sich im Zustand "durchlassen" befindet, stellt der Unterbrechungssignal- Prozessor 100 durch Lesezugriff auf den Prioritäts-Speicher 120 fest, ob der Ausführungs-Prozessor 20 aktuell ein Unterbrechungsbehandlungs-Programm ausführt, das eine Priorität besitzt, die höher oder gleich die des Typs i ist. Ist dies der Fall, speichert er wiederum Kennung und Eintreffens-Zeitpunkt im Unterbrechungssignal-Speicher 110 ab. Ansonsten leitet er das Unterbrechungssignal an den Ausführungs-Prozessor 20 weiter. Dieser führt das zugeordnete Unterbrechungsbehandlungs-Programm für den Typ i aus.
- - Falls der Unterbrechungssignal-Prozessor 100 das Unterbrechungssignal weiterleitet, veranlaßt er gleichzeitig, daß der Ausführungs-Prozessor 20 alle Unterbrechungsbehandlungs-Programme mit einer niedrigeren Priorität unterbricht und zuerst das für den Typ i ausführt.
Diese Ausführung führt dazu, daß ein Unterbrechungssignal mit
der Priorität j stets vor einem mit einer Priorität k (k < j)
bevorzugt behandelt wird. Zwei Unterbrechungssignale gleicher
Priorität werden in der zeitlichen Reihenfolge ihres
Eintreffens behandelt.
Der Unterbrechungssignal-Prozessor 100 aktualisiert bei Bedarf
weiterhin die beiden Zeitglieder für den Typ i und den
Prioritäts-Speicher 120.
Unmittelbar nach Eintreffen des Unterbrechungssignals vom Typ i
bringt er das Sperr-Zeitglied 130.i für den Typ i in den
Zustand "sperren_ignorieren". Das Sperr-Zeitglied 130.i beginnt
mit der Messung der vorgegebenen Sperrzeit. Der Ausführungs-
Prozessor 20 sendet dann, wenn er mit der Ausführung des
Unterbrechungsbehandlungs-Programms für den Typ i beginnt, ein
entsprechendes Signal an den Unterbrechungssignal-Prozessor
100. Dieser überführt daraufhin das Sperr-Zeitglied 130.i für
den Typ i vom Zustand "sperren_ignorieren" in den Zustand
"sperren_speichern". Nach Ablauf der vorgegebenen und durch das
Sperr-Zeitglied 130.i überwachten Sperrzeit wird es vom Zustand
"sperren_speichern" in den Zustand "durchlassen" überführt.
Läuft die Sperrzeit ab, bevor die Ausführung des
Unterbrechungsbehandlungs-Programms begonnen hat, so wird das
Sperr-Zeitglied 130.i vom Zustand "sperren_ignorieren" in den
Zustand "sperren_speichern" überführt und nach Beendigung des
Unterbrechungsbehandlungs-Programms in den Zustand
"durchlassen". Diese Ausgestaltung führt dazu, daß weitere
Unterbrechungssignale des Typs i in der Latenzzeit des
Unterbrechungsbehandlungs-Programms für den Typ i ignoriert und
in der Ausführungszeit abgespeichert werden.
Der Unterbrechungssignal-Prozessor 100 bringt weiterhin
unmittelbar nach Eintreffen des Unterbrechungssignals das
Reaktionszeit-Zeitglied 140.i in den Zustand "aktiv". Das
Reaktionszeit-Zeitglied 140.1 beginnt daraufhin mit der
Überwachung der Reaktionszeit. Falls der Ausführungs-Prozessor
20 innerhalb der vorgegebenen maximalen Reaktionszeit das
Unterbrechungsbehandlungs-Programm vollständig ausführt, sendet
er ein entsprechendes Signal an den Unterbrechungssignal-
Prozessor 100. Dieser überführt das Reaktionszeit-Zeitglied
140.i für den Typ i in den Modus "inaktiv". Falls das Zeitglied
registriert, daß die vorgegebene maximale Reaktionszeit
abgelaufen ist und es sich noch im Zustand "aktiv" befindet, so
sendet es ein entsprechendes Signal an den
Unterbrechungssignal-Prozessor 100. Dieser überführt es
daraufhin in den Zustand "inaktiv" und sendet ein
entsprechendes Signal an den Ausführungs-Prozessor 20. Der
Ausführungs-Prozessor 20 bricht daraufhin die Ausführung des
Unterbrechungsbehandlungs-Programms für den Typ i und beginnt
eine vordefinierte Unterbrechungsbehandlung nach Abbruch.
Bevorzugt greift der Ausführungs-Prozessor 20 hierfür lesend
auf einen Programmspeicher 150 für Abbruchbehandlungen zu.
Diese kann wie oben beschrieben daraus bestehen, einen
Vorzugswert zu ermitteln oder das Ergebnis des zuletzt
ausgeführten Teilprozesses, das im Ergebnisspeicher 70
abgespeichert ist, als Endergebnis des
Unterbrechungsbehandlungs-Programms für den Typ i zu verwenden.
Sobald der Unterbrechungssignal-Prozessor 100 registriert, daß
ein Unterbrechungsbehandlungs-Programm vollständig ausgeführt
wurde oder dessen maximale Reaktionszeit abgelaufen ist,
aktualisiert er den Prioritäts-Speicher 120 und wählt unter den
im Unterbrechungssignal-Speicher 110 abgespeicherten
Unterbrechungssignalen das mit der höchsten Priorität aus.
Unter mehreren mit gleicher Priorität wird das mit dem
frühesten Eintreffens-Zeitpunkt ausgewählt. Der Eintrag für das
ausgewählte Unterbrechungssignal wird aus dem
Unterbrechungssignal-Speicher 110 entfernt, und die oben
beschriebenen Entscheidungen und Arbeitsschritte werden für das
ausgewählte Unterbrechungssignal ausgeführt. Das
Unterbrechungssignal wird an den Ausführungs-Prozessor 20
weitergeleitet oder wieder in den Unterbrechungssignal-Speicher
110 abgespeichert. Letzteres kann insbesondere dann geschehen,
wenn ein Unterbrechungssignal höherer Priorität abgearbeitet
wird. Bei Bedarf werden weiterhin die Zustände der beiden
zugeordneten Zeitglieder aktualisiert.
Der Unterbrechungssignal-Prozessor 100 kann auf zwei
verschiedene Weisen konfiguriert werden: Falls die Ausführung
eines Unterbrechungsbehandlungs-Programms unterbrochen wird,
weil ein Unterbrechungssignal höherer Priorität bevorzugt
behandelt wird, so wird entweder das Reaktionszeit-Zeitglied
140.i angehalten, oder es läuft weiter. Im ersten Fall
verlängert sich die Reaktionszeit des
Unterbrechungsbehandlungs-Programms für die Dauer des weiteren
Unterbrechungsbehandlungs-Programms höherer Priorität, im
zweiten Fall nicht. Im ersten Fall unterbricht der
Unterbrechungssignal-Prozessor 100 die Arbeit des
Reaktionszeit-Zeitgliedes 140.i, im zweiten Fall nicht. Der
Wechsel zwischen diesen beiden Arbeitsweisen kann dadurch auf
einfache Weise realisiert werden.
10
Motorsteuergerät
20
Ausführungs-Prozessor
30
Überwachungseinrichtung
40
Programmspeicher für Berechnungsprogramme
41
Programm-Teilspeicher für den Startwert
42
Programm-Teilspeicher für einen Berechnungsschritt
50
Programmspeicher für Unterbrechungsbehandlungs-Programme
60
Reaktionszeit-Zeitglied
70
Ergebnisspeicher
71
erster Daten-Teilspeicher für aktuelles Ergebnis
72
zweiter Daten-Teilspeicher für voriges Endergebnis
80
Interner Datenspeicher
90
Schnittstelle zum Datenbus
100
Unterbrechungssignal-Prozessor
110
Speicher für Unterbrechungssignale
120
Prioritäts-Speicher
130
Sperr-Zeitglied
140
Reaktionszeit-Zeitglied
150
Programmspeicher für Abbruchbehandlungen
200
Systemuhr
Claims (21)
1. Verfahren zur Beschränkung der Reaktionszeit eines
Software-Prozesses auf eine vorgegebene maximale
Reaktionszeit, wobei
durch die Ausführung des Software-Prozesses ein Endergebnis erbracht wird
und die Ausführung des Software-Prozesses spätestens dann abgebrochen wird, wenn sie nach Ablauf der maximalen Reaktionszeit nicht beendet ist,
dadurch gekennzeichnet,
daß
die Ausführung des Software-Prozesses die Ausführung von Teilprozessen umfaßt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
und bei Abbruch der Ausführung des Software-Prozesses ein Teilprozeß ausgewählt und dessen Ergebnis als Endergebnis des Software-Prozesses verwendet wird.
durch die Ausführung des Software-Prozesses ein Endergebnis erbracht wird
und die Ausführung des Software-Prozesses spätestens dann abgebrochen wird, wenn sie nach Ablauf der maximalen Reaktionszeit nicht beendet ist,
dadurch gekennzeichnet,
daß
die Ausführung des Software-Prozesses die Ausführung von Teilprozessen umfaßt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
und bei Abbruch der Ausführung des Software-Prozesses ein Teilprozeß ausgewählt und dessen Ergebnis als Endergebnis des Software-Prozesses verwendet wird.
2. Verfahren nach Anspruch 1,
dadurch gekennzeichnet,
daß die Reaktionszeit des Software-Prozesses durch ein Bauteil überwacht wird,
das beim Auslösen des Software-Prozesses aktiviert wird.
daß die Reaktionszeit des Software-Prozesses durch ein Bauteil überwacht wird,
das beim Auslösen des Software-Prozesses aktiviert wird.
3. Verfahren nach Anspruch 1 oder Anspruch 2,
dadurch gekennzeichnet,
daß bei Abbruch nur diejenigen Teilprozesse auswählbar sind
die bei Abbruch der Ausführung des Software-Prozesses
vollständig ausgeführt sind.
4. Verfahren nach einem der Ansprüche 1 bis 3,
dadurch gekennzeichnet,
daß
die Teilprozesse nacheinander in einer bestimmten Reihenfolge ausgeführt werden
und nach einem Abbruch derjenige Teilprozeß ausgewählt wird, der als letzter vollständig ausgeführt wurde.
daß
die Teilprozesse nacheinander in einer bestimmten Reihenfolge ausgeführt werden
und nach einem Abbruch derjenige Teilprozeß ausgewählt wird, der als letzter vollständig ausgeführt wurde.
5. Verfahren nach Anspruch 4,
dadurch gekennzeichnet,
daß das Endergebnis iterativ durch den Software-Prozeß erbracht wird
und jeder Teilprozeß ein Näherungsergebnis für das Endergebnis erbringt.
daß das Endergebnis iterativ durch den Software-Prozeß erbracht wird
und jeder Teilprozeß ein Näherungsergebnis für das Endergebnis erbringt.
6. Verfahren nach Anspruch 4 oder Anspruch 5,
dadurch gekennzeichnet,
daß das Ergebnis jedes Teilprozesses abgespeichert wird,
wobei das Ergebnis eines Vorgänger-Teilprozesses durch das Ergebnis eines Nachfolger-Teilprozesses überschrieben wird.
daß das Ergebnis jedes Teilprozesses abgespeichert wird,
wobei das Ergebnis eines Vorgänger-Teilprozesses durch das Ergebnis eines Nachfolger-Teilprozesses überschrieben wird.
7. Verfahren nach einem der Ansprüche 1 bis 6,
dadurch gekennzeichnet,
daß mindestens einer der Teilprozesse ein Standardwert- Ermittlungs-Teilprozeß ist, durch den
ein Standardwert für das Endergebnis des Software- Prozesses ermittelt wird
oder eine Handlung ausgelöst wird.
daß mindestens einer der Teilprozesse ein Standardwert- Ermittlungs-Teilprozeß ist, durch den
ein Standardwert für das Endergebnis des Software- Prozesses ermittelt wird
oder eine Handlung ausgelöst wird.
8. Verfahren nach Anspruch 7,
dadurch gekennzeichnet,
daß bei Abbruch des Software-Prozesses der Standardwert-
Ermittlungs-Teilprozeß ausgewählt wird.
9. Verfahren nach Anspruch 7,
dadurch gekennzeichnet,
daß die Ausführung des Software-Prozesses mit der
Ausführung des Standardwert-Ermittlungs-Teilprozesses
beginnt.
10. Verfahren nach einem der Ansprüche 7 bis 9,
dadurch gekennzeichnet,
daß der Standardwert-Ermittlungs-Teilprozeß eine Reaktionszeit hat,
die nicht länger als eine vorgegebene maximale Notreaktionszeit ist.
daß der Standardwert-Ermittlungs-Teilprozeß eine Reaktionszeit hat,
die nicht länger als eine vorgegebene maximale Notreaktionszeit ist.
11. Verfahren nach Anspruch 10,
dadurch gekennzeichnet,
daß die Ausführung des Software-Prozesses spätestens dann abgebrochen wird,
wenn die maximale Reaktionszeit bis auf die maximale Notreaktionszeit verstrichen ist,
und der Standardwert-Ermittlungs-Teilprozeß nach Abbruch des Software-Prozesses ausgeführt wird.
daß die Ausführung des Software-Prozesses spätestens dann abgebrochen wird,
wenn die maximale Reaktionszeit bis auf die maximale Notreaktionszeit verstrichen ist,
und der Standardwert-Ermittlungs-Teilprozeß nach Abbruch des Software-Prozesses ausgeführt wird.
12. Verfahren nach einem der Ansprüche 1 bis 11,
dadurch gekennzeichnet,
daß der Software-Prozeß ein Unterbrechungsbehandlungs- Programm ist,
das durch ein Unterbrechungssignal ausgelöst wurde.
daß der Software-Prozeß ein Unterbrechungsbehandlungs- Programm ist,
das durch ein Unterbrechungssignal ausgelöst wurde.
13. Verfahren nach Anspruch 12,
dadurch gekennzeichnet,
daß nach einem ersten Auslösen des Unterbrechungsbehandlungs-Programms
ein erneutes Auslösen für eine vorgegebene Zeitspanne unterbunden wird.
daß nach einem ersten Auslösen des Unterbrechungsbehandlungs-Programms
ein erneutes Auslösen für eine vorgegebene Zeitspanne unterbunden wird.
14. Verfahren nach einem der Ansprüche 1 bis 13,
dadurch gekennzeichnet,
daß
der Software-Prozeß in einem Mehrprozessorsystem ausgeführt wird, das unterschiedliche Prioritäten für Software-Prozesse berücksichtigt,
dem Software-Prozeß eine Priorität zugeordnet ist,
ein Ereignis einen weiteren Software-Prozeß auslöst,
dem weiteren Software-Prozeß eine Priorität zugeordnet ist, die höher als die des Software-Prozesses ist,
und die Ausführung des Software-Prozesses nach Auftreten des auslösenden Ereignisses unterbrochen wird.
daß
der Software-Prozeß in einem Mehrprozessorsystem ausgeführt wird, das unterschiedliche Prioritäten für Software-Prozesse berücksichtigt,
dem Software-Prozeß eine Priorität zugeordnet ist,
ein Ereignis einen weiteren Software-Prozeß auslöst,
dem weiteren Software-Prozeß eine Priorität zugeordnet ist, die höher als die des Software-Prozesses ist,
und die Ausführung des Software-Prozesses nach Auftreten des auslösenden Ereignisses unterbrochen wird.
15. Verfahren nach Anspruch 14,
dadurch gekennzeichnet,
daß die Zeitspanne, während der die Ausführung des Software-Prozesses unterbrochen ist,
zu der Reaktionszeit des Software-Prozesses hinzugerechnet wird.
daß die Zeitspanne, während der die Ausführung des Software-Prozesses unterbrochen ist,
zu der Reaktionszeit des Software-Prozesses hinzugerechnet wird.
16. Verfahren nach Anspruch 14 oder Anspruch 15,
dadurch gekennzeichnet,
daß
der weitere Software-Prozeß ein Unterbrechungsbehandlungs-Programm
und das auslösende Ereignis ein Unterbrechungssignal
ist.
daß
der weitere Software-Prozeß ein Unterbrechungsbehandlungs-Programm
und das auslösende Ereignis ein Unterbrechungssignal
ist.
17. Vorrichtung zur Durchführung des Verfahrens nach einem der
Ansprüche 1 bis 16
mit einem Mittel zur Überwachung der Reaktionszeit des Software-Prozesses,
mit einem Mittel zur Ausführung von Teilprozessen,
mit einem Mittel zur Auswahl eines ausgeführten Teilprozesses
und mit einem Mittel zur Erbringung eines Ergebnisses des ausgewählten Teilprozesses.
mit einem Mittel zur Überwachung der Reaktionszeit des Software-Prozesses,
mit einem Mittel zur Ausführung von Teilprozessen,
mit einem Mittel zur Auswahl eines ausgeführten Teilprozesses
und mit einem Mittel zur Erbringung eines Ergebnisses des ausgewählten Teilprozesses.
18. Vorrichtung zur Ausführung eines Software-Prozesses, der
ein Endergebnis erbringt,
wobei die Vorrichtung
einen Prozessor (20) zum Ausführen des Software-Prozesses
und eine Überwachungseinrichtung (30) zur Überwachung der Reaktionszeit des Software-Prozesses
umfaßt
und wobei die Überwachungseinrichtung (30) mindestens dann die Ausführung des Software-Prozesses abbricht und die Ausführung eines Unterbrechungsbehandlungs-Programms auslöst,
wenn die Ausführung des Software-Prozesses nach Ablauf einer vorgegebenen maximalen Reaktionszeit nicht beendet ist,
dadurch gekennzeichnet,
daß
der Prozessor (20) bei der Ausführung des Software- Prozesses Teilprozesse ausführt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
das Unterbrechungsbehandlungs-Programm einen dieser Teilprozesse auswählt
und die Vorrichtung das Ergebnis des ausgewählten Teilprozesses als Endergebnis verwendet.
wobei die Vorrichtung
einen Prozessor (20) zum Ausführen des Software-Prozesses
und eine Überwachungseinrichtung (30) zur Überwachung der Reaktionszeit des Software-Prozesses
umfaßt
und wobei die Überwachungseinrichtung (30) mindestens dann die Ausführung des Software-Prozesses abbricht und die Ausführung eines Unterbrechungsbehandlungs-Programms auslöst,
wenn die Ausführung des Software-Prozesses nach Ablauf einer vorgegebenen maximalen Reaktionszeit nicht beendet ist,
dadurch gekennzeichnet,
daß
der Prozessor (20) bei der Ausführung des Software- Prozesses Teilprozesse ausführt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
das Unterbrechungsbehandlungs-Programm einen dieser Teilprozesse auswählt
und die Vorrichtung das Ergebnis des ausgewählten Teilprozesses als Endergebnis verwendet.
19. Vorrichtung nach Anspruch 18,
dadurch gekennzeichnet,
daß der Prozessor das Endergebnis iterativ erbringt
und jedes Ergebnis eines Teilprozesses ein Näherungsergebnis für das Endergebnis ist.
daß der Prozessor das Endergebnis iterativ erbringt
und jedes Ergebnis eines Teilprozesses ein Näherungsergebnis für das Endergebnis ist.
20. Vorrichtung nach Anspruch 19,
dadurch gekennzeichnet,
daß
die Vorrichtung einen Ergebnisspeicher (70) umfaßt,
der Prozessor das Ergebnis jedes Teilprozesses in diesen Ergebnisspeicher (70) abspeichert
und das Unterbrechungsbehandlungs-Programm den Inhalt dieses Ergebnisspeichers (70) ausliest.
daß
die Vorrichtung einen Ergebnisspeicher (70) umfaßt,
der Prozessor das Ergebnis jedes Teilprozesses in diesen Ergebnisspeicher (70) abspeichert
und das Unterbrechungsbehandlungs-Programm den Inhalt dieses Ergebnisspeichers (70) ausliest.
21. Vorrichtung nach einem der Ansprüche 18 bis 20,
dadurch gekennzeichnet,
daß die Überwachungseinrichtung (30) ein Zeitglied (60, 140) umfaßt,
das nach Verstreichen der maximalen Reaktionszeit ein Signal erzeugt.
daß die Überwachungseinrichtung (30) ein Zeitglied (60, 140) umfaßt,
das nach Verstreichen der maximalen Reaktionszeit ein Signal erzeugt.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10206865A DE10206865C1 (de) | 2002-02-18 | 2002-02-18 | Reaktionszeit-Beschränkung eines Software-Prozesses |
EP03739445A EP1514180A2 (de) | 2002-02-18 | 2003-01-24 | Reaktionszeit-beschränkung eines software-prozesses |
US10/504,931 US20050160425A1 (en) | 2002-02-18 | 2003-01-24 | Limitation of the response time of a software process |
PCT/EP2003/000721 WO2003069424A2 (de) | 2002-02-18 | 2003-01-24 | Reaktionszeit-beschränkung eines software-prozesses |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10206865A DE10206865C1 (de) | 2002-02-18 | 2002-02-18 | Reaktionszeit-Beschränkung eines Software-Prozesses |
Publications (1)
Publication Number | Publication Date |
---|---|
DE10206865C1 true DE10206865C1 (de) | 2003-05-15 |
Family
ID=7713860
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10206865A Expired - Fee Related DE10206865C1 (de) | 2002-02-18 | 2002-02-18 | Reaktionszeit-Beschränkung eines Software-Prozesses |
Country Status (4)
Country | Link |
---|---|
US (1) | US20050160425A1 (de) |
EP (1) | EP1514180A2 (de) |
DE (1) | DE10206865C1 (de) |
WO (1) | WO2003069424A2 (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005046072A1 (de) * | 2005-09-27 | 2006-09-21 | Daimlerchrysler Ag | Verfahren und Vorichtung zur Prozeßregelung |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7703073B2 (en) * | 2004-06-08 | 2010-04-20 | Covia Labs, Inc. | Device interoperability format rule set and method for assembling interoperability application package |
JP4541054B2 (ja) * | 2004-07-09 | 2010-09-08 | 株式会社リコー | レンズ鏡胴及び撮影装置 |
DE102004035097A1 (de) * | 2004-07-20 | 2006-02-09 | Endress + Hauser Gmbh + Co. Kg | Elektronisches Gerät und Verfahren zur Durchführung mehrerer Prozesse mit dem elektronischen Gerät |
FR2884628A1 (fr) * | 2005-04-18 | 2006-10-20 | St Microelectronics Sa | Procede de traitement d'interruptions non securisees par un processeur operant dans le mode securise, processeur associe. |
US8025034B2 (en) * | 2007-01-05 | 2011-09-27 | Ford Global Technologies, Llc | Interval phasing for valve timing |
US8019899B2 (en) * | 2008-08-28 | 2011-09-13 | Yahoo! Inc. | Delivering partially processed results based on system metrics in network content delivery systems |
GB2517493A (en) * | 2013-08-23 | 2015-02-25 | Advanced Risc Mach Ltd | Handling access attributes for data accesses |
US10013280B2 (en) * | 2013-09-30 | 2018-07-03 | Dell Products, Lp | System and method for host-assisted background media scan (BMS) |
GB2522477B (en) * | 2014-01-28 | 2020-06-17 | Advanced Risc Mach Ltd | Speculative interrupt signalling |
WO2021111554A1 (ja) * | 2019-12-04 | 2021-06-10 | 三菱電機株式会社 | 車両制御装置 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3243760C2 (de) * | 1982-11-26 | 1989-04-27 | Brown, Boveri & Cie Ag, 6800 Mannheim | Einrichtung zur Funktionsüberwachung eines Prozessors |
US5257357A (en) * | 1991-01-22 | 1993-10-26 | Motorola, Inc. | Method and apparatus for implementing a priority adjustment of an interrupt in a data processor |
DE4329872A1 (de) * | 1993-09-03 | 1995-03-09 | Siemens Ag | Überwachungsschaltung für Mikroprozessoren |
EP0717361A2 (de) * | 1994-12-16 | 1996-06-19 | International Business Machines Corporation | System zur Verkürzung der Latenz von Echtzeitunterbrechungen |
DE3544079C2 (de) * | 1985-12-13 | 1998-07-30 | Bosch Gmbh Robert | Verfahren zur Verarbeitung von Interrupt-Signalen |
US6085218A (en) * | 1991-09-26 | 2000-07-04 | International Business Machines Corporation | Monitoring processor execution cycles to prevent task overrun in multi-task, hard, real-time system |
DE19927657A1 (de) * | 1999-06-17 | 2001-01-04 | Daimler Chrysler Ag | Partitionierung und Überwachung von softwaregesteuerten Systemen |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4894846A (en) * | 1988-06-30 | 1990-01-16 | Digital Equipment Corporation | Method for maintaining a correct time in a distributed processing system |
US6182203B1 (en) * | 1997-01-24 | 2001-01-30 | Texas Instruments Incorporated | Microprocessor |
US6081665A (en) * | 1997-12-19 | 2000-06-27 | Newmonics Inc. | Method for efficient soft real-time execution of portable byte code computer programs |
FI108478B (fi) * | 1998-01-21 | 2002-01-31 | Nokia Corp | Sulautettu jõrjestelmõ |
EP1243987B1 (de) * | 2001-03-19 | 2011-10-05 | Siemens Enterprise Communications GmbH & Co. KG | Verfahren und Anordnung zur Steuerung der Ausführung von Teilaufgaben eines Prozesses |
-
2002
- 2002-02-18 DE DE10206865A patent/DE10206865C1/de not_active Expired - Fee Related
-
2003
- 2003-01-24 WO PCT/EP2003/000721 patent/WO2003069424A2/de not_active Application Discontinuation
- 2003-01-24 US US10/504,931 patent/US20050160425A1/en not_active Abandoned
- 2003-01-24 EP EP03739445A patent/EP1514180A2/de not_active Withdrawn
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3243760C2 (de) * | 1982-11-26 | 1989-04-27 | Brown, Boveri & Cie Ag, 6800 Mannheim | Einrichtung zur Funktionsüberwachung eines Prozessors |
DE3544079C2 (de) * | 1985-12-13 | 1998-07-30 | Bosch Gmbh Robert | Verfahren zur Verarbeitung von Interrupt-Signalen |
US5257357A (en) * | 1991-01-22 | 1993-10-26 | Motorola, Inc. | Method and apparatus for implementing a priority adjustment of an interrupt in a data processor |
US6085218A (en) * | 1991-09-26 | 2000-07-04 | International Business Machines Corporation | Monitoring processor execution cycles to prevent task overrun in multi-task, hard, real-time system |
DE4329872A1 (de) * | 1993-09-03 | 1995-03-09 | Siemens Ag | Überwachungsschaltung für Mikroprozessoren |
EP0717361A2 (de) * | 1994-12-16 | 1996-06-19 | International Business Machines Corporation | System zur Verkürzung der Latenz von Echtzeitunterbrechungen |
DE19927657A1 (de) * | 1999-06-17 | 2001-01-04 | Daimler Chrysler Ag | Partitionierung und Überwachung von softwaregesteuerten Systemen |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005046072A1 (de) * | 2005-09-27 | 2006-09-21 | Daimlerchrysler Ag | Verfahren und Vorichtung zur Prozeßregelung |
DE102005046072B4 (de) * | 2005-09-27 | 2009-04-02 | Daimler Ag | Verfahren und Vorichtung zur Prozeßregelung |
Also Published As
Publication number | Publication date |
---|---|
WO2003069424A2 (de) | 2003-08-21 |
EP1514180A2 (de) | 2005-03-16 |
WO2003069424A3 (de) | 2004-12-29 |
US20050160425A1 (en) | 2005-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10231668B4 (de) | Multitaskingbetriebssystem zur Verringerung des Stromverbrauchs und elektronische Steuerung im Fahrzeug, die selbiges benutzt | |
DE60008267T2 (de) | Verfahren zum planen von zeitverteilten anwendungen in einem rechnerbetriebssystem | |
EP0635784B1 (de) | Multiprozessorsystem | |
DE60226176T2 (de) | Verfahren und programme zur einstellung von prioritätsstufen in einem datenverarbeitungssystem mit multiprogrammierung und priorisierte warteschlangenbildung | |
EP0655682B1 (de) | Recheneinheit mit mehreren ausführbaren Tasks | |
DE19648422C2 (de) | Verfahren und Vorrichtung zum Implementieren eines echtzeitfähigen Steuerprogramms in einem nicht-echtzeitfähigen Betriebsprogramm | |
EP2504738B1 (de) | Parallelisierte programmsteuerung | |
DE10206865C1 (de) | Reaktionszeit-Beschränkung eines Software-Prozesses | |
DE102005048037A1 (de) | Verfahren zur Steuerung/Regelung wenigstens einer Task | |
DE69908682T2 (de) | Prozessor mit Echtzeit-Ablaufsteuerung zur Fehlerbeseitigung ohne Fehlerbeseitigungsmonitor | |
DE4227345A1 (de) | Cachescheduler | |
EP1831786A1 (de) | Verfahren zur verteilung von rechenzeit in einem rechnersystem | |
DE102007051803A1 (de) | Verfahren und Vorrichtung zur Datenverarbeitung | |
EP0799441B1 (de) | Verfahren zur steuerung von technischen vorgängen | |
DE102013022564B4 (de) | Aufrechterhalten der Bandbreiten-Servicequalität einer Hardware-Ressource über einen Hardware-Zähler | |
DE102015100566A1 (de) | Verfahren und leichter Mechanismus für gemischte kritische Anwendungen | |
DE3831048A1 (de) | Betriebsprogramm fuer eine datenverarbeitungsanlage | |
EP1220065B1 (de) | Verfahren zum Betrieb einer industriellen Steuerung mit Run-Time-System | |
WO2021249616A1 (de) | Verfahren zum konfigurieren von komponenten in einem system mit hilfe von multi-agent reinforcement learning, computerlesbares speichermedium und system | |
EP4293437A1 (de) | Verfahren und vorrichtung zum steuern des ablaufs von programmteilen, programmierverfahren, programmiervorrichtung | |
EP2126700B1 (de) | Steuerung des laufzeitverhaltens von prozessen | |
EP0584512A1 (de) | Verfahren zum zeitlichen Überwachen einer Programmabarbeitung | |
DE112018003505T5 (de) | Zugriffssteuereinrichtung | |
DE60211703T2 (de) | Verfahren und system zur zeitverwaltung in einem echtzeitsystem | |
DE10360319B3 (de) | Verfahren zum Steuern der Auslastung einer Datenverarbeitungsanlage |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE |
|
8327 | Change in the person/name/address of the patent owner |
Owner name: DAIMLER AG, 70327 STUTTGART, DE |
|
8320 | Willingness to grant licences declared (paragraph 23) | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20140902 |