Titel

Verfahren zum Bereitstellen von Daten in einem Fahrzeug

Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen von Daten in einem Fahrzeug unter Verwendung eines Datenfilters sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.

Hintergrund der Erfindung

Bei der Entwicklung von Fahrzeugen, sowohl vor als auch nach Serienstart der Fahrzeuge, können in den Fahrzeugen anfallende Daten, z.B. Sensorsignale, erfasst und analysiert werden, um z.B. verschiedene Funktionen zu prüfen und etwaige Fehler zu finden. Eine Möglichkeit, solche Daten zu erhalten, ist z.B. die Verwendung eines speziell konfigurierten Messrechners im Fahrzeug, der die gewünschten Daten aufzeichnet.

Offenbarung der Erfindung

Erfindungsgemäß werden ein Verfahren zum Bereitstellen von Daten sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.

Die Erfindung beschäftigt sich mit dem Bereitstellen und insbesondere Sammeln von Daten, insbesondere Signalen, in einem Fahrzeug bzw. die in einem Fahrzeug anfallen, und zwar insbesondere während des Betriebs des Fahrzeugs. Um an solche Daten zu gelangen, kommt, wie erwähnt, die Verwendung eines spezi- ell konfigurierten Messrechners im Fahrzeug in Betracht, der die gewünschten Daten aufzeichnet. Dies ist allerdings mit großem Aufwand verbunden und insbesondere bei einer Vielzahl von Fahrzeugen in der Regel nicht praktikabel. Es hat sich auch gezeigt, dass Fahrzeuge, die z.B. schon in Serie sind und von Kunden gefahren werden, mitunter relevante Daten für die Entwicklung liefern können (sog. Felddaten). Der Einsatz eines Messrechners kommt hier nicht in Betracht.

Daneben fällt gerade in modernen Fahrzeugen eine große Menge an solchen Daten an, da es immer mehr Sensoren, Aktoren und Steuergeräte oder Funktionen im Fahrzeug gibt, beispielsweise für das automatisierte Fahren. Hierbei kann es schwierig werden, die konkret gewünschten Daten zu finden. Davon abgesehen wäre das Sammeln aller anfallenden Fahrzeugdaten von einer Vielzahl an Fahrzeugen in der Regel nicht sinnvoll darstellbar, insbesondere, wenn z.B. eine drahtlose Übermittlung der Fahrzeugdaten an z.B. einen Server für die weitere Verwendung in Betracht gezogen werden soll.

Vor diesem Hintergrund wird die Verwendung bzw. Anwendung eines speziellen Datenfilters im Fahrzeug vorgeschlagen. Dieser Datenfilter kann z.B. als ein Softwaremodul auf einer Recheneinheit, insbesondere einem Steuergerät oder Zentralrechner (dann z.B. im Rahmen des sog. "Vehicle Edge Computing") eines Fahrzeugs, ausgeführt werden. Im Lichte vorstehender Erläuterungen ist es besonders zweckmäßig, wenn ein solcher Datenfilter auf einer Vielzahl von Fahrzeugen verwendet wird.

Hierbei werden, und zwar insbesondere während eines Betriebs des Fahrzeugs, im Fahrzeug anfallende Fahrzeugdaten als Eingangsdaten für den Datenfilter erhalten. Hierzu kann ein Zugriff des Datenfilters bzw. des betreffenden Softwaremoduls auf z.B. einen oder mehrere Busse oder andere Kommunikationsmedien im Fahrzeug gestattet werden, um z.B. sämtliche im Fahrzeug anfallenden Fahrzeugdaten erfassen bzw. auslesen zu können. Diese im Fahrzeug anfallenden Fahrzeugdaten umfassen dabei z.B. die während eines Betriebs des Fahrzeugs von Sensoren und/oder Aktoren und/oder Steuergeräten erzeugten Signale und/oder Nachrichten. Es sei erwähnt, dass je nach Art und Einsatz des Datenfil- ters nicht notwendigerweise alle anfallenden Fahrzeugdaten erfasst bzw. ausgelesen werden können müssen, wenngleich dies zweckmäßig ist. So können je nach Anwendungsfall z.B. die auf einem speziellen Bus oder von bestimmten Sensoren/Aktoren oder Steuergeräten anfallenden Fahrzeugdaten ausreichend sein.

Durch Anwenden des Datenfilters, mit einer bereitgestellten Konfiguration, auf die Eingangsdaten werden dann aus den Eingangsdaten Daten ausgewählt und/oder erzeugt, die eine oder mehrere mittels der bereitgestellten Konfiguration vorgegebene Bedingungen erfüllen. Die ausgewählten und/oder erzeugten Daten (ggf. im Form von Signalen) werden dann, sofern vorhanden, als Ausgangsdaten bereitgestellt. Vorteilhafterweise werden die bereitgestellten Ausgangsdaten nach extern, d.h. nach außerhalb des Fahrzeugs, insbesondere mittels drahtloser Kommunikation, ausgegeben. So können die Ausgangsdaten z.B. an einen Server übermittelt werden, von wo sie von einem Entwickler oder anderen Berechtigten abgerufen und verwendet werden können.

Bei aktiviertem Datenfilter werden dann die anfallenden Fahrzeugdaten analysiert und ggf. entsprechenden Ausgangsdaten bestimmt und bereitgestellt sowie ggf. nach extern übermittelt. In diesem Sinne kann auch von einem Trigger oder Trigger-Framework gesprochen werden, da immer dann, wenn die Fahrzeugdaten bzw. Eingangsdaten die durch die Konfiguration vorgegebenen Bedingungen erfüllen, Ausgangsdaten bestimmt bzw. erzeugt und ggf. übermittelt werden.

Wie später noch näher erläutert wird, kann es auch vorkommen, dass bei Anwendung einer bestimmten Konfiguration bzw. eines bestimmten Datenfilters aus den Eingangsdaten keine Daten ausgewählt und/oder erzeugt werden, nämlich dann, wenn die Eingangsdaten z.B. die Bedingungen nicht erfüllen, oder zumindest nicht bei regulärem Betrieb, sondern z.B. nur bei einem Fehler. Genau dies soll im Rahmen der vorliegenden Erfindung aber insbesondere auch genutzt werden.

Außerdem liegen die eine oder die mehreren mittels der bereitgestellten Konfiguration vorgegebenen Bedingungen in einer gegenüber den Fahrzeugdaten abs- trainierten Form, aufweisend Datenbezeichner, vor. Es kann z.B. eine formale Beschreibungssprache gewählt werden. Hierzu ist dann insbesondere auch eine Zuordnung von solchen abstrakten Bezeichnungen (den Datenbezeichnern) zu den (tatsächlichen) Fahrzeugsignalen bzw. Fahrzeugdaten vorzusehen, z.B. in Form einer Zuordnungstabelle. Eine abstrakte Beschreibung der Eingangs- sowie Ausgangsdaten in der Konfiguration erlaubt es, unabhängig von der konkreten Fahrzeug-Architektur, E/E-Architektur sowie Fahrzeugfunktion zu sein. Diese abstrakte Beschreibung von Datenfiltern kann über eine formale Sprache realisiert werden, welche gleichartig über verschiedene Fahrzeugtypen, Hersteller usw. verwendet und damit auch wiederverwendet werden kann.

Die Zuordnung (oder Umrechnung) zwischen abstrakten Bezeichnungen (den Datenbezeichnern) und den (tatsächlichen) Fahrzeugsignalen bzw. Fahrzeugdaten erfolgt besonders bevorzugt automatisch in oder bei der Anwendung mittels einer Konfigurationsdatei (Mapping) zwischen Signal und verwendeten Elementen der formalen Sprache.

Es kann eine dem Datenfilter vorgeschaltete Komponente vorgesehen sein, welche die Notation einer formalen Sprache automatisiert in Bytecode übersetzt (z.B. in Art eines "STL-Compilers", STL siehe unten), d.h. die Beschreibung der Bedingungen (Triggerbedingung) erfolgt immer in der formalen Sprache, es wird kein Code manuell erzeugt. Diese Übersetzung in Bytecode kann z.B. außerhalb des Fahrzeugs erfolgen (die vorgeschaltete Komponente befindet sich dann außerhalb des Fahrzeugs) und es wird nur der übersetzte Bytecode ins Fahrzeug übermittelt; es ist aber auch möglich, die Triggerbedingung zur Laufzeit zu interpretieren, dann befindet sich die vorgeschaltete Komponente im Fahrzeug. Letzteres erfolgt z.B. bevorzugt in der Entwicklungsphase und bei sog. "Rapid Prototyping", ersteres findet bevorzugt im Umfeld regulierter Einsatzbedingungen statt (wo z.B. vorab die Auswirkung dieser Änderung des Laufzeit-Verhaltens getestet und abgesichert werden soll oder werden muss).

Besonders bevorzugt erfolgt das Anwenden des Datenfilters, insbesondere eine Prüfung, ob die eine oder die mehreren mittels der bereitgestellten Konfiguration vorgegebenen Bedingungen erfüllt sind, unter Verwendung einer temporalen Lo- gik von Signalen. Diese temporale (zeitliche) Logik von Signalen ist auch unter dem Begriff "Signal Temporal Logic", STL, bekannt. Bei temporalen Logiken oder Zeitlogiken handelt es sich um Erweiterungen der Logik, durch die zeitliche Abläufe erfasst werden können. Es handelt sich z.B. um Anwendungen der Modallogik, die auf einer Vorher-Nachher-Beziehung zwischen Zeitpunkten basieren.

Eine temporale Logik von Signalen (STL) beschäftigt sich dann insbesondere mit den zeitlichen Abläufen von Signalen, im vorliegenden Fall den Signalen (oder allgemein Daten oder auch Nachrichten) im Fahrzeug. Dabei werden insbesondere Echtzeit-Beschränkungen bzw. Echtzeit-Bedingungen berücksichtigt, wie sie während des Betriebs des Fahrzeugs auftreten oder auftreten können; ebenso können Beschränkungen oder Bedingungen der tatsächlich möglichen Werte berücksichtigt werden, z.B. speziell angepasst für die im Fahrzeug möglichen Signale bzw. Daten. Nähere Ausführungen und Erläuterungen zur temporalen Logik von Signalen finden sich z.B. in

"https://people.eecs.berkeley.edu/~sseshia/fmee/lectures/ EECS294- 98_Spring2014_STL_Lecture.pdf".

Die Verwendung temporaler Logik von Signalen erlaubt es, bestimmte Bedingungen (wie Muster oder Kriterien) für Signale bzw. Daten, und zwar nicht nur einzelne Signale, sondern insbesondere auch die Kombination von mehreren Signalen, vorzugeben bzw. zu definieren, die z.B. erfüllt sein müssen oder nicht erfüllt sein dürfen. So kann z.B. für zwei bestimmte Signale im Fahrzeug gelten, dass sie - bei regulärem Betrieb bzw. ohne Fehler - nie zur selben Zeit denselben Wert annehmen können. Ist dies doch der Fall, kann von einem Fehler ausgegangen werden. Dies erlaubt es z.B., eine Konfiguration mit Bedingungen für einen Datenfilter zu erstellen, bei der - wenn kein Fehler vorliegt - keine Ausgangsdaten erhalten werden, die bereitgestellt werden könnten. Werden hingegen Ausgangsdaten bei Anwendung des betreffenden Datenfilters mit dieser Konfiguration erhalten, so kann darauf geschlossen werden, dass ein Fehler vorliegt, und zwar z.B. bei einem der beiden Signale bzw. der diese Signale erzeugenden Einheiten (Sensor, Aktor, Steuergerät). Ebenso erlaubt es die Verwendung temporaler Logik von Signalen aber auch, bestimmte Signale oder Kombi- nationen von Signalen (oder Daten), die z.B. für ein bestimmtes Entwicklungsprojekt oder ein bestimmtes Problem von Bedeutung sind, aus den Eingangsdaten herauszufiltern und dann entsprechend als Ausgabedaten bereitzustellen.

Durch die Verwendung einer formalen Sprache können mathematisch beweisbare System-Eigenschaften garantiert werden (z.B. Mindestabstand), oder sogar statistische Argumentation abgleitet werden, wenn z.B. über eine große Fahr- zeug-/Kilometer/-Betriebsstunden-Stichprobe keine Daten zu spezifiziertem Fehlverhalten gesammelt werden können.

Ein Beispiel für Bedingungen in der formalen Sprache mit STL ist im Folgenden angegeben: float vx, ax; bool PersonDetection; formula = once[0s, 2s, ax <= 0] and once[2s, 2.1s, PersonDetection] and al- ways[2s, 2.1s, vx > 2];

Hiermit werden für Geschwindigkeit (vx) und Beschleunigung (ax) des Fahrzeugs in x- bzw. Längsrichtung sowie die Erkennung einer Person mittels Kamera (PersonDetection) Bedingungen aufgestellt. Wenn eine Person erkannt wird, während das Fahrzeug schneller als 2ms/ fährt, und danach die Beschleunigung innerhalb der nächsten 2 Sekunden weniger oder gleich 0 m/s ² ist, dann sollen Daten erfasst und ausgegeben werden. Hierbei ist nämlich von einer Bremsung aufgrund Personenerkennung auszugehen. Die Begrifflichkeiten "once", "always" entsprechen dabei üblichen STL-Bedingungen.

Durch die vorstehend erwähnte Komponente (STL-Compiler) kann diese Bedingungen dann z.B. in Bytecode übersetzt werden, sodass das betreffenden Steuergerät weiß, welche Signale zu beobachten sind, um eben z.B. die Geschwindigkeit des Fahrzeugs zu kennen. Entsprechend kann ein erhaltenes Signal (das dann z.B. als Bytecode vorliegt) wieder in die formale Beschreibung übersetzt werden. Es kann nicht nur ein solcher Datenfilter mit einer Konfiguration vorgesehen sein, vielmehr können auch mehrere solcher Datenfilter auf einem Fahrzeug bzw. einer Recheneinheit eines Fahrzeugs (oder auch auf verschiedenen Recheneinheiten des Fahrzeugs) vorgesehen sein. Diese können dann für unterschiedliche Zwecke genutzt werden, funktionierten grundsätzlich aber gleichartig. Verschiedene Datenfilter können, müssen aber nicht, auf dieselben Fahrzeugdaten zugreifen. Dies Ausgangsdaten verschiedener Filter werden in der Regel verschieden sein, können ggf. aber auch gleich sein, auch wenn z.B. die Arten der Datenfilter bzw. deren Konfigurationen verschieden sind.

Vorzugsweise wird der Datenfilter anhand einer von extern, d.h. von außerhalb des Fahrzeugs, insbesondere mittels drahtloser Kommunikation (sog. "Over The Air", OTA), erhaltenen Information zum Aktiveren oder Deaktivieren des Datenfilters aktiviert oder deaktiviert. Der Datenfilter kann also grundsätzlich auf einer Recheneinheit des Fahrzeugs vorhanden sein, z.B. als das erwähnte Softwaremodul auf einem z.B. speziell vorgesehenen Speicherbereich, aber nur bei Bedarf aktiviert und danach ggf. wieder deaktiviert werden. So kann z.B. ein Entwicklungsteam zu einem bestimmten Zeitpunkt an bestimmten Signalen oder dessen Eigenschaften interessiert sein. Hierzu kann dann der - auf der Recheneinheit hinterlegte - Datenfilter mit entsprechender Konfiguration für eine bestimmte Zeitdauer aktiviert werden.

Vorteilhafterweise wird die Konfiguration anhand einer von extern, d.h. von außerhalb des Fahrzeugs, insbesondere mittels drahtloser Kommunikation, erhaltenen Information zum Auswählen der Konfiguration aus mehreren Konfigurationen ausgewählt. Es können also für den Datenfilter mehrere - insbesondere verschiedene - Konfigurationen hinterlegt sein, die z.B. aus den Eingangsdaten verschiedene Ausgangsdaten bestimmen. Je nach aktuellem Bedarf, kann dann eine der Konfigurationen ausgewählt werden; dies kann z.B. durch Übermitteln eines entsprechenden Befehls (Information zum Auswählen der Konfiguration) an das Fahrzeug bzw. die ausführende Recheneinheit erfolgen.

Bei aktiviertem Datenfilter mit (ausgewählter) Konfiguration werden dann insbesondere während des Betriebs des Fahrzeugs - zur Laufzeit - die anfallenden Fahrzeugdaten analysiert und ggf. entsprechenden Ausgangsdaten bestimmt und bereitgestellt sowie ggf. nach extern übermittelt. In diesem Sinne kann auch von einem Trigger oder Trigger-Framework gesprochen werden, da immer dann, wenn die Fahrzeugdaten bzw. Eingangsdaten die durch die Konfiguration vorgegebenen Bedingungen erfüllen, Ausgangsdaten bestimmt bzw. erzeugt und ggf. übermittelt werden.

Es ist auch von Vorteil, wenn die Konfiguration von extern, d.h. von außerhalb des Fahrzeugs, insbesondere mittels drahtloser Kommunikation, erhalten wird. Die Konfiguration kann zwar z.B. bereits bei Herstellung des Fahrzeugs auf der ausführenden Recheneinheit vorgesehen werden (z.B. im Rahmen oder vergleichbar wie bei einer sog. Variantenkodierung von Fahrzeugen), ebenso kann sie aber später noch dorthin übermittelt werden. Dies ist z.B. dann von Interesse, wenn eine bestimmte Konfiguration erst später relevant oder bekannt wird. Es können auch mehrere Konfigurationen auf diese Weise erhalten werden; ebenso können auf diese Weise schon vorhandenen Konfigurationen um weitere Konfigurationen ergänzt werden. Ebenso können auf diese Weise eine oder mehrere vorhandene Konfigurationen aktualisiert (upgedatet) werden.

Vorzugsweise umfasst das Anwenden des Datenfilters eine Verwendung eines Maschinenlernalgorithmus wie z.B. eines künstlichen neuronalen Netzes. Dabei können mittels des Maschinenlernalgorithmus auf die Eingangsdaten für den Datenfilter z.B. bestimmte Berechnungen oder Kriterien - eben entsprechend der Konfiguration - angewendet werden, um die Ausgangsdaten zu erhalten. Ebenso kann ein Maschinenlernalgorithmus aber z.B. nur für Teilaufgaben hiervon verwendet werden, z.B. auch für die Vorauswahl von letztlich zu prüfenden Eingangsdaten und/oder für die Vorverarbeitung von Eingangsdaten für die Anwendung der temporalen Logik für Signale. Es ist also auch die Einbindung von komplexen Berechnungsschritten möglich, und zwar unabhängig vom konkreten Anwendungsfall.

Ein neuronales Netz (NN) kann z.B. in die Vorverarbeitungskette der Signale eingebunden werden, indem das Ausgangssignal des neuronalen Netzes wiederum als Input (Eingangsdaten) in den Datenfilter eingespeist wird. Z.B. könnte ein neuronales Netz die Funktion einer "Sensor Blindness" abbilden und der Datenfilter dann Daten ausgibt, wenn über einen spezifizieren Zeitraum (z.B. 300ms) ununterbrochen eine Sensor-Blindness der Frontkamera erkannt wird. Ein Anwendungsfall hierfür könnte sein, dass z.B. Bewegungen des Scheibenwischers als falsch-positiv aussortiert werden sollen.

Generell können damit im Prinzip jegliche Arten von komplexen Berechnungen aus dem Datenfilter ausgelagert werden und nur die zeitliche Abhängigkeit auf Ausgangssignal-Ebene der komplexen Berechnungen modelliert werden. Damit wird die komplexe Detektionslogik vom Zeitverhalten sowie von Interdependenzen getrennt.

Vorteilhafterweise erfolgt das Bereitstellen der Fahrzeugdaten, umfassend zumindest das Anwenden des Datenfilters, insbesondere aber auch das Erhalten der Eingangsdaten sowie das Bereitstellen der Ausgangsdaten, nur dann, wenn ein oder mehrere Kriterien bezüglich eines Laufzeitverhaltens erfüllt sind. Insbesondere wird das Bereitstellen der Fahrzeugdaten auch abgebrochen, wenn das eine oder zumindest eines der mehreren Kriterien nicht mehr erfüllt sind. Wie schon erwähnt, erfolgt die Anwendung des Datenfilters inkl. der Bereitstellung sowie ggf. Übermittlung der Ausgangsdaten zur Laufzeit. Es werden also Rechenressourcen auf der ausführenden Recheneinheit genutzt. Daher sollte darauf geachtet werden, dass die Aufgaben, für die die Recheneinheit (z.B. Steuergerät, Zentralrechner) eigentlich bzw. primär vorgesehen ist, auch ausgeführt werden können. Falls dies aufgrund der Anwendung des Datenfilters nicht mehr möglich sein sollte bzw. nicht mehr im Rahmen einer vorgegebenen Zeit, so kann und sollte die Anwendung des Datenfilters unterbrochen oder ggf. gar nicht erst gestartet werden. Als Kriterien kommen also z.B. ein bestimmter Anteil an frei verfügbarer Rechenleistung und/oder Speicherbereich oder die Abwesenheit sicherheitskritischer Regeleingriffe in Betracht.

Eine Anwendung eines solchen Datenfilters im Bereich sicherheitskritischer Systeme kann durch eine Vorab-Reservierung des benötigten geschützten Speicherbereichs auf der ausführenden Recheneinheit ebenfalls ermöglicht werden, wobei sichergestellt werden sollte, dass sich Änderungen in Umfang und Konfi- guration der Datenfilter ausschließlich in den Grenzen des vorab reservierten geschützten Speicherbereichs sowie Laufzeit-Budgets bewegen.

Eine erfindungsgemäße Recheneinheit, z.B. ein Steuergerät oder ein Zentralrechner eines Kraftfahrzeugs, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.

Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Schließlich ist ein maschinenlesbares Speichermedium vorgesehen mit einem darauf gespeicherten Computerprogramm wie oben beschrieben. Geeignete Speichermedien bzw. Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash- Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich. Ein solcher Download kann dabei drahtgebunden bzw. kabelgebunden oder drahtlos (z.B. über ein WLAN- Netz, eine 3G-, 4G-, 5G- oder 6G-Verbindung, etc.) erfolgen.

Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.

Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.

Kurze Beschreibung der Zeichnungen

Figur 1 zeigt schematisch ein Fahrzeug zur Erläuterung einer bevorzugten Ausführungsform der Erfindung. Figur 2 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.

Ausführungsform(en) der Erfindung

In Figur 1 ist schematisch ein Fahrzeug 100 zur Erläuterung einer bevorzugten Ausführungsform der Erfindung dargestellt. Das Fahrzeug 100 weist beispielhaft eine als Zentralrechner 110 ausgebildete Recheneinheit 110 auf, an die beispielhaft über eine Kommunikationsverbindung bzw. einen Bus 120 zwei Steuergeräte 122 und 124 angebunden sind.

An die Steuergeräte 122, 124 wiederum sind beispielhaft Sensoren 130, 132, 134 und 136 sowie Aktoren 140, 142 angebunden. Bei den Sensoren kann es sich z.B. um Kameras, Radar-, Ultraschall, oder Lidarsensoren, Drehzahlmesser oder andere Messgeber oder Messgeräte handeln, ebenso z.B. um Inertialsenso- ren. Bei den Aktoren kann es sich z.B. um Bremsaktoren, Lenkaktoren oder sonstige Stellglieder handeln. Die Sensoren, Aktoren und Steuergeräte erzeugen während des Betriebs des Fahrzeugs 100 Signale oder Daten bzw. allgemein Fahrzeugdaten, die beispielhaft mit 160 bezeichnet sind. Diese Daten bzw. Signale liegen auf der Kommunikationsverbindung 120 an und können vom Zentralrechner 110 gelesen bzw. erfasst werden.

Im bzw. auf dem Zentralrechner 110 wird ein Datenfilter 112 mit einer Konfiguration 114 ausgeführt. Die Fahrzeugdaten 160 dienen als Eingangsdaten für den Datenfilter 112. Mittels des Datenfilters 112 werden aus den Eingangsdaten entsprechend der Konfiguration 114 bestimmte Anteile der Fahrzeugdaten ausgewählt und als Ausgangsdaten 170 z.B. drahtlos an einen Server 190 oder eine andere fahrzeugfremde Recheneinheit, also nach extern, übermittelt. Dort kann dann z.B. von einem Entwickler auf die Ausgangsdaten 170 zugegriffen werden, um sie für eine Analyse zu verwenden.

Weiterhin sind beispielhaft zwei weitere Fahrzeuge 102, 104 angedeutet, auf deren Zentralrechner ebenfalls ein Datenfilter mit entsprechender Konfiguration vorhanden sein kann. Damit soll verdeutlicht werden, dass ein solcher Datenfilter auf einer Vielzahl von z.B. im Feld befindlichen Fahrzeugen vorhanden sein und angewendet werden kann, um bestimmte Fahrzeugdaten von dieser Vielzahl an Fahrzeugen sammeln zu können.

In Figur 2 ist schematisch ein Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt. Hierzu ist ein Datenfilter 212 gezeigt, der z.B. dem Datenfilter 112 in Figur 1 entsprechen kann.

Während des Betriebs des Fahrzeugs werden Fahrzeugdaten, also verschiedene Signale erfasst und als Eingangsdaten dem Datenfilter 212 zugeführt. Beispielhaft sind vier Signale 260, 262, 264, 266 gezeigt. Der Datenfilter 212 weist eine Konfiguration 214 auf, durch beispielhaft zwei Bedingungen 216, 218 vorgegeben ist. Die Bedingung 216 kann z.B. umfassen, dass nur Signale der Art 260 und 262 betrachtet werden. Die Bedingung 218 kann dann umfassen, dass von den betrachteten Signalen ein Signal, z.B. das der Art 260, zeitlich vor dem Signal der Art 262, einen Wert eins annehmen muss. Diese Bedingungen könne dabei derart formuliert sein, dass sie bei regulärem Betrieb nie erfüllt werden, weil z.B. das Signal 260 nie vor, allenfalls nach dem Signal 262 den Wert eins annimmt.

Entsprechend werden nur dann, wenn ein Fehler vorliegt, beide Bedingungen 216 und 218 erfüllt und es werden Daten 270, z.B. eine Information darüber, dass ein Fehler aufgetreten ist, als Ausgangsdaten bereitgestellt.

Bei einer anderen Konfiguration kann z.B. auch nur die Bedingung vorgegeben sein, dass nur Signale der Art 264 betrachtet werden, die dann aber auch immer (ggf. direkt) als Ausgangsdaten ausgegeben werden.

Auf diese Weise können sehr schnell und flexible gewünschte Datenfilter in einer Vielzahl von Fahrzeugen verwendet werden, um gewünschten Fahrzeugdaten zu gewinnen.

Wichtig hierbei ist, dass die Konfiguration 214 auch spezifiziert, welche Daten bei Erfüllung einer Bedingung (Triggerbedingung) 216, 218 bereitgestellt bzw. ge- speichert werden sollen. Das können auch andere als die für die Triggerbedingungen verwendeten Signale (Fahrzeugdaten), also hier 260, 262, sein. Es ist ein bevorzugter Anwendungsfall, dass z.B. auf einfache skalare Signale getriggert wird, danach dann aber das Kamera-Bild zusätzlich gespeichert werden soll. Es können also, wie eingangs beschrieben, nicht nur Daten aus den Fahrzeugdaten ausgewählt, werden, sondern ggf. auch andere Daten erzeugt werden.