Generische Strukturierung von Sicherheitsnachweisen von Fahrcomputern für automatisierte Fahrzeugsysteme des Level 3

In der Entwicklung sicherheitsrelevanter elektronischer Steuerungssysteme für Kraftfahrzeuge werden von den an der Entwicklung beteiligten Unternehmen gezielt Maßnahmen zur Vermeidung systematischer Fehler und zufälliger Ausfälle umgesetzt. Ausgangspunkt der Systementwicklung ist in der Regel ein strenger „Top-Down“-Entwurfsprozess, an dessen Beginn die Vorgabe von Zielgrößen (Automotive Safety Integrity Level, ASIL) für die Systementwicklung steht. Die ASIL bestimmen den Umfang der umzusetzenden Maßnahmen zur Vermeidung systematischer Fehler sowie zufälliger Ausfälle eines zu entwickelnden sicherheitsrelevanten elektronischen Steuerungssystems. Diese Vorgehensweise eines strengen „Top-Down“-Entwurfsprozesses ist nicht immer möglich:

Die zuvor dargestellten Herausforderungen erfordern ein anderes Vorgehen in der Entwicklung sicherheitsrelevanter Steuerungssysteme für Kraftfahrzeuge. Die internationale Norm für die Entwicklung funktional sicherer elektronischer Steuerungssysteme für Kraftfahrzeuge sieht deshalb vor, dass Komponenten, welche in sicherheitsrelevanten Systemen im Kraftfahrzeug eingesetzt werden sollen auch außerhalb ihres spezifischen Anwendungskontexts entwickelt werden können (Safety Element out of Context, SEooC nach ISO 26262-10). Dieser Beitrag stellt dar, unter welchen Rahmenbedingungen generische Sicherheitsnachweise in der Entwicklung sicherheitsrelevanter Steuerungssysteme für Kraftfahrzeuge zum Einsatz kommen.

Unter Generizität wird die Eigenschaft eines anwendungsunabhängigen Elements verstanden, Klassen von Anwendungen (auf Ebene eines Items nach ISO 26262) realisieren zu können. Abb. 1 stellt die Betrachtungseinheit eines Fahrcomputers (controller) für das hochautomatisierte Fahren dar.

Aus dieser Abstraktion heraus können – in Anlehnung an die in anderen Verkehrsmoden etablierte Vorgehensweise der Sicherheitsnachweisführung (vgl. [1]) – verschiedene Kategorien an Sicherheitsnachweisen differenziert werden:

Für alle drei Kategorien ist die grundsätzliche Struktur des Sicherheitsnachweises im Wesentlichen identisch. Allerdings sind zwischen den Sicherheitsnachweisen bestehende Abhängigkeiten zu beachten. Dies wird im nächsten Abschnitt beschrieben.

Bereits heute sieht die ISO 26262 die Möglichkeit einer Betrachtung generischer Elemente vor. Dies wird in der ISO 26262 als so genanntes „Safety Element out of Context“ (SEooC) gehandhabt. In diesem Sinne verfügt ein SEooC abstrakt gesprochen über die prinzipielle Fähigkeit, in späteren Integrationsstufen zu einem ASIL-qualifizierten Produkt zu führen (vgl. Abb. 2).

Dies führt zu einer Schnittstelle zwischen verschiedenen Sicherheitsnachweisen auf unterschiedlichen Betrachtungsebenen des Systems. Dies wird nachfolgend durch die Differenzierung des unterlagerten Sicherheitsnachweises vom integrierenden Sicherheitsnachweis beschrieben:

Die Rolle des Sicherheitsnachweises in der hochgradig verteilten Systementwicklung in der Automobilindustrie ist zuvor dargestellt worden. Aus dieser Rolle heraus resultieren besondere Anforderungen an die Ausgestaltung der Gefährdungsanalyse und der Sicherheitsnachweisführung. Dies wird im nächsten Abschnitt dargestellt.

In der Entwicklung eines sicherheitsrelevanten elektronischen Steuerungssystems für Kraftfahrzeuge müssen verschiedene Entwurfsaufgaben strukturiert bearbeitet werden. Hierfür sind methodische Vorgehensweisen erforderlich, die den Bearbeiter zu einer vollständigen Bearbeitung der Entwurfsaufgabe zwingen. Die methodische Vorgehensweise sollte hierbei die grundlegenden Wirkzusammenhänge im Systemkontext offenbaren. Der Sicherheitsnachweis hat also – auch für den Bearbeiter selbst – eine Funktion der Unterstützung im Systementwurf:

Bereits zuvor ist deutlich geworden, dass eine zentrale Aufgabe des Sicherheitsnachweises die strukturierte Darlegung der die Entwicklung eines sicherheitsrelevanten elektronischen Steuerungssystems für Kraftfahrzeuge leitenden Sicherheitserwägungen ist. Der Sicherheitsnachweis hat somit eine Dokumentationsfunktion. Dies führt zur folgenden Anforderung an die Darstellung im Sicherheitsnachweis:

Die Automobilindustrie ist geprägt von einer hochgradig differenzierten Aufgabenteilung entlang der Wertschöpfungskette. Sicherheitsnachweise fixieren den genauen Funktionsumfang sowie die entwurfsleitenden Annahmen. Ein Sicherheitsnachweis dient also auch der Kommunikation zu einem unbeteiligten Dritten darüber, auf welcher Grundlage eine höhere Integrationsstufe (generische Anwendung, spezifische Anwendung) aufsetzen kann. Die Kommunikationsfunktion des Sicherheitsnachweises führt zur folgenden Anforderung an die Darstellung im Sicherheitsnachweis:

Ziel der ISO 26262 ist die Vermeidung von E/E-Ausfällen. Die Norm legt einen Sicherheitslebenszyklus fest und beschreibt, wie ein auf die Funktionale Sicherheit ausgerichtetes Systems Engineering aussehen soll. Eine zentrale Aufgabe in der Konzeptphase ist die Durchführung einer Risikoanalyse (Hazard Analysis and Risk Assessment, HARA). Die Risikoanalyse umfasst die beiden Teilaufgaben der Risikoidentifikation und der Risikobewertung. Während die Risikobewertung durch Nutzung der Risikoparameter in ISO 26262‑3 klar festgelegt ist, lässt die Norm eine Wahlfreiheit für die anzuwendende Methode zur Risikoidentifikation. Konventionelle Ansätze der Risikoidentifikation sind Fehlerbaumanalysen (Fault Tree Analysis, FTA), die Fehlermöglichkeits- und Einflussanalyse (FMEA, vgl. [3] und [4]) sowie die Durchführung einer Hazard and Operability Study (HAZOP, vgl. [5]). Diese Ansätze haben jedoch Einschränkungen bei der Risikoidentifikation in komplexen (Mensch-Maschine)Systemen. Dementsprechend gibt es die Notwendigkeit, die Wirksamkeit anderer Ansätze für Risikoidentifikation zu untersuchen. STAMP/STPA (Theoretic Accident Model and. Processes/Systems Theoretic Process AnalysisSTPA) hat sich in der Literatur als geeigneter Ansatz herausgestellt. Qualitative Vergleiche der Ergebnisse mittels konventioneller Methoden (bspw. FMEA) durchgeführter Gefährdungsanalysen mit den Ergebnissen einer mit STAMP/STPA durchgeführten Gefährdungsanalysen zeigen, dass diese Methode für die Nutzer anwendbar ist und zu vergleichbaren Ergebnissen führt [6]. Weitergehendes Potenzial zeigt sich hinsichtlich einer Einbettung von STAMP/STPA in einen ganzheitlichen modellbasierten Entwurfsprozess softwareintensiver sicherheitskritischer Systeme für Automotive-Anwendungen [7], bzw. der Prozessindustrie [8]. Aus Sicht der Autoren adressiert STAMP/STPA die zuvor genannten Anforderungen an den Sicherheitsnachweis für Automotive-Anwendungen:

Die zuvor definierten Anforderungen werden durch die Methode STAMP/STPA (Systems-Theoretic Accident Model and Processes, Systems-Theoretic Process Analysis) angepasst an die ISO 26262 umgesetzt. Das methodische Vorgehen folgt dabei dem Vorgehensmodell in Abb. 3. Hierbei ist auf der linken Seite der für die Konzeptphase der Systementwicklung relevante Ausschnitt aus dem Sicherheitslebenszyklus zu dargestellt. Bei einem Fahrcomputer handelt es sich nicht um ein Item im Sinne der ISO 26262. ISO 26262‑3 ist somit nicht anwendbar. Allerdings sollte für die Ableitung von Annahmen zur Entwicklung des SEooCs eine übergeordnete HARA der (potentiell später) integrierenden Items vorgenommen werden.

Auf der rechten Seite ist die Vorgehensweise von STAMP/STPA nach [9] dargestellt. Aus der Gegenüberstellung ergeben sich erforderliche Ergänzungen in der Vorgehensweise nach [9] insbesondere hinsichtlich der Bewertung der erkannten Gefährdungen nach Schwere (Severity), Auftreten (Exposure) und Kontrollierbarkeit (Controllability). Die Pfeile zwischen den beiden Vorgehensweisen verdeutlichen, dass STAMP/STPA die Erstellung zentraler Dokumentationsartefakte einer Systementwicklung nach ISO 26262 sowohl methodisch als auch hinsichtlich des gewählten Beschreibungsmittels (Regelstrukturen) unterstützt. So setzt beispielsweise die Entwicklung sicherheitsrelevanter elektronischer Steuerungssysteme für Kraftfahrzeuge voraus, dass zunächst einmal eindeutig bestimmt wird, was Gegenstand der Entwicklung des funktional sicheren Systems sein soll. Die hierfür einschlägige internationale Norm spricht hierbei von einer Item Definition (vgl. [11]).

Nachfolgend wird dargestellt, wie der eigentliche Scope einer Systementwicklung durch die semi-formale Notation der STPA/STAMP-Analyse fixiert werden kann. Gegenstand der hier durchzuführenden Identifikation generischer funktionaler Sicherheitsanforderungen ist ein Fahrzeugcomputer, welcher für die Anwendung hochautomatisierter Fahrfunktionen geeignet ist. Die STPA sieht zur Beschreibung des Items vor, die sog. hierarchischen Regelungsstrukturen als semi-formale Beschreibungsmethode zu verwenden. Um diese Struktur zu erstellen, ist zuerst notwendig die logischen im System enthaltenen Komponenten zu identifizieren und deren Wirkzusammenhänge zu beschreiben. Dies ist exemplarisch in der folgenden Abb. 4 erfolgt.

Die Regelstruktur des Fahrcomputers sieht dabei eine Differenzierung zwischen sog. Basisfunktionalitäten (z. B. Betriebssystem, AUTOSAR, etc.) und spezifischen Applikationen zur Durchführung der operativen Fahraufgabe (z. B. Objekterkennung, Trajektorienplanung, Aktuatormodelle, etc.) vor. Die Sensorsignale können entweder direkt oder über andere fahrzeuginterne Kommunikationssysteme an den Fahrzeugcomputer gegeben werden. Nach Verarbeitung der Sensorinformationen durch die spezifischen Applikationen, gibt der Fahrcomputer die Aktuatorbefehle direkt/indirekt an die Fahrzeugaktuatoren (Lenkung, Bremse, Antrieb) und übernimmt so die operative Regelung des Fahrzeugs. Um nun die notwendigen Sicherheitsziele für Fahrcomputer zu bestimmen, ist gemäß ISO eine Definition u. a. der Betriebsmodi, der kompletten Funktionalität und Schnittstellen des SEooC des Items, hier der Fahrcomputers, notwendig (analog zur „Item Definition“ aus ISO 26262-3). Diese sind gemäß ISO wie in Tab. 1 dargestellt zu definieren.

Je nach Automatisierungslevel muss der Fahrzeugcomputer einen „fail operational mode“ ermöglichen, also der Fehlerfall muss ebenfalls abgesichert sein. Die Gefährdungen auf Fahrzeugebene bei denen ein potentieller Schadensfall eintreten kann, sind in Tab. 2 dargestellt.

Da bisher nicht eindeutig ist, welche spezifische Assistenz der Fahrzeugcomputer übernimmt (z. B. Spurhaltefunktion, Spurwechselfunktion, etc.) sind die hier definierten Gefährdung sehr generisch gehalten und beziehen sich ausschließlich auf unerwünschte Reaktionen auf Fahrzeuglevel. Um nun generische funktionale Sicherheitsanforderungen und die entsprechende ASIL Einstufung für Fahrzeugcomputer zu identifizieren, schlägt die STPA die Identifikation der sog. Unsafe Control Actions (UCA) vor. Hierunter sind verschiedene unerwünschte Regelungsaktionen zu verstehen, welche potentiell eine der Gefährdungen hervorrufen können. Basierend auf der generischen Regelungsstruktur eines Fahrzeugcomputers ergeben sich 13 UCAs, welche es im Nachgang durch eine Szenariobetrachtung im Rahmen der Hazard Analysis and Risk Assessment (nach ISO 26262) zu analysieren, zu bewerten und an die Entwicklung in Form von funktionalen Sicherheitsanforderungen zu geben sind (vgl. Tab. 3).

Sicherheitsziele nehmen in der Entwicklung von sicherheitsrelevanten Steuerungssystemen für Kraftfahrzeuge eine zentrale Rolle ein. In der Regel werden die Gefährdungen auf Grundlage von Szenarienkatalogen bestimmt [12] und gemäß den Merkmalen Schweregrad, Kontrollierbarkeit und Exposure (Zeitdauer oder Häufigkeit des Auftretens einer zu betrachtenden Situation) bewertet [13]. Für jedes der erkannten gefährlichen Ereignisse wird ein Sicherheitsziel formuliert. Jedem der funktionalen Sicherheitsanforderungen wird eine Sicherheitsintegritätsstufe (ASIL, Automotive Safety Integrity Level) zugeordnet. Das im weiteren Verlauf der Systementwicklung aufgestellte Funktionale Sicherheitskonzept formuliert, welche Funktionen zur Erreichung der Sicherheitsziele des Items erforderlich sind. Für den Fahrcomputer ergeben sich die in Tab. 4 dargestellten funktionalen Sicherheitsanforderungen samt zugehöriger ASIL Einstufungen. Demnach beschreiben die vier funktionalen Sicherheitsanforderungen die Schnittstelle vom Fahrcomputer für die Anwendung einer Assistenzfunktion im Level 2 und Level 3. Hierin fließen gleichzeitig die UCAs aus der STPA fließen, um direkt funktionalen Sicherheitsanforderungen hinreichend zu präzisieren. Damit sind generische funktionale Sicherheitsanforderungen für Fahrzeugcomputer im Umfeld des hochautomatisierten Fahrens definiert und im Sinne eines Safety Element out of Context normkonform in die ISO 262626 eingebunden.

Dieser Beitrag zeigt auf, dass „Top-Down“-Entwurfsansätze von spezifischen Anwendungen (im Fahrzeug) und „Bottom-up“ Lösungen generischer Produkte, bzw. generischer Anwendungen kein Widerspruch in sich darstellen. Die Komponentenhersteller generischer Produkte stellen ein marktgerechtes Produkt mit wohl definierten Annahmen bereit. Diese Annahmen müssen bei der Integration in „überlagerte“ generische Anwendungen und spezifische Systemausprägungen (konkretes Fahrzeug) im Sinne einzuhaltender „sicherheitsbezogener Anwendungsregeln“ nachgewiesen werden. Damit dieser Nachweis gelingt, müssen Anforderungen klar und eindeutig gefasst werden. Hierfür wurde in diesem Beitrag das Beschreibungsmittel der Regelstrukturen, die in übergeordneten methodischen Rahmen von STPA/STAMP eingebettet sind, vorgestellt. Dieser Ansatz ist für die in diesem Beitrag dargestellte generische Strukturierung funktionaler Sicherheitsanforderungen für automatisierte Fahrzeugsysteme des Level 3 erfolgversprechend.