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

Verfahren zur abarbeitung eines computerprogramms auf einem computersystem

Info

Publication number
EP1794680A1
EP1794680A1 EP05784608A EP05784608A EP1794680A1 EP 1794680 A1 EP1794680 A1 EP 1794680A1 EP 05784608 A EP05784608 A EP 05784608A EP 05784608 A EP05784608 A EP 05784608A EP 1794680 A1 EP1794680 A1 EP 1794680A1
Authority
EP
European Patent Office
Prior art keywords
error
runtime object
computer system
computer program
runtime
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
EP05784608A
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
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
Publication of EP1794680A1 publication Critical patent/EP1794680A1/de
Withdrawn legal-status Critical Current

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/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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level

Definitions

  • the invention relates to a method for processing a computer program on a computer system, which comprises at least one computing unit.
  • the computer program comprises at least one runtime object.
  • An error occurring during the execution of the runtime object is detected by an error detection unit. If a fault is detected, the error detection unit generates an error detection signal.
  • 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 further relates to a computer program executable on a computer system and to a machine-readable data carrier
  • Errors When processing a computer program on a computer, errors may occur. Errors can be distinguished according to whether they are caused by the hardware (processor, bus systems, peripherals, etc.) or by the software (application programs, operating systems, BIOS, etc.).
  • 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. In the case of 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 be assigned in principle to the running runtime object.
  • Permanent error handling is typically based on the shutdown of the computer system or at least the shutdown of Operay stemen.
  • 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 that the task interrupted by the error or the runtime object processed at this time is no longer executed (so-called forward recovery). For example, forward recovery is used on real-time systems.
  • Checkpoint resumed Such a technique, known as backward recovery, is used, for example, on computer systems used to conduct transactions in financial markets.
  • an error handling routine be selected from a predefinable set of error handling routines in dependence on an identifier associated with the runtime object and the selected one
  • one or more runtime objects that are executed on the computer system are assigned an identifier, which in turn designates at least one error handling routine. If an error occurs during the execution of the runtime object, the error handling routine corresponding to the identifier of the runtime object is selected and executed.
  • this identifier can already be defined during the programming of the runtime object or during the installation of the runtime object on the computer system. This can already during the programming of the computer system or during the installation of the computer program on the computer system in the event of an occurring
  • Error to be performed error handling routine to be determined.
  • a runtime object that relates to a security-relevant and / or time-critical function can be assigned a different identifier than a runtime object that relates to a non-real-time function. This allows a very flexible treatment of errors occurring different maturity objects.
  • the error handling routine is additionally dependent on the.
  • Error detection unit generated error detection signal selected.
  • the error detection unit can determine, for example, whether it is a hardware error or a software error, or which hardware unit (processor, bus system, memory, etc.) has triggered the error. Furthermore, it is possible for the error detection unit to determine whether the error that has occurred is more of a permanent error or a transient error. For this purpose, the error detection unit for each runtime object provide a counter that counts the number of errors occurred. If a large number of errors occur during the execution of a specific runtime object, then the error detection unit can switch to a permanent runtime
  • the error detection signal contains information about a determined size, For example, the current count of the number of errors encountered during execution of the runtime object includes. This allows a particularly flexible selection of an error handling routine.
  • the computer system comprises a plurality of arithmetic units
  • the arithmetic unit on which the runtime object was executed and the error occurred can be identified on the basis of the error detection signal. If one and the same runtime object runs, for example, on a plurality of different arithmetic units and these arithmetic units are assigned to different environments of different security relevance, then different error handling routines can be selected in the event of an error occurring during the execution of the runtime object, depending on which arithmetic unit the runtime object was executed, although Runtime object is always assigned the same identifier.
  • error handling can provide, for example, the result that is made available by the arithmetic unit on which the error occurred during further processing (for example, during a voting to be subsequently performed). to ignore.
  • the error handling is carried out as a function of at least one variable characterizing the executed runtime object and / or the execution of the runtime object.
  • a size may for example be a priority assigned to the runtime object. That's it possible to perform an error handling additionally depending on the priority of the executed runtime object.
  • a variable characterizing the execution of the run-time object can also designate the execution time that has already taken place or that is still available. 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 to be processed urgently, it can be provided that
  • Runtime object during which the error occurred simply terminate.
  • the computer system comprises a plurality of arithmetic units.
  • the runtime object is executed redundantly on at least two of the arithmetic units.
  • a comparison of the redundantly generated results of the at least two arithmetic units is performed and an error detection signal is generated if the results do not match.
  • a computer system comprising several computing units is referred to, for example, as a dual-core architecture (two computing units) or as a multi-processor architecture (multiple computing units).
  • a particularly flexible error handling can be carried out in particular in the redundant execution of runtime objects.
  • the method in a motor vehicle, in particular in a
  • Motor vehicle control unit or used in a safety-related system.
  • Security-relevant systems are used, for example, for controlling aircraft. In these areas, it is particularly important to treat transient errors systematically and flexibly and thus to achieve the highest possible availability of the corresponding system.
  • At least one of the error handling routines realizes in the predeterminable amount of
  • Error handling routines one of the following error handling options:
  • the execution of the runtime object is aborted and, for example, another runtime object is executed instead. - Abort the execution of the runtime object and ban a new one
  • Reset The entire computer system or a subsystem is restarted.
  • 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 can simply be ignored or handled by means of forward recovery.
  • a hardware test is performed by means of a test routine.
  • the error detection signal is then generated as a function of the result of the execution of the test routine. This makes it possible, for example, to detect a hardware defect particularly reliably and thus to deduce a permanent error.
  • different identifiers are assigned to the runtime object for different error types. For example, if a permanent error is detected during the execution of a runtime object, a different error handler may be selected than if during the runtime
  • the runtime object can be assigned different identifiers for different runtime environments.
  • a runtime object may be assigned an identifier for execution in a security-relevant environment, another identifier for redundant execution on a redundant processor, and another identifier for execution in a time-critical environment.
  • This embodiment enables a more flexible treatment of an error that has occurred during the execution of a runtime object and can increase the availability even further.
  • the object is also achieved by a computer system of the type mentioned above in that the runtime object is assigned an identifier and, depending on the identifier, an executable error handling routine can be selected from a predefinable set of error handling routines.
  • the computer program on a computer system, in particular on a computing device, executable and programmed to carry out the method according to the invention erf programmiertndungswashen.
  • the invention is realized by the computer program, so that the computer program represents in the same way the invention as the method which the computer program is suitable for executing.
  • the computer program is preferably stored on a machine-readable data carrier.
  • a machine-readable medium for example, a random access memory, a read-only memory, a
  • Flash memory a digital versatile disc or a compact disc are used.
  • Figure 1 is a schematic representation of components of a
  • FIG. 2 shows a flow diagram for a schematic representation of the method according to the invention in a first embodiment
  • FIG. 3 shows a flow chart for a schematic representation of the method according to the invention in a second embodiment.
  • FIG. 1 shows a computer system 1 is shown schematically, the
  • the computer system 1 has two arithmetic units 2, 3.
  • the arithmetic units can be, for example, complete processors (CPUs) (so-called dual-core architecture).
  • the dual-core architecture makes it possible to operate the two arithmetic units 2, 3 in such a redundant manner that a process or a runtime object is executed almost simultaneously on both arithmetic units 2, 3.
  • the arithmetic units 2, 3 can also be arithmetic logic units, so-called arithmetic local units (ALUs) (dual ALU architecture).
  • ALUs arithmetic local units
  • 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 which run-time object is 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 executable runtime object the identifier assigned to this runtime object or the identifiers associated with this runtime object. 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 assigned, for example, to the arithmetic unit 2 or the arithmetic unit 3
  • Be memory or a cache Be memory or a cache.
  • the computer system 1 could have only one computing unit.
  • An error in the execution 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 one another, conclude the presence of an error.
  • the computer system 1 has more than two arithmetic units 2, 3.
  • a runtime object could then be executed redundantly, for example, on three of the existing computing units 2, 3. By comparing the results thus obtained, the error detection unit could
  • step 100 the scheduler 7 initiates the arithmetic units 2, 3
  • Runtime object from the program memory 4 read and execute.
  • 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. If there is no error, the method branches back to step 101 and a further run-time object is executed in the arithmetic units 2, 3.
  • an error detection signal is generated by the error detection unit in step 103 and transmitted to the operating system 6 via the interface 8.
  • a step 104 the operating system 6 determines the faulty runtime object. This information can be obtained, for example, from the scheduler 7.
  • a step 105 the identifier assigned to the runtime object determined in step 104 is determined.
  • a table can be stored, in which for each extendable runtime object the identifier assigned to this is stored.
  • the identification associated with the runtime object is stored together with the runtime object itself in the program memory 4. If a run-time object is loaded for execution in the arithmetic unit 2, 3, it can be provided that the identifier is stored in a memory area, for example a register, allocated to the respective arithmetic unit 2, 3. In this case, the operating system 6 could request the identifier of the runtime object from the respective computing unit 2, 3.
  • the error detection unit determines the identifier associated with the runtime object and makes it available to the operating system via the interface 8 together with the error detection signal, for example as a parameter.
  • an error handling routine is selected as a function of the error detection signal and the identifier associated with the runtime object.
  • the identification associated with the runtime object can uniquely determine the error handling routine to be selected. 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 you want to jump back to a given checkpoint and from there the runtime object should be executed again (backward recovery). The identifier may further determine that a forward recovery is performed, the execution of the runtime object is repeated, or no further error handling is to be performed.
  • Operating system 6 transmitted error detection signal information can be found in terms of the type of error occurred. For example, this type can indicate whether it is transient or permanent.
  • the error signal can also be configured such that information about it can be found on which the
  • Arithmetic units 2, 3 the error has occurred.
  • several identifiers can be assigned to the runtime object.
  • a first identifier can describe the error handling routine to be executed when the permanent error occurs.
  • a second identifier is the one to be executed when a transient error occurs
  • the computer system 1 is designed as a multi-processor system or as a multi-ALU system, it may be advantageous to select the
  • Error handling routine depending on whether the runtime object has occurred on one or more of the processors or the ALUs. This information could, for example, be taken from the error detection signal.
  • the runtime object could in this case have different identifiers for the cases that the runtime object is executed on only one arithmetic unit 2, 3 and that the runtime object on several arithmetic units 2, 3 is executed incorrectly.
  • the error handling is performed in which the error handling routine selected by the operating system 6 is executed. Depending on the selected error handling routine, for example, the operating system may cause the scheduler 7 to abort all the runtime objects currently executing on the arithmetic units 2, 3
  • a step 108 the inventive method for error treatment ends.
  • the processing of a program with sequential execution of run-time objects shown in FIG. 2 and subsequent checking for the presence of an error at this point is not necessarily also terminated. if the
  • step 108 If the execution of the program has not yet ended when step 108 has been reached, it is possible to return to step 101 (dashed line).
  • 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.
  • a variable characterizing the runtime object or the execution of 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.
  • 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 Runtime objects that depend on the sizes of the runtime object. Thus dependencies of the runtime objects could be described among each other.
  • variable characterizing an execution of a runtime object can describe, for example, 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 required and / or how large the for a runtime object nor for
  • Is available time span Is available time span. These quantities can then be taken into account in a selection of the error handling routine. For example, if there is not enough time to rerun the entire runtime object, it may be scheduled to perform backward recovery or forward recovery.
  • a step 207 it is determined whether there is a permanent or a transient error. For example, error counters that indicate how frequently an error occurs when a particular runtime object is executed can be included. If this happens particularly frequently or always, a permanent error can be assumed.
  • Steps 206 and 207 are initially independent of each other and can be performed individually. A version in reverse order is possible.
  • the variable determined in step 206 and characterizing the runtime object or the execution of the runtime object is used as an input value for determining the type of fault in step 207.
  • the two steps 206 and 207 in the be processed in the specified order.
  • steps 206 and 207 do not necessarily have to be executed sequentially; they can also be processed in parallel.
  • Computer system 1 that is, for example, a computing unit 2, 3 to assign an error counter. If, for example, it is determined that the execution of especially many runtime objects is faulty on a computer unit 2, 3 of the computer system 1, then the existence of a permanent error (eg a hardware error) can be inferred.
  • a permanent error eg a hardware error
  • an error handling routine is selected.
  • the variables ascertained in steps 205 to 207 in particular one or more identifiers associated with the erroneous runtime object, one or more of the runtime object or the execution of the
  • the error handling routine is selected by the operating system 6, for example.
  • the selection can by means of the aforementioned sizes in a kind
  • a step 209 the error handling is performed and in a step 210 the method according to the invention for error handling is ended.
  • the processing of a program shown in FIG. 3 is sequential
  • step 210 Execution of runtime objects and subsequent check for the presence of an error at this point is not necessarily terminated. if the If the execution of the program has not yet ended when step 210 has been reached, it is possible to return to step 201 (dashed line).
  • 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 which is 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 can from the information, whether the considered
  • Runtime object on only one of the arithmetic units 2, 3 or on both arithmetic units 2, 3 was processed simultaneously / will be closed to the safety relevance of the runtime object at the current processing time. Furthermore, it is possible to provide further information of the computer system and / or the periphery (eg current value range of
  • Error handling routine causes re-execution of the faulty runtime object again leads to an error.
  • it could be provided to again select an error handling routine, but this time a different one. For example, it may be provided in this case to switch off the entire system or a subsystem.

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)
  • Storage Device Security (AREA)

Abstract

Bei der Ausführung eines mindestens ein Laufzeitobjekt umfassenden Computerprogramms, das auf einem Computersystem (1) ausgeführt wird, können Fehler auftreten, die durch eine Fehlererkennungseinheit (5) erkannt werden können. Um einen erkannten Fehler besonders flexibel zu behandeln und das Computersystem (1) möglichst verfügbar zu halten wird vorgeschlagen, eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen in Abhängigkeit von einer dem Laufzeitobjekt zugeordneten Kennung auszuwählen und die ausgewählte Fehlerbehandlungsroutine auszuführen.

Description

Verfahren zur Abarbeitung eines Computerprograrnms 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 Ausiü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 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 Ausiü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 von Teilsy stemen. 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. - A -
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 eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen in Abhängigkeit von einer dem Laufzeitobjekt zugeordneten Kennung ausgewählt wird und die ausgewählte
Behandlungsroutine ausgeführt wird.
Vorteile der Erfindung
Erfindungsgemäß ist einem oder mehreren Laufzeitobjekten, die auf dem Computersystem ausgeführt werden, eine Kennung zugeordnet, die wiederum mindestens eine Fehlerbehandlungsroutine bezeichnet. Tritt während der Ausiührung des Laufzeitobjekts ein Fehler auf, so wird die der Kennung des Laufzeitobjekts entsprechende Fehlerbehandlungsroutine ausgewählt und durchgeführt. Diese Kennung kann beispielsweise bereits bei der Programmierung des Laufzeitobjekts beziehungsweise bei der Installation des Laufzeitobjekts auf dem Computersystem festgelegt werden. Damit kann bereits während der Programmierung des Computersystems bzw. bei der Installation des Computerprogramms auf dem Computersystem die im Falle eines auftretenden
Fehlers durchzuführende Fehlerbehandlungsroutine bestimmt werden. Beispielsweise kann einem Laufzeitobjekt, das eine sicherheitsrelevante und/oder zeitkritische Funktion betrifft, eine andere Kennung zugeordneten werden als einem Laufzeitobjekt, das eine nicht-echtzeitiahige Funktion betrifft. Dies ermöglicht eine sehr flexible Behandlung auftretender Fehler unterschiedlicher Laufzeitobjekte.
Insbesondere kann mit dem erfindungsgemäßen Verfahren erreicht werden, dass nicht stets ein Teilsystem oder gar das gesamte Computersystem neu gestartet werden muss, wenn bei der Abarbeitung eines Laufzeitobjekts ein Fehler auftritt. Vielmehr ist eine flexible Auswahl eines Fehlerbehandlungsmechanismus möglich. Damit kann die Verfügbarkeit des Gesamtsystems deutlich gesteigert werden.
Gemäß einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens wird die Fehlerbehandlungsroutine zusätzlich in Abhängigkeit von dem durch die
Fehlererkennungseinheit erzeugten Fehlererkennungssignal ausgewählt. Die Fehlererkennungseinheit kann beispielsweise feststellen, ob es sich um einen Hardware-Fehler oder um einen Software-Fehler handelt, bzw. welche Hardwareeinheit (Prozessor, Bussystem, Speicher, etc.) den Fehler ausgelöst hat. Ferner ist es möglich, dass die Fehlererkennungseinheit feststellt, ob es sich bei dem aufgetretenen Fehler eher um einen permanenten Fehler oder um einen transienten Fehler handelt. Dazu kann die Fehlererkennungseinheit für jedes Laufzeitobjekt einen Zähler vorsehen, der die Anzahl aufgetretenen Fehler zählt. Treten besonders viele Fehler bei der Ausführung eines bestimmten Laufzeitobjekts auf, so kann die Fehlererkennungseinheit auf einen permanenten
Fehler schließen und ein anderes Fehlererkennungssignal erzeugen, als wenn der Zähler nur einen sehr niedrigen Wert aufweist. Insbesondere ist es vorstellbar, dass das Fehlererkennungssignal eine Information über eine ermittelte Größe, beispielsweise den aktuellen Zählerstand der Anzahl der bei der Abarbeitung des Laufzeitobjekts bisher aufgetretenen Fehler, beinhaltet. Dies ermöglicht eine besonders flexible Auswahl einer Fehlerbehandlungsroutine.
Umfasst das Computersystem beispielsweise mehrere Recheneinheiten, kann vorgesehen sein, dass anhand des Fehlererkennungssignals diejenige Recheneinheit identifizierbar ist, auf der das Laufzeitobjekt ausgeführt wurde und der Fehler auftrat. Läuft ein und dasselbe Laufzeitobjekt beispielsweise auf mehreren unterschiedlichen Recheneinheiten ab und sind diese Recheneinheiten unterschiedlichen Umgebungen von unterschiedlicher Sicherheitsrelevanz zugeordnet, so können unterschiedliche Fehlerbehandlungsroutinen bei einem aufgetretenen Fehler während der Abarbeitung des Laufzeitobjekts ausgewählt werden, je nachdem, aufweicher Recheneinheit das Laufzeitobjekt ausgeführt wurde, obwohl dem Laufzeitobjekt stets dieselbe Kennung zugeordnet ist.
Sind mehrere Recheneinheiten redundant ausgelegt und wird das Laufzeitobjekt redundant auf diesen Recheneinheiten ausgeführt, kann eine Fehlerbehandlung beispielsweise vorsehen, das Ergebnis, das von derjenigen Recheneinheit zur Verfügung gestellt wird, auf der der Fehler auftrat, bei der Weiterbehandlung (beispielsweise bei einem anschließend durchzuführenden Voting) zu ignorieren.
Damit wird eine noch flexiblere Behandlung von aufgetretenen Fehlern ermöglicht.
Vorteilhafterweise wird die Fehlerbehandlung in Abhängigkeit von mindestens einer das ausgeführte Laufzeitobjekt und/oder die Ausführung des Laufzeitobjekts charakterisierenden Größe durchgeführt. 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.
Eine die Ausführung des Laufzeitobjekts charakterisierende Größe kann auch die bereits erfolgte oder die noch zur Verfügung stehende Abarbeitungsdauer 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 oder ein
Speicherzugriff erfolgt ist. Die Auswahl der Fehlerbehandlungsroutine kann dies dann berücksichtigen.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens umfasst das Computersystem mehrere Recheneinheiten. Das Laufzeitobjekt wird auf mindestens zwei der Recheneinheiten redundant ausgeführt. Ein Vergleich der redundant erzeugten Ergebnisse der mindestens zwei Recheneinheiten wird durchgeführt und ein Fehlererkennungssignal wird erzeugt, wenn die Ergebnisse nicht übereinstimmen.
Ein mehrere Recheneinheiten umfassendes Computersystem wird beispielsweise als Dual-Core- Architektur (zwei Recheneinheiten) oder als Multi-Prozessor- Architektur (mehrere Recheneinheiten) bezeichnet. Mittels des erfindungsgemäßen Verfahrens kann insbesondere bei der redundanten Abarbeitung von Laufzeitobjekten eine besonders flexible Fehlerbehandlung durchgeführt werden.
Vorzugsweise wird das Verfahren in einem Kraftfahrzeug, insbesondere in einem
Kraftiahrzeugsteuergerät, oder in einem sicherheitsrelevanten System eingesetzt. Sicherheitsrelevante Systeme werden beispielsweise zur Steuerung von Flugzeugen eingesetzt. In diesen Bereichen ist es besonders wichtig, transiente Fehler systematisch und flexibel zu behandeln und damit eine möglichst hohe Verfügbarkeit des entsprechenden Systems zu erreichen.
Vorteilhafterweise läuft auf mindestens einer Recheneinheit des Computersystems ein Betriebssystem ab, wobei die Auswertung der Kennung und/oder die Auswertung des Fehlererkennungssignals und/oder die Auswahl der Fehlerbehandlungsroutine durch das Betriebssystem erfolgt. Dies ermöglicht eine besonders schnelle und sichere Bearbeitung von erkannten Fehlern, da Betriebssysteme üblicherweise auf die zur Behandlung von aufgetretenen Fehlern notwendigen Ressourcen Zugriff haben. Beispielsweise weisen Betriebssysteme 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.
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 bzw. das Laufzeitobjekt wird neu initialisiert und mit aktuellen Eingangsdaten gestartet.
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 einfach ignoriert werden oder mittels eines Forward-Recovery behandelt werden.
Vorteilhafterweise wird mittels einer Testroutine ein Hardware-Test durchgeführt. Das Fehlererkennungssignal wird dann in Abhängigkeit des Ergebnisses der Abarbeitung der Testroutine erzeugt. Damit kann beispielsweise besonders zuverlässig ein Hardwaredefekt erkannt werden und somit auf einen permanenten Fehler geschlossen werden.
In einer bevorzugten Ausführungsform sind dem Laufzeitobjekt für verschiedene Fehlerarten unterschiedliche Kennungen zugeordnet. Wird beispielsweise ein permanenter Fehler während der Abarbeitung eines Laufzeitobjekts erkannt, kann eine andere Fehlerbehandlungsroutine ausgewählt werden als wenn während der
Abarbeitung des Laufzeitobjekts ein transienter Fehler auftritt.
Ferner können dem Laufzeitobjekt unterschiedliche Kennungen für unterschiedliche Laufzeitumgebungen zugeordnet sein. Beispielsweise kann einem Laufzeitobjekt eine Kennung für eine Abarbeitung in einer sicherheitsrelevanten Umgebung, eine andere Kennung für eine redundante Abarbeitung auf einer redundant ausgelegten Recheneinheit, sowie noch eine andere Kennung für eine Abarbeitung in einer zeit-kritischen Umgebung zugeordnet sein. Diese Ausführungsform ermöglicht eine nochmals flexiblere Behandlung eines bei der Abarbeitung eines Laufzeitobjekts aufgetretenen Fehlers und kann die Verfügbarkeit nochmals erhöhen. Die Aufgabe wird auch durch ein Computersystem der eingangs genannten Art dadurch gelöst, dass dem Laufzeitobjekt eine Kennung zugeordnet ist und in Abhängigkeit von der Kennung eine ausführbare Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen auswählbar ist.
Von besonderer Bedeutung ist die Realisierung des erfindungsgemäßen Verfahrens in der Form eines Computerprogramms. Dabei ist das Computerprogramm auf einem Computersystem, insbesondere auf einem Rechengerät, ablauffähig und zur Ausführung des erfϊndungsgemäßen Verfahrens programmiert. In diesem Fall wird die Erfindung durch das Computerprogramm realisiert, so dass das Computerprogramm in gleicher Weise die Erfindung darstellt wie das Verfahren, zu dessen Ausführung das Computerprogramm geeignet ist. Das 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- Versatile-Disc oder eine Compact-Disc zum Einsatz kommen.
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 Ausführungsform;
Figur 3 ein Ablaufdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens in einer zweiten Ausführungsform.
Beschreibung der Ausführungsbeispiele
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 können beispielsweise vollständige Prozessoren (CPUs) sein (sogenannte Dual- Core- Architektur). Die Dual-Core-Architektur ermöglicht es, die beiden Recheneinheiten 2, 3 derart redundant zu betreiben, dass ein Prozess beziehungsweise ein Laufzeitobjekt auf beiden Recheneinheiten 2, 3 nahezu gleichzeitig ausgeführt wird. Die Recheneinheiten 2, 3 können auch arithmetisch¬ logische Einheiten, sogenannte arithmetic locial units (ALUs) sein (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 welches Laufzeitobjekt auf den 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 ausführbare Laufzeitobjekt die diesem Laufzeitobjekt zugeordnete Kennung bzw. die diesem Laufzeitobjekt 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.
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üfungen 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 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.
In Figur 2 ist ein Ablaufdiagramm des erfϊndungsgemäß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. Liegt kein Fehler vor, so wird zu dem Schritt 101 zurückverzweigt und ein weiteres Laufzeitobjekt 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 ein Fehlererkennungssignal erzeugt und an das Betriebssystem 6 über das Interface 8 übermittelt.
In einem Schritt 104 ermittelt das Betriebssystem 6 das fehlerhafte Laufzeitobjekt. Diese Information kann beispielsweise von dem Scheduler 7 erhalten werden.
In einem Schritt 105 wird die dem in dem Schritt 104 ermittelten Laufzeitobjekt zugeordnete Kennung ermittelt. Dazu kann beispielsweise in dem Speicherbereich 9 eine Tabelle abgelegt sein, in der zu jedem ausfahrbaren Laufzeitobjekt die diesem zugeordnete Kennung abgespeichert ist.
Es ist ferner möglich, dass die dem Laufzeitobjekt zugeordnete Kennung zusammen mit dem Laufzeitobjekt selbst in dem Programmspeicher 4 abgespeichert ist. Wird ein Laufzeitobjekt zur Ausführung in dem Recheneinheit 2, 3 geladen, kann vorgesehen sein, dass die Kennung in einem dem jeweiligen Recheneinheit 2, 3 zugeordneten Speicherbereich, beispielsweise einem Register, abgelegt wird. In diesem Fall könnte das Betriebssystem 6 von der jeweiligen Recheneinheit 2, 3 die Kennung des Laufzeitobjekts anfordern.
Es ist auch vorstellbar, dass die Fehlererkennungseinheit die dem Laufzeitobjekt zugeordnete Kennung ermittelt und zusammen mit dem Fehlererkennungssignal, beispielsweise als Parameter, dem Betriebssystem über die Schnittstelle 8 zur Verfügung stellt.
In einem Schritt 106 wird in Abhängigkeit von dem Fehlererkennungssignal und der dem Laufzeitobjekt zugeordneten Kennung eine Fehlerbehandlungsroutine ausgewählt. Dabei kann die dem Laufzeitobjekt zugeordnete Kennung die auszuwählende Fehlerbehandlungsroutine eindeutig bestimmten. 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.
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. Das Fehlersignal kann ferner derart ausgestaltet sein, dass diesem eine Information darüber zu entnehmen ist, auf welchem der
Recheneinheiten 2, 3 der Fehler aufgetreten ist. 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 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 das Laufzeitobjekt auf einem oder mehreren der Prozessoren beziehungsweise der ALUs aufgetreten ist. Diese Information könnte beispielsweise dem Fehlererkennungssignal entnommen werden. Das Laufzeitobjekt könnte hierbei unterschiedliche Kennungen für die Fälle aufweisen, dass das Laufzeitobjekt auf nur eine Recheneinheit 2, 3 und dass das Laufzeitobjekt auf mehreren Recheneinheiten 2, 3 fehlerhaft ausgeführt wird. 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 erfindungsgemäße Verfahren zur Fehlerbehandlung. Allerdings ist die in Figur 2 dargestellte Abarbeitung eines Programms mit sequentieller Ausführung von Laufzeitobjekten und anschließender Überprüfung auf Vorliegen eines Fehlers an dieser Stelle nicht zwangsläufig ebenfalls beendet. Falls die
Abarbeitung des Programms beim Erreichen des Schritts 108 noch nicht beendet ist, kann zu Schritt 101 rückgesprungen werden (gestrichelte Linie).
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 beispielsweise 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. Diese Größen können dann bei einer Auswahl der Fehlerbehandlungsroutine berücksichtigt werden. Steht beispielsweise nicht mehr genug Zeit zur Verfügung, das gesamte Laufzeitobjekt erneut auszuführen, kann vorgesehene sein, ein Backward-Recovery oder ein Forward-Recovery durchzuführen.
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.
Die Schritte 206 und 207 sind zunächst voneinander unabhängig und können jeweils einzeln ausgeführt werden. Auch eine Ausführung in umgekehrter Reihenfolge ist jedoch möglich. Außerdem ist es denkbar, dass die in Schritt 206 ermittelte, das Laufzeitobjekt oder die Ausführung des Laufzeitobjektes charakterisierende Größe als Eingangswert zur Ermittlung der Fehlerart in Schritt 207 verwendet wird. In diesem Fall müssen die beiden Schritte 206 und 207 in der angegebenen Reihenfolge abgearbeitet werden. Schließlich müssen die Schritte 206 und 207 nicht notwendigerweise sequenziell abgearbeitet werden; sie können auch parallel abgearbeitet werden.
Es ist des weiteren möglich, einer einzelnen Hardwareeinheit des
Computersystems 1, also beispielsweise einer Recheneinheit 2, 3, einen Fehlerzähler zuzuordnen. Wird beispielsweise festgestellt, dass auf einer Recheneinheit 2, 3 des Computersystems 1 die Ausführung besonders vieler Laufzeitobjekte fehlerhaft ist, so kann auf das Vorhandensein eines permanenten Fehlers (z. B. eines Hardware-Fehlers) 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 Laufzeitobjekt zugeordneten Kennungen, eine oder mehrere das Laufzeitobjekt beziehungsweise die Ausführung des
Laufzeitobjekts charakterisierende Größen 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 erfindungsgemäße Verfahren zur Fehlerbehandlung beendet. Allerdings ist die in Figur 3 dargestellte Abarbeitung eines Programms mit sequentieller
Ausiührung von Laufzeitobjekten und anschließender Überprüfung auf Vorliegen eines Fehlers an dieser Stelle nicht zwangsläufig ebenfalls beendet. Falls die Abarbeitung des Programms beim Erreichen des Schritts 210 noch nicht beendet ist, kann zu Schritt 201 rückgesprungen werden (gestrichelte Linie).
Mit dem erfindungsgemäßen Verfahren ist es folglich möglich, bereits bei der Programmierung beziehungsweise der Implementierung oder der Installation eines Laufzeitobjekts auf dem Computersystem festzulegen, welche Fehlerbehandlungsroutine bei Auftreten eines Fehlers ausgeführt werden soll. Dies ermöglicht eine besonders flexible und dem ausgeführten Laufzeitobjekt angepasste Fehlerbehandlung. Insbesondere können erfindungsgemäß einem Laufzeitobjekt mehrere Kennungen zugeordnete 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. Dabei kann aus der Information, ob das betrachtete
Laufzeitobjekt auf nur einer der Recheneinheiten 2, 3 oder auf beiden Recheneinheiten 2, 3 gleichzeitig abgearbeitet wurde/ wird, auf die Sicherheitsrelevanz des Laufzeitobjekts zum momentanen Abarbeitungszeitpunkt geschlossen werden. Weiterhin ist es möglich, weitere Informationen des Computersystems und/ oder der Peripherie (z. B. aktueller Wertebereich von
Sensorgrößen und/ oder Wertebereich der Ausgangsgrößen) des Computersystems zur Einschätzung der momentanen Sicherheitsrelevanz der Laufzeitumgebung heranzuziehen. Damit ist eine noch flexiblere Fehlerbehandlung auf einem Computersystem 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 des fehlerhaften Laufzeitobjekts 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.

Claims

22.09.2004Robert Bosch GmbH, 70442 StuttgartAnsprüche
1. Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem (1), das mindestens eine Recheneinheit (2, 3) umfasst, wobei das Computerprogramm mindestens ein Laufzeitobjekt umfasst, wobei ein während der Ausführung des Laufzeitobjekts auftretender Fehler durch eine
Fehlererkennungseinheit (5) erkannt wird und wobei die Fehlererkennungseinheit (5) bei einem erkannten Fehler ein Fehlererkennungssignal erzeugt, dadurch gekennzeichnet, dass eine Fehlerbehandlungsroutine aus einer vorgebbaren Menge von Fehlerbehandlungsroutinen in Abhängigkeit von einer dem Laufzeitobjekt zugeordneten Kennung ausgewählt wird und die ausgewählte
Fehlerbehandlungsroutine ausgeführt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Fehlerbehandlungsroutine zusätzlich in Abhängigkeit von dem Fehlererkennungssignal ausgewählt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die
Fehlerbehandlung in Abhängigkeit von mindestens einer das ausgeführte Laufzeitobjekt und/oder die Ausführung des Laufzeitobjekts charakterisierenden Größe durchgeführt wird.
4. 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) redundant ausgeführt wird, ein Vergleich der redundant erzeugten Ergebnisse der mindestens zwei Recheneinheiten (2, 3) durchgeführt wird und ein Fehlererkennungssignal erzeugt wird, wenn die Ergebnisse nicht übereinstimmen.
5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, verwendet wird.
6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren in einem sicherheitsrelevanten System eingesetzt wird.
7. 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 Auswertung der Kennung und/oder die Auswertung des Fehlererkennungssignals und/oder die Auswahl der Fehlerbehandlungsroutine durch das Betriebssystem (6) erfolgt.
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 mittels einer Testroutine ein Hardware-Test durchgeführt wird und das Fehlererkennungssignal in Abhängigkeit des Ergebnisses
Abarbeitung der Testroutine erzeugt wird.
12. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass dem Laufzeitobjekt für verschiedene Fehlerarten und/oder für unterschiedliche Laufzeitumgebungen unterschiedliche Kennungen zugeordnet sind.
13. Computerprogramm, das auf einem Computersystem (1) ablauffähig ist, dadurch gekennzeichnet, dass das Computerprogramm ein Verfahren nach einem der Ansprüche 1 bis 12 ausfuhrt, wenn es auf dem Computersystem (1) abläuft.
14. Computerprogramm nach Anspruch 13, dadurch gekennzeichnet, dass das Computerprogramm als Betriebssystem (6) ausgebildet ist.
15. Maschinenlesbarer Datenträger, auf dem ein Computerprogramm abgespeichert ist, wobei das Computerprogramm auf einem Computersystem (1) ausführbar ist, dadurch gekennzeichnet, dass das Computerprogramm ein Verfahren nach einem der Ansprüche 1 bis 12 ausführt, wenn es auf dem Computersystem (1) abgearbeitet wird.
16. Computersystem (1 ), auf dem ein Computerprogramm ausführbar ist, das mindestens ein Laufzeitobjekt umfasst und bei dem ein während der Ausführung des Laufzeitobjekts auftretender Fehler durch eine Fehlererkennungseinheit (5) erkennbar ist, dadurch gekennzeichnet, dass dem Laufzeitobjekt eine Kennung zugeordnet ist und in Abhängigkeit von der Kennung eine ausführbare Fehlerbehandlungsroutine aus einer vorgebbaren Menge von
Fehlerbehandlungsroutinen auswählbar ist.
17. Computersystem (1) nach Anspruch 16, dadurch gekennzeichnet, dass das Computersystem (1) ein Computerprogramm zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 12 aufweist.
EP05784608A 2004-09-25 2005-09-12 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem Withdrawn EP1794680A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004046611A DE102004046611A1 (de) 2004-09-25 2004-09-25 Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem
PCT/EP2005/054513 WO2006032617A1 (de) 2004-09-25 2005-09-12 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem

Publications (1)

Publication Number Publication Date
EP1794680A1 true EP1794680A1 (de) 2007-06-13

Family

ID=35447817

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05784608A Withdrawn EP1794680A1 (de) 2004-09-25 2005-09-12 Verfahren zur abarbeitung eines computerprogramms auf einem computersystem

Country Status (6)

Country Link
US (1) US8316261B2 (de)
EP (1) EP1794680A1 (de)
JP (1) JP4903149B2 (de)
CN (1) CN101027647B (de)
DE (1) DE102004046611A1 (de)
WO (1) WO2006032617A1 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070294584A1 (en) * 2006-04-28 2007-12-20 Microsoft Corporation Detection and isolation of data items causing computer process crashes
US20090024870A1 (en) * 2007-07-20 2009-01-22 Telefonaktiebolaget Lm Ericsson System and method for managing application server responses in ip multimedia subsystem
DE102007056218A1 (de) * 2007-11-22 2009-05-28 Robert Bosch Gmbh Verfahren zur Behandlung von transienten Fehlern in Echtzeitsystemen, insbesondere in Steuergeräten von Kraftfahrzeugen
DE102009030774B4 (de) * 2009-06-27 2020-01-30 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur rechnergestützten Erfassung von Fehlern beim Ablauf von einem oder mehreren softwarebasierten Programmen in einem System aus Komponenten
WO2013073761A1 (ko) * 2011-11-14 2013-05-23 (주)네오위즈게임즈 비정상 종료 처리 방법, 이를 수행하는 비정상 종료 처리 서버 및 이를 저장한 기록 매체
DE102013208666A1 (de) 2013-05-13 2014-11-13 Zf Friedrichshafen Ag Verfahren und Vorrichtung zur Absicherung eines Errorhandlers für eine Abarbeitung eines Computerprogramms auf einem Rechnersystem
DE102015222168B4 (de) 2015-11-11 2024-02-22 Kuka Roboter Gmbh Verfahren und computerprogramm zur korrektur von fehlern eines manipulatorsystems
DE102015222164A1 (de) 2015-11-11 2017-05-11 Kuka Roboter Gmbh Verfahren und Computerprogramm zur Erzeugung einer grafischen Benutzerschnittstelle eines Manipulatorprogramms
US10216521B2 (en) * 2017-06-20 2019-02-26 Nvidia Corporation Error mitigation for resilient algorithms
KR102259928B1 (ko) * 2017-06-26 2021-06-03 에스케이하이닉스 주식회사 오류 관리 시스템 및 이를 포함하는 데이터 처리 시스템
EP3765962A1 (de) 2018-03-12 2021-01-20 Celonis SE Verfahren zur behebung von prozessanomalien
CN116319269B (zh) * 2023-05-19 2023-09-15 南方电网数字电网研究院有限公司 具备通讯故障自检及快速隔离的新能源边缘侧通信模块

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6334193B1 (en) * 1997-05-29 2001-12-25 Oracle Corporation Method and apparatus for implementing user-definable error handling processes

Family Cites Families (28)

* 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
JP2779559B2 (ja) * 1991-09-04 1998-07-23 本田技研工業株式会社 レーダ装置
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
US5619409A (en) * 1995-06-12 1997-04-08 Allen-Bradley Company, Inc. Program analysis circuitry for multi-tasking industrial controller
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
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
CN1141644C (zh) * 1999-11-20 2004-03-10 深圳市中兴通讯股份有限公司 一种嵌入处理机内存的检测和监控方法
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 情報再生装置、情報処理方法及び情報記録媒体
DE10056408C1 (de) 2000-11-14 2002-03-07 Bosch Gmbh Robert Vorrichtung zur Überwachung eines Prozessors
WO2002052411A1 (en) * 2000-12-21 2002-07-04 Veritas Operating Corporation Computer software run-time analysis systems and methods
US6950978B2 (en) * 2001-03-29 2005-09-27 International Business Machines Corporation Method and apparatus for parity error recovery
US6931571B2 (en) * 2001-11-20 2005-08-16 Hewlett-Packard Development Company, L.P. Method and apparatus for handling transient memory errors
US7194671B2 (en) * 2001-12-31 2007-03-20 Intel Corporation Mechanism handling race conditions in FRC-enabled processors
US7418618B2 (en) * 2003-01-08 2008-08-26 Transpacific Ip Ltd. Error reporting and correcting method for peripheral
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
US7716652B2 (en) * 2004-03-30 2010-05-11 Symantec Corporation System and methods for tracing transactions
US7263631B2 (en) * 2004-08-13 2007-08-28 Seakr Engineering, Incorporated Soft error detection and recovery
DE102004046288A1 (de) 2004-09-24 2006-03-30 Robert Bosch Gmbh Verfahren zur Abarbeitung eines Computerprogramms auf einem Computersystem

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6334193B1 (en) * 1997-05-29 2001-12-25 Oracle Corporation Method and apparatus for implementing user-definable error handling processes

Also Published As

Publication number Publication date
US20080201618A1 (en) 2008-08-21
DE102004046611A1 (de) 2006-03-30
CN101027647B (zh) 2013-05-01
JP4903149B2 (ja) 2012-03-28
WO2006032617A1 (de) 2006-03-30
CN101027647A (zh) 2007-08-29
US8316261B2 (en) 2012-11-20
JP2008513900A (ja) 2008-05-01

Similar Documents

Publication Publication Date Title
EP1794680A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE102012109614B4 (de) Verfahren zum Wiederherstellen von Stapelüberlauf- oder Stapelunterlauffehlern in einer Softwareanwendung
DE69219657T2 (de) Fortsetzung der Aufgabe eines fehlerhaften Prozessors von einem alternativen Prozessor
EP1917592B1 (de) Rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit sowie verfahren zu dessen steuerung
WO2006032585A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE68924400T2 (de) Fliessbanddatenverarbeitungsvorrichtung.
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
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
EP1812853B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE69120104T2 (de) Fehlerbeseitigung für Superrechner
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
EP1915687A1 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems mit wenigstens zwei ausführungseinheiten
EP1461701B1 (de) Programmgesteuerte einheit mit überwachungseinrichtung
DE102009000874A1 (de) Verfahren zur Verbesserung der Analysierbarkeit von Softwarefehlern in einem Mikrocontroller
DE2240432C3 (de) Verfahren und Einrichtung zum Festlegen von Fixpunkten und zur Operationswiederholung ab dem letzten Fixpunkt in Datenverarbeitungsanlagen mit überlappter Arbeitsweise
DE102023202348A1 (de) Verfahren zum Testen eines Computerprogramms
DE10110050A1 (de) Verfahren zur Absicherung sicherheitskritischer Programmteile vor versehentlicher Ausführung und eine Speichereinrichtung zur Durchführung dieses Verfahrens
DE102015218386A1 (de) Verfahren und Vorrichtung zum Überwachen eines Programmflusses eines von einem Prozessor ausführbaren Programmes und Prozessoreinrichtung
EP1917594A2 (de) Verfahren und vorrichtung zur abarbeitung von datenwörtern und/oder instruktionen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070425

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090304

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180404