Vehicle control device and software updating system

Abstract

The present invention addresses the problem of identifying software defects and environmental changes that may lead to hazards in the future, and improving software so as to prevent such hazards. The present invention provides a vehicle control device 2 comprising a memory (1002) in which programs including a vehicle control program and a safety evaluation program are stored, and a processor (1001) that executes the programs, characterized in that the processor: executes the vehicle control program to determine a vehicle control command value from input information acquired by a sensor (21); executes the safety evaluation program to evaluate the safety of vehicle control based on the control command value; and determines, on the basis of the safety evaluation results, whether or not at least one of the vehicle control program and the safety evaluation program needs to be redesigned.

Description

Vehicle control device and software update system

[0001] The present invention relates to a vehicle control device mounted on a vehicle or the like, and a software update system for updating software included in the vehicle control device.

[0002] As background art in this technical field, there is Japanese Patent Application Laid-Open No. 2022-179940 (Patent Document 1). Patent Document 1 has an issue of "appropriately suppressing or deterring functions against changes in control safety over time", and as a solution, "an electronic control device that controls a vehicle with embedded software, a control amount calculation unit that calculates a control amount of the vehicle, and a control amount that suppresses or deters the function of the vehicle based on the control amount calculated by the control amount calculation unit. The countermeasure unit for elapsed time includes elapsed information including information on the operation time of the electronic control device, diagnoses the severity with respect to safety based on the result of the determination, and determines a control amount for suppressing or deterring the function of the vehicle based on the diagnosed severity."

[0003] Japanese Patent Application Laid-Open No. 2022-179940

[0004] In the electronic control device described in Patent Document 1, in response to changes in vehicle control safety over time, the safety of control is evaluated based on the operation time of the electronic control device, and the function of the vehicle is suppressed or deterred according to the result to ensure safety. This enables countermeasures against changes over time in system quality such as deterioration of system component parts, rattling of combined parts, and software security vulnerabilities.

[0005] However, in autonomous driving and vehicle control using ADAS (Advanced Driver-Assistance Systems), in addition to the changes over time mentioned above, software defects that cause unexpected behavior due to integration with other software when applying updated software components to the system, and changes in the driving environment that were not anticipated during the software design, can reduce the safety of the control. If these software defects or environmental changes cause dangerous vehicle behavior, it can lead to hazards that cause harm to people and the environment. In order to continuously ensure the safety of autonomous driving and ADAS, it is necessary to identify software defects and environmental changes that can lead to the hazards mentioned above and improve the software to prevent dangerous vehicle behavior.

[0006] The present invention aims to address the above-mentioned problems by identifying software defects and environmental changes that could lead to future hazards and improving the software to prevent such hazards.

[0007] To solve the above problems, the present invention provides a vehicle control device comprising: a memory storing a program including a vehicle control program and a safety evaluation program; and a processor that executes the program, wherein the processor determines a vehicle control command value from input information acquired by a sensor by executing the vehicle control program; evaluates the safety of vehicle control based on the control command value by executing the safety evaluation program; and determines whether or not to redesign at least one of the vehicle control program or the safety evaluation program according to the safety evaluation result.

[0008] According to the present invention, by quantitatively evaluating the safety of the control software output while driving, it becomes possible to detect hazard factors such as software malfunctions and environmental changes that may cause dangerous vehicle behavior in the future, and to improve the software.

[0009] This figure shows the overall structure of the software update system in the first to third embodiments of the present invention. This figure shows the configuration of the software update system in the first embodiment of the present invention. This figure shows an example of a risk model in the first embodiment of the present invention. This figure shows an example of criteria for determining whether safety control and redesign are necessary according to the risk value in the first embodiment of the present invention. This is a processing flow diagram in the first embodiment of the present invention. This figure shows the configuration of the software update system in the second embodiment of the present invention. This is a processing flow diagram in the second embodiment of the present invention. This figure shows the configuration of the software update system in the third embodiment of the present invention. This is a processing flow diagram in the third embodiment of the present invention. This figure shows an example of the configuration of an autonomous driving ECU. This figure shows an example of the configuration of a server.

[0010] Embodiments of the present invention will be described below with reference to the drawings.

[0011] Figure 1 shows an overall view of the software update system in the first to third embodiments of the present invention. The vehicle 1 and server 13 of the software update system 100 are configured to communicate information bidirectionally, for example, via a wireless communication network or a wired connection. The vehicle 1 is equipped with multiple ECUs (Electronic Control Units) as vehicle control devices, depending on the application. These multiple ECUs are connected to each other via an in-vehicle network such as a CAN (Controller Area Network) to enable communication. The autonomous driving ECU 2 includes a memory that stores a program including a vehicle control program and a processor that executes the program. The server 13 includes a memory that stores a program including a software update program and a processor that executes the program in the memory.

[0012] In the autonomous driving ECU 2, control software 5 is executed to determine control command values ​​for vehicle 1 based on information acquired from sensors such as radar 3 and camera 4, and other information acquisition devices. The control command values ​​determined by the control software 5 are output to the powertrain ECU 9, steering ECU 10, and brake ECU 11, which control actuators such as the engine / motor 6, steering 7, and brakes 8, respectively. The communication ECU 12 communicates with a server 13 outside the vehicle and with other vehicles to acquire information such as location information and traffic conditions. The communication ECU 12 also communicates with a software update device 14 on the server 13 via communication equipment to update the software of each ECU.

[0013] [Example 1] Figure 2 shows the configuration of a software update system according to the first embodiment of the present invention. Each part of the autonomous driving ECU 2 represents a function realized by executing the control software 5 stored in ROM by the CPU. In this embodiment, the control software 5 has a vehicle control program and a safety evaluation program. The autonomous driving ECU 2 realizes various functions of the vehicle control unit 20, risk evaluation unit 23, redesign necessity determination unit 24, output unit 25, safety control unit 26, and recognition reliability acquisition unit 27 by executing the control software 5.

[0014] The vehicle control unit 20 determines control command values ​​for vehicle 1 from input information acquired by sensors 21 by executing the vehicle control program of the control software 5. Specifically, it determines the control of vehicle 1 based on input information acquired from sensors 21 such as radar 3 and camera 4, and outputs control command values ​​for controlling actuators 22 such as steering 7 and brakes 8. In addition to external information acquired by external sensors such as radar 3 and camera 4 installed on vehicle 1, the vehicle's control status, driver status, external communication status, and information acquired through communication may also be used as input information for determining the control command values ​​for vehicle 1.

[0015] The risk assessment unit 23 evaluates the safety of the control of vehicle 1 based on control command values ​​by executing the safety evaluation program of the control software 5. The risk assessment unit 23 quantitatively evaluates the safety of the vehicle control by the vehicle control unit 20 as a risk value. As input at this time, the information used by the vehicle control unit 20 to decide on the control of vehicle 1 and the control command values ​​output by the vehicle control unit 20 are used. As an example of a risk model for calculating the risk value, the distance to pedestrians, other vehicles, lanes, and obstacles, and the collision margin (Time-To-Collision) calculated from the vehicle speed and the speed of other vehicles can be used. It is also possible to use a model such as a neural network that outputs safety evaluation values ​​from time-series data of vehicle operation and external information, which has been trained by evaluating and labeling the safety of vehicle control and camera image data during actual driving and using this as training data. In addition, it is also possible to construct a risk model that models the causal relationship and probability of occurrence leading to the occurrence of accidents and near misses, and outputs a risk value based on the probability of occurrence of accidents and near misses and the degree of harm, and use it for risk evaluation.

[0016] Figure 3 shows an example of a risk model constructed based on the causal relationship leading up to a collision with a vehicle ahead. The final node, "Probability of Collision with Vehicle Ahead" 31, outputs the probability of a collision with a vehicle ahead, which is a hazard, as a risk value, based on the outputs of the previous nodes, "Vehicle Speed" 32 and "Vehicle Speed ​​Ahead" 33. The "Vehicle Speed ​​Ahead" node 32 outputs the vehicle's current speed based on the control command value determined by the vehicle control unit 20. The "Vehicle Speed ​​Ahead" node 33 outputs a predicted value of the vehicle's speed, predicted based on the output of the previous node. The "Current Speed" node 34 outputs the vehicle's speed obtained by sensors, etc. The "Acceleration / Deceleration Possibility" node 35 outputs a prediction of the vehicle's acceleration / deceleration, predicted based on the output of the previous node. In addition to outputting the predicted acceleration value, the "Acceleration / Deceleration Possibility" node 35 may output the degree of acceleration / deceleration divided into multiple levels, with the possibility of each level output. For example, conditions such as "acceleration," "maintaining speed," "deceleration (deceleration of less than 10 km / h within 3 seconds)," "rapid deceleration (deceleration of 10-30 km / h within 3 seconds)," and "sudden stop" can be set, and the probability of each occurring can be output as the predicted action of the vehicle in front. As described above, based on the causal relationships leading up to the hazard, it is possible to predict the state and probability of occurrence of each node in order from the events actually observed, and output the calculated probability of the hazard occurring as a risk value. The output from the risk model may take into account not only the probability of the hazard occurring, but also the degree and target of the resulting harm (personal injury or death, or property loss).

[0017] The redesign necessity determination unit 24 determines whether redesign is necessary for at least one of the vehicle control program or the safety evaluation program, based on the safety evaluation results. Based on the risk values ​​output by the risk evaluation unit 23, the redesign necessity determination unit 24 determines whether it is necessary to modify or update (redesign) the design of the control software (vehicle control program) that constitutes the vehicle control unit 20, or the risk model (safety evaluation program) used for risk evaluation in the risk evaluation unit 23. For example, if the risk value exceeds a predetermined threshold, or if the rate of change of the risk value over time exceeds a certain level, it is determined that the safety of the vehicle control is insufficient, or that the risk evaluation by the risk model is inappropriate, and it is determined that redesign of at least one of the control software or the risk model is necessary. The thresholds for the risk value and rate of change can be the average values ​​from tests conducted in advance.

[0018] The output unit 25 outputs a redesign request to the software update device 14 on the external server 13 if the redesign necessity determination unit 24 determines that redesign is necessary. When outputting the redesign request, the output unit 25 adds the output information of the control command values ​​used by the risk assessment unit 23 and the basis information for the safety assessment.

[0019] With the above configuration, it becomes possible to quantitatively evaluate the safety of vehicle control in real time and request redesign of the control software or risk model if a high risk is identified. This makes it possible to detect dangerous behavior of the control software or risk factors that were not anticipated during the design phase before a hazard actually occurs.

[0020] The safety control unit 26 determines the control to ensure the safety of the vehicle 1 based on the safety evaluation results, specifically the risk evaluation results from the risk evaluation unit 23. The safety control unit 26 determines the control to ensure safety based on the risk value output by the risk evaluation unit 23 and outputs a control command value. This makes it possible to ensure safety in real time without waiting for design improvements if a high risk is determined during driving.

[0021] Figure 4 shows examples of criteria for determining whether safety control and redesign are necessary based on risk values. For example, assuming a risk value range of 0 to 1, in low-risk scenarios (less than 0.5), the danger is judged to be low, and the safety control to ensure safety is not changed, nor is redesign of the control software or risk model required. When the risk value is moderate (0.5 to 0.7), a certain level of danger is judged to exist, and deceleration control is implemented to ensure safety. However, it is judged that there is no danger that would immediately require redesign of the control software or risk model, and redesign is not required. When the risk value is high (0.7 to 0.9), deceleration control is implemented to ensure safety, and redesign of the control software and risk model is deemed necessary. When the risk value is very high (0.9 or higher), an imminent danger is judged to exist, and emergency stop control is implemented, along with a request for redesign of the control software and risk model. As described above, by setting safety controls and redesign requirements separately according to the risk value, low-risk situations can be handled solely with real-time safety controls, while high-risk situations can be addressed by ensuring real-time safety through safety controls, and by redesigning the control software and risk model to prevent similar incidents from occurring in the future.

[0022] The recognition reliability acquisition unit 27 acquires an index indicating the reliability of the recognition result, that is, how reliable the accuracy of the recognition is, regarding the external environment recognition in the vehicle control unit 20. For example, in the case of object recognition, the prediction probability of the class predicted with the highest probability can be used as the reliability. The reliability acquired by the recognition reliability acquisition unit 27 is input to the risk evaluation unit 23. The risk evaluation unit 23 evaluates safety based on the recognition reliability. In the risk evaluation unit 23, if the recognition reliability is low, it is determined to be high risk, making it possible to determine and detect scenes in which the accuracy of external environment recognition has decreased as high risk. As a result, when an unknown object or environment appears that was not anticipated during the initial design, cannot be properly recognized by the external environment recognition function, and whose existence was not considered in the risk model, it is possible to determine that a redesign of the control software and risk model is necessary.

[0023] The various parts of the software update device 14 shown in Figure 2 represent functions that are realized by the execution of software stored in ROM by the CPU of the server 13. The software update device 14 realizes the various functions of the risk factor identification unit 28 and the redesign unit 29 by executing software.

[0024] The risk factor identification unit 28 analyzes the cause of the high-risk determination when a redesign request is output from the output unit 25 of the autonomous driving ECU 2. At this time, the basis for the risk assessment by the risk assessment unit 23 can be used in the analysis. For example, in the case of risk assessment using the risk model 30 based on causal relationships shown in Figure 3, the output of the node that contributes to the increase in the risk value can be extracted as a risk factor. This makes it possible to streamline the analysis of the cause of the high-risk determination. Furthermore, for the extracted risk factors, the unit analyzes why those risk factors were judged to be high-risk. If the safety of the output of the vehicle control unit 20 for the risk factor is insufficient, the control software needs to be modified. If the risk assessment for the risk factor is inappropriate, the risk model needs to be modified.

[0025] The redesign unit 29 modifies the control software or risk model based on the redesign request from the autonomous driving ECU 2 and the risk factor analysis results from the risk factor identification unit 28. The modification of the control software or risk model may be done using a machine learning model, or the redesign unit 29 may be configured to acquire the redesigned control software or risk model by an engineer. The modified control software or risk model modified by the redesign unit 29 is transmitted from the server 13 to the autonomous driving ECU 2 of the vehicle 1 and used in the autonomous driving ECU 2 to update the program. The vehicle 1 that receives the modified control software or risk model from the server 13 may include not only the vehicle 1 that sent the redesign request to the server 13, but also other vehicles that meet predetermined conditions, such as being the same model as vehicle 1.

[0026] Figure 5 shows a flowchart of the process according to the first embodiment. In step 101, the recognition reliability acquisition unit 27 acquires the reliability of the external environment recognition function included in the vehicle control unit 20. In step 102, the risk evaluation unit 23 calculates a risk value using the risk model 30 based on the content of the vehicle control instructions from the vehicle control unit 20 and the reliability of the external environment recognition function. In step 103, the redesign necessity determination unit 24 determines whether the risk value is above the threshold for executing control to ensure safety. In step 104, the safety control unit 26 outputs a control instruction to ensure safety. In step 105, the redesign necessity determination unit 24 determines whether the risk value is above the threshold for implementing redesign. In step 106, the output unit 25 outputs a request for redesign. In step 107, the risk factor identification unit 28 identifies the risk factors that affected the risk value. In step 108, the redesign unit 29 redesigns the control software or risk model included in the vehicle control unit 20 according to the identified risk factors.

[0027] According to the first embodiment described above, by determining whether or not software redesign is necessary based on the results of the risk assessment, it is possible to appropriately respond to malfunctions caused by integration with other software and changes in the driving environment that were not anticipated during the design phase. The autonomous driving ECU 2 quantitatively evaluates the safety of the output of the vehicle's control software while driving, and if it is determined to be high risk, it implements control to ensure safety and requests improvements to the control software, thereby enabling the identification and countermeasures of hazard factors before they lead to dangerous vehicle behavior. By requesting a revision of the risk model, vehicle 1 can receive a risk model that takes new risk factors into account from server 13, enabling appropriate risk assessment for the new risk factors and allowing for the anticipation of risks that were not anticipated. Furthermore, by analyzing risk factors using the processing results of the risk assessment, the analysis man-hours are reduced and software improvement is made more efficient.

[0028] [Example 2] Figure 6 shows the configuration of a software update system according to a second embodiment of the present invention.

[0029] The autonomous driving ECU 2 has various functions, including control software 40, a risk assessment unit 41, a data acquisition unit 42, and an output unit 43. These various functions are realized by the processor executing dedicated software stored in memory.

[0030] The control software 40 is executed in the background on the autonomous driving ECU 2 for operational verification, separate from normal autonomous driving control. The control software 40 performs calculation processing in the background to determine the control command value of the vehicle 1 in response to input information acquired by sensors 21, etc. The risk evaluation unit 41 evaluates the safety of vehicle control by the control command value based on the input information and the background execution results of the control function. The risk evaluation unit 41 evaluates the safety of control by the control software 40 as a risk value based on the execution results of the control software 40 and the information input to the control software 40 from sensors 21. The risk evaluation unit 41 may also evaluate safety by considering the recognition reliability of the input information of the recognition reliability acquisition unit 27 in the first embodiment.

[0031] The data acquisition unit 42 collects input information and output information of control command values ​​according to the safety evaluation results. The data acquisition unit 42 collects input information and output information of control command values ​​triggered by the timing when it is determined that the risk value indicating the safety evaluation results is above a threshold. In other words, if the evaluation result by the risk evaluation unit 41 is high risk, the data acquisition unit 42 uses this as a trigger to collect the execution results (output information of control command values) and input information of the control software 40 in the scene determined to be high risk and before and after it. Operational information of the control function that is actually responsible for controlling the vehicle 1 may also be collected as data for comparison.

[0032] The output unit 43 outputs the data collected by the data acquisition unit 42 and the risk assessment results from the risk assessment unit 41 to the external software update device 14.

[0033] The risk factor identification unit 28 of the software update device 14 identifies the risk factors that caused the high-risk determination based on the acquired data and risk assessment results. The redesign unit 29 redesigns at least one of the control software 40 or the risk model 30 to correspond to the risk factors identified by the risk factor identification unit 28 and improves the program.

[0034] Figure 7 shows a flowchart of the process according to the second embodiment. In step 201, the risk assessment unit 41 of the autonomous driving ECU 2 calculates a risk value using the risk model 30 with respect to the control output of the control software 40 executed in the background. In step 202, it is determined whether the risk value is above a threshold. In step 203, the data collection unit 42 collects execution data of the control software 40 in scenes where the risk value is above a threshold. In step 204, the output unit 43 uploads the collected data to the server 13. In step 205, the risk factor identification unit 28 of the server 13 identifies the risk factors that affected the risk value from the uploaded execution data. In step 206, the redesign unit 29 redesigns the control software 40 or the risk model 30 according to the identified risk factors.

[0035] According to the second embodiment described above, the safety of the output of control software executed in the background for the purpose of verifying operation can be quantitatively evaluated in real time, and data can be collected using the timing determined to be high risk as a trigger. This makes it possible to collect only the data necessary for software improvement aimed at improving safety. As a result, the amount of data uploaded from the autonomous driving ECU 2 to the server 13 can be reduced. Furthermore, by linking the collected data with the results of identifying risk factors based on the risk evaluation processing content, it becomes possible to efficiently extract the data necessary for redesign from the data.

[0036] [Example 3] Figure 8 shows the configuration of a software update system according to a third embodiment of the present invention. The autonomous driving ECU 2 has various functions including a vehicle control unit 20, a data acquisition unit 50, and an output unit 51. The software update device 14 has various functions including a risk assessment unit 52, a redesign necessity determination unit 24, a risk factor identification unit 28, a data acquisition request unit 53, and a redesign unit 29. The various functions in the autonomous driving ECU 2 and the software update device 14 are realized by a processor executing dedicated software stored in memory.

[0037] The vehicle control unit 20 determines the control of the vehicle 1 based on input information from sensors 21 and the like, and outputs control commands to the actuators 22. The data acquisition unit 50 collects the input information used for vehicle control and the control command values ​​output from the vehicle control unit 20. The output unit 51 uploads the data collected by the data acquisition unit 50 to the software update device 14.

[0038] The risk assessment unit 52 of the software update device 14 evaluates the safety of the control of the vehicle 1 by the vehicle control unit 20 as a risk value with respect to uploaded input information and data such as control command values. The risk assessment unit 52 may also calculate the risk value using the risk model 30 based on the content of the vehicle control instructions from the vehicle control unit 20 and the recognition reliability of the external environment recognition function by the sensor 21. The redesign necessity determination unit 24 determines whether or not to redesign the control software or risk model based on the risk assessment result from the risk assessment unit 52. The risk factor identification unit 28 identifies risk factors using the processing content of the risk assessment unit 52. The redesign unit 29 redesigns the control software or risk model to correspond to the risk factors identified by the risk factor identification unit 28.

[0039] With the above configuration, it becomes possible to quantitatively evaluate the safety of vehicle control by the control software based on driving data collected by the autonomous driving ECU, and to identify and improve risk factors for software operations that are evaluated as high risk. This makes it possible to identify the causes and take countermeasures for dangerous software operations that may not have clearly manifested as dangerous vehicle behavior but could lead to hazards in the future.

[0040] The data collection request unit 53 requests the autonomous driving ECU 2 to collect additional data necessary for countermeasures regarding the risk factors identified by the risk factor identification unit 28. For example, if a combination of environmental conditions (e.g., dense fog at night) is identified as a risk factor, the unit requests the autonomous driving ECU to collect vehicle data at the time that environmental condition occurs. This allows the system to obtain additional information about the circumstances under which the risk factor occurred, which can then be used to improve the software.

[0041] Figure 9 shows a flowchart of the process according to the third embodiment. In step 301, the data acquisition unit 50 collects vehicle control data (control command values) from the vehicle control unit 20. In step 302, the collected vehicle control data is uploaded from the output unit 51 to the software update device 14 of the server 13. In step 303, the risk assessment unit 52 calculates a risk value using the risk model 30 with respect to the collected vehicle control data. In step 304, the redesign necessity determination unit 24 determines whether the risk value is above a threshold. In step 305, the risk factor identification unit 28 identifies the risk factors that influenced the risk value. In step 306, the redesign unit 29 redesigns at least one of the control software or risk model constituting the vehicle control unit 20 according to the identified risk factors. In step 307, the data acquisition request unit 53 requests the autonomous driving ECU 2 to collect vehicle control data related to the identified risk factors.

[0042] According to the third embodiment described above, for the operation data of the control software collected during driving, the safety of vehicle control is quantitatively evaluated. In the case of high risk, by improving the design, it is possible to identify and improve the risk factors of software operations that may lead to future hazards. Also, by requesting the collection of vehicle data related to the identified risk factors, it is possible to efficiently collect data effective for software improvement.

[0043] FIG. 10 is a diagram showing a configuration example of the automatic driving ECU. In the automatic driving ECU 2, a processor 1001 such as a CPU, a memory 1002 such as a RAM (Random Access Memory), a storage 1003 such as an SSD (Solid State Drive) or an HDD (Hard Disk Drive), and a network I / F (Inter / Interface) 1004 are connected via a bus.

[0044] FIG. 11 is a diagram showing a configuration example of the server. In the server 13, a processor 1101 such as a CPU, a memory 1102 such as a RAM (Random Access Memory), a storage 1103 such as an SSD (Solid State Drive) or an HDD (Hard Disk Drive), and a network I / F (Inter / Interface) 1104 are connected via a bus.

[0045] The present invention is not limited to the embodiments described above and includes various modifications. The above embodiments are described as examples of the present invention and are not necessarily limited to those having all the configurations described.

[0046] 1: Vehicle, 2: Autonomous driving ECU (Vehicle Control Unit), 3: Radar, 4: Camera, 5: Control software, 6: Engine / motor, 7: Steering, 8: Brakes, 9: Powertrain ECU, 10: Steering ECU, 11: Brake ECU, 12: Communication ECU, 13: Server, 14: Software update device, 20: Vehicle control unit, 21: Sensor, 22: Actuator, 23: Risk assessment unit for evaluating the safety of the vehicle control unit, 24: Redesign necessity determination unit, 25: Redesign necessity output unit, 26: Safety control unit, 27: Recognition reliability acquisition unit, 28: Risk factor identification unit, 29: Redesign unit, 30: Based on causal relationships 31-35: Risk model nodes, 40: Control software to be verified, 41: Risk assessment unit for evaluating the safety of the control software, 42: Data collection unit for background execution, 43: Output unit for collected background execution data, 50: Data collection unit for vehicle data during operation, 51: Output unit for collected data, 52: Risk assessment unit for collected data, 53: Data collection request unit, 100: Software update system, 101-108: Processing in the first embodiment, 201-206: Processing in the second embodiment, 301-307: Processing in the third embodiment

Claims

1. A vehicle control device comprising a memory storing a program including a vehicle control program and a safety evaluation program, and a processor that executes the program, wherein the processor determines a vehicle control command value from input information acquired by a sensor by executing the vehicle control program, evaluates the safety of vehicle control based on the control command value by executing the safety evaluation program, and determines whether or not to redesign at least one of the vehicle control program or the safety evaluation program according to the safety evaluation result.

2. A vehicle control device according to claim 1, wherein the processor determines control to ensure the safety of the vehicle based on the safety evaluation result.

3. A vehicle control device according to claim 1 or claim 2, wherein the processor evaluates the safety based on the recognition reliability of the input information.

4. A software update system comprising a vehicle control device and a server, wherein the vehicle control device has a memory storing a program including a vehicle control program and a safety evaluation program, and a processor that executes the program in the memory; the server has a memory storing a program including a software update program, and a processor that executes the program in the memory; the processor of the vehicle control device determines a vehicle control command value from input information acquired by a sensor by executing the vehicle control program; evaluates the safety of vehicle control based on the control command value by executing the safety evaluation program; determines whether or not to redesign at least one of the vehicle control program or the safety evaluation program according to the safety evaluation result; outputs a request for redesign to the server if it is determined that redesign is necessary; and the processor of the server, upon receiving a request for redesign from the vehicle control device by executing the software update program, identifies risk factors in vehicle control using the output information of the control command value and the basis information for the safety evaluation, and redesigns at least one of the vehicle control program or the safety evaluation program according to the identified risk factors.

5. A software update system according to claim 4, wherein the processor of the vehicle control device determines a control to ensure the safety of the vehicle based on the safety evaluation result.

6. A software update system according to claim 5, wherein the processor of the vehicle control device outputs a control command value for ensuring safety when the risk value indicating the safety evaluation result is equal to or greater than a threshold for implementing safety control, and outputs a request for redesign to the server when the risk value is equal to or greater than a threshold for implementing redesign.

7. A software update system comprising a vehicle control device and a server, wherein the vehicle control device has a memory storing a program including a vehicle control program and a safety evaluation program, and a processor that executes the program in the memory; the server has a memory storing a program including a software update program, and a processor that executes the program in the memory; the processor of the vehicle control device performs a calculation process in the background to determine a vehicle control command value in response to input information acquired by a sensor; evaluates the safety of vehicle control based on the control command value based on the input information and the results of the background execution; and the processor of the server determines whether or not to redesign at least one of the vehicle control program or the safety evaluation program according to the safety evaluation result.

8. A software update system according to claim 7, wherein the processor of the vehicle control device collects the input information and the output information of the control command values ​​in accordance with the safety evaluation result and outputs it to the server, and the processor of the server uses the input information and the output information of the control command values ​​and the safety evaluation result to identify risk factors in vehicle control, and redesigns at least one of the vehicle control program or the safety evaluation program in accordance with the identified risk factors.

9. A software update system according to claim 8, wherein the processor of the vehicle control device collects the input information and the output information of the control command value as a trigger when it is determined that the risk value indicating the safety evaluation result is equal to or greater than a threshold.

10. A software update system according to any one of claims 7 to 9, wherein the processor of the vehicle control device evaluates the safety based on the recognition reliability of the input information.

11. A software update system comprising a vehicle control device and a server, wherein the vehicle control device has a memory storing a vehicle control program and a processor that executes the program in the memory, the server has a memory storing a program including a software update program and a safety evaluation program and a processor that executes the program in the memory, the processor of the vehicle control device determines a vehicle control command value from input information acquired by a sensor by executing the vehicle control program, collects the input information and output information of the control command value and outputs it to the server, the processor of the server evaluates the safety of vehicle control by executing the safety evaluation program, determines whether or not to redesign at least one of the vehicle control program or the safety evaluation program according to the safety evaluation result, when a request for redesign is output from the vehicle control device, identifies risk factors in the vehicle control using the output information of the control command value and the basis information for the safety evaluation, and redesigns at least one of the vehicle control program or the safety evaluation program according to the identified risk factors.

12. A software update system according to claim 11, wherein the server's processor requests the vehicle control device to collect data related to the risk factors.

13. A software update system according to claim 11 or claim 12, wherein the server's processor evaluates the safety based on the recognition reliability of the input information.

Images