Autonome Systeme - aber sicher

Details

Montag, 18. Mai 2020

Autonome Systeme sind eine große Herausforderung für die Automobilindustrie. Neben den benötigten Funktionen (die großenteils bereits implementiert sind), gilt es, die Sicherheit der Systeme unter allen (un-)denkbaren Umständen zu gewährleisten, damit durch verringerte Unfallzahlen die Systeme breite gesellschaftliche Akzeptanz bekommen.

In der recht neuen Norm SOTIF wurden für Level 1 und 2 der 6 Automatisierungsstufen bereits weitreichende Regeln definiert. Aber für Level 3 und 4 werden weitere benötigt. Unter Federführung von Daimler haben Fahrzeughersteller und Zulieferer eine Studie durchgeführt und deren Ergebnisse in dem Whitepaper Safety First for Automated Driving (SaFAD) veröffentlicht.

Welche zusätzlichen Anforderungen für die Systementwicklung definiert wurden, weiß Dipl.-Inform. Marc Ruppert. Er arbeitet als Berater bei der F+S Fleckner und Simon Informationstechnik GmbH.

Herr Ruppert, wenn die funktionalen Probleme gelöst sind, wieso sind dann die Systeme nicht sicher?

Dipl.-Inform. Marc Ruppert: Funktional heißt, dass das System einen Algorithmus hat, der funktioniert. Nehmen Sie die Schildererkennung: Wir haben Algorithmen, die ein Schild erkennen und seine Bedeutung verstehen. Funktionale Herausforderungen sind nun, alle Schilder auf der Welt zu kennen, auch alte, ehemals gültige, auch die Warnung vor Kängurus in Australien oder vor Elchen in Schweden. Inklusive der Bedeutung, also welche Gefahr droht und wie man (bzw. das Fahrzeug) sich verhalten soll.

Sicher heißt aber, dass jedes Schild jederzeit erkannt wird, zumindest mit der Qualität eines menschlichen Fahrers. Auch wenn es teilweise von Sträuchern verdeckt wird, ausgebleicht oder verwittert ist, selbst ein von Schnee bedecktes Stoppschild.

Aber ist die Erkennung eines verwitterten Schildes nicht auch eine funktionale Herausforderung?

Ruppert: Teilweise schon. Wenn ich die Anforderungen kenne, kann ich den Algorithmus darauf erweitern. Aber abhängig vom Wetter, den Sicht- und Straßenverhältnissen, von anderen Verkehrsteilnehmern und aufgrund von Streuungen im Fertigungsprozess kommt das System irgendwann an seine Grenzen und erkennt ein Schild gar nicht mehr als solches oder interpretiert es falsch. Und das kann dann zu gefährlichen Situationen führen. Die Optimierung der Funktionalität ist nur eine Möglichkeit für fehlerfreies Verhalten. Sie wird immer an ihre Grenzen kommen, und dann müssen andere Lösungen sicherstellen, dass es zu keinem Unfall kommt.

Und welche Lösungen hat die Studie entwickelt?

Ruppert: Zuerst hat man definiert, was überhaupt abzusichern ist. Hierfür hat man "Twelve Principles" (12 allgemeine Prinzipien) definiert, die ein autonomes System erfüllen muss. Man kann diese 12 Prinzipien quasi als 12 „Safety Goals“ ansehen, die jedes autonome System gewährleisten muss.

Aus diesen Prinzipien leitet SaFAD ab, welche zusätzlichen Entwicklungsschritte wie durchzuführen sind, Stichwort „Safety by Design“.

Ein dritter Schwerpunkt ist die ausführliche Verifikation und Validierung der Systeme zum Nachweis der Sicherheit und, insbesondere in der Anfangszeit der Entwicklung, zur Ermittlung weiterer konkreter Anforderungen. Eine Kombination aus Simulation, Testfahrten auf dem Prüfgelände und in der realen Welt wird gefordert. Die Verifikation weist nach, dass alle 12 Prinzipien erfüllt sind.

Herr Ruppert, können Sie die 12 Prinzipien näher erläutern?

Ruppert: Ja, gerne. Zur besseren Übersicht ordne ich die Prinzipien in drei Bereiche:

Der erste Bereich ist verantwortlich dafür, dass das System seine Aufgabe immer sicher ausführt. Hierzu gehört die klare Definition des Einsatzbereiches (fahrerische Aufgabe, Strecke, Wetter, ...), das immer für andere Verkehrsteilnehmer nachvollziehbare Verhalten und Rückfallebenen für problematische Situationen und Fehlerfälle. Das ist in den folgenden vier Prinzipien beschrieben:

• Operational Design Domain (ODD)
• Behaviour in Traffic
• Safe Operation
• Safe Layer

Der zweite Bereich sichert die Verantwortung zwischen Fahrer und Fahrzeug, also die Übergabe der Verantwortung vom Fahrer an das autonome System oder umgekehrt, aber auch die Überwachung der Fahrtüchtigkeit des Fahrers und seiner möglichen Fehlreaktionen nach Übernahme der Verantwortung. Das erfordert die Einhaltung folgender vier Prinzipien:

• Vehicle Operator-initiated Handover
• User Responsibility
• Vehicle initiated Handover
• Interdependency

Den dritten Bereich bilden einzelne Prinzipien, die als Unterstützung notwendig sind. Diese sind:

• Security
• Passive Safety
• Data Recording
• Safety Assessment

Klingt sehr sinnvoll. Aber, was kann ich mir unter „Safety by Design“ vorstellen?

Ruppert: So wie man Qualität nicht durch Testen in ein System hinein bekommt, so ist es auch notwendig, die Sicherheit von Anfang an zu betrachten und in die Architektur einzuarbeiten. Wie dieses geschehen kann, wird in der Studie erarbeitet.

Dafür leitet SaFAD aus den 12 Prinzipien 13 "Capabilities" (Fähigkeiten) ab, die ein autonomes System beherrschen muss, um die Prinzipien zu erfüllen. 7 Fähigkeiten bilden die eigentliche Regelung für das autonome Fahren und eine erste Überwachungsebene. Sie sind "fail-safe“, also ausfallsicher. Die anderen 6 Fähigkeiten erkennen Probleme wie kritische Wetterbedingungen oder Systemfehler. Sie bilden eine Rückfallebene, sie sind „fail-degraded“, eine Fehler vermindernde Fähigkeit. D.h. im Problemfall verhindern sie ein Versagen des Systems und damit einen drohenden Unfall. Sie bringen das Fahrzeug immer in den Zustand des kleinsten Risikos (Minimal Risk Condition (MRC).

Und was hat das mit Design zu tun?

Ruppert: Die fail-safe Fähigkeiten werden nach dem "Sense – Plan – Act („wahrnehmen – planen – agieren) Design Paradigma“, bekannt aus der Robotik und Automatisierungsliteratur, angeordnet. Das heißt, die ersten drei Fähigkeiten nehmen die notwendigen Informationen einer Situation wahr, z. B. Objekte und ihre Bewegung. Die nächste Fähigkeit erstellt einen Plan über das eigene dynamische Verhalten, wie und wo soll sich das Fahrzeug hinbewegen. Zwei weitere agieren, setzen also den Plan um und informieren andere Teilnehmer über den Plan. Die letzte, die überwachende fail-safe und die 6 fail-degraded Fähigkeiten sind parallel immer aktiv, um Probleme zu erkennen und als Rückfallebene zu agieren.

Und das ergibt dann das Design?

Ruppert: Das ist der erste Schritt. Den 12 Fähigkeiten werden in einem zweiten Schritt auf einer funktionalen Ebene “elements“ (Elemente) wie Sensoren, Algorithmen und Aktuatoren zugeordnet, die diese implementieren. Diese Elemente werden dann in einer generischen Architektur angeordnet und Schnittstellen zwischen ihnen definiert. Diese Architektur folgt auch dem Sense – Plan – Act Design Paradigma“.

Das Ergebnis ist also eine funktionale generische Architektur, die ich für alle autonomen Systeme implementieren kann. Mit Hilfe der beschriebenen einzelnen Schritte kann ich meine konkreten Anforderungen auf die Architektur übertragen und erhalte, wenn ich sie richtig implementiere, ein sicheres System.

„Wenn ich es richtig implementiere“ klingt aber nicht sehr vertrauenerweckend!

Ruppert: Natürlich können immer und überall Fehler passieren. Um diese zu erkennen und zu beheben gibt es den dritten Teil: Verifikation und Validierung.

Ähnlich wie beim Design werden hier zuerst einmal fünf Testherausforderungen der autonomen Systeme identifiziert, die es bisher nicht oder nur eingeschränkt gab.

Zur Herleitung einer Teststrategie orientierte sich das Team dann an den 5W2H Fragen (who, what, where, when, why, how, how well). Diese Fragen werden für jede Herausforderung beantwortet, so dass eine Teststrategie entsteht, die man „nur noch“ umsetzen muss.

Wohlgemerkt, die etablierten Testmethoden gelten auch weiterhin, bisherige Tests auf allen Ebenen müssen zusätzlich durchgeführt werden.

Herr Ruppert, das klingt alles sehr theoretisch.

Ruppert: Ja und nein. Im SaFAD Whitepaper wird es natürlich deutlich ausführlicher erläutert, als ich es hier machen kann. Zudem sind zur besseren Veranschaulichung vier Entwicklungsbeispiele enthalten, an denen man sich orientieren kann (Staupilot und Autobahnpilot als Level 3, Stadtpilot und Parkpilot als Level 4 Beispiele).

Ähnlich wie das vom VDA entwickelte E-Gas Überwachungskonzept, das sich zum Quasi-Standard für die Entwicklung sicherheitsrelevanter E/E-Systeme im Fahrzeug entwickelte, bis es von der ISO 26262 abgelöst wurde, hat man hier eine Vorlage, an der man sich orientieren kann. Viele Details, die man übersehen oder Fallen, in die man stolpern könnte, sind benannt und Lösungsvorschläge erstellt. Mit diesem Whitepaper als Grundlage kann man die Entwicklung und Absicherung autonomer Systeme viel genauer abschätzen und planen.

Herr Ruppert, könnten Sie das mal anhand des Beispiels Verkehrsschild ausführen?

Ruppert: Gerne. Wie gesagt, können die Schilder z.B. abhängig vom Wetter nicht erkannt werden. Indem man die Funktionalität erweitert, kann man z.B. ein Stoppschild auch unter Schnee erkennen. Aber bei schwierigen Sichtverhältnissen wie Nebel oder Schneetreiben ist man außerhalb der Operational Design Domain (ODD), sprich ab einer definierten Einschränkung der Sensoren muss das System den Fahrer zur Übernahme des Fahrzeugs auffordern, bevor Schilder übersehen oder falsch interpretiert werden.

Die Grenzen hierzu kann man zuerst mit Simulationen am Rechner, dann z.B. in Klimakammern ausloten. Auf dem Testgelände kann man entsprechende (schlechte) Schilder aufstellen und die Wetterbedingungen simulieren, wenn möglich die Testfahrten auch nach Wetter planen. Fahrten in der realen Umgebung, insbesondere bei den kritischen Wetterbedingungen dort, wo Schilder schon mal falsch erkannt wurden, runden die Erfahrungen ab.

Man braucht also das Whitepaper nur wie ein Kochbuch Schritt für Schritt umzusetzen?

Ruppert: Ganz so einfach ist es auch nicht. Die Vorgaben sind schon noch recht abstrakt. Ähnlich wie bei der Anwendung einer Norm wie Automotive SPICE oder der ISO 26262 muss man aus dem Whitepaper konkrete Arbeitsschritte für das eigene System und Umfeld ableiten, ggf. die eigenen Prozesse anpassen und ergänzen. Auch hier lauern wieder Fallen, die viel Lehrgeld kosten können. Von unserer Erfahrung im Umgang mit solchen Anforderungen und deren Transfer in pragmatische, konkrete Prozessschritte in einem echten technischen Umfeld, profitieren unsere Kunden.

Dann hoffe ich, dass viele Kunden Ihre Dienste nutzen und mit Ihrer Hilfe wirklich sichere autonome Systeme entwickeln, vor denen niemand Angst zu haben braucht.