JP7677030B2 - Software update device, software update system, and software update method - Google Patents

Description

The present invention relates to a software update device, a software update system, and a software update method for updating software.

Conventionally, information processing terminals that can automatically update software at times according to the user's preferences have been known (Patent Document 1). This information processing terminal can also be used as an in-vehicle terminal installed in a vehicle.

JP 2016-38634 A

The above information processing terminal does not take into account the user's consent process for software updates, so even if the user is asked whether to consent to the start of the update process, if there is no response from the user, it is difficult to determine whether the update process should be started.

The problem that the present invention aims to solve is to provide a software update device, a software update system, and a software update method that can prompt a user to agree to the start of a software update process and determine whether or not to start the update process even if there is no response from the user.

The present invention solves the above problem by obtaining update processing information related to software updates for an on-board control device from a server installed outside the vehicle, outputting consent request information that asks the user whether to consent to the start of the update processing, executing the update processing according to response information that is the user's response to the consent request information, and determining whether to start the update processing based on at least one of the time required for the update processing and the importance of updating the software if no response information is input for a predetermined period of time or more after the consent request information is output.

According to the present invention, the user is asked whether or not to consent to the start of the software update process, and even if there is no response from the user, it is possible to determine whether or not to start the update process.

FIG. 1 is a block diagram showing an example of a software updating system including a software updating device according to the first embodiment. FIG. 2 is an explanatory diagram for explaining the flow of a software update via OTA. FIG. 3 is an explanatory diagram for explaining software updating by OTA according to the memory configuration of the ECU. FIG. 4 is an example of a screen displayed on the in-vehicle HMI when requesting the user's consent to start the update process. FIG. 5 is an example of a functional block of the controller 40 of the software updating device 10 shown in FIG. FIG. 6 is a flowchart of the software updating method according to the first embodiment. FIG. 7 is a flowchart of a software updating method according to the second embodiment. FIG. 8 is a flowchart of a software updating method according to the third embodiment.

Below, an embodiment of a software update device, a software update system, and a software update method according to the present invention will be described with reference to the drawings.

First Embodiment
As shown in FIG. 1, the software update device 10 according to the present embodiment is realized as a part of a software update system 100. FIG. 1 is a block diagram showing an example of the software update system 100 according to the present embodiment. The software update system 100 is a system capable of updating software for vehicle control, diagnosis, and the like, executed by an electronic control unit (hereinafter referred to as an ECU (Electronic Control Unit)) of a vehicle 1, over the air (OTA). Updating software by OTA is also called FOTA (Firmware Over The Air). The software of the ECU is realized by a microcomputer included in the ECU executing a program. In the present embodiment, a case where a program executed by a microcomputer of the ECU is rewritten wirelessly as an example of updating the software of the ECU wirelessly will be described. However, the software update system 100 can also be applied to a case where data used in various software, such as map data used in a navigation system of the vehicle 1 and control parameters used in the ECU, are rewritten wirelessly. The software update system 100 can also be applied to cases where an FPGA (Field Programmable Gate Array) is used in the ECU and the function (logic) of the FPGA is rewritten wirelessly. Although one vehicle is illustrated as the vehicle 1 in Fig. 1, the software update system 100 is a system capable of updating software for multiple vehicles 1.

In this embodiment, "ECU software update" means that the version of the ECU software is changed to a new version, that is, the program to be executed by the microcomputer is changed to a new version. In addition, the wireless software update includes not only obtaining the new version of the program itself from outside the vehicle 1 via wireless and rewriting it, but also obtaining various data used when the new version of the program is executed and difference data between the new version of the program and the old version of the program via wireless from outside the vehicle 1 and rewriting it. In the following explanation, data necessary for software update, such as the new version of the program and difference data, is referred to as "update data". Also, the "new version of the program" is referred to as the "new program", the "old version of the program" is referred to as the "old program", and the "difference data between the new version of the program and the old version of the program" is referred to as the "difference data". In this embodiment, "completion" means that something has ended normally, and does not include the end of something due to an abnormal situation. For example, "completion of processing" means that processing has ended normally, and does not include the end of processing abnormally. In this embodiment, the user who performs the software update procedure will be an occupant of vehicle 1 (including the driver).

As shown in FIG. 1, the software update system 100 includes a vehicle 1, a server 2, and a user terminal 3. Each component included in the software update system 100 is capable of sending and receiving information via a wireless communication network 4. The wireless communication network 4 includes, for example, a mobile communication network using a 4G line or the like, the Internet, Wi-Fi (Wireless Fidelity) (registered trademark), and the like. First, the roles of the vehicle 1, the server 2, and the user terminal 3 in the software update system 100 will be described.

Vehicle 1 is equipped with an ECU capable of updating software. Vehicle 1 exchanges various information related to software updates with server 2. Information about each ECU installed in vehicle 1 is transmitted from vehicle 1 to server 2. Information about the ECU includes, for example, the current version of the software. Information about each ECU installed in vehicle 1 is transmitted from vehicle 1 to server 2 based on a predetermined transmission condition (for example, at a predetermined interval).

Information regarding software updates is also transmitted from the server 2 to the vehicle 1. Examples of information regarding software updates include campaign information, update data, an estimate of the time required for the update process, and the importance of the update. A campaign is an event in which the server 2 distributes a distribution package to one or more vehicles 1. The distribution package includes update data, authentication data used in the authentication process of the update data, and the like. The campaign information is information for presenting an overview of the software update to the user. Specific examples of campaign information, an estimate of the time required for the update process, and the importance of the update will be described later. If the user agrees to the start of the software update process, the software update process is executed in the vehicle 1 by the software update device 10 described later. When the update process is started in the vehicle 1, information indicating the progress of the update process is transmitted from the vehicle 1 to the server 2.

Server 2 is a server that manages the software update process in software update system 100 and functions as an OTA center. Server 2 exchanges various information related to the above-mentioned software updates with vehicle 1. Server 2 also exchanges various information with user terminal 3.

The server 2 has a storage function for storing update data, a data management function for managing the version of each software, the vehicle identification number (VIN: Vehicle Identification Number) of the vehicle 1 to be updated, the ECU to be updated, etc., a campaign management function for managing information related to the campaign such as the timing of distribution of campaign information, and a distribution function for distributing campaign information and update data. For example, when the server 2 receives various information including update data from a provider of update data, the server 2 stores the update data in a storage device. Based on the information received from the provider, the server 2 identifies the VIN to which the update data is to be distributed and the ECU to be updated (hereinafter referred to as the ECU to be updated). The server 2 sets the distribution timing of the campaign information, and when the distribution timing of the campaign information arrives, the server 2 transmits the campaign information to the vehicle 1 and/or the user terminal 3. If the user agrees to the transmission of the distribution package to the vehicle 1, the server 2 transmits the distribution package to the vehicle 1. When the update process is started in the vehicle 1 after the server 2 has completed transmission of the distribution package, the server 2 receives progress information indicating the progress of the update process from the vehicle 1 and transmits the received progress information to the user terminal 3.

The user terminal 3 is a terminal that can be carried by a user and has a function of accepting operation input from a user and a function of displaying various screens. Examples of the user terminal 3 include a smartphone and a tablet. The user terminal 3 exchanges various information such as campaign information with the server 2. When the user terminal 3 receives the campaign information from the server 2, it notifies the user of the campaign information. When the user performs an operation on the user terminal 3 indicating consent to the transmission of the distribution package, the user terminal 3 transmits information indicating that the user has consented to the server 2. The user terminal 3 also exchanges information regarding the update process with the vehicle 1 via the server 2. When information for requesting the user to consent to the start of the update process is input from the server 2, the user terminal 3 displays an image for requesting consent from the user. When the user performs an operation on the user terminal 3 indicating consent to the start of the update process, the user terminal 3 transmits consent information indicating that the user has consented to the server 2. When the update process is started in the vehicle 1, the user terminal 3 receives progress information indicating the progress of the update process from the server 2 and notifies the user of the received progress information.

Next, the configuration of the vehicle 1, the server 2, and the user terminal 3 will be described with reference to FIG. 1. First, the configuration of the server 2 will be described. As shown in FIG. 1, the server 2 includes a communication device 21, a database 22, and a control device 23.

The communication device 21 has a communication function for performing data communication between the vehicle 1 and the user terminal 3 via the wireless communication network 4. In order for the communication device 21 to transmit and receive data between the vehicle 1, the vehicle 1 needs to be located within the range of the wireless communication network 4. In addition, in order for the communication device 21 to transmit and receive data between the user terminal 3, the user terminal 3 needs to be located within the range of the wireless communication network 4.

The database 22 stores the registration information of the vehicle 1, campaign information, update data, etc. The registration information of the vehicle 1 includes at least the VIN of the vehicle 1, the number of ECUs installed in the vehicle 1 and the type of each ECU, and the software version of each ECU. The campaign information includes the data size of the update data, information identifying the ECU to be updated (ECU name, ECU ID, etc.), information on the version of the software to be updated (version name, version ID, etc.), a brief description of the functions to be updated, the estimated time until the download of the distribution package is completed (estimated download time), and the estimated time until the update process in the vehicle 1 is completed (estimated update process time), etc.

The control device 23 is a device that functions as the command center of the server 2, and is composed of, for example, a processor and memory programmed to execute one or more functions embodied in a computer program. The control device 23 has the above-mentioned data management function, campaign management function, distribution function, etc. In this embodiment, as examples of the functions of the control device 23, a function for calculating an estimated update processing time and a function for calculating the importance of an update will be described.

The control device 23 calculates the estimated update processing time based on the data size of the update data. As described below, while the update processing is being performed on the ECU to be updated (including the period from when the ECU to be updated stops operating under the old program to when it starts up normally under the new program), the ECU to be updated cannot execute software functions. For this reason, the estimated update processing time is also referred to as downtime, as it is the time during which the functions of the vehicle 1 cannot be used.

For example, if a map showing the relationship between the data size of the update data and the estimated update processing time is stored in advance in the database 22, the control device 23 refers to the map and calculates the estimated update processing time according to the data size. Also, for example, the larger the data size of the update data, the longer the estimated update processing time calculated by the control device 23. Note that the data size of the update data may be either the data size of the new program itself or the data size of the difference data. Also, the method of calculating the estimated update processing time is one example, and the control device 23 may calculate the estimated update processing time using other calculation methods.

The control device 23 also calculates the importance of the update based on the type of the ECU to be updated. The importance of the update is based on at least one of the indices of the running of the vehicle 1 and the security of the vehicle 1. An example of the importance based on the indices of the running of the vehicle 1 is ASIL (Automotive Safety Integrity Level). ASIL is an index that specifies the safety requirements and safety measures of an automobile, as stipulated in IEC61508/ISO2626, which is a standard for the functional safety of the vehicle 1. ASIL has four safety levels, and the highest safety standards are ASIL-D, ASIL-C, ASIL-B, and ASIL-A. Some or all of the ECUs installed in the vehicle 1 are assigned an ASIL rank in advance. An example of the importance based on the indices of the security of the vehicle 1 is the urgency (priority) of the security patch. A security patch is a file for correcting vulnerabilities or security holes that may cause some security problems when they are found. The importance of the update calculated by the control device 23 includes the ASIL rank and the urgency of the security patch, as described above. Note that if a standardized security rank, similar to the ASIL, is assigned to one or all of the ECUs mounted on the vehicle 1, the control device 23 may use the standardized security rank as the importance of the update.

For example, when the control device 23 receives information indicating the urgency of the update together with the update data from the provider of the update data, the control device 23 calculates the importance of the update to be higher than when the information indicating the urgency of the update is not received. Also, for example, when the ECU to be updated is an ECU involved in the running of the vehicle 1, the control device 23 calculates the importance of the update to be higher than when the ECU to be updated is an ECU not involved in the running of the vehicle 1. As an example of an ECU involved in the running of the vehicle 1, there is the driving system ECU 14B shown in FIG. 1. As an example of an ECU not involved in the running of the vehicle 1, there are the body system ECU 14A and the multimedia system ECU 14C shown in FIG. 1. Also, for example, when the ASIL rank assigned to the ECU to be updated is higher than a predetermined reference rank, the control device 23 calculates the importance of the update to be higher than when the ASIL rank assigned to the ECU to be updated is lower than a predetermined reference rank. Note that the calculation method of the importance of the update is only an example, and the control device 23 may calculate the importance of the update using other calculation methods.

The configuration of the user terminal 3 will now be described. As shown in FIG. 1, the user terminal 3 includes a terminal communication device 31, a terminal HMI (Human Machine Interface) 32, and a terminal control device 33.

The terminal communication device 31 has a function of performing data communication with the server 2 via the wireless communication network 4. The terminal HMI 32 functions as at least one of a device that accepts user operation input and a device that notifies the user of information. An example of the terminal HMI 32 is a touch panel display. The terminal HMI 32 is not limited to a device that displays information, and may be a device that outputs information by voice, such as a speaker. If the user terminal 3 is directly connected to the in-vehicle device of the vehicle 1 via Bluetooth (registered trademark) or the like, the user terminal 3 may perform data communication with the server 2 via the in-vehicle communication device 11 of the vehicle 1. If the in-vehicle device and the user terminal 3 are directly connected, the in-vehicle device may communicate with the server 2 from the user terminal 3 via the wireless communication network 4.

The terminal control device 33 is a device that functions as a control tower for the user terminal 3, and is composed of, for example, a processor and a memory programmed to execute one or more functions embodied by a computer program. The terminal control device 33 executes a process for notifying the user of campaign information and progress information of the update process in the software update process of the ECU of the vehicle 1. Taking campaign information as an example, when the terminal control device 33 receives campaign information from the server 2 via the terminal communication device 31, it outputs the campaign information to the terminal HMI 32 and displays the campaign information on the terminal HMI 32. The terminal control device 33 also executes a process for requesting consent from the user in the software update process of the ECU of the vehicle 1. Taking the case of requesting consent from the user to start the update process as an example, the terminal control device 33 generates a consent request image for requesting consent to start the update process from the user, outputs the consent request image to the terminal HMI 32, and displays the consent request image on the terminal HMI 32.

When the user terminal 3 is located within the range of the wireless communication network 4, the user outside the vehicle 1 can perform software update procedures by inputting operations while checking various information related to the software update on the user terminal 3. Note that the block configuration and functions of the user terminal 3 described above are merely examples and are not limited to the user terminal 3. Furthermore, the software update device, software update system, and software update method according to the present invention do not necessarily require the user terminal 3. In other words, the present invention can also be applied to a software update system that does not include the user terminal 3. The block configuration and functions of the user terminal 3 can be those known at the time of filing the present application. Furthermore, in this embodiment, an example is described in which a passenger, who is a user, performs procedures related to the update process using the in-vehicle terminal 12, but the software update device, software update system, and software update method according to the present invention can also be applied to a case in which a user performs procedures related to the update process using a user terminal.

Next, the configuration of vehicle 1 will be described. As shown in FIG. 1, vehicle 1 includes a software update device 10, an in-vehicle communication device 11, an in-vehicle terminal 12, an ignition switch 13, a body system ECU 14A, a driving system ECU 14B, a multimedia system ECU 14C, and a power supply system ECU 14D. Each component included in vehicle 1 is connected by an in-vehicle network such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN).

The in-vehicle communication device 11 has a function of performing data communication with the server 2 via the wireless communication network 4. An example of the in-vehicle communication device 11 is a telematics control unit (TCU).

The in-vehicle terminal 12 is a terminal having a function of accepting operation input from a user (passenger) riding in the vehicle 1 and a function of displaying various screens. Examples of the in-vehicle terminal 12 include a touch panel display. Signals for informing the occupant of various information are input from the software update device 10 to the in-vehicle terminal 12. For example, when information for requesting the occupant to consent to the start of the update process is input from the software update device 10, the in-vehicle terminal 12 displays an image for requesting the occupant to consent. In addition, when, for example, the occupant performs an operation on the in-vehicle terminal 12 to consent to the start of the update process, the in-vehicle terminal 12 outputs consent information indicating that the occupant has consented to the software update device 10. When the vehicle 1 is located within the range of the wireless communication network 4, a user in the cabin of the vehicle 1 can perform operation input while checking various information related to the software update using the in-vehicle terminal 12, and perform procedures related to the software update. Note that the in-vehicle terminal 12 is not limited to a device for displaying information, and may be, for example, a device for outputting information by voice, such as a speaker.

The ignition switch 13 functions as a start switch for the vehicle 1 and is a switch for turning the ignition of the vehicle 1 on or off. For example, when an occupant performs an operation to turn the ignition from on to off, the ignition switch 13 outputs a signal representing the user's operation to the software update device 10.

The body system ECU 14A, driving system ECU 14B, and multimedia system ECU 14C are examples of ECUs that are updated by the software update device 10. Each ECU has, as functional blocks, a microcomputer consisting of a CPU (Central Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), and flash memory, as well as a power supply circuit, a data transfer circuit, etc. The flash memory stores programs for realizing the software of the ECU. The ECU software is realized when the microcomputer executes the programs stored in the flash memory to perform various processes.

ECU flash memory is classified into single bank memory and double bank memory according to the memory configuration. Single bank memory does not distinguish between the program storage area and the area where the program is executed by the microcomputer, and the program cannot be rewritten in the single bank memory while the microcomputer is executing the program. On the other hand, double bank memory has two areas for storing programs, and the microcomputer executes the program in one of the two storage areas. Therefore, with double bank memory, even while the microcomputer is executing a program, it is possible to write a program to the other storage area that does not store the program being executed. For convenience, the two program storage areas of double bank memory will be referred to as the first memory and the second memory hereinafter.

The body system ECU 14A is a general term for ECUs that control the body system of the vehicle 1. Examples of the body system ECU 14A include a door control ECU that controls the locking/unlocking of the doors of the vehicle 1, a meter control ECU that controls the meter display of the vehicle 1, an air conditioner control ECU that controls the operation of the air conditioner of the vehicle 1, and a window control ECU that controls the opening and closing of the windows of the vehicle 1. The driving system ECU 14B is a general term for ECUs that control the driving system of the vehicle 1. Examples of the driving system ECU 14B include a drive source control ECU that controls the drive source of the vehicle 1, a brake control ECU that controls the operation of the brakes of the vehicle 1, and a power steering control ECU that controls the operation of the power steering of the vehicle 1. The multimedia system ECU 14C is a general term for ECUs that control the multimedia system of the vehicle 1. Examples of the multimedia system ECU 14C include a navigation control ECU that controls the navigation system of the vehicle 1, and an audio control ECU that controls the audio equipment of the vehicle 1.

The body system ECU 14A, driving system ECU 14B, and multimedia system ECU 14C receive update process control signals from the software update device 10, and each ECU executes software update processing. Note that while FIG. 1 shows one of each ECU, the number of ECUs to be updated is not particularly limited, and the software update system 100 can update software for multiple ECUs to be updated. Also, the body system ECU 14A, driving system ECU 14B, and multimedia system ECU 14C shown in FIG. 1 are examples of ECUs mounted on the vehicle 1, and do not limit the types of ECUs mounted on the vehicle 1 or the way in which the ECUs are distinguished. Also, the vehicle 1 may be equipped with ECUs other than those shown in FIG. 1.

The power supply system ECU 14D is a general term for the ECUs that control the power supply system of the vehicle 1. An example of the power supply system ECU 14D is a power supply control ECU that controls the ACC (accessory) power supply and IG (ignition) power supply mounted on the vehicle 1. A control signal for the update process is input to the power supply system ECU 14D from the software update device 10. For example, the power supply system ECU 14D executes a process to turn off the ignition of the vehicle 1.

Here, the outline of the OTA software update flow and its relationship with the memory configuration of the ECU will be explained using Figs. 2 to 4. Fig. 2 is an explanatory diagram for explaining the OTA software update flow. As shown in Fig. 2, the OTA software update is carried out in multiple stages. Specifically, the OTA software update sequentially involves notification of campaign information (step S1), download (step S2), installation (step S3), activation (step S4), and confirmation of update completion (step S5).

In step S1, campaign information is sent from the server 2 to the vehicle 1 and/or the user terminal 3, and the user is notified of the campaign information via the in-vehicle terminal 12 and/or the user terminal 3. In step S2, a distribution package including update data is sent from the server 2 to the vehicle 1, and the distribution package is stored in the vehicle 1. In step S3, a process of writing a new program to the ECU to be updated is performed. In step S4, the new program is enabled by a process of reading the new program by the microcomputer. In step S5, completion of the software update is notified via the in-vehicle terminal 12 and/or the user terminal 3.

Figure 3 is an explanatory diagram for explaining software updates by OTA according to the memory configuration of the ECU. Of the multiple steps shown in Figure 2, Figure 3 shows each step of download, installation, activation, and update completion confirmation as an "update state." Figure 3 also shows the state of the vehicle 1 in each update state as a "vehicle state," the operation of the ECU to be updated as a "target ECU," and the state of the user as a "user." Figure 3 (A) is an example of a software update flow when the ECU has a single-bank memory configuration, and Figure 3 (B) is an example of a software update flow when the ECU has a double-bank memory configuration.

As shown in FIG. 3(A), when the memory configuration of the ECU to be updated is single bank, the distribution package is "downloaded" in the vehicle 1 while the vehicle 1 is in a state in which it can be driven (ignition switch 13 is on). After the download is complete, when the ignition switch 13 is switched from on to off while the vehicle 1 is stopped, a "consent request" is made in the vehicle 1 to ask the user for consent to the start of the update process. In this embodiment, the user in the vehicle 1 performs operation input while checking various information related to the software update on the in-vehicle terminal 12, and performs the procedure for the software update.

Figure 4 is an example of a screen displayed on the in-vehicle terminal 12 when the occupant of the vehicle 1 is asked to consent to the start of the update process. After the download from the server 2 is completed, when the occupant (driver) of the vehicle 1 switches the ignition switch 13 from on to off, for example, as shown in Figure 4, the display (in-vehicle terminal 12) of the vehicle 1 displays, as a screen D, information C1 (display of "Do you want to update the software?") requesting the occupant to consent to the start of the update process, and two icons that the occupant can operate, an icon A1 (display of "Now") indicating consent and an icon A2 (display of "Later") indicating refusal. If the occupant consents to the start of the update process and presses the icon A1, the ECU software update process is started in the vehicle 1. On the other hand, if the occupant does not consent to the start of the update process and presses the icon A2, the ECU software update process is not started in the vehicle 1, and the power supply system ECU 14D executes the process of turning off the ignition of the vehicle 1. Additionally, the in-vehicle terminal 12 displays a notification that the update process has been postponed (for example, a message that says "Postponed until next time").

Returning to FIG. 3, when the occupant agrees to start the update process, an "installation" is performed in the vehicle 1 using the update data. Specifically, in the ECU's flash memory, the old program is deleted and then a rewrite process is performed to write the new program. When the rewrite process is complete, an "activation" process is performed to have the ECU's microcomputer read the new program. The vehicle 1 is then powered on again (rebooted), and the software update is complete. When the software update is complete, the in-vehicle terminal 12 displays an update completion notification indicating that the update has been completed (for example, a display of "Software update has been completed"). In addition, after the update process is complete, the power supply system ECU 14D executes a process to turn off the ignition of the vehicle 1.

As shown in FIG. 3B, when the ECU has a double-bank memory configuration, the vehicle 1 "downloads" the distribution package and also "installs" the update data while the vehicle 1 is in a driveable state. When the ECU's microcomputer is executing the program (old program) stored in the first memory, a write process is performed to write the new program in the second memory. After the installation is complete, when the ignition switch 13 is turned from on to off while the vehicle 1 is stopped, a "consent request" is made in the vehicle 1 to ask the occupant for consent to the start of the update process (see FIG. 4). When the occupant consents to the start of the update process, an "activation" is performed to change the memory the microcomputer reads from from the first memory to the second memory. The vehicle 1 is then powered on again, and the software update is completed.

As described above, the specific content of the software update process varies between "install" and "activate" and "activate" depending on the configuration of the ECU's flash memory, but regardless of the update process, the occupant is asked to consent to starting the update process, and the update process is executed in the vehicle 1 when the occupant performs an operation that consents to starting the update process. However, in the example of FIG. 4, if the occupant does not perform any operation while screen D1 is displayed on the in-vehicle terminal 12, the occupant's intention (approval or refusal) regarding the start of the update process cannot be confirmed, and it is not possible to determine whether the update process should be started or not. Therefore, the software update device 10 according to this embodiment aims to solve the above problem by the following configuration and method.

Next, the software update device 10 will be described. As shown in FIG. 5, the software update device 10 includes a controller 40. FIG. 5 shows an example of a functional block of the controller 40 of the software update device 10. The controller 40 is configured by a computer including hardware and software, and includes a memory that stores a program, and a CPU that executes the program stored in the memory. Note that, as the operating circuit, an MPU, DSP, ASIC, FPGA, etc. can be used instead of or in addition to the CPU.

As shown in FIG. 5, the controller 40 has, as functional blocks, an information acquisition unit 41, a storage unit 42, an output unit 43, a start determination unit 44, an update processing execution unit 45, and a power processing execution unit 50. The controller 40 realizes each function of the functional blocks by software stored in the memory.

The information acquisition unit 41 acquires update processing information related to software updates from the server 2 via the in-vehicle communication device 11. The update processing information includes the campaign information and distribution package described above. The information acquisition unit 41 also acquires a signal indicating the on or off state of the ignition switch 13 from the ignition switch 13. The information acquisition unit 41 also acquires a signal indicating a user operation from the in-vehicle terminal 12. In the example of FIG. 4, when the occupant presses icon A1, which indicates consent, the information acquisition unit 41 acquires a signal from the in-vehicle terminal 12 indicating that the consent display has been pressed by the occupant. On the other hand, in the example of FIG. 4, when the occupant presses icon A2, which indicates refusal, the information acquisition unit 41 acquires a signal from the in-vehicle terminal 12 indicating that the refusal display has been pressed by the occupant.

The memory unit 42 functions as a storage device that stores information acquired from the server 2 among the information acquired by the information acquisition unit 41. For example, a non-volatile recording medium such as a flash memory is used as the memory unit 42. The memory unit 42 stores the campaign information and distribution packages acquired from the server 2. The memory unit 42 may also store information related to the ECU installed in the vehicle 1 (such as the memory configuration of the ECU). The various information stored in the memory unit 42 is used for processing by the update process execution unit 45.

The output unit 43 outputs consent request information that requests the occupant of the vehicle 1 to consent to the start of the update process by the update process execution unit 45. Examples of the consent request information include an image and a sound, but the method of requesting consent from the occupant is not particularly limited. For example, the output unit 43 reads out a display image of "Do you want to update the software?" as shown in FIG. 4 from the memory and outputs an image signal to the in-vehicle terminal 12. As a result, a screen D as shown in the example of FIG. 4 is displayed on the in-vehicle terminal 12. Also, for example, the output unit 43 may output an audio signal to the in-vehicle terminal 12 together with or instead of the image signal, requesting the occupant to consent to the start of the update process. As a result, the occupant can be requested to consent to the start of the update process by voice.

In addition, in this embodiment, the output unit 43 outputs consent request information when a predetermined output condition is satisfied. The output unit 43 determines whether the ignition switch 13 has been operated from on to off by the occupant based on the information acquired by the information acquisition unit 41. The output unit 43 outputs consent request information when a signal indicating the state of the ignition switch 13 switches from an on state to an off state. Note that the output condition by the output unit 43 is an example, and the output condition may be other conditions.

The start determination unit 44 determines whether or not to start the update process by the update process execution unit 45. If the occupant agrees to start the update process in response to the consent request information output by the output unit 43, the start determination unit 44 determines to start the update process, and if the occupant refuses to start the update process in response to the consent request information, the start determination unit 44 determines not to start the update process. In the example of FIG. 4, when the occupant operates the consent display (icon A1) or the refusal display (icon A2) on the screen D displayed on the in-vehicle terminal 12, the information acquisition unit 41 acquires an operation signal from the in-vehicle terminal 12 indicating that the consent display or the refusal display has been pressed by the occupant. The start determination unit 44 regards the operation signal acquired by the information acquisition unit 41 as answer information, which is the occupant's answer to the consent request information. The start determination unit 44 determines whether or not to start the update process according to the answer information. For example, the start determination unit 44 determines to start the update process if the response information indicates that the occupant has operated the consent display, and determines not to start the update process if the response information indicates that the occupant has operated the refusal display.

In addition, in this embodiment, if no response information is input for a predetermined time or more after the consent request information is output, the start determination unit 44 determines whether or not to start the update process based on the time required for the update process. In other words, if the occupant does not respond despite being asked whether to consent to the start of the update process, the start determination unit 44 determines whether or not to start the update process based on the time required for the update process. The predetermined time is a time that is set in advance. Furthermore, the time required for the update process is the estimated time calculated by the server 2 until the update process in the vehicle 1 is completed.

The start determination unit 44 determines to start the update process if the time required for the update process is less than the first threshold, and determines not to start the update process if the time required for the update process is equal to or greater than the first threshold. The first threshold is a preset threshold (unit: time). The first threshold is, for example, a time calculated based on the average time for the update process of each ECU.

The update process execution unit 45 executes the update process according to the response information, which is the occupant's response to the consent request information. If the start determination unit 44 determines that the update process should be started, the update process execution unit 45 executes the update process, and if the start determination unit 44 determines that the update process should not be started, the update process execution unit 45 postpones the execution of the update process. Note that if the start determination unit 44 determines that the update process should not be started, it is sufficient that the execution of the update process is postponed, and the update process execution unit 45 may execute other processes.

The update process execution unit 45 includes an installation execution unit and an activation execution unit corresponding to the memory configuration of the ECU to be updated as a functional block that executes the update process. As shown in FIG. 5, the update process execution unit 45 includes a first installation execution unit 46 and a first activation execution unit 47 corresponding to a single-bank memory configuration, and a second installation execution unit 48 and a second activation execution unit 49 corresponding to a double-bank memory configuration. As described with reference to FIG. 3, the processing contents of "install" and "activate" differ depending on whether the memory configuration of the ECU is single-bank or double-bank. For this reason, in this embodiment, multiple installation execution units and multiple activation execution units are provided. When the memory configuration of the ECU to be updated is single-bank, the first installation execution unit 46 installs a new program, and the first activation execution unit 47 activates the new program. On the other hand, when the memory configuration of the ECU to be updated is double-bank, the second installation execution unit 48 installs a new program, and the second activation execution unit 49 activates the new program. The update process execution unit 45 determines the memory configuration of the ECU to be updated from information about the ECU installed in the vehicle 1 stored in the storage unit 42.

The first installation execution unit 46 executes an installation process to write a new program after deleting the old program stored in the flash memory. The first activation execution unit 47 executes an activation process to read the new program written in the flash memory into the microcomputer of the ECU to be updated.

When the old program is stored in the first memory of the first and second memories of the flash memory and the microcomputer is reading the old program, the second installation execution unit 48 executes an installation process to write the new program to the second memory where the old program is not stored. The second activation execution unit 49 executes an activation process to switch the program reading destination by the microcomputer of the ECU to be updated from the first memory to the second memory.

The power supply processing execution unit 50 outputs a control signal to the power supply system ECU 14D to set the output power of the drive battery, which is the IG power supply of the vehicle 1, to zero, and turns off the ignition of the vehicle 1.

Next, an example of a software update method according to this embodiment will be described with reference to the flowchart in FIG. 6. The flowchart in FIG. 6 is executed by the controller 40 of the software update device 10 shown in FIG. 5. Note that the flowchart in FIG. 6 is a flowchart for the case where the memory configuration of the ECU to be updated is a single bank. The flowchart in FIG. 6 is also a flowchart of the steps from download (step S2) to confirmation of update completion (step S5) shown in FIG. 2.

In step S11, the controller 40 acquires (downloads) a distribution package from the server 2 via the in-vehicle communication device 11. The distribution package includes update data, authentication data used in the authentication process of the update data, and an estimated update process time.

In step S12, the controller 40 determines whether the ignition switch 13 has been switched from on to off by the occupant's operation. The controller 40 acquires a signal indicating the operation by the occupant from the ignition switch 13. If the ignition switch 13 has been switched from on to off by the occupant, the controller 40 proceeds to step S13, and if the ignition switch 13 remains on, the controller 40 waits in step S12 until the occupant switches the ignition switch 13 from on to off.

In step S13, the controller 40 outputs consent request information that requests the occupant of the vehicle 1 to consent to the start of the software update process. For example, as shown in the example of FIG. 4, the controller 40 displays the consent request information that requests the occupant's consent on the screen of the in-vehicle terminal 12.

In step S14, the controller 40 determines whether or not there is a response from the occupant to the consent request information output in step S13. For example, as in the example of FIG. 4, when the consent request information is displayed on the screen of the in-vehicle terminal 12, when a signal indicating an operation by the occupant is input to the screen, the controller 40 regards the input signal as response information from the occupant and determines that there is a response from the occupant. On the other hand, when a signal indicating an operation by the occupant is not input to the screen, the controller 40 determines that there is no response from the occupant. If it is determined that there is a response from the occupant, the process proceeds to step S15, and if it is determined that there is no response from the occupant, the process proceeds to step S18.

If it is determined in step S14 that there is a response from the occupant, the process proceeds to step S15. In step S15, the controller 40 determines whether the response information from the occupant input in step S14 indicates consent to the start of the update process. For example, in the example of FIG. 4, if the occupant presses icon A1 (displaying "Now"), the response information acquired in step S14 includes information indicating that the occupant has consented, and the controller 40 determines that the occupant has consented to the start of the update process. Also, for example, in the example of FIG. 4, if the occupant presses icon A2 (displaying "Later"), the response information acquired in step S14 includes information indicating that the occupant refuses, and the controller 40 determines that the occupant has not consented to the start of the update process. If it is determined that the occupant has consented, the process proceeds to step S16, and if it is determined that the occupant has not consented, the process proceeds to step S17.

If it is determined in step S15 that the occupant has consented, the process proceeds to step S16. In step S16, the controller 40 executes a software update process for the ECU to be updated. Specifically, when the memory configuration of the ECU is a single bank, as shown in the example of FIG. 3(A), the controller 40 executes an installation process and an activation process. The specific contents of each process are described above.

If it is determined in step S15 that the occupant has not consented, or if the processing in step S16 has ended, the process proceeds to step S17. In step S17, the controller 40 executes a process to turn off the ignition of the vehicle 1 as a process corresponding to the operation of the ignition switch 13 by the occupant in step S12. Specifically, the controller 40 outputs a control signal to the power supply system ECU 14D to turn off the ignition of the vehicle 1. When the processing in step S15 ends, the processing in the flowchart shown in FIG. 6 ends.

If it is determined in step S14 that there is no response from the occupant, the process proceeds to step S18. In step S18, the controller 40 determines whether or not a predetermined time has elapsed. If it is determined that the predetermined time has elapsed, the process proceeds to step S19. If it is determined that the predetermined time has not elapsed, the process returns to step S14, and the controller 40 executes the process in step S14 described above.

If it is determined in step S18 that the predetermined time has elapsed, the process proceeds to step S19. In step S19, the controller 40 determines whether the time required for the update process obtained in step S11 is less than a first threshold. Specifically, the controller 40 determines whether the time required for the installation process and the activation process is less than the first threshold. If it is determined that the time required for the update process is less than the first threshold, the process proceeds to step S20, and if it is determined that the time required for the update process is equal to or greater than the first threshold, the process proceeds to step S21.

If it is determined in step S19 that the time required for the update process is less than the threshold, the process proceeds to step S20. In step S20, the controller 40 determines to start the update process. Then, the process proceeds to step S16, where the controller 40 executes the update process described above. On the other hand, if it is determined in step S19 that the time required for the update process is equal to or greater than the threshold, the process proceeds to step S21. In step S21, the controller 40 determines not to start the update process. Then, the process proceeds to step S17, where the controller 40 executes the process of turning off the ignition of the vehicle 1 described above, and the process in the flowchart shown in FIG. 6 ends.

For the flowchart when the memory configuration of the ECU to be updated is double bank, only the steps that differ from the processing for a single bank will be explained using FIG. 6. When the memory configuration is double bank, after the processing of step S11 is completed, the controller 40 executes an installation process using the new program acquired in step S11 before proceeding to step S12. Specifically, when the memory configuration of the ECU is double bank, the controller 40 executes an installation process as shown in the example of FIG. 3(B). For the specific contents of the process, the explanation given above will be used.

In addition, in step S16, the controller 40 executes an activation process as a software update process for the ECU to be updated. Specifically, when the memory configuration of the ECU is double bank, as shown in the example of FIG. 3(B), the controller 40 switches the read destination of the ECU's microcomputer from the memory in which the old program is stored to the memory in which the new program is stored as the activation process.

In step S19, the controller 40 determines whether the time required for the update process obtained in step S11 is less than a first threshold value. Specifically, when the memory configuration of the ECU is double bank, the controller 40 determines whether the time required for the activation process is less than a first threshold value.

As described above, the software update device 10 according to the present embodiment is a software update device that updates software in the body system ECU 14A, the driving system ECU 14B, and the multimedia system ECU 14C mounted on the vehicle 1. The software update device 10 includes an output unit 43,
The software update device 10 includes an update process execution unit 45 and a start determination unit 44. The output unit 43 acquires update process information related to software update from the server 2. The update process execution unit 45 executes the update process according to response information, which is the occupant's response to the consent request information. If no response information is input for a predetermined time or more after the consent request information is output, the start determination unit 44 determines whether or not to start the update process based on the time required for the update process. According to the software update device 10, software update system 100, and software update method of this embodiment, the occupant, who is the user of the vehicle 1, is asked whether to consent to the start of the software update process, and even if there is no response from the user, it is possible to determine whether or not to start the update process.

In addition, in this embodiment, when the start determination unit 44 determines that the update process should be started, the update process execution unit 45 executes the update process, and when the start determination unit 44 determines that the update process should not be started, the update process execution unit 45 postpones the update process without executing it. This makes it possible to ask the occupant whether to consent to the start of the software update process, and to automatically execute or automatically postpone the update process even if there is no response from the occupant.

In addition, in this embodiment, the start determination unit 44 determines to start the update process when the time required for the update process is less than the first threshold value, and determines not to start the update process when the time required for the update process is equal to or greater than the first threshold value. Since it is possible to determine whether to start the update process depending on the time required for the update process, for example, when the time required for the update process is relatively long, i.e., when the downtime of the vehicle 1 is relatively long, it is possible to prevent the occupant from being unable to use the vehicle 1 until the update process is completed. Also, for example, when the time required for the update process is relatively short, i.e., when the downtime of the vehicle 1 is relatively short, even if the update process is started, the occupant can use the vehicle 1 with a relatively short waiting time.

In this embodiment, the ECU to be updated has a flash memory that stores the old program, and the update process execution unit 45 includes a first installation execution unit 46 that executes an installation process to write a new program to the flash memory after deleting the old program from the flash memory, and a first activation execution unit 47 that executes an activation process to read the new program written to the flash memory into the microcomputer, and the update process executed by the update process execution unit 45 is an installation process and an activation process. This makes it possible to determine whether or not to start the update process even when the memory configuration of the ECU to be updated is single bank.

In addition, in this embodiment, the ECU to be updated has a flash memory configured with double banks of a first memory that stores the old program and a second memory, and the update process execution unit 45 includes a second installation execution unit 48 that writes a new program to the second memory, and a second activation execution unit 49 that executes an activation process that switches the microcomputer's program reading destination from the first memory to the second memory, and the update process executed by the update process execution unit 45 is an installation process and an activation process. This makes it possible to determine whether or not to start the update process even when the memory configuration of the ECU to be updated is double bank.

In this embodiment, the information acquisition unit 41 acquires a signal indicating the on or off state of the ignition switch 13 from the ignition switch 13 of the vehicle 1, and the output unit 43 outputs consent request information when the ignition switch 13 is turned from on to off by the occupant. The consent request information can be presented to the occupant using an operation indicating that the occupant will not use the vehicle 1 as a trigger.

In addition, in this embodiment, the information acquisition unit 41 acquires the time required for the update process from the server 2. This allows the software update device 10 to determine whether or not to start the update process without calculating the time required for the update process, thereby reducing the computational load on the software update device 10.

In this embodiment, the software update device 10 acquires the time required for the update process from the server 2, but the entity that calculates the time required for the update process is not limited to the server 2, and the software update device 10 may calculate the time required for the update process.

As a modified example of this embodiment, the controller 40 may have, as a functional block, a calculation unit that calculates the time required for the update process based on the data size of the update data. For example, if a map showing the relationship between the data size of the update data and the estimated update process time is stored in advance in the storage unit 42, the calculation unit may refer to the map to calculate the estimated update process time according to the data size. For example, the calculation unit may calculate a longer estimated update process time as the data size of the update data increases. As in the modified example, the software update device 10 calculates the estimated update process time, thereby reducing the calculation load on the server 2. Note that the timing at which the controller 40 calculates the estimated update process time is not particularly limited as long as it is before the comparison of the estimated update process time with the first threshold value is performed. For example, in the flowchart of FIG. 6, the controller 40 calculates the required time required for the update process based on the data size of the update data between steps S11 and S12.

Second Embodiment
Next, a software update device according to a second embodiment will be described. The software update device according to the second embodiment has the same configuration as the first embodiment, except that the start determination unit 44 has a part of different function from the software update device 10 according to the first embodiment described above. Therefore, the same configuration as the first embodiment will be described with reference to the above description.

In this embodiment, if no response information is input from the occupant for a predetermined time or longer after the output unit 43 outputs the consent request information, the start determination unit 44 determines whether or not to start the update process based on the importance of the ECU software update. The importance of the ECU software update is the importance of the update calculated by the server 2 in the first embodiment described above.

The start determination unit 44 determines to start the update process when the importance of the update is equal to or greater than the second threshold, and determines not to start the update process when the importance of the update is less than the second threshold. The second threshold is a preset threshold. The second threshold is, for example, a value calculated based on an average rank obtained by averaging the ASIL ranks assigned to each ECU.

Next, an example of a software update method according to this embodiment will be described with reference to the flowchart in FIG. 7. The flowchart shown in FIG. 7 is executed by the controller 40 of the software update device according to this embodiment. Note that the flowchart in FIG. 7 is the same as the flowchart in FIG. 6 except for the step corresponding to step S19 in FIG. 6, and therefore the above explanation will be used for the steps that are the same as those in the flowchart in FIG. 6.

If it is determined in step S18 that the predetermined time has elapsed, the process proceeds to step S22. In step S22, the controller 40 determines whether the importance of the update obtained in step S11 is equal to or greater than the second threshold. If it is determined that the importance of the update is equal to or greater than the second threshold, the process proceeds to step S20, and if it is determined that the importance of the update is less than the second threshold, the process proceeds to step S21.

As described above, in this embodiment, if no response information is input from the occupant for a predetermined time or longer after the output unit 43 outputs consent request information, the start determination unit 44 determines whether or not to start the update process based on the importance of the ECU software update. This makes it possible to ask the occupant, who is the user of the vehicle 1, whether to consent to the start of the software update process, and to determine whether or not to start the update process even if there is no response from the user.

In addition, in this embodiment, the start determination unit 44 determines to start the update process when the importance of the update is equal to or greater than the second threshold, and determines not to start the update process when the importance of the update is less than the second threshold. Since it is possible to determine whether to start the update process or not depending on the importance of the update, the occupant is asked whether to consent to the start of an update process that is highly important or urgent, and even if there is no response from the occupant, the update process that is highly important or urgent can be automatically executed.

In this embodiment, the software update device 10 acquires the importance of the update from the server 2. However, the entity that calculates the importance of the update is not limited to the server 2. The software update device 10 may calculate the importance of the update.

As a modified example of this embodiment, the controller 40 may include, as a functional block, an importance calculation unit that calculates the importance of the update based on the type of the ECU to be updated. For example, when the ECU to be updated is an ECU involved in the running of the vehicle 1, the importance calculation unit calculates the importance of the update to be higher than when the ECU to be updated is an ECU not involved in the running of the vehicle 1. Also, for example, when the rank of the ASIL attached to the ECU to be updated is higher than a predetermined reference rank, the importance calculation unit calculates the importance of the update to be higher than when the rank of the ASIL attached to the ECU to be updated is lower than a predetermined reference rank. The software update device 10 calculates the importance of the update, thereby reducing the calculation load on the server 2. Note that the timing when the controller 40 calculates the importance of the update is not particularly limited as long as it is before comparing the importance of the update with the second threshold value. For example, in the flowchart of FIG. 7, the controller 40 calculates the importance of the update based on the type of the ECU to be updated between steps S11 and S12. Furthermore, the explanation in the first embodiment above applies to the flowchart when the memory configuration of the ECU to be updated is a dumble bank.

Third Embodiment
Next, a software update device according to a third embodiment will be described. The software update device according to the third embodiment has the same configuration as the first and second embodiments except for a part of the function of the start determination unit 44, which is different from that of the software update devices according to the above-mentioned two embodiments. Therefore, the above-mentioned description will be used for the same configuration as the first and second embodiments.

In this embodiment, when no response information is input from the occupant for a predetermined time or more after the output unit 43 outputs the consent request information, the start determination unit 44 combines the determination method according to the time required for the update process in the first embodiment and the determination method according to the importance of the update in the second embodiment to determine whether or not to start the update process. When the importance of the update process is equal to or greater than the second threshold, the start determination unit 44 determines to start the update process regardless of whether the time required for the update process is less than the first threshold. For example, the start determination unit 44 first uses the determination method according to the importance of the update, and when the importance of the update is equal to or greater than the second threshold, determines to start the update process. When the importance of the update is less than the second threshold, the start determination unit 44 uses the determination method according to the time required for the update process, and when the time required for the update process is less than the first threshold, determines to start the update process, and when the time required for the update process is equal to or greater than the first threshold, determines not to start the update process. The importance of the update is the importance of the update in the second embodiment, and the time required for the update process is the time required for the update process in the first embodiment.

Next, an example of a software update method according to this embodiment will be described with reference to the flowchart in FIG. 8. The flowchart shown in FIG. 8 is executed by the controller 40 of the software update device according to this embodiment. Note that the flowchart in FIG. 8 is the same as the flowchart in FIG. 7 except that step S23 has been added to the flowchart in FIG. 7. Therefore, the above explanation will be used for the steps that are the same as those in the flowchart in FIG. 7.

If it is determined in step S18 that the predetermined time has elapsed, the process proceeds to step S22. In step S22, the controller 40 determines whether the importance of the update obtained in step S11 is equal to or greater than the second threshold. If it is determined that the importance of the update is equal to or greater than the second threshold, the process proceeds to step S20, and if it is determined that the importance of the update is less than the second threshold, the process proceeds to step S23.

If it is determined in step S22 that the importance of the update is less than the second threshold, the process proceeds to step S23. In step S23, the controller 40 determines whether the time required for the update process obtained in step S11 is less than the first threshold. Specifically, the controller 40 determines whether the time required for the installation process and the activation process is less than the first threshold. If it is determined that the time required for the update process is less than the first threshold, the process proceeds to step S20, and if it is determined that the time required for the update process is equal to or greater than the first threshold, the process proceeds to step S21. Step S23 corresponds to step S19 in the first embodiment.

As described above, in this embodiment, when the importance of the update is equal to or greater than the second threshold, the start determination unit 44 determines that the update process should be started regardless of whether the time required for the update process is less than the first threshold. As a result, in the case of an update with a relatively high importance, it is possible to determine that the update process should be started regardless of the time required for the update process, and therefore it is possible to ask the occupant whether to consent to the start of an update process with high importance or urgency, and to automatically execute the update process with high importance or urgency even if there is no response from the occupant.

As in the first and second embodiments described above, in this embodiment, the entity that calculates the time required for the update process and the importance of the update is not limited to the server 2, and the software update device 10 may calculate the time required for the update process. The specific configuration is as described above. Also, the explanation in the first embodiment described above is as follows for the flow chart when the memory configuration of the ECU to be updated is a dumble bank.

The above-described embodiments are described to facilitate understanding of the present invention, and are not described to limit the present invention. Therefore, each element disclosed in the above embodiments is intended to include all design modifications and equivalents that fall within the technical scope of the present invention.

For example, in the above-mentioned third embodiment, a configuration using a start determination method according to the time required for the update process and a start determination method according to the importance of the update are described as an example, but a method that can obtain an effect equivalent to that of the start determination method in the third embodiment is not limited to using two start determination methods. For example, in the above-mentioned first embodiment, the start determination unit 44 may set a first threshold value to be compared with the time required for the update process according to the importance of the update. For example, when the importance of the update is equal to or greater than the second threshold value, the start determination unit 44 may set the first threshold value higher than when the importance of the update is less than the second threshold value. In addition, the start determination unit 44 may set the first threshold value higher as the importance of the update increases. The higher the first threshold value is set, the easier it is to determine that the update process should be started when comparing the time required for the update process in the start determination unit 44 with the first threshold value, and the same effect as that in the third embodiment can be obtained.

In the above-described first to third embodiments, the occupant is asked to consent to the start of the update process, and if the occupant consents, the software update device 10 executes the update process. However, the software update device 10 may execute the update process according to the stopping point of the vehicle 1 in addition to the occupant's response to the consent request information. For example, the information acquisition unit 41 may acquire the location information of the vehicle 1 from a detection device that detects the current location of the vehicle 1, such as a GPS, and the update process execution unit 45 may execute the update process according to the response information, which is the occupant's response to the consent request information, and the stopping point of the vehicle 1. For example, when the occupant stops the vehicle 1 in a parking lot of a store to stop by a specific store, the occupant's stay time at the store is shorter than that at the occupant's home, so the time available for the update process tends to be shorter. In such a case, the update process execution unit 45 does not execute the update process even if the occupant consents to the start of the update process. For example, in the flowchart of FIG. 8, the software update device 10 may omit the processes of steps S13 and S14 and execute the process of step S21 if a positive determination is made in step S12. For example, when the occupant parks the vehicle 1 in a parking lot at home to return home, the time available for the update process tends to be relatively long. In such a case, the update process execution unit 45 executes the update process if the occupant agrees to start the update process. For example, in the flowchart of FIG. 8, after the process of step S13 is completed, the software update device 10 may omit the process of step S14 and execute step S16. Note that, although the store and the user's home have been described as examples of vehicle stopping points, the vehicle stopping points are not limited to these.

For example, in the above-described first to third embodiments, the first threshold value, which is compared with the time required for the update process, and the second threshold value, which is compared with the importance of the update, are each described as being preset values, but the first threshold value and/or the second threshold value may be values that the user can set. For example, the user may set the first threshold value and/or the second threshold value via the in-vehicle terminal 12. For example, if the user wants the software update device 10 to determine that the update process should be started when the time required for the update process is less than five minutes, the user sets the first threshold value to five minutes.

REFERENCE SIGNS LIST 100 software update system 1 vehicle 10 software update device 40 controller 41 information acquisition unit 42 storage unit 43 output unit 44 start determination unit 45 update process execution unit
46...First installation execution unit
47...First activation execution unit
48...Second installation execution unit
Reference Signs List 49: second activation execution unit 50: power supply processing execution unit 11: in-vehicle communication device 12: in-vehicle terminal 13: ignition switch 14A: body system ECU
14B...Driving system ECU
14C...Multimedia ECU
14D...Power system ECU
2: Server 21: Communication device 22: Database 23: Control device 3: User terminal 31: Terminal communication device 32: Terminal HMI
33...Terminal control device

Claims (17)

A software update device for updating software of an on-board control device mounted in a vehicle,
an information acquisition unit that acquires update processing information related to the software update from a server provided outside the vehicle;
an output unit that outputs consent request information that requests a user to consent to the start of the software update process;
an execution unit that executes the update process in response to answer information that is an answer of the user to the consent request information;
A software update device comprising a start determination unit that, when the response information is not input for a predetermined time or longer after the consent request information is output, determines whether to start the update process based on at least one of the time required for the update process and the importance of the software update. 2. The software update device according to claim 1,
The execution unit is
When the start determination unit determines that the update process should be started, the update process is executed;
A software updating device that postpones execution of the update process when the start determination unit determines not to start the update process. 3. The software update device according to claim 2,
The start determination unit is
If the required time is less than a predetermined first threshold, it is determined that the update process is to be started;
When the required time is equal to or greater than the first threshold value, the software updating device determines not to start the update process. 4. The software update device according to claim 2,
The start determination unit is
If the importance is equal to or greater than a predetermined second threshold, it is determined that the update process is to be started;
When the importance is less than the second threshold, the software updating device determines not to start the update process. 3. The software update device according to claim 2,
The software updating device, wherein the initiation determination unit determines to start the update process when the importance is equal to or greater than a predetermined second threshold, regardless of whether the required time is less than a predetermined first threshold. 4. The software update device according to claim 3,
The software updating device, wherein the initiation determination unit sets the first threshold value depending on the importance. The software update device according to any one of claims 1 to 6,
the on-board control device has a first memory that stores a first program for implementing the old version of the software;
The execution unit is
an installation execution unit that executes an installation process to write a second program for implementing a new version of the software into the first memory after deleting the first program from the first memory;
an activation execution unit that executes an activation process to read the second program written in the first memory,
The software updating device, wherein the update process includes the installation process and the activation process. The software update device according to any one of claims 1 to 6,
the on-board control device has a first memory for storing a first program for implementing the old version of the software, and a second memory;
The execution unit is
an installation execution unit that writes a second program for implementing a new version of the software into the second memory;
an activation execution unit that executes an activation process to switch a program loading destination from the first memory to the second memory,
The software updating device, wherein the update process is the activation process. The software update device according to any one of claims 1 to 8,
The information acquisition unit acquires, from a start switch of the vehicle, a signal indicating an on state or an off state of the start switch,
The output unit outputs the consent request information when the user turns the activation switch from on to off. The software update device according to any one of claims 1 to 9,
The information acquisition unit acquires location information of the vehicle from a detection device that detects a current location of the vehicle,
The execution unit is a software update device that executes the update process in accordance with the response information and a stopping point of the vehicle. A software update device according to any one of claims 1 to 10,
The software updating device, wherein the information acquisition unit acquires at least one of the required time and the importance from the server. A software update device according to any one of claims 1 to 11,
A software update device comprising a calculation unit that calculates the required time based on a size of data used to update the software. A software update device according to any one of claims 1 to 12,
The software update device further comprises an importance calculation unit that calculates the importance based on a type of the in-vehicle control device. 14. A software update device according to claim 13, comprising:
The importance calculation unit of the software update device calculates the importance to be higher when the in-vehicle control device is a control device involved in the driving of the vehicle than when the in-vehicle control device is a control device not involved in the driving of the vehicle. A software update device according to any one of claims 1 to 14,
A software update device, wherein the importance is based on at least one of indicators of the vehicle's running and the vehicle's security. A software update system including the software update device according to any one of claims 1 to 15 and the server. A software updating method in which a controller updates software of an on-board control device mounted in a vehicle, comprising:
acquiring update processing information relating to the software update from a server provided outside the vehicle;
outputting consent request information for requesting a user to consent to the start of the software update process;
Executing the update process in response to answer information which is a reply from the user to the consent request information;
A software update method for determining whether to start the update process based on at least one of the time required for the update process and the importance of the software update when the response information is not input for a predetermined time after the consent request information is output.