Sicherheitskritische Systeme, Teil 3
Einführung in die Software-Entwicklung gemäß IEC61508
05.10.2009 | 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.
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.
Softwarefehler sind immer Entwurfs- oder Implementierungsfehler. Im Kontext der IEC 61508 werden diese Fehler als „systematische Fehler“ bezeichnet.
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
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).
Themenverwandte Beiträge
Sicherheitskritische Systeme, Teil 2: Einführung in die Entwicklung gemäß IEC 61508 — Hardwareaspekte
Sicherheitskritische Systeme, Teil 1: Leitfaden für die Norm IEC 61508
Sicherheitskritische Systeme, Teil 1: Leitfaden für die Norm IEC 61508
Safety-Critical-Systeme: Tut mein Compiler was ich will?
Safety-Critical-Systeme: Tut mein Compiler was ich will?
Lizenzierung urheberrechtlich geschützter Artikel
Nutzen Sie diesen Artikel ID 317511 oder andere Fachinformationen für Ihr Marketing. Wir bieten Ihnen die Nutzungsrechte für Ihre Website, Ihren Newsletter oder Ihre Kundenzeitschrift. Für alle Fragen wenden sie sich bitte an Frau Maurer unter Tel. 0931 / 418-2888 oder unseren Content-Dienstleister www.mycontentfactory.de .Quategra GmbH
Leipzig, Deutschland

MKS GmbH
Esslingen, Deutschland

MSC Vertriebs GmbH
Stutensee, Deutschland

pls Programmierbare Logik & Systeme GmbH
Lauta, Deutschland
National Instruments Germany GmbH
München, Deutschland
Echte Wiederverwendung für Anforderungen
Die Wiederverwendung von Anforderungen bietet die Möglichkeit, Anforderungen gemeinsam und projektübergreifend zu nutzen, ohne unnötige Duplikate von Artefakten in das Repository aufnehmen zu müssen.
Die Wiederverwendung von Anforderungen bietet die Möglichkeit, Anforderungen gemeinsam und projektübergreifend zu nutzen, ohne unnötige Duplikate von Artefakten in das Repository aufnehmen zu müssen.
Software-Entwicklung für integrierte modulare Avionik
Whitepaper über aktuelle Trends in der Entwicklung von sicherheitskritischen Avioniksystemen.
Whitepaper über aktuelle Trends in der Entwicklung von sicherheitskritischen Avioniksystemen.
Ein innovativer Ansatz für das Management von Anforderungen
Die Verwaltung von Anforderungen ist ein integraler Bestandteil des Entwicklungsprozesses in Unternehmen und unerlässlich, um Risiken in großen Entwicklungsprojekten zu begrenzen.
Die Verwaltung von Anforderungen ist ein integraler Bestandteil des Entwicklungsprozesses in Unternehmen und unerlässlich, um Risiken in großen Entwicklungsprojekten zu begrenzen.
Unit-Tests erhöhen die Software-Qualität
Unit-Tests reduzieren die Komplexität, wodurch Fehler einfacher aufzuspüren und zu beheben sind.
Unit-Tests reduzieren die Komplexität, wodurch Fehler einfacher aufzuspüren und zu beheben sind.
Das könnte Sie auch interessieren
Benutzer
Passwort
Passwort







Home




Meine ELEKTRONIKPRAXIS








zum Login