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.
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 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:
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).
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.
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:
Zum Schluss ist noch die Verifikation nach Teil 8-9 der Norm durchzuführen.
Folgende wesentliche Arbeitsprodukte sind gefordert:
Neben diesen Arbeitsprodukten sind auch folgende Arbeitsprodukte mit viel Wissen zur Norm in dieser Phase erforderlich: