Optimierung einer Softwarebibliothek für sicherheitsrelevante

Fachhochschule
Bonn-Rhein-Sieg
University of Applied Sciences
Fachbereich Informatik
Department of Computer Science
Abschlussarbeit
im Bachelor Studiengang
Optimierung einer Softwarebibliothek für
sicherheitsrelevante Anwendungen auf 32 Bit
µControllern der „ARM“-Familie
von
Denis Kiel
Erstbetreuer: Prof. Dr.-Ing. Norbert Jung
Zweitbetreuer: Prof. Dr. Dietmar Reinert
Eingereicht am: 17.09.2007

Danksagung 2
Danksagung
An dieser Stelle möchte ich mich bei allen Beteiligten, die an der Erstellung dieser Ausarbeitung
mitgewirkt haben, herzlich bedanken.
Besonderer Dank geht an:
Prof. Dr. Dietmar Reinert und Prof. Dr. -Ing. Norbert Jung die mich immer mit ihrem Rat
unterstützt haben.
Meinen Kommilitonen Edmund Milke und Christian Müller, die mich mit Rat und Tat immer
unterstützen.
Ganz besonderer Dank geht an meine Frau Natalia und meinen Sohn David, die mich
die ganze Zeit motivierten, viel Geduld hatten, sowie auf viele Gemeinsamkeiten verzichten
mussten.

Erklärung 3
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Bachelorarbeit selbständig angefertigt habe.
Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt.
Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches kenntlich
gemacht.
Ort, Datum Unterschrift

Kurzfassung 4
Kurzfassung
Diese Thesis beschäftigt sich mit einer Softwarebibliothek, die grundlegende Tests eines
µControllers, der auf einem „ARM7TDMI“-Prozessor basiert, enthält. Diese Bibliothek
soll es ermöglichen sicherheitskritische Anwendungen auf diesen µControllern laufen zu
lassen. Tests, die diese Bibliothek enthält, sind so genannte Selbsttests, die der Fehleraufdeckung
sowie der Fehlerbeherrschung dienen. Diese Tests prüfen Hardware auf
ihre Fehlerfreiheit. Die Software, die auf dem µController eingespielt ist, wird nicht getestet.
Zu den Tests, die in dieser Bibliothek enthalten sind, zählen: CPU-, Register-, RAM-,
ROM-, Timer-, Ein/Ausgabe-Tests, sowie Analog-Digital- und Digital-Analog-Wandler-
Test wobei beim RAM-Test kein Laufzeitstack getestet wird.
Es wird Softwaremäßig getestet. Bei diesen Tests werden keine weiteren Hardwarekomponenten
benötigt, nur die, die der µController besitzt.
Bei dem CPU-Test wird das Vergleichsprinzip zum Testen verwendet. In diesem Test
werden alle Befehle auf ihre korrekte Funktionalität überprüft. Beim Register- sowie beim
Ein/Ausgabe-Test wird das Prinzip des „Walking-Bit-Patterns“ angewendet.
Weil für das Testen der Komponenten im Echtzeitbetrieb sehr wenig Zeit zur Verfügung
steht, wird der Analog-Digital- und Digital-Analog-Wandler anhand des Plausibilitätsprinzips
geprüft.
Der RAM- und ROM-Test werden so konzipiert und entworfen, dass diese in Scheiben
ausführbar sind. Solch eine Vorgehensweise erlaubt die Ausführung von diesen Tests
im Hintergrund einer Hauptanwendung. Zum Testen des RAMs wird der transparente
Speichertest implementiert. Zum Testen des ROMs wird eine CRC-Prüfsumme (oder
auch CRC-Signatur) verwendet.
Außerdem wird ein Überblick über die ARM-Architektur (Grundwissen) und Anforderungen
an sicherheitskritische Anwendungen gegeben.

Inhaltsverzeichnis 5
Inhaltsverzeichnis
Danksagung...................................................................................................................2
Erklärung .......................................................................................................................3
Kurzfassung ..................................................................................................................4
Inhaltsverzeichnis.........................................................................................................5
1 Einleitung............................................................................................................7
1.1 Zielsetzung / Motivation .......................................................................................7
1.2 Aufbau der Thesis................................................................................................8
1.3 Stand der Technik................................................................................................8
1.4 Abgrenzung: Stand der Technik und eingeschlagener Realisierungsweg...........9
2 Grundlagen.......................................................................................................10
2.1 Aufbau der Hardware.........................................................................................10
2.1.1 ARM-Architektur.................................................................................................10
2.1.2 Das Evaluationsboard MCB2140 von Keil .........................................................12
2.2 Entwicklungsumgebung HITOP 5.2 ...................................................................23
2.3 Anforderungen an sicherheitsgerichtete Systeme .............................................24
2.4 Fehler.................................................................................................................25
2.5 Tests und Testverfahren ....................................................................................27
2.5.1 CPU-Tests .........................................................................................................28
2.5.2 RAM/ROM-Fehler ..............................................................................................29
2.5.3 RAM- und ROM-Testverfahren ..........................................................................31
2.5.4 Ein-/Ausgabe Test .............................................................................................34
3 Anforderungsanalyse und –definition ...........................................................36
3.1 Zielbestimmung..................................................................................................36
3.1.1 Musskriterien......................................................................................................36
3.1.2 Kannkriterien......................................................................................................36
3.1.3 Abgrenzungskriterien .........................................................................................37
3.2 Bibliothekseinsatz ..............................................................................................37
3.2.1 Anwendungsbereiche ........................................................................................37
3.2.2 Zielgruppen ........................................................................................................37
3.3 Bibliotheksfunktionen .........................................................................................37
3.4 Bibliotheksleistungen .........................................................................................38
3.5 Technische Bibliotheksumgebung .....................................................................38
3.5.1 Software.............................................................................................................38
3.5.2 Hardware ...........................................................................................................38
4 Konzept und Implementierung .......................................................................39

Inhaltsverzeichnis 6
4.1 Software.............................................................................................................39
4.1.1 Programmablauf ................................................................................................39
4.1.2 Watchdog-Test...................................................................................................40
4.1.3 Register-Test .....................................................................................................41
4.1.4 CPU-Test ...........................................................................................................43
4.1.5 RAM-Test...........................................................................................................47
4.1.6 Ein-/Ausgabe Test .............................................................................................49
4.1.7 ROM-Test ..........................................................................................................50
4.1.8 Timer-Test..........................................................................................................51
4.1.9 Zeitscheibenverfahren .......................................................................................51
5 Validation..........................................................................................................53
6 Fazit und Ausblick ...........................................................................................55
Literaturverzeichnis....................................................................................................56
Abbildungsverzeichnis...............................................................................................58
Tabellenverzeichnis....................................................................................................60
Anhang A: Tests..........................................................................................................61
Anhang B: Entwicklungsumgebung HITOP 5.2 .......................................................69
Abkürzungsverzeichnis..............................................................................................72

1 Einleitung 7
1 Einleitung
Während in der heutigen Welt Mikrokontroller, die ihre Dienste in Bereichen wie Consumer
Elektronik, Industrie, Fahrzeugtechnik, Luft- und Raumfahrtechnik, sowie in vielen
anderen Sparten erbringen, immer mehr Aufgaben übernehmen, steigen auch die
Sicherheitsanforderungen, falls sie sicherheitskritische Aufgaben erbringen müssen. Zu
diesen Aufgaben zählen z.B. in der Fahrzeugtechnik ABS 1 - und ESP 2 -Steuerung, in der
Industrie die Steuerung von Robotern, die zusammen mit Menschen arbeiten. Eine der
wichtigsten Aspekte der sicherheitsrelevanten oder auch sicherheitskritischen Anwendungen
ist es, zu einem gewissen Grad sicherzustellen, dass die Hardware, auf der diese
Anwendungen ausgeführt werden, nicht fehlerhaft ist und dass auch zur Laufzeit keine
Fehler auftreten. Falls infolge z.B. externer Einwirkungen oder auch Materialermüdung
Fehler in der Hardware auftreten, soll in vorgegebener Weise auf diese reagiert
werden. Eine der Möglichkeiten Fehler in der Hardware aufzudecken ist es, bestimmte
hardwarespezifische Selbsttests durchzuführen. Zu diesen grundlegenden Tests gehört
unter anderem z.B. ein Arbeitspeicher-Test.
1.1 Zielsetzung / Motivation
Ziel dieser Thesis ist es, eine vorhandene Bibliothek, die der Fehleraufdeckung und
Fehlerbeherrschung dient, eingehend zu untersuchen und weiter zu entwickeln. Die
entwickelten Tests können dann in sicherheitskritische Anwendungen eingebunden werden
und im Hintergrund laufen. Alle Tests sollen, gemeinsam oder einzeln, nicht mehr
als ein Drittel 3 der Ausführungszeit am Stück die CPU belegen. Es soll ein möglichst
vollständiger Testsatz entstehen, der einen Fehleraufdeckungsgrad von mindestens
90% ermöglicht. Die Bibliothek wird für das Evalutionsboard MCB2140 von Keil, das
eine LPC2148-CPU von Philips (heute NXP) besitzt, die zur „ARM7TDMI“-Familie gehört,
entwickelt, ist aber auf viele andere µController die zur Philips LPC2xxx Familie
gehören portierbar. Außer der Philips µControllern können auch µController anderer
Hersteller getestet werden, aber nur wenn diese über eine „ARM7TDMI“-CPU verfügen.
Auf diesen µControllern werden der CPU- und der Register-Test mit sehr hoher Wahrscheinlichkeit
ohne Einschränkungen laufen. Die anderen Tests müssen angepasst werden.
Im Vordergrund dieser Thesis lag die Idee; erworbene Kenntnisse der Lehrveranstaltungen
„Grundlagen eingebetteter Systeme“ sowie „Designmethodik zuverlässiger Systeme“
in der Praxis zu vertiefen. Außerdem werden die Ergebnisse dieser Thesis zur Lehre
dieser Fächer zur Verfügung gestellt.
1 Anti Blockier System
2 Elektronisches Stabilitätsprogramm
3 z.B. bei Ausführungszeit von einer Sekunde wären es ~330ms

1 Einleitung 8
Die Entscheidung eine Bibliothek für einen µController, der auf einem „ARM7TDMI“ 32-
Bit Prozessor basiert zu entwickeln, wurde durch folgende Gründe beeinflusst. Als erster
Grund hierfür dient die Tatsache, dass ARM-Prozessoren in bestimmten Marktsegmenten
sehr große Marktanteile besitzen. Deshalb entstand die Frage, ob es möglich wäre
sicherheitskritische Anwendungen auf diesen µControllern auszuführen. Als zweiter
Grund kann die Tatsache angesehen werden, dass während des Studiums nur mit
µControllern, die 8-Bit bzw. mit 16-Bit Prozessoren besitzen, gearbeitet wurde. Deswegen
dient diese Thesis auch als Einstieg in den 32-Bit µController-Welt. Zudem wurden
die Selbsttests z.B. im BGIA (Berufgenossenschaftliches Institut für Arbeitschutz)-Report
7/2006 für den 80C537 von Siemens, der eine 8-Bit CPU besitzt, entwickelt [BGIA706].
Es bleibt noch hinzuzufügen, dass, obwohl eigentlich einzelne Testmethoden für Speicher
oder CPU vorhanden sind und implementiert wurden, zu kompletten Testroutinen
gibt. Ausnahmen bilden [BGIA706] und [TUR05].
1.2 Aufbau der Thesis
Für fast jedes Projekt sind festgelegte Anforderungen sehr wichtig. Deswegen werden in
dieser Thesis im Kapitel 2 Grundlagen der Sicherheitstechnik, Besonderheiten der ARM-
Architektur sowie Tests und Testverfahren vorgestellt. Basierend auf diesen Informationen,
bilden im Kapitel 3 Anforderungen an eine Bibliothek festgelegt und anhand derer
die Bibliothek im Kapitel 4 entworfen und im Kapitel 5 implementiert. Im Kapitel 6 werden
die implementierten Methoden getestet, sowie deren Ausführungszeiten gemessen. Abschließend
wird ein Fazit gezogen.
1.3 Stand der Technik
Als Ausgangsbasis für diese Thesis dient ein Prototyp einer Softwarebibliothek, der einige
Selbsttest beinhaltet. Dieser Prototyp wurde im Fachbereich für interne Benutzung
entworfen. Zu den Tests, die in der Bibliothek enthalten sind, zählen: Register-, Arbeitspeicher(RAM)-,
Programmspeicher(ROM)-, Watchdog- und CPU-Test, wobei bei diesem
Test nur einige Befehle getestet wurden. Diese Bibliothek wird überarbeitet und
weiter entwickelt. Sehr viele Grundgedanken und Ideen sind in [BGIA706] und [TUR05]
erläutert.
Der in der Bibliothek vorhandene Register-Test basiert auf so genannten „Walking Bit
Pattern“-Verfahren. Für den Arbeitsspeicher–Test wurden zwei verschiedene Methoden
implementiert: Als erstes ein transparenter Speichertest und zweitens ein „March X“-
Test. Dies hatte zum Ziel, Unterschiede in Ausführungsgeschwindigkeit und Fehleraufdeckungsgrad
zu ermittelt. Beim Programmspeicher-Test wird beim Start eine 32-Bit
lange Signatur(CRC 4 ) gebildet, dann im Betrieb in bestimmten Zeitintervallen eine neue
berechnet und mit dem Anfangswert verglichen. Grundgedanke des implementierten
4 CRC – Cyclic Redundancy Check

1 Einleitung 9
CPU-Tests ist es, Befehle der CPU mit bestimmten Testwerten durchzuführen und die
Ergebnisse mit Erwartungswerten zu vergleichen.
Die Bibliothek wurde zum Testen der Hardware entworfen und benutzt. Fehler in der
Software werden nicht aufgedeckt.
1.4 Abgrenzung: Stand der Technik und eingeschlagener
Realisierungsweg
Watchdog-, Register- und ROM-Test werden im Wesentlichen von der Bibliothek übernommen.
Nur die Feinheiten werden überarbeitet:
• beim Register-Test wird anstelle von einer Multiplikation, eine Schiebeoperation
benutzt
• beim ROM-Test anstelle einer 16-Bit eine 32-Bit lange Signatur benötigt, was eine
größere Fehleraufdeckung ermöglicht
Im Falle des RAM-Tests wird eine der beiden implementierten Methoden ausgewählt
und weiterentwickelt. Es kommt ebenfalls eine 32-Bit-Signatur zum Einsatz. Wie auch im
vorhandenen Test wird im überarbeiteten kein Laufzeitstack überprüft. Der CPU-Test
wird auf den ganzen Befehlsatz erweitert, womit eine hinreichend große Fehlerfreiheit
gewährleistet wird.
Zur Bibliothek wird ein Test der Ein-/Ausgabeports hinzugefügt. Zudem werden Digital-
Analog- und Analog-Digital-Umsetzer getestet. Da in der Bibliothek ein so genanntes
Zeitscheiben-Verfahren zum Einsatz kommt, wird auch der Timer getestet.
Da für diese Thesis eine bestimmte Anzahl von Stunden zur Verfügung steht, wurde
entschieden nur die obengenannten Tests, die zu den grundlegenden Tests gehören, zu
entwickeln. Werden zusätzliche Funktionseinheiten des Kontrollers verwendet, müssen
diese natürlich ebenfalls getestet werden.

2 Grundlagen 10
2 Grundlagen
Das Grundlagenkapitel beschreibt für die Arbeit genutztes Prozessorboard, die Entwicklungsumgebung,
die Grundlagen der Sicherheitstechnik, sowie die Selbsttestmethoden.
2.1 Aufbau der Hardware
In diesem Kapitel wird auf Besonderheiten der ARM-Architektur eingegangen.
2.1.1 ARM-Architektur
Bevor die ARM-Architektur detailliert beschrieben wird, werden zunächst die Begriffe
CISC und RISC erklärt. Diese Begriffe sind hier deswegen wichtig, weil die ARM-
Prozessoren sich von der Mehrheit auf dem Markt vorhandenen Prozessoren unterscheiden.
Die meisten Mikroprozessoren sind heutzutage „Universalprozessoren“, die
über einen umfangreichen Befehlssatz verfügen. Diese Prozessoren besitzen einige
hunderte Befehle in unterschiedlichen Formaten, Dutzende von Adressierungsarten,
sowie unterschiedliche Datentypen. Diese zählen zu so genannten CISC-Prozessoren,
also „Complex Instruction Set Computer“. Die Realisierung dieser Prozessoren ist mit
einigen technischen sowie ökonomischen Problemen verbunden, wie z.B.:
• Ein großer Befehlssatz mit verschiedenen Adressierungsarten bedarf eines sehr
komplexen Steuerwerks. Große Komplexität kann Fehler hervorrufen. Zudem
wird für das Steuerwerk viel Chipfläche benötigt.
• Da die Befehle komplex sind, werden für gleiche Befehle meist unterschiedliche
Ausführungszeiten benötigt. Dies bedeutet, dass eine vollständige Pipeline
(„Fließbandverarbeitung“ [BEC03]) nur mit einem hohen Aufwand realisierbar
und in der Regel nicht effizient ist.
• Es werden effiziente Compiler benötigt [vgl. BEC03].
Aus einer Studie von IBM in den frühen 70iger Jahren wurde bekannt, dass die meisten
Befehle des Befehlssatzes eines IBM-Minicomputers gerade einmal zu 1% zum Einsatz
in einem Standardprogramm kamen, der von einem Compiler erzeugt wurde. Als Resultat
dieser Studie wurde folgendes ersichtlich: Reduzierung eines Befehlsatzes auf ein
Minimum und Festverdrahtung einzelner Befehle in einem Schaltwerk. Das war die „Geburtsstunde“
der RISC-Architektur (Reduced Instruction Set Computer). Die Grundidee
eines RISC-Prozessors ist es, den möglichst größten Teil der Befehle in einem Taktzyklus
ausführen zu können [vgl. WAL04].
Die Grenzen zwischen CISC- und RISC-Prozessoren sind fließend zu verstehen und
der Unterschied zwischen den beiden wird in letzter Zeit immer kleiner. Zum Beispiel
benutzte auch Intel in seiner 486-Prozessorlinie einen RISC-Kern, der die einfachsten
Befehle ausführte, die komplexeren wurden dann vom CISC-Kern bearbeitet. Da aber

2 Grundlagen 11
die RISC-Prozessoren weiterentwickelt wurden, ähneln sie jetzt den CISC-Prozessoren.
RISC-Prozessoren ebenso wie CISC-Prozessoren auch „Universalprozessoren“, die in
vielen Branchen zum Einsatz kommen, wie z.B. PDAs oder Spielkonsolen, auch deswegen,
weil sie stromsparend sind. Für die meisten RISC-Prozessoren gelten weitere
Merkmale [vgl. BEC03]:
• Die Komplexität des Steuerwerkes ist um ein vielfaches reduziert.
o Es wird ein relativ kleiner Befehlsatz (30-100 Befehle) verwendet.
o Speicherzugriff nur über LOAD- und STORE-Befehle, grundsätzlich wird
mit Registern gearbeitet .
o Bevorzugt wird das 3-Adress-Format (Opcode / Source1/ Source2/
Destination).
o Ganzzahlige Datentypen (Byte, Wort, Doppelwort).
o Ausführung aller Befehle möglichst in einem Taktzyklus.
• Durch diese Maßnahmen erreicht man ein einfaches, festverdrahtetes Steuerwerk.
• Alle Datenwege sind 32-Bit breit.
• Getrennte Pfade für Daten- und Programmspeicher (Harward-Architektur).
• Relativ viele 32-Bit-Register.
• Befehlsverarbeitung durch eine vollständige, lineare Pipeline(meist 3-stufig).
Pipeline-Verarbeitung ist für die RISC-Prozessoren sehr wichtig und bedeutet die Zerlegung
eines Befehls in Einzelschritte. Im Falle einer 3-stufigen Pipeline wird ein Befehl in
drei Einzelschritte zerlegt [WAL04]: „1. Befehl aus dem Speicher holen (Instruction
Fetch), 2. Befehl decodieren (Instruction Decode), 3. Befehl ausführen (Instruction Execute)“.
Wobei die einzelnen Schritte dieser Pipeline in mehreren Schritten ausgeführt
sein können, je nach Instruktionskomplexität. Das Funktionsprinzip zeigt die Abbildung
1 (hier sind die einzelnen Schritte in einem Taktzyklus ausführbar):
Abbildung 1: 3-stufige Pipeline
Die Funktionsweise einer 3-stufigen Pipeline ist folgende: Während im zweiten Zyklus(Cycle
2) der 1. Befehl (Instruction 1) dekodiert (Decode) wird, werden in der zweiten
Stufe der Pipeline bereits die Instruktionen für den zweiten Befehl (Instruction 2) geholt.
In drittem Zyklus (Cycle 3) wird der 1. Befehl ausgeführt (Execute), der 2. Befehl decodiert
und Instruktionen für den 3. Befehl (Intruction 3) geholt usw. Sind die einzelnen
Befehle einfache Befehle, z.B. logische, so werden sie in dieser Pipeline in einem Takt-

2 Grundlagen 12
zyklus ausgeführt. Aus der Tatsache, dass die meisten Befehle eines RISC-Prozessors
in einem Taktzyklus ausführbar sind und für jede Stufe der Pipeline ein anderes bestimmtes
Stück Hardware verantwortlich ist, bewirkt die Pipeline eine parallele Bearbeitung
eines Befehls in mehreren Schritten. Das Prinzip der Pipeline ist dem des Fließbands
ähnlich, z.B. bei der Autoherstellung.
Die ARM-Prozessoren basieren auf einer RISC-Architektur. Die inzwischen inoffizielle
Abkürzung „ARM“ steht für „Advanced RISC Machine“ oder auch „Acorn RISC Machine“.
ARM ist das Warenzeichen der britischen Firma ARM Limited, die aus Acorn Computer
Limited entstand. Die ARM Limited ist so zusagen eine „Prozessorschmiede“. Sie
handelt eigentlich nur mit CPU-Lizenzen, „die einem ARM-Kunden das Recht einräumen,
ein IC mit einer integrierten ARM-CPU zu entwickeln, anzufertigen(oder anfertigen
zulassen) und zu verkaufen“ [WAL04].
2.1.2 Das Evaluationsboard MCB2140 von Keil
In dieser Thesis wurde auf dem MCB2140 Evaluation Board von KEIL der ARM Company
mit der ARM7TDMI-CPU LPC2148 von Philips gearbeitet.
Abbildung 2: Evaluation Board MCB2140
Der µController besitzt;
• die Philips LPC2148 16/32-Bit-CPU, basierend auf der ARM7TDMI-S-Familie mit
16-Bit langem Thumb-Mode (spezieller Befehlsatz) Unterstützung, 12 MHz
Quarzfrequenz, CPU-Frequenz bis zu 60 MHz,
• ein 32 KByte On-Chip static RAM, sowie 512 KByte On-Chip Flash-Speicher
(auch ROM oder Programmspeicher genannt), 128-Bit lange Speicheranbindung,
• bis zu 45 Ein-/Ausgabe Pins, 8 LEDs; zwei serielle Ports (UART), zwei Fast I²C-
Busse, sowie ein USB- und ein SD-Card-Interface,

2 Grundlagen 13
• zwei 10-Bit A/D-Wandler mit insgesamt 14 Kanälen und Konvertierungszeiten
von etwa 2,5µs pro Kanal,
• ein 10-Bit D/A-Wandler,
• zwei 32-Bit Timer/Counter, zwei PWM und ein Watchdog-Timer,
• Stromversorgung erfolgt via USB, 5V DC(Gleichstrom),
• ein JTAG-Interface.
Um den µController vom PC aus zu programmieren, sowie zu debuggen wird dieser
über ein JTAG-Interface an das Tantino Debug Tool angeschlossen. Das Tantino wird
über USB an den PC angeschlossen.
Abbildung 3: Tantino für ARM7-9
Dieses Debugger Tool unterstützt die schnelle Flash-Programmierung, schnelles Programmdownload
mit bis zu 180 KByte/s, sowie eine Ausführungskontrolle wie
Run/Stopp, schrittweise Ausführung, und die Möglichkeit Breakpoints und Watchpoints
zu setzen.
2.1.2.1 LPC2148 CPU-Core
Die Philips LPC2148 gehört zu der ARM7TDMI-Familie, deren Prozessoren übersichtlich
gestaltet sind. Sie benutzen relativ wenig Siliziumfläche und haben deswegen einen
geringen Stromverbrauch. Die Abbildung 4 zeigt die Blockschaltung des ARM7TDMI-
Cores:

2 Grundlagen 14
Abbildung 4: ARM7TDMI main processor logic [ARM7]
Die wichtigsten Funktionseinheiten sind [vgl. WAL04]:
• Adress Register:
Dieses enthält die Speicheradresse, auf die die CPU zugreifen soll
• Adress Incrementer: Diese Funktionseinheit inkrementiert die 32-Bit-Adresse.
Da aber der Speicher eine Byte-Struktur besitzt. Eine Adresse wird wie folgt inkrementiert:
neue Adresse = alte Adresse +4
• Register Bank: Die 32-Bit-Register sind hier zusammengefasst, was bei der Befehlsverarbeitung
eine große Rolle spielt.
• Multiplier:
Mit Hilfe festverdrahteter Logik führt dieser schnelle Multiplikationen durch.
• Barrel Shifter:
Spezielles Schieberegister, das eine Verschiebung um mehrere Bits ermöglicht.
• ALU: Arithmetical Logical Unit, das Rechenwerk.
• Write Data Register und Read Data Register: durch diese Register geschehen
Schreib- und Lesezugriffe auf Daten.
• Instuction Decoder/Control Logic: Decodierung sämtlicher Befehle und Steuerung
der Ausführung von Befehlen.
• Instruction Pipeline:
Hier wird die oben beschriebene eine 3-stufige Pipeline realisiert.

2 Grundlagen 15
Das genaue Funktionsprinzip kann aus Dokumentationen von der Webseite ARM Limited
(www.arm.com) entnommen werden.
Die gegebene CPU verfügt über eine 3-stufige Pipeline mit einer so genannten Loadand-Store
Architektur. Die Besonderheit dabei ist, dass alle zum Berechnen benötigten
Daten aus dem Speicher in Register kopiert (Load) und nach der Operation wieder in
den Speicher zurück geschrieben (Store) werden (Abbildung 5). Dies bringt eine Steigerung
der Performance mit sich, weil mit viel schnelleren Registern gearbeitet und deshalb
nicht jedes Mal auf den langsamen Speicher zugegriffen wird.
Register:
Abbildung 5:Load-and-Store Prinzip [MAR06]
Die ARM7TDMI-S CPU besitz eine Bank aus sechzehn 32-Bit langen Registers(Abbildung
6) und einem Current Program Status Register(CPSR) (Abbildung 7). Die
Register R0-R12 sind benutzerspezifische Register (User Register) und besitzen keine
speziellen Funktionen. Die R13-R15 hingegen sind so genannte Special Function Register
und haben bestimmte Funktionen zu erfüllen. Register R13 hat die Funktion des
Stack Pointers, R14 des Link Registers. In R14 wird die Rücksprungadresse
(siehe s. 20) gespeichert. R15 ist der Programmcounter.
Das Current Program Status Register(CPSR) erfüllt folgende Funktionen:
• In den Bits 28-31 des Registers stehen die Statusflags (Negative, Zero, Carry
und Overflow). Die Statusflags-Bits werden benutzt, um logische und arithmetische
Befehle unter bestimmten Bedienungen durchzuführen.
• Mit Hilfe von Bit 6 und 7 werden Interrupts 5 ein- oder ausgeschaltet.
• Mit Hilfe von Bits 0-4 wird zwischen den Benutzungsmodi umgeschaltet.
5 IRQ(Interrupt Request) sowie FIQ(Fast Interrupt Request)

2 Grundlagen 16
Benutzungsmodi:
Abbildung 6: Registerbank [MAR06]
Abbildung 7: Current Program Status Register ([LPC2148])
Die CPU hat sechs Benutzungsmodi, wie die Abbildung 8 zeigt. Im Normalfall laufen die
Anwendungen im „User“-Betrieb. Bei einem Ausnahmefall z. B. bei einem Interrupt,
wechselt der Prozessor in einen anderen Betriebsmodus über. In diesem Fall haben die
Register R0-R12 und R15 die gleichen Funktionen, die R13 und R14 werden hingegen
durch einzigartige Paare von Registern, die für jeden Modus verschieden sind, ausgetauscht.
Zudem kommt ein weiteres Register namens Saved Programm Status Register
(SPSR) zum Einsatz. In diesem wird der Wert des CPSR beim Wechsel gespeichert und
beim Zurückkehren in den „User“-Modus zurück geschrieben.
Das 5. Bit des CPSR’s symbolisiert in welchem Instruktionssatz sich der Prozessor gerade
befindet; im ARM- oder THUMB-Satz 6 . Der Unterschied dabei ist: der ARM-Satz ist
32-Bit lang und der THUMB 16-Bit lang. Außerdem werden im THUMB-Satz nicht alle
Register benutzt, wie es die Abbildung 9 zeigt, sondern nur R0-R7 der Benutzer-
Registern (so genante „untere Register“).
6 wird hier nicht weiter behandelt, kann aber im [umPhilips] nachgelesen werden

2 Grundlagen 17
Befehlsatz:
Abbildung 8: ARM Benutzungsmodi ([LPC2148])
Abbildung 9: Benutzung von Registern im THUMB-Satz([LPC2148])
Eine der interessantesten Besonderheit des ARM Instruktionssatzes ist, dass fast jeder
Befehl bedingt ausgeführt werden kann. Dies ist dadurch möglich, dass die Bits 28-31
des 32-Bit langen Befehls (Abbildung 10) für Bedienungspräfixe benutzt werden, wie
beim CPRS. Assemblerbefehle können mit 16 möglichen Bedienungspräfixen ergänzt
werden. Diese zeigt die Tabelle 1 (siehe s. 20).

2 Grundlagen 18
Zum Beispiel wird der Befehl:
EQMOV R1, #0x00080000
nur ausgeführt, falls das Ergebnis des vorherigen Befehls gleich war und das Z-Flag im
CPSR permanent gesetzt wurde.
Die ARM7TDMI-S CPU hat folgende sechs Gruppen von Befehlen:
• Sprung (Branching)
• Datenverarbeitung (Data Processing)
• Datentransfer (Data Transfer)
• Blocktransfer (Block Transfer)
• Multiplikation (Multiply)
• Software Interrupt
Im Weiteren werden diese Gruppen näher betrachtet.
Tabelle 1: Bedienungspräfixe [ARMREF]

2 Grundlagen 19
Sprung (Branching)
Abbildung 10: ARM-Instruktionssatz Formate [ARMREF]
Der ARM7 verfügt über weitere Sprungbefehle:
• B, BL Branch, Branch with Link
• BLX Branch with Link and Exchange
• BX Branch and Exchange
Der Standardsprungbefehl B – Branch, sowie BL, erlaubt es vorwärts oder rückwärts um
bis zu 32 MB weit zu springen, wobei BL – Branch with Link die Rücksprungadresse im
Link Register R14 speichert. Das Funktionsprinzip zeigt Abbildung 11:
Abbildung 11: Standartsprungbefehle [MAR06]

2 Grundlagen 20
BLX(Branch with Link Exchange) und BL(Branch Exchange) haben die gleiche Funktionalität
wie die B und BL, außerdem werden sie benutzt, um zwischen den ARM- und
THUMB-Instruktionssatzen zu wechseln (Abbildung 12).
Abbildung 12: Sprungbefehle BLX und BL [MAR06]
Datenverarbeitende Befehle (Data Processing Instructions)
Wie ein datenverarbeitender Befehl aussieht, zeigen die Abbildungen 13 und 14:
Abbildung 13: Data Processing Instruction [MAR06]
Abbildung 14: Data Processing Instruction [ARMREF]
Jeder Befehl hat zwei Operanden und schreibt das Ergebnis in ein Register. Der erste
Operand muss immer ein Register sein, der zweite hingegen ein Register oder eine Variable.
Als Zusatz gibt es einen Barrel Shifter, dieser erlaubt es, den zweiten Operanden
bitweise zu shiften. Das „S“-Bit wird benutzt um Statusflags zu kontrollieren. Die datenverarbeitenden
Befehle sind in der Tabelle 2 aufgelistet.
Zum Beispiel könnte folgende Anweisung:
if (z==1) R1 = R2 + (R3 * 4)

2 Grundlagen 21
so kompiliert werden:
EQADDS R1,R2,R3,LSL #2
Datentrasfer Befehle (Data Transfer)
Tabelle 2:Datenbearbeitende Befehle [ARMREF]
In den Tabellen 3 und 4 aufgelistete Befehle erlauben es signed und unsigned Words,
Half Words und Bytes in (Load) Registern von dem Speicher zu schreiben und von (Store)
Registern in den Speicher zu schreiben:
Tabelle 3: Load- Befehle [ARM7]

2 Grundlagen 22
Tabelle 4:Store- Befehle [ARM7]
Wie aus den Tabellen zu ersehen ist, existiert nicht nur die Möglichkeit Daten
zwischen einzelnen, sondern zwischen mehreren Registern zu bewegen, was
Abbildung 15 zeigt:
Abbildung 15: Bewegung von Daten zwischen mehreren Registern[MAR06]
Multiplikation (Multiply)
Zusätzlich zu einem Barrel Shifter besitzt die ARM7TDMI-S-CPU eine Multiply Accumulate
Unit (MAC), diese wird für die Multiplikation von Integer und Long Integer benutzt.
Bei einer Integer-Multiplikation werden zwei 32-Bit lange Integer-Zahlen multipliziert und
das Ergebnis in ein 32-Bit-langes Register geschrieben (modulo 32). Bei einer Long Integer-Multiplikation
werden zwei 32-Bit lange Integer-Zahlen multipliziert und das 64-Bitlange
Ergebnis in zwei 32-Bit lange Register geschrieben. MAC-Befehle sind folgende:
Mnemonik Bedeutung Resolution
MUL Multiply 32 Bit Resultat
MULA Multiply accumulate 32 Bit Resultat
UMULL Unsigned multiply 64 Bit Resultat
UMLAL Unsigned multiply accumulate 64 Bit Resultat
SMULL Signed multiply 64 Bit Resultat
SMLAL Signed multiply accumulate 64 Bit Resultat
Tabelle 5: Die Multiplikationsbefehle

2 Grundlagen 23
2.1.2.2 Speicher
Weil der µController eine 32-Bit-CPU besitzt, verfügt der µController über einen 2³² = 4,0
Gigabyte großen Adressraum, den die Abbildung 16 zeigt.
Abbildung 16: LPC2148 Memory Map [LPC2148]
Zur Verfügung stehen dem µController die Bereiche:
• 0x0000 0000 – 0x0007 FFFF = 512 KB für den ROM / Programmspeicher
• 0x4000 0000 – 0x4000 7FFF = 32 KB für den SRAM / Arbeitspeicher
2.2 Entwicklungsumgebung HITOP 5.2
Zum Entwickeln von Programmen für das Board LPC2148 wurde die Entwicklungsumgebung
HITOP 5.2 von Hitex eingesetzt. Diese integrierte Entwicklungsumgebung
(DIE) nutzt den GCC-Compiler für die Programmiersprache C und bietet dem Entwickler
alle benötigten Funktionen, wie zum Beispiel: Kompilieren von Programmen und

2 Grundlagen 24
übersichtliches Editorfenster. Über diese IDE geschieht das Downloaden von Programmen
in den Flash-Speicher von µControllers. Außerdem werden verschiedene
Funktionen zum Debuggen zur Verfügung gestellt, solche wie die schrittweise Ausführung
eines Programms und die Möglichkeit die Breakpoints zu setzen. Es existieren
auch Fenster mit Register-, und Speicherinhalten. Außerdem besteht die Möglichkeit
verschiedene Variable zu verändern. Nähere Informationen befinden sich im
Anhang B.
Abbildung 17: Entwicklungsumgebung HITOP 5.2
2.3 Anforderungen an sicherheitsgerichtete Systeme
Ein System oder eine Maschine, die elektronisch gesteuert wird, soll als sicherheitskritisch
bezeichnet werden, wenn von diesem oder dieser für Menschen und/oder Umwelt
Gefahr ausgeht oder es im Falle eines Unfalls zu einem Schaden kommen kann. Ist das
der Fall, muss geklärt werden was, wann und wie es gefährlich für einen Menschen oder
die Umwelt werden kann. Die wichtigsten Kriterien hierbei sind Häufigkeit und Wahrscheinlichkeit
des Auftretens des Schadens. Nach diesen Kriterien wird dann einem System
eine Risikokategorie zugeordnet. Hierbei werden so genannte Risikographen genutzt
z.B. die Risikographen aus den Normen EN 954-1 (Abbildung 18) oder IEC 61508
(Safety Integrity Level, SIL).

2 Grundlagen 25
Abbildung 18: Risikograph(EN 954-1)[GEH07]
Nach erfolgter Gefährdungsanalyse wird für jede Gefährdung mit diesem Risikographen
eine Risikoanalyse durchgeführt, um die erforderliche Risikoreduzierung zu bestimmen.
Je nach dem in welche Kategorie ein System zugeordnet wird, müssen unterschiedliche
Maßnahmen der Risikoreduzierung ergriffen werden, um den Anforderungen an diese
Kategorie zu genügen. Die Maßnahmen können technischen und nicht technischen Charakter
tragen. Je höher der Schaden, der infolge eines Fehler und/oder Ausfalls des Systems
entstehen kann, und je höher die Kategorie des Systems, desto höher das Maß der
zu ergreifenden Risikoreduzierung [BÖR04].
Die Normen EN 954 „Sicherheit von Maschinen - Sicherheitsbezogene Teile von Steuerungen“
sowie IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar
elektronischer Systeme (E/E/PES)“ sind sehr wichtig
bei dem Entwurf, der Konzipierung sowie der Entwicklung von sicherheitskritischen
E/E/PES, da diese Normen grundlegende Informationen und Empfehlungen für die Arbeit
mit E/E/PES enthalten.
2.4 Fehler
Um Fehler aufzudecken und behandeln zu können, muss verstanden werden, was eigentlich
ein Fehler ist. In der Norm DIN 40041 wird ein Fehler wie folgt definiert:
„Ein Fehler ist die Nichterfüllung vorgegebener Forderungen durch einen Merkmalswert.
Ein Fehler ist also ein Zustand (z.B. auch ein falscher logischer Zustand)“
Man kann Fehler allgemein in zwei Kategorien aufteilen[vgl. BÖR04]:
• Physikalische Fehler (z.B. Hardwareausfall)
• Funktionale Fehler (z.B. Softwareausfall)
Aus Abbildung 19 ist zu sehen, dass Ausfälle einer Steuerung infolge eines Fehlers fast
in allen „Lebensphasen“ eines Systems auftreten können.

2 Grundlagen 26
Abbildung 19: Steuerungsversagen nach „Lebensphasen“ [330219]
Die Ursachen für diese Ausfälle, betrachtet unter zeitlichem Aspekt, können entweder
vor oder nach der Inbetriebnahme liegen. Als Beispiele können weitere Auflistungen
dienen (nach [ISSA02]:
vor der Inbetriebnahme:
• Spezifikationsfehler
• Dimensionierungsfehler
• Programmierfehler
nach der Inbetriebnahme:
• Fehler im Speicher
• Fehler in der CPU
• Fehler in der Peripherie
Gegen Fehler vor der Inbetriebnahme sollen die Maßnamen zur Fehlervermeidung ergriffen
werden. Diese werden von Herstellen und Entwicklern durchgeführt. Gegen die
Fehler nach der Inbetriebnahme sind die Maßnahmen der Fehlerbeherrschung anzuwenden.
Gegenstand dieser Thesis ist die Fehlerbeherrschung, dabei fangen bestimmte
Hard- und/oder Softwarebausteine Fehler während des Betriebs auf. Maßnahmen zur
Fehlervermeidung können sein: Verwendung von Case-Tools, strukturierter Entwurf,
Programmanalyse; zur Fehlerbeherrschung: redundante Soft- und Hardware, Speicher-,
CPU- und E/A-Tests(vgl. [ISSA02]).
Dass Software häufig fehlerhaft ist, ist bekannt, aber es muss auch erwähnt werden:
keine Hardwarekomponente ist immer fehlerfrei. Sie kann entweder schon nach der
Herstellung defekt sein oder es können Defekte während des nicht ordnungsgemäßen
Betriebes auftreten oder infolge von Alterung. Jedes „Leben“ einer Hardwarekomponente
lässt sich mit Weibull-Verteilung, auch „Badewannekurve“ genannt,
(Abbildung 20) beschreiben:

2 Grundlagen 27
Abbildung 20: „Badewannekurve“
Der Bereich Nummer 2, also normaler Betrieb macht etwa 80% der Produktlebenszeit
aus. Diese Abbildung ist wie folgt zu verstehen: Nach vielen Anfangsfehlern („Kinderkrankheiten“)
folgt ein relativ zuverlässiger normaler Betrieb. Nach einer bestimmten
Zeit, spezifisch für jede Komponente, häufen sich die Fehler infolge des Alterungsprozesses.
Da ein zufälliger Fehler immer auftreten kann, müssen bei einem System, das
sicherheitskritische Aufgaben ausführt, Hardwarekomponenten überprüft werden. Diese
Prüfung oder auch Test sollte vor Inbetriebnahme, sowie während des Betriebes durchgeführt
werden.
2.5 Tests und Testverfahren
Für ein System, das sicherheitskritische Aufgaben ausführt, sind Tests von großer Bedeutung.
Aus diesem Anlass wurde versucht, ein allgemeines Prinzip der Fehleraufdeckung
oder auch Tests zu formulieren (nach [HAL99]):
„In einem beliebigen Verfahren zur Erkennung von Fehlern werden mindestens zwei
Werte auf Erfüllung der zwischen diesen Werten vorgegebenen Zusammenhänge
geprüft. Unzulässige Abweichungen von diesen Zusammenhängen werden als Fehler
interpretiert.“
Das allgemeine Prinzip zeigt die Abbildung 21. Die erhaltenen Werte x1, x2,…,xn, die
durch die Verarbeitung der Einheiten E1,E2,…,En der Eingangswerte y1,y2,…,yn ermittelt
wurden, werden von der Prüfeinheit auf den vorgegeben Zusammenhang geprüft.
Falls der Zusammenhang nicht vorhanden ist, wird ein Fehler gemeldet.

2 Grundlagen 28
Abbildung 21: Das allgemeine Fehlererkennungsprinzip[HAL99]
Zwei Modifikationen dieses Prinzips sind die Plausibilitätsprüfung und der Vergleich. Bei
der Plausibilitätsprüfung werden Werte auf Erfüllung des vorgegeben Zusammenhangs
geprüft 7 . Bei einem Vergleich werden die Prüfwerte auf ihre Gleichheit geprüft 8 .
2.5.1 CPU-Tests
Eine CPU ist das Rechenwerk des µControllers; funktioniert es nicht richtig, ist die korrekte
Funktion des sicherheitsgerichteten Systems unmöglich. Zudem ist es auch nicht
möglich andere Selbsttests durchzuführen. CPU-Tests basieren auf dem Vergleichsprinzip
der Fehleraufdeckung. Der Grundgedanke bei einem CPU-Test ist es: eine Operation
mit vorgegebenen Testvariablen durchzuführen und dann Ist- mit Soll-Werten zu vergleichen.
Wird eine Abweichung festgestellt, so wird auf dieses Ereignis in vordefinierter
Weise reagiert, sei es eine Fehlermeldung oder eine steuerungstechnische Reaktion.
Bei einem CPU-Test werden alle Befehle der CPU getestet. Diese können in folgende
Gruppen aufgeteilt werden: arithmetische(z.B. ADD), logische(z.B. AND), Transferbefehle(z.B.
MOV) sowie die Sprungbefehle.
Die Arithmetikbefehle wie Addition oder Multiplikation sollen deswegen geprüft werden,
da sie Berechnungen z. B. von neuen Koordinaten eines Roboterarms, der einem Menschen
einen Gegenstand überreicht, benutzt werden.
Die logischen Befehle müssen deswegen geprüft werden, da mit ihrer Hilfe meist Vergleiche
durchgeführt werden. Funktionieren diese nicht richtig, kann eine falsche Entscheidung
getroffen werden.
Die Transferbefehle werden benutzt um Daten von und zum Speicher, sowie Registern
zu bewegen. Funktionieren diese nicht richtig, werden trotz korrekter Funktion der restlichen
Befehle falsche Ergebnisse erzielt. Dies kann natürlich zum Verlust der Sicherheitsfunktion
führen.
Die bedingten sowie unbedingten Sprünge werden z.B. in Schleifen oder als die Unterprogrammaufrufe
benutzt. Die fehlerhafte Funktion bei einer Schleife kann zu einer endlosen
Schleife führen. Bei einem Unterprogrammsprung kommt hinzu, dass überhaupt
kein Sprung stattfinden kann. Diese Fehler werden durch den WD abgefangen.
7
z.B. wächst der Eingangswert, so soll auch der Ausgangswert wachsen
8
z.B. ein Operationsergebnis wird mit dem Sollergebnis verglichen

2 Grundlagen 29
2.5.2 RAM/ROM-Fehler
In diesem Kapitel werden die Fehler behandelt, die bei einen RAM auftreten können. Ein
fehlerfreier RAM-Speicherbaustein soll in etwa wie folgt funktionieren:
Abbildung 22: Zustandgraph eines fehlerfreien Speicherbausteins[RED98]
„S0/1“ bedeutet eine Zelle mit dem Wert „0/1“, „w0/1“ ist der Übergang von „0-1/1-0“.
Also muss eine Zelle ihren Zustand von „S0“(Zelleninhalt „0“) beim Übergang „w1“ in den
Zustand „S1“(Zelleninhalt „1“) ändern und umgekehrt. Beim Übergang „w0“ aus dem
Zustand „S0“ bleibt die Zelle in diesem Zustand, ebenfalls bleibt „S1“ beim Übergang
„w1“ in diesem Zustand.
In der Tabelle 6[HAM99] sind wesentliche funktionale Fehler eines RAMs aufgelistet.
Diese Fehler können entweder einfache Fehler sein („Stack-at“), oder auch eine Menge
an Fehlern, die unter einem Begriff aufgefasst werden („Adress Decoder Fault“).
Tabelle 6: Funktionale Fehler eines RAMs [HAM99]
Im Folgenden werden Fehlermodelle für das RAM vorgestellt.
Der einfachste Fehler ist ein Haftfehler (Stuck-at Fehler, SAF). Ein Übergang von einem
logischen Wert zu einem anderen ist unmöglich (die Zelle bleibt so zu sagen an einem
Wert „haften“).

2 Grundlagen 30
Abbildung 23: Zustandgraph eines SA0[RED98]
Abbildung 24: Zustandgraph eines SA1[RED98]
Ein weiterer Fehler ist ein Übergangsfehler (Transition Fault, TF). Eine Speicherzelle
kann ihren Wert nicht von 0 nach 1 wechseln oder umgekehrt. Es gibt zwei Arten
dieses Fehlers: 1.) Transition-Up-Fault (von „0“ nach „1“); 2.) Transition-Down-Fault(von
„1“ nach „0“). Abbildung 26 zeigt ein Transition-Up-Fault:
Abbildung 25: Zustandgraph eines Transition-Up-Faults[RED98]
Der Koppelfehler (Coupling Fault, CF): Inhalt einer Zelle hängt von den Inhalten in anderen
Zellen ab. Es gibt zwei Varianten dieses Fehlers: 1.) 2-Coupling Fault: zwei Zellen
beeinflussen einander; 2.) k-Coupling-Fault: k-2 Zellen beeinflussen den Inhalt einer
Zelle. Außerdem existieren verschiedene Möglichkeiten wie eine Zelle beeinflusst werden
kann 9 , z.B. wie Inversion Coupling Fault, Idempotent Coupling Fault, State Coupling
Fault und Bridging Fault.
Der Musterabhängige Fehler (Pattern Sensitive Fault, PSF): der Inhalt einer Zelle wird
von anderen Zellen bestimmt. Es ist ein Sonderfall des k-Coupling-Fault, alle k-Zellen
bestimmen den Übergang. In der Literatur wird die Betrachtung dieses Fehlers auf
„Nachbarschaft“ „reduziert“. In diesem Fall spricht man von Neighborhood Pattern Sensitive
Fault (NPSF). Es sind drei verschiedene Varianten von diesen Fehlern definiert
[RED98]: 1.) Active Neighborhood Pattern Sensitive Fault; 2.) Passive Neighborhood
Pattern Sensitive Fault; 3.) Static Neighborhood Pattern Sensitive Fault 10 .
Der Adressdekodierfehler (Adress Decoder Fault, AF): es gibt vier verschiedene Adressdekodierfehler
[RED98]:
9 hier nicht weiter betrachtet, weiter führende Informationen in [RED98]
10 hier nicht weiter betrachtet, weiter führende Informationen in [RED98]

2 Grundlagen 31
1. Adresse zeigt auf keine Speicherzelle
2. für eine Speicherzelle existiert keine Adresse
3. an eine Adresse sind mehrere Speicherzellen gebunden
4. mehrere Adressen sind an dieselbe Speicherzelle gebunden
Die Tabelle 6[HAM99] zeigt den Zusammenhang der Fehlermodellen und der funktionalen
Fehler eines RAMs:
Tabelle 7: Zusammenhang der Fehlermodelle und funktionaler Fehler [HAM99]
2.5.3 RAM- und ROM-Testverfahren
Das RAM ist der Arbeitspeicher, in dem zur Laufzeit benötigte Daten gespeichert werden.
Existiert ein Fehler im RAM so kann es zu einer Verfälschung der Daten kommen,
was zu verheerenden Folgen führen kann.
Es gibt verschiedene Möglichkeiten Fehler im RAM aufzudecken. In dieser Thesis werden
deterministische Testverfahren behandelt, da sich für diese Tests leichter Aussagen
über den Fehlerabdeckungsgrad treffen lassen. Nach [RED98] erreicht ein deterministischer
Test, „von einem speziellen Fehler eines Fehlermodels ausgehend, eine Fehlerabdeckung
von 100%. Alle erkennbaren Fehler werden detektiert.“ In dieser Thesis werden
folgende Testalgorithmen betrachtet: March X Algorithmus 11 und transparenter Speichertest.
11 da es in der vorhandenen Bibliothek schon implementiert wurde

2 Grundlagen 32
March X Algorithmus: Dieser Test ist ein Vertreter der March-Tests, von denen mehrere
existieren. Mit Hilfe dieses Testes werden alle Haftfehler, alle Übergangsfehler, alle
Adressdecodierfehler und eine bestimmte Art von Koppelfehlern (Idempotent Coupling
Fault) entdeckt. Die Komplexität aller March-Tests ist O(n), deswegen sind diese Tests
sehr verbreitet bei SRAM-Tests [RED98]. Der March X Test wurde von [HAM99] entwickelt
und sieht in Pseudo-Code folgendermaßen aus:
Funktionsweise dieses Testes:
1.) Gesamten Speicher mit „0“ beschreiben;
for i in 0 to n-1 do
A[i] := 0;
end
for i in 0 to n-1 do
read A[i];
compare (A[i],0);
Branch FAULT if not equal;
A[i] := 1;
end
for i in n-1 to 0 do
read A[i];
comp (A[i],1);
Branch FAULT if not equal;
A[i] := 0;
end
for i in 0 to n-1 do
read A[i];
comp (A[i],0);
Branch FAULT if not equal;
end
2.) jede Speicherzelle lesen und mit „0“ vergleichen, wenn ungleich -> Fehler, ansonsten
Speicherzelle invertieren;
3.) jede Speicherzelle lesen und mit „1“ vergleichen, wenn ungleich -> Fehler, ansonsten
Speicherzelle invertieren;
4.) Schritt 2 wiederholen.
Transparenter Speichertest: Dieser Test wurde vom BGIA entwickelt. Mit Hilfe dieses
Testes werden alle Fehler aus der Tabelle 6 in einem RAM entdeckt. Das hat aber
seinen Preis, der Test benötigt sehr viel Ausführungszeit. Der transparente Speichertest
benutzt eine CRC-Prüfung(Cyclic-Redundancy-Check). Die Grundidee zur CRC Bildung
ist eine Polynomdivision durch ein spezielles Generatorpolynom, der Rest dieser Division
ist die Signatur.

2 Grundlagen 33
Die Division sieht folgendermaßen aus:
1. z.B. die binäre Zahl 1011 wird in Polynomform umgewandelt, also
1*x 3 + 0*x 2 + 1*x 1 + 1*x 0 = x 3 + x 1 + x 0
2. Das Generatorpolynom sei: x 2 + x 1
3. x 3 + x 1 + x 0 : x 2 + x 1 = x 1 - 1
- (x 3 + x 2 )
-x 2 + x 1 + x 0
2 1
-( -x - x )
x 0
4. Rest ist x 0 -> ist die Signatur 01
Die Funktionsweise des transparenten Speichertests[SCH97]:
1.) Speicher wird in Segmente gleicher Größe eingeteilt (mind. 2 Byte);
2.) es wird ein Testwort, Mindestlänge 1 Byte, genommen;
3.) Über das Segment, in dem sich das Testwort befindet, wird eine Signatur gebildet
(CRC-Prüfung), jedoch ohne des Testworts selbst, und eine für alle andere
Segmente;
4.) Das Testwort wird invertiert und es werden wieder Signaturen gebildet;
5.) Die gebildeten Signaturen werden verglichen, bei Gleichheit wird das Testwort
wieder invertiert und die Signaturen gebildet, ansonsten wird ein Fehler gemeldet;
6.) Das Testwort selbst prüfen mit Hilfe des „Walking Bit“-Verfahrens: Inhalt des
Wortes sichern, in alle Bits des Wortes „0“ schreiben, in das niederwertigste Bit
„1“ schreiben und vergleichen, dann „1“ in das nächste Bit „schreiben“, bis das
Wort wieder gleich Null ist. Am Ende des Tests das Testwort wiederherstellen.
7.) Falls alles erfolgreich, Testwort um Länge des Worts verschieben und mit 3.)
weiter bis Speicherende erreicht ist.
Die Abbildung 26 [SCH97] zeigt das Funktionsprinzip des transparenten Speichertests.
ROM-Testverfahren: ROM ist die Abkürzung für Read Only Memory, das heißt, dass in
diesem Speicher das eigentliche Programm dauerhaft gespeichert und von hier ausgeführt
wird. Während des Betriebs wird nichts in diesen Speicher geschrieben. Daraus
folgt die Erkenntnis: der ROM-Inhalt muss immer gleich sein. Wenn vor Inbetriebnahme
über das gesamte ROM eine Signatur gebildet worden ist, muss diese immer mit der
neu gebildeten Signatur gleich bleiben, ansonsten ist ein Fehler im ROM aufgetreten.

2 Grundlagen 34
Abbildung 26: Funktionsweise eines transparenten Speichertests
2.5.4 Ein-/Ausgabe Test
Funktionieren bei einem µController Eingabeports sowie analoge Eingänge nicht
richtig, so kann er seine Umgebung nicht richtig wahrnehmen. Funktionieren die Ausgabeports
sowie analoge Ausgänge nicht richtig, dann kann ein µController seine Peripherie
nicht mehr angemessen ansteuern.
Bei Ein-/Ausgabe-Tests muss nicht nur softwaremäßig, sondern auch hardwaremäßig
getestet werden. Das heißt, dass erstens eine Routine zum Testen implementiert werden
soll und zweitens die digitalen Ports aufgeteilt werden: eine Hälfte dient zuerst als
Ausgang und die zweite als Eingang. Die beiden Hälften werden mit einander fest verdrahtet.
Über die Ausgangsports wird eine Eins „geschoben“ und an den Eingansports
geprüft, ob die Ports gesetzt konnten oder nicht.
Fehler, die bei einem Analog-Digital-Wandler auftreten können, werden in statische und
dynamische unterteilt. Zu den statischen Fehlern gehören z.B. der Quantisierungsfehler,
integrale und differenzielle Nichtlinearität, zu den dynamischen z.B. die Verletzung des
Abtasttheorems und dynamische Nichtlinearitäte. Weil diese Fehler sehr komplex sein
können und jeweils geeignete Test um die Fehler aufzudecken und Maßnahmen die
diese Fehler kompensieren benötigt werden, wurde die Entscheidung getroffen den Analog-Digital-Wandler
auf seine plausible Funktionalität zu prüfen. Diese Entscheidung
wurde im Wesentlichen durch folgende Erkenntnis beeinflusst: zum Testen des Wandlers
stehen weniger als 50ms zu Verfügung und in dieser Zeit muss er auf seine korrekte
Funktionalität geprüft werden. In dieser kurzen Zeit werden nicht die Typen der Fehler
festgestellt, sondern das Vorhandensein eines Fehlers, was eigentlich das Ziel eines
Selbsttests ist.

2 Grundlagen 35
Bei den Tests von Analog-Digital (A/D)- und Digital-Analog (D/A)-Wandlern werden die
beiden hardwaremäßig verbunden. Es wird die plausible Fehlererkennungsmethode
angewendet. Die Grundidee: wird Wert am D/A erhöht, so muss sich auch eingelesener
Wert am A/D erhöhen.

3 Anforderungsanalyse und –definition 36
3 Anforderungsanalyse und –definition
Die Anforderungsanalyse wird mit Hilfe der Erstellung eines Pflichtenheftes, dessen
Struktur auf der Struktur eines Pflichtenheftes für die Fallstudie „Teach-Roboter“ von
[BAL96] basiert, durchgeführt.
3.1 Zielbestimmung
Die Bibliothek soll dem Nutzer einen vollständigen Testsatz zur Verfügung stellen, der
grundlegende Tests der Sicherheitstechnik für die µControllern der Philips LPC21xx
Familie enthält.
3.1.1 Musskriterien
• Watchdog-Test: in der Bibliothek soll ein Watchdog-Test vorhanden sein
• Register-Test: in der Bibliothek soll ein Test, der anhand des „Walking Bit“ Verfahrens
die Register des CPU testet, vorhanden sein
• CPU-Test: ebenfalls soll eine Funktion enthalten sein, die es ermöglicht logische,
arithmetische, Transfer- sowie restliche Befehle der CPU zu testen
• RAM-Test: die Bibliothek soll solch eine Funktion zur Verfügung stellen, die das
RAM des µControllers mit einer der in dem Grundlagenkapitel genannten Methoden
testet und folgende Fehler entdeckt:
o beide Arten von Haftfehler
o beide Arten von Übergangsfehlern
o Koppelfehler
o musterabhängige Fehler
o Adressdekodierfehler
• ROM-Test: Die Bibliothek soll einen ROM-Test durchführen können, der den
Speicher mit Hilfe der CRC-Bildung prüft
• Ein-/Ausgabe-Test: Mit Hilfe der Bibliothek soll ermöglicht werden Ports, sowie
A/D und D/A-Wandler des µControllers zu testen
• Timer-Test: Es soll eine Routine vorhanden sein, die den Timer von dem Evaluation
Board auf seine korrekte Funktion testet.
3.1.2 Kannkriterien
Optional kann die Bibliothek weitere Funktionen enthalten, die;
• den USB (Universal Serial Bus) testen

3 Anforderungsanalyse und –definition 37
• den PWM (Pulse Width Modulator),
• die Zeitscheibenverfahren realisieren.
3.1.3 Abgrenzungskriterien
• Keine Laufzeitstacküberprüfung: Es wird keine Funktion implementiert, die
Laufzeitstack überprüft,
• Keine weiterführende Tests: Es werden keine andere als obengenanten Tests
implementiert.
3.2 Bibliothekseinsatz
Die Bibliothek ist als ein Prototyp gedacht und kann als Basis für eine Weiterentwicklung
genommen werden, sowie als Lehrmaterial für Studierende des Schwerpunktes
„Embedded Systems“ des Fachbereichs Informatik der Fachhochschule
Bonn-Rhein-Sieg.
3.2.1 Anwendungsbereiche
Entwickelnde und forschende Labore des Fachbereichs Informatik der Fachhochschule
Bonn-Rhein-Sieg, sowie andere Personen oder Firmen, die Interesse an der Bibliothek
haben.
3.2.2 Zielgruppen
Zielgruppe sind in erster Linie Entwickler, die sich mit der Problematik sicherheitskritischer
Systeme befassen, sowie die Studierenden der Informatik an der Fachhochschule
Bonn-Rhein-Sieg.
3.3 Bibliotheksfunktionen
Die entworfene Bibliothek soll folgende Funktionen bieten:
• Testen des Watchdog Timers
• Testen der für den Benutzer verfügbaren internen Register der CPU
• Testen der CPU des µControllers
• Testen des RAM, wobei der zum Testen freiverfügbare Bereich des RAM in der
Funktion festgelegt werden kann, sowie weitere Parameter wie
Sektorgröße und Adresse des Prüfwortes
• Testen des ROM
• Testen von Ein-/Ausgabe Ports

3 Anforderungsanalyse und –definition 38
• Testen der A/D- und D/A-Wandlers
• Testen des Timers/Counters
3.4 Bibliotheksleistungen
90% Fehleraufdeckung bei allen Tests, falls die Hardware fehlerhaft ist.
3.5 Technische Bibliotheksumgebung
3.5.1 Software
Um den µController von dem Computer aus zu programmieren, werden weitere Softwarekomponenten
benötigt:
• Windows XP, zum Ausführen der Entwicklungsumgebung HITOP 5.2
• C-Compiler, bevorzugt GNU C Compiler for ARM
• Assembler, bevorzugt arm-hitex-elf-as zum Assemblieren der Assembler
Dateien
• Linker, bevorzugt arm-hitex-elf-ld zum Linken der assemblierten Dateien
• Downloadtool, zum Downloaden der Tests auf den Ziel-µController
3.5.2 Hardware
Zum Erstellen und Bearbeitung der Bibliothek wird weitere Hardware benötigt:
• PC zum erstellen der Bibliothek. Minimale Systemanforderungen:
o 1,0 GHz CPU oder schneller
o 256 MB Arbeitspeicher oder mehr
o 600 MB frei verfügbarer Platz auf der Festplatte
• Debugger, bevorzugt Tantino zum Debuggen der Bibliothek
• µController MCB2140 von Keil

4 Konzept und Implementierung 39
4 Konzept und Implementierung
In diesem Kapitel werden die Tests konzipiert und anschließend implementiert. Konzipiert
wird anhand der in dem Kapitel Grundlagen vorgestellten Verfahren. Implementiert
wird in der IDE HiTOP52 in der Programmiersprache C sowie in der Assemblersprache.
4.1 Software
Die Bibliothek ist modular aufgebaut, dadurch lässt sich jedes einzelne Modul viel leichter
und schneller testen. Die Änderungen eines einzelnen Moduls sind viel leichter nachvollziehbar.
Die Bibliothek lässt sich somit gut erweitern. Es besteht außerdem die Möglichkeit
neue Tests hinzuzufügen.
4.1.1 Programmablauf
Bevor ein System, das sicherheitsgerichtete Aufgaben erbringt, in Betrieb genommen
wird, soll zuerst sichergestellt werden, dass das System hinreichend fehlerfrei ist. Aus
dieser Tatsache wird zuerst ein Anlauftest durchgeführt. Bei diesem Test werden alle zu
testende Einheiten auf ihre korrekte Funktionalität geprüft. Da es sehr wichtig ist, dass
die Sicherheit – so zu sagen – „Stück für Stück“ erreicht wird, werden zuerst die Komponenten
getestet, ohne die die Durchführung von Tests gefährdet würde. Der Ablauf des
Anlauftests ist folgender:
1. Es werden die Sprung-Befehle der CPU getestet.
2. Es wird ein Watchdog-Test ausgeführt.
3. Es werden die internen Register getestet.
4. Es werden weitere CPU-Befehle überprüft.
5. ROM-Test.
6. Timer-Test.
7. I/O-Test.
8. RAM-Test.
Der Hintergrund dieser Reihenfolge ist folgender:
• Sprung-Befehle werden bei dem WD benutzt, deswegen sollen diese vor dem
WD-Test auf ihre korrekte Funktionalität überprüft werden.
• Watchdog überprüft ob die CPU ihre Arbeit in einer bestimmten Zeit ausführen
kann. So kann z.B. der Watchdog ein Programm aus einer Endlosschleife, so zu
sagen, „herausholen“, in dem er den µController „resetet“.

4 Konzept und Implementierung 40
• Die internen Register werden für die Zwischenspeicherung der Daten für Berechnungen
in der CPU benötigt. Funktionieren diese nicht, z. B. existiert ein
Haftfehler, dann würde auch eine fehlerfreie CPU falsche Resultate liefern.
• Bei einer fehlerhaften CPU werden die Programme einfach falsch ausgeführt,
was eine große Gefährdung mit sich bringt.
• Im ROM werden Programme gespeichert, die von dem µController ausgeführt
werden. Sind richtige Programme falsch eingespeichert, wird das richtige Programm
falsch ausgeführt.
• Der Timer wird benötigt um das Zeitscheibenverfahren zu realisieren. Funktioniert
der Timer nicht richtig, so werden die Zeitscheiben falsch eingeteilt, was unvorhersehbare
Auswirkungen als Folge haben kann.
• Funktionieren die Eingänge oder Ausgänge eines µControllers nicht richtig und
sind an diese Sensoren und Aktuatoren angeschlossen, kann der µController die
Umgebung nicht richtig wahrnehmen, sowie seine Aufgabe nicht richtig ausführen,
z.B. Bewegen eines Roboterarms.
• Im RAM werden Daten, die für die Berechnung nicht gerade benötigt werden
zwischengespeichert. Existiert ein Fehler im RAM werden anschließend für die
Berechnung verfälschte Daten zurückgeliefert. Der RAM-Test wird als letzter gestartet,
weil er am meisten Zeit braucht und in Zeitscheiben ausgeführt wird.
Sind die Tests erfolgreich verlaufen, kann der µController „freigegeben“ werden. Im Betrieb
wird ein Hintergrundtest ausgeführt. Die Besonderheit dabei ist, dass nur CPU-,
Register-, Watchdog- und I/O-Tests vollständig ausgeführt werden, da diese schnell genug
sind. RAM- und ROM-Test sind hingegen rechnerisch mit großem Aufwand verbunden
und würden somit die Sicherheitsfunktion des µControllers gefährden, falls sie am
Stück ausgeführt wurden. Deswegen werden die Speichertests in Zeitscheiben ausgeführt,
was aber ihre Wirksamkeit nicht mindert.
4.1.2 Watchdog-Test
Konzept
Als Ausgangsposition für die Entwicklung des Watchdog(WD)-Tests wurde das Verfahren
des BGIA [SCH97] genommen. Der Test ist wie folgt definiert [vgl. DEMER]:
1. Eine Variable wird eingerichtet ( im Programm „getestet“).
2. WD wird initialisiert und gesetzt.
3. Es wird eine Funktion definiert, die länger dauert als der WD (im Programm
„wait_5ms“).
4. Kurz vor dem Eingreifen des WD wird die Variable invertiert („getestet=1“)
und nach dem Eingreifen wieder invertiert („getestet=0“).

4 Konzept und Implementierung 41
5. Das Programm geht in eine Endlosschleife, falls die Variable nicht geändert
wurde.
Diesem Konzept entsprechend wird der WD-Test auch implementiert. Den Ablauf des
WD-Tests zeigt die Abbildung 27:
4.1.3 Register-Test
Konzept
Abbildung 27: Ablauf des WD-Tests
Zum Testen der Register wird eine „laufende“ Eins verwendet auch Walking Bit genannt.
Hierbei werden alle Bits eines Registers mit „0“ beschrieben und dann beginnend mit
dem Bit 0 und bis zum 32-ten Bit eine „1“ „geschoben“. Abbildung 28 zeigt das Funktionsprinzip:
Abbildung 28: Walking Bit

4 Konzept und Implementierung 42
Es könnten auch bestimmte Zahlenmuster in die Register geschrieben werden. Üblich
sind die Zahlen 0x55555555 12 und 0xAAAAAAAA, dies entspricht binär wechselnden
Nullen und Einsen, also „010101..01“ und „101010…10“. Mit diesen Mustern werden
zwar alle Haftfehler und Übergangsfehler 13 entdeckt, aber nicht alle Koppelfehler 14 . Der
Vorteil dieses Verfahrens ist die kürzere Zeit, die zum Testen gebraucht wird.
Implementation
Die CPU des Philips LPC2148 besitzt 16 32 Bit lange Register R0-R15. Wie diese verteilt
sind zeigt die Abbildung 8 auf Seite 17.
Die Register R0-R12 besitzen keine speziellen Funktionen und können problemlos im so
genanntem „User mode“[ARM7] getestet werden. Die Register R13-R15 sind Special
Function Register. Der R13 ist der Stack Pointer und der R14 werden auch getestet.
Dies ist möglich, weil beim Ausführen eines Unterprogramms diese nicht benutzt werden,
sondern erst beim Zurückkehren in das Aufrufprogramm. Dies gibt die Möglichkeit
die Inhalte des R13 und des R14 zu sichern und den Walking-Bit Pattern auf diese Register
anzuwenden. Weil das R15 eine hoch dynamische Funktionseinheit ist, ist das
Testen mit sehr großem Aufwand verbunden. Aus diesem Grund wird das R15 nicht
getestet, aber ein inkorrekt funktionierender Programmzähler wird von dem WD aufgedeckt.
Damit das Testen so schnell wie möglich geschieht, wurde die Testmethode in der Assemblersprache
geschrieben. Das Testen eines Registers geschieht in einer Schleife,
wie es der Programmausschnitt zeigt:
" #----- 1. Schleife ----------------------"
1. " mov r0,#0x1; "
2. " mov r1,#0x1; "
3. " teq r0,r1; bne Error;"
4. " Schleife_r0_r1: mov r0, r0,LSL #1; "
5. " mov r1, r1,LSL #1;"
6. " teq r0,r1; "
7. " teq r0,#0x80000000; bne Schleife_r0_r1;"
In dieser Schliefe werden die Register R0 und R1 getestet. In den Zeilen 1und 2 werden
Anfangswerte in die Register geschrieben und in der Zeile 3 verglichen. Sind diese ungleich,
erfolgt ein Sprung zur Fehlerroutine. Als nächstes werden in den Zeilen 4 und 5
zwei Schiebeoperationen durchgeführt. Anschließend werden die Register in der Zeile 6
verglichen. Die Schleife wird in zwei Fällen beendet: 1.) Ein Fehler tritt auf; 2.) die Eins
hat 32. Bit erreicht, was ein fehlerfreies Register signalisiert. Das gleiche Verfahren wird
für alle restliche zu testende Register angewendet.
12 Hexadezimal
13 Falls diese Muster zwei Mal hintereinander in Register geschrieben werden
14 Kurzschlüsse zwischen den Bits

4 Konzept und Implementierung 43
Da bei allen Register-Tests das Register R1 als Referenz dient, wird dieses auf eine
andere Weise überprüft. Anstelle der Schiebeoperation LSL wird die zweier Multiplikation
verwendet. Durch das Testen des Register R1 auf zwei verschiedene Weisen wird
mit sehr hoher Wahrscheinlichkeit sichergestellt, dass das Register fehlerfrei ist. Die
Funktionsweise kann an dem folgenden Listing nachvollzogen werden:
1. " mov r0,#0x1; "
2. " mov r1,#0x1; "
3. " mov r2,#0x2; "
4. " Schleife_r0_r1: mul r3,r0,r2;"
5. " mov r0,r3; "
6. " mov r3,#0; "
7. " mul r3,r1,r2; "
8. " mov r1,r3; "
9. " mov r3,#0; "
10. " teq r0,r1; bne Error;"
11. " teq r0,#0x80000000; bne Schleife_r0_r1;"
Wobei zu diesem Listing gesagt werden muss, dass die Fehlerfreiheit des Registers R3
angenommen wird.
4.1.4 CPU-Test
Konzept
Wie schon in den Grundlagen erwähnt wurde, bedeutet das Testen einer CPU eigentlich
das Testen von einzelnen Befehlen der CPU. Die Befehle des Philips LPC2148 wurden
in dem Kapitel Grundlagen aufgelistet.
Beim Testen wird das Vergleichsprinzip der Fehleraufdeckung benutzt. Der CPU-Test
wird in mehrere kleinere Tests aufgeteilt. In einzelnen Funktionen werden arithmetische
und logische, Load und Store, Vergleichs- sowie Sprungbefehle getestet.
Implementierung der arithmetischen, logischen und Multiplikation-Befehl-Tests
Wie bei der Implementierung aller CPU-Tests wird die Assemblersprache verwendet,
weil sich nicht alle Befehle der CPU in Programmiersprache C implementieren lassen.
Die Funktionsweise des Testens aller arithmetischen, logischen sowie Multiplikations-
Befehlen ist folgende:
1. Zwei Register werden mit Testmustern beladen.
2. Der zu prüfende Befehl wird auf diese Register angewendet.
3. Das Resultat wird mit dem erwarteten Wert verglichen.
4. Ist die Prüfung erfolgreich, wird der nächste Befehl getestet.

4 Konzept und Implementierung 44
Als Beispiel dient die Funktionsweise des Befehls ADC (Add with Carry – Addition mit
Übertrag); wenn zu 0xFFFFFFFF (hexadezimal), binär 11111…111, eine „1“ addiert
wird, findet ein Übertrag statt. Der Registerinhalt wird invertiert und eine „1“ dazu addiert.
Getestet wird wie folgt:
1. " ldr r1, =0x55555555;"
2. " ldr r2, =0xAAAAAAAB;"
3. " mov r4, #0x1;"
4. " adc r3,r1,r2;"
5. " teq r3,r4; bne Error;"
In den Zeilen 1 und 2 werden die Register R1 und R2 mit Testwerten beladen, sowie der
R4 mit dem Erwartungswert (Zeile 3). In der Zeile 4 wird der Befehl ausgeführt und in
der Zeile 5 das Resultat überprüft.
Implementierung Load und Store Befehls-Tests
Die Load und Store Befehle werden benutzt, um Daten zwischen den Registern oder
dem RAM zu bewegen. Es besteht die Möglichkeit entweder einzelne (LDR/STR) oder
mehrere (LDM/STM) Register zu manipulieren, sowie deren Inhalte in und von RAM zu
bewegen. Das Testen der LDR- und STR-Befehle, sowie deren Modifikationen, geschieht
wie folgt:
1. In eine Adresse im RAM wird ein Musterwort geschrieben.
2. Vier Befehlzyklen erfolgt keine Aktion, damit der Schreibvorgang seine
Wirkung im Speicher zeigt.
3. Das Wort wird vom Speicher in ein anderes Register geschrieben.
4. Die Wörter werden verglichen, stimmen Sie nicht überein, wird ein
Fehler gemeldet.
Die Vorgehensweise beim Testen von STM und LDM (Arbeit mit mehreren Registern) ist
die gleiche, jedoch werden die Register R0-12 in zwei Hälften geteilt: Eine Hälfte hält die
Referenzwerte, die andere dient für die Zwischenspeicherung der Testwerte. Nach einem
erfolgreichen Test werden die Aufgaben der Hälften getauscht, damit die Funktionalität
der Befehle auf allen Registern geprüft wird.
Die Funktionsweise zeigt der Auszug aus dem Quellcode:
1. "ldr r12, =0x40000500; # R12 mit neuer Adresse laden"
2. "ldr r0, =0x5A5A5A5A; # in Register 32-Bit langen Wert laden"
3. "ldr r1, =0xA5A5A5A5; # --"
4. "ldr r2, =0x5A5A5A5A; # --"
5. "ldr r3, =0xA5A5A5A5; # --"
6. "ldr r4, =0x5A5A5A5A; # --"
7. "ldr r5, =0xA5A5A5A5; # --"

4 Konzept und Implementierung 45
8. "stmdb r12, {r0-r5}; # Registerinhalte ab Speicheradresse"
" # die in R12 steht, schpeichern"
9. "NOP; # No Operation"
10. "NOP; #"
11. "NOP; #"
12. "NOP; # damit Schreibvorgang Wirkung zeigt"
13. "ldmdb r12, {r6-r11}; # Werte vom Schpeicher holen"
14. "teq r0, r6; bne LSMError; # vergleichen, falls ungleich -> Error"
15. "teq r1, r7; bne LSMError; # vergleichen, falls ungleich -> Error"
16. "teq r2, r8; bne LSMError; # vergleichen, falls ungleich -> Error"
17. "teq r3, r9; bne LSMError; # vergleichen, falls ungleich -> Error"
18. "teq r4, r10; bne LSMError; # vergleichen, falls ungleich -> Error"
19. "teq r5, r11; bne LSMError; # vergleichen, falls ungleich -> Error"
In der Zeile 1 wird die Adresse im RAM, ab der die Inhalte der Register gespeichert werden,
in das R12 geladen. In den Zeilen 2 bis 7 werden die Register R0-5 mit den Testwerten
beschrieben. In der Zeile 8 werden die Inhalte der Register in den RAM geschrieben.
Es wird vier Zyklen keine Aktion ausgeführt, damit de Schreibvorgang seine
Wirkung zeigt. In Zeile 13 werden die Werte in die Register R6-11 vom Speicher geschrieben.
In den Zeilen 14 bis 19 werden die vom RAM geholten Werte mit Referenzwerten
verglichen.
Implementierung der „Test“- und „Compare“-Tests
Der ARM7TDMI-CPU stehen zwei Arten von Test- und Vergleichsbefehlen, sowie deren
Modifikationen zur Verfügung, und zwar TST und CMP. Diese Befehle werden gemeinsam
geprüft, also CMP mit Hilfe von TST und umgekehrt. Die Funktionsweise des Tests
wird anhand des Quellcodes erläutert.
1. "ldr r1, =0xA5555555; "
2. "ldr r2, =0x15555555; "
3. "mrs r0, cpsr; "
4. "cmp r1, r2; "
5. "mrs r3, cpsr; "
6. "teq r3, r0; bne CTError; "
In den Zeilen 1 und 2 werden die Register mit Testwerten befüllt. In der Zeile 3 wird der
aktuelle Inhalt des Current Programm Status Registers (CPSR) gespeichert, um Änderungen
in den Statusflags festzuhalten. In der Zeile 4 wird der zu testende Befehl (hier
CMP) ausgeführt. Anschließend wird in der Zeile 5 der Inhalt des CPSR nach der Operation
gespeichert und die beiden Werte mit der Erwartungshaltung verglichen.

4 Konzept und Implementierung 46
Implementation des Sprungbefehl-Tests
Bei den Sprungbefehlen werden unbedingte Sprünge sowie bedingte Sprünge auf ihre
korrekte Funktionalität geprüft.
Zuerst wird der unbedingte Sprung geprüft und zwar wie folgt: Es wird eine Schleife für
drei unbedingte Sprünge initialisiert. Bei einem erfolgreichen Sprung wird hoch gezählt.
Falls die drei Sprünge erfolgt sind, wird die Schleife verlassen und es wird mit weiteren
Tests fortgefahren, ansonsten verbleibt die CPU in der Schleife. Diese Schleife zeigt
folgendes Listing:
1. "ldr r0, =0x00000001; # belade Register mit Werte"
2. "ldr r1, =0x00000008; # --"
3. "BER: NOP; # No Operation"
4. "mov r0, r0,LSL #1; # eins schieben"
5. "teq r0, r1; beq BER1; # vergleiche, ob 3 Spuenge erfolgt sind"
6. "b BER; # falls nicht -> zurueck"
Ein bedingter Sprung findet statt, falls bestimmte Kombinationen von Statusflags vorhanden
sind 15 . Geprüft wird wie folgt: es wird eine Operation mit bestimmten Werten
durchgeführt, infolge deren, bestimmte Flags gesetzt („1“) oder nicht gesetzt („0“) werden;
anhand des Ergebnisses soll ein bedingter Sprung erfolgen und zwar zum nächsten
Test; falls nicht, verfängt sich die CPU in einer Endlosschleife. Dies zeigt die folgende
Listing:
1. "ldr r0, =0xAAAAAAAA; # belade Register mit Werten"
2. "ldr r1, =0xAAAAAAAA; # --"
3. "mov r3, #0x00000000; # --"
4. "Berror0:NOP; # "
5. "NOP; # No Operation"
6. "NOP; # --"
7. "sub r2, r0, r1; # Subtraktion => 0X00000000"
8. "teq r3, r2; bne Berror0; # falls ungleich , "
" # zurueck; Z-Flag nicht gesetzt"
9. "b Berror1; # ansonsten weiter"
10."Berror2: b Berror2; # beide versagt, endlosschleife"
11."Berror1: NOP; # die naechste Schleife"
15 z.B. beim Befehl „TEQ“ muss der Flag Z gesetzt(gleich) oder nicht gesetzt(ungleich) sein

4 Konzept und Implementierung 47
4.1.5 RAM-Test
Konzept
In dem Kapitel Grundlagen wurden zwei Testverfahren genannt, mit denen in der vorhandenen
Bibliothek das RAM getestet wurde. Die beiden Testmethoden wurden auf
ihre Fehleraufdeckung, Zeit und die sicherheitstechnische Tauglichkeit beglichen. Dabei
kam nur ein entscheidender Unterschied als Ergebnis heraus: bei dem X-March-Test
wird der Inhalt des RAMs vollständig „zerstört“, weil das gesamte RAM mit Nullen überschrieben
wird. Beim Überschreiben des RAMs können sehr wichtige und für den Erhalt
der Sicherheitsfunktion benötigte Daten einfach gelöscht werden. Anhand dieser Tatsache
wurde der transparente Speichertest ausgewählt und überarbeitet.
Der Philips LPC2148 verfügt über einen 32 KB großen Arbeitspeicher(RAM). Abbildung
29 [LPC2148] zeigt der Adressbereich des RAMs:
Abbildung 29: Adressbereich des RAMs
Aus der Abbildung geht hervor, dass das RAM sich von 0x40000000 bis 0x40007FFF
erstreckt. Im unteren RAM-Bereich befindet sich ein reservierter Bereich. In diesem Bereich
befinden sich Stack, Heap und Interrupt Vektoren. In dieser Thesis werden diese
Bereiche nicht getestet, weil es sich während der Ausführung von Programmen der Stackinhalt
ständig verändert, was zu immer neuen CRC-Werten führen wird, also nach
Definition des Tests zu einem Fehler. Um diese Bereiche zu testen, sollen neue Testmethoden
entworfen werden. Leider ist diese Thesis zeitlich begrenzt und lässt dies nicht
zu.
Implementierung des ROM-Tests
Dem vorhandenen transparenten Speichertest werden die Start-, Endadressen, Sektorlänge
und Anzahl der Sektoren übergeben. Anhand dieser Daten wird der Test durchgeführt.
Zuerst wird das Testwort selbst mit einem Walking Bit Pattern überprüft. Als nächstes
wird der Sektor, in dem sich das Testwort befindet, getestet, danach die übrigen Sektoren.
Falls die Tests erfolgreich waren, wird das nächste Testwort genommen.
In der vorhandenen Bibliothek wurde zur Signaturberechnung (CRC-Bildung) eine 16 Bit
Signatur verwendet. Dies wird geändert und eine 32 Bit lange CRC genommen. Anstatt
der Berechnung jedes einzelnen Wertes zur Laufzeit, was zusätzlichen zeitlichen Aufwand
bedeutet, wird eine andere Methode verwendet. Bei dieser Methode wird eine Tabelle
(Look-Up-Tabelle) im ROM angelegt mit Hilfe derer die CRC-Signatur berechnet

4 Konzept und Implementierung 48
wird. Diese Funktion berechnet die CRC nur für ein Byte. Deswegen wird das 32 Bit
Wort in vier Bytes zerlegt und über diese die CRC-Prüfsumme gebildet. Dies liefert die
gleichen Ergebnisse, als wenn die CRC über das gesamte Wort gebildet würde.
Aus der Analyse des aus der Literatur bekannten transparenten Speicher Tests wurde
ersichtlich, dass Signaturen über alle Sektoren immer gebildet werden, sogar über die,
die schon getestet wurden. Das muss aber nicht sein. Wenn von einem „doppelseitigen“
Kurzschluss ausgegangen wird, also die kurzgeschlossenen Speicherzellen beeinflussen
sich wechselseitig, so können die schon getesteten Sektoren aus dem Test weggelassen
werden. Die Begründung für dieses Vorgehen ist die folgende: falls eine Zelle
z.B. aus dem Sektor 5 einen Kurzschluss mit einer Zelle aus dem Sektor 1 hat, so wird
dieser schon beim Testen des ersten Sektors aufgedeckt. Durch dieses Vorgehen wird
der zu testende Speicherbereich zum Ende hin immer kleiner und somit immer schneller.
Dieses Prinzip wird in der Abbildung 30 veranschaulicht:
Abbildung 30: RAM-Test
Die Realisierung dieses Prinzips zeigt das Flussdiagramm von Abbildung 32. Alle Variablen
wie RAM-Anfangsadresse, RAM-Endadresse, Sektorlänge, Adresse des Testwortes
und der Sektor, in dem sich das zu testende Wort befindet, werden als globale Variablen
deklariert, damit sie ihren Wert nicht verlieren, wenn in den normalen Betrieb gewechselt
wird. Bei den Aufrufen des RAM-Tests werden das Testwort, der zu
testende Sektor und Informationen darüber, wo sich das Testwort befindet (im zu
testenden Sektor oder außerhalb) übergeben.
Die Vorgehensweise:
1. Zuerst wird überprüft ob sich das zu testende Wort immer noch im RAM befindet,
falls nicht wird die Adresse des Wortes an die Anfangsadresse gesetzt und die
erste Testscheibe ausgeführt.

4 Konzept und Implementierung 49
2. Dann wird analysiert ob sich das Wort noch im laufenden Sektor befindet. Falls
nicht (das Testwort hat den laufenden Sektor verlassen), wird die Nummer des
laufenden Sektors inkrementiert, sowie die Variable (im Programm „SMWgetestet“),
die ob der Sektor mit dem Testwort geprüft worden ist oder nicht zeigt,
auf „false“ gesetzt.
3. Im nächsten Schritt unter sucht der Algerithmus ob schon alle Sektoren ohne das
Testwort überprüft sind. Falls ja: wird der Index auf eins zurückgesetzt, „SMWgetestet“
auf „false“ gesetzt und das nächste Testwort genommen. Falls nicht: siehe
Punkt 4.
4. Es wird unterschieden zwischen zwei Arten von Sektoren: in dem sich das Testwort
befindet und wo nicht. Im ersten Fall wird der RAM-Test aufgefordert den
Sektor mit Testwort (dritter Übergabeparameter gleich 1, sowie die laufende Sektornummer)
zu testen, im zweiten ohne (dritter Übergabeparameter gleich 0, sowie
die laufende Sektornummer+index 16 ).
4.1.6 Ein-/Ausgabe Test
Konzept
Abbildung 31: RAM-Test (Flussdiagramm)
Um mit seiner Umgebung zu kommunizieren verfügt das gegebene Board über zwei Ein-
/Ausgabe Ports P0 und P1 (GPIO-Ports), zwei ADC, einen DAC und zwei PWMs. Das

4 Konzept und Implementierung 50
Port P0 ist 32-Bit lang, also es besitzt 32 Pins P0.0-32. Diese Pins können entweder als
Eingang, Ausgang, ADC, DAC oder PWM benutzt werden. Die Umschaltung geschieht
mit Hilfe des Registers PINSEL 17 . Das Port P0 ist bitadressierbar sowie maskierbar: jedes
der 30 zur Verfügung stehenden Pins dieses Portes können einzeln oder mehrfach
manipuliert werden. Der Pin P0.31 ist nur als Ausgabeport zu benutzen. Der Pin P0.24
ist nicht vorhanden.
Die Pins wurden mit dem Walking Bit Verfahren getestet, da an den µController keine
Peripherie angeschlossen wurde, müssten keine besonderen Schaltzeiten angehalten
werden. Die Pins wurden in zwei Hälften aufgeteilt, eine dient als Ausgang, die andere
als Eingang. Über die Ausgangspins wird eine „1“ geschoben und an den Eingangspins
kontrolliert.
Implementierung
Das Board besitzt zwei ADCs mit jeweils 6 Kanälen, außerdem ein DAC. Alle Kanäle der
ADCs wurden hardwaremäßig an den Ausgang des DACs angeschlossen. Zum Testen
wurde das Prinzip der Plausibilitätsprüfung angewendet. Hierbei handelt es sich um einen
Zusammenhang zwischen dem Ausgang(DAC) und Eingang(ADC): werden die
ausgegebenen Werte größer, so müssen auch eingelesene Werte größer werden. Der
Vergleich soll aber Toleranzen beinhalten, diese sollen an die Vergleichswerte angepasst
sein. Die Toleranzen müssen vorhanden sein, weil jede Schaltung rauscht und die
eingelesenen Werte dadurch verfälscht werden können.
Das Testen geschieht für alle Kanäle der beiden ADCs und zwar nacheinander, weil die
eingelesenen und konvertierten Werte in jeweils einem Register der ADCs gespeichert
werden.
4.1.7 ROM-Test
Konzept
Das gegebene Board Philips LPC2140 hat 512 KByte Programmspeicher bzw. ROM,
dies zeigt die Abbildung 16 (siehe s.24).
Der Adressbereich des ROMs befindet sich zwischen 0x00000000-0x0007FFFF. Dieser
Speicher soll während des Betriebs immer unverändert bleiben. Weil im ROM das auszuführende
Programm abgelegt wird, können kleinste Veränderungen im Speicher zu
einem falschen Programmablauf führen, was natürlich verheerende Auswirkungen zur
Folge haben kann.
Implementierung
Das ROM wird wie folgt getestet: beim Anlauftest wird eine 32-Bit lange Signatur (CRC)
gebildet. Dabei wird angenommen, dass das Programm im Speicher korrekt ist. Diese
16 in der Summe max. 8 – Anzahl der Sektoren im RAM

4 Konzept und Implementierung 51
Anfangssignatur wird gespeichert und als Referenz gebraucht. Unterscheidet sich die im
Betrieb berechnete Signatur von der Anfangssignatur, so wird angenommen, dass im
ROM ein Fehler vorhanden ist.
Für die Berechnung der CRC-Werte wird eine Look-Up Tabelle mit allen CRC-Werten für
ein Byte als Konstante definiert und im ROM abgelegt 18 . Mit diesem Verfahren werden
nur etwa 5 Sekunden benötigt, um eine Signatur über das gesamte ROM zu bilden.
Trotzdem wird das ROM in Segmente unterteilt und zwar in 64, jeder 8 KB groß, damit
die Berechnung nur etwa 100ms dauert. Was nur ein Drittel der Zeit ist, die für den
Selbsttest während des Betriebs zur Verfügung steht.
Ob die Signatur über den gesamten ROM am Stück oder Segmentweise gebildet wird,
macht keinen Unterschied.
4.1.8 Timer-Test
Konzept
Die Grundidee des Testen des Timers ist folgende: Wenn der Timer fehlerfrei funktioniert,
muss die Differenz zwischen zwei Abfragungen des Timers innerhalb einer bestimmten
Zeit immer gleich sein. Dieser Idee nach wird der Test konzipiert.
Implementierung
Das Evaluationsboard verfügt über zwei 32-Bit Timer/Counter. Für die Realisation des
Zeitscheibenverfahrens wird der Timer 0 verwendet. Da es nur zwei Zeitscheiben gibt
die Längste 700ms für das Hauptprogramm und die zweite, die etwa 300ms dauert, die
zum Testen des Boards benötigt wird. Der Timer wird benötigt um die längste Scheibe
zu ermöglichen.
Zum Testen des Timers wird der Zeitintervall von 1ms ausgewählt und der Timer zwei
Sekunden lang beim Anlauftest überprüft. Die Differenz, die während dieses Tests errechnet
wird, wird als Referenzwert gespeichert und bei weiteren Tests mit aktuellen
Differenzen verglichen. Falls diese nicht übereinstimmen, wird ein Fehler gemeldet. Im
Betrieb wird 10 ms lang getestet. Hier mit wird der Timer 10-mal überprüft.
4.1.9 Zeitscheibenverfahren
Wie schon beim Timer-Test erwähnt, wurden die Selbsttests alle 700ms aufgerufen.
Dies geschieht wie folgt:
• der Timer wird mit 700ms geladen und nach Ablauf dieser Zeit ein Interrupt ausgelöst.
• Beim Auslösen des Interrupts wird die Interrupt-Routine aufgerufen.
17 weitergehende Informationen in [LPC2148]
18 in der Praxis überprüft

4 Konzept und Implementierung 52
• In dieser Routine werden alle Test entweder ganz (CPU-Test) oder als Teiltests
ausgeführt.
• Danach wird der Timer resetet und mit dem Hauptprogramm für weitere 700ms
fort gefahren.
Weil solche Tests wie CPU-, Reister- oder DA-/AD-Test zusammen in etwa 60ms benötigen,
wurden diese nicht in Scheiben unterteilt. Der RAM- und ROM-Test werden jedoch
in Scheiben ausgeführt, deswegen wurden sie auch dementsprechend
konzipiert.

5 Validation 53
5 Validation
Dieses Kapitel beschäftigt sich mit dem Testen der Bibliothek. Dabei werden folgende
Punkte bewertet:
• die Ausführungszeit
• und die Fehleraufdeckung
Die Ausführungszeiten werden mit Hilfe eines digitalen Oszilloskops gemessen. Verfahren
wird wie folgt: in dem Hauptprogramm wird eine Endlosschleife initialisiert, in dieser
Schleife wird eine LED angeschaltet, dann der Test ausgeführt (bzw. ein Teiltest oder
eine Zeitscheibe), und nach dem Test die LED ausgeschaltet. Die Zeit in der die LED
eingeschaltet war, ist die Ausführungszeit eines Tests. Die Ausführungszeiten der Tests
sind in der Tabelle 7 aufgelistet:
Test Ausführungszeit
CPU (alle Befehle + Register-Test) 50 µs
DA-/AD-Wandler 40 ms
Watchdog 10 ms
Eine Zeitscheibe des ROM-Tests 72 ms
Eine Zeitscheibe des RAM-Tests 71 ms
ROM-Test komplett (Anlauftest) ~ 5 s
Timer-Test (Anlauftest) ~2,5 s
Timer-Test (Betrieb) 11 ms
Ein-/Ausgabe-Test 10 ms
Tabelle 8: Ausführungszeiten der Tests
Aus dieser Tabelle wird im Betrieb für das Testen des Boards insgesamt maximal etwa
220 ms benötigt. Dementsprechend kann die angenommene Zeit von 300 ms verkürzt
werden.
Was die Fehleraufdeckung angeht, können bei einigen Tests die Fehler „eingebaut“
werden, wie bei einem RAM-, oder einem Ein-/Ausgabe-Test. Bei dem ROM-Test wird
gezeigt, dass das Ändern eines einzelnen Bits zu einer anderen Signatur führt.
Da die Entwicklungsumgebung HiTOP 5.2 über ein Fenster, in dem die Registerinhalte
angezeigt werden, verfügt, kann durch dieses der Register-Test kontrolliert werden. Dieses
Fenster wird ebenso zur Kontrolle des CPU-Tests genutzt.
Bei dem ROM-Test wird gezeigt, dass durch das Ändern eines einzelnen Bits eine neue
CRC-Signatur gebildet wird. Dabei wird eine Konstante mit dem Wert „0“ im ROM gespeichert
und der ROM-Test ausgeführt, danach die CRC-Signatur festgehalten.

5 Validation 54
Der Wert der Konstante wird geändert und auf „1“ gesetzt. Der ROM-Test wird durchgeführt
und die CRC-Signaturen verglichen. Dieser Test ist erfolgreich verlaufen.
Bei dem RAM-Test wird in der Routine „sector_without_word“, nach dem die erste Signatur
gebildet und das Testwort invertiert wurde, der Inhalt einer Speicherzelle im Sektor
geändert. Die zweite Signatur wird gebildet und es muss eine Fehlermeldung erfolgen.
Dieser Test ist erfolgreich verlaufen, es wurde eine Fehlermeldung ausgelöst.
Bei dem Ein-/Ausgabe-Test wird ein Port anstatt mit nur einem anderem, jetzt mit zwei
Porten hardwaremäßig verbunden. Der Test soll diese Manipulation abfangen können.
Dieser Fehler wird vom Test aufgedeckt.
Das genauere Testverfahren kann im Anhang A nachgeschaut werden.

6 Fazit und Ausblick 55
6 Fazit und Ausblick
Diese Thesis hat einen Überblick über die große Welt der Sicherheitstechnik der
µControllern verschafft. Grundlegenden Selbsttests der Hardware wurden implementiert.
Es wurden die grundlegenden Selbsttests für einen ARM7TDMI Prozessor implementiert.
Diese dienen einer Überprüfung des gesamten Systems vor Inbetriebnahme und
während des Betriebs. Alle Tests wurden so konzipiert, dass diese im Hintergrund einer
Hauptanwendung ausführbar sind. Die größten Schwierigkeiten sind mit dem RAM-Test
verbunden, da mehrmals Signaturen über einen Sektor gebildet werden. Dennoch ist
der Test fast auf alle µController portierbar. Dies betrifft auch den ROM-Test und den
Ein-/Ausgabetest. Der CPU-Test könnte auch in der Programmiersprache C geschrieben
werden, was bei einfachen Befehlen wie ADD oder ORR sehr leicht wäre. Jedoch ist es
nicht möglich in C alle spezifischen Befehle wie RSB (Reverse Subtract with Carry) zu
testen. Deswegen wurde der ganze Instruktionssatz des ARM7TDMI in Assembler überprüft.
Die Grundidee dieser Tests ist auf viele andere CPUs anwendbar.
Es wurden alle Musskriterien, die an die Bibliothek gestellt wurden, erfüllt. Zudem wurde
auch ein Kannkriterium erfüllt, nämlich die Zeitscheiben implementiert.
Die hier implementierte Bibliothek soll als ein Prototyp angesehen werden und kann als
Basis genommen werden. Weil diese Bibliothek modular aufgebaut ist, besteht die Möglichkeit
für die Interessenten diese mit beliebigen benötigten Tests für bestimmte Anwendungen
zu ergänzen. Dabei müssen aber die Ausführungszeiten beachtet werden.
Als Erweiterung für diese Bibliothek könnte z.B. die Implementierung der nicht erfüllten
Kannkriterien (z.B. PWM-Test) sein. Außerdem kann versucht werden den CPU-Test in
der Programmiersprache C zu implementieren.

Literaturverzeichnis 56
Literaturverzeichnis
[ANLPC2148] Applications Notes
http://www.semiconductors.philips.com/pip/LPC2141FBD64.html
(letzter Zugriff 30.08.2007)
[ARM7] „ARM7TDMI Technical Reference Manual“, www.arm.com
[ARMREF] “ARM Architecture Reference Manual”,
http://www.altera.com/literature/third-party/ddi0100e_arm_arm.pdf
[BAL96] Prof. Dr.-Ing. habil. Helmut Balzert: „Lernbuch der Software-
Technik“, Software Entwicklung, Spektrum, 1996
[BEC03] Prof. Dr. rer. nat. W.-J. Becker(Hrsg.): „Mikroprozessortechnik:
Architektur, Implementierung, Schnittstellen“, VDE, 2003
[BGIA06] Mario Mai, Günter Reuß: „Selbsttests für Mikroprocessoren mit Sicherheitsaufgaben
oder „Quo vadis Felehr?““, BGIA-Report 7/2006
http://www.hvbg.de/d/bia/pub/rep/rep05/bgia0706.html
[BIA97] Werner Kleinbreuer, Franz Kreutzkampf, Karlheinz Meffert, Dietmar
Reinert: „Kategorien für sicherheitsbezogene Steuerungen nach EN
954-1“, BIA-Report 6/97, HVBG, 1997
http://www.hvbg.de/d/bia/pub/rep/rep02/bia0697.html
[BÖM05] Thomas Bömer: „Funktionale Sicherheit nach IEC 61508“, BGIA,
2005, Sicherheitstechnisches Informations- und Arbeitsblatt 330 219
[BÖR04] Josef Börcsök: „Elektronische Sicherheitssysteme: Hardwarekonzepte,
Modelle und Berechnung“, Hüthig, 2004
[BÖR06] Josef Börcsök: „Funktionale Sicherheit: Grundzüge sicherheitsgerichteter
Systeme“, Hüthig, 2006
[GEH07] Patrik Gehlen: „Funktionale Sicherheit von Maschinen und Anlagen:
Umsetzung der europäischen Maschinenrichtlinie in der Praxis“, Siemens,
2007
[GRÄ04] Winfried Gräf: „Maschinensicherheit: Auf der Grundlage der europäischen
Sicherheitsnormen“, Hüthig, 2004
[HAL99] W.A. Halang/R. Konakowsy: „Sicherheitsgerichtete Echtzeitsysteme“,
Oldenburg, 1999

Literaturverzeichnis 57
[HAM99] Qaisar Hameed, Master’s Thesis: „A Behavioral Test Strategy
For Board Level Systems“, 1999
(http://scholar.lib.vt.edu/theses/available/etd-031099-213422/)
(letzter Zugriff 30.08.2007)
[ISSA02] “Rechner in der Maschinensicherheit“, ISSA Prevention Series
No. 2046(G), ISBN 92-843-7157-0
[KRA04] Michael Kraus, Diplomareit: „Realisierung eines programmierbaren
Sicherheitsbauteils zum Anschluss von Bus-Systemen in dezentralen
Energieverteilungsanlagen“, 2004
[LPC2148] Philips LPC2148 User Manual
http://www.nxp.com/acrobat_download/usermanuals/UM10139 1.pdf
[MAR06] Trevor Martin: „The Insider Guide to the Philips ARM ® 7 Microcontrollers“,
2006,
http://www.hitex.co.uk/arm/lpc2000book/free_downloadpage.html
[RED98] Michael Redeker, Studienarbeit: „Design und Verifikation eines
defekttoleranten selbstkonfigurierenden DRAM-Moduls“, 1998
[SCH97] Michael, Schäfer: „Fehlererkennende Maßnamen in Mikroprozessoren“,
BIA, 1997, Sicherheitstechnisches Informations- und Arbeitsblatt
330 225
[TUR05] Kiranraj Tiruchinapalli, Master Thesis: „Modular Safety Design of Autonomous
Systems Using KURT3D as an Example“, 2005
[WAH05] Dr. Michael Wahl, Skript: „Speichertest“ http://www.rs.uni-
siegen.de/skripte/Speichertechnologien_1/ 7 Test. pdf
[WAL04] Klaus-Dieter Walter: „Messen, Steuern und Regeln mit ARM-
Mikrokontrollern“, Franzis, 2004

Abbildungsverzeichnis 58
Abbildungsverzeichnis
Abbildung 1: 3-stufige Pipelne......................................................................11
Abbildung 2: Evaluation Board MCB2140........... .........................................12
Abbildung 3: Tantino für ARM7-9..................................................................13
Abbildung 4: ARM7TDMI main processor logic .......….................................14
Abbildung 5: Load-and-Store Prinzip ………….............................................15
Abbildung 6: Registerbank ...........................................................................16
Abbildung 7: Current Program Status Register ............................................16
Abbildung 8: ARM Benutzungsmodi .............................................................17
Abbildung 9: Benutzung von Registern im THUMB-Satz ..................................17
Abbildung 10: ARM-Instruktionssatz Formate ....................................................19
Abbildung 11: Standartsprungbefehle .................................................................19
Abbildung 12: Sprungbefehle BLX und BL ..........................................................20
Abbildung 13: Data Processing Instruction ………………………….……………..20
Abbildung 14: Data Processing Instruction …………………………………….…..20
Abbildung 15: Bewegung von Daten zwischen mehreren Registern ..................22
Abbildung 16: LPC2148 Memory Map …………..………………………….….…...23
Abbildung 17: Entwicklungsumgebung HITOP 5.2..............................................24
Abbildung 18: Risikograph(EN 954-1) .................................................................25
Abbildung 19: Steuerungsversagen nach „Lebensphasen“ ................................26
Abbildung 20: „Badewannekurve“........................................................................27
Abbildung 21: Das allgemeine Fehlererkennungsprinzip ....................................28
Abbildung 22: Zustandgraph eines fehlerfreien Speicherbausteins ....................29
Abbildung 23: Zustandgraph eines SA0 ..............................................................30
Abbildung 24: Zustandgraph eines SA1 ..............................................................30
Abbildung 25: Zustandgraph eines Transition-Up-Faults ....................................30
Abbildung 26: Funktionsweise eines transparenten Speichertests .....................34
Abbildung 27: Ablauf des WD-Tests ...................................................................41

Abbildungsverzeichnis 59
Abbildung 28: Walking Bit ...................................................................................41
Abbildung 29: Adressbereich des RAMs .............................................................47
Abbildung 30: RAM-Test .....................................................................................48
Abbildung 31: RAM-Test (Flussdiagramm) .........................................................49

Tabellenverzeichnis 60
Tabellenverzeichnis
Tabelle 1: Bedienungspräfixe ..................................................................................... 18
Tabelle 2: Datenbearbeitende Befehle ....................................................................... 21
Tabelle 3: Load- Befehle ............................................................................................. 21
Tabelle 4: Store- Befehle ............................................................................................ 22
Tabelle 5: Die Multiplikationsbefehle ........................................................................... 22
Tabelle 6: Funktionale Fehler eines RAMs ................................................................. 29
Tabelle 7: Zusammenhang der Fehlermodelle und funktionaler Fehler ...................... 31
Tabelle 8: Ausführungszeiten der Tests ...................................................................... 52

Anhang A: Tests 61
Anhang A: Tests
1. ROM-Test
Ausführungszeit:
Es wird die Zeit ermittelt, die für die Ausführung einer Zeitscheibe des ROM-Tests benötigt
wird. Für diese Zwecke wird eine Testroutine geschrieben, die wie folgt aussieht:
for(z=1;z

Anhang A: Tests 62
Fehleraufdeckung:
Es wird gezeigt, dass ändern eines Bits zu einer anderen Signatur führt. Für diese Zwecke
wird im ROM eine Konstante angelegt nämlich:
“static const unsigned int testvar = 0;”
Der ROM-Test wird ausgeführt. Die Signatur, die berechnet wurde, ist die folgende:
0xBCDE18DA - Hexadezimal oder 3168671962 - Dezimal
Nach diesem Durchlauf wird nur die Konstante geändert, und zwar wie folgt:
“static const unsigned int testvar = 1;”
Der ROM-Test wird wieder ausgeführt. Die Signatur die berechnet wurde, ist die folgende:
0x5860C61F – Hexadezimal oder 1482737183 - Dezimal
Die berechneten Signaturen unterscheiden sich deutlich. Jetzt wird überprüft ob das
Ändern der Konstanten in den ursprünglichen Zustand auch die zuerst berechnete Signatur
als Ergebnis wieder zurückgegeben wird. Die Konstante wird wieder geändert wie
folgt:
“static const unsigned int testvar = 0;”
Der ROM-Test wird wieder ausgeführt. Die Signatur die berechnet wurde, ist die folgende:
0xBCDE18DA – Hexadezimal oder 3168671962 - Dezimal
Das ist die gleiche Signatur, die im ersten Test das Ergebnis war. Aus diesem wird ersichtlich,
dass das Ändern eines einzelnen Bits zu einer anderen Signatur führt.
2. RAM-Test
Ausführungszeit:
Die Ermittlung der Ausführungszeit für eine Zeitscheibe des RAM-Tests geschieht genau
wie beim ROM-Test: mit Hilfe von LEDs.
Für eine Zeitscheibe des RAM-Tests werden laut Osziloskops 71ms benötigt. Bis ein
Wort selbst und das Wort mit allen 8 Sektoren getestet wird, werden in etwa 71*8 ≈ 568
ms benötigt. Bis ein Sektor vollständig getestet ist und weggelassen werden kann vergehen
≈ 581632 ms oder etwa 10min. Diese Zeit wird benötigt um den größten Teil des
Tests (von acht die immer schneller werden) auszuführen, falls dieser am Stück ausgeführt
sein sollte. Die weiteren Berechnungen werden immer Kürzer, weil immer weniger
Sektoren zu testen gibt. Dies zeigt der Auszug aus dem Quellcode bevor dieser automatisiert
wurde:
void RAM_test()
{ …
runsector = 1;
…

Anhang A: Tests 63
for(i=start; i

Anhang A: Tests 64
Fehleraufdeckung:
Es wird ein Fehler in das RAM „eingebaut“: in der Routine „sector_without_word()“ wird
vor dem Berechnen der zweiten Signatur eine Speicheradresse im zu testenden Sektor
verändert, was eine andere CRC-Signatur als Folge hat. Die Routine muss den Fehler
abfangen. Dieser Test verläuft erfolgreich: es wird eine Fehlermeldung ausgelöst.
Den eingebauten Fehler zeigt der Auszug aus dem Quellcode:
unsigned long *fehler = 0x40001010;
…
void sector_without_word(int sector, unsigned long *testword)
{
…
for (i=start; i

Anhang A: Tests 65
Ausführungszeit:
Die CPU-Tests und Register-Test werden nacheinander ausgeführt und die Ausführungszeit
gemessen. Die Abbildung zeigt das Ergebnis:
Die gemessene Ausführungszeit beträgt laut dem Oszilloskop 48,20 µs.
Bei diesen Tests ist es schwer einen Fehler einzubauen. Aber es ist möglich einen Test
mit falschen Werten ausführen lassen. Dieser Test verlief erfolgreich: es kam eine Fehlermeldung.
4. Timer-Test
Ausführungszeit:
Für die Ausführung des Timer-Tests werden laut dem Oszilloskop 10,00 µs im Betrieb
benötigt. Beim Anlauftest werden 2s benötigt.

Anhang A: Tests 66
Fehleraufdeckung:
Es wird ein Fehler „eingebaut“: weil es in der Routine zwei „while“-Schleifen gibt, wird die
zweite nur um einen Schritt länger gemacht. Dabei entstehen zwei unterschiedliche Differenzen.
Es muss eine Fehlermeldung erfolgen. Dies zeigt das folgende Listing:
void timer_test_run(void){
unsigned int timer0, timer1, dif0, dif1;
unsigned int timer10, timer11;
int u=-2;
int o=2;
unsigned int r, zyklen = 0;
while(zyklen < 5){
r=0;
timer0 = TIMER0_TC;
- while(r

Anhang A: Tests 67
5. DA-/AD-Test
Ausführungszeit
}
}
dif1 = timer11-timer10;
if( u

Anhang A: Tests 68
6. Port-Test
Es werden exemplarisch vier Pins von Port 0 getestet. Für die Ausführung werden laut
Oszilloskop 42,00 µs gebraucht. Die Zeit wird benötigt um 2 Pins zu testen.
Also werden demnach in etwa für restliche 28 Pins: 21µs * 28 ≈ 600µs = 0,6ms benötigt.
Fehleraufdeckung
Der Pin P0.0 wird nicht nur an den P0.4 sondern auch an den P0.5 angeschlossen, dabei
erhält man ein anderes Ergebnis und es muss eine Fehlermeldung erscheinen. Dies
wurde in der Praxis nachgewiesen.

Anhang B: Entwicklungsumgebung HITOP 5.2 69
Anhang B: Entwicklungsumgebung HITOP 5.2
In diesem Anhang findet sich eine kurze Einleitung in HITOP 5.2 gemacht. Diese Umgebung
wurde benutzt um die Tests zu entwickeln und zu testen. In dieser Einleitung wird
gezeigt wie ein Projekt geöffnet werden kann, sowie wie ein Projekt kompiliert, übertragen
und von der Entwicklungsumgebung aus schrittweise ausgeführt wird.
Um ein Projekt zu öffnen muss die IDE gestartet und das Board an den PC angeschlossen
sein.
Nach dem Auswählen des Projekts, kann folgende Fehlermeldung erscheinen:
Auf der Tantinos Rückseite kann Nummer festgestellt werden. Diese Nummer wird später
gebraucht. Nach dem es drei Mal in drei hintereinander folgenden Fenster auf die
Taste „Ok“ gedrückt wird, kommt das Fenster in dem das Debbuger-Tool ausgewählt
wird. In unserem Fall ist es das „Tantino for ARM 7-9“.

Anhang B: Entwicklungsumgebung HITOP 5.2 70
Nach diesem Fenster kommt das nächste in dem die ermittelte Tantino-Nummer eingegeben
wird:
Nach dem Verbinden mit dem Tantino wird abgefragt, ob das Projekt in den Flasch-
Speicher des Boards geschrieben werden soll. Dücken Sie auf „Ok“
Das Downloaden dauert einige Sekunden. Nach dem Download kann das Projekt bearbeitet
werden.

Anhang B: Entwicklungsumgebung HITOP 5.2 71
Die IDE verfügt über mehrere Fenster wie Speicherinhalt und Registerinhalt. Aus dem
Fenster „Workspace“ können einzelne Dateien geöffnet und bearbeiten werden. Jedoch
um die Dateien zu bearbeiten muss in den Editor-Modus gewechselt werden mit Hilfe
von Tastenkombination „STRG+T“, eine weitere Betätigung dieser Tasten führt wieder in
den Debugger-Modus zurück.
In dem Debugger-Modus stehen weitere Möglichkeiten zur Verfügung:
Nach der Bearbeitung von Dateien können diese kompiliert und auf das Board übertragen
werden:

Abkürzungsverzeichnis 72
Abkürzungsverzeichnis
ADC Analog Digital Converter
ALU Arithmetical Logical Unit
ARM Advanced RISC Machine
ARM7TDMI Advanced RISC Machine 7
BIA Berufgenossenschaftliches Institut für Arbeitschutz
BGIA Berufgenossenschaftliches Institut für Arbeitschutz
CISC Complex Instruction Set Computer
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DAC Digital Analog Converter
DIN Deutsche Institut für Normung
DRAM Dynamic Random Access Memory
EN Europäsche Norm
GALPAT Galloping Pattern
GCC GNU Compiler Collection
IEC International Electrotechnical Commission
I/O Input / Output
JTAG Joint Test Action Group
MP3 MPEG-1 Audio Layer 3
PDA Personal Digital Assistant
RAM Random Access Memory
RISC Reduced Instruction Set Computer
ROM Read Only Memory
SRAM Static Random Access Memory
UART Universal Asynchronous Receiver Transmitter
USB Universal Serial Bus
VDE Verband der Elektrotechnik Elektronik Informationstechnik
WD Watchdog