Software update system and update necessity determination device

Abstract

This software update system updates vehicle control software that is executed by an electronic control device mounted on a vehicle and controls the vehicle. The software update system comprises: a monitoring unit that monitors an operation state of an alternative control means for controlling the vehicle in place of the vehicle control software, and acquires a log of the vehicle control software in a period including at least a time point before an operation start time point of the alternative control means when the alternative control means operates; an update necessity determination unit that determines necessity of update of the vehicle control software on the basis of the log acquired by the monitoring unit; and a distribution unit that, when it is determined by the update necessity determination unit that update of the vehicle control software is necessary, distributes update software for updating the vehicle control software to the vehicle.

Description

Software update system, update necessity determination device

[0001] The present invention relates to a software update system for updating vehicle control software and an update necessity determination device used in the system.

[0002] In the field of automotive control, vehicle control software that runs on electronic control units (ECUs) installed in vehicles is widely used to advance control functions such as autonomous driving, hybrids, and electrification. Furthermore, with the advancement of software functions and network technology, a wireless software update technology called OTA (Over The Air) has been put into practical use.

[0003] For example, Patent Document 1 discloses a technology relating to a software update device that can maintain the functions of a vehicle even while updating a vehicle control function.

[0004] Japanese Patent Application Publication No. 2022-12834

[0005] In Patent Document 1, during software updates, for example, during overwrite installation in a software recording area or while software installed multiple times is running, the vehicle functions are continued by an alternative control means. However, in a software update system, it is essential to determine under what conditions software improvements and updates should be implemented.

[0006] For example, in a preceding vehicle approach warning system, which is one function of an autonomous driving system, while efforts are being made to reduce missed detections of preceding vehicles to ensure system safety, a certain percentage of false detections still occur. As a result, false alarms may be issued even when there is no preceding vehicle, which reduces user convenience. In such cases, it is preferable to update the software based on user complaints received during periodic inspections or other occasions.

[0007] Furthermore, although vehicles equipped with autonomous driving systems undergo sufficient test runs before going on sale, new obstacles that appear after the system goes on sale may not be correctly recognized as obstacles, resulting in false detection. Even in such cases, it is preferable to update the software based on complaints from users obtained during periodic inspections and other occasions.

[0008] As described above, even if excessive false positives occur in a sold system, there is a problem in that it takes time for the situation to be identified and for software updates to be implemented.

[0009] Therefore, an object of the present invention is to quickly update vehicle control software used to control a vehicle when an event occurs that requires improvement.

[0010] A software update system according to the present invention updates vehicle control software executed by an electronic control unit mounted on a vehicle to control the vehicle, and includes: a monitoring unit that monitors the operation status of an alternative control means that controls the vehicle in place of the vehicle control software, and, when the alternative control means operates, acquires a log of the vehicle control software for a period that includes at least a time period before the alternative control means starts operating; an update necessity determination unit that determines whether the vehicle control software needs to be updated based on the log acquired by the monitoring unit; and a distribution unit that distributes update software to the vehicle to update the vehicle control software when the update necessity determination unit determines that the vehicle control software needs to be updated.A software update necessity determination device according to the present invention determines whether vehicle control software executed by an electronic control unit mounted on a vehicle that controls the vehicle needs to be updated, and includes: a log storage unit that, when the alternative control means that controls the vehicle in place of the electronic control unit operates, saves a log of the vehicle control software acquired in the vehicle for a determination period from the time the alternative control means operates to a predetermined time period before the alternative control means operates, and an update necessity determination unit that determines whether the vehicle control software needs to be updated based on the log.

[0011] According to the present invention, when an event occurs that requires improvement in vehicle control software used to control a vehicle, software update can be quickly implemented.

[0012] Problems, configurations, and effects other than those described above will become clear from the following description of the embodiments.

[0013] 1 is a diagram showing the overall configuration of a software update system according to an embodiment of the present invention; FIG. 2 is a diagram showing the hardware configuration of a server device and an electronic control device; FIG. 3 is a diagram showing an example of a correspondence table showing the correspondence between vehicle control software and alternative control means; FIG. 4 is a flowchart showing the flow of a vehicle control software monitoring process; FIG. 5 is a flowchart showing the flow of an update necessity determination process; FIG. 6 is a diagram showing an example of update necessity determination data that records the determination result of whether or not the vehicle control software needs to be updated; FIG. 7 is a flowchart showing the flow of an update priority setting process; FIG. 8 is a flowchart showing the flow of a continued use possibility determination process; FIG. 9 is a diagram showing an example of development software management information; and FIG.

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and some omissions and simplifications have been made as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0015] In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0016] Fig. 1 is a diagram showing the overall configuration of a software update system according to one embodiment of the present invention. The software update system 100 shown in Fig. 1 is configured to include server devices, namely, a software distribution management server 1, a software development server 2, and an update necessity determination server 3, as well as devices mounted on a vehicle. In the figure, the area above the dotted line represents the server devices, and the area below the dotted line represents the devices mounted on the vehicle.

[0017] The software distribution management server 1 includes a distribution unit 11 that distributes update software to the vehicle for updating the vehicle control software used in the vehicle. The distribution unit 11 is implemented in the software distribution management server 1 as one of its functions.

[0018] The software development server 2 has a development software management unit 21 that manages the development status of update software, and a software storage unit 22 that stores updated software that has already been developed. The development software management unit 21 is implemented in the software development server 2 as one of its functions.

[0019] The update necessity determination server 3 includes an update necessity determination unit 31 that determines whether the vehicle control software needs to be updated, an update necessity management unit 32 that manages the result of the determination by the update necessity determination unit 31 as to whether the vehicle control software needs to be updated, and a log storage unit 33 that stores log information on the vehicle control software and alternative control means uploaded from the vehicle. The update necessity determination unit 31 and the update necessity management unit 32 are each implemented in the update necessity determination server 3 as one function of the update necessity determination server 3.

[0020] The software distribution management server 1, the software development server 2, and the update necessity determination server 3 may be configured as separate server devices. In this case, the software distribution management server 1, the software development server 2, and the update necessity determination server 3 may be installed in the same location or in remote locations. Alternatively, two or more of the software distribution management server 1, the software development server 2, and the update necessity determination server 3 may be combined into a single server device.

[0021] The vehicle-side devices include electronic control devices such as an autonomous driving ECU 4, an ADAS (Advanced Driver Assistance System) ECU 5, a communication ECU 6, a powertrain ECU 71, a steering ECU 72, and a brake ECU 73, as well as on-board equipment other than the electronic control devices such as a radar 81 and a camera 82, and vehicle operating members such as an accelerator pedal 83, a steering wheel 84, and a brake pedal 85.

[0022] The radar 81 detects obstacles present around the vehicle. The camera 82 acquires photographed images of the situation around the vehicle. The obstacle detection results by the radar 81 and the images of the situation around the vehicle acquired by the camera 82 are input to the autonomous driving ECU 4 and the ADAS_ECU 5 as external environment information for the vehicle.

[0023] The autonomous driving ECU 4 executes an autonomous driving system 41, which is a type of vehicle control software, to perform autonomous driving control of the vehicle. The autonomous driving system 41 calculates control command values ​​related to acceleration / deceleration amounts and steering amounts for autonomous driving of the vehicle based on external information input from a radar 81 and a camera 82. The calculated control command values ​​are then output to the powertrain ECU 71, steering ECU 72, and brake ECU 73, respectively, and these electronic control devices are used to adjust the acceleration / deceleration amounts and steering amounts of the vehicle according to the control command values, thereby performing autonomous driving of the vehicle. The autonomous driving system 41 is configured using, for example, a predetermined algorithm and AI (artificial intelligence) such as a deep neural network that extracts predetermined objects from images.

[0024] The ADAS_ECU 5 has the functions of an autonomous emergency braking (AEB) 51, a preceding vehicle approach warning 52, a driving lane departure warning 53, and a preceding vehicle departure notification 54. The automatic emergency braking 51 is a function that automatically issues a braking command to the brake ECU 73 when a collision with a nearby obstacle is predicted based on external information input from a radar 81 and a camera 82. The preceding vehicle approach warning 52 is a function that issues a warning, such as an alarm sound, to the user 9 in the vehicle when an approach to a preceding vehicle is estimated based on the external information from the radar 81 and the camera 82. The driving lane departure warning 53 is a function that issues a warning, such as an alarm sound, to the user 9 when a deviation of the vehicle from the driving lane is estimated based on the external information from the camera 82. The preceding vehicle departure notification 54 is a function that issues a warning, such as an alarm sound, to the user 9 when the preceding vehicle starts moving while the vehicle is stopped, such as at a traffic light, but the accelerator pedal 83 is not operated to accelerate, based on external information from the radar 81 and the camera 82. These functions are realized by vehicle control software executed in the ADAS_ECU 5. That is, the vehicle control software executed by the ADAS_ECU 5 is software that causes the ADAS_ECU 5 to perform control to automatically apply the brakes when there is a risk of the vehicle colliding with an obstacle, and causes the ADAS_ECU 5 to output a warning in response to the vehicle's departure from its driving lane, its approach to a preceding vehicle, or a delay in starting after stopping. The automatic emergency brake 51 operates as an alternative control means for the autonomous driving system 41 executed by the autonomous driving ECU 4.

[0025] The powertrain ECU 71 controls powertrain equipment such as the engine and electric motor mounted on the vehicle based on the amount of operation of an accelerator pedal 83 by the user 9, who is the driver of the vehicle, or a control command value from the automatic driving ECU 4. The steering ECU 72 controls steering equipment such as electric power steering and steer-by-wire mounted on the vehicle based on the amount of operation of a steering wheel 84 by the user 9 or a control command value from the automatic driving ECU 4. The brake ECU 73 controls brakes mounted on the vehicle based on the amount of operation of a brake pedal 85 by the user 9 or a control command value from the automatic driving ECU 4. The user 9 can drive the vehicle by operating the accelerator pedal 83, steering wheel 84, and brake pedal 85 to issue acceleration instructions, steering instructions, and deceleration / braking instructions to the vehicle, respectively.

[0026] The communication ECU 6 includes a monitoring unit 61, a log storage unit 62, and a communication unit 63. The monitoring unit 61 monitors the operation status of vehicle control software executed by the autonomous driving ECU 4 and the ADAS_ECU 5 to control the vehicle, and the operation status of an alternative control means that controls the vehicle in place of the vehicle control software. When the alternative control means operates in place of the vehicle control software, the communication ECU 6 acquires input logs and operation logs of the vehicle control software and the alternative control means during a log acquisition period that includes at least a period prior to the start of operation of the alternative control means. The alternative control means may be the automatic emergency brake 51 of the ADAS_ECU 5 or vehicle operations performed by the user 9 using the accelerator pedal 83, steering wheel 84, or brake pedal 85, and is predetermined for each type of vehicle control software. The specific correspondence between the vehicle control software and the alternative control means will be described later.

[0027] The monitoring unit 61 acquires an input log and an operation log of the vehicle control software for each type of vehicle control software. For example, in the case of the autonomous driving system 41, the monitoring unit 61 acquires, as an input log, external environment information input to the autonomous driving ECU 4 from the radar 81 and the camera 82, and the calculation results of the acceleration / deceleration amount and steering amount by the autonomous driving system 41, as an operation log. Furthermore, in the case of the preceding vehicle approach warning 52 and the preceding vehicle departure notification 54, the monitoring unit 61 acquires, as an input log, external environment information input to the ADAS_ECU 5 from the radar 81 and the camera 82, and the estimation results of the positional relationship between the host vehicle and the preceding vehicle based on the preceding vehicle approach warning 52 and the preceding vehicle departure notification 54, as an operation log. Similarly, in the case of the driving lane departure warning 53, the monitoring unit 61 acquires, as an input log, external environment information input to the ADAS_ECU 5 from the camera 82, and the estimation result of deviation from the driving lane based on the driving lane departure warning 53, as an operation log.

[0028] The monitoring unit 61 also acquires an input log and an operation log of the alternative control means for each type of alternative control means. For example, in the case of the automatic emergency brake 51 operating as an alternative control means for the automatic driving system 41, the monitoring unit 61 acquires external environment information input from the radar 81 or the camera 82 to the ADAS_ECU 5 as an input log, and the operation status of the automatic emergency brake 51 as an operation log. For example, when the user 9 operates the brake pedal 85 as an alternative control means for the automatic driving system 41 or the preceding vehicle approach warning 52, the monitoring unit 61 acquires the operation amount of the brake pedal 85 input from the brake pedal 85 to the brake ECU 73 as an input log, and the brake control status by the brake ECU 73 as an operation log. Similarly, for example, when the user 9 operates the steering wheel 84 as an alternative control means for the lane departure warning 53, the monitoring unit 61 acquires the operation amount of the steering wheel 84 input from the steering wheel 84 to the steering ECU 72 as an input log, and the control status of the steering device by the steering ECU 72 as an operation log. Furthermore, for example, when the user 9 operates the accelerator pedal 83 as an alternative control means for the preceding vehicle departure notification 54, the amount of operation of the accelerator pedal 83 input from the accelerator pedal 83 to the powertrain ECU 71 is acquired as an input log, and the control status of the powertrain equipment by the powertrain ECU 71 is acquired as an operation log.

[0029] The log storage unit 62 temporarily stores the operation logs of the vehicle control software and the alternative control means acquired by the monitoring unit 61. The communication unit 63 periodically transmits the operation logs stored in the log storage unit 62 to the update necessity determination server 3, and when update software is distributed from the software distribution management server 1, receives the update software and provides it to the autonomous driving ECU 4 and the ADAS_ECU 5.

[0030] 2A and 2B are diagrams showing the hardware configurations of the server devices and electronic control devices. Each of the server devices, the software distribution management server 1, the software development server 2, and the update necessity determination server 3, has a hardware configuration such as that shown in FIG. 2A. Furthermore, each of the autonomous driving ECU 4, the ADAS_ECU 5, and the communication ECU 6 has a hardware configuration such as that shown in FIG. 2B.

[0031] As shown in FIG. 2(a), each server device includes a processor 101, a memory 102, an external storage device 103, a communication interface (communication IF) 104, an input / output device 105, and a communication bus 106 connecting these components.

[0032] The processor 101 controls each unit of the server device and performs various arithmetic operations. The processor 101 is configured using, for example, a central processing unit (CPU) or a graphics processing unit (GPU), and can implement each functional block shown in FIG. 1 of the software distribution management server 1, the software development server 2, and the update necessity determination server 3 by executing programs stored in the memory 102. That is, the distribution unit 11 of the software distribution management server 1, the development software management unit 21 of the software development server 2, the update necessity determination unit 31 and the update necessity management unit 32 of the update necessity determination server 3, and the like are implemented by processing by the processor 101. The memory 102 is, for example, a semiconductor storage device such as a random access memory (RAM), and temporarily stores programs loaded from the external storage device 103 and executed by the processor 101, as well as necessary work data.

[0033] The external storage device 103 is, for example, a large-capacity non-transitory magnetic storage device or semiconductor storage device such as a hard disk drive (HDD) or a solid state drive (SSD), and stores programs executed by the processor 101 and data used in the processing of the processor 101. The software storage unit 22 in the software development server 2 and the log storage unit 33 in the update necessity determination server 3 are each realized using the external storage device 103. Note that some or all of the programs and data in the external storage device 103 may be stored in the external storage device 103 in advance, or may be introduced from outside as needed.

[0034] The communication IF 104 operates under the control of the processor 101 and performs interface processing for transmitting and receiving various information via a network (not shown). The interface processing of this communication IF 104 enables communication between each server device, and between the software distribution management server 1 or the update necessity determination server 3 and the vehicle-side communication ECU 6 via the Internet or a wireless communication network.

[0035] The input / output device 105 is a device for receiving input from an administrator who manages each server device and for outputting information to be presented to the administrator, and is configured using, for example, a mouse, keyboard, display, and the like.

[0036] As shown in FIG. 2(b), each electronic control device includes a processor 201, a memory 202, an external storage device 203, a communication interface (communication IF) 204, and a communication bus 206 connecting these components.

[0037] The processor 201 controls each part of the electronic control device and performs various arithmetic processing. The processor 201 is configured using, for example, a CPU, GPU, FPGA, etc., and can implement each functional block of the autonomous driving ECU 4, the ADAS_ECU 5, and the communication ECU 6 shown in FIG. 1 by executing programs such as vehicle control software stored in the memory 202. The memory 202 is a semiconductor storage device such as a RAM, and temporarily stores programs loaded from the external storage device 203 and executed by the processor 201, as well as necessary work data.

[0038] The external storage device 203 is configured using a semiconductor storage device such as a flash memory, and stores programs executed by the processor 201 and data used in the processing of the processor 201. The log storage unit 62 in the communication ECU 6 is realized using the external storage device 203.

[0039] The communication IF 204 operates under the control of the processor 201 and performs interface processing for transmitting and receiving various types of information via a network (not shown). The interface processing of this communication IF 204 enables communication between electronic control units in the vehicle, and between the communication ECU 6 and the software distribution management server 1 or the update necessity determination server 3 via an in-vehicle network such as a Controller Area Network (CAN) or various external networks such as the Internet or a wireless communication network.

[0040] It should be noted that other electronic control units mounted on the vehicle, such as the powertrain ECU 71, steering ECU 72, and brake ECU 73, can also have the same hardware configuration as that shown in FIG. 2(a).

[0041] Next, the process performed by the communication ECU 6 will be described in detail below.

[0042] 3 is a diagram showing an example of a correspondence table 61A showing the correspondence between vehicle control software and alternative control means. The monitoring unit 61 in the communication ECU 6 stores, for example, a correspondence table 61A as shown in FIG. 3, and can use this correspondence table 61A to identify the correspondence between each vehicle control software to be monitored and the alternative control means.

[0043] In the correspondence table 61A of FIG. 3 , for example, ID number 1-1 indicates that the autonomous driving system 41, which is vehicle control software executed by the autonomous driving ECU 4, is the object of monitoring by the monitoring unit 61, and the alternative control means of this autonomous driving system 41 is the automatic emergency brake 51. This represents a scene in which the autonomous driving system 41 instructs the vehicle to move forward, while the automatic emergency brake 51 instructs the vehicle to brake, causing the vehicle to stop. Specifically, this corresponds to a scene in which the autonomous driving system 41 overlooks a nearby obstacle, causing the automatic emergency brake 51, which is a redundant system, to operate due to this nearby obstacle. Similarly, for the other ID numbers 1-2, 2, 3, and 4, correspondences between the vehicle control software monitored by the monitoring unit 61 and their alternative control means are shown.

[0044] The combinations of vehicle control software and alternative control means shown in the correspondence table 61A represent situations in which the vehicle control software does not operate as intended and the alternative control means operates instead. The occurrence of such situations leads to a degradation of the driving experience of the user riding in the vehicle. Therefore, if a situation corresponding to one of the combinations shown in the correspondence table 61A occurs, it is preferable to quickly improve the vehicle control software included in that combination to suppress the operation of the alternative control means.

[0045] In the software update system 100 of this embodiment, the monitoring unit 61 uses the correspondence table 61A to set a correspondence relationship between the vehicle control software and the alternative control means, and monitors the operation of the vehicle control software and the alternative control means. If the corresponding alternative control means operates while the vehicle control software is operating, the update necessity determination unit 31 determines whether the vehicle control software needs to be updated. This makes it possible to determine whether the vehicle control software needs to be updated before a user reports a complaint about a malfunction of the vehicle control software caused by environmental changes after market shipment or a malfunction of the vehicle control software caused by extremely rare conditions. This advantageously enables continuous improvement of the vehicle control software.

[0046] Specifically, for example, among the vehicle control software, the autonomous driving system 41 executed by the autonomous driving ECU 4 is software that causes the autonomous driving ECU 4 to perform autonomous driving control of the vehicle. For this autonomous driving system 41, the monitoring unit 61 monitors the operation status of the automatic emergency brake 51 and the driver's operation of the brake pedal 85 as alternative control means, based on the correspondence table 61A. For example, among the vehicle control software, the driving lane departure warning 53 executed by the ADAS_ECU 5 is software that outputs an alarm to the ADAS_ECU 5 in response to the vehicle's departure from its driving lane. For this driving lane departure warning 53, the monitoring unit 61 monitors the operation status of the driver's steering operation, i.e., operation of the steering wheel 84, as an alternative control means, based on the correspondence table 61A. For example, among the vehicle control software, the leading vehicle approach warning 52 executed by the ADAS_ECU 5 is software that outputs an alarm to the ADAS_ECU 5 in response to the vehicle's approach to a leading vehicle. In response to this preceding vehicle approach warning 52, the monitoring unit 61 monitors the operation status of the driver's operation of the brake pedal 85 as an alternative control means based on the correspondence table 61A. Furthermore, for example, among the vehicle control software, the preceding vehicle departure notification 54 executed by the ADAS_ECU 5 is software that outputs a notification regarding the start of the preceding vehicle to the ADAS_ECU 5. In response to this preceding vehicle departure notification 54, the monitoring unit 61 monitors the operation status of the driver's operation of the accelerator pedal 83 as an alternative control means based on the correspondence table 61A. This makes it possible to monitor the operation status of the corresponding alternative control means for the vehicle control software executed in each electronic control unit of the vehicle and store an operation log.

[0047] 4 is a flowchart showing the flow of the vehicle control software monitoring process executed by the monitoring unit 61. The monitoring unit 61 performs the vehicle control software monitoring process shown in the flowchart of FIG. 4 at predetermined processing intervals. The vehicle control software monitoring process starts from step S610.

[0048] In step S611, the correspondence table 61A is referenced to check whether the vehicle control software to be monitored is running. If it is running, the process proceeds to step S612, and if it is not running, the process returns to step S611.

[0049] In step S612, the correspondence table 61A is referenced to monitor whether the alternative control means corresponding to the vehicle control software determined to be in operation in step S611 has been activated. If it has been activated, the process proceeds to step S613, and if it has not been activated, the process proceeds to step S615.

[0050] In steps S613 and S614, the input log and operation log of the alternative control means determined to be in operation in step S612 are acquired and stored in the log storage unit 62 in the communication ECU 6, respectively.

[0051] In steps S615 and S616, the input log and operation log of the vehicle control software to be monitored that was determined to be in operation in step S611 are acquired and stored in the log storage unit 62 in the communication ECU 6, respectively.

[0052] After the process of step S616 is executed, the vehicle control software monitoring process ends in step S617.

[0053] By executing the vehicle control software monitoring process described above, the monitoring unit 61 monitors the operating status of the alternative control means that controls the vehicle in place of the vehicle control software, and when the alternative control means operates, it can obtain the input log and operation log of the vehicle control software for a period that includes at least a point before the start of the operation.

[0054] Fig. 5 is a flowchart showing the flow of the update necessity determination process executed by the update necessity determination unit 31. In the update necessity determination server 3, the update necessity determination unit 31 performs the update necessity determination process shown in the flowchart of Fig. 5 at every predetermined processing cycle. The update necessity determination process starts from step S310.

[0055] In step S311, the operation log of the alternative control means that is periodically transmitted from the communication ECU 6 and stored in the log storage unit 33 is read.

[0056] In step S312, the operation start time of the alternative control means when the alternative control means operates, that is, the time when the alternative control means starts operating, is identified based on the operation log of the alternative control means read in step S311.

[0057] In step S313, based on the operation start time of the alternative control means identified in step S312, the input log and operation log of the vehicle control software that are periodically transmitted from the communication ECU 6 and stored in the log storage unit 33 are read. Here, a time a predetermined time before the operation start time of the alternative control means is set as the log acquisition start time of the vehicle control software, and the input log and operation log of the vehicle control software that were acquired from this log acquisition start time to the operation start time of the alternative control means are read from the log storage unit 33.

[0058] In step S314, it is determined whether or not an update of the vehicle control software is necessary based on the input log and operation log of the vehicle control software read in step S313. If it is determined that an update is necessary, the process proceeds to step S315; if it is determined that an update is not necessary, the process proceeds to step S316. Here, the contents of the input log and operation log of the read vehicle control software are compared, and it is determined from the contents of these logs whether or not the cause of the operation of the alternative control means is a malfunction of the vehicle control software.

[0059] For example, among the vehicle control software, the autonomous driving system 41 executed by the autonomous driving ECU 4 is software that causes the autonomous driving ECU 4 to output vehicle control command values ​​based on information about the environment outside the vehicle. When an automatic emergency brake 51 is activated or the brake pedal 85 is operated by the user 9 as an alternative control means for the autonomous driving system 41, the update necessity determination unit 31 determines whether the autonomous driving ECU 4 executing the autonomous driving system 41 was able to output control command values ​​that satisfy predetermined criteria, and determines whether an update of the autonomous driving system 41 is necessary based on the determination result. Specifically, for example, the values ​​of the acceleration / deceleration amount and steering amount indicated in the operation log of the autonomous driving system 41 are compared with the external environment information indicated in the input log of the autonomous driving system 41, and if values ​​of the acceleration / deceleration amount and steering amount that match the external environment information are obtained, the update necessity determination unit 31 determines that the autonomous driving ECU 4 was able to output control command values ​​that satisfy the predetermined criteria, and determines that an update of the autonomous driving system 41 is not necessary. On the other hand, if values ​​of acceleration / deceleration and steering amount that match the external information are not obtained, it is determined that the automatic driving ECU 4 was unable to output control command values ​​that satisfy the specified criteria, and it is determined that an update of the automatic driving system 41 is necessary.

[0060] Furthermore, for example, among the vehicle control software, the preceding vehicle approach warning 52, the driving lane departure warning 53, and the preceding vehicle departure notification 54 executed by the ADAS_ECU 5 are software that causes the ADAS_ECU 5 to output predetermined warnings and notifications based on information about the environment outside the vehicle. When the accelerator pedal 83, the steering wheel 84, or the brake pedal 85 is operated by the user 9 as an alternative control means, the update necessity determination unit 31 determines whether the ADAS_ECU 5 was able to output a warning or notification appropriate to the vehicle situation, and determines whether the preceding vehicle approach warning 52, the driving lane departure warning 53, or the preceding vehicle departure notification 54 needs to be updated based on the determination result. Specifically, for example, the ADAS_ECU 5 compares the estimation result of the positional relationship between the host vehicle and the preceding vehicle indicated by the operation log of the preceding vehicle approach warning 52 or the preceding vehicle departure notification 54 with the external environment information indicated by these input logs, and if the estimation result matches the external environment information, it determines that the ADAS_ECU 5 was able to output an alarm or notification suited to the vehicle situation, and determines that there is no need to update the preceding vehicle approach warning 52 or the preceding vehicle departure notification 54. Also, for example, the ADAS_ECU 5 compares the estimation result of deviation from the driving lane indicated by the operation log of the driving lane departure warning 53 with the external environment information indicated by the input log of the driving lane departure warning 53, and if the estimation result matches the external environment information, it determines that there is no need to update the driving lane departure warning 53. On the other hand, if an estimation result that matches the external information is not obtained, the ADAS_ECU 5 determines that it is unable to output an alarm or notification that matches the vehicle situation, and determines that the preceding vehicle approach alarm 52, driving lane departure alarm 53, or preceding vehicle departure notification 54 needs to be updated.

[0061] In step S314, by performing the determination process described above, for example, even if the alternative control means is operated, if there is no problem with the operation of the vehicle control software, such as sudden braking due to a driver's incorrect judgment, it is determined that an update is not necessary. On the other hand, if the vehicle control software is not operating normally and the driver intervenes in the driving operation, it is determined that an update is necessary. In addition, it is possible to determine whether an update of the vehicle control software is necessary by any method based on the input log and operation log of the vehicle control software.

[0062] In step S315, the vehicle control software determined to require updating in step S314 is notified to the update necessity management unit 32. In response to this notification, the update necessity management unit 32 can manage the result of the determination made by the update necessity determination unit 31 as to whether the vehicle control software needs to be updated. If the process of step S315 has been executed, or if it has been determined in step S314 that updating is not required, the process ends in step S316.

[0063] By executing the update necessity determination process described above, the update necessity determination unit 31 can determine whether the vehicle control software needs to be updated based on the vehicle control software log acquired by the monitoring unit 61. This has the effect of analyzing the operating status of the alternative control means and accurately determining whether the vehicle control software needs to be updated.

[0064] 6 is a diagram showing an example of update necessity determination data 322 that records the determination result of whether or not the vehicle control software needs to be updated by update necessity determination unit 31. In update necessity determination server 3, update necessity management unit 32 can manage the determination result of whether or not the vehicle control software needs to be updated by update necessity determination unit 31 by storing update necessity determination data 322 such as that shown in FIG.

[0065] The update necessity determination data 322 in Figure 6 includes the following items for each vehicle control software determined to require an update: ID, software requiring update, required update version, number of alternative control operations, number of accidents, number of user complaints, update priority, continued use possible, and rollback version. The ID represents an ID number individually assigned to each vehicle control software. The software requiring update represents the name of the vehicle control software determined to require an update. The required update version represents the version of the vehicle control software determined to require an update. The number of alternative control operations represents the number of operations of the alternative control means corresponding to each vehicle control software, and is set based on, for example, the operation log of the alternative control means stored in the log storage unit 33.

[0066] The number of accidents indicates the number of past accidents caused by malfunctions of each vehicle control software, and is set, for example, based on the operation log of each vehicle control software. The number of user complaints indicates the number of past complaints from users about malfunctions of each vehicle control software, and is set based on data collected from an external information source, for example, a vehicle manufacturer's server. The update priority indicates the priority when updating each vehicle control software, and is set, for example, by an update priority setting process executed by the update necessity management unit 32. The update priority setting process will be described in detail later.

[0067] The continued use possibility indicates whether or not each vehicle control software can be continued to be used in the state before the update. The rollback version indicates an old version (rollback version) that can be temporarily applied to vehicle control software that cannot be continued to be used until it is updated. The continued use possibility and rollback version are set, for example, by a continued use possibility determination process executed by the update necessity management unit 32. The continued use possibility determination process will be described in detail later.

[0068] The above items included in the update necessity determination data 322 are merely examples, and any of the items may be omitted, or other items may be included.

[0069] Fig. 7 is a flowchart showing the flow of the update priority setting process executed by the update necessity management unit 32. The update necessity management unit 32 performs the update priority setting process shown in the flowchart of Fig. 7 at predetermined processing intervals. The update priority setting process starts from step S3220.

[0070] In step S3221, the number of accidents in the update necessity determination data 322 is referenced, and the vehicle control software in the update necessity determination data 322 is sorted so that the highest priority is given to the software with the highest number.

[0071] In step S3222, for each vehicle control software sorted in step S3221 that has the same priority (same number of accidents), the number of user complaints in the update necessity determination data 322 is referenced, and the vehicle control software in the update necessity determination data 322 is sorted so that the highest number is assigned a higher priority.

[0072] In step S3223, for each vehicle control software among those sorted in steps S3221 and S3222 that has the same priority (same number of accidents and number of user complaints), the number of alternative control operations in the update necessity determination data 322 is referenced, and the vehicle control software in the update necessity determination data 322 is sorted so that the higher the number, the higher the priority.

[0073] After the process of step S3223 is executed, the update priority setting process ends in step S3224.

[0074] By executing the update priority setting process as described above, the update necessity management unit 32 can set update priorities for each of the vehicle control software that has been determined to require updating, based on the number of accidents, the number of user complaints, and the number of alternative control operations, when there are multiple vehicle control software that have been determined to require updating. This has the effect of enabling prioritization of vehicle control software update requests that must be addressed to maintain safety.

[0075] The update priority setting process described above is merely an example, and update priorities may be set based on other information. For example, update priorities may be set by excluding any of the items of the number of accidents, the number of user complaints, and the number of alternative control operations, or update priorities may be set by taking other information into consideration. However, in order to improve safety and user satisfaction, it is preferable to set the update priority for each vehicle control software based on at least one of the past frequency of operation of the alternative control means represented by the number of alternative control operations, the past frequency of accidents represented by the number of accidents, and the past frequency of user complaints represented by the number of user complaints, by referring to the update necessity determination data 322.

[0076] Fig. 8 is a flowchart showing the flow of the continued use permission determination process executed by the update necessity management unit 32. The update necessity management unit 32 performs the continued use permission determination process shown in the flowchart of Fig. 8 at every predetermined processing cycle. The continued use permission determination process starts from step S3230.

[0077] In step S3231, the update necessity determination data 322 is referenced, and one of the vehicle control software whose information is set in the update necessity determination data 322, that is, the vehicle control software whose update is determined to be necessary, is selected.

[0078] In step S3232, it is determined whether the vehicle control software selected in step S3231 can be continued to be used. Here, the determination of whether the vehicle control software can be continued to be used is made based on, for example, the number of alternative control operations and the number of accidents, or both, of the items set in the update necessity determination data 322. Specifically, for example, if both the number of alternative control operations and the number of accidents are less than their respective predetermined thresholds, it is determined that the vehicle control software can be continued to be used. On the other hand, if either or both of the number of alternative control operations and the number of accidents exceed their respective thresholds, it is determined that the vehicle control software cannot be continued to be used.

[0079] The above determination method is merely an example, and other determination methods may be used to determine whether the vehicle control software can be continued. For example, the determination whether the vehicle control software can be continued may be made using only one of the number of alternative control operations or the number of accidents, or the determination whether the vehicle control software can be continued may be made taking other information into consideration. However, considering safety, it is preferable to refer to the update necessity determination data 322 and determine whether the vehicle control software can be continued based on at least one of the past frequency of operation of the alternative control means represented by the number of alternative control operations and the past frequency of accidents represented by the number of accidents.

[0080] In step S3233, it is determined whether or not it was determined in step S3232 that the vehicle control software can be continuously used. If it is determined that the vehicle control software can be continuously used, the process proceeds to step S3235. If it is determined that the vehicle control software cannot be continuously used, the process proceeds to step S3234.

[0081] In step S3234, a rollback version of the vehicle control software selected in step S3231 is set. Here, for example, the latest version of the vehicle control software that has previously been determined to be usable is set as the rollback version.

[0082] In step S3235, it is determined whether all of the vehicle control software whose information is set in the update necessity determination data 322, i.e., all of the vehicle control software determined to require updating, have been selected in step S3231. If there is unselected vehicle control software remaining in the update necessity determination data 322, the process returns to step S3231, and steps S3231 to S3235 are repeated for any of the vehicle control software. On the other hand, if all of the vehicle control software has been selected, the process proceeds to step S3236, and the continued use eligibility determination process ends.

[0083] By executing the above-described continued use permission determination process, the update necessity management unit 32 can set whether continued use is permitted and the rollback version for each piece of vehicle control software determined to require updating. This has the effect of making it possible to appropriately determine, taking safety into consideration, whether vehicle control software that requires updating can be continued to be used, and, for vehicle control software that cannot be continued to be used, which version should be used until it is updated.

[0084] 9 is a diagram showing an example of development software management information 211 used by the development software management unit 21 when managing the development status of update software. By storing development software management information 211 such as that shown in FIG. 8 , the development software management unit 21 in the software development server 2 can manage the development status of update software to be used for each update of each vehicle control software that has been determined by the update necessity determination server 3 to require updating and for which development of update software has been instructed.

[0085] The development software management information 211 in Figure 9 includes the following items for each vehicle control software determined to require an update: ID, vehicle control software, and latest version. The ID represents an ID number individually assigned to each vehicle control software. The vehicle control software represents the name of the vehicle control software determined to require an update and for which development of update software has been instructed. The latest version represents the latest version of each vehicle control software. Note that the above items included in the development software management information 211 are merely examples, and some items may be omitted or other items may be included.

[0086] 10 is a flowchart showing the flow of distribution processing executed by the distribution unit 11. In the software distribution management server 1, the distribution unit 11 performs the distribution processing shown in the flowchart of FIG. 10 at predetermined processing intervals. The distribution processing starts from step S110.

[0087] In step S111, an inquiry is made to the update necessity determination server 3 to obtain information on the update-required version of the vehicle control software that has been determined to require updating. Here, for example, by obtaining the value set for the update-required version of each vehicle control software in the update necessity determination data 322 shown in FIG. 6, it is possible to obtain information on the update-required version of the vehicle control software that requires updating.

[0088] In step S112, an inquiry is made to the software development server 2 to obtain information on the latest version of the developed vehicle control software. Here, for example, by obtaining the value set for the latest version of each vehicle control software in the development software management information 211 shown in Fig. 9, it is possible to obtain information on the latest version of the vehicle control software that is currently available for distribution.

[0089] In step S113, the information on the update-required version acquired in step S111 is compared with the information on the latest version acquired in step S112, and it is confirmed whether the latest version is newer than the update-required version for each vehicle control software that needs to be updated. If the result shows that the latest version is newer than the update-required version, it is determined that update software is available, and the process proceeds to step S114; otherwise, it is determined that update software is not available, and the process proceeds to step S115.

[0090] In step S114, the latest version of the developed vehicle control software stored in the software storage unit 22 of the software development server 2 is acquired from the software development server 2. The acquired latest version of the vehicle control software is then distributed to the vehicle as update software for updating the vehicle control software in the vehicle. The process then proceeds to step S117. The update software distributed from the distribution unit 11 in step S114 is received by the communication ECU 6 in the vehicle and used to update the corresponding vehicle control software.

[0091] In step S115, it is determined whether the vehicle control software version requiring update acquired in step S111 can be continuously used. Here, it is possible to determine whether the vehicle control software can be continuously used based on the value set for whether the vehicle control software can be continuously used in the update necessity determination data 322 shown in FIG. 6. If the vehicle control software can be continuously used, the process proceeds to step S117. If the vehicle control software cannot be continuously used, the process proceeds to step S116.

[0092] In step S116, the software development server 2 is queried for vehicle control software corresponding to the rollback version specified in the update necessity determination data 322. Upon receiving the query from the distribution unit 11, the software development server 2 obtains the vehicle control software corresponding to the rollback version from the software storage unit 22 and provides it to the software distribution management server 1. The distribution unit 11 distributes the rollback version of the vehicle control software provided by the software development server 2 to the vehicle. Then, the process proceeds to step S117. The rollback version of the vehicle control software distributed from the distribution unit 11 in step S116 is received by the communication ECU 6 in the vehicle and used to roll back the corresponding vehicle control software.

[0093] After the processing of step S114, S115, or S116 is executed, the distribution processing ends in step S117.

[0094] By executing the distribution process described above, the distribution unit 11 determines whether or not update software is available when the update necessity determination unit 31 determines that an update of the vehicle control software is required. As a result, if update software is available, the distribution unit 11 can distribute the update software, and if update software is not available, the distribution unit 11 can not distribute the update software. Furthermore, if the update necessity management unit 32 determines that the vehicle control software cannot be continuously used, the distribution unit 11 can distribute to the vehicle a rollback version of the vehicle control software that is available in each electronic control unit.

[0095] According to the embodiment of the present invention described above, the following advantageous effects are achieved.

[0096] (1) The software update system 100 updates vehicle control software, which is executed by an electronic control unit (ECU) mounted on a vehicle and controls the vehicle. The software update system 100 includes a monitoring unit 61, an update necessity determination unit 31, and a distribution unit 11. The monitoring unit 61 monitors the operation status of an alternative control means that controls the vehicle in place of the vehicle control software. When the alternative control means operates (step S612: Yes), the monitoring unit 61 acquires logs (input log, operation log) of the vehicle control software for a period that includes at least a time before the alternative control means starts operating (steps S615, S616). The update necessity determination unit 31 determines whether the vehicle control software needs to be updated based on the logs acquired by the monitoring unit 61 (step S314). When the update necessity determination unit 31 determines that the vehicle control software needs to be updated, the distribution unit 11 distributes update software for updating the vehicle control software to the vehicle (step S114). This configuration allows for rapid software update when an issue requiring improvement occurs in the vehicle control software used to control the vehicle.

[0097] (2) The vehicle control software includes an autonomous driving system 41, which is software that causes an autonomous driving ECU 4, which is an electronic control device, to output control command values ​​for the vehicle based on information about the environment outside the vehicle. In step S314, the update necessity determination unit 31 determines whether the autonomous driving ECU 4 was able to output control command values ​​that satisfy predetermined criteria, and determines whether the autonomous driving system 41 needs to be updated based on the determination result. This makes it possible to appropriately determine whether the autonomous driving system 41 needs to be updated.

[0098] (3) The vehicle control software includes an autonomous driving system 41, which is software that causes an autonomous driving ECU 4, which is an electronic control device, to perform autonomous driving control of the vehicle. The monitoring unit 61 monitors the operating status of the autonomous driving system 41, based on the correspondence table 61A of FIG. 3 , using an automatic emergency brake 51 of the vehicle or a brake operation by the user 9, who is the driver of the vehicle, as an alternative control means. The vehicle control software also includes a lane departure warning 53, which is software that outputs an alarm for the vehicle's departure from its lane to the ADAS_ECU 5, which is an electronic control device. The monitoring unit 61 monitors the operating status of the lane departure warning 53, based on the correspondence table 61A of FIG. 3 , using a steering operation by the user 9 as an alternative control means. The vehicle control software also includes a leading vehicle approach warning 52, which is software that outputs an alarm for the vehicle's approach to a leading vehicle to the ADAS_ECU 5, and a leading vehicle departure notification 54, which is software that outputs a notification for the start of the leading vehicle to the ADAS_ECU 5. In response to these, the monitoring unit 61 monitors the operating status of the brake pedal operation or accelerator pedal operation by the user 9 as the alternative control means based on the correspondence table 61A in Fig. 3. In this way, it is possible to reliably monitor the operating status of the alternative control means corresponding to various vehicle control software.

[0099] (4) When the update necessity determination unit 31 determines that the vehicle control software needs to be updated, the distribution unit 11 determines whether or not the update software is available (step S113), and if the update software is available (step S113: Yes), the distribution unit 11 distributes the update software (step S114). On the other hand, if the update software is not available (step S113: No), the distribution unit 11 does not distribute the update software. This allows the distribution unit 11 to appropriately distribute the update software depending on whether or not the update software is available.

[0100] (5) The software update system 100 includes an update necessity management unit 32 that manages the results of the determination by the update necessity determination unit 31 as to whether or not a vehicle control software update is necessary. When there are multiple pieces of vehicle control software determined to require updating by the update necessity determination unit 31, the update necessity management unit 32 executes the update priority setting process shown in the flowchart of FIG. 7 to set update priorities for each of the multiple pieces of vehicle control software. Specifically, the update necessity management unit 32 sets update priorities based on at least one of the frequency of operation of the alternative control means, the frequency of accidents, and the frequency of user complaints (steps S3221 to S3223). As a result, when there are multiple pieces of vehicle control software requiring updating, appropriate update priorities can be set for each piece of vehicle control software, taking safety and user satisfaction into consideration.

[0101] (6) The update necessity management unit 32 also sets information about whether the vehicle control software can be continued to be used based on at least one of the operation frequency of the alternative control means and the accident frequency (step S3232). If the distribution unit 11 determines that the vehicle control software cannot be continued to be used (step S115: No), the distribution unit 11 distributes a rollback version of the vehicle control software that can be used in the electronic control unit to the vehicle (step S116). This allows the appropriate determination, taking safety into consideration, of whether vehicle control software that requires an update can be continued to be used and, for vehicle control software that cannot be continued to be used, which version should be used until the software is updated.

[0102] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0103] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in the processor's built-in memory, an external flash memory, a storage device such as an HDD or SSD, or on a virtualization server such as a cloud.

[0104] Furthermore, the present invention is not limited to the above-described embodiment, and various modifications are possible within the scope of the invention.

[0105] 1...Software distribution management server, 2...Software development server, 3...Update necessity determination server, 4...Autonomous driving ECU, 5...ADAS_ECU, 6...Communication ECU, 9...User, 11...Distribution unit, 21...Development software management unit, 22...Software storage unit, 31...Update necessity determination unit, 32...Update necessity management unit, 33...Log storage unit, 41...Autonomous driving system, 51...Automatic emergency braking, 52...Preceding vehicle approach warning, 53...Travel lane departure warning, 54...Preceding vehicle departure notification, 61...Monitoring unit, 62...Log storage unit, 63...Communication unit, 71...Powertrain ECU, 72...Steering ECU, 73...Brake ECU, 83...Accelerator pedal, 84...Steering wheel, 85...Brake pedal

Claims

1. A software update system that updates vehicle control software that is executed by an electronic control unit mounted on a vehicle and controls the vehicle, comprising: a monitoring unit that monitors the operating status of an alternative control means that controls the vehicle in place of the vehicle control software, and, when the alternative control means operates, acquires a log of the vehicle control software for a period that includes at least a point in time before the alternative control means starts operating; an update necessity determination unit that determines whether the vehicle control software needs to be updated based on the log acquired by the monitoring unit; and a distribution unit that distributes update software to the vehicle to update the vehicle control software when the update necessity determination unit determines that the vehicle control software needs to be updated.

2. A software update system as described in claim 1, wherein the vehicle control software includes software that causes the electronic control unit to output control command values ​​for the vehicle based on information about the external environment of the vehicle, and the update necessity determination unit determines whether the electronic control unit was able to output the control command values ​​that satisfy predetermined standards, and determines whether the vehicle control software needs to be updated based on the determination result.

3. A software update system as described in claim 1, wherein the vehicle control software includes software that causes the electronic control unit to perform automatic driving control of the vehicle, and the monitoring unit monitors the operating status using the automatic emergency braking of the vehicle or braking operation by the driver of the vehicle as the alternative control means.

4. A software update system as described in claim 1, wherein the vehicle control software includes software that causes the electronic control unit to output an alarm in response to the vehicle's departure from its driving lane, and the monitoring unit monitors the operating status using steering operations by the driver of the vehicle as the alternative control means.

5. A software update system as described in claim 1, wherein the vehicle control software includes software that causes the electronic control unit to output an alarm when the vehicle approaches a preceding vehicle or a notification when the preceding vehicle starts moving, and the monitoring unit monitors the operating status using brake pedal operation or accelerator pedal operation by the driver of the vehicle as the alternative control means.

6. A software update system as described in claim 1, wherein, when the update necessity determination unit determines that an update of the vehicle control software is necessary, the distribution unit determines whether the update software is available, distributes the update software if the update software is available, and does not distribute the update software if the update software is not available.

7. A software update system as described in claim 1, comprising an update necessity management unit that manages the results of the update necessity determination unit's determination of whether or not the vehicle control software needs to be updated, and when there are multiple pieces of vehicle control software that have been determined by the update necessity determination unit to need to be updated, the update necessity management unit sets update priorities for each of the multiple pieces of vehicle control software.

8. A software update system as described in claim 7, wherein the update necessity management unit sets the update priority based on at least one of the frequency of operation of the alternative control means, the frequency of accidents, and the frequency of user complaints.

9. A software update system as described in claim 1, comprising an update necessity management unit that manages the results of the update necessity determination unit's determination of whether the vehicle control software needs to be updated, and the update necessity management unit sets information on whether the vehicle control software can be continued to be used based on at least one of the frequency of operation of the alternative control means and the frequency of accidents.

10. A software update system as described in claim 9, wherein the distribution unit distributes a rollback version of the vehicle control software that is usable in the electronic control unit to the vehicle when it is determined that the vehicle control software cannot be continued to be used.

11. A device for determining whether vehicle control software executed by an electronic control unit mounted on a vehicle and controlling the vehicle needs to be updated, the device comprising: a log storage unit that stores a log of the vehicle control software acquired in the vehicle for a determination period from the time of operation of an alternative control means that controls the vehicle in place of the electronic control unit to a predetermined time before the operation of the alternative control means when the alternative control means operates; and an update necessity determination unit that determines whether the vehicle control software needs to be updated based on the log.

Images