DE102017008084A1

DE102017008084A1 - Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen

Info

Publication number: DE102017008084A1
Application number: DE102017008084.4A
Authority: DE
Inventors: Dirk Hassert; Thomas Hartmann; Christian Rupert; Frank-Peter Pesl; Gerd Scheidhauer; Christian Heikamp
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2017-08-25
Filing date: 2017-08-25
Publication date: 2019-02-28
Also published as: US11292485B2; JP7257343B2; WO2019037922A1; EP3673466A1; CN110914876A; JP2020526824A; US20210155256A1; CN110914876B

Abstract

Die Erfindung betrifft ein Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen sowie auszuführender Fahrbefehle, in Form eines Datenformats (9), für ein Fahrzeug (1). Das erfindungsgemäße Verfahren ist dadurch gekennzeichnet, dass mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (2, 5, 6, 7, 8), welche über mehrere Kommunikationsverbindungen das Datenformat (9) austauschen, genutzt werden, wobei eine Vermittlungsstelle (6) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen (2, 5, 6, 7, 8) und in das Fahrzeug übernimmt.

Description

Die Erfindung betrifft ein Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen nach der im Oberbegriff von Anspruch 1 näher definierten Art.
Durch die Erfindung soll die Nutzung von Fahrzeugen flexibler gemacht werden. Hierzu werden insbesondere die Überprüfung und die Vergabe von Zugangsberechtigungen zum Fahrzeug, Fahrberechtigungsvergaben für das Fahrzeug sowie die Vergabe von Fahrbefehlen an das Fahrzeug mit dem erfindungsgemäßen Verfahren ermöglicht und bewirkt. Das Verfahren ist hierbei besonders vorteilhaft bei Fahrzeugen einsetzbar, die teilautonom oder vollständig autonom fahren können. Hier können dann manueller Betrieb des Fahrzeugs und autonomer bzw. teilautonomer Betrieb des Fahrzeugs kombiniert werden.
Die Vergabe von Fahrbefehlen an autonom fahrfähige Fahrzeuge ist beispielsweise aus der DE 10 2014 001 836 A1 bekannt. Hier wird vorgeschlagen über ein zwischen dem Fahrzeug und einer Infrastruktureinheit auszutauschendes Signal Authentifizierungscodes und weitere Kommunikationsinhalte zu übermitteln. Zu den weiteren Kommunikationsinhalten gehört gemäß Absatz 18 dieser Schrift insbesondere ein Fahrauftrag, den der Fahrer im Fahrzeug eingibt, damit das Fahrzeug ein anschließendes Parkmanöver inklusive Zufahrt in ein Parkhaus mit Unterstützung eines Rechenzentrums autonom bzw. teilautonom ausführt. Zugangsberechtigungen zum Fahrzeug und Fahrberechtigungen für das Fahrzeug werden mit dem vorgenannten Verfahren nicht vergeben.
Des Weiteren ist aus der DE 10 2012 012 389 A1 ein Verfahren für das Verteilen von Zugangsberechtigungen zum Fahrzeug und von Fahrberechtigungen für das Fahrzeug bekannt. Hier werden sowohl die Zugangsberechtigungen als auch die Fahrberechtigungen von einem Datenbankserver im sogenannten Vehicle Backend des Fahrzeugherstellers an ein mobiles Endgerät in der Hand des potentiellen Fahrzeugnutzers übertragen. Das mobile Endgerät weist hierbei einen geschützten Speicherbereich auf, in den die Daten übertragen werden. Die Verfügung über den geschützten Speicherbereich kann verschiedenen Nutzergruppen zugeordnet werden, so dass ein mobiles Fahrberechtigungs- und Zugangsberechtigungssystem realisiert werden kann, welche verschiedene Fahrzeugnutzer berücksichtigt. Die Vergabe von Fahrbefehlen und damit die sinnvolle Einbindung von autonomen oder teilautonomen Fahrzeugen ist mit dem vorgenannten Verfahren nicht möglich, da stets der potentielle Fahrer das Fahrzeug Öffnen, Starten und Fahren muss.
Mit der DE 10 2013 201 168 A1 ist ein Fernsteuerungssystem für Kraftfahrzeuge bekannt, bei dem der Fahrer zwischen manuellem Betrieb des Fahrzeug und autonomem bzw. teilautonomem Betrieb des Fahrzeugs wechseln kann. Im autonomen bzw. teilautonomen Betrieb gibt der Fahrer die Kontrolle an eine Fernüberwachung oder an einen Fahragenten ab, die oder der dann das Fahrzeug steuert. Der Fahrzeugnutzer kann hierbei bestimmen welche Personen an der Fernüberwachung beteiligt sein sollen. Umgekehrt kann die Fernüberwachung die Kontrolle über das Fahrzeug übernehmen, wenn der Fahrer erkennbar nicht mehr geeignet ist, das Fahrzeug sicher zu führen. Eine Zentrale vergleichbar einem Vehicle Backend vermittelt die Datenverbindung zwischen einem persönlichen Datenendgerät des Fahrzeugnutzers und dem Fernüberwachungssystems. Zudem vermittelt die Zentrale Angebote für die Durchführung der Fernüberwachung an verschiedene Operatoren. Die notwendigen Software Programme werden von der Zentrale zur Verfügung gestellt. Ebenso sorgt die Zentrale für die Kommunikationsverbindung zwischen vermitteltem Operator, Fahrzeug und persönlichem Datenendgerät des Fahrzeugnutzers. Für diese Fernüberwachungssysteme ist eine permanente und störungsfreie Kommunikationsverbindung zwischen Fahrzeug, Datenendgerät des Fahrzeugnutzers und dem vermittelten Operator für die Fernüberwachung essentiell, wie es in Absatz 26 dieser Schrift ausgeführt ist.
Aus der US 9 494 938 B1 ist ein Verfahren zu Betrieb eines autonom fahrenden Fahrzeugs, eines Robotaxis, bekannt, das zu einem, das Fahrzeug anfragenden, Kunden geführt wird. Erreicht das autonom fahrende Fahrzeug den Kunden wird dem Kunden eine Information angezeigt, entweder am Fahrzeug oder in einem mobilen Datenendgerät des Kunden, die dem Kunden das Fahrzeug als das bestellte Taxi identifiziert. Zu diesem Zweck wird ein einzigartiges Datensignal, ein sogenannter Token, zwischen verschiedenen Datenverarbeitungsanlagen beim Taxibetreiber, bei Kunden und im Fahrzeug ausgetauscht und verteilt. Dieser Token enthält die notwendigen Daten, um das bestellte Taxi eindeutig dem anfragenden Kunden zuzuordnen und diesem bei Eintreffen beim Kunden kenntlich zu machen. Ebenso wird das Signal genutzt, um dem Robotaxi die Authentifizierung des Kunden für den betreffenden Fahrauftrag zu ermöglichen. Dieses Verfahren erfordert keinen Wechsel über die Kontrolle des Fahrzeugs. Das Fahrzeug verbleibt im autonomen Fahrbetrieb auch wenn der Kunde eingestiegen ist. Ein Leitrechner im Fahrzeug behält die ganze Zeit die vollständige Kontrolle über das Fahrzeug und führt das Fahrzeug über einen Positionsabgleich des Fahrzeugs an die erfasste Position des mobilen Endgeräts des Kunden. Die Fahrberechtigung muss daher nicht überprüft werden. Ebenso wenig muss dem Kunden eine Zugangsberechtigung in das Fahrzeug vermittelt werden. Die Token Vergabe kann nur von einem Dispatching System beim Taxibetreiber erfolgen. Eine eigenständige Zertifikatsfreigabe durch den Verfügungsberechtigten über das Fahrzeug ist daher nicht vorhanden. Die Erstellung des Token ist immer an das Dispatching System des Taxibetreibers gebunden. Damit ist das Verfahren in seinen Anwendungsfällen auf diese Anwendung beschränkt. Das Dispatching System baut Kommunikationsschnittstellen zum Fahrzeug und zum Kunden auf. Weitere Kommunikationsverbindungen zu zusätzlichen zentralen Datenverarbeitungssystemen wie Vehicle Backend des Fahrzeugherstellers, Autovermietungen oder zentrale Hintergrundsysteme eines Herstellers, mit denen die Fahrberechtigungssysteme und Zugangsberechtigungssysteme des Fahrzeugs bedatet werden, existieren nicht. Das Verfahren aus der US 9 494 938 B1 ist daher auf den Betrieb von Robotaxis ohne Wechsel in der Kontrolle über das Fahrzeug beschränkt.
Zusammenfassend kann gesagt werden, dass keine der vorgenannten technischen Lehren in der Lage ist in einem einheitlichen Verfahren die Themen Zugangsberechtigung, Fahrberechtigung und Erteilen von Fahrbefehlen für den autonomen Fahrbetrieb zu behandeln. Beispielsweise kann keines der vorgenannten Verfahren ein Fahrzeug im autonomen Fahrbetrieb zu einem potentiellen Nutzer fahren lassen und dann der Nutzer im manuellen Fahrbetrieb weiter fahren. Dies scheitert bereits an den Fahrberechtigungssystemen, die bisher immer eine Übergabe eines dem Fahrzeugeigentümer zugeordneten Identifikationselements in Form eines Schlüssels oder einer Keyless-Go Card verlangen. D.h. wenn das Identifikationselement im Fahrzeug ist kann das Fahrzeug zwar autonom bewegt werden, jedoch kann dann jeder das Fahrzeug übernehmen. Ein Diebstahlschutz wäre überhaupt nicht mehr gegeben. Der Fahrzeugbesitzer oder der Eigentümer hätten keine Kontrolle mehr über das Fahrzeug. Befindet sich das Identifikationselement beim aktuellen Fahrzeugbesitzer oder beim Eigentümer kann jeweils nur dieser das Fahrzeug starten. Eine autonome Fahrt ohne anwesenden aktuellen Besitzer des Identifikationselements ist nicht möglich, da sofort die Wegfahrsperren eingreifen, wenn im Fahrzeug kein Identifikationselement detektiert wird.
Ein anderes ungelöstes Problem aus dem bisher genannten Verfahren ist die Kontrollfrage über die Fahrbefehle im autonomen Fahrbetrieb und die Frage der Zugangsberechtigung in das Fahrzeug im autonomen Fahrbetrieb bzw. beim Wechsel zum manuellen Fahrbetrieb. Bisher sind die Ausführung von Fahrbefehlen und die Zugangsberechtigung ebenfalls an die physikalische Anwesenheit eines Identifikationselements gebunden. Ein Dienstleister wie eine Autovermietung kann das Fahrzeug nicht im diebstahlgesicherten Zustand führerlos und autonom zum Kunden fahren lassen und der Kunde übernimmt das Fahrzeug und fährt weiter. Mit den bisherigen Zugangsberechtigungen könnte er nicht einsteigen, da ihm ja zunächst ein physikalisches Identifikationselement übergeben werden müsste.
Erfindungsgemäße Aufgabe ist es daher, ein Verfahren anzugeben, mit dem der Wechsel zwischen führerlosem autonomen Fahrbetrieb und manuellem Fahrbetrieb besser kombiniert werden können, ohne dass es zu Problemen mit Fahrberechtigungssystemen, Zugangsberechtigungen oder dem Erteilen von Fahrbefehlen kommt.
Die Lösung gelingt mit einem Verfahren, bei dem mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (z.B. Autovermieter, Zentrales Hintergrundsystem des Herstellers des Fahrzeugs, Benutzerauthentifizierung, Vehicle Backend, potentieller Fahrzeugnutzer) über mehrere Kommunikationsverbindungen ein Datenformat, welches auch als Zertifikat bezeichnet werden kann, austauschen und eine Vermittlungsstelle (z.B. das Vehicle Back End) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen und in das betreffende Fahrzeug übernimmt. Das Datenformat enthält hierbei Daten für die Zugangsberechtigung, für die Fahrberechtigung und für den auszuführenden Fahrbefehl im autonomen Fahrbetrieb.
Ein großer Vorteil des Verfahrens ist, dass für die Durchführung kein physikalischer Identifikationsgeber notwendig ist und trotzdem die für das Fahrzeug vorhandenen physikalischen Identifikationsgeber, wie Fahrzeugschlüssel oder Keyless Go Card, parallel dazu genutzt werden können, ohne dass sich die Zugangsberechtigungscodes und Fahrberechtigungscodes aus dem schlüssellosen Verfahren mit den Codes im physikalischen Identifikationsgeber blockieren oder stören. Dies wird auch damit erreicht, das mit dem Datenformat in dem Verfahren eigene Fahrberechtigungen und Zugangsberechtigungen, erzeugt und verteilt werden. Sprich es werden verfahrenseigene Hashcodes erzeugt und verbraucht. Was den Verbrauch von Hashcodes im physikalischen Identifikationsgeber unberührt lässt. Das Fahrzeug erkennt dabei, ob es über ein übertragenes Datenformat zugänglich gemacht und gestartet werden soll oder mittels physikalischen Identifikationsgeber, der ein Zertifikat überträgt. Entsprechend werden fahrzeugseitig entweder die Berechtigungsdaten aus dem Datenformat oder die Berechtigungsdaten aus dem physikalischen Identifikationsgeber geprüft und nach erfolgreicher Prüfung genutzt.
Gemäß einer sehr günstigen Ausgestaltung ist es dabei zweckmäßiger Weise so, dass das Datenverarbeitungssystem des potentiellen Fahrzeugnutzers ein mobiles Kommunikationsgerät ist.
Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht es vor, dass die Datenverarbeitungssysteme das Datenformat untereinander austauschen und mit den notwendigen Daten befüllen. Das Datenformat muss gegebenenfalls noch mit weiteren notwendigen Daten befüllt werden. Die Datenverarbeitungssysteme der jeweils involvierten Nutzergruppen tauschen dazu das Datenformat untereinander aus und befüllen dieses, sodass letztlich das komplett ausgefüllte Datenformat zumindest im Bereich der Vermittlungsstelle, beispielsweise des Vehicle Back End entsprechend vorliegt und als vollständig ausgefülltes Datenformat an das Fahrzeug übertragen werden kann. Diese Vorgehensweise ermöglicht es dabei, den einzelnen Datenverarbeitungssystemen die Erzeugung von Datenformaten anzustoßen, auch wenn ihnen nicht alle notwendigen Daten vorliegen. Diese können dann anderweitig ergänzt werden, beispielsweise indem ein Verfügungsberechtigter über das Fahrzeug sein O.K. zu einer Fahrzeugnutzung beispielsweise durch einen anderen Nutzer erteilt oder dergleichen. Das fertig befüllte Datenformat gelangt dann in das Fahrzeug und kann hier entsprechend genutzt werden.
Gemäß einer sehr vorteilhaften Weiterbildung des Verfahrens kann es vorgesehen sein, dass das an das Fahrzeug übermittelte Datenformat in dem Fahrzeug, insbesondere in einem geschützten Speicherbereich, gespeichert wird.
Ein weiterer großer Vorteil des so weitergebildeten erfindungsgemäßen Verfahrens ist dann die erhöhte Verfügbarkeit des Fahrzeugs und insbesondere die erhöhte Betriebssicherheit im autonomen Fahrbetrieb. Im Unterschied zu den vorbekannten Überwachungsverfahren bzw. Fernsteuerungsverfahren im autonomen Fahrbetrieb ist keine permanente Online Verbindung, die nicht abbrechen darf, notwendig. Dies wird erreicht durch die Platzierung des Datenformats bzw. Zertifikat im Fahrzeug. Eine Online Verbindung ist nur für die Zeitdauer der Übertragung notwendig. Nach erfolgter Übertragung verfügt das Fahrzeug über alle notwendigen Daten, um Zugangsberechtigung, Fahrberechtigung und Fahrauftrag auszuführen. Der Fahrauftrag kann gegebenenfalls mit einem weiteren Unterstützungssystem z.B. einem Navigationssystem durchgeführt werden. Ebenso wenig braucht der Nutzer eine permanente oder zeitlich koordinierte Datenverbindung zu einem der beteiligten Datenverarbeitungssysteme. Die Verteilung des Datenformats an die beteiligten Datenverarbeitungssysteme kann auf den getrennten Kommunikationswegen zeitlich unabhängig voneinander erfolgen. Grundsätzlich braucht es daher im autonomen Fahrbetrieb keine permanente Onlineverbindung, um die autonome Fahrt durchzuführen.
Eine günstige Weiterbildung dieser Ausgestaltung des erfindungsgemäßen Verfahrens sieht es dabei ferner vor, dass das an das Fahrzeug übermittelte und in dem Fahrzeug gespeicherte Datenformat Daten für mehrere zeitlich nacheinander nutzbare Zugangs- und Fahrberechtigungen sowie auszuführende Fahrbefehle umfasst. Von der Vermittlungsstelle, wie beispielsweise dem Vehicle Back End, kann also nicht nur ein Datenformat an das Fahrzeug überragen werden, sondern gleich mehrere, welche zeitlich nacheinander genutzt werden können. Hierdurch ist es möglich, eine Gruppe von Datenformaten an das Fahrzeug zu übertragen, beispielsweise zehn einzelne Datenformate. Mit jedem dieser Datenformate kann dann, ohne dass eine Online-Verbindung des Fahrzeugs zu der Vermittlungsstelle besteht, eine Zugangsberechtigung oder eine Fahrberechtigung erteilt, sowie ein auszuführender Fahrbefehl freigegeben werden. Auch wenn das Fahrzeug über einen längeren Zeitraum keine Online-Verbindung zur Vermittlungsstelle hat, kann es dennoch über das vorzugsweise mobile Endgerät als Datenverarbeitungssystem des potenziellen Fahrzeugnutzers zu dessen Identifikation genutzt werden, auch mehrfach hintereinander, sodass eine Fahrt beispielsweise unterbrochen und nach einer gewissen Wartezeit, einer Übernachtung oder dergleichen fortgesetzt werden kann, ohne dass dazwischen eine Online-Verbindung zwischen dem Fahrzeug und der Vermittlungsstelle notwendig wäre. Dies ist hinsichtlich der Nutzung insbesondere dann ein entscheidender Gewinn an Komfort, wenn keine durchgehende Online-Verbindung zwischen dem Fahrzeug und der Vermittlungsstelle möglich ist.
Weitere vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den weiteren abhängigen Unteransprüchen und aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figur näher erläutert werden.
Die einzige beigefügte Figur zeigt dabei die einzelnen Funktionen und Aufgaben der beteiligten Datenverarbeitungsanlagen in einem schematischen Beispiel.
Die Figur zeigt ein angedeutetes Fahrzeug 1 sowie einen mit 2 bezeichneten potenziellen Fahrzeugnutzer. Dieser verfügt über ein mit 3 bezeichnetes mobiles Endgerät, beispielsweise ein Smartphone als Datenverarbeitungssystem. Der potenzielle Fahrzeugnutzer 2 bzw. sein Smartphone 3 steht über eine prinzipmäßig angedeutete Kommunikationsverbindung beispielsweise mit einer Benutzerauthentifizierung 5 in Verbindung. Diese ist hier beispielhaft als Desktop-Rechner dargestellt und kann beispielsweise im Büro oder zu Hause bei dem über das Fahrzeug 1 Verfügungsberechtigten positioniert sein. Dieses Datenverarbeitungssystem für die Benutzerauthentifizierung steht wiederum in Kontakt mit einer mit 6 bezeichneten Vermittlungsstelle, welche als Vehicle Back End ausgebildet ist und nachfolgend auch als DaiVB (Daimler Vehicle Back End) bezeichnet wird. Diese Vermittlungsstelle 6 steht wiederum mit einem Datenverarbeitungssystem eines oder mehrerer Dienstleister für fahrzeugbezogene Dienstleistungen 7 in Kontakt. Hierbei kann es sich beispielsweise über ein Car-Sharing-System, eine Autovermietung oder ähnliches handeln. Außerdem steht die Vermittlungsstelle 6 mit einem mit 8 bezeichneten Hintergrundserver des Fahrzeugherstellers in Verbindung. Diese Verbindungen können beispielsweise über Internetverbindungen, vorzugweise gesicherte Internetverbindungen, ausgeführt werden.
Die Benutzerauthentifizierung 5 wird vom Verfügungsberechtigten des betreffenden Fahrzeugs 1 bedient und ausgeführt. Der Verfügungsberechtigte gibt z.B. ein anfragendes Datenformat 9 frei und dokumentiert seine Zustimmung im Datenformat 9. Zweckmäßiger Weise erfolgt die Authentifizierung über den Dienst Mercedes-me, ein anderes dem Fahrzeug zugeordnetes Internet Portal und/oder eine parallel App.
Das DaiVB 6 erhält das freigegebene Datenformat 9 und übernimmt die weitere Verteilung des Datenformats und die weiteren, eventuell notwendigen Anfragen, um das Datenformat 9 mit weiteren Daten zu befüllen. Wichtigste Aufgabe des DaiVB 6 ist dann der Transfer des voll befüllten Datenformats 9 in das betreffende Fahrzeug 1 bzw. in ein Secure Element 10 (geschützter Datenbereich) im Fahrzeug 1.
Das zentrale Hintergrundsystem 8 stellt insbesondere Zugangsdaten und Fahrberechtigungsdaten bereit und befüllt das Datenformat 9 mit den für das Fahrzeug 1 spezifischen Zugangsdaten und Fahrberechtigungsdaten. Die Fahrberechtigungsdaten (Hash Codes für das Fahrberechtigungssystem) können hierbei vom DaiVB 6 in das Fahrzeug 1 geroutet werden, so dass das Fahrzeug 1 mit diesen Codes gestartet und bewegt werden kann. Das Routing vom DaiVB 6 in das Fahrzeug 1 ist dabei über eine Luftschnittstelle entsprechend angedeutet.
Die Zugangsberechtigungen werden außerdem vom DaiVB 6 an das mobile Endgerät 3 des Nutzers 2 geroutet. Entweder direkt über Mobilfunk oder indirekt über die Benutzerauthentifizierung 5, wie es hier angedeutet ist. Der Nutzer 2 kann dann das Fahrzeug 1, das z.B. in autonomer Fahrt zu ihm geschickt wird, mit seinem mobilen Endgerät 3 öffnen.
Die Hash Codes für die Fahrberechtigung wurden vor dem Zeitpunkt der Nutzung bereits in das Fahrzeug 1 transferiert. Im Fahrzeug 1 prüft ein Steuergerät11 oder ein Steuergeräteverbund, ob das vom DaiVB 6 ins Fahrzeug 1 übertragene Datenformat 9 die gleiche Kennung enthält wie das Datenformat 9 auf dem mobilen Endgerät 3 des Nutzers 2. Wenn ja, werden die ins Fahrzeug 1 übertragenen Fahrberechtigungen freigegeben und das Fahrzeug 1 kann vom Nutzer 2 per Startknopf gestartet und gefahren werden. Zweckmäßiger Weise wird eine genügende Anzahl von Fahrberechtigungen (Hash Codes) übertragen, so dass das Fahrzeug 1 mehrfach gestartet werden kann, bis alle Hash Codes verbraucht sind. Alternativ können die übertragenen Zugangs- und Fahrberechtigungen auch zeitlich oder örtlich, z.B. auf die Position des Fahrzeugs 1 bezogen, beschränkt werden.
Der Dienstanbieter 7, z.B. Vermieter, Carsharing, wie Car2Go, usw., oder Privatmann bietet das Fahrzeug 1, über das er verfügungsberechtigt ist, z.B. im Internet an. In diesem Fall kann der Dienstleister 7 mit der Benutzerauthentifizierung 5 in der Figur zusammenfallen. Wird ein angebotenes Fahrzeug 1 vom Nutzer 2 angefragt, kann die Befüllung des Datenformats auch vom Dienstanbieter 7 gestartet werden. Die Freigabe kann er dann gleich selbst erteilen. Wieder übernimmt die Vermittlungsstelle 6 die Verteilung des befüllten Datenformats 9 an Fahrzeug 1 und an den Nutzer 2. Zugangs- und Fahrberechtigungsdaten werden auch in diesem Fall von dem zentralen Hintergrundsystem 8 in das Datenformat 9 geschrieben. Soll das Fahrzeug 1 autonom zum Nutzer 2 fahren, muss ein Fahrauftrag für die autonome Fahrt erstellt und in das Datenformat 9 geschrieben werden. Soll eine autonome Fahrt durchgeführt werden, führt das Fahrzeug 1 diese Fahrt mit den Angaben im Fahrauftrag durch. Das Fahrzeug 1 kann sich hierbei mit den ebenfalls per Datenformat 9 übertragenen Fahrberechtigungen selbst starten, sobald eine Zertifikatfreigabe von der Benutzerauthentifizierung 5 vorliegt, die ja ebenfalls in dem Datenformat 9 enthalten ist und von dem Steuergerät 11 im Fahrzeug 1 überprüft werden kann.
Ein weiterer Anwendungsfall ergibt sich, wenn der Fahrzeughersteller selbst, das Fahrzeug 1 autonom fahren lassen will, z.B. am Ende des Produktionsprozesses oder zur Verladung oder Verschiffung des Fahrzeugs 1. Dann startet der Fahrzeughersteller mit seinem zentralen Hintergrundsystem 8 das Verfahren, in dem von diesem Hintergrundsystem 8 ein Datenformat 9 erstellt wird. In diesem Fall erfolgt die Authentifizierung durch den Fahrzeughersteller, so dass das Hintergrundsystem 8 und die Benutzerauthentifizierung 5, unter Wegfall des Dienstleisters 7, zusammenfallen. Das DaiVB 6 übernimmt auch hier das Routing des Datenformats 9 an die weiteren beteiligten Datenverarbeitungssysteme. Der Fahrauftrag muss dann vom Fahrzeughersteller über das zentrale Hintergrundsystem 8 erstellt werden. Der weitere Ablauf des Verfahrens läuft wie zuvor für das autonome Fahren bereits beschrieben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102014001836 A1 [0003]
DE 102012012389 A1 [0004]
DE 102013201168 A1 [0005]
US 9494938 B1 [0006]

Claims

Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen sowie auszuführender Fahrbefehle, in Form eines Datenformats (9), für ein Fahrzeug (1), dadurch gekennzeichnet, dass mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (2, 5, 6, 7, 8), welche über mehrere Kommunikationsverbindungen das Datenformat (9) austauschen, genutzt werden, wobei eine Vermittlungsstelle (6) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen (2, 5, 6, 7, 8) und in das Fahrzeug übernimmt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Nutzergruppen (2, 5, 6, 7, 8) zumindest einem potenziellen Fahrzeugnutzer (2), einer Benutzerauthentifizierung (5) und einem Anbieter von fahrzeugbezogenen Dienstleistungen (7) und/oder dem Hersteller des Fahrzeugs (8) zugeordnet werden.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass zumindest eines der Datenverarbeitungssysteme des potenziellen Fahrzeugnutzers (2) als mobiles Endgerät (3) ausgebildet ist.
Verfahren nach einem der Ansprüche 1, 2 oder 3, dadurch gekennzeichnet, dass die Datenverarbeitungssysteme das Datenformat (9) untereinander austauschen und mit den notwendigen Daten befüllen.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass ein Fahrzeug-Backend-Server (6) als Vermittlungsstelle genutzt wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das an das Fahrzeug (1) übermittelte Datenformat (9) in dem Fahrzeug (1) gespeichert wird.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Speichern in einem geschützten Speicherbereich (11) erfolgt.
Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass das an das Fahrzeug (11) übermittelte und in dem Fahrzeug gespeicherte Datenformat (9) Daten für mehrere zeitlich nacheinander nutzbare Zugangs- und Fahrberechtigungen sowie auszuführende Fahrbefehle umfasst.