Warum ist XiL so wichtig? Heftiges Schneetreiben. Im Nu haftet Schnee an der Kleidung von Passanten und Radfahrern; im Nu bedeckt er Straßenschilder und Fahrbahnmarkierungen. Kommen sensorgestützte, hoch automatisierte Fahrzeuge mit dieser Situation zurecht? Werden sie richtig reagieren, wenn ein Kind sich plötzlich von der Hand der Eltern losreißt und auf die Straße rennt, wenn Rehe oder Wildschweine plötzlich aus dem Dunkeln auftauchen oder wenn Ampeln ausfallen und Polizisten den Verkehr per Handzeichen regeln?

Nur mit Simulation (XiL) und Virtualisierung finden Entwickler noch den Weg durch all die Problemstellungen des automatisierten Fahrens.

Nur mit Simulation und Virtualisierung finden Entwickler noch den Weg durch all die Problemstellungen des automatisierten Fahrens. ETAS

Gerade mit Blick auf das automatisierte Fahren werden diese Fragen zu beantworten sein – und theoretisch unendlich viele weitere Fragen zu allen erdenklichen Verkehrs-, Wetter- und Umweltsituationen. Vor dem Hintergrund, dass drei bis vier Dutzend Sensoren pro Fahrzeug zusammenwirken, deren Daten permanent unter Echtzeitbedingungen von Steuergeräten (ECUs), Mikroprozessoren (µPs) und Grafikprozessoren (GPUs) ausgewertet und in Fahrbefehle für die Fahrzeug-Aktorik übersetzt werden müssen, wird die enorme Komplexität dieser Aufgabe klar. Hinzu kommt, dass all dies, je nach Hersteller, in komplett unterschiedlichen, häufig aktualisierten Hard- und Softwarearchitekturen geschieht. Doch damit nicht genug. Durch Updates over-the-air (OTA) ändert sich die Software während der Lebensdauer laufend. Spätestens jetzt wird klar, dass neue, konsequente Ansätze in der Entwicklung gefragt sind.

Virtualisierung macht Komplexität beherrschbar

Die Absicherung von hoch automatisierten Fahrzeugen sprengt alle bisherigen Dimensionen. Um sie dennoch unter Berücksichtigung des Zeit- und Kostenrahmens bewältigen zu können, sind intelligente Ansätze gefragt: Es gilt, über den gesamten Entwicklungszyklus der eingesetzten Soft- und Hardwaresysteme hinweg effiziente, weitestgehend virtualisierte Methoden zu etablieren. Im Idealfall gewährleisten dies durchgängige Daten- und Workflows entlang des Entwicklungszyklus (Bild 1). Hohe Datendurchlässigkeit ist hierbei zentral: Einerseits, um verschiedene Datenformate der eingesetzten Video-, Radar-, Lidar- und Ultraschallsensoren in die virtualisierten Tests einspielen zu können, andererseits, damit bereits erfolgte Verifizierungen und Validierungen im Entwicklungsablauf von Stufe zu Stufe weiterverwendet werden können, um verlässlich darauf aufzubauen. Das kann nur gelingen, wo zum einen Schnittstellen standardisiert sind und zum anderen eine offene Systemarchitektur der Absicherungskette den Einsatz von Entwicklungswerkzeugen verschiedener Anbieter ermöglicht.

Durchgängige Tests sind ein wichtiger Schlüssel zum Erfolg von XiL.

Bild 1: Durchgängige Tests sind ein wichtiger Schlüssel zum Erfolg. ETAS

ETAS verfolgt beide Ansätze seit vielen Jahren konsequent und hat dabei ein breites Portfolio an X-in-the-Loop-Lösungen (XiL) aufgebaut. Sie reichen vom Model-in-the-Loop-Ansatz (MiL) für die grundlegende Auslegung der Systemfunktionen und -architektur in der Frühphase, über Software-in-the-Loop-Verfahren (SiL) zur Absicherung von Softwarefunktionen, die schon sehr früh zum Einsatz kommen, lange bevor ECUs, µPs, GPUs und andere Fahrzeuginfrastruktur als Hardware bereitstehen. Dabei erlaubt der Einsatz virtueller Steuergeräte bereits umfassende Tests bis hin zur Simulation künftiger Car-to-x-Kommunikation mit nahezu beliebig vielen virtuellen ECUs. Diese haben auch den Vorteil, dass sich Tests zeitsparend parallelisieren lassen, dabei schneller als in Echtzeit durchgespielt werden können und Situationen so oft reproduzierbar sind, bis die Entwickler eine sichere und verlässliche Systemantwort erhalten. Später ist es in Hardware-in-the-Loop- (HiL) sowie Vehicle-in-the-Loop-Settings (HiL) möglich, diese in SiL-Tests verifizierten und validierten Funktionen auch mit der Serienhardware zu testen und zu validieren. Die Simulationen parallelisieren nicht nur den Entwicklungsprozess: Im ADAS-Umfeld ermöglichen sie es auch, die Interaktion der Fahrzeugsysteme mit variablen Umweltbedingungen zu erproben – und dabei auch sicherheitskritische Tests beliebig oft zu wiederholen.

Vorhandene Werkzeugkette intelligent einsetzen

Für erfolgreiche ADAS-Tests muss auch die Verkehrssituation am HiL bzw. XiL simuliert werden.

Bild 2: Für erfolgreiche ADAS-Tests muss auch die Verkehrssituation am HiL simuliert werden. ETAS

Mit Blick auf ADAS und das hoch automatisierte Fahren kommt es nun darauf an, diese XiL-Werkzeugkette effizient zu nutzen, sie für neue Datenformate und Simulationsaufgaben zu öffnen und sie hierbei zugleich auf die rasant zunehmenden Datenvolumina vorzubereiten. Wo bisher vor allem fahrzeuginterne Systeme wie Motorsteuerungen im Fokus standen, gilt es nun zusätzlich, die dreidimensionalen Daten der Umfelderkennung, Verkehrssimulationen oder das Fahrerverhalten und die Aufgaben der autonomen Fahrzeugführung in die Tests einzubeziehen (Bild 2). Je nach Architektur gilt es dafür, verschiedene ECUs und Prozessoren mit den heute üblichen Automotive-Datenbussen und künftigen Gigabyte-Ethernetleitungen zu verbinden. Das ist allerdings nur die Basis: Die schwierigere Aufgabe besteht darin, jeweils geeignete Stimuli für die in die Simulationen eingebundenen Sensoren und Steuergeräte zu injizieren. Diese sind für Stereo-Videokameras andere als für Radar- oder Lidar-Sensoren.

Die Herausforderung beginnt mit der grundlegenden Frage, wie entsprechende Datenfiles für die Fülle an Testfällen generiert – und wie sie abgelegt werden, damit Entwickler bei Bedarf schnell gezielt darauf zugreifen können. Dieser erste Schritt erweist sich in gegenwärtigen Entwicklungsprojekten als hohe Hürde. Denn es fehlt an leistungsfähigen Tools für die notwendige Datenerfassung in Versuchsfahrzeugen. Datenraten von 500 MByte/s am Steuergerät sind gefragt, schon bald werden es 1,5 bis 3 Gigabyte/s sein. ETAS hat für die hoch performante Datenerfassung in Steuergeräten mit der neuen Schnittstellenbaureihe GETK-Px jüngst eine Lösung vorgestellt. Daneben stehen leistungsfähige Datenlogger bereit, die per 10-GByte/s-Ethernet-Switch an die Schnittstellen angebunden werden. Wechselspeicher mit Terrabyte-Volumen erleichtern die Workflows. Datenraten beim Speichern werden schon in naher Zukunft in den Bereich von 4 Gigabyte/s vorstoßen.

 

Lesen Sie auf der nächsten Seite, warum Standardisierung ein Muss ist und das Feld für Künstliche Intelligenz bereitet.

Seite 1 von 3123