Post on 19-Aug-2019
transcript
Bachelorthesis
Aufbau eines homogen redundanten Rechnersystems undUntersuchung des Ausfallverhaltens unter Umgebungseinflussen
Hochschule Bonn-Rhein-SiegFachbereich Informatik
Studiengang:Bachelor of Computer Science / Embedded Systems
Grantham-Allee 2053757 Sankt Augustin
Vorgelegt von:
Maxim Kupper
Erstprufer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prof. Dr. Dietmar ReinertZweitprufer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr. Michael Schaefer
Eingereicht am: 15. April 2009
Eidesstattliche Erklarung
Ich versichere an Eides statt, die von mir vorgelegte Arbeit selbststandig verfasstzu haben. Alle Stellen, die wortlich oder sinngemaß aus veroffentlichten oder nichtveroffentlichten Arbeiten anderer entnommen sind, habe ich als entnommen kennt-lich gemacht. Samtliche Quellen und Hilfsmittel, die ich fur die Arbeit benutzt habe,sind angegeben. Die Arbeit hat mit gleichem Inhalt bzw. in wesentlichen Teilen nochkeiner anderen Prufungsbehorde vorgelegen.
(Datum, Ort, Unterschrift)
Danksagung
An dieser Stelle mochte ich mich bei meinen beiden Prufern, Prof. Dr. Dietmar Rei-nert und Dr. Schaefer, fur die Ermoglichung und die hilfreiche Unterstutzung beider Erstellung meiner Bachelor-Thesis bedanken. Ohne sie ware diese Arbeit nichtmoglich gewesen.
Weiterhin danke ich auch den Mitarbeitern des BGIA in Sankt Augustin. Hervor-zuheben sind hierbei Herr K.-H. Bullesbach, Herr W. Grommez, Herr A. Lungfielund Herr T. Seifen, die mir mit Rat und Tat zur Seite standen.
Zum Schluss mochte ich mich noch bei meiner Familie und meinen Freunden furihre Unterstutzung und ihr Verstandnis bedanken.
Inhaltsverzeichnis Seite IV
Inhaltsverzeichnis
Inhaltsverzeichnis IV
Abbildungsverzeichnis VII
Abkurzungsverzeichnis IX
Quellcodeverzeichnis XI
1 Einleitung 11.1 Thema und Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Losungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Eingesetzte Techniken fur mehrkanalige Strukturen . . . . . . . . . . 2
2 Anforderungen an sicherheitsgerichtete Maschinensteuerungen 42.1 Performance Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Schwere der Verletzung . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Haufigkeit und/oder Dauer der Gefahrdungsexposition . . . . 62.1.3 Moglichkeit zur Gefahrenabwendung oder Begrenzung des Scha-
dens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Kategorie B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Kategorie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Kategorie 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Kategorie 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Kategorie 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Mittlere Zeit bis zum gefahrbringenden Ausfall . . . . . . . . . . . . . 112.4 Diagnosedeckungsgrad . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Fehler infolge gemeinsamer Ursache . . . . . . . . . . . . . . . . . . . 12
3 Technische Realisierung 143.1 AVR Butterfly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Atmel ATMega169P . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 Peripherie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 AVR Butterfly Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 Universal Asynchronous Receiver Transmitter (UART) . . . . 173.2.2 In-System-Programmer (ISP) . . . . . . . . . . . . . . . . . . 193.2.3 Joint Test Action Group - Port (JTAG) . . . . . . . . . . . . 19
3.3 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 Revision 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Revision 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3 Revision 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Inhaltsverzeichnis Seite V
4 Entwickelte Software 244.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Konfigurationsmoglichkeiten . . . . . . . . . . . . . . . . . . . . . . . 274.5 Fehlerbeherrschende Maßnahmen . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.2 Fehlerroutinen . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.3 Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Selbsttests 365.1 CPU-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Arithmetische Tests . . . . . . . . . . . . . . . . . . . . . . . . 375.1.2 Registertests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.3 Push-Pop-Return-Jump-Test . . . . . . . . . . . . . . . . . . . 415.1.4 Test der logischen Operationen . . . . . . . . . . . . . . . . . 435.1.5 Tests der Bit-Operationen . . . . . . . . . . . . . . . . . . . . 445.1.6 Test der Transfer-Befehle . . . . . . . . . . . . . . . . . . . . . 45
5.2 Peripherie Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.1 Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2 Tests der integrierten Timer . . . . . . . . . . . . . . . . . . . 485.2.3 RAM-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2.4 ROM-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.5 Ports als Ein- und Ausgange . . . . . . . . . . . . . . . . . . . 53
5.3 Bibliothek der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6 Beobachtung des Verhaltens unter Umgebungsbedingungen 586.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Elektromagnetische Vertraglichkeit . . . . . . . . . . . . . . . . . . . 59
6.2.1 Kapazitive Kopplung . . . . . . . . . . . . . . . . . . . . . . . 596.2.2 Elektrostatische Entladung . . . . . . . . . . . . . . . . . . . . 636.2.3 Unterbrechung der Versorgungsspannung . . . . . . . . . . . . 646.2.4 Austastung der Versorgungsspannung . . . . . . . . . . . . . . 656.2.5 Analyse der EMV-Untersuchungen . . . . . . . . . . . . . . . 66
6.3 Temperaturbestandigkeit . . . . . . . . . . . . . . . . . . . . . . . . . 676.3.1 Positiver Temperaturbereich . . . . . . . . . . . . . . . . . . . 686.3.2 Negativer Temperaturbereich . . . . . . . . . . . . . . . . . . 696.3.3 Analyse der Temperaturmessungen . . . . . . . . . . . . . . . 69
7 Zusammenfassung 717.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Literaturverzeichnis 73
A Quellcode 75A.1 Quellcode Main-App.c . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.2 Quellcode Main-App.h . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.3 Quellcode TestLib.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Inhaltsverzeichnis Seite VI
A.4 Quellcode TestLib.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B Tabelle der Anforderung fur Kategorien 106
C Schaltplan 108
D CD-ROM mit Inhalten der Bachelor-Thesis 109
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Abbildungsverzeichnis Seite VII
Abbildungsverzeichnis
2.1 Ausfallwahrscheinlichkeit nach Performance Level . . . . . . . . . . . 42.2 Risikograph zur Bestimmung des PLr . . . . . . . . . . . . . . . . . . 52.3 Saulendiagramm zur vereinfachten Bestimmung des PL . . . . . . . . 72.4 Architektur eines Kategorie B bzw. Kategorie 1-Systems . . . . . . . 82.5 Architektur eines Kategorie 2-Systems . . . . . . . . . . . . . . . . . 92.6 Architektur eines Kategorie 3-Systems . . . . . . . . . . . . . . . . . 102.7 Architektur eines Kategorie 4-Systems . . . . . . . . . . . . . . . . . 112.8 Zuordnung des MTTFd zu Betriebsjahren . . . . . . . . . . . . . . . . 122.9 Ubersicht des Diagnosedeckungsgrad . . . . . . . . . . . . . . . . . . 13
3.1 Butterfly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 AVR Butterfly Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Datenubertragung mittels EIA-232 . . . . . . . . . . . . . . . . . . . 183.4 Mogliche Ubertragungsfehler von Bussystemen . . . . . . . . . . . . . 183.5 Revision 1 des Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . 223.6 Revision 2 des Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . 223.7 Revision 3 des Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Struktur der Initialisierung und der Betriebsbereitschaft . . . . . . . 254.2 Struktur der Hauptroutine . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Tabelle der Laufzeitanzeige . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Tabelle der Betriebsmodi . . . . . . . . . . . . . . . . . . . . . . . . . 274.5 Struktur der Synchronisationsroutine . . . . . . . . . . . . . . . . . . 304.6 Tabelle der Fehlercodes . . . . . . . . . . . . . . . . . . . . . . . . . . 344.7 Struktur der Fehlerroutinen . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Programmablauf des Tests fur die Addition . . . . . . . . . . . . . . . 385.2 Programmablauf des ADDC-Tests . . . . . . . . . . . . . . . . . . . . 395.3 Programmablauf der Registertests . . . . . . . . . . . . . . . . . . . . 405.4 Abschnitt 1 des PPRJ-Test: PUSH-Test . . . . . . . . . . . . . . . . 415.5 Abschnitt 2 des PPRJ-Test: POP-Test . . . . . . . . . . . . . . . . . 425.6 Abschnitt 3 des PPRJ-Test: RETURN und JUMP-Test . . . . . . . . 435.7 Programmablauf des Test der logischen AND-Verknupfung . . . . . . 445.8 Test des Befehls fur das indirekte Laden von Registern . . . . . . . . 465.9 Test der Timer auf korrekte Funktionsweise . . . . . . . . . . . . . . 495.10 Struktur des ROM-Tests. . . . . . . . . . . . . . . . . . . . . . . . . . 525.11 Struktur der Test-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . 55
6.1 Prinzip des Interferenzen-Problems . . . . . . . . . . . . . . . . . . . 596.2 Positiver Impuls (rot) und Impulsfolge (blau) . . . . . . . . . . . . . 606.3 Storung der Ubertragung durch gekipptes Bit . . . . . . . . . . . . . 616.4 Versuchsaufbau 1b - serielle Schnittstelle zu GND . . . . . . . . . . . 626.5 Sichtbare ESD-Entladung . . . . . . . . . . . . . . . . . . . . . . . . 63
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Abbildungsverzeichnis Seite VIII
6.6 Versuchsaufbau: Spannungsunterbrechung . . . . . . . . . . . . . . . 656.7 Zeitlicher Verlauf der Spannung . . . . . . . . . . . . . . . . . . . . . 666.8 Schematischer Temperaturverlauf, positiver Temperaturbereich . . . . 686.9 Schematischer Temperaturverlauf, negativer Temperaturbereich . . . 69
B.1 Tabelle der Anforderung fur Kategorien . . . . . . . . . . . . . . . . . 107
C.1 Schaltplan eines Kanals . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.1 Ordnerstruktur der CD-ROM . . . . . . . . . . . . . . . . . . . . . . 109
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Abkurzungsverzeichnis Seite IX
Abkurzungsverzeichnis
µC . . . . . . . . . . . . . . . . . . MikrocontrollerADC . . . . . . . . . . . . . . . Analog/Digital - Converter
Analog/Digital - WandlerAVR . . . . . . . . . . . . . . . . Bezeichnung einer µC-Familie von ATMELCCF . . . . . . . . . . . . . . . . Common Cause Failure
Ausfalle infolge gemeinsamer UrsachenCRC . . . . . . . . . . . . . . . . Cyclic Redundancy Check
Zyklische RedundanzprufungDC . . . . . . . . . . . . . . . . . Diagnostic Coverage
DiagnosedeckungsgradDCavg . . . . . . . . . . . . . . Average Diagnostic Coverage
Durchschnittlicher DiagnosedeckungsgradEEPROM . . . . . . . . . . Electrically Erasable Programmable Read Only Memory
Nicht fluchtiger, elektronischer SpeicherELF . . . . . . . . . . . . . . . . Executable and linkable format
Dateiformat fur µC-ProgrammierungEM . . . . . . . . . . . . . . . . . ElektromagnetischEMV . . . . . . . . . . . . . . . Elektromagnetische VertraglichkeitESD . . . . . . . . . . . . . . . . Elektostatic Discharge
Elektrostatische EntladungI/O . . . . . . . . . . . . . . . . . Input / OutputICE . . . . . . . . . . . . . . . . In-Circuit-EmulatorISP . . . . . . . . . . . . . . . . . In-System-Programmer, auch In-System-ProgrammingJTAG . . . . . . . . . . . . . . Joint Test Action GroupLCD . . . . . . . . . . . . . . . . Liquid Crystal Display
Flussigkristall DisplayMTTFd . . . . . . . . . . . . . Mean Time to Dangerous Failure
Mittlere Zeit bis zu einem gefahrbringenden AusfallPAP . . . . . . . . . . . . . . . . ProgrammablaufplanPCB . . . . . . . . . . . . . . . . Printed Circuit Board
Elektronische LeiterplattePFH . . . . . . . . . . . . . . . . Probability of Dangerous Failure per Hour
Wahrscheinlichkeit eines gefahrlichen Ausfalls pro StundePL . . . . . . . . . . . . . . . . . Performance-LevelPLr . . . . . . . . . . . . . . . . . Performance Level required
Benotigtes Performance LevelRAM . . . . . . . . . . . . . . . Random Access Memory
Speicher mit wahlfreiem ZugriffRISC . . . . . . . . . . . . . . . Reduced Instruction Set Computing
Rechnen mit reduziertem BefehlssatzROM . . . . . . . . . . . . . . . Read only Memory
Nur-Lese-Festwertspeicher
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Abkurzungsverzeichnis Seite X
SRP/CS . . . . . . . . . . . . Safety-Related Parts of Control SystemSicherheitsbezogene Teile einer Steuerung
UART . . . . . . . . . . . . . . Universal Asynchronous Receiver TransmitterUSB . . . . . . . . . . . . . . . . Universal Serial BusUSI . . . . . . . . . . . . . . . . . Universal Serial Interface
Universelle Serielle SchnittstelleV . . . . . . . . . . . . . . . . . . . Volt
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Quellcodeverzeichnis Seite XI
Quellcodeverzeichnis
4.1 Konfigurationsmoglichkeiten der Software . . . . . . . . . . . . . . . . 294.2 Synchronisationsroutine . . . . . . . . . . . . . . . . . . . . . . . . . 325.1 Selbsttest der Addition . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Selbsttest der bitweisen Verschiebung nach links . . . . . . . . . . . . 455.3 Watchdog-Prufroutine am Programmbeginn . . . . . . . . . . . . . . 475.4 Watchdog-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5 RAM-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.6 Porttest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7 Beispiel: Aufruf der Selbsttests . . . . . . . . . . . . . . . . . . . . . . 555.8 Beispielhafte Implementierung der testError() . . . . . . . . . . . . . 57
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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, mussen diese Teile einer Steuerung mit Maßnahmen
gegen Ausfalle infolge gemeinsamer Ursachen ausgestattet sein. Die Anforderungen
an diese Maßnahmen sehen vor, dass ein System moglichst diversitar aufzubauen ist,
um solche Ausfalle zu verhindern. Ob ein homogen redundantes System ein hoheres
Risiko darstellt, da es gegen die Art dieser Ausfalle nicht ausreichend geschutzt ist,
soll mit dieser Arbeit geklart werden.
Dazu befasst sich diese Bachelorthesis mit dem Titel”Aufbau eines homogen
redundanten Rechnersystems und Untersuchung des Ausfallverhaltens unter Um-
gebungseinflussen“ mit der Erstellung eines homogen redundanten Rechnersystems,
ahnlich wie sie in Maschinensteuerungen in der Industrie verwendet werden. Im Zuge
dieser Arbeit wird ein System aus zwei Kanalen aufgebaut.
Beide Kanale bestehen aus identischer Hardware und werden mit derselben Soft-
ware betrieben. In Anlehnung an die Anforderungen an SRP/CS durch die Norm
werden wichtige Maßnahmen zur Fehlererkennung und deren Beherrschung imple-
mentiert, damit das System bei auftretenden Fehlern in den sicheren Zustand uber-
fuhrt wird. Trotz dieser Mechanismen wird das System keine vollwertige Struktur
einer Kategorie darstellen, sondern lediglich die grundlegenden Elemente aufweisen,
die benotigt werden, um die geplanten Untersuchungen durchzufuhren.
Um eine Aussage uber das Verhalten der Kanale treffen zu konnen, werden diese
verschiedenen Umgebungseinflussen ausgesetzt und das Ausfallverhalten des kom-
pletten Rechnersystems beobachtet. Im Speziellen soll gepruft werden, ob das Sys-
tem aufgrund gemeinsamer Schwachpunkte in einen unsicheren Zustand gerat.
Die wahrend der Entwicklung implementierten Selbsttests sollen zu einer Biblio-
thek zusammengefasst werden. Diese soll uber Methoden und Parameter auf den
benotigten Leistungsumfang anpassbar sein, um anderen Projekten zur Verfugung
gestellt zu werden. Voraussetzung ist, dass diese Projekte als technische Grundla-
ge einen ATMEL AVR-Mikrocontroller einsetzen, der uber den gleichen Befehlssatz
verfugt wie ein ATMega169P.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
1.2 Motivation Seite 2
1.2 Motivation
Viele Steuereinheiten in Maschinen mit hohem Gefahrdungspotential sind homogen
redundant aufgebaut. Dadurch besteht die Gefahr, dass alle Kanale dieser Steue-
rung zur selben Zeit ausfallen und das gesamte Steuerungssystem einen unsicheren
Zustand hervorruft. Ob ein System mit homogen redundanter Struktur allerdings
eine hohere Ausfallwahrscheinlichkeit hat, ist nicht hinreichend geklart. Diese Arbeit
wird versuchen eine Antwort auf diese Frage zu finden.
Der Nachteil von Diversitat ist der hohere Aufwand bei der Entwicklung, Er-
stellung und Wartung des Systems, wodurch hohere Kosten entstehen. Bietet ein
homogenes System jedoch die gleichen Sicherheitseigenschaften wie ein diversitares
System, sind diese Muhen unnotig und konnen eingespart werden.
1.3 Losungsansatz
Um das Ziel der Arbeit zu erreichen, wird ein exemplarisches Testsystem aufge-
baut dessen Verhalten unter verschiedenen Einflussen untersucht wird. Es soll durch
zwei Mikrocontroller (µC) realisiert werden, die in ein System eingebettet und mit-
einander verbunden sind, um sich so zur Laufzeit synchronisieren zu konnen. Zur
Demonstration des Programmablaufs wird eine Applikation erstellt, die zu jeder
Zeit einen Status hat, der uber eine visuelle Ausgabe ausgegeben wird. Um die
sicherheitsrelevanten Anforderungen zu erfullen, 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 uberfuhrt wird.
In Untersuchungen unter verschiedenen Umgebungsvariablen wird anschließend
das Verhalten des Systems beobachtet. Konkret wird die Eignung eines homogen
redundanten Systems zur Erfullung der Anforderung nach der Norm DIN EN ISO
13849-1 gepruft. Diese Untersuchungen sollen Aufschluss daruber geben, ob es moglich
ist, beide Kanale systematisch auszuhebeln und so das Rechnersystem in den unsi-
cheren Zustand zu bringen. Tritt dieser Fall ein, ist gezeigt, dass homogene Redun-
danz nicht geeignet ist, um Maßnahmen gegen Ausfalle infolge gemeinsamer Ursache
zu realisieren.
1.4 Eingesetzte Techniken fur mehrkanalige Strukturen
Neben nicht elektronischen, pneumatischen oder mechanischen Sicherheitsvorkeh-
rungen gibt es auch sicherheitsrelevante Teile einer Steuerung auf elektronischer
Basis. Mehrkanalige Strukturen konnen dabei homogen oder diversitar realisiert
werden.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
1.4 Eingesetzte Techniken fur mehrkanalige Strukturen Seite 3
Homogene Redundanz
Strukturen mit homogener Redundanz basieren auf den gleichen technischen Grund-
lagen. So sind gleiche Bauteile verbaut, die in der Theorie die gleichen Schwach-
punkte haben. Durch die Verwendungen derselben Software sind alle Kanale mit
den selben systematischen Softwarefehlern behaftet.
Diversitare Redundanz
Diversitare Redundanz basiert hingegen darauf, Systeme mit unterschiedlichen tech-
nischen Grundlagen aufzubauen. Theoretisch ist dadurch die Wahrscheinlichkeit ei-
nes Ausfalls infolge gemeinsamer Ursache deutlich geringer, da sowohl die Hardware
als auch die betreibende Software nicht gleich sind. Das fuhrt dazu, dass durch
außere Einflusse ein unterschiedliches Ausfallverhalten fur jeden Kanal entsteht.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 Beschaffen-
heit oder ihrer Handhabung Gefahrdungen fur die Menschen in naherer Umgebung
aus. Um diese Gefahrdungen zu reduzieren, sind verschiedene Sicherheitsvorkehrun-
gen zu treffen. Diese Vorkehrungen konnen nicht immer durch konstruktive Maß-
nahmen getroffen werden, wodurch die Notwendigkeit von sicheren Steuerungen der
Maschinen entsteht. Da sich die Gefahrdungen je nach Beschaffenheit und Einsatz-
zweck unterscheiden - zumal von einer Maschine meistens mehr als eine Gefahrdung
ausgeht - ist es notwendig, diese Gefahrdungen einschatzen und bewerten zu konnen,
um somit okonomisch 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 aus-
gehenden Gefahrdungen identifiziert. Anschließend wird jeder Gefahrdung eine Si-
cherheitsfunktion, mit dem Ziel die Gefahrdung 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-
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.1 Performance Level Seite 5
tion ausfuhren soll. Der Performance Level (PL) dieses SRP/CS orientiert sich am
geforderten Performance Level (Performance Level required, PLr), der durch die
Gefahrdung vorgegeben wird. Um die Anforderungen der DIN EN ISO 13849-1 zu
erfullen, 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 Wahr-
scheinlichkeit eines gefahrlichen Ausfalls pro Stunde (PFH) zu einem der funf 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. Dafur wird der Graph
anhand von drei Risikoparametern durchlaufen, die als Entscheidungskriterien fur
die Einstufung der Gefahrdung dienen. Folgende Parameter werden in Betracht ge-
zogen:
• S - Schwere der Verletzung
• F - Haufigkeit und/oder Dauer der Gefahrdungsexposition
• P - Moglichkeit zur Gefahrenabwendung oder Begrenzung des Schadens
Abbildung 2.2: Risikograph zur Bestimmung des PLr
[BGIA08, S. 30]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.1 Performance Level Seite 6
2.1.1 Schwere der Verletzung
Die Schwere der Verletzung wird dabei in zwei Kategorien unterteilt:
• S1 - leichte, uberlicherweise reversible Verletzungen
• S2 - schwere, nicht reversible Verletzungen einschließlich Tod
Zu beachten ist, dass vom Worst-Case ausgegangen werden muss. Nicht jeder Feh-
ler einer gefahrbringenden Maschine fuhrt zu einer todlichen Verletzung, es genugt
jedoch, dass allein die Moglichkeit besteht, eine derart ernste Verletzung herbei zu
fuhren.
2.1.2 Haufigkeit und/oder Dauer der Gefahrdungsexposition
Ebenso wird die Haufigkeit und/oder die Dauer der Gefahrundgsexposition in zwei
Kategorien unterteilt:
• F1 - selten bis weniger haufig und/oder die Dauer der Gefahrdungsexposition
ist kurz
• F2 - haufig bis dauernd und/oder die Dauer der Gefahrdungsexposition 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 Haufig-
keit oder der Dauer wird in der Norm nicht genannt. Eine Anmerkung besagt aber,
dass F2 gewahlt werden soll, wenn die Frequenz der Gefahrdungsexposition großer
als einmal pro Stunde ist und keine anderen Festlegungen getroffen wurden.
2.1.3 Moglichkeit zur Gefahrenabwendung oder Begrenzung des Schadens
Die Moglichkeit zur Gefahrenabwendung beschreibt, ob der Bediener einer Maschine
eine Verletzung noch abwenden kann, wenn er feststellt, dass die Maschine sich nicht
wie vorgesehen verhalt. Die zwei Moglichkeiten sind:
• P1 - moglich unter bestimmten Bedingungen
• P2 - kaum moglich
Dabei ist zu beachten, ob ein Bediener auf eine auftretende Gefahr uberhaupt
reagieren kann und wenn ja, welche Chance er hat, diese Gefahr abzuwenden. Auch
die physikalischen Eigenschaften des Systems mussen in diese Bewertung einfließen.
[BGIA08, S. 26ff]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.2 Kategorien Seite 7
Der von den sicherheitsbezogenen Teilen einer Steuerung erreichte Performance Le-
vel wird durch die erzielte Kategorie, der mittleren Zeit bis zum gefahrbringenden
Ausfall der verwendeten Bauteile (MTTFd, vgl. Abschnitt 2.3, S. 11), dem Diagno-
sedeckungsgrad der Tests (DC, vgl. Abschnitt 2.4, S. 12) und den Maßnahmen gegen
Ausfalle 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: Saulendiagramm 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 Zuverlassigkeit von SRP/CS. Zusammen mit den anderen, sicher-
heitsrelevanten Parametern - MTTFd, DCavg und Maßnahmen gegen CCF - sind sie
daher ein geeignetes Maß, um die Widerstandsfahigkeit von Steuerungen gegenuber
Fehlern zu beschreiben.
2.2.1 Kategorie B
Diese Kategorie dient als Grundlage fur alle Kategorien. Sie setzt voraus, dass die
SRP/CS unter Verwendung von grundlegenden Sicherheitsprinzipien entwickelt wer-
den. Weiterhin mussen alle Bauteile den zu erwartenden Belastungen standhalten
konnen, d.h. im Speziellen den Betriebsbeanspruchungen sowie dem Einfluss von
Materialien, die im Arbeitsprozess verwendeten werden. Da ein Kategorie B-System
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.2 Kategorien Seite 8
nicht kontrolliert ob die Sicherheitsfunktion ausgefuhrt wird und auch nicht mehr-
kanalig 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 hoheren 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 zwangslaufig
fur die Realisierung einer SRP/CS genutzt werden, eine Abweichung muss jedoch
hinreichend begrundet 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 Zuverlassigkeit von den verwendeten Bau-
teilen verlangt, fordert Kategorie 1 bewahrte Bauteile. Ein Bauteil gilt als bewahrt,
wenn es in der Vergangenheit fur ahnliche Anwendungen mit Erfolg eingesetzt wurde
oder unter Anwendung von Prinzipien hergestellt und verifiziert wurde, die seine Eig-
nung und Zuverlassigkeit fur sicherheitsbezogene Anwendungen zeigen. Die SRP/CS
muss uber eine hohe MTTFd verfugen (vgl. Anhang B). Weiterhin mussen alle An-
forderungen der Kategorie B erfullt 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 fuhren. 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 Bau-
teile nicht als bewahrte Bauteile gesehen und daher in Systemen der Kategorie 1
nicht eingesetzt werden konnen.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 mussen
SRP/CS dieser Kategorie, nach DIN EN ISO 13849-1, in angemessenen Zeitabstan-
den durch die Maschinensteuerung auf korrekte Arbeitsweise uberpruft werden. Die
Sicherheitsfunktion muss getestet werden, wenn die Maschine anlauft oder die Ein-
leitung einer Gefahrdungssituation erfolgt.
Anmerkung 2 erganzt, 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 hoher sein als die mittlere Anforde-
rungsrate der Sicherheitsfunktion. Bei der vereinfachten Bestimmung des PLs einer
SRP/CS mittels des in Abbildung 2.3 dargestellten Saulendiagramms wird daher
von einer 100-mal hoheren Testrate ausgegangen.
Die durchgefuhrten Tests durfen nicht zu einer Gefahrdungssituation fuhren. Soll-
te es zu einem Fehler der SRP/CS kommen, so verfugt die Testeinrichtung uber einen
unabhangigen Abschaltpfad, der die Maschine in den sicheren Zustand versetzen
kann.
Die gestellten Anforderungen an die MTTFd oder den DCavg gelten hierbei nur fur
die Bauteile der SRP/CS, nicht fur die der Testeinrichtung. Zu den Anforderungen
der Kategorie 2 gehoren 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]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.2 Kategorien Seite 10
2.2.4 Kategorie 3
Die Anforderungen nach der Kategorie 3 sehen vor, dass ein Fehler nicht zum Aus-
fall der Sicherheitsfunktion fuhren darf. Damit soll verhindert werden, dass bedingt
durch einen einzelnen Fehler die Sicherheitsfunktion nicht mehr ausgefuhrt wer-
den kann, wodurch eine Gefahrdungssituation entstehen wurde. Auftretende Fehler
mussen bei oder vor der nachsten Anforderung der Sicherheitsfunktion erkannt wer-
den. Meistens wird dies durch eine zweikanalige Struktur, wie die Architektur in
Abbildung 2.6 darstellt, gelost.
Es ist jedoch moglich, Einfehlersicherheit ohne Redundanz zu realisieren. Die Ver-
wendung mehrere Kanale kann durch ein fehlersicheres Design - inharente Sicherheit
- ersetzt werden. Auch ein eigener Abschaltpfad mit hochwertiger Uberwachung der
Logik des SRP/CS, der im Fehlerfall den sicheren Zustand des Systems so schnell
einleitet, dass ein gefahrlicher Zustand vermieden wird, kann als Alternative genutzt
werden.
Auch gegen Ausfalle infolge gemeinsamer Ursachen mussen 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. Fur eine Struktur der
Kategorie 3 wird eine MTTFd von mindestens niedrig vorausgesetzt (vgl. Anhang
B).
Sowohl Kategorie 3, wie auch die folgende Kategorie 4, konnen einen maximalen
Performance Level von PL = e erreichen (vgl. Abbildung 2.3).
Abbildung 2.6: Architektur eines Kategorie 3-Systems[BGIA08, S. 50]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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. Zusatzlich verscharft sie einige der Anforderungen.
Die Architektur dieser Kategorie entspricht, bis auf die Uberwachung der Ausgange
und dem Kreuzvergleich der SRP/CS, der der Kategorie 3. Die Uberwachung der
Ausgange und der Kreuzvergleich sind zwar auch in der Architektur der Katego-
rie 3 vorhanden, mussen jedoch nur eine angemessene Rate haben. In Kategorie 4
mussen alle Fehler erkannt werden, was in Abbildung 2.7 mittels durchgezogener Li-
nien dargestellt wird (vgl. Abbildung 2.6). Einzelne Fehler durfen nicht zum Ausfall
der Sicherheitsfunktion fuhren. Sollte eine Erkennung eines Fehlers nicht moglich
sein, so darf eine Akkumulation weiterer nicht erkannter Fehler nicht zum Verlust
der Sicherheitsfunktion fuhren.
MTTFd sowie DCavg jedes Kanals mussen hoch sein (vgl. Anhang B). Ebenfalls
mussen Maßnahmen gegen CCF vorhanden sein, um den Ausfall infolge gemeinsa-
mer Ursache zu verhindern. Durch diese hohen Anforderungen kann mit einer sicher-
heitsrelevanten Steuerung dieser Kategorie der hochste Performance Level PL = e
realisiert werden (vgl. Abbildung 2.3).
Abbildung 2.7: Architektur eines Kategorie 4-Systems[BGIA08, S. 50]
2.3 Mittlere Zeit bis zum gefahrbringenden Ausfall
Der von SRP/CS erreichbare Performance Level richtet sich nicht nur nach der Ka-
tegorie, sondern auch nach der Zuverlassigkeit 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-
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 ublicherweise in
Jahren angegeben. Die Bereiche der MTTFd-Angaben fur die einzelnen Kanale einer
SRP/CS sind der Abbildung 2.8 zu entnehmen.
Abbildung 2.8: Zuordnung des MTTFd zu Betriebsjahren[BGIA08, S. 53]
Moglich ist auch die Lebensdauer in Ausfallraten oder Schaltspielen anzugeben,
allerdings mussen diese Werte fur 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 uber die Anzahl
der Ausfalle 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 Ausfallen er-
kannt werden kann. DCavg bezeichnet dabei den Prozentsatz fur die gesamte sicher-
heitsrelevante 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 Ausfallen infolge gemeinsamer Ur-
sachen (Common Cause Failure) begutachtet. Die getroffenen Maßnahmen werden
dazu gemaß DIN EN ISO 13849-1 mit Punkten bewertet:
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
2.5 Fehler infolge gemeinsamer Ursache Seite 13
Abbildung 2.9: Ubersicht des Diagnosedeckungsgrad[BGIA08, S. 55]
• 25 Punkte: Schutz vor durch Verunreinigung oder durch elektromagnetischer
Beeinflussung ausgeloste CCF
• 20 Punkte: Diversitare Gestaltung der Kanale
• 15 Punkte: Physikalische Trennung zwischen den Signalpfaden
• 15 Punkte: Schutz gegen Uberbelastung
• 10 Punkte: Schutz vor CCF, die durch anderen Einflusse ausgelost werden
konnen
• 5 Punkte: Schulung von Konstrukteuren und Monteuren gegenuber CCF
• 5 Punkte: Verwendung bewahrter 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 Kate-
gorie 2, 3 oder 4 erlangen kann. Im Saulendiagramm zur vereinfachten Bestimmung
des Performance Level - Abbildung 2.3 (S. 7) - ist daher von der Erfullung der
Anforderung fur die genannten Kategorien ausgegangen worden.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3 Technische Realisierung Seite 14
3 Technische Realisierung
Um das Verhalten einer homogen redundanten Steuerung zu erforschen, wurde ein
Rechnersystem aus zwei hard- und softwaretechnisch identisch aufgebauten Kanalen
erstellt. Diese Kanale setzen sich aus einem Butterflyboard von Atmel, dem passen-
den Butterfly Carrier von Ecros Technology [@Ecr09] und weiteren Peripheriegerate,
LEDs und Programmierschnittstellen zusammen. Die Verbindung zwischen den ein-
zelnen Systemen des Rechnersystems wird uber die serielle Schnittstelle des Butter-
flys hergestellt.
3.1 AVR Butterfly
Bei dem AVR Butterfly handelt es sich um ein eigenstandiges, abgeschlossenes Sys-
tem, das zu Evaluationszwecken genutzt wurde. Es zeigt die Moglichkeiten der aktu-
ellen µC-Technologie von Atmel. Zu diesem Zweck ist es standardmaßig mit einem
ATMega169P-µC und passender Peripherie ausgestattet, wozu neben diversen An-
schlussports, ein LCD-Display, ein ADC, ein Temperatursensor, ein Joystick und
ein Piezo-Element zur Ausgabe von akustischen Signalen gehoren. Statt uber eine
Batterie, die eine Spannung von 3 Volt (V) liefert, kann das System wahlweise auch
uber eine externe Versorgung betrieben werden. Im Auslieferungszustand befindet
sich bereits ein Bootloader sowie ein rudimentares Programm in dem Programm-
speicher des µC, das einen kurzen Uberblick uber die Funktionen des Butterflys
gibt.
Das Butterfly stellt das Herzstuck der Kanale dar. Da es sich dabei um ein fur
Evaluationszwecke erstelltes System handelt, erfullt 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 Bau-
teile unter Einhaltung grundlegender Sicherheitsprinzipien, konnen nicht als gege-
ben vorausgesetzt werden. Trotz alledem war das Butterfly-Evaluationsboard fur
die Untersuchungen gut geeignet, da es durch seine Ausstattung und der einfachen
Handhabung eine hohe Flexibilitat bot und durch seine einfache Qualitat eine Art
”Worst-Case“-Szenario bildete.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 AVR-
RISC-Familie des Herstellers Atmel. Der ATMega169P ist das Nachfolgermodell des
ATMega169 und basiert auf einem Re-Design zur Senkung des Stromverbrauchs.
Nach Einfuhrung der picoPower-Technology von Atmel wurden die wichtigsten µC
in diesem Design neu aufgelegt. [@ATM08b]
Wie auch der Vorganger ist der ATMega169P in zwei Ausfuhrungen erhaltlich.
Diese unterscheiden sich durch die maximale Taktfrequenz und die benotigte Be-
triebsspannung. Das V-Modell ist fur stromsparende Anwendungen konzipiert und
ist dadurch mit niedrigerer Spannung, auf Kosten einer reduzierten Taktfrequenz,
arbeitsfahig. Durch die Halbierung der Taktfrequenz werden zur Inbetriebnahme
statt 2,7 V nur noch 1,8 V benotigt. 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 benotigt
der große Bruder schon 4,5 V fur die maximale Frequenz.
Die gesamte AVR-Mikrocontroller-Familie basiert auf der Reduced Instruction Set
Computing (RISC)-Architektur. Diese Art der µC verfugt uber einen reduzierten Be-
fehlssatz, der allerdings optimiert ist, um den Dekodierungsaufwand zu reduzieren.
Dadurch konnen die meisten der 130 Befehle des Befehlssatzes eines 8 Bit-AVR-
Controllers in einem Arbeitszyklus verarbeitet werden. Dem ATMega169 stehen 32,
jeweils 8 Bit breite Arbeitsregister zur Verfugung. Diese ersetzen den ublicherwei-
se verwendeten Akkumulator. Die unteren sechs Register konnen paarweise zu 16
Bit-Registern zusammengefasst werden und dienen als Pointer zur indirekten Adres-
sierung des Datenspeichers. Insgesamt 16 Kilobyte (kB) Flashspeicher konnen zur
Programmspeicherung genutzt werden. Laut Herstellerangaben hat dieser eine Le-
bensdauer von mindestens 10.000 Zyklen, wobei ein Zyklus dabei aus dem Loschen,
dem erneutem Programmieren und anschließendem Loschen besteht. [ATM08a, S.19]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 zusatzliche Hard-
ware eingesetzt werden kann. Die zusatzliche Peripherie wurde bereits in Abschnitt 3
(S. 14) erwahnt und wird im folgenden naher beschrieben.
Das LCD-Display verfugt uber 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 Menus genutzt. Neben dem Dis-
play befindet sich ein Joystick. Dieser hat vier Richtungen, in die er bewegt werden
kann. Weiterhin ist es moglich den Joystick in Ausgangsposition nach unten - zur
Platine (PCB) - zu drucken, wodurch ein funfter Kontakt geschlossen werden kann.
Wie das Display ist auch der Joystick bereits angeschlossen. Eingaben uber den Joy-
stick 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 konnen. Wie der Abbildung 3.1 entnommen werden kann, befinden sich
die Anschlussmoglichkeiten der beiden Ports unter dem Display; dort ist auch die
Schnittstelle fur den JTAG-Anschluss beziehungsweise den A/D-Wandler. Diese An-
schlusse werden beim Einsatz mit einem Butterfly Carrier Tragerboard - Abschnitt
3.2 - mit Hilfe von Steckverbindungen mit der Prototypflache des Butterfly Carrier
verbunden. Ebenfalls uber Steckverbindungen werden die serielle Schnittstelle und
der ISP - Abschnitt 3.2.2 (S. 19) - angeschlossen.
Auf der Ruckseite befindet sich ein Piezo-Element, mit dem es moglich ist, akus-
tische Signale auszugeben. Außerdem ist dort ein Temperatursensor verbaut, der
durch einen Widerstand mit einem negativen Temperaturkoeffizienten realisiert wur-
de.
3.2 AVR Butterfly Carrier
Der AVR Butterfly Carrier ist als Tragerboard fur das Butterfly gedacht. Wird
das Butterfly mit dem Carrier verbunden, konnen die in Abschnitt 3.1.2 erwahnten
Anschlusse leichter verwendet werden, da sie mit der experimentellen Flache - der
Prototypflache - des Carrier oder mit vorgesehen Steckvorrichtungen verbunden sind.
Uber einen Hohlstecker kann ein Gleichstrom-Netzteil an den Carrier angeschlos-
sen werden, das sowohl das Butterflyboard als auch samtliche Peripherie auf der
Prototypflache mit Strom versorgen kann. Um eine Verpolung auszuschließen, ist ei-
ne Diode hinter dem Versorgungsstecker verbaut, die Beschadigung oder Zerstorung
von Bauteilen im System durch falsch gepolte Stromversorgung verhindert. Der ver-
baute Spannungsregler, ein LF33CV, regelt eine eingehende Gleichspannung von
maximal 40 V in eine 3,3 V Ausgangsspannung um. [STM]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.2 AVR Butterfly Carrier Seite 17
Abbildung 3.2: AVR Butterfly Carrier
Folgende Schnittstellen und Ports werden durch den Carrier zur weiteren Beschal-
tung 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 benotigt wird.
Er wird mit der auf dem AVR Butterfly Carrier befindlichen EIA-232 Buchse ver-
bunden. Die entstehende EIA-232 Schnittstelle - ehemals als RS-232 bekannt - wurde
im Rahmen dieser Arbeit zur Vernetzung der Kanale verwendet. Darauf gesendete
Daten werden in, jeweils aus einem Zeichen bestehenden, Paketen verschickt. Diese
Pakete haben ein Start- und Stopp-Bit, die dem Empfanger zur Synchronisation
dienen. Ubertragen wird, wie Abbildung 3.3 entnommen werden kann, mittels nega-
tiver Logik, was bedeutet, dass eine 1 Ruhe auf dem Medium und eine 0 ein Signal
ist.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.2 AVR Butterfly Carrier Seite 18
Abbildung 3.3: Datenubertragung mittels EIA-232
Wie auch bei den in der Industrie eingesetzten Bus-Systemen, kann es bei einer
Kommunikation uber die serielle Schnittstelle zu Problemen kommen. Abbildung
3.4 zeigt mogliche Fehler. Tritt einer dieser Fehler auf, kann das im Worst-Case
zu einem gefahrlichen Zustand fuhren. Um dies zu vermeiden, sind in der Softwa-
re fehlerbehandelnde Maßnahmen implementiert (vgl. Abschnitt 4.5.1, S. 30), die
auftretende Ubertragungsfehler erkennen und behandeln konnen.
Abbildung 3.4: Mogliche Ubertragungsfehler von Bussystemen[Rei01, S. 33]
Die Programmierung des ATMega169P uber die serielle Schnittstelle ist moglich,
vorausgesetzt auf dem µC befindet sich ein Bootloader, der vom PC gesendete Da-
ten empfangen und im Programmspeicher ablegen kann. Im Auslieferungszustand
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.2 AVR Butterfly Carrier Seite 19
verfugt der Controller bereits uber einen Bootloader mit dieser Fahigkeit, der auch
beim Aufspielen neuer Software uber die EIA-232 nicht uberschrieben wird. Die im
Programmspeicher befindliche Software wird jedoch durch die neu uberspielte er-
setzt. Ein Nachteil der Programmierung uber die serielle Schnittstelle ist, dass das
Programm nicht automatisch bei Inbetriebnahme gestartet wird, sondern uber den
Bootloader angestoßen werden muss.
3.2.2 In-System-Programmer (ISP)
Um ein Programm direkt auf einen µC zu uberspielen, benotigt man einen soge-
nannten Brenner. Diese konnen direkt in den Programmspeicher schreiben und sind
zwingend notwendig, wenn auf dem Controller kein Bootloader vorhanden ist, der
Daten uber eine definierte Schnittstelle annehmen und im Programmspeicher able-
gen kann. Aber auch wenn ein Bootloader vorhanden ist, kann es sinnvoll sein, den
µC zu brennen. Die im Programmspeicher abgelegte Software ist nach dem Brenn-
vorgang die einzige auf dem Controller, wodurch sie nicht mehr uber den Bootloader
gestartet werden muss, sondern bei Inbetriebnahme automatisch ausgefuhrt wird.
Der vorhandene Bootloader wird durch das Brennen uberschrieben.
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
fur das Bauteil verbunden. Daher wird meistens bei experimentellen Systemen - wie
dem hier verwendeten Butterfly - der Weg uber eine Schnittstelle genutzt, die es
ermoglicht, das Programm direkt im Einsatzsystem auf den Controller zu schreiben.
Als einfache Schnittstelle steht der In-System-Programmer (ISP) zur Verfugung.
Uber diesen wird der Computer mit dem Butterfly verbunden und kann nun das
gewunschte Programm direkt in den Programmspeicher schreiben. Bei dieser Art
der Programmierung werden vorhandene Programme - beispielsweise ein Bootloader
- uberschrieben. Das aufgespielte Programm ist nun das Einzige auf dem Controller
und wird bei Inbtriebnahme automatisch ausgefuhrt.
Bei der Programmierung mittels ISP gibt es keine Einschrankung in der Benut-
zung der Ports, da die ISP-Schnittstelle nur zur Programmierung genutzt wird.
Wahrend der Laufzeit konnen alternative Belegungen dieser Ports benutzt werden,
da der ISP inaktiv ist.
3.2.3 Joint Test Action Group - Port (JTAG)
Neben der ISP, verfugt der ATMega169P noch uber eine weitere Schnittstelle, die
zum Brennen des Controllers genutzt werden kann. Diese Schnittstelle ist nach dem
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.3 Versuchsaufbau Seite 20
Standard IEEE 1149.1 der Joint Test Action Group (JTAG) aufgebaut. Die allge-
meine Bezeichnung lautet JTAG-Schnittstelle oder JTAG-Port.
Uber diese Schnittstelle ist es moglich, das Programm wie uber eine ISP auf den µC
zu ubertragen. Daruber hinaus ermoglicht der Einsatz des JTAG-Ports das direkte
Debugging des Systems zur Laufzeit. Dazu kann der Programmablauf einer nicht
zeitkritischen Software schrittweise ausgefuhrt werden, wobei eine Betrachtung des
aktuellen Zustandes nach jedem Schritt moglich ist.
Alternativ ist es moglich, das Programm auszufuhren und zu jedem beliebigem
Zeitpunkt, beispielsweise mittels Breakpoints, anzuhalten. In beiden Fallen konnen
die Zustande der Ein- sowie Ausgange 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. Die-
se emulieren das Verhalten eines µC, arbeiten in der Praxis allerdings nicht exakt
wie der zu emulierende Controller. Weiterhin ist eine Simulation einiger Operatio-
nen aufgrund technischer Voraussetzungen nicht moglich; beispielsweise kann das
Empfangen von Synchronisationsdaten uber die serielle Schnittstelle nicht simuliert
werden.
Um das System mit dem Computer zu verbinden, ist ein JTAG-Adapter notig,
der die Kommunikation zwischen dem Computer und dem Butterfly ubernimmt.
Als einfach zu bedienen hat sich der JTAG ICE-USB-Adapter von AVR erwiesen.
Dieser benotigt keinen seriellen Port am Computer, der bei modernerer Hardware
nicht mehr zur Standardausstattung gehort und notigenfalls mit einer zusatzlichen
Slotkarte zur Verfugung gestellt werden musste. Stattdessen wird der USB-Anschluss
genutzt, der zur Standardausstattung jedes modernen Computers gehort.
Um die Schnittstelle zu nutzen, muss das JTAGEN Fuse Bit des µC gesetzt wer-
den, damit der Controller auch uber JTAG kommuniziert. Dies stellt den einzigen
Nachteil des JTAG-Ports dar. Wenn dieses Fuse Bit gesetzt ist, konnen die I/O-Pins
der JTAG nicht mehr fur eine alternative Belegung verwendet werden. [Pard05, S.
45] Im Falle des ATMega169P ist dies der ADC, der bei der Aktivierung der JTAG-
Schnittstelle nicht mehr genutzt werden kann.
3.3 Versuchsaufbau
Ziel der Arbeit ist das Erforschen des Verhaltens von Rechnersystemen unter extre-
men Umgebungsbedingungen. Damit ein Rechnersystem entsteht, das einem SRP/-
CS, wie es in der Industrie eingesetzt wird, entspricht, mussen die beiden aufge-
bauten Systeme miteinander verbunden werden. Die geeignetste Methode, um die
beiden Systeme zu verbinden, stellt die serielle Schnittstelle dar. Werden die Syste-
me uber diese Schnittstelle verbunden und mit entsprechender Software betrieben,
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.3 Versuchsaufbau Seite 21
erfullt 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 gewahrleistet ist, sind keine ausreichenden Maßnahmen gegen
Ausfalle infolge gemeinsamer Ursache vorhanden.
Fur den Einsatzzweck des Systems mussen diese Voraussetzungen allerdings nicht
erfullt werden. Das Rechnersystem wird genutzt, um das Ausfallverhalten von ho-
mogen redundanten Systemen zu untersuchen. Bei der Auswertung der Ergebnisse
muss jedoch beachtet werden, dass ein nicht gesichertes System erwartungsgemaß
leichter ausfallt als ein gegen Storungen geschutztes.
Um das Verhalten der Kanale auch ohne weitere Analysehardware erkennen zu
konnen, wurden auf den Flachen der Butterfly Carrier mehrere LEDs verbaut. Diese
stellen, je nach Programmierung, den Status und die Fehlermeldung in einer eindeu-
tigen Kodierung dar. Weitere Details zu den Anzeigemoglichkeiten der LEDs sind
Kapitel 4 (S. 24) zu entnehmen.
Bis der Versuchsaufbau seine endgultige Form erreicht hat, wurden mehrere Re-
visionen durchlaufen, in denen sich der Aufbau veranderte. Da sich die Beschaltung
des µC von Revision 2 zu Revision 3 nicht geandert hat und der Unterschied zwi-
schen den Revisionen auf den implementierten Programmablauf keine Auswirkung
hat, ist es nicht von Bedeutung, welche Revision bei den Untersuchungen des Verhal-
tens unter Umgebungsvariablen zum Einsatz kommt. Die im Rahmen dieser Arbeit
durchgefuhrten Beobachtungen wurden mit einem Rechnersystem bestehend aus ei-
nem Kanal der Revision 2 und einem Kanal der Revision 3 gemacht. Nachtragliche
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 moglich, 24 = 16 verschiedene Zustande darzustellen. Fur den weiteren
Projektverlauf zeigte sich, dass 16 eindeutige Zustande zu wenig waren. Allein die
Anzahl der Tests uberstieg diesen Wert und so konnte, im Fehlerfall, keine eindeu-
tige Identifizierung eines fehlerhaften Tests erfolgen. Weiterhin war die Darstellung
von Fehlercode und Systemstatus schwierig, da diese uber eine wechselnde Anzeige
realisiert wurde. Dazu zeigten die LEDs nacheinander, mit einer Anzeigedauer von
jeweils etwa einer Sekunde, den Fehlercode, den Systemstatus und einen Referenz-
zustand - 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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.3 Versuchsaufbau Seite 22
Ubergang 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 erhoht, um
bis zu 28 = 256 eindeutige Zustande ausgeben zu konnen. Zudem wurde ein weiteres
LED-Feld aufgebaut, dass fur die Ausgabe der Fehlercodes und der Betriebsmodi
genutzt wird. Dieses Design erfullt bereits alle Voraussetzungen, die fur den vorge-
sehenen Programmablauf benotigt werden. Einzig die Tatsache, dass der Porttest -
Abschnitt 5.2.5 (S. 53) - mit diesem Aufbau nicht realisierbar war, fuhrte zu einer
weiteren Revision.
Abbildung 3.6: Revision 2 des Versuchsaufbau
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
3.3 Versuchsaufbau Seite 23
3.3.3 Revision 3
In Revision 3 des Versuchsaufbaus wurde der Aufbau um eine modulare Steckver-
bindung erweitert. Dieser Aufbau ermoglicht hardwareubergreifende Test, die mit
dem Aufbau der Revision 2, in dem die LEDs fest an die Ports gekoppelt wurden,
nicht moglich waren. In diesem Aufbau konnen nun wahlweise die LEDs mit den
Ports oder die Ports untereinander verbunden werden. Durch dieses modulare De-
sign kann zum einen das Programm in seiner vorgesehenen Weise ausgefuhrt und
die LEDs zur Anzeige der Zustande genutzt werden, zum anderen ist es moglich
den Porttest durchzufuhren. Dazu ist es allerdings notig, den normalen Program-
mablauf zu verlassen, die beiden Ports miteinander zu verbinden und ein separates
Testprogramm auszufuhren. Da das Butterfly nur zwei Ports zur weiteren Beschal-
tung auf der Flache des Butterfly Carrier bereitstellt, gibt es meiner Ansicht nach
keine andere Moglichkeit die korrekte Funktion der Ports zu prufen.
Abbildung 3.7: Revision 3 des Versuchsaufbau
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4 Entwickelte Software Seite 24
4 Entwickelte Software
4.1 Anforderungen
Die fur 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 ver-
schiedene Fehler gesichert. Sollten bekannten Fehler auftreten, so werden sie durch
fehlerbehandelnde Maßnahmen aufgefangen und verarbeitet.
4.2 Grundlagen
Wahrend das Programm in der Sprache C geschrieben wurde, sind Teile der Selbst-
tests in Assembler verfasst worden. Alle implementierten Selbsttests sind zu einer
Bibliothek zusammengefasst worden und konnen somit in anderen Projekten Ver-
wendung finden. Genauere Details uber die Selbsttests werden im Kapitel 5 (S. 36)
erlautert.
Als Entwicklungsumgebung wurde”Programmers Notepad“ von WinAVR ge-
nutzt. WinAVR ist eine Sammlung von Open-Source-Tools, die zum Entwickeln
von Programmen fur AVR µC genutzt werden konnen. WinAVR enthalt außerdem
alle wichtigen Tools zum Brennen und Debuggen eines µCs. Ebenfalls enthalten
ist die GNU Compiler Collection (GCC), die den benotigten Cross-Compiler AVR-
GCC beinhaltet. [@WinAVR] Die vorhandenen Assembler-Dateien werden nach dem
Kompilierungsprozess dem Projekt durch Verlinkung hinzugefugt.
Zum Beschreiben des µC wird nicht das im WinAVR-Paket enthaltene avrdude,
sondern das von Atmel entwickelte AVRStudio genutzt. Dieses Tool ermoglicht die
Entwicklung von Software in den Sprachen C und Assembler, allerdings erschwert die
kompliziertere Bedienung beim Erstellen von Programmen in C den Entstehungs-
prozess. 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.
Daruberhinaus enthalt das Programm eine Reihe von Simulatoren, mit denen der
Programmablauf auch ohne Hardware getestet werden kann (vgl. Abschnitt 3.2.3,
S. 19).
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.3 Struktur Seite 25
Nach dem Kompilieren und Verlinken der Software liegt das Programm im executa-
ble and linkable format (elf) vor. Diese Datei beinhaltet den benotigten Programm-
code und kann mit dem AVRStudio auf den µC ubertragen 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, prufen das
System auf Fehler (vgl. Kapitel 5, S. 36).
Das Hauptprogramm strukturiert sich in funf Bereiche:
• Initialisierung
• Betriebsbereitschaft
• Hauptroutine
• Synchronisation
• Fehlerbehandlung
Nach dem Programmstart werden wahrend der Initialisierung diverse Routinen
durchgefuhrt, um die Anlauftests und die Konfiguration des Systems vorzunehmen
(vgl. Abbildung 4.1). Sind diese abgearbeitet, verweilt das Programm in einer Schlei-
fe, 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 Betatigen des Joysticks
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.3 Struktur Seite 26
auf dem AVR Butterfly ausgelost werden kann. Wahrend der Wartezeit werden
zyklisch Selbsttests durchgefuhrt. Nach der Registrierung des Startsignals, beendet
das Programm die Warteschleife und geht in die Hauptroutine uber.
Da das Rechnersystem zur Laufzeit keine Eingange hat, auf die es reagieren muss,
wurde stattdessen ein Zahler implementiert, der in jedem Zyklus inkrementiert wird
und damit eine Prozedur simuliert, die das System zur Laufzeit durchfuhrt. Der
Zahler der Pseudo-Aktion reprasentiert dabei den Systemstatus. Abbildung 4.2 zeigt
die Struktur der Hauptroutine. Tabelle 4.3 zeigt die Ausgabe der LEDs zur Lauf-
zeit. Der gelb hinterlegte Pin stellt den definierten Ausgang der Steuerung dar, der
der zu steuernden Maschine signalisiert, dass kein Fehler vorliegt und der Betrieb
ausgefuhrt 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 uberfuhrt wer-
den soll. Daher wird in den implementierten Fehlerroutinen der definierte Ausgang
immer geloscht, wodurch das Signal von dem Pin verschwindet.
Abbildung 4.2: Struktur der Hauptroutine
Abbildung 4.3: Tabelle der Laufzeit-anzeige
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 moglich ist.
Durch den anschließenden Aufruf der Selbsttests wird in jedem Schleifendurchlauf
der Hauptroutine ein Selbsttest aufgerufen. In dem zu Evaluationszwecken entwi-
ckelten System ist diese Art der Testaufrufung einsetzbar, da keine langen Pro-
zessablaufe erwartet werden, so dass, trotz zyklischer Ausfuhrung, eine ausreichend
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.4 Konfigurationsmoglichkeiten Seite 27
hohe Testrate erwartet werden kann. In Systemen mit nicht linearen Programma-
blaufen, die auf externe Ereignisse reagieren mussen, ist diese Art der Testung unge-
eignet, da die Testrate stark von der aktuellen Last des Systems abhangt und gerade
zu kritischen Zeiten der Beanspruchung enorm sinken wurde. Mogliche Losungen fur
diese Probleme werden in Kapitel 5.3 (S. 54) vorgeschlagen.
4.4 Konfigurationsmoglichkeiten
Um das Programm flexibel aber gleichzeitig testbar zu halten, wurden verschiedene
Konfigurationsmoglichkeiten 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 konnen. Auch die Simulation ist nur in diesem Modus moglich, da Synchro-
nisation sowie Warteschleifen wahrend der Testphasen im Simulator nicht ausfuhrbar
sind.
Alternativ konnen auch Tests oder Synchronisation einzeln, durch entsprechende
Einstellungen im Quellcode, deaktiviert werden. Der regulare Programmablauf, wie
er auch in der Beobachtung des Verhaltens unter Umgebungseinflussen zum Einsatz
kam, fuhrt 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 Haufigkeit der Synchronisation kann uber die Variablen iSyncMod, die die An-
zahl 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 fur eine schnellere Datenverarbeitung sinnvoll, die Haufigkeit der Syn-
chronisationspunkte zu reduzieren. Dies bewirkt allerdings eine großere Abweichung
der Systeme untereinander und erhoht die Dauer, bis ein Fehler oder Ausfall des
anderen Systems erkannt wird.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.4 Konfigurationsmoglichkeiten Seite 28
Uber weitere Variablen kann die maximal zulassige Dauer der einzelnen Schleifen im
Programm, die Speicherzellen fur 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.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.4 Konfigurationsmoglichkeiten Seite 29
// −−− Kon f i gu r a t i on s e i n s t e l l ung en −−−char cStatus = 0 ; // cStatus = ak tue l l e n Status
// S t a r t s t a tu s andern
i n t iMaxStat = 255 ; // Maximaler Status 255
i n t iDelayMs = 10∗DELAY; // Warteze it Synchron i sa t ion in ms
// max : ˜30ms
i n t iMaxTimeMs = 20∗DELAY; // Ze i t S ch l e i f e ndu r ch l au f in ms
// max : ˜30ms
i n t iDebugFlag = 0 ; // 1 : Autostart
// 0 : S t a r t s i g n a l ( d e f au l t )
// Fur Simulator 1 e i n s e t z en
// −− WICHTIG: −−// DEBUG−MODUS: SYNCHRONISATION
// SELBSTTESTS DEAKTIVIERT!
i n t iTes tF lag = 1 ; // 1 : S e l b s t t e s t s ( d e f au l t )
// 0 : ke ine S e l b s t t e s t s
i n t iSyncFlag = 1 ; // 1 : Synchron i sa t ion ( d e f au l t )
// 0 : ke ine Synchron i sa t ion
i n t iSyncMod = 1 ; // S t a t u s s c h r i t t e zwischen Sync
// Minimum : 1
// Maximum : iMaxStat
i n t iOn = 0xFF ; // Lampen an / Port a l s Ausgang
i n t iO f f = 0x00 ; // Lampen aus / Port a l s Eingang
i n t iSecurePortD = ˜0x80 ; // 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 Spe i ch e r 1 = 0x00 ; // Sp e i c h e r z e l l e 1 d ek l a r i e r e n
i n t i Spe i ch e r 2 = 0x01 ; // Sp e i c h e r z e l l e 2 d ek l a r i e r e n
Quellcode 4.1: Konfigurationsmoglichkeiten der Software
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 30
4.5 Fehlerbeherrschende Maßnahmen
Damit das entwickelte Programm den Anforderungen an Software von sicherheits-
bezogenen Steuerungen entspricht, mussen Maßnahmen zur Erkennung und Beherr-
schung 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 geschutzt.
4.5.1 Synchronisation
Uber verschiedene Konfigurationsparamter kann im Programm eingestellt werden,
ob und wenn ja, wie haufig eine Synchronisation erfolgen soll.
Abbildung 4.5: Struktur der Synchronisationsroutine
Wahrend der Synchronisation - Struktur in Abbildung 4.5 - kommt es zu Wartezei-
ten, 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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 31
leichte Abweichungen voneinander haben. So kommt es zu unterschiedlichen Takt-
frequenzen, woraus eine Abweichung in der Arbeitsgeschwindigkeit resultiert. Kom-
pensierbar waren diese durch einen gemeinsamen Taktgeber, durch den jedoch die
Mehrkanaligkeit des Rechnersystems wegfallen wurde.
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 verfallt es in den Wartezustand, bis das
andere System ebenfalls Daten ubermittelt 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 uberschreitet, wird ein Timer
verwendet, der mit Hilfe der Konfigurationsvariablen iMaxTimeMs auf einen maxi-
malen 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
fur das Problem war, das andere System langer fur die Datenverarbeitung brauchte
oder die Nachricht aufgrund von Storungen der seriellen Schnittstelle nicht oder nur
verzogert ubertragenen wurden, ist dabei nicht erkennbar.
Vor der Ubermittlung von Daten wird eine Plausibilitatskontrolle, in der der zu
sendende Status auf zulassige Werte gepruft wird, durchgefuhrt.
Durch die Verwendung des kreuzweisen Vergleichs, werden fast alle Ubertragungs-
fehler (vgl. Abbildung 3.4, S. 18) erkannt und behandelt. Lediglich Verzogerungen
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 fuhrt. [Rei99]
Weiterhin wird mit der Synchronisation die Einfehlersicherheit gewahrleistet. Fallt
ein System aufgrund von Storungen aus oder produziert Fehler, so erkennt das ande-
re System dies zum nachsten Synchronisationszeitpunkt und lost eine Fehlerroutine
aus.
Ausschnitt 4.2 aus dem Programmcode zeigt den Quelltext der Synchronisation-
routine.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 32
515 /∗ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ∗/
516 /∗ −−−−− Synch ron i s a t i on s rou t in e −−−−−− ∗/
517 /∗ empfangt und sendet ak tu e l l e n Status ∗/
518 /∗ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ∗/
519 void doSync ( ) {520
521 // ak tue l l e n Status senden
522 i f ( cStatus <= iMaxStat ) {523 sendChar ( cStatus ) ;
524 }525 e l s e
526 stdError ( ) ;
527
528 // WD re s e t t en , damit n i cht au s l o s t
529 wdt re s e t ( ) ;
530
531 d e l a y l o op 2 (4000) ;
532
533 TCNT2 = 0 ;
534 OCR2A = iDelayMs ; // Ladt 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 ihn
537 TCCR2A = (1<<CS20) |(1<<CS22) |(1<<WGM21) ;
538
539 whi l e ( ! (UCSRA & (1<<RXC) ) ) ; // Daten empfangen?
540
541 cReceived = UDR; // Daten aus l e s en
542
543 i f ( cReceived != cStatus ) { // Vgl . empf . Daten & Status . .
544 syncError ( ) ; // . . Feh ler wenn ung l e i ch
545 }546
547 // Timer anhalten
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. Mogliche Fehler werden durch Vorkehrungen im Programm
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 33
erkannt und mit Hilfe entsprechender Fehlerroutinen, durch Ausgabe des Fehlercodes
und Uberfuhrung in den sicheren Zustand, behandelt.
Weiterhin wird ein eindeutiger Fehlercode in den Festwertspeicher des µCs ge-
schrieben. 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 fur den Watchdogalarm, fest definierte Fehler
behandelt. Diese werden im folgenden naher erlautert.
Synchronisationsfehler und -timer
Diese Routinen behandeln die Fehler, die bei der Synchronisation auftreten konnen.
Ausloser sind die in Abschnitt 4.5.1 (S. 30) genannten Umstande.
Watchdog
Nach einem, durch den Watchdog herbeigefuhrten, Systemreset wird diese Routine
ausgefuhrt, 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 mogliche Fehler werden in Kapitel 5 (S. 36) erklart.
Echtzeitverletzung
Mit dem Echtzeittimer wird uberpruft, ob ein Schleifendurchlauf des Hauptpro-
gramms - dargestellt in Abbildung 4.2 (S. 26) - die mittels der in Quellcode 4.1
(S. 29) vorgesehenen Variablen iMaxTimeMs eingestellte Zeit uberschreiten. Ist dies
der Fall, kann nicht mehr von der Echtzeitfahigkeit des Systems ausgegangen wer-
den. Dieser Fehler tritt auf, wenn durch unvorhergesehene Ereignisse wahrend der
Datenverarbeitung in der Hauptroutine der Zeitrahmen fur den Schleifendurchlauf
uberschritten wird.
Sonstige
Diese Routine dient fur alle weiteren Fehler und kommt im aktuellen Programmab-
lauf nur bei der Plausibilitatsprufung vor der Synchronisation zum Einsatz. Denkbar
ist es jedoch weitere, vorstellbare Fehler mit ihr abzudecken.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 34
Abbildung 4.6: Tabelle der Fehlercodes
Alle Routinen haben die gleiche Struktur, unterscheiden sich jedoch durch die ge-
speicherten und angezeigten Fehlercodes voneinander. Sie wurden trotzdem getrennt
implementiert, da auch unterschiedliche Reaktion auf verschiedene Fehler denkbar
waren. Ein Fehler der Kategorie”Sonstige“ muss beispielsweise nicht direkt zum
Ubergang in den sicheren Zustand fuhren, 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 visu-
elle Ausgabe der Fehlercodes auf den LEDs, in der der gelb hinterlegte Port den
definierten Ausgang zeigt. Im Fehlerfall ist dieser, ebenso wie im Betriebsbereit-
schaftsmodus, 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 andert.
Um solche Fehler zu entdecken, verfugt der µC uber einen Watchdog. Dieser funk-
tioniert nach dem Prinzip eines Weckers. Ist er einmal gestartet, zahlt er bis zu einer
gewissen Zahl und schlagt beim Erreichen Alarm. Der Alarm hat zur Folge, dass ein
Reset das System neu startet, um zum planmaßigem Programmablauf zuruck zu
kehren. Damit dies nicht geschieht, muss der Watchdog wahrend der Programmab-
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
4.5 Fehlerbeherrschende Maßnahmen Seite 35
laufs standig zuruck gesetzt werden. Dies muss so oft geschehen, dass der Watchdog
bei planmaßigem Ablauf keinen Alarm erzeugt. Wird der Ablauf gestort oder verlas-
sen, geschieht das Zurucksetzten des Watchdog nicht, wodurch ein Zahler ablauft,
was zu einem Reset fuhrt. [Schae08, S. 176ff]
Wahrend der Initialisierung wird uberpruft, ob ein Reset durch den Watchdog
statt gefunden hat. Ist dies der Fall wird uberpruft, ob der Reset beabsichtigt durch
die Testung des Watchdogs herbei gefuhrt 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
uberfuhrt und eine entsprechende Fehlermeldung ausgibt.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5 Selbsttests Seite 36
5 Selbsttests
Um die korrekte Verarbeitung der Daten durch den µC sicher zu stellen, wurden
diverse Selbsttests implementiert. Diese Tests konnen sowohl einzelne Befehle des
Befehlssatz, komplette Speicherbereiche als auch die angeschlossene Peripherie auf
ihre korrekte Funktion prufen. 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 zu-
geschnitten sind und sich dessen Befehlssatz stark von dem des ATMega169P un-
terscheidet, waren sie auf dem hier verwendeten µC nicht einsatzfahig. Trotzdem
dienten sie als Vorlage, indem sie sinn- und funktionsgemaß auf den Befehlssatz des
ATMEL µC ubertragen wurden.
Daruber hinaus mussten die umgesetzten Tests um einige Elemente erweitert wer-
den, damit sie zur Laufzeit des Systems ausgefuhrt werden konnen ohne den Pro-
grammablauf zu storen. Die Tests aus dem Report speichern keine Registerwerte vor
dem Testbeginn, so dass eventuell vorhandene Daten durch die verwendeten Test-
daten uberschrieben werden. Auf einem System im Produktiveinsatz wurde dies
zur Veranderung der Datenverarbeitung und des Programmablaufs fuhren, wodurch
selbst ein korrekt funktionierendes System nicht wie vorgesehen arbeiten wurde.
Daher mussen 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 durchgefuhrt werden. Ist dieser Initialtest positiv verlaufen, wird
das ausfuhrende Programm gestartet. Wahrend der Laufzeit werden zyklisch weitere
Tests aufgerufen, um den korrekten Ablauf zu prufen. Sowohl beim Initialtest als
auch zur Laufzeit fuhrt ein unerwartetes Ergebnis eines Selbsttests dazu, dass eine
Fehlerroutine ausgelost 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 fur eine Bearbei-
tung benotigen. Selbsttests sollen im Hintergrund laufen und den planmaßig vorge-
sehenen Arbeitsablauf nicht behindern. Aus diesem Grund ist es wichtig, die Tests
in moglichst kurzer Zeit durchfuhren zu konnen. [Klug97]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 37
5.1 CPU-Tests
Die grundlegendste Kategorie von Selbsttests ist die, die die Befehle des µC prufen.
Da es sich bei diesen Tests des Befehlssatzes um sehr hardwarenahe Programma-
blaufe handelt, wurden sie in Assembler verfasst. In einer Hochsprache wie C waren
der großere Teil dieser Tests nicht sinnvoll realisierbar, da auf Programmablaufe
und die verwendeten Befehle kein genauer Einfluss genommen werden kann. Die Art
der Ubersetzung des Programms von einer Hochsprache in die Maschinensprache
Assembler hangt stark vom eingesetzten Compiler und dessen Konfiguration ab.
Selbst wenn es moglich ware alle Tests in einer Hochsprache zu verfassen, so konn-
te im Fehlerfalle nicht die genaue Fehlerursache erkannt werden, da keine absolute
Gewissheit uber den Programmablauf auf Hardwareeben besteht.
Die implementierten Selbsttests fur das Instruction Set gliedern sich in sechs Grup-
pen:
• 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 verrat, die arithmeti-
schen Befehle des µCs getestet. Dazu gehoren Grundrechenarten wie das Addieren,
das Subtrahieren und das Multiplizieren von Zahlen aber auch spezielle Anweisun-
gen wie das In- und Dekrementieren von Registerinhalten. Die Division wird dabei
nicht mittels direktem Befehl durchgefuhrt und getestet, sondern durch eine Kom-
bination aus Subtraktion und Schiebe-Operationen ersetzt. Dies ist notig, da der
ATMega169P uber keine Hardware-Divisionseinheit verfugt. Trotzdem ist die Divi-
sion durch die Selbsttests abgedeckt, da sowohl die Subtraktion als arithmetischer
Befehl als auch die Schiebe-Operation als Bit-Operation durch Selbsttests gepruft
werden. Werden diese Tests ohne Probleme durchgefuhrt, kann davon ausgegangen
werden, dass auch eine Division einwandfrei funktionieren wird.
Anders als die anderen Tests des Befehlssatzes, konnten sie in einer Hochsprache
formuliert werden, wodurch sie auf andere Systeme portiert werden konnten. Da
diese Gruppe der Tests jedoch die einzige mit dieser Moglichkeit ist und durch
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 38
die Verwendung einer Hochsprache anderweitig Probleme auftreten wurden, wurde
davon abgesehen.
Addition
Bei diesem Test wird die korrekte Verarbeitung der Addition zweier Zahlen uber-
pruft, 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
ausgelost. Abbildung 5.1 zeigt den Programmablauf des ADD-Tests.
Abbildung 5.1: Programmablauf des Tests fur die Addition
1 ; ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ADD TEST ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ADD TEST:
3 PUSH R31 ; a l t e Reg i s t e rwer t e spe i che rn
4 PUSH R30
5 LDI R31 , 0xAA ; Testmuster 1 laden
6 LDI R30 , 0x55 ; Testmuster 2 laden
7 ADD R31 , R30 ; B e f e h l s t e s t
8 CPI R31 , 0xFF ; Verg l e i ch mit Erwartungshaltung
9 BRNE ADD err
10 JMP ARI END1
11
12 ADD err :
13 CALL te s tE r r o r
Quellcode 5.1: Selbsttest der Addition
Die Dauer des Selbsttests, dargestellten in Quellcode 5.1, betragt 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 weni-
ger als 212
µs. Zu beachten ist, dass dieser Test nicht nur zu Beginn des Programms,
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 39
sondern auch wahrend der Laufzeit ausgefuhrt wird. Daher mussen die Register-
werte gespeichert werden, bevor sie durch die Testwerte uberschrieben 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 ein-
gesetzten Befehl beschrankt.
Addition mit Beachtung des Carry-Flag
Ahnlich verlauft auch der Test des Befehls fur 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, uberschreitet. Ist dies
bei einer Addition der Fall, wird der Uberlauf, das sogenannte Carry-Flag gesetzt.
Somit kann das Ergebnis im hoheren Register angepasst werden, indem das Carry-
Flag mittels dem ADDC-Befehl bei der nachsten Addition mit berucksichtigt und
dazu addiert wird. Additionen deren Summe die Registerobergrenze uberschreiten,
mussen immer mit einer Kombination mehrere Register durchgefuhrt werden. In
der Regel werden dazu zwei 8 Bit Register zu einem 16 Bit Register verknupft.
Dabei stehen die unteren 8 Bit im Low- und die oberen 8 Bit im High-Register. Der
ADDC-Test - PAP in Abbildung 5.2 - pruft jedoch nur, ob das Carry-Flag bei einem
Uberlauf gesetzt wird und ob der Befehl das korrekte Ergebnis berechnet.
Abbildung 5.2: Programmablauf des ADDC-Tests
Weitere arithmetische Tests
Weiterhin wurden die Befehle fur die In- und Dekrementierung (INC und DEC) sowie
der Befehl fur die vorzeichenlose Multiplikation (MUL) auf ihre korrekte Funktion
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 40
gepruft. Das Prinzip hinter den Tests dieser Befehle ist das gleiche, wie bei den oben
aufgefuhrten Tests. Vorbereitete Testregister werden mit definierten Speicherwerten
geladen. Anschließend wird die zu testende Operation durchgefuhrt und das Ergebnis
mit dem erwarteten Wert verglichen.
5.1.2 Registertests
Wie in Abschnitt 3.1.1 (S. 15) erlautert, besitzt der ATMega169P 32 Arbeitregister,
die den klassischen Akkumulator ersetzen. Um die korrete Verarbeitung der Daten
in den Arbeitsregistern sicher zu stellen, mussen 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 fruher 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 betragt etwa funf µs. Das bedeutet, dass insgesamt
circa 150 µs benotigt werden, um alle 32 Arbeitsregister zu testen. Die genannte
Zeit bezieht sich nur auf die Selbsttests. Hinzu kommt noch die von der aufrufenden
Methode benotigte Zeit zum Starten des nachsten Tests.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 Verar-
beitung 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 konnen.
Der Stack ist beim ATMega169P so angelegt, dass er sein Ende an der hochsten
Speicheradresse hat und in tiefere Speicherbereiche wachst. Daher wird der Stack-
pointer beim Ablegen von Daten auf dem Stack dekrementiert und beim Lesen vom
Stack inkrementiert. Der RETURN-Befehl setzt den Programmzahler auf die Adres-
se, die auf dem Stack abgelegt ist. Er wird fur die Ruckkehr aus einer Interrupt-
oder Subroutine benutzt. Der letzte getestete Befehl ist der JUMP-Befehl. Dieser ist
nicht vom Stack abhangig. Er ahnelt jedoch dem RETURN-Befehl, da er auch den
Programmzahler 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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 42
Abbildung 5.4 zeigt den ersten Abschnitt des Tests, der die PUSH-Operation testet.
Die gelb eingefarbten Anweisungen stellen den Anfang des nachsten Testbereichs
dar. Im ersten Testbereich wird getestet, ob bei einem PUSH der Stackpointer kor-
rekt 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 uberpruft. 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
gepruft, ob der Befehl einen Wert korrekt vom Stack ausliest. Zu diesem Zweck
wird der im ersten Abschnitt des PPRJ-Tests auf Korrektheit geprufte Wert vom
Stack gelesen und mit dem Erwartungswert verglichen. Im zweiten Schritt wird die
Inkrementierung des Stackpointers uberpruft. Nach einem POP muss der Stackpointer
um Eins erhoht werden. Verglichen wird mit der im ersten Abschnitt genommenen
Stackpointerposition.
Abschnitt drei, dargestellt in Abbildung 5.6, testet abschließend den RETURN-
Befehl. 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, lauft 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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 zuruck-
kehrt. Wie beim RETURN-Befehl lauft das Programm in eine Fehlerroutine, falls die
JUMP-Operation versagt.
Bei einer mittleren Zeit von zwei Zyklen pro Befehl, betragt die Gesamtdauer des
PPRJ-Test etwa 125 Zyklen. Der ATMega169P fuhrt jedoch einen großen Teil seiner
Befehle in einem Zyklus aus, wodurch die tatsachliche Dauer des Tests unter diesem
Wert liegen wird. Bei exakt acht MHz wurde dieser Test weniger als 16 µs brauchen.
5.1.4 Test der logischen Operationen
Eine weitere Art von Operationen, die getestet werden mussen, sind die logischen
Operationen. Dazu gehoren die Befehle fur die UND-Verknupfung (AND), die ODER-
Verknupfung (OR) sowie das EXCLUSIVE ODER (EOR). Diese Operationen werden
benutzt, um Bits logisch miteinander zu verknupfen, was bei Embedded Systems
und der Programmierung von µC sehr oft fur die Zuweisung von Werten zu Register
und Speicherbereiche verwendet wird. Die Tests der logischen Operationen haben
eine sehr hohe Ahnlichkeit zu den arithmetischen Tests. Bei allen Tests werden vor-
her festgelegte Testwerte, meistens Schachbrettmuster - Werte deren Bits abwech-
selnd gesetzt sind - in verschiedene Register geladen. Danach werden diese Register
logisch miteinander verknupft und der erhaltene Wert mit einem Erwartungswert
verglichen. Abbildung 5.7 demonstriert einen moglichen Testablauf.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.1 CPU-Tests Seite 44
Abbildung 5.7: Programmablauf des Test der logischen AND-Verknupfung
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 gehoren folgende Befehle:
• Loschen (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 Um-
gang mit dem Carry-Flag. Wahrend die Schiebe-Operationen das Register nur um
eine Stelle nach links oder rechts schiebt und das erste, nun frei gewordene Bit
durch eine 0 erganzt wird, rotiert die Rotations-Operation das Register uber das
Carry-Flag. Dabei wird das Carry-Flag an der leer gewordenen Stelle eingefugt und
anschließend das uberstehende Bit in das Carry-Flag geschoben. Bei einer Schie-
beoperation wird das heraus geschobene Bit zwar auch im Carry-Flag gespeichert,
jedoch bei einer weiteren Verschiebung nicht wieder eingefugt. Die Registertests zei-
gen eine beispielhafte Verwendung fur das Carry-Flag bei einer Schiebe-Operation.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 45
1 ; ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ LSL TEST ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 LSL TEST :
3 PUSH R31 ; Reg i s t e rwer t e spe i che rn
4 LDI R31 , 0xAA ; Testmuster 1 laden
5 LSL R31 ; B e f e h l s t e s t
6 CPI R31 , 0x54 ; Verg l e i ch mit Erwartung . .
7 BRNE LSL err ; . . wenn ungle ich , Fehler
8 POP R31 ; Reg i s t e rwer t e wieder h e r s t e l l e n
9 RET
10
11 LSL err :
12 CALL te s tE r r o r ; Spr inge in Routine der Fehlermeldung
Quellcode 5.2: Selbsttest der bitweisen Verschiebung nach links
Beispiel 5.2 zeigt den Quellcode des Tests fur die bitweise Verschiebung nach links.
Sowohl beim Rotations- als auch beim Test der Schiebeoperation ist der Ausgangs-
wert 0xAA. Nach einer Ausfuhrung ist der Erwartungswert des LSL- sowie des
ROL-Befehls 0x54. Eine weitere Durchfuhrung der Befehle zeigt den Unterschied.
Wahrend das Ergebnis der LSL-Operation 0xA8 lautet, ist das Ergebnis der ROL-
Operation 0xA9, da die in der ersten Ausfuhrung uberstehende Eins in das Carry-
Flag verschoben wurde und nun wieder eingefugt wird.
5.1.6 Test der Transfer-Befehle
Um Werte aus dem Speicher auszulesen und in ein Register zu schreiben oder um Re-
gisterinhalte in andere Register zu kopieren, werden die Transfer-Befehle benotigt.
Die implementierten Selbsttests der Transfer-Befehle prufen die Befehle fur das di-
rekte 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 fur 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 gepruft.
5.2 Peripherie Tests
Neben dem Befehlssatz muss auch die Peripherie getestet werden. Damit ist zum
einen der Watchdog gemeint, der elementar fur den sicheren Betrieb eines Systems
ist. Zum anderen werden beide vorhandene Ports darauf getestet, ob sie ein Signal
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 46
Abbildung 5.8: Test des Befehls fur das indirekte Laden von Registern
fehlerfrei ausgeben bzw. einlesen konnen. Weiterhin konnen 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 wurde aber uber die mehrkanalige Struktur und die Synchronisation
aufgedeckt werden.
5.2.1 Watchdog
Um sicher zu gehen, dass diese Notfallmaßnahme voll funktionstuchtig ist, wird der
Watchdog wahrend des Systemstarts uberpruft. Dazu wird uberpruft, ob dieser nach
Ablauf der eingestellten Zeit einen Systemreset ausfuhrt. Geschieht dies nicht, ist
die Funktion des Watchdog gestort und das System wird uber die Fehlerroutine in
den sicheren Zustand uberfuhrt.
Wahrend bei allen Tests ein Anfang und ein Ende definiert ist - wenn kein Feh-
lerfall eintritt - so ist dies beim Test des Watchdog nicht moglich. Verlauft 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 Auswer-
tung des Tests benotigte Daten zuruckgreifen zu konnen, mussen diese in einem nicht
fluchtigen Speicher festgehalten werden. Der ATMega169P verfugt uber beschreib-
baren Festwertspeicher in Form von EEPROM. Jede Speicherzelle des EEPROM ist
nach einer gewissen Anzahl von Schreib/Losch-Zyklen nicht mehr funktionsfahig.
Diese Anzahl betragt beim ATMega169P mindestens 100.000 Zyklen [ATM08a, S.
22]; deshalb kann sie fur den eingesetzten Evaluationszweck vernachlassigt werden,
da wahrend einer Betriebsabfolge nur maximal ein Schreib/Losch-Zyklus pro Zelle
durchgefuhrt wird.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 47
Ist der Status gespeichert, kann nach einem Reset gepruft 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 uberfuhren soll. Quellcode
5.3 zeigt diese Routine.
65 iWDStatusFlag = eepromRead ( iWDSpeicher ) ;
66
67 // WD−Routine , wenn Systemreset durch WD
68 i f ( (MCUSR & (1 << WDRF) ) ) {69 MCUSR = 0 ;
70 wdt d i sab l e ( ) ;
71 i f ( iWDStatusFlag != 1) {72 wdError ( ) ;
73 }74 }75 // WD−Test , wenn Tests akt iv & vorher ke in WD−Test
76 i f ( iWDStatusFlag != 1 && iTestF lag ) {77 s t a r tTe s t (99) ;
78 }79 // sons t l o s ch e Watchdog−Flag und TestNr
80 e l s e i f ( iTestF lag ) {81 eepromWrite ( iWDSpeicher , 0) ;
82 iTe s tS ta t = 0 ;
83 }
Quellcode 5.3: Watchdog-Prufroutine am Programmbeginn
Der Watchdog-Test ist der einzige Selbsttest, der nicht zur Laufzeit ausgefuhrt
werden kann. Er wird daher zyklisch ausgefuhrt, 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 einges-
telklt wurde und somit diese Zeit bis zum Auslosen des Watchdogs gewartet werden
muss, ist auch die Dauer dieses Tests großer als 15 ms. Mit diesem Testverfahren ist
es nur moglich zu erkennen, ob der Watchdog nach der vorgegeben Wartezeit rea-
giert hat oder nicht. Ein verfruhtes oder verzogertes Reagieren kann nicht erkannt
werden, da eine Alarmmeldung vor Ablauf der 15 ms den Test positiv verlaufen las-
sen wurde, wahrend eine Verzogerung hierbei einem Ausfall gleich kommen wurde.
Die Ermittlung der exakten Laufzeit bis zu einem Reset des Watchdogs ist fast
unmoglich, da dazu zum einem der genaue Zeitpunkt des Resets festgehalten wer-
den musste und zum anderem eine Berechnung der Laufzeit, aufgrund getrennter
Oszillatoren fur das System und den Watchdog, nur schwer moglich ist.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 48
266 // Watchdog−Test rout ine
267 void WDTest( ) {268 eepromWrite ( iSpe i che r3 , 1) ; // WD−Test−Status => EEPROM
269
270 wdt enable (WDTO 15MS) ; // Watchdog au f z i ehen
271 d e l a y l o op 2 (5∗DelayMS) ; // Warten
272 d e l a y l o op 2 (5∗DelayMS) ;
273 d e l a y l o op 2 (5∗DelayMS) ;
274 d e l a y l o op 2 (5∗DelayMS) ; // ke in WD−Reset = Defekt
275
276 t e s tE r r o r ( ) ; // in Fehlermeldung spr ingen
277 }
Quellcode 5.4: Watchdog-Test
5.2.2 Tests der integrierten Timer
Timer werden - wie schon der Watchdog - zur Kontrolle des korrekten Programmab-
laufs genutzt. Um deren Funktionalitat zu verifizieren, wurden auch dafur Selbsttests
implementiert. Dieses Tests aktivieren die Timer fur eine definierte Zeit und verglei-
chen im Anschluss die Erwartungswerte mit den generierten Werten aus den Timer-
registern. Im Detail wird der Timer funfmal fur eine Dauer von einer ms aktiviert.
Stimmen im Anschluss die Testergebnisse mit den festgelegten Erwartungswerten
uberein, wird davon ausgegangen, dass die Timer wie erwartet arbeiten.
Da die Timer zum Teil kontinuierlich laufen und, ahnlich wie beim Watchdog, nur
zu bestimmten Zeiten eine Ruckstellung stattfindet, werden auch diese Tests nicht
zur Laufzeit durchgefuhrt. Stattdessen werden sie zu Beginn des Programms, noch
vor den Anlauftests, eingeleitet.
Abbildung 5.9 zeigt die Struktur der Tests. Alle Timer, unabhangig 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 Arbeits-
weise des Oszillators, kann die Laufzeitdauer der Warteschleife von dem erwarteten
Wert abweichen. Da aber sowohl die Warteschleife als auch der Timer von der Takt-
frequenz des µC abhangig sind, fuhrt dies nicht zu einem Fehler, solange diese Ein-
heiten korrekt Arbeiten. Aus diesem Grund kann mit diesem Test nicht festgestellt
werden, ob der Timer zeitlich exakt lauft, sondern nur ob dieser wie vorgesehen
abhangig von der Taktfrequenz seine Schritte ausfuhrt.
Der Watchdog dient zur zeitlichen Begrenzung, um auch bei einer Fehlfunktion
des Tests diesen zu terminieren. Eine Kontrolle der Laufzeitdauer erfolgt jedoch
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 49
Abbildung 5.9: Test der Timer auf korrekte Funktionsweise
nicht.
Eine fehlerhafte Taktfrequenz kann, je nach Auspragung der Ungenauigkeit, durch
die Synchroninsation erkannt werden.
5.2.3 RAM-Test
Der fluchtige Speicher (Random Access Memory, RAM) wird vorwiegend fur tem-
porare Speicherung von Daten genutzt. Da es sich um fluchtigen Speicher handelt,
gehen bei einem Spannungsverlust oder dem Neustart des Systems die zuvor gespei-
cherten Daten verloren.
Um bei der Verwendung des RAMs die Integritat der Daten zu gewahrleisten, wird
dessen Funktionalitat durch einen implementierten Selbsttest sichergestellt. Dieser
pruft die einzelnen Zellen des Speichers, indem Testwerte, die zuvor gespeichert
wurden, ausgelesen und mit Erwartungswerten verglichen werden. Verlauft dieser
Vergleich positiv, wird davon ausgegangen, dass diese Speicherzelle intakt ist.
Die Dauer des RAM-Tests hangt stark von Große und Art der Prufung ab. Im
Testsystem wurde dieser Test sinnvollerweise in mehrere Testdurchlaufe zerlegt, um
das System nicht ubermaß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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 50
Zelle befindliche Wert zwischen gespeichert um nach Abschluss des Tests wieder-
hergestellt werden zu konnen. Die Anzahl der getesteten Zellen kann dabei mithilfe
der Variable iRamTestLaenge aus der Testbibliothek variiert werden. Bei dem zy-
klischen Durchlauf ist diese fix - zehn Zellen -, kann jedoch bei anderen Arten der
Testaufrufung (vgl. Abschnitt 5.3, S. 5.3) variiert werden, um eine moglichst opti-
male 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 zwei-
te Routine aufgerufen wird, die den eigentlichen RAM-Test durchfuhrt.
193 // Routine f u r den e i n f a che r en RAM−Test
194 void Ram Test ( ) {195 // Prufen ob Prufrahmen uber Ramende hinaus
196 i f ( ( cErsteRamZelle + iTestLaenge ) > RamE) {197 // Wenn ja , b i s zum Ende prufen ,
198 unsigned i n t iTestLaengeTemp = ( cErsteRamZelle +
iTestLaenge ) − RamE;
199 Ram Check( cErsteRamZelle , RamE) ;
200 // Pointer auf Anfang s e t z t en
201 cErsteRamZelle = RamA;
202 // und r e s t l i c h e Ze l l e n pr u fen
203 Ram Check( cErsteRamZelle , ( cErsteRamZelle +
iTestLaengeTemp ) ) ;
204 }205 e l s e
206 // Ram Test durchf uhren .
207 Ram Check( cErsteRamZelle , ( cErsteRamZelle + iTestLaenge )
) ;
208
209 // Ramzelle auf n achste Z e l l e s e t z en
210 // ( f a l l s Ramende , dann auf Ramanfang )
211 cErsteRamZelle = cErsteRamZelle + 1 ;
212 i f ( cErsteRamZelle > RamE)
213 cErsteRamZelle = RamA;
214
215 }216
217
218 // e i g e n t l i c h e r Ram Test
219 void Ram Check( unsigned char ∗ cStartAddr , unsigned char ∗
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 51
cEndAddr )
220 {221 unsigned char cOr ig ina lByte ;
222 v o l a t i l e unsigned char ∗ cTestAddr ;
223
224 f o r ( cTestAddr = cStartAddr ; cTestAddr < cEndAddr ;
cTestAddr++ ) {225 cOr ig ina lByte = ∗cTestAddr ; // Orignalwert spe i che rn
226
227 ∗cTestAddr = 0x55 ; // Testwerte laden und
Prufen
228 i f ( ∗cTestAddr != 0x55 )
229 t e s tE r r o r ( ) ;
230
231 ∗cTestAddr = 0xAA;
232 i f ( ∗cTestAddr != 0xAA )
233 t e s tE r r o r ( ) ;
234
235 ∗cTestAddr = cOr ig ina lByte ; // Or ig ina lwer t
w i e d e r h e r s t e l l e n
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 fluchtiger, 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 Programma-
blauf im Worst-Case derartig verandern, dass eine gefahrliche Sitation eintritt.
Der Programmspeicher des ATMega169P ist als Flash-EEPROM realisiert, das,
wie auch der verbaute EEPROM, nur eine bestimmte Anzahl an Schreib-/Losch-
Zyklen verfugt in der die korrekte Beschreibung gewahrleistet ist (vgl. Abschnitt
3.1.1, S. 15). Gepruft wird der Programmspeicher, indem uber dessen Inhalt eine
Prufsumme mittels einer zyklische Redundanzprufung (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 Prufsumme die Polynomdivision. Hier-
bei werden die Nutzdaten Byteweise durch ein Generator-Polynom - x^16+x^12+x^5+1
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 52
beim CRC-CCITT-Verfahren - dividiert. Dies geschieht solange, bis alle Nutzdaten
abgearbeitet wurden, wobei immer der Rest einer einzelnen Berechnung mit dem
nachsten Byte verknupft wird. Der nach Abschluss der Division verbleibende Rest
ist die Prufsumme, die zur Prufung der Validitat der Daten genutzt wird
Beim ROM-Test wird eine aus dem Inhalt des Programmspeichers gebildete Prufsum-
me an einer festen Adresse im EEPROM abgelegt. Sie dient als Erwartungswert fur
den Algorithmus, der zur Laufzeit ebenfalls eine Prufsumme uber den Programm-
speicher bildet. Der Speicherinhalt wird dabei durch das gleiche Generator-Polynom
dividiert, das auch bei der Prufsummenbildung verwendet wurde, so dass bei korrek-
ter Speicherfunktion ein identischer Rest als Ergebnis verbleibt. Stimmt das errech-
nete Ergebnis des ROM-Tests mit dem vorher gebildeten Erwartungswert uberein,
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 eigent-
lichen Programms durch den ROM-Test auf ein vertretbares Maß reduzieren zu
konnen, wurde eine Durchfuhrung in mehreren kleinen Schritten vorgesehen. Dazu
kann anhand der Variable iFlashTestLaenge die Anzahl der pro Zyklus auszule-
senden Speicherzellen eingestellt werden. Nachdem der komplette Speicherbereich
ausgelesen wurde, findet der Vergleich mit der Erwarteten CRC-Prufsumme statt.
Weiterhin muss bei jeder Programmanderung ein neuer Erwartungswert berechnet
und in das EEPROM ubertragen werden, da selbst kleine Anderungen im Quellcode,
wozu auch Kommentare und Leerzeilen zahlen, den Inhalt des Programmspeichers
verandern.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.2 Peripherie Tests Seite 53
5.2.5 Ports als Ein- und Ausgange
Um Ein- und Ausgaben zu realisieren, benotigt ein µC Ports. Auf dem Butterfly-
board wird beispielsweise das verbaute LCD-Display uber verschiedene Ports ange-
steuert. Um die korrekte Funktionsweise der Ports zu gewahrleisten, mussen diese
getestet werden. Zu diesem Zweck mussen 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 prufen. Dabei ist zu beach-
ten, dass Ports, die vom Programm als Ausgange genutzt, auch als Ausgange im
Test gepruft werden. Dementsprechend mussen vorgesehene Eingange in den Test
als Eingange fungieren.
Der Aufbau des Systems in der zweiten Revision sah keine entsprechenden Vorkeh-
rungen vor, um beide Ports miteinander zu verbinden. Weitere Ports die zur Lauf-
zeit des Programms genutzt werden konnen, sind auf dem Butterfly nicht vorhanden,
wodurch es notwendig ist den Test außerhalb des regularen Programmablaufs durch-
zufuhren. Daher wurde Revision 3 mit entsprechenden Verschaltungsmoglichkeiten
realisiert (vgl. Abschnitt 3.3, S. 20).
Der Test beinhaltet zwei mogliche Testablaufe. Bei der ersten Moglichkeit, im
Quellcode 5.6 als Pruf-0-Test bezeichnet, wird an dem ausgehenden Port eine lau-
fende 0 angelegt. Das heißt, dass alle Pins, bis auf einen, auf 1 gesetzt werden.
Begonnen wird mit Pin 0. Anschließend wird gepruft, 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 Prufung wiederholt. Dies wird solange durchgefuhrt, bis alle Pins
einzeln durchgeschaltet wurden.
Die andere Moglichkeit - Pruf-1-Test - vertauscht die Zustande. Statt einer 0
wird eine laufende 1 angelegt. Beide Tests konnen einen feststeckenden (stuck-at)
Pin identifizieren. Sollte der ausgegeben Wert nicht mit dem zuruck gelesenen Wert
ubereinstimmen, so ist einer der beiden Ports defekt. Um jedoch heraus zu finden,
welcher der verwendeten Ports den Wert nicht korrekt ubermittelt hat, muss der
Test mit einem drittem Port zur Kontrolle wiederholt werden. Dies ist mit dem
Butterflyboard jedoch nicht moglich, da es nur zwei Ports zur weiteren Verarbei-
tung nach außen leitet. Fur das in der Arbeit beschriebene Testszenario genugt es,
den Fehlerfall zu erkennen, um das System in den sicheren Zustand zu uberfuhren.
151 // Methode um die Ports auf ko r r ek t e Funktion zu uberpr u fen
152 void PortTest ( ) {153 u i n t 8 t iPruefVar = 0 ; // Pruf−Var iab le
154 i n t iDDRB = DDRB; // Port−Zustande spe i che rn
155 i n t iDDRD = DDRD;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.3 Bibliothek der Tests Seite 54
156 i n t iPortB = PORTB;
157 i n t iPortD = PORTD;
158 DDRB = 0x00 ; // PortB a l s Eingang
159 DDRD = 0xFF ;
160 // PortD a l s Ausgang
161 // Pruf−0−Test
162 iPruefVar = ˜0x01 ; // Pruf−0 vor laden
163 PORTD = iPruefVar ;
164 f o r ( i n t i =0; i <=7; i++){165 i f (PINB != iPruefVar ) // Vgl . PortB und pruefVar
166 t e s tE r r o r ( ) ;
167 iPruefVar = ( iPruefVar <<1) | 0x01 ; // 0 sch i eben
168 PORTD = iPruefVar ;
169 }170
171 /∗172 // Pruf−1−Test
173 iPruefVar = 0x01 ; // Pruf−1 vor laden
174 PORTD = iPruefVar ;
175 f o r ( i n t i =0; i <=7; i++){176 i f (PINB != iPruefVar ) // Vgl . PortB und pruefVar
177 t e s tE r r o r ( ) ;
178 iPruefVar = ( iPruefVar << 1) ; // 1 sch i eben
179 PORTD = iPruefVar ;
180 }181 ∗/
182
183 // a l t e Zustande zuruck s e t z en
184 DDRB = iDDRB;
185 PORTB = iPortB ;
186 DDRD = iDDRD;
187 PORTD = iPortD ;
188 }
Quellcode 5.6: Porttest
5.3 Bibliothek der Tests
Alle implementierten Tests sind zu einer Bibliothek zusammen gefasst worden. Diese
Bibliothek kann in andere Projekte eingebunden werden, um sie um die Moglich-
keit der Selbsttests zu erweitern. Abbildung 5.11 zeigt die Struktur der Bibliothek.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.3 Bibliothek der Tests Seite 55
Sie stellt Variablen und Methoden bereit, um die Tests aufzurufen, setzt aber eine
implementierte Routine fur den Fehlerfall voraus.
Abbildung 5.11: Struktur der Test-Bibliothek
Die Variable iTestStat vom Typ int beinhaltet die Nummer des zuletzt ausgefuhr-
ten Selbsttests. In der Variablen iTestAnzahl steht die Nummer des hochsten, aus-
zufuhrenden Tests. Um die Tests der Reihe nach auszufuhren, genugt es, eine Schlei-
fe zu durchlaufen, die alle Selbsttests nacheinander aufruft, bis sie bei der hochsten
Nummer angekommen ist. Der Quellcode 5.7 ist ein Beispiel fur eine mogliche Im-
plementierung dieser Schleife.
505 /∗ −−− Se l b s t t e s t−Aufruf −−− ∗/
506 void doTest ( ) {507 s e l e c tTe s t ( ) ; // Testauswahl au f ru f en
508 iTes tS ta t++; // Zah ler erhohen
509 i f ( iTe s tS ta t > iTestAnzahl ) // IF Zah ler > Testanzahl . .
510 iTe s tS ta t = 0 ; // . . Z ah ler zuruck s e t z en
511 }
Quellcode 5.7: Beispiel: Aufruf der Selbsttests
Um einzelne Tests zu uberspringen, mussen diese uber bedingte Anweisungen -
IF-Anweisungen - abgefangen und umgangen werden. Sollen nur spezielle Tests
durchgefuhrt werden, kann mit der Methode startTest(int iTestNr) ein geziel-
ter Test aufgerufen werden. Dabei ist iTestNr durch die Nummer des gewunschten
Tests zu ersetzen:
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.3 Bibliothek der Tests 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 aus-
zufuhrenden Tests enthalt. Anschließend wird die Methode
startTest(int iTestNr) uber eine Schleife mit den Werten aus dem Array aufge-
rufen. Diese Technik hat den Vorteil, dass wichtigere Tests ofter durchgefuhrt werden
konnen, indem sie ofter in das Array eingetragen werden.
Auch denkbar ist eine Losung mittels Zeitscheibensystem. Der Aufruf ist in die-
sem Fall nicht an einen festen Punkt im Programmablauf gebunden, sondern wird
von einem Testmanager ubernommen, sobald eine freie Zeitscheibe verfugbar ist.
Vorteil dieser Methode ist, dass zu lastfreien Zeiten mehr Tests durchgefuhrt wer-
den konnen 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 fur Tests einplant. Nachteil dieser Methode ist der erhohte Aufwand in
der Erstellung des Systems und die Schwierigkeit nachzuvollziehen, wann genau ein
Test durchgefuhrt wird. [Klug97]
Um die Bibliothek in ein Projekt einbinden zu konnen, muss die Fehlerroutine
testError() definiert werden. Diese Routine wird aufgerufen, wenn ein Fehler bei
einem Selbsttest auftritt. Eine mogliche Implementierung dieser Methode zeigt der
Quellcodeauszug 5.8. Dabei wird uber die beiden Ports des AVR Butterfly die Feh-
lermeldung ausgegeben, wie sie in Abbildung 4.6 (S. 34) gezeigt ist. Außerdem wird
der Fehlercode im EEPROM gespeichert.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
5.3 Bibliothek der Tests Seite 57
416 /∗ −−− Feh l e r r ou t in 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 tE r r o r ( ) {418 c l i ( ) ; // In t e r rup t s d eak t i v i e r en
419 wdt d i sab l e ( ) ;
420
421 // I n i t i a l i s i e r e d i e Ports a l s Ausgang
422 // Fehlermeldung und ak t u e l l e S e l b s t t e s t n r ausgeben
423 DDRD = iSecurePortD ;
424 DDRB = 0xFF ;
425 PORTB = iTes tS ta t ;
426
427 eepromWrite ( iSpe i che r1 , 5) ; // Fehlerwert i n s Eeprom
428 eepromWrite ( iSpe i che r2 , iTe s tS ta t ) ;
429
430 whi l e (1 ) {431 // Setz t d i e LEDs an PORTD auf den Fehlercode−Anzeige
432 PORTD = (0 x55 & iSecurePortD ) ;
433 d e l a y l o op 2 (65535) ;
434 d e l a y l o op 2 (65535) ;
435 d e l a y l o op 2 (65535) ;
436 d e l a y l o op 2 (65535) ;
437 PORTD = ( iO f f & iSecurePortD ) ;
438 d e l a y l o op 2 (65535) ;
439 d e l a y l o op 2 (65535) ;
440 d e l a y l o op 2 (65535) ;
441 d e l a y l o op 2 (65535) ;
442 }443 }
Quellcode 5.8: Beispielhafte Implementierung der testError()
Diese Bibliothek kann in Projekten mit µC eingesetzt werden, die uber den gleichen
Befehlssatz und den gleichen technischen Aufbau verfugen wie der hier verwendete
ATMega169P. Stimmen die verwendeten Befehle nicht mit denen des neuen µC
uberein, so sind einzelne Tests bis hin zur ganzen Bibliothek nicht lauffahig. Um die
Tests auf Projekte mit einem absolut verschiedenen Controller zu ubertragen, ist es
notig, alle Tests einzeln zu konvertieren. Eine globale Implementierung der Tests, die
auf allen Prozessoren lauffahig 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 .
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6 Beobachtung des Verhaltens unter Umgebungsbedingungen Seite 58
6 Beobachtung des Verhaltens unter
Umgebungsbedingungen
Um die Frage zu klaren, ob homogene Redundanz die Wahrscheinlichkeit eines Aus-
falls infolge gemeinsamer Ursache erhoht, wird das System verschiedenen, extre-
men Umgebungseinflussen ausgesetzt. Dabei wird beobachtet, wie sich das System
bezuglich seines Ausfallverhaltens verhalt.
6.1 Ausgangssituation
Die Ausgangssituation fur die Versuche war ein Rechnersystem mit zwei unter-
schiedlichen Revisionen, die mit der erstellten, zyklisch die vorgesehenen Schritte
abarbeitende Software betrieben wurde. In der Software waren dabei die Standard-
einstellungen eingestellt, d.h. die Synchronisation sowie die Selbsttests waren aktiv
und alle weiteren Einstellungen auf einen festgelegten Wert eingestellt. Die Werte
konnen dem Quellcode 4.1 (S. 29) entnommen werden.
Dieser Aufbau wurde fur alle Untersuchungen verwendet. Kontrollprufungen ein-
zelner Versuche zeigten keinen Unterschied zwischen einem System aus zwei Kanalen
gleicher Revision oder aus einem mit zwei Kanalen 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 verandert. Zu
Beginn war kein fest definierter Ausgang vorgesehen. Uber die Anzeigen der LEDs
konnte der Status eindeutig erkannt werden. Um jedoch das Verhalten des Systems
an ein System der Kategorie 3 anzunahern, wurde ein Ausgang definiert. Dazu wurde
Pin 8 von Port D umfunktioniert. Im sicheren Zustand dient er als Eingang ohne
jedoch die internen Widerstande geschaltet zu haben. Das bedeutet, dass eine 0
anliegt, Low-Pegel. Im unsicheren Zustand ist er Ausgang und gibt eine 1 - High-
Pegel - aus.
Sollte einer der Versuche ein Bit zum Kippen bringen, wurde dies nicht ausrei-
chen, um den sicheren Zustand zu verlassen. Um in einen nicht sicheren Zustand
zu gelangen, mussten entweder das Bit fur die Porteinstellung und das Bit fur das
ausgegebene Signal kippen oder der Programmablauf so verandert werden, dass der
µC selber die Einstellung andert. Erst dann wurde im sicheren Zustand eine 1 am
definierten Ausgang anliegen.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 59
6.2 Elektromagnetische Vertraglichkeit
Jedes elektrische Gerat hat elektromagnetische (EM) Eigenschaften, die auf andere
Gerate in der Nahe wirken. Diese Auswirkungen konnen Storungen - Interferen-
zen - hervorrufen. Ein Gerat, das nicht hinreichend gegen diese Einflusse geschutzt
ist, kann durch diese Interferenzen gestort werden. Die elektromagnetische Ver-
traglichkeit (EMV) eines System setzt voraus, dass es zufriedenstellend in einer
EM-Umgebung funktioniert ohne dabei Storungen zu verursachen, die fur andere
Systeme unannehmbar waren. [Goed97, S.15]
Abbildung 6.1: Prinzip des Interferenzen-Problems[Goed97, S.19]
Auftretende Interferenzen konnen dabei durch unterschiedliche Emissionen der Gerate
auftreten. Die Art der Einwirkung, der Kopplungsweg, kann dabei variieren.
Die hier durchgefuhrten Untersuchungen der elektromagnetischen Vertraglichkeit
prufen die Moglichkeit zwei gleiche Systeme durch Beeinflussung in den unsicheren
Zustand zu bringen. Dazu wirken Storungen, wie sie in einer EM-Umgebung auftre-
ten konnen, uber verschiedene Kopplungswege auf das Rechnersystem ein. Um die
Versuche einfach zu halten, wurde das System nicht durch Filterschaltungen oder
spannungsbegrenzende Bauteile gegen Storungen geschirmt, wodurch es auch fur
geringe Storungen anfallig ist und somit ein”Worst-Case“-Szenario darstellt.
Eine genaue Analyse der Signale im System wurde nicht vorgenommen, da der
primare Beobachtungspunkt das Ausfallverhalten war. Es wurde lediglich gepruft,
ob durch Storungen ein unsicherer Ausfall reproduzierbar erreicht werden kann.
6.2.1 Kapazitive Kopplung
Kapazitive Kopplungen sind Storungen, die zwischen Leitern mit unterschiedlichem
Potential auftreten konnen. Sie sind meistens die Folge von unzureichend oder nicht
geschirmten Leitungen, konnen aber auch bei Verlegung von storungsbehafteten
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
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 60
weiteren wurden die Impulse noch uber die Versorgungsleitung und uber 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 aufein-
anderfolgenden, 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 betragt im Schnitt 130 V. Außer mit positiven
wurde auch mit negativen Impulsen gepruft. 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 uberpruft, wie empfindlich die serielle Schnittstelle
auf kapazitive Kopplungen reagiert. Dazu wurde direkt auf das verbindende Kabel
zwischen den zwei Kanalen eingekoppelt. Dieses Kabel ist ein, aus drei Adern be-
stehendes, ungeschirmtes Nullmodemkabel, weshalb die Storspannungen direkt auf
die Datenleitungen einkoppeln.
Der Versuch ergab, dass ein einmaliger, kurzfristiger Impuls nicht ausreicht, um
das System zu storen. Die entstehende Storspannung uberschreitet nicht den Wert,
um von der seriellen Schnittstelle als gekipptes Bit erkannt zu werden. Erst durch
eine Burst-Storung konnten die ubermittelten Daten beeinflusst und die Storung
des Systems erreicht werden. Je nach Art des Bursts, positiv oder negativ, trat
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 61
die Storung unmittelbar oder verzogert ein. Ein negativer Burst storte das System
innerhalb kurzer Zeit (2-3 Sekunden). Trifft ein negativer Impuls des Burst in eine
Ubertragung, kippen durch die Storspannung die High-Pegel auf Low-Pegel, wodurch
keine korrekte Synchronisation mehr moglich ist.
Ein positiver Burst erzeugte keine Storspannungen, die das System storen 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 Storung eines Bits.
Abbildung 6.3: Storung der Ubertragung durch gekipptes Bit
Die auftretende Storung wurde vom System uber Maßnahmen erkannt und behan-
delt, wodurch das System trotz Storung den sicheren Zustand erreichte.
Aufbau 1b - serielle Schnittstelle zu GND
Auch dieser Aufbau - Abbildung 6.4 - dient der Uberprufung der seriellen Schnittstel-
le. Anders als beim ersten Versuchsaufbau wurde hier das Potential des Storkreises
auf die Masse eines Kanals gelegt. Durch diese Anderung ergab sich eine Storung
auch schon durch einen einzelnen Impuls. Zuruck zu fuhren ist dies auf den geander-
ten Koppelweg und die daraus resultierende, starkere Storung. Bereits ein einzelner
Impuls erzeugt Storspannungen in einer Großenordnung, die zum Kippen eines Bits
auf der seriellen Schnittstelle ausreichen.
Trotzdem wurde die auftretende Storung erkannt und durch Uberfuhrung des
Systems in den sicheren Zustand behandelt.
Aufbau 2 - Versorgungsleitung
Ob eine kapazitive Einkopplung auf die Versorgungsleitung der Kanale einen Fehler
oder gar den unsicheren Ausfall provozieren kann, wurde durch den zweiten Ver-
suchsaufbau gepruft. Der Bezugspunkt des storenden Systems wurde, wie im vor-
hergehenden Versuch, auf die Masse eines Kanals gelegt, wahrend der positive Pol
auf den Leitungen vom Netzteil zu den Kanalen einkoppelte.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit 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 auslosten, wahrend positive Impulse oder Bursts keinen Einfluss
ausubten. Durch die negativen Impulse sank vermutlich die Versorgungsspannung
unter die von der EIA-232-Schnittstelle benotigten 3 V, wodurch eine Ubertragung
von Daten zur Synchronisation nicht mehr moglich war. Dadurch konnten keine 0 -
High-Pegel - mehr ubertragen werden und alle Bits wurden als 1 erkannt.
Trotz des Spannungsabfalls reichte die Restspannung zur korrekten Datenver-
arbeitung des µC. Daher werden die Fehler erkannt, wodurch das System in den
sicheren Zustand uberfuhrt wird. Ein unsicherer, gefahrbringender Ausfall ist nicht
eingetreten.
Aufbau 3 - Koppelplatte
Im letzten Versuch wird die Wirkung einer kapazitiven Kopplung auf das gesamte
System gepruft. Dazu wird mittels einer Platte, die sich in diesem Versuchsaufbau
unter den Systemen befindet, auf die komplette Flache der Kanale eingekoppelt. So
entstehende Storspannungen wirken auf alle Bauteilen und alle Leitungen und nicht
nur an einzelnen Punkten ein.
Das am starksten gestorte Element ist wiederum die empfindliche, gegen Storun-
gen nicht geschirmte, serielle Schnittstelle. Bei einer Storung mittels positiver oder
negativer Bursts wird daher ein Synchronisationsfehler erkannt, was zum sicheren
Abschalten des Systems fuhrt.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 63
6.2.2 Elektrostatische Entladung
Elektrostatische Entladungen (Elektotatic Discharge, ESD) sind Entladungen sta-
tischer Elektrizitat. Sie treten immer dann auf, wenn ein statisch geladener Korper
seine Ladung uber einen Funken oder einen Durchschlag auf ein leitendes Material
entladt. Diese Impulse haben eine sehr geringe Anstiegszeit, haufig unter einer Nano-
sekunde und eine maximale Dauer von 50 ns. Wahrend des Impuls fließen transiente
Strome, die magnetische und elektrische Felder erzeugen. Entladungen, die direkt
auf Bauteile gerichtet sind, konnen die Zerstorung dieses Bauteils durch Durchschlag
bewirken.
Die Aufladung vor einem ESD erfolgt bei der Trennung von zwei sich vorher
beruhrenden Materialien, von denen mindestens eines isolierende Eigenschaften be-
sitzt. [Schwa96] Die dabei entstehende Spannung ist von den Materialien und der
Luftfeuchtigkeit abhangig und kann bis zu 30 kV betragen. Meistens entsteht eine
ESD, wenn ein Mensch einen elektrischen Leiter, etwa einen geerdeten Gegenstand
aus Metall, beruhrt. Dabei kann es sich beispielsweise um Leitungen oder Verklei-
dungen von Geraten handeln. Abbildung 6.5 zeigt deutlich eine elektrostatische Ent-
ladung.
Abbildung 6.5: Sichtbare ESD-Entladung
Der im Versuch eingesetzt ESD-Generator erzeugte einen Impuls mit einer Span-
nung von annahernd 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 gestort. Eine direkte Einwirkung
auf den µC wurde nicht vorgenommen, da dies moglicherweise die Zerstorung des
Systems durch unzureichende EMV-Sicherung bedeuten konnte. Weiterhin ist es
nicht moglich den Impuls auf beide µC gleichzeitig zu geben, so dass der sichere
Zustand auch bei Komplettausfall des anderen Systems erreicht werden wurde. Ei-
ne Einwirkung dieser hochsynchronen Art wurde auch nicht den realen Storungen
entsprechen.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 64
Folgende Aufbauten wurden vorgenommen:
• kapazitive ESD-Einwirkung auf die Versorgungsleitungen
• kapazitive ESD-Einwirkung uber eine Koppelplatte
• direkte Einwirkung auf die EIA-232-Buchse
Die Untersuchungen ergaben, dass ein ESD das System dermaßen enorm stort, dass
ein Reset ausgelost wird. Der Angriffspunkt der einzelnen Aufbauten spielte dabei
keine Rolle. Egal ob uber kapazitive Kopplungen des Impulses oder durch direkte
Einspeisung auf den Bezugspunkt, die Reaktion war immer die gleiche.
Lediglich die Einkopplung uber die Koppelplatte fuhrte in einem Fall zu unter-
schiedlichen Reaktionen. Wahrend das eine System durch einen Reset zuruck gesetzt
wurde, zeigte das andere System den Ausfall seines Gegenubers an. Der sichere Zu-
stand wurde von beiden Systemen erreicht. Zu erklaren ist dies durch die verschie-
dene Einwirkung des ESD uber die Koppelplatte. Die Entfernung vom Punkt der
Einspeisung zur Flache 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 Ver-
haltens des Rechnersystems bei plotzlich ausfallender Versorgung. Dazu wurden bei-
de Systeme uber Leitungen, deren Aufbau und Lange gleich beschaffen sind, an ein
gemeinsames Netzteil angebunden. Dieses unterbrach die Versorgungsspannung in
festen Abstanden fur eine eingestellte Dauer. Diese Dauer wurde variiert, um zu
prufen, 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 fur diese kurze Dauer verursachte keinerlei Storung. In dieser
Zeit wird die Spannung von verbauten Kondensatoren stabilisiert.
Eine Unterbrechung uber 10 ms zeigte ebenfalls keinerlei Reaktion, erst ab 100
ms anderte sich das Verhalten. So wurde ab dieser Dauer ein Synchronisationsfeh-
ler erkannt. Wahrend der Unterbrechung sinkt die Spannung unter die benotigte
Betriebsspannung der EIA-232, womit keine eindeutigen High-Pegel mehr erzeugt
werden konnen. Fur den µC reicht die restliche Spannung aus, weshalb kein Re-
set durchgefuhrt wird. Dieser passiert erst ab etwa 200 ms Unterbrechungsdauer.
Nach einer Unterbrechung startet das System neu, verweilt nach dem Start aber im
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 65
Abbildung 6.6: Versuchsaufbau: Spannungsunterbrechung
sicheren Zustand.
Abbildung 6.7 zeigt den zeitlichen Verlauf der Spannung bei einer 10 ms dau-
ernden Unterbrechung. Wie der Abbildung entnommen werden kann, entspricht die
Rasterbreite 10 ms wahrend die Hohe jedes Kastens 2 V entspricht.
6.2.4 Austastung der Versorgungsspannung
Wie im Versuch zur Unterbrechung der Versorgungsspannung, wurde auch in die-
sem Versuchsaufbau die Versorgungsspannung der Kanale modifiziert. Mittels des
gleichen Aufbaus - Abbildung 6.6 - wurde auch dieser Versuch durchgefuhrt. Aller-
dings wurde die Spannung nicht komplett abgeschaltet, sondern lediglich bis in den
undefinierten Bereich reduziert. Um dies zu erreichen, wurde die Spannung fur eine
festgelegte Dauer auf 1 V gesenkt. Als Ausgangsspannung wurden 3,8 V genom-
men. Ein vorhergehender Versuch zeigte, dass mindestens 3,8 V benotigt werden,
um einen normalen Betrieb zu erreichen. Andernfalls reicht die Spannung nicht aus
um definierte High-Pegel auf der seriellen Schnittstelle erzeugen zu konnen. Dies
liegt daran, dass der Spannungsregler, obwohl es sich um ein Very Low Drop Mo-
dell handelt, 0,45 V Spannungsabfall erzeugt, womit die dem System tatsachlich zur
Verfugung stehende Spannung unter 3 V sinkt.
Ab einer Austastungsdauer von 100 ms pro Sekunde wurde ein Synchronisations-
fehler erkannt. Wahrend der Austastung sank die Versorgungsspannung unter die
benotigte Mindestspannung fur die Peripherie, so dass eine Kommunikation uber
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.2 Elektromagnetische Vertraglichkeit Seite 66
Abbildung 6.7: Zeitlicher Verlauf der Spannung
die serielle Schnittstelle nicht mehr moglich 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 durchfuhren. Nach diesem verblieb es, wie auch im vorher gehenden Versuch,
im sicheren Zustand. Weitere Erhohungen der Austastungsdauer fuhrten nur zu
langeren 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 EM-
Umgebung in der uberwiegenden Anzahl auf die relativ anfallige serielle Schnitt-
stelle aus. Diese Fehler werden erkannt, da zu diesem Zeitpunkt eine Storung des
µCs aufgrund seiner geringeren Anfalligkeit nicht vorliegt. Durch fehlerbehandeln-
de Maßnahmen reagieren die Kanale auf die Storungen, indem der sichere Zustand
eingeleitet wird.
Eine Storung, die auch den µC in seiner Arbeitsweise beeinflusst, ist indes nicht
aufgetreten. Wird eine bestimmte Intensitat der Storungen uberschritten, so fuhrte
das Rechnersystem einen Reset durch, wodurch das System ebenfalls in den sicheren
Zustand gelangte.
Daher ist anzunehmen, dass homogen redundante Systeme ebenso wenig fur Fehler
und Ausfalle infolge gemeinsamer Ursache anfallig sind wie ihre diversitare Pendants.
Solange in den SRP/CS Elemente vorhanden sind, die empfindlicher auf Storungen
reagieren als die steuernden Mikroelektronik, wird eine Storung diese als erstes be-
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.3 Temperaturbestandigkeit Seite 67
einflussen, wodurch fehlerbehandelnde Maßnahmen eingeleitet werden konnen.
Schirmungen oder andere, EMV verbessernde Maßnahmen konnen die Fehleranfallig-
keit einzelner Elemente reduzieren, wodurch die Fehleranfalligkeit von µC im Ver-
gleich zum restlichen System steigen kann. Im Falle einer Storung kann dann der
Controller das gestorte Element sein. Dass in diesem Fall homogene Redundanz
anders reagiert und dadurch haufiger oder leichter einen unsicheren Ausfall hervor-
ruft, kann jedoch nicht gefolgert werden. Bauteiltoleranzen und Unterschiede in den
Signalpfaden fuhren meistens dazu, dass keine exakt gleiche Arbeitsweise vorliegt.
Selbst mit identischer Hard- und Software unterscheidet sich die Arbeitsweise und
die Reaktionen auf Einflusse, wodurch auch auf Storungen unterschiedlich reagiert
wird.
Ein Beispiel dafur ist die ESD-Prufung uber die Koppelplatte. Obwohl beide Sys-
teme unter den gleichen Bedingungen betrieben wurden, ist nicht immer dieselbe
Storung erkannt worden.
6.3 Temperaturbestandigkeit
Neben den elektromagnetischen Storungen wirkt auf SRP/CS auch die Tempera-
tur des Standorts ein. Die Umgebungstemperatur kann die Funktionsweise eines
Systems dabei maßgeblich beeinflussen. Jedes elektronische System besteht zu ei-
nem Großteil, wenn nicht sogar ausschließlich, aus elektrischen Bauteilen, welche
ihr Verhalten unter wechselnden Bedingungen andern. Daher ist es wichtig zu wis-
sen, wie sich das Verhalten der einzelnen Elemente andert, um eine Aussage uber
die Funktionsweise des gesamten Systems unter Einfluss der Umgebungstemperatur
treffen zu konnen. Eine Schaltung besteht meistens aus einer Anzahl von Standard-
Komponenten wie Widerstanden, Kondensatoren und Transistoren. Diese verfugen
uber unterschiedliche Eigenschaften unter Temperaturwechseln.
Widerstande werden beispielsweise in zwei Kategorien unterteilt. Es gibt sie mit
positivem und negativem Temperaturkoeffizienten (α). Ein positiver Temperatur-
koeffizient bedeutet, dass sich der Widerstandswert bei steigenden Temperaturen
erhoht. Bei Widestanden mit negativem α verhalt es sich entsprechend umgekehrt.
Das Verhaltnis zwischen Temperatur- und Widerstandsanderung ist in den meisten
Fallen linear. Wird eine Kombination aus Widerstanden mit positiven und nega-
tiven Koeffizienten verwendet, kann das Maß der Widerstandsanderung teilweise
kompensiert werden. [Krue08, S. 237]
Auch Kondensatoren besitzen, wie Widerstande, einen Temperaturkoeffizienten.
Dieser hat Auswirkung auf die Kapazitat des Kondensators. Da die Produktion von
Kondensatoren aufgrund von Prozessmodellen jedoch hohen Toleranzen unterliegt,
kann die Veranderung der Kapazitat in den meisten Fallen vernachlassigt werden.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.3 Temperaturbestandigkeit Seite 68
Bei komplexen Filtern oder Schwingkreisen sind sie von Relevanz, in dem hier ein-
gesetzten System jedoch nicht.
Transistoren dienen in Schaltungen meistens zur Verstarkung von Stromflussen.
Eine Eigenschaft von Transistoren ist, dass bei hoheren Temperaturen ein großerer
Stromfluss moglich ist. Bis zu einem Punkt erhoht sich der Verstarkungsfaktor mit
dem Anstieg der Temperatur. Ist dieser Punkt erreicht, brennt das Bauteil durch.
Im Umkehrzug dagegen wird die Verstarkung bei niedrigen Temperaturen deutlich
geringer ausfallen.[Krue08, S. 236ff]
Diese Auswirkungen konnen auf das Rechnersystem ubertragen werden. Darum ist
das System in einer Klimakammer auf seine Temperaturbestandigkeit gepruft wor-
den. Ausgangstemperatur fur die Versuche war die Temperatur im Versuchsraum,
etwa 20°C. Die Moglichkeit 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, daruber hinaus erhitzt. Bis zur Obergrenze wurde in
Schritten von 10°C, anschließend jeweils um 5°C erhoht. Die Gesamtdauer des Ver-
suchs belief sich auf etwa 412
Stunden. Wahrend der ersten 60 Minuten wurde das
System von der Ausgangstemperatur bis zum Spezifikationslimit erhitzt. Anschlie-
ßend wurde es fur etwa eine halbe Stunde am Limit betrieben. In der restlichen Zeit
wurde die Temperatur etwa alle 30 Minuten um weitere funf Grad Celsius bis zur
Endtemperatur von 110°C erhoht. Auf diesem Level lief das System 30 Minuten.
Die Gesamtdauer des Betriebes uber dem Spezifikationslimit belauft sich damit auf
circa drei Stunden.
Abbildung 6.8: Schematischer Temperaturverlauf, positiver Temperaturbereich
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.3 Temperaturbestandigkeit 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 212
Stunden unter dem Limit bei -55°C und
-65°C betrieben.
Abbildung 6.9: Schematischer Temperaturverlauf, negativer Temperaturbereich
Nach dem Offnen der Ture zur Klimakammer gefror die eindringende Luftfeuchtig-
keit 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 Einflussen extremer Temperaturen zu be-
schreiben ist, mit den vorliegenden Resultaten, nur eingeschrankt moglich. Wahrend
der Versuche zeigten sich keine Probleme, jedoch stellen diese, auch wenn unter
verscharften Bedingungen durchgefuhrt, 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, lasst jedoch keine Aussage
daruber zu, wie das System bei einer Storung reagieren wurde. Hohere Belastungen
wurden die Bauteile des System zerstoren, nicht jedoch zu weiteren Erkenntnissen
fuhren. Derart intensive Uberschreitungen von Spezifikationsgrenzen wurden eine
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
6.3 Temperaturbestandigkeit Seite 70
unsachgemaße Entwicklung voraussetzen, was nicht den Anforderungen der DIN
EN ISO 13849-1 entsprechen wurde.
Um eine gultige Aussage uber das Verhalten des Rechnersystems unter langerfris-
tig einwirkenden Temperaturen treffen zu konnen, musste dieses uber einen langeren
Zeitraum unter moderaten Temperatureinflussen gepruft werden. Mogliche eintre-
tende Ausfalle mussten schließlich auf das Verhalten der Kanale und des erreichten
Zustandes - sicher oder unsicher - untersucht werden. Anschließend musste die Aus-
fallrate eines gefahrbringenden Ausfalls mit denen diversitarer Pendants verglichen
werden, um die Eignung von homogener Redundanz beurteilen zu konnen.
Da es sich bei dem hier verwendeten System um eine Art”Worst-Case“-Szenario
handelt, in dem kaum Maßnahmen gegen Umgebungseinflusse getroffen sind, kann
davon ausgegangen werden, dass das Verhalten dieses Systems deutlich starker aus-
gepragt ist, als dass eines der Norm entsprechenden Systems. Daher ist anzuneh-
men, dass die Ausfallwahrscheinlichkeit eines industriellen SRP/CS unter solchen
Einflussen geringer ist als das des gepruften Teils. Die Tatsache, dass selbst das
einfache System die Tests ohne Fehler absolviert hat, zeigt zumindest die Tendenz,
dass homogene Redundanz keine direkte Schwachstelle fur Temperaturempfindlich-
keit bedeutet.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
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 uber 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
Umgebungseinflussen darstellen konnen.
Die entwickelte Software sowie die implementieren Selbsttests beinhalten fehler-
behandelnde Maßnahmen. Weiterhin wird in der Software eine Pseudo-Aktion aus-
gefuhrt, wodurch eine Maschinensteuerung wie sie in der Industrie eingesetzt wird,
simuliert werden soll. Die Selbsttests sind zu einer Bibliothek zusammen gefasst
und konnen auf andere Projekte, mit einem µC mit gleichem Befehlssatz, ubertra-
gen werden.
Verschiedene Untersuchungen sollten Aufschlusse uber das Verhalten von homo-
gen redundanten Systemen unter Umgebungseinflussen geben. Hauptaugenmerk der
Untersuchungen war dabei die Frage, ob homogene Redundanz ein erhohtes Risiko
fur Ausfalle infolge gemeinsamer Ursachen birgt.
Wie die Ergebnisse der Untersuchungen zeigen, kann nicht pauschal gesagt wer-
den, dass ein homogen redundant aufgebautes Rechnersystem anfalliger fur Ausfalle
infolge gemeinsamer Ursache ist. Das entwickelte System hat, trotz homogener Red-
undanz, unter Einfluss diverser Storungen keine gefahrbringenden Ausfalle gezeigt.
Eine sicherheitsrelevante Architektur und passende Software zur Betreibung des Sys-
tem kann die Wahrscheinlichkeit der Ausfalle reduzieren. Da diese Anforderungen
von der Norm DIN EN ISO 13849-1 auch an homogen redundante SRP/CS ge-
stellt werden, kann bei konsequenter Umsetzung der Anforderung nicht von einem
erhohten Risiko ausgegangen werden.
7.2 Ausblick
Die durchgefuhrten Prufungen beschranken sich alle auf einen kurzen Zeitraum aus
einem speziell fur diese Untersuchungen entwickeltem System. Sie zeigen zwar, dass
unter kurzzeitigen Belastungen auch uber die Grenzen des Systems kein gefahr-
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
7.2 Ausblick Seite 72
bringender Ausfall stattfindet, konnen jedoch keine Aussage uber die langfristige
Zuverlassigkeit des Systems machen oder reprasentativ fur industrielle SRP/CS be-
trachtet werden.
Um das zu erreichen, kann das Projekt fortgefuhrt werden. Angedacht sind vollau-
tomatische Testablaufe, die selbststandig ausgewahlte Untersuchungen durchfuhren.
Da bei dieser Art der Prufung der manuelle Eingriff entfallt oder zu Kontrollzwe-
cken auf ein Minimum reduziert werden kann, kann der Ablauf beschleunigt und oh-
ne dauerhafte Aufsicht durchgefuhrt werden. Dies wurde eine fortlaufend steigende
Anzahl an Prufungen bedeuten und, je nach Lange des Projektes, auch verschiedene
Abschnitte des Lebenszyklus berucksichtigen.
Um die Ergebnisse der Untersuchungen zu validieren und auf andere Systeme zu
ubertragen, ist eine Untersuchung an einem oder mehrerer Systeme aus dem indus-
triellen Einsatz durchzufuhren. Das Verhalten eines Systems, das den Anforderungen
der Norm entspricht, ist reprasentativer fur eingesetzte SRP/CS als ein an die Norm
angelehntes System. Weiterhin muss durch die Untersuchungen eine Aussage uber
den gesamten Lebenszyklus des Systems getroffen werden konnen, um Parameter
wie Abnutzung und Alterung zu berucksichtigen. Zu diesem Zweck mussen die Be-
dingungen wahrend der Prufungen denen wahrend des realen Einsatzes entsprechen.
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Literaturverzeichnis Seite 73
Literaturverzeichnis
Fachliteratur
[BGIA06] BGIA Institut fur Arbeitsschutz der Deutschen Ge-setzlichen Unfallversicherung: Selbsttests fur Mikropro-zessoren 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 fur Arbeitsschutz der DeutschenGesetzlichen Unfallversicherung: Funktionale Sicherheitvon Maschinensteuerung. http://www.dguv.de/bgia/de/pub/
rep/pdf/rep07/biar0208/rep2_08.pdf, DGUV (Hrsg.), Report2, Februar 2008
[DIN07] DIN Deutsches Institut fur Normung e. V.: Sicherheitvon Maschinen - Sicherheitsbezogene Teile von Steuerungen - Teil1: Allgemeine Geltungsleitsatze. Beuth Verlag GmbH, Berlin 2007
[Fis92] Fischer, P.; Balzer G.; Lutz, M.: EMV - Storfestig-keitsprufungen. Franzis-Verlag GmbH & Co. KG, Munchen 1992
[Goed97] Goedbloed, J. J.: EMV - Elektromagnetische Vertraglichkeit.Pflaum Verlag GmbH, Munchen et. al. 1997
[Klug97] Klug, J.; Schaefer, M.: Sicherheitstechnisches Informations-und Arbeitsblatt 330 225, 29. Lfg. VII/97, 9 S., 14 Lit., Abb. In:BGIA-Handbuch Sicherheit und Gesundheitsschutz am Arbeits-platz. Hrsg.: Berufsgenossenschaftliches Institut fur Arbeitsschutz- BGIA. 2. Auflage. Erich Schmidt Verlag, Berlin 2003 - Loseblatt-Ausgabe.
[Krue08] Kruger, M.: Grundlagen der Kraftfahrzeugelektronik. Schal-tungstechnik. 2. neu bearbeitete Auflage, Carl Hanser Verlag,Munchen 2008
[Pard05] Pardue, J.: C Programming for Microcontrollers. Smiley Micros,Knoxville (USA) 2005
[Rei99] Reinert, D.; Meffert, K.: Mikroprozessoren in sicherheitskri-tischen 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 fur die Auto-mation, Huthig GmbH & Co. KG, Heidelberg 2001
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
Literaturverzeichnis Seite 74
[Schae08] Schaffer, F.: Hardware und C-Programmierung in der Praxis.elektor-Verlag, Aachen 2008
[Schwa96] Schwab, A. J.: Elektromagnetische Vertraglichkeit. 4. neu bear-beitete Auflage, Springer Verlag, Berlin et. al. 1996
Datenblatter
[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: Dezem-ber 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: Marz 2008
[@Ecr09] Ecros Technology: AVR Buttefly Carrier. http://www.
ecrostech.com/AtmelAvr/Butterfly/index.htm, Stand: Marz2009
[@WinAVR] WinAVR. http://winavr.sourceforge.net/, Stand: Marz2009
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A Quellcode Seite 75
A Quellcode
A.1 Quellcode Main-App.c
1 #inc lude ”Main−App . h”
2 #inc lude ”TestLib . h”
3
4 /∗ −−− Main−App v1 . 1 −− ∗/
5 /∗ Autor : Maxim Kupper ∗/
6
7 v o l a t i l e i n t iProgStatus = 0 ; // 0 = Programm noch n i cht
g e s t a r t e t
8 // 1 = Programm ge s t a r t e t , l a u f t
9 // −−−−−−−−−−−−−−−− WICHTIG:
−−−−−−−−−−−−−−−−−−−−−−−−−10 // v o l a t i l e , sons t andert s i c h
progs ta tus n i cht in der ISR !
11
12 char cStatus = 0 ; // cStatus b e i nha l t e t den
ak tue l l e n Status des Programmes
13 // wird zur Synchron i sa t ion ben o t i g t
14 i n t iMaxStat = 255 ; // Maximaler Status , da 8
mogl iche zust ande der LEDS
15
16
17 i n t iDelayMs = 10∗DELAY; // Warteze it zur
Synchron i sa t ion in ms ( n i cht 100% genau ,
18 // da Taktfrequenz s t a t t durch 1000 ( auf
kHz) durch 1024 g e t e i l t wurde )
19 // Maximum : ˜30ms
20
21 i n t iMaxTimeMs = 20∗DELAY; // Maximale Ze i t e i n e s
S ch l e i f e ndu r ch l au f s des Hauptprogramms
22 // Angabe in ms
23 // Maximum : ˜30ms
24
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 76
25 i n t iDebugFlag = 0 ; // 1 : Programm s t a r t e t
automatisch
26 // 0 : Programm wartet auf S t a r t s i g n a l
27 // S t a r t s i g n a l : Startknopf od .
ex t e rne s S t a r t s i g n a l
28 // Fur Simulator 1 e in s e t z en , dann wird
außerdem das Delay d e k a t i v i e r t !
29 // −−−−−−−−−−−−−−−− WICHTIG:
−−−−−−−−−−−−−−−−−−−−−−−−−30 // IM DEBUG−MODUS WERDEN DIE
SYNCHRONISATION
31 // UND DIE SELBSTTESTS DEAKTIVIERT!
32
33 i n t iTes tF lag = 1 ; // 1 : S e l b s t t e s t s werden
durchge f uhrt
34 // 0 : ke ine S e l b s t t e s t s
35
36 i n t iSyncFlag = 1 ; // Flag ob Synchron i sa t ion
durchge f uhrt werden s o l l
37 // 0 : d e a k t i v i e r t
38 // 1 : a k t i v i e r t
39
40 i n t iSyncMod = 10 ; // Anzahl der S ch r i t t e nach
welcher d i e Synchron i sa t ion durchge f uhrt 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 ek l a r i e r e n
45 i n t iO f f = 0x00 ; // a l l e Lampen aus / Port a l s
Eingang d ek l a r i e r e n
46
47
48 i n t iSecurePortD = ˜0x80 ;
49
50 i n t iWDStatusFlag ; // Status des Watchdog−Tests
51
52 char cReceived ;
53
54 i n t i Spe i ch e r 1 = 0x00 ; // Sp e i c h e r z e l l e 1
d ek l a r i e r e n
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 77
55 i n t i Spe i ch e r 2 = 0x01 ; // Sp e i c h e r z e l l e 2
d ek l a r i e r e n
56
57
58
59 /∗ −−− Hauptmethode −−− ∗/
60 i n t main ( void )
61 {62 iWDStatusFlag = eepromRead ( iWDSpeicher ) ;
63
64 // Watchdog−Routine , wenn Watchdog e inen Systemreset
durchge f uhrt hat
65 i f ( (MCUSR & (1 << WDRF) ) ) {66 MCUSR = 0 ;
67 wdt d i sab l e ( ) ;
68 i f ( iWDStatusFlag < 1 | | iWDStatusFlag > 4) {69 wdError ( ) ;
70 }71 // Wenn Timer0Test zu einem Reset ge f uh r t hat , Wird das
h i e r abgefangen
72 e l s e i f ( iWDStatusFlag == 2) {73 iTes tS ta t = 54 ;
74 t e s tE r r o r ( ) ;
75 }76 e l s e i f ( iWDStatusFlag == 3) {77 iTes tS ta t = 55 ;
78 t e s tE r r o r ( ) ;
79 }80 e l s e i f ( iWDStatusFlag == 4) {81 iTes tS ta t = 56 ;
82 t e s tE r r o r ( ) ;
83 }84 }85
86 // Wenn Tests a k t i v i e r t s ind
87 i f ( iTestF lag ) {88 // Ruft den Watchdog−Test auf wenn er noch n i cht
au fge ru f en wurde
89 i f ( iWDStatusFlag != 1) {90 s t a r tTe s t (99) ;
91 }
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 78
92 // sons t l o s ch e Watchdog−Flag
93 e l s e {94 eepromWrite ( iWDSpeicher , 0) ;
95 }96
97 // S ta r t e t d i e Timer−Tests
98 s t a r tTe s t (96) ; // Timer 0
99 s t a r tTe s t (97) ; // Timer 1
100 s t a r tTe s t (98) ; // Timer 2
101
102 // Loscht das TestStat−Flag f u r Ausgangss i tuat ion beim
Programmstart
103 iTe s tS ta t = 0 ;
104 }105
106 // Ruft d i e Methode zum Programmstart auf
107 programmInit ( ) ;
108
109 // Prufen ob Debugmodus ak t i v i e r t , wenn nein
Synchron i sa t ion s t a r t en und Tests durchf uhren
110 i f ( ! iDebugFlag ) {111 // Fa l l s Tests gewunscht werden
112 i f ( iTestF lag ) {113 // Beim Star t e inmal ig a l l e S e l b s t t e s t s durchf uhren
114 i n i tT e s t ( ) ;
115 }116 // Status−LEDs setzen , jenachdem ob Synchron i sa t ion
erwunscht oder n i cht
117 i f ( iSyncFlag ) {118 PORTD = iOn ;
119 }120 e l s e i f ( ! iSyncFlag ) {121 PORTD = 0x33 ;
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 // Fuhrt S e l b s t t e s t s der Reihe nach aus .
127 // Wartet auf ex t e rne s S i gna l ( Button−Aktion oder Start−S igna l )
128 whi l e ( iProgStatus != 1) {
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 79
129 doTest ( ) ; // Routine zur Testauswahl
au f ru f en
130 wdt re s e t ( ) ; // Watchdog zuruck s e t z en
131 i f ( (UCSRA & (1<<RXC) ) && iSyncFlag ) { // Pru f t ob
ex t e rne s S i gna l v o r l i e g t
132 i f (UDR == ’x ’ ) { // Im Fa l l e das ex t e rne s
S i gna l e in x i s t . .
133 programmStart ( ) ; // . . f uh re Programmstart
aus
134 }135 }136 }137
138
139 // −−− UNSICHERER ZUSTAND −−−140 // −− so lange Programm nicht in Feh l e r r ou t in e geht be f i nde t
es s i c h im uns i cheren Zustand −−141
142 /∗143 PORTD = iO f f ;
144 ∗/
145 DDRD = iOn ;
146 PORTD = ˜ iSecurePortD ;
147 DDRB = iOn ; // PortB a l s Ausgang s cha l t en
148 PORTB = iO 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 Echtze i t−Uberwachung
152 OCR0A = iMaxTimeMs ; // Ladt das
V e r g l e i c h s r e g i s t e r
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 ihn
154
155 // Hauptprogamm−End l o s s c h l e i f e
156 // wird nur durch e inen F e h l e r f a l l v e r l a s s e n
157 whi l e (1 ) {158
159 TCNT0 = 0 ; // Setz t den Timer auf 0
zuruck
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 80
160 // . . Wenn ja , Status zuruck auf 0
s e t z en
161
162 i f ( cStatus < iMaxStat ) // Pru f t ob der Status
den hochsten Wert e r r e i c h t hat . .
163 cStatus++; // . . wenn nein , Status
inkrement i e ren
164 e l s e
165 cStatus = 0 ;
166
167 PORTB = cStatus ; // Status uber d i e LEDs
ausgeben .
168
169 i f ( iSyncFlag & ( cStatus % iSyncMod == 0) ) { // Fa l l s
S yn c r on i s a t i o n s f l a g g e s e t z t . .
170 doSync ( ) ; // . . Sychron i sa t i on ausf uhren
171 }172
173 // f u r den Debug−Modus d i e Tests d eak t i v i e r en
174 i f ( iTestF lag ) {175 doTest ( ) ; // S e l b s t t e s t−Auswahl au f ru f en
176 }177
178 wdt re s e t ( ) ; // Watchdog zuruck s e t z en
179 }180 }181
182
183
184 /∗ −−−− Aufruf der I n i t i a l i s i e r u n g −−− ∗/
185 void programmInit ( void ) {186 // Wennn Autostart a k t i v i e r t i s t , s e t z e Progstatus auf 1
zum Starten des Programmes
187 i f ( iDebugFlag ) {188 iProgStatus = 1 ;
189 iSyncFlag = 0 ;
190 iTestF lag = 0 ;
191 }192
193 eepromOverwrite ( ) ;
194
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 81
195 // Ruft d i e I n i t i a l i s i e r ung sme thod e auf
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 ihn auf den
gewunschten Wert
199 // WDTO 60MS en t sp r i c h t 60mS
200 // WDTO 30MS en t sp r i c h t 30mS
201 // WDTO 1S en t sp r i c h t 1S
202 wdt enable (WDTO 60MS) ;
203 }204
205 /∗ −−− Routine zum Programmstart −−− ∗/
206 void programmStart ( void ) {207 iProgStatus = 1 ; // Programmstatus−Var iab le
auf 1 s t e l l e n
208 PCMSK1 = ˜PINB MASK; // Pin−Change−In t e r rup t
d eak t i v i e r en
209 EIMSK = (0<<7) ;
210 }211
212
213
214 /∗ −−− g l oba 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 rup t s
a k t i v i e r e n
221 TIMSK2 = (1<<OCIE2A) ;
222
223 i f ( ! iDebugFlag ) {224 // PortB−Pin 4 a l s Eingang s cha l t en & Pull−Up
Widerstande s cha l t en
225 DDRB = iO f f ;
226 PORTB = 0x10 ;
227
228 /∗229 // PortD−Pin a l s Ausgang f u r d i e Fehlermeldung s cha l t en
230 DDRD = iOn ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 82
231 PORTD = iO f f ;
232 ∗/
233 DDRD = iSecurePortD ;
234 PORTD = iSecurePortD ;
235
236 // Pin−Change−In t e r rup t f u r PortB scha l t en
237 PCMSK1 = PINB MASK;
238 EIMSK = (1<<7) ;
239 }240 }241
242 /∗ −−− Taster−Inte r rupt−Routine −−−−−− ∗/
243 SIGNAL(PCINT1 vect )
244 {245 PinChangeInterrupt ( ) ;
246 }247
248
249 /∗ −−− Ausfuhrende Routine der Taster−ISR −−− ∗/
250 void PinChangeInterrupt ( void )
251 {252 char cbuttons ;
253
254 cbuttons = (˜PINB) & PINB MASK;
255
256 // Output v i r t u a l keys
257 i f ( cbuttons & (1<<BUTTON O) ) { // Uberpru fe ob
gedr uckte Taste = Taster war
258 programmStart ( ) ; // wenn ja , programmstart
aus f uhren
259 i f ( iSyncFlag ) { // und f a l l s gewunscht dem
anderen System das S ta r t z e i ch en senden
260 sendChar ( ’ x ’ ) ;
261 }262 }263
264 EIFR = (0<<PCIF1) ; // Losche Pinchange−Inte r rupt−Flag
265 }266
267
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 83
268 /∗ −−− Daten senden −−− ∗/
269 void sendChar ( char data )
270 {271 // Darauf warten , dass das S ende 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 whi l e ( ! (UCSRA & (1<<UDRE) ) ) ;
273
274 // Daten i n s S ende r e g i s t e r sch i eben
275 UDR = data ;
276
277 // Warte darauf , dass Daten gesendet werden
278 whi 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 void 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 Empfanger
i n i t i a l i s i e r e n
287 UCSRB = (1<<RXEN) |(1<<TXEN) |(0<<RXCIE) |(0<<UDRIE) ;
288
289 // Asynchroner Modus mit 8 Bits , ke ine Par i ty und einem
Stop−Bit e i n s t e l l e n
290 UCSRC = (0<<UMSEL) |(0<<UPM0) |(0<<USBS) |(3<<UCSZ0) |(0<<
UCPOL) ;
291
292 // Baudratenwert ( Berechnung s i e h e Header ) dem Reg i s t e r
zuweisen
293 UBRRH = ( unsigned long )UBRR VAL>>8;
294 UBRRL = ( unsigned long )UBRR VAL;
295
296
297 // Enable i n t e r r up t s
298 s e i ( ) ;
299 }300
301
302 /∗ −−− Feh l e r r ou t in e f u r unbekannte Fehler −−− ∗/
303 void stdError ( ) {
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 84
304 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
305 wdt d i sab l e ( ) ; // Watchdog deak t i v i e r en
306
307
308 DDRB = iOn ; // Ports a l s Ausgang s cha l t en
309 //DDRD = iOn ;
310 DDRD = iSecurePortD ;
311
312 PORTB = iO f f ;
313
314 eepromWrite ( iSpe i che r1 , 6) ; // Fehlerwert i n s
Eeprom schre iben
315
316 whi l e (1 ) {317 // Fehlercode an PortD ausgeben . Fehlercode l au t Tabe l l e
318 PORTD = (0xAA & iSecurePortD ) ;
319 d e l a y l o op 2 (65535) ;
320 d e l a y l o op 2 (65535) ;
321 d e l a y l o op 2 (65535) ;
322 d e l a y l o op 2 (65535) ;
323 PORTD = ( iO f f & iSecurePortD ) ;
324 d e l a y l o op 2 (65535) ;
325 d e l a y l o op 2 (65535) ;
326 d e l a y l o op 2 (65535) ;
327 d e l a y l o op 2 (65535) ;
328 }329 }330
331 /∗ −−− Feh l e r r ou t in e f u r S yn ch r on i s a t i o n s f e h l e r −−− ∗/
332 void syncError ( ) {333 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
334 wdt d i sab l e ( ) ; // Watchdog deak t i v i e r en
335
336 eepromWrite ( iSpe i che r1 , 4) ; // Fehlerwert i n s
Eeprom schre iben
337 eepromWrite ( iSpe i che r2 , cStatus ) ;
338
339 DDRB = iOn ; // Ports a l s Ausgang s cha l t en
340 //DDRD = iOn ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 85
341 DDRD = iSecurePortD ;
342
343 PORTB = cStatus ;
344
345 whi l e (1 ) {346 // Fehlercode an PortD ausgeben . Fehlercode l au t Tabe l l e
347 PORTD = (0 x66 & iSecurePortD ) ;
348 d e l a y l o op 2 (65535) ;
349 d e l a y l o op 2 (65535) ;
350 d e l a y l o op 2 (65535) ;
351 d e l a y l o op 2 (65535) ;
352 PORTD = ( iO f f & iSecurePortD ) ;
353 d e l a y l o op 2 (65535) ;
354 d e l a y l o op 2 (65535) ;
355 d e l a y l o op 2 (65535) ;
356 d e l a y l o op 2 (65535) ;
357 }358 }359
360 /∗ −−− Feh l e r r ou t in e f u r Watchdog−Reset −−− ∗/
361 void wdError ( ) {362 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
363 wdt d i sab l e ( ) ; // Watchdog deak t i v i e r en
364
365 eepromWrite ( iSpe i che r1 , 3) ; // Fehlerwert i n s
Eeprom schre iben
366
367 DDRB = iOn ; // Ports a l s Ausgang s cha l t en
368 //DDRD = iOn ;
369 DDRD = iSecurePortD ;
370
371 PORTB = iSecurePortD ;
372
373 whi l e (1 ) {374 // Fehlercode an PortD ausgeben . Fehlercode l au t Tabe l l e
375 PORTD = (0 x99 & iSecurePortD ) ;
376 d e l a y l o op 2 (65535) ;
377 d e l a y l o op 2 (65535) ;
378 d e l a y l o op 2 (65535) ;
379 d e l a y l o op 2 (65535) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 86
380 PORTD = ( iO f f & iSecurePortD ) ;
381 d e l a y l o op 2 (65535) ;
382 d e l a y l o op 2 (65535) ;
383 d e l a y l o op 2 (65535) ;
384 d e l a y l o op 2 (65535) ;
385 }386 }387
388 /∗ −−− Feh l e r r ou t in 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 tE r r o r ( ) {390 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
391 wdt d i sab l e ( ) ;
392
393 // I n i t i a l i s i e r e d i e Ports a l s Ausgang und gebe
Fehlermeldung und ak t u e l l e S e l b s t t e s t n r . aus
394 DDRD = iSecurePortD ;
395 DDRB = 0xFF ;
396 PORTB = iTes tS ta t ;
397
398 eepromWrite ( iSpe i che r1 , 5) ; // Fehlerwert i n s
Eeprom schre iben
399 eepromWrite ( iSpe i che r2 , iTe s tS ta t ) ;
400
401 whi l e (1 ) {402 // Setz t d i e LEDs an PORTD auf den Fehlercode−Anzeige
403 PORTD = (0 x55 & iSecurePortD ) ;
404 d e l a y l o op 2 (65535) ;
405 d e l a y l o op 2 (65535) ;
406 d e l a y l o op 2 (65535) ;
407 d e l a y l o op 2 (65535) ;
408 PORTD = ( iO f f & iSecurePortD ) ;
409 d e l a y l o op 2 (65535) ;
410 d e l a y l o op 2 (65535) ;
411 d e l a y l o op 2 (65535) ;
412 d e l a y l o op 2 (65535) ;
413 }414 }415
416 /∗ −−− Feh l e r r ou t in e f u r den Fa l l e i n e s Au s f a l l s des anderen
Systems −−− ∗/
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 87
417 void aus fErro r ( ) {418 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
419 wdt d i sab l e ( ) ; // Watchdog deak t i v i e r en
420
421 eepromWrite ( iSpe i che r1 , 1) ; // Fehlerwert i n s
Eeprom schre iben
422 eepromWrite ( iSpe i che r2 , cStatus ) ;
423
424 DDRB = iOn ; // Ports a l s Ausgang s cha l t en
425 //DDRD = iOn ;
426 DDRD = iSecurePortD ;
427
428 PORTB = cStatus ;
429
430 whi l e (1 ) {431 // Fehlercode an PortD ausgeben . Fehlercode l au t Tabe l l e
432 PORTD = ( iOn & iSecurePortD ) ;
433 d e l a y l o op 2 (65535) ;
434 d e l a y l o op 2 (65535) ;
435 d e l a y l o op 2 (65535) ;
436 d e l a y l o op 2 (65535) ;
437 PORTD = ( iO f f & iSecurePortD ) ;
438 d e l a y l o op 2 (65535) ;
439 d e l a y l o op 2 (65535) ;
440 d e l a y l o op 2 (65535) ;
441 d e l a y l o op 2 (65535) ;
442 }443 }444
445 /∗ −−− Feh l e r r ou t in e f u r den Ablauf des Timers der
Haupt s ch l e i f e −−− ∗/
446 void z e i tE r r o r ( ) {447 c l i ( ) ; // Inte r rupt−Behandlungen
deak t i v i e r en
448 wdt d i sab l e ( ) ; // Watchdog deak t i v i e r en
449
450 eepromWrite ( iSpe i che r1 , 2 ) ; // Fehlerwert i n s
Eeprom schre iben
451 DDRB = iOn ; // Ports a l s Ausgang s cha l t en
452 //DDRD = iOn ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 88
453 DDRD = iSecurePortD ;
454
455 whi l e (1 ) {456 // Fehlercode an PortD ausgeben . Fehlercode l au t Tabe l l e
457 PORTD = ( iOn & iSecurePortD ) ;
458 PORTB = iOn ;
459 d e l a y l o op 2 (65535) ;
460 d e l a y l o op 2 (65535) ;
461 d e l a y l o op 2 (65535) ;
462 d e l a y l o op 2 (65535) ;
463 PORTD = ( iO f f & iSecurePortD ) ;
464 PORTB = iO f f ;
465 d e l a y l o op 2 (65535) ;
466 d e l a y l o op 2 (65535) ;
467 d e l a y l o op 2 (65535) ;
468 d e l a y l o op 2 (65535) ;
469 }470 }471
472
473 /∗ −−−− Se l b s t t e s t−Aufruf −−− ∗/
474 void doTest ( ) {475 s e l e c tTe s t ( ) ; // Methode zur Testauswahl
au f ru f en
476 iTes tS ta t++; // Zah ler erhohen
477 i f ( iTe s tS ta t > iTestAnzahl ) // Wenn Zah ler gr oße r
a l s Testanzahl . .
478 iTe s tS ta t = 0 ; // . . Z ah ler zuruck s e t z en
479 }480
481 /∗ −−− Synch ron i s a t i on s rou t in e −−− ∗/
482 /∗ −−− empfangt und sendet ak tu e l l e n Status −−− ∗/
483 void doSync ( ) {484
485 // ak tue l l e n Status senden
486 i f ( cStatus <= iMaxStat ) {487 sendChar ( cStatus ) ;
488 }489 e l s e
490 stdError ( ) ;
491
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 89
492 // Watchdog zuruck s e t z en um keinen Alarm beim Warten auf
Statusantwort zu sch lagen
493 wdt re s e t ( ) ;
494
495 d e l a y l o op 2 (4000) ;
496
497 TCNT2 = 0 ;
498 OCR2A = iDelayMs ; // Ladt das
V e r g l e i c h s r e g i s t e r
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 ihn
501
502 // S c h l e i f e zur uberpru fung ob Synchron i sa t ion
s ta t tge funden hat
503 whi l e ( ! (UCSRA & (1<<RXC) ) ) ; // Pru fe ob
Daten empfangen wurden
504
505 cReceived = UDR;
506
507 i f ( cReceived != cStatus ) { // Wenn Daten
empfangen mit aktue l lem Status v e r g l e i c h en
508 syncError ( ) ; // Bei ung l e i c hh e i t
Sy ch r on i t a t s v e r l u s t melden
509 }510
511 TCCR2A &= ˜((1<<CS20) |(1<<CS21) |(1<<CS22) ) ; // Timer
anhalten
512 }513
514 /∗ −−− Timer0−Inte r rupt−Routine −−− ∗/
515 SIGNAL(TIMER0 COMP vect)
516 {517 TCCR0A &= ˜((1<<CS00) |(1<<CS02) ) ;
518 z e i tE r r o r ( ) ;
519 }520
521 /∗ −−− Timer2−Inte r rupt−Routine −−− ∗/
522 SIGNAL(TIMER2 COMP vect)
523 {524 TCCR2A &= ˜((1<<CS20) |(1<<CS21) |(1<<CS22) ) ;
525 aus fErro r ( ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.1 Quellcode Main-App.c Seite 90
526 }527
528 /∗ −−− Funktion um in s EEEPROM zu schre iben −−− ∗/
529
530 void eepromWrite ( i n t iSpe i che r , i n t iE r ro r ) {531 eeprom wri te byte ( ( u i n t 8 t ∗) iSpe i che r , iE r r o r ) ;
532 }533
534 /∗ −−− Uber schre ibt d i e Sp 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 cht schon 0 s ind . −−− ∗/
536 void eepromOverwrite ( ) {537 i f ( eepromRead ( i Spe i ch e r 1 ) != 0) {538 eepromWrite ( iSpe i che r1 , 0) ;
539 }540
541 i f ( eepromRead ( i Spe i ch e r 2 ) != 0) {542 eepromWrite ( iSpe i che r2 , 0) ;
543 }544 }545
546 /∗ −−− Funktion um aus dem EEPROM zu l e s e n −−− ∗/
547 i n t eepromRead ( i n t i Sp e i c h e r ) {548 return eeprom read byte ( ( u i n t 8 t ∗) i Sp e i c h e r ) ;
549 }
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.2 Quellcode Main-App.h Seite 91
A.2 Quellcode Main-App.h
1 #inc lude <avr / i o . h>
2 #inc lude <avr / i n t e r r up t . h>
3 #inc lude <s t d l i b . h>
4 #inc lude <avr / s i g n a l . h>
5 #inc lude <s t d i o . h>
6 #inc lude <avr /wdt . h>
7 #inc lude <avr / de lay . h>
8 #inc lude <avr /eeprom . h>
9
10 #i f n d e f EEMEM
11 // a l l e Tex t s t e l l e n EEMEM im Quel lcode durch a t t r i b u t e
. . . e r s e t z en
12 #de f i n e EEMEM a t t r i b u t e ( ( s e c t i o n ( ” . eeprom” ) ) )
13 #end i f
14
15
16 #de f i n e BUTTON O 4 // Wenn Center gedr uckt wird
, wird PortB Pin4 g e s e t z t
17
18 #de f i n e PINB MASK (1<<PINB4)
19
20 #de f i n e FOSC 8000000UL // Taktfrequenz in Hz
21 #de f i n e BAUD 38400UL // Baud−Rate in Bi t s pro
Sekunde
22 #de f i n e UBRR VAL FOSC/16/BAUD−1 // Berechnung des Wertes
f u r das Reg i s t e r UBBR (16 Bit−Reg i s t e r )
23
24 #de f i n e DELAY FOSC/1000/1024 // Umrechnungswert f u r
Delayfunkt ion
25
26
27 void i n i t i a l i z e r ( void ) ;
28 void USARTinit ( void ) ;
29 char i sCharAva i l ab l e ( void ) ;
30 char rece iveChar ( void ) ;
31 void sendChar ( char ) ;
32 void sendStr ing ( char ∗) ;
33 void programmInit ( void ) ;
34 void programmStart ( void ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.2 Quellcode Main-App.h Seite 92
35 void statusSenden ( void ) ;
36 void parseInput ( char ∗) ;
37 void PinChangeInterrupt ( void ) ;
38 void stdError ( void ) ;
39 void syncError ( void ) ;
40 void aus fErro r ( void ) ;
41 void z e i tE r r o r ( void ) ;
42 void t e s tE r r o r ( void ) ;
43 void wdError ( void ) ;
44 void doTest ( void ) ;
45 void doSync ( void ) ;
46 void getSync ( void ) ;
47 void eepromWrite ( int , i n t ) ;
48 void eepromOverwrite ( void ) ;
49 i n t eepromRead ( i n t ) ;
50 // void CRCSet( void ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 93
A.3 Quellcode TestLib.c
1 #inc lude ”TestLib . h”
2 #inc lude ”Main−App . h”
3
4 // 0 − 31 : R e g i s t e r t e s t s
5 // 32 : Push−Pop−Return−Jump−Test
6 // 33 − 38 : Ar i thmet i sche Tests
7 // 39 − 45 : Tests der l o g i s c h en Bi toperat ionen
8 // 46 − 48 : Tests der l o g i s c h en Operationen
9 // 49 − 52 : Tests der Transfer−Befeh l e
10 // 53 : RAM−Test
11 // 54 : Flash−Test
12 // 55 : Port−Test
13 // 96 − 98 : Timer−Tests
14 // 99 : Watchdog−Test
15
16 i n t iTestAnzahl = 54 ; // Die Anzahl der z yk l i s c h zu
durchlaufenden Tests
17 i n t iTe s tS ta t = 0 ; // Der a k t u e l l ausgewahlte
s e l b s t t e s t
18
19 i n t iWDSpeicher = 0x02 ; // Sp e i c h e r z e l l e 3 d ek l a r i e r e n
20
21
22 // Var iab le b e i nha l t e t d i e e r s t e zu te s t ende Ramzelle
23 unsigned char ∗ cErsteRamZelle = ( unsigned char ∗) 0x0100 ;
24 // Anzahl der zu tes tenden Ramzellen pro Zyklus
25 unsigned i n t iRamTestLaenge = 10 ;
26 // Anfang und Ende vom Ram
27 unsigned char ∗RamA = ( unsigned char ∗) 0x0100 ;
28 unsigned char ∗RamE = ( unsigned char ∗) 0x04FF ;
29
30
31 // Ze ige r auf a k t u e l l e Pos i t i on des F l a sh spe i ch e r s
32 unsigned char ∗ cF la shZe ige r = ( unsigned char ∗) 0x0000 ;
33 // Anzahl der zu tes tenden F l a s h z e l l e n pro Zyklus
34 unsigned i n t iFlashTestLaenge = 10 ;
35 // a k t u e l l e r CRC−Wert
36 unsigned i n t iCRC ;
37 // e rwar t e t e r CRC−Wert
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 94
38 unsigned i n t iCRCCheck ;
39 // Anfang und Ende der CRC−Berechnung des Flash−Spe i che r s
40 unsigned char ∗FlashA = ( unsigned char ∗) 0x0000 ;
41 unsigned char ∗FlashE = ( unsigned char ∗) 0x3FFC ;
42
43
44 void s e l e c tTe s t ( ) {45 s t a r tTe s t ( iTe s tS ta t ) ;
46 }47
48 // f uh r t den Gewahlten Test aus !
49 void s t a r tTe s t ( i n t iTestNr ) {50 iTes tS ta t = iTestNr ;
51 switch ( iTestNr ) {52
53 // Re g i s t e r t e s t s
54 case 0 : TEST R0( ) ; break ;
55 case 1 : TEST R1( ) ; break ;
56 case 2 : TEST R2( ) ; break ;
57 case 3 : TEST R3( ) ; break ;
58 case 4 : TEST R4( ) ; break ;
59 case 5 : TEST R5( ) ; break ;
60 case 6 : TEST R6( ) ; break ;
61 case 7 : TEST R7( ) ; break ;
62 case 8 : TEST R8( ) ; break ;
63 case 9 : TEST R9( ) ; break ;
64 case 10 : TEST R10 ( ) ; break ;
65 case 11 : TEST R11 ( ) ; break ;
66 case 12 : TEST R12 ( ) ; break ;
67 case 13 : TEST R13 ( ) ; break ;
68 case 14 : TEST R14 ( ) ; break ;
69 case 15 : TEST R15 ( ) ; break ;
70 case 16 : TEST R16 ( ) ; break ;
71 case 17 : TEST R17 ( ) ; break ;
72 case 18 : TEST R18 ( ) ; break ;
73 case 19 : TEST R19 ( ) ; break ;
74 case 20 : TEST R20 ( ) ; break ;
75 case 21 : TEST R21 ( ) ; break ;
76 case 22 : TEST R22 ( ) ; break ;
77 case 23 : TEST R23 ( ) ; break ;
78 case 24 : TEST R24 ( ) ; break ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 95
79 case 25 : TEST R25 ( ) ; break ;
80 case 26 : TEST R26 ( ) ; break ;
81 case 27 : TEST R27 ( ) ; break ;
82 case 28 : TEST R28 ( ) ; break ;
83 case 29 : TEST R29 ( ) ; break ;
84 case 30 : TEST R30 ( ) ; break ;
85 case 31 : TEST R31 ( ) ; break ;
86
87 // Push−Pop−Ret−Test
88 case 32 : PPRJ TEST( ) ; break ;
89
90 // Ar i thmet i sche Tests
91 case 33 : ADD TEST( ) ; break ;
92 case 34 : ADDC TEST( ) ; break ;
93 case 35 : SUB TEST( ) ; break ;
94 case 36 : INC TEST( ) ; break ;
95 case 37 : DEC TEST( ) ; break ;
96 case 38 : MUL TEST( ) ; break ;
97
98 // Tests der l o g i s ch en Bi toperat i onen
99 case 39 : CLR TEST( ) ; break ;
100 case 40 : COM TEST( ) ; break ;
101 case 41 : LSL TEST( ) ; break ;
102 case 42 : LSR TEST( ) ; break ;
103 case 43 : ROL TEST( ) ; break ;
104 case 44 : ROR TEST( ) ; break ;
105 case 45 : SWAP TEST( ) ; break ;
106
107 // Tests der l o g i s ch en Operationen
108 case 46 : AND TEST( ) ; break ;
109 case 47 : OR TEST( ) ; break ;
110 case 48 : EOR TEST( ) ; break ;
111
112 // Tests der Transfer−Befeh l e
113 case 49 : mov test ( ) ; break ;
114 case 50 : movw test ( ) ; break ;
115 case 51 : l d i t e s t ( ) ; break ;
116 case 52 : l d t e s t ( ) ; break ;
117
118 // Test des Rams
119 case 53 : Ram Test ( ) ; break ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 96
120
121 // Test des Flashroms
122 case 54 : Flash Test ( ) ; break ;
123
124 // Port−Test
125 case 55 : PortTest ( ) ; break ;
126
127 // Tests der Timer
128 case 96 : Timer0Test ( ) ; break ;
129 case 97 : Timer1Test ( ) ; break ;
130 case 98 : Timer2Test ( ) ; break ;
131
132 // Watchdog−Test
133 case 99 : WDTest( ) ; break ;
134
135 // Sons t i g e s
136 d e f au l t : s tdError ( ) ; break ;
137 }138 }139
140 // f uh r t a l l e vorhanden Se l fT e s t s aus
141 // Bsp . f u r Start uberpr u fung !
142 void i n i tT e s t ( ) {143 whi l e ( iTe s tS ta t <= iTestAnzahl ) {144 s e l e c tTe s t ( ) ;
145 iTe s tS ta t++;
146 }147 iTes tS ta t = 0 ;
148 }149
150
151 // Methode um die Ports auf ko r r ek t e Funktion zu uberpr u fen
152 void PortTest ( ) {153 u i n t 8 t iPruefVar = 0 ; // Pruf−Var iab le
154 i n t iDDRB = DDRB; // Wert der a l t en Port−Zustande spe i che rn
155 i n t iDDRD = DDRD;
156 i n t iPortB = PORTB;
157 i n t iPortD = PORTD;
158
159 DDRB = 0x00 ; // PortB a l s Eingang
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 97
160 DDRD = 0xFF ; // PortD a l s Ausgang
161
162 // Pruf−0−Test
163 iPruefVar = ˜0x01 ; // Pruf−0 vor laden
164 PORTD = iPruefVar ;
165 f o r ( i n t i =0; i <=7; i++){166 i f (PINB != iPruefVar ) // Verg l e i chen von PortB
und pruefVar und f a l l s n ot ig ,
167 t e s tE r r o r ( ) ; // in Fehlermeldung spr ingen
168 iPruefVar = ( iPruefVar <<1) | 0x01 ; // 0 sch i eben
169 PORTD = iPruefVar ;
170 }171
172 // Pruf−1−Test
173 /∗174 iPruefVar = 0x01 ; // Pruf−1 vor laden
175 PORTD = iPruefVar ;
176 f o r ( i n t i =0; i <=7; i++){177 i f (PINB != iPruefVar ) // Verg l e i chen von PortB
und pruefVar und f a l l s n ot ig ,
178 t e s tE r r o r ( ) ; // in Fehlermeldung spr ingen
179 iPruefVar = ( iPruefVar << 1) ; // 1 sch i eben
180 PORTD = iPruefVar ;
181 }182 ∗/
183
184 // a l t e Zustande zuruck s e t z en
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 che r en RAM−Test
194 void Ram Test ( ) {195 i f ( ( cErsteRamZelle + iRamTestLaenge ) > RamE) { // Prufen
ob Prufrahmen uber Ramende hinaus
196 unsigned i n t iRamTestLaengeTemp = ( cErsteRamZelle +
iRamTestLaenge ) − RamE;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 98
197 Ram Check( cErsteRamZelle , RamE) ; // Wenn ja , b i s
zum Ende pr u fen und
198 cErsteRamZelle = RamA; // Pointer auf Anfang
s e t z t en
199 Ram Check( cErsteRamZelle , ( cErsteRamZelle +
iRamTestLaengeTemp ) ) ;
200 }201 e l s e
202 // Ram Test durchf uhren .
203 Ram Check( cErsteRamZelle , ( cErsteRamZelle +
iRamTestLaenge ) ) ;
204
205 // Ramzelle auf n achste Z e l l e s e t z en ( f a l l s Ramende , dann
auf Ramanfang )
206 cErsteRamZelle = cErsteRamZelle + 1 ;
207 i f ( cErsteRamZelle > RamE)
208 cErsteRamZelle = RamA;
209
210 }211
212 // e i g e n t l i c h e r Ram Test
213 void Ram Check( unsigned char ∗ cStartAddr , unsigned char ∗cEndAddr )
214 {215 unsigned char cOr ig ina lByte ;
216 v o l a t i l e unsigned char ∗ cTestAddr ;
217
218 f o r ( cTestAddr = cStartAddr ; cTestAddr < cEndAddr ;
cTestAddr++ ) {219 cOr ig ina lByte = ∗cTestAddr ;
220
221 ∗cTestAddr = 0x55 ;
222 i f ( ∗cTestAddr != 0x55 )
223 t e s tE r r o r ( ) ;
224
225 ∗cTestAddr = 0xAA;
226 i f ( ∗cTestAddr != 0xAA )
227 t e s tE r r o r ( ) ;
228
229 ∗cTestAddr = cOr ig ina lByte ;
230 }
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 99
231 }232
233 // Test des Flash−Spe i che r s
234 void Flash Test ( ) {235 i f ( ( cF la shZe ige r + iFlashTestLaenge ) >= FlashE ) {236 unsigned i n t iFlashTestLaengeTemp = ( cF la shZe ige r +
iFlashTestLaenge ) − FlashE ;
237 f o r ( i n t i = 0 ; i <= iFlashTestLaengeTemp ; i++){238 // i f ( ( i n t ) cF la shZe ige r != 0x041B | | ( i n t ) cF la shZe ige r
!= 0x0428 )
239 iCRC = c r c c c i t t u p d a t e (iCRC, pgm read byte (
cF la shZe ige r++)) ;
240 // e l s e
241 // cF la shZe ige r++;
242 }243 // Prufen ob e rm i t t e l t e CRC mit e rwar t e t e r Ubereinstimmt
244 iCRCCheck = ( eepromReadFrom (8)<<8) | eepromReadFrom (9) ;
245 i f ( iCRCCheck != iCRC) {246 // wenn nicht , Feh l e r r ou t in e au f ru f en
247 t e s tE r r o r ( ) ;
248 }249 // Ze ige r auf Flashanfang zuruck s e t z t en
250 cF la shZe ige r = FlashA ;
251 // ak t u e l l e CRC nach Prufen zuruck s e t z t en
252 iCRC = 0 ;
253 }254 e l s e {255 f o r ( i n t i = 0 ; i <= iFlashTestLaenge ; i++){256 // i f ( ( i n t ) cF la shZe ige r != 0x041B | | ( i n t ) cF la shZe ige r
!= 0x0428 )
257 iCRC = c r c c c i t t u p d a t e (iCRC, pgm read byte (
cF la shZe ige r++)) ;
258 // e l s e
259 // cF la shZe ige r++;
260 }261 }262
263 }264
265
266 // Watchdog−Test rout ine
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 100
267 void WDTest( ) {268 eepromWriteTo ( iWDSpeicher , 1) ; // Watchdog−Test−
Status im EEPROM f e s t h a l t e n
269
270 wdt enable (WDTO 15MS) ; // Watchdog au f z i ehen
271 d e l a y l o op 2 (5∗DelayMS) ; // Warten
272 d e l a y l o op 2 (5∗DelayMS) ;
273 d e l a y l o op 2 (5∗DelayMS) ;
274 d e l a y l o op 2 (5∗DelayMS) ; // Wenn er h i e r n i cht
zuschnappt i s t e r wohl de f ek t
275
276 t e s tE r r o r ( ) ; // in Fehlermeldung spr ingen
277 }278
279 // Timer0−Test rout ine
280 void Timer0Test ( )
281 {282 i n t i Z e i t [ 5 ] , i ;
283
284 OCR0A = 10∗DELAY; // Ladt das
V e r g l e i c h s r e g i s t e r (15mS)
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
fe s tha l t en , dass Timer0Test l a u f t .
289 // wdt enable (WDTO 15MS) ; // Akt i v i e r t den
Watchdog
290
291 f o r ( i = 0 ; i < 5 ; i++)
292 {293 TCCR0A = (1<<CS00) |(1<<CS02) ; // Timer s t a r t en
294 d e l a y l o op 2 (DelayMS) ; // Timer l au f en l a s s e n
295 TCCR0A &= ˜((1<<CS00) |(1<<CS02) ) ; // Timer stoppen
296 i Z e i t [ i ] = TCNT0;
297 i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) ) // Verg l e i chen mit
Erwartungshaltung
298 t e s tE r r o r ( ) ;
299 }300
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 101
301 // wdt d i sab l e ( ) ; // Deak t i v i e r t den
Watchdog
302 }303
304 // Timer1−Test rout ine
305 void Timer1Test ( )
306 {307 unsigned i n t i Z e i t [ 1 0 ] , i ;
308
309 OCR1A = 10∗DELAY; // Ladt das
V e r g l e i c h s r e g i s t e r (15mS)
310 TCNT1 = 0 ;
311 TCCR1A = (1<<WGM11) ; // I n i t i a l i s i e r t den
Timer
312
313 //eepromWriteTo ( iWDSpeicher , 3) ; // Im EEPROM
fe s tha l t en , dass Timer0Test l a u f t .
314 // wdt enable (WDTO 15MS) ; // Akt i v i e r t den
Watchdog
315
316 f o r ( i = 0 ; i < 5 ; i++)
317 {318 TCCR1B = (1<<CS10) |(1<<CS12) ; // Timer s t a r t en
319 d e l a y l o op 2 (DelayMS) ; // Timer l au f en l a s s e n
320 TCCR1B &= ˜((1<<CS10) |(1<<CS12) ) ; // Timer stoppen
321 i Z e i t [ i ] = TCNT1;
322 i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) ) // Verg l e i chen mit
Erwartungshaltung
323 t e s tE r r o r ( ) ;
324 }325
326 // wdt d i sab l e ( ) ; // Deak t i v i e r t den
Watchdog
327 }328
329 // Timer2−Test rout ine
330 void Timer2Test ( )
331 {332 i n t i Z e i t [ 5 ] , i ;
333
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.3 Quellcode TestLib.c Seite 102
334 OCR2A = 10∗DELAY; // Ladt das
V e r g l e i c h s r e g i s t e r (15mS)
335 TCNT2 = 0 ;
336 TCCR2A = (1<<WGM21) ; // I n i t i a l i s i e r t den
Timer
337
338 //eepromWriteTo ( iWDSpeicher , 4) ; // Im EEPROM
fe s tha l t en , dass Timer0Test l a u f t .
339 // wdt enable (WDTO 15MS) ; // Akt i v i e r t den
Watchdog
340
341 f o r ( i = 0 ; i < 5 ; i++)
342 {343 TCCR2A = (1<<CS20) |(1<<CS21) |(1<<CS22) ; // Timer s t a r t en
344 d e l a y l o op 2 (DelayMS) ; // Timer l au f en l a s s e n
345 TCCR2A &= ˜((1<<CS20) |(1<<CS21) |(1<<CS22) ) ; // Timer
stoppen
346 i Z e i t [ i ] = TCNT2;
347 i f ( i Z e i t [ i ] != ( ( i +1) ∗ DELAY) ) // Verg l e i chen mit
Erwartungshaltung
348 t e s tE r r o r ( ) ;
349 }350
351 // wdt d i sab l e ( ) ; // Deak t i v i e r t den
Watchdog
352 }353
354
355 // Routine um in den EEPROM zu schre iben
356 void eepromWriteTo ( i n t iSpe i che r , i n t i I n f o ) {357 eeprom wri te byte ( ( u i n t 8 t ∗) iSpe i che r , i I n f o ) ;
358 }359
360 // Routine um aus dem EEPROM zu l e s e n
361 i n t eepromReadFrom( i n t i Sp e i c h e r ) {362 return eeprom read byte ( ( u i n t 8 t ∗) i Sp e i c h e r ) ;
363 }
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.4 Quellcode TestLib.h Seite 103
A.4 Quellcode TestLib.h
1 #inc lude <avr /wdt . h>
2 #inc lude <avr / de lay . h>
3 #inc lude <avr /eeprom . h>
4 #inc lude <avr / crc16 . h>
5 #inc lude <avr /pgmspace . h>
6
7 #de f i n e FOSC 8000000UL // Taktfrequenz in Hz
8 #de f i n e DelayMS FOSC/4/1000 // DelayMs en t sp r i c h t 1mS
9 #de f i n e DELAY FOSC/1000/1024
10
11 extern i n t iWDSpeicher ; // S p e i c h e r z e l l e in der der
Status des WD−Tests f e s t g e h a l t e n wird
12
13
14 // Var iab le d e f i n i e r e n
15 extern i n t iTe s tS ta t ;
16 extern i n t iTestAnzahl ;
17
18 // Methode zur Auswahl des Tests d e k l a r i e r e n
19 void s e l e c tTe s t ( void ) ;
20 void s t a r tTe s t ( i n t ) ;
21 void i n i tT e s t ( void ) ;
22
23 // Sons t i g e
24 void eepromWriteTo ( int , i n t ) ;
25 i n t eepromReadFrom( i n t ) ;
26
27 // Re g i s t e r t e s t s
28 extern void TEST R0( void ) ;
29 extern void TEST R1( void ) ;
30 extern void TEST R2( void ) ;
31 extern void TEST R3( void ) ;
32 extern void TEST R4( void ) ;
33 extern void TEST R5( void ) ;
34 extern void TEST R6( void ) ;
35 extern void TEST R7( void ) ;
36 extern void TEST R8( void ) ;
37 extern void TEST R9( void ) ;
38 extern void TEST R10( void ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.4 Quellcode TestLib.h Seite 104
39 extern void TEST R11( void ) ;
40 extern void TEST R12( void ) ;
41 extern void TEST R13( void ) ;
42 extern void TEST R14( void ) ;
43 extern void TEST R15( void ) ;
44 extern void TEST R16( void ) ;
45 extern void TEST R17( void ) ;
46 extern void TEST R18( void ) ;
47 extern void TEST R19( void ) ;
48 extern void TEST R20( void ) ;
49 extern void TEST R21( void ) ;
50 extern void TEST R22( void ) ;
51 extern void TEST R23( void ) ;
52 extern void TEST R24( void ) ;
53 extern void TEST R25( void ) ;
54 extern void TEST R26( void ) ;
55 extern void TEST R27( void ) ;
56 extern void TEST R28( void ) ;
57 extern void TEST R29( void ) ;
58 extern void TEST R30( void ) ;
59 extern void TEST R31( void ) ;
60
61
62 // Push−Pop−Ret−Test
63 extern void PPRJ TEST( void ) ;
64
65 // Ar i thmet i sche Tests
66 extern void ADD TEST( void ) ;
67 extern void ADDC TEST( void ) ;
68 extern void SUB TEST( void ) ;
69 extern void INC TEST( void ) ;
70 extern void DEC TEST( void ) ;
71 extern void MUL TEST( void ) ;
72
73 // Tests der l o g i s ch en Bi toperat i onen
74 extern void CLR TEST( void ) ;
75 extern void COM TEST( void ) ;
76 extern void LSL TEST( void ) ;
77 extern void LSR TEST( void ) ;
78 extern void ROL TEST( void ) ;
79 extern void ROR TEST( void ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
A.4 Quellcode TestLib.h Seite 105
80 extern void SWAP TEST( void ) ;
81
82 // Tests der l o g i s ch en Operationen
83 extern void AND TEST( void ) ;
84 extern void OR TEST( void ) ;
85 extern void EOR TEST( void ) ;
86
87 // Tests der Transfer−Befeh l e
88 extern void mov test ( void ) ;
89 extern void movw test ( void ) ;
90 extern void l d i t e s t ( void ) ;
91 extern void l d t e s t ( void ) ;
92
93 // Port−Tests
94 void PortTest ( void ) ;
95
96 // Timer−Tests
97 void Timer0Test ( void ) ;
98 void Timer1Test ( void ) ;
99 void Timer2Test ( void ) ;
100
101 // Watchdog−Test
102 void WDTest( void ) ;
103
104 // RAM−Test
105 void Ram Test ( void ) ;
106 void Ram Check( unsigned char ∗ , unsigned char ∗) ;
107
108 // Flash−Test
109 void Flash Test ( void ) ;
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
B Tabelle der Anforderung fur Kategorien Seite 106
B Tabelle der Anforderung fur Kategorien
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
B Tabelle der Anforderung fur Kategorien Seite 107
Abbildung B.1: Tabelle der Anforderung fur Kategorien[BGIA08, S. 46f]
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
B Tabelle der Anforderung fur Kategorien Seite 108
C Schaltplan
Abbildung C.1: Schaltplan eines Kanals
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik
D CD-ROM mit Inhalten der Bachelor-Thesis Seite 109
D CD-ROM mit Inhalten der Bachelor-Thesis
Diese Bachelor-Thesis ist als PDF-Dokument auf der beiliegenden CD-ROM ent-
halten. Weiterhin sind die entwickelte Software, sowie diverse Fotoaufnahmen der
Testablaufe auf dem optischen Medium zu finden.
Die Ordnerstruktur der CD-ROM ist in Abbildung D.1 dargestellt.
Abbildung D.1: Ordnerstruktur der CD-ROM
Maxim Kupper - Hochschule Bonn-Rhein-Sieg - FB02 - Informatik