DE102022117926A1

DE102022117926A1 - Verfahren, system sowie computerprogramm betreffend eine fahrzeug-daten-infrastruktur

Info

Publication number: DE102022117926A1
Application number: DE102022117926.5A
Authority: DE
Inventors: Alexander Augst
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2022-07-18
Filing date: 2022-07-18
Publication date: 2024-01-18

Abstract

Die Erfindung betrifft ein Verfahren, System sowie Computerprogramm im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen (F1, F2). Beispiele betreffen ein Verfahren (10) im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen (F1, F2). Das Verfahren (10) umfasst die Schritte:- Erzeugen und/oder Versenden (11) von Referenz-Datenpaketen (22a, 22b) in einem oder mehreren Fahrzeugen (F1, F2);- Auswerten (12) der in einem Backend ankommenden Referenz-Datenpakete (22a, 22b) und abhängig von dem Auswerten (12):- ein Rückschluss (13a) betreffend Nutz-Datenpakete (21); und/oder- ein Rückschluss (13b) auf eine abhängig von Nutz-Datenpaketen (21) betriebene Funktionalität.

Description

Technisches Gebiet
Ausführungsbeispiele betreffen ein Verfahren im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen. Weitere Beispiele betreffen ein Computerprogramm mit Programmcode zum Ausführen des Verfahrens und ein System zum Sammeln und/oder Verarbeiten von Daten aus Fahrzeugen in einem Backend.
Hintergrund
In modernen Kraftfahrzeugen werden mit zunehmender Digitalisierung der Fahrzeugausstattung sowie verbesserter Konnektivität des Fahrzeugs mit der Außenwelt (z.B. via Mobilfunknetze) immer mehr Daten generiert und in Echtzeit versendet. Die Verfügbarkeit dieser Daten kann wesentlichen Einfluss auf die Funktionalität von Fahrzeugfunktionen, z.B. im Bereich des autonomen Fahrens, haben.
Das Erfassen von Daten und/oder Generierung von (entsprechenden) Datenpaketen innerhalb des Fahrzeugs durch die entsprechenden Daten-Clients wird jedoch immer dann unterbrochen, wenn das Steuergerät in die Nähe seiner Ressourcengrenzen kommt. Dies betrifft vor allem Steuergeräte, die Nutzerfunktionen ausführen. In kritischen Fällen degradiert also die Fahrzeugdateninfrastruktur, insbesondere die Clients, zu Gunsten der Funktion. Mit anderen Worten wird die Ausführung der Funktion gegenüber der Generierung von Daten priorisiert. Dadurch fehlen im Ergebnis teilweise genau die Daten, die besonders wichtig sind.
Das Versenden der Daten aus dem Fahrzeug erfolgt nach dem Prinzip FAF (= Fire and Forget). Die Datenpakete nehmen einen sehr komplexen Weg über einen Zwischenspeicher, Telematik des Fahrzeugs, Mobilfunk, diverse Hubs sowie Backendinfrastruktur. Es kann zu einem Datenverlustkommen. Es kann unbekannt sein, an welcher Stelle der Übertragungsstrecke die Daten verloren gehen.
Dies kann je nach Zustand entsprechender Steuergeräte jeweiliger Fahrzeuge, Land, Gebiet, allgemeinen Empfang, Auslastung des Mobilfunknetzes, IT-Infrastruktur, jeweils aktueller Dienstleisterverträge sowie auch zufällig stark variieren. Im Endeffekt ist im Backend faktisch nicht bekannt, ob und was hinsichtlich generierter Daten aus dem Fahrzeug gesendet worden ist und wie viel ggf. nicht angekommen ist.
Ein bestätigungsbasiertes Verfahren auf der Nachrichtenübertragungsebene würde einen entsprechenden Rückkanal notwendig machen. Die Etablierung eines solchen Rückkanals würde hohe Investitionen und langjährige Entwicklungszeit nach sich ziehen.
Zusammenfassung
Es ist eine Aufgabe der vorliegenden Offenbarung, verbesserte Konzepte für ein Verfahren, System sowie Computerprogramm zu einer effektiven, kosteneffizienten sowie zeitnah umsetzbaren Weiterentwicklung einer Fahrzeugdateninfrastruktur bereitzustellen.
Die Aufgabe wird durch die Merkmale der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen, der folgenden Beschreibung sowie in Verbindung mit den Figuren beschrieben. Es wird darauf hingewiesen, dass zusätzliche Merkmale eines von einem unabhängigen Patentanspruch abhängigen Patentanspruchs ohne die Merkmale des unabhängigen Patentanspruchs oder nur in Kombination mit einer Teilmenge der Merkmale des unabhängigen Patentanspruchs eine eigene und von der Kombination sämtlicher Merkmale des unabhängigen Patentanspruchs unabhängige Erfindung bilden können, die zum Gegenstand eines unabhängigen Anspruchs, einer Teilungsanmeldung oder einer Nachanmeldung gemacht werden kann. Dies gilt in gleicher Weise für in der Beschreibung beschriebene technische Lehren, die eine von den Merkmalen der unabhängigen Patentansprüche unabhängige Erfindung bilden können.
Gemäß eines ersten Aspekts der Erfindung wird ein Verfahren im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen vorgeschlagen. Das Verfahren im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen kann ein Verfahren zum Sammeln und/oder Verarbeiten der Daten aus Fahrzeugen und/oder Verfahren das das Sammeln von Daten unterstützt umfassen oder sein. Verfahrensgemäß erfolgt ein Erzeugen und/oder Versenden von Referenz-Datenpaketen in einem oder mehreren Fahrzeugen. Ferner erfolgt eine Auswertung der im Backend ankommenden Referenz-Datenpakete. Abhängig von der Auswertung (d.h. insbesondere von dem Ergebnis der Auswertung) erfolgt ein Rückschluss betreffend Nutz-Datenpakete und/oder ein Rückschluss auf eine abhängig von solchen Nutz-Datenpaketen betreibbare, insbesondere betriebene Funktionalität.
Der Begriff „Nutz-Datenpakete“ bedeutet im Rahmen des vorliegenden Dokuments Datenpakete die jeweils die Nutzdaten bzw. einen Teil der Nutzdaten umfassen bzw. repräsentieren.
Die Nutzdaten können: z.B. ausgewählte Signalwerte aus einem Steuergerät und/oder Sensor des Fahrzeugs und/oder auf Basis dieser berechnete, für einen bestimmten Zweck zu sammelnde umfassen oder sein. Die Nutzdaten können Daten für eine Datenanalyse, z.B. Systemanalyse und/oder Funktionsanalyse und/oder Verhaltensanalyse genutzt werden, etwa wie häufig bestimmte Funktionen von Nutzern ausgeführt (z.B. effektiv genutzt, nicht genutzt bzw. magenhaft oder fehlerhaft bedient) werden oder mit welcher Performance bestimmte Funktionen ausgeführt werden können (Funktionsperformance, Analyse von Key-Performance-Indikatoren). Dabei können diverse Daten aus dem Fahrzeug betreffend Nutzung (auch Bedienvorgänge) des Fahrzeugs, Zustand sowie Funktionsfähigkeit diverser Systeme, Qualitätssicherung sowie für das sogenannte datengestützte Entwicklung bzw. Data Driven Development gesammelt (auch zu verstehen erfasst) werden. Das Sammeln, insbesondere Erfassen der Daten, insbesondere jeweils bestimmter oder bestimmten Kriterien entsprechender Daten kann aus einem Backend veranlasst werden.
Der Begriff „Referenz-Datenpakete“ bezeichnet hingegen, insbesondere im Verfahren erzeugte (auch zu verstehen: erstellte, generierte, verwendete) Daten, insbesondere von Nutzdaten abweichende Daten. Diese müssen keine Nutzdaten umfassen bzw. können (z.B. überwiegend) Daten umfassen, die von den Nutzdaten abweichen. Es kann sich um bei und/oder zur Ausführung des Verfahrens (speziell) erzeugte und/oder verwendete Daten handeln. In einem vereinfachten Fall können dies an sich wertlose und/oder nicht direkt für einen oder mehrere (z.B. oben aufgezählte Zwecke) verwertbare Datenabschnitte (sozusagen ein Datenballast) umfassen oder sein.
Bei der abhängig von Nutzdaten betreibbare, insbesondere betriebenen Funktionalität kann es sich um eine Funktionalität handeln, die (im Betrieb bzw. Betriebszustand) abhängig von den Nutzdaten betrieben, insbesondere gesteuert wird. Insbesondere kann es sich um die Funktionalität handeln, bei der ein wesentlicher Anteil der Funktionalität abhängig von den gesammelten Nutzdaten (d.h. mittels eines oder mehreren Nutz-Datenpaketen übertragenen Daten) ausführbar sind, insbesondere ausgeführt werden. Insbesondere muss die Funktionalität zum Zeitpunkt des Sammelns der Daten nicht unbedingt in Betrieb bzw. in einer aktiven Ausführung sein.
Insbesondere kann abhängig von dem Rückschluss über die Aktivierbarkeit, Aktivierung, Deaktivierung und/oder Veränderung, insbesondere Einschränkung der von den Nutzdaten betreibbaren Funktionalität entschieden werden bzw. die Aktivierbarkeit, Aktivierung, Deaktivierung und/oder Veränderung, insbesondere Einschränkung der von den Nutzdaten betreibbaren Funktionalität kann abhängig von dem Rückschluss (automatisch) bewirkt werden.
Das Erzeugen und/oder Versenden von Referenz-Datenpaketen kann z.B. bevorzugt in Abhängigkeit von einem Fahrzeugparameter erfolgen. Dadurch ist eine besonders kontrollierte Generierung von Referenz-Datenpaketen möglich, sodass diese z.B. in bestimmten Fahrsituationen, an bestimmten Geopositionen und/oder zu bestimmten Zeitpunkten erfolgen kann. Der Fahrzeugparameter kann dabei z.B. mittels Sensoren oder Einstellungen am Fahrzeug ermittelt werden. Ein Referenzdatenpaket braucht nicht notwendigerweise einen Informationsinhalt, lediglich eine Zuordnung zum sendenden Fahrzeug kann erforderlich sein. Dadurch kann der Mehraufwand des Verfahrens bezüglich vom Fahrzeug zu sendender Daten sehr gering gehalten werden.
Die Auswertung der am Backend empfangenen Referenz-Datenpakete kann auf vielfältige Weise erfolgen. Beispielsweise kann vor dem Senden der Referenz-Datenpakete bekannt sein bzw. vereinbart, nach welchem Muster und/oder gemäß welcher Regel die Referenz-Datenpakete gesendet werden. Dann kann ein Vergleich am Backend erfolgen, ob alle zu erwartenden Referenz-Datenpaketen ankommen oder ob teilweise Referenz-Datenpaketen fehlen, wodurch ein Datenverlust erkannt werden kann. Alternativ kann in den Referenz-Datenpaketen selbst eine Nutzinformation mitgesendet werden, die erkennen lässt, ob in einer Reihe von Referenz-Datenpaketen einzelne Pakete fehlen oder nicht (z.B. durch Verwendung eines Zählers als Nutzinformation). Zum Beispiel kann ein Vergleich mit einer erwarteten Anzahl an Referenz-Datenpaketen innerhalb einer vorbestimmten Zeitdauer erfolgen. Wenn innerhalb der vorbestimmten Zeitdauer weniger Referenz-Datenpaketen als erwartet am Backend empfangen wurden kann ein Datenverlust vorteilhafterweise quantitativ beziffert werden (z.B. bei 99 empfangenen Referenz-Datenpaketen statt 100 erwarteten Referenz-Datenpaketen ein Datenverlust von 1 %). Die Anzahl an erwarteten Referenz-Datenpaketen pro Zeiteinheit kann zum Beispiel von einer aktuellen Geschwindigkeit des Fahrzeugs abhängen, sodass bei höheren Geschwindigkeiten Referenz-Datenpaketen mit höherer Frequenz gesendet werden. Dadurch kann eine räumliche Auflösung möglicher Datenverluste genauer möglich sein.
Basierend auf der Auswertung der empfangenen Referenz-Datenpaketen wird ein Rückschluss (erfolgt ein Rückschließen hinsichtlich der) auf die Übertragung von Nutzdaten, wobei der entsprechende Rückschluss Nutz-Datenpakete betreffen kann und/oder eine von diesen abhängige Funktionalitäten betreffen kann. Hinsichtlich der Nutzdatenpakete kann von einer Übertragungsqualität das Referenz-Datenpaket auf eine Übertragungsqualität der Nutzdatenpakete rückgeschlossen werden.
In einem vereinfachten Beispiel kann bei einem Datenverlust von 1 % bei den Referenz-Datenpaketen entsprechend ein zu erwartender Datenverlust von 1 % auch bei den Nutzdatenpaketen angenommen werden. Da einzelne Funktionen in Bezug auf ihre Ausführbarkeit oder Funktionalität von den Informationen der Nutzdatenpakete abhängen, kann alternativ oder zusätzlich auch auf diese Funktionen (z.B. Fahrzeugfunktion) rückgeschlossen werden.
Beispielsweise kann eine Verfügbarkeit der Funktion in Abhängigkeit der analysierten Datenübertragungsqualität, Datenübertragungsgeschwindigkeit, Datenfehler, Datenverlust, in Bezug auf die Referenz-Datenpakete ermittelt werden. Beispielsweise können manche Funktionen auch (z.B. weniger genau) ausgeführt werden oder können zu unerwünschten Ereignissen bzw. Zuständen führen, selbst wenn ein gewisser Datenverlust auftritt.
Durch die Möglichkeit der quantitativen Analyse bezüglich der Referenz-Datenpaketen kann somit ermittelt werden, ob und inwiefern von einer hinreichenden, Verfügbarkeit, Fehlerfreiheit und/oder Performance (vereinfacht: Funktionstüchtigkeit) der jeweiligen (von den Nutzdaten abhängigen) Funktion ausgegangen werden kann. Beispielsweise kann diese Information genutzt werden, um bestimmte Funktionen gar nicht oder nur beschränkt und/oder in einem veränderten Funktionsumfang auszuführen, wenn von einer nicht ausreichenden Datenübertragungsqualität bzw. von zu hohen Datenverlusten ausgegangen werden muss. Dies wird vorteilhafterweise ermöglicht, da verfahrensgemäß eine qualitative und/oder quantitative Information über Datenverlust erlangt werden kann. Bevorzugt kann der Rückschluss in Echtzeit erfolgen oder auch zeit- und/oder ortsabhängig erfolgen, sodass präzise prädiktive Aussagen bezüglich einer Ausführbarkeit der Funktion möglich sein können.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass der Rückschluss betreffend Nutz-Datenpakete kennzeichnend ist für eine Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit, die insbesondere als eine zeitliche und/oder räumliche Funktion dargestellt werden kann. Dabei kann es sich bei der Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit um einen qualitativen und/oder quantitativen Rückschluss handeln. Ein solcher Rückschluss kann z.B. die Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit in klein (z.B. feingranularen) Stufen oder weitgehen stufenlos kennzeichnen. Die Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit können beispielsweise auch als Funktion eines weiteren Parameters sein. Beispielsweise kann der Rückschluss (Ergebnis des Rückschlusses) die Abhängigkeit des Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit von einem fahrzeugspezifischen Parameter und/oder Positionsparameter (z.B. Geo-Position und/oder relative Position).
Die zeitliche und/oder räumliche Funktion kann z.B. eine relative Veränderung betreffen, z.B. einen Anstieg des Datenverlustes (z.B. während eines Überholmanövers des Fahrzeugs, da in diesem Fall z.B. ein Steuergerät überlastet sein kann und entsprechend das Senden von Nutzdatenpaketen zugunsten der Ausführung lokaler Fahrzeugfunktionen eingestellt werden kann). Beispielsweise kann ein steigender Datenverlust innerhalb einer Zeitdauer ermittelt werden (z.B. höhere Datenverlustwahrscheinlichkeit während Rush-Hour kann auf Überlastung des Mobilfunknetzes statt auf Überlastung von fahrzeuginternen Steuergeräten hinweisen). Es kann ein räumliches und/oder zeitliches Gradient beim Rückschluss auf die Nutzdatenpakete und/oder die von diesen betroffenen Funktionen einbezogen werden.
Beispielsweise kann unter dem Rückschluss auch ein Ergebnis einer Aggregation aus einer Vielzahl von Rückschlüssen (z.B. basierend auf demselben Fahrzeug oder auf mehreren Fahrzeugen) aufgefasst werden. Diese können dann z.B. ein Resultat der statistischen Auswertung sein und/oder für Prädiktionen in Bezug auf ein oder mehrere Zeitintervalle in der Zukunft verwendet werden. Beispielsweise erfolgt abhängig von der der Auswertung der Referenz-Datenpakete: - ein Rückschluss auf die Vollständigkeit der Daten und/oder Datenverlust und/oder Datenverlustwahrscheinlichkeit der Nutz-Datenpakete; und/oder - eine Prädiktion einer Vollständigkeit der Daten und/oder Datenverlust und/oder Datenverlustwahrscheinlichkeit der Nutz-Datenpakete.
Zum Beispiel können die Referenz-Datenpakete (z.B. in einer bestimmten Umgebung, Verkehrssituation, Fahrsituation, Uhrzeit, Wochentag, etc.) erzeugt und/oder gesendet werden, um einen Rückschluss über (z.B. sehr wichtige Nutz-Datenpakete) zu bekommen (z.B. in einer bestimmten Umgebung, Verkehrssituation, Fahrsituation, Uhrzeit, Wochentag, etc.); und/oder es kann Prädizieren erfolgen, wie es (z.B. sehr wichtige Nutz-Datenpakete) in der Zukunft betreffen wird. Diese Art, Referenz-Datenpaketen zu generieren kann z.B. in Abhängigkeit von bestimmten Fahrzeugparametern erfolgen. Vorteilhafterweise kann somit bekannt sein, in welchen Situationen mit einem Datenverlust zu rechnen ist, z.B. um die Ausführung von Funktionen entsprechend zu steuern.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass der Rückschluss betreffend die abhängig von den Nutz-Datenpaketen betreibbare Funktionalität eine Verfügbarkeit; und/oder eine Ausfallwahrscheinlichkeit; und/oder eine Sicherheit der Funktionalität betrifft, insbesondere für das aktuelle Zeitintervall, auf ein vorausliegendes Zeitintervall und/oder auf ein Zeitintervall in der Vergangenheit erfolgt.
Entsprechend kann z.B. eine erwartete Performance oder Präzision, mit der die Funktionalität (z.B. Fahrzeugfunktion) ausgeführt werden kann, ermittelt werden. Somit kann basierend auf dem erfolgten Rückschluss bereits vor dem Einschalten einer Funktion eine Information vorliegen kann, ob und wie präzise die Funktion voraussichtlich funktionieren wird. Wenn zum Beispiel eine untere Performancegrenze unterschritten wird, kann eine Aktivierung der Funktionalität blockiert werden (z.B. aus Sicherheitsgründen oder um dem Nutzer eine schlecht funktionierende Funktion zu ersparen). Der Nutzer des Fahrzeugs kann z.B. auf einer Karte dargestellt bekommen, an welchen Orten welche Funktionen voraussichtlich nicht verfügbar sein werden. Darauf basierend kann z.B. eine Routenplanung optimiert werden, z.B. je nach Bedarf der Funktionsverfügbarkeit.
Es kann auch eine Kurzzeitprädiktion erfolgen, z.B. ob in naher Zukunft mit einer Degradierung der Datenübertragungsqualität zu rechnen ist. So kann z.B. für einen Zeithorizont von wenigen Sekunden bis einigen Minuten die Datenübertragungsqualität prädiziert werden und entsprechend reagiert werden, wenn z.B. mit zeitnahem Anstieg der Datenverlustwahrscheinlichkeit zu rechnen ist. Damit lassen sich rechtzeitig sicherheitskritische Funktionen deaktivieren, noch bevor ein Funktionsausfall auftritt. Andererseits kann z.B. das Ausführen einer bestimmten Funktion verzögert werden, wenn mit einer zeitnahen Verbesserung der Datenübertragungsqualität zu rechnen ist und die Funktion nicht dringend benötigt wird.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass das Ergebnis einer Vielzahl von Rückschlüssen zu den Daten (z.B. Nutzdatenpaketen oder Datenverlusten) einer digitalen Karte zugeordnet und insbesondere zu Entwicklungszwecken und/oder für einen Flottenbetrieb verwendet wird. Es kann somit eine Datenaggregation erfolgen, die abhängig von einer jeweiligen Geoposition ist, an der die Referenz-Datenpakete, auf denen die Rückschlüsse basieren, generiert wurden. Entsprechend der jeweiligen Geoposition kann ein Eintrag auf der digitalen Karte erfolgen.
Die digitale Karte kann z.B. ferner zeitdynamisch sein, sodass auch der zeitliche Einfluss auf Datenverluste an verschiedenen Geopositionen ersichtlich wird bzw. aus dieser ermittelbar ist. Beispielsweise kann so (mittels der jeweils erzeugten und/oder versendeten Referenz-Datenpaketen eine (vergleichsweise sehr genaue) digitale Karte kennzeichnend Vollständigkeit der Daten; und/oder eine Verzögerung (z.B. beim Datenempfang am Backend); und/oder einen Datenverlust und/oder eine Datenverlustwahrscheinlichkeit erzeugt werden.
Als Flottenbetrieb ist insbesondere ein sogenanntes Flottenmanagement zu verstehen. Dies kann besonders effektiv bzw. notwendig für das zumindest teilweise automatisierte Fahren sein, aber im Rahmen des vorliegenden Dokuments auch auf beliebige Fahrzeugfunktionen anwendbar sein.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass abhängig von dem Rückschluss ein Verändern von aktiven Leistungsmerkmalen einer Funktionalität; und/oder eine Information, insbesondere eine Warnung, in Bezug auf eine Funktionalität; und/oder zumindest teilweise eine Umstellung der Funktionalität auf eine weitere Datenquelle und/oder Funktionsprinzip erfolgt. Alternativ oder zusätzlich kann ein Modus der Funktionalität verändert werden. Das Verändern der aktiven Leistungsmerkmale der Funktion kann z.B. eine Performancereduzierung umfassen, z.B. kann die betroffene Fahrzeugfunktion nur mit reduzierter Performance bereitgestellt werden, wenn z.B. der Rückschluss ergibt, dass mit verringerter Datenübertragungsqualität zu rechnen ist. Zum Beispiel kann abhängig von dem Rückschluss entschieden werden, ob beispielsweise automatisiertes Fahren nur bis 60 km/h oder nur bis 80 km/h bereitgestellt wird, wobei Grenzparameter abhängig von der quantitativen Ermittlung der Datenverfügbarkeit eingestellt werden können. Es kann auch eine Warnung erfolgen, dass ein Nutzer beim Ausführen der Funktionalität besonders aufmerksam sein sollte, da möglicherweise Funktionsstörungen auftreten könnten. Beispielsweise kann bei unzureichender Datenverfügbarkeit eine komplette Abschaltung der Funktionalität erfolgen. Insbesondere kann ein selektives Abschalten einer Funktion, z.B. als zeitliche Überbrückung, erfolgen für eine Zeitdauer (z.B. prädizierte Zeitdauer), während der mit zu hohen Datenverlusten gerechnet werden muss. Beispielsweise kann z.B. die Funktion im Fall von erwarteten Datenverlusten basierend auf lokalen Daten und/oder Sensoren weiterbetrieben werden, falls dies möglich ist.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass eine, insbesondere ferngesteuerte oder gemäß aus dem Backend veränderbaren Parameter im Fahrzeug steuerbare Veränderung von einer oder mehrerer Fahrzeugfunktionalitäten, abhängig von einem oder mehreren Rückschlüssen, insbesondere aggregierter Daten auf Basis einer Vielzahl der Rückschlüsse erfolgt. Ein Vorteil durch die ferngesteuerte Veränderung kann sein, dass sich z.B. eine Aktivierbarkeit und/oder Deaktivierbarkeit und/oder Anpassung eines Funktionsumfangs für das Fahrzeug aus dem Backend heraus ergibt. Somit können aggregierte Daten bzw. Rückschlüsse hinsichtlich Datenverfügbarkeit von mehreren unterschiedlichen Fahrzeugen genutzt werden, um die Veränderung bei einem bestimmten Fahrzeug besser steuern zu können. Beispielsweise können so auch Funktionen von Fahrzeugen gesteuert werden, die selbst keine Referenz-Datenpakete versenden.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass abhängig von dem Rückschluss eine Kampagne zur Erfassung der Daten aus einer Flotte von Fahrzeugen betreffend das ein oder mehrere Fahrzeuge; und/oder - betreffend weitere unter vergleichbaren Bedingungen betriebene Fahrzeuge angepasst wird. Bei einer Kampagne zum Erfassen von Daten können z.B. Daten von Fahrzeugen in einem bestimmten räumlichen Bereich abgefragt werden oder baugleiche oder bauähnliche Fahrzeuge abgefragt werden (z.B. Fahrzeuge mit gleicher Sonderausstattung). Durch eine solche zielgerichtete Analyse der Daten oder Datenverfügbarkeit kann eine besonders differenzierte Aussage hinsichtlich der Auswirkung interner Parameter (z.B. bestimmte Steuermodule im Fahrzeug; z.B. bestimmte Hardware oder Softwarekonfiguration) gegenüber externen Parametern (z.B. lokale Netzverfügbarkeit; z.B. Verkehrsaufkommen) auf Datenverluste oder eine Datenverlustwahrscheinlichkeit erfolgen.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass eine Streckenfreigabe; und/oder eine Streckensperrung; und/oder eine Einschränkung eines nutzbaren Automatisierungsgrads für eine oder mehrere Fahrzeugfunktionalitäten, insbesondere Funktionalitäten zum zumindest teilweise automatisierten Fahren, abhängig von einem oder mehreren Rückschlüssen, insbesondere aggregierter Daten auf Basis einer Vielzahl der Rückschlüsse erfolgt. Gerade bei automatisiertem oder teilautomatisiertem Fahren ist es notwendig, dass die Funktionalität sicher verfügbar ist. Das vorgeschlagene Verfahren kann es ermöglichen, gezielt, z.B. abhängig von Geopositionen, zu erkennen, wo eine genügend hohe Datenverfügbarkeit besteht und wo nicht. Beispielsweise kann somit auch für kleine Abschnitte oder Bereiche (z.B. ein bestimmter Kreisverkehr; z.B. eine bestimmte Kreuzung) mit zu hoher Datenverlustwahrscheinlichkeit eine Sperrung für ein Ausführen der Fahrzeugfunktion erfolgen (z.B. Streckensperrung). Beispielsweise kann bei verschiedenen Funktionen, die auf verschiedene Steuergeräte oder Sensoren zurückgreifen herausgefunden werden, ob Datenverluste lokal aufgrund einer Überlastung bestimmter Steuergeräte oder Sensoren auftreten. Diese Kenntnis kann vorteilhaft in die Weiterentwicklung der Fahrzeuge und Fahrzeugfunktionen einfließen.
Flottenmanagement, Streckenfreigabe bzw. -sperrung können im Zusammenhang mit automatisiertem Fahren sehr wichtig sein. Insbesondere ergibt sich z.B. als objektiver technischer Vorteil, dass in den Bereichen wo (ggf. aufgrund der Funklöcher oder vieler weiteren Gründe) nur mangelhafte Daten aus der Vergangenheit vorliegen (das heißt z.B. dass wenig Kenntnis über das tatsächliche Verhalten der Fahrzeugfunktionen dort bereitstehen kann) tendenziell vorsichtiger umgegangen werden kann. Gerade in solchen Situationen kann es besonders vorteilhaft zu wissen, ob Datenverlust auftritt und welche Daten verloren gehen.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass die Referenz-Datenpakete erzeugt und/oder gesendet werden in einem zeitlichen und/oder kausalen Zusammenhang mit den Nutz-Datenpaketen und/oder mit der Erwartung, dass Nutz-Datenpakete aktuell oder zu einem späteren Zeitintervall erzeugt werden.
Beispielsweise kann in Situationen, in denen besonders viele Nutzdatenpakete gesendet werden auch eine besonders hohe Zahl an Referenz-Datenpaketen gesendet werden, um einen möglichst realistischen Vergleich zu haben. Beispielsweise können in Situationen, in denen besonders große Nutzdatenpakete gesendet werden (hohe Datenmenge) auch entsprechend größere Referenz-Datenpaketen gesendet werden. Beispielsweise können die Referenz-Datenpakete in einer bestimmten Umgebung, Verkehrssituation, Fahrsituation, Uhrzeit, Wochentag, etc. erzeugt werden. Es kann eine Umgebung, Verkehrssituation, Fahrsituation, Uhrzeit, Wochentag, etc. sein, die für die Nutzung der Nutz-Datenpakete besonders relevant sind. Aus der Auswertung der ankommenden Referenz-Datenpakete kann ein Rückschluss darauf gemacht werden, wie die (z.B. echten; z.B. für Funktionen tatsächlich relevanten) Nutz-Datenpakete ankommen werden oder (z.B. aus der Vergangenheit) angekommen sind.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass die Referenz-Datenpakete mit einer Information versehen werden, die kennzeichnend ist für: - Ihre Anzahl, Reihenfolge, Sequenz; und/oder - einen zeitlichen und/oder kausalen Bezug zu den Nutz-Datenpaketen. Mit anderen Worten kann in den Referenz-Datenpaketen eine Nutzinformation enthalten sein, die Rückschlüsse ermöglicht, ob Datenverlust auftritt oder nicht. Zum Beispiel kann ein Zähler als Nutzinformation integriert werden. Zum Beispiel kann ein in Bezug zu den erwarteten Nutzdatenpaketen genutztes Sendemuster übermittelt werden. Ein kausaler Bezug zu den Nutzdatenpakete kann etwa sein, dass nach jedem fünften (oder zehnten oder zwanzigsten) Nutzdatenpaket wird ein Referenz-Datenpaketen verschickt wird. Zum Beispiel kann vorgesehen sein, dass erst ab einer bestimmten Größe und/oder Frequenz der Nutzdatenpakete ein oder mehrere Referenz-Datenpaketen verschickt werden. Die Art des kausalen Zusammenhangs kann als Information oder Kodierung im Referenzdatenpaket integriert sein, sodass dieser Zusammenhang im Backend ausgewertet werden kann. Zum Beispiel sind so dynamisch wechselnde Zusammenhänge möglich, da im Backend die Sendevorschrift stets bekannt sein kann und entsprechend korrekte Rückschlüsse gezogen werden können. Zum Beispiel kann die Information im Referenzdatenpaket mitgesendet werden, dass immer in einem bestimmten zeitlichen Abstand nach einem Nutzdatenpaket ein Referenzdatenpaket gesendet wird (z.B. 1 Sekunde nach Nutzdatenpaket). Dadurch kann z.B. auch zusätzlich eine sich ändernde zeitliche Verzögerung beim Empfang von unterschiedlichen Datenpaketen ermittelt werden.
Somit ist z.B. (zumindest betreffend die Referenz-Datenpakete) im Backend bekannt, wie viele und welche solcher Pakete versendet worden sind. Dadurch kann ein besonders präziser Rückschluss über diese Pakete (insbesondere Statistik, Zeitverläufe, etc.) ermittelt werden. Ein kausaler Bezug kann z.B. auch eine Information sein, dass aktuell auch Nutz-Datenpakete zu erwarten sind oder ein Bezug auf eine Anzahl, Reihenfolge und/oder Sequenz der Nutzdaten sein. Somit kann der Rückschluss auf die Nutzdatenpakete verfahrensgemäß weiter verbessert werden.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass - die Referenz-Datenpakete mit einer Identifikationsinformation oder Identifikationsnummer (z.B. ID; z.B. abweichend von einer Fahrzeug-ID oder VIN) erzeugt und versendet werden, die mit der gleichen Identifikationsnummer wie die Nutz-Datenpakete oder einer Identifikationsnummer die mit der Identifikationsnummer der entsprechenden Daten-Clients (logisch) zugeordnet ist. Im Gegensatz zur Verwendung einer Fahrzeug-ID zur Zuordnung der Datenpakete kann eine paketspezifische ID z.B. dynamisch geändert werden oder in Abhängigkeit von bestimmten Situationen angepasst werden. Somit kann zum Beispiel ermöglicht werden, dass sich die Referenz-Datenpakete auf bestimmte Nutzdatenpakete beziehen oder diesen zugeordnet werden können. Durch die Nutzung der Identifikationsnummer kann zum Beispiel auch der Bezug zum Fahrzeug ersetzt werden. Aus Datenschutzgründen kann es vorteilhaft sein, wenn die Fahrzeug-ID weggelassen werden kann
Beispielsweise können Referenz-Datenpakete erzeugt und versendet werden, die jeweils Nutz-Datenpakete aus mehreren unterschiedlichen Daten-Clients und/oder Steuergeräten des Fahrzeugs repräsentieren. Dabei können diese möglichst gleiche Chancen wie die Nutz-Datenpakete zum Ankommen am Backend aufweisen. Somit ist durch die Nutzung der Referenz-Datenpakete eine besonders realistische Vorhersage auf das Verhalten der ansonsten (z.B. später) gesendeten Nutzdatenpakete möglich.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass - die Referenz-Datenpakete mittels einer ersten Recheneinheit erzeugt werden, die sich von einer zweiten Recheneinheit mit den Nutzdaten für die Nutz-Datenpakete unterscheidet. Ein Vorteil kann sein, dass Referenz-Datenpaketen auch dann versendet werden können, wenn die zweite Recheneinheit, die die Nutzdatenpakete erzeugt (und ferner die Fahrzeugfunktion ausführt) überlastet ist und daher im Moment keine Referenz-Datenpaketen erzeugen kann. Wenn in einem solchen Moment Referenz-Datenpaketen der ersten Recheneinheit (aber beispielsweise keine Datenpakete der zweiten Recheneinheit) empfangen werden, besteht die Kenntnis darüber, dass nicht die Kommunikationsverbindung (z.B. schlechter Mobilfunkempfang), sondern eine Überlastung der funktionsausführenden Recheneinheit (z.B. Steuergerät) für den Datenverlust bzw. die mangelhafte Datenverfügbarkeit verantwortlich ist.
Damit kann der Situation begegnet werden, dass Daten gemäß anderen Konzepten meist immer dann fehlen, verloren gehen oder verschwinden, wenn man sie braucht, da z.B. eine Überlastung der Steuergeräte auftritt. In einem solchen Fall kann die Funktion eher schlechter ausgeführt werden, da zu wenige Ressourcen zur Verfügung stehen können. Es kann nachteilig sein, wenn in solchen Situationen keine Daten vorhanden sind, denn diese Daten können sehr hilfreich sein, die Funktionsausführung in der betreffenden Situation zu verbessern oder das Fahrzeugsystem anzupassen.
Gemäß dem vorgeschlagenen Beispiel wird daher eine andere Recheneinheit genutzt, die nicht mit der Überlastung korreliert. Zum Beispiel kommen Nutzdatenpakete von einer Recheneinheit, die automatisiertes Fahren steuert, Referenz-Datenpaketen werden jedoch im Infotainmentsystem erzeugt. Wenn nun die Recheneinheit, die automatisiertes Fahren steuert überlastet ist, keine Nutzdatenpakete mehr erzeugt und folglich auch keine Nutzdatenpakete empfangen werden, jedoch Referenz-Datenpaketen empfangen werden, besteht Kenntnis, dass Nutzdatenpakete hätten ankommen sollen, es aber nicht sind. An dieser Stelle kann vorteilhaft angesetzt werden, um das Fahrzeugsystem an die bestehenden Herausforderungen anzupassen und die Funktionalität zu verbessern.
Beispielsweise würden gemäß anderen Konzepten bei einer Überlastung einer Recheneinheit, die gleichzeitig Nutzdatenpakete und Referenz-Datenpaketen erzeugt, gar keine Daten mehr im Backend ankommen, wodurch größere Unkenntnis hinsichtlich der Ursache dafür bestehen kann. Durch die Nutzung separater Recheneinheiten kann eine Quantifizierung über den auftretenden Datenverlust erfolgen. Der vorgeschlagene Aspekt kann eine Datenverfügbarkeit entsprechend verbessern, sodass Daten auch verfügbar sind, wenn ein funktionsausführendes Steuergerät keine zu sendenden Daten mehr generiert.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass ein oder mehrere Schritte des Verfahrens ausgeführt werden, insbesondere die Referenz-Datenpakete erzeugt werden, im Rahmen und/oder parallel zu und/oder abwechselnd mit dem Betrieb der Dateninfrastruktur innerhalb einer Endnutzerflotte (z.B. Nutzung der Flotte im normalen Straßenverkehr). Durch das Einsetzen einer solchen Fahrzeugflotte kann eine besonders realistische Analyse hinsichtlich Datenverfügbarkeit, Übertragungsqualität oder Datenverlusten erfolgen. Insbesondere das abwechselnde Ausführen der Verfahrensschritte mit dem Betrieb der Dateninfrastruktur kann vorteilhaft sein. In diesem Fall können immer dann, wenn Nutzdatenpakete nicht benötigt werden, Referenz-Datenpaketen für die Messung bzw. den verfahrensgemäßen Rückschluss (z.B. Analyse für Performance der Fahrzeugfunktionen oder Dateninfrastruktur) genutzt werden. Die Analyse kann dabei immer quantitativ erfolgen.
Beispielsweise kann verfahrensgemäß vorgesehen sein, dass - die Referenz-Datenpakete im Fahrzeug abhängig von dem aktuellen und/oder voraussichtlichen Bedarf an Nutz-Datenpaketen und/oder abhängig von den Daten betreibbaren Funktionalitäten, insbesondere im Backend erzeugt werden. Beispielsweise kann so an Stellen mit hohem Bedarf einer Datenübertragung eine besonders genaue Analyse der Übertragungsqualität erfolgen und realitätsnah bezüglich einer hohen Auslastung der Übertragungskapazität erfolgen. Der Bedarf kann z.B. an Strecken, an denen automatisiertes Fahren verfügbar ist, sehr hoch sein (z.B. Autobahnstrecken), während andere Strecken unkritischer sind und weniger Daten für eine ausreichende Analyse genügen können (z.B. Strecken innerorts). Vorteilhafterweise kann eine Voraussage darüber getroffen werden, wo voraussichtlicher Bedarf an wichtigen Daten bestehen wird und dort das Verfahren besonders intensiv eingesetzt werden. Referenz-Datenpaketen können ganz allgemein vor dem Ausführen der Funktion erzeugt werden, um zu prüfen, ob die Funktion aufgrund einer zu erwartenden Übertragungsqualität funktionieren wird oder nicht (z.B. zu hohe Datenverluste). Dadurch kann eine prädiktive Aussage getroffen werden, was wichtig sein kann, um kritische Funktionen sicher ausführen zu können oder bei Bedarf auch blockieren zu können. Die Aussage, ob eine Funktion sicher ausgeführt werden kann, kann abhängig davon sein, wie viel Bedarf an Nutzdatenpakete diese Funktion hat und damit funktionsgekoppelt sein. Die Qualitätsanforderungen bei verschiedenen Fahrzeugfunktionen können sehr unterschiedlich ausfallen, was eine quantitative Aussage zur Datenübertragungsqualität unabdingbar machen kann.
Ein weiterer Aspekt betrifft ein Computerprogramm mit einem Programmcode, um das zuvor oder nachstehend beschriebene Verfahren auszuführen, wenn das Computerprogramm auf einem Prozessor, einem Computer, oder einer programmierbaren Hardware ausgeführt wird. Ein solcher Programmcode kann vorteilhaft in einer Software für ein Fahrzeug oder ein Backend implementiert sein. Beispielsweise kann das Computerprogramm auf einem Bordcomputer und/oder auf einem Server ausgeführt werden.
Das Computerprogramm kann ein Computerprogrammprodukt umfassen oder sein. Zu dem Programmcode können computerprogrammspezifische bzw. verfahrensspezifische Daten gezählt werden.
Das Computerprogramm kann als ein Update eines bisherigen Computerprogramms ausgebildet sein, welches beispielsweise im Rahmen einer Funktionserweiterung, beispielsweise im Rahmen eines sogenannten „Remote Software Update“ die Teile des Computerprogramms bzw. des entsprechenden Programmcodes umfasst. Das Computerprogrammprodukt umfasst insbesondere ein von der Datenverarbeitungsvorrichtung lesbares Medium, auf dem der Programmcode gespeichert ist, oder zumindest eine verschlüsselte Datei. Gemäß einem weiteren Aspekt wird ein Programmprodukt beschrieben, das ein autorisiertes Zugriffsrecht auf abgelegte Daten des Computerprogrammprodukts umfasst.
Es ist zu beachten, dass die in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systeme sowohl alleine, als auch in Kombination mit anderen in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systemen verwendet werden können. Des Weiteren können jegliche Aspekte der in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systemen in vielfältiger Weise miteinander kombiniert werden. Insbesondere können die Merkmale der Ansprüche in vielfältiger Weise miteinander kombiniert werden.
Ein weiterer Aspekt der Erfindung betrifft ein System zum Sammeln und/oder Verarbeitung von Daten aus Fahrzeugen, wobei das System eingerichtet ist zum: - Erzeugen und/oder Versenden von Referenz-Datenpaketen in einem oder mehreren Fahrzeugen; - Auswertung der im Backend ankommender Referenz-Datenpakete und abhängig von der Auswertung:- Ermitteln eines Rückschlusses betreffend die Nutz-Datenpakete; und/oder - Ermitteln eines Rückschluss auf eine abhängig von den Nutz-Datenpaketen betreibbare, insbesondere betriebene Funktionalität.
Das System kann die zu den Merkmalen des Verfahrens korrespondierende Merkmale ausweisen und/oder zur Ausführung des Verfahrens eingerichtet sein. Aus einem solchen System können sich dieselben oder korrespondierende Vorteile ergeben, wie sie bereits in Verbindung mit dem offenbarten Verfahren beschrieben sind.
Bevorzugt umfasst das System ein oder mehrere Fahrzeuge und/oder ein Backend (auch zu verstehen als eine Cloud, ein Server, ein Portal, Serververbund). Bevorzugt sind ein oder mehrere Fahrzeuge zu einer unmittelbaren oder mittelbaren Wirkverbindung mit dem Backend ausgestaltet.
Ferner können die ein oder mehreren Fahrzeuge ausgestaltet sein, die entsprechenden Daten (z.B. bei der Ausführung der Wirkverbindung) an das Backend (B) zu übermitteln. Das Backend kann ausgestaltet sein, die Daten aus einer Mehrzahl der Fahrzeuge zu verarbeiten, insbesondere einen Rückschluss zu ermitteln. Auf Basis des Rückschlusses (Ergebnisses der Auswertung im Zusammenhang mit Referenz-Datenpaketen), kann (zumindest teilweise in dem Backend und/oder zumindest teilweise in dem weiteren Fahrzeug) eine Aktivierbarkeit, Aktivierung, Deaktivierung und/oder Veränderung, insbesondere Einschränkung der von den Nutzdaten betreibbaren Funktionalität kann abhängig von dem Rückschluss (automatisch) bewirkt werden.
Ein weiterer Aspekt (z.B. zusätzlich oder alternativ zum zuvor beschriebenen Verfahren) betrifft ein Verfahren (z.B. Entwicklungsverfahren) bzw. System (z.B. Entwicklungssystem) zur Entwicklung der Dateninfrastruktur im Zusammenhang mit einem Fahrzeug; und/oder - auf den Daten aus der Daten-Infrastruktur betreibbare Funktionalitäten (z.B. Fahrzeugfunktionen). Dabei kann eine Versuchsflotte und/oder Endnutzerflotte mit Referenzdatengeneratoren verwendet werden, um mit diesen Daten Testfälle und/oder Ground Truth für die Verarbeitung der Daten bzw. eine mit diesen betreibbare (sozusagen nachgeschaltete) Funktionalität zu entwickeln, anzupassen und/oder zu betreiben.
Beispielsweise können verwendete Recheneinheiten basierend auf Ground-Truth-Daten (z.B. als ideal angenommene Daten aus Testfahrzeugen mit deutlich besseren Mess- oder Recheneinheiten als Standardfahrzeuge) betrieben werden. Daraus kann ermittelt werden, welche Verbesserungen in der Sensorik aber auch im Rest des Fahrzeugsystems sinnvoll sein können. Zum Beispiel kann ideale Sensorik genutzt werden, um den Rest des Systems testen (z.B. Leistungsfähigkeit von elektronischen Steuergeräten oder Telematik, etc. im Fahrzeug). Beispielsweise können dabei nur Referenz-Datenpaketen generiert werden, die von nichts abhängig sind, und dann geprüft werden, was noch am System weiterentwickelt oder verbessert werden sollte. Somit lässt sich das beschriebene Verfahren vorteilhaft für die Entwicklung und Verbesserung von Fahrzeugen einsetzen.
In einer solchen Variante des Verfahrens oder Systems können ein oder mehrere Referenzdatengeneratoren alternativ oder zusätzlich: Variable, z.B. nach einer vorausbestimmten Funktion wechselnde Größe und/oder Frequenz (in einem Sonderfall kann die vorausbestimmte Funktion eine zumindest teilweise zufällig veränderliche Funktion bzw. Abhängigkeit von einer Zufallszahl umfassen oder sein) und/oder Werte in einem oder mehreren Grenzbereichen der Fahrzeug-Dateninfrastruktur und/oder einer mit dieser betreibbaren Funktionalität aufweisen.
Die ankommenden Referenz-Datenpakete können verwendet werden für den Test, Parametrierung und/oder eine (Weiter-)Entwicklung eines: - Systems umfassend die Fahrzeug-Dateninfrastruktur; und/oder - eines Teilsystems der Fahrzeug-Dateninfrastruktur.
Ferner können alle im vorliegenden Dokument beschriebene Merkmale des Verfahrens mit Merkmalen des Entwicklungsverfahrens bzw. alle Merkmale des Systems frei mit allen Merkmalen des Entwicklungssystems kombiniert werden.
Dabei kann (anstatt dem Versuch ein extrem komplexes Gesamtsystem sozusagen auf einmal zu entwickeln), ein Teilsystem umfassend eine oder mehrere Fahrzeug-interne Vorrichtungen und/oder eine oder mehrere Fahrzeug-externe Vorrichtungen getestet, parametriert und/oder entwickelt werden. Dadurch kann der resultierende Aufwand reduziert und/oder eine Etablierung des Teilsystems beschleunigt werden. Beispielsweise kann ein Teilsystems umfassend: - Zwischenspeichern und/oder Verarbeiten der Daten in einem Zentral-Steuergerät; und/oder - Fahrzeug-Telematik-Vorrichtung; - Mobilfunk und/oder IT-Infrastruktur; - Backend, Data-Pipe; - mit den (aktuellen und/oder späteren) Nutz-Datenpaketen betreibbare Funktionalitäten; Zum Beispiel kann vorgesehen sein, dass die Referenz-Datenpakete durch einen Teil der Fahrzeugflotte (z.B. einer Versuchsflotte und/oder der Endnutzerflotte) generiert werden, die nicht zum Generieren der Nutzdaten eingerichtet oder verwendet werden.
Figurenkurzbeschreibung
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:

1 ein Flussdiagramm eines Verfahrens im Zusammenhang mit dem Sammeln von Daten aus einem oder mehreren Fahrzeugen;
2 ein schematisches Beispiel einer Sequenz von aus einem Fahrzeug gesendeten Daten mit Nutz- und Referenz-Datenpaketen; und
3 ein schematisches Beispiel eines Systems mit mehreren Fahrzeugen und einem Backend.

Beschreibung
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein. Bei der nachfolgenden Beschreibung der beigefügten Figuren, die lediglich einige exemplarische Ausführungsbeispiele zeigen, können gleiche Bezugszeichen gleiche oder vergleichbare Komponenten bezeichnen.
Ein Element, das als mit einem anderen Element „verbunden“ oder „verkoppelt“ bezeichnet wird, mit dem anderen Element direkt verbunden oder verkoppelt sein kann oder dass dazwischenliegende Elemente vorhanden sein können. Solange nichts anderes definiert ist, haben sämtliche hierin verwendeten Begriffe (einschließlich von technischen und wissenschaftlichen Begriffen) die gleiche Bedeutung, die ihnen ein Durchschnittsfachmann auf dem Gebiet, zu dem die Ausführungsbeispiele gehören, beimisst.
1 zeigt ein Flussdiagramm eines Verfahrens 10 im Zusammenhang mit dem Sammeln von Daten aus einem oder mehreren Fahrzeugen. Verfahrensgemäß erfolgt ein Erzeugen und/oder Versenden 11 von Referenz-Datenpaketen in einem oder mehreren Fahrzeugen sowie eine Auswertung 12 der im Backend ankommenden Referenz-Datenpakete. Abhängig von der Auswertung 12 erfolgt ein Rückschließen 13 in Form eines Rückschlusses 13a betreffend Nutz-Datenpakete und/oder eines Rückschluss 13b auf eine abhängig von solchen Nutz-Datenpaketen betreibbare, insbesondere betriebene Funktionalität.
Das Verfahren 10 ermöglicht es, dass eine Information gewonnen wird, die den Rückschluss 13 darauf erlaubt, ob und welcher Teil von Nutzdaten aus jeweiligen Fahrzeugen tatsächlich (z.B. vollständig) ankommt oder nicht ankommt. Es ist z.B. eine quantitative Analyse hinsichtlich Datenverlust oder Datenverlustwahrscheinlichkeit möglich. Dadurch lassen sich die Daten für neue Zwecke nutzen bzw. auf Basis der Daten Anwendungen realisieren, die bisher vorgesehen bzw. machbar waren. Bereits das Wissen darüber, dass bestimmte Daten vollständig oder nicht vollständig sind, insbesondere welche konkreten Daten (zumindest mit einer gewissen Wahrscheinlichkeit) vollständig sind oder (zumindest mit einer gewissen Wahrscheinlichkeit) fehlen, kann je nach Use-Case bzw. Anwendungsbereich der Daten einen großen technischen und wirtschaftlichen Wert schaffen.
Das vorgeschlagene Verfahren 10 kann eine Reihe von Vorteilen bringen von denen nur einige explizit aufgezählt werden: - Daten werden für neue Zwecke nutzbar gemacht; - Datenbasierte Anwendungen, insbesondere Endnutzerfunktionen realisierbar; - Vergleichsweise sehr niedrige Kosten sowie erforderliche Entwicklungsdauer; - Erfordert kein bestätigungsbasiertes Verfahren auf der Nachrichtenübertragungsebene; - Verringert den Aufwand in der Handhabung sowie Verwendung der Daten auf der Empfängerseite; - Einige Varianten sind auch verwendbar, um die Fahrzeug-Dateninfrastruktur zu testen, zu parametrieren, zu entwickeln und/oder im Betrieb anzupassen.
2 zeigt ein schematisches Beispiel einer Sequenz 20 von aus einem Fahrzeug gesendeten Daten mit Nutzdatenpaketen 21 und Referenz-Datenpaketen 22a, 22b. Es ist eine rein beispielhafte und schematische Darstellung der Reihenfolge der gesendeten Datenpakete 21, 22a, 22b über eine Zeitleiste t gegeben. Das offenbarte Verfahren kann insbesondere hinsichtlich des Sendemusters, der Sequenz oder Anzahl von Datenpaketen vollkommen variabel sein und z.B. an bestimmte Nutzungsbedarfe angepasst werden.
Demnach können die Referenz-Datenpakete 22a, 22b an bestimmten Positionen und/oder gemäß einem bestimmten Muster zwischen einer Reihe von Nutzdatenpaketen eingefügt und übertragen werden (z.B. zu einem Backend). Durch die vorbestimmte Position ist es am Backend möglich zu ermitteln, ob die gesendeten Datenpakete angekommen sind oder nicht. Zum Beispiel kann ein erstes Referenzdatenpaket 22a nach vier gesendeten Nutzdatenpaketen 21 (als fünftes Datenpaket) eingefügt und gesendet werden und ein zweites Referenzdatenpaket 22b nach weiteren vier gesendeten Nutzdatenpaketen 21 eingefügt und gesendet werden. Dadurch kann am Backend ermittelt werden, ob Datenverluste auftreten, wenn nicht regelmäßig vier Nutzdatenpakete und anschließend ein Referenzdatenpaket eintrifft. Das Auswerten der Referenz-Datenpakete kann somit musterbasiert erfolgen.
Die Referenz-Datenpakete nicht (in vorliegenden Fall benötigte oder (wesentlich) weniger wichtige Daten als die Nutzdaten umfassen. In einem vereinfachten Beispiel können diese Referenz-Datenpakete sozusagen einen Daten-Ballst umfassen oder sein. Es können Daten sein, die zur Ausführung des Verfahrens ggf. verloren bzw. in einer nicht vollständigen oder korrekten Form ankommen müssen.
Bei den mit den Nutz-Datenpaketen und/oder Referenz-Datenpaketen versendeten Daten bzw. bei dem Inhalt der Datenpakete ist insbesondere der sogenannter Payload („Nutzlast“) der (jeweiligen) Datenpakete gemeint.
Beispielsweise können die beiden Referenz-Datenpaketen 22a, 22b unterschiedliche Paketgrö-ßen aufweisen, sodass ermittelt werden kann, ob Datenverluste wahrscheinlicher bei großen Datenmengen bzw. Datenpaketgrößen sind als bei kleineren. Ferner können die Referenz-Datenpaketen 22a, 22b z.B. eine geringere Größe aufweisen als die Nutzdatenpakete, um eine Analyse hinsichtlich Datenverlusten zu ermöglichen und dabei gleichzeitig die Übertragungskapazität möglichst wenig zu belasten. Somit kann das Verfahren 10 auch im laufenden Betrieb eingesetzt werden, z.B. ohne die eigentlichen Fahrzeugfunktionen wesentlich zu beeinträchtigen.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. 1) oder nachstehend (z.B. 3) beschriebenen Ausführungsbeispielen erwähnt sind.
3 zeigt ein schematisches Beispiel eines Systems 30 mit mehreren Fahrzeugen F1, F2 und einem Backend B. Verfahrensgemäß einbezogene Fahrzeuge können alle Fahrzeugarten sein, die über eine jeweilige Kommunikationsverbindung 31 (z.B. Mobilfunk) mit dem Backend B kommunizieren können. Beispielsweise können die beiden Fahrzeuge F1, F2 ein Automobil und ein Motorrad sein.
Es kann somit möglich sein, den Einfluss der Fahrzeugsysteme selbst auf eine mögliche Datenverlustwahrscheinlichkeit beim Senden von Daten an das Backend B zu ermitteln. Beispielsweise sind im ersten Fahrzeug F1 andere Steuergeräte und Telematikmodule eingesetzt als im zweiten Fahrzeug F2. Wenn an einer selben Position und mit gleichen Umgebungsbedingungen bei dem ersten Fahrzeug F1 mit höheren Datenverlusten zu rechnen ist als bei dem zweiten Fahrzeug F2 kann z.B. eine Verringerung der Datenverluste durch Änderung oder Weiterentwicklung der betroffenen Elemente an das erste Fahrzeug F 1 erfolgen.
Dagegen kann z.B. bei hinsichtlich der betroffenen Elemente zum Senden von Daten baugleichen Fahrzeugen F1, F2 z.B. eine zeitabhängige Datenverlustwahrscheinlichkeit ermittelt werden, z.B. wenn die beiden Fahrzeuge zu unterschiedlichen Zeiten an derselben Position Daten übermitteln, dabei aber unterschiedlich hohe Datenverluste auftreten.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in 3 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. 1-2) oder nachstehend beschriebenen Ausführungsbeispielen erwähnt sind.

Claims

Verfahren (10) im Zusammenhang mit dem Sammeln von Daten aus Fahrzeugen (F1, F2), das Verfahren (10) umfassend: - Erzeugen und/oder Versenden (11) von Referenz-Datenpaketen (22a, 22b) in einem oder mehreren Fahrzeugen (F1, F2); - Auswerten (12) der in einem Backend ankommenden Referenz-Datenpakete (22a, 22b) und abhängig von dem Auswerten (12): - ein Rückschluss (13a) betreffend Nutz-Datenpakete (21); und/oder - ein Rückschluss (13b) auf eine abhängig von Nutz-Datenpaketen (21) betreibbare, insbesondere betriebene Funktionalität.
Verfahren (10) nach dem Anspruch 1, wobei der Rückschluss (13a, 13b) betreffend Nutz-Datenpakete (21) kennzeichnend ist für: - Vollständigkeit der Nutzdaten; und/oder - Verzögerung der Nutzdaten; und/oder - Verlust der Nutzdaten; und/oder - Datenverlustwahrscheinlichkeit, insbesondere als eine zeitliche und/oder räumliche Funktion.
Verfahren (10) nach dem Anspruch 1 oder 2, wobei der Rückschluss (13a, 13b) betreffend die abhängig von den Nutz-Datenpaketen (21) betreibbare Funktionalität: - eine Verfügbarkeit; und/oder - Ausfallwahrscheinlichkeit; und/oder - Sicherheit der Funktionalität; insbesondere für das aktuelle Zeitintervall, auf ein vorausliegendes Zeitintervall; und/oder - auf ein Zeitintervall in der Vergangenheit gemacht wird.
Verfahren (10) nach einem der vorangegangenen Ansprüchen, wobei das Ergebnis einer Vielzahl der Rückschlüsse (13a, 13b) zu den Daten einer digitalen Karte zugeordnet und insbesondere zu Entwicklungszwecken und/oder für einen Nutzbetrieb, insbesondere Flottenbetrieb verwendet wird.
Verfahren (10) nach einem der vorangegangenen Ansprüchen, wobei abhängig von dem Rückschluss (13a, 13b): - ein, insbesondere temporäres oder permanentes, Ausführen, Unterdrücken und/oder Verändern einer Anzahl von aktiven oder aktivierbaren Leistungsmerkmalen einer Funktionalität; und/oder - Ausgabe einer Information, insbesondere an den Fahrer des Fahrzeugs und/oder einen Dispatcher in Bezug auf eine Funktionalität; und/oder - Verändern eines aktiven oder aktivierbaren Betriebsmodus der Funktionalität; und/oder - zumindest teilweise Umstellung der Funktionalität auf eine weitere Datenquelle und/oder auf eine weitere Funktionslogik und/oder Funktionsprinzip erfolgt.
Verfahren (10) nach einem der vorangegangenen Ansprüchen, wobei: eine, insbesondere ferngesteuerte oder gemäß aus dem Backend (B) veränderbaren Parametern im Fahrzeug (F1, F2) steuerbare Ausführen, Unterdrücken und/oder Verändem von einer oder mehreren Fahrzeugfunktionalitäten, abhängig von einem oder mehreren Rückschlüssen (13a, 13b), insbesondere aggregierter Daten auf Basis einer Vielzahl der Rückschlüsse (13a, 13b) erfolgt.
Verfahren (10) nach einem der vorangegangenen Ansprüchen, wobei abhängig von dem Rückschluss (13a, 13b) eine Kampagne zur Erfassung der Daten aus einer Flotte von Fahrzeugen (F1, F2): - betreffend das ein oder mehrere Fahrzeuge (F 1, F2); und/oder - betreffend weitere unter vergleichbaren Bedingungen betriebene Fahrzeuge (F1, F2) angepasst wird.
Verfahren (10) nach einem der vorangegangenen Ansprüchen, wobei: - eine Streckenfreigabe; und/oder - eine Streckensperrung; und/oder - eine Einschränkung des nutzbaren Automatisierungsgrads; für eine oder mehrere Fahrzeugfunktionalitäten, insbesondere Funktionalitäten zum zumindest teilweise automatisierten Fahren, abhängig von einem oder mehreren Rückschlüssen (13a, 13b), insbesondere abhängig von aggregierten Daten auf Basis einer Vielzahl der Rückschlüsse (13a, 13b) erfolgt.
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei: - die Referenz-Datenpakete (22a, 22b) werden erzeugt und/oder versendet in einem zeitlichen und/oder kausalen Zusammenhang mit den Nutz-Datenpaketen (21) und/oder mit der Erwartung, dass Nutz-Datenpakete (21) aktuell oder zu einem späteren Zeitintervall erzeugt werden.
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei gilt: die Referenz-Datenpakete (22a, 22b) werden mit einer Information versehen, die kennzeichnend ist für: - ihre Anzahl, Reihenfolge, Sequenz (20); und/oder - einen zeitlichen und/oder kausalen Bezug zu den Nutz-Datenpaketen (21).
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei gilt: - die Referenz-Datenpakete (22a, 22b) werden mit einer Identifikationsinformation erzeugt und versendet, die mit der gleichen Identifikationsinformation wie die Nutz-Datenpakete (21) oder einer Identifikationsinformation, die mit der Identifikationsinformation von entsprechenden Daten-Clients zugeordnet ist.
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei gilt: - die Referenz-Datenpakete (22a, 22b) werden mittels einer Recheneinheit erzeugt, die sich von der Recheneinheit aus der die Nutzdaten für die Nutz-Datenpakete (21) bezogen werden unterscheidet.
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei gilt: ein oder mehrere Schritte des Verfahrens (10) werden ausgeführt, insbesondere die Referenz-Datenpakete (22a, 22b) werden erzeugt (11), im Rahmen und/oder parallel zu und/oder abwechselnd mit dem Betrieb der Dateninfrastruktur zum Sammeln der Daten aus Fahrzeugen innerhalb einer Fahrzeugflotte in einem Endnutzerbetrieb.
Verfahren (10) nach einem oder mehreren vorangegangenen Ansprüchen, wobei die Referenz-Datenpakete (22a, 22b) im Fahrzeug (F 1, F2) abhängig von dem aktuellen und/oder voraussichtlichen Bedarf an Nutz-Datenpaketen (21) und/oder abhängig von den Daten betreibbaren Funktionalitäten, insbesondere im Backend (B), erzeugt werden.
Ein Computerprogramm mit einem Programmcode, um das Verfahren (10) gemäß einem der vorhergehenden Ansprüche auszuführen, wenn das Computerprogramm auf einem Prozessor, einem Computer, oder einer programmierbaren Hardware ausgeführt wird.
System (30) zum Sammeln und/oder Verarbeiten von Daten aus Fahrzeugen (F1, F2), wobei das System (30) eingerichtet ist zum: - Erzeugen und/oder Versenden (11) von Referenz-Datenpaketen (22a, 22b) in einem oder mehreren Fahrzeugen (F1, F2); - Auswerten (12) der in einem Backend (B) ankommenden Referenz-Datenpakete (22a, 22b) und abhängig von der Auswertung (12): - Ermitteln eines Rückschlusses (13a) betreffend Nutz-Datenpakete (21); und/oder - Ermitteln eines Rückschlusses (13b) auf eine abhängig von Nutz-Datenpaketen (21) betreibbare, insbesondere betriebene Funktionalität.