Optimierung einer Softwarebibliothek für sicherheitsrelevante
Optimierung einer Softwarebibliothek für sicherheitsrelevante
Optimierung einer Softwarebibliothek für sicherheitsrelevante
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Fachhochschule<br />
Bonn-Rhein-Sieg<br />
University of Applied Sciences<br />
Fachbereich Informatik<br />
Department of Computer Science<br />
Abschlussarbeit<br />
im Bachelor Studiengang<br />
<strong>Optimierung</strong> <strong>einer</strong> <strong>Softwarebibliothek</strong> <strong>für</strong><br />
<strong>sicherheitsrelevante</strong> Anwendungen auf 32 Bit<br />
µControllern der „ARM“-Familie<br />
von<br />
Denis Kiel<br />
Erstbetreuer: Prof. Dr.-Ing. Norbert Jung<br />
Zweitbetreuer: Prof. Dr. Dietmar R<strong>einer</strong>t<br />
Eingereicht am: 17.09.2007
Danksagung 2<br />
Danksagung<br />
An dieser Stelle möchte ich mich bei allen Beteiligten, die an der Erstellung dieser Ausarbeitung<br />
mitgewirkt haben, herzlich bedanken.<br />
Besonderer Dank geht an:<br />
Prof. Dr. Dietmar R<strong>einer</strong>t und Prof. Dr. -Ing. Norbert Jung die mich immer mit ihrem Rat<br />
unterstützt haben.<br />
Meinen Kommilitonen Edmund Milke und Christian Müller, die mich mit Rat und Tat immer<br />
unterstützen.<br />
Ganz besonderer Dank geht an meine Frau Natalia und meinen Sohn David, die mich<br />
die ganze Zeit motivierten, viel Geduld hatten, sowie auf viele Gemeinsamkeiten verzichten<br />
mussten.
Erklärung 3<br />
Erklärung<br />
Hiermit erkläre ich, dass ich die vorliegende Bachelorarbeit selbständig angefertigt habe.<br />
Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt.<br />
Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches kenntlich<br />
gemacht.<br />
Ort, Datum Unterschrift
Kurzfassung 4<br />
Kurzfassung<br />
Diese Thesis beschäftigt sich mit <strong>einer</strong> <strong>Softwarebibliothek</strong>, die grundlegende Tests eines<br />
µControllers, der auf einem „ARM7TDMI“-Prozessor basiert, enthält. Diese Bibliothek<br />
soll es ermöglichen sicherheitskritische Anwendungen auf diesen µControllern laufen zu<br />
lassen. Tests, die diese Bibliothek enthält, sind so genannte Selbsttests, die der Fehleraufdeckung<br />
sowie der Fehlerbeherrschung dienen. Diese Tests prüfen Hardware auf<br />
ihre Fehlerfreiheit. Die Software, die auf dem µController eingespielt ist, wird nicht getestet.<br />
Zu den Tests, die in dieser Bibliothek enthalten sind, zählen: CPU-, Register-, RAM-,<br />
ROM-, Timer-, Ein/Ausgabe-Tests, sowie Analog-Digital- und Digital-Analog-Wandler-<br />
Test wobei beim RAM-Test kein Laufzeitstack getestet wird.<br />
Es wird Softwaremäßig getestet. Bei diesen Tests werden keine weiteren Hardwarekomponenten<br />
benötigt, nur die, die der µController besitzt.<br />
Bei dem CPU-Test wird das Vergleichsprinzip zum Testen verwendet. In diesem Test<br />
werden alle Befehle auf ihre korrekte Funktionalität überprüft. Beim Register- sowie beim<br />
Ein/Ausgabe-Test wird das Prinzip des „Walking-Bit-Patterns“ angewendet.<br />
Weil <strong>für</strong> das Testen der Komponenten im Echtzeitbetrieb sehr wenig Zeit zur Verfügung<br />
steht, wird der Analog-Digital- und Digital-Analog-Wandler anhand des Plausibilitätsprinzips<br />
geprüft.<br />
Der RAM- und ROM-Test werden so konzipiert und entworfen, dass diese in Scheiben<br />
ausführbar sind. Solch eine Vorgehensweise erlaubt die Ausführung von diesen Tests<br />
im Hintergrund <strong>einer</strong> Hauptanwendung. Zum Testen des RAMs wird der transparente<br />
Speichertest implementiert. Zum Testen des ROMs wird eine CRC-Prüfsumme (oder<br />
auch CRC-Signatur) verwendet.<br />
Außerdem wird ein Überblick über die ARM-Architektur (Grundwissen) und Anforderungen<br />
an sicherheitskritische Anwendungen gegeben.
Inhaltsverzeichnis 5<br />
Inhaltsverzeichnis<br />
Danksagung...................................................................................................................2<br />
Erklärung .......................................................................................................................3<br />
Kurzfassung ..................................................................................................................4<br />
Inhaltsverzeichnis.........................................................................................................5<br />
1 Einleitung............................................................................................................7<br />
1.1 Zielsetzung / Motivation .......................................................................................7<br />
1.2 Aufbau der Thesis................................................................................................8<br />
1.3 Stand der Technik................................................................................................8<br />
1.4 Abgrenzung: Stand der Technik und eingeschlagener Realisierungsweg...........9<br />
2 Grundlagen.......................................................................................................10<br />
2.1 Aufbau der Hardware.........................................................................................10<br />
2.1.1 ARM-Architektur.................................................................................................10<br />
2.1.2 Das Evaluationsboard MCB2140 von Keil .........................................................12<br />
2.2 Entwicklungsumgebung HITOP 5.2 ...................................................................23<br />
2.3 Anforderungen an sicherheitsgerichtete Systeme .............................................24<br />
2.4 Fehler.................................................................................................................25<br />
2.5 Tests und Testverfahren ....................................................................................27<br />
2.5.1 CPU-Tests .........................................................................................................28<br />
2.5.2 RAM/ROM-Fehler ..............................................................................................29<br />
2.5.3 RAM- und ROM-Testverfahren ..........................................................................31<br />
2.5.4 Ein-/Ausgabe Test .............................................................................................34<br />
3 Anforderungsanalyse und –definition ...........................................................36<br />
3.1 Zielbestimmung..................................................................................................36<br />
3.1.1 Musskriterien......................................................................................................36<br />
3.1.2 Kannkriterien......................................................................................................36<br />
3.1.3 Abgrenzungskriterien .........................................................................................37<br />
3.2 Bibliothekseinsatz ..............................................................................................37<br />
3.2.1 Anwendungsbereiche ........................................................................................37<br />
3.2.2 Zielgruppen ........................................................................................................37<br />
3.3 Bibliotheksfunktionen .........................................................................................37<br />
3.4 Bibliotheksleistungen .........................................................................................38<br />
3.5 Technische Bibliotheksumgebung .....................................................................38<br />
3.5.1 Software.............................................................................................................38<br />
3.5.2 Hardware ...........................................................................................................38<br />
4 Konzept und Implementierung .......................................................................39
Inhaltsverzeichnis 6<br />
4.1 Software.............................................................................................................39<br />
4.1.1 Programmablauf ................................................................................................39<br />
4.1.2 Watchdog-Test...................................................................................................40<br />
4.1.3 Register-Test .....................................................................................................41<br />
4.1.4 CPU-Test ...........................................................................................................43<br />
4.1.5 RAM-Test...........................................................................................................47<br />
4.1.6 Ein-/Ausgabe Test .............................................................................................49<br />
4.1.7 ROM-Test ..........................................................................................................50<br />
4.1.8 Timer-Test..........................................................................................................51<br />
4.1.9 Zeitscheibenverfahren .......................................................................................51<br />
5 Validation..........................................................................................................53<br />
6 Fazit und Ausblick ...........................................................................................55<br />
Literaturverzeichnis....................................................................................................56<br />
Abbildungsverzeichnis...............................................................................................58<br />
Tabellenverzeichnis....................................................................................................60<br />
Anhang A: Tests..........................................................................................................61<br />
Anhang B: Entwicklungsumgebung HITOP 5.2 .......................................................69<br />
Abkürzungsverzeichnis..............................................................................................72
1 Einleitung 7<br />
1 Einleitung<br />
Während in der heutigen Welt Mikrokontroller, die ihre Dienste in Bereichen wie Consumer<br />
Elektronik, Industrie, Fahrzeugtechnik, Luft- und Raumfahrtechnik, sowie in vielen<br />
anderen Sparten erbringen, immer mehr Aufgaben übernehmen, steigen auch die<br />
Sicherheitsanforderungen, falls sie sicherheitskritische Aufgaben erbringen müssen. Zu<br />
diesen Aufgaben zählen z.B. in der Fahrzeugtechnik ABS 1 - und ESP 2 -Steuerung, in der<br />
Industrie die Steuerung von Robotern, die zusammen mit Menschen arbeiten. Eine der<br />
wichtigsten Aspekte der <strong>sicherheitsrelevante</strong>n oder auch sicherheitskritischen Anwendungen<br />
ist es, zu einem gewissen Grad sicherzustellen, dass die Hardware, auf der diese<br />
Anwendungen ausgeführt werden, nicht fehlerhaft ist und dass auch zur Laufzeit keine<br />
Fehler auftreten. Falls infolge z.B. externer Einwirkungen oder auch Materialermüdung<br />
Fehler in der Hardware auftreten, soll in vorgegebener Weise auf diese reagiert<br />
werden. Eine der Möglichkeiten Fehler in der Hardware aufzudecken ist es, bestimmte<br />
hardwarespezifische Selbsttests durchzuführen. Zu diesen grundlegenden Tests gehört<br />
unter anderem z.B. ein Arbeitspeicher-Test.<br />
1.1 Zielsetzung / Motivation<br />
Ziel dieser Thesis ist es, eine vorhandene Bibliothek, die der Fehleraufdeckung und<br />
Fehlerbeherrschung dient, eingehend zu untersuchen und weiter zu entwickeln. Die<br />
entwickelten Tests können dann in sicherheitskritische Anwendungen eingebunden werden<br />
und im Hintergrund laufen. Alle Tests sollen, gemeinsam oder einzeln, nicht mehr<br />
als ein Drittel 3 der Ausführungszeit am Stück die CPU belegen. Es soll ein möglichst<br />
vollständiger Testsatz entstehen, der einen Fehleraufdeckungsgrad von mindestens<br />
90% ermöglicht. Die Bibliothek wird <strong>für</strong> das Evalutionsboard MCB2140 von Keil, das<br />
eine LPC2148-CPU von Philips (heute NXP) besitzt, die zur „ARM7TDMI“-Familie gehört,<br />
entwickelt, ist aber auf viele andere µController die zur Philips LPC2xxx Familie<br />
gehören portierbar. Außer der Philips µControllern können auch µController anderer<br />
Hersteller getestet werden, aber nur wenn diese über eine „ARM7TDMI“-CPU verfügen.<br />
Auf diesen µControllern werden der CPU- und der Register-Test mit sehr hoher Wahrscheinlichkeit<br />
ohne Einschränkungen laufen. Die anderen Tests müssen angepasst werden.<br />
Im Vordergrund dieser Thesis lag die Idee; erworbene Kenntnisse der Lehrveranstaltungen<br />
„Grundlagen eingebetteter Systeme“ sowie „Designmethodik zuverlässiger Systeme“<br />
in der Praxis zu vertiefen. Außerdem werden die Ergebnisse dieser Thesis zur Lehre<br />
dieser Fächer zur Verfügung gestellt.<br />
1 Anti Blockier System<br />
2 Elektronisches Stabilitätsprogramm<br />
3 z.B. bei Ausführungszeit von <strong>einer</strong> Sekunde wären es ~330ms
1 Einleitung 8<br />
Die Entscheidung eine Bibliothek <strong>für</strong> einen µController, der auf einem „ARM7TDMI“ 32-<br />
Bit Prozessor basiert zu entwickeln, wurde durch folgende Gründe beeinflusst. Als erster<br />
Grund hier<strong>für</strong> dient die Tatsache, dass ARM-Prozessoren in bestimmten Marktsegmenten<br />
sehr große Marktanteile besitzen. Deshalb entstand die Frage, ob es möglich wäre<br />
sicherheitskritische Anwendungen auf diesen µControllern auszuführen. Als zweiter<br />
Grund kann die Tatsache angesehen werden, dass während des Studiums nur mit<br />
µControllern, die 8-Bit bzw. mit 16-Bit Prozessoren besitzen, gearbeitet wurde. Deswegen<br />
dient diese Thesis auch als Einstieg in den 32-Bit µController-Welt. Zudem wurden<br />
die Selbsttests z.B. im BGIA (Berufgenossenschaftliches Institut <strong>für</strong> Arbeitschutz)-Report<br />
7/2006 <strong>für</strong> den 80C537 von Siemens, der eine 8-Bit CPU besitzt, entwickelt [BGIA706].<br />
Es bleibt noch hinzuzufügen, dass, obwohl eigentlich einzelne Testmethoden <strong>für</strong> Speicher<br />
oder CPU vorhanden sind und implementiert wurden, zu kompletten Testroutinen<br />
gibt. Ausnahmen bilden [BGIA706] und [TUR05].<br />
1.2 Aufbau der Thesis<br />
Für fast jedes Projekt sind festgelegte Anforderungen sehr wichtig. Deswegen werden in<br />
dieser Thesis im Kapitel 2 Grundlagen der Sicherheitstechnik, Besonderheiten der ARM-<br />
Architektur sowie Tests und Testverfahren vorgestellt. Basierend auf diesen Informationen,<br />
bilden im Kapitel 3 Anforderungen an eine Bibliothek festgelegt und anhand derer<br />
die Bibliothek im Kapitel 4 entworfen und im Kapitel 5 implementiert. Im Kapitel 6 werden<br />
die implementierten Methoden getestet, sowie deren Ausführungszeiten gemessen. Abschließend<br />
wird ein Fazit gezogen.<br />
1.3 Stand der Technik<br />
Als Ausgangsbasis <strong>für</strong> diese Thesis dient ein Prototyp <strong>einer</strong> <strong>Softwarebibliothek</strong>, der einige<br />
Selbsttest beinhaltet. Dieser Prototyp wurde im Fachbereich <strong>für</strong> interne Benutzung<br />
entworfen. Zu den Tests, die in der Bibliothek enthalten sind, zählen: Register-, Arbeitspeicher(RAM)-,<br />
Programmspeicher(ROM)-, Watchdog- und CPU-Test, wobei bei diesem<br />
Test nur einige Befehle getestet wurden. Diese Bibliothek wird überarbeitet und<br />
weiter entwickelt. Sehr viele Grundgedanken und Ideen sind in [BGIA706] und [TUR05]<br />
erläutert.<br />
Der in der Bibliothek vorhandene Register-Test basiert auf so genannten „Walking Bit<br />
Pattern“-Verfahren. Für den Arbeitsspeicher–Test wurden zwei verschiedene Methoden<br />
implementiert: Als erstes ein transparenter Speichertest und zweitens ein „March X“-<br />
Test. Dies hatte zum Ziel, Unterschiede in Ausführungsgeschwindigkeit und Fehleraufdeckungsgrad<br />
zu ermittelt. Beim Programmspeicher-Test wird beim Start eine 32-Bit<br />
lange Signatur(CRC 4 ) gebildet, dann im Betrieb in bestimmten Zeitintervallen eine neue<br />
berechnet und mit dem Anfangswert verglichen. Grundgedanke des implementierten<br />
4 CRC – Cyclic Redundancy Check
1 Einleitung 9<br />
CPU-Tests ist es, Befehle der CPU mit bestimmten Testwerten durchzuführen und die<br />
Ergebnisse mit Erwartungswerten zu vergleichen.<br />
Die Bibliothek wurde zum Testen der Hardware entworfen und benutzt. Fehler in der<br />
Software werden nicht aufgedeckt.<br />
1.4 Abgrenzung: Stand der Technik und eingeschlagener<br />
Realisierungsweg<br />
Watchdog-, Register- und ROM-Test werden im Wesentlichen von der Bibliothek übernommen.<br />
Nur die Feinheiten werden überarbeitet:<br />
• beim Register-Test wird anstelle von <strong>einer</strong> Multiplikation, eine Schiebeoperation<br />
benutzt<br />
• beim ROM-Test anstelle <strong>einer</strong> 16-Bit eine 32-Bit lange Signatur benötigt, was eine<br />
größere Fehleraufdeckung ermöglicht<br />
Im Falle des RAM-Tests wird eine der beiden implementierten Methoden ausgewählt<br />
und weiterentwickelt. Es kommt ebenfalls eine 32-Bit-Signatur zum Einsatz. Wie auch im<br />
vorhandenen Test wird im überarbeiteten kein Laufzeitstack überprüft. Der CPU-Test<br />
wird auf den ganzen Befehlsatz erweitert, womit eine hinreichend große Fehlerfreiheit<br />
gewährleistet wird.<br />
Zur Bibliothek wird ein Test der Ein-/Ausgabeports hinzugefügt. Zudem werden Digital-<br />
Analog- und Analog-Digital-Umsetzer getestet. Da in der Bibliothek ein so genanntes<br />
Zeitscheiben-Verfahren zum Einsatz kommt, wird auch der Timer getestet.<br />
Da <strong>für</strong> diese Thesis eine bestimmte Anzahl von Stunden zur Verfügung steht, wurde<br />
entschieden nur die obengenannten Tests, die zu den grundlegenden Tests gehören, zu<br />
entwickeln. Werden zusätzliche Funktionseinheiten des Kontrollers verwendet, müssen<br />
diese natürlich ebenfalls getestet werden.
2 Grundlagen 10<br />
2 Grundlagen<br />
Das Grundlagenkapitel beschreibt <strong>für</strong> die Arbeit genutztes Prozessorboard, die Entwicklungsumgebung,<br />
die Grundlagen der Sicherheitstechnik, sowie die Selbsttestmethoden.<br />
2.1 Aufbau der Hardware<br />
In diesem Kapitel wird auf Besonderheiten der ARM-Architektur eingegangen.<br />
2.1.1 ARM-Architektur<br />
Bevor die ARM-Architektur detailliert beschrieben wird, werden zunächst die Begriffe<br />
CISC und RISC erklärt. Diese Begriffe sind hier deswegen wichtig, weil die ARM-<br />
Prozessoren sich von der Mehrheit auf dem Markt vorhandenen Prozessoren unterscheiden.<br />
Die meisten Mikroprozessoren sind heutzutage „Universalprozessoren“, die<br />
über einen umfangreichen Befehlssatz verfügen. Diese Prozessoren besitzen einige<br />
hunderte Befehle in unterschiedlichen Formaten, Dutzende von Adressierungsarten,<br />
sowie unterschiedliche Datentypen. Diese zählen zu so genannten CISC-Prozessoren,<br />
also „Complex Instruction Set Computer“. Die Realisierung dieser Prozessoren ist mit<br />
einigen technischen sowie ökonomischen Problemen verbunden, wie z.B.:<br />
• Ein großer Befehlssatz mit verschiedenen Adressierungsarten bedarf eines sehr<br />
komplexen Steuerwerks. Große Komplexität kann Fehler hervorrufen. Zudem<br />
wird <strong>für</strong> das Steuerwerk viel Chipfläche benötigt.<br />
• Da die Befehle komplex sind, werden <strong>für</strong> gleiche Befehle meist unterschiedliche<br />
Ausführungszeiten benötigt. Dies bedeutet, dass eine vollständige Pipeline<br />
(„Fließbandverarbeitung“ [BEC03]) nur mit einem hohen Aufwand realisierbar<br />
und in der Regel nicht effizient ist.<br />
• Es werden effiziente Compiler benötigt [vgl. BEC03].<br />
Aus <strong>einer</strong> Studie von IBM in den frühen 70iger Jahren wurde bekannt, dass die meisten<br />
Befehle des Befehlssatzes eines IBM-Minicomputers gerade einmal zu 1% zum Einsatz<br />
in einem Standardprogramm kamen, der von einem Compiler erzeugt wurde. Als Resultat<br />
dieser Studie wurde folgendes ersichtlich: Reduzierung eines Befehlsatzes auf ein<br />
Minimum und Festverdrahtung einzelner Befehle in einem Schaltwerk. Das war die „Geburtsstunde“<br />
der RISC-Architektur (Reduced Instruction Set Computer). Die Grundidee<br />
eines RISC-Prozessors ist es, den möglichst größten Teil der Befehle in einem Taktzyklus<br />
ausführen zu können [vgl. WAL04].<br />
Die Grenzen zwischen CISC- und RISC-Prozessoren sind fließend zu verstehen und<br />
der Unterschied zwischen den beiden wird in letzter Zeit immer kl<strong>einer</strong>. Zum Beispiel<br />
benutzte auch Intel in s<strong>einer</strong> 486-Prozessorlinie einen RISC-Kern, der die einfachsten<br />
Befehle ausführte, die komplexeren wurden dann vom CISC-Kern bearbeitet. Da aber
2 Grundlagen 11<br />
die RISC-Prozessoren weiterentwickelt wurden, ähneln sie jetzt den CISC-Prozessoren.<br />
RISC-Prozessoren ebenso wie CISC-Prozessoren auch „Universalprozessoren“, die in<br />
vielen Branchen zum Einsatz kommen, wie z.B. PDAs oder Spielkonsolen, auch deswegen,<br />
weil sie stromsparend sind. Für die meisten RISC-Prozessoren gelten weitere<br />
Merkmale [vgl. BEC03]:<br />
• Die Komplexität des Steuerwerkes ist um ein vielfaches reduziert.<br />
o Es wird ein relativ kl<strong>einer</strong> Befehlsatz (30-100 Befehle) verwendet.<br />
o Speicherzugriff nur über LOAD- und STORE-Befehle, grundsätzlich wird<br />
mit Registern gearbeitet .<br />
o Bevorzugt wird das 3-Adress-Format (Opcode / Source1/ Source2/<br />
Destination).<br />
o Ganzzahlige Datentypen (Byte, Wort, Doppelwort).<br />
o Ausführung aller Befehle möglichst in einem Taktzyklus.<br />
• Durch diese Maßnahmen erreicht man ein einfaches, festverdrahtetes Steuerwerk.<br />
• Alle Datenwege sind 32-Bit breit.<br />
• Getrennte Pfade <strong>für</strong> Daten- und Programmspeicher (Harward-Architektur).<br />
• Relativ viele 32-Bit-Register.<br />
• Befehlsverarbeitung durch eine vollständige, lineare Pipeline(meist 3-stufig).<br />
Pipeline-Verarbeitung ist <strong>für</strong> die RISC-Prozessoren sehr wichtig und bedeutet die Zerlegung<br />
eines Befehls in Einzelschritte. Im Falle <strong>einer</strong> 3-stufigen Pipeline wird ein Befehl in<br />
drei Einzelschritte zerlegt [WAL04]: „1. Befehl aus dem Speicher holen (Instruction<br />
Fetch), 2. Befehl decodieren (Instruction Decode), 3. Befehl ausführen (Instruction Execute)“.<br />
Wobei die einzelnen Schritte dieser Pipeline in mehreren Schritten ausgeführt<br />
sein können, je nach Instruktionskomplexität. Das Funktionsprinzip zeigt die Abbildung<br />
1 (hier sind die einzelnen Schritte in einem Taktzyklus ausführbar):<br />
Abbildung 1: 3-stufige Pipeline<br />
Die Funktionsweise <strong>einer</strong> 3-stufigen Pipeline ist folgende: Während im zweiten Zyklus(Cycle<br />
2) der 1. Befehl (Instruction 1) dekodiert (Decode) wird, werden in der zweiten<br />
Stufe der Pipeline bereits die Instruktionen <strong>für</strong> den zweiten Befehl (Instruction 2) geholt.<br />
In drittem Zyklus (Cycle 3) wird der 1. Befehl ausgeführt (Execute), der 2. Befehl decodiert<br />
und Instruktionen <strong>für</strong> den 3. Befehl (Intruction 3) geholt usw. Sind die einzelnen<br />
Befehle einfache Befehle, z.B. logische, so werden sie in dieser Pipeline in einem Takt-
2 Grundlagen 12<br />
zyklus ausgeführt. Aus der Tatsache, dass die meisten Befehle eines RISC-Prozessors<br />
in einem Taktzyklus ausführbar sind und <strong>für</strong> jede Stufe der Pipeline ein anderes bestimmtes<br />
Stück Hardware verantwortlich ist, bewirkt die Pipeline eine parallele Bearbeitung<br />
eines Befehls in mehreren Schritten. Das Prinzip der Pipeline ist dem des Fließbands<br />
ähnlich, z.B. bei der Autoherstellung.<br />
Die ARM-Prozessoren basieren auf <strong>einer</strong> RISC-Architektur. Die inzwischen inoffizielle<br />
Abkürzung „ARM“ steht <strong>für</strong> „Advanced RISC Machine“ oder auch „Acorn RISC Machine“.<br />
ARM ist das Warenzeichen der britischen Firma ARM Limited, die aus Acorn Computer<br />
Limited entstand. Die ARM Limited ist so zusagen eine „Prozessorschmiede“. Sie<br />
handelt eigentlich nur mit CPU-Lizenzen, „die einem ARM-Kunden das Recht einräumen,<br />
ein IC mit <strong>einer</strong> integrierten ARM-CPU zu entwickeln, anzufertigen(oder anfertigen<br />
zulassen) und zu verkaufen“ [WAL04].<br />
2.1.2 Das Evaluationsboard MCB2140 von Keil<br />
In dieser Thesis wurde auf dem MCB2140 Evaluation Board von KEIL der ARM Company<br />
mit der ARM7TDMI-CPU LPC2148 von Philips gearbeitet.<br />
Abbildung 2: Evaluation Board MCB2140<br />
Der µController besitzt;<br />
• die Philips LPC2148 16/32-Bit-CPU, basierend auf der ARM7TDMI-S-Familie mit<br />
16-Bit langem Thumb-Mode (spezieller Befehlsatz) Unterstützung, 12 MHz<br />
Quarzfrequenz, CPU-Frequenz bis zu 60 MHz,<br />
• ein 32 KByte On-Chip static RAM, sowie 512 KByte On-Chip Flash-Speicher<br />
(auch ROM oder Programmspeicher genannt), 128-Bit lange Speicheranbindung,<br />
• bis zu 45 Ein-/Ausgabe Pins, 8 LEDs; zwei serielle Ports (UART), zwei Fast I²C-<br />
Busse, sowie ein USB- und ein SD-Card-Interface,
2 Grundlagen 13<br />
• zwei 10-Bit A/D-Wandler mit insgesamt 14 Kanälen und Konvertierungszeiten<br />
von etwa 2,5µs pro Kanal,<br />
• ein 10-Bit D/A-Wandler,<br />
• zwei 32-Bit Timer/Counter, zwei PWM und ein Watchdog-Timer,<br />
• Stromversorgung erfolgt via USB, 5V DC(Gleichstrom),<br />
• ein JTAG-Interface.<br />
Um den µController vom PC aus zu programmieren, sowie zu debuggen wird dieser<br />
über ein JTAG-Interface an das Tantino Debug Tool angeschlossen. Das Tantino wird<br />
über USB an den PC angeschlossen.<br />
Abbildung 3: Tantino <strong>für</strong> ARM7-9<br />
Dieses Debugger Tool unterstützt die schnelle Flash-Programmierung, schnelles Programmdownload<br />
mit bis zu 180 KByte/s, sowie eine Ausführungskontrolle wie<br />
Run/Stopp, schrittweise Ausführung, und die Möglichkeit Breakpoints und Watchpoints<br />
zu setzen.<br />
2.1.2.1 LPC2148 CPU-Core<br />
Die Philips LPC2148 gehört zu der ARM7TDMI-Familie, deren Prozessoren übersichtlich<br />
gestaltet sind. Sie benutzen relativ wenig Siliziumfläche und haben deswegen einen<br />
geringen Stromverbrauch. Die Abbildung 4 zeigt die Blockschaltung des ARM7TDMI-<br />
Cores:
2 Grundlagen 14<br />
Abbildung 4: ARM7TDMI main processor logic [ARM7]<br />
Die wichtigsten Funktionseinheiten sind [vgl. WAL04]:<br />
• Adress Register:<br />
Dieses enthält die Speicheradresse, auf die die CPU zugreifen soll<br />
• Adress Incrementer: Diese Funktionseinheit inkrementiert die 32-Bit-Adresse.<br />
Da aber der Speicher eine Byte-Struktur besitzt. Eine Adresse wird wie folgt inkrementiert:<br />
neue Adresse = alte Adresse +4<br />
• Register Bank: Die 32-Bit-Register sind hier zusammengefasst, was bei der Befehlsverarbeitung<br />
eine große Rolle spielt.<br />
• Multiplier:<br />
Mit Hilfe festverdrahteter Logik führt dieser schnelle Multiplikationen durch.<br />
• Barrel Shifter:<br />
Spezielles Schieberegister, das eine Verschiebung um mehrere Bits ermöglicht.<br />
• ALU: Arithmetical Logical Unit, das Rechenwerk.<br />
• Write Data Register und Read Data Register: durch diese Register geschehen<br />
Schreib- und Lesezugriffe auf Daten.<br />
• Instuction Decoder/Control Logic: Decodierung sämtlicher Befehle und Steuerung<br />
der Ausführung von Befehlen.<br />
• Instruction Pipeline:<br />
Hier wird die oben beschriebene eine 3-stufige Pipeline realisiert.
2 Grundlagen 15<br />
Das genaue Funktionsprinzip kann aus Dokumentationen von der Webseite ARM Limited<br />
(www.arm.com) entnommen werden.<br />
Die gegebene CPU verfügt über eine 3-stufige Pipeline mit <strong>einer</strong> so genannten Loadand-Store<br />
Architektur. Die Besonderheit dabei ist, dass alle zum Berechnen benötigten<br />
Daten aus dem Speicher in Register kopiert (Load) und nach der Operation wieder in<br />
den Speicher zurück geschrieben (Store) werden (Abbildung 5). Dies bringt eine Steigerung<br />
der Performance mit sich, weil mit viel schnelleren Registern gearbeitet und deshalb<br />
nicht jedes Mal auf den langsamen Speicher zugegriffen wird.<br />
Register:<br />
Abbildung 5:Load-and-Store Prinzip [MAR06]<br />
Die ARM7TDMI-S CPU besitz eine Bank aus sechzehn 32-Bit langen Registers(Abbildung<br />
6) und einem Current Program Status Register(CPSR) (Abbildung 7). Die<br />
Register R0-R12 sind benutzerspezifische Register (User Register) und besitzen keine<br />
speziellen Funktionen. Die R13-R15 hingegen sind so genannte Special Function Register<br />
und haben bestimmte Funktionen zu erfüllen. Register R13 hat die Funktion des<br />
Stack Pointers, R14 des Link Registers. In R14 wird die Rücksprungadresse<br />
(siehe s. 20) gespeichert. R15 ist der Programmcounter.<br />
Das Current Program Status Register(CPSR) erfüllt folgende Funktionen:<br />
• In den Bits 28-31 des Registers stehen die Statusflags (Negative, Zero, Carry<br />
und Overflow). Die Statusflags-Bits werden benutzt, um logische und arithmetische<br />
Befehle unter bestimmten Bedienungen durchzuführen.<br />
• Mit Hilfe von Bit 6 und 7 werden Interrupts 5 ein- oder ausgeschaltet.<br />
• Mit Hilfe von Bits 0-4 wird zwischen den Benutzungsmodi umgeschaltet.<br />
5 IRQ(Interrupt Request) sowie FIQ(Fast Interrupt Request)
2 Grundlagen 16<br />
Benutzungsmodi:<br />
Abbildung 6: Registerbank [MAR06]<br />
Abbildung 7: Current Program Status Register ([LPC2148])<br />
Die CPU hat sechs Benutzungsmodi, wie die Abbildung 8 zeigt. Im Normalfall laufen die<br />
Anwendungen im „User“-Betrieb. Bei einem Ausnahmefall z. B. bei einem Interrupt,<br />
wechselt der Prozessor in einen anderen Betriebsmodus über. In diesem Fall haben die<br />
Register R0-R12 und R15 die gleichen Funktionen, die R13 und R14 werden hingegen<br />
durch einzigartige Paare von Registern, die <strong>für</strong> jeden Modus verschieden sind, ausgetauscht.<br />
Zudem kommt ein weiteres Register namens Saved Programm Status Register<br />
(SPSR) zum Einsatz. In diesem wird der Wert des CPSR beim Wechsel gespeichert und<br />
beim Zurückkehren in den „User“-Modus zurück geschrieben.<br />
Das 5. Bit des CPSR’s symbolisiert in welchem Instruktionssatz sich der Prozessor gerade<br />
befindet; im ARM- oder THUMB-Satz 6 . Der Unterschied dabei ist: der ARM-Satz ist<br />
32-Bit lang und der THUMB 16-Bit lang. Außerdem werden im THUMB-Satz nicht alle<br />
Register benutzt, wie es die Abbildung 9 zeigt, sondern nur R0-R7 der Benutzer-<br />
Registern (so genante „untere Register“).<br />
6 wird hier nicht weiter behandelt, kann aber im [umPhilips] nachgelesen werden
2 Grundlagen 17<br />
Befehlsatz:<br />
Abbildung 8: ARM Benutzungsmodi ([LPC2148])<br />
Abbildung 9: Benutzung von Registern im THUMB-Satz([LPC2148])<br />
Eine der interessantesten Besonderheit des ARM Instruktionssatzes ist, dass fast jeder<br />
Befehl bedingt ausgeführt werden kann. Dies ist dadurch möglich, dass die Bits 28-31<br />
des 32-Bit langen Befehls (Abbildung 10) <strong>für</strong> Bedienungspräfixe benutzt werden, wie<br />
beim CPRS. Assemblerbefehle können mit 16 möglichen Bedienungspräfixen ergänzt<br />
werden. Diese zeigt die Tabelle 1 (siehe s. 20).
2 Grundlagen 18<br />
Zum Beispiel wird der Befehl:<br />
EQMOV R1, #0x00080000<br />
nur ausgeführt, falls das Ergebnis des vorherigen Befehls gleich war und das Z-Flag im<br />
CPSR permanent gesetzt wurde.<br />
Die ARM7TDMI-S CPU hat folgende sechs Gruppen von Befehlen:<br />
• Sprung (Branching)<br />
• Datenverarbeitung (Data Processing)<br />
• Datentransfer (Data Transfer)<br />
• Blocktransfer (Block Transfer)<br />
• Multiplikation (Multiply)<br />
• Software Interrupt<br />
Im Weiteren werden diese Gruppen näher betrachtet.<br />
Tabelle 1: Bedienungspräfixe [ARMREF]
2 Grundlagen 19<br />
Sprung (Branching)<br />
Abbildung 10: ARM-Instruktionssatz Formate [ARMREF]<br />
Der ARM7 verfügt über weitere Sprungbefehle:<br />
• B, BL Branch, Branch with Link<br />
• BLX Branch with Link and Exchange<br />
• BX Branch and Exchange<br />
Der Standardsprungbefehl B – Branch, sowie BL, erlaubt es vorwärts oder rückwärts um<br />
bis zu 32 MB weit zu springen, wobei BL – Branch with Link die Rücksprungadresse im<br />
Link Register R14 speichert. Das Funktionsprinzip zeigt Abbildung 11:<br />
Abbildung 11: Standartsprungbefehle [MAR06]
2 Grundlagen 20<br />
BLX(Branch with Link Exchange) und BL(Branch Exchange) haben die gleiche Funktionalität<br />
wie die B und BL, außerdem werden sie benutzt, um zwischen den ARM- und<br />
THUMB-Instruktionssatzen zu wechseln (Abbildung 12).<br />
Abbildung 12: Sprungbefehle BLX und BL [MAR06]<br />
Datenverarbeitende Befehle (Data Processing Instructions)<br />
Wie ein datenverarbeitender Befehl aussieht, zeigen die Abbildungen 13 und 14:<br />
Abbildung 13: Data Processing Instruction [MAR06]<br />
Abbildung 14: Data Processing Instruction [ARMREF]<br />
Jeder Befehl hat zwei Operanden und schreibt das Ergebnis in ein Register. Der erste<br />
Operand muss immer ein Register sein, der zweite hingegen ein Register oder eine Variable.<br />
Als Zusatz gibt es einen Barrel Shifter, dieser erlaubt es, den zweiten Operanden<br />
bitweise zu shiften. Das „S“-Bit wird benutzt um Statusflags zu kontrollieren. Die datenverarbeitenden<br />
Befehle sind in der Tabelle 2 aufgelistet.<br />
Zum Beispiel könnte folgende Anweisung:<br />
if (z==1) R1 = R2 + (R3 * 4)
2 Grundlagen 21<br />
so kompiliert werden:<br />
EQADDS R1,R2,R3,LSL #2<br />
Datentrasfer Befehle (Data Transfer)<br />
Tabelle 2:Datenbearbeitende Befehle [ARMREF]<br />
In den Tabellen 3 und 4 aufgelistete Befehle erlauben es signed und unsigned Words,<br />
Half Words und Bytes in (Load) Registern von dem Speicher zu schreiben und von (Store)<br />
Registern in den Speicher zu schreiben:<br />
Tabelle 3: Load- Befehle [ARM7]
2 Grundlagen 22<br />
Tabelle 4:Store- Befehle [ARM7]<br />
Wie aus den Tabellen zu ersehen ist, existiert nicht nur die Möglichkeit Daten<br />
zwischen einzelnen, sondern zwischen mehreren Registern zu bewegen, was<br />
Abbildung 15 zeigt:<br />
Abbildung 15: Bewegung von Daten zwischen mehreren Registern[MAR06]<br />
Multiplikation (Multiply)<br />
Zusätzlich zu einem Barrel Shifter besitzt die ARM7TDMI-S-CPU eine Multiply Accumulate<br />
Unit (MAC), diese wird <strong>für</strong> die Multiplikation von Integer und Long Integer benutzt.<br />
Bei <strong>einer</strong> Integer-Multiplikation werden zwei 32-Bit lange Integer-Zahlen multipliziert und<br />
das Ergebnis in ein 32-Bit-langes Register geschrieben (modulo 32). Bei <strong>einer</strong> Long Integer-Multiplikation<br />
werden zwei 32-Bit lange Integer-Zahlen multipliziert und das 64-Bitlange<br />
Ergebnis in zwei 32-Bit lange Register geschrieben. MAC-Befehle sind folgende:<br />
Mnemonik Bedeutung Resolution<br />
MUL Multiply 32 Bit Resultat<br />
MULA Multiply accumulate 32 Bit Resultat<br />
UMULL Unsigned multiply 64 Bit Resultat<br />
UMLAL Unsigned multiply accumulate 64 Bit Resultat<br />
SMULL Signed multiply 64 Bit Resultat<br />
SMLAL Signed multiply accumulate 64 Bit Resultat<br />
Tabelle 5: Die Multiplikationsbefehle
2 Grundlagen 23<br />
2.1.2.2 Speicher<br />
Weil der µController eine 32-Bit-CPU besitzt, verfügt der µController über einen 2³² = 4,0<br />
Gigabyte großen Adressraum, den die Abbildung 16 zeigt.<br />
Abbildung 16: LPC2148 Memory Map [LPC2148]<br />
Zur Verfügung stehen dem µController die Bereiche:<br />
• 0x0000 0000 – 0x0007 FFFF = 512 KB <strong>für</strong> den ROM / Programmspeicher<br />
• 0x4000 0000 – 0x4000 7FFF = 32 KB <strong>für</strong> den SRAM / Arbeitspeicher<br />
2.2 Entwicklungsumgebung HITOP 5.2<br />
Zum Entwickeln von Programmen <strong>für</strong> das Board LPC2148 wurde die Entwicklungsumgebung<br />
HITOP 5.2 von Hitex eingesetzt. Diese integrierte Entwicklungsumgebung<br />
(DIE) nutzt den GCC-Compiler <strong>für</strong> die Programmiersprache C und bietet dem Entwickler<br />
alle benötigten Funktionen, wie zum Beispiel: Kompilieren von Programmen und
2 Grundlagen 24<br />
übersichtliches Editorfenster. Über diese IDE geschieht das Downloaden von Programmen<br />
in den Flash-Speicher von µControllers. Außerdem werden verschiedene<br />
Funktionen zum Debuggen zur Verfügung gestellt, solche wie die schrittweise Ausführung<br />
eines Programms und die Möglichkeit die Breakpoints zu setzen. Es existieren<br />
auch Fenster mit Register-, und Speicherinhalten. Außerdem besteht die Möglichkeit<br />
verschiedene Variable zu verändern. Nähere Informationen befinden sich im<br />
Anhang B.<br />
Abbildung 17: Entwicklungsumgebung HITOP 5.2<br />
2.3 Anforderungen an sicherheitsgerichtete Systeme<br />
Ein System oder eine Maschine, die elektronisch gesteuert wird, soll als sicherheitskritisch<br />
bezeichnet werden, wenn von diesem oder dieser <strong>für</strong> Menschen und/oder Umwelt<br />
Gefahr ausgeht oder es im Falle eines Unfalls zu einem Schaden kommen kann. Ist das<br />
der Fall, muss geklärt werden was, wann und wie es gefährlich <strong>für</strong> einen Menschen oder<br />
die Umwelt werden kann. Die wichtigsten Kriterien hierbei sind Häufigkeit und Wahrscheinlichkeit<br />
des Auftretens des Schadens. Nach diesen Kriterien wird dann einem System<br />
eine Risikokategorie zugeordnet. Hierbei werden so genannte Risikographen genutzt<br />
z.B. die Risikographen aus den Normen EN 954-1 (Abbildung 18) oder IEC 61508<br />
(Safety Integrity Level, SIL).
2 Grundlagen 25<br />
Abbildung 18: Risikograph(EN 954-1)[GEH07]<br />
Nach erfolgter Gefährdungsanalyse wird <strong>für</strong> jede Gefährdung mit diesem Risikographen<br />
eine Risikoanalyse durchgeführt, um die erforderliche Risikoreduzierung zu bestimmen.<br />
Je nach dem in welche Kategorie ein System zugeordnet wird, müssen unterschiedliche<br />
Maßnahmen der Risikoreduzierung ergriffen werden, um den Anforderungen an diese<br />
Kategorie zu genügen. Die Maßnahmen können technischen und nicht technischen Charakter<br />
tragen. Je höher der Schaden, der infolge eines Fehler und/oder Ausfalls des Systems<br />
entstehen kann, und je höher die Kategorie des Systems, desto höher das Maß der<br />
zu ergreifenden Risikoreduzierung [BÖR04].<br />
Die Normen EN 954 „Sicherheit von Maschinen - Sicherheitsbezogene Teile von Steuerungen“<br />
sowie IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar<br />
elektronischer Systeme (E/E/PES)“ sind sehr wichtig<br />
bei dem Entwurf, der Konzipierung sowie der Entwicklung von sicherheitskritischen<br />
E/E/PES, da diese Normen grundlegende Informationen und Empfehlungen <strong>für</strong> die Arbeit<br />
mit E/E/PES enthalten.<br />
2.4 Fehler<br />
Um Fehler aufzudecken und behandeln zu können, muss verstanden werden, was eigentlich<br />
ein Fehler ist. In der Norm DIN 40041 wird ein Fehler wie folgt definiert:<br />
„Ein Fehler ist die Nichterfüllung vorgegebener Forderungen durch einen Merkmalswert.<br />
Ein Fehler ist also ein Zustand (z.B. auch ein falscher logischer Zustand)“<br />
Man kann Fehler allgemein in zwei Kategorien aufteilen[vgl. BÖR04]:<br />
• Physikalische Fehler (z.B. Hardwareausfall)<br />
• Funktionale Fehler (z.B. Softwareausfall)<br />
Aus Abbildung 19 ist zu sehen, dass Ausfälle <strong>einer</strong> Steuerung infolge eines Fehlers fast<br />
in allen „Lebensphasen“ eines Systems auftreten können.
2 Grundlagen 26<br />
Abbildung 19: Steuerungsversagen nach „Lebensphasen“ [330219]<br />
Die Ursachen <strong>für</strong> diese Ausfälle, betrachtet unter zeitlichem Aspekt, können entweder<br />
vor oder nach der Inbetriebnahme liegen. Als Beispiele können weitere Auflistungen<br />
dienen (nach [ISSA02]:<br />
vor der Inbetriebnahme:<br />
• Spezifikationsfehler<br />
• Dimensionierungsfehler<br />
• Programmierfehler<br />
nach der Inbetriebnahme:<br />
• Fehler im Speicher<br />
• Fehler in der CPU<br />
• Fehler in der Peripherie<br />
Gegen Fehler vor der Inbetriebnahme sollen die Maßnamen zur Fehlervermeidung ergriffen<br />
werden. Diese werden von Herstellen und Entwicklern durchgeführt. Gegen die<br />
Fehler nach der Inbetriebnahme sind die Maßnahmen der Fehlerbeherrschung anzuwenden.<br />
Gegenstand dieser Thesis ist die Fehlerbeherrschung, dabei fangen bestimmte<br />
Hard- und/oder Softwarebausteine Fehler während des Betriebs auf. Maßnahmen zur<br />
Fehlervermeidung können sein: Verwendung von Case-Tools, strukturierter Entwurf,<br />
Programmanalyse; zur Fehlerbeherrschung: redundante Soft- und Hardware, Speicher-,<br />
CPU- und E/A-Tests(vgl. [ISSA02]).<br />
Dass Software häufig fehlerhaft ist, ist bekannt, aber es muss auch erwähnt werden:<br />
keine Hardwarekomponente ist immer fehlerfrei. Sie kann entweder schon nach der<br />
Herstellung defekt sein oder es können Defekte während des nicht ordnungsgemäßen<br />
Betriebes auftreten oder infolge von Alterung. Jedes „Leben“ <strong>einer</strong> Hardwarekomponente<br />
lässt sich mit Weibull-Verteilung, auch „Badewannekurve“ genannt,<br />
(Abbildung 20) beschreiben:
2 Grundlagen 27<br />
Abbildung 20: „Badewannekurve“<br />
Der Bereich Nummer 2, also normaler Betrieb macht etwa 80% der Produktlebenszeit<br />
aus. Diese Abbildung ist wie folgt zu verstehen: Nach vielen Anfangsfehlern („Kinderkrankheiten“)<br />
folgt ein relativ zuverlässiger normaler Betrieb. Nach <strong>einer</strong> bestimmten<br />
Zeit, spezifisch <strong>für</strong> jede Komponente, häufen sich die Fehler infolge des Alterungsprozesses.<br />
Da ein zufälliger Fehler immer auftreten kann, müssen bei einem System, das<br />
sicherheitskritische Aufgaben ausführt, Hardwarekomponenten überprüft werden. Diese<br />
Prüfung oder auch Test sollte vor Inbetriebnahme, sowie während des Betriebes durchgeführt<br />
werden.<br />
2.5 Tests und Testverfahren<br />
Für ein System, das sicherheitskritische Aufgaben ausführt, sind Tests von großer Bedeutung.<br />
Aus diesem Anlass wurde versucht, ein allgemeines Prinzip der Fehleraufdeckung<br />
oder auch Tests zu formulieren (nach [HAL99]):<br />
„In einem beliebigen Verfahren zur Erkennung von Fehlern werden mindestens zwei<br />
Werte auf Erfüllung der zwischen diesen Werten vorgegebenen Zusammenhänge<br />
geprüft. Unzulässige Abweichungen von diesen Zusammenhängen werden als Fehler<br />
interpretiert.“<br />
Das allgemeine Prinzip zeigt die Abbildung 21. Die erhaltenen Werte x1, x2,…,xn, die<br />
durch die Verarbeitung der Einheiten E1,E2,…,En der Eingangswerte y1,y2,…,yn ermittelt<br />
wurden, werden von der Prüfeinheit auf den vorgegeben Zusammenhang geprüft.<br />
Falls der Zusammenhang nicht vorhanden ist, wird ein Fehler gemeldet.
2 Grundlagen 28<br />
Abbildung 21: Das allgemeine Fehlererkennungsprinzip[HAL99]<br />
Zwei Modifikationen dieses Prinzips sind die Plausibilitätsprüfung und der Vergleich. Bei<br />
der Plausibilitätsprüfung werden Werte auf Erfüllung des vorgegeben Zusammenhangs<br />
geprüft 7 . Bei einem Vergleich werden die Prüfwerte auf ihre Gleichheit geprüft 8 .<br />
2.5.1 CPU-Tests<br />
Eine CPU ist das Rechenwerk des µControllers; funktioniert es nicht richtig, ist die korrekte<br />
Funktion des sicherheitsgerichteten Systems unmöglich. Zudem ist es auch nicht<br />
möglich andere Selbsttests durchzuführen. CPU-Tests basieren auf dem Vergleichsprinzip<br />
der Fehleraufdeckung. Der Grundgedanke bei einem CPU-Test ist es: eine Operation<br />
mit vorgegebenen Testvariablen durchzuführen und dann Ist- mit Soll-Werten zu vergleichen.<br />
Wird eine Abweichung festgestellt, so wird auf dieses Ereignis in vordefinierter<br />
Weise reagiert, sei es eine Fehlermeldung oder eine steuerungstechnische Reaktion.<br />
Bei einem CPU-Test werden alle Befehle der CPU getestet. Diese können in folgende<br />
Gruppen aufgeteilt werden: arithmetische(z.B. ADD), logische(z.B. AND), Transferbefehle(z.B.<br />
MOV) sowie die Sprungbefehle.<br />
Die Arithmetikbefehle wie Addition oder Multiplikation sollen deswegen geprüft werden,<br />
da sie Berechnungen z. B. von neuen Koordinaten eines Roboterarms, der einem Menschen<br />
einen Gegenstand überreicht, benutzt werden.<br />
Die logischen Befehle müssen deswegen geprüft werden, da mit ihrer Hilfe meist Vergleiche<br />
durchgeführt werden. Funktionieren diese nicht richtig, kann eine falsche Entscheidung<br />
getroffen werden.<br />
Die Transferbefehle werden benutzt um Daten von und zum Speicher, sowie Registern<br />
zu bewegen. Funktionieren diese nicht richtig, werden trotz korrekter Funktion der restlichen<br />
Befehle falsche Ergebnisse erzielt. Dies kann natürlich zum Verlust der Sicherheitsfunktion<br />
führen.<br />
Die bedingten sowie unbedingten Sprünge werden z.B. in Schleifen oder als die Unterprogrammaufrufe<br />
benutzt. Die fehlerhafte Funktion bei <strong>einer</strong> Schleife kann zu <strong>einer</strong> endlosen<br />
Schleife führen. Bei einem Unterprogrammsprung kommt hinzu, dass überhaupt<br />
kein Sprung stattfinden kann. Diese Fehler werden durch den WD abgefangen.<br />
7<br />
z.B. wächst der Eingangswert, so soll auch der Ausgangswert wachsen<br />
8<br />
z.B. ein Operationsergebnis wird mit dem Sollergebnis verglichen
2 Grundlagen 29<br />
2.5.2 RAM/ROM-Fehler<br />
In diesem Kapitel werden die Fehler behandelt, die bei einen RAM auftreten können. Ein<br />
fehlerfreier RAM-Speicherbaustein soll in etwa wie folgt funktionieren:<br />
Abbildung 22: Zustandgraph eines fehlerfreien Speicherbausteins[RED98]<br />
„S0/1“ bedeutet eine Zelle mit dem Wert „0/1“, „w0/1“ ist der Übergang von „0-1/1-0“.<br />
Also muss eine Zelle ihren Zustand von „S0“(Zelleninhalt „0“) beim Übergang „w1“ in den<br />
Zustand „S1“(Zelleninhalt „1“) ändern und umgekehrt. Beim Übergang „w0“ aus dem<br />
Zustand „S0“ bleibt die Zelle in diesem Zustand, ebenfalls bleibt „S1“ beim Übergang<br />
„w1“ in diesem Zustand.<br />
In der Tabelle 6[HAM99] sind wesentliche funktionale Fehler eines RAMs aufgelistet.<br />
Diese Fehler können entweder einfache Fehler sein („Stack-at“), oder auch eine Menge<br />
an Fehlern, die unter einem Begriff aufgefasst werden („Adress Decoder Fault“).<br />
Tabelle 6: Funktionale Fehler eines RAMs [HAM99]<br />
Im Folgenden werden Fehlermodelle <strong>für</strong> das RAM vorgestellt.<br />
Der einfachste Fehler ist ein Haftfehler (Stuck-at Fehler, SAF). Ein Übergang von einem<br />
logischen Wert zu einem anderen ist unmöglich (die Zelle bleibt so zu sagen an einem<br />
Wert „haften“).
2 Grundlagen 30<br />
Abbildung 23: Zustandgraph eines SA0[RED98]<br />
Abbildung 24: Zustandgraph eines SA1[RED98]<br />
Ein weiterer Fehler ist ein Übergangsfehler (Transition Fault, TF). Eine Speicherzelle<br />
kann ihren Wert nicht von 0 nach 1 wechseln oder umgekehrt. Es gibt zwei Arten<br />
dieses Fehlers: 1.) Transition-Up-Fault (von „0“ nach „1“); 2.) Transition-Down-Fault(von<br />
„1“ nach „0“). Abbildung 26 zeigt ein Transition-Up-Fault:<br />
Abbildung 25: Zustandgraph eines Transition-Up-Faults[RED98]<br />
Der Koppelfehler (Coupling Fault, CF): Inhalt <strong>einer</strong> Zelle hängt von den Inhalten in anderen<br />
Zellen ab. Es gibt zwei Varianten dieses Fehlers: 1.) 2-Coupling Fault: zwei Zellen<br />
beeinflussen einander; 2.) k-Coupling-Fault: k-2 Zellen beeinflussen den Inhalt <strong>einer</strong><br />
Zelle. Außerdem existieren verschiedene Möglichkeiten wie eine Zelle beeinflusst werden<br />
kann 9 , z.B. wie Inversion Coupling Fault, Idempotent Coupling Fault, State Coupling<br />
Fault und Bridging Fault.<br />
Der Musterabhängige Fehler (Pattern Sensitive Fault, PSF): der Inhalt <strong>einer</strong> Zelle wird<br />
von anderen Zellen bestimmt. Es ist ein Sonderfall des k-Coupling-Fault, alle k-Zellen<br />
bestimmen den Übergang. In der Literatur wird die Betrachtung dieses Fehlers auf<br />
„Nachbarschaft“ „reduziert“. In diesem Fall spricht man von Neighborhood Pattern Sensitive<br />
Fault (NPSF). Es sind drei verschiedene Varianten von diesen Fehlern definiert<br />
[RED98]: 1.) Active Neighborhood Pattern Sensitive Fault; 2.) Passive Neighborhood<br />
Pattern Sensitive Fault; 3.) Static Neighborhood Pattern Sensitive Fault 10 .<br />
Der Adressdekodierfehler (Adress Decoder Fault, AF): es gibt vier verschiedene Adressdekodierfehler<br />
[RED98]:<br />
9 hier nicht weiter betrachtet, weiter führende Informationen in [RED98]<br />
10 hier nicht weiter betrachtet, weiter führende Informationen in [RED98]
2 Grundlagen 31<br />
1. Adresse zeigt auf keine Speicherzelle<br />
2. <strong>für</strong> eine Speicherzelle existiert keine Adresse<br />
3. an eine Adresse sind mehrere Speicherzellen gebunden<br />
4. mehrere Adressen sind an dieselbe Speicherzelle gebunden<br />
Die Tabelle 6[HAM99] zeigt den Zusammenhang der Fehlermodellen und der funktionalen<br />
Fehler eines RAMs:<br />
Tabelle 7: Zusammenhang der Fehlermodelle und funktionaler Fehler [HAM99]<br />
2.5.3 RAM- und ROM-Testverfahren<br />
Das RAM ist der Arbeitspeicher, in dem zur Laufzeit benötigte Daten gespeichert werden.<br />
Existiert ein Fehler im RAM so kann es zu <strong>einer</strong> Verfälschung der Daten kommen,<br />
was zu verheerenden Folgen führen kann.<br />
Es gibt verschiedene Möglichkeiten Fehler im RAM aufzudecken. In dieser Thesis werden<br />
deterministische Testverfahren behandelt, da sich <strong>für</strong> diese Tests leichter Aussagen<br />
über den Fehlerabdeckungsgrad treffen lassen. Nach [RED98] erreicht ein deterministischer<br />
Test, „von einem speziellen Fehler eines Fehlermodels ausgehend, eine Fehlerabdeckung<br />
von 100%. Alle erkennbaren Fehler werden detektiert.“ In dieser Thesis werden<br />
folgende Testalgorithmen betrachtet: March X Algorithmus 11 und transparenter Speichertest.<br />
11 da es in der vorhandenen Bibliothek schon implementiert wurde
2 Grundlagen 32<br />
March X Algorithmus: Dieser Test ist ein Vertreter der March-Tests, von denen mehrere<br />
existieren. Mit Hilfe dieses Testes werden alle Haftfehler, alle Übergangsfehler, alle<br />
Adressdecodierfehler und eine bestimmte Art von Koppelfehlern (Idempotent Coupling<br />
Fault) entdeckt. Die Komplexität aller March-Tests ist O(n), deswegen sind diese Tests<br />
sehr verbreitet bei SRAM-Tests [RED98]. Der March X Test wurde von [HAM99] entwickelt<br />
und sieht in Pseudo-Code folgendermaßen aus:<br />
Funktionsweise dieses Testes:<br />
1.) Gesamten Speicher mit „0“ beschreiben;<br />
for i in 0 to n-1 do<br />
A[i] := 0;<br />
end<br />
for i in 0 to n-1 do<br />
read A[i];<br />
compare (A[i],0);<br />
Branch FAULT if not equal;<br />
A[i] := 1;<br />
end<br />
for i in n-1 to 0 do<br />
read A[i];<br />
comp (A[i],1);<br />
Branch FAULT if not equal;<br />
A[i] := 0;<br />
end<br />
for i in 0 to n-1 do<br />
read A[i];<br />
comp (A[i],0);<br />
Branch FAULT if not equal;<br />
end<br />
2.) jede Speicherzelle lesen und mit „0“ vergleichen, wenn ungleich -> Fehler, ansonsten<br />
Speicherzelle invertieren;<br />
3.) jede Speicherzelle lesen und mit „1“ vergleichen, wenn ungleich -> Fehler, ansonsten<br />
Speicherzelle invertieren;<br />
4.) Schritt 2 wiederholen.<br />
Transparenter Speichertest: Dieser Test wurde vom BGIA entwickelt. Mit Hilfe dieses<br />
Testes werden alle Fehler aus der Tabelle 6 in einem RAM entdeckt. Das hat aber<br />
seinen Preis, der Test benötigt sehr viel Ausführungszeit. Der transparente Speichertest<br />
benutzt eine CRC-Prüfung(Cyclic-Redundancy-Check). Die Grundidee zur CRC Bildung<br />
ist eine Polynomdivision durch ein spezielles Generatorpolynom, der Rest dieser Division<br />
ist die Signatur.
2 Grundlagen 33<br />
Die Division sieht folgendermaßen aus:<br />
1. z.B. die binäre Zahl 1011 wird in Polynomform umgewandelt, also<br />
1*x 3 + 0*x 2 + 1*x 1 + 1*x 0 = x 3 + x 1 + x 0<br />
2. Das Generatorpolynom sei: x 2 + x 1<br />
3. x 3 + x 1 + x 0 : x 2 + x 1 = x 1 - 1<br />
- (x 3 + x 2 )<br />
-x 2 + x 1 + x 0<br />
2 1<br />
-( -x - x )<br />
x 0<br />
4. Rest ist x 0 -> ist die Signatur 01<br />
Die Funktionsweise des transparenten Speichertests[SCH97]:<br />
1.) Speicher wird in Segmente gleicher Größe eingeteilt (mind. 2 Byte);<br />
2.) es wird ein Testwort, Mindestlänge 1 Byte, genommen;<br />
3.) Über das Segment, in dem sich das Testwort befindet, wird eine Signatur gebildet<br />
(CRC-Prüfung), jedoch ohne des Testworts selbst, und eine <strong>für</strong> alle andere<br />
Segmente;<br />
4.) Das Testwort wird invertiert und es werden wieder Signaturen gebildet;<br />
5.) Die gebildeten Signaturen werden verglichen, bei Gleichheit wird das Testwort<br />
wieder invertiert und die Signaturen gebildet, ansonsten wird ein Fehler gemeldet;<br />
6.) Das Testwort selbst prüfen mit Hilfe des „Walking Bit“-Verfahrens: Inhalt des<br />
Wortes sichern, in alle Bits des Wortes „0“ schreiben, in das niederwertigste Bit<br />
„1“ schreiben und vergleichen, dann „1“ in das nächste Bit „schreiben“, bis das<br />
Wort wieder gleich Null ist. Am Ende des Tests das Testwort wiederherstellen.<br />
7.) Falls alles erfolgreich, Testwort um Länge des Worts verschieben und mit 3.)<br />
weiter bis Speicherende erreicht ist.<br />
Die Abbildung 26 [SCH97] zeigt das Funktionsprinzip des transparenten Speichertests.<br />
ROM-Testverfahren: ROM ist die Abkürzung <strong>für</strong> Read Only Memory, das heißt, dass in<br />
diesem Speicher das eigentliche Programm dauerhaft gespeichert und von hier ausgeführt<br />
wird. Während des Betriebs wird nichts in diesen Speicher geschrieben. Daraus<br />
folgt die Erkenntnis: der ROM-Inhalt muss immer gleich sein. Wenn vor Inbetriebnahme<br />
über das gesamte ROM eine Signatur gebildet worden ist, muss diese immer mit der<br />
neu gebildeten Signatur gleich bleiben, ansonsten ist ein Fehler im ROM aufgetreten.
2 Grundlagen 34<br />
Abbildung 26: Funktionsweise eines transparenten Speichertests<br />
2.5.4 Ein-/Ausgabe Test<br />
Funktionieren bei einem µController Eingabeports sowie analoge Eingänge nicht<br />
richtig, so kann er seine Umgebung nicht richtig wahrnehmen. Funktionieren die Ausgabeports<br />
sowie analoge Ausgänge nicht richtig, dann kann ein µController seine Peripherie<br />
nicht mehr angemessen ansteuern.<br />
Bei Ein-/Ausgabe-Tests muss nicht nur softwaremäßig, sondern auch hardwaremäßig<br />
getestet werden. Das heißt, dass erstens eine Routine zum Testen implementiert werden<br />
soll und zweitens die digitalen Ports aufgeteilt werden: eine Hälfte dient zuerst als<br />
Ausgang und die zweite als Eingang. Die beiden Hälften werden mit einander fest verdrahtet.<br />
Über die Ausgangsports wird eine Eins „geschoben“ und an den Eingansports<br />
geprüft, ob die Ports gesetzt konnten oder nicht.<br />
Fehler, die bei einem Analog-Digital-Wandler auftreten können, werden in statische und<br />
dynamische unterteilt. Zu den statischen Fehlern gehören z.B. der Quantisierungsfehler,<br />
integrale und differenzielle Nichtlinearität, zu den dynamischen z.B. die Verletzung des<br />
Abtasttheorems und dynamische Nichtlinearitäte. Weil diese Fehler sehr komplex sein<br />
können und jeweils geeignete Test um die Fehler aufzudecken und Maßnahmen die<br />
diese Fehler kompensieren benötigt werden, wurde die Entscheidung getroffen den Analog-Digital-Wandler<br />
auf seine plausible Funktionalität zu prüfen. Diese Entscheidung<br />
wurde im Wesentlichen durch folgende Erkenntnis beeinflusst: zum Testen des Wandlers<br />
stehen weniger als 50ms zu Verfügung und in dieser Zeit muss er auf seine korrekte<br />
Funktionalität geprüft werden. In dieser kurzen Zeit werden nicht die Typen der Fehler<br />
festgestellt, sondern das Vorhandensein eines Fehlers, was eigentlich das Ziel eines<br />
Selbsttests ist.
2 Grundlagen 35<br />
Bei den Tests von Analog-Digital (A/D)- und Digital-Analog (D/A)-Wandlern werden die<br />
beiden hardwaremäßig verbunden. Es wird die plausible Fehlererkennungsmethode<br />
angewendet. Die Grundidee: wird Wert am D/A erhöht, so muss sich auch eingelesener<br />
Wert am A/D erhöhen.
3 Anforderungsanalyse und –definition 36<br />
3 Anforderungsanalyse und –definition<br />
Die Anforderungsanalyse wird mit Hilfe der Erstellung eines Pflichtenheftes, dessen<br />
Struktur auf der Struktur eines Pflichtenheftes <strong>für</strong> die Fallstudie „Teach-Roboter“ von<br />
[BAL96] basiert, durchgeführt.<br />
3.1 Zielbestimmung<br />
Die Bibliothek soll dem Nutzer einen vollständigen Testsatz zur Verfügung stellen, der<br />
grundlegende Tests der Sicherheitstechnik <strong>für</strong> die µControllern der Philips LPC21xx<br />
Familie enthält.<br />
3.1.1 Musskriterien<br />
• Watchdog-Test: in der Bibliothek soll ein Watchdog-Test vorhanden sein<br />
• Register-Test: in der Bibliothek soll ein Test, der anhand des „Walking Bit“ Verfahrens<br />
die Register des CPU testet, vorhanden sein<br />
• CPU-Test: ebenfalls soll eine Funktion enthalten sein, die es ermöglicht logische,<br />
arithmetische, Transfer- sowie restliche Befehle der CPU zu testen<br />
• RAM-Test: die Bibliothek soll solch eine Funktion zur Verfügung stellen, die das<br />
RAM des µControllers mit <strong>einer</strong> der in dem Grundlagenkapitel genannten Methoden<br />
testet und folgende Fehler entdeckt:<br />
o beide Arten von Haftfehler<br />
o beide Arten von Übergangsfehlern<br />
o Koppelfehler<br />
o musterabhängige Fehler<br />
o Adressdekodierfehler<br />
• ROM-Test: Die Bibliothek soll einen ROM-Test durchführen können, der den<br />
Speicher mit Hilfe der CRC-Bildung prüft<br />
• Ein-/Ausgabe-Test: Mit Hilfe der Bibliothek soll ermöglicht werden Ports, sowie<br />
A/D und D/A-Wandler des µControllers zu testen<br />
• Timer-Test: Es soll eine Routine vorhanden sein, die den Timer von dem Evaluation<br />
Board auf seine korrekte Funktion testet.<br />
3.1.2 Kannkriterien<br />
Optional kann die Bibliothek weitere Funktionen enthalten, die;<br />
• den USB (Universal Serial Bus) testen
3 Anforderungsanalyse und –definition 37<br />
• den PWM (Pulse Width Modulator),<br />
• die Zeitscheibenverfahren realisieren.<br />
3.1.3 Abgrenzungskriterien<br />
• Keine Laufzeitstacküberprüfung: Es wird keine Funktion implementiert, die<br />
Laufzeitstack überprüft,<br />
• Keine weiterführende Tests: Es werden keine andere als obengenanten Tests<br />
implementiert.<br />
3.2 Bibliothekseinsatz<br />
Die Bibliothek ist als ein Prototyp gedacht und kann als Basis <strong>für</strong> eine Weiterentwicklung<br />
genommen werden, sowie als Lehrmaterial <strong>für</strong> Studierende des Schwerpunktes<br />
„Embedded Systems“ des Fachbereichs Informatik der Fachhochschule<br />
Bonn-Rhein-Sieg.<br />
3.2.1 Anwendungsbereiche<br />
Entwickelnde und forschende Labore des Fachbereichs Informatik der Fachhochschule<br />
Bonn-Rhein-Sieg, sowie andere Personen oder Firmen, die Interesse an der Bibliothek<br />
haben.<br />
3.2.2 Zielgruppen<br />
Zielgruppe sind in erster Linie Entwickler, die sich mit der Problematik sicherheitskritischer<br />
Systeme befassen, sowie die Studierenden der Informatik an der Fachhochschule<br />
Bonn-Rhein-Sieg.<br />
3.3 Bibliotheksfunktionen<br />
Die entworfene Bibliothek soll folgende Funktionen bieten:<br />
• Testen des Watchdog Timers<br />
• Testen der <strong>für</strong> den Benutzer verfügbaren internen Register der CPU<br />
• Testen der CPU des µControllers<br />
• Testen des RAM, wobei der zum Testen freiverfügbare Bereich des RAM in der<br />
Funktion festgelegt werden kann, sowie weitere Parameter wie<br />
Sektorgröße und Adresse des Prüfwortes<br />
• Testen des ROM<br />
• Testen von Ein-/Ausgabe Ports
3 Anforderungsanalyse und –definition 38<br />
• Testen der A/D- und D/A-Wandlers<br />
• Testen des Timers/Counters<br />
3.4 Bibliotheksleistungen<br />
90% Fehleraufdeckung bei allen Tests, falls die Hardware fehlerhaft ist.<br />
3.5 Technische Bibliotheksumgebung<br />
3.5.1 Software<br />
Um den µController von dem Computer aus zu programmieren, werden weitere Softwarekomponenten<br />
benötigt:<br />
• Windows XP, zum Ausführen der Entwicklungsumgebung HITOP 5.2<br />
• C-Compiler, bevorzugt GNU C Compiler for ARM<br />
• Assembler, bevorzugt arm-hitex-elf-as zum Assemblieren der Assembler<br />
Dateien<br />
• Linker, bevorzugt arm-hitex-elf-ld zum Linken der assemblierten Dateien<br />
• Downloadtool, zum Downloaden der Tests auf den Ziel-µController<br />
3.5.2 Hardware<br />
Zum Erstellen und Bearbeitung der Bibliothek wird weitere Hardware benötigt:<br />
• PC zum erstellen der Bibliothek. Minimale Systemanforderungen:<br />
o 1,0 GHz CPU oder schneller<br />
o 256 MB Arbeitspeicher oder mehr<br />
o 600 MB frei verfügbarer Platz auf der Festplatte<br />
• Debugger, bevorzugt Tantino zum Debuggen der Bibliothek<br />
• µController MCB2140 von Keil
4 Konzept und Implementierung 39<br />
4 Konzept und Implementierung<br />
In diesem Kapitel werden die Tests konzipiert und anschließend implementiert. Konzipiert<br />
wird anhand der in dem Kapitel Grundlagen vorgestellten Verfahren. Implementiert<br />
wird in der IDE HiTOP52 in der Programmiersprache C sowie in der Assemblersprache.<br />
4.1 Software<br />
Die Bibliothek ist modular aufgebaut, dadurch lässt sich jedes einzelne Modul viel leichter<br />
und schneller testen. Die Änderungen eines einzelnen Moduls sind viel leichter nachvollziehbar.<br />
Die Bibliothek lässt sich somit gut erweitern. Es besteht außerdem die Möglichkeit<br />
neue Tests hinzuzufügen.<br />
4.1.1 Programmablauf<br />
Bevor ein System, das sicherheitsgerichtete Aufgaben erbringt, in Betrieb genommen<br />
wird, soll zuerst sichergestellt werden, dass das System hinreichend fehlerfrei ist. Aus<br />
dieser Tatsache wird zuerst ein Anlauftest durchgeführt. Bei diesem Test werden alle zu<br />
testende Einheiten auf ihre korrekte Funktionalität geprüft. Da es sehr wichtig ist, dass<br />
die Sicherheit – so zu sagen – „Stück <strong>für</strong> Stück“ erreicht wird, werden zuerst die Komponenten<br />
getestet, ohne die die Durchführung von Tests gefährdet würde. Der Ablauf des<br />
Anlauftests ist folgender:<br />
1. Es werden die Sprung-Befehle der CPU getestet.<br />
2. Es wird ein Watchdog-Test ausgeführt.<br />
3. Es werden die internen Register getestet.<br />
4. Es werden weitere CPU-Befehle überprüft.<br />
5. ROM-Test.<br />
6. Timer-Test.<br />
7. I/O-Test.<br />
8. RAM-Test.<br />
Der Hintergrund dieser Reihenfolge ist folgender:<br />
• Sprung-Befehle werden bei dem WD benutzt, deswegen sollen diese vor dem<br />
WD-Test auf ihre korrekte Funktionalität überprüft werden.<br />
• Watchdog überprüft ob die CPU ihre Arbeit in <strong>einer</strong> bestimmten Zeit ausführen<br />
kann. So kann z.B. der Watchdog ein Programm aus <strong>einer</strong> Endlosschleife, so zu<br />
sagen, „herausholen“, in dem er den µController „resetet“.
4 Konzept und Implementierung 40<br />
• Die internen Register werden <strong>für</strong> die Zwischenspeicherung der Daten <strong>für</strong> Berechnungen<br />
in der CPU benötigt. Funktionieren diese nicht, z. B. existiert ein<br />
Haftfehler, dann würde auch eine fehlerfreie CPU falsche Resultate liefern.<br />
• Bei <strong>einer</strong> fehlerhaften CPU werden die Programme einfach falsch ausgeführt,<br />
was eine große Gefährdung mit sich bringt.<br />
• Im ROM werden Programme gespeichert, die von dem µController ausgeführt<br />
werden. Sind richtige Programme falsch eingespeichert, wird das richtige Programm<br />
falsch ausgeführt.<br />
• Der Timer wird benötigt um das Zeitscheibenverfahren zu realisieren. Funktioniert<br />
der Timer nicht richtig, so werden die Zeitscheiben falsch eingeteilt, was unvorhersehbare<br />
Auswirkungen als Folge haben kann.<br />
• Funktionieren die Eingänge oder Ausgänge eines µControllers nicht richtig und<br />
sind an diese Sensoren und Aktuatoren angeschlossen, kann der µController die<br />
Umgebung nicht richtig wahrnehmen, sowie seine Aufgabe nicht richtig ausführen,<br />
z.B. Bewegen eines Roboterarms.<br />
• Im RAM werden Daten, die <strong>für</strong> die Berechnung nicht gerade benötigt werden<br />
zwischengespeichert. Existiert ein Fehler im RAM werden anschließend <strong>für</strong> die<br />
Berechnung verfälschte Daten zurückgeliefert. Der RAM-Test wird als letzter gestartet,<br />
weil er am meisten Zeit braucht und in Zeitscheiben ausgeführt wird.<br />
Sind die Tests erfolgreich verlaufen, kann der µController „freigegeben“ werden. Im Betrieb<br />
wird ein Hintergrundtest ausgeführt. Die Besonderheit dabei ist, dass nur CPU-,<br />
Register-, Watchdog- und I/O-Tests vollständig ausgeführt werden, da diese schnell genug<br />
sind. RAM- und ROM-Test sind hingegen rechnerisch mit großem Aufwand verbunden<br />
und würden somit die Sicherheitsfunktion des µControllers gefährden, falls sie am<br />
Stück ausgeführt wurden. Deswegen werden die Speichertests in Zeitscheiben ausgeführt,<br />
was aber ihre Wirksamkeit nicht mindert.<br />
4.1.2 Watchdog-Test<br />
Konzept<br />
Als Ausgangsposition <strong>für</strong> die Entwicklung des Watchdog(WD)-Tests wurde das Verfahren<br />
des BGIA [SCH97] genommen. Der Test ist wie folgt definiert [vgl. DEMER]:<br />
1. Eine Variable wird eingerichtet ( im Programm „getestet“).<br />
2. WD wird initialisiert und gesetzt.<br />
3. Es wird eine Funktion definiert, die länger dauert als der WD (im Programm<br />
„wait_5ms“).<br />
4. Kurz vor dem Eingreifen des WD wird die Variable invertiert („getestet=1“)<br />
und nach dem Eingreifen wieder invertiert („getestet=0“).
4 Konzept und Implementierung 41<br />
5. Das Programm geht in eine Endlosschleife, falls die Variable nicht geändert<br />
wurde.<br />
Diesem Konzept entsprechend wird der WD-Test auch implementiert. Den Ablauf des<br />
WD-Tests zeigt die Abbildung 27:<br />
4.1.3 Register-Test<br />
Konzept<br />
Abbildung 27: Ablauf des WD-Tests<br />
Zum Testen der Register wird eine „laufende“ Eins verwendet auch Walking Bit genannt.<br />
Hierbei werden alle Bits eines Registers mit „0“ beschrieben und dann beginnend mit<br />
dem Bit 0 und bis zum 32-ten Bit eine „1“ „geschoben“. Abbildung 28 zeigt das Funktionsprinzip:<br />
Abbildung 28: Walking Bit
4 Konzept und Implementierung 42<br />
Es könnten auch bestimmte Zahlenmuster in die Register geschrieben werden. Üblich<br />
sind die Zahlen 0x55555555 12 und 0xAAAAAAAA, dies entspricht binär wechselnden<br />
Nullen und Einsen, also „010101..01“ und „101010…10“. Mit diesen Mustern werden<br />
zwar alle Haftfehler und Übergangsfehler 13 entdeckt, aber nicht alle Koppelfehler 14 . Der<br />
Vorteil dieses Verfahrens ist die kürzere Zeit, die zum Testen gebraucht wird.<br />
Implementation<br />
Die CPU des Philips LPC2148 besitzt 16 32 Bit lange Register R0-R15. Wie diese verteilt<br />
sind zeigt die Abbildung 8 auf Seite 17.<br />
Die Register R0-R12 besitzen keine speziellen Funktionen und können problemlos im so<br />
genanntem „User mode“[ARM7] getestet werden. Die Register R13-R15 sind Special<br />
Function Register. Der R13 ist der Stack Pointer und der R14 werden auch getestet.<br />
Dies ist möglich, weil beim Ausführen eines Unterprogramms diese nicht benutzt werden,<br />
sondern erst beim Zurückkehren in das Aufrufprogramm. Dies gibt die Möglichkeit<br />
die Inhalte des R13 und des R14 zu sichern und den Walking-Bit Pattern auf diese Register<br />
anzuwenden. Weil das R15 eine hoch dynamische Funktionseinheit ist, ist das<br />
Testen mit sehr großem Aufwand verbunden. Aus diesem Grund wird das R15 nicht<br />
getestet, aber ein inkorrekt funktionierender Programmzähler wird von dem WD aufgedeckt.<br />
Damit das Testen so schnell wie möglich geschieht, wurde die Testmethode in der Assemblersprache<br />
geschrieben. Das Testen eines Registers geschieht in <strong>einer</strong> Schleife,<br />
wie es der Programmausschnitt zeigt:<br />
" #----- 1. Schleife ----------------------"<br />
1. " mov r0,#0x1; "<br />
2. " mov r1,#0x1; "<br />
3. " teq r0,r1; bne Error;"<br />
4. " Schleife_r0_r1: mov r0, r0,LSL #1; "<br />
5. " mov r1, r1,LSL #1;"<br />
6. " teq r0,r1; "<br />
7. " teq r0,#0x80000000; bne Schleife_r0_r1;"<br />
In dieser Schliefe werden die Register R0 und R1 getestet. In den Zeilen 1und 2 werden<br />
Anfangswerte in die Register geschrieben und in der Zeile 3 verglichen. Sind diese ungleich,<br />
erfolgt ein Sprung zur Fehlerroutine. Als nächstes werden in den Zeilen 4 und 5<br />
zwei Schiebeoperationen durchgeführt. Anschließend werden die Register in der Zeile 6<br />
verglichen. Die Schleife wird in zwei Fällen beendet: 1.) Ein Fehler tritt auf; 2.) die Eins<br />
hat 32. Bit erreicht, was ein fehlerfreies Register signalisiert. Das gleiche Verfahren wird<br />
<strong>für</strong> alle restliche zu testende Register angewendet.<br />
12 Hexadezimal<br />
13 Falls diese Muster zwei Mal hintereinander in Register geschrieben werden<br />
14 Kurzschlüsse zwischen den Bits
4 Konzept und Implementierung 43<br />
Da bei allen Register-Tests das Register R1 als Referenz dient, wird dieses auf eine<br />
andere Weise überprüft. Anstelle der Schiebeoperation LSL wird die zweier Multiplikation<br />
verwendet. Durch das Testen des Register R1 auf zwei verschiedene Weisen wird<br />
mit sehr hoher Wahrscheinlichkeit sichergestellt, dass das Register fehlerfrei ist. Die<br />
Funktionsweise kann an dem folgenden Listing nachvollzogen werden:<br />
1. " mov r0,#0x1; "<br />
2. " mov r1,#0x1; "<br />
3. " mov r2,#0x2; "<br />
4. " Schleife_r0_r1: mul r3,r0,r2;"<br />
5. " mov r0,r3; "<br />
6. " mov r3,#0; "<br />
7. " mul r3,r1,r2; "<br />
8. " mov r1,r3; "<br />
9. " mov r3,#0; "<br />
10. " teq r0,r1; bne Error;"<br />
11. " teq r0,#0x80000000; bne Schleife_r0_r1;"<br />
Wobei zu diesem Listing gesagt werden muss, dass die Fehlerfreiheit des Registers R3<br />
angenommen wird.<br />
4.1.4 CPU-Test<br />
Konzept<br />
Wie schon in den Grundlagen erwähnt wurde, bedeutet das Testen <strong>einer</strong> CPU eigentlich<br />
das Testen von einzelnen Befehlen der CPU. Die Befehle des Philips LPC2148 wurden<br />
in dem Kapitel Grundlagen aufgelistet.<br />
Beim Testen wird das Vergleichsprinzip der Fehleraufdeckung benutzt. Der CPU-Test<br />
wird in mehrere kl<strong>einer</strong>e Tests aufgeteilt. In einzelnen Funktionen werden arithmetische<br />
und logische, Load und Store, Vergleichs- sowie Sprungbefehle getestet.<br />
Implementierung der arithmetischen, logischen und Multiplikation-Befehl-Tests<br />
Wie bei der Implementierung aller CPU-Tests wird die Assemblersprache verwendet,<br />
weil sich nicht alle Befehle der CPU in Programmiersprache C implementieren lassen.<br />
Die Funktionsweise des Testens aller arithmetischen, logischen sowie Multiplikations-<br />
Befehlen ist folgende:<br />
1. Zwei Register werden mit Testmustern beladen.<br />
2. Der zu prüfende Befehl wird auf diese Register angewendet.<br />
3. Das Resultat wird mit dem erwarteten Wert verglichen.<br />
4. Ist die Prüfung erfolgreich, wird der nächste Befehl getestet.
4 Konzept und Implementierung 44<br />
Als Beispiel dient die Funktionsweise des Befehls ADC (Add with Carry – Addition mit<br />
Übertrag); wenn zu 0xFFFFFFFF (hexadezimal), binär 11111…111, eine „1“ addiert<br />
wird, findet ein Übertrag statt. Der Registerinhalt wird invertiert und eine „1“ dazu addiert.<br />
Getestet wird wie folgt:<br />
1. " ldr r1, =0x55555555;"<br />
2. " ldr r2, =0xAAAAAAAB;"<br />
3. " mov r4, #0x1;"<br />
4. " adc r3,r1,r2;"<br />
5. " teq r3,r4; bne Error;"<br />
In den Zeilen 1 und 2 werden die Register R1 und R2 mit Testwerten beladen, sowie der<br />
R4 mit dem Erwartungswert (Zeile 3). In der Zeile 4 wird der Befehl ausgeführt und in<br />
der Zeile 5 das Resultat überprüft.<br />
Implementierung Load und Store Befehls-Tests<br />
Die Load und Store Befehle werden benutzt, um Daten zwischen den Registern oder<br />
dem RAM zu bewegen. Es besteht die Möglichkeit entweder einzelne (LDR/STR) oder<br />
mehrere (LDM/STM) Register zu manipulieren, sowie deren Inhalte in und von RAM zu<br />
bewegen. Das Testen der LDR- und STR-Befehle, sowie deren Modifikationen, geschieht<br />
wie folgt:<br />
1. In eine Adresse im RAM wird ein Musterwort geschrieben.<br />
2. Vier Befehlzyklen erfolgt keine Aktion, damit der Schreibvorgang seine<br />
Wirkung im Speicher zeigt.<br />
3. Das Wort wird vom Speicher in ein anderes Register geschrieben.<br />
4. Die Wörter werden verglichen, stimmen Sie nicht überein, wird ein<br />
Fehler gemeldet.<br />
Die Vorgehensweise beim Testen von STM und LDM (Arbeit mit mehreren Registern) ist<br />
die gleiche, jedoch werden die Register R0-12 in zwei Hälften geteilt: Eine Hälfte hält die<br />
Referenzwerte, die andere dient <strong>für</strong> die Zwischenspeicherung der Testwerte. Nach einem<br />
erfolgreichen Test werden die Aufgaben der Hälften getauscht, damit die Funktionalität<br />
der Befehle auf allen Registern geprüft wird.<br />
Die Funktionsweise zeigt der Auszug aus dem Quellcode:<br />
1. "ldr r12, =0x40000500; # R12 mit neuer Adresse laden"<br />
2. "ldr r0, =0x5A5A5A5A; # in Register 32-Bit langen Wert laden"<br />
3. "ldr r1, =0xA5A5A5A5; # --"<br />
4. "ldr r2, =0x5A5A5A5A; # --"<br />
5. "ldr r3, =0xA5A5A5A5; # --"<br />
6. "ldr r4, =0x5A5A5A5A; # --"<br />
7. "ldr r5, =0xA5A5A5A5; # --"
4 Konzept und Implementierung 45<br />
8. "stmdb r12, {r0-r5}; # Registerinhalte ab Speicheradresse"<br />
" # die in R12 steht, schpeichern"<br />
9. "NOP; # No Operation"<br />
10. "NOP; #"<br />
11. "NOP; #"<br />
12. "NOP; # damit Schreibvorgang Wirkung zeigt"<br />
13. "ldmdb r12, {r6-r11}; # Werte vom Schpeicher holen"<br />
14. "teq r0, r6; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
15. "teq r1, r7; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
16. "teq r2, r8; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
17. "teq r3, r9; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
18. "teq r4, r10; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
19. "teq r5, r11; bne LSMError; # vergleichen, falls ungleich -> Error"<br />
In der Zeile 1 wird die Adresse im RAM, ab der die Inhalte der Register gespeichert werden,<br />
in das R12 geladen. In den Zeilen 2 bis 7 werden die Register R0-5 mit den Testwerten<br />
beschrieben. In der Zeile 8 werden die Inhalte der Register in den RAM geschrieben.<br />
Es wird vier Zyklen keine Aktion ausgeführt, damit de Schreibvorgang seine<br />
Wirkung zeigt. In Zeile 13 werden die Werte in die Register R6-11 vom Speicher geschrieben.<br />
In den Zeilen 14 bis 19 werden die vom RAM geholten Werte mit Referenzwerten<br />
verglichen.<br />
Implementierung der „Test“- und „Compare“-Tests<br />
Der ARM7TDMI-CPU stehen zwei Arten von Test- und Vergleichsbefehlen, sowie deren<br />
Modifikationen zur Verfügung, und zwar TST und CMP. Diese Befehle werden gemeinsam<br />
geprüft, also CMP mit Hilfe von TST und umgekehrt. Die Funktionsweise des Tests<br />
wird anhand des Quellcodes erläutert.<br />
1. "ldr r1, =0xA5555555; "<br />
2. "ldr r2, =0x15555555; "<br />
3. "mrs r0, cpsr; "<br />
4. "cmp r1, r2; "<br />
5. "mrs r3, cpsr; "<br />
6. "teq r3, r0; bne CTError; "<br />
In den Zeilen 1 und 2 werden die Register mit Testwerten befüllt. In der Zeile 3 wird der<br />
aktuelle Inhalt des Current Programm Status Registers (CPSR) gespeichert, um Änderungen<br />
in den Statusflags festzuhalten. In der Zeile 4 wird der zu testende Befehl (hier<br />
CMP) ausgeführt. Anschließend wird in der Zeile 5 der Inhalt des CPSR nach der Operation<br />
gespeichert und die beiden Werte mit der Erwartungshaltung verglichen.
4 Konzept und Implementierung 46<br />
Implementation des Sprungbefehl-Tests<br />
Bei den Sprungbefehlen werden unbedingte Sprünge sowie bedingte Sprünge auf ihre<br />
korrekte Funktionalität geprüft.<br />
Zuerst wird der unbedingte Sprung geprüft und zwar wie folgt: Es wird eine Schleife <strong>für</strong><br />
drei unbedingte Sprünge initialisiert. Bei einem erfolgreichen Sprung wird hoch gezählt.<br />
Falls die drei Sprünge erfolgt sind, wird die Schleife verlassen und es wird mit weiteren<br />
Tests fortgefahren, ansonsten verbleibt die CPU in der Schleife. Diese Schleife zeigt<br />
folgendes Listing:<br />
1. "ldr r0, =0x00000001; # belade Register mit Werte"<br />
2. "ldr r1, =0x00000008; # --"<br />
3. "BER: NOP; # No Operation"<br />
4. "mov r0, r0,LSL #1; # eins schieben"<br />
5. "teq r0, r1; beq BER1; # vergleiche, ob 3 Spuenge erfolgt sind"<br />
6. "b BER; # falls nicht -> zurueck"<br />
Ein bedingter Sprung findet statt, falls bestimmte Kombinationen von Statusflags vorhanden<br />
sind 15 . Geprüft wird wie folgt: es wird eine Operation mit bestimmten Werten<br />
durchgeführt, infolge deren, bestimmte Flags gesetzt („1“) oder nicht gesetzt („0“) werden;<br />
anhand des Ergebnisses soll ein bedingter Sprung erfolgen und zwar zum nächsten<br />
Test; falls nicht, verfängt sich die CPU in <strong>einer</strong> Endlosschleife. Dies zeigt die folgende<br />
Listing:<br />
1. "ldr r0, =0xAAAAAAAA; # belade Register mit Werten"<br />
2. "ldr r1, =0xAAAAAAAA; # --"<br />
3. "mov r3, #0x00000000; # --"<br />
4. "Berror0:NOP; # "<br />
5. "NOP; # No Operation"<br />
6. "NOP; # --"<br />
7. "sub r2, r0, r1; # Subtraktion => 0X00000000"<br />
8. "teq r3, r2; bne Berror0; # falls ungleich , "<br />
" # zurueck; Z-Flag nicht gesetzt"<br />
9. "b Berror1; # ansonsten weiter"<br />
10."Berror2: b Berror2; # beide versagt, endlosschleife"<br />
11."Berror1: NOP; # die naechste Schleife"<br />
15 z.B. beim Befehl „TEQ“ muss der Flag Z gesetzt(gleich) oder nicht gesetzt(ungleich) sein
4 Konzept und Implementierung 47<br />
4.1.5 RAM-Test<br />
Konzept<br />
In dem Kapitel Grundlagen wurden zwei Testverfahren genannt, mit denen in der vorhandenen<br />
Bibliothek das RAM getestet wurde. Die beiden Testmethoden wurden auf<br />
ihre Fehleraufdeckung, Zeit und die sicherheitstechnische Tauglichkeit beglichen. Dabei<br />
kam nur ein entscheidender Unterschied als Ergebnis heraus: bei dem X-March-Test<br />
wird der Inhalt des RAMs vollständig „zerstört“, weil das gesamte RAM mit Nullen überschrieben<br />
wird. Beim Überschreiben des RAMs können sehr wichtige und <strong>für</strong> den Erhalt<br />
der Sicherheitsfunktion benötigte Daten einfach gelöscht werden. Anhand dieser Tatsache<br />
wurde der transparente Speichertest ausgewählt und überarbeitet.<br />
Der Philips LPC2148 verfügt über einen 32 KB großen Arbeitspeicher(RAM). Abbildung<br />
29 [LPC2148] zeigt der Adressbereich des RAMs:<br />
Abbildung 29: Adressbereich des RAMs<br />
Aus der Abbildung geht hervor, dass das RAM sich von 0x40000000 bis 0x40007FFF<br />
erstreckt. Im unteren RAM-Bereich befindet sich ein reservierter Bereich. In diesem Bereich<br />
befinden sich Stack, Heap und Interrupt Vektoren. In dieser Thesis werden diese<br />
Bereiche nicht getestet, weil es sich während der Ausführung von Programmen der Stackinhalt<br />
ständig verändert, was zu immer neuen CRC-Werten führen wird, also nach<br />
Definition des Tests zu einem Fehler. Um diese Bereiche zu testen, sollen neue Testmethoden<br />
entworfen werden. Leider ist diese Thesis zeitlich begrenzt und lässt dies nicht<br />
zu.<br />
Implementierung des ROM-Tests<br />
Dem vorhandenen transparenten Speichertest werden die Start-, Endadressen, Sektorlänge<br />
und Anzahl der Sektoren übergeben. Anhand dieser Daten wird der Test durchgeführt.<br />
Zuerst wird das Testwort selbst mit einem Walking Bit Pattern überprüft. Als nächstes<br />
wird der Sektor, in dem sich das Testwort befindet, getestet, danach die übrigen Sektoren.<br />
Falls die Tests erfolgreich waren, wird das nächste Testwort genommen.<br />
In der vorhandenen Bibliothek wurde zur Signaturberechnung (CRC-Bildung) eine 16 Bit<br />
Signatur verwendet. Dies wird geändert und eine 32 Bit lange CRC genommen. Anstatt<br />
der Berechnung jedes einzelnen Wertes zur Laufzeit, was zusätzlichen zeitlichen Aufwand<br />
bedeutet, wird eine andere Methode verwendet. Bei dieser Methode wird eine Tabelle<br />
(Look-Up-Tabelle) im ROM angelegt mit Hilfe derer die CRC-Signatur berechnet
4 Konzept und Implementierung 48<br />
wird. Diese Funktion berechnet die CRC nur <strong>für</strong> ein Byte. Deswegen wird das 32 Bit<br />
Wort in vier Bytes zerlegt und über diese die CRC-Prüfsumme gebildet. Dies liefert die<br />
gleichen Ergebnisse, als wenn die CRC über das gesamte Wort gebildet würde.<br />
Aus der Analyse des aus der Literatur bekannten transparenten Speicher Tests wurde<br />
ersichtlich, dass Signaturen über alle Sektoren immer gebildet werden, sogar über die,<br />
die schon getestet wurden. Das muss aber nicht sein. Wenn von einem „doppelseitigen“<br />
Kurzschluss ausgegangen wird, also die kurzgeschlossenen Speicherzellen beeinflussen<br />
sich wechselseitig, so können die schon getesteten Sektoren aus dem Test weggelassen<br />
werden. Die Begründung <strong>für</strong> dieses Vorgehen ist die folgende: falls eine Zelle<br />
z.B. aus dem Sektor 5 einen Kurzschluss mit <strong>einer</strong> Zelle aus dem Sektor 1 hat, so wird<br />
dieser schon beim Testen des ersten Sektors aufgedeckt. Durch dieses Vorgehen wird<br />
der zu testende Speicherbereich zum Ende hin immer kl<strong>einer</strong> und somit immer schneller.<br />
Dieses Prinzip wird in der Abbildung 30 veranschaulicht:<br />
Abbildung 30: RAM-Test<br />
Die Realisierung dieses Prinzips zeigt das Flussdiagramm von Abbildung 32. Alle Variablen<br />
wie RAM-Anfangsadresse, RAM-Endadresse, Sektorlänge, Adresse des Testwortes<br />
und der Sektor, in dem sich das zu testende Wort befindet, werden als globale Variablen<br />
deklariert, damit sie ihren Wert nicht verlieren, wenn in den normalen Betrieb gewechselt<br />
wird. Bei den Aufrufen des RAM-Tests werden das Testwort, der zu<br />
testende Sektor und Informationen darüber, wo sich das Testwort befindet (im zu<br />
testenden Sektor oder außerhalb) übergeben.<br />
Die Vorgehensweise:<br />
1. Zuerst wird überprüft ob sich das zu testende Wort immer noch im RAM befindet,<br />
falls nicht wird die Adresse des Wortes an die Anfangsadresse gesetzt und die<br />
erste Testscheibe ausgeführt.
4 Konzept und Implementierung 49<br />
2. Dann wird analysiert ob sich das Wort noch im laufenden Sektor befindet. Falls<br />
nicht (das Testwort hat den laufenden Sektor verlassen), wird die Nummer des<br />
laufenden Sektors inkrementiert, sowie die Variable (im Programm „SMWgetestet“),<br />
die ob der Sektor mit dem Testwort geprüft worden ist oder nicht zeigt,<br />
auf „false“ gesetzt.<br />
3. Im nächsten Schritt unter sucht der Algerithmus ob schon alle Sektoren ohne das<br />
Testwort überprüft sind. Falls ja: wird der Index auf eins zurückgesetzt, „SMWgetestet“<br />
auf „false“ gesetzt und das nächste Testwort genommen. Falls nicht: siehe<br />
Punkt 4.<br />
4. Es wird unterschieden zwischen zwei Arten von Sektoren: in dem sich das Testwort<br />
befindet und wo nicht. Im ersten Fall wird der RAM-Test aufgefordert den<br />
Sektor mit Testwort (dritter Übergabeparameter gleich 1, sowie die laufende Sektornummer)<br />
zu testen, im zweiten ohne (dritter Übergabeparameter gleich 0, sowie<br />
die laufende Sektornummer+index 16 ).<br />
4.1.6 Ein-/Ausgabe Test<br />
Konzept<br />
Abbildung 31: RAM-Test (Flussdiagramm)<br />
Um mit s<strong>einer</strong> Umgebung zu kommunizieren verfügt das gegebene Board über zwei Ein-<br />
/Ausgabe Ports P0 und P1 (GPIO-Ports), zwei ADC, einen DAC und zwei PWMs. Das
4 Konzept und Implementierung 50<br />
Port P0 ist 32-Bit lang, also es besitzt 32 Pins P0.0-32. Diese Pins können entweder als<br />
Eingang, Ausgang, ADC, DAC oder PWM benutzt werden. Die Umschaltung geschieht<br />
mit Hilfe des Registers PINSEL 17 . Das Port P0 ist bitadressierbar sowie maskierbar: jedes<br />
der 30 zur Verfügung stehenden Pins dieses Portes können einzeln oder mehrfach<br />
manipuliert werden. Der Pin P0.31 ist nur als Ausgabeport zu benutzen. Der Pin P0.24<br />
ist nicht vorhanden.<br />
Die Pins wurden mit dem Walking Bit Verfahren getestet, da an den µController keine<br />
Peripherie angeschlossen wurde, müssten keine besonderen Schaltzeiten angehalten<br />
werden. Die Pins wurden in zwei Hälften aufgeteilt, eine dient als Ausgang, die andere<br />
als Eingang. Über die Ausgangspins wird eine „1“ geschoben und an den Eingangspins<br />
kontrolliert.<br />
Implementierung<br />
Das Board besitzt zwei ADCs mit jeweils 6 Kanälen, außerdem ein DAC. Alle Kanäle der<br />
ADCs wurden hardwaremäßig an den Ausgang des DACs angeschlossen. Zum Testen<br />
wurde das Prinzip der Plausibilitätsprüfung angewendet. Hierbei handelt es sich um einen<br />
Zusammenhang zwischen dem Ausgang(DAC) und Eingang(ADC): werden die<br />
ausgegebenen Werte größer, so müssen auch eingelesene Werte größer werden. Der<br />
Vergleich soll aber Toleranzen beinhalten, diese sollen an die Vergleichswerte angepasst<br />
sein. Die Toleranzen müssen vorhanden sein, weil jede Schaltung rauscht und die<br />
eingelesenen Werte dadurch verfälscht werden können.<br />
Das Testen geschieht <strong>für</strong> alle Kanäle der beiden ADCs und zwar nacheinander, weil die<br />
eingelesenen und konvertierten Werte in jeweils einem Register der ADCs gespeichert<br />
werden.<br />
4.1.7 ROM-Test<br />
Konzept<br />
Das gegebene Board Philips LPC2140 hat 512 KByte Programmspeicher bzw. ROM,<br />
dies zeigt die Abbildung 16 (siehe s.24).<br />
Der Adressbereich des ROMs befindet sich zwischen 0x00000000-0x0007FFFF. Dieser<br />
Speicher soll während des Betriebs immer unverändert bleiben. Weil im ROM das auszuführende<br />
Programm abgelegt wird, können kleinste Veränderungen im Speicher zu<br />
einem falschen Programmablauf führen, was natürlich verheerende Auswirkungen zur<br />
Folge haben kann.<br />
Implementierung<br />
Das ROM wird wie folgt getestet: beim Anlauftest wird eine 32-Bit lange Signatur (CRC)<br />
gebildet. Dabei wird angenommen, dass das Programm im Speicher korrekt ist. Diese<br />
16 in der Summe max. 8 – Anzahl der Sektoren im RAM
4 Konzept und Implementierung 51<br />
Anfangssignatur wird gespeichert und als Referenz gebraucht. Unterscheidet sich die im<br />
Betrieb berechnete Signatur von der Anfangssignatur, so wird angenommen, dass im<br />
ROM ein Fehler vorhanden ist.<br />
Für die Berechnung der CRC-Werte wird eine Look-Up Tabelle mit allen CRC-Werten <strong>für</strong><br />
ein Byte als Konstante definiert und im ROM abgelegt 18 . Mit diesem Verfahren werden<br />
nur etwa 5 Sekunden benötigt, um eine Signatur über das gesamte ROM zu bilden.<br />
Trotzdem wird das ROM in Segmente unterteilt und zwar in 64, jeder 8 KB groß, damit<br />
die Berechnung nur etwa 100ms dauert. Was nur ein Drittel der Zeit ist, die <strong>für</strong> den<br />
Selbsttest während des Betriebs zur Verfügung steht.<br />
Ob die Signatur über den gesamten ROM am Stück oder Segmentweise gebildet wird,<br />
macht keinen Unterschied.<br />
4.1.8 Timer-Test<br />
Konzept<br />
Die Grundidee des Testen des Timers ist folgende: Wenn der Timer fehlerfrei funktioniert,<br />
muss die Differenz zwischen zwei Abfragungen des Timers innerhalb <strong>einer</strong> bestimmten<br />
Zeit immer gleich sein. Dieser Idee nach wird der Test konzipiert.<br />
Implementierung<br />
Das Evaluationsboard verfügt über zwei 32-Bit Timer/Counter. Für die Realisation des<br />
Zeitscheibenverfahrens wird der Timer 0 verwendet. Da es nur zwei Zeitscheiben gibt<br />
die Längste 700ms <strong>für</strong> das Hauptprogramm und die zweite, die etwa 300ms dauert, die<br />
zum Testen des Boards benötigt wird. Der Timer wird benötigt um die längste Scheibe<br />
zu ermöglichen.<br />
Zum Testen des Timers wird der Zeitintervall von 1ms ausgewählt und der Timer zwei<br />
Sekunden lang beim Anlauftest überprüft. Die Differenz, die während dieses Tests errechnet<br />
wird, wird als Referenzwert gespeichert und bei weiteren Tests mit aktuellen<br />
Differenzen verglichen. Falls diese nicht übereinstimmen, wird ein Fehler gemeldet. Im<br />
Betrieb wird 10 ms lang getestet. Hier mit wird der Timer 10-mal überprüft.<br />
4.1.9 Zeitscheibenverfahren<br />
Wie schon beim Timer-Test erwähnt, wurden die Selbsttests alle 700ms aufgerufen.<br />
Dies geschieht wie folgt:<br />
• der Timer wird mit 700ms geladen und nach Ablauf dieser Zeit ein Interrupt ausgelöst.<br />
• Beim Auslösen des Interrupts wird die Interrupt-Routine aufgerufen.<br />
17 weitergehende Informationen in [LPC2148]<br />
18 in der Praxis überprüft
4 Konzept und Implementierung 52<br />
• In dieser Routine werden alle Test entweder ganz (CPU-Test) oder als Teiltests<br />
ausgeführt.<br />
• Danach wird der Timer resetet und mit dem Hauptprogramm <strong>für</strong> weitere 700ms<br />
fort gefahren.<br />
Weil solche Tests wie CPU-, Reister- oder DA-/AD-Test zusammen in etwa 60ms benötigen,<br />
wurden diese nicht in Scheiben unterteilt. Der RAM- und ROM-Test werden jedoch<br />
in Scheiben ausgeführt, deswegen wurden sie auch dementsprechend<br />
konzipiert.
5 Validation 53<br />
5 Validation<br />
Dieses Kapitel beschäftigt sich mit dem Testen der Bibliothek. Dabei werden folgende<br />
Punkte bewertet:<br />
• die Ausführungszeit<br />
• und die Fehleraufdeckung<br />
Die Ausführungszeiten werden mit Hilfe eines digitalen Oszilloskops gemessen. Verfahren<br />
wird wie folgt: in dem Hauptprogramm wird eine Endlosschleife initialisiert, in dieser<br />
Schleife wird eine LED angeschaltet, dann der Test ausgeführt (bzw. ein Teiltest oder<br />
eine Zeitscheibe), und nach dem Test die LED ausgeschaltet. Die Zeit in der die LED<br />
eingeschaltet war, ist die Ausführungszeit eines Tests. Die Ausführungszeiten der Tests<br />
sind in der Tabelle 7 aufgelistet:<br />
Test Ausführungszeit<br />
CPU (alle Befehle + Register-Test) 50 µs<br />
DA-/AD-Wandler 40 ms<br />
Watchdog 10 ms<br />
Eine Zeitscheibe des ROM-Tests 72 ms<br />
Eine Zeitscheibe des RAM-Tests 71 ms<br />
ROM-Test komplett (Anlauftest) ~ 5 s<br />
Timer-Test (Anlauftest) ~2,5 s<br />
Timer-Test (Betrieb) 11 ms<br />
Ein-/Ausgabe-Test 10 ms<br />
Tabelle 8: Ausführungszeiten der Tests<br />
Aus dieser Tabelle wird im Betrieb <strong>für</strong> das Testen des Boards insgesamt maximal etwa<br />
220 ms benötigt. Dementsprechend kann die angenommene Zeit von 300 ms verkürzt<br />
werden.<br />
Was die Fehleraufdeckung angeht, können bei einigen Tests die Fehler „eingebaut“<br />
werden, wie bei einem RAM-, oder einem Ein-/Ausgabe-Test. Bei dem ROM-Test wird<br />
gezeigt, dass das Ändern eines einzelnen Bits zu <strong>einer</strong> anderen Signatur führt.<br />
Da die Entwicklungsumgebung HiTOP 5.2 über ein Fenster, in dem die Registerinhalte<br />
angezeigt werden, verfügt, kann durch dieses der Register-Test kontrolliert werden. Dieses<br />
Fenster wird ebenso zur Kontrolle des CPU-Tests genutzt.<br />
Bei dem ROM-Test wird gezeigt, dass durch das Ändern eines einzelnen Bits eine neue<br />
CRC-Signatur gebildet wird. Dabei wird eine Konstante mit dem Wert „0“ im ROM gespeichert<br />
und der ROM-Test ausgeführt, danach die CRC-Signatur festgehalten.
5 Validation 54<br />
Der Wert der Konstante wird geändert und auf „1“ gesetzt. Der ROM-Test wird durchgeführt<br />
und die CRC-Signaturen verglichen. Dieser Test ist erfolgreich verlaufen.<br />
Bei dem RAM-Test wird in der Routine „sector_without_word“, nach dem die erste Signatur<br />
gebildet und das Testwort invertiert wurde, der Inhalt <strong>einer</strong> Speicherzelle im Sektor<br />
geändert. Die zweite Signatur wird gebildet und es muss eine Fehlermeldung erfolgen.<br />
Dieser Test ist erfolgreich verlaufen, es wurde eine Fehlermeldung ausgelöst.<br />
Bei dem Ein-/Ausgabe-Test wird ein Port anstatt mit nur einem anderem, jetzt mit zwei<br />
Porten hardwaremäßig verbunden. Der Test soll diese Manipulation abfangen können.<br />
Dieser Fehler wird vom Test aufgedeckt.<br />
Das genauere Testverfahren kann im Anhang A nachgeschaut werden.
6 Fazit und Ausblick 55<br />
6 Fazit und Ausblick<br />
Diese Thesis hat einen Überblick über die große Welt der Sicherheitstechnik der<br />
µControllern verschafft. Grundlegenden Selbsttests der Hardware wurden implementiert.<br />
Es wurden die grundlegenden Selbsttests <strong>für</strong> einen ARM7TDMI Prozessor implementiert.<br />
Diese dienen <strong>einer</strong> Überprüfung des gesamten Systems vor Inbetriebnahme und<br />
während des Betriebs. Alle Tests wurden so konzipiert, dass diese im Hintergrund <strong>einer</strong><br />
Hauptanwendung ausführbar sind. Die größten Schwierigkeiten sind mit dem RAM-Test<br />
verbunden, da mehrmals Signaturen über einen Sektor gebildet werden. Dennoch ist<br />
der Test fast auf alle µController portierbar. Dies betrifft auch den ROM-Test und den<br />
Ein-/Ausgabetest. Der CPU-Test könnte auch in der Programmiersprache C geschrieben<br />
werden, was bei einfachen Befehlen wie ADD oder ORR sehr leicht wäre. Jedoch ist es<br />
nicht möglich in C alle spezifischen Befehle wie RSB (Reverse Subtract with Carry) zu<br />
testen. Deswegen wurde der ganze Instruktionssatz des ARM7TDMI in Assembler überprüft.<br />
Die Grundidee dieser Tests ist auf viele andere CPUs anwendbar.<br />
Es wurden alle Musskriterien, die an die Bibliothek gestellt wurden, erfüllt. Zudem wurde<br />
auch ein Kannkriterium erfüllt, nämlich die Zeitscheiben implementiert.<br />
Die hier implementierte Bibliothek soll als ein Prototyp angesehen werden und kann als<br />
Basis genommen werden. Weil diese Bibliothek modular aufgebaut ist, besteht die Möglichkeit<br />
<strong>für</strong> die Interessenten diese mit beliebigen benötigten Tests <strong>für</strong> bestimmte Anwendungen<br />
zu ergänzen. Dabei müssen aber die Ausführungszeiten beachtet werden.<br />
Als Erweiterung <strong>für</strong> diese Bibliothek könnte z.B. die Implementierung der nicht erfüllten<br />
Kannkriterien (z.B. PWM-Test) sein. Außerdem kann versucht werden den CPU-Test in<br />
der Programmiersprache C zu implementieren.
Literaturverzeichnis 56<br />
Literaturverzeichnis<br />
[ANLPC2148] Applications Notes<br />
http://www.semiconductors.philips.com/pip/LPC2141FBD64.html<br />
(letzter Zugriff 30.08.2007)<br />
[ARM7] „ARM7TDMI Technical Reference Manual“, www.arm.com<br />
[ARMREF] “ARM Architecture Reference Manual”,<br />
http://www.altera.com/literature/third-party/ddi0100e_arm_arm.pdf<br />
[BAL96] Prof. Dr.-Ing. habil. Helmut Balzert: „Lernbuch der Software-<br />
Technik“, Software Entwicklung, Spektrum, 1996<br />
[BEC03] Prof. Dr. rer. nat. W.-J. Becker(Hrsg.): „Mikroprozessortechnik:<br />
Architektur, Implementierung, Schnittstellen“, VDE, 2003<br />
[BGIA06] Mario Mai, Günter Reuß: „Selbsttests <strong>für</strong> Mikroprocessoren mit Sicherheitsaufgaben<br />
oder „Quo vadis Felehr?““, BGIA-Report 7/2006<br />
http://www.hvbg.de/d/bia/pub/rep/rep05/bgia0706.html<br />
[BIA97] Werner Kleinbreuer, Franz Kreutzkampf, Karlheinz Meffert, Dietmar<br />
R<strong>einer</strong>t: „Kategorien <strong>für</strong> sicherheitsbezogene Steuerungen nach EN<br />
954-1“, BIA-Report 6/97, HVBG, 1997<br />
http://www.hvbg.de/d/bia/pub/rep/rep02/bia0697.html<br />
[BÖM05] Thomas Bömer: „Funktionale Sicherheit nach IEC 61508“, BGIA,<br />
2005, Sicherheitstechnisches Informations- und Arbeitsblatt 330 219<br />
[BÖR04] Josef Börcsök: „Elektronische Sicherheitssysteme: Hardwarekonzepte,<br />
Modelle und Berechnung“, Hüthig, 2004<br />
[BÖR06] Josef Börcsök: „Funktionale Sicherheit: Grundzüge sicherheitsgerichteter<br />
Systeme“, Hüthig, 2006<br />
[GEH07] Patrik Gehlen: „Funktionale Sicherheit von Maschinen und Anlagen:<br />
Umsetzung der europäischen Maschinenrichtlinie in der Praxis“, Siemens,<br />
2007<br />
[GRÄ04] Winfried Gräf: „Maschinensicherheit: Auf der Grundlage der europäischen<br />
Sicherheitsnormen“, Hüthig, 2004<br />
[HAL99] W.A. Halang/R. Konakowsy: „Sicherheitsgerichtete Echtzeitsysteme“,<br />
Oldenburg, 1999
Literaturverzeichnis 57<br />
[HAM99] Qaisar Hameed, Master’s Thesis: „A Behavioral Test Strategy<br />
For Board Level Systems“, 1999<br />
(http://scholar.lib.vt.edu/theses/available/etd-031099-213422/)<br />
(letzter Zugriff 30.08.2007)<br />
[ISSA02] “Rechner in der Maschinensicherheit“, ISSA Prevention Series<br />
No. 2046(G), ISBN 92-843-7157-0<br />
[KRA04] Michael Kraus, Diplomareit: „Realisierung eines programmierbaren<br />
Sicherheitsbauteils zum Anschluss von Bus-Systemen in dezentralen<br />
Energieverteilungsanlagen“, 2004<br />
[LPC2148] Philips LPC2148 User Manual<br />
http://www.nxp.com/acrobat_download/usermanuals/UM10139 1.pdf<br />
[MAR06] Trevor Martin: „The Insider Guide to the Philips ARM ® 7 Microcontrollers“,<br />
2006,<br />
http://www.hitex.co.uk/arm/lpc2000book/free_downloadpage.html<br />
[RED98] Michael Redeker, Studienarbeit: „Design und Verifikation eines<br />
defekttoleranten selbstkonfigurierenden DRAM-Moduls“, 1998<br />
[SCH97] Michael, Schäfer: „Fehlererkennende Maßnamen in Mikroprozessoren“,<br />
BIA, 1997, Sicherheitstechnisches Informations- und Arbeitsblatt<br />
330 225<br />
[TUR05] Kiranraj Tiruchinapalli, Master Thesis: „Modular Safety Design of Autonomous<br />
Systems Using KURT3D as an Example“, 2005<br />
[WAH05] Dr. Michael Wahl, Skript: „Speichertest“ http://www.rs.uni-<br />
siegen.de/skripte/Speichertechnologien_1/ 7 Test. pdf<br />
[WAL04] Klaus-Dieter Walter: „Messen, Steuern und Regeln mit ARM-<br />
Mikrokontrollern“, Franzis, 2004
Abbildungsverzeichnis 58<br />
Abbildungsverzeichnis<br />
Abbildung 1: 3-stufige Pipelne......................................................................11<br />
Abbildung 2: Evaluation Board MCB2140........... .........................................12<br />
Abbildung 3: Tantino <strong>für</strong> ARM7-9..................................................................13<br />
Abbildung 4: ARM7TDMI main processor logic .......….................................14<br />
Abbildung 5: Load-and-Store Prinzip ………….............................................15<br />
Abbildung 6: Registerbank ...........................................................................16<br />
Abbildung 7: Current Program Status Register ............................................16<br />
Abbildung 8: ARM Benutzungsmodi .............................................................17<br />
Abbildung 9: Benutzung von Registern im THUMB-Satz ..................................17<br />
Abbildung 10: ARM-Instruktionssatz Formate ....................................................19<br />
Abbildung 11: Standartsprungbefehle .................................................................19<br />
Abbildung 12: Sprungbefehle BLX und BL ..........................................................20<br />
Abbildung 13: Data Processing Instruction ………………………….……………..20<br />
Abbildung 14: Data Processing Instruction …………………………………….…..20<br />
Abbildung 15: Bewegung von Daten zwischen mehreren Registern ..................22<br />
Abbildung 16: LPC2148 Memory Map …………..………………………….….…...23<br />
Abbildung 17: Entwicklungsumgebung HITOP 5.2..............................................24<br />
Abbildung 18: Risikograph(EN 954-1) .................................................................25<br />
Abbildung 19: Steuerungsversagen nach „Lebensphasen“ ................................26<br />
Abbildung 20: „Badewannekurve“........................................................................27<br />
Abbildung 21: Das allgemeine Fehlererkennungsprinzip ....................................28<br />
Abbildung 22: Zustandgraph eines fehlerfreien Speicherbausteins ....................29<br />
Abbildung 23: Zustandgraph eines SA0 ..............................................................30<br />
Abbildung 24: Zustandgraph eines SA1 ..............................................................30<br />
Abbildung 25: Zustandgraph eines Transition-Up-Faults ....................................30<br />
Abbildung 26: Funktionsweise eines transparenten Speichertests .....................34<br />
Abbildung 27: Ablauf des WD-Tests ...................................................................41
Abbildungsverzeichnis 59<br />
Abbildung 28: Walking Bit ...................................................................................41<br />
Abbildung 29: Adressbereich des RAMs .............................................................47<br />
Abbildung 30: RAM-Test .....................................................................................48<br />
Abbildung 31: RAM-Test (Flussdiagramm) .........................................................49
Tabellenverzeichnis 60<br />
Tabellenverzeichnis<br />
Tabelle 1: Bedienungspräfixe ..................................................................................... 18<br />
Tabelle 2: Datenbearbeitende Befehle ....................................................................... 21<br />
Tabelle 3: Load- Befehle ............................................................................................. 21<br />
Tabelle 4: Store- Befehle ............................................................................................ 22<br />
Tabelle 5: Die Multiplikationsbefehle ........................................................................... 22<br />
Tabelle 6: Funktionale Fehler eines RAMs ................................................................. 29<br />
Tabelle 7: Zusammenhang der Fehlermodelle und funktionaler Fehler ...................... 31<br />
Tabelle 8: Ausführungszeiten der Tests ...................................................................... 52
Anhang A: Tests 61<br />
Anhang A: Tests<br />
1. ROM-Test<br />
Ausführungszeit:<br />
Es wird die Zeit ermittelt, die <strong>für</strong> die Ausführung <strong>einer</strong> Zeitscheibe des ROM-Tests benötigt<br />
wird. Für diese Zwecke wird eine Testroutine geschrieben, die wie folgt aussieht:<br />
for(z=1;z
Anhang A: Tests 62<br />
Fehleraufdeckung:<br />
Es wird gezeigt, dass ändern eines Bits zu <strong>einer</strong> anderen Signatur führt. Für diese Zwecke<br />
wird im ROM eine Konstante angelegt nämlich:<br />
“static const unsigned int testvar = 0;”<br />
Der ROM-Test wird ausgeführt. Die Signatur, die berechnet wurde, ist die folgende:<br />
0xBCDE18DA - Hexadezimal oder 3168671962 - Dezimal<br />
Nach diesem Durchlauf wird nur die Konstante geändert, und zwar wie folgt:<br />
“static const unsigned int testvar = 1;”<br />
Der ROM-Test wird wieder ausgeführt. Die Signatur die berechnet wurde, ist die folgende:<br />
0x5860C61F – Hexadezimal oder 1482737183 - Dezimal<br />
Die berechneten Signaturen unterscheiden sich deutlich. Jetzt wird überprüft ob das<br />
Ändern der Konstanten in den ursprünglichen Zustand auch die zuerst berechnete Signatur<br />
als Ergebnis wieder zurückgegeben wird. Die Konstante wird wieder geändert wie<br />
folgt:<br />
“static const unsigned int testvar = 0;”<br />
Der ROM-Test wird wieder ausgeführt. Die Signatur die berechnet wurde, ist die folgende:<br />
0xBCDE18DA – Hexadezimal oder 3168671962 - Dezimal<br />
Das ist die gleiche Signatur, die im ersten Test das Ergebnis war. Aus diesem wird ersichtlich,<br />
dass das Ändern eines einzelnen Bits zu <strong>einer</strong> anderen Signatur führt.<br />
2. RAM-Test<br />
Ausführungszeit:<br />
Die Ermittlung der Ausführungszeit <strong>für</strong> eine Zeitscheibe des RAM-Tests geschieht genau<br />
wie beim ROM-Test: mit Hilfe von LEDs.<br />
Für eine Zeitscheibe des RAM-Tests werden laut Osziloskops 71ms benötigt. Bis ein<br />
Wort selbst und das Wort mit allen 8 Sektoren getestet wird, werden in etwa 71*8 ≈ 568<br />
ms benötigt. Bis ein Sektor vollständig getestet ist und weggelassen werden kann vergehen<br />
≈ 581632 ms oder etwa 10min. Diese Zeit wird benötigt um den größten Teil des<br />
Tests (von acht die immer schneller werden) auszuführen, falls dieser am Stück ausgeführt<br />
sein sollte. Die weiteren Berechnungen werden immer Kürzer, weil immer weniger<br />
Sektoren zu testen gibt. Dies zeigt der Auszug aus dem Quellcode bevor dieser automatisiert<br />
wurde:<br />
void RAM_test()<br />
{ …<br />
runsector = 1;<br />
…
Anhang A: Tests 63<br />
for(i=start; i
Anhang A: Tests 64<br />
Fehleraufdeckung:<br />
Es wird ein Fehler in das RAM „eingebaut“: in der Routine „sector_without_word()“ wird<br />
vor dem Berechnen der zweiten Signatur eine Speicheradresse im zu testenden Sektor<br />
verändert, was eine andere CRC-Signatur als Folge hat. Die Routine muss den Fehler<br />
abfangen. Dieser Test verläuft erfolgreich: es wird eine Fehlermeldung ausgelöst.<br />
Den eingebauten Fehler zeigt der Auszug aus dem Quellcode:<br />
unsigned long *fehler = 0x40001010;<br />
…<br />
void sector_without_word(int sector, unsigned long *testword)<br />
{<br />
…<br />
for (i=start; i
Anhang A: Tests 65<br />
Ausführungszeit:<br />
Die CPU-Tests und Register-Test werden nacheinander ausgeführt und die Ausführungszeit<br />
gemessen. Die Abbildung zeigt das Ergebnis:<br />
Die gemessene Ausführungszeit beträgt laut dem Oszilloskop 48,20 µs.<br />
Bei diesen Tests ist es schwer einen Fehler einzubauen. Aber es ist möglich einen Test<br />
mit falschen Werten ausführen lassen. Dieser Test verlief erfolgreich: es kam eine Fehlermeldung.<br />
4. Timer-Test<br />
Ausführungszeit:<br />
Für die Ausführung des Timer-Tests werden laut dem Oszilloskop 10,00 µs im Betrieb<br />
benötigt. Beim Anlauftest werden 2s benötigt.
Anhang A: Tests 66<br />
Fehleraufdeckung:<br />
Es wird ein Fehler „eingebaut“: weil es in der Routine zwei „while“-Schleifen gibt, wird die<br />
zweite nur um einen Schritt länger gemacht. Dabei entstehen zwei unterschiedliche Differenzen.<br />
Es muss eine Fehlermeldung erfolgen. Dies zeigt das folgende Listing:<br />
void timer_test_run(void){<br />
unsigned int timer0, timer1, dif0, dif1;<br />
unsigned int timer10, timer11;<br />
int u=-2;<br />
int o=2;<br />
unsigned int r, zyklen = 0;<br />
while(zyklen < 5){<br />
r=0;<br />
timer0 = TIMER0_TC;<br />
- while(r
Anhang A: Tests 67<br />
5. DA-/AD-Test<br />
Ausführungszeit<br />
}<br />
}<br />
dif1 = timer11-timer10;<br />
if( u
Anhang A: Tests 68<br />
6. Port-Test<br />
Es werden exemplarisch vier Pins von Port 0 getestet. Für die Ausführung werden laut<br />
Oszilloskop 42,00 µs gebraucht. Die Zeit wird benötigt um 2 Pins zu testen.<br />
Also werden demnach in etwa <strong>für</strong> restliche 28 Pins: 21µs * 28 ≈ 600µs = 0,6ms benötigt.<br />
Fehleraufdeckung<br />
Der Pin P0.0 wird nicht nur an den P0.4 sondern auch an den P0.5 angeschlossen, dabei<br />
erhält man ein anderes Ergebnis und es muss eine Fehlermeldung erscheinen. Dies<br />
wurde in der Praxis nachgewiesen.
Anhang B: Entwicklungsumgebung HITOP 5.2 69<br />
Anhang B: Entwicklungsumgebung HITOP 5.2<br />
In diesem Anhang findet sich eine kurze Einleitung in HITOP 5.2 gemacht. Diese Umgebung<br />
wurde benutzt um die Tests zu entwickeln und zu testen. In dieser Einleitung wird<br />
gezeigt wie ein Projekt geöffnet werden kann, sowie wie ein Projekt kompiliert, übertragen<br />
und von der Entwicklungsumgebung aus schrittweise ausgeführt wird.<br />
Um ein Projekt zu öffnen muss die IDE gestartet und das Board an den PC angeschlossen<br />
sein.<br />
Nach dem Auswählen des Projekts, kann folgende Fehlermeldung erscheinen:<br />
Auf der Tantinos Rückseite kann Nummer festgestellt werden. Diese Nummer wird später<br />
gebraucht. Nach dem es drei Mal in drei hintereinander folgenden Fenster auf die<br />
Taste „Ok“ gedrückt wird, kommt das Fenster in dem das Debbuger-Tool ausgewählt<br />
wird. In unserem Fall ist es das „Tantino for ARM 7-9“.
Anhang B: Entwicklungsumgebung HITOP 5.2 70<br />
Nach diesem Fenster kommt das nächste in dem die ermittelte Tantino-Nummer eingegeben<br />
wird:<br />
Nach dem Verbinden mit dem Tantino wird abgefragt, ob das Projekt in den Flasch-<br />
Speicher des Boards geschrieben werden soll. Dücken Sie auf „Ok“<br />
Das Downloaden dauert einige Sekunden. Nach dem Download kann das Projekt bearbeitet<br />
werden.
Anhang B: Entwicklungsumgebung HITOP 5.2 71<br />
Die IDE verfügt über mehrere Fenster wie Speicherinhalt und Registerinhalt. Aus dem<br />
Fenster „Workspace“ können einzelne Dateien geöffnet und bearbeiten werden. Jedoch<br />
um die Dateien zu bearbeiten muss in den Editor-Modus gewechselt werden mit Hilfe<br />
von Tastenkombination „STRG+T“, eine weitere Betätigung dieser Tasten führt wieder in<br />
den Debugger-Modus zurück.<br />
In dem Debugger-Modus stehen weitere Möglichkeiten zur Verfügung:<br />
Nach der Bearbeitung von Dateien können diese kompiliert und auf das Board übertragen<br />
werden:
Abkürzungsverzeichnis 72<br />
Abkürzungsverzeichnis<br />
ADC Analog Digital Converter<br />
ALU Arithmetical Logical Unit<br />
ARM Advanced RISC Machine<br />
ARM7TDMI Advanced RISC Machine 7<br />
BIA Berufgenossenschaftliches Institut <strong>für</strong> Arbeitschutz<br />
BGIA Berufgenossenschaftliches Institut <strong>für</strong> Arbeitschutz<br />
CISC Complex Instruction Set Computer<br />
CPU Central Processing Unit<br />
CRC Cyclic Redundancy Check<br />
DAC Digital Analog Converter<br />
DIN Deutsche Institut <strong>für</strong> Normung<br />
DRAM Dynamic Random Access Memory<br />
EN Europäsche Norm<br />
GALPAT Galloping Pattern<br />
GCC GNU Compiler Collection<br />
IEC International Electrotechnical Commission<br />
I/O Input / Output<br />
JTAG Joint Test Action Group<br />
MP3 MPEG-1 Audio Layer 3<br />
PDA Personal Digital Assistant<br />
RAM Random Access Memory<br />
RISC Reduced Instruction Set Computer<br />
ROM Read Only Memory<br />
SRAM Static Random Access Memory<br />
UART Universal Asynchronous Receiver Transmitter<br />
USB Universal Serial Bus<br />
VDE Verband der Elektrotechnik Elektronik Informationstechnik<br />
WD Watchdog