Deutsche BlogsFunktionale SicherheitTop_5

DO 178B/C, ISO 26262, IEC 61508: Wieviel Ebenen von Software Requirements dürfen es denn sein, bitte?

Software requirement level

In meinen täglichen Projekten in der Automobilbranche und der Automatisierungstechnik treffe ich immer wieder auf die Frage, wie viele Ebenen von Software Requirements denn nun geschrieben werden müssen. Das ist eine spannende Frage, insbesondere wenn man viel Erfahrung mit Luftfahrtprojekten hat.
Daher möchte ich in diesem Blogbeitrag dieses Thema einmal etwas näher beleuchten. Zunächst möchte ich die Vorgaben der FuSi-Standards IEC 61508, ISO 26262 und DO 178B/C vergleichen. Abschließend gebe ich noch Projekterfahrungshinweise, die auf meiner mehr als 15 jährigen Erfahrung beruhen.
Aus meiner Sicht unterteilt sich eine gute Software Spezifikation in zwei wesentliche Teile: Architektur/Design und textuelle Requirements.
Die Architektur beschreibt, meist überwiegend in grafischer Form, die Struktur und den Aufbau der Software. Insbesondere werden auch Daten- und Kontrollflüsse dargestellt. Der Schwerpunkt von textuellen Requirements wiederum liegt auf der Beschreibung der Funktionalität, sowie den zeitlichen Anforderungen an das System.

Die Ausgangsfrage dieses Blogs bezieht sich auf die Anzahl der Ebenen von textuellen Requirements. Nicht mitgezählt wird hier die Ebene der System-Requirements, welche immer vorhanden sein muss.

IEC 61508:

Die IEC 61508 definiert im Teil 3, Tabelle A1 eine Ebene von Requirements. Wobei sehr interessant ist, dass bei den empfohlenen Verfahren und Maßnahmen für semi-formale Methoden keine Maßnahmen wie Requirements Schablonen etc. genannt sind. Man könnte hier fast den Eindruck gewinnen, als ob textuelle Requirements bei der Erstellung der IEC 61508 gar nicht im Fokus standen. Denn alle weiteren Verfahren und Maßnahmen (Tabelle A2 und A4) beziehen sich eindeutig auf die Architektur und das Design der Software.
Damit ist festzuhalten, dass man gemäß der IEC 61508 maximal eine Ebene von textuellen Software Requirements erstellen muss.

ISO 26262:

Der den Software Prozess beschreibende Teil 6 der ISO26262-2011 fordert im Kapitel 6 „Specification of software safety requirements“, die Erstellung einer Requirements Ebene. Im Kapitel 8 „Software unit design and implementation“, Tabelle 7 „Notations for software unit design“ wird als eine mögliche Methode auch die Erstellung von natürlich sprachlichen Requirements für die Beschreibung der Software Units vorgeschlagen. Als weitere Methoden können aber stattdessen auch „informal notations“, „semi-formale notations“ oder „formale notations“ gewählt werden.
Die ISO 26262 fordert also für die Software auf jeden Fall die Erstellung einer Ebene von Requirements. Eine zweite Ebene von textuellen Requirements kann erstellt werden, muss aber nicht.

DO 178B/C:

Der Luftfahrtstandard DO 178B/C definiert eindeutig zwei Ebenen von textuellen Requirements (DO-178 Tabelle A2). Diese sind als High-Level Requirements und Low-Level Requirements mit eindeutigen Namen benannt. Dementsprechend hat sich in der Luftfahrtbranche das Erstellen von zwei Ebenen von Requirements (zumindest für die kritischeren Projekte (DAL A, B, C)) als nicht diskutierbarer Standard durchgesetzt.

Praxiserfahrungen und Fazit:

Für ein DAL A, B oder C Projekt in der Luftfahrt haben Sie keine Wahl, es müssen zwei Ebenen von Software Requirements erstellt werden. Im Umkehrschluss ergibt sich für mich daraus aber auch die Feststellung, dass es für alle anderen Projekte (insbesondere in der Automobilindustrie und der Automatisierungstechnik) nicht zwingend notwendig ist, mit 2 Ebenen von textuellen Requirements zu arbeiten. Insbesondere bei Projekten, bei denen der Umfang und die Komplexität der Software begrenzt sind, sollte versucht werden, mit einer Ebene von Software Requirements auszukommen. Die jahrzehntelange Erfahrung in der Luftfahrt zeigt generell, dass die zweite Ebene von Requirements, die sogenannten Low-Level Requirements (Luftfahrt) bzw. Unit Design Requirements (Automotive) in sehr großen und komplexen Softwareprojekten durchaus ihre Berechtigung haben. Gleichzeitig muss aber auch kritisch festgestellt werden, dass es sehr kostenintensiv ist, solche Requirements zu erstellen. Die Erfahrung zeigt, dass es in vielen Projekten, in der Praxis sehr schwer ist, gute, textuelle Low-Level Requirements zu schreiben. Meist sind sie entweder zu detailliert, d.h. Pseudo-Code mit viel zu vielen, nicht notwendigen Details, oder sie sind zu abstrakt, sodass sie nicht testbar sind, obwohl sie eigentlich die unterste Ebene beschreiben sollen.
Meiner Erfahrung nach kommt man in vielen Projekten der Automobilindustrie und der Automatisierungstechnik gut mit einer Ebene von textuellen Requirements aus. Man sollte sich vielmehr darauf konzentrieren, gute, testbare, eindeutige und vollständige Requirements mit dieser einen Ebene zu erstellen, anstatt den Aufwand in oft technisch nicht begründete zwei Ebenen von Requirements zu stecken.
Es soll aber auch nicht unerwähnt bleiben, dass oft die Notwendigkeit der Ermittlung der strukturellen Code Coverage dazu führt, dass man meint man bräuchte mehrere Ebenen von Requirements. Richtig daran ist, dass dies für komplexe Projekte voll und ganz zutreffend ist. Genauso stimmt es aber auch, dass für mehr als 50% der Projekte die ich bisher gesehen habe, die Komplexität nicht so hoch war, dass das Argument der Code Coverage ausgereicht hätte, um eine zweite Ebene von Requirements zu definieren.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der HEICON Homepage.

Ein Gedanke zu „DO 178B/C, ISO 26262, IEC 61508: Wieviel Ebenen von Software Requirements dürfen es denn sein, bitte?

  1. Hallo Herr Heininger,

    im Teil 10 der ISO2626 werden aber komischerweise zwei Ebenen (siehe Figure 8) – und zwar „SW safety requirements at architectural level“ und „SW safety requirements at unit level“ – unterschieden. In Teil 6 wird dagegen nicht von „requirements at architectural level“ und „… at unit level“ gesprochen, sondern nur von „Software safety requirements“. Dem entgegen ist anzumerken, dass in ISO26262 6-7 unter 7.5.3 ein „Work Product“ „Software safety requirements specification (refined)“ geannannt wird, was auch als „Input“ für das „Sofware unit design and implementation“ aufgeführt ist (8.3.1). Dass es sich um eine „optionale“ Maßnahme handelt, lässt sich ggf. von der Anmerkung bei 7.4.9 ableiten: „Following this allocation, further refinement of the software safety requirements can be necessary.“.

    Eine konsequente und konsistente Verwendung von Begriffen in der ISO26262 wäre wünschenswert (z.B. auch des Begriffes „Technical Safety Concept“).

    Schöne Grüße
    Markus Schmidt

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

This site uses Akismet to reduce spam. Learn how your comment data is processed.