MASTER, NETWORK SYSTEM, METHOD, PROGRAM, CENTER, AND VEHICLE

Abstract

To provide a master capable of suitably updating a program according to the storable size of the master.SOLUTION: A master controls software update of a target electronic control unit that is subject to software update among a plurality of electronic control units installed in a vehicle. The master obtains the storage free capacity of a specific electronic control unit among the plurality of electronic control units, transmits a download request for update data for software update to a center based on the free capacity, receives the update data from the center, and uses the received update data to cause the target electronic control unit to activate the software of the target electronic control unit when the vehicle is powered off.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a software update device (master) and the like included in a network system mounted on a vehicle or the like. [Background technology]

[0002] Vehicles are equipped with a network system consisting of multiple on-board devices called ECUs (Electronic Control Units) connected to each other via communication lines. Each on-board device sends and receives messages to each other and shares and executes each function of the vehicle.

[0003] An in-vehicle device typically includes a processor and a temporary storage unit such as a RAM or a non-volatile storage unit such as a flash ROM. The programs (software) executed by the processor are stored in the non-volatile storage unit. By updating the programs with newer versions, the functions of the in-vehicle device can be improved and enhanced.

[0004] Program updates include the steps of downloading, in which update data is received from an external device (center) via wireless communication or the like, and installing, in which an update program (update software) is written into the storage unit of the in-vehicle device based on the downloaded update data. Depending on the specifications of the in-vehicle device, installation can be performed in two ways: overwrite installation, in which the downloaded update program is written by overwriting the current program (old program) into one area (first side: single bank) of the storage unit that is designated as an area for program storage, and dual-side installation, in which the downloaded update program is written into the area (other side) that is not the area (one side) where the current program (old program) is stored, out of two areas (two sides: dual banks) that are designated as areas for program storage.

[0005] In the case of a multi-faceted installation, in addition to the download and installation steps, the program update step includes an activation step that configures the settings of the update program, such as the start address, so that the installed update program can be executed.

[0006] In relation to updating a program in an ECU, Patent Document 1 discloses that a specific ECU functions as a master ECU, communicates with a server, and updates the programs of the master ECU itself and other slave ECUs. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] JP 2011-148398 A Summary of the Invention [Problem to be solved by the invention]

[0008] The above downloading and installation are controlled by a software update device included in the network system. The software update device, for example, downloads update programs for each of a plurality of in-vehicle devices from an external device collectively, temporarily stores the programs in a storage unit included in the software update device, and then transmits the update programs to each in-vehicle device, causing each in-vehicle device to install or further activate the programs. The storage unit may be shared with other in-vehicle devices and used to store various data. The further storage area, such as the free space of the storage unit, varies depending on the amount of various data stored, so when there is little free storage area, there is a risk that the update programs cannot be downloaded and stored collectively.

[0009] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a software update device (master) or the like that can suitably update a program according to the storage size of the software update device (master) or the like. [Means for solving the problem]

[0010] In order to solve the above problem, one aspect of the disclosed technology is a master that controls software updates of a target electronic control unit that is the subject of a software update among multiple electronic control units mounted on a vehicle, the master obtains free storage space of a specific electronic control unit among the multiple electronic control units, transmits a request to a center to download update data for the software update based on the free space, receives the update data from the center, and uses the received update data to activate the software of the target electronic control unit in the target electronic control unit when the vehicle is turned off. Effect of the Invention

[0011] According to the disclosed technology, a software update device (master) or the like can receive update data from a center that is generated so that the software update device or the like does not run out of memory space, thereby enabling program updates of in-vehicle equipment to be performed efficiently. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a configuration diagram of a network system according to an embodiment; [Diagram 2] A sequence diagram showing a process according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] (Embodiment) <Configuration> FIG. 1 shows a configuration example of a 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. A plurality of buses 10, 20, 30, etc. are connected to the software update device (OTA master) 50. A plurality of in-vehicle devices (electronic control units) 11, 12, etc. are connected to the bus 10. A plurality of in-vehicle devices 21, 22, etc. are connected to the bus 20. A plurality of actuators 31, 32, etc. are connected to the bus 30. In FIG. 1 and the following description, the buses 10, 20, and 30 are exemplified as buses, and the in-vehicle devices 11, 12, 21, and 22 and the actuators 31 and 32 are exemplified as in-vehicle devices, but the numbers of these are not limited.

[0014] The software update device (master) 50 includes a communication unit (communication module) 51 capable of communicating with an external device (center) 100 installed outside the vehicle, a first memory unit (storage) 52 that stores various data, a confirmation unit 53 that controls and manages access to the first memory unit 52 and can check the available space in the first memory unit 52, and a control unit 54.

[0015] The in-vehicle devices 11, 12, 21, and 22 communicate with each other via a network and perform various processes for controlling the vehicle. Although not shown, these in-vehicle devices include a non-volatile second storage unit (storage) such as a flash ROM, a control unit (processor) that reads and executes a program (software) from the second storage unit to perform various processes, and a temporary storage unit such as a RAM that stores part of the program and data. The software update device 50 also stores a program for the software update device 50 in the first storage unit 52, and the control unit (processor) reads and executes the program to perform the functions of the confirmation unit 53 and the control unit 54. That is, the in-vehicle devices 11, 12, 21, and 22 and the software update device 50 can be implemented as a computer including a processor. The first storage unit 52 can be accessed for reading and writing from the in-vehicle devices 11, 12, 21, and 22, and may be used as a shared storage device.

[0016] Further, the control unit of the software update device 50 controls and relays communications between the external device 100 and each of the in-vehicle devices 11, 12, 21, 22, communications between each of the in-vehicle devices 11, 12, 21, 22, and communications between each of the in-vehicle devices 11, 12, 21, 22 and each of the actuators 31, 32 via each of the buses 10, 20, 30. In this manner, the software update device 50 also functions as a relay device that relays communications.

[0017] The actuators 31 and 32 are devices that generate mechanical effects on the vehicle or its parts, such as a brake, an engine, or a power steering device, and operate based on instructions from the on-vehicle devices 11, 12, 21, and 22.

[0018] The control unit 54 of the software update device 50 can update the programs stored in the second storage units of the in-vehicle devices 11, 12, 21, and 22. That is, the software update device 50 performs control of downloading, control of installing, and further control of activating. Downloading is a process of receiving and storing update data (distribution package) for updating a program of any of the in-vehicle devices 11, 12, 21, and 22 transmitted from the external device 100. Downloading control can include not only download execution, but also control of a series of processes related to downloading, such as determining whether downloading can be performed and verifying the update data. Installing is a process of writing an updated version of a program (update software) into the storage unit of the in-vehicle device to be updated based on the downloaded update data. Installing control can include not only installation execution, but also control of a series of processes related to installation, such as determining whether installation can be performed, transferring the update data, and verifying the updated version of the program. Activating is a process of validating (activating) the installed updated version of the program. The control of activation may include not only the execution of activation, but also a series of controls related to activation, such as determining whether activation can be executed and verifying the execution result.

[0019] In controlling the installation, if the update data includes the update program itself, the control unit 54 can transmit the update program to the in-vehicle device. Also, if the update data includes compressed data, difference data, or divided data of the update program, the control unit 54 may expand or assemble the update data to generate an update program and transmit it to the in-vehicle device. Alternatively, the control unit 54 may transmit the update data to the in-vehicle device, and the in-vehicle device may expand or assemble the update data to generate the update program.

[0020] The installation itself, which writes the update program into the second memory unit of the in-vehicle device, may be performed by the control unit 54, or may be performed by the in-vehicle device upon receiving instructions from the control unit 54, or may be performed autonomously by the in-vehicle device that receives the update data (or update program) even without explicit instructions from the control unit 54.

[0021] The activation process to activate the installed update program may be performed by the control unit 54, or may be performed by the in-vehicle device upon receiving instructions from the control unit 54, or may be performed autonomously by the in-vehicle device following installation without explicit instructions from the control unit 54.

[0022] Such program update processing can be performed consecutively or in parallel for each of a plurality of in-vehicle devices. The update data is data used to generate an update program, and the contents and format are not limited, and include, for example, the update program itself, differential data for generating the update program, or compressed data or divided data thereof. The update data may also include an identifier (ECU ID) of the in-vehicle device (target electronic control unit) that is the target of the program update, and an identifier (WCU Software ID) of the version of the program before the update.

[0023] The external device 100 is, for example, a computer device such as a server installed in a specific center, etc. The external device 100 includes a communication unit 111 that communicates with the software update device 50 and a communication management unit (control unit) 112 that manages the communication unit 111. The external device 100 also includes a storage unit (not shown) and can receive and store data for updating the programs of each of a plurality of in-vehicle devices from the outside.

[0024] <Processing example 1> An example of the process according to this embodiment will be described below. A sequence diagram showing this process is shown in Fig. 2. First, an example of the process performed according to the size of the available storage area of ​​the first storage unit 52 of the software update device 50 will be shown.

[0025] (Step S101) The control unit 54 of the software update device 50 controls the communication unit 51 to inquire of the external device 100 whether or not an update program is available. This inquiry may be made periodically, for example, or may be made when a predetermined operation such as turning on the power supply of the vehicle (ignition on, power on) is performed.

[0026] (Step S102) When the communication unit 111 of the external device 100 receives the inquiry, the transmission management unit 112 controls the communication unit 111 to transmit an update presence notification to the software update device 50 if an update program exists. The transmission management unit 112 can determine the presence or absence of an update program, which is an updated version of the program for the in-vehicle devices, based on information indicating the types of the multiple in-vehicle devices included in the network system 1 and the current program version, for example. Such information may be stored in the external device 100 in advance, or may be received from the software update device 50 together with the inquiry. Note that, if an update program does not exist, the transmission management unit 112 controls the communication unit 111 to transmit a no update notification to the software update device 50.

[0027] (Step S103) When the communication unit 51 of the software update device 50 receives a notification that there is an update, the control unit 54 acquires the size that the first storage unit 52 can store from the confirmation unit 53, and controls the communication unit 51 to notify the external device 100 of the size that can be stored. Note that when the communication unit 51 receives a notification that there is no update, the processing ends. Note that the size that can be stored refers to the size that the first storage unit 52 can store data of that size without affecting the processing of the software update device 50, and is typically the size of the free space.

[0028] (Step S104) When 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 includes data for updating the programs of one or more in-vehicle devices. For example, the transmission management unit 112 creates update data by adjusting the compression rate to compress each update program of one or more in-vehicle devices (target electronic control units) to be updated in programs, or difference data (update data for each in-vehicle device) used to generate the update program, so that the total size is equal to or smaller than the storable size. Note that if a series of data is equal to or smaller than the storable size of the first storage unit 52 even without compression, the external device 100 does not need to compress the data. Hereinafter, a package of data for updating the programs of one or more in-vehicle devices is simply referred to as update data, and data included in the update data for updating the program of one in-vehicle device is referred to as the update data of that in-vehicle device.

[0029] (Step S105) The control unit 54 of the software update device 50 controls the communication unit 51 to issue a download request representing a request to transmit update data to the external device 100. The download request may be included in the notification of the storable size in step S103, or may be issued consecutively to the notification of the storable size. The process of the external device 100 in step S104 may be performed after the download request.

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

[0031] (Step S107) When the communication unit 51 of the software update device 50 receives the update data, the confirmation unit 53 stores (downloads) the update data in a free area of ​​the first storage unit 52.

[0032] (Step S108) The control unit 54 of the software update device 50 reads the update data from the first storage unit 52 and generates update data for each in-vehicle device that is a program update target. For example, the control unit 54 unpacks the update data read from the first storage unit 52 and divides it into update data for each in-vehicle device. The control unit 54 also controls the communication unit 51 to transmit the update data to the in-vehicle device that is a program update target. In this step, as an example, the in-vehicle device 11 is included in the in-vehicle devices that are a program update target, and the control unit 54 transmits the update data for the in-vehicle device 11 to the in-vehicle device 11.

[0033] (Step S109) When the in-vehicle device 11 receives the update data, it updates the program executed by itself based on the received update data. That is, if the in-vehicle device 11 is a single bank type, the in-vehicle device 11 performs the above-mentioned overwrite installation. Also, if the in-vehicle device 11 is the above-mentioned dual bank type, the in-vehicle device 11 performs the above-mentioned other side installation and activation in this order.

[0034] (Step S110) If there is any unsent 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 transmit the update data to the in-vehicle device to be updated. In this step, as an example, the in-vehicle device 12 is included in the in-vehicle devices to be updated for the program, and the control unit 54 transmits the update data for the in-vehicle device 12 to the in-vehicle device 12.

[0035] (Step S111) When the in-vehicle device 12 receives the update data, it performs overwrite installation or other side installation and activation of the program executed by the in-vehicle device 12 based on the received update data in the same manner as the in-vehicle device 11 in step S109.

[0036] The above example is an example in which the update data received from the external device 100 includes update data for the in-vehicle devices 11 and 12, and updates the programs of the in-vehicle devices 11 and 12, but updates to the programs of other in-vehicle devices can be performed in a similar manner. Also, the number of in-vehicle devices to be updated is not limited to two, and may be one, three or more.

[0037] In this way, the external device 100 changes the compression ratio of the update data so that it fits within the storable size of the first storage unit 52 of the software update device 50, thereby enabling the software update device 50 to reliably store the update data in the first storage unit 52. Furthermore, since the external device 100 performs data compression processing at a compression ratio that is equal to or smaller than the storable size of the first storage unit 52 of the software update device 50, it is possible to prevent the compression ratio from being made larger than necessary, and it is possible to minimize the load of the data compression processing on the external device 100.

[0038] Also, in step S104, if one piece of update data cannot be reduced to a size that is smaller than the storable size even if the compression rate is increased, multiple pieces of update data smaller than the storable size may be generated. For example, if the in-vehicle devices to be updated are the in-vehicle devices 11, 12, 21, and 22, and the total amount of data for updating the programs of these in-vehicle devices is large and the update data does not become smaller than the storable size even at the maximum compression rate, the update data for the in-vehicle devices 11 and 12 and the update data for the in-vehicle devices 21 and 22 may be generated as transmission units. In this case, the process from transmitting the update data to updating the programs in each in-vehicle device, such as steps S106 to S111, is repeated the number of times equal to the number of generated transmission units. Note that, in this way, when the external device 100 generates update data divided into multiple transmission units, the necessity of compressing each piece of update data and the compression rate when compressing can be set so that the size of the update data is smaller than the storable size of the first storage unit 52. Note that the control unit 54 of the software updating device 50 may specify in step S103 which of compression and division of the update data is to be given priority.

[0039] Also, in step S102, when notifying that there is an update, the transmission management unit 112 may obtain the size of the update data when it is not compressed or divided, and transmit it to the software update device 50. In this case, for example, in step S103, if the received size is equal to or smaller than the storable size, the control unit 54 of the software update device 50 notifies the external device 100 of the storable size, and notifies the external device 100 of a request to transmit the update data without compressing and dividing it. Also, in this case, in step S104, the transmission management unit 112 of the external device 100 can determine that the storable size of the first storage unit 52 is sufficient to store the update data without compressing it, and therefore generates the update data without compressing and dividing it. This eliminates the need for the external device 100 to perform a process of determining the compression rate of data based on the storable size and compressing it, thereby reducing the processing load.

[0040] Also, 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 may notify the external device 100 of the increased storable size. This allows the external device 100 to reduce the compression ratio and suppress the load of the data compression process. The storable size may be increased, for example, by releasing areas of the storage area of ​​the first storage unit 52 that are reserved as areas in use by the control unit 54 and the in-vehicle devices sharing the first storage unit 52, and that do not need to be kept reserved or that do not need to be reserved very much. This process may be performed when the control unit 54 receives the size of the update data when it is not compressed and divided from the external device 100, and the received size is larger than the current storable size of the first storage unit 52.

[0041] <Processing example 2> Next, an example of processing to be performed according to the size of the storage area of ​​the second storage unit of the vehicle-mounted device to be updated will be shown. In this example, the same step numbers are used to refer to the processing corresponding to the processing in the above-mentioned processing example 1, with reference to the sequence diagram in Figure 2. Also, the description of the same matters as those in the above-mentioned processing example 1 will be omitted as appropriate.

[0042] (Step S101) As in the processing example 1, the control unit 54 of the software updating device 50 controls the communication unit 51 to inquire of the external device 100 about the presence or absence of an update program.

[0043] (Step S102) As in the processing example 1, when the communication unit 111 of the external device 100 receives an inquiry, the transmission management unit 112 controls the communication unit 111 to transmit a notification to the software update device 50 that an update program is available if an update program is available.

[0044] (Step S103) When the communication unit 51 of the software update device 50 receives the update availability notification, the control unit 54 acquires the storable size of the second storage unit of each in-vehicle device, and controls the communication unit 51 to notify the external device 100 of the storable size. The update availability notification may include information specifying the in-vehicle device to be updated, and the control unit 54 may acquire the storable size of each of the specified in-vehicle devices. In this example, the storable size refers to a size in which the in-vehicle device can store data of that size without affecting the processing of the in-vehicle device and can perform program update processing, and is typically a free space.

[0045] (Step S104) When 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. For example, the transmission management unit 112 creates update data by compressing the update data for each in-vehicle device by adjusting the compression rate so that the size of the data does not cause a shortage of storage space in the in-vehicle device, and then consolidating the compressed data. Note that if the storable size of the in-vehicle device is such that the storage space is not insufficient even if the update data for the in-vehicle device is not compressed, the external device 100 does not need to perform compression.

[0046] (Step S105) As in the processing example 1, the control unit 54 of the software update device 50 controls the communication unit 51 to make a download request representing a request to transmit update data to the external device 100. The download request may be included in the notification of the storable size in step S103, or may be made consecutively to the notification of the storable size. The processing of the external device 100 in step S104 may be performed after the download request.

[0047] (Step S106) As in the processing example 1, the transmission management unit 112 of the external device 100 controls the communication unit 111 to transmit the update data to the software update device 50 as one transmission unit.

[0048] (Step S107) As in the first processing example, the confirmation unit 53 stores (downloads) the update data in a free area of ​​the first storage unit 52.

[0049] (Step S108) As in the processing example 1, the control unit 54 of the software update device 50 generates update data for each in-vehicle device to be updated and transmits each update data to the in-vehicle device to be updated. In this step, as an example, the control unit 54 transmits update data for the in-vehicle device 11 to the in-vehicle device 11.

[0050] (Step S109) When the in-vehicle device 11 receives the update data, it updates the program executed by itself based on the received update data. That is, if the in-vehicle device 11 is the above-mentioned single bank type, the in-vehicle device 11 performs overwrite installation. Also, if the in-vehicle device 11 is the above-mentioned dual bank type, the in-vehicle device 11 performs the other-side installation and activation in this order. This allows the in-vehicle device 11 to receive compressed update data from the software update device 50, temporarily store it in a free area, expand it to generate an update program, and install it, without running out of storage capacity, so that the load on the software update device 50 can be reduced compared to when the update program is generated on the software update device 50 side.

[0051] (Step S110) As in the processing example 1, if there is any unsent 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 transmit the update data to the in-vehicle device to be updated. In this step, as an example, the control unit 54 transmits the update data for the in-vehicle device 12 to the in-vehicle device 12.

[0052] (Step S111) When the in-vehicle device 12 receives the update data, it performs overwrite installation or other side installation and activation of the program executed by the in-vehicle device 12 based on the received update data in the same manner as the in-vehicle device 11 in step S109.

[0053] In the same manner as above, the programs of other in-vehicle devices can also be updated.

[0054] In this way, the external device 100 changes the compression ratio of the update data for each vehicle-mounted device so that the update data fits within the storage capacity of each vehicle-mounted device that is the target of program update, thereby allowing each vehicle-mounted device to reliably store the update data. Also, since the external device 100 performs data compression processing at a compression ratio that is equal to or smaller than the storage capacity of each vehicle-mounted device, it is possible to prevent the compression ratio from being increased more than necessary, and to minimize the load of the data compression processing on the external device 100.

[0055] Also, in step S104, if there is an in-vehicle device that cannot be compressed to a size equal to or smaller than the storable size with one update data even if the compression rate is increased, the update data of the in-vehicle device may be divided to a size equal to or smaller than the storable size. For example, if the update data of the in-vehicle device 11 is large and cannot be compressed to a size equal to or smaller than the storable size of the in-vehicle device 11 even at the maximum compression rate, the update data of the in-vehicle device 11 may be divided and each divided data may be generated as a different transmission unit. In this case, in the process of steps S106 to S109, the process of transmitting, downloading, and installing a part of the update data of the in-vehicle device 11 is repeated the number of times equal to the number of generated transmission units. Note that if the in-vehicle device 11 is a dual bank type, activation is performed after installation is completed. In this way, by the external device 100 dividing the update data of one in-vehicle device, the software update device 50 does not need to divide the update data, so that the processing load of the software update device 50 can be suppressed. Note that the control unit 54 of the software update device 50 may specify in step S103 which of compression and division is to be given priority for the update data for each in-vehicle device.

[0056] Alternatively, in steps S108 and S110, the control unit 54 of the software update device 50 may divide the update data of each in-vehicle device to be updated into two or more pieces regardless of the size of the data, and transmit the divided data to the in-vehicle device to be updated. For example, even if the update data for the in-vehicle device 11 is equal to or smaller than the size that the in-vehicle device 11 can store, the control unit 54 may divide the update data and transmit the divided data at multiple times. This can distribute the communication load of the network system 1 and stabilize the operation.

[0057] Also, in step S102, when notifying that there is an update, the transmission management unit 112 may obtain the size of the update data of each of one or more in-vehicle devices to be updated as a program when the data is not compressed or divided, and transmit the size to the software update device 50. In this case, for example, in step S103, if the size of the received update data is equal to or smaller than 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 external device 100 of the storable size of the in-vehicle device, and notifies the external device 100 of a request to transmit the update data of the in-vehicle device as the notified size without compressing or dividing it. Also, in this case, in step S104, 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, and therefore the data is used as the update data as it is without compressing it. This eliminates the need for the external device 100 to perform a process of compressing the data by determining the compression rate based on the storable size, thereby reducing the processing load.

[0058] Also, in step S103, the control unit 54 of the software update device 50 may control each in-vehicle device to increase the storable size of its second storage unit, and notify the external device 100 of the increased storable size. This allows the external device 100 to reduce the compression rate and suppress the load of the data compression process. Note that this process may be performed by the control unit 54 receiving from the external device 100 the size of the update data of each of one or more in-vehicle devices when it is not compressed and divided, and performing this process for an in-vehicle device whose update data size is larger than the current storable size.

[0059] The process example 1 and the process example 2 have been described above. The process example 1 can be suitably applied when the storage area of ​​the software update device 50 is likely to be insufficient, but the storage area of ​​each in-vehicle device is not likely to be insufficient. The process example 2 can be suitably applied when the storage area of ​​the software update device 50 is not likely to be insufficient, but the storage area of ​​each in-vehicle device is likely to be insufficient. When the storage area of ​​either the software update device 50 or each in-vehicle device is likely to be insufficient, the process example 1 and the process example 2 can be combined and implemented. That is, 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 for each in-vehicle device received by the software update device 50 from each in-vehicle device can be stored by that in-vehicle device. In addition, a device other than the software update device 50 and the in-vehicle device to be the target of the software update may be used as a shared storage device to temporarily store the update data, and a similar method can be suitably applied. For example, in the processing example 1, when another device stores update data instead of the software update device 50, a similar process can be performed based on the storable size of the other device instead of the storable size of the software update device 50. In this manner, the present embodiment can cause the external device 100 to transmit update data configured so as not to cause a shortage of storage space in a specific in-vehicle device, based on the storable size of the specific in-vehicle device selected from a plurality of in-vehicle devices included in the in-vehicle network.

[0060] In addition, in the processing example 1, the storage capacity of the software update device 50 may be insufficient, and the update data for all the in-vehicle devices that are the target of the program update may not be stored. In this case, for example, in step S106, the transmission management unit 112 of the external device 100 may detect this, generate the update data so that the update data for the in-vehicle devices selected in order from the in-vehicle devices with the highest priority are included within the range of the allowable size based on the priority determined for each in-vehicle device, and transmit the generated update data to the software update device 50. For example, the priority may be set relatively high for in-vehicle devices related to driving performance and safety performance. In addition, in the processing example 2, even if the in-vehicle device is the target of the program update, the storage capacity of the in-vehicle device may be insufficient, and the program may not be updated. In this case, for example, in step S106, the transmission management unit 112 of the external device 100 may detect this, generate the update data including the update data for the in-vehicle devices that are the target of the program update, but not including the update data for the in-vehicle devices with the insufficient storage capacity, and transmit the generated update data to the software update device 50. Furthermore, the transmission management unit 112 may generate information identifying in-vehicle devices for which program updates have not been performed due to insufficient storage size and notify the software update device 50, and the control unit 54 of the software update device 50 may notify the user of the presence of in-vehicle devices for which program updates have not been performed, or may further notify the user of information identifying the in-vehicle devices. Note that if the priority of the in-vehicle devices for which program updates have not been performed is lower than a predetermined priority, notification may not be given.

[0061] In addition, the vehicle-side processing in each step described above, particularly the transmission of update data to each in-vehicle device such as in steps S108 and S110, and the installation and activation processing in each in-vehicle device such as in steps S109 and S111, may be appropriately restricted. For example, when the vehicle is turned off (ignition off, power off), the control unit 54 may suspend these processing to prevent the battery from running out. Alternatively, only in-vehicle devices that are predetermined or specified in the update data from the external device 100 may be permitted to execute processing when the power is off, and processing for other in-vehicle devices may be suspended. In addition, the control unit 54 may appropriately calculate or acquire the amount of power required for each update processing and the remaining capacity of the battery, and execute the processing for each in-vehicle device when it is estimated that the remaining capacity of the battery will not fall below a predetermined level even if the processing is executed when the power is off, or may execute the processing for some of the in-vehicle devices within a range where it is estimated that the remaining capacity of the battery will not fall below a predetermined level. In addition, when processing is performed when the power is off, the in-vehicle device may limit functions compared to normal startup such as when the power is on, and may execute only processes necessary for updating such as installation and activation to reduce power consumption. In this way, by continuing processing as much as possible even when the power is off, the program update can be completed quickly and convenience can be improved.

[0062] <Effects> In this embodiment, the software update device 50 can receive update data from the external device 100 that is generated so that each in-vehicle device does not run out of memory space, and can optimally perform program updates for the in-vehicle devices.

[0063] The present disclosed technology can be understood as not only a software update device (master), an external device, but also a network system including a software update device, a method executed by each of the computers equipped in the software update device and the external device, a program and a computer-readable non-transitory storage medium on which the program is stored, a vehicle equipped with a software update device, etc. [Industrial Applicability]

[0064] The disclosed technology is useful for network systems mounted on vehicles and the like. [Explanation of symbols]

[0065] 1 Network System 10, 20, 30 Bus 11, 12, 21, 22 Automotive equipment 31, 32 Actuator 50 Software update device (master) 51 Communications Department 52 1st memory section 53 Verification Department 54 Control section 100 External device (center) 111 Communications Department 112 Transmission Management Department

Claims

1. A master that controls software update of a target electronic control unit that is a software update target among a plurality of electronic control units mounted on a vehicle, Obtaining the free space of a storage of a specific electronic control unit that stores update data for the software update to be downloaded from a center; transmitting a download request for the update data to the center based on the available capacity; receiving the update data from the center; A master activates software of the target electronic control unit using the received update data when the vehicle is powered off.

2. 2. The master according to claim 1, wherein the update data is data compressed or divided by the center based on the free space.

3. A network system including a plurality of electronic control units mounted on a vehicle, and a master that controls software updates of target electronic control units that are targets of software updates among the plurality of electronic control units, The master acquires free space in a storage of a specific electronic control unit that stores update data for the software update to be downloaded from a center, the master transmits a download request for the update data to the center based on the available capacity; The master receives the update data from the center, A network system in which the master uses the received update data to activate software in the target electronic control unit when the vehicle's power is turned off.

4. 4. The network system according to claim 3, wherein the update data is data that has been compressed or divided by the center based on the available capacity.

5. a first storage for storing the update data downloaded from the center; 3. The master according to claim 1, further comprising: a control unit that checks the free space of the first storage as the free space of the storage of the specific electronic control unit, and uses the update data to perform a software update of the target electronic control unit.

6. A method implemented by a master computer, comprising: When downloading from the center, acquiring free space of a storage of a specific electronic control unit mounted on the vehicle for storing update data for software update downloaded from the center; transmitting a download request for the update data to the center based on the available capacity; receiving the update data from the center; and using the received update data to activate software of a target electronic control unit that is to be updated, in the target electronic control unit when the vehicle is powered off.

7. A program to be executed on a master computer, When downloading from the center, acquiring free space of a storage of a specific electronic control unit mounted on the vehicle for storing update data for software update downloaded from the center; transmitting a download request for the update data to the center based on the available capacity; receiving the update data from the center; and a step of activating software of a target electronic control unit, the software of which is to be updated, in the target electronic control unit when the power supply of the vehicle is turned off, using the received update data.

8. A vehicle comprising the master according to any one of claims 1 to 5.

Images