Einführung in die Software-Entwicklung gemäß IEC61508

Anbieter zum Thema

MicroConsult Academy GmbH

Heitec AG

ISH Ingenieursozietät GmbH

Softwareentwurf und Softwareentwicklung

Zunächst ist eine Softwarearchitektur zu entwerfen. Diese ist bezüglich der definierten Sicherheitsanforderungen zu begutachten (zu verifizieren). Dabei sollte die Softwarearchitektur Informationen zu Programmmodulen und der Trennung zwischen sicherheitsgerichteten und nichtsicheren Programmteilen beinhalten. Softwareschichten, Schnittstellen (auch Software/Hardware-Schnittstellen), Interruptverarbeitung, Daten- und Funktionsgrafen sowie verschiedene andere „Constraints“ (Zeitanforderungen, Determinismus, Prioritäten, etc) können bereits in der Software-Architektur spezifiziert werden.

Der Übergang von der Architektur zum Software-Design ist fließend. Die Vorgaben aus der Architektur werden detailliert. Softwaremodule werden näher spezifiziert (Funktionen, Daten, Schnittstellen), wenn möglich mit semi-formellen Methoden. Dazu geeignet sind Klassendiagramme, Block-Diagramme, Sequenz-Diagramme, Programmablaufpläne und/oder Zustandsautomaten.

Im folgenden Software-Entwurf selber werden eher allgemeine Anforderungen gestellt. Verwendete Werkzeuge und die Programmiersprache sind zu wählen (C ist laut IEC 61508 nur mit Einschränkungen verwendbar!). Dabei spielt die „Betriebsbewährtheit“ der Werkzeuge eine wichtige Rolle. Ein geeignetes Konfigurationsmanagement ist dringend empfohlen.

Insbesondere beim Einsatz der Programmiersprache C in Embedded-Systemen sind, die Empfehlungen der IEC61508-3 zu beachten. Programmierkonventionen mit Spracheinschränkungen (z.B. Vermeidung dynamischer Speicher und Pointer), defensive Programmierung und die Kapselung von Moduldaten und Funktionen (Geheimnisprinzip) werden ebenso erwähnt, wie die strukturierte Programmierung mit beispielsweise:

• Wenige Verzweigungen im Modul
• Einfacher Zusammenhang zwischen Eingangs- und Ausgangsdaten
• Komplexe Bedingungen und Berechnungen als Sprungbedingung vermeiden
• GOTO (unbedingter Sprung) vermeiden
• Keine dynamischen Variablen und keine Objekte
• Vorsicht bei Interrupts, Pointer und rekursiven Routinen!

Zur Verifikation des Codes bezüglich der Sicherheit gibt es weitere Anforderungen:

• Code Reviews
• Modultests
• Integrationstests mit vordefinierten Testfällen/-daten (Funktions- , Black Box-, White Box- und Performance-Test)
• Dokumentation, Versionierung und Rückverfolgbarkeit der Ergebnisse

Die Funktionen der Software können klassifiziert werden. Dabei gibt es sicherheitsrelevante Abstufungen (z.B. anhand einer „Criticality Analyse“ mittels FMECA) der einzelnen Funktionen. Bei sicherheitskritischen Programmteilen sollten Maßnahmen zur Erkennung und Vermeidung von Softwarefehlern definiert werden, auf die in den folgenden Tests besonders eingegangen wird.

Software-Modultest

Im Software-Modultest finden sich Testkonzept und Testfälle. Sie sind je nach Phase vom entsprechenden Entwurf abgeleitet. Testfälle definieren eine Erwartung und ein Resultat (siehe auch IEEE829). Alle relevanten Zweige im Modul sollten durch Tests abgedeckt sein. Aufgrund des Aufwandes ist eine Code- und Decision- Coverage von 100% in der Praxis als gängige Mindestanforderung zu finden.

Neben Guttests, Grenzwerten, Über- und Unterläufe sollten alle Funktionalitäten getestet werden, die als Sicherheitsfunktion definiert sind und zu sicheren Reaktionen im System führen können. Bei den Tests kann grundsätzlich zwischen statischen und dynamischen Tests unterschieden werden:

Statische Tests:

• Reviews/ Code Inspection/ Walkthrought
• Statische Analyse (z.B. PC-Lint)

Dynamische Tests:

• Funktionaler, Stress-, Reaktions-, Performance-Test
• Datenfluss- und Interface-Test

(ID:317511)