WO2006045733A2 - 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
WO2006045733A2
WO2006045733A2 PCT/EP2005/055390 EP2005055390W WO2006045733A2 WO 2006045733 A2 WO2006045733 A2 WO 2006045733A2 EP 2005055390 W EP2005055390 W EP 2005055390W WO 2006045733 A2 WO2006045733 A2 WO 2006045733A2
Authority
WO
WIPO (PCT)
Prior art keywords
error
program
computing device
detection
computer program
Prior art date
Application number
PCT/EP2005/055390
Other languages
English (en)
French (fr)
Other versions
WO2006045733A3 (de
Inventor
Reinhard Weiberle
Bernd Mueller
Werner Harter
Ralf Angerbauer
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/665,726 priority Critical patent/US7711985B2/en
Priority to EP05803095A priority patent/EP1812853B1/de
Priority to DE502005005915T priority patent/DE502005005915D1/de
Priority to JP2007537272A priority patent/JP4596488B2/ja
Publication of WO2006045733A2 publication Critical patent/WO2006045733A2/de
Publication of WO2006045733A3 publication Critical patent/WO2006045733A3/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

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 can occur.
  • the structures on the semiconductor components (so-called chips) become smaller and smaller, but the clock rate of the signals becomes ever greater and the voltages of the signals ever lower, transient errors occur more frequently.
  • transient errors are only temporary and usually disappear after some time.
  • Transient faults can have different causes, such as electromagnetic influences, alpha particles or neutrons.
  • communication systems eg in the Controller Area Network, CAN
  • 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, in a trained as a motor vehicle control unit computing device during a workshop stay, are read out as diagnostic or error information. Only then can be reacted to the error accordingly.
  • 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 error handling mechanisms known from the prior art can not adequately respond to transient errors that occur in the processing of a computer program on a computing device.
  • transient errors are very common in future technologies. If discovered, e.g. via dual-core mechanisms, the question of fault localization still remains to be answered in order to identify the correct result. This is even more true if one has the goal that a transient error does not always result in a restart of the computer. As described, fault localization is typically only achievable using comparatively complex procedures.
  • 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 roll-back 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 erroneous task so the erroneous task or the faulty program or program part or program object or at least operating system object to be re-calculated. If the error was originally transient, the two outputs are the same in a recalculation, so the error has disappeared and treated by the recalculation.
  • a method for processing a computer program on a computing device in particular on a microprocessor is shown, wherein the Computer program comprises a plurality of program objects and in the method during the processing of the computer program on the computing device errors are detected, in a detection of an error at least one program object that has already been processed, transferred to a defined state and restarted from this, and subsequent further program objects are moved.
  • the program objects are subdivided into at least two classes, wherein program objects of the first class are repeated upon detection of an error, and this program object of the first class is detected instead of a first class class object that has already been processed for detecting an error in a program object of the first class Program object of the second class is restarted.
  • the detection of an error is only performed in classes that are restarted.
  • a total computing time is provided in one pass for all program objects, and the total computing time is divided such that the program objects which are restarted upon detection of an error receive no more than 50% of the total computing time in one pass in the error-free case, the program objects of the different classes alternating be executed and the erroneous program object of the first class is processed instead of the directly following program object of the second class or restarted.
  • the error detection itself can be done by any method. It is conceivable that
  • concurrent checking Use of any type of error detection mechanism that can detect errors during the execution of the computer program (so-called concurrent checking). 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 with
  • This error detection mechanism thus detects errors in the processing of the program objects in real time.
  • 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 detect transient errors very quickly and provide an error signal when an error has been detected.
  • an error handling mechanism that repeats the program object may be initiated. If the same error occurs again during the renewed execution, a permanent error can be concluded, or an error counter can be increased, whereby a permanent error is only concluded when it exceeds a certain value. If, on the other hand, the error does not occur when the program object is executed again, it can be assumed that the error was a transient error. Even during the error-free re-execution of the program object, the computer program is again ready for its intended function. The availability is thus restored after a very short time. A repetition of at least one program object is thus a good way to handle transient errors.
  • Program objects are designed as runtime objects of the computer program (hereinafter referred to as tasks) and at the detection of an error at least one task is executed again.
  • a task is a typical object, especially at the operating system level. 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. Of course, more than one redundant computing device can be used for error detection.
  • the method according to the invention is used in a motor vehicle, in particular in a motor vehicle control unit, in order to ensure reliable and reliable processing of the computer program despite unavoidable transient errors during execution of a computer program. This is especially important for the execution of control and / or regulation programs in safety-critical applications in a motor vehicle.
  • 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, for example, be repeated 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.
  • Computer program in a detection of an error on a particular program object is jumped back to a predefinable return point in the period of the computer program.
  • a predefinable return point in the period of the computer program.
  • the values of all variables relevant to the state of the program object are then stored at the return point only before the execution of a program object.
  • only the values of the relevant variables of the program object at the return point have to be stored once per cycle or period. This can save time for storage and storage space.
  • Program object several return points are created. When an error occurs not the entire program object, but only a part of the program object are processed 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. Preferably, when each return point is crossed, at least one defined state is generated and stored during execution of the program object.
  • the operating system on a computing device, in particular on a microprocessor, executable and programmed to carry out the method according to the invention when it runs on the computing device.
  • 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.
  • any storage medium or an electrical storage medium may be used as the storage element, for example a random access memory (RAM), a read-only memory (ROM) or a flash memory.
  • Error handling mechanism that 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.
  • Figure 1 is a flow chart of a method according to the invention according to its preferred embodiment.
  • Figure 2 shows a computing device according to the invention according to its preferred embodiment in a schematic representation
  • Figure 3 consisting of Figures 3a and 3b, a first approach according to the invention for the integration of the task repetition, and
  • Figure 4 consisting of Figures 4a and 4b, a second approach according to the invention for the integration of the task repetition
  • Figure 5 consisting of Figures 5a and 5b, a third approach according to the invention for the integration of the task repetition.
  • 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.
  • transient errors can occur during the execution of a computer program on a computing device. Since the structures on the semiconductor components (so-called chips) of the computing devices are getting smaller, the clock rate of the signals getting larger and the voltages of the signals are getting lower, transient errors occur more and more often when processing a computer program on a computing device. 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.
  • Error handling 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 be read off-line, that is, for example, during a workshop visit, as a diagnostic or error information. Only then can be reacted to the error accordingly.
  • the known error handling thus does not allow error handling within a particular security-relevant systems required short fault tolerance time and on the other hand no constructive error treatment in the sense that within the fault tolerance time, the computer program is properly processed again and the computing device can fulfill its intended purpose.
  • the method according to the invention allows treatment of a transient error of a computer program running on a computing device with a systematic, constructive handling of 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.
  • the task is then processed further. The processing can be done either to another return point or to the end of the task. Then, an error detection mechanism is executed. The error detection can after any
  • Such an error detection mechanism thus discovers Error while processing the task in real time.
  • error-detecting codes that are used throughout the processor architecture or even 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 query block 4 is checked whether an error, ie a transient or a permanent error was discovered. If 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 does not fall below a predefined counter reading (with a decrementing counter reading)
  • a branch is made in a function block 8 in which the status of the error counter logic is updated (decremented or incremented) with the information that a further error has occurred. From there, a branch is made into a function block 5, in which the variables stored in the function block 2 are loaded and the task for generating a defined state is supplied at the beginning of the processing. Then it is branched to the function block 3, 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 executed again.
  • a branch is made in a query block 11, where it is checked whether the computer program has been completed. If so, a branch is made to function block 6 at the end of the computer program. Otherwise, a branch is made to a function block 12 where, according to the current task status, a further return point is generated, by providing safe relevant task input variables which are sufficient for the task to be assigned again start, be defined and saved. 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 that, for example, particularly important tasks are repeated several times before a permanent 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.
  • the task has a longer time, or more runs, until the transient error no longer occurs.
  • a permanent error is detected and a corresponding action is initiated.
  • 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.
  • the blocks 7 to 9 can be dispensed with, which relate to the error counter logic.
  • 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.
  • 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.
  • FIG. 2 shows a computing device according to the invention for executing a computer program according to its preferred embodiment.
  • the computing device is designated in its entirety 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 may be formed 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 an error detection mechanism for detecting an error during execution of the computer program 23 on the microprocessor 22.
  • the operating system 25 includes an error handling mechanism that, upon detection of a failure, re-executes at least one program object (a task) of the Computer program 23 causes.
  • a method, an operating system and a computing device are proposed in the context of a system strategy according to the invention, which make it possible to incorporate this concept of task repetition with minimal or even no performance overhead. It is based on a system strategy that minimizes the performance overhead and thus the costs for different conditions.
  • an especially already described error detection mechanism is available, which can detect errors during the execution of a task (eg a dual-core mechanism, with redundant processing).
  • transient errors To cover permanent errors, an extension is necessary, eg an error counter as already mentioned.
  • At least two classes of tasks are distinguished.
  • the error detection mechanisms are not already used for all classes of tasks and / or the task repetition is not performed for all classes of tasks.
  • two classes of tasks are distinguished in which only one class carries out a task repetition and / or only one class starts an error detection mechanism.
  • critical and uncritical tasks only errors in the critical tasks are intercepted according to the invention; in particular, the error detection mechanism is used only for the first class.
  • Critical tasks are those in which a correct execution for the overall function or basic functionality of the system is required and must be done at the latest at a certain time in order to obtain this function.
  • Uncritical tasks are those in which the overall system function or even the basic function is either unaffected or not significantly restricted. In particular, a distinction is made in this case between safety-critical and safety-critical functions.
  • first critical class 1 tasks should preferably occupy no more than a certain systemic percentage (eg, 50%) of the total computational time of a run or task processing round.
  • the critical tasks are allotted a maximum of 50% of the total computation time in a critical and uncritical split, so that in the worst case, if all critical tasks are faulty, they can be restarted or calculated.
  • Tl is again calculated instead of Sl. This ensures that the error in Tl is corrected before the calculation of T2. Error detection and handling (including a very probable cure while retaining the fault tolerance properties) thus takes place within the computational time of a task.
  • FIG. 3 a distinction is made between class 1 tasks T1, T2 and T3 and class 2 tasks S1, S2 and S3.
  • the task sequence T1, S1, T2, S2, T3, S3 is shown by way of example in FIG. 3a. If a transient error occurs during T1, T1 is again calculated in the SI time according to FIG. 3b and T2, S2, T3, S3 are connected so that the tarnished error is corrected.
  • FIG. 4 Another system approach for integrating the task repetition is shown in FIG. 4, consisting of FIGS. 4a and 4b.
  • the system should use smaller jitter (in the
  • FIG. 4 a shows a run with the tasks T 1, T 2, T 3, T 4, T 5 and S in the case of error-free execution.
  • there must be at least two classes of tasks eg, as before, critical and uncritical
  • critical and uncritical tasks only errors in the critical tasks are intercepted according to the invention; in particular, the error detection mechanism is used only for the first class. This applies as in FIG. 3.
  • critical tasks are not executed in the event of multiple errors thus depends directly on the length of the uncritical task or idle time S.
  • the entire duration of tasks of the first, critical class 1 can also be selected here in such a way that they preferably occupy no more than a specific system-related percentage (eg 50%) of the total computing time of a pass or a task processing round.
  • a specific system-related percentage eg 50%
  • the critical tasks in a division into critical and uncritical also here for safety reasons a total of at most 50% of the total computing time assigned, so that in the worst case if all critical tasks are faulty they can be restarted or calculated.
  • FIG. 5, consisting of FIGS. 5a and 5b, shows a further approach in which substantially identical conditions apply.
  • the system copes with slightly larger jitters (in the order of a run). This must be through application and platform mechanisms, especially the operating system.
  • there are at least two classes of tasks e.g., critical T1-T5 and non-critical S).
  • the error detection mechanism is used only for the first class (T1-T5). Transient errors in a second-class task can also be ignored here.
  • a task of the second class can not "get in”, ie that from a system point of view it does not have serious consequences if a task of this class is not called in a round, since at least one uncritical task has to be executed per pass or Cycle that lasts as long as the longest of the critical tasks (can also be realized here as idle time). (Considerations as above in Figure 3 and 4).
  • Tl there are Tl, ..., Tn (all critical) tasks to be executed in this run. Furthermore, there is at least one task S after Tn, which is uncritical and longer than every single Ti.
  • Tn the sequence without faulty task is shown for this with the sequence T 1, T 2, T 3, T 4, T 5 and S for one pass.
  • T3 Upon detection of an error in Ti, e.g. According to FIG. 5b in T3, the result of Ti (T3) is now declared to be irrelevant, and in contrast to the previous examples, the other tasks (T4, T5) are executed. After Tn (T5) is done, Ti (T3) is calculated again.
  • the prerequisite is a system design that does not require that the results of tasks from one round be required from other tasks of the same round (compulsorily), as this does not respect the order of the tasks.
  • Embodiment with any other invention can be combined.
  • an optimal FO property (FO: Fail operation (al), Fault operation (al)) with respect to transient errors, even with a very short healing time, which heals the FO property itself, can be achieved.
  • This approach can also be used very well in time-controlled systems and can be optimized to that extent.

Abstract

Die Erfindung betrifft ein Verfahren Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor, wobei das Computerprogramm mehrere Programmobjekte umfasst und bei dem Verfahren während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert werden, wobei 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, und nachfolgende weitere Programmobjekte verschoben werden.

Description

Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
Stand der Technik
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.
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 Fehlerbehandlungsmechanismen können auf transiente Fehler, die bei der Abarbeitung eines Computerprogramms auf einem Rechengerät auftreten, nicht in geeigneter Weise reagieren.
Transiente Fehler sind aber gerade in künftigen Technologien sehr häufig. Falls man sie entdeckt z.B. über Dual Core Mechanismen, dann bleibt somit immer noch die Frage einer Fehlerlokalisierung zu beantworten, um das korrekte Resultat zu identifizieren. Dies gilt um so mehr, wenn man das Ziel hat, dass ein transienter Fehler nicht immer einen Neustart des Rechners zur Folge hat. Eine Fehlerlokalisierung ist typischerweise wie beschrieben nur über vergleichsweise aufwändige Verfahren zu erreichen.
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.
Auf Systemebene stellt sich allerdings weiterhin die Frage, wie man ein solches Konzept der Taskwiederholung vernünftig einsetzen kann. Es ist in der Regel nicht der Fall, dass man ein beliebiges fehlerhaftes Task einfach nochmals rechnen kann, da die zusätzlich benötigte Rechenzeit und auch der dafür verwendete Zeitpunkt aus Systemsicht anders verplant sind. Wenn die Auslastung des Prozessors schon nahe 100% ist (und das ist sie in der Regel), dann wird durch eine solche ungeplante Zusatzlast (wie sie eine Taskwiederholung darstellt) eine Überlastung des Systems erzeugt, die typischerweise zu einem Zusammenbruch führen kann. Noch deutlicher wird dies, wenn man zeitgesteuerte Systeme betrachtet (die sich, wie es sich abzeichnet, zumindest teilweise durchsetzen werden). Bei diesen ist eine Deadlineverletzung nicht tolerierbar, ebenso wenig wie bei den meisten anderen harten Echtzeitkonzepten.
Als Konsequenz ergibt sich, dass man also aus Systemsicht die Zusatzlast, die durch eine potenzielle Taskwiederholung entstehen kann, einplanen muss. Wenn man nach jedem Task die Rechenzeit vorhält, die eine Taskwiederholung benötigt, so ist das sicherlich funktionsfähig, allerdings muss man gegenüber einem nicht-fehlerbehandelnden System 100% zusätzliche Performanz bezahlen. Aus Kostensicht ist das nicht akzeptabel.
Es ist daher weiterhin Aufgabe der Erfindung eine optimale Systemstrategie anzugeben, die das zweifache Rechnen eines Tasks nicht immer einplant (und damit einen permanenten und sehr großen Overhead erzeugt) und gleichzeitig die Frage löst, wie sich das mit zeitgesteuerten Ansätzen verbinden lässt.
Vorteile der Erfindung Es wird somit ein Verfahren, eine Betriebssystem und eine Rechengerät im Rahmen einer erfindungsgemäßen Systemstrategie vorgeschlagen, die es erlauben, das Konzept der Taskwiederholung mit minimalem oder sogar ohne Performanzoverhead einzubinden. Eine solche Systemstrategie ist dabei eine Randbedingung für Schedulingverfahren von Tasks, Aufgaben, Programmen oder Programmteilen, welche im Weiteren insbesondere als Programmobjekt oder Programmobjekte bezeichnet werden.
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 Roll-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.
Günstiger ist es somit im Vergleich zum Stand der Technik, das fehlerhafte Task, also die fehlerhafte Aufgabe bzw. das fehlerhafte Programm oder Programmteil bzw. Programmobjekt oder mindestens Betriebssystemobjekt nochmals zu rechnen. Falls der Fehler ursprünglich transient war, sind bei einer Neuberechnung die beiden Outputs gleich, der Fehler ist also verschwunden und durch die Neuberechnung behandelt.
Vorteilhafter Weise wird somit ein Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor dargestellt, wobei das Computerprogramm mehrere Programmobjekte umfasst und bei dem Verfahren während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert werden, wobei 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, und nachfolgende weitere Programmobjekte verschoben werden.
Zweckmäßiger Weise werden die Programmobjekte in wenigstens zwei Klassen unterteilt, wobei bei einer Detektion eines Fehlers Programmobjekte der ersten Klasse wiederholt werden und bei einer Detektion eines Fehlers in einem Programmobjekt der ersten Klasse, das bereits einer Abarbeitung zugeführt wurde, dieses Programmobjekt der ersten Klasse anstelle eines Programmobjektes der zweiten Klasse erneut gestartet wird. Dabei wird die Detektion eines Fehler nur in Klassen durchgeführt, die erneut gestartet werden.
Zweckmäßiger Weise ist für alle Programmobjekte eine Gesamtrechenzeit in einem Durchlauf vorgesehen und die Gesamtrechenzeit wird derart aufgeteilt, dass die Programmobjekte welche bei Detektion eines Fehlers erneut gestartet werden im fehlerfreien Fall höchstens 50% der Gesamtrechenzeit in einem Durchlauf erhalten, wobei die Programmobjekte der unterschiedlichen Klassen abwechselnd abgearbeitet werden und das fehlerhafte Programmobjekt der ersten Klasse anstelle des direkt nachfolgenden Programmobjektes der zweiten Klasse abgearbeitet bzw. erneut gestartet wird.
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 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 Überschreiten 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 speziell 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 insbesondere 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 Fehlerentdeckungsmechanismus 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 Ausfuhrungsform 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:
Figur 1 Ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens gemäß seiner bevorzugten Ausführungsform; und
Figur 2 ein erfindungsgemäßes Rechengerät gemäß seiner bevorzugten Ausführungsform in einer schematischen Darstellung, und
Figur 3 bestehend aus den Figuren 3a und 3b einen ersten erfindungsgemäßen Ansatz zur Einbindung der Taskwiederholung, und
Figur 4 bestehend aus den Figuren 4a und 4b einen zweiten erfindungsgemäßen Ansatz zur Einbindung der Taskwiederholung, und Figur 5 bestehend aus den Figuren 5a und 5b einen dritten erfindungsgemäßen Ansatz zur Einbindung der Taskwiederholung.
Beschreibung der Ausfiihrungsbeispiele
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.
Es wird somit ein Verfahren, eine Betriebssystem und eine Rechengerät im Rahmen einer erfindungsgemäßen Systemstrategie vorgeschlagen, die es erlauben, dieses Konzept der Taskwiederholung mit minimalem oder sogar ohne Performanzoverhead einzubinden. Es wird dabei eine Systemstrategie zugrunde gelegt, die bei jeweils unterschiedlichen Voraussetzungen den Performanzoverhead und damit die Kosten minimiert. Generell wird dabei vorausgesetzt, dass ein insbesondere bereits beschriebener Fehlerentdeckungsmechanismus zur Verfugung steht, der Fehler beim Ablauf eines Tasks entdecken kann (z.B. ein Dual Core Mechanismus, mit redundanter Verarbeitung). Weiter wird hier speziell auf transiente Fehler eingegangen. Um permanente Fehler abzudecken, ist eine Erweiterung notwendig z.B. ein Fehlerzähler wie bereits erwähnt.
Bei der erfindungsgemäßen Strategie zur Einbindung der Taskwiederholung, wie diese in Figur 3 beschrieben wird, sind einige Voraussetzungen zu beachten:
Es werden mindestens zwei Klassen von Tasks (z.B. kritsche und unkritische Tasks) unterschieden. Dabei werden bereits die Fehlerentdeckungsmechanismen nicht für alle Klassen von Tasks eingesetzt und/oder die Taskwiederholung wird nicht für alle Klassen von Tasks durchgeführt.
Im Beispiel von Figur 3 werden zwei Klassen von Tasks unterschieden, bei denen nur bei einer Klasse eine Taskwiederholung durchgeführt wird und/oder nur bei einer Klasse ein Fehlerentdeckungsmechanismus gestartet wird. Bei einer Unterscheidung in kritische und unkritische Tasks, werden eben nur Fehler in den kritischen Tasks erfindungsgemäß abgefangen, insbesondere wird nur für die erste Klasse der Fehlerentdeckungsmechanismus eingesetzt. Kritische Tasks sind dabei solche bei denen eine korrekte Abarbeitung für die Gesamtfunktion oder grundlegende Funktionalität des Systems erforderlich ist und spätestens zu einem bestimmten Zeitpunkt erfolgt sein muss um diese Funktion zu erhalten. Unkritische Tasks sind solche bei denen die Gesamtsystemfunktion oder auch die grundlegende Funktion entweder nicht betroffen oder nicht wesentlich eingeschränkt wird. Insbesondere wird bei einem System dabei zwischen sicherheitskritischen und sicherheitsunkritischen Funktionen unterschieden.
Transiente Fehler in einem Task der zweiten, also hier unkritischen Klasse 2 können ignoriert werden. Weiter gilt wie ausgeführt, dass ein Task der zweiten Klasse auch mal nicht
„drankommen darf", d.h. dass es aus Systemsicht keine gravierenden Folgen hat, wenn ein Task dieser zweiten Klasse in einer Taskverarbeitungsrunde nicht aufgerufen wird. Darüber hinaus sollte die gesamte Laufzeit von Tasks der ersten, kritischen Klasse 1 vorzugsweise nicht mehr als einen bestimmten systembedingten Prozentsatz (z.B. 50%) der Gesamtrechenzeit eines Durchlaufs bzw. einer Taskverarbeitungrunde beanspruchen. Dabei sind den kritischen Tasks bei einer Zweiteilung in kritische und unkritische insgesamt höchstens 50% der Gesamtrechenzeit zugewiesen, so dass im worst case wenn alle kritischen Tasks fehlerhaft sind diese erneut gestartet bzw. gerechnet werden können.
Dann ist ein Systemansatz gemäß Figur 3 möglich, bei dem sich Tasks der verschiedenen Klassen abwechseln so, dass der „Nachfolger" Sl (Klasse 2) eines Tasks Tl (Klasse 1) im Zeitplan mindestens ebensoviel Zeit erhält, wie die WCET (worst case execution time) von Tl.
Grundidee ist dann, dass bei Auftreten eines transienten Fehlers in Tl an Stelle von Sl nochmals Tl gerechnet wird. Damit ist sichergestellt, dass der Fehler in Tl vor der Berechnung von T2 behoben ist. Fehlererkennung und -behandlung (einschließlich einer sehr wahrscheinlichen Heilung unter Beibehaltung der Fehlertoleranzeigenschaften) finden damit innerhalb der Rechenzeit eines Tasks statt.
In Figur 3 wird dazu zwischen Klasse 1 Tasks Tl, T2 und T3 und Klasse 2 Tasks Sl, S2 und S3 unterschieden. Bei Fehlerfreier Ausführung ist in Figur 3a die Taskabfolge Tl, Sl, T2, S2, T3, S3 beispielhaft dargestellt. Bei Auftreten eines Transienten Fehlers während Tl wird gemäß Figur 3b Tl in der Sl Zeit nochmals gerechnet und anschließen T2, S2, T3, S3, so dass der tarnsiente Fehler korrigiert wird.
Ein weiterer Systemansatz zur Einbindung der Taskwiederholung ist in Figur 4, bestehend aus den Figuren 4a und 4b dargestellt. Dabei sollte das System mit kleineren Jittern (in der
Größenordnung einer Taskrechenzeit) zurecht kommen. Dies sollte sich vorzugsweise durch Anwendung und Plattformmechanismen (vor allem wohl Betriebssystem) hindurchziehen. In Figur 4a ist dabei ein Durchlauf mit den Tasks Tl, T2, T3, T4, T5 und S bei fehlerfreier Ausführung dargestellt. Wieder muss es mindestens zwei Klassen von Tasks (z.B. wie vorher kritsche und unkritische) geben bei denen hier im Beispiel nur bei einer Klasse eine Taskwiederholung durchgeführt wird und/oder nur bei einer Klasse ein Fehlerentdeckungsmechanismus gestartet wird. Bei einer Unterscheidung in kritische und unkritische Tasks, werden eben nur Fehler in den kritischen Tasks erfindungsgemäß abgefangen, insbesondere wird nur für die erste Klasse der Fehlerentdeckungsmechanismus eingesetzt. Dies gilt wie bei Figur 3.
So können auch hier transiente Fehler in einem Task der zweiten Klasse ignoriert werden. Weiter gilt auch hier, dass ein Task der zweiten Klasse auch mal nicht „drankommen darf", d.h. dass es aus Systemsicht keine gravierenden Folgen hat, wenn ein Task dieser Klasse in einer Runde nicht aufgerufen wird. Schließlich muss es mindestens ein unkritisches Task pro Durchlauf oder Zyklus, also Taskrechenrunde geben, das so lange dauert wie das längste der kritischen Tasks. Diese wenigstens eine unkritische Task kann auch als idle Zeit realisiert werden, was natürlich auch für das Beispiel nach Figur 3 gilt.
Im Beispiel wird nun angenommen, dass es gibt in einem Durchlauf oder Zyklus die Tasks Ti von Tl, ..bis .,Tn (mit n als natürlicher Zahl, hier 5) gibt, die alle kritisch sind und die im wesentlichen in dieser Reihenfolge abgearbeitet werden sollen. Weiter gibt es noch mindestens ein Task S nach Tn, das unkritisch und länger als jedes einzelne Ti ist. In Figur 4b ist nun in Task T3 ein transienter Fehler aufgetreten. Bei Detektion eines Fehlers in Ti wird das Task Ti einfach sofort wiederholt und der Rest, also T4 und T5 nach hinten geschoben, entsprechend Figur 4b. So lange nur ein transienter Fehler im Durchlauf auftritt fällt keines der kritischen Tasks unter den Tisch und keines wird in der Ausführung um mehr als die maximale Tasklänge nach hinten geschoben. Ob dabei bei mehreren Fehlern kritische Tasks nicht ausgeführt werden hängt somit direkt von der Länge der unkritischen Task bzw. der idle Zeit S ab. Aus Sicherheitsgründen kann auch hier die gesamte Laufzeit von Tasks der ersten, kritischen Klasse 1 so gewählt werden, dass diese vorzugsweise nicht mehr als einen bestimmten systembedingten Prozentsatz (z.B. 50%) der Gesamtrechenzeit eines Durchlaufs bzw. einer Taskverarbeitungrunde beanspruchen. Dabei sind den kritischen Tasks bei einer Zweiteilung in kritische und unkritische auch hier aus Sicherheitsaspekten insgesamt höchstens 50% der Gesamtrechenzeit zugewiesen, so dass im worst case wenn alle kritischen Tasks fehlerhaft sind diese erneut gestartet bzw. gerechnet werden können.
Figur 5 bestehend aus Figur 5a und 5b zeigt einen weiteren Ansatz, bei welchem im wesentlichen übereinstimmende Voraussetzungen gelten. Hier kommt das System mit etwas größeren Jittern (in der Größenordnung eines Durchlaufs) zurecht. Dies muss sich durch Anwendung und Plattformmechanismen, insbesondere das Betriebssystem hindurchziehen. Wieder gibt es mindestens zwei Klassen von Tasks (z.B. kritsche T1-T5 und unkritische S). Auch hier wird nur für die erste Klasse (T1-T5) der Fehlerentdeckungsmechanismus eingesetzt. Transiente Fehler in einem Task der zweiten Klasse können auch hier ignoriert werden. Weiter muss gelten, dass ein Task der zweiten Klasse auch mal nicht „drankommen darf", d.h. dass es aus Systemsicht keine gravierenden Folgen hat, wenn ein Task dieser Klasse in einer Runde nicht aufgerufen wird. Schließlich muss es mindestens ein unkritisches Task pro Durchlauf oder Zyklus geben, das so lange dauert wie das längste der kritischen Tasks (kann auch hier als idle time realisiert werden). (Überlegungen wie oben bei Figur 3 und 4).
Angenommen, es gibt in einem Durchlauf die Tasks Tl,...,Tn (alle kritisch), die in diesem Durchlauf abgearbeitet werden sollen. Weiter gebe es noch mindestens ein Task S nach Tn, das unkritisch und länger als jedes einzelne Ti ist. In Figur 5a ist dazu der Ablauf ohne fehlerhafte Task dargestellt mit der Reihenfolge Tl, T2, T3, T4, T5 und S für einen Durchlauf.
Bei Detektion eines Fehlers in Ti, wie z.B. entsprechend Figur 5b in T3, wird nun das Ergebnis von Ti (T3) als irrelevant erklärt und im Gegensatz zu den vorherigen Beispielen werden die anderen Tasks (T4, T5) abgearbeitet. Nach dem Tn (T5) erledigt ist, wird Ti (T3) nochmals gerechnet. Voraussetzung ist dabei ein Systemdesign, das es nicht fordert, dass die Ergebnisse von Tasks einer Runde von anderen Tasks der selben Runde noch (zwingend) benötigt werden, da hierbei die Reihenfolge der Tasks nicht eingehalten wird.
Diese Systemansätze werden entsprechend der Ausführungen zu den Figuren 1 und 2 mit der entsprechenden Vorrichtung ausgeführt, so dass bezüglich der Offenbarung ausdrücklich jede
Ausführungsform mit jeder anderen erfindungsgemäß kombinierbar ist. Dadurch ist erfindungsgemäß eine optimale FO-Eigenschaft (FO: Fail Operation(al), Fault Operation(al)) bzgl. transienter Fehler, sogar mit einer sehr kurzen Heilungszeit, die die FO- Eigenschaft selbst wieder heilt erzielbar. Dieser Ansatz ist auch sehr gut in zeitgesteuerten Systemen einsetzbar und dahingehend optimierbar.

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, und nachfolgende weitere Programmobjekte verschoben werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programmobjekte in wenigstens zwei Klassen unterteilt werden, wobei bei einer Detektion eines Fehlers Programmobjekte der ersten Klasse wiederholt werden und dass bei einer Detektion eines Fehlers in einem Programmobjekt der ersten Klasse, das bereits einer Abarbeitung zugeführt wurde, dieses Programmobjekt erneut gestartet wird und nachfolgende weitere Programmobjekte der ersten Klasse verschoben werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Detektion eines Fehlers nur in Klassen durchgeführt wird, die erneut gestartet werden.
4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass für alle Programmobjekte eine Gesamtrechenzeit in einem Durchlauf vorgesehen ist und die Gesamtrechenzeit derart aufgeteilt wird, dass die Programmobjekte welche bei Detektion eines Fehlers erneut gestartet werden im fehlerfreien Fall höchstens 50% der Gesamtrechenzeit in einem Durchlauf erhalten.
5. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Programmobjekte der unterschiedlichen Klassen abwechselnd abgearbeitet werden.
6. Verfahren nach Anspruch 2 und 5, dadurch gekennzeichnet, dass das fehlerhafte Programmobjekt der ersten Klasse anstelle des direkt nachfolgenden Programmobjektes der zweiten Klasse abgearbeitet wird.
7. 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.
8. Verfahren nach Anspruch 1 oder 6, dadurch gekennzeichnet, dass ein zum Zeitpunkt der Detektion des Fehlers ausgeführtes Programmobjekt erneut ausgeführt wird.
9. Verfahren nach Anspruch 1, 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.
10. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren in einem Kraftfahrzeug, insbesondere in einem Kraftfahrzeugsteuergerät, verwendet wird.
11. Verfahren nach Anspruch 1 , 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 Anspruch 1, 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. 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 12 programmiert ist und das erfindungsgemäße Verfahren ausführt, wenn es auf dem Rechengerät (20) abläuft.
14. 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, und nachfolgende weitere Programmobjekte verschoben werden.
15. Rechengerät nach Anspruch 14, dadurch gekennzeichnet, dass der Fehlerbehandlungsmechanismus derart ausgebildet ist, dass die Programmobjekte in wenigstens zwei Klassen unterteilt werden, wobei bei einer Detektion eines Fehlers in einem Programmobjekt der ersten Klasse dieses anstelle eines Programmobjektes der zweiten Klasse erneut gestartet wird.
16. Rechengerät (20) nach Anspruch 14, dadurch gekennzeichnet, dass der Fehlerbehandlungsmechanismus eine Triggerlogik aufweist, welche bei einer Detektion eines Fehlers das mindestens eine Programmobjekt neu startet.
17. Rechengerät (20) nach Anspruch 14, dadurch gekennzeichnet, dass auf dem Rechengerät (20) ein Echtzeit-Betriebssystem (25) abläuft.
PCT/EP2005/055390 2004-10-25 2005-10-19 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms WO2006045733A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US11/665,726 US7711985B2 (en) 2004-10-25 2005-10-19 Restarting an errored object of a first class
EP05803095A EP1812853B1 (de) 2004-10-25 2005-10-19 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
DE502005005915T DE502005005915D1 (de) 2004-10-25 2005-10-19 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
JP2007537272A JP4596488B2 (ja) 2004-10-25 2005-10-19 コンピュータプログラムを処理する方法、駆動システム、および計算装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004051967A DE102004051967A1 (de) 2004-10-25 2004-10-25 Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102004051967.6 2004-10-25

Publications (2)

Publication Number Publication Date
WO2006045733A2 true WO2006045733A2 (de) 2006-05-04
WO2006045733A3 WO2006045733A3 (de) 2006-07-20

Family

ID=36129013

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/055390 WO2006045733A2 (de) 2004-10-25 2005-10-19 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms

Country Status (7)

Country Link
US (1) US7711985B2 (de)
EP (1) EP1812853B1 (de)
JP (1) JP4596488B2 (de)
CN (1) CN100511165C (de)
AT (1) ATE413646T1 (de)
DE (2) DE102004051967A1 (de)
WO (1) WO2006045733A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008011848A1 (de) * 2006-07-26 2008-01-31 Nokia Siemens Networks Gmbh & Co. Kg Verfahren und system zur erneuten berechnung von gebühren eines bereits mit anderen, auch fehlerhaften tarifparametern vergebührten ereignisses
EP2568346B1 (de) 2011-09-06 2015-12-30 Airbus Operations Robustes Systemsteuerungsverfahren mit kurzen Ausführungsfristen
US9734006B2 (en) * 2015-09-18 2017-08-15 Nxp Usa, Inc. System and method for error detection in a critical system
US11305810B2 (en) 2020-04-24 2022-04-19 Steering Solutions Ip Holding Corporation Method and system to synchronize non-deterministic events

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006015945A2 (de) * 2004-08-04 2006-02-16 Robert Bosch Gmbh Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3248697A (en) * 1962-11-27 1966-04-26 Ibm Error classification and correction system
US5138708A (en) * 1989-08-03 1992-08-11 Unisys Corporation Digital processor using current state comparison for providing fault tolerance
US5269017A (en) * 1991-08-29 1993-12-07 International Business Machines Corporation Type 1, 2 and 3 retry and checkpointing
US5815651A (en) * 1991-10-17 1998-09-29 Digital Equipment Corporation Method and apparatus for CPU failure recovery in symmetric multi-processing systems
US5530802A (en) * 1994-06-22 1996-06-25 At&T Corp. Input sequence reordering method for software failure recovery
JPH10326220A (ja) * 1997-05-27 1998-12-08 Toshiba Corp ファイルシステムおよびファイル管理方法
JPH117431A (ja) * 1997-06-16 1999-01-12 Hitachi Ltd 複数コンピュータで実行する業務の障害回復システム
US6205542B1 (en) * 1997-12-24 2001-03-20 Intel Corporation Processor pipeline including replay
US20040064756A1 (en) * 2002-09-26 2004-04-01 Sudarshan Kadambi Method and apparatus for improving reliability in computer processors by re-executing instructions
FR2869430A1 (fr) * 2004-04-27 2005-10-28 St Microelectronics Sa Controle de l'execution d'un algorithme par un circuit integre

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006015945A2 (de) * 2004-08-04 2006-02-16 Robert Bosch Gmbh Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
GHOSH S ET AL: "FAULT-TOLERANT RATE-MONOTONIC SCHEDULING" REAL TIME SYSTEMS, KLUWER ACADEMIC PUBLISHERS, DORDRECHT, NL, Bd. 15, Nr. 2, September 1998 (1998-09), Seiten 149-181, XP000790355 ISSN: 0922-6443 *
HONG Y S ET AL: "A fault tolerant technique for scheduling periodic tasks in real-time systems" SOFTWARE TECHNOLOGIES FOR FUTURE EMBEDDED AND UBIQUITOUS SYSTEMS, 2004. PROCEEDINGS. SECOND IEEE WORKSHOP ON VIENNA, AUSTRIA 11-12 MAY 2004, PISCATAWAY, NJ, USA,IEEE, 11. Mai 2004 (2004-05-11), Seiten 135-138, XP010707048 ISBN: 0-7695-2123-1 *
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 *
LIU J W S ET AL: "IMPRECISE COMPUTATIONS" PROCEEDINGS OF THE IEEE, IEEE. NEW YORK, US, Bd. 82, Nr. 1, Januar 1994 (1994-01), Seiten 83-93, XP000435883 ISSN: 0018-9219 *
RAMOS-THUEL S ET AL: "The transient server approach to scheduling time-critical recovery operations" PROCEEDINGS OF THE REAL TIME SYSTEMS SYMPOSIUM. SAN ANTONIO, DEC. 4 - 6, 1991, LOS ALAMITOS, IEEE. COMP. SOC. PRESS, US, Bd. SYMP. 12, 4. Dezember 1991 (1991-12-04), Seiten 286-295, XP010026216 ISBN: 0-8186-2450-7 *

Also Published As

Publication number Publication date
DE502005005915D1 (de) 2008-12-18
WO2006045733A3 (de) 2006-07-20
JP2008518292A (ja) 2008-05-29
US7711985B2 (en) 2010-05-04
CN101048742A (zh) 2007-10-03
EP1812853B1 (de) 2008-11-05
ATE413646T1 (de) 2008-11-15
EP1812853A2 (de) 2007-08-01
CN100511165C (zh) 2009-07-08
JP4596488B2 (ja) 2010-12-08
DE102004051967A1 (de) 2006-04-27
US20080162989A1 (en) 2008-07-03

Similar Documents

Publication Publication Date Title
WO2006015945A2 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
EP1810139B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
EP1917592B1 (de) Rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit sowie verfahren zu dessen steuerung
DE102014002473A1 (de) System und verfahren zur erhöhung der lockstep-kern-verfügbarkeit
DE10049441A1 (de) Verfahren zum Betrieb eines von einem Prozessor gesteuerten Systems
DE102013015172A1 (de) Challenge-and-response-Verfahren für Sicherheitssystem unter Verwendung eines modifizierten Watchdog-Zeitgebers
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
DE112010005400T5 (de) System für gegenseitige Überwachung von Mikrocomputern und ein Verfahren für gegenseitige Überwachung von Mikrocomputern
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
EP1812853B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
EP2085883A1 (de) Verfahren zur Behandlung von transienten Fehlern in Echtzeitsystemen, insbesondere in Steuergeräten von Kraftfahrzeugen
EP1805617A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE102008024193A1 (de) System mit konfigurierbaren Funktionseinheiten und Verfahren
EP1359485B1 (de) Steuer- und Überwachungssystem
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
WO2016206847A1 (de) Verfahren und vorrichtung zum absichern einer programmzählerstruktur eines prozessorsystems und zum überwachen der behandlung einer unterbrechungsanfrage
EP2338111B1 (de) Verfahren und vorrichtung zum testen eines rechnerkerns in einer mindestens zwei rechnerkerne aufweisenden recheneinheit
WO2007017372A1 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems mit wenigstens zwei ausführungseinheiten
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
DE102023004853A1 (de) Verfahren zur Fehlerbehebung von sicherheitsrelevanten mikrocontrollergesteuerten Anwendungen in einem Kraftfahrzeug, sicherheitsrelevanten Computerprogrammprodukt, sicherheitsrelevanten Mikrocontroller, sowie Kraftfahrzeug
WO2003032162A2 (de) Verfahren zum überprüfen eines rechnerkerns eines mikroprozessors oder eines mikrocontrollers
DE10229817A1 (de) Verfahren und Vorrichtung zum Ablegen eines Computerprogramms in einen Programmspeicher eines Steuergeräts

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 BW BY BZ CA CH CN CO CR CU CZ DM DZ EC EE EG ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KM KP KZ LC LK LR LS LT LU LV LY MA MG MK MN MW MX MZ NA NG NI NZ OM PG PH PL PT RO RU SC SD SE SK SL SM SY TJ TM TN TR TT TZ UA US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

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

WWE Wipo information: entry into national phase

Ref document number: 2005803095

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007537272

Country of ref document: JP

Ref document number: 200580036496.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2005803095

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11665726

Country of ref document: US