Software update system, software update device, software update method, and program

The software update system addresses sync issues between display and update devices by implementing a user consent verification and limited retries, ensuring efficient and battery-conserving updates.

JP7868201B1Active Publication Date: 2026-06-01HONDA MOTOR CO LTD

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
HONDA MOTOR CO LTD
Filing Date
2025-01-27
Publication Date
2026-06-01

AI Technical Summary

Technical Problem

Existing software update systems for vehicles face issues where the display device and software update device can become out of sync, leading to continuous retries and prolonged power consumption, which significantly depletes the vehicle's battery without proper shutdown.

Method used

A software update system that includes a permission confirmation unit to verify user consent within a predetermined time, displaying a shutdown notification if no response is received, and executing shutdown after a limited number of retries to prevent continuous power consumption.

Benefits of technology

This system ensures efficient software updates by preventing continuous retries and battery drain by ensuring timely shutdown of the software update device and connected display devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007868201000001_ABST
    Figure 0007868201000001_ABST
Patent Text Reader

Abstract

The present invention provides a software update system, a software update device, a software update method, and a program. [Solution] In the software update system 10, if the confirmation process is not completed within a predetermined time, the update processing unit 28 provided in the vehicle will not execute the software update process, but will instead have the display control unit 40 display a shutdown notification screen and then execute a shutdown. If no response is received from the display control unit 40 to the request to display the shutdown notification screen, the system will repeat a predetermined number of retries before executing a shutdown.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to a software update system, a software update device, a software update method, and a program.

Background Art

[0002] Japanese Patent Application Laid-Open No. 2011-40912 discloses an in-vehicle network device that rewrites a rewritable program of an arithmetic device connected to a network.

Prior Art Document

Patent Document

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] It is desired to suitably perform software updates.

[0005] The present disclosure aims to solve the above-described problems.

Means for Solving the Problems

[0006] A first aspect of the present disclosure is a software update system comprising a vehicle and a server device capable of communicating with the vehicle via a network, the system comprising: a permission confirmation unit that performs a confirmation process to confirm with the user whether or not to permit the execution of a software update process on an electronic control device provided in the vehicle; and an update processing unit that executes the software update process if the execution of the software update process is permitted by the user, wherein if the confirmation process is not completed within a predetermined time, the update processing unit does not execute the software update process, causes a display control unit to display a shutdown notification screen, and then executes a shutdown, and if no response is received from the display control unit to the request to display the shutdown notification screen, the update processing unit repeats a predetermined number of retries before executing the shutdown.

[0007] A second aspect of the present disclosure is a software update system comprising a vehicle and a server device capable of communicating with the vehicle via a network, the system comprising: a permission confirmation unit that performs a confirmation process to confirm with the user whether or not to permit the execution of a software update process on an electronic control device provided in the vehicle; and an update processing unit that executes the software update process if the execution of the software update process is permitted by the user, wherein the update processing unit does not execute the software update process and performs a shutdown without causing the display control unit to display a shutdown notification screen if the confirmation process is not completed within a predetermined time.

[0008] A third aspect of this disclosure is a software update device in a software update system according to the first or second aspect, comprising the license confirmation unit and the update processing unit.

[0009] A fourth aspect of the present disclosure is a software update method for performing data communication between a server device and a vehicle via a network, comprising: a permission confirmation step for performing a confirmation process to confirm with a user whether or not to permit the execution of a software update process on an electronic control device provided in the vehicle; and an update process step for performing the software update process if the execution of the software update process is permitted by the user, wherein in the update process step, if the confirmation process is not completed within a predetermined time, the software update process is not performed, and a shutdown is performed after causing the display control unit to display a shutdown notification screen; and if no response is received from the display control unit to the request to display the shutdown notification screen, the update process step repeats a predetermined number of retries before performing the shutdown.

[0010] A fifth aspect of this disclosure is a program that causes a computer to execute the software update method of the fourth aspect. [Effects of the Invention]

[0011] According to this disclosure, software updates can be performed appropriately. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 is a schematic diagram illustrating a software update system. [Figure 2] Figure 2 is a flowchart of the software update process performed by the software update system. [Figure 3] Figure 3 is a flowchart of the first process performed by the software update device from IG-OFF to IG-ON (READY). [Figure 4] Figure 4 is a time chart showing the status of the switch, IVI, software update device, timer, and MID. [Figure 5]Figure 5 is a flowchart of the second process performed by the software update device between IG-OFF and IG-ON (READY). [Modes for carrying out the invention]

[0013] Traditionally, software updates for the Electronic Control Unit (ECU) installed in vehicles were performed at dealerships or similar locations. In recent years, vehicles capable of ECU software updates via over-the-air (OTA) wireless communication have become commercially available. Such vehicles allow for ECU software updates without the need to bring them to a dealership or similar location.

[0014] For example, a vehicle is equipped with a software update device and a display device that perform software update processing. During the software update process, the software update device displays a screen related to the software update process on the display device. However, if the display device and the software update device become out of sync, the display device will no longer respond to the display request from the software update device. In this case, the software update device will repeatedly retry the display request. If the software update device continues to retry until it receives a response from the display device just before shutting down, it will not be able to shut down. In this case, power will continue to be supplied to devices whose power supply is cut off when the software update device shuts down. As a result, the remaining capacity of the battery installed in the vehicle will decrease significantly. In contrast, according to the present disclosure described below, it is possible to suppress the decrease in the remaining capacity of the battery installed in the vehicle.

[0015] [1. Configuration of Software Update System 10] Figure 1 is a schematic diagram showing a software update system 10 according to the first embodiment. The software update system 10 comprises a vehicle 12 and a server device 14. The server device 14 can communicate with the vehicle 12 via a network 16.

[0016] Vehicle 12 is equipped with multiple ECUs 18. Each ECU 18 performs control to realize the driving function and other functions of vehicle 12. Each ECU 18 has an arithmetic unit 20 and a storage unit 22. The arithmetic unit 20 is a processor such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). At least a portion of the arithmetic unit 20 may be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array). At least a portion of the arithmetic unit 20 may be implemented by an electronic circuit including discrete devices.

[0017] The storage unit 22 is a computer-readable, non-transient, tangible storage medium. The storage unit 22 is composed of volatile memory (not shown) and non-volatile memory (not shown). The volatile memory is, for example, RAM (Random Access Memory). The non-volatile memory is, for example, ROM (Read Only Memory), flash memory, etc. Data is stored in the volatile memory, for example. Programs, tables, maps, etc. are stored in the non-volatile memory, for example. At least a portion of the storage unit 22 may be provided in the processor, integrated circuit, etc. mentioned above. At least a portion of the storage unit 22 may be mounted on equipment connected to the vehicle 12 by a network 16.

[0018] Each ECU18 is connected to a CAN (Controller Area Network) (registered trademark). Each ECU18 can communicate with each other via CAN. Note that the communication line connecting each ECU18 is not limited to CAN; Ethernet (registered trademark) may also be used, or both CAN and Ethernet may be used. Furthermore, communication lines of other standards besides CAN and Ethernet may also be used.

[0019] The plurality of ECUs 18 includes a software update device 18a and a Telematics Control Unit (hereinafter referred to as TCU) 18b.

[0020] The software update device 18a can be constituted by, for example, a CGW-ECU (Central GateWay-Electronic Control Unit). The software update device 18a has an arithmetic unit 20a and a storage unit 22a. The arithmetic unit 20a has a configuration synchronization response unit 24, a campaign information acquisition unit 26, an update processing unit 28, and a permission confirmation unit 30. The configuration synchronization response unit 24, the campaign information acquisition unit 26, the update processing unit 28, and the permission confirmation unit 30 are realized by a program stored in the storage unit 22a being executed in the arithmetic unit 20a. At least a part of the configuration synchronization response unit 24, the campaign information acquisition unit 26, the update processing unit 28, and the permission confirmation unit 30 may be realized by an integrated circuit such as an ASIC or an FPGA. At least a part of the configuration synchronization response unit 24, the campaign information acquisition unit 26, the update processing unit 28, and the permission confirmation unit 30 may be realized by an electronic circuit including discrete devices.

[0021] The software update device 18a performs software update processing for the ECU 18 (including the software update device 18a). The software update processing includes software download processing, software installation processing, software activation processing, and complete processing.

[0022] The software download processing includes the process of acquiring update data transmitted from the server device 14 via the network 16 and storing it in the storage unit 22a of the software update device 18a. The update data is data including a program of the software after update. The update data may include an installer or the like.

[0023] The software installation process includes the process of deploying the update data from the storage unit 22a to the ROM of the ECU 18. The software installation process may be performed by an installer. The software installation process may also be performed by copying the update data to the ROM.

[0024] The software activation process includes the authentication of the license for the installed software. During the software activation process, executable files and other files used by the software before the update may be rewritten. Once the software activation process is complete, the execution of the software on the ECU18 is permitted. The activation process may be performed by the software update device 18a or by another ECU18.

[0025] The completion process includes post-update processing for the software update. For example, the completion process includes uploading a result log to the server device 14 and notifying the user that the software update is complete. The result log includes information such as whether the software update for the ECU 18 was successful, and the time when the activation process was completed.

[0026] The configuration synchronization response unit 24 transmits configuration synchronization information to the server device 14 in response to a configuration synchronization request sent from the server device 14. The campaign information acquisition unit 26 acquires campaign information, which is information related to the software update process, from the server device 14 and stores the campaign information in the storage unit 22a. The update processing unit 28 executes the software update process on the ECU 18 equipped with the software to be updated. The permission confirmation unit 30 performs a confirmation process to ask the user whether or not to permit the execution of the software update process on the ECU 18.

[0027] The software update device 18a can communicate with a base station 32 connected to the network 16 via cellular communication through the TCU 18b. The network 16 is, for example, the internet.

[0028] An in-vehicle infotainment (IVI) 34 is connected to the software update device 18a. The IVI 34 has an arithmetic unit 36 ​​and a storage unit 38. The arithmetic unit 36 ​​is, for example, a processor such as a CPU or GPU. The arithmetic unit 36 ​​has a display control unit 40 and a reset control unit 42. The display control unit 40 and the reset control unit 42 are realized by the execution of a program stored in the storage unit 38 in the arithmetic unit 36. The display control unit 40 and the reset control unit 42 may be realized by integrated circuits such as ASICs or FPGAs. The display control unit 40 and the reset control unit 42 may also be realized by electronic circuits including discrete devices.

[0029] The display control unit 40 performs display control for various screens. The reset control unit 42 performs reset control to return the IVI 34 to its factory default state if a malfunction occurs in the processing performed by the calculation unit 36.

[0030] The storage unit 38 is a computer-readable, non-transient, tangible storage medium. The storage unit 38 is composed of volatile memory (not shown) and non-volatile memory (not shown). The volatile memory is, for example, RAM. The non-volatile memory is, for example, ROM, flash memory, etc. Data is stored, for example, in the volatile memory. Programs, tables, maps, etc. are stored, for example, in the non-volatile memory. At least a portion of the storage unit 38 may be provided in the processor, integrated circuit, etc. described above. At least a portion of the storage unit 38 may be mounted on equipment connected to the vehicle 12 by a network 16.

[0031] IVI34 provides information such as route guidance and road traffic information, as well as entertainment such as audio, DVD, and TV tuner. IVI34 is composed of, for example, a display audio system.

[0032] The IVI34 has a display unit 44. The display unit 44 is installed on the dashboard of the vehicle 12 or the like. The display unit 44 is a touch panel display. The display unit 44 provides information to the user through images, text, etc., and accepts user input. The screen of the display unit 44 is liquid crystal, organic electroluminescence (organic EL), etc., and is not particularly limited. The touch panel of the display unit 44 is resistive, capacitive, etc., and is not particularly limited. Instead of the display unit 44 which is a touch panel display, a combination of a display device such as a head-up display and a pointing device such as motion capture may be used.

[0033] A multi-information display (MID) 46 is connected to the software update device 18a. The MID 46 has an arithmetic unit 48 and a storage unit 50. The arithmetic unit 48 is, for example, a processor such as a CPU or GPU.

[0034] The storage unit 50 is a computer-readable, non-transient, tangible storage medium. The storage unit 50 is composed of a volatile memory (not shown) and a non-volatile memory (not shown). The volatile memory is, for example, RAM. The non-volatile memory is, for example, ROM, flash memory, etc. Data is stored in the volatile memory, for example. Programs, tables, maps, etc. are stored in the non-volatile memory, for example. At least a part of the storage unit 50 may be provided in the processor, integrated circuit, etc. described above.

[0035] The MID46 provides information related to the vehicle's operation, such as vehicle speed, engine speed, motor speed, mileage, battery capacity, and various warning lights. The MID46 is composed of, for example, a digital meter.

[0036] The MID46 has a display unit 52. The display unit 52 is installed on the dashboard of the vehicle 12 or the like. The display unit 52 provides information to the user through images, text, etc. The screen of the display unit 52 is liquid crystal, organic electroluminescence (organic EL), etc., and is not particularly limited.

[0037] Vehicle 12 is equipped with a start-stop switch (hereinafter referred to as the switch) 54. The power mode of vehicle 12 can be switched by operating the switch 54. If vehicle 12 is an engine vehicle, the power modes include OFF mode, ACC mode, ON mode, and START mode. If vehicle 12 is a hybrid vehicle or an electric vehicle, the power modes include OFF mode, ACC mode, and READY mode.

[0038] OFF mode is when the power to vehicle 12 is OFF. In OFF mode, most of the equipment in vehicle 12 cannot be used. Even in OFF mode, the keyless entry system, etc., can be used. The state of switch 54 when in OFF mode is sometimes referred to as IG-OFF or ACC-OFF. In ACC mode, equipment such as the audio system can be used. The state of switch 54 when in ACC mode is sometimes referred to as IG-OFF or ACC-ON. In ON mode, all of the equipment in vehicle 12 can be used. The state of switch 54 when in ON mode is sometimes referred to as IG-ON. START mode is when the engine is started, and after the engine has started, vehicle 12 can be driven. READY mode is when vehicle 12 can be driven by the drive motor. The state of switch 54 when in READY mode is sometimes referred to as READY.

[0039] When switch 54 is in the IG-OFF state, it corresponds to the start switch of the present invention being in the OFF state. When switch 54 is in the IG-ON (or READY) state, it corresponds to the start switch of the present invention being in the ON state.

[0040] Vehicle 12 is equipped with a shift position sensor 56. The shift position sensor 56 detects the shift position selected by the user.

[0041] The server device 14 has an arithmetic unit 58 and a storage unit 60. The arithmetic unit 58 is, for example, a processor such as a CPU or GPU. The arithmetic unit 58 has an information acquisition unit 62 and a transmission processing unit 64. The information acquisition unit 62 and the transmission processing unit 64 are realized by the execution of a program stored in the storage unit 60 in the arithmetic unit 58. At least a part of the information acquisition unit 62 and the transmission processing unit 64 may be realized by an integrated circuit such as an ASIC or FPGA. At least a part of the information acquisition unit 62 and the transmission processing unit 64 may be realized by an electronic circuit including discrete devices.

[0042] The storage unit 60 is a computer-readable, non-transient, tangible storage medium. The storage unit 60 is composed of volatile memory (not shown) and non-volatile memory (not shown). The volatile memory is, for example, RAM. The non-volatile memory is, for example, ROM, flash memory, etc. Data is stored, for example, in the volatile memory. Programs, tables, maps, etc. are stored, for example, in the non-volatile memory. At least a portion of the storage unit 60 may be provided in the processor, integrated circuit, etc., as described above. At least a portion of the storage unit 60 may be mounted on equipment connected to the server device 14 by a network 16.

[0043] Multiple vehicles 12 are registered in the server device 14, and the server device 14 manages the software update status of the ECU 18 of each vehicle 12. The server device 14 provides update data to each vehicle 12 for updating the software of the ECU 18 of each vehicle 12.

[0044] [2. Software update process performed by the software update system 10] Figure 2 is a flowchart of the software update process performed by the software update system 10. Figure 2 will be used to explain the overview of the software update process performed by the software update system 10.

[0045] When campaign information is registered in the server device 14 (P1), the transmission processing unit 64 sends a configuration synchronization request to the vehicle 12's software update device 18a (P2). The campaign information, along with update data for updating the ECU 18's software, is registered in the server device 14 by the ECU 18's software developer, the vehicle 12's manufacturer, etc.

[0046] The configuration synchronization response unit 24 of the software update device 18a receives a configuration synchronization request (Q1) and transmits configuration synchronization information to the server device 14 (Q2). The configuration synchronization information includes information on a unique identifier assigned to each ECU 18 of the vehicle 12, information on the software version of each ECU 18, and so on.

[0047] When the information acquisition unit 62 of the server device 14 acquires configuration synchronization information (P3), the transmission processing unit 64 transmits campaign information regarding the software update process of each ECU 18 to the software update device 18a (P4).

[0048] The campaign information acquisition unit 26 of the software update device 18a acquires campaign information (Q3) and stores the campaign information in the storage unit 22a. The update processing unit 28 displays the campaign information on the display unit 44 of the IVI 34. The permission confirmation unit 30 performs a confirmation process to ask the user whether or not to allow the download of the software. In this confirmation process, if the user allows the download of the software (Q4), the update processing unit 28 sends an update data request to the server device 14 (Q5).

[0049] When the information acquisition unit 62 of the server device 14 acquires an update data request (P5), the transmission processing unit 64 transmits the update data to the software update device 18a (P6).

[0050] The update processing unit 28 of the software update device 18a performs the software download process. That is, the update processing unit 28 downloads the software by acquiring update data and storing the update data in the storage unit 22a (Q6). Subsequently, the update processing unit 28 performs the software installation process. That is, the update processing unit 28 expands the update data from the storage unit 22a into the ROM of the ECU 18 and installs the software (Q7).

[0051] When the state of switch 54 switches from IG-ON (or READY) to IG-OFF, and the shift position detected by the shift position sensor 56 is "P", the permission confirmation unit 30 performs a confirmation process to ask the user whether or not to grant permission for downtime. If the user grants permission for downtime in this confirmation process (Q8), the update processing unit 28 performs the software activation process for the ECU 18 (Q9). Downtime refers to the period of time during which the power mode of the vehicle 12 cannot be set to START mode or READY mode, and the vehicle 12 cannot be driven. Once the software activation process is complete, it becomes possible to set the power mode of the vehicle 12 to START mode or READY mode.

[0052] When the software activation process is complete and the state of switch 54 changes from IG-OFF to IG-ON (or READY), the update processing unit 28 executes a completion process (Q10). For example, the update processing unit 28 uploads a result log to the server device 14. The result log includes information such as whether the software update of the ECU 18 was successful and the time when the activation process was completed. The update processing unit 28 also displays a completion notification on the display unit 44 of the IVI 34 indicating that the software update is complete.

[0053] When the information acquisition unit 62 of the server device 14 acquires the result log (P7), the software update is completed.

[0054] [3. Processes performed from IG-OFF to IG-ON (READY)] [3-1 First Processing] Figure 3 is a flowchart of the first process performed by the software update device 18a from IG-OFF to IG-ON (READY). Figure 3 shows the details of the process, including the downtime permission (Q8) and software activation process (Q9) shown in Figure 2.

[0055] The software update device 18a performs the process of step S1 when it detects that the state of switch 54 has switched from IG-ON (or READY) to IG-OFF, and also detects that the shift position detected by the shift position sensor 56 is "P".

[0056] In step S1, the permission confirmation unit 30 performs a confirmation process to ask the user whether or not they consent to downtime occurring. The process in step S1 corresponds to the process shown in Figure 2, Q8. For example, the permission confirmation unit 30 instructs the IVI 34 to display the permission confirmation screen. The permission confirmation unit 30 also measures the waiting time while waiting for a response from the user. The permission confirmation unit 30 starts the confirmation process and simultaneously starts measuring the waiting time using a timer.

[0057] In step S2, the permission confirmation unit 30 determines the response result from the user. For example, the permission confirmation unit 30 obtains the response result from the user from the IVI 34. If the permission confirmation unit 30 obtains a response indicating that the user has permitted the downtime (step S2: permitted), the process proceeds to step S3. On the other hand, if the permission confirmation unit 30 obtains a response indicating that the user has not permitted the downtime (step S2: not permitted), the process proceeds to step S4.

[0058] Incidentally, the verification process regarding downtime may not be completed within a predetermined time (referred to as the first predetermined time). For example, the waiting time may reach the first predetermined time without any response from the user to the verification process. In such cases, the permission verification unit 30 determines that a timeout has occurred. If the permission verification unit 30 determines that the waiting time has exceeded the first predetermined time pre-stored in the storage unit 22a (step S2: no response), the process proceeds to step S4.

[0059] When the process moves from step S2 to step S3, the update processing unit 28 performs activation processing. The processing in step S3 corresponds to the processing Q9 shown in Figure 2. Once the activation processing is completed, the process moves to step S4.

[0060] When the system transitions from step S2 or step S3 to step S4, the update processing unit 28 requests the IVI 34 to display a shutdown notification screen. For example, the update processing unit 28 sends a request signal to the IVI 34 indicating a request to display a shutdown notification screen. The shutdown notification screen is a screen that notifies the user that the software update device 18a will be shut down before it is shut down. The shutdown notification screen is displayed on the IVI 34.

[0061] The display control unit 40 provided in the IVI34 responds to the software update device 18a when it successfully receives a shutdown notification request. For example, the display control unit 40 sends back a signal (ACKknowledgement: hereinafter referred to as ACK) to the software update device 18a indicating that it has successfully received the request signal. However, there are cases in which the display control unit 40 cannot respond to the software update device 18a, as follows.

[0062] If the switch 54 is in the IG-ON or READY state, a malfunction may occur in the processing performed by the IVI 34's arithmetic unit 36. In this case, the reset control unit 42 performs a reset control (initialization) of the IVI 34. If the IVI 34 performs a reset control after the software download process has been completed but before the activation process has been completed, the IVI 34 and the software update device 18a will become out of sync. After the reset control, the IVI 34 transitions to a sleep state approximately a certain period of time after the switch 54 is switched from IG-ON (or READY) to IG-OFF. This period of time is called the sleep transition time. The software update device 18a cannot communicate with the IVI 34 in the sleep state. The shutdown notification request signal from the software update device 18a to the IVI 34 is sent after the sleep transition time or longer has elapsed since the switch 54 was switched from IG-ON (or READY) to IG-OFF. In other words, when the IVI34 is reset, the IVI34 is unable to receive the shutdown notification request signal sent from the software update device 18a. As a result, the display control unit 40 in the IVI34 is unable to send an ACK back to the software update device 18a.

[0063] When the process moves from step S4 to step S5, the update processing unit 28 determines whether or not there is a response (ACK) from the display control unit 40 of the IVI 34 to the request to display the shutdown notification screen. After making a request to the IVI 34 to display the shutdown notification screen in step S4, the update processing unit 28 waits for a response from the IVI 34 for a predetermined time (referred to as the second predetermined time) that is pre-stored in the storage unit 22a. If there is a response from the IVI 34 within the second predetermined time (step S5: YES), the process moves to step S8. In this case, the display control unit 40 provided in the IVI 34 displays the shutdown notification screen on the display unit 44. On the other hand, if there is no response from the IVI 34 within the second predetermined time (step S5: NO), the process moves to step S6.

[0064] When the process moves from step S5 to step S6, the update processing unit 28 compares the number of retries made to the request to display the shutdown notification screen with a predetermined number of retries pre-stored in the storage unit 22a. In this embodiment, the number of retries is, for example, 1, but is not limited to this. Thus, the update processing unit 28 limits the number of retries to a predetermined number. If the number of retries is less than the predetermined number (step S6: NO), the process moves to step S7. On the other hand, if the number of retries is equal to or greater than the predetermined number (step S6: YES), the process moves to step S8.

[0065] When the process moves from step S6 to step S7, the update processing unit 28 increments the retry count by 1. Then, the process returns to step S4. In step S4, the update processing unit 28 retries the request to display the shutdown notification screen.

[0066] When the process moves from step S5 or step S6 to step S8, the update processing unit 28 shuts down the software update device 18a. This completes the series of processes shown in Figure 3. When the software update device 18a is shut down, the update processing unit 28 instructs the MID 46 to turn off. As a result, the MID 46 turns off.

[0067] After the software update device 18a is shut down, the user gets into the vehicle 12 and operates the switch 54. At this time, the state of the switch 54 is switched from IG-OFF to IG-ON (or READY). At this stage, the update processing unit 28 executes the completion process shown in Figure 2.

[0068] Figure 4 is a time chart showing the status of switch 54, IVI 34, software update device 18a, timer, and MID 46. Figure 4 shows the status of switch 54, IVI 34, software update device 18a, timer, and MID 46 in an embodiment in which the reset control unit 42 performs reset control of IVI 34.

[0069] At time t1, the reset control unit 42 provided in the IVI34 executes a reset control for the IVI34. As a result, the IVI34 returns to its initial state.

[0070] At time t2, the user operates switch 54. At this time, the state of switch 54 is switched from IG-ON (or READY) to IG-OFF. At this point, the authorization confirmation unit 30 provided in the software update device 18a starts the confirmation process and also starts measuring the waiting time using a timer (step S1 in Figure 3).

[0071] At time t3, the waiting time measured by the timer reaches the first predetermined time (Step S2 in Figure 3: No response). Then, the update processing unit 28 requests the IVI 34 to display the shutdown notification screen (Step S4 in Figure 3).

[0072] At time t4, the number of retries for the shutdown notification screen display request by the update processing unit 28 exceeds a predetermined number (step S6: YES in Figure 3). At this time, the update processing unit 28 executes the shutdown of the software update device 18a.

[0073] In the first process, the number of retries for the request to display the shutdown notification screen is limited to, for example, one. As a result, even if the IVI 34 does not respond to the display request of the software update device 18a, the software update device 18a can shut down without endlessly repeating the retry of the display request. In addition, the MID 46 can be turned off when the software update device 18a shuts down. Therefore, according to the first process, it is possible to suppress a significant decrease in the remaining capacity of the battery provided in the vehicle 12 due to the MID 46 remaining lit. Thus, according to the first process, the software update can be performed suitably.

[0074] [3-2 Second Processing] Figure 5 is a flowchart of the second process performed by the software update device 18a between IG-OFF and IG-ON (READY). The software update device 18a may perform the second process shown in Figure 5 instead of the first process shown in Figure 3.

[0075] The process in step S11 shown in Figure 5 corresponds to the process in step S1 shown in Figure 3. The process in step S12 shown in Figure 5 corresponds to the process in step S2 shown in Figure 3. The process in step S13 shown in Figure 5 corresponds to the process in step S3 shown in Figure 3. The process in step S14 shown in Figure 5 corresponds to the process in step S8 shown in Figure 3.

[0076] In the second process, no request is made to display the shutdown notification screen. As a result, even if the IVI 34 does not respond to the display request from the software update device 18a, the software update device 18a can shut down without endlessly retrying the display request. In addition, the MID 46 can also be turned off when the software update device 18a shuts down. Therefore, the second process makes it possible to suppress a significant decrease in the remaining capacity of the battery in the vehicle 12 due to the MID 46 remaining lit. Thus, the software update can be performed suitably according to the second process.

[0077] The following additional information is disclosed regarding the above embodiments.

[0078] (Note 1) The software update system (10) of this disclosure is a software update system comprising a vehicle (12) and a server device (14) capable of communicating with the vehicle via a network (16), comprising: a permission confirmation unit (30) that performs a confirmation process to confirm with the user whether or not to permit the execution of a software update process on an electronic control device (18) provided in the vehicle; and an update processing unit (28) that executes the software update process if the execution of the software update process is permitted by the user, wherein if the confirmation process is not completed within a predetermined time, the update processing unit does not execute the software update process, but instead causes a display control unit (40) to display a shutdown notification screen and then executes a shutdown, and if no response is received from the display control unit to the request to display the shutdown notification screen, the update processing unit executes the shutdown after repeating a predetermined number of retries.

[0079] With the above configuration, the electronic control unit (software update device) equipped with an update processing unit can be shut down without endlessly retrying display requests. Furthermore, when the electronic control unit is shut down, the display device connected to the electronic control unit can also be turned off. Therefore, with the above configuration, it is possible to suppress a significant decrease in the remaining capacity of the vehicle's battery caused by the display device remaining lit. In this way, the above configuration allows for efficient software updates.

[0080] (Note 2) The software update system of this disclosure is a software update system comprising a vehicle and a server device capable of communicating with the vehicle via a network, comprising: a permission confirmation unit that performs a confirmation process to confirm with the user whether or not to permit the execution of a software update process on an electronic control device provided in the vehicle; and an update processing unit that executes the software update process if the execution of the software update process is permitted by the user, wherein if the confirmation process is not completed within a predetermined time, the update processing unit does not execute the software update process and executes a shutdown without causing the display control unit to display a shutdown notification screen.

[0081] With the above configuration, the electronic control unit (software update device) equipped with an update processing unit can be shut down without endlessly retrying display requests. Furthermore, when the electronic control unit is shut down, the display device connected to the electronic control unit can also be turned off. Therefore, with the above configuration, it is possible to suppress a significant decrease in the remaining capacity of the vehicle's battery caused by the display device remaining lit. In this way, the above configuration allows for efficient software updates.

[0082] (Note 3) In the software update system described in Appendix 1, the predetermined number of times may be one.

[0083] (Note 4) In the software update system described in Appendix 1 or 2, the shutdown may include the electronic control unit equipped with the update processing unit.

[0084] (Note 5) The software update device of this disclosure is a software update device in the software update system described in Appendix 1 or 2, comprising the license confirmation unit and the update processing unit.

[0085] (Note 6) The software update method of this disclosure is a software update method that performs data communication between a server device and a vehicle via a network, and comprises: a permission confirmation step which performs a confirmation process which asks the user whether or not to permit the execution of a software update process on an electronic control device provided in the vehicle; and an update process step which executes the software update process when the execution of the software update process is permitted by the user, wherein in the update process step, if the confirmation process is not completed within a predetermined time, the software update process is not executed, and the display control unit is ordered to display a shutdown notification screen before the shutdown is executed, and if no response is received from the display control unit to the request to display the shutdown notification screen, the update process step repeats a predetermined number of retries before executing the shutdown.

[0086] (Note 7) The program disclosed herein causes a computer to execute the software update method described in Appendix 6.

[0087] While this disclosure has been described in detail, it is not limited to the individual embodiments described above. These embodiments can be added, replaced, modified, partially deleted, etc., in any way that does not depart from the gist of this disclosure or from the intent of this disclosure derived from the claims and their equivalents. These embodiments can also be implemented in combination. For example, the order of operations and processes in the embodiments described above are given as examples only and are not limited thereto. The same applies when numerical values ​​or mathematical formulas are used in the description of the embodiments described above. [Explanation of symbols]

[0088] 10…Software update system 12…Vehicle 14…Server equipment 16…Network 18...ECU (Electronic Control Unit) 28...Update Processing Unit 30...Permission confirmation unit 40...Display control unit

Claims

1. A software update system comprising a vehicle and a server device capable of communicating with the vehicle via a network, A permission confirmation unit performs a confirmation process to ask the user whether or not to authorize the execution of a software update process for the electronic control unit installed in the vehicle, If the user has authorized the execution of the software update process, an update processing unit that executes the software update process, Equipped with, If the confirmation process is not completed within a predetermined time, the update processing unit will not execute the software update process, but will instead have the display control unit display a shutdown notification screen, and then execute the shutdown of the electronic control unit equipped with the update processing unit. A software update system in which, if no response is received from the display control unit to the request to display the shutdown notification screen, the update processing unit performs the shutdown of the electronic control unit equipped with the update processing unit after repeating a predetermined number of retries.

2. In the software update system according to claim 1, A software update system in which the predetermined number of times is 1.

3. A software update device in the software update system according to claim 1, A software update device comprising the license confirmation unit and the update processing unit.

4. A software update method in which a server device and a vehicle communicate data via a network is performed by a processor, A permission confirmation step involves performing a confirmation process to ask the user whether or not to permit the execution of a software update process for the electronic control unit installed in the vehicle, If the user has authorized the execution of the software update process, the update process step includes executing the software update process, Equipped with, In the update processing step, if the confirmation process is not completed within a predetermined time, the software update process is not executed, and the display control unit is instructed to display a shutdown notification screen, after which the electronic control unit that executes the update processing step is shut down. A software update method in which, if no response is received from the display control unit to the request to display the shutdown notification screen, the update process step repeats a predetermined number of retries and then shuts down the electronic control unit that executes the update process step.

5. A program that causes a computer to execute the software update method described in claim 4.