EP4315069A1 - Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs - Google Patents

Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs

Info

Publication number
EP4315069A1
EP4315069A1 EP22706756.8A EP22706756A EP4315069A1 EP 4315069 A1 EP4315069 A1 EP 4315069A1 EP 22706756 A EP22706756 A EP 22706756A EP 4315069 A1 EP4315069 A1 EP 4315069A1
Authority
EP
European Patent Office
Prior art keywords
version
objects
data
vehicle
relevant
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22706756.8A
Other languages
English (en)
French (fr)
Inventor
Dora WILMES
Marina Ullmann
Matthias Birk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
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 EP4315069A1 publication Critical patent/EP4315069A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3604—Analysis of software for verifying properties of programs
    • G06F11/3608—Analysis of software for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/0098—Details of control systems ensuring comfort, safety or stability not otherwise provided for
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G06V20/58—Recognition of moving objects or obstacles, e.g. vehicles or pedestrians; Recognition of traffic objects, e.g. traffic signs, traffic lights or roads
    • 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/0808—Diagnosing performance data
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/217—Validation; Performance evaluation; Active pattern learning techniques

Definitions

  • the invention relates to a method for evaluating software for a control unit of a vehicle. Furthermore, the invention relates to a control device, a computer program and a computer-readable medium for executing the aforementioned method.
  • a vehicle such as a passenger car or truck can be equipped with a driver assistance system that enables partially or fully automated control of the vehicle.
  • the driver assistance system can recognize positions, orientations and/or object types of objects in the vicinity of the vehicle, for example by means of a suitable sensor system, and steer, brake and/or accelerate the vehicle taking these objects into account.
  • driver assistance system is generally subject to strict safety requirements. Updating the driver assistance system, for example to improve or expand the driver assistance system, can be very time-consuming, since each time individual components are updated, the entire system must be released.
  • Embodiments of the present invention make it possible to run a not yet released version of object recognition software for a control unit of a vehicle in parallel with an already released version of the object recognition software on the control unit, to evaluate the not yet released version with regard to its recognition quality by comparing recognition results of the two versions and to send a corresponding evaluation result to a central data processing device for further evaluation.
  • evaluation results i. H. real data
  • a correspondingly large number of production vehicles can thus be guaranteed a very fast and cost-effective validation of the not yet released version, for example a new version of an object recognition or sensor data fusion module.
  • a first aspect of the invention relates to a computer-implemented method for evaluating software for a control unit of a vehicle.
  • the control unit includes a memory in which a first version and a second version of the software are stored, and a processor for executing the first version and the second version.
  • the method comprises at least the following steps: receiving in the control unit sensor data which were generated by a sensor system for detecting an environment of the vehicle; entering the sensor data into the first version and the second version; Generating first object data from the sensor data by the first version, the first object data comprising positions and/or orientations of first objects in the area surrounding the vehicle detected by the first version; generating second object data from the sensor data by the second version, the second object data comprising positions and/or orientations of second objects in the area surrounding the vehicle detected by the second version; Assessing the second version with regard to a recognition quality by comparing the first object data with the second object data, wherein an evaluation result is generated; and sending the evaluation result from the control unit to a central data processing device.
  • the method can be executed automatically by the processor of the control device, for example.
  • the method can be executed when a command generated by the central data processing device for executing the method is received in the control unit.
  • the vehicle may be an automobile, such as a car, truck, bus, or motorcycle.
  • a vehicle can also be understood as an autonomous, mobile robot.
  • the sensor system can include at least one environment sensor such as a camera, a radar, lidar or ultrasonic sensor.
  • the sensors can include a location sensor for determining the geographic coordinates of the vehicle using a global navigation satellite system such as GPS, GLONASS or similar.
  • the sensor system for detecting a driving condition of the vehicle can have at least one driving dynamics sensor such as an acceleration, wheel speed, steering wheel angle,
  • positions and/or orientations of the objects relative to the vehicle can be determined in several consecutive magazines and stored in the form of an object list in an environment model. It is possible that in each current journal future positions and/or orientations of the objects are estimated from their positions and/or orientations in one or more previous journals.
  • the sensor data can be received in several consecutive journals, whereby the sensor data in each journal can be entered in both the first version and the second version.
  • the controller software can be configured to steer, accelerate and/or decelerate the vehicle based on the sensor data.
  • the vehicle can include a corresponding actuator, for example in the form of a steering actuator, a brake actuator, an engine control unit, an electric drive motor or a combination of at least two of the examples mentioned.
  • the control unit software can include one or more components of a driver assistance system.
  • the central data processing device can be a server, a PC, a laptop, a tablet or a smartphone, for example.
  • control device and the central data processing device can be connected via a wireless data communication connection such as WLAN,
  • Bluetooth and/or cellular be connected to each other.
  • a wired data communication connection between the control device and the central data processing device is also possible.
  • the method can additionally include the following steps: receiving the second version in the control unit; storing the second version in the controller's memory.
  • the second version can be generated by the central data processing device and/or sent from the central data processing device to the control device.
  • the second version can be received in the control unit and stored there, for example in the form of a file that can be executed by the processor.
  • the first version can be an older version of the software that has already been released.
  • the second version may be a newer, unreleased version of the software.
  • the second version may include an updated version of one or more software modules of the first version, such as a detection or sensor data fusion module for detecting the objects in the sensor data or an interpretation module for interpreting the objects in terms of their relevance to the vehicle.
  • a detection or sensor data fusion module for detecting the objects in the sensor data
  • an interpretation module for interpreting the objects in terms of their relevance to the vehicle.
  • the first version includes a first detection module for converting the sensor data into the first object data and/or a first interpretation module for determining objects relevant to the vehicle based on the first object data and/or the sensor data.
  • a first detection module for converting the sensor data into the first object data
  • a first interpretation module for determining objects relevant to the vehicle based on the first object data and/or the sensor data.
  • the first recognition module or the first interpretation module can be an already released software module of the software.
  • the second version may include a second detection module for converting the sensor data into the second object data and/or a second interpretation module for determining objects relevant to the vehicle based on the second object data and/or the sensor data.
  • the second recognition module or the second interpretation module can be a software module of the software that has not yet been released.
  • the first version and the second version can, for example, be executed in parallel processes by the processor of the control device.
  • the second version can be executed in an isolated area within which the second version can be executed without safety-relevant effects on hardware and software components of the vehicle located outside this area, for example on the first version or an actuator of the vehicle.
  • Software running in such an isolated area may also be referred to as shadow mode software.
  • the first version and the second version can be executed in different operating environments.
  • the second version can be executed in an operating environment that is restricted compared to the operating environment of the first version.
  • the first object data can include object classes of the first objects in addition to the positions and/or orientations of the first objects.
  • the second object data can include object classes of the second objects in addition to the positions and/or orientations of the second objects.
  • an object class can be an object type, such as “oncoming vehicle”, “vehicle in front”, “lane marking”, “pedestrian” or similar.
  • the object classes can be assigned to the first or second objects by evaluating the sensor data using one or more classifiers. More than one object class can also be assigned to one and the same object.
  • the first object data and the second object data can be compared with one another, for example, by comparing the positions and/or orientations of the first objects with the positions and/or orientations of the second objects and/or by recognition times, at which the first objects were detected, are compared with detection times at which the second objects were detected.
  • other comparison methods are also possible.
  • links can be determined from a first object and a second object.
  • the positions and/or orientations and/or the detection times of the objects linked to one another can be compared with one another.
  • the objects that are linked to one another can be object models that describe one and the same actual object in the area surrounding the vehicle.
  • the second version By evaluating the second version, it can be determined whether its recognition quality, i. H. the recognition accuracy and reliability with which objects are recognized by the second version is worse than or at least as good as the recognition quality of the first version.
  • the evaluation result can include, for example, statistical estimates for the recognition accuracy and reliability of the second version, seen in absolute terms and/or in relation to the first version. Additionally or alternatively, the evaluation result for the evaluation of the second version can include relevant data sequences from the first and/or second object data and/or the sensor data with regard to the recognition quality.
  • the central data processing device for example via a wireless data communication link, the data sequences can be evaluated at a central location regardless of where the vehicle is located.
  • Such a data sequence can include, for example, an object list with objects relevant to the assessment of the second version with regard to the recognition quality and/or the (raw) sensor data on which these objects are based.
  • the second version can be rated worse than the first version in terms of recognition quality if it is determined that an object that was recognized by the first version was not recognized by the second version.
  • the second version is rated better than the first version in terms of recognition quality if it is determined that an object that was recognized by the second version was not recognized by the first version.
  • an object can be recognized as relevant or not relevant for the vehicle depending on its distance and/or its relative speed relative to the vehicle and/or depending on its object class.
  • the approach described here and below is based on the fact that software can be executed in a so-called shadow mode in production vehicles to support the development of driver assistance systems.
  • the software or individual software modules run passively in an isolated area without affecting active components in the vehicle.
  • newly developed software versions can be uploaded and evaluated in quick iterations.
  • an evaluation framework can be used for this purpose, which triggers the recording of data sequences based on defined trigger logic and ensures wireless data transmission to a cloud.
  • newly developed software versions can be compared and evaluated very quickly with a large amount of data that corresponds to what is happening in the field.
  • such a shadow mode can now be used to determine whether an updated version of software for a control unit of a vehicle achieves certain target parameters just as well or better than an already released version of this software is active in the vehicle.
  • the results of the updated version running in shadow mode in the vehicle can be compared directly with the results of the version that has already been released.
  • the first version is executed by a first controller and the second version is executed by a second controller.
  • the second control device can run the (released) first version or another released version of the software.
  • the first control unit can be the control unit of a first vehicle, for example.
  • the second control unit can be the control unit of a second vehicle, for example.
  • the first control device and the second control device can be connected to one another for data communication, for example via a wireless data communication connection.
  • the first object data can be generated by the first control unit from first sensor data, for example, it being possible for the first sensor data to have been generated by a first sensor system for detecting an environment of the first vehicle.
  • the second object data can be generated by the second control unit from second sensor data, for example, it being possible for the second sensor data to have been generated by a second sensor system for detecting surroundings of the second vehicle.
  • the first control device prefferably receives the second object data from the second control device.
  • the evaluation result by comparing the first object data with that of the second control unit received second object data are generated by the first control device.
  • the evaluation result can be sent from the first control unit to the central data processing device and, in addition, to the second control unit.
  • a second aspect of the invention relates to a control device, comprising a processor which is configured to carry out the method according to an embodiment of the first aspect of the invention.
  • a control device comprising a processor which is configured to carry out the method according to an embodiment of the first aspect of the invention.
  • Features of the method according to an embodiment of the first aspect of the invention can also be features of the control unit and vice versa.
  • the control unit can include hardware and/or software modules.
  • control unit can include a memory and data communication interfaces for data communication with peripheral devices.
  • a third aspect of the invention relates to a computer program.
  • the computer program comprises instructions which, when the computer program is executed by the processor, cause a processor to carry out the method according to an embodiment of the first aspect of the invention.
  • a fourth aspect of the invention relates to a computer-readable medium on which the computer program according to an embodiment of the third aspect of the invention is stored.
  • the computer-readable medium can be volatile or non-volatile data storage.
  • the computer-readable medium can be a hard drive, USB storage device, RAM, ROM, EPROM, or flash memory.
  • the computer-readable medium can also be a downloadable program code
  • data communication network such as the Internet or a data cloud (cloud).
  • At least one first evaluation parameter is determined for each first object, which indicates how well the first object was recognized by the first version.
  • At least one second evaluation parameter is determined for every second object, which indicates how well the second object was recognized by the second version.
  • the second version is then scored by comparing the first scoring parameters to the second scoring parameters.
  • a first or second evaluation parameter can be, for example, a time of recognition or a statistical value, for example a confidence with regard to the recognized positions and/or orientations.
  • the second version can be evaluated by comparing the first evaluation parameters and second evaluation parameters of identical objects.
  • a first object can be evaluated with a second object that matches the first object by comparing the first evaluation parameter(s) assigned to the first object with the second evaluation parameter(s) assigned to the second object. For example, to compare the first version with the second version, a difference can be formed from the first evaluation parameter(s) and the corresponding second evaluation parameter(s), wherein the second version can be evaluated based on the difference. This enables the software to be evaluated based on individual detected objects.
  • the first evaluation parameter is a detection time at which the first object was detected by the first version.
  • the second evaluation parameter can be a detection time at which the second object was detected by the second version.
  • the second version can be rated better than the first version in terms of recognition quality if the recognition time at which an object was recognized by the second version is an earlier time than the recognition time at which the same object was recognized by the first version became, and vice versa. Such a comparison of the detection times is easy to carry out and provides a sufficiently accurate assessment result.
  • the first evaluation parameter is a probability regarding the position and/or orientation of the first object.
  • the second evaluation parameter can Probability regarding the position and/or orientation of the second object.
  • the precision of the positions and/or orientations more precisely the precision of a position parameter with regard to a probability distribution of the positions and/or orientations, can be specified with the probability.
  • the first or second evaluation parameter can be a position and/or scatter parameter of a probability distribution, for example. It is also possible for the first or second evaluation parameter to indicate a confidence interval.
  • the accuracy and reliability of the method can thus be increased.
  • first objects relevant to the vehicle are selected from the first objects by the first version.
  • Objects that match one another are determined by comparing the relevant first objects with the second objects.
  • the evaluation parameters of the objects that match one another are then compared with one another.
  • a relevant first object can be selected from the first objects, for example depending on its distance and/or its relative speed relative to the vehicle and/or depending on its object class. This can be done using the first interpretation module of the first version, which can be configured to determine the relevance of the first objects depending on the situation and/or function, for example by dividing the first objects into different relevance categories, in the simplest case into the relevance categories "relevant ' and 'not relevant'.
  • second objects relevant to the vehicle are selected by the second version from the second objects that do not match any relevant first object.
  • an individual evaluation is generated for each relevant second object, which indicates whether the recognition of the relevant second object by the second version corresponds to an improvement or deterioration in the recognition quality of the second version compared to the first version.
  • the second version will then be further based on the individual ratings. For this purpose, it can first be determined whether the second object data contain second objects that do not match any of the relevant first objects, ie that were not recognized or at least not recognized as relevant by the first version. It can also be determined whether the second objects that do not match any of the relevant first objects are relevant to the vehicle or not.
  • this can be done using the second interpretation module of the second version, which - analogous to the first interpretation module - can be configured to determine the relevance of the second objects depending on the situation and/or function, for example by dividing the second objects into different relevance categories, in the simplest case the relevance categories “relevant” and “not relevant”.
  • the individual assessments can, for example, be sent to the central data processing device as part of the assessment result.
  • the assessment result can include the object data and/or sensor data on which the respective individual assessments are based. It is possible for the object data and/or sensor data to be sent as part of the assessment result only if the individual assessments on which they are based indicate a deterioration in the recognition quality of the second version in relation to the first version.
  • the second version can be evaluated depending on whether the second version recognizes relevant objects that were not already recognized by the first version. For example, the rating of the second version can be recalculated with each individual rating.
  • changes in a driving state of the vehicle are determined which correlate in time with detection times at which the relevant second objects were detected by the second version .
  • each individual evaluation is generated by evaluating the change in the driving state that correlates in time with the respective relevant second object.
  • the sensor data and / or the driving dynamics data can be evaluated, for example, to determine a reaction of a driver of the vehicle at the time of detection of the object in question and to interpret this. If, for example, no reaction or at least no relevant reaction by the driver can be determined, this can be interpreted as a strong indication that the recognition quality was not appreciably improved with the recognition of the object in question, and vice versa.
  • the second object data is generated in a number of consecutive magazines.
  • the second objects are checked for plausibility by comparing the second object data from different magazines.
  • the second version is then also evaluated as a function of the plausibility of the second objects. For example, the positions and/or orientations of one and the same object from different magazines can be compared with one another in order to identify inconsistencies, i. H. implausible changes in the position and/or orientation of the object. This makes it possible to determine whether the second version supplies chronologically consistent and plausible object data. It is possible for object data relating to individual, implausible objects, such as their positions and/or orientations over a number of consecutive time steps, to be sent to the central data processing device as part of the assessment result.
  • the assessment result includes data sequences from the sensor data, the first object data and/or the second object data.
  • the evaluation of the second version can be based on the data sequences.
  • the data sequences can indicate an improvement or deterioration in the recognition quality of the second version compared to the first version.
  • the data sequences are only sent if the second version was rated worse than the first version in terms of recognition quality.
  • the efficiency of the data communication between the control device and the central data processing device can be improved.
  • FIG. 1 shows a vehicle with a control device according to an exemplary embodiment of the invention.
  • FIG. 2 shows various modules of software running on the control device from FIG.
  • FIG. 1 shows a vehicle 100 that is equipped with a control unit 102 , a sensor system 104 for detecting surroundings of the vehicle 100 , and an actuator system 106 .
  • the sensor system 104 can include a camera, a radar, lidar and/or ultrasonic sensor, for example.
  • the sensor system 104 can include at least one vehicle dynamics sensor, such as an acceleration or yaw rate sensor.
  • the sensor system 104 generates sensor data 108 in several consecutive magazines, which are received in the control unit 102 and evaluated there as part of an object recognition.
  • Control unit 102 includes a memory 110 on which appropriate software 111 is stored, and a processor 112 for executing software 111.
  • control unit 102 It is possible for control unit 102 to generate a control signal 114 for automatically activating actuator system 106 based on sensor data 108 , ie based on the results of the object recognition carried out therewith.
  • the Actuator system 106 can include, for example, one or more steering and/or braking actuators for steering or braking vehicle 100 .
  • First objects 116 in the area surrounding vehicle 100 are detected by a first version 111a of software 111 evaluating sensor data 108
  • second objects 118 in the area surrounding vehicle 100 are detected by evaluating sensor data 108 using a second version 111b of software 111 will.
  • the first objects 116 and the second objects 118 here for example vehicles driving ahead, can be identical or different objects.
  • the control device 102 can evaluate a recognition quality of the second version 111b compared to the first version lila. This is described in more detail below with reference to FIG.
  • the second version 111b can be an update of the first version lila, for example an improved and/or expanded version of the software 111 compared to the first version lila.
  • the second version 111b can also be referred to as shadow software.
  • the second version 111b can also be allocated to a separate control device in the same way.
  • the sensor data 108 enter both a first recognition module 202 of the first version IIIa and a second recognition module 204 of the second version III1b.
  • the first detection module 202 uses the sensor data 108 to generate first object data 206, the positions and/or orientations of the first objects 116 relative to vehicle 100 .
  • second detection module 204 From sensor data 108 , second detection module 204 generates second object data 208 , which includes positions and/or orientations of second objects 118 relative to vehicle 100 .
  • Detected objects 116, 118 can be stored together with their respective positions and/or orientations, for example in the form of object lists, in an environment model of the environment of vehicle 100 and continuously updated there based on sensor data 108.
  • the first objects 116 and the second objects 118 can be understood as object models stored in the environment model of objects actually present in the environment of the vehicle 100 .
  • the first object data 206 and/or the second object data 208 can specify one or more object types for each detected object 116 or 118, such as “vehicle”, “pedestrian” or “lane marking”.
  • the first object data 206 and the second object data 208 are entered into an evaluation module 210 of the software 111, which in this example, like the second version 111b, runs in the restricted operating environment 200 for security reasons.
  • the evaluation module 210 evaluates the recognition quality of the second version 111b in relation to the first version 111a by suitably comparing the first object data 206 with the second object data 208 .
  • the evaluation module 210 generates a corresponding evaluation result 212 and sends this, for example via a WLAN, Bluetooth and/or cellular connection, to a central data processing device 214 outside of the vehicle 100 for further evaluation.
  • the first objects 116 can be compared with the corresponding second objects 118 using one or more suitable assessment parameters, for example using the respective detection times or using one or more estimated values with regard to the accuracy and/or reliability of the respective positions and/or orientations .
  • the first object data 206 can be interpreted by a first interpretation module 216 of the first version IIIa, ie evaluated with regard to their relevance for the vehicle 100 .
  • the first interpretation module 216 can select one or more relevant first objects 116′ from the first objects 116, in FIG. 1 for example a vehicle driving ahead to the left of the vehicle 100, and correspondingly filtered first object data 206′. send to the scoring module 210.
  • the evaluation module 210 can then link the relevant first objects 116' to the corresponding second objects 118, for example based on the respective positions and/or orientations and/or the respective detection times. Subsequently, the evaluation parameters of the linked objects can be compared with one another in order to evaluate the second version 111b.
  • the objects that are linked to one another can be objects that correspond to one another in that they are object models of one and the same object that actually exists in the environment of the vehicle 100 .
  • the second object data 208 is interpreted by a second interpretation module 218 of the second version 111b, i. H. be evaluated with regard to their relevance for the vehicle 100 .
  • second interpretation module 218 can select one or more relevant second objects 118' from second objects 118, in FIG. 1 for example a vehicle driving ahead to the right of vehicle 100, and correspondingly filtered second object data 208'. send to the scoring module 210.
  • the evaluation module 210 can determine whether there are objects that clearly match one another among the relevant first objects 206′ and the relevant second objects 208′ or not. If one of the relevant second objects 208′ does not match one of the relevant first objects 206′, the rating module 210 can generate an individual rating for this second object, which indicates whether the recognition of this second object improves or worsens the recognition quality of the second version 111b is purple compared to the first version.
  • the evaluation result 212 can then be generated based on the individual evaluation.
  • the individual evaluation can be generated based on the sensor data 108 .
  • Sensor data 108 can include driving dynamics data generated by one or more driving dynamics sensors of vehicle 100 in addition to environmental data generated by one or more environmental sensors of vehicle 100 .
  • temporally correlating changes in the driving dynamics state of the vehicle 100 for example triggered by a corresponding reaction of its driver, can be determined with the detection of the relevant second objects 118′. Based on this change, it can finally be determined whether the recognition of the relevant object is equivalent to an improvement or deterioration in the recognition quality of the second version 111b.
  • the second interpretation module 218 may be configured to first determine those of the second objects 118 that do not uniquely match any of the relevant first objects 116' and then select the relevant second objects 118' therefrom.
  • the evaluation module 210 can be configured to check the second objects 118 for plausibility. For this purpose, the evaluation module 210 can evaluate the second objects 118 based on the second object data 208 of a number of consecutive time steps. In this case, the assessment result 212 can also be determined taking into account the plausibility of the second objects 118 .
  • An example of an implausible or inconsistent second object 118 is indicated in FIG. 1 with a dashed frame.
  • the assessment of the second version 111b in terms of a validation of a recognition task that is to be solved by means of the second recognition module 204 and/or the second interpretation module 218 can include the following steps, for example.
  • first objects 116' which were recognized by the first version 111a, were also recognized in the same or improved manner by the second version 111b running in shadow mode.
  • the relevance of the first objects 116 is not determined by the first recognition module 202 itself, but by the first interpretation module 216, ie determined by one or more subsequent interpreting software elements in a kind of situation analysis.
  • a link is carried out in the evaluation module 210 .
  • the recognition quality of the two versions 111a, 111b is then compared with one another on the basis of defined metrics, which can include, for example, the respective recognition times or a confidence with regard to the respective positions and/or orientations.
  • a corresponding data sequence can be sent directly to the central data processing device 214.
  • the data sequence can be generated from the corresponding sensor data 108 and/or the corresponding object data 116 or 118 .
  • an improvement in the recognition quality can be confirmed by the non-arrival of such data sequences at the central data processing device 214 .
  • the improvement or deterioration in the recognition quality can be recorded by the control unit 102 regularly sending bundled statistics to the central data processing device 214 .
  • the second interpretation module 218 determines a second relevant object 118' in a type of situation analysis that cannot be linked to any of the relevant first objects 116', then it is first determined using defined logic, for example based on the driver's reaction to this object, whether the recognition of this object represents an improvement or deterioration in the recognition quality. Depending on the logic, the process can be recorded in a statistic. Additionally or alternatively, the direct transmission of a corresponding data sequence for external evaluation in the central data processing device 214 can be triggered.
  • the evaluation module 210 detects using time curves from the sensor data 108 and/or the second object data 208 or 208' Inconsistencies, such as second objects 118 suddenly appearing or suddenly disappearing in the immediate vicinity of vehicle 100.
  • Information about these objects can be sent from control unit 102 to data processing device 214 either directly in the form of a corresponding data sequence or bundled in the form of statistics.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Data Mining & Analysis (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Biology (AREA)
  • Evolutionary Computation (AREA)
  • Traffic Control Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Bewerten einer Software (111) für ein Steuergerät (102) eines Fahrzeugs (100), wobei das Steuergerät (102) einen Speicher (110), in dem eine erste Version (111a) und eine zweite Version (111b) der Software (111) gespeichert sind, sowie einen Prozessor (112) zum Ausführen der ersten Version (111a) und der zweiten Version (111b) umfasst. Das Verfahren umfasst: Empfangen von Sensordaten (108), die durch eine Sensorik (104) zum Erfassen einer Umgebung des Fahrzeugs (100) erzeugt wurden, in dem Steuergerät (102); Eingeben der Sensordaten (108) in die erste Version (111a) und die zweite Version (111b); Erzeugen erster Objektdaten (206, 206') aus den Sensordaten (108) durch die erste Version (111a), wobei die ersten Objektdaten (206, 206') Positionen und/oder Orientierungen von durch die erste Version (111a) erkannten ersten Objekten (116, 116') in der Umgebung des Fahrzeugs (100) umfassen; Erzeugen zweiter Objektdaten (208, 208') aus den Sensordaten (108) durch die zweite Version (111b), wobei die zweiten Objektdaten (208, 208') Positionen und/oder Orientierungen von durch die zweite Version (111b) erkannten zweiten Objekten (118, 118') in der Umgebung des Fahrzeugs (100) umfassen; Bewerten der zweiten Version (111b) hinsichtlich einer Erkennungsgüte durch Vergleichen der ersten Objektdaten (206, 206') mit den zweiten Objektdaten (208, 208'), wobei ein Bewertungsergebnis (212) erzeugt wird; und Senden des Bewertungsergebnisses (212) von dem Steuergerät (102) an eine zentrale Datenverarbeitungsvorrichtung (214).

Description

Verfahren zum Bewerten einer Software für ein Steuergerät eines Fahrzeugs
Gebiet der Erfindung
Die Erfindung betrifft ein Verfahren zum Bewerten einer Software für ein Steuergerät eines Fahrzeugs. Des Weiteren betrifft die Erfindung ein Steuergerät, ein Computerprogramm und ein computerlesbares Medium zum Ausführen des vorgenannten Verfahrens.
Stand der Technik
Ein Fahrzeug wie beispielsweise ein Pkw oder Lkw kann mit einem Fahrerassistenzsystem ausgestattet sein, das eine teil- oder vollautomatisierte Steuerung des Fahrzeugs ermöglicht. Hierzu kann das Fahrerassistenzsystem beispielsweise mittels einer geeigneten Sensorik Positionen, Orientierungen und/oder Objekttypen von Objekten in der Umgebung des Fahrzeugs erkennen und das Fahrzeug unter Berücksichtigung dieser Objekte lenken, bremsen und/oder beschleunigen.
Ein solches Fahrerassistenzsystem unterliegt im Allgemeinen strengen Sicherheitsanforderungen. Aktualisierungen des Fahrerassistenzsystems, etwa zur Verbesserung oder Erweiterung des Fahrerassistenzsystems, können sehr aufwendig sein, da bei jeder Aktualisierung einzelner Komponenten eine Freigabe des Gesamtsystems erfolgen muss.
Offenbarung der Erfindung
Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz ein Verfahren zum Bewerten einer Software für ein Steuergerät eines Fahrzeugs, ein entsprechendes Steuergerät, ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Medium gemäß den unabhängigen
KU:JU Ansprüchen vorgestellt. Vorteilhafte Weiterbildungen und Verbesserungen des hier vorgestellten Ansatzes ergeben sich aus der Beschreibung und sind in den abhängigen Ansprüchen beschrieben.
Vorteile der Erfindung
Ausführungsformen der vorliegenden Erfindung ermöglichen es, eine noch nicht freigegebene Version einer Objekterkennungssoftware für ein Steuergerät eines Fahrzeugs parallel zu einer bereits freigegebenen Version der Objekterkennungssoftware auf dem Steuergerät auszuführen, die noch nicht freigegebene Version hinsichtlich ihrer Erkennungsgüte durch Vergleichen von Erkennungsergebnissen der beiden Versionen zu bewerten und ein entsprechendes Bewertungsergebnis zur weiteren Auswertung an eine zentrale Datenverarbeitungsvorrichtung zu senden.
Unter Einbeziehung von Bewertungsergebnissen, d. h. von Realdaten, einer entsprechend großen Anzahl von Serienfahrzeugen kann somit eine sehr schnelle und kostengünstige Validierung der noch nicht freigegebenen Version, beispielsweise einer neuen Version eines Objekterkennungs- oder Sensordatenfusionsmoduls, gewährleistet werden.
Ein erster Aspekt der Erfindung betrifft ein computerimplementiertes Verfahren zum Bewerten einer Software für ein Steuergerät eines Fahrzeugs. Dabei umfasst das Steuergerät einen Speicher, in dem eine erste Version und eine zweite Version der Software gespeichert sind, sowie einen Prozessor zum Ausführen der ersten Version und der zweiten Version. Das Verfahren umfasst zumindest die folgenden Schritte: Empfangen von Sensordaten, die durch eine Sensorik zum Erfassen einer Umgebung des Fahrzeugs erzeugt wurden, in dem Steuergerät; Eingeben der Sensordaten in die erste Version und die zweite Version; Erzeugen erster Objektdaten aus den Sensordaten durch die erste Version, wobei die ersten Objektdaten Positionen und/oder Orientierungen von durch die erste Version erkannten ersten Objekten in der Umgebung des Fahrzeugs umfassen; Erzeugen zweiter Objektdaten aus den Sensordaten durch die zweite Version, wobei die zweiten Objektdaten Positionen und/oder Orientierungen von durch die zweite Version erkannten zweiten Objekten in der Umgebung des Fahrzeugs umfassen; Bewerten der zweiten Version hinsichtlich einer Erkennungsgüte durch Vergleichen der ersten Objektdaten mit den zweiten Objektdaten, wobei ein Bewertungsergebnis erzeugt wird; und Senden des Bewertungsergebnisses von dem Steuergerät an eine zentrale Datenverarbeitungsvorrichtung.
Das Verfahren kann beispielsweise automatisch durch den Prozessor des Steuergeräts ausgeführt werden. Beispielsweise kann das Verfahren dann ausgeführt werden, wenn ein durch die zentrale Datenverarbeitungsvorrichtung generierter Befehl zum Ausführen des Verfahrens in dem Steuergerät empfangen wird.
Das Fahrzeug kann ein Kraftfahrzeug, etwa in Form eines Pkw, Lkw, Busses oder eines Motorrads, sein. Im weiteren Sinn kann unter einem Fahrzeug auch ein autonomer, mobiler Roboter verstanden werden.
Die Sensorik kann mindestens einen Umfeldsensor wie beispielsweise eine Kamera, einen Radar-, Lidar- oder Ultraschallsensor umfassen. Darüber hinaus kann die Sensorik einen Ortungssensor zur Bestimmung geografischer Koordinaten des Fahrzeugs mithilfe eines globalen Navigationssatellitensystems wie GPS, GLONASS o. Ä. umfassen. Zusätzlich kann die Sensorik zum Erfassen eines Fahrzustands des Fahrzeugs mindestens einen Fahrdynamiksensor wie beispielsweise einen Beschleunigungs-, Raddrehzahl-, Lenkradwinkel-,
Lenkmoment-, Bremsdruck- oder Bremspedalwegsensor umfassen.
Durch Verarbeiten der Sensordaten in dem Steuergerät können in der Umgebung des Fahrzeugs befindliche Objekte wie beispielsweise andere Verkehrsteilnehmer, Fahrbahnmarkierungen, Verkehrsschilder, Signalanlagen, Gebäude oder Bewuchs erkannt werden. Hierbei können Positionen und/oder Orientierungen der Objekte relativ zum Fahrzeug in mehreren aufeinanderfolgenden Zeitschriften bestimmt und in Form einer Objektliste in einem Umgebungsmodell abgespeichert werden. Es ist möglich, dass in jedem aktuellen Zeitschrift zukünftige Positionen und/oder Orientierungen der Objekte aus deren Positionen und/oder Orientierungen in einem oder mehreren früheren Zeitschriften geschätzt werden.
Die Sensordaten können in mehreren aufeinanderfolgenden Zeitschriften empfangen werden, wobei die Sensordaten in jedem Zeitschrift sowohl in die erste Version als auch in die zweite Version eingegeben werden können. Es ist möglich, dass die Software des Steuergeräts konfiguriert ist, um das Fahrzeug basierend auf den Sensordaten zu lenken, zu beschleunigen und/oder abzubremsen. Hierzu kann das Fahrzeug eine entsprechende Aktorik umfassen, beispielsweise in Form eines Lenkaktors, eines Bremsaktors, eines Motorsteuergeräts, eines elektrischen Antriebsmotors oder einer Kombination aus mindestens zwei der genannten Beispiele. Die Software des Steuergeräts kann eine oder mehrere Komponenten eines Fahrerassistenzsystems umfassen.
Die zentrale Datenverarbeitungsvorrichtung kann beispielsweise ein Server, ein PC, ein Laptop, ein Tablet oder ein Smartphone sein.
Das Steuergerät und die zentrale Datenverarbeitungsvorrichtung können über eine drahtlose Datenkommunikationsverbindung wie beispielsweise WLAN,
Bluetooth und/oder Mobilfunk miteinander verbunden sein. Möglich ist aber auch eine drahtgebundene Datenkommunikationsverbindung zwischen dem Steuergerät und der zentralen Datenverarbeitungsvorrichtung.
Das Verfahren kann zusätzlich die folgenden Schritte umfassen: Empfangen der zweiten Version in dem Steuergerät; Speichern der zweiten Version in dem Speicher des Steuergeräts. Dabei kann die zweite Version durch die zentrale Datenverarbeitungsvorrichtung erzeugt und/oder von der zentralen Datenverarbeitungsvorrichtung an das Steuergerät gesendet worden sein. Die zweite Version kann beispielsweise in Form einer durch den Prozessor ausführbaren Datei in dem Steuergerät empfangen und dort gespeichert werden.
Die erste Version kann eine ältere, bereits freigegebene Version der Software sein. Die zweite Version kann eine neuere, noch nicht freigegebene Version der Software sein.
Beispielsweise kann die zweite Version eine aktualisierte Version eines oder mehrerer Softwaremodule der ersten Version umfassen, wie etwa eines Erkennungs- oder Sensordatenfusionsmoduls zum Erkennen der Objekte in den Sensordaten oder eines Interpretationsmoduls zum Interpretieren der Objekte hinsichtlich ihrer Relevanz für das Fahrzeug.
Es ist möglich, dass die erste Version ein erstes Erkennungsmodul zum Umwandeln der Sensordaten in die ersten Objektdaten und/oder ein erstes Interpretationsmodul zum Bestimmen von für das Fahrzeug relevanten Objekten basierend auf den ersten Objektdaten und/oder den Sensordaten umfasst. Bei dem ersten Erkennungsmodul bzw. dem ersten Interpretationsmodul kann es sich um ein bereits freigegebenes Softwaremodul der Software handeln.
Analog dazu ist es möglich, dass die zweite Version ein zweites Erkennungsmodul zum Umwandeln der Sensordaten in die zweiten Objektdaten und/oder ein zweites Interpretationsmodul zum Bestimmen von für das Fahrzeug relevanten Objekten basierend auf den zweiten Objektdaten und/oder den Sensordaten umfasst. Bei dem zweiten Erkennungsmodul bzw. dem zweiten Interpretationsmodul kann es sich um ein noch nicht freigegebenes Softwaremodul der Software handeln.
Die erste Version und die zweite Version können beispielsweise in parallelen Prozessen durch den Prozessor des Steuergeräts ausgeführt werden.
Dabei kann die zweite Version in einem isolierten Bereich ausgeführt werden, innerhalb dessen die zweite Version ohne sicherheitsrelevante Auswirkungen auf außerhalb dieses Bereichs befindliche Hard- und Softwarekomponenten des Fahrzeugs, etwa auf die erste Version oder eine Aktorik des Fahrzeugs, ausgeführt werden kann. Software, die in einem solchen isolierten Bereich ausgeführt wird, kann auch als Shadow- Mode-Software bezeichnet werden.
Anders ausgedrückt können die erste Version und die zweite Version in unterschiedlichen Betriebsumgebungen ausgeführt werden. Dabei kann die zweite Version in einer gegenüber der Betriebsumgebung der ersten Version eingeschränkten Betriebsumgebung ausgeführt werden.
Beispielsweise können die ersten Objektdaten zusätzlich zu den Positionen und/oder Orientierungen der ersten Objekte Objektklassen der ersten Objekte umfassen. Alternativ oder zusätzlich können die zweiten Objektdaten zusätzlich zu den Positionen und/oder Orientierungen der zweiten Objekte Objektklassen der zweiten Objekte umfassen. Eine Objektklasse kann beispielsweise ein Objekttyp sein, wie „entgegenkommendes Fahrzeug“, „vorausfahrendes Fahrzeug“, „Spurmarkierung“, „Fußgänger“ o. Ä. Die Objektklassen können den ersten bzw. zweiten Objekten durch Auswerten der Sensordaten mittels eines oder mehrerer Klassifikatoren zugeordnet werden. Ein und demselben Objekt kann auch mehr als eine Objektklasse zugeordnet werden. Zum Bewerten der zweiten Version hinsichtlich der Erkennungsgüte können die ersten Objektdaten und die zweiten Objektdaten beispielsweise dadurch miteinander verglichen werden, dass die Positionen und/oder Orientierungen der ersten Objekte mit den Positionen und/oder Orientierungen der zweiten Objekte verglichen werden und/oder dass Erkennungszeitpunkte, zu denen die ersten Objekte erkannt wurden, mit Erkennungszeitpunkten, zu denen die zweiten Objekte erkannt wurden, verglichen werden. Möglich sind aber auch andere Vergleichsmethoden.
Hierzu können Verknüpfungen aus je einem ersten Objekt und einem zweiten Objekt bestimmt werden. Dabei können die Positionen und/oder Orientierungen und/oder die Erkennungszeitpunkte der miteinander verknüpften Objekte miteinander verglichen werden. Bei den miteinander verknüpften Objekten kann es sich um Objektmodelle handeln, die ein und dasselbe tatsächliche Objekt in der Umgebung des Fahrzeugs beschreiben.
Durch Bewerten der zweiten Version kann bestimmt werden, ob deren Erkennungsgüte, d. h. die Erkennungsgenauigkeit und -Zuverlässigkeit, mit der Objekte durch die zweite Version erkannt werden, schlechter als oder mindestens ebenso gut wie die Erkennungsgüte der ersten Version ist.
Das Bewertungsergebnis kann beispielsweise statistische Schätzwerte für die Erkennungsgenauigkeit und -Zuverlässigkeit der zweiten Version, absolut und/oder in Bezug auf die erste Version gesehen, umfassen. Zusätzlich oder alternativ kann das Bewertungsergebnis für die Bewertung der zweiten Version hinsichtlich der Erkennungsgüte relevante Datensequenzen aus den ersten und/oder zweiten Objektdaten und/oder den Sensordaten umfassen. Durch Senden der Datensequenzen an die zentrale Datenverarbeitungsvorrichtung, beispielsweise über eine drahtlose Datenkommunikationsverbindung, können die Datensequenzen unabhängig vom Aufenthaltsort des Fahrzeugs an zentraler Stelle ausgewertet werden.
Eine solche Datensequenz kann beispielsweise eine Objektliste mit für die Bewertung der zweiten Version hinsichtlich der Erkennungsgüte relevanten Objekten und/oder die diesen Objekten zugrunde liegenden Sensor(roh)daten umfassen. Beispielsweise kann die zweite Version hinsichtlich der Erkennungsgüte schlechter als die erste Version bewertet werden, wenn festgestellt wird, dass ein Objekt, das durch die erste Version erkannt wurde, nicht durch die zweite Version erkannt wurde.
Umgekehrt ist es möglich, dass die zweite Version hinsichtlich der Erkennungsgüte besser als die erste Version bewertet wird, wenn festgestellt wird, dass ein Objekt, das durch die zweite Version erkannt wurde, nicht durch die erste Version erkannt wurde.
Dabei ist es zweckmäßig, wenn zwischen für das Fahrzeug relevanten Objekten und nicht für das Fahrzeug relevanten Objekten unterschieden wird. Beispielsweise kann ein Objekt in Abhängigkeit von seinem Abstand und/oder seiner Relativgeschwindigkeit relativ zum Fahrzeug und/oder in Abhängigkeit von seiner Objektklasse als für das Fahrzeug relevant oder nicht relevant erkannt werden.
Der hier und im Folgenden beschriebene Ansatz beruht darauf, dass zur Unterstützung bei der Entwicklung von Fahrerassistenzsystemen Software in einem sogenannten Shadow Mode in Serienfahrzeugen ausgeführt werden kann. Dabei läuft die Software oder laufen einzelne Softwaremodule passiv in einem isolierten Bereich ohne Rückwirkung auf aktive Komponenten im Fahrzeug. In diesen Bereich können beispielsweise neu entwickelte Softwarestände in schnellen Iterationen aufgespielt und evaluiert werden. Hierzu kann beispielsweise ein Bewertungsframework genutzt werden, das basierend auf definierten Triggerlogiken die Aufzeichnung von Datensequenzen auslöst und die drahtlose Datenübertragung an eine Cloud sicherstellt. Somit können neu entwickelte Softwarestände sehr schnell mit einer großen Datenmenge, die einem realistischen Feldgeschehen entspricht, abgeglichen und bewertet werden.
In dem Verfahren gemäß einer Ausführungsform des ersten Aspekts der Erfindung kann nun ein solcher Shadow Mode genutzt werden, um festzustellen, ob eine aktualisierte Version einer Software für ein Steuergerät eines Fahrzeugs bestimmte Zielparameter ebenso gut oder besser erreicht als eine bereits freigegebene Version dieser Software, die im Fahrzeug aktiv ist. Hierzu können Ergebnisse der im Shadow Mode laufenden aktualisierten Version im Fahrzeug direkt mit Ergebnissen der bereits freigegebenen Version verglichen werden. Dies hat den Vorteil, dass Aktualisierungen von Softwaremodulen, etwa eines Fahrerassistenzsystems, im Vergleich zu gängigen Freigabemethoden mit deutlich geringerem Aufwand freigegeben und damit deutlich häufiger bereitgestellt werden können.
Es wird darauf hingewiesen, dass es zum Ausführen des vorstehend und nachstehend erläuterten Verfahrens nicht zwingend erforderlich ist, die erste und zweite Version der Software in ein und demselben Steuergerät auszuführen. Die beiden Versionen können stattdessen auch auf verschiedenen, gegebenenfalls miteinander vernetzten Steuergeräten ausgeführt werden, wie es im Folgenden beschrieben wird.
Es ist möglich, dass die erste Version durch ein erstes Steuergerät ausgeführt wird und die zweite Version durch ein zweites Steuergerät ausgeführt wird. Das zweite Steuergerät kann zusätzlich zur zweiten Version die (freigegebene) erste Version oder eine sonstige freigegebene Version der Software ausführen.
Das erste Steuergerät kann beispielsweise das Steuergerät eines ersten Fahrzeugs sein. Das zweite Steuergerät kann beispielsweise das Steuergerät eines zweiten Fahrzeugs sein. Das erste Steuergerät und das zweite Steuergerät können zur Datenkommunikation miteinander verbunden sein kann, beispielsweise über eine drahtlose Datenkommunikationsverbindung.
Die ersten Objektdaten können beispielsweise aus ersten Sensordaten durch das erste Steuergerät erzeugt werden, wobei die ersten Sensordaten durch eine erste Sensorik zum Erfassen einer Umgebung des ersten Fahrzeugs erzeugt worden sein können.
Die zweiten Objektdaten können beispielsweise aus zweiten Sensordaten durch das zweite Steuergerät erzeugt werden, wobei die zweiten Sensordaten durch eine zweite Sensorik zum Erfassen einer Umgebung des zweiten Fahrzeugs erzeugt worden sein können.
Es ist möglich, dass das erste Steuergerät die zweiten Objektdaten von dem zweiten Steuergerät empfängt.
Dementsprechend kann beispielsweise das Bewertungsergebnis durch Vergleichen der ersten Objektdaten mit den von dem zweiten Steuergerät empfangenen zweiten Objektdaten durch das erste Steuergerät erzeugt werden. Dabei kann das Bewertungsergebnis von dem ersten Steuergerät an die zentrale Datenverarbeitungsvorrichtung und, zusätzlich, an das zweite Steuergerät gesendet werden.
Ein zweiter Aspekt der Erfindung betrifft ein Steuergerät, umfassend einen Prozessor, der konfiguriert ist, um das Verfahren gemäß einer Ausführungsform des ersten Aspekts der Erfindung auszuführen. Merkmale des Verfahrens gemäß einer Ausführungsform des ersten Aspekts der Erfindung können auch Merkmale des Steuergeräts sein und umgekehrt.
Das Steuergerät kann Hardware- und/oder Softwaremodule umfassen.
Zusätzlich zum Prozessor kann das Steuergerät einen Speicher und Datenkommunikationsschnittstellen zur Datenkommunikation mit Peripheriegeräten umfassen.
Ein dritter Aspekt der Erfindung betrifft ein Computerprogramm. Das Computerprogramm umfasst Befehle, die einen Prozessor bei Ausführung des Computerprogramms durch den Prozessor veranlassen, das Verfahren gemäß einer Ausführungsform des ersten Aspekts der Erfindung auszuführen.
Ein vierter Aspekt der Erfindung betrifft ein computerlesbares Medium, auf dem das Computerprogramm gemäß einer Ausführungsform des dritten Aspekts der Erfindung gespeichert ist. Das computerlesbare Medium kann ein flüchtiger oder nicht flüchtiger Datenspeicher sein. Beispielsweise kann das computerlesbare Medium eine Festplatte, ein USB-Speichergerät, ein RAM, ROM, EPROM oder Flash-Speicher sein. Das computerlesbare Medium kann auch ein einen Download eines Programmcodes ermöglichendes
Datenkommunikationsnetzwerk wie etwa das Internet oder eine Datenwolke (Cloud) sein.
Merkmale des Verfahrens gemäß einer Ausführungsform des ersten Aspekts der Erfindung können auch Merkmale des Computerprogramms und/oder des computerlesbaren Mediums sein und umgekehrt.
Ideen zu Ausführungsformen der vorliegenden Erfindung können unter anderem als auf den nachfolgend beschriebenen Gedanken und Erkenntnissen beruhend angesehen werden. Gemäß einer Ausführungsform wird für jedes erste Objekt mindestens ein erster Bewertungsparameter bestimmt, der anzeigt, wie gut das erste Objekt durch die erste Version erkannt wurde. Dabei wird für jedes zweite Objekt mindestens ein zweiter Bewertungsparameter bestimmt, der anzeigt, wie gut das zweite Objekt durch die zweite Version erkannt wurde. Die zweite Version wird dann durch Vergleichen der ersten Bewertungsparameter mit den zweiten Bewertungsparametern bewertet. Ein erster bzw. zweiter Bewertungsparameter kann beispielsweise ein Erkennungszeitpunkt oder ein statistischer Wert, beispielsweise eine Konfidenz bezüglich der erkannten Positionen und/oder Orientierungen, sein. Die zweite Version kann durch Vergleichen der ersten Bewertungsparameter und zweiten Bewertungsparameter identischer Objekte bewertet werden. Anders ausgedrückt kann ein erstes Objekt mit einem mit dem ersten Objekt übereinstimmenden zweiten Objekt durch Vergleichen des oder der dem ersten Objekt zugeordneten ersten Bewertungsparameter(s) mit dem oder den dem zweiten Objekt zugeordneten zweiten Bewertungsparameter(n) bewertet werden. Beispielsweise kann zum Vergleichen der ersten Version mit der zweiten Version eine Differenz aus dem oder den ersten Bewertungsparameter(n) und dem oder den entsprechenden zweiten Bewertungsparameter(n) gebildet werden, wobei die zweite Version basierend auf der Differenz bewertet werden kann. Damit wird eine Bewertung der Software basierend auf einzelnen erkannten Objekten ermöglicht.
Gemäß einer Ausführungsform ist der erste Bewertungsparameter ein Erkennungszeitpunkt, zu dem das erste Objekt durch die erste Version erkannt wurde. Zusätzlich oder alternativ kann der zweite Bewertungsparameter ein Erkennungszeitpunkt sein, zu dem das zweite Objekt durch die zweite Version erkannt wurde. Beispielsweise kann die zweite Version hinsichtlich der Erkennungsgüte besser als die erste Version bewertet werden, wenn der Erkennungszeitpunkt ist, zu dem ein Objekt durch die zweite Version erkannt wurde, ein früherer Zeitpunkt ist als der Erkennungszeitpunkt, zu dem das gleiche Objekt durch die erste Version erkannt wurde, und umgekehrt. Ein derartiger Vergleich der Erkennungszeitpunkte ist einfach durchzuführen und liefert ein hinreichend genaues Bewertungsergebnis.
Gemäß einer Ausführungsform ist der erste Bewertungsparameter eine Wahrscheinlichkeit bezüglich der Position und/oder Orientierung des ersten Objekts. Zusätzlich oder alternativ kann der zweite Bewertungsparameter eine Wahrscheinlichkeit bezüglich der Position und/oder Orientierung des zweiten Objekts sein. Mit der Wahrscheinlichkeit kann beispielsweise die Präzision der Positionen und/oder Orientierungen, genauer die Präzision eines Lageparameters bezüglich einer Wahrscheinlichkeitsverteilung der Positionen und/oder Orientierungen, angegeben werden. Der erste bzw. zweite Bewertungsparameter kann beispielsweise ein Lage- und/oder Streuungsparameter einer Wahrscheinlichkeitsverteilung sein. Möglich ist auch, dass der erste bzw. zweite Bewertungsparameter ein Konfidenzintervall angibt.
Damit können die Genauigkeit und die Zuverlässigkeit des Verfahrens erhöht werden.
Gemäß einer Ausführungsform werden für das Fahrzeug relevante erste Objekte aus den ersten Objekten durch die erste Version ausgewählt. Dabei werden miteinander übereinstimmende Objekte durch Vergleichen der relevanten ersten Objekte mit den zweiten Objekten bestimmt. Es werden dann die Bewertungsparameter der miteinander übereinstimmenden Objekte miteinander verglichen. Wie bereits weiter oben erwähnt, kann ein relevantes erstes Objekt aus den ersten Objekten beispielsweise in Abhängigkeit von seinem Abstand und/oder seiner Relativgeschwindigkeit relativ zum Fahrzeug und/oder in Abhängigkeit von seiner Objektklasse ausgewählt werden. Dies kann mittels des ersten Interpretationsmoduls der ersten Version erfolgen, das konfiguriert sein kann, um die Relevanz der ersten Objekte situations- und/oder funktionsabhängig zu bestimmen, beispielsweise durch Einteilen der ersten Objekte in verschiedene Relevanzkategorien, im einfachsten Fall etwa in die Relevanzkategorien „relevant“ und „nicht relevant“. Dadurch kann festgestellt werden, ob die zweite Version die durch die (validierte oder freigegebene) erste Version als relevant erkannten Objekte überhaupt erkennt. Wird dies festgestellt, so kann dies als starker Hinweis darauf gewertet werden, dass die Erkennungsgüte der zweiten Version zumindest nicht schlechter als die Erkennungsgüte der ersten Version ist.
Gemäß einer Ausführungsform werden für das Fahrzeug relevante zweite Objekte aus den zweiten Objekten, die mit keinem relevanten ersten Objekt übereinstimmen, durch die zweite Version ausgewählt. Dabei wird für jedes relevante zweite Objekt eine Einzelbewertung erzeugt, die anzeigt, ob die Erkennung des relevanten zweiten Objekts durch die zweite Version einer Verbesserung oder Verschlechterung der Erkennungsgüte der zweiten Version gegenüber der ersten Version entspricht. Die zweite Version wird dann ferner basierend auf den Einzelbewertungen bewertet. Hierzu kann zunächst festgestellt werden, ob die zweiten Objektdaten zweite Objekte enthalten, die mit keinem der relevanten ersten Objekte übereinstimmen, d. h., die durch die erste Version nicht oder zumindest nicht als relevant erkannt wurden. Weiter kann festgestellt werden, ob die zweiten Objekte, die mit keinem der relevanten ersten Objekte übereinstimmen, für das Fahrzeug relevant sind oder nicht. Wie bereits weiter oben erwähnt, kann dies mittels des zweiten Interpretationsmoduls der zweiten Version erfolgen, das - analog zum ersten Interpretationsmodul - konfiguriert sein kann, um die Relevanz der zweiten Objekte situations- und/oder funktionsabhängig zu bestimmen, beispielsweise durch Einteilen der zweiten Objekte in verschiedene Relevanzkategorien, im einfachsten Fall etwa in die Relevanzkategorien „relevant“ und „nicht relevant“.
Die Einzelbewertungen können beispielsweise als Teil des Bewertungsergebnisses an die zentrale Datenverarbeitungsvorrichtung gesendet werden. Zusätzlich oder alternativ kann das Bewertungsergebnis die den jeweiligen Einzelbewertungen zugrunde liegenden Objektdaten und/oder Sensordaten umfassen. Es ist möglich, dass die Objektdaten und/oder Sensordaten nur dann als Teil des Bewertungsergebnisses gesendet werden, wenn die Einzelbewertungen, denen sie zugrunde liegen, eine Verschlechterung der Erkennungsgüte der zweiten Version in Bezug auf die erste Version anzeigen.
Durch diese Ausführungsform kann die zweite Version in Abhängigkeit davon bewertet werden, ob die zweite Version relevante Objekte erkennt, die nicht bereits durch die erste Version erkannt wurden. Die Bewertung der zweiten Version kann beispielsweise mit jeder Einzelbewertung neu berechnet werden.
Gemäß einer Ausführungsform werden basierend auf den Sensordaten und/oder auf Fahrdynamikdaten, die durch mindestens einen Fahrdynamiksensor des Fahrzeugs erzeugt wurden, Änderungen eines Fahrzustands des Fahrzeugs bestimmt, die mit Erkennungszeitpunkten, zu denen die relevanten zweiten Objekte durch die zweite Version erkannt wurden, zeitlich korrelieren. Dabei wird jede Einzelbewertung durch Auswerten der mit dem jeweiligen relevanten zweiten Objekt zeitlich korrelierenden Änderung des Fahrzustands erzeugt. Zur Feststellung, ob die Erkennung der relevanten zweiten Objekte, die durch die erste Version nicht (als relevant) erkannt wurden, tatsächlich einer Verbesserung der Erkennungsgüte der zweiten Version gegenüber der ersten Version entspricht, können die Sensordaten und/oder die Fahrdynamikdaten beispielsweise ausgewertet werden, um eine Reaktion eines Fahrers des Fahrzeugs zum Erkennungszeitpunkt des betreffenden Objekts zu bestimmen und diese zu interpretieren. Ist beispielsweise keine oder zumindest keine relevante Reaktion des Fahrers feststellbar, so kann dies als starker Hinweis darauf gewertet werden, dass mit der Erkennung des betreffenden Objekts die Erkennungsgüte nicht nennenswert verbessert wurde, und umgekehrt.
Gemäß einer Ausführungsform werden die zweiten Objektdaten in mehreren aufeinanderfolgenden Zeitschriften erzeugt. Dabei werden die zweiten Objekte durch Vergleichen zwischen den zweiten Objektdaten aus unterschiedlichen Zeitschriften auf Plausibilität geprüft. Die zweite Version wird dann ferner in Abhängigkeit von der Plausibilität der zweiten Objekte bewertet. Beispielsweise können die Positionen und/oder Orientierungen ein und desselben Objekts aus unterschiedlichen Zeitschriften miteinander verglichen werden, um Inkonsistenzen, d. h. nicht plausible Änderungen der Position und/oder Orientierung des Objekts, zu ermitteln. Damit kann festgestellt werden, ob die zweite Version zeitlich konsistente und plausible Objektdaten liefert. Es ist möglich, dass Objektdaten bezüglich einzelner, nicht plausibler Objekte, etwa deren Positionen und/oder Orientierungen über mehrere aufeinanderfolgende Zeitschritte, als Teil des Bewertungsergebnisses an die zentrale Datenverarbeitungsvorrichtung gesendet werden.
Gemäß einer Ausführungsform umfasst das Bewertungsergebnis Datensequenzen aus den Sensordaten, den ersten Objektdaten und/oder den zweiten Objektdaten. Auf den Datensequenzen kann die Bewertung der zweiten Version beruhen. Anders ausgedrückt können die Datensequenzen eine Verbesserung oder Verschlechterung der Erkennungsgüte der zweiten Version gegenüber der ersten Version anzeigen. Durch Senden dieser Datensequenzen wird eine gezielte externe Auswertung der zweiten Version hinsichtlich deren Erkennungsgüte ermöglicht.
Gemäß einer Ausführungsform werden die Datensequenzen nur dann gesendet, wenn die zweite Version hinsichtlich der Erkennungsgüte schlechter als die erste Version bewertet wurde. Dadurch kann die Effizienz der Datenkommunikation zwischen dem Steuergerät und der zentralen Datenverarbeitungsvorrichtung verbessert werden. Kurze Beschreibung der Zeichnungen
Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, wobei weder die Zeichnungen noch die Beschreibung als die Erfindung einschränkend auszulegen sind.
Fig. 1 zeigt ein Fahrzeug mit einem Steuergerät gemäß einem Ausführungsbeispiel der Erfindung.
Fig. 2 zeigt verschiedene Module einer Software, die auf dem Steuergerät aus Fig. 1 läuft.
Die Figuren sind lediglich schematisch und nicht maßstabsgetreu. Gleiche Bezugszeichen bezeichnen in den Figuren gleiche oder gleichwirkende Merkmale.
Ausführungsformen der Erfindung
Fig. 1 zeigt ein Fahrzeug 100, das mit einem Steuergerät 102, einer Sensorik 104 zum Erfassen einer Umgebung des Fahrzeugs 100 und einer Aktorik 106 ausgestattet ist.
Die Sensorik 104 kann beispielsweise eine Kamera, einen Radar-, Lidar- und/oder Ultraschallsensor umfassen. Zusätzlich kann die Sensorik 104 mindestens einen Fahrdynamiksensor, etwa einen Beschleunigungs- oder Drehratensensor, umfassen. Die Sensorik 104 erzeugt in mehreren aufeinanderfolgenden Zeitschriften Sensordaten 108, die in dem Steuergerät 102 empfangen und dort im Rahmen einer Objekterkennung ausgewertet werden. Das Steuergerät 102 umfasst einen Speicher 110, auf dem eine entsprechende Software 111 gespeichert ist, sowie einen Prozessor 112 zum Ausführen der Software 111.
Es ist möglich, dass das Steuergerät 102 basierend auf den Sensordaten 108, d. h. basierend auf Ergebnissen der damit durchgeführten Objekterkennung, ein Steuersignal 114 zum automatischen Ansteuern der Aktorik 106 erzeugt. Die Aktorik 106 kann beispielsweise einen oder mehrere Lenk- und/oder Bremsaktoren zum Lenken bzw. Bremsen des Fahrzeugs 100 umfassen.
Auf dem Steuergerät 102 laufen zeitgleich zwei unterschiedliche Versionen lila, 111b der Software 111, in die jeweils die Sensordaten 108 eingegeben werden. Dabei werden durch Auswerten der Sensordaten 108 durch eine erste Version lila der Software 111 erste Objekte 116 in der Umgebung des Fahrzeugs 100 erkannt, während durch Auswerten der Sensordaten 108 durch eine zweite Version 111b der Software 111 zweite Objekte 118 in der Umgebung des Fahrzeugs 100 erkannt werden. Bei den ersten Objekten 116 und den zweiten Objekten 118, hier beispielhaft vorausfahrende Fahrzeuge, kann es sich um identische oder unterschiedliche Objekte handeln. Durch Vergleichen der ersten Objekte 116 mit den zweiten Objekten 118 kann das Steuergerät 102 eine Erkennungsgüte der zweiten Version 111b gegenüber der ersten Version lila bewerten. Dies wird nachstehend anhand von Fig. 2 näher beschrieben.
Fig. 2 zeigt ein Blockdiagramm der auf dem Steuergerät 102 laufenden Software 111. In diesem Beispiel handelt es sich bei der ersten Version lila um eine bereits validierte oder freigegebene, d. h. aktive Version der Software 111, während es sich bei der zweiten Version 111b um eine noch nicht validierte oder noch nicht freigegebene Version der Software 111 handelt, die im Gegensatz zur ersten Version lila in einer eingeschränkten Betriebsumgebung 200 des Steuergeräts 102 laufen kann, d. h. in einem von Komponenten außerhalb der eingeschränkten Betriebsumgebung 200 abgeschirmten Testbereich passiv mit der ersten Version lila mitlaufen kann. Bei der zweiten Version 111b kann es sich um eine Aktualisierung der ersten Version lila handeln, etwa um eine gegenüber der ersten Version lila verbesserte und/oder erweiterte Version der Software 111. Die zweite Version 111b kann auch als Sh ad ow- Software bezeichnet werden.
Alternativ kann die zweite Version 111b auch in gleicher Weise auf einem separaten Steuergerät allokiert sein.
In diesem Beispiel gehen die Sensordaten 108 sowohl in ein erstes Erkennungsmodul 202 der ersten Version lila als auch in ein zweites Erkennungsmodul 204 der zweiten Version 111b ein. Das erste Erkennungsmodul 202 erzeugt dabei aus den Sensordaten 108 erste Objektdaten 206, die Positionen und/oder Orientierungen der ersten Objekte 116 relativ zum Fahrzeug 100 umfassen. Das zweite Erkennungsmodul 204 erzeugt dabei aus den Sensordaten 108 zweite Objektdaten 208, die Positionen und/oder Orientierungen der zweiten Objekte 118 relativ zum Fahrzeug 100 umfassen.
Die erkannten Objekte 116, 118 können zusammen mit ihren jeweiligen Positionen und/oder Orientierungen beispielsweise in Form von Objektlisten in einem Umgebungsmodell der Umgebung des Fahrzeugs 100 gespeichert und dort fortlaufend basierend auf den Sensordaten 108 aktualisiert werden. Die ersten Objekte 116 und die zweiten Objekte 118 können in diesem Zusammenhang als in dem Umgebungsmodell gespeicherte Objektmodelle von in der Umgebung des Fahrzeugs 100 tatsächlich vorhandenen Objekten aufgefasst werden.
Zusätzlich zu den jeweiligen Positionen und/oder Orientierungen können die ersten Objektdaten 206 und/oder die zweiten Objektdaten 208 einen oder mehrere Objekttypen für jedes erkannte Objekt 116 bzw. 118 spezifizieren, wie beispielsweise „Fahrzeug“, „Fußgänger“ oder „Fahrbahnmarkierung“.
Die ersten Objektdaten 206 und die zweiten Objektdaten 208 werden in ein Bewertungsmodul 210 der Software 111 eingegeben, das in diesem Beispiel wie die zweite Version 111b aus Sicherheitsgründen in der eingeschränkten Betriebsumgebung 200 läuft. Das Bewertungsmodul 210 bewertet die Erkennungsgüte der zweiten Version 111b in Bezug auf die erste Version lila, indem es die ersten Objektdaten 206 mit den zweiten Objektdaten 208 in geeigneter Weise vergleicht. Dabei erzeugt das Bewertungsmodul 210 ein entsprechendes Bewertungsergebnis 212 und sendet dieses, beispielsweise über eine WLAN-, Bluetooth- und/oder Mobilfunkverbindung, an eine zentrale Datenverarbeitungsvorrichtung 214 außerhalb des Fahrzeugs 100 zur weiteren Auswertung.
Im Rahmen dieser Bewertung können die ersten Objekte 116 mit den entsprechenden zweiten Objekten 118 anhand eines oder mehrerer geeigneter Bewertungsparameter miteinander verglichen werden, beispielsweise anhand der jeweiligen Erkennungszeitpunkte oder anhand eines oder mehrerer Schätzwerte bezüglich der Genauigkeit und/oder Zuverlässigkeit der jeweiligen Positionen und/oder Orientierungen. Es ist möglich, dass die ersten Objektdaten 206 durch ein erstes Interpretationsmodul 216 der ersten Version lila interpretiert, d. h. hinsichtlich ihrer Relevanz für das Fahrzeug 100 ausgewertet werden. Dabei kann das erste Interpretationsmodul 216 abhängig von einer aktuellen Situation des Fahrzeugs 100 ein oder mehrere relevante erste Objekte 116’ aus den ersten Objekten 116 auswählen, in Fig. 1 beispielhaft ein links neben dem Fahrzeug 100 vorausfahrendes Fahrzeug, und entsprechend gefilterte erste Objektdaten 206’ an das Bewertungsmodul 210 senden.
Das Bewertungsmodul 210 kann dann die relevanten ersten Objekte 116’ mit den entsprechenden zweiten Objekten 118 verknüpfen, beispielsweise basierend auf den jeweiligen Positionen und/oder Orientierungen und/oder den jeweiligen Erkennungszeitpunkten. Anschließend können die Bewertungsparameter der miteinander verknüpften Objekte miteinander verglichen werden, um die zweite Version 111b zu bewerten. Bei den miteinander verknüpften Objekten kann es sich um Objekte handeln, die insofern miteinander übereinstimmen, als sie Objektmodelle ein und desselben Objekts sind, das in der Umgebung des Fahrtzeugs 100 tatsächlich vorhanden ist.
Darüber hinaus ist es möglich, dass die zweiten Objektdaten 208 durch ein zweites Interpretationsmodul 218 der zweiten Version 111b interpretiert werden, d. h. hinsichtlich ihrer Relevanz für das Fahrzeug 100 ausgewertet werden.
Dabei kann das zweite Interpretationsmodul 218 abhängig von der aktuellen Situation des Fahrzeugs 100 ein oder mehrere relevante zweite Objekte 118’ aus den zweiten Objekten 118 auswählen, in Fig. 1 beispielhaft ein rechts neben dem Fahrzeug 100 vorausfahrendes Fahrzeug, und entsprechend gefilterte zweite Objektdaten 208’ an das Bewertungsmodul 210 senden.
Das Bewertungsmodul 210 kann in diesem Fall bestimmen, ob es unter den relevanten ersten Objekten 206’ und den relevanten zweiten Objekten 208’ eindeutig miteinander übereinstimmende Objekte gibt oder nicht. Stimmt eines der relevanten zweiten Objekte 208’ nicht mit einem der relevanten ersten Objekte 206’ überein, so kann das Bewertungsmodul 210 für dieses zweite Objekt eine Einzelbewertung erzeugen, die anzeigt, ob die Erkennung dieses zweiten Objekts eine Verbesserung oder Verschlechterung der Erkennungsgüte der zweiten Version 111b gegenüber der ersten Version lila darstellt.
Basierend auf der Einzelbewertung kann dann das Bewertungsergebnis 212 erzeugt werden. Die Erzeugung der Einzelbewertung kann basierend auf den Sensordaten 108 erfolgen. Dabei können die Sensordaten 108 zusätzlich zu Umfelddaten, die durch einen oder mehrere Umfeldsensoren des Fahrzeugs 100 erzeugt wurden, Fahrdynamikdaten, die durch einen oder mehrere Fahrdynamiksensoren des Fahrzeugs 100 erzeugt wurden, umfassen.
Bei der Auswertung der Sensordaten 108 durch das Bewertungsmodul 210 können mit der Erkennung der relevanten zweiten Objekte 118’ zeitlich korrelierende Änderungen des fahrdynamischen Zustands des Fahrzeugs 100, beispielsweise ausgelöst durch eine entsprechende Reaktion dessen Fahrers, bestimmt werden. Anhand dieser Änderung kann schließlich festgestellt werden, ob die Erkennung des betreffenden Objekts einer Verbesserung oder Verschlechterung der Erkennungsgüte der zweiten Version 111b gleichkommt.
Alternativ kann das zweite Interpretationsmodul 218 konfiguriert sein, um zunächst diejenigen der zweiten Objekte 118 zu bestimmen, die mit keinem der relevanten ersten Objekte 116’ eindeutig übereinstimmen, und anschließend daraus die relevanten zweiten Objekte 118’ auszuwählen.
Zusätzlich kann das Bewertungsmodul 210 konfiguriert sein, um die zweiten Objekte 118 auf Plausibilität zu prüfen. Hierzu kann das Bewertungsmodul 210 die zweiten Objekte 118 anhand der zweiten Objektdaten 208 mehrerer aufeinanderfolgender Zeitschritte auswerten. Das Bewertungsergebnis 212 kann dabei ferner unter Berücksichtigung der Plausibilität der zweiten Objekte 118 bestimmt werden. Ein Beispiel für ein nicht plausibles oder inkonsistentes zweites Objekt 118 ist in Fig. 1 mit einem gestrichelten Rahmen angedeutet.
Die Bewertung der zweiten Version 111b im Sinne einer Validierung einer Erkennungsaufgabe, die mittels des zweiten Erkennungsmoduls 204 und/oder des zweiten Interpretationsmoduls 218 gelöst werden soll, kann beispielsweise folgende Schritte umfassen.
Als Erstes wird überprüft, ob die relevanten ersten Objekte 116’, die durch die erste Version lila erkannt wurden, auch durch die im Shadow Mode laufenden zweiten Version 111b in gleicher oder verbesserter Art und Weise erkannt wurden. Die Relevanz der ersten Objekte 116 wird dabei nicht durch das erste Erkennungsmodul 202 selbst, sondern durch das erste Interpretationsmodul 216, d. h. durch ein oder mehrere nachfolgende interpretierende Softwareelemente, in einer Art Situationsanalyse ermittelt. Um festzustellen, welche der zweiten Objekte 118 den relevanten ersten Objekten 116’ entsprechen, wird im Bewertungsmodul 210 eine Verknüpfung durchgeführt. Anhand definierter Metriken, die beispielsweise die jeweiligen Erkennungszeitpunkte oder eine Konfidenz bezüglich der jeweiligen Positionen und/oder Orientierungen umfassen können, wird dann die Erkennungsgüte der zwei Versionen lila, 111b miteinander verglichen. Wird eine Verschlechterung der Erkennungsgüte der zweiten Version 111b festgestellt, so kann eine entsprechende Datensequenz direkt an die zentrale Datenverarbeitungsvorrichtung 214 gesendet werden. Die Datensequenz kann dabei aus den entsprechenden Sensordaten 108 und/oder den entsprechenden Objektdaten 116 bzw. 118 erzeugt werden. Eine Verbesserung der Erkennungsgüte kann umgekehrt durch Nichteintreffen solcher Datensequenzen an der zentralen Datenverarbeitungsvorrichtung 214 bestätigt werden. Zusätzlich oder alternativ kann die Verbesserung oder Verschlechterung der Erkennungsgüte durch regelmäßiges Senden einer gebündelten Statistik vom Steuergerät 102 an die zentrale Datenverarbeitungsvorrichtung 214 erfasst werden.
Als Zweites wird für jedes zweite Objekt 118, das durch die zweite Version 111b erkannt wurde, aber nicht mit einem der relevanten ersten Objekte 116’ verknüpft werden kann, dessen Relevanz für das Fahrzeug 100 festgestellt und es wird eine Bewertung durchgeführt, die anzeigt, ob sich die Erkennungsgüte durch Erkennen dieses zweiten Objekts verschlechtert oder verbessert hat. Hat das zweite Interpretationsmodul 218 in einer Art Situationsanalyse ein zweites relevantes Objekt 118’ ermittelt, das mit keinem der relevanten ersten Objekte 116’ verknüpft werden kann, so wird zunächst mit definierten Logiken, beispielsweise anhand der Reaktion des Fahrers auf dieses Objekt, ermittelt, ob die Erkennung dieses Objektes eine Verbesserung oder Verschlechterung der Erkennungsgüte darstellt. Je nach Logik kann der Vorgang in einer Statistik erfasst werden. Zusätzlich oder alternativ kann das direkte Aussenden einer entsprechenden Datensequenz zur externen Auswertung in der zentralen Datenverarbeitungsvorrichtung 214 ausgelöst werden.
Als Drittes wird überprüft, ob die zweiten Objekte 118 und/oder die relevanten zweiten Objekte 118’ über die Zeit konsistent und plausibel sind. Hierfür detektiert das Bewertungsmodul 210 anhand von Zeitverläufen aus den Sensordaten 108 und/oder den zweiten Objektdaten 208 bzw. 208’ Inkonsistenzen, etwa plötzlich auftauchende oder plötzlich verschwindende zweite Objekte 118 in der näheren Umgebung des Fahrzeugs 100. Informationen über diese Objekte können entweder direkt in Form einer entsprechenden Datensequenz oder gebündelt in Form einer Statistik vom Steuergerät 102 an die Datenverarbeitungsvorrichtung 214 gesendet werden.
Die Validierung einer Klassifikationsaufgabe kann in analoger Weise durchgeführt werden. Abschließend wird darauf hingewiesen, dass Begriffe wie „aufweisend“,
„umfassend“ etc. keine anderen Elemente oder Schritte ausschließen und Begriffe wie „eine“ oder „ein“ keine Vielzahl ausschließen. Bezugszeichen in den Ansprüchen sind nicht als Einschränkung anzusehen.

Claims

Ansprüche
1. Verfahren zum
Bewerten einer Software (111) für ein Steuergerät (102) eines Fahrzeugs
(100), wobei das Steuergerät (102) einen Speicher (110), in dem eine erste Version (lila) und eine zweite Version (111b) der Software (111) gespeichert sind, sowie einen Prozessor (112) zum Ausführen der ersten Version (lila) und der zweiten Version (111b) umfasst, wobei das Verfahren umfasst:
Empfangen von Sensordaten (108), die durch eine Sensorik (104) zum Erfassen einer Umgebung des Fahrzeugs (100) erzeugt wurden, in dem Steuergerät (102);
Eingeben der Sensordaten (108) in die erste Version (lila) und die zweite Version (111b);
Erzeugen erster Objektdaten (206, 206’) aus den Sensordaten (108) durch die erste Version (lila), wobei die ersten Objektdaten (206, 206’) Positionen und/oder Orientierungen von durch die erste Version (lila) erkannten ersten Objekten (116, 116’) in der Umgebung des Fahrzeugs (100) umfassen;
Erzeugen zweiter Objektdaten (208, 208’) aus den Sensordaten (108) durch die zweite Version (111b), wobei die zweiten Objektdaten (208, 208’) Positionen und/oder Orientierungen von durch die zweite Version (111b) erkannten zweiten Objekten (118, 118’) in der Umgebung des Fahrzeugs (100) umfassen;
Bewerten der zweiten Version (111b) hinsichtlich einer Erkennungsgüte durch Vergleichen der ersten Objektdaten (206, 206’) mit den zweiten Objektdaten (208, 208’), wobei ein Bewertungsergebnis (212) erzeugt wird; und
Senden des Bewertungsergebnisses (212) von dem Steuergerät (102) an eine zentrale Datenverarbeitungsvorrichtung (214).
2. Verfahren nach
Anspruch 1, wobei für jedes erste Objekt (116, 116’) mindestens ein erster Bewertungsparameter bestimmt wird, der anzeigt, wie gut das erste Objekt (116, 116’) durch die erste Version (lila) erkannt wurde; wobei für jedes zweite Objekt (118, 118’) mindestens ein zweiter Bewertungsparameter bestimmt wird, der anzeigt, wie gut das zweite Objekt (118, 118’) durch die zweite Version (111b) erkannt wurde; wobei die zweite Version (111b) durch Vergleichen der ersten Bewertungsparameter mit den zweiten Bewertungsparametern bewertet wird.
3. Verfahren nach
Anspruch 2, wobei der erste Bewertungsparameter ein Erkennungszeitpunkt ist, zu dem das erste Objekt (116, 116’) durch die erste Version (lila) erkannt wurde; und/oder wobei der zweite Bewertungsparameter ein Erkennungszeitpunkt ist, zu dem das zweite Objekt (118, 118’) durch die zweite Version (111b) erkannt wurde.
4. Verfahren nach
Anspruch 2 oder 3, wobei der erste Bewertungsparameter eine Wahrscheinlichkeit bezüglich der Position und/oder Orientierung des ersten Objekts (116, 116’) ist; und/oder wobei der zweite Bewertungsparameter eine Wahrscheinlichkeit bezüglich der Position und/oder Orientierung des zweiten Objekts (118, 118’) ist.
5. Verfahren nach einem der Ansprüche 2 bis 4, wobei für das Fahrzeug (100) relevante erste Objekte (116’) aus den ersten Objekten (116) durch die erste Version (lila) ausgewählt werden; wobei miteinander übereinstimmende Objekte (116’, 118, 118’) durch Vergleichen der relevanten ersten Objekte (116’) mit den zweiten Objekten (118, 118’) bestimmt werden; wobei die Bewertungsparameter der miteinander übereinstimmenden Objekte (116’, 118, 118’) miteinander verglichen werden.
6. Verfahren nach
Anspruch 5, wobei für das Fahrzeug (100) relevante zweite Objekte (118’) aus den zweiten Objekten (118), die mit keinem relevanten ersten Objekt (116’) übereinstimmen, durch die zweite Version (111b) ausgewählt werden; wobei für jedes relevante zweite Objekt (118’) eine Einzelbewertung erzeugt wird, die anzeigt, ob die Erkennung des relevanten zweiten Objekts (118’) durch die zweite Version (111b) einer Verbesserung oder Verschlechterung der Erkennungsgüte der zweiten Version (111b) gegenüber der ersten Version (lila) entspricht; wobei die zweite Version (111b) ferner basierend auf den Einzelbewertungen bewertet wird.
7. Verfahren nach
Anspruch 6, wobei basierend auf den Sensordaten (108) und/oder auf Fahrdynamikdaten, die durch mindestens einen Fahrdynamiksensor des Fahrzeugs (100) erzeugt wurden, Änderungen eines Fahrzustands des Fahrzeugs (100) bestimmt werden, die mit Erkennungszeitpunkten, zu denen die relevanten zweiten Objekte (118’) durch die zweite Version (111b) erkannt wurden, zeitlich korrelieren; wobei jede Einzelbewertung durch Auswerten der mit dem jeweiligen relevanten zweiten Objekt (118’) zeitlich korrelierenden Änderung des Fahrzustands erzeugt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweiten Objektdaten (208, 208’) in mehreren aufeinanderfolgenden Zeitschriften erzeugt werden; wobei die zweiten Objekte (118, 118’) durch Vergleichen zwischen den zweiten Objektdaten (208, 208’) aus unterschiedlichen Zeitschriften auf Plausibilität geprüft werden; wobei die zweite Version (111b) ferner in Abhängigkeit von der Plausibilität der zweiten Objekte (118, 118’) bewertet wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bewertungsergebnis (212) Datensequenzen aus den Sensordaten (108), den ersten Objektdaten (206, 206’) und/oder den zweiten Objektdaten (208, 208’) umfasst.
10. Verfahren nach Anspruch 9, wobei die Datensequenzen nur dann gesendet werden, wenn die zweite Version (111b) hinsichtlich der Erkennungsgüte schlechter als die erste Version (lila) bewertet wurde.
11. Steuergerät (102), umfassend einen Prozessor (112), der konfiguriert ist, um das Verfahren nach einem der vorhergehenden Ansprüche auszuführen.
12. Computerprogramm, umfassend Befehle, die einen Prozessor (112) bei Ausführung des Computerprogramms durch den Prozessor (112) veranlassen, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
13. Computerlesbares Medium, auf dem das Computerprogramm nach Anspruch 12 gespeichert ist.
EP22706756.8A 2021-03-24 2022-02-03 Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs Pending EP4315069A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021202903.5A DE102021202903A1 (de) 2021-03-24 2021-03-24 Verfahren zum Bewerten einer Software für ein Steuergerät eines Fahrzeugs
PCT/EP2022/052522 WO2022199916A1 (de) 2021-03-24 2022-02-03 Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs

Publications (1)

Publication Number Publication Date
EP4315069A1 true EP4315069A1 (de) 2024-02-07

Family

ID=80595546

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22706756.8A Pending EP4315069A1 (de) 2021-03-24 2022-02-03 Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs

Country Status (7)

Country Link
US (1) US12386724B2 (de)
EP (1) EP4315069A1 (de)
JP (1) JP7634108B2 (de)
KR (1) KR20230157514A (de)
CN (1) CN117099085A (de)
DE (1) DE102021202903A1 (de)
WO (1) WO2022199916A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7777239B2 (ja) * 2022-09-30 2025-11-27 Ａｓｔｅｍｏ株式会社 電子制御装置、車両制御システム、及びソフトウェア検証方法
DE102023123177A1 (de) 2023-08-29 2025-03-06 Audi Aktiengesellschaft Vorrichtung zum Betrieb eines Kraftfahrzeugs sowie Kraftfahrzeug
KR20250090104A (ko) * 2023-12-12 2025-06-19 현대자동차주식회사 전자 장치 및 제어 방법

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7934201B2 (en) * 2006-10-17 2011-04-26 Artoftest, Inc. System, method, and computer readable medium for universal software testing
JP4254844B2 (ja) * 2006-11-01 2009-04-15 トヨタ自動車株式会社 走行制御計画評価装置
JP2009276906A (ja) 2008-05-13 2009-11-26 Panasonic Corp 走行情報提供装置
US20210326236A1 (en) * 2016-02-29 2021-10-21 Jpmorgan Chase Bank, N.A. Systems and methods for resiliency testing
US20180267538A1 (en) * 2017-03-15 2018-09-20 Toyota Jidosha Kabushiki Kaisha Log-Based Vehicle Control System Verification
US10884902B2 (en) * 2017-05-23 2021-01-05 Uatc, Llc Software version verification for autonomous vehicles
JP7027721B2 (ja) 2017-08-07 2022-03-02 株式会社Ihi 検証システム及び検証方法
US10073763B1 (en) * 2017-12-27 2018-09-11 Accenture Global Solutions Limited Touchless testing platform
JP7208610B2 (ja) 2018-07-20 2023-01-19 学校法人 芝浦工業大学 車両認識システムおよび車両認識方法
JP7074723B2 (ja) 2019-07-04 2022-05-24 Kddi株式会社 学習装置及びプログラム
DE102019211037A1 (de) * 2019-07-25 2021-01-28 Robert Bosch Gmbh Verfahren zum Testen eines Systems

Also Published As

Publication number Publication date
US20240184686A1 (en) 2024-06-06
DE102021202903A1 (de) 2022-09-29
WO2022199916A1 (de) 2022-09-29
US12386724B2 (en) 2025-08-12
JP7634108B2 (ja) 2025-02-20
JP2024512563A (ja) 2024-03-19
CN117099085A (zh) 2023-11-21
KR20230157514A (ko) 2023-11-16

Similar Documents

Publication Publication Date Title
DE102016212326A1 (de) Verfahren zur Verarbeitung von Sensordaten für eine Position und/oder Orientierung eines Fahrzeugs
DE102017215552A1 (de) Plausibilisierung der Objekterkennung für Fahrassistenzsysteme
DE102016212195A1 (de) Verfahren zum Durchführen eines automatischen Eingriffs in die Fahrzeugführung eines Fahrzeugs
WO2022199916A1 (de) Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs
WO2022056564A1 (de) Verfahren und system zum testen eines fahrerassistenzsystems
WO2020061603A1 (de) Verfahren und vorrichtung zur analyse eines sensordatenstroms sowie verfahren zum führen eines fahrzeugs
DE102021128041A1 (de) Verbesserung eines neuronalen fahrzeugnetzwerks
DE102017206344A1 (de) Fahrerassistenzsystem für ein Fahrzeug
WO2021130066A1 (de) Training von neuronalen netzen durch ein neuronales netz
EP3530537B1 (de) Kraftfahrzeug-steuervorrichtung und verfahren zum betreiben der steuervorrichtung zum autonomen führen eines kraftfahrzeugs
DE102020211970A1 (de) Verfahren zum Steuern eines Fahrzeugs
DE102020213496A1 (de) Validierung von Modellen für Fahrbahn-Spuren basierend auf Schwarmdaten
DE102018213844A1 (de) Verfahren zum Testen einer zumindest teilautomatisierten Fahrfunktion für Kraftfahrzeuge
DE102017201796A1 (de) Steuervorrichtung zum Ermitteln einer Eigenbewegung eines Kraftfahrzeugs sowie Kraftfahrzeug und Verfahren zum Bereitstellen der Steuervorrichtung
DE102017223621A1 (de) Verfahren und Steuereinheit zur Steuerung einer Funktion eines zumindest teilweise automatisiert fahrenden Fahrzeugs
DE102024100521A1 (de) Bildgestützte generierung von beschreibenden und wahrnehmungs-nachrichten von automobilszenen
WO2023131603A1 (de) Verfahren zur optimierung der umfeldwahrnehmung für ein fahrunterstützungssystem mittels zusätzlicher referenzsensorik
DE102018211726A1 (de) Verfahren zum automatischen maschinellen Trainieren eines elektronischen Fahrzeugführungssystems, sowie Kraftfahrzeug
DE102020206610A1 (de) Sicherheitsarchitektur zur steuerung eines autonomen fahrzeugs
DE102017201517A1 (de) Verfahren und Vorrichtung zum Plausibilisieren einer Fahrzeugtrajektorie zum Steuern eines Fahrzeugs
WO2023222357A1 (de) Verfahren und vorrichtung zum erkennen einer fehlfunktion eines umfeldmodells einer automatisierten fahrfunktion
WO2023031018A1 (de) Verfahren zum infrastrukturgestützten assistieren eines kraftfahrzeugs
DE102021209431A1 (de) Verfahren zum zumindest teilautomatisierten Führen eines Kraftfahrzeugs
DE102024108224B3 (de) Verfahren zur relationalen speicherung von objekt-eigenschaften eines objektes, zum trainieren einer künstlichen intelligenz und zur erzeugung einer ein objekt betreffenden klasse, computerprogrammprodukt, speichermedium, datenträgersignal, vorrichtungen und fahrzeug
DE102021107938A1 (de) Verfahren, Vorrichtung und Computerprogramm zur Entwicklung, Parametrierung, Absicherung und/oder zum Betreiben eines Fahrzeugsystems

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231024

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20260324