Vernetzte Autos, die von Software angetrieben werden, mögen direkt aus der Science-Fiction stammen, aber sie sind alle bereit, die Art und Weise, wie wir uns Mobilität heute vorstellen, radikal zu verändern. Mit erfahrenen Automobilunternehmen, die aufstrebende Technologien nutzen, ist es nur eine Frage der Zeit, bis fahrerlose Autos zu einem alltäglichen Anblick werden¹. Der Weg in die Zukunft ist jedoch mit Herausforderungen gepflastert, die von der zunehmenden Komplexität der Automobilsoftware und der schrittweisen Entkopplung der Hardware- und Softwarekomponenten bis hin zur Notwendigkeit einer stärkeren Konzentration auf methodisches, sicherheitsbasiertes Design und Produktion reichen, was die sichere Einführung futuristischer Technologien vorantreiben kann. So etabliert und ermöglicht KPIT die sichere Einführung von Software der nächsten Generation, die autonome Fahrzeuge antreibt.

Ebenen des autonomen Fahrens²

Experten haben fünf Stufen definiert³ in der Evolution des autonomen Fahrens, die jeweils beschreiben, inwieweit ein Auto Aufgaben und Verantwortung von seinem Fahrer übernimmt und wie Mensch und Maschine interagieren. Die fünf Ebenen der Fahrzeugautomatisierung umfassen:

• L0: Nur Fahrer: Das System bietet vorübergehende Fahrunterstützung durch Warnungen, Warnungen und Notfall-Sicherheitseingriffe, während der Fahrer engagiert und aufmerksam bleibt
• L1: Fahrerassistenz: System hilft dem Fahrer, übernimmt aber nicht
• L2: Teilautomatisiertes Fahren: Das System kann die Kontrolle übernehmen, aber die Verantwortung für den Fahrzeugbetrieb verbleibt beim Fahrer
• L3: Hochautomatisiertes Fahren: Der Fahrer kann sich in bestimmten Situationen für eine gewisse Zeit vom Fahren lösen
• L4: Vollautomatisches Fahren: Das Fahrzeug kann die meiste Zeit selbst fahren, wobei der Fahrer anderen Tätigkeiten nachgeht, aber bei Bedarf die Kontrolle übernehmen kann
• L5: Vollautomatisierung: Das Fahrzeug übernimmt die volle Kontrolle über die Fahrfunktionen, wobei die Passagiere nur diese sind

Diese Stufen können realisiert werden, sofern bestimmte Voraussetzungen für den Bau solcher zukunftsfähigen Autos erfüllt sind. Die aktuelle Connected-Car-Architektur bringt Basissoftware – AUTOSAR – mit sich, die zwar effizient auf kleinen Mikrocontrollern arbeitet und für zeitkritische, sichere Anwendungen gut geeignet ist, aber den Zweck nicht vollständig erfüllt. Die meisten dieser Merkmale stellen den Komfort über die Sicherheit und verfehlen dadurch ein effektives und methodisches anforderungsbasiertes Design und geeignete Validierungs- und Verifizierungstests. Während für solche Autos eine hohe Rechenleistung erforderlich ist, benötigt die darin enthaltene Softwareinfrastruktur auch etwa 25 GB pro Stunde⁴ und verwendet fast 40 Mikroprozessoren und Dutzende von Sensoren, um Daten zu sammeln.

KPITs Voraussetzungen für den Bau zukunftsfähiger Autos

KPIT sieht eine serviceorientierte Architektur als robuste Grundlage für Connected Cars vor. Ausgestattet mit aufgeteilten ECUs im Safety IO Controller und dem High Performance Controller und einer dedizierten Infrastruktur, um eine hohe Rechenleistung zu ermöglichen, nutzt das Framework von KPIT ein weit verbreitetes POSIX-ähnliches Betriebssystem (z. B. Linux), Adaptive AUTOSAR und einen IO-Controller, der dies ermöglicht bietet Sensor- und Aktuatordienste zusammen mit einem tief eingebetteten Echtzeit-Betriebssystem (z. B. Classic AUTOSAR).

Während der Performance Controller den menschlichen Fahrer unterstützt und sich auf die Nicht-Hochgeschwindigkeitsfunktionen konzentriert, befasst sich der IO-Controller mit Hochgeschwindigkeitsfunktionen, Filterverarbeitung und Berechnung mit starkem Timing. Die Software variiert je nach Einschränkungen der verfügbaren Funktionen und den angeschlossenen Sensoren/Aktoren. Die Vorteile des Performance Controllers – Request IOs/Data on Demand (SOME/IP) – werden Over-The-Air aktualisiert und können neue Funktionen umfassen, Fehler beheben und sich gegenseitig ersetzen (Fail-Operational). Alle genannten Elemente sind unerlässlich, um sowohl die Systemintegrität als auch die Verfügbarkeit für ein umfangreiches Softwaresystem wie das autonome Fahren zu ermöglichen.

Konzepte für Fail-operational Systeme⁵

Eines der Kernprinzipien, das schon früh in der Design- und Entwicklungsreise des vernetzten Autos beim Entwurf der elektronischen Steuerungssysteme für Kraftfahrzeuge zum Einsatz kam, war der ausfallsichere Betrieb. Ausfallsicherheit ist heute nicht mehr ausreichend, Ausfallsicherheit stellt sich als absolutes Minimum heraus.

Abb. 1: Der Übergang von Fail-safe zu Fail-operational umfasst kritische Schritte, die sich auf Fehlererkennung, Redundanz und schrittweisen sicheren Stopp konzentrieren

Der Weg vom ausfallsicheren zum ausfallsicheren Betrieb, wie in Abbildung 1 schematisch dargestellt, umfasst Folgendes:

Funktion Safe State Spans deaktivieren / herabsetzen

• Informieren Sie den Fahrer
• Diagnosefehler melden

Standardansatz in vielen sicherheitsrelevanten Systemen enthalten

• Airbag, ESP, Klimaanlage, Batterieladung
• Fahrerassistenzfunktionen wie Abstandsregeltempomat, Spurhalteassistent

Einige Funktionen wie unten bieten einen eingeschränkten Modus, der manchmal zeitlich begrenzt ist

• Elektronische Servolenkung
• Bremsen

In hochautomatisierten Autos werden solchen sicherheitskritischen Systemen oft dedizierte Systeme zugewiesen, die ihnen helfen, diese Funktionen auszuführen, wenn ein Fehler erkannt wird. Dies sorgt zwar für Redundanz, ermöglicht aber auch den Betrieb des Fahrzeugs, bis es selbst zu einem sicheren Halt verlangsamt wird.

Sicherer Zustand beinhaltet

Fahren Sie weiter, bis der Fahrer in der Schleife ist

• Ca. 7-15s für bedingtes autonomes Fahren
• Mehrere Minuten für hoch- und vollautonomes Fahren

Führen Sie einen autonomen „sicheren Stopp“ durch (Stillstand an einer ungefährlichen Stelle)

• Lenken Sie die Aufmerksamkeit des Fahrers auf die Situation
• Kann je nach Situation mehrere Minuten dauern

KPITs Ansatz zur Ermöglichung von Fail-Operational-Systemen

Abb. 2: Die vier Säulen von Fail-Operational-Systemen

Ein ganzheitliches Modell der Wirkungskette autonomer Autos besteht aus Sensorelementen wie Radar, Kameras und anderen Sensoren, die in die Wahrnehmungsebene eingespeist werden, die Sensoreingaben in eine handhabbare Darstellung der Umgebung um das Fahrzeug kontextualisiert. Die dargestellte Umgebung wird dann in Planungskomponenten verwendet, um eine ausführbare Trajektorie für das Steuermodul zu erzeugen.

Aus sicherheitstechnischer Sicht ist es offensichtlich, dass die einfache Simplex-Implementierung nicht ausreicht, um weder Ausfallsicherheit noch Betriebsfähigkeit zu erreichen, und dass zusätzliche Designelemente eingeführt werden müssen, um Fehler zu erkennen und zu verhindern, dass Ausfälle das System in einen nicht betriebsbereiten Zustand bringen. sicherer Zustand.

Abb.3: Vergleich zwischen zwei Ansätzen bei der Einführung interner Diagnosen in die AD-Fahrzeugarchitektur

Die Idee, eine interne Diagnose in ein System einzuführen, damit das System bei Erkennung eines Fehlers auf sichere Weise ausfallen kann, wurde in Abbildung 3 oben untersucht, obwohl klar ist, dass es mit einer 1oo1D-Architektur nicht möglich ist, einen Ausfall zu erreichen. Sicherheits- und Betriebskriterien für Hochsicherheitssysteme wie autonomes Fahren. Die in der Automobilindustrie immer beliebter werdende Lösung ist jedoch die sogenannte Zwei-von-Zwei-mit-Diagnose-Architektur (2oo2D), bei der zwei 1oo1D-Kanäle parallel arbeiten, um eine maximale Verfügbarkeit zu gewährleisten. Fällt einer der Kanäle aus, steht der Gesunde weiterhin zur Verfügung, um den kontinuierlichen Betrieb zu gewährleisten.

Abb.4: Analyse von Fehlern, die zum Ausfall in einem sicherheitskritischen System führen

Der wichtige Faktor, der beim 2oo2D-Ansatz zu berücksichtigen ist, besteht darin, die Unabhängigkeit der Kanäle sicherzustellen, damit das System vor Ausfällen aufgrund gemeinsamer Ursache geschützt werden kann. Ein Fehler aufgrund gemeinsamer Ursache ist ein Szenario, in dem eine Grundursache eine Diskrepanz in beiden Kanälen verursacht, wodurch beide ausfallen. Einige gängige Praktiken bei der Behandlung dieses Themas sind die Verwendung unterschiedlicher Sensorsätze über verschiedene Kanäle, die Verwendung unterschiedlicher Implementierungen in kritischen Teilen (z. B. mathematische Bibliothek, Fusionsalgorithmen und ähnliche Elemente), die Diversifizierung der Hardwareplattform und andere Kopplungsfaktoren.

Fazit

Vernetzte Autos haben seit den 1980er Jahren in Bezug auf Design, Infrastruktur und Technologien einen langen Weg zurückgelegt. Heute streben diese danach, zukunftsfähig zu sein, aber mit großem Augenmerk auf Sicherheit. Der Denkprozess von KPIT für autonom fahrende Autos beinhaltet die Wiederverwendung verfügbarer Integritätsmechanismen aus ausfallsicheren Systemen als Hauptstütze für den Aufbau ausfallsicherer Systeme. Während Softwaresysteme, die darauf ausgelegt sind, eine hohe diagnostische Abdeckung zu erreichen, heute leicht verfügbar sind, erfordert die Zukunft, dass diese in einem robusten Design untergebracht werden, um die AD-Funktion zu erfüllen. KPIT erkennt auch an, dass etablierte Methoden zur Verfolgung von Softwarequalität und -sicherheit der Schlüssel zur Entwicklung einer optimal sicheren Lösung sind, und arbeitet an der Herausforderung, alle Fälle für komplexe Softwarelösungen durch erstklassige Verifizierungs- und Validierungsmethoden sowohl im virtuellen Bereich abzudecken und Feldumgebungen.

Verweise

1. https://www.brookings.edu/research/securing-the-future-of-driverless-cars/

2. https://www.nhtsa.gov/technology-innovation/automated-vehicles-safety

3. Die Stufen 0 bis 5 werden entsprechend ihrem relativen Automatisierungsgrad definiert. Die Level 3-5 befinden sich noch in der Testphase.

4. https://qz.com/344466/connected-cars-will-send-25-gigabytes-of-data-to-the-cloud-every-hour/

5. https://www.forbes.com/sites/samabuelsamid/2022/02/08/automated-driving-must-be-fail-operational/?sh=24ef7b2a527f