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

Anbieter zum Thema

Integrationstest (Module)

Analog den Modultest werden hier Tests „auf höherer“ Ebene gefordert. Unterschieden werden können grundsätzlich Modul-Integrationstest (Test mehrerer Module im Zusammenspiel und Integrationstest (Test der Module und Teilsysteme auf der Zielhardware). Überschneidungen, auch mit der Validierung der Softwaresicherheitsanforderungen, sind oft nicht zu vermeiden – hier sollte eine projektbezogene herangehensweise definiert werden.

Wichtig ist, dass alle Software-Tests auf einer(!) Softwareversion nach Spezifikation und Testplan durchgeführt werden und jederzeit auf einer beliebigen Version reproduzierbar sind. Empfohlen sind folgende Methoden: Black-Box- und Performance Tests mit Grenzwert-Analyse, Ablauf-Analyse, Stress- und Performance-Tests.

Software Validierung/Verifikation

Für die Software-Validierung sind Testplanungen und Testfälle von der Spezifikation der Software-Sicherheitsanforderung abgeleitet und der Zusammenhang ist rückverfolgbar. Die Validierung soll durch Simulation oder Stimulation durchgeführt werden:

Eingangssignale
Ereignisse im Vorgriff
Unerwünschte Zustände, die eine Reaktion des Systems erfordern
Grenzwert-Analyse, Prozess-Simulation
Ablauf-Analyse, Performance-Test

Softwaremodifikation

Die Softwaremodifikation beginnt mit einer Anforderung zur Änderung der Software. Diese enthält die geforderte Änderung und den Änderungsgrund. Es folgen eine Einschätzung bezüglich der Beeinflussung von Sicherheitsfunktion, eine detaillierte Änderungsdokumentation inklusive Testfälle und erneut auszuführende vorhandene Tests. Eventuell muss nach der Änderung sogar die gesamte Software neu verifiziert werden.

Abläufe und Tätigkeiten erfolgen dabei nach einem (Teil-) Prozess, der im FSM (Functional Safety Management) definiert wurde (siehe 1. Teil dieser Artikelreihe). Die Rückverfolgbarkeit der Softwareänderungen (Konfigurationsmanagement) ist erforderlich.

Beurteilung der funktionalen Sicherheit

Die Ergebnisse der einzelnen Phasen sind, wie in der IEC61508 Teil 1, Abschnitt 8 vorgegeben, einer Beurteilung zu unterziehen. Festgelegt wird, je nach erforderlichem SIL, der minimale Grad der Unabhängigkeit derjenigen, die die Beurteilung ausführen. Die erforderlichen Tätigkeiten dazu sind in der Tabelle A.10 definiert. Die Beurteilung kann aufgrund von Checklisten, Wahrheitstabellen, Komplexitätsmetriken, Versagensanalyse (auch mit gemeinsamer Ursache für diversitäre Software) oder Zuverlässigkeitsdiagrammen geprüft werden.

Die Programmiersprache C

Streng typisierte Programmiersprachen sind nach der IEC 61508 empfohlen (ADA, Pascal), C jedoch nicht (nur mit Einschränkungen). Aber: C ist in der Softwareentwicklung von Embedded-Systemen de facto Standard. Es gibt eine Zuordnung der C-Befehle zu Assembler-Instruktionen, um die Abhängigkeit von einer Laufzeitumgebung zu minimieren. Mit C kann (relativ) hardwarenah programmiert werden (Speicherzugriffe und hardwarenahe Konstrukte). Es gibt bewährte Compiler und Debugger für C unter fast allen Umgebungen.

Know-How in der C-Programmierung ist (meist) vorhanden und die Investition ist bereits erfolgt (Compiler, Debugger, Editoren, etc.). Funktionen der Standardbibliothek stehen in den meisten Umgebungen zur Verfügung, dadurch sind C Programme gut portabel. Vorsicht: Nicht immer wird die Standardbibliothek voll unterstützt!

Laut IEC61508 ist C nicht uneingeschränkt empfohlen. Warum?

C ist flexibel, weil nur sehr eingeschränkte Prüfungen bei Speicherzugriffen, Variablentypen und Stacknutzung durchgeführt werden. Dadurch können die Compiler (anders als z. B. in Pascal) nur sehr eingeschränkt bei der Fehlersuche helfen.
C enthält kritische Funktionen, z. B. gets() kann fremde Speicherbereiche überschreiben (bei zu langer Eingabe). Der Fehler ist nicht erkennbar oder prüfbar.
Modularisierung in C erfolgt auf Dateiebene. Die Bekanntgabe der Funktions- und Datenschnittstellen erfolgt in Headerdateien. Das ist insgesamt ein sehr schwach ausgeprägtes Modulkonzept.
Wegen der Hardwarenähe der Programmiersprache können manche Sprachkonstrukte (z.B. Bitmasken oder Zeigerarithmetik) zu Annahmen über die Byte-Reihenfolge (Endianess) oder Wortbreite führen, was die Portabilität auf andere Prozessoren einschränkt.

(ID:317511)

Sicherheitskritische Systeme, Teil 3