WO2006032585A1 - Verfahren zur abarbeitung eines computerprogramms auf einem computersystem - Google Patents

Verfahren zur abarbeitung eines computerprogramms auf einem computersystem Download PDF

Info

Publication number
WO2006032585A1
WO2006032585A1 PCT/EP2005/054038 EP2005054038W WO2006032585A1 WO 2006032585 A1 WO2006032585 A1 WO 2006032585A1 EP 2005054038 W EP2005054038 W EP 2005054038W WO 2006032585 A1 WO2006032585 A1 WO 2006032585A1
Authority
WO
WIPO (PCT)
Prior art keywords
error
runtime object
computer system
error handling
computer program
Prior art date
Application number
PCT/EP2005/054038
Other languages
English (en)
French (fr)
Inventor
Wolfgang Pfeiffer
Reinhard Weiberle
Bernd Mueller
Florian Hartwich
Werner Harter
Ralf Angerbauer
Eberhard Boehl
Thomas Kottke
Yorck Collani
Rainer Gmehlich
Karsten Graebitz
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 JP2007532872A priority Critical patent/JP2008513899A/ja
Priority to EP05787147A priority patent/EP1805617A1/de
Priority to US11/662,429 priority patent/US20080133975A1/en
Publication of WO2006032585A1 publication Critical patent/WO2006032585A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components

Definitions

  • the invention relates to a method for processing a computer program on a
  • the invention also relates to a computer system on which a computer program can be executed.
  • the computer program comprises at least one runtime object.
  • An error occurring during execution of the runtime object on the computer system can be recognized by an error detection unit.
  • the invention also relates to an error detection unit in a computer system, which has at least one hardware component and on which at least one runtime object is executable, wherein the error detection unit detects errors occurring during execution of a runtime object.
  • the invention further relates to a computer program executable on a computer system and to a machine-readable data carrier on which a computer program is stored.
  • Errors When processing a computer program on a computer, errors may occur. Errors can be distinguished according to whether they are determined by the hardware (processor, bus systems, peripherals, etc.) or by the software (application programs,
  • transient errors When errors occur, a distinction is also made between permanent errors and transient errors. Permanent errors are always present and are based, for example, on faulty hardware or incorrectly programmed software. In contrast, transient errors are only temporary and therefore much more difficult to reproduce and predict. With binary stored, binary transmitted and / or binary processed data, transient errors occur, for example, in that individual bits are changed by electromagnetic influences or radiation (alpha radiation, neutron radiation).
  • Runtime objects are, for example, processes, tasks, or threads. During the execution of the computer program occurring errors can thus in principle the executed
  • Runtime object can be assigned.
  • a treatment of permanent errors is typically based on the shutdown of the computer system or at least the shutdown of individual hardware components or subsystems.
  • this has the disadvantage that the functionality of the computer system or the subsystem is no longer available.
  • the subsystems of a computer system are designed, for example, redundant.
  • transient errors are also dealt with by shutting down subsystems. It is also known to shut down one or more subsystems in case of transient errors that occur and to start again and, for example, to conclude by a self-test on a now error-free processing of the computer program. If no new error is detected, the subsystem continues to work. In this case, it is possible for the task interrupted by the error or the runtime object processed at this time not to continue is executed (so-called forward recovery). For example, forward recovery is used on real-time systems.
  • the error generated during an error error signal is assigned an identifier, depending on the identifier an error handling routine is selected from a predetermined amount of error handling routines and the selected error handling routine is executed.
  • an identifier is assigned to each error detection signal that can initiate error handling. This identifier indicates which of the default error handling mechanisms to use. This makes it possible to select the optimum error handling routine for an occurring error, so that a maximum availability of the computer system can be maintained.
  • An error detection signal can initiate error handling, for example in the form of a so-called interrupt.
  • an error detection signal can initiate error handling, for example in the form of a so-called interrupt.
  • a unit of the computer system monitoring the execution of the computer program is informed that an error has occurred.
  • the monitoring unit can then cause the execution of an error handling.
  • Erf ⁇ ndungshiel are to carry out the error treatment several
  • Error handling routines available Depending on an identifier associated with the error detection signal, an error routine is selected and executed. This allows a particularly flexible selection of an error handling routine. In particular, it is always possible to select the error handling routine which allows maximum availability of the computer system.
  • the error detection signal may be an internal signal. If, for example, the computer system comprises a plurality of arithmetic units and if the runtime object is executed in parallel on at least two of the arithmetic units, then a comparison of the results of the at least two arithmetic units generated in parallel can be carried out by the error detection unit.
  • Error detection unit then generates an error handling signal if the results do not match. If the run-time object is executed redundantly on more than two of the arithmetic units and the majority of executions of the runtime object have no error, then it may be expedient to continue the execution of the computer program and to ignore the erroneous execution of the runtime object. This is the from the
  • Error detection unit generated error detection signal associated with an identifier, which causes the computer system to select an error handling routine, by means of which the above-described error handling is possible.
  • the error handling signal is an external signal.
  • An external one is an external signal.
  • An error detection signal may be generated, for example, by an error detection unit associated with a communication system (e.g., a bus system).
  • the error detection unit can detect the presence of a transmission error or a defect of the communication system and attach to the generated error detection signal identifying the detected error identifier or a containing the identifier
  • An external error detection signal can for example also be generated by a memory element and describe a so-called parity error.
  • the error detection signal may be assigned a different identifier. Because the selection of the error handling routine depends on the Error detection signal associated identifier is carried out, an error handling can be performed very flexible. In particular, it is already possible during programming or when installing a new software component or a new hardware component to determine how the computer system should handle certain errors.
  • At least one variable characterizing the runtime object and / or the execution of the runtime object is detected.
  • the error handling signal is then generated depending on the detected quantity.
  • a size may for example be a priority assigned to the runtime object.
  • the detected quantity describes a still available time duration up to a predetermined event.
  • a predetermined event can be, for example, a change of the runtime object to be processed by a scheduler or the still available time duration until data calculated by the runtime object must be made available to another runtime object.
  • a variable characterizing the execution of the runtime object can also designate the one already executed. If, for example, the error occurs shortly after the runtime object has been loaded, it can be provided to reload and execute the entire runtime object. However, if the runtime object is already close to the end of the available execution time, or if another runtime object is urgently to be processed, it can be provided that the runtime object, during which the error occurred, can simply be ended.
  • variable characterizing the execution of the run-time object can also describe whether a data exchange with other run-time objects, whether a transfer of data via one or more communication systems or whether a memory access has already occurred.
  • the detected quantity can then be reflected in the identifier transmitted by the error detection signal and can thus be taken into account in the selection of the error handling routine.
  • the inventive method in a motor vehicle, in particular in a motor vehicle control unit, or in a safety-related system, for example used in a control of an aircraft.
  • a motor vehicle or in a safety-relevant system it is particularly important that occurring errors can be handled flexibly and thus the computer system operates particularly safely and is highly available.
  • Error handling routines in the specifiable set of error handlers one of the following error handling options:
  • the execution of the runtime object is aborted and, for example, another runtime object is executed instead.
  • Forward recovery The execution of the runtime object is interrupted and resumed at another subsequent point.
  • the method according to the invention is used to treat transient errors.
  • the selection of the error handling routine is performed depending on whether the detected error is a transient error or a permanent error.
  • a detected permanent error can be handled, for example, by the runtime object no longer being executed or a subsystem being switched off permanently.
  • a detected transient error for example, can simply be ignored or treated by forward recovery.
  • an operating system runs on at least one arithmetic unit of the computer system.
  • the selection of the error handling routine is performed by the operating system. This allows a particularly fast and secure processing of detected errors, as an operating system usually on the necessary resources to handle an error occurred
  • an operating system has a so-called scheduler, which decides which runtime object is executed on a processor at what time. This allows an operating system to terminate a runtime object very quickly, restart it, or start an error handler instead of the runtime object.
  • an error handling routine which provides for switching off the defective component or performing a self-test can be selected particularly easily by the operating system, since the operating system usually uses the Management of the individual components or has access to the components managing functional unit.
  • the object is also achieved by a computer system of the type mentioned above in that an error signal generated by the error detection unit in the event of an error occurring is assigned an identifier and the computer system has means for
  • an error detection unit of the type mentioned above in that the error detection unit has means for generating an error detection signal as a function of at least one property of the detected error, wherein an identifier can be assigned to the error detection signal, which selects an error handling routine allows a predeterminable set of error handling routines.
  • the at least one property of the detected error indicates whether the detected error is a transient or a permanent error, whether the error is caused by a faulty runtime object or software component or a faulty hardware component or faulty subsystem and / or which Runtime object was executed during the occurrence of the error.
  • Computer program includes at least one runtime object.
  • the method according to the invention is realized by the computer program, so that this computer program represents the invention in the same way as the method which the computer program is suitable for executing.
  • This computer program is preferably stored on a machine-readable data carrier.
  • a machine-readable data carrier For example, a random access memory, a read-only memory, a flash memory, a digital versitile disc or a compact disc can be used as the machine-readable data carrier.
  • the computer program for carrying out the method according to the invention is advantageously designed as an operating system.
  • Figure 1 is a schematic representation of components of a computer system for carrying out the method according to the invention
  • FIG. 3 shows a flow chart for a schematic representation of the method according to the invention in a second embodiment.
  • FIG. 1 schematically shows a computer system 1 which is suitable for carrying out the method according to the invention.
  • the computer system 1 has two arithmetic units 2, 3.
  • the arithmetic units 2, 3 can, for example, complete
  • CPUs Processors
  • dual-core architecture makes it possible to operate the two arithmetic units 2, 3 in such a redundant manner that a process or a run-time object can be executed almost simultaneously on the two arithmetic units 2, 3.
  • the arithmetic units 2, 3 can also be arithmetic logic units (so-called arithmetic logical units, ALUs, his (so-called dual ALU architecture).
  • the two computing units 2, 3 are assigned a common program memory 4 and an error detection unit 5.
  • the error detection unit 5 is designed, for example, as a comparator, which makes it possible to compare values calculated by the processors 2 and 3.
  • an operating system 6 runs on the computer system 1.
  • the operating system 6 has a scheduler 7 and an interface 8.
  • the scheduler 7 manages the computing time provided by the computing units 2, 3 by deciding when which process, or when, which runtime object, will be executed on the computing units 2 and 3.
  • the interface 8 allows the error detection unit 5 to notify detected errors by means of an error detection signal to the operating system 6.
  • the operating system 6 has access to a memory area 9.
  • the memory area 9 contains for each error detection signal the identifier assigned to this error detection signal or the identifiers assigned to this error detection signal. It is both possible to image the memory area 9 and the program memory 4 on one and the same memory element as well as on different memory elements.
  • the memory element or the memory elements can be, for example, a main memory or a cache assigned to the arithmetic unit 2 or the arithmetic unit 3.
  • the memory area 9 can also be in particular the same memory area on which the operating system 6 is stored on the computer system 1 before or during the processing
  • the computer system 1 could have only one computing unit.
  • An error in the processing of a runtime object could then be done for example by the error detection unit 5 by means of a plausibility check.
  • one and the same runtime object could be executed several times in succession on the arithmetic unit 2, 3.
  • the error detection unit 5 could then compare the results produced in each case and in the event of a deviation of the results from each other on the presence of an error of the runtime object or a hardware component, such as the arithmetic unit 2, 3, on which the runtime object is executed close.
  • the error detection unit 5 could detect the presence of an error.
  • the computer system 1 may comprise further components.
  • the computer system 1 may include a bus system for exchanging data between the individual components.
  • the computer system 1 can comprise arithmetic units which are controlled by means of a further, independent operating system.
  • the computer system 1 can have a multiplicity of different memory elements on which programs and / or data are stored or read out during operation of the computer system 1 and / or written.
  • FIG. 2 schematically shows a flow chart of the method according to the invention. The method begins in a step 100.
  • the scheduler 7 causes the arithmetic units 2, 3 to read out and execute a runtime object from the program memory 4.
  • a step 102 it is checked whether there is an error during the execution of the runtime object. This is done, for example, by the error detection unit 5, which compares the redundantly calculated by the arithmetic units 2, 3 results. For error detection, a hardware test can also be carried out, which checks the correct functioning of the hardware by means of predefined routines. If there is no error, it is branched back to the step 101 and the runtime object is executed further or another runtime object is loaded and executed in the arithmetic units 2, 3.
  • step 103 furthermore, the error detection signal is transmitted from the error detection unit 5, for example via the interface 8, to the operating system 6.
  • the error detection signal in the form of an interrupt of one of the arithmetic units 2, 3 is supplied.
  • the arithmetic unit 2, 3 then interrupts the current processing and ensures that the error detection signal to the operating system 6, for example via the interface 8, is passed.
  • a step 104 the identifier of the error detection signal is determined.
  • a table can be stored in the memory area 9 in which to each Error detection signal associated with this identifier or the associated identifiers is stored.
  • the identifier designates, for example, the error handling routine to be selected by the operating system 6 as a result of the received error detection signal.
  • the identifier is stored in a memory area assigned to the respective computing unit 2, 3, for example a cache or register.
  • the operating system 6 could request from the respective computing unit 2, 3 the identifier of the error detection signal.
  • the operating system 6 determines the faulty runtime object or the faulty hardware component. This information can be obtained, for example, from the scheduler 7.
  • the error detection unit 5 has already identified the faulty hardware component or the erroneous runtime object and the error detection signal was generated as a function of the hardware component such that the identifier associated with the error detection signal can provide information about the affected component.
  • the faulty components can be specified by means of suitable identifiers which can trigger a generation of the error detection signal obtained. Based on a received error detection signal can then be concluded that the faulty hardware component or the faulty runtime object.
  • an error handling routine is selected in response to the error detection signal and the identifier associated with the error detection signal.
  • the identifier associated with the error detection signal can unambiguously determine the error handling routine to be selected and thus the error handling mechanism to be performed. For example, the identifier may determine that the erroneous runtime object should be aborted and should not be reactivated. The identifier can also determine that a jump back to a given check point and from there the runtime object should be executed again (backward recovery). The identifier may further determine that a forward recovery is performed Execution of the runtime object is repeated or no further error handling is to be performed.
  • the identifier may also specify that a hardware component, for example a computing unit 2, 3 or a bus system, should be restarted, a self-test should be executed or the corresponding hardware component or a subsystem of the computer system should be switched off.
  • a hardware component for example a computing unit 2, 3 or a bus system
  • the error detection signal transmitted by the error detection unit 5 to the operating system 6 contains information regarding the type of error that has occurred. For example, this type can indicate whether it is transient or permanent.
  • a second identifier may designate the error handling routine to be executed upon the occurrence of a transient error. This consequently allows an even more flexible error handling.
  • the computer system 1 as a multi-processor system or as a multi-ALU
  • the System may be advantageous to make the selection of the error handling routine depending on whether a runtime object just executed on one or more of the arithmetic units 2, 3 and the ALUs was executed and whether the error on one or more of the arithmetic units 2, 3rd occured.
  • This information could, for example, be taken from the error detection signal.
  • the error detection signal could in this case have different identifiers for the cases that the run-time object was executed on only one arithmetic unit 2, 3 or that the runtime object on several arithmetic units 2, 3 was executed incorrectly.
  • a step 107 the error handling is performed in which the by the
  • Operating system 6 selected error handling routine is executed.
  • the operating system may cause the scheduler 7 to abort the runtime objects currently executing on the arithmetic units 2, 3, to discard all calculated values, and to restart the runtime objects.
  • the method ends.
  • FIG. 3 schematically shows a further embodiment of the method according to the invention by means of a flowchart, in which further variables are taken into account in the selection of the error handling routine to be carried out.
  • the method begins in a step 200.
  • the steps 201 to 205 may correspond to the steps 101 to 105 shown and described in FIG.
  • variable characterizing the runtime object is determined.
  • a variable characterizing the run-time object can describe, for example, a security relevance assigned to this run-time object.
  • a variable characterizing the runtime object can also describe whether and from which further runtime objects the variables calculated by the present runtime object are required, or whether and from which further runtime objects the variables calculated by the present runtime object depend. Thus dependencies of the runtime objects could be described among each other.
  • variable characterizing an execution of a runtime object can also describe whether memory access by the runtime object has already taken place at the time the error occurs, if the error took place relatively shortly after the runtime object was loaded, if the variables to be calculated by the runtime object are urgently required by other runtime objects are needed and / or how large is the time available for an execution of the runtime object.
  • Such quantities can be taken into account particularly advantageously when selecting the error handling routine. For example, if there is not enough time left to rerun the entire runtime object, it may be scheduled to perform backward recovery or forward recovery. This is achieved by selecting the respective error handling routine depending on the size which indicates the remaining available time span.
  • a step 207 it is determined whether there is a permanent or a transient error.
  • error counters may be included which indicate how frequently an error occurs occurs during execution of a particular runtime object. If this happens particularly frequently or always, a permanent error can be assumed.
  • a specific hardware component or a subsystem of the computer system that is, for example, a computing unit 2, 3, or a bus system, a
  • Assign error counter If, for example, it is determined that the execution of particularly many runtime objects is faulty on a computer unit 2, 3 of the computer system 1, or an execution is particularly often not possible, it can be concluded that a permanent fault, for example defective hardware, is present.
  • an error handling routine is selected.
  • the variables ascertained in steps 205 to 207 in particular one or more identifiers associated with the faulty error detection signal, one or more variables characterizing the runtime object or the execution of the runtime object, as well as the type of error that has occurred, are taken into account.
  • the error handling routine is selected by the operating system 6, for example.
  • the selection can be carried out by means of the aforementioned variables in a type of decision tree.
  • a step 209 the error handling is performed and in a step 210 the method is ended.
  • a variable characterizing the nature of the error (transient / permanent), a variable characterizing the runtime object itself or a variable characterizing the execution of the runtime object can be used to select the error handling routine.
  • information determined by the error detection unit 5 for example an identity of the arithmetic units 2, 3 on which the runtime object was executed during the occurrence of the error, in the selection of the error handling routine. It is conceivable that one or more hardware components or one or more of the computing units 2, 3 is assigned a security relevance.
  • step 105 or the step 205 may be omitted if neither of the
  • Error generation involved hardware component so for example, the bus system, a memory element or one of the arithmetic units 2, 3, nor the running during or before the error occurred software component, so for example, running on a computing unit runtime object, explicitly taken into account in the selection or selection of the error handling routine must become. This is not necessary in particular if the generated error detection signal already clearly indicates a hardware and / or a software component.
  • the inventive method can be implemented or programmed in a variety of ways and implemented on the computer system 1.
  • the available programming environment as well as the characteristics of the underlying computer system 1, as well as the operating system 6 running on it.
  • the error detection signal, the identifier associated with an error detection signal, a hardware component or a software component can also be designated in a wide variety of ways.
  • hardware and software components are referred to by means of alpha-numeric identifiers, so-called strings.
  • the identifier assigned to an error detection signal can be realized, for example, by a pointer structure assigned to the error handling routine to be selected, a so-called pointer. This allows, for example, a particularly convenient call of the selected error handling routine. It is conceivable to provide further information, e.g. Information that allows identification of a faulty hardware or software component, in the form of so-called arguments when calling the error handling routine to pass to them.

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

Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem
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. - A -
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. Erfϊndungsgemäß 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: Figur 1 eine schematische Darstellung von Komponenten eines Computersystems zur Durchführung des erfindungsgemäßen Verfahrens;
Figur 2 ein Ablaufdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens in einer ersten Ausfuhrungsform;
Figur 3 ein Ablaufdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens in einer zweiten Ausfuhrungsform.
Beschreibung der Ausfuhrungsbeispiele
In Figur 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 weicher 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 Figur 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 Figur 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 Figur 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 Figuren 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 alpha-numerischer 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

Ansprüche
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.
PCT/EP2005/054038 2004-09-24 2005-08-17 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem WO2006032585A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
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
US11/662,429 US20080133975A1 (en) 2004-09-24 2005-08-17 Method for Running a Computer Program on a Computer System

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=35311372

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/054038 WO2006032585A1 (de) 2004-09-24 2005-08-17 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 (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8316261B2 (en) 2004-09-25 2012-11-20 Robert Bosch Gmbh Method for running a computer program on a computer system
US11934257B2 (en) 2020-12-10 2024-03-19 Imagination Technologies Limited Processing tasks in a processing system

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
JP4458119B2 (ja) * 2007-06-11 2010-04-28 トヨタ自動車株式会社 マルチプロセッサシステム及びその制御方法
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
CN113989023A (zh) * 2021-10-29 2022-01-28 中国银行股份有限公司 差错交易的处理方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5371742A (en) * 1992-08-12 1994-12-06 At&T Corp. Table driven fault recovery system with redundancy and priority handling
WO2000075923A1 (en) * 1999-06-04 2000-12-14 Seagate Technology Llc Disc drive for achieving improved audio and visual data transfer
EP1164590A2 (de) * 2000-06-14 2001-12-19 Sony Corporation Informationswiedergabegerät, Informationsverarbeitungsverfahren und Informationsaufzeichnungsmedium
US20040025082A1 (en) * 2002-07-31 2004-02-05 Roddy Nicholas Edward Method and system for monitoring problem resolution of a machine

Family Cites Families (17)

* 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 プログラム監視制御装置
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 Ｃｐｕ監視装置
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 コンピュータの再起動制御回路
US6393582B1 (en) * 1998-12-10 2002-05-21 Compaq Computer Corporation Error self-checking and recovery using lock-step processor pair architecture
US6948092B2 (en) * 1998-12-10 2005-09-20 Hewlett-Packard Development Company, L.P. System recovery from errors for processor and associated components
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
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
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5371742A (en) * 1992-08-12 1994-12-06 At&T Corp. Table driven fault recovery system with redundancy and priority handling
WO2000075923A1 (en) * 1999-06-04 2000-12-14 Seagate Technology Llc Disc drive for achieving improved audio and visual data transfer
EP1164590A2 (de) * 2000-06-14 2001-12-19 Sony Corporation Informationswiedergabegerät, Informationsverarbeitungsverfahren und Informationsaufzeichnungsmedium
US20040025082A1 (en) * 2002-07-31 2004-02-05 Roddy Nicholas Edward Method and system for monitoring problem resolution of a machine

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MANCINI L ET AL: "EXCEPTION HANDLING IN REPLICATED SYSTEMS WITH VOTING", INTERNATIONAL SYMPOSIUM ON FAULT TOLERANT COMPUTING SYSTEMS. (FTCS). VIENNA, JULY 1 - 4, 1986, INTERNATIONAL SYMPOSIUM ON FAULT TOLERANT COMPUTING SYSTEMS. (FTCS). SYSTEMS, NEW YORK, IEEE, US, vol. SYMP. 16, July 1986 (1986-07-01), pages 384 - 389, XP000757419 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8316261B2 (en) 2004-09-25 2012-11-20 Robert Bosch Gmbh Method for running a computer program on a computer system
US11934257B2 (en) 2020-12-10 2024-03-19 Imagination Technologies Limited Processing tasks in a processing system

Also Published As

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

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
EP1917592B1 (de) Rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit sowie verfahren zu dessen steuerung
DE102012109614B4 (de) Verfahren zum Wiederherstellen von Stapelüberlauf- oder Stapelunterlauffehlern in einer Softwareanwendung
WO2007017396A2 (de) Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems
DE102014002473A1 (de) System und verfahren zur erhöhung der lockstep-kern-verfügbarkeit
EP1854007A2 (de) Verfahren, betriebssysem und rechengerät zum abarbeiten eines computerprogramms
EP1917581A2 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems
EP1810139B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE102006054169B4 (de) Verfahren und System für eine Zentralisierung einer Prozessabfolgeüberprüfung
DE102011119585A1 (de) Verbesserte skalierbare CPU für die codierte Ausführung von Software in hochabhängigen sicherheitsrelevanten Anwendungen
DE102005037213A1 (de) Verfahren und Vorrichtung zur Umschaltung zwischen Betriebsmodi eines Multiprozessorsystems durch wenigstens ein externes Signal
WO2010049339A1 (de) Vorrichtung und verfahren zur generierung redundanter, aber unterschiedlicher maschinencodes aus einem quellcode zur verifizierung für ein sicherheitskritisches system
EP1812853B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
WO2016206847A1 (de) Verfahren und vorrichtung zum absichern einer programmzählerstruktur eines prozessorsystems und zum überwachen der behandlung einer unterbrechungsanfrage
WO2007017372A1 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems mit wenigstens zwei ausführungseinheiten
WO2017153411A1 (de) Verfahren zum betreiben eines steuergeräts für ein kraftfahrzeug
DE102009000874A1 (de) Verfahren zur Verbesserung der Analysierbarkeit von Softwarefehlern in einem Mikrocontroller
EP1739559A2 (de) Behandlung von Fehlerereignissen bei einem tragbarem Datenträger
DE10110050A1 (de) Verfahren zur Absicherung sicherheitskritischer Programmteile vor versehentlicher Ausführung und eine Speichereinrichtung zur Durchführung dieses Verfahrens
DE102022205521A1 (de) Verfahren für einen Betrieb eines Steuergeräts eines Fahrzeuges
DE102020209137A1 (de) Verfahren und Vorrichtung zum Betreiben eines Fuzzing-Testens eines Programmcodes
DE102009005449B4 (de) Prozessor, der zur Überwachung des Kontrollflusses Befehlen zugeordnete Eigen- und Folgekennungen auswertet
WO2015007717A1 (de) Verfahren zur erhöhung der verfügbarkeit eines mikroprozessorsystems

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2005787147

Country of ref document: EP

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1236/CHENP/2007

Country of ref document: IN

Ref document number: 200580032256.X

Country of ref document: CN

Ref document number: 2007532872

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2005787147

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11662429

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 11662429

Country of ref document: US