1. Einleitung

Sicherheitsbezogene und sicherheitskritische Produkte müssen nach branchenspezifischen Standards für funktionale Sicherheit und Informationssicherheit („Cybersecurity“) entwickelt werden. Für die Automobilindustrie sind dies die ISO 26262 und die ISO 21434.

Alle Normen für funktionale Sicherheit und Cybersecurity stellen Anforderungen an

• den Produktentwicklungsprozess und
• Arbeitsergebnisse, die nachweisen, dass das Produkt zuverlässig ist und keine Sicherheitsziele während der bestimmungsgemäßen Verwendung des Produkts oder bei vorhersehbarem Produktmissbrauch verletzt werden können.

Die Anzahl der Anforderungen, die durch diese Normen gestellt werden, ist beträchtlich, und die einzelnen Anforderungen lassen Interpretationsspielräume. Es ist deshalb schwierig, diese Normen vollständig und korrekt anzuwenden. Noch schwieriger ist es, ein Produktentwicklungsprojekt vollständig normkonform UND effizient durchzuführen.

Deshalb arbeiten

• AutoFusa Consultancy Services Pvt Limited aus Bengaluru, Indien, und
• automated conformance GmbH aus Nürnberg, Deutschland,

zusammen, um ihren Kunden ein umfassendes Angebot an Schulungen, Beratungen und praktischen Ingenieurdienstleistungen anzubieten, die dazu beitragen, die Prozess- und Produktkonformität mit den relevanten Standards für funktionale Sicherheit und Cybersecurity zu erreichen. Die beiden Unternehmen haben jeweils ein spezielles Software-Tool entwickelt:

• das AutoPro-Tool, von AutoFuSa, für die Einhaltung von Prozessen und
• die autoConform® Software für ein normkonformes Produktdesign.

In Abschnitt 2 wird beschrieben, wie das AutoPro-Tool eine effiziente Prozesskonformität ermöglicht. Analog dazu wird in Abschnitt 3 beschrieben, wie die autoConform® Software eine effiziente Produktdesignkonformität ermöglicht. In Abschnitt 4 werden abschließend die Vorteile und der Nutzen dieser Software-Tools bei der Produktentwicklung zusammengefasst.

2. Prozesskonformität mit Hilfe des AutoPro-Tools

Das AutoPro-Tool stellt den V-Modell-basierten Prozessablauf der Produktentwicklung nach ISO 26262 dar. Abb. 1 zeigt diesen Prozessablauf für die „Konzeptphase“ nach ISO2626-3. Sobald die Ergebnisdokumente (FSC und FSC-Verifizierungsbericht) erstellt wurden, werden sie in den Ausgabebereich des AutoPro-Tools hochgeladen. Im Tool werden diese Ergebnisdokumente automatisch überall dort angezeigt, wo sie als Eingangsdokumente verwendet werden. Der Status jedes Dokuments wird durch die jeweilige Farbdarstellung angezeigt.

Abb. 1: ISO 26262 Konzeptphase Prozess und Arbeitsprodukte im AutoPro-Tool.
© AutoFusa Beratungsdienste Pvt Limited

Das AutoPro-Tool ist serverbasiert und wird beim Kunden installiert. Das Tool bietet die Möglichkeit, externe Stakeholder über Webschnittstellen mit vollständig konfigurierbaren Zugriffsrechten zu verbinden, die der ISO 27001:2022 entsprechen. Dies hilft dem Product Owner, andere Stakeholder effektiv zu managen, wie in Abb. 2 gezeigt.

Abb. 2: Anbindung verschiedener Stakeholder an das AutoPro-Tool.
© AutoFusa Beratungsdienste Pvt Limited

3. Befüllung der Produktdesign-Dokumente mit Hilfe der autoConform® Software

Die autoConform® Software ermöglicht die halbautomatische Erstellung des Inhalts aller Arbeitsprodukte auf der linken Seite des V-Modells sowie der Testfallspezifikationen auf der rechten Seite des V-Modells. Die Anzahl der benötigten Arbeitsprodukte hängt von der Anzahl der Architekturebenen des zu entwickelnden Produkts ab. Abb. 3 zeigt das V-Modell für ein Produkt mit mit ingesamt vier Architekturebenen, die sich aufteilen in zwei Systemebenen (in der Abbildung als „Produkt- oder Systemebene“ und als „Subsystemebene“ bezeichnet), eine Hardwareebene und eine Softwareebene.

Abb. 3: V-Modell für ein Produkt mit 4 Architekturebenen plus der übergeordneten Ebene des Produktkontexts.
© automated conformance GmbH

Auf der linken Seite des V werden auf jeder Architekturebene

• eine Spezifikation für den architektonischen Entwurf (in Form eines Spezifikationsdokuments und eines Schnittstellendokuments),
• ein Architekturmodell,
• Sicherheitsanalysen (d. h. HARA auf oberster Ebene; FTA, DFMEA und DFA auf allen anderen Ebenen; FMEDA auf der E/E-Hardware-Ebene) und
• Anforderungsspezifikationen

benötigt. Abb. 4 listet alle diese Arbeitsergebnisse für ein Produkt mit 4 Architekturebenen auf. Wie in der Abbildung dargestellt, sind das ingesamt 48 Dokumente. In Abb. 4 heißt es aber auch, dass nur 10 verschiedene Dokumenttypen als Vorlagen für all diese Arbeitsprodukte ausreichen. Mit Hilfe der autoConform® Software werden die Inhalte der Arbeitsergebnisse halbautomatisch „top-down“ erstellt, was um ein Vielfaches schneller ist als eine rein manuelle Erstellung.

Abb. 4: Arbeitsprodukte auf der linken Seite des V-Modells für ein Produkt mit 4 Architekturebenen.
© automated conformance GmbH

4. Vorteile und Nutzen

Wie ermöglichen das AutoPro-Tool und die autoConform® Software ihren Kunden, FuSa- und Cybersec-Prozess- und Produktkonformität auf systematische und einfache Weise zu erreichen?

Das AutoPro-Tool bietet eine integrierte Prozess- und Dokumentationsumgebung. Die Hauptvorteile des Tools bestehen darin, dass es

• das Team durch den durch die Produktarchitektur und den FuSa-Standard definierten Workflow führt,
• einen aktuellen Status der Prozesskonformität während der Projektdurchführung bietet und
• den Aufwand und die Dauer von Statusbewertungen und Audits reduziert.

Die autoConform® Software ermöglicht eine halbautomatische Erstellung der Inhalte aller technischen Arbeitsprodukte des V-Modells, einschließlich der bidirektionalen Rückverfolgbarkeit zwischen den Arbeitsprodukten. Detaillierte Konstruktionsspezifikationen und Prüfberichte werden von der autoConform® Software nicht abgedeckt. Diese Arbeitsergebnisse werden in der Regel mit Hilfe von CAD- und Testwerkzeugen erstellt.

Die Erstellung von Design- und Designanalyse-Dokumenten mit Hilfe der autoConform® Software dient zwei Zwecken:

• Qualität: die Konsistenz der Arbeitsergebnisse und Übereinstimmung des Prozesses ihrer Erstellung mit der branchenspezifischen Norm für funktionale Sicherheit (e.g. ISO 26262) und
• Zeit: Minimierung des Zeit- und Arbeitsaufwands, der für Erstellung, Überprüfung/Review und Finalisierung aller Arbeitsprodukte erforderlich ist.

Merkmal (i) minimiert produktbezogene Risiken, während Merkmal (ii) die Produktentwicklungs-kosten und die Markteinführungszeit reduziert.

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

In diesem Beitrag geht es darum, wie Inhalte und Reihenfolge der Arbeitsprodukte (d.h. der Dokumente) des V-Modells so definiert werden können, dass eine iterationsfreie Erstellung aller Arbeitsprodukte möglich ist.

Ein iterationsfreier V-Modell-Ablauf hat zwei entscheidende Vorteile.

1. Die initiale Befüllung aller Arbeitsprodukte des V-Modells kann in einem iterationsfreien V-Modell deutlich schneller erfolgen als in einem V-Modell, das nicht iterationsfrei ist.
2. Eine Produktdesignänderung oder -korrektur, die in einem bestimmten Arbeitsprodukt des V-Modells vorgenommen wird, kann in einem iterationsfreien V-Modell nur Auswirkungen auf nachfolgende Arbeitsprodukte haben. Auf Basis der Verknüpfungen („Traces“) zwischen den Inhalten voneinander abhängiger Arbeitsprodukte können diese Auswirkungen sehr schnell vollumfänglich ermittelt werden.

Mit anderen Worten:

1. Eine Produktentwicklung nach einem iterationsfreien V-Modell ist deutlich schneller als eine Produktentwicklung nach einem nicht iterationsfreien V-Modell.
2. Die normativ geforderte „Impact Analysis“

• bei Modifikation eines sicherheitskritischen Produkts oder
• bei Verwendung eines sicherheitskritischen Produkts in einem anderen Kontext

ist deutlich leichter durchzuführen, wenn die produktentwicklungsbegleitenden Dokumente einem iterationsfreien V-Modell folgen.

Abschnitt 2 beschreibt den iterationsfreien V-Modell-Ablauf. Abschnitt 3 fasst die Voraussetzungen für einen iterationsfreien V-Modell-Ablauf zusammen.

2. Iterationsfreier V-Modell-Ablauf

Der iterationsfreie V-Modell-Ablauf ist in Abb. 2 dargestellt.

Abb. 2: Iterationsfreier V-Modell-Ablauf

 Abb. 2 stellt den V-Modell-Ablauf für ein Produkt dar, dessen Produktarchitektur aus

• einer Systemebene
• n Subsystemebenen (von denen die letzte die E/E-Hardwareebene ist) und
• 2 Softwareebenen

besteht. Abb. 2 zeigt damit, dass es in einer Produktarchitektur grundsätzlich beliebig viele System-, Hardware- und Softwareebenen geben kann. Im einfachsten Fall enthält die Produktarchitektur eines elektronischen Produkts mit eingebetteter Software nur eine E/E-Hardwareebene und zwei Softwareebenen (nämlich die Gesamtsoftware-Ebene und eine Softwaredetaildesign-Ebene). Alle weiteren System-, Hardware- und Softwareebenen kann es geben, muss es aber nicht geben.

In Abb. 2 ist der Arbeitsablauf mit grünen Pfeilen dargestellt. Der V-Modell-Ablauf beginnt links oben beim Arbeitsprodukt „Item Definition“ und dem Arbeitsprodukt „External System Interface Specification“. Diese beiden Arbeitsprodukte stehen in engem Zusammenhang miteinander und sollten zusammen erstellt werden.

Ähnliches gilt für die Sicherheitsanalysen „(A)SIL-Allokation“, „FTA“, „DFMEA“ und „DFA“ auf jeder Produktarchitekturebene und den aus diesen Analysen erstellen Sicherheitsanforde-rungen: auch diese Arbeitsprodukte stehen in engem Zusammenhang miteinander und sollten deshalb zusammen erstellt werden.

In Abb. 2 gibt es bidirektionale Pfeile nur zwischen

• den Design- und Interface-Spezifikationen (ganz links) und
• den Sicherheitsanalysen (in der zweiten Block-Spalte von links).

Diese Darstellung trägt der Tatsache Rechnung, dass

• die Sicherheitsanalysen (in der zweiten Block-Spalte von links) die Informationen aus den Design- und Interface-Spezifikationen (ganz links) benötigen und andererseits
• Informationen wie das „(Automotive) Safety Integrity Level“, kurz „(A)SIL“, erst mit den Analysen „Hazard Analysis and Risk Assessment“ sowie „ASIL Allocation“ ermittelt und anschließend in die Design- und Interface-Spezifikationen eingetragen werden.

Aus Abb. 2 ergibt sich kein eindeutiger iterationsfreier Ablauf. Es ist (theoretisch) möglich, zuerst die Blockspalte ganz links (Design- und Interface-Spezifikationen) in Abb. 2 von oben nach unten zu bearbeiten, anschließend die zweite Blockspalte von links (Sicherheitsanalysen) von oben nach unten, danach die dritte Blockspalte (Anforderungen) von oben nach unten und schließlich die vierte Blockspalte (Testspezifikationen).

Der übliche und präferierte Ablauf ist aber der von links nach rechts, Ebene für Ebene, beginnend bei der obersten Ebene.

3. Voraussetzungen für ein iterationsfreies V-Modell

Nach einem iterationsfreien V-Modell kann immer dann gearbeitet werden, wenn sich alle Anforderungs-, Design- und Test-Spezifikationen auf eine hierarchisch Produktarchitektur beziehen können, in der alle physischen Hardware- und Softwareelemente und ihre jeweiligen Funktionen durch Dekomposition von oben nach unten definiert wurden.

Die erwarteten Inhalte jedes Arbeitsprodukts müssen ferner so definiert sein, dass sie nur Inhalte voraussetzen, die in einem der vorgelagerten Arbeitsprodukte enthalten oder definiert sind.

Die Arbeitsprodukt-Templates der autoConform®-Methodik und -Software sind so gestaltet, dass sie diese beiden Voraussetzungen erfüllen. Der iterationsfreie V-Modell-Ablauf ist einer der wesentlichen Schlüssel, um den Produktentwicklungsprozess wesentlich zu beschleunigen.

1. Einleitung

Um die gewünschte Qualität und Sicherheit eines elektronischen Produkts zu erreichen, müssen die qualitäts- und sicherheitsrelevanten Funktionen und Eigenschaften des Produkts und seiner Komponenten während der Produktentwicklung bestimmt und optimiert und während der Produktfertigung erreicht und aufrechterhalten werden. Die Identifikation und Optimierung dieser Produktfunktionen und -eigenschaften geschieht während der Produktentwicklung durch

• Definition von Produktfunktionen und deren messbaren Produktmerkmalen,
• Design-Sicherheitsanalysen, die immer mindestens eine Design-Fehlermöglichkeits- und Einflussanalyse (DFMEA) umfassen,
• Simulationen auf Basis von physikalischen und datengestützten Produktmodellen sowie
• Herstellung und Test von Hardware-Prototypen des Produkts.

Mit Kenntnis der kritischen Produktfunktionen und -eigenschaften erfolgt die Identifikation, Optimierung und Steuerung von Produktionsprozessparametern, die die kritischen Produkteigenschaften beeinflussen, durch

• Prozess-Sicherheitsanalysen des Produktionsprozesses (PFMEA),
• Auswertungen von Produktprüfungen an Prototypen und in der Serienproduktion sowie
• KI-Vorhersagemodelle für die Prozessparameter samt Auslegung der Sollwerte und Spezifikationen.

Die Maßnahmen zur Qualitätssicherung in der Produktion werden als eine Abfolge von Kontrollschritten im Produktionslenkungsplan beschrieben. Die Beschreibung jedes Kontrollschritts umfasst die angewandte Methodik, die verwendeten Geräte und Werkzeuge sowie die Qualitäts- und Akzeptanzkriterien.

Abschnitt 2 beschreibt, wie qualitäts- und sicherheitsbezogene Produkteigenschaften in der Produktentwicklungsphase vorteilhaft identifiziert und optimiert werden. Abschnitt 3 stellt dar, wie sich die Produkteigenschaften und die Prozessparameter in der Produktionsumgebung effizient überwachen, optimieren und steuern lassen. Abschnitt 4 beschreibt, in welcher Form

• die automated conformance GmbH und
• die Contech Software & Engineering GmbH

die beschriebenen Methodiken Ihren Kunden bereitstellen.

2. Wie lassen sich qualitäts- und sicherheitsrelevante Produkteigenschaften und Produktionsprozessparameter identifizieren und optimieren?

Als Anwendungsbeispiel betrachten wir den Antriebsstrangwechselrichter eines Elektrofahrzeugs – ein sicherheitskritisches System im Fahrzeug, dessen Ausfallwahrscheinlichkeit aufgrund von Hardwarefehlern sehr gering sein muss. Zu den berücksichtigten Hardwarefehlern gehören Ausfälle von

• Wechselrichterkomponenten,
• trennbaren Steckverbindern und
• festen Verbindungen wie Laserschweißverbindungen.

Beispielhaft betrachten wir nun etwas genauer die Laserschweißverbindungen der Stromschienen im Leistungsteil des Wechselrichters. Die Ausfallrate dieser Laserschweißverbindungen hängt, neben den Betriebsbedingungen, wesentlich von ausgewählten Eigenschaften der Laserschweißverbindung ab wie beispielsweise der Schweißtiefe und -geometrie. Diese Eigenschaften werden wiederum von ca. 40 Parametern des Laserschweißprozesses beeinflusst. Eine Kombination aus einer DFMEA und einer Analyse von Produktprobenmessungen zeigt, dass die Laserschweißprozessparameter „Spaltmaß in z-Achse“, „lokale Wärmeabfuhr während des Schweißprozesses“, „Leistung und reflektierte Leistung“, „Schweißrichtung“ sowie „Schweißnaht-Querversatz“ aufgrund ihrer Variabilität (und damit hohen „Risikozahl“) die wichtigsten sind. Auf Basis statistischer Versuchsplanungsmodelle werden Messungen an Produktstichproben durchgeführt und optimale Werte der Produktionsparameter durch eine Engineering-KI ermittelt. Anschließend werden diese optimalen Parameterwerte bei der Herstellung weiterer Produktmuster verwendet und validiert.

Abb. 1 zeigt den gesamten Prozess mit seinen acht Schritten.

Abb. 1: Achtstufiges Vorgehen zur Identifizierung und Optimierung qualitäts- und sicherheitsrelevanter Produkteigenschaften und Produktionsprozessparameter. © Contech Software & Engineering GmbH, https://www.contech-analyser.de/

3. Wie kann man die Parameter des Produktionsprozesses während der Produktion überwachen und optimieren?

Während des Aufbaus des Serienfertigungsprozesses wird die Überwachung, Steuerung und Regelung der kritischen Produktionsparameter implementiert, um die Qualität und Funktionssicherheit des herzustellenden Produkts zu gewährleisten.

Abb. 2 zeigt den Aufbau und den Prozess der Online-Überwachung, -Steuerung und -Regelung von Produktionsprozessparametern. Dargestellt ist, wie Maschinendaten über die unterschiedlichen Industrie-Standard-Kommunikationsschnittstellen wie OPC UA, Ethernet/IP, Modbus, Profinet etc. ausgelesen, in eine Datenbank übertragen und vom Engineering-KI-System Analyser® der Firma Contech Software & Engineering in Echtzeit analysiert werden. Der Analyser® sagt die Qualität vorher und gibt dem Werker Informationen, Handlungsempfehlungen, Maßnahmen und Lösungen, um nachhaltig auf Qualität zu fertigen. Es kann auch eine Online-Anbindung des Engineering-KI-Systems Analyser® an ausgewählte Maschinen implementiert werden, die kritische Maschinenparameter automatisch – ohne Maschinen-Bediener oder Werker – nachjustiert, s. Abb. 2.

Abb. 2: Online-Überwachung und -Steuerung von Produktionsprozessparametern. © Contech & Engineering GmbH, https://www.contech-analyser.de/

Dem Industrialisierungs-Ingenieur zeigt die Engineering-KI an,

• ob das Vorhersagemodell nach Gegenmessungen noch nachhaltig valide ist oder ob nachgelernt werden muss;
• ob Messfehler bei Qualitätsmerkmalen bzw. Einflussgrößen vorliegen könnten sowie
• ob zeitnah Kalibrierungs- bzw. Messsystemanalysen anstehen.

4. Methodik und Angebot an die Kunden

Für die in den vorangegangenen Abschnitten beschriebenen Produktentwicklungs- und Produktfertigungsschritte bieten die Firmen automated conformance GmbH und Contech Software & Engineering GmbH geeignete Methoden, Ingenieurdienstleistungen und Software an.

Die automated conformance GmbH hat die autoConform®-Methodik und -Software entwickelt und bietet auf dieser Basis Engineering-Dienstleistungen für eine normkonforme und schnelle Durchführung aller Entwicklungsphasen eines sicherheitskritischen Produkts an. Die autoConform®-Methodik und -Software ermöglichen unter anderem die teilautomatisierte Erstellung technischer Design-, Anforderungs- und Testspezifikationen, der System-, Hardware- und Software-Architekturen sowie der normativ geforderten Sicherheits- und Zuverlässigkeitsanalysen des Produktdesigns und des Produktionsprozesses.

Die Contech Software & Engineering GmbH ist eine Engineering-Firma mit eigenem patentierten Engineering-KI-System, das auf Basis kleiner Stichproben für robuste Produkte und stabile Prozesse in der Industrie sorgt. Ein gegebenes Produktdesign sichert Contech ab, indem sie die Produktfunktionalitäten samt Sollwerten und Toleranzen durch physikalische und datengestützte Simulationen, Prototypen-Tests sowie KI-Vorhersagemodelle auslegt. In der Industrialisierungsphase werden mit der Methode Robust Design und der Engineering-KI sämtliche Prozessparameter mit Sollwerten und Spezifikationen ermittelt und in der Serienproduktion in Echtzeit nachhaltig auf Qualität gesteuert und geregelt. Dadurch lassen sich die in Design- und Prozess-FMEAs identifizierten Risiken signifikant reduzieren.

Zusammen bieten die beiden Unternehmen ein umfassendes Angebot an Methoden, Ingenieurdienstleistungen und Software für eine effiziente und qualitativ hochwertige Produktentwicklung und -herstellung an. Das kombinierte Angebot der beiden Firmen ermöglicht

• eine schnelle Markteinführung eines neuen oder modifizierten Produkts
• bei minimalen technischen Risiken,
• reduziertem Energie-, Material- und Ressourcenverbrauch
• zu geringeren Kosten.

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

Parameter sind typischerweise in allen Dokumenten des V-Modells enthalten, auf der linken wie auf der rechten Seite des V, und auf allen Ebenen. Parameter sind nicht auf Softwareparameter in Form von Softwarekonfigurationsdaten und Softwarekalibrations-daten beschränkt. Konfigurations- und Kalibrationsparameter gibt es ebenso auf den System- und Hardware-Ebenen.

Eine korrekte Handhabung aller System-, Hardware- und Softwareparameter ist Voraussetzung für ein korrektes Variantenmangement.

Abschnitt 2 macht einen Vorschlag, wie Parameter in den V-Modell-Dokumenten vorteilhaft gehandhabt werden können. Abschnitt 3 erläutert die Vorteile dieses Vorschlags.

2. Handhabung von Parametern in den V-Modell-Dokumenten

Der Vorschlag zur Handhabung von Parametern in den V-Modell-Dokumenten besteht aus den Teilen A, B, C und D.

(A) Es wird vorgeschlagen, dass sämtliche Parameter in einem zentralen Parameter-dokument spezifiziert werden. Statt eines Parameterdokuments kann es auch zwei, eines für System- und Hardware-Parameter und das andere für Software-Parameter, geben.

Solche Parameterdokumente sind hinsichtlich ihrer Struktur identisch zu Schnittstellen-dokumenten (Interface-Dokument), in denen verallgemeinerte Signale spezifiziert wer-den: Parameter- und Interface-Dokumente bestehen jeweils nur aus einem Dokumenten-blatt mit den Parameter- bzw. Signalattributen. Die Attribute, die einen Parameter charak-terisieren, sind dabei nahezu dieselben wie die Attribute, die ein Signal charakterisieren.

(B) Es wird vorgeschlagen, dass alle Parameternamen so gewählt werden, dass anhand des Namens offensichtlich ist, dass es sich um einen Parameternamen handelt. Eine Möglichkeit, dies zu erreichen, besteht darin, dass jeder Parametername mit einem String beginnt, der ausschließlich in Parameternamen verwendet wird.

Beispiele:

• „PARAM_“ oder
• „PAR_“ oder
• „P__“.

(C) Sämtliche Attribut-Werte (wie beispielsweise der Default-Wert eines Parameters) werden lt. (A) im zentralen Parameterdokument spezifiziert. Um die übrigen Dokumente, in denen ein spezifischer Parameter vorkommt, lesbarer zu machen, wird vorgeschlagen, dass nach jedem Parameternamen in runden Klammern der Default-Wert des Parameters angegeben wird.

Beispiel:

PAR_Spring1Stiffness_Npm(4.7N/m)

Anmerkung: Wenn der Parametername bereits die Einheit des Parameterwerts enthält, dann muss die Einheit in den runden Klammern nicht unbedingt wiederholt werden.

Werden weitere Parameterattribut-Werte für die Lesbarkeit einer Textstelle benötigt, wird vorgeschlagen, in den runden Klammern nach dem Parameternamen alle für die Lesbarkeit benötigten Parameterattribut-Namen gefolgt vom zugehörigen Parameterattribut-Wert aufzulisten: (Parameterattribut_#1-Name: Parameterattribut_#1-Wert, Parameterattribut_#2-Name: Parameterattribut_#2-Wert, …).

Beispiel:

PAR_Spring1Stiffness_Npm(DEFAULT: 4.7N/m, MINIMUM: 4.4N/m, MAXIMUM: 5.0N/m).

(D) Schließlich wird vorgeschlagen, dass alle Zahlenwerte, die in mehr als einem V-Modell-Dokument benötigt werden, nicht als „nackte“ Zahlenwerte, sondern als Parameter in den V-Modell-Dokumenten erscheinen.

Beispiel: Statt in der HARA und anderen Dokumenten die Fehlertoleranzzeit zum Sicherheitsziel #1 (SG1) mit „500ms“ einzutragen, wird stattdessen „PAR_FTTI_SG1_ms(500ms)“ oder „PAR_FTTI_SG1_ms(500)“ eingetragen.

3. Vorteile des Vorschlags zur Parameterhandhabung

Durch Vorschlag (A), jeden Parameter in einem zentralen Parameterdokument zu spezifizieren, wird sichergestellt, dass die Parameternamen in allen V-Modell-Dokumenten eindeutig und einheitlich sind.

Durch die Vorschläge (B), (C) und (D) wird sichergestellt, dass alle in den V-Modell-Dokumenten wiederholt vorkommenden Zahlenwerte automatisiert aktualisiert und so konsistent und korrekt gehalten werden können.

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.

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.

1. Einleitung

Praktisch alle funktionalen 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 -Software

In diesem V-Modell werden auf der linken Seite des V auf jeder Produktarchitekturebene, beginnend bei der obersten,

1. eine Designspezifikation,
2. eine oder mehrere Sicherheitsanalysen sowie
3. eine Anforderungsspezifikation

in dieser Reihenfolge erstellt. Auf der rechten Seite des V stehen die Verifikations- und Validierungsspezifikationen sowie die zugehörigen Testberichte.

Innerhalb einer Produktarchitekturebene werden die technischen Anforderungen in der Anforderungsspezifikation teilautomatisiert aus der Designspezifikation und den Sicherheitsanalysen generiert. Die Rückverfolgbarkeit jeder einzelnen generierten Anforderung zu den Quellen in der Designspezifikation sowie in den Sicherheitsanalysen derselben Produktarchitekturebene ist gegeben, weil die zugehörigen Verknüpfungen von der autoConform®-Software automatisch erstellt werden.

Analog ist die Rückverfolgbarkeit aller Verifikations- und Validierungstestspezifikationen zu den zugehörigen technischen Anforderungen gegeben, weil die Testspezifikationen aus den Anforderungen teilautomatisiert generiert und dabei auch die Verknüpfungen zwischen Anforderungen und Testspezifikationen automatisch erstellt werden.

Es bleibt deshalb nur zu klären, wie die Rückverfolgbarkeit von Designentscheidungen und Anforderungen zwischen benachbarten Produktarchitekturebenen durch automatisches Setzen von Verknüpfungen sichergestellt werden kann. Abschnitt 2 beschreibt die Verknüpfung von Designentscheidungen und Abschnitt 3 die Verknüpfung technischer Anforderungen. Abschnitt 4 fasst die wesentlichen Voraussetzungen für eine automatisierte Rückverfolgbarkeit von Anforderungen, Designentscheidungen und Tests zusammen.

2. Automatisierte Verknüpfung von Designentscheidungen benachbarter Produktarchitekturebenen

Jedes Spezifikationsdokument beschreibt eine „Mutter“ (englisch: „parent“) und ihre „Kinder“ (englisch: „child elements“).

Die Verknüpfungen zwischen den Einträgen hierarchisch benachbarter Spezifikationsdokumente kann deshalb automatisiert erfolgen, weil

1. die Spezifikationsdokumente auf jeder Produktarchitekturebene gleich aufgebaut sind,
2. eine „Mutter“ im Spezifikationsdokument einer Produktarchitekturebene bereits im Spezifikationsdokument eine Produktarchitekturebene darüber als „Kind“ eingeführt wurde und
3. die Verbindung zwischen „Mutter“ und „Kind“ (sowie zwischen „Mutterfunktionen“ und „Kindfunktionen“) innerhalb eines Spezifikationsdokuments beschrieben ist.

Wenn die Spezifikationsdokumente aller Produktarchitekturebenen mit Hilfe der autoConform®-Software erstellt wurden und die gerade beschriebenen Informationen in den Spezifikationsdokumenten enthalten sind, dann kann die autoConform®-Software die Verknüpfung von Designentscheidungen, also die Verknüpfung von Einträgen in den Spezifikationsdokumenten benachbarter Produktarchitekturebenen, automatisch vornehmen.

3. Automatisierte Verknüpfung technischer Anforderungen benachbarter Produktarchitekturebenen

Bei der automatischen Verknüpfung der technischen Anforderungen benachbarter Produktarchitekturebenen wird ausgenutzt, das

a) die autoConform®-Software auf jeder Produktarchitekturebene in derselben Art und Weise die technischen Anforderungen aus dem Spezifikationsdokument der jeweiligen Produktarchitekturebene generiert,

b) bei der Generierung der technischen Anforderungen die im Spezifikationsdokument eingeführten Namen für Mutter- und Kindelemente sowie deren Funktionen, Schnittstellen und Signale unverändert verwendet werden

und darüber hinaus

c) die Spezifikationsdokumente benachbarter Produktarchitekturebenen miteinander verknüpft sind (s. den vorangegangenen Abschnitt 2).

Unter diesen Voraussetzungen kann die autoConform®-Software die Verknüpfung technischer Anforderungen, also die Verknüpfung von Einträgen in den Anforderungsdokumenten benachbarter Produktarchitekturebenen, automatisch vornehmen.

1. Einleitung

Strukturelle Komplexität, genauer: eine geringe strukturelle Komplexität, ist ein Qualitätsmerkmal eines System- oder Softwaredesigns. Wenn das System- oder Softwaredesign strukturell komplex ist, dann ist es

• zeitaufwändiger und damit teurer, es zu entwickeln,
• technisch schwieriger und damit teurer, es herzustellen und zu warten,
• fehleranfälliger und damit weniger zuverlässig und
• schwerer zu verstehen und damit bezüglich seiner Sicherheitsargumentation weniger überzeugend.

Daher ist es wichtig, die strukturelle Komplexität im System- und Softwaredesignprozess zu minimieren. Angenommen, wir haben zwei mögliche System- oder Softwarearchitekturentwürfe: wie können wir entscheiden, welcher Entwurf besser ist, weil seine strukturelle Komplexität geringer ist?

Wie lässt sich die strukturelle Komplexität eines Systems oder einer Software quantifizieren?

Eine Systemarchitektur (und analog eine Softwarearchitektur) ist durch mehrere Aspekte gekennzeichnet, nämlich

1. die Dekomposition des Systems in seine physischen Systemelemente,
2. die Dekomposition der Systemfunktionen in Systemelementfunktionen,
3. die physischen und funktionalen Schnittstellen und ihre wechselseitigen Abhängigkeiten innerhalb des Systems und seiner Elemente sowie
4. die verallgemeinerten Signale (d.h. die Übertragung von Informationen, Material oder Energie) und ihre wechselseitigen Abhängigkeiten innerhalb des Systems und seiner Elemente.

Wir suchen ein Maß für die strukturelle Komplexität, mit dessen Hilfe wir

1. die Abhängigkeiten der physischen Systemelemente,
2. die Abhängigkeiten der Funktionen der Systemelemente,
3. die Abhängigkeiten der systeminternen Schnittstellen und
4. die Abhängigkeiten der systeminternen (verallgemeinerten) Signale

bewerten können.

Darüber hinaus wollen wir ein wichtiges Merkmal sicherheitskritischer Systeme berücksichtigen: je höher die geforderte Sicherheitsintegrität eines Systemteils ist, desto weniger strukturell komplex darf dieser Systemteil sein.

Abschnitt 2 beschreibt, wie wir vorschlagen, strukturelle Komplexität zu messen und zu reduzieren. Abschnitt 3 fasst die Hauptgedanken dieses Artikels zusammen.

2. Welches ist das geeignetste Maß für die strukturelle Komplexität?

2.1. Strukturelle Komplexität wovon?

Der Inhalt dieses Abschnitts 2.1 und des nachfolgenden Abschnitts 2.2 basiert weitgehend auf [1].

Wie bereits in der Einleitung erwähnt, handelt es sich bei struktureller Komplexität um system- oder softwareinterne Abhängigkeiten: Je mehr Abhängigkeiten vorhanden sind, desto höher ist die strukturelle Komplexität. Abb. 1 zeigt beispielhaft einen Abhängigkeitsbaum und die zugehörige Abhängigkeitsstrukturmatrix A (die in der englischen Fachliteratur als „Dependency Structure Matrix“, kurz „DSM“, bekannt ist).

Abb. 1: Abhängigkeitsbaum (links) und zugehörige DSM (rechts), entnommen aus [1], S. 34.

Es können

1. die Abhängigkeiten der physischen Systemelemente,
2. die Abhängigkeiten der Systemelementfunktionen,
3. die Abhängigkeiten der systeminternen Schnittstellen und
4. die Abhängigkeiten der systeminternen (verallgemeinerten) Signale

durch Abhängigkeitsbäume und DSMs dargestellt werden.

2.2. Empfohlenes Maß für die strukturelle Komplexität

Die Beeinflussung anderer oder die Beeinflussung durch andere Systemelemente muss nicht direkt erfolgen – sie kann auch indirekt über Zwischenverbindungen stattfinden. Um dies zu erfassen, schlagen wir ein Maß für die strukturelle Komplexität vor, das sowohl direkte als auch indirekte Verbindungen in der Systemarchitektur berücksichtigt.

Bei sicherheitskritischen Systemen kann man nicht davon ausgehen, dass alle Systemelemente die gleiche Sicherheitsintegrität haben. Um dieser Tatsache Rechnung zu tragen, wichten wir die Systemelemente entsprechend ihrer Sicherheitsintegrität. Die zugehörige Wichtungsmatrix ist gegeben durch

Als strukturelles Komplexitätsmaß c schlagen wir die Frobenius-Norm der spaltengewichteten erweiterten Erreichbarkeitsmatrix R^ext vor, wobei die Spalten entsprechend der Sicherheitsintegrität der Systemelemente gewichtet werden:

Welche Werte sollten für die skalaren Wichtungen gewählt werden?

In den nachstehenden Tabellen 1 und 2 geben wir Empfehlungen, die davon abhängen, ob die Systemelemente nach

1. den „Safety Integrity Levels (SILs)“ der IEC 61508 oder
2. den „Automotive Safety Integrity Levels (ASILs)“ der ISO 26262

klassifiziert sind.

Tabelle 1: Empfohlene Wichtung der Systemelemente mit SIL-Klassifizierung

Tabelle 2: Empfohlene Wichtung der Systemelemente mit ASIL-Klassifizierung

Die ISO 26262:2018, Teil 9, ermöglicht eine sogenannte „ASIL-Dekomposition“ von Sicherheitsanforderungen. In der Praxis wird diese Idee auf ASIL-Dekompositionen von Systemelementen und Systemfunktionen ausgeweitet, die die dekomponierten Sicherheitsanforderungen erfüllen. Die Wichtungen in Tabelle 2 wurden so gewählt, dass jede Art von ASIL-Dekomposition „komplexitätsneutral“ ist. Ein Beispiel für eine solche ASIL-Dekomposition ist in Abb. 2 a) und b) dargestellt, wobei die strukturelle Komplexität in a) und b) gleich ist.

Abb. 2: Abhängigkeitsbäume (a) ohne und (b) mit ASIL-Dekomposition.

2.3 Reduzierung der strukturellen Komplexität

Nehmen wir an, wir haben einen statischen Systemarchitekturentwurf. Für diesen Entwurf bestimmen wir den c-Wert. Die strukturelle Komplexität des Systems zu reduzieren bedeutet, nach alternativen Architekturentwürfen mit niedrigeren c-Werten zu suchen (durch „Ausprobieren“).

Niedrige c-Werte werden in der Regel erreicht durch

• Definition von Abhängigkeiten, die sich von oben nach unten „verzweigen“, aber weiter unten nicht wieder „verbinden“,
• Einführung von SIL/ASIL-Dekompositionen und zugehörigen Sicherheitsmechanismen so nahe wie möglich an den sicherheitsbezogenen Ausgängen des Systems und
• Sicherstellung, dass ein möglichst großer Teil der Systemfunktionalität nicht sicherheitsbezogen bzw. sicherheitskritisch ist.

3. Zusammenfassung

In diesem Artikel wurde ein strukturelles Komplexitätsmaß c aus der Netzwerktheorie auf sicherheitskritische Systeme übertragen. Dieses Maß c für die strukturelle Komplexität basiert auf einer spaltengewichteten erweiterten Erreichbarkeitsmatrix. Eine solche Erreichbarkeitsmatrix kann bestimmt werden für

1. das physische System und seine Dekomposition in physische Systemelemente,
2. das System und seine funktionale Dekomposition,
3. die Schnittstellenketten, die in den sicherheitsbezogenen Ausgangsschnittstellen des Systems enden, und
4. die (verallgemeinerten) Signalketten, die in den sicherheitsbezogenen Ausgängen des Systems enden.

Die folgenden Eigenschaften, die von einem strukturellen Komplexitätsmaß erwartet werden, werden erfüllt durch c:

1. c ist ein Maß im mathematischen Sinne (vgl. z.B. [2]). Insbesondere ist bei einem System, das aus den n Elementen s₁, …, s_n besteht, der Wert von c unabhängig von der Reihenfolge der Systemelemente s₁, …, s_n.
2. Der Wert von c steigt mit der Anzahl n der Systemelemente.
3. Der Wert von c steigt mit der Anzahl der direkten oder indirekten Abhängigkeiten zwischen den Systemelementen.
4. Der Wert von c steigt mit zunehmendem „Safety Integrity Level“ der Systemelemente.

Literatur

[1] Sturtevant, D.J.: „System design and the cost of architectural complexity“, 2013, https://dspace.mit.edu/handle/1721.1/79551

[2] Maß (Mathematik) – Wikipedia

1. Einleitung

Verzögerungen in Produktentwicklungsprojekten sind oft auf fehlende Kompetenzen, unklare Anforderungen oder unausgereifte Technologien zurückzuführen. Diese Risiken müssen frühzeitig erkannt und adressiert werden, um Produktentwicklungsprojekte erfolgreich und effizient abzuschließen.

2. Risikominimierungsstrategien

1. Erforderliche Kompetenzen sicherstellen

Ein Entwicklungsprojekt kann nur mit einem kompetenten Team normkonform durchgeführt werden. Neben dem Kompetenzmanagement sollten die Verantwortlichkeiten und die projektinternen Kunden-/Lieferantenbeziehungen klar definiert sein, um reibungslose Abläufe zu gewährleisten.

2. Anforderungen vollständig formulieren

Die Erstellung einer vollständigen Designspezifikation der obersten Produktarchitekturebene ist der erste Schritt. Sie bildet die Grundlage für die Erstellung der Sicherheitsanalyse auf dieser Ebene im zweiten Schritt. Die Ableitung eines vollständigen Satzes technischer Anforderungen dieser Ebene ist der dritte Schritt. Diese drei Schritte werden für die jeweils nächste darunterliegende Produktarchitekturebene wiederholt.

3. Nur hinreichend ausgereifte Technologien verwenden

Technologien, die in noch keinem ähnlichen Produkt verwendet wurden, sollten erst in einem Forschungs- oder Vorentwicklungsprojekt verwendet und geprüft werden. Ihre Integration in Produktentwicklungsprojekte ist erst nach Erreichen eines ausreichenden Reifegrads sinnvoll.

3. Zusammenfassung

Die Minimierung von Risiken erfordert:

• ein kompetentes Team,
• präzise und vollständige Anforderungen,
• den Einsatz ausgereifter Technologien.

Eine strukturierte Vorgehensweise reduziert Risiken und sichert den Erfolg von Entwicklungsprojekten.

1. Einleitung

Die Bewertung der erreichten Marktreife eines Produkts ist essenziell, um den Fortschritt eines Entwicklungsprojekts nachvollziehbar zu machen. Ein systematischer Ansatz verbindet die technische Anforderungsspezifikation mit den Verifikationsnachweisen, um die Marktreife transparent zu bewerten.

Dieser Beitrag zeigt, wie diese Verbindung hergestellt wird und wie der Restaufwand bis zur vollen Marktreife abgeschätzt werden kann.

2. Marktreife bewerten

1. Voraussetzungen

Die Marktreife eines Produkts kann nur präzise bewertet werden, wenn:

• alle Sicherheitsanalysen abgeschlossen sind,
• alle Anforderungen an das Produkt und seine Elemente – einschließlich der Anforderungen an Produktion, Betrieb, Wartung und Entsorgung – formuliert sind und
• eine klare Integrations- und Teststrategie vorhanden ist.

2. Verknüpfung von Anforderungen und Testberichten

Durch eine bidirektionale Verknüpfung zwischen Anforderungen und Testberichten wird nachvollziehbar:

• welche Anforderungen erfolgreich getestet wurden und damit nachweislich korrekt implementiert sind und
• welche Anforderungen noch offen oder in Bearbeitung sind.

3. Restaufwand visualisieren

Burndown-Diagramme bieten eine effektive Methode, um den Fortschritt zu visualisieren. Sie zeigen den Anteil der erfolgreich implementierten und getesteten Anforderungen im Verhältnis zu allen Anforderungen. Anhand der bereits erbrachten Aufwände kann die Höhe der noch benötigten Restaufwände abgeschätzt werden.

3. Zusammenfassung

Die transparente Bewertung der Marktreife wird möglich durch:

• abgeschlossene Produktsicherheitsanalysen,
• vollständige technische Anforderungen und zugehörige Testspezifikationen,
• Burndown-Diagramme zur Visualisierung der implementierten Anforderungen und des Ist-Aufwands in Bezug zu den noch zu implementierenden Anforderungen.

Mit dieser Methode lassen sich Projekte effizient steuern und die Marktreife jederzeit nachvollziehbar darstellen.