Die vorliegende Erfindung betrifft ein Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor. Das Computerprogramm umfasst mehrere Programmobjekte. Bei dem Verfahren werden während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert.

Die Erfindung betrifft außerdem ein Betriebssystem, das auf einem Rechengerät, insbesondere auf einem Mikroprozessor, ablauffähig ist.

Schließlich betrifft die vorliegende Erfindung auch ein Rechengerät zum Abarbeiten eines Computerprogramms, das mehrere Programmobjekte umfasst. Das Rechengerät weist einen Fehlerentdeckungsmechanismus zur Detektion eines Fehlers während der Abarbeitung des Computerprogramms auf dem Rechengerät auf.

Stand der Technik

Bei der Abarbeitung eines Computerprogramms auf einem Rechengerät kann es zu sogenannten transienten Fehlern kommen. Da die Strukturen auf den Halbleiterbausteinen (sog. Chips) immer kleiner, die Taktrate der Signale aber immer größer und die Spannungen der Signale immer niedriger werden, treten transiente Fehler immer häufiger auf. Transiente Fehler treten im Gegensatz zu permanenten Fehlern nur temporär auf und verschwinden nach einiger Zeit in der Regel von selbst wieder. Bei transienten Fehlern sind lediglich einzelne Bits falsch, ohne dass das Rechengerät an sich permanent beschädigt ist. Transiente Fehler können verschiedene Ursachen haben, wie beispielsweise elektromagnetische Einflüsse, Alpha-Partikel oder Neutronen.

Bei Kommunikationssystemen liegt schon heute der Schwerpunkt bei der Fehlerbehandlung auf transienten Fehlern. Bei Kommunikationssystemen (z.B. bei dem Controller Area Network, CAN) ist es bekannt, bei der Detektion eines Fehlers die fehlerhaft übermittelten Daten erneut zu senden. Außerdem ist es bekannt, in Kommunikationssystemen einen Fehlerzähler einzusetzen , der bei Detektion eines Fehlers erhöht wird, bei korrektem Senden erniedrigt wird, und ein Senden von Daten verhindert, sobald er einen bestimmten Wert überschreitet.

Bei Rechengeräten zur Abarbeitung von Computerprogrammen erfolgt eine Fehlerbehandlung jedoch im Wesentlichen nur für permanente Fehler. Eine Berücksichtigung transienter Fehler beschränkt sich auf das Inkrementieren und gegebenenfalls Dekrementieren eines Fehlerzählers. Dieser wird in einem Speicher abgelegt und kann off-line, das heißt beispielsweise bei einem als Kraftfahrzeugsteuergerät ausgebildeten Rechengerät während eines Werkstattaufenthalts, als Diagnose- oder Fehlerinformation ausgelesen werden. Erst dann kann auf den Fehler entsprechend reagiert werden.

Die Fehlerbehandlung mittels Fehlerzähler erlaubt also zum einen keine Fehlerbehandlung innerhalb einer insbesondere für sicherheitsrelevante Systeme erforderlichen kurzen Fehlertoleranzzeit und zum anderen auch keine konstruktive Fehlerbehandlung in dem Sinne, dass innerhalb der Fehlertoleranzzeit das Computerprogramm wieder ordnungsgemäß abgearbeitet wird. Statt dessen wird beim Stand der Technik das Computerprogramm nach dem Überschreiten eines bestimmten Wertes des Fehlerzählers in einen Notlaufbetrieb umgeschaltet. Das bedeutet,

dass statt des fehlerbehafteten Teils des Computerprogramms ein anderes abgearbeitet wird und die auf diese Weise ermittelten Ersatzwerte für die weitere Berechnung herangezogen werden. Die Ersatzwerte können beispielsweise anhand anderer Größen modelliert werden. Alternativ können die mit dem fehlerbehafteten Teil des Computerprogramms berechneten Ergebnisse als fehlerhaft verworfen und durch für den Notlaufbetrieb vorgesehene Standardwerte für die weitere Berechnung ersetzt werden. Die bekannten Verfahren zur Behandlung eines transienten Fehlers eines auf einem Rechengerät ablaufenden Computerprogramms erlauben somit keinen systematischen, konstruktiven Umgang mit der transienten Natur der meisten Fehler.

Aus dem Stand der Technik ist es außerdem bekannt, bei der Abarbeitung eines Computerprogramms auf einem Rechengerät auftretende transiente Fehler durch einen kompletten Neustart des Rechengeräts zu beheben. Auch diese Lösung kann nicht wirklich befriedigen, da in dem bisherigen Verlauf der Abarbeitung des Computerprogramms gewonnene Größen verloren gehen und das Rechengerät für die Dauer des Neustarts seine bestimmungsgemäße Funktion nicht erfüllen kann. Dies ist insbesondere bei sicherheitsrelevanten Systemen inakzeptabel.

Schließlich ist es als Fehlerbehandlung für transiente Fehler eines auf einem Rechengerät abgearbeiteten Computerprogramms auch bekannt, das Computerprogramm um einige Takte zurückzusetzen und einzelne Maschinenbefehle des Computerprogramms zu wiederholen. Dieses Verfahren wird auch als Micro Roll-Back bezeichnet. Bei dem bekannten Verfahren wird nur um Objekte auf Maschinenebene (Takte, Maschinenbefehle) zurückgesprungen. Das erfordert eine entsprechende Hardwareunterstützung auf Maschinenebene, was mit einem erheblichen Aufwand im Bereich des Rechengeräts verbunden ist. Eine Ausführung des bekannten Verfahrens rein durch Software gesteuert ist nicht möglich.

Die aus dem Stand der Technik bekannten 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 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 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 Ausfuhrungsform 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 erfindungsgemäßen Ansatz zur Einbindung der Taskwiederholung.

Beschreibung der Ausführungsbeispiele

Die vorliegende Erfindung betrifft ein Verfahren zum Abarbeiten eines Computerprogramms auf einem Rechengerät, insbesondere auf einem Mikroprozessor. Das Computerprogramm umfasst mehrere Programmobjekte, die vorzugsweise als Tasks ausgebildet sind. Bei dem Verfahren werden während der Abarbeitung des Computerprogramms auf dem Rechengerät Fehler detektiert. Die detektierten Fehler können transienter (also vorübergehender) oder permanenter Art sein.

Die transienten Fehler können bei der Abarbeitung eines Computerprogramms auf einem Rechengerät auftreten. Da die Strukturen auf den Halbleiterbausteinen (sogenannten Chips) der Rechengeräte immer kleiner, die Taktrate der Signale aber immer größer und die Spannungen der Signale immer niedriger werden, treten bei der Abarbeitung eines Computerprogramms auf einem Rechengerät immer häufiger transiente Fehler auf. Im Gegensatz zu permanenten Fehlern treten sie nur temporär auf und verschwinden nach einiger Zeit in der Regel von selbst wieder. Bei transienten Fehlern sind lediglich einzelne Bits falsch, ohne dass das Rechengerät an sich permanent beschädigt ist. Transiente Fehler können verschiedene Ursachen haben, wie beispielsweise elektromagnetische Einflüsse, Alpha-Partikel oder Neutronen.

Aufgrund der Tatsache, dass transiente Fehler nahezu unvorhersehbar auftreten und deshalb nicht reproduzierbar sind, erfolgt bei aus dem Stand der Technik bekannten Rechengeräten eine Fehlerbehandlung im wesentlichen nur für permanente Fehler. Eine Berücksichtigung transienter Fehler beschränkt sich auf das Inkrementieren und gegebenenfalls Dekrementieren eines Fehlerzählers. Dieser wird in einem Speicher abgelegt und kann off-line, das heißt beispielsweise während eines Werkstattaufenthalts, als Diagnose- oder Fehlerinformation ausgelesen werden. Erst dann kann auf den Fehler entsprechend reagiert werden. Die bekannte Fehlerbehandlung erlaubt also keine Fehlerbehandlung innerhalb einer insbesondere für sicherheitsrelevante Systeme erforderlichen kurzen Fehlertoleranzzeit und zum anderen auch keine konstruktive Fehlerbehandlung in dem Sinne, dass innerhalb der Fehlertoleranzzeit das Computerprogramm wieder ordnungsgemäß abgearbeitet wird und das Rechengerät seine bestimmungsgemäße Aufgabe erfüllen kann.

Im Gegensatz dazu erlaubt das erfindungsgemäße Verfahren eine Behandlung eines transienten Fehlers eines auf einem Rechengerät ablaufenden Computerprogramms mit einem systematischen, konstruktiven Umgang mit der transienten Natur der meisten Fehler. Ein Ablaufdiagramm des erfindungsgemäßen Verfahrens am Beispiel eines Laufzeitobjekts, einer sogenannten Task, ist in Fig.l dargestellt. Die Existenz weiterer Tasks beeinflusst den prinzipiellen Ablauf nicht, eine Berücksichtigung entfällt also. So wie gemäß dem in Fig. 1 dargestellten Ablauf eine Task behandelt wird, können erfindungsgemäß also auch mehrere Tasks behandelt werden. Besonders vorteilhaft ist ein parallel arbeitender

Fehlerentdeckungsmechanismus (sog. concurrent checking). Dieser ist in einem Ablaufdiagramm so aber nicht darstellbar, er ist an der entsprechenden Stelle als serieller Baustein eingefügt.

Das erfindungsgemäße Verfahren beginnt in einem Funktionsblock 1. In dem Funktionsblock 1 wird mit der Abarbeitung der Task auf dem Rechengerät begonnen; die Task wird aufgerufen. In einem Funktionsblock 2 wird ein Rücksprungpunkt erzeugt. Zu diesem Zweck werden sichere relevante Taskeingangsgrößen, die ausreichen, die Task in eine definierten Zustand für einen Neustart zu versetzen und die Task nochmals zu starten, in einem Speicherelement des Rechengerätes abgespeichert. Vorzugsweise werden alle Eingangsgrößen der Task abgespeichert. In einem Funktionsblock 3 wird dann die Task weiter abgearbeitet. Die Abarbeitung kann entweder zu einem weiteren Rücksprungpunkt oder bis zum Ende der Task erfolgen. Dann wird ein Fehlerentdeckungsmechanismus ausgeführt. Die Fehlerdetektion kann nach einem beliebigen Verfahren erfolgen. Die Fehler werden während der Abarbeitung des Computerprogramms detektiert (sogenanntes concurrent checking). So ist beispielsweise bei einer sogenannten Dual- Core-Architektur der ganze Rechnerkern zweifach ausgebildet. Wenn die Rechnerkerne in einem sogenannten Lockstep-Modus betrieben werden, kann für jede Instruktion verglichen werden, ob beide Rechnerkerne die gleichen Ergebnisse liefern. Ein Unterschied der Ergebnisse lässt dann mit Sicherheit auf einen Fehler schließen. Ein solcher Fehlerentdeckungsmechanismus entdeckt also Fehler bei der Abarbeitung der Task in Echtzeit. Entsprechendes gilt auch für fehlerentdeckende Codes, die in der Prozessorarchitektur durchgängig verwendet werden oder auch für duplizierte Teilkomponenten des Rechengerätes. Vorzugsweise werden solche

Fehlerentdeckungsmechanismen eingesetzt, die transiente Fehler sehr schnell entdecken und ein Fehlersignal liefern, wenn ein Fehler detektiert wurde.

In einem Abfrageblock 4 wird überprüft, ob ein Fehler, also ein transienter oder ein permanenter Fehler, entdeckt wurde. Falls ein Fehler entdeckt wurde, wird in einen weiteren Abfrageblock 7 verzweigt, wo der aktuelle Wert einer Fehlerzählerlogik überprüft wird. Falls der Fehlerzähler einen vorgebbaren Zählerstand noch nicht unterschritten (bei einem dekrementierenden Fehlerzähler) oder überschritten (bei einem inkrementierenden Fehlerzähler) hat, kann die Task, während deren Abarbeitung der Fehler aufgetreten ist, bzw. können eine bestimmte Anzahl an Tasks, die vor dem Auftreten des Fehlers abgearbeitet wurden, noch einmal ausgeführt werden. Falls ein erneutes Starten der Abarbeitung der Task möglich ist, wird in einem Funktionsblock 8

verzweigt, in dem der Status der Fehlerzählerlogik mit der Information, dass ein weiterer Fehler aufgetreten ist, aktualisiert (dekrementiert oder inkrementiert) wird. Von dort wird in einen Funktionsblock 5 verzweigt, in welchem die in dem Funktionsblock 2 abgespeicherten Größen geladen und der Task zum Erzeugen eines definierten Zustandes zu Beginn der Abarbeitung zugeführt werden. Dann wird zu dem Funktionsblock 3 verzweigt, wo die zu wiederholende Task teilweise, das heißt beispielsweise von einem bereits abgearbeiteten Rücksprungpunkt aus, oder aber als ganzes, das heißt die Task wird von Beginn an noch einmal gestartet, noch einmal abgearbeitet wird.

Falls sich in dem Abfrageblock 4 ergibt, dass während der Abarbeitung der Task in dem Funktionsblock 3 kein Fehler aufgetreten ist, wird in einem Funktionsblock 9 verzweigt, in welchem der Status der Fehlerzählerlogik mit der Information aktualisiert wird, dass kein Fehler detektiert worden ist. Von dort aus wird in einen Abfrageblock 11 verzweigt, wo überprüft wird, ob das Computerprogramm zu Ende abgearbeitet ist. Falls dem so ist, wird zum Ende des Computerprogramms in Funktionsblock 6 verzweigt. Anderenfalls wird in einen Funktionsblock 12 verzweigt, wo entsprechend dem aktuellen Taskstatus ein weiterer Rücksprungpunkt erzeugt wird, indem sichere relevante Taskeingangsgrößen, die ausreichen, um die Task nochmals zu starten, definiert und abgespeichert werden. Von dort aus wird dann wieder zu dem Funktionsblock 3 verzweigt, wo die zu wiederholende Task erneut gestartet und entweder teilweise oder als ganzes noch einmal abgearbeitet wird.

Falls sich in dem Abfrageblock 7 ergibt, dass aufgrund des Standes der Fehlerzählerlogik ein weiterer Versuch zur erneuten Abarbeitung der Task nicht mehr möglich ist, wird in einen Funktionsblock 10 verzweigt. In dem Abfrageblock 7 wird überprüft, ob der Wert der Fehlerzählerlogik für diese Task größer als ein taskabhängiger Wiederholwert ist. Dieser taskabhängige Wiederholwert kann entweder für verschiedene Tasks gleich oder aber individuell für jede Task einzeln vorgegeben werden. Auf diese Weise ist es möglich, dass beispielsweise besonders wichtige Tasks zunächst mehrmals wiederholt werden, bevor ein permanenter Fehler gemeldet wird. Wenn der taskabhängige Wiederholwert als 1 vorgegeben wird, wird die Task nur einmal wiederholt, bevor ein permanenter Fehler detektiert wird. Falls der taskabhängige Wiederholwert auf 2 oder 3 vorgegeben wird, wird die Task 2 oder 3-mal wiederholt, bevor ein permanenter Fehler detektiert wird. Die Task hat in diesem Fall also eine längere Zeit,

beziehungsweise mehr Durchläufe zur Verfugung, 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 überfuhren 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 auszufuhrende(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 ausfuhrt, 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 Ausfuhren 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 Verfügung 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 Ausfuhrung 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.

Dieser Systemansatz wird 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.