Software updating device, host, OTA host, network system, method, storage medium, center and vehicle

Abstract

The present disclosure relates to a host configured to control a software update of a target electronic control unit that is a software update target among a plurality of electronic control units mounted in a vehicle, the host receiving an update notification including size information of update data from a center, and transmitting the update notification to the target electronic control unit. The storage unit acquires the spare capacity of the storage unit of a specific electronic control unit from among the plurality of electronic control units, makes a download request for update data disposed so that the storage area of the storage unit is not insufficient to the center on the basis of the size information of the update data and the spare capacity, receives the update data from the center, and stores the update data in the storage unit. And starting software of the target electronic control unit at the target electronic control unit when the power supply of the vehicle is disconnected by using the received update data.

Description

Division Application Description This application is a divisional application of a Chinese patent application with an application date of June 16, 2021, an invention title of "Software Update Device, Host, OTA Host, Network System, Method, Storage Medium, Center and Vehicle", and an application number of 202110668480.9. Technical Field

[0001] The present disclosure relates to a software update device, a host, an OTA host, a network system, a method, a storage medium, a center and a vehicle. Background Art

[0002] A vehicle is equipped with a network system, which is composed of a plurality of in-vehicle devices called ECUs (Electronic Control Units) connected to each other via communication lines. Each in-vehicle device sends and receives messages to and from each other and shares the execution of various functions of the vehicle.

[0003] Typically, as an in-vehicle device, it includes a processor, a volatile storage unit such as a RAM, and a non-volatile storage unit such as a flash ROM. The program (software) executed by the processor is stored in the non-volatile storage unit. By rewriting and updating the program to a newer version, the improvement of the functions of the in-vehicle device can be achieved.

[0004] The update of the program has steps of downloading update data received from an external device (center) through wireless communication, etc., and writing and installing an update program (update software) into the storage unit of the in-vehicle device based on the downloaded update data. At the time of installation, depending on the specifications of the in-vehicle device, there are overwrite installation and other repository installations. The so-called overwrite installation is to write the downloaded update program into an area (single-sided: single bank) in the storage area of the storage unit that is determined to be used for program storage in a manner that overwrites the current program (old program). The so-called other repository installation is to write the downloaded update program into an area (the other side (other-bank)) other than the area (one side) in which the current program (old program) is stored in two areas (double-sided: dual bank) determined to be used for program storage.

[0005] In the case of other repository installation, in the steps of program update, in addition to the steps of downloading and installation, there is also a startup step, in which set values such as the starting address of the update program are set so that the installed update program can be executed.

[0006] Regarding the program update of the ECU, Japanese Patent Application Laid-Open No. 2011-148398 discloses the following: A specific ECU functions as a main ECU, communicates with a server, and updates the programs of the main ECU itself and other slave ECUs. Summary of the Invention

[0007] The above downloading and installation are controlled by a software update device included in a network system. The software update device, for example, centrally downloads the update programs of respective in-vehicle devices from an external device, temporarily stores them in a storage unit included in the software update device, and then sends the update programs to the respective in-vehicle devices to cause the respective in-vehicle devices to perform installation and / or further start-up. Considering that the storage unit is shared with other in-vehicle devices and is used to store various data. Since the area that can continue to be stored, such as the free capacity of the storage unit, varies according to the amount of various data stored, when the area that can be stored is small, it may not be possible to centrally download and store the update programs.

[0008] The present disclosure provides a software update device or the like that can appropriately update a program according to the storage size that can be achieved by the software update device or the like.

[0009] The host according to the aspect of the present invention includes: a communication unit configured to request the download of update data from a center; a first storage unit configured to store the downloaded update data; and a control unit configured to, when performing the download, confirm at least one of the free capacity of the first storage unit and the free capacity of a second storage unit of one or more in-vehicle devices to be updated among a plurality of in-vehicle devices connected via an in-vehicle network, and perform control based on the update data to install, or install and start, update software on the one or more in-vehicle devices to be updated, wherein the communication unit is configured to request the download of the update data from the center based on the free capacity.

[0010] According to the technology of the present disclosure, since the software update device or the like can receive update data generated in such a way that the storage area of the software update device or the like will not be insufficient from the center, the program update of the in-vehicle device can be appropriately performed. Brief Description of the Drawings

[0011] The features, advantages, and technical and industrial significance of the exemplary embodiments of the present invention are described with reference to the accompanying drawings, in which the same reference numerals denote the same components, wherein: Figure 1 is a configuration diagram of a network system according to an embodiment. Figure 2 is a sequence diagram showing the processing according to an embodiment. Detailed Description of the Embodiment

[0012] (Embodiment) <Configuration> Figure 1 FIG. 4 shows a configuration example of the network system 1 according to this embodiment. The network system 1 is mounted on a vehicle. The network system 1 includes a software update device 50. The software update device (OTA (Over-the-Air) host) 50 is connected to a plurality of buses 10, 20, 30,.... A plurality of in-vehicle devices (electronic control units) 11, 12,... are connected to the bus 10. A plurality of in-vehicle devices 21, 22,... are connected to the bus 20. A plurality of actuators 31, 32,... are connected to the bus 30. In Figure 1 and the following description, as buses, buses 10, 20, 30 are exemplified, and as in-vehicle devices, in-vehicle devices 11, 12, 21, 22 and actuators 31, 32 are exemplified, but the number is not limited to these.

[0013] The software update device 50 includes: a communication unit (communication module) 51 capable of communicating with an external device (center) 100 provided outside the vehicle; a first storage unit (storage device, storage) 52 for storing various data; a confirmation unit 53 for controlling and managing access to the first storage unit 52 and capable of confirming the free capacity of the first storage unit 52; and a control unit 54.

[0014] Each of the in-vehicle devices 11, 12, 21, 22 communicates with each other via a network and performs various processes for controlling the vehicle. Although not shown, these in-vehicle devices include: a non-volatile second storage unit (storage device, storage) such as a flash ROM; a control unit (one or more processors) that performs various processes by reading and executing a program (software) from the second storage unit; and a volatile storage unit such as a RAM for storing a part of the program and data. In addition, the software update device 50 can similarly execute the functions of the confirmation unit 53 and the control unit 54 by storing the program for the software update device 50 in the first storage unit 52 and the control unit (one or more processors) reading and executing the program. That is, each of the in-vehicle devices 11, 12, 21, 22 and the software update device 50 can be installed as a computer including a processor. In addition, the first storage unit 52 can be read and written to and from the in-vehicle devices 11, 12, 21, 22 and can also be used as a shared storage device.

[0015] In addition, the control unit of the software update device 50 controls and relays the communication between the external device 100 and each of the in-vehicle devices 11, 12, 21, 22, the communication between each of the in-vehicle devices 11, 12, 21, 22, and the communication between each of the in-vehicle devices 11, 12, 21, 22 and each of the actuators 31, 32 via the respective buses 10, 20, 30. Thus, the software update device 50 also functions as a relay device for relaying communication.

[0016] The actuators 31 and 32 are devices that exert a mechanical action on the vehicle and its parts, such as brakes, engines, or power steering devices, and operate based on instructions from in-vehicle devices 11, 12, 21, and 22.

[0017] The control unit 54 of the software update device 50 can update the programs stored in the respective second storage units of the in-vehicle devices 11, 12, 21, and 22. That is, the software update device 50 performs download control, installation control, or further start control. Downloading is a process of receiving and storing update data (distribution package) for updating any of the in-vehicle devices 11, 12, 21, and 22, which is sent from an external device 100. Download control includes not only control of downloading execution but also control of a series of processes related to downloading, such as judgment of whether to execute downloading and verification of update data. Installation is a process of writing an updated version of the program (updated software) into the storage unit of the in-vehicle device to be updated based on the downloaded update data. Installation control includes not only control of installation execution but also control of a series of processes related to installation, such as judgment of whether to execute installation, transmission of update data, and verification of the updated version of the program. Starting is a process of validating the installed updated version of the program. Start control includes not only control of start execution but also control of a series of controls related to starting, such as judgment of whether to execute starting and verification of execution results.

[0018] In the installation control, when the update data includes the update program itself, the control unit 54 can send the update program to the in-vehicle device. In addition, when the update data includes compressed data, differential data, or split data of the update program, the control unit 54 can decompress or assemble the update data, etc., to generate an update program and send it to the in-vehicle device. Alternatively, the control unit 54 can send the update data to the in-vehicle device, and the in-vehicle device decompresses or assembles the update data, etc., to generate an update program.

[0019] The execution of the installation itself of writing the update program into the second storage unit of the in-vehicle device can be performed by the control unit 54 or by the in-vehicle device that has received an instruction from the control unit 54. Even without an explicit instruction from the control unit 54, the in-vehicle device that has received the update data (or update program) can perform it autonomously.

[0020] The execution of the start itself of validating the installed update program can be performed by the control unit 54 or by the in-vehicle device that has received an instruction from the control unit 54. Even without an explicit instruction from the control unit 54, the in-vehicle device can perform it autonomously after installation.

[0021] In addition, the update process of such a program can be performed continuously or in parallel for each of a plurality of in-vehicle devices. The update data is data for generating an update program, and its content and form are not limited. For example, it includes the update program itself, differential data for generating the update program, or compressed data or segmented data thereof. In addition, the update data may include an identifier (ECU ID) of the in-vehicle device (target electronic control unit) to be updated by the program and an identifier (WCU Soffware ID) of the version of the program before the update.

[0022] As an example, the external device 100 is a computer device such as a server provided at a designated center or the like. The external device 100 includes a communication unit (communication module) 111 that communicates with the software update device 50 and a transmission management unit (control unit) 112 that manages the communication unit 111. In addition, the external device 100 has a storage unit (not shown) and can receive and store data for updating the program for each of a plurality of in-vehicle devices from the outside.

[0023] <Processing Example 1> Hereinafter, an example of the process according to the present embodiment will be described. Figure 2 Yes Figure 2 A sequence diagram showing an example of this process is shown. First, an example of the process according to the size of the storable area of the first storage unit 52 of the software update device 50 is shown.

[0024] (Step S101) The control unit 54 of the software update device 50 controls the communication unit 51 to inquire the external device 100 about the existence of an update program. This inquiry can be made, for example, regularly or at the moment when a specified operation such as turning on the vehicle power (ignition on, power on) is performed.

[0025] (Step S102) If the communication unit 111 of the external device 100 receives the inquiry, the transmission management unit 112 controls the communication unit 111 to send an update notification to the software update device 50 when there is an update program. The transmission management unit 112 can determine whether there is an update program as an updated version of the program for these in-vehicle devices based on information indicating, for example, the types of a plurality of in-vehicle devices included in the network system 1 and the current version of the program. Such information can be stored in advance by the external device 100 or received from the software update device 50 at the same time as the inquiry. In addition, when there is no update program, the transmission management unit 112 controls the communication unit 111 to send a no-update notification to the software update device 50.

[0026] (Step S103) If the communication unit 51 of the software update device 50 receives an update notification, the control unit 54 obtains the storable size of the first storage unit 52 from the confirmation unit 53, and controls the communication unit 51 to notify the external device 100 of the storable size. Additionally, if the communication unit 51 receives a no-update notification, the process ends. The storable size refers to the size of data that the first storage unit 52 can store without affecting the processing of the software update device 50, typically the size of the available area.

[0027] (Step S104) If the communication unit 111 of the external device 100 receives the storable size, the transmission management unit 112 generates update data for updating the programs of the in-vehicle devices. That is, the update data contains data for updating the programs of one or more in-vehicle devices. For example, the transmission management unit 112 compresses the update programs of each of one or more in-vehicle devices (target electronic control units) that are the update targets of the program or the differential data (update data for each in-vehicle device) for generating the update programs by adjusting the compression ratio so that the total size is below the storable size, to create the update data. Additionally, in the case where the total size of a series of data is below the storable size of the first storage unit 52 even without compression, the external device 100 may not perform compression. Hereinafter, the data packet for updating the programs of one or more in-vehicle devices is simply referred to as update data, and the data for updating the program of an in-vehicle device included in the update data is referred to as the update data of that in-vehicle device.

[0028] (Step S105) The control unit 54 of the software update device 50 controls the communication unit 51 to send a download request to the external device 100 indicating a request to send the update data. Additionally, the download request may be included in the notification of the storable size in Step S103, or may be sent continuously with the notification of the storable size. Furthermore, the processing of the external device 100 in Step S104 may be performed after the download request.

[0029] (Step S106) The transmission management unit 112 of the external device 100 controls the communication unit 111 to send the update data to the software update device 50 as one transmission unit.

[0030] (Step S107) If the communication unit 51 of the software update device 50 receives the update data, the confirmation unit 53 stores the update data in the available area (download) of the first storage unit 52.

[0031] (Step S108) The control unit 54 of the software update device 50 reads the update data from the first storage unit 52 and generates the update data for each in-vehicle device that is the object of the program update. For example, the control unit 54 decompresses the update data read from the first storage unit 52 and divides it into the update data for each in-vehicle device. In addition, the control unit 54 controls the communication unit 51 to send the update data of one in-vehicle device to its corresponding in-vehicle device that is the update object. In this step, as an example, the in-vehicle device 11 is included in the in-vehicle devices that are the objects of the program update, and the control unit 54 sends the update data of the in-vehicle device 11 to the in-vehicle device 11.

[0032] (Step S109) If the in-vehicle device 11 receives the update data of the in-vehicle device 11, it updates the program executed by this device based on the received update data. That is, when the in-vehicle device 11 is of the single repository type, the in-vehicle device 11 performs the above-mentioned overwrite installation. In addition, when the in-vehicle device 11 is of the above-mentioned dual repository type, the in-vehicle device 11 sequentially performs the above-mentioned other repository installation and startup.

[0033] (Step S110) If there is untransmitted update data among the update data divided for each in-vehicle device, the control unit 54 of the software update device 50 controls the communication unit 51 to send the update data of this in-vehicle device to its corresponding in-vehicle device that is the update object. In this step, as an example, the in-vehicle device 12 is included in the in-vehicle devices that are the objects of the program update, and the control unit 54 sends the update data of the in-vehicle device 12 to the in-vehicle device 12.

[0034] (Step S111) If the in-vehicle device 12 receives the update data of the in-vehicle device 12, it performs the overwrite installation or other repository installation and startup of the program executed by this device in the same way as the in-vehicle device 11 in Step S109 based on the received update data.

[0035] The above example is the case where the update data received from the external device 100 includes the update data of the in-vehicle devices 11 and 12 and updates the programs of the in-vehicle devices 11 and 12. The update of the programs of other in-vehicle devices can also be carried out in the same way. In addition, the number of in-vehicle devices that are the update objects is not limited to 2, and can also be 1 or 3 or more.

[0036] In this way, the external device 100 changes the compression ratio of the update data so that it can be accommodated within the storable size of the first storage unit 52 of the software update device 50, enabling the software update device 50 to reliably store the update data in the first storage unit 52. Additionally, since the external device 100 performs data compression processing on the update data at a compression ratio such that the update data becomes smaller than the storable size according to the storable size of the first storage unit 52 of the software update device 50, it is possible to suppress an unnecessary increase in the compression ratio and to minimize the load of the data compression processing of the external device 100 as much as possible.

[0037] Furthermore, in step S104, when even increasing the compression ratio by one still does not result in the update data being smaller than the storable size, multiple update data smaller than the storable size can be generated. For example, when the in-vehicle devices to be updated are in-vehicle devices 11, 12, 21, 22 and the total amount of data for the programs to update these in-vehicle devices is large, and even at the maximum compression ratio, the update data cannot be made smaller than the storable size, the update data for in-vehicle devices 11, 12 and the update data for in-vehicle devices 21, 22 can be generated separately for each transmission unit. In this case, the processes from the transmission of the update data to the execution of the update of the programs in each in-vehicle device, as in steps S106 to S111, are repeated the number of times equal to the number of generated transmission units. Additionally, in this way, when the external device 100 generates update data in multiple transmission units, it is possible to separately set whether compression of each update data is required and the compression ratio in the case of compression, so that the size of the update data is smaller than the storable size of the first storage unit 52. Also, the control unit 54 of the software update device 50 can specify which of the compression and segmentation of the update data should be given priority in step S103.

[0038] Moreover, in step S102, when an update notification is made, the transmission management unit 112 obtains the size of the update data without compression and segmentation and sends it to the software update device 50. In this case, for example, in step S103, if the received size is smaller than the storable size, the control unit 54 of the software update device 50 issues a notification requesting the transmission of the update data without compression and segmentation, rather than notifying the external device 100 of the storable size. Additionally, in this case, in step S104, since the transmission management unit 112 of the external device 100 can determine that the storable size of the first storage unit 52 is large enough to store the update data without compression, the update data is generated without compression and segmentation. Therefore, since the external device 100 does not need to perform processes such as determining the compression ratio of the data based on the storable size and compressing it, the processing load can be suppressed.

[0039] In addition, in step S103, the control unit 54 of the software update device 50 may control the confirmation unit 53 to increase the storable size of the first storage unit 52, and notify the increased storable size to the external device 100. Therefore, the external device 100 can reduce the compression ratio and can suppress the load of the data compression process. The storable size can be increased, for example, in the following manner: in the storage area of the first storage unit 52, the in-vehicle devices of the common control unit 54 and the first storage unit 52 release the areas that are not necessary to maintain and the areas with low necessity in the areas ensured as their respective used areas. In addition, this process can be performed in the following case: the control unit 54 receives the size in the case where the update data is not compressed and segmented from the external device 100, and the received size is larger than the current storable size of the first storage unit 52.

[0040] <Example of Processing 2> Next, an example of the process according to the size of the storable area of the second storage unit of the in-vehicle device to be the object of the program update is shown. In this example, referring to Figure 2 the sequence diagram, the processes corresponding to the dispositions of the above-mentioned Processing Example 1 are referred to with the same step numbers. In addition, appropriate descriptions of the same matters as those in the above-mentioned Processing Example 1 are omitted.

[0041] (Step S101) Similar to Processing Example 1, the control unit 54 of the software update device 50 controls the communication unit 51 to inquire the external device 100 about the existence of an update program.

[0042] (Step S102) Similar to Processing Example 1, if the communication unit 111 of the external device 100 receives the inquiry, the transmission management unit 112 controls the communication unit 111 to send an update notification to the software update device 50 when there is an update program.

[0043] (Step S103) If the communication unit 51 of the software update device 50 receives the update notification, the control unit 54 acquires the storable size of the first storage unit of each in-vehicle device from each in-vehicle device, and controls the communication unit 51 to notify the storable size to the external device 100. In addition, the above update notification may include information specifying the in-vehicle device to be the update object, and the control unit 54 may acquire the storable sizes of the specified in-vehicle devices respectively. The control unit 54 can acquire the storable size by making a request related to the acquisition of the storable size to each in-vehicle device or the specified in-vehicle devices. In addition, in this example, the storable size refers to the size at which the in-vehicle device can store data of this size without affecting the processing of the in-vehicle device and can also perform the program update process, typically the size of the available area.

[0044] (Step S104) If the communication unit 111 of the external device 100 receives the storable size, the transmission management unit 112 generates update data for updating the program of the in-vehicle device. For example, the transmission management unit 112 creates the update data by adjusting the compression ratio to compress the update data of each in-vehicle device so that its size does not make the storage area of the in-vehicle device insufficient, and centralizes the compressed data. Additionally, when the storable size of the in-vehicle device is such that the storage area is sufficient even without compressing the update data of the in-vehicle device, the external device 100 may not perform compression.

[0045] (Step S105) Similar to Processing Example 1, the control unit 54 of the software update device 50 controls the communication unit 51 to send a download request to the external device 100 indicating a request to send the update data. Additionally, the download request may be included in the notification of the storable size in Step S103, or may be performed continuously with the notification of the storable size. Furthermore, the processing of the external device 100 in Step S104 may be performed after the download request.

[0046] (Step S106) Similar to Processing Example 1, the transmission management unit 112 of the external device 100 controls the communication unit 111 to send the update data to the software update device 50 as one transmission unit.

[0047] (Step S107) Similar to Processing Example 1, the confirmation unit 53 stores the update data in the available area (download) of the first storage unit 52.

[0048] (Step S108) Similar to Processing Example 1, the control unit 54 of the software update device 50 generates the update data for each in-vehicle device that is the update object of the program, and sends each update data to the in-vehicle device that is the update object. In this step, as an example, the control unit 54 sends the update data of the in-vehicle device 11 to the in-vehicle device 11.

[0032] (Step S109) If the in-vehicle device 11 receives the update data of the in-vehicle device 11, it updates the program executed by this device based on the received update data. That is, when the in-vehicle device 11 is the above single repository type, the in-vehicle device 11 performs an overwrite installation. Additionally, when the in-vehicle device 11 is the above dual repository type, the in-vehicle device 11 performs other repository installations and startups in sequence. Therefore, for example, since the in-vehicle device 11 can perform the process of receiving the compressed update data from the software update device 50, temporarily storing it in the available area, decompressing it to generate an update program, and installing it without making the storage capacity insufficient, the load on the software update device 50 can be reduced compared to the case where the update program is generated on the software update device 50 side.

[0050] (Step S110) Similar to Processing Example 1, if there is unsent update data among the update data segmented for each in-vehicle device, the control unit 54 of the software update device 50 controls the communication unit 51 to send the update data of the in-vehicle device to the in-vehicle device to be updated. In this step, as an example, the control unit 54 sends the update data of the in-vehicle device 12 to the in-vehicle device 12.

[0034] (Step S111) If the in-vehicle device 12 receives the update data of the in-vehicle device 12, based on the received update data, similar to the in-vehicle device 11 in Step S109, perform overwrite installation of the program executed by this device or other repository installation and startup.

[0052] Similarly, it is also possible to update the programs of other in-vehicle devices.

[0053] In this way, the external device 100 enables each in-vehicle device to reliably store the update data by changing the compression ratio of the update data of each in-vehicle device to fit within the storable size of each in-vehicle device that is the object of program update. In addition, since the external device 100 performs data compression processing at a compression ratio such that the update data of the in-vehicle device becomes below this size according to the storable size of each in-vehicle device, it is possible to suppress an unnecessary increase in the compression ratio and to suppress the load of the data compression processing of the external device 100 as much as possible.

[0054] In addition, in Step S104, in the case where there is an in-vehicle device for which even if the compression ratio is increased, one update data cannot be made below the storable size, the update data of the in-vehicle device can be segmented into below the storable size. For example, in the case where the update data of the in-vehicle device 11 is large and cannot be made below the storable size of the in-vehicle device 11 even at the maximum compression ratio, the update data of the in-vehicle device 11 can be segmented to generate each segmented update data with different transmission units. In this case, in the processing of Steps S106 to S109, the processing of sending, downloading, and installing a part of the update data of the in-vehicle device 11 is repeated the number of times of the generated transmission units. Also, if the in-vehicle device 11 is a dual repository type, it is started after the installation is completed. In this way, since the external device 100 performs the segmentation of the update data of one in-vehicle device, the software update device 50 can avoid performing the segmentation process of the update data, and thus, the processing load of the software update device 50 can be suppressed. In addition, the control unit 54 of the software update device 50 can specify which of the compression and segmentation of the update data of each in-vehicle device to prioritize in Step S103.

[0055] Alternatively, in steps S108 and S110, the control unit 54 of the software update device 50 can divide the update data of each in-vehicle device that is the update target of the program into two or more parts without considering its size, and send it to the in-vehicle device that is the update target. For example, even if the update data of the in-vehicle device 11 is below the storable size of the in-vehicle device 11, the control unit 54 can divide the update data of the in-vehicle device 11 and send it at multiple times. Therefore, the communication load of the network system 1 can be dispersed and the operation can be stabilized.

[0056] In addition, in step S102, when there is an update notification, the transmission management unit 112 obtains the size of the update data of each of one or more in-vehicle devices that are the update targets of the program without compression and division, and sends it to the software update device 50. In this case, for example, in step S103, if the size of the received update data of the in-vehicle device is below the storable size of the in-vehicle device that stores the update data, the control unit 54 of the software update device 50 notifies the request to send the update data of the in-vehicle device as it is in the notified size without compression and division, rather than notifying the storable size of the in-vehicle device to the external device 100. In addition, in this case, in step S104, since the transmission management unit 112 of the external device 100 can determine that the storable size of the in-vehicle device is a sufficient size to store the update data without compression, the data is not compressed and is used as the update data as it is. Therefore, since the external device 100 does not need to perform processes such as determining the compression rate of the data based on the storable size and compressing it, the processing load can be suppressed.

[0057] In addition, in step S103, the control unit 54 of the software update device 50 can control each in-vehicle device to increase the storable size of its second storage unit, and notify the increased storable size to the external device 100. Therefore, the external device 100 can reduce the compression rate and suppress the load of the data compression process. In addition, this process can be performed on in-vehicle devices whose update data size of this device is larger than the current storable size, where the control unit 54 receives the size without compressing and dividing the update data of each of one or more in-vehicle devices from the external device 100.

[0058] As described above, Processing Example 1 and Processing Example 2 have been explained. Processing Example 1 can be appropriately applied to a case where the storage area of the software update device 50 may be insufficient, but the storage areas of the respective in-vehicle devices are not insufficient. Processing Example 2 can be appropriately applied to a case where the storage area of the software update device 50 is not insufficient, but the storage areas of the respective in-vehicle devices may be insufficient. In a case where the storage area of any one of the software update device 50 and the respective in-vehicle devices may be insufficient, Processing Example 1 and Processing Example 2 can be combined and implemented. That is, it can be set as follows: The update data received by the software update device 50 from the external device 100 can be stored by the software update device 50, and the update data of each in-vehicle device received by the software update device 50 from the respective in-vehicle devices can be stored by the in-vehicle device. In addition, a case where a device other than the software update device 50 and the in-vehicle device to be updated is used as a shared storage device to temporarily store the update data is considered, and the same method can be appropriately applied. For example, in Processing Example 1, when an update data is stored by a device other than the software update device 50, the same processing can be performed based on the storage size of the other device instead of the storage size of the software update device 50. In this way, the present embodiment can cause the external device 100 to transmit update data configured such that the storage area of the specified in-vehicle device is not insufficient, based on the storage size of the specified in-vehicle device selected from among the plurality of in-vehicle devices included in the in-vehicle network.

[0059] In addition, in Processing Example 1, there may be a case where the storage size of the software update device 50 is insufficient and it is impossible to store the update data of all in-vehicle devices to be updated as programs. In this case, for example, in step S106, the transmission management unit 112 of the external device 100 can detect this situation, generate update data that includes the update data of in-vehicle devices selected in order starting from the in-vehicle devices with higher priorities determined for each in-vehicle device within the allowable size range, and transmit it to the software update device 50. For example, a higher priority can be set for in-vehicle devices related to driving performance and safety performance. In addition, in Processing Example 2, even for an in-vehicle device to be updated as a program, there may be a case where the storage size of this in-vehicle device is insufficient and the program cannot be updated. In this case, for example, in step S106, the transmission management unit 112 of the external device 100 can detect this situation, generate update data that does not include the update data of the in-vehicle device with insufficient storage size but includes the update data of other in-vehicle devices, and transmit it to the software update device 50. In addition, the transmission management unit 112 can generate information specifying the in-vehicle device for which the program update has not been performed due to the above-mentioned insufficient storage size and notify it to the software update device 50. The control unit 54 of the software update device 50 can notify the user of the situation that there is an in-vehicle device for which the program update has not been performed or further specify the information of this in-vehicle device. In addition, when the priority of the in-vehicle device for which the program update has not been performed is lower than the specified priority, the notification may not be made.

[0060] In addition, for the vehicle-side processing in each of the above steps, in particular, for the transmission of update data to each in-vehicle device such as steps S108 and S110, and for the installation and startup processing in each in-vehicle device such as steps S109 and S111, restrictions can be appropriately set. For example, when performing an operation to disconnect the vehicle's power supply (ignition off, power off), in order to prevent battery depletion, the control unit 54 can interrupt these processes. Alternatively, only in-vehicle devices that are pre-determined or specified by the external device 100 within the update data are allowed to execute the processing when the power supply is disconnected, and the processing for other in-vehicle devices is interrupted. In addition, the control unit 54 can appropriately calculate or obtain the power required for each update process and the remaining battery capacity, and can execute the processing of each in-vehicle device when it is estimated that the remaining battery capacity will not become less than the specified value even if the processing is executed when the power supply is disconnected, or can execute the processing of a part of the in-vehicle devices within the range where it is estimated that the remaining battery capacity will become less than the specified value. In addition, when executing the processing when the power supply is disconnected, the functions of the in-vehicle device are restricted compared to when the power supply is turned on and normal startup occurs, and only the processing required for updates such as installation and startup can be executed to suppress power consumption. In this way, if the processing can be continued as much as possible when the power supply is disconnected, the program update can be completed earlier and the convenience is improved.

[0061] <Effect> In the present embodiment, the software update device 50 can receive update data generated so as not to make the storage areas of the respective in-vehicle devices insufficient from the external device 100, and can appropriately update the programs of the in-vehicle devices.

[0062] The technology of the present invention relates not only to the software update device and the external device, but also to a network system including the software update device, methods, programs executed by each of the computers included in the software update device and the external device, a computer-readable non-volatile storage medium storing the program, a vehicle including the software update device, and the like.

[0063] The technology of the present invention is useful for a network system mounted on a vehicle or the like.

Claims

1. A host configured to control software updates for a target electronic control unit that is an object of software update among a plurality of electronic control units mounted on a vehicle. After receiving an update notification including size information of update data from a center, the host obtains the free capacity of the storage unit of a specific electronic control unit from among the plurality of electronic control units. Based on the size information of the update data and the free capacity, the host makes a download request for the update data to the center, configured such that the storage area of the storage unit will not be insufficient. Receives the update data from the center. Using the received update data, when the power supply of the vehicle is turned off, the host causes the software of the target electronic control unit to start up in the target electronic control unit.

2. The host according to claim 1, wherein the update data is data that has been compressed or segmented by the center based on the size information of the update data and the free capacity.

3. The host according to claim 1 or 2, wherein the host includes: a first storage unit that stores the update data downloaded from the center; and a control unit that confirms the free capacity of the first storage unit as the free capacity of the storage unit of the specific electronic control unit, and uses the update data to perform an update of the software of the target electronic control unit.

4. The host according to claim 3, wherein the control unit also confirms the free capacity of a second storage unit of the target electronic control unit as the free capacity of the storage unit of the specific electronic control unit, and uses the update data to perform an update of the software of the target electronic control unit.

5. A vehicle having the OTA host according to claim 1 or 2.

Images