29.01.2013 Aufrufe

Optimierung einer Softwarebibliothek für sicherheitsrelevante

Optimierung einer Softwarebibliothek für sicherheitsrelevante

Optimierung einer Softwarebibliothek für sicherheitsrelevante

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

4 Konzept und Implementierung 40<br />

• Die internen Register werden <strong>für</strong> die Zwischenspeicherung der Daten <strong>für</strong> Berechnungen<br />

in der CPU benötigt. Funktionieren diese nicht, z. B. existiert ein<br />

Haftfehler, dann würde auch eine fehlerfreie CPU falsche Resultate liefern.<br />

• Bei <strong>einer</strong> fehlerhaften CPU werden die Programme einfach falsch ausgeführt,<br />

was eine große Gefährdung mit sich bringt.<br />

• Im ROM werden Programme gespeichert, die von dem µController ausgeführt<br />

werden. Sind richtige Programme falsch eingespeichert, wird das richtige Programm<br />

falsch ausgeführt.<br />

• Der Timer wird benötigt um das Zeitscheibenverfahren zu realisieren. Funktioniert<br />

der Timer nicht richtig, so werden die Zeitscheiben falsch eingeteilt, was unvorhersehbare<br />

Auswirkungen als Folge haben kann.<br />

• Funktionieren die Eingänge oder Ausgänge eines µControllers nicht richtig und<br />

sind an diese Sensoren und Aktuatoren angeschlossen, kann der µController die<br />

Umgebung nicht richtig wahrnehmen, sowie seine Aufgabe nicht richtig ausführen,<br />

z.B. Bewegen eines Roboterarms.<br />

• Im RAM werden Daten, die <strong>für</strong> die Berechnung nicht gerade benötigt werden<br />

zwischengespeichert. Existiert ein Fehler im RAM werden anschließend <strong>für</strong> die<br />

Berechnung verfälschte Daten zurückgeliefert. Der RAM-Test wird als letzter gestartet,<br />

weil er am meisten Zeit braucht und in Zeitscheiben ausgeführt wird.<br />

Sind die Tests erfolgreich verlaufen, kann der µController „freigegeben“ werden. Im Betrieb<br />

wird ein Hintergrundtest ausgeführt. Die Besonderheit dabei ist, dass nur CPU-,<br />

Register-, Watchdog- und I/O-Tests vollständig ausgeführt werden, da diese schnell genug<br />

sind. RAM- und ROM-Test sind hingegen rechnerisch mit großem Aufwand verbunden<br />

und würden somit die Sicherheitsfunktion des µControllers gefährden, falls sie am<br />

Stück ausgeführt wurden. Deswegen werden die Speichertests in Zeitscheiben ausgeführt,<br />

was aber ihre Wirksamkeit nicht mindert.<br />

4.1.2 Watchdog-Test<br />

Konzept<br />

Als Ausgangsposition <strong>für</strong> die Entwicklung des Watchdog(WD)-Tests wurde das Verfahren<br />

des BGIA [SCH97] genommen. Der Test ist wie folgt definiert [vgl. DEMER]:<br />

1. Eine Variable wird eingerichtet ( im Programm „getestet“).<br />

2. WD wird initialisiert und gesetzt.<br />

3. Es wird eine Funktion definiert, die länger dauert als der WD (im Programm<br />

„wait_5ms“).<br />

4. Kurz vor dem Eingreifen des WD wird die Variable invertiert („getestet=1“)<br />

und nach dem Eingreifen wieder invertiert („getestet=0“).

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!