Funktionale Sicherheit
ISO 26262 in Serienprojekten
Fortsetzung des Artikels von Teil 1
OEM-Anforderungen an Zulieferer in Re-Use-Projekten
Ausgelöst durch die Forderung von ISO 26262 nach einem koordinierten Sicherheitsvorgehen mit abgestimmten Sicherheitsplänen, einem DIA (Development Interface Agreement) und einem Definitionsdokument für das fahrzeugspezifische Item oder fahrzeugunabhängige SEooC (Safety Element out of Context), beginnen viele Entwicklungsingenieure von Zulieferern ihr Verständnis für die vollständige Anwendung gründlich zu hinterfragen. Sie sehen die Notwendigkeit, nicht nur die an sie gestellten unmittelbaren Sicherheitsanforderungen zu implementieren, sondern auch das zugrundeliegende Funktionale Sicherheitskonzept zu verstehen. Dieses Streben nach einem besseren Verständnis der Sicherheitsanwendung kann zu einer wesentlichen Verbesserung der Sicherheit des gesamten System- und Software-Designs führen.
Heutige Praxis ist jedoch häufig, dass die Entwicklungsingenieure die Spezifikation des Fahrzeugherstellers mit Tausenden von Anforderungen bekommen, ohne dass das zugehörige funktionale Sicherheitskonzept kommuniziert wird. Die schiere Menge der Anforderungen macht es für das Entwicklungsteam des Zulieferers schwierig, das eigene Management davon zu überzeugen, dass es für ein zumeist als Re-Use definiertes Projekt wesentlich mehr Zeit und Ressourcen bedarf, um die Auswirkungen von neuen oder geänderten Sicherheitsanforderungen auf das Produkt zu verstehen und umzusetzen. Bei ausländischen Zulieferern, die zum ersten Mal eine Ausschreibung für ein Sicherheitssystem wie EGas oder EPS (Electric Power Steering) gewinnen, kommt erschwerend hinzu, dass die Anforderungen oft auf einem in Deutschland fest etablierten Architekturkonzept wie dem des VDA EGas Konzepts beruhen, ohne dies explizit zu beschreiben.
Ein anderer Aspekt ist die Zuordnung eines Sicherheits-Integritätsniveaus (ASIL – Automotive Safety Integrity Level) zu Sicherheitszielen. Gerade die Sicherheitsziele für Getriebe-Funktionen sind gute oder traurige Beispiele dafür, wie das ASIL mit zunehmenden Verständnis der Gefahren angepasst und erhöht werden musste. Vor einigen Jahren wurden die Sicherheitsziele für Getriebe ähnlich derer für elektronisches Motormanagement bewertet, nämlich mit ASIL B. Weitere sorgfältige Gefahren- und Risikoanalysen durch Fahrzeughersteller führten zu einer Erhöhung auf ASIL C, und heute ist das Sicherheitsziel „Zu hohes Sperrmoment muss vermieden werden“ für Hinterrad- und Allrad-Antriebe fraglos als ASIL D einzustufen. Noch gravierender ist die ASIL-Erhöhung für das Sicherheitsziel eines Untersetzungsgetriebes „Der Wechsel in den niedrigen Gang bei >100 km/h muss vermieden werden“ von QM auf ASIL D in spezifischen Anwendungen.
Abhängig von der Beziehung zwischen OEM und Zulieferer können die notwendigen Informationen in Meetings an die Entwicklungsteams des Zulieferers weitergegeben werden, in denen der Hintergrund schwierig zu verstehender Anforderungen erläutert wird. Oder aber der Zulieferer muss ein eigenes Verständniss des Funktionalen Sicherheitskonzepts entwickeln. Aus Kosten- und Zeitgründen kann dies in einem Re-Use-Projekt aber nicht geleistet werden, sondern nur für strategische Produkte des Zulieferers.
In Worst-Case-Projektsituationen führte das fehlende Verständnis für das Funktionale Sicherheitskonzept zu Lösungen, bei denen z.B. ASIL-Dekompositionen von System-Designern des Zulieferers vorgenommen wurden, wobei die dekomponierten Lösungen schlussendlich im gleichen Abschaltpfad auf Systemebene endeten. Dies wurde im konkreten Fall erst spät in der Integration und Gesamtvalidation aller Teile erkannt. Aus diesen Vorkommnissen muss man die Vorsichtsmaßnahme ableiten, dass ASIL-Dekomposition auf jedweder Verfeinerungsebene nur von System-Designern durchgeführt werden dürfen, die das Verständnis für das vollständige Funktionale Sicherheitskonzept haben.
Ein anderes Beispiel sind Sicherheitsmechanismen, um Fehler in mechanischen Komponenten zu erkennen. Eine frühzeitige Abstimmung zwischen Elektronik- und Maschinenbau-Ingenieuren hilft, späte konzeptionelle Änderungen zu vermeiden, die zu aufwändigen Re-Designs führen können. Leider wird die Beurteilung von zur Überwachung mechanischer Komponenten geeigneten Sicherheitsmechanismen in der Praxis oft viel zu lange den Elektronik- und Software-Entwicklern überlassen. Dies führte schon häufig zu Situationen, in denen erst später bei der FMEA der mechanischen Teile und bei Fehlerversuchen festgestellt wurde, dass die implementierten Sicherheitsmechanismen nicht ausreichend wirksam sind.
Die Konsequenzen aus diesen praktischen Fällen sind eine Reihe von technischen Prozessverbesserungen:
- Der Fahrzeughersteller oder Zulieferer muss ein Funktionales Sicherheitskonzept spezifizieren, das die Sicherheitsfunktionen im Gesamtzusammenhang definiert. Dies soll sicherstellen, dass die Bedeutung der Sicherheitsfunktionen von den Entwicklern des Lieferanten verstanden wird.
- Die Entwicklungsteams sollten einem Verification-Driven Design-Ansatz folgen, bei dem bereits während der Machbarkeitsstudie die Design-Vorschläge einer Fehleranalyse unterzogen werden. Die Analyse schließt alle relevanten Entwicklungsbereiche – HW, SW und Mechanik – mit ein. Diese zeitigen informellen Verifikationen müssen nicht allen Formalismen der ISO 26262 genügen, sondern dienen dem Ziel, ein solides Design zu erhalten. Die Angst der Entwickler und Projektleiter vor den Formalismen der ISO 26262 darf nicht dazu führen, dass diese notwendigen frühen technischen Fehleranalysen auf einen zu späten Projektzeitpunkt verschoben werden! Sie sind aber auch nicht geeignet, die von der Norm geforderten formalisierten Verifikationsaktivitäten, z.B. FMEA und FMEDA, später im Projekt zu ersetzen.
- Fahrzeughersteller und Zulieferer müssen ggf. gemeinsam eine Validierungsstrategie und -spezifikation entwickeln, die eine systematische Vorgehensweise für Fehlerversuche im Fahrzeug unter Berücksichtigung aller Betriebszustände, Fahrszenarien, Produktvarianten, und Validierungskriterien definiert. Um die Reproduzierbarkeit der Fehlerversuche zu erhöhen, sollten Validierungen auf physikalischen Messungen des Fahrzeugverhaltens beruhen, und nicht alleine auf einer Beurteilung des Testfahrers bzgl. der Beherrschbarkeit des Fahrzeugs.
Etablierte ECU und SW-Designs überdenken
Jüngste Rückrufe und Gerichtsverfahren von OEMs in den USA haben die Augen für Gefahren in etablierten Produkt-und Software-Designs geöffnet. Zum ersten Mal in der Funktionalen Sicherheit von Fahrzeugen hat eine Jury in den USA im Oktober 2013 Toyota für die Selbstbeschleunigung eines ihrer etablierten Mittelklasse-Wagen schuldig gesprochen und zu einer Zahlung von 1,2 Milliarden Dollar verurteilt [4]. Um zu diesem Ergebnis zu gelangen, haben Rechtsanwälte ein zwei Jahre andauerndes unabhängiges Software Re-Engineering beauftragt, welches Schwächen in der Software durch fehlende Partitionierung und Abgrenzung der Sicherheits-Software von anderen Software-Teilen und durch mangelnden Schutz kritischer Betriebssystem-Variablen aufgezeigt hat. Das Re-Engineering-Team konnte zeigen, aber nicht beweisen, dass diese Schwachstellen zur beobachteten Selbstbeschleunigungen führen können, was die Jury als ausreichend für ihren Schuldspruch befand.
Nach unserer Kenntnis sind die identifizierten Probleme der mangelnden Trennung und des mangelnden Schutzes kritischer Variablen kein Einzelvorfall in der Software dieses spezifischen Fahrzeuges von Toyota, sondern ein recht weit verbreitetes Problem in Fahrzeug-Software. Die genannten Schwächen wären sicherlich durch Software-Sicherheitsanalysen auf Architekturebene in einer frühen Projektphase identifiziert worden.
Jobangebote+ passend zum Thema
- ISO 26262 in Serienprojekten
- OEM-Anforderungen an Zulieferer in Re-Use-Projekten
- Verification-Driven Design mit ISO 26262
- ISO 26262 in der Zukunft
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Distribution
Rutronik gründet Automotive Business Unit
Call for Papers - Jetzt Vortrag einreichen
Forum Funktionale Sicherheit 2015
Interview Prof. Dr. Thomas Klindt
»Normenkonformität bedeutet nicht Rechtskonformität!«
PES
Funktionale Sicherheit in verteilten Embedded-Systemen
VDE – Teil 2
Modelle der funktionalen Sicherheit
