Software update system and update necessity determination device

The system rapidly updates vehicle control software by monitoring alternative control means and analyzing logs to determine update needs, addressing false detections and user complaints, enhancing user convenience.

JP2026028625APending Publication Date: 2026-02-20ASTEMO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024131198
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-08-07
Publication Date
2026-02-20

AI Technical Summary

Technical Problem

Existing software update systems for vehicle control software fail to quickly address software improvements needed due to false detections and user complaints, leading to delayed updates and reduced user convenience.

Method used

A system that includes a monitoring unit to log the operation status of alternative control means and vehicle control software, an update necessity determination unit to analyze logs for update requirements, and a distribution unit to distribute updates when necessary, enabling rapid software updates based on real-time data.

Benefits of technology

Enables quick implementation of software updates when improvements are needed, reducing false alarms and improving user convenience by proactively addressing software issues.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026028625000001_ABST
    Figure 2026028625000001_ABST
Patent Text Reader

Abstract

To quickly update vehicle control software used for controlling a vehicle when an event requiring improvement occurs.SOLUTION: 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 an operation status of an alternative control means that controls 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. The update necessity determination unit 31 determines the necessity of updating the vehicle control software based on the log acquired by the monitoring unit 61. When the update necessity determination unit 31 determines that the update of the vehicle control software is necessary, the distribution unit 11 distributes the update software for updating the vehicle control software to the vehicle.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[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. [Background technology]

[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 the vehicle control functions. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-12834 Summary of the Invention [Problem to be solved by the invention]

[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. [Means for solving the problem]

[0010] The software update system according to the present invention updates vehicle control software that is executed by an electronic control device mounted on a vehicle and controls the vehicle, and includes 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. The update necessity determination device according to the present invention is a device that determines whether vehicle control software executed by an electronic control unit mounted on a vehicle and controlling the vehicle needs to be updated, and is equipped with a log storage unit that stores a log of the vehicle control software for a determination period from the time of operation of the alternative control means that controls the vehicle in place of the electronic control unit when the alternative control means operates, the determination period being from the time of operation of the alternative control means acquired in the vehicle to a predetermined time before that, and an update necessity determination unit that determines whether the vehicle control software needs to be updated based on the log. [Effects of the Invention]

[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. [Brief explanation of the drawings]

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

[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] Figure 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 Figure 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 has 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 made 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, software development server 2, and update necessity determination server 3 may be configured as separate server devices. In this case, the software distribution management server 1, software development server 2, and 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, software development server 2, and 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 controls the autonomous driving of the vehicle by executing an autonomous driving system 41, which is a type of vehicle control software. The autonomous driving system 41 calculates control command values ​​related to the amount of acceleration / deceleration and steering amount 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 amount of acceleration / deceleration and steering amount 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 automatic 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 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 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 when the vehicle deviates from its driving lane, approaches a preceding vehicle, or is delayed 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 a user 9, who is the driver of the vehicle, or a control command value from the autonomous 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 autonomous 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 autonomous 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 monitoring unit 61 sets a predetermined period of time that includes at least a period before the alternative control means starts operating as a log acquisition period, and acquires input logs and operation logs of the vehicle control software and the alternative control means during this log acquisition period. 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 from the radar 81 or the camera 82 to the autonomous driving ECU 4, and, as an operation log, the results of calculations of the acceleration / deceleration amount and the steering amount by the autonomous driving system 41. Furthermore, in the case of the preceding vehicle approach warning 52 or the preceding vehicle departure notification 54, the monitoring unit 61 acquires, as an input log, external environment information input from the radar 81 or the camera 82 to the ADAS_ECU 5, and, as an operation log, the results of estimations of the positional relationship between the host vehicle and the preceding vehicle based on the preceding vehicle approach warning 52 or the preceding vehicle departure notification 54. Similarly, in the case of the driving lane departure warning 53, the monitoring unit 61 acquires, as an input log, external environment information input from the camera 82 to the ADAS_ECU 5, and, as an operation log, the results of estimations of deviation from the driving lane based on the driving lane departure warning 53.

[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 an automatic emergency brake 51 operating as an alternative control means for the automatic driving system 41, external information input from a radar 81 or a camera 82 to the ADAS_ECU 5 is acquired as an input log, and the operation state of the automatic emergency brake 51 is acquired as an operation log. For example, when a brake pedal 85 is operated by a user 9 as an alternative control means for the automatic driving system 41 or a 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 state by the brake ECU 73 as an operation log. Similarly, for example, when a steering wheel 84 is operated by a user 9 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 state 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 state 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] 2 is a diagram showing the hardware configuration of the server device and the electronic control device. 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. 2(a). 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. 2(b).

[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 CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), and can implement each functional block of the software distribution management server 1, the software development server 2, and the update necessity determination server 3 shown in FIG. 1 by executing programs stored in the memory 102. That is, the distribution unit 11 in the software distribution management server 1, the development software management unit 21 in the software development server 2, the update necessity determination unit 31 and the update necessity management unit 32 in the update necessity determination server 3, and the like are implemented by the processing of the processor 101. The memory 102 is, for example, a semiconductor storage device such as a RAM (Random Access Memory), 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 an HDD (Hard Disk Drive) or an SSD (Solid State Drive), 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 necessary.

[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, a GPU, an FPGA, etc., and can realize each of the functional blocks in FIG. 1 that the autonomous driving ECU 4, the ADAS_ECU 5, and the communication ECU 6 each have by executing programs such as vehicle control software stored in the memory 202. The memory 202 is, for example, a semiconductor storage device such as a RAM, and temporarily stores programs that are 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 the 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 CAN (Controller Area Network) or various external networks such as the Internet or a wireless communication network.

[0040] It should be noted that other electronic control devices 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 processing 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. In the communication ECU 6, the monitoring unit 61 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 that 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 to be 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 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 deterioration in the driving experience of the user riding in the vehicle. Therefore, if a situation corresponding to one of the combinations shown in 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 the correspondence 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 release 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 the autonomous driving system 41, the monitoring unit 61 monitors the operation status of the autonomous emergency brake 51 and the driver's operation of the brake pedal 85 as alternative control means, based on a 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 the driving lane departure warning 53, the monitoring unit 61 monitors the operation status of the driver's steering operation, i.e., the 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 departure 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. As a result, it is 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] Fig. 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 or not the alternative control means corresponding to the vehicle control software determined to be in operation in step S611 has operated. If it has operated, the process proceeds to step S613, and if it has not operated, 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 on behalf 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 prior to 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 it 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. As a result, if it is determined that an update is necessary, the process proceeds to step S315, and 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 surrounding 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 a predetermined standard, 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. 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 standard, and determines that an update of the autonomous driving system 41 is unnecessary. 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 autonomous driving ECU 4 was unable to output control command values ​​that satisfy the specified criteria, and it is determined that the autonomous driving system 41 needs to be updated.

[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 user 9 operates the accelerator pedal 83, the steering wheel 84, or the brake pedal 85 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 estimation result of the positional relationship between the vehicle and the preceding vehicle indicated by the operation log of the preceding vehicle approach warning 52 and the preceding vehicle departure notification 54 is compared with the external environment information indicated by these input logs, and if an estimation result that matches the external environment information is obtained, it is determined that the ADAS_ECU 5 was able to output an alarm or notification that matches the vehicle situation, and it is determined that there is no need to update the preceding vehicle approach warning 52 or the preceding vehicle departure notification 54. Also, for example, the estimation result of deviation from the driving lane indicated by the operation log of the driving lane departure warning 53 is compared with the external environment information indicated by the input log of the driving lane departure warning 53, and if an estimation result that matches the external environment information is obtained, it is determined that the ADAS_ECU 5 was able to output an alarm that matches the vehicle situation, and it is determined 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 not possible 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 activated, 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 using 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 log of the vehicle control software 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, whether continued use is 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, for example, based on 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 every predetermined processing cycle. 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 among the 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 highest priority is given to the vehicle control software with the highest number.

[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 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 actions, 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 other information may be used to set the update priority. For example, the update priority may be set by excluding any one of the items of the number of accidents, the number of user complaints, and the number of alternative control operations, or the update priority 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 / or the number of accidents among 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 of 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 of 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 operations 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, and 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 among them. On the other hand, if all of the vehicle control software have been selected, the process proceeds to step S3236, where the continued use eligibility determination process ends.

[0083] By executing the above-described continued use 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, with safety in mind, 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] Fig. 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 in the software development server 2, the development software management unit 21 can manage the development status of update software to be used for updating each piece of 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 has the following items set for each vehicle control software determined to require updating: 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 updating 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 not be included, or other items may be included.

[0086] Fig. 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 vehicle control software that has already been developed. 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. Then, the process 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 confirmed whether the update-required version of the vehicle control software acquired in step S111 can be continuously used. Here, it can be determined whether the vehicle control software can be continuously used, for example, 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, and 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 vehicle control software of the rollback version provided by the software development server 2 to the vehicle. Then, the process proceeds to step S117. The vehicle control software of the rollback version 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 to the vehicle control software is required. As a result, if update software is available, the distribution unit 11 distributes the update software, and if update software is not available, the distribution unit 11 does 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 that is executed by an electronic control unit 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 a rapid software update when an event 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. A monitoring unit 61 monitors the operating status of the autonomous driving system 41, based on a correspondence table 61A in FIG. 3 , using an automatic emergency brake 51 of the vehicle or a brake operation by a 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 an 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 in 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 departure 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 an 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 there is update software (step S113), and if there is update software (step S113: Yes), distributes the update software (step S114). On the other hand, if there is no update software (step S113: No), the distribution unit 11 does not distribute the update software. In this manner, the distribution unit 11 can appropriately distribute the update software depending on whether or not there is update software.

[0100] (5) The software update system 100 includes an update necessity management unit 32 that manages the results of the determination made 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 operation frequency 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, it is possible to set appropriate update priorities 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 on 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 makes it possible to appropriately determine, with safety in mind, 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 update is available.

[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 storage device such as a flash memory, HDD, or SSD, or on a virtualization server such as the 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. [Explanation of symbols]

[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...Autonomous emergency braking, 52...Leading vehicle approach warning, 53...Driving lane departure warning, 54...Leading 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 for updating vehicle control software that is executed by an electronic control device mounted on a vehicle and controls the vehicle, comprising: 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 point in time before the alternative control means starts operating; an update necessity determination unit that determines whether or not the vehicle control software needs to be updated based on the log acquired by the monitoring unit; a distribution unit that distributes update software for updating the vehicle control software to the vehicle when the update necessity determination unit determines that the vehicle control software needs to be updated. Software update system.

2. 2. The software update system of claim 1, the vehicle control software includes software that causes the electronic control unit to output a control command value for the vehicle based on information about the environment outside the vehicle; The update necessity determination unit determines whether the electronic control unit was able to output the control command value that satisfies a predetermined standard, and determines whether the vehicle control software needs to be updated based on the determination result. Software update system.

3. 2. The software update system of claim 1, the vehicle control software includes software that causes the electronic control unit to perform automatic driving control of the vehicle, The monitoring unit monitors the operating status of the vehicle using an automatic emergency brake or a brake operation by a driver of the vehicle as the alternative control means. Software update system.

4. 2. The software update system of claim 1, the vehicle control software includes software that causes the electronic control unit to output an alarm when the vehicle deviates from a driving lane, The monitoring unit monitors the operating status of the vehicle using a steering operation by a driver as the alternative control means. Software update system.

5. 2. The software update system of claim 1, the vehicle control software includes software that causes the electronic control device to output a warning when the vehicle approaches a leading vehicle or a notification when the leading vehicle starts moving, The monitoring unit monitors the operating status using a brake pedal operation or an accelerator pedal operation by a driver of the vehicle as the alternative control means. Software update system.

6. 2. The software update system of claim 1, When the update necessity determination unit determines that the vehicle control software needs to be updated, the distribution unit determines whether or not the update software is available, and distributes the update software if the update software is available, and does not distribute the update software if the update software is not available. Software update system.

7. 2. The software update system of claim 1, an update necessity management unit that manages a result of the determination by the update necessity determination unit as to whether or not the vehicle control software needs to be updated; When there are a plurality of pieces of vehicle control software determined by the update necessity determination unit to require updating, the update necessity management unit sets update priorities for each of the plurality of pieces of vehicle control software. Software update system.

8. 8. The software update system of claim 7, The update necessity management unit sets the update priority based on at least one of the operation frequency of the alternative control means, the accident frequency, and the user complaint frequency. Software update system.

9. 2. The software update system of claim 1, an update necessity management unit that manages a result of the determination by the update necessity determination unit as to whether or not the vehicle control software needs to be updated; The update necessity management unit sets information on whether or not the vehicle control software can be continuously used based on at least one of an operation occurrence frequency of the alternative control means and an accident occurrence frequency. Software update system.

10. 10. The software update system of claim 9, When it is determined that the vehicle control software cannot be continuously used, the distribution unit distributes a rollback version of the vehicle control software that can be used in the electronic control unit to the vehicle. Software update system.

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, a log storage unit that stores a log of the vehicle control software during a determination period from the time when the alternative control unit that controls the vehicle in place of the electronic control unit is activated to a predetermined time before the time when the alternative control unit is activated, the log being acquired by the vehicle; an update necessity determination unit that determines whether or not the vehicle control software needs to be updated based on the log. Update necessity determination device.

Citation Information

Patent Citations

  • Software update device, method, program and vehicle

    JP2022012834A