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

Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher Download PDF

Info

Publication number
DE102007040721B4
DE102007040721B4 DE102007040721A DE102007040721A DE102007040721B4 DE 102007040721 B4 DE102007040721 B4 DE 102007040721B4 DE 102007040721 A DE102007040721 A DE 102007040721A DE 102007040721 A DE102007040721 A DE 102007040721A DE 102007040721 B4 DE102007040721 B4 DE 102007040721B4
Authority
DE
Germany
Prior art keywords
memory element
data
data processing
signature information
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE102007040721A
Other languages
English (en)
Other versions
DE102007040721A1 (de
Inventor
Dipl.-Inf. Wappler Ute
Prof. Dr. Fetzer Christof
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Silistra Systems De GmbH
Original Assignee
Technische Universitaet Dresden
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Technische Universitaet Dresden filed Critical Technische Universitaet Dresden
Priority to DE102007040721A priority Critical patent/DE102007040721B4/de
Publication of DE102007040721A1 publication Critical patent/DE102007040721A1/de
Application granted granted Critical
Publication of DE102007040721B4 publication Critical patent/DE102007040721B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1008Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's in individual solid state devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Detection And Correction Of Errors (AREA)

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, diet 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 verwende, 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.
  • 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 xf wird codiert durch xc = A·xf + Bx + d wobei A eine Variablenunabhängige Konstante ist, Bx 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 xc ein gültiges Codewort ist, indem überprüft wird, ob (xc – d) mod A der für die entsprechenden Variable x vorgesehenen Signatur Bx 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 xc 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 xf von durch folgende Ganzzahldivision (xc – 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 xf, so hat sie bei der zweiten Ausführung den Wert xc = –A·xf – 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.
  • Ferner wird in Druckschrift [11] eine Schaltungsanordnung beschreiben, die eine kodierende Einheit aufweist, die ihrerseits erste Eingänge zum Anlegen eines Adresswortes und zweite Eingänge zum Anlegen eines Datenwortes und eines Kontrollwortes aufweist. Die kodierende Einheit ist dabei ausgebildet, ein Alarmsignal auszugeben, wenn das Kontrollwort zumindest nicht mit dem Adresswort oder dem Datenwort übereinstimmt.
  • 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 adressierbaren 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, wobei das Codewort gebildet wird aus dem Datenwort, multipliziert mit einer vorgegebenen Konstante, die nicht als Zweierpotenz gewählt ist, addiert mit der Signaturinformation, 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 (instruktion 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 verarbeite 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 codiere 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 Zeitpunk 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 xf wird der codierte Inhalt xc in einer Speicherzelle des Arbeitsspeichers 101 gespeichert und bei der Ausführung des Programms 105 verwendet. xf 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 xf auch nur einen Teil einer Programminstruktion bezeichnen und xc 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 xf 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 xc 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 0x8fc1fff4 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 0x8fc3fff 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 r4 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 0x8fc1fff0 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 Assemblerbefehls 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 Modulo-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) = 0x2000fe6004b (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 Versonsinformation 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 PCc = A·PCf + h(PCf, 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 Ic aus dem Arbeitsspeicher 101 aus der Speicherzelle geladen, deren Adresse durch den funktionalen Wert PCf des codierten Programmzählers PCc 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 Ic = 0x20001fe6004b.
  • In Schritt 205 wird die geladene codierte Instruktion decodiert. Dies geschieht mittels ganzzahliger Division der codierten Instruktion Ic durch A. Das Ergebnis ist die decodierte Instruktion If, also If = Ic/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(PCf, Versionp) – Ic 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(PCf, Versiond) – PCc 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 PCc ein korrektes Codewort ist und eine korrekte Codierung des funktionalen Werts des Programnzählers PCf ist. Ist der Programmzähler korrekt codiert, so hat der zweite Term Wert 0.
  • Die verwendeten Versionsnummern Versionp und Versiond 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 If, 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 If abhängt, also eine Funktion f(If) ist. Als Funktion f kann beispielsweise die Identität verwendet werden.
  • In Schritt 207 werden die zur Ausführung der Instruktion erforderlichen Bestandteile aus Ic 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(operandl, sig1, operand2, sig2, sigResult)
  • Die Funktion loadRegister lädt dabei den Inhalt des Registers 0 der CPU 102. Die Funktion GetEncodedlmmediate extrahiert den codierten Direktwert 4 aus der codierten Instruktion Ic. 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(If) 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 xf 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 xf 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 xf gespeichert ist und Version die aktuelle Versionsnummer des Datums xf 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 Modulo-Division des Inhalts der Speicherzelle gemäß sigx = xc mod A. Hierbei bezeichnet sigx 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 xc = 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 PCc ü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
    • [11] DE 10 2004 041 657 A1

Claims (21)

  1. Datenverarbeitungsanordnung aufweisend – einen Speicher, der eine Mehrzahl von adressierbaren 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, wobei das Codewort gebildet wird aus dem Datenwort, multipliziert mit einer vorgegebenen Konstante, die nicht als Zweierpotenz gewählt ist, addiert mit der Signaturinformation, 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.
  2. 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.
  3. Datenverarbeitungsanordnung gemäß Anspruch 2, wobei die Signaturinformation, die einem Codewort entspricht, aus dem Codewort ermittelbar ist.
  4. 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.
  5. 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.
  6. Datenverarbeitungsanordnung gemäß einem der Ansprüche 1 bis 5, wobei die Signaturinformation auf einer dem Speicherelement zugeordneten Versionsinformation basiert.
  7. Datenverarbeitungsanordnung gemäß Anspruch 6, wobei die Versionsinformation ein Wert ist, der bei jedem Eintreten mindestens eines vorgebbaren Versionsänderungs-Ereignisses geändert wird.
  8. Datenverarbeitungsanordnung gemäß Anspruch 7, wobei das Versionsänderungs-Ereignis die Ausführung einer Instruktion eines Computerprogramms durch die Datenverarbeitungsanordnung ist.
  9. 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.
  10. 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.
  11. Datenverarbeitungsanordnung gemäß Anspruch 10, wobei das Startereignis der Beginn der Ausführung eines Computerprogramms mittels der Datenverarbeitungsanordnung ist.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Datenverarbeitungsanordnung gemäß Anspruch 15, wobei das Überprüfungsereignis die Ausgabe des Datenworts ist oder die Beendigung eines auf der Datenverarbeitungsanordnung ausgeführten Computerprogramms ist.
  17. 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.
  18. Datenverarbeitungseinrichtung gemäß Anspruch 17, bei der Laufzeitfehler bei der Verarbeitung des Datenworts oder der Ermittlung des Datenworts detektiert werden.
  19. Verfahren zur Datenverarbeitung, bei dem – jedem Speicherelement einer Mehrzahl von adressierbaren 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, wobei das Codewort gebildet wird aus dem Datenwort, multipliziert mit einer vorgegebenen Konstante, die nicht als Zweierpotenz gewählt ist, addiert mit der Signaturinformation, – anhand der einem Speicherelement zugeordneten Signaturinformation überprüft wird, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
  20. 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 adressierbaren 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, wobei das Codewort gebildet ist aus dem Datenwort, multipliziert mit einer vorgegebenen Konstante, die nicht als Zweierpotenz gewählt ist, addiert mit der Signaturinformation, – anhand der einem Speicherelement zugeordneten Signaturinformation überprüft wird, ob ein in dem Speicherelement gespeichertes Datenwort ein gültiges Codewort ist.
  21. Ü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 adressierbaren 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, wobei das Codewort gebildet ist aus dem Datenwort, multipliziert mit einer vorgegebenen Konstante, die nicht als Zweierpotenz gewählt ist, addiert mit der Signaturinformation.
DE102007040721A 2006-12-08 2007-08-23 Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher Expired - Fee Related DE102007040721B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102007040721A DE102007040721B4 (de) 2006-12-08 2007-08-23 Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102006059092 2006-12-08
DE102006059092.9 2006-12-08
DE102007040721A DE102007040721B4 (de) 2006-12-08 2007-08-23 Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher

Publications (2)

Publication Number Publication Date
DE102007040721A1 DE102007040721A1 (de) 2008-06-19
DE102007040721B4 true DE102007040721B4 (de) 2012-06-21

Family

ID=39399895

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007040721A Expired - Fee Related DE102007040721B4 (de) 2006-12-08 2007-08-23 Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher

Country Status (1)

Country Link
DE (1) DE102007040721B4 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014219179A1 (de) * 2014-09-23 2016-03-24 Siemens Aktiengesellschaft Verfahren zur parallelen Verarbeitung von Daten in einem Rechnersystem mit mehreren Rechnereinheiten und Rechnersystem mit mehreren Rechnereinheiten

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010037457B4 (de) 2010-09-10 2012-06-21 Technische Universität Dresden Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zum Erzeugen von Programm-Code, Datenverarbeitungsanordnungen zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Datenverarbeitungsanordnungen zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
DE102014114157B4 (de) * 2014-09-30 2016-11-03 Technische Universität Dresden Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
EP4266175B1 (de) 2022-04-22 2024-09-04 Siemens Mobility GmbH Verfahren zum rechnergestützten betreiben einer speichereinheit und ausführen von applikationsprogrammen mit speicherüberprüfung auf speicherfehler

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10219501A1 (de) * 2002-04-30 2003-11-27 Siemens Ag System und Verfahren zur Verbesserung von Fehlerbeherrschungsmassnahmen, insbesondere in Automatisierungssystemen

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10219501A1 (de) * 2002-04-30 2003-11-27 Siemens Ag System und Verfahren zur Verbesserung von Fehlerbeherrschungsmassnahmen, insbesondere in Automatisierungssystemen

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FORIN, P.: Vital coded microprocessor principles and application for various transit systems. In: IFAC Symposia Series, 1990, Nr. 12, S. 79-84 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014219179A1 (de) * 2014-09-23 2016-03-24 Siemens Aktiengesellschaft Verfahren zur parallelen Verarbeitung von Daten in einem Rechnersystem mit mehreren Rechnereinheiten und Rechnersystem mit mehreren Rechnereinheiten

Also Published As

Publication number Publication date
DE102007040721A1 (de) 2008-06-19

Similar Documents

Publication Publication Date Title
DE102010037457B4 (de) Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zum Erzeugen von Programm-Code, Datenverarbeitungsanordnungen zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Datenverarbeitungsanordnungen zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
DE69619372T2 (de) Fehlererkennungs- und fehlerkorrekturverfahren
DE102011112174B4 (de) Vorrichtung und Verfahren zum Schutz und zur zerstörungsfreien Prüfung sicherheitsrelevanter Register
DE102015210651B4 (de) Schaltung und Verfahren zum Testen einer Fehlerkorrektur-Fähigkeit
DE102006005817B4 (de) Fehlererkennungsvorrichtung für einen Adressdecoder und Vorrichtung zur Fehlererkennung für einen Adressdecoder
DE102005016050A1 (de) Speicherfehlererkennungsvorrichtung und Verfahren zum Erkennen eines Speicherfehlers
DE102014117971B4 (de) Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
DE102007040721B4 (de) Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher
DE102004011450A1 (de) Anvisierte Fehlertoleranz durch spezielle CPU-Befehle
EP1955164A1 (de) Programmgesteuerte einheit und verfahren zum betreiben derselbigen
DE102011119585A1 (de) Verbesserte skalierbare CPU für die codierte Ausführung von Software in hochabhängigen sicherheitsrelevanten Anwendungen
DE102014114157B4 (de) Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
EP1359485B1 (de) Steuer- und Überwachungssystem
DE102022111126A1 (de) Datenverarbeitungsvorrichtung und verfahren zum prüfen der integrität eines speichers
DE102005016051B4 (de) Speicherüberprüfungsvorrichtung und Verfahren zum Überprüfen eines Speichers
EP3798873B1 (de) Verfahren zum schützen einer computer-implementierten anwendung vor manipulation
WO2006089943A1 (de) Verfahren zur datensicherung und gerät zu dessen ausführung
DE102020211540A1 (de) Verfahren zur Absicherung eines Mikrocontrollers
DE102010032765B4 (de) Automatische Verifizierung von Übersetzungen
DE102005040917A1 (de) Datenverarbeitungssystem und Betriebsverfahren dafür
DE102013112020B4 (de) Verfahren und Vorrichtung zum Erkennen von Bitfehlern
DE102018219700B4 (de) Steuervorrichtung
EP4181000A1 (de) Verfahren und rechenumgebung zum erstellen und anwenden eines prüfalgorithmus für rechenvorgänge
EP1246062B1 (de) Verfahren zum Betrieb eines von einem Prozessor gesteuerten Systems
DE102015114233B4 (de) Datenverarbeitungsvorrichtungen und Verfahren zum Speichern eines Datenvektors

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8181 Inventor (new situation)

Inventor name: FETZER, CHRISTOF, PROF. DR., 01277 DRESDEN, DE

Inventor name: WAPPLER, UTE, DIPL.-INF., 01069 DRESDEN, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20120922

R081 Change of applicant/patentee

Owner name: SILISTRA SYSTEMS GMBH, DE

Free format text: FORMER OWNER: TECHNISCHE UNIVERSITAET DRESDEN, 01069 DRESDEN, DE

Effective date: 20121204

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