Ein Angebot von

Software Safety Concept: Welche Safety-Analysen sind sinnvoll?

| Autor / Redakteur: Dr. Thomas Liedtke, Christian Bayer* / Sebastian Gerstl

Damit die funktionale Sicherheit von Embedded Software auch wirklich gewährleistet ist, lohnt es sich, von Anfang an ein Software Safety Concept aufzustellen und eine Safety-Analyse durchzuführen. Nur dann, wenn das Requirements Engineering und das Architektur-Design gründlich waren, kann ein Sicherheitskonzept auch wirklich aufgehen.
Damit die funktionale Sicherheit von Embedded Software auch wirklich gewährleistet ist, lohnt es sich, von Anfang an ein Software Safety Concept aufzustellen und eine Safety-Analyse durchzuführen. Nur dann, wenn das Requirements Engineering und das Architektur-Design gründlich waren, kann ein Sicherheitskonzept auch wirklich aufgehen. (Bild: gemeinfrei / CC0)

Safety-Analysen in der Softwareentwicklung sind – bis auf Ausnahmen – primär auf Software Architekturebene vorgesehen. Doch wie erfasst man alle für die funktionale Sicherheit erforderlichen Voraussetzungen möglichst umfassend? Und welche Aspekte muss die Safety-Analyse für ein Softwaresicherheitskonzept abdecken? Ein Beispiel aus der Praxis.

Das in diesem Beispiel beschriebene Software Safety Concept fokussiert sich auf die Software-Requirements-specification-Ebene sowie die Architectural-design-Ebene. Die Autoren stellen die im realen Kundenprojekt durchgeführten vier verschiedenen Safety Analysen vor. Dabei beschreiben sie den Zweck, gemachte Erfahrungen und typische Befunde.

Verbleibende Restrisiken können übrigens durch die konsequente Anwendung empfohlener Maßnahmen der ISO 26262 [1] Band 6: Product development at software level im weiteren Entwicklungsverlauf als ausreichend klein eingestuft werden.

Das Projekt und die Aufgabenstellung für das Software Safety Concept

Für eine Fahrerassistenzfunktion stand ein OEM vor der Herausforderung einen vorhandenen Software-Algorithmus zu optimieren und zu industrialisieren. Der Algorithmus diente zwei Kunden-erlebbaren Funktionen im sicherheitskritischen Kontext. Durch Dekomposition wurde auf Systemebene eine ASIL-B (D) Einstufung vorgenommen.

Ein technisches Sicherheitskonzept (technical safety conept/ TSK) fokussierte auf die zu erstellende Softwarekomponente (SW-C) und diente als Basis der Softwareentwicklung. Eine Plattform (Hardware und Software) mit entsprechendem Safety Manual bot die notwendige Ausführungsumgebung an.

Die Firma Elektrobit Automotive (EB) wurde damit beauftragt für die Softwarekomponente darzulegen, welche Sicherheitsmaßnahmen notwendig sind, um den Anforderungen aus dem TSK gerecht zu werden. Desweiteren wurde EB in die Softwareentwicklung auf Requirements-, Architektur- sowie die entsprechenden Testebenen eingebunden. Zur externen Beratung wurde die Safety-Expertise von Kugler Maag CIE hinzugezogen.

Aus OEM-Sicht sollte ein Dokument mit dem Titel „Software Safety Concept“ darlegen, welche Sicherheitsmechanismen warum implementiert wurden und wie diese die Sicherheit gewährleisten. Das Dokument sollte zum Finden und Dokumentieren der notwendigen Sicherheitsmechanismen dienen. Das externe Assessorenteam wollte das Dokument um die Sicherheitsanalysen und die Sicherheitsargumentation für das Projekt ausgebaut wissen, um letztlich die Freigabe der Software zu verargumentieren.

Entsprechend blickt das Projekt mit dem Software Safety Concept auf das zentrale Dokument, wenn es um Freigaben oder um die Bewertung neuer Change Requests für das Projekt geht.

Software Safety Concept

Nachdem ein seperates Software Safety Concept kein in der ISO 26262 [1] spezifiziertes Workproduct darstellt, musste zunächst der Umfang und Inhalt definiert werden. Der Zweck des Software Safety Concepts ist zum einen, die Abbildung der Safety Requirements auf die Architektur zu evaluieren. Zum anderen maßgebliche Evidenzen durch die Auswahl und die Ergebnisse durchgeführter Safety-Analysen für die Safety-Argumentation zu liefern.

Entsprechend stellten die Software Safety Requirements (betrafen im Wesentlichen die Behandlung von sicherheitsrelevanten und nichtsicherheitsrelevanten Sensoren und Signale), die abgeleitete Software-Architektur und die Traceability Matrix die Analysebasis dar, welche iterativ untersucht und angepasst wurde.

Ursprünglich war geplant, die Software in zwei Sub-Komponenten mit unterschiedlicher ASIL-Einstufung zu entwickeln. Jedoch konnte die Vermengung von Signalen mit unterschiedlicher ASIL-Allokation nicht verargumentiert und eine Freedom from Interference nicht hinreichend dargestellt werden. Es folgte die Forderung, dass sämtliche Softwareteile nach gleichem ASIL zu entwickeln sind.

Safety-Analysen in der Software werden aufgrund ihrer Wirksamkeit meist in der Architekturebene durchgeführt. Für die weitere Software-Entwicklung sollten die ASIL-orientierten Vorgaben der ISO 26262 [1] die notwendige Sicherheit geben, um verbleibende systematische Fehler auf ein Mindestmaß zu reduzieren.

Safety-Analysen

Bild 1: Bestandteile des Software Safety Concepts
Bild 1: Bestandteile des Software Safety Concepts (Bild: Kugler Maag CIE)

Zur Untersuchung folgender Fragestellungen wurden Safety-Analysen angesetzt:

  • Sind die Sicherheitsanforderungen intern und extern konsistent, vollständig und verständlich? → Systematische TSK-Analyse
  • Welches sind die kritischen Safety-Mechanismen? Werden sie mit entsprechenden Maßnahmen hinreichend sicher entwickelt? → Requirements FMEA (Failure Mode and Effect Analysis [2])
  • Ist die Architektur ausreichend abgesichert (im Sinne von vollständig logisch beschrieben), vollständig und konsistent? → Architektur HAZOP (Hazard and Operational Analysis [3])
  • Analyse und Identifikation welche Basis-Fehler zu Top-Level-Fehlversagen führen können → Fehlerbaum Analyse (FTA)

Systematische TSK-Analyse

Das technische Sicherheitskonzept des OEM bestand aus ca. 1000 Datenbankeinträgen und beinhaltete Definitionen, Systemerklärungen, Relevante Ein- und Ausgangssignale, sowie die geforderten ca. 40 funktionalen Sicherheitsanforderungen. Das klingt zunächst überschaubar und trotzdem glänzten die Anforderungen durch

  • verschachtelte Bedingungen,
  • teils mehrere Fußnoten mit weiteren Bedingungen, Ausnahmen, Referenzen auf Signaltabellen und Definitionen innerhalb des Dokuments.

Im Projekt hatte man sich entschieden, eine systematische Anforderungsanalyse gemeinsam mit dem OEM durchzuführen. Ziel war es, ein gleiches Verständnis zu schaffen und Kundenanforderungen bei Missverständnissen oder aufgedeckten Unzulänglichkeiten zu ändern.

Die Durchsprache mit dem OEM in zahlreichen Treffen wurde mitprotokolliert und die Ergebnisse dokumentiert. Bei notwendigen Änderungen an den Kundenanforderungen wurden diese solange nachverfolgt, bis die Änderung in Form neuer Kundenanforderungen bei EB vorlag.

Lessons Learned:

  • Komplexität der Anforderungen wurde unterschätzt; die Ergebnisse einer ersten TSK Durchsicht mit Anforderungsableitung mussten verworfen werden.
  • Viele implizite Annahmen wurden explizit nachdokumentiert und Terminologie geklärt.
  • Widersprüche konnten aufgedeckt und geklärt werden.

Requirements FMEA

Eine FMEA auf Requirementsebene hatte folgende Ziele:

  • Als Teil der Risiko-Analyse sollte sie frühzeitig mögliche Inkonsistenzen (interne und externe) in den Safety-Mechanismen aufdecken.
  • Die Kritikalität der einzelnen Sicherheitsmechanismen sollte evaluiert und dokumentiert werden.
  • Die protokollierte Wissensbasis sollte erhöht werden, der Kommunikationsfluss mit dem Kunden und damit verbundenem erforderlichen Wissenstransfer sollte gefördert werden.

Die Analyse-Sitzungen starteten jeweils auf Basis der negierten Anforderungen. In zwei Richtungen wurden diese evaluiert:

1. Fehlerursache: Welche Fehler können zu einer Verletzung von Safety-Anforderungen führen?
2. Fehlerauswirkung: Welches mögliche Fehlversagen kann eintreten? Dabei stellte sich heraus, dass die Kombinatorik unübersichtlich werden kann, weshalb eine einheitliche Risikobewertung erstellt wurde (Abbildung).

FMEA Risikobewertung
FMEA Risikobewertung (Bild: Kugler Maag CIE)

In mehreren Sitzungen wurden Fehlerkombinationen und deren Auswirkungen evaluiert. Typische Befunde bezogen sich auf bislang unberücksichtigte komplexe Fehlerkombinationen und Fehlerarten (lang oder kurz anliegend, instabile Situation, …). Anforderungen wurden aufgrund von Befunden entsprechend angepasst.

Architektur HAZOP

Sämtliche Diagramme (u.a. Komponenten, Sequenzen) sollten systematisch hinterfragt werden. Hierzu wurde für jede Diagrammart ein passender Fragenkatalog mit HAZOP-Leitworten [3] erstellt.

Der Prozess lief iterativ in den folgenden Phasen ab:
1. Identifikation der Design Elemente für die die Analyse durchgeführt werden soll
2. Bestimmung der Abweichungen: Anwendung der HAZOP-Leitworte auf alle Elemente eines Diagramms
3. Analyse der Abweichungen bzgl. Ursache, Folge und möglicher Verletzung einer Anforderung
4. Definition neuer Anforderungen für fehlende Maßnahmen und Anwendung von Maßnahmen
5. Allokation und Realisierung neuer Anforderungen an die Sicherheitsarchitektur oder Komponente
6. Übertragung Benutzeranforderung an die HW-/ SW-Randbedingung
7. Aktualisierung des Designs → neue Iteration beginnend bei Schritt 1

Beispiele der Anwendung möglicher Leitworte für ein Komponentendiagramm sind:

Vollständigkeit:
–> Komponente fehlt – Memory Partition fehlt – Schnittstelle fehlt – Konnektor fehlt - …
Quantitativ:
–> enthält mehr: Memory Partition umfasst unabsichtlich weitere Komponenten – Assoziation falsche Anzahl - … |
–> enthält weniger: Memory Partition umfasst nicht alle Komponenten - …

Lessons Learned:

  • Typische Befunde bezogen sich mehrheitlich auf die Testbarkeit (z.B. wie kann die vorgegebene Sequenz geprüft werden?) sowie auf Vollständigkeit (wie kann das vollständige Durchlaufen einer Schleife geprüft werden).
  • Die Diagramme wurden im Verlauf der Analyse schlüssiger und stimmiger und damit die Architektur wertvoller.

Fehlerbaumanalyse (FTA)

Um nicht nur Bottom up auf mögliche Fehlerquellen schließen zu können, wurde eine Fehlerbaumanalyse basierend auf den Ebenen Software Safety Requirements und der Safety-Architektur erstellt. Hierbei wurden minimal cut sets aufgestellt und untersucht. Die Abhängigkeiten zwischen verschiedenen Safety-Mechanismen wurden hergestellt. Die Fehlerbäume wurden in mehreren gemeinsamen Runden von Safety-Experten und Architekten aufgestellt.

Lessons Learned:

  • Obwohl die Top-level-Events sehr schnell gefunden waren gestaltete sich die Ableitung durch die Safety Mechanismen auf einzelne Single-Events schwierig.
  • Die FTA-Analyse ergab eine gute Übersicht über mögliche Kombinationen von Fehlerursachen und der Wirkung von Safety Mechanismen.

Aufwandsübersicht Safety-Analysen
Aufwandsübersicht Safety-Analysen (Bild: Kugler Maag CIE)

Fazit: Die Erstellung eines Software Safety Concepts half den Umfang des Projektes zu begreifen. Es bildet nun das zentrale Dokument inklusive wesentlicher Evidenzen für die Safety Argumentation. Bei neuen Kundenanforderungen ermöglicht es dem Team, effizient Einflussanalysen auf bestehende Safety Mechanismen durchzuführen. Der Aufwand für die Safety-Analysen war zunächst unterschätzt worden. Eine Übersicht über Dauer, Aufwand und Nutzen gibt die nebenstehende Übersicht.

Requirement Traceability: Rückverfolgung von Anforderungen pragmatisch umsetzen

Requirement Traceability: Rückverfolgung von Anforderungen pragmatisch umsetzen

25.06.19 - In sicherheitskritischen Anwendungen ist heute eine Rückverfolgbarkeit der gestellten Anforderungen verpflichtend, wenn man die gängigen Normen einhalten will. Wie lassen sich Traceability-Analysen wirkungsvoll umsetzen? Und welche potentielle Fehlerquellen lauern in der Umsetzung? lesen

Functional Safety Software Engineering: Problemfälle Prozess & Qualität

Functional Safety Software Engineering: Problemfälle Prozess & Qualität

07.03.19 - Auch fast zehn Jahre nach der Verabschiedung von ISO 26262 wird Entwickeln unter dem Aspekt Funktionaler Sicherheit als sehr aufwändig wahrgenommen. Doch für diesen wahrgenommenen Mehraufwand sind meist Defizite in Prozessen und der Softwarequalität verantwortlich. lesen

Literaturhinweise

[1] ISO 26262 Road vehicles – Functional safety 1st edition (2011)
[2] VDA-Band 4: Produkt- und Prozess FMEA (2009)
[3] HAZOP Studies on Systems Containing Programmable Electronics Part 2 General Application Guidance. Ministery of Defence. Defence Standard 00-58, (2000)

(Der Beitrag wurde mit freundlicher Genehmigung der Autoren dem Embedded Software Engineering Kongress Tagungsband 2018 entnommen)

* Dr. Thomas Liedtke ist seit 2017 Principal bei der Kugler Maag Cie GmbH und Leiter der Expert Area Security. Christian Bayer ist bei der Elektrobit Automotive GmbH als Quality Risk Manager tätig.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46133289 / Requirements)