DE102017009971A1

DE102017009971A1 - Verfahren zum Testen eines Spurhalteassistenzsystems für ein Fahrzeug

Info

Publication number: DE102017009971A1
Application number: DE102017009971.5A
Authority: DE
Inventors: Mohamed Elgharbawy; Andreas Schwarzhaupt; Michael Frey
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2017-10-26
Filing date: 2017-10-26
Publication date: 2019-05-02

Abstract

Die Erfindung betrifft ein Verfahren zum Testen eines Spurhalteassistenzsystems (3) für ein Fahrzeug (2), insbesondere für einen Lastkraftwagen.
Erfindungsgemäß wird ontologiebasiert eine Kategorie adäquater und relevanter Szenarien für existierende Feldtests extrahiert.

Description

Die Erfindung betrifft ein Verfahren zum Testen eines Spurhalteassistenzsystems für ein Fahrzeug.
Aus dem Stand der Technik sind Spurhalteassistenzsysteme für Fahrzeuge allgemein bekannt. Ebenso ist es allgemein bekannt, derartige Spurhalteassistenzsysteme, insbesondere in einer Entwicklungsphase, zu testen.
Der Erfindung liegt die Aufgabe zu Grunde, ein gegenüber dem Stand der Technik verbessertes Verfahren zum Testen eines Spurhalteassistenzsystems für ein Fahrzeug anzugeben.
Die Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zum Testen eines Spurhalteassistenzsystems für ein Fahrzeug mit den Merkmalen des Anspruchs 1.
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
In einem erfindungsgemäßen Verfahren zum Testen eines Spurhalteassistenzsystems für ein Fahrzeug, insbesondere für einen Lastkraftwagen, wird ontologiebasiert eine Kategorie adäquater und relevanter Szenarien für existierende Feldtests extrahiert, wobei vorteilhafterweise kritische Szenarien, insbesondere ungünstigster-Fall-Szenarien, d. h. so genannte worst-case-Szenarien, mittels Data-Mining extrahiert und in Anforderungen für eine Testabdeckung transformiert werden.
Das erfindungsgemäße Verfahren und eine entsprechende Vorrichtung zur Durchführung des Verfahrens ermöglichen eine adaptive Testabdeckung für das Spurhalteassistenzsystem. Das Verfahren ermöglicht es, eine Kluft zwischen wissensbasierten und datenbasierten Ansätzen zu schließen, um eine kontinuierliche Erweiterung des Wissens in der adaptiven Testabdeckung zu ermöglichen.
Im Verfahren werden als obligatorische Verfahrensschritte beispielsweise folgende Schritte durchgeführt, wobei deren Reihenfolge veränderbar ist:

I. Ereignisbasiertes Data-Mining
II. Clustering, d. h. Gruppierung, von naturalistischen Fahrszenarien basierend auf Spurverlassenswarnereignissen des Spurhalteassistenzsystems
III. Training eines Klassifikators mit markierten Clusterdaten
IV. Anwendung des Klassifikators mit naturalistischen Fahrdaten
V. Nutzung der klassifizierten Clusterdaten zur Ermittlung der charakteristischen Verläufe der Systemeingangsgrößen für die jeweilige Gruppierung
VI. Identifikation eines zu den charakteristischen Verläufen zugehörigen Szenarios
VII. Bestimmen der jeweiligen Gruppe durch eine Parameter- und Signalschätzung von der Zeitreihenanalyse
VIII: Ableitung von worst-case-Szenarien, d. h. von ungünstigster-Fall-Szenarien
IX. zeitliche Kombination unterschiedlichen Charakterisierungen eines charakteristischen Signalverlaufs
X. Parsing von Felddaten in ein für die synthetische Umgebung geeignetes Format
XI. Kombination von Einzelergebnissen zu einem Testablauf
XII. Beschreiben des Testablaufs in einem De-facto-Standardformat
XIII. Testausführung auf einer so genannten auf Cluster-in-the-Loop-Plattform
XIV. Auswertung von Testfällen mittels Bestanden- und Durchgefallen-Kriterien
XV. Anwendung der adaptiven Testabdeckung

Eine weitere Vorgehensweise zur Berücksichtigung zusätzlicher Felddaten bei bereits ermittelten charakteristischen Verläufen der Systemeingangsgrößen sieht beispielsweise als optionale Verfahrensschritte vor:

XVI. Vergleich der zusätzlichen Felddaten mit charakteristischen Verläufen
XVII. Gegebenenfalls Erweiterung der Anzahl der Cluster für die Gruppierung
XVIII. Wiederholung und Anwendung der Schritte von II bis XV.

Ausführungsbeispiele der Erfindung werden im Folgenden anhand von Zeichnungen näher erläutert.
Dabei zeigen:

1 schematisch eine Einbindung einer adaptiven Testabdeckung in einen Erprobungsprozess am Beispiel eines Spurhalteassistenzsystems,
2 schematisch eine Unterscheidung in Anwendungsfall, verschiedene Szenarien, Situationen und Szenen sowie deren Bestandteile,
3 schematisch eine Darstellung der Unterschiede zwischen Tests einzelner Einheiten oder Komponenten, einem situationsbasierten open-loop-testing und einem szenarienbasierten closed-loop-testing,
4 schematisch eine ontologiebasierte Testszenariosynthese,
5 schematisch eine Distanz bis zum Überfahren einer Fahrspurmarkierung bei einem Szenario mit gerader Straße,
6 schematisch eine Distanz bis zum Überfahren einer Fahrspurmarkierung bei einem Szenario mit gekrümmter Straße,
7 schematisch eine Identifizierung von Parametern, zum Beispiel der Time to Line Crossing, d. h. der Zeit bis zum Überfahren einer Fahrspurmarkierung, mit unterschiedlichen Quergeschwindigkeiten an einer Cluster-in-the-Loop Plattform,
8 schematisch eine ereignisbasierte Analyse einer Distanz bis zum Überfahren einer Fahrspurmarkierung,
9 schematisch ein Clustering einer ereignisbasierten Analyse,
10 schematisch eine Anwendung des Clustering auf eine ereignisbasierte Analyse einer Distanz bis zum Überfahren einer Fahrspurmarkierung,
11 schematisch charakteristische Verläufe der Systemeingangsgrößen für den jeweiligen Cluster, und
12 schematisch ein Verfahren und eine Vorrichtung zum Testen eines Spurhalteassistenzsystems mittels Data-Mining von Fahrzeugdaten und adaptiver Testabdeckung.

Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
Im Folgenden werden anhand der 1 bis 12 ein Verfahren zum Testen eines Spurhalteassistenzsystems 3 für ein Fahrzeug 2, insbesondere für einen Lastkraftwagen, und eine Vorrichtung zur Durchführung des Verfahrens beschrieben. Damit wird eine adaptive Testabdeckung 9 für das Spurhalteassistenzsystem 3 ermöglicht.
Die digitale Transformation hat zu schnellen und tiefgreifenden Veränderungen in der Lastkraftwagenindustrie geführt und wird die Zukunft des Güterverkehrs verändern und zu einer Ära digitalisierter Lastkraftwagen führen. Aufgrund globaler Forschungs- und Entwicklungsaktivitäten nimmt die Technologiereife des automatisierten Fahrens ständig zu. In diesem Wachstumstrend sind Daten von besonderer Bedeutung, um diese Umwandlung zu fördern. Jedes Fahrzeug 2, welches mit einer entsprechenden Datenerfassung ausgerüstet ist, produziert täglich ein großes Datenvolumen bezüglich öffentlicher Straßen und deren entsprechenden geographischen Variation. Dies erfordert höhere Kapazitäten zur Datenerfassung und -speicherung, hat aber den Vorteil, dass eine vollständige Re-Simulation mit modifizierten funktionalen Software-Versionen über alle Feldtests (Field Operational Test - FOT) ermöglicht wird.
Lastkraftwagen, insbesondere schwere Lastkraftwagen, und Personenkraftwagen unterscheiden sich in ihrer wirtschaftlichen Bedeutung und in ihrer Fahrzeugtechnik. Trotz rascher Fortschritte im Bereich der Umgebungserfassungssensortechnologie sind die Anforderungen an die Umgebungserfassungssensorik bei Lastkraftwagen, insbesondere bei schweren Lastkraftwagen, deutlich höher als bei Personenkraftwagen. Infolgedessen stellen Lastkraftwagen, insbesondere schwere Lastkraftwagen, eine große Herausforderung bei der Überprüfung und Validierung von automatisierten Fahrfunktionen dar. Zufallsfehler werden in der Regel durch stochastische Analysen von gefahrenen Kilometern ermittelt. Im Gegensatz dazu können systematische Fehler identifiziert und lokalisiert werden durch eine sorgfältige Analyse, eine geeignete Vorrichtungsausstattung zur Durchführung der Tests und eine entsprechende Systemdezentralisierung. Daher wird ein methodischer Ansatz benötigt, um das Test-Dilemma der automatisierten Fahrfunktionen zu überwinden und eine erfolgreiche Markteinführung zu ermöglichen.
Software-Produktlinien haben daten- und wissensbasierte Testmethoden etabliert, um die erforderliche Zuverlässigkeit ihrer Produkte sicherzustellen. Datenbasierte Ansätze analysieren empirische Daten, um automatische Fahrsysteme basierend auf ihren so genannten Key Performance Indicators (KPIs) d. h. basierend auf ihren Hauptleistungsindikatoren, zu validieren. Um im Laufe der Produktentwicklung eine effiziente Verifizierung zu ermöglichen, werden verschiedene so genannte X-in-the-Loop (XiL) Simulationen, reichend von makroskopischen bis nanoskopischen Verkehrssimulationen, eingesetzt. Diese synthetischen simulativen Ansätze werden häufig in einem so genannten closed-loop setting verwendet, d. h. in einer geschlossenen Schleife, um die Anforderungen der Testabdeckung sicherzustellen, welche definiert wird durch Fachwissen in Form von Aussagen in natürlicher Sprache. Implizite Informationen werden von Experten in Form von formalen Testanforderungen explizit gemacht. Trotz der einfachen Nachverfolgbarkeit dieses Ansatzes ist einer seiner Hauptnachteile die Annahme der Wissensvollständigkeit.
Trotz der Vielfalt der repräsentativen Situationen im Straßenverkehr mit einem strecken basierten Testansatz ist eine drastische Reduzierung der erforderlichen Fahrstrecke erforderlich. Ein Ausweg aus diesem Dilemma besteht darin, eine Initialroute zu bestimmen, die eine Vielfalt möglicher Variationen im Straßenverkehr ermöglicht. Darüber hinaus muss ein Testkatalog identifiziert werden, um einen Parameterbereich relevanter Szenarien und Systemumgebungen adäquat abzudecken. Anschließend ist eine Korrelation zwischen realen und simulierten Daten notwendig, um abzuleiten, ob mehr Testkilometer erforderlich sind oder mehr Simulationen durchgeführt werden müssen. Der im Folgenden näher beschriebene Ansatz zielt darauf ab, die Kluft zwischen wissensbasierten und datenbasierten Ansätzen zu überbrücken und eine kontinuierliche Erweiterung des Wissens in einer adaptiven Testabdeckung 9 zu ermöglichen.
Die Erfindung, welche im Folgenden anhand von Ausführungsbeispielen beschrieben wird, betrifft ein Verfahren und eine Vorrichtung zum Testen eines Spurhalteassistenzsystems 3 für ein Fahrzeug 2, insbesondere für einen Lastkraftwagen, insbesondere zum Testen eines Spurhaltewarnprozesses. Es ist eine ontologiebasierte Methode identifiziert, um eine Kategorie von adäquaten und relevanten Szenarien für bestehende Feldtests, auch als Field Operational Tests (FOT) bezeichnet, zu extrahieren. Es stellt ein Konzept für eine semantische Repräsentation von worst-case-Szenarien dar. Diese sind mittels Data-Mining-Techniken zu extrahieren und systematisch in Anforderungen für eine Testabdeckung umzuwandeln. Das vorgeschlagene Konzept zielt darauf ab, die Lücke zwischen wissens- und datenbasierten Ansätzen zu schließen, um eine kontinuierliche Erweiterbarkeit des Wissens in einer adaptiven Testabdeckung 9 zu ermöglichen, wie in 1 dargestellt.
1 zeigt eine adaptive Testabdeckung 9 am Beispiel des Spurhalteassistenzsystems 3, wobei die funktionale Spezifikation 30 aus Spitzenanforderung 32 und Anwendungsfällen 13 erstellt und in natürlicher Sprache formuliert ist. Diese bilden die Basis für das wissensbasierte Testen 40, welches das zu testende Spurhalteassistenzsystem 3 mit konkreten Szenarien 16 beaufschlägt. Die Adaption besteht nun in der Erweiterung der mit Hilfe des wissensbasierten Testens erzeugten konkreten Szenarien 16 durch weitere logische Szenarien 15, welche ontologiebasiert, d. h. mittels einer ontologiebasierten Szenariosynthese 27, aus funktionalen Szenarien 14 synthetisiert werden. Dabei werden die funktionalen Szenarien 14 aus dem datenbasierten Testen, insbesondere aus einem ereignisbasierten Data-Mining 26, abgeleitet. Dabei kennzeichnet Bezugszeichen 1 ein natürliches Fahrszenario, welches mit dem Fahrzeug 2 mit dem Spurhalteassistenzsystem 3 in einer realen Testfahrt befahren wird, d. h. ein reales Fahrszenario. Mit Bezugszeichen 4 ist ein synthetisches Fahrszenario gekennzeichnet, welches mit Kamera-Box 5 für das Spurhalteassistenzsystem 3 erfasst oder in dieser oder mittels dieser für das Spurhalteassistenzsystem 3 simuliert wird. Jeweilige Ereignisse 6, 7 des Spurhalteassistenzsystems 3 werden einer mit dem Bezugszeichen 8 gekennzeichneten Kritikalitätsanalyse, insbesondere auf Basis einer so genannten Time to Line Crossing, d. h. einer Zeit bis zum Überfahren einer Fahrspurmarkierung, zugeführt. Das Bezugszeichen 9 kennzeichnet die adaptive Testabdeckung 9, welche aus der Kritikalitätsanalyse 8 resultiert. Bezugszeichen 10 kennzeichnet ein so genanntes Parsing, d. h. eine Konvertierung in eine de-facto Standard Beschreibungssprache, von worst-case-Szenarien auf Basis der Kritikalitätsanalyse 8. Zwischen der adaptiven Testabdeckung 9 und einer Testautomation 11 besteht eine Wechselbeziehung. Die Testautomation 11 und das Parsing von worst-case-Szenarien 10 beeinflussen das synthetische Fahrszenario 4 und/oder die Kamera-Box 5. Des Weiteren beeinflusst eine Fahrzeugdynamik 12 das synthetische Fahrszenario 4.
Die Vision des unfallfreien Verkehrs beschleunigt die Weiterentwicklung von intelligenten, verbundenen und komplexen Fahrfunktionen in Fahrzeugen 2. Deswegen müssen Testverfahren mit diesen steigenden Anforderungen umgehen. Datenbasierte Ansätze analysieren empirische Daten, um neues Wissen zu gewinnen zu explizieren. Neben der Statistik der Ursachen von Unfällen als empirische Daten werden zunehmend naturalistische Fahrdaten als Quelle des Wissens angenommen. Gleichwohl ist eine statistische Validierung mittels Feldtests, dem so genannten Field Operational Testing (FOT) sehr zeitaufwändig und ressourcenaufwändig und umfasst Milliarden von Kilometern realer Fahrtests für eine erfolgreiche Markteinführung eines vollautomatischen Fahrzeugs 2. Trotz dieser Nachteile ist dies wichtig, um die Funktionssicherheit und Zuverlässigkeit sicherzustellen.
Eine Re-Simulation aufgezeichneter Fahrsequenzen erleichtert situationsbezogene Regressionstests im Open-Loop-Setting. Um im Laufe der Produktentwicklung eine effiziente Verifizierung zu ermöglichen, werden verschiedene so genannte X-in-the-Loop (XiL) Simulationen, reichend von makroskopischen bis nanoskopischen Verkehrssimulationen, eingesetzt. Diese synthetischen simulativen Ansätze werden häufig in einem so genannten closed-loop setting verwendet, d. h. in einer geschlossenen Schleife, um die Anforderungen der Testabdeckung sicherzustellen, welche definiert wird durch Fachwissen in Form von Aussagen in natürlicher Sprache. Implizite Informationen werden von Experten in Form von formalen Testanforderungen explizit gemacht. Trotz der einfachen Nachverfolgbarkeit dieses Ansatzes ist einer seiner Hauptnachteile die Annahme der Wissensvollständigkeit.
Aktuelle Forschungsanstrengungen nutzen Data-Mining Techniken im Rahmen der Fahrerverhaltensbewertung oder Fallstudienanalyse. Aufgrund der Interaktion von Fahrerassistenzsystemfunktionen mit der Umgebung wird das Testen hochkomplex und eine Validierung kann nicht mit einem einzigen Testansatz realisiert werden, wie in den 2 und 3 dargestellt.
2 zeigt eine Darstellung der Unterschiede zwischen Tests einzelner Einheiten oder Komponenten, dem so genannten Unit Testing UT, einem situationsbasierten open-loop-testing, d. h. einem situationsbasierten Test mit offener Schleife, und einem szenarienbasierten closed-loop-testing CLT, d. h. einem szenarienbasierten Test mit geschlossener Schleife. Dabei ist mit dem Bezugszeichen 13 ein Anwendungsfall, d. h. ein Use Case, gekennzeichnet. Bezugszeichen 14 kennzeichnet ein jeweiliges funktionales Szenario. Bezugszeichen 15 kennzeichnet ein jeweiliges logisches Szenario. Bezugszeichen 16 kennzeichnet ein jeweiliges konkretes Szenario. Bezugszeichen 17 kennzeichnet eine jeweilige Situation. Bezugszeichen 18 kennzeichnet eine Szene.
Bezugszeichen 19 kennzeichnet einen Fahrer des Fahrzeugs 2. Bezugszeichen 20 kennzeichnet eine Aktion. Bezugszeichen 12 kennzeichnet die Fahrzeugdynamik. Bezugszeichen 21 kennzeichnet Sensoren des Fahrzeugs 2. Bezugszeichen 22 kennzeichnet eine Fahrfunktion. Bezugszeichen 23 kennzeichnet Aktoren des Fahrzeugs 2 und Bezugszeichen 24 statische und dynamische Elemente. Der Fahrer 19 und die Aktoren 23 beeinflussen eine Aktion 20, welche zu einer entsprechenden Fahrzeugdynamik 12 führt. Die Fahrzeugdynamik 12 und die statischen und dynamischen Elemente 24, insbesondere in der Umgebung des Fahrzeugs 2, werden von den Sensoren 21 des Fahrzeugs 2 erfasst. Entsprechende Sensorergebnisse werden der Fahrfunktion 22 zugeführt und führen zu einer entsprechenden Ansteuerung der Aktoren 23.
In 3 sind das situationsbasierte open-loop-testing OLT mit dem Unit Testing UT und das szenarienbasierte closed-loop-testing CLT im Zeitverlauf ZV dargestellt, wobei das Bezugszeichen 25 Ziele und Werte kennzeichnet. Zweckmäßigerweise werden das situationsbasierte open-loop-testing OLT mit dem Unit Testing UT und das szenarienbasierte closed-loop-testing CLT nacheinander durchgeführt, beispielsweise auch ein- oder mehrfach wiederholt nacheinander.
4 zeigt eine ontologiebasierte Testszenariosynthese. Es wird zunächst ein ereignisbasiertes Data-Mining 26 mit einer ontologiebasierten Szenariosynthese 27 durchgeführt.
Die ontologiebasierte Szenariosynthese 27 umfasst:

1. Szenariofilterung mittels einer Kritikalitätsmatrix
2. Ermittlung einer Szenariozugehörigkeit
3. Clusterbildung, d. h. Gruppierung, von Fahrszenarien, insbesondere basierend auf Spurverlassenswarnereignissen des Spurhalteassistenzsystems 3
4. Identifizieren von Parametern, zum Beispiel der Time to Line Crossing, d. h. der Zeit bis zum Überfahren einer Fahrspurmarkierung

Aus dem ereignisbasierten Data-Mining 26 resultieren die logischen Szenarien 15, welche in eine systematische Testfallgenerierung 28 mit einem generischen Modell für eine Szenariobeschreibung 29 einfließen.
Dieses generische Modell für die Szenariobeschreibung 29 umfasst:

1. eine Straßengeometrie, zum Beispiel Krümmung und/oder andere Parameter
2. statische Objekte, zum Beispiel Verkehrszeichen und/oder andere statische Objekte
3. dynamische Objekte, zum Beispiel andere Fahrzeuge und/oder andere dynamische Objekte
4. Wetterverhältnisse, zum Beispiel Regen und/oder andere Wetterverhältnisse

Aus der systematischen Testfallgenerierung 28 resultieren die konkreten Szenarien 16 und daraus Testfälle 31. In die Testfälle 31 fließt des Weiteren eine funktionale Spezifikation 30 ein, welche aus Spitzenanforderungen 32 und den Anwendungsfällen 13 resultiert, wobei die Spitzenanforderungen 32 auch in die Anwendungsfälle 13 einfließen.
Die Testfälle 31 werden in einer Testausführung 33 mit einer so genannten Cluster-in-the-Loop Plattform 34 verwendet. Cluster-in-the-Loop steht für Subsystem-in-the-Loop. Ein Subsystem kann ein Komponenten-Cluster oder eine Komponente sein. Eine daraus resultierende Änderung ausgewählter Parameter 35 fließt in die systematische Testfallgenerierung 28 ein.
Testresultate 36 der Testausführung 33 fließen in eine Testevaluierung, d. h. in eine Testauswertung 37, ein. Es erfolgt eine Auswertung 38 der Testfälle 31 mittels Bestanden- und Durchgefallen-Kriterien. Basierend auf dieser Auswertung sind gegebenenfalls Änderungen am zu testenden System vorzunehmen. Beispielsweise muss das Produkt nachgebessert werden, falls es die gewünschte Spezifikation nicht erfüllt.
Im Folgenden wird die Ermittlung der so genannten Time to Line Crossing, d. h. der Zeit bis zum Überfahren der Fahrspurmarkierung, näher beschrieben. Hierzu wird zunächst eine trigonometrische Berechnung beschrieben.
Eine mathematische Beschreibung der Time to Line Crossing t_LC ist wie folgt: $t_{L C} = \frac{d_{L C}}{v_{e g o}}, \forall v_{e g o} > 0$
Dabei ist d_LC [m] eine Distanz bis zum Überfahren der Fahrspurmarkierung entlang eines Fahrwegs des Fahrzeugs 2 und v_ego [m/s] ist eine Geschwindigkeit des Fahrzeugs 2, welche beispielsweise eine Längsgeschwindigkeit v_längs [m/s] und/oder eine Lateralgeschwindigkeit v_lat [m/s] des Fahrzeugs 2 umfasst (Die jeweilige Angabe in eckigen Klammern gibt die Dimension des jeweiligen Parameters an). Der Parameter d_LC [m] ist direkt berechenbar mittels der Kosinusregel: $d_{L C} = α * r_{e g o}$
wobei der Radius r_ego des Fahrwegs des Fahrzeugs 2 berechnet wird als $r_{e g o} = \frac{v_{l ä n g s}}{φ}$
mit cp[rad/s] als Gierrate des Fahrzeugs 2. α ist der Winkel zwischen einer Linie von einem Zentrumpunkt (x,y)_ego einer Trajektorie des Fahrzeugs 2 zu einem Fahrspurverlassenspunkt p und einer Linie von einem Vorderrad des Fahrzeugs 2 zum Zentrumpunkt (x,y)_ego, wie in der 5 dargestellt, welche die Distanz d_LC[m] bis zum Überfahren der Fahrspurmarkierung bei einem Szenario mit gerader Straße zeigt.
Im Fall eines solchen Szenarios mit gerader Straße wird der Winkel α mittels der Kosinusregel berechnet: $α = arccos ((\frac{b^{2} + r_{e g o}^{2} - c^{2}}{2 * b * c}))$
wobei $b = r_{e g o} - \frac{f}{cos (γ)}$
Dabei ist f die Distanz zwischen dem Vorderrad des Fahrzeugs 2 und einer Fahrspurgrenze entlang einer rechtwinkligen Linie zum Straßenverlauf, γ der Winkel zwischen dieser rechtwinkligen Linie f und einer Linie zwischen dem Vorderrad des Fahrzeugs 2 und dem Zentrumpunkt (x,y)_ego, b der Abstand zwischen dem Zentrumpunkt (x,y)_ego und der Fahrbahngrenze auf der Linie zwischen dem Zentrumpunkt (x,y)_ego und dem Vorderrad des Fahrzeugs 2 und c der Abstand zwischen dem Fahrspurverlassenspunkt p und dem Schnittpunkt zwischen Fahrspurgrenze und der Linie zwischen dem Zentrumpunkt (x,y)_ego und dem Vorderrad des Fahrzeugs 2. β ist ein Winkel zwischen der Fahrspurgrenze und der Linie zwischen dem Zentrumpunkt (x,y)_ego und dem Vorderrad des Fahrzeugs 2 und d ist ein Abstand zwischen dem Vorderrad des Fahrzeugs 2 und der Fahrspurgrenze auf der Linie zwischen dem Zentrumpunkt (x,y)_ego und dem Vorderrad des Fahrzeugs 2. $c = \frac{2 * b * cos (β) + \sqrt{{(2 * b * cos (β))}^{2} - 4 (b^{2} - r_{e g o}^{2}))}}{2}$
Im Gegensatz dazu zeigt 6 das Szenario mit gekrümmter Straße. In diesem Fall wird der Winkel α berechnet als $α = δ - ε$
Der Parameter δ ist ein Winkel zwischen einer Linie vom Zentrumpunkt (x,y)_ego zu einem Straßenkurvenzentrumpunkt (x,y)_road und einer Linie vom Zentrumpunkt (x,y)_ego zum linken Vorderrad des Fahrzeugs 2 und ε ist der Winkel zwischen der Linie vom Fahrspurverlassenspunkt p zum Zentrumpunkt (x,y)_ego und der Linie zwischen dem Zentrumpunkt (x,y)_ego und dem Straßenkurvenzentrumpunkt (x,y)_road. $ε = \frac{arccos (e^{2} + r_{e g o}^{2} - r_{r o a d}^{2})}{2 * e * r_{e g o}}$
Dabei ist e der Abstand zwischen dem Zentrumpunkt (x,y)_ego und dem Straßenkurvenzentrumpunkt (x,y)_road und r_road ist der Radius des gekrümmten Straßensegments.
Im Folgenden wird das ereignisbasierte Data-Mining 26 für die Ermittlung der so genannten Time to Line Crossing beschrieben.
Zunächst erfolgt eine Extraktion von Parametern, zum Beispiel die Time to Line Crossing, zum semantischen Beschreiben von Fahrszenarien, wie in 7 gezeigt. 7 zeigt eine ereignisbasierte Analyse der Distanz d_LC bis zum Überfahren der Fahrspurmarkierung aus synthetischen Fahrdaten im Koordinatensystem der Videokamera basierend auf dem optischen Fluss des Videostroms der Videokamera, welche an der Cluster-in-Loop-Plattform angewendet werden, für drei unterschiedliche Lateralgeschwindigkeiten v_lat . Auf der Abszissenachse ist die Zeit t abgetragen und auf der Ordinatenachse die Distanz f zwischen Fahrzeug 2 und Fahrspurmarkierung.
8 zeigt die Distanz f zwischen Fahrzeug 2 und Fahrspurmarkierung ohne Gruppierung.
Dann erfolgt eine Plausibilisierung durch Erarbeitung von Kriterien aus synthetischen Fahrdaten.
Dann erfolgt eine Erfassung ausgewählter Parameter basierend auf einer prinzipiellen Komponentenanalyse K1, K2.
Dann erfolgt ein Clustering, d. h. eine Gruppierung, von natürlichen Fahrszenarien 1 basierend auf Spurverlassenswarnereignissen des Spurhalteassistenzsystems 3, wie in 9 gezeigt. 9 zeigt ein Clustering einer ereignisbasierten Analyse. Auf der Abszissenachse ist eine erste prinzipielle Komponentenanalyse K1 abgetragen und auf der Ordinatenachse eine zweite prinzipielle Komponentenanalyse K2. Dargestellt sind die Cluster C0, C1, C2.
Dann erfolgt ein Klassifikatortraining mit markierten Clusterdaten, wie in 10 gezeigt. 10 zeigt beispielsweise die Zeitreihenanalyse für die jeweilige Gruppierung nach dem Klassifikatortraining.
Dann erfolgt eine Anwendung des Klassifikators mit naturalistischen Fahrdaten, wie in 11 gezeigt. 11 zeigt die Anwendung des Clustering auf die ereignisbasierte Analyse einer Distanz bis zum Überfahren einer Fahrspurmarkierung zu einem Referenzmodell des charakteristischen Verlaufes der Systemeingangsgrößen für den jeweiligen Cluster C0, C1, C2, wobei ein jeweiliger Signalprototyp S0, S1, S2 dargestellt ist.
Dann erfolgt eine Identifizierung der jeweiligen Gruppe durch eine Parameter- und Signalschätzung von der Zeitreihenanalyse.
Dann erfolgt ein Parsing von Felddaten in ein für die synthetische Umgebung geeignetes Format.
Abschließend erfolgt ein Beschreiben von Szenarien in einem De-facto-Standardformat.
12 zeigt eine schematische Darstellung des Verfahrens und der Vorrichtung zur Evaluierung des Spurhalteassistenzsystems 3 mittels Data-Mining von Fahrzeugdaten.
Bezugszeichen 1 kennzeichnet auch hier das natürliche Fahrszenario und somit eine reale Testfahrt.
Bezugszeichen 2 kennzeichnet auch hier das Fahrzeug 2, beispielsweise ein realer Lastkraftwagen.
Bezugszeichen 4 kennzeichnet auch hier das synthetische Fahrszenario und somit eine virtuelle Testfahrt, d. h. eine Simulation.
Bezugszeichen 39 kennzeichnet ein datenbasiertes Ausdauertesten.
Bezugszeichen 40 kennzeichnet ein wissensbasiertes Testen des Fahrzeugs 2.
Bezugszeichen 41 kennzeichnet ein datenbasiertes Clustertesten.
Bezugszeichen 42 kennzeichnet ein wissensbasiertes Clustertesten.
Bezugszeichen 43 kennzeichnet ein Fahrzeugdynamikmodell, insbesondere Lastkraftwagendynamikmodell, inklusive einer Fahrerkabine.
Bezugszeichen 44 kennzeichnet eine Steuergerätplattform für automatische Fahrfunktionen.
Bezugszeichen 45 kennzeichnet ein Aktormodell.
Bezugszeichen 46 kennzeichnet ausgelöste Ereignisse.
Bezugszeichen 47 kennzeichnet eine integrierte Datenbank.
Bezugszeichen 48 kennzeichnet Data-Mining und Analyse.
Bezugszeichen 49 kennzeichnet eine Auswahl von Fahrfällen.
Bezugszeichen 50 kennzeichnet eine semantikbasierte Funktionalspezifikation.
Bezugszeichen 32 kennzeichnet auch hier die Spitzenanforderungen.
Bezugszeichen 51 kennzeichnet die Fahrfälle.
Bezugszeichen 52 kennzeichnet eine Funktionalspezifikation basierend auf natürlicher Sprache.
Bezugszeichen 53 kennzeichnet ein Verbinden von Fahrszenarien.
Bezugszeichen 54 kennzeichnet ein Fahrzeugverhalten, insbesondere Lastkraftwagenverhalten, in einer virtuellen Umgebung.
Bezugszeichen 55 kennzeichnet Werte zum Beeinflussen der Fahrzeugdynamik 12.
Bezugszeichen 16 kennzeichnet auch hier die konkreten Szenarien, insbesondere Fahrszenarien.
Bezugszeichen 14 kennzeichnet auch hier die funktionalen Szenarien, insbesondere Fahrszenarien.
Bezugszeichen 15 kennzeichnet auch hier die logischen Szenarien, insbesondere Fahrszenarien.
Bezugszeichenliste

1: natürliches Fahrszenario
2: Fahrzeug
3: Spurhalteassistenzsystem
4: synthetisches Fahrszenario
5: Kamera-Box
6, 7: Ereignis
8: Kritikalitätsanalyse
9: adaptive Testabdeckung
10: Zergliedern von worst-case-Szenarien
11: Testautomation
12: Fahrzeugdynamik
13: Anwendungsfall
14: funktionales Szenario
15: logisches Szenario
16: konkretes Szenario
17: Situation
18: Szene
19: Fahrer
20: Aktion
21: Sensor
22: Fahrfunktion
23: Aktor
24: statische und dynamische Elemente
25: Ziele und Werte
26: ereignisbasiertes Data-Mining
27: ontologiebasierte Szenariosynthese
28: systematische Testfallgenerierung
29: generisches Modell für eine Szenariobeschreibung
30: funktionale Spezifikation
31: Testfall
32: Spitzenanforderung
33: Testausführung
34: Cluster-in-the-Loop Plattform
35: Änderung ausgewählter Parameter
36: Testresultat
37: Testauswertung
38: Auswertung der Testfälle
39: datenbasiertes Ausdauertesten
40: wissensbasiertes Testen
41: datenbasiertes Clustertesten
42: wissensbasiertes Clustertesten
43: Fahrzeugdynamikmodell
44: Steuergerätplattform
45: Aktormodell
46: ausgelöstes Ereignis
47: Datenbank
48: Data-Mining und Analyse
49: Auswahl von Fahrfällen
50: semantikbasierte Funktionalspezifikation
51: Fahrfall
52: Funktionalspezifikation basierend auf natürlicher Sprache
53: Verbinden von Fahrszenarien
54: Fahrzeugverhalten in virtueller Umgebung
55: Werte zum Beeinflussen der Fahrzeugdynamik
b: Abstand
c: Abstand
C0: Cluster
C1: Cluster
C2: Cluster
d: Abstand
e: Abstand
CLT: closed-loop-testing
d_LC: Distanz bis zum Überfahren der Fahrspurmarkierung
f: Distanz zwischen Vorderrad und Fahrspurgrenze
I: Index
K1: erste prinzipielle Komponentenanalyse
K2: zweite prinzipielle Komponentenanalyse
Is: linke Seite
OLT: open-loop-testing
p: Fahrspurverlassenspunkt
r_ego: Radius
r_road: Radius
rs: rechte Seite
S0: Signalpprototyp
S1: Signalpprototyp
S2: Signalpprototyp
t: Zeit
UT: Unit Testing
v_längs: Längsgeschwindigkeit des Egofahrzeugs
v_lat: Lateralgeschwindigkeit des Egofahrzeugs
ZV: Zeitverlauf
α: Winkel
β: Winkel
γ: Winkel
δ: Winkel
ε: Winkel
(x,y)_ego: Zentrumpunkt
(x,y)_road: Straßenkurvenzentrumpunkt

Claims

Verfahren zum Testen eines Spurhalteassistenzsystems (3) für ein Fahrzeug (2), insbesondere für einen Lastkraftwagen, dadurch gekennzeichnet, dass ontologiebasiert eine Kategorie adäquater und relevanter Szenarien für existierende Feldtests extrahiert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass worst-case-Szenarien mittels Data-Mining extrahiert und in Anforderungen für eine Testabdeckung transformiert werden.