WO2006015945A2 - Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms - Google Patents

Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms Download PDF

Info

Publication number
WO2006015945A2
WO2006015945A2 PCT/EP2005/053621 EP2005053621W WO2006015945A2 WO 2006015945 A2 WO2006015945 A2 WO 2006015945A2 EP 2005053621 W EP2005053621 W EP 2005053621W WO 2006015945 A2 WO2006015945 A2 WO 2006015945A2
Authority
WO
WIPO (PCT)
Prior art keywords
error
computing device
program
computer program
execution
Prior art date
Application number
PCT/EP2005/053621
Other languages
English (en)
French (fr)
Other versions
WO2006015945A3 (de
Inventor
Reinhard Weiberle
Bernd Mueller
Werner Harter
Thomas Kottke
Yorck Collani
Rainer Gmehlich
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 US11/659,307 priority Critical patent/US7890800B2/en
Priority to CN2005800262785A priority patent/CN1993679B/zh
Priority to EP05777777A priority patent/EP1854007A2/de
Priority to BRPI0513229-0A priority patent/BRPI0513229A/pt
Priority to JP2007524328A priority patent/JP4728334B2/ja
Publication of WO2006015945A2 publication Critical patent/WO2006015945A2/de
Publication of WO2006015945A3 publication Critical patent/WO2006015945A3/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/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
    • G06F11/1438—Restarting or rejuvenating
    • 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/1479—Generic software techniques for error detection or fault masking

Definitions

  • the present invention relates to a method for processing a computer program on a computing device, in particular on a microprocessor.
  • the computer program includes several program objects.
  • errors are detected during the execution of the computer program on the computing device.
  • the invention also relates to an operating system that is executable on a computing device, in particular on a microprocessor.
  • the present invention also relates to a computing device for processing a computer program comprising a plurality of program objects.
  • the computing device includes an error detection mechanism for detecting an error during execution of the computer program on the computing device.
  • transient errors are only temporary and usually disappear after some time. In the case of transient errors, only individual bits are wrong without the computing device per se being permanently damaged. Transient faults can have different causes, such as electromagnetic influences, alpha particles or neutrons.
  • Controller Area Network it is known to resend the erroneously transmitted data when detecting an error.
  • an error counter in communication systems, which is increased upon detection of an error, is lowered on correct transmission, and prevents transmission of data as soon as it exceeds a certain value.
  • an error treatment is essentially only for permanent errors.
  • a consideration of transient errors is limited to the incrementing and possibly decrementing of an error counter. This is stored in a memory and can off-line, that is, for example, as a motor vehicle control unit trained computing device during a
  • Error handling by means of an error counter therefore on the one hand does not allow any error handling within a short error tolerance time required in particular for security-relevant systems and on the other hand also no constructive error treatment in the sense that the computer program is again processed properly within the fault tolerance time.
  • the computer program is switched to an emergency mode after exceeding a certain value of the error counter.
  • the replacement values determined in this way are used for the further calculation.
  • the substitute values can be modeled based on other quantities.
  • the results calculated with the faulty part of the computer program can be rejected as faulty and replaced by standard values for further calculation intended for run-flat operation.
  • the known methods for handling a transient error of a computer program running on a computing device thus do not allow a systematic, constructive handling of the transient nature of most errors.
  • Processing a computer program on a computing device may not respond appropriately.
  • the present invention is based on the object, in the event of transient errors when working a computer program in a computer system to treat this constructive so that the full functionality and reliability of the computer system is restored within the shortest possible fault tolerance time.
  • the program object that is restarted does not have to be completely executed when the error was detected.
  • such program objects can also be restarted when an error occurs that has not yet been fully processed at the time of error detection, but whose execution has probably already begun.
  • at least one operating system object is executed again when a transient or a permanent error occurs.
  • the advantages over the Micro RoIlBack are, in particular, that the repetition of a program object can be realized with very little hardware support. At the most, additional storage space is required to store some information required for the re-execution of the program object (e.g., program object input variables).
  • the actual administration of the method according to the invention can be carried out by the operating system of the computing device. That is, the inventive method can be realized with conventional, commercially available processors, without the need for additional hardware. Of course, it is also possible to realize the inventive method with hardware support.
  • the error detection itself can be done by any method. Conceivable is the use of any type of error detection mechanism, the error during the Processing of the computer program (so-called concurrent checking) can detect. For example, in a dual-core architecture, the whole core of the computer is twofold. If the computer cores are operated in a lockstep mode, it can be compared for each instruction as to whether both computer cores provide the same results. A difference in the results can then certainly conclude an error.
  • This error detection mechanism thus detects errors in the processing of the program objects in real time. The same applies to error-detecting codes that are used throughout the processor architecture, or for duplicate subcomponents of the computing device. All of these error detection mechanisms have in common that they discover transient errors very quickly
  • an error handling mechanism that repeats the program object may be initiated. If at the renewed
  • the program objects are designed as runtime objects of the computer program (referred to below as tasks) and at least one task is executed again when a fault is detected.
  • a task is a typical OS-level object. The repetition of a task can be realized with minimal effort, if desired even purely software controlled.
  • a program object executed at the time of the detection of the error is restarted.
  • program objects can also be started and executed again, which were already completely processed at the time the error was detected.
  • At least one defined state of the program objects is generated and stored during the execution of the program objects, in particular at the beginning of the execution of the program objects. This can be done, for example, by storing the values of all variables relevant to the state of the program object.
  • a redundant additional computing device be used for the computing device on which the computer program with the several program objects is executed.
  • the inventive method in a motor vehicle in particular in a Motor vehicle control unit, used to ensure safe and reliable processing of the computer program despite unavoidable transient error when processing a computer program. This is especially for the execution of tax and / or
  • a permanent error be inferred if the same error occurs again in the re-execution of the at least one program object. It is also conceivable that a permanent error is only concluded when the error still occurs after a predefinable number of repetitions of the program object. In this case, even then a transient error is concluded even if it does not disappear after a third or later repetition of the program object.
  • important program objects can be repeated, for example, 3 times instead of only 2 times.
  • the number of repetitions of the at least one program object is limited to a predefinable value. This prevents the same program object from being repeated any number of times in the event of a permanent error.
  • the restriction of the number of repetitions of the at least one program object can be done, for example, by means of a counter or via time limits.
  • the number of repetitions of the at least one program object be dynamically limited to a predefinable value.
  • the number of repetitions of the at least one program object is dynamically limited to a predefinable value as a function of a remaining time remaining for a scheduling. In this way, for example, a first task and a second task can go through, while a third task can be repeated several times.
  • the values of the variables necessary for executing the program object or defining the state of the program object be stored during the execution of the computer program prior to the execution of a program object. According to this embodiment, therefore, the sizes of all program objects are stored.
  • a plurality of return points be created for a program object.
  • an error occurs, not the entire program object, but only a part of the program object has to be executed again. If an error occurs, it simply jumps to the previous return point up to which the execution of the program object was error-free. For example, in the case of error-free execution of the program object up to the nth return point, an error between this and the (n + l) -th return point can be jumped back to the nth return point. The program object is then processed again from the nth return point. This saves time.
  • at least one defined state is generated and stored during execution of the program object.
  • the operating system is executable on a computing device, in particular on a microprocessor, and for the execution of the inventive Procedure programmed when it runs on the calculator.
  • the invention is realized by the operating system, so that this operating system in the same way represents the invention as the method, the execution of which the operating system is suitable.
  • the operating system is preferably stored on a memory element and is transmitted to the computing device for processing.
  • an arbitrary data carrier or an electrical storage medium can be used as the storage element, for example a random access memory (RAM), a read-only memory (ROM) or a flash memory.
  • the computing device has an error handling mechanism which causes a re-execution of at least one program object upon detection of an error by the error detection mechanism.
  • the error handling mechanism has a trigger logic which, when a fault is detected, restarts the at least one program object.
  • a real-time operating system for example OSEK time
  • the computing device comprises a microprocessor.
  • Fig. 1 is a flowchart of an inventive
  • Fig. 2 shows an inventive computing device according to its preferred embodiment in a schematic representation.
  • the present invention relates to a method for processing a computer program on a computing device, in particular on a microprocessor.
  • the computer program comprises a plurality of program objects, which are preferably designed as tasks.
  • errors are detected during the execution of the computer program on the computing device.
  • the detected errors can be transient (ie transient) or permanent.
  • the transient errors can occur during the execution of a computer program on a computing device. Since the structures on the semiconductor devices (so-called chips) the computing devices are getting smaller, the clock rate of the signals but always larger and the voltages of the signals are getting lower and lower, occur during the processing of a computer program on a computing device more frequently transient errors. In contrast to permanent errors, they only appear temporarily and usually disappear after some time. In the case of transient errors, only individual bits are wrong without the computing device per se being permanently damaged. Transient faults can have different causes, such as electromagnetic influences, alpha particles or neutrons.
  • the method according to the invention allows treatment of a transient error of one on one Calculator running computer program with a systematic, constructive approach to the transient nature of most errors.
  • the existence of further tasks does not affect the basic process, so there is no need to consider it.
  • a task is handled according to the flow shown in FIG. 1, according to the invention, therefore, a plurality of tasks can also be handled.
  • a parallel error detection mechanism so-called concurrent checking. This can not be represented in a flow chart, but is inserted at the corresponding position as a serial block.
  • the inventive method begins in a function block 1.
  • the function block 1 is started with the execution of the task on the computing device; the task is called.
  • a function block 2 a return point is generated.
  • safe relevant task input variables that are sufficient to put the task into a defined state for a restart and to restart the task are stored in a memory element of the computing device.
  • all input variables of the task are stored.
  • Function block 3 then the task is processed further.
  • the processing can be done either to another return point or to the end of the task.
  • an error detection mechanism is executed.
  • the error detection can be done by any method.
  • the errors are detected during the processing of the computer program (so-called concurrent checking). For example, in a so-called dual-core architecture, the whole core of the computer is twofold. If the computer cores in a so-called Lockstep mode can be compared for each instruction whether both computer cores provide the same results. A difference in the results can then certainly conclude an error.
  • Such an error detection mechanism thus detects errors in the processing of the task in real time. The same applies to error-detecting codes that are used in the
  • Processor architecture can be used consistently or for duplicate subcomponents of the computing device.
  • error detection mechanisms are used which detect transient errors very quickly and provide an error signal when an error has been detected.
  • a branch is made to another query block 7, where the current value of an error counter logic is checked. If the error counter has not fallen below a predefinable counter reading (with a decrementing error counter) or exceeded (with an incrementing error counter), the task may have occurred during the execution of which the error has occurred, or may have a specific number of tasks that occurred before the error occurred of the error have been executed again. If it is possible to restart the execution of the task, a branch is made in a function block 8 in which the status of the error counter logic is updated with the information that another error has occurred
  • Function block 5 branches, where the task to be repeated partially, that is, for example, from an already processed return point, or as a whole, that is, the task is started again from the beginning, is again processed.
  • a branch is made to a function block 12 where, according to the current task status, a further return point is generated by defining and storing safe relevant task input variables which are sufficient to restart the task. From there, it is then branched again to the function block 3, where the task to be repeated is restarted and executed again either partially or as a whole.
  • a branch is made to a function block 10.
  • This task-dependent repeat value can be specified either individually for different tasks or individually for each task. In this way, it is possible, for example, for particularly important tasks to be repeated several times before a permanent one Error is reported. If the task-dependent repeat value is specified as 1, the task is repeated only once before a permanent error is detected. If the task-dependent repeat value is set to 2 or 3, the task is repeated 2 or 3 times before a permanent error is detected. In this case, the task has a longer time, or more runs, until the transient error no longer occurs. In the function block 10, a permanent error is detected and a corresponding one
  • This measure may be, for example, to convert the computer program into a limp home or initially do nothing and then terminate the flow of the computer program.
  • the method according to the invention does not necessarily have to include all the function and query blocks illustrated in FIG. 1 and explained above. Thus, for example, can be dispensed with the blocks 7 to 9, which the
  • Affect error counter logic Upon detection of an error, the task (s) to be restarted and executed would be repeated until the error no longer occurs. A permanent error would not be detected, so that function block 10 could be omitted. Alternatively, the task-dependent repeat value can be specified as 1, so that the function blocks 8 and 9 for updating the error counter could be omitted. Finally, it would also be possible to dispense with blocks 11 and 12 if only a single task with a single return point is executed.
  • FIG. 2 shows a computing device according to the invention for executing a computer program according to its preferred embodiment.
  • the computing device is in its Entity designated by the reference numeral 20.
  • the computing device comprises a memory element 21, which is designed, for example, as an electronic memory, in particular as a flash memory.
  • the computing device 20 includes a microprocessor 22, on which a computer program can be processed.
  • the computer program is stored on the electronic storage medium 21 and designated by the reference numeral 23.
  • the computer program is transmitted either as a whole or in sections, for example by command, via a data link 24 to the microprocessor 22.
  • the data connection 24 can be designed as one or more data lines or as a bus system for data transmission.
  • an operating system is also stored that is at least partially transferred from the memory 21 to the microprocessor 22 and executed there when the computing device 20 is started up.
  • the operating system is designated by the reference numeral 25. It has the task of controlling the processing of the computer program 23 to the microprocessor 22 and to the computing device 20 connected peripherals and manage.
  • the operating system 25 is designed in a special way so that it is programmed to carry out the method according to the invention and carries out the method according to the invention when it runs on the microprocessor 22.
  • the operating system 25 includes access to a fault detection mechanism for detecting a
  • the operating system 25 includes an error handling mechanism that re-executes upon detection of an error at least one program object (a task) of the computer program 23 causes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Abarbeiten eines Computerprogramms (23) auf einem Rechengerät (20), insbesondere auf einem Mikroprozessor (22) . Das Computerprogramm (23) umfasst mehrere Programmobjekte, die beispielsweise als Tasks ausgebildet sind. Während der Abarbeitung des Computerprogramms (23) auf dem Rechengerät (20) werden transiente und permanente Fehler detektiert. Um beim Auftreten von transienten Fehlern in einem Rechnersystem diese derart konstruktiv behandeln zu können, dass die Funktionsfähigkeit und die Funktionssicherheit des Rechnersystems innerhalb einer möglichst kurzen Fehlertoleranzzeit wieder hergestellt ist, wird vorgeschlagen, dass bei einer Detektion eines Fehlers mindestens ein Programmobjekt, das bereits einer Abarbeitung zugeführt wurde, in einen definierten Zustand überführt und aus diesem heraus erneut gestartet wird. Das Programmobjekt ist bspw. ein Laufzeitobjekt des Computerprogramms (23), eine sog. Task. Im Sinne der Erfindung kann eine Task oder können mehrere Tasks, die beim Auftreten des Fehlers noch abgearbeitet werden oder bereits abgearbeitet wurden, erneut gestartet und ausgeführt werden.

Description

Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
Die vorliegende Erfindung betrifft ein Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor. Das Computerprogramm umfasst mehrere Programmobjekte. Bei dem Verfahren werden während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert.
Die Erfindung betrifft außerdem ein Betriebssystem, das auf einem Rechengerät, insbesondere auf einem Mikroprozessor, ablauffähig ist.
Schließlich betrifft die vorliegende Erfindung auch ein Rechengerät zum Abarbeiten eines Computerprogramms, das mehrere Programmobjekte umfasst. Das Rechengerät weist einen Fehlerentdeckungsmechanismus zur Detektion eines Fehlers während der Abarbeitung des Computerprogramms auf dem Rechengerät auf. Stand der Technik
Bei der Abarbeitung eines Computerprogramms auf einem Rechengerät kann es zu sogenannten transienten Fehlern kommen. Da die Strukturen auf den Halbleiterbausteinen
(sog. Chips) immer kleiner, die Taktrate der Signale aber immer größer und die Spannungen der Signale immer niedriger werden, treten transiente Fehler immer häufiger auf. Transiente Fehler treten im Gegensatz zu permanenten Fehlern nur temporär auf und verschwinden nach einiger Zeit in der Regel von selbst wieder. Bei transienten Fehlern sind lediglich einzelne Bits falsch, ohne dass das Rechengerät an sich permanent beschädigt ist. Transiente Fehler können verschiedene Ursachen haben, wie beispielsweise elektromagnetische Einflüsse, Alpha-Partikel oder Neutronen.
Bei Kommunikationssystemen liegt schon heute der Schwerpunkt bei der Fehlerbehandlung auf transienten Fehlern. Bei Kommunikationssystemen (z.B. bei dem
Controller Area Network, CAN) ist es bekannt, bei der Detektion eines Fehlers die fehlerhaft übermittelten Daten erneut zu senden. Außerdem ist es bekannt, in Kommunikationssystemen einen Fehlerzähler einzusetzen , der bei Detektion eines Fehlers erhöht wird, bei korrektem Senden erniedrigt wird, und ein Senden von Daten verhindert, sobald er einen bestimmten Wert überschreitet.
Bei Rechengeräten zur Abarbeitung von Computerprogrammen erfolgt eine Fehlerbehandlung jedoch im Wesentlichen nur für permanente Fehler. Eine Berücksichtigung transienter Fehler beschränkt sich auf das Inkrementieren und gegebenenfalls Dekrementieren eines Fehlerzählers. Dieser wird in einem Speicher abgelegt und kann off-line, das heißt beispielsweise bei einem als Kraftfahrzeugsteuergerät ausgebildeten Rechengerät während eines
Werkstattaufenthalts, als Diagnose- oder Fehlerinformation ausgelesen werden. Erst dann kann auf den Fehler entsprechend reagiert werden.
Die Fehlerbehandlung mittels Fehlerzähler erlaubt also zum einen keine Fehlerbehandlung innerhalb einer insbesondere für sicherheitsrelevante Systeme erforderlichen kurzen Fehlertoleranzzeit und zum anderen auch keine konstruktive Fehlerbehandlung in dem Sinne, dass innerhalb der Fehlertoleranzzeit das Computerprogramm wieder ordnungsgemäß abgearbeitet wird. Statt dessen wird beim Stand der Technik das Computerprogramm nach dem Überschreiten eines bestimmten Wertes des Fehlerzählers in einen Notlaufbetrieb umgeschaltet. Das bedeutet, dass statt des fehlerbehafteten Teils des Computerprogramms ein anderes abgearbeitet wird und die auf diese Weise ermittelten Ersatzwerte für die weitere Berechnung herangezogen werden. Die Ersatzwerte können beispielsweise anhand anderer Größen modelliert werden. Alternativ können die mit dem fehlerbehafteten Teil des Computerprogramms berechneten Ergebnisse als fehlerhaft verworfen und durch für den Notlaufbetrieb vorgesehene Standardwerte für die weitere Berechnung ersetzt werden. Die bekannten Verfahren zur Behandlung eines transienten Fehlers eines auf einem Rechengerät ablaufenden Computerprogramms erlauben somit keinen systematischen, konstruktiven Umgang mit der transienten Natur der meisten Fehler.
Aus dem Stand der Technik ist es außerdem bekannt, bei der Abarbeitung eines Computerprogramms auf einem Rechengerät auftretende transiente Fehler durch einen kompletten Neustart des Rechengeräts zu beheben. Auch diese Lösung kann nicht wirklich befriedigen, da in dem bisherigen Verlauf der Abarbeitung des Computerprogramms gewonnene Größen verloren gehen und das Rechengerät für die Dauer des Neustarts seine bestimmungsgemäße Funktion nicht erfüllen kann. Dies ist insbesondere bei sicherheitsrelevanten Systemen inakzeptabel.
Schließlich ist es als Fehlerbehandlung für transiente Fehler eines auf einem Rechengerät abgearbeiteten Computerprogramms auch bekannt, das Computerprogramm um einige Takte zurückzusetzen und einzelne Maschinenbefehle des Computerprogramms zu wiederholen. Dieses Verfahren wird auch als Micro Roll-Back bezeichnet. Bei dem bekannten Verfahren wird nur um Objekte auf Maschinenebene (Takte, Maschinenbefehle) zurückgesprungen. Das erfordert eine entsprechende Hardwareunterstützung auf Maschinenebene, was mit einem erheblichen Aufwand im Bereich des Rechengeräts verbunden ist. Eine Ausführung des bekannten Verfahrens rein durch Software gesteuert ist nicht möglich.
Die aus dem Stand der Technik bekannten Fehlerbehandlungs- mechanismen können auf transiente Fehler, die bei der
Abarbeitung eines Computerprogramms auf einem Rechengerät auftreten, nicht in geeigneter Weise reagieren.
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, beim Auftreten von transienten Fehlern beim Ararbeiten eines Computerprogramms in einem Rechnersystem diese derart konstruktiv zu behandeln, dass die volle Funktionsfähigkeit und die Funktionssicherheit des Rechnersystems innerhalb einer möglichst kurzen Fehlertoleranzzeit wieder hergestellt ist.
Zur Lösung dieser Aufgabe wird ausgehend von dem Verfahren der eingangs genannten Art vorgeschlagen, dass bei einer Detektion eines Fehlers mindestens ein Programmobjekt, das bereits einer Abarbeitung zugeführt wurde, in einen definierten Zustand überführt und aus diesem heraus erneut gestartet wird.
Vorteile der Erfindung
Das Programmobjekt, das erneut gestartet wird, muss bei der Detektion des Fehlers nicht vollständig abgearbeitet worden sein. Im Sinne der Erfindung können auch solche Programmobjekte beim Auftreten eines Fehlers erneut gestartet werden, die zum Zeitpunkt der Fehlerdetektion noch nicht vollständig abgearbeitet worden sind, mit deren Abarbeitung aber wohl schon begonnen wurde. Erfindungsgemäß wird also beim Auftreten eines transienten oder eines permanenten Fehlers mindestens ein Betriebssystemobjekt erneut ausgeführt. Die Vorteile gegenüber dem Micro RoIl- Back liegen insbesondere darin, dass die Wiederholung eines Programmobjekts mit einer sehr geringen Hardwareunterstützung realisiert werden kann. Es ist höchstens zusätzlicher Speicherplatz erforderlich, um einige für die erneute Ausführung des Programmobjekts erforderliche Informationen (z.B. Eingangsgrößen des Programmobjekts) abspeichern zu können. Die eigentliche Verwaltung des erfindungsgemäßen Verfahrens kann durch das Betriebssystem des Rechengeräts ausgeführt werden. Das heißt, das erfindungsgemäße Verfahren ist mit herkömmlichen, handelsüblichen Prozessoren realisierbar, ohne dass es zusätzlicher Hardware bedarf. Selbstverständlich ist es aber auch möglich, das erfindungsgemäße Verfahren mit Hardwareunterstützung zu realisieren.
Die Fehlerdetektion selbst kann nach einem beliebigen Verfahren erfolgen. Denkbar ist der Einsatz jeder Art von Fehlerentdeckungsmechanismus, der Fehler während der Abarbeitung des Computerprogramms (sog. concurrent checking) detektieren kann. Beispielsweise bei einer Dual Core Architektur ist der ganze Rechnerkern zweifach ausgebildet. Wenn die Rechnerkerne in einem Lockstep-Modus betrieben werden, kann für jede Instruktion verglichen werden, ob beide Rechnerkerne die gleichen Ergebnisse liefern. Ein Unterschied der Ergebnisse lässt dann mit Sicherheit auf einen Fehler schließen. Dieser Fehlerentdeckungsmechanismus entdeckt also Fehler bei der Abarbeitung der Programmobjekte in Echtzeit. Entsprechendes gilt auch für fehlerentdeckende Codes, die in der Prozessorarchitektur durchgängig verwendet werden, oder auch für duplizierte Teilkomponenten des Rechengeräts. All diesen Fehlerentdeckungsmechanismen ist gemeinsam, dass sie transiente Fehler sehr schnell entdecken und ein
Fehlersignal liefern, wenn ein Fehler detektiert wurde.
Auf ein solches Fehlersignal hin kann ein Fehlerbehandlungsmechanismus angestoßen werden, der das Programmobjekt wiederholt. Falls sich bei der erneuten
Ausführung der gleiche Fehler nochmals auftritt, kann auf einen permanenten Fehler geschlossen werden, oder ein Fehlerzähler erhöht werden, wobei erst bei dessen Überschreitens eines bestimmten Wertes auf einen permanenten Fehler geschlossen wird. Wenn der Fehler dagegen bei der erneuten Ausführung des Programmobjekts nicht mehr auftritt, kann davon ausgegangen werden, dass der Fehler ein transienter Fehler war. Noch während der fehlerfreien erneuten Ausführung des Programmobjekts steht das Computerprogramm wieder für seine bestimmungsgemäße Funktion bereit. Die Verfügbarkeit ist also bereits nach kürzester Zeit wieder hergestellt. Eine Wiederholung mindestens eines Programmobjekts ist somit ein gutes Mittel, transiente Fehler zu behandeln. Gemäß einer vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass die Programmobjekte als Laufzeitobjekte des Computerprogramms ausgebildet sind (im Folgenden Tasks genannt) und bei der Detektion eines Fehlers mindestens eine Task erneut ausgeführt wird. Bei einer Task handelt es sich um ein typisches Objekt auf Betriebssystemebene. Die Wiederholung einer Task kann mit minimalem Aufwand, falls gewünscht sogar rein softwaremäßig gesteuert, realisiert werden.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird vorgeschlagen, dass ein zum Zeitpunkt der Detektion des Fehlers ausgeführtes Programmobjekt erneut gestartet wird. Alternativ oder zusätzlich können aber auch Programmobjekte gestartet und erneut abgearbeitet werden, die zum Zeitpunkt der Detektion des Fehlers bereits vollständig abgearbeitet waren.
Es wird vorgeschlagen, dass während der Abarbeitung der Programmobjekte, insbesondere zu Beginn der Abarbeitung der Programmobjekte, mindestens ein definierter Zustand der Programmobjekte erzeugt und abgespeichert wird. Dies kann bspw. dadurch erfolgen, dass die Werte aller für den Zustand des Programmobjekts relevanten Größen abgespeichert werden.
Des weiteren wird vorgeschlagen, dass zur Fehlerdetektion ein zu dem Rechengerät, auf dem das Computerprogramm mit den mehreren Programmobjekten abgearbeitet wird, redundant arbeitendes weiteres Rechengerät verwendet wird.
Selbstverständlich kann auch mehr als ein redundantes Rechengerät zur Fehlerdetektion eingesetzt werden.
Vorteilhafterweise wird das erfindungsgemäße Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, verwendet, um trotz unvermeidbarer transienter Fehler beim Abarbeiten eines Computerprogramms eine sichere und zuverlässige Abarbeitung des Computerprogramms zu gewährleisten. Das ist vor allem für die Abarbeitung von Steuer- und/oder
Regelungsprogrammen in sicherheitskritischen Anwendungen in einem Kraftfahrzeug von Bedeutung.
Es wird ferner vorgeschlagen, dass auf einen permanenten Fehler geschlossen wird, falls der gleiche Fehler bei der erneuten Ausführung des mindestens einen Programmobjekts erneut auftritt. Es ist auch denkbar, dass erst dann auf einen permanenten Fehler geschlossen wird, wenn der Fehler nach einer vorgebbaren Anzahl an Wiederholungen des Programmobjekts noch immer auftritt. In diesem Fall wird also selbst dann noch auf einen transienten Fehler geschlossen, wenn dieser erst nach einer dritten oder einer noch späteren Wiederholung des Programmobjekts wegfällt. Durch diese Weiterbildung der Erfindung können wichtige Programmobjekte bspw. 3-mal statt nur 2-mal wiederholt werden.
Gemäß einer anderen vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass die Anzahl der Wiederholungen des mindestens einen Programmobjekts auf einen vorgebbaren Wert begrenzt wird. Dadurch wird verhindert, dass bei einem permanenten Fehler das gleiche Programmobjekt beliebig oft wiederholt wird. Die Beschränkung der Anzahl der Wiederholungen des mindestens einen Programmobjekts kann bspw. mittels eines Zählers oder über Zeitschranken erfolgen. Durch die Vorgabe des taskabhängigen Wiederholwerts wird außerdem ermöglicht, wichtige Tasks öfter zu wiederholen als weniger wichtige, und somit wichtigen Tasks öfter bzw. länger die Möglichkeit zu geben, ohne transiente Fehler fehlerfrei abzulaufen, während bei weniger wichtigen Tasks relativ schnell auf einen permanenten Fehler geschlossen und eine andere Systemreaktion eingeleitet wird.
Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung wird vorgeschlagen, dass die Anzahl der Wiederholungen des mindestens einen Programmobjekts auf einen vorgebbaren Wert dynamisch begrenzt wird. Vorteilhafterweise wird die Anzahl der Wiederholungen des mindestens einen Programmobjekts in Abhängigkeit von einer verbleibenden Restzeit für ein Scheduling auf einen vorgebbaren Wert dynamisch begrenzt. Auf diese Weise können bspw. eine erste Task und eine zweite Task durchlaufen, während eine dritte Task mehrmals wiederholt werden kann.
Zur Realisierung des erfindungsgemäßen Verfahrens wird vorgeschlagen, dass während der Abarbeitung des Computerprogramms vor der Ausführung eines Programmobjekts die Werte der zur Ausführung des Programmobjekts notwendigen bzw. den Zustand des Programmobjekts definierenden Größen gespeichert werden. Gemäß dieser Ausführungsform werden also die Größen aller Programmobjekte abgespeichert.
Alternativ wird vorgeschlagen, dass bei einem in einer Periode periodisch abzuarbeitenden Computerprogramm bei einer Detektion eines Fehlers auf ein bestimmtes Programmobjekt an einem vorgebbaren Rücksprungpunkt in der Periode des Computerprogramms zurückgesprungen wird. Gemäß dieser Ausführungsform wird also bei einem Fehler stets an die gleiche Stelle innerhalb der Periode gesprungen. Vorzugsweise werden dann während der Abarbeitung des Computerprogramms nur vor der Ausführung eines Programmobjekts an dem Rücksprungpunkt die Werte von allen für den Zustand des Programmobjekts relevanten Größen gespeichert. Es müssen also nur einmal pro Zyklus oder Periode nur die Werte der relevanten Größen des Programmobjekts an dem Rücksprungpunkt abgespeichert werden. Dadurch kann Zeit für die Speicherung und Speicherplatz eingespart werden.
Bei einer erneuten Ausführung eines Programmobjekts nach der Detektion eines Fehlers werden dann die abgespeicherten Eingangsgrößen aufgerufen und dem erneut auszuführenden Programmobjekt als Eingangsgrößen zur Verfügung gestellt.
Als eine weitere Ausführungsform der Erfindung wird vorgeschlagen, dass zu einem Programmobjekt mehrere Rücksprungpunkte angelegt werden. Beim Auftreten eines Fehlers muss nicht das gesamte Programmobjekt, sondern nur ein Teil des Programmobjekts erneut abgearbeitet werden. Beim Auftreten eines Fehlers wird einfach auf denjenigen vorangegangenen Rücksprungpunkt gesprungen, bis zu dem die Abarbeitung des Programmobjekts fehlerfrei war. Zum Beispiel kann bei einem fehlerfreien Abarbeiten des Programmobjekts bis zum n-ten Rücksprungpunkt beim Auftreten eines Fehlers zwischen diesem und dem (n+l)-ten Rücksprungpunkt auf den n-ten Rücksprungpunkt zurückgesprungen werden. Das Programmobjekt wird dann ab dem n-ten Rücksprungpunkt erneut abgearbeitet. Damit ist eine Zeitersparnis möglich. Vorzugsweise wird beim Überschreiten eines jeden Rücksprungpunktes während der Abarbeitung des Programmobjekts jeweils mindestens ein definierter Zustand erzeugt und abgespeichert.
Von besonderer Bedeutung ist die Realisierung des erfindungsgemäßen Verfahrens in der Form eines Betriebssystems. Dabei ist das Betriebssystem auf einem Rechengerät, insbesondere auf einem Mikroprozessor, ablauffähig und zur Ausführung des erfindungsgemäßen Verfahrens programmiert, wenn es auf dem Rechengerät abläuft. In diesem Fall wird also die Erfindung durch das Betriebssystem realisiert, so dass dieses Betriebssystem in gleicher Weise die Erfindung darstellt wie das Verfahren, zu dessen Ausführung das Betriebssystem geeignet ist. Das Betriebssystem ist vorzugsweise auf einem Speicherelement abgespeichert und wird zur Abarbeitung an das Rechengerät übermittelt. Als Speicherelement kann insbesondere ein beliebiger Datenträger oder ein elektrisches Speichermedium zur Anwendung kommen, beispielsweise ein Random-Access- Memory (RAM) , ein Read-Only-Memory (ROM) oder ein Flash- Memory.
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung wird ausgehend von dem Rechengerät der eingangs genannten Art vorgeschlagen, dass das Rechengerät einen Fehlerbehandlungsmechanismus aufweist, der bei einer Detektion eines Fehlers durch den Fehlerentdeckungs¬ mechanismus ein erneutes Ausführen mindestens eines Programmobjekts veranlasst.
Gemäß einer vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass der Fehlerbehandlungsmechanismus eine Triggerlogik aufweist, welche bei einer Detektion eines Fehlers das mindestens eine Programmobjekt neu startet.
Gemäß einer bevorzugten Ausführungsform wird vorgeschlagen, dass auf dem Rechengerät ein Echtzeit-Betriebssystem, bspw. OSEK time, abläuft. Schließlich wird vorgeschlagen, dass das Rechengerät einen Mikroprozessor umfasst.
Zeichnungen Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Patentansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung beziehungsweise Darstellung in der Beschreibung, beziehungsweise in der Zeichnung. Es zeigen:
Fig. 1 Ein Ablaufdiagramm eines erfindungsgemäßen
Verfahrens gemäß seiner bevorzugten
Ausführungsform; und
Fig. 2 ein erfindungsgemäßes Rechengerät gemäß seiner bevorzugten Ausführungsform in einer schematischen Darstellung.
Beschreibung der Ausführungsbeispiele
Die vorliegende Erfindung betrifft ein Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor. Das Computerprogramm umfasst mehrere Programmobjekte, die vorzugsweise als Tasks ausgebildet sind. Bei dem Verfahren werden während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert. Die detektierten Fehler können transienter (also vorübergehender) oder permanenter Art sein.
Die transienten Fehler können bei der Abarbeitung eines Computerprogramms auf einem Rechengerät auftreten. Da die Strukturen auf den Halbleiterbausteinen (sogenannten Chips) der Rechengeräte immer kleiner, die Taktrate der Signale aber immer größer und die Spannungen der Signale immer niedriger werden, treten bei der Abarbeitung eines Computerprogramms auf einem Rechengerät immer häufiger transiente Fehler auf. Im Gegensatz zu permanenten Fehlern treten sie nur temporär auf und verschwinden nach einiger Zeit in der Regel von selbst wieder. Bei transienten Fehlern sind lediglich einzelne Bits falsch, ohne dass das Rechengerät an sich permanent beschädigt ist. Transiente Fehler können verschiedene Ursachen haben, wie beispielsweise elektromagnetische Einflüsse, Alpha-Partikel oder Neutronen.
Aufgrund der Tatsache, dass transiente Fehler nahezu unvorhersehbar auftreten und deshalb nicht reproduzierbar sind, erfolgt bei aus dem Stand der Technik bekannten Rechengeräten eine Fehlerbehandlung im wesentlichen nur für permanente Fehler. Eine Berücksichtigung transienter Fehler beschränkt sich auf das Inkrementieren und gegebenenfalls Dekrementieren eines Fehlerzählers. Dieser wird in einem Speicher abgelegt und kann off-line, das heißt beispielsweise während eines Werkstattaufenthalts, als Diagnose- oder Fehlerinformation ausgelesen werden. Erst dann kann auf den Fehler entsprechend reagiert werden. Die bekannte Fehlerbehandlung erlaubt also keine
Fehlerbehandlung innerhalb einer insbesondere für sicherheitsrelevante Systeme erforderlichen kurzen Fehlertoleranzzeit und zum anderen auch keine konstruktive Fehlerbehandlung in dem Sinne, dass innerhalb der Fehlertoleranzzeit das Computerprogramm wieder ordnungsgemäß abgearbeitet wird und das Rechengerät seine bestimmungsgemäße Aufgabe erfüllen kann.
Im Gegensatz dazu erlaubt das erfindungsgemäße Verfahren eine Behandlung eines transienten Fehlers eines auf einem Rechengerät ablaufenden Computerprogramms mit einem systematischen, konstruktiven Umgang mit der transienten Natur der meisten Fehler. Ein Ablaufdiagramm des erfindungsgemäßen Verfahrens am Beispiel eines Laufzeitobjekts, einer sogenannten Task, ist in Fig.l dargestellt. Die Existenz weiterer Tasks beeinflusst den prinzipiellen Ablauf nicht, eine Berücksichtigung entfällt also. So wie gemäß dem in Fig. 1 dargestellten Ablauf eine Task behandelt wird, können erfindungsgemäß also auch mehrere Tasks behandelt werden. Besonders vorteilhaft ist ein parallel arbeitender Fehlerentdeckungsmechanismus (sog. concurrent checking) . Dieser ist in einem Ablaufdiagramm so aber nicht darstellbar, er ist an der entsprechenden Stelle als serieller Baustein eingefügt.
Das erfindungsgemäße Verfahren beginnt in einem Funktionsblock 1. In dem Funktionsblock 1 wird mit der Abarbeitung der Task auf dem Rechengerät begonnen; die Task wird aufgerufen. In einem Funktionsblock 2 wird ein Rücksprungpunkt erzeugt. Zu diesem Zweck werden sichere relevante Taskeingangsgrößen, die ausreichen, die Task in eine definierten Zustand für einen Neustart zu versetzen und die Task nochmals zu starten, in einem Speicherelement des Rechengerätes abgespeichert. Vorzugsweise werden alle Eingangsgrößen der Task abgespeichert. In einem
Funktionsblock 3 wird dann die Task weiter abgearbeitet. Die Abarbeitung kann entweder zu einem weiteren Rücksprungpunkt oder bis zum Ende der Task erfolgen. Dann wird ein Fehlerentdeckungsmechanismus ausgeführt. Die Fehlerdetektion kann nach einem beliebigen Verfahren erfolgen. Die Fehler werden während der Abarbeitung des Computerprogramms detektiert (sogenanntes concurrent checking) . So ist beispielsweise bei einer sogenannten Dual-Core-Architektur der ganze Rechnerkern zweifach ausgebildet. Wenn die Rechnerkerne in einem sogenannten Lockstep-Modus betrieben werden, kann für jede Instruktion verglichen werden, ob beide Rechnerkerne die gleichen Ergebnisse liefern. Ein Unterschied der Ergebnisse lässt dann mit Sicherheit auf einen Fehler schließen. Ein solcher Fehlerentdeckungsmechanismus entdeckt also Fehler bei der Abarbeitung der Task in Echtzeit. Entsprechendes gilt auch für fehlerentdeckende Codes, die in der
Prozessorarchitektur durchgängig verwendet werden oder auch für duplizierte Teilkomponenten des Rechengerätes. Vorzugsweise werden solche Fehlerentdeckungsmechanismen eingesetzt, die transiente Fehler sehr schnell entdecken und ein Fehlersignal liefern, wenn ein Fehler detektiert wurde.
In einem Abfrageblock 4 wird überprüft, ob ein Fehler, also ein transienter oder ein permanenter Fehler, entdeckt wurde. Falls ein Fehler entdeckt wurde, wird in einen weiteren Abfrageblock 7 verzweigt, wo der aktuelle Wert einer Fehlerzählerlogik überprüft wird. Falls der Fehlerzähler einen vorgebbaren Zählerstand noch nicht unterschritten (bei einem dekrementierenden Fehlerzähler) oder überschritten (bei einem inkrementierenden Fehlerzähler) hat, kann die Task, während deren Abarbeitung der Fehler aufgetreten ist, bzw. können eine bestimmte Anzahl an Tasks, die vor dem Auftreten des Fehlers abgearbeitet wurden, noch einmal ausgeführt werden. Falls ein erneutes Starten der Abarbeitung der Task möglich ist, wird in einem Funktionsblock 8 verzweigt, in dem der Status der Fehlerzählerlogik mit der Information, dass ein weiterer Fehler aufgetreten ist, aktualisiert
(dekrementiert oder inkrementiert) wird. Von dort wird in einen Funktionsblock 5 verzweigt, in welchem die in dem Funktionsblock 2 abgespeicherten Größen geladen und der Task zum Erzeugen eines definierten Zustandes zu Beginn der Abarbeitung zugeführt werden. Dann wird zu dem Funktionsblock 3 verzweigt, wo die zu wiederholende Task teilweise, das heißt beispielsweise von einem bereits abgearbeiteten Rücksprungpunkt aus, oder aber als ganzes, das heißt die Task wird von Beginn an noch einmal gestartet, noch einmal abgearbeitet wird.
Falls sich in dem Abfrageblock 4 ergibt, dass während der Abarbeitung der Task in dem Funktionsblock 3 kein Fehler aufgetreten ist, wird in einem Funktionsblock 9 verzweigt, in welchem der Status der Fehlerzählerlogik mit der
Information aktualisiert wird, dass kein Fehler detektiert worden ist. Von dort aus wird in einen Abfrageblock 11 verzweigt, wo überprüft wird, ob das Computerprogramm zu Ende abgearbeitet ist. Falls dem so ist, wird zum Ende des Computerprogramms in Funktionsblock 6 verzweigt.
Anderenfalls wird in einen Funktionsblock 12 verzweigt, wo entsprechend dem aktuellen Taskstatus ein weiterer Rücksprungpunkt erzeugt wird, indem sichere relevante Taskeingangsgrößen, die ausreichen, um die Task nochmals zu starten, definiert und abgespeichert werden. Von dort aus wird dann wieder zu dem Funktionsblock 3 verzweigt, wo die zu wiederholende Task erneut gestartet und entweder teilweise oder als ganzes noch einmal abgearbeitet wird.
Falls sich in dem Abfrageblock 7 ergibt, dass aufgrund des Standes der Fehlerzählerlogik ein weiterer Versuch zur erneuten Abarbeitung der Task nicht mehr möglich ist, wird in einen Funktionsblock 10 verzweigt. In dem Abfrageblock 7 wird überprüft, ob der Wert der Fehlerzählerlogik für diese Task größer als ein taskabhängiger Wiederholwert ist. Dieser taskabhängige Wiederholwert kann entweder für verschiedene Tasks gleich oder aber individuell für jede Task einzeln vorgegeben werden. Auf diese Weise ist es möglich, dass beispielsweise besonders wichtige Tasks zunächst mehrmals wiederholt werden, bevor ein permanenter Fehler gemeldet wird. Wenn der taskabhängige Wiederholwert als 1 vorgegeben wird, wird die Task nur einmal wiederholt, bevor ein permanenter Fehler detektiert wird. Falls der taskabhängige Wiederholwert auf 2 oder 3 vorgegeben wird, wird die Task 2 oder 3-mal wiederholt, bevor ein permanenter Fehler detektiert wird. Die Task hat in diesem Fall also eine längere Zeit, beziehungsweise mehr Durchläufe zur Verfügung, bis der transiente Fehler nicht mehr auftritt. In dem Funktionsblock 10 wird ein permanenter Fehler detektiert und eine entsprechende
Maßnahme eingeleitet. Diese Maßnahme kann beispielsweise darin bestehen, das Computerprogramm in einen Notlaufbetrieb zu überführen oder zunächst nichts zu unternehmen und den Ablauf des Computerprogramms dann zu beenden.
Das erfindungsgemäße Verfahren muss nicht notwendiger Weise alle in Fig. 1 dargestellten und oben erläuterten Funktions- und Abfrageblöcke umfassen. So kann bspw. auf die Blöcke 7 bis 9 verzichtet werden, welche die
Fehlerzählerlogik betreffen. Bei der Detektion eines Fehlers würde (n) die erneut zu startende (n) und auszuführende (n) Task(s) so lange wiederholt werden, bis der Fehler nicht mehr auftritt. Ein permanenter Fehler würde nicht detektiert werden, so dass auch Funktionsblock 10 wegfallen könnte. Alternativ kann der taskabhängige Wiederholwert als 1 vorgegeben werden, so dass die Funktionsblöcke 8 und 9 zum Aktualisieren des Fehlerzählers entfallen könnten. Schließlich wäre es auch möglich, auf die Blöcke 11 und 12 zu verzichten, wenn nur eine einzige Task mit einem einzigen Rücksprungpunkt ausgeführt wird.
In Fig. 2 ist ein erfindungsgemäßes Rechengerät zum Abarbeiten eines Computerprogramms gemäß seiner bevorzugten Ausführungsform dargestellt. Das Rechengerät ist in seiner Gesamtheit mit dem Bezugszeichen 20 bezeichnet. Das Rechengerät umfasst ein Speicherelement 21, das beispielsweise als ein elektronischer Speicher, insbesondere als ein Flash-Memory, ausgebildet ist. Außerdem umfasst das Rechengerät 20 einen Mikroprozessor 22, auf dem ein Computerprogramm abgearbeitet werden kann. Das Computerprogramm ist auf dem elektronischen Speichermedium 21 abgespeichert und mit dem Bezugszeichen 23 bezeichnet. Zur Abarbeitung des Computerprogramms auf dem Mikroprozessor 22 wird das Computerprogramm entweder als Ganzes oder abschnittsweise, beispielsweise befehlsweise, über eine Datenverbindung 24 an den Mikroprozessor 22 übertragen. Die Datenverbindung 24 kann als eine oder mehrere Datenleitungen oder als ein Bus- System zur Datenübertragung ausgebildet sein. Auf dem Speichermedium 21 ist außerdem ein Betriebssystem abgespeichert, dass beim Hochfahren des Rechengerätes 20 zumindest teilweise aus dem Speicher 21 an den Mikroprozessor 22 übertragen und dort ausgeführt wird. Das Betriebssystem ist mit dem Bezugszeichen 25 bezeichnet. Es hat die Aufgabe, die Abarbeitung des Computerprogramms 23 auf den Mikroprozessor 22 und an das Rechengerät 20 angeschlossene Peripheriegeräte zu steuern und zu verwalten. Gemäß der vorliegenden Erfindung ist das Betriebssystem 25 in besonderer Weise ausgebildet, so dass es zur Ausführung des erfindungsgemäßen Verfahrens programmiert ist und das erfindungsgemäße Verfahren ausführt, wenn es auf dem Mikroprozessor 22 abläuft. Insbesondere umfasst das Betriebssystem 25 einen Zugang zu einem Fehlerentdeckungsmechanismus zur Detektion eines
Fehlers während der Abarbeitung des Computerprogramms 23 auf dem Mikroprozessor 22. Außerdem umfasst das Betriebssystem 25 einen Fehlerbehandlungsmechanismus, der bei einer Detektion eines Fehlers ein erneutes Ausführen mindestens eines Programmobjektes (einer Task) des Computerprogramms 23 veranlasst.

Claims

Ansprüche
1. Verfahren zum Abarbeiten eines Computerprogramms (23) auf einem Rechengerät (20) , insbesondere auf einem Mikroprozessor (22), wobei das Computerprogramm (23) mehrere Programmobjekte umfasst und bei dem Verfahren während der Abarbeitung des Computerprogramms (23) auf dem Rechengerät (20) Fehler detektiert werden, dadurch gekennzeichnet, dass bei einer Detektion eines Fehlers mindestens ein Programmobjekt, das bereits einer Abarbeitung zugeführt wurde, in einen definierten Zustand überführt und aus diesem heraus erneut gestartet wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programmobjekte als Tasks des Computerprogramms (23) ausgebildet sind und bei der Detektion eines Fehlers mindestens eine Task erneut ausgeführt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein zum Zeitpunkt der Detektion des Fehlers ausgeführtes Programmobjekt erneut ausgeführt wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass während der Abarbeitung der
Programmobjekte, insbesondere zu Beginn der Abarbeitung der Programmobjekte, mindestens ein definierter Zustand der Programmobjekte erzeugt und abgespeichert wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zur Fehlerdetektion ein zu dem Rechengerät (20) redundant arbeitendes weiteres Rechengerät verwendet wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, verwendet wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass auf einen permanenten Fehler geschlossen wird (12), falls der gleiche Fehler bei der erneuten Ausführung des mindestens einen Programmobjekts erneut auftritt.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die Anzahl der Wiederholungen des mindestens einen Programmobjekts auf einen vorgebbaren Wert begrenzt wird.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Anzahl der Wiederholungen des mindestens einen
Programmobjekts auf einen vorgebbaren Wert dynamisch begrenzt wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Anzahl der Wiederholungen des mindestens einen Programmobjekts in Abhängigkeit von einer verbleibenden Restzeit für ein Scheduling auf einen vorgebbaren Wert dynamisch begrenzt wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass während der Abarbeitung des Computerprogramms (23) vor der Ausführung eines Programmobjekts die Werte von zur Abarbeitung des Programmobjekts notwendigen Größen gespeichert werden (3) .
12. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass bei einem in einer Periode periodisch abzuarbeitenden Computerprogramm (23) bei einer Detektion eines Fehlers auf ein bestimmtes Programmobjekt an einem vorgebbaren Rücksprungpunkt in der Periode des Computerprogramms (23) zurückgesprungen wird.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass während der Abarbeitung des Computerprogramms (23) nur vor der Ausführung eines Programmobjekts an dem Rücksprungpunkt alle an dem Programmobjekt anliegenden Eingangsgrößen gespeichert werden.
14. Verfahren nach Anspruch 11 oder 13, dadurch gekennzeichnet, dass während der erneuten Ausführung eines Programmobjekts nach der Detektion eines Fehlers das Programmobjekt mit den für dieses Programmobjekt gespeicherten Eingangsgrößen erneut ausgeführt wird.
15. Betriebssystem (25), das auf einem Rechengerät (20), insbesondere auf einem Mikroprozessor (22), ablauffähig ist, dadurch gekennzeichnet, dass das Betriebssystem (25) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 14 programmiert ist und das erfindungsgemäße Verfahren ausführt, wenn es auf dem Rechengerät (20) abläuft.
16. Rechengerät (20) zum Abarbeiten eines
Computerprogramms (23) , das mehrere Programmobjekte umfasst, wobei das Rechengerät (20) einen
Fehlerentdeckungsmechanismus zur Detektion eines Fehlers während der Abarbeitung des Computerprogramms (23) auf dem Rechengerät (20) aufweist, dadurch gekennzeichnet, dass das Rechengerät (20) einen Fehlerbehandlungsmechanismus aufweist, der bei einer Detektion eines Fehlers durch den Fehlerentdeckungsmechanismus veranlasst, dass mindestens ein Programmobjekt, das bereits einer Abarbeitung zugeführt wurde, in einen definierten Zustand überführt und aus diesem heraus erneut gestartet wird.
17. Rechengerät (20) nach Anspruch 16, dadurch gekennzeichnet, dass der Fehlerbehandlungsmechanismus eine Triggerlogik aufweist, welche bei einer Detektion eines Fehlers das mindestens eine Programmobjekt neu startet.
18. Rechengerät (20) nach Anspruch 16 oder 17, dadurch gekennzeichnet, dass auf dem Rechengerät (20) ein Echtzeit- Betriebssystem (25) abläuft.
19. Rechengerät (20) nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass das Rechengerät (20) einen Mikroprozessor (22) umfasst.
PCT/EP2005/053621 2004-08-04 2005-07-25 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms WO2006015945A2 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US11/659,307 US7890800B2 (en) 2004-08-04 2005-07-25 Method, operating system and computing hardware for running a computer program
CN2005800262785A CN1993679B (zh) 2004-08-04 2005-07-25 执行计算机程序的方法、操作系统和计算设备
EP05777777A EP1854007A2 (de) 2004-08-04 2005-07-25 Verfahren, betriebssysem und rechengerät zum abarbeiten eines computerprogramms
BRPI0513229-0A BRPI0513229A (pt) 2004-08-04 2005-07-25 processo, sistema operacional e computador para o processamento de um programa de computador
JP2007524328A JP4728334B2 (ja) 2004-08-04 2005-07-25 コンピュータプログラムを処理する方法、オペレーティングシステムおよび計算装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004037713.8 2004-08-04
DE102004037713A DE102004037713A1 (de) 2004-08-04 2004-08-04 Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms

Publications (2)

Publication Number Publication Date
WO2006015945A2 true WO2006015945A2 (de) 2006-02-16
WO2006015945A3 WO2006015945A3 (de) 2006-06-08

Family

ID=35395722

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/053621 WO2006015945A2 (de) 2004-08-04 2005-07-25 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms

Country Status (8)

Country Link
US (1) US7890800B2 (de)
EP (1) EP1854007A2 (de)
JP (1) JP4728334B2 (de)
CN (1) CN1993679B (de)
BR (1) BRPI0513229A (de)
DE (1) DE102004037713A1 (de)
RU (1) RU2431182C2 (de)
WO (1) WO2006015945A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045733A2 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
US20220171668A1 (en) * 2020-11-27 2022-06-02 Arm Limited Data processing systems

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005037247A1 (de) * 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Steuerung eines Speicherzugriffs bei einem Rechnersystem mit wenigstens zwei Ausführungseinheiten
US8205113B2 (en) * 2009-07-14 2012-06-19 Ab Initio Technology Llc Fault tolerant batch processing
CN102279787B (zh) * 2010-06-08 2015-06-17 腾讯科技（深圳）有限公司 一种平均无故障时间的测试方法和装置
EP2657797B1 (de) * 2012-04-27 2017-01-18 Siemens Aktiengesellschaft Verfahren zum Betreiben eines redundanten Automatisierungssystems
RU2521265C2 (ru) * 2012-09-28 2014-06-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ автоматической обработки системных ошибок программного обеспечения
RU2543960C1 (ru) * 2013-08-29 2015-03-10 Открытое акционерное общество "Концерн "Системпром" Способ определения уязвимых функций при автоматизированной проверке веб-приложений на наличие уязвимостей
US9389863B2 (en) 2014-02-10 2016-07-12 Via Alliance Semiconductor Co., Ltd. Processor that performs approximate computing instructions
US9588845B2 (en) * 2014-02-10 2017-03-07 Via Alliance Semiconductor Co., Ltd. Processor that recovers from excessive approximate computing error
US10235232B2 (en) 2014-02-10 2019-03-19 Via Alliance Semiconductor Co., Ltd Processor with approximate computing execution unit that includes an approximation control register having an approximation mode flag, an approximation amount, and an error threshold, where the approximation control register is writable by an instruction set instruction
US9990245B2 (en) * 2015-11-25 2018-06-05 Stmicroelectronics S.R.L. Electronic device having fault monitoring for a memory and associated methods

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2326254A (en) * 1997-06-12 1998-12-16 Mitsubishi Electric Corp Agent system sends object including program and data to server for execution
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
EP1121642B1 (de) * 1998-10-12 2003-02-05 Centre National D'etudes Spatiales Verfahren zur behandlung eines vorübergehenden fehlern unterworfenes elektronisches systems
US20030088807A1 (en) * 2001-11-07 2003-05-08 Mathiske Bernd J.W. Method and apparatus for facilitating checkpointing of an application through an interceptor library
CA2365427A1 (en) * 2001-12-19 2003-06-19 Ibm Canada Limited-Ibm Canada Limitee Internal product fault monitoring apparatus and method

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4852092A (en) * 1986-08-18 1989-07-25 Nec Corporation Error recovery system of a multiprocessor system for recovering an error in a processor by making the processor into a checking condition after completion of microprogram restart from a checkpoint
JP2674764B2 (ja) 1987-10-17 1997-11-12 日本電気株式会社 冗長系切替回路網
JP2679575B2 (ja) * 1993-06-21 1997-11-19 日本電気株式会社 入出力チャネルの障害処理システム
JP2685712B2 (ja) * 1994-03-30 1997-12-03 株式会社サンポウロック ハンドルロック
US6105148A (en) * 1995-06-16 2000-08-15 Lucent Technologies Inc. Persistent state checkpoint and restoration systems
JP3258228B2 (ja) * 1996-03-15 2002-02-18 株式会社東芝 チェックポイント生成方法
US6625756B1 (en) * 1997-12-19 2003-09-23 Intel Corporation Replay mechanism for soft error recovery
US6584581B1 (en) * 1999-12-06 2003-06-24 Ab Initio Software Corporation Continuous flow checkpointing data processing
US6542844B1 (en) * 2000-08-02 2003-04-01 International Business Machines Corporation Method and apparatus for tracing hardware states using dynamically reconfigurable test circuits
US7412520B2 (en) * 2001-06-07 2008-08-12 Intel Corporation Systems and methods for recoverable workflow
US7206964B2 (en) * 2002-08-30 2007-04-17 Availigent, Inc. Consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication
US7543001B2 (en) * 2004-06-17 2009-06-02 International Business Machines Corporation Storing object recovery information within the object
US7634687B2 (en) * 2005-01-13 2009-12-15 Microsoft Corporation Checkpoint restart system and method
US7516361B2 (en) * 2005-06-27 2009-04-07 Sun Microsystems, Inc. Method for automatic checkpoint of system and application software

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2326254A (en) * 1997-06-12 1998-12-16 Mitsubishi Electric Corp Agent system sends object including program and data to server for execution
EP1121642B1 (de) * 1998-10-12 2003-02-05 Centre National D'etudes Spatiales Verfahren zur behandlung eines vorübergehenden fehlern unterworfenes elektronisches systems
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
US20030088807A1 (en) * 2001-11-07 2003-05-08 Mathiske Bernd J.W. Method and apparatus for facilitating checkpointing of an application through an interceptor library
CA2365427A1 (en) * 2001-12-19 2003-06-19 Ibm Canada Limited-Ibm Canada Limitee Internal product fault monitoring apparatus and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUANG Y ET AL: "COMPONENTS FOR SOFTWARE FAULT TOLERANCE AND REJUVENATION" BELL LABS TECHNICAL JOURNAL, WILEY, CA, US, Bd. 75, Nr. 2, April 1996 (1996-04), Seiten 29-37, XP000584937 ISSN: 1089-7089 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045733A2 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
WO2006045733A3 (de) * 2004-10-25 2006-07-20 Bosch Gmbh Robert Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
US7711985B2 (en) 2004-10-25 2010-05-04 Robert Bosch Gmbh Restarting an errored object of a first class
US20220171668A1 (en) * 2020-11-27 2022-06-02 Arm Limited Data processing systems
US11907056B2 (en) * 2020-11-27 2024-02-20 Arm Limited Runtime fault detection testing in data processing system

Also Published As

Publication number Publication date
RU2431182C2 (ru) 2011-10-10
RU2007106437A (ru) 2008-09-10
US7890800B2 (en) 2011-02-15
DE102004037713A1 (de) 2006-03-16
EP1854007A2 (de) 2007-11-14
US20090217090A1 (en) 2009-08-27
JP4728334B2 (ja) 2011-07-20
CN1993679B (zh) 2010-05-26
BRPI0513229A (pt) 2008-04-29
JP2008508626A (ja) 2008-03-21
WO2006015945A3 (de) 2006-06-08
CN1993679A (zh) 2007-07-04

Similar Documents

Publication Publication Date Title
WO2006015945A2 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE10049441B4 (de) Verfahren zum Betrieb eines von einem Prozessor gesteuerten Systems
EP1810139B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE102012109614A1 (de) Fehlerbehebung bei Stapel-Korruption in eingebetteten Softwaresystemen
DE102014002473A1 (de) System und verfahren zur erhöhung der lockstep-kern-verfügbarkeit
EP1917592A1 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit
WO2012007266A1 (de) Verfahren zum überwachen eines datenspeichers
WO2006032617A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE10235564A1 (de) Verfahren zum Überwachen eines Mikroprozessors und Schaltungsanordnung mit einem Mikroprozessor
DE102008004205A1 (de) Schaltungsanordnung und Verfahren zur Fehlerbehandlung in Echtzeitsystemen
EP2085883A1 (de) Verfahren zur Behandlung von transienten Fehlern in Echtzeitsystemen, insbesondere in Steuergeräten von Kraftfahrzeugen
DE102008024193A1 (de) System mit konfigurierbaren Funktionseinheiten und Verfahren
EP1812853B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
EP1359485B1 (de) Steuer- und Überwachungssystem
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
DE102013202961A1 (de) Verfahren zum Überwachen eines Stackspeichers in einem Betriebssystem eines Steuergeräts eines Kraftfahrzeuges
DE102005061394A1 (de) Fehlertolerantes Prozessorsystem
EP1774417B1 (de) Verfahren und vorrichtung zum überwachen des ablaufs eines steuerprogramms auf einem rechengerät
DE102009000874A1 (de) Verfahren zur Verbesserung der Analysierbarkeit von Softwarefehlern in einem Mikrocontroller
WO2023232401A1 (de) Verfahren für einen betrieb eines steuergeräts eines fahrzeuges
EP1433061A2 (de) Verfahren zum überprüfen eines rechnerkerns eines mikroprozessors oder eines mikrocontrollers
DE10148157B4 (de) Programmgesteuerte Einheit
DE10229817A1 (de) Verfahren und Vorrichtung zum Ablegen eines Computerprogramms in einen Programmspeicher eines Steuergeräts
DE102006040644A1 (de) Korrekturverfahren für einen neu-programmierbaren Mikroprozessor
DE102004047363A1 (de) Prozessor bzw. Verfahren zum Betreiben eines Prozessors und/oder Betriebssystems im Fall einer Störung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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: A2

Designated state(s): 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

REEP Request for entry into the european phase

Ref document number: 2005777777

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2005777777

Country of ref document: EP

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: 2007524328

Country of ref document: JP

Ref document number: 200580026278.5

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2007106437

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2005777777

Country of ref document: EP

ENP Entry into the national phase

Ref document number: PI0513229

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: 11659307

Country of ref document: US