Seite wählen

autoConform® Methodik, Software und Ingenieurdienstleistungen

Was sind die Voraussetzungen für Systemanalysen?

1. Einleitung

Funktionale Sicherheitsnormen setzen voraus, dass die Entwicklung eines sicherheitskritischen Produkts nach dem V-Modell der Systementwicklung 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 autoConform®-Software

Wie in Abb. 1 zu sehen ist, sind Sicherheitsanalysen auf jeder Ebene der Produktarchitektur vorgesehen. Diese Sicherheitsanalysen umfassen

  • eine Gefahren- und Risikoanalyse (GuR) auf Produkt- oder Systemebene; und
  • eine Kombination aus einer deduktiven Analyse (Fehlerbaumanalyse, FTA), einer induktiven Analyse (Fehlermöglichkeits- und Einflussanalyse, FMEA) und einer Analyse abhängiger Fehler (DFA) auf allen anderen Ebenen der Produktarchitektur.

Cybersicherheitsanalysen des Systems müssen in der Regel zusätzlich zu Sicherheitsanalysen durchgeführt werden.

Darüber hinaus wird empfohlen, Komplexitätsanalysen des strukturellen Designs des Produkts durchzuführen, weil unnötige Komplexität die Produktqualität, insbesondere die Produktzuverlässigkeit, verringert und die Kosten für Produktentwicklung sowie Herstellung und Wartung/Service erhöht.

All diesen Analysen haben einige Voraussetzungen gemeinsam, die in Abschnitt 2 beschrieben werden. Abschnitt 3 fasst die wichtigsten Erkenntnisse dieses Artikels zusammen.

2. Voraussetzungen für Systemanalysen

Die erste Voraussetzung leitet sich daraus ab, dass alle Systemanalysen auf dem statischen Produktarchitekturentwurf basieren. Daher muss der statische Produktarchitekturentwurf in geeigneter Weise dokumentiert und von der obersten Ebene bis hinunter zur zu analysierenden Produktarchitekturebene vollständig sein. Wenn ein oder mehrere Produktelemente im Produktarchitekturentwurf fehlen oder wenn der Produktarchitekturentwurf „lose Enden“ in Form von offenen oder getrennten Schnittstellen und Signalen enthält, kann die auf dieser Grundlage durchgeführte Analyse irreführend sein. Denn die „losen Enden“ können dazu führen, dass wichtige Fehlerfortpflanzungs- oder Intrusionspfade übersehen werden oder die Komplexität des Systems stark unterschätzt wird.

Voraussetzung #1: Bevor eine Analyse auf einer bestimmten Produktarchitekturebene durchgeführt wird, muss der statische Produktarchitekturentwurf von der obersten Produktarchitekturebene bis hinunter zur zu analysierenden Produktarchitekturebene vollständig vorliegen.

Die zweite Voraussetzung ergibt sich daraus, dass alle in der Einleitung genannten Analysen beginnend bei der obersten Produktarchitekturebene von oben nach unten durchgeführt werden müssen. So macht es beispielsweise wenig Sinn, Sicherheitsanalysen auf Subsystemebene durchzuführen, wenn noch keine Sicherheitsanalyse auf Produkt- oder Systemebene durchgeführt wurde. Denn wir müssen zunächst wissen, welche Sicherheitsziele und Sicherheitsanforderungen das gesamte Produkt erfüllen muss, bevor wir diese Produktsicherheitsanforderungen in Sicherheitsanforderungen für die Produktelemente herunterbrechen können.

Voraussetzung #2: Eine Analyse auf einer bestimmten Produktarchitekturebene sollte erst durchgeführt werden, nachdem die entsprechenden Analysen auf allen höheren Produktarchitekturebenen abgeschlossen wurden.

Einige Analysen hängen nicht nur vom statischen Produktarchitekturentwurf ab, sondern können viel einfacher werden, wenn zuvor andere Analysen durchgeführt wurden. So werden Sicherheits- und Cybersicherheitsanalysen in der Regel immer aufwändiger, je komplexer das System ist. Daher sollte die Untersuchung der Systemkomplexität und die weitestgehende Reduzierung der Systemkomplexität immer vor der Durchführung von Sicherheits- und Cybersicherheitsanalysen erfolgen. Ein weiteres Beispiel ist die Reihenfolge, in der Sicherheitsanalysen auf einer bestimmten Produktarchitekturebene durchgeführt werden. Eine Fehlerbaumanalyse deckt sowohl die möglichen Einfachfehler als auch die Mehrfachfehler auf. Die Analyse und Behandlung von Einfachfehlern erfolgt in der Regel durch eine FMEA, die Analyse und Behandlung von Mehrfachfehlern durch eine DFA. Daher ist es sinnvoll, die Sicherheitsanalysen auf einer bestimmten Produktarchitekturebene in der Reihenfolge FTA zuerst, FMEA an zweiter Stelle und DFA an dritter Stelle durchzuführen.

Voraussetzung #3: Wenn eine bestimmte Analyse sinnvollerweise auf den Ergebnissen anderer Analysen aufbaut, dann sollten diese anderen Analysen zuerst durchgeführt werden.

Die empfohlene Reihenfolge der Systemanalysen ist die folgende.

a) Auf Produkt- oder Systemebene:

  1. Komplexitätsanalyse,
  2. GuR,
  3. Cybersicherheitsanalyse.

b) Auf allen anderen Ebenen der Produktarchitektur:

  1. Komplexitätsanalyse,
  2. Fehlerbaumanalyse,
  3. FMEA (oder ein anderes induktives Verfahren wie beispielsweise eine FMEDA),
  4. Analyse abhängiger Fehler,
  5. Cybersicherheitsanalyse.

3. Zusammenfassung

Alle Systemanalysen basieren auf dem statischen Produktarchitekturentwurf, der vollständig sein muss, d.h. frei von fehlenden Elementen oder nicht verbundenen Schnittstellen und Signalen.

Alle Systemanalysen müssen von oben nach unten durchgeführt werden, beginnend auf der obersten Ebene der Produktarchitektur, d. h. der Produkt- oder Systemebene.

Es wird empfohlen, die Systemanalysen in einer bestimmten Reihenfolge durchzuführen:

  1. Komplexitätsanalyse,
  2. Deduktive Analyse (typischerweise eine Fehlerbaumanalyse (FTA)),
  3. Induktive Analyse (typischerweise eine Fehlermöglichkeits- und Einflussanalyse (FMEA)),
  4. Analyse abhängiger Fehler (DFA) und
  5. Cybersicherheitsanalyse.
Was sind die Voraussetzungen für Systemanalysen?

Ihr Ansprechpartner:

Zugänglichkeit