DE102023131726A1

DE102023131726A1 - Validierung eines strassennutzungsgebührensystems

Info

Publication number: DE102023131726A1
Application number: DE102023131726.1A
Authority: DE
Inventors: Ivan Vukovic; Krishna Bandi; Sathyanaraya Chary Palakonda; Syed Amaar Ahmad; Joseph Zane
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2022-11-22
Filing date: 2023-11-14
Publication date: 2024-05-23
Also published as: CN118096145A; US20240169765A1

Abstract

Das Durchführen einer Validierung von Straßennutzungsgebühren(RUC)-Systemen wird bereitgestellt. Ein Hardware-Prozessor eines Fahrzeugs empfängt von einer HMI des Fahrzeugs eine Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist. Im Testmodus werden RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test berechnet. Ein oder mehrere Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität werden erzeugt, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.

Description

TECHNISCHES GEBIET
Aspekte der Offenbarung betreffen im Allgemeinen die Validierung von Straßennutzungsgebührensystemen.
ALLGEMEINER STAND DER TECHNIK
Eine Straßennutzungsgebühr (road usage charging - RUC), die mitunter als Entgelt für zurückgelegte Fahrzeugmeilen (vehicle miles traveled - VMT) oder meilenbasiertes Benutzerentgelt (mileage-based user fee - MBUF) bezeichnet wird, ist ein Konzept, durch das Autofahrer für die Verwendung des Fahrbahnnetzes in Abhängigkeit von der zurückgelegten Entfernung bezahlen. Die VMT sind möglicherweise nicht die einzige Eingabe in die Entgeltberechnung, da die Uhrzeit oder die auf der Straße verbrachte Zeit ebenfalls eine Eingabe in die Entgeltberechnung sein kann.
Wie bei der Mauterhebung handelt es sich bei der RUC um ein direktes Benutzerentgelt, das ein „Benutzer-bezahlt“-Prinzip der Finanzierung des Verkehrswesens sowie die Auffassung der Verwaltung von Straßennetzen als Infrastruktur unterstützt. Während Mautsysteme im Allgemeinen in einer oder mehreren Einrichtungen, wie etwa Schnellstraßenkorridoren, Brücken oder Tunneln, eingesetzt werden, können Straßennutzungsgebühren für alle Straßen in einem definierten Zuständigkeitsbereich oder einer definierten Geografie zu jeder Zeit anfallen. Die RUC kann unter Verwendung eines breiten Bereichs von Ansätzen umgesetzt werden, von Papierlizenzen und Tachoständen bis hin zu automatisierten Technologien, wie etwa fahrzeuginternen Vorrichtungen und in Fahrzeuge eingebauten Telematiksystemen.
KURZDARSTELLUNG
In einem oder mehreren veranschaulichenden Beispielen wird ein Fahrzeug zum Durchführen einer Validierung von RUC-Systemen bereitgestellt. Das Fahrzeug beinhaltet eine Mensch-Maschine-Schnittstelle (human machine interface - HMI). Das Fahrzeug beinhaltet ferner einen Hardware-Prozessor, der programmiert ist zum Empfangen einer Eingabe von der HMI, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist, im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test, und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
In einem oder mehreren veranschaulichenden Beispielen wird ein Verfahren zum Durchführen einer Validierung von RUC-Systemen bereitgestellt. Das Verfahren beinhaltet Empfangen, an einem Hardware-Prozessor eines Fahrzeugs, von einer HMI des Fahrzeugs, einer Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist; im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test; und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein nicht transitorisches computerlesbares Medium Anweisungen zum Durchführen einer Validierung von RUC-Systemen, die bei Ausführung durch einen Hardware-Prozessor eines Fahrzeugs das Fahrzeug zum Durchführen von Vorgängen veranlassen, die Folgendes beinhalten: Empfangen, von einer HMI des Fahrzeugs, einer Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist, wobei die Eingabe eine Spezifikation einer einheitlichen Ressourcenkennung (uniform resource identifier - URI) eines Zertifizierungsservers beinhaltet; im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test, wobei die Route eine Vielzahl von Gebührendomänen durchquert; Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind, wobei der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht beinhalten, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind; und Senden des einen oder der mehreren Berichte zur Validierung an die URI des Zertifizierungsservers, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 veranschaulicht eine beispielhafte Referenzarchitektur eines kompletten RUC-Systems;
2 veranschaulicht eine beispielhafte RUC-Architektur zum Durchführen einer Validierung mit der RUC-Anwendung, die als ein Fahrzeugteil der RUC-Anwendung und ein Cloud-Teil der RUC-Anwendung umgesetzt ist;
3 veranschaulicht eine alternative beispielhafte RUC-Architektur zum Durchführen einer Validierung mit der RUC-Anwendung, die als eine fahrzeugumgesetzte RUC-Anwendung umgesetzt ist;
4 veranschaulicht ein Beispiel für die Verwendung der RUC-Architektur, um den Schutz der in dem RUC-Bericht beinhalteten Daten zu erhöhen;
5 veranschaulicht ein Beispiel für die Verwendung der RUC-Architektur aus 3, um den Schutz der in dem internen RUC-Bericht beinhalteten Daten zu erhöhen, ohne dass die Verwendung des Cloud-Teils der RUC-Anwendung oder der sicheren Anwendungs-Cloud erforderlich ist;
6 veranschaulicht ein beispielhaftes Datenablaufdiagramm der Kommunikation zwischen der RUC-Anwendung und dem RUC-Dienstanbieter;
7 veranschaulicht ein Beispiel für einen Zertifizierungsansatz, bei dem ein Fahrzeug einem Zertifizierungsserver eine Berichterstattung über eine Route durch mehrere Gebührendomänen bereitstellt;
8 veranschaulicht einen beispielhaften Prozess zum Zertifizieren der RUC-Anwendung in einer Testeinrichtung;
9 veranschaulicht eine beispielhafte HMI für die Konfiguration des Fahrzeugs in einen Zertifizierungsmodus;
10 veranschaulicht eine beispielhafte HMI, die einen Alarm für das Fahrzeug im Zertifizierungsmodus veranschaulicht, um zu dem Startstandort der Route vorzurücken;
11 veranschaulicht eine beispielhafte HMI, die den Alarm für das Fahrzeug im Zertifizierungsmodus veranschaulicht, um zu dem Endstandort der Route vorzurücken;
12 veranschaulicht eine beispielhafte HMI, die den Alarm für das Fahrzeug im Zertifizierungsmodus veranschaulicht, der den Abschluss der Route zeigt;
13 veranschaulicht einen beispielhaften Prozess zum Testen der RUC-Anwendung durch eine Drittpartei in einem Feldtestmodus; und
14 veranschaulicht eine beispielhafte HMI, die ein Selbsttest-beginnen-Steuerelement zum Einleiten eines Tests im Feldtestmodus beinhaltet;
15 veranschaulicht eine beispielhafte HMI, die ein Selbsttest-beenden-Steuerelement zum Abschließen eines Tests im Feldtestmodus beinhaltet; und
16 veranschaulicht ein Beispiel für eine Rechenvorrichtung zur Verwendung bei der Validierung von RUC-Systemen.

DETAILLIERTE BESCHREIBUNG
Wie erforderlich, werden in dieser Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können stark vergrößert oder verkleinert sein, um Details konkreter Komponenten zu zeigen. Daher sind in dieser Schrift offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann den vielfältigen Einsatz der vorliegenden Erfindung zu lehren.
Mit dem wachsenden Interesse an nachhaltigen und gerechten Verfahren zum Bezahlen der Wartung und des Betrieb von Transportinfrastruktur und angesichts sinkender Kraftstoffsteuererträge ist das weltweite Interesse an Straßennutzungsgebührenprogrammen erheblich gewachsen. Somit kann es wünschenswert sein, verbesserte Fähigkeiten zum Bestimmen der Nutzung der Infrastruktur bereitzustellen.
Das gleiche Entgelt fällt möglicherweise nicht für die gesamte Straßeninfrastruktur an. Daher kann es für das Fahrzeug nützlich sein, kombinierte Standort- und Entgeltinformationen zu erhalten, um eine RUC ordnungsgemäß zu berechnen. Diese Standort- und Entgeltinformationen können einen große Bereich an Genauigkeit aufweisen. Behörden oder Gebührenstellen können relativ grobe Standortinformationen bereitstellen, für die ein gewisses Entgelt anfällt; es ist jedoch unwahrscheinlich, dass die Behörden Entgeltinformationen für sämtliche Straßen bereitstellen. Stattdessen besteht ein Ansatz darin, Geopolygone zu verwenden, die einen konkreten Entgeltplan definieren. Zusätzlich zu Polygonen oder Bereichen können Korridore spezifiziert werden, da Gebührenstellen den Wunsch geäußert haben, für spezifische Straßen separate Preise zu verwenden.
Während Gebührengeometrien möglicherweise nicht die feinste geografische Detailstufe aufweisen, kann die Unterteilung einer Drittpartei dennoch Möglichkeiten bieten, Fahrtmuster von einzelnen Benutzern abzuleiten. Außerdem können Gebührenstellen Informationen in Bezug darauf benötigen, welche Entfernung an jeder Preisgeometrie (z. B. Gebührenzuständigkeitsbereich) zurückgelegt wurde, um der Geometrie die korrekten Mittel zuzuordnen.
Aspekte der Offenbarung betreffen das Durchführen von Tests, um zu identifizieren, ob die RUC-Systeme ordnungsgemäß funktionieren. Diese Ansätze können sowohl eine kontrollierte Umgebung, in der das Fahrzeug zu einer Zertifizierungseinrichtung gebracht wird, als auch das Durchführen eines Selbsttests vor Ort durch das Fahrzeug beinhalten. Weitere Details über die Ansätze werden in dieser Schrift detailliert erörtert.
1 veranschaulicht eine beispielhafte Referenzarchitektur eines kompletten RUC-Systems 100. Der Darstellung nach beinhaltet das System 100 eine RUC-Anwendung 102 in Kommunikation mit einem RUC-Dienstanbieter 104. Der RUC-Dienstanbieter 104 steht wiederum in Kommunikation mit einer oder mehreren RUC-Gebührenstellen 106. Obwohl nicht gezeigt, ist anzumerken, dass mehrere RUC-Dienstanbieter 104 vorhanden sein können, wobei sich in diesem Fall unterschiedliche RUC-Anwendungen 102 mit unterschiedlichen RUC-Dienstanbietern 104 verbinden können. Die RUC-Gebührenstellen 106 können dazu konfiguriert sein, dem RUC-Dienstanbieter 104 Karten- und Entgeltinformationen 108 bereitzustellen. Der RUC-Dienstanbieter 104 kann die Karten- und Entgeltinformationen 108 von einer oder mehreren der RUC-Gebührenstellen 106 empfangen, um sie an die RUC-Anwendung 102 weiterzuleiten. Die RUC-Anwendung 102 kann dem RUC-Dienstanbieter 104 RUC-Berichte 110 bereitstellen, die wiederum der RUC-Dienstanbieter 104 an die geeignete(n) RUC-Gebührenstelle(n) 106 weiterleiten kann. In einigen Beispielen kann der von dem RUC-Dienstanbieter 104 weitergeleitete RUC-Bericht 110 eine komprimierte Version des Berichts sein, der von der RUC-Anwendung 102 an den RUC-Dienstanbieter 104 gesendet wurde.
Die Karten- und Entgeltinformationen 108 können Informationen beinhalten, welche die fälligen Gebühren pro Gebührenbereich und/oder Gebührendomäne beschreiben, die ein Fahrzeug durchqueren kann. Dies kann in einem Beispiel Datentabellen, welche die Straßengeometrie der Domänen beschreiben, und Entgelttabellen für die Durchquerung der angegebenen Bereiche beinhalten. Die Karten- und Entgeltinformationen 108 können ferner Informationen in Bezug darauf beinhalten, für welche Fahrbahnen eine Gebühr für die Durchquerung anfällt und für welche nicht. Die Karten- und Entgeltinformationen 108 können ferner Informationen in Bezug darauf beinhalten, welche Straßen Privatstraßen sind, welche unbefestigte Straßen sind sowie für welche im Vergleich zu anderen Fahrbahnen eine andere oder gar keine Gebühr anfallen kann. Die Karten- und Entgeltinformationen 108 können zudem angeben, welche Straßen/Fahrstreifen von der RUC ausgenommen sind und welche Bereiche Geländestandorte sind, die möglicherweise nicht in Messungen der zurückgelegten Entfernung beinhaltet sind. Dementsprechend können die Karten- und Entgeltinformationen 108 es der RUC-Anwendung 102 ermöglichen, eine für das Fahrzeug fällige Gesamtgebühr zu berechnen. Die RUC-Anwendung 102 kann den RUC-Bericht 110 periodisch oder ausgelöst durch ein Ereignis an den RUC-Dienstanbieter 104 senden.
Der RUC-Bericht 110 kann Informationen beinhalten, die es ermöglichen, für das Fahrzeug Gebühren zu verlangen. Dies kann zum Beispiel eine Kontokennung beinhalten, die mit dem fälligen Betrag für den durch den RUC-Bericht 110 detailliert beschriebenen Berichtszeitraum belastet wird. Die Kontokennung kann zum Beispiel ein Konto des Insassen, der dem Fahrzeug entspricht, und/oder ein Konto eines Insassen des Fahrzeugs identifizieren. Der RUC-Bericht 110 kann zudem andere Informationen beinhalten, wie etwa eine zurückgelegte Gesamtentfernung und/oder eine pro Gebührenstellendomäne zurückgelegte Entfernung. Auf Grundlage des RUC-Berichts 110 kann der RUC-Dienstanbieter 104 das Fahrzeug abrechnen und den verschiedenen RUC-Gebührenstellen 106 Mittel bereitstellen, die den in jeder Gebührendomäne anfallenden Entgelten entsprechen.
2 veranschaulicht eine beispielhafte RUC-Architektur 200 zum Durchführen einer Validierung mit der RUC-Anwendung 102, die als ein Fahrzeugteil 202 der RUC-Anwendung und ein Cloud-Teil 204 der RUC-Anwendung umgesetzt ist. Der Fahrzeugteil 202 der RUC-Anwendung kann durch die Steuerungen eines Fahrzeugs 206 ausgeführt werden. Der Cloud-Teil 204 der RUC-Anwendung kann durch einen oder mehrere Server oder andere Rechenvorrichtungen einer sicheren Anwendungs-Cloud 208 ausgeführt werden.
Bei dem Fahrzeug 206 kann es sich um ein beliebiges verschiedener Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländewagen (sport utility vehicle - SUV), Trucks, Wohnmobilen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern handeln. Derartige Fahrzeuge 206 können von Menschen gefahren werden oder autonom sein. In vielen Fällen kann das Fahrzeug 206 durch eine Brennkraftmaschine mit Leistung versorgt werden. Als eine andere Möglichkeit kann das Fahrzeug 206 ein Batterieelektrofahrzeug (battery electric vehicle - BEV) sein, das durch einen oder mehrere Elektromotoren mit Leistung versorgt wird. Als eine weitere Möglichkeit kann das Fahrzeug 206 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch eine Brennkraftmaschine als auch einen oder mehrere Elektromotoren mit Leistung versorgt wird. Da die Art und Konfiguration des Fahrzeugs 206 variieren können, können die Fähigkeiten des Fahrzeugs 206 entsprechend variieren. Als einige andere Möglichkeiten können die Fahrzeuge 206 unterschiedliche Fähigkeiten in Bezug auf Fahrgastkapazität, Zugfähigkeit und -kapazität und Lagervolumen aufweisen. Zu Registrierungszwecken, Inventarzwecken und anderen Zwecken können die Fahrzeuge 206 mit eindeutigen Kennungen assoziiert sein, wie etwa Fahrzeugidentifikationsnummern (FINs).
Das Fahrzeug 206 kann eine Vielzahl von Steuerungen (nicht gezeigt) beinhalten, die dazu konfiguriert sind, verschiedene Funktionen des Fahrzeugs 206 mit der Leistung der Batterie und/oder Kraftübertragung des Fahrzeugs durchzuführen und zu verwalten. Ein oder mehrere Datenbusse können verschiedene Kommunikationsverfahren beinhalten, die zwischen den Steuerungen sowie zwischen einer Telematiksteuereinheit (telematics control unit - TCU) 210 und den Steuerungen zur Verfügung stehen. Unter Verwendung der Steuerungen kann die TCU 210 in der Lage sein, verschiedene Informationen zu überwachen, wie etwa den aktuellen Standort des Fahrzeugs 206 (z. B. über ein globales Navigationssatellitensystem (GNSS)), die durch das Fahrzeug 206 zurückgelegte Entfernung, die Straße und/oder den Fahrstreifen, die/der von dem Fahrzeug 206 durchquert wird, den Fortschritt entlang einer Route, die durch das Fahrzeug 206 durchquert wird, usw.
Die TCU 210 kann Netzwerk-Hardware beinhalten, die dazu konfiguriert ist, die Kommunikation zwischen den Steuerungen des Fahrzeugs 206 und mit anderen Vorrichtungen des Systems 100 zu erleichtern. Die TCU 210 kann zum Beispiel ein Modem, das dazu konfiguriert ist, die Kommunikation über die sichere Anwendungs-Cloud 208 und/oder ein Weitverkehrsnetz 212, wie etwa das Internet, zu erleichtern, beinhalten oder anderweitig darauf zugreifen. Die TCU 210 kann dementsprechend dazu konfiguriert sein, über verschiedene Protokolle zu kommunizieren, wie etwa ein Netzprotokoll (wie etwa Uu oder eine Mobilfunknetzschnittstelle). Die TCU 210 kann zusätzlich dazu konfiguriert sein, über ein Peer-to-Peer-Übertragungsprotokoll (wie etwa PC5) zu kommunizieren, um Mobilfunk-Fahrzeug-zu-Allem-Kommunikation (cellular vehicle-to-everything communications - C-V2X-Kommunikation) mit Vorrichtungen, wie etwa anderen Fahrzeugen 206 oder straßenseitigen Einheiten (nicht gezeigt), zu erleichtern. Es ist anzumerken, dass diese Protokolle lediglich Beispiele sind und andere Peer-to-Peer- und/oder Mobilfunktechnologien verwendet werden können.
Die sichere Anwendungs-Cloud 208 kann verschiedene private Rechenressourcen beinhalten, die dazu konfiguriert sind, dem Fahrzeug 206 Dienste bereitzustellen. In einem Beispiel kann das Fahrzeug 206 die TCU 210 nutzen, um sich mit einem Netzzugriffspunktnamen (access point name - APN) für Fahrzeuganwendungen zu verbinden, die Remote-Rechenunterstützung nutzen. Die sichere Anwendungs-Cloud 208 kann sich über ein Gateway mit dem Weitverkehrsnetz 212 verbinden, wodurch Zugriff auf andere Vorrichtungen in dem Weitverkehrsnetz 212, wie etwa den RUC-Dienstanbieter 104, bereitgestellt wird.
In 2 ist die Schnittstelle zwischen der RUC-Anwendung 102 und dem RUC-Dienstanbieter 104 sowohl an dem Fahrzeug 206 als auch der sicheren Anwendungs-Cloud 208 umgesetzt. Gemeinsam können der Fahrzeugteil 202 der RUC-Anwendung und der Cloud-Teil 204 der RUC-Anwendung die Vorgänge der RUC-Anwendung 102 durchführen. Dies kann das Empfangen der Karten- und Entgeltinformationen 108 von dem RUC-Dienstanbieter 104 und das Senden der RUC-Berichte 110 oder anderer Informationen in Bezug auf die Fahrbahnnutzung des Fahrzeugs an den RUC-Dienstanbieter 104 beinhalten.
3 veranschaulicht eine alternative beispielhafte RUC-Architektur 300 zum Durchführen einer Validierung mit der RUC-Anwendung 102, die als eine fahrzeugumgesetzte RUC-Anwendung 302 umgesetzt ist. Ähnlich wie der Fahrzeugteil 202 der RUC-Anwendung kann die fahrzeugumgesetzte RUC-Anwendung 302 durch die Steuerungen des Fahrzeugs 206 ausgeführt werden. In der in 3 gezeigten alternativen Architektur ist die Schnittstelle zwischen der RUC-Anwendung 102 und dem RUC-Dienstanbieter 104 an dem Fahrzeug 206 allein umgesetzt. Hier kann sich das Fahrzeug 206 mit dem Weitverkehrsnetz 212 verbinden, um auf den RUC-Dienstanbieter 104 zuzugreifen, ohne die Dienste der sicheren Anwendungs-Cloud 208 zu verwenden.
In jeder der RUC-Architekturen 200 und 300 kann die RUC-Anwendung 102, die einem einzelnen Fahrzeug 206 entspricht, über einen Zeitraum die in jeder Gebührendomäne zurückgelegte Gesamtentfernung erfassen. Auf Grundlage der Entgelttabelle, die durch den RUC-Dienstanbieter 104 in den Karten- und Entgeltinformationen 108 bereitgestellt wird, kann die RUC-Anwendung 102 den internen RUC-Bericht 110 berechnen. Zum Beispiel kann der fällige Betrag als die in der Gebührendomäne zurückgelegte Entfernung multipliziert mit dem Entgelt für die Fahrt pro Entfernungseinheit berechnet werden. Oder der fällige Betrag kann als die in der Gebührendomäne verbrachte Zeit multipliziert mit dem Entgelt für die Anwesenheit pro Zeiteinheit berechnet werden. Es ist auch anzumerken, dass die internen RUC-Berichte 110 Privatstraßen, unbefestigte Straßen, von der RUC ausgenommene Straßen/Fahrstreifen, wie auf der Karte markiert, und Geländefahrten von den Messungen der zurückgelegten Entfernung abziehen können, wenn dies durch die Karten- und Entgeltinformationen 108 spezifiziert ist. Ein beispielhafter interner RUC-Bericht 110 ist in Tabelle 1 gezeigt. Tabelle 1 - Interner RUC-Bericht

Benutzerkonto Konto X

Gebührendomäne Fälliger Betrag Zurückgelegte Entfernung

C1 X1 M1

C2 X2 M2

··· ·· ···

Cn Xn Mn
Ein Benutzer mit „Konto X“ kann den internen RUC-Bericht 110 an den RUC-Dienstanbieter 104 senden, der die Informationen aus Tabelle 1 übermittelt. Die in dem internen RUC-Bericht 110 beinhalteten Informationen können jedoch ausreichend beschreibend sein, um dazu verwendet werden zu können, das Fahrtmuster des Benutzers zu dekonstruieren. Zum Beispiel könnte unter Verwendung der Kenntnis der Straßengeometrie der Gebührendomänen sowie der Informationen über die zurückgelegte Entfernung ein am besten passender Fahrtweg rekonstruiert werden.
4 veranschaulicht ein Beispiel 400 für die Verwendung der RUC-Architektur 200, um den Schutz der in dem RUC-Bericht 110 beinhalteten Daten zu erhöhen. In diesem Beispiel 400 kann der Cloud-Teil 204 der RUC-Anwendung als Aggregator von Nachrichten dienen, die von verschiedenen Instanzen des Fahrzeugteils 202 der RUC-Anwendung kommen. Jede Instanz des Fahrzeugteils 202 der RUC-Anwendung kann einen vollständigen internen RUC-Bericht 110 bereitstellen, wie in Tabelle 1 angegeben.
Der interne RUC-Bericht 110 kann Informationen beinhalten, die ausreichend beschreibend sind, um dazu verwendet werden zu können, das Fahrtmuster des Benutzers zu dekonstruieren. Zum Beispiel könnte unter Verwendung der Kenntnis der Straßengeometrie der Gebührendomänen sowie der Informationen über die zurückgelegte Entfernung ein am besten passender Fahrtweg rekonstruiert werden. Dementsprechend kann die RUC-Anwendung 102 stattdessen zwei unterschiedliche Berichte senden, um den Schutz der in dem internen RUC-Bericht 110 beinhalteten Daten zu erhöhen. Diese Berichte können einen Summenbericht 402 und einen aufgeschlüsselten Bericht 404 beinhalten.
Der Summenbericht 402 kann die von jedem Fahrzeug 206 fällige Gesamtsumme angeben. Ein beispielhafter Summenbericht 402, der durch das Fahrzeug 206 erzeugt wird, ist in Tabelle 2 gezeigt. Tabelle 2 - Summenbericht

Benutzerkontokennung X

Fälliger Betrag Σ(X1,X2, ...,Xn)
Der aufgeschlüsselte Bericht 404 kann Beträge angeben, die für jede der RUC-Gebührenstellen 106 durch das Fahrzeug 206 fällig sind. Der aufgeschlüsselte Bericht 404 kann optional zudem die Entfernung bereitstellen, die innerhalb des Bereichs zurückgelegt wurde, der von jeder der RUC-Gebührenstellen 106 für das Fahrzeug 206 bedient wird. Ein beispielhafter aufgeschlüsselter Bericht 404 ist in Tabelle 3 gezeigt. Tabelle 3 - aufgeschlüsselter Bericht

Benutzerkonto Anonym oder X

Gebührendomäne Fälliger Betrag Zurückgelegte Entfernung

C1 X1 M1

C2 X2 M2

··· ··· ···

Cn Xn Mn
Die RUC-Anwendung 102 kann dem RUC-Dienstanbieter 104 den aufgeschlüsselten Bericht 404 entweder mit (i) der Kontokennung (ID) oder (ii) anonymisiert ohne Konto-ID und nur der Signatur bereitstellen, die validiert, dass die Nachricht von einem berechtigten Kontoinhaber stammt, aber ansonsten anonymisiert ist. Wenn sich die RUC-Anwendung 102 dafür entscheidet, den aufgeschlüsselten Bericht 404 mit ihrer eigenen ID bereitzustellen, muss die RUC-Anwendung 102 den Summenbericht 402 nicht zusätzlich senden. Unabhängig davon, ob der aufgeschlüsselte Bericht 404 oder der aufgeschlüsselte Bericht 404 und der Summenbericht 402 gesendet werden, können diese Nachrichten in einem gewissen Rhythmus bereitgestellt werden, der durch Ereignisse bestimmt ist, wie etwa: Zeitüberschreitung (z. B. jeden Tag/jede Woche/jeden Monat), jedes Mal, wenn die Summe von Meilen, die seit dem letzten Bericht zurückgelegt wurden, einen Schwellenwert überschreiten, oder jedes Mal, wenn eine Summe, die seit dem letzten Bericht fällig ist, einen Schwellenwert überschreitet.
5 veranschaulicht ein Beispiel 500 für die Verwendung der RUC-Architektur 300 aus 3, um den Schutz der in dem internen RUC-Bericht 110 beinhalteten Daten zu erhöhen, ohne dass die Verwendung des Cloud-Teils 204 der RUC-Anwendung oder der sicheren Anwendungs-Cloud 208 erforderlich ist. Im Gegensatz zu dem Beispiel 400 sendet die fahrzeugumgesetzte RUC-Anwendung 302 in dem Beispiel 500 den Summenbericht 402 und den aufgeschlüsselten Bericht 404 an den RUC-Dienstanbieter 104, ohne die Dienste der sicheren Anwendungs-Cloud 208 als Vermittlungsinstanz zu nutzen.
6 veranschaulicht ein Beispiel 600 für Datenablaufdiagramm der Kommunikation zwischen der RUC-Anwendung 102 und dem RUC-Dienstanbieter 104. In dem Beispiel 600 werden ein Client-Server-Modell und Anwendungstransportprotokolle des Hypertext-Übertragungsprotokolls (hypertext transfer protocol - HTTP) oder des sicheren Hypertext-Übertragungsprotokolls (hypertext transfer protocol secure - HTTPS) genutzt. Diese Nachrichten werden maßgeblich zwischen dem Fahrzeug 206 und einer URI des RUC-Dienstanbieters 104 gesendet.
Dieses Beispiel 600 veranschaulicht sowohl die Übertragung der Karten- und Entgeltinformationen 108 von dem RUC-Dienstanbieter 104 an die RUC-Anwendung 102 als auch die Übertragung von Summenberichten 402 und/oder aufgeschlüsselten Berichten 404 von der RUC-Anwendung 102 an den RUC-Dienstanbieter 104. Die Client-Server-Architektur ist besonders praktisch, da sie es der RUC-Anwendung 102 ermöglicht, den RUC-Dienstanbieter 104 nach Belieben zu kontaktieren, um entweder Informationen anzufordern oder Informationen bereitzustellen.
7 veranschaulicht ein Beispiel 700 für einen Zertifizierungsansatz, bei dem ein Fahrzeug 206 einem Zertifizierungsserver 702 eine Berichterstattung über eine Route 706 durch mehrere Gebührendomänen 704 bereitstellt. Der Darstellung nach beinhaltet die Route 706 Segmente innerhalb einer Gebührendomäne 704A und Segmente innerhalb einer Gebührendomäne 704B. Der Zertifizierungsserver 702 kann die Rolle des Servers des RUC-Dienstanbieters 104 übernehmen und kann dem zwischen der RUC-Anwendung 102 und dem RUC-Dienstanbieter 104 vereinbarten Protokoll folgen. Ein Zweck dieser Validierung besteht darin, zu zertifizieren, dass die RUC-Anwendung 102 ordnungsgemäß funktioniert.
Der Zertifizierungsserver 702 kann ein Server sein, der verwendet wird, um die Summenberichte 402 und/oder die aufgeschlüsselten Berichte 404 für eine definierte Route 706 auf Grundlage von definierten Karten- und Entgeltinformationen 108 zu validieren. In einigen Fällen kann der Zertifizierungsserver 702 eine andere URI als die des RUC-Dienstanbieters 104 aufweisen. Dies kann ermöglichen, dass die Summenberichte 402 und/oder die aufgeschlüsselten Berichte 404 von der RUC-Anwendung 102 einer Testumgebung bereitgestellt werden, anstatt einem Produktions-RUC-Dienstanbieter 104 bereitgestellt zu werden, der Testberichte zum Erheben von Gebühren nutzen kann.
Die Karten- und Entgeltinformationen 108 können Informationen beinhalten, welche die fälligen Gebühren pro Gebührenbereich und/oder Gebührendomäne 704 beschreiben, die das Fahrzeug 206 durchqueren kann. In dem veranschaulichten Beispiel sind zwei derartige Gebührendomänen 704 angegeben - die Gebührendomäne 704A links von der Gebührendomäne 704B.
Die Route 706 kann ein definierter Weg durch die Straßensegmente der Karten- und Entgeltinformationen 108 sein. Der Darstellung nach kann die Route 706 von einem Startstandort 708 zu einem Endstandort 710 spezifiziert sein. In diesem Fall ist die Route 706 eine Hin- und Rückfahrt, dies ist jedoch nur eine Möglichkeit. In einigen Fällen kann eine Überwachung erforderlich sein, um sicherzustellen, dass das zu testende Fahrzeug 206 der Testroute 706 folgt.
Unter Verwendung der Karten- und Entgeltinformationen 108 kann das Fahrzeug 206 die Route 706 durchqueren und den Summenbericht 402 und/oder den aufgeschlüsselten Bericht 404 berechnen. Diese Berichte können an den Zertifizierungsserver 702 gesendet werden. Da die Route 706 und die Karten- und Entgeltinformationen 108 für den Zertifizierungsserver 702 verfügbar sein können, kann der Zertifizierungsserver 702 in der Lage sein, zu verifizieren, ob die RUC-Anwendung 102 den Summenbericht 402 und/oder den aufgeschlüsselten Bericht 404 korrekt berechnet hat.
8 veranschaulicht einen beispielhaften Prozess 800 zum Zertifizieren der RUC-Anwendung 102 in einer Testeinrichtung. In dem Prozess 800 wird verifiziert, ob die RUC-Anwendung 102 in einer Testumgebung ordnungsgemäß funktioniert. Dies kann demonstrieren, dass die RUC-Anwendung 102 für eine vordefinierte Route 706 und die Gebührendomänen 704 mit definierten Karten- und Entgeltinformationen 108 das Gesamtentgelt sowie die Entgelte für jede Domäne korrekt (innerhalb einer definierten Genauigkeit) berichten kann. In einem Beispiel kann der Prozess 800 als Reaktion darauf eingeleitet werden, dass das Fahrzeug 206 an einem Zertifizierungszentrum oder -standort ankommt.
Bei Vorgang 802 tritt das Fahrzeug 206 in den Zertifizierungsmodus ein. In einem Beispiel kann die RUC-Anwendung 102 eine Option beinhalten, um die RUC-Anwendung 102 in den Zertifizierungsmodus zu versetzen. Bei Vorgang 804 empfängt das Fahrzeug 206 die URI des Zertifizierungsservers 702. In einem Beispiel kann die RUC-Anwendung 102 zudem eine Option beinhalten, um die URI des Zertifizierungsservers 702 zu empfangen. Eine beispielhafte HMI zum Versetzen der RUC-Anwendung 102 in den Zertifizierungsmodus ist in 9 gezeigt.
9 veranschaulicht eine beispielhafte HMI 900 für die Konfiguration des Fahrzeugs 206 in einen Zertifizierungsmodus. In einem Beispiel kann die HMI 900 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 angezeigt werden.
Der Darstellung nach beinhaltet die HMI 900 eine Kategorieauflistung 902 eines oder mehrerer Bildschirme von Inhalt, der in einem Hauptbildschirmbereich 906 anzuzeigen ist. Beispielsweise kann die Kategorieauflistung 902 einen Audiobildschirm, von dem aus eine Konfiguration der Audioeinstellungen des Fahrzeugs 206 vorgenommen werden kann, einen Klimasteuerungsbildschirm, von dem aus die Klimasteuerungseinstellungen des Fahrzeugs 206 konfiguriert werden können, einen Telefonbildschirm, von dem aus Anrufdienste genutzt werden können, einen Navigationsbildschirm, von dem aus Karten und Routen durchgeführt werden können, einen Anwendungsbildschirm, von dem aus installierte Anwendungen aufgerufen werden können, und einen Einstellungsbildschirm, von dem aus auf die Hintergrundbeleuchtung oder andere allgemeine Einstellungen zugegriffen werden kann, beinhalten. Die HMI 900 kann zudem einen Bereich 904 für allgemeine Informationen beinhalten, von dem aus Uhrzeit, aktuelle Temperatur und andere Informationen für den Benutzer sichtbar bleiben, und zwar unabhängig von dem/der spezifischen Bildschirm oder Anwendung, der/die in dem Hauptbildschirmbereich 906 aktiv ist.
Der Hauptbildschirmbereich 906 kann eine Übersicht von Inhalten von mehreren der Inhaltskategorien zeigen. In einem Beispiel kann der Hauptbildschirmbereich 906 eine Audioübersicht, die eine reduzierte Version des Inhalts angibt, der angezeigt wird, wenn die Audioeinstellungen ausgewählt werden, und eine Telefonübersicht anzeigen, die eine reduzierte Version des Inhalts angibt, der angezeigt wird, wenn die Telefoneinstellungen ausgewählt werden.
Die HMI 900 kann zum Beispiel als Reaktion auf eine Benutzerauswahl der RUC-Einstellungen von einem Einstellungsbildschirm aus angezeigt werden, der bei Auswahl des Einstellungsbildschirms aus der Kategorieauflistung 902 angezeigt wird. Der Darstellung nach stellt die HMI 900 einen Satz konfigurierbarer Optionen 908 bereit, die im Hauptbildschirmbereich 906 angezeigt werden und von einem Benutzer verwendet werden können, um die Einstellungen der RUC-Funktionalität einzustellen. Die konfigurierbaren Optionen 908 können eine Zertifizierungsmodus-Umschalteinstellung 910, eine Zertifizierungs-URI-Eingabeeinstellung 912 und eine Feldtestmodus-Umschalteinstellung 914 beinhalten.
Die Zertifizierungsmodus-Umschalteinstellung 910 kann es dem Benutzer ermöglichen, zu wählen, ob ein Test der RUC-Anwendung 102 durchzuführen ist. Wenn sie abgewählt ist, kann die RUC-Anwendung 102 dazu konfiguriert sein, mit dem RUC-Dienstanbieter 104 zu kommunizieren. Wenn sie ausgewählt ist, kann die RUC-Anwendung 102 dazu konfiguriert sein, mit dem Zertifizierungsserver 702 zu kommunizieren, dessen URI in die Zertifizierungs-URI-Eingabeeinstellung 912 eingegeben wird. In einigen Beispielen kann es erforderlich sein, dass ein Passwort oder andere Anmeldeinformationen in die HMI 900 eingegeben wird/werden, um zu ermöglichen, dass die Zertifizierungsmodus-Umschalteinstellung 910 auf den Zertifizierungsmodus eingestellt wird. In einigen Beispielen kann es erforderlich sein, dass ein Passwort oder andere Anmeldeinformationen in die HMI 900 eingegeben wird/werden, um den Zugriff auf die konfigurierbaren Optionen 908 der HMI 900 im Allgemeinen zu ermöglichen.
Die Feldtestmodus-Umschalteinstellung 914 kann ausgewählt werden, um es dem Benutzer zu ermöglichen, auszuwählen, einen Feldtest durchzuführen. Weitere Aspekte der Feldtestmodus-Umschalteinstellung 914 werden nachstehend in Bezug auf den Prozess 1300 erörtert.
Unter erneuter Bezugnahme auf 8 stellt das Fahrzeug 206 bei Vorgang 806 eine Verbindung mit dem Zertifizierungsserver 702 her. Zum Beispiel, ähnlich wie in 6 gezeigt, kann sich das Fahrzeug 206 unter Verwendung der Zertifizierungs-URI anstelle der URI des RUC-Dienstanbieters 104 mit dem Zertifizierungsserver 702 verbinden.
Bei Vorgang 808 fordert das Fahrzeug 206 Testparameter von dem Zertifizierungsserver 702 an. Diese Testparameter können in einem Beispiel Karten- und Entgeltinformationen 108 beinhalten, die verschiedene Gebührendomänen 704 definieren. Die RUC-Anwendung 102 kann bereits einige Karteninformationen pflegen, z. B. für die Navigation, sodass die zusätzlichen Testinformationen, die durch den RUC-Dienstanbieter 104 bereitgestellt werden, zusätzliche Informationen beinhalten können, die über die bestehende Karte in der RUC-Anwendung 102 gelegt werden können. Zum Beispiel können die Testparameter eine Preisgestaltung für das Durchqueren von Straßensegmenten innerhalb jeder Gebührendomäne 704 beinhalten (z. B. 0,11 $/Meile zwischen 8 und 17 Uhr für die Gebührendomäne 704X). In einem anderen Beispiel können die Testparameter zudem einen Berichterstattungsrhythmus (z. B. alle 30 Minuten) für das Fahrzeug 206 beinhalten, um Aktualisierungen der Fahrt des Fahrzeugs 206 bereitzustellen.
Bei Vorgang 810 empfängt das Fahrzeug 206 die Route 706 für den Test. In einem Beispiel kann der Zertifizierungsserver 702 die Route 706 dem Fahrzeug 206 als einen Weg bereitstellen, für den der Zertifizierungsserver 702 bereits eine erwartete Gebühr berechnet hat. Die Route 706 kann verschiedene zu testende Aspekte beinhalten. Zum Beispiel kann die Route 706 verschiedene Zonen, Teilzonen und/oder Korridore beinhalten, die zu testen sind, um sicherzustellen, dass das Fahrzeug 206 die korrekten Berichte erstellt. In einigen Beispielen kann das Fahrzeug 206 aufgefordert werden, die Durchquerung der Route 706 innerhalb eines vordefinierten Zeitraums abzuschließen.
Bei Vorgang 812 durchquert das Fahrzeug 206 die Route 706. Zum Beispiel kann das Fahrzeug 206 seine Navigationsfunktionalität nutzen, um zum Anfang der Route 706 vorzurücken, der Route 706 zu folgen und die Route 706 abzuschließen. In dem Beispiel eines autonomen Fahrzeugs 206 kann die Routenführung automatisch durch das Fahrzeug 206 durchgeführt werden. In dem Beispiel eines teilautonomen oder angetriebenen Fahrzeugs 206 kann der Benutzer des Fahrzeugs 206 einige oder alle Aspekte des Steuerns des Fahrzeugs 206 durchführen. Das Fahrzeug 206 kann Informationen zur Verwendung beim Durchführen der Berichterstattung nachverfolgen. Zum Beispiel können diese Informationen den internen RUC-Bericht 110, die von dem Fahrzeug 206 durchquerten Straßensegmente sowie andere Informationen, wie etwa die zurückgelegte Entfernung, gemäß den Karten- und Entgeltinformationen 108 anfallende Gebühren usw., beinhalten. Die Benutzerschnittstelle des Fahrzeugs 206 kann zudem verwendet werden, um bei der Durchquerung der Route 706 zu unterstützen.
10 veranschaulicht eine beispielhafte HMI 1000, die einen Alarm 1002 für das Fahrzeug 206 im Zertifizierungsmodus veranschaulicht, um zu dem Startstandort 708 der Route 706 vorzurücken. In einem Beispiel kann die HMI 1000 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 angezeigt werden. Der Darstellung nach beinhaltet der Alarm 1002 einen Titel 1004, der angibt, dass sich der Alarm 1002 auf die RUC-Anwendung 102 bezieht, und eine Nachricht 1006, die angibt, dass der Benutzer zu dem Startstandort 708 vorzurücken hat. Die Nachricht 1006 kann ferner den Startstandort 708 spezifizieren. In einer anderen Möglichkeit kann die Navigationsfunktionalität des Fahrzeugs 206 verwendet werden, um den Startstandort 708 abzubilden und/oder das Fahrzeug 206 zu diesem zu leiten. In einem derartigen Beispiel kann der Alarm 1002 stattdessen die Form einer automatischen Navigation zu dem Startstandort 708 annehmen. Der Alarm 1002 kann ferner ein Steuerelement 1008 beinhalten, die, wenn es durch den Benutzer ausgewählt wird, veranlasst, dass der Alarm 1002 verworfen wird. Der Alarm 1002 kann zudem automatisch verworfen werden, wenn der Benutzer den Startstandort 708 erreicht.
11 veranschaulicht eine beispielhafte HMI 1100, die den Alarm 1002 für das Fahrzeug 206 im Zertifizierungsmodus veranschaulicht, um zu dem Endstandort 710 der Route 706 vorzurücken. Wie die HMI 1000 kann die HMI 1000 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 angezeigt werden. Im Vergleich zu der beispielhaften HMI 1000 kann hier die Nachricht 1006 eine Fahrt zu dem Endstandort 710 spezifizieren oder anderweitig leiten.
12 veranschaulicht eine beispielhafte HMI 1200, die den Alarm 1002 für das Fahrzeug 206 im Zertifizierungsmodus veranschaulicht, der den Abschluss der Route 706 zeigt. Wie die HMI 1000 kann die HMI 1000 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 angezeigt werden. Im Vergleich zu den beispielhaften HMIs 1000 und 1100 gibt hier die Nachricht 1006 dem Benutzer an, dass die Route 706 abgeschlossen ist, und die RUC-Anwendung 102 kann die Ergebnisse dementsprechend an den Zertifizierungsserver 702 berichten.
Unter erneuter Bezugnahme auf 8 berechnet das Fahrzeug 206 bei Vorgang 814 die Berichte. Dies kann den Summenbericht 402 und/oder den aufgeschlüsselten Bericht 404 beinhalten, wie vorstehend detailliert erörtert. Bei Vorgang 816 sendet das Fahrzeug 206 die Berichte an den Zertifizierungsserver 702. Zum Beispiel kann die RUC-Anwendung 102 den Summenbericht 402 und/oder den aufgeschlüsselten Bericht 404 gemäß dem in den empfangenen Testparametern spezifizierten Rhythmus an den Zertifizierungsserver 702 senden. Der Zertifizierungsserver 702 kann die Berichte empfangen und kann die beinhalteten Informationen als mit dem erwarteten Mautbetrag übereinstimmend validieren. Der Zertifizierungsserver 702 kann zudem validieren, dass die Berichte mit dem spezifizierten Rhythmus empfangen werden. Nach Vorgang 814 endet das Verfahren 800.
Variationen des Prozesses 800 sind möglich. In einer Variation kann, anstatt die HMI 900 für die Vorgänge 802-804 zu verwenden, die Schnittstelle zwischen dem Zertifizierungsserver 702 und dem Cloud-Teil 204 der RUC-Anwendung (im Hinblick auf die Architektur aus 2) genutzt werden, um den Zertifizierungsmodus für ein konkretes Fahrzeug 206 (z. B. das Fahrzeug 206, das durch die FIN oder eine andere Kennung des Fahrzeugs 206 spezifiziert ist) anzufordern. Zusätzlich kann der Cloud-Teil 204 der RUC-Anwendung ebenfalls die URI an den Cloud-Teil 204 der RUC-Anwendung zusammen mit einer beliebigen Kennung des zu konfigurierenden Fahrzeugs 206 bereitstellen. Zum Beispiel kann der Cloud-Teil 204 der RUC-Anwendung das Fahrzeug 206 anweisen, in den Zertifizierungsmodus mit einer bestimmten URI einzutreten. Diese Schnittstelle kann durch verschiedene Ansätze erreicht werden, zum Beispiel durch einen Publish/Subscribe-Mechanismus, bei dem der RUC-Dienstanbieter 104 (oder der Zertifizierungsserver 702) einen neuen Zustand für das Fahrzeug 206 veröffentlicht oder das Fahrzeug 206 auffordert, den Cloud-Teil 204 der RUC-Anwendung zu kontaktieren, um die Testparameter abzurufen.
13 veranschaulicht einen beispielhaften Prozess 1300 zum Testen der RUC-Anwendung 102 durch eine Drittpartei in einem Feldtestmodus. In einem Beispiel kann der Prozess 1300 wie der Prozess 800 durch das Fahrzeug 206 im Kontext des Systems 100 durchgeführt werden. Im Vergleich zu dem Prozess 800 wird jedoch in dem Prozess 1300 der Zertifizierungsserver 702 nicht genutzt. Stattdessen kann das Fahrzeug 206 in Kommunikation mit dem RUC-Dienstanbieter 104 bleiben.
Bei Vorgang 1302 empfängt das Fahrzeug 206 eine Angabe für einen Selbsttest. In einem Beispiel kann das Fahrzeug 206 eine Option in dem Navigationssystem beinhalten, um es einem Benutzer zu ermöglichen, den Selbsttest einzuleiten.
14 veranschaulicht eine beispielhafte HMI 1400, die ein Selbsttest-beginnen-Steuerelement 1402 zum Einleiten eines Tests im Feldtestmodus beinhaltet. In einem Beispiel kann die HMI 1400 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 angezeigt werden. Der Darstellung nach gibt das Selbsttest-beginnen-Steuerelement 1402 an, dass es gedrückt werden kann, um es einem Benutzer, wie etwa einem Drittparteiprüfer, zu ermöglichen, in ein beliebiges Fahrzeug 206 einzusteigen, das Selbsttest-beginnen-Steuerelement 1402 und entlang einer vordefinierten Route 706 zu fahren. Das Selbsttest-beginnen-Steuerelement 1402 kann durch den Benutzer gedrückt werden, wenn das Fahrzeug 206 stationär ist oder, in anderen Beispielen, während das Fahrzeug 206 in Bewegung ist.
Wenngleich dies nicht gezeigt ist, kann es erforderlich sein, ein Passwort oder eine andere Authentifizierung durchzuführen, um es dem Benutzer zu ermöglichen, einen Selbsttest zu beginnen. Als eine Möglichkeit kann das Selbsttest-beginnen-Steuerelement 1402 nur in der Navigationsansicht gezeigt werden, nachdem sich der Benutzer als zum Durchführen von Selbsttests autorisiert authentifiziert hat. In einer anderen Möglichkeit kann das Selbsttest-beginnen-Steuerelement 1402 unabhängig zur Verfügung gestellt werden, um es dem Benutzer zu ermöglichen, den ordnungsgemäßen Betrieb der RUC-Anwendung 102 zu bestätigen.
Bei Vorgang 1308 beginnt das Fahrzeug 206 mit der Berichterstattung für den Selbsttest. Zum Beispiel kann das Fahrzeug 206 Informationen für die Erzeugung eines internen RUC-Berichts 110 nachverfolgen, wie etwa die von dem Fahrzeug 206 durchquerten Straßensegmente sowie andere Informationen, wie etwa die zurückgelegte Entfernung, gemäß den Karten- und Entgeltinformationen 108 anfallende Gebühren usw.
Diese Informationen für den Selbsttest können maßgeblich durch das Fahrzeug 206 unabhängig von einer beliebigen Nachverfolgung, die bei der Durchführung regulärer RUC-Dienste durchgeführt wird, nachverfolgt werden. Stattdessen kann die Nachverfolgung für den Selbsttest eine parallele Handlung sein, die stattfindet.
Bei Vorgang 1310 hat das Fahrzeug 206 die Berichterstattung für den Selbsttest abgeschlossen. In einem Beispiel kann das Fahrzeug 206 eine Option in dem Navigationssystem beinhalten, um es einem Benutzer zu ermöglichen, den Selbsttest abzuschließen.
15 veranschaulicht eine beispielhafte HMI 1500, die ein Selbsttest-beenden-Steuerelement 1502 zum Abschließen eines Tests im Feldtestmodus beinhaltet. In einem Beispiel kann die HMI 1500 auf einer Kopfeinheit oder einem anderen Bildschirm des Fahrzeugs 206 während des Selbsttests angezeigt werden. Wie gezeigt, gibt das Selbsttest-beenden-Steuerelement 1502 an, dass es gedrückt werden kann, um es dem Benutzer zu ermöglichen, den Selbsttest abzuschließen. Das Selbsttest-beenden-Steuerelement 1502 kann durch den Benutzer gedrückt werden, wenn das Fahrzeug 206 stationär ist oder, in anderen Beispielen, während das Fahrzeug 206 in Bewegung ist.
Bei Vorgang 1312 speichert das Fahrzeug 206 die Selbsttestberichte zur Überprüfung. Diese Selbsttestberichte können in einem Arbeitsspeicher oder Datenspeicher des Fahrzeugs 206 aufbewahrt werden und können durch das Fahrzeug 206 verifiziert oder zur Verifizierung auf ein anderes System ausgelagert werden. In einem anderen Beispiel können die Selbsttestberichte auf der HMI des Fahrzeugs 206 angezeigt werden, um es dem Benutzer zu ermöglichen, den Selbsttestbericht von dem Fahrzeug 206 selbst aus visuell zu überprüfen.
Zum Beispiel kann der Selbsttestbericht als ein aufgeschlüsselter Bericht 404 gezeigt werden, der dem in Tabelle 3 ähnelt. Der Selbsttestbericht wird maßgeblich nicht an den RUC-Dienstanbieter 104 gesendet. Nach Vorgang 1312 endet der Prozess 1300.
Andere Variationen der Prozesse 800 und 1300 sind möglich. Zusätzlich zu den vorstehend beschriebenen Ansätzen kann die RUC-Anwendung 102 auf andere Weise getestet werden. Zum Beispiel kann eine Partei, die fordert, dass die RUC-Anwendung 102 getestet wird, gegenüber dem Fahrzeug 206 eine URI veröffentlichen, um einen aufgeschlüsselten Bericht 404 für eine hypothetische Fahrt anzufordern. Oder die Partei kann direkt anfordern, dass der Test über die HMI des Fahrzeugs 206 durchgeführt wird. Die RUC-Anwendung 102 kann in einem Offline-Modus die Durchquerung der Route 706 simulieren, indem sie die auf einer bestimmten Fahrt zurückgelegten Meilen berechnet und die Preisinformationen anwendet, die durch die Karten- und Entgeltinformationen 108 spezifiziert werden, die von dem RUC-Dienstanbieter 104 empfangen wurden. Eine derartige Simulation kann das Simulieren sowohl der durchquerten Route als auch des Preisschemas beinhalten, um die Entgelte zu bestimmen. Dieser Bericht kann an dem Fahrzeug erstellt oder an einen bestimmten Klienten gesendet werden, der ihn anfordert. Ein derartiger Test kann dementsprechend verwendet werden, um die Steuerauswirkungen einer konkreten Fahrt zu verstehen, und kann mit keiner konkreten Konto-ID assoziiert sein.
In noch einer anderen Variation kann eine andere Ausführungsform der Validierung das Nutzen bestehender Mautportale auf einer durchquerten Route beinhalten, um für die RUC-Anwendung 102 zu validieren, dass das Fahrzeug 206 diese tatsächlich passiert hat. Der Betreiber des Mautportals kann beliebige Übertritte des Fahrzeugs 206 mit den RUC-Gebührenstellen 106 abgleichen, wenn beide Entitäten (d. h. Mautgebührenstelle und RUC-Gebührenstelle 106) wechselseitig oder teilweise unabhängig sind.
16 veranschaulicht ein Beispiel 1600 für eine Rechenvorrichtung 1602 zur Verwendung bei der Validierung von RUC-Systemen. Unter Bezugnahme auf 16 und unter Bezugnahme auf die 1-13 können der RUC-Dienstanbieter 104, die RUC-Gebührenstelle 106, das Fahrzeug 206, die sichere Anwendungs-Cloud 208, die TCU 210, das Weitverkehrsnetz 212 usw. Beispiele für derartige Rechenvorrichtungen 1602 beinhalten. Der Darstellung nach kann die Rechenvorrichtung 1602 einen Prozessor 1604 beinhalten, der mit einem Datenspeicher 1606, einer Netzvorrichtung 1608, einer Ausgabevorrichtung 1610 und einer Eingabevorrichtung 1612 wirkverbunden ist. Es ist anzumerken, dass dies lediglich ein Beispiel ist und Rechenvorrichtungen 1602 mit mehr, weniger oder unterschiedlichen Komponenten verwendet werden können.
Der Prozessor 1604 kann eine oder mehrere integrierte Schaltungen beinhalten, welche die Funktionalität einer zentralen Verarbeitungseinheit (central processing unit - CPU) und/oder Grafikverarbeitungseinheit (graphics processing unit - GPU) umsetzen. In einigen Beispielen sind die Prozessoren 1604 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 etwa den Datenspeicher 1606 und die Netzvorrichtung 1608, in einer einzelnen integrierten Vorrichtung beinhalten. In anderen Beispielen sind die CPU und die GPU über eine Peripherieverbindungsvorrichtung, wie etwa Peripheral Component Interconnect (PCI) Express oder eine andere geeignete Peripheriedatenverbindung, 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 1604 während des Betriebs gespeicherte Programmanweisungen aus, die aus dem Datenspeicher 1606 abgerufen werden. Die gespeicherten Programmanweisungen beinhalten entsprechend Software, die den Betrieb der Prozessoren 1604 steuert, um die in dieser Schrift beschriebenen Vorgänge durchzuführen. Der Datenspeicher 1606 kann sowohl nicht flüchtige als auch flüchtige Arbeitsspeichervorrichtungen beinhalten. Der nichtflüchtige Arbeitsspeicher beinhaltet Folgendes: Festkörperspeicher, wie etwa Not-And(NAND)-Flash-Speicher, magnetische und optische Datenspeichermedien oder eine beliebige andere geeignete Datenspeichervorrichtung, die Daten speichert, wenn das System abgeschaltet wird oder dessen Stromversorgung unterbrochen ist. Der flüchtige Arbeitsspeicher beinhaltet einen statischen und dynamischen Direktzugriffsspeicher (random-access memory - RAM), auf dem während des Betriebs des Systems 100 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 1610 beinhalten. Die Ausgabevorrichtung 1610 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 anderes Beispiel kann die Ausgabevorrichtung 1610 eine Audiovorrichtung, wie etwa einen Lautsprecher oder einen Kopfhörer, beinhalten. Als noch ein weiteres Beispiel kann die Ausgabevorrichtung 1610 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 1612 kann eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der Rechenvorrichtung 1602 ermöglichen, Steuereingaben von Benutzern zu empfangen. Beispiele für geeignete Eingabevorrichtungen, die Eingaben über eine menschliche Schnittstelle empfangen, können Tastaturen, Mäuse, Trackballs, Touchscreens, Spracheingabevorrichtungen, Grafiktablets und dergleichen beinhalten.
Die Netzvorrichtungen 1608 können jeweils eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der TCU 210, der sicheren Anwendungs-Cloud 208, dem RUC-Dienstanbieter 104 und der RUC-Gebührenstelle 106 ermöglichen, Daten von externen Vorrichtungen über Netze (wie etwa das Weitverkehrsnetz 212) zu senden und/oder zu empfangen. Beispiele für geeignete Netzvorrichtungen 1608 beinhalten eine Ethernet-Schnittstelle, einen Wi-Fi-Sendeempfänger, einen Mobilfunk-Sendeempfänger, einen Satelliten-Sendeempfänger, einen Fahrzeug-zu-Allem-Sendeempfänger (V2X-Sendeempfänger, vehicle-to-everything - V2X), einen BLUETOOTH- oder BLUETOOTH-Low-Energy(BLE)-Sendeempfänger oder einen anderen Netzadapter oder eine andere Peripherie-Verbindungsvorrichtung, der/die Daten von einem anderen Computer oder einer externen Datenspeichervorrichtung empfängt, was zum Empfangen großer Datensätze auf effiziente Weise nützlich sein kann.
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen beschreiben, die durch die Patentansprüche eingeschlossen werden. 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 Validierung von Straßennutzungsgebühren(RUC)-Systemen bereitgestellt, das Folgendes aufweist: eine Mensch-Maschine-Schnittstelle (HMI); und einen Hardware-Prozessor, der zu Folgendem programmiert ist: Empfangen einer Eingabe von der HMI, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist, im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test, und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
Gemäß einer Ausführungsform ist der Testmodus ein Zertifizierungsmodus und beinhaltet die Eingabe, um in den Zertifizierungsmodus einzutreten, eine Spezifikation einer einheitlichen Ressourcenkennung (URI) eines Zertifizierungsservers und ist der Hardware-Prozessor dazu programmiert, im Zertifizierungsmodus den einen oder die mehreren Berichte zur Validierung an die URI des Zertifizierungsservers zu senden, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden.
Gemäß einer Ausführungsform werden die Karten- und Entgeltinformationen für den Test von dem Zertifizierungsserver an dem Fahrzeug empfangen.
Gemäß einer Ausführungsform werden der eine oder die mehreren Berichte dem Zertifizierungsserver gemäß einem durch den Zertifizierungsserver spezifizierten Rhythmus bereitgestellt.
Gemäß einer Ausführungsform ist der Testmodus ein Feldtestmodus, ist die Eingabe, um in den Feldtestmodus einzutreten, ein Empfangen eines Drückens eines Selbsttest-beginnen-Steuerelements, beinhaltet eine zweite Eingabe, um den Feldtestmodus abzuschließen, ein Empfangen eines Drückens eines Selbsttest-beenden-Steuerelements und ist der Hardware-Prozessor dazu programmiert, es im Feldtestmodus zu unterlassen, den einen oder die mehreren Berichte, die sich aus dem Test der RUC-Funktionalität ergeben, an einen RUC-Dienstanbieter zu senden.
Gemäß einer Ausführungsform ist der Hardware-Prozessor im Feldtestmodus dazu konfiguriert, gleichzeitiges Durchführen der RUC-Berichterstattung über die Fahrzeugstraßennutzung an den RUC-Dienstanbieter fortzusetzen.
Gemäß einer Ausführungsform ist der Hardware-Prozessor ferner zu einem oder mehreren von Folgenden programmiert: Führen, an dem Fahrzeug, eines Selbsttestberichts, der Beträge angibt, die für das Durchqueren von Straßensegmenten während des Feldtestmodus durch das Fahrzeug fällig sind, anstatt dem RUC-Dienstanbieter bereitgestellt zu werden; oder Anzeigen des Selbsttestberichts auf der HMI des Fahrzeugs.
Gemäß einer Ausführungsform wird die Route durch die HMI empfangen.
Gemäß einer Ausführungsform durchquert die Route eine Vielzahl von Gebührendomänen und beinhalten der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind.
Gemäß einer Ausführungsform ist der Hardware-Prozessor ferner dazu programmiert, die HMI zu nutzen, um das Fahrzeug zu dem Startstandort der Route zu leiten, um den Test zu beginnen, und die HMI ferner zu nutzen, um das Fahrzeug zu dem Endstandort der Route zu leiten, um den Test abzuschließen.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren zum Durchführen einer Validierung von Straßennutzungsgebühren(RUC)-Systemen Folgendes: Empfangen, an einem Hardware-Prozessor eines Fahrzeugs, von einer HMI des Fahrzeugs, einer Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist; im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test; und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
In einem Aspekt der Erfindung ist der Testmodus ein Zertifizierungsmodus und beinhaltet die Eingabe, um in den Zertifizierungsmodus einzutreten, eine Spezifikation einer einheitlichen Ressourcenkennung (URI) eines Zertifizierungsservers und ferner umfassend, im Zertifizierungsmodus, Senden des einen oder der mehreren Berichte zur Validierung an die URI des Zertifizierungsservers, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden.
In einem Aspekt der Erfindung werden die Karten- und Entgeltinformationen für den Test von dem Zertifizierungsserver an dem Fahrzeug empfangen.
In einem Aspekt der Erfindung werden der eine oder die mehreren Berichte dem Zertifizierungsserver gemäß einem durch den Zertifizierungsserver spezifizierten Rhythmus bereitgestellt.
In einem Aspekt der Erfindung ist der Testmodus ein Feldtestmodus, ist die Eingabe, um in den Feldtestmodus einzutreten, ein Empfangen eines Drückens eines Selbsttest-beginnen-Steuerelements, beinhaltet eine zweite Eingabe, um den Feldtestmodus abzuschließen, ein Empfangen eines Drückens eines Selbsttest-beenden-Steuerelements und ferner umfassend: im Feldtestmodus, Unterlassen des Sendens des einen oder der mehreren Berichte, die sich aus dem Test der RUC-Funktionalität ergeben, an den RUC-Dienstanbieter.
In einem Aspekt der Erfindung, im Feldtestmodus, ferner umfassend Fortsetzen von gleichzeitigem Durchführen der RUC-Berichterstattung über die Fahrzeugstraßennutzung an den RUC-Dienstanbieter.
In einem Aspekt der Erfindung beinhaltet das Verfahren eines oder mehrere von Folgenden: Führen, an dem Fahrzeug, eines Selbsttestberichts, der Beträge angibt, die für das Durchqueren von Straßensegmenten während des Feldtestmodus durch das Fahrzeug fällig sind, anstatt dem RUC-Dienstanbieter bereitgestellt zu werden; oder Anzeigen des Selbsttestberichts auf der HMI des Fahrzeugs.
In einem Aspekt der Erfindung wird die Route durch die HMI empfangen.
In einem Aspekt der Erfindung durchquert die Route eine Vielzahl von Gebührendomänen und beinhalten der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind.
In einem Aspekt der Erfindung beinhaltet das Verfahren Nutzen der HMI, um das Fahrzeug zu dem Startstandort der Route zu leiten, um den Test zu beginnen, und Nutzen der HMI, um das Fahrzeug zu dem Endstandort der Route zu leiten, um den Test abzuschließen.
Gemäß der vorliegenden Erfindung wird ein nicht transitorisches computerlesbares Medium bereitgestellt, das Anweisungen zum Durchführen einer Validierung von Straßennutzungsgebühren(RUC)-Systemen aufweist, die bei Ausführung durch einen Hardware-Prozessor eines Fahrzeugs das Fahrzeug zum Durchführen von Vorgängen veranlassen, die Folgendes beinhalten: Empfangen, von einer HMI des Fahrzeugs, einer Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist, wobei die Eingabe eine Spezifikation einer einheitlichen Ressourcenkennung (URI) eines Zertifizierungsservers beinhaltet; im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test, wobei die Route eine Vielzahl von Gebührendomänen durchquert; Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind, wobei der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht beinhalten, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind; und Senden des einen oder der mehreren Berichte zur Validierung an die URI des Zertifizierungsservers, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden.

Claims

Fahrzeug zum Durchführen einer Validierung von Straßennutzungsgebühren(RUC)-Systemen, umfassend: eine Mensch-Maschine-Schnittstelle (HMI); und einen Hardware-Prozessor, der zu Folgendem programmiert ist: Empfangen einer Eingabe von der HMI, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist, im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test, und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
Fahrzeug nach Anspruch 1, wobei der Testmodus ein Zertifizierungsmodus ist und die Eingabe, um in den Zertifizierungsmodus einzutreten, eine Spezifikation einer einheitlichen Ressourcenkennung (URI) eines Zertifizierungsservers beinhaltet und der Hardware-Prozessor dazu programmiert ist, im Zertifizierungsmodus den einen oder die mehreren Berichte zur Validierung an die URI des Zertifizierungsservers zu senden, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden.
Fahrzeug nach Anspruch 2, wobei die Karten- und Entgeltinformationen für den Test von dem Zertifizierungsserver an dem Fahrzeug empfangen werden.
Fahrzeug nach Anspruch 2, wobei der eine oder die mehreren Berichte dem Zertifizierungsserver gemäß einem durch den Zertifizierungsserver spezifizierten Rhythmus bereitgestellt werden.
Fahrzeug nach Anspruch 1, wobei der Testmodus ein Feldtestmodus ist, die Eingabe, um in den Feldtestmodus einzutreten, ein Empfangen eines Drückens eines Selbsttest-beginnen-Steuerelements ist, eine zweite Eingabe, um den Feldtestmodus abzuschließen, ein Empfangen eines Drückens eines Selbsttest-beenden-Steuerelements beinhaltet und der Hardware-Prozessor dazu programmiert ist, es im Feldtestmodus zu unterlassen, den einen oder die mehreren Berichte, die sich aus dem Test der RUC-Funktionalität ergeben, an einen RUC-Dienstanbieter zu senden.
Fahrzeug nach Anspruch 5, wobei der Hardware-Prozessor im Feldtestmodus dazu konfiguriert ist, gleichzeitiges Durchführen der RUC-Berichterstattung über die Fahrzeugstraßennutzung an den RUC-Dienstanbieter fortzusetzen.
Fahrzeug nach Anspruch 5, wobei der Hardware-Prozessor ferner zu einem oder mehreren von Folgenden programmiert ist: Führen, an dem Fahrzeug, eines Selbsttestberichts, der Beträge angibt, die für das Durchqueren von Straßensegmenten während des Feldtestmodus durch das Fahrzeug fällig sind, anstatt dem RUC-Dienstanbieter bereitgestellt zu werden; oder Anzeigen des Selbsttestberichts auf der HMI des Fahrzeugs.
Fahrzeug nach Anspruch 1, wobei die Route durch die HMI empfangen wird.
Fahrzeug nach Anspruch 1, wobei die Route eine Vielzahl von Gebührendomänen durchquert und der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht beinhalten, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind.
Fahrzeug nach Anspruch 1, wobei der Hardware-Prozessor ferner dazu programmiert ist, die HMI zu nutzen, um das Fahrzeug zu dem Startstandort der Route zu leiten, um den Test zu beginnen, und die HMI ferner zu nutzen, um das Fahrzeug zu dem Endstandort der Route zu leiten, um den Test abzuschließen.
Verfahren zum Durchführen einer Validierung von Straßennutzungsgebühren(RUC)-Systemen, umfassend: Empfangen, an einem Hardware-Prozessor eines Fahrzeugs, von einer HMI des Fahrzeugs, einer Eingabe, um in einen Testmodus einzutreten, in dem ein Test der RUC-Funktionalität des Fahrzeugs durchzuführen ist; im Testmodus, Berechnen von RUC-Gebühren für eine Route von einem Startstandort zu einem Endstandort auf Grundlage von Karten- und Entgeltinformationen für den Test; und Erzeugen eines oder mehrerer Berichte über die Gebühren zur Verifizierung der RUC-Funktionalität, wobei die Gebühren auf Grundlage der Route und der Karten- und Entgeltinformationen, die für den Test definiert worden sind, verifizierbar sind.
Verfahren nach Anspruch 11, wobei der Testmodus ein Zertifizierungsmodus ist und die Eingabe, um in den Zertifizierungsmodus einzutreten, eine Spezifikation einer einheitlichen Ressourcenkennung (URI) eines Zertifizierungsservers beinhaltet und ferner umfassend, im Zertifizierungsmodus, Senden des einen oder der mehreren Berichte zur Validierung an die URI des Zertifizierungsservers, anstatt den einen oder die mehreren Berichte an einen RUC-Dienstanbieter zu senden, wobei die Karten- und Entgeltinformationen für den Test von dem Zertifizierungsserver an dem Fahrzeug empfangen werden, und wobei der eine oder die mehreren Berichte dem Zertifizierungsserver gemäß einem durch den Zertifizierungsserver spezifizierten Rhythmus bereitgestellt werden.
Verfahren nach Anspruch 12, wobei der Testmodus ein Feldtestmodus ist, die Eingabe, um in den Feldtestmodus einzutreten, ein Empfangen eines Drückens eines Selbsttest-beginnen-Steuerelements ist, eine zweite Eingabe, um den Feldtestmodus abzuschließen, ein Empfangen eines Drückens eines Selbsttest-beenden-Steuerelements beinhaltet und ferner umfassend: im Feldtestmodus, Unterlassen des Sendens des einen oder der mehreren Berichte, die sich aus dem Test der RUC-Funktionalität ergeben, an den RUC-Dienstanbieter; im Feldtestmodus, Fortsetzen von gleichzeitigem Durchführen der RUC-Berichterstattung über die Fahrzeugstraßennutzung an den RUC-Dienstanbieter; und eines oder mehrere von Folgenden: Führen, an dem Fahrzeug, eines Selbsttestberichts, der Beträge angibt, die für das Durchqueren von Straßensegmenten während des Feldtestmodus durch das Fahrzeug fällig sind, anstatt dem RUC-Dienstanbieter bereitgestellt zu werden; oder Anzeigen des Selbsttestberichts auf der HMI des Fahrzeugs.
Verfahren nach Anspruch 11, wobei die Route eine Vielzahl von Gebührendomänen durchquert und der eine oder die mehreren Berichte einen aufgeschlüsselten Bericht beinhalten, wobei der aufgeschlüsselte Bericht Beträge angibt, die für das Durchqueren von Straßensegmenten durch das Fahrzeug innerhalb jeder der Gebührendomänen fällig sind.
Verfahren nach Anspruch 11, ferner umfassend Nutzen der HMI, um das Fahrzeug zu dem Startstandort der Route zu leiten, um den Test zu beginnen, und Nutzen der HMI, um das Fahrzeug zu dem Endstandort der Route zu leiten, um den Test abzuschließen.