Suchen

Safety-Critical-Systeme Tut mein Compiler was ich will?

Autor / Redakteur: Richard Barry* / Martina Hafner

IEC 61508 beschreibt zwei Wege für die Verifikation von Compilern, wobei eine glaubwürdige Einhaltung der Norm auf beiden Wegen problematisch ist. Hier soll eine Alternative vorgestellt werden, die vor kurzem erfolgreich in der IEC-61508-Prozess-Verifikation des SafeRTOS, eines kleinen Echtzeit-Schedulers, verwendet wurde.

Firmen zum Thema

Richard Barry ist Entwicklungsleiter bei Wittenstein High-Integrity Systems in UK. Er ist Urheber des Open-Source-Betriebssystems FreeRTOS. Kontakt: r.barry@freertos.org
Richard Barry ist Entwicklungsleiter bei Wittenstein High-Integrity Systems in UK. Er ist Urheber des Open-Source-Betriebssystems FreeRTOS. Kontakt: r.barry@freertos.org
( Archiv: Vogel Business Media )

IEC 61508 (Norm für die funktionale Sicherheit sicherheitsbezogener elektrischer, elektronischer und programmierbarer elektronischer Systeme) deckt Prinzipiell drei Gebiete ab: Geschäftsprozesse und Struktur, Hardwareentwicklung und Softwareentwicklung. Letzteres befasst sich mit Techniken, um systematische Fehler in sicherheitskritischer Software zu verringern, deren Wahrscheinlichkeit sich im Allgemeinen nicht quantifizieren lässt. Hinter IEC 61508 steht keine gesetzlich vorgeschriebene Körperschaft um die Norm-Konformität zu zertifizieren.

Dies bedeutet, dass die Einhaltung der Norm unabhängig von einer anerkannten Organisation zertifiziert werden muss.

Bildergalerie

Empfehlungen für Entwicklungswerkzeuge nach IEC 61508

IEC 61508 verwendet den Begriff „empfehlenswert“ („highly recommended“) für Anforderungen, die erfüllt sein müssen. Alternativ ist eine Begründung vorzulegen, falls Anforderungen nicht erfüllbar sind, oder es muss eine akzeptable Alternative geboten werden. In Bezug auf unterstützende Werkzeuge und Programmiersprachen definiert IEC 61508 die folgenden Empfehlungen:

  • Einsatz einer passenden Programmiersprache,
  • Einsatz einer streng typisiert Programmiersprache,
  • Einsatz einer definierten Sprach-Untermenge,
  • Nutzung von Werkzeugen mit Zertifizierung oder Nachweis der Vertrauenswürdigkeit dieser Werkzeuge aufgrund eines langen Tool-Einsatzes ,
  • Nutzung eines ein zertifizierten Translator-Programms oder Nachweis der Vertrauenswürdigkeit dieses Programms aufgrund eines langen Einsatzes;
  • Einsatz einer Bibliothek aus vertrauenswürdigen und verifizierten Software-Modulen und -Komponenten.

Darüber hinaus sollte man auch darauf achten, dass der Compiler über die gesamte Lebensdauer des Produkts verfügbar ist.

Es gibt zwei „empfehlenswerte“ Wege um die Eignung eines Compilers nachzuweisen. Er kann auf dem gleichen oder einem höheren Level zertifiziert werden, oder man wendet das Konzept der „Bewährung im Einsatz“ an. Beide Vorgehensweisen bergen Probleme. Darüber hinaus schreibt IEC 61508 einige Anforderungen bei der Auswahl der Programmiersprache vor.

Strenge Einschränkungen bei der Wahl der Programmiersprache

IEC 61508 gibt für die Auswahl der Programmiersprache strenge Einschränkungen vor. Weil dies aber nicht immer praktikabel ist, bietet die Norm auch Alternativen. So wird zum Beispiel festgelegt, dass die Sprache vor allem folgende Merkmale haben sollte:

  • Sie sollte über einen Translator/Compiler verfügen, der ein Validierungs-Zertifikat nach einem anerkannten nationalen oder internationalen Standard besitzt. Als Alternative muss die Eignung des Translators/Compilers für den vorgesehenen Zweck bewertet werden.
  • Sie sollte vollständig und eindeutig definiert sein. Als Alternative sollte sie auf eindeutig definierte Funktionsmerkmale eingeschränkt sein.
  • Sie sollte zu den Merkmalen der Anwendung passen.
  • Sie sollte Funktionen enthalten, um Programmiererfehler zu erkennen.
  • Sie sollte über Funktionen verfügen, die zur Design-Methode passen

Der Einsatz von C als Programmiersprache macht die Einhaltung der Punkte eins, zwei und vier schwierig. Im vorliegenden Fall erlaubte IEC 61508 unter folgenden Voraussetzungen ein Abweichen von den Regeln:

  • Die Projekt-Dokumentation enthält eine Begründung für die Abweichung.
  • Die Eignung der Programmiersprache für den gewünschten Zweck wird bewertet.
  • Risiken, die während der Bewertung der Eignung identifiziert wurden, werden durch den Einsatz zusätzlicher Maßnahmen verringert.
  • Der Benutzer der die Bewertung durchführt, akzeptiert die Argumente für die obigen Punkte.

Weil wir die Programmiersprache C einsetzten (SafeRTOS musste in C geschrieben werden, da es in ein C Programm kompiliert werden sollte), war die Einhaltung dieser Bedingungen entscheidend für die IEC-61508-Konformität bei der Entwicklung von SafeRTOS.

Norm-Konformität durch Compiler-Zertifizierung

Die Norm schreibt nicht klar vor, welche Kriterien der Compiler erfüllen muss, damit er als zertifiziert gelten kann. Wir mussten daher unsere eigene logische Argumentation formulieren. Aus unserer Sicht kann ein C-Compiler den Einsatz in einem sicherheitsbezogenem System zu Recht als vertrauenswürdig und langfristig unterstützbar bewertet werden, wenn er die folgenden Bedingungen erfüllt:

  • Sein Einsatz wurde in einem Validierungsprozess überprüft, der ähnlich streng ist wie der, der für das SIL der zur entwickelnden Anwendung erforderlich ist.
  • Belege für die Compiler-Validierung stehen zur Überprüfung bereit, oder der Compiler hat eine Auditierung von einer glaubwürdigen und unabhängigen Organisation bestanden, deren Umfang dokumentiert wurde.
  • Der Compiler implementiert eine klar definierte Auswahl an Sprachmerkmalen auf genau festgelegte Weise, wobei sämtliche Abweichungen ausführlich dokumentiert sind.
  • Die Konfiguration des Compilers ist streng festgelegt, wobei die gewählte Version über die gesamte absehbare Lebenszeit des Produktes vom Hersteller als aktives Produkt unterstützt wird.

Gibt es keine solche C-Werkzeugkette für den gewünschten Prozessor, gibt es die Option, die Norm durch „Nachweis im tatsächlichen Betrieb“ zu erfüllen.

Norm-Erfüllung durch Nachweis des Compilers im tatsächlichen Betrieb

Der Nachweis im tatsächlichen Betrieb ist unter folgenden Bedingungen glaubwürdig:

  • Es gibt eine große und bekannte Anzahl von Benutzern, die alle eine stabile Version des Werkzeugs über einen längeren Zeitraum mit einer bekannten Häufigkeit benutzt haben. Dabei muss eine stabile Version des Werkzeugs zum Einsatz gekommen sein, die unverändert geblieben ist, sofern sie nicht durch einen sorgfältig konzipierten und offen gelegten Versionskontrollprozess überwacht wurde. Es bleibt die Frage, wie oft ein Compiler eingesetzt werden muss, und wie man den Einsatz quantifizieren kann. Welche Beweiskraft liegt vor, wenn ein 10 Sekunden dauernder Kompilierungslauf alle vier Stunden ausgeführt wird?
  • Die Gesamtheit der von Benutzer eingesetzten Sprach-Konstrukte muss bekannt sein.Benutzen die bestehenden Anwender, auf denen der Nachweis des tatsächlichen Betriebs beruht, die gleichen Sprach-Konstrukte, wie die, die künftig eingesetzt werden? Falls nein, welche Beweiskraft hat dieser Nachweis dann?
  • Gibt es einen vorgeschriebenen und durchsetzbaren Mechanismus um Fehler zu berichten und zu protokollieren? Falls nein, woher weiss man dann, dass der Nachweis komplett ist?
  • Alle Abweichungen vom beabsichtigten Verhalten werden sorgfältig dokumentiert und stehen für eine Überprüfung bereit. Dies setzt voraus, dass das beabsichtigte Verhalten selbst ordentlich dokumentiert ist.

Es ist unwahrscheinlich, dass es Werkzeuge gibt, die zertifiziert sind oder glaubwürdig die Kriterien eines Compiler-Nachweises im tatsächlichen Betrieb erfüllen. Es ist daher wenig überraschend, dass es in einem Anhang zu IEC 61508 lautet, dass die Verifikation bei Anwendung auf Compiler-Werkzeuge in der Regel nur nachweist, in wie weit das Werkzeug den relevanten Sprachstandard erfüllt. Darüber hinaus gibt es keine weiteren Anforderungen in Bezug auf die Sicherheit von Übersetzungswerkzeugen.

Zunächst einmal wirkt das wie eine Entlastungsklausel. Für den Entwickler von sicherheitsbezogenen Systemen bedeutet dies aber, dass er nicht weiß, ob diese Werkzeuge sicher sind. Systementwickler sind verantwortlich für die Gewährleistung der Sicherheit, und daher ist diese Information nicht als Entlastung zu verstehen, sondern als erneuter Hinweis auf die Probleme:

  • Wie kann ich sich sicher sein, dass die Compiler-Ausgangsdaten in Bezug auf die Eingangsdaten des Compilers korrekt sind? Wie kann ich wissen, ob die Compiler-Ausgangsdaten sicher sind hinsichtlich der Frage, ob die Ausgabedaten in Bezug auf die Eingangsdaten ausschließlich das beabsichtigte Funktionsverhalten bewirken?
  • Wie lässt sich der Standard definieren, der durch die Werkzeuge implementiert wird? Embedded-C Compiler erfüllen im Allgemeinen keinen der anerkannten C-Standards in vollem Umfang.

Wie bereits erwähnt, lassen sich durch den Einsatz von C die Empfehlung von IEC 61508 nicht erfüllen. Die Norm schreibt vor, dass eine stark typenorientierten Programmiersprache eingesetzt werden muss. Der Einsatz von C ist damit eine Abweichung und gilt als mögliche Fehlerquelle, die eine sinnvolle, dokumentierte und mit der bewertenden Institutionen abgestimmte Fehlermilderung erfordert.

Modified Decision Condition Coverage als Maßstab für strukturelle Codeabdeckung

Der Weg aus dem Dilemma: Falls eine detaillierte Spezifikation sowie Code als Daten-Eingang vorliegt, eröffnet eine gründliche Überprüfung des Daten-Ausgangs eine gute Möglichkeit. Die Tests in der SafeRTOS Testbench sind so ausgelegt, dass sie neben der üblichen Boundary- und Äquivalenzklassen-Analyse alle Anforderungen komplett abdecken. Die Lösung für die Werkzeug-Verifikation besteht darin, dass die Ergebnisse der SafeRTOS Testbench analysiert und so sicherstellt wird, dass eine MCDC (Modified Decision/Condition Coverage) erzielt wurde.

MCDC hat sich in der Luftfahrt-Softwarebranche als Maßstab für strukturelle Codeabdeckung etabliert. Diese erfordert, dass Testfälle jede Bedingung einer jeden Entscheidung im Programm durchspielen, und dass dabei jede Bedingung innerhalb einer Entscheidung unabhängig von anderen das Ergebnis der Entscheidung beeinflussen kann.

Betrachten wir als Beispiel die folgende Entscheidung:

if ((a>b) && (c

Die beiden Bedingungen lauten (a > b), was als CondA, und (c < d), was als CondB bezeichnet werden soll.

Die nachfolgende Wahrheitstabelle zeigt, dass es vier mögliche Eingangszustände gibt:

CondA CondB

True True

True False

False True

False False

Um MCDC-Abdeckung zu erzielen, muss nachgewiesen werden, dass bei konstant gehaltener CondA eine Modifikation von CondB das Ergebnis der Entscheidung so beeinflussen kann, dass es sowohl True wie auch False lauten kann. Auf ähnliche Weise muss es ebenfalls möglich sein, dass bei konstant gehaltenem CondB die Veränderung von CondA ein Ergebnis produzieren kann, das sowohl True wie auch False sein kann. Für diesen Fall kann man also die MCDC überprüfen, indem man Testfälle bereit stellt, deren Eingangssignale True/True, True/False und False/True lauten. Der Testfall False/False ist nicht erforderlich, da lediglich nachgewiesen werden muss, dass jede Bedingung unabhängig von der anderen das Ergebnis der Entscheidung beeinflussen kann.

Analog zu diesem logischen Betrachtungen lässt sich erkennen, dass für eine Entscheidung in der Form if ((a>b) || (c

Was spricht für Modified Decision Condition Coverage?

Folgenden Gründe sprechen dafür, MCDC als Maß für die strukturelle Abdeckung einer Software zu verwenden:

  • Genug geprüft? Es ist schwierig zu bewerten, wann genug geprüft wurde, insbesondere bei Systemen, bei denen Zuverlässigkeit höchste Bedeutung hat. Im Idealfall führt man umfassende Tests durch, dies aber ist nur selten möglich. MCDC kann in dieser Situation ein Maß für Angemessenheit bieten.
  • Angemessenheit von anforderungsorientierten Tests. Möglicherweise gibt es eine Reihe von Wegen, wie man eine Anforderung implementieren kann. Dementsprechend können ausschließlich auf der Basis von Anforderungen erzeugte Testfälle nicht gewährleisten, dass der gesamte Code durchgespielt wird. Eine strukturelle Abdeckungsanalyse hingegen bestätigt, dass die anforderungsbasierten Tests tatsächlich die gesamte Code-Struktur durchgespielt haben.
  • 3. Ermittlung nicht-beabsichtigter Funktionen. Testfälle, die eine MCDC-Abdeckung liefern, helfen beim Nachweis, dass es keine Betriebssituationen gibt, in denen sich das Programm anders als beabsichtigt verhält.
  • 4. Ermittlung von nicht-erreichbarem Code.
  • 5. Hohe Abdeckung des Objekt-Codes.

Das Erreichen einer MCDC belegt, dass jede Komponente jeder Entscheidung einzelnen überprüft wurde. Weiterhin ist damit gesichert, dass der erzeugte Objektcode sowohl für das positive wie auch für das negative Ergebnis einer solchen Entscheidungskomponente durchgespielt und dass das daraus resultierende Verhalten mit dem erwarteten Verhalten verglichen wurde.

Aufbauend auf diese Überlegungen führten wir eine gründlichen Messung und Analyse der strukturellen Code-Abdeckung durch. Ein Vergleich mit der Gesamtheit der Anforderungen für den Abdeckungstest belegt, dass wir einen großen Prozentsatz der Code-Ausgabe des Compilers durchgespielt hatten, wenn nicht sogar den gesamten erreichbaren Code. Anschließend verglichen wir das Ergebnis mit der beabsichtigten Funktion oder dem Compiler-Eingangstext. Praktisch überprüften wir damit die Interpretation des Eingangstextes durch den Compiler, anstatt uns nur darauf zu verlassen, dass sich der Compiler erwartungsgemäß verhält.

MCDC ermöglichte Sicherheits-Ingetritätslevel 3 für SafeRTOS

Die Norm IEC 61508 enthält Einschränkungen in Bezug auf den Einsatz von Programmiersprachen und Werkzeugen, die schwierig zu erfüllen sind. Aus Sorgfaltspflicht muss die Sicherheit der eingesetzten Werkzeuge bewertet werden. Der für die zivile Luftfahrt gültige Standard DO-178B wurde unter der Annahme formuliert, dass sich Compiler nicht zertifizieren lassen. Er enthält daher Schutzmaßnahmen gegen die Sicherheitsrisiken von Kompilationswerkzeugen. Die Nutzung einer dieser Maßnahmen aus DO-178B Level A - die Anforderung für MCDC - ermöglichte es, dass eine unabhängige Untersuchungsorganisation die Entwicklungsprozeduren für SafeRTOS als ausreichend für eine SIL 3 Entwicklung akzeptierte.

Man geht also davon aus, dass Kompilationswerkzeuge nicht vertrauenswürdig sind und schützt sich gegen die daraus folgenden Risiken durch eine Teststruktur. Ihr Aufbau gewährleistet, dass die Ausgabedaten des Compilers unter allen Umständen das beabsichtigte Verhalten erzeugen.

Während des Testprozesses ergaben sich zwei interessante Beobachtungen. Zusätzliche Entwicklungskosten: Hochwertige Entwicklungsprozesse erfordern präzise Verwaltung und Kontrolle sowie streng kontrollierte Entwicklungs-, Coding- und Testprozeduren. Wurden diese bereits zuvor implementiert, so schlägt der Nachweis, dass das Ergebnis dieser Prozeduren eine MCDC ermöglicht, nur mit minimalen zusätzlichen Kosten zu Buche.

Werkzeug-Unabhängigkeit: Die dabei entstandene Suite aus Testwerkzeugen und -Prozessen ist für alle Einsatzgebiete und Absichten unabhängig vom Compiler geeignet. Veränderungen an den Entwicklungswerkzeugen würden zum Nachweis der Vertrauenswürdigkeit der Compiler-Ausgabedaten eine Analyse der Auswirkungen dieser Änderungen mit einer anschließenden erneuten Ausführung des Testablaufs erfordern.

Artikelfiles und Artikellinks

(ID:255596)