-
Die Erfindung betrifft ein computerimplementiertes Verfahren zum Bereitstellen einer Datenstruktur für die Streckenkomplexitätserfassung, die Entwicklung und Validierung von Funktionalitäten eines automatisierten Fahrsystems, eine derartige Datenstruktur, einen Computer zum Validieren von Funktionalitäten eines automatisierten Fahrsystems, ein Computerprogramm zum Bereitstellen einer derartigen Datenstruktur und einen computerlesbaren Datenträger.
-
In Staplin, L., Mastromatto, T., Lococo, K. H., Kenneth W. Gish, K. W., & Brooks, J. O. (2018, September), „The effects of medical conditions on driving performance" (Report No. DOT HS 812 623), Washington, DC: National Highway Traffic Safety Administration ist ein Konzept zur Validierung von Funktionalitäten eines automatisierten Fahrsystems offenbart.
-
In Koopman P., Fratrik F., „How Many Operational Desgin Domains, Objects, and Events?", Preprint: Safe AI 2019: AAAI Workshop on Artificial Intelligence Safety, Jan 27, 2019, sind Faktoren offenbart, die aus Sicht der Autoren relevant für die Validierung von automatisierten Fahrsystemen sind.
-
Die im Folgenden eingeführten Begriffe behalten ihre jeweilige Bedeutung für den gesamten Gegenstand der Erfindung.
-
In dem bekannten und aktuellen Stand der Technik werden zur Streckenkomplexitätserfassung, Entwicklung und Validierung von automatisierten Fahrsystemen Strecken, die das automatisierte Fahrsystem automatisiert fahren soll, aufgenommen. In den Aufnahmen werden die Betriebsfunktionen, im Englischen operational design domains, abgekürzt ODD, genannt, die Überwachung des Fahrumfeldes, im Englischen object and event detection and response, abgekürzt OEDR, genannt, die Trajektorienplanung, im Englischen maneuver behavior genannt, und die Systemfehler, im Englischen failure mode behaviors genannt, und deren jeweiligen Atrribute auf den Strecken für die Kompelxitätsbeschreibung händisch beschrieben und händisch kategorisiert, beispielsweise in Tabellen erfasst. Das automatisierte Fahrsystem wird derart ausgelegt, dass es für diese ODDs, OEDRs, maneuver behavior und failure mode behaviors funktioniert.
-
Problematisch dabei ist, dass diese händische Vorgehensweise nicht skalierbar ist. Alle vergangenen Strecken und jede zukünftige Strecke werden händisch mit bekannten und neuen Attributen strukturiert und gleichzeitig gegen die vorhandenen Systemfähigkeiten abgeglichen. Dies ist nicht effizient.
-
Aufgabe der Erfindung war es, wie Strecken, die ein automatisiertes Fahrsystem automatisiert fahren soll, gegenüber dem Stand der Technik effizienter bewertet und/oder abgeglichen werden können hinsichtlich des Streckenkomplexitätsgrad und der bis dahin durchgeführten Validierung des automatisierten Fahrsystems.
-
Die Erfindung löst diese Aufgabe durch eine Software und eine Datenbank, wobei die Software neue Attribute in jeweils zugeordnete Klassen der Datenbank automatisiert aufnimmt.
-
Gemäß einem Aspekt stellt die Erfindung ein computerimplementiertes Verfahren bereit. Das Verfahren stellt eine Datenstruktur für Streckenkomplexitätserfassung und Validierung von Funktionalitäten eines automatisierten Fahrsystems bereit oder eine derartige Datenstruktur wird durch Ausführen des Verfahrens erhalten. Die Datenstruktur ist in einem Datenspeicher enthalten. Die Datenstruktur umfasst mehrere Objektklassen, Hauptklassen und Unterklassen, für deren Objekte und/oder Objektattribute das Fahrsystem jeweils entwickelt und validiert ist. Die Objekte und/oder Objektattribute sind mittels einer Indexstruktur identifiziert. Wenigstens eine erste Objektklasse bildet Betriebsfunktionen des automatisierten Fahrsystems ab. Wenigstens eine zweite Objektklasse bildet Überwachung des Fahrumfeldes ab. Wenigstens eine dritte Objektklasse bildet Trajektorienplanung ab. Wenigstens eine vierte Objektklasse bildet Systemfehler ab. Die erste Objektklasse umfasst wenigstens eine erste Hauptklasse, wobei die erste Hauptklasse eine Infrastruktur abbildet und die erste Hauptklasse wenigstens eine erste Unterklasse umfasst, wobei die erste Unterklasse Straßengeometrien abbildet. Die zweite Objektklasse umfasst wenigstens eine zweite Hauptklasse, wobei die zweite Hauptklasse Objektdetektierung und Reaktion auf die Objektdetektierung abbildet und die zweite Hauptklasse wenigstens eine zweite Unterklasse umfasst, wobei die zweite Unterklasse Detektierung und Reaktion auf Geschwindigkeitsbegrenzungen abbildet. Die dritte Objektklasse umfasst wenigstens eine dritte Hauptklasse, wobei die dritte Hauptklasse Fahrverhalten abbildet und die dritte Hauptklasse wenigstens eine dritte Unterklasse umfasst, wobei die dritte Unterklasse Spurwechsel abbildet. Die vierte Objektklasse umfasst wenigstens eine vierte Hauptklasse, wobei die vierte Hauptklasse Sensorfehler abbildet und die vierte Hauptklasse wenigstens eine vierte Unterklasse umfasst, wobei die vierte Unterklasse Stromausfall abbildet. Die Indexstruktur identifiziert die Objekte und/oder Objektattribute mittels einer derartigen Klassenhierarchie. Das Verfahren umfassend die Schritte
- • Erhalten eines Objekts und/oder Objektattributs und Indexieren des Objekts und/oder Objektattributs basierend auf der Indexstruktur,
- • Abfragen der Datenstruktur nach Vorhandensein des Objekts und/oder Objektattributs mittels der Indexstruktur,
- • Speichern des Objekts und/oder Objektattributs in der von der Indexstruktur abhängigen Klasse, falls die Abfrage negativ ausfällt, und Bereitstellen des Objekts und/oder Objektattributs zur Validierung des Fahrsystems oder
- • Bereitstellen der Information, dass das Fahrsystem für dieses Objekt und/oder Objektattribut entwickelt und validiert ist, falls die Abfrage positiv ausfällt.
-
Computerimplementiert bedeutet, dass der jeweilige Gegenstand mit einer programmierbaren Vorrichtung, beispielsweise Computer oder Computernetze, realisiert wird. Bei einem computerimplementierten Verfahren werden Schritte des Verfahrens von einem Computer ausgeführt.
-
Die Datenstruktur dient der Speicherung und Organisation der Objekte und/oder Objektattribute. Beispielsweise werden in Aufnahmen eines Fahrzeug-Umfelderkennungssensors, beispielsweise Videoaufnahmen einer Kamera, Punktewolken eines Radars und/oder Lidars oder Cepstrum eines Akustiksensors, Spurmarkierungen, Verkehrsschilder, Fußgänger und weitere Verkehrteilnehmer erkannt, klassifiziert, lokalisiert und semantisch segmentiert. Die Segmentierungen werden in der Datenstruktur als Objekte gespeichert und organisiert. Damit wird vorteilhafterweise die Grundstruktur der Datenstruktur an der Struktur des Umfeldes des Fahrzeuges ausgerichtet. Die Objekte der Datenstruktur entsprechen den Objekten der objektorientierten Programmierung, das heißt auf die Objekte der Datenstruktur wird beispielsweise mittels Methoden zugegriffen. Nach einem Aspekt der Erfindung umfasst die Datenstruktur eine Programmierschnittstelle, im Englischen application programming interface, abgekürzt API, genannt, beispielsweise eine C++ API, um die Objekte der Datenstruktur basierend auf der Indexstruktur mittels Methoden abzufragen.
-
Validierung bezieht sich auf die Prüfung von Funktionalitäten eines automatisierten Fahrsystems bezogen auf einen konkreten Einsatzzweck. Die Prüfung erfolgt auf Grundlage eines vorher aufgestellten Anforderungsprofils. Beispielsweise wird eine Strecke, die das automatisierte Fahrsystem bei Tag automatisiert fahren soll, zunächst bei Tag von einem Fahrzeug, das von einem menschlichen Fahrer gefahren wird, abgefahren. Dabei wird die Strecke beispielsweise per Video aufgezeichnet. Diese Aufzeichnung wird nun analysiert hinsichtlich möglichen Anforderungen, die das automatisierte Fahrsystem auf dieser Strecke erfüllen muss. Beispielsweise umfasst die Strecke einen Kreisverkehr. Eine Anforderung an das automatisierte Fahrsystem ist dann beispielsweise, einen Kreisverkehr zu erkennen, beispielsweise die entsprechenden Verkehrszeichen, in einen Kreisverkehr einzufahren und auszufahren unter Beachtung der geltenden Verkehrsvorschriften. Ein Steuerungssystem umfassend Algorithmen zur Umfelderkennung, Trajektorienplanung und zum Ableiten von Regel- und/oder Steuerungssignalen und Aktuatoren für Längs- und/oder Querführung des automatisierten Fahrsystems wird davon ausgehend programmiert und konzipiert, für den Einsatzzweck des Fahrens bei Tag auf dieser Strecke die Fahraufgabe des Fahrens durch den Kreisverkehr zu erfüllen. In der Validierung wird geprüft, ob das automatisierte Fahrsystem für diesen Einsatzzweck diese Fahraufgabe erfüllt.
-
Ein automatisiertes Fahrsystem umfasst zumindest eine Umfelderkennungseinheit, die das Umfeld wahrnimmt, eine Steuereinheit, die ausgehend von der Umfeldwahrnehmung Längs- und/oder Querführung des Fahrsystems regelt und/oder steuert und Trajektorien prädiziert, und Aktuatoren, die in Abhängigkeit von Regel- und/oder Steuerungssignalen der Steuereinheit die Längs- und/oder Querführung des Fahrsystems steuern. Ein automatisiertes Fahrsystem ist beispielsweise ein PKW, LKW, Bus, people mover, ein Personal oder Group Rapid Transit System oder eine Drohne mit entsprechender technischer Ausrüstung zur Automatisierung der Fahraufgaben. Automatisierungsstufen werden beispielsweise nach der SAE J 3016 Norm eingeteilt, die von Stufe L0, das heißt keine Automation, bis hin zu Stufe L5, das heißt Vollautomation oder auch autonomes Fahren, reicht.
-
Funktionalitäten des Fahrsystems betreffen bestimme Fahraufgaben bei einer entsprechenden Automatisierungsstufe. Eine Funktionalität ist beispielsweise eine L3, das heißt bedingt automatisierte, Autobahnfahrt. Bei L3 übernimmt die Längs- und Querführung und die Umgebungsbeobachtung das Fahrsystem, der menschliche Fahrer bleibt aber Rückfallebene. Verschiedene Funktionalitäten müssen für die gleiche Fahraufgabe unterschiedlich validiert werden. Bei dem Ereignis, dass ein vorausfahrendes Fahrzeug am Abbremsen ist, wird von einem L2+ Fahrsystem beispielsweise verlangt, dem vorausfahrenden Fahrzeug zunächst zu folgen, abzubremsen, und anzuhalten. Für das gleiche Ereignis wird von einem L4 Fahrsystem verlangt, dem vorausfahrenden Fahrzeug zunächst zu folgen, abzubremsen, ggf. anzuhalten, Spur zu wechseln und vorbeizufahren. Bei L4 übernimmt die Längs- und Querführung, die Umgebungsbeobachtung und die Rückfallebene das Fahrsystem und nicht der Fahrer
-
In den Klassen sind die Objekte und deren Attribute festgelegt. Durch die Klassenhierarchie der Objektklassen, Hauptklassen und Unterklassen ist die Datenstruktur als eine objektorientierte Datenstruktur realisiert. Ein weiterer Vorteil einer objektorientierten Datenstruktur ist, dass die Objekte einfach über die in der Indexstruktur enthaltenen Beziehungen der Objekte abgefragt werden. Durch die Indexstruktur, die die Klassenhierarchie abbildet und mittels der die Objekte in der Datenstruktur gesucht werden, sind ferner semantische Zusammenhänge zwischen den Objekten bekannt. Die Datenstruktur hat damit ein Verständnis darüber, welche Daten oder Objekte zusammengehören. Bei einer Abfrage werden keine Datensätze, sondern vorteilhafterweise einzelne Objekte erhalten.
-
Die erste Objektklasse beschreibt die Betriebsfunktionen, das heißt die ODDs. Hauptklassen für ODDs umfassen Infrastruktur, Betriebsbedingungen, Objekte, Konnektivität und Umweltbedingungen. Unterklassen der Infrastruktur umfassen beispielsweise Straßengeometrie, Straßenoberflächen, Straßenarten, Straßenmarkierungen, auch länderspezifische Straßenmarkierungen. Objektattribute für Straßengeometrien umfassen Kurve, Hügel, geradlinig, Spurbreite. Objektattribute für Straßenoberflächen umfassen Asphalt, Beton, Mischung, Kies, befestigt, nicht befestigt, Gras, Verschmutzungsgrad, Reibwert. Objektattribute für Straßenarten umfassen Autobahn, Bundesstraße, Landstraße, Brücke, Tunnels, jeweils mehr- oder einspurig, Kreuzungen, Kreisverkehre, Spurzusammenführungen, Straßenüberquerungen. Objektattribute für Straßenmarkierungen umfassen Spurmarkierungen, Fahrbahnmarkierungen. Unterklassen der Konnektivität umfassen V2V und V2X Kommunikation. Objektattribute für V2V und/oder V2X Kommunikation umfassen Kommunikationsprotokolle, Bandbreite, Latenzzeiten, Stabilität, Verfügbarkeit. Als ein weiteres Beispiel umfassen Unterklassen der Umweltbedingungen Wetter, Beleuchtung und Wetter bedingte Straßenbedingungen. Objektattribute für Wetter umfassen Schnee, Wind, Temperatur und Regen. Objektattribute für Regen umfassen Nieselregen, Durchschnittsregen und Starkregen. Objektattribute für Beleuchtung umfassen Tag, Dämmerung, Nacht, Straßenbeleuchtung, Fahrzeugleuchten. Objektattribute für Wetter bedingte Straßenbedingungen umfassen trocken, nass, vereist.
-
Die zweite Objektklasse beschreibt die Überwachung des Fahrumfeldes, das heißt die OEDRs. Hauptklassen für OEDRS umfassen beispielsweise Objektdetektierung, Ereignisdetektierung, Erkennung, Klassifikation und Reaktion auf die Objekt- und/oder Ereignisdetektierung. Unterklassen der Objektdetektierung umfassen Detektierung von Fahrzeugen, Fußgängern, Fahrradfahrern, Tieren, Verkehrszeichen, Baustellen und Spuränderungen. Objektattribute von Fahrzeugen umfassen Passagierfahrzeuge, Nutzfahrzeuge, Lastfahrzeuge, Busse, Motorräder. Objektattribute von Verkehrszeichen umfassen minimale Geschwindigkeitsbegrenzung, maximale Geschwindigkeitsbegrenzung, Stopp-Schilder, Bahnüberquerungen. Unterklassen der Ereignisdetektierung umfassen Abbremsen oder Beschleunigen eines vorausfahrenden Fahrzeuges, Überqueren einer Straße eines Fußgängers. Unterklassen der Reaktionen umfassen Ausführen einer Verfolgung eines vorausfahrenden Fahrzeuges.
-
Die dritte Objektklasse beschreibt die Trajektorienplanung, das heißt maneuver behavior. Hauptklassen der Trajektorienplanung umfassen Fahrverhalten. Unterklassen des Fahrverhaltens umfassen Parken, Geschwindigkeit Halten, Fahrzeug Folgen, in der Spur Fahren, Spurwechsel, einem Hindernis ausweichen, Verkehrsregeln Beachten, Kreisverkehre Navigieren und Routenplanung.
-
Die vierte Objektklasse beschreibt Systemfehler, das heißt failure mode behaviors. Hauptklassen der Systemfehler umfassen z.B. Sensorfehler, Kommunikationsfehler, Wahrnehmungsfehler, Fehler in Navigation und Regelung und/oder Steuerung, Fehler in Mensch-Maschinen-Benutzungsschnittstellen. Hinsichtlich Sensorfehler sind Fehler betreffend die funktionale Sicherheit nach ISO 2626.2 umfasst. Hinsichtlich Wahrnehmungsfehler sind Fehler betreffend die safety of the intended functions nach ISO/PAS 21448 umfasst. Unterklassen der Sensorfehler umfassen Hardware- und Softwarefehler, beispielsweise Stromausfall, Ausfall einer Datenverbindung. Sensoren umfassen Radar, Lidar, Kamera, Schall, GPS, Beschleunigungssensoren, Radsensoren. Unterklassen der Wahrnehmungsfehler umfassen Softwarefehler von Algorithmen zum Prozessieren von Daten und zur Bilderkennung. Unterklassen der Fehler in Mensch-Maschinen-Benutzungsschnittstellen, auch human machine interface, abgekürzt HMI, genannt, umfassen Fehler in optischen Anzeigevorrichtungen. Die Systemfehler einzelner Komponenten des Fahrsystems, beispielsweise Fehler des Perzeptionssystems, pflanzen sich auf andere Komponenten und das Gesamtsystem fort, beispielsweise das Antriebssystem. Die Systemfehler resultieren in einer suboptimalen Performanz des Fahrsystems, beispielsweise fährt das Fahrsystem langsamer als erlaubt basierend auf einem Wahrnehmungsfehler eines Geschwindigkeitsschildes, oder das Fahrsystem führt unerwartete oder unsichere Manöver aus, beispielsweise plötzliches Beschleunigen oder Verlassen der Fahrspur, oder es kommt zu Kollisionen. Diese Fehler werden während Fahrten aufgezeichnet und/oder in Simulationen modelliert und gehen in die Validierung ein. Beispielsweise werden Sensorrauschen oder Hardwarefehler modelliert. Auf die die Fehler wird mit fail-safe und/oder fail-operational Verfahren reagiert. Das validierte Fahrsystem wird auf die Fehler situationsbedingt mit fail-safe oder fail-operational reagieren. Fail-safe ist beispielsweise ein Sicherheitsstopp. Fail-operational ist beispielsweise Fahren mit verringerter Maximalgeschwindigkeit.
-
Ein Szenario, für die das Fahrsystem beispielsweise validiert wird, ist Erkennung und Reaktion auf einen Schulbus. Die ODD Kennzeichen umfassen beispielsweise mehrspurige Fahrbahnen, Asphalt als Straßenoberfläche, Spurmarkierungen, Tageslicht, trockenes, sonniges Wetter. Die OEDR Kennzeichen umfassen als Objekte Schulbusse. Vereinfacht wird kein Fehlverhalten angenommen. Während einer Testfahrt auf einer ersten Strecke wurden in der ersten Objektklasse der Datenstruktur bereits in die erste Hauptklasse der Infrastruktur die Attribute geradlinige Fahrspur, keine Steigung aufgenommen. Werden nun während einer Testfahrt auf einer zweiten Strecke enge Kurven gefahren, lautet einen Abfrage basierend auf der Indexstruktur der Datenbank beispielsweise:
| SELECT ODD.Infrastructure | /*Hauptklasse Infrastruktur der Objektklasse ODD wählen*/ |
| FROM Infrastructure in DATA | /*Durchlauf aller Objekte/Objektattribute in der Hauptklasse Infrastrukttur*/ |
| IF narrow bends IN DATA THEN OUTPUT Object is in DATA | /*Abfrage positiv, dann Bereitstellen der Information, dass das Fahrsystem für dieses Objekt und/oder Objektattribut validiert ist */ |
| ELSE SAFE narrow bends IN DATA WITH ODD.Infrastructure.narrow_bends | /*Abfrage negativ, dann Speichern des Objekts und/oder Objektattributs in der von der Indexstruktur abhängigen Klasse*/ |
-
Die Indexstruktur wird beispielsweise mit einer Abfragesprache für Objektdatenbanken erzeugt. Die Abfragesprache basiert beispielsweise auf object querry language.
-
Über diese Abfragen werden gegebenenfalls auch neue Hauptklassen und/oder Unterklassen angelegt. Damit ist die Datenstruktur skalierbar.
-
Gemäß einem weiteren Aspekt stellt die Erfindung eine computerimplementierte Datenstruktur für die Streckenkomplexitätserfassung und Validierung von Funktionalitäten eines automatisierten Fahrsystems bereit. Die Datenstruktur entspricht der Datenstruktur, die oben im Rahmen des erfindungsgemäßen Verfahrens beschrieben wurde. Die Indexstruktur identifiziert die Objekte und/oder Objektattribute mittels der Klassenhierarchie der Datenstruktur. Die Datenstruktur wird nach dem erfindungsgemäßen Verfahren bereitgestellt.
-
Computerimplementiert bedeutet, dass die Datenstruktur mittels eines Computers erhalten, bereitgestellt und/oder organisiert wird.
-
Gemäß einem weiteren Aspekt stellt die Erfindung einen Computer bereit zum Streckenkomplexitätserfassung und Validieren von Funktionalitäten eines automatisierten Fahrsystems. Der Computer umfasst eine erste Schnittstelle, über die der Computer Objekte und/oder Objektattribute aus aufgezeichneten Fahrten oder in Echtzeit während Fahrten von wenigstens einem automatisierten Fahrsystemen oder einer handelsüblichen Kamera erhält. Ferner umfasst der Computer eine Verarbeitungseinheit, mittels der die Objekte und/oder Objektattribute gemäß dem erfindungsgemäßen Verfahren mit einer Indexstruktur indexiert werden. Außerdem umfasst der Computer eine zweite Schnittstelle zu einer erfindungsgemäßen Datenstruktur, über die der Computer die Datenstruktur nach Vorhandensein der Objekte und/oder Objektattribute abfragt und die Objekte und/oder Objektattribute in einer von der Indexstruktur abhängigen Klasse der Datenstruktur speichert, falls die Abfrage negativ ausfällt. Des Weiteren umfasst der Computer eine dritte Schnittstelle, um im Falle der negativen Abfrage die Objekte und/oder Objektattribute zur Entwicklung und Validierung des Fahrsystems bereitzustellen oder, im Falle einer positiven Abfrage, die Information bereitzustellen, dass das Fahrsystem für diese Objekte und/oder Objektattribute validiert ist.
-
Die Verarbeitungseinheit des Computers umfasst einen oder mehrere Zentralprozessoreinheiten, einen oder mehrere Grafikprozessoren und/oder weitere integrierte Schaltkreise.
-
Nach einem Aspekt der Erfindung ist der Computer ein Computer einer Entwicklungsumgebung. Der Computer ist beispielsweise ausgeführt als ein Personalcomputer, abgekürzt PC. Nach einem weiteren Aspekt der Erfindung ist der Computer ein Rechenzentrum. Das Rechenzentrum wird beispielsweise von einem Flottenbetreiber einer Flotte von automatisierten Fahrsystemen, beispielsweise people movern, genutzt.
-
Im Falle der in Echtzeit während Fahrten erhaltenen Objekte und/oder Objektattribute ist die erste Schnittstelle eine Schnittstelle zu Sensoren des Fahrsystems für Umfeldperzeption. Die zweite Schnittstelle ist beispielsweise kabelgebunden, beispielsweise für den Fall, dass die Datenstruktur in einem lokalen Speicher des PCs gespeichert ist. Falls die Datenstruktur in einem Cloud-Speicher gespeichert ist, ist die zweite Schnittstelle eine Funkschnittstelle, beispielsweise basierend auf WLAN Technologie. Die zweite Schnittstelle ist nach einem Aspekt der Erfindung bidirektional.
-
Gemäß einem weiteren Aspekt stellt die Erfindung ein Computerprogramm bereit zum Bereitstellen einer erfindungsgemäßen Datenstruktur. Das Computerprogramm umfasst Befehle, die bewirken, dass ein Computer ein erfindungsgemäßes Verfahren ausführt, wenn das Programm auf dem Computer läuft.
-
Nach einem Aspekt der Erfindung führt der erfindungsgemäße Computer das Computerprogramm aus.
-
Die Befehle sind Programminstruktionen und in einer prozessualen Programmiersprache, beispielsweise C, oder objektorientierten Programmiersprache, beispielsweise C++, geschrieben. Das Computerprogramm liegt als Quellcode in der jeweiligen Programmiersprache oder als Maschinencode vor. Die Attributierung kann ebenfalls über einen Computer im offline Betrieb außerhalb des Fahrzeuges mit einem Offline Programm durchgeführt werden, um eine Datenbank zu befüllen.
-
Gemäß einem weiteren Aspekt stellt die Erfindung einen computerlesbarer Datenträger bereit, auf dem eine erfindungsgemäße Datenstruktur und/oder das erfindungsgemäße Computerprogramm gespeichert sind.
-
Nach einem Aspekt der Erfindung ist der Datenträger ein digitales Medium, beispielsweise eine DVD oder Blue-ray Disc oder ein nicht-flüchtiger Halbleiterspeicher, beispielsweise ein Flash-Speicher.
-
Ein Aspekt der Erfindung betrifft das Anbieten des erfindungsgemäßen Verfahrens, der erfindungsgemäßen Datenstruktur, des erfindungsgemäßen Computers, Computerprogramms und/oder des erfindungsgemäßen Datenträgers an Kunden, die ein automatisiertes Fahrsystem oder zum Validieren des Fahrsystems erforderliche Strecken, real oder virtuell, fordern. Falls die Kundenanforderung auf der erfindungsgemäße Klassenhierarchie basiert, wird die Kundenanforderung erfindungsgemäß sehr schnell gegen die von der erfindungsgemäßen Datenstruktur schon abgebildeten Objekte und/oder Objektattribute abgeglichen. Die nicht von der Datenstruktur behandelten Objekte und/oder Objektattribute werden schnell transparent dargestellt, nämlich mittels einer Abfrage der Datenstruktur basierend auf der Indexstruktur. Damit sind Aufwände besser kalkulierbar. Ferner werden nach einem Aspekt der Erfindung die geforderten Objekte und/oder Objektattribute mit den zu entwickelnden Eigenschaften des Fahrsystems gegenübergestellt, um die technische Machbarkeit zu prüfen und das zukünftige Portfolio der zu entwickelnden Eigenschaften des automatisierten Fahrsystems zu definieren.
-
Weitere Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen, den Zeichnungen und der Beschreibung bevorzugter Ausführungsbeispiele.
-
In einer Ausgestaltung der Erfindung werden die Objekte und/oder Objektattribute in der Klassenhierarchie vererbt. Beispielsweise umfasst die Klasse Wetter die Objektattribute leicht und moderat. Die Unterklassen Regen und Schnee erben dann die Objektattribute leicht und moderat. Regen ergänzt noch stark. Mittels Vererbung werden aufbauend auf existierenden Klassen neue Klassen geschaffen und die Beziehungen zwischen ursprünglicher und neuer Klasse dauerhaft beibehalten. Dies erleichtert den Zugriff auf die Objekte in der Datenbank mittels der Indexstruktur.
-
In einer weiteren Ausgestaltung der Erfindung werden einzelne Objektattribute permutiert oder kombiniert werden und diese Permutationen oder Kombinationen dem Fahrsystem simuliert. Nach einem Aspekt der Erfindung werden die weiter oben beschriebenen erste, zweite, dritte und vierte Objektklasse, Objekte der Haupt- oder Unterklassen dieser Objektklassen und die jeweiligen Objektattribute permutiert oder kombiniert. Während einer Testfahrt werden immer nur eine jeweils spezielle ODD, OEDR, maneuver behavior oder failure mode behaviors und deren jeweilige Kombination eingefahren. Die Datenstruktur umfasst aber Objekte und/oder Objektattribute aus mehreren Testfahrten. Beispielsweise wurde eine erste Testfahrt bei Tag auf gerader Fahrbahn gefahren und Elemente der ODD und OEDR bestimmt. Eine zweite Testfahrt wurde bei Nacht auf einer Kurvenfahrt bei vereister Fahrbahnoberfläche gefahren und Elemente der ODD und OEDR bestimmt. Mit den während der ersten Testfahrt erhaltenen Objekten und /oder Objektattributen kann das Fahrsystem nicht für Kurvenfahrten auf vereister Fahrbahnoberfläche validiert werden. Mit den während der zweiten Testfahrt erhaltenen Objekten und/oder Objektattributen kann das Fahrsystem nicht für geradlinige Fahrten bei Tag validiert werden. Die Datenstruktur umfasst die während der ersten und der zweiten Testfahrt erhaltenen Objekte und/oder Objektattribute. Eine Kombination ergibt dann eine simulierte Testfahrt umfassend geradlinige Abschnitte bei Tag und Kurvenabschnitte bei Nacht und vereister Fahrbahnoberfläche. Eine einzige reale Testfahrt, auf der sowohl geradlinige Abschnitte bei Tag und Kurvenabschnitte bei Nacht und vereister Fahrbahnoberfläche vorherrschen, ist vergleichsweise unwahrscheinlich und wird in der Regel erst nach mehreren Testkilometern erreicht. Durch die Permutation oder Kombination werden damit vorteilhafterweise Testkilometer eingespart.
-
Nach einem Aspekt der Erfindung werden das Objekt und/oder das Objektattribut aus aufgezeichneten Fahrten oder in Echtzeit während Fahrten des Fahrsystems erhalten. Damit ist das Verfahren in einem offline Modus oder in einem online Modus während Fahrten betreibbar.
-
Nach einem weiteren Aspekt der Erfindung werden die Objekte und/oder die Objektattributs aus aufgezeichneten Fahrten oder in Echtzeit während Fahrten von mehreren Fahrsystemen erhalten. Damit werden in einer limitierten Zeit mehr Daten erhalten als mit nur einem Fahrsystem. Die mehreren Fahrsysteme sind nach einem Aspekt der Erfindung unabhängig voneinander. Nach einem weiteren Aspekt der Erfindung umfassen die mehreren Fahrsysteme den gleichen Fahrzeugaufbau und/oder das gleiche Sensor-, Software- und/oder Hardwarekonzept. Damit sind die Daten besser korrelierbar. Die mehreren Fahrsysteme sind beispielsweise Fahrsysteme eines Flottenbetreibers, beispielsweise people mover.
-
In einer weiteren Ausgestaltung der Erfindung werden die Objekte und/oder die Objektattribute mittels eines Maschinenlernalgorithmus indexiert.
-
Maschinelles Lernen ist eine Technologie, die Computern und anderen Datenverarbeitungsvorrichtungen die Ausführung von Aufgaben durch Lernen aus Daten lehrt, anstatt für die Aufgaben programmiert zu werden. Der Maschinenlernalgorithmus lernt die Indexstruktur aus den Daten. Damit ist ein händisches indexieren der Objekte und/oder Objektattribute entbehrlich.
-
Nach einem Aspekt der Erfindung umfasst der Maschinenlernalgorithmus ein künstliches neuronales Netzwerk, das auf semantische Bildsegmentierung und Indexierung gemäß der Indexstruktur trainiert. Das künstliche neuronale Netzwerk ist beispielsweise ein Faltungsnetzwerk, beispielsweise ein VGG Net, siehe K. Simonyan et al., „Very Deep Convolutional Networks For Large-Scale Image Recognition“, ar-Xiv:1409.1556v6 [cs.CV]. Das künstliche neuronale Netzwerk wird nach einem Aspekt der Erfindung mittels überwachtem Lernen trainiert. Damit ist der Lernprozess besser nachvollziehbar als beim unüberwachten Lernen, was vorteilhaft für die Validierung und Absicherung des Fahrsystems ist.
-
Nach einem weiteren Aspekt der Erfindung wird der Maschinenlernalgorithmus, beispielsweise das künstliches neuronales Netzwerk auf dem erfindungsgemäßen Computer auf semantische Bildsegmentierung und Indexierung gemäß der Indexstruktur trainiert. Für das Training ist es vorteilhaft, dass der Computer eine Mikroarchitektur zum parallelisierten Ausführen von Prozessen umfasst, um das künstliche neuronale Netzwerk mit einer großen Anzahl an Daten zeiteffizient trainieren zu können.
-
Graphikprozessoren umfassen eine derartige Mikroarchitektur. Das trainierte Netz wird nach einem Aspekt der Erfindung auf dem Computer ausgeführt.
-
Nach einem weiteren Aspekt der Erfindung werden die Objekte und/oder die Objektattribute in einem Cloud-Speicher gespeichert und die Datenstruktur wird als Software-as-a-Service bereitgestellt.
-
Ein Cloud-Speicher speichert Daten in logischen Pools. Der physische Speicher erstreckt sich beispielsweise über mehrere Server. Mit dem Cloud-Speicher werden große Datenmengen gespeichert. Mittels internet-of-things-Technik ist ein globaler, Zeit unabhängiger Zugriff auf den Speicher bereitgestellt.
-
Software-as-a-Service bedeutet, dass ein Nutzungszugang zu dem erfindungsgemäßen Verfahren und damit auch zu dem erfindungsgemäßen Computerprogramm in einer Cloud angeboten wird. Das erfindungsgemäße Verfahren und das erfindungsgemäße Computerprogramm werden damit als eine Cloud-basierte Anwendungssoftware bereitgestellt. Die Cloud umfasst Speicherplatz, Rechenleistung und Anwendungssoftware, die über internet-of-things-Technik verfügbar gemacht werden. Nach einem Aspekt der Erfindung ist der erfindungsgemäße Computer Cloud-basiert. Beispielsweise wird das künstliche neuronale Netzwerk in der Cloud trainiert und ausgeführt.
-
Nach einem Aspekt der Erfindung werden Objekte und/oder die Objektattribute, die aus aufgezeichneten Fahrten oder in Echtzeit während Fahrten von mehreren Fahrsystemen erhalten werden, in dem Cloud-Speicher gespeichert. Nach einem weiteren Aspekt der Erfindung ist die Verarbeitungseinheit des Computers in der Cloud implementiert.
-
Nach einem Aspekt der Erfindung wird der erfindungsgemäße Datenträger in der Cloud bereitgestellt.
-
Ein Aspekt der Erfindung betrifft das Anbieten des erfindungsgemäßen Verfahrens, der erfindungsgemäßen Datenstruktur, des erfindungsgemäßen Computers, Computerprogramms und/oder des erfindungsgemäßen Datenträgers als Cloud-basierte Lösung an Kunden, die ein automatisiertes Fahrsystem oder zum Validieren des Fahrsystems erforderliche Strecken, real oder virtuell, fordern.
-
In einer weiteren Ausgestaltung der Erfindung umfassen die Funktionalitäten des Fahrsystems eine bedingt automatisierte Verkehrsstau-Fahrt, eine bedingt automatisierte Autobahnfahrt, einen hochautomatisierten Parkservice, eine hochautomatisierte Autobahnfahrt und/oder ein hochautomatisiertes Transportnetzwerk.
-
Für die bedingt automatisierte Verkehrsstau-Fahrt wird die Datenstruktur bei Testfahrten mittels der Indexstruktur beispielsweise wie folgt abgefragt:
- • ODD.Infrastructure.Roadway Types:
- ◯ Ist eine mehrspurige Fahrbahn in der Datenstruktur enthalten?
- ◯ Gibt es Kreisverkehre?
- • ODD.Infrastructure.Roadway Surfaces:
- • ODD.Infrastructure.Lane Markings:
- ◯ Gibt es Spurmarkierungen?
- • ODD.Infrastructure.Geometry:
- • OEDR.Objects.Vehicle Types:
- ◯ Wurden Passagierfahrzeuge, LKWs, NKWs, Busse, Motorräder, Einsatzfahrzeuge, Baustellenfahrzeuge erkannt?
- • OEDR.Objects:
- ◯ Wurden Fußgänger, Fahrradfahrer erkannt?
-
Für das hochautomatisierte Transportnetz sind entsprechend weitere Objekte und/oder Objektattribute im Vergleich zur bedingt automatisierten Verkehrsstau-Fahrt abzufragen und zu prüfen, beispielsweise mehrere Straßentypen, zum Beispiel Stadtbereich, Landbereich, Parkplätze, Brücken, da sich das hochautomatisierte Transportnetz in diesen Verkehrsbereichen bewegen wird.
-
Falls eine der Abfragen negativ ist, wird das jeweilige Objekt und/oder Objektattribut in der von der Indexstruktur abhängigen Klasse gespeichert und die Information bereitgestellt, dass das Fahrsystem für dieses Objekt und/oder Objektattribut zu validieren ist.
-
Nach einem Aspekt der Erfindung ist die Datenstruktur in eine Datenbank implementiert. Nach einem Aspekt der Erfindung ist die Datenbank Cloud-basiert.
-
Nach einem weiteren Aspekt der Erfindung ist die Datenstruktur in einer Größe und/oder hinsichtlich einer Hierarchie von Attributen, beispielsweise einer Verfeinerung von Attributen, skalierbar. Bei steigender Erfahrung mit neuen Strecken und neu hinzukommenden Attribute nimmt die Datenstruktur diese in die passenden Klassen automatisiert mit auf.
-
Die Erfindung wird in den folgenden Ausführungsbeispielen verdeutlicht. Es zeigen:
- 1 ein Ausführungsbeispiel einer erfindungsgemäßen Datenstruktur,
- 2 eine schematische Darstellung eines erfindungsgemäßen Verfahrens,
- 3 ein Ausführungsbeispiels eines erfindungsgemäßen Computers,
- 4 ein Ausführungsbeispiel eines Szenarios und
- 5 ein Ausführungsbeispiel eines weiteren Szenarios.
-
In den Figuren bezeichnen gleiche Bezugszeichen gleiche oder funktionsähnliche Bezugsteile. Übersichtshalber werden in den einzelnen Figuren nur die jeweils relevanten Bezugsteile hervorgehoben.
-
1 zeigt die erfindungsgemäße Datenstruktur DS. Die Datenstruktur DS ist beispielsweise eine Cloud basierte objektorientierte Datenbank. Eine erste Objektklasse 1 beschreibt die ODD. Eine zweite Objektklasse 2 beschreibt die OEDR. Eine dritte Objektklasse 3 beschreibt maneuver behavior. Eine vierte Objektklasse 4 beschreibt failure mode behaviors.
-
Die erste Objektklasse 1 umfasst als Hauptklassen 1.1, 1.2 und 1.3 beispielsweise Infrastruktur 1.1, Objekte 1.2, Umweltbedingungen 1.3. Unterklassen der Hauptklasse 1.3 umfassen als weitere Klassen beispielsweise Wetter 1.3.1, Beleuchtung 1.3.2 und Wetter bedingte Straßenbedingungen 1.3.3. Objektattribute für Wetter umfassen Schnee, Wind, Temperatur und Regen. Objektattribute für Regen umfassen Nieselregen, Durchschnittsregen und Starkregen. Objektattribute für Beleuchtung umfassen Tag, Dämmerung, Nacht, Straßenbeleuchtung, Fahrzeugleuchten. Objektattribute für Wetter bedingte Straßenbedingungen umfassen trocken, nass, vereist. Die Objektattribute sind vererbbar in andere Unterklassen anderer Hauptklassen. Die Objekte und/oder Objektattribute sind mit einer Indexstruktur I indiziert. Mittels der Indexstruktur I werden die in der Datenstruktur DS gespeicherten Objekte und/oder Objektattribute abgefragt. Für neue Objekte und/oder Objektattribute wird gemäß der Indexstruktur I ein neuer Index vergeben, mittels dem die Objekte und/oder Objektattribute gemäß der Klassenhierarchie in der Datenstruktur DS gespeichert werden und referenzierbar sind.
-
2 zeigt die Verfahrensschritte, die beispielsweise von einer Verarbeitungseinheit 14 des in 3 gezeigten Computers 10 ausgeführt werden. In einem Verfahrensschritt V1 wird ein Objekts und/oder Objektattribut erhalten und indexiet basierend auf der Indexstruktur I. In einem Verfahrensschritt V2 wird die Datenstruktur DS nach Vorhandensein des Objekts und/oder Objektattributs mittels der Indexstruktur I abgefragt. Falls die Abfrage negativ ausfällt, wird das Objekt und/oder das Objektattribut in der von der Indexstruktur I abhängigen Klasse gespeichert. Ebenfalls wird in einem Verfahrensschritt V3 das Objekt und/oder Objektattribut zur Validierung des Fahrsystems bereitgestellt. Falls die Abfrage positiv ausfällt, wird in einem Verfahrensschritt V4 die Information bereitgestellt, dass das Fahrsystem für dieses Objekt und/oder Objektattribut validiert ist.
-
Der Computer 10 in 3 umfasst eine erste Schnittstelle 11. Die erste Schnittstelle 11 ist eine Datenübertragungsschnittelle zu einem Speicher eines Fahrtenaufzeichnungsdatenträgers, über die der Computer 10 Objekte und/oder Objektattribute aus aufgezeichneten Fahrten erhält. Alternativ ist die erste Schnittstelle eine Datenübertragungsschnittstelle zu einem Umfelderfassungssensor des Fahrsystems, um in Echtzeit während Fahrten des automatisierten Fahrsystems Objekte und/oder Objektattribute zu erhalten. Die erste Schnittstelle 11 arbeitet nach einem Deserializer Protokoll, beispielsweise nach gigabit multimedia serial link Standard, um hohe Übertragungsraten zu realisieren.
Ferner umfasst der Computer 10 eine Verarbeitungseinheit 14, mittels der die Objekte und/oder Objektattribute erfindungsgemäß mit der Indexstruktur I indexiert werden. Beispielsweise führt die Verarbeitungseinheit 14 ein Faltungsnetzwerk aus, das Objekt und/oder Objektattribute aus Fahrtaufzeichnungen klassifiziert, lokalisiert und semantisch segmentiert. Außerdem umfasst der Computer 10 eine zweite Schnittstelle 12 zu der Datenstruktur DS. Die zweite Schnittstelle 12 ist bidirektional. Über die zweite Schnittstelle 12 fragt der Computer 10 die Datenstruktur DS mittels der Indexstruktur I nach Vorhandensein der Objekte und/oder Objektattribute ab. Die die Objekte und/oder Objektattribute werden in einer von der Indexstruktur I abhängigen Klasse der Datenstruktur DS gespeichert, falls die Abfrage negativ ausfällt. Des Weiteren umfasst der Computer 10 eine dritte Schnittstelle 13, um im Falle der negativen Abfrage die Objekte und/oder Objektattribute zur Validierung des Fahrsystems bereitzustellen oder, im Falle einer positiven Abfrage, die Information bereitzustellen, dass das Fahrsystem für diese Objekte und/oder Objektattribute validiert ist.
-
Die 4 und 5 zeigen jeweils ein Beispiel für ein sogenanntes key scenario, das auf Testfahrten aufgezeichnet wurde und für dieses das automatisierte Fahrsystem zu validieren ist. Im Stand der Technik wird beispielsweise für jede zu Teststrecke händisch, beispielsweise tabellarisch, aufgezeichnet, ob eines dieser kex scenarios in der Strecke enthalten ist. Bei einer wachsenden Anzahl von Teststrecken und einer wachsenden Anzahl an ODDs, OEDRs, Manövern und Systemfehlern wird eine derartige Tabelle undurchschaubar. Die erfindungsgemäße Datenstruktur ermöglicht eine im Vergleich hierzu effizientere Bewertung und/oder Abgleich hinsichtlich
-
4 zeigt als ODD beispielsweise das Testszenario, dass ein Egofahrzeug E, das ist das zu validierende Fahrzeug, in einen Kreisverkehr einfährt und diesen an der zweiten Ausfahrt verlassen möchte. An der dritten Ausfahrt ist ein Fahrradfahrer C in den Kreisverkehr eingefahren. Hinsichtlich OEDR ist dieser als Fahrradfahrer C zu erkennen und in Reaktion auf die Verkehrssituation unter Einhaltung der Straßenverkehrsordnung Vorfahrt zu gewähren. Das Egofahrzeug E soll beim Einfahren in den Kreisverkehr den Fahrradfahrer C erkennen, halten, dem Fahrradfahrer C Vorfahrt gewähren und erst anschließend in den Kreisverkehr einfahren. An der ersten Ausfahrt fährt ein Fremdfahrzeug F ein. Das Fremdfahrzeug F wird den Kreisverkehr an der dritten Ausfahrt verlassen. Das Egofahrzeug E, das bereits im Kreisverkehr ist, wenn das Fremdfahrzeug F in den Kreisverkehr einfahren möchte, hat Vorfahrt. Hinsichtlich OEDR ist das Fremdfahrzeug F zu erkennen und in Reaktion auf die Verkehrssituation unter Einhaltung der Straßenverkehrsordnung weiterzufahren.
-
5 zeigt als ODD beispielsweise das Testszenario, dass ein Egofahrzeug E einspurigen Straße mit Gegenverkehr folgen soll. Falls ein Fremdfahrzeug F dabei vor dem Egofahrzeug E fährt, ist ein Sicherheitsabstand einzuhalten. Falls ein Fremdfahrzeug F in Abhängigkeit von der Verkehrslage und unter Einhaltung der Straßenverkehrsordnung überholt werden kann, soll das Egofahrzeug E das Fremdfahrzeug F überholen. Hinsichtlich OEDR sind das vorausfahrende Fremdfahrzeug F und auf der Gegenfahrbahn fahrende Fremdfahrzeuge F zu erkennen, Abstände einzuhalten, Geschwindigkeiten zu erkennen und Spurwechsel mit Überholmanövern einzuleiten.
-
Bezugszeichenliste
-
- DS
- Datenstruktur
- 1-4
- Objektklassen
- 1.1-1.3
- Hauptklassen
- 1.3.1-1.3.3
- Unterklassen
- I
- Indexstruktur
- V1-V4
- Verfahrensschritte
- 10
- Computer
- 11
- erste Schnittstelle
- 12
- zweite Schnittstelle
- 13
- dritte Schnittstelle
- 14
- Verarbeitungseinheit
- C
- Fahrradfahrer
- E
- Egofahrzeug
- F
- Fremdfahrzeug
-
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 Nicht-Patentliteratur
-
- Staplin, L., Mastromatto, T., Lococo, K. H., Kenneth W. Gish, K. W., & Brooks, J. O. (2018, September), „The effects of medical conditions on driving performance“ (Report No. DOT HS 812 623), Washington, DC: National Highway Traffic Safety Administration [0002]
- P., Fratrik F., „How Many Operational Desgin Domains, Objects, and Events?“, Preprint: Safe AI 2019 [0003]
