DE102021202332A1

DE102021202332A1 - Identifizierung von corner cases von betriebsszenarien

Info

Publication number: DE102021202332A1
Application number: DE102021202332.0A
Authority: DE
Inventors: Maria Belen Bescos Del Castillo; Paul Ruhnau; Indrasen Raghupatruni; Antonia Reiter
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-03-10
Filing date: 2021-03-10
Publication date: 2022-09-15
Also published as: CN115131751A; US20220292894A1

Abstract

Ein Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Identifizierung von Corner Cases von Betriebsszenarien von Fahrzeugen, umfassend Empfangen eines oder mehrerer Merkmale zur Charakterisierung eines Betriebszustands eines Fahrzeugs, Extrahieren mindestens eines Spurgraphen zu dem einen oder den mehreren Merkmalen aus einer Graphendatenbank, Modifizieren des mindestens einen Spurgraphen, wobei ein modifizierter Spurgraph erzeugt wird, Rekonstruieren eines ersten Betriebsszenarios aus dem Spurgraphen, Rekonstruieren eines zweiten Betriebsszenarios aus dem modifizierten Spurgraphen, und Identifizieren des zweiten Betriebsszenarios als Corner Case, wenn das zweite Betriebsszenario im Vergleich zum ersten Betriebsszenario auf Basis eines vorbestimmten Kriteriums als neu und/oder unbekannt bewertet wird.

Description

Stand der Technik
Unter einem Corner Case (deutsch: Eckfall) kann eine Situation im Betrieb eines technischen Systems verstanden werden, die bezüglich der die Situation beschreibenden Parameter in einem nicht-normalen und/oder unüblichen Parameterbereich liegt. Solche Parameter können z.B. Betriebsparameter und/oder Umgebungsvariablen des technischen Systems sein. Insbesondere kann (in Abgrenzung zum Edge Case oder auf deutsch Kantenfall) ein Corner Case dann vorliegen, wenn mehrere solche Parameter gleichzeitig nicht-normal und/oder unüblich sind, obwohl sie jeweils in einem spezifizierten Bereich liegen. Während hypothetische Corner Cases sich (im Statischen) bereits aus der Spezifikation von Parametern - d.h. deren Parameterbereichen - ergeben können, geht es bei der Identifizierung von Corner Cases üblicherweise darum, die im Betrieb (und in der Dynamik) tatsächlich auftretenden Corner Cases zu ermitteln. Corner Cases können beispielsweise auf Basis von bekannten Methoden wie search-based testing und/oder boundary parameter testing (die gebräuchlichen englischen Begriffe werden verwendet) erkannt und/oder erzeugt werden.
Bei der Entwicklung eines Fahrzeugs, insbesondere eines Fahrzeugs zum assistierten und/oder (teil)autonomen Fahren, kann die Situation eines Corner Case als Betriebs- und/oder Fahrszenario verstanden werden, welches beispielsweise durch einen oder mehrere Zeitschriebe (z.B. Geschwindigkeit, Lenkwinkel, etc.) über einen gewissen Zeitraum beschrieben wird. Die jeweiligen y-Werte des einen oder der mehreren Zeitschriebe können als Parameter gesehen werden und/oder aus diesen y-Werten können Parameter abgeleitet werden.
Um einen verlässlichen und sicheren Betrieb eines Fahrzeugs, insbesondere eines (teil)autonomen Fahrzeugs, zu erreichen, können Methoden zur Verifikation und Validierung in den Produktentwicklungszyklen zum Einsatz kommen. Dem Erkennen und Erproben von Corner Cases in Fahrzeugtestdaten, insbesondere in Felddaten, kommt dabei eine besondere Bedeutung zu.
Im beispielhaften Falle eines Antriebsstranges mit Doppelkupplung und einem dazugehörigen Doppelnehmerkolben für die Aktuierung der Doppelkupplung kann z.B. ein Corner Case in einer hohen Summendruckbelastung des Doppelnehmerkolbens gesehen werden. Hier könnte z.B. jede der beiden hydraulischen Kammern des Doppelnehmerkolbens auf einen Betriebsdruck von 40 bar ausgelegt sein. Da in einem üblichen Antriebsstrang (zur Vermeidung einer Getriebeblockade) nicht beide Kupplungen der Doppelkupplung gleichzeitig (vollständig) geschlossen sind, kann eine Summendruckbelastung von 80 bar als unrealistisch bewertet werden. Andererseits können sehr wohl z.B. bei Überschneidungsschaltungen, in denen die bisher geschlossene Kupplung der Doppelkupplung geöffnet und die bisher offene Kupplung geschlossen wird, Summendrücke z.B. in Höhe von 60 bar am Doppelnehmerkolben entstehen. Solche Summendrücke können z.B. von der Schaltdynamik und/oder der Fahrweise abhängen und können in der Regel nur mit Aufwand im Vorfeld berechnet/simuliert werden. Andererseits können sie einfach aus Felddaten ermittelt werden. In jedem Fall können (und sollen) Summendruck Corner Cases in der Auslegung (hier z.B. bei der Dimensionierung der Wandstärken des Doppelnehmerkolbens) berücksichtigt werden.
Im Kontext des assistierten und/oder zumindest teilautonomen Fahrens kann eine wichtige Klasse von Corner Cases durch eine (zufällige) Kombination von Umgebungsbedingungen gebildet werden. Hier können z.B. Parameter aus den Zeitschrieben, insbesondere den Sensordaten aus mindestens einem bildgebenden System, abgeleitet werden, um Corner Cases zu definieren. Beispielsweise können Parameter für die Stärke des Gegenlichts, ein oder mehrere Winkel des Gegenlichts und ein Maß für die Nässe der Fahrbahn aus Kameradaten abgeleitet werden. In diesem Fall kann z.B. ein Corner Case aus starkem Gegenlicht und nasser Fahrbahn zu Spiegelungen führen, die zu einer falschen Bewertung der Fahrsituation und im schlimmsten Fall zu einem ungeeigneten Fahrmanöver führen.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Identifizierung von Corner Cases von Betriebsszenarien von Fahrzeugen, umfassend Empfangen eines oder mehrerer Merkmale zur Charakterisierung eines Betriebszustands eines Fahrzeugs, Extrahieren mindestens eines Spurgraphen zu dem einen oder den mehreren Merkmalen aus einer Graphendatenbank, Modifizieren des mindestens einen Spurgraphen, wobei ein modifizierter Spurgraph erzeugt wird, Rekonstruieren eines ersten Betriebsszenarios aus dem Spurgraphen, Rekonstruieren eines zweiten Betriebsszenarios aus dem modifizierten Spurgraphen, und Identifizieren des zweiten Betriebsszenarios als Corner Case, wenn das zweite Betriebsszenario im Vergleich zum ersten Betriebsszenario auf Basis eines vorbestimmten Kriteriums als neu und/oder unbekannt bewertet wird.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-lesbares Medium oder Signal, das das Computer-Programm nach dem zweiten allgemeinen Aspekt speichert und/oder enthält.
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computersystem, das dafür ausgelegt ist, das Computer-Programm nach dem zweiten allgemeinen Aspekt auszuführen.
Corner Cases, die im Betrieb und insbesondere während der Fahrt eines Fahrzeugs, insbesondere eines Fahrzeugs zum assistierten und/oder (teil)autonomen Fahren, auftreten können, sind wichtige (Grenz-)Fälle, die in der entwicklungs- und/oder serienbegleitenden Auslegung und Erprobung des Fahrzeugs berücksichtigt werden können (und sollen), um einen verlässlichen und sicheren Betrieb des Fahrzeugs zu gewährleisten. Solche Corner Cases können über einen oder mehrere Zeitschriebe, deren y-Werte Parameter sind und/oder umfassen (z.B. Betriebsparameter und/oder Umgebungsvariablen wie Fahrzeuggeschwindigkeit, Lenkungswinkel, Sensordaten eines bildgebenden Systems, Positionsdaten,...) und/oder aus denen Parameter (z.B. Stärke und Winkel des Gegenlichts, ein erkanntes Objekt,...) abgeleitet werden können, über einen bestimmten Zeitraum beschrieben werden. Der Zeitraum kann sich von wenigen Interrupts (z.B. mehr als zwei, mehr als fünf, mehr als zehn oder mehr als hundert) eines Steuergeräts (z.B. mit 100 Hz Taktung) über mehr als eine oder mehrere Sekunden, bis hin zu mehr als einer oder mehreren Minuten und/oder mehr als eine oder mehrere Stunden erstrecken (in manchen Beispielen kann der Zeitraum sich zwischen 10ms und einer Stunde erstrecken).
Zur Erkennung von Corner Cases können solche Zeitschriebe während des Betriebs und/oder während der Fahrt eines oder mehrerer Fahrzeuge erfasst werden. Allerdings entstehen dabei üblicherweise, z.B. in Abhängigkeit der Datendichte in den Zeitschrieben und je nach Flottenstärke, sehr große Datenmengen, die viel Speicherplatz (z.B. auf einem Cloud Server) beanspruchen. Alternativ oder zusätzlich kann die Auswertung solcher Datenmenge eine große Rechenzeit erfordern. Insbesondere in Fällen, in denen die Zeitschriebe nicht nur in Testphasen während der Entwicklung, sondern auch nach Verkauf und Übergabe der Fahrzeuge an Verbraucher gesammelt werden, um die Funktionalität (z.B. Computer Vision) fortlaufend über Updates verbessern zu können, kann die Flotte z.B. mehr als 1e1, mehr als 1e2, mehr als 1e3, mehr als 1e4, mehr als 1e5, mehr als 1e6, oder mehr als 1e7 Fahrzeuge umfassen.
Solche Datenmengen weisen üblicherweise eine hohe Redundanz auf. Zum einen beschreiben diese Datenmenge überwiegend normale Betriebs-/Fahrszenarien, die häufig bereits bekannt sind. In der Tat können Corner Cases unwahrscheinlich sein, insbesondere bei höher-dimensionalen Parameterräumen. Zum anderen kann jeder Zeitschrieb für sich oder im Zusammenspiel mit anderen Zeitschrieben redundante Informationen enthalten (z.B. Datenpunkte in konstanten Phasen oder Proportionalitäten zwischen Signalen wie z.B. Fahrzeuggeschwindigkeit und Drehfrequenz einer Antriebsmaschine in bestimmten Betriebs-/Fahrzuständen).
Durch Spurgraphen können das eine oder die mehreren Betriebs-/Fahrszenarien in einer aggregierten und dadurch redundanzärmeren Weise (in manchen Fällen in einer weitestgehend redundanzfreien Weise) gespeichert werden. Durch Rekonstruktion z.B. durch eine Simulation können dann aus diesen Spurgraphen wieder Betriebs-/Fahrszenarien erzeugt werden, die im Wesentlichen mit den ursprünglichen Betriebs-/Fahrszenarien übereinstimmen. In diesem Sinne können die Spurgraphen als eine reversible Komprimierung betrachtet werden. Dadurch kann der Speicherbedarf zum Speichern von Informationen zu Betriebs- und/oder Fahrszenarien gesenkt werden.
Solche Spurgraphen können zudem z.B. (in einer zwei-dimensionalen Ebene) durch Knoten und Kanten visualiert werden und ermöglichen dadurch Entwicklungs- und Testingenieuren eine zusätzliche Perspektive auf Betriebs-/Fahrszenarien jenseits von Zeitschrieben. Die Knoten können z.B. in unterschiedlicher Größe und/oder unterschiedlicher Farbe (z.B. gemäß einer heatmap) dargestellt werden. Dadurch können beispielsweise Häufigkeit und/oder Verweildauer graphisch und somit anschaulich dargestellt werden.
Die Erkennung neuer und/oder unbekannter Betriebs-/Fahrszenarien erfordert üblicherweise einen Vergleich von einem Betriebs-/Fahrszenario mit bereits vorhandenen Betriebs-/Fahrszenarien. Beispielsweise kann das zu bewertende Betriebs-/Fahrszenario mit jedem der bereits vorhandenen Betriebs-/Fahrszenarien verglichen werden, was allerdings aufgrund der großen Datenmenge eine entsprechende Rechenleistung erfordert. Eine Steigerung der Effizienz kann dagegen erreicht werden, wenn anstelle der Betriebs-/Fahrszenarien deren zugehörigen Spurgraphen verglichen werden.
In frühen Entwicklungsphasen ist häufig nur eine überschaubare Menge an Daten vorhanden. Die Kenntnis von Corner Cases für das zu entwickelnde Fahrzeug ist somit eher beschränkt. Es kann daher vorteilhaft sein neue Corner Cases durch Modifikation zu erzeugen und ggf. als neue Corner Cases zu identifizieren. Dazu können anstelle der Betriebs-/Fahrszenarien deren Spurgraphen modifiziert werden. Dadurch kann vermieden werden, dass eine Modifikation zu einem Betriebs-/Fahrszenario führt, das sich im Vergleich zu dem ursprünglichen Betriebs-/Fahrszenario z.B. nur in einer Redundanz unterscheidet. Das Verfahren des ersten allgemeinen Aspekts kann somit als generischer Corner Case Erzeuger basierend auf dem aggregierten Wissen aus Felddaten betrachtet werden. Im Gegensatz zu anderen Corner Case Erzeugern, die (nur) auf klassischen Verifikations- und Validierungsmethoden (search-based testing, boundary parameter testing) basieren, ist der vorgeschlagene generische Corner Case Erzeuger von einem Spurgraphen abhängig und somit insbesondere nicht mehr direkt von dem oder den Zeitschrieben (und deren Datenart) abhängig. Ein Vorteil davon kann darin gesehen werden, dass der mögliche kombinatorische Raum reduziert wird, weil der Spurgraph komprimiert und (weitestgehend) redundanzfrei ist.
Der Begriff „Fahrzeug“ umfasst jegliche Vorrichtungen, die Passagiere und/oder Fracht transportieren. Ein Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen Fahrzeuge sein.
Dementsprechend umfasst der Begriff „zumindest teilautonom operierendes Fahrzeug“ jegliche Vorrichtungen, die in zumindest teilautonomer Weise Passagiere und/oder Fracht transportieren. Ein zumindest teilautonom operierendes Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen zumindest teilautonom operierende Fahrzeuge sein. Das Attribut „zumindest teilautonom“ drückt aus, dass das Fahrzeug zumindest in manchen Situationen und/oder zumindest zu manchen Zeiten autonom (d.h. ohne Mitwirkung eines Nutzers) gesteuert wird und/oder dass gewisse Systeme des Fahrzeugs (z.B. Assistenzsysteme) einen Fahrer zumindest zeitweise autonom unterstützen (z.B. ein Notbremssystem oder ein Spurhalteassistent). Insbesondere betrifft die vorliegende Offenbarung assistierte und/oder zumindest teilautonome Kraftfahrzeuge, daher werden in der Folge Aspekte der Offenbarung mithin an Beispielen von zumindest teilautonom operierenden Kraftfahrzeugen (einschließlich der assistierten Kraftfahrzeuge) erläutert (z.B. autonome Fahrzeuge der SAE J3016 Autonomiestufen 1 bis 5). Die entsprechenden Aspekte sind aber auch auf andere Typen von zumindest teilautonom operierenden Fahrzeugen übertragbar (insofern sie nicht spezifische Gegebenheiten zumindest teilautonom operierenden Kraftfahrzeugen betreffen).
Der Begriff „Nutzer“ umfasst jegliche Person, die mit dem Fahrzeug fährt, von diesem transportiert wird oder seinen Betrieb überwacht. Ein Nutzer kann ein Passagier eines Fahrzeugs (insbesondere ein Fahrer) sein. Ein Nutzer kann sich aber auch außerhalb des Fahrzeugs befinden und dieses beispielsweise steuern und/oder überwachen (z.B. während eines Einparkvorgangs oder von einer entfernten Zentrale).
Ein „Betriebsszenario“ kann jegliches Szenario sein, dass während des Betriebs des Fahrzeugs auftritt. Zum Beispiel kann ein Betriebsszenario eine bestimmte Fahrsituation sein. Ein Betriebsszenario kann sich auf einen zeitlich begrenzten Abschnitt während des Betriebs des Fahrzeugs beziehen (z.B. kürzer als 10 Minuten oder kürzer als 1 Minute). Dabei ist ein Betriebszenario nicht auf Szenarien beschränkt, in denen das Fahrzeug sich bewegt (also fährt).
Unter dem Begriff „Fahrszenario“ wird ein Betriebsszenario verstanden, das während der Fahrt des Fahrzeugs auftritt.
Der Begriff „Sensordaten“ umfasst alle Daten, die für das Fahrzeug im Betrieb des Fahrzeugs erfasst werden. Dabei können die Sensordaten von Sensoren des Fahrzeugs erfasst werden. Sensordaten können auch außerhalb des Fahrzeugs erfasst werden (und an dieses übermittelt werden). Zum Beispiel sind GPS-Daten (oder andere Positionsdaten) Sensordaten. Der Begriff „Sensordaten“ umfasst auch Verarbeitungsstufen der Daten, die von den jeweiligen Sensoren aufgenommen werden, sowie entsprechende Metadaten. Weitere Beispiele sind weiter unten zu finden.
„Felddaten“ umfassen alle Daten, die im Zusammenhang mit dem Betrieb eines (oder einer Vielzahl) von Fahrzeugen anfallen und die beispielsweise zum Auslegen (z.B. Training) von zumindest teilautonomen Fahrzeugen verwendet werden. Beispielsweise können Felddaten dazu verwendet werden, entsprechende Betriebsszenarien in einer Simulationsumgebung zum Trainieren von zumindest teilautonomen Fahrzeugen (bzw. der darin enthaltenen Systeme) zu erzeugen.
Figurenliste

1 ist ein Flussdiagramm, das die Verfahren der vorliegenden Offenbarung schematisch illustriert.
2 zeigt in schematischer Weise ein Computer-Programm, ein computer-lesbares Medium oder Signal und ein Computersystem.
3 zeigt ein Beispiel eines Spurgraphen.
4 zeigt eine Ausführungsform für ein Flussdiagramm, das die Verfahren der vorliegenden Offenbarung schematisch illustriert.

Beschreibung
Die in dieser Offenbarung vorgestellten Verfahren zielen auf das Erzeugen und Identifizieren von Corner Cases 40 von Betriebs-/Fahrszenarien ab, die beim Entwickeln und/oder Testen eines Fahrzeugs, insbesondere eines Fahrzeugs (teil)autonomen Fahren, von Bedeutung sein können.
Offenbart wird ein computer-implementiertes Verfahren 100 zur Identifizierung von Corner Cases (Eckfälle) 40 von Betriebs-/Fahrszenarien von Fahrzeugen, welches schematisch in 1 dargestellt ist. Das Verfahren 100 umfasst Empfangen 110 eines oder mehrerer Merkmale 10 zur Charakterisierung eines Betriebs-/Fahrzustands. Das Verfahren 100 umfasst weiterhin Extrahieren 120 mindestens eines Spurgraphen 20 zu dem einen oder den mehreren Merkmalen 10 aus einer Graphendatenbank 500. Die Graphendatenbank 500 kann eine Datenbank sein oder durch eine gleichwertige Speicherstruktur realisiert sein. Das Empfangen 110 des einen oder der mehreren Merkmale 10 zur Charakterisierung eines Betriebs-/Fahrzustands kann auch implizit dadurch erfolgen (d.h. formell entfallen), dass ein Spurgraph 20 aus der Graphendatenbank 500 gewählt/extrahiert wird. In der Tat beinhaltet das Wählen des Spurgraphs 20 bereits implizit eine Wahl von dem einen oder der mehreren Merkmale 10, da jeder Knoten im Spurgraphen 20 einem jeweiligen Wertebereich in ein und demselbem durch das oder die Merkmale 10 aufgespannten (Vektor-) Raum entspricht. In anderen Worten, jeder Spurgraph 20 kann einem oder mehreren Merkmalen 10 zugeordnet werden. 3 zeigt zum Beispiel einen Spurgraphen 20 mit vier Merkmalen 10, wobei jedem Knoten ein vierdimensionaler Vektor (z.B. [1, 2, 1, 1]) zugeordnet ist, dessen Einträge sich auf die durch das oder die Merkmale 10 definierte Basis in einem Vektorraum beziehen (in anderen Fällen kann jedem Knoten ein Vektor höherer oder niedriger Dimensionaliät, z.B. mit mehr als vier Dimensionen oder weniger als vier Dimensionen zugeordnet sein).
Das Verfahren 100 umfasst weiterhin Modifizieren 130 des mindestens einen Spurgraphen 20, wobei ein modifizierter Spurgraph 21 erzeugt wird. Das Modifizieren 130 des mindestens einen Spurgraphen 20 kann beispielsweise eine Änderung (z.B. eine Deformation, d.h. eine stetige Änderung) der Knoten und/oder der Kanten des Spurgraphen 20 sowie aller Parameter (Häufigkeit, Verweildauer, Richtungen,...), die den Knoten oder den Kanten zugeordnet sind, umfassen. Insbesondere können die Vektoren eines oder mehrerer Knoten (z.B. innerhalb der entsprechenden Spezifikation) in dem von dem oder die Merkmale 10 aufgespannten (Vektor-) Raum geändert werden. Im beispielhaften Fall, in dem ein Merkmal der Fahrgeschwindigkeit des Fahrzeugs entspricht, kann z.B. der Eintrag dieses Merkmals in einen höheren oder tieferen Fahrgeschwindigkeitsbereich skaliert werden.
Eine weitere Möglichkeit des Modifizierens 130 kann darin bestehen, einen oder mehrere Knoten und deren zugehörige Kanten zu entfernen. Alternativ oder zusätzlich können ein oder mehrere Knoten hinzugefügt werden, und über neue Kanten mit den ursprünglich vorhandenen Knoten verbunden werden. Durch das Entfernen von Knoten und/oder Kanten können Zustände und/oder Übergänge zwischen Zuständen eliminiert werden. Alternativ oder zusätzlich können durch das Hinzufügen von Knoten und/oder Kanten Zustände und/oder Übergänge zwischen Zuständen erzeugt werden.
Das Modifizieren 130 des Spurgraphen 20 kann beispielsweise darauf abzielen, Lücken von Betriebs-/Fahrszenarien in den Messdaten (z.B. in den Felddaten) zu schließen.
Das Verfahren 100 umfasst weiterhin Rekonstruieren 140a eines ersten Betriebs-/Fahrszenarios 30 aus dem Spurgraphen 20 und Rekonstruieren 140b eines zweiten Betriebs-/Fahrszenarios 31 aus dem modifizierten Spurgraphen 21, wobei die Reihenfolge des Rekonstruierens 140a des ersten Betriebs-/Fahrszenarios 30 und des Rekonstruierens 140b des zweiten Betriebs-/Fahrszenarios 31 irrelevant ist. Das Rekonstruieren 140a und das Rekonstruieren 140b kann Wählen je einer Spur im Spurgraphen umfassen, aus der jeweils das (erste/zweite) Betriebs-/Fahrszenario 30, 31 rekonstruiert werden kann. Das Wählen der Spur kann automatisch und/oder manuell erfolgen. Eine automatische Wahl kann z.B. dadurch realisiert werden, dass ein beliebiger Knoten als Startknoten ausgewählt wird und davon ausgehend in Pfeilrichtung einer Kante ein weiterer beliebiger Knoten ausgewählt wird. Dieser Prozess kann solange wiederholt werden, bis eine Spur einer gewünschten Länge (Anzahl der Knoten in einer Spur) erreicht ist. Je nach Spurgraph kann es allerdings auch vorkommen, dass die gewünschte Länge der Spur nicht erreicht werden kann. In diesem Fall kann eine geringere Länge der Spur entweder akzeptiert werden oder ein neuer Versuch mit einem anderen Startknoten gestartet werden. Die Spur 11 kann eine Sequenz von zwei oder mehr Knoten des Spurgraphen 10 sein, wobei jeweils zwei aufeinanderfolgende Knoten der Sequenz eine Pfeilrichtung in Richtung der Sequenz aufweisen. Diese Sequenz kann auch einen oder mehrere Knoten des Spurgraphen 10 mehrfach beinhalten. Eine graphische Darstellung der Spur umfasst in diesem Fall dann eine oder mehrere geschlossene Schleifen.
Es kann vorteilhaft sein, eine Spur vor dem Modifizieren 130 des Spurgraphen 20 zu wählen und beim Modifizieren 130 des Spurgraphen 20 die Spur ebenfalls zu modifizieren. Dadurch kann die Vergleichbarkeit der rekonstruierten Betriebs-/Fahrszenarien 30, 31 erhöht werden.
Das Rekonstruieren 140a, 140b kann eine Simulation des ersten oder zweiten Betriebs-/Fahrszenarios 30, 31 umfassen. Das Rekonstruieren 140a, 140b des ersten oder zweiten Betriebs-/Fahrszenarios 30, 31 kann weiterhin umfassen Prüfen, ob das zu erzeugende erste oder zweite Betriebs-/Fahrszenario 30, 31 realistisch ist. Eine solche Prüfung kann z.B. darin bestehen, ob das erste oder zweite Betriebs-/Fahrszenario 30, 31 (erfolgreich) simuliert werden kann. Eine Kurvenfahrt mit hochskalierter Fahrzeuggeschwindigkeit kann z.B. an physikalische Grenzen stoßen, sofern die Querdynamik mitsimuliert wird. In anderen Worten die Lösbarkeit der Modellgleichungen kann als ein Maß dafür gesehen werden, dass das rekonstruierte Betriebs-/Fahrszenario realistisch ist. Alternativ oder zusätzlich kann bei der Beurteilung der Realistizität auch eine Fahrzeugspezifikation herangezogen werden, z.B. wie schnell eine Kurve mit einem bestimmten Kurvenradius durchfahren werden können muss. Der Begriff „Rekonstruieren“ zielt zum einen darauf ab, ein Betriebs-/Fahrszenario 30, 31 auf Basis eines Spurgraphen 20, welcher ursprünglich aus einer Messung abgeleitet wurde, zu erzeugen. Alternativ oder zusätzlich, kann „Rekonstruieren“ auch im Sinne eines „Konstruieren“ , d.h. unabhängig einer Ableitung des Spurgraphen 20 aus einer Messung, verstanden werden. Das kann z.B. der Fall sein, wenn der Spurgraph selbst synthetisch erzeugt oder geändert wurde (wie z.B. der modifizierte Spurgraph 21) und in der Graphendatenbank 500 gespeichert wurde (z.B. im Schritt 160). Alternativ oder zusätzlich kann der Spurgraph auch aus Fahrzeugmessungen eines anderen Projekts (typischerweise eines Vorgängerprojekts) stammen.
Das Verfahren 100 umfasst weiterhin Identifizieren 150 des zweiten Betriebs-/Fahrszenarios 31 als Corner Case 40, wenn das zweite Betriebs-/Fahrszenario 31 im Vergleich zum ersten Betriebs-/Fahrszenario 30 auf Basis eines vorbestimmten Kriteriums als neu und/oder unbekannt bewertet wird.
Das Identifizieren 150 des zweiten Betriebs-/Fahrszenarios 31 als neu und/oder unbekannt zielt unter anderem darauf ab, die Menge von Spurgraphen 20, 21, die z.B. in der Graphendatenbank 500 gespeichert 160 werden können, möglichst klein und redundanzfrei zu halten. Dadurch kann erreicht werden, dass das Verfahren 100 auch nach vielen Wiederholungen effizient bleibt. Zusätzliche Ausführungen zu möglichen Ausgestaltungen des vorbestimmten Kriteriums finden sich weiter unten.
Ein (z.B. jedes, insbesondere das erste und/oder das zweite) Betriebs-/Fahrszenario 30, 31 kann ein oder mehrere Zeitschriebe umfassen. Der eine oder die mehreren Zeitschriebe können ein oder mehrere Sensordaten, optional ein oder mehrere Sensordaten eines zumindest teilautonom fahrenden Fahrzeugs, sein. Die mehreren Zeitschriebe können sich auf ein und denselben Zeitraum beziehen. Die Abtastungen der mehreren Zeitschriebe können unterschiedlich sein. Der eine oder die mehreren Zeitschriebe können Felddaten sein.
4 zeigt eine Ausführungsform des Verfahrens 100 zur Identifizierung von Corner Cases (Eckfälle) 40 von Betriebs-/Fahrszenarien.
Ein (z.B. beliebiges) Merkmal 10 zur Charakterisierung eines Betriebs-/Fahrzustands kann einen Zeitschrieb und/oder einen Wertebereich (oder einen Teil des Wertebereichs, insbesondere einen Wert) des Zeitschriebs umfassen (oder sein). Alternativ oder zusätzlich kann ein (z.B. beliebiges) Merkmal 10 einen Parameter des einen oder der mehreren Zeitschriebe oder einen aus diesen abgeleiteten Parameter umfassen (oder sein). In dem beispielhaften Fall mit vier Merkmalen 10, wobei z.B. einem Knoten der vierdimensionale Vektor [1, 2, 1, 1] zugeordnet ist, kann z.B. der erste Eintrag (hier: eine 1) des Vektors einem Wertebereich der Fahrzeuggeschwindigkeit von 20km/h bis 50km/h zugeordnet sein. Weiterhin kann der zweite Eintrag (hier: eine 2) des Vektors z.B. einem Wertebereich des Lenkwinkels von 0° bis +5° zugeordnet sein. Weiterhin kann z. B. der dritte Eintrag (hier: eine 1) des Vektors einer aus Kameradaten abgeleiteten Stärke des Gegenlichts von 3 (oder einem Wertebereich, z.B. auf einer einheitlosen Skala von 1 bis 5) sein. Weiterhin kann z.B. der vierte Eintrag (hier: eine 1) des Vektors einem (diskreten) Klassifikationsergebnis zur Erkennung eines Hindernisses auf der Fahrbahn sein. Jeder mögliche andere Knoten des Spurgraphen 20, 21 kann ebenfalls einen vierdimensionalen Vektor (z.B. [2, 0, 1, 1]) mit jeweils anderen Einträgen aufweisen. Hierbei können die Einträge zweier Vektoren als anders betrachtet werden, wenn sie sich mindestens in einem Eintrag unterscheiden. Die Vektoren der Knoten eines Spurgraphens können sich allerdings auf dieselben Merkmale beziehen. Z.B. kann sich der erste Eintrag (hier: eine 2) des Vektors des anderen Knoten ebenfalls auf den Zeitschrieb Fahrzeuggeschwindigkeit beziehen und insbesondere auf einen Wertebereich der Fahrzeuggeschwindigkeit z.B. von 50km/h bis 70km/h, etc.
Ein Spurgraph 20, 21, dargestellt z.B. in 3, kann ein Graph sein. Der Graph kann einen oder mehrere Knoten umfassen, wobei jeder Knoten einem Wertebereich in einem durch das oder die Merkmale 10 aufgespannten (Vektor-)Raum entspricht. Die Wertebereiche von je zwei Knoten des Spurgraphen 20, 21 können unterschiedlich sein. Überlappungen zwischen Wertebereiche von je zwei Knoten des Spurgraphen 20, 21 können vermieden werden. Jeder Wertebereich kann eine höherdimensionale Untermenge des durch das oder die Merkmale 10 aufgespannten (Vektor-) Raum sein. Ein Knoten kann einem Wertebereich in dem (Vektor-) Raum entsprechen, indem dem Knoten ein Vektor zugeordnet ist, dessen Einträge Koordinaten bezüglich einer Basis im (Vektor-) Raum und/oder Abzählungen von Untermengen des (Vektor-)Raums sind. Zum Beispiel können (höher-dimensionale) Intervalle im (Vektor)-Raum durchnummeriert werden.
In bestimmten Fällen kann es vorteilhaft sein, wenn der Spurgraph mindestens einen Knoten mehrfach umfasst. Ein solcher Knoten könnte z.B. einen Zwischenzustand darstellen, der in je zwei Betriebs-/Fahrszenarien auftritt, die allerdings auseinandergehalten werden sollen.
Der Graph kann weiterhin keine oder eine Kante zwischen je zwei Knoten umfassen, wobei jede Kante mindestens eine Pfeilrichtung aufweist, optional auch entgegengesetzte Pfeilrichtungen aufweisen kann, wobei die Pfeilrichtung jeweils die Richtung eines Übergangs zwischen den den Knoten zugehörigen Wertebereichen anzeigt.
Jedem Knoten kann eine Häufigkeit zugeordnet werden, die optional durch die Größe des Knoten dargestellt werden kann. Alternativ oder zusätzlich kann jedem Knoten eine Verweildauer zugeordnet werden, die optional durch eine Farbkodierung dargestellt werden kann. Alternativ oder zusätzlich kann jeder Kante (oder jeder Kante und deren Richtung) eine Übergangshäufigkeit zugeordnet werden, die optional durch eine weitere Farbkodierung dargestellt werden kann (z.B. können jeweils die Pfeilspitzen von Kanten entsprechend eingefärbt werden).
Der mindestens eine Spurgraph 20, 21 kann eine Datenstruktur sein, die ein oder mehrere Zeitschriebe aggregiert und komprimiert (d.h. weitesgehend redundanzfrei) repräsentiert. Der eine oder die mehreren Zeitschriebe können insbesondere Sensorsignale des Fahrzeugs oder der Fahrzeuge der Fahrzeugflotte sein. Die Datenstruktur kann z.B. in einem xml oder json Format gespeichert werden. Dabei können auch Metadaten (z.B. zur eindeutigen Kennzeichnung von Fahrzeugen in der Fahrzeugflotte) gespeichert werden.
Das Modifizieren 130 des mindestens einen Spurgraphen 20 kann auf einem Parameterbeschreibungsmodel basieren. In dem Parameterbeschreibungsmodel können Informationen (z.B. weitere Parameter, Intervalle, Randbedingungen...) enthalten sein, die darüber Aufschluss geben, inwieweit der Spurgraph 20 modifiziert werden kann/darf. Dadurch kann beispielsweise verhindert werden, dass einem Fahrzeug mit einer bestimmten Fahrzeugmasse und Motorisierung ein Betriebs-/Fahrszenario (z.B. eine Beschleunigung auf eine große Fahrzeuggeschwindigkeit innerhalb sehr kurzer Zeit) abverlangt wird, obwohl das Betriebs-/Fahrszenario außerhalb der Spezifikation des Fahrzeugs liegt. Zusätzlich oder alternativ, kann das Modifizieren 130 des mindestens einen Spurgraphen 20 auf einem Parameterrauschenbeschreibungsmodell basieren. Das Parameterrauschenbeschreibungsmodell kann Informationen (z.B. weitere Parameter, Intervalle, Randbedingungen, Verteilungsfunktionen...) enthalten, anhand derer der Spurgraph 20, insbesondere ein Knoten oder eine Kante des Spurgraphen 20, einem Rauschen unterzogen werden kann. Beispielsweise kann eine einem Knoten zugeordnete Verweildauer nach einer Verteilungsfunktion bestimmt („gewürfelt“) werden.
In einer beispielhaften Ausführungsform kann ein Spurgraph 20 (oder können mehrere Spurgraphen 20) über Monte-Carlo Simulationen mit folgenden exemplarischen Rauschparametern erzeugt werden. Zum einen kann je Knoten eine Verweildauer nach einer Verteilungsfunktion der Verweildauer je Knoten berechnet werden. Weiterhin können Knotenübergänge über bestehende Kanten nach einer Verteilungsfunktion der Zustandsübergänge je zweier Knoten berechnet werden. Weiterhin können Parameter der einzelnen Cluster/Knoten beispielsweise durch sampling über einen zeitkontinuierlichen stochastischen Prozess (z.B. Wiener Prozess, Ornstein-Uhlenstein Prozess) mit Startwerten berechnet werden. Die Startwerte können beispielsweise Grenzwerte der einzelnen Cluster/Knoten darstellen. Alternativ oder zusätzlich können die Startwerte Parameterwerte nach Logik einer inversen Gauß-Verteilung der bekannten Parameterverteilung innerhalb eines Clusters/Knoten mit geringer Auftretenswahrscheinlichkeit sein. Z.B. können diejenigen Startwerte, die eine geringe Wahrscheinlichkeit bei Erzeugung des Graphen hatten - entweder durch Verwendung der inversen Gauß-Verteilung oder durch Ablesen aus Tabelle, z.B. Werte außerhalb eines 1-sigma oder 2-sigma Wahrscheinlichkeitsbereichs - verwendet werden. Alternativ oder zusätzlich können die Startwerte Parameterwerte nach Logik einer randomisierten Gauß-Verteilung sein. Weiterhin können Knoten nach dem Parameterbeschreibungsmodell über eine Gauß-Verteilung (Hinzunahme z.B. außerhalb eines 2-sigma Bereichs) hinzugefügt werden. Weiterhin können Kanten nach dem Parameterbeschreibungsmodell über eine Gauß-Verteilung (Hinzunahme z.B. außerhalb eines 2-sigma Bereichs) hinzugefügt werden.
In einer anderen beispielhaften Ausführungsform (oder zusätzlich) kann ein Spurgraph 20 (oder können mehrere Spurgraphen 20) durch ein generative adversarial network (GAN) oder GraphGAN erzeugt werden.
Das Modifizieren 130 des mindestens einen Spurgraphen 20 kann auf search-based testing und/oder boundary case testing basieren. Die Verwendung von search-based testing und/oder boundary case testing kann vorteilhaft sein, da der Raum der Möglichkeiten beim Modifizieren 130 des mindestens einen Spurgraphen 20 sehr groß (und ohne Diskretisierung unendlich groß) sein kann. Dank search-based testing und/oder boundary case testing können in dem großen Raum der Möglichkeiten wenige (und dadurch handhabbare) Konfigurationen bestimmt werden, die den großen Raum möglichst gut abdecken. Zudem kann dadurch vermieden werden, dass mehrere Modifikationen des mindestens einen Spurgraphen 20 zu ähnlich sind. Dadurch können bei der Identifizierung von Corner Cases Zeit und Ressourcen gespart werden.
Der modifizierte Spurgraph 21 kann z.B. via dem Parameterbeschreibungsmodell und/oder via einem Generator, der den extrahierten Spurgraph nach klassischen Verifikationsmethoden (search-based testing, boundary parameter testing) erzeugt, erzeugt werden.
Das Rekonstruieren 140a, 140b eines Betriebs-/Fahrszenarios 30, 31 aus einem Spurgraphen 20, 21 kann ein Betriebs-/Fahrszenario 30, 31, insbesondere dem oder den Merkmalen 10 zugehörige simulative Zeitschriebe, derart erzeugen, dass aus dem erzeugten Betriebs-/Fahrszenario 30, 31 ein weiterer Spurgraph abgeleitet (oder erzeugt) werden kann, der zum Spurgraphen 20, 21 (nach einem weiteren vorbestimmten Kriterium) äquivalent ist. In dieser Hinsicht kann der Spurgraph als reversible Komprimierung gesehen werden.
Die Ableitung (oder Erzeugung) eines Spurgraphen für einen oder mehrere Zeitschriebe aus einem Betriebs-/Fahrszenario kann zunächst Clustern von y-Werten des einen oder der mehreren Zeitschriebe in mindestens zwei Clusters in einem (Vektor-) Raum, dessen Dimensionalität der Anzahl der einen oder der mehreren Zeitschriebe entspricht, optional mittels unüberwachtem Lernen, umfassen. Dabei kann optional unüberwachtes Maschinenlernen zum Einsatz kommen (z.B. k-means clustering oder andere Cluster-Verfahren).
Zum Beispiel können die y-Werte zweier Zeitschriebe (z.B. Fahrzeuggeschwindigkeit und Lenkwinkel) (als Punktewolke) in einen zweidimensionalen (Vektor-) Raum abgebildet und zweidimensionale Clusters, d.h. zweidimensionale Untermengen, im zweidimensionalen (Vektor-)Raum definiert werden.
Alternativ kann das Erzeugen des Spurgraphen für die einen oder mehreren Zeitschriebe (oder zusätzlich kann das Clustern von y-Werten des einen oder der mehreren Zeitschriebe in mindestens zwei Clusters in dem (Vektor-) Raum) zunächst Clustern von y-Werten jedes der Zeitschriebe separat in jeweils eindimensionale Clusters umfassen, wobei mindestens für einen Zeitschrieb mindestens zwei eindimensionale Clusters definiert werden können. Im Falle von mehreren Zeitschrieben kann das Erzeugen des Spurgraphen (oder das Clustern von y-Werten des einen oder der mehreren Zeitschriebe in mindestens zwei Clusters in dem (Vektor-) Raum) sodann Erstellen von höherdimensionalen Clusters in einem (Vektor-) Raum, dessen Dimensionalität der Anzahl der mehreren Zeitschriebe entspricht, durch Kombinieren eindimensionaler Clusters je Zeitschrieb umfassen. Werden zum Beispiel die y-Werte des Zeitschriebs (z.B. der Fahrzeuggeschwindigkeit) in zwei Clusters geclustert und die y-Werte des Zeitschriebs (z.B. der Lenkgeschwindigkeit) in drei Clusters geclustert, können sechs höherdimensionale (hier: zweidimensionale) Clusters in dem (Vektor-) Raum definiert werden.
Weiterhin kann die Ableitung des Spurgraphen Identifizieren von mindestens einem Cluster (z.B. einem höher-dimensionalen Wertebereich) als Knoten im Spurgraphen umfassen. In der Regel werden mindestens zwei Clusters als Knoten identifiziert, da anderenfalls der Spurgraph keine Kante und somit keinen Übergang zwischen Zuständen enthalten kann. Das Erstellen von Knoten im Spurgraphen kann eine Zustand-zu-Vektor Transformation bezüglich des einen oder der mehreren Merkmale umfassen. Weiterhin kann die Ableitung des Spurgraphen Analysieren der Übergänge zwischen Clusters anhand des einen oder der mehreren Zeitschriebe und Identifizieren von mindestens einem Übergang als Kante zwischen zwei Knoten im Spurgraphen umfassen. Die Ableitung des Spurgraphen kann optional auch Auswerten der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters anhand des einen oder der mehreren Zeitschriebe umfassen. Die Ableitung des Spurgraphen kann optional auch Hinzufügen der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters an den mit dem Cluster identifizierten Knoten im Spurgraphen umfassen. Die Clusterbildung kann derart ausgelegt sein, dass im Zuge der Clusterbildung irrelevante und/oder redundante Information in dem einen oder den mehreren Zeitschrieben eliminiert wird.
Das weitere vorbestimmte Kriterium ist dafür ausgelegt, zwei Spurgraphen vergleichen zu können. Dazu kann beispielsweise zunächst die Anzahl der Knoten in den zwei Spurgraphen verglichen werden. Alternativ oder zusätzlich kann die Anzahl der Kanten in den zwei Spurgraphen verglichen werden. Weiterhin kann z.B. die Anzahl der übereinstimmenden Knoten in den zwei Spurgraphen ermittelt werden. Alternativ oder zusätzlich kann auch die Anzahl der übereinstimmenden Kanten zwischen übereinstimmenden Knoten in den zwei Spurgraphen ermittelt werden. Alternativ oder zusätzlich können die den Knoten und/oder Kanten zugeordneten Parameter miteinander verglichen werden. Dabei kann es vorteilhaft sein, die Knoten beispielsweise nach ihrem Vektor geordnet anzuordnen. Dadurch können z.B. auch je zwei nicht übereinstimmende aber sich nahestehende Knoten aus beiden Spurgraphen identifiziert werden. Alternativ oder zusätzlich können die Spurgraphen in einen (metrischen) Raum eingebettet werden. Dadurch kann dann über eine Metrik ein Abstand zwischen den Spurgraphen ermittelt werden. Dabei können bekannte Abstandsmaße beispielsweise der Levenshtein-Abstand (z.B. nach Transformation der Spurgraphen in je eine Zeichenkette), der Hamming-Abstand, durchschnittliche kürzeste Pfade und/oder Euklidische Oberflächen angewandt werden.
Das vorbestimmte Kriterium (zur Bewertung der Neuheit und/oder Unbekanntheit des zweiten Betriebs/Fahrszenarios 31) kann darauf basieren, den oder die Zeitschriebe des ersten Betriebs/Fahrszenarios 30 mit dem oder den Zeitschrieben des zweiten Betriebs/Fahrszenarios 31 zu vergleichen. Ein solcher Vergleich können zunächst die Zeitschriebe (z.B. die Fahrzeuggeschwindigkeiten) für jeweils ein Merkmal 10 des ersten bzw. zweiten Betriebs-/Fahrszenarios verglichen werden. Dabei können bekannte Methoden zum Vergleichen zweier Kurven eingesetzt werden. In Fällen, in denen der Zeitraum der Zeitschriebe identisch ist, kann beispielsweise ein Integral über die absolute Differenz aus einem Zeitschrieb des ersten Betriebs-/Fahrszenarios 30 und dem zugehörigen Zeitschrieb des zweiten Betriebs-/Fahrszenarios 31 berechnet werden. Ein solches Integral kann dann als Maß für die Unterschiedlichkeit dieser Zeitschriebe betrachtet werden. Weiterhin kann jeweils ein vorbestimmter Schwellwert definiert werden, oberhalb dessen die Unterschiedlichkeit als neu und/oder unbekannt bewertet wird.
Im Falle mehrerer Zeitschriebe je Betriebs-/Fahrszenario können aus den Maßen für die Unterschiedlichkeit und/oder den Bewertungen dieser Zeitschriebe bezüglich Neuheit und/oder Unbekanntheit ein Gesamtmaß für die Unterschiedlichkeit der Betriebs-/Fahrszenarien (z.B. über Summation und/oder Mittelwertbildung) berechnet werden. Dadurch kann dann eine Gesamtbewertung bezüglich Neuheit und/oder Unbekanntheit des zweiten Betriebs-/Fahrszenarios 31 ermittelt werden, gegebenenfalls erneut über einen Vergleich des Gesamtmaßes mit einem vorbestimmten Schwellwert.
Der modifizierte Spurgraph 21 kann in der Graphendatenbank 500 gespeichert 160 werden, wenn das zweite Betriebs-/Fahrszenario 31 als Corner Case 40 identifiziert worden ist. Dadurch wird die Menge von Spurgraphen, die (nun) bekannten Corner Cases 40 entsprechen, in der Graphendatenbank 500 erweitert. Das Speichern 160 des (modifizierten) Spurgraphen anstelle des (zweiten) Betriebs-/Fahrszenarios kann insofern vorteilhaft sein, als die Datengröße des Spurgraphs wesentlich geringer ist im Vergleich zu dem Betriebs-/Fahrszenario (z.B. mit einem oder mehreren Zeitschrieben). Dadurch können bei demselben Speicherplatz mehr Betriebs-/Fahrszenarien als Spurgraphen gespeichert werden. Weiterhin kann das als eine Voraussetzung dafür gesehen werden, dass das Verfahren 100 mehrfach wiederholt werden kann und dennoch effizient bleibt.
Das Verfahren 100 kann in einem Steuergerät in einem Fahrzeug durchgeführt werden, wobei die Graphendatenbank 500 innerhalb des Fahrzeugs oder auf einem Cloud Server gespeichert sein kann. Innerhalb des Fahrzeugs kann die Graphendatenbank 500 z.B. in einem nicht-volatilen Speicher eines Steuergeräts gespeichert werden. Alternativ kann die Graphendatenbank 500 auch in einem volatilen Speicher des Steuergeräts gespeichert werden, sofern eine spätere Datenübertragung z.B. in einen Cloud Server vorgesehen ist. Ein Vorteil des Verfahrens 100 in dem Steuergerät des Fahrzeugs kann darin gesehen werden, dass große Datenmengen, insbesondere redundante Daten verworfen werden können, ehe sie endgültig (z.B. in Form von Spurgraphen) gespeichert werden. Offenbart wird ein Computer-Programm 200, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Identifizierung von Corner Cases 40 von Betriebs-/Fahrszenarien auszuführen. Das Computer-Programm 200 kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann zur Ausführung z.B. als Byte-Folge in den RAM eines Steuergeräts oder Computer geladen werden.
Offenbart wird weiterhin ein computer-lesbares Medium oder Signal 300, das das Computer-Programm 200 speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM,... umfassen, in dem das Signal gespeichert wird.
Offenbart wird weiterhin ein Computersystem 400, schematisch dargestellt in 2, das dafür ausgelegt ist, das Computer-Programm 200 auszuführen. Das Computersystem 400 kann insbesondere mindestens einen Prozessor und mindestens einen Arbeitsspeicher umfassen. Weiterhin kann das Computersystem 400 einen Speicher mit der Graphendatenbank 500 umfassen. Alternativ oder zusätzlich kann das Computersystem 400 eine Kommunikationsschnittstelle umfassen, über welche eine Verbindung zu der Graphendatenbank 500 hergestellt werden kann.

Claims

Computer-implementiertes Verfahren (100) zur Identifizierung von Corner Cases (40) von Betriebsszenarien von Fahrzeugen, umfassend: Empfangen (110) eines oder mehrerer Merkmale (10) zur Charakterisierung eines Betriebszustands eines Fahrzeugs; Extrahieren (120) mindestens eines Spurgraphen (20) zu dem einen oder den mehreren Merkmalen (10) aus einer Graphendatenbank (500); Modifizieren (130) des mindestens einen Spurgraphen (20), wobei ein modifizierter Spurgraph (21) erzeugt wird; Rekonstruieren (140a) eines ersten Betriebsszenarios (30) aus dem Spurgraphen (20); Rekonstruieren (140b) eines zweiten Betriebsszenarios (31) aus dem modifizierten Spurgraphen (21); Identifizieren (150) des zweiten Betriebsszenarios (31) als Corner Case (40), wenn das zweite Betriebsszenario (31) im Vergleich zum ersten Betriebsszenario (30) auf Basis eines vorbestimmten Kriteriums als neu und/oder unbekannt bewertet wird.
Verfahren (100) nach Anspruch 1, wobei ein Betriebsszenario (30, 31) ein oder mehrere Zeitschriebe umfasst.
Verfahren (100) nach Anspruch 2, wobei der eine oder die mehreren Zeitschriebe ein oder mehrere Sensordaten, optional ein oder mehrere Sensordaten eines Fahrzeugs, sind.
Verfahren (100) nach Anspruch 2 oder 3, wobei ein Merkmal (10) zur Charakterisierung eines Betriebszustands einen Zeitschrieb und/oder einen Wertebereich des Zeitschriebs umfasst.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei ein Spurgraph (20, 21) ein Graph ist, umfassend: einen oder mehrere Knoten, wobei jeder Knoten einem Wertebereich in einem durch das oder die Merkmale aufgespannten Raum entspricht; keine oder eine Kante zwischen je zwei Knoten, wobei jede Kante mindestens eine Pfeilrichtung aufweist, optional auch entgegengesetzte Pfeilrichtungen aufweisen kann, wobei die Pfeilrichtung jeweils die Richtung eines Übergangs zwischen den den Knoten zugehörigen Wertebereichen anzeigt.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Rekonstruieren (140a, 140b) eines Betriebsszenarios (30, 31) aus einem Spurgraphen (20, 21) ein Betriebsszenario (30, 31), insbesondere dem oder den Merkmalen (10) zugehörige simulative Zeitschriebe, derart erzeugt, dass aus dem erzeugten Betriebsszenario (30, 31) ein weiterer Spurgraph abgeleitet werden kann, der zum Spurgraphen (20, 21) äquivalent ist.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wenn abhängig von Anspruch 2, wobei das vorbestimmte Kriterium darauf basiert, den oder die Zeitschriebe des ersten Betriebsszenarios (30) mit dem oder den Zeitschrieben des zweiten Betriebsszenarios (31) zu vergleichen.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der modifizierte Spurgraph (21) in der Graphendatenbank (500) gespeichert (160) wird, wenn das zweite Betriebsszenario (31) als Corner Case (40) identifiziert worden ist.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Verfahren (100) in einem Steuergerät in einem Fahrzeug durchgeführt wird, wobei die Graphendatenbank (500) innerhalb des Fahrzeugs oder auf einem Cloud Server gespeichert ist.
Ein Computer-Programm (200), das dafür ausgelegt ist, das computer-implementierte Verfahren (100) nach einem der vorhergehenden Ansprüche auszuführen.
Computer-lesbares Medium oder Signal (300), das das Computer-Programm (200) nach Anspruch 10 speichert und/oder enthält.
Ein Computersystem (400), das dafür ausgelegt ist, das Computer-Programm (200) nach Anspruch 10 auszuführen.