DE102019127363A1 - Lichtbasierte spurwechselsteuerung - Google Patents

Lichtbasierte spurwechselsteuerung Download PDF

Info

Publication number
DE102019127363A1
DE102019127363A1 DE102019127363.3A DE102019127363A DE102019127363A1 DE 102019127363 A1 DE102019127363 A1 DE 102019127363A1 DE 102019127363 A DE102019127363 A DE 102019127363A DE 102019127363 A1 DE102019127363 A1 DE 102019127363A1
Authority
DE
Germany
Prior art keywords
vehicle
light
computer
lane change
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019127363.3A
Other languages
English (en)
Inventor
Linjun Zhang
Helen Elizabeth Kourous-Harrigan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102019127363A1 publication Critical patent/DE102019127363A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/18Propelling the vehicle
    • B60W30/18009Propelling the vehicle related to particular drive situations
    • B60W30/18163Lane change; Overtaking manoeuvres
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/02Control of position or course in two dimensions
    • G05D1/021Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0276Control of position or course in two dimensions specially adapted to land vehicles using signals provided by a source external to the vehicle
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096733Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place
    • G08G1/096741Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place where the source of the transmitted information selects which information to transmit to each vehicle
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096791Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/16Anti-collision systems
    • G08G1/161Decentralised systems, e.g. inter-vehicle communication
    • G08G1/162Decentralised systems, e.g. inter-vehicle communication event-triggered
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/16Anti-collision systems
    • G08G1/167Driving aids for lane monitoring, lane changing, e.g. blind spot detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891Revocation or update of secret information, e.g. encryption key update or rekeying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00Input parameters relating to data
    • B60W2556/45External transmission of data to or from the vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84Vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Atmospheric Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Computing Systems (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Offenbarung stellt eine lichtbasierte Spurwechselsteuerung bereit. Bei einer Bestimmung zum Ausführen eines Spurwechsels kann eine lichtbasierte Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug gesendet werden, um den Spurwechsel zu verhandeln. Bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug kann der Spurwechsel ausgeführt werden.

Description

  • TECHNISCHES GEBIET
  • Die Offenbarung betrifft im Allgemeinen Fahrzeuglenkung und -steuerung.
  • ALLGEMEINER STAND DER TECHNIK
  • Es ist ein herausforderndes Problem für ein Fahrzeug, insbesondere ein autonomes Fahrzeug, Fahrspuren wechseln zu können, ohne ein inakzeptables Risiko einer Kollision zu erfahren oder darzustellen. Dies trifft zu, egal ob Fahrzeuge auf benachbarten Fahrspuren durch einen Computer oder durch einen Menschen betrieben werden. Herkömmliche Sätze von bordeigenen Sensoren (z. B. Kamera, Radar, LiDAR usw.) können die Bewegung oder künftigen Wege anderer Fahrzeuge nicht mit hoher Gewissheit vorhersagen.
  • KURZDARSTELLUNG
  • Ein System kann einen Computer umfassen, der einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausführbar sind, um bei einer Bestimmung zum Ausführen eines Spurwechsels eine lichtbasierte Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug zu senden, um den Spurwechsel zu verhandeln; und bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug, den Spurwechsel auszuführen. Der Sicherheitsschlüssel kann ein Sicherheitszertifikat, eine Codierungsregel und eine Verschlüsselungsregel beinhalten. Die Anweisungen können ferner Anweisungen beinhalten, um zumindest ein Zertifikat in dem Sicherheitsschlüssel von einem straßenseitigen Infrastrukturelement zu empfangen. Die Anweisungen können ferner Anweisungen umfassen, um eine zusammen mit dem Sicherheitsschlüssel von dem straßenseitigen Infrastrukturelement empfangene Signatur zu verifizieren. Das System kann ferner ein straßenseitiges Infrastrukturelement umfassen, das einen zweiten Computer mit einem zweiten Prozessor und einem zweiten Speicher beinhaltet, wobei der zweite Speicher zweite Anweisungen speichert, die durch den Prozessor ausführbar sind, um den Sicherheitsschlüssel zu generieren und zu übertragen. Der Sicherheitsschlüssel kann durch nicht-lichtbasierte Kommunikation bereitgestellt werden. Die Anweisungen können ferner Anweisungen umfassen, um vor dem Senden der lichtbasierten Anfragekommunikation eine lichtbasierte Handshake-Nachricht zu senden. Die Anweisungen können ferner Anweisungen beinhalten, um einen Spurwechselplan über lichtbasierte Kommunikation zu senden. Die Anweisungen können ferner Anweisungen umfassen, um eine Antwort auf den Spurwechselplan über lichtbasierte Kommunikation zu empfangen. Die Anweisungen können ferner Anweisungen umfassen, um den Spurwechsel abzubrechen, wenn bestimmt wird, dass ein zweites Zielfahrzeug Priorität auf der Zielfahrspur hat.
  • Ein Verfahren kann Folgendes umfassen: bei einer Bestimmung zum Ausführen eines Spurwechsels, Senden einer lichtbasierten Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug, um den Spurwechsel zu verhandeln; und bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug, Ausführen des Spurwechsels. Der Sicherheitsschlüssel kann ein Sicherheitszertifikat, eine Codierungsregel und eine Verschlüsselungsregel beinhalten. Das Verfahren kann ferner Empfangen zumindest eines Zertifikats in dem Sicherheitsschlüssel von einem straßenseitigen Infrastrukturelement umfassen. Das Verfahren kann ferner Verifizieren einer zusammen mit dem Sicherheitsschlüssel von dem straßenseitigen Infrastrukturelement empfangenen Signatur umfassen. Das Verfahren kann ferner Generieren und Übertragen des Sicherheitsschlüssels von einem straßenseitigen Infrastrukturelement umfassen. Der Sicherheitsschlüssel kann durch nicht-lichtbasierte Kommunikation bereitgestellt werden. Das Verfahren kann ferner, vor dem Senden der lichtbasierten Anfragekommunikation, Senden einer lichtbasierten Handshake-Nachricht umfassen. Das Verfahren kann ferner Senden eines Spurwechselplans über lichtbasierte Kommunikation umfassen. Das Verfahren kann ferner Empfangen einer Antwort auf den Spurwechselplan über lichtbasierte Kommunikation umfassen. Das Verfahren kann ferner Abbrechen des Spurwechsels umfassen, wenn bestimmt wird, dass ein zweites Zielfahrzeug Priorität auf der Zielfahrspur hat.
  • Figurenliste
    • 1 ist ein Diagramm eines beispielhaften lichtbasierten Fahrzeug-Fahrzeug-Kommunikationssystems.
    • 2 ist ein Blockdiagramm eines beispielhaften Host-Fahrzeugs.
    • 3 ist eine Draufsicht auf einen beispielhaften lichtbasierten Kommunikationstransceiver.
    • 4 ist ein Diagramm eines Prozesses.
    • 5 ist ein Diagramm eines Prozesses.
  • BESCHREIBUNG
  • 1 ist ein Diagramm eines beispielhaften lichtbasierten Fahrzeug-Fahrzeug-Kommunikationssystems 100. Ein erstes Fahrzeug 101 sowie auch ein oder mehrere zweite Fahrzeuge 102 können in einer gleichen Richtung auf jeweiligen Fahrspuren 135, 140 einer Straße 130 fahren. Jedes Fahrzeug 101, 102 sowie ein Infrastrukturelement 150 kann einen daran montierten lichtbasierten Kommunikationstransceiver 105 aufweisen. Das Infrastrukturelement 150 kann von Zeit zu Zeit ein Sicherheitszertifikat, das von jedem Fahrzeug 101, 102 unterhalten wird, aktualisieren. Beim Bestimmen eines Spurwechsels kann das Fahrzeug 101 eine lichtbasierte Kommunikation mit einem oder mehreren anderen Fahrzeugen 102 einleiten. Die lichtbasierte Kommunikation kann mit dem Sicherheitszertifikat authentifiziert werden. Nachdem die Fahrzeuge 101, 102 die Authentizität und Sicherheit der lichtbasierten Kommunikation ermittelt haben, kann die Kommunikation zwischen den Fahrzeugen 101, 102 dann Kommunikation beinhalten, um einen Spurwechsel des Fahrzeugs 101 zu verhandeln und/oder zu planen.
  • 2 ist ein Blockdiagramm eines beispielhaften Fahrzeugs 101, 102, das typischerweise einen Lichttransceiver 105, eine Computer 110, Sensoren 115 sowie Aktoren 120, die Komponenten 125 betätigen können, beinhaltet. Die Fahrzeuge 101, 102 sind typischerweise maschinenangetriebene Landfahrzeuge, wie etwa ein Auto, ein Lastwagen usw. Das Fahrzeug 101 wird manchmal als „Host“-Fahrzeug 101 bezeichnet, um das Fahrzeug 101 von anderen Fahrzeugen 102, d. h. Zielfahrzeugen 102, die aus Sicht des Host-Fahrzeugs 101 Objekte oder Ziele sind, die bei der Wegeplanung und/oder der Navigation des Fahrzeugs 101 zu vermeiden und/oder zu berücksichtigen sind, zu unterscheiden.
  • Der Lichttransceiver 105, der nachstehend in Bezug auf 2 weiter erörtert wird, kann Lichtkommunikation (manchmal als „lichtbasierte Kommunikation“ bezeichnet) zwischen Fahrzeugen 101, 102 und/oder einem Infrastrukturelement 150 bereitstellen. Zusätzlich zum Lichttransceiver 105 kann das Fahrzeug andere Mechanismen beinhalten, wie etwa verschiedene Funkfrequenz-Transceiver, um dem Fahrzeugcomputer 110 zu ermöglichen, mit einem oder mehreren Infrastrukturelementen 150, anderen Fahrzeugen 102 und/oder einem oder mehreren entfernten Computerservern (nicht gezeigt) z. B. gemäß Fahrzeug-Fahrzeug- oder Fahrzeug-Infrastruktur-Kommunikationssystemen zu kommunizieren.
  • Der Computer 110 beinhaltet einen Prozessor und einen Speicher, wie sie bekannt sind. Der Speicher beinhaltet eine oder mehrere Arten von computerlesbaren Medien und speichert Anweisungen, die durch den Computer 110 zum Durchführen verschiedener Vorgänge, einschließlich solcher, die in der vorliegenden Schrift offenbart sind, ausführbar sind.
  • Der Computer 110 kann ein Fahrzeug 101, 102 in einem autonomen, einem halbautonomen oder einem nicht autonomen (oder manuellen) Modus betreiben. Für die Zwecke dieser Offenbarung wird ein autonomer Modus als ein Modus definiert, in dem Antreiben, Bremsen und Lenken jedes Fahrzeugs 101, 102 jeweils durch den Computer 110 gesteuert werden; in einem halbautonomen Modus steuert der Computer 110 eines oder zwei von Antreiben, Bremsen und Lenken des Fahrzeugs 101; in einem nicht autonomen Modus steuert ein menschlicher Fahrzeugführer das Antreiben, Bremsen und Lenken des Fahrzeugs 101.
  • Der Computer 110 kann Programmierung beinhalten, um eine oder mehrere von Komponenten 125 des Fahrzeug 101, 102, z. B Bremsen, Antrieb (z. B. Steuerung der Beschleunigung des Fahrzeugs durch Steuern von einem oder mehreren von einer Brennkraftmaschine, einem Elektromotor, Hybridmotor usw.), Lenkung, Klimasteuerung, Innen- und/oder Außenbeleuchtung usw. des Fahrzeugs 101, 102 zu betreiben, sowie um zu bestimmen, ob und wann der Computer 110 derartige Vorgänge anstelle eines menschlichen Fahrzeugführers steuern soll. Des Weiteren kann der Computer 110 programmiert sein, um zu bestimmen, ob und wann ein menschlicher Fahrzeugführer derartige Vorgänge steuern soll.
  • Der Computer 110 kann mehr als einen Prozessor, z.B. beinhaltet in elektronischen Steuerungseinheiten (electronic controller units - ECUs) oder dergleichen, die in dem Fahrzeug zum Überwachen und/oder Steuern verschiedener Fahrzeugkomponenten 125, z. B. einer Antriebsstrangsteuerung, einer Bremssteuerung, einer Lenkungssteuerung usw., beinhaltet sind, beinhalten oder kommunikativ mit diesem gekoppelt sein, z. B. über einen Kommunikationsbus des Fahrzeugs 101, 102 oder ein anderes drahtgebundenes oder drahtloses Netzwerk des Fahrzeugs 101, 102. Der Computer 110 ist im Allgemeinen zur Kommunikation in einem Fahrzeugkommunikationsnetzwerk angeordnet, das einen Kommunikationsbus in dem Fahrzeug beinhalten kann, wie etwa ein Controller Area Network (CAN) oder dergleichen, und/oder andere drahtgebundene und/oder drahtlose Mechanismen.
  • Über das Netzwerk des Fahrzeugs 101, 102 kann der Computer 110 Nachrichten an verschiedene Vorrichtungen in dem Fahrzeug übertragen und/oder Nachrichten von den verschiedenen Vorrichtungen, z. B. Sensoren 115, einem Aktor 120, einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI) usw., empfangen. Alternativ oder zusätzlich kann in den Fällen, in denen der Computer 110 tatsächlich eine Vielzahl von Vorrichtungen umfasst, das Kommunikationsnetzwerk des Fahrzeugs 101, 102 für Kommunikationen zwischen Vorrichtungen verwendet werden, die in dieser Offenbarung als der Computer 110 dargestellt sind. Ferner können, wie nachstehend erwähnt, verschiedene Steuerungen und/oder Sensoren 115 dem Computer 110 Daten über das Fahrzeugkommunikationsnetzwerk bereitstellen.
  • Die Sensoren 115 des Fahrzeugs 101, 102 können zusätzlich zu Lichtdetektoren, die in dem Lichttransceiver 105 beinhaltet sein können, eine Vielzahl von Vorrichtungen beinhalten, die bekanntermaßen Daten für den Computer 110 bereitstellen. Zum Beispiel können die Sensoren 115 Light-Detection-and-Ranging-Sensoren (LIDAR-Sensoren) 115 usw. beinhalten, die auf einer Oberseite des Fahrzeugs 101, 102, hinter einer Windschutzscheibe des Fahrzeugs 101, 102, um das Fahrzeug 101, 102 herum usw. angeordnet sind, die relative Positionen, Größen und Formen von Objekten bereitstellen, die das Fahrzeug 101, 102 umgeben. Als ein weiteres Beispiel können ein oder mehrere Radarsensoren 115, die an Stoßfängern des Fahrzeugs 101, 102 befestigt sind, Daten bereitstellen, um Positionen der Objekte, zweiten Fahrzeuge 102 usw. relativ zu der Position des Fahrzeugs 101, 102 bereitzustellen. Die Sensoren 115 können ferner alternativ oder zusätzlich zum Beispiel Kamerasensor(en) 115 beinhalten, z. B. mit Sicht nach vorne, zur Seite usw., um Bilder von einem Bereich um das Fahrzeug 101, 102 herum bereitzustellen, einen Ultraschallsensor 115 usw.
  • Die Aktoren 120 des Fahrzeugs 101, 102 sind über Schaltungen, Chips oder andere elektronische und/oder mechanische Komponenten implementiert, die unterschiedliche Fahrzeugteilsysteme gemäß geeigneten Steuersignalen, wie bekannt, betätigen können. Die Aktoren 120 können verwendet werden, um Komponenten 125, darunter Bremsung, Beschleunigung und Lenkung, eines Fahrzeugs 101, 102 zu steuern.
  • Im Kontext der vorliegenden Offenbarung ist eine Fahrzeugkomponente 125 eine oder mehrere Hardwarekomponenten und beliebige darin gespeicherte und/oder durch diese ausführbare Programmanweisungen, die dazu ausgelegt sind, eine mechanische oder elektromechanische Funktion oder Operation durchzuführen - wie etwa das Bewegen des Fahrzeugs 101, 102, das Abbremsen oder Anhalten des Fahrzeugs 102, das Lenken des Fahrzeugs 101, 102 usw. Nicht einschränkende Beispiele für Komponenten 125 beinhalten eine Antriebskomponente (die z. B. eine Brennkraftmaschine und/oder einen Elektromotor usw. beinhaltet), eine Getriebekomponente, eine Lenkkomponente (die z. B. eines oder mehrere von einem Lenkrad, einer Lenkzahnstange usw. beinhalten kann), eine Bremskomponente, eine Einparkhilfekomponente, eine Komponente für adaptive Geschwindigkeitsregelung, eine adaptive Lenkkomponente, einen bewegbaren Sitz usw.
  • Zusätzlich kann der Computer 110 programmiert oder anderweitig konfiguriert sein (z. B. mit geeigneten Hardwareschnittstelle(n)), um über ein Fahrzeug-Fahrzeug-Kommunikationsmodul oder eine Fahrzeug-Fahrzeug-Kommunikationsschnittstelle 130 mit Vorrichtungen außerhalb des Fahrzeugs 101, 102, z. B. durch drahtlose Fahrzeugkommunikation (z. B. Fahrzeug-Fahrzeug-Kommunikation (F2F), Fahrzeug-Infrastruktur-Kommunikation (F2I oder F2X), Fahrzeug-Cloud-Kommunikation (F2C) usw.), mit einem Infrastrukturknoten 150 (typischerweise über direkte Funkfrequenzkommunikation) und/oder mit einem entfernten (d. h. außerhalb des Fahrzeugs 101, 102 und an einer geografischen Stelle außer Sichtweite (auch als Blickrichtung bezeichnet) des Fahrzeugs 101, 102 und des Knotens 150) Server 170 zu kommunizieren (üblicherweise über das Netzwerk 135). Das Modul 130 könnte einen oder mehrere Mechanismen beinhalten, durch welche die Computer 110 der Fahrzeuge 102 kommunizieren können, einschließlich einer beliebigen gewünschten Kombination aus drahtlosen (z. B. zellularen, drahtlosen, Satelliten-, Mikrowellen- und Funkfrequenz-) Kommunikationsmechanismen und einer beliebigen gewünschten Netzwerktopologie (oder Topologien, wenn eine Vielzahl von Kommunikationsmechanismen verwendet wird). Beispielhafte Kommunikationsmöglichkeiten, die für Fahrzeug-Fahrzeug (F2F) oder Fahrzeug-Infrastruktur (F2X)-Kommunikation verwendet werden können, beinhalten Mobilfunk, Bluetooth, IEEE 802.11, dedizierte Nahbereichs-Kommunikation (dedicated short range communication - DSRC) und/oder Weitverkehrsnetzwerke (wide area network - WAN), einschließlich Internet, die Datenkommunikationsdienste bereitstellen.
  • Ein Infrastrukturknoten oder -element 150 beinhaltet eine physische Struktur wie etwa einen Turm oder eine andere Trägerstruktur (z. B. eine Säule, ein Kasten, der an einem Brückenpfeiler befestigt werden kann, ein Mobilfunkmast, eine Verkehrszeichenhalterung usw.), an der verschiedene Hardware oder Ausrüstung, einschließlich eines Lichttransceivers 105 und möglicherweise verschiedener Sensoren, Computer usw. montiert, gelagert und/oder enthalten und mit Strom versorgt usw. sein können. Da es sich typischerweise in der Nähe einer Straße befindet, kann das Infrastrukturelement 150 als ein straßenseitiges Infrastrukturelement bezeichnet werden. Wie die Fahrzeuge 101, 102 kann ein Infrastrukturelement 150 einen Computer beinhalten, der Funkfrequenz- oder andere Kommunikation für oben beschriebene beispielhafte Kommunikation steuert. Ein Infrastrukturknoten 150 ist zur einfacheren Veranschaulichung in 1 gezeigt, das System 100 könnte und würde wahrscheinlich aber zehn, hunderte oder tausende von Knoten 150 beinhalten. Der Infrastrukturknoten 150 ist typischerweise stationär, d. h. an einem konkreten physischen Standort fixiert und von dort nicht beweglich. Die Sensoren des Infrastrukturelements 150 können zusätzlich zu Lichtdetektoren, die in einem Lichttransceiver 105 beinhaltet sein können, einen oder mehrere Sensoren beinhalten, wie etwa zuvor für die Sensoren 115 des Fahrzeugs 105 beschrieben, z. B. LiDAR, Radar, Kameras, Ultraschallsensoren usw. Obgleich zur vereinfachten Veranschaulichung nicht gezeigt, beinhaltet der Infrastrukturknoten 150 auch eine Stromquelle, wie etwa eine Batterie, Solarstromzellen und/oder eine Verbindung mit einem Stromnetz.
  • Eine Draufsicht auf einen beispielhaften lichtbasierten Kommunikationstransceiver 105 wird in 2 bereitgestellt. Ein Sender 205 kann bereitgestellt sein, um lichtbasierte Kommunikation, z. B. in herkömmlicher Weise, zu senden oder zu übertragen. Das für derartige Kommunikation verwendete Licht kann im sichtbaren oder unsichtbaren Spektrum liegen. Zum Beispiel könnte der Sender 205 eine Anordnung von einer oder mehreren Leuchtdioden (LED) beinhalten und könnte ein in dem Sender 205 beinhalteter Prozessor programmiert sein, um eine Modulation des LED-generierten Lichts zu verursachen. Der Sender 205 kann auf einer drehbaren Plattform 215 bereitgestellt sein. Zum Beispiel kann ein Motor (nicht gezeigt) bereitgestellt sein, um die Plattform 215 zu drehen, sodass der Sender 205 Licht in mehrere Richtungen übertragen kann, in einem Beispiel z. B. in eine beliebige Richtung über eine Reichweite von 360 Grad. Das heißt, der Sender 205 kann Licht auf einem Strahl mit einer Breite von nur 1 bis 2 Grad emittieren, aber der Motor kann die Plattform 215 um bis zu 360 Grad drehen. Ferner kann sich eine Empfangsfläche 210 bis zu 360 Grad um einen Umfang oder Umkreis des Transceivers 105 erstrecken. Die Empfangsfläche 210 kann herkömmliche fotosensitive Elemente beinhalten, die für eine Entnahme von Daten aus einem empfangenen modulierten Lichtstrahl bereitgestellt sind.
  • Gewisse Formen der hierin erörterten lichtbasierten Kommunikation beinhalten einen Schlüssel. Im Kontext dieser Offenbarung ist ein „Schlüssel“ ein Datensatz, der zumindest verwendet werden kann, um eine Quelle einer Nachricht zu verifizieren oder zu authentifizieren. Ein Schlüssel kann typischerweise auch verwendet werden, um festzulegen, wie Nachrichteninhalte aus Rohdaten (typischerweise eine Reihe von Bits, d. h. eine Sequenz von Binärdaten in der Form einer 1 oder 0), die in einer Nachricht beinhaltet sind, zu entnehmen sind. Dementsprechend beinhaltet ein Schlüssel typischerweise drei Elemente: ein Zertifikat, eine Verschlüsselungsregel und eine Codierungsregel.
  • Ein Teil des Schlüssels oder der gesamte Schlüssel (zumindest ein Zertifikat) kann einem Fahrzeug 101, 102 von einem Infrastrukturelement 150 bereitgestellt werden. Zum Beispiel das Infrastrukturelement 150, wie vorstehend erörtert, für F2X-Kommunikation über eine Vielfalt von Protokollen oder Kommunikationsmedien. Ein in dem Infrastrukturelement 150 beinhalteter Computer kann programmiert sein, um F2X-Kommunikation zu betätigen, z. B. eine Funkfrequenz-F2X-Kommunikation zu betätigen, um einen Schlüssel bereitzustellen.
  • In einem Beispiel könnte ein Infrastrukturelement 150 periodisch, z. B. einmal pro Minute, eine Nachricht, die einen Schlüssel beinhaltet, z. B. unter Verwendung von F2X-Kommunikation für Fahrzeuge 101, 102 innerhalb einer Empfangsreichweite des Infrastrukturelements 150 aussenden. Zum Beispiel könnte ein in oder an dem Infrastrukturelement 150 beinhalteter Computer Programmierung beinhalten, um den Schlüssel z. B. über Kommunikationsmechanismen in oder an dem Infrastrukturelement 150 zu generieren und zu übertragen. Somit würden die Fahrzeuge 101, 102 in einem Empfangsbereich des Infrastrukturelements 150 einen gleichen Schlüssel empfangen und könnten einander somit in einer lichtbasierten Kommunikation, wie hierin beschrieben, authentifizieren. Um den Schlüssel bereitzustellen, könnte eine ausgesendete Nachricht von einem Infrastrukturknoten 150 zwei Elemente beinhalten, erstens eine Infrastruktursignatur und zweitens den Schlüssel für die Fahrzeuge 101, 102 zur Verwendung für die hierin beschriebene lichtbasierte Kommunikation. Die Infrastruktursignatur ist typischerweise eine Sequenz von verschlüsselten Daten, die durch autorisierte Vorrichtungen, z. B. Fahrzeugcomputer 110, entschlüsselt werden kann. Zum Beispiel könnte ein Fahrzeugcomputer 110 einen Verschlüsselungs-/Entschlüsselungsschlüssel für eine z. B. durch einen Hersteller der Fahrzeugs 101, 102, durch ein Servicecenter usw. in seinem Speicher gespeicherte Infrastruktursignatur aufweisen. Ferner könnte der Schlüssel, oder zumindest dessen Zertifikatabschnitt, der zusammen mit der Infrastruktursignatur bereitgestellt wird, durch Zufalls- oder Pseudozufalls-Zahlengenerierungstechnik generiert werden, um die Möglichkeit, dass eine nicht autorisierte Vorrichtung den Schlüssel errät, zu minimieren.
  • Im vorliegenden Kontext haben ein Zertifikat oder Sicherheitszertifiakt die übliche Bedeutung, die diesen Begriffen in Bezug auf digitale Kommunikation zugeordnet ist, d. h. ein Datensatz, der verwendet werden kann, um eine Nachrichtenquelle zu authentifizieren. Das heißt, ein Zertifikat beinhaltet typischerweise eine Sequenz von Daten, z. B. Bytes, festgelegt durch ein Zertifikat einer Behörde, z. B. einer Agentur der Regierung oder eines Unternehmens, die überprüft werden kann, um eine Nachrichtenquelle zu authentifizieren.
  • Eine Verschlüsselungsregel legt fest, wie Nachrichteninhalte, z. B. Nutzdaten, aus Rohdaten zu entnehmen sind. Verschiedene Verschlüsselungsregeln, einschließlich verschiedener herkömmliche Regeln, können im vorliegenden Kontext verwendet werden. Diese beinhalten Regeln wie XOR, Bitsprung, Autocodierer usw. XOR ist das, was als ein additiver Code bezeichnet wird, bei dem zwei Datenketten gleicher Läge erforderlich sind, aus denen Nutzdaten entnommen werden können, d. h. die Datenketten wurden mit einer bitweisen XOR (exklusives ODER) Operation codiert. Bitsprung ist eine Codierungstechnik, bei der Nutzdaten erlangt werden, indem ein ursprünglicher Datensatz mit festgelegten Bitschritten erneut abgetastet wird. Zum Beispiel könnte in einem Zwei-Bit-Sprung eine ursprüngliche Bitkette 11010001 sein, wobei die realen Nutzdaten, die zu entnehmen sind, 1101 sind. Ein Autocodierer ist ein Modell eines neuronalen Netzes zum Umwandeln von Rohdaten in Nutzdaten, wobei Modellparameter, wie etwa eine Anzahl von Schichten und eine Art der Schicht in dem neuronalen Netz, in dem Schlüssel beinhaltet sind.
  • Eine Codierungsregel ist eine Regel, die verwendet wird, um eine Bitsequenz in eine strukturierte Nachricht umzuwandeln. Beispielhafte Codierungsregeln beinhalten Codierung mit LCM (last common multiple - kleinstes gemeinsames Vielfaches), PROTO (protocol buffer - Protokollpuffer), ROS-Bild, BER (basic encoding rule - grundlegende Codierungsregel) und OER (octet encoding rules - Achtbitzeichen-Codierungsregeln).
  • 4 ist ein Diagramm eines beispielhaften Prozesses 400 für ein Host-Fahrzeug 101, um einen Spurwechsel, der lichtbasierte Kommunikation beinhaltet, zu steuern. Der Prozess 400 kann durch einen Prozessor eines Computers 110 gemäß in einem Speicher des Computer 110 gespeicherten Anweisungen in Kombination mit anderen Komponenten 125 des Fahrzeugs 101 ausgeführt werden, wie hierin erörtert.
  • Der Prozess 400 kann in einem Block 405 beginnen, in dem der Computer 110 bestimmt, dass das Fahrzeug 101 einen Spurwechselvorgang ausführen soll. Zum Beispiel könnte der Computer 110 eine Bedienereingabe, z.B. über eine Mensch-Maschine-Schnittstelle oder dergleichen, empfangen, um einen Spurwechselvorgang durchzuführen und/oder könnte auf Grundlage eines Wegeplanungsalgorithmus oder dergleichen bestimmen, Fahrspuren zu wechseln. Das Bestimmen eines Spurwechsels beinhaltet typischerweise Festlegen einer Zielfahrspur 140, von der aus sich das Fahrzeug 101 von einer aktuellen Fahrspur 135 bewegen soll.
  • Als nächstes bestimmt der Computer 110 in einem Block 410, ob ein Zielfahrzeug 102 auf einer Zielfahrspur 140 erkannt wird, z. B. unter Verwendung herkömmlicher Objekterkennungsalgorithmen auf Grundlage von Daten von den Sensoren 115. Falls dies nicht der Fall ist, geht der Prozess 400 weiter zu einem Block 455, um einen Spurwechsel auszuführen. Anderenfalls geht der Prozess 400 weiter zu einem Block 415.
  • In Block 415 veranlasst der Computer 110 eine Betätigung des Lichttransceivers 105 des Host-Fahrzeugs 101, um eine Handshake-Nachricht an ein Fahrzeug 102 auf einer benachbarten Zielfahrspur 140 zu übertragen. Wie vorstehend erwähnt, ist ein Lichttransceiver 105 typischerweise dazu konfiguriert, lichtbasierte Nachrichten gerichtet zu übertragen. Ferner ist der Zweck der Handshake-Nachricht, eine Kommunikation zwischen dem Host-Fahrzeug 101 und einem festgelegten Zielfahrzeug 102 aufzubauen. Daher kann der Computer 110 die Betätigung des Lichttransceivers 105 veranlassen, um die Plattform 215 zu drehen, sodass der Sender 205 in eine Richtung ausgerichtet ist oder in diese zielt, um mit einem festgelegten Zielfahrzeug 102 zu kommunizieren.
  • Die Handshake-Nachricht ist typischerweise eine unverschlüsselte Nachricht, die in einer Sequenz von Bits codiert ist. Die im System 100 beinhalteten Fahrzeuge 101, 102 könnten Computer 110 beinhalten, die programmiert sind, um Handshake-Nachrichten gemäß einem festgelegten Satz aus einer oder mehreren Codierungs-/Decodierungsregeln zu codieren und zu decodieren. Die Handshake-Nachricht kann grundlegende Informationen zum Aufbauen einer lichtbasierten Kommunikation zwischen Fahrzeugen 101, 102 beinhalten, wie etwa Identifizierungsinformationen für jedes Fahrzeug 101, 102. Zum Beispiel könnte ein Host-Fahrzeug 101 eine Handshake-Nachricht, die Marke, Modell, Farbe, Fahrgestellnummer usw. des Host-Fahrzeugs 101 beinhaltet, an ein Zielfahrzeug 102 übertragen. Das Zielfahrzeug 102, das die Handshake-Nachricht empfängt, könnte dann eine Antwort-Handshake-Nachricht mit ähnlichen Identifizierungsdaten des Zielfahrzeugs 102 bereitstellen. Zusätzlich könnte eine Handshake-Nachricht des Host-Fahrzeugs 101 Identifizierungsinformationen für ein festgelegtes Zielfahrzeug 102 beinhalten, woraufhin ein Zielfahrzeug 102 nur dann antworten kann, wenn es das Fahrzeug ist, das durch die empfangenen Identifizierungsinformationen des Zielfahrzeugs 101 identifiziert wurde.
  • Nach dem Block 415 bestimmt der Computer 110, ob eine Antwort-Handshake-Nachricht von dem Zielfahrzeug 102, an das die Handshake-Nachricht in Block 415 gesendet wurde, empfangen wurde. Falls dies nicht der Fall ist, geht der Prozess 400 weiter zu einem Block 425. Falls eine Antwort-Handshake-Nachricht empfangen wurde, geht der Prozess 400 dann weiter zu einem Block 430. Der Computer 110 kann auf Grundlage von Decodieren von in dem Lichttransceiver 105 empfangenen Lichtimpulsen und Bestimmen, dass Nutzdaten der Antwort-Handshake-Nachricht den Empfang bestätigen und/oder Identifizierungsinformationen des festgelegten Zielfahrzeugs 102 bereitstellen, bestimmen, ob eine Antwort-Handshake-Nachricht empfangen wurde.
  • In Block 425 bestimmt der Computer 110, ob die Handshake-Nachricht erneut versucht, d. h. erneut gesendet, werden soll. Zum Beispiel kann ein festgelegter Zeitraum verstrichen sein, kann der Computer 110 bestimmen, dass ein Spurwechsel nicht länger in dem Wegeplanungsalgorithmus beinhaltet ist, könnte eine Benutzereingabe empfangen werden, einen Spurwechselvorgang abzubrechen usw. Falls die Handshake-Nachricht nicht erneut gesendet wird, endet dann der Prozess 400. Andernfalls kehrt der Prozess 400 zu dem Block 415 zurück.
  • Nach dem Block 420, wenn die Handshake-Nachricht gesendet und bestätigt wurde, können weitere Nachrichten in dem Prozess 400 mit einem sicheren Schlüssel, wie vorstehend beschrieben, gesendet werden. Zum Beispiel sendet der Computer 110 in Block 430 eine Spurwechselanfrage zusammen mit einem Schlüssel (einschließlich eines Zertifikats und einer Codierungsregel und einer Verschlüsselungsregel, wie vorstehend beschrieben) an das Zielfahrzeug 102. Die Spurwechselanfrage kann wie in dem Schlüssel festgelegt verschlüsselt und codiert werden und kann zusätzlich zu dem Schlüssel eine Anfrage von dem Host-Fahrzeug 101 beinhalten, auf eine Zielfahrspur 140 zu wechseln, auf der das Zielfahrzeug 102 aktuell fährt. Ferner kann eine Spurwechselanfrage Informationen, wie etwa eine geplante Geschwindigkeit, mit der das Host-Fahrzeug 101 beim Spurwechsel fahren wird, ob das Host-Fahrzeug 101 plant, sich vor oder hinter das Zielfahrzeug 102 zu bewegen usw., festlegen.
  • Als nächstes bestimmt der Computer 110 in einem Block 435, ob eine Nachricht von einem Fahrzeug 102 empfangen wurde, die die Spurwechselanfrage des Blocks 430 akzeptiert. Falls dies nicht der Fall ist, z. B. falls eine negative Antwort empfangen wird oder falls keine Antwort innerhalb eines festgelegten Zeitraums, z. B. zwei Sekunden, empfangen wird, geht der Prozess 400 dann weiter zu einem Block 440. Anderenfalls geht der Prozess 400 weiter zu einem Block 445.
  • In Block 440 bestimmt der Computer 110, ob erneut versucht wird, die Spurwechselanfrage zu senden, falls z. B. eine negative Antwort in Block 435 empfangen wurde, falls der Computer 110 und/oder ein Bediener des Fahrzeugs 101 die Spurwechselanfrage abgebrochen hat oder ein festgelegter Zeitraum verstrichen ist, dann kann der Computer 110 bestimmen, die Spurwechselanfrage nicht erneut zu versuchen, woraufhin der Prozess 400 endet. Andernfalls kehrt der Prozess 400 nach Block 440 zu Block 430 zurück.
  • In Block 445 veranlasst der Computer 110 eine Betätigung des Lichttransceivers 105, um einen Spurwechselplan an das Zielfahrzeug 102 zu senden. Ein Teil des Spurwechselplans oder der gesamte Spurwechselplan wurde möglicherweise in der zuvor in Bezug auf Block 430 beschriebenen Nachricht gesendet, auch wenn einige oder alle der Daten in dem Spurwechselplan seit dem Block 430 möglicherweise aktualisiert wurden. Zum Beispiel kann ein Spurwechselplan einen Zeitpunkt, zu dem sich das Fahrzeug 101 von einer aktuellen Fahrspur 135 auf eine Zielfahrspur 140 bewegen wird, eine Geschwindigkeit, mit der sich das Fahrzeug 101 bewegen wird, ob sich das Fahrzeug 101 vor oder hinter ein Fahrzeug 102 bewegen wird usw. beinhalten.
  • In Block 450 bestimmt der Computer 110, ob der Spurwechselplan ausgeführt werden soll. Zum Beispiel könnte eine Nachricht von einem Zielfahrzeug 102 und/oder einem Infrastrukturelement 150 empfangen werden, die festlegt, einen Spurwechsel nicht durchzuführen, oder könnte es sein, dass das Zielfahrzeug 102 keinen Antwortplan gesendet hat, wie nachstehend in Bezug auf 5 erörtert wird. Das Zielfahrzeug 102 könnte bestimmen, dass sein Wegeplan den durch das Host-Fahrzeug 101 geplanten Spurwechsel nicht länger unterstützt, z. B. da es notwendig ist, aufgrund anderer Zielfahrzeuge 102 zu bremsen oder zu beschleunigen. Ferner könnte ein Infrastrukturelement 150 eine Nachricht entweder über einen Lichttransceiver 105 oder einen anderen Mechanismus, wie etwa funkbasierte F2X-Kommunikation, aussenden, die angibt, dass ein Fahrzeug 102 mit Priorität auf einer Zielfahrspur 140 fährt und/oder sich zur Zielfahrspur 140 bewegt, wodurch der Spurwechselplan des Host-Fahrzeugs 101 außer Kraft gesetzt wird. Falls der Computer 110 bestimmt, den Spurwechsel nicht auszuführen, endet dann der Prozess 400. Andernfalls geht der Prozess 400 weiter zu Block 455.
  • In Block 455 veranlasst der Computer 110 Aktoren 120 dazu, zu arbeiten, um Komponenten 125 des Fahrzeugs 101 zu betätigen, z. B. Lenkung, Antrieb und/oder Bremsung, um den geplanten Spurwechsel auszuführen, und um dies in Übereinstimmung mit einem von einem Fahrzeug 102 bereitgestellten Antwortplan zu tun. Zum Beispiel könnte ein Spurwechsel bei einer Geschwindigkeit des Fahrzeugs 101 gemäß einer Geschwindigkeit, die in einem Antwortplan des Fahrzeugs 102 festgelegt ist, ausgeführt werden. Gleichermaßen könnte ein Spurwechsel zu einem Zeitpunkt, der in einem Antwortplan des Fahrzeugs 102 festgelegt ist, ausgeführt werden. Im Anschluss an Block 455 endet der Prozess 400.
  • 5 ist ein Diagramm eines beispielhaften Prozesses 500 für ein Zielfahrzeug 102, um lichtbasierte Kommunikation für ein Host-Fahrzeug 101 bereitzustellen, damit es einen Spurwechsel, der lichtbasierte Kommunikation beinhaltet, steuert. Der Prozess 500 kann durch einen Prozessor eines Computers 110 eines Zielfahrzeugs 102 gemäß in einem Speicher des Computer 110 gespeicherten Anweisungen in Kombination mit anderen Komponenten 125 des Fahrzeugs 102 ausgeführt werden, wie hierin erörtert.
  • Der Prozess 500 beginnt in einem Block 505, in dem ein Zielfahrzeug 102 eine Handshake-Nachricht, z. B. wie vorstehend beschrieben, von einem Host-Fahrzeug 101 empfängt.
  • Als nächstes bestimmt ein Computer 110 des Zielfahrzeugs 102 in einem Block 510, ob eine Prioritätsdirektive oder -regel einen Spurwechsel, wie durch das Host-Fahrzeug 101 angefragt, verhindert. Zum Beispiel könnte ein erkanntes Notfallfahrzeug 102 auf der gleichen Fahrspur wie das Zielfahrzeug 102 Priorität gegenüber dem Host-Fahrzeug 101 erfordern, und bei Erkennen eines solchen Notfallfahrzeugs 102 könnte ein Computer 110 des Zielfahrzeugs 102 programmiert sein, um eine Handshake-Nachricht von dem Host-Fahrzeug 101 abzulehnen. Alternativ oder zusätzlich könnte ein Fahrzeug 102 mit Priorität, wie etwa ein Notfallfahrzeug, und/oder ein Infrastrukturelement 150 z. B. über F2F- oder F2X-Kommunikation eine Nachricht senden, die festlegt, dass das Zielfahrzeug 102 gegenüber einem weiteren Zielfahrzeug 102 für die Nutzung einer Zielfahrspur 140 Priorität gewähren soll. Wenn Priorität gewährt werden soll, dann endet der Prozess 500. Anderenfalls geht der Prozess 500 weiter zu einem Block 515.
  • In Block 515 antwortet das Zielfahrzeug 102 auf die Handshake-Nachricht, z. B. in einer vorstehend beschriebenen Art und Weise.
  • Als nächstes bestimmt das Zielfahrzeug 102 in einem Block 520, ob es einen anerkannten Schlüssel von dem Host-Fahrzeug 101 empfangen hat. Wie vorstehend erläutert, kann das Host-Fahrzeug 101 einen Schlüssel in einer lichtbasierten Kommunikation mit dem Zielfahrzeug 102 beinhalten. Der Sicherheitsschlüssel kann ein Sicherheitszertifikat beinhalten, das das Zielfahrzeug 102 unter Verwendung herkömmlicher Techniken authentifizieren kann. Der Computer 110 des Zielfahrzeugs 102 kann ferner verifizieren, dass der Schlüssel Regeln zum Entschlüsseln und Decodieren der empfangenen Nachricht beinhaltet. Falls ein Schlüssel empfangen wurde, geht der Prozess 500 dann weiter zu einem Block 530. Anderenfalls geht der Prozess 500 weiter zu einem Block 525.
  • In Block 525 bestimmt der Computer 110 des Zielfahrzeugs 102, ob weiter gewartet werden soll, um eine Nachricht mit einem Schlüssel von dem Host-Fahrzeug 101 zu empfangen. Zum Beispiel könnte das Zielfahrzeug 102 eine Nachricht empfangen, die angibt, dass ein weiteres Fahrzeug 102 nun Priorität und die Zielfahrspur 140 hat, könnte seinen Wegeplan so ändern, dass es nicht in der Lage ist, einen Spurwechsel mit dem Host-Fahrzeug 101 zu verhandeln, könnte ein festgelegter Zeitraum, z. B. zwei Sekunden, verstrichen sein usw. Falls der Computer 110 bestimmt, auf eine Nachricht mit einem Schlüssel zu warten, dann kehrt der Prozess 500 zu Block 520 zurück. Andernfalls endet der Prozess 500.
  • In Block 530 betätigt der Computer 110 des Zielfahrzeugs 102 seinen lichtbasierten Transceiver 105, um eine Zustimmung, z. B. wie vorstehend beschrieben, an das Host-Fahrzeug 101 zu senden. Zum Beispiel könnte der Computer 110 das Fahrzeug 102 autonom oder halbautonom betreiben und könnte bestimmen, eine Spurwechselanfrage von dem Host-Fahrzeug 101 in einen Wegeplan des Zielfahrzeugs 102 zu integrieren. Alternativ oder zusätzlich könnte ein menschlicher Bediener des Zielfahrzeugs 102 eine Nachricht über eine Mensch-Maschine-Schnittstelle (HMI) des Fahrzeugs 102 oder dergleichen empfangen, die die Spurwechselanfrage festlegt, und könnte eine Eingabe bereitstellen, um diese zu akzeptieren oder abzulehnen. Auch wenn der Block 530 nicht als ein Entscheidungsblock veranschaulicht ist, ist anzumerken, dass der Computer 110 des Fahrzeug 102 es ablehnen könnte, eine Zustimmung zur Spurwechselanfrage von dem Host-Fahrzeug 101 bereitzustellen, z. B. wie eben beschrieben.
  • Als nächstes bestimmt der Computer 110 des Zielfahrzeugs 102 in einem Block 535, ob er einen Spurwechselplan vom Host-Fahrzeug 101 empfangen hat. Falls dies nicht der Fall ist, geht der Prozess 500 weiter zu einem Block 540. Anderenfalls geht der Prozess 500 weiter zu einem Block 540.
  • In Block 540 bestimmt das Zielfahrzeug 102, ob weiter gewartet werden soll, um eine Nachricht mit einem Spurwechselplan von dem Host-Fahrzeug 101 zu empfangen, wie z. B. vorstehend bezüglich Block 525 beschrieben. Wenn bestimmt wird, nicht weiter zu warten, dann endet der Prozess 500. Andernfalls kehrt der Prozess 500 zu dem Block 535 zurück.
  • In Block 540 veranlasst der Computer 110 des Fahrzeugs 102 eine Betätigung des lichtbasierten Transceivers 105, um den Antwortplan zu senden. Der Antwortplan kann einfach eine Bestätigung sein, dass das Fahrzeug 102 in einer Weise, die mit dem vom Fahrzeug 101 bereitgestellten Plan übereinstimmt, funktionieren wird. Zum Beispiel kann der Antwortplan festlegen, dass das Fahrzeug 102 eine Geschwindigkeit beibehalten wird oder eine Geschwindigkeit verringern oder erhöhen wird, um dem Fahrzeug 101 zu ermöglichen, sich zu einem Platz hinter oder vor dem Fahrzeug 102 zu bewegen usw.
  • In einem Block 545 veranlasst der Computer 110 des Fahrzeugs 102 als nächstes die Aktoren 120 der Komponenten des Fahrzeugs 102 dazu zu arbeiten, um den Antwortplan auszuführen, z. B. zu lenken, zu beschleunigen und/oder zu bremsen, wie festgelegt, um den Spurwechsel durch das Host-Fahrzeug 101 zu ermöglichen. Im Anschluss an Block 545 endet der Prozess 500.
  • SCHLUSSFOLGERUNG
  • Im hierin verwendeten Sinne bedeutet der Ausdruck „im Wesentlichen“, dass eine Form, eine Struktur, ein Maß, eine Menge, eine Zeit usw. aufgrund von Mängeln bei Materialien, Bearbeitung, Herstellung, Datenübertragung, Berechnungszeit usw. von einem bzw. einer genauen beschriebenen Geometrie, Abstand, Maß, Menge, Zeit usw. abweichen kann.
  • Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen ein beliebiges aus einer Reihe von Computerbetriebssystemen einsetzen, einschließlich unter anderem Versionen und/oder Varianten der Sync®-Anwendung von Ford, AppLink/Smart Device Link Middleware, der Betriebssysteme Microsoft Automotive®, Microsoft Windows®, Unix (z. B. das Betriebssystem Solaris®, vertrieben durch die Oracle Corporation in Redwood Shores, Kalifornien), AIX UNIX, vertrieben durch International Business Machines in Armonk, New York, Linux, Mac OSX und iOS, vertrieben durch die Apple Inc. in Cupertino, Kalifornien, BlackBerry OS, vertrieben durch die Blackberry, Ltd. in Waterloo, Kanada, und Android, entwickelt von der Google, Inc. und der Open Handset Alliance, oder der Plattform QNX® CAR für Infotainment, angeboten von QNX Software Systems. Beispiele für Rechenvorrichtungen beinhalten unter anderem einen bordeigenen Fahrzeugcomputer, eine Computer-Workstation, einen Server, einen Desktop-, Notebook-, Laptop- oder Handcomputer oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung.
  • Computer und Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa die vorstehend aufgeführten, ausführbar sein können. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder ausgewertet werden, welcher unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, einschließlich unter anderem und entweder für sich oder in Kombination Java™, C, C++, Python, Matlab, Simulink, Stateflow, Visual Basic, Java Script, Perl, HTML usw. Einige dieser Anwendungen können auf einer virtuellen Maschine zusammengestellt und ausgeführt werden, wie beispielsweise die Java Virtual Machine, die Dalvik Virtual Machine oder dergleichen. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, einschließlich eines oder mehrerer der hierin beschriebenen Prozesse. Derartige Anweisungen und weitere Daten können unter Verwendung einer Vielzahl computerlesbarer Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw., gespeichert sind.
  • Speicher kann ein computerlesbares Medium (auch als prozessorlesbares Medium bezeichnet) beinhalten, das ein beliebiges nichttransitorisches (z. B. physisches) Medium beinhaltet, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die durch einen Computer (z. B. durch einen Prozessor eines Computers) ausgelesen werden können. Ein derartiges Medium kann viele Formen annehmen, einschließlich unter anderem nichtflüchtiger Medien und flüchtiger Medien. Nichtflüchtige Medien können zum Beispiel optische Platten oder Magnetplatten und andere dauerhafte Speicher beinhalten. Flüchtige Medien können beispielsweise einen dynamischen Direktzugriffsspeicher (dynamic random access memory - DRAM) beinhalten, der in der Regel einen Hauptspeicher darstellt. Derartige Anweisungen können durch ein oder mehrere Übertragungsmedien übertragen werden, darunter Koaxialkabel, Kupferdraht und Glasfaser, einschließlich der Drähte, die einen mit einem Prozessor einer ECU verbundenen Systembus umfassen. Gängige Formen computerlesbarer Medien beinhalten beispielsweise eine Diskette, eine Folienspeicherplatte, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen FLASH-EEPROM, einen beliebiger anderer Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das durch einen Computer ausgelesen werden kann.
  • Datenbanken, Daten-Repositorys oder sonstige Datenspeicher, die hierin beschrieben sind, können unterschiedliche Arten von Mechanismen zum Speichern von, Zugreifen auf und Abrufen von unterschiedlichen Arten von Daten einschließen, darunter eine hierarchische Datenbank, eine Gruppe von Dateien in einem Dateisystem, eine Anwendungsdatenbank in einem proprietären Format, ein relationales Datenbankverwaltungssystem (Relational Database Management System - RDBMS) usw. Jeder dieser Datenspeicher ist im Allgemeinen in einer Rechenvorrichtung beinhaltet, welche ein Computerbetriebssystem, wie beispielsweise eines der oben aufgeführten, verwendet, und es wird auf eine oder mehrere mögliche Weisen über ein Netzwerk darauf zugegriffen. Auf ein Dateisystem kann von einem Computerbetriebssystem zugegriffen werden, und es kann in verschiedenen Formaten gespeicherte Dateien beinhalten. Ein RDBMS setzt im Allgemeinen die strukturierte Abfragesprache (structured query language - SQL) zusätzlich zu einer Sprache zum Erstellen, Speichern, Bearbeiten und Ausführen gespeicherter Abläufe ein, wie etwa die vorstehend erwähnte PL/SQL-Sprache.
  • In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, PCs usw.) umgesetzt sein, die auf diesen zugeordneten computerlesbaren Speichermedien (z. B. Platten, Speicher usw.) gespeichert sind. Ein Computerprogrammprodukt kann derartige Anweisungen umfassen, die zum Ausführen der hierin beschriebenen Funktionen auf computerlesbaren Medien gespeichert sind.
  • Hinsichtlich der hierin beschriebenen Medien, Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte derartiger Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Prozesse jedoch so umgesetzt werden können, dass die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der hierin beschriebenen Reihenfolge abweicht. Es versteht sich zudem, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte hierin beschriebene Schritte weggelassen werden können. Anders ausgedrückt dienen hierin die Beschreibungen von Prozessen dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Ansprüche einschränken.
  • Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, werden dem Fachmann beim Lesen der vorstehenden Beschreibung ersichtlich sein. Der Umfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Ansprüche in Zusammenhang mit dem vollständigen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigen. Es wird erwartet und ist beabsichtigt, dass es hinsichtlich der hierin erörterten Fachgebiete künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Erfindung modifiziert und variiert werden kann und ausschließlich durch die folgenden Ansprüche eingeschränkt wird.
  • Allen in den Ansprüchen verwendeten Ausdrücken soll deren allgemeine und gewöhnliche Bedeutung zukommen, wie sie vom Fachmann aufgefasst wird, es sei denn, es wird ausdrücklich das Gegenteil angegeben. Insbesondere ist die Verwendung der Singularartikel wie etwa „ein“, „eine“, „der“, „die“, „das“ usw. dahingehend auszulegen, dass eines oder mehrere der aufgeführten Elemente genannt wird bzw. werden, es sei denn, ein Patentanspruch enthält ausdrücklich eine gegenteilige Einschränkung.
  • Gemäß der vorliegenden Erfindung wird ein System bereitgestellt, das einen Computer aufweist, der einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausführbar sind, um: bei einer Bestimmung zum Ausführen eines Spurwechsels eine lichtbasierte Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug zu senden, um den Spurwechsel zu verhandeln; und bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug, den Spurwechsel auszuführen.
  • Gemäß einer Ausführungsform beinhaltet der Sicherheitsschlüssel ein Sicherheitszertifikat, eine Codierungsregel und eine Verschlüsselungsregel.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um zumindest ein Zertifikat in dem Sicherheitsschlüssel von einem straßenseitigen Infrastrukturelement zu empfangen.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um eine zusammen mit dem Sicherheitsschlüssel von dem straßenseitigen Infrastrukturelement empfangene Signatur zu verifizieren.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch ein straßenseitiges Infrastrukturelement gekennzeichnet, das einen zweiten Computer mit einem zweiten Prozessor und einem zweiten Speicher beinhaltet, wobei der zweite Speicher zweite Anweisungen speichert, die durch den Prozessor ausführbar sind, um den Sicherheitsschlüssel zu generieren und zu übertragen.
  • Gemäß einer Ausführungsform wurde der Sicherheitsschlüssel durch nicht-lichtbasierte Kommunikation bereitgestellt.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um vor dem Senden der lichtbasierten Anfragekommunikation eine lichtbasierte Handshake-Nachricht zu senden.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um einen Spurwechselplan über lichtbasierte Kommunikation zu senden.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um eine Antwort auf den Spurwechselplan über lichtbasierte Kommunikation zu empfangen.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Anweisungen gekennzeichnet, um den Spurwechsel abzubrechen, wenn bestimmt wird, dass ein zweites Zielfahrzeug Priorität auf der Zielfahrspur hat.
  • Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren: bei einer Bestimmung zum Ausführen eines Spurwechsels, Senden einer lichtbasierten Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug, um den Spurwechsel zu verhandeln; und bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug, Ausführen des Spurwechsels.
  • Gemäß einer Ausführungsform beinhaltet der Sicherheitsschlüssel ein Sicherheitszertifikat, eine Codierungsregel und eine Verschlüsselungsregel.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Empfangen zumindest eines Zertifikats in dem Sicherheitsschlüssel von einem straßenseitigen Infrastrukturelement gekennzeichnet.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Verifizieren einer zusammen mit dem Sicherheitsschlüssel von dem straßenseitigen Infrastrukturelement empfangenen Signatur gekennzeichnet.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Generieren und Übertragen des Sicherheitsschlüssels von einem straßenseitigen Infrastrukturelement gekennzeichnet.
  • Gemäß einer Ausführungsform wurde der Sicherheitsschlüssel durch nicht-lichtbasierte Kommunikation bereitgestellt.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Senden einer lichtbasierten Handshake-Nachricht vor dem Senden der lichtbasierten Anfragekommunikation gekennzeichnet.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Senden eines Spurwechselplans über lichtbasierte Kommunikation gekennzeichnet.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Empfangen einer Antwort auf den Spurwechselplan über lichtbasierte Kommunikation gekennzeichnet.
  • Gemäß einer Ausführungsform ist die Erfindung ferner durch Abbrechen des Spurwechsels gekennzeichnet, wenn bestimmt wird, dass ein zweites Zielfahrzeug Priorität auf der Zielfahrspur hat.

Claims (14)

  1. Verfahren, umfassend: bei einer Bestimmung zum Ausführen eines Spurwechsels, Senden einer lichtbasierten Anfragekommunikation, die einen Sicherheitsschlüssel beinhaltet, an ein Zielfahrzeug, um den Spurwechsel zu verhandeln; und bei Empfang einer lichtbasierten Antwortkommunikation von dem Zielfahrzeug, Ausführen des Spurwechsels.
  2. Verfahren nach Anspruch 1, wobei der Sicherheitsschlüssel ein Sicherheitszertifikat, eine Codierungsregel und eine Verschlüsselungsregel beinhaltet.
  3. Verfahren nach Anspruch 1, ferner umfassend Empfangen zumindest eines Zertifikats in dem Sicherheitsschlüssel von einem straßenseitigen Infrastrukturelement.
  4. Verfahren nach Anspruch 3, ferner umfassend Verifizieren einer zusammen mit dem Sicherheitsschlüssel von dem straßenseitigen Infrastrukturelement empfangenen Signatur.
  5. Verfahren nach Anspruch 1, ferner umfassend Generieren und Übertragen des Sicherheitsschlüssels von einem straßenseitigen Infrastrukturelement.
  6. Verfahren nach Anspruch 1, wobei der Sicherheitsschlüssel durch nicht-lichtbasierte Kommunikation bereitgestellt wurde.
  7. Verfahren nach Anspruch 1, ferner umfassend, vor dem Senden der lichtbasierten Anfragekommunikation, Senden einer lichtbasierten Handshake-Nachricht.
  8. Verfahren nach Anspruch 1, ferner umfassend Senden eines Spurwechselplans über lichtbasierte Kommunikation.
  9. Verfahren nach Anspruch 8, ferner umfassend Empfangen einer Antwort auf den Spurwechselplan über lichtbasierte Kommunikation.
  10. Verfahren nach Anspruch 1, ferner umfassend Abbrechen des Spurwechsels, wenn bestimmt wird, dass ein zweites Zielfahrzeug Priorität auf der Zielfahrspur hat.
  11. Computer, der programmiert ist, um das Verfahren nach einem der Ansprüche 1-4 oder 6-10 auszuführen.
  12. Fahrzeug, umfassend einen Computer, der programmiert ist, um das Verfahren nach einem der Ansprüche 1-4 oder 6-10 auszuführen.
  13. Straßenseitiges Infrastrukturelement, das einen Computer beinhaltet, der programmiert ist, um den Sicherheitsschlüssel nach Anspruch 5 zu generieren und zu übertragen.
  14. System, umfassend ein Fahrzeug, das einen Computer umfasst, der programmiert ist, um das Verfahren nach Anspruch 1 auszuführen, und ein straßenseitiges Infrastrukturelement mit einem Computer, der programmiert ist, um den Sicherheitsschlüssel nach Anspruch 5 zu generieren und zu übertragen.
DE102019127363.3A 2018-10-11 2019-10-10 Lichtbasierte spurwechselsteuerung Pending DE102019127363A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/157,809 2018-10-11
US16/157,809 US20200114920A1 (en) 2018-10-11 2018-10-11 Light-based lane-change control

Publications (1)

Publication Number Publication Date
DE102019127363A1 true DE102019127363A1 (de) 2020-04-16

Family

ID=69954349

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019127363.3A Pending DE102019127363A1 (de) 2018-10-11 2019-10-10 Lichtbasierte spurwechselsteuerung

Country Status (3)

Country Link
US (1) US20200114920A1 (de)
CN (1) CN111038508A (de)
DE (1) DE102019127363A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3737124B1 (de) * 2019-05-10 2022-03-02 Volkswagen AG Konzept zur adressierung von verkehrsteilnehmern in drahtlosen kommunikationen
CN112540366A (zh) * 2020-11-18 2021-03-23 文思海辉智科科技有限公司 计算车辆位置关系的方法及装置、车辆、可读存储介质
US20230231916A1 (en) * 2022-01-18 2023-07-20 Ford Global Technologies, Llc Vehicle operation for providing attribute data
US20230237904A1 (en) * 2022-01-24 2023-07-27 Qualcomm Incorporated Smart traffic management

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8103412B2 (en) * 2008-06-13 2012-01-24 Ford Global Technologies, Llc System and method for controlling blind spot monitoring and cross traffic alert based on driver status
DE102009029318A1 (de) * 2009-09-09 2011-03-17 Ford Global Technologies, LLC, Dearborn Verfahren und Vorrichtung zur Erprobung einer Fahrzeugkonstruktion
US8863256B1 (en) * 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US20120268260A1 (en) * 2011-04-21 2012-10-25 Ford Global Technologies, Llc Method and apparatus for dynamically providing space management alerts for a vehicle
US9373044B2 (en) * 2011-07-25 2016-06-21 Ford Global Technologies, Llc Trailer lane departure warning system
US20130124009A1 (en) * 2011-11-14 2013-05-16 Ford Global Technologies, Llc Method and system for managing personal settings on a vehicle
DE102011087959A1 (de) * 2011-12-08 2013-06-13 Ford Global Technologies, Llc Verfahren und Vorrichtung zur Abwicklung einer straßennutzungsabhängigen Finanztransaktion sowie Computerprogrammprodukt
US20140092249A1 (en) * 2012-09-28 2014-04-03 Ford Global Technologies, Llc Vehicle perimeter detection system
US9141583B2 (en) * 2013-03-13 2015-09-22 Ford Global Technologies, Llc Method and system for supervising information communication based on occupant and vehicle environment
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US10088844B2 (en) * 2013-11-22 2018-10-02 Ford Global Technologies, Llc Wearable computer in an autonomous vehicle
US20170012783A1 (en) * 2015-07-10 2017-01-12 Entrust, Inc. Low friction device enrollment
US9550528B1 (en) * 2015-09-14 2017-01-24 Ford Global Technologies, Llc Lane change negotiation
US9791544B2 (en) * 2016-02-01 2017-10-17 Qualcomm Incorporated Location determination using light-based communications
US9919740B2 (en) * 2016-02-05 2018-03-20 Ford Global Technologies, Llc Situational deactivation of lane keep assist system
US20180137470A1 (en) * 2016-11-14 2018-05-17 Uber Technologies, Inc. Vehicle work environment

Also Published As

Publication number Publication date
US20200114920A1 (en) 2020-04-16
CN111038508A (zh) 2020-04-21

Similar Documents

Publication Publication Date Title
DE102019127363A1 (de) Lichtbasierte spurwechselsteuerung
DE102018113926A1 (de) Autonome Fahrzeugantriebssysteme und Verfahren für kritische Zustände
DE102016212195A1 (de) Verfahren zum Durchführen eines automatischen Eingriffs in die Fahrzeugführung eines Fahrzeugs
DE102018118598A1 (de) Multimodale fahrzeugnäherungssicherheit
EP2931567A1 (de) System zum selektiven öffnen eines fahrzeuges durch einen servicedienstleister
DE102017221629A1 (de) Verfahren und Vorrichtung zum Überprüfen eines Fahrzeugs in einem Kommunikationsumfeld zwischen Fahrzeugen
DE102016212196A1 (de) Verfahren zum Auswerten von Sensordaten
DE102019110790A1 (de) System und verfahren für den zugang zu eingeschränkten bereichen durch ein autonomes fahrzeug
DE102020100027A1 (de) Überwachungs- und steuerinfrastruktur für fahrzeuge
DE102021108470A1 (de) Realistische bildperspektiventransformation unter verwendung neuronaler netze
DE102019124913A1 (de) Adaptive fahrzeug-zu-infrastruktur-kommunikation
DE102020211478A1 (de) Konzept zum Unterstützen eines zumindest teilautomatisiert geführten Kraftfahrzeugs
DE102021101281A1 (de) Prioritätsfahrzeugverwaltung
DE102021123067A1 (de) Sicherer Transportmittel-Datenaustausch
DE102021131848A1 (de) Sicherheits-gateway
DE102020119083A1 (de) Abgrenzungsdefinition eines erkannten objekts
DE102020102345A1 (de) Fahrzeugservicesteuerung
DE102020127886A1 (de) V2x-torzufahrtsverwaltung
DE102019127816A1 (de) Adaptive fahrzeuginfrastrukturkommunikationen
DE112016006519T5 (de) Echtzeitkommunikation mit mobiler Infrastruktur
DE102021106278A1 (de) Infrastruktursystem
DE102020121259A1 (de) Lokalisieren eines sich bewegenden Objekts
DE102020133412A1 (de) System und Verfahren zum Festlegen eines Fahrspurwechselmanövers
DE102020122086A1 (de) Messen von vertrauen in tiefen neuronalen netzwerken
DE102020114379A1 (de) Speichern von fahrzeugdaten

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: BONSMANN - BONSMANN - FRANK PATENTANWAELTE, DE