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

Abstract

Provided is a software updating device (10) that updates software of in-vehicle control devices (14A to 14C) mounted on a vehicle (1), the software updating device (10) including: an information acquisition unit (41) that acquires update processing information regarding update of the software of the in-vehicle control devices (14A to 14C); an output unit (43) that outputs acceptance request information of asking a user whether to accept the update of the software; an update processing execution unit (45) that executes update processing in accordance with answer information as an user's answer to the acceptance request information; and a control unit (50) that controls the in-vehicle control devices (14A to 14C) to execute a program corresponding to unupdated software when the update is not completed in estimated time required for the update, and controls the in-vehicle control devices (14A to 14C) to execute a program corresponding to updated software when the update is completed in the estimated time.

Description

[Technical field]

[0001] The present invention relates to a software updating device, a software updating system, and a software updating method. [Background technology]

[0002] Conventionally, there has been known an information processing terminal capable of automatically updating software at a timing according to a user's preference (Patent Document 1). This information processing terminal can also be used as an in-vehicle terminal mounted in a vehicle. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-38634 A Summary of the Invention [Problem to be solved by the invention]

[0004] While the software update process is being executed, the vehicle cannot be started, and the user cannot use the vehicle. In the above information processing terminal, if an error occurs that causes the software update to not finish, the software to be executed by the in-vehicle control device cannot be determined, and there is a possibility that the user cannot use the vehicle.

[0005] An object of the present invention is to provide a software update device, a software update system, and a software update method that allow a user to use a vehicle. [Means for solving the problem]

[0006] The present invention obtains update processing information related to software updates for an in-vehicle control device from a server provided outside the vehicle, and outputs consent request information that prompts a user to consent to the software update. , outputting an estimated time required for the software update;Execute update processing according to answer information, which is the user's answer to the consent request information. do This solves the above problem. Effect of the Invention

[0007] According to the present invention, The software update process can be carried out based on the estimated time required for the software update and the user's response information. The user can use the vehicle. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram showing an example of a software updating system including a software updating device according to the first embodiment. [Diagram 2] FIG. 2 is an explanatory diagram for explaining the flow of a software update via OTA. [Diagram 3] FIG. 3 is an explanatory diagram for explaining software updating by OTA in accordance with the memory configuration of the ECU. [Figure 4] FIG. 4 is an example of a functional block of the controller of the software updating device shown in FIG. [Diagram 5] FIG. 5 is a flowchart of the software updating method according to the first embodiment. [Figure 6] FIG. 6 is an example of a functional block of a controller of the software updating device according to the second embodiment. [Figure 7] FIG. 7 is a flowchart of a software updating method according to the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of a software updating device, a software updating system, and a software updating method according to the present invention will be described with reference to the accompanying drawings.

[0010] 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 device (hereinafter referred to as an ECU (Electronic Control Unit)) of a vehicle 1, by OTA (Over The Air). 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 will be described as an example of updating the software of the ECU wirelessly. 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 when 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.

[0011] 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 description, data required for software update, such as the new version of the program and difference data, will be referred to as "update data". Also, the "new version of the program" will be referred to as the "new program", the "old version of the program" will be referred to as the "old program", and the "difference data between the new version of the program and the old version of the program" will be referred to as the "difference data". In this embodiment, "completion of processing" means that the processing has been normally completed, and does not include abnormal completion of the processing. In this embodiment, a user who is outside the vehicle 1 will be used as an example of a user who performs a procedure related to the software update.

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

[0013] Vehicle 1 is equipped with an ECU capable of updating software. Vehicle 1 exchanges various information related to software updates with server 2. Information related to each ECU installed in vehicle 1 is transmitted from vehicle 1 to server 2. Information related to ECUs includes, for example, the current version of software. Information related to 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).

[0014] Also, information related to software updates is transmitted from the server 2 to the vehicle 1. Examples of the information related to 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 authentication processing 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 and an estimate of the time required for the update process will be described later. The estimate of the time required for the update process may be included in the distribution package. When 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.

[0015] The server 2 is a server that controls the software update process in the software update system 100 and functions as an OTA center. The server 2 exchanges various pieces of information related to the above-mentioned software update with the vehicle 1. The server 2 also exchanges various pieces of information with the user terminal 3.

[0016] 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) 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 the campaign information and the update data. For example, when the server 2 receives various information including the update data from a provider of the 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 update target ECU). The server 2 sets the distribution timing of the campaign information, and transmits the campaign information to the vehicle 1 and / or the user terminal 3 when the distribution timing of the campaign information arrives. 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.

[0017] The user terminal 3 is a terminal that has a function of accepting operation input from a user and a function of displaying various screens, and is portable by the user. 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 consent information indicating the user's consent 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 the user's consent. 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 the user's consent to the server 2. When the update process is started in the vehicle 1, the user terminal 3 receives progress information from the server 2 and notifies the user of the received progress information.

[0018] Next, the configurations 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.

[0019] 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 to and from 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 to and from the user terminal 3, the user terminal 3 needs to be located within the range of the wireless communication network 4.

[0020] The database 22 stores 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 mounted on 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 for 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, an estimated time until the download of the distribution package is completed (estimated download time), an estimated time until the update process in the vehicle 1 is completed (estimated update process time), etc.

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

[0022] The control device 23 calculates the estimated update processing time 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 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.

[0023] The control device 23 may calculate the estimated update processing time based on the type of the ECU to be updated instead of or in addition to the data size of the update data. For example, the control device 23 calculates the estimated update processing time based on the specifications of the microcomputer and / or the flash memory included in the ECU. For example, when the operating frequency of the microcomputer included in the ECU to be updated is higher than a predetermined reference frequency, the control device 23 calculates the estimated update processing time to be shorter than when the operating frequency of the microcomputer is lower than the predetermined reference frequency. This is based on the viewpoint that the higher the operating frequency of the microcomputer, the shorter the time required for the update processing. For example, when the memory capacity of the flash memory included in the ECU to be updated is larger than a predetermined reference capacity, the control device 23 calculates the time required for the update processing to be longer than when the memory capacity of the flash memory is lower than the predetermined reference capacity. This is based on the viewpoint that the larger the memory capacity of the flash memory, the larger the file size of the program and the longer the time required for the update processing. The calculation method of the estimated update processing time is just an example, and the control device 23 may calculate the estimated update processing time using other calculation methods.

[0024] The following describes the configuration of the user terminal 3. As shown in FIG.

[0025] 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. For example, the terminal HMI 32 may be 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. When 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. When 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.

[0026] 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 an approval request process for requesting approval from the user in the software update process of the ECU of the vehicle 1. Taking a case where the user is requested to approve the start of the update process as an example, the terminal control device 33 generates an approval request image for requesting approval from the user for the start of the update process, outputs the approval request image to the terminal HMI 32, and displays the approval request image on the terminal HMI 32.

[0027] When the user terminal 3 is located within the range of the wireless communication network 4, the user outside the vehicle 1 can perform procedures related to the software update by inputting operations while checking various information related to the software update on the user terminal 3. Note that the above-mentioned block configuration and functions of the user terminal 3 are merely an example and are not limited to the user terminal 3. Furthermore, in this embodiment, an example is described in which a user uses the user terminal 3 to perform procedures related to the update process, 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 uses the in-vehicle terminal 12 to perform procedures related to the update process.

[0028] Next, the configuration of the vehicle 1 will be described. As shown in Fig. 1, the 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. The components included in the vehicle 1 are connected to each other by an in-vehicle network such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN).

[0029] 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).

[0030] The in-vehicle terminal 12 is a terminal having a function of receiving an operation input from a user (passenger) riding in the vehicle 1 and a function of displaying various screens. An example of the in-vehicle terminal 12 is a touch panel display. A signal for notifying various information to the occupant is 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, for example, when the occupant performs an operation indicating consent to the start of the update process on the in-vehicle terminal 12, 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 an operation input while checking various information related to the software update on the in-vehicle terminal 12, and perform a procedure 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.

[0031] The ignition switch 13 functions as a start switch for the vehicle 1 and is a switch for turning on or off the ignition of the vehicle 1. 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.

[0032] The body system ECU 14A, the driving system ECU 14B, and the multimedia system ECU 14C are examples of ECUs to be updated by the software update device 10. Each ECU has, as functional blocks, a microcomputer composed of a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), and a flash memory, a power supply circuit, a data transfer circuit, and the like. The flash memory stores programs for implementing the software of the ECU. The software of the ECU is implemented by the microcomputer executing the programs stored in the flash memory to perform various processes.

[0033] 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 microcomputer executes the program, 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, in 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 are referred to as the first memory and the second memory hereinafter.

[0034] 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 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 drive of the brakes of the vehicle 1, and a power steering control ECU that controls the drive 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.

[0035] A control signal for the update process is input from the software update device 10 to the body system ECU 14A, the driving system ECU 14B, and the multimedia system ECU 14C, and the software update process is executed in each ECU. Although one ECU is shown in FIG. 1, the number of ECUs to be updated is not particularly limited, and the software update system 100 can update software for a plurality of ECUs to be updated. The body system ECU 14A, the driving system ECU 14B, and the 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. The vehicle 1 may also be equipped with ECUs other than the ECUs shown in FIG. 1.

[0036] The power supply system ECU 14D is a general term for 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 an ACC (accessory) power supply and an IG (ignition) power supply mounted on the vehicle 1. A control signal for an 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.

[0037] Here, an overview of the OTA software update flow and its relationship with the memory configuration of the ECU will be described with reference to Figs. 2 and 3. 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 through a number of 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).

[0038] In step S1, campaign information is transmitted 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 transmitted 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, the completion of the software update is notified to the user via the in-vehicle terminal 12 and / or the user terminal 3.

[0039] FIG. 3 is an explanatory diagram for explaining software update by OTA according to the memory configuration of the ECU. Among the multiple steps shown in FIG. 2, FIG. 3 shows each step of download, installation, activation, and update completion confirmation as an "update state". FIG. 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". FIG. 3(A) is an example of a software update flow when the memory configuration of the ECU is a single bank, and FIG. 3(B) is an example of a software update flow when the memory configuration of the ECU is a double bank.

[0040] 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 the vehicle can be driven (ignition switch 13 is on). After the download is completed, when the ignition switch 13 is switched from on to off while the vehicle 1 is stopped, a "consent request" is made to ask the user for consent to the start of the update process. In this embodiment, the user outside the vehicle 1 performs operation input while checking various information related to the software update on the user terminal 3, and performs the procedure related to the software update.

[0041] After the download from the server 2 is completed, when the occupant (driver) of the vehicle 1 switches the ignition switch from on to off, for example, the user terminal 3 displays information requesting consent to start of the update process (for example, a display of "Do you want to update the software?") and two icons that the user can operate, an icon indicating consent (for example, a display of "Now") and an icon indicating refusal (for example, a display of "Later"). When the user consents to start of the update process and presses the "Now" icon, "installation" using the update data is performed in the vehicle 1. Specifically, in the flash memory of the ECU, a rewrite process is performed in which the old program is deleted and then a new program is written. When the rewrite process is completed, "activation" is performed in which the microcomputer of the ECU reads the new program. After that, the vehicle 1 is powered on and the software update is completed after a process of rebooting the vehicle 1. When the software update is completed, the user terminal 3 displays an update completion notification indicating that the update has been completed (for example, a display of "Software update has been completed"). After the update process is completed, the power supply system ECU 14D executes a process of turning off the ignition of the vehicle 1. On the other hand, if the user does not consent to the start of the update process and presses the "Later" icon, the power supply system ECU 14D executes a process of turning off the ignition of the vehicle 1 without starting the software update process of the ECU in the vehicle 1. In addition, the user terminal 3 displays an update process postponement notice indicating the postponement of the update process (for example, a display of "Postponed until next time").

[0042] As shown in FIG. 3B, when the memory configuration of the ECU is double bank, the vehicle 1 performs "downloading" of the distribution package and "installation" using the update data while the vehicle 1 is in a running state. When the microcomputer of the ECU 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 completed, when the occupant (driver) of the vehicle 1 switches the ignition switch 13 from on to off, an "approval request" is made to request the user to approve the start of the update process. As in the example of FIG. 3A, the user terminal 3 displays, for example, information requesting approval for the start of the update process, an icon indicating approval, and an icon indicating refusal. When the user approves the start of the update process, an "activation" is performed to change the memory from which the microcomputer reads from the first memory to the second memory. After that, the vehicle 1 is powered on and the software update is completed.

[0043] Thus, the specific content of the software update process varies between "installation" and "activation" and "activation" depending on the configuration of the flash memory of the ECU. In any case, the vehicle 1 executes the update process when the occupant is asked to consent to the start of the update process and the occupant performs an operation to consent to the start of the update process. In addition, when the update process is completed, the user can know that the update process is completed through the update completion notice displayed on the user terminal 3. For example, when there is a first user at home and a second user using the vehicle 1, the second user parks the vehicle 1 in a parking lot at home and switches the ignition switch from on to off, and the first user performs a software update procedure via the user terminal 3. After that, when the first user tries to go out using the vehicle 1, the first user who has confirmed the update completion notice can use the vehicle 1 in a state in which the software update process has been completed. However, if a loop process or the like occurs during the update process due to some abnormality and the update process is not completed (if the update process is abnormally terminated), didIn this case, the update completion notification is not displayed on the user terminal 3, and therefore the first user may not be able to use the vehicle 1. Therefore, the software update device 10 according to this embodiment aims to solve the above problem by using the following configuration and method.

[0044] Next, the software update device 10 will be described. As shown in Fig. 4, the software update device 10 includes a controller 40. Fig. 4 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, a CPU that executes the program stored in the memory, and the like. Note that, as the operating circuit, an MPU, a DSP, an ASIC, an FPGA, and the like can be used instead of or together with the CPU.

[0045] 4, 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 process execution unit 45, a control unit 50, and a power process execution unit 51. The controller 40 realizes the functions of the functional blocks by software stored in the memory.

[0046] The information acquisition unit 41 acquires update processing information related to software update from the server 2 via the in-vehicle communication device 11. The update processing information includes the campaign information and the 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. The information acquisition unit 41 also acquires a signal indicating a user operation on the user terminal 3 via the server 2. For example, when the user presses the consent display displayed on the user terminal 3, the information acquisition unit 41 acquires a signal indicating that the consent display has been pressed by the user from the user terminal 3 via the server 2. For example, when the user presses the rejection display displayed on the user terminal 3, the information acquisition unit 41 acquires a signal indicating that the rejection display has been pressed by the user from the user terminal 3 via the server 2.

[0047] 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 mounted on the vehicle 1 (such as the memory configuration of the ECU). The various pieces of information stored in the memory unit 42 are used for processing by the update process execution unit 45.

[0048] The output unit 43 outputs consent request information that requests the user 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 voice, but the method of requesting the user to consent is not particularly limited. For example, the display image of "Do you want to update the software?" as described above is read from the memory, and the image signal is transmitted to the server 2 via the in-vehicle communication device 11. Also, for example, the output unit 43 may transmit a voice signal that requests the user to consent to the start of the update process to the server 2 via the in-vehicle communication device 11 together with or instead of the image signal. The consent request information transmitted from the in-vehicle communication device 11 is received by the server 2, and then transmitted from the server 2 to the user terminal 3.

[0049] 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 has switched from an on state to an off state. Note that the output condition by the output unit 43 is an example, and other conditions may be used as the output condition.

[0050] The start determination unit 44 determines whether or not to start the update process by the update process execution unit 45. When the user 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 when the user 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. For example, when the user performs an operation on the user terminal 3 indicating consent to start the update process, as described above, the information acquisition unit 41 acquires consent information from the server 2, and the start determination unit 44 determines to start the update process. On the other hand, when the user performs an operation on the user terminal 3 indicating refusal to start the update process, as described above, the information acquisition unit 41 acquires refusal information from the server 2, and the start determination unit 44 determines not to start the update process.

[0051] The update process execution unit 45 executes the update process according to answer information, which is a user's answer to the consent request information. When the start determination unit 44 determines that the update process is to be started, the update process execution unit 45 executes the update process, and when the start determination unit 44 determines that the update process is not to be started, the update process execution unit 45 postpones the execution of the update process. When the update process in the update target ECU is normally completed, an update process completion notification is input to the update process execution unit 45 from the update target ECU, and the update process execution unit 45 outputs the input notification to the control unit 50. Note that when the start determination unit 44 determines that the update process is not to 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.

[0052] The update process execution unit 45 includes an install execution unit and an activate execution unit according to the memory configuration of the ECU to be updated as a functional block for executing the update process. As shown in FIG. 4, the update process execution unit 45 includes a first install execution unit 46 and a first activate execution unit 47 corresponding to a single-bank memory configuration, and a second install execution unit 48 and a second activate execution unit 49 corresponding to a double-bank memory configuration. As described with reference to FIG. 3, the process 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, a plurality of install execution units and a plurality of activate execution units are provided. When the memory configuration of the ECU to be updated is single-bank, the first install execution unit 46 installs a new program, and the first activate 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 install execution unit 48 installs a new program, and the second activate execution unit 49 activates the new program. The update process execution unit 45 determines the memory configuration of the ECU to be updated from the information about the ECU mounted on the vehicle 1 stored in the storage unit .

[0053] 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 included in the ECU to be updated.

[0054] 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 of the microcomputer included in the ECU to be updated from the first memory to the second memory.

[0055] The control unit 50 determines the target program to be executed by the ECU to be updated based on the estimated time required for the update process. In this embodiment, the estimated time required for the update process is the estimated update process time calculated by the server 2. As described with reference to FIG. 3, the specific content of the update process varies depending on the memory configuration of the ECU to be updated, and includes "installation" and "activation" and "activation". For this reason, the breakdown of the estimated update process time calculated by the server 2 varies depending on the specifications of the ECU to be updated. Specifically, when the memory configuration of the ECU to be updated is a single bank, the estimated update process time is composed of the time required for installation and the time required for activation. When the memory configuration of the ECU to be updated is a double bank, the estimated update process time is composed of the time required for activation.

[0056] If the update process is not completed within the estimated update process time, the control unit 50 causes the update target ECU to execute the old program corresponding to the pre-update software. On the other hand, if the update process is completed within the estimated update process time, the control unit 50 causes the update target ECU to execute the new program corresponding to the updated software.

[0057] For example, when the update process is started by the update process execution unit 45, the control unit 50 starts a timer for measuring the update process time and starts measuring the elapsed time from the start of the update process. The control unit 50 waits for an update process completion notification to be input from the update process execution unit 45 while comparing the elapsed time with the estimated update process time. If the update process completion notification is input with an elapsed time shorter than the estimated update process time, the control unit 50 causes the microcomputer provided in the ECU to be updated to execute the new program. On the other hand, if the elapsed time exceeds the estimated update process time, the control unit 50 causes the microcomputer provided in the ECU to be updated to execute the old program.

[0058] The process of the control unit 50 when the elapsed time exceeds the estimated update process time will be described in more detail. When the elapsed time exceeds the estimated update process time, the control unit 50 executes different processes according to the memory configuration of the ECU to be updated. case, The control unit 50 executes rollback processing on the ECU to be updated. Rollback means writing or rewriting to return the flash memory of the ECU to a predetermined state, such as returning a program version to the original state, when the update processing is interrupted. In other words, rollback means returning the state of the ECU to be updated to the state before the update processing was started, as seen from the user. The control unit 50 can apply rollback processing known at the time of filing of this application. For example, when a rollback program is included in the distribution package, the control unit 50 executes rollback processing on the ECU to be updated using the rollback program.

[0059] In the case of a double-bank memory configuration, the control unit 50 stores the new program in the flash memory of the ECU to be updated. For example, if the old program is stored in the first memory and the new program is written to the second memory, the control unit 50 stores the new program written to the second memory. As in the example of FIG. 3B, when installation is performed with the ignition switch 13 on and writing of the new program to the second memory is completed, the control unit 50 Estimated update process time Even if the update process is not completed within new Save the program.

[0060] The power supply process execution unit 51 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.

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

[0062] 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 authentication processing of the update data, and an estimated update processing time. In step S12, the controller 40 acquires the estimated update processing time from the distribution package acquired in step S11.

[0063] In step S13, the controller 40 determines whether or not 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 S14, and if the ignition switch 13 remains on, the controller 40 waits in step S13 until the occupant switches the ignition switch from on to off.

[0064] In step S14, the controller 40 outputs consent request information for requesting consent to the start of the software update process from the user. In this embodiment, the controller 40 transmits the consent request information to the server 2 via the in-vehicle communication device 11. The consent request information is then transmitted from the server 2 to the user terminal 3.

[0065] In step S15, the controller 40 judges whether or not the user has accepted the consent request information output in step S14. If the user has performed an operation on the user terminal 3 indicating acceptance of the start of the update process, consent information is transmitted from the user terminal 3 to the server 2 as the user's response information to the consent request information. The controller 40 acquires the consent information from the server 2 and judges to start the update process. In this case, the process proceeds to step S16. On the other hand, if the user has performed an operation on the user terminal 3 indicating refusal to start the update process, refusal information is transmitted from the user terminal 3 to the server 2 as the user's response information to the consent request information. The controller 40 acquires the refusal information from the server 2 and judges not to start the update process. In this case, the process proceeds to step S19.

[0066] If it is determined in step S15 that the user has accepted, the process proceeds to step S16. In step S16, the controller 40 starts a software update process for the ECU to be updated. Specifically, when the memory configuration of the ECU is a single bank, the controller 40 executes an installation process and an activation process as shown in the example of FIG. 3(A). The above explanations are used for the specific contents of each process. Also, in this step, the controller 40 starts a timer for measuring the update process time, and starts measuring the elapsed time from the start of the update process.

[0067] In step S17, the controller 40 determines whether the update process started in step S16 has been normally completed. If an update process completion notification is input to the controller 40 from the update target ECU, the controller 40 determines that the update process has been normally completed. In this case, the process proceeds to step S18. On the other hand, if an update process completion notification is not input from the update target ECU, the controller 40 determines that the update process has not been normally completed. In this case, the process proceeds to step S20.

[0068] If it is determined in step S17 that the update process has been normally completed, the process proceeds to step S18. In step S18, the controller 40 determines the target program to be executed by the update target ECU as a new program, and causes the update target ECU to execute the new program. In step S19, 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 by the occupant in step S13. Specifically, the controller 40 outputs a control signal to turn off the ignition of the vehicle 1 to the power supply system ECU 14D. When the process of step S19 ends, the process in the flowchart shown in FIG. 5 ends.

[0069] If it is determined in step S17 that the update process has not ended normally, step S 20 In step S29, the controller 40 determines whether the update process has ended abnormally. For example, if an abnormal end notification is received from the update target ECU, the controller 40 determines that the update process has ended abnormally. In this case, the process proceeds to step S21. On the other hand, if an abnormal end notification is not received from the update target ECU, the controller 40 determines that the update process has not ended abnormally. In this case, the process proceeds to step S22.

[0070] If it is determined in step S20 that the update process has ended abnormally, the process proceeds to step S21. In step S21, the controller 40 determines the target program to be executed by the update target ECU as the old program, and causes the update target ECU to execute the old program. For example, the controller 40 performs a rollback process on the update target ECU. When the process of step S21 ends, the process proceeds to step S19, and the controller 40 executes the process of step S19 described above.

[0071] If it is determined in step S20 that the update process has not ended abnormally, the process proceeds to step S22. In step S22, the controller 40 determines whether the elapsed time that began to be measured in step S16 has exceeded the estimated update process time acquired in step S12. If the controller 40 determines that the elapsed time has exceeded the estimated update process time, the process proceeds to step S21, where the controller 40 executes the process in step S21 described above. On the other hand, if the controller 40 determines that the elapsed time has not exceeded the estimated update process time, the process returns to step S17, and thereafter, the processes in the steps described above are executed until the process in FIG. 5 is completed.

[0072] Regarding the flow chart when the memory configuration of the ECU to be updated is double bank, only steps different from the processing for a single bank will be described with reference to Fig. 5. 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 above explanation will be used.

[0073] In step S12, the controller 40 obtains the estimated time of the activation process as the estimated update process time. Therefore, the comparison target with the elapsed time in step S22 is the estimated processing time of the activation process. In step S16, the controller 40 executes the activation process as the software update process for the ECU to be updated. If the memory configuration of the ECU is double bank, the controller 40 executes the activation process as shown in the example of FIG. 3(B). The above explanation is used for the specific contents of the process. In step S21, the controller 40 saves the new program written in the memory, and switches the read destination of the ECU's microcomputer to the memory in which the old program is stored.

[0074] As described above, the software update device 10 according to this embodiment is a software update device that updates the software of 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, an update process execution unit 45, and a control unit 50. 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 answer information that is a user's answer to the consent request information. The control unit 50 determines a target program to be executed by the update target ECU based on the update process estimated time. In addition, if the update process is not completed within the update process estimated time, the control unit 50 causes the update target ECU to execute the old program, and if the software update is completed within the update process estimated time, causes the update target ECU to execute the new program.

[0075] One possible cause of an error that causes the software update process to not end is the surrounding environment of the ECU to be updated. For example, if the surrounding temperature of the ECU to be updated rises due to some reason, the ECU to be updated executes a self-diagnosis process based on the detection result of the temperature sensor, and the calculation load of the microcomputer increases. Go up The computational load on the microcomputer Go upIt is believed that this will slow down the processing speed of the microcomputer, leading to an error that prevents the update process from ending. However, according to the software update device 10, the software update system 100, and the software update method according to the present embodiment, even if an error that prevents the update process from ending occurs due to such a cause, the target program to be executed by the update target ECU can be determined, so that the vehicle 1 becomes usable and the user can use the vehicle 1.

[0076] In this embodiment, the information acquisition unit 41 acquires an update processing estimated time from the server 2. As a result, the software update device 10 time Since the target program to be executed by the update target ECU can be determined without calculating the above, the calculation load on the software update device 10 can be reduced.

[0077] In this embodiment, the ECU to be updated has a flash memory that stores an old program, and the update process execution unit 45 includes a first installation execution unit 46 and a first activation execution unit 47. The first installation execution unit 46 executes an installation process to write a new program to the flash memory after deleting the old program from 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. If the update process is not completed within the estimated update process time, the control unit 50 executes a rollback process on the ECU to be updated. This makes it possible to determine the target program to be executed by the ECU to be updated when an error occurs that prevents the update process from being completed, even if the memory configuration of the ECU to be updated is a single bank.

[0078] In this embodiment, the ECU to be updated has a flash memory configured with a double bank of a first memory for storing an old program and a second memory, and the update process execution unit 45 includes a second installation execution unit 48 and a second activation execution unit 49. The second installation execution unit 48 writes a new program to the second memory. The second activation execution unit 49 executes an activation process for switching the program read destination of the microcomputer from the first memory to the second memory. The control unit 50 stores the new program written in the second memory as a process for when the update process is not completed within the estimated update process time. Since the new program can be stored in the second memory of the ECU to be updated, it is not necessary to install it when the update process is performed again, and the calculation load of the software update device 10 can be reduced.

[0079] In the software update system 100 according to the present embodiment, the server 2 calculates the estimated update processing time based on at least one of the size of the update data and the type of the ECU to be updated. This reduces the computation load on the software update device 10.

[0080] In this embodiment, an example has been described in which the software update device 10 obtains the estimated update processing time from the server 2, but the entity that calculates the estimated update processing time is not limited to the server 2, and the software update device 10 may calculate the estimated update processing time.

[0081] As a modification of this embodiment, the controller 40 may have, as a functional block, a calculation unit that calculates an estimated update processing time based on at least one of the data size of the update data and the type of the ECU to be updated. 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 storage unit 42, the calculation unit may refer to the map to calculate an estimated update processing time according to the data size. As another example, the calculation unit may calculate a longer estimated update processing time as the data size of the update data increases. As another example, The calculation part isAlternatively, the estimated update processing time may be calculated based on the specifications of the microcomputer and / or flash memory included in the ECU. As a specific example of the calculation method, the example of the calculation method in the control device 23 described above is used. As in the modified example, the software update device 10 calculates the estimated update processing time, thereby reducing the calculation load on the server 2. Note that the timing at which the controller 40 calculates the estimated update processing time is not particularly limited as long as it is before the update processing is started, but for example, in step S12 of the flowchart in FIG. 5, the controller 40 calculates the estimated update processing time instead of acquiring the estimated update processing time.

[0082] Second Embodiment Next, a software update device according to the second embodiment will be described. In the above-mentioned first embodiment, among the steps of software update by OTP shown in FIG. 2, installation (step S3) and activation (step S4) are taken as examples, but in this embodiment, an example including download (step S2) in addition to installation and activation will be described. For example, after the notification of campaign information in step S1, the user is asked to consent to start update, and if the user consents, download to activation are performed in sequence without the user being asked to consent thereafter. One example is a situation in which software update by OTP is performed in a situation in which the vehicle is not being used by the user, such as when the vehicle is parked in a parking lot at home.

[0083] The software update system according to the second embodiment has the same configuration as the software update system 100 according to the first embodiment, except for the estimated time calculated by the server 2 and the functional blocks included in the controller 60 of the software update device 10. Therefore, the above-mentioned explanation will be used for the same configuration as the first embodiment.

[0084] In this embodiment, the server 2 calculates an estimated time until the software update is completed (estimated update completion time) by combining an estimated download time until the download of the distribution package is completed and the estimated update processing time in the first embodiment. The server 2 distributes campaign information including the estimated update completion time to one or more vehicles 1.

[0085] The control device 23 of the server 2 calculates the estimated download time based on the data size of the distribution package. For example, if a map showing the relationship between the data size of the distribution package and the estimated download time is stored in advance in the database 22, the control device 23 refers to the map and calculates the estimated download time according to the data size. Also, for example, the larger the data size of the distribution package, the longer the estimated download time calculated by the control device 23.

[0086] Next, the controller of this embodiment 60 The functional blocks of the above will be described. FIG. 6 is an example of functional blocks of the controller 60 of the software update device 10 according to this embodiment. In this embodiment, the controller 60 has a communication status acquisition unit 52, a correction unit 53, and a notification unit 54 in addition to the functional blocks in the first embodiment. In this embodiment, the function of the output unit 43 is partially different from that in the first embodiment. The controller 60 realizes each function of the functional blocks by software stored in the memory. Note that the description in the first embodiment is used for the functional blocks similar to those in the first embodiment.

[0087] In this embodiment, the output unit 43 outputs consent request information that prompts the user to decide whether or not to consent to the software update, including not only the update process by the update process execution unit 45 but also the download of the distribution package from the server 2. For specific examples of the consent request information and the method for transmitting the consent request information to the user terminal 3, the explanation in the first embodiment is cited. Also, in this embodiment, the output unit 43 outputs the consent request information during the period from when the information acquisition unit 41 acquires the campaign information to when the information acquisition unit 41 acquires the distribution package.

[0088] The communication status acquisition unit 52 acquires communication status information regarding the communication status with the server 2. The communication status acquisition unit 52 detects the communication status between the in-vehicle communication device 11 and the communication device 21 of the server 2, and acquires the detected communication status as communication status information. For example, when communication is not established between the in-vehicle communication device 11 and the communication device 21, the communication status acquisition unit 52 detects that the communication status is abnormal. The communication status acquisition unit 52 may also calculate a delay time in wireless data communication. The delay time includes a fixed delay time determined by the capability of the in-vehicle communication device 11, and a delay time that varies depending on the number of communication devices accessing the wireless communication network 4, the size of data to be communicated (communication fee), and the like. The communication status acquisition unit 52 may apply a technology for acquiring a communication status that was known at the time of filing of the present application.

[0089] The correction unit 53 acquires the estimated update completion time from the campaign information, and corrects the estimated update completion time based on the communication status information acquired by the communication status acquisition unit 52. The estimated download time calculated by the server 2 among the estimated update completion times does not take into account the actual communication status, so there is a possibility that the estimated download time differs from the actual download time. For example, since the communication status between the in-vehicle communication device 11 and the communication device 21 is good, the delay time in the wireless data communication may be short, and the actual download time may be earlier than the estimated download time. The correction unit 53 shortens the estimated download time according to the delay time in the wireless data communication. Naturally, since the communication status between the in-vehicle communication device 11 and the communication device 21 is poor, the delay time in the wireless data communication may be long, and the actual download time may be slower than the estimated download time. In this case, the correction unit 53 extends the estimated download time according to the delay time in the wireless data communication included in the communication status information.

[0090] The notification unit 54 outputs information on an update estimated time (hereinafter referred to as a corrected update estimated time) obtained by adding together the estimated download time corrected by the correction unit 53 (hereinafter referred to as a corrected estimated download time) and the update processing estimated time. In this embodiment, the notification unit 54 transmits information on the corrected update estimated time to the server 2 via the in-vehicle communication device 11. The information on the corrected update estimated time transmitted from the in-vehicle communication device 11 is received by the server 2, and is then transmitted from the server 2 to the user terminal 3. The information on the corrected update estimated time is displayed on the user terminal 3, thereby notifying the user of the corrected estimated time.

[0091] In addition, the notification unit 54 may output the corrected estimated update time as an output condition for outputting information on the corrected estimated update time when the corrected estimated update time is longer than the estimated update time calculated by the server 2 (hereinafter referred to as the estimated update time before correction) by a predetermined threshold time or more. The predetermined threshold time may be, for example, a time in minutes, such as 5 minutes, that is set in advance. If the actual update time is expected to be significantly later than the estimated time, it is highly likely to affect the user's decision on whether or not to accept the update, so the notification unit 54 notifies the user of the corrected update time before the distribution package is downloaded. On the other hand, if the corrected estimated update time is shorter than the estimated update time before correction, the notification unit 54 may not output the corrected estimated time. If the actual update time is expected to be earlier than the estimated time, it is unlikely to affect the user's decision on whether or not to accept the update, so the notification unit 54 does not notify the user of the corrected update time before the distribution package is downloaded.

[0092] Next, an example of a software update method according to this embodiment will be described with reference to the flowchart of FIG. 7. The flowchart shown in FIG. 7 is executed by the controller 60 of the software update device 10 shown in FIG. 6. The flowchart in FIG. 7 is a flowchart for the case where the memory configuration of the ECU to be updated is a single bank. The flowchart in FIG. 7 is a flowchart of the steps from notification of campaign information (step S1) to confirmation of update completion (step S5) shown in FIG. 2. 5 It contains some of the same steps as the flowchart in FIG. 5 The same steps are shown in Figure 5 The steps are numbered the same as those in FIG. 5 The above-mentioned explanation is applied to the same steps as those in the flowchart of FIG. 7. In the flowchart of FIG. 7, the ignition switch 13 is turned off. 5 In the flowchart of FIG. 7, step S19 shown in FIG. 5 The process in step S19 shown in FIG.

[0093] In step S31, the controller 60 acquires (downloads) campaign information from the server 2 via the in-vehicle communication device 11. The campaign information includes the data size of the update data, information for identifying the ECU to be updated, information on the version of the software to be updated, a summary of the functions to be updated, an estimated download time, and an estimated update processing time. In step S32, the controller 60 acquires an estimated update time, which is the sum of the estimated download time and the estimated update processing time, from the campaign information acquired in step S31.

[0094] In step S33, the controller 60 corrects the estimated download time, which is included in the estimated update time acquired in step S32, based on communication status information related to the communication status with the server 2. The controller 60 outputs a corrected estimated update time obtained by adding up the corrected estimated download time and the update processing estimated time acquired in step S31. In this embodiment, the controller 60 transmits the corrected estimated update time to the user terminal 3 via the in-vehicle communication device 11 and the server 2.

[0095] In step S34, the controller 60 outputs consent request information for requesting consent to the software update from the user. In this embodiment, the controller 60 transmits the consent request information to the user terminal 3 via the in-vehicle communication device 11 and the server 2.

[0096] In step S35, the controller 60 determines whether or not the user has consented to the consent request information output in step S34. When the user performs an operation on the user terminal 3 indicating consent to the software update, consent information is transmitted from the user terminal 3 to the server 2 as the user's response information to the consent request information. The controller 60 acquires the consent information from the server 2 and determines to start the software update. Furthermore, in this embodiment, when it is determined that the user has consented, the controller 60 starts a timer for measuring the download time of the distribution package and the update processing time, and starts measuring the elapsed time from the download of the distribution package.

[0097] On the other hand, if the user performs an operation on the user terminal 3 indicating refusal to start the update process, refusal information is transmitted from the user terminal 3 to the server 2 as the user's response information to the consent request information. The controller 60 acquires the refusal information from the server 2, and the process in the flowchart shown in FIG. 7 ends.

[0098] If it is determined in step S35 that the user has accepted, the process proceeds to step S11, where the controller 60 starts downloading the distribution package, as in the first embodiment. After the downloading of the distribution package is completed, the process proceeds to step S16, where the controller 60 starts the update process, as in the first embodiment.

[0099] Step S36 is shown in FIG. 5 This step corresponds to step S22 shown in FIG. 36 In step S35, the controller 60 compares the measurement time that started to be measured when the user consented with the corrected estimated update time corrected in step S33, and judges whether the elapsed time has exceeded the corrected estimated update time. Since this is the same as step S22 except that the calculation start timing of the elapsed time and the object to which the elapsed time is compared are different, the above-mentioned explanation is applied.

[0100] As described above, the software updating device 10 according to this embodiment includes the communication status acquisition unit 52, the correction unit 53, and the notification unit 54. The communication status acquisition unit 52 acquires communication status information regarding the communication status with the server 2. The correction unit 53 corrects the estimated update time based on the communication status information. The notification unit 54 outputs information on the corrected estimated update time. This makes it possible to improve the accuracy of the estimated download time. In addition, since the estimated update time including the estimated download time can be notified to the user, the user can recognize the estimated time required to update the software including download.

[0101] In this embodiment, when the corrected estimated update time is longer than the pre-correction estimated update time by a predetermined threshold time or more, the notification unit 54 outputs information on the corrected estimated update time. This allows the user to recognize the estimated time that takes into account the actual communication situation, even if the actual download time is slower than the estimated download time because of poor communication conditions between the in-vehicle communication device 11 and the communication device 21, for example.

[0102] In this embodiment, when the corrected estimated update time is shorter than the estimated update time before correction, the notification unit 54 does not output information on the corrected estimated update time. This makes it possible to omit the process of notifying the user of the estimated time when, for example, the communication state between the in-vehicle communication device 11 and the communication device 21 is good and the actual download time is faster than the estimated download time. As a result, it is possible to shorten the time required for the entire software update flow by OTP.

[0103] The above-described embodiments are described for the purpose of facilitating understanding of the present invention, and are not described for the purpose of limiting the present invention. Therefore, the elements disclosed in the above embodiments are intended to include all design modifications and equivalents that fall within the technical scope of the present invention.

[0104] For example, in the above-mentioned first embodiment, the flow in which the distribution package is downloaded while the vehicle 1 is in a state in which it is possible to travel has been described as an example, but the "estimated update processing time" in the first embodiment can be replaced with the "estimated update time obtained by adding up the estimated download time and the estimated update processing time" in the second embodiment. For example, in the modified example of the first embodiment, the controller 40 has a calculation unit that calculates the estimated update processing time, but the controller 60 according to the second embodiment may have a calculation unit that calculates the estimated download time out of the estimated update time. When the vehicle 1 travels along a travel route, the information acquisition unit 41 acquires information on the travel route of the vehicle 1 from a navigation system (not shown) of the vehicle 1. The calculation unit calculates the estimated download time based on the communication status information acquired by the communication status acquisition unit 52 and the travel route of the vehicle 1 acquired by the information acquisition unit 41. For example, the calculation unit acquires communication status information of the wireless communication network 4 at multiple points on the travel route from a communication map indicating the communication status of the wireless communication network 4 provided by a communication carrier. The calculation unit calculates an estimated download time when the vehicle 1 travels along the travel route based on the communication status information on the travel route of the vehicle 1. This can improve the accuracy of the estimated download time when downloading a distribution package while the vehicle 1 is in a drivable state.

[0105] In addition, for example, in the second embodiment described above, the estimated update time is corrected, but the present invention is not limited to the above. The controller 60 may determine the execution target program of the ECU to be updated by using the estimated update time before correction.

[0106] Also, for example, in the second embodiment described above, the process from download (step S2) to update completion shown in FIG. confirmationAlthough the flow in which no consent request is made to the user until (step S5) has been described as an example, the controller 60 may output consent request information that asks the user whether to consent to the start of processing before starting processing of each step. In addition, the controller 60 may execute a rollback process on the update target ECU as a process when the memory configuration is double bank and the elapsed time exceeds the estimated update time (including the corrected one). For example, in the flowchart of FIG. 7, it is assumed that the actual download time becomes longer than the estimated download time, and it is determined that the elapsed time exceeds the corrected estimated update time during the installation process (determined as Yes in step S36). In this case, since writing of the new program to the second memory is not completed, the controller 60 executes a rollback process on the update target ECU. Even if the memory configuration of the update target ECU is double bank and writing of the new program is not completed, the target program to be executed by the update target ECU can be determined, so that the vehicle 1 becomes available and the user can use the vehicle 1.

[0107] Furthermore, for example, the controller 60 may include a measurement unit that measures the actual time required from the start to the completion of the update process. When the measurement by the measurement unit is completed, the output unit 43 transmits information on the actual time required for the update process to the server 2 via the in-vehicle communication device 11. This makes it possible to reflect the actual time required for the update process for other vehicles 1 that have not yet completed the software update, thereby improving the accuracy of the update process estimated time. [Explanation of symbols]

[0108] 100…Software update system 1. Vehicle 10...Software update device 40…Controller 41…Information acquisition department 42...Storage section 43...Output section 44...Start determination section 45...Update processing execution unit 46…First installation execution section 47…First activation execution unit 48…Second installation execution part 49…Second activation execution unit 50...Control unit 51...Power supply processing execution unit 11...In-vehicle communication device 12…In-vehicle terminal 13…Ignition switch 14A…Body ECU 14B…Driving system ECU 14C...Multimedia ECU 14D…Power system ECU 2. Server 21...Communication equipment 22…Database 23...Control device 3. User terminal 31...Terminal communication device 32...Terminal HMI 33...Terminal control device

Claims

1. 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 software update; an execution unit that executes the software update process in response to answer information that is an answer of the user to the consent request information; a calculation unit that calculates an estimated time required for the update before the output unit outputs the approval request information and before the execution unit executes the software update process; A communication status acquisition unit that acquires communication status information regarding a communication status between the server and the communication status acquisition unit; a correction unit that corrects the estimated time based on the communication status information before the output unit outputs the approval request information and before the execution unit executes the software update process; a notification unit that outputs information on the corrected estimated time before the output unit outputs the consent request information and before the execution unit executes the software update process, The software updating device, wherein the notification unit does not output information about the corrected estimated time when the corrected estimated time is shorter than the estimated time before correction.

2. 2. The software update device according to claim 1, The software updating device, wherein the calculation unit calculates the corrected estimated time based on a size of data used to update the software.

3. 3. The software update device according to claim 1, a control unit that determines a target program to be executed by the in-vehicle control device based on the corrected estimated time, 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 control unit executes a rollback process on the in-vehicle control device when the update process is not completed within the corrected estimated time.

4. 3. The software update device according to claim 1, a control unit that determines a target program to be executed by the in-vehicle control device based on the corrected estimated time, 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 control unit stores the second program written in the second memory as a process for when the update process is not completed within the estimated time.

5. 5. The software update device according to claim 4, The control unit executes a rollback process on the in-vehicle control device as a process in a case where the update is not completed within the corrected estimated time.

6. 3. The software update device according to claim 1, a measurement unit that measures an actual time required from the start to the completion of the update process; The output unit outputs information on the actual required time to the server.

7. 3. The software update device according to claim 1, a control unit that determines a target program to be executed by the in-vehicle control device based on the estimated time; The control unit is If the update is not completed within the estimated time, the vehicle control device executes a program corresponding to the pre-update software; If the update is completed within the estimated time, the software update device causes the vehicle-mounted control device to execute a program corresponding to the updated software.

8. The software update device according to any one of claims 1 to 7, The calculation unit is a software update device provided in the vehicle.

9. 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 software update; an execution unit that executes the software update process in response to answer information that is an answer of the user to the consent request information; A communication status acquisition unit that acquires communication status information regarding a communication status between the server and the communication status acquisition unit; a correction unit that corrects an estimated download time required for the update, the estimated download time being a period until downloading of the update process information from the server is completed, based on the communication status information, before the output unit outputs the approval request information and before the execution unit executes the software update process; a notification unit that outputs information on the corrected estimated update time including the corrected estimated download time before the output unit outputs the consent request information and before the execution unit executes the software update process; a control unit that determines a target program to be executed by the in-vehicle control device based on the update estimated time before or after the correction; the notification unit outputs information on the corrected estimated update time when the corrected estimated update time is longer than the uncorrected estimated update time by a predetermined threshold time or more, The control unit is if the update is not completed within the estimated update time before or after the correction, causing the in-vehicle control device to execute a program corresponding to the pre-update software; a software update device that causes the vehicle-mounted control device to execute a program corresponding to the updated software when the update is completed within the estimated update time before or after the correction;

10. 10. A software updating system comprising: the software updating device according to claim 1; and the server.

11. 10. The software update system of claim 9, A software update system in which the server calculates the corrected estimated update time based on at least one of a size of data used to update the software and a type of the in-vehicle control device.

12. 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; Calculating an estimated time required for said update; Acquire communication status information regarding the communication status with the server; correcting the estimated time based on the communication status information; Outputting the corrected estimated time information; outputting, after the information on the corrected estimated time, consent request information for requesting a user to consent to the software update; After outputting the corrected estimated time information, execute the software update process in response to response information which is a response of the user to the consent request information; The step of outputting information on the corrected estimated time includes: not outputting information on the corrected estimated time if the corrected estimated time is shorter than the estimated time before the correction.

Images