DE102019105874A1

DE102019105874A1 - Automatisierte Fahrsysteme und Steuerlogik für die Cloud-basierte Szenarienplanung autonomer Fahrzeuge

Info

Publication number: DE102019105874A1
Application number: DE102019105874.0A
Authority: DE
Inventors: Praveen Palanisamy; Sayyed Rouholla Jafari Tafti; Soheil Samii; Marcus J. Huber
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2018-03-14
Filing date: 2019-03-07
Publication date: 2019-09-19
Also published as: CN110271556A; US20190286151A1

Abstract

Präsentiert werden Szenarienplanungs- und Routenerzeugungssysteme, Verfahren zum Betreiben/Konstruieren dieser Systeme und Fahrzeuge mit Szenarienplanauswahl und Echtzeit-Trajektorienplanungsfunktionen. Ein Verfahren zum Steuern des Betriebs eines Kraftfahrzeugs beinhaltet das Bestimmen von Fahrzeugzustandsdaten, wie beispielsweise einer aktuellen Position und Geschwindigkeit des Fahrzeugs, und von Wegplandaten, wie beispielsweise einem Ausgangspunkt und einem gewünschten Ziel des Fahrzeugs. Ein entfernter Rechenknoten außerhalb des Kraftfahrzeugs erzeugt eine Liste von Trajektorienplankandidaten basierend auf den Fahrzeugzustandsdaten, den Wegplandaten und den aktuellen Daten des Straßenszenarios. Der entfernte Rechenknoten berechnet dann für jeden Kandidaten in der Liste der Trajektorienplankandidaten entsprechende Fahrtkosten und sortiert die Liste von den niedrigsten zu den höchsten Fahrtkosten. Der Kandidat mit den niedrigsten Fahrtkosten wird an eine residierende Fahrzeugsteuerung übermittelt. Die Fahrzeugsteuerung führt einen automatisierten Fahrbetrieb basierend auf dem empfangenen Trajektorienplankandidaten durch.

Description

EINLEITUNG
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf Kraftfahrzeuge mit automatisiertem Fahrvermögen. Insbesondere beziehen sich Aspekte dieser Offenbarung auf die Routengenerierung und Szenarienplanung für autonome Fahrzeuge.
Aktuelle Serienfahrzeuge, wie das moderne Automobil, werden ursprünglich mit einem Netzwerk von elektronischen Bordgeräten ausgestattet oder nachgerüstet, die automatisierte Fahrfunktionen zur Minimierung des Fahreraufwands bereitstellen. In Automobilanwendungen ist beispielsweise die am besten erkennbare Art der automatisierten Fahrweise das Tempomatsystem, das es einem Fahrzeugführer ermöglicht, eine bestimmte Fahrzeuggeschwindigkeit einzustellen und diese vom fahrzeugseitigen Computersystem aufrechtzuerhalten, ohne dass der Fahrer das Gaspedal oder die Bremspedale betätigt. Die adaptive Geschwindigkeitsregelung der nächsten Generation (ACC; auch als autonome Geschwindigkeitsregelung bezeichnet) ist eine computergestützte Fahrzeugregelung, mit der die Fahrzeuggeschwindigkeit geregelt wird, während gleichzeitig der Vorder- und Hinterabstand zwischen dem Trägerfahrzeug und den führenden oder nachfolgenden Fahrzeugen verwaltet wird. Eine weitere Art von automatisiertem Fahren ist das Kollisionsvermeidungssystem (CAS), das bevorstehende Kollisionsbedingungen erkennt und entweder eine Fahrerwarnung ausgibt oder autonom eingreift - z. B. durch Lenken oder Bremsen - ohne Eingriff des Fahrers. Intelligente Parkhilfesysteme (IPAS), Spurüberwachungssysteme und andere autonome Fahrzeugmanövrierfunktionen sind ebenfalls bei vielen modernen Automobilen verfügbar.
Da sich die Fahrzeugerkennungs-, Kommunikations- und Steuerungssysteme immer weiter verbessern, sind die Hersteller bestrebt, auch weiterhin autonomere Fahrleistungen anzubieten, mit dem Ziel, letztendlich vollständig autonome Fahrzeuge bereitzustellen, die für den Betrieb zwischen heterogenen Fahrzeugtypen sowohl in städtischen als auch in ländlichen Szenarien geeignet sind. Erstausrüster (Original Equipment Manufacturers, OEM) bewegen sich in Richtung vernetzter „sprechender“ Autos mit einer übergeordneten Fahrautomatisierung, die autonome Systeme zur Fahrzeugführung, zum Spurwechsel, zum Überholen, zur Szenarienplanung usw. einsetzen. Automatisierte Routengenerierungssysteme verwenden Fahrzeugzustands- und -dynamiksensoren, benachbarte Fahrzeug- und Straßenzustandsdaten und Wegvorhersagealgorithmen, um die Weggenerierung mit automatisierter Vorhersage von Spurmitte und Spurwechsel zu ermöglichen. Computergestützte Umleitungstechniken bieten einen empfohlenen Fahrweg für das Fahrzeug mit vorhergesagten alternativen Fahrtrouten, die beispielsweise basierend auf Echtzeit- und geschätzten Fahrzeugdaten aktualisiert werden können.
KURZDARSTELLUNG
Hierin werden Szenarienplanungs- und Routengenerierungssysteme für verteilte Rechensysteme und die dazugehörige Steuerlogik für autonome Fahrzeuge, Verfahren zum Betrieb und zur Konstruktion dieser Systeme sowie Kraftfahrzeuge mit Szenarienplanauswahl und Echtzeit-Trajektorienplanungsfunktionen offenbart. Als Beispiel wird ein Szenarienplanungssystem vorgestellt, das opportunistisch Cloud-basierte Dienste nutzt, um eine umfassende Liste von Trajektorienplankandidaten unter dynamischen Straßenszenarien bereitzustellen. Die Cloud-Komponente erzeugt mithilfe von High-Performance-Computing optimierte Szenarienpläne und Trajektorienkandidaten, die über drahtlose Medien an ein Szenarienplanungsmodul im Fahrzeug übertragen werden. Das Szenarienplanungsmodul des Trägerfahrzeugs wertet lokal erfasste dynamische Informationen zu Straßenszenarien aus, um in Echtzeit einen besten Kandidaten auszuwählen und andere praktikable, global optimale Trajektorienkandidaten bereitzustellen. Dieser beste Kandidat wird an ein bordeigenes Trajektorienplanungsmodul zum abschließenden Verfeinern und Ausführen durch die zentrale Verarbeitungseinheit des Fahrzeugs gesendet. Vor dem Ausführen kann das Trajektorienplanungsmodul zunächst in Echtzeit bestimmen, ob der „beste“ Kandidat tatsächlich ein „optimaler“ Kandidat ist, z. B. durch Schätzen, ob der beste Kandidat eine kollisionsfreie Option ist oder nicht und/oder kinodynamisch machbar ist.
Durch das Generieren von Trajektorienplänen außerhalb des Fahrzeugs zu einem entfernten Knoten tragen die offenbarten Funktionen dazu bei, den Bedarf an eingebetteten Rechenkapazitäten im Fahrzeug für die Szenarienplanung zu reduzieren, die als Schlüsselfunktion für das autonome Fahren angesehen werden kann. Ein damit verbundener Vorteil von reduzierten Onboard-Rechenanforderungen ist eine Erhöhung der Fahrzeugbatterielaufzeit und damit eine verbesserte Reichweite für Hybrid- und Batterie-Elektrofahrzeuge. Ein weiterer damit verbundener Vorteil kann eine einheitliche Quelle für realisierbare Trajektorienplankandidaten und Straßenbegrenzungsinformationen auf Fahrspurniveau sein, was ein gemeinsames Cloud-Computing und die Konsolidierung der Berechnung in einer Fahrzeugflotte ermöglicht. Offenbarte Szenarienplanungsfunktionen nutzen opportunistisch Cloud-basierte Dienste, um effizientere, vereinfachte und umfassendere Navigationspläne zum Erzeugen von Trajektorien im Fahrzeug unter dynamischen Straßenszenarien bereitzustellen. Dies kann einen längeren Planungshorizont über die Sichtlinie der Sensoren hinaus bieten und gleichzeitig eine einheitliche Quelle für praktikable Trajektorienplankandidaten und Straßenbegrenzungsinformationen auf Fahrspurniveau bereitstellen. Die offenbarten Funktionen können auch eine benutzerdefinierte Auflösung von Cloud-Daten basierend auf der individuellen Bandbreite und Latenzzeit der Fahrzeugkonnektivität bieten.
Aspekte dieser Offenbarung richten sich an die Cloud-basierte Szenarienplanung und Routengenerierung von Logik und computerausführbaren Algorithmen für autonome Fahrzeuge. So wird beispielsweise ein Verfahren zum Steuern eines automatisierten Fahrbetriebs eines Kraftfahrzeugs vorgestellt. Dieses repräsentative Verfahren beinhaltet in beliebiger Reihenfolge und in beliebiger Kombination mit einem der offenbarten Merkmale und Optionen: das Ermitteln von Fahrzeugzustandsdaten, die eine aktuelle Position, Geschwindigkeit, Beschleunigung, Richtung usw. des Kraftfahrzeugs beinhalten können, und Wegplandaten, die einen Ausgangspunkt und ein gewünschtes Ziel des Kraftfahrzeugs beinhalten können; das Erzeugen über einen entfernten Rechenknoten außerhalb des Kraftfahrzeugs (z. B. durch einen Backend-Cloud-Server-Computer), eine Liste von Trajektorienplankandidaten basierend auf den Fahrzeugzustandsdaten, den Wegplandaten und aktuellen Straßenszenariendaten, die Echtzeit-Situations-/Kontextdaten des Fahrzeugs beinhalten können; Berechnen über den entfernten Rechenknoten der jeweiligen Fahrkosten für jeden Trajektorienplankandidaten in der Liste der Trajektorienplankandidaten; Sortieren der Liste der Trajektorienplankandidaten über den entfernten Rechenknoten von den niedrigsten jeweiligen Fahrkosten zu den höchsten jeweiligen Fahrkosten; Übertragen der sortierten Liste von Trajektorienplankandidaten vom entfernten Rechenknoten an eine im Kraftfahrzeug befindliche Fahrzeugsteuerung; Identifizieren des Trajektorienplankandidaten mit den jeweils niedrigsten Fahrkosten über die fahrzeugseitige Steuerung; und Ausführen eines automatisierten Fahrvorgangs über die fahrzeugseitige Steuerung, basierend auf dem übertragenen Trajektorienplankandidaten.
Alle der offenbarten Systeme, Verfahren und Vorrichtungen können optional das Schätzen eines Szenarienplans für den Ausgangspunkt und das gewünschte Ziel des Kraftfahrzeugs über einen Szenarienprozessor des entfernten Rechenknotens beinhalten. Dieser Szenarienplan kann eine Fahrspurzentrierschätzung, eine Fahrspuränderungsschätzung, eine Fahrzeugüberholungsschätzung und/oder eine Objektvermeidungsschätzung beinhalten. Das Schätzen des Szenarienplans kann das Bestimmen geeigneter Schritte zum Verwalten oder anderweitigem „Handhaben“ von zu erwartenden Verkehrszeichen, Kreuzungen, Straßenverhältnissen, Fahrzeugmanövern, Verbindungen und/oder Verkehrsbedingungen beinhalten. Der Szenarienprozessor des entfernten Rechenknotens kann das Fahrzeug während der Fahrt verfolgen, um bei jedem Handhabungsentscheid zu unterstützen. Der geschätzte Szenarienplan kann dann verwendet werden, um die Kandidatenliste für den Trajektorienplan zu erstellen. Darüber hinaus kann ein Referenzweggenerator des entfernten Rechenknotens hochauflösende, mehrspurige Begrenzungs- und Manövrierinformationen für eine geplante Route in einer entfernten Speichervorrichtung speichern. Die zwischengespeicherten Informationen können dann verwendet werden, um die Liste der Trajektorienplankandidaten zu erzeugen.
Alle offenbarten Systeme, Verfahren und Vorrichtungen können optional den Referenzweggenerator des entfernten Rechenknotens beinhalten, der die Fahrtkosten für die sortierte Liste von Trajektorienplankandidaten an das Szenarienauswahlmodul übermittelt. Das Szenarienauswahlmodul der residenten Fahrzeugsteuerung bestimmt dann dynamische Fahrzeugdaten, wie beispielsweise lokal erfasste Objektdaten und Verhaltenspräferenzdaten des Kraftfahrzeugs, und aktualisiert anschließend die jeweiligen Fahrkosten für die Trajektorienplankandidaten basierend auf diesen dynamischen Fahrzeugdaten. Unter Verwendung der aktualisierten Fahrtkosten kann das Szenarienauswahlmodul dann die Liste der Trajektorienplankandidaten von jeweils aktualisierten höchsten bis zu aktualisierten niedrigsten Fahrtkosten neu sortieren.
Weitere Optionen können das Szenarienauswahlmodul sein, das einen aktualisierten Trajektorienplankandidaten mit den jeweils niedrigsten aktualisierten Fahrtkosten an das Echtzeit-Trajektorienplanungsmodul überträgt. Das Trajektorienplanungsmodul kann dann bestimmen, ob dieser Kandidat ein optimaler Kandidat ist, z. B. ob der aktualisierte Trajektorienplankandidat kollisionsfrei und kinodynamisch durchführbar ist. Wenn der aktualisierte Trajektorienplankandidat kein optimaler Kandidat ist, kann das Echtzeit-Trajektorienplanungsmodul eine Anforderung an das Szenarienauswahlmodul für einen anderen Trajektorienplankandidaten übermitteln, z. B. den mit den jeweils zweitniedrigsten Fahrtkosten. Das Echtzeit-Trajektorienplanungsmodul kann eine endgültige Trajektorie definieren durch Verfeinerung des aktualisierten Trajektorienplankandidaten, bei dem es sich um den optimalen Kandidaten handelt. In diesem Fall wird der automatisierte Fahrbetrieb basierend auf dem aktualisierten, optimalen und endgültigen Trajektorienplankandidaten ausgeführt.
Alle offenbarten Systeme, Verfahren und Vorrichtungen können optional den Szenarienprozessor des entfernten Rechenknotens beinhalten, der eine Zustandsabschätzung durchführt, die das Erhalten von lokal fusionierten Fahrspurinformationen und das Erhalten semantischer Straßenszenariendaten umfassen kann. Der Referenzweggenerator des entfernten Rechenknotens kann gleichzeitig einen oder mehrere alternative „Wiederherstellungspläne“ identifizieren. Der Szenarienprozessor des entfernten Rechenknotens kann dynamische Fahrzeugdaten, wie beispielsweise lokal erfasste Objektdaten und Verhaltenspräferenzdaten des Kraftfahrzeugs, und Maplet-Daten, wie beispielsweise geografische Informationen zum Ausgangspunkt und gewünschten Ziel des Kraftfahrzeugs, empfangen. Maplet- und dynamische Fahrzeugdaten können zum Erzeugen der Liste der Trajektorienplankandidaten verwendet werden.
Weitere Aspekte der vorliegenden Offenbarung richten sich an verteilte Fahrzeugsteuerungssysteme und Cloud-basierte Szenarienplanungsarchitekturen zum Regeln des Betriebs von autonomen Kraftfahrzeugen. Ein „Kraftfahrzeug“, wie hierin verwendet, kann jede relevante Fahrzeugplattform, wie z. B. Personenkraftwagen (Verbrennungsmotoren, Hybrid-, vollständig Elektro-, Brennstoffzellenantrieben usw.), Transportfahrzeuge, Industriefahrzeuge, Raupenfahrzeuge, Geländefahrzeuge (ATV), landwirtschaftliche Geräte, Boote, Flugzeuge usw. beinhalten. Zusätzlich kann der Begriff „autonomes Fahrzeug“ jede relevante Fahrzeugplattform beinhalten, die von der Society of Automotive Engineers (SAE) als Level 2, 3, 4 oder 5 Fahrzeug klassifiziert werden kann. SAE Level 0 ist beispielsweise im Allgemeinen als „nicht unterstütztes“ Fahren typisiert, das von einem Fahrzeug erzeugte Warnungen mit vorübergehender Intervention ermöglicht, sich aber ansonsten ausschließlich auf die menschliche Steuerung stützt. Im Vergleich dazu ermöglicht der SAE Level 3 nicht unterstützendes, teilunterstütztes und vollständig unterstütztes Fahren mit ausreichender Fahrzeugautomatisierung für eine volle Fahrzeugsteuerung (Lenkung, Geschwindigkeit, Beschleunigung/Verzögerung usw.), während der Fahrer innerhalb eines kalibrierten Zeitrahmens eingreifen muss. Am oberen Ende des Spektrums steht die Level 5-Automatisierung, die menschliche Eingriffe (z. B. kein Lenkrad, Gaspedal oder Schalthebel) vollständig ausschließt.
In einem Beispiel wird ein autonomes Fahrzeugsteuerungssystem vorgestellt, das ein oder mehrere Kraftfahrzeuge beinhaltet, die drahtlos mit einem entfernten (Cloud-basierten) Rechenknoten kommunizieren, der physisch außerhalb des Fahrzeugs liegt und aus dem/den Kraftfahrzeug(en) verlagert wird. Jedes Kraftfahrzeug kann eine Fahrzeugkarosserie mit einem beliebigen Antriebsstrang und eine residuelle Fahrzeugsteuerung beinhalten, die an der Fahrzeugkarosserie angebracht ist. Die residierende Fahrzeugsteuerung beinhaltet ein Szenarienauswahlmodul und ein Echtzeit-Trajektorienplanungsmodul, während der entfernte Rechenknoten einen Szenarienprozessor und einen Referenzweggeneratorprozessor beinhaltet („Prozessor“ und „Modul“ werden hierin austauschbar verwendet). Während des Systembetriebs bestimmt der Szenarienprozessor Fahrzeugzustandsdaten und Wegplandaten für das Kraftfahrzeug. Die Fahrzeugzustandsdaten können eine aktuelle Position und Geschwindigkeit des Kraftfahrzeugs beinhalten, während die Wegplandaten einen Ausgangspunkt und ein gewünschtes Ziel des Kraftfahrzeugs beinhalten können. Der Referenzweggeneratorprozessor erzeugt eine Liste von Trajektorienplankandidaten basierend auf den Fahrzeugzustandsdaten, den Wegplandaten und aktuellen Straßenszenariendaten (z. B. kontextbezogene Echtzeitdaten des Kraftfahrzeugs).
In Fortführung des vorstehenden Beispiels berechnet der Referenzweggenerator dann für jeden Kandidaten in der Trajektorienplankandidatenliste die entsprechenden Fahrtkosten, sortiert die Liste der Trajektorienplankandidaten von einem niedrigsten zu einem höchsten jeweiligen Fahrtkostenwert und sendet die sortierte Liste an die residierende Fahrzeugsteuerung des Kraftfahrzeugs. Das Szenarienauswahlmodul ermittelt aus der sortierten Liste einen optimalen Trajektorienplankandidaten, z. B. den Kandidaten mit den jeweils geringsten Fahrtkosten. Als Reaktion darauf, dass der erhaltene Trajektorienplankandidat ein optimaler und verfeinerter Kandidat ist, führt der Echtzeit-Trajektorienplaner einen automatisierten Fahrbetrieb basierend auf dem Plankandidaten aus.
Die vorstehende Kurzdarstellung soll nicht jede Ausführungsform oder jeden Aspekt der vorliegenden Offenbarung repräsentieren. Vielmehr stellt die vorstehende Kurzdarstellung lediglich einige der neuartigen Konzepte und Merkmale, wie hierin dargelegt, als Beispiel dar. Die vorstehend aufgeführten Merkmale und Vorteile sowie andere Merkmale und Vorteile dieser Offenbarung werden aus der folgenden ausführlichen Beschreibung der veranschaulichten Ausführungsformen und der Arten zum Ausführen der vorliegenden Offenbarung in Verbindung mit den zugehörigen Zeichnungen und den beigefügten Ansprüchen leicht ersichtlich. Darüber hinaus beinhaltet die vorliegende Offenbarung ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale, die oben und im Folgenden dargestellt sind.
Figurenliste

1 ist eine schematische Darstellung eines repräsentativen Kraftfahrzeugs mit einem Netzwerk von Fahrzeugsteuerungen, Sensoren und Kommunikationsvorrichtungen zum Ausführend des autonomen Fahrbetriebs gemäß den Aspekten der vorliegenden Offenbarung.
2 ist eine schematische Darstellung einer verteilenden Rechenarchitektur für ein repräsentatives Szenarienplanungssystem gemäß den Aspekten der vorliegenden Offenbarung.
3 ist ein Arbeitsablaufdiagramm, das den operativen Aufbau und Austausch für das Szenarienplanungssystem von 2 veranschaulicht.
4 ist ein Flussdiagramm für ein Szenarienplanungs- und Routengenerierungsprotokoll, das den Anweisungen entsprechen kann, die von bordeigenen und fernbetätigten Steuerlogikschaltungen, programmierbaren elektronischen Steuereinheiten oder anderen computergestützten Vorrichtungen oder Netzwerken von Vorrichtungen gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.

Die vorliegende Offenbarung kann ist verschiedenen Modifikationen und alternativen Formen zur Anwendung zugänglich, und einige repräsentative Ausführungsformen werden exemplarisch in den Zeichnungen dargestellt und hierin ausführlich beschrieben. Es versteht sich allerdings, dass die neuartigen Aspekte dieser Offenbarung nicht auf die in den vorstehend aufgeführten Zeichnungen dargestellten besonderen Formen beschränkt sind. Vielmehr umfasst diese Offenbarung alle Modifikationen, Entsprechungen, Kombinationen, Teilkombinationen Permutationen, Gruppierungen und Alternativen, die dem Erfindungsgedanken und dem Umfang der Offenbarung entsprechen, wie sie durch die beigefügten Ansprüche festgelegt sind.
AUSFÜHRLICHE BESCHREIBUNG
Diese Offenbarung eignet sich für eine Vielzahl von Ausführungsformen. Diese sind in den Zeichnungen dargestellt und hierin in detaillierten repräsentativen Ausführungsformen der Offenbarung beschrieben, mit der Erkenntnis, dass die vorliegende Offenbarung als eine Veranschaulichung der Prinzipien der Offenbarung zu betrachten ist, und nicht als eine Einschränkung der breiten Aspekte der Offenbarung bezüglich der repräsentativen Ausführungsformen. Entsprechend sollten Elemente und Einschränkungen, die beispielsweise in der Kurzdarstellung, der Einführung, der Zusammenfassung und der ausführlichen Beschreibung offenbart, aber nicht explizit in den Patentansprüchen aufgeführt sind, nicht per Schlussfolgerung, Rückschluss oder anderweitig einzeln oder insgesamt in die Patentansprüche integriert werden.
Zu Zwecken der vorliegenden ausführlichen Beschreibung, soweit nicht ausdrücklich dementiert: beinhaltet die Singularform die Pluralform und umgekehrt; die Wörter „und“ und „oder“ sind beide verbindend und trennend; die Wörter „alle und jegliche“ bedeuten beide „alles und jedes“; und die Wörter „einschließlich, beinhaltet“ und „umfassend“ und „aufweisen“ bedeuten „einschließlich ohne Einschränkung.“ Darüber hinaus können beispielsweise Wörter für Annäherungen, wie „etwa“, „fast“, „wesentlich“, „ungefähr“ und dergleichen, hierin im Sinne von „bei, nahe oder nahezu“, oder „innerhalb 0-5 % von“ oder „innerhalb akzeptabler Herstellungstoleranzen“ oder jegliche logische Kombination davon verwendet werden. Schließlich sind Richtungsadjektive und Adverbien, wie etwa vorn, achtern, innen, außen, Steuerbord, Backbord, vertikal, horizontal, oben, unten, vorne, hinten, links, rechts usw. in Bezug auf ein Kraftfahrzeug, wie etwa eine Vorwärtsfahrtrichtung eines Kraftfahrzeugs, vorliegen können, wenn das Fahrzeug operativ auf einer normalen Fahroberfläche ausgerichtet ist.
Mit Bezug auf die Zeichnungen, worin sich gleiche Bezugszeichen auf gleiche Merkmale in den verschiedenen Ansichten beziehen, wird in 1 ein repräsentatives Fahrzeug, das im Allgemeinen mit 10 bezeichnet wird und hierin zu Zwecken der Erörterung als ein autonomes Personenfahrzeug im Limousinenstil dargestellt. Verpackt in einer Fahrzeugkarosserie 12 des Automobils 10, z. B. verteilt auf die verschiedenen Fahrzeugabteile, ist ein Bordnetz von elektronischen Vorrichtungen, wie beispielsweise die nachfolgend beschriebenen verschiedenartigen Rechenvorrichtungen und Steuerungen. Das dargestellte Automobil 10 - hierin auch kurz als „Kraftfahrzeug“ oder „Fahrzeug“ bezeichnet - ist lediglich eine exemplarische Anwendung, mit der die neuartigen Aspekte und Merkmale dieser Offenbarung praktiziert werden können. Ebenso sollte die Implementierung der vorliegenden Konzepte für die in 1 veranschaulichte spezifische Architektur als exemplarische Anwendung der hierin offenbarten Konzepte und Merkmale verstanden werden. Insofern wird davon ausgegangen, dass Aspekte und Merkmale dieser Offenbarung auf jede beliebige Anzahl und Art und Anordnung von vernetzten Steuerungen und Vorrichtungen angewendet und für jeden logisch relevanten Kraftfahrzeugtyp umgesetzt werden können. Darüber hinaus wurden nur ausgewählte Komponenten des Fahrzeugs 10 dargestellt und werden hierin ausführlich beschrieben. Dennoch beinhalten die hierin erörterten Kraftfahrzeuge und Netzwerkarchitekturen zahlreiche zusätzliche und alternative Merkmale und andere verfügbare periphere Komponenten, zum Beispiel zum Ausführen der verschiedenen Verfahren und Funktionen dieser Offenbarung. Letztendlich sind die hierin abgebildeten Zeichnungen nicht unbedingt maßstabsgetreu und dienen lediglich Anleitungszwecken. Somit gelten die spezifischen und relativen Maße der Zeichnungen nicht als einschränkend.
Das repräsentative Fahrzeug 10 von 1 ist ursprünglich mit einer Fahrzeug-Telekommunikations- und Informationseinheit 14 (umgangssprachlich als „Telematik“ bezeichnet) ausgestattet, die mit einem drahtlosen entfernt gelegenen oder „Off-Board“ Cloud-Computing-System 24 (z. B. Mobilfunkmasten, Basisstationen und/oder mobile Vermittlungsstellen (MSCs) usw.) kommuniziert. Einige der anderen Fahrzeug-Hardwarekomponenten 16, die allgemein in 1 dargestellt sind, beinhalten als nicht einschränkende Beispiele eine Anzeigevorrichtung 18, ein Mikrofon 28, einen Lautsprecher 30 und Eingangssteuerungen 32 (z. B. Tasten, Knöpfe, Schalter, Tastaturen, Touchscreens usw.). Im Allgemeinen ermöglichen diese Hardwarekomponenten 16 dem Benutzer die Kommunikation mit der Telematikeinheit 14 und anderen Systemen und Systemkomponenten innerhalb des Fahrzeugs 10. Das Mikrofon 28 ermöglicht dem Fahrzeuginsassen die Eingabe von verbalen oder anderen auditiven Befehlen; das Fahrzeug 10 kann mit einer integrierten Sprachverarbeitungseinheit mit einer Mensch/Maschine-Schnittstellen-(HMI)-Technologie ausgestattet sein. Umgekehrt kann der Lautsprecher 30 eine verbale Ausgabe für die Fahrzeuginsassen bereitstellen und kann entweder ein eigenständiger Lautsprecher speziell zur Verwendung mit der Telematikeinheit 14 oder Teil der Fahrzeug-Audiokomponente 22 sein. Das Audiosystem 22 ist funktionsfähig mit einer Netzwerkverbindungsschnittstelle 34 und einem Audiobus 20 verbunden, um analoge Informationen über eine oder mehrere Lautsprecherkomponenten zu empfangen und als Ton wiederzugeben.
Kommunikativ an die Telematikeinheit 14 angekoppelt ist eine Netzwerkverbindungsschnittstelle 34, zu deren geeigneten Beispielen Twisted Pair/Fiber Optic Ethernet Switch, interner/externer paralleler/serieller Kommunikationsbus, eine lokale Netzwerkschnittstelle (LAN), Controller Area Network (CAN), Media Oriented System Transfer (MOST), Local Interconnection Network (LIN) u.ä. gehören. Andere geeignete Kommunikationsschnittstellen können diejenigen sein, die den ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen. Die Netzwerkverbindungsschnittstelle 34 ermöglicht der Fahrzeughardware 16 das Senden und Empfangen von Signalen untereinander und mit verschiedenen Systemen und Subsystemen sowohl außerhalb als auch „entfernt“ von der Fahrzeugkarosserie 12 und innerhalb oder „resident“ zur Fahrzeugkarosserie 12. Dadurch kann das Fahrzeug 10 verschiedene Fahrzeugfunktionen ausführen, wie beispielsweise das Steuern der Fahrzeuglenkung, das Steuern der Funktion des Fahrzeuggetriebes, das Steuern der Motordrosselklappe, das Ein- und Ausschalten des Bremssystems und andere automatisierte Fahrfunktionen. So empfängt und/oder überträgt die Telematikeinheit 14 beispielsweise Daten zu/von einem Sicherheitssystem ECU 52, einem Motorsteuergerät (ECM) 54, einem Infotainment-Anwendungsmodul 56, Sensorschnittstellenmodul(en) 58 und verschiedenen anderen Fahrzeugsteuervorrichtungen 60, wie beispielsweise einem Getriebesteuermodul (TCM), einem Klimasteuermodul (CCM), einem Bremssystemmodul (BCM) usw.
Mit weiterem Bezug auf 1 ist die Telematikeinheit 14 eine bordeigene Datenverarbeitungsvorrichtung, die sowohl einzeln als auch durch ihre Verbindung mit anderen vernetzten Vorrichtungen eine Mischung von Dienstleistungen bereitstellt. Diese Telematikeinheit 14 besteht im Allgemeinen aus einem oder mehreren Prozessoren, die als diskreter Mikroprozessor, anwendungsspezifische integrierte Schaltung (ASIC), Zentraleinheit (CPU) 36 usw. ausgeführt werden können, die funktionsfähig an eine oder mehrere elektronische Speichervorrichtungen 38 gekoppelt sind, von denen jede die Form einer CD-ROM, einer Magnetplatte, einer IC-Vorrichtung, eines Halbleiterspeichers (z. B. verschiedene Arten von RAM oder ROM) usw. und einer Echtzeituhr (RTC) 46 annehmen kann. Die Kommunikationsfähigkeiten mit entfernten, off-board vernetzten Vorrichtungen werden über einen oder mehrere oder alle von einem/einer zellularen Chipsatz/Komponente 40, ein drahtloses Modem 42, einen Navigations- und Ortungs-Chipsatz/Komponente 44 (z. B. Global Positioning System (GPS)), eine drahtlose Nahbereichs-Kommunikationsvorrichtung 48 (z. B. eine Bluetooth®-Einheit oder Nahfeldkommunikations-(NFC)-Sender/Empfänger) und/oder eine Dualantenne 50 bereitgestellt. Es ist davon auszugehen, dass die Telematikeinheit 14 ohne eine oder mehrere der vorstehend aufgeführten Komponenten implementiert werden kann, oder dass sie je nach Bedarf zusätzliche Komponenten und Funktionen für eine bestimmte Endanwendung beinhalten kann.
Um das autonome Fahrzeug 10 von 1 bei der Navigation sowohl einfacher als auch komplexer Fahrsituationen zu unterstützen, einschließlich des Passierens stehender und fahrender Fahrzeuge, der richtigen Reaktion auf statische und dynamische Objekte in der Fahrbahn, der angemessenen Interaktion an Kreuzungen, des Manövrierens auf Parkplätzen und dergleichen, bietet ein Szenarienplanungssystem 200 eine opportunistische und effiziente Nutzung von Cloud-basierten und/oder anderen Remote-Computing-Diensten, die umfangreiche Rechenfunktionen und Ressourcen für autonome Fahrzeugplanungsberechnungen bieten. Das Szenarienplanungssystem 200 von 2 kann die Verwendung solcher Cloud-/Remote-Computing-Dienste basierend auf fahrzeugkalibrierten Opportunitätskosten regeln. Das Szenarienplanungssystem 200 vermittelt beispielsweise Art, Menge und/oder Auflösung der von den Remote-Computing-Diensten abgerufenen Plandaten und Trajektorienkandidaten in Abhängigkeit vom Umfang der verfügbaren drahtlosen Kommunikationsbandbreite und der Netzwerkkanallatenz für einen bestimmten Zeitrahmen. Auf diese Weise ist das Szenarienplanungssystem 200 in der Lage, die externen Rechenressourcen für Planungsprozesse im Zusammenhang mit dem autonomen Fahren unter verschiedenen Verbindungs- und Kommunikationseinschränkungen, die für autonome Fahrzeuganwendungen bestehen können, zu optimieren und effizient zu nutzen.
Das repräsentative Szenarienplanungssystem 200 von 2 besteht im Allgemeinen aus drei interoperablen, kommunikativ verbundenen Segmenten: einem Eingangsanbietersegment 202, einem Szenariendatensegment 204 und einem Ausgangskonsumentensegment 206. Auf der Eingangsseite des Szenarienplanungssystems 200 hilft das Eingangsanbietersegment 202 - das als Backend-Server-Computer in Kombination mit einer fahrzeuginternen elektronischen Steuereinheit (z. B. der Telematikeinheit 14 von 1) verkörpert sein kann - verschiedene Arten von Eingangsdaten zu erzeugen, abzurufen, zu berechnen und/oder zu speichern (zusammenfassend „bestimmen“), einschließlich Zustandsdaten 201 des Trägerfahrzeugs (HV), dynamische Informationen 203, Maplet-Daten 205 und Wegplandaten 207. Die HV-Zustandsdaten 201 können im Allgemeinen die aktuellen Positions-, Richtungs-, Geschwindigkeits- und/oder Beschleunigungsinformationen des Fahrzeugs 10 umfassen. Andere Arten von Fahrzeugzustandsinformationen können sensorbasierte Echtzeit-Gier-, Neigungs- und Rolldaten, Quergeschwindigkeit, Seitenversatz und Richtungswinkel beinhalten. Die Maplet-Daten 205 hingegen können alle geeigneten Navigationsinformationen zum Ausführen eines gewünschten Fahrbetriebs beinhalten, einschließlich Straßenplanungsdaten, geografische Daten, Infrastrukturdaten und Topologiedaten. Andere Maplet-Informationen können Stoppschilder- und Bremslichtdaten, Geschwindigkeitsbegrenzungsdaten, geplante Straßenbauarbeiten und Straßensperrdaten usw. umfassen. Darüber hinaus beinhalten die Wegplandaten 207 einen aktuellen oder erwarteten Ausgangspunkt (Ursprung) und einen gewünschten Endpunkt (Ziel) für das Fahrzeug 10.
Die dynamischen Informationen 203 von 2 können im Allgemeinen Verhaltenspräferenzen und lokal erfasste Objektinformationen einkapseln. Beispiele für Verhaltenspräferenzen können gewünschte Praktiken beinhalten, die speziell für ein bestimmtes autonomes Fahrzeug (AV) gelten. So kann beispielsweise ein Insasse des Fahrzeugs 10 von 1 das AV bevorzugen, das den Fahrgastkomfort gegenüber der Fahrtzeit in den Vordergrund stellt. Das Szenarienplanungssystem 200 kann auf diese Verhaltenspräferenz mit der Priorisierung von Routen reagieren, welche die Anzahl der Spurwechsel reduzieren und ungepflasterte oder nicht reparierte Straßen vermeiden, um ein bestimmtes Ziel zu erreichen, auch wenn die Gesamtzeit bis zum Ziel oder die Entfernung zum Ziel größer ist als andere alternative Routen. Lokal erfasste Objektinformationen beinhalten dagegen Informationen zu statischen und dynamischen Objekten außerhalb des Fahrzeugs 10, die von einem oder mehreren Sensoren erfasst werden, die lokal an der Fahrzeugkarosserie 12 angebracht sind. Das Cloud-Computing-System 24 kann Objektinformationen aus der Menge von „global erfassten“ Objektinformationen aggregieren oder anderweitig darauf zugreifen, d. h. ein Kollektiv von Informationen, die von mehreren Fahrzeugen gesammelt werden, die Daten mit dem Cloud-Computing-System 24 teilen.
Unter fortgesetzter Bezugnahme auf 2 empfängt das Szenariendatensegment 204 - das als entfernter Rechenknoten (z. B. das Cloud-Computing-System 24 von 1) ausgeführt werden kann - als Eingangsdaten eine oder alle der vorstehend erläuterten Informationen in Bezug auf das Eingangsanbietersegment 202. Vor, zeitgleich mit oder nach dem Empfangen der Daten bestimmt das Szenariendatensegment 204 verschiedene zusätzliche Informationskategorien für die Szenarienplanung, einschließlich Referenztrajektoriendaten 209, linke Begrenzungsdaten 211, Spurmittendaten 213 und rechte Begrenzungsdaten 215. Die Referenztrajektoriendaten 209 können eine unmittelbare Weginformation (z. B. Trajektorie, Beschleunigung, Geschwindigkeit usw.) und unmittelbare Szenarieninformationen (Verkehr, Fußgänger usw.) des autonomen Fahrzeugs 10 für einen kurzfristigen Zeitraum, z. B. für die nächsten 10-30 Sekunden, beinhalten. Die linken Begrenzungsdaten 211, die Spurmittendaten 213 und die rechten Begrenzungsdaten 215 können jeweils entsprechende Straßengeometriedaten bereitstellen, wie beispielsweise geschätzte oder erfasste oder im Speicher gespeicherte linke Randwerte, Mittelwerte bzw. rechte Randwerte, die der Referenztrajektorie 209 des autonomen Fahrzeugs 10 entsprechen. Zusätzliche Daten zu den Straßeneigenschaften, die bei 209, 211, 213 und/oder 215 bereitgestellt werden, können eine Gesamtzahl von Fahrspuren, eine Art oder Arten von Fahrspuren (z. B. Autobahn, Dienst, Wohngebiet usw.), eine Fahrbahnbreite, eine Anzahl oder Schwere von Kurven in einem Straßenabschnitt usw. beinhalten.
Um eine umfassende Liste von Trajektorienplankandidaten unter dynamischen Straßenszenarien bereitzustellen, kann das Szenariendatensegment 204 von 2 auch aktuelle Straßenszenariodaten 217 und Daten des nächsten Szenarios 219 erzeugen. Die aktuellen Straßenszenariodaten 217 können Echtzeitinformationen beinhalten, die auf die vorliegenden situativen/kontextuellen Daten des Fahrzeugs 10 hinweisen, während die Daten des nächsten Szenarios 219 Daten beinhalten können, die auf die kurzfristigen situativen/kontextuellen Daten des Fahrzeugs 10 hinweisen, z. B. für die nächsten 10-30 Sekunden. Die Fahrspurnutzungsdaten 221 können auch bestimmt werden, um die Bevölkerungsdichte einer aktuellen, kurzfristigen und/oder zukünftigen Fahrbahn eines potenziellen Trajektorienkandidaten zu schätzen. Als nicht einschränkendes Beispiel können die Fahrspurnutzungsdaten 221 Informationen zu einer vorhergesagten Nutzung einer Fahrspur beinhalten, die je nach Anzahl der Fahrzeuge in der Fahrspur, der Art oder den Arten von Fahrzeugen in einer Fahrspur (z. B. Krankenwagen, Feuerwehrfahrzeuge oder Polizeifahrzeuge gegenüber gewöhnlichen Personenkraftwagen gegenüber Fahrrädern und anderen Fußgängerfahrzeugen) und dem resultierenden oder erwarteten Verkehr/Durchschnittsgeschwindigkeit auf dieser Fahrspur variieren können. Andere aggregierte Daten können Folgendes umfassen: Verkehrsüberlastung und damit zusammenhängende Bedingungen 223, Umgebungstemperatur und damit zusammenhängende Wetterbedingungen 225, Sichtbarkeitsebene und damit zusammenhängende Sichtbereichsbedingungen 227 und/oder Lichtverhältnisse und damit zusammenhängende Tag/Nachtzeitbedingungen 229. Unter Verwendung einer beliebigen Kombination der vorstehend beschriebenen Daten erzeugt und überträgt das Szenariendatensegment 204 eine umfassende Liste von Trajektorienplankandidaten an einen lokalen Trajektorienplaner 231 des Ausgangsverbrauchersegments 206, der als autonomes Personenfahrzeug 10 von 1 ausgebildet sein kann.
3 stellt ein Arbeitsablaufdiagramm 300 dar, das den operativen Aufbau und Datenaustausch für das Szenarienplanungssystem 200 von 2 veranschaulicht. Wie vorstehend angegeben, kann das Szenarienplanungssystem 200 durch ein Eingangsanbietersegment 202, das hilft, Eingangsdaten zu sammeln oder zu erstellen, die zum Erzeugen von Routen und zur Szenarienplanung erforderlich sein können, ein Szenariendatensegment 204, das verschiedene Eingaben empfängt, aggregiert und verarbeitet, um Listen von Trajektorienplankandidaten zu erzeugen, und ein Ausgangsverbrauchersegment 206, das eine Trajektorienplankandidatenliste verwendet, um einen optimalen Trajektorienkandidaten zu identifizieren, zu überprüfen und auszuführen, typisiert werden. In 3 wird das Szenariendatensegment 204 als ein Remote-Cloud-Computing-System 24 dargestellt, das im Allgemeinen aus einem Szenarienprozessor 302 besteht, der Daten mit einem Referenzweggeneratorprozessor 304 austauscht. Ebenso wird das Ausgangsverbrauchersegment 206 als autonomes Fahrzeug 10 mit einem Szenarienplanauswahlmodul 306 dargestellt, das Daten mit dem Szenariendatensegment 204 und einem Echtzeit-Trajektorienplanungsmodul 308 austauscht. Steuermodul, Modul, Steuerung, Steuergerät, Prozessor und Permutationen hiervon können definiert werden als eine oder mehrere Kombinationen einer oder mehrerer logischer Schaltungen, anwendungsspezifischer integrierter Schaltung(en) (ASIC), elektronische Schaltung(en), zentrale Verarbeitungseinheit(en) (z. B. Mikroprozessor(en)) und dazugehörige Arbeits- und Datenspeicher (Lesespeicher, programmierbare Lesespeicher, Direktzugriffsspeicher, Festplattenlaufwerke usw.)), ob resident, entfernt oder eine Kombination aus beidem, die ein oder mehrere Software- oder Firmware-Programme oder Routinen, kombinatorische Logikschaltung(en), Eingangs-/Ausgangsschaltung(en) und -geräte, entsprechende Signal-Konditionierungs- und Pufferschaltungen ausführen, sowie weitere Komponenten, die die beschriebene Funktionalität bereitstellen.
Unter fortgesetzter Bezugnahme auf 3 koordiniert der Szenarienprozessor 302 mit dem Eingangsanbietersegment 202, um die HV-Zustandsdaten 201 zu akkumulieren, die vorstehend unter Bezugnahme auf 2 erläutert werden. Dieser Vorgang kann das Erhalten einer Ausgangsposition, einer Richtung, einer Geschwindigkeit und/oder einer Beschleunigung (zusammen „Lagedaten“) des Fahrzeugs 10 und das Bestimmen einer Schätzung der fusionierten Position beinhalten, die einer lokalisierten Position und einer Richtung des Fahrzeugs 10 nahe kommt, basierend auf sensorisch fusionierten Daten von verschiedenen Sensormodalitäten (z. B. GPS, Radkodierer, Lidar, Karte, usw.). Ein aktueller HV-Zustand des autonomen Fahrzeugs 10 kann dann aus den anfänglichen Lagedaten und den Schätzdaten der fusionierten Position bestimmt werden; der aktuelle HV-Zustand kann aktualisiert und im lokalen Speicher gespeichert werden.
Unter Verwendung des HV-Zustands in Verbindung mit den Maplet-Daten 205 und vorberechneten aktuellen Planinformationen (die als Speicherblock in den SRAM-Cache-Speicher für Schnelllesevorgänge zwischengespeichert werden können) kann der Szenarienprozessor 302 das Trägerfahrzeug 10 verfolgen, während er auf der Route zwischen einem bestimmten Ausgangspunkt und einem bestimmten Ziel ist. Das Cloud-Computing-System 24 kann dieses Verfahren unter Verwendung von Kartendaten, einem globalen Plan und dem aktuellen Zustand des Fahrzeugs implementieren, um Informationen vorzuberechnen, die für die weitere Szenarienplanung erforderlich sein könnten, z. B. unter Ausnutzung des Verständnisses, dass Straßennetze typischerweise stationär und zur einfachen Referenz vorab abgebildet sind. Ein globaler Plan (oder „Missionsplan“) kann Informationen zum Ausgangspunkt/Ursprung des autonomen Fahrzeugs 10, Bestimmungsort/Ziel und höherrangige Planinformationen beinhalten, um einen/ein gewünschten(s) Bestimmungsort/Ziel zu erreichen. Die vorberechneten und zwischengespeicherten Informationen können verwendet werden, um ein aktuelles Segment (z. B. eine aktuelle Strecke der Fahrbahn oder Fahrspur, auf der sich das Fahrzeug 10 gerade befindet) und verschiedene erforderliche Verbindungen und Verbindungslängen zu finden.
Der Szenarienprozessor 302 kann danach einen Szenarienplan-Schätzprozess ausführen, auch die „Handhabung von Szenarien“ beinhalten kann, um die geeigneten Schritte zum Verwalten von zu erwartenden Verkehrsschildern, Verbindungen, Kreuzungen, erwarteten oder unerwarteten Straßenverhältnissen, Fahrzeugmanövern und/oder erwarteten oder unerwarteten Verkehrsbedingungen festzulegen. Wie hierin verwendet, kann der Begriff „Handhabung“ als ein Protokoll oder eine Technik beinhaltend definiert werden, um einen oder mehrere geeignete Schritte zu bestimmen, die einem Plan zum Verwalten verschiedener erwarteter Aufgaben hinzuzufügen sind (z. B. Anhalten an Stoppschildern oder Ampelanlagen, Zeitsteuerung und Ausführung erwarteter Verbindungen, Zeitsteuerung und Ausführung von fortgeschrittenen Manövern usw.). Die Suchraumschätzung kann dann vom Szenarienprozessor 302 durchgeführt werden, um lokal fusionierte Fahrspurinformationen und semantische Straßenszenarieninformationen zu erhalten. Semantische Straßenszenarieninformationen können semantische Informationen beinhalten, die spezifisch für ein aktuelles Szenario des autonomen Fahrzeugs 10 sind (z. B. und in einem maschinenlesbaren Format gespeichert sind).
Nachdem der Szenarienprozessor 302 einen oder mehrere oder alle der vorstehend beschriebenen Prozesse ausgeführt hat, verwendet der Referenzweggeneratorprozessor 304 die sich daraus ergebenden Informationen, um Szenariendatenkandidaten und entsprechende Ranglistendaten zu erzeugen und an das im Fahrzeug 10 befindliche Szenarienplanauswahlmodul 306 zu übertragen. Um die Kandidaten mit den zugehörigen Ranglistendaten zu erzeugen, speichert der Referenzweggenerator 304 hochauflösende, mehrspurige Grenz- und Manöverinformationen für die geplante Route und erzeugt gleichzeitig einen oder mehrere alternative „Wiederherstellungspläne“ z. B. für Szenarien, in denen das Fahrzeug 10 von einer bestimmten Route abweicht oder eine bestimmte Route unerwartet nicht verfügbar wird. Nach dem Erstellen der Trajektorienplankandidaten kann der Referenzweggeneratorprozessor 304 eine Navigationsplankostenkarte berechnen, indem er die geschätzten Kosten für das Fahrzeug 10 identifiziert, um gemäß jedem Trajektorienplankandidaten zu navigieren. Die zugehörigen „Kosten“ können eine Kombination aus mehreren Faktoren umfassen, einschließlich, aber nicht beschränkt auf den Gesamtenergieverbrauch für einen gegebenen Kandidaten, die allgemeine Laufruhe für einen gegebenen Kandidaten, die Gesamtzeit, die zur Fertigstellung eines gegebenen Kandidaten benötigt wird, die erwartete maximale Beschleunigung und/oder Verzögerung, den voraussichtlichen Ruck, Zeitverzögerungen usw. Die Pläne können dann basierend auf berechneten Kosten bewertet werden, wobei höhere Kosten mit einem niedrigeren Rang verbunden sind.
Das Szenarienplanauswahlmodul 306, das sich im Fahrzeug 10 des Ausgangsverbrauchersegments 206 befindet, kommuniziert drahtlos mit dem Szenariendatensegment 204 des Szenarienplanungssystems 200, um die Trajektorienplankandidaten und die zugehörigen Ranglistendaten vom Referenzweggeneratorprozessor 304 abzurufen. Anhand dieser Informationen und der verfügbaren lokal erfassten Daten (z. B. lokale Objekte, Fahrspurdaten und andere lokale Eingaben) kann das Szenarienplanauswahlmodul 306 die Kostenübersicht des Navigationsplans aktualisieren, die Kandidaten für das aktuelle Szenario neu einordnen (falls erforderlich) und einen optimalen Kandidaten oder eine Teilmenge von optimalen Kandidaten zusammen mit den Szenariodaten an das Trajektorienplanungsmodul 308 senden. Das lokale Szenarienplanauswahlmodul 306 kann nach dem Empfangen der Trajektorienplankandidaten vom Remote-Cloud-Computing-Dienst 24 neue Informationen von fahrzeugseitigen Fahrzeugsensoren und lokalen Fahrzeugsteuermodulen sammeln; diese Informationen können zum Aktualisieren der Referenzpläne, ihrer Kosten und Rankings verwendet werden.
Für jeden optimalen Plankandidaten, der vom Szenarienplanauswahlmodul 306 empfangen wird, überprüft das Echtzeit-Trajektorienplanungsmodul 308 die Praktikabilität des Kandidaten, z. B. durch die Beurteilung im Hinblick darauf, ob der Kandidat voraussichtlich kollisionsfrei ist und ob der Kandidat voraussichtlich kinodynamisch durchführbar ist oder nicht, usw. Ein Trajektorienplan kann als kinodynamisch durchführbar bezeichnet werden, wenn die 10 Kinematiken und Dynamiken des Fahrzeugs es ihm ermöglichen, dem vorgegebenen Trajektorienplan zu folgen, ohne den realisierbaren Betriebsraum der Antriebs-, Brems- und Lenksysteme des Fahrzeugs zu belasten oder zu überschreiten. So sollten beispielsweise Fahrzeuggeschwindigkeit, Beschleunigung/Verzögerung und personenerfahrene Kräfte für einen bestimmten Kandidaten die entsprechenden fahrzeugkalibrierten Grenzen erfüllen und gleichzeitig alle kinematischen Fahrzeugbeschränkungen erfüllen, wie beispielsweise das Umgehen von Hindernissen beim Lenken durch den Verkehr. Wenn es als praktisch erachtet wird, verfeinert das Trajektorienplanungsmodul 308 den Plan, um eine endgültige Trajektorie zu erzeugen, die zum Ausführen an ein autonomes Fahrzeugsteuermodul oder eine ähnlich konfigurierte Fahrzeugsteuerung gesendet wird. Wenn ein Trajektorienplankandidat als nicht praktikabel eingestuft wird, kann das Trajektorienplanungsmodul 308 einen anderen Plankandidaten aus dem Szenarienplanauswahlmodul 306 anfordern; die vorstehend beschriebenen Prüfungs- und Verfeinerungsprozesse werden dann für den neuen Kandidaten wiederholt.
Unter nunmehriger Bezugnahme auf das Flussdiagramm von 4 wird ein verbessertes Verfahren oder eine verbesserte Steuerstrategie zum Steuern des Betriebs eines autonomen Fahrzeugs, wie beispielsweise das Automobil 10 von 1, im Allgemeinen bei 400 gemäß den Aspekten der vorliegenden Offenbarung beschrieben wird. Einige oder alle der in 4 veranschaulichten und hierin beschriebenen Vorgänge können repräsentativ für einen Algorithmus sein, was prozessorausführbaren Anweisungen entspricht, die beispielsweise im Haupt- oder Hilfsspeicher gespeichert werden können und beispielsweise durch eine fahrzeugseitige oder fernbetätigte Steuerung, Verarbeitungseinheit, Steuerlogikschaltung oder ein anderes Modul oder eine andere Vorrichtung ausgeführt werden können, um beliebige oder alle der vorstehend oder nachfolgend beschriebenen Funktionen auszuführen, die den offenbarten Konzepten zugeordnet sind. Es sollte angemerkt werden, dass die Reihenfolge bei der Ausführung der veranschaulichten Operationsblöcke geändert, zusätzliche Blöcke hinzugefügt und einige der beschriebenen Blöcke geändert, kombiniert oder eliminiert werden können.
Das Verfahren 400 beginnt an der Klemmenleiste 401 mit prozessorausführbaren Anweisungen für eine programmierbare Steuerung oder ein Steuermodul, um ein Initialisierungsverfahren für ein Protokoll zum Steuern eines automatisierten Fahrbetriebs eines Kraftfahrzeugs aufzurufen. Beim Prozessblock 403 stellt das Verfahren 400 prozessorausführbare Anweisungen für eine Systemkomponente zum Bestimmen von HV-Zustandsdaten, Maplet-Daten, Wegplandaten und dynamischen Informationen bereit, die alle vorstehend in den Erläuterungen zu den 2 und 3 ausführlich beschrieben werden. Beim Prozessblock 405 wird aus den Daten, die bei Block 403 gesammelt oder erstellt werden, ganz oder teilweise ein aktueller Zustand des Trägerfahrzeugs bestimmt. Das Verfahren 400 von 4 fährt mit dem Prozessblock 407 fort, mit Anweisungen, das Trägerfahrzeug 10 während der Fahrt zu verfolgen, ein aktuelles Szenario für das Trägerfahrzeug 10 bei Prozessblock 409 zu behandeln und einen Suchraum (Ausführen eines Suchraumschätzverfahrens) bei Prozessblock 411 zu schätzen. Wie durch das Referenzzeichen 302 in 4 angegeben, können die Prozessvorgänge 405, 407, 409 und 411 durch den Szenarienprozessor 302 des Cloud-Computing-Systems 24 durchgeführt werden. In diesem Zusammenhang kann der Prozessblock 411 weiterhin den Datenaustausch des Szenarienprozessors 302 mit dem Referenzweggeneratorprozessor 304 erfordern.
In Fortführung der Erläuterung des repräsentativen Verfahrens 400 von 4 beinhaltet der Prozessblock 413 maschinenlesbare, prozessorausführbare Anweisungen zum Zwischenspeichern hochauflösender, mehrspuriger Grenzinformationen und Manöverinformationen für die geplante Route. Der Prozessblock 415 verwendet die zwischengespeicherten Daten, Suchraumschätzungen, Annäherungswerte für die Handhabung von Szenarien usw., um eine Liste von Referenzplankandidaten für einen gewünschten Fahrzeugwegplan zu erstellen. Wie vorstehend beschrieben, werden jedem Referenzplankandidaten im Prozessblock 417 Fahrtkosten berechnet und zugeordnet, und die aufgelisteten Kandidaten werden dann zumindest teilweise basierend auf den berechneten Kosten im Prozessblock 419 bewertet. Wie durch das Referenzzeichen 304 in 4 angegeben, können die Prozessvorgänge 413, 415, 417 und 419 durch den Referenzweggeneratorprozessor 304 des Cloud-Computing-Systems 24 durchgeführt werden. In diesem Zusammenhang kann der Prozessblock 419 weiterhin den Datenaustausch zwischen dem Referenzweggeneratorprozessor 304 und dem im Fahrzeug 10 befindlichen Szenarienplanauswahlmodul 306 erfordern.
Das Verfahren 400 wird mit Block 421 mit prozessorausführbaren Anweisungen für eine programmierbare Steuerung oder ein Steuermodul fortgesetzt, um lokale Sensordaten und Verhaltenseingaben des autonomen Fahrzeugs 10 zu sammeln und zu verarbeiten. Anhand dieser Informationen aktualisiert das Verfahren 400 die Kostenkarte des Navigationsplans bei Prozessblock 423 und identifiziert einen optimalen Trajektorienkandidaten bei Prozessblock 425. Wie durch das Referenzzeichen 306 in 4 angegeben, können die Prozessvorgänge 421, 423 und 425 durch das Szenarienplanauswahlmodul 306 des Fahrzeugs 10 durchgeführt werden. In diesem Zusammenhang kann der Prozessblock 425 weiterhin den Datenaustausch zwischen dem Szenarienplanauswahlmodul 306 und dem Echtzeit-Trajektorienplanungsmodul 308 im Fahrzeug 10 erfordern.
Unter fortgesetzter Bezugnahme auf 4 fährt das Verfahren 400 mit dem Prozessblock 427 fort, um die Praktikabilität des am Prozessblock 425 identifizierten optimalen Trajektorienkandidaten zu überprüfen. Beim Entscheidungsblock 429 bestimmt das Verfahren 400, ob der optimale Trajektorienkandidat als praktisch angesehen wird oder nicht. Wenn das Verfahren 400 zu dem Schluss kommt, dass ein bestimmter Kandidat nicht praktikabel ist (Block 429 = NEIN), fährt das Verfahren 400 mit dem Prozessblock 431 fort und sendet eine Anforderung an das Szenarienplanauswahlmodul 306, um einen anderen Kandidaten zu übertragen. Das Verfahren 400 reagiert beim Prozessblock 433 automatisch, indem es den nächstfolgenden optimalen Trajektorienkandidaten auswählt und überträgt. Dieser neue Kandidat wird dann bei den Blöcken 427 und 429 auf seine Praktikabilität geprüft. Sobald das Verfahren 400 einen praktischen Kandidaten findet (Block 429 = JA), fährt das Verfahren 400 mit dem Prozessblock 435 fort, um den praktischen Trajektorienkandidaten zu verfeinern und dadurch eine endgültige Trajektorie zu erstellen; die endgültige Trajektorie wird an eine residierende Fahrzeugsteuerung oder ein dediziertes Steuermodul bei 437 übertragen und ausgeführt. Das Verfahren 400 kann dann an der Klemmenleiste 439 enden und/oder zur Klemmenleiste 401 zurückgeschleift werden. Wie durch das Referenzzeichen 308 in 4 angegeben, können die Prozessvorgänge 427, 429, 431, 435 und 437 durch das Trajektorienplanungsmodul 308 des Fahrzeugs 10 durchgeführt werden.
Aspekte dieser Offenbarung können in einigen Ausführungsformen durch ein computerausführbares Programm von Anweisungen implementiert werden, wie zum Beispiel Programmmodulen, die allgemein als Softwareanwendungen oder Anwendungsprogramme bezeichnet werden, die von einem Fahrzeug-Bordcomputer oder ein verteiltes Netzwerk von residenten und entfernten Rechenvorrichtungen ausgeführt werden. Die Software kann in nicht einschränkenden Beispielen Routinen, Programme, Objekte, Komponenten und Datenstrukturen beinhalten, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Software kann eine Schnittstelle bilden, damit ein Computer entsprechend einer Eingabequelle reagieren kann. Die Software kann auch mit anderen Codesegmenten zusammenarbeiten, um eine Vielzahl von Aufgaben in Reaktion auf Daten zu initiieren, die in Verbindung mit der Quelle der empfangenen Daten empfangen werden. Die Software kann auf einem beliebigen einer Vielzahl von Speichermedien, wie CD-ROM, Magnetplatte, Blasenspeicher und Halbleiterspeicher (z. B. verschiedene Arten von RAM oder ROM), gespeichert sein.
Darüber hinaus können Aspekte der vorliegenden Offenbarung mit einer Vielzahl von Computersystem- und Computernetzkonfigurationen einschließlich Mehrprozessorsystemen, Mikroprozessor-basierter oder programmierbarer Unterhaltungselektronik, Minicomputern, Mainframe-Computern und dergleichen durchgeführt werden. Zusätzlich können Aspekte der vorliegenden Offenbarung in Umgebungen mit verteilter Datenverarbeitung ausgeführt werden, bei denen Aufgaben durch Fernverarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Computerumgebung können Programmmodule sowohl auf lokalen als auch entfernten Computerspeichermedien einschließlich Speichergeräten angeordnet sein. Aspekte der vorliegenden Offenbarung können daher in Verbindung mit verschiedener Hardware, Software oder einer Kombination davon in einem Computersystem oder einem anderen Verarbeitungssystem implementiert werden.
Jedes der hierin beschriebenen Verfahren kann maschinenlesbare Anweisungen zur Ausführung beinhalten durch: (a) einen Prozessor, (b) eine Steuerung, und/oder (c) jede andere geeignete Verarbeitungsvorrichtung. Jeder hierin offenbarte Algorithmus, jede Software oder jedes Verfahren kann in einer Software enthalten sein, die auf einem greifbaren Medium, wie beispielsweise einem Flash-Speicher, einer CD-ROM, einer Diskette, einer Festplatte, einer Digital Versatile Disk (DVD) oder andere Speichervorrichtungen, gespeichert ist, jedoch werden Fachleute leicht erkennen, dass der gesamte Algorithmus und/oder Teile davon alternativ durch eine andere Vorrichtung als eine Steuerung ausgeführt werden können und/oder in Firmware oder dedizierter Hardware in einer verfügbaren Art und Weise implementiert werden können (z. B. kann er durch einen anwendungsspezifischen integrierter Schaltkreis (Application Specific Integrated Circuit), eine programmierbare Logikvorrichtung (PLD), eine feldprogrammierbare Logikvorrichtung (FPLD), eine diskrete Logik usw. implementiert werden). Obwohl spezielle Algorithmen unter Bezugnahme auf die hier dargestellten Flussdiagramme beschrieben werden, wird der Durchschnittsfachmann leicht erkennen, dass viele andere Verfahren zum Implementieren der exemplarischen maschinenlesbaren Anweisungen alternativ verwendet werden können.
Aspekte der vorliegenden Offenbarung wurden im Detail unter Bezugnahme auf die dargestellten Ausführungsformen beschrieben; der Fachmann wird jedoch erkennen, dass viele Änderungen daran vorgenommen werden können, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Die vorliegende Offenbarung ist nicht beschränkt auf die hierin offenbarte genaue Konstruktion und Zusammensetzung; jegliche und alle Modifikationen, Änderungen und Variationen, ersichtlich aus den vorangehenden Beschreibungen, liegen innerhalb des Umfangs der Offenbarung, wie durch die hinzugefügten Ansprüchen definiert. Darüber hinaus beinhalten die vorliegenden Konzepte ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale.

Claims

Verfahren zum Steuern eines automatisierten Fahrbetriebs eines Kraftfahrzeugs, wobei das Verfahren Folgendes umfasst: Bestimmen von Fahrzeugzustandsdaten und Wegplandaten für das Kraftfahrzeug, wobei die Fahrzeugzustandsdaten eine aktuelle Position und Geschwindigkeit des Kraftfahrzeugs beinhalten und die Wegplandaten einen Ausgangspunkt und ein gewünschtes Ziel des Kraftfahrzeugs beinhalten; Erzeugen einer Liste von Trajektorienplankandidaten über einen entfernten Rechenknoten außerhalb des Kraftfahrzeugs basierend auf den Fahrzeugzustandsdaten, den Wegplandaten und den aktuellen Straßenszenariodaten einschließlich Echtzeit-Kontextdaten des Kraftfahrzeugs; Berechnen von Fahrkosten über den entfernten Rechenknoten für jeden Trajektorienplankandidaten in der Liste der Trajektorienplankandidaten; Sortieren der Liste der Trajektorienplankandidaten über den entfernten Rechenknoten von den niedrigsten jeweiligen Fahrtkosten bis zu den höchsten jeweiligen Fahrtkosten; Übertragen der sortierten Liste von Trajektorienplankandidaten vom entfernten Rechenknoten an eine residierende Fahrzeugsteuerung an Bord des Kraftfahrzeugs; Identifizieren des Trajektorienplankandidaten mit den jeweils niedrigsten Fahrtkosten über die residierende Fahrzeugsteuerung; und Ausführen des automatisierten Fahrvorgangs über die residierende Fahrzeugsteuerung basierend auf dem identifizierten Trajektorienplanungskandidaten.
Verfahren nach Anspruch 1, ferner umfassend das Schätzen eines Szenarienplans für den Ausgangspunkt und das gewünschte Ziel des Kraftfahrzeugs über den entfernten Rechenknoten, wobei der Szenarienplan eine Spurzentrierschätzung, eine Spurwechselschätzung, eine Fahrzeugüberholschätzung und eine Objektvermeidungsschätzung beinhaltet, worin das Erzeugen der Liste von Trajektorienplankandidaten weiterhin basierend auf dem geschätzten Szenarienplan erfolgt.
Verfahren nach Anspruch 2, worin das Schätzen des Szenarienplans das Handhaben von folgenden beinhaltet: zu erwartende Verkehrsschilder, erwartete Kreuzungen, erwartete Straßenverhältnisse, erwartete Fahrzeugmanöver und erwartete Verkehrsbedingungen.
Verfahren nach Anspruch 3, ferner umfassend das Verfolgen einer aktuellen Route des Kraftfahrzeugs über den entfernten Rechenknoten.
Verfahren nach Anspruch 1, ferner umfassend das Zwischenspeichern von mehrspurigen Begrenzungs- und Manöverinformationen für eine geplante Route über den entfernten Rechenknoten in einer entfernten Speichervorrichtung, worin das Erzeugen der Liste von Trajektorienplankandidaten weiterhin basierend auf der zwischengespeicherten mehrspurigen Begrenzung und Manöverinformationen erfolgt.
Verfahren nach Anspruch 1, worin die residierende Fahrzeugsteuerung ein Szenarienauswahlmodul und ein Echtzeit-Trajektorienplanungsmodul beinhaltet, wobei das Verfahren ferner umfasst: Übertragen der jeweiligen Fahrtkosten für die sortierte Liste der Trajektorienplankandidaten vom entfernten Rechenknoten an das Szenarienauswahlmodul; Bestimmen von dynamischen Fahrzeugdaten über die residierende Fahrzeugsteuerung, einschließlich Daten zu erfassten Objekten außerhalb des Kraftfahrzeugs und Verhaltenspräferenzen des Kraftfahrzeugs; und Aktualisieren der jeweiligen Fahrtkosten für die Trajektorienplankandidaten über das Szenarienauswahlmodul basierend auf den dynamischen Fahrzeugdaten.
Verfahren nach Anspruch 6, ferner umfassend das Umsortieren der sortierten Liste von Trajektorienplankandidaten über das Szenarienauswahlmodul von einer aktualisierten höchsten bzw. jeweiligen Fahrtkosten zu einer aktualisierten niedrigsten bzw. jeweiligen Fahrtkosten basierend auf den aktualisierten bzw. jeweiligen Fahrtkosten.
Verfahren nach Anspruch 7, ferner umfassend das Übertragen eines aktualisierten Trajektorienplankandidaten mit den aktualisierten niedrigsten bzw. jeweiligen Fahrtkosten vom Szenarienauswahlmodul an das Echtzeit-Trajektorienplanungsmodul, worin der automatisierte Fahrbetrieb, basierend auf dem aktualisierten Trajektorienplankandidaten, über die residierende Fahrzeugsteuerung ausgeführt wird.
Verfahren nach Anspruch 8, ferner umfassend das Bestimmen, ob der aktualisierte Trajektorienplankandidat ein optimaler Kandidat ist, einschließlich des Schätzens, ob der aktualisierte Trajektorienplankandidat kollisionsfrei und kinodynamisch durchführbar ist, worin das Übertragen des aktualisierten Trajektorienplankandidaten vom Szenarienauswahlmodul zum Echtzeit-Trajektorienplanungsmodul auf das Bestimmen reagiert, dass der aktualisierte Trajektorienplankandidat der optimale Kandidat ist.
Verfahren nach Anspruch 9, ferner umfassend, als Reaktion auf ein Bestimmen, dass der aktualisierte Trajektorienplankandidat nicht der optimale Kandidat ist, das Übertragen einer Anforderung vom Echtzeit-Trajektorienplanungsmodul an das Szenarienauswahlmodul für den aktualisierten Trajektorienplankandidaten mit den aktualisierten zweitniedrigsten jeweiligen Fahrtkosten.