Aufbau eines homogen redundanten Rechnersystems und

Transcrição

Bachelorthesis
Aufbau eines homogen redundanten Rechnersystems und
Untersuchung des Ausfallverhaltens unter Umgebungseinflüssen
Hochschule Bonn-Rhein-Sieg
Fachbereich Informatik
Studiengang:
Bachelor of Computer Science / Embedded Systems
Grantham-Allee 20
53757 Sankt Augustin
Vorgelegt von:
Maxim Küpper
Erstprüfer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prof. Dr. Dietmar Reinert
Zweitprüfer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr. Michael Schaefer
Eingereicht am: 15. April 2009
Eidesstattliche Erklärung
Ich versichere an Eides statt, die von mir vorgelegte Arbeit selbstständig verfasst
zu haben. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht
veröffentlichten Arbeiten anderer entnommen sind, habe ich als entnommen kenntlich gemacht. Sämtliche Quellen und Hilfsmittel, die ich für die Arbeit benutzt habe,
sind angegeben. Die Arbeit hat mit gleichem Inhalt bzw. in wesentlichen Teilen noch
keiner anderen Prüfungsbehörde vorgelegen.
(Datum, Ort, Unterschrift)
Danksagung
An dieser Stelle möchte ich mich bei meinen beiden Prüfern, Prof. Dr. Dietmar Reinert und Dr. Schaefer, für die Ermöglichung und die hilfreiche Unterstützung bei
der Erstellung meiner Bachelor-Thesis bedanken. Ohne sie wäre diese Arbeit nicht
möglich gewesen.
Weiterhin danke ich auch den Mitarbeitern des BGIA in Sankt Augustin. Hervorzuheben sind hierbei Herr K.-H. Büllesbach, Herr W. Grommez, Herr A. Lungfiel
und Herr T. Seifen, die mir mit Rat und Tat zur Seite standen.
Zum Schluss möchte ich mich noch bei meiner Familie und meinen Freunden für
ihre Unterstützung und ihr Verständnis bedanken.
Inhaltsverzeichnis
Seite IV
Inhaltsverzeichnis
Inhaltsverzeichnis
IV
Abbildungsverzeichnis
VII
Abkürzungsverzeichnis
IX
Quellcodeverzeichnis
XI
1 Einleitung
1.1 Thema und Ziele der Arbeit . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . .
1.3 Lösungsansatz . . . . . . . . . . . . . .
1.4 Eingesetzte Techniken für mehrkanalige
. . . . . . .
. . . . . . .
. . . . . . .
Strukturen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
2
2 Anforderungen an sicherheitsgerichtete Maschinensteuerungen
2.1 Performance Level . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Schwere der Verletzung . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Häufigkeit und/oder Dauer der Gefährdungsexposition . . . .
2.1.3 Möglichkeit zur Gefahrenabwendung oder Begrenzung des Schadens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Kategorie B . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Kategorie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Kategorie 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Kategorie 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Kategorie 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Mittlere Zeit bis zum gefahrbringenden Ausfall . . . . . . . . . . . . .
2.4 Diagnosedeckungsgrad . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Fehler infolge gemeinsamer Ursache . . . . . . . . . . . . . . . . . . .
6
7
7
8
9
10
11
11
12
12
3 Technische Realisierung
3.1 AVR Butterfly . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Atmel ATMega169P . . . . . . . . . . . . . . . . . . .
3.1.2 Peripherie . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 AVR Butterfly Carrier . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Universal Asynchronous Receiver Transmitter (UART)
3.2.2 In-System-Programmer (ISP) . . . . . . . . . . . . . .
3.2.3 Joint Test Action Group - Port (JTAG) . . . . . . . .
3.3 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Revision 1 . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Revision 2 . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Revision 3 . . . . . . . . . . . . . . . . . . . . . . . . .
14
14
15
16
16
17
19
19
20
21
22
23
Maxim Küpper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
6
6
Inhaltsverzeichnis
4 Entwickelte Software
4.1 Anforderungen . . . . . . . . . .
4.2 Grundlagen . . . . . . . . . . . .
4.3 Struktur . . . . . . . . . . . . . .
4.4 Konfigurationsmöglichkeiten . . .
4.5 Fehlerbeherrschende Maßnahmen
4.5.1 Synchronisation . . . . . .
4.5.2 Fehlerroutinen . . . . . . .
4.5.3 Watchdog . . . . . . . . .
Seite V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Selbsttests
5.1 CPU-Tests . . . . . . . . . . . . . . . .
5.1.1 Arithmetische Tests . . . . . . .
5.1.2 Registertests . . . . . . . . . . .
5.1.3 Push-Pop-Return-Jump-Test . .
5.1.4 Test der logischen Operationen
5.1.5 Tests der Bit-Operationen . . .
5.1.6 Test der Transfer-Befehle . . . .
5.2 Peripherie Tests . . . . . . . . . . . . .
5.2.1 Watchdog . . . . . . . . . . . .
5.2.2 Tests der integrierten Timer . .
5.2.3 RAM-Test . . . . . . . . . . . .
5.2.4 ROM-Test . . . . . . . . . . . .
5.2.5 Ports als Ein- und Ausgänge . .
5.3 Bibliothek der Tests . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Beobachtung des Verhaltens unter Umgebungsbedingungen
6.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . .
6.2 Elektromagnetische Verträglichkeit . . . . . . . . . . . . .
6.2.1 Kapazitive Kopplung . . . . . . . . . . . . . . . . .
6.2.2 Elektrostatische Entladung . . . . . . . . . . . . . .
6.2.3 Unterbrechung der Versorgungsspannung . . . . . .
6.2.4 Austastung der Versorgungsspannung . . . . . . . .
6.2.5 Analyse der EMV-Untersuchungen . . . . . . . . .
6.3 Temperaturbeständigkeit . . . . . . . . . . . . . . . . . . .
6.3.1 Positiver Temperaturbereich . . . . . . . . . . . . .
6.3.2 Negativer Temperaturbereich . . . . . . . . . . . .
6.3.3 Analyse der Temperaturmessungen . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
27
30
30
32
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
37
37
40
41
43
44
45
45
46
48
49
51
53
54
.
.
.
.
.
.
.
.
.
.
.
58
58
59
59
63
64
65
66
67
68
69
69
7 Zusammenfassung
71
7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Literaturverzeichnis
73
A Quellcode
A.1 Quellcode Main-App.c . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Quellcode Main-App.h . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Quellcode TestLib.c . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
75
91
93
Inhaltsverzeichnis
Seite VI
A.4 Quellcode TestLib.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B Tabelle der Anforderung für Kategorien
106
C Schaltplan
108
D CD-ROM mit Inhalten der Bachelor-Thesis
109
Seite VII
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Ausfallwahrscheinlichkeit nach Performance Level . . . .
Risikograph zur Bestimmung des PLr . . . . . . . . . . .
Säulendiagramm zur vereinfachten Bestimmung des PL .
Architektur eines Kategorie B bzw. Kategorie 1-Systems
Architektur eines Kategorie 2-Systems . . . . . . . . . .
Zuordnung des MTTFd zu Betriebsjahren . . . . . . . . .
Übersicht des Diagnosedeckungsgrad . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
7
8
9
10
11
12
13
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Butterfly . . . . . . . . . . . . . . . . . . . . .
AVR Butterfly Carrier . . . . . . . . . . . . .
Datenübertragung mittels EIA-232 . . . . . .
Mögliche Übertragungsfehler von Bussystemen
Revision 1 des Versuchsaufbau . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
17
18
18
22
22
23
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Struktur der Initialisierung und der Betriebsbereitschaft
Struktur der Hauptroutine . . . . . . . . . . . . . . . . .
Tabelle der Laufzeitanzeige . . . . . . . . . . . . . . . . .
Tabelle der Betriebsmodi . . . . . . . . . . . . . . . . . .
Struktur der Synchronisationsroutine . . . . . . . . . . .
Tabelle der Fehlercodes . . . . . . . . . . . . . . . . . . .
Struktur der Fehlerroutinen . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
26
27
30
34
34
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
Programmablauf des Tests für die Addition . . . . . . . . .
Programmablauf des ADDC-Tests . . . . . . . . . . . . . .
Programmablauf der Registertests . . . . . . . . . . . . . .
Abschnitt 1 des PPRJ-Test: PUSH-Test . . . . . . . . . .
Abschnitt 2 des PPRJ-Test: POP-Test . . . . . . . . . . .
Abschnitt 3 des PPRJ-Test: RETURN und JUMP-Test . .
Programmablauf des Test der logischen AND-Verknüpfung
Test des Befehls für das indirekte Laden von Registern . .
Test der Timer auf korrekte Funktionsweise . . . . . . . .
Struktur des ROM-Tests. . . . . . . . . . . . . . . . . . . .
Struktur der Test-Bibliothek . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
41
42
43
44
46
49
52
55
6.1
6.2
6.3
6.4
6.5
Prinzip des Interferenzen-Problems . . . . . . . .
Positiver Impuls (rot) und Impulsfolge (blau) . .
Störung der Übertragung durch gekipptes Bit . .
Versuchsaufbau 1b - serielle Schnittstelle zu GND
Sichtbare ESD-Entladung . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
60
61
62
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Seite VIII
6.6 Versuchsaufbau: Spannungsunterbrechung . . . . . . . . . . . .
6.7 Zeitlicher Verlauf der Spannung . . . . . . . . . . . . . . . . . .
6.8 Schematischer Temperaturverlauf, positiver Temperaturbereich .
6.9 Schematischer Temperaturverlauf, negativer Temperaturbereich
.
.
.
.
.
.
.
.
.
.
.
.
65
66
68
69
B.1 Tabelle der Anforderung für Kategorien . . . . . . . . . . . . . . . . . 107
C.1 Schaltplan eines Kanals . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.1 Ordnerstruktur der CD-ROM . . . . . . . . . . . . . . . . . . . . . . 109
Seite IX
µC . . . . . . . . . . . . . . . . . . Mikrocontroller
ADC . . . . . . . . . . . . . . . Analog/Digital - Converter
Analog/Digital - Wandler
AVR . . . . . . . . . . . . . . . . Bezeichnung einer µC-Familie von ATMEL
CCF . . . . . . . . . . . . . . . . Common Cause Failure
Ausfälle infolge gemeinsamer Ursachen
CRC . . . . . . . . . . . . . . . . Cyclic Redundancy Check
Zyklische Redundanzprüfung
DC . . . . . . . . . . . . . . . . . Diagnostic Coverage
Diagnosedeckungsgrad
DCavg . . . . . . . . . . . . . . Average Diagnostic Coverage
Durchschnittlicher Diagnosedeckungsgrad
EEPROM . . . . . . . . . . Electrically Erasable Programmable Read Only Memory
Nicht flüchtiger, elektronischer Speicher
ELF . . . . . . . . . . . . . . . . Executable and linkable format
Dateiformat für µC-Programmierung
EM . . . . . . . . . . . . . . . . . Elektromagnetisch
EMV . . . . . . . . . . . . . . . Elektromagnetische Verträglichkeit
ESD . . . . . . . . . . . . . . . . Elektostatic Discharge
Elektrostatische Entladung
I/O . . . . . . . . . . . . . . . . . Input / Output
ICE . . . . . . . . . . . . . . . . In-Circuit-Emulator
ISP . . . . . . . . . . . . . . . . . In-System-Programmer, auch In-System-Programming
JTAG . . . . . . . . . . . . . . Joint Test Action Group
LCD . . . . . . . . . . . . . . . . Liquid Crystal Display
Flüssigkristall Display
MTTFd . . . . . . . . . . . . . Mean Time to Dangerous Failure
Mittlere Zeit bis zu einem gefahrbringenden Ausfall
PAP . . . . . . . . . . . . . . . . Programmablaufplan
PCB . . . . . . . . . . . . . . . . Printed Circuit Board
Elektronische Leiterplatte
PFH . . . . . . . . . . . . . . . . Probability of Dangerous Failure per Hour
Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde
PL . . . . . . . . . . . . . . . . . Performance-Level
PLr . . . . . . . . . . . . . . . . . Performance Level required
Benötigtes Performance Level
RAM . . . . . . . . . . . . . . . Random Access Memory
Speicher mit wahlfreiem Zugriff
RISC . . . . . . . . . . . . . . . Reduced Instruction Set Computing
Rechnen mit reduziertem Befehlssatz
ROM . . . . . . . . . . . . . . . Read only Memory
Nur-Lese-Festwertspeicher
SRP/CS . . . . . . . . . . . . Safety-Related Parts of Control System
Sicherheitsbezogene Teile einer Steuerung
UART . . . . . . . . . . . . . . Universal Asynchronous Receiver Transmitter
USB . . . . . . . . . . . . . . . . Universal Serial Bus
USI . . . . . . . . . . . . . . . . . Universal Serial Interface
Universelle Serielle Schnittstelle
V . . . . . . . . . . . . . . . . . . . Volt
Seite X
Seite XI
4.1
4.2
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Konfigurationsmöglichkeiten der Software . . . .
Synchronisationsroutine . . . . . . . . . . . . .
Selbsttest der Addition . . . . . . . . . . . . . .
Selbsttest der bitweisen Verschiebung nach links
Watchdog-Prüfroutine am Programmbeginn . .
Watchdog-Test . . . . . . . . . . . . . . . . . .
RAM-Test . . . . . . . . . . . . . . . . . . . . .
Porttest . . . . . . . . . . . . . . . . . . . . . .
Beispiel: Aufruf der Selbsttests . . . . . . . . . .
Beispielhafte Implementierung der testError() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
32
38
45
47
48
50
53
55
57
1 Einleitung
Seite 1
1 Einleitung
1.1 Thema und Ziele der Arbeit
Gemäß der Norm DIN EN ISO 13849-1, die sich mit sicherheitsbezogenen Teilen von
Maschinensteuerungen befasst, müssen diese Teile einer Steuerung mit Maßnahmen
gegen Ausfälle infolge gemeinsamer Ursachen ausgestattet sein. Die Anforderungen
an diese Maßnahmen sehen vor, dass ein System möglichst diversitär aufzubauen ist,
um solche Ausfälle zu verhindern. Ob ein homogen redundantes System ein höheres
Risiko darstellt, da es gegen die Art dieser Ausfälle nicht ausreichend geschützt ist,
soll mit dieser Arbeit geklärt werden.
Dazu befasst sich diese Bachelorthesis mit dem Titel Aufbau eines homogen
”
redundanten Rechnersystems und Untersuchung des Ausfallverhaltens unter Umgebungseinflüssen“ mit der Erstellung eines homogen redundanten Rechnersystems,
ähnlich wie sie in Maschinensteuerungen in der Industrie verwendet werden. Im Zuge
dieser Arbeit wird ein System aus zwei Kanälen aufgebaut.
Beide Kanäle bestehen aus identischer Hardware und werden mit derselben Software betrieben. In Anlehnung an die Anforderungen an SRP/CS durch die Norm
werden wichtige Maßnahmen zur Fehlererkennung und deren Beherrschung implementiert, damit das System bei auftretenden Fehlern in den sicheren Zustand überführt wird. Trotz dieser Mechanismen wird das System keine vollwertige Struktur
einer Kategorie darstellen, sondern lediglich die grundlegenden Elemente aufweisen,
die benötigt werden, um die geplanten Untersuchungen durchzuführen.
Um eine Aussage über das Verhalten der Kanäle treffen zu können, werden diese
verschiedenen Umgebungseinflüssen ausgesetzt und das Ausfallverhalten des kompletten Rechnersystems beobachtet. Im Speziellen soll geprüft werden, ob das System aufgrund gemeinsamer Schwachpunkte in einen unsicheren Zustand gerät.
Die während der Entwicklung implementierten Selbsttests sollen zu einer Bibliothek zusammengefasst werden. Diese soll über Methoden und Parameter auf den
benötigten Leistungsumfang anpassbar sein, um anderen Projekten zur Verfügung
gestellt zu werden. Voraussetzung ist, dass diese Projekte als technische Grundlage einen ATMEL AVR-Mikrocontroller einsetzen, der über den gleichen Befehlssatz
verfügt wie ein ATMega169P.
1.2 Motivation
Seite 2
1.2 Motivation
Viele Steuereinheiten in Maschinen mit hohem Gefährdungspotential sind homogen
redundant aufgebaut. Dadurch besteht die Gefahr, dass alle Kanäle dieser Steuerung zur selben Zeit ausfallen und das gesamte Steuerungssystem einen unsicheren
Zustand hervorruft. Ob ein System mit homogen redundanter Struktur allerdings
eine höhere Ausfallwahrscheinlichkeit hat, ist nicht hinreichend geklärt. Diese Arbeit
wird versuchen eine Antwort auf diese Frage zu finden.
Der Nachteil von Diversität ist der höhere Aufwand bei der Entwicklung, Erstellung und Wartung des Systems, wodurch höhere Kosten entstehen. Bietet ein
homogenes System jedoch die gleichen Sicherheitseigenschaften wie ein diversitäres
System, sind diese Mühen unnötig und können eingespart werden.
1.3 Lösungsansatz
Um das Ziel der Arbeit zu erreichen, wird ein exemplarisches Testsystem aufgebaut dessen Verhalten unter verschiedenen Einflüssen untersucht wird. Es soll durch
zwei Mikrocontroller (µC) realisiert werden, die in ein System eingebettet und miteinander verbunden sind, um sich so zur Laufzeit synchronisieren zu können. Zur
Demonstration des Programmablaufs wird eine Applikation erstellt, die zu jeder
Zeit einen Status hat, der über eine visuelle Ausgabe ausgegeben wird. Um die
sicherheitsrelevanten Anforderungen zu erfüllen, wird eine Fehlererkennung sowie
Maßnahmen zur Fehlerbeherrschung implementiert. Dadurch soll erreicht werden,
dass das System bei unplanmäßigem Programmablauf und Fehlern in den sicheren
Zustand überführt wird.
In Untersuchungen unter verschiedenen Umgebungsvariablen wird anschließend
das Verhalten des Systems beobachtet. Konkret wird die Eignung eines homogen
redundanten Systems zur Erfüllung der Anforderung nach der Norm DIN EN ISO
13849-1 geprüft. Diese Untersuchungen sollen Aufschluss darüber geben, ob es möglich
ist, beide Kanäle systematisch auszuhebeln und so das Rechnersystem in den unsicheren Zustand zu bringen. Tritt dieser Fall ein, ist gezeigt, dass homogene Redundanz nicht geeignet ist, um Maßnahmen gegen Ausfälle infolge gemeinsamer Ursache
zu realisieren.
1.4 Eingesetzte Techniken für mehrkanalige Strukturen
Neben nicht elektronischen, pneumatischen oder mechanischen Sicherheitsvorkehrungen gibt es auch sicherheitsrelevante Teile einer Steuerung auf elektronischer
Basis. Mehrkanalige Strukturen können dabei homogen oder diversitär realisiert
werden.
1.4 Eingesetzte Techniken für mehrkanalige Strukturen
Seite 3
Homogene Redundanz
Strukturen mit homogener Redundanz basieren auf den gleichen technischen Grundlagen. So sind gleiche Bauteile verbaut, die in der Theorie die gleichen Schwachpunkte haben. Durch die Verwendungen derselben Software sind alle Kanäle mit
den selben systematischen Softwarefehlern behaftet.
Diversitäre Redundanz
Diversitäre Redundanz basiert hingegen darauf, Systeme mit unterschiedlichen technischen Grundlagen aufzubauen. Theoretisch ist dadurch die Wahrscheinlichkeit eines Ausfalls infolge gemeinsamer Ursache deutlich geringer, da sowohl die Hardware
als auch die betreibende Software nicht gleich sind. Das führt dazu, dass durch
äußere Einflüsse ein unterschiedliches Ausfallverhalten für jeden Kanal entsteht.
2 Anforderungen an sicherheitsgerichtete Maschinensteuerungen
Seite 4
2 Anforderungen an sicherheitsgerichtete
Maschinensteuerungen
2.1 Performance Level
Von vielen industriellen Maschinen gehen aufgrund ihrer Aufgabe, ihrer Beschaffenheit oder ihrer Handhabung Gefährdungen für die Menschen in näherer Umgebung
aus. Um diese Gefährdungen zu reduzieren, sind verschiedene Sicherheitsvorkehrungen zu treffen. Diese Vorkehrungen können nicht immer durch konstruktive Maßnahmen getroffen werden, wodurch die Notwendigkeit von sicheren Steuerungen der
Maschinen entsteht. Da sich die Gefährdungen je nach Beschaffenheit und Einsatzzweck unterscheiden - zumal von einer Maschine meistens mehr als eine Gefährdung
ausgeht - ist es notwendig, diese Gefährdungen einschätzen und bewerten zu können,
um somit ökonomisch angemessene Vorkehrungen zu treffen.
Abbildung 2.1: Ausfallwahrscheinlichkeit nach Performance Level
[BGIA08, S. 37]
Dazu werden nach der Norm DIN EN ISO 13849-1 die von einer Maschine ausgehenden Gefährdungen identifiziert. Anschließend wird jeder Gefährdung eine Sicherheitsfunktion, mit dem Ziel die Gefährdung zu reduzieren, zugeordnet. Zu jeder
notwendigen Sicherheitsfunktion muss ein sicherheitsbezogenes Teil der Steuerung
(Safety-Related Parts of Control System, SRP/CS) erstellt werden, das diese Funk-
Seite 5
tion ausführen soll. Der Performance Level (PL) dieses SRP/CS orientiert sich am
geforderten Performance Level (Performance Level required, PLr ), der durch die
Gefährdung vorgegeben wird. Um die Anforderungen der DIN EN ISO 13849-1 zu
erfüllen, muss das SRP/CS den PLr erreichen.
Der Performance Level beschreibt die Wahrscheinlichkeit eines gefahrbringenden
Ausfalls des Systems mit Verlust der Sicherheitsfunktion. Die Zuordnung der Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde (PFH) zu einem der fünf PL (a
bis e) ist der Abbildung 2.1 zu entnehmen.
Der geforderte Performance Level kann beispielsweise mittels des Risikographen
nach DIN EN ISO 13849-1 - Abbildung 2.2 - bestimmt werden. Dafür wird der Graph
anhand von drei Risikoparametern durchlaufen, die als Entscheidungskriterien für
die Einstufung der Gefährdung dienen. Folgende Parameter werden in Betracht gezogen:
• S - Schwere der Verletzung
• F - Häufigkeit und/oder Dauer der Gefährdungsexposition
• P - Möglichkeit zur Gefahrenabwendung oder Begrenzung des Schadens
Abbildung 2.2: Risikograph zur Bestimmung des PLr
[BGIA08, S. 30]
Seite 6
2.1.1 Schwere der Verletzung
Die Schwere der Verletzung wird dabei in zwei Kategorien unterteilt:
• S1 - leichte, überlicherweise reversible Verletzungen
• S2 - schwere, nicht reversible Verletzungen einschließlich Tod
Zu beachten ist, dass vom Worst-Case ausgegangen werden muss. Nicht jeder Fehler einer gefahrbringenden Maschine führt zu einer tödlichen Verletzung, es genügt
jedoch, dass allein die Möglichkeit besteht, eine derart ernste Verletzung herbei zu
führen.
2.1.2 Häufigkeit und/oder Dauer der Gefährdungsexposition
Ebenso wird die Häufigkeit und/oder die Dauer der Gefährundgsexposition in zwei
Kategorien unterteilt:
• F1 - selten bis weniger häufig und/oder die Dauer der Gefährdungsexposition
ist kurz
• F2 - häufig bis dauernd und/oder die Dauer der Gefährdungsexposition ist
lang
Wichtig hierbei ist nicht zu unterscheiden, welche Person, sondern wie oft und wie
lange Personen der Gefahr ausgesetzt sind. Eine genaue Klassifizierung der Häufigkeit oder der Dauer wird in der Norm nicht genannt. Eine Anmerkung besagt aber,
dass F2 gewählt werden soll, wenn die Frequenz der Gefährdungsexposition größer
als einmal pro Stunde ist und keine anderen Festlegungen getroffen wurden.
2.1.3 Möglichkeit zur Gefahrenabwendung oder Begrenzung des Schadens
Die Möglichkeit zur Gefahrenabwendung beschreibt, ob der Bediener einer Maschine
eine Verletzung noch abwenden kann, wenn er feststellt, dass die Maschine sich nicht
wie vorgesehen verhält. Die zwei Möglichkeiten sind:
• P1 - möglich unter bestimmten Bedingungen
• P2 - kaum möglich
Dabei ist zu beachten, ob ein Bediener auf eine auftretende Gefahr überhaupt
reagieren kann und wenn ja, welche Chance er hat, diese Gefahr abzuwenden. Auch
die physikalischen Eigenschaften des Systems müssen in diese Bewertung einfließen.
[BGIA08, S. 26ff]
2.2 Kategorien
Seite 7
Der von den sicherheitsbezogenen Teilen einer Steuerung erreichte Performance Level wird durch die erzielte Kategorie, der mittleren Zeit bis zum gefahrbringenden
Ausfall der verwendeten Bauteile (MTTFd , vgl. Abschnitt 2.3, S. 11), dem Diagnosedeckungsgrad der Tests (DC, vgl. Abschnitt 2.4, S. 12) und den Maßnahmen gegen
Ausfälle infolge gemeinsamer Ursache (CCF, vgl. Abschnitt 2.5, S. 12) bestimmt.
Abbildung 2.3 zeigt die vereinfachte Methode der Norm, um den Performance
Level aus der Kategorie, dem durchschnittlichen Diagnosedeckungsgrad (DCavg , vgl.
Abschnitt 2.4, S. 12) und der MTTFd zu ermitteln.
Abbildung 2.3: Säulendiagramm zur vereinfachten Bestimmung des PL
[BGIA08, S. 56]
2.2 Kategorien
Die Kategorien beschreiben nach DIN EN ISO 13849-1 den strukturellen Aufbau
und Aspekte der Zuverlässigkeit von SRP/CS. Zusammen mit den anderen, sicherheitsrelevanten Parametern - MTTFd , DCavg und Maßnahmen gegen CCF - sind sie
daher ein geeignetes Maß, um die Widerstandsfähigkeit von Steuerungen gegenüber
Fehlern zu beschreiben.
2.2.1 Kategorie B
Diese Kategorie dient als Grundlage für alle Kategorien. Sie setzt voraus, dass die
SRP/CS unter Verwendung von grundlegenden Sicherheitsprinzipien entwickelt werden. Weiterhin müssen alle Bauteile den zu erwartenden Belastungen standhalten
können, d.h. im Speziellen den Betriebsbeanspruchungen sowie dem Einfluss von
Materialien, die im Arbeitsprozess verwendeten werden. Da ein Kategorie B-System
2.2 Kategorien
Seite 8
nicht kontrolliert ob die Sicherheitsfunktion ausgeführt wird und auch nicht mehrkanalig aufgebaut ist, kann es im Falle eines Fehlers zum unbemerkten Ausfall der
Sicherheitsfunktion kommen. Die Anforderungen an die MTTFd sind niedrig bis
mittel (vgl. Anhang B).
Alle höheren Kategorien setzen nach DIN EN ISO 13849-1 die Anforderungen der
Kategorie B voraus und erweitern diese um strengere Anforderungen. Abbildung 2.4
zeigt die allgemeine Architektur nach der Kategorie B. Diese muss nicht zwangsläufig
für die Realisierung einer SRP/CS genutzt werden, eine Abweichung muss jedoch
hinreichend begründet werden.
Der maximale Performance Level, der mit einem Kategorie B-System erreicht
werden kann, ist PL = b (vgl. Abbildung 2.3).
Abbildung 2.4: Architektur eines Kategorie B bzw. Kategorie 1-Systems
[BGIA08, S. 48]
2.2.2 Kategorie 1
Anders als bei Kategorie B, die keine hohe Zuverlässigkeit von den verwendeten Bauteilen verlangt, fordert Kategorie 1 bewährte Bauteile. Ein Bauteil gilt als bewährt,
wenn es in der Vergangenheit für ähnliche Anwendungen mit Erfolg eingesetzt wurde
oder unter Anwendung von Prinzipien hergestellt und verifiziert wurde, die seine Eignung und Zuverlässigkeit für sicherheitsbezogene Anwendungen zeigen. Die SRP/CS
muss über eine hohe MTTFd verfügen (vgl. Anhang B). Weiterhin müssen alle Anforderungen der Kategorie B erfüllt werden, wie beispielsweise die Entwicklung unter
Verwendung von grundlegenden Sicherheitsprinzipien.
Die allgemeine Architektur entspricht der von Kategorie B, die in Abbildung 2.4
dargestellt ist. Kategorie 1 stellt keine Anforderungen an DCavg oder CCF, da es
sich, wie bei Kategorie B, um einkanalige Strukturen handelt. Daher kann auch
das Auftreten eines Fehlers zum Verlust der Sicherheitsfunktion führen. Trotzdem
muss die Wahrscheinlichkeit eines Ausfalls kleiner sein als bei einem System der
Kategorie B.
Anmerkung 1 der Norm zur Kategorie 1 besagt, dass komplexe elektronische Bauteile nicht als bewährte Bauteile gesehen und daher in Systemen der Kategorie 1
nicht eingesetzt werden können.
2.2 Kategorien
Seite 9
Mit einem Kategorie 1-System kann ein maximaler Performance Level von PL = c
erreicht werden (vgl. Abbildung 2.3).
2.2.3 Kategorie 2
Ab Kategorie 2 wird eine Testung der Sicherheitsfunktion vorausgesetzt. So müssen
SRP/CS dieser Kategorie, nach DIN EN ISO 13849-1, in angemessenen Zeitabständen durch die Maschinensteuerung auf korrekte Arbeitsweise überprüft werden. Die
Sicherheitsfunktion muss getestet werden, wenn die Maschine anläuft oder die Einleitung einer Gefährdungssituation erfolgt.
Anmerkung 2 ergänzt, dass die Sicherheitsfunktion zwischen den einzelnen Tests
ausfallen darf, dieser Ausfall jedoch durch die Tests zum Testzeitpunkt erkannt
werden muss. Daher muss die Testrate deutlich höher sein als die mittlere Anforderungsrate der Sicherheitsfunktion. Bei der vereinfachten Bestimmung des PLs einer
SRP/CS mittels des in Abbildung 2.3 dargestellten Säulendiagramms wird daher
von einer 100-mal höheren Testrate ausgegangen.
Die durchgeführten Tests dürfen nicht zu einer Gefährdungssituation führen. Sollte es zu einem Fehler der SRP/CS kommen, so verfügt die Testeinrichtung über einen
unabhängigen Abschaltpfad, der die Maschine in den sicheren Zustand versetzen
kann.
Die gestellten Anforderungen an die MTTFd oder den DCavg gelten hierbei nur für
die Bauteile der SRP/CS, nicht für die der Testeinrichtung. Zu den Anforderungen
der Kategorie 2 gehören auch Maßnahmen gegen CCF. Abbildung 2.5 zeigt die
allgemeine Architektur einer SRP/CS der Kategorie 2.
Der maximal realisierbare Performance Level einer Kategorie 2-Systems liegt bei
PL = d (vgl. Abbildung 2.3).
Abbildung 2.5: Architektur eines Kategorie 2-Systems
[BGIA08, S. 49]
2.2 Kategorien
Seite 10
2.2.4 Kategorie 3
Die Anforderungen nach der Kategorie 3 sehen vor, dass ein Fehler nicht zum Ausfall der Sicherheitsfunktion führen darf. Damit soll verhindert werden, dass bedingt
durch einen einzelnen Fehler die Sicherheitsfunktion nicht mehr ausgeführt werden kann, wodurch eine Gefährdungssituation entstehen würde. Auftretende Fehler
müssen bei oder vor der nächsten Anforderung der Sicherheitsfunktion erkannt werden. Meistens wird dies durch eine zweikanalige Struktur, wie die Architektur in
Abbildung 2.6 darstellt, gelöst.
Es ist jedoch möglich, Einfehlersicherheit ohne Redundanz zu realisieren. Die Verwendung mehrere Kanäle kann durch ein fehlersicheres Design - inhärente Sicherheit
- ersetzt werden. Auch ein eigener Abschaltpfad mit hochwertiger Überwachung der
Logik des SRP/CS, der im Fehlerfall den sicheren Zustand des Systems so schnell
einleitet, dass ein gefährlicher Zustand vermieden wird, kann als Alternative genutzt
werden.
Auch gegen Ausfälle infolge gemeinsamer Ursachen müssen entsprechende Maßnahmen getroffen werden. Ein Fehler muss jedoch nur erkannt werden, wenn dies
mit einem angemessenen Aufwand realisierbar ist. Daher wird, wie in Kategorie 2,
ein DCavg im Bereich zwischen niedrig und mittel gefordert. Für eine Struktur der
Kategorie 3 wird eine MTTFd von mindestens niedrig vorausgesetzt (vgl. Anhang
B).
Sowohl Kategorie 3, wie auch die folgende Kategorie 4, können einen maximalen
Performance Level von PL = e erreichen (vgl. Abbildung 2.3).
[BGIA08, S. 50]
2.3 Mittlere Zeit bis zum gefahrbringenden Ausfall
Seite 11
2.2.5 Kategorie 4
Kategorie 4 beinhaltet im wesentlichen alle Anforderungen der Kategorie B und der
Kategorie 3. Zusätzlich verschärft sie einige der Anforderungen.
Die Architektur dieser Kategorie entspricht, bis auf die Überwachung der Ausgänge
und dem Kreuzvergleich der SRP/CS, der der Kategorie 3. Die Überwachung der
Ausgänge und der Kreuzvergleich sind zwar auch in der Architektur der Kategorie 3 vorhanden, müssen jedoch nur eine angemessene Rate haben. In Kategorie 4
müssen alle Fehler erkannt werden, was in Abbildung 2.7 mittels durchgezogener Linien dargestellt wird (vgl. Abbildung 2.6). Einzelne Fehler dürfen nicht zum Ausfall
der Sicherheitsfunktion führen. Sollte eine Erkennung eines Fehlers nicht möglich
sein, so darf eine Akkumulation weiterer nicht erkannter Fehler nicht zum Verlust
der Sicherheitsfunktion führen.
MTTFd sowie DCavg jedes Kanals müssen hoch sein (vgl. Anhang B). Ebenfalls
müssen Maßnahmen gegen CCF vorhanden sein, um den Ausfall infolge gemeinsamer Ursache zu verhindern. Durch diese hohen Anforderungen kann mit einer sicherheitsrelevanten Steuerung dieser Kategorie der höchste Performance Level PL = e
realisiert werden (vgl. Abbildung 2.3).
[BGIA08, S. 50]
2.3 Mittlere Zeit bis zum gefahrbringenden Ausfall
Der von SRP/CS erreichbare Performance Level richtet sich nicht nur nach der Kategorie, sondern auch nach der Zuverlässigkeit der einzelnen Bauteile. Zwar setzen
die Kategorien eine gewisse mittlere Zeit bis zum gefahrbringenden Ausfall (Mean
Time to Dangerous Failure) voraus, jedoch kann, wie in Abbildung 2.3 (S. 7) er-
2.4 Diagnosedeckungsgrad
Seite 12
kennbar, nicht pauschal von der Kategorie auf den Performance Level geschlossen
werden. Die mittlere Zeit bis zum gefahrbringenden Ausfall wird üblicherweise in
Jahren angegeben. Die Bereiche der MTTFd -Angaben für die einzelnen Kanäle einer
SRP/CS sind der Abbildung 2.8 zu entnehmen.
Abbildung 2.8: Zuordnung des MTTFd zu Betriebsjahren
[BGIA08, S. 53]
Möglich ist auch die Lebensdauer in Ausfallraten oder Schaltspielen anzugeben,
allerdings müssen diese Werte für die Berechnung der MTTFd in Jahre umgerechnet
werden. Zu beachten ist, dass sich alle Angaben jeweils auf einen gefahrenbringenden
Ausfall beziehen. Dies bedeutet einen Ausfall der SRP/CS zur unsicheren Seite,
womit der Ausfall der Sicherheitsfunktion gemeint ist. Eine Aussage über die Anzahl
der Ausfälle in den sicheren Zustand kann mit der MTTFd nicht gemacht werden.
2.4 Diagnosedeckungsgrad
Der Diagnosedeckungsgrad (Diagnostic Coverage) ist ein weiterer Bestandteil zur
Bestimmung des PL. Er gibt an, welcher Anteil an gefahrbringenden Ausfällen erkannt werden kann. DCavg bezeichnet dabei den Prozentsatz für die gesamte sicherheitsrelevante Steuerung. Dieser fließt in den erreichbaren Performance Level mit
ein. Abbildung 2.9 zeigt die Unterteilung des DC in vier Kategorien.
2.5 Fehler infolge gemeinsamer Ursache
Desweiteren werden zur Bestimmung des Performance Level als letztes noch die
Maßnahmen zur Vermeidung von Fehlern und Ausfällen infolge gemeinsamer Ursachen (Common Cause Failure) begutachtet. Die getroffenen Maßnahmen werden
dazu gemäß DIN EN ISO 13849-1 mit Punkten bewertet:
2.5 Fehler infolge gemeinsamer Ursache
Seite 13
Abbildung 2.9: Übersicht des Diagnosedeckungsgrad
[BGIA08, S. 55]
• 25 Punkte: Schutz vor durch Verunreinigung oder durch elektromagnetischer
Beeinflussung ausgelöste CCF
• 20 Punkte: Diversitäre Gestaltung der Kanäle
• 15 Punkte: Physikalische Trennung zwischen den Signalpfaden
• 15 Punkte: Schutz gegen Überbelastung
• 10 Punkte: Schutz vor CCF, die durch anderen Einflüsse ausgelöst werden
können
• 5 Punkte: Schulung von Konstrukteuren und Monteuren gegenüber CCF
• 5 Punkte: Verwendung bewährter Bauteile
Sind insgesamt 65 der oben genannten 100 Punkten erreicht, gelten die getroffenen
Maßnahmen als ausreichend. Dies ist Voraussetzung, damit eine SRP/CS die Kategorie 2, 3 oder 4 erlangen kann. Im Säulendiagramm zur vereinfachten Bestimmung
des Performance Level - Abbildung 2.3 (S. 7) - ist daher von der Erfüllung der
Anforderung für die genannten Kategorien ausgegangen worden.
Seite 14
Um das Verhalten einer homogen redundanten Steuerung zu erforschen, wurde ein
Rechnersystem aus zwei hard- und softwaretechnisch identisch aufgebauten Kanälen
erstellt. Diese Kanäle setzen sich aus einem Butterflyboard von Atmel, dem passenden Butterfly Carrier von Ecros Technology [@Ecr09] und weiteren Peripheriegeräte,
LEDs und Programmierschnittstellen zusammen. Die Verbindung zwischen den einzelnen Systemen des Rechnersystems wird über die serielle Schnittstelle des Butterflys hergestellt.
3.1 AVR Butterfly
Bei dem AVR Butterfly handelt es sich um ein eigenständiges, abgeschlossenes System, das zu Evaluationszwecken genutzt wurde. Es zeigt die Möglichkeiten der aktuellen µC-Technologie von Atmel. Zu diesem Zweck ist es standardmäßig mit einem
ATMega169P-µC und passender Peripherie ausgestattet, wozu neben diversen Anschlussports, ein LCD-Display, ein ADC, ein Temperatursensor, ein Joystick und
ein Piezo-Element zur Ausgabe von akustischen Signalen gehören. Statt über eine
Batterie, die eine Spannung von 3 Volt (V) liefert, kann das System wahlweise auch
über eine externe Versorgung betrieben werden. Im Auslieferungszustand befindet
sich bereits ein Bootloader sowie ein rudimentäres Programm in dem Programmspeicher des µC, das einen kurzen Überblick über die Funktionen des Butterflys
gibt.
Das Butterfly stellt das Herzstück der Kanäle dar. Da es sich dabei um ein für
Evaluationszwecke erstelltes System handelt, erfüllt es nicht die Anforderungen, die
in der Industrie an Hardware gestellt werden. MTTFd -Werte sind nicht bekannt
und auch die Voraussetzung der Kategorien, beispielsweise das Entwickeln der Bauteile unter Einhaltung grundlegender Sicherheitsprinzipien, können nicht als gegeben vorausgesetzt werden. Trotz alledem war das Butterfly-Evaluationsboard für
die Untersuchungen gut geeignet, da es durch seine Ausstattung und der einfachen
Handhabung eine hohe Flexibilität bot und durch seine einfache Qualität eine Art
Worst-Case“-Szenario bildete.
”
3.1 AVR Butterfly
Seite 15
Abbildung 3.1: Butterfly
3.1.1 Atmel ATMega169P
Bei dem Prozessor handelt es sich um einen ATMega169PV, einem µC der AVRRISC-Familie des Herstellers Atmel. Der ATMega169P ist das Nachfolgermodell des
ATMega169 und basiert auf einem Re-Design zur Senkung des Stromverbrauchs.
Nach Einführung der picoPower-Technology von Atmel wurden die wichtigsten µC
in diesem Design neu aufgelegt. [@ATM08b]
Wie auch der Vorgänger ist der ATMega169P in zwei Ausführungen erhältlich.
Diese unterscheiden sich durch die maximale Taktfrequenz und die benötigte Betriebsspannung. Das V-Modell ist für stromsparende Anwendungen konzipiert und
ist dadurch mit niedrigerer Spannung, auf Kosten einer reduzierten Taktfrequenz,
arbeitsfähig. Durch die Halbierung der Taktfrequenz werden zur Inbetriebnahme
statt 2,7 V nur noch 1,8 V benötigt. Auch die maximale Taktfrequenz, die mit 8
MHz ebenfalls nur halb so hoch ist wie die des nicht V-Modells, kann bereits mit
deutlich niedrigerer Spannung von 3,3 V erreicht werden. Verglichen dazu benötigt
der große Bruder schon 4,5 V für die maximale Frequenz.
Die gesamte AVR-Mikrocontroller-Familie basiert auf der Reduced Instruction Set
Computing (RISC)-Architektur. Diese Art der µC verfügt über einen reduzierten Befehlssatz, der allerdings optimiert ist, um den Dekodierungsaufwand zu reduzieren.
Dadurch können die meisten der 130 Befehle des Befehlssatzes eines 8 Bit-AVRControllers in einem Arbeitszyklus verarbeitet werden. Dem ATMega169 stehen 32,
jeweils 8 Bit breite Arbeitsregister zur Verfügung. Diese ersetzen den üblicherweise verwendeten Akkumulator. Die unteren sechs Register können paarweise zu 16
Bit-Registern zusammengefasst werden und dienen als Pointer zur indirekten Adressierung des Datenspeichers. Insgesamt 16 Kilobyte (kB) Flashspeicher können zur
Programmspeicherung genutzt werden. Laut Herstellerangaben hat dieser eine Lebensdauer von mindestens 10.000 Zyklen, wobei ein Zyklus dabei aus dem Löschen,
dem erneutem Programmieren und anschließendem Löschen besteht. [ATM08a, S.19]
3.2 AVR Butterfly Carrier
Seite 16
3.1.2 Peripherie
Neben dem µC ist das AVR Butterfly noch mit weiterer Peripherie ausgestattet
worden, wodurch es - in einem gewissen Rahmen - komplett ohne zusätzliche Hardware eingesetzt werden kann. Die zusätzliche Peripherie wurde bereits in Abschnitt 3
(S. 14) erwähnt und wird im folgenden näher beschrieben.
Das LCD-Display verfügt über 100 Segmente und kann sechs Stellen darstellen.
Es ist bereits an die vom Controller vorgesehen Ports angebunden und wird bei der
Demo-Applikation des Butterflys zur Ausgabe des Menüs genutzt. Neben dem Display befindet sich ein Joystick. Dieser hat vier Richtungen, in die er bewegt werden
kann. Weiterhin ist es möglich den Joystick in Ausgangsposition nach unten - zur
Platine (PCB) - zu drücken, wodurch ein fünfter Kontakt geschlossen werden kann.
Wie das Display ist auch der Joystick bereits angeschlossen. Eingaben über den Joystick werden an Port B und Port E registriert. Port B und Port D sind Ports, die auf
dem PCB des Butterflys zum Anschließen vorbereitet sind, um einfacher verwendet
werden zu können. Wie der Abbildung 3.1 entnommen werden kann, befinden sich
die Anschlussmöglichkeiten der beiden Ports unter dem Display; dort ist auch die
Schnittstelle für den JTAG-Anschluss beziehungsweise den A/D-Wandler. Diese Anschlüsse werden beim Einsatz mit einem Butterfly Carrier Trägerboard - Abschnitt
3.2 - mit Hilfe von Steckverbindungen mit der Prototypfläche des Butterfly Carrier
verbunden. Ebenfalls über Steckverbindungen werden die serielle Schnittstelle und
der ISP - Abschnitt 3.2.2 (S. 19) - angeschlossen.
Auf der Rückseite befindet sich ein Piezo-Element, mit dem es möglich ist, akustische Signale auszugeben. Außerdem ist dort ein Temperatursensor verbaut, der
durch einen Widerstand mit einem negativen Temperaturkoeffizienten realisiert wurde.
Der AVR Butterfly Carrier ist als Trägerboard für das Butterfly gedacht. Wird
das Butterfly mit dem Carrier verbunden, können die in Abschnitt 3.1.2 erwähnten
Anschlüsse leichter verwendet werden, da sie mit der experimentellen Fläche - der
Prototypfläche - des Carrier oder mit vorgesehen Steckvorrichtungen verbunden sind.
Über einen Hohlstecker kann ein Gleichstrom-Netzteil an den Carrier angeschlossen werden, das sowohl das Butterflyboard als auch sämtliche Peripherie auf der
Prototypfläche mit Strom versorgen kann. Um eine Verpolung auszuschließen, ist eine Diode hinter dem Versorgungsstecker verbaut, die Beschädigung oder Zerstörung
von Bauteilen im System durch falsch gepolte Stromversorgung verhindert. Der verbaute Spannungsregler, ein LF33CV, regelt eine eingehende Gleichspannung von
maximal 40 V in eine 3,3 V Ausgangsspannung um. [STM]
Seite 17
Abbildung 3.2: AVR Butterfly Carrier
Folgende Schnittstellen und Ports werden durch den Carrier zur weiteren Beschaltung bereit gestellt:
• Serielle Schnittstelle
• In-System-Programmer (ISP)
• Joint Test Action Group - Port (JTAG)
• Port B & Port D
• Analog/Digital-Konverter (ADC)
• Universelle Serielle Schnittstelle (USI)
3.2.1 Universal Asynchronous Receiver Transmitter (UART)
Der Universal Asynchronous Receiver Transmitter (UART) ist das elektronische
Bauelement des µC, das zur Realisierung der seriellen Schnittstelle benötigt wird.
Er wird mit der auf dem AVR Butterfly Carrier befindlichen EIA-232 Buchse verbunden. Die entstehende EIA-232 Schnittstelle - ehemals als RS-232 bekannt - wurde
im Rahmen dieser Arbeit zur Vernetzung der Kanäle verwendet. Darauf gesendete
Daten werden in, jeweils aus einem Zeichen bestehenden, Paketen verschickt. Diese
Pakete haben ein Start- und Stopp-Bit, die dem Empfänger zur Synchronisation
dienen. Übertragen wird, wie Abbildung 3.3 entnommen werden kann, mittels negativer Logik, was bedeutet, dass eine 1 Ruhe auf dem Medium und eine 0 ein Signal
ist.
Seite 18
Abbildung 3.3: Datenübertragung mittels EIA-232
Wie auch bei den in der Industrie eingesetzten Bus-Systemen, kann es bei einer
Kommunikation über die serielle Schnittstelle zu Problemen kommen. Abbildung
3.4 zeigt mögliche Fehler. Tritt einer dieser Fehler auf, kann das im Worst-Case
zu einem gefährlichen Zustand führen. Um dies zu vermeiden, sind in der Software fehlerbehandelnde Maßnahmen implementiert (vgl. Abschnitt 4.5.1, S. 30), die
auftretende Übertragungsfehler erkennen und behandeln können.
Abbildung 3.4: Mögliche Übertragungsfehler von Bussystemen
[Rei01, S. 33]
Die Programmierung des ATMega169P über die serielle Schnittstelle ist möglich,
vorausgesetzt auf dem µC befindet sich ein Bootloader, der vom PC gesendete Daten empfangen und im Programmspeicher ablegen kann. Im Auslieferungszustand
Seite 19
verfügt der Controller bereits über einen Bootloader mit dieser Fähigkeit, der auch
beim Aufspielen neuer Software über die EIA-232 nicht überschrieben wird. Die im
Programmspeicher befindliche Software wird jedoch durch die neu überspielte ersetzt. Ein Nachteil der Programmierung über die serielle Schnittstelle ist, dass das
Programm nicht automatisch bei Inbetriebnahme gestartet wird, sondern über den
Bootloader angestoßen werden muss.
3.2.2 In-System-Programmer (ISP)
Um ein Programm direkt auf einen µC zu überspielen, benötigt man einen sogenannten Brenner. Diese können direkt in den Programmspeicher schreiben und sind
zwingend notwendig, wenn auf dem Controller kein Bootloader vorhanden ist, der
Daten über eine definierte Schnittstelle annehmen und im Programmspeicher ablegen kann. Aber auch wenn ein Bootloader vorhanden ist, kann es sinnvoll sein, den
µC zu brennen. Die im Programmspeicher abgelegte Software ist nach dem Brennvorgang die einzige auf dem Controller, wodurch sie nicht mehr über den Bootloader
gestartet werden muss, sondern bei Inbetriebnahme automatisch ausgeführt wird.
Der vorhandene Bootloader wird durch das Brennen überschrieben.
Zum Brennen des Programms in den Programmspeicher, kann der Prozessor aus
seiner Fassung genommen werden, um dann programmiert und wieder eingesetzt zu
werden. Dies ist jedoch mit großem Aufwand und hoher physikalischer Belastung
für das Bauteil verbunden. Daher wird meistens bei experimentellen Systemen - wie
dem hier verwendeten Butterfly - der Weg über eine Schnittstelle genutzt, die es
ermöglicht, das Programm direkt im Einsatzsystem auf den Controller zu schreiben.
Als einfache Schnittstelle steht der In-System-Programmer (ISP) zur Verfügung.
Über diesen wird der Computer mit dem Butterfly verbunden und kann nun das
gewünschte Programm direkt in den Programmspeicher schreiben. Bei dieser Art
der Programmierung werden vorhandene Programme - beispielsweise ein Bootloader
- überschrieben. Das aufgespielte Programm ist nun das Einzige auf dem Controller
und wird bei Inbtriebnahme automatisch ausgeführt.
Bei der Programmierung mittels ISP gibt es keine Einschränkung in der Benutzung der Ports, da die ISP-Schnittstelle nur zur Programmierung genutzt wird.
Während der Laufzeit können alternative Belegungen dieser Ports benutzt werden,
da der ISP inaktiv ist.
3.2.3 Joint Test Action Group - Port (JTAG)
Neben der ISP, verfügt der ATMega169P noch über eine weitere Schnittstelle, die
zum Brennen des Controllers genutzt werden kann. Diese Schnittstelle ist nach dem
3.3 Versuchsaufbau
Seite 20
Standard IEEE 1149.1 der Joint Test Action Group (JTAG) aufgebaut. Die allgemeine Bezeichnung lautet JTAG-Schnittstelle oder JTAG-Port.
Über diese Schnittstelle ist es möglich, das Programm wie über eine ISP auf den µC
zu übertragen. Darüber hinaus ermöglicht der Einsatz des JTAG-Ports das direkte
Debugging des Systems zur Laufzeit. Dazu kann der Programmablauf einer nicht
zeitkritischen Software schrittweise ausgeführt werden, wobei eine Betrachtung des
aktuellen Zustandes nach jedem Schritt möglich ist.
Alternativ ist es möglich, das Programm auszuführen und zu jedem beliebigem
Zeitpunkt, beispielsweise mittels Breakpoints, anzuhalten. In beiden Fällen können
die Zustände der Ein- sowie Ausgänge und die Inhalte der Register und Speicher
ausgelesen werden. Dadurch ist die Fehlersuche zur Laufzeit deutlich genauer und
einfacher als die Simulierung des Programmablaufs mittels eines Emulators. Diese emulieren das Verhalten eines µC, arbeiten in der Praxis allerdings nicht exakt
wie der zu emulierende Controller. Weiterhin ist eine Simulation einiger Operationen aufgrund technischer Voraussetzungen nicht möglich; beispielsweise kann das
Empfangen von Synchronisationsdaten über die serielle Schnittstelle nicht simuliert
werden.
Um das System mit dem Computer zu verbinden, ist ein JTAG-Adapter nötig,
der die Kommunikation zwischen dem Computer und dem Butterfly übernimmt.
Als einfach zu bedienen hat sich der JTAG ICE-USB-Adapter von AVR erwiesen.
Dieser benötigt keinen seriellen Port am Computer, der bei modernerer Hardware
nicht mehr zur Standardausstattung gehört und nötigenfalls mit einer zusätzlichen
Slotkarte zur Verfügung gestellt werden müsste. Stattdessen wird der USB-Anschluss
genutzt, der zur Standardausstattung jedes modernen Computers gehört.
Um die Schnittstelle zu nutzen, muss das JTAGEN Fuse Bit des µC gesetzt werden, damit der Controller auch über JTAG kommuniziert. Dies stellt den einzigen
Nachteil des JTAG-Ports dar. Wenn dieses Fuse Bit gesetzt ist, können die I/O-Pins
der JTAG nicht mehr für eine alternative Belegung verwendet werden. [Pard05, S.
45] Im Falle des ATMega169P ist dies der ADC, der bei der Aktivierung der JTAGSchnittstelle nicht mehr genutzt werden kann.
3.3 Versuchsaufbau
Ziel der Arbeit ist das Erforschen des Verhaltens von Rechnersystemen unter extremen Umgebungsbedingungen. Damit ein Rechnersystem entsteht, das einem SRP/CS, wie es in der Industrie eingesetzt wird, entspricht, müssen die beiden aufgebauten Systeme miteinander verbunden werden. Die geeignetste Methode, um die
beiden Systeme zu verbinden, stellt die serielle Schnittstelle dar. Werden die Systeme über diese Schnittstelle verbunden und mit entsprechender Software betrieben,
3.3 Versuchsaufbau
Seite 21
erfüllt das entstandene Rechnersystem die Anforderungen an die Architektur der
Kategorie 3. Von einer Struktur der Kategorie 3 kann trotzdem nicht ausgegangen
werden, da weder Werte zum MTTFd noch zum DCavg bekannt sind. Obwohl die
Einfehlersicherheit gewährleistet ist, sind keine ausreichenden Maßnahmen gegen
Ausfälle infolge gemeinsamer Ursache vorhanden.
Für den Einsatzzweck des Systems müssen diese Voraussetzungen allerdings nicht
erfüllt werden. Das Rechnersystem wird genutzt, um das Ausfallverhalten von homogen redundanten Systemen zu untersuchen. Bei der Auswertung der Ergebnisse
muss jedoch beachtet werden, dass ein nicht gesichertes System erwartungsgemäß
leichter ausfällt als ein gegen Störungen geschütztes.
Um das Verhalten der Kanäle auch ohne weitere Analysehardware erkennen zu
können, wurden auf den Flächen der Butterfly Carrier mehrere LEDs verbaut. Diese
stellen, je nach Programmierung, den Status und die Fehlermeldung in einer eindeutigen Kodierung dar. Weitere Details zu den Anzeigemöglichkeiten der LEDs sind
Kapitel 4 (S. 24) zu entnehmen.
Bis der Versuchsaufbau seine endgültige Form erreicht hat, wurden mehrere Revisionen durchlaufen, in denen sich der Aufbau veränderte. Da sich die Beschaltung
des µC von Revision 2 zu Revision 3 nicht geändert hat und der Unterschied zwischen den Revisionen auf den implementierten Programmablauf keine Auswirkung
hat, ist es nicht von Bedeutung, welche Revision bei den Untersuchungen des Verhaltens unter Umgebungsvariablen zum Einsatz kommt. Die im Rahmen dieser Arbeit
durchgeführten Beobachtungen wurden mit einem Rechnersystem bestehend aus einem Kanal der Revision 2 und einem Kanal der Revision 3 gemacht. Nachträgliche
Kontrolltests mit zwei Systemen der zweiten Revision zeigten keine Abweichung der
Ergebnisse.
3.3.1 Revision 1
Der erste Entwurf eines Versuchsaufbaus wurde mit vier LEDs erstellt. Mit diesem
Design war es möglich, 24 = 16 verschiedene Zustände darzustellen. Für den weiteren
Projektverlauf zeigte sich, dass 16 eindeutige Zustände zu wenig waren. Allein die
Anzahl der Tests überstieg diesen Wert und so konnte, im Fehlerfall, keine eindeutige Identifizierung eines fehlerhaften Tests erfolgen. Weiterhin war die Darstellung
von Fehlercode und Systemstatus schwierig, da diese über eine wechselnde Anzeige
realisiert wurde. Dazu zeigten die LEDs nacheinander, mit einer Anzeigedauer von
jeweils etwa einer Sekunde, den Fehlercode, den Systemstatus und einen Referenzzustand - 0, alle LEDs aus - an. Anhand des Referenzzustandes sollte der aktuell
ausgegebene Wert interpretierbar werden. Problematisch hierbei war allerdings, dass
sowohl Status als auch Fehlercode den Wert 0 annehmen konnten, wodurch der klare
3.3 Versuchsaufbau
Seite 22
Übergang zwischen den verschiedenen Darstellungen verschwand. Daher wurde die
Idee der Darstellung aus Revision 1 verworfen und durch ein neues Konzept ersetzt.
Abbildung 3.5: Revision 1 des Versuchsaufbau
3.3.2 Revision 2
In Revision 2 wurde zum einen die Anzahl der LEDs von vier auf acht erhöht, um
bis zu 28 = 256 eindeutige Zustände ausgeben zu können. Zudem wurde ein weiteres
LED-Feld aufgebaut, dass für die Ausgabe der Fehlercodes und der Betriebsmodi
genutzt wird. Dieses Design erfüllt bereits alle Voraussetzungen, die für den vorgesehenen Programmablauf benötigt werden. Einzig die Tatsache, dass der Porttest Abschnitt 5.2.5 (S. 53) - mit diesem Aufbau nicht realisierbar war, führte zu einer
weiteren Revision.
3.3 Versuchsaufbau
Seite 23
3.3.3 Revision 3
In Revision 3 des Versuchsaufbaus wurde der Aufbau um eine modulare Steckverbindung erweitert. Dieser Aufbau ermöglicht hardwareübergreifende Test, die mit
dem Aufbau der Revision 2, in dem die LEDs fest an die Ports gekoppelt wurden,
nicht möglich waren. In diesem Aufbau können nun wahlweise die LEDs mit den
Ports oder die Ports untereinander verbunden werden. Durch dieses modulare Design kann zum einen das Programm in seiner vorgesehenen Weise ausgeführt und
die LEDs zur Anzeige der Zustande genutzt werden, zum anderen ist es möglich
den Porttest durchzuführen. Dazu ist es allerdings nötig, den normalen Programmablauf zu verlassen, die beiden Ports miteinander zu verbinden und ein separates
Testprogramm auszuführen. Da das Butterfly nur zwei Ports zur weiteren Beschaltung auf der Fläche des Butterfly Carrier bereitstellt, gibt es meiner Ansicht nach
keine andere Möglichkeit die korrekte Funktion der Ports zu prüfen.
Seite 24
4.1 Anforderungen
Die für das Rechnersystem verwendete Software wurde nach den Anforderungen
an ein SRP/CS der Kategorie 3 entwickelt. Wird das erstellte Rechnersystem mit
der Software betrieben, so wird die Einfehlersicherheit durch die Synchronisation
und die Fehlerbehandlung erreicht. Weiterhin ist der Programmablauf gegen verschiedene Fehler gesichert. Sollten bekannten Fehler auftreten, so werden sie durch
fehlerbehandelnde Maßnahmen aufgefangen und verarbeitet.
4.2 Grundlagen
Während das Programm in der Sprache C geschrieben wurde, sind Teile der Selbsttests in Assembler verfasst worden. Alle implementierten Selbsttests sind zu einer
Bibliothek zusammengefasst worden und können somit in anderen Projekten Verwendung finden. Genauere Details über die Selbsttests werden im Kapitel 5 (S. 36)
erläutert.
Als Entwicklungsumgebung wurde Programmers Notepad“ von WinAVR ge”
nutzt. WinAVR ist eine Sammlung von Open-Source-Tools, die zum Entwickeln
von Programmen für AVR µC genutzt werden können. WinAVR enthält außerdem
alle wichtigen Tools zum Brennen und Debuggen eines µCs. Ebenfalls enthalten
ist die GNU Compiler Collection (GCC), die den benötigten Cross-Compiler AVRGCC beinhaltet. [@WinAVR] Die vorhandenen Assembler-Dateien werden nach dem
Kompilierungsprozess dem Projekt durch Verlinkung hinzugefügt.
Zum Beschreiben des µC wird nicht das im WinAVR-Paket enthaltene avrdude,
sondern das von Atmel entwickelte AVRStudio genutzt. Dieses Tool ermöglicht die
Entwicklung von Software in den Sprachen C und Assembler, allerdings erschwert die
kompliziertere Bedienung beim Erstellen von Programmen in C den Entstehungsprozess. Daher wurde das einfacher zu nutzende Programmers Notepad“ zur Ent”
wicklung eingesetzt. Weiterhin kann mit dem AVRStudio ein µC beschrieben und,
entsprechende Analysehardware vorausgesetzt, auch zur Laufzeit debuggt werden.
Darüberhinaus enthält das Programm eine Reihe von Simulatoren, mit denen der
Programmablauf auch ohne Hardware getestet werden kann (vgl. Abschnitt 3.2.3,
S. 19).
4.3 Struktur
Seite 25
Nach dem Kompilieren und Verlinken der Software liegt das Programm im executable and linkable format (elf) vor. Diese Datei beinhaltet den benötigten Programmcode und kann mit dem AVRStudio auf den µC übertragen werden. [Pard05, S.
18ff]
4.3 Struktur
Die Software ist in zwei Teile unterteilt. Teil Eins, das Hauptprogramm, verarbeitet
die Daten und simuliert den Effektiveinsatz. Teil Zwei, die Selbsttests, prüfen das
System auf Fehler (vgl. Kapitel 5, S. 36).
Das Hauptprogramm strukturiert sich in fünf Bereiche:
• Initialisierung
• Betriebsbereitschaft
• Hauptroutine
• Synchronisation
• Fehlerbehandlung
Nach dem Programmstart werden während der Initialisierung diverse Routinen
durchgeführt, um die Anlauftests und die Konfiguration des Systems vorzunehmen
(vgl. Abbildung 4.1). Sind diese abgearbeitet, verweilt das Programm in einer Schleife, dem Zustand der Betriebsbereitschaft.
Abbildung 4.1: Struktur der Initialisierung und der Betriebsbereitschaft
In der Betriebsbereitschaft, dargestellt in Abbildung 4.1, wartet das System auf
den Start, der durch ein externes Signal oder durch das Betätigen des Joysticks
4.3 Struktur
Seite 26
auf dem AVR Butterfly ausgelöst werden kann. Während der Wartezeit werden
zyklisch Selbsttests durchgeführt. Nach der Registrierung des Startsignals, beendet
das Programm die Warteschleife und geht in die Hauptroutine über.
Da das Rechnersystem zur Laufzeit keine Eingänge hat, auf die es reagieren muss,
wurde stattdessen ein Zähler implementiert, der in jedem Zyklus inkrementiert wird
und damit eine Prozedur simuliert, die das System zur Laufzeit durchführt. Der
Zähler der Pseudo-Aktion repräsentiert dabei den Systemstatus. Abbildung 4.2 zeigt
die Struktur der Hauptroutine. Tabelle 4.3 zeigt die Ausgabe der LEDs zur Laufzeit. Der gelb hinterlegte Pin stellt den definierten Ausgang der Steuerung dar, der
der zu steuernden Maschine signalisiert, dass kein Fehler vorliegt und der Betrieb
ausgeführt werden kann.
Nach dem Prinzip des Ruhestroms wird das fehlende Signal auf diesem Pin als
ein Fehler gedeutet, wodurch die Maschine in den sicheren Zustand überführt werden soll. Daher wird in den implementierten Fehlerroutinen der definierte Ausgang
immer gelöscht, wodurch das Signal von dem Pin verschwindet.
Abbildung 4.3: Tabelle der Laufzeitanzeige
Abbildung 4.2: Struktur der Hauptroutine
Nach der Datenverarbeitung folgt die Synchronisation, in der die Systeme kreuzweise
ihren aktuellen Stand abgleichen. Obwohl die Routine der Synchronisation von der
Hauptroutine aufgerufen wird, stellt sie einen eigenen Teil des Programmablaufs
dar, da der Programmablauf auch ohne Synchronisation möglich ist.
Durch den anschließenden Aufruf der Selbsttests wird in jedem Schleifendurchlauf
der Hauptroutine ein Selbsttest aufgerufen. In dem zu Evaluationszwecken entwickelten System ist diese Art der Testaufrufung einsetzbar, da keine langen Prozessabläufe erwartet werden, so dass, trotz zyklischer Ausführung, eine ausreichend
4.4 Konfigurationsmöglichkeiten
Seite 27
hohe Testrate erwartet werden kann. In Systemen mit nicht linearen Programmabläufen, die auf externe Ereignisse reagieren müssen, ist diese Art der Testung ungeeignet, da die Testrate stark von der aktuellen Last des Systems abhängt und gerade
zu kritischen Zeiten der Beanspruchung enorm sinken würde. Mögliche Lösungen für
diese Probleme werden in Kapitel 5.3 (S. 54) vorgeschlagen.
Um das Programm flexibel aber gleichzeitig testbar zu halten, wurden verschiedene
Konfigurationsmöglichkeiten eingebaut.
Anhand der Konfiguration kann das System im Debugmodus gestartet werden,
in dem Synchronisation und Selbsttests deaktiviert sind. Dieser Modus dient dazu,
andere Programmelemente ohne den Einfluss der fehlerbehandelnden Maßnahmen
testen zu können. Auch die Simulation ist nur in diesem Modus möglich, da Synchronisation sowie Warteschleifen während der Testphasen im Simulator nicht ausführbar
sind.
Alternativ können auch Tests oder Synchronisation einzeln, durch entsprechende
Einstellungen im Quellcode, deaktiviert werden. Der reguläre Programmablauf, wie
er auch in der Beobachtung des Verhaltens unter Umgebungseinflüssen zum Einsatz
kam, führt diese Routinen jedoch aus.
Solange sich das Programm in der Betriebsbereitschaft befindet, kann der aktuelle
Modus an den angeschlossenen LEDs abgelesen werden. Die Kodierung des Modus
wird wie in Abbildung 4.4 dargestellt vorgenommen.
Abbildung 4.4: Tabelle der Betriebsmodi
Die Häufigkeit der Synchronisation kann über die Variablen iSyncMod, die die Anzahl der Zyklen der Hauptroutine vor einer Synchronisation einstellt, vorgenommen
werden. Da die Synchronisation mitunter lange dauern kann (vgl. Abschnitt 4.5.1,
S. 30) ist es für eine schnellere Datenverarbeitung sinnvoll, die Häufigkeit der Synchronisationspunkte zu reduzieren. Dies bewirkt allerdings eine größere Abweichung
der Systeme untereinander und erhöht die Dauer, bis ein Fehler oder Ausfall des
anderen Systems erkannt wird.
Seite 28
Über weitere Variablen kann die maximal zulässige Dauer der einzelnen Schleifen im
Programm, die Speicherzellen für die Sicherung des Fehlercodes im Fehlerfall sowie
der definierte Ausgang eingestellt werden.
Quellcode 4.1 zeigt die Standardeinstellungen des Programms, wie sie auch bei
den Untersuchungen des Ausfallverhaltens verwendet wurden.
Seite 29
// −−− K o n f i g u r a t i o n s e i n s t e l l u n g e n −−−
char cStatus = 0 ;
// c S t a t u s = a k t u e l l e n S t a t u s
// S t a r t s t a t u s ändern
i n t iMaxStat = 2 5 5 ;
// Maximaler S t a t u s 255
i n t iDelayMs = 10∗DELAY;
// W a r t e z e i t S y n c h r o n i s a t i o n i n ms
// max
i n t iMaxTimeMs = 20∗DELAY;
// Z e i t S c h l e i f e n d u r c h l a u f i n ms
// max
i n t iDebugFlag = 0 ;
: ˜30ms
: ˜30ms
// 1
: Autostart
// 0
: Startsignal ( default )
// Für S i m u l a t o r 1 e i n s e t z e n
// −− WICHTIG: −−
// DEBUG−MODUS: SYNCHRONISATION
// SELBSTTESTS DEAKTIVIERT !
int iTestFlag = 1;
i n t iSyncFlag = 1;
i n t iSyncMod = 1 ;
// 1
: Selbsttests ( default )
// 0
: keine S e l b s t t e s t s
// 1
: Synchronisation ( default )
// 0
: keine Synchronisation
// S t a t u s s c h r i t t e z w i s c h e n Sync
// Minimum
: 1
// Maximum
: iMaxStat
i n t iOn = 0xFF ;
// Lampen an
/ Port a l s Ausgang
i n t i O f f = 0 x00 ;
// Lampen aus / Port a l s Eingang
i n t i S e c u r e P o r t D = ˜0 x80 ;
// d e f i n i e r t e n Ausgang f e s t l e g e n
i n t i S p e i c h e r 1 = 0 x00 ;
// S p e i c h e r z e l l e 1 d e k l a r i e r e n
i n t i S p e i c h e r 2 = 0 x01 ;
Quellcode 4.1: Konfigurationsmöglichkeiten der Software
Seite 30
Damit das entwickelte Programm den Anforderungen an Software von sicherheitsbezogenen Steuerungen entspricht, müssen Maßnahmen zur Erkennung und Beherrschung von Fehlern implementiert werden. In dem entwickelten Programm werden
daher drei Kategorien von Maßnahmen eingesetzt:
1. Synchronisation
2. Fehlerbehandlung
3. Watchdog
Mit diesen Maßnahmen ist das System gegen bekannte Fehler sowie auch gegen
unerwartete und damit nicht bekannte Fehler geschützt.
4.5.1 Synchronisation
Über verschiedene Konfigurationsparamter kann im Programm eingestellt werden,
ob und wenn ja, wie häufig eine Synchronisation erfolgen soll.
Abbildung 4.5: Struktur der Synchronisationsroutine
Während der Synchronisation - Struktur in Abbildung 4.5 - kommt es zu Wartezeiten, da die Systeme niemals exakt gleich arbeiten. Zwar arbeiten beide Controller
mit einer eingestellte Taktfrequenz von acht Megahertz (MHz), diese Einstellung
richtet sich jedoch an der Frequenz der einzelnen Oszillatoren aus, die wiederum
Seite 31
leichte Abweichungen voneinander haben. So kommt es zu unterschiedlichen Taktfrequenzen, woraus eine Abweichung in der Arbeitsgeschwindigkeit resultiert. Kompensierbar wären diese durch einen gemeinsamen Taktgeber, durch den jedoch die
Mehrkanaligkeit des Rechnersystems wegfallen würde.
Um diese Abweichung ohne synchronisierten Taktgeber auszugleichen, wird in der
Routine eine Schleife durchlaufen, die auf das Empfangen von Daten wartet. Das
System, das zuerst am Punkt der Synchronisation angelangt ist, sendet und wartet
anschließend auf eingehende Daten. Dabei verfällt es in den Wartezustand, bis das
andere System ebenfalls Daten übermittelt hat. Die empfangenen Daten werden mit
dem eigenen Status verglichen. Sofern eine Differenz vorliegt, wird eine Fehlerroutine
aufgerufen, die das System sicher abschaltet.
Damit die Wartezeit eine bestimmte Grenze nicht überschreitet, wird ein Timer
verwendet, der mit Hilfe der Konfigurationsvariablen iMaxTimeMs auf einen maximalen Wert eingestellt werden kann. Die Variable definiert die maximale Zeit nach
der das Programm den sicheren Zustand einleitet. Antwortet das andere System
nicht innerhalb des Zeitfensters, liegt ein Fehler vor. Ob ein Ausfall die Ursache
für das Problem war, das andere System länger für die Datenverarbeitung brauchte
oder die Nachricht aufgrund von Störungen der seriellen Schnittstelle nicht oder nur
verzögert übertragenen wurden, ist dabei nicht erkennbar.
Vor der Übermittlung von Daten wird eine Plausibilitätskontrolle, in der der zu
sendende Status auf zulässige Werte geprüft wird, durchgeführt.
Durch die Verwendung des kreuzweisen Vergleichs, werden fast alle Übertragungsfehler (vgl. Abbildung 3.4, S. 18) erkannt und behandelt. Lediglich Verzögerungen
werden durch die Verwendung des Timers erkannt. Obwohl alle aufgezeigten Fehler
erkannt werden, kann der genaue Fehlertyp nicht bestimmt werden, was trotzdem
zur sicheren Abschaltung des Systems führt. [Rei99]
Weiterhin wird mit der Synchronisation die Einfehlersicherheit gewährleistet. Fällt
ein System aufgrund von Störungen aus oder produziert Fehler, so erkennt das andere System dies zum nächsten Synchronisationszeitpunkt und löst eine Fehlerroutine
aus.
Ausschnitt 4.2 aus dem Programmcode zeigt den Quelltext der Synchronisationroutine.
Seite 32
515
/∗ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ∗/
516
/∗ −−−−− S y n c h r o n i s a t i o n s r o u t i n e −−−−−− ∗/
517
/∗ empfängt und s e n d e t a k t u e l l e n S t a t u s ∗/
518
/∗ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ∗/
519
v o i d doSync ( ) {
520
521
// a k t u e l l e n S t a t u s senden
522
i f ( c S t a t u s <= iMaxStat ) {
523
sendChar ( c S t a t u s ) ;
524
}
525
else
526
stdError () ;
527
528
// WD r e s e t t e n , damit n i c h t a u s l ö s t
529
wdt reset () ;
530
531
delay loop 2 (4000) ;
532
533
TCNT2 = 0 ;
534
OCR2A = iDelayMs ;
// Lädt das V e r g l e i c h s r e g i s t e r
535
536
// I n i t i a l i s i e r t den Timer und s t a r t e t i h n
537
TCCR2A = (1<<CS20 ) |(1<<CS22 ) |(1<<WGM21) ;
538
539
w h i l e ( ! ( UCSRA & (1<<RXC) ) ) ; // Daten empfangen ?
540
541
c R e c e i v e d = UDR;
// Daten a u s l e s e n
i f ( c R e c e i v e d != c S t a t u s ) {
// Vgl . empf . Daten & S t a t u s . .
542
543
544
syncError () ;
// . . F e h l e r wenn u n g l e i c h
}
545
546
547
// Timer a n h a l t e n
548
TCCR2A &= ˜((1<<CS20 ) |(1<<CS22 ) ) ;
549
}
Quellcode 4.2: Synchronisationsroutine
4.5.2 Fehlerroutinen
Im Programm sind mehrere Fehlerroutinen implementiert, mit denen auf auftretende
Fehler reagiert wird. Mögliche Fehler werden durch Vorkehrungen im Programm
Seite 33
erkannt und mit Hilfe entsprechender Fehlerroutinen, durch Ausgabe des Fehlercodes
und Überführung in den sicheren Zustand, behandelt.
Weiterhin wird ein eindeutiger Fehlercode in den Festwertspeicher des µCs geschrieben. Sollte ein Fehler auftreten, der die Peripherie beeinflusst, so kann mittels
Hardwareanalysetools der gespeicherte Wert zur Identifizierung des Fehlers aus den
eingestellten Speicherzellen ausgelesen werden.
Es gibt sechs verschiedene Fehlerroutinen, die unterschiedliche Fehler behandeln,
wobei alle Routinen mit Ausnahme der für den Watchdogalarm, fest definierte Fehler
behandelt. Diese werden im folgenden näher erläutert.
Synchronisationsfehler und -timer
Diese Routinen behandeln die Fehler, die bei der Synchronisation auftreten können.
Auslöser sind die in Abschnitt 4.5.1 (S. 30) genannten Umstände.
Watchdog
Nach einem, durch den Watchdog herbeigeführten, Systemreset wird diese Routine
ausgeführt, außer der Systemreset war Teil des Watchdog-Tests. Mit dieser Maßnahme werden nicht erkannte Fehler behandelt, die das System zum Verlassen des
vorgesehenen Programmablaufs bringen, wodurch der Watchdog nicht mehr gesetzt
wird und das System neu startet.
Selbsttestfehler
Die Routine wird durch einen Fehler eines Selbsttests aufgerufen. Die Selbsttests
und mögliche Fehler werden in Kapitel 5 (S. 36) erklärt.
Echtzeitverletzung
Mit dem Echtzeittimer wird überprüft, ob ein Schleifendurchlauf des Hauptprogramms - dargestellt in Abbildung 4.2 (S. 26) - die mittels der in Quellcode 4.1
(S. 29) vorgesehenen Variablen iMaxTimeMs eingestellte Zeit überschreiten. Ist dies
der Fall, kann nicht mehr von der Echtzeitfähigkeit des Systems ausgegangen werden. Dieser Fehler tritt auf, wenn durch unvorhergesehene Ereignisse während der
Datenverarbeitung in der Hauptroutine der Zeitrahmen für den Schleifendurchlauf
überschritten wird.
Sonstige
Diese Routine dient für alle weiteren Fehler und kommt im aktuellen Programmablauf nur bei der Plausibilitätsprüfung vor der Synchronisation zum Einsatz. Denkbar
ist es jedoch weitere, vorstellbare Fehler mit ihr abzudecken.
Seite 34
Abbildung 4.6: Tabelle der Fehlercodes
Alle Routinen haben die gleiche Struktur, unterscheiden sich jedoch durch die gespeicherten und angezeigten Fehlercodes voneinander. Sie wurden trotzdem getrennt
implementiert, da auch unterschiedliche Reaktion auf verschiedene Fehler denkbar
wären. Ein Fehler der Kategorie Sonstige“ muss beispielsweise nicht direkt zum
”
Übergang in den sicheren Zustand führen, da durch gezielte Maßnahmen der Fehler
behoben und der Betrieb fortgesetzt werden kann.
Abbildung 4.7 zeigt die Struktur der Fehlerroutinen. Tabelle 4.6 zeigt die visuelle Ausgabe der Fehlercodes auf den LEDs, in der der gelb hinterlegte Port den
definierten Ausgang zeigt. Im Fehlerfall ist dieser, ebenso wie im Betriebsbereitschaftsmodus, auf Low gesetzt.
Abbildung 4.7: Struktur der Fehlerroutinen
4.5.3 Watchdog
Wenn im Programm eines µC unerwartete oder unentdeckte Fehler auftreten, kann
es passieren, dass sich der Programmablauf auf eine unvorhergesehene Weise ändert.
Um solche Fehler zu entdecken, verfügt der µC über einen Watchdog. Dieser funktioniert nach dem Prinzip eines Weckers. Ist er einmal gestartet, zählt er bis zu einer
gewissen Zahl und schlägt beim Erreichen Alarm. Der Alarm hat zur Folge, dass ein
Reset das System neu startet, um zum planmäßigem Programmablauf zurück zu
kehren. Damit dies nicht geschieht, muss der Watchdog während der Programmab-
Seite 35
laufs ständig zurück gesetzt werden. Dies muss so oft geschehen, dass der Watchdog
bei planmäßigem Ablauf keinen Alarm erzeugt. Wird der Ablauf gestört oder verlassen, geschieht das Zurücksetzten des Watchdog nicht, wodurch ein Zähler abläuft,
was zu einem Reset führt. [Schae08, S. 176ff]
Während der Initialisierung wird überprüft, ob ein Reset durch den Watchdog
statt gefunden hat. Ist dies der Fall wird überprüft, ob der Reset beabsichtigt durch
die Testung des Watchdogs herbei geführt wurde (vgl. Abschnitt 5.2.1, S. 46) oder
ob es sich um einen unplanmäßigen Reset handelt. Ist letzteres der Fall, wird die
Fehlerroutine des Watchdogs aufgerufen, die das System in den sicheren Zustand
überführt und eine entsprechende Fehlermeldung ausgibt.
5 Selbsttests
Seite 36
5 Selbsttests
Um die korrekte Verarbeitung der Daten durch den µC sicher zu stellen, wurden
diverse Selbsttests implementiert. Diese Tests können sowohl einzelne Befehle des
Befehlssatz, komplette Speicherbereiche als auch die angeschlossene Peripherie auf
ihre korrekte Funktion prüfen. Die Selbsttests sind dem Reports 7/06 des BGIA
[BGIA06] entnommen und auf den ATMega169P angepasst worden.
Da die im Report genannten Tests auf den damals verwendeten Siemens µC zugeschnitten sind und sich dessen Befehlssatz stark von dem des ATMega169P unterscheidet, waren sie auf dem hier verwendeten µC nicht einsatzfähig. Trotzdem
dienten sie als Vorlage, indem sie sinn- und funktionsgemäß auf den Befehlssatz des
ATMEL µC übertragen wurden.
Darüber hinaus mussten die umgesetzten Tests um einige Elemente erweitert werden, damit sie zur Laufzeit des Systems ausgeführt werden können ohne den Programmablauf zu stören. Die Tests aus dem Report speichern keine Registerwerte vor
dem Testbeginn, so dass eventuell vorhandene Daten durch die verwendeten Testdaten überschrieben werden. Auf einem System im Produktiveinsatz würde dies
zur Veränderung der Datenverarbeitung und des Programmablaufs führen, wodurch
selbst ein korrekt funktionierendes System nicht wie vorgesehen arbeiten würde.
Daher müssen diese Werte vor Beginn eines Tests gespeichert und anschließend
Wiederhergestellt werden.
Bei Inbetriebnahme des Rechnersystems wird ein Anlauftest gestartet, in dem
alle Tests einmal durchgeführt werden. Ist dieser Initialtest positiv verlaufen, wird
das ausführende Programm gestartet. Während der Laufzeit werden zyklisch weitere
Tests aufgerufen, um den korrekten Ablauf zu prüfen. Sowohl beim Initialtest als
auch zur Laufzeit führt ein unerwartetes Ergebnis eines Selbsttests dazu, dass eine
Fehlerroutine ausgelöst wird, die den Fehlercode wie in Abbildung 4.6 (S. 34) ausgibt
und in den Festwertspeicher schreibt.
Eine wichtige Eigenschaft von Selbsttests ist die Dauer, die sie für eine Bearbeitung benötigen. Selbsttests sollen im Hintergrund laufen und den planmäßig vorgesehenen Arbeitsablauf nicht behindern. Aus diesem Grund ist es wichtig, die Tests
in möglichst kurzer Zeit durchführen zu können. [Klug97]
5.1 CPU-Tests
Seite 37
5.1 CPU-Tests
Die grundlegendste Kategorie von Selbsttests ist die, die die Befehle des µC prüfen.
Da es sich bei diesen Tests des Befehlssatzes um sehr hardwarenahe Programmabläufe handelt, wurden sie in Assembler verfasst. In einer Hochsprache wie C wären
der größere Teil dieser Tests nicht sinnvoll realisierbar, da auf Programmabläufe
und die verwendeten Befehle kein genauer Einfluss genommen werden kann. Die Art
der Übersetzung des Programms von einer Hochsprache in die Maschinensprache
Assembler hängt stark vom eingesetzten Compiler und dessen Konfiguration ab.
Selbst wenn es möglich wäre alle Tests in einer Hochsprache zu verfassen, so könnte im Fehlerfalle nicht die genaue Fehlerursache erkannt werden, da keine absolute
Gewissheit über den Programmablauf auf Hardwareeben besteht.
Die implementierten Selbsttests für das Instruction Set gliedern sich in sechs Gruppen:
• Arithmetische Tests
• Registertests
• Push-Pop-Return-Jump-Test
• Tests der logischen Operationen
• Tests der Bit-Operationen
• Tests der Transfer-Befehle
5.1.1 Arithmetische Tests
Mit den arithmetischen Tests werden, wie der Name schon verrät, die arithmetischen Befehle des µCs getestet. Dazu gehören Grundrechenarten wie das Addieren,
das Subtrahieren und das Multiplizieren von Zahlen aber auch spezielle Anweisungen wie das In- und Dekrementieren von Registerinhalten. Die Division wird dabei
nicht mittels direktem Befehl durchgeführt und getestet, sondern durch eine Kombination aus Subtraktion und Schiebe-Operationen ersetzt. Dies ist nötig, da der
ATMega169P über keine Hardware-Divisionseinheit verfügt. Trotzdem ist die Division durch die Selbsttests abgedeckt, da sowohl die Subtraktion als arithmetischer
Befehl als auch die Schiebe-Operation als Bit-Operation durch Selbsttests geprüft
werden. Werden diese Tests ohne Probleme durchgeführt, kann davon ausgegangen
werden, dass auch eine Division einwandfrei funktionieren wird.
Anders als die anderen Tests des Befehlssatzes, könnten sie in einer Hochsprache
formuliert werden, wodurch sie auf andere Systeme portiert werden könnten. Da
diese Gruppe der Tests jedoch die einzige mit dieser Möglichkeit ist und durch
5.1 CPU-Tests
Seite 38
die Verwendung einer Hochsprache anderweitig Probleme auftreten würden, wurde
davon abgesehen.
Addition
Bei diesem Test wird die korrekte Verarbeitung der Addition zweier Zahlen überprüft, indem zwei, mit speziellen Testwerten vorbereiteten, Register addiert werden
und anschließend das Ergebnisses im Zielregisters mit dem Sollwert verglichen wird.
Sollte der Wert nicht der Erwartungshaltung entsprechen, wird eine Fehlerroutine
ausgelöst. Abbildung 5.1 zeigt den Programmablauf des ADD-Tests.
Abbildung 5.1: Programmablauf des Tests für die Addition
1
; ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ADD TEST ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 ADD TEST :
3 PUSH
R31
4 PUSH
R30
5
LDI
R31 , 0xAA
; Testmuster 1 l a d e n
6
LDI
R30 , 0 x55
7 ADD
R31 , R30
; Befehlstest
8
R31 , 0xFF
; V e r g l e i c h mit Erwartungshaltung
CPI
9 BRNE
10 JMP
; alte Registerwerte speichern
ADD err
ARI END1
11
12
ADD err :
13 CALL
testError
Quellcode 5.1: Selbsttest der Addition
Die Dauer des Selbsttests, dargestellten in Quellcode 5.1, beträgt weniger als 20
Zyklen, da der ATMega169P den Großteil aller Befehle seines Befehlssatz in einem
Zyklus abarbeiten kann. Bei einem Takt von acht Megahertz dauert der Test weniger als 2 21 µs. Zu beachten ist, dass dieser Test nicht nur zu Beginn des Programms,
5.1 CPU-Tests
Seite 39
sondern auch während der Laufzeit ausgeführt wird. Daher müssen die Registerwerte gespeichert werden, bevor sie durch die Testwerte überschrieben werden, um
Datenverlust und damit Fehler des Programms zu vermeiden.
Subtraktion
Die Funktion zur Testung der Subtraktion (SUB) ist vom Prinzip identisch mit der
der Addition. Die Unterschiede sind auf die verwendeten Testwerte sowie den eingesetzten Befehl beschränkt.
Addition mit Beachtung des Carry-Flag
Ähnlich verläuft auch der Test des Befehls für die Addition mit dem Carry-Flag
(ADDC), der von Bedeutung ist, wenn die Summe der zwei zu addierenden Zahlen die
Grenze von 255, dem maximalen Wert eines 8 Bit-Registers, überschreitet. Ist dies
bei einer Addition der Fall, wird der Überlauf, das sogenannte Carry-Flag gesetzt.
Somit kann das Ergebnis im höheren Register angepasst werden, indem das CarryFlag mittels dem ADDC-Befehl bei der nächsten Addition mit berücksichtigt und
dazu addiert wird. Additionen deren Summe die Registerobergrenze überschreiten,
müssen immer mit einer Kombination mehrere Register durchgeführt werden. In
der Regel werden dazu zwei 8 Bit Register zu einem 16 Bit Register verknüpft.
Dabei stehen die unteren 8 Bit im Low- und die oberen 8 Bit im High-Register. Der
ADDC-Test - PAP in Abbildung 5.2 - prüft jedoch nur, ob das Carry-Flag bei einem
Überlauf gesetzt wird und ob der Befehl das korrekte Ergebnis berechnet.
Abbildung 5.2: Programmablauf des ADDC-Tests
Weitere arithmetische Tests
Weiterhin wurden die Befehle für die In- und Dekrementierung (INC und DEC) sowie
der Befehl für die vorzeichenlose Multiplikation (MUL) auf ihre korrekte Funktion
5.1 CPU-Tests
Seite 40
geprüft. Das Prinzip hinter den Tests dieser Befehle ist das gleiche, wie bei den oben
aufgeführten Tests. Vorbereitete Testregister werden mit definierten Speicherwerten
geladen. Anschließend wird die zu testende Operation durchgeführt und das Ergebnis
mit dem erwarteten Wert verglichen.
5.1.2 Registertests
Wie in Abschnitt 3.1.1 (S. 15) erläutert, besitzt der ATMega169P 32 Arbeitregister,
die den klassischen Akkumulator ersetzen. Um die korrete Verarbeitung der Daten
in den Arbeitsregistern sicher zu stellen, müssen sie getestet werden. Dazu wird eine
1 in das zu testende Register geladen und anschließend bis zu acht mal nach links
geschoben wird. Diese 1 soll nun durch das Register durchgewandert sein und im
Carry-Flag stehen. Ist dies nicht der Fall und die 1 steht noch im Register oder ist
sie früher in das Carry-Flag verschoben worden, so liegt ein Fehler des Registers vor
und eine Fehlerroutine wird aufgerufen. Der abstrahierte Programmablauf kann der
Abbildung 5.3 entnommen werden.
Abbildung 5.3: Programmablauf der Registertests
Die Dauer eines Register-Tests beträgt etwa fünf µs. Das bedeutet, dass insgesamt
circa 150 µs benötigt werden, um alle 32 Arbeitsregister zu testen. Die genannte
Zeit bezieht sich nur auf die Selbsttests. Hinzu kommt noch die von der aufrufenden
Methode benötigte Zeit zum Starten des nächsten Tests.
5.1 CPU-Tests
Seite 41
5.1.3 Push-Pop-Return-Jump-Test
Dieser Selbsttest ist der komplexeste implementierte Test. Durch diesen Test werden
vier eng verwandte Befehle getestet. Die Befehle PUSH und POP dienen zur Verarbeitung der Daten auf dem Stack. Mit dem PUSH-Befehl werden Werte auf dem
Stack abgelegt, die mit dem POP-Befehl wieder vom Stack geholt werden können.
Der Stack ist beim ATMega169P so angelegt, dass er sein Ende an der höchsten
Speicheradresse hat und in tiefere Speicherbereiche wächst. Daher wird der Stackpointer beim Ablegen von Daten auf dem Stack dekrementiert und beim Lesen vom
Stack inkrementiert. Der RETURN-Befehl setzt den Programmzähler auf die Adresse, die auf dem Stack abgelegt ist. Er wird für die Rückkehr aus einer Interruptoder Subroutine benutzt. Der letzte getestete Befehl ist der JUMP-Befehl. Dieser ist
nicht vom Stack abhängig. Er ähnelt jedoch dem RETURN-Befehl, da er auch den
Programmzähler auf eine Adresse setzt, die im Gegensatz zum RETURN-Befehle aber
fest vorzugeben ist. Der Programmablauf des Tests ist in den Abbildungen 5.4, 5.5
und 5.6 in drei Abschnitte unterteilt.
Abbildung 5.4: Abschnitt 1 des PPRJ-Test: PUSH-Test
5.1 CPU-Tests
Seite 42
Abbildung 5.4 zeigt den ersten Abschnitt des Tests, der die PUSH-Operation testet.
Die gelb eingefärbten Anweisungen stellen den Anfang des nächsten Testbereichs
dar. Im ersten Testbereich wird getestet, ob bei einem PUSH der Stackpointer korrekt dekrementiert wird. Dazu wird der Stackpointer vorher gespeichert und dieser
Wert als Erwartungswert genutzt. Nach dem PUSH-Befehl muss der neue Wert des
Stackpointers um Eins kleiner sein als der Erwartungswert. Ob der gepushte Wert
auch korrekt auf dem Stack vorliegt, wird im zweiten Bereich überprüft. Der auf
dem Stack liegende Wert wird dazu mit dem geschriebenen Wert verglichen.
Abbildung 5.5: Abschnitt 2 des PPRJ-Test: POP-Test
Im zweiten Abschnitt des PPRJ-Test, der in Abbildung 5.5 schematisch dargestellt
ist, wird die Funktionsweise der POP-Operation getestet. Dabei wird im ersten Schritt
geprüft, ob der Befehl einen Wert korrekt vom Stack ausliest. Zu diesem Zweck
wird der im ersten Abschnitt des PPRJ-Tests auf Korrektheit geprüfte Wert vom
Stack gelesen und mit dem Erwartungswert verglichen. Im zweiten Schritt wird die
Inkrementierung des Stackpointers überprüft. Nach einem POP muss der Stackpointer
um Eins erhöht werden. Verglichen wird mit der im ersten Abschnitt genommenen
Stackpointerposition.
Abschnitt drei, dargestellt in Abbildung 5.6, testet abschließend den RETURNBefehl. Hierbei wird die Adresse einer definierten Funktion auf den Stack gelegt und
der RETURN-Befehl aufgerufen. Das Programm muss nun in die Funktion springen.
Geschieht dies nicht, läuft das Programm in eine Fehlerroutine. Hat der Sprung
funktioniert, so wird im zweiten Bereich der JUMP-Befehl getestet. Dieser soll das
Programm in die abschließende Methode springen lassen, in der die Register wieder
5.1 CPU-Tests
Seite 43
Abbildung 5.6: Abschnitt 3 des PPRJ-Test: RETURN und JUMP-Test
hergestellt werden und das System in seinen normalen Programmablauf zurückkehrt. Wie beim RETURN-Befehl läuft das Programm in eine Fehlerroutine, falls die
JUMP-Operation versagt.
Bei einer mittleren Zeit von zwei Zyklen pro Befehl, beträgt die Gesamtdauer des
PPRJ-Test etwa 125 Zyklen. Der ATMega169P führt jedoch einen großen Teil seiner
Befehle in einem Zyklus aus, wodurch die tatsächliche Dauer des Tests unter diesem
Wert liegen wird. Bei exakt acht MHz würde dieser Test weniger als 16 µs brauchen.
5.1.4 Test der logischen Operationen
Eine weitere Art von Operationen, die getestet werden müssen, sind die logischen
Operationen. Dazu gehören die Befehle für die UND-Verknüpfung (AND), die ODERVerknüpfung (OR) sowie das EXCLUSIVE ODER (EOR). Diese Operationen werden
benutzt, um Bits logisch miteinander zu verknüpfen, was bei Embedded Systems
und der Programmierung von µC sehr oft für die Zuweisung von Werten zu Register
und Speicherbereiche verwendet wird. Die Tests der logischen Operationen haben
eine sehr hohe Ähnlichkeit zu den arithmetischen Tests. Bei allen Tests werden vorher festgelegte Testwerte, meistens Schachbrettmuster - Werte deren Bits abwechselnd gesetzt sind - in verschiedene Register geladen. Danach werden diese Register
logisch miteinander verknüpft und der erhaltene Wert mit einem Erwartungswert
verglichen. Abbildung 5.7 demonstriert einen möglichen Testablauf.
5.1 CPU-Tests
Seite 44
Abbildung 5.7: Programmablauf des Test der logischen AND-Verknüpfung
5.1.5 Tests der Bit-Operationen
Bei Bit-Operationen handelt es sich um Befehle, die dazu dienen, Registerinhalte zu
manipulieren. Zu den Bit-Operationen gehören folgende Befehle:
• Löschen (CLR)
• Invertieren (COM)
• Vertauschen der Nibbles (4 Bit) (SWAP)
• Verschieben (LSL & LSR)
• Rotieren (ROL & ROR)
Der Unterschied zwischen einer Schiebe- und einer Rotations-Operation ist der Umgang mit dem Carry-Flag. Während die Schiebe-Operationen das Register nur um
eine Stelle nach links oder rechts schiebt und das erste, nun frei gewordene Bit
durch eine 0 ergänzt wird, rotiert die Rotations-Operation das Register über das
Carry-Flag. Dabei wird das Carry-Flag an der leer gewordenen Stelle eingefügt und
anschließend das überstehende Bit in das Carry-Flag geschoben. Bei einer Schiebeoperation wird das heraus geschobene Bit zwar auch im Carry-Flag gespeichert,
jedoch bei einer weiteren Verschiebung nicht wieder eingefügt. Die Registertests zeigen eine beispielhafte Verwendung für das Carry-Flag bei einer Schiebe-Operation.
5.2 Peripherie Tests
Seite 45
1
; ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ LSL TEST ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2
LSL TEST :
3 PUSH
R31
; Registerwerte speichern
4
LDI
R31 , 0xAA
5
LSL
R31
; Befehlstest
6
CPI
R31 , 0 x54
; V e r g l e i c h mit Erwartung . .
7 BRNE
LSL err
; . . wenn u n g l e i c h , F e h l e r
8 POP
R31
; Registerwerte wieder h e r s t e l l e n
9 RET
10
11
LSL err :
12 CALL
testError
; S p r i n g e i n Routine d e r Fehlermeldung
Quellcode 5.2: Selbsttest der bitweisen Verschiebung nach links
Beispiel 5.2 zeigt den Quellcode des Tests für die bitweise Verschiebung nach links.
Sowohl beim Rotations- als auch beim Test der Schiebeoperation ist der Ausgangswert 0xAA. Nach einer Ausführung ist der Erwartungswert des LSL- sowie des
ROL-Befehls 0x54. Eine weitere Durchführung der Befehle zeigt den Unterschied.
Während das Ergebnis der LSL-Operation 0xA8 lautet, ist das Ergebnis der ROLOperation 0xA9, da die in der ersten Ausführung überstehende Eins in das CarryFlag verschoben wurde und nun wieder eingefügt wird.
5.1.6 Test der Transfer-Befehle
Um Werte aus dem Speicher auszulesen und in ein Register zu schreiben oder um Registerinhalte in andere Register zu kopieren, werden die Transfer-Befehle benötigt.
Die implementierten Selbsttests der Transfer-Befehle prüfen die Befehle für das direkte und das indirekte Laden von Registern (LDI & LD) sowie die Befehle, um
einzelne Register oder ein Registerpaar zu kopieren (MOV & MOVW). Auch hier wird
das Ergebnis einer Operation mit vorgegebenen Anfangs- und Erwartungswerten
verglichen. Beim Test des LD-Befehls für die indirekte Beladung eines Registers,
wird der Wert jedoch zuvor auf den Stack geschrieben und von dort mittels Pointer
in das Register gelesen. Abbildung 5.8 zeigt den Programmablauf des LD-Tests. Die
weiteren Transfer-Befehle werden nach dem selben Schema geprüft.
Neben dem Befehlssatz muss auch die Peripherie getestet werden. Damit ist zum
einen der Watchdog gemeint, der elementar für den sicheren Betrieb eines Systems
ist. Zum anderen werden beide vorhandene Ports darauf getestet, ob sie ein Signal
Seite 46
Abbildung 5.8: Test des Befehls für das indirekte Laden von Registern
fehlerfrei ausgeben bzw. einlesen können. Weiterhin können wichtige Komponenten
wie ADC, Speicher oder Taktgeber getestet werden. Da durch die Verwendung eines
JTAG-Adapters zur Erstellung des Systems der ADC nicht genutzt werden kann
(vgl. Abschnitt 3.2.3, S. 19), wird dieser auch nicht getestet. Auch die korrekte
Funktionsweise des Taktgebers wird nicht direkt getestet, ein fehlerhaftes Verhalten
des Oszillators würde aber über die mehrkanalige Struktur und die Synchronisation
aufgedeckt werden.
5.2.1 Watchdog
Um sicher zu gehen, dass diese Notfallmaßnahme voll funktionstüchtig ist, wird der
Watchdog während des Systemstarts überprüft. Dazu wird überprüft, ob dieser nach
Ablauf der eingestellten Zeit einen Systemreset ausführt. Geschieht dies nicht, ist
die Funktion des Watchdog gestört und das System wird über die Fehlerroutine in
den sicheren Zustand überführt.
Während bei allen Tests ein Anfang und ein Ende definiert ist - wenn kein Fehlerfall eintritt - so ist dies beim Test des Watchdog nicht möglich. Verläuft der Test
positiv, arbeitet der Watchdog wie erwartet und startet das System neu, womit alle
gespeicherten Werte in den Registern verloren gehen. Um dennoch auf zur Auswertung des Tests benötigte Daten zurückgreifen zu können, müssen diese in einem nicht
flüchtigen Speicher festgehalten werden. Der ATMega169P verfügt über beschreibbaren Festwertspeicher in Form von EEPROM. Jede Speicherzelle des EEPROM ist
nach einer gewissen Anzahl von Schreib/Lösch-Zyklen nicht mehr funktionsfähig.
Diese Anzahl beträgt beim ATMega169P mindestens 100.000 Zyklen [ATM08a, S.
22]; deshalb kann sie für den eingesetzten Evaluationszweck vernachlässigt werden,
da während einer Betriebsabfolge nur maximal ein Schreib/Lösch-Zyklus pro Zelle
durchgeführt wird.
Seite 47
Ist der Status gespeichert, kann nach einem Reset geprüft werden, ob das System
aufgrund eines WD-Tests neu gestartet wurde. Dies geschieht in der Routine, die das
System nach einem WD-Reset in den sicheren Zustand überführen soll. Quellcode
5.3 zeigt diese Routine.
65
iWDStatusFlag = eepromRead ( iWDSpeicher ) ;
66
67
// WD−Routine , wenn S y s t e m r e s e t durch WD
68
i f ( (MCUSR & ( 1 << WDRF) ) ) {
69
MCUSR = 0 ;
70
wdt disable () ;
71
i f ( iWDStatusFlag != 1 ) {
72
wdError ( ) ;
}
73
74
}
75
// WD−Test , wenn T e s t s a k t i v & v o r h e r k e i n WD−Test
76
i f ( iWDStatusFlag != 1 && i T e s t F l a g ) {
77
startTest (99) ;
78
}
79
// s o n s t l ö s c h e Watchdog−Flag und TestNr
80
e l s e i f ( iTestFlag ){
81
eepromWrite ( iWDSpeicher , 0 ) ;
82
iTestStat = 0;
83
}
Quellcode 5.3: Watchdog-Prüfroutine am Programmbeginn
Der Watchdog-Test ist der einzige Selbsttest, der nicht zur Laufzeit ausgeführt
werden kann. Er wird daher zyklisch ausgeführt, sondern nur einmalig beim Start
des Systems. Die Routine zum Aufrufen des Tests kann ebenfalls dem Quellcode 5.3
entnommen werden.
Quellcode 5.4 zeigt die Watchdog-Testroutine. Da der Watchdog auf 15 ms eingestelklt wurde und somit diese Zeit bis zum Auslösen des Watchdogs gewartet werden
muss, ist auch die Dauer dieses Tests größer als 15 ms. Mit diesem Testverfahren ist
es nur möglich zu erkennen, ob der Watchdog nach der vorgegeben Wartezeit reagiert hat oder nicht. Ein verfrühtes oder verzögertes Reagieren kann nicht erkannt
werden, da eine Alarmmeldung vor Ablauf der 15 ms den Test positiv verlaufen lassen würde, während eine Verzögerung hierbei einem Ausfall gleich kommen würde.
Die Ermittlung der exakten Laufzeit bis zu einem Reset des Watchdogs ist fast
unmöglich, da dazu zum einem der genaue Zeitpunkt des Resets festgehalten werden müsste und zum anderem eine Berechnung der Laufzeit, aufgrund getrennter
Oszillatoren für das System und den Watchdog, nur schwer möglich ist.
Seite 48
266
// Watchdog−T e s t r o u t i n e
267
v o i d WDTest ( ) {
268
eepromWrite ( i S p e i c h e r 3 , 1 ) ;
// WD−Test−S t a t u s => EEPROM
w d t e n a b l e (WDTO 15MS) ;
// Watchdog a u f z i e h e n
269
270
271
d e l a y l o o p 2 ( 5 ∗ DelayMS ) ;
272
273
274
// Warten
// k e i n WD−Reset = D e f e k t
275
276
277
testError () ;
// i n Fehlermeldung s p r i n g e n
}
Quellcode 5.4: Watchdog-Test
5.2.2 Tests der integrierten Timer
Timer werden - wie schon der Watchdog - zur Kontrolle des korrekten Programmablaufs genutzt. Um deren Funktionalität zu verifizieren, wurden auch dafür Selbsttests
implementiert. Dieses Tests aktivieren die Timer für eine definierte Zeit und vergleichen im Anschluss die Erwartungswerte mit den generierten Werten aus den Timerregistern. Im Detail wird der Timer fünfmal für eine Dauer von einer ms aktiviert.
Stimmen im Anschluss die Testergebnisse mit den festgelegten Erwartungswerten
überein, wird davon ausgegangen, dass die Timer wie erwartet arbeiten.
Da die Timer zum Teil kontinuierlich laufen und, ähnlich wie beim Watchdog, nur
zu bestimmten Zeiten eine Rückstellung stattfindet, werden auch diese Tests nicht
zur Laufzeit durchgeführt. Stattdessen werden sie zu Beginn des Programms, noch
vor den Anlauftests, eingeleitet.
Abbildung 5.9 zeigt die Struktur der Tests. Alle Timer, unabhängig davon ob es
sich um einen 8- oder einen 16-Bit Timer handelt, werden auf die gleiche Art und
Weise getestet.
Bei einer fehlerhaften Taktfrequenz, durch ungenaue oder nicht korrekte Arbeitsweise des Oszillators, kann die Laufzeitdauer der Warteschleife von dem erwarteten
Wert abweichen. Da aber sowohl die Warteschleife als auch der Timer von der Taktfrequenz des µC abhängig sind, führt dies nicht zu einem Fehler, solange diese Einheiten korrekt Arbeiten. Aus diesem Grund kann mit diesem Test nicht festgestellt
werden, ob der Timer zeitlich exakt läuft, sondern nur ob dieser wie vorgesehen
abhängig von der Taktfrequenz seine Schritte ausführt.
Der Watchdog dient zur zeitlichen Begrenzung, um auch bei einer Fehlfunktion
des Tests diesen zu terminieren. Eine Kontrolle der Laufzeitdauer erfolgt jedoch
Seite 49
Abbildung 5.9: Test der Timer auf korrekte Funktionsweise
nicht.
Eine fehlerhafte Taktfrequenz kann, je nach Ausprägung der Ungenauigkeit, durch
die Synchroninsation erkannt werden.
5.2.3 RAM-Test
Der flüchtige Speicher (Random Access Memory, RAM) wird vorwiegend für temporäre Speicherung von Daten genutzt. Da es sich um flüchtigen Speicher handelt,
gehen bei einem Spannungsverlust oder dem Neustart des Systems die zuvor gespeicherten Daten verloren.
Um bei der Verwendung des RAMs die Integrität der Daten zu gewährleisten, wird
dessen Funktionalität durch einen implementierten Selbsttest sichergestellt. Dieser
prüft die einzelnen Zellen des Speichers, indem Testwerte, die zuvor gespeichert
wurden, ausgelesen und mit Erwartungswerten verglichen werden. Verläuft dieser
Vergleich positiv, wird davon ausgegangen, dass diese Speicherzelle intakt ist.
Die Dauer des RAM-Tests hängt stark von Größe und Art der Prüfung ab. Im
Testsystem wurde dieser Test sinnvollerweise in mehrere Testdurchläufe zerlegt, um
das System nicht übermäßiglang mit einem einzelnen Test zu beanspruchen.
In diesem speziellen Test wird jede Zelle mit zwei Schachbrettmustern versehen,
die feststeckende Bits erkennbar machen. Zu diesem Zweck wird der zuvor in der
Seite 50
Zelle befindliche Wert zwischen gespeichert um nach Abschluss des Tests wiederhergestellt werden zu können. Die Anzahl der getesteten Zellen kann dabei mithilfe
der Variable iRamTestLaenge aus der Testbibliothek variiert werden. Bei dem zyklischen Durchlauf ist diese fix - zehn Zellen -, kann jedoch bei anderen Arten der
Testaufrufung (vgl. Abschnitt 5.3, S. 5.3) variiert werden, um eine möglichst optimale Testrate zu erreichen.
Quellcode 5.5 zeigt die zwei Routinen des RAM-Tests. In der ersten Routine wird
Start- und Endzelle des einzelnen Tests definiert, womit im zweiten Schritt die zweite Routine aufgerufen wird, die den eigentlichen RAM-Test durchführt.
193
// Routine f ü r den e i n f a c h e r e n RAM−Test
194
v o i d Ram Test ( ) {
195
// Pr üfen ob Prüfrahmen über Ramende h i n a u s
196
i f ( ( c E r s t e R a m Z e l l e + i T e s t L a e n g e ) > RamE) {
197
// Wenn ja , b i s zum Ende pr üfen ,
198
u n s i g n e d i n t iTestLaengeTemp = ( c E r s t e R a m Z e l l e +
i T e s t L a e n g e ) − RamE;
199
Ram Check ( cErsteRamZelle , RamE) ;
200
// P o i n t e r a u f Anfang s e t z t e n
201
c E r s t e R a m Z e l l e = RamA;
202
// und r e s t l i c h e Z e l l e n p r ü f e n
203
Ram Check ( cErsteRamZelle , ( c E r s t e R a m Z e l l e +
iTestLaengeTemp ) ) ;
204
}
205
else
206
// Ram Test d u r c h f ü h r e n .
207
Ram Check ( cErsteRamZelle , ( c E r s t e R a m Z e l l e + i T e s t L a e n g e )
);
208
209
// Ramzelle a u f n ä c h s t e Z e l l e s e t z e n
210
// ( f a l l s Ramende , dann a u f Ramanfang )
211
cErsteRamZelle = cErsteRamZelle + 1 ;
212
i f ( c E r s t e R a m Z e l l e > RamE)
213
214
215
}
216
217
218
// e i g e n t l i c h e r Ram Test
219
v o i d Ram Check ( u n s i g n e d c h a r ∗ cStartAddr , u n s i g n e d c h a r ∗
Seite 51
cEndAddr )
220
{
221
unsigned char cOriginalByte ;
222
v o l a t i l e u n s i g n e d c h a r ∗ cTestAddr ;
223
224
f o r ( cTestAddr = cStartAddr ; cTestAddr < cEndAddr ;
cTestAddr++ ) {
225
c O r i g i n a l B y t e = ∗ cTestAddr ;
// O r i g n a l w e r t s p e i c h e r n
∗ cTestAddr = 0 x55 ;
// T e s t w e r t e l a d e n und
226
227
Pr üfen
i f ( ∗ cTestAddr != 0 x55 )
228
229
testError () ;
230
231
∗ cTestAddr = 0xAA ;
232
i f ( ∗ cTestAddr != 0xAA )
233
testError () ;
234
∗ cTestAddr = c O r i g i n a l B y t e ;
235
// O r i g i n a l w e r t
wiederherstellen
}
236
237
}
Quellcode 5.5: RAM-Test
5.2.4 ROM-Test
Anders als das RAM, ist der Nur-Lese-Festwertspeicher (Read only Memory, ROM)
ein nicht flüchtiger, aber auch nicht beschreibbarer Speicher, in dem meistens das
Programm zur Steuerung des Systems abgelegt wird. Daher ist es wichtig, dass dieser
Speicher fehlerfrei ist, denn selbst ein einzelnes gekipptes Bit kann den Programmablauf im Worst-Case derartig verändern, dass eine gefährliche Sitation eintritt.
Der Programmspeicher des ATMega169P ist als Flash-EEPROM realisiert, das,
wie auch der verbaute EEPROM, nur eine bestimmte Anzahl an Schreib-/LöschZyklen verfügt in der die korrekte Beschreibung gewährleistet ist (vgl. Abschnitt
3.1.1, S. 15). Geprüft wird der Programmspeicher, indem über dessen Inhalt eine
Prüfsumme mittels einer zyklische Redundanzprüfung (Cyclic Redundancy Check,
CRC) gebildet wird. Als eingesetzte Verfahren kommt CRC-CCITT, auch als CRC16
bekannt, zum Einsatz.
Das CRC-Verfahren nutzt zur Bildung der Prüfsumme die Polynomdivision. Hierbei werden die Nutzdaten Byteweise durch ein Generator-Polynom - x^16+x^12+x^5+1
Seite 52
beim CRC-CCITT-Verfahren - dividiert. Dies geschieht solange, bis alle Nutzdaten
abgearbeitet wurden, wobei immer der Rest einer einzelnen Berechnung mit dem
nächsten Byte verknüpft wird. Der nach Abschluss der Division verbleibende Rest
ist die Prüfsumme, die zur Prüfung der Validität der Daten genutzt wird
Beim ROM-Test wird eine aus dem Inhalt des Programmspeichers gebildete Prüfsumme an einer festen Adresse im EEPROM abgelegt. Sie dient als Erwartungswert für
den Algorithmus, der zur Laufzeit ebenfalls eine Prüfsumme über den Programmspeicher bildet. Der Speicherinhalt wird dabei durch das gleiche Generator-Polynom
dividiert, das auch bei der Prüfsummenbildung verwendet wurde, so dass bei korrekter Speicherfunktion ein identischer Rest als Ergebnis verbleibt. Stimmt das errechnete Ergebnis des ROM-Tests mit dem vorher gebildeten Erwartungswert überein,
so sind die Daten im Programmspeicher integer. Abbildung 5.10 zeigt die Struktur
des ROM-Tests.
Abbildung 5.10: Struktur des ROM-Tests.
Zu beachten ist, dass die Bearbeitungsdauer des ROM-Tests, bei einem Test des
kompletten Speicherbereiches, sehr hoch ist. Dieser erstreckt sich von 0x0000 bis
0xEFFF, was 61439 Speicherzellen entspricht. Um die Unterbrechung des eigentlichen Programms durch den ROM-Test auf ein vertretbares Maß reduzieren zu
können, wurde eine Durchführung in mehreren kleinen Schritten vorgesehen. Dazu
kann anhand der Variable iFlashTestLaenge die Anzahl der pro Zyklus auszulesenden Speicherzellen eingestellt werden. Nachdem der komplette Speicherbereich
ausgelesen wurde, findet der Vergleich mit der Erwarteten CRC-Prüfsumme statt.
Weiterhin muss bei jeder Programmänderung ein neuer Erwartungswert berechnet
und in das EEPROM übertragen werden, da selbst kleine Änderungen im Quellcode,
wozu auch Kommentare und Leerzeilen zählen, den Inhalt des Programmspeichers
verändern.
Seite 53
5.2.5 Ports als Ein- und Ausgänge
Um Ein- und Ausgaben zu realisieren, benötigt ein µC Ports. Auf dem Butterflyboard wird beispielsweise das verbaute LCD-Display über verschiedene Ports angesteuert. Um die korrekte Funktionsweise der Ports zu gewährleisten, müssen diese
getestet werden. Zu diesem Zweck müssen in dem System dieser Arbeit zwei Ports
miteinander verbunden werden, um ein auf dem einen Port ausgegebenes Signal auf
dem anderen Port einzulesen und auf Korrektheit zu prüfen. Dabei ist zu beachten, dass Ports, die vom Programm als Ausgänge genutzt, auch als Ausgänge im
Test geprüft werden. Dementsprechend müssen vorgesehene Eingänge in den Test
als Eingänge fungieren.
Der Aufbau des Systems in der zweiten Revision sah keine entsprechenden Vorkehrungen vor, um beide Ports miteinander zu verbinden. Weitere Ports die zur Laufzeit des Programms genutzt werden können, sind auf dem Butterfly nicht vorhanden,
wodurch es notwendig ist den Test außerhalb des regulären Programmablaufs durchzuführen. Daher wurde Revision 3 mit entsprechenden Verschaltungsmöglichkeiten
realisiert (vgl. Abschnitt 3.3, S. 20).
Der Test beinhaltet zwei mögliche Testabläufe. Bei der ersten Möglichkeit, im
Quellcode 5.6 als Prüf-0-Test bezeichnet, wird an dem ausgehenden Port eine laufende 0 angelegt. Das heißt, dass alle Pins, bis auf einen, auf 1 gesetzt werden.
Begonnen wird mit Pin 0. Anschließend wird geprüft, ob am eingehenden Port der
korrekte Wert anliegt. Sofern dies der Fall ist, wird Pin 0 auf 1 und Pin 1 auf 0
geschaltet und die Prüfung wiederholt. Dies wird solange durchgeführt, bis alle Pins
einzeln durchgeschaltet wurden.
Die andere Möglichkeit - Prüf-1-Test - vertauscht die Zustände. Statt einer 0
wird eine laufende 1 angelegt. Beide Tests können einen feststeckenden (stuck-at)
Pin identifizieren. Sollte der ausgegeben Wert nicht mit dem zurück gelesenen Wert
übereinstimmen, so ist einer der beiden Ports defekt. Um jedoch heraus zu finden,
welcher der verwendeten Ports den Wert nicht korrekt übermittelt hat, muss der
Test mit einem drittem Port zur Kontrolle wiederholt werden. Dies ist mit dem
Butterflyboard jedoch nicht möglich, da es nur zwei Ports zur weiteren Verarbeitung nach außen leitet. Für das in der Arbeit beschriebene Testszenario genügt es,
den Fehlerfall zu erkennen, um das System in den sicheren Zustand zu überführen.
151
// Methode um d i e P o r t s a u f k o r r e k t e Funktion zu ü b e r p r ü f e n
152
v o i d PortTes t ( ) {
153
u i n t 8 t iPruefVar = 0;
// Pr üf−V a r i a b l e
154
i n t iDDRB = DDRB;
// Port−Zustände s p e i c h e r n
155
i n t iDDRD = DDRD;
5.3 Bibliothek der Tests
Seite 54
156
i n t iPortB = PORTB;
157
i n t iPortD = PORTD;
158
DDRB = 0 x00 ;
159
DDRD = 0xFF ;
160
// PortB a l s Eingang
// PortD a l s Ausgang
161
// Pr üf −0−Test
162
i P r u e f V a r = ˜0 x01 ;
163
PORTD = i P r u e f V a r ;
164
f o r ( i n t i =0; i <=7; i ++){
165
i f (PINB != i P r u e f V a r )
166
// Pr üf −0 v o r l a d e n
// Vgl . PortB und pru e fV a r
testError () ;
167
i P r u e f V a r = ( i Prue fVar <<1) | 0 x01 ;
168
// 0 s c h i e b e n
}
169
170
171
/∗
172
173
i P r u e f V a r = 0 x01 ;
174
175
f o r ( i n t i =0; i <=7; i ++){
176
177
// Vgl . PortB und pru e fV a r
testError () ;
178
i P r u e f V a r = ( i P r u e f V a r << 1 ) ;
179
180
}
181
∗/
182
183
// a l t e Zustände zur ück s e t z e n
184
DDRB = iDDRB ;
185
PORTB = iPortB ;
186
DDRD = iDDRD ;
187
PORTD = iPortD ;
188
}
Quellcode 5.6: Porttest
Alle implementierten Tests sind zu einer Bibliothek zusammen gefasst worden. Diese
Bibliothek kann in andere Projekte eingebunden werden, um sie um die Möglichkeit der Selbsttests zu erweitern. Abbildung 5.11 zeigt die Struktur der Bibliothek.
Seite 55
Sie stellt Variablen und Methoden bereit, um die Tests aufzurufen, setzt aber eine
implementierte Routine für den Fehlerfall voraus.
Abbildung 5.11: Struktur der Test-Bibliothek
Die Variable iTestStat vom Typ int beinhaltet die Nummer des zuletzt ausgeführten Selbsttests. In der Variablen iTestAnzahl steht die Nummer des höchsten, auszuführenden Tests. Um die Tests der Reihe nach auszuführen, genügt es, eine Schleife zu durchlaufen, die alle Selbsttests nacheinander aufruft, bis sie bei der höchsten
Nummer angekommen ist. Der Quellcode 5.7 ist ein Beispiel für eine mögliche Implementierung dieser Schleife.
505
/∗ −−− S e l b s t t e s t −A u f r u f −−− ∗/
506
v o i d doTest ( ) {
507
selectTest () ;
// Testauswahl a u f r u f e n
508
i T e s t S t a t ++;
// Z ä h l e r erhöhen
509
i f ( iTestStat > iTestAnzahl )
// IF Z ä h l e r > T e s t a n z a h l . .
510
511
iTestStat = 0;
// . . Z ä h l e r zur ück s e t z e n
}
Quellcode 5.7: Beispiel: Aufruf der Selbsttests
Um einzelne Tests zu überspringen, müssen diese über bedingte Anweisungen IF-Anweisungen - abgefangen und umgangen werden. Sollen nur spezielle Tests
durchgeführt werden, kann mit der Methode startTest(int iTestNr) ein gezielter Test aufgerufen werden. Dabei ist iTestNr durch die Nummer des gewünschten
Tests zu ersetzen:
Seite 56
• 0 - 31 : Registertests
• 32 : Push-Pop-Return-Jump-Test
• 33 - 38 : Arithmetische Tests
• 39 - 45 : Tests der logischen Bitoperationen
• 46 - 48 : Tests der logischen Operationen
• 49 - 52 : Tests der Transfer-Befehle
• 53 : RAM-Test
• 54 : ROM-Test
• 55 : Port-Test
• 96 - 98 : Tests der Timer
• 99 : Watchdog-Test
Alternativ kann ein Array vom Typ int angelegt werden, das die Nummern aller auszuführenden
Tests
enthält.
Anschließend
wird
die
Methode
startTest(int iTestNr) über eine Schleife mit den Werten aus dem Array aufgerufen. Diese Technik hat den Vorteil, dass wichtigere Tests öfter durchgeführt werden
können, indem sie öfter in das Array eingetragen werden.
Auch denkbar ist eine Lösung mittels Zeitscheibensystem. Der Aufruf ist in diesem Fall nicht an einen festen Punkt im Programmablauf gebunden, sondern wird
von einem Testmanager übernommen, sobald eine freie Zeitscheibe verfügbar ist.
Vorteil dieser Methode ist, dass zu lastfreien Zeiten mehr Tests durchgeführt werden können als beim zyklischen Ansatz. Dass auch unter Last die Testrate nicht zu
stark sinkt, muss der Testmanager sicherstellen, indem er, wie im zyklischen Ansatz,
Zeitscheiben für Tests einplant. Nachteil dieser Methode ist der erhöhte Aufwand in
der Erstellung des Systems und die Schwierigkeit nachzuvollziehen, wann genau ein
Test durchgeführt wird. [Klug97]
Um die Bibliothek in ein Projekt einbinden zu können, muss die Fehlerroutine
testError() definiert werden. Diese Routine wird aufgerufen, wenn ein Fehler bei
einem Selbsttest auftritt. Eine mögliche Implementierung dieser Methode zeigt der
Quellcodeauszug 5.8. Dabei wird über die beiden Ports des AVR Butterfly die Fehlermeldung ausgegeben, wie sie in Abbildung 4.6 (S. 34) gezeigt ist. Außerdem wird
der Fehlercode im EEPROM gespeichert.
Seite 57
416
/∗ −−− F e h l e r r o u t i n e f ü r S e l b s t t e s t f e h l e r −−− ∗/
417
void t e s t E r r o r ( ) {
418
c l i () ;
419
wdt disable () ;
// I n t e r r u p t s d e a k t i v i e r e n
420
421
// I n i t i a l i s i e r e d i e P o r t s a l s Ausgang
422
// Fehlermeldung und a k t u e l l e S e l b s t t e s t n r ausgeben
423
DDRD = i S e c u r e P o r t D ;
424
DDRB = 0xFF ;
425
PORTB = i T e s t S t a t ;
426
427
// F e h l e r w e r t i n s Eeprom
428
eepromWrite ( i S p e i c h e r 2 , i T e s t S t a t ) ;
429
while (1) {
430
431
// S e t z t d i e LEDs an PORTD a u f den F e h l e r c o d e −Anzeige
432
PORTD = ( 0 x55 & i S e c u r e P o r t D ) ;
433
434
435
436
437
PORTD = ( i O f f & i S e c u r e P o r t D ) ;
438
439
440
441
}
442
443
}
Quellcode 5.8: Beispielhafte Implementierung der testError()
Diese Bibliothek kann in Projekten mit µC eingesetzt werden, die über den gleichen
Befehlssatz und den gleichen technischen Aufbau verfügen wie der hier verwendete
ATMega169P. Stimmen die verwendeten Befehle nicht mit denen des neuen µC
überein, so sind einzelne Tests bis hin zur ganzen Bibliothek nicht lauffähig. Um die
Tests auf Projekte mit einem absolut verschiedenen Controller zu übertragen, ist es
nötig, alle Tests einzeln zu konvertieren. Eine globale Implementierung der Tests, die
auf allen Prozessoren lauffähig ist, kann selber in einer Hochsprache nicht realisiert
werden. Selbst µC gleicher Art - RISC, CISC - unterscheiden sich von Familie zu
Familie derart, dass anders gestaltete Tests notwendig werden .
6 Beobachtung des Verhaltens unter Umgebungsbedingungen
Seite 58
6 Beobachtung des Verhaltens unter
Umgebungsbedingungen
Um die Frage zu klären, ob homogene Redundanz die Wahrscheinlichkeit eines Ausfalls infolge gemeinsamer Ursache erhöht, wird das System verschiedenen, extremen Umgebungseinflüssen ausgesetzt. Dabei wird beobachtet, wie sich das System
bezüglich seines Ausfallverhaltens verhält.
6.1 Ausgangssituation
Die Ausgangssituation für die Versuche war ein Rechnersystem mit zwei unterschiedlichen Revisionen, die mit der erstellten, zyklisch die vorgesehenen Schritte
abarbeitende Software betrieben wurde. In der Software waren dabei die Standardeinstellungen eingestellt, d.h. die Synchronisation sowie die Selbsttests waren aktiv
und alle weiteren Einstellungen auf einen festgelegten Wert eingestellt. Die Werte
können dem Quellcode 4.1 (S. 29) entnommen werden.
Dieser Aufbau wurde für alle Untersuchungen verwendet. Kontrollprüfungen einzelner Versuche zeigten keinen Unterschied zwischen einem System aus zwei Kanälen
gleicher Revision oder aus einem mit zwei Kanälen unterschiedlicher Revision. Daher
wird davon ausgegangen, dass der Unterschied das Verhalten des Rechnersystems
nicht beeinflusst.
Lediglich der definierte Ausgang hat sich im Laufe der Versuche verändert. Zu
Beginn war kein fest definierter Ausgang vorgesehen. Über die Anzeigen der LEDs
konnte der Status eindeutig erkannt werden. Um jedoch das Verhalten des Systems
an ein System der Kategorie 3 anzunähern, wurde ein Ausgang definiert. Dazu wurde
Pin 8 von Port D umfunktioniert. Im sicheren Zustand dient er als Eingang ohne
jedoch die internen Widerstände geschaltet zu haben. Das bedeutet, dass eine 0
anliegt, Low-Pegel. Im unsicheren Zustand ist er Ausgang und gibt eine 1 - HighPegel - aus.
Sollte einer der Versuche ein Bit zum Kippen bringen, würde dies nicht ausreichen, um den sicheren Zustand zu verlassen. Um in einen nicht sicheren Zustand
zu gelangen, müssten entweder das Bit für die Porteinstellung und das Bit für das
ausgegebene Signal kippen oder der Programmablauf so verändert werden, dass der
µC selber die Einstellung ändert. Erst dann würde im sicheren Zustand eine 1 am
definierten Ausgang anliegen.
6.2 Elektromagnetische Verträglichkeit
Seite 59
Jedes elektrische Gerät hat elektromagnetische (EM) Eigenschaften, die auf andere
Geräte in der Nähe wirken. Diese Auswirkungen können Störungen - Interferenzen - hervorrufen. Ein Gerät, das nicht hinreichend gegen diese Einflüsse geschützt
ist, kann durch diese Interferenzen gestört werden. Die elektromagnetische Verträglichkeit (EMV) eines System setzt voraus, dass es zufriedenstellend in einer
EM-Umgebung funktioniert ohne dabei Störungen zu verursachen, die für andere
Systeme unannehmbar wären. [Goed97, S.15]
Abbildung 6.1: Prinzip des Interferenzen-Problems
[Goed97, S.19]
Auftretende Interferenzen können dabei durch unterschiedliche Emissionen der Geräte
auftreten. Die Art der Einwirkung, der Kopplungsweg, kann dabei variieren.
Die hier durchgeführten Untersuchungen der elektromagnetischen Verträglichkeit
prüfen die Möglichkeit zwei gleiche Systeme durch Beeinflussung in den unsicheren
Zustand zu bringen. Dazu wirken Störungen, wie sie in einer EM-Umgebung auftreten können, über verschiedene Kopplungswege auf das Rechnersystem ein. Um die
Versuche einfach zu halten, wurde das System nicht durch Filterschaltungen oder
spannungsbegrenzende Bauteile gegen Störungen geschirmt, wodurch es auch für
geringe Störungen anfällig ist und somit ein Worst-Case“-Szenario darstellt.
”
Eine genaue Analyse der Signale im System wurde nicht vorgenommen, da der
primäre Beobachtungspunkt das Ausfallverhalten war. Es wurde lediglich geprüft,
ob durch Störungen ein unsicherer Ausfall reproduzierbar erreicht werden kann.
6.2.1 Kapazitive Kopplung
Kapazitive Kopplungen sind Störungen, die zwischen Leitern mit unterschiedlichem
Potential auftreten können. Sie sind meistens die Folge von unzureichend oder nicht
geschirmten Leitungen, können aber auch bei Verlegung von störungsbehafteten
direkt neben empfindlichen Leitungen auftreten.
Um das Verhalten des Rechnersystem unter den Einwirkungen von kapazitiven
Kopplungen zu beobachten, wurden auf die Leitungen verschiedene Impulse gegeben.
Insgesamt vier verschiedene Versuchsaufbauten wurden konstruiert. Dabei wurde
zweimal auf das serielle Kabel eingekoppelt, jeweils mit anderem Bezugspunkt. Des
Seite 60
weiteren wurden die Impulse noch über die Versorgungsleitung und über eine, isoliert
unter dem System befindliche, Koppelplatte eingekoppelt.
Abbildung 6.2: Positiver Impuls (rot) und Impulsfolge (blau)
Abbildung 6.2 zeigt einen positiven Impuls und eine Impulsfolge von schnell aufeinanderfolgenden, transienten Impulse, wie sie in den Versuchen verwendet wurden.
Die Impulsfolge hat eine Frequenz von etwa 120 Hz, was einem Impuls etwa alle 8
ms entspricht. Der maximale Spannungswert des einzelnen Impulses liegt bei etwa
80 V, die eines Impulses des Bursts beträgt im Schnitt 130 V. Außer mit positiven
wurde auch mit negativen Impulsen geprüft. Wie die positiven Impulse haben sie
eine Anstiegszeit von circa zehn µs, einer Breite von circa 200 µs und erreichen bis
zu -130 V.
Aufbau 1a - serielle Schnittstelle
Im ersten Versuchsaufbau wurde überprüft, wie empfindlich die serielle Schnittstelle
auf kapazitive Kopplungen reagiert. Dazu wurde direkt auf das verbindende Kabel
zwischen den zwei Kanälen eingekoppelt. Dieses Kabel ist ein, aus drei Adern bestehendes, ungeschirmtes Nullmodemkabel, weshalb die Störspannungen direkt auf
die Datenleitungen einkoppeln.
Der Versuch ergab, dass ein einmaliger, kurzfristiger Impuls nicht ausreicht, um
das System zu stören. Die entstehende Störspannung überschreitet nicht den Wert,
um von der seriellen Schnittstelle als gekipptes Bit erkannt zu werden. Erst durch
eine Burst-Störung konnten die übermittelten Daten beeinflusst und die Störung
des Systems erreicht werden. Je nach Art des Bursts, positiv oder negativ, trat
Seite 61
die Störung unmittelbar oder verzögert ein. Ein negativer Burst störte das System
innerhalb kurzer Zeit (2-3 Sekunden). Trifft ein negativer Impuls des Burst in eine
Übertragung, kippen durch die Störspannung die High-Pegel auf Low-Pegel, wodurch
keine korrekte Synchronisation mehr möglich ist.
Ein positiver Burst erzeugte keine Störspannungen, die das System stören konnten.
Erst beim Abschalten des Bursterzeugers kam es durch technische Bedingtheiten zu
einem satten, negativem Impuls, der das System auf die gleiche Weise beeinflusste
wie ein negativer Burst. Abbildung 6.3 zeigt eine beispielhafte Störung eines Bits.
Abbildung 6.3: Störung der Übertragung durch gekipptes Bit
Die auftretende Störung wurde vom System über Maßnahmen erkannt und behandelt, wodurch das System trotz Störung den sicheren Zustand erreichte.
Aufbau 1b - serielle Schnittstelle zu GND
Auch dieser Aufbau - Abbildung 6.4 - dient der Überprüfung der seriellen Schnittstelle. Anders als beim ersten Versuchsaufbau wurde hier das Potential des Störkreises
auf die Masse eines Kanals gelegt. Durch diese Änderung ergab sich eine Störung
auch schon durch einen einzelnen Impuls. Zurück zu führen ist dies auf den geänderten Koppelweg und die daraus resultierende, stärkere Störung. Bereits ein einzelner
Impuls erzeugt Störspannungen in einer Größenordnung, die zum Kippen eines Bits
auf der seriellen Schnittstelle ausreichen.
Trotzdem wurde die auftretende Störung erkannt und durch Überführung des
Systems in den sicheren Zustand behandelt.
Aufbau 2 - Versorgungsleitung
Ob eine kapazitive Einkopplung auf die Versorgungsleitung der Kanäle einen Fehler
oder gar den unsicheren Ausfall provozieren kann, wurde durch den zweiten Versuchsaufbau geprüft. Der Bezugspunkt des störenden Systems wurde, wie im vorhergehenden Versuch, auf die Masse eines Kanals gelegt, während der positive Pol
auf den Leitungen vom Netzteil zu den Kanälen einkoppelte.
Seite 62
Abbildung 6.4: Versuchsaufbau 1b - serielle Schnittstelle zu GND
Das Ergebnis war, dass negative Einzelimpulse wie auch der negative Burst einen
Fehler im System auslösten, während positive Impulse oder Bursts keinen Einfluss
ausübten. Durch die negativen Impulse sank vermutlich die Versorgungsspannung
unter die von der EIA-232-Schnittstelle benötigten 3 V, wodurch eine Übertragung
von Daten zur Synchronisation nicht mehr möglich war. Dadurch konnten keine 0 High-Pegel - mehr übertragen werden und alle Bits wurden als 1 erkannt.
Trotz des Spannungsabfalls reichte die Restspannung zur korrekten Datenverarbeitung des µC. Daher werden die Fehler erkannt, wodurch das System in den
sicheren Zustand überführt wird. Ein unsicherer, gefahrbringender Ausfall ist nicht
eingetreten.
Aufbau 3 - Koppelplatte
Im letzten Versuch wird die Wirkung einer kapazitiven Kopplung auf das gesamte
System geprüft. Dazu wird mittels einer Platte, die sich in diesem Versuchsaufbau
unter den Systemen befindet, auf die komplette Fläche der Kanäle eingekoppelt. So
entstehende Störspannungen wirken auf alle Bauteilen und alle Leitungen und nicht
nur an einzelnen Punkten ein.
Das am stärksten gestörte Element ist wiederum die empfindliche, gegen Störungen nicht geschirmte, serielle Schnittstelle. Bei einer Störung mittels positiver oder
negativer Bursts wird daher ein Synchronisationsfehler erkannt, was zum sicheren
Abschalten des Systems führt.
Seite 63
6.2.2 Elektrostatische Entladung
Elektrostatische Entladungen (Elektotatic Discharge, ESD) sind Entladungen statischer Elektrizität. Sie treten immer dann auf, wenn ein statisch geladener Körper
seine Ladung über einen Funken oder einen Durchschlag auf ein leitendes Material
entlädt. Diese Impulse haben eine sehr geringe Anstiegszeit, häufig unter einer Nanosekunde und eine maximale Dauer von 50 ns. Während des Impuls fließen transiente
Ströme, die magnetische und elektrische Felder erzeugen. Entladungen, die direkt
auf Bauteile gerichtet sind, können die Zerstörung dieses Bauteils durch Durchschlag
bewirken.
Die Aufladung vor einem ESD erfolgt bei der Trennung von zwei sich vorher
berührenden Materialien, von denen mindestens eines isolierende Eigenschaften besitzt. [Schwa96] Die dabei entstehende Spannung ist von den Materialien und der
Luftfeuchtigkeit abhängig und kann bis zu 30 kV betragen. Meistens entsteht eine
ESD, wenn ein Mensch einen elektrischen Leiter, etwa einen geerdeten Gegenstand
aus Metall, berührt. Dabei kann es sich beispielsweise um Leitungen oder Verkleidungen von Geräten handeln. Abbildung 6.5 zeigt deutlich eine elektrostatische Entladung.
Abbildung 6.5: Sichtbare ESD-Entladung
Der im Versuch eingesetzt ESD-Generator erzeugte einen Impuls mit einer Spannung von annähernd 15 kV. Anders als ein Burst-Impuls ist seine Energie allerdings
sehr gering. [Fis92, S. 129] In verschiedenen Versuchsaufbauten wurde das System
auf unterschiedliche Weise mit dieser Entladung gestört. Eine direkte Einwirkung
auf den µC wurde nicht vorgenommen, da dies möglicherweise die Zerstörung des
Systems durch unzureichende EMV-Sicherung bedeuten könnte. Weiterhin ist es
nicht möglich den Impuls auf beide µC gleichzeitig zu geben, so dass der sichere
Zustand auch bei Komplettausfall des anderen Systems erreicht werden würde. Eine Einwirkung dieser hochsynchronen Art würde auch nicht den realen Störungen
entsprechen.
Seite 64
Folgende Aufbauten wurden vorgenommen:
• kapazitive ESD-Einwirkung auf die Versorgungsleitungen
• kapazitive ESD-Einwirkung über eine Koppelplatte
• direkte Einwirkung auf die EIA-232-Buchse
Die Untersuchungen ergaben, dass ein ESD das System dermaßen enorm stört, dass
ein Reset ausgelöst wird. Der Angriffspunkt der einzelnen Aufbauten spielte dabei
keine Rolle. Egal ob über kapazitive Kopplungen des Impulses oder durch direkte
Einspeisung auf den Bezugspunkt, die Reaktion war immer die gleiche.
Lediglich die Einkopplung über die Koppelplatte führte in einem Fall zu unterschiedlichen Reaktionen. Während das eine System durch einen Reset zurück gesetzt
wurde, zeigte das andere System den Ausfall seines Gegenübers an. Der sichere Zustand wurde von beiden Systemen erreicht. Zu erklären ist dies durch die verschiedene Einwirkung des ESD über die Koppelplatte. Die Entfernung vom Punkt der
Einspeisung zur Fläche der Einkopplung sowie die Toleranzen der Bauteile in den
einzelnen Systemen lassen die Reaktion leicht variieren.
Einen Defekt oder einen undefinierten Zustand gab es durch die ESD-Versuche
nicht. Nach dem Impuls und dem daraus resultierenden Reset verblieben die Systeme
im sicheren Zustand.
6.2.3 Unterbrechung der Versorgungsspannung
Der in Abbildung 6.6 dargestellte Versuchsaufbau dient zur Untersuchung des Verhaltens des Rechnersystems bei plötzlich ausfallender Versorgung. Dazu wurden beide Systeme über Leitungen, deren Aufbau und Länge gleich beschaffen sind, an ein
gemeinsames Netzteil angebunden. Dieses unterbrach die Versorgungsspannung in
festen Abständen für eine eingestellte Dauer. Diese Dauer wurde variiert, um zu
prüfen, ob ein Bereich existiert, in dem das Verhalten der Systeme nicht definiert
ist.
Begonnen wurde mit einer Unterbrechung von 1 ms, bei einer Periodendauer von
1 s. Die Unterbrechung für diese kurze Dauer verursachte keinerlei Störung. In dieser
Zeit wird die Spannung von verbauten Kondensatoren stabilisiert.
Eine Unterbrechung über 10 ms zeigte ebenfalls keinerlei Reaktion, erst ab 100
ms änderte sich das Verhalten. So wurde ab dieser Dauer ein Synchronisationsfehler erkannt. Während der Unterbrechung sinkt die Spannung unter die benötigte
Betriebsspannung der EIA-232, womit keine eindeutigen High-Pegel mehr erzeugt
werden können. Für den µC reicht die restliche Spannung aus, weshalb kein Reset durchgeführt wird. Dieser passiert erst ab etwa 200 ms Unterbrechungsdauer.
Nach einer Unterbrechung startet das System neu, verweilt nach dem Start aber im
Seite 65
Abbildung 6.6: Versuchsaufbau: Spannungsunterbrechung
sicheren Zustand.
Abbildung 6.7 zeigt den zeitlichen Verlauf der Spannung bei einer 10 ms dauernden Unterbrechung. Wie der Abbildung entnommen werden kann, entspricht die
Rasterbreite 10 ms während die Höhe jedes Kastens 2 V entspricht.
6.2.4 Austastung der Versorgungsspannung
Wie im Versuch zur Unterbrechung der Versorgungsspannung, wurde auch in diesem Versuchsaufbau die Versorgungsspannung der Kanäle modifiziert. Mittels des
gleichen Aufbaus - Abbildung 6.6 - wurde auch dieser Versuch durchgeführt. Allerdings wurde die Spannung nicht komplett abgeschaltet, sondern lediglich bis in den
undefinierten Bereich reduziert. Um dies zu erreichen, wurde die Spannung für eine
festgelegte Dauer auf 1 V gesenkt. Als Ausgangsspannung wurden 3,8 V genommen. Ein vorhergehender Versuch zeigte, dass mindestens 3,8 V benötigt werden,
um einen normalen Betrieb zu erreichen. Andernfalls reicht die Spannung nicht aus
um definierte High-Pegel auf der seriellen Schnittstelle erzeugen zu können. Dies
liegt daran, dass der Spannungsregler, obwohl es sich um ein Very Low Drop Modell handelt, 0,45 V Spannungsabfall erzeugt, womit die dem System tatsächlich zur
Verfügung stehende Spannung unter 3 V sinkt.
Ab einer Austastungsdauer von 100 ms pro Sekunde wurde ein Synchronisationsfehler erkannt. Während der Austastung sank die Versorgungsspannung unter die
benötigte Mindestspannung für die Peripherie, so dass eine Kommunikation über
Seite 66
Abbildung 6.7: Zeitlicher Verlauf der Spannung
die serielle Schnittstelle nicht mehr möglich war und die LEDs erloschen. Dem µC
reichte die verbleibende Spannung, um die Datenverarbeitung aufrecht zu erhalten.
Eine Austastung der Spannung von einer halben Sekunde lies das System einen
Reset durchführen. Nach diesem verblieb es, wie auch im vorher gehenden Versuch,
im sicheren Zustand. Weitere Erhöhungen der Austastungsdauer führten nur zu
längeren Pausen zwischen dem Ab- und dem wieder Anschalten des Systems. Ein
unsicherer Zustand wurde nicht erreicht.
6.2.5 Analyse der EMV-Untersuchungen
Wie die einzelnen Untersuchungen der EMV-Analyse zeigten, wirkt sich eine EMUmgebung in der überwiegenden Anzahl auf die relativ anfällige serielle Schnittstelle aus. Diese Fehler werden erkannt, da zu diesem Zeitpunkt eine Störung des
µCs aufgrund seiner geringeren Anfälligkeit nicht vorliegt. Durch fehlerbehandelnde Maßnahmen reagieren die Kanäle auf die Störungen, indem der sichere Zustand
eingeleitet wird.
Eine Störung, die auch den µC in seiner Arbeitsweise beeinflusst, ist indes nicht
aufgetreten. Wird eine bestimmte Intensität der Störungen überschritten, so führte
das Rechnersystem einen Reset durch, wodurch das System ebenfalls in den sicheren
Zustand gelangte.
Daher ist anzunehmen, dass homogen redundante Systeme ebenso wenig für Fehler
und Ausfälle infolge gemeinsamer Ursache anfällig sind wie ihre diversitäre Pendants.
Solange in den SRP/CS Elemente vorhanden sind, die empfindlicher auf Störungen
reagieren als die steuernden Mikroelektronik, wird eine Störung diese als erstes be-
6.3 Temperaturbeständigkeit
Seite 67
einflussen, wodurch fehlerbehandelnde Maßnahmen eingeleitet werden können.
Schirmungen oder andere, EMV verbessernde Maßnahmen können die Fehleranfälligkeit einzelner Elemente reduzieren, wodurch die Fehleranfälligkeit von µC im Vergleich zum restlichen System steigen kann. Im Falle einer Störung kann dann der
Controller das gestörte Element sein. Dass in diesem Fall homogene Redundanz
anders reagiert und dadurch häufiger oder leichter einen unsicheren Ausfall hervorruft, kann jedoch nicht gefolgert werden. Bauteiltoleranzen und Unterschiede in den
Signalpfaden führen meistens dazu, dass keine exakt gleiche Arbeitsweise vorliegt.
Selbst mit identischer Hard- und Software unterscheidet sich die Arbeitsweise und
die Reaktionen auf Einflüsse, wodurch auch auf Störungen unterschiedlich reagiert
wird.
Ein Beispiel dafür ist die ESD-Prüfung über die Koppelplatte. Obwohl beide Systeme unter den gleichen Bedingungen betrieben wurden, ist nicht immer dieselbe
Störung erkannt worden.
Neben den elektromagnetischen Störungen wirkt auf SRP/CS auch die Temperatur des Standorts ein. Die Umgebungstemperatur kann die Funktionsweise eines
Systems dabei maßgeblich beeinflussen. Jedes elektronische System besteht zu einem Großteil, wenn nicht sogar ausschließlich, aus elektrischen Bauteilen, welche
ihr Verhalten unter wechselnden Bedingungen ändern. Daher ist es wichtig zu wissen, wie sich das Verhalten der einzelnen Elemente ändert, um eine Aussage über
die Funktionsweise des gesamten Systems unter Einfluss der Umgebungstemperatur
treffen zu können. Eine Schaltung besteht meistens aus einer Anzahl von StandardKomponenten wie Widerständen, Kondensatoren und Transistoren. Diese verfügen
über unterschiedliche Eigenschaften unter Temperaturwechseln.
Widerstände werden beispielsweise in zwei Kategorien unterteilt. Es gibt sie mit
positivem und negativem Temperaturkoeffizienten (α). Ein positiver Temperaturkoeffizient bedeutet, dass sich der Widerstandswert bei steigenden Temperaturen
erhöht. Bei Wideständen mit negativem α verhält es sich entsprechend umgekehrt.
Das Verhältnis zwischen Temperatur- und Widerstandsänderung ist in den meisten
Fällen linear. Wird eine Kombination aus Widerständen mit positiven und negativen Koeffizienten verwendet, kann das Maß der Widerstandsänderung teilweise
kompensiert werden. [Krue08, S. 237]
Auch Kondensatoren besitzen, wie Widerstände, einen Temperaturkoeffizienten.
Dieser hat Auswirkung auf die Kapazität des Kondensators. Da die Produktion von
Kondensatoren aufgrund von Prozessmodellen jedoch hohen Toleranzen unterliegt,
kann die Veränderung der Kapazität in den meisten Fällen vernachlässigt werden.
Seite 68
Bei komplexen Filtern oder Schwingkreisen sind sie von Relevanz, in dem hier eingesetzten System jedoch nicht.
Transistoren dienen in Schaltungen meistens zur Verstärkung von Stromflüssen.
Eine Eigenschaft von Transistoren ist, dass bei höheren Temperaturen ein größerer
Stromfluss möglich ist. Bis zu einem Punkt erhöht sich der Verstärkungsfaktor mit
dem Anstieg der Temperatur. Ist dieser Punkt erreicht, brennt das Bauteil durch.
Im Umkehrzug dagegen wird die Verstärkung bei niedrigen Temperaturen deutlich
geringer ausfallen.[Krue08, S. 236ff]
Diese Auswirkungen können auf das Rechnersystem übertragen werden. Darum ist
das System in einer Klimakammer auf seine Temperaturbeständigkeit geprüft worden. Ausgangstemperatur für die Versuche war die Temperatur im Versuchsraum,
etwa 20°C. Die Möglichkeit zur Regulierung der Luftfeuchtigkeit ist nicht genutzt
worden.
6.3.1 Positiver Temperaturbereich
Im Versuch zur Bestimmung des Verhaltens im positiven Temperaturbereich wurde
das System auf das Spezifikationslimit des µCs - +85°C [ATM08a] - und, nachdem
kein Ausfall stattgefunden hat, darüber hinaus erhitzt. Bis zur Obergrenze wurde in
Schritten von 10°C, anschließend jeweils um 5°C erhöht. Die Gesamtdauer des Versuchs belief sich auf etwa 4 12 Stunden. Während der ersten 60 Minuten wurde das
System von der Ausgangstemperatur bis zum Spezifikationslimit erhitzt. Anschließend wurde es für etwa eine halbe Stunde am Limit betrieben. In der restlichen Zeit
wurde die Temperatur etwa alle 30 Minuten um weitere fünf Grad Celsius bis zur
Endtemperatur von 110°C erhöht. Auf diesem Level lief das System 30 Minuten.
Die Gesamtdauer des Betriebes über dem Spezifikationslimit beläuft sich damit auf
circa drei Stunden.
Abbildung 6.8: Schematischer Temperaturverlauf, positiver Temperaturbereich
Seite 69
6.3.2 Negativer Temperaturbereich
Wie im vorhergehenden Versuch wurde das System bis an seine Spezifikationsgrenzen
gebracht. Im negativen Bereich liegt diese bei -40°C [ATM08a]. Nachdem der Betrieb
unter diesen Bedingungen circa 30 Minuten fehlerfrei verlief, wurde die Temperatur
schrittweise bis auf -65 °C reduziert. Abbildung 6.9 zeigt den Temperaturverlauf vom
Nullpunkt bis zum Spezifikationslimit. Wie der Grafik entnommen werden kann,
dauerte es1 ab 0 °C eine Stunde bis zum erreichen der unteren Grenze von -40°C.
Anschließend wurde das System weitere 2 12 Stunden unter dem Limit bei -55°C und
-65°C betrieben.
Abbildung 6.9: Schematischer Temperaturverlauf, negativer Temperaturbereich
Nach dem Öffnen der Türe zur Klimakammer gefror die eindringende Luftfeuchtigkeit binnen Sekunden an den Versuchsaufbauten. Doch auch dies verhinderte nicht
den reibungslosen Betrieb.
6.3.3 Analyse der Temperaturmessungen
Das Verhalten des Systems unter den Einflüssen extremer Temperaturen zu beschreiben ist, mit den vorliegenden Resultaten, nur eingeschränkt möglich. Während
der Versuche zeigten sich keine Probleme, jedoch stellen diese, auch wenn unter
verschärften Bedingungen durchgeführt, relativ kurze Ausschnitte aus dem Leben
der Systeme dar.
Dass kein Ausfall aufgetreten ist, zeigt zwar, dass das System in seiner aktuellen
Form, zumindest kurzzeitig, sehr temperaturresistent ist, lässt jedoch keine Aussage
darüber zu, wie das System bei einer Störung reagieren würde. Höhere Belastungen
würden die Bauteile des System zerstören, nicht jedoch zu weiteren Erkenntnissen
führen. Derart intensive Überschreitungen von Spezifikationsgrenzen würden eine
Seite 70
unsachgemäße Entwicklung voraussetzen, was nicht den Anforderungen der DIN
EN ISO 13849-1 entsprechen würde.
Um eine gültige Aussage über das Verhalten des Rechnersystems unter längerfristig einwirkenden Temperaturen treffen zu können, müsste dieses über einen längeren
Zeitraum unter moderaten Temperatureinflüssen geprüft werden. Mögliche eintretende Ausfälle müssten schließlich auf das Verhalten der Kanäle und des erreichten
Zustandes - sicher oder unsicher - untersucht werden. Anschließend müsste die Ausfallrate eines gefahrbringenden Ausfalls mit denen diversitärer Pendants verglichen
werden, um die Eignung von homogener Redundanz beurteilen zu können.
Da es sich bei dem hier verwendeten System um eine Art Worst-Case“-Szenario
”
handelt, in dem kaum Maßnahmen gegen Umgebungseinflüsse getroffen sind, kann
davon ausgegangen werden, dass das Verhalten dieses Systems deutlich stärker ausgeprägt ist, als dass eines der Norm entsprechenden Systems. Daher ist anzunehmen, dass die Ausfallwahrscheinlichkeit eines industriellen SRP/CS unter solchen
Einflüssen geringer ist als das des geprüften Teils. Die Tatsache, dass selbst das
einfache System die Tests ohne Fehler absolviert hat, zeigt zumindest die Tendenz,
dass homogene Redundanz keine direkte Schwachstelle für Temperaturempfindlichkeit bedeutet.
7 Zusammenfassung
Seite 71
7 Zusammenfassung
7.1 Ergebnisse
Das im Rahmen dieser Arbeit erstellte System entspricht von der Architektur einem
SRP/CS der Kategorie 3. Die Einfehlersicherheit ist über homogene Redundanz
gegeben. DCavg sowie MTTFd sind nicht bekannt oder gegeben, aber auch nicht
relevant. Das System ist keinesfalls als eine Struktur nach der Norm DIN EN ISO
13849-1 anzusehen, sondern soll lediglich das Verhalten homogener Redundanz unter
Umgebungseinflüssen darstellen können.
Die entwickelte Software sowie die implementieren Selbsttests beinhalten fehlerbehandelnde Maßnahmen. Weiterhin wird in der Software eine Pseudo-Aktion ausgeführt, wodurch eine Maschinensteuerung wie sie in der Industrie eingesetzt wird,
simuliert werden soll. Die Selbsttests sind zu einer Bibliothek zusammen gefasst
und können auf andere Projekte, mit einem µC mit gleichem Befehlssatz, übertragen werden.
Verschiedene Untersuchungen sollten Aufschlüsse über das Verhalten von homogen redundanten Systemen unter Umgebungseinflüssen geben. Hauptaugenmerk der
Untersuchungen war dabei die Frage, ob homogene Redundanz ein erhöhtes Risiko
für Ausfälle infolge gemeinsamer Ursachen birgt.
Wie die Ergebnisse der Untersuchungen zeigen, kann nicht pauschal gesagt werden, dass ein homogen redundant aufgebautes Rechnersystem anfälliger für Ausfälle
infolge gemeinsamer Ursache ist. Das entwickelte System hat, trotz homogener Redundanz, unter Einfluss diverser Störungen keine gefahrbringenden Ausfälle gezeigt.
Eine sicherheitsrelevante Architektur und passende Software zur Betreibung des System kann die Wahrscheinlichkeit der Ausfälle reduzieren. Da diese Anforderungen
von der Norm DIN EN ISO 13849-1 auch an homogen redundante SRP/CS gestellt werden, kann bei konsequenter Umsetzung der Anforderung nicht von einem
erhöhten Risiko ausgegangen werden.
7.2 Ausblick
Die durchgeführten Prüfungen beschränken sich alle auf einen kurzen Zeitraum aus
einem speziell für diese Untersuchungen entwickeltem System. Sie zeigen zwar, dass
unter kurzzeitigen Belastungen auch über die Grenzen des Systems kein gefahr-
7.2 Ausblick
Seite 72
bringender Ausfall stattfindet, können jedoch keine Aussage über die langfristige
Zuverlässigkeit des Systems machen oder repräsentativ für industrielle SRP/CS betrachtet werden.
Um das zu erreichen, kann das Projekt fortgeführt werden. Angedacht sind vollautomatische Testabläufe, die selbstständig ausgewählte Untersuchungen durchführen.
Da bei dieser Art der Prüfung der manuelle Eingriff entfällt oder zu Kontrollzwecken auf ein Minimum reduziert werden kann, kann der Ablauf beschleunigt und ohne dauerhafte Aufsicht durchgeführt werden. Dies würde eine fortlaufend steigende
Anzahl an Prüfungen bedeuten und, je nach Länge des Projektes, auch verschiedene
Abschnitte des Lebenszyklus berücksichtigen.
Um die Ergebnisse der Untersuchungen zu validieren und auf andere Systeme zu
übertragen, ist eine Untersuchung an einem oder mehrerer Systeme aus dem industriellen Einsatz durchzuführen. Das Verhalten eines Systems, das den Anforderungen
der Norm entspricht, ist repräsentativer für eingesetzte SRP/CS als ein an die Norm
angelehntes System. Weiterhin muss durch die Untersuchungen eine Aussage über
den gesamten Lebenszyklus des Systems getroffen werden können, um Parameter
wie Abnutzung und Alterung zu berücksichtigen. Zu diesem Zweck müssen die Bedingungen während der Prüfungen denen während des realen Einsatzes entsprechen.
Seite 73
Fachliteratur
[BGIA06]
BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung: Selbsttests für Mikroprozessoren mit Sicherheitsaufgaben. http://www.dguv.de/bgia/
de/pub/rep/pdf/rep05/biar0706/Report7_2006.pdf, HVBG
(Hrsg.), Report 7, November 2005
[BGIA08]
BGIA Institut für Arbeitsschutz der Deutschen
Gesetzlichen Unfallversicherung: Funktionale Sicherheit
von Maschinensteuerung. http://www.dguv.de/bgia/de/pub/
rep/pdf/rep07/biar0208/rep2_08.pdf, DGUV (Hrsg.), Report
2, Februar 2008
[DIN07]
DIN Deutsches Institut für Normung e. V.: Sicherheit
von Maschinen - Sicherheitsbezogene Teile von Steuerungen - Teil
1: Allgemeine Geltungsleitsätze. Beuth Verlag GmbH, Berlin 2007
[Fis92]
Fischer, P.; Balzer G.; Lutz, M.: EMV - Störfestigkeitsprüfungen. Franzis-Verlag GmbH & Co. KG, München 1992
[Goed97]
Goedbloed, J. J.: EMV - Elektromagnetische Verträglichkeit.
Pflaum Verlag GmbH, München et. al. 1997
[Klug97]
Klug, J.; Schaefer, M.: Sicherheitstechnisches Informationsund Arbeitsblatt 330 225, 29. Lfg. VII/97, 9 S., 14 Lit., Abb. In:
BGIA-Handbuch Sicherheit und Gesundheitsschutz am Arbeitsplatz. Hrsg.: Berufsgenossenschaftliches Institut für Arbeitsschutz
- BGIA. 2. Auflage. Erich Schmidt Verlag, Berlin 2003 - LoseblattAusgabe.
[Krue08]
Krüger, M.: Grundlagen der Kraftfahrzeugelektronik. Schaltungstechnik. 2. neu bearbeitete Auflage, Carl Hanser Verlag,
München 2008
[Pard05]
Pardue, J.: C Programming for Microcontrollers. Smiley Micros,
Knoxville (USA) 2005
[Rei99]
Reinert, D.; Meffert, K.: Mikroprozessoren in sicherheitskritischen Anwendungen. Teil 1: Elektronik 48 (1999) Nr. 4, S. 56-63;
Teil 2: Elektronik 48 (1999) Nr. 6, S. 48-52
[Rei01]
Reinert, D.; Schaefer, M.: Sichere Bussysteme für die Automation, Hüthig GmbH & Co. KG, Heidelberg 2001
Seite 74
[Schae08]
Schäffer, F.: Hardware und C-Programmierung in der Praxis.
elektor-Verlag, Aachen 2008
[Schwa96]
Schwab, A. J.: Elektromagnetische Verträglichkeit. 4. neu bearbeitete Auflage, Springer Verlag, Berlin et. al. 1996
Datenblätter
[ATM03]
ATMEL: Buttefly Board Datasheet. http://atmel.com/dyn/
resources/prod_documents/doc4249.pdf, Stand: Februar 2009
[ATM08a]
ATMEL: ATMega169P(V) Datasheet. http://www.atmel.com/
dyn/resources/prod_documents/doc8018.pdf, Stand: Dezember 2008
[STM]
STMicroelectronics: LFxxC Datasheet. http://www.st.
com/stonline/products/literature/ds/2574/lf33c.pdf,
Stand: Februar 2009
Onlineliteratur
[@ATM08b]
ATMEL:
PicoPower-Technology.
http://www.atmel.com/
products/AVR/default_picopower.asp, Stand: März 2008
[@Ecr09]
Ecros Technology: AVR Buttefly Carrier. http://www.
ecrostech.com/AtmelAvr/Butterfly/index.htm, Stand: März
2009
[@WinAVR]
WinAVR. http://winavr.sourceforge.net/, Stand: März
2009
A Quellcode
Seite 75
A Quellcode
A.1 Quellcode Main-App.c
1 #i n c l u d e ”Main−App . h”
2 #i n c l u d e ” Te stLib . h”
3
4
/∗ −−− Main−App v1 . 1 −− ∗/
5
/∗ Autor : Maxim Küpper
∗/
6
7
v o l a t i l e int iProgStatus = 0;
// 0 = Programm noch n i c h t
gestartet
8
// 1 = Programm g e s t a r t e t , l ä u f t
9
// −−−−−−−−−−−−−−−− WICHTIG:
−−−−−−−−−−−−−−−−−−−−−−−−−
10
// v o l a t i l e , s o n s t ä n d e r t s i c h
p r o g s t a t u s n i c h t i n d e r ISR !
11
12
char cStatus = 0 ;
// c S t a t u s b e i n h a l t e t den
a k t u e l l e n S t a t u s d e s Programmes
13
14
// wird z u r S y n c h r o n i s a t i o n b e n ö t i g t
i n t iMaxStat = 2 5 5 ;
// Maximaler S t a t u s , da 8
m ö g l i c h e z u s t ä n d e d e r LEDS
15
16
17
i n t iDelayMs = 10∗DELAY;
// W a r t e z e i t z u r
S y n c h r o n i s a t i o n i n ms ( n i c h t 100% genau ,
18
// da T a k t f r e q u e n z s t a t t durch 1000 ( a u f
kHz ) durch 1024 g e t e i l t wurde )
19
// Maximum
: ˜30ms
20
21
i n t iMaxTimeMs = 20∗DELAY;
// Maximale Z e i t e i n e s
S c h l e i f e n d u r c h l a u f s d e s Hauptprogramms
22
// Angabe i n ms
23
// Maximum
: ˜30ms
24
25
Seite 76
i n t iDebugFlag = 0 ;
// 1
:
Programm s t a r t e t
automatisch
26
// 0
: Programm w a r t e t a u f S t a r t s i g n a l
27
// S t a r t s i g n a l
: S t a r t k n o p f od .
externes Startsignal
28
// Für S i m u l a t o r 1 e i n s e t z e n , dann wird
außerdem das Delay d e k a t i v i e r t !
// −−−−−−−−−−−−−−−− WICHTIG:
29
−−−−−−−−−−−−−−−−−−−−−−−−−
// IM DEBUG−MODUS WERDEN DIE
30
SYNCHRONISATION
31
// UND DIE SELBSTTESTS DEAKTIVIERT !
32
33
int iTestFlag = 1;
// 1
: S e l b s t t e s t s werden
d u r c h g e f ü h r t
34
// 0
: keine S e l b s t t e s t s
35
36
i n t iSyncFlag = 1;
// Flag ob S y n c h r o n i s a t i o n
d u r c h g e f ü h r t werden s o l l
37
// 0
:
deaktiviert
38
// 1
:
aktiviert
39
40
i n t iSyncMod = 1 0 ;
// Anzahl d e r S c h r i t t e nach
w e l c h e r d i e S y n c h r o n i s a t i o n d u r c h g e f ü h r t wird
41
// Minimum
: 1
42
// Maximum
: iMaxStat
43
44
i n t iOn = 0xFF ;
// a l l e Lampen an / Port a l s
Ausgang d e k l a r i e r e n
45
i n t i O f f = 0 x00 ;
// a l l e Lampen aus
/ Port a l s
Eingang d e k l a r i e r e n
46
47
48
i n t i S e c u r e P o r t D = ˜0 x80 ;
49
50
i n t iWDStatusFlag ;
// S t a t u s d e s Watchdog−T e s t s
51
52
char cReceived ;
53
54
i n t i S p e i c h e r 1 = 0 x00 ;
// S p e i c h e r z e l l e 1
deklarieren
55
i n t i S p e i c h e r 2 = 0 x01 ;
Seite 77
// S p e i c h e r z e l l e 2
deklarieren
56
57
58
59
/∗ −−− Hauptmethode −−− ∗/
60
i n t main ( v o i d )
61
{
62
iWDStatusFlag = eepromRead ( iWDSpeicher ) ;
63
64
// Watchdog−Routine , wenn Watchdog e i n e n S y s t e m r e s e t
d u r c h g e f ü h r t hat
65
i f ( (MCUSR & ( 1 << WDRF) ) ) {
66
MCUSR = 0 ;
67
wdt disable () ;
68
i f ( iWDStatusFlag < 1 | | iWDStatusFlag > 4 ) {
69
wdError ( ) ;
70
}
71
// Wenn Timer0Test zu einem Reset g e f ü h r t hat , Wird das
h i e r abgefangen
e l s e i f ( iWDStatusFlag == 2 ) {
72
73
iTestStat = 54;
74
testError () ;
75
}
76
77
iTestStat = 55;
78
testError () ;
79
}
80
81
iTestStat = 56;
82
testError () ;
}
83
84
}
85
86
// Wenn T e s t s a k t i v i e r t s i n d
87
i f ( iTestFlag ){
88
// Ruft den Watchdog−Test a u f wenn e r noch n i c h t
a u f g e r u f e n wurde
89
i f ( iWDStatusFlag != 1 ) {
90
91
startTest (99) ;
}
Seite 78
92
// s o n s t l ö s c h e Watchdog−Flag
93
else {
94
eepromWrite ( iWDSpeicher , 0 ) ;
}
95
96
97
// S t a r t e t d i e Timer−T e s t s
98
startTest (96) ;
// Timer 0
99
startTest (97) ;
// Timer 1
100
startTest (98) ;
// Timer 2
101
// Löscht das T e s t S t a t −Flag f ü r A u s g a n g s s i t u a t i o n beim
102
Programmstart
103
104
iTestStat = 0;
}
105
106
// Ruft d i e Methode zum Programmstart a u f
107
programmInit ( ) ;
108
109
// Pr üfen ob Debugmodus a k t i v i e r t , wenn n e i n
S y n c h r o n i s a t i o n s t a r t e n und T e s t s d u r c h f ü h r e n
110
i f ( ! iDebugFlag ) {
111
// F a l l s T e s t s gew ünscht werden
112
i f ( iTestFlag ){
113
// Beim S t a r t e i n m a l i g a l l e S e l b s t t e s t s d u r c h f ü h r e n
114
initTest () ;
115
}
116
// S t a t u s −LEDs s e t z e n , jenachdem ob S y n c h r o n i s a t i o n
erw ünscht o d e r n i c h t
117
i f ( iSyncFlag ) {
118
PORTD = iOn ;
119
}
120
e l s e i f ( ! iSyncFlag ) {
121
PORTD = 0 x33 ;
}
122
123
}
124
125
// S c h l e i f e vor dem e i g e n t l i c h e n Programmstart .
126
// F ührt S e l b s t t e s t s d e r Reihe nach aus .
127
// Wartet a u f e x t e r n e s S i g n a l ( Button−Aktion o d e r S t a r t −
Signal )
128
w h i l e ( i P r o g S t a t u s != 1 ) {
129
doTest ( ) ;
Seite 79
// Routine z u r Testauswahl
aufrufen
130
wdt reset () ;
// Watchdog zur ück s e t z e n
131
i f ( (UCSRA & (1<<RXC) ) && i S y n c F l a g ) {
// P r ü f t ob
externes Signal vorliegt
i f (UDR == ’ x ’ ) {
132
// Im F a l l e das e x t e r n e s
Signal ein x i s t . .
133
programmStart ( ) ;
// . . f ü h r e Programmstart
aus
}
134
}
135
136
}
137
138
139
// −−− UNSICHERER ZUSTAND −−−
140
// −− s o l a n g e Programm n i c h t i n F e h l e r r o u t i n e g e h t b e f i n d e t
e s s i c h im u n s i c h e r e n Zustand −−
141
142
/∗
143
PORTD = i O f f ;
144
∗/
145
DDRD = iOn ;
146
PORTD = ˜ i S e c u r e P o r t D ;
147
DDRB = iOn ;
// PortB a l s Ausgang s c h a l t e n
148
PORTB = i O f f ;
// I n i t i a l w e r t dem PortB
zuweisen
149
150
151
// Timer f ü r d i e E c h t z e i t −Überwachung
152
OCR0A = iMaxTimeMs ;
// Lädt das
Vergleichsregister
153
TCCR0A = (1<<CS00 ) |(1<<CS02 ) |(1<<WGM01) ;
// I n i t i a l i s i e r t
den Timer und s t a r t e t i h n
154
155
// Hauptprogamm−E n d l o s s c h l e i f e
156
// wird nur durch e i n e n F e h l e r f a l l v e r l a s s e n
157
while (1) {
158
159
TCNT0 = 0 ;
// S e t z t den Timer a u f 0
zur ück
160
Seite 80
// . . Wenn ja , S t a t u s zur ück a u f 0
setzen
161
162
i f ( c S t a t u s < iMaxStat )
// P r ü f t ob d e r S t a t u s
den h ö c h s t e n Wert e r r e i c h t hat . .
163
c S t a t u s ++;
// . . wenn nein , S t a t u s
inkrementieren
164
else
165
cStatus = 0;
166
167
PORTB = c S t a t u s ;
// S t a t u s über d i e LEDs
ausgeben .
168
i f ( i S y n c F l a g & ( c S t a t u s % iSyncMod == 0 ) ) {
169
// F a l l s
Syncronisationsflag gesetzt . .
170
doSync ( ) ;
// . . S y c h r o n i s a t i o n a u s f ü h r e n
}
171
172
173
// f ü r den Debug−Modus d i e T e s t s d e a k t i v i e r e n
174
i f ( iTestFlag ){
175
doTest ( ) ;
// S e l b s t t e s t −Auswahl a u f r u f e n
}
176
177
178
wdt reset () ;
}
179
180
// Watchdog zur ück s e t z e n
}
181
182
183
184
/∗ −−−− A u f r u f d e r I n i t i a l i s i e r u n g −−− ∗/
185
v o i d programmInit ( v o i d ) {
186
// Wennn A u t o s t a r t a k t i v i e r t i s t , s e t z e P r o g s t a t u s a u f 1
zum S t a r t e n d e s Programmes
187
i f ( iDebugFlag ) {
188
iProgStatus = 1;
189
iSyncFlag = 0;
190
iTestFlag = 0;
191
}
192
193
eepromOverwrite ( ) ;
194
Seite 81
195
// Ruft d i e I n i t i a l i s i e r u n g s m e t h o d e a u f
196
i n i t i a l i z e r () ;
197
198
// I n i t i a l i s i e r t den Watchdog und s t e l l t i h n a u f den
gew ünschten Wert
199
// WDTO 60MS e n t s p r i c h t 60mS
200
// WDTO 30MS e n t s p r i c h t 30mS
201
// WDTO 1S e n t s p r i c h t 1S
202
203
}
204
205
/∗ −−− Routine zum Programmstart −−− ∗/
206
v o i d programmStart ( v o i d ) {
207
iProgStatus = 1;
// Programmstatus−V a r i a b l e
auf 1 s t e l l e n
208
PCMSK1 = ˜PINB MASK ;
// Pin−Change−I n t e r r u p t
deaktivieren
209
210
EIMSK = (0<<7) ;
}
211
212
213
214
/∗ −−− g l o b a l e I n i t i a l i s i e r u n g −−− ∗/
215
void i n i t i a l i z e r ( )
216
{
217
// I n i t USART
218
USARTinit ( ) ;
219
220
TIMSK0 = (1<<OCIE0A) ;
// Timer−I n t e r r u p t s
aktivieren
221
TIMSK2 = (1<<OCIE2A) ;
222
223
224
i f ( ! iDebugFlag ) {
// PortB−Pin 4 a l s Eingang s c h a l t e n & P u l l −Up
Widerstände s c h a l t e n
225
DDRB = i O f f ;
226
PORTB = 0 x10 ;
227
228
/∗
229
// PortD−Pin a l s Ausgang f ü r d i e Fehlermeldung s c h a l t e n
230
DDRD = iOn ;
231
PORTD = i O f f ;
232
∗/
233
234
PORTD = i S e c u r e P o r t D ;
Seite 82
235
236
// Pin−Change−I n t e r r u p t f ü r PortB s c h a l t e n
237
PCMSK1 = PINB MASK ;
238
EIMSK = (1<<7) ;
}
239
240
}
241
242
/∗ −−− Taster −I n t e r r u p t −Routine −−−−−− ∗/
243 SIGNAL( PCINT1 vect )
244
{
245
246
PinChangeInterrupt ( ) ;
}
247
248
249
/∗ −−− Ausf ührende Routine d e r Taster −ISR −−− ∗/
250
void PinChangeInterrupt ( void )
251
{
252
char cbuttons ;
253
254
c b u t t o n s = ( ˜PINB) & PINB MASK ;
255
256
// Output v i r t u a l k e y s
257
i f ( c b u t t o n s & (1<<BUTTON O) ) {
// Ü be rpr üfe ob
g e d r ü c k t e Taste = T a s t e r war
258
programmStart ( ) ;
// wenn ja , programmstart
a u s f ü h r e n
i f ( iSyncFlag ) {
259
// und f a l l s gew ünscht dem
anderen System das S t a r t z e i c h e n senden
260
sendChar ( ’ x ’ ) ;
}
261
}
262
263
264
EIFR = (0<<PCIF1 ) ;
// Lösche Pinchange−
I n t e r r u p t −Flag
265
}
266
267
268
/∗ −−− Daten senden −−− ∗/
269
v o i d sendChar ( c h a r data )
270
{
271
Seite 83
// Darauf warten , d a s s das S e n d e r e g i s t e r l e e r wird und
b e r e i t f ü r neue Daten zum Senden i s t .
272
w h i l e ( ! ( UCSRA & (1<<UDRE) ) ) ;
273
274
// Daten i n s S e n d e r e g i s t e r s c h i e b e n
275
UDR = data ;
276
277
// Warte darauf , d a s s Daten g e s e n d e t werden
278
w h i l e ( ! ( UCSRA & (1<<TXC) ) ) ;
279
}
280
281
282
/∗ −−− S e r i e l l e S c h n i t t s t e l l e i n i t i a l i s i e r e n −−− ∗/
283
v o i d USARTinit ( )
284
{
285
286
// S e r i e l l e S c h n i t t s t e l l e a l s Sender und Empfänger
initialisieren
UCSRB = (1<<RXEN) |(1<<TXEN) |(0<<RXCIE) |(0<<UDRIE) ;
287
288
289
// Asynchroner Modus mit 8 B i t s , k e i n e P a r i t y und einem
Stop−B i t e i n s t e l l e n
UCSRC = (0<<UMSEL) |(0<<UPM0) |(0<<USBS) |(3<<UCSZ0) |(0<<
290
UCPOL) ;
291
292
// Baudratenwert ( Berechnung s i e h e Header ) dem R e g i s t e r
zuweisen
293
UBRRH = ( u n s i g n e d l o n g )UBRR VAL>>8;
294
UBRRL = ( u n s i g n e d l o n g )UBRR VAL;
295
296
297
// Enable i n t e r r u p t s
298
sei () ;
299
}
300
301
302
/∗ −−− F e h l e r r o u t i n e f ü r unbekannte F e h l e r −−− ∗/
303
void stdError ( ) {
304
c l i () ;
Seite 84
// I n t e r r u p t −Behandlungen
deaktivieren
305
wdt disable () ;
// Watchdog d e a k t i v i e r e n
306
307
308
DDRB = iOn ;
309
//DDRD = iOn ;
310
// P o r t s a l s Ausgang s c h a l t e n
311
312
PORTB = i O f f ;
313
314
// F e h l e r w e r t i n s
Eeprom s c h r e i b e n
315
while (1) {
316
317
// F e h l e r c o d e an PortD ausgeben . F e h l e r c o d e l a u t T a b e l l e
318
PORTD = ( 0xAA & i S e c u r e P o r t D ) ;
319
320
321
322
323
324
325
326
327
}
328
329
}
330
331
/∗ −−− F e h l e r r o u t i n e f ü r S y n c h r o n i s a t i o n s f e h l e r −−− ∗/
332
void syncError ( ) {
333
c l i () ;
deaktivieren
334
wdt disable () ;
335
336
337
eepromWrite ( i S p e i c h e r 2 , c S t a t u s ) ;
338
339
DDRB = iOn ;
340
//DDRD = iOn ;
341
Seite 85
342
343
344
while (1) {
345
346
347
348
349
350
351
352
353
354
355
356
}
357
358
}
359
360
/∗ −−− F e h l e r r o u t i n e f ü r Watchdog−Reset −−− ∗/
361
v o i d wdError ( ) {
362
c l i () ;
deaktivieren
363
wdt disable () ;
364
365
366
367
DDRB = iOn ;
368
//DDRD = iOn ;
369
370
371
PORTB = i S e c u r e P o r t D ;
372
373
while (1) {
374
375
376
377
378
379
380
381
382
383
384
}
385
386
Seite 86
}
387
388
/∗ −−− F e h l e r r o u t i n e f ü r S e l b s t t e s t f e h l e r −−− ∗/
389
void t e s t E r r o r ( ) {
390
c l i () ;
deaktivieren
391
wdt disable () ;
392
393
// I n i t i a l i s i e r e d i e P o r t s a l s Ausgang und gebe
Fehlermeldung und a k t u e l l e S e l b s t t e s t n r . aus
394
395
DDRB = 0xFF ;
396
PORTB = i T e s t S t a t ;
397
398
399
eepromWrite ( i S p e i c h e r 2 , i T e s t S t a t ) ;
400
while (1) {
401
402
// S e t z t d i e LEDs an PORTD a u f den F e h l e r c o d e −Anzeige
403
404
405
406
407
408
409
410
411
412
}
413
414
}
415
416
/∗ −−− F e h l e r r o u t i n e f ü r den F a l l e i n e s A u s f a l l s d e s anderen
Systems −−− ∗/
417
Seite 87
void ausfError ( ) {
418
c l i () ;
deaktivieren
419
wdt disable () ;
420
421
422
eepromWrite ( i S p e i c h e r 2 , c S t a t u s ) ;
423
424
DDRB = iOn ;
425
//DDRD = iOn ;
426
427
428
429
while (1) {
430
431
432
PORTD = ( iOn & i S e c u r e P o r t D ) ;
433
434
435
436
437
438
439
440
441
}
442
443
}
444
445
/∗ −−− F e h l e r r o u t i n e f ü r den Ablauf d e s Timers d e r
H a u p t s c h l e i f e −−− ∗/
446
447
void z e i t E r r o r ( ) {
c l i () ;
deaktivieren
448
wdt disable () ;
449
450
451
DDRB = iOn ;
452
//DDRD = iOn ;
453
Seite 88
454
while (1) {
455
456
457
PORTD = ( iOn & i S e c u r e P o r t D ) ;
458
PORTB = iOn ;
459
460
461
462
463
464
PORTB = i O f f ;
465
466
467
468
}
469
470
}
471
472
473
/∗ −−−− S e l b s t t e s t −A u f r u f −−− ∗/
474
v o i d doTest ( ) {
475
selectTest () ;
// Methode z u r Testauswahl
aufrufen
476
477
i f ( iTestStat > iTestAnzahl )
// Z ä h l e r erhöhen
// Wenn Z ä h l e r g r ö ß e r
a l s Testanzahl . .
478
479
iTestStat = 0;
// . . Z ä h l e r zur ück s e t z e n
}
480
481
/∗ −−− S y n c h r o n i s a t i o n s r o u t i n e −−− ∗/
482
/∗ −−− empfängt und s e n d e t a k t u e l l e n S t a t u s −−− ∗/
483
v o i d doSync ( ) {
484
485
// a k t u e l l e n S t a t u s senden
486
i f ( c S t a t u s <= iMaxStat ) {
487
sendChar ( c S t a t u s ) ;
488
}
489
else
490
stdError () ;
491
492
// Watchdog
Seite 89
zur ück s e t z e n um k e i n e n Alarm beim Warten a u f
S t a t u s a n t w o r t zu s c h l a g e n
493
wdt reset () ;
494
495
496
497
TCNT2 = 0 ;
498
OCR2A = iDelayMs ;
// Lädt das
Vergleichsregister
499
TCCR2A = (1<<CS20 ) |(1<<CS21 ) |(1<<CS22
500
) |(1<<WGM21) ; // I n i t i a l i s i e r t den Timer und s t a r t e t i h n
501
502
// S c h l e i f e z u r ü b e r p r ü f u n g ob S y n c h r o n i s a t i o n
s t a t t g e f u n d e n hat
503
w h i l e ( ! ( UCSRA & (1<<RXC) ) ) ;
// P r ü f e ob
Daten empfangen wurden
504
505
c R e c e i v e d = UDR;
506
i f ( c R e c e i v e d != c S t a t u s ) {
507
// Wenn Daten
empfangen mit a k t u e l l e m S t a t u s v e r g l e i c h e n
508
syncError () ;
// Bei u n g l e i c h h e i t
S y c h r o n i t ä t s v e r l u s t melden
}
509
510
TCCR2A &= ˜((1<<CS20 ) |(1<<CS21 ) |(1<<CS22 ) ) ;
511
anhalten
512
}
513
514
/∗ −−− Timer0−I n t e r r u p t −Routine −−− ∗/
515 SIGNAL( TIMER0 COMP vect )
516
{
517
TCCR0A &= ˜((1<<CS00 ) |(1<<CS02 ) ) ;
518
zeitError () ;
519
}
520
521
/∗ −−− Timer2−I n t e r r u p t −Routine −−− ∗/
522 SIGNAL( TIMER2 COMP vect )
523
{
524
TCCR2A &= ˜((1<<CS20 ) |(1<<CS21 ) |(1<<CS22 ) ) ;
525
ausfError () ;
// Timer
526
Seite 90
}
527
528
/∗ −−− Funktion um i n s EEEPROM zu s c h r e i b e n −−− ∗/
529
530
v o i d eepromWrite ( i n t i S p e i c h e r , i n t i E r r o r ) {
eeprom write byte ( ( u i n t 8 t ∗) iSpeicher , i E r r o r ) ;
531
532
}
533
534
/∗ −−− Ü b e r s c h r e i b t d i e S p e i c h e r z e l l e n im EEPROM mit 0 −−−
∗/
535
/∗ −−− f a l l s d i e s e n i c h t schon 0 s i n d . −−− ∗/
536
v o i d eepromOverwrite ( ) {
i f ( eepromRead ( i S p e i c h e r 1 ) != 0 ) {
537
538
}
539
540
i f ( eepromRead ( i S p e i c h e r 2 ) != 0 ) {
541
542
}
543
544
}
545
546
/∗ −−− Funktion um aus dem EEPROM zu l e s e n −−− ∗/
547
i n t eepromRead ( i n t i S p e i c h e r ) {
return eeprom read byte ( ( u i n t 8 t ∗) i S p e i c h e r ) ;
548
549
}
A.2 Quellcode Main-App.h
Seite 91
1 #i n c l u d e <avr / i o . h>
2 #i n c l u d e <avr / i n t e r r u p t . h>
3 #i n c l u d e < s t d l i b . h>
4 #i n c l u d e <avr / s i g n a l . h>
5 #i n c l u d e <s t d i o . h>
6 #i n c l u d e <avr /wdt . h>
7 #i n c l u d e <avr / d e l a y . h>
8 #i n c l u d e <avr / eeprom . h>
9
10 #i f n d e f EEMEM
11
// a l l e T e x t s t e l l e n EEMEM im Q u e l l c o d e durch
attribute
. . . ersetzen
12 #d e f i n e EEMEM
attribute
( ( s e c t i o n ( ” . eeprom ” ) ) )
13 #e n d i f
14
15
16 #d e f i n e BUTTON O
4
// Wenn Center g e d r ü c k t wird
, wird PortB Pin4 g e s e t z t
17
18 #d e f i n e PINB MASK (1<<PINB4 )
19
20 #d e f i n e FOSC 8000000UL
21 #d e f i n e BAUD 38400UL
// T a k t f r e q u e n z i n Hz
// Baud−Rate i n B i t s pro
Sekunde
22 #d e f i n e UBRR VAL FOSC/16/BAUD−1
// Berechnung d e s Wertes
f ü r das R e g i s t e r UBBR ( 1 6 Bit−R e g i s t e r )
23
24 #d e f i n e DELAY FOSC/1000/1024
// Umrechnungswert f ü r
Delayfunktion
25
26
27
void i n i t i a l i z e r ( void ) ;
28
v o i d USARTinit ( v o i d ) ;
29
char isCharAvailable ( void ) ;
30
char receiveChar ( void ) ;
31
v o i d sendChar ( c h a r ) ;
32
void sendString ( char ∗) ;
33
v o i d programmInit ( v o i d ) ;
34
v o i d programmStart ( v o i d ) ;
35
void statusSenden ( void ) ;
36
void parseInput ( char ∗) ;
37
void PinChangeInterrupt ( void ) ;
38
void stdError ( void ) ;
39
void syncError ( void ) ;
40
void ausfError ( void ) ;
41
void z e i t E r r o r ( void ) ;
42
void t e s t E r r o r ( void ) ;
43
v o i d wdError ( v o i d ) ;
44
v o i d doTest ( v o i d ) ;
45
v o i d doSync ( v o i d ) ;
46
v o i d getSync ( v o i d ) ;
47
v o i d eepromWrite ( i n t , i n t ) ;
48
v o i d eepromOverwrite ( v o i d ) ;
49
i n t eepromRead ( i n t ) ;
50
// v o i d CRCSet ( v o i d ) ;
Seite 92
A.3 Quellcode TestLib.c
Seite 93
1 #i n c l u d e ” Te stLib . h”
2 #i n c l u d e ”Main−App . h”
3
4
// 0 − 31
5
// 32
6
// 33 − 38
: Arithmetische Tests
7
// 39 − 45
: Tests der l o g i s c h e n Bitoperationen
8
// 46 − 48
: T e s t s d e r l o g i s c h e n O pe ra t io ne n
9
// 49 − 52
: T e s t s d e r T r a n s f e r −B e f e h l e
10
// 53
:
RAM−Test
11
// 54
: Flash−Test
12
// 55
: Port−Test
13
// 96 − 98
14
// 99
: Registertests
: Push−Pop−Return−Jump−Test
: Timer−T e s t s
: Watchdog−Test
15
16
i n t iTestAnzahl = 54;
// Die Anzahl d e r z y k l i s c h zu
durchlaufenden Tests
17
int iTestStat = 0;
// Der a k t u e l l a u s g e w ä h l t e
selbsttest
18
19
i n t iWDSpeicher = 0 x02 ;
20
21
22
// V a r i a b l e b e i n h a l t e t d i e e r s t e zu t e s t e n d e Ramzelle
23
u n s i g n e d c h a r ∗ c E r s t e R a m Z e l l e = ( u n s i g n e d c h a r ∗ ) 0 x0100 ;
24
// Anzahl d e r zu t e s t e n d e n Ramzellen pro Z yk l us
25
u n s i g n e d i n t iRamTestLaenge = 1 0 ;
26
// Anfang und Ende vom Ram
27
u n s i g n e d c h a r ∗RamA = ( u n s i g n e d c h a r ∗ ) 0 x0100 ;
28
u n s i g n e d c h a r ∗RamE = ( u n s i g n e d c h a r ∗ ) 0x04FF ;
29
30
31
// Z e i g e r a u f a k t u e l l e P o s i t i o n d e s F l a s h s p e i c h e r s
32
u n s i g n e d c h a r ∗ c F l a s h Z e i g e r = ( u n s i g n e d c h a r ∗ ) 0 x0000 ;
33
// Anzahl d e r zu t e s t e n d e n F l a s h z e l l e n pro Z yk l us
34
unsigned i n t iFlashTestLaenge = 10;
35
// a k t u e l l e r CRC−Wert
36
u n s i g n e d i n t iCRC ;
37
// e r w a r t e t e r CRC−Wert
Seite 94
38
u n s i g n e d i n t iCRCCheck ;
39
// Anfang und Ende d e r CRC−Berechnung d e s Flash−S p e i c h e r s
40
u n s i g n e d c h a r ∗ FlashA = ( u n s i g n e d c h a r ∗ ) 0 x0000 ;
41
u n s i g n e d c h a r ∗ FlashE = ( u n s i g n e d c h a r ∗ ) 0x3FFC ;
42
43
44
void s e l e c t T e s t ( ) {
45
46
startTest ( iTestStat ) ;
}
47
48
// f ü h r t den Gewählten Test aus !
49
void s t a r t T e s t ( i n t iTestNr ) {
50
iTestStat = iTestNr ;
51
switch ( iTestNr ) {
52
53
// R e g i s t e r t e s t s
54
c a s e 0 : TEST R0 ( ) ; break ;
55
56
57
58
59
60
61
62
63
64
c a s e 1 0 : TEST R10 ( ) ; break ;
65
c a s e 1 1 : TEST R11 ( ) ; break ;
66
c a s e 1 2 : TEST R12 ( ) ; break ;
67
c a s e 1 3 : TEST R13 ( ) ; break ;
68
c a s e 1 4 : TEST R14 ( ) ; break ;
69
c a s e 1 5 : TEST R15 ( ) ; break ;
70
c a s e 1 6 : TEST R16 ( ) ; break ;
71
c a s e 1 7 : TEST R17 ( ) ; break ;
72
c a s e 1 8 : TEST R18 ( ) ; break ;
73
c a s e 1 9 : TEST R19 ( ) ; break ;
74
c a s e 2 0 : TEST R20 ( ) ; break ;
75
c a s e 2 1 : TEST R21 ( ) ; break ;
76
c a s e 2 2 : TEST R22 ( ) ; break ;
77
c a s e 2 3 : TEST R23 ( ) ; break ;
78
c a s e 2 4 : TEST R24 ( ) ; break ;
79
c a s e 2 5 : TEST R25 ( ) ; break ;
80
c a s e 2 6 : TEST R26 ( ) ; break ;
81
c a s e 2 7 : TEST R27 ( ) ; break ;
82
c a s e 2 8 : TEST R28 ( ) ; break ;
83
c a s e 2 9 : TEST R29 ( ) ; break ;
84
c a s e 3 0 : TEST R30 ( ) ; break ;
85
c a s e 3 1 : TEST R31 ( ) ; break ;
86
87
// Push−Pop−Ret−Test
88
c a s e 3 2 : PPRJ TEST ( ) ; break ;
89
90
// A r i t h m e t i s c h e T e s t s
91
c a s e 3 3 : ADD TEST( ) ; break ;
92
c a s e 3 4 : ADDC TEST( ) ; break ;
93
c a s e 3 5 : SUB TEST ( ) ; break ;
94
c a s e 3 6 : INC TEST ( ) ; break ;
95
c a s e 3 7 : DEC TEST( ) ; break ;
96
c a s e 3 8 : MUL TEST( ) ; break ;
97
98
// T e s t s d e r l o g i s c h e n B i t o p e r a t i o n e n
99
c a s e 3 9 : CLR TEST ( ) ; break ;
100
c a s e 4 0 : COM TEST( ) ; break ;
101
c a s e 4 1 : LSL TEST ( ) ; break ;
102
c a s e 4 2 : LSR TEST ( ) ; break ;
103
c a s e 4 3 : ROL TEST( ) ; break ;
104
c a s e 4 4 : ROR TEST( ) ; break ;
105
c a s e 4 5 : SWAP TEST( ) ; break ;
106
107
// T e s t s d e r l o g i s c h e n Op e ra t io ne n
108
c a s e 4 6 : AND TEST( ) ; break ;
109
c a s e 4 7 : OR TEST( ) ; break ;
110
c a s e 4 8 : EOR TEST( ) ; break ;
111
112
// T e s t s d e r T r a n s f e r −B e f e h l e
113
c a s e 4 9 : m o v t e s t ( ) ; break ;
114
c a s e 5 0 : movw test ( ) ; break ;
115
c a s e 5 1 : l d i t e s t ( ) ; break ;
116
c a s e 5 2 : l d t e s t ( ) ; break ;
117
118
// Test d e s Rams
119
c a s e 5 3 : Ram Test ( ) ; break ;
Seite 95
Seite 96
120
121
// Test d e s Flashroms
122
c a s e 5 4 : F l a s h T e s t ( ) ; break ;
123
124
// Port−Test
125
c a s e 5 5 : PortTest ( ) ; break ;
126
127
// T e s t s d e r Timer
128
c a s e 9 6 : Timer0Test ( ) ; break ;
129
130
131
132
// Watchdog−Test
133
c a s e 9 9 : WDTest ( ) ; break ;
134
135
// S o n s t i g e s
136
d e f a u l t : s t d E r r o r ( ) ; break ;
}
137
138
}
139
140
// f ü h r t a l l e vorhanden S e l f T e s t s aus
141
// Bsp . f ü r S t a r t ü b e r p r ü f u n g !
142
void i n i t T e s t ( ) {
w h i l e ( i T e s t S t a t <= i T e s t A n z a h l ) {
143
144
selectTest () ;
145
146
}
147
iTestStat = 0;
148
}
149
150
151
// Methode um d i e P o r t s a u f k o r r e k t e Funktion zu ü b e r p r ü f e n
152
v o i d PortTes t ( ) {
153
u i n t 8 t iPruefVar = 0;
154
i n t iDDRB = DDRB;
// Pr üf−V a r i a b l e
// Wert d e r a l t e n Port−
Zustände s p e i c h e r n
155
i n t iDDRD = DDRD;
156
i n t iPortB = PORTB;
157
i n t iPortD = PORTD;
158
159
DDRB = 0 x00 ;
// PortB a l s Eingang
160
DDRD = 0xFF ;
Seite 97
// PortD a l s Ausgang
161
162
163
i P r u e f V a r = ˜0 x01 ;
164
165
f o r ( i n t i =0; i <=7; i ++){
166
// V e r g l e i c h e n von PortB
und p r u e f V ar und f a l l s n ö t i g ,
167
testError () ;
168
i P r u e f V a r = ( i Prue fVar <<1) | 0 x01 ;
169
}
170
171
172
173
/∗
174
i P r u e f V a r = 0 x01 ;
175
176
f o r ( i n t i =0; i <=7; i ++){
177
// V e r g l e i c h e n von PortB
und p r u e f V ar und f a l l s n ö t i g ,
178
testError () ;
179
i P r u e f V a r = ( i P r u e f V a r << 1 ) ;
180
181
}
182
∗/
183
184
// a l t e Zustände zur ück s e t z e n
185
DDRB = iDDRB ;
186
PORTB = iPortB ;
187
188
DDRD = iDDRD ;
189
PORTD = iPortD ;
190
191
}
192
193
// Routine f ü r den e i n f a c h e r e n RAM−Test
194
v o i d Ram Test ( ) {
195
i f ( ( c E r s t e R a m Z e l l e + iRamTestLaenge ) > RamE) {
// Pr üfen
ob Prüfrahmen über Ramende h i n a u s
196
u n s i g n e d i n t iRamTestLaengeTemp = ( c E r s t e R a m Z e l l e +
iRamTestLaenge ) − RamE;
197
Ram Check ( cErsteRamZelle , RamE) ;
Seite 98
// Wenn ja , b i s
zum Ende p r ü f e n und
198
// P o i n t e r a u f Anfang
setzten
199
iRamTestLaengeTemp ) ) ;
200
}
201
else
202
// Ram Test d u r c h f ü h r e n .
203
iRamTestLaenge ) ) ;
204
205
// Ramzelle a u f n ä c h s t e Z e l l e s e t z e n ( f a l l s Ramende , dann
a u f Ramanfang )
206
cErsteRamZelle = cErsteRamZelle + 1 ;
207
i f ( c E r s t e R a m Z e l l e > RamE)
208
209
210
}
211
212
// e i g e n t l i c h e r Ram Test
213
v o i d Ram Check ( u n s i g n e d c h a r ∗ cStartAddr , u n s i g n e d c h a r ∗
cEndAddr )
214
{
215
unsigned char cOriginalByte ;
216
v o l a t i l e u n s i g n e d c h a r ∗ cTestAddr ;
217
218
f o r ( cTestAddr = cStartAddr ; cTestAddr < cEndAddr ;
cTestAddr++ ) {
c O r i g i n a l B y t e = ∗ cTestAddr ;
219
220
221
∗ cTestAddr = 0 x55 ;
222
i f ( ∗ cTestAddr != 0 x55 )
223
testError () ;
224
225
∗ cTestAddr = 0xAA ;
226
i f ( ∗ cTestAddr != 0xAA )
227
testError () ;
228
∗ cTestAddr = c O r i g i n a l B y t e ;
229
230
}
231
Seite 99
}
232
233
// Test d e s Flash−S p e i c h e r s
234
void Flash Test ( ) {
i f ( ( c F l a s h Z e i g e r + i F l a s h T e s t L a e n g e ) >= FlashE ) {
235
236
u n s i g n e d i n t iFlashTestLaengeTemp = ( c F l a s h Z e i g e r +
i F l a s h T e s t L a e n g e ) − FlashE ;
237
f o r ( i n t i = 0 ; i <= iFlashTestLaengeTemp ; i ++){
// i f ( ( i n t ) c F l a s h Z e i g e r != 0x041B | | ( i n t ) c F l a s h Z e i g e r
238
!= 0 x0428 )
239
iCRC
=
c r c c c i t t u p d a t e (iCRC , pgm read byte (
c F l a s h Z e i g e r++)) ;
240
// e l s e
241
// c F l a s h Z e i g e r ++;
242
}
243
// Pr üfen ob e r m i t t e l t e CRC mit e r w a r t e t e r Übereinstimmt
244
iCRCCheck = ( eepromReadFrom ( 8 ) <<8) | eepromReadFrom ( 9 ) ;
245
i f ( iCRCCheck != iCRC) {
246
// wenn n i c h t , F e h l e r r o u t i n e a u f r u f e n
247
testError () ;
248
}
249
// Z e i g e r a u f F l a s h a n f a n g zur ück s e t z t e n
250
c F l a s h Z e i g e r = FlashA ;
251
// a k t u e l l e CRC nach Pr üfen zur ück s e t z t e n
252
iCRC = 0 ;
253
}
254
else{
255
f o r ( i n t i = 0 ; i <= i F l a s h T e s t L a e n g e ; i ++){
// i f ( ( i n t ) c F l a s h Z e i g e r != 0x041B | | ( i n t ) c F l a s h Z e i g e r
256
!= 0 x0428 )
257
iCRC =
c r c c c i t t u p d a t e (iCRC , pgm read byte (
c F l a s h Z e i g e r++)) ;
258
// e l s e
259
// c F l a s h Z e i g e r ++;
}
260
}
261
262
263
}
264
265
266
// Watchdog−T e s t r o u t i n e
267
Seite 100
v o i d WDTest ( ) {
268
eepromWriteTo ( iWDSpeicher , 1 ) ;
// Watchdog−Test−
S t a t u s im EEPROM f e s t h a l t e n
269
270
271
272
273
274
// Watchdog a u f z i e h e n
// Warten
// Wenn e r h i e r n i c h t
zuschnappt i s t e r wohl d e f e k t
275
276
277
testError () ;
}
278
279
// Timer0−T e s t r o u t i n e
280
v o i d Timer0Test ( )
281
{
282
int iZeit [5] , i ;
283
284
OCR0A = 10∗DELAY;
// Lädt das
V e r g l e i c h s r e g i s t e r ( 1 5mS)
285
TCNT0 = 0 ;
286
TCCR0A = (1<<WGM01) ;
// I n i t i a l i s i e r t den
Timer
287
288
// eepromWriteTo ( iWDSpeicher , 2 ) ;
// Im EEPROM
f e s t h a l t e n , d a s s Timer0Test l ä u f t .
289
// w d t e n a b l e (WDTO 15MS) ;
// A k t i v i e r t den
Watchdog
290
291
f o r ( i = 0 ; i < 5 ; i ++)
292
{
TCCR0A = (1<<CS00 ) |(1<<CS02 ) ;
293
294
d e l a y l o o p 2 ( DelayMS ) ;
295
TCCR0A &= ˜((1<<CS00 ) |(1<<CS02 ) ) ;
296
i Z e i t [ i ] = TCNT0;
297
i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) )
// Timer s t a r t e n
// Timer l a u f e n l a s s e n
// Timer s t op pe n
// V e r g l e i c h e n mit
Erwartungshaltung
298
299
testError () ;
}
300
301
Seite 101
// w d t d i s a b l e ( ) ;
// D e a k t i v i e r t den
Watchdog
302
}
303
304
305
306
{
307
unsigned i n t i Z e i t [ 1 0 ] , i ;
308
309
OCR1A = 10∗DELAY;
// Lädt das
310
TCNT1 = 0 ;
311
TCCR1A = (1<<WGM11) ;
Timer
312
313
// Im EEPROM
314
Watchdog
315
316
f o r ( i = 0 ; i < 5 ; i ++)
317
{
TCCR1B = (1<<CS10 ) |(1<<CS12 ) ;
318
319
// Timer s t a r t e n
320
TCCR1B &= ˜((1<<CS10 ) |(1<<CS12 ) ) ;
321
322
i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) )
// Timer s t op pe n
Erwartungshaltung
323
testError () ;
}
324
325
326
// w d t d i s a b l e ( ) ;
Watchdog
327
}
328
329
330
331
{
332
int iZeit [5] , i ;
333
334
OCR2A = 10∗DELAY;
Seite 102
// Lädt das
335
TCNT2 = 0 ;
336
TCCR2A = (1<<WGM21) ;
Timer
337
338
// Im EEPROM
339
Watchdog
340
341
f o r ( i = 0 ; i < 5 ; i ++)
342
{
TCCR2A = (1<<CS20 ) |(1<<CS21 ) |(1<<CS22 ) ; // Timer s t a r t e n
343
344
TCCR2A &= ˜((1<<CS20 ) |(1<<CS21 ) |(1<<CS22 ) ) ;
345
// Timer
stoppen
346
347
i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) )
Erwartungshaltung
348
testError () ;
}
349
350
351
// w d t d i s a b l e ( ) ;
Watchdog
352
}
353
354
355
// Routine um i n den EEPROM zu s c h r e i b e n
356
v o i d eepromWriteTo ( i n t i S p e i c h e r , i n t i I n f o ) {
eeprom write byte ( ( u i n t 8 t ∗) iSpeicher , i I n f o ) ;
357
358
}
359
360
// Routine um aus dem EEPROM zu l e s e n
361
i n t eepromReadFrom ( i n t i S p e i c h e r ) {
return eeprom read byte ( ( u i n t 8 t ∗) i S p e i c h e r ) ;
362
363
}
A.4 Quellcode TestLib.h
Seite 103
1 #i n c l u d e <avr /wdt . h>
2 #i n c l u d e <avr / d e l a y . h>
3 #i n c l u d e <avr / eeprom . h>
4 #i n c l u d e <avr / c r c 1 6 . h>
5 #i n c l u d e <avr / pgmspace . h>
6
7 #d e f i n e FOSC 8000000UL
8 #d e f i n e DelayMS FOSC/4/1000
// T a k t f r e q u e n z i n Hz
// DelayMs e n t s p r i c h t 1mS
9 #d e f i n e DELAY FOSC/1000/1024
10
11
e x t e r n i n t iWDSpeicher ;
// S p e i c h e r z e l l e i n d e r d e r
S t a t u s d e s WD−T e s t s f e s t g e h a l t e n wird
12
13
14
// V a r i a b l e d e f i n i e r e n
15
extern int iTestStat ;
16
extern i n t iTestAnzahl ;
17
18
// Methode z u r Auswahl d e s T e s t s d e k l a r i e r e n
19
void s e l e c t T e s t ( void ) ;
20
void startTest ( i n t ) ;
21
void i n i t T e s t ( void ) ;
22
23
// S o n s t i g e
24
v o i d eepromWriteTo ( i n t , i n t ) ;
25
i n t eepromReadFrom ( i n t ) ;
26
27
// R e g i s t e r t e s t s
28
e x t e r n v o i d TEST R0( v o i d ) ;
29
30
31
32
33
34
35
36
37
38
e x t e r n v o i d TEST R10 ( v o i d ) ;
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// Push−Pop−Ret−Test
63
e x t e r n v o i d PPRJ TEST( v o i d ) ;
64
65
// A r i t h m e t i s c h e T e s t s
66
e x t e r n v o i d ADD TEST( v o i d ) ;
67
e x t e r n v o i d ADDC TEST( v o i d ) ;
68
e x t e r n v o i d SUB TEST( v o i d ) ;
69
e x t e r n v o i d INC TEST( v o i d ) ;
70
e x t e r n v o i d DEC TEST( v o i d ) ;
71
e x t e r n v o i d MUL TEST( v o i d ) ;
72
73
// T e s t s d e r l o g i s c h e n B i t o p e r a t i o n e n
74
e x t e r n v o i d CLR TEST( v o i d ) ;
75
e x t e r n v o i d COM TEST( v o i d ) ;
76
e x t e r n v o i d LSL TEST ( v o i d ) ;
77
e x t e r n v o i d LSR TEST( v o i d ) ;
78
e x t e r n v o i d ROL TEST( v o i d ) ;
79
e x t e r n v o i d ROR TEST( v o i d ) ;
Seite 104
80
e x t e r n v o i d SWAP TEST( v o i d ) ;
81
82
// T e s t s d e r l o g i s c h e n Op e ra t i o ne n
83
e x t e r n v o i d AND TEST( v o i d ) ;
84
e x t e r n v o i d OR TEST( v o i d ) ;
85
e x t e r n v o i d EOR TEST( v o i d ) ;
86
87
// T e s t s d e r T r a n s f e r −B e f e h l e
88
extern void mov test ( void ) ;
89
e x t e r n v o i d movw test ( v o i d ) ;
90
extern void l d i t e s t ( void ) ;
91
extern void l d t e s t ( void ) ;
92
93
// Port−T e s t s
94
v o i d PortTes t ( v o i d ) ;
95
96
// Timer−T e s t s
97
v o i d Timer0Test ( v o i d ) ;
98
99
100
101
// Watchdog−Test
102
v o i d WDTest( v o i d ) ;
103
104
// RAM−Test
105
v o i d Ram Test ( v o i d ) ;
106
v o i d Ram Check ( u n s i g n e d c h a r ∗ , u n s i g n e d c h a r ∗ ) ;
107
108
// Flash−Test
109
void Flash Test ( void ) ;
Seite 105
Seite 106
Abbildung B.1: Tabelle der Anforderung für Kategorien
[BGIA08, S. 46f]
Seite 107
C Schaltplan
Abbildung C.1: Schaltplan eines Kanals
Seite 108
Seite 109
Diese Bachelor-Thesis ist als PDF-Dokument auf der beiliegenden CD-ROM enthalten. Weiterhin sind die entwickelte Software, sowie diverse Fotoaufnahmen der
Testabläufe auf dem optischen Medium zu finden.
Die Ordnerstruktur der CD-ROM ist in Abbildung D.1 dargestellt.
Abbildung D.1: Ordnerstruktur der CD-ROM

Aufbau eines homogen redundanten Rechnersystems und

Transcrição

Documentos relacionados

Auf der Via Gebennensis von La Côte-Saint-André nach Le Puy

Biografie - Maxim Zettel

PDF / 33 kB - Forschungszentrum Jülich

Maxim Kazyukanov, Industrie

PG-Antrag - Lehrstuhl 5 für Programmiersysteme

Marketing Guide

Das Noether-Theorem in der klassischen Feldtheorie

Eklat im Leinwiger Rat - Leuphana Universität Lüneburg

Kurzinterview Hellmuth Karasek: 1. Dieses Jahr wird die 5

Technischer Bericht126.4 KB