Sicherer autonom mit ISO 26262 und simulationsbasiertem Testen

19. September 2018: Einer der wichtigsten Schritte auf dem Weg zur vollständigen Autonomie ist die Gewährleistung der funktionalen Sicherheit der Fahrzeugsysteme für das automatisierte Fahren. Denn in einem „Augen zu, Hände weg“-Szenario gibt es keinen Spielraum für Fehler. Beim autonomen Betrieb stellt sich daher die Frage, auf welche Weise die Sicherheitsanforderungen abgesichert werden.

Das Testen auf Fahrzeugebene reicht nicht aus, um die Sicherheit zu gewährleisten, jedoch könnte der Software-Sicherheitsstandard ISO 26262 eine praktikable Option sein.

Durch die Einhaltung des ISO-26262-V-Zyklus-Entwicklungsprozesses sind Automobilhersteller und -zulieferer in der Lage, die Grundlagen für die Entwicklung von Sicherheitssystemen für autonome Funktionen zu legen. Um die vollständige Übereinstimmung mit der ISO 26262 zu erreichen, müssen Software und Hardware systematisch getestet und abgesichert werden, einschließlich der Planung, Spezifikation, Ausführung, Auswertung und Dokumentation von Anforderungstests.

Simulation ist entscheidend

Die eingebettete Software ist für ein autonomes Fahrzeug von größter Bedeutung, da sie steuert, wie das Fahrzeug die Umgebung wahrnimmt. Die Bordcomputer sammeln Echtzeitdaten, auf deren Basis das autonome Fahrzeug intelligente Entscheidungen trifft, den Fahrzeuginsassen sofortige Rückmeldung gibt und Risiken minimiert.

Die ISO 26262 legt fest, dass die Simulation für die Validierung des Systemverhaltens entscheidend ist und empfiehlt die Simulation auf allen Ebenen. Der Vorteil der Simulation besteht darin, dass die Tests reproduzierbar sind, und dass sich zudem auch die Möglichkeit bietet, über Leistungs- und Belastbarkeitsgrenzen und Gefahrensituationen hinaus zu testen.

Die ISO 26262 schlägt Model-in-the-Loop (MIL)-, Software-in-the-Loop (SIL)- und Hardware-in-the-Loop (HIL)-Simulation zur Absicherung von Software-Sicherheitsanforderungen vor. Alle diese Simulationsverfahren (MIL, SIL, HIL) lassen sich verwenden, um das gemeinsame Ziel der Generierung von Anforderungen an autonome Fahrzeuge zu erreichen (Abbildung 2).

Um die Sicherheitsanforderungen an die Software zu erfüllen, empfiehlt die ISO 26262:

Software Unit (Component) Testing (6-9): Für das Testen einzelner Software-Komponenten empfiehlt die Norm dringend folgende Testmethoden: Anforderungsbasierte Tests, Schnittstellentests, Fehlereinspeisetests und Leistungstests.

Software Integration & Testing (6-10): Für Anwendungssoftware und in Subsysteme integrierte Basissoftware sowie die Integration von Anwendungssoftware für verteilte Funktionen werden die gleichen Testmethoden (anforderungsbasiertes Testen, Schnittstellentests, Fehlereinspeisetests und Leistungstests) empfohlen.

Verification of Software Safety Requirements (6-11): Diese Tests, die den letzten Meilenstein in der Software-Entwicklung darstellen, müssen auf der Zielhardware durchgeführt werden, um ein ordnungsgemäßes Funktionieren der Software sicherzustellen. Dafür ist ein HIL-Simulator unabdingbar. Der Einsatz der HIL-Simulation wird mit der zweiten Version der ISO 26262 noch wichtiger werden, denn diese empfiehlt die HIL-Simulation auch für die höchsten ASIL-Klassifikationen (Automotive Safety Integrity Level).

Item and Integration Testing (4-8): Die ISO 26262 bietet keine klare Definition des Systemkonzepts, dafür aber die Freiheit, verschiedene Projektvarianten zur Anwendung der erforderlichen Testmethoden zu nutzen. Die Automobilindustrie ist bestrebt, immer mehr Schritte zu virtualisieren und auch den Anteil der Simulation zu erhöhen, damit die einzelnen Komponenten beim Integrationstest eine möglichst hohe Reife besitzen und so der Integrationstest so früh wie möglich erfolgreich abgeschlossen werden kann.

Für jedes Software-Werkzeug, das in einem sicherheitskritischen Projekt eingesetzt wird, muss das erforderliche Vertrauensniveau klassifiziert werden. Für manche, sehr sicherheitskritische Werkzeuge ist eine Qualifikation erforderlich. Die Zertifizierung der Software-Werkzeuge kann diesen Qualifikationsprozess unterstützen.

Safety of the Intended Function (SOTIF)

Eine spezielle Arbeitsgruppe bei der ISO hat eine Spezifikation namens SOTIF (Safety of the Intended Function) festgelegt. Dieser Standard soll Sicherheitsleitlinien für Funktionen für autonomes Fahren definieren und enthält folgende Punkte:

• Detaillierte, ausgereifte Konzepte einer Architektur für autonomes Fahren (AD)
• Wie man SOTIF-Gefahren bewertet, die sich von ISO-26262-Gefahren unterscheiden
• Wie man Szenarien identifiziert und bewertet sowie Ereignisse auslöst
• Wie können SOTIF-bezogene Risiken reduziert werden?
• Wie kann man SOTIF-bezogene Risiken verifizieren und validieren?
• Kriterien, die vor der Freigabe eines autonomen Fahrzeugs erfüllt sein müssen

Ende 2018 wird der SOTIF-Standard veröffentlicht.

Definition der Anforderungen an Verifikation und Validierung

Jace Allen, Business Development Manager – Simulation, Test and EEDM bei dSPACE Inc., ist überzeugt, dass Unternehmen, die an Entwicklungsprozessen für autonome Systeme beteiligt sind, irgendwann auf die Konformität mit ISO 26262 oder einer ähnlichen, allgemein anerkannten Norm geprüft werden. Derzeit liegt der Schwerpunkt aber noch darauf, die Anforderungen zu definieren.

„Welches sind die Anforderungen an ein autonomes System?" , sagt Allen. „Das weiß derzeit niemand. Deshalb ist die Entwicklung eines Verifikations- und Validierungsprozesses eine große Aufgabe. Bei den aktuellen Tests im Fahrzeug geht es darum, die kritischen Testszenarien herauszufiltern und mit ihrer Hilfe die erforderlichen Anforderungen an die Szenarien zu definieren."

Wenn man bedenkt, wie viele Tests erforderlich sind, um die Funktionalität eines autonomen Fahrzeugs zu validieren, ist es unrealistisch, alle diese Tests auf der Straße durchführen zu wollen. Allerdings kann dieses enorme Vorhaben durch eine Kombination mehrere Maßnahmen umgesetzt werden:

1. Virtuelle Simulationstests, z. B. MIL, SIL HIL
2. Durch Simulation erweiterte Prüfstände
3. Praxistests auf der Straße

Standard-Simulationstechniken erweisen sich aufgrund des Fehlens von Simulations- und Testressourcen möglicherweise als nicht ausreichend für den Umfang der erforderlichen Tests. In diesem Zusammenhang ist es von entscheidender Bedeutung, dass robuste statistische Teststrategien eingesetzt werden, um die Abdeckung für die Validierung zu erweitern. Dazu gehören integrierte probabilistische Teststrategien und sogar fortschrittliche KI-Algorithmen für das Management des Testprozesses. So wird eine größere Abdeckung der Bereiche gewährleistet, um unangemessene Risiken zu reduzieren.

Sensibilisierung für die Umwelt

Für viele OEMs ist ein guter Ausgangspunkt zur Generierung von Anforderungen der Fahrersitz. Die Ingenieure senden Fahrzeuge aus, die mit Sensoren und Datenaufzeichnungsgeräten ausgestattet sind, um reale Situationen zu erfassen (Abbildung 3).

Die während eines Feldversuchs gesammelten Daten werden anschließend im Labor in ein Simulationssystem eingespeist. Mit den Daten eines Szenarios und den Automatisierungswerkzeugen kann ein Ingenieur Tausende von unterschiedlichen Varianten durchspielen, um ein Verständnis für die vielen verschiedenen Möglichkeiten zu entwickeln. Die SOTIF-Spezifikation, die sich noch in der Entwicklung befindet, wird Leitlinien für solche Tests enthalten.

Restrisiken

Wie hoch ist die Wahrscheinlichkeit, dass in einer Welt voller Unwägbarkeiten etwas mit autonomen Fahrzeugen schiefgeht? Und wenn etwas schiefgeht, was wären die Folgen? Um die Auswirkungen von Restrisiken zu verstehen, gilt es, zunächst Risiken zu identifizieren und zu bewerten. Anschließend lässt sich ein Handlungsplan für das Risikomanagement definieren.

Die Risiken werden grob in zwei Kategorien unterteilt: bekannte Risiken und unbekannte Risiken.

Ein akzeptables Maß an Systemsicherheit erfordert die Vermeidung unangemessener Risiken, die durch jedwede Gefahr, einschließlich der Einschränkungen der Regelstrecke, verursacht werden. Um ein akzeptables Niveau zu bestimmen, müssen die bekannten und unbekannten Restrisiken bewertet werden.

Bei bekannten Risiken kann dies durch anforderungsbasiertes Testen geschehen. Die Bewertung unbekannter Risiken erfordert jedoch eine geeignete Kombination von Testansätzen, das heißt anforderungsbasiertes Testen und szenariobasiertes Testen, und den Einsatz stochastischer Techniken.

Überprüfen bekannter Risiken

Ein typischer Prozess zur Validierung bekannter Risiken besteht aus folgenden Schritten:

1. Überprüfen der Anforderungen und Testziele
2. Generieren der Testspezifikationen
3. Entwurf von Testfällen einschließlich ihrer Parameter, also Vorbedingungen, Datenbasis, Eingaben, erwartete Ergebnisse und tatsächliche Ergebnisse.
4. Durchführen und Dokumentieren von Tests
5. Verifizieren von Testergebnissen und Testabdeckung
6. Beheben all derjenigen Probleme, die während des Testprozesses aufgedeckt wurden

Es ist wichtig, Tests zu wiederholen und den Prozess von MIL über SIL bis HIL vollständig nachvollziehbar zu gestalten. Im Hinblick auf die ISO 26262 ist es besonders wichtig, über einen strukturierten und sehr zuverlässigen Testprozess zu verfügen, insbesondere bei der Erstellung und Gestaltung von Testfällen.

Überprüfen unbekannter Risiken

Bei der Validierung der unbekannten Risiken gibt es einen grundlegenden Unterschied. Diese Tests müssen weitgehend auf Wahrscheinlichkeiten basieren. Das anforderungsbasierte Testen wird zwar noch durchgeführt, aber durch das szenariobasierte Testen ergänzt.

Beim szenariobasierten Testen werden wahrscheinliche Szenarien definiert, validiert und durch automatisierte Tests verifiziert. Szenarien sind Nachbildungen möglicher Situationen, die in der realen Welt auftreten, zum Beispiel die Verengung von zwei Fahrspuren auf eine, und das bei starkem Verkehr. Zudem beinhalten sie typischerweise die Interaktion von externen Einflüssen mit einem System, zum Beispiel die Beeinträchtigung der Sicht der vorausschauenden Kamera durch starken Regen.

„Man kann nicht eine Million Szenarien manuell erstellen oder programmieren", so Allen. „Um diese Szenarien zu erstellen, müssen Automatisierungswerkzeuge eingesetzt werden. Und dann müssen diese Szenarien einen intelligent verwalteten und automatisierten Testprozess durchlaufen."

Modellieren von Testszenarien

Um ein Testszenario zu erstellen, muss eine Szene virtuell mit High-Fidelity-Modellen und Simulationswerkzeugen repliziert werden. Ein Testszenario wird in der simulierten Umgebung unter Verwendung der Modellelemente wie Fahrzeug, Fahrzeugumgebungssensoren – Radar, Lidar, GPS, HD-Karten usw., Straße, Straßenverkehr, verschiedene Verkehrsteilnehmer –, Fußgänger, Radfahrer, Schilder und deren erwarteten Verhaltens implementiert. Nach der Modellierung eines Testszenarios besteht der eigentliche Vorteil darin, dass sich durch das Variieren er Modellparameter unzählige Testfälle erzeugen lassen.

Ingenieure, die viele verschiedene Testszenarien simulieren, müssen so nicht jedes einzelne manuell beschreiben. Viele Szenariobeschreibungen können mit Ressourcen und Standards wie Open DRIVE, Open SCENARIO und Open Simulation Interface (OSI) importiert werden. Ingenieure können auch ihre eigenen erfassten Sensordaten aus den Fahrzeugtests verwenden. Mit den so definierten Testszenarien lassen sich nun verschiedene autonome Fahralgorithmen validieren.

Absichern von Funktionen für autonomes Fahren

Wenn ein Fehler- oder Sicherheitsrisiko festgestellt wird, verlangt die ISO 26262, dass das potenzielle Risiko bewertet wird, um ein Sicherheitsziel auf höchster Ebene zu definieren. Nachfolgende Teile der ISO 26262 enthalten Anforderungen und Hinweise zur Vermeidung und Kontrolle von zufälligen Hardware- und systematischen Software-Fehlern, die das Sicherheitsziel gefährden könnten. Die ISO 26262 definiert weiterhin einen standardisierten Ansatz, um die Iteration von der Einheit über die Funktion bis hin zum Test der Systemintegration zu ermöglichen.

Um die Funktionsalgorithmen des autonomen Systems zu validieren, werden typischerweise szenariobasierte Tests während des gesamten Entwicklungsprozesses durchgeführt. Testmethoden im Validierungsprozess:

1. PC-basierte Simulation mit Model-in-the-Loop (MIL) und Software-in-the-Loop (SIL)
2. Hardware-in-the-Loop (HIL)-Simulation
3. Prüfstände
4. Feldversuch/Reale Testfahrten

Zur Unterstützung dieser Testmethoden bietet dSPACE eine komplette Werkzeugkette mit Modellen, fahrzeuginternen Entwicklungs- und Datenerfassungsplattformen, PC-basierter Simulationsumgebung, HIL-Testsystemen und mechanischen Prüfständen. Zudem werden komplette Testpläne einschließlich Straßentests durch eine Daten- und Testmanagement-Lösung unterstützt. Die dSPACE Echtzeitsimulationsmodelle unterstützen ein breites Simulationsspektrum. Mit den dSPACE Automotive Simulation Models (ASM) können Ingenieure ganze virtuelle Fahrzeuge, Straßennetze, Verkehrsmanöver, Verkehrsobjekte, Sensormodelle, Fahrdynamiken und vieles mehr erstellen. Mit standardisierten Schnittstellen lassen sich die Eigenschaften der ASM-Modelle optimal an individuelle Projekte anpassen. Die ASM-Toolsuite bietet auch offene Schnittstellen für den Import von Szenarioinformationen und die Automatisierung der Permutation von Szenarien. Diese Modelle werden dann zusammen mit zusätzlichen Hardware- und Software-Werkzeugen für verschiedene autonome Antriebssysteme mit den oben beschriebenen Testverfahren eingesetzt.

PC-basierte Simulation

Die Tests können bereits in einer sehr frühen Entwicklungsphase mit Hilfe der PC-basierten MIL/SIL-Simulation in einer sicheren Laborumgebung beginnen. Mit Modellen, also mit Funktionsmodellen, Bussystemen, Fahrzeugmodellen usw., sowie virtuellen Steuergeräten (V-ECUs) können Ingenieure einzelne Fahrzeugfunktionen, Fahrzeugsysteme und sogar ganze virtuelle Fahrzeuge unabhängig von der jeweiligen Simulationshardware testen.

Die softwarebasierte Simulationsplattform dSPACE VEOS ermöglicht es Ingenieuren, eine Vielzahl von Simulationen auf einem PC-System durchzuführen. Mit VEOS lassen sich Tests schneller als in Echtzeit ausführen, was einen hohen Testdurchsatz ermöglicht. Durch den Aufbau eines PC-Clusters kann eine große Anzahl an Simulationen parallel durchgeführt werden. Dieses PC-Cluster wird von einer zentralen Einheit gesteuert, die die Ausführung der Simulationsaufgaben und Testfälle terminiert.

Ein wichtiger Punkt dieser Art von MIL/SIL-Tests ist der, dass VEOS die gleichen offenen Standardschnittstellen bietet, die auch für HIL-Tests verwendet werden. Daher können Sie mit demselben Testequipment (Werkzeuge, Szenarien, Modelle, Tests usw.) arbeiten, was Synergieeffekte und Wiederverwendung ermöglicht, was bei der Menge an durchzuführenden Tests unverzichtbar ist.

Mit der PC-basierten SIL-Simulation können die Ingenieure bereits in einer sehr frühen Entwicklungsphase mit dem Testen beginnen – noch bevor HIL-Tests oder Feldversuche/reale Testfahrten durchgeführt werden. Zudem sind durch den Einsatz von virtuellen Steuergeräten Simulation und Test vor Hardware-Freigabe des Steuergeräts oder anderer fehlender Komponenten in einem integrierten System möglich.

HIL-Tests

HIL-Simulationstests sind ein ausgezeichneter Ansatz zur Validierung des Datenfusionsprozesses und der Algorithmen, die von den realen Sensorsystemen des autonomen Testfahrzeugs verwendet werden, zum Beispiel Kamera, Radar, Lidar, Ultraschall etc. HIL-Simulationstests sind deterministisch, wiederholbar, kostengünstig und können rund um die Uhr durchgeführt werden. Darüber hinaus lassen sich auf Basis der HIL-Testergebnisse Qualitätsziele erreichen und Software-Sicherheitsanforderungen verifizieren.

Auch müssen HIL-Tests eingesetzt werden, um tatsächliche „Echzeit“ zu erreichen, wobei alle Software- und Hardware-Aspekte des Systems berücksichtigt werden. Dies ist ein Grundprinzip der ISO 26262 und eine etablierte Standardmethode für die Absicherung von Steuergeräte-Software in der Automobilindustrie.

Für die Simulation müssen Modelle erstellt werden, die das Verhalten der Sensoren wie Kameras, Radar, Lidar, Ultraschall etc. am autonomen Fahrzeug nachbilden. Neben Daten aus V2X und GNSS müssen auch Landkarten modelliert werden, um nicht nur ein vollständiges Bild der Umgebung des Fahrzeugs zu erhalten, sondern auch von dessen Fähigkeit, diese zu erkennen. Die Struktur der Sensorsysteme wird in Funktionsblöcke unterteilt, und die Erfassung basiert auf Erkennungspunkten, die durch physikalische Messungen, Optik, Wellenausbreitung usw. bestimmt werden.

Im HIL-Umfeld ist es auch plausibel, reale Sensoren im Testaufbau zu verwenden. Diese Sensoren müssen dann entsprechend stimuliert werden, um Daten/Informationen zu erzeugen, die ihr Verhalten in der realen Welt nachbilden und im Testszenario abbilden. dSPACE hat spezielle Lösungen zur Stimulation von Sensoren in Testaufbauten über eine spezielle Schnittstelle, die Environment Sensor Interface Unit (ESI Unit), entwickelt. Die ESI-Units sind in der Lage, mehrere Arten und Anzahlen von Sensoren synchron zu stimulieren, um die Echtzeitintegrität der gesamten Testumgebung aufrechtzuerhalten.

Daher haben die Ingenieure mit der dSPACE Werkzeugkette verschiedene Optionen für die Tests zur Verfügung, die unterschiedliche Funktionen bieten, um die Testziele zu erreichen (Abbildung 4).

Prüfstände

Wenn es darum geht, mechanische Komponenten der Antriebssysteme in die HIL-Simulationsumgebung einzubinden, bietet es sich an, Prüfstand und HIL zu integrieren. Der Prüfstand unterstützt das Testen realer mechanischer Grenzen, bietet Hardware-Qualitätssicherung und ermöglicht die Einbindung integrierter Sensoren und Aktoren.

Beispiele für Anwendungen, die auf einem Prüfstand getestet werden können: Radarsensoren, integrierte Sensoren, elektrische Servolenkung, elektrische Bremsung und Hinterradlenkung.

Anforderungen an einen mechanischen Prüfstand:

• Gesamte HIL-Umgebung (Software und Hardware)
• Leistungsstarke, latenzarme HIL-Kopplung mit den Prüfstandssteuerungen
• Anwendungsspezifische Dynamik des Lastaktors
• Elektrischer Aufbau mit rauscharmer Verbindung der Messsignale

Ein Prüfstand zur Sensorstimulation erfordert intelligente Sensoren mit Busschnittstelle (CAN, LIN), Positionssensoren (Schalthebel), Winkelsensoren (Lenkung) und die Möglichkeit, relevante physikalische Verhaltensweisen wie Gierrate und Beschleunigung einschließlich der erforderlichen Freiheitsgrade einzuspeisen.

Feldversuch/Reale Testfahrten

Während virtuelle Simulationstests den Prozess erheblich beschleunigen und die Vielzahl der erforderlichen Testszenarien für autonome Fahrzeuge besser abdecken, sind Feldversuche/reale Testfahrten nach wie vor ein Muss, um reale Fahrbedingungen zu bewerten und die durch virtuelle Tests erzielten Testergebnisse zu überprüfen.

Nachdem die Funktionalität von Sensorsystemen und Algorithmen in einer simulierten Umgebung nachgewiesen wurde, führen die Testingenieure echte Testfahrten durch, um die Leistungsfähigkeit des autonomen Fahrzeugs unter realen Wetterbedingungen wie Regen, Schnee, Eis, Nebel, Dunkelheit, Hitze und Kälte zu testen. Auf diese Weise ist es auch möglich, eine endgültige Abstimmung vorzunehmen und außerdem auch den Umgang der Sensoren mit realen Situationen zu validieren.

Verwaltung von Testdaten und -prozessen

Für jede Testmethode und jedes Verkehrsszenario, das zur Absicherung von Funktionen für autonomes Fahren durchgeführt werden muss, wird eine große Menge an Tests und Daten generiert. Und diese Flut an Informationen muss verwaltet werden.

Aus Sicht des Datenmanagements entstehen im Wesentlichen folgende Aufgaben und Herausforderungen:

• Speichern und Verwalten der Daten (Sicherstellung der Verfügbarkeit)
• Verbinden und Verknüpfen der Daten und Speichern der Verbindungen (Nachverfolgbarkeit)
• Bereitstellen von APIs und offenen Schnittstellen für die Test- und Prozessautomatisierung
• Ermöglichen der Wiederverwendung, um neue Versionen der Steuergeräte-Software schnell zu testen und zu validieren, indem zuvor ausgeführte Szenarien und Tests eingesetzt werden.
• Teilen der Daten und Ergebnisse innerhalb des Teams und der Organisation

Um die Anforderungen der ISO 26262 an die Dokumentation von Tests von Sicherheitsanforderungen zu erfüllen, bietet dSPACE das Datenverwaltungswerkzeug SYNECT. SYNECT unterstützt die Verwaltung von Testfällen, Ausführungen und Testergebnissen. Das Software-System ist flexibel und anpassbar und kann verwendet werden, um Testszenarien und andere mit dem Testprozess zusammenhängende Dinge wie Modelle, Parameter usw. zu verwalten. Darüber hinaus bietet es die notwendigen Optionen und Schnittstellen für die Automatisierung des Prozesses und des Workflows. VEOS bietet offene Schnittstellen und Standards zur Automatisierung vieler COTS-Testwerkzeuge und zur Anbindung von Application-/Product-Lifecycle-Management (ALM/PLM)-Systemen an den modellbasierten Entwicklungsprozess.

Fazit und Ausblick

Die Validierung von Funktionen für das autonome Fahren ist abhängig von der Definition der Anforderungen. Die ISO 26262 fördert den Einsatz von Model-in-the-Loop (MIL)-, Software-in-the-Loop (SIL)- und Hardware-in-the-Loop (HIL)-Methoden als Teil des Prozesses zur Absicherung von Anforderungen an die Sicherheit einer Software.

Es ist unmöglich, jedes denkbare Szenario des autonomen Fahrens auf der Straße zu testen. Die überwiegende Mehrheit der Testszenarien muss modelliert und dann mit einer Kombination aus MIL-, SIL- und HIL-Simulation, Prüfständen und Feldversuchen/realen Testfahrten getestet werden.

Um unsere Kunden bei der Gestaltung eines Prozesses nach ISO 26262 und SOTIF zu unterstützen, bietet dSPACE Beratungsleistungen und eine zugehörige Werkzeugkette, die auf offenen Standards und Application Programming Interfaces (APIs) basiert. Diese ermöglichen eine Automatisierung der Testgenerierungs- und Testprozesse und haben einen entscheidenden Vorteil bei der Anpassung anspruchsvoller probabilistischer Testmethoden. Um Funktionen für autonomes Fahren abzusichern, ist eine enorme Anzahl an Tests erforderlich. Die dSPACE Werkzeugkette bietet die notwendigen Datenmanagementfunktionen, die für die Handhabung der riesigen Mengen an Szenarien und Daten unerlässlich sind.