DE102004046288A1 - Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem - Google Patents

Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem Download PDF

Info

Publication number
DE102004046288A1
DE102004046288A1 DE102004046288A DE102004046288A DE102004046288A1 DE 102004046288 A1 DE102004046288 A1 DE 102004046288A1 DE 102004046288 A DE102004046288 A DE 102004046288A DE 102004046288 A DE102004046288 A DE 102004046288A DE 102004046288 A1 DE102004046288 A1 DE 102004046288A1
Authority
DE
Germany
Prior art keywords
error
computer system
runtime object
error handling
computer program
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.)
Withdrawn
Application number
DE102004046288A
Other languages
English (en)
Inventor
Wolfgang Pfeiffer
Reinhard Weiberle
Bernd Müller
Florian Hartwich
Werner Harter
Ralf Angerbauer
Eberhard Boehl
Thomas Kottke
Yorck Von Collani
Rainer Gmehlich
Karsten Graebitz
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102004046288A priority Critical patent/DE102004046288A1/de
Priority to PCT/EP2005/054038 priority patent/WO2006032585A1/de
Priority to US11/662,429 priority patent/US20080133975A1/en
Priority to CNA200580032256XA priority patent/CN101027646A/zh
Priority to JP2007532872A priority patent/JP2008513899A/ja
Priority to EP05787147A priority patent/EP1805617A1/de
Publication of DE102004046288A1 publication Critical patent/DE102004046288A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/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/0721Error 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 within a central processing unit [CPU]
    • G06F11/0724Error 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 within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • 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
    • 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/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1629Error detection by comparing the output of redundant processing systems
    • G06F11/1641Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Um die bei der Abarbeitung eines Computerprogramms auf einem Computersystem (1) auftretenden Fehler möglichst flexibel zu behandeln und dabei eine möglichst hohe Verfügbarkeit des Computersystems zu gewährleisten, wird vorgeschlagen, dass dem bei einem auftretenden Fehler von einer Fehlererkennungseinheit (5) erzeugten Fehlerbehandlungssignal eine Kennung zugeordnet ist, in Abhängigkeit von der Kennung eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen ausgewählt wird und die ausgewählte Fehlerbehandlungsroutine ausgeführt wird.

Description

  • Die Erfindung betrifft ein Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem, das mindestens eine Recheneinheit umfasst. Das Computerprogramm umfasst mindestens ein Laufzeitobjekt. Ein während der Ausführung des Laufzeitobjekts auftretender Fehler wird durch eine Fehlererkennungseinheit erkannt. Bei einem erkannten Fehler erzeugt die Fehlererkennungseinheit ein Fehlererkennungssignal.
  • Die Erfindung betrifft auch ein Computersystem, auf dem ein Computerprogramm ausführbar ist. Das Computerprogramm umfasst mindestens ein Laufzeitobjekt. Ein während der Ausführung des Laufzeitobjekts auf dem Computersystem auftretender Fehler ist durch eine Fehlererkennungseinheit erkennbar.
  • Die Erfindung betrifft auch eine Fehlererkennungseinheit in einem Computersystem, das mindestens eine Hardwarekomponente aufweist und auf dem mindestens ein Laufzeitobjekt ablauffähig ist, wobei die Fehlererkennungseinheit während der Ausführung eines Laufzeitobjekts auftretende Fehler erkennt.
  • Die Erfindung betrifft ferner ein Computerprogramm, das auf einem Computersystem ablauffähig ist, sowie einen maschinenlesbaren Datenträger, auf dem ein Computerprogramm abgespeichert ist.
  • Stand der Technik
  • Bei der Abarbeitung eines Computerprogramms auf einem Computer können Fehler auftreten. Fehler können danach unterschieden werden, ob sie durch die Hardware (Prozessor, Bussysteme, Peripheriegeräte, etc.) oder durch die Software (Anwendungsprogramme, Betriebssysteme, BIOS, etc.) bedingt sind.
  • Bei auftretenden Fehlern wird ferner zwischen permanenten Fehlern und transienten Fehlern unterschieden. Permanente Fehler sind stets vorhanden und beruhen beispielsweise auf einer fehlerhaften Hardware oder einer fehlerhaft programmierten Software. Transiente Fehler treten im Gegensatz hierzu nur temporär auf und sind damit auch deutlich schwieriger reproduzierbar und vorhersagbar. Bei binär abgespeicherten, binär übertragenen und/oder binär verarbeiteten Daten treten transiente Fehler beispielsweise dadurch auf, dass durch elektromagnetische Einflüsse oder Strahlung (Alpha-Strahlung, Neutronen-Strahlung) einzelne Bits verändert werden.
  • Üblicherweise wird ein Computerprogramm in mehrere Laufzeitobjekte unterteilt, die sequentiell oder parallel auf dem Computersystem ausgeführt werden. Laufzeitobjekte sind beispielsweise Prozesse, Tasks oder Threads. Während der Ausführung des Computerprogramms auftretende Fehler können damit prinzipiell dem ausgeführten Laufzeitobjekt zugeordnet werden.
  • Eine Behandlung von permanenten Fehlern basiert typischerweise auf der Abschaltung des Computersystems oder zumindest der Abschaltung einzelner Hardwarekomponenten bzw. Teilsystemen. Dies hat jedoch den Nachteil, dass damit die Funktionalität des Computersystems oder des Teilsystems nicht mehr zur Verfügung steht. Um einen sicheren Betrieb insbesondere in einer sicherheitsrelevanten Umgebung dennoch gewährleisten zu können, sind die Teilsysteme eines Computersystems beispielsweise redundant ausgelegt.
  • Häufig werden auch transiente Fehler durch eine Abschaltung von Teilsystemen behandelt. Es ist außerdem bekannt, bei aufgetretenen transienten Fehlern ein oder mehrere Teilsysteme abzuschalten und erneut zu starten und beispielsweise durch einen Selbsttest auf eine nun fehlerfreie Abarbeitung des Computerprogramms zu schließen. Wird kein neuer Fehler erkannt, setzt das Teilsystem seine Arbeit fort. Hierbei ist es möglich, dass die durch den Fehler unterbrochene Aufgabe bzw. das zu dieser Zeit abgearbeitete Laufzeitobjekt nicht weiter ausgeführt wird (sogenanntes Forward-Recovery). Forward-Recovery wird beispielsweise bei echtzeitfähigen Systemen angewandt.
  • Insbesondere bei nicht-echtzeitfähigen Anwendungen ist es bekannt, an vorgebbaren Stellen eines Computerprogramms bzw. Laufzeitobjekts Checkpunkte zu setzen. Tritt ein transienter Fehler auf und wird infolgedessen das Teilsystem neu gestartet, wird die Aufgabe bei dem zuletzt bearbeiteten Checkpunkt wieder aufgenommen. Ein derartiges als Backward-Recovery bezeichnetes Verfahren wird beispielsweise auf Computersystemen verwendet, die zur Durchführung von Transaktionen an Finanzmärkten eingesetzt werden.
  • Die bekannten Verfahren zur Behandlung aufgetretener transienter Fehler haben den Nachteil, dass das gesamte Computersystem, zumindest jedoch Teilsysteme zeitweise nicht verfügbar sind, was zu einer Verzögerung der Abarbeitung des Computerprogramms und zu Datenverlust führen kann.
  • Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, einen bei der Abarbeitung eines Computerprogramms auf einem Computersystem auftretenden Fehler möglichst flexibel zu behandeln und dabei eine möglichst hohe Verfügbarkeit des Computersystems zu gewährleisten.
  • Zur Lösung dieser Aufgabe wird ausgehend von dem Verfahren der eingangs genannten Art vorgeschlagen, dass dem bei einem auftretenden Fehler erzeugten Fehlerbehandlungssignal eine Kennung zugeordnet ist, in Abhängigkeit von der Kennung eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen ausgewählt wird und die ausgewählte Fehlerbehandlungsroutine ausgeführt wird.
  • Vorteile der Erfindung
  • Erfindungsgemäß wird jedem Fehlererkennungssignal, das eine Fehlerbehandlung initiieren kann, eine Kennung zugewiesen. Diese Kennung zeigt an, welche der vorgegebenen Fehlerbehandlungsmechanismen zu verwenden ist. Damit ist es möglich, für einen auftretenden Fehler die jeweils optimale Fehlerbehandlungsroutine auszuwählen, so dass eine maximale Verfügbarkeit des Computersystems aufrecht erhalten werden kann.
  • Ein Fehlererkennungssignal kann eine Fehlerbehandlung beispielsweise in Form eines sogenannten Interrupt initiieren. Mittels des Interrupt wird einer die Abarbeitung des Computerprogramms überwachenden Einheit des Computersystems mitgeteilt, dass ein Fehler vorliegt. Die überwachende Einheit kann dann die Durchführung einer Fehlerbehandlung veranlassen. Erfindungsgemäß stehen zur Durchführung der Fehlerbehandlung mehrere Fehlerbehandlungsroutinen zur Verfügung. In Abhängigkeit von einer dem Fehlererkennungssignal zugeordneten Kennung wird eine Fehlerroutine ausgewählt und ausgeführt. Dies ermöglicht eine besonders flexible Auswahl einer Fehlerbehandlungsroutine. Insbesondere kann stets die Fehlerbehandlungsroutine ausgewählt werden, die eine maximale Verfügbarkeit des Computersystems ermöglicht.
  • Das Fehlererkennungssignal kann ein internes Signal sein. Umfasst das Computersystem beispielsweise mehrere Recheneinheiten und wird das Laufzeitobjekt auf mindestens zwei der Recheneinheiten parallel ausgeführt, so kann von der Fehlererkennungseinheit ein Vergleich der parallel erzeugten Ergebnisse der mindestens zwei Recheneinheiten durchgeführt werden. Die Fehlererkennungseinheit erzeugt dann ein Fehlerbehandlungssignal, wenn die Ergebnisse nicht übereinstimmen. Wird das Laufzeitobjekt auf mehr als zwei der Recheneinheiten redundant ausgeführt und weisen die Mehrzahl der Ausführungen des Laufzeitobjekts keinen Fehler auf, so kann es zweckmäßig sein, die Ausführung des Computerprogramms fortzusetzen und die fehlerhafte Ausführung des Laufzeitobjekts zu ignorieren. Dazu wird dem von der Fehlererkennungseinheit erzeugten Fehlererkennungssignal eine Kennung zugeordnet, die das Computersystem veranlasst, eine Fehlerbehandlungsroutine auszuwählen, mittels derer die oben beschriebene Fehlerbehandlung möglich ist.
  • Vorzugsweise ist das Fehlerbehandlungssignal ein externes Signal. Ein externes Fehlererkennungssignal kann beispielsweise von einer einem Kommunikationssystem (z.B. einem Bussystem) zugeordneten Fehlererkennungseinheit erzeugt werden. In diesem Falle kann die Fehlererkennungseinheit das Vorhandensein eines Übertragungsfehlers oder einen Defekt des Kommunikationssystems feststellen und dem erzeugten Fehlererkennungssignal eine den erkannten Fehler kennzeichnende Kennung beifügen bzw. ein die Kennung enthaltendes Fehlererkennungssignal erzeugen. Ein externes Fehlererkennungssignal kann beispielsweise auch von einem Speicherelement erzeugt werden und einen sogenannten Parity-Fehler beschreiben. Je nach Art des Fehlers und nach der Herkunft des externen Fehlererkennungssignals kann dem Fehlererkennungssignal eine andere Kennung zugeordnet sein. Da die Auswahl der Fehlerbehandlungsroutine in Abhängigkeit von der dem Fehlererkennungssignal zugeordneten Kennung erfolgt, kann eine Fehlerbehandlung besonders flexibel durchgeführt werden. Insbesondere kann bereits bei der Programmierung bzw. bei der Installation einer neuen Softwarekomponente oder einer neuen Hardwarekomponente festgelegt werden, wie das Computersystem bestimmte Fehler behandeln soll.
  • Gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird mindestens eine das Laufzeitobjekt und/oder die Ausführung des Laufzeitobjekts charakterisierende Größe erfasst. Das Fehlerbehandlungssignal wird dann in Abhängigkeit der erfassten Größe erzeugt. Eine derartige Größe kann beispielsweise eine dem Laufzeitobjekt zugeordnete Priorität sein. Damit ist es möglich, eine Fehlerbehandlung zusätzlich in Abhängigkeit zu der Priorität des ausgeführten Laufzeitobjekts durchzuführen.
  • Vorteilhafterweise beschreibt die erfasste Größe eine noch zur Verfügung stehende Zeitdauer bis zu einem vorgegebenen Ereignis. Ein derartiges Ereignis kann beispielsweise ein durch einen Scheduler vorzunehmender Wechsel des abzuarbeitenden Laufzeitobjekts sein oder die noch zur Verfügung stehende Zeitdauer, bis durch das Laufzeitobjekt berechnete Daten einem anderen Laufzeitobjekt bereitgestellt werden müssen.
  • Eine die Ausführung des Laufzeitobjekts charakterisierende Größe kann auch die bereits erfolgte bezeichnen. Tritt beispielsweise der Fehler kurz nach dem Laden des Laufzeitobjekts auf, kann vorgesehen sein, das gesamte Laufzeitobjekt nochmals zu laden und auszuführen. Steht das Laufzeitobjekt jedoch bereits kurz vor Ende der zur Verfügung stehenden Abarbeitungszeit, beziehungsweise soll ein anderes Laufzeitobjekt dringend abgearbeitet werden, kann vorgesehen sein, dass Laufzeitobjekt, während dessen Abarbeitung der Fehler auftrat, einfach zu beenden.
  • Die die Abarbeitung des Laufzeitobjekts charakterisierende Größe kann ferner beschreiben, ob bereits ein Datenaustausch mit anderen Laufzeitobjekten, ob eine Übertragung von Daten über eines oder mehrere Kommunikationssystem oder ob ein Speicherzugriff erfolgt ist. Die erfasste Größe kann sich dann in der mittels des Fehlererkennungssignals übertragenen Kennung widerspiegeln und kann somit bei der Auswahl der Fehlerbehandlungsroutine berücksichtigt werden.
  • Vorteilhafterweise wird das erfindungsgemäße Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, oder in einem sicherheitsrelevanten System, beispielsweise bei einer Steuerung eines Flugzeugs, eingesetzt. In einem Kraftfahrzeug bzw. in einem sicherheitsrelevanten System ist es besonders wichtig, dass auftretende Fehler flexibel behandelt werden können und somit das Computersystem besonders sicher arbeitet und hochverfügbar ist.
  • Gemäß einer bevorzugten Ausführungsform des Verfahrens realisiert mindestens eine der Fehlerbehandlungsroutinen in der vorgebbaren Menge von Fehlerbehandlungsroutinen eine der folgenden Fehlerbehandlungsmöglichkeiten:
    • – Durchführen keiner Operation: Ein aufgetretener Fehler wird ignoriert.
    • – Abbruch der Ausführung des Laufzeitobjekts: Die Ausführung des Laufzeitobjekts wird abgebrochen und beispielsweise stattdessen ein anderes Laufzeitobjekt ausgeführt.
    • – Abbruch der Ausführung des Laufzeitobjekts und Verbot einer neuen Aktivierung des Laufzeitobjekts: Das Laufzeitobjekt, während dessen Ausführung der Fehler auftrat, wird folglich nicht wieder ausgeführt.
    • – Wiederholung der Ausführung des Laufzeitobjekts.
    • – Backward-Recovery: Während der Ausführung des Laufzeitobjekts werden Checkpunkte gesetzt und bei Auftreten eines Fehlers wird zu dem letzten Checkpunkt zurückgesprungen.
    • – Forward-Recovery: Die Ausführung des Laufzeitobjekts wird unterbrochen und an einem anderen, nachfolgenden Punkt wieder fortgesetzt.
    • – Reset: Das gesamte Computersystem oder ein Teilsystem werden neu gestartet.
  • Diese Fehlerbehandlungsroutinen ermöglichen eine besonders flexible Behandlung auftretender Fehler.
  • Vorzugsweise wird das erfindungsgemäße Verfahren zur Behandlung transienter Fehler eingesetzt. Vorteilhafterweise jedoch wird die Auswahl der Fehlerbehandlungsroutine in Abhängigkeit davon durchgeführt, ob der erkannte Fehler ein transienter Fehler oder ein permanenter Fehler ist.
  • Ein erkannter permanenter Fehler kann beispielsweise dadurch behandelt werden, dass das Laufzeitobjekt nicht mehr ausgeführt wird oder ein Teilsystem dauerhaft abgeschaltet wird. Ein erkannter transienter Fehler hingegen kann beispielsweise einfach ignoriert werden oder mittels eines Forward-Recovery behandelt werden.
  • In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens läuft auf mindestens einer Recheneinheit des Computersystems ein Betriebssystem ab. Die Auswahl der Fehlerbehandlungsroutine wird hierbei durch das Betriebssystem durchgeführt. Dies ermöglicht eine besonders schnelle und sichere Bearbeitung von erkannten Fehlern, da ein Betriebssystem üblicherweise auf die zur Behandlung eines aufgetretenen Fehlers notwendigen Ressourcen Zugriff hat. Beispielsweise weist ein Betriebssystem einen sogenannten Scheduler auf, der entscheidet, welches Laufzeitobjekt zu welcher Zeit auf einem Prozessor ausgeführt wird. Dies ermöglicht es einem Betriebssystem, besonders schnell ein Laufzeitobjekt zu beenden, neu zu starten oder statt des Laufzeitobjekts eine Fehlerbehandlungsroutine zu starten.
  • Weist das Computersystem mehrere Komponenten auf und wird eine Komponente, beispielsweise eine Recheneinheit, als defekt erkannt, so kann eine Fehlerbehandlungsroutine, die das Abschalten der defekten Komponente oder die Durchführung eines Selbsttests vorsieht, besonders einfach durch das Betriebssystem ausgewählt werden, da das Betriebssystem üblicherweise die Verwaltung der einzelnen Komponenten vornimmt oder einen Zugriff auf die die Komponenten verwaltenden Funktionseinheit besitzt.
  • Die Aufgabe wird auch durch ein Computersystem der eingangs genannten Art dadurch gelöst, dass einem durch die Fehlererkennungseinheit bei einem auftretenden Fehler erzeugten Fehlerbehandlungssignal eine Kennung zugeordnet ist und das Computersystem Mittel zur Auswahl einer ausführbaren Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen in Abhängigkeit von der Kennung aufweist.
  • Die Aufgabe wird auch durch eine Fehlererkennungseinheit der eingangs genannten Art dadurch gelöst, dass die Fehlererkennungseinheit Mittel aufweist, um in Abhängigkeit von mindestens einer Eigenschaft des erkannten Fehlers ein Fehlererkennungssignal zu erzeugen, wobei dem Fehlererkennungssignal eine Kennung zugeordnet werden kann, die eine Auswahl einer Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen ermöglicht.
  • Vorteilhafterweise gibt die mindestens eine Eigenschaft des erkannten Fehlers an, ob der erkannte Fehler ein transienter oder ein permanenter Fehler ist, ob der Fehler durch ein fehlerhaftes Laufzeitobjekt bzw. eine fehlerhafte Softwarekomponente oder eine fehlerhafte Hardwarekomponente bzw. ein fehlerhaftes Teilsystem bedingt ist und/oder welches Laufzeitobjekt während des Auftretens des Fehlers ausgeführt wurde.
  • Auf einem Computersystem können üblicherweise eine Vielzahl von Computerprogrammen parallel, quasi-parallel oder sequentiell ablaufen. Ein auf dem erfindungsgemäßen Computersystem ablaufendes Computerprogramm ist beispielsweise ein sogenanntes Anwendungsprogramm, mittels dessen Anwendungsdaten bearbeitet werden. Dieses Computerprogramm umfasst mindestens ein Laufzeitobjekt.
  • Von besonderer Bedeutung bei der vorliegenden Erfindung ist ferner die Realisierung des erfindungsgemäßen Verfahrens in Form mindestens eines Computerprogramms. Dabei ist das mindestens eine Computerprogramm auf dem Computersystem, insbesondere auf einem Rechengerät, ablauffähig und zur Ausführung des erfindungsgemäßen Verfahrens programmiert. In diesem Fall wird das erfindungsgemäße Verfahren durch das Computerprogramm realisiert, so dass dieses Computerprogramm in gleicher Weise die Erfindung darstellt wie das Verfahren, zu dessen Ausführung das Computerprogramm geeignet ist. Dieses Computerprogramm ist vorzugsweise auf einem maschinenlesbaren Datenträger abgespeichert. Als maschinenlesbarer Datenträger kann beispielsweise ein Random-Access-Memory, ein Read-Only-Memory, ein Flash-Memory, eine Digital-Versitile-Disc oder eine Compact-Disc zum Einsatz kommen.
  • Das Computerprogramm zur Ausführung des erfindungsgemäßen Verfahrens ist vorteilhafterweise als ein Betriebssystem ausgestaltet.
  • Zeichnungen
  • Weitere Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen, die in der Zeichnung dargestellt sind. Es zeigen:
  • 1 eine schematische Darstellung von Komponenten eines Computersystems zur Durchführung des erfindungsgemäßen Verfahrens;
  • 2 ein Ablaufdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens in einer ersten Ausführungsform;
  • 3 ein Ablaufdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens in einer zweiten Ausführungsform.
  • Beschreibung der Ausführungsbeispiele
  • In 1 ist ein Computersystem 1 schematisch dargestellt, das zur Durchführung des erfindungsgemäßen Verfahrens geeignet ist. Das Computersystem 1 weist zwei Recheneinheiten 2, 3 auf. Die Recheneinheiten 2, 3 können beispielsweise vollständige Prozessoren (CPUs) sein (sogenannte Dual-Core-Architektur). Eine Dual-Core-Architektur ermöglicht es, die beiden Recheneinheiten 2, 3 derart redundant zu betreiben, dass ein Prozess, beziehungsweise ein Laufzeitobjekt, auf den beiden Recheneinheiten 2, 3 nahezu gleichzeitig ausgeführt werden kann. Die Recheneinheiten 2, 3 können auch arithmetisch-logische Einheiten (sogenannte arithmetic logical units; ALUs, sein (sogenannte Dual-ALU-Architektur).
  • Den beiden Recheneinheiten 2, 3 sind ein gemeinsamer Programmspeicher 4 und eine Fehlererkennungseinheit 5 zugeordnet. In dem Programmspeicher 4 sind mehrere ausführbare Laufzeitobjekte abgespeichert. Die Fehlererkennungseinheit 5 ist beispielsweise als Vergleicher ausgebildet, der es ermöglicht, von den Prozessoren 2 und 3 berechnete Werte zu vergleichen.
  • Zur Durchführung der grundlegenden Steuerung des Computersystems 1 läuft auf dem Computersystem 1 ein Betriebssystem 6 ab. Das Betriebssystem 6 weist einen Scheduler 7 und ein Interface 8 auf. Der Scheduler 7 verwaltet die von den Recheneinheiten 2, 3 zur Verfügung gestellte Rechenzeit, indem er entscheidet, wann welcher Prozess, beziehungsweise wann welches Laufzeitobjekt, auf welcher der Recheneinheiten 2 und 3 ausgeführt wird. Das Interface 8 ermöglicht es der Fehlererkennungseinheit 5, erkannte Fehler mittels eines Fehlererkennungssignals dem Betriebssystem 6 mitzuteilen.
  • Das Betriebssystem 6 hat Zugriff auf einen Speicherbereich 9. Der Speicherbereich 9 beinhaltet für jedes Fehlererkennungssignal die diesem Fehlererkennungssignal zugeordnete Kennung bzw. die diesem Fehlererkennungssignal zugeordneten Kennungen. Es ist sowohl möglich, den Speicherbereich 9 und den Programmspeicher 4 auf ein und demselben Speicherelement als auch auf unterschiedlichen Speicherelementen abzubilden. Das Speicherelement beziehungsweise die Speicherelemente können beispielsweise ein der Recheneinheit 2 beziehungsweise der Recheneinheit 3 zugeordneter Arbeitsspeicher oder ein Cache sein. Der Speicherbereich 9 kann aber auch insbesondere derselbe Speicherbereich sein, auf dem das Betriebssystem 6 vor oder während der Abarbeitung auf dem Computersystem 1 abgespeichert ist.
  • Es sind eine Vielzahl weiterer Ausgestaltungen des Computersystems 1 vorstellbar. Beispielsweise könnte das Computersystem 1 nur eine Recheneinheit aufweisen. Ein Fehler bei der Abarbeitung eines Laufzeitobjekts könnte dann beispielsweise durch die Fehlererkennungseinheit 5 mittels einer Plausibilitätsprüfung erfolgen.
  • Insbesondere könnte ein und dasselbe Laufzeitobjekt auf der Recheneinheit 2, 3 mehrmals hintereinander ausgeführt werden. Die Fehlererkennungseinheit 5 könnte dann die jeweils erzeugten Ergebnisse vergleichen und bei einem Abweichen der Ergebnisse voneinander auf das Vorhandensein eines Fehlers des Laufzeitobjekts oder einer Hardwarekomponente, beispielsweise der Recheneinheit 2, 3, auf dem das Laufzeitobjekt ausgeführt wird, schließen.
  • Ferner ist es vorstellbar, dass das Computersystem 1 mehr als zwei Recheneinheiten 2, 3 aufweist. Ein Laufzeitobjekt könnte dann beispielsweise auf drei der vorhandenen Recheneinheiten 2, 3 redundant ausgeführt werden. Durch einen Vergleich der so erhaltenen Ergebnisse könnte die Fehlererkennungseinheit 5 das Vorhandensein eines Fehlers erkennen.
  • Insbesondere kann das Computersystem 1 weitere Komponenten umfassen. Beispielsweise kann das Computersystem 1 ein Bussystem zum Austausch von Daten zwischen den einzelnen Komponenten umfassen. Ferner kann das Computersystem 1 Recheneinheiten umfassen, die mittels eines weiteren, unabhängigen Betriebssystems gesteuert werden. Insbesondere kann das Computersystem 1 eine Vielzahl unterschiedlicher Speicherelemente aufweisen, auf denen Programme und oder Daten abgespeichert sind bzw. während des Betriebs des Computersystems 1 ausgelesen und/oder geschrieben werden.
  • In 2 ist ein Ablaufdiagramm des erfindungsgemäßen Verfahrens schematisch dargestellt. Das Verfahren beginnt in einem Schritt 100. In einem Schritt 101 veranlasst der Scheduler 7 die Recheneinheiten 2, 3, ein Laufzeitobjekt aus dem Programmspeicher 4 auszulesen und auszuführen.
  • In einem Schritt 102 wird überprüft, ob ein Fehler bei der Abarbeitung des Laufzeitobjekts vorliegt. Dies geschieht beispielsweise durch die Fehlererkennungseinheit 5, die die von den Recheneinheiten 2, 3 redundant berechneten Ergebnisse vergleicht. Zur Fehlererkennung kann ferner ein Hardwaretest durchgeführt werden, der eine korrekte Funktionsweise der Hardware mittels fest vorgegebener Routinen überprüft. Liegt kein Fehler vor, so wird zu dem Schritt 101 zurückverzweigt und das Laufzeitobjekt weiter ausgeführt bzw. ein weiteres Laufzeitobjekt geladen und in den Recheneinheiten 2, 3 ausgeführt.
  • Wird in dem Schritt 102 jedoch ein Fehler erkannt, so wird in dem Schritt 103 von der Fehlererkennungseinheit 5 ein Fehlererkennungssignal erzeugt.
  • Die Fehlererkennungseinheit 5 erzeugt dabei das Fehlererkennungssignal in Abhängigkeit von dem erkannten Fehler. Beispielsweise wird bei einem erkannten Hardware-Fehler ein anderes Fehlererkennungssignal erzeugt als bei einem erkannten Software-Fehler. Ebenso kann die Fehlererkennungseinheit 5 unterscheiden, ob der erkannte Fehler ein transienter Fehler oder ein permanenter Fehler ist. Des weiteren kann das Fehlererkennungssignal in Abhängigkeit der Hardwarekomponente, auf der der Fehler auftritt oder auf der ein fehlerhaftes Laufzeitobjekt aufläuft, erzeugt werden. Insbesondere ist es vorstellbar, dass das Fehlererkennungssignal in Abhängigkeit davon erzeugt wird, ob das fehlerhafte Laufzeitobjekt bzw. die fehlerhafte Hardwarekomponente in einer sicherheitskritischen oder einer zeitkritischen Umgebung abläuft.
  • In dem Schritt 103 wird ferner das Fehlererkennungssignal von der Fehlererkennungseinheit 5 beispielsweise über das Interface 8 an das Betriebssystem 6 übermittelt. Es ist ferner vorstellbar, dass das Fehlererkennungssignal in Form eines Interrupts einer der Recheneinheiten 2, 3 zugeführt wird. Die Recheneinheit 2, 3 unterbricht daraufhin die aktuelle Abarbeitung und sorgt dafür, dass das Fehlererkennungssignal an das Betriebssystem 6, beispielsweise über das Interface 8, weitergegeben wird.
  • In einem Schritt 104 wird die Kennung des Fehlererkennungssignals ermittelt. Dazu kann beispielsweise in dem Speicherbereich 9 eine Tabelle abgelegt sein, in der zu jedem Fehlererkennungssignal die diesem zugeordnete Kennung bzw. die diesem zugeordneten Kennungen abgespeichert ist. Die Kennung bezeichnet beispielsweise die Fehlerbehandlungsroutine, die infolge des erhaltenen Fehlererkennungssignals von dem Betriebssystem 6 ausgewählt werden soll.
  • Es kann aber auch vorgesehen sein, dass die Kennung in einem der jeweiligen Recheneinheit 2, 3 zugeordneten Speicherbereich, beispielsweise einem Cache oder Register, abgelegt wird. In diesem Fall könnte das Betriebssystem 6 von der jeweiligen Recheneinheit 2, 3 die Kennung des Fehlererkennungssignals anfordern.
  • In einem optionalen Schritt 105 ermittelt das Betriebssystem 6 das fehlerhafte Laufzeitobjekt bzw. die fehlerhafte Hardwarekomponente. Diese Information kann beispielsweise von dem Scheduler 7 erhalten werden.
  • Es ist ferner möglich, diese Information direkt dem Fehlererkennungssignal zu entnehmen. Dies ist beispielsweise dann möglich, wenn die Fehlererkennungseinheit 5 bereits die fehlerhafte Hardwarekomponente oder das fehlerhafte Laufzeitobjekt identifiziert hat und das Fehlererkennungssignal in Abhängigkeit von der Hardwarekomponente derart erzeugt wurde, dass die dem Fehlererkennungssignal zugeordnete Kennung Aufschluss über die betroffene Komponente geben kann. Beispielsweise kann hierzu in der in dem Speicherbereich 9 abgespeicherten Tabelle zu jedem Fehlererkennungssignal die fehlerhaften Komponenten mittels geeigneter Bezeichner angegeben sein, die eine Erzeugung des erhaltenen Fehlererkennungssignals auslösen können. Anhand eines erhaltenen Fehlererkennungssignal kann dann auf die fehlerhafte Hardwarekomponente bzw. das fehlerhafte Laufzeitobjekt geschlossen werden.
  • In einem Schritt 106 wird in Abhängigkeit von dem Fehlererkennungssignal und der dem Fehlererkennungssignal zugeordneten Kennung eine Fehlerbehandlungsroutine ausgewählt. Dabei kann die dem Fehlererkennungssignal zugeordnete Kennung die auszuwählende Fehlerbehandlungsroutine und damit den durchzuführenden Fehlerbehandlungsmechanismus eindeutig bestimmen. Beispielsweise kann die Kennung bestimmen, dass das fehlerhafte Laufzeitobjekt abgebrochen werden soll und nicht wieder aktiviert werden soll. Die Kennung kann ebenso bestimmen, dass zu einem vorgegebenen Check-Punkt zurückgesprungen werden soll und von dort das Laufzeitobjekt erneut ausgeführt werden soll (Backward-Recovery). Die Kennung kann ferner bestimmen, dass ein Forward-Recovery durchgeführt wird, die Ausführung des Laufzeitobjekts wiederholt wird oder keine weitere Fehlerbehandlung durchgeführt werden soll.
  • Die Kennung kann auch bestimmen, dass eine Hardwarekomponente, beispielsweise eine Recheneinheit 2, 3 oder ein Bussystem, neu gestartet werden soll, ein Selbsttest ausgeführt werden soll oder die entsprechende Hardwarekomponente, bzw. ein Teilsystem des Computersystems abgeschaltet werden soll.
  • Besonders vorteilhaft ist es, wenn dem von der Fehlererkennungseinheit 5 an das Betriebssystem 6 übermittelten Fehlererkennungssignal eine Information bezüglich der Art des aufgetretenen Fehlers zu entnehmen ist. Diese Art kann beispielsweise angeben, ob es sich um einen transienten oder um einen permanenten Fehler handelt.
  • Dabei können dem Laufzeitobjekt beispielsweise mehrere Kennungen zugeordnet sein. Eine erste Kennung kann dabei die bei einem Auftreten des permanenten Fehlers auszuführende Fehlerbehandlungsroutine beschreiben. Eine zweite Kennung hingegen kann die bei einem Auftreten eines transienten Fehlers auszuführende Fehlerbehandlungsroutine bezeichnen. Dies ermöglicht folglich eine noch flexiblere Fehlerbehandlung.
  • Insbesondere wenn das Computersystem 1 als Mehr-Prozessor-System oder als Mehr-ALU-System ausgestaltet ist, kann es vorteilhaft sein, die Auswahl der Fehlerbehandlungsroutine davon abhängig zu machen, ob ein gerade ausgeführtes Laufzeitobjekt auf einem oder mehreren der Recheneinheiten 2, 3 beziehungsweise der ALUs ausgeführt wurde und ob der Fehler auf einem oder mehreren der Recheneinheiten 2, 3 aufgetreten ist. Diese Information könnte beispielsweise dem Fehlererkennungssignal entnommen werden. Das Fehlererkennungssignal könnte hierbei unterschiedliche Kennungen für die Fälle aufweisen, dass das Laufzeitobjekt auf nur eine Recheneinheit 2, 3 bzw. dass das Laufzeitobjekt auf mehreren Recheneinheiten 2, 3 fehlerhaft ausgeführt wurde.
  • In einem Schritt 107 wird die Fehlerbehandlung durchgeführt, in dem die durch das Betriebssystem 6 ausgewählte Fehlerbehandlungsroutine ausgeführt wird. In Abhängigkeit von der ausgewählten Fehlerbehandlungsroutine kann das Betriebssystem beispielsweise den Scheduler 7 veranlassen, die aktuell auf den Recheneinheiten 2, 3 ausgeführten Laufzeitobjekte abzubrechen, alle berechneten Wert zu verwerfen und die Laufzeitobjekte erneut zu starten.
  • In einem Schritt 108 endet das Verfahren.
  • In 3 ist eine weitere Ausführungsform des erfindungsgemäßen Verfahrens mittels eines Ablaufdiagramms schematisch dargestellt, bei dem weitere Größen bei der Auswahl der durchzuführenden Fehlerbehandlungsroutine berücksichtigt werden.
  • Das Verfahren beginnt in einem Schritt 200. Die Schritt 201 bis 205 können den in 2 dargestellten und beschriebenen Schritten 101 bis 105 entsprechen.
  • In einem Schritt 206 wird eine das Laufzeitobjekt beziehungsweise die Ausführung des Laufzeitobjekts charakterisierende Größe ermittelt. Eine das Laufzeitobjekt charakterisierende Größe kann beispielsweise eine diesem Laufzeitobjekt zugeordnete Sicherheitsrelevanz beschreiben. Eine das Laufzeitobjekt charakterisierende Größe kann ferner beschreiben, ob und von welchen weiteren Laufzeitobjekten die von dem vorliegenden Laufzeitobjekt berechneten Größen benötigt werden, bzw. ob und von welchen weiteren Laufzeitobjekten die von dem vorliegenden Laufzeitobjekt berechneten Größen abhängen. Damit könnten folglich Abhängigkeiten der Laufzeitobjekte untereinander beschrieben werden.
  • Die eine Ausführung eines Laufzeitobjekts charakterisierende Größe kann ferner beschreiben, ob zur Zeit des Auftretens des Fehlers bereits ein Speicherzugriff durch das Laufzeitobjekt erfolgt ist, ob der Fehler relativ kurz nach Laden des Laufzeitobjekts erfolgte, ob die von dem Laufzeitobjekt zu berechnenden Größen dringend von anderen Laufzeitobjekten benötigt werden und/oder wie groß die für eine Ausführung des Laufzeitobjekts noch zur Verfügung stehende Zeitspanne ist.
  • Derartige Größen können bei einer Auswahl der Fehlerbehandlungsroutine besonders vorteilhaft berücksichtigt werden. Steht beispielsweise nicht mehr genug Zeit zur Verfügung, das gesamte Laufzeitobjekt erneut auszuführen, kann vorgesehen sein, ein Backward-Recovery oder ein Forward-Recovery durchzuführen. Dies wird dadurch erreicht, dass in Abhängigkeit der Größe, die die noch zur Verfügung stehende Zeitspanne angibt, die jeweilige Fehlerbehandlungsroutine ausgewählt wird.
  • In einem Schritt 207 wird ermittelt, ob ein permanenter oder ein transienter Fehler vorliegt. Dazu können beispielsweise Fehlerzähler mitgeführt werden, die angeben, wie häufig ein Fehler bei der Ausführung eines bestimmten Laufzeitobjekts auftritt. Tritt dieser besonders häufig oder gar immer auf, kann von einem permanenten Fehler ausgegangen werden.
  • Es ist des weiteren möglich, einer bestimmten Hardwarekomponente bzw. einem Teilsystem des Computersystems 1, also beispielsweise einer Recheneinheit 2, 3, oder einem Bussystem, einen Fehlerzähler zuzuordnen. Wird beispielsweise festgestellt, dass auf einer Recheneinheit 2, 3 des Computersystems 1 die Ausführung besonders vieler Laufzeitobjekte fehlerhaft ist, bzw. eine Ausführung besonders häufig nicht möglich ist, so kann auf das Vorhandensein eines permanenten Fehlers, beispielsweise eine defekten Hardware, geschlossen werden.
  • In einem Schritt 208 wird eine Fehlerbehandlungsroutine ausgewählt. Dazu werden die in den Schritten 205 bis 207 ermittelten Größen, insbesondere eine oder mehrere dem fehlerhaften Fehlererkennungssignal zugeordneten Kennungen, eine oder mehrere das Laufzeitobjekt, beziehungsweise die Ausführung des Laufzeitobjekts, charakterisierende Größe, sowie die Art des aufgetretenen Fehlers berücksichtigt.
  • Die Fehlerbehandlungsroutine wird beispielsweise durch das Betriebssystem 6 ausgewählt. Die Auswahl kann mittels der vorgenannten Größen in einer Art Entscheidungsbaum durchgeführt werden.
  • In einem Schritt 209 wird die Fehlerbehandlung durchgeführt und in einem Schritt 210 das Verfahren beendet.
  • Mit dem erfindungsgemäßen Verfahren ist es folglich möglich, bei der Programmierung beziehungsweise der Implementierung oder der Installation der Fehlererkennungseinheit 5 auf dem Computersystem 1 festzulegen, welche Fehlerbehandlungsroutine bei Auftreten eines bestimmten Fehlers ausgeführt werden soll. Dies ermöglicht eine besonders flexible und der Art des erkannten Fehlers angepasste Fehlerbehandlung. Dabei können erfindungsgemäß einem Laufzeitobjekt mehrere Kennungen zugeordnet sein. Damit kann die Auswahl einer Fehlerbehandlungsroutine noch flexibler gestaltet sein.
  • Vorzugsweise können eine die Art des Fehlers (transient/permanent), eine das Laufzeitobjekt selbst oder eine die Ausführung des Laufzeitobjekts charakterisierende Größen zur Auswahl der Fehlerbehandlungsroutine herangezogen werden.
  • Ferner ist es möglich, Informationen, die von der Fehlererkennungseinheit 5 ermittelt werden, beispielsweise eine Identität der Recheneinheiten 2, 3, auf dem das Laufzeitobjekt während des Auftretens des Fehlers ausgeführt wurde, bei der Auswahl der Fehlerbehandlungsroutine zu berücksichtigen. Hierbei ist es vorstellbar, dass einer oder mehreren Hardwarekomponenten beziehungsweise einer oder mehreren der Recheneinheiten 2, 3 eine Sicherheitsrelevanz zugeordnet ist. Tritt ein Fehler auf einer Recheneinheit 2, 3 auf, der besonders sicherheitsrelevant ist, kann vorgesehen sein, dass eine andere Fehlerbehandlungsroutine ausgewählt wird, als wenn dasselbe Laufzeitobjekt bei Auftreten eines Fehlers auf einer Recheneinheit 2, 3 ausgeführt wurde, die weniger sicherheitsrelevant ist. Damit ist eine noch flexiblere Fehlerbehandlung auf dem Computersystem 1 möglich.
  • Während der Durchführung der Fehlerbehandlung in den Schritten 107 beziehungsweise 209 kann ferner geprüft werden, ob beispielsweise ein durch die Fehlerbehandlungsroutine veranlasstes erneutes Ausführen eines Laufzeitobjekts bzw. ein erneutes Betreiben einer neu gestarteten Hardwarekomponente wieder zu einem Fehler führt. In diesem Fall könnte vorgesehen sein, erneut eine Fehlerbehandlungsroutine, dieses Mal jedoch eine andere, auszuwählen. Beispielsweise kann in diesem Fall vorgesehen sein, das ganze System beziehungsweise ein Teilsystem abzuschalten.
  • Neben den mittels der Ablaufdiagramme in den 2 und 3 dargestellten Ausführungsformen des erfindungsgemäßen Verfahrens sind weitere Ausführungsformen denkbar. Insbesondere kann die Reihenfolge einzelner Schritte geändert werden, können einige Schritte entfallen oder können neue Schritte hinzugenommen werden.
  • Beispielsweise kann der Schritt 105 bzw. der Schritt 205 entfallen, wenn weder die an der Fehlererzeugung beteiligte Hardwarekomponente, also beispielsweise das Bussystem, ein Speicherelement oder eine der Recheneinheiten 2, 3, noch die während oder vor dem aufgetretenen Fehler ausgeführte Softwarekomponente, also beispielsweise das auf einer Recheneinheit ablaufende Laufzeitobjekt, bei der Auswahl bzw. der Auswahl der Fehlerbehandlungsroutine explizit berücksichtigt werden muss. Dies ist insbesondere dann nicht notwendig, wenn das erzeugte Fehlererkennungssignal bereits eindeutig auf eine Hardware- und/oder eine Softwarekomponente hinweist.
  • Das erfindungsgemäße Verfahren kann auf unterschiedlichste Weise realisiert bzw. programmiert und auf dem Computersystem 1 implementiert sein. Hierbei sind insbesondere die zur Verfügung stehende Programmierumgebung, sowie die Eigenschaften des zugrundeliegenden Computersystems 1, sowie das darauf ablaufende Betriebssystem 6 zu berücksichtigen.
  • Ferner können auch das Fehlererkennungssignal, die einem Fehlererkennungssignal zugeordnete Kennung, eine Hardwarekomponente oder eine Softwarekomponente auf unterschiedlichste Art bezeichnet sein. Beispielsweise werden Hardware- und Softwarekomponenten mittels alphanumerischer Bezeichner, sogenannter strings, bezeichnet. Die einem Fehlererkennungssignal zugeordnete Kennung kann beispielsweise durch eine der auszuwählenden Fehlerbehandlungsroutine zugeordneten Zeigerstruktur, einem sogenannten pointer, realisiert sein. Dies erlaubt beispielsweise einen besonders bequemen Aufruf der ausgewählten Fehlerbehandlungsroutine. Dabei ist es vorstellbar, weitere Informationen, z.B. Informationen, die eine Identifizierung einer fehlerhaften Hardware- oder Softwarekomponente ermöglichen, in Form sogenannter Argumente bei dem Aufruf der Fehlerbehandlungsroutine an diese zu übergeben.

Claims (19)

  1. Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem (1), wobei das Computerprogramm mindestens ein Laufzeitobjekt umfasst und bei dem ein während der Ausführung des Laufzeitobjekts auftretender Fehler durch eine Fehlererkennungseinheit (5) erkannt wird, dadurch gekennzeichnet, dass die Fehlererkennungseinheit (5) bei einem auftretenden Fehler ein Fehlerbehandlungssignal erzeugt, dem Fehlerbehandlungssignal eine Kennung zugeordnet ist, in Abhängigkeit von der Kennung eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen ausgewählt wird und die ausgewählte Fehlerbehandlungsroutine ausgeführt wird.
  2. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Fehlerbehandlungssignal ein externes Signal ist.
  3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine das Laufzeitobjekt und/oder die Ausführung des Laufzeitobjekts charakterisierende Größe erfasst wird und das Fehlerbehandlungssignal in Abhängigkeit der mindestens einen erfassten Größe erzeugt wird.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die erfasste Größe eine noch zur Verfügung stehende Zeitdauer bis zu einem vorgegebenen Ereignis beschreibt.
  5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Computersystem (1) mehrere Recheneinheiten (2, 3) umfasst, das Laufzeitobjekt auf mindestens zwei der Recheneinheiten (2, 3) parallel ausgeführt wird, ein Vergleich der parallel erzeugten Ergebnisse der mindestens zwei Recheneinheiten (2, 3) durchgeführt wird und ein Fehlerbehandlungssignal erzeugt wird, wenn die Ergebnisse nicht übereinstimmen.
  6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, verwendet wird.
  7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren in einem sicherheitsrelevanten System eingesetzt wird.
  8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine der Fehlerbehandlungsroutinen in der vorgebbaren Menge von Fehlerbehandlungsroutinen eine der folgenden Fehlerbehandlungsmöglichkeiten realisiert: a. Durchführen keiner Operation; b. Abbruch der Ausführung des Laufzeitobjekts; c. Abbruch der Ausführung des Laufzeitobjekts und Verbot einer neuen Aktivierung des Laufzeitobjekts; d. Wiederholung der Ausführung des Laufzeitobjekts; e. Backward Recovery; f. Forward Recovery; g. Reset.
  9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der auftretende Fehler ein transienter Fehler ist.
  10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Auswahl der Fehlerbehandlungsroutine zusätzlich in Abhängigkeit davon durchgeführt wird, ob der erkannte Fehler ein transienter Fehler oder ein permanenter Fehler ist.
  11. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass auf mindestens einer Recheneinheit (2, 3) des Computersystems (1) ein Betriebssystem (6) abläuft und die Auswahl der Fehlerbehandlungsroutine durch das Betriebssystem (6) durchgeführt wird.
  12. Computerprogramm, das auf einem Computersystem (1) ablauffähig ist, dadurch gekennzeichnet, dass das Computerprogramm ein Verfahren nach einem der Ansprüche 1 bis 11 ausführt, wenn es auf dem Computersystem (1) abläuft.
  13. Computerprogramm nach Anspruch 12, dadurch gekennzeichnet, dass das Computerprogramm als ein Betriebssystem (6) ausgebildet ist.
  14. Maschinenlesbarer Datenträger, auf dem ein auf einem Computersystem (1) ausführbares Computerprogramm abgespeichert ist, dadurch gekennzeichnet, dass das Computerprogramm ein Verfahren nach einem der Ansprüche 1 bis 11 ausführt, wenn es auf dem Computersystem (1) ausgeführt wird.
  15. Computersystem (1), auf dem ein Computerprogramm ausführbar ist, das mindestens ein Laufzeitobjekt umfasst, wobei das Computersystem (1) eine Fehlererkennungseinheit (5) zur Erkennung eines während der Ausführung des Laufzeitobjekts auftretenden Fehlers aufweist, dadurch gekennzeichnet, dass einem durch die Fehlererkennungseinheit (5) bei einem auftretenden Fehler erzeugten Fehlerbehandlungssignal eine Kennung zugeordnet ist, und das Computersystem (1) Mittel zur Auswahl einer ausführbaren Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen in Abhängigkeit von der Kennung aufweist.
  16. Computersystem (1) nach Anspruch 15, dadurch gekennzeichnet, dass das Computersystem (1) ein Computerprogramm zur Auswahl einer Fehlerbehandlungsroutine gemäß eines Verfahrens nach einem der Ansprüche 1 bis 11 aufweist.
  17. Computersystem (1) nach Anspruch 16, dadurch gekennzeichnet, dass das Computerprogramm als Betriebssystem (6) ausgebildet ist.
  18. Fehlererkennungseinheit (5) in einem Computersystem (1), das mindestens eine Hardwarekomponente aufweist und auf dem mindestens ein Laufzeitobjekt ablauffähig ist, wobei die Fehlererkennungseinheit (5) während der Ausführung eines Laufzeitobjekts auftretende Fehler erkennt, dadurch gekennzeichnet, dass die Fehlererkennungseinheit (5) Mittel aufweist, um in Abhängigkeit von mindestens einer Eigenschaft des erkannten Fehlers ein Fehlererkennungssignal zu erzeugen, wobei dem Fehlererkennungssignal eine Kennung zugeordnet werden kann, die eine Auswahl einer Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen ermöglicht.
  19. Fehlererkennungseinheit (5) nach Anspruch 18, dadurch gekennzeichnet, dass die mindestens eine Eigenschaft des erkannten Fehlers angibt, ob der erkannte Fehler ein transienter oder ein permanenter Fehler ist, ob der Fehler durch eine fehlerhaftes Laufzeitobjekt oder eine fehlerhafte Hardwarekomponente bedingt ist und/oder welches Laufzeitobjekt während des Auftretens des Fehlers ausgeführt wurde.
DE102004046288A 2004-09-24 2004-09-24 Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem Withdrawn DE102004046288A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE102004046288A DE102004046288A1 (de) 2004-09-24 2004-09-24 Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem
PCT/EP2005/054038 WO2006032585A1 (de) 2004-09-24 2005-08-17 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
US11/662,429 US20080133975A1 (en) 2004-09-24 2005-08-17 Method for Running a Computer Program on a Computer System
CNA200580032256XA CN101027646A (zh) 2004-09-24 2005-08-17 用于处理计算机系统上的计算机程序的方法
JP2007532872A JP2008513899A (ja) 2004-09-24 2005-08-17 コンピュータシステム上でコンピュータプログラムを処理する方法
EP05787147A EP1805617A1 (de) 2004-09-24 2005-08-17 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004046288A DE102004046288A1 (de) 2004-09-24 2004-09-24 Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem

Publications (1)

Publication Number Publication Date
DE102004046288A1 true DE102004046288A1 (de) 2006-03-30

Family

ID=35311372

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004046288A Withdrawn DE102004046288A1 (de) 2004-09-24 2004-09-24 Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem

Country Status (6)

Country Link
US (1) US20080133975A1 (de)
EP (1) EP1805617A1 (de)
JP (1) JP2008513899A (de)
CN (1) CN101027646A (de)
DE (1) DE102004046288A1 (de)
WO (1) WO2006032585A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112008001528B4 (de) * 2007-06-11 2020-11-19 Toyota Jidosha Kabushiki Kaisha Multiprozessorsystem und Steuerverfahren hierfür

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004046611A1 (de) 2004-09-25 2006-03-30 Robert Bosch Gmbh Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem
US7962798B2 (en) * 2006-04-17 2011-06-14 The Trustees Of Columbia University In The City Of New York Methods, systems and media for software self-healing
WO2008092162A2 (en) 2007-01-26 2008-07-31 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US8095829B1 (en) * 2007-11-02 2012-01-10 Nvidia Corporation Soldier-on mode to control processor error handling behavior
JP4571996B2 (ja) * 2008-07-29 2010-10-27 富士通株式会社 情報処理装置及び処理方法
FR2986879B1 (fr) * 2012-02-15 2014-10-17 Airbus Operations Sas Procede et systeme de detection d'anomalies a solutionner dans un aeronef
GB202019527D0 (en) * 2020-12-10 2021-01-27 Imagination Tech Ltd Processing tasks in a processing system
CN113989023A (zh) * 2021-10-29 2022-01-28 中国银行股份有限公司 差错交易的处理方法及装置

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5155729A (en) * 1990-05-02 1992-10-13 Rolm Systems Fault recovery in systems utilizing redundant processor arrangements
JPH0635758A (ja) * 1992-07-20 1994-02-10 Fujitsu Ltd プログラム監視制御装置
US5371742A (en) * 1992-08-12 1994-12-06 At&T Corp. Table driven fault recovery system with redundancy and priority handling
DE4439060A1 (de) * 1994-11-02 1996-05-09 Teves Gmbh Alfred Mikroprozessoranordnung für ein Fahrzeug-Regelungssystem
JPH09120368A (ja) * 1995-10-25 1997-05-06 Unisia Jecs Corp Cpu監視装置
US5928369A (en) * 1996-06-28 1999-07-27 Synopsys, Inc. Automatic support system and method based on user submitted stack trace
US6012148A (en) * 1997-01-29 2000-01-04 Unisys Corporation Programmable error detect/mask utilizing bus history stack
DE19720618A1 (de) * 1997-05-16 1998-11-19 Itt Mfg Enterprises Inc Mikroprozessorsystem für Kfz-Regelungssysteme
JPH11259340A (ja) * 1998-03-10 1999-09-24 Oki Comtec:Kk コンピュータの再起動制御回路
US6948092B2 (en) * 1998-12-10 2005-09-20 Hewlett-Packard Development Company, L.P. System recovery from errors for processor and associated components
US6393582B1 (en) * 1998-12-10 2002-05-21 Compaq Computer Corporation Error self-checking and recovery using lock-step processor pair architecture
US6366980B1 (en) * 1999-06-04 2002-04-02 Seagate Technology Llc Disc drive for achieving improved audio and visual data transfer
US6615374B1 (en) * 1999-08-30 2003-09-02 Intel Corporation First and next error identification for integrated circuit devices
US6625749B1 (en) * 1999-12-21 2003-09-23 Intel Corporation Firmware mechanism for correcting soft errors
JP2001357637A (ja) * 2000-06-14 2001-12-26 Sony Corp 情報再生装置、情報処理方法及び情報記録媒体
US6950978B2 (en) * 2001-03-29 2005-09-27 International Business Machines Corporation Method and apparatus for parity error recovery
US7194671B2 (en) * 2001-12-31 2007-03-20 Intel Corporation Mechanism handling race conditions in FRC-enabled processors
US20040078650A1 (en) * 2002-06-28 2004-04-22 Safford Kevin David Method and apparatus for testing errors in microprocessors
US6993675B2 (en) * 2002-07-31 2006-01-31 General Electric Company Method and system for monitoring problem resolution of a machine
US7251755B2 (en) * 2004-02-13 2007-07-31 Intel Corporation Apparatus and method for maintaining data integrity following parity error detection
US7263631B2 (en) * 2004-08-13 2007-08-28 Seakr Engineering, Incorporated Soft error detection and recovery

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112008001528B4 (de) * 2007-06-11 2020-11-19 Toyota Jidosha Kabushiki Kaisha Multiprozessorsystem und Steuerverfahren hierfür

Also Published As

Publication number Publication date
CN101027646A (zh) 2007-08-29
US20080133975A1 (en) 2008-06-05
JP2008513899A (ja) 2008-05-01
WO2006032585A1 (de) 2006-03-30
EP1805617A1 (de) 2007-07-11

Similar Documents

Publication Publication Date Title
EP1794680A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
EP1805617A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE102012109614B4 (de) Verfahren zum Wiederherstellen von Stapelüberlauf- oder Stapelunterlauffehlern in einer Softwareanwendung
EP0011685B1 (de) Programmierbare Speicherschutzeinrichtung für Mikroprozessorsysteme und Schaltungsanordnung mit einer derartigen Einrichtung
EP1854007A2 (de) Verfahren, betriebssysem und rechengerät zum abarbeiten eines computerprogramms
WO2007017396A2 (de) Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems
DE102015210651B4 (de) Schaltung und Verfahren zum Testen einer Fehlerkorrektur-Fähigkeit
DE102006054169B4 (de) Verfahren und System für eine Zentralisierung einer Prozessabfolgeüberprüfung
EP1810139B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE102011119585A1 (de) Verbesserte skalierbare CPU für die codierte Ausführung von Software in hochabhängigen sicherheitsrelevanten Anwendungen
DE102007056218A1 (de) Verfahren zur Behandlung von transienten Fehlern in Echtzeitsystemen, insbesondere in Steuergeräten von Kraftfahrzeugen
DE102005037213A1 (de) Verfahren und Vorrichtung zur Umschaltung zwischen Betriebsmodi eines Multiprozessorsystems durch wenigstens ein externes Signal
DE102023201815A1 (de) Verfahren zum Testen eines Computerprogramms
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
DE102013202961A1 (de) Verfahren zum Überwachen eines Stackspeichers in einem Betriebssystem eines Steuergeräts eines Kraftfahrzeuges
WO2016206847A1 (de) Verfahren und vorrichtung zum absichern einer programmzählerstruktur eines prozessorsystems und zum überwachen der behandlung einer unterbrechungsanfrage
EP1812853A2 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
WO2017153411A1 (de) Verfahren zum betreiben eines steuergeräts für ein kraftfahrzeug
DE102009000874A1 (de) Verfahren zur Verbesserung der Analysierbarkeit von Softwarefehlern in einem Mikrocontroller
EP1461701B1 (de) Programmgesteuerte einheit mit überwachungseinrichtung
EP3388944A1 (de) Verfahren zur fehlererkennung in einem betriebssystem
EP1774417B1 (de) Verfahren und vorrichtung zum überwachen des ablaufs eines steuerprogramms auf einem rechengerät
DE10110050A1 (de) Verfahren zur Absicherung sicherheitskritischer Programmteile vor versehentlicher Ausführung und eine Speichereinrichtung zur Durchführung dieses Verfahrens
EP1739559A2 (de) Behandlung von Fehlerereignissen bei einem tragbarem Datenträger
DE102022205521A1 (de) Verfahren für einen Betrieb eines Steuergeräts eines Fahrzeuges

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee