Kurzfassung

Dr. Rainer Gerlich
Diplom-Physiker
BSSE System and Software Engineering
DGLR Workshop Fachausschuss Q3.4, 2016
„Software Safety“
Titel:
Ergebnisse und Empfehlungen aus der Fehleranalyse von Raumfahrtsoftware
Autoren:
Rainer Gerlich, Ralf Gerlich
Inhalt:
Der Inhalt des Vortrages basiert auf Ergebnissen, die während fast 10 Jahren in verschiedenen
Raumfahrtprojekten gesammelt wurden, in denen C verwendet wurde.
Ziel ist, auf Aspekte der Verifikation von Software, der Fehlerprävention und mittels Beispielen auf typische
Fehler hinzuweisen.
Folgende Punkte sollen mit Beispielen angesprochen werden:
Code vs. Verifikation
Die Komplexität der Verifikation des Codes – durch statische oder dynamische Analyse (Test) – und
zugehöriger Aufwand hängen wesentlich vom Codierstil ab.
Je klarer der Code interpretiert werden kann, desto einfacher ist die Verifikation, sowohl für ein Tool als auch
für den Prüfenden.
Wesentlich für den Verifikationsaufwand ist die Klärung der nicht sicher als fehlerhaft oder korrekt
einzustufenden Meldungen eines Tools. Je mehr solcher Meldungen es gibt, desto größer ist der Aufwand.
Ist vorab bekannt, wie die Anzahl solcher Meldungen verringert werden kann, so kann der Aufwand der
Verifikation erheblich reduziert werden. Wird ein Verifikationstool bereits von Beginn der Codierungsphase an
eingesetzt, so können auf der Basis der ausgewerteten Meldungen Korrekturen am Codierungstil oder der
Systemarchitektur rechtzeitig vorgenommen und somit die Anzahl der Meldungen zum Projektende (Quality
Gate) signifikant reduziert werden.
Notwendigkeit der Definition von Verifikationszielen
Beim Funktionstest wird eine Funktion hinsichtlich funktionaler und nicht-funktionaler Eigenschaften im
Hinblick auf die speziellen Anforderungen an die Funktion und allgemeiner Anforderungen untersucht. Aus
Systemsicht kann es aber ausreichen nachzuweisen, dass die Funktion im Systemkontext die Anforderungen
voll erfüllt.
Bspw. kann eine Funktion im Systemkontext für einen reduzierten Wertebereich der Daten benutzt werden,
so dass kritische Werte, die einen Fehler auslösen würden, nicht vorkommen können.
Ob geringere Anforderungen an eine Funktion bedingt durch den Systemkontext bei der Verifikation
berücksichtigt werden sollen oder nicht, sollte früh im Entwicklungs- und Testplan festgelegt werden. Es
muss entschieden werden:
• Robustheit und höherer Verifikations- bzw. Testaufwand, aber stabileres System und weniger
Wartungsaufwand,
• Design-by-Contract und niedriger Verifikations- bzw. Testaufwand, aber ein System, das gerade die
momentanen Anforderungen erfüllt bei zu erwartendem höheren Wartungsaufwand.
Fehlermanagement
In vielen Fällen wurde beobachtet, dass die Fehlererkennung und -behandlung unzureichend ist. Vielfach
wird nicht beachtet, dass die Art der Fehlerbehandlung nicht nur lokale, sondern auch eine systemweite
Bedeutung hat, sofern überhaupt eine Fehlerbehandlung erfolgt. Es fehlt dann ein vorgegebener
ganzheitlicher Ansatz, dass und wie Fehler zu behandeln sind.
Das Fehlerbehandlungskonzept muss bereits mit der Systemarchitektur definiert werden. Bspw. ist es nicht
sinnvoll, einen Fehler lokal – wie auch immer – zu maskieren, aber den Vorfall nicht anzuzeigen.
Verschiedene Fehler beim Fehlermanagement und Strategien zu größerer Robustheit werden beschrieben.
Sicher Programmieren
© Dr. Rainer Gerlich – BSSE System and Software Engineering 2016
Auf dem Ruhbühl 181, 88090 Immenstaad, Tel. 07545/911258, 0171/8020659, Fax 07545/911240 [email protected]
BSSE System and Software Engineering
Durch geeignete Maßnahmen kann Software inhärent sicher werden. Schwache, unsichere Algorithmen
implizieren ein endliches Risiko für einen Systemausfall oder einen eingeschränkten Betrieb. Sichere
Algorithmen schließen jegliches Risiko aus. Bei ausreichender Erfahrung implizieren sie meistens keinen
erhöhten Aufwand. Diese Erfahrung kann durch Feedback aus der Analyse von Schwachstellen – bspw.
angezeigt durch Verifikationswerkzeuge – gewonnen werden, wie an Beispielen gezeigt wird, die zu einem
erhöhten Risiko führen:
• potenzielle Inkonsistenzen
• Mix signed – unsigned
• Macros mit Seiteneffekten
• Abweichung von Konventionen
• hohe Komplexität, auch durch Standards
Zusammenfassung
Vor Beginn der Entwicklung sind bereits Maßnahmen zu treffen mit dem Ziel, Regeln festzulegen für
• die Verifikation und die Abnahme,
• die Fehlerbehandlung,
• die Dokumentation von erkannten Schwachstellen und deren zukünftiger Vermeidung,
• die Verwendung sicherer Algorithmen.
Der Aufwand für die Verifikation kann signifikant verringert werden, wenn während der Entwicklung ständig –
in dem notwendigen Maß – überprüft wird, ob die vereinbarten Regeln auch eingehalten werden.
Erhöhter Verifikationsaufwand entsteht immer dann, wenn Regeln nicht eingehalten werden, und dann sehr
viele Beanstandungen festgestellt werden.
Insbesondere erhöht sich der Aufwand signifikant, wenn codiert wird, bevor alle Regeln bekannt sind, die bei
der Verifikation angewendet werden sollen.
Die Meldungen von Tools sollten konsequent genutzt werden, um die Qualität des Codes zu verbessern. Die
überwiegende Anzahl von solchen Meldungen ist berechtigt, und sie sollten ernst genommen werden.
Kontakt:
Dr. Rainer Gerlich
Dr. Ralf Gerlich
[email protected]
[email protected]
Dr. Rainer Gerlich BSSE System and Software Engineering (BSSE)
Auf dem Ruhbühl 181, 88090 Immenstaad
Tel. 07545/911258
Fax 07545/911249
-2© Dr. Rainer Gerlich BSSE System and Software Engineering 2016

Download Report