Safety Automotive Sicherheitstechnische Auslegung von neuen Fahrzeugfunktionen

Risiko-Zustandsdiagramm auf Fahrzeugebene

Risiko-Zustandsdiagramm auf Fahrzeugebene

Bezüglich der Ausführung eines selbstständigen Manövervorschlags ist es notwendig, dass sicherheitsrelevante Kenngrößen wie maximales Lenkdrehmoment und maximale Anbremsverzögerung nicht überschritten werden. Generell ist der Startpunkt des Sicherheits-Lebenszyklus die Gefährdungs- und Risikoanalyse, die auch Hazard Analysis genannt wird. Bild 2 zeigt schematisch das Vorgehen.

Aus dieser Analyse ergeben sich die ASIL-Einstufungen für die Features, die dann auf Subsysteme, Komponenten, Hardware und Software nach den Regeln von ISO 26262 heruntergebrochen werden. Trägt eine Komponente zur Realisierung mehrerer Features bei, ist sie nach dem höchsten ASIL dieser Features zu entwickeln. Ein Beispiel: Wenn auf dem Controller der Frontkamera-Komponente sowohl Software-Anteile des „Traffic Sign Memory“ – eingestuft als QM – und des „Collision Imminent Braking“ – eingestuft als „ASIL-B“ unter gewissen Randbedingungen – laufen, so ist die Hardware des Controllers nach den Anforderungen für ASIL-B zu entwickeln.

Ein weiteres Beispiel soll die Auswirkungen von verschiedenen Leistungscharakteristiken und unterschiedlichen ASIL-Dekompositionen verdeutlichen. Wird die Verzögerungswirkung des „Collision Imminent Braking“ eingeschränkt auf unterhalb einer festgelegten Hazard-Metrik, zum Beispiel 0,4 g, so ist das Feature als QM einzustufen. Jedoch muss die Sicherheitsfunktion nach dem höchsten ASIL ausgelegt werden, weil durch zufällige Hardware-Fehler hervorgerufene Fehlfunktionen bei der G&R zu berücksichtigen sind. Bild 3 zeigt zwei mögliche Auslegungen. Weil bei Variante 2 sich die zusätzliche Sicherheitsfunktion auf dem Electronic Brake Controller (EBCM) mit minimalem Zusatzaufwand realisieren lässt, ist diese Variante aus Kostengründen zu präferieren

Fahrerassistenzsystem als Klassifizier

Bei Entscheidung des Assistenzsystems zu einer Notfallintervention ist es wichtig festzustellen, dass der Fahrer vorher gewarnt wurde und immer die Möglichkeit hat, das autonome Fahrmanöver zu unterbrechen. Blendet man diese Aspekte für ein einfaches Modell aus, handelt es sich bei einem solchen System um einen binären Klassifizierer. Aufgrund der erfassten Information wird entweder ein Manöver ausgeführt oder nicht.

Weil die Entscheidung immer auf Grundlage der vorhandenen Information getroffen wird, ist die Trenngüte zwischen diesen Entscheidungen eine Frage der Kalibrierung. Eine getroffene Entscheidung kann falsch sein, wobei als Maßstab die Trennschärfe eines guten Fahrers ohne unterstützende Systeme dient. Als Modell lässt sich eine ROC-Kurve (Bild 4) wählen, wobei die Richtig-Positiv-Rate (Sensitivität) über die Falsch-Positiv-Rate (1-Spezifität) aufgetragen wird. Werden die Folgen eines falsch positiven Ereignisses und eines falsch negativen gewichtet, so ergibt sich das Optimum der Kalibrierung bei der Tangente der Winkelhalbierenden mit der Kalibrierungslinie. Je nachdem, ob der Kundennutzen bei einem Unfall oder die Qualität des Systems im Normalbetrieb optimiert wird, verschieben sich die notwendigen Kalibrierungsparameter. Unabhängig von der Gewährleistung der funktionalen Sicherheit durch einen Prozess nach ISO 26262 ist es daher notwendig, die sicherheitsgerichtete Leistungsfähigkeit des Klassifizierers zu validieren.

Prozessschnittstelle zum Lieferanten

Eine wichtige Voraussetzung für die Durchführung erfolgreicher Functional-Safety-Projekte ist intensives Lieferanten-Management. Im System-Safety-Engineering-Prozess von General Motors wird das durch ein Development Interface Agreement, kurz DIA, sichergestellt. Durch dieses gemeinsame RASI-Chart werden die Verantwortlichkeiten für alle notwendigen Aktivitäten und Arbeitsprodukte festgelegt. Des Weiteren werden regelmäßige Meetings zum Projektfortschritt auf technischer und auf Management-Ebene sowie Safety Peer Reviews am Ende einer jeder Projektphase vereinbart, um die Arbeitsschritte zu planen sowie die Arbeitsergebnisse abzunehmen. Vorgesehen ist ferner die Möglichkeit von Ad-hoc-Audits der System- und Software-Entwicklungsprozesse, zum Beispiel nach AutomotiveSPiCE, ISO 15504 oder CMMI sowie ein Eskalationsprozess im Rahmen des Advanced Program Quality Process (APQP) und Production Part Approval Process (PPAP).

 

Die Autoren

Dr. Christian Sachs 
ist nach seinem Physikstudium in Göttigen, München, Lausanne und anschließender Promotion in Berlin seit 2002 bei der Adam Opel AG / General Motors Europe beschäftigt. Bis 2012 war er für die Wasserstoffsicherheit im GM-Brennstoffzellenprogramm verantwortlich. In der Abteilung Systems Engineering – Funktionale Sicherheit betreut er aktuell die ISO-26262-konforme Produktentwicklung auf Fahrzeugebene.
Dr. Manfred Schölzke 
studierte Informatik an der Technischen Universität Kaiserslautern, wo er auch promovierte. Seit 2007 ist er bei der Adam Opel AG tätig, zunächst als Senior Process Engineer und anschließend als Gruppenleiter „System Configuration and Release Management“. Seit 2012 leitet er die Gruppe „Funktionale Sicherheit und Tools“.