Mobile-Menu

Sicherheitskritische Systeme, Teil 3 Einführung in die Software-Entwicklung gemäß IEC61508

Redakteur: Martina Hafner

Teil 3 der Norm IEC 61508 richtet sich an Software-Entwickler sicherheitsgerichteter Systeme. Da viele Softwarefehler auf Spezifikationsmängeln und mangelnder Transparenz in den Abläufen basieren nehmen Entwicklungsprozesse und Methoden in der Norm einen breiten Raum ein.

Anbieter zum Thema

MicroConsult Academy GmbH
Heitec AG
ISH Ingenieursozietät GmbH

Für Softwarefehler gilt seit jeher: Kleine Fehler können große Auswirkungen haben. Dabei sind Softwarefehler immer (latent) vorhanden, insbesondere da die Komplexität von Software kontinuierlich steigt.

Die Qualität heutiger Software wird nicht allein durch möglichst fehlerfreie Codierung und Tests erreicht, nach verschiedenen Untersuchungen basieren viele Softwarefehler bereits auf Spezifikationsmängeln und mangelnder Transparenz in den Abläufen. Daher nehmen Entwicklungsprozesse und Methoden einen breiten Raum im 3. Teil der IEC 61508 ein.

Tabelle 1: Restfehler in Software (Archiv: Vogel Business Media)

Softwarefehler sind immer Entwurfs- oder Implementierungsfehler. Im Kontext der IEC 61508 werden diese Fehler als „systematische Fehler“ bezeichnet.

Bild 1: IEC 61508: E/E/PES im Teil 2 und Software im Teil 3 (Archiv: Vogel Business Media)

Sicherheitskritische Software sind Programmteile, die unmittelbar oder mittelbar die Sicherheit eines Systems durch Fehlfunktionen beeinflussen können. Dabei sind Funktionen der Applikation (z.B. Berechnungen, Ablaufsteuerungen), der Hardware (z.B. Diagnosen wie RAM- Test) und der Kommunikation (z.B. sichere Datenübertragung) unterscheidbar.

Anforderungen der IEC61508-3

Bild 2: Software- Lebenszyklus nach IEC 61508-3 (Archiv: Vogel Business Media)

Teil 3 der Norm IEC 61508 beschreibt einen Lebenszyklus der Software und schlägt Techniken und Verfahren vor, wie sicherheitsgerichtete Software(teile) entworfen und dokumentiert sein sollte. Alle Tätigkeiten und Ergebnisse des Lebenszyklus müssen dokumentiert werden.

Basierend auf dem Software- Lebenszyklus ist das bekannte V-Modell mit sicherheitskritischen Anforderungen erweitert worden und kann als Grundlage einer Softwareentwicklung nach der IEC61508-3 angewendet werden. Haben sich im Unternehmen andere Software- Entwurfsmodelle (Wasserfall, Spiralmodelle) etabliert, sollte der Zusammenhang zu den vorgeschlagenen Phasen der IEC61508 dargestellt werden. Dabei ist die Rückverfolgbarkeit für sicherheitsgerichtete Funktionen in der Dokumentation elementar: Die Informationskette Spezifikation- Entwurf- Implementierung- Test und zurück muss für jede einzelne Sicherheitsfunktion erkenntlich sein.

Spezifikation der Software-Sicherheitsanforderung

  • Beschreibung der sicherheitsrelevanten Funktion
  • Beschreibung der Schnittstellen zwischen Hard- und Software
  • Trennung zwischen sicherheitsrelevanten und nichtsicheren Programmteilen
  • Sicherheitsrelevante Kommunikationsverbindungen

Je nach SIL sind dabei bestimmte Methoden der Beschreibung gefordert (z.B. semi- formale oder formale Methoden).

IEC 61508 Teil-7 enthält generell eine nähere Beschreibung der vorgeschlagenen Methoden. Diese sind jedoch oft in der Softwareentwicklung von Embedded- Systemen nahezu unbedeutend. Äquivalente Methoden und Verfahren sind erlaubt – so ist heute z.B. UML 2.0 ein gängiger Standard, um Software zu entwerfen und zu dokumentieren.

Planung der Validierung der Software bezüglich der Sicherheit

Die IEC 61508 fordert immer eine Planung der geforderten Tests (Validierungen) im Vorfeld, inklusive Reviews und Begutachtungen (Verifikationen). In der Testplanung werden die Tests mit Erwartungshaltung beschrieben. Auch wann diese Tests von wem auszuführen sind, muss aus der Dokumentation ersichtlich sein. Auf dieser System- Ebene sind die Tests auf die Sicherheitsanforderungen an die Software zu beziehen, nicht auf die fertigen Module (siehe Software- Modultest).

(ID:317511)

Weiterführende Inhalte