DE102016220913A1

DE102016220913A1 - Verfahren und Vorrichtung zur Generierung von Testfällen für autonome Fahrzeuge

Info

Publication number: DE102016220913A1
Application number: DE102016220913.2A
Authority: DE
Inventors: Frederic Stefan; Marie Roger Alain Chevalier; Michael Marbaix; Evangelos BITSANIS
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-11-06
Filing date: 2016-10-25
Publication date: 2017-05-11
Also published as: US20170132117A1; CN107015483A; US10255168B2

Abstract

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Generierung von Testfällen für autonome Fahrzeuge. Gemäß der Erfindung werden die Testfälle unter Verwendung von Daten, die von am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelt worden sind (1), automatisch generiert (9). Hierzu werden die von den am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelten Daten analysiert, um repräsentative Fahrsituationen zu identifizieren (4). Zusätzlich werden dedizierte, auf der realen Welt basierende Testfälle gewonnen, wobei zwischen Anwendungsfällen, die auf Testfällen basieren, und den durch Analyse von Daten aus der realen Welt identifizierten Anwendungsfällen eine Vergleichsanalyse (6) durchgeführt wird. Bei Detektion von vergleichbaren Fällen werden diese zu einem Fall verschmolzen, wobei bei der Verschmelzung der auf Testfällen basierende Fall beibehalten wird und bei Vorhandensein von Abweichungen auf Basis eines auf Daten aus der realen Welt identifizierten Anwendungsfalls modifiziert wird.

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Generierung von Testfällen für autonome Fahrzeuge gemäß den Oberbegriffen der Patentansprüche 1 und 8.
Für Software-Verifikation und -Validierung auf Systemebene spezifiziert man traditionell einen Satz von Stimuli und erwarteten Reaktionen des Systems. Die Stimuli und erwarteten Reaktionen werden direkt aus entsprechenden Anforderungen abgeleitet. Der Umfang dieser Anforderungen und daher auch der Umfang der Testfälle sind im Allgemeinen auf einen endlichen Satz von identifizierten Anwendungsfällen beschränkt. Typischerweise werden die Testfälle von Testingenieuren unter Verwendung von Software-Testwerkzeugen spezifiziert. Solche Werkzeuge können Funktionen zur Unterstützung von Testautomatisierung und zur Vergrößerung der Test-Maturität aufweisen (Versions-Management, Ausgabe-Tracker, grafische Testspezifikation usw.).
Es gibt auch formale Verifikationsmethoden für systematischere Überprüfungen, dass Software-Implementierungen bestimmte Regeln nicht verletzen.
Das Testen von Software für autonome Fahrzeuge auf Systemebene bringt die neue Herausforderung mit sich, dass der zu einem solchen System gehörende Satz von Anwendungsfällen beinahe unendlich ist. Tatsächlich muss so ein System im Stande sein, die meisten Fahrsituationen zu bewältigen, denen irgendein Fahrer in seinem Leben möglicherweise begegnet. Verschiedene Fahrer werden verschiedenen Arten von Anwendungsfällen gegenüber stehen, abhängig von einer großen Zahl von Umfeldfaktoren (andere Verkehrsteilnehmer, Tageszeit, Wetter, Gesundheit, Fahrzeugverschleiß, Straßenzustand usw.). Daher scheint es eine extrem hohe Zahl von Testkombinationen zu geben.
Virtuelle Testumfelder für autonome Fahrzeuge sind bekannt. So beschreibt die Publikation Bock T., Maurer M., van Meel F., Müller T., "Vehicle in the Loop, Ein innovativer Ansatz zur Kopplung virtueller mit realer Erprobung" in ATZ 01/2008 Jahrgang 110, S. 2–8,, ein Test- und Simulationsumfeld für Fahrerassistenzsysteme, in dem ein reales Versuchsfahrzeug, das sich nicht im öffentlichen Straßenverkehr, sondern auf einer Freifläche oder einem Erprobungsgelände bewegt, mit einem Fahrsimulator kombiniert wird. Mit einem derartigen, "Vehicle in the Loop" genannten Prüfaufbau kann gefahrlos getestet werden, wie Fahrerassistenzfunktionen auf virtuellen Fremdverkehr oder sonstige virtuelle Objekte in einem virtuellen Verkehrsumfeld reagieren.
Die Publikation "Towards a Hybrid Real/Virtual Simulation von Autonomous Vehicles for Critical Scenarios", SIMUL 2014, ISBN 978 1 61208 371 1, S. 14–17, beschreibt gemischt reale/virtuelle Simulationen von autonomen Fahrzeugen für kritische Situationen, und zwar mit virtuellen Sensoren und einem realen Fahrzeug als "Hardware in the simulation loop".
Aus der DE 10 2007 053 500 A1 ist es bekannt, ein vorausschauendes Sicherheitssystem zur Unfallverhütung/Unfallfolgenbegrenzung bei einem fahrergeführten Kraftfahrzeug anhand von gespeicherten Realwelt-Unfallereignissen zu bewerten, wobei dabei zusätzlich Simulationsrechnungen berücksichtigt werden können, wobei jedoch offen bleibt, wie Realwelt- und Simulationsdaten sinnvoll miteinander kombiniert werden sollen.
Aus der DE 10 2008 027 526 A1 ist ein Verfahren zur prognostischen Bewertung eines vorausschauenden Sicherheitssystems bei fahrergeführten Kraftfahrzeugen bekannt, bei dem Realunfalldaten statistisch ausgewertet und mit berechneten Prognoseparametern verglichen werden, woraus dann eine Nutzenbewertung des Sicherheitssystems gewonnen werden soll. Das bekannte Verfahren ist jedoch nicht zur Generierung eines möglichst optimalen Satzes von Testfällen ausgelegt.
Es besteht somit Bedarf an verbesserten Werkzeugen und Verfahren, die Testfälle für autonome Fahrzeuge effizienter generieren können.
Der Erfindung liegt die Aufgabe zu Grunde, eine automatische Generierung von Testfällen für autonome Fahrzeuge auf Systemebene zu ermöglichen, bei der Realwelt- und vordefinierte Anwendungsfälle derart kombiniert werden, dass der Betrieb von autonomen Fahrzeugen möglichst erschöpfend und realistisch, aber andererseits mit einer möglichst geringen Anzahl von Testfällen, verifiziert werden kann.
Diese Aufgabe wird durch ein Verfahren und eine Vorrichtung mit den Merkmalen der Patentansprüche 1 und 8 gelöst.
Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Das erfindungsgemäße Verfahren macht von bis zu drei Arten von Eingangsgrößen Gebrauch: reales Fahrerleben von Fahrern (Massendaten); für autonome Fahrzeuge definierte Anwendungsfälle; und spezielle Anwendungsfälle, die von Sicherheits- und Zuverlässigkeitsprozessen möglicherweise verlangt werden.
Ein generierter Testfall kann ein Platzhalter sein, d. h., das System generiert einen Testfall-Titel und eine kurze Erläuterung in höherer Programmiersprache, was getestet werden soll. Insbesondere kann ein Testfall direkt eine Beschreibung in höherer Programmiersprache und formale Testanweisungen, die von einer Maschine interpretiert werden können, sein.
Damit kann auf die neuen Herausforderungen an Softwaretests für die aufkommenden autonomen Fahrzeuge reagiert werden, indem eine automatisierte Plattform für die effiziente Identifizierung von geeigneten Testfällen auf Systemebene bereitgestellt wird.
Das erfindungsgemäße Verfahren basiert auf der Analyse von mindestens einer Datenquelle von realem Fahrerleben als Eingangsgröße und auch vordefinierten System-Anwendungsfällen und vorzugsweise von sicherheits- und zuverlässigkeitsbezogenen System-Anwendungsfällen als weitere Eingangsgrößen.
Das reale Fahrerleben ist das gesammelte Erleben der Fahrer einer Vielzahl von Fahrzeugen einer Flotte von Fahrzeugen über längere Zeitspannen in der realen Welt. Die Fahrer sind z. B. alle, die ein Fahrzeug einer bestimmten Marke oder eines bestimmten Typs fahren. Es werden Massendaten wie z. B. CAN-Bus-Daten, Sensordaten, Fahrzeugkommunikationsdaten usw. gesammelt. All diese Daten werden analysiert und klassifiziert, um Fahrsituationen zu identifizieren und eine Sammlung von Fahrsituationen zusammen mit deren Häufigkeit aufzustellen. Fahrsituationen lassen sich nach unterschiedlichen Methoden klassifizieren. Zum Beispiel kann ein Katalog eine grobe Indikation geben, welche Arten von Situationen relevant sind, z. B. Stillstände, Beschleunigungen, Notbremsungen, Motorstarts usw. Oder ein Klassifizierungsalgorithmus kann Gruppen von Fahrsituationen hinsichtlich unterschiedlicher Merkmale wie z. B. Fahrzeuggeschwindigkeit, Motordrehzahl, Pedalgebrauch usw. aufstellen.
Auf Basis der solchermaßen identifizierten Fahrsituationen werden Testfälle generiert, die hier Testfälle aus der realen Welt genannt werden. Auch die verschiedenen Schritte, die zu einer bestimmten Fahrsituation führen, und die durchschnittliche Reaktion der Fahrer können analysiert werden. Diese Informationen bilden dann die Basis zum Generieren von Testfall-Schritten und Akzeptanzkriterien. Ein Beispiel für einen repräsentativen Testfall, der identifiziert werden kann, ist das sanfte Verlangsamen und Anhalten eines Fahrzeugs an einer Verkehrsampel. Das Identifizieren von Fahrsituationen und das Generieren von Testfällen können typischerweise mit Hilfe von Massendaten und Prädiktionsanalysen durchgeführt werden.
Bei modellbasiertem Systementwurf ist es allgemeine Praxis, System-Anwendungsfälle zu definieren, welche die Interaktion zwischen dem Fahrzeug, dem Fahrer und dem Umfeld repräsentieren. Solche Anwendungsfälle können in einer Textform oder mittels Modelliersprachen wie z. B. UML oder SysML beschrieben werden. Tatsächlich kann ein Anwendungsfall sehr leicht als ein Testfall betrachtet werden. Vorliegend wird jedoch eine Vergleichsanalyse zwischen Anwendungsfällen, die auf Testfällen basieren, und den durch Analyse von Daten aus der realen Welt identifizierten Anwendungsfällen durchgeführt, wobei bei Detektion von vergleichbaren Fällen diese zu einem Fall verschmolzen werden. Dabei kann dieses Verschmelzen, das auch als Vereinigungsoperation in einer Gruppentheorie dargestellt werden kann, gemäß verschiedenen Konventionen erfolgen. Beispielsweise kann jeweils dem "theoretischen" Fall, d.h. dem aus vordefinierten Anwendungsfällen oder sicherheits- und zuverlässigkeitsbezogenen Anwendungsfällen gewonnenen Fällen der Vorrang eingeräumt werden und gleichartige "Realweltfälle" können gelöscht werden.
Bei der Verschmelzung werden besonders bevorzugt Aspekte aus beiden Fallarten berücksichtigt. Beispielsweise kann der vordefinierte Anwendungsfall als Rahmen für die Falldefinition verwendet werden und um Details aus dem "Realweltfall" ergänzt werden, z.B. ein real gemessenes Geschwindigkeitsprofil. Damit wird bei der Verschmelzung der auf Testfällen basierende Fall beibehalten, der allerdings ggf. – d.h. bei Vorhandensein von Abweichungen – auf Basis eines auf Daten aus der realen Welt identifizierten Anwendungsfalls modifiziert wird.
Spezielle Anwendungsfälle, die Sicherheitsprozessen wie z. B. ISO 26262 oder Zuverlässigkeitsprozessen wie z. B. FMEA gewidmet sind, müssen ebenfalls behalten werden. Falls Sicherheits-/Zuverlässigkeits-Testfälle schon durch irgendwelche Testfälle aus der realen Welt abgedeckt werden, können sie bei dem Verfahren entsprechend markiert werden, da derartige Testfälle möglicherweise andere Testmethoden erfordern, z. B. formales Testen.
Bei einer erfindungsgemäßen Vorrichtung zur Generierung von Testfällen für autonome Fahrzeuge sind wenigstens folgende logische Blöcke vorgesehen: Ein zentraler Datenbankblock, der kontinuierlich die von realen Fahrzeugen in der realen Welt erhaltene und gesammelte Daten enthält, ein Anwendungsfallblock, in dem System-Anwendungsfälle für autonome Fahrzeuge definiert und bereitgestellt werden, ein Identifikationsblock, mittels dessen repräsentative Testfälle aus der realen Welt anhand von typischen Fahrsituationen, anhand von System-Anwendungsfällen und/oder anhand von sicherheits- und zuverlässigkeitsbezogen System-Anwendungsfällen identifiziert werden, ein Testfallspeicherblock, in dem die in dem Identifikationsblock identifizierten Testfälle gespeichert werden, ein Vergleichsanalyseblock, im dem die in dem Testfallspeicherblock gespeicherten Testfälle aus der realen Welt und die im Anwendungsfallblock erhaltenen anwendungsfallbasierten Testfälle abgeglichen werden, wobei Duplikate anhand vorgegebener Vorrangregeln zu einem einzigen Testfall verschmolzen werden, so dass ein erweiterter Satz von Testfällen gewonnen wird.
Bevorzugt werden zusätzlich in einem Block sicherheits- und zuverlässigkeitsbezogene System-Anwendungsfälle für autonome Fahrzeuge bzw. für einen bestimmten derartigen Fahrzeugtyp definiert, wobei ein weiterer Vergleichsanalyseblock vorgesehen ist, in dem eine Vergleichsanalyse durchgeführt, um den im Vergleichsdatenblock erhaltenen erweiterten Satz von Testfällen mit im vorgenannten Block erhaltenen sicherheits- und zuverlässigkeitsbezogenen System-Anwendungsfällen abgeglichen werden.
Es folgt eine Beschreibung eines Ausführungsbeispiels anhand der Zeichnung. Deren einzige Figur zeigt einen Überblick über ein System zur automatischen Generierung von Testfällen für autonome Fahrzeuge auf Systemebene.
Unter Bezugnahme auf die Figur werden in einem Block 1, der eine zentrale Datenbank umfasst, kontinuierlich Daten gesammelt, die von realen Fahrzeugen in der realen Welt erhalten werden, insbesondere von am normalen öffentlichen Straßenverkehr teilnehmenden Fahrzeugen, die nicht autonom sein oder autonom gesteuert werden müssen, sondern von menschlichen Fahrern gesteuert werden können.
In einem Block 2 werden System-Anwendungsfälle für autonome Fahrzeuge bzw. für einen bestimmten derartigen Fahrzeugtyp definiert.
In einem Block 3 werden sicherheits- und zuverlässigkeitsbezogene System-Anwendungsfälle für autonome Fahrzeuge bzw. für einen bestimmten derartigen Fahrzeugtyp definiert.
In einem Block 4 anhand Massendaten erhoben und Prädiktionsanalysen durchgeführt, um repräsentative Testfälle aus der realen Welt zu identifizieren. Dazu kann z.B. ein Mustererkennungsalgorithmus verwendet werden, in den ein Referenzkatalog von typischen Fahrsituationen, die System-Anwendungsfälle und/oder die sicherheits- und zuverlässigkeitsbezogen System-Anwendungsfälle eingegeben werden. Die repräsentativen Testfälle werden sodann (strukturiert nach dem jeweiligen Kriterium) in einem Block 5 abgespeichert.
In einem Block 6 wird eine Vergleichsanalyse durchgeführt, um die in einem Block 5 erhaltenen Testfälle aus der realen Welt und die im Block 2 erhaltenen anwendungsfallbasierten Testfälle abzugleichen, wobei "Duplikate" anhand vorgegebener Regeln zu einem einzigen Testfall verschmolzen werden. Hierzu können Vorrangregeln vorgegeben sein (z.B. Vorrang der anwendungsfallbasierten Testfälle oder der Testfälle aus der realen Welt) oder es können bestimmte Daten aus beiden Fällen kombiniert werden. Dieser Schritt fusioniert die Inhalte der Blöcke 2 und 5, um einen erweiterten Satz von Testfällen aufzustellen.
In einem Block 7 wird eine Vergleichsanalyse durchgeführt, um den im Block 6 erhaltenen erweiterten Satz von Testfällen mit den im Block 3 erhaltenen sicherheits- und zuverlässigkeitsbezogenen System-Anwendungsfällen abzugleichen. Auch hier können Duplikate nach vorgegebenen Regeln zu einem Datensatz fusioniert werden. Dieser Schritt fusioniert die Inhalte der Blöcke 6 und 3 und liefert einen vollständigeren Satz von Testfällen für autonome Fahrzeuge.
Optional werden in einem Block 8 auf Basis der im Block 1 erhaltenen Daten aus der realen Welt Testschrittanweisungen und Akzeptanzen für jeden Testfall generiert.
Der Block 9 stellt ein zentrales Testplanungssystem dar. Dieses Testplanungssystem kann durch ein Werkzeug für Projektlebenszyklusmanagement und/oder Anwendungslebenszyklusmanagement gesteuert werden, um die für autonome Fahrzeuge geeigneten Testfälle zu generieren und abzufragen. Das zentrale Testplanungssystem kann mit Regeln für kontinuierliche Integration versehen sein, um die Testfälle aus der realen Welt regelmäßig zu aktualisieren, nämlich durch regelmäßiges Starten des Blocks 4. Dies erlaubt es, automatisch neue Testfälle zu generieren, die nur sehr selten auftreten oder die nur in ganz speziellen Situationen erkennbar werden.
Der Block 10 stellt den im Block 9 erhaltenen vollständigen Satz von Testfällen für autonome Fahrzeuge dar, der von Testingenieuren, für Testdokumentation und/oder für Testdurchführung verwendet werden kann, entweder manuell oder automatisch.
Das Arbeitsprinzip des oben beschriebenen Systems zur automatischen Generierung von Testfällen für autonome Fahrzeuge auf Systemebene wird nun anhand eines einfachen Beispiels unter Bezugnahme auf die Figur näher erläutert.
In diesem Beispiel soll ein Testingenieur Tests eines autonomen Fahrzeugs so auslegen, dass dessen Software das Fahrzeug im Stadtverkehr bis zum Stillstand verzögern lässt, wenn dies verlangt wird. Dies kann in sehr vielen möglichen Situationen geschehen. Für diese Aufgabe möchte der Testingenieur in Erfahrung bringen, welches Testszenario zu definieren ist, um einen repräsentativen Satz von Testfällen zu erreichen.
Der Testingenieur hat im Block 2 das folgende Testszenario vordefiniert und in den Block 9 eingegeben:

– Teste, dass das Fahrzeug bis zum Stillstand verzögert, wenn es sich einem stehenden Fahrzeug oder einer stehenden Fahrzeugschlange nähert
– Teste, dass das Fahrzeug bis zum Stillstand verzögert, wenn es sich einem Fußgängerübergang mit einem die Straße überquerenden Fußgänger nähert
– Teste, dass das Fahrzeug bis zum Stillstand verzögert, wenn es sich einem Stoppschild nähert

Mit dem Block 1 steht eine zentrale Datenbank zur Verfügung, die Aufzeichnungen der Fahrten von Fahrzeugen in der realen Welt enthält, die mehrere Jahre lang gemacht worden sind. Es stehen Daten zu mehrerlei Fahrzeugtypen, mehrerlei Fahrzeugumfeldern u. dgl. zur Verfügung. Man beachte, dass die Daten nicht notwendigerweise an autonomen Fahrzeugen, sondern wahrscheinlich an konventionellen, von menschlichen Fahrern gesteuerten Fahrzeugen aufgezeichnet worden sind. Diese Datenbank wächst ständig und zeichnet ständig Daten auf, doch sei hier angenommen, dass sie einen eingefrorenen und repräsentativen Inhalt hat, wenn sie der Testingenieur abfragen will.
Der Testingenieur spezifiziert im zentralen Testplanungssystem (Block 9) eine Abfrage an die zentrale Datenbank. Er möchte Testfälle in der realen Welt für die Fahrsituation "im Stadtverkehr bis zum Stillstand verzögern" gewinnen. Das Testplanungssystem analysiert die in der Datenbank vorhandenen Daten, wobei es von speziellen Analysealgorithmen im Block 4 Gebrauch macht, um die Daten zu klassifizieren, und liefert eine Liste von identifizierten Testfällen im Block 5 wie folgt, wobei die jeweiligen Häufigkeiten in Prozent angegeben sind:

a) Fahrzeug verzögert bis zum Stillstand wegen eines erkannten Hindernisses (Abstand zu stehendem Hindernis ist unter einem Schwellenwert): 30 %
b) Fahrzeug verzögert bis zum Stillstand wegen einer roten Verkehrsampel: 30 %
c) Fahrzeug verzögert bis zum Stillstand wegen eines Stoppschildes: 10 %
d) Fahrzeug verzögert bis zum Stillstand wegen eines Fußgängers (unter der Voraussetzung, dass automatische Fußgängererkennung möglich ist): 10 %
e) Fahrzeug verzögert bis zum Stillstand, wenn es sich einer Zapfsäule nähert: 8 %
f) Fahrzeug verzögert bis zum Stillstand, wenn von einem Polizeibeamten verlangt: 5 %
g) Fahrzeug verzögert bis zum Stillstand, wenn es sich einem Bahnübergang mit geschlossenen Schranken nähert: 4 %
h) Fahrzeug verzögert bis zum Stillstand, wenn es in ein Drive-In-Restaurant od. dgl. einfährt: 3 %

Im nächsten Schritt wird im Block 6 eine Vergleichsanalyse durchgeführt, d. h., eine Abbildung zwischen den Testfällen aus der realen Welt (Block 5) und den im Block 2 vom Testingenieur definierten anwendungsfallbasierten Testfällen. In dem obigen Beispiel können die Testfälle a) bis d) auf die vom Testingenieur definierten Testfälle abgebildet werden. Die Testfälle e) bis h) sind am Ende der Vergleichsanalyse im Block 6 vom Block 9 auf Basis von Daten der realen Welt als zusätzliche Testszenarien identifiziert worden.
Von jetzt an hat der Testingenieur die Möglichkeit, auf Basis der Daten aus der realen Welt Testschrittanweisungen zu generieren (Block 8), d. h., die Testszenarien zu verbessern. Im Falle, das sich einer der vom Testingenieur definierten Testfälle mit einem Testfall aus der realen Welt überschneidet, kann der vom Testingenieur definierte Testfall unter Verwendung des Testszenarios aus der realen Welt verbessert werden. Zum Beispiel könnten neue Testschritte, neue Abfolgen von Schritten, neue alternative Ereignisflüsse usw. hinzugefügt werden.
Am Ende des Prozesses erhält der Testingenieur schließlich einen Satz von Fahrzeug-Testszenarien (Block 10), die durch die vom Testingenieur definierten Testfälle (Block 2) und durch zusätzliche Testszenarien aus der realen Welt (Block 6) gebildet werden. Der Testingenieur kann die zu testende Software für autonome Fahrzeugen jetzt mit einem Satz von repräsentativen und realistischeren Tests testen. Die im Block 10 erhaltenen Testfälle können entweder eine Beschreibung in höherer Programmiersprache sein oder können eine detaillierte Abfolge von Aktionen und Reaktionen sein, je nach den Erfordernissen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102007053500 A1 [0007]
DE 102008027526 A1 [0008]

Zitierte Nicht-Patentliteratur

Publikation Bock T., Maurer M., van Meel F., Müller T., "Vehicle in the Loop, Ein innovativer Ansatz zur Kopplung virtueller mit realer Erprobung" in ATZ 01/2008 Jahrgang 110, S. 2–8 [0005]
Publikation "Towards a Hybrid Real/Virtual Simulation von Autonomous Vehicles for Critical Scenarios", SIMUL 2014, ISBN 978 1 61208 371 1, S. 14–17 [0006]
ISO 26262 [0021]

Claims

Verfahren zur Generierung von Testfällen für autonome Fahrzeuge, dadurch gekennzeichnet, dass die Testfälle unter Verwendung von Daten, die von am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelt worden sind (1), automatisch generiert werden (9), und dass die automatische Generierung von Testfällen auch unter Verwendung von vordefinierten Anwendungsfällen (2) durchgeführt wird, wobei die von den am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelten Daten analysiert werden, um repräsentative Fahrsituationen zu identifizieren (4), wobei dedizierte, auf der realen Welt basierende Testfälle gewonnen werden, und wobei zwischen Anwendungsfällen, die auf Testfällen basieren, und den durch Analyse von Daten aus der realen Welt identifizierten Anwendungsfällen eine Vergleichsanalyse (6) durchgeführt wird, und dass bei Detektion von vergleichbaren Fällen diese zu einem Fall verschmolzen werden, wobei bei der Verschmelzung der auf Testfällen basierende Fall beibehalten wird und bei Vorhandensein von Abweichungen auf Basis eines auf Daten aus der realen Welt identifizierten Anwendungsfalls modifiziert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die automatische Generierung von Testfällen auch unter Verwendung von sicherheits- und zuverlässigkeitsbezogenen Anwendungsfällen (3) durchgeführt wird, welche mit den bis dahin identifizierten Testfällen abgeglichen werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Daten, die von den am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelt worden sind, reales Fahrerleben von Fahrern der Fahrzeuge repräsentieren.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die von den am öffentlichen Straßenverkehr teilnehmenden Fahrzeugen gesammelten Daten analysiert werden, um Durchschnitts-Testschritte und Akzeptanzkriterien für alle auf der realen Welt basierenden Testfälle zu identifizieren.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Testfälle auf Systemebene automatisch gewonnen und zu Zwecken der Testdokumentation und Testdurchführung gespeichert werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Regeln für kontinuierliche Integration angewendet werden, um die Testfälle aus der realen Welt zu aktualisieren, und dass ein Signal ausgegeben wird, wenn neue derartige Testfälle identifiziert werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt, die bei Fahrzeugen gesammelten Daten zu analysieren, um repräsentative Fahrsituationen zu identifizieren (6), das Klassifizieren der identifizierten Fahrsituationen nach ihrer Häufigkeit umfasst.
Vorrichtung zur Generierung von Testfällen für autonome Fahrzeuge, dadurch gekennzeichnet, dass die Vorrichtung folgende logische Blöcke aufweist: einen zentralen Datenbankblock (1), der kontinuierlich die von realen Fahrzeugen in der realen Welt erhaltene und gesammelte Daten enthält, einen Anwendungsfallblock (2), in dem System-Anwendungsfälle für autonome Fahrzeuge definiert und bereitgestellt werden, einen Identifikationsblock (4), mittels dessen repräsentative Testfälle aus der realen Welt anhand von typischen Fahrsituationen, anhand von System-Anwendungsfällen und/oder anhand von sicherheits- und zuverlässigkeitsbezogen System-Anwendungsfällen identifiziert werden, einem Testfallspeicherblock (5), in dem die in dem Identifikationsblock (4) identifizierten Testfälle gespeichert werden, einem Vergleichsanalyseblock (6), im dem die in dem Testfallspeicherblock (5) gespeicherten Testfälle aus der realen Welt und die im Anwendungsfallblock (2) erhaltenen anwendungsfallbasierten Testfälle abgeglichen werden, wobei Duplikate anhand vorgegebener Vorrangregeln zu einem einzigen Testfall verschmolzen werden, so dass ein erweiterter Satz von Testfällen gewonnen wird, wobei die Vorrichtung zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche ausgebildet ist.
Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, dass zusätzlich in einem Block (3) sicherheits- und zuverlässigkeitsbezogene System-Anwendungsfälle für autonome Fahrzeuge bzw. für einen bestimmten derartigen Fahrzeugtyp definiert werden, und dass ein weiterer Vergleichsanalyseblock (7) vorgesehen ist, in dem eine Vergleichsanalyse durchgeführt, um den im Vergleichsdatenblock (6) erhaltenen erweiterten Satz von Testfällen mit im vorgenannten Block (3) erhaltenen sicherheits- und zuverlässigkeitsbezogenen System-Anwendungsfällen abgeglichen werden.