Bachelorthesis - Hochschule Bonn-Rhein-Sieg (H-BRS) · ge einen ATMEL AVR-Mikrocontroller...

120
Bachelorthesis Aufbau eines homogen redundanten Rechnersystems und Untersuchung des Ausfallverhaltens unter Umgebungseinfl¨ ussen Hochschule Bonn-Rhein-Sieg Fachbereich Informatik Studiengang: Bachelor of Computer Science / Embedded Systems Grantham-Allee 20 53757 Sankt Augustin Vorgelegt von: Maxim K¨ upper Erstpr¨ ufer: .................................. Prof. Dr. Dietmar Reinert Zweitpr¨ ufer: ........................................ Dr. Michael Schaefer Eingereicht am: 15. April 2009

Transcript of Bachelorthesis - Hochschule Bonn-Rhein-Sieg (H-BRS) · ge einen ATMEL AVR-Mikrocontroller...

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