DE102007040721A1

DE102007040721A1 - Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher

Info

Publication number: DE102007040721A1
Application number: DE102007040721A
Authority: DE
Original assignee: Technische Universitaet Dresden
Current assignee: Silistra Systems De GmbH
Priority date: 2006-12-08
Filing date: 2007-08-23
Publication date: 2008-06-19
Anticipated expiration: 2027-08-24
Also published as: DE102007040721B4

Abstract

Datenverarbeitungsanordnung aufweisend - einen Speicher, der eine Mehrzahl von Speicherelementen zum Speichern jeweils eines Datenwortes aufweist, - eine Zuordnungseinrichtung, die eingerichtet ist, jedem Speicherelement der Mehrzahl von Speicherelementen eine Signaturinformation zuzuordnen, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, - eine Codiereinrichtung, die eingerichtet ist, einem in einem Speicherelement zu speichernden Datenwort basierend auf der Signaturinformation ein Codewort zuzuordnen und das Codewort in dem Speicherelement zu speichern und - eine Überprüfungseinrichtung, die eingerichtet ist, anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.

Description

Die Erfindung betrifft eine Datenverarbeitungsanordnung, ein Verfahren zur Datenverarbeitung, ein Computerprogrammelement und eine Überprüfungsanordnung für einen Speicher.
Computersysteme werden heutzutage zunehmend für Anwendungen eingesetzt, bei denen es wichtig ist, dass die Computersysteme korrekt arbeiten und Computerprogramme fehlerlos ausführen, beispielsweise für Finanzanwendungen und für Steueranwendungen in Kraftfahrzeugen. Bei Anwendungen dieser Art ist es wichtig, Fehler bei der Ausführung von Programmen, d. h. Laufzeitfehler, zu erkennen. Laufzeitfehler können sowohl transiente Fehler als auch permanente Fehler in der programmausführenden Infrastruktur sein. Sie können zu einer fehlerhaften Programmausgabe oder einem fehlerhaften Programmzustand führen oder geführt haben.
Verfahren zur Detektion von Laufzeitfehlern können nach der Art ihrer Implementierung unterschieden werden:

• Implementierung durch Software, was auch als "Software Implemented Hardware Fault Tolerance" bezeichnet wird;
• Implementierung durch Hardware;
• Kombinierte Verfahren (Hardware/Software).

Im Folgenden werden einige durch Software implementierte Verfahren angesprochen.
Die Druckschriften in [1], [2], [3] und [4] beschreiben Verfahren, die auf der Annahme basieren, dass die durch ein ausgeführtes Programm erzeugten Ergebnisse durch eine Probe auf ihre Korrektheit überprüft werden können. Jedoch existiert nicht für jeden Algorithmus eine solche Probe. Dies schließt eine automatisierte Anwendung solcher Vorgehensweisen auf beliebige Programme aus.
Bei dem in [5] beschriebenen Verfahren wird eine einfache zeitliche Redundanz zur Erkennung von Fehlern ausgenutzt. Dies geschieht derart, dass Programme so verändert werden, dass alle Programminstruktionen doppelt ausgeführt werden. Unterscheiden sich die Ergebnisse zweier Ausführungen derselben Instruktionen, so muss ein Fehler aufgetreten sein. Bei dieser Vorgehensweise ist es jedoch nicht möglich, permanente Fehler zu erkennen, da diese bei jeder Ausführung einer Instruktion auftreten. Außerdem können Fehler unerkannt bleiben oder Fehler vermutet werden, wo keine aufgetreten sind, wenn der Vergleich zweier Ergebnisse nicht korrekt durchgeführt wird. Dies ist möglich, wenn die Überprüfung, also der Vergleich der beiden Ergebnisse, durch dieselbe Infrastruktur durchgeführt wird. Dann ist nicht gewährleistet, dass die Vergleiche korrekt ausgeführt werden, da sie ebenso von transienten oder permanenten Fehlern betroffen sein können wie die übrige Programmausführung. Die Überprüfung sollte von einer redundanten und weniger fehleranfälligen Hardwarekomponente ausgeführt werden. Weiterhin wird für die in [1, 2, 3, 4, 5] beschriebenen Verfahren der Quellcode des zu schützenden Programms benötigt.
Bei der in [6] beschriebenen Vorgehensweise wird eine in den Programmcode eingefügte Redundanz verwendet, um zu testen, ob der bei der Ausführung des Programms auftretende Kontrollfluss einem für dieses Programm möglichen Kontrollfluss entspricht.
Dabei werden jedoch keine Fehler erkannt, bei denen Daten falsch ermittelt werden, bei denen diese Daten keinen Einfluss auf den Kontrollfluss und diesen nicht in für das ausgeführte Programm ungültigen Programmfluß überführen.
Die bisher genannten Verfahren ermöglichen es außerdem nicht oder nur schlecht, die Fehlererkennungswahrscheinlichkeit zu erhöhen, indem der Aufwand zur Fehlererkennung erhöht wird.

1. Bei dem in Druckschrift [7] beschriebenen Verfahren wird wie bei [5] zeitliche Redundanz ausgenutzt. Die Ausführung von Instruktionen wird jedoch nicht einfach wiederholt, sondern die Ausführung jeder einzelnen Instruktion wird derart wiederholt, dass die Daten, die durch die Instruktion verarbeitet werden, mit einer Konstanten multipliziert werden. Die ausgeführten Instruktionen werden so angepasst, dass das Resultat ebenfalls ein Vielfaches der Konstanten ist, so bei der Ausführung kein Fehler aufgetreten ist. Entsprechend muss das Ergebnis der redundanten, zweiten Ausführung der Instruktion ein entsprechendes Vielfaches des Ergebnisses der ersten Ausführung der Instruktion sein. Andernfalls muss ein Fehler bei einer der beiden Ausführungen aufgetreten sein. Hierbei hängt die Fehlererkennungswahrscheinlichkeit von der gewählten Konstanten ab. Je größer diese ist, desto höher ist die Wahrscheinlichkeit, dass auftretende Fehler erkannt werden. Es ist eine zweimalige Ausführung jeder Programminstruktion erforderlich und die Wahrscheinlichkeit, permanente Hardwarefehler in den für die Ausführung verwendeten Logikbausteinen zu entdecken ist nach wie vor verhältnismäßig gering. Auch bei diesem Verfahren ist es erforderlich, dass der Quellcode der ausgeführten Programme zur Verfügung steht.

Die folgenden Verfahren werden zumeist in Hardware realisiert.
Zum Erkennen von transienten und permanenten Fehlern in Speicherelementen können paritätsbasierte Codes eingesetzt werden. Diese schützen Daten vor einer fehlerhaften Veränderung, jedoch nur beim Datentransport und bei der Datenspeicherung und nicht bei der Transformation der Daten durch Logikbausteine. Außerdem ist der Einsatz zum Schutz vor fehlerhafter Datenveränderung bei allen Speichern und Datentransportwegen eines IT-Systems aufgrund des hohen entstehenden Aufwands nicht praktikabel, so dass meistens nur der Hauptspeicher, Zwischenspeicher (Cache) und Registerbänke auf diese Weise gegen Datenkorruption, also fehlerhafte und ungewollte Veränderungen von Daten, geschützt werden.
Eine weitere mögliche Vorgehensweise zur Fehlererkennung bei der Programmausführung ist die Verwendung von redundanten Logikbausteinen. Dies geschieht immer in Kombination mit dem Schutz der Daten vor unerkannter Modifikation im Speicher oder beim Transport. Hierzu werden zum Beispiel die schon vorgestellten Paritäten verwendet. Beispielsweise wird ein Programm mehrfach mittels unterschiedlicher Prozessoren ausgeführt und die erhaltenen Ergebnisse der beiden Programmausführungen werden verglichen und anschließend, wenn kein Fehler erkannt wurde, in einen mit Paritäten geschützten Speicher abgelegt. Entsprechende Computersysteme, wie beispielsweise in [8] beschrieben, sind sehr aufwändig zu realisieren und sehr teuer, da sie kein Massenprodukt sind.
Weiterhin haben diese in Hardware realisierten Verfahren den Nachteil, dass die Fehlererkennungswahrscheinlichkeit nicht zur Laufzeit wählbar ist. Dies gilt sowohl für eine mittels Hardware implementierte Codierung mit Paritäten zum Schutz gegen fehlerhafte Veränderung der Daten, als auch für die Nutzung von redundanten Logikbausteinen zur Fehlerdetektion.
In [9] ist ein Verfahren zur Fehlerdetektion beschrieben, welches sowohl spezielle Hardware erfordert als auch eine spezielle Vorverarbeitung der Programme, bei deren Ausführung Fehler detektiert werden sollen. Das Verfahren wird auf speicherprogrammierbare Steuerungen (SPS) angewendet, bei denen Programme üblicherweise in einer Endlosschleife wiederholt ausgeführt werden. Eine Iteration der Ausführung eines Programms wird durch den Wert eines Iterationszählers d identifiziert. Bei jeder Iteration, d. h. bei jeder Ausführung eines Programms, werden Eingabedaten übernommen, von dem Programm verarbeitet und Ausgabedaten erzeugt.
Alle zu verarbeitenden Daten, d. h. alle Eingabedaten werden mit einem arithmetischen Code, einer Signatur und einer Versionsnummer versehen. Übersetzt man dabei die auszuführenden Programme in eine Single-Assignment-Form, d. h. in eine Form, so dass jeder Programmvariablen nur genau einmal ein Wert zugewiesen wird, so kann jeder Programmvariablen eine eindeutige Signatur zugeordnet werden.
Eine Programmvariable x mit dem funktionalen Wert x_f wird codiert durch x_c = A·x_f + Bx + d wobei A eine Variablenunabhängige Konstante ist, B_x die Signatur der Programmvariable x ist und d die Nummer der aktuellen Iteration der Ausführung des Programms ist. Das Programm wird derart ausgeführt, dass nur auf diese Weise codierte Variablenwerte verwendet werden.
Es kann überprüft werden, ob ein Variablenwert x_c ein gültiges Codewort ist, indem überprüft wird, ob (x_c – d) mod A der für die entsprechenden Variable x vorgesehenen Signatur B_x entspricht. Liegt ein gültiges Codewort vor, so ist dies der Fall. Wurde der Variablenwert jedoch durch einen Fehler fälschlicherweise modifiziert oder durch fehlerhafte Berechnungen erzeugt, so ist der Variablenwert x_c mit einer von der Größe von A abhängigen Wahrscheinlichkeit kein gültiges Codewort. Bei diesem Verfahren wird vorausgesetzt, dass alle verwendeten Signaturen kleiner als A sind. Diese Voraussetzung stellt auch sicher, dass der funktionale Wert x_f von durch folgende Ganzzahldivision (x_c – d)/A ermittelt werden kann.
Liegt der Quellcode eines Programms vor, so können für alle Eingabevariablen des Programms statische Signaturen vergeben werden. Anhand des Programms, d. h. anhand des Programmflusses in der Verarbeitung der Eingabevariablen durch das Programm, werden Signaturen für alle von dem Programm verwendeten Variablen bestimmt. Jede Operation, bei der Variablenwerte verwendet werden, resultiert in einer bestimmten vorherbestimmbaren Signatur der Variable, der das Resultat der Operation zugewiesen wird. Kontrollstrukturen wie Verzweigungen und Schleifen werden derart implementiert, dass die Signaturen der jeweils abhängigen Variablen unabhängig vom gewählten Zweig bzw. der Anzahl durchgeführter Iterationen vorbestimmbar sind und im Falle eines Ausführungsfehlers, beispielsweise der Ausführung des falschen Zweiges, der Ausführung einer falschen Anzahl von Iterationen usw., kein gültiges Codewort entsteht.
Diese Vorgehensweise erfordert Änderungen an dem auszuführenden Programm – das Programm muss also codiert werden. Nach vielen Programminstruktionen sind Korrekturoperationen erforderlich, die die Codierung des Resultates anpassen. Beispielsweise muss bei der Addition zweier Variablenwerte einmal der Wert d subtrahiert werden, um zu erreichen, dass das Resultat ein gültiges Codewort ist.
Eingabedaten werden von einer speziellen Hardware unter Verwendung der zur Entwicklungszeit vergebenen Signaturen und unter Verwendung des in der Hardware realisierten Iterationszählers codiert. Die codierten Daten werden durch das System durch Ausführung des codierten Programms verarbeitet. Die Ausgabevariablen werden nicht direkt ausgeben sondern durch eine spezielle Hardware auf ihre Gültigkeit geprüft, d. h. ihre Signatur wird, mit der bei korrekter Ausführung erwarteten und vorherbestimmten Signatur, verglichen. Durch diesen Vergleich können die folgenden Fehler detektiert werden:

• eine zufällige Veränderung im Arbeitsspeicher, die Daten oder das ausgeführte Programm betrifft (memory modification);
• eine fehlerhafte Instruktionsausführung (operation error);
• Ausführung einer falschen Instruktion (operator error);
• Verwendung eines falschen Operanden (operand error);
• eine fehlende Aktualisierung eines Variablenwerts (lost update).

Die in [9] beschriebene Vorgehensweise hat den Nachteil, dass der Quellcode der auszuführenden Programme bekannt sein muss und diese speziell vorbereitet werden müssen. Der komplette Datenfluss der ausgeführten Programme muss bekannt sein, wenn die Signaturen für die Eingabevariablen festgelegt und die erwarteten Signaturen der Ausgabevariablen berechnet werden. Ferner wird eine spezielle Hardware zur Codierung der Eingabedaten, zur Überprüfung und Decodierung der Ausgabedaten benötigt. Die Notwendigkeit den gesamten Datenfluss apriori zu kennen, schränkt die Anwendbarkeit dieses Verfahrens auf sehr kleine Programme ein. Eine Anwendung auf beliebige Programme, deren Programmfluss nicht bereits zur Entwicklungszeit bekannt ist, ist nicht möglich. Weiterhin schränkt die spezielle Codierung von Schleifen, wenn codierte Werte einen eingeschränkten Wertebereich besitzen den Wertebereich von in Schleifen verwendeten Variablen weiter ein.
Bei dem in Druckschrift [10] beschriebenen Verfahren wird ein Programm zweimal ausgeführt, wobei bei der zweiten Ausführung des Programms alle Daten wie folgt codiert werden: Hatte bei der ersten Ausführung des Programms eine Variable den Wert x_f, so hat sie bei der zweiten Ausführung den Wert x_c = –A·x_f – 1. Die Ergebnisse der beiden Ausführungen werden direkt von der ausführenden Hardware verglichen oder das Ergebnis der zweiten Ausführung wird decodiert und für das Resultat ein CRC (Cyclic Redundancy Code) gebildet. Der CRC wird zusammen mit dem Ergebnis der ersten Ausführung ausgegeben. Externe Einheiten, die die Ausgabe des Programms verarbeiten, prüfen ob der CRC der Ausgabe der ersten Ausführung mit dem CRC der zweiten Ausführung übereinstimmt. Auch für dieses Verfahren ist der Quellcode des Programms erforderlich und das Programm muss zweimal ausgeführt werden.
Der Erfindung liegt das Problem zu Grunde, eine im Vergleich zu den in [1, 2, 3, 4, 5, 6, 7, 8, 10] vorgestellten Lösungen sicherere Möglichkeit zur Fehlerdetektion zu schaffen. Sie soll eine ähnlich hohe Sicherheit wie die in [9] vorgestellte Lösung bieten, aber auf beliebige Programme anwendbar sein, ohne die Notwendigkeit den kompletten Datenfluss der Programme zur Entwicklungszeit kennen zu müssen. Eine Einschränkung des Wertebereichs von in Schleifen verwendeten Variablen soll nicht erfolgen.
Das Problem wird durch eine Datenverarbeitungsanordnung, ein Verfahren zur Datenverarbeitung, ein Computerprogrammelement und eine Überprüfungsanordnung für einen Speicher mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
Es wird eine Datenverarbeitungsanordnung bereitgestellt mit einem Speicher, der eine Mehrzahl von Speicherelementen zum Speichern jeweils eines Datenwortes aufweist, einer Zuordnungseinrichtung, die eingerichtet ist, jedem Speicherelement der Mehrzahl von Speicherelementen eine Signaturinformation zuzuordnen, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, einer Codiereinrichtung, die eingerichtet ist, einem in einem Speicherelement zu speichernden Datenwort basierend auf der Signaturinformation ein Codewort zuzuordnen und das Codewort in dem Speicherelement zu speichern und einer Überprüfungseinrichtung, die eingerichtet ist, anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
Ferner werden ein Verfahren zur Datenverarbeitung, ein Computerprogrammelement und eine Überprüfungsanordnung für einen Speicher gemäß der oben beschriebenen Datenverarbeitungsanordnung bereitgestellt.
Anschaulich wird jedem Speicherelement basierend auf seiner Adresse eine Signaturinformation zugeordnet, die einen Teil aller in dem Speicherelement speicherbaren Datenworte als gültige Codeworte definiert. Wird festgestellt, dass ein in einem Speicherelement gespeichertes Datenwort kein gültiges Codewort ist, so muss ein Fehler beim Speichern oder beim Erzeugen des Datenworts aufgetreten sein.
Wird das Verfahren zum Detektieren von Laufzeitfehlern von ausgeführten Programmen eingesetzt, so ermöglicht es die Zuordnung von Signaturinformationen zu Speicherzellen (anstatt beispielsweise zu Variablen des Programms) von dem Programmquellcode zu abstrahieren. Es ist nicht erforderlich, dass der Quellcode des Programms bekannt ist oder sogar für eine Laufzeitfehlerdetektion verändert wird. Lediglich die Ausführung von Maschinenbefehlen wird bei Ausführungsformen der Erfindung, wie weiter unten erläutert, angepasst. Dies erfordert aber nicht die Kenntnis des Programmquellcodes.
Das in einem Speicherelement zu speichernde Datenwort kann sowohl ein durch ein Computerprogramm zu verarbeitender Variablenwert sein, als auch die Angabe einer Programminstruktion oder eines Teiles einer Programminstruktion, beispielsweise ein Binärwort, das eine Maschineninstruktion mit zugehörigen Operanden spezifiziert. Auf diese Weise wird es auch ermöglicht, fehlerhafte Instruktionen zu detektieren.
Zusammenfassend können durch Ausführungsformen der Erfindung folgende Fehler mit hoher Wahrscheinlichkeit detektiert werden:

• Ungewollte, zufällige Modifikationen von Speicherinhalten, die Daten oder ein ausgeführtes Programm betreffen (memory modification).
• Verwendung falscher Operanden (operand error).
• Verwendung veralteter Daten (lost update). Solch ein Fehler kann auftreten, wenn die Aktualisierung von Speicherinhalten, nicht durchgeführt wurde, beispielsweise Variablenwerte nach einer Instruktion nicht aktualisiert werden.
• Fehler im Kontrollfluss, so dass eine falsche Instruktion ausgeführt wird (operator error).
• Ausführung einer Instruktion, die nicht der in der Binärdatei eines Programms vorgesehenen Instruktion entspricht (instruction error).
• Fehlerhafte Ausführung einer Operation durch den verwendeten Prozessor (operation error).

Wie erwähnt ist die Kenntnis des Programmquellcodes nicht erforderlich. Er kann aber, wenn er vorhanden ist, zur Erhöhung der Ausführungsgeschwindigkeit sicher ausgeführter Programme genutzt werden. Ausführungsformen der Erfindung können auf beliebig große Programme angewendet werden und es ist keine spezielle Hardware erforderlich, das heißt Ausführungsformen der Erfindung können mittels eines üblichen Computersystems, beispielsweise mittels eines PCs oder einer Workstation, realisiert werden. Weiterhin ist es nicht erforderlich, dass ein Programm mehrfach ausgeführt wird, um die Fehlerdetektion zu ermöglichen.
Beispielhafte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die Ausgestaltungen der Erfindung, die im Zusammenhang mit der Datenverarbeitungsanordnung beschrieben sind, gelten sinngemäß auch für das Verfahren zur Datenverarbeitung, das Computerprogrammelement und die Überprüfungsanordnung für einen Speicher.
In einer Ausführungsform entspricht jedes Codewort mindestens einer Signaturinformation und einem Datenwort wird ein Codewort zugeordnet, das der Signaturinformation entspricht, die dem Speicherelement zugeordnet ist. Die Signaturinformation, die einem Codewort entspricht, ist beispielsweise aus dem Codewort ermittelbar.
Die Überprüfungseinrichtung kann eingerichtet sein, zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist, indem sie überprüft, ob ein in dem Speicherelement gespeichertes Codewort der Signaturinformation, die dem Speicherelement zugeordnet ist, entspricht.
Die Adressinformation ist beispielsweise eine Adresse des Speicherelements, mittels welchem das Speicherelement in dem Speicher adressiert werden kann.
Die Signaturinformation kann (zusätzlich zu der Adressinformation) auf einer dem Speicherelement zugeordneten Versionsinformation basieren. Die Versionsinformation ist beispielsweise ein Wert, der bei jedem Eintreten mindestens eines vorgebbaren Versionsänderungs-Ereignisses geändert wird. Versionsänderungs-Ereignisse werden beispielsweise immer an solchen Stellen der Ausführung eines Computerprogramms definiert, das heißt vorgegeben, an denen ansonsten die Gefahr von lost-update-Fehler bestehen würde.
In einer Ausführungsform ist das Versionsänderungs-Ereignis die Ausführung einer Instruktion eines Computerprogramms durch die Datenverarbeitungsanordnung. Das Versionsänderungs-Ereignis ist beispielsweise die Ausführung einer Instruktion eines Computerprogramms durch die Datenverarbeitungsanordnung, bei der das Datenwort verarbeitet wird. In diesem Fall wird nicht nach jeder Instruktion die Versionsinformation für alle Speicherzellen geändert, sondern es wird beispielsweise für jede Speicherzelle gespeichert, wann (d. h. vor wie vielen Instruktionen) sich ihr Inhalt das letzte Mal geändert hat. Dann ändern sich nicht nach jeder Ausführung einer Instruktion die Versionsinformationen aller Speicherzellen und entsprechend ändert sich nicht nach jeder Ausführung einer Instruktion für alle Speicherzellen das jeweils zuzuordnende Codewort. Unter anderem mögliche Datenstrukturen zur Verwaltung der Versionsinformationen für die Speicherzellen sind Listen und Baumstrukturen.
In einer Ausführungsform ist die Versionsinformation ein Wert, der ab einem vorgebbaren Startereignis ausgehend von einem Startwert bei jedem Eintreten des Versionsänderungs-Ereignisses inkrementiert wird. Das Startereignis ist beispielsweise der Beginn der Ausführung eines Computerprogramms mittels der Datenverarbeitungsanordnung.
Es wird zum Beispiel bei jeder Änderung der Versionsinformation jedem Speicherelement die Signaturinformation neu zugeordnet und einem in dem Speicherelement zu speicherndem Datenwort wird basierend auf der (neu zugeordneten) Signaturinformation ein (neues) Codewort zugeordnet und dieses Codewort wird in dem Speicherelement gespeichert.
Dem Datenwort wird das Codewort beispielsweise zugeordnet, indem das Datenwort und die Signaturinformation als Zahlenwerte dargestellt werden und das Codewort durch eine Rechenoperation aus dem Datenwort und der Signaturinformation gebildet wird. Bestehen das Datenwort und die Signaturinformation beispielsweise aus einer Folge von Bits, so werden diese Bitfolgen als Zahlen in Binärdarstellung interpretiert.
Zum Beispiel wird dem Datenwort das Codewort zugeordnet, indem das Datenwort mit einem vorgebbaren Wert multipliziert wird und die Signaturinformation zu dem Ergebnis der Multiplikation addiert wird. Durch die Wahl des Werts, mit dem multipliziert wird, kann die Fehlerdetektionswahrscheinlichkeit eingestellt werden. Der Wert wird beispielsweise als Primzahl gewählt.
Die Überprüfungseinrichtung ist in einer Ausführungsform eingerichtet, bei Eintreten eines Überprüfungsereignisses anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist. Das Überprüfungsereignis ist beispielsweise die Ausgabe des Datenworts oder die Beendigung eines auf der Datenverarbeitungsanordnung ausgeführten Computerprogramms. Ebenso ist beispielsweise ein periodisch auftretendes Überprüfungsereignis möglich.
In einer Ausführungsform weist die Datenverarbeitungsanordnung ferner eine Interpretationseinrichtung auf, die eingerichtet ist, das Datenwort, dem ein in einem Speicherelement gespeichertes Codewort zugeordnet ist, zu ermitteln und das Datenwort mittels der Datenverarbeitungsanordnung zu verarbeiten. Das Datenwort spezifiziert beispielsweise eine Programminstruktion. In diesem Fall ist unter der Verarbeitung des Datenworts die Ausführung der Programminstruktion zu verstehen. Die Interpretationseinrichtung arbeitet in diesem Fall also als (Computerprogramm-)Interpreter. Laufzeitfehler bei der Verarbeitung des Datenworts oder der Ermittlung des Datenworts werden in einer Ausführungsform detektiert. Beispielsweise kann dies dadurch erreicht werden, dass die Interpretationseinrichtung selbst durch ein Computerprogramm, beispielsweise ein Interpreter-Programm, realisiert wird, dass analog zu [9] codiert und ausgeführt wird.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
1 zeigt eine Computersystem gemäß einem Ausführungsbeispiel der Erfindung.
2 zeigt ein Ablaufdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
3 zeigt ein Ablaufdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
1 zeigt eine Computersystem 100 gemäß einem Ausführungsbeispiel der Erfindung.
Das Computersystem 100 weist einen Arbeitsspeicher 101, eine CPU 102, beispielsweise einen Mikroprozessor, eine Graphikkarte 103 sowie Speichermedien 104 auf. In den Speichermedien 104, beispielsweise auf einer Festplatte, auf einer Diskette oder auf einer CD-ROM ist ein Computer-Programm 105 gespeichert, das von dem Computersystem 100 ausgeführt werden soll, wobei es möglich sein soll, dass Fehler bei der Ausführung des Programms 105 detektiert werden. Beispielsweise soll ein Laufzeitfehler, der zu einem fehlerhaften Status des ausgeführten Programms 105 führt, der sich in einem fehlerhaften Wert einer Variable niederschlägt, beispielsweise einem fehlerhaften Wert einer Ausgabevariable, bemerkt werden können.
Das Programm 105 ist ein beliebiges ausführbares Programm, das beispielsweise in Form einer Binärdatei mittels eines der Speichermedien 104 gespeichert ist. Außerdem sind Eingabedaten 106 mittels der Speichermedien 104 gespeichert, d. h. Daten, die bei der Ausführung des Programms 105 verarbeitet werden sollen.
Um eine Detektion von Laufzeitfehlern zu ermöglichen, werden folgende Schritte durchgeführt:

• Die von dem Programm 105 verwendeten Daten, beispielsweise die Eingabedaten 106, werden codiert und als codierte Daten 107 in dem Arbeitspeicher 101 gespeichert. Die codierten Daten 107 sind beispielsweise auch codierte Variablenwerte, die bei der Ausführung des Programms 105 erzeugt werden.
• Das Programm 105 wird codiert und als codiertes Programm 108 in dem Arbeitsspeicher 101 gespeichert. Dabei wird in einer Ausführungsform überprüft, ob das Programm 105 und das codierte Programm 108 semantisch übereinstimmen.
• Das codierte Programm 108 wird ausgeführt.
• Das codierte Programm 108 und/oder die codierten Daten 107 werden auf Korrektheit überprüft. Dies geschieht zu einem beliebigen Zeitpunkt während der Ausführung des codierten Programms 108 oder nach Ausführung des codierten Programms 108.

Die genannten Schritte werden nun mit Bezug auf 2 genauer erläutert.
2 zeigt ein Ablaufdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
In Schritt 201 wird das Programm 105 codiert und als codiertes Programm 108 in den Arbeitsspeicher 101 geladen. Dabei werden auch die von dem Programm verarbeiteten Daten, beispielsweise die Eingabedaten 106, codiert und als codierte Daten 107 in den Arbeitsspeicher 101 geladen. Es wird eine Codierung gewählt, bei der gewährleistet ist, dass bei einem Laufzeitfehler gültige Codeworte mit hoher Wahrscheinlichkeit in ungültige Codeworte überführt werden, d. h. bei einem auftretenden Laufzeitfehler mit hoher Wahrscheinlichkeit ungültige Codeworte erzeugt werden, die bei der Codeprüfung, d. h. bei der Überprüfung, ob gespeicherte Datenworte gültige Codeworte sind, detektiert werden können. Bei einer Codeprüfung können alle oder ein Teil der Datenworte überprüft werden. In einer Ausführungsform werden zumindest Datenworte überprüft, die Daten entsprechen, die von dem Computerprogramm ausgegeben werden sollen. Beispielsweise werden am Ende der Ausführung des Computerprogramms alle auszugebenden Daten überprüft. Es kann auch eine Kontrollvariable verwendet werden, die nur dann ein gültiges Codewort als Wert hat, wenn kein Fehler aufgetreten ist. Diese kann dann regelmäßig überprüft werden.
Gemäß einem Ausführungsbeispiel der Erfindung wird dazu die folgende Codierungsvorschrift verwendet: xc = A·xf + h(Adresse, Version).
Statt einem Datenwort x_f wird der codierte Inhalt x_c in einer Speicherzelle des Arbeitsspeichers 101 gespeichert und bei der Ausführung des Programms 105 verwendet. x_f kann dabei sowohl ein Datenwort bezeichnen, das eine Instruktion spezifiziert, d. h. ein Teil des Programms 105 ist, oder auch ein von dem Programm verarbeitetes Datenwort. Anschaulich wird also gemäß der obigen Vorschrift der Inhalt jeder Speicherzelle, die Teile des auszuführenden Programms 105 oder zu verarbeitende Daten enthält, codiert, und so das Programm als codiertes Programm 108 bzw. die zu verarbeitenden Daten als codierte Daten 107 in dem Arbeitsspeicher 101 abgelegt. Bei Programminstruktionen, die mehrere Speicherzellen erfordern, kann x_f auch nur einen Teil einer Programminstruktion bezeichnen und x_c entsprechend einen codierten Teil der Programminstruktion.
Um Fehler mit einer hohen Wahrscheinlichkeit detektieren zu können, wird in einer Ausführungsform der Erfindung der Parameter A nicht als Zweierpotenz gewählt, kann aber ansonsten frei gewählt werden. Eine hohe Detektionswahrscheinlichkeit kann beispielsweise durch Verwendung einer Primzahl als Parameter A erreicht werden.
Der Term h(Adresse, Version) wird als Signatur der Speicherzelle x_f bezeichnet. Die Signaturen werden so gewählt, dass sie alle kleiner als A sind. Die Vorschrift zur Ermittlung von h(Adresse, Version) wird so gewählt, dass sie für alle Speicherzellen unabhängig von dem Programm 105 vorausberechnet werden kann. Der Parameter Adresse ist dabei die Adresse der Speicherzelle (oder allgemein eines Speicherelements), für das die Signatur bestimmt wird, beispielsweise eine Adresse entsprechend einer Adressierung eines virtuellen Adressraums.
Der Parameter Version wird durch die Versionsänderungs-Ereignisse geändert/bestimmt. Beispielsweise, kann der Parameter Version angeben, wie viele Instruktionen seit einem definierten Zeitpunkt, beispielsweise dem Start der Ausführung des Programms oder dem Zeitpunkt der Bereinigung von Datenstrukturen, ausgeführt worden sind. Somit ändert sich der Parameter Version während der Programmausführung. In einer Ausführungsform der Erfindung wird nach jeder Ausführung einer Instruktion und damit nach jeder Änderung des Wertes des Parameters Version der Wert x_c für jede Speicherzelle entsprechend der Änderung des Parameters Version angepasst.
Die Verwendung von Signaturen ermöglicht es, folgende Fehler zu detektieren:

• Verwendung falscher, aber korrekt codierter Operanden (operand error). Solch ein Fehler könnte z. B. bei einer falschen Operandenadressierung entstehen.
• Verwendung veralteter Daten (lost update). Solch ein Fehler kann auftreten, wenn die Aktualisierung von Speicherinhalten nicht durchgeführt wurde.
• Fehler im Kontrollfluss, die zum Auslassen oder zur Mehrfachausführung von Programminstruktionen führen (operator error) oder Ausführung einer falschen Instruktion, d. h. es wird eine Instruktion ausgeführt, die nicht der laut Binärdatei auszuführenden Instruktion entspricht (instruction error).

Die Multiplikation mit dem Faktor A ermöglicht es, folgende Fehler zu detektieren:

• Ungewollte Modifikation von Speicherinhalten (memory modification).
• Fehlerhaft ausgeführte Operationen (operation error). Beispielsweise ist es möglich zu detektieren, dass das Ergebnis einer Addition von dem für bestimmte Eingabewerte erwarteten Ergebnis abweicht.

Das Programm 105 kann ein beliebiges ausführbares Programm sein. Es besteht aus Maschinencode, der eine direkte Übersetzung von Assemblercode ist. Ein Beispiel für das Programm 105 ist in Tabelle 1 dargestellt.

Assemblerbefehl	Uncodierter Binärcode	Codiertes Speicherabbild
lw r30 65524 r1	0x8fclfff4	0xffff8fc89396012b
addi r0 4 r2	0x20020004	0x20001fe6004b
movi2fp r1 f0 r0	0x200035	0x1ffe54fd7c
movi2fp r1 f1 r0	0x400835	0x400474858c
mult f0 f1 f0	0x401000e	0x400c3feffe5
movfp2i f0 r1 r0	0x834	0x83385bb
lw r30 0 r2	0x8fc20000	0xffff8fc893a200d7
add ri r2 r1	0x220820	0x2206218707
lw r30 5 r2	0x8fc20004	0xffff8fc893a600bb
lw r30 65520 r4	0x8fc4fff0	0xfff8fcb936500fc
add r2 r4 r3	0x441820	0x441422963
lbu r3 0 r2	0x906200000	0xffff90688a42002c
lw r30 65520 r3	0x8fc3fff0	0xffff8fca9374012
lw r30 4 r4	0x8fc40004	0xffff8fca93880010
add r3 r4 r3	0x641820	0x641242967c
addi r3 1 r4	0x20640001	0x20621a25005d
lbu r4 0 r3	0x90830000	0xffff90898853007c
slli r3 8 r4	0x50640008	0x505f4a2c0014
or r2 r4 r2	0x441025	0x440c280c71
lw r30 65520 r3	0x8fc3fff0	0xffff8fca9374019c
lw r30 4 r4	0x8fc40004	0xffff8fca93880080
add r3 r4 r3	0x641820	0x64124296ec
addi r3 2 r4	0x20640002	0x20621a2600bc
lbu r4 0 r3	0x90830000	0xffff9089885300ec
slli r3 16 r4	0x50640010	0x505f4a33ff11
or r2 r 4 r2	0x441025	0x440c280de6
lw r30 65520 r3	0x8fc3fff0	0xffff8fca93740111
lw r30 4 r4	0x8fc40004	0xffff8fca9387fff5
add r3 r4 r3	0x641820	0x6412429661
addi r3 3 r4	0x20640003	0x20621a270024
lbu r4 0 r3	0x90830000	0xffff908988530061
slli r3 24 r4	0x50640018	0x505f4a3bff09
or r2 r4 r2	0x441025	0x440c280e56
sw r1 0 r2	0xac220000	0xffffac26ea020091
lw r30 65524 r2	0x8fc2fff4	0xffff8fc993870155
addi r2 1 r1	0x20410001	0x203f1c3200a2
add r0 r1 r2	0x11020	0x110100ee1
sw r30 65524 r2	0xafc2fff4	0xffffafc7v3870185
lw r30 65520 r1	0x8fclfff0	0xffff8fc8939201d1
addi r1 4 r2	0x20220004	0x20201e0600b5
swr30 65520 r2	0xafc2fff0	0xffffafc7b38300f6
jmp 4294967100	0xbffff3c	0xbff4b3c0b92

Tabelle 1

Die erste Spalte von Tabelle 1 enthält die Assemblerbefehle des Programms 105. Die zweite Spalte enthält den entsprechenden Maschinencode (Binärcode) in uncodierter Form, wie er durch eine Übersetzung des entsprechenden Assemblerbefehis entsteht und Spalte 3 zeigt den Inhalt der Speicherzellen, die den gemäß der obigen Codierungsvorschrift codierten Binärcode enthalten.
Als Beispiel wird die Codierung des in Zeile 2 von Tabelle 1 dargestellten Befehls genauer erläutert. Die zu codierende Assemblerinstruktion ist in diesem Fall addi r0 4 r2. Dies Bewirkt die Addition des Wertes im Register 0 der CPU 102 zu dem Direktwert 4 und Speichern des Ergebnisses der Addition in dem Register 2 der CPU 102.
Der dieser Instruktion entsprechende Maschinencode ist m = 0x20020004. Die Zeichen 0x sollen dabei anzeigen, dass der folgende Zahlenwert hexadezimal angegeben ist. Dieser Maschinencode, d. h. diese Instruktion des Programms 105, soll nun in codierter Form in dem Arbeitsspeicher 101 gespeichert werden (als Teil des codierten Programms 108). Es wird angenommen, dass die Speicheradresse der Speicherzelle, in der die codierte Instruktion gespeichert werden soll a = 0x5354d0 ist.
In diesem Ausführungsbeispiel wird als Codierungsparameter A der Wert A = 0xfff1 verwendet und die Signatur h wird gemäß h(Adresse, Version) = Adresse·Version mod 0xfb berechnet (dabei bezeichnet mod die Moduln-Division). Es wird angenommen, dass der Parameter Version den Wert 2 hat. Als codierte Instruktion, die in der Speicherzelle gespeichert wird, ergibt sich somit i = A·m + h(a, v) = 0x20001fe6004b (vergleiche Zeile 3 Spalte 3 von Tabelle 1).
Tabelle 1 zeigt entsprechend weitere Codierungen von Programminstruktionen. Dabei wurden Vorzeichen behaftete Operationen verwendet.
Von dem Programm zu verarbeitende Daten werden analog codiert. Die Codierung ist dabei wie beschrieben von der Adresse des gespeicherten Datums und von der Versionsinformation des Datums abhängig.
Im Unterschied zu [9] werden bei dem beschriebenen Ausführungsbeispiel nicht einzelnen Programmvariablen in einem Programm, welches in Single-Assignment-Form vorliegt, Signaturen zugeordnet und diese mit einer Version versehen, die mit jeder wiederholten Ausführung des Programms inkrementiert wird, sondern einzelnen Speicherzellen im virtuellen Adressraum des ausgeführten Programms werden Signaturen zugeordnet, die von den Adressen der Speicherzellen und der aktuellen Versionsinformation abhängen. Diese Versionsinformation ist unterschiedlich von der in [9] verwendeten Version. Wie erwähnt wird die Versionsinformation beispielsweise nach Ausführung jeder Instruktion oder auch nach Ausführung jeder Speicher verändernden Instruktion erhöht, so dass keine Speicheraktualisierungen verloren gehen können. Im Gegensatz zu [9] wird gemäß dem beschriebenen Ausführungsbeispiel eine Abstraktion von dem auszuführenden Programm 105 erreicht und es ist nicht erforderlich, den Programmquellcode, Kontrollflüsse des Programms oder Datenflüsse des Programms zu kennen, um zu erwartende Signaturen zu berechnen.
Die beschriebene Codierung wird in einem Ausführungsbeispiel nicht nur im Arbeitsspeicher 101 durchgeführt, sondern wird auf weiterverarbeitende Systeme oder datenspeichernde Systeme erweitert. Beispielsweise werden die bei der Ausführung des Programms 105 erzeugten Ausgabedaten in codierter Form an andere Programme weitergegeben und in codierter Form weiterverwendet. Es können auch zu verarbeitende Daten oder Ausgabedaten, die nicht im Arbeitsspeicher 101 gespeichert werden, sondern beispielsweise auf Hintergrundspeichern, wie beispielsweise einer Festplatte, dort in codierter Form gespeichert werden.
In Schritt 202 wird überprüft, ob das Programm 105 korrekt codiert und als codiertes Programm 108 in den Arbeitsspeicher 101 geladen wurde. Es wird dabei sichergestellt, dass das Programm beim Codieren und Laden nicht verfälscht worden ist und das das korrekte Programm codiert und geladen worden ist. Dazu wird beispielsweise ein Testprogramm verwendet, welches gemäß [9] codiert wurde und eine kryptographische Hashsumme (beispielsweise gemäß MD5) des codierten und geladenen Programms 108 berechnet und mit einer zum Programm 105 ausgelieferten Hashsumme vergleicht. Stimmen die beiden Hashsummen überein, so wurde das Programm korrekt codiert und in den Arbeitspeicher (Hauptspeicher) 101 geladen und kann ausgeführt werden. Stimmen die beiden Hashsummen nicht überein so wurde entweder die Binärdatei, in der das Programm 105 vorliegt, selbst schon verändert oder beim Laden und Codieren des Programms 105 in dem Arbeitsspeicher 101 verändert. In diesem Fall wird das codierte Programm 108 nicht ausgeführt und beispielsweise Schritt 201 erneut ausgeführt.
In einer Ausführungsform der Erfindung liegt das Programm 105 schon in den Speichermedien 104 codiert vor und wird nur noch in den Arbeitsspeicher 101 geladen und die Codierung an die neuen Adressen angepasst.
Wurde das Programm 105 korrekt codiert und in den Arbeitsspeicher 101 geladen, so wird das codierte Programm 108 ausgeführt, was in 2 durch den Block 203 symbolisiert ist, der eine Schleife zur Ausführung der Programminstruktionen aufweist. Das geladene codierte Programm 108 wird durch einen Interpreter 109, d. h. ein Interpreter-Programm interpretiert und ausgeführt. Der Interpreter 109 ist beispielsweise auch im Arbeitsspeicher 101 gespeichert und wird von der CPU 102 ausgeführt.
Um Fehler bei der Ausführung des Interpreters 109 detektieren zu können, muß dieser ebenfalls vor unerkannter fehlerhafter Ausführung geschützt werden. Dies kann zum Beispiel erreicht werden, indem der Interpreter 109 gemäß [9] codiert wird und ausschließlich mit gemäß [9] codierten Daten arbeitet, sodass Laufzeitfehler des Interpreters detektiert werden können. Das heißt, dass in einer Ausführungsform das codierte Programm 108 und die codierten Daten 107 nicht gemäß [9] codiert sind, sondern nur Interpreter-interne Datenstrukturen analog zu [9] codiert werden. Dabei kann auch ähnlich der zur Codierung des codierten Programms 108 und der codierten Daten 107 auch statt der separaten Addition von Signaturinformation und Versionsinformation auch eine Signatur verwendet werden, die von Version und Adressinformation abhängt Im Folgenden wird ein Beispiel für eine mögliche Implementierung des Interpreters 109 erläutert. Dieser ist in diesem Beispiel gemäß [9] codiert.
Die aktuell auszuführende Instruktion des codierten Programms 108 wird durch einen Programmzähler PC (Programm Counter) identifiziert, der als Wert die Speicheradresse der aktuell auszuführenden Programminstruktion des codierten Programms 108 hat. Der Programmzähler wird selbst codiert im Arbeitsspeicher 101 abgelegt, wobei der codierte Wert des Programmzählers gegeben ist durch PC_c = A·PC_f + h(PC_f, Version).
Auf diese Weise ist auch der Programmzähler vor fehlerhaften und ungewollten Veränderungen geschützt. Eine fehlerhafte Veränderung des Programmzählers wäre ein Fehler im Kontrollfluss, der auf diese Weise detektiert werden kann. Die Codierung des Programmzählers ermöglicht es weiterhin zu erkennen, ob im Speicher ungewollt veränderte Assemblerinstruktionen ausgeführt werden, da die Signatur einer Assemblerinstruktion, die ausgeführt wird, der Signatur des Programmzählers entsprechen muss.
Der Programmzähler wird von dem Interpreter beim Start der Ausführung des codierten Programms 108 mit der Startadresse des codierten Programms 108 im Arbeitsspeicher 101 initialisiert. Die Instruktionen des codierten Programms 108 werden dann nacheinander ausgeführt, indem entsprechender Code aufgerufen wird, der die Instruktionen implementiert. Die Auswahl der Implementierung der einzelnen Instruktionen wird beispielsweise analog zu der in [9] beschriebenen Codierung der If-Anweisung codiert.
Der Interpreter 109 verwaltet weiterhin die Versionsnummern (d. h. die Werte des Parameters Version). Diese können für unterschiedliche Speicherzellen auch unterschiedlich sein. In diesem Ausführungsbeispiel wird als Versionsnummer für alle Speicherzellen die Anzahl der ausgeführten Instruktionen seit dem Programmstart verwendet. Es ist somit erforderlich, dass der Interpreter 109 die Anzahl der ausgeführten Instruktionen seit Programmstart kennt, um die Versionsnummern für die codierten Daten bestimmen zu können. Bestimmt der Interpreter die Versionsnummern unabhängig von der Anzahl der ausgeführten Instruktionen so werden bestimmte Laufzeitfehler nicht detektiert.
Es wird beispielsweise nach jeder Ausführung einer Instruktion die Versionsnummer für alle codierten Daten erhöht und dementsprechend die Codierung aller codierten Daten angepasst. In diesem Fall sind alle Daten gemäß der dem Interpreter bekannten Anzahl aufgeführter Instruktionen codiert. In anderen Ausführungsformen der Erfindung werden zusätzliche Datenstrukturen und Verfahren zur Verwaltung der Versionsnummer oder auch verschiedene Versionsnummern zur Effizienzsteigerung verwendet. Diese werden ebenfalls vor Modifikation durch Laufzeitfehler geschützt.
Im Folgenden wird die Ausführung einer Instruktion anhand eines Beispiels erläutert. Das Beispiel ist das bereits oben verwendete Beispiel der Addition des Wertes 4 zum Inhalt des Registers 0 und Speicherung des Ergebnisses im Register 2 vergleiche Tabelle 1, Zeile 3. Im Schritt 204 wird die codierte Instruktion I_c aus dem Arbeitsspeicher 101 aus der Speicherzelle geladen, deren Adresse durch den funktionalen Wert PC_f des codierten Programmzählers PC_c angegeben wird (unter funktionalem Wert ist im Folgenden stets der decodierte Inhalt einer Speicherzelle zu verstehen). Im Beispiel des Additionsbefehls wird die Instruktion von der Adresse 0x5354d0 geladen. Das Ergebnis dieser Ladeoperation ist die codierte Instruktion I_c = 0x20001fe6004b.
In Schritt 205 wird die geladene codierte Instruktion decodiert. Dies geschieht mittels ganzzahliger Division der codierten Instruktion I_c durch A. Das Ergebnis ist die decodierte Instruktion I_f, also I_f = I_c/A (wobei/die ganzzahlige Divison ohne Rest bezeichnet). Im Falle des Additionsbefehls ist dies der Wert 0x20020004. Da die Signatur kleiner ist als der Faktor A und eine ganzzahlige Division durchgeführt wird, ist es nicht erforderlich, beim Decodieren der Instruktion die Signatur zu subtrahieren.
In Schritt 206 wird ein Kontrollwert k berechnet, welcher die Summe aus drei Termen ist. Der erste Term ist gegeben durch h(PC_f, Version_p) – I_c mod A
In Falle der Addition ist dies
h(0x5354D0,2) – 0x20001FE6004B mod 0xFFF1.
Durch diesen Term wird überprüft, ob die geladene codierte Instruktion dem aktuellen Programmzähler entspricht. Ist dies der Fall, so hat dieser Term den Wert 0.
Der zweite Term ist gegeben durch h(PC_f, Version_d) – PC_c mod A.
In Falle der Addition ist dies
h(0x5354D0,2) – 0x534FEE0857 mod 0xFFF1.
Durch diesen Probeschritt wird überprüft, ob der aktuelle codierte Programmzähler PC_c ein korrektes Codewort ist und eine korrekte Codierung des funktionalen Werts des Programmzählers PC_f ist. Ist der Programmzähler korrekt codiert, so hat der zweite Term Wert 0.
Die verwendeten Versionsnummern Version_p und Version_d können wie erwähnt unterschiedlich sein. In dem Fall, dass die Versionsnummer lediglich durch die Anzahl der ausgeführten Programminstruktionen seit Programmstart gegeben ist, sind sie jedoch identisch.
Der dritte Term ist der Wert der decodierten Instruktion I_f, im Falle der Addition ist dies der Wert 0x20020004. Er ermöglicht es, im Laufe der weiteren Verarbeitung zu überprüfen, ob die richtige Operation (Instruktion) ausgeführt worden ist (das wird im weiteren Ablauf deutlich). Allgemein kann ein beliebiger Wert verwendet werden, der von I_f abhängt, also eine Funktion f(I_f) ist. Als Funktion f kann beispielsweise die Identität verwendet werden.
In Schritt 207 werden die zur Ausführung der Instruktion erforderlichen Bestandteile aus I_c extrahiert, beispielsweise Informationen über die Operanden und die zur Ausführung der Instruktion erforderlichen Befehle. Im Falle der Addition wären dies zum Beispiel Befehle für die Instruktion Addieren (add) und Informationen über die Quelloperanden (Register 0 und Wert 4) und die Information über den Zieloperanden (Register 2).
In Schritt 208 wird die Instruktion ausgeführt und dabei die erforderlichen Daten geladen und berechnet und die entsprechenden Befehle zur Ausführung der Instruktion durchgeführt. Informationen über die Operanden werden dabei an das entsprechende Mikroprogramm übergeben.
Für die Addition werden beispielsweise folgende Befehle durchgeführt
operand1 = loadRegister(0)
operand2 = getEncodedImmediate (0x20001FE6004B)
sig1 = h(0, 2)
sig2 = h("Adresse von operand2", 2)
sigResult = h(2, 3)
result = encodedAdd(operand1, sig1, operand2, sig2, sigResult)
Die Funktion loadRegister lädt dabei den Inhalt des Registers 0 der CPU 102. Die Funktion GetEncodedImmediate extrahiert den codierten Direktwert 4 aus der codierten Instruktion I_c. Die Funktion encodedAdd führt die Addition aus, wobei die Codierung der Daten berücksichtig wird und das Ergebnis der Addition unter Verwendung der Signatur des Ergebnisses sigResult codiert wird. Das Ergebnis ist das codierte Ergebnis result. Die hierzu erforderliche Korrektur kann nur mit Kenntnis der Signaturen der Operanden sig1 und sig2 durchgeführt werden.
Der Wert des Parameters Version hat sich von sig1 und sig2 zu sigResult von 2 auf 3 erhöht. Dies liegt daran, dass eine Instruktion ausgeführt wurde und dementsprechend der Parameter Version um eins erhöht wurde.
Im Schritt 209 wird die Differenz aus dem berechneten Kontrollwert und dem funktionalen Wert der tatsächlich ausgeführten Instruktion (d. h. dem Datenwort, dass die tatsächlich ausgeführte Instruktion spezifiziert) gebildet und das Ergebnis dieser Subtraktion zu allen durch die ausgeführte Instruktion veränderten Daten und zu dem codierten Programmzähler im Falle einer kontrollflussverändernden Instruktion addiert. Wurde die korrekte Instruktion ausgeführt und trat auch kein anderer Fehler auf, so dass der erste Term und der zweite Term des Kontrollwerts k Null sind, so ist die Differenz aus dem Kontrollwert und dem funktionalen Wert der tatsächlich ausgeführten Instruktion Null. In diesem Fall wird effektiv der Wert Null addiert und gültige Codeworte bleiben nach der Addition gültig. Ist jedoch ein Fehler aufgetreten, der sich im ersten oder zweiten Term des Kontrollparameters k oder in der Differenz des dritten Terms des Kontrollparameters k und dem funktionalen Wert der tatsächlich ausgeführten Instruktion widerspiegelt, so wird ein Wert ungleich Null addiert und mit hoher Wahrscheinlichkeit entstehen ungültige Codeworte, die bei einer Codeüberprüfung detektiert werden können. Wird, wie oben erwähnt, allgemein ein Wert f(I_f) als dritter Term verwendet, so kann je nach Ausgestaltung der Funktion f überprüft werden, ob die richtige Instruktion ausgeführt worden ist.
Im Falle der Addition wird Folgendes durchgeführt
result += k
result –= formInstruction ("add", 1, decode (operand2, sig2), 2)
storeRegister(2, result)
Dabei bewirkt der Befehl formInstruction die Erzeugung des funktionalen Werts der tatsächlich ausgeführten Instruktion mit den tatsächlich verwendeten Operanden, in diesem Fall der Instruktion add mit dem Register 0, dem Direktwert 4 und dem Ergebnisregister 2 als Operanden. Der Befehl storeRegister speichert das Ergebnis der Ausführung der Instruktion im Register 2. Der Wert der Variable result ist gemäß dem Befehl encodedAdd codiert.
Im Schritt 210 wird überprüft, ob alle Instruktionen des auszuführenden codierten Programms 108 ausgeführt wurden. Ist dies nicht der Fall, so wird die nächste Instruktion in Schritt 204 geladen. Wurde die letzte Instruktion ausgeführt und ist somit das Programmende erreicht, so wird der Ablauf im Schritt 211 beendet.
Zur Fehlerdetektion werden zu einem beliebigen Zeitpunkt der Programmausführung oder auch am Ende der Programmausführung die codierten Daten 107 dahingehend überprüft, ob sie gültige Codeworte sind. Dies kann von der CPU 102 selbst vorgenommen werden, aber auch von der Graphikkarte 103 oder einem FPGA (Field Programmable Gate Array) 110 des Computersystems 100 oder auch einer Prüf-Spezialhardware 111 des Computersystems 100, welche sowohl intern als auch extern vorgesehen sein können. Zur Codeüberprüfung werden die codierten Daten 107, der Speicheraddressen im Arbeitsspeicher 101 und die aktuelle Versionsnummer an die Hardware, die die Codeprüfung durchführt, übergeben. Der Ablauf für die Überprüfung des Inhalts einer Speicherzelle wird im Folgenden mit Bezug auf 3 erläutert.
3 zeigt ein Ablaufdiagramm 300 gemäß einem Ausführungsbeispiel der Erfindung.
Soll überprüft werden, ob ein Datum x_f in einer Speicherzelle korrekt codiert gespeichert ist, d. h., ob der Inhalt der Speicherzelle ein gültiges Codewort ist und somit mit hoher Wahrscheinlichkeit kein Fehler aufgetreten ist, der das Datum x_f betrifft, so wird in Schritt 301 für die Speicherzelle zunächst die erwartete Signatur h(Adresse, Version) berechnet. Diese Signatur wird als erwartete Signatur sigerwartet bezeichnet, wobei Adresse die Adresse der Speicherzelle ist, in der das Datum x_f gespeichert ist und Version die aktuelle Versionsnummer des Datums x_f ist, beispielsweise die Anzahl der ausgeführten Instruktionen seit dem Programmstart, welche von dem Interpreter 109 ermittelt werden kann.
Soll beispielsweise der Inhalt der Speicherzelle mit der Adresse 0x3564 überprüft werden und der Wert des Parameters Version ist 0x100, so wird als erwartete Signatur der Wert h(0x3564, 0x100) berechnet. Wie im obigen Beispiel wird z. B. als Parameter A der Wert 0xfff1 verwendet und die Signatur gemäß h(Adresse, Version) = Adresse·Version mod 0xfb berechnet.
Im Schritt 302 wird die aktuelle Signatur des Inhalts der Speicherzelle berechnet. Dies geschieht durch Moduln-Division des Inhalts der Speicherzelle gemäß sig_x = x_c mod A. Hierbei bezeichnet sig_x die aktuelle Signatur des Inhalts der Speicherzelle.
Im Schritt 303 werden die erwartete Signatur und die aktuelle Signatur der Speicherzelle verglichen. Stimmen beide überein, so ist in der Speicherzelle ein gültiges Codewort gespeichert und es ist mit hoher Wahrscheinlichkeit kein Fehler aufgetreten, der die Speicherzelle betrifft.
In diesem Fall wird in Schritt 304 entschieden, ob weitere Speicherzellen überprüft werden sollen oder nicht. Sollen weitere Speicherzellen überprüft werden, so wird die zu erwartende Signatur für die nächste zu überprüfende Speicherzelle gemäß Schritt 301 ermittelt. Sollen keine weiteren Speicherzellen überprüft werden, so wird der Ablauf in Schritt 305 beendet. Gemäß dem obigen Beispiel erfüllt beispielsweise der Inhalt der Speicherzelle x_c = 0x6ffdb die Bedingung, dass die aktuelle Signatur mit der erwartenden Signatur übereinstimmt. Der durch das Codewort 0x6ffdb gespeicherte funktionale Wert ist xf = xc/A = 0x6ffdb/0xfff1 = 7.
Stimmt die erwartete Signatur nicht mit der aktuellen Signatur der Speicherzelle überein, so ist ein Fehler aufgetreten und es wird davon ausgegangen, dass fehlerhafte Daten erzeugt wurden. In diesem Fall wird in Schritt 306 eine Fehlerbehandlung durchgeführt, beispielsweise wird die Ausführung des Programms beendet oder es werden andere Fehlertoleranzmaßnahmen durchgeführt.
Wie erwähnt kann zu beliebigen Zeitpunkt der Ausführung des Programms überprüft werden, ob die codierten Daten 107 korrekt sind, d. h. gültige Codeworte sind. In einer Ausführungsform werden Daten zumindest dann überprüft, wenn sie zur Weiterverarbeitung ausgegeben werden. Dabei wird in einer Ausführungsform der Erfindung auch der codierte Programmzähler PC_c überprüft, sodass festgestellt werden kann, ob der Kontrollfluss des Programms korrekt war.
Zur Codeüberprüfung kann auch eine spezielle Variable eingesetzt werden, in deren Wert sich alle auftretenden Fehler widerspiegeln. Dies kann beispielsweise mittels einer Variable erreicht werden, deren Wert die Summe aller Ergebnisse von ausgeführten Instruktionen ist. Es kann dann periodisch überprüft werden, ob der Wert dieser Summe ein gültiges Codewort ist. Bei dieser Vorgehensweise ist weniger Rechenaufwand zur Fehlerdetektion erforderlich.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[1] H. Wasserman, M. Blum. Software reliability via run-time result-checking. J. ACM, 44(6): 826-849, 1997
[2] M. Blum, M. Luby, R. Rubinfeld. Self-testing/correcting with applications to numerical problems. In STOC '90: Proceedings of the twenty-second annual ACM symposium on Theory of computing, pages 73-83, New York, NY, USA, 1990 ACM Press.
[3] Kuang-Hua Huang, J. A. Abraham. Algorithm-based fault tolerance for matrix operations. IEEE Trans. Computers, 33(6): 518-528, 1984.
[4] V. K. Stefanidis, K.G. Margaritis. Algorithm based fault tolerance: Review and experimental study. In International Conference of Numerical Analysis and Applied Mathematics, 2004.
[5] B. Nicolescu, Raoul Velazco. Detecting soft errors by a purely software approach: Method, tools and experimental results. In Date, pages 20057-20063. IEEE Computer Society, 2003
[6] S. Bagchi, Z. Kalbarczyk, R. Iyer, Y. Levendel. Design and evaluation of preemptive control signature (PECOS) checking. IEEE Transactions on Computers, 2003
[7] Nahmsuk Oh, Subhasish Mitra, Edward J. McCluskey. ED4I: Error detection by diverse data and duplicated instructions. IEEE Trans. Comput. 51(2): 180-199, 2002
[8] D. Bernick, B. Bruckert, P. Del Vigna, D. Garcia, R. Jardine, J. Klecka, J. Smullen. Nonstop^® advanced architecture. dsn, 00:12-21, 2005
[9] P. Forin. Vital coded microprocessor principles and application for various transit systems. In D, editor, IFA-GCCT, pages 79-84, Sept 1989
[10] DE 10219501 A1

Claims

Datenverarbeitungsanordnung aufweisend – einen Speicher, der eine Mehrzahl von Speicherelementen zum Speichern jeweils eines Datenwortes aufweist, – eine Zuordnungseinrichtung, die eingerichtet ist, jedem Speicherelement der Mehrzahl von Speicherelementen eine Signaturinformation zuzuordnen, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, – eine Codiereinrichtung, die eingerichtet ist, einem in einem Speicherelement zu speichernden Datenwort basierend auf der Signaturinformation ein Codewort zuzuordnen und das Codewort in dem Speicherelement zu speichern und – eine Überprüfungseinrichtung, die eingerichtet ist, anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
Datenverarbeitungsanordnung gemäß Anspruch 1, wobei jedes Codewort mindestens einer Signaturinformation entspricht und einem Datenwort ein Codewort zugeordnet wird, das der Signaturinformation entspricht, die dem Speicherelement zugeordnet ist.
Datenverarbeitungsanordnung gemäß Anspruch 2, wobei die Signaturinformation, die einem Codewort entspricht, aus dem Codewort ermittelbar ist.
Datenverarbeitungsanordnung gemäß Anspruch 2 oder 3, wobei die Überprüfungseinrichtung eingerichtet ist, zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist, indem sie überprüft, ob ein in dem Speicherelement gespeichertes Codewort der Signaturinformation, die dem Speicherelement zugeordnet ist, entspricht.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 4, wobei die Adressinformation eine Adresse des Speicherelements ist, mittels welchem das Speicherelement in dem Speicher adressiert werden kann.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 5, wobei die Signaturinformation auf einer dem Speicherelement zugeordneten Versionsinformation basiert.
Datenverarbeitungsanordnung gemäß Anspruch 6, wobei die Versionsinformation ein Wert ist, der bei jedem Eintreten mindestens eines vorgebbaren Versionsänderungs-Ereignisses geändert wird.
Datenverarbeitungsanordnung gemäß Anspruch 7, wobei das Versionsänderungs-Ereignis die Ausführung einer Instruktion eines Computerprogramms durch die Datenverarbeitungsanordnung ist.
Datenverarbeitungsanordnung gemäß Anspruch 8, wobei das Versionsänderungs-Ereignis die Ausführung einer Instruktion eines Computerprogramms durch die Datenverarbeitungsanordnung ist, bei der ein Datenwort verarbeitet wird.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 7 bis 9, wobei die Versionsinformation ein Wert ist, der ab einem vorgebbaren Startereignis ausgehend von einem Startwert bei jedem Eintreten des Versionsänderungs-Ereignisses inkrementiert wird.
Datenverarbeitungsanordnung gemäß Anspruch 10, wobei das Startereignis der Beginn der Ausführung eines Computerprogramms mittels der Datenverarbeitungsanordnung ist.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 6 bis 11, wobei bei jeder Änderung der Versionsinformation jedem Speicherelement der Mehrzahl von Speicherelementen die Signaturinformation zugeordnet wird und einem in dem Speicherelement zu speicherndem Datenwort basierend auf der Signaturinformation ein Codewort zugeordnet wird und das Codewort in dem Speicherelement gespeichert wird.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 12, wobei dem Datenwort das Codewort zugeordnet wird, indem das Datenwort und die Signaturinformation als Zahlenwerte dargestellt werden und das Codewort durch eine Rechenoperation aus dem Datenwort und der Signaturinformation das Codewort gebildet wird.
Datenverarbeitungsanordnung gemäß Anspruch 13, wobei dem Datenwort das Codewort zugeordnet wird, indem das Datenwort mit einem vorgebbaren Wert multipliziert wird und die Signaturinformation zu dem Ergebnis der Multiplikation addiert wird.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 14, wobei die Überprüfungseinrichtung eingerichtet ist, bei Eintreten eines Überprüfungsereignisses anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
Datenverarbeitungsanordnung gemäß Anspruch 15, wobei das Überprüfungsereignis die Ausgabe des Datenworts ist oder die Beendigung eines auf der Datenverarbeitungsanordnung ausgeführten Computerprogramms ist.
Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 16, ferner aufweisend eine Interpretationseinrichtung aufweist, die eingerichtet ist, das Datenwort, dem ein in einem Speicherelement gespeichertes Codewort zugeordnet ist, zu ermitteln und das Datenwort mittels der Datenverarbeitungsanordnung zu verarbeiten.
Datenverarbeitungseinrichtung gemäß Anspruch 17, bei der Laufzeitfehler bei der Verarbeitung des Datenworts oder der Ermittlung des Datenworts detektiert werden.
Verfahren zur Datenverarbeitung, bei dem – jedem Speicherelement einer Mehrzahl von Speicherelementen eines Speichers zum Speichern jeweils eines Datenwortes eine Signaturinformation zugeordnet wird, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, – einem in einem Speicherelement zu speichernden Datenwort basierend auf der Signaturinformation ein Codewort zugeordnet wird und das Codewort in dem Speicherelement gespeichert wird, – anhand der einem Speicherelement zugeordneten Signaturinformation überprüft wird, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
Computerprogrammelement, das, wenn es von einem Prozessor ausgeführt wird, bewirkt, dass der Prozessor ein Verfahren zur Datenverarbeitung ausführt, bei dem – jedem Speicherelement einer Mehrzahl von Speicherelementen eines Speichers zum Speichern jeweils eines Datenwortes eine Signaturinformation zugeordnet wird, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, – einem in einem Speicherelement zu speichernden Datenwort basierend auf der Signaturinformation ein Codewort zugeordnet wird und das Codewort in dem Speicherelement gespeichert wird, – anhand der einem Speicherelement zugeordneten Signaturinformation überprüft wird, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
Überprüfungsanordnung für einen Speicher, der eine Mehrzahl von Speicherelementen zum Speichern jeweils eines Datenwortes aufweist, aufweisend – eine Zuordnungseinrichtung, die eingerichtet ist, jedem Speicherelement der Mehrzahl von Speicherelementen eine Signaturinformation zuzuordnen, die auf einer dem Speicherelement zugeordneten Adressinformation basiert, – eine Überprüfungseinrichtung, die eingerichtet ist, anhand der einem Speicherelement zugeordneten Signaturinformation zu überprüfen, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.