Was sind die essentiellen Arbeitsprodukte auf der linken Seite des V-Modells?

1. Einleitung

Funktionale Sicherheitsnormen setzen voraus, dass die Entwicklung eines sicherheitsbezogenen oder sicherheitskritischen Produkts nach dem V-Modell erfolgt. Abb. 1 zeigt dieses V-Modell in der Form, wie es der autoConform®-Methodik und der autoConform®-Software zugrunde liegt.

Abb. 1: Systementwicklungs-V-Modell der autoConform®-Methodik und -Software

Im V-Modell der Abb. 1 steht ein Kästchen in der Regel nicht für ein Arbeitsprodukt, sondern für mehrere Arbeitsprodukte. In Abschnitt 2 wird erklärt, welche Arbeitsprodukte das sind. Abschnitt 3 erläutert, warum es sinnvoll ist, all diese Arbeitsprodukte zu erstellen, und wie die Erstellung der Arbeitsprodukte zeitsparend erfolgen kann.

2. Die Arbeitsprodukte auf der linken Seite des V-Modells

Die Übersetzung der linken Seite des V-Modells der Abb. 1 in konkrete Arbeitsprodukte ist in Abb. 2 dargestellt.

Abb. 2: Übersetzung der linken Seite des V-Modells in Arbeitsprodukte

Der Startpunkt des V-Modells ist die Design-Spezifikation (1) auf oberster Ebene („Product’s Parent Level“). Diese Design-Spezifikation unterteilt sich in zwei Dokumente:

1a) das Spezifikations-Dokument „Item Definition“, welches die Umgebung, die Schnittstellen, die Funktionen und die statischen Eigenschaften des zu entwickelnden Produkts beschreibt, und

1b) das Schnittstellen-Dokument „External System Interface Specification“, welches sämtliche beabsichtigten und unbeabsichtigten Interaktionen des Produkts mit seiner Umgebung und mit anderen externen Systemen in Form von mechanischen, elektrischen, Kommunikations- u.a. beabsichtigten Signalen sowie von unbeabsichtigten, aber unvermeidlichen Störsignalen spezifiziert.

Die Sicherheitsanalysen (2) auf der obersten Ebene entsprechen der Gefahren- und Risikoanalyse (G&R, 2a) des Produkts und den daraus abgeleiteten Sicherheitsanforderungen (2b). Die G&R (englisch: HARA – „Hazard Analysis and Risk Assessment“) liefert als Hauptergebnisse

• die Sicherheitsziele an das zu entwickelnde Produkt sowie
• die Sicherheitsintegritätsstufe (englisch: „Safety Integrity Level“, SIL) jedes Sicherheitsziels und damit auch jedes Produktausgangs.

Die höchste Sicherheitsintegritätsstufe, die einer oder mehreren der Produktausgänge in der HARA zugewiesen wird, entspricht der Sicherheitsintegritätsstufe des gesamten Produkts. Sämtliche aus der HARA ermittelten Sicherheitsintegritätsstufen werden in die vorher erstellen Arbeitsprodukte „Item Definition“ (1a) und „External System Interface Specification“ (1b) eingetragen.

Die aus der GuR in Verbindung mit der „Item Definition“ abgeleiteten Sicherheitsanforderungen an das Produkt bilden das Funktionale Sicherheitskonzept (FSK, 2b) des Produkts.

Das FSK geht in die Systemanforderungen (3) ein, ist aber in der Regel nur ein kleiner Teil von (3). Der überwiegende Teil der Systemanforderungen (3) wird aus der „Item Definition“ (1a), der „External System Interface Specification“ (1b) sowie aus den übergeordneten Anforderungen an das Produkt abgeleitet.

Auf der nächsten Ebene, der Produkt- oder Systemebene, wird als erstes die Design-Spezifikation (4) erstellt. Diese unterteilt sich in

4a) das Spezifikations-Dokument „System Architectural Design Spezification“, welches

• das System,
• die Systemzustände und -betriebsmodi sowie
• die Systemelemente mit deren
  • Schnittstellen,
  • Funktionen,
  • systemzustandsabhängigen Funktionsaktivierungen sowie
  • statischen Eigenschaften

beschreibt, und

4b) das Schnittstellen-Dokument „Internal System Interface Specification“, welches sämtliche beabsichtigten und unbeabsichtigten Interaktionen zwischen den Systemelementen innerhalb des Systems bzw. Produkts spezifiziert.

Die Sicherheitsanalysen (5) umfassen

5a) die Analysen der Produktarchitektur und des Produktdesigns

• SIL-Allokation (im Automobilbau: ASIL-Allokation),
• Fehlerbaumanalyse (FTA),
• Design-Fehlermöglichkeits- und Einflussanalyse (DFMEA) sowie
• Analyse abhängiger Fehler („Dependent Failure Analysis“ – DFA)

und

5b) Anforderungen an die Systemelemente, die sich aus den Sicherheitsanalysen „SIL-Allokation“, „DFMEA“ und „DFA“ in (5a) ergeben.

Die SIL-Allokation in (5a) ermittelt die Sicherheitsintegritätsstufe der Aus- und Eingänge jedes Systemelements und damit auch die Sicherheitsintegritätsstufe jedes einzelnen Systemelements. Analog zur Ebene darüber werden auf der Systemebene die durch die SIL-Allokation ermittelten Sicherheitsintegritätsstufen in die vorher erstellten Arbeitsprodukte „System Architectural Design Spezification“ (4a) und „Internal System Interface Specification“ (4b) eingetragen. Wir empfehlen jedoch trotzdem, das Dokument „SIL Allocation at System Level“ als eigenständiges Arbeitsprodukt zu erstellen und in die Liste der verknüpften Arbeitsprodukte, die dem Nachweis der funktionalen Produktsicherheit zugrunde liegen, aufzunehmen.

Der Zweck der FTA in (5a) besteht darin, die Einfach- und Mehrfachfehler zu bestimmen, die zur Verletzung von Sicherheitszielen führen können. Die in der FTA (und dort konkret durch den Analyseteil „Cut Set Analysis“) ermittelten Einfachfehler werden anschließend in einer DFMEA behandelt. In einer solchen DFMEA werden die notwendigen Einfachfehlervermeidungsmaßnahmen festgelegt und die zugehörigen Anforderungen formuliert. Analog zur Behandlung der Einfachfehler in einer DFMEA werden die Mehrfachfehler (Zweifachfehler) der FTA in einer DFA betrachtet, und es werden im Rahmen der DFA technische Sicherheitsanforderungen zur Mehrfachfehlervermeidung formuliert.  

Die Anforderungen (5b) werden als „technische Sicherheitsanforderungen“ bezeichnet. Sie gehen in die technischen Anforderungen (6) an die Systemelemente ein, bilden aber in der Regel den kleineren Teil der Anforderungen (6). Der überwiegende Teil der Anforderungen (6) wird aus den Arbeitsprodukten (4a) und (4b) sowie den übergeordneten Anforderungen (3) abgeleitet.

Auf den Produktarchitekturebenen unterhalb der Systemebene wiederholt sich die eben für die Systemebene beschriebene Struktur der Arbeitsprodukte. Auf der E/E-Hardwareebene kommt bei den Sicherheitsanalysen noch die FMEDA („Failure Modes, Effects and Diagnostic Analysis“) hinzu, mit der die Zuverlässigkeit des E/E-Designs quantitativ abgeschätzt wird.

Bei den Analysen von Software-Architektur und -Design können

• die deduktive Analysemethode „FTA“ und
• die induktive Analysemethode „DFMEA“

zu einer einzigen Analysemethode, der SHARD („Software Hazard Analysis and Resolution in Design“), zusammengefasst werden.

Passend zu Abb. 1 und Abb. 2 listet Tabelle 1 jedes einzelne Arbeitsprodukt auf der linken Seite des V-Modells auf.

Tabelle 1: Liste der essenziellen Arbeitsprodukte auf der linken Seite des V-Modells

3. Erstellung der Arbeitsprodukte

Die Gesamtzahl der Arbeitsprodukte hängt von der Anzahl der Produktarchitekturebenen ab. Tabelle 1 listet die Arbeitsprodukte auf für ein Produkt mit den Architekturebenen

• Systemebene,
• Subsystemebene,
• E/E-Hardwareebene,
• (Gesamt-)Softwareebene und
• Softwaredetaildesign-Ebene.

Wenn das Produkt nur aus einer Steuerplatine in einem Gehäuse besteht, dann entfallen die Ebenen „Systemebene“ und „Subsystemebene“ und damit auch die Arbeitsprodukte dieser beiden Ebenen. Andererseits ist es möglich, dass ein Produkt zusätzlich zur System- und Subsystemebene noch eine Subsubsystemebene aufweist. Auch die Softwarearchitektur kann in mehr als eine Softwaredetaildesign-Ebene unterteilt sein. Fazit: Unnötiger Analyse- und Dokumentationsaufwand kann vermieden werden, indem nur die absolut notwendigen Produktarchitekturebenen definiert werden.

Angesichts der hohen Anzahl an Arbeitsprodukten in Tabelle 1 ist die Frage naheliegend, ob man die Anzahl der Arbeitsprodukte reduzieren kann. Bei gegebener Produktarchitektur bzw. gegebenen Produktarchitekturebenen ist es leider nicht möglich, einzelne Arbeitsprodukte einfach wegzulassen, weil ansonsten entweder

• die technischen Anforderungen und Design-Entscheidungen nicht mehr vollumfänglich, nachvollziehbar „top-down“ abgeleitet und dokumentiert wären oder
• normativ geforderte Sicherheitsanalysen weggelassen würden.

Mit der autoConform®-Software steht glücklicherweise ein Werkzeug zur Verfügung, welches für alle Arbeitsprodukte geeignete Templates zur Verfügung stellt und diese zu großen Teilen automatisch befüllt. Mit der autoConform®-Software ist es möglich, alle Arbeitsprodukte vollständig, konsistent, korrekt und vor allem sehr zeitsparend zu erstellen.