[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

DE102004037713A1 - 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
DE102004037713A1
DE102004037713A1 DE102004037713A DE102004037713A DE102004037713A1 DE 102004037713 A1 DE102004037713 A1 DE 102004037713A1 DE 102004037713 A DE102004037713 A DE 102004037713A DE 102004037713 A DE102004037713 A DE 102004037713A DE 102004037713 A1 DE102004037713 A1 DE 102004037713A1
Authority
DE
Germany
Prior art keywords
error
computing device
program
computer program
program object
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004037713A
Other languages
English (en)
Inventor
Reinhard Weiberle
Bernd Müller
Werner Harter
Thomas Kottke
Yorck Von Collani
Rainer Gmehlich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102004037713A priority Critical patent/DE102004037713A1/de
Priority to PCT/EP2005/053621 priority patent/WO2006015945A2/de
Priority to CN2005800262785A priority patent/CN1993679B/zh
Priority to BRPI0513229-0A priority patent/BRPI0513229A/pt
Priority to US11/659,307 priority patent/US7890800B2/en
Priority to JP2007524328A priority patent/JP4728334B2/ja
Priority to EP05777777A priority patent/EP1854007A2/de
Priority to RU2007106437/08A priority patent/RU2431182C2/ru
Publication of DE102004037713A1 publication Critical patent/DE102004037713A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1438Restarting or rejuvenating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking

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

  • 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.
  • 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 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.
  • 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 + 1)-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 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:
  • 1 Ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens gemäß seiner bevorzugten Ausführungsform; und
  • 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 1 dargestellt. Die Existenz weiterer Tasks beeinflusst den prinzipiellen Ablauf nicht, eine Berücksichtigung entfällt also. So wie gemäß dem in 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 Locksteg-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 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 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 (19)

  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.
DE102004037713A 2004-08-04 2004-08-04 Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms Withdrawn DE102004037713A1 (de)

Priority Applications (8)

Application Number Priority Date Filing Date Title
DE102004037713A DE102004037713A1 (de) 2004-08-04 2004-08-04 Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
PCT/EP2005/053621 WO2006015945A2 (de) 2004-08-04 2005-07-25 Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
CN2005800262785A CN1993679B (zh) 2004-08-04 2005-07-25 执行计算机程序的方法、操作系统和计算设备
BRPI0513229-0A BRPI0513229A (pt) 2004-08-04 2005-07-25 processo, sistema operacional e computador para o processamento de um programa de computador
US11/659,307 US7890800B2 (en) 2004-08-04 2005-07-25 Method, operating system and computing hardware for running a computer program
JP2007524328A JP4728334B2 (ja) 2004-08-04 2005-07-25 コンピュータプログラムを処理する方法、オペレーティングシステムおよび計算装置
EP05777777A EP1854007A2 (de) 2004-08-04 2005-07-25 Verfahren, betriebssysem und rechengerät zum abarbeiten eines computerprogramms
RU2007106437/08A RU2431182C2 (ru) 2004-08-04 2005-07-25 Способ, операционная система и вычислительное устройство для выполнения компьютерной программы

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
DE102004037713A1 true DE102004037713A1 (de) 2006-03-16

Family

ID=35395722

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004037713A Withdrawn DE102004037713A1 (de) 2004-08-04 2004-08-04 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)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004051967A1 (de) * 2004-10-25 2006-04-27 Robert Bosch Gmbh Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
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
GB2604089B (en) * 2020-11-27 2024-05-08 Advanced Risc Mach Ltd Data processing systems

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2602891B1 (fr) * 1986-08-18 1990-12-07 Nec Corp Systeme de correction d'erreur d'un systeme a multiprocesseurs pour corriger une erreur dans un processeur en mettant le processeur en condition de controle apres achevement du redemarrage du microprogramme a partir d'un point de reprise
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 株式会社東芝 チェックポイント生成方法
JP3490256B2 (ja) * 1997-06-12 2004-01-26 三菱電機株式会社 エージェント方式
US6625756B1 (en) * 1997-12-19 2003-09-23 Intel Corporation Replay mechanism for soft error recovery
FR2784475B1 (fr) * 1998-10-12 2000-12-29 Centre Nat Etd Spatiales Procede de traitement d'un systeme electronique soumis a des contraintes d'erreurs transitoires
US6366980B1 (en) * 1999-06-04 2002-04-02 Seagate Technology Llc Disc drive for achieving improved audio and visual data transfer
US6584581B1 (en) * 1999-12-06 2003-06-24 Ab Initio Software Corporation Continuous flow checkpointing data processing
JP2001357637A (ja) * 2000-06-14 2001-12-26 Sony Corp 情報再生装置、情報処理方法及び情報記録媒体
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
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
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

Also Published As

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

Similar Documents

Publication Publication Date Title
EP1917592B1 (de) Rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit sowie verfahren zu dessen steuerung
DE102014002473B4 (de) System und verfahren zur erhöhung der lockstep-kern-verfügbarkeit
WO2007057271A1 (de) Vorrichtung und verfahren zum beheben von fehlern bei einem wenigstens zwei ausführungseinheiten mit registern aufweisenden system
DE102012109614A1 (de) Fehlerbehebung bei Stapel-Korruption in eingebetteten Softwaresystemen
DE102004037713A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102008004205A1 (de) Schaltungsanordnung und Verfahren zur Fehlerbehandlung in Echtzeitsystemen
DE102008024193A1 (de) System mit konfigurierbaren Funktionseinheiten und Verfahren
EP2085883A1 (de) Verfahren zur Behandlung von transienten Fehlern in Echtzeitsystemen, insbesondere in Steuergeräten von Kraftfahrzeugen
EP1810139B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
WO2006032617A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
EP1359485B1 (de) Steuer- und Überwachungssystem
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
EP1812853B1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
WO2006032585A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
DE102005054587A1 (de) Programmgesteuerte Einheit und Verfahren zum Betreiben derselbigen
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
WO2003032162A2 (de) Verfahren zum überprüfen eines rechnerkerns eines mikroprozessors oder eines mikrocontrollers
DE102023203238A1 (de) Verfahren zum Betreiben einer Recheneinheit in einem sicheren Betriebsmodus
WO2023232401A1 (de) Verfahren für einen betrieb eines steuergeräts eines fahrzeuges
DE102005061394A1 (de) Fehlertolerantes Prozessorsystem
DE102004047363A1 (de) Prozessor bzw. Verfahren zum Betreiben eines Prozessors und/oder Betriebssystems im Fall einer Störung
DE102006040644A1 (de) Korrekturverfahren für einen neu-programmierbaren Mikroprozessor

Legal Events

Date Code Title Description
R012 Request for examination validly filed

Effective date: 20110428

R084 Declaration of willingness to licence
R084 Declaration of willingness to licence

Effective date: 20150325

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee