DE102023126579A1

DE102023126579A1 - Vorabsicherheitsverifizierung von nachrichten

Info

Publication number: DE102023126579A1
Application number: DE102023126579.2A
Authority: DE
Inventors: Krishna Bandi; Sathyanarayana Chary Palakonda; Ivan Vukovic
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2022-09-30
Filing date: 2023-09-28
Publication date: 2024-04-04
Also published as: US20240114341A1; CN117858047A

Abstract

Durchführen einer Filterung von Infrastruktur-zu-Fahrzeug-(V2I-)Nachrichten durch ein Fahrzeug wird bereitgestellt. Erste Nachrichten werden von einer oder mehreren straßenseitigen Einheiten (RSUs) empfangen. Als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, wird eine Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als ein aktueller Eincheckstandort für das Fahrzeug gespeichert. Zweite Nachrichten werden von der einen oder den mehreren RSUs empfangen. Als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, werden die zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung weitergeleitet. Anderenfalls werden die zweiten Nachrichten verworfen.

Description

GEBIET DER TECHNIK
Aspekte der Offenbarung betreffen im Allgemeinen die Filterung von Infrastruktur-zu-Fahrzeug-(I2V-)Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten.
ALLGEMEINER STAND DER TECHNIK
Fahrzeug-zu-Alles (V2X) ist eine Kommunikationsart, die es Fahrzeugen ermöglicht, mit verschiedenen Aspekten der Verkehrsumgebung zu kommunizieren. Diese Kommunikation kann eine Interaktion mit Fahrzeugen unter Verwendung von Fahrzeug-zu-Fahrzeug-(V2V-)Kommunikation und eine Interaktion mit Infrastruktur unter Verwendung von Fahrzeug-zu-Infrastruktur-(V2I-)Kommunikation beinhalten.
Fahrzeuge können Funksendeempfänger und Fahrzeugbordeinheiten (vehicle on-board units - Fahrzeug-OBUs) beinhalten, um die V2X-Kommunikation zu erleichtern. Straßenseitige Einheiten (roadside units - RSUs) können den OBUs drahtlose Kommunikation von der straßenseitigen Infrastruktur bereitstellen. Eine derartige Kommunikation kann als I2V-Kommunikation bezeichnet werden. RSUs werden im Allgemeinen im gleichen Frequenzband wie V2X über Technologien wie etwa Mobilfunk-Fahrzeug-zu-Alles-(CV2X-)Technologien und Technologien der dedizierten Nahbereichskommunikation (dedicated short range communications - DSRC) betrieben. Einige RSUs stellen eine zusätzliche Funktionalität bereit, wie etwa lokale Wi-Fi-Hotspots für Fußgänger oder Mobilfunk-Backhaul zur Kommunikation von Informationen mit einem zentralen System.
KURZDARSTELLUNG
In einem oder mehreren veranschaulichenden Beispielen ist ein Fahrzeug zum Durchführen einer Filterung von I2V-Nachrichten bereitgestellt. Das Fahrzeug beinhaltet einen Sendeempfänger und eine OBU. Die OBU ist dazu programmiert, erste Nachrichten von einer oder mehreren RSUs zu empfangen, als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegebenen wird, durch Algorithmusverarbeitung auf der Sicherheitsschicht zu verifizieren, welche Nachrichten für das Fahrzeug relevant sind, bevor die Sicherheitsverifizierung/Entschlüsselung und eine Fahrzeuganwendung zur weiteren Verarbeitung durchgeführt werden, eine Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug zu speichern, zweite Nachrichten von der einen oder den mehreren RSUs zu empfangen, als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, dadurch, dass die Eincheckstandortkennung der ersten Nachricht mit dem Auscheckstandort der ersten Nachricht übereinstimmt und der Auscheckstandort der ersten Nachricht mit dem Standort des letzten Knotens/Eincheckstandort der zweiten Nachrichten übereinstimmt, über Verifizieren aller Nachrichten, die für das Fahrzeug relevant sind, über Algorithmusverarbeitung auf der Sicherheitsschicht, bevor die Sicherheitsverifizierung/Entschlüsselung und die Fahrzeuganwendung zur weiteren Verarbeitung durchgeführt werden, und anderenfalls die zweiten Nachrichten zu verwerfen.
In einem oder mehreren veranschaulichenden Beispielen wird ein Verfahren zum Durchführen einer Filterung von I2V-Nachrichten durch ein Fahrzeug bereitgestellt. Erste Nachrichten werden von einer oder mehreren RSUs empfangen. Als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, wird eine Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als ein aktueller Eincheckstandort für das Fahrzeug gespeichert. Zweite Nachrichten werden von der einen oder den mehreren RSUs empfangen. Als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, werden die zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung weitergeleitet. Anderenfalls werden die zweiten Nachrichten verworfen.
In einem oder mehreren veranschaulichenden Beispielen umfasst ein nicht transitorisches computerlesbares Medium Anweisungen zum Durchführen einer Filterung von I2V-Nachrichten, die bei Ausführung durch eine OBU eines Fahrzeugs die OBU dazu veranlassen, Vorgänge durchzuführen, die Folgendes beinhalten: Empfangen erster Nachrichten von einer oder mehreren RSUs; Verifizieren, dass die ersten Nachrichten gültig sind, bevor ein Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird; als Reaktion darauf, dass sich das Fahrzeug dem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug; als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, Entfernen der Eincheckstandortkennung aus dem Speicher, um den aktuellen Eincheckstandort zurückzusetzen; Weiterleiten der ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an eine Fahrzeuganwendung zur Verarbeitung; Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs; Verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden; als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an die Fahrzeuganwendung zur Verarbeitung; und anderenfalls Verwerfen der zweiten Nachrichten.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1A veranschaulicht ein beispielhaftes System für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
1B veranschaulicht ein alternatives beispielhaftes System für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
2 veranschaulicht eine beispielhafte Darstellung eines Datenflusses zwischen Elementen des Systems;
3 veranschaulicht eine beispielhafte Kreuzung, wie durch Signalstatusnachrichten (signal status messages - SSMs) und/oder MAP-Nachrichten definiert, die von einem Fahrzeug empfangen werden;
4 veranschaulicht ein Beispiel für mehrere Kreuzungen, die zum Durchfahren durch ein Fahrzeug verfügbar sind;
5A veranschaulicht einen ersten Teil eines beispielhaften Datenflusses für den Betrieb der Fahrzeuganwendung in einem Kreuzungsszenario für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
5B veranschaulicht einen zweiten Teil eines beispielhaften Datenflusses für den Betrieb der Fahrzeuganwendung in einem Kreuzungsszenario für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
6 veranschaulicht ein Beispiel für mehrere Mautportale, die zum Durchfahren durch ein Fahrzeug verfügbar sind;
7A veranschaulicht einen ersten Teil eines beispielhaften Datenflusses für den Betrieb der Fahrzeuganwendung für die Filterung von V2I-Nachrichten in einem Mautszenario vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
7B veranschaulicht einen zweiten Teil eines beispielhaften Datenflusses für den Betrieb der Fahrzeuganwendung für die Filterung von V2I-Nachrichten in einem Mautszenario vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten;
8 veranschaulicht einen ersten Teil eines beispielhaften Prozesses für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten; und
9 veranschaulicht einen zweiten Teil eines beispielhaften Prozesses für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten; und
10 veranschaulicht ein Beispiel für eine Verwendung einer Rechenvorrichtung bei der Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten.

DETAILLIERTE BESCHREIBUNG
In dieser Schrift werden Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale könnten vergrößert oder verkleinert dargestellt sein, um Details konkreter Komponenten zu zeigen. Deshalb sind in dieser Schrift offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann zu lehren, die Ausführungsformen verschiedenartig einzusetzen. Für den Durchschnittsfachmann versteht es sich, dass verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben sind, mit Merkmalen kombiniert werden können, die in einer oder mehreren anderen Figuren veranschaulicht sind, um Ausführungsformen zu produzieren, die nicht ausdrücklich veranschaulicht oder beschrieben sind. Die veranschaulichten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für konkrete Anwendungen gewünscht sein.
Da der V2X-Raum nicht nur im Konnektivitätsbereich, sondern auch bei autonomen und elektrischen Fahrzeugen wächst, kann der Nachrichtenverkehr zunehmen, um verschiedene Anwendungen zu unterstützen. Diese Nachrichten werden im Allgemeinen verifiziert, um die Authentizität sicherzustellen. Es kann jedoch rechnerisch komplex sein, jede einzelne Nachricht zu verifizieren. Darüber hinaus kann eine derartige Verifizierung aufgrund der Verarbeitung von Nachrichten, die für den Standort des Fahrzeugs irrelevant oder anderweitig nicht von Interesse sind, zeitkritische Vorgänge beeinflussen. Zudem kann es unnötig sein, eine Verifizierung für jede Nachricht von einem Sender durchzuführen, z. B. alle 100 Millisekunden. Eine Nachrichtenfilterung durch Nutzen von hochauflösenden statischen Karten in Kombination mit einer komplexen Lokalisierung des Fahrzeugs kann unpraktisch sein. Zusätzlich kann die Auswirkung auf die Übertragungsseite der Nachrichten beim Signieren jeder Nachricht ebenfalls belastend sein.
Ein Ansatz für Fahrzeugnachrichtenübermittlung kann eine Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten beinhalten. Dies kann den Rechenaufwand, die Zeitkritikalität und Filterungsaspekte der Zunahme des Nachrichtenverkehrs angehen und kann die Reduzierung der Verifizierungskomplexität unterstützen, sodass diese Ressourcen an anderer Stelle zugewiesen werden können. Diese Verarbeitung kann für die Kreuzungsverwaltung sowie für Mautsituationen, als einige nicht einschränkende Beispiele, nützlich sein. Weitere Aspekte der Offenbarung werden in dieser Schrift im Detail erörtert.
1A veranschaulicht ein beispielhaftes System 100A für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten. Wie gezeigt, beinhaltet das System 100A ein Fahrzeug 102 mit Drahtlosfähigkeit, das dazu konfiguriert ist, entlang einer Fahrbahn 114 zu fahren. Das Fahrzeug 102 beinhaltet eine OBU 104 und einen Sendeempfänger 106. Das System 100A beinhaltet außerdem eine Verkehrssteuerungseinrichtung, die eine RSU 112 und eine Verkehrssignalsteuerung 118 beinhaltet, die sich innerhalb eines Verkehrssteuerschranks 120 befindet. Die RSU 112 kommuniziert über eine lokale Verbindung mit der Verkehrssignalsteuerung 118 und über ein Kommunikationsnetzwerk 110 mit einem Cloud-Server 116. Unter Verwendung der OBU 104 kommuniziert das Fahrzeug 102 über das Kommunikationsnetzwerk 110, z. B. über Kommunikation über ein Mobilfunknetz 108 und/oder einen Satelliten 122, mit der RSU 112.
Die Fahrzeuge 102 können verschiedene andere Arten von Personenkraftwagen beinhalten, wie etwa Limousinen, Softroader (crossover utility vehicles - CUVs), Vans, Geländelimousinen (sport utility vehicles - SUVs), Trucks, Wohnmobile (recreational vehicles - RVs), Roller oder andere mobile Maschinen zum Transportieren von Personen oder Gütern. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. In derartigen Fällen kann die Kraftstoffquelle Benzin oder Dieselkraftstoff sein. Als eine weitere Möglichkeit kann das Fahrzeug 102 ein Hybrid-Elektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electric vehicle - PHEV) oder ein Parallel/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Als noch eine weitere Möglichkeit kann das Fahrzeug 102 ein Elektrofahrzeug (electric vehicle - EV) ohne einen Verbrennungsmotor sein, das durch Elektromotoren angetrieben wird. Da die Art und Konfiguration der Fahrzeuge 102 variieren können, können die Fähigkeiten der Fahrzeuge 102 entsprechend variieren. Als einige andere Möglichkeiten können Fahrzeuge 102 unterschiedliche Fähigkeiten in Bezug auf Fahrgastkapazität, Zugfähigkeit und -kapazität und Lagervolumen aufweisen. Für Eigentumsrechts-, Bestandsführungs- und andere Zwecke kann dem Fahrzeug 102 eine einmalige Kennung zugeordnet werden, wie zum Beispiel eine Fahrzeugidentifizierungsnummer (FIN).
Die OBU 104 kann dazu konfiguriert sein, dem Fahrzeug 102 Telematikdienste bereitzustellen. Zu diesen Diensten können als nicht einschränkende Möglichkeiten Navigation, Routenführung, Fahrzeugdiagnosen, lokale Unternehmenssuche, Unfallmeldung und Freisprecheinrichtungen gehören. Die OBU 104 kann mit einem Sendeempfänger 106 in Kommunikation stehen. Die OBU 104 kann dementsprechend dazu konfiguriert sein, den Sendeempfänger 106 zu nutzen, um mit einem Mobilfunknetz 108 über verschiedene Protokolle und mit einem Kommunikationsnetzwerk 110 über ein Netzwerkprotokoll (wie etwa Uu) zu kommunizieren. Die OBU 104 kann zusätzlich dazu konfiguriert sein, über ein Peer-to-Peer-Übertragungsprotokoll (wie etwa PC5) zu kommunizieren, um eine V2X-Kommunikation mit Vorrichtungen, wie etwa der RSU 112, zu erleichtern. Es ist anzumerken, dass diese Protokolle lediglich Beispiele sind und unterschiedliche Peer-to-Peer- und/oder Mobilfunktechnologien verwendet werden können.
Das Kommunikationsnetzwerk 110 kann Vorrichtungen, die mit dem Kommunikationsnetzwerk 110 verbunden sind, Kommunikationsdienste bereitstellen, wie etwa paketvermittelte Netzwerkdienste (z. B. Internetzugang, Voice-over-Internet-Protocol-(VoIP-)Kommunikationsdienste). Ein Beispiel für ein Kommunikationsnetzwerk 110 ist ein Mobilfunknetz. Zum Beispiel kann die OBU 104 über eine Verbindung mit einem oder mehreren Mobilfunkmasten auf das Mobilfunknetz zugreifen. Um die Kommunikation über das Kommunikationsnetzwerk 110 zu erleichtern, kann die OBU 104 eindeutigen Vorrichtungskennungen (z. B. Mobilvorrichtungsnummern (mobile device number - MDNs), Internetprotokoll-(IP-)Adressen usw.) zugeordnet sein, um die Kommunikation der OBU 104 an dem Kommunikationsnetzwerk 110 als mit dem Fahrzeug 102 zugeordnet zu identifizieren.
Die RSU 112 kann eine Vorrichtung mit Verarbeitungsfähigkeiten und Netzwerkfähigkeiten sein und kann dazu ausgelegt sein, zur Verwendung bei der Kommunikation mit Fahrzeugen 102 in der Nähe einer Fahrbahn 114 platziert zu werden. In einem Beispiel kann die RSU 112 Hardware beinhalten, die dazu konfiguriert ist, über das Peer-to-Peer-Übertragungsprotokoll (wie etwa PC5) zu kommunizieren, um eine V2X-Kommunikation mit den Fahrzeugen 102 zu erleichtern. Die RSU 112 kann außerdem eine drahtgebundene oder drahtlose Backhaul-Fähigkeit aufweisen, um eine Kommunikation mit anderen Elementen des Kommunikationsnetzwerkes 110, wie etwa dem Cloud-Server 116, zu ermöglichen.
Die RSU 112 kann ferner dazu konfiguriert sein, mit einer Verkehrssignalsteuerung 118 zu kommunizieren. Die Verkehrssignalsteuerung 118 kann eine oder mehrere Hardware-Vorrichtungen beinhalten, die dazu konfiguriert sind, den Betrieb einer oder mehrerer Verkehrssteuerungen zu steuern. In einem Beispiel kann die Verkehrssignalsteuerung 118 dazu konfiguriert sein, eine oder mehrere Verkehrsampeln an einer Kreuzung entlang der Fahrbahn 114 zu steuern.
Die Verkehrssignalsteuerung 118 kann zum Schutz in einem Verkehrssteuerschrank 120 montiert sein. Der Verkehrssteuerschrank 120 kann wiederum an einem Strommast montiert sein, der auch von der RSU 112 und/oder den Verkehrssteuerungen selbst geteilt werden kann.
Zu Positionierungszwecken kann die Fahrzeug-OBU 104 zusätzlich die Funktionalität des globalen Navigationssatellitensystems (GNSS) beinhalten, um eine autonome georäumliche Positionierung für das Fahrzeug 102 bereitzustellen. Als einige Beispiele kann es die GNSS-Funktionalität dem Fahrzeug 102 ermöglichen, seine Position unter Verwendung eines oder mehrerer Satelliten 122, wie etwa des globalen Positionierungssystems (GPS), GLONASS, Galileo, Beidou und/oder anderen, zu bestimmen.
Es ist anzumerken, dass das in 1A gezeigte System 100A lediglich ein Beispiel ist und Systeme verwendet werden können, die mehr, weniger und unterschiedliche Anordnungen von Elementen aufweisen. Zum Beispiel können eines oder mehrere von der OBU 104, der RSU 112, dem Cloud-Server 116 und der Verkehrssignalsteuerung 118 in einer einzigen Vorrichtung kombiniert sein. Darüber hinaus wird, während ein Fahrzeug 102 entlang einer Fahrbahn 114 gezeigt ist, in Betracht gezogen, dass die Systeme 100A viele Fahrzeuge 102 und Fahrbahnen 114 beinhalten, die befahren werden sollen.
1B veranschaulicht ein alternatives beispielhaftes System 100B für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten. In dem System 100B steht die RSU 112 anstatt mit einem Verkehrssteuerschrank 120 in Kommunikation mit einem Mautportal 124. Somit kann das System 100B anders als das System 100A, das für Verkehrssteuerungsverwendungsfälle verwendet werden kann, für Mautverwendungsfälle verwendet werden.
2 veranschaulicht eine beispielhafte Darstellung 200 eines Datenflusses zwischen Elementen der Systeme 100A, 100B. Diese Datenelemente können als einige Beispiele Signalphasen- und -taktungsinformationen (signal phase and timing information - SPaT), Kartendaten (map data - MAP), Signalanforderungsnachrichten (signal request messages - SRMs), SSMs, BSMs, Verkehrsstörungsnachrichten (traffic Incident message - TIMs), PSMs usw. beinhalten. Die SPaT können verwendet werden, um den aktuellen Status einer oder mehrerer signalgesteuerter Kreuzungen zu übermitteln, wie etwa den Signalzustand der Kreuzung und wie lange dieser Zustand für jede Annäherung und jeden Fahrstreifen, der aktiv ist, bestehen bleibt. Die MAP-Nachrichten können verwendet werden, um viele Arten von geografischen Straßeninformationen zu übermitteln, und können die physische Geometrie einer oder mehrerer Kreuzungen beschreiben. Die MAP-Nachrichten können periodisch übertragen werden und können verschiedene Elemente enthalten, die eine oder mehrere Kreuzungen oder ein oder mehrere Straßensegmente beschreiben. Die SRM kann Unterbrechungs- oder Prioritätsdienste für ausgewählte Benutzergruppen anfordern und kann entweder für eine Prioritätssignalanforderung oder eine Unterbrechungssignalanforderung verwendet werden, je nachdem, wie die Anforderung festgelegt ist. Die SSM kann verwendet werden, um den aktuellen Status des Signals und die Sammlung von ausstehenden oder aktiven Unterbrechungs- oder Prioritätsanforderungen, die von der Steuerung bestätigt wurden, in Beziehung zu setzen. Die BSM kann in einer Vielfalt von Anwendungen verwendet werden, um Daten bezüglich des Fahrzeugzustands auszutauschen. Die TIM-Nachricht kann verwendet werden, um verschiedene Fahrbahn- oder andere Informationen zu Bedingungen zu enthalten. Zum Beispiel können TIM-Nachrichten verwendet werden, um Informationen in Bezug auf Wetterbedingungen, Straßenhindernisse, Verkehrszeichen, Straßenbedingungen oder andere allgemeine Informationen bereitzustellen. Die PSM-Nachricht kann Informationen in Bezug auf Fußgänger beinhalten, wie im Standard J2945/9 ausführlicher beschrieben.
Wie gezeigt, können die RSU 112 und die Verkehrssignalsteuerung 118 über eine lokale Verbindung, wie etwa eine Wi-Fi-Verbindung oder eine drahtgebundene Verbindung, kommunizieren. Die RSU 112 und die Verkehrssignalsteuerung 118 können Daten kommunizieren, wie etwa SPaT-, MAP-, SRM- und SSM-Nachrichten. Ebenfalls wie gezeigt, können die RSU 112 und das Mautportal 124 über eine lokale Verbindung, wie etwa eine Wi-Fi-Verbindung oder eine drahtgebundene Verbindung, kommunizieren. Die RSU 112 und das Mautportal 124 können Daten, wie etwa eine Mautzugangsnachricht (toll access message - TAM), eine Mautnutzungsnachricht (toll usage message - TUM) und Mautnutzungsnachrichtenbestätigungsnachrichten (toll usage message acknowledgement messages - TUMAck-Nachrichten), kommunizieren.
Die RSU 112 und das Fahrzeug 102 können über eine V2X-Verbindung kommunizieren. Die RSU 112 kann Daten an das Fahrzeug 102 kommunizieren, wie etwa SPaT-, MAP-, SSM-, TIM-, PSM- und TAM-Nachrichten. Das Fahrzeug 102 kann Daten an die RSU 112 kommunizieren, wie etwa SRM-Nachrichten. Das Fahrzeug 102 kann außerdem GNSS-Informationen über den Satelliten 122 empfangen. Diese Informationen können durch das Fahrzeug 102 verwendet werden, um sich selbst entlang der Fahrbahn 114 zu lokalisieren und/oder um Mauttransaktionen mit dem Mautportal 124 durchzuführen.
Die Verkehrssignalsteuerung 118 kann über eine Mobilfunkverbindung mit dem Kommunikationsnetzwerk 110 kommunizieren. Die Verkehrssignalsteuerung 118 und das Kommunikationsnetzwerk 110 können Daten kommunizieren, wie etwa SPaT-, MAP-, SRM- und SSM-Nachrichten. Diese Daten können abhängig von den Umständen an den/die Cloud-Server 116 und/oder das Fahrzeug 102 gesendet oder von diesem/diesen empfangen werden. Gleichermaßen können das Mautportal 124 und das Kommunikationsnetzwerk 110 Daten, wie etwa TAM-Nachrichten, kommunizieren.
Das Fahrzeug 102 kann außerdem über eine Mobilfunkverbindung mit dem Kommunikationsnetzwerk 110 kommunizieren. Das Kommunikationsnetzwerk 110 kann Daten an das Fahrzeug 102 kommunizieren, wie etwa SPaT-, MAP-, SSM-, TIM-, PSM- und TAM-Nachrichten. Das Fahrzeug 102 kann Daten an das Kommunikationsnetzwerk 110 kommunizieren, wie etwa SRM-Nachrichten. Diese Daten können abhängig von den Umständen an den Cloud-Server 116, die Verkehrssignalsteuerung 118 und/oder das Mautportal 124 gesendet oder von diesem/dieser empfangen werden. Der Cloud-Server 116 kann über eine drahtlose und/oder drahtgebundene Verbindung mit dem Kommunikationsnetzwerk 110 kommunizieren.
Die Verkehrssignalsteuerung 118 kann dazu konfiguriert sein, den aktuellen Bewegungszustand (z. B. Signalphase und -taktung) für die signalgesteuerte Kreuzung auszugeben. Die Verkehrssignalsteuerung 118 kann außerdem dazu konfiguriert sein, die MAP-, SRM- und SSM-Nachrichten an die RSU 112 weiterzuleiten. Die RSU 112 kann dazu konfiguriert sein, die von der Verkehrssignalsteuerung 118 empfangenen SPaT-Daten zusammen mit einer MAP-Nachricht, die das geometrische Layout der Kreuzung beschreibt, an das Fahrzeug 102 weiterzuleiten und/oder zu übertragen.
In Bezug auf die Kommunikation über das Kommunikationsnetzwerk 110 können die SPaT- und MAP-Daten durch das Kommunikationsnetzwerk 110 an das Fahrzeug 102 weitergeleitet und/oder übertragen werden. Wenn eine solche Ausstattung vorliegt, kann eine derartige Kommunikation zusätzlich und/oder alternativ über Kommunikation über den Satelliten 122 durchgeführt werden.
Die OBU 104 des Fahrzeugs 102 kann dazu konfiguriert sein, eine Fahrzeuganwendung 202 auszuführen, die dazu konfiguriert ist, das Fahrzeug 102 dazu zu veranlassen, verschiedene in dieser Schrift im Detail beschriebene Prozesse durchzuführen. Diese Prozesse können die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten beinhalten.
3 veranschaulicht eine beispielhafte Kreuzung 300, wie durch SSM- und MAP-Nachrichten definiert, die von einem Fahrzeug 102 empfangen werden. Ein Fahrzeug 102 kann die SSM- und MAP-Nachrichten über die OBU 104 empfangen, wenn es sich in der Nähe einer RSU 112 für die Kreuzung 300 befindet. Die Kreuzung 300 weist, wie gezeigt, fünf Fahrstreifen auf. Die empfangenen Informationen beinhalten einen Kreuzungsreferenzpunkt 302 für die Kreuzung 300, einen Eincheckstandort 304 für jeden ankommenden Fahrstreifen der Kreuzung 300, einen oder mehrere Eintrittspunkte 306 für ankommende Fahrstreifen der Kreuzung 300, einen oder mehrere Austrittspunkte 308 für jeden ausgehenden Fahrstreifen der Kreuzung 300 und einen Auscheckstandort 310 für jeden ausgehenden Fahrstreifen der Kreuzung 300. Es ist anzumerken, dass der Einfachheit halber nur ein Teil der Standorte in der beispielhaften Kreuzung 300 gezeigt ist, um einen Teil zu veranschaulichen, der für die aktuelle Bewegung des Fahrzeugs 102 am relevantesten ist.
Der Kreuzungsreferenzpunkt 302 kann sich auf einen Standort beziehen, der durch die Nachrichten spezifiziert wird, anhand dessen Standorte der anderen Elemente der Kreuzung 300 berechnet werden können. Die Eincheckstandorte 304 können Standorte relativ zu dem Kreuzungsreferenzpunkt 302 für jeden Fahrstreifen angeben. Zum Beispiel kann die Fahrzeuganwendung 202 der OBU 104 als Reaktion darauf, dass die geografischen Koordinaten des Fahrzeugs 102 mit einem der Eincheckstandorte 304 der Kreuzung 300 übereinstimmen, identifizieren, dass das Fahrzeug 102 in die Nähe der Kreuzung 300 einfährt, die durch die Eincheckstandorte 304 definiert ist.
Gleichermaßen können die Eintrittspunkte 306 Standorte relativ zu dem Kreuzungsreferenzpunkt 302 für jeden Fahrstreifen angeben, die angeben, dass das Fahrzeug 102 in die Kreuzung 300 selbst einfährt. Die Eintrittspunkte 306 können im Allgemeinen näher an der Kreuzung 300 liegen als die Eincheckstandorte 304, die eine größere Entfernung aufweisen können, und können Standorte angeben, die das Fortschreiten des Fahrzeugs 102 entlang eines Fahrstreifens in die Kreuzung 300 zeigen. Die Austrittspunkte 308 können gleichermaßen Standorte relativ zu dem Kreuzungsreferenzpunkt 302 für jeden Fahrstreifen angeben, die angeben, dass das Fahrzeug 102 die Kreuzung 300 selbst verlässt. Die Auscheckstandorte 310 können gleichermaßen Standorte relativ zu dem Kreuzungsreferenzpunkt 302 für jeden Fahrstreifen angeben, die angeben, dass das Fahrzeug 102 nicht mehr als in der Nähe der Kreuzung 300 betrachtet wird.
4 veranschaulicht ein Beispiel 400 für mehrere Kreuzungen 300, die zum Durchfahren durch ein Fahrzeug 102 verfügbar sind. Wie gezeigt, zeigt das Beispiel 400 sechs Kreuzungen 300A-300F, von denen jede ihren eigenen Kreuzungsreferenzpunkt 302, ihre eigenen Eincheckstandorte 304, Eintrittspunkte 306, Austrittspunkte 308 und Auscheckstandorte 310 aufweist. Das Fahrzeug 102 kann aufgrund der unmittelbaren Nähe des Fahrzeugs 102 zu den RSUs 112, die den Kreuzungen 300 entsprechen, MAP- und SSM-Nachrichten von mehr als einer der Kreuzungen 300A-300F empfangen. Um eine derartige Kommunikation zu verifizieren, kann es rechnerisch komplex sein, jede einzelne Nachricht zu verifizieren. Darüber hinaus kann eine derartige Verifizierung aufgrund der Verarbeitung von Nachrichten, die für den Standort des Fahrzeugs 102 irrelevant sind (z. B. sich auf eine Kreuzung 300 beziehen, in die das Fahrzeug 102 nicht einfährt) oder anderweitig nicht von Interesse sind, zeitkritische Vorgänge beeinflussen. Zudem kann es unnötig sein, eine Verifizierung für jede Nachricht von den RSUs 112 durchzuführen, z. B. alle 100 Millisekunden. Eine Nachrichtenfilterung durch Nutzen von hochauflösenden statischen Karten in Kombination mit einer komplexen Lokalisierung des Fahrzeugs 102 kann unpraktisch sein. Zusätzlich kann die Auswirkung auf die Übertragungsseite der RSU 112 der Nachrichten beim Signieren jeder Nachricht ebenfalls belastend sein.
5A-5B veranschaulichen gemeinsam einen beispielhaften Datenfluss 500 für den Betrieb der Fahrzeuganwendung 202 in einem Szenario einer Kreuzung 300 für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten. In einem Beispiel kann der Datenfluss 500 Komponenten des Systems 100A einschließen, wie vorstehend im Detail erörtert.
Bei Index (A) empfängt das Fahrzeug 102 MAP-Nachrichten von den RSUs 112. Wie gezeigt, kann das Fahrzeug 102 MAP-Nachrichten von einer ersten RSU 112A und auch von einer zweiten RSU 112B empfangen. Es ist anzumerken, dass dies nur eine Möglichkeit ist und sich eine beliebige Anzahl von RSUs 112 in Kommunikationsentfernung zu der OBU 104 des Fahrzeugs 102 befinden kann.
Bei Index (B) nähert sich das Fahrzeug 102 einem Eincheckstandort 304 einer Kreuzung 300. In einem Beispiel kann das Fahrzeug 102 GNSS-Funktionalität nutzen, um den aktuellen Standort des Fahrzeugs 102 zu bestimmen, und kann identifizieren, dass das Fahrzeug 102 einen Eincheckstandort 304 erreicht hat, der durch die MAP-Nachricht für eine der Kreuzungen 300 spezifiziert wird. Wenn dies der Fall ist, stellt das Fahrzeug 102 die Kennung der Kreuzung 300 aus der MAP-Nachricht als die aktuelle eingecheckte Kreuzung 300 fest. In einigen Beispielen kann das Fahrzeug 102 eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und auf Grundlage der aktuellen Position und/oder Fahrtrichtung sicherstellen, dass die MAP-Nachrichten mit der eingecheckten Kreuzung 300 übereinstimmen, bevor eine Sicherheitsverifizierung der MAP-Nachrichten durchgeführt wird. Dies kann es dem Fahrzeug 102 ermöglichen, die Sicherheitsverarbeitung von MAP-Nachrichten, die nicht für die eingecheckte Kreuzung 300 gelten, nicht durchführen zu müssen.
Bei Index (C) sendet das Fahrzeug 102 das Zertifikat aus der MAP-Nachricht an einen Sicherheitsdienst des Fahrzeugs 102 zur Verifizierung. Das Zertifikat kann von einem Hardware-Sicherheitsmodul (HSM) der sendenden RSU 112 (z. B. der ersten RSU 112A, der zweiten RSU 112B usw.) in die MAP-Nachricht eingeschlossen worden sein. Die RSU 112 kann ihr in die MAP-Nachrichten einzuschließendes Zertifikat über eine Verbindung zu einem Backend-Sicherheitsanmeldeinformationsverwaltungssystem (security credential management system - SCMS) periodisch aktualisieren. In einem Beispiel kann der Sicherheitsdienst einen sicheren Datendienst (secure data service - SDS) über das Protokoll für drahtlosen Zugang in Fahrzeugumgebungen (wireless access in vehicular environments - WAVE), wie durch den WAVE-Standard 1609.2 des Institute of Electrical and Electronics Engineer (IEEE) definiert, umsetzen. Der Sicherheitsdienst kann umgesetzt werden, um eine Validierung des Zertifikats durchzuführen, um sicherzustellen, dass die MAP-Nachricht authentisch und/oder autorisiert ist. Diese Validierung ist bei Index (D) gezeigt. Bei Index (E) antwortet der Sicherheitsdienst mit der Angabe, ob die MAP-Nachricht gültig ist. Wenn dies der Fall ist, wird der Datenfluss 500 wie gezeigt fortgesetzt. Falls nicht, endet der Datenfluss 500 (nicht gezeigt).
Bei Index (F) empfängt das Fahrzeug 102 SSM-Nachrichten von den RSUs 112. Diese Nachrichten können von den RSUs 112 auf Grundlage von Daten, die von der Verkehrssignalsteuerung 118 empfangen werden, übertragen werden. Wie gezeigt, kann das Fahrzeug 102 SSM-Nachrichten von einer ersten RSU 112A und auch von einer zweiten RSU 112B empfangen. Es ist anzumerken, dass dies nur eine Möglichkeit ist und sich eine beliebige Anzahl von RSUs 112 in Kommunikationsentfernung zu der OBU 104 des Fahrzeugs 102 befinden kann.
Bei Index (G) bestimmt das Fahrzeug 102, ob die empfangenen SSM-Nachrichten mit der aktuellen Kreuzung 300 des Fahrzeugs 102 übereinstimmen. In einem Beispiel kann das Fahrzeug 102 eine Kennung einer Kreuzung 300, die in den SSM-Nachrichten beinhaltet ist, mit dem Eincheckstandort 304 der Kreuzung 300 vergleichen, der bei Index (B) identifiziert wurde. Wenn die SSM für die eingecheckte Kreuzung 300 gilt, wird der Datenfluss 500 fortgesetzt, um diese Nachricht zu verarbeiten. Falls nicht, endet der Datenfluss 500 in Bezug auf diese SSM-Nachricht. In einigen Beispielen kann das Fahrzeug 102 ferner eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und auf Grundlage der aktuellen Position und/oder Fahrtrichtung sicherstellen, dass die SSM-Nachrichten mit der eingecheckten Kreuzung 300 übereinstimmen, bevor eine Sicherheitsverifizierung der SSM-Nachrichten durchgeführt wird. Dies kann es dem Fahrzeug 102 ermöglichen, die Sicherheitsverarbeitung von SSM-Nachrichten, die nicht für die eingecheckte Kreuzung 300 gelten, nicht durchführen zu müssen.
Bei Index (H) verifiziert das Fahrzeug 102 das Zertifikat aus der SSM-Nachricht unter Verwendung des Sicherheitsdienstes. Diese Verifizierung wird bei Index (I) durchgeführt, ähnlich wie in Bezug auf die Indizes (C) und (D) für die MAP-Nachrichten erörtert. Das Ergebnis wird bei Index (J) an das Fahrzeug 102 zurückgegeben, ähnlich wie vorstehend in Bezug auf Index (E) erörtert.
Wenn die SSM-Nachricht als gültig bestätigt wird, kann bei Index (K) die SSM-Nachricht an die Fahrzeuganwendungen 202 zur Verwendung weitergeleitet werden. Somit beinhalten die Nachrichten, die weitergeleitet werden, nur diejenigen Nachrichten, die mit der aktuellen Kreuzung 300 übereinstimmen und die auch über den Sicherheitsdienst validiert sind. Die anderen Nachrichten, die nicht übereinstimmen, können verworfen werden.
Unter Bezugnahme auf 5B nähert sich das Fahrzeug 102 bei Index (L) einem Auscheckstandort 310 der Kreuzung 300. In einem Beispiel kann das Fahrzeug 102 GNSS-Funktionalität nutzen, um den aktuellen Standort des Fahrzeugs 102 zu bestimmen, und es kann identifizieren, dass das Fahrzeug 102 den Auscheckstandort 310 erreicht hat, der durch die MAP-Nachricht für die aktuelle eingecheckte Kreuzung 300 spezifiziert wird.
Wenn dies der Fall ist, stellt das Fahrzeug 102 bei Index (M) die Kennung der Kreuzung aus der MAP-Nachricht als nicht mehr die aktuelle eingecheckte Kreuzung 300 fest. Stattdessen kann das Fahrzeug 102 zum Beispiel angeben, dass keine Kreuzung 300 die aktuelle eingecheckte Kreuzung 300 ist.
Bei Index (N) gibt das Fahrzeug 102 den Fahrzeuganwendungen 202 an, dass es keine eingecheckte Kreuzung 300 mehr gibt. Dies kann es der Fahrzeuganwendung 202 in einem Beispiel ermöglichen, ihren Zustand zu aktualisieren, um keine Dienste für die Kreuzung 300 mehr durchzuführen, und/oder der Navigation anzugeben, dass das Fahrzeug 102 die Kreuzung 300 verlässt. Nach Index (N) endet der Datenfluss 500. Als eine Variation ist anzumerken, dass das Fahrzeug 102 bei den Indizes (M)-(N) auch identifizieren kann, dass das Verlassen der aktuellen eingecheckten Kreuzung 300 zu einer neuen aktuellen eingecheckten Kreuzung 300 führt. Zum Beispiel kann das Fahrzeug 102 eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und sicherstellen, dass der Standort und/oder die Fahrtrichtung des Fahrzeugs 102 mit dem Eincheckstandort 304 des nächsten Mautportals 124 übereinstimmen. In einem derartigen Fall kann die aktuelle eingecheckte Kreuzung 300 auf die neue Kreuzung 300 aktualisiert werden, der sich genähert wird.
6 veranschaulicht ein Beispiel 600 für mehrere Mautportale 124A-B (gemeinsam die Mautportale 124), die zum Durchfahren durch ein Fahrzeug 102 verfügbar sind. Wie gezeigt, erstrecken sich ein erstes Mautportal 124A und ein zweites Mautportal 124B jeweils über Fahrstreifen der Fahrbahn 114. Die erste RSU 112A steuert im Betrieb das Mautportal 124A. Gleichermaßen steuert die zweite RSU 112B im Betrieb das Mautportal 124B. Die Fahrstreifen der Fahrbahn 114 beinhalten zum Beispiel in einer ersten Fahrtrichtung einen ersten Fahrstreifen, einen zweiten Fahrstreifen, einen dritten Fahrstreifen und einen vierten Fahrstreifen. Die veranschaulichte Fahrbahn 114 beinhaltet ferner einen Mittelstreifen und Fahrsteifen in einer zweiten Fahrtrichtung, und zwar einen vierten Fahrstreifen, einen fünften Fahrstreifen, einen sechsten Fahrstreifen und einen achten Fahrstreifen. Es ist anzumerken, dass das konkrete Fahrbahnlayout lediglich ein Beispiel ist.
Die TAM-Nachrichten können Karteninformationen beinhalten, die das Layout der Fahrbahn 114 angeben, wie etwa eine Kreuzungsgeometrieliste und eine Straßensegmentliste. Die Straßensegmentliste beinhaltet verschiedene Eigenschaften der Fahrbahn 114, einschließlich einer Fahrstreifenbeschreibung, eines Status einer hohen Auslastung, ob Fahrstreifen verfügbar sind oder für Verkehr mit hoher Priorität vorbehalten sind, und so weiter. Diese Informationen können zum Beispiel Angaben des Layouts der Fahrstreifen der Fahrbahn 114 beinhalten, die verwendet werden können, um es Fahrzeugen 102 zu ermöglichen, zu identifizieren, wann sie sich einem mautpflichtigen Bereich nähern sowie auf welchem Fahrstreifen das Fahrzeug 102 fährt.
Die Geometrieliste kann auch Informationen zur Mautstraßengeometrie in Bezug auf die Platzierung von Fahrstreifen in einem Mautbereich beinhalten. Zum Beispiel können die TAM-Nachrichten eine Mautgeometriereferenz beinhalten, die einen Referenzpunkt 602 angeben kann, der den geografischen Standort des Mautportals 124 angibt, anhand dessen Standorte des Mautbereichs berechnet werden können (z. B. als Referenzpunkte 602 für jedes der Mautportale 124 gezeigt). Die TAM-Nachrichten können auch Fahrstreifenknotenversätze 604 relativ zu dem Referenzpunkt 602 für das Mautportal 124 angeben sowie welche der Fahrstreifenknotenversätze 604 eine Auslösezone 606, in der eine Maut abgeschlossen werden soll, oder Geometriestandorte 608 vor der Auslösezone 606 angeben. Die TAM-Nachrichten können auch Mautkontextdaten beinhalten, wie etwa Tageszeiten, Fahrstreifen für Fahrgemeinschaften oder andere Einschränkungen oder anderen Kontext bezüglich der Verwendung der Fahrbahn 114.
Welche Fahrstreifenknotenversätze 604 zu verwenden sind, kann von der Fahrtrichtung des Fahrzeugs 102 abhängen. Zum Beispiel fährt das Fahrzeug 102 in dem Beispiel 600 in der Fahrtrichtung von rechts nach links und kann daher seinen Standort in Bezug auf die Fahrstreifenknotenversätze 604 für die Fahrstreifen in dieser Fahrtrichtung (z. B. Fahrstreifen fünf bis acht) referenzieren. Diese Fahrstreifenknotenversätze 604 können eine Mautankündigungszone für die zweite Fahrtrichtung bilden. Die Fahrstreifenknotenversätze 604 für jeden Fahrstreifen können gemeinsam die Auslösezone 606 definieren, in der das Fahrzeug 102 dazu konfiguriert sein kann, die Maut zu bezahlen.
Das Fahrzeug 102 kann aufgrund der unmittelbaren Nähe des Fahrzeugs 102 zu den RSUs 112, die den Mautportalen 124 entsprechen, TAM-Nachrichten von mehr als einem der Mautportale 124 empfangen. Um eine derartige Kommunikation zu verifizieren, kann es rechnerisch komplex sein, jede einzelne Nachricht zu verifizieren. Darüber hinaus kann eine derartige Verifizierung aufgrund der Verarbeitung von Nachrichten, die für den Standort des Fahrzeugs 102 irrelevant sind (z. B. sich auf ein Mautprotal 124 beziehen, in das das Fahrzeug 102 nicht einfährt, sich auf ein Mautportal 124 beziehen, von dem das Fahrzeug 102 wegfährt) oder anderweitig nicht von Interesse sind, zeitkritische Vorgänge beeinflussen. Wie vorstehend angemerkt, kann es zudem unnötig sein, eine Verifizierung für jede Nachricht von den RSUs 112 durchzuführen, z. B. alle 100 Millisekunden. Eine Nachrichtenfilterung durch Nutzen von hochauflösenden statischen Karten in Kombination mit einer komplexen Lokalisierung des Fahrzeugs 102 kann unpraktisch sein. Zusätzlich kann die Auswirkung auf die Übertragungsseite der RSU 112 der TAM oder anderer Mautnachrichten beim Signieren jeder Nachricht ebenfalls belastend sein.
7A-7B veranschaulichen gemeinsam einen beispielhaften Datenfluss 700 für den Betrieb der Fahrzeuganwendung 202 in einem Mautszenario für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung der Nachrichten. In einem Beispiel kann der Datenfluss 700 Komponenten des Systems 100B einschließen, wie vorstehend im Detail erörtert.
Bei Index (A) empfängt das Fahrzeug 102 TAM-Nachrichten von den RSUs 112. Wie gezeigt, kann das Fahrzeug 102 TAM-Nachrichten von einer ersten RSU 112A und auch von einer zweiten RSU 112B empfangen. Es ist anzumerken, dass dies nur eine Möglichkeit ist und sich eine beliebige Anzahl von RSUs 112 in Kommunikationsentfernung zu der OBU 104 des Fahrzeugs 102 befinden kann.
Bei Index (B) nähert sich das Fahrzeug 102 einem Fahrstreifenknotenversatz 604 des Mautportals 124. In einem Beispiel kann das Fahrzeug 102 GNSS-Funktionalität nutzen, um den aktuellen Standort des Fahrzeugs 102 zu bestimmen, und es kann identifizieren, dass das Fahrzeug 102 einen Fahrstreifenknotenversatz 604 erreicht hat, der durch die TAM-Nachricht für eines der Mautportale 124 spezifiziert wird. Wenn dies der Fall ist, stellt das Fahrzeug 102 die Kennung des Mautportals 124 aus der TAM-Nachricht als das aktuelle eingecheckte Mautportal 124 fest. In einigen Beispielen kann das Fahrzeug 102 eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und auf Grundlage der aktuellen Position und/oder Fahrtrichtung sicherstellen, dass die TAM-Nachrichten mit dem eingecheckten Mautportal 124 übereinstimmen, bevor eine Sicherheitsverifizierung der TAM-Nachrichten durchgeführt wird. Dies kann es dem Fahrzeug 102 ermöglichen, die Sicherheitsverarbeitung von TAM-Nachrichten, die nicht für das eingecheckte Mautportal 124 gelten, nicht durchführen zu müssen.
Bei Index (C) sendet das Fahrzeug 102 das Zertifikat aus der TAM-Nachricht an einen Sicherheitsdienst zur Verifizierung. Das Zertifikat kann von einem HSM der sendenden RSU 112 (z. B. der ersten RSU 112A, der zweiten RSU 112B usw.) in die TAM-Nachricht eingeschlossen worden sein. Die RSU 112 kann ihr in die TAM-Nachrichten einzuschließendes Zertifikat über eine Verbindung zu einem Backend-SCMS periodisch aktualisieren. In einem Beispiel kann der Sicherheitsdienst einen SDS über das WAVE-Protokoll, wie durch den WAVE-Standard 1609.2 des IEEE definiert, umsetzen. Der Sicherheitsdienst kann in einem Beispiel umgesetzt werden, um eine Validierung des Zertifikats durchzuführen, um sicherzustellen, dass die TAM-Nachricht authentisch und/oder autorisiert ist. Diese Validierung ist bei Index (D) gezeigt. Bei Index (E) antwortet der Sicherheitsdienst mit der Angabe, ob die TAM-Nachricht gültig ist. Wenn dies der Fall ist,, wird der Datenfluss 700 wie gezeigt fortgesetzt. Falls nicht, endet der Datenfluss 700 (nicht gezeigt).
Bei Index (F) empfängt das Fahrzeug 102 TUMAck-Nachrichten von den RSUs 112. Diese Nachrichten können von den RSUs 112 auf Grundlage von Daten, die von dem Mautportal 124 empfangen werden, übertragen werden. Wie gezeigt, kann das Fahrzeug 102 TUMAck-Nachrichten von einer ersten RSU 112A und auch von einer zweiten RSU 112B empfangen. Es ist anzumerken, dass dies nur eine Möglichkeit ist und sich eine beliebige Anzahl von RSUs 112 in Kommunikationsentfernung zu der OBU 104 des Fahrzeugs 102 befinden kann.
Bei Index (G) bestimmt das Fahrzeug 102, ob die empfangenen TUMAck-Nachrichten mit der aktuellen Portalkennung des Mautportals 124, die durch das Fahrzeug 102 festgestellt wurde, übereinstimmen. In einem Beispiel kann das Fahrzeug 102 eine in den TUMAck-Nachrichten beinhaltete Portalkennung mit der bei Index (B) identifizierten Kennung des eingecheckten Portals vergleichen. Wenn die TUMAck für das eingecheckte Mautportal 124 gilt, wird der Datenfluss 500 fortgesetzt, um diese Nachricht zu verarbeiten. Falls nicht, endet der Datenfluss 500 in Bezug auf diese TUMAck-Nachricht. In einigen Beispielen kann das Fahrzeug 102 ferner eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und auf Grundlage der aktuellen Position und/oder Fahrtrichtung sicherstellen, dass die TUMAck-Nachrichten mit dem eingecheckten Mautportal 124 übereinstimmen, bevor eine Sicherheitsverifizierung der TUMAck-Nachrichten durchgeführt wird. Dies kann es dem Fahrzeug 102 ermöglichen, die Sicherheitsverarbeitung von TUMAck-Nachrichten, die nicht für das eingecheckte Mautportal 124 gelten, nicht durchführen zu müssen.
Bei Index (H) verifiziert das Fahrzeug 102 das Zertifikat aus der TUMAck-Nachricht unter Verwendung des Sicherheitsdienstes. Diese Verifizierung wird bei Index (I) durchgeführt, ähnlich wie in Bezug auf die Indizes (C) und (D) für die TAM-Nachrichten erörtert. Das Ergebnis wird bei Index (J) an das Fahrzeug 102 zurückgegeben, ähnlich wie vorstehend in Bezug auf Index (E) erörtert.
Wenn die TUMAck-Nachricht als gültig bestätigt wird, kann bei Index (K) die TUMAck-Nachricht zur Verwendung an die Fahrzeuganwendungen 202 weitergeleitet werden. Somit beinhalten die Nachrichten, die weitergeleitet werden, nur diejenigen Nachrichten, die mit der aktuellen Kreuzung 300 übereinstimmen und die auch über den Sicherheitsdienst validiert sind. Die anderen Nachrichten, die nicht übereinstimmen oder gültig sind, können dementsprechend verworfen werden.
Unter Bezugnahme auf 7B verlässt das Fahrzeug 102 bei Index (L) die Auslösezone 606 des Mautportals 124. In einem Beispiel kann das Fahrzeug 102 GNSS-Funktionalität nutzen, um den aktuellen Standort des Fahrzeugs 102 zu bestimmen, und es kann identifizieren, dass das Fahrzeug 102 die Auslösezone 606 verlassen hat, die durch die TUM-Nachricht für das aktuelle eingecheckte Mautportal 124 spezifiziert wird.
Wenn dies der Fall ist, stellt das Fahrzeug 102 bei Index (M) die Kennung des Mautportals 124 aus der TUM-Nachricht als nicht mehr das aktuelle eingecheckte Mautportal 124 fest. Stattdessen kann das Fahrzeug 102 zum Beispiel angeben, dass kein Mautportal 124 das aktuelle eingecheckte Mautportal 124 ist.
Bei Index (N) gibt das Fahrzeug 102 den Fahrzeuganwendungen 202 an, dass es kein eingechecktes Mautportal 124 mehr gibt. Dies kann es der Fahrzeuganwendung 202 in einem Beispiel ermöglichen, ihren Zustand zu aktualisieren, um keine Mautdienste mehr durchzuführen, und/oder der Navigation anzugeben, dass das Fahrzeug 102 das Mautportal 124 verlässt. Nach Index (N) endet der Datenfluss 700. Als eine Variation ist anzumerken, dass das Fahrzeug 102 bei den Indizes (M)-(N) auch identifizieren kann, dass das Verlassen des aktuellen eingecheckten Mautportals 124 zu einem neuen aktuellen eingecheckten Mautportal 124 führt. Zum Beispiel kann das Fahrzeug 102 eine aktuelle Position und/oder Fahrtrichtung des Fahrzeugs 102 identifizieren und sicherstellen, dass der Standort und/oder die Fahrtrichtung des Fahrzeugs 102 mit dem Eincheckstandort 304 des nächsten Mautportals 124 übereinstimmen. In einem derartigen Fall kann das aktuelle eingecheckte Mautportal 124 auf das neue Mautportal 124, dem sich genähert wird, aktualisiert werden.
8 veranschaulicht einen ersten Teil eines Prozesses 800 für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten. In einem Beispiel kann der Prozess 800 durch das Fahrzeug 102 im Kontext des Systems 100A und/oder des Systems 100B durchgeführt werden.
Bei Vorgang 802 empfängt das Fahrzeug 102 erste Nachrichten von einer oder mehreren RSUs 112. Die OBU 104 des Fahrzeugs 102 kann dazu konfiguriert sein, drahtlose Nachrichten zu empfangen, und kann erste Nachrichten empfangen, die von der einen oder den mehreren RSUs 112 übertragen werden. In einem Beispiel können die ersten Nachrichten MAP-Nachrichten sein, wie in Bezug auf 3, 4 und 5A-5B erörtert. In einem anderen Beispiel können die ersten Nachrichten TAM-Nachrichten sein, wie in Bezug auf 6 und 7A-7B erörtert.
Bei Vorgang 804 führt das Fahrzeug 102 eine Validierung der ersten Nachrichten durch. In einem Beispiel kann dies Sicherstellen beinhalten, dass die Kreuzung 300 und/oder das Mautportal 124, die durch die ersten Nachrichten angegeben werden, mit dem aktuellen Standort und/oder der aktuellen Fahrtrichtung des Fahrzeugs 102 übereinstimmen. Wenn die ersten Nachrichten nicht übereinstimmen, muss die Sicherheitsverifizierung nicht durchgeführt werden. Wenn die erste Nachricht übereinstimmt, kann das Fahrzeug 102 die ersten Nachrichten verifizieren, indem es ein Zertifikat aus den Nachrichten abruft und das Zertifikat zur Verifizierung sendet. Die Verifizierung kann in einem Beispiel gemäß dem WAVE-Protokoll durchgeführt werden, wie vorstehend erörtert. In einem Beispiel kann das Fahrzeug 102 für jede erste Nachricht eine Verifizierungsanforderung senden, die das Zertifikat beinhaltet, und kann es eine Antwort empfangen, die angibt, ob das Zertifikat angibt, dass die erste Nachricht gültig ist.
Bei Vorgang 806 bestimmt das Fahrzeug 102, ob die ersten Nachrichten gültig sind. In einem Beispiel, wenn die Antwort angibt, dass die erste Nachricht gültig ist, geht die Steuerung zu Vorgang 808 über. Falls nicht, kehrt die Steuerung zu Vorgang 802 zurück, um erneut erste Nachrichten zu empfangen.
Bei Vorgang 808 identifiziert das Fahrzeug 102 die Position des Fahrzeugs 102. In einem Beispiel kann das Fahrzeug 102 GNSS oder eine andere Positionsbestimmungstechnologie nutzen, um den aktuellen Standort des Fahrzeugs 102 zu bestimmen.
Bei Vorgang 810 bestimmt das Fahrzeug 102, ob sich das Fahrzeug 102 einem Eincheckpunkt nähert. In einem Beispiel kann das Fahrzeug 102 unter Verwendung des bei Vorgang 808 bestimmten Standorts des Fahrzeugs 102 und der Informationen in den ersten Nachrichten (z. B. MAP-Nachrichten) bestimmen, ob es in einen Eincheckstandort 304 für eine Kreuzung 300 eingefahren ist. In einem anderen Beispiel kann das Fahrzeug 102 unter Verwendung des bei Vorgang 808 bestimmten Standorts des Fahrzeugs 102 und der Fahrstreifenknotenversätze 604 in den ersten Nachrichten (z. B. TAM-Nachrichten) bestimmen, ob es in eine Auslösezone 606 für ein Mautportal 124 eingefahren ist. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 812 über. Falls nicht, wird die Steuerung in Vorgang 816 fortgesetzt.
Bei Vorgang 812 setzt das Fahrzeug 102 die Kennung für den Eincheckpunkt als aktuellen Eincheckpunkt. Diese Kennung der Kreuzung 300 oder des Mautportals 124 kann aus den ersten Nachrichten abgerufen werden.
Bei Vorgang 814 leitet das Fahrzeug 102 die ersten Nachrichten an die Fahrzeuganwendung 202 weiter. Somit beinhalten die ersten Nachrichten, die weitergeleitet werden, nur diejenigen ersten Nachrichten, die mit der aktuellen eingecheckten Kennung übereinstimmen und die auch über den Sicherheitsdienst validiert sind. Die anderen ersten Nachrichten, die nicht übereinstimmen oder gültig sind, können dementsprechend verworfen werden. Nach Vorgang 814 kehrt die Steuerung zu Vorgang 802 zurück.
Bei Vorgang 816 bestimmt das Fahrzeug 102, ob das Fahrzeug 102 einen Eincheckpunkt verlässt. In einem Beispiel kann das Fahrzeug 102 unter Verwendung des bei Vorgang 808 bestimmten Standorts des Fahrzeugs 102 und der Informationen in den ersten Nachrichten (z. B. MAP-Nachrichten) bestimmen, ob es in einen Auscheckstandort 310 für die Kreuzung 300 eingefahren ist. In einem anderen Beispiel kann das Fahrzeug 102 unter Verwendung des bei Vorgang 808 bestimmten Standorts des Fahrzeugs 102 und der Fahrstreifenknotenversätze 604 in den ersten Nachrichten (z. B. TAM-Nachrichten) bestimmen, ob es die Auslösezone 606 für das Mautportal 124 verlassen hat. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 818 über. Falls nicht, wird die Steuerung in Vorgang 802 fortgesetzt.
Bei Vorgang 818 setzt das Fahrzeug 102 die Kennung für den Eincheckpunkt zurück. Somit kann die Kennung der aktuellen Kreuzung 300 oder des aktuellen Mautportals 124 auf einen Wert gesetzt werden, der angibt, dass es keine aktuelle eingecheckte Kreuzung 300 und/oder kein aktuelles eingechecktes Mautportal 124 gibt. Nach Vorgang 818 kehrt die Steuerung zu Vorgang 802 zurück.
9 veranschaulicht einen beispielhaften zweiten Teil eines Prozesses 900 für die Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten. In einem Beispiel kann der Prozess 900 wie der erste Teil des Prozesses 800 durch das Fahrzeug 102 im Kontext der Systeme 100A und/oder 100B durchgeführt werden.
Bei Vorgang 902 empfängt das Fahrzeug 102 zweite Nachrichten der einen oder den mehreren RSUs 112. Ähnlich wie bei Vorgang 802 kann die OBU 104 des Fahrzeugs 102 dazu konfiguriert sein, drahtlose Nachrichten zu empfangen, und kann sie zweite Nachrichten empfangen, die von der einen oder den mehreren RSUs 112 übertragen werden. In einem Beispiel können die zweiten Nachrichten SSM-Nachrichten sein, wie in Bezug auf 3, 4 und 5A-5B erörtert. In einem anderen Beispiel können die ersten Nachrichten TUMAck - Nachrichten sein, wie in Bezug auf 6 und 7A-7B erörtert.
Bei Vorgang 904 bestimmt das Fahrzeug 102, ob die zweite Nachricht der Eincheckkennung entspricht. Zum Beispiel kann die Kennung der Kreuzung 300 oder des Mautportals 124 aus den zweiten Nachrichten abgerufen werden. Diese Kennung kann mit der bei Vorgang 812 gespeicherten Kennung für die eingecheckte Kreuzung 300 oder das eingecheckte Mautportal 124 verglichen werden. Wenn die zweite Nachricht übereinstimmt, geht die Steuerung zu Vorgang 906 über. Anderenfalls kehrt die Steuerung zu Vorgang 902 zurück.
Bei Vorgang 906 validiert das Fahrzeug 102 die zweite Nachricht. In einem Beispiel kann dies Sicherstellen beinhalten, dass die Kreuzung 300 und/oder das Mautportal 124, die durch die zweiten Nachrichten angegeben werden, mit dem aktuellen Standort und/oder der aktuellen Fahrtrichtung des Fahrzeugs 102 übereinstimmen. Wenn die zweiten Nachrichten nicht übereinstimmen, muss die Sicherheitsverifizierung nicht durchgeführt werden. Wenn die zweite Nachricht übereinstimmt, kann das Fahrzeug 102 die zweiten Nachrichten verifizieren, indem es ein Zertifikat aus den Nachrichten abruft und das Zertifikat zur Verifizierung sendet. Die Verifizierung kann in einem Beispiel gemäß dem WAVE-Protokoll durchgeführt werden, wie vorstehend erörtert. In einem Beispiel kann das Fahrzeug 102 für jede zweite Nachricht eine Verifizierungsanforderung senden, die das Zertifikat beinhaltet, und kann es eine Antwort empfangen, die angibt, ob das Zertifikat angibt, dass die zweite Nachricht gültig ist.
Bei Vorgang 908 bestimmt das Fahrzeug 102, ob die zweite Nachricht gültig ist. In einem Beispiel, wenn die Antwort angibt, dass die zweite Nachricht gültig ist, geht die Steuerung zu Vorgang 910 über. Falls nicht, kehrt die Steuerung zu Vorgang 902 zurück, um erneut zweite Nachrichten zu empfangen.
Bei Vorgang 910 leitet das Fahrzeug 102 die zweite Nachricht an die Fahrzeuganwendung 202 weiter. Somit beinhalten die zweiten Nachrichten, die weitergeleitet werden, nur diejenigen zweiten Nachrichten, die mit der aktuellen eingecheckten Kennung übereinstimmen und die auch über den Sicherheitsdienst validiert sind. Die anderen zweiten Nachrichten, die nicht übereinstimmen oder gültig sind, können dementsprechend verworfen werden. Nach Vorgang 910 kehrt die Steuerung zu Vorgang 902 zurück.
10 veranschaulicht ein Beispiel 1000 für eine Verwendung einer Rechenvorrichtung 1002 bei der Filterung von V2I-Nachrichten vor einer Sicherheitsverifizierung oder anderen Verarbeitung von Nachrichten. Unter Bezugnahme auf 10 und mit Bezug auf 1-9 können die OBU 104, die RSU 112, der Cloud-Server 116 und die Verkehrssignalsteuerung 118 Beispiele für derartige Rechenvorrichtungen 1002 sein. Wie gezeigt, kann die Rechenvorrichtung 1002 einen Prozessor 1004 beinhalten, der mit einem Speicher 1006, einer Netzwerkvorrichtung 1008, einer Ausgabevorrichtung 1010 und einer Eingabevorrichtung 1012 wirkverbunden ist. Es ist anzumerken, dass dies lediglich ein Beispiel ist und Rechenvorrichtungen 1002 mit mehr, weniger oder unterschiedlichen Komponenten verwendet werden können.
Der Prozessor 1004 kann eine oder mehrere integrierte Schaltungen beinhalten, die die Funktionalität einer zentralen Verarbeitungseinheit (central processing unit - CPU) und/oder Grafikverarbeitungseinheit (graphics processing unit - GPU) umsetzen. In einigen Beispielen sind die Prozessoren 1004 ein System auf einem Chip (system on a chip - SoC), in das die Funktionalität der CPU und der GPU integriert ist. Das SoC kann optional andere Komponenten wie zum Beispiel den Speicher 1006 und die Netzwerkvorrichtung 1008 in einer einzigen integrierten Vorrichtung beinhalten. In anderen Beispielen sind die CPU und die GPU über eine Peripherie-Verbindungsvorrichtung, wie etwa Peripheral-Component-Interconnect-Express (PCI-Express) oder eine andere geeignete Peripherie-Datenverbindung, miteinander verbunden. In einem Beispiel handelt es sich bei der CPU um eine handelsübliche zentrale Verarbeitungsvorrichtung, die einen Anweisungssatz umsetzt, wie etwa eine von der x86-, ARM-, Power- oder Microprocessor-without-Interlocked-Pipeline-Stages-(MIPS)Anweisungssatzfamilie.
Unabhängig von den Einzelheiten führt der Prozessor 1004 während des Betriebs gespeicherte Programmanweisungen aus, die aus dem Datenspeicher 1006 abgerufen werden. Die gespeicherten Programmanweisungen beinhalten entsprechend Software, die den Betrieb der Prozessoren 1004 steuert, um die in dieser Schrift beschriebenen Vorgänge durchzuführen. Der Speicher 1006 kann sowohl nicht flüchtige als auch flüchtige Speichervorrichtungen beinhalten. Der nicht flüchtige Speicher beinhaltet Festkörperspeicher, wie etwa Nicht-UND-(not and - NAND-)Flash-Speicher, magnetische und optische Speichermedien oder eine beliebige andere geeignete Datenspeichervorrichtung, die Daten aufbewahrt, wenn das System deaktiviert oder dessen Stromversorgung unterbrochen ist. Der flüchtige Speicher beinhaltet einen statischen und dynamischen Direktzugriffsspeicher (random-access memory - RAM), auf dem während des Betriebs des Systems 100A-B Programmanweisungen und Daten gespeichert werden.
Die GPU kann Hardware und Software zur Anzeige von mindestens zweidimensionalen (2D-) und optional dreidimensionalen (3D-)Grafiken auf der Ausgabevorrichtung 1010 beinhalten. Die Ausgabevorrichtung 1010 kann eine grafische oder visuelle Anzeigevorrichtung, wie etwa einen elektronischen Anzeigebildschirm, einen Projektor, einen Drucker oder eine beliebige andere geeignete Vorrichtung, die eine grafische Anzeige wiedergibt, beinhalten. Als ein weiteres Beispiel kann die Ausgabevorrichtung 1010 eine Audiovorrichtung, wie etwa einen Lautsprecher oder einen Kopfhörer, beinhalten. Als noch ein weiteres Beispiel kann die Ausgabevorrichtung 1010 eine taktile Vorrichtung beinhalten, wie etwa eine mechanisch anhebbare Vorrichtung, die in einem Beispiel dazu konfiguriert sein kann, Brailleschrift oder eine andere physische Ausgabe anzuzeigen, die berührt werden kann, um einem Benutzer Informationen bereitzustellen.
Die Eingabevorrichtung 1012 kann eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der Rechenvorrichtung 1002 erlauben, Steuereingaben von Benutzern zu empfangen. Beispiele für geeignete Eingabevorrichtungen 1012, die menschliche Eingaben über eine Schnittstelle empfangen, können Tastaturen, Mäuse, Trackballs, Touchscreens, Sprachmikrofone, Grafiktablets und dergleichen beinhalten.
Die Netzwerkvorrichtungen 1008 können jeweils eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der OBU 104, der RSU 112 und/oder der Verkehrssignalsteuerung 118 ermöglichen, Daten von externen Vorrichtungen über Netzwerke (wie etwa das Kommunikationsnetzwerk 110) zu senden und/oder zu empfangen. Beispiele für geeignete Netzwerkvorrichtungen 1008 beinhalten eine Ethernet-Schnittstelle, einen Wi-Fi-Sendeempfänger, einen Mobilfunk-Sendeempfänger, einen BLUETOOTH- oder BLUETOOTH-Low-Energy-(BLE-)Sendeempfänger oder einen anderen Netzwerkadapter oder eine andere Peripherie-Verbindungsvorrichtung, der/die Daten von einem anderen Computer oder einer externen Speichervorrichtung empfängt, was zum Empfangen großer Datensätze auf effiziente Weise nützlich sein kann.
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen beschreiben, die durch die Patentansprüche eingeschlossen sind. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Offenbarung zu bilden, die unter Umständen nicht ausdrücklich beschrieben oder veranschaulicht sind. Wenngleich verschiedene Ausführungsformen gegenüber anderen Ausführungsformen oder Umsetzungen nach dem Stand der Technik in Bezug auf eine oder mehrere gewünschte Eigenschaften als vorteilhaft oder bevorzugt beschrieben worden sein könnten, erkennt der Durchschnittsfachmann, dass bei einem/einer oder mehreren Merkmalen oder Eigenschaften Kompromisse eingegangen werden können, um die gewünschten Gesamtattribute des Systems zu erzielen, die von der konkreten Anwendung und Umsetzung abhängen. Diese Attribute können Festigkeit, Haltbarkeit, Lebenszyklus, Marktfähigkeit, Erscheinungsbild, Verbauung, Größe, Wartbarkeit, Gewicht, Herstellbarkeit, Einfachheit der Montage usw. beinhalten, sind aber nicht darauf beschränkt. Soweit beliebige Ausführungsformen in Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder Umsetzungen nach dem Stand der Technik beschrieben werden, liegen diese Ausführungsformen demnach nicht außerhalb des Umfangs der Offenbarung und können für konkrete Anwendungen wünschenswert sein.
Gemäß der vorliegenden Erfindung wird ein Fahrzeug zum Durchführen einer Filterung von Infrastruktur-zu-Fahrzeug-(I2V-)Nachrichten bereitgestellt, das Folgendes aufweist: einen Sendeempfänger; und eine Bordeinheit (OBU), die zu Folgendem programmiert ist: Empfangen erster Nachrichten von einer oder mehreren straßenseitigen Einheiten (RSUs), als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug, Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs, als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung und anderenfalls Verwerfen der zweiten Nachrichten.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, die ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an die Fahrzeuganwendung zur Verarbeitung weiterzuleiten.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, die Eincheckstandortkennung aus dem Speicher zu entfernen, um den aktuellen Eincheckstandort zurückzusetzen.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, zu verifizieren, dass die ersten Nachrichten gültig sind, bevor der Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, auf Grundlage der aktuellen Position und/oder Fahrtrichtung, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, die ersten Nachrichten unter Verwendung des Protokolls für drahtlosen Zugang in Fahrzeugumgebungen (WAVE), wie durch den WAVE-Standard 1609.2 des Institute of Electrical and Electronics Engineer (IEEE) definiert, zu verifizieren.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, zu verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
Gemäß einer Ausführungsform ist die OBU ferner dazu programmiert, die zweiten Nachrichten unter Verwendung des WAVE-Protokolls, wie durch den WAVE-Standard 1609.2 des IEEE definiert, zu verifizieren.
Gemäß einer Ausführungsform sind die ersten Nachrichten MAP-Nachrichten und sind die zweiten Nachrichten Signalstatusnachrichten (SSMs).
Gemäß einer Ausführungsform sind die ersten Nachrichten Mautzugangsnachrichtennachrichten (TAM-Nachrichten) und sind die zweiten Nachrichten Mautnutzungsnachrichtenbestätigungsnachrichten (TUMAck-Nachrichten).
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren zum Durchführen einer Filterung von I2V-Nachrichten durch ein Fahrzeug: Empfangen erster Nachrichten von einer oder mehreren straßenseitigen Einheiten (RSUs), als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug, Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs, als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung und anderenfalls Verwerfen der zweiten Nachrichten.
In einem Aspekt der Erfindung beinhaltet das Verfahren Weiterleiten der ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an die Fahrzeuganwendung zur Verarbeitung.
In einem Aspekt der Erfindung beinhaltet das Verfahren, als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, Entfernen der Eincheckstandortkennung aus dem Speicher, um den aktuellen Eincheckstandort zurückzusetzen.
In einem Aspekt der Erfindung beinhaltet das Verfahren Verifizieren, dass die ersten Nachrichten gültig sind, bevor der Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die ersten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der ersten Nachrichten beinhaltet.
In einem Aspekt der Erfindung beinhaltet das Verfahren Verifizieren der ersten Nachrichten unter Verwendung des Protokolls für drahtlosen Zugang in Fahrzeugumgebungen (WAVE), wie durch den WAVE-Standard 1609.2 des Institute of Electrical and Electronics Engineer (IEEE) definiert.
In einem Aspekt der Erfindung beinhaltet das Verfahren Verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
In einem Aspekt der Erfindung beinhaltet das Verfahren Verifizieren der zweiten Nachrichten unter Verwendung des WAVE-Protokolls, wie durch den WAVE-Standard 1609.2 des IEEE definiert.
In einem Aspekt der Erfindung gilt eines von Folgenden: Die ersten Nachrichten sind MAP-Nachrichten und die zweiten Nachrichten sind Signalstatusnachrichten (SSMs); oder die ersten Nachrichten sind Mautzugangsnachrichtennachrichten (TAM-Nachrichten) und die zweiten Nachrichten Mautnutzungsnachrichtenbestätigungsnachrichten (TUMAck-Nachrichten).
Gemäß der vorliegenden Erfindung wird ein nicht transitorisches computerlesbares Medium bereitgestellt, das Anweisungen zum Durchführen einer Filterung von I2V-Nachrichten aufweist, die bei Ausführung durch eine OBU eines Fahrzeugs die OBU dazu veranlassen, Vorgänge durchzuführen, die Folgendes beinhalten: Empfangen erster Nachrichten von einer oder mehreren straßenseitigen Einheiten (RSUs); Verifizieren, dass die ersten Nachrichten gültig sind, bevor ein Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die ersten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der ersten Nachrichten beinhaltet; als Reaktion darauf, dass sich das Fahrzeug dem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug; als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, Entfernen der Eincheckstandortkennung aus dem Speicher, um den aktuellen Eincheckstandort zurückzusetzen; Weiterleiten der ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an eine Fahrzeuganwendung zur Verarbeitung; Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs; Verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden, wobei das zweite Verifizieren Identifizieren der aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet; als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an die Fahrzeuganwendung zur Verarbeitung; und anderenfalls Verwerfen der zweiten Nachrichten.
Gemäß einer Ausführungsform gilt eines von Folgenden: die ersten Nachrichten sind MAP-Nachrichten und die zweiten Nachrichten sind Signalstatusnachrichten (SSMs); oder die ersten Nachrichten sind Mautzugangsnachrichtennachrichten (TAM-Nachrichten) und die zweiten Nachrichten sind Mautnutzungsnachrichtenbestätigungsnachrichten (TUMAck-Nachrichten).

Claims

Fahrzeug zum Durchführen einer Filterung von Infrastruktur-zu-Fahrzeug-(I2V-)Nachrichten, umfassend: einen Sendeempfänger; und eine Bordeinheit (OBU), die zu Folgendem programmiert ist: Empfangen erster Nachrichten von einer oder mehreren straßenseitigen Einheiten (RSUs), als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug, Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs, als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung und anderenfalls Verwerfen der zweiten Nachrichten.
Fahrzeug nach Anspruch 1, wobei die OBU ferner dazu programmiert ist, die ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an die Fahrzeuganwendung zur Verarbeitung weiterzuleiten.
Fahrzeug nach Anspruch 1, wobei die OBU ferner dazu programmiert ist, als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, die Eincheckstandortkennung aus dem Speicher zu entfernen, um den aktuellen Eincheckstandort zurückzusetzen.
Fahrzeug nach Anspruch 1, wobei die OBU ferner dazu programmiert ist, zu verifizieren, dass die ersten Nachrichten gültig sind, bevor der Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, auf Grundlage der aktuellen Position und/oder Fahrtrichtung, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
Fahrzeug nach Anspruch 1, wobei die OBU ferner zu einem oder mehreren von Folgenden programmiert ist: Verifizieren der ersten Nachrichten unter Verwendung des Protokolls für drahtlosen Zugang in Fahrzeugumgebungen (WAVE), wie durch den WAVE-Standard 1609.2 des Institute of Electrical and Electronics Engineer (IEEE) definiert, oder Verifizieren der zweiten Nachrichten unter Verwendung des WAVE-Protokolls, wie durch den WAVE-Standard 1609.2 des IEEE definiert.
Fahrzeug nach Anspruch 1, wobei die OBU ferner dazu programmiert ist, zu verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
Fahrzeug nach Anspruch 1, wobei die ersten Nachrichten MAP-Nachrichten sind und die zweiten Nachrichten Signalstatusnachrichten (SSMs) sind.
Fahrzeug nach Anspruch 1, wobei die ersten Nachrichten Mautzugangsnachrichtennachrichten (TAM-Nachrichten) sind und die zweiten Nachrichten Mautnutzungsnachrichtenbestätigungsnachrichten (TUMAck-Nachrichten) sind.
Verfahren zum Durchführen einer Filterung von I2V-Nachrichten durch ein Fahrzeug, umfassend: Empfangen erster Nachrichten von einer oder mehreren straßenseitigen Einheiten (RSUs), als Reaktion darauf, dass sich das Fahrzeug einem Eincheckstandort nähert, der durch die ersten Nachrichten angegeben wird, Speichern einer Eincheckstandortkennung für den Eincheckstandort, der aus den ersten Nachrichten abgerufen wurde, als einen aktuellen Eincheckstandort für das Fahrzeug, Empfangen zweiter Nachrichten von der einen oder den mehreren RSUs, als Reaktion darauf, dass eine Nachrichtenkennung in den zweiten Nachrichten mit der Eincheckstandortkennung übereinstimmt, Weiterleiten der zweiten Nachrichten an eine Fahrzeuganwendung zur Verarbeitung und anderenfalls Verwerfen der zweiten Nachrichten.
Verfahren nach Anspruch 9, ferner umfassend Weiterleiten der ersten Nachrichten, die mit dem aktuellen Eincheckstandort übereinstimmen, an die Fahrzeuganwendung zur Verarbeitung.
Verfahren nach Anspruch 9, ferner umfassend, als Reaktion darauf, dass das Fahrzeug einen Auscheckstandort verlässt, der durch die ersten Nachrichten angegeben wird, Entfernen der Eincheckstandortkennung aus dem Speicher, um den aktuellen Eincheckstandort zurückzusetzen.
Verfahren nach Anspruch 9, ferner umfassend Verifizieren, dass die ersten Nachrichten gültig sind, bevor der Eincheckstandort, der durch die ersten Nachrichten angegeben wird, genutzt wird, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die ersten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der ersten Nachrichten beinhaltet.
Verfahren nach Anspruch 9, ferner umfassend eines oder mehrere von Folgenden: Verifizieren der ersten Nachrichten unter Verwendung des Protokolls für drahtlosen Zugang in Fahrzeugumgebungen (WAVE), wie durch den WAVE-Standard 1609.2 des Institute of Electrical and Electronics Engineer (IEEE) definiert, oder Verifizieren der zweiten Nachrichten unter Verwendung des WAVE-Protokolls, wie durch den WAVE-Standard 1609.2 des IEEE definiert.
Verfahren nach Anspruch 9, ferner umfassend Verifizieren, dass die zweiten Nachrichten gültig sind, bevor die zweiten Nachrichten an die Fahrzeuganwendung weitergeleitet werden, wobei das Verifizieren Identifizieren einer aktuellen Position und/oder Fahrtrichtung des Fahrzeugs und Sicherstellen, dass die zweiten Nachrichten mit dem Eincheckstandort übereinstimmen, vor dem Durchführen einer Sicherheitsverifizierung der zweiten Nachrichten beinhaltet.
Verfahren nach Anspruch 9, wobei eines von Folgenden gilt: die ersten Nachrichten sind MAP-Nachrichten und die zweiten Nachrichten sind Signalstatusnachrichten (SSMs); oder die ersten Nachrichten sind Mautzugangsnachrichtennachrichten (TAM-Nachrichten) und die zweiten Nachrichten sind Mautnutzungsnachrichtenbestätigungsnachrichten (TUMAck-Nachrichten).