Method for providing data in a vehicle

Abstract

The invention relates to a method for providing data in a vehicle (100), comprising: obtaining vehicle data (160) accumulating in the vehicle (100) as input data for a data filter (112); applying the data filter (112) with a provided configuration (114) to the input data, wherein data are selected and / or generated from the input data, which meet one or more conditions specified by the provided configuration (114), wherein the one or more conditions specified by the provided configuration are present in a form which is abstracted with respect to the vehicle data, comprising data identifiers; and providing the selected and / or generated data, if present, as output data (170).

Description

[0001] Description

[0002] title

[0003] Method for providing data in a vehicle

[0004] The present invention relates to a method for providing data in a vehicle using a data filter as well as a computing unit and a computer program for carrying out the method.

[0005] Background of the invention

[0006] During vehicle development, both before and after series production, data generated in the vehicles, such as sensor signals, can be recorded and analyzed to test various functions and identify any errors. One way to obtain such data is to use a specially configured measurement computer in the vehicle that records the desired data.

[0007] Disclosure of the invention

[0008] According to the invention, a method for providing data, as well as a computing unit and a computer program for implementing the method, are proposed, having the features of the independent patent claims. Advantageous embodiments are the subject of the dependent claims and the following description.

[0009] The invention relates to the provision and, in particular, collection of data, in particular signals, in a vehicle or which arise in a vehicle, in particular during operation of the vehicle. In order to obtain such data, as mentioned above, the use of a specially configured measuring computer in the vehicle which records the desired data is conceivable. However, this involves a great deal of effort and is generally not practical, particularly with a large number of vehicles. It has also been shown that vehicles which are already in series production and are driven by customers, for example, can sometimes provide relevant data for development (so-called field data). The use of a measuring computer is not conceivable here.

[0010] In addition, a large amount of such data is generated, especially in modern vehicles, as the number of sensors, actuators, and control units or functions in the vehicle, for example, for automated driving, increases. It can be difficult to find the specific data required. Furthermore, collecting all vehicle data from a large number of vehicles would generally not be feasible, especially if, for example, wireless transmission of the vehicle data to a server for further use is to be considered.

[0011] Against this background, the use or application of a special data filter in the vehicle is proposed. This data filter can be implemented, for example, as a software module on a computing unit, in particular a control unit or central computer (then, for example, within the framework of so-called "vehicle edge computing") of a vehicle. In light of the above explanations, it is particularly expedient if such a data filter is used on a large number of vehicles.

[0012] In this case, vehicle data generated in the vehicle is received as input data for the data filter, particularly during vehicle operation. For this purpose, the data filter or the relevant software module can be granted access to, for example, one or more buses or other communication media in the vehicle in order to be able to record or read out all vehicle data generated in the vehicle. This vehicle data generated in the vehicle includes, for example, the signals and / or messages generated by sensors and / or actuators and / or control units during vehicle operation. It should be noted that, depending on the type and use of the data filter, it may not necessarily be possible to record or read out all vehicle data, although this is expedient. For example, depending on the application, the vehicle data generated on a specific bus or by specific sensors / actuators or control units may be sufficient.

[0013] By applying the data filter, with a provided configuration, to the input data, data is then selected and / or generated from the input data that fulfills one or more conditions specified by the provided configuration. The selected and / or generated data (possibly in the form of signals), if available, is then provided as output data. Advantageously, the provided output data is output externally, i.e., outside the vehicle, in particular via wireless communication. In this way, the output data can be transmitted, for example, to a server, from where it can be retrieved and used by a developer or other authorized party.

[0014] When the data filter is activated, the resulting vehicle data is analyzed, and if necessary, corresponding output data is determined and provided, and if necessary, transmitted externally. In this sense, it can also be referred to as a trigger or trigger framework, since whenever the vehicle data or input data meets the conditions specified by the configuration, output data is determined or generated and, if necessary, transmitted.

[0015] As will be explained in more detail later, it may also happen that when applying a specific configuration or a specific data filter, no data is selected and / or generated from the input data, namely if the input data does not meet the conditions, for example, or at least not during normal operation, but only in the event of an error, for example. This is precisely what the present invention is intended to exploit in particular.

[0016] In addition, the one or more conditions specified by means of the provided configuration are present in a form that is abstracted from the vehicle data and comprises data identifiers. For example, a formal description language can be selected. For this purpose, an assignment of such abstract designations (the data identifiers) to the (actual) vehicle signals or vehicle data must then be provided, e.g. 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 that can be used uniformly across different vehicle types, manufacturers, etc. and can therefore also be reused.

[0017] The assignment (or conversion) between abstract designations (the data identifiers) and the (actual) vehicle signals or vehicle data is particularly 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.

[0018] A component can be provided upstream of the data filter that automatically translates the notation of a formal language into bytecode (e.g., in the manner of an "STL compiler"; for STL, see below). This means that the description of the conditions (trigger condition) is always in the formal language; no code is manually generated. 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 located inside the vehicle. The latter is preferably done, for example, during the development phase and in so-called "rapid prototyping," while the former is preferably done in an environment with regulated operating conditions (where, for example, the impact of this change in runtime behavior should or must be tested and validated in advance).

[0019] Particularly preferably, the application of the data filter, in particular a check to determine whether one or more conditions specified by the provided configuration are met, is carried out using a temporal logic of signals. This 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 capture temporal sequences. These are, for example, applications of modal logic based on a before-and-after relationship between points in time.

[0020] A temporal logic of signals (STL) then deals in particular with the temporal sequences of signals, in this case the signals (or generally data or messages) in the vehicle. In particular, real-time constraints or real-time conditions are taken into account, as they occur or can occur during the operation of the vehicle; likewise, constraints or conditions of the actually possible values ​​can be considered, e.g., specifically adapted for the signals or data possible in the vehicle. Further details and explanations on the temporal logic of signals can be found, for example, in

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

[0022] The use of temporal logic for signals makes it possible to specify or define certain conditions (such as patterns or criteria) for signals or data, not just for individual signals but also for combinations of multiple signals, which conditions must or must not be met. For example, it may be the case for two specific signals in a vehicle that - during normal operation or without errors - they can never assume the same value at the same time. If this is the case, it can be assumed that there is an error. This makes it possible, for example, to create a configuration with conditions for a data filter which, if there is no error, does not produce any output data that could be provided. If, on the other hand, output data is produced when the data filter in question is applied with this configuration, it can be concluded that there is an error, for example with one of the two signals.of the units that generate these signals (sensor, actuator, control unit). The use of temporal logic of signals also allows specific signals or combinations of signals (or data) that are relevant, for example, for a specific development project or problem to be filtered out of the input data and then provided as output data.

[0023] By using a formal language, mathematically provable system properties can be guaranteed (e.g. minimum distance), or even statistical argumentation can be derived if, for example, no data on specified malfunctions can be collected over a large vehicle / kilometer / operating hour sample.

[0024] An example of conditions in formal language using STL is given below: float vx, ax; bool PersonDetection; formula = once[0s, 2s, ax <= 0] and once[2s, 2.1s, PersonDetection] and always[2s, 2.1s, vx > 2];

[0025] This sets conditions for the speed (vx) and acceleration (ax) of the vehicle in the x- and longitudinal directions, respectively, as well as the detection of a person by means of a camera (PersonDetection). If a person is detected while the vehicle is traveling faster than 2 ms / s, and the acceleration is less than or equal to 0 m / s within the next 2 seconds, 2 If the system is inactive, then data should be recorded and output. This is because braking is assumed to be due to person detection. The terms "once" and "always" correspond to standard STL conditions.

[0026] Using the aforementioned component (STL compiler), these conditions can then be translated into bytecode, for example, so that the relevant control unit knows which signals are to be observed in order to determine, for example, the vehicle's speed. Accordingly, a received signal (which is then available as bytecode, for example) can be translated back into the formal description. Not only can one such data filter be provided with one configuration, but several such data filters can also be provided on a vehicle or a computing unit of a vehicle (or even on different computing units of the vehicle). These can then be used for different purposes, but fundamentally function in the same way. Different data filters can, but do not have to, access the same vehicle data. The output data of different filters will generally be different, but may also be the same, even if, for example,the types of data filters and their configurations are different.

[0027] Preferably, the data filter is activated or deactivated based on information received externally, i.e., from outside the vehicle, in particular via wireless communication (so-called "Over The Air", OTA), for activating or deactivating the data filter. The data filter can therefore, in principle, be present on a computing unit of the vehicle, e.g., as the aforementioned software module in a specially designated memory area, but can only be activated when needed and then deactivated again if necessary. For example, a development team may be interested in certain signals or their properties at a specific time. For this purpose, the data filter—stored on the computing unit—can be activated with the appropriate configuration for a specific period of time.

[0028] Advantageously, the configuration is selected from several configurations based on information received externally, i.e., from outside the vehicle, in particular via wireless communication. Thus, several—in particular different—configurations can be stored for the data filter, which, for example, determine different output data from the input data. Depending on the current requirement, 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 processing unit.

[0029] When the data filter is activated with a (selected) configuration, the resulting vehicle data is analyzed, particularly during vehicle operation – at runtime – and, if necessary, corresponding output data is determined and provided, 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 meets the conditions specified by the configuration, output data is determined or generated and, if necessary, transmitted.

[0030] It is also advantageous if the configuration is received externally, i.e. from outside the vehicle, in particular by means of wireless communication. Although the configuration can, for example, be provided on the executing processing unit during vehicle manufacture (e.g. as part of or in a similar way to so-called variant coding of vehicles), it can also be transmitted there later. This is of interest, for example, if a certain configuration only becomes relevant or known later. Several configurations can be received in this way; further configurations can also be added to existing configurations in this way. One or more existing configurations can also be updated in this way.

[0031] Preferably, applying the data filter involves using a machine learning algorithm, such as an artificial neural network. The machine learning algorithm can be used to apply certain calculations or criteria—depending on the configuration—to the input data for the data filter in order to obtain the output data. However, a machine learning algorithm can also be used only for subtasks, such as for the pre-selection of input data to be ultimately checked and / or for the pre-processing of input data for the application of temporal logic for signals. Thus, the integration of complex calculation steps is also possible, regardless of the specific application.

[0032] A neural network (NN), for example, can be integrated into the signal preprocessing chain by feeding the neural network's output signal into the data filter as input data. For example, a neural network could map the function of "sensor blindness," and the data filter could then output data if sensor blindness of the front camera is continuously detected over a specified period of time (e.g., 300 ms). One use case for this could be, for example, to filter out windshield wiper movements as false positives.

[0033] In principle, this allows any type of complex calculation to be outsourced from the data filter, and only the temporal dependence of the complex calculations can be modeled at the output signal level. This separates the complex detection logic from the temporal behavior and interdependencies.

[0034] Advantageously, the provision of the vehicle data, comprising 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 takes place if one or more criteria regarding runtime behavior are met. In particular, the provision of the vehicle data is also aborted if one or at least one of the several criteria is no longer met. As already mentioned, the application of the data filter, including the provision and, if applicable, transmission of the output data, takes place at runtime. This means that computing resources on the executing computing unit are used. Therefore, care should be taken to ensure that the tasks for which the computing unit (e.g. control unit, central computer) is actually or primarily intended can also be executed. If this is no longer possible due to the application of the data filter orIf the data filter is no longer available within a specified time frame, the application of the data filter can and should be interrupted or, if necessary, not started at all. Possible criteria include, for example, a certain amount of freely available computing power and / or memory space or the absence of safety-critical control interventions.

[0035] The application of such a data filter in the area of ​​safety-critical systems can also be made possible by pre-reserving the required protected memory area on the executing processing unit, whereby it should be ensured that changes in the scope and configuration of the data filter remain exclusively within the limits of the pre-reserved protected memory area and runtime budget.

[0036] A computing unit according to the invention, 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.

[0037] The implementation of a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, as this entails particularly low costs, in particular if an executing control unit is also used for other tasks and is therefore already present. Finally, 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 memories, such as hard disks, flash memories, EEPROMs, DVDs, and others. Downloading a program via computer networks (Internet, intranet, etc.) is also possible. Such a download can be wired or cable-based or wireless (e.g., via a WLAN network, a 3G, 4G, 5G, or 6G connection, etc.).

[0038] Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawings.

[0039] The invention is illustrated schematically in the drawing using exemplary embodiments and is described below with reference to the drawing.

[0040] Short description of the drawings

[0041] Figure 1 schematically shows a vehicle to illustrate a preferred embodiment of the invention. Figure 2 schematically shows a sequence of a method according to the invention in a preferred embodiment.

[0042] Embodiment(s) of the invention

[0043] Figure 1 schematically illustrates a vehicle 100 to illustrate a preferred embodiment of the invention. The vehicle 100 includes, for example, a computing unit 110 configured as a central computer 110, to which two control units 122 and 124 are connected, for example, via a communication link or bus 120.

[0044] Sensors 130, 132, 134, and 136, as well as actuators 140, 142, are connected to the control units 122, 124. The sensors can be, for example, cameras, radar, ultrasound, or lidar sensors, tachometers, or other measuring devices, as well as, for example, inertial sensors. The actuators can be, for example, brake actuators, steering actuators, or other control elements. During operation of the vehicle 100, the sensors, actuators, and control units generate signals or data, or general vehicle data, which are designated, for example, by 160. This data or signals are present on the communication link 120 and can be read or recorded by the central computer 110.

[0045] A data filter 112 with a configuration 114 is executed in or on the central computer 110. The vehicle data 160 serves as input data for the data filter 112. Using the data filter 112, specific portions of the vehicle data are selected from the input data according to the configuration 114 and transmitted as output data 170, e.g., wirelessly, to a server 190 or another computing unit external to the vehicle. There, the output data 170 can then be accessed by a developer, for example, in order to use it for analysis.

[0046] Furthermore, two additional vehicles 102, 104 are indicated as examples, on whose central computers a data filter with a corresponding configuration may also be present. This is intended to illustrate that such a data filter can be present and applied to a large number of vehicles, for example, in the field, in order to be able to collect specific vehicle data from this large number of vehicles.

[0047] Figure 2 schematically illustrates a preferred embodiment of a method according to the invention. For this purpose, a data filter 212 is shown, which may, for example, correspond to the data filter 112 in Figure 1.

[0048] During operation of the vehicle, vehicle data, i.e. various signals, are recorded and fed to the data filter 212 as input data. Four signals 260, 262, 264, 266 are shown as examples. The data filter 212 has a configuration 214 which is specified by two conditions 216, 218, for example. The condition 216 can, for example, comprise that only signals of type 260 and 262 are considered. The condition 218 can then comprise that of the considered signals, e.g. that of type 260, must assume a value of one before the signal of type 262. These conditions can be formulated in such a way that they are never met during normal operation because, for example, signal 260 never assumes the value one before, and at most after, signal 262.

[0049] Accordingly, only if an error occurs are both conditions 216 and 218 met and data 270, e.g. information that an error has occurred, is provided as output data.

[0050] In a different configuration, for example, the condition can be specified that only signals of type 264 are considered, which are then always output (if necessary directly) as output data.

[0051] In this way, desired data filters can be used very quickly and flexibly in a variety of vehicles to obtain desired vehicle data.

[0052] It is important here that configuration 214 also specifies which data should be provided or stored when a condition (trigger condition) 216, 218 is met. This can also be signals other than those used for the trigger conditions (vehicle data), i.e., 260, 262 in this case. A preferred application is to trigger on simple scalar signals, for example, but then the camera image should also be saved. Thus, as described at the beginning, not only can data be selected from the vehicle data, but other data can also be generated if necessary.

Claims

Claims 1. Method for providing data in a vehicle (100), comprising: Receiving vehicle data (160, 260, 262, 264, 266) generated in the vehicle (100) as input data for a data filter (112, 212), applying the data filter (112, 212) with a provided configuration (114, 214) to the input data, wherein data is selected and / or generated from the input data that fulfills one or more conditions (216, 218) specified by means of the provided configuration (114, 214), wherein the one or more conditions (216, 218) specified by means of the provided configuration are in an abstracted form compared to the vehicle data, having data identifiers, and Providing the selected and / or generated data, if available, as output data (170, 270).

2. Method according to claim 1, wherein the application of the data filter (112, 212), in particular a check to see whether one or more conditions (216, 218) specified by means of the provided configuration are met, is carried out using a temporal logic of signals.

3. Method according to claim 1 or 2, wherein applying the data filter (112, 212), with a provided configuration (114, 214), to the input data comprises using a mapping between the input data and the data identifiers.

4. Method according to one of the preceding claims, wherein the provided output data (170, 270) are output externally, in particular by means of wireless communication.

5. Method according to one of the preceding claims, wherein the data filter (112, 212) is activated or deactivated based on information obtained from an external source, in particular by means of wireless communication, to activate or deactivate the data filter.

6. Method according to one of the preceding claims, wherein the configuration (114, 214) is selected from several configurations based on information obtained externally, in particular by means of wireless communication.

7. Method according to one of the preceding claims, wherein the configuration (114, 214) is obtained or updated from an external source, in particular by means of wireless communication.

8. Method according to one of the preceding claims, wherein several data filters (112, 212) each with a configuration (114, 214) are used to determine and provide respective output data (170, 270).

9. Method according to one of the preceding claims, wherein the application of the data filter (112, 212) comprises the use of a machine learning algorithm.

10. Method according to one of the preceding claims, wherein the application of the data filter (112, 212) only takes place if one or more criteria regarding a runtime behavior are met, and in particular is terminated if one or at least one of the several criteria is no longer met.

11. Method according to one of the preceding claims, wherein the vehicle data (160, 260, 262, 264, 266) generated in the vehicle (100) during operation of the vehicle comprise signals and / or messages generated by sensors (130, 132, 134, 136) and / or actuators (140, 142) and / or control units (122, 124).

12. Computing unit (110), in particular a control unit or central computer of a vehicle, which is configured to perform all process steps of a method according to any of the preceding claims.

13. A computer program that causes a computing unit (110) to perform all the process steps of a method according to any one of claims 1 to 11 when executed on the computing unit (110).

14. A machine-readable storage medium with a computer program according to claim 13 stored thereon.

Images