Konzeptphase & Funktionales Sicherheitskonzept nach ISO 26262

Die Konzeptphase bildet den Anfang des Sicherheitslebenszyklus und ist der Grundstein eines FuSi-Projekts. Anschließend lässt sich eine realistische Projektkostenabschätzung aufstellen. Diese Phase gleicht einem Lastenheft und erfordert viel Zeit. Die wesentlichen Elemente sind die Beschreibung der bestimmungsgemäßen Funktion, die Gefahren- und Risikoanalyse sowie ein funktionales Sicherheitskonzept nach ISO 26262.

Der Normteil “3” zur Funktionalen Sicherheit nach ISO 26262 ist im Beuth-Verlag hier verfügbar.

Item-Definition

Ein High-Level-Model des Systems in SysML ist empfehlenswert für die Item-Definition. Das zu entwickelnde System soll klar funktional beschrieben sein, sodass alle Gefahren, die von diesem Item durch Fehlfunktionen ausgehen durch die G&R ermittelt werden können. Dabei ist die bestimmungsgemäße Funktion und die Interaktion mit dem Menschen (z.B. Fahrer) und der Umwelt zu beschreiben.

Die Gefahren- und Risikoanalyse (G&R)

Die G&R wird i.d.R. durch den OEM wie auch Systemzulieferer erstellt. Sie ist eine qualitative Methode zur Ermittlung der Sicherheitsziele (SateyGoals) und dem ASIL. Der ASIL (Sicherheitsintegritätslevel) gibt die quantitative Schwelle zum tolerierbaren Restrisiko vor und bestimmt als Arbeitshypothese die Maßnahmen zur Vermeidung systematischer Fehler, welche während der Entwicklung Anwendung finden müssen. Die quantitative Schwelle bezeichnet die Ausfallwahrscheinlichkeit der Hardware. Die Maßnahmen zur Vermeidung systematischer Fehler sind z.B. Analysen, Checklisten und Unabhängigkeitsgrade der beurteilenden Personen. Mit dem ASIL ist eine Proportionalität der Entwicklungskosten gegeben.

Das Item ist durch Parameterabweichungen im funktionalen Sinn auf alle mögliche Fehlerquellen zu analysieren. Diese wird durch Kombination von verschiedenen Fahrsituationen erreicht und bildet die Gefahrenquellen, deren Risiko mittels ASIL-Risikograph bewertet wird. Zum Schluss werden die Sicherheitsziele und der sichere Zustand des Systems in der G&R beschreiben. Eine mögliche Fehlertoleranzzeit ist festzulegen. Gegenebenfalls ist noch der Übergang in den sicheren Zustand oder eine Notfallreaktion festzulegen. Die G&R ist kostensensitiv und sollte mit ausreichend Aufwand und Qualität durch qualifiziertes Personal entstehen.

Einige Beispiele zur ASIL-Einstufung:

  • elektrisches Antriebssystem: ASIL B bis C
  • Fahrerassistenzsysteme: ASIL C bis D (meist machen Zeitbegrenzer in der Dekomposition eine Realisierung erst möglich)
  • Bremsensteuergerät: ASIL D (auch X-by-wire)
  • Batteriemanagementsystem ASIL A bis B
  • Selbstständig startende Systeme, die unbeaufsichtigt sind ASIL C

Sicherheitsanforderungen aus den Sicherheitszielen ableiten

Nun sind die Sicherheitsziele mit Ihren ASIL-Attribut in eine funktional sicherer Architektur einzubetten. Dazu sind funktionale Sicherheitsanforderungen zu ermitteln. Beschreiben Sie was zu tun ist, um ein Sicherheitsziel zu erreichen. Ein Beispiel: “Fu-Si-Anf-001: Es muss ein Fehler des Gaspedals innerhalb einer Zeit von …ms erkannt werden.” . Nach der Spezifikation erstellt ein Systemarchitekt oder interdisziplinär arbeitender Mechatroniker die funktionale Architektur. Hiermit beginnt das funktionale Sicherheitskonzept (FSC). Es ist realisierungsunabhängig und kann später von verschiedenen Technologien umgesetzt werden.

Das funktionale Sicherheitskonzept nach ISO 26262 beschreibt, was getan wird, um die funktionale Sicherheit zu gewährleisten, nicht wie!

Beispiel: Eine “Torque-Controller-Überwachungsfunktion” kann in Software oder Hardware auf einem Steuergerät, oder sogar auf mehrere Steuergeräte aufgeteilt werden. Um ein Optimum zu identifizieren, ist eine qualitative Methode (FTA/FMEA) empfehlenswert, um Fehler im Design der funktionalen Architektur aufzuspüren. Die zuvor ermittelten funktionalen Sicherheitsanforderungen ist im FSC in der funktional sicheren Architektur zu allokieren (an Elemente zu verknüpfen).

Funktionales Sicherheitskonzept nach ISO 26262 und Dekomposition

Die Dekomposition im Kontext der Funktionebene ist noch erwähnenswert. Sie ist ein zweischneidiges Schwert und eigentlich im technischen Sicherheitskonzept (TSC) angesiedelt. Der ASIL kann auf Subfunktionen aufgeteilt werden und damit die Entwicklung erleichtern und Kosten einsparen. Zum Anderen ist dann die funktionale Architektur signifikant geprägt und ist nicht mehr vollständig flexibel realisierbar. Der Charakter der Funktion ist entscheidend für die Möglichkeiten der Dekomposition auf der funktionalen Ebene. Wenn die bestimmungsgemäße Funktion bei Fehlern direkt abschalten darf und damit der sichere Zustand erreicht wird, so handelt es sich um eine Fail-Safe-Charakteristik. Wenn die bestimmungsgemäße Funktion jedoch im Sinne des sicheren Zustands aufrecht erhalten wird, so ist die Funktion mit der erforderlichen Ausfallwahrscheinlichkeit gemäß dem ASIL zu realisieren. Insofern handelt es sich um eine Fail-Operational-Charakteristik.

Beispiel: Eine Überwachungsfunktion ist auf Steuergerät A ausgelagert und auf ein bereits im Betrieb befindliches Steuergerät B verlegt. Nun muss dieses Steuergerät B funktionale Sicherheitsanforderungen erfüllen und damit einen ASIL. Der Vorteil einer Diversifikation und damit die einhergehende Entschärfung eines Redundanzproblems steht einer Einschränkung im Hinblick auf die Verwendung von weiteren Funktionen auf diesem Steuergerät B gegenüber. Eine Konzentration auf das Steuergerät A und eine Aufteilung dieser Funktion innerhalb dieses Steuergerätes kann kostensparender sein. Dadurch kann später im technischen Sicherheitskonzept (TSC) diese Funktion im Steuergerät B zum Beispiel von einer Statemachine auf einem FPGA neben einer MCU umgesetzt werden. Dies ermöglicht auf Teil 6 zu verzichten für diese Funktion, das spart Aufwand. Der initiale ASIL aus der G&R kann durch Dekomposition nicht verkleinert werden. Die Aufteilung unterstützt die “Freedom of interference” (Wechselwirkungsfreiheit) und beeinflusst die Architektur. Das Testen und die Validierungs- & Verifikationsaktivitäten müssen dem initialen ASIL weiterhin entsprechen.

Ein Funktionales Sicherheitskonzept nach ISO 26262 enthält nur Funktionen

Sie müssen auf funktionaler Ebene bleiben. Daher ist eine Absicherung einer CAN-Kommunikation mit Nachrichten-CRC-Check oder eine zusätzliche Aktivitätsüberwachung von Netzwerkpartnern durch einen Alive-Counter bereits eine technische Sicherheitsanforderungen (T-S-Req). Richtig wäre eine “Absicherung der Ende zu Ende Kommunikation mit Überwachung der Prozessaktivität wichtiger Teilnehmer” wäre eine funktionale Sicherheitsanforderung  (F-S-Req).

Ein 2 oder 3 Ebenen-Sicherheitskonzept ist eine gute Voraussetzung um ein tragfähioges funktionales Sicherheitskonzept nach ISO 26262 zu erhalten.

Ein “Functional safety concept” könnte folgende Inhalte besitzen:

  • Die zugrunde liegenden Sicherheitsziele und ASIL und Fehlertoleranzzeitintervalle (FTTI) aus der G&R und die Item-Definition
  • Die funktionalen Sicherheitsanforderungen (F-S-Req)
  • Die sicheren Zustände und erforderliche Notfallreaktionen außerdem funktionale Redundanzen
  • Das Warn- und Degradierungskonzept
  • Spezifikation der Fahrerreaktion und relevante Informationen für das “User Manual”
  • Spezifikation zu anderen Technologien und externen Maßnahmen zur Sicherstellung der funktionalen Sicherheit beteiligter Systeme
  • Die funktionale Architktur in SysML und die Allokation der funktionalen Sicherheitsanforderungen in der Architektur
  • ggf. eine Untersuchung der F-S-Req durch Abhängigkeitsanalysen nach Teil 9-7 oder Dekompositionen nach Teil 9-5 der Norm

Zum Schluss ist noch die Verifikation nach Teil 8-9 der Norm durchzuführen.

Die Ausgabe der Konzeptphase

Folgende wesentliche Arbeitsprodukte sind gefordert:

  • Item-Definition
  • Gefahren- & Risikoanalyse (G&R, engl. H&R)
  • Funktionales Sicherheitskonzept (FSC)

Neben diesen Arbeitsprodukten sind auch folgende Arbeitsprodukte mit viel Wissen zur Norm in dieser Phase erforderlich:

  • bei einer Modifikation eines bestehenden Item kann ein geteilter Sicherheitslebenszyklus erforderlich sein (Stichwort “Impact Analyse”)
  • Die Planung der Sicherheitsaktivitäten im Safety plan
  • der Verification review report of H&R/G&R, dieser muss z.B. nach I3 von einer unabhängigen Organisation durchgeführt werden
  • der Verification report of functional safety concept, dieser prüft das TSC auf Einhaltung und Erfüllung der Sicherheitsziele und Anforderungen