Startseite » Security »

MicroConsult hilft, systematische Fehler in der Softwareentwicklung einzudämmen

MicroConsult hilft, systematische Fehler in der Softwareentwicklung einzudämmen
Mittels Struktur und Prozesse

Ein ganzheitlicher Ansatz und das Wissen um die Details sind essentiell, wenn es um das Erstellen von funktional sicheren Embedded-Systemen geht. Die Integrität der Software kann durch strukturierte und zielgerichtete Methoden und Techniken erreicht werden. Doch was ist dabei zu beachten?

Marcus Gößler ist Trainer und Coach im Bereich Embedded Systems bei MicroConsult in München

Funktionale Sicherheit ist ein Teil des allgemeinen Sicherheitsbegriffs. Der Wortbildung liegt schon inne, dass es sich hierbei um Systeme handeln wird, die funktionieren müssen, weil sie bei einem Ausfall zu unsicheren Systemen führen können. Internationale Normen tragen heute dafür Sorge, dass nur nachvollziehbar sichere Systeme zum Einsatz gelangen. Auch wenn Normen keine Gesetze darstellen, so werden sie doch vor Gericht als Referenz angesehen, um zu beurteilen, ob ein System nach dem aktuellen Stand von Wissenschaft und Technik gebaut wurde.

Basisnorm definiert Lebenszyklus von Systemen

Welche Norm hat für den Entwickler Gültigkeit? Es gilt, dass marktspezifische Normen Vorrang gegenüber generischen Normen haben. Im industriellen Umfeld stellt die IEC 61508 die Basisnorm dar, nach deren Vorbild eine Vielzahl von spezifischen Normen entwickelt wurde. Trotzdem steht diese Basisnorm auch für sich alleine und sollte zur Anwendung gelangen, wenn es keine spezifische Norm gibt. Im Zentrum der Basisnorm stehen ein definierter Lebenszyklus von Systemen, unterteilt in mehrere Phasen, die jeweils mit entsprechenden Anforderungen versehen sind, sowie definierte Artefakte, die bei Einhaltung der Norm erstellt werden müssen. Dabei umfasst der Lebenszyklus die Entstehung des Systems durch ein entsprechendes Konzept bis hin zur Stilllegung.

Ein weiteres zentrales Instrument ist das Bewerten der Sicherheit über Risiken und das eventuelle Senken des Risikos auf ein sozial verträgliches Niveau. Dazu werden zunächst alle möglichen Gefahren, die von dem System ausgehen können, analysiert und anschließend das Risiko bewertet. Dieses ergibt sich als Produkt aus Wahrscheinlichkeit des Eintretens der Gefahr und der Schwere der resultierenden Verletzungen. Je stärker ein Risiko gesenkt werden muss (auf das sozial verträgliche Niveau), umso höher sind die Anforderungen, die die Norm an sicherheitsrelevante Systeme stellt. Die Anforderungen werden dabei in sogenannte Integritätslevel eingeordnet. Die IEC 61508 benennt vier Level, SIL 1 bis 4, wobei letzterer die höchsten Anforderungen nach sich zieht. Die Norm erkennt an, dass es keine hundertprozentige Sicherheit gibt. Sie gibt über die Integritätslevel an, welche Maßnahmen zu treffen sind, damit die sicherheitsrelevanten Funktionen ordnungsgemäß funktionieren.

Die Dokumentation als Herzstück

Welche Vorgaben stellt die Norm? Grundsätzlich geht es um das Vermeiden von Fehlern. Dazu ist es notwendig, sich mit unterschiedlichen Fehlerklassen auseinanderzusetzen. Als oberstes Unterscheidungsmerkmal wird zwischen zufälligen (random) und systematischen Fehlern unterschieden. Die zufälligen Fehler (z.B. Ausfall eines Bauteils) werden vereinfacht auch gerne als Hardwarefehler bezeichnet. Diese Fehler kann man nicht wirklich vorhersehen oder verhindern, sondern nur deren Auftreten über geeignete Bauteilauswahl und Systemdesignmaßnahmen verringern. Im Gegensatz dazu lassen sich systematische Fehler (solche, die menschlich verursacht sind) eindämmen, wenn strukturiert und nach Prozessen gearbeitet wird. Dazu gehören entsprechend hohe Anforderungen an die Dokumentation, das Management und die Verifikation in allen Phasen des Lebenszyklus. Häufig wird von Ingenieuren nur der damit verbundene hohe Aufwand gesehen, der eigentliche Nutzen aber darüber vergessen.

Selbst Anforderungen definieren

Aber nicht nur die Norm stellt Anforderungen, sie fordert auch, dass der Anwender Normen definiert. Für jede sicherheitsrelevante Funktion sind demnach Anforderungen an die Funktion an sich sowie an die Integrität der Funktion zu dokumentieren und umzusetzen. Ganz gemäß den zwei Basisfehlerklassen lassen sich Anforderungen an die Hardwareintegrität und systematische Integrität unterscheiden, die allerdings wieder aus der Norm heraus definiert in Abhängigkeit des notwendigen SIL sind. Für den eigentlichen Systementwurf spielen neben den Anforderungen an die systematische und Hardwareintegrität auch Anforderungen hinsichtlich der Behandlung von erkannten Fehlern und der Datenkommunikation eine Rolle.

Für die Hardwareintegrität kommen schließlich zwei Gruppen von Forderungen ins Spiel: Einerseits ist dies die Einhaltung von Vorgaben für zufällige Hardwarefehler, zusätzlich aber auch die Einhaltung von architekturbedingter Einschränkungen. Letzteres kann man über zwei sogenannte Pfade bzw. Routen erreichen (1H oder 2H). Die Route 2H bezieht sich dabei auf bereits betriebsbewährte Architekturen, für die aber zusätzlich Forderungen an Minimalwerte der sogenannten Hardware Fault Tolerance (HFT) gestellt werden. Route 1H bedeutet letztlich, dass man gemäß der Norm entwickelt und den Nachweis für zwei Maße führt, nämlich für die HFT und die SFF (Safe Failure Fraction), deren Werte je nach zu erfüllendem SIL eingehalten werden müssen.

Software-Integrität durch strukturierte Methoden

Ähnliches gilt für die systematische Integrität, deren Einhaltung sich über das Folgen von drei unterschiedlichen Routen (1S, 2S oder 3S) umsetzen lässt. Route 1S bedeutet wiederum das Entwickeln gemäß der Norm, Route 2S bezieht sich auf die Betriebsbewährtheit, und Route 3S sowie damit in Zusammenhang stehende Anforderungen gelten für den Einsatz von vorgefertigter Software, die allerdings nicht nach Norm entwickelt wurde. Wenn funktionale Sicherheit über Software auf programmierbaren Geräten sichergestellt werden soll, gelten weitere Maßnahmen, die je nach gefordertem SIL getroffen werden müssen. Da es allerdings keine zufälligen Fehler in Software gibt, zielen die Maßnahmen auf das Verhindern von systematischen Fehlern ab. Das Übel soll also an der Wurzel gepackt und die Integrität der Software durch strukturierte und zielgerichtete Methoden und Techniken erreicht werden.

Die gute Nachricht an dieser Stelle geht an all jene, die bereits strukturiert und prozessorientiert Software entwickeln, sprich, allgemein anerkannte Software-Engineering-Praktiken anwenden. Der Aufwand hält sich in diesem Fall in Grenzen. Das Erstellen einer Software-Architektur sowie das Software-Design und Modul-Design zählen ebenfalls zu diesen Best Practices. Neu ist allerdings die Notwendigkeit, sich auch die Software-Tools näher anzusehen, mithilfe derer Software realisiert wird. Je nach potentiellen Auswirkungen von Fehlern dieser Tools sind Validierungen durchzuführen, um sicherzustellen, dass über die Verwendung der Tools keine erhöhten Ausfallraten der Safety-relevanten Softwarefunktionen zu erwarten sind.

Verifikation und Validierung durch entsprechende Test sind essentiell. Da Software häufig verändert wird, besteht die Notwendigkeit, solche Veränderungen über einen eigens dafür definierten Prozess in die Softwareentwicklung einfließen zu lassen. Dieser Prozess kann selbst definiert werden, aber er muss z.B. sicherstellen, dass nur freigegebene Änderungsanforderungen auch tatsächlich umgesetzt werden und dass über eine Impact-Analyse festgestellt wird, welche Phasen des Lebenszyklus von solchen Änderungen betroffen sind. Nur so kann man sicherstellen, dass das System als Ganzes weiterhin sicher entwickelt wird. ge

www.microconsult.com

Trainings zum Thema

http://hier.pro/f1VCC

Newsletter

Abonnieren Sie unseren Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts

Technisches Wissen aus erster Hand

Whitepaper

Hier finden Sie aktuelle Whitepaper

Videos

Hier finden Sie alle aktuellen Videos


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de