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

Abstract

To provide a software update apparatus, a software update system, and a software update method capable of prompting a user whether or not to approve the start of software update processing and determining whether or not to start the update processing even if there is no response from the user.SOLUTION: A software update apparatus is configured to: acquire update processing information related to updating software of an in-vehicle control apparatus from a server provided outside a vehicle; output consent request information prompting a user whether or not to approve the start of the update process; execute update processing according to response information, which is the user's response to the consent request information; determine whether or not to start the update processing based on at least one of the estimated time for the update processing and the importance of software update when the response information is not input for a predetermined period of time after the consent request information is output.SELECTED DRAWING: Figure 1

Description

Technical Field

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

Background Art

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

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the above information processing terminal, since the user's approval process for software update is not considered, even if the user is asked to approve the start of the update process and there is no response from the user, it is difficult to determine whether to start the update process.

[0005] The problem to be solved by the present invention is to provide a software update device, a software update system, and a software update method that can request the user to approve the start of the software update process and can determine whether to start the update process even when there is no response from the user.

Means for Solving the Problems

[0006] The present invention acquires update processing information regarding software update of an in-vehicle control device from a server provided outside the vehicle, outputs commitment request information for asking a user whether to commit to starting the update processing, executes the update processing according to response information which is a response of the user to the commitment request information, and after the commitment request information is output, when the response information is not input for a predetermined time or more, determines whether to start the update processing based on at least one of the required time for the update processing and the importance of updating the software, thereby solving the above problems.

Effect of the Invention

[0007] According to the present invention, it is possible to ask a user whether to commit to starting software update processing and to determine whether to start the update processing even when there is no response from the user.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Embodiments for Carrying Out the Invention

[0009] Hereinafter, embodiments 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.

[0010] <<First Embodiment>> As shown in FIG. 1, the software update device 10 according to the present embodiment is realized as a part of the 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 that can update software such as vehicle control and diagnosis executed by an electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) of the vehicle 1 via OTA (Over The Air). Updating software in this way is also referred to as FOTA (Firmware Over The Air). The software of the ECU is realized by the microcomputer provided in the ECU executing a program. In the present embodiment, as an example of wireless software update of the ECU, the case where the program executed by the microcomputer of the ECU is rewritten wirelessly will be described. However, the software update system 100 can also be applied to the case of wirelessly rewriting data used in various software such as map data used in the navigation system of the vehicle 1 and control parameters used in the ECU. Further, the software update system 100 can also be applied to the case of wirelessly rewriting the function (logic) of the FPGA (Field Programmable Gate Array) when the FPGA is used in the ECU. Also, in FIG. 1, one vehicle is illustrated as the vehicle 1, but the software update system 100 is a system capable of updating software for a plurality of vehicles 1.

[0011] In addition, in the present embodiment, "software update of the ECU" means that the version of the software of the ECU changes to a new version, that is, the program to be executed by the microcomputer changes to a new version. Further, the wireless software update includes, in addition to acquiring and rewriting the program of the new version itself from the outside of the vehicle 1 via wireless, acquiring and rewriting various data used when the program of the new version is executed, and differential data between the program of the new version and the program of the old version, from the outside of the vehicle 1 via wireless. In the following description, data necessary for software update, such as a program of a new version and differential data, is referred to as "update data". Further, the "program of the new version" is referred to as the "new program", the "program of the old version" is referred to as the "old program", and the "differential data between the program of the new version and the program of the old version" is referred to as the "differential data". In addition, in the present embodiment, "completion" means that something has ended normally, and does not include the case where something has ended due to an abnormal situation. For example, "completion of processing" means that the processing has ended normally, and does not include the case where the processing has ended abnormally. In the present embodiment, the user who performs the procedure related to software update is described by taking the passengers (including the driver) of the vehicle 1 as an example.

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

[0013] Vehicle 1 is equipped with an ECU whose software can be updated. Vehicle 1 exchanges various types of information related to software updates with Server 2. Information about each ECU installed in Vehicle 1 is transmitted from Vehicle 1 to Server 2. Examples of information about the ECU include the current version of the software. Information about each ECU installed in Vehicle 1 is transmitted from Vehicle 1 to Server 2 based on predetermined transmission conditions (for example, at predetermined intervals).

[0014] Also, information related to software updates is transmitted from Server 2 to Vehicle 1. Examples of information related to software updates include campaign information, update data, an estimate of the time required for the update process, the importance of the update, etc. A campaign is an event in which Server 2 distributes a delivery package to one or more Vehicles 1. The delivery package includes update data, authentication data used for the authentication process of the update data, etc. 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. When the user approves the start of the software update process, in Vehicle 1, the software update process is executed by the software update device 10 described later. When the update process starts in Vehicle 1, information representing the progress of the update process is transmitted from Vehicle 1 to Server 2.

[0015] Server 2 is a server that coordinates the software update process in the software update system 100 and functions as an OTA center. Server 2 exchanges various types of information related to software updates with Vehicle 1. Server 2 also exchanges various types of information with the user terminal 3.

[0016] Server 2 has a storage function for storing update data, manages the version of each software, the vehicle identification number (VIN) of Vehicle 1 to be updated, the ECU to be updated, etc. with a data management function, manages campaign-related information such as the distribution timing of campaign information with a campaign management function, and has a distribution function for distributing campaign information and update data, etc. For example, when Server 2 receives various information including update data from a provider of update data, it stores the update data in a storage device. Server 2 identifies the VIN that is the distribution target of the update data and the ECU to be updated (hereinafter referred to as the update target ECU) based on the information received from the provider. Server 2 sets the distribution timing of the campaign information, and when the distribution timing of the campaign information arrives, it transmits the campaign information to Vehicle 1 and / or User Terminal 3. When the user approves the transmission of the distribution package to Vehicle 1, Server 2 transmits the distribution package to Vehicle 1. After the transmission of the distribution package by Server 2 is completed, when the update process is started in Vehicle 1, Server 2 receives progress information indicating the progress of the update process from Vehicle 1 and transmits the received progress information to User Terminal 3.

[0017] The user terminal 3 has functions such as receiving operation inputs from the user and displaying various screens, and is a terminal that the user can carry. Examples of the user terminal 3 include smartphones and tablets. The user terminal 3 exchanges various types of information such as campaign information with the server 2. When the user terminal 3 receives campaign information from the server 2, it notifies the user of the campaign information. Also, 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 given consent to the server 2. Further, the user terminal 3 exchanges information regarding the update process with the vehicle 1 via the server 2. When information for requesting the user's consent to start the update process is input from the server 2 to the user terminal 3, the user terminal 3 displays an image for requesting the user's consent. Also, when the user performs an operation on the user terminal 3 indicating consent to start the update process, the user terminal 3 transmits consent information indicating that the user has given consent 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.

[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 with 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. Also, 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 the registration information of the vehicle 1, campaign information, data for update, 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 for identifying the ECU to be updated (ECU name, ECU ID, etc.), information on the software version to be updated (version name, version ID, etc.), a brief description of the function to be updated, an estimated time until the download of the distribution package is completed (download estimated time), and an estimated time until the update process in the vehicle 1 is completed (update process estimated time), etc.

[0021] 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 a memory programmed to execute one or more functions embodied by a computer program. The control device 23 has the data management function, campaign management function, distribution function, etc. described above. In this embodiment, as an example of the functions of the control device 23, the function of calculating the update process estimated time and the function of calculating the importance of the update will be described.

[0022] The control device 23 calculates the update process estimated time based on the data size of the update data. As will be described later, during the update process in the ECU to be updated (including the period from when the ECU to be updated stops operating with the old program until it normally starts with the new program), the ECU to be updated cannot execute the software function. Therefore, the update process estimated time is also referred to as the downtime as the time when the functions of the vehicle 1 cannot be used.

[0023] For example, when a map showing the relationship between the data size of the update data and the estimated update processing time is stored in the database 22 in advance, the control device 23 refers to the map and calculates the estimated update processing time according to the data size. Also, for example, the control device 23 calculates a longer estimated update processing time as the data size of the update data is larger. 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 differential data. Also, the method of calculating the estimated update processing time is an example, and the control device 23 may calculate the estimated update processing time using other calculation methods.

[0024] Further, the control device 23 calculates the importance of the update based on the type of the ECU to be updated. The importance of the update is the importance based on at least one of the driving of the vehicle 1 and the security of the vehicle 1. The importance based on the driving index of the vehicle 1 includes ASIL (Automotive Safety Integrity Level). ASIL is an index that specifies the safety requirements and safety measures of automobiles, which is defined in IEC61508 / ISO2626 standardized for the functional safety of the vehicle 1. Four levels of safety levels are defined for ASIL, and in descending order of the safety standard, they are defined as ASIL-D, ASIL-C, ASIL-B, and ASIL-A. Some or all of the ECUs installed in the vehicle 1 are pre-assigned ASIL ranks. Also, the importance based on the security index of the vehicle 1 includes the urgency (priority) of the security patch. A security patch is a file for fixing vulnerabilities or security holes that may cause some security problems. The importance of the update calculated by the control device 23 includes the above-mentioned ASIL rank and the urgency of the security patch. Note that when one or all of the ECUs installed in the vehicle 1 are assigned a standardized security rank similar to ASIL, the control device 23 may use the standardized security rank as the importance of the update.

[0025] For example, when the control device 23 receives information indicating the urgency of an update from the provider of the update data together with the update data, it calculates a higher importance of the update compared to when it does not receive the information indicating the urgency of the update. 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 a higher importance of the update compared to 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, the running system ECU 14B shown in FIG. 1 can be cited. Also, as an example of an ECU not involved in the running of the vehicle 1, the body system ECU 14A and the multimedia system ECU 14C shown in FIG. 1 can be cited. 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 a higher importance of the update compared to when the ASIL rank assigned to the ECU to be updated is lower than the predetermined reference rank. Note that the method for calculating the importance of the update is an example, and the control device 23 may calculate the importance of the update using other calculation methods.

[0026] The configuration of the user terminal 3 will 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.

[0027] 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 receives a user's operation input and a device that notifies the user of information. As the terminal HMI 32, for example, a touch panel display can be cited. Note that the terminal HMI 32 is not limited to a device that displays information, and may be a device that outputs information as sound, such as a speaker. When the user terminal 3 is directly connected to the in-vehicle device of the vehicle 1 through 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. Also, 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.

[0028] The terminal control device 33 functions as the command center of 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. In the software update process of the ECU of the vehicle 1, the terminal control device 33 executes a process for notifying the user of the campaign information and the progress information of the update process. Taking the campaign information as an example, when the terminal control device 33 receives the campaign information from the server 2 via the terminal communication device 31, it outputs the campaign information to the terminal HMI 32 to display the campaign information on the terminal HMI 32. Also, in the software update process of the ECU of the vehicle 1, the terminal control device 33 executes a process for seeking the user's approval. Taking the case of seeking the user's approval to start the update process as an example, the terminal control device 33 generates a commitment request image for seeking the user's approval to start the update process, outputs the commitment request image to the terminal HMI 32, and displays the commitment request image on the terminal HMI 32.

[0029] When the user outside the vehicle 1 is within the range of the wireless communication network 4 of the user terminal 3, the user can perform an operation input while confirming various information related to the software update by the user terminal 3 and perform the procedures related to the software update. Note that the block configuration and functions of the user terminal 3 described above are merely examples and do not limit the user terminal 3. Also, in the software update device, software update system, and software update method according to the present invention, the user terminal 3 is not necessarily required. That is, the present invention can also be applied to a software update system that does not include the user terminal 3. It is assumed that the known block configurations and functions at the time of filing this application can be applied to the block configuration and functions of the user terminal 3. Also, in this embodiment, the case where the user, who is a passenger, uses the in-vehicle terminal 12 to perform the procedures related to the update process will be described as an example, but the software update device, software update system, and software update method according to the present invention can also be applied when the user uses the user terminal to perform the procedures related to the update process.

[0030] 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 running 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 CAN (Controller Area Network) or LIN (Local Interconnect Network).

[0031] The in-vehicle communication device 11 has a function of performing data communication with the server 2 via the wireless communication network 4. Examples of the in-vehicle communication device 11 include a telematics control unit (TCU: Telematics Control Unit).

[0032] The in-vehicle terminal 12 is a terminal that has functions of receiving operation inputs from a user (passenger) riding in vehicle 1 and displaying various screens. Examples of the in-vehicle terminal 12 include a touch panel display. A signal for notifying the passenger of various information is input to the in-vehicle terminal 12 from the software update device 10. For example, when information for requesting the passenger's approval to start the update process is input from the software update device 10 to the in-vehicle terminal 12, the in-vehicle terminal 12 displays an image for requesting the passenger's approval. Further, for example, when the passenger performs an operation on the in-vehicle terminal 12 to approve the start of the update process, the in-vehicle terminal 12 outputs approval information indicating that the passenger has approved it to the software update device 10. When the vehicle 1 is located within the range of the wireless communication network 4, the user inside the vehicle 1 can perform an operation input while confirming various information related to software update by the in-vehicle terminal 12 and perform procedures related to software update. Note that the in-vehicle terminal 12 is not limited to a device that displays information, and may be a device that outputs information as sound, such as a speaker.

[0033] 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. When, for example, an occupant performs an operation to turn the ignition from on to off, the ignition switch 13 outputs a signal representing the content of the user's operation to the software update device 10.

[0034] The body system ECU 14A, the running system ECU 14B, and the multimedia system ECU 14C are examples of ECUs to be updated by the software update device 10. Each ECU includes, 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, and a power supply circuit, a data transfer circuit, etc. A program for realizing the software of the ECU is stored in the flash memory. The software of the ECU is realized by the microcomputer executing the program stored in the flash memory to perform various processes.

[0035] The flash memory of the ECU is classified into a single bank memory and a double bank memory according to the memory configuration. In the single bank memory, there is no distinction between the program storage area and the program execution area by the microcomputer, and the program cannot be rewritten to the single bank memory while the microcomputer is executing the program. On the other hand, the double bank memory has two-sided areas as the program storage area, and the microcomputer executes the program in one of the two-sided storage areas. Therefore, in the double bank memory, even while the microcomputer is executing the program, the program can be written to the other storage area that does not store the executing program. Regarding the two-sided program storage areas of the double bank memory, hereinafter, for convenience, they are referred to as the first memory and the second memory.

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

[0037] A control signal for update processing is input from the software update device 10 to the body system ECU 14A, the running system ECU 14B, and the multimedia system ECU 14C, and software update processing is executed in each ECU. In FIG. 1, each ECU is shown one by one, but 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. Also, the body system ECU 14A, the running system ECU 14B, and the multimedia system ECU 14C shown in FIG. 1 are an example of the ECUs mounted on vehicle 1, and do not limit the types of ECUs mounted on vehicle 1 or the way of distinguishing the ECUs. Also, vehicle 1 may be equipped with ECUs other than the ECUs shown in FIG. 1.

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

[0039] Here, the relationship between the outline of the software update flow by OTA and the memory configuration of the ECU will be described with reference to FIGS. 2 to 4. FIG. 2 is an explanatory diagram for explaining the software update flow by OTA. As shown in FIG. 2, the software update by OTA is performed through a plurality of stages. Specifically, in the software update by OTA, notification of campaign information (step S1), download (step S2), installation (step S3), activation (step S4), and update completion confirmation (step S5) are sequentially performed.

[0040] 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 delivery package including update data is transmitted from the server 2 to the vehicle 1, and the delivery package is stored in the vehicle 1. In step S3, a process of writing a new program is performed on the ECU to be updated. In step S4, the new program is activated by a process of reading the new program by the microcomputer. In step S5, the completion of the software update is notified via the in-vehicle terminal 12 and / or the user terminal 3.

[0041] FIG. 3 is an explanatory diagram for explaining software update by OTA according to the memory configuration of the ECU. FIG. 3 shows each step of download, installation, activation, and update completion confirmation among the plurality of steps shown in FIG. 2 as an "update state". Further, FIG. 3 shows the state of the vehicle 1 in each update state as a "vehicle state", shows the operation of the update target ECU as a "target ECU", and shows 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.

[0042] As shown in FIG. 3(A), when the memory configuration of the update target ECU is a single bank, "download" of the distribution package is performed in the vehicle 1 in a state where the vehicle 1 can run (the ignition switch 13 is on). After the download is completed, when the ignition switch 13 is switched from on to off in a state where the vehicle 1 has stopped, a "commitment request" for requesting the user to commit to start the update process is performed in the vehicle 1. In the present embodiment, the user in the vehicle 1 performs an operation input while confirming various information related to the software update by the in-vehicle terminal 12, and performs procedures related to the software update.

[0043] Figure 4 is an example of a screen displayed on in-vehicle terminal 12 when requesting the driver of vehicle 1 to approve the start of the update process. After the download from server 2 is completed, when the driver of vehicle 1 switches the ignition switch 13 from on to off, for example, as shown in Figure 4, on the display of vehicle 1 (in-vehicle terminal 12), as screen D, information C1 requesting the driver to approve the start of the update process (display of "Do you want to update the software?") and, as two operable icons for the driver, an approval icon A1 (display of "Now") and a rejection icon A2 (display of "Later") are displayed. When the driver approves the start of the update process and presses icon A1, in vehicle 1, the software update process of the ECU is started. On the other hand, when the driver does not approve the start of the update process and presses icon A2, in vehicle 1, the process of turning off the ignition of vehicle 1 is executed by power supply system ECU 14D without starting the software update process of the ECU. Also, on in-vehicle terminal 12, an update process delay notice indicating the delay of the update process is displayed (for example, display of "Postpone to next time").

[0044] Returning to Figure 3, when the driver approves the start of the update process, in vehicle 1, "Installation" using the update data is performed. Specifically, in the flash memory of the ECU, after deleting the old program, a rewriting process of writing the new program is performed. When the rewriting process is completed, "Activation" is performed to cause the microcomputer of the ECU to load the new program. After that, through the power restart process (reboot process) of vehicle 1, the software update is completed. When the software update is completed, an update completion notice indicating that the update is completed is displayed on in-vehicle terminal 12 (for example, display of "Software update is completed"). Also, after the completion of the update process, the process of turning off the ignition of vehicle 1 is executed by power supply system ECU 14D.

[0045] Also, as shown in FIG. 3(B), when the memory configuration of the ECU is double-bank, while the vehicle 1 is in a drivable state, in addition to "downloading" the distribution package, "installation" using update data is performed in the vehicle 1. When the microcomputer of the ECU is executing the program (old program) stored in the first memory, in the second memory, a writing process for writing the new program is performed. After the installation is completed, when the ignition switch 13 is switched from on to off while the vehicle 1 is stopped, in the vehicle 1, a "commitment request" is made to the occupant to request commitment to start the update process (see FIG. 4). When the occupant commits to starting the update process, an "activate" operation is performed to change the memory from which the microcomputer reads from the first memory to the second memory. After that, through the power restart process of the vehicle 1, the software update is completed.

[0046] As described above, depending on the configuration of the flash memory of the ECU, the specific content of the software update process includes differences between "installation" and "activation" and "activation". However, in any update process, the occupant is requested to commit to starting the update process, and when the occupant performs an operation to commit to starting the update process, the update process is executed in the vehicle 1. However, in the example of FIG. 4, when the occupant does not perform any operation in the state where the screen D1 is displayed on the in-vehicle terminal 12, there is a problem that the intention (commitment or rejection) of the occupant regarding starting the update process cannot be confirmed and it cannot be determined whether to start the update process. Therefore, the software update device 10 according to the present embodiment aims to solve the above problems by the following configuration and method.

[0047] 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 is 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 has a memory for storing a program and a CPU for executing the program stored in this memory. As the operation circuit, an MPU, DSP, ASIC, FPGA, etc. can be used instead of or together with the CPU.

[0048] 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 process execution unit 45, and a power supply process execution unit 50. The controller 40 realizes each function of the functional blocks by software stored in a memory.

[0049] The information acquisition unit 41 acquires update process information regarding software update from the server 2 via the in-vehicle communication device 11. The update process information includes the campaign information and the distribution package described above. The information acquisition unit 41 also acquires a signal indicating the on state 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 the icon A1 which is an approval display, the information acquisition unit 41 acquires a signal from the in-vehicle terminal 12 indicating that the approval display has been pressed by the occupant. On the other hand, in the example of FIG. 4, when the occupant presses the icon A2 which is a rejection display, the information acquisition unit 41 acquires a signal from the in-vehicle terminal 12 indicating that the rejection display has been pressed by the occupant.

[0050] The storage unit 42 functions as a storage device that stores the information acquired by the information acquisition unit 41 and obtained from the server 2. As the storage unit 42, for example, a non-volatile recording medium such as a flash memory is used. The storage unit 42 stores the campaign information and the distribution package acquired from the server 2. The storage unit 42 may also store information regarding the ECU mounted on the vehicle 1 (such as the memory configuration of the ECU). The various information stored in the storage unit 42 is used in the processing by the update process execution unit 45.

[0051] The output unit 43 outputs commitment request information for asking the occupant of the vehicle 1 whether to approve the start of the update process by the update process execution unit 45. Examples of the commitment request information include an image, voice, etc., but the method for asking the occupant for approval 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. Thereby, a screen D as in the example of FIG. 4 is displayed on the in-vehicle terminal 12. Also, for example, the output unit 43 may output a voice signal for asking the occupant whether to approve the start of the update process to the in-vehicle terminal 12 together with or instead of the image signal. Thereby, it is possible to ask the occupant for approval of the start of the update process by voice.

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

[0053] The start determination unit 44 determines whether to start the update process by the update process execution unit 45. When the occupant approves the start of the update process for the approval request information output by the output unit 43, the start determination unit 44 determines to start the update process. When the occupant rejects the start of the update process for the approval 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 approval display (icon A1) or the rejection display (icon A2) for the screen D displayed on the in-vehicle terminal 12, the information acquisition unit 41 acquires, from the in-vehicle terminal 12, an operation signal indicating that the approval display or the rejection display has been pressed by the occupant. The start determination unit 44 regards the operation signal acquired by the information acquisition unit 41 as response information that is the occupant's response to the approval request information. The start determination unit 44 determines whether to start the update process according to the response information. For example, when the response information indicates that the approval display has been operated by the occupant, the start determination unit 44 determines to start the update process. When the response information indicates that the rejection display has been operated by the occupant, the start determination unit 44 determines not to start the update process.

[0054] Also, in this embodiment, when no response information is input for a predetermined time or more after the approval request information is output, the start determination unit 44 determines whether to start the update process based on the required time for the update process. That is, even though the occupant is asked to approve the start of the update process, if the occupant does not respond at all, the start determination unit 44 determines whether to start the update process based on the required time for the update process. The predetermined time is a preset time. The required time for the update process is an estimated time until the update process on the vehicle 1 is completed, calculated by the server 2.

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

[0056] The update process execution unit 45 executes an update process according to the response information, which is the occupant's response to the approval request information. When it is determined by the start determination unit 44 that the update process is to be started, the update process execution unit 45 executes the update process. When it is determined by the start determination unit 44 that the update process is not to be started, the execution of the update process is postponed. Note that when it is determined by the start determination unit 44 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.

[0057] As a functional block that executes the update process, the update process execution unit 45 includes an installation execution unit and an activation execution unit according to the memory configuration of the ECU to be updated. 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 "installation" and "activation" differ depending on whether the memory configuration of the ECU is a single bank or a double bank. For this reason, in the present embodiment, a plurality of installation execution units and a plurality of activation execution units are provided. When the memory configuration of the ECU to be updated is a 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 a 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 discriminates the memory configuration of the ECU to be updated from the information on the ECU mounted on the vehicle 1 stored in the storage unit 42.

[0058] The first installation execution unit 46 executes an installation process of writing a new program after deleting the old program stored in the flash memory. The first activation execution unit 47 executes an activation process of causing the microcomputer included in the ECU to be updated to read the new program written in the flash memory.

[0059] When the old program is stored in the first memory of the first memory and the second memory of the flash memory and the microcomputer is reading the old program, the second installation execution unit 48 executes an installation process of writing the new program in the second memory in which the old program is not stored. The second activation execution unit 49 executes an activation process of switching the program reading destination by the microcomputer included in the ECU to be updated from the first memory to the second memory.

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

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

[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 for the authentication process of the update data, and an estimated update processing time.

[0063] In step S12, the controller 40 determines whether the ignition switch 13 has been switched from on to off by the operation of the occupant. The controller 40 acquires a signal indicating the operation by the occupant from the ignition switch 13. When the ignition switch 13 is switched from on to off by the occupant, the process proceeds to step S13. When the ignition switch 13 remains on, the controller 40 waits in step S12 until the ignition switch 13 is switched from on to off by the occupant.

[0064] In step S13, the controller 40 outputs commitment request information for requesting the occupant of the vehicle 1 to commit to starting the software update process. For example, as in the example of FIG. 4, the controller 40 causes the commitment request information for requesting the occupant to commit to be displayed on the screen of the in-vehicle terminal 12.

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

[0066] In step S14, if it is determined 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 information of consent for starting the update process. For example, in the example of FIG. 4, when the occupant presses the icon A1 (display of "immediately"), the response information obtained in step S14 includes information indicating that the occupant has consented. Therefore, the controller 40 determines that the occupant has consented to start the update process. Also, for example, in the example of FIG. 4, when the occupant presses the icon A2 (display of "later"), the response information obtained in step S14 includes information indicating that the occupant has refused. Therefore, the controller 40 determines that the occupant has not consented to start the update process. If it is determined that the occupant has consented, the process proceeds to step S16. If it is determined that the occupant has not consented, the process proceeds to step S17.

[0067] 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. For the specific content of each process, the above-mentioned description is incorporated by reference.

[0068] If it is determined in step S15 that the occupant has not consented, or if the process in step S16 is completed, the process proceeds to step S17. In step S17, the controller 40 executes a process of turning 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 for turning off the ignition of the vehicle 1 to the power system ECU 14D. When the process of step S15 is completed, the process in the flowchart shown in FIG. 6 is completed.

[0069] 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.

[0070] 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 or not the required time for the update process acquired in step S11 is less than a first threshold value. Specifically, the controller 40 determines whether or not the required times for the installation process and the activation process are less than the first threshold value. If it is determined that the required time for the update process is less than the first threshold value, the process proceeds to step S20. If it is determined that the required time for the update process is equal to or greater than the first threshold value, the process proceeds to step S21.

[0071] If it is determined in step S19 that the required time for the update process is less than the threshold value, the process proceeds to step S20. In step S20, the controller 40 determines to start the update process. Thereafter, the process proceeds to step S16, and the controller 40 executes the update process described above. On the other hand, if it is determined in step S19 that the required time for the update process is equal to or greater than the threshold value, the process proceeds to step S21. In step S21, the controller 40 determines not to start the update process. Thereafter, the process proceeds to step S17, and 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.

[0072] Regarding the flowchart in the case where the memory configuration of the ECU to be updated is double-bank, only the steps different from the processing in the single-bank will be described with reference to FIG. 6. When the memory configuration is double-bank, after the processing in step S11 is completed, the controller 40 executes the 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 the installation process as shown in the example of FIG. 3(B). For the specific content of the processing, the above-described explanation is incorporated.

[0073] Also in step S16, the controller 40 executes the activation process as the 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 reading destination of the ECU's microcomputer from the memory storing the old program to the memory storing the new program as the activation process.

[0074] Also in step S19, the controller 40 determines whether the required time for the update process acquired in step S11 is less than the first threshold value. Specifically, when the memory configuration of the ECU is double-bank, the controller 40 determines whether the required time for the activation process is less than the first threshold value.

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

[0076] Also, in this embodiment, when it is determined by the start determination unit 44 that the update process is to be started, the update process execution unit 45 executes the update process, and when it is determined by the start determination unit 44 that the update process is not to be determined, the update process is postponed without being executed. Thereby, the occupant is asked whether to approve the start of the software update process, and even when there is no response from the occupant, it is possible to automatically execute the update process or automatically postpone the update process.

[0077] Also, in this embodiment, when the required time for the update process is less than the first threshold value, the start determination unit 44 determines to start the update process, and when the required time for the update process is equal to or more than the first threshold value, the start determination unit 44 determines not to start the update process. Since it is possible to determine whether to start the update process according to the required time for the update process, for example, when the required time for the update process is relatively long, that is, 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, that is, 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.

[0078] Also, in the present embodiment, the ECU to be updated has a flash memory that stores an old program, and the update processing execution unit 45 includes a first installation execution unit 46 that executes an installation process of writing a new program into the flash memory after deleting the old program from the flash memory, and a first activation execution unit 47 that executes an activation process of causing the microcomputer to read the new program written into the flash memory. The update process executed by the update processing execution unit 45 is an installation process and an activation process. Thereby, even when the memory configuration of the ECU to be updated is a single bank, it is possible to determine whether to start the update process.

[0079] Also, in the present embodiment, the ECU to be updated has a flash memory configured by a double bank of a first memory that stores an old program and a second memory, and the update processing execution unit 45 includes a second installation execution unit 48 that writes a new program into the second memory, and a second activation execution unit 49 that executes an activation process of switching the program reading destination of the microcomputer from the first memory to the second memory. The update process executed by the update processing execution unit 45 is an installation process and an activation process. Thereby, even when the memory configuration of the ECU to be updated is a double bank, it is possible to determine whether to start the update process.

[0080] Also, in the present embodiment, the information acquisition unit 41 acquires a signal indicating the on state or off state of the ignition switch 13 from the ignition switch 13 of the vehicle 1, and the output unit 43 outputs approval request information when the ignition switch 13 is operated from on to off by the occupant. The approval request information can be presented to the occupant by triggering an operation indicating that the occupant does not use the vehicle 1.

[0081] Also, in the present embodiment, the information acquisition unit 41 acquires the required time for the update process from the server 2. Thereby, without calculating the required time for the update process in the software update device 10, it is possible to determine whether to start the update process, so that the calculation load on the software update device 10 can be reduced.

[0082] In addition, in this embodiment, the software update device 10 has been described by taking as an example the configuration in which the software update device 10 acquires the required time for the update process from the server 2. However, the entity that calculates the required time for the update process is not limited to the server 2, and the software update device 10 may calculate the required time for the update process.

[0083] As a modification of this embodiment, the controller 40 may have, as a functional block, a calculation unit that calculates the required time for the update process based on the data size of the update data. For example, when a map showing the relationship between the data size of the update data and the estimated update time is stored in the storage unit 42 in advance, the calculation unit may refer to the map and calculate the estimated update time according to the data size. Also, for example, the calculation unit may calculate the estimated update time to be longer as the data size of the update data is larger. By calculating the estimated update time by the software update device 10 as in the modification example, the calculation load on the server 2 can be reduced. Note that the timing at which the controller 40 calculates the estimated update time is not particularly limited as long as it is before the comparison between the estimated update time and the first threshold value. For example, in the flowchart of FIG. 6, the controller 40 calculates the required time for the update process based on the data size of the update data between step S11 and step S12.

[0084] <<Second Embodiment>> Next, the software update device according to the second embodiment will be described. The software update device according to the second embodiment has the same configuration as that of the software update device 10 according to the first embodiment described above, except that some functions of the start determination unit 44 are different. Therefore, for the same configuration as that of the first embodiment, the above description will be incorporated by reference.

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

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

[0087] Next, an example of the 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 40 of the software update device according to this embodiment. Note that the flowchart of FIG. 7 is the same as the flowchart of FIG. 6 except that the step corresponding to step S19 in FIG. 6 is different. Therefore, for the same steps as in the flowchart of FIG. 6, the above-described explanations are incorporated by reference.

[0088] 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 acquired 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. If it is determined that the importance of the update is less than the second threshold, the process proceeds to step S21.

[0089] As described above, in this embodiment, after the output unit 43 outputs the approval request information, when no response information from the occupant is input for a predetermined time or longer, the start determination unit 44 determines whether to start the update process based on the importance of the update of the ECU software. Thereby, the occupant, who is the user of the vehicle 1, is asked whether to approve the start of the software update process, and even when there is no response from the user, it is possible to determine whether the update process should be started.

[0090] Also, in this embodiment, when the importance of the update is equal to or higher than the second threshold value, the start determination unit 44 determines to start the update process, and when the importance of the update is lower than the second threshold value, the start determination unit 44 determines not to start the update process. Since it is possible to determine whether to start the update process according to the importance of the update, the occupant is asked whether to approve the start of the update process with high importance or urgency, and even when there is no response from the occupant, it is possible to automatically execute the update process with high importance or urgency.

[0091] In addition, in this embodiment, the configuration in which the software update device 10 obtains the importance of the update from the server 2 has been described as an example. However, the entity that calculates the importance of the update is not limited to the server 2, and the software update device 10 may calculate the importance of the update.

[0092] As a modification 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 vehicle 1, the importance calculation unit calculates a higher importance of the update than when the ECU to be updated is an ECU not involved in the running of vehicle 1. Also, for example, when the ASIL rank assigned to the ECU to be updated is higher than a predetermined reference rank, the importance calculation unit calculates a higher importance of the update than when the ASIL rank assigned to the ECU to be updated is lower than the predetermined reference rank. By calculating the importance of the software update by the software update device 10, the computing load on the server 2 can be reduced. Note that the timing at which 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 step S11 and step S12. Also, for the flowchart in the case where the memory configuration of the ECU to be updated is a dual bank, the description in the above-described first embodiment is incorporated.

[0093] ≪Third Embodiment≫ Next, a software update device according to the third embodiment will be described. The software update device according to the third embodiment has the same configuration as that of the software update devices according to the above-described two embodiments, except that some functions of the start determination unit 44 are different. Therefore, for the same configuration as that of the first embodiment and the second embodiment, the description already given is incorporated.

[0094] In this embodiment, after the output unit 43 outputs the approval request information, when the response information from the occupant is not input for a predetermined time or more, 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 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, first, the start determination unit 44 uses the determination method according to the importance of the update. When the importance of the update is equal to or greater than the second threshold, the start determination unit 44 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. When the time required for the update process is less than the first threshold, the start determination unit 44 determines to start the update process. When the time required for the update process is greater than the first threshold, the start determination unit 44 determines not to start the update process. The importance of the update is the importance of the update according to the second embodiment, and the time required for the update process is the time required for the update process according to the first embodiment.

[0095] Next, an example of the software update method according to this embodiment will be described with reference to the flowchart of 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 of FIG. 8 is the same as the flowchart of FIG. 7 except that step S23 is added. Therefore, for the same steps as those in the flowchart of FIG. 7, the above-described explanations are incorporated.

[0096] 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 acquired 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. If it is determined that the importance of the update is less than the second threshold, the process proceeds to step S23.

[0097] 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 required time for the update process acquired in step S11 is less than the first threshold. Specifically, the controller 40 determines whether the required time for the installation process and the activation process is less than the first threshold. If it is determined that the required time for the update process is less than the first threshold, the process proceeds to step S20. If it is determined that the required time 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.

[0098] As described above, in this embodiment, when the start determination unit 44 determines that the importance of the update is equal to or greater than the second threshold, it determines to start the update process regardless of whether the required time for the update process is less than the first threshold. Thereby, in the case of an update with relatively high importance, it is possible to determine to start the update process without depending on the time required for the update process. Therefore, it is possible to request the occupant to approve or decline to start an update process with high importance or urgency, and even if there is no response from the occupant, it is possible to automatically execute an update process with high importance or urgency.

[0099] Similar to the above-described first and second embodiments, in this embodiment as well, the entity that calculates the required time 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 required time for the update process. For the specific configuration, the above description is incorporated by reference. Also, for the flowchart in the case where the memory configuration of the ECU to be updated is a dual bank, the description in the above-described first embodiment is incorporated by reference.

[0100] Note that the embodiments described above 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 changes and equivalents belonging to the technical scope of the present invention.

[0101] For example, in the above-described third embodiment, a configuration using a start determination method according to the required time for the update process and a start determination method according to the importance of the update has been described as an example. However, the method that can obtain the same effect as the start determination method in the third embodiment is not limited to using two start determination methods. For example, in the above-described first embodiment, the start determination unit 44 may set a first threshold value that is a comparison target with the required time 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 a 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. Further, the start determination unit 44 may set the first threshold value higher as the importance of the update is higher. The higher the first threshold value is set, the easier it is to be determined that the update process is to be started in the comparison between the required time for the update process in the start determination unit 44 and the first threshold value, and the same effect as that in the third embodiment can be obtained.

[0102] For example, in the above-described first to third embodiments, it has been described by taking as an example a configuration in which the software update device 10 requests the occupant to approve the start of the update process, and when the occupant approves, the software update device 10 executes the update process. However, in addition to the occupant's response to the approval request information, the software update device 10 may execute the update process according to the parking location of the vehicle 1. For example, the information acquisition unit 41 acquires the position information of the vehicle 1 from a detection device that detects the current location of the vehicle 1 such as GPS, and the update process execution unit 45 may execute the update process according to the response information that is the occupant's response to the approval request information and the parking location of the vehicle 1. For example, when the vehicle 1 is parked in the parking lot of a store for the occupant to visit a predetermined store, the staying time of the occupant in the store is shorter than that at the occupant's home, so the time available for the update process tends to be short. In such a case, the update process execution unit 45 does not execute the update process even if the occupant approves 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 when an affirmative determination is made in step S12. Further, for example, when the vehicle 1 is parked in the parking lot of the home for the occupant 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 approves the start of the update process. For example, in the flowchart of FIG. 8, the software update device 10 may omit the process of step S14 after the process of step S13 is completed and execute step S16. Note that, although the store and the user's home have been described as examples of the parking location of the vehicle, the parking location of the vehicle is not limited thereto.

[0103] Also, for example, in the first to third embodiments described above, the first threshold value that is a comparison target with the required time for the update process and the second threshold value that is a comparison target with the importance of the update were described as preset values. However, the first threshold value and / or the second threshold value may be values that can be set by the user. For example, the user may be configured to set the first threshold value and / or the second threshold value via the in-vehicle terminal 12. For example, when it is desired to determine that the software update device 10 starts the update process if the required time for the update process is less than 5 minutes, the user sets the first threshold value to 5 minutes.

Explanation of Signs

[0104] 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 49…Second activation execution unit 50…Power supply process execution unit 11…In-vehicle communication device 12…In-vehicle terminal 13…Ignition switch 14A…Body system ECU 14B…Running system ECU 14C…Multimedia system ECU 14D…Power supply 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

1. A software update device for updating software of an in-vehicle control device mounted on a vehicle, comprising: an information acquisition unit that acquires update process information regarding the update of the software from a server provided outside the vehicle; an output unit that outputs commitment request information for requesting whether to commit to the start of the software update process or for asking the user; an execution unit that executes the update process according to the response information which is the response of the user to the commitment request information; a start determination unit that determines whether to start the update process based on at least one of the required time for the update process and the importance of the software update when the response information is not input within a predetermined time or more after the commitment request information is output. A software update device comprising the same.

2. The software update device according to claim 1, wherein the execution unit executes the update process when it is determined by the start determination unit that the update process is to be started; and defers the execution of the update process when it is determined by the start determination unit that the update process is not to be started. A software update device.

3. The software update device according to claim 2, wherein the start determination unit determines to start the update process when the required time is less than a predetermined first threshold value; and determines not to start the update process when the required time is greater than or equal to the first threshold value. A software update device.

4. The software update device according to claim 2 or 3, wherein the start determination unit determines to start the update process when the importance is greater than or equal to a predetermined second threshold value; and determines not to start the update process when the importance is less than the second threshold value. A software update device.

5. The software update device according to claim 2, wherein the start determination unit determines to start the update process regardless of whether the required time is less than a predetermined first threshold value when the importance is greater than or equal to a predetermined second threshold value. A software update device.

6. The software update device according to claim 3, wherein the start determination unit sets the first threshold value according to the importance. A software update device.

7. The software update device according to any one of claims 1 to 6, wherein the in-vehicle control device has a first memory that stores a first program for implementing the old version of the software; the execution unit An install execution unit that executes an install process of writing a second program for realizing new version software into the first memory after deleting the first program from the first memory; An activate execution unit that executes an activate process of causing the second program written in the first memory to be read, including: The update process is a software update device that includes the install process and the activate process.

8. A software update device according to any one of Claims 1 to 6, The in-vehicle control device has a first memory for storing a first program for realizing old version software and a second memory, The execution unit includes: An install execution unit that writes a second program for realizing new version software into the second memory; An activate execution unit that executes an activate process of switching a program reading destination from the first memory to the second memory, The update process is a software update device that includes the activate process.

9. A software update device according to any one of Claims 1 to 8, The information acquisition unit acquires a signal indicating an on state or an off state of the start switch from the start switch of the vehicle, The output unit outputs the consent request information when the start switch is operated from on to off by the user. A software update device.

10. A software update device according to any one of Claims 1 to 9, The information acquisition unit acquires vehicle position information from a detection device that detects the current location of the vehicle, The execution unit executes the update process according to the response information and the vehicle stop location. A software update device.

11. A software update device according to any one of Claims 1 to 10, The information acquisition unit acquires at least one of the required time and the importance from the server. A software update device.

12. A software update device according to any one of Claims 1 to 11, A software update device including a calculation unit that calculates the required time based on the size of data used for updating the software.

13. A software update device according to any one of Claims 1 to 12, A software update device including an importance calculation unit that calculates the importance based on the type of the in-vehicle control device.

14. The software update device according to claim 13, wherein when the in-vehicle control device is a control device involved in the running of the vehicle, the importance calculation unit calculates a higher importance than when the in-vehicle control device is a control device not involved in the running of the vehicle.

15. The software update device according to any one of claims 1 to 14, wherein the importance is an importance based on at least one of an index of the running of the vehicle and the security of the vehicle.

16. A software update system including the software update device according to any one of claims 1 to 15 and the server.

17. A software update method in which a controller updates software of an in-vehicle control device mounted on a vehicle, acquiring update processing information regarding the update of the software from a server provided outside the vehicle, outputting commitment request information for asking the user whether to approve the start of the software update process, executing the update process according to response information which is the response of the user to the commitment request information, and determining whether to start the update process based on at least one of the required time for the update process and the importance of the software update when the response information is not input for a predetermined time or more after the commitment request information is output.

Images