-
Diese Erfindung betrifft Verbesserungen an der Behandlung von Daten und in Bezug auf diese, wobei die Daten von einem Fahrzeug erhalten und darin gespeichert wurden, und insbesondere das Erhöhen der Effizienz der Übermittlung der Daten zu fernen Orten in der Art der Cloud in Zusammenhang mit verbundenen Fahrzeugen.
-
Es ist eine Erhöhung der Anzahl von Sensoren in Fahrzeugen aufgetreten, welche eine Vielzahl von Fahrzeug-, Benutzer- und Verbrennungsmotordaten erfassen. Einige der Daten sollen intern über eine Reihe von Rückkopplungsschleifen innerhalb des Fahrzeugs verwendet werden. Beispielsweise kann die Fahrzeugfahrgastraumtemperatur überwacht werden, um festzustellen, ob die Klimaanlage die Zieltemperatur für den Fahrzeugfahrgastraum erreicht hat.
-
Ein Teil der Daten von den Sensoren wird in Fahrzeugsystemen gespeichert. Abhängig von der Natur des Systems können die Daten unbegrenzt gespeichert werden oder gespeichert werden, bis eine weitere Messung desselben Parameters erfolgt, wobei die früheren Daten an diesem Punkt mit den neuen Daten überschrieben werden können.
-
Um aus dieser zunehmenden Fülle innerhalb eines Fahrzeugs gespeicherter Daten Erkenntnisse zu gewinnen, ist es bekannt, die Daten aus dem Fahrzeug heraus zu übermitteln. Wenn sich beispielsweise ein Problem innerhalb eines Fahrzeugs ergibt, ist es bekannt, dass sich ein Techniker über eine Portalvorrichtung in der Art eines Laptopcomputers mit dem Fahrzeugsystem verbindet, um die innerhalb des Fahrzeugs gespeicherten Daten, welche den Fehler erklären können, zu untersuchen.
-
Ferner ist es bekannt, ein Datenstreaming zu einer Cloudspeichervorrichtung bereitzustellen, wo Daten analysiert werden können.
-
Es sind auch intelligente Fahrzeugtransportsysteme bekannt, wie beispielsweise in
US 2014/380264 (Tata) dargelegt ist, welche die Leistung von Smartphones der Fahrzeugbenutzer ausnutzen, um Informationen, die zu Anomalien in den Fahrzeugen, Straßenbedingungen, Fahrgewohnheiten des Fahrers, Umweltbedingungen und Fahrgastverhalten gehören, zu kanalisieren. Diese Daten werden von den Smartphones zur Cloud gestreamt, wo sie weiter verarbeitet werden können. In Übereinstimmung mit vielen Smartphone-Datenstreamingprotokollen werden Daten typischerweise vom Fahrzeug zur Cloud verschoben.
-
US 2009/170537 offenbart ein Verfahren zum Verzögern eines Telematikdatenhochladens von einem Fahrzeug, das mit Drahtlostelefonie- und Drahtlosnetzkommunikationsvorrichtungen ausgerüstet ist. Die offenbarten Verfahren konzentrieren sich auf das Verzögern der Kommunikation, wenn ein Kommunikationsmodus nicht verfügbar ist.
-
US 2006/253235 offenbart ein Verfahren zur drahtlosen Kommunikation mit einer Vorrichtung. Bei dem Verfahren wird auf Diagnoseinformationen in Zusammenhang mit der Vorrichtung zugegriffen und werden die Diagnoseinformationen über eine Luftschnittstelle bereitgestellt. Die Offenbarung konzentriert sich auf das drahtlose Erhalten von Daten.
-
US 2013/274950 offenbart ein System für eine ausgelöste Anforderung heruntergeladener Informationen von einer fahrzeugbasierten Überwachungseinrichtung, die einen Sender, einen Empfänger und einen Prozessor aufweist. Die Offenbarung konzentriert sich auf ein Client-Server-Konzept.
-
Die vorliegende Erfindung hat sich vor diesem Hintergrund ergeben.
-
Gemäß der vorliegenden Erfindung ist ein Orchestrierungsmanager vorgesehen, um einen auf Anforderung erfolgenden Fahrzeuginformationsaustausch zwischen mehreren Fahrzeugen und einem fernen Server anzuregen, wobei der Orchestrierungsmanager dafür ausgelegt ist, Datenanforderungen in einer Warteschlange einzureihen, zu priorisieren und zu einem oder mehreren Fahrzeugen zu senden, von dem oder von jedem Fahrzeug empfangene Daten zu verarbeiten und Datenanforderungsantworten zum fernen Server zu übertragen.
-
Der Orchestrierungsmanager kann ferner dafür ausgelegt sein, Informationen mit einem Informationskunden zu teilen. Der Orchestrierungsmanager kann ferner innerhalb der Cloud angeordnet sein.
-
Jedes der mehreren Fahrzeuge kann Folgendes umfassen: mehrere Sensoren zum Erhalten von Daten, welche den Status mindestens eines Parameters des Fahrzeugs angeben, einen Speicher zum Speichern der von dem oder jedem Sensor erhaltenen Daten, einen Prozessor, der dafür ausgelegt ist, zumindest einen Teil der Daten zu verarbeiten und zu analysieren, um Metadaten zu erzeugen, eine oder mehrere Kommunikationsvorrichtungen, die dafür ausgelegt sind, eine Datenanfrage von einem fernen Server zu empfangen, eine Steuereinrichtung, welche dafür ausgelegt ist, Daten oder Metadaten auszuwählen, die geeignet sind, um die Anfrage zu beantworten, und welche ferner dafür ausgelegt ist, die geeignete Kommunikationsvorrichtung zu identifizieren, mit der die Daten oder Metadaten zu senden sind, und auch die Übertragung der Daten zum fernen Server zu planen.
-
Die vorliegende Erfindung bietet gegenüber aktuellen Systemen in der Hinsicht erhebliche Vorteile, dass sie die Daten behandelt, so dass nur die notwendigen Daten oder Metadaten zum fernen Server übertragen werden. Dies verringert erheblich das Volumen der zu übertragenden Daten. Weil ferner einige der Daten verarbeitet werden können, um vor der Übertragung Metadaten zu bilden, können die Daten durch die Verarbeitungsaktivität anonymisiert werden.
-
Beispielsweise kann, statt mehrere GPS-Ortspunkte zum fernen Server zu streamen, die Bordverarbeitung am Fahrzeug die mehreren GPS-Ortspunkte speichern und nur dann, wenn dies vom Server gefordert wird, diese Daten verarbeiten, um die Länge der Fahrt zu berechnen. Aus einer Privatheitsperspektive hat die Bordverarbeitung den erheblichen Vorteil, dass der Server nicht den Ort des Fahrzeugs, sondern nur die Länge der Fahrt erfährt. Die Kommunikation mit dem Server ist auf einer "Mussgewusst-werden"-Basis wirksam, statt ein Standardzustand zu sein.
-
Die vorliegende Erfindung sieht eine Stufenänderung des Ansatzes zur Datenübertragung in der Hinsicht vor, dass die Daten nur ansprechend auf eine Anforderung der Daten übertragen werden. Die Daten, die übertragen werden, können Metadaten sein, die anhand der von den Sensoren bereitgestellten Daten erzeugt werden. Zusätzlich hilft die intelligente Auswahl von Kommunikationsvorrichtungs- und Kompressionsschemata weiter bei der kostenwirksamen Übertragung von Daten.
-
Die Sensoren können einen oder mehrere Verbrennungsmotorparameter messen, einschließlich des Kraftstoffpegels, der prozentualen NOx-Umwandlung, der SCR-Temperatur, der Katalysatortemperatur, des DPF-Filterstatus, des Ölpegels und des Batterieladepegels.
-
Die Sensoren können einen oder mehrere Fahrzeugparameter messen, einschließlich der Fahrzeuggeschwindigkeit, des Fahrzeugorts, der Nähe zu einem benachbarten Fahrzeug und der Umgebungstemperatur in der Nähe des Fahrzeugs.
-
Die Sensoren können einen oder mehrere Benutzerparameter messen, einschließlich der Anzahl der Personen im Fahrzeug, der Radiostation, die im Fahrzeug spielt, des CO-Pegels im Fahrgastraum und der Temperatur im Fahrgastraum.
-
Die Kommunikationsvorrichtungen können aus einer Gruppe ausgewählt werden, welche ein eingebettetes Modem und ein drahtloses lokales Netz in der Art von WiFi einschließt. Falls beispielsweise ein Modem und eine WiFi-Fähigkeit bereitgestellt sind, können die Daten über WiFi bereitgestellt werden, wenn das Fahrzeug zu Hause geparkt ist und mit dem Heim-WiFi verbunden ist. Dies kann beispielsweise dann nützlich sein, wenn sich vom Server angeforderte Daten auf über den Tag zusammengestellte Daten beziehen, so dass, wenn das Fahrzeug nach Hause zurückkehrt, die Daten verarbeitet werden können und ansprechend auf die Anfrage durch den fernen Server über WiFi übermittelt werden können. Diese Datenhandhabung kann auch für Daten geeignet sein, die von der anfordernden Stelle nicht unmittelbar benötigt werden.
-
Die Behandlung von Daten zwischen verschiedenen Kommunikationsvorrichtungen ermöglicht es auch, dass die Kosten in Zusammenhang mit der Datenübertragung wirksam behandelt werden. Die Kosten für das Senden von Daten unter Verwendung des Modems können infolge von Spitzen- und Außerhalb-der-Spitze-Tarifen für die Datenübertragung schwanken. Durch eine Behandlung der Zeitsteuerung sowie der verwendeten Kommunikationsvorrichtung können die Kosten für die Datenübertragung minimiert werden. Falls die Daten beispielsweise zusammengestellt werden können und Anforderungen in einer Warteschlange eingereiht werden können, bis ein Außerhalbder-Spitze-Tarif anwendbar ist, können alle angeforderten Daten oder Metadaten übertragen werden, wenn ein Außerhalb-der-Spitze-Tarif anwendbar ist. Alternativ oder zusätzlich können, falls die Antwort auf die Anfrage vorgehalten werden kann, bis vernünftigerweise erwartet werden kann, dass das Fahrzeug nach Hause zurückkehrt, wo die Datenübertragung über WiFi stattfinden kann, die ansprechend auf Anfragen vom fernen Server verarbeiteten Daten in einer Warteschlange eingereiht werden, bis das Fahrzeug nach Hause zurückkehrt.
-
Das System kann ferner einen Informationszusammenstellungsmanager aufweisen, der dafür ausgelegt sein kann, die von einem oder mehreren Fahrzeugen empfangenen Informationen zu verarbeiten.
-
Das System kann ferner einen Anforderungsprozessor aufweisen, der dafür ausgelegt sein kann, eine zusammengestellte Antwort auf die ursprüngliche Datenanforderung auf der Grundlage der von den Fahrzeugen empfangenen Daten zu berechnen. Der Anforderungsprozessor kann ferner dafür ausgelegt sein, die Anforderung zu analysieren und eine zu einem oder mehreren Fahrzeugen zu sendende Nachricht zu erzeugen.
-
Das System kann ferner einen Flottenmanager und einen Privatheitsmanager aufweisen, die dafür ausgelegt sind, eine Untermenge von Fahrzeugen, welche die Nachricht empfangen sollten, zu bestimmen.
-
Das System kann ferner einen Kommunikationsmanager aufweisen, der dafür ausgelegt ist, die Authentizität einer Datenanforderung zu prüfen.
-
Ferner ist gemäß der vorliegenden Erfindung ein Datenmanager zur Verwendung an einem Fahrzeug vorgesehen, wobei der Datenmanager dafür ausgelegt ist, Folgendes auszuführen: Aufzeichnen von Daten von mehreren Sensoren, lokales Komprimieren und Speichern der Daten am Fahrzeug, lokales Verarbeiten der Daten am Fahrzeug, um Metadaten zu erzeugen, und Bereitstellen (möglicherweise anonymisierter) Metadaten für einen fernen Server ansprechend auf eine Abfrage durch den Server.
-
Der Datenmanager ist insbesondere auf die Privatheit des Fahrzeugbenutzers konzentriert. Während er Anforderungen vom Server empfängt, ist er dafür ausgelegt, zu gewährleisten, dass alle Daten oder Metadaten, die zum Server gesendet werden, mit der Privatheit des Fahrzeugbenutzers vereinbar sind. Beispielsweise könnte der Datenmanager dafür ausgelegt sein, zu gewährleisten, dass der Ort des Fahrzeugs vom fernen Server nicht bestimmt werden kann. Die Verwendung von GPS-Ortsdaten wäre daher auf das Bestimmen der Länge einer Fahrt begrenzt. Alternativ könnte auf die GPS-Ortsdaten selbst zugegriffen werden, wenn festgestellt wird, dass sich das Fahrzeug auf einer Hauptstraße, einer Schnellstraße, einer Fernstraße oder einer Autobahn befindet. Falls festgestellt wird, dass sich das Fahrzeug an einem solchen Ort befindet, können die Ortsdaten des Fahrzeugs durch den Server mit den Ortsdaten von anderen Fahrzeugen zusammengestellt werden, um Verkehrsprobleme auf solchen Straßen zu identifizieren.
-
Der Datenmanager kann sich auch insbesondere auf die Privatheit eines Fahrgasts konzentrieren, das ein Kind oder Kleinkind ist. Es ist anhand der Belegungssensoren, die in Zusammenhang mit Sicherheitsgurterinnerungswarnungen verwendet werden können, ersichtlich, wenn sich ein Kind oder Kleinkind im Fahrzeug befindet. Das Fahrzeug kann eine Anzahl kurzer Fahrten unternehmen, und der Belegungssensor kann nach einer Fahrt angeben, dass ein kindlicher Fahrgast nicht mehr vorhanden ist. Dies wäre beispielsweise damit vereinbar, dass das Kind an einem vom Heim entfernten Ort abgesetzt wurde. Um die Privatheit des Kinds zu schützen, würde der Ort, an dem das Fahrzeug angehalten hat, wenn der kindliche Fahrgast nicht zum Fahrzeug zurückgekehrt ist, nicht zum fernen Server übermittelt werden, weil dies ermöglichen würde, den Ort des Kinds zu bestimmen.
-
Der Datenmanager kann vom Benutzer editierbare Einstellungen aufweisen, welche den Benutzer in die Lage versetzen, "private Zonen" einzurichten. Wenn festgestellt wird, dass sich ein Fahrzeug innerhalb einer "privaten Zone" befindet, kann der Fahrzeugort nicht geteilt werden. Ein Benutzer könnte eine "private Zone" um das Heim, die Schule des Kinds und den Arbeitsplatz des Benutzers oder einen anderen Ort, wo das Fahrzeug gewöhnlich während eines längeren Zeitraums unbeaufsichtigt gelassen wird, einrichten, so dass der Ort des unbeaufsichtigten Fahrzeugs nicht bestimmt werden kann.
-
Der Datenmanager kann den in Bezug auf die Fahrzeuggeschwindigkeit und den Fahrzeugort angeforderten Daten weitere Beschränkungen auferlegen. Der Datenmanager kann dafür ausgelegt sein, zu gewährleisten, dass es die vom Fahrzeug bereitgestellten Daten dem fernen Server nicht erlauben, zu bestimmen, ob das Fahrzeug unter Verletzung der Geschwindigkeitsgrenze auf einem bestimmten Straßenabschnitt gefahren wurde.
-
Es ist wohlbekannt, dass das Smartphone eines Benutzers innerhalb des Fahrzeugs in Bluetooth-Kommunikation mit dem Audiosystem steht. Diese Funktionalität ermöglicht es dem Benutzer, legal am Telefon zu sprechen, wobei der Ton über das Audiosystem des Fahrzeugs geleitet wird. Um diese Funktionalität zu erreichen, kann der Benutzer sein Telefon jedoch über das Fahrzeugaudiosystem steuern. Der Datenmanager kann ferner dafür ausgelegt sein, zu gewährleisten, dass jegliche vom Smartphone des Benutzers eingegebene Daten, wenn es verwendet wird, um Anrufe zu machen, nicht über den Server geleitet werden können. Beispielsweise wären die gewählte Nummer und die Dauer des Anrufs wahrscheinlich innerhalb des Systems bekannt, der Datenmanager kann jedoch dafür ausgelegt sein, zu gewährleisten, dass diese Informationen nicht an den fernen Server übergeben werden können.
-
Ein Server ist dafür ausgelegt, Folgendes auszuführen: Senden von Anfragen zu mehreren Fahrzeugen, Empfangen von Antworten von jedem der Fahrzeuge und Weiterverarbeiten der Daten, um Metadaten bereitzustellen.
-
Der Server kann in der Cloud bereitgestellt werden. Der Server kann durch einen Fahrzeughersteller bereitgestellt werden und auf alle hergestellten und mit dem System ausgerüsteten Fahrzeuge anwendbar sein. Alternativ oder zusätzlich kann der Server durch einen Bereitsteller von Leasingfahrzeugen oder einen Flottenmanager, der Kontrolle über eine Fahrzeugflotte hat, bereitgestellt werden.
-
Jede Anfrage kann so ausgelegt sein, dass sie eine Frist für die Antwort aufweist. Beispielsweise kann es der Server wünschen, Daten zu erhalten und zusammenzustellen, die zur Aktivität einer Fahrzeugflotte an einem gegebenen Tag gehören. Falls eines der Fahrzeuge in der Flotte am relevanten Tag nicht aktiv war, ist die Anforderung für dieses Fahrzeug bedeutungslos. Durch Festlegen einer Frist für die Antwort ist es ersichtlich, welche Fahrzeuge während des relevanten Zeitraums nicht aktiv waren, und kann der Server die geeignet empfangenen Daten verarbeiten, ohne dass er verzögert wird, während er auf Daten von inaktiven Fahrzeugen wartet.
-
Die Bereitstellung einer Frist für eine Antwort ermöglicht es dem System innerhalb des Fahrzeugs auch, die am besten geeignete Kommunikationsvorrichtung für das Senden der Daten und die Zeit für die Übermittlung auszuwählen. Falls die Frist für die Antwort beispielsweise Mitternacht ist, ist es nicht erforderlich, die vergleichsweise kostspielige Modemkommunikation zu verwenden, falls erwartet werden kann, dass das Fahrzeug vor Mitternacht nach Hause zurückkehrt und daher die WiFi-Verbindbarkeit am Heimort ausnutzen kann.
-
Die Erfindung wird nun weiter und eingehender nur als Beispiel und mit Bezug auf die anliegende Zeichnung beschrieben. Es zeigen:
-
die 1A und 1B einen breiten Konzeptüberblick über den aktuellen Ansatz bzw. die vorgeschlagene Strategie,
-
2 ein weiteres Beispiel der vorliegenden Erfindung,
-
3 eine weitere Einzelheit eines angeschlossenen Fahrzeugdaten-Hubs und
-
4 eine weitere Einzelheit eines innerhalb eines Fahrzeugs ausgeführten angeschlossenen Fahrzeugdatenknotens.
-
1A zeigt ein Beispiel eines existierenden Telematikansatzes mit mehreren Fahrzeugen 5, die jeweils mit einem Modem 6 versehen sind. Die Fahrzeuge 5 streamen kontinuierlich am Fahrzeug erzeugte Daten über das Modem 6 zu einem cloudbasierten Datenspeicher 7 in der Cloud 20. Die Cloud 20 weist auch eine Datenverarbeitung 9 auf, welche es ermöglicht, dass die Daten verarbeitet und analysiert werden.
-
1B zeigt ein Beispiel eines verteilten Systems gemäß der vorliegenden Erfindung. Jedes Fahrzeug 10 weist einen lokalen Datenspeicher 12, eine Datenverarbeitungsvorrichtung 14 und eine Kommunikationsvorrichtung 16 auf. Die Daten werden alle in der Datenspeichervorrichtung 12 gespeichert, welche typischerweise ein Speicher ist, der sich innerhalb eines Computers befindet, der die Datenverarbeitungsvorrichtung 14 verwirklicht. Alle Daten werden gespeichert, so dass sie verarbeitet oder in einem späteren Stadium weiter verarbeitet werden können.
-
Durch das Bereitstellen einer Datenverarbeitungsvorrichtung 14 am Fahrzeug wird eine intensivere Verarbeitung von Fahrzeugdaten mit einer hohen Abtastrate ermöglicht. In diesem Zusammenhang kann hoch einschließen, dass Daten mit bis zu einigen 1000 Hz abgetastet werden. Diese lokale Verarbeitung von Fahrzeugdaten mit einer so hohen Abtastrate ermöglicht eine Kompression, Echtzeitanalytik und Rückkopplung, die nicht möglich wären, wenn die gesamte Verarbeitung fern ausgeführt werden müsste, weil die Datenübertragungsrate dies ausschließen würde und die zeitliche Verzögerung beim Erreichen einer Analyse der Daten und einer Rückkopplung zu groß wäre.
-
Durch das Bereitstellen einer Datenverarbeitungsvorrichtung 14 an jedem Fahrzeug 10 wird eine erhebliche Parallelverarbeitung von Daten ermöglicht, weil jedes Fahrzeug Daten gleichzeitig und lokal verarbeitet.
-
An einem fernen, zentralisierten Ort befinden sich ein ferner Server 22 und ein Datenprozessor 24 zusammen mit einem Datenspeicher 26. Dieser zentralisierte Ort befindet sich typischerweise in der Cloud 20. Anders als beim in 1A dargestellten aktuellen System ist das System gemäß der vorliegenden Erfindung für einen Zweiwegeinformationsaustausch zwischen dem fernen Server 22 und den Fahrzeugen 10 ausgelegt.
-
Bei diesem Beispiel beginnt die Kommunikation mit einer Anfrage 30, die vom fernen Server 22 zu den Fahrzeugen 10 gesendet wird. Ansprechend auf diese Anfrage 30 wird eine Antwort 32 vom Fahrzeug 10 zum fernen Server 22 gesendet. Die Antwort 32 weist Daten vom Fahrzeug auf. Diese Daten sind zumindest aus dem am Fahrzeug existierenden Datensatz ausgewählt, oder die Daten wurden wahrscheinlicher am Fahrzeug 10 unter Verwendung der Datenverarbeitungsvorrichtung 14 vorverarbeitet, so dass die in der Antwort 32 gesendeten Daten eine Zusammenstellung oder ein Durchschnitt oder ein berechneter Wert von einem größeren Datensatz sind, der am Fahrzeug 10 gespeichert bleibt. Ein Beispiel ausgewählter Daten ist die maximale Temperatur eines Kühlmittels. Ein Beispiel verarbeiteter Daten ist die gefahrene Gesamtstrecke, welche anhand eines Stroms von GPS-Positionsdaten berechnet wird, die in vorgegebenen Intervallen während des Tags aufgezeichnet werden.
-
Weil innerhalb des Fahrzeugs 10 ein lokaler Datenspeicher 12 bereitgestellt ist, ist es nicht erforderlich, dass alle Daten zur Speicherung zur Cloud 20 übertragen werden. Daher sind die einzigen Daten, die übertragen werden, jene, die vom fernen Server 22 angefordert werden. Dies bedeutet, dass erheblich weniger Daten übertragen werden.
-
2 zeigt weitere Einzelheiten des Systems am Fahrzeug 10 und auch des angeschlossenen Daten-Hubs, der sich an der Cloud 20 befindet. Das Fahrzeug 10 weist den Datenspeicher 12, die Datenverarbeitungsvorrichtung 14 und die Kommunikationsvorrichtung 16 auf. Die Kommunikation zwischen diesen Einheiten wird durch einen angeschlossenen Fahrzeugagenten oder Datenmanager 40 unterstützt, der als Vermittler für das Empfangen und Interpretieren von Anfragen vom fernen Server, welcher sich in der Cloud 20 befindet, wirkt. Der Datenmanager 40 steuert auch die Auswahl von Daten vom Fahrzeug zur Übermittlung zum fernen Server 22 in Form einer Antwort 32.
-
Der Datenmanager 40 kann auch Fahrerprivatheitsprobleme behandeln, indem er die Daten untersucht, die angefordert und zum fernen Server 22 übermittelt werden. Weil der größte Teil der vom Fahrzeug 10 aufgezeichneten Daten am Fahrzeug gespeichert wird, ist die Standardposition dadurch gegeben, dass keine persönlichen Daten zum fernen Server 22 übertragen werden. Der ferne Server 22 kann Anforderungen machen, welche der Datenmanager 40 als eine Bedrohung für die Privatheit des Benutzers interpretiert. In diesem Fall kann der Datenmanager 40 nur eine Teilantwort auf die Anfrage 30 senden oder eine alternative Anfrage fordern, falls das Beantworten der Anfrage 30 in ihrer ursprünglichen Form die Privatheit des Benutzers gefährden würde.
-
Die Daten werden von den Sensoren über einen Fahrzeugbus 42 empfangen, der mit verschiedenen ECU kommuniziert, die wiederum mit Sensoren (nicht dargestellt) verbunden sind, welche die Bedingungen an verschiedenen Teilen des Verbrennungsmotors, des Fahrgastraums und des Fahrzeugs insgesamt erfassen. Die erfassten Bedingungen umfassen unter anderem die Temperatur, den Druck, eine vorhandene Gaszusammensetzung, den Fahrzeugort, die Geschwindigkeit und den Kraftstoffpegel. Jede ECU kann dafür ausgelegt sein, Daten von einem bestimmten Gebiet des Fahrzeugs zu behandeln. Innerhalb jedes Gebiets können verschiedene Parameter erfasst werden. Beispielsweise kann die ECU1 den DPF behandeln und von einem Drucksensor, der den Staudruck durch den DPF identifiziert, empfangene Daten, die Temperatur des DPF und das Teilchenniveau im durch den DPF hindurchtretenden Abgas behandeln.
-
Der ferne Server 22 empfängt Daten vom Fahrzeug 10 und speichert diese Daten innerhalb des Datenspeichers 26. Der ferne Server 22 wirkt als ein Orchestrierungsmanager, welcher den Auf-Anforderung-Fahrzeuginformationsaustausch anregt. Zusätzlich ist der Orchestrierungsmanager mit einem Informationszusammenstellungsmanager 28 verbunden, der als Datenprozessor 24 wirkt, welcher auf die von einem oder mehreren Fahrzeugen empfangenen Informationen einwirkt.
-
Zusätzlich zur Kommunikation zwischen dem fernen Server 22 und den Fahrzeugen 10 können Informationen auch einem Informationskunden 50 zur Verfügung gestellt werden.
-
3 zeigt eine weitere Einzelheit eines angeschlossenen Fahrzeugdaten-Hubs 60, und 4 zeigt eine weitere Einzelheit eines innerhalb eines Fahrzeugs 10 ausgeführten angeschlossenen Fahrzeugdatenknotens 70. Bezugszahlen für mit Bezug auf die vorhergehenden Figuren beschriebene Einheiten werden aus Gründen der Klarheit beibehalten.
-
3 zeigt die verschiedenen Teile des angeschlossenen Fahrzeugdaten-Hubs 60, der sich typischerweise innerhalb der Cloud 20 befindet. Es ist eine Kommunikation über das Netz 100 bereitgestellt. Diese Kommunikation wird durch einen Kommunikationsmanager 21 gesteuert, der wiederum mit dem Orchestrierungsmanager 22 und einem Anforderungsprozessor 23 kommuniziert. Der Anforderungsprozessor 23 kommuniziert mit einem Flottenmanager 25, einem Privatheitsmanager 27, einem Fahrzeugdatenaustauschsprachprozessor 29 und einem Softwaremanager 31. Ein Sicherheitsmanager 33 ist bereitgestellt, um alle Kommunikationsebenen innerhalb des angeschlossenen Fahrzeugdaten-Hubs 60 zu überlagern.
-
Die Funktionen dieser verschiedenen Einheiten werden nachstehend dargelegt: Der Kommunikationsmanager 21 ist dafür verantwortlich, Nachrichten zum Knoten 70, der sich an einem Fahrzeug 10 befindet, zu senden und davon zu empfangen. Der Orchestrierungsmanager 22 ist dafür verantwortlich, Datenanforderungen 30 für ein oder mehrere Fahrzeuge 10 innerhalb einer Fahrzeugflotte in einer Warteschlange einzureihen, zu priorisieren und zu senden. Zusätzlich ist der Orchestrierungsmanager 22 dafür verantwortlich, von angeschlossenen Fahrzeugdaten-(CVD)-Knoten 70 empfangene Daten zu verarbeiten und Datenanforderungsantworten zu übermitteln. Der Anforderungsprozessor 23 ist für die Ausführung einer Datenanforderung oder -anfrage 30 verantwortlich. Der Fahrzeugdatenanalytik- und -zusammenstellungsmanager 28 ist für das Ausführen einer Analytik an einem Satz von Datennachrichten, die von CVD-Knoten 70 zurückgegeben werden, auf der Grundlage einer gegebenen Datenanforderung verantwortlich. Der Fahrzeugdatenaustauschsprachprozessor 29 ist für das Erzeugen von Fahrzeugdatenanforderungen und für das Erzeugen von Anforderungen für den Fahrzeugdatenanalytik- und -zusammenstellungsmanager 28 verantwortlich.
-
Zusätzlich unterhält der Flottenmanager 25 eine Liste aller beim angeschlossenen Fahrzeugdaten-Hub 60 registrierten Fahrzeuge 10, unterhält Privatheitseinstellungen für jedes Fahrzeug 10 und bestimmt den Fahrzeugbereich für eine gegebene Datenanforderung oder -anfrage 30. Der Privatheitsmanager 27 sammelt Privatheitseinstellungen aller CVD-Knoten 70 und stellt eine Liste von Fahrzeugen 10 bereit, welche eine gegebene Datenanforderung oder -anfrage 30 empfangen können. Der Sicherheitsmanager 33 ist für die Nachrichtensicherheit, nämlich die Verschlüsselung, Autorisierung und Authentifizierung übermittelter Daten, verantwortlich. Der Sicherheitsmanager 33 ist auch für die Datensicherheit verantwortlich, nämlich für die Verschlüsselung von Daten in Ruhe. Ferner ist der Sicherheitsmanager dafür ausgelegt, die Betriebssicherheit zu verwalten, beispielsweise DDoS-Angriffe. Der Softwaremanager 31 ist für Firmware-, Betriebssystem-, Konfigurations- und Softwaremodulaktualisierungen, die zu CVD-Knoten 70 gesendet werden, verantwortlich.
-
4 zeigt die verschiedenen Teile des angeschlossenen Fahrzeugdatenknotens 70, die innerhalb eines Fahrzeugs 10 ausgeführt werden. Es ist eine Kommunikation über das Netz 100 bereitgestellt. Diese Kommunikation findet über ein Fahrzeugmodem 16 oder eine andere Kommunikationsvorrichtung statt. Die Kommunikation wird durch einen Fahrzeugkommunikationsmanager 41 gesteuert, der wiederum mit einem Fahrzeugorchestrierungsmanager 43 kommuniziert. Der Fahrzeugorchestrierungsmanager 43 kommuniziert mit dem Datenspeicher 12, einem Privatheitsmanager 44, einem Fahrzeugdatenaustauschsprachprozessor 45, einem Fahrzeugdatenanalytik- und -berechnungsmanager 46 und einem Softwaremanager 47. Die wirksame Funktionsweise des Datenspeichers 12 wird durch das Bereitstellen eines kontextbasierten Datenkompressionsmanagers 13 komplementiert. Daten werden vom CAN-Bus 42 erhalten, und diese Daten werden im CAN-Datensemantikprozessor 14 verarbeitet. Ein Sicherheitsmanager 48 ist bereitgestellt, um alle Kommunikationsebenen innerhalb des Fahrzeugdatenknotens 70 zu überlagern.
-
Der Knoten 70 arbeitet, wenn der CAN-Datensemantikprozessor 14 Basisnachrichten vom CAN-Bus 42 sammelt und sie unter Verwendung des Vokabulars und Wörterbuchs im Fahrzeugdatenaustauschsprachprozessor 45 in Name-Werte-Paare übersetzt. Die übersetzten Tupel werden dann zur Verarbeitung und lokalen Speicherung innerhalb des Datenspeichers 12 zum kontextbasierten Datenkompressionsmanager 13 gesendet. Die Fahrzeugmetadaten werden zusammen mit den Basisdaten innerhalb des Datenspeichers 12 gesammelt und gespeichert.
-
Die Funktionen dieser verschiedenen Einheiten werden nachstehend dargelegt: Der Fahrzeugkommunikationsmanager 41 behandelt die Fahrzeugnetzschnittstelle und die Mobilfunkdatenvolumina auf der Grundlage einer Nachrichtenpriorität, d.h. einer sofortigen Übermittlung durch Mobilkommunikation oder einer verzögerten Übermittlung durch WiFi, wenn sich das Fahrzeug an einer geeigneten WiFi-Stelle befindet. Der Fahrzeugkommunikationsmanager 41 ist auch für das Senden einer Nachricht zum Hub 60 und das Empfangen einer Nachricht davon und auch für das Senden von Fahrzeugmetadaten/eines Herzschlags zum Hub 60 verantwortlich (diese Operation wird nachstehend in weiteren Einzelheiten beschrieben). Der Fahrzeugorchestrierungsmanager 43 ist dafür verantwortlich, eingehende Datenanforderungen oder -anfragen 30 in einer Warteschlange einzureihen und zu verarbeiten und eine Kommunikation zwischen getrennten Vorrichtungsmodulen zu behandeln. Der Fahrzeugdatenanalytik- und -berechnungsmanager 46 ist für alle an Fahrzeugdaten ausgeführten Berechnungen verantwortlich und in der Lage, ein dynamisches Scripting auszuführen, das in der Datenanforderung oder -anfrage 30 enthalten ist. Der Fahrzeugdatenaustauschsprachprozessor ist dafür verantwortlich, Fahrzeugdatenanforderungen zu interpretieren und eine Anforderung an den Fahrzeugdatenanalytik- und -berechnungsmanager 46 zu erzeugen.
-
Der kontextbasierte Datenkompressions- und Speichermanager 13 führt eine kontextbasierte Datenkompression aus, um die Speicherverwendung zu maximieren, und er behält Fahrzeugmetadaten bei. Er ist auch für die Fahrzeugdatenarchivierung verantwortlich. Der Privatheitsmanager 44 gibt dem Fahrzeugeigentümer die Fähigkeit, ein persönliches Privatheitsfilter festzulegen (welche Datenelemente gesammelt werden können), und auch die Fähigkeit, Datenelementebenen festzulegen (auf welcher Ebene Daten gesammelt werden können (Rohdaten gegenüber zusammengestellten Daten)). Der CAN-Datensemantikprozessor 14 behandelt die CAN-BUS-Schnittstelle und übersetzt CAN-Daten in vereinheitlichte Fahrzeugdateneinheiten. Der Sicherheitsmanager 48 ist für die Nachrichtensicherheit, nämlich die Verschlüsselung, Autorisierung und Authentifizierung übermittelter Daten, verantwortlich. Der Sicherheitsmanager 48 ist auch für die Datensicherheit verantwortlich, nämlich für die Verschlüsselung von Daten in Ruhe. Zusätzlich behandelt der Sicherheitsmanager 48 die Betriebssicherheit (DDoS-Angriffe usw.). Der Softwaremanager 47 ist für Firmware-, Betriebssystem- und Softwaremodulaktualisierungen über das Netz 100 verantwortlich.
-
Zusätzlich zu durch eine Anfrage vom Hub 60 angeregten Kommunikationen können Fahrzeugmetadaten und "Herzschlag"-Daten vom Fahrzeug 10 zum Hub 60 übermittelt werden. Diese Kommunikation findet bei einer vorgegebenen Kadenz statt und kann Änderungen der Privatheitsrichtlinie, des allgemeinen geographischen Orts und der Fahrteigenschaften, Fahrzeugkommunikationsdiagnostik und Fahrzeugstatusdaten einschließen. Diese Informationen werden vom Fahrzeugdaten-Hub verwendet, um Fahrzeugflottendaten beizubehalten.
-
Die Schritte, welche eine Fahrzeugdaten-Hub-Datenanforderung bilden, sind die folgenden:
- Schritt 1 – Der Fahrzeugdaten-Hub 60 empfängt eine Datenanforderung
– Wenn der angeschlossene Fahrzeugdaten-Hub 60 eine Datenanforderung empfängt (beispielsweise "Was war letzten Monat die durchschnittliche Geschwindigkeit von Fahrzeugen in Wayne County?"), prüft der Kommunikationsmanager 21 die Nachrichtenauthentizität und leitet sie zum Orchestrierungsmanager 22 weiter.
– Der Orchestrierungsmanager 22 bestimmt den Typ und die Priorität der Anforderung und gibt sie in die geeignete Anforderungswarteschlange. Wenn die Anforderung für die Ausführung bereit ist, verwendet der Anforderungsprozessor 23 den Fahrzeugdatenaustauschsprachprozessor 29 für das Analysieren der Anforderung und das Erzeugen einer Nachricht, die zu individuellen angeschlossenen Fahrzeugdatenknoten 70 zu senden ist.
– Der Flottenmanager 25 und der Privatheitsmanager 27 bestimmen eine Untergruppe der Fahrzeuge 10, welche die neue Nachricht empfangen sollten, und der Orchestrierungsmanager 22 fordert dann den Kommunikationsmanager 21 auf, die Nachrichten abzusenden.
- Schritt 2 – Der Fahrzeugdatenknoten 70 empfängt eine Datenanforderung
– Wenn ein individueller angeschlossener Fahrzeugdatenknoten 70 eine Nachricht vom Hub 60 empfängt, prüft der Fahrzeugkommunikationsmanager 41 die Nachrichtenauthentizität und leitet sie zum Fahrzeugorchestrierungsmanager 43 weiter.
– Der Fahrzeugorchestrierungsmanager 43 verwendet den Fahrzeugdatenaustauschsprachprozessor 45 in Zusammenhang mit dem Analytik- und Berechnungsmanager 46, um die angeforderte Operation entsprechend der vom Privatheitsmanager 44 bereitgestellten Privatheitsrichtlinie auszuführen.
– Der lokale Datenspeicher 12 wird verwendet, um angeforderte Ergebnisse zu berechnen. Die Rückkehrnachricht 32 wird für die Verarbeitung zum angeschlossenen Fahrzeugdaten-Hub 60 zurückgesendet.
- Schritt 3 – Der Fahrzeugdaten-Hub 60 empfängt ein individuelles Datenergebnis von einem Fahrzeug 10
– Der angeschlossene Fahrzeugdaten-Hub 60 sammelt alle für eine gegebene Datenanforderung 30 zurückgegebenen Nachrichten.
– Sobald alle ausgesendeten Nachrichten zurückgegeben wurden oder ein vordefinierter Zeitablauf erreicht wurde, verwendet der Anforderungsprozessor 23 den Fahrzeugdatenanalytik- und -rechenmanager 28 zum Berechnen einer zusammengestellten Antwort auf die ursprüngliche Datenanforderung. Diese zweite Datenzusammenstellung ist wichtig, weil sie es ermöglicht, die ursprüngliche Anfrage mit einer einzigen Antwort statt einer Fahrzeug-für-Fahrzeug-Antwort zu beantworten. Dies ermöglicht es auch, die Daten wirksam zu anonymisieren, weil jede Facette der Daten, die verwendet werden könnte, um die Quelle der Daten zu identifizieren, an dieser Stufe entfernt werden kann.
-
Als ein Beispiel der vorstehenden drei Schritte sei bemerkt, dass, falls die vom Daten-Hub empfangene Anforderung "Wie viele Fahrzeuge hatten eine durchschnittliche Fahrtlänge von weniger als 5 Meilen?" ist, der Orchestrierungsmanager 22 eine Anfrage "Was ist ihre durchschnittliche Fahrtlänge?" formulieren kann. Der Orchestrierungsmanager 22 könnte diese an alle Fahrzeuge senden, falls einige Fahrzeuge innerhalb der Flotte jedoch auf Langstreckenüberführungen spezialisiert sind, kann es als unnötig angesehen werden, diese Fahrzeuge aufzurufen. Die Anforderung kann daher zu einer Untergruppe von Fahrzeugen gesendet werden.
-
Beim Empfang dieser Anfrage verwendet der Fahrzeugorchestrierungsmanager 43 den Fahrzeugdatenaustauschsprachprozessor 45, um eine erste Datenzusammenstellung auszuführen, wobei er die Länge jeder Fahrt auf der Grundlage individueller GPS-Koordinaten des Fahrzeugs über die Zeit berechnet. Diese jeweiligen Fahrten können dann zusammengestellt werden, um die durchschnittliche Fahrtstrecke zu berechnen. Der Privatheitsmanager 44 gewährleistet, dass es keine verbleibende GPS-Spur gibt, welche den tatsächlichen Ort des Fahrzeugs zu einer Zeit identifiziert. Zeitstempel können auch entfernt werden, um zu verhindern, dass die Geschwindigkeit des Fahrzeugs anhand der Daten festgestellt wird.
-
Wenn das Fahrzeug durch ein geeignetes Kommunikationsmittel mit dem Daten-Hub 60 verbunden wird, wird ansprechend darauf eine Nachricht gesendet. Ein Beispiel hierfür kann "Fahrzeug x hat eine durchschnittliche Fahrtlänge von 10,5 Meilen" sein.
-
Wenn alle Antworten von den ausgewählten Fahrzeugen empfangen wurden oder ein vorgegebener Zeitablauf erreicht wird, wodurch nahe gelegt wird, dass bestimmte Fahrzeuge zu einer Zeit innerhalb des für das Bereitstellen einer Antwort erlaubten Zeitraums nicht geeignet verbunden wurden, stellt der Anforderungsprozessor 23 die Daten zusammen, wobei er ein binäres Lesen für jede Fahrzeugantwort auswählt: d.h. eine 1 für eine durchschnittliche Fahrtlänge von weniger als 5 Meilen und eine 0 für eine durchschnittliche Fahrtlänge von mehr als 5 Meilen. Der Anforderungsprozessor addiert alle Fahrzeuge, die eine durchschnittliche Fahrtlänge von weniger als 5 Meilen angeben, beispielsweise 327 Fahrzeuge. Die Antwort, die auf die ursprüngliche Anfrage gegeben wird, ist einfach "327".
-
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
-
- US 2014/380264 [0006]
- US 2009/170537 [0007]
- US 2006/253235 [0008]
- US 2013/274950 [0009]
