Method and system for fleet-based data adaptation and adaptation by driver assistance system of individual vehicle

Abstract

A method includes receiving input condition data for a plurality of remote vehicles in a fleet and for generating automatic control commands at the vehicles to control the vehicles. The method then includes receiving actual output parameter measurement data from the remote vehicle and derived using the automatic control command, and receiving or generating performance measurement data dependent at least in part on a difference between the actual output parameter measurement data and the expected output parameter measurement data. Thereafter, the method determines whether one or more performance is considered insufficient. The method uses data of a fleet database to update a correlation of calibration control commands to input conditions, and generates calibration corrections based on the correlation, and will be used to change or replace previous control command values associated with insufficient performance measurements. The calibration correction is then sent to the remote vehicle.

Description

BACKGROUND

[0001] Modern vehicles are becoming increasingly automated, i.e., capable of providing driving control with less and less driver intervention. Vehicle automation has been categorized into different levels of numerals ranging from zero, corresponding to no automation with full human control, to five, corresponding to full automation with no human control. Various driver assistance systems, such as cruise control, adaptive cruise control, and parking assistance systems, correspond to lower levels of automation, while truly "driverless" vehicles, or autonomous driving, correspond to higher levels of automation. These systems have various adaptive and self-learning strategies that use vehicle-own onboard measurements to improve driver assistance performance on individual vehicles. SUMMARY

[0002] In an example implementation, a method includes receiving input condition data of a plurality of remote vehicles in a fleet and for generating automatic control commands at a vehicle to control the vehicle. The method includes receiving actual output parameter measurement data from the remote vehicles and resulting from use of the automatic control commands, and receiving or generating performance measurement data that depends at least in part on a difference between the actual output parameter measurement data and expected output parameter measurement data. Thereafter, the performance measurement data, the input condition data, and the output parameter measurement data are placed into one or more fleet databases, and the method determines whether one or more of the performance measurements in the fleet databases are deemed to be deficient. The method uses data of the fleet databases to update a calibration control command to input condition correlation, and adapts one or more control commands related to the update. The method includes generating a calibration correction that is based on the correlation and that is to be used to change or replace a previous control command value associated with the deficient performance measurement. Thereafter, the method sends the calibration correction or the one or more control commands or both to the remote vehicles.

[0003] Further according to another example implementation, the performance measurement is generated at the vehicle.

[0004] Further according to another example implementation, the performance measurement is generated remotely from the vehicle.

[0005] Further according to another example implementation, the calibration correction is part of a software or firmware update of a driver assistance program on the remote vehicle.

[0006] Further according to another example implementation, the updating and generating includes using a calibration equation that takes into account a fleet-based version of one or more input conditions, one or more control commands, and one or more performance measurements.

[0007] Further according to another example implementation, the updating includes determining a distribution of the error according to one or more input conditions, and using the distribution to determine a correspondence between the control commands and actual output parameters used to determine the performance measures associated with the one or more input conditions, and using the correspondence between the control commands and the actual output parameters to determine the control command to input condition correlation.

[0008] Further according to another example implementation, the method includes updating the fleet database with an indication of which events triggered an insufficient performance measure, where the events include a corresponding input condition, control command, and output parameter measurement.

[0009] Further according to another example implementation, the method includes updating the fleet database with the updated control command to input condition correlation data.

[0010] Further according to another example implementation, the method includes testing the calibration correction on a test vehicle prior to sending the calibration correction to the fleet of vehicles.

[0011] In another example implementation, a computing device includes a memory that stores driver assistance data; and a processor circuit that forms one or more processors and is communicatively coupled to the memory. The processor is to operate by receiving input condition data for a plurality of remote vehicles in a fleet of vehicles that are remote from the computing device and that are used to generate automatic control commands at the vehicles to control the vehicles; receiving actual output parameter measurement data from the remote vehicles; and receiving performance measures that depend at least in part on a difference between the actual output parameter measurement data and expected output parameter measurement data that depends on the automatic control commands. The processor is further to operate by placing the performance measure data, the input condition data, and the output parameter measurement data into a fleet database; determining whether one or more performance measures in the fleet database are deemed to be insufficient; using data of the fleet database to update a calibration control command to input condition correlation; generating a calibration correction that is based on the correlation and that is to be used to change or replace a previous control command value associated with the insufficient performance measure; and sending the calibration correction to the remote vehicles.

[0012] Further according to another example implementation, where the input condition data includes a state of the individual vehicle that includes at least one of: a location, an orientation, a vehicle speed, a direction of motion, a road surface condition, a positioning of an object relative to the vehicle, a vehicle acceleration, a vehicle deceleration, a visibility, and a lighting condition.

[0013] Further according to another example implementation, the input condition data includes an environment of the individual vehicle that includes at least one of: an outdoor temperature, a humidity, and an ambient pressure.

[0014] In addition, according to another example implementation, the processor also operates by obtaining input conditions from a computer network and including at least one of the following: climate, external wind speed, outdoor temperature, precipitation, humidity, lane surface conditions, and environmental pressure.

[0015] In addition, according to another example implementation, the control command includes at least one of the following: steering torque or angle setting, braking pressure setting, or accelerator setting, and wherein the output parameter measurement data includes at least one of the following: wheel steering angle, deceleration measurement, vehicle speed, or acceleration measurement.

[0016] In another example implementation, a vehicle includes one or more controllers, which include: a memory; processor circuitry forming one or more processors communicatively coupled to the memory; and a driver assistance unit operated by the one or more processors. The processors operate by: generating input condition data for generating automatic control commands at the vehicle to control the vehicle; generating output parameter measurement data obtained using the automatic control commands; generating performance measurement data that depends at least in part on the difference between the actual output parameter measurement data and the expected output parameter measurement data of the automatic control commands; and sending the performance measurement data, input condition data, and actual output parameter measurement data to a fleet data adaptation computing device, which receives transmissions from multiple remote vehicles in the fleet and places the performance measurement, input condition, and actual output parameter measurement data into a fleet database. The processor also operates by receiving calibration corrections over the air (OTA) from the fleet data adaptation computing device, which generates the calibration corrections by: determining whether performance measurements in the fleet database are considered insufficient; using data from the fleet database to determine the correlation between the updated calibration control commands and input conditions; generating calibration corrections based on the correlation; and replacing or modifying previously insufficient control command values ​​at the vehicle using the calibration corrections.

[0017] Furthermore, according to another example implementation, performance measurement data is considered insufficient when the determination error is large enough to affect safety or lead to a reduction in the quality of the vehicle user experience.

[0018] Furthermore, according to another example implementation, receiving calibration corrections is part of broadcasting calibration corrections to multiple vehicles in the fleet.

[0019] Furthermore, according to another example implementation, receiving calibration corrections includes receiving multiple calibration corrections for multiple different types of control commands.

[0020] In addition, according to another example implementation, vehicle performance measurements, status and environment, as well as calibration corrections, are transmitted via a 5G network at 10-20Gbps.

[0021] Furthermore, according to another example implementation, the vehicle's input conditions and the transmission of calibration corrections are encrypted. Attached Figure Description

[0022] The present disclosure will be described below with reference to the accompanying drawings. The drawings are not drawn to scale, and the numbers in the drawings denote similar elements, and wherein:

[0023] Figure 1 This is a schematic diagram of an example driver assistance communication network for a fleet of vehicles, based on at least one of the implementations described in this paper;

[0024] Figure 2A This is a schematic diagram of an example fleet of vehicles based on at least one of the implementation methods described in this paper;

[0025] Figure 2B It is shown Figure 2A Example locations of vehicles in the fleet and heatmaps based on at least one of the implementations in this paper;

[0026] Figure 3 This is a flowchart of an example process for adapting fleet data for a driver assistance system according to at least one of the implementation methods described in this paper;

[0027] Figure 4 It is a graph showing performance measurements from multiple vehicles in a fleet according to at least one of the implementations described herein;

[0028] Figure 5 It is a graph showing the lateral offset of a vehicle platoon to the desired path according to the wind spectrum distribution of at least one of the implementations in this paper;

[0029] Figure 6 This is a graph showing the handwheel angle error of a vehicle fleet according to at least one of the implementations described herein, based on the wind spectrum distribution;

[0030] Figure 7 This is a graph showing the temperature-dependent handwheel angle error for a fleet of vehicles according to at least one of the implementations described herein;

[0031] Figure 8 It is a graph showing the spectral distribution of the lateral offset of a vehicle convoy to the desired path according to the temperature of at least one of the implementations in this paper;

[0032] Figure 9This is a graph showing the spectral distribution of the handwheel angle error for a fleet of vehicles according to temperature, based on at least one of the implementations described herein.

[0033] Figure 10 This is a schematic top view illustrating a steering correction scenario for a vehicle's yaw rate error according to at least one of the implementations described herein;

[0034] Figure 11 It is shown Figure 10 The vehicle's steering yaw rate error over time and a graph based on at least one of the implementations in this paper; and

[0035] Figure 12 It is a comparison based on at least one of the implementation methods in this paper. Figure 9 Another chart showing the steering yaw rate error correction for vehicles with and without fleet data adaptation. Detailed Implementation

[0036] The following detailed description presents only exemplary implementations and is not intended to limit this disclosure or its application and use. Furthermore, it is not intended to be bound by the foregoing background or any theories set forth in the following detailed description.

[0037] The driver assistance system employs an adaptive self-learning strategy, where vehicle sensors are used to make real-time measurements to determine the vehicle's state, including its motion, while the driver assistance system is performing actions to control the vehicle's movement. These strategies are used to learn in-vehicle uncertainties and adjust suboptimal (or inadequate) driver assistance settings to enhance control and the customer experience.

[0038] However, it has been found that the methods disclosed herein improve the performance of driver assistance systems when considering fleet data from multiple vehicles to calibrate on-board driver assistance control actions or commands. Therefore, in one form, this disclosure generally relates to fleet data collected from a fleet of connected vehicles and via a wireless communication network, characterizing the collected fleet data for a single, specific control type or function (such as steering control for an example), and using this characterization to generate calibration values ​​or signals for a specific type of vehicle (e.g., brand (e.g., manufacturer), model, and year of manufacture) or even a specific function on a particular individual vehicle. The calibration values ​​are then sent to the individual vehicles or multiple vehicles in the fleet. In other words, this method and system use an over-the-air (OTA) network to send adjustments to the correlation between driver assistance control command values ​​and input condition data to update the software or firmware of the driver assistance system on the individual vehicle. The reduction in calibration error has been found to be significant, such as a 67% reduction in error for autonomous steering control in the example described below. Here, the terms correlation and correspondence refer in a general sense to elements in a causal relationship, and not to or limited to a strict mathematical relationship or algorithm.

[0039] refer to Figure 1 A system 100 for collecting and using fleet data from a fleet 102 of vehicles 104 is described in various implementations herein. In addition to the fleet 102, the system 100 includes a fleet data adaptation server or computing device (or fleet server only) 108, which may be or has one or more fleet servers that communicate remotely with one or more vehicles 104 via a communication network 106. In various implementations, the system 100 generates fleet data, including data related to braking, steering, and / or driving, to name only a few examples, but which may be used by any control or system that uses input conditions (such as the vehicle's state or the environment around the vehicle) to set or instruct control commands on the vehicle. The fleet data may be communicated to the fleet data adaptation server 108 for analysis and characterization. Calibration is performed at the fleet server 108, which uses the fleet data to generate control command corrections (or calibration values) to adjust or replace previous control commands or control command values ​​that were primarily based on on-board measurements without using fleet data or have become obsolete. The calibration value represents the correlation between the input condition that reduces performance measurement or error and the control command, and the calibration value can be the control command value or a modified value used to adjust the control command value. It will be understood that this can also include adapting new control commands that were not previously used when fleet data indicates that new correlations can be used. The fleet server then sends the calibration value back to vehicle 104 to update the driver assistance program at vehicle 104. According to the example implementation herein, the details of the operation of system 100 utilize... Figure 3The process is described in 300, and its sub-processes and implementation methods utilize... Figures 4-12 Described by any one of them.

[0040] Return to Figure 1 In various implementations, vehicle 104 refers to one of several different vehicles 104 operating on a road or other path (collectively referred to here as a "lane"). System 100 may include any number of vehicles 104 that work together and perform in conjunction with a remote fleet server 108. Figure 3 The process 300 is described in the text. In addition, although the singular term “vehicle” may sometimes be used, it will be understood that unless the context otherwise indicates, it refers to any number of different vehicles (e.g., in a convoy or otherwise used together in system 100).

[0041] In one form, each vehicle 104 includes an automobile, and vehicle 104 can be any of several different types of automobiles, such as, for example, a sedan, van, truck, or sport utility vehicle (SUV), and can be two-wheel drive (2WD) (i.e., rear-wheel drive or front-wheel drive), four-wheel drive (4WD), or all-wheel drive (AWD) and / or various other types of vehicles. Additionally, vehicle 104 may also include motorcycles or other vehicles, such as aircraft, spacecraft, boats, etc., and / or one or more other types of mobile platforms (e.g., robots and / or other mobile platforms).

[0042] In some methods, some of the vehicles 104 (in the convoy 102) may be operated wholly or partially by human drivers, while other vehicles in the convoy 104 may include autonomous or semi-autonomous vehicles, for example, where vehicle control (including acceleration, deceleration, braking, and / or steering) is wholly or partially planned and executed automatically by control unit 110. Additionally, some vehicles 104 may be operated by humans at certain times and by automatic control at other times. Furthermore, some of the vehicles 104 include automated functions via a computer model trained using data generated and processed by system 100.

[0043] Many physical components and various details of the mechanical and electrical systems on vehicle 104 are omitted to avoid obscuring the description of the fleet data adaptation methods and systems disclosed herein. Relatedly, each individual vehicle 104 may have a control unit 110, which includes a sensor unit or array 112, a controller or computer system 111, a display 113 for providing information to the driver or passengers, and a transceiver 115 for communicating with a remote fleet adaptation server 108 (also referred to herein simply as a fleet unit or fleet server 108) or other remote computers or servers. Control unit 110 also includes an encryption / decryption (E / D) unit 117 for encrypting output data transmitted by transceiver 115 and decrypting input data received by transceiver 115 to protect the privacy of vehicle users.

[0044] In one example configuration, control unit 110 also facilitates or performs the generation and processing of sensor data by using sensors or sensor array 112 and for vehicle 104 or another vehicle. Additionally, control unit 110 is coupled to braking, steering, and / or drive (or throttle or accelerator) systems, and when vehicle 104 is an autonomous or semi-autonomous vehicle, control unit 110 can also provide control over the automatic characteristics of vehicle 104, including the automatic operation of the braking, steering, and / or drive systems.

[0045] In one example configuration, sensor array 112 acquires sensor data used to generate input condition data, which will be used to set control commands and sent to fleet server 108. Example sensor array 112 includes one or more cameras (such as video cameras and / or still image cameras in some implementations) and may include one or more other detection sensors, such as radar, sonar, lidar, etc., and / or other types of sensors, such as vehicle positioning sensors, speed sensors, accelerometers, gyroscopes, inertial measurement units (IMUs), brake sensors, steering sensors, etc. Sensor array 112 is used to capture the state, location, and orientation of vehicle 104, and to detect, identify, and / or track objects near vehicle 104. Other vehicle location data may be obtained from wireless communications or computer networks, such as via GPS and other navigation applications. Such location data may include map data indicating lanes, traffic data, weather conditions, construction information, etc.

[0046] The controller 111 of control unit 110 includes one or more driver assistance (or assisted driving) programs or units 114, a driver assistance (DA) update unit 105 for updating driver assistance units 114, a memory 116, a storage device 119, and processor circuitry forming one or more processors 118 that operate driver assistance units 114. Driver assistance units 114 may or may not be stored in memory 116. Control unit 110 or controller 111 may also include an interface and a computer bus (not shown). In one example, controller (or computer system) 111 obtains sensor data from sensor array 112 and / or other data from transceiver 115. In various examples, controller 111 processes sensor or other data to develop, train, and / or implement one or more autonomous driving models for vehicle 104 (e.g., automatic control for braking systems, steering systems, drive systems, and / or one or more other related features, such as cruise control, blind spot or pedestrian detection, etc.).

[0047] Control unit 110 and consequently controller 111 are mounted on vehicle 104. In other forms, control unit 110, controller 111, and / or one or more components thereof may be located outside vehicle 104, for example, at other network locations such as the cloud or other remote servers, where sensor data processing, including image processing, is performed remotely. In other examples, as further described below, controller 111 also collaborates with a remote fleet data adaptation system or server 108 to perform functions. It will be understood that controller 111 may otherwise differ from... Figure 1 The implementation described herein. For example, controller 111 may be coupled to or otherwise utilize one or more remote computer systems and / or other control systems, for example as part of one or more of the aforementioned vehicle 104 equipment and systems.

[0048] Processor 118 performs the computational and control functions of controller 111 and may include any type of processor circuitry, processor core, single integrated circuit such as a microprocessor, processor on a system-on-a-chip (SoC), or any suitable number of integrated circuit devices, processor circuitry, and / or circuit boards that work together to implement the functions of the processing unit to form one or more processors. During operation, processor 118 executes one or more of driver assistance programs 114 and thus controls the general functions of controller 111 and performs the processes described herein at the vehicle, such as those in Figure 2- Figure 12 The part described in the text and further described below in conjunction with its implementation method.

[0049] The driver assistance (DA) unit or program 114 may be an advanced driver assistance system (ADAS) and may include autonomous driver (AD) functions, which include either functions or levels of automation ranging from providing information only to the driver in a fully driver-controlled situation or estimating fully autonomous driving in a driverless vehicle or without driver control. In the example implementation herein, an autonomous steering system is used to explain the method of using fleet data and the driver assistance system. In this example and related examples, the driver assistance (DA) unit 114 has a vehicle data analysis unit 107 that analyzes sensor data to generate input conditions and generates control commands based on the input conditions to execute control over the aforementioned vehicle system. Furthermore, in this example, a performance unit 109 compares the raw measurements (also referred to as actual output parameter measurements) obtained by the DA unit 114 using control commands with estimated or expected output parameters that should be obtained using control commands, thereby generating performance measurements or errors to rate the performance of the DA unit 114.

[0050] The DA update unit 105 receives calibration correction updates from the remote fleet data adaptation computing device or server 108. The DA update unit 105 then updates the control commands or the correlation between control commands and input conditions, as also described in detail below. Such correlations and / or control command values ​​may be stored in memory 116 or storage 119.

[0051] Memory 116 can be any suitable type of memory. For example, memory 116 can include various types of dynamic random access memory (DRAM) (such as SDRAM), various types of static RAM (SRAM), and various types of non-volatile memory (PROM, EPROM, and flash memory). In some examples, memory 116 is located on and / or co-located with processor 118 on the same computer chip. In the depicted implementation, memory 116 stores the aforementioned DA program 114. Memory 116 may also include one or more databases to store data and other stored values ​​related to the driver assistance functions described herein, including input condition data, control command data, output parameter measurement data and / or performance measurement data, and corresponding system control settings, etc., and is configured as shown in Figure 2- Figure 12 The implementation described herein is explained and further described below.

[0052] The components of controller 111 may have one or more buses (not shown) to transmit programs, data, status, and other information or signals between the various components of controller 111. The bus can be any suitable physical or logical connection between the computer system and the components. This includes, but is not limited to, direct hardwired connections, fiber optics, infrared, and wireless bus technologies. During operation, DA unit 114 is stored in memory 116 and executed by processor 118.

[0053] An interface (not shown) may provide communication to and from controller 111 (e.g., from a system driver and / or another computing system) and may be implemented using any suitable method and means. In one form, the interface obtains various data from sensor array 112 and / or a navigation system. The interface may include one or more network interfaces for communicating with other systems, components, or technicians, and / or one or more storage interfaces for connecting to storage devices (such as storage device 119).

[0054] Storage device 119 can be any suitable type of storage device, including various types of direct-access storage and / or other memory devices. In one example implementation, storage device 119 includes a program product from which memory 116 can receive program 114, which executes. Figure 3 And one or more of the processes and implementations described below in conjunction with their further description. In another example implementation, the DA unit (or program product) 114 may be directly stored in the memory 116 and / or secondary storage devices (such as disks) and / or otherwise accessed thereto.

[0055] It will be understood that although this example implementation is described in the context of a full-featured computer system, the mechanisms of this disclosure can be distributed as a program product using one or more types of non-transitory computer-readable signal-bearing media used to store the program and its instructions and to perform the distribution, such as a non-transitory computer-readable medium carrying at least DA program 114 and DA update unit 105 and including computer instructions stored therein for causing a computer processor (such as processor 118) to execute and run the program. Such program products can take various forms, and this disclosure applies equally regardless of the specific type of computer-readable signal-bearing medium used to perform the distribution. Examples of signal-bearing media include recordable media such as floppy disks, hard disks, memory cards, and optical disks, and transmission media such as digital and analog communication links. It will be understood that cloud-based storage and / or other technologies may also be utilized in some implementations. Similarly, it will be understood that the computer system of controller 111 may otherwise differ from other systems. Figure 1The described implementation, for example, suggests that the computer system of controller 111 may be coupled to or may otherwise utilize one or more remote computer systems and / or other control systems.

[0056] Continue to refer to Figure 1 In various implementations, vehicle 104 and remote fleet server 108 communicate via one or more communication networks 106. In various implementations, communication network 106 may include one or more computer networks such as the Internet, and communication networks (e.g., satellite-based, cellular, and / or any number of other different types of wireless communication networks). In one example form, the transmitted data (such as vehicle performance measurements, input conditions, control commands, and output parameter measurements) and calibration corrections mentioned herein are transmitted via a 5G network using a data bandwidth of up to 10-20 Gbps. In another form, calibration corrections are sent back to the vehicle using over-the-air (OTA) broadcast.

[0057] Furthermore, in various implementations, the remote fleet server or computing device 108 is positioned remotely from at least one of the vehicles 104 (e.g., in fleet 102), but may also be remotely located from each of them. In one form, all components (units or modules) of the fleet server 108 are located in one physical location, but in other alternatives, any one or more of the components may be located remotely from each other at separate network locations. In some examples, the fleet server 108 includes one or more fleet units 120 to perform the driver assistance operations described below. Specifically, in one example form, the fleet unit 120 here has: an environment unit 122 and a vehicle motion unit 124 for collecting data on input conditions sensed or otherwise determined at the vehicles; and a vehicle data analysis unit 126 for receiving other input conditions, control commands executed in response to the input conditions, actual output parameters, and optional expected output parameters (if not already in the fleet database (tagged fleet data) 138 or other storage or memory on the fleet server). The performance unit 128 receives performance measurements (or errors) from the vehicles or uses data from the vehicle data analysis unit 126 to calculate performance measurements. The data obtained by the input condition units 122 and 124, the vehicle data analysis unit 126 and the performance unit 128 is provided to the fleet data collection unit 130, which uses the data to update the fleet database 138.

[0058] Fleet data observer unit 131 is provided to analyze data in fleet database 138 to identify when performance measurements are insufficient and should be updated to correct the identified errors. Cause identification (ID) unit 132 determines or receives which parameters have errors that are being corrected, while calibration correction unit 134 then determines the updated correlation between input conditions and control commands for the identified parameters and calculates a calibration correction or value, which is then tested or verified as explained below. After verification, fleet unit 120 provides calibration values ​​to be sent to the vehicles as software (SW) and / or firmware (FW) updates performed by SW / FW update unit 136. Adaptor generation unit 133 updates fleet database 138 via fleet data collection unit 130 to identify input conditions and control commands (also referred to as trigger data) that cause insufficient performance measurements, such that updated calibration data or values ​​can be sent to the vehicles after parameters with errors have been identified and such identification may occur after correction data (or calibration values) have been sent, for example, to the fleet. Alternatively, updated correlation data indicating the relationship between input conditions and control commands, along with calibration values, can also be stored in the fleet database. The following utilizes at least process 300 (…). Figure 3 This describes in detail the operation of fleet unit 120 using fleet data to improve driver assistance performance on vehicles 104 in fleet 102.

[0059] The fleet server 108 also includes processor circuitry forming one or more processors 140, a transceiver 142, a decryption and / or encryption unit 143, and a memory 144. The fleet server also includes a fleet database 138 for storing driver assistance-related data. In various implementations, the transceiver 142 is used to communicate with the vehicle 104, including regarding driver assistance data and its processing, and the data being transmitted can be encrypted and / or decrypted on demand.

[0060] Furthermore, in some implementations, as shown in Figure 2 below- Figure 12 The process and implementation are further described, with processor 140 having processor circuitry to process or facilitate the processing of driver assistance data from vehicle 104, including input conditions such as vehicle status, motion, environmental data, and / or performance values, and to process the generation of calibration updates to be sent back to vehicle 104 from fleet server 108. Additionally, as... Figure 1 The D / E unit 143, transceiver 142, processor 140 and memory 144 (which may include storage devices) depicted herein are similar to similar features of vehicle 104 and need not be described again here except for the operations performed by each unit or component of fleet server 108 as described below.

[0061] refer toFigures 2A-2B The differences in the calibration operation are visualized using the fleet 200 of vehicles 202. Any of the vehicles 202 performs self-calibration 204 using only onboard measurements and online data (such as climate data) to update the correlation between the input conditions, control commands, and raw measurements (also referred to as actual output parameters) to be used by the driver assistance system at the vehicle. Alternatively, fleet-based or fleet-level calibration or update 206 can occur as described herein to perform fleet data adaptation, where fleet data is collected, used to update the correlation between input conditions and control commands, and subsequently provided to multiple or all vehicles 202 in the fleet 200 with updated correction or control command values ​​(or calibration values) as described herein. Example heatmap 210 ( Figure 2B The diagram illustrates the geographic clustering of vehicles 202 of fleet 200 across region 208 (the United States is used here as an example), where vehicles across any desired region wirelessly communicate with a fleet server or computing device (such as fleet server 108). This region can be anywhere in the world or any part of the world, or even in space.

[0062] refer to Figure 3 Based on various implementations described herein, an example procedure 300 for calibrating driver assistance systems for individual vehicles using fleet-based data adaptation is provided. Procedure 300 includes operations 302 to 322 (typically numbered in even numbers) and involves data from... Figures 1-2B and Figures 4-12 Any of the systems and their sub-components (when relevant).

[0063] In the first phase of process 300, operations 302 to 310 involve data collection. The second phase of process 300 involves performance analysis at operations 312, 314, and 324, while in the third phase, operations 316 and 318 involve generating updated calibration corrections. In the fourth phase, operations 320 and 322 involve updating the calibration values ​​at the vehicle.

[0064] As a prerequisite, fleet server 108 can choose to collect data from certain vehicles in the fleet or analyze data collected from all vehicles in the fleet. First, vehicles can be grouped by vehicle type (such as SUVs or sedans) and vehicle arrangement (such as a vehicle arrangement towing a specific type of trailer, a vehicle arrangement with roof racks for carrying objects on the vehicle's roof, or, for trucks, such as pickup trucks or larger trucks, a vehicle arrangement carrying a specific type of cargo). Another category for grouping vehicles is by brand and model (including specific model years), making it highly likely that such vehicles have the same driver assistance programs being used by the vehicles. In one form, the fleet can include all vehicles of a specific model and year manufactured by a specific manufacturer. Another grouping method is to subgroup vehicles as needed by the parameters being analyzed (such as parameters related to steering control, brake pressure, throttle or accelerator pressure, cruise control, etc.) when it is known that vehicles have the same (or sufficiently similar) systems and / or the same driver assistance programs being tested, and other variations in the vehicles are found not to be problematic. As an example, when vehicle type, brand, and model are not considered, the parameter (or type of control command) can be a unique classification used to include the vehicles in the analysis. Alternatively, the fleet server can simply select (or otherwise configure to use) data from the vehicles to receive calibration updates, such that only vehicles in the analyzed group are updated. In other examples, even if a smaller subgroup of vehicles is used to calculate calibration updates, any vehicle in the fleet or vehicle group receives the updates. In some forms, vehicles in the target group are monitored, and the number monitored is much greater than the statistical conclusions required for calibration updates. Therefore, 3000 vehicles may be in the fleet and being monitored, but calibration updates only require a sample of 1500. This is one example, and many variations can be envisioned.

[0065] More specifically, for the first phase, several different types of data are collected to perform calibration updates. This includes: data related to input conditions describing the vehicle's state and / or its surrounding environment; control commands initiated and executed in response to the input conditions; and raw measurement data obtained, which may include actual output parameters and optional expected or estimated output parameters (for those parameters that may have expected values ​​already stored for a remote fleet server). Similarly, performance or error measurements are calculated at the vehicle or fleet server, but regardless of whether the fleet server performs its own performance measurement calculations, performance or error measurements can be provided from the vehicle to the fleet server.

[0066] As described above for vehicle 104, sensor unit 112 at the vehicle can be used to collect data to establish the vehicle's state and the environment surrounding the vehicle. The vehicle's state can include data about the vehicle's current motion, including driver status (whether the steering wheel is held), vehicle speed, vehicle heading (or orientation), applied current steering torque (or handwheel angle (HWA)), steering angle of the vehicle wheels, vehicle curvature and / or tilt, braking pressure and / or throttle (or accelerator) pressure, to name a few. Sensor 112 can also detect environmental conditions near the vehicle, such as road surface conditions, temperature, location and identification of objects near the vehicle via camera images, visibility, and lighting conditions. Additionally, communication via transceiver 115 can be used to collect other data via communication or computer networks to determine vehicle location and general lane conditions (such as construction) using remote applications such as GPS, and / or to determine climate, external wind speed, outdoor temperature, precipitation, humidity, lane surface conditions (dry, wet, icy, etc.), and environmental pressure using weather networks. The generated input condition data can then be stored in the vehicle's memory 116.

[0067] Process 300 includes “operating ADAS control” 306, which refers to the operation of many different driver assistance (DA) programs and is not limited to a specific level of automation. Here, in this example, the driver assistance (or aiding) unit 114 enables the vehicle data analysis unit to generate appropriate control commands using input condition data. Thus, for example, for steering, the vehicle data analysis unit 107 has a predetermined correlation or generates the correlation between one or a set of input conditions and the corresponding control command that should be applied to achieve an estimated or expected output parameter (or raw measurement). For example, after generating a set of input condition data, the vehicle data analysis unit 107 may determine that a steering torque should be applied to achieve a five-degree HWA. In this example form, it is assumed that as a result of the HWA, the vehicle data analysis unit 107 determines the expected raw measurement as a 10-degree rotation of the vehicle's front wheels. As described below, such expected raw measurements may be calculated separately by the DA unit 114, or the expected raw measurements may be predetermined in the correlation between input conditions, control commands, and expected output parameters for a specific parameter, and generated by the vehicle itself or obtained from external communications or computer networks. Such correlations can be determined by the fleet server 108 or another remote server.

[0068] The raw measurement or output parameter data can be any vehicle parameter that can be correlated (or corresponded) to, or more precisely, obtained by applying, a control command value under a specific set of input conditions, and is specific to a particular vehicle parameter such as steering or handwheel angle (HWA) or steering wheel torque. It will be understood that many different parameters can be raw measurements or output parameters, and these same parameters can also be input conditions for other parameters. It should also be understood that, in addition to the correlation between the control command and the raw measurement (or output parameter), the calibration update described herein also corrects for the correlation (or correspondence) between the input conditions and the control command. The terms “correlation” and “correlation” as used herein refer to the relationship between input conditions and the control command, and between the control command and the output parameter, and indirectly to the relationship between input conditions and the output parameter; these terms refer to causality. Therefore, depending on the type of parameter being calibrated, the calibration update can adjust the relationship between any pair of these elements (input conditions, control commands, and output parameters) or any combination of these pairs of elements.

[0069] Process 300 is primarily provided from the perspective of the fleet server, which is configured to receive input condition data from multiple remote vehicles in the fleet and is used to generate automatic control commands at the vehicles to control the vehicles. In this example, the transmission of input condition data via transceiver 115 at the vehicle can be encrypted by E / D unit 117 and using known encryption algorithms such as Advanced Encryption Standard (AES) and Transport Layer Security (TLS).

[0070] Therefore, process 300 may include "acquiring vehicle motion data" 302 and "acquiring environmental data" 304, and is used to receive input condition data from the vehicle and sent to input condition units (e.g., such as environment unit 122 and vehicle status or vehicle motion unit 124) at fleet server 108 as described above. It should be noted that environmental data received from a wireless network outside the vehicle may first be received at the vehicle for generating control commands, and then subsequently sent to environment unit 122 at fleet server. Alternatively, such external environmental data may be sent directly to fleet server when needed. Each type of input condition may have its own unit at fleet server 108 to convert the data format to the data expected at fleet database 138 and used for calibration calculations. The format of wireless transmission is not particularly limited if the wireless network used has bandwidth for reliably transmitting large amounts of data, such as 10-20 Gbps via a 5G network.

[0071] The first stage of process 300 may also include receiving other data types at the fleet server. Therefore, process 300 may include "determine performance measurement" 308, and, for example, at the vehicle, performance unit 109 may compare actual and expected output parameters (or raw and estimated measurements) to determine a performance or error measurement. Alternatively, the vehicle may send input conditions and subsequently send the actual output parameters separately or together with the expected output parameters, such that vehicle data analysis unit 126 at fleet server 108 receives the data, formats it if it is not yet in a format processed by the fleet server, and then performance unit 128 at the fleet server compares the actual and expected output parameters and calculates the performance measurement or error. In the example above where HWA is 5 degrees and the expected angle is 10 degrees, assuming the actual output parameter measurement for front wheel steering is 13 degrees, the performance measurement or error is 3 degrees.

[0072] refer to Figure 4 For an example, Figure 400 shows a set of performance measurement data, where 1 to n refer to the vehicle number or identifier of a vehicle in a monitored platoon or group of vehicles within a platoon. The horizontal axis represents time and the vertical axis represents HWA error, which can be measured in degrees. The performance errors for vehicles 1-3 are specified as 402, 404, and 406, and the performance error for vehicle n is specified as 408. The performance measurement itself is specified as... Where k is the time instance or order in which the calibration is updated over time, and v represents the vehicle, and n is as defined above. Figure 400 illustrates that each vehicle can react differently to the same or similar input conditions; in this example, this refers to steering.

[0073] The timing of the transmission of calibration data from vehicles can vary depending on the objectives of the calibration update. For example, while input condition data can be generated by the vehicle in real-time or near real-time to quickly select and execute control commands on the vehicle, calibration updates do not necessarily need to be that fast. Many calibration updates are expected to take much longer, where calibration accuracy using fleet data is a higher priority, and many parameters receiving the updated calibration will first be tested on test vehicles before the calibration update is released to consumer vehicles. Therefore, the timing for a single calibration can be measured in hours or days, rather than seconds or less. The timing can be even longer when the system will be waiting for a specific amount of data from a minimum number of vehicles in the fleet for a specific parameter (such as steering in a specific situation).

[0074] In one form, data collection is activated when certain conditions are met at the vehicle, such as when all desired data has been generated for a specific parameter or event being monitored. Once this occurs, calibration data included in a single event, comprising input conditions, command control, raw measurements (output parameters), and performance measurements for that parameter when provided from the vehicle, are uploaded from the vehicle until all desired data for that event is obtained at the fleet server. In another form, data for numerous events over a specific duration can be obtained, such as, for example, 5-10 seconds of data sampled at 10 times per second. Each event has input conditions associated with a control command, and the control command has the expected or estimated output parameter and the resulting actual output parameter.

[0075] Process 300 may include "placing fleet data in a DB" 310, which may be performed by fleet data collection unit 130 to place data in fleet database 138. This includes placing performance measurement data, input condition data, and output parameter measurement data into one or more fleet databases.

[0076] Table 1 below is an example representation of a fleet database (such as Fleet Database 138). In the first section of Table 1, labeled “Events,” the individual rows hold data on control command events, whether the event is used to control the movement of a vehicle or to perform another task, such as displaying information to a user or calculating estimated measurements of desired parameters. The collected data is then organized into columns as shown in the figure, and it is collected for individual events for the following: a specific vehicle group, such as vehicle category (brand, model, and / or year) and specific vehicle identification, input conditions, control commands used in response to those conditions, the actual output parameters obtained, the expected output parameters compared to the actual output parameters, and performance measurements as a comparison or error between the actual and expected output parameters.

[0077] Regarding vehicle categories and IDs, and using an example, a single fleet database listing all vehicle brands and models (including manufacturing years) is used, with the calibration unit selecting data only for those vehicles with specific brands and models to perform data analysis. Alternatively, separate fleet databases can be assigned to individual vehicle categories and models, or even for specific vehicles, where data from separate databases is selected, collected, and compared. This can include vehicles with trailers of any kind or particular type, or other arrangements such as roof racks carrying various objects (such as hard or soft luggage racks, canoes, kayaks, bicycles, etc.). It can also include cargo areas or cargo beds of vehicles, such as various trucks filled with various cargo objects or materials.

[0078] As mentioned above, input conditions can include many different characteristics, regardless of whether they indicate the vehicle's state (including the vehicle's motion) and the environment surrounding the vehicle. The examples in Table 1 below illustrate the vehicle's state, including vehicle speed and heading, and steering wheel angle (or handwheel angle), while environmental conditions related to the vehicle's surroundings include temperature and wind. More and / or alternative input conditions than those shown can be included.

[0079] Table 1. Team Database

[0080]

[0081]

[0082] The control command column and the columns for raw measurements and output parameters have values ​​as described above, and are for specific events with combinations of input conditions.

[0083] The second part, marked as triggered in Table 1, can be reserved for triggering data collection conditions to identify when performance measurements show insufficient (or suboptimal) performance, as explained in this paper. It will be understood that Table 1 is an example representation of a fleet database, and a fleet database can have many different field arrangements. Therefore, alternative arrangements could include first-in, first-out (FIFO) assignment of fields in the database, where labels, tags, etc., are assigned to data values, and could be field addresses with lookup indexes for labels or tags, rather than using columns and rows to assign data categories as shown in the figure. Many variations can also be envisioned.

[0084] Process 300 may include “Monitoring Fleet Data Database for Insufficient Performance” 312, where fleet data observer unit 131 monitors fleet data in fleet database 138 to identify problems related to the observer vehicle. This refers to determining whether one or more performance measurements in the fleet database are considered insufficient. In one example, when any performance measurement or error is too large and is considered insufficient or suboptimal, the correlation between input conditions and control commands, and consequently with output parameters, should be adjusted.

[0085] Performance measurements can be considered insufficient by comparing them to thresholds determined through experiments targeting specific events and vehicle parameters. Thresholds can be set when the determination error is large enough to indicate that it will affect safety or lead to a deterioration in the quality of the vehicle's user experience.

[0086] Process 300 may include “determining potential root cause IDs” 314, in which the deficient parameter has been identified by observer unit 131. Therefore, cause ID unit 132 simply places the cause identifier in fleet database 138, thereby indicating which parameter should be updated and, consequently, which control command should be updated.

[0087] Process 300 may include “performing calibration correction” 316, and this may be performed by calibration correction unit 134. Figure 1 Therefore, once performance measurements are deemed insufficient for the event, preparatory operations may include detecting the pattern between input conditions and observed errors to determine if a relationship exists that can aid in calibration updates. This includes the distribution of observed errors relative to input conditions.

[0088] refer to Figures 5-6 For example patterns or correlations (or non-correlations) accompanying performance measurements, Spectrum 500 illustrates the impact of wind on steering and trajectory control performance measurements or errors based on fleet data from more than 1500 vehicles. The vertical axis represents the lateral offset to the desired path (in meters) and from the center of the lane, compared to wind speed on the horizontal axis, with brighter grayscale shading indicating more vehicles with the same error value (more dense error counts). It will be noted that, alternatively, other performance measurements and input conditions can also be graphed. Graph 500 shows the error concentration between 5-10 mph winds and a lateral offset error of approximately 0.3 meters. It does not show a clear correlation, i.e., that the stronger the wind, the larger the error. Depending on other factors surrounding this particular event (with specific input conditions), the error may be considered insufficient, and the control command value should be adjusted to reduce it by 0.3 meters at these wind levels.

[0089] Similarly, Figure 600 shows performance measurements, where, as an example, the handwheel angle (HWA) error on the vertical axis is compared to the wind speed on the horizontal axis, and the brighter the grayscale shading, the denser the vehicle count for the error value. Consistent with Figure 500, when the HWA error is approximately 0.1 degrees, an error concentration occurs in the 5-10 mph range, making a clear correlation not apparent, and if insufficient error is found, the error should be reduced.

[0090] refer to Figures 7-9 For another example, in addition to using temperature as an input condition here, Figure 700 shows the distribution of fleet data collected for more than 1,500 vehicles, and plots the HWA error in degrees on the vertical axis compared to the temperature in degrees on the horizontal axis.

[0091] Figure 800 is a spectrum of data from Figure 700, illustrating the effect of temperature on steering control error (here, lateral deviation to the desired path (or road center)). Furthermore, Figure 900 shows the steering control error in terms of HWA error degrees compared to temperature. In both cases here, the correlation is clearer than in the wind case, where the error generally increases with increasing temperature. The data can be analyzed to determine equations that better match temperature with appropriate control commands to maintain lower HWA and lateral deviation errors. As mentioned above, fleet data can be analyzed similarly for many different types of vehicle parameters and control commands. In the fleet database, input conditions (wind or temperature) can be labeled as relevant to control commands in these cases, and consequently, to desired output parameter values.

[0092] As described above, calibration involves using data from the fleet database to update the correlation between the calibration control command and the input conditions, and subsequently generating a calibration correction based on the correlation. This correction will be used to modify or replace previous control command values ​​for certain input conditions and associated with inadequate performance measurements. In one form, these two operations can be performed simultaneously by using calibration equations that take into account the input conditions, control commands, and performance conditions. This can also include, or result in, modifying the control command or generating a new control command when the previous correlation does not yet exist and is determined by the fleet or other analyses. This is referred to as adapting the control command or fitting the control command.

[0093] More specifically, in an example correlation calibration, the update may include determining the distribution of error according to one or more input conditions, and using that distribution to determine the correspondence between control commands and actual output parameters used to determine the performance measurements associated with one or more input conditions. The correspondence between control commands and actual output parameters is then used to determine the correlation between the control commands and the input conditions. This can be achieved by using various different calibration equations. One example calibration equation (1) below relies heavily on previous calibration values, taking into account both the input conditions (or states) and the performance measurements, and is provided as follows:

[0094] c k = F k-1 c k-1 + G k-1 P k-1 + w k (1)

[0095] In this example, equation (1) is a linear discrete system model, and the fleet data is considered in all cases in equation (1) because the variable c in equation (1) k-1 F k-1 G k-1P k-1 、 and w k Each of these is a combined average or other mathematical combination of variable values ​​from multiple vehicles in the fleet. In this example, k is the current step in a series of calibration corrections for a specific control command parameter (such as steering torque or HWA), and can be considered as a time instance used to calculate the calibration correction for a specific control command executed under certain input conditions. Additionally, c... k This is a correction or calibration value, and it can be a control command value for a specific type of command, such as steering torque or HWA. Instead of a command value, c k This can be the amount or percentage changed from a previous control command value. Other variations are also conceivable. Furthermore, F... k-1 This refers to the vehicle's previous state, which includes values ​​from one or more input conditions as described above, where values ​​from multiple different input conditions can be combined into a single-state factor value. Furthermore, c k-1 It is the current calibration value being adjusted, G k-1 It is the previous value of the learning gain, or in other words, as an example, the inverse of the function describing the effect of calibration on performance. P k-1 This is a previous performance measurement, while w k It is process noise, which refers to any noise from deterministic closed-loop changes, or in other words, based on an uncertainty model.

[0096] As a result, the calibration value (or modified value) c k This can then be used to provide control commands for updating the vehicle. In one form, a separate calibration value can be provided. In another form, a calibration value c can be provided. k The range is correspondingly related to the range of states (or input conditions) for a specific control command (such as the range for the handwheel angle). Control commands can be provided at intervals such as every 1 / 2 degree, and vehicles can be configured to interpolate control commands between calibration values ​​provided by the fleet server. Many variations can also be used alternatively.

[0097] It will also be understood that, instead of the calibration equation (1) used above, other equations, algorithms, or models can be used, including those using machine learning, such as neural networks, hidden Markov models, filtering models, regression or classification models, etc. Furthermore, each machine learning model can be trained using fleet data collected from vehicles with events for which parameters are being updated.

[0098] refer to Figures 10-12This provides another example to illustrate the performance improvements achieved by using fleet data. Vehicle scenario 1000 shows a vehicle 1002 that may be towing a trailer (not shown) and a target ground-based vehicle path 1004. Updated route (shown as dashed lines) 1006 shows the calculated path determined by using a calibration update based on fleet data as described herein, while unupdated route (shown as dashed lines) 1008 shows the path generated without the disclosed methods and systems. The parameter analyzed is the yaw rate error, where Wz (before correction) indicates the error before using this method, and Wz (after correction) indicates the error when this method considering fleet data is applied. It can be seen that updated route 1006 is closer to ground-based route 1004 than unupdated route 1008.

[0099] Figure 1100 illustrates several example calibration updates performed on vehicle 1002 over time according to this calibration update method and using fleet data. Figure 1100 shows the performance of the calibration updates, where the error initially increases and then decreases after time point zero. Note that the Wz error is shown as a negative value in Figures 1100 and 1200. The yaw rate error Wz for vehicle 1002 is measured using an inertial measurement unit (IMU).

[0100] Chart 1200 compares the calibrated and updated yaw rate error curve 1202 with the unupdated yaw rate error curve 1204 for vehicle 1002 over a short time period, which can be considered a single event with a time range recorded in the fleet database. Therefore, Chart 1200 shows the current vehicle situation over time, where the updated and calibrated Wz error 1202 has a significant reduction 1206 in model error compared to the unupdated Wz error 1204. This example shows a 67% reduction in yaw rate error.

[0101] With one option at this time, the updated calibration values, and consequently the data relating the updated control commands to the input conditions, can be placed in the fleet database 138 when needed. Therefore, this can include placing the calibration values ​​solely in the fleet database, either in a separate section, or tagging them to an event with corresponding input conditions and which may or may not have insufficient performance now corrected by the calibration values, or placing them together with that event.

[0102] Returning to process 300, process 300 may include “test calibration correction” 318. Subsequently, by an option, the method includes testing the calibration correction on a test vehicle before sending the calibration correction to the fleet. This may be performed on a golden vehicle and carried out or authorized by the manufacturing company or other company that controls such calibration updates. This is typically not a vehicle already owned by the consumer, allowing for careful and secure control of the testing.

[0103] Once validation is achieved on the test vehicle, process 300 may include "providing calibration correction update" 320 to send calibration correction to a remote vehicle, and this may be accomplished by SW / FW update unit 136. Figure 1 This is performed as described above. The transmission can be a broadcast only to those vehicles in the fleet that are grouped together and provided with data for calibration updates; these vehicles can typically be grouped by brand, model, and year. Alternatively, any vehicle with the same brand, model, and year can receive the broadcast for calibration updates. Therefore, vehicles can still receive calibration updates or corrections regardless of whether they have experienced inadequate performance measurements or errors. Additionally, vehicles can receive calibration updates with the same DA procedure. As an example, calibration updates are provided when it is known that changes in vehicle type and / or model are not otherwise related to the specific non-critical calibration values ​​being updated (e.g., for estimates such as those used for displays, audio systems, and / or onboard data analysis, such as those used for vehicle satellite type position estimation).

[0104] Process 300 may include "updating (multiple) calibration values ​​at the vehicle fleet" 322. This involves receiving calibration corrections at the vehicle by broadcasting calibration corrections to multiple vehicles in the fleet, although individual vehicles may be updated as needed. This broadcast may be an over-the-air (OTA) broadcast. For broadcasting, 5G wireless or mobile networks may be used, or other such networks may be used to reliably broadcast calibration data to the fleet of vehicles equipped with transceivers and other devices, such as antennas for good quality transmission.

[0105] Receiving calibration corrections at the vehicle location can include receiving multiple calibration corrections for multiple different types of control commands. Furthermore, calibration corrections can be software or firmware updates for driver assistance programs or units (such as ADAS) on a remote vehicle. Therefore, the vehicle DA update unit 105 ( Figure 1The system can receive calibration update data and can replace the input conditions of vehicle parameters with control command values ​​or settings (or ranges of control command values ​​or settings) in the control command table or formula. This can also include adapting modified previously used control commands or new control commands that have not yet been used. The calibration update data can be placed in the vehicle and stored in memory 116 or storage 119 to store the control command values. The vehicle data analysis unit 107 of the driver assistance (DA) unit 114 will then retrieve those updated values ​​from the memory or storage, or use those updated values ​​to calculate the control command settings. The ADAS or DA unit 114 can then operate 306 to generate new control commands based on fleet data.

[0106] In this example, process 300 may include an "adaptation trigger data collection condition" 324 performed by the adapt generation unit 133. This operation involves storing data that triggers the determination of insufficient performance in the fleet database 138. In the example shown, separate sections or indexes may be provided for events that lead to insufficient performance. Alternatively, events in the event section of the fleet database may be tagged as having insufficient performance measurements. Events with insufficient performance may identify outdated correlations between one or more input conditions and control commands, as well as the resulting output parameters that led to the insufficient performance measurement. Updating the fleet database with trigger data may be performed each time an insufficient performance is determined, and this may include each of multiple events for a single related insufficient determination. For example, steering error using 10 seconds of data (10 samples per second) from 100 events may have insufficient flags or labels for all 100 events. Alternatively, a single event may be recorded as an insufficient trigger event representing the entire 10 seconds. Other variations may also be used alternatively.

[0107] While at least one example implementation has been presented in the foregoing detailed description, it should be understood that numerous variations exist. It should also be understood that the example implementations are not intended to limit the scope, applicability, or configuration of this disclosure in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient roadmap for implementing the example implementations. It should be understood that various changes can be made to the function and arrangement of the elements without departing from the scope of this disclosure as set forth in the appended claims and their legal equivalents.

Claims

1. A method comprising: Receives input condition data from multiple remote vehicles in a fleet and is used to generate automatic control commands at said vehicles to control said vehicles; Receive actual output parameter measurement data from the remote vehicle obtained using the automatic control commands; Receive or generate performance measurement data that depends at least in part on the difference between the actual output parameter measurement data and the expected output parameter measurement data; The performance measurement data, the input condition data, and the output parameter measurement data are placed into one or more fleet databases; Determine whether one or more performance measurements in the fleet database are considered insufficient; Use the data from the fleet database to update the correlation between calibration control commands and input conditions; Adapt one or more control commands related to the update; Generate calibration corrections based on the correlation and which will be used to change or replace previous control command values ​​associated with inadequate performance measurements; as well as Send the calibration correction or one or more control commands, or both, to the remote vehicle.

2. The method of claim 1, wherein the performance measurement is generated at the vehicle.

3. The method of claim 1, wherein the performance measurement is generated remotely from the vehicle.

4. The method of claim 1, wherein the calibration correction is part of a software or firmware update of the driver assistance program on the remote vehicle.

5. The method of claim 1, wherein the updating and generation includes using a calibration equation that takes into account one or more input conditions, one or more control commands, and a fleet-based version of one or more performance measurements.

6. The method of claim 1, wherein the update includes determining a distribution of error according to one or more input conditions, using the distribution to determine a correspondence between a control command and an actual output parameter for determining the performance measurement associated with one or more input conditions, and using the correspondence between the control command and the actual output parameter to determine the correlation between the control command and the input conditions.

7. The method of claim 1, further comprising updating the fleet database using updated control command and input condition correlation data.

8. The method of claim 1, further comprising updating the fleet database with an indication of which events trigger insufficient performance measurements, wherein the events include corresponding input conditions, control commands, and output parameter measurements.

9. A vehicle comprising: One or more controllers, including: Memory; Processor circuitry, the processor circuitry forming one or more processors communicatively coupled to the memory; and A driving assistance unit, operated by one or more processors, the processors being configured to operate in the following manner: Generate input condition data for generating automatic control commands at the vehicle to control the vehicle. Generate output parameter measurement data obtained using the automatic control commands. The performance measurement data is generated, which depends at least in part on the difference between the actual output parameter measurement data and the expected output parameter measurement data of the automatic control command. The system sends the performance measurement data, the input condition data, and the actual output parameter measurement data to the fleet data adaptation computing device. The fleet data adaptation computing device receives transmissions from multiple remote vehicles in the fleet and places the performance measurement, input condition, and actual output parameter measurement data into the fleet database. The system receives calibration corrections over the air (OTA) from the fleet data adaptation computing device, which generates the calibration corrections by: determining whether performance measurements in the fleet database are considered insufficient; using the data in the fleet database to determine the correlation between updated calibration control commands and input conditions; and generating the calibration corrections based on the correlation. The previously insufficient control command values ​​at the vehicle are replaced or modified by using the calibration correction.

10. The vehicle of claim 9, wherein the receipt of the calibration correction is part of a broadcast of the calibration correction to a plurality of vehicles in the fleet.

Images