DE10206865C1 - Reaktionszeit-Beschränkung eines Software-Prozesses - Google Patents

Reaktionszeit-Beschränkung eines Software-Prozesses

Info

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
Application number
DE10206865A
Other languages
English (en)
Inventor
Rainer Falsett
Reinhard Seyer
Christian Siemers
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Priority to DE10206865A priority Critical patent/DE10206865C1/de
Priority to EP03739445A priority patent/EP1514180A2/de
Priority to US10/504,931 priority patent/US20050160425A1/en
Priority to PCT/EP2003/000721 priority patent/WO2003069424A2/de
Application granted granted Critical
Publication of DE10206865C1 publication Critical patent/DE10206865C1/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4812Task transfer initiation or dispatching by interrupt, e.g. masked
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0706Error 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/0715Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording 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/3409Recording 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/3419Recording 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording 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/3466Performance evaluation by tracing or monitoring
    • G06F11/348Circuit details, i.e. tracer hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0706Error 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/0736Error 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/0739Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0793Remedial 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.
Bezugszeichenliste
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
DE10206865A 2002-02-18 2002-02-18 Reaktionszeit-Beschränkung eines Software-Prozesses Expired - Fee Related DE10206865C1 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (7)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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