-
Die Erfindung bezieht sich auf ein Verfahren und auf eine Vorrichtung für die Durchführung von virtuellen Tests in einer virtuellen Realitätsumgebung für ein Fahrzeug mit automatisierten Fahrmerkmalen ohne die Notwendigkeit eines physischen Fahrzeugs oder einer physischen Testumgebung. Sie bezieht sich speziell auf autonom fahrende Fahrzeuge. Die Erfindung bezieht sich auf das Erzeugen eines kompletten, selbstständig ablaufenden Tests und auf das Bewerten der erhaltenen Ergebnisse. Die Erfindung konzentriert sich auf die Definition der Testumgebung, auf Testvariationen und auf Testauswertungen. Das vorgeschlagene Verfahren erlaubt es, Hypothesen, Annahmen, Algorithmen in einer sehr frühen Phase der Projektentwicklung (d.h. Konzeptauswahl) bis hin zu einer späten Phase der Projektentwicklung (d.h. Akzeptanzbereitschaft) zu validieren oder zu verifizieren und Fragen zu beantworten, die bei einer Entwicklung eines Fahrzeugs, die nicht elektronisch erfolgt, sowohl kostenintensiv als auch zeitintensiv sind.
-
Bei autonom fahrenden Fahrzeugen stehen das Entwickeln und die Erprobung der Software vor neuen Herausforderungen. Aufgrund der Algorithmen, die zur automatisierten Steuerung eingesetzt werden, ergeben sich während der Entwurfsphase eine Vielzahl von Fragen und es wird eine Vielzahl von Tests notwendig. Bei der konventionellen Entwicklung sind die Fahrzeugtests dagegen mehr oder weniger vorbestimmt, basierend auf einigen ausgewählten Anwendungsfällen, die während der Entwicklung und des Entwurfs angegeben werden. In einer vorgegebenen Anzahl von Anwendungsfällen, die spezifische Szenarien und Situationen betreffen, muss die Software, die in dem Fahrzeug implementiert sein wird, in der Lage sein, diese unterschiedlichsten Anwendungsfälle zu meistern.
-
Für autonom fahrende Fahrzeuge stellen die bisherigen Ansätze der konventionellen Entwicklung zu viele Einschränkungen dar. So ist zum Beispiel die Anzahl der Szenarien, die autonomes Fahren zu meistern hat, wesentlich größer und fast unendlich. Dies erfordert gemäß den bisherigen Ansätzen eine ausgesprochen große Anzahl von gefahrenen Testkilometern und damit eine erhebliche Zeit. Derartige Tests erfordern auch eine Umgebung, die ein hohes Maß an Flexibilität bietet, um in einer angemessenen Zeitspanne die maximale Anzahl von Situationen (z. B. unterschiedliche Gradienten, unterschiedliche Hindernis-Layout, verschiedene Straßenoberflächen ...) zu testen. Diese Flexibilität ist mit hohen Kosten verbunden (d.h. Reisen, Transport von Material, Installation, Materialien, öffentliche Straßen-Zertifizierungen ...). Die Definition der großen Anzahl von Szenarien erfolgt in der Regel in Textform, die sich auf eine spezielle Softwaresprache bezieht. Aufgrund der Anzahl der zu handhabenden Szenarien kann dies eine sehr komplexe Aufgabe werden.
-
Bislang wurden Fahrzeug-Tests in der Regel in der realen Welt durchgeführt, zumindest und insbesondere in einer späten Phase der Entwicklung. Dies verlangt zunächst, dass ein physischer Prototyp vorhanden ist und mit realistischer Hardware implementiert wird. Dies ist ein kostenintensiver Prozess. Er erfordert Zeit, Ressourcen, Geld usw.. Es können häufig viele Fragen, die während der Designphase anfallen oder entstehen, erst nur sehr spät im Entwicklungsprozess beantwortet werden. Die vielen unterschiedlichen Verkehrssituationen, beispielsweise dichter, innerstädtischer Verkehr, Autobahn, kurvenreiche Bergstrecke, machen es aufgrund ihrer Komplexität nahezu unmöglich, alle möglichen Situationen im Zuge einer Testphase berücksichtigen zu können.
-
Die
DE 10 2011 088 807 A1 beschreibt ein Verfahren zum Entwickeln und/oder Testen eines Fahrerassistenzsystems, bei welchem aus einem vorgegebenen Testszenario mittels der Monte Carlo Simulation, also einem stochastischen Verfahren, eine Vielzahl weiterer Testszenarien erstellt wird. Für jedes auf diese Weise erstellte Szenarium wird jeweils ein Verlauf mit und ein Verlauf ohne Eingriff des Fahrerassistenzsystems simuliert. Durch den Vergleich dieser beiden Szenarien wird es möglich, quantitative Maße für die Auswirkungen des Eingriffs des Fahrerassistenzsystems zu finden. Beispielsweise kann für jedes der Szenarien ein Unfallrisiko, ein Schadensrisiko oder ähnliches quantifiziert werden.
-
Die
DE 10 2008 027 509 A1 zeigt ein Verfahren, das ebenfalls ein Fahrerassistenzsystem betrifft. Dieses soll bezüglich seiner Effektivität bereits in der Planungsphase bewertet werden können. Dazu wird eine Simulation, welche auf den Messdaten eines realen Unfalls basieren, durchgeführt. An entscheidenden Stellen der Simulation wird eine Untersimulation erzeugt, die das Eingreifen eines Fahrerassistenzsystems beinhaltet. Dieses Eingreifen kann beispielsweise die Aktivierung eines automatischen Bremssystems mit unterschiedlichen Verzögerungen beinhalten. Die Ergebnisse, beziehungsweise der Ausgang der Unfallsituation, werden als Simulationsdatensatz gespeichert. Bezüglich des als Basis dienenden Unfalls, dessen Daten für die Simulation herangezogen wurden, können so beispielsweise für unterschiedliche Verzögerungen entsprechende Aktivierungszeitpunkte für ein automatisches Bremssystem errechnet werden, welche zu einer Vermeidung des Unfalls führen. Auf diese Weise wird eine Datenbank von Simulationsdatensätzen geschaffen, die für eine Vielzahl von Fahrerassistenzsystemen genutzt werden kann, um eine verlässliche, auf realen Daten basierende Aussage über die Wirksamkeit des Fahrerassistenzsystems zu erhalten. Nachteilig ist, dass lediglich auf Messdaten von tatsächlich eingetretenen Unfallsituationen zugegriffen wird. Szenarien, für welche keine Unfalldaten vorhanden sind, Daten einer Fahrsituation, bei der es zu keinem Verlust der Fahrzeugkontrolle gekommen ist, beziehungsweise aus erfolgreich verhinderten Unfällen oder „Beinahe“ -Unfällen, finden im vorgestellten Verfahren keine Nutzung. Daher wird eine Reihe an Messdaten, welche möglicherweise zur Erstellung weitere Testszenarien durchaus geeignet wären, verworfen. Gerade der kritische Bereich zwischen durch ein Fahrerassistenzsystem verhindertem Unfall und eingetretenem Unfall beziehungsweise Kontrollverlust, ist jener Bereich, der beim Testen größtmögliches Potential für die Entwicklung bzw. Weiterentwicklung in sich trägt.
-
Es ist Ziel der Erfindung, eine Methode vorzuschlagen, um virtuelle Tests in einer virtuellen Realitätsumgebung zu entwickeln und durchzuführen, um so automatisierte Fahrsoftware zu überprüfen und zu validieren oder möglichst jede Art von Fragen zu beantworten, die während der Entwurfsphase aufgeworfen werden könnten. Die Methode soll alle notwendige Flexibilität bieten, um die automatisierte Fahrsoftware zu testen oder zu simulieren und soll weder ein physikalisches Fahrzeug noch eine physikalische Prüfumgebung erfordern, welche den Verkehr simuliert.
-
Diese Aufgabe wird gelöst durch das Verfahren mit den Merkmalen des Anspruchs 1. Dieses Verfahren verwendet wissenschaftliche Erkenntnisse aus der Spieltheorie und kann durch derartige Erkenntnisse ergänzt und weitergebildet werden.
-
Weitere Merkmale der Erfindung finden sich in den übrigen Patentansprüchen. Ausführungsbeispiele und nähere Erläuterungen der Erfindung ergeben sich aus der nun folgenden Beschreibung eines nicht einschränkend zu verstehenden Ausführungsbeispiels der Erfindung, das unter Bezugnahme auf die Zeichnung näher erläutert wird. In dieser Zeichnung zeigen:
- 1 ein Blockdiagramm des für die Durchführung der Erfindung verwendeten Systems,
- 2 eine dreidimensionale Darstellung eines virtuellen Testszenarios,
- 3 die Darstellung gemäß 2, jedoch nun mit eingefügten Definitionen von variablen Punkten,
- 4 die Darstellung gemäß 3, jedoch mit einer anderen Auswahl der variablen Punkte, und
- 5 die Darstellung gemäß 4, wiederum mit einer anderen Auswahl der gewählten Punkte.
-
Die Erfindung setzt voraus, dass die Definition eines virtuellen Testszenarios für ein Fahrzeug aus dem Stand der Technik bekannt ist. Die Methode gemäß der Erfindung geht wie folgt vor:
-
Im Block 20 wird ein virtuelles Testszenario für ein zu testendes, autonom fahrendes Fahrzeug 22 definiert und ausgewählt.
-
Im Block 24 werden Variationspunkte definiert und ausgewählt. Sie ermöglichen es, aus einem Testszenario eine große Anzahl von Tests abzuleiten.
-
Im Block 26 werden spezielle Validierungspunkte definiert und ausgewählt, die es ermöglichen, ein besonderes Element der virtuellen Welt zu markieren, das für die Validierungs- und Verifizierungsmethode relevant ist
-
Im Block 28 werden Antriebsbefehlspunkte definiert und ausgewählt, die es erlauben, einige einfache Anweisungen zu geben, wann und/oder wo bestimmte Algorithmen des zu prüfenden Fahrzeugs 22 aktiviert sind.
-
Im Block 30 wird eine Validierungs- und Verifikationsmethode definiert und ausgewählt, die es ermöglicht, eine Bewertung jeder Prüfung bzw. jedes Tests durchzuführen.
-
Block 32 sieht die Nutzung einer virtuellen Realitätsschnittstelle vor, um eine nahtlose, effiziente und ultraschnelle Definition des Tests zu ermöglichen.
-
Im Folgenden wird auf die einzelnen Blöcke und insbesondere ihre Funktion eingegangen. Jeder Block steht für eine elektronische Einheit, die Software aufweist und die in einem elektronischen Rechner implementiert ist:
-
Block 20, virtuelles Testszenario:
-
Die Definition des virtuellen Testszenarios ist im Stand der Technik bekannt und kann in folgenden Elementen bestehen:
- • Definition der aktiven Verkehrsteilnehmer:
- - Ein oder mehrere Fahrzeuge 22 im Test.
- • Definition der passiven Verkehrsteilnehmer:
- - Alle anderen Verkehrsteilnehmer, die sich im Verkehrsraum bewegen, aber nicht unter Test sind und möglicherweise mit dem getesteten Fahrzeug 22 interagieren können, wie zum Beispiel Fußgänger, Fahrradfahrer, andere Fahrzeuge 34, 36, Tiere ...
- • Definition der virtuellen Umgebung:
- - virtuelle Straße 38,
- - virtuelle Infrastruktur Definition (Zeichen, Ampeln ...)
- - virtuelle Hindernisse (Wände, Zäune, Bäume, Häuser 40, 42, 44, Bordstein 46, Parkstreifen 48, Löcher...)
- - virtuelles Wetter usw.
-
Block 24, Definition und Auswahl der Variationspunkte:
-
Bei der Auswahl eines beliebigen Elements des virtuellen Testszenarios kann der Testdesigner eine oder mehrere Variationsregeln für eine oder mehrere Merkmale der ausgewählten Elemente verknüpfen. Jede Variationsregel kann darin bestehen, zunächst eine Markierung mit einem Element des virtuellen Tests mit Hilfe einer virtuellen Realitätsschnittstelle (siehe Block
36) zu assoziieren und dann einen Wertbereich für ein oder mehrere Merkmale des Elements zu definieren (siehe Block
36). Beispiele für Variationen, die mit einem auf Testelementen positionierten Variationspunkt verknüpft werden können, sind in der folgenden Tabelle aufgeführt:
| Elemente des virtuellen Testszenarios verknüpft mit Variationspunkten | Variationspunkte für bestimmte, charakterisierende Elemente des virtuellen Testszenarios |
| getestetes Fahrzeug 22 | Steuerungs- und Kontrollalgorithmen (z.B. Längskontrolle, Steuerung der Geradeausfahrt, Software des getesteten Fahrzeugs 22 |
| | Sensormodelle (z.B. Radar, Bremsdruck...) |
| | Aktuatormodelle (z.B. Antriebsmotor, Bremsen, Lenkung...) |
| | |
| Passive Testteilnehmer | Verhaltensmodell (passiv, aggressiv, unvorhersehbar...) |
| | Bewegungslinien (Navigation im virtuellen Test) |
| | Dimensionen (Größe, Form) |
| | Erkennungsmerkmale (Material, Farbe, Modell...) |
| | |
| virtuelle Umgebung | Eigenschaften der Straße (Gradient, Oberfläche, Breite, Haftung...) |
| | Merkmale der Infrastruktur (Art der Verkehrszeichen, zeitliches Verhalten der Ampeln...) |
| | Merkmale der Hindernisse (Abmessungen, Oberfläche, Reibung...) |
| | Wetterbedingungen (Windgeschwindigkeit und - richtung, Regen, Schnee, Nebel...) |
-
Vorzugsweise könnte in einer weiteren Implementierung der Variationspunkt die Software-Kalibrierung einschließen.
-
Block 26, Definition und Auswahl der Validierungspunkte:
-
Validierungspunkte sind Marker, die mit irgendwelchen Elementen des virtuellen Testszenarios über eine virtuelle Realitätsschnittstelle verbunden sind. Validierungspunkte sind eine Methode zur Definition eines zusätzlichen Bewertungskriteriums für die Bewertung in Block 30, dieser Block führt u.a. auch die Bewertung durch. Es gibt positive und negative Validierungspunkte:
- - Positive Validierungspunkte, die mit einer positiven Punktzahl verbunden sind.
- - Negative Validierungspunkte, die mit einer negativen Punktzahl verbunden sind.
- - KO-Validierungspunkte.
-
Wenn während des Tests das getestete Fahrzeug 22 mit einem Element in Kontakt kommt, das mit einem Validierungspunkt verknüpft ist, wird es den entsprechenden Validierungspunkt und die zugehörige Punktzahl erhalten. Wenn das dem Validierungspunkt zugeordnete Element z.B. eine horizontale Fläche wie ein Parkplatz 48 ist, muss das getestete Fahrzeug 22 den größten Teil dieser Fläche (siehe Beispiel unten) in der virtuellen Testumgebung abdecken, um entsprechende Punkte zu erhalten.
-
Block 28 für Antriebsbefehle:
-
Im traditionellen Ansatz definiert ein Testingenieur sogenannte Testschritte, die eine Folge von Aktionen sind, die auf das zu prüfende Objekt (z. B. das getestete Fahrzeug) angewendet werden. Die Abfolge von Aktionen umfasst im Allgemeinen eine spezielle Interaktion mit der Umgebung (z. B. fährt das getestete Fahrzeug mit 50 km/h und ein zweites Fahrzeug stoppt 50 m davor). Da automatisierte Fahrzeugsoftware von Natur aus so gestaltet ist, dass sie mit ihrer Umgebung interagieren kann, kann ein einfacherer Ansatz verwendet werden, einschließlich der Definition von Antriebsbefehlen. Jeder einzelne Antriebsbefehl ist ein Element, das mittels einer virtuellen Realitätsschnittstelle im virtuellen Testszenario positioniert ist. Es gibt mehrere Arten von Fahranweisungspunkten:
- - Startpunkte, die die Koordinate beschreiben, bei der das getestete Fahrzeug 22 den Test starten oder sich neu positionieren soll, sofern es die Grenzen der virtuellen Testszenariumgebung verlassen sollte. Der Startpunkt ist in der Regel mit Anweisungen zum „Starten des Fahrzeugs“ verbunden (Taste EIN, Aktivieren eines bestimmten Teils der Steuerungssoftware) verknüpft. Wenn der Test mit mehreren Fahrzeugen durchgeführt werden soll, können mehrere Startpunkte definiert und kann ein Startpunkt jeweils mit einem getesteten Fahrzeug 22 verbunden werden. Hierbei kann auch mit einer gewissen Wahrscheinlichkeit für die Bewegung gearbeitet werden. In der Regel hat jedes einzelne getestete Fahrzeug 22 einen eigenen Startpunkt, es können aber auch Startpunkte zusammenfallen.
- - Software-Aktivierungspunkte, die die Koordinate oder die Zeit beschreiben, in der bestimmte Teile der Software, die im getesteten Fahrzeug 22 vorgesehen sind, aktiviert werden (z. B. selbstständiges Einparken aktivieren, Segeln aktivieren, geringere Fahrgeschwindigkeit aktivieren ...)
- - Routenpunkte, die eine Route in der virtuellen Testumgebung beschreiben, und die das getestete Fahrzeug 22 erreichen soll. Es kann mindestens einer der Routenpunkte mit einem einzelnen getesteten Fahrzeug 22 assoziiert werden, wobei jede Route mit einer gewissen Wahrscheinlichkeit verknüpft ist, so dass jedes einzelne getestete Fahrzeug 22 auch einen alternativen Weg wählen kann. Routenpunkte können mit einer Art virtuellem Navigationssystem verglichen werden. Jeder mit jedem einzelnen getesteten Fahrzeug 22 verbundene Routen- bzw. Streckenpunkt kann auch mit einer vorgegebenen Zeitspanne verknüpft sein, die das getestete Fahrzeug 22 einhalten soll. Jede Route beginnt von einem Startpunkt aus. Das getestete Fahrzeug 22 kann entweder zu ihm zurückkehren oder an einer anderen Stelle der virtuellen Testumgebung seine Fahrt beenden. Wenn ein getestetes Fahrzeug 22 einen Streckenpunkt erreicht hat, kehrt es mit der damit verbundenen Wahrscheinlichkeit zu einem seiner Startpunkte zurück oder fährt einen nächsten Streckenpunkt an.
-
Block 30 für die Bewertung:
-
Generische Bewertung:
-
Da die automatisierte Fahrsoftware auf der einen Seite in der Lage ist, jede Interaktion mit der Umgebung zu bewältigen und auf der anderen Seite einen bestimmten Fahrkomfort bieten soll, können die Akzeptanzkriterien des Tests generisch und identisch für alle Testpersonen sein. Es besteht in der Regel keine Notwendigkeit, bestimmte Akzeptanzkriterien festzulegen. In diesem Fall können die generischen Akzeptanzkriterien gegeben werden durch:
- - eine Sammlung von Verkehrsregeln (z. B. kein Kontakt mit einem anderen Verkehrsteilnehmer, Halten an einer Ampel, Vorfahrt für von rechts kommenden Verkehr...).
- - Eine Sammlung von Fahrkomfortregeln, die sich zumindest durch die Analyse der Beschleunigung und eines ruckelnden Fahrens (abrupte Variation der Beschleunigung über die Zeit) zusammensetzen. Übermäßige Beschleunigung, starkes Bremsen und Ruckeln können von Fahrgästen sehr negativ wahrgenommen werden, besonders, wenn sie bestimmte Schwellen überschreiten.
-
Die Erfindung schlägt vor, eine Klassifizierung sowohl jeder Verkehrsregel als auch jeder Komfortregel zu erstellen und jeweils eine bestimmte Anzahl von Punkten mit ihnen zu verknüpfen. Dies ermöglicht es, eine standardisierte Möglichkeit zu definieren und die Fähigkeit automatisierter Softwarealgorithmen zu vergleichen. Am Ende eines Tests wird die Gesamtbewertung, die durch die Algorithmen erreicht wird, durch die Testumgebung geschätzt und dem Testdesigner gemeldet. Diese Punktzahl kann in Bezug auf ein Auftreten und/oder auf die Dauer der Soft-Drive-Algorithmus-Aktivierung und in Bezug auf das Auftreten und/oder die Dauer der zugehörigen Regeln normiert werden. Am Ende des Tests ermittelt der Algorithmus eine bestimmte Gesamtpunktzahl und gibt diese an den Testdesigner aus. Dieser hat die Möglichkeit, bestimmte Regeln zu aktivieren und/oder zu deaktivieren, wenn sie für die im getesteten Fahrzeug 22 implementierte Software nicht relevant sind.
-
Speziell auf einen Bedarf zugeschnittene Bewertung:
-
Darüber hinaus kann die Bewertung auch einen speziell auf einen konkreten Bedarf zugeschnittenen Teil aufweisen, der durch:
- - speziell vorgegebene Validierungspunkte, siehe Block 26 für Validierungspunkte, bestimmt und definiert ist.
-
Am Ende des Tests ermittelt die Testumgebung die Punktzahl, die mit den Validierungspunkten für jede Testwiederholung verbunden ist. Ein Test kann als bestanden betrachtet werden, wenn die Punktzahl eines Testereignisses einen bestimmten Schwellenwert überschreitet. Der Test kann als fehlgeschlagen betrachtet werden, wenn ein KO-Validierungspunkt während eines der wiederholten Tests eingesammelt wurde. Es können gesamte Tests als fehlgeschlagen betrachtet werden, wenn etwas klar darauf hindeutet, dass der in dem getesteten Fahrzeug 22 implementierte Algorithmus nicht in der Lage ist, eine bestimmte Situation richtig zu behandeln.
-
Die maßgeschneiderte Bewertungsmethode bietet eine schnelle und einfache Möglichkeit, während des Entwicklungszyklus zu validieren, zu überprüfen und Hypothesen zu überprüfen.
-
Der Block 32 umfasst die virtuelle Realitätsschnittstelle (VR-Schnittstelle):
-
Diese ist die grafische Oberfläche, die es dem Benutzer ermöglicht, problemlos auf jedes Element des virtuellen Testszenarios zuzugreifen und die verschiedenen Variations-, Validierungs-, Antriebsbefehlspunkte zuzuordnen. Die Zuordnung kann erfolgen, indem man einen der Punkte auswählt und auf einem bestimmten Element der virtuellen Testdefinition positioniert. In einer bevorzugten Implementierung kann diese Aufgabe mittels einer virtuellen Realitätsschnittstelle (virtuelle Realitätsbrille, interaktive Holographie, haptische Handschuhe ...) durchgeführt werden, über die der Testdesigner mit der Welt der virtuellen Testdefinition verbunden ist. Die Verwendung von haptischen Handschuhen ermöglicht es dem Fahrer, die Punkte und die verschiedenen Elemente des virtuellen Testszenarios zu „berühren“. Sobald der Punkt positioniert ist, kann der Testdesigner ihn auswählen und ihn öffnen, um ihn zu konfigurieren (z. B. gibt er einen Wertebereich für ein Merkmal ein, definiert eine Punktzahl...). Das Öffnen eines Punktes kann z.B. durch Verwendung einer gewissen Geste auf dieses Element mit haptischen Handschuhen erfolgen. Sobald der Punkt geöffnet ist, kann der Testdesigner die zu verarbeitenden Eigenschaften aufheben und mit einer anderen Geste auf einen anderen bestimmten Wert oder auf einen anderen Bereich von Werten setzen. Das folgende Beispiel enthält einige Details zur Verwendung der VR-Schnittstelle. Dieses Verfahren kann auch auf einer herkömmlichen grafischen Oberfläche eines Desktop-Computers, eines Tablets oder dergleichen angewendet werden.
-
Beispiel: virtuelles Testen einer vollautomatischen Parkassistenz:
-
Im Beispiel möchte ein Entwicklungsteam eine Strategie für eine vollautomatisierte Parkassistenz auf Fahrzeugebene in einer frühen Phase des Projekts testen, in der noch kein physischer Prototyp und keine reale Testumgebung existiert.
-
Definition des virtuellen Testszenarios, siehe 2: Der Testdesigner erstellt aus einer Asset-Bibliothek für eine VR-Umgebung ein neues virtuelles Test-Szenario. Er stellt konkret folgende Elemente in die Test-Szene ein: Eine Straße 38, ein Bordstein 46, ein erstes, geparktes Fahrzeug 34, ein zweites geparktes Fahrzeug 36, einen Parkplatz 48, ein erstes Haus 40, ein zweites Haus 42 und ein drittes Haus 44. Weiterhin stellt er einen zu testendes Fahrzeug 22 ein und definiert zwei Grenzen 50, die jeweils den Abstand zwischen dem Parkplatz und den beiden geparkten Fahrzeugen 34, 36 darstellen. Sie werden später verwendet, um unterschiedliche individuelle Abstände zu den geparkten Fahrzeugen 34, 36 zu emulieren. Das Testszenario kann auf einem holographischen Tisch visualisiert werden.
-
Definition der Variationspunkte:
-
Der Designer ist daran interessiert, die Software für eine Vielzahl von Variationen zu überprüfen und zu validieren. Der Testdesigner ruft einzelne Variationspunkte in der VR-Welt auf und verknüpft sie mit dem gewünschten Element der Szene, siehe 3:
- - Ein Variationspunkt V1 ist der Straße 38 zugeordnet,
- - ein Variationspunkt V2 ist dem Bordstein 46 zugeordnet,
- - zwei Variationspunkte V3 und V4 sind den Grenzen 50 zugeordnet,
- - dem getesteten Fahrzeug 22 ist ein Variationspunkt V5 zugeordnet.
-
Jeden einzelnen dieser fünf Variationspunkte wählt der Testdesigner aus, er spezifiziert für die Variation folgende Merkmale:
- - V1: Der Straßengradient variiert von -15% bis +15% in Schritten von 1% (31x Kombinationen),
- - V2: die Höhe des Bordsteins 46 variiert von 0 cm bis 15 cm mit einem Schritt von 1 cm (16x Kombinationen),
- - V3 und V4: Die Grenzen 50 werden von einem Abstand von 20 cm (sehr eng) bis 100 cm (sehr groß) zu dem jeweiligen geparkten Fahrzeug 34 bzw. 36 mit einem Schritt von 10 cm (9x Kombinationen) gesetzt, damit ist der Platz vor und hinter dem auf dem Parkplatz 48 ein geparkten, getesteten Fahrzeug 22 bestimmt.
- - V5: Zuordnung von zwei verschiedenen Sätzen Parksensoren, von zwei unterschiedlichen Bremsverfahren, von drei unterschiedlichen Softwaren für Parkassistenz (insgesamt 16x Kombinationen).
-
Insgesamt ergeben sich damit insgesamt 31x16x9x16 = 71424 einzelne Tests, die durchgeführt werden sollen.
-
Definition der Validierungspunkte im Block 30:
-
Für die Beurteilung des Tests will der Designer sicherstellen, dass das getestete Fahrzeug 22 auf den Parkplatz einparkt, ohne die beiden geparkten Fahrzeuge 34, 36 und die umliegenden Häuser 40 - 44 zu berühren. Um eine dedizierte Bewertung zu ermöglichen, wird der Testdesigner folgende Validierungsmarkierungen zuweisen, siehe 4:
- - Einen KO-Validierungsmarker KO1 zu den Häusern 40 - 44,
- - ein KO-Validierungsmarker zu dem ersten (hinteren) geparkten Fahrzeug 34 (KO2),
- - einen KO-Validierungsmarker zu dem zweiten (vorderen) geparkten Fahrzeug 36 (KO3) und
- - einen positiven Validierungs-Marker zum Parkplatz 48, der mit einer Punktzahl von 1 verbunden ist. Jedes Mal, wenn das getestete Fahrzeug 22 in der Lage ist, korrekt auf den Parkplatz 48 zu gelangen, wird eine Punktzahl von 1 gewährt.
-
Darüber hinaus möchte der Testdesigner die Beschleunigung und ein eventuelles ruckweißes Fahren des getesteten Fahrzeugs 22 während des Manövers überprüfen und bestätigen, dass diese Parameter innerhalb einer vorgegebenen Toleranz liegen, die typisch für Fahrzeuge des betreffenden Herstellers ist oder durch andere Attribute definiert ist. Um dies zu ermöglichen, wird der Testdesigner alle anderen Verkehrs- und Komfortregeln außer den Komfortregeln, die mit Beschleunigung und Ruck verbunden sind, deaktivieren.
-
Definition der Art und Weise des Antriebs, also der Antriebsbefehlspunkte im Block 28, siehe Figur 5:
-
Es ist nur ein Startpunkt notwendig. Es wird davon ausgegangen, dass das getestete Fahrzeug 22 im Startpunkt angehalten ist. Der Startpunkt (SP1) wird dem getesteten Fahrzeug 22 zugewiesen. Dem getesteten Fahrzeug 22 wird auch ein Software-Aktivierungspunkt (SP2) zugeordnet. Dieser Software-Aktivierungspunkt enthält eine Information an das getestete Fahrzeug 22, die es diesem ermöglicht, anzufahren und das Parkassistenzsystem zu aktivieren.
-
Jedes Mal, wenn das System ein Manöver eines Einparkens beendet hat oder in einer Situation endet, wo es nichts mehr tun kann, wird der Test ausgewertet, gestoppt und der nächste Test beginnt.
-
Auswertung im Block 32:
-
Der Testdesigner kann nun die 71 424 Tests starten. Er kann die so tun, dass der entsprechende Computer z.B. über Nacht tätig ist. Das System führt automatisch alle Kombinationen aus, die durch mindestens einen Variationspunkt und mindestens einen Antriebsbefehlspunkt definiert sind. Die Laufzeit kann durch Entfernen einer mit dem getesteten Fahrzeug 22 verbundenen Variation optimiert werden, sobald die entsprechende Kombination einen KO-Punkt erzielt hat. Folgende Beurteilung kann aus dem oben beschriebenen Beispiel abgeleitet werden:
- - Wenn das getestete Fahrzeug 22 einen beliebigen KO-Punkt berührt, wird die zugehörige Variation des getesteten Fahrzeugs 22 als fehlgeschlagen betrachtet.
- - Als bestanden gilt, wenn das getestete Fahrzeug in jeder konkreten Variation den positiven Punkt, der mit dem Parkplatz verbunden ist, für jeden Testauftritt erreicht. Da es 16 Variationen gibt, die mit dem getesteten Fahrzeug 22 verbunden sind, bedeutet das, dass eine Punktzahl von 4464 erreicht werden soll. Andernfalls ist je nach Ergebnis eine Optimierung durchzuführen.
-
Mit dem Ergebnis kann das Entwicklungsteam nun bestimmte Parksensor-, Brems- und Strategiealgorithmen befürworten bzw. ausschließen.
-
Die Testumgebung umfasst Modelle jedes Teils des getesteten Fahrzeugs 22 (Sensoren, Aktoren ...) und befolgt die Gesetze der Physik. Es ist möglich, Steuerungssoftware mit dem getesteten Fahrzeug 22 zu verknüpfen. Die Testmethode wird nach den wissenschaftlichen Regeln der Spieltheorie durchgeführt.
-
Die Erfindung beschreibt Methoden zur praktischen Prüfung eines getesteten Fahrzeugs 22, das mit einer automatisierten Fahrsoftware ausgestattet ist, die mit folgenden Teilen implementiert ist, die in der virtuellen Testumgebung verwendet werden können:
- O Ein virtuelles Testszenario,
- O mindestens einen Variationspunkt oder Marker,
- O mindestens einen Validierungspunkt oder Marker,
- O mindestens ein Antriebsbefehlspunkt oder Marker,
- O eine Bewertungsmethode, die sich vorzugsweise auf ein Scoring bezieht, und
- O eine virtuelle Realitätsumgebung, die es erlaubt, den Test zu definieren
Die Erfindung beschreibt weiterhin Methoden und Algorithmen zur Festlegung des virtuellen Testszenarios, dabei umfasst das Testszenario
- - mindestens einen aktiven virtuellen Verkehrsteilnehmer,
- - mindestens einen passiven Verkehrsteilnehmer und
- - eine virtuelle Testumgebung, erhalten aus einer Bibliothek.
Ein Variationspunkt ist ein Element der VR-Umgebung, das mit jedem Objekt des virtuellen Testszenarios verknüpft werden kann. Ein Variationspunkt ermöglicht den Zugriff auf Merkmale oder Eigenschaften des Testszenariumsobjekts, dem es zugeordnet wurde. Ein Variationspunkt erlaubt es, einen Wert oder einen Wertbereich für mindestens eine der Eigenschaften des Testszenariumsobjekts zu definieren bzw. festzulegen, mit dem er assoziiert wurde. Mehrere Variationspunkte können mit einem Objekt verknüpft werden. In einer bevorzugten Ausführungsform wird der Variationspunkt oder Marker mittels einer VR-Umgebung positioniert.
-
Eine Eigenschaft, auf die durch einen Variationspunkt zugegriffen werden kann, ist ein Steuerungsalgorithmus, ein Parameterwert, ein Modell, ein Stück Code ...
-
Ein Validierungspunkt ist ein Element der VR-Umgebung, das mit jedem Objekt des virtuellen Testszenarios verknüpft werden kann. Ein Validierungspunkt ist ein Element, das vom getesteten Fahrzeug 22 gesammelt werden kann, bei Kontakt zwischen dem getesteten Fahrzeug 22 und dem Validierungspunkt zugeordneten Element. Dies kann entweder sobald der Kontakt hergestellt ist oder für eine gewisse Dauer des Kontaktes gelten. Ein Validierungspunkt kann ein positiver Validierungspunkt sein, der mit einer positiven Punktzahl assoziiert ist, um ein Element anzuzeigen, mit dem getesteten Fahrzeug 22 interagieren soll. Ein Validierungspunkt kann ein negativer Validierungspunkt sein, der mit einer negativen Punktzahl verbunden ist, um ein Element anzugeben, dem das getestete Fahrzeug 22 nicht zu nahekommen sollte bzw. mit dem das getestete Fahrzeug 22 nicht kritisch interagieren sollte. Ein Validierungspunkt kann ein KO-Validierungspunkt sein, der ein Element angibt, mit dem das getestete Fahrzeug 22 niemals interagieren darf, andernfalls wird der gesamte Test als fehlgeschlagen betrachtet. Ein Validierungspunkt wird vom Testsystem verwendet, um die Tests zu beurteilen.
-
Ein Antriebsbefehlspunkt ist ein Element der VR-Umgebung, das an jedem beliebigen Standort des virtuellen Testszenarios und insbesondere auf einem Testumgebungselement (Straße 38, Bordstein 46...) positioniert oder mit einem Element des virtuellen Testszenarios verknüpft werden kann. Ein Antriebsbefehlspunkt kann mindestens ein Ausgangspunkt für das getestete Fahrzeug 22 sein. Ein Antriebsbefehlspunkt bzw. Fahranweisungspunkt kann mindestens ein Streckenpunkt sein, den das getestete Fahrzeug 22 erreichen soll. Ein Antriebsbefehlspunkt kann mindestens ein Software-Aktivierungspunkt oder Ereignisaktivierungspunkt sein, der mit einem Element des virtuellen Testszenarios verknüpft ist, was anzeigt, dass eine bestimmte Software, Parameter, Aktor, Strategie ... dieses Elements aktiviert werden soll (z.B. Assistent für Einparken). Ein Antriebsbefehlspunkt kann mit einer gewissen Aktivierungswahrscheinlichkeit verbunden sein und/oder mit einer zeitlichen Verzögerung einsetzen.
-
Eine Bewertungsmethode besteht darin, die mit den Validierungspunkten verbundene Punktzahl zu zählen und auszugeben. Eine Bewertungsmethode besteht darin, das Auftreten von KO-Validierungspunkten zu überwachen. Wenn ein KO-Punkt erhalten wird, werden die gesamten Testvariationen, die mit der Konfiguration des zu prüfenden Fahrzeugs verbunden sind, als fehlgeschlagen betrachtet, und verbleibende Tests, die mit der gleichen Konfiguration verbunden sind, können vom System übersprungen werden. Eine Bewertungsmethode besteht darin, die Punktzahl pro Konfiguration des zu prüfenden Gegenstandes zu zählen und auszugeben. Die Bewertung kann eine Normalisierung über die Anzahl der Tests, über die Anzahl der Tests mit einer bestimmten Konfiguration des geprüften Fahrzeugs 22 vorsehen.
-
Eine Bewertungsmethode besteht darin, eine Klassifikation der Verkehrsregeln und der zugehörigen Punktzahl zu definieren. Dieser Regelkatalog ist generisch und kann dann für jede Art von Test wiederverwendet werden und könnte Teil eines Standards sein, der für jeden Fahrzeughersteller zur Verfügung steht. Es ist möglich, zu konfigurieren, welche Regel für einen Test beurteilt werden soll oder nicht.
-
Eine Beurteilungsmethode besteht darin, eine Klassifikation von „Komfortregeln“ und damit verbundener Punktzahl zu definieren. Dieser Katalog ist generisch und kann für jede Art von Test verwendet werden. Er ist in der Regel für jeden Fahrzeughersteller spezifisch, da ein bestimmtes Fahrgefühl und Verhalten vom Hersteller spezifiziert sind. Es ist möglich, auszuwählen, welche Regel für eine Prüfung nicht berücksichtigt werden soll.
-
Unter Definition wird das Eingeben eines Wertes, das Festsetzen bzw. Auswählen eines Parameters verstanden.
-
Die Anmelderin behält sich vor, Merkmale aus Sätzen der Beschreibung, auch aus Teilen der Sätze, sowie aus Ansprüchen, hier auch einzelne Merkmale aus Ansprüchen, beliebig miteinander zu kombinieren. Diese Kombination kann auch unabhängig sein von den Merkmalen der unabhängigen und abhängigen Ansprüche.
-
Bezugszeichenliste
-
- 20
- Block für virtuelles Testszenarium
- 22
- getestetes Fahrzeug
- 24
- Block für Variationspunkte
- 26
- Block für Validierungspunkte
- 28
- Block für Antriebsbefehlspunkte
- 30
- Block für Validierungs- und Verifikationsmethode, Bewertung
- 32
- Block für virtuelle Realitätsschnittstelle
- 34
- erstes geparktes Fahrzeug
- 36
- zweites geparktes Fahrzeug
- 38
- Straße
- 40
- erstes Haus
- 42
- zweites Haus
- 44
- drittes Haus
- 46
- Bordstein
- 48
- Parkstreifen, Parkplatz
- 50
- Grenze
-
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 102011088807 A1 [0005]
- DE 102008027509 A1 [0006]
