Reviews in der DIN EN 61508 (bzw. in der IEC 61508)

von Maud Schlich

DIN EN 61508

Die DIN EN 61508 Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme [61508] ist eine Norm, die ursprünglich für die Errichtung großer sicherheitsrelevanter Anlagen als IEC 61508 erstellt wurde und die funktionale Sicherheit der Anlagen so ermöglichen soll, dass diese ein tolerierbares Restrisiko darstellen.

Sie ist nicht gut für Serienprodukte geeignet, da sie aber gerade im Bereich Automotive (häufig in Deutschland, seltener in den USA) angewendet wird, wurde eine darauf aufbauende Norm erarbeitet IOS/DIS 26262. DIS steht dabei für Draft International Standard, sie ist seit 2998 öffentlich und wird vermutlich Mitte 2011 finalisiert.

Die [61508] besteht aus sieben Teilen, von denen in diesem Artikel vor allem der Teil 3 Anforderungen an die Software und Teil 7 Anwendungshinweise über Verfahren und Maßnahmen betrachtet werden.

Anforderungen an Dokumente und Code

In Kapitel 7 von Teil 3 Anforderungen an die Software werden u.a. die Anforderungen an Spezifikation der Software-Sicherheitsanforderungen (7.2) sowie  an Softwareentwurf und Softwareentwicklung (7.4) dargelegt. Diese beinhalten nicht nur Anforderungen an die Inhalte der dabei zu erstellende Dokumenten (z.B.  müssen die Spezifikationen wie in 7.2.2.11 … die Leistungsfähigkeit und  Reaktionszeit … darstellen ), sondern fordern auch die Überprüfung dieser Dokumente (7.4.4.5 Programmierrichtlinien müssen a) vom Gutachter für ihre Eignung überprüft werden …) und stellen Qualitätsmerkmale dieser Dokumente auf (Spezifizierte Anforderungen müssen 7.2.26 … a) verständlich, genau, unzweideutig, verifzierbar, testbar, pflegbar, durchführbar und angemessen zum Sicherheits-Integritätslevel sein).

Dies gilt in der gesamten [61508] für fast alle Arten von Dokumente und umfasst damit auch Planungsdokumente (z.B. 7.3.2.2 … Plan zur Validierung der Software …) und Testspezifikationen (7.4.8.2 Spezifikation für den Softwareintegrationstest …).

Verifikation

Die Verifikation wird in der [61508] im Teil 4 entsprechend der ISO 8402 verwendet:

3.8.1 Verifikation (en: verification)

Bestätigen aufgrund einer Untersuchung und durch Bereitstellung eines Nachweises, dass die Anforderungen erfüllt worden sind.

ANMERKUNG 2 In Zusammenhang mit dieser Norm ist Verifikation die Tätigkeit, die in jeder Phase des relevanten Sicherheitslebenszyklus (gesamt, E/E/PES) und Software) durch Analyse und/oder Prüfung darlegt, dass für die speziellen Eingaben die gelieferten Elemente in jeder Hinsicht die Ziele und Anforderungen erfüllen, die für diese Phase festgelegt wurden.

Als Beispiele werden dann u.a. Dokumentenprüfungen und Entwurfsüberprüfungen genannt.

Review-Verfahren

Im Teil 7 der [61508] werden verschiedene Reviewarten definiert:

Im Anhang B Überblick über Verfahren und Maßnahmen für E/E/PES: Vermeidung von systematischen Ausfällen werden

  • B3.8 Walkthrough
  • B.3.7 Inspektion (Überprüfungen und Analysen)
  • B.2.6 Inspektion der Spezifikation

vorgestellt. Wobei die Definition der ersten beiden sehr ähnlich ist:

“Festgelegte Funktionen des sicherheitsbezogenen Systems werden geprüft und ausgewertet, um zu gewährleisten, dass das sicherheitsbezogenen System den in der Spezifikation gegebenen Anforderungen entspricht…” Alle gefundenen Punkte werden dokumentiert. Der Unterschied besteht darin, dass beim Walkthrough der Autor aktiv und der Prüfer passiv sei und bei der Inspektion umgekehrt. (In B.3.8 wird fälschlicherweise das Wort Inspektion verwendet, gemeint ist aber der Walkthrough).

Bei der B.2.6 Inspektion der Spezifikation ist die Definition interessanterweise ausführlicher,  es handelt sich um ein “… Verfahren, in der verschiedene Eigenschaften einer Spezifikation von einer unabhängigen Arbeitsgruppe bewertet werden. ” Die möglichst nicht an der Erstellung beteiligten Prüfer stellen “… Fragen an den Ersteller, der diese zufriedenstellend beantworten muss.” Eine Dokumentation wird nicht gefordert,  insofern ist es nach der IEEE Std. 1028-2008 kein formales Review

Im Anhang C Überblick über Verfahren und Maßnahmen zum Erreichen der Sicherheitsintegrität der Software werden als Reviewarten

  • C.5.15 Fagan-Inspektion und
  • C.5.16 Walk-through / Entwurfsprüfungen

beschrieben.

Die Fagan-Inspektion wird nur sehr kurz als “formales Audit der Qualitätssicherungsdokumente mit dem Ziel, Irrtümer und Fehler aufzudecken” definiert und die fünf Phasen aufgezählt.  Der Literaturhinweis verweist auf [Fagan1976].

In der Darstellung von Walk-through / Entwurfsprüfungen wird die IEC 61160:1992, Formal design review mit zwei Abschnitten auffallend ausführlich mit ihren Inhalten vorgestellt. Der letzte Abschnitt geht erst auf den Walk-through selbst ein und definiert diesen als eine Prüfung durch eine Arbeitsgruppe, die “… einige Testfälle auf dem Papier mit einer repräsentativen Auswahl von Eingaben und entsprechend erwarteten Ausgaben für das Programm auswählt. Die Testdaten werden anschließend manuell Schritt für Schritt durch die Logik des Programms verfolgt.” Als Literaturhinweis wird zusätzlich (an dieser Stelle für mich besonders überraschend) auf das Buch [GilbGraham1993] verwiesen, das ja sehr formale Inspektionen zum Thema hat.

Fazit

Die [61508] fordert an vielen Stellen Dokumentenprüfungen ein. Gerade da es sich um eine Sicherheits-Norm handelt, sind formale Reviews vor allem bei besonders hohen Sicherheitsanforderungen (SIL 3 und SIL 4) daher aus meiner Sicht unabdingbar. In den informativen Teilen des Standards werden diese jedoch missverständlich (Bezeichnung als “Audit”) und sehr informell vorgestellt. Machen sich die Anwender dieser Norm nicht die Mühe, die empfohlene Literatur ebenfalls zu lesen, erhalten sie leider nur sehr wenig und teilweise irreführende Informationen zu den Reviewarten.

Ich hoffe, dass die Edition 2 der [61508], die derzeit in Arbeit ist, diese Teile ebenfalls überarbeitet und dass sie auf die [IEEE1028] verweisen wird.


Whitepaper-Banner flach

Zurück

Einen Kommentar schreiben