TEST + TOOLS

Elektronik Safety + Security 2018 35elektronik.de

Autonomes Fahren benötigt zukunftssichere AUTOSAR-Basis-Software:

Sichere Software für das Auto von Morgen

Mit einem immer höher werdenden Grad an Automatisierung von Fahrfunktionen steigen auch die Anforderungen an die Zuverlässigkeit der Systeme und deren Hard- und Software. Insbesondere die Software lässt sich nur schwer mit den aktuell im Automobilbereich etablierten Methoden beherrschen. Welche Argumentationen, Methoden und Belege werden in Zukunft gebraucht, um einen Sicherheitsnachweis zu führen? Und welche Auswirkungen hat das auf die AUTOSAR-Basis-Software?

Von Jonas Wolf

Ein Wohnmobil fährt mit 100 km/h auf der Autobahn. Der Fahrer sitzt nicht hinter dem Steuer, sondern

kocht sich im hinteren Teil des Fahr-zeugs einen Kaffee. Das Fahrzeug steu-ert sich selbst. Dieses Szenario erinnert sehr an Fiktion, doch es soll irgendwann Wirklichkeit werden. Daher wird sich einiges für die Systeme im Fahrzeug ändern müssen: Es werden mehr Sen-soren benötigt, um die Umwelt genau zu erfassen. Außerdem müssen die Steuergeräte im Fahrzeug breitbandig miteinander vernetzt werden, um der neuen Informationsflut Herr zu werden. Aber ist das alles? Welche Konsequen-zen gibt es zum Beispiel für die Soft-ware-Entwicklung? Kann so weiterge-macht werden wie bisher?

Heute sind nahezu alle Systeme im Fahrzeug einkanalig ausgelegt. Einka-nalig bedeutet, dass, wenn ein Element in der Kette von Sensor über Logik zu Aktor ausfällt, auch das Gesamtsystem ausfällt. Redundanzen, also beispiels-weise ein zweiter Sensor oder ein zwei-

ter Mikrokontroller, dienen ausschließ-lich dazu, einen Fehler in der Kette hinreichend sicher erkennen zu können. Die übliche Reaktion im Fehlerfall ist, das Steuergerät neu zu starten oder das Gesamtsystem abzuschalten und den Fahrer zu informieren. Dieser kann sich dann auf die neue Situation einstellen und das Fahrzeug zur Not stoppen. Das Neustarten oder aber das vollständige Abschalten eines Systems gelten dabei

als sichere Zustände. Das zugehörige System wird als fail-safe bezeichnet.

Die Software für Fail-Safe-Systeme muss Fehler in der Hardware und Soft-ware innerhalb einer Toleranzzeit er-kennen. Das erfolgt oft durch eine Überwachung von Deadlines für die Ausführung von bestimmten Soft-warefunktionen oder durch zusätzliche Prüfungen der Korrektheit und Aktua-lität von empfangenen Daten wie auch

(Bild: Vector Informatik)

TEST + TOOLS

36 Elektronik Safety + Security 2018 elektronik.de

dieser Bauart wird als Fail-Operational bezeichnet.

In der System- und Hardware-Tech-nik wird davon ausgegangen, dass jeder Teil eines Systems zu jedem Zeitpunkt mit einer gewissen Wahrscheinlichkeit ausfällt. Für die Berechnung dieser Wahrscheinlichkeit gibt es unterschied-liche Modelle, mit denen sich untersu-chen und begründen lässt, warum ein System als sicher angenommen wird. Die Modelle haben eine gewisse Unsi-cherheit. Der entscheidende Punkt dabei ist aber, dass es Modelle gibt. Denn im Folgenden werden zwei Fehlerfälle betrachtet, die an die Grenzen dessen führen, was über Wahrscheinlichkeiten berechenbar ist.

Aus Gründen des Kosten-drucks und der Komplexität werden Teile der Software in beiden Kanälen zukünftiger Systeme sehr wahrscheinlich identisch sein. Dadurch stellt sich natürlich sofort das Pro-blem der abhängigen Fehler, insbesondere der Fehler ge-meinsamer Ursache – auch Common Cause Faults ge-nannt. Wenn ein solcher Fehler im System vorhanden ist, dann führt dessen Eintritt dazu, dass beide, eigentlich unabhängigen Kanäle zum selben Zeitpunkt ausfallen (Bild 2b) und damit das Gesamtsystem seiner Aufga-be nicht mehr nachkommen kann. Eine Diversifizierung, zum Beispiel durch Nutzung von Software unterschied-licher Hersteller, kann eine Lösung hierfür sein. Die tatsächliche Unter-schiedlichkeit muss jedoch sorgfältig überprüft werden. Oft ist eine Diversi-fizierung aus technischen oder kom-merziellen Gründen nicht möglich oder weil es einfach keine zweite Implemen-tierung gibt. Eine andere Möglichkeit wäre, zu argumentieren, dass ein Fehler gemeinsamer Ursache hinreichend unwahrscheinlich ist. Doch gibt es dazu ein Wahrscheinlichkeitsmodell?

Die gleiche Frage stellt sich bei ei-nem weiteren möglichen Fehlerfall: Das Steuerungssystem des Wohnmobils funktioniert einwandfrei. Plötzlich wird ein zufälliger Hardware-Fehler im akti-ven Kanal entdeckt. Das System reagiert richtig und deaktiviert den aktiven Kanal. Im selben Moment will der bis dahin im Hot-Standby laufende andere Kanal die Steuerung übernehmen.

Durch die sich plötzlich ändernde Last-situation auf dessen Controller, braucht zum Beispiel der Kommunikationsteil der Software unvorhergesehen lange. Es kann keine weitere Kommunikation mehr stattfinden. Dieser Folgefehler wird zwar direkt erkannt, eine vernünf-tige Fehlerbehandlung gibt es im All-gemeinen jedoch nicht. Ein Neustart führt zum Verlust aller Zustandsinfor-mationen der Steuerungsapplikation. Bis die Informationen alle wieder vor-liegen, ist es unter Umständen schon zu spät für den kaffeekochenden Fahrer.

Ein Argumentationsversuch könnte sein, dass es sich hierbei um eine sehr spezielle Art des Doppelfehlers handelt, der nicht weiter betrachtet werden muss. Allerdings ist es auch nachvoll-ziehbar, einen solchen Folgefehler als latenten Fehler (Bild 2c) zu betrachten. Für den Automotive Safety Integrity Level (ASIL) D müssen 90 Prozent aller latenten Fehler erkannt werden. Doch gibt es eine quantitative Aussage zu Fehlern in Software?

Fehlervermeidung für die Software

Alle Fehler in Software sind systema-tische Fehler. Das Erstellen eines allge-mein anerkannten Wahrscheinlichkeits-modells für systematische Fehler ist bisher nicht gelungen. Daher muss Fehlervermeidung als Maßnahme ge-troffen werden, um die auf Wahrschein-lichkeiten basierenden Argumente einer Analyse auf Systemebene nicht wir-kungslos zu machen. Eine Fehlererken-nung ist nicht mehr ausreichend, weil es dem Wohnmobilfahrer wenig hilft, wenn das System erkennt, dass es keine Steuerkommandos mehr erzeugt. Der

SafeE2ESWC SWC

ASIL QM

SWC SWC

SafeRTE

SafeBSW

MCAL

Hardware

Microsar SafeQM-Software vom Tier1 oder OEMASIL-Software vom Tier1 oder OEMASIL-Soft- und Hardware vom Drittlieferanten

SafeWDGSafeOS

Bild 3. Microsar Safe – AUTOSAR-Basis-Software zum Er-stellen von sicherheitsrelevanten Steuergeräten (Bild: Vector Informatik)

bei der Ende-zu-Ende-Absicherung (E2E) für die Kommunikation.

Weiterfahren trotz Fehler

Damit der Fahrer nun in aller Ruhe seine Kaffee kochen und genießen kann, darf er nicht mehr die Rückfallebene im Sicherheitskonzept des Systems sein. Es muss also ein elektronisches Rückfall-system geben (Bild 1). Eine Vorausset-zung für ein derartiges System ist, dass jeder Kanal alle seine Fehler selbst erkennt. Im Fehlerfall des aktiven Kanals wird dieser abgeschaltet und der ande-re Kanal übernimmt die Steuerung des Fahrzeugs (Bild 2a). Ein System

1. SBC/Watchdog

2. SBC/Watchdog

Datenaustausch

1. Mikrocontroller

Steuergerät1. Spannungs-

versorgung1. Kommuni-kationskanal

2. Kommuni-kationskanal 2. Spannungs-

versorgung

2. Mikrocontroller

1. Aktor1. Sensor

2. Aktor2. Sensor

Bild 1. Potenzielle Architektur für ein Fail-Operational-Sys-tem. Durch Redundanz wird im Fehlerfall auf den anderen Kanal umgeschaltet. (Bild: Vector Informatik)

Kana

l 1

a) Zufälliger Hardware-Fehler

ActiveFault DetectedPassive

Kana

l 2

ActiveFault DetectedPassiveHot Standby

Kana

l 1

b) Fehler gemeinsamer Ursache

ActiveFault DetectedPassive

Kana

l 2

ActiveFault DetectedPassiveHot Standby

Kana

l 1

c) Latenter Fehler

ActiveFault DetectedPassive

Kana

l 2

ActiveFault DetectedPassiveHot Standby

Take Over

Take Over

Bild 2. Verschiedene Fehlerarten und deren Auswirkung (Bild: Vector Informatik)

Elektronik Safety + Security 2018 37elektronik.de

TEST + TOOLS/BUSINESS PORTRAITS

Fahrer verlässt sich darauf, dass das System auch im Fehlerfall sein Wohnmobil noch unter Kontrolle hat.

Wie kann nun Fehlervermeidung für eine komplexe Software gezeigt werden? Systematische Fehler können nur durch einen geeigneten Entwicklungsprozess vermieden werden. Die ISO 26262 legt für die notwendigen Aktivitäten und Methoden eine untere Schranke fest. Im Gegensatz zu Fail-Safe-Systemen sind bei Fail-Operational-Systemen wesentlich mehr Funktionen einer Software sicherheitsrelevant und nicht nur die Funktionen zur Fehlererkennung und -behandlung. In einer AUTOSAR-Basis-Software gibt es daher auch Sicherheitsanforderungen an die Kommunikation und weitere Basisfunktionen.

Üblicherweise resultiert mehr als die Hälfte der Aufwände für eine sicherheitsgerichtete Software-Entwicklung aus dem Test. Daher ist zu erwarten, dass der Aufwand für das Entwickeln eines Fail-Operational-Systems enorm steigt. Zudem lassen sich einige Software-Eigenschaften nur schwer testen. Wie bereits erwähnt, ist die maximale Ausführungszeit eine solche Eigen-schaft. Aber auch das Verhalten bei Nebenläufigkeit erfordert intensive Analysen, um kritische Wettläufe (Race Conditions) zu verhindern. Beide Formen der Analyse sind nur mit modernen Werkzeugen überhaupt möglich. Zusätzlich unterstützen die in der ISO 26262 geforderten Sicherheits-, Daten- und Kontroll-flussanalysen die Argumentation, dass hinreichend viel dafür getan wurde, das ursprüngliche Risiko auf ein akzeptables Maß zu reduzieren.

Sichere Software für die Zukunft

AUTOSAR-Basis-Software zum Erstellen von Fail-Safe-Systemen gibt es bereits seit einigen Jahren, wie die vollständig bis ASI D zertifizierte AUTOSAR-Basis-Software Microsar von Vector (Bild 3). Durch eine intensive Daten- und Kontrollflussanalyse und einen ISO-26262-konformen Test ist die Rückwirkungsfrei-heit im Speicher nachgewiesen. Eine E2E-Absicherung erkennt eine fehlerhafte Kommunikation in Fail-Safe-Systemen. Ein solches System ist, verglichen mit einem rein auf Partitionierung basierten System, bereits gut auf Fail-Operational-Anforderun-gen vorbereitet.

Zur weiteren Vermeidung von systematischen Fehlern müs-sen jedoch zusätzliche Analysen durchgeführt werden. Im Be-triebssystem Microsar OS wurde beispielsweise bereits großer Wert darauf gelegt, die maximalen Laufzeiten bestimmbar zu machen und ein möglichst deterministisches Verhalten bereit-zustellen. Doch auch hier zeigen erste Analysen, dass es einigen Aufwand braucht, realistische Obergrenzen mit Werkzeug-unterstützung zu ermitteln. Gleiches gilt für die Nebenläufig-keitsanalyse zur Vermeidung von Race Conditions.

Mit aktueller Software und Technologie können heute schon Systeme gebaut werden, die in Zukunft autonom auf der Straße agieren können. Der Weg dorthin wird allerdings noch einiges an Mühen kosten, sowohl bei Software-Lieferanten als auch bei Fahrzeugherstellern und deren Zulieferern. Der Wohnmobilfahrer

wird sich also noch ein paar Jahre selbst hinter das Lenkrad setzen müssen, bis er sich in einem auto-nom fahrenden Fahr-zeug Kaffee kochen kann. eck

Dipl.-Ing. Jonas Wolf studierte Luft- und Raumfahrt-technik an der Universität Stuttgart. Er ist seit 2012 bei Vector und jetzt als Principal Product Management Engineer für Funktionale Sicherheit tätig.