WO2023057044A1 - Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule - Google Patents

Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule Download PDF

Info

Publication number
WO2023057044A1
WO2023057044A1 PCT/EP2021/077344 EP2021077344W WO2023057044A1 WO 2023057044 A1 WO2023057044 A1 WO 2023057044A1 EP 2021077344 W EP2021077344 W EP 2021077344W WO 2023057044 A1 WO2023057044 A1 WO 2023057044A1
Authority
WO
WIPO (PCT)
Prior art keywords
sensor data
quality
sensors
information
vehicle
Prior art date
Application number
PCT/EP2021/077344
Other languages
English (en)
Inventor
Stephan Max
Original Assignee
Volkswagen Aktiengesellschaft
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 Volkswagen Aktiengesellschaft filed Critical Volkswagen Aktiengesellschaft
Priority to PCT/EP2021/077344 priority Critical patent/WO2023057044A1/fr
Priority to EP21787377.7A priority patent/EP4377920A1/fr
Publication of WO2023057044A1 publication Critical patent/WO2023057044A1/fr

Links

Classifications

    • 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
    • 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/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data

Definitions

  • the present invention relates to an apparatus, a method and a computer program for determining information on a quality of sensor data of one or more sensors of a vehicle, and to an apparatus, method and computer program for a backend server.
  • the car itself has many configuration possibilities, therefore sensors/actors can be optionally installed into the car, or have a different quality depending on the configuration of the car.
  • the configuration is of course known by the car factory and can be stored as additional information into the car.
  • the sensors / actors can be damaged (e.g. by accident) or replaced (by the customer) during the life cycle of the car.
  • the car sensors / actors can be temporarily damaged or impeded by snow or dust, for example.
  • the car sensors can be temporarily disabled by trailers connected to eh car, or additional parts mounted to the car (e.g. a bicycle holder to the roof or the trunk of the car).
  • function containers may require a (pre-set) set of sensors and actors to perform the functional operations. If a function is sold to a customer, the function should ensure the functionality of all of its operations, and thus may require information on the status of sensors / actors of the car.
  • a diagnostic tool is integrated in a vehicle. Diagnostic requests are transmitted from a server to the diagnostic tool, and a result is transmitted back to the server. Tests can be launched on various aspects of the vehicles, such as sensors or actuators. However, the tests are not used to locally determine the sensor quality of the sensors of the vehicle.
  • a diagnostic test is performed in a vehicle, comparing a local sensor value to a sensor value received from an external sensor. If a deviation is detected between the local and the external sensor, a signal is transmitted to a service center. The service center then provides an artificial sensor value to be used instead of the faulty sensor.
  • the state of sensors i.e., the quality of the sensor data, the presence or absence of a sensor, and/or a malfunctioning of the respective sensors
  • some sensors may be prone to having sensor data with a reduced quality in heavy weather, e.g., when snow and ice impede the respective sensors.
  • Other sensors can be made useless through the addition of a vehicular accessory, such as a bike holder.
  • Other sensors might be installed only temporarily (such as a dashcam camera sensor).
  • some software functionality relies on the availability of high-quality sensor data - if such functionality is provided on substandard sensor data, the functionality of the respective software may be impeded and errors may occur.
  • the present disclosure provides a concept for continually monitoring the quality of sensor data of sensors of the vehicle.
  • a ruleset for evaluating the quality of the sensor data e.g., based on a comparison of sensor data of the same or different types of sensors, is provided from a backend server.
  • the ruleset is used to determine the quality of the sensor data.
  • Information on the quality of the sensor data is provided to the backend server, where it can be used to determine, which software functions, e.g., which computational function blocks, are suitable for execution on the vehicle.
  • the apparatus comprises at least one interface for communicating with a backend server and for accessing sensor data of the one or more sensors of the vehicle.
  • the apparatus comprises one or more processors, configured to obtain a ruleset for determining a quality of sensor data of the one or more sensors of the vehicle from the backend server.
  • the one or more processors are configured to determine a quality of the sensor data of the one or more sensors based on the ruleset.
  • the one or more processors are configured to provide information on the quality of the sensor data of the one or more sensors to the backend server.
  • determining the quality of the sensor data of the vehicle By determining the quality of the sensor data of the vehicle, a determination can be made on which computational function blocks are suitable for the vehicle.
  • a ruleset that is supplied by a backend server, the quality of the sensor data can be determined by the vehicle, the ruleset can be extended based on new insights by the vehicle manufacturer, and the quality of the sensor data may be comparable across different vehicles and vehicle types.
  • the one or more processors may be configured to repeat determining the quality of the sensor data according to a pre-defined schedule. This may help identifying quality problems with sensors in a precautionary manner.
  • the quality of sensor data may degrade in a permanent manner, e.g., as a calibration of the sensor is no longer possible, or as the sensor is slowly failing.
  • the degradation in quality may be non-permanent, e.g., due to dirt, or due to an accessory being attached to the vehicle.
  • the proposed concept may distinguish between those two cases.
  • the one or more processors may be configured to determine whether the sensor data of a sensor exhibits a temporary or permanent degradation in quality based on the repeated determination of the quality of the sensor data, and to include information on whether the quality of the sensor data exhibits a temporary or permanent degradation in quality in the information on the quality of the sensor data.
  • the one or more processors may be configured to obtain information on one or more computational function containers suitable for the vehicle, in response to the information on the quality of the sensor data of the one or more sensors.
  • the backend server may determine, based on the quality of the sensor data, which computational function containers are suitable for the vehicle.
  • the one or more computational function containers may be suitable for the vehicle in light of the quality of the sensor data and/or in light of an availability of sensors within the vehicle.
  • the ruleset may comprise at least one rule for determining the quality of sensor data of a sensor based on a comparison with sensor data of another sensor of the same type.
  • a correlation between sensor data of different types of sensors, between the sensor data of a sensor and data of an actuator, or between the sensor data of a sensor an external data may be used to determine the sensor data.
  • the ruleset may comprise at least one rule for determining the quality of sensor data of a sensor based on a comparison with sensor data of a different type of sensor, based on data of an actuator, or based on data provided by the backend server.
  • the sensor data may include a sensor bias, i.e., a deviation that persists over multiple measurements.
  • the one or more processors may be configured to obtain information for at least partially compensating for a sensor data offset or a sensor data nonlinearity from the backend server in response to the information on the quality of the sensor data of the one or more sensors. This information may be used to improve the quality of the sensor data.
  • sensors may fail or may be removed, e.g., due to an accident, or because they are stollen. In this case, they might still be registered at the backend, but the determination of the quality of the respective sensor data may fail.
  • the one or more processors may be further configured to detect a failure and/or an absence of the one or more sensors, and to include information on the failure and/or absence of the one or more sensors in the information on the quality of the sensor data. This way, the backend server may (temporarily) assume that these sensors are not available for the computational function blocks.
  • the present disclosure relate to a corresponding method for determining information on a quality of sensor data of one or more sensors of a vehicle.
  • the method comprises obtaining a ruleset for determining a quality of sensor data of one or more sensors of the vehicle from a backend server.
  • the method comprises determining a quality of sensor data of the one or more sensors based on the ruleset.
  • the method comprises providing information on the quality of the sensor data of the one or more sensors to the backend server.
  • the method may be performed by the vehicle, e.g., an apparatus of the vehicle.
  • the apparatus comprises at least one interface for communicating with one or more vehicles.
  • the apparatus comprises one or more processors, configured to provide a ruleset for determining a quality of sensor data of one or more sensors of the one or more vehicles to the one or more vehicles.
  • the one or more processors are configured to obtain information on the quality of the sensor data of the one or more sensors of the one or more vehicles from the one or more vehicles. By determining the quality of the sensor data of the vehicle in the vehicle using the ruleset, a determination can be made on which computational function blocks are suitable for the vehicle.
  • the quality of the sensor data can be determined by the vehicle, the ruleset can be extended based on new insights by the vehicle manufacturer, and the quality of the sensor data may be comparable across different vehicles and vehicle types.
  • the information on the quality of the sensor data comprises information on whether the quality of the sensor data exhibits a temporary or permanent degradation in quality and/or information on a failure and/or absence of the one or more sensors of the one or more vehicles.
  • the backend server may be informed of a (temporary) unavailability or unsuitability of the respective sensor or sensor data.
  • the one or more processors may be configured to determine, for each vehicle of the one or more vehicles separately, information on one or more computational function containers suitable for the vehicle based on the information on the quality of the sensor data of the vehicle, and to provide the information on one or more computational function containers suitable for the vehicle to the vehicle.
  • the backend server may determine, based on the quality of the sensor data, which computational function containers are suitable for the vehicle.
  • the one or more computational function containers may be suitable for the vehicle in light of the quality of the sensor data and/or in light of an availability of sensors within the vehicle.
  • a fleet wide analysis of the quality of the sensor data may be performed.
  • the one or more processors may be configured to obtain the information on the quality of the sensor data from a plurality of vehicles, and to perform a statistical analysis of the quality of the sensor data across the plurality of vehicles.
  • the sensor data may include a sensor bias, i.e., a deviation that persists over multiple measurements.
  • the one or more processors may be configured to determine information for at least partially compensating for a sensor data offset or a sensor data non-linearity based on the information on the quality of the sensor data of the one or more sensors, and to provide the information for at least partially compensating for a sensor data offset or a sensor data non-linearity to the one or more vehicles. This information may be used to compensate for the sensor bias or the non-linearity.
  • the method comprises providing a ruleset for determining a quality of sensor data of one or more sensors of one or more vehicles to the one or more vehicles.
  • the method comprises obtaining information on the quality of the sensor data of the one or more sensors of the one or more vehicles from the one or more vehicles.
  • Various examples of the present disclosure relate to a computer program having a program code for performing the method for determining information on a quality of sensor data of one or more sensors of a vehicle or the method for the backend server, when the computer program is executed on a computer, a processor, or a programmable hardware component.
  • Fig. 1a shows a block diagram of an example of an apparatus for determining information on a quality of sensor data of one or more sensors of a vehicle
  • Fig. 1b shows a schematic diagram of an example of a vehicle comprising an apparatus for determining information on a quality of sensor data of one or more sensors of a vehicle;
  • Fig. 1c shows a flow chart of an example of a method for determining information on a quality of sensor data of one or more sensors of a vehicle
  • Fig. 2a shows a block diagram of an example of an apparatus for a backend server and of the backend server comprising said apparatus
  • Fig. 2b shows a flow chart of an example of a method for a backend server
  • Fig. 3 shows a schematic diagram of a system comprising vehicular components and backend components.
  • FIG. 1a shows a block diagram of an example of an apparatus 10 for determining information on a quality of sensor data of one or more sensors 105 of a vehicle 100 (shown in Fig. 1 b).
  • the apparatus 10 comprises at least one interface 12 for communicating with a backend server 200 (shown in Fig. 1b) and for accessing sensor data of the one or more sensors 105 of the vehicle.
  • the apparatus 10 comprises one or more processors 14, which are coupled with the at least one interface 12.
  • the apparatus 10 further comprises one or more storage devices 16, which are also coupled with the one or more processors 14.
  • the functionality of the apparatus 10 is provided by the one or more processors 14, in conjunction with the at least one interface 12 (for exchanging information) and/or the optional one or more storage devices 16 (for storing and retrieving information).
  • the one or more processors 14 are configured to obtain a ruleset for determining a quality of sensor data of the one or more sensors of the vehicle from the backend server (e.g., via the at least one interface 12).
  • the one or more processors 14 are configured to determine a quality of the sensor data of the one or more sensors based on the ruleset. Accordingly, the one or more processors may be configured to obtain the sensor data of the one or more sensors, e.g., from the one or more sensor or from the one or more storage devices.
  • the one or more processors are configured to provide information on the quality of the sensor data of the one or more sensors to the backend server (e.g., via the at least one interface 12).
  • Fig. 1b shows a schematic diagram of an example of a vehicle 100 comprising the apparatus for determining information on a quality of sensor data of one or more sensors of a vehicle.
  • the apparatus 10 may be part of the vehicle 100.
  • Fig. 1c shows a flow chart of an example of a corresponding method for determining information on a quality of sensor data of the one or more sensors of a vehicle.
  • the method comprises obtaining 110 the ruleset for determining the quality of the sensor data of the one or more sensors of the vehicle from the backend server.
  • the method comprises determining 120 the quality of the sensor data of the one or more sensors based on the ruleset.
  • the method comprises providing 130 the information on the quality of the sensor data of the one or more sensors to the backend server.
  • the method may be performed by the vehicle, e.g., by the apparatus 10 of the vehicle 100.
  • Various examples of the present disclosure relate to the apparatus, method and computer program for determining the information on the quality of the sensor data of the one or more sensors of the vehicle.
  • a monitoring system is provided, which performs a long-term monitoring of the quality of the sensor data.
  • the monitoring is based on the ruleset provided by the backend server.
  • the ruleset may provide one or more (e.g., a plurality of) rules for evaluating the quality of the sensor data.
  • the sensor data may be evaluated according to the plurality of rules, in order to quantify the quality of the sensor data.
  • the quality of the sensor data may be a quantifiable measure.
  • the quality of the sensor data may be expressed on a range (e.g., a range from 0 or 1 to 100, a range from 0 to 1 , a range from 1 to 6), or the quality may be expressed with respect to an error measure (e.g., a sensor bias).
  • the ruleset may comprise the rules for determining this quantifiable measures.
  • the sensor data of a sensor is analyzed in isolation, e.g., without comparing it to sensor data of other sensors or other data.
  • a dynamic range of the sensor data may be analyzed (e.g., to determine whether the values provided by the sensor extend over a whole range of expected values included in the ruleset).
  • a bias may be determined (e.g., by comparing a median or average of a numeric value representing the sensor data with an expected median or average value included in the ruleset).
  • the sensor data may be repeatedly analyzed over time to determine, whether the dynamic range and/or the average/median values change over time.
  • the quality of the sensor data may be based on the dynamic range and/or based on a deviation from the expected average or median value.
  • the ruleset may comprise the range of expected values or the expected median or average value of the respective sensor data.
  • the sensor data of different sensors of the same type of sensor may be compared to determine the quality of the sensor data.
  • the vehicle e.g., a motor of the vehicle
  • the vehicle may comprise multiple temperature sensors, providing sensor data of temperatures that differ only up to a maximal value. If the temperatures differ by more than the maximal value, or if the temperature changes in the sensor data of one sensor, but not in the sensor data of the other sensor, the quality of the sensor data of at least one of the sensors may have degenerated. In this case, the quality of the sensor data may be based on a difference between the two temperatures, e.g., a difference that extends beyond the maximal value.
  • the ruleset may comprise information on the maximal value for comparing the sensor data of the two sensors of the same type.
  • Another example relates to ultrasound sensors being used as distance sensors for parking. In most cases, if the vehicle is driving straight, two adjacent sensors that are directed in the same direction should provide sensor data with similar distance values. If this is not the case, e.g., if the distance included in the sensor data of one sensor is always off by a certain amount from the distance included in the sensor data of the other sensor, the quality of the sensor data of at least one of the sensors may have degenerated. In this case, the quality of the sensor data may be based on the offset between the distances.
  • the ruleset may include information on the sensors that are expected to provide similar sensor data. In effect, the ruleset may comprise at least one rule for determining the quality of sensor data of a sensor based on a comparison with sensor data of another sensor of the same type.
  • the sensor data of a sensor is compared with other data, such as sensor data of a different type of sensor, data of an actuator, or data provided by the backend server.
  • the sensor data of a temperature sensor for determining an ambient temperature may be compared with temperature data for the region the vehicle is traveling in.
  • the quality of sensor data may be based on a difference between the sensor data of the temperature sensor and the temperature data, and the ruleset may specify the comparison between the sensor data and the temperature data.
  • the sensor data of a camera sensor may be compared with sensor data of a lidar sensor or a radar sensor.
  • the quality of the sensor data may be based on information on an angular misalignment between the sensor data of the camera sensor and the sensor data of the lidar/radar sensor, and the ruleset may specify the sensor data to be compared, in the criteria to be used for performing the comparison.
  • a correlation between a rate of rotation of the engine of the vehicle (which may be derived from sensor data or actuator data) and sensor data of a temperature sensor of the engine may be used to determine the quality of the sensor data of the temperature sensor.
  • the ruleset may comprise at least one rule for determining the quality of sensor data of a sensor based on a comparison with sensor data of a different type of sensor, based on data of an actuator, or based on data provided by the backend server.
  • the proposed concept may be used for a long-time, periodic evaluation of the quality of the sensor data.
  • the one or more processors may be configured to repeat determining the quality of the sensor data according to a pre-defined schedule.
  • the one or more processors may be configured to update the quality of the sensor data, and thus also the information on the quality of the sensor data, according to the pre-defined schedule.
  • the update may be triggered by the backend server, or by the vehicle itself, e.g., if a computational function block fails to use sensor data of the vehicle.
  • the one or more processors may be configured to determine whether the sensor data of a sensor exhibits a temporary or permanent degradation in quality based on the repeated determination of the quality of the sensor data. For example, if the sensor quality is degraded, or monotonically degrades, over a pre-defined number of samples of sensor data, or over a pre-defined amount of time (e.g., at least two weeks or at least one month), the sensor may be deemed to exhibit a permanent degradation of quality. If the quality of the sensor data of the sensor fluctuates over multiple samples of sensor data, the sensor may be deemed to exhibit a temporary degradation of quality.
  • the one or more processors may be configured to include information on whether the quality of the sensor data exhibits a temporary or permanent degradation in quality in the information on the quality of the sensor data.
  • sensors may fail entirely, or may even be removed, e.g., in case of an accident.
  • the backend server may be informed of the failure and/or removal.
  • a failure may be determined based on an error code received from the sensor, while an absence may be determined based on a lack of response of the respective sensor.
  • the one or more processors may be further configured to detect a failure and/or an absence of the one or more sensors, and to include information on the failure and/or absence of the one or more sensors in the information on the quality of the sensor data, or to provide the information on the failure and/or absence of the one or more sensors separately from the information on the quality of the sensor data to the backend server.
  • the one or more processors may be further configured to detect a failure and/or absence of one or more actors of the vehicle, and to include information on the failure and/or absence of the one or more actors (i.e., actuators) in the information on the quality of the sensor data, or to provide the information on the failure and/or absence of the one or more actors separately from the information on the quality of the sensor data to the backend server.
  • the one or more processors may be further configured to detect a failure and/or absence of one or more actors of the vehicle, and to include information on the failure and/or absence of the one or more actors (i.e., actuators) in the information on the quality of the sensor data, or to provide the information on the failure and/or absence of the one or more actors separately from the information on the quality of the sensor data to the backend server.
  • the information on the quality of the sensor data may comprise, for each sensor of the one or more sensors, or for a subset of the one or more sensors (e.g., for a subset that deviates from the norm), a report about the quality of the sensor data.
  • the information on the quality of the sensor data may comprise, for each sensor or for a subset of sensors, one or more numerical values representing the quality of the sensor data.
  • the information on the quality of the sensor data may comprise a binary identifier indicating whether the sensor data of the respective sensor has an image quality that is sufficiently high (e.g., that suffices a quality criterion).
  • the backend can perform various analysis.
  • a major motivation behind the determination of the quality of the sensor data lies in the question, whether the vehicle is suitable for executing various software functionality, with the software functionality being provided as so-called computational function containers.
  • This software may be provided as so-called software containers, which are denoted computational function containers in the present disclosure.
  • One or more services can be encapsulated with all their dependencies in such a computational function container/software container.
  • Software containers are particularly known for use on servers and developer devices. For example, such containers may be provided by various container engines (Docker, Podman, Crio, ). In the present disclosure, such software containers are adapted for the use in vehicles.
  • each computational function container represents a vehicle functionality that is implemented by software.
  • each computational function container is configured to provide a vehicle functionality of the vehicle.
  • each computational function container represents a software-implemented vehicle functionality.
  • each computational function container is encapsulated, i.e., it includes all program code and dependencies, to be executable within a runtime environment of a computation device.
  • the computational function container may be executed in a runtime provided by the apparatus 10.
  • the computational function container may be executed in a runtime provided by an another computation device of the vehicle.
  • Abstract interfaces may be provided, by the respective computation device, to access the one or more sensors, actuators, communication channels and host resources from within the runtime environment.
  • the computational function containers can be implemented, for example, as software containers that are used in runtime environments that provide standardized and abstracted interfaces for the containers. Accordingly, each computational function container may be designed to be executed as a container within a runtime environment. In turn, the apparatus 10 or the computation device may be configured to provide a runtime environment for the execution of containers. In the present disclosure, it is assumed, that at least some computational function containers require access to (high-quality) sensor data of the one or more sensors.
  • the one or more processors may be configured to obtain information on one or more computational function containers suitable for the vehicle, in response to the information on the quality of the sensor data of the one or more sensors. This information may be used in the vehicle, to activate and/or deactivate, or to make available or unavailable, computational function containers.
  • the one or more computational function containers indicated by the information on the one or more computational function containers may be suitable for the vehicle in light of the quality of the sensor data and/or in light of an availability of sensors and/or actors within the vehicle.
  • the apparatus may be configured to make the one or more computational function containers available for execution in the vehicle, and/or or to make computational function containers that are not part of the one or more computational function containers unavailable for execution in the vehicle.
  • a computational function containers being used in the vehicle may be replaced with another computational functional container with similar functionality and access to either more or less sensor data.
  • the one or more computational function containers may be indicated to be compatible with the vehicle, with other computational function containers being indicated to be incompatible.
  • the backend may also be used to improve the quality of the sensor data available in the sensor data.
  • the sensor data may exhibit some bias, i.e., a numerical value representing the sensor data may be off by a certain offset amount from the “actual” numerical value representing unbiased sensor data.
  • the backend may use various techniques, such as curve fitting of a difference between the measured value and the expected value, to determine a correction value, to counteract the sensor bias.
  • some examples may be prone to non-linearities in some cases, such that the backend may provide a non-vehicle specific correction value or function to counteract the non- linearity in this case.
  • the one or more processors may be configured to obtain information for at least partially compensating for a sensor data offset (bias) or a sensor data non-linearity from the backend server in response to the information on the quality of the sensor data of the one or more sensors.
  • the information for at least partially compensating for a sensor data offset may comprise a value, a function or multiple values in a lookup table that is to be added to/subtracted from or multiplied with the sensor data.
  • the information for at least partially compensating for a may comprise a function or a look-up table for compensating for the non-linearity.
  • the mechanism introduced in the present disclosure can be used to collect data on a reliability of electrical and electromechanical components, and also to collect mobility and other data, at a high sensor data quality.
  • the quality of sensor data can be verified using the proposed concept.
  • Such a verification of the quality of sensor data may be compliant with quality standards as defined by mobility data marketplaces, such as the Mobilitats TSplatz (MDM), or other exchanges of mobility data.
  • MDM Mobilitats TSplatz
  • the proposed concept may suitable for ascertaining a high quality of sensor and mobility data being exchanged via the MDM or other, similar, data exchanges.
  • the proposed concept may be used to define the “Qualitatsbe mixing” field for data publications on the MDM.
  • the at least one interface 12 may correspond to one or more inputs and/or outputs for receiving and/or transmitting information, which may be in digital (bit) values according to a specified code, within a module, between modules or between modules of different entities.
  • the at least one interface 12 may comprise interface circuitry configured to receive and/or transmit information.
  • the one or more processors 14 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software.
  • the described function of the one or more processors 14 may as well be implemented in software, which is then executed on one or more programmable hardware components.
  • Such hardware components may comprise a general purpose processor, a Digital Signal Processor (DSP), a micro-controller, etc.
  • DSP Digital Signal Processor
  • the one or more storage devices 16 may comprise at least one element of the group of a computer readable storage medium, such as an magnetic or optical storage medium, e.g. a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.
  • a computer readable storage medium such as an magnetic or optical storage medium, e.g. a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.
  • the apparatus, method, computer program and vehicle may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.
  • Fig. 2a shows a block diagram of an example of an apparatus 20 for a backend server 200.
  • Fig. 2a further shows the backend server 200 comprising said apparatus.
  • the apparatus 20 comprises at least one interface 22 for communicating with one or more vehicles.
  • the apparatus 20 further comprises one or more processors 24 that are coupled with the at least one interface 22.
  • the apparatus 20 further comprises one or more storage devices 26, which are also coupled with the one or more processors 24.
  • the functionality of the apparatus 20 is provided by the one or more processors 24, in conjunction with the at least one interface 22 (for exchanging information) and/or the optional one or more storage devices 26 (for storing and retrieving information).
  • the one or more processors 24 are configured to provide a ruleset for determining a quality of sensor data of one or more sensors of the one or more vehicles to the one or more vehicles.
  • the one or more processors 24 are configured to obtain information on the quality of the sensor data of the one or more sensors of the one or more vehicles from the one or more vehicles.
  • Fig. 2b shows a flow chart of an example of a corresponding method for the backend server.
  • the method comprises providing 210 the ruleset for determining the quality of the sensor data of the one or more sensors of the one or more vehicles to the one or more vehicles.
  • the method comprises obtaining 220 information on the quality of the sensor data of the one or more sensors of the one or more vehicles from the one or more vehicles.
  • the method may be performed by the backend 200.
  • the backend server 200 which was already discussed in connection with Figs. 1 a to 1c, is the counterpart of the apparatus 10 and vehicle 100. It provides (and determines) the ruleset, receives the information on the quality of the sensor data, and analyzes the information on the sensor data. Moreover, the backend potentially manages the ruleset, receives information on the quality of the sensor data, and performs the analysis for multiple different vehicles.
  • the ruleset is the basis of the analysis.
  • the contents of the ruleset have been discussed above.
  • the ruleset may be generated for each of the one or more vehicles, e.g., based on the one or more sensors of the respective vehicle.
  • the one or more processors may be configured to generate a ruleset for each of the one or more vehicles, based on the one or more vehicles known to be available in the respective vehicles.
  • a database of sensors known to be available at the one or more vehicles may be stored in the one or more storage devices, and used to generate the respective ruleset or rulesets for the one or more vehicles.
  • the information on the quality of the sensor data may comprise information on a failure and/or absence of the one or more sensors of the one or more vehicles, or the one or more processors may be configured to receive the information on the failure and/or absence of the one or more sensors of the one or more vehicles separately from the vehicle.
  • the one or more processors may be configured to update the database of known sensors based on the information and/or absence of the one or more sensors.
  • the one or more processors may be configured to receive information on a failure and/or absence of one or more actors (i.e., actuators) of the one or more vehicles (e.g., in the information on the quality of the sensor data) from the vehicle.
  • the database may comprise, in addition to the information on the sensors known to be available at the one or more vehicles, information on actors known to be available at the one or more vehicles.
  • the one or more processors may be configured to update the information on the actors known to be available at the one or more vehicles based on the information on a failure and/or absence of one or more actors.
  • the information on the quality of the sensor data may now be used for various purposes.
  • the one or more processors may be configured to determine, for each vehicle of the one or more vehicles separately, information on one or more computational function containers suitable for the vehicle based on the information on the quality of the sensor data of the vehicle, and to provide the information on one or more computational function containers suitable for the vehicle to the vehicle.
  • each of the computational function containers may have one or more requirements with respect to the availability and/or quality of sensor data.
  • the one or more processors may be configured to compare the one or more requirements with respect to the availability and/or quality of sensor data with the information on the quality of the sensor data of the respective vehicle, and to select the one or more computational function blocks for the respective vehicle based on the comparison.
  • the one or more processors may be configured to pre-select computational function blocks for the comparison based on the information on the sensors known to be available at the vehicle and/or based on the information on the actors known to be available at the vehicle. If the vehicles has the sensors and/or actors required by a computational function package, and if the quality of the sensor data matches the requirements with respect to the quality of the sensor data, the respective computational function block may be included in the one or more computational function blocks being selected for the vehicle.
  • the backend server may use the information on the quality of the sensor data to perform a fleet-level analysis of the quality of the sensors of the fleet.
  • the one or more processors may be configured to obtain the information on the quality of the sensor data from a plurality of vehicles, and to perform a statistical analysis of the quality of the sensor data across the plurality of vehicles.
  • the one or more processors may be configured to identify patterns in the quality of the sensor data across the plurality of vehicles, e.g., to determine whether a degradation of quality in sensor data is an isolated incident or a systemic issue with a type of sensor.
  • the one or more processors may be configured to use the statistical analysis of the quality of the sensor data to determine the range of expected values of sensor data of a sensor and/or to determine the expected average or median value of sensor data of a sensor, which may be included in the ruleset provided to a vehicle comprising the respective sensor(s).
  • the information on the quality of the sensor data may comprise information on whether the quality of the sensor data exhibits a temporary or permanent degradation in quality. This information may be relevant both for the selection of the one or more computational function blocks (where a temporary degradation in quality may be ignored for the purpose of selecting the one or more computational function blocks) and also for the statistical analysis (where a temporary degradation in quality may be disregarded, or where the temporary degradation in quality may be analyzed in a separate statistical analysis). In the latter case, the statistical analysis of the temporary degradation may be used to improve a placement of the respective sensor and/or a weather protection of the respective sensor. As outlined with respect to Figs.
  • the one or more processors may be configured to determine information for at least partially compensating for a sensor data offset or a sensor data non-linearity based on the information on the quality of the sensor data of the one or more sensors.
  • the sensor data may exhibit some bias, i.e., a numerical value representing the sensor data may be off by a certain offset amount from the “actual” numerical value representing unbiased sensor data, or exhibit some non-linearity.
  • the former may be detected based on a comparison between the sensor data of the vehicle and sensor data of the plurality of vehicles, e.g., by determining an average or median value of the respective sensor data, and comparing the two.
  • the sensor may exhibit some bias.
  • the one or more processors may be configured to calculate the difference between the average or median value of the sensor data of the vehicle and average or median value across the sensor data of the plurality of vehicles, and to provide information on the difference as correction value to the vehicle. If the bias is not constant across the dynamic range of the sensor, histograms of the sensor data of the vehicle and of the combined sensor data of the plurality of vehicles may be plotted and compared, and curve fitting may be used on the difference between the histograms to determine a function or lookup table to correct for the bias across the dynamic range.
  • a function or a lookup table for compensating for the non-linearity may be determined based on a difference between the histogram and an ideal histogram of the sensor data.
  • the one or more processors may be configured to provide the information for at least partially compensating for a sensor data offset or a sensor data non-linearity to the one or more vehicles.
  • the at least one interface 22 may correspond to one or more inputs and/or outputs for receiving and/or transmitting information, which may be in digital (bit) values according to a specified code, within a module, between modules or between modules of different entities.
  • the at least one interface 22 may comprise interface circuitry configured to receive and/or transmit information.
  • the one or more processors 24 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software.
  • the described function of the one or more processors 24 may as well be implemented in software, which is then executed on one or more programmable hardware components.
  • Such hardware components may comprise a general purpose processor, a Digital Signal Processor (DSP), a micro-controller, etc.
  • DSP Digital Signal Processor
  • the one or more storage devices 26 may comprise at least one element of the group of a computer readable storage medium, such as an magnetic or optical storage medium, e.g. a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.
  • a computer readable storage medium such as an magnetic or optical storage medium, e.g. a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.
  • the apparatus, method, computer program and backend server may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.
  • Fig. 3 shows a schematic diagram of a system comprising vehicular components and backend components.
  • the quality controller 10 may be configured to read out a setup storage, in which the sensor configuration of the car is written to.
  • the sensor configuration may be stored in the one or more storage devices 16, or the setup storage may be separate, as shown in Fig. 3, where the setup store 325 of the car sensor/actor setups 320 is separate from the quality controller 10.
  • the quality controller 10 may be configured to connect to the car signals 310.
  • the quality controller 10 may be configured to receive a control ruleset 330 from the backend 200, which is used to measure the quality of the sensors.
  • the quality controller 10 may be configured to regularly perform a quality measurement.
  • the quality controller 10 may be configured to regularly report the results to the backend.
  • a rules setup (Backend sensor/actor control rules set 330) for all types of car sensors and actors may be stored.
  • This rules set may help the in-car quality component 10 to identify (determine) the quality of the car signals.
  • the ruleset may be based on the experience of known issues and can be extended at any time if new issues are discovered - by an update of the backend rules and (also) the car rules.
  • the second new software element on the backend side holds I collects the status of the car (Car sensor/actor status 340). This software element may be regularly updated by the car.
  • a third element 345 may match the status of the car with the requirements of the functions and can therefore identify functions that can be performed on the car, and which therefore can be offered to the customer.
  • the output of the quality control software can also be used to analyze the overall fleet quality of car sensors (in a fleet quality monitor 350) by identifying one or more of the group of permanent quality drops, temporary quality drops, general measurement quality and availability. Such information may be valuable for future development.
  • Various examples of the present disclosure may therefore provide permanent monitoring of sensor / actor availability and quality, a rule-set provided by backend, and a reporting of available sensors / actors to the backend.
  • the backend may determine which functions match available sensors / actors and/or perform fleet quality monitoring of sensors / actors.
  • the proposed concept may also be applicable in other areas, such as industrial applications with various sensors.
  • Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component.
  • steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components.
  • Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and/or contain machine-executable, processor-executable or computer-executable programs and instructions.
  • Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example.
  • Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.
  • FPLAs field programmable logic arrays
  • F field) programmable gate arrays
  • GPU graphics processor units
  • ASICs application-specific integrated circuits
  • ICs integrated circuits
  • SoCs system-on-a-chip
  • aspects described in relation to a device or system should also be understood as a description of the corresponding method.
  • a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method.
  • aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Des exemples de la présente divulgation concernent un appareil, un procédé et un programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule, et un appareil, un procédé et un programme informatique pour un serveur principal. L'appareil (10) pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule comprend au moins une interface (12) pour communiquer avec un serveur principal et pour accéder à des données de capteur du ou des capteurs du véhicule. L'appareil comprend un ou plusieurs processeurs (14), configuré pour obtenir un ensemble de règles pour déterminer une qualité de données de capteur du ou des capteurs du véhicule à partir du serveur principal, déterminer une qualité des données de capteur du ou des capteurs sur la base de l'ensemble de règles, et fournir des informations sur la qualité des données de capteur du ou des capteurs au serveur principal.
PCT/EP2021/077344 2021-10-05 2021-10-05 Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule WO2023057044A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/EP2021/077344 WO2023057044A1 (fr) 2021-10-05 2021-10-05 Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule
EP21787377.7A EP4377920A1 (fr) 2021-10-05 2021-10-05 Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2021/077344 WO2023057044A1 (fr) 2021-10-05 2021-10-05 Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule

Publications (1)

Publication Number Publication Date
WO2023057044A1 true WO2023057044A1 (fr) 2023-04-13

Family

ID=78085675

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/077344 WO2023057044A1 (fr) 2021-10-05 2021-10-05 Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule

Country Status (2)

Country Link
EP (1) EP4377920A1 (fr)
WO (1) WO2023057044A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160282874A1 (en) * 2013-11-08 2016-09-29 Hitachi, Ltd. Autonomous Driving Vehicle and Autonomous Driving System
WO2017003350A1 (fr) 2015-07-02 2017-01-05 Scania Cv Ab Module de surveillance de paramètre
WO2017189361A1 (fr) * 2016-04-29 2017-11-02 Pcms Holdings, Inc. Système et procédé d'étalonnage de capteurs de véhicule assisté par communication inter-véhicules
JP2018135844A (ja) 2017-02-23 2018-08-30 トヨタ自動車株式会社 エンジンの監視システム
FR3064390A1 (fr) 2017-03-24 2018-09-28 Peugeot Citroen Automobiles Sa Vehicule automobile equipe d’un ordinateur de bord et d’un outil de diagnostic

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160282874A1 (en) * 2013-11-08 2016-09-29 Hitachi, Ltd. Autonomous Driving Vehicle and Autonomous Driving System
WO2017003350A1 (fr) 2015-07-02 2017-01-05 Scania Cv Ab Module de surveillance de paramètre
WO2017189361A1 (fr) * 2016-04-29 2017-11-02 Pcms Holdings, Inc. Système et procédé d'étalonnage de capteurs de véhicule assisté par communication inter-véhicules
JP2018135844A (ja) 2017-02-23 2018-08-30 トヨタ自動車株式会社 エンジンの監視システム
FR3064390A1 (fr) 2017-03-24 2018-09-28 Peugeot Citroen Automobiles Sa Vehicule automobile equipe d’un ordinateur de bord et d’un outil de diagnostic

Also Published As

Publication number Publication date
EP4377920A1 (fr) 2024-06-05

Similar Documents

Publication Publication Date Title
US10665039B2 (en) Distributed monitoring and control of a vehicle
US7369925B2 (en) Vehicle failure diagnosis apparatus and in-vehicle terminal for vehicle failure diagnosis
EP2376989B1 (fr) Identification de defaillances dans un moteur d'aeronef
RU2479042C2 (ru) Моделирование дистанционной диагностики
CN102163255B (zh) 使用故障建模的复杂系统的健康预测
EP3176663B1 (fr) Procédé de diagnostic de défaillance pour véhicule
US20100082197A1 (en) Intermittent fault detection and reasoning
US11603110B2 (en) Addressing vehicle sensor abnormalities
US11073567B2 (en) Vehicle battery diagnosis method and apparatus
Freiberger et al. Reverse engineering technologies for remanufacturing of automotive systems communicating via CAN bus
GB2497636A (en) Vehicle fault diagnosis system
CN111284426A (zh) 车辆故障根本原因诊断
US20190186853A1 (en) Method for diagnosing lack of coolant suppled to coolant pump of vehicle
CN113232462B (zh) 胎压管理方法、装置及计算机存储介质
JP2008546083A (ja) メカトロニクスシステムをモデルベースで診断するための方法
US8285514B2 (en) Sensor fault detection systems and methods thereof
WO2023057044A1 (fr) Appareil, procédé et programme informatique pour déterminer des informations sur une qualité de données de capteur d'un ou de plusieurs capteurs d'un véhicule
US20190120159A1 (en) Sensor diagnostic procedure
CN113222185A (zh) 联网车队中的车辆动力传动系统分析
US20200372731A1 (en) Enhanced system failure diagnosis
Qiu et al. Reliability assessment of multi-sensor perception system in automated driving functions
US11416371B2 (en) Method and apparatus for evaluating and selecting signal comparison metrics
Susarev et al. Use of previous conditions matrixes for the vehicle on the basis of operational information and dynamic models of systems, Nodes and Units
US7809986B2 (en) Fault diagnosis
US11435712B2 (en) Storage of device-related data relating to field devices in a cloud

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: 21787377

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2021787377

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2021787377

Country of ref document: EP

Effective date: 20240227