WO2023165887A1 - Verfahren zum bereitstellen von daten in einem fahrzeug - Google Patents

Verfahren zum bereitstellen von daten in einem fahrzeug Download PDF

Info

Publication number
WO2023165887A1
WO2023165887A1 PCT/EP2023/054521 EP2023054521W WO2023165887A1 WO 2023165887 A1 WO2023165887 A1 WO 2023165887A1 EP 2023054521 W EP2023054521 W EP 2023054521W WO 2023165887 A1 WO2023165887 A1 WO 2023165887A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
vehicle
configuration
filter
signals
Prior art date
Application number
PCT/EP2023/054521
Other languages
English (en)
French (fr)
Inventor
Wolfgang Hauck
Krisztian NYILAS
Antonia Reiter
Klaus Grabmaier
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2023165887A1 publication Critical patent/WO2023165887A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • the present invention relates to a method for providing data in a vehicle using a data filter and a computing unit and a computer program for its implementation.
  • data generated in the vehicles can be recorded and analyzed in order to check various functions and find any errors, for example.
  • One way to obtain such data is, for example, to use a specially configured measurement computer in the vehicle that records the desired data.
  • the invention deals with the provision and in particular the collection of data, in particular signals, in a vehicle or which occur in a vehicle, specifically in particular during the operation of the vehicle.
  • a special ell configured measuring computer in the vehicle which records the desired data.
  • this involves a great deal of effort and is generally not practicable, particularly in the case of a large number of vehicles.
  • vehicles that are already in series production and are being driven by customers can sometimes provide relevant data for development (so-called field data).
  • field data relevant data for development
  • This data filter can be executed, for example, as a software module on a computing unit, in particular a control unit or central computer (then, for example, as part of what is known as "vehicle edge computing") of a vehicle.
  • a control unit or central computer then, for example, as part of what is known as "vehicle edge computing" of a vehicle.
  • vehicle data occurring in the vehicle are received as input data for the data filter.
  • the data filter or the relevant software module can be allowed to access, for example, one or more buses or other communication media in the vehicle in order, for example, to be able to record or read out all of the vehicle data occurring in the vehicle.
  • This vehicle data occurring in the vehicle includes, for example, the signals and/or messages generated by sensors and/or actuators and/or control devices during operation of the vehicle. It should be mentioned that depending on the type and use of the data file ters does not necessarily have to be able to record or read out all vehicle data, although this is expedient. Depending on the application, for example, the vehicle data occurring on a special bus or from certain sensors/actuators or control units may be sufficient.
  • the data filter By applying the data filter, with a provided configuration, to the input data, data are then selected and/or generated from the input data that meet one or more conditions specified by means of the provided configuration.
  • the selected and/or generated data (possibly in the form of signals) are then provided as output data, if available.
  • the output data provided is advantageously output externally, i.e. outside the vehicle, in particular by means of wireless communication.
  • the output data can be transmitted to a server from where it can be accessed and used by a developer or other authorized person.
  • the resulting vehicle data is then analyzed and, if necessary, the corresponding output data is determined and made available and, if necessary, transmitted externally.
  • a trigger or trigger framework since whenever the vehicle data or input data meet the conditions specified by the configuration, output data is determined or generated and, if necessary, transmitted.
  • the one or more conditions specified by means of the configuration provided are in an ab- trained form comprising data identifiers.
  • a formal description language can be selected.
  • an assignment of such abstract designations (the data identifiers) to the (actual) vehicle signals or vehicle data is then to be provided, for example in the form of an assignment table.
  • An abstract description of the input and output data in the configuration makes it possible to be independent of the specific vehicle architecture, E/E architecture and vehicle function.
  • This abstract description of data filters can be implemented using a formal language, which is used in the same way across different vehicle types, manufacturers, etc. and can therefore also be reused.
  • the assignment (or conversion) between abstract designations (the data designators) and the (actual) vehicle signals or vehicle data is preferably carried out automatically in or during the application by means of a configuration file (mapping) between the signal and the elements of the formal language used.
  • a component upstream of the data filter can be provided, which automatically translates the notation of a formal language into byte code (e.g. in the manner of an "STL compiler", STL see below), i.e. the conditions (trigger condition) are always described in the formal language , no code is generated manually.
  • This translation into bytecode can, for example, take place outside the vehicle (the upstream component is then located outside the vehicle) and only the translated bytecode is transmitted to the vehicle; However, it is also possible to interpret the trigger condition at runtime, in which case the upstream component is in the vehicle.
  • the latter preferably takes place in the development phase and with so-called “rapid prototyping", the former preferably takes place in the environment of regulated operating conditions (where, for example, the effect of this change in the runtime behavior should or must be tested and secured in advance).
  • the data filter is applied, in particular a check as to whether the one or more conditions specified by means of the configuration provided are met, using a temporal log gik of signals.
  • This temporal (temporal) logic of signals is also known under the term "Signal Temporal Logic", STL.
  • Temporal logics or time logics are extensions of logic that can be used to capture time sequences. These are, for example, applications of modal logic based on a before-after relationship between points in time.
  • a temporal logic of signals deals in particular with the temporal sequences of signals, in the present case the signals (or generally data or also messages) in the vehicle.
  • real-time restrictions or real-time conditions are taken into account as they occur or can occur during operation of the vehicle; restrictions or conditions of the actually possible values can also be taken into account, e.g. specially adapted for the signals or data possible in the vehicle. More detailed explanations and explanations of the temporal logic of signals can be found, for example, in
  • temporal logic of signals makes it possible to specify or define certain conditions (such as patterns or criteria) for signals or data, and not just individual signals, but also the combination of several signals, which, for example, must be fulfilled or may not be fulfilled. For example, it can be the case for two specific signals in the vehicle that they can never assume the same value at the same time—with regular operation or without errors. If this is the case, an error can be assumed. This makes it possible, for example, to create a configuration with conditions for a data filter in which - if there is no error - no output data that could be provided is obtained.
  • output data is obtained with this configuration when the relevant data filter is used, it can be concluded that there is an error, for example in one of the two signals or in the units generating these signals (sensor, actuator, control unit).
  • temporal logic of signals also allows certain signals or combinations Nations of signals (or data) that are important, for example, for a specific development project or a specific problem, to be filtered out of the input data and then made available accordingly as output data.
  • the above-mentioned component can then be used to translate these conditions into bytecode, for example, so that the relevant control unit knows which signals are to be observed in order to know the speed of the vehicle, for example.
  • a received signal (which is then available, for example, as a byte code) can be translated back into the formal description.
  • the data filter is preferably activated or deactivated using information obtained from outside, i.e. from outside the vehicle, in particular by means of wireless communication (so-called "Over The Air", OTA), for activating or deactivating the data filter.
  • OTA Over The Air
  • the data filter can therefore be present on a computing unit of the vehicle, e.g. as the software module mentioned on a e.g. specially provided memory area, but can only be activated when required and then deactivated again if necessary.
  • a development team may be interested in certain signals or their properties at a certain point in time.
  • the data filter stored on the computing unit can be activated with the appropriate configuration for a specific period of time.
  • the configuration is selected from a plurality of configurations using information obtained externally, i.e. from outside the vehicle, in particular by means of wireless communication.
  • information obtained externally i.e. from outside the vehicle, in particular by means of wireless communication.
  • Several - in particular different - configurations can therefore be stored for the data filter, which e.g. determine different output data from the input data.
  • one of the configurations can then be selected; this can be done, for example, by transmitting a corresponding command (information for selecting the configuration) to the vehicle or the executing computing unit.
  • the data filter When the data filter is activated with a (selected) configuration, the resulting Vehicle data is analyzed and, if necessary, the corresponding output data is determined and made available and, if necessary, transmitted externally. In this sense, one can also speak of a trigger or trigger framework, since whenever the vehicle data or input data meet the conditions specified by the configuration, output data is determined or generated and, if necessary, transmitted.
  • the configuration is obtained externally, i.e. from outside the vehicle, in particular by means of wireless communication.
  • the configuration can, for example, already be provided on the executing processing unit when the vehicle is manufactured (e.g. in the frame or comparable to a so-called variant coding of vehicles), but it can also be transmitted there later. This is of interest, for example, if a specific configuration only becomes relevant or known later. Multiple configurations can also be obtained in this way; existing configurations can also be supplemented with additional configurations in this way. One or more existing configurations can also be updated (updated) in this way.
  • applying the data filter includes using a machine learning algorithm such as an artificial neural network.
  • the machine learning algorithm can be used to apply certain calculations or criteria to the input data for the data filter, for example - according to the configuration - in order to obtain the output data.
  • a machine learning algorithm can, for example, only be used for subtasks thereof, e.g. also for the preselection of input data to be ultimately checked and/or for the preprocessing of input data for the application of the temporal logic for signals. It is therefore also possible to integrate complex calculation steps, regardless of the specific application.
  • a neural network can, for example, be integrated into the pre-processing chain of the signals, in that the output signal of the neural network is in turn fed into the data filter as an input (input data).
  • the data filter depict the function of a "sensor blindness" and the data filter then outputs data if a sensor blindness of the front camera is continuously detected over a specified period of time (e.g. 300ms).
  • a sensor blindness of the front camera is continuously detected over a specified period of time (e.g. 300ms).
  • An application for this could be that, for example, movements of the windshield wiper are to be sorted out as false positives.
  • any type of complex calculations can thus be outsourced from the data filter and only the time dependency of the complex calculations can be modeled at the output signal level. This separates the complex detection logic from the timing and interdependencies.
  • the vehicle data are advantageously provided, including at least the application of the data filter, but in particular also the receipt of the input data and the provision of the output data, only if one or more criteria relating to a runtime behavior are met.
  • the provision of the vehicle data is also aborted if one or at least one of the multiple criteria is no longer met.
  • the data filter is used, including the provision and, if necessary, the transmission of the output data at runtime. Computing resources are therefore used on the executing computing unit. It should therefore be ensured that the tasks for which the computing unit (e.g. control unit, central computer) is actually or primarily intended can also be carried out.
  • the application of the data filter can and should be interrupted or, if necessary, not started at all. Criteria that can be considered are, for example, a certain proportion of freely available computing power and/or memory space or the absence of safety-critical control interventions.
  • An application of such a data filter in the area of safety-critical systems can also be made possible by reserving the required protected memory area on the executing processing unit in advance, whereby it should be ensured that changes in scope and configuration guration of the data filter move exclusively within the limits of the previously reserved protected memory area and runtime budget.
  • a computing unit e.g. a control unit or a central computer of a motor vehicle, is set up, in particular in terms of programming, to carry out a method according to the invention.
  • a machine-readable storage medium is provided with a computer program stored thereon as described above.
  • Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical and electrical storage devices such as hard drives, flash memories, EEPROMs, DVDs, etc.
  • FIG. 1 schematically shows a vehicle to explain a preferred embodiment of the invention.
  • FIG. 2 schematically shows a sequence of a method according to the invention in a preferred embodiment.
  • Vehicle 100 has, for example, a computing unit 110 embodied as central computer 110 , to which two control devices 122 and 124 are connected, for example via a communication connection or a bus 120 .
  • Sensors 130, 132, 134 and 136 and actuators 140, 142 are in turn connected to control units 122, 124, for example.
  • the sensors can be, for example, cameras, radar, ultrasonic or lidar sensors, tachometers or other sensors or measuring devices, as well as, for example, inertial sensors.
  • the actuators can be, for example, brake actuators, steering actuators or other actuators.
  • the sensors, actuators and control devices generate signals or data or vehicle data in general, which are denoted by 160 by way of example. These data or signals are present on the communication connection 120 and can be read or recorded by the central computer 110 .
  • a data filter 112 with a configuration 114 is executed in or on the central computer 110 .
  • Vehicle data 160 serves as input data for data filter 112.
  • Data filter 112 is used to select certain parts of the vehicle data from the input data according to configuration 114 and transmit them as output data 170, e.g. wirelessly to a server 190 or another non-vehicle computing unit, i.e. externally.
  • a developer for example, can then access the output data 170 there in order to use it for an analysis.
  • two further vehicles 102, 104 are indicated by way of example, on the central computer of which a data filter with a corresponding configuration can also be present. This should make it clear that such a data filter be present and used on a large number of vehicles, for example, in the field, in order to be able to collect certain vehicle data from this large number of vehicles.
  • FIG. 2 shows a sequence of a method according to the invention in a preferred embodiment.
  • a data filter 212 is shown for this purpose, which can correspond, for example, to the data filter 112 in FIG.
  • vehicle data that is to say various signals
  • vehicle data that is to say various signals
  • Four signals 260, 262, 264, 266 are shown as an example.
  • the data filter 212 has a configuration 214, which is specified by two conditions 216, 218, for example.
  • condition 216 may include that only signals of types 260 and 262 are considered.
  • the condition 218 can then include that, of the signals under consideration, a signal, e.g. These conditions can be formulated in such a way that they are never met during regular operation because, for example, signal 260 never assumes the value one before, at best after signal 262.
  • both conditions 216 and 218 are only met if there is an error, and data 270, for example information about the fact that an error has occurred, is provided as output data.
  • desired data filters can be used very quickly and flexibly in a large number of vehicles in order to obtain desired vehicle data.
  • the configuration 214 also specifies which data is provided or given when a condition (trigger condition) 216, 218 is met. are to be saved. These can also be signals (vehicle data) other than those used for the trigger conditions, ie here 260, 262.
  • a preferred application is, for example, to trigger on simple scalar signals, but then the camera image is then also to be saved. As described at the outset, not only can data be selected from the vehicle data, but other data can also be generated if necessary.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Bereitstellen von Daten in einem Fahrzeug (100), umfassend: Erhalten von im Fahrzeug (100) anfallenden Fahrzeugdaten (160) als Eingangsdaten für einen Datenfilter (112); Anwenden des Datenfilters (112), mit einer bereitgestellten Konfiguration (114), auf die Eingangsdaten, wobei aus den Eingangsdaten Daten ausgewählt und/oder erzeugt werden, die eine oder mehreren mittels der bereitgestellten Konfiguration (114) vorgegebene Bedingungen erfüllen, wobei die eine oder die mehreren mittels der bereitgestellten Konfiguration vorgegebenen Bedingungen in einer gegenüber den Fahrzeugdaten abstrahierten Form, aufweisend Datenbezeichner, vorliegen; und Bereitstellen der ausgewählten und/oder erzeugten Daten, sofern vorhanden, als Ausgangsdaten (170)

Description

Beschreibung
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/s2 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.

Claims

Ansprüche
1. Verfahren zum Bereitstellen von Daten in einem Fahrzeug (100), umfassend:
Erhalten von im Fahrzeug (100) anfallenden Fahrzeugdaten (160, 260, 262, 264, 266) als Eingangsdaten für einen Datenfilter (112, 212), Anwenden des Datenfilters (112, 212), mit einer bereitgestellten Konfiguration (114, 214), auf die Eingangsdaten, wobei aus den Eingangsdaten Daten ausgewählt und/oder erzeugt werden, die eine oder mehreren mittels der bereitgestellten Konfiguration (114, 214) vorgegebene Bedingungen (216, 218) erfüllen, wobei die eine oder die mehreren mittels der bereitgestellten Konfiguration vorgegebenen Bedingungen (216, 218) in einer gegenüber den Fahrzeugdaten abstrahierten Form, aufweisend Datenbezeichner, vorliegen, und
Bereitstellen der ausgewählten und/oder erzeugten Daten, sofern vorhanden, als Ausgangsdaten (170, 270).
2. Verfahren nach Anspruch 1 , wobei das Anwenden des Datenfilters (112, 212), insbesondere eine Prüfung, ob die eine oder die mehreren mittels der bereitgestellten Konfiguration vorgegebenen Bedingungen (216, 218) erfüllt sind, unter Verwendung einer temporalen Logik von Signalen erfolgt.
3. Verfahren nach Anspruch 1 oder 2, wobei das Anwenden des Datenfilters (112, 212), mit einer bereitgestellten Konfiguration (114, 214), auf die Eingangsdaten das Verwenden einer Zuordnung zwischen den Eingangsdaten und den Datenbezeichnern umfasst.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei die bereitgestellten Ausgangsdaten (170, 270) nach extern, insbesondere mittels drahtloser Kommunikation, ausgegeben werden.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei der Datenfilter (112, 212) anhand einer von extern, insbesondere mittels drahtloser Kommunikation, erhaltenen Information zum Aktiveren oder Deaktivieren des Datenfilters aktiviert oder deaktiviert wird.
6. Verfahren nach einem der vorstehenden Ansprüche, wobei die Konfiguration (114, 214) anhand einer von extern, insbesondere mittels drahtloser Kommunikation, erhaltenen Information zum Auswahlen der Konfiguration aus mehreren Konfigurationen ausgewählt wird.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei die Konfiguration (114, 214) von extern, insbesondere mittels drahtloser Kommunikation, erhalten oder aktualisiert wird.
8. Verfahren nach einem der vorstehenden Ansprüche, wobei mehrere Datenfilter (112, 212) mit jeweils einer Konfiguration (114, 214) zum Bestimmen und Bereitstellen von jeweiligen Ausgangsdaten (170, 270) verwendet werden.
9. Verfahren nach einem der vorstehenden Ansprüche, wobei das Anwenden des Datenfilters (112, 212) eine Verwendung eines Maschinenlernalgorithmus umfasst.
10. Verfahren nach einem der vorstehenden Ansprüche, wobei das Anwenden des Datenfilters (112, 212) nur dann erfolgt, wenn ein oder mehrere Kriterien bezüglich eines Laufzeitverhaltens erfüllt sind, und insbesondere abgebrochen wird, wenn das eine oder zumindest eines der mehreren Kriterien nicht mehr erfüllt sind.
11 . Verfahren nach einem der vorstehenden Ansprüche, wobei die im Fahrzeug (100) anfallenden Fahrzeugdaten (160, 260, 262, 264, 266) während eines Betriebs des Fahrzeugs von Sensoren (130, 132, 134, 136) und/oder Aktoren (140, 142) und/oder Steuergeräten (122, 124) erzeugte Signale und/oder Nachrichten umfassen.
12. Recheneinheit (110), insbesondere Steuergerät oder Zentralrechner eines Fahrzeugs, die dazu eingerichtet ist, alle Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche durchzuführen.
13. Computerprogramm, das eine Recheneinheit (110) dazu veranlasst, alle Verfahrensschritte eines Verfahrens nach einem der Ansprüche 1 bis 11 durchzuführen, wenn es auf der Recheneinheit (110) ausgeführt wird.
14. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Com- puterprogramm nach Anspruch 13.
PCT/EP2023/054521 2022-03-01 2023-02-23 Verfahren zum bereitstellen von daten in einem fahrzeug WO2023165887A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022202071.5A DE102022202071A1 (de) 2022-03-01 2022-03-01 Verfahren zum Bereitstellen von Daten in einem Fahrzeug
DE102022202071.5 2022-03-01

Publications (1)

Publication Number Publication Date
WO2023165887A1 true WO2023165887A1 (de) 2023-09-07

Family

ID=85384544

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/054521 WO2023165887A1 (de) 2022-03-01 2023-02-23 Verfahren zum bereitstellen von daten in einem fahrzeug

Country Status (2)

Country Link
DE (1) DE102022202071A1 (de)
WO (1) WO2023165887A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19915097A1 (de) * 1999-04-01 2000-10-12 Siemens Ag Vorrichtung und Verfahren zur insbesondere mobilen Datenerfassung
DE102016009195B3 (de) * 2016-07-27 2017-12-07 Audi Ag Verfahren zum Extrahieren von Fahrzeugdaten aus einem Kraftfahrzeug, Steuervorrichtung und Kraftfahrzeug
US20210306437A1 (en) * 2019-07-11 2021-09-30 Ghost Locomotion Inc. Transmitting remotely valued data in an autonomous vehicle

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004015163A1 (de) 2004-02-13 2005-08-25 Volkswagen Ag Verfahren und Einrichtung zur Diagnose von Fahrzeugen
DE102019119460A1 (de) 2019-07-18 2021-01-21 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Steuern eines maschinellen Lernverfahrens einer Funktion eines Fahrzeugs, computerlesbares Medium, System, und Fahrzeug
DE102020113193B4 (de) 2020-05-15 2023-03-16 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Verarbeiten von Sensordaten zur Übermittlung an eine zentrale Einheit

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19915097A1 (de) * 1999-04-01 2000-10-12 Siemens Ag Vorrichtung und Verfahren zur insbesondere mobilen Datenerfassung
DE102016009195B3 (de) * 2016-07-27 2017-12-07 Audi Ag Verfahren zum Extrahieren von Fahrzeugdaten aus einem Kraftfahrzeug, Steuervorrichtung und Kraftfahrzeug
US20210306437A1 (en) * 2019-07-11 2021-09-30 Ghost Locomotion Inc. Transmitting remotely valued data in an autonomous vehicle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SCHUMANN JOHANN ET AL: "Runtime Analysis with R2U2: A Tool Exhibition Report", 20 September 2016, SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 504 - 509, ISBN: 978-3-540-74549-5, XP047354315 *

Also Published As

Publication number Publication date
DE102022202071A1 (de) 2023-09-07

Similar Documents

Publication Publication Date Title
WO2021121695A1 (de) Verfahren, vorrichtung und system zur detektion von anomalen betriebszuständen eines geräts
EP0768584B1 (de) Verfahren zur Überwachung einer Maschine oder Anlage
DE102008013366A1 (de) Verfahren zur Bereitstellung von Information für Fahrerassistenzsysteme
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
DE102018221063A1 (de) Konfiguration eines Steuerungssystems für ein zumindest teilautonomes Kraftfahrzeug
EP2102723B1 (de) Verfahren und vorrichtung zum diagnostizieren von funktionen und fahrzeugsystemen
DE102020204714A1 (de) Verfahren und Vorrichtung zum Prüfen der Kompatibilität zwischen einer Anwendungssoftware und einer mobilen Arbeitsmaschine
WO2023165887A1 (de) Verfahren zum bereitstellen von daten in einem fahrzeug
DE102019213061A1 (de) Klassifizierung von KI-Modulen
DE102019203205A1 (de) Verfahren zum Auswerten von Fahrzeugdaten sowie Fahrzeugdatenauswertesystem zum Durchführen eines derartigen Verfahrens
DE102021206297A1 (de) Verfahren und System zum Betreiben eines wenigstens teilweise automatisierten Fahrzeugs
DE102016208076A1 (de) Verfahren und vorrichtung zur auswertung eines eingabewerts in einem fahrerassistenzsystem, fahrerassistenzsystem und testsystem für ein fahrerassistenzsystem
DE102017214610B4 (de) Verfahren zum Überprüfen von zumindest einer Fahrzeugfunktion sowie Prüfvorrichtung
DE102015214987A1 (de) Bestimmung eines defekten Bauteils eines Fahrzeugs
DE102018214414A1 (de) Verfahren zum Testen eines Kraftfahrzeugs
DE102018009451A1 (de) Verfahren zum Überprüfen wenigstens eines Fahrzeugs sowie elektronische Recheneinrichtung
DE102021111724B4 (de) Verfahren und Computerprogramm zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
EP3644582B1 (de) Verfahren, vorrichtung und zentraleinrichtung zum erkennen einer verteilungsverschiebung in einer daten- und/oder merkmalsverteilung von eingangsdaten
DE102021214334B3 (de) Fahrzeugdatensystem und Verfahren zur Ermittlung von relevanten bzw. übertragenswerten Fahrzeugdaten eines Umgebungserfassungssensors
DE102023000357B3 (de) Verfahren zum Erzeugen von Testdaten für eine Simulation eines Assistenzsystems eines zumindest teilweise assistiert betriebenen Kraftfahrzeugs, Computerprogrammprodukt, computerlesbares Speichermedium sowie elektronische Recheneinrichtung
WO2023237274A1 (de) Konzept zum auswählen von audioausschnitten von bremsquietschgeräuschen in einem fahrzeug
EP4312127A1 (de) Vorrichtung und verfahren zur prüfung einer ki-basierten sicherheitsfunktion eines steuerungssystems eines fahrzeugs
DE202021004237U1 (de) Computerlesbares Speichermedium und Rechenvorrichtung zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
DE102021106863A1 (de) Fahrsystem zum automatisierten fahren mit einem lautsprecher zur akustischen informationsausgabe, entsprechendes verfahren und entsprechende software

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23707691

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023707691

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023707691

Country of ref document: EP

Effective date: 20241001