-
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Abfrage von Daten eines Fahrzeugs.
-
Es ist bekannt, Daten zwischen einem Fahrzeug und einem Backend (umfassend mindestens einen Rechner oder mindestens ein Rechnernetz, das insbesondere eine Verbindung zu anderen Rechnernetzen, z. B. dem Internet, aufweist) auszutauschen. Hierbei kann das Fahrzeug Daten von dem Backend anfordern oder das Backend kann (unaufgefordert) Daten an das Fahrzeug übertragen.
-
Hierbei können die Daten nur zwischen dem Backend und dem Fahrzeug übermittelt werden. Auch ist für die Übertragung eine Verbindung mit dem Fahrzeug notwendig. Der Zugriff auf die Daten erfolgt über unterschiedliche Schnittstellen, wobei die Schnittstellen je nach Ausführungsort der Anwendung variieren: Beispielsweise laufen in dem Fahrzeug, in dem Backend oder an einem Computer im Büro oder zuhause unterschiedliche Applikationen mit unterschiedlichen Schnittstellen. Dies gestaltet den Umgang mit den Daten als umständlich und für den Benutzer stark gewöhnungsbedürftig.
-
Die Aufgabe der Erfindung besteht darin, die vorstehend genannten Nachteile zu vermeiden und insbesondere eine effiziente Lösung zum Zugriff auf Daten eines Fahrzeugs anzugeben.
-
Diese Aufgabe wird gemäß den Merkmalen der unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung ergeben sich auch aus den abhängigen Ansprüchen.
-
Zur Lösung der Aufgabe wird ein Verfahren zur Abfrage von Daten eines Fahrzeugs angegeben, bei dem die Daten des Fahrzeugs von dem Fahrzeug oder von einem mit einem Netzwerk verbundenen separat zu dem Fahrzeug vorgesehenen Server bereitgestellt werden.
-
Bei dem Server kann es sich um mindestens einen Rechner und/oder mindestens ein Rechnernetz (z. B. ein Backend) handeln, das mit dem Fahrzeug über eine Kommunikationsschnittstelle (z. B. eine drahtlose Mobilfunkschnittstelle) Nachrichten austauschen kann und zumindest zeitweise so mit dem Fahrzeug Daten austauscht. Der Datenaustausch kann im Rahmen einer leitungsvermittelten oder paketvermittelten Kommunikation erfolgen. Insbesondere kann der Datenaustausch auch zusammen mit einem anderen Dienst, z. B. einem Telefongespräch erfolgen. Somit ist es von Vorteil, dass ein Nutzer oder eine Applikation zum Zugriff auf die Daten des Fahrzeugs nicht mit dem Fahrzeug verbunden sein muss. Auch ist hierfür ggf. keine Verbindung des Servers mit dem Fahrzeug nötig, weil bereits auf dem Server (zwischen)gespeicherte Daten des Fahrzeugs mit einer ausreichenden Aktualität dem Benutzer oder der Applikation bereitgestellt werden können. Somit kann, der Zugriff auf diese Daten des Fahrzeugs über den Server erfolgen, auch wenn das Fahrzeug selbst nicht erreichbar sein sollte.
-
Insbesondere kann der Server einen Zwischenspeicher, hier auch bezeichnet als virtueller KFZ Datenspeicher, aufweisen. Ergänzend sei angemerkt, dass der Server (bzw. das Backend) eine Vielzahl von Fahrzeugen entsprechend verwalten kann.
-
Vorzugsweise handelt es sich bei einem Betreiber des Servers um einen Dienstanbieter oder Fahrzeughersteller, der die Kommunikationsverbindung zu dem Fahrzeug (oder entsprechend zu mehreren Fahrzeugen) administriert.
-
Hierbei sei angemerkt, dass auf die hier beschriebene Art die Daten des Fahrzeugs von einer Applikation, die unabhängig von dem Fahrzeug abläuft, abgefragt werden können. Entsprechend ist es auch möglich, die Daten des Fahrzeugs (oder Teile der Daten) über die Applikation zu verändern, zu löschen oder neue Daten zu ergänzen. Dies kann entsprechend über die hier beschriebenen Schnittstellen erfolgen.
-
Eine Weiterbildung ist es, dass basierend auf der Abfrage ein transparenter Zugriff auf die Daten des Fahrzeugs entweder über das Fahrzeug selbst oder über den Server durchgeführt wird.
-
Transparent meint hierbei insbesondere, dass ein Dienst erbracht wird, beispielsweise wird eine Antwort auf eine Abfrage eines Benutzers oder einer Applikation betreffend Daten eines Fahrzeugs bereitgestellt, ohne dass die anfragende Instanz (Benutzer oder Applikation) sich darum kümmern muss, wer die Antwort bereitstellt, also ob tatsächlich die übermittelte Antwort auf dem Server zwischengespeicherte Daten oder aktuell von dem Fahrzeug übertragene Daten enthält. Insofern ist es von Vorteil, dass für den Benutzer oder die Applikation der Eindruck entstehen kann als wäre das Fahrzeug permanent erreichbar (online), ohne dass dies tatsächlich der Fall sein müsste. Die Abfrage kann, wie erläutert, mit auf dem Server zwischengespeicherten Daten beantwortet werden.
-
Eine andere Weiterbildung ist es, dass die auf dem Server gespeicherten Daten des Fahrzeugs mit den aktuellen Daten des Fahrzeugs synchronisiert werden.
-
Eine Synchronisation kann automatisch, regelmäßig, unregelmäßig oder basierend auf vorgegeben Ereignissen (auf der Seite des Fahrzeugs und/oder des Servers) ausgelöst werden bzw. erfolgen.
-
Insbesondere ist es eine Weiterbildung, dass die Daten des Fahrzeugs mittels einer einheitlichen Programmierschnittstelle für unterschiedliche Plattformen bereitgestellt werden.
-
So kann eine webbasierte Applikation z. B. auf einem Server des Internets implementiert sein, die eine solche Programmierschnittstelle (API) nutzt, um auf die Daten des Fahrzeugs zuzugreifen. Auch kann eine Applikation auf einem mobilen Endgerät vorgesehen sein, die über eine API auf die Daten des Fahrzeugs zugreifen kann. Weiterhin ist es möglich, dass ein Nutzer von seinem Büro oder von zuhause mittels einer Applikation, die eine API nutzt, auf die Daten des Fahrzeugs zugreift.
-
Auch ist es eine Weiterbildung, dass das Fahrzeug zumindest zeitweise über eine Funkschnittstelle mit dem Server verbunden ist.
-
Beispielsweise kann es sich bei der Funkschnittstelle um eine Mobilfunkschnittstelle oder um eine WLAN-Schnittstelle handeln.
-
Ferner ist es eine Weiterbildung, dass die Daten eine Information, insbesondere eine Aktualitätsinformation, einen Zeitstempel oder eine Positionsinformation, aufweisen.
-
So kann die Applikation die Aktualität der Daten ermitteln bzw. entscheiden, ob die erhaltenen Daten ausreichend aktuell sind. Sollte dies nicht der Fall sein, also für die Zwecke der Applikation veraltete Daten bereitgestellt worden sein, so kann die Applikation aktuelle Daten z. B. bei dem Server oder direkt bei dem Fahrzeug anfordern. Auch ist es möglich, dass die Applikation bereits mit der Abfrage signalisiert, welche Art der Aktualität der Daten erforderlich ist (z. B. ”nicht älter als 2 Tage”).
-
Insbesondere ist es möglich, dass der Server selbst eine vorgegebene Aktualität der Daten (wobei verschiedene Daten unterschiedlich lange als aktuell angesehen werden können) gewährleistet, indem entsprechend veraltete Daten automatisch (z. B. bei nächster Gelegenheit oder im Rahmen einer zu vorgegebenen Zeiten oder Ereignissen durchgeführten Synchronisation mit dem Fahrzeug) aktualisiert werden. Dies erhöht die Wahrscheinlichkeit, dass eine Abfrage an den Server betreffend bestimmte Daten des Fahrzeugs beantwortet werden kann, ohne dass hierfür eine (erneute) Verbindung mit dem Fahrzeug aufgebaut werden müsste (sei es von der anfragenden Applikation oder von dem Server selbst) und ohne dass das Fahrzeug erreichbar sein müsste (z. B. ist ein in einer Tiefgarage abgestelltes Fahrzeug meist nicht über ein Mobilfunknetzwerk erreichbar).
-
Im Rahmen einer zusätzlichen. Weiterbildung wird abhängig von einem vorgegebenen Ereignis eine Kommunikationsverbindung von dem Server zu dem Fahrzeug oder von einer anfragenden Applikation zu dem Fahrzeug hergestellt.
-
Beispielsweise kann regelmäßig eine Synchronisation der Daten des Fahrzeugs mit den auf dem Server gespeicherten Daten erfolgen. Auch kann manuell oder nach einer Hardware-Aktualisierung des Servers eine Synchronisation gestartet werden.
-
Die Synchronisation kann abschnittsweise erfolgen, z. B. dann wenn das Fahrzeug über ein Mobilfunknetzwerk erreichbar ist. Auch kann die Synchronisation mit hoher oder niedriger Priorität erfolgen. Weiterhin ist es möglich, dass die Synchronisation insbesondere dann durchgeführt wird, wenn eine breitbandige Verbindung mit dem Fahrzeug besteht, z. B. das Fahrzeug über WLAN oder 3GPP LTE verbunden ist.
-
Eine nächste Weiterbildung besteht darin, dass von der Applikation die Abfrage an den Server übermittelt wird und die Applikation versucht, das Fahrzeug zu kontaktieren, falls der Server nicht über die angefragten Daten verfügt.
-
Auch ist es eine Weiterbildung, dass die Applikation die Abfrage an eine Middleware überträgt, wobei die Middleware als zentrale oder dezentrale Funktion eines Netzwerks die Daten des Fahrzeugs bereitstellt.
-
Die Middleware kann teilweise den von dem Server bereitgestellten Dienst nutzen oder teilweise auf diesem implementiert sein. Insbesondere kann somit effizient anhand der Middleware ein transparenter Zugriff auf die Daten des Fahrzeugs erfolgen.
-
Weiterhin können die Applikationen bei der Middleware einen Dienst abonnieren, wobei der Dienst aktiv Daten des Fahrzeugs an die Applikationen überträgt, beispielsweise falls sich die Daten ändern oder falls sonstige Ereignisse oder Bedingungen erfüllt sind.
-
Auch ist es eine Weiterbildung, dass abhängig von einem vorgegebenen Ereignis eine Kommunikationsverbindung von dem Fahrzeug zu dem Server hergestellt wird.
-
Insbesondere können Ereignisse (z. B. ein Abstellen oder ein Starten, das Erreichen einer vorgegebenen Position oder eines Zustands einer Steuereinheit) des Fahrzeugs eine Übertragung von Daten an den Server auslösen.
-
Eine Ausgestaltung ist es, dass die Daten des Fahrzeugs umfassen:
- – Eigenschaften des Fahrzeugs,
- – Einstellungen des Fahrzeugs,
- – Informationen von Steuergeräten des Fahrzeugs.
-
Die vorstehend genannte Aufgabe wird auch gelöst mittels einer Vorrichtung zur Bereitstellung von Daten eines Fahrzeugs
- – wobei die Vorrichtung separat zu dem Fahrzeug ausgeführt ist,
- – umfassend eine Verarbeitungseinheit und einen Speicher,
- – wobei die Verarbeitungseinheit derart eingerichtet ist, dass die Daten des Fahrzeugs von dem Fahrzeug oder aus dem Speicher bereitgestellt werden.
-
Insbesondere kann die Vorrichtung Teil eines drahtgebundenen und/oder drahtlosen Kommunikationsnetzes sein. Auch kann die Vorrichtung eine Verbindung mit dem Internet aufweisen. Weiterhin kann die Vorrichtung über eine Möglichkeit zur Kontaktierung des Fahrzeugs (z. B. über eine Mobilfunkschnittstelle) aufweisen.
-
Entsprechend kann die Vorrichtung den vorstehend genannten Dienst ”Bereitstellung von Daten des Fahrzeugs” transparent erbringen ohne dass die anfragende Instanz weiß, ob die Daten (nur) aus dem Speicher der Vorrichtung oder (unmittelbar) von dem Fahrzeug stammen.
-
Eine Ausführungsform besteht darin, dass anhand der Verarbeitungseinheit die Daten zwischen dem Fahrzeug und dem Speicher synchronisierbar sind.
-
Eine nächste Ausgestaltung ist es, dass die Vorrichtung ein Server eines Dienstanbieters oder Fahrzeugherstellers ist.
-
Insbesondere kann der Server mehrere Rechner umfassen bzw. können ein Rechnernetz oder eine Vielzahl von Kommunikationsnetzwerken vorgesehen sein.
-
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der Zeichnung dargestellt und erläutert.
-
Es zeigt:
-
1 schematisch eine Architektur zur Abfrage einer Information aus einem virtuellen KFZ Datenspeicher, wodurch ein übergangsloser (”seamless”) Zugriff auf Daten des Fahrzeugs ermöglicht wird.
-
Es wird ein Framework für einen transparenten Zugriff auf Fahrzeugeigenschaften und Fahrzeugeinstellungen vorgeschlagen. Dieses Framework umfasst insbesondere eine einheitliche Schnittstelle für verschiedene Plattformen, z. B.
- – für das Fahrzeug selbst,
- – für einen (Personal-)Computer im Büro oder zuhause,
- – für ein mobiles Endgerät des Benutzers,
- – für eine über das Internet nutzbare (Web-)Applikation.
-
Weiterhin wird ein (Zwischen-)Speicher (”virtueller KFZ Datenspeicher”) vorgeschlagen, der z. B. in einem Backend vorgesehen ist, um Abfragen von Applikationen zu bedienen, falls z. B. gerade kein Kommunikationskanal zu dem Fahrzeug existiert. Alternativ oder zusätzlich kann der (Zwischen-)Speicher auch verteilt ausgeführt sein, z. B. zumindest teilweise auf anderen Geräten als den Geräten des Backends, z. B. einem Heimnetzwerk und/oder einem Personalcomputer.
-
Es sei angemerkt, dass das Backend mindestens einen Rechner, insbesondere eine Vielzahl von Rechnern, eines Fahrzeugherstellers oder Dienstanbieters umfasst, wobei über das Backend zumindest zeitweise eine Kommunikationsverbindung zu dem Fahrzeug besteht bzw. hergestellt werden kann.
-
Hierbei ist es von Vorteil, dass die Kommunikation mit dem Backend transparent ist, also dass nicht erkennbar ist, ob die Abfrage direkt von dem Fahrzeug oder von dem virtuellen KFZ Datenspeicher beantwortet wird.
-
1 zeigt schematisch eine Architektur zur Abfrage einer Information aus einem virtuellen KFZ Datenspeicher 102. Hierdurch wird ein übergangsloser (”seamless”) Zugriff auf Daten des Fahrzeugs ermöglicht, ohne dass permanent eine Kommunikationsverbindung zwischen dem Backend und dem Fahrzeug bestehen müsste.
-
Es wird ein SCMA (Seamless Car and Data Management = übergangsloses KFZ- und Datenmanagement) Framework vorgeschlagen, wobei hier Framework einen funktionalen Rahmen bzw. ein Bezugssystem für ein übergangsloses KFZ- und Datenmanagement bezeichnet.
-
Eine Komponente SCMA KFZ 110 ist als Teil eines Fahrzeugs 111 vorgesehen und ermöglicht einen Zugriff auf fahrzeugrelevante Daten (Eigenschaften, Einstellungen, Dienstinformationen, etc.), die beispielsweise in mindestens einer Steuereinheit 112 des Fahrzeugs 111 verfügbar sind. Insbesondere kann das Fahrzeug 111 mehrere Steuereinheiten 112 aufweisen, wobei beispielsweise eine zentrale Steuereinheit (auch bezeichnet als Headunit) in dem Fahrzeug vorgesehen sein kann. Beispielsweise kann die zentrale Steuereinheit Infotainment-Funktionen umfassen.
-
Auch kann die Komponente SCMA KFZ 110 so eingerichtet sein, dass es Kommunikationsstrukturen des Fahrzeug 111, z. B. Bussysteme (CAN, MOST, Ethernet, etc.) nutzt, um Daten von der Steuereinheit 112 auszulesen bzw. auf diese zu schreiben.
-
1 zeigt weiterhin den virtuellen KFZ Datenspeicher 102, der als Teil eines Backends 101 ausgeführt ist. Bei dem virtuellen KFZ Datenspeicher 102 handelt es sich insbesondere um einen Zwischenspeicher (auch bezeichnet als ”Cache”) für Daten des Fahrzeugs 111. Vorzugsweise können diese Daten des Fahrzeugs 111 automatisch mit dem virtuellen KFZ Datenspeicher 102 synchronisiert werden. So kann eine Kommunikationsverbindung mit dem Fahrzeug 111 aufgebaut werden oder es kann eine bestehende Kommunikationsverbindung mit dem Fahrzeug 111 genutzt werden, um die Daten zu synchronisieren.
-
Die Kommunikation mit der Komponente SCMA KFZ 110 erfolgt über eine SCMA Programmierschnittstelle (SCMA API, API = Application Programming Interface, Programmierschnittstelle), anhand derer Applikationen eine universelle und einfach nutzbare Schnittstelle bereitgestellt wird, um auf Daten des Fahrzeugs 111 zuzugreifen.
-
So kann eine webbasierte Applikation 106 z. B. auf einem Server des Internets 103 implementiert sein, die eine SCMA API 105 nutzt, um auf die Daten des Fahrzeugs 111 zuzugreifen. Auch kann eine Applikation 108 auf einem mobilen Endgerät 109 vorgesehen sein, die über eine SCMA API 107 auf die Daten des Fahrzeugs 111 zugreifen kann. Weiterhin ist es möglich, dass ein Nutzer von seinem Büro oder von zuhause 115 mittels einer Applikation 114, die eine SCMA API 113 nutzt, auf die Daten des Fahrzeugs 111 zugreift.
-
Ergänzend sei angemerkt, dass es verschiedene Implementierungen einer Programmierschnittstelle geben kann. Beispielsweise kann eine Web-basierte Implementierung von Applikationen des Internets genutzt werden oder es kann eine Implementierung in Java, C, C++, C#, o. ä. geben, die z. B. von einer Desktop-Applikation genutzt wird.
-
Die Komponente SCMA KFZ 110 stellt einen Dienst entsprechend einer (transparenten) Zugriffsschicht bereit, um auf die Daten des Fahrzeugs 111, die beispielsweise in einem Bordnetz oder in den Steuereinheiten 112 des Fahrzeugs 111 verfügbar oder gespeichert sind, zuzugreifen.
-
Insbesondere können von der Komponente SCMA KFZ 110 Daten des Fahrzeugs 111 in dem virtuellen KFZ Datenspeicher 102 zwischengespeichert und/oder mit diesem abgeglichen werden.
-
Der virtuelle Datenspeicher kann zusätzlich zu den Daten aus dem Fahrzeug (z. B. Daten, deren Quelle das Fahrzeug selbst ist) auch Daten aus anderen Quellen umfassen, die an das Fahrzeug übermittelt werden (z. B. Verkehrs-, Stau-, Parkplatzinformationen). Diese zusätzlichen Informationen können dann gezielt, z. B. basierend auf einer aktuellen Position des Fahrzeugs, an andere Fahrzeuge übertragen werden (Geo-Tagging des Fahrzeugs).
-
Unterschiedliche Typen oder Kategorien von Daten können unterschiedliche Ereignisse aufweisen basierend z. B. auf Zustandsänderungen des Fahrzeugs 111 (z. B. das Fahrzeug wird geparkt), die eine Synchronisation mit dem virtuellen KFZ Datenspeicher 102 auslösen. Auch kann ein Abgleich mit dem virtuellen KFZ Datenspeicher 102 ausgelöst werden, wenn mindestens ein zwischengespeicherter Wert geändert wurde während das Fahrzeug abgestellt (ausgeschaltet) war.
-
Insofern wird erreicht, dass der virtuellen KFZ Datenspeicher 102 zumindest teilweise oder betreffend bestimmte Daten des Fahrzeugs synchronisiert wird abhängig von bestimmten Ereignissen oder Zustandsübergängen des Fahrzeugs. Insbesondere die Verfügbarkeit und Qualität einer bestehenden Funkverbindung kann eine solche Synchronisation anstoßen. Bei schlechter Verbindung können auch nur Teile der Daten (gemäß einer vorgegebenen Priorisierung) synchronisiert werden.
-
Somit kann die Synchronisation insbesondere (z. B. proaktiv) unabhängig von einer Abfrage betreffend die Daten des Fahrzeugs erfolgen.
-
Hierbei sei angemerkt, dass der virtuelle, KFZ Datenspeicher 102 auch gezielt aktualisiert werden kann, indem z. B. mehr oder weniger regelmäßig automatisch oder manuell oder aber aufgrund eines Ereignisses des Backends 101 (z. B. nach einer Konfiguration oder einem Austausch von Komponenten) die Synchronisation mit den Daten des Fahrzeugs 111 gestartet wird.
-
Je nach Verfügbarkeit eines Kommunikationskanals zu dem Fahrzeug 111 wird eine Abfrage einer Applikation betreffend die Daten des Fahrzeugs 111 entweder direkt von der Komponente SCMA KFZ 110 des Fahrzeugs 111 oder von dem virtuellen KFZ Datenspeicher 102 beantwortet. Die Beantwortung der Abfrage der Applikation (bzw. des Benutzers) erfolgt vorzugsweise transparent, also ohne dass die Applikation erkennen müsste, wer (Fahrzeug oder Backend) die Daten zur Beantwortung der Abfrage bereitstellt.
-
Vorzugsweise können die Daten des Fahrzeugs 111 eine Zeitinformation (z. B. einen Zeitstempel) aufweisen, anhand dessen eine Aktualität der Daten ermittelt werden kann. Eine Applikation 106, 108 oder 114 kann auf die Zeitinformation entsprechend reagieren, indem sie z. B. mitteilt, dass aktuellere Daten benötigt werden. Ergänzend sei angemerkt, dass anstelle oder zusätzlich zu der Zeit- oder Aktualitätsinformation unterschiedliche Informationen (auch bezeichnet als Tags) mit den Daten verknüpft und/oder bereitgestellt werden können, z. B. Positionsinformationen (Geo-Tagging).
-
Insofern ist es auch möglich, dass auf eine Abfrage einer Applikation hin eine Kommunikationsverbindung mit dem Fahrzeug 111 genutzt oder hergestellt wird, um die Daten in dem virtuellen KFZ Datenspeicher 102 zu aktualisieren und die angefragten aktualisierten Daten der Applikation bereitzustellen.
-
Der Einsatz einer einheitlichen SCMA API erlaubt eine universelle Bereitstellung von Applikationen für unterschiedliche Zielplattformen, z. B. webbasierte Applikationen im Internet, Applikationen für einen Computer zuhause oder im Büro, Applikationen für (verschiedene) mobile Endgeräte oder Dienste direkt in dem Fahrzeug. Somit ist es sogar möglich, dass die Applikation (oder zumindest die Applikationslogik) unabhängig von dem tatsächlichen Installationsort ist.
-
Der jeweiligen Applikation 106, 108, 114 wird somit ein transparenter Zugriff 116 auf die Daten des Fahrzeugs 111 ermöglicht, wobei diese Daten tatsächlich von dem virtuellen KFZ Datenspeicher 102 oder von dem KFZ (ggf. dann auch über das Backend 101) bereitgestellt werden können.
-
Hierbei ist es möglich, dass eine Abfrage der Applikation 106, 108, 114 zuerst bei dem Backend erfolgt und das Backend versucht, diese Abfrage zu beantworten mittels der in dem virtuellen KFZ Datenspeicher 102 abgespeicherten Daten. Sind die angeforderten Daten nicht in dem virtuellen KFZ Datenspeicher 102 verfügbar oder sind in dem virtuellen KFZ Datenspeicher 102 verfügbare Daten älter als von der Applikation gefordert, so versucht das Backend 101 das Fahrzeug 111 zu kontaktieren und die (aktualisierten) Daten von dem Fahrzeug 111 zu erhalten. Ist die Kommunikation des Backends 101 mit dem Fahrzeug 111 erfolgreich, so werden die (aktualisierten) Daten von dem Backend der Applikation 106, 108, 114 bereitgestellt. Ist die Kommunikation des Backends 101 mit dem Fahrzeug 111 nicht erfolgreich (weil z. B. das Fahrzeug 111 nicht erreichbar ist oder die Daten nicht zur Verfügung stehen), so kann eine entsprechende Rückmeldung an die Applikation 106, 108, 114 erfolgen. Optional kann ein Zeitgeber (Timer) von dem Backend gesetzt werden, nach dessen Ablauf erneut die Abfrage an das Fahrzeug 111 gesendet wird.
-
Alternativ ist es möglich, dass die Applikation 106, 108, 114 die Abfrage direkt an das Fahrzeug 111 sendet. Falls das Fahrzeug 111 nicht erreichbar ist, kann die Applikation 106, 108, 114 die Abfrage an das Backend senden.
-
Auch ist es möglich, dass der transparente Zugriff 116 mittels einer Middleware erfolgt, die transparent den Dienst der Bereitstellung von Daten des Fahrzeugs 111 anbietet. Dazu kann die Middleware als eine zentrale Einheit in einem Netzwerk ausgeführt sein, an die die Applikation 106, 108, 114 die Abfrage sendet. Die Middleware kann einen Erreichbarkeits-Zustand des Fahrzeugs 111 verwalten und entsprechend eine Abfrage an das Fahrzeug oder eine Abfrage an das Backend und damit den virtuellen KFZ Datenspeicher 102 starten. Auch kann die Middleware zumindest teilweise in der Applikation 106, 108, 114 realisiert sein.
-
Weiterhin ist es eine Möglichkeit, dass die Funktion des transparenten Zugriffs 116 dezentral verfügbar ist, indem z. B. Applikationen Zustände des Fahrzeugs 111 abonnieren und Zustandsänderungen der Zustände den Applikationen übermittelt werden. Dabei können die Zustandsänderungen vorzugsweise über eine Middleware oder über das Backend an die Applikationen übertragen werden.
-
Anwendungsbeispiele:
-
- a) Ein Nutzer kann von unterschiedlichen Endgeräten über unterschiedliche Plattformen (z. B. Computer zuhause, mobiles Endgerät) über drahtgebundene oder drahtlose Schnittstellen Daten des Fahrzeugs, z. B. servicerelevante Fahrzeugdaten, Kilometerstand, Ölstand, Zustand der Bremsbeläge, etc., abfragen und ggf. geeignete Maßnahmen einleiten, z. B. einen Service-Termin vereinbaren. Diese Daten können von dem virtuellen KFZ Datenspeicher z. B. auch dann bereitgestellt werden, falls das Fahrzeug ausgeschaltet oder nicht erreichbar ist.
- b) Beispielsweise können im Rahmen eines Flottenmanagements Fahrzeugdaten, z. B. eine aktuelle Position des Fahrzeugs, über eine Web-Anwendung oder auch über ein mobiles Endgerät (z. B. ein Mobiltelefon) abgefragt werden. Auch können bestimmte Einstellungen (z. B. betreffend einen Fahrerarbeitsplatz umfassend z. B. individuelle Einstellungen für den Fahrer wie Sitzposition, Radiosender, Klimatisierung, Cockpiteinstellungen, etc.) per Fernsteuerung gesetzt oder eingespielt werden.
- c) Applikationen können über eine geeignete elektronische Plattform (z. B. das Internet) angeboten und vertrieben werden. Derartige Applikationen nutzen die SCMA API, um auf Fahrzeuginformationen zuzugreifen. Dies ermöglicht ein Testen und Debuggen von Applikationen zum Entwicklungszeitpunkt (z. B. in Verbindung mit einem simulierten virtuellen KFZ Datenspeicher). Auch können Nutzer Applikationen bereits vor einer Installation in dem Fahrzeug auf ihrem Computer testen.
