On-vehicle update system, on-vehicle device, and on-vehicle ecu

Abstract

To provide an on-vehicle update system etc. that reduce time required for an on-vehicle device to transmit an update program to an on-vehicle ECU.SOLUTION: In an on-vehicle update system according to an embodiment of the present disclosure, an on-vehicle device sequentially transmits an update program to an on-vehicle ECU in blocks divided by predetermined size. The on-vehicle ECU stores, when receiving the blocks, the received blocks in a memory in order. The on-vehicle ECU performs, by using at least a part of the memory as a work area, post-processing on the blocks stored in the memory. The on-vehicle device transmits, even while the on-vehicle ECU is performing the post-processing on the blocks stored in the memory, a next block following the block currently undergoing the post-processing to the on-vehicle ECU.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present technology relates to an in-vehicle update system, an in-vehicle device, and an in-vehicle ECU. [Background technology]

[0002] A vehicle is equipped with an ECU (Electronic Control Unit) for controlling in-vehicle devices such as drive control systems (e.g., engine control) and body systems (e.g., air conditioning control). The ECU includes a processing unit such as an MPU, a rewritable nonvolatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs, and controls the in-vehicle devices by reading and executing control programs stored in the storage unit. The vehicle is also equipped with a communication device (in-vehicle device) equipped with wireless communication capabilities, and can communicate with a program provider connected to a network outside the vehicle via the communication device, download (receive) a control program for the ECU from the program provider, and update the control program for the ECU (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2017-97851 Summary of the Invention [Problem to be solved by the invention]

[0004] However, Patent Document 1 does not consider reducing the time it takes for an in-vehicle device to transmit an updating control program (update program) to an in-vehicle ECU.

[0005] The present disclosure has been made in view of the above circumstances, and aims to provide an in-vehicle system and the like that shortens the time required for an in-vehicle device to transmit an update program to an in-vehicle ECU. [Means for solving the problem]

[0006] An in-vehicle update system according to one embodiment of the present disclosure is an in-vehicle update system including an in-vehicle ECU mounted on a vehicle and an in-vehicle device that acquires update programs transmitted from an external server outside the vehicle and performs processing to update the program of the in-vehicle ECU, wherein the in-vehicle device transmits the update programs to the in-vehicle ECU sequentially in blocks divided into a predetermined size, and when the in-vehicle ECU receives the blocks, it stores the received blocks sequentially in memory, and the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a portion of the memory as a work area, and even while the in-vehicle ECU is performing post-processing on the block stored in the memory, the in-vehicle device transmits the next block following the block for which post-processing is being performed to the in-vehicle ECU. [Effects of the Invention]

[0007] In the in-vehicle update system according to an embodiment of the present disclosure, the time required for an in-vehicle device to transmit an update program to an in-vehicle ECU can be reduced. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram illustrating the configuration of an in-vehicle update system. [Figure 2] 1 is a block diagram illustrating a physical configuration of an in-vehicle device and an in-vehicle ECU according to a first embodiment. [Figure 3] FIG. 10 is an explanatory diagram showing the transition of memory usage status. [Figure 4] 1 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to the first embodiment and an in-vehicle ECU to be updated; [Figure 5] 1 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to the first embodiment and an in-vehicle ECU to be updated; [Figure 6] 1 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to the first embodiment and an in-vehicle ECU to be updated; [Figure 7] 3 is a flowchart illustrating a program update process of an in-vehicle device according to the first embodiment and an in-vehicle ECU to be updated. [Figure 8] 10 is a flowchart illustrating a subroutine of post-processing of a block of an in-vehicle ECU to be updated. [Figure 9] 4 is a flowchart illustrating a transmission control process of an in-vehicle device according to the first embodiment and an in-vehicle ECU to be updated. [Figure 10] FIG. 2 is an explanatory diagram illustrating an example of an ECU table. [Figure 11] FIG. 10 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to a second embodiment and an in-vehicle ECU to be updated. [Figure 12] FIG. 10 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to a second embodiment and an in-vehicle ECU to be updated. [Figure 13] FIG. 10 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to a second embodiment and an in-vehicle ECU to be updated. [Figure 14] FIG. 10 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device according to a second embodiment and an in-vehicle ECU to be updated. [Figure 15] 10 is a flowchart illustrating a transmission control process of an in-vehicle device according to a second embodiment and an in-vehicle ECU to be updated. [Figure 16] FIG. 10 is a schematic diagram showing the configuration of an in-vehicle update system according to a third embodiment. [Figure 17] FIG. 11 is a schematic diagram illustrating an example of an outline of a processing flow (sequence) by a terminal device, an in-vehicle device, and an in-vehicle ECU to be updated according to a third embodiment. [Figure 18] FIG. 10 is a block diagram illustrating the physical configuration of an in-vehicle device and an in-vehicle ECU according to a fourth embodiment. [Figure 19] FIG. 10 is a schematic diagram illustrating an example of an outline of a processing flow (sequence) performed by an in-vehicle device according to a third embodiment and a plurality of in-vehicle ECUs to be updated. [Figure 20]10 is a flowchart illustrating the correlation between a transmission control process and a program update process of an in-vehicle device according to a fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] [Description of the embodiments of the present disclosure] First, embodiments of the present disclosure will be listed and described. At least some of the embodiments described below may be combined in any desired manner.

[0010] (1) An in-vehicle update system according to one embodiment of the present disclosure includes an in-vehicle ECU mounted on a vehicle and an in-vehicle device that acquires update programs transmitted from an external server outside the vehicle and performs processing to update the program of the in-vehicle ECU, wherein the in-vehicle device transmits the update programs to the in-vehicle ECU sequentially in blocks divided into a predetermined size, the in-vehicle ECU sequentially stores the received blocks in memory when it receives the blocks, the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a portion of the memory as a work area, and the in-vehicle device transmits the next block following the block for which post-processing is being performed to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the memory.

[0011] In this aspect, an in-vehicle device of an in-vehicle update system acquires an update program for an in-vehicle ECU from an external server and divides the acquired update program into multiple blocks. The in-vehicle device transmits the divided blocks sequentially (e.g., in the order of first block, second block, third block, etc.) to an in-vehicle ECU (Electronic Control Unit). The in-vehicle ECU stores the received blocks of the update program in memory and performs post-processing on the stored blocks (decryption, decompression, restoration such as differential application, or partial application to the update target program, etc.) to apply the update program corresponding to the block to the in-vehicle ECU for updating. In other words, the update program is applied stepwise in the in-vehicle ECU for updating. Note that the blocks received by the in-vehicle ECU are stored in the memory area until post-processing is completed (ended). For example, after the in-vehicle ECU stores a first block in memory, the in-vehicle device transmits the block next to the first block (second block) to the in-vehicle ECU. While performing post-processing of the first block, the in-vehicle ECU can store the second block in an area different from the area in which the first block is stored and start post-processing of the stored second block. In this way, the in-vehicle device transmits the next sequential block (the (n+1)th block) to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing of a block (the nth block). This allows the in-vehicle device to transmit blocks of the update program at short intervals, thereby reducing the time required to transmit the update program. The in-vehicle device may be connected by wire to a maintenance device, such as a diagnostic tool, that stores the update program, and may receive the update program from the maintenance device.

[0012] (2) In an in-vehicle update system according to one aspect of the present disclosure, the in-vehicle device stops transmitting the block when the free space in the memory of the in-vehicle ECU becomes equal to or less than a first predetermined value.

[0013] In this aspect, from the time the in-vehicle ECU receives a block until the block is applied, the block occupies memory space, reducing the amount of available memory space. When the block is subsequently applied (post-processing is completed normally), the data associated with the block is deleted from the memory, the allocated memory space is released, and the amount of available memory space increases. If the post-processing terminates abnormally, the in-vehicle ECU may retry the post-processing. By configuring the in-vehicle device to stop transmitting blocks when the memory capacity of the in-vehicle ECU falls below a first predetermined value, the in-vehicle device can transmit update program blocks at short intervals until the memory capacity of the in-vehicle ECU becomes low, and can prevent the in-vehicle device from transmitting blocks when there is no memory space for storing the blocks or when memory space is limited.

[0014] (3) In an in-vehicle update system according to one embodiment of the present disclosure, the memory of the in-vehicle ECU includes a plurality of buffers corresponding to each of the blocks received, and the in-vehicle ECU uses the buffers as a work area to perform post-processing on the blocks stored in the buffers, and the in-vehicle device transmits the next block following the block for which post-processing is being performed to the in-vehicle ECU, even while the in-vehicle ECU is performing post-processing on the block stored in the buffer.

[0015] In this embodiment, the memory area of ​​the vehicle-mounted ECU is partitioned into multiple buffers each capable of storing a predetermined amount of data, and each buffer can store one block. The buffer is also used as a work area for post-processing one block, and the amount of data (capacity) that the buffer can store is slightly larger than the data amount of the block (e.g., 1.2 times the data amount of the block). When a predetermined number of blocks (e.g., five) are transmitted as a set from the vehicle-mounted device to the vehicle-mounted ECU, the buffer may have a capacity large enough to store the five blocks. In this case, a group of the five blocks may correspond to one block (processing unit block) as a processing unit corresponding to one buffer. That is, the buffer capacity is equal to or greater than the product of the data amount of the block, the number of blocks per processing unit, and a coefficient for post-processing (work). Even while the vehicle-mounted ECU is performing post-processing on a block stored in the buffer, the vehicle-mounted device can transmit update program blocks at short intervals by transmitting the next block following the block currently being post-processed to the vehicle-mounted ECU.

[0016] (4) In one embodiment of the in-vehicle update system of the present disclosure, the in-vehicle ECU receives the next block while performing post-processing on the block stored in the buffer, and stores the next block in another buffer different from the buffer in which the block being post-processed is stored.

[0017] In this aspect, the memory area of ​​the in-vehicle ECU is divided into multiple buffers each capable of storing a predetermined amount of data, and each buffer can store one block. The in-vehicle ECU receives the next block while performing post-processing on a block stored in a buffer, and stores the next block in a buffer different from the buffer in which the block being post-processed is stored. This allows the in-vehicle ECU to receive blocks transmitted at short intervals from the in-vehicle device, thereby reducing the time required for transmitting an update program from the in-vehicle device to the in-vehicle ECU.

[0018] (5) In an in-vehicle update system according to one embodiment of the present disclosure, the memory of the in-vehicle ECU includes a plurality of buffers corresponding to each of the blocks received, the in-vehicle ECU uses the buffers as a work area to perform post-processing on the blocks stored in the buffers, and after performing post-processing on the blocks stored in the buffers, erases the blocks from the buffers, and the free space in the memory of the in-vehicle ECU corresponds to the number of buffers among the plurality of buffers that do not store the blocks.

[0019] In this aspect, the on-board ECU stores blocks received from an on-board device in a buffer in memory. The on-board ECU uses the buffer as a work area to perform post-processing on the blocks stored in the buffer, and after performing (completing) the post-processing, deletes the post-processed blocks from the buffer. This makes the buffer an empty buffer that does not store any blocks, and when the on-board ECU receives a new block, it becomes possible to store the received block in the empty buffer. In other words, when a block is stored in the buffer, the free memory capacity decreases, and when a block is deleted from the buffer, the free memory capacity increases. Note that deleting a block from the buffer may include changing an attribute, such as a write flag, that allows the data of the block stored in the buffer to be overwritten while remaining in the buffer.

[0020] (6) In an in-vehicle update system according to one embodiment of the present disclosure, the in-vehicle ECU erases the block from the memory after performing post-processing on the block stored in the memory, and the in-vehicle device starts transmitting the block when the free space in the memory of the in-vehicle ECU becomes equal to or greater than a second predetermined value.

[0021] In this embodiment, after restoring a block stored in memory, the in-vehicle ECU deletes the block from memory, thereby freeing up the area occupied by the block. This increases the memory capacity. When the free memory capacity of the in-vehicle ECU becomes equal to or greater than a second predetermined value (increases), the in-vehicle device starts (resumes) transmitting the block to the in-vehicle ECU, thereby shortening the time required to transmit the update program. The second predetermined value is greater than the first predetermined value. Note that the first predetermined value and the second predetermined value may be the same value. In this case, when the free memory capacity of the memory 41 becomes less than the predetermined value, the in-vehicle device 3 stops transmitting the block.

[0022] (7) In an in-vehicle update system according to one embodiment of the present disclosure, the in-vehicle ECU stores the block in the memory, and then transmits a signal to the in-vehicle device requesting transmission of the next block in the sequence before post-processing of the block stored in the memory is completed.

[0023] In this embodiment, after storing a received block in its memory, the in-vehicle ECU transmits a signal to the in-vehicle device in the update program requesting transmission of the block next to the stored block before completing post-processing of the block. This allows the in-vehicle device to transmit blocks to the in-vehicle ECU at short intervals without waiting while the in-vehicle ECU post-processes the previously received block, thereby shortening the time required to transmit the update program. Furthermore, the in-vehicle ECU 4 can perform post-processing on multiple blocks in parallel or in parallel.

[0024] (8) In an in-vehicle update system according to one embodiment of the present disclosure, the in-vehicle ECU transmits a signal to the in-vehicle device requesting that transmission of the block be stopped when the free space in the memory falls below a first predetermined value.

[0025] In this aspect, the on-board ECU monitors the free space in the memory, and when the on-board ECU detects that the free space in the memory has fallen below a first predetermined value, the on-board ECU requests the on-board device to stop transmitting blocks, thereby preventing the on-board device from transmitting blocks when there is no memory space to store the blocks.

[0026] (9) In an in-vehicle update system according to one embodiment of the present disclosure, two connections are established between the in-vehicle device and the in-vehicle ECU, and the block is transmitted from the in-vehicle device to the in-vehicle ECU over one connection, and a signal requesting that the transmission of the block be stopped is transmitted from the in-vehicle ECU to the in-vehicle device over the other connection.

[0027] In this aspect, two connections are established between the on-board device and the on-board ECU, and one connection is used for transmitting a block from the on-board device to the on-board ECU and a signal requesting transmission of another (next) block from the on-board ECU to the on-board device, and the other connection is used for transmitting a signal requesting stop of block transmission from the on-board ECU to the on-board device. As a result, even during transmission of a block or a signal requesting block transmission, if the on-board ECU detects that the free memory capacity has fallen below a first predetermined value, it can transmit a signal to the on-board device requesting stop of block transmission.

[0028] (10) In one embodiment of the in-vehicle update system of the present disclosure, the in-vehicle ECU transmits a signal to the in-vehicle device requesting the start of transmission of the block when the free space in the memory becomes equal to or greater than a second predetermined value.

[0029] In this embodiment, the in-vehicle ECU monitors the free space of the memory (the number of free buffers). When the free space of the memory becomes equal to or greater than a second predetermined value, the in-vehicle ECU requests the in-vehicle device to start (resume) transmission of the blocks, thereby enabling the in-vehicle ECU to receive the update program blocks again. Note that the signal from the in-vehicle ECU to the in-vehicle device requesting the start (resume) of transmission of the blocks is sent, for example, via the other connection.

[0030] (11) In an in-vehicle update system according to an aspect of the present disclosure, the in-vehicle device acquires information about the free space of the memory of the in-vehicle ECU, and stops transmitting the block when the free space of the memory is equal to or less than a first predetermined value.

[0031] In this aspect, the in-vehicle device periodically transmits a signal to the in-vehicle ECU, for example, inquiring about the free space in the memory of the in-vehicle ECU. When the in-vehicle ECU receives the signal inquiring about the free space, it transmits information about the free space in the memory (a numerical value of the free space) to the in-vehicle device. The in-vehicle device determines whether the received (acquired) free space in the memory of the in-vehicle ECU is equal to or less than a first predetermined value, and if it is equal to or less than the first predetermined value, stops transmitting blocks to the in-vehicle ECU. This prevents the in-vehicle device from transmitting blocks when there is no space in the memory of the in-vehicle ECU to store the blocks. Note that the information about the free space in the memory may be information indicating whether the memory can store the blocks (for example, a flag value indicating that the memory is able to store the blocks by 0 and that the memory is under memory load by 1).

[0032] (12) In an in-vehicle update system according to one embodiment of the present disclosure, two connections are established between the in-vehicle device and the in-vehicle ECU, and one connection is used for transmitting the block from the in-vehicle device to the in-vehicle ECU and for transmitting a signal from the in-vehicle ECU to the in-vehicle device requesting transmission of the next block in the sequence, and the other connection is used for transmitting a signal from the in-vehicle device to the in-vehicle ECU inquiring about the available capacity of the memory and for transmitting information regarding the available capacity of the memory from the in-vehicle ECU to the in-vehicle device.

[0033] In this aspect, for example, two connections are established between the on-board device and the on-board ECU. One connection is used for transmitting a block from the on-board device to the on-board ECU and for transmitting a signal from the on-board ECU to the on-board device requesting transmission of another (next) block. The other connection is used for transmitting a signal from the on-board device to the on-board ECU inquiring about available capacity and for transmitting the available capacity from the on-board ECU to the on-board device. This allows the on-board device to inquire about available capacity of the on-board ECU even during transmission of a block or a signal requesting transmission of a block. Furthermore, if the on-board system includes multiple on-board ECUs that can communicate with the on-board device, the on-board device may store predetermined values ​​(first and second predetermined values) of available capacity for each on-board ECU, and may determine whether to stop transmitting the block to the on-board ECU based on the predetermined value corresponding to the on-board ECU.

[0034] (13) In an in-vehicle update system according to an aspect of the present disclosure, the in-vehicle device starts transmitting the block when the free space in the memory is equal to or greater than a second predetermined value.

[0035] In this aspect, even after stopping the transmission of blocks to the in-vehicle ECU, the in-vehicle device periodically transmits a signal to the in-vehicle ECU inquiring about the available memory space of the in-vehicle ECU. When the in-vehicle ECU receives the signal inquiring about the available memory space, it transmits the available memory space to the in-vehicle device. The in-vehicle device determines whether the received (acquired) available memory space of the in-vehicle ECU is equal to or greater than a second predetermined value, and if it is equal to or greater than the second predetermined value, starts (resumes) the transmission of blocks to the in-vehicle ECU. This allows the in-vehicle device to start (resume) the transmission of blocks to the in-vehicle ECU when the available memory space of the in-vehicle ECU becomes (increases) equal to or greater than the second predetermined value, thereby shortening the time required to transmit an update program.

[0036] (14) An in-vehicle device according to one embodiment of the present disclosure is an in-vehicle device that acquires update programs transmitted from an external server outside the vehicle and performs processing to update a program of an in-vehicle ECU mounted on the vehicle, the update programs being transmitted to the in-vehicle ECU sequentially in blocks divided into a predetermined size, and the in-vehicle ECU uses at least a portion of the area of ​​a memory that stores the blocks sequentially received by the in-vehicle ECU as a work area, and even while the in-vehicle ECU is performing post-processing on the block stored in the memory, the in-vehicle ECU transmits the next block that is immediately following the block for which post-processing is being performed.

[0037] In this embodiment, the on-board device transmits the next sequential block to the on-board ECU even while the on-board ECU is performing post-processing on the block, so that blocks of the update program can be transmitted at short intervals, thereby shortening the time required to transmit the update program.

[0038] (15) An in-vehicle ECU according to one embodiment of the present disclosure is an in-vehicle ECU mounted on a vehicle, which receives an update program transmitted from an external server outside the vehicle from an in-vehicle device that has acquired the update program in blocks divided into a predetermined size, and when it receives a block, it stores the received block in a memory and uses at least a portion of the memory as a work area to perform post-processing on the block stored in the memory, and even while it is performing post-processing on the block stored in the memory, it receives the next block from the in-vehicle device that is the next block after the block for which post-processing is being performed.

[0039] In this embodiment, the on-board ECU can receive the next block even while performing post-processing on a block, so the on-board device can send program blocks to the on-board ECU at short intervals, thereby reducing the time required to send an update program.

[0040] (16) An in-vehicle update system according to one embodiment of the present disclosure is an in-vehicle update system including an in-vehicle ECU mounted on a vehicle and an in-vehicle device that acquires an update program transmitted from a program providing device and performs processing to update the program of the in-vehicle ECU, wherein the in-vehicle device transmits the update program to the in-vehicle ECU sequentially in blocks divided into a predetermined size, and when the in-vehicle ECU receives the blocks, it stores the received blocks sequentially in memory, and the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a portion of the memory as a work area, and even while the in-vehicle ECU is performing post-processing on the block stored in the memory, the in-vehicle device transmits the next block to the in-vehicle ECU that is the next in order after the block for which post-processing is being performed.

[0041] In this aspect, an on-board device in an on-board update system acquires an update program for an on-board ECU from a program provider. The program provider includes a terminal device such as an external server, a factory tool, or a diagnostic tool. The program provider transmits blocks into which the update program has been divided to the on-board device. Note that the program provider may transmit the update program before division to the on-board device, and the on-board device may divide the acquired update program into multiple blocks. The on-board device transmits the divided blocks sequentially (e.g., in the order of first block, second block, third block, etc.) to the on-board ECU (Electronic Control Unit). The on-board ECU stores the received blocks of the update program in memory and applies the update program corresponding to the stored blocks to the on-board ECU by post-processing (decrypting, decompressing, restoring by applying differences, or partially applying the blocks to the program to be updated, etc.). In other words, the update program is applied step by step in the on-board ECU to perform the update. Note that the blocks received by the on-board ECU are stored in a memory area until post-processing is completed (ended). For example, after the in-vehicle ECU stores a first block in a memory, the in-vehicle device transmits the block (second block) next to the first block to the in-vehicle ECU. While the in-vehicle ECU is performing post-processing of the first block, the in-vehicle ECU can store the second block in an area different from the area in which the first block is stored and start post-processing of the stored second block. In this way, the in-vehicle device transmits the next sequential block (the (n+1)th block) to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing of a block (the nth block). This allows the in-vehicle device to transmit blocks of the update program at short intervals, thereby reducing the time required to transmit the update program. The in-vehicle device may also receive a diagnostic processing command from a program provider.

[0042] (17) In an in-vehicle update system according to one aspect of the present disclosure, the program providing device is an external server outside the vehicle.

[0043] In this aspect, the in-vehicle device can acquire update programs from the outside via the external vehicle network.

[0044] (18) An in-vehicle update system according to one embodiment of the present disclosure includes a plurality of the in-vehicle ECUs, and when the in-vehicle device stops transmitting the block to any one of the in-vehicle ECUs, it starts transmitting the block of the update program to another in-vehicle ECU that is different from any one of the in-vehicle ECUs, to the other in-vehicle ECU.

[0045] In this aspect, when an in-vehicle ECU has no free memory space and is unable to receive new blocks, the in-vehicle device transmits blocks to another in-vehicle ECU. The blocks transmitted to the other in-vehicle ECU are divided versions of the update programs applied to the other in-vehicle ECUs, and are different from the update programs applied to the in-vehicle ECU for which block transmission has been stopped. That is, when performing processing to update the programs of the in-vehicle ECUs for each of the in-vehicle ECUs, the in-vehicle device may acquire each update program applied to each of the in-vehicle ECUs from a program provider. This allows the in-vehicle device to perform processing on the other in-vehicle ECUs without waiting for free memory space to become available in the in-vehicle ECU. This allows at least a portion of the processing for each of the in-vehicle ECUs to be performed substantially in parallel, thereby shortening the time required to complete processing for the multiple in-vehicle ECUs.

[0046] (19) In one embodiment of the in-vehicle update system of the present disclosure, when the free space in the memory is equal to or less than a first predetermined value, the in-vehicle ECU transmits a signal to the in-vehicle device requesting that transmission of the block be stopped, and when the free space in the memory is equal to or greater than a second predetermined value, the in-vehicle ECU transmits a signal to the in-vehicle device requesting that transmission of the block be started, and when the in-vehicle device receives a signal requesting that transmission of the block be stopped from one of the in-vehicle ECUs, the in-vehicle device starts transmitting the block to another in-vehicle ECU different from one of the in-vehicle ECUs that transmitted a signal requesting that transmission of the block be started.

[0047] In this aspect, the in-vehicle device can determine whether each of the multiple in-vehicle ECUs can receive the block, thereby identifying the in-vehicle ECUs that can receive the block and transmitting the block to the identified in-vehicle ECU, thereby preventing waiting time and shortening the time required to complete processing for the multiple in-vehicle ECUs.

[0048] (20) An in-vehicle update system according to one embodiment of the present disclosure is an in-vehicle update system including an in-vehicle ECU mounted on a vehicle and an in-vehicle device that acquires update programs transmitted from a program providing device and performs processing to update the program of the in-vehicle ECU, and two connections are established between the in-vehicle device and the in-vehicle ECU.

[0049] In this aspect, for example, two connections are established between the in-vehicle device and the in-vehicle ECU. One connection is used for transmitting a block of an update program from the in-vehicle device to the in-vehicle ECU, and for transmitting a signal from the in-vehicle ECU to the in-vehicle device requesting transmission of another (next) block. The other connection is used for transmitting a signal from the in-vehicle device to the in-vehicle ECU inquiring about available space, and for transmitting the available space from the in-vehicle ECU to the in-vehicle device. This allows the in-vehicle device to inquire about available space from the in-vehicle ECU even while transmitting a block or a signal requesting transmission of a block. This reduces the time required for the in-vehicle device to transmit an update program to the in-vehicle ECU.

[0050] [Details of the embodiment of the present invention] The present invention will be specifically described with reference to the drawings showing embodiments thereof. An in-vehicle device 3 according to an embodiment of the present disclosure will be described below with reference to the drawings. Note that the present invention is not limited to these examples, but is defined by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

[0051] (Embodiment 1) Hereinafter, embodiments will be described with reference to the drawings. FIG. 1 is a schematic diagram showing the configuration of an in-vehicle update system S. FIG. 2 is a block diagram showing an example of the physical configuration of an in-vehicle device 3 and an in-vehicle ECU 4 according to the first embodiment. The in-vehicle update system S includes an exterior communication device 1 and an in-vehicle device 3 (update device) mounted on a vehicle C, and transmits update programs acquired from an external server S1 (program providing device, OTA server) connected via an exterior network N to the in-vehicle ECU 4 (Electronic Control Unit) mounted on the vehicle C. The in-vehicle update system S also includes a communication line on the in-vehicle ECU side (in-vehicle communication line 51) connecting the in-vehicle device 3 and the in-vehicle ECU 4 (ECU), and a communication line on the external server side (exterior communication line 52) connecting the in-vehicle device 3 and the exterior communication device 1.

[0052] The external server S1 is a computer such as a server connected to an external network N such as the Internet or a public line network, and includes a storage unit S11 such as a RAM (Random Access Memory), a ROM (Read Only Memory), or a hard disk, and corresponds to an external program providing device. The external server S1 stores in the storage unit S1 programs or data for controlling the in-vehicle ECU 4, which have been created by the manufacturer of the in-vehicle ECU 4, etc. The programs or data are transmitted to the vehicle C as update programs, as will be described later, and are used to update the programs or data of the in-vehicle ECU 4 installed in the vehicle C. The external server S1 (program providing device) configured in this way can be used to provide programs via OTA. It is also called an (Over The Air) server.

[0053] The in-vehicle device 3 functions as an OTA master that transmits update programs acquired from the external server S1 to the in-vehicle ECU 4 to be updated and transmits an activation instruction for applying the transmitted update program to the in-vehicle ECU 4. The in-vehicle ECU 4 installed in the vehicle C acquires the update program transmitted by wireless communication from the external server S1 via the in-vehicle device 3, and applies the update program (activation process) in response to the activation instruction, thereby updating (reprogramming) the program executed by its own ECU. The in-vehicle device 3 may be connected to a maintenance device such as a diagnostic tool via a wired connection. When the in-vehicle device 3 is connected to the diagnostic tool, the in-vehicle device 3 may acquire the update program stored in the diagnostic tool via communication using, for example, the UDS (Unified Diagnostic Service) protocol.

[0054] Hereinafter, the program will be described as including program code including control syntax and the like for the in-vehicle ECU 4 to perform processing, and an external file describing data referenced when the program code is executed. When transmitting an update program, the external file describing the program code and data is transmitted from the external server S1 as, for example, an encrypted archive file. When transmitting the update program, the external server S1 generates a package including the update program and transmits the generated package to the vehicle C. The package includes, for example, package information (campaign information) that is information about the program update, information about the in-vehicle ECU 4 to be updated (target information), and the update program to be applied to the in-vehicle ECU 4 to be updated.

[0055] The vehicle C is equipped with an exterior communication device 1, an in-vehicle device 3, a display device (not shown), and a plurality of in-vehicle ECUs 4 for controlling various in-vehicle devices. The exterior communication device 1 and the in-vehicle device 3 are communicably connected by a harness such as a serial cable. The in-vehicle device 3 and the in-vehicle ECU 4 are communicably connected by an in-vehicle network 5 that supports a communication protocol such as Ethernet (registered trademark) or CAN (Control Area Network).

[0056] The exterior-vehicle communication device 1 includes an exterior-vehicle communication unit (not shown) and an input / output I / F (not shown) (interface) for communicating with the in-vehicle device 3. The exterior-vehicle communication unit is a communication device for wireless communication using a mobile communication protocol such as LTE (registered trademark), 4G, 5G, or WiFi (registered trademark), and transmits and receives data to and from an external server S1 via an antenna 11 connected to the exterior-vehicle communication unit. The communication between the exterior-vehicle communication device 1 and the external server S1 is performed via an exterior-vehicle network N, such as a public line network or the Internet.

[0057] The input / output I / F of the extra-vehicle communication device 1 is a communication interface for, for example, serial communication with the in-vehicle device 3. The extra-vehicle communication device 1 and the in-vehicle device 3 communicate with each other via a harness such as a serial cable connected between the input / output I / Fs. In this embodiment, the extra-vehicle communication device 1 is a device separate from the in-vehicle device 3, and these devices are communicatively connected by the input / output I / F or the like, but this is not limiting. The extra-vehicle communication device 1 may be built into the in-vehicle device 3 as one component of the in-vehicle device 3. Alternatively, the extra-vehicle communication device 1 and the in-vehicle device 3 may be connected by an in-vehicle network 5 such as Ethernet.

[0058] The in-vehicle device 3 is a gateway (in-vehicle relay device) that manages multiple buses (segments), such as the in-vehicle ECU 4 for a control system, the in-vehicle ECU 4 for a safety system, and the in-vehicle ECU 4 for a body system, and relays communications between the in-vehicle ECUs 4 between these buses (segments). That is, the in-vehicle communication lines 51 constituting these multiple buses (segments) are connected to the in-vehicle device 3, and the in-vehicle network 5 is configured by the multiple in-vehicle communication lines 51 (segments) aggregated by the in-vehicle device 3. The in-vehicle device 3 functions as an Ethernet gateway for relaying Ethernet protocols and as a Layer 2 switch or Layer 3 switch for relaying TCP / IP protocols. The in-vehicle device 3 may be a PLB (Power LAN Box) that, in addition to relaying communications, also functions as a power distribution device that distributes and relays power output from a power supply device such as a secondary battery and supplies power to in-vehicle devices such as actuators connected to the in-vehicle device 3. Alternatively, the in-vehicle device 3 may be configured as a functional part of a body ECU that controls the entire vehicle C. Alternatively, the in-vehicle device 3 may be an integrated ECU that is configured with a central control device such as a vehicle computer and performs overall control of the vehicle C.

[0059] The in-vehicle device 3 includes a device control unit 30, a storage unit 31, and an in-vehicle communication unit 32. The in-vehicle device 3 is configured to acquire, from the outside-vehicle communication device 1, an update program (package) that the outside-vehicle communication device 1 has received from the external server S1 via wireless communication, preprocess (divide or compress, etc.) the update program via the in-vehicle network 5, and transmit the update program in blocks of a predetermined size to a predetermined in-vehicle ECU 4 (an in-vehicle ECU 4 to be updated). That is, the in-vehicle device 3 functions as an OTA master (repro master) that controls program updates in the in-vehicle ECU 4 to be updated.

[0060] The device control unit 30 of the in-vehicle device 3 is configured with a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control processes and arithmetic processes by reading and executing a device control program P1 (program product) and data pre-stored in the storage unit 31. The device control unit 30 may be configured to be capable of parallel processing of multiple processes using multiple CPUs (multi-CPUs) or a multi-core CPU.

[0061] The storage unit 31 of the in-vehicle device 3 is configured by a volatile memory element such as a random access memory (RAM) or a non-volatile memory element such as a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The storage unit 31 stores a control program (device control program P1) for the in-vehicle device 3. The storage unit 31 also stores update programs acquired from an external server S1. The device control program P1 (program product) stored in the storage unit 31 may be a device control program P1 (program product) read from a recording medium 311 readable by the in-vehicle device 3. The device control program P1 may also be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 31.

[0062] The in-vehicle communication unit 32 of the in-vehicle device 3 is an input / output interface using a communication protocol such as Ethernet (registered trademark) or CAN, and the device control unit 30 communicates with in-vehicle devices such as the in-vehicle ECU 4 or other relay devices connected to the in-vehicle network 5 via the in-vehicle communication unit 32. A plurality of in-vehicle communication units 32 (four in this embodiment) are provided, and three of the four in-vehicle communication units 32 are connected to in-vehicle inside communication lines 51 (segments) that constitute the in-vehicle network 5. By providing a plurality of in-vehicle communication units in this manner, the in-vehicle network 5 is divided into a plurality of segments, and each in-vehicle ECU 4 is connected to each segment depending on, for example, the function of the in-vehicle ECU 4 (control system function, safety system function, body system function). Of the four in-vehicle communication units 32, the in-vehicle communication unit 32 that is not connected to the in-vehicle inside communication line 51 is connected to the in-vehicle outside communication line 52, and the in-vehicle communication unit communicates with the exterior communication device 1 via the exterior communication line 52. 2 shows an in-vehicle communication unit 32 to which one in-vehicle communication line 51 is connected, and an in-vehicle communication unit 32 to which one out-vehicle communication line 52 is connected.

[0063] The in-vehicle ECU 4 includes an ECU control unit 40, a memory (main storage unit) 41, an auxiliary storage unit 42, and an in-vehicle communication unit 43. The in-vehicle ECU 4 is configured to post-process (decrypt, decompress, restore by applying differences, or partially apply to the program to be updated, etc.) the blocks of the update program received from the in-vehicle device 3, and apply the update program to its own ECU. In other words, the in-vehicle ECU 4 functions as an OTA target (repro target) whose program update is controlled by the in-vehicle device 3.

[0064] The ECU control unit 40 of the vehicle-mounted ECU 4 is a CPU (Central Processing Unit) or an MPU The ECU control unit 40 is configured with an ECU control program P2 (program product) and data stored in advance in the auxiliary storage unit 42, and performs various control processes and arithmetic processes by reading and executing the program. The ECU control unit 40 may be configured to be capable of parallel processing of multiple processes using multiple CPUs (multi-CPUs) or a multi-core CPU.

[0065] The memory 41 of the in-vehicle ECU 4 is configured with, for example, a RAM. The memory 41 stores blocks of update programs that the in-vehicle ECU 4 receives from the in-vehicle device 3. The ECU control unit 40 performs post-processing on the blocks stored in the memory 41, and blocks for which post-processing has been completed are erased (volatilized) from the memory 41. The memory 41 can store different blocks in multiple areas (buffers 411), and the ECU control unit 40 can perform post-processing on the blocks stored in the multiple areas in parallel. The areas or buffers of the memory 41 may be defined by ranges of physical address or logical address values ​​in the memory 41.

[0066] The auxiliary storage unit 42 of the in-vehicle ECU 4 is configured with a non-volatile memory element such as a rewritable read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The auxiliary storage unit 42 stores a control program (ECU control program P2) for the in-vehicle ECU 4. The ECU control program P2 (program product) stored in the auxiliary storage unit 42 is transmitted from the in-vehicle device 3 and stored in the auxiliary storage unit by the ECU control unit 40 performing post-processing. In other words, the ECU control program P2 is a program to be updated.

[0067] The in-vehicle communication unit 43 of the in-vehicle ECU 4 is an input / output interface that uses a communication protocol such as Ethernet (registered trademark) or CAN, and the in-vehicle ECU 4 communicates with the in-vehicle device 3 or other in-vehicle ECUs 4 via the in-vehicle communication unit 43.

[0068] FIG. 3 is an explanatory diagram showing transitions in the usage status of the memory 41. In FIG. 3, the upper side represents the past, and the lower side represents the future. The memory 41 is partitioned into areas of a predetermined capacity, and each partitioned area includes a buffer 411. Each buffer 411 can store one block received by the in-vehicle ECU 4 from the in-vehicle device 3. Hereinafter, a buffer 411 that stores a block will be referred to as an in-use buffer, and a buffer 411 that does not store a block will be referred to as an empty buffer. The buffer 411 is used as a work area for the ECU control unit 40 to post-process the stored blocks. That is, the memory 41 includes multiple buffers 411 with capacities corresponding to the amount of data of the blocks to be received. Note that, because the buffer 411 is used as a work area for post-processing the stored blocks, the capacity of the buffer 411 is slightly larger than the amount of data of the blocks to be received (for example, 1.2 times the amount of data of the blocks). Furthermore, if a received block can be stored in any of the free buffers 411, the capacity of each buffer 411 is set to a capacity corresponding to the block with the largest amount of data among the blocks to be received.

[0069] In the example shown in FIG. 3 , the memory 41 includes four buffers 411 (first buffer 411a to fourth buffer 411d), and the in-vehicle ECU 4 receives blocks of the update program sequentially from the in-vehicle device 3 in the order of the first block, the second block, the third block, and so on. When the in-vehicle ECU 4 receives the first block, the first block is stored in the first buffer 411a. The first buffer 411a becomes an in-use buffer, and post-processing by the ECU control unit 40 is started for the first block stored in the first buffer 411a. The post-processing includes decoding, decompressing, and restoring the data of the block, such as applying differences, or partially applying the data to the program to be updated (ECU control program P2). In other words, by post-processing the block, at least a portion of the ECU control program P2 stored in the auxiliary storage unit 42 is updated. Since the in-vehicle device 3 transmits the next block before (during) the in-vehicle ECU 4 completes post-processing of the block, the in-vehicle ECU 4 receives the second block before completing post-processing of the first block.

[0070] The second block received by the in-vehicle ECU 4 is stored in the second buffer 411b, which is an empty buffer. The ECU control unit 40 starts post-processing of the second block, similar to the first block. Note that the post-processing of the first block and the post-processing of the second block are executed in parallel. Furthermore, the third block received by the in-vehicle ECU 4 is stored in the third buffer 411c, which is an empty buffer. The ECU control unit 40 starts post-processing of the third block, similar to the first and second blocks.

[0071] If the post-processing of the first block is not completed when the memory 41 stores the third block in the third buffer 411c, the number of free buffers in the memory 41 will be one. At this time, for example, the ECU control unit 40 of the in-vehicle ECU 4 detects that the free memory capacity is equal to or less than a first predetermined value (equal to or less than the capacity of one buffer 411), and transmits a signal (stop signal) to the in-vehicle device 3 requesting that transmission of the block be stopped (see FIGS. 4 to 6). When the in-vehicle device 3 receives the stop signal, it does not transmit the block to the in-vehicle ECU 4 until it receives a signal (start signal) from the in-vehicle ECU 4 requesting that transmission of the block be started.

[0072] When the post-processing of a first block being post-processed in the first buffer 411a is completed, the first buffer 411a is erased (released) from the first buffer 411a. Note that erasing a block from the buffer 411 includes, for example, changing an attribute such as a write flag that allows the data of the block stored in the buffer 411 to be overwritten. When the first block is erased, the first buffer 411a becomes a free buffer. Similarly, when the post-processing of a second block being post-processed in the second buffer 411b is completed, the second buffer 411b is erased (released) from the second buffer 411b. When the second block is erased, the second buffer 411b becomes a free buffer. If the post-processing of two blocks is completed after the in-vehicle device 3 stops transmitting blocks, and two free buffers are added, the number of free buffers in the memory 41 becomes three. At this time, for example, the ECU control unit 40 of the in-vehicle ECU 4 detects that the free memory capacity has fallen below a second predetermined value (a capacity equivalent to or greater than 3 buffers 4113), and transmits a signal (start signal) to the in-vehicle device 3 to start (restart) the suspension of block transmission (see FIGS. 4 to 6).

[0073] When the in-vehicle device 3 receives a start signal from the in-vehicle ECU 4, it resumes transmitting blocks and transmits the fourth block to the in-vehicle ECU 4. The in-vehicle ECU 4 stores the received fourth block in the fourth buffer 411d, and the ECU control unit 40 starts post-processing of the fourth block, causing the fourth buffer 411d to become an in-use buffer. Subsequently, the ECU control unit 40 of the in-vehicle ECU 4 stores the blocks sequentially received by the in-vehicle ECU 4 in each buffer 411 of the memory 41 and performs post-processing of the stored blocks. Note that the blocks received by the in-vehicle ECU 4 are stored in, for example, the buffer 411 that has been empty for the longest time. That is, the fifth block is stored in, for example, the first buffer 411a. After completing post-processing of the blocks, the ECU control unit 40 erases the blocks from the buffers 411 and makes the in-use buffers empty. The in-vehicle device 3 stops transmitting blocks when the free space in the memory 41 of the in-vehicle ECU 4 becomes equal to or less than a first predetermined value (when the number of free buffers becomes equal to or less than a first predetermined number), and starts transmitting blocks when the free space in the memory 41 becomes equal to or more than a second predetermined value (when the number of free buffers becomes equal to or more than a second predetermined number).

[0074] 3, blocks sequentially received by the in-vehicle ECU 4 are stored in the order starting from the first buffer 411a, but this is not limiting. In the example shown in FIG. 3, the nth block is stored in the buffer 411 whose number is the remainder when n is divided by 4 (the number of buffers 411 included in the memory 41), but the block received by the in-vehicle ECU 4 may be stored in any buffer 411 as long as it is an empty buffer. Furthermore, the number of buffers 411 included in the memory 41 is not limited to four. Furthermore, the first predetermined value and the second predetermined value are not limited to the values ​​described above. If the memory 41 also includes areas (other areas) other than the area of ​​the buffer 411 (the area where the blocks are stored), for example, the first predetermined value is the capacity of the other areas and 1 buffer 411, and the second predetermined value is the capacity of the other areas and 3 buffers 411.

[0075] 4 to 6 are explanatory diagrams illustrating an example of a processing flow (sequence) performed by the in-vehicle device 3 and the in-vehicle ECU 4 to be updated according to the first embodiment. The in-vehicle device 3 and the in-vehicle ECU 4 have established two communication connections, allowing two types of communication processing to be performed in parallel or in parallel. The in-vehicle device 3 and the in-vehicle ECU 4 to be updated are connected by, for example, using different port numbers as destinations in communication using the TCP / IP protocol. When the in-vehicle device 3 and the in-vehicle ECU 4 perform CAN communication, two connections may be established by using different CAN IDs as destinations. In this embodiment, the in-vehicle device 3 and the in-vehicle ECU 4 perform two types of processing: a transmission control process and a program update process. In the example shown in FIGS. 4 to 6, an update program is divided into five blocks. The program update process stops when the number of free buffers becomes one or less, and starts (resumes) when the number of free buffers becomes three or more. In FIGS. 4 to 6, the number of free buffers at each processing stage is displayed on the right side.

[0076] The device control unit 30 of the in-vehicle device 3 receives an update program for the in-vehicle ECU 4 from the external server S1 (S101). The device control unit 30 generates a first block by preprocessing the received update program (S102). The device control unit 30 transmits the first block to the in-vehicle ECU 4 (S103).

[0077] The ECU control unit 40 of the in-vehicle ECU 4 stores the first block received from the in-vehicle device 3 in the first buffer 411a of the memory 41 (S104). The ECU control unit 40 transmits a signal (next order request signal) to the in-vehicle device 3 requesting transmission of the next block that follows the block stored in S104 (S105). The ECU control unit 40 starts post-processing of the first block (S106).

[0078] When the device control unit 30 of the in-vehicle device 3 receives the next-order request signal from the in-vehicle ECU 4, the device control unit 30 generates a block (second block) next to the previously transmitted block through preprocessing (S107). The device control unit 30 transmits the second block to the in-vehicle ECU 4 (S108).

[0079] The ECU control unit 40 of the in-vehicle ECU 4 stores the second block received from the in-vehicle device 3 in the second buffer 411b of the memory 41 (S109). The ECU control unit 40 transmits a signal (next-order request signal) to the in-vehicle device 3 requesting transmission of the next block that follows the block stored in S109 (S110). The ECU control unit 40 starts post-processing of the second block (S111).

[0080] When the device control unit 30 of the in-vehicle device 3 receives the next-order request signal from the in-vehicle ECU 4, the device control unit 30 generates a block (third block) next to the previously transmitted block through preprocessing (S112). The device control unit 30 transmits the third block to the in-vehicle ECU 4 (S113).

[0081] The ECU control unit 40 of the in-vehicle ECU 4 stores the third block received from the in-vehicle device 3 in the third buffer 411c of the memory 41 (S114). The ECU control unit 40 transmits a signal (next-order request signal) to the in-vehicle device 3 requesting transmission of the next block that is the next in order to the block stored in S114 (S115). The ECU control unit 40 starts post-processing of the third block (S116). When the device control unit 30 of the in-vehicle device 3 receives the next-order request signal from the in-vehicle ECU 4, it generates a block (fourth block) that is the next block to the previously transmitted block by pre-processing (S117).

[0082] In this example, when the third block is stored in the third buffer 411c, the first to third buffers 411c become in-use buffers, and the ECU control unit 40 of the in-vehicle ECU 4 detects in the transmission control process that the free memory capacity has fallen below a first predetermined value (below the capacity of one buffer 411) (insufficient free memory capacity in the memory 41) (S201), and transmits a signal (stop signal) requesting the stop of block transmission to the in-vehicle device 3 (S202). When the device control unit 30 of the in-vehicle device 3 receives the stop signal from the in-vehicle ECU 4 in the transmission control process, it stops transmission of the fourth block to the in-vehicle ECU 4 after completing generation of the fourth block (pre-processing of the fourth block) in the program update process (S203).

[0083] The post-processing of the first block that has been executed in the first buffer 411a is completed after the post-processing of the third block, for example, starts (S118). When the post-processing of the first block is completed, the first block is deleted from the first buffer 411a, and the first buffer 411a becomes a free buffer.

[0084] The post-processing of the second block that has been executed in the second buffer 411b is completed after the post-processing of the third block has started (S119). When the post-processing of the second block is completed, the second block is deleted from the second buffer 411b, and the second buffer 411b becomes a free buffer.

[0085] When blocks are deleted (released) from the first buffer 411a and the second buffer 411b and the first buffer 411a and the second buffer 411b become free buffers, the ECU control unit 40 of the in-vehicle ECU 4 detects in the transmission control process that the free memory capacity has reached or exceeded a second predetermined value (the capacity of 3 buffers 4113 or more) (free capacity is full) (S204), and transmits a signal (start signal) to the in-vehicle device 3 requesting the start (resumption) of transmission of the blocks (S205).

[0086] When the device control unit 30 of the in-vehicle device 3 receives the start signal from the in-vehicle ECU 4, the device control unit 30 starts (resumes) transmission of blocks to the in-vehicle ECU 4 in the transmission control process (S206).

[0087] When the transmission control process is started (restarted), the device control unit 30 of the in-vehicle device 3 transmits the fourth block to the in-vehicle ECU 4 (S120). The ECU control unit 40 of the in-vehicle ECU 4 stores the fourth block received from the in-vehicle device 3 in the fourth buffer 411d of the memory 41 (S121). The ECU control unit 40 transmits a signal (next order request signal) to the in-vehicle device 3 requesting transmission of the next block that is the next in order after the block stored in S121 (S122). The ECU control unit 40 starts post-processing of the fourth block (S123).

[0088] The post-processing of the third block that has been executed in the third buffer 411c is completed after the post-processing of the fifth block, for example, starts (S124). When the post-processing of the third block is completed, the third block is deleted from the third buffer 411c, and the third buffer 411c becomes a free buffer.

[0089] When the device control unit 30 of the in-vehicle device 3 receives the next-order request signal from the in-vehicle ECU 4, the device control unit 30 generates a block (fifth block) next to the previously transmitted block through preprocessing (S125). The device control unit 30 transmits the fifth block to the in-vehicle ECU 4 (S126) and ends the process.

[0090] The ECU control unit 40 of the in-vehicle ECU 4 stores the fifth block received from the in-vehicle device 3 in the first buffer 411a of the memory 41 (S127). The ECU control unit 40 transmits a signal (next-order request signal) to the in-vehicle device 3 requesting transmission of the next block that is the next in order after the block stored in S127 (S128). The ECU control unit 40 starts post-processing of the fifth block (S129). Note that the device control unit 30 of the in-vehicle device 3 may transmit the last block (the fifth block in this example) included in the update program to the in-vehicle ECU 4, for example, including a flag indicating that the block is the last block. In this case, the ECU control unit 40 of the in-vehicle ECU 4 that received the block including the flag does not need to transmit the next-order request signal to the in-vehicle device 3.

[0091] The post-processing of the fourth block that has been executed in the fourth buffer 411d is completed after the post-processing of the fifth block has started (S130). When the post-processing of the fourth block is completed, the fourth block is deleted from the fourth buffer 411d, and the fourth buffer 411d becomes a free buffer.

[0092] The post-processing of the fifth block that has been executed in the first buffer 411a is completed, for example, after the post-processing of the fourth block is completed (S131). When the post-processing of the fifth block is completed, the fifth block is deleted from the first buffer 411a, and the first buffer 411a becomes a free buffer.

[0093] 7 is a flowchart illustrating a program update process of the in-vehicle device 3 and the in-vehicle ECU 4 to be updated according to the first embodiment. The device control unit 30 of the in-vehicle device 3 receives an update program for the in-vehicle ECU 4 from the external server S1 (S31). The received update program is preprocessed to generate a block (S32). The device control unit 30 transmits the generated block to the in-vehicle ECU 4 (S33). Note that the first block of the update program Before the first block is transmitted, the free space in the memory 41 of the in-vehicle ECU 4 is greater than the first predetermined value. Therefore, the device control unit 30 of the in-vehicle device 3 transmits the first block to the in-vehicle ECU 4 without checking the free space in the memory 41.

[0094] The ECU control unit 40 of the in-vehicle ECU 4 receives the block from the in-vehicle device 3 (S34) and stores the received block in the buffer 411 of the memory 41 (S35). The ECU control unit 40 transmits a next-order request signal to the in-vehicle device 3 (S36). The ECU control unit 40 starts a post-processing subroutine (generates a subprocess) for the block stored in S35 (S37). Note that even if the post-processing subroutine (see FIG. 8) for a block has not been completed, when the ECU control unit 40 receives the next block from the in-vehicle device 3, it can execute the loop of S34 to S37 for the next block. In other words, the ECU control unit 40 can execute post-processing for multiple blocks in parallel.

[0095] The device control unit 30 of the in-vehicle device 3 receives a next-order request signal from the in-vehicle ECU 4 (S38). The in-vehicle ECU 4 determines whether all blocks of the update program have been transmitted (S39). If all blocks have not been transmitted (S39: NO), the process returns to S32, and the process continues for the next block in the next order. In this case, when the device control unit 30 of the in-vehicle device 3 returns the process, the process of the ECU control unit 40 of the in-vehicle ECU 4 also returns to S34. If all blocks have been transmitted (S39: YES), the device control unit 30 of the in-vehicle device 3 ends the process.

[0096] 8 is a flowchart illustrating a subroutine for post-processing a block of the in-vehicle ECU 4 to be updated. The ECU control unit 40 of the in-vehicle ECU 4 decodes the block stored in the buffer 411 of the memory 41 (S371) and decompresses the decoded block (S372). The ECU control unit 40 applies the decompressed block to the ECU control program P2 (the program to be updated) stored in the auxiliary storage unit 42 (S373). The ECU control unit 40 deletes the block from the buffer 411 of the memory 41 (memory 41) (S374) and ends the subroutine. When the block is deleted from the buffer 411 of the memory 41, the buffer 411 becomes a free buffer. The ECU control unit 40 of the in-vehicle ECU 4 may measure the free space (number of free buffers) of the memory 41 based on the number of subroutines (subprocesses) currently being executed.

[0097] 9 is a flowchart illustrating a transmission control process of the in-vehicle device 3 according to the first embodiment and the in-vehicle ECU 4 to be updated. The ECU control unit 40 of the in-vehicle ECU 4 measures the free space in the memory 41 (S41). The ECU control unit 40 determines whether the free space measured in S41 is equal to or less than a first predetermined value (S42). If the free space is not equal to or less than the first predetermined value, If the free space is equal to or less than the first predetermined value (S42: YES), the ECU control unit 40 transmits a stop signal to the in-vehicle device 3 (S43).

[0098] The device control unit 30 of the in-vehicle device 3 receives a stop signal from the in-vehicle ECU 4 (S44). The device control unit 30 stops transmitting the block to the in-vehicle ECU 4 (S45). That is, the device control unit 30 does not execute the process of transmitting the block to the in-vehicle ECU 4 (S33) in the program update process (see FIG. 7), and stops the program update process at a stage before executing S33.

[0099] The ECU control unit 40 of the in-vehicle ECU 4 measures the free space (number of free buffers) in the memory 41 (S46). The ECU control unit 40 determines whether the free space measured in S46 is equal to or greater than a second predetermined value (S47). If the free space is not equal to or greater than the second predetermined value (less than the second predetermined value) (S47: NO), the ECU control unit 40 returns the process to S46. If the free space is equal to or greater than the first predetermined value (S47: YES), the ECU control unit 40 transmits a start signal to the in-vehicle device 3 (S48), and returns the process to S41.

[0100] The device control unit 30 of the in-vehicle device 3 receives a start signal from the in-vehicle ECU 4 (S49). The device control unit 30 starts (resumes) transmission of the block to the in-vehicle ECU 4 (S50). That is, the device control unit 30 executes the process of transmitting the block to the in-vehicle ECU 4 (S33), which was not executed in the program update process (see FIG. 7), and resumes the program update process. Note that the device control unit 30 of the in-vehicle device 3 returns the process to S44 when the ECU control unit 40 of the in-vehicle ECU 4 returns the process to S41.

[0101] According to the above configuration and processing, the in-vehicle device 3 can transmit the next block to the in-vehicle ECU 4 even when the in-vehicle ECU 4 is post-processing the update program, can stop transmitting blocks when the free space in the memory 41 of the in-vehicle ECU 4 decreases, and can resume transmitting blocks when the free space increases, so that blocks of the update program can be transmitted at short intervals, thereby shortening the time required to transmit the update program. Note that the memory 41 of the in-vehicle ECU 4 is partitioned into buffers 411, and blocks are stored in each buffer 411, but the area in the memory 41 where the blocks are stored may be variable.

[0102] (Embodiment 2) The in-vehicle device 3 according to the second embodiment transmits, at predetermined time intervals, to the in-vehicle ECU 4, a signal (inquiry signal) inquiring about the free space (number of free buffers) in the memory 41 of the in-vehicle ECU 4, and upon receiving the inquiry signal, the in-vehicle ECU 4 transmits information about the free space in the memory 41 to the in-vehicle device 3. The in-vehicle device 3 performs transmission control processing based on the received information about the free space in the memory 41.

[0103] 10 is an explanatory diagram showing an example of the ECU table T. The ECU table T is stored in the storage unit 31 (see FIG. 2) of the in-vehicle device 3. The ECU table records a first predetermined value for determining whether to stop transmitting a block to the memory 41 of the in-vehicle ECU 4 that is communicatively connected to the in-vehicle device 3 via the in-vehicle communication line 51, and a second predetermined value for determining whether to start transmitting a block. The management items (fields) of the ECU table include an identification number field, a buffer count field, a first predetermined value field, a second predetermined value field, a free space field, a transmission status field, and a transmitted block count field.

[0104] The identification number field of the ECU table T stores the identification number of each in-vehicle ECU 4. The identification number of the in-vehicle ECU 4 may be indicated by an IP address, a MAC address, or the like. The buffer count field stores the number of buffers 411 included in the memory 41 (the maximum number of free buffers). The first predetermined value field stores a first predetermined value of the free space of the memory 41 at which the device control unit 30 of the in-vehicle device 3 stops transmitting blocks to the in-vehicle ECU 4 that is the target of program update. The second predetermined value field stores a second predetermined value of the free space of the memory 41 at which the device control unit 30 of the in-vehicle device 3 starts transmitting blocks to the in-vehicle ECU 4 that is the target of program update. The free space field stores information about the free space of the memory 41 of the in-vehicle ECU 4 (the number of free buffers), which the in-vehicle device 3 receives from the in-vehicle ECU 4. The value stored in the free space field is updated every time the in-vehicle device 3 receives information about the free space from the in-vehicle ECU 4. In the example shown in FIG. 8 , the first predetermined value, the second predetermined value, and the free space are represented by the number of free buffers, but are not limited to this. The first predetermined value, the second predetermined value, and the free space may be represented by the amount of data that the memory 41 can store, for example, in MB. The transmission status field stores whether the in-vehicle device 3 is currently stopping or currently transmitting blocks to the in-vehicle ECU 4. The transmission status field stores “Stopped” if the in-vehicle device 3 has stopped transmitting blocks but has not resumed them. The transmission status field stores “Current” if the in-vehicle device 3 has not yet stopped transmitting blocks before the first time the in-vehicle device 3 stopped transmitting blocks, or has resumed transmitting blocks after stopping them but has not yet stopped them again. The value stored in the transmission status field is updated when the device control unit 30 of the in-vehicle device 3 stops or starts (restarts) transmitting blocks. The transmitted block count field stores the number of blocks that the in-vehicle device 3 has already transmitted to the in-vehicle ECU 4. The denominator of the transmitted block count field indicates the total number of blocks included in the update program to be transmitted to the in-vehicle ECU 4, and the numerator indicates the number of blocks that have been transmitted to the in-vehicle ECU 4. The value of the transmitted block count field is updated every time the device control unit 30 transmits a block.

[0105] 11 to 14 are explanatory diagrams illustrating a processing flow (sequence) by the in-vehicle device 3 and the in-vehicle ECU 4 to be updated according to the second embodiment. In the example shown in FIG. 9, the update program is divided into five blocks, and the program update process is stopped when the number of free buffers becomes one or less, and is started (restarted) when the number of free buffers becomes three or more. In the program update process by the device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4, the same processing as in the first embodiment (the processing related to S101 to S131 shown in FIGS. 4 to 6) is performed. In the transmission control processing, the device control unit 30 of the in-vehicle device 3 reads out the first predetermined value and the second predetermined value of the in-vehicle ECU 4 to be updated from the ECU table T (S601). The device control section 30 transmits to the in-vehicle ECU 4 a signal (inquiry signal) inquiring about the free space (number of free buffers) in the memory 41 of the in-vehicle ECU 4 (S602).

[0106] The ECU control unit 40 of the in-vehicle ECU 4 that has received the inquiry signal from the in-vehicle device 3 measures the free space (the number of free buffers) in the memory 41 (S603). The ECU control unit 40 transmits information relating to the measured free space (the number of free buffers) to the in-vehicle device 3 (S604).

[0107] The device control unit 30 of the in-vehicle device 3, which has received information regarding the free space from the in-vehicle ECU 4, determines whether the free space in the memory 41 is equal to or less than a first predetermined value (equivalent to one buffer 411) (S605). Since the free space in the memory 41 is greater than the first predetermined value in S605, the device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 again after a predetermined time has elapsed (S606). Thereafter, the device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 at predetermined time intervals (periodically at predetermined time intervals). The predetermined time interval is, for example, twice the length of the time (preprocessing time) estimated to be required for the device control unit to preprocess the update program and generate blocks. If the preprocessing time differs depending on the block, the predetermined time interval may be the average or minimum value of the preprocessing time.

[0108] The device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 repeat the same processes as those of S602 to S605 (S606 to S609 and S610 to S613). Note that in S612, the ECU control unit 40 of the in-vehicle ECU 4 transmits information that the number of free buffers is one to the in-vehicle device 3, so in S613 the device control unit 30 of the in-vehicle device 3 determines that the free space in the memory 41 is equal to or less than a first predetermined value (equivalent to one buffer 4111). When the device control unit 30 determines that the free space in the memory 41 is equal to or less than the first predetermined value (equivalent to one buffer 4111), it stops transmitting blocks in the program update process (S614).

[0109] The device control unit 30 of the in-vehicle device 3 periodically transmits an inquiry signal to the in-vehicle ECU 4 even after the transmission of blocks has stopped. Steps S615 to S617 are the same as steps S602 to S604. The device control unit 30 of the in-vehicle device 3 determines whether the free space in the memory 41 is equal to or greater than a second predetermined value (equivalent to 3 buffers 4113) (S618). In step S618, the free space in the memory 41 is less than the second predetermined value, so the device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 again after a predetermined time has elapsed (S619).

[0110] The device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 repeat the same processes as those of S615 to S618 (S619 to S622). Note that in S621, the ECU control unit 40 of the in-vehicle ECU 4 transmits information that the number of free buffers is three to the in-vehicle device 3, so in S622 the device control unit 30 of the in-vehicle device 3 determines that the free space in the memory 41 is equal to or greater than a second predetermined value (equivalent to 3 buffers 4113). When the device control unit 30 determines that the free space in the memory 41 is equal to or greater than the second predetermined value (equivalent to 3 buffers 4113), it starts (resumes) transmitting blocks in the program update process (S623).

[0111] The device control unit 30 of the in-vehicle device 3 executes the same processes as those in S602 to S605. (S624 to S627 and S628 to S631). Thereafter, when the device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 determine that the available space in the memory 41 is equal to or less than a first predetermined value in a process similar to that of S605, they stop transmitting blocks in the program update process and repeat processes similar to that of S615 to S618. Furthermore, when the device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 determine that the available space in the memory 41 is equal to or greater than a second predetermined value in a process similar to that of S618, they start (resume) transmitting blocks in the program update process and repeat processes similar to that of S602 to S605. The device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 repeat the above processes until the program update process is completed.

[0112] 15 is a flowchart illustrating a transmission control process of the in-vehicle device 3 and the in-vehicle ECU 4 to be updated according to the second embodiment. The device control unit 30 of the in-vehicle device 3 reads out the first predetermined value and the second predetermined value of the in-vehicle ECU 4 to be updated from the ECU table T (S71). The device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 (S72).

[0113] The ECU control unit 40 of the in-vehicle ECU 4 receives an inquiry signal from the in-vehicle device 3 (S73). The ECU control unit 40 measures the free space (number of free buffers) in the memory 41 (S74). The ECU control unit 40 transmits information relating to the measured free space (number of free buffers) to the in-vehicle device 3 (S75).

[0114] The device control unit 30 of the in-vehicle device 3 receives information about the free space from the in-vehicle ECU 4 (S76). The device control unit 30 determines whether the free space in the memory 41 is equal to or less than a first predetermined value (whether the number of free buffers is equal to or less than a first predetermined number) (S77). If the free space in the memory 41 is not equal to or less than the first predetermined value (if the free space in the memory 41 is greater than the first predetermined value) (S77: NO), the device control unit 30 returns the process to S72. The device control unit 30 transmits an inquiry signal again after a predetermined time has elapsed since the previous transmission of the inquiry signal. If the free space in the memory 41 is equal to or less than the first predetermined value (S77: YES), the device control unit 30 stops transmitting the block to the in-vehicle ECU 4 (S78). That is, the device control unit 30 stops the process of transmitting the block to the in-vehicle ECU 4 in the program update process (see FIG. 7). The program update process is stopped before S33 is executed without executing S33. The device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 (S79). The device control unit 30 transmits the inquiry signal again after a predetermined time has elapsed since the previous transmission of the inquiry signal.

[0115] The ECU control unit 40 of the in-vehicle ECU 4 receives an inquiry signal from the in-vehicle device 3 (S80). The ECU control unit 40 measures the free space (number of free buffers) in the memory 41 (S81). The ECU control unit 40 transmits information about the measured free space (number of free buffers) to the in-vehicle device 3 (S82).

[0116] The device control unit 30 of the in-vehicle device 3 receives information about the free space from the in-vehicle ECU 4 (S83). The device control unit 30 determines whether the free space in the memory 41 is equal to or greater than a second predetermined value (whether the number of free buffers is equal to or greater than a second predetermined number) (S84). If the free space in the memory 41 is not equal to or greater than the second predetermined value (if the free space in the memory 41 is less than the second predetermined value) (S84: NO), the device control unit 30 returns the process to S79. The device control unit 30 transmits an inquiry signal again after a predetermined time has elapsed since the previous transmission of the inquiry signal. If the free space in the memory 41 is equal to or less than the first predetermined value (S84: YES), the device control unit 30 starts (resumes) transmission of blocks to the in-vehicle ECU 4 (S85). That is, the device control unit 30 executes a process (S33) of transmitting blocks that were not executed in the program update process (see FIG. 7) to the in-vehicle ECU 4, and resumes the program update process. The device control unit 30 returns the process to S72. Note that, when the device control unit 30 of the in-vehicle device 3 returns the process to S72, the ECU control unit 40 of the in-vehicle ECU 4 returns the process to S73.

[0117] According to the above configuration and processing, the in-vehicle device 3 periodically acquires the free space in the memory 41 of the in-vehicle ECU 4, stops transmitting blocks when the free space in the memory 41 of the in-vehicle ECU 4 decreases, and resumes transmitting blocks when the free space increases. Therefore, even when the in-vehicle ECU 4 is post-processing an update program, the next block can be transmitted to the in-vehicle ECU 4, and blocks of the update program can be transmitted at short intervals, thereby shortening the time required to transmit the update program.

[0118] (Embodiment 3) The in-vehicle device 3 according to the third embodiment transmits the update program acquired from the terminal device to each in-vehicle ECU 4.

[0119] 16 is a schematic diagram showing the configuration of an in-vehicle update system S according to embodiment 3. An in-vehicle device 3 according to embodiment 3 is connected to a terminal device S2 and acquires update programs from the terminal device S2.

[0120] The terminal device S2 is a computer, such as a factory tool or a diagnostic tool, connected to the in-vehicle device 3 by a wire. The terminal device S2 includes a storage unit S21 such as a random access memory (RAM), a read-only memory (ROM), or a hard disk, and corresponds to an in-vehicle or external program providing device. The terminal device S2 stores in the storage unit S21 programs or data for controlling the in-vehicle ECU 4, which are created by the manufacturer of the in-vehicle ECU 4 or the like. The programs or data are transmitted to the in-vehicle device 3 as update programs and are used to update the programs or data of the in-vehicle ECU 4 installed in the vehicle C. The terminal device S2 may communicate with the in-vehicle device 3 via the external network N, the antenna 11, and the external communication device 1. The in-vehicle device 3 may also acquire diagnostic processing commands from the terminal device S2.

[0121] 17 is a schematic diagram illustrating an outline of a processing flow (sequence) by the terminal device S2, the in-vehicle device 3, and the in-vehicle ECU 4 to be updated according to the third embodiment. As shown in Fig. 17, the in-vehicle device 3 establishes two connections with each of the terminal device S2 and the in-vehicle ECU 4. In this embodiment, the terminal device S2, the in-vehicle device 3, and the in-vehicle ECU 4 execute two types of processing: a transmission control processing and a program update processing.

[0122] In the program update process, the terminal device S2 transmits blocks into which the update program has been divided to the in-vehicle device 3. The device control unit 30 of the in-vehicle device 3 sequentially transmits the blocks received from the terminal device S2 to the in-vehicle ECU 4. The terminal device S2 transmits the blocks based on the next-sequence request signal (see FIG. 4) transmitted from the in-vehicle ECU 4 in the program update process. The ECU control unit 40 of the in-vehicle ECU 4 performs post-processing while storing the received blocks in a buffer, and transmits a stop signal to the in-vehicle device 3 in the transmission control process when the free memory capacity falls below a first predetermined value. Upon receiving the stop signal, the device control unit 30 of the in-vehicle device 3 transmits a transmission stop request (stop signal) to the terminal device S2. When the transmission stop request is received, the terminal device S2 stops transmitting the blocks.

[0123] The ECU control unit 40 of the in-vehicle ECU 4 proceeds with post-processing of the received block, and when the free memory capacity becomes equal to or greater than a second predetermined value, transmits a start signal to the in-vehicle device 3. Upon receiving the start signal, the device control unit 30 of the in-vehicle device 3 transmits a data request (start signal) to the terminal device S2. Upon receiving the data request, the terminal device S2 starts transmitting the block again. Thereafter, the terminal device S2, the in-vehicle device 3, and the in-vehicle ECU 4 repeat the same processing. As described above, two connections are established between the terminal device S2 and the in-vehicle device 3. This makes it possible for the in-vehicle device to transmit a transmission stop request or a data request to the terminal device S2 even while the terminal device S2 is transmitting a block to the in-vehicle device 3. This reduces the time required for the terminal device S2 to transmit an update program to the in-vehicle device 3.

[0124] In this embodiment, the device control unit 30 of the in-vehicle device 3 transmits the next-order request signal, stop signal, and start signal received from the in-vehicle ECU 4 to the terminal device S2 as described above. Furthermore, the terminal device S2 generates a block in response to the next-order request signal and transmits it to the in-vehicle device 3. The device control unit 30 of the in-vehicle device 3 transmits the received block to the in-vehicle ECU 4. That is, the terminal device S2 has the same functions as the in-vehicle device 3 described in the first embodiment, and the in-vehicle device 3 in this embodiment functions as a relay device that transmits programs, data, signals, etc. received from the terminal device S2 to the in-vehicle ECU 4 without processing them. When the transmission control process is performed using a protocol using UDS (Unified Diagnostic Service), the ECU control unit 40 of the in-vehicle ECU 4 can transmit a stop signal or a start signal to the in-vehicle device 3 by responding to an inquiry signal using a Response on Event function transmitted from the in-vehicle device 3 at a predetermined interval. Furthermore, the device control unit 30 of the in-vehicle device 3 may receive an undivided update program from the terminal device S2 and generate blocks by preprocessing the update program.

[0125] According to the above configuration and processing, the in-vehicle device 3 can transmit the next block to the in-vehicle ECU 4 even when the in-vehicle ECU 4 is post-processing the update program received from the terminal device S2, and can stop transmitting blocks when the free space in the memory 41 of the in-vehicle ECU 4 decreases and resume transmitting blocks when the free space increases. This makes it possible to transmit blocks of the update program at short intervals and shorten the time required to transmit the update program.

[0126] (Embodiment 4) The in-vehicle device 3 of embodiment 4 receives a stop signal from an in-vehicle ECU 4, stops transmitting blocks to the in-vehicle ECU 4 that sent the stop signal (any of the in-vehicle ECUs 4), and then starts transmitting blocks to another in-vehicle ECU 4 that is different from the one of the in-vehicle ECUs 4.

[0127] 18 is a block diagram illustrating the physical configuration of an on-board device 3 and an on-board ECU 4 according to the fourth embodiment. The configuration of the on-board ECU 4 according to this embodiment is the same as the configuration of the on-board ECU 4 according to the other embodiments (see FIG. 2). The configuration of the on-board update system S is substantially the same as that of the first embodiment (see FIG. 1), but in this embodiment, the multiple on-board ECUs 4 included in the on-board update system S will be described separately. The on-board update system S includes on-board ECUs 4(1) to (n) (n is an integer of 2 or more).

[0128] The in-vehicle ECUs 4(1) to (n) are each connected to an in-vehicle communication unit 32 of the in-vehicle device 3 via an in-vehicle communication line 51. Two connections are established between the in-vehicle communication unit 32 and each in-vehicle ECU 4 via the in-vehicle communication line 51. The processing and communication between each in-vehicle ECU 4 and the in-vehicle device 3 are the same as those in the first embodiment (see FIGS. 3 to 9).

[0129] 19 is a schematic diagram illustrating an outline of a processing flow (sequence) performed by an in-vehicle device 3 and a plurality of in-vehicle ECUs 4 to be updated according to the third embodiment. As shown in FIG. 19, two connections are established between the in-vehicle device 3 and each of the in-vehicle ECUs 4. The in-vehicle device 3 and the in-vehicle ECUs 4 execute two types of processing: a transmission control processing and a program update processing.

[0130] Each in-vehicle ECU 4, if not performing post-processing of the block, transmits a start signal to the in-vehicle device 3. The device control unit 30 of the in-vehicle device 3 determines one of the in-vehicle ECUs 4 that transmitted the start signal (in-vehicle ECU 4(1) in the example shown in FIG. 19) as the in-vehicle ECU 4 that will transmit the block, and starts transmitting the block. The device control unit 30 transmits the block based on the next-order request signal (see FIG. 4) transmitted from the in-vehicle ECU 4(1) during the program update process.

[0131] The ECU control unit 40 of the in-vehicle ECU 4(1) performs post-processing while storing the received blocks in a buffer. When the free memory capacity becomes equal to or less than a first predetermined value, the ECU control unit 40 transmits a stop signal to the in-vehicle device 3 in the transmission control process. Upon receiving the stop signal, the device control unit 30 of the in-vehicle device 3 stops transmitting the blocks to the in-vehicle ECU 4(1) that transmitted the stop signal. Note that, when the transmission control process is performed using a protocol using UDS, the ECU control unit 40 of the in-vehicle ECU 4 transmits a stop signal or a start signal to the in-vehicle device 3 by responding to an inquiry signal using a Response on Event function transmitted from the in-vehicle device 3 at a predetermined interval. That is, each in-vehicle ECU 4 can transmit a stop signal or a start signal periodically according to the number of free buffers. When the stop signal is received from any of the in-vehicle ECUs 4, the device control unit 30 of the in-vehicle device 3 identifies the in-vehicle ECUs 4 that can perform post-processing when the block is received by receiving a stop signal or a start signal from each of the other in-vehicle ECUs 4.

[0132] When a stop signal is received from the in-vehicle ECU 4, the device control unit 30 of the in-vehicle device 3 determines one of the in-vehicle ECUs 4 that last transmitted either the stop signal or the start signal (in-vehicle ECU 4(n) in the example shown in FIG. 19) as the in-vehicle ECU 4 to transmit the block next. The device control unit 30 starts transmitting the block to the in-vehicle ECU 4(n), and transmits the block based on the next-order request signal (see FIG. 4) transmitted from the in-vehicle ECU 4(n) during the program update process.

[0133] The ECU control unit 40 of the in-vehicle ECU 4(n) performs post-processing while storing the received blocks in a buffer, and when the free memory capacity becomes equal to or less than a first predetermined value, transmits a stop signal to the in-vehicle device 3 in the transmission control process. The device control unit 30 of the in-vehicle device 3 that received the stop signal stops transmitting blocks to the in-vehicle ECU 4(n) that transmitted the stop signal. Furthermore, the ECU control unit 40 of the in-vehicle ECU 4(1) transmits a start signal to the in-vehicle device 3 when the number of free buffers becomes equal to or greater than a second predetermined value.

[0134] Thereafter, the device control unit 30 of the in-vehicle device 3 sends the blocks to the in-vehicle ECU 4 that sent the start signal, and when it receives a stop signal from that in-vehicle ECU 4, it starts sending the blocks to other in-vehicle ECUs that sent the start signal. This allows the device control unit 30 to send the blocks to other in-vehicle ECUs 4 while one of the in-vehicle ECUs 4 is performing post-processing of the blocks, thereby shortening the time required to complete sending of the blocks to multiple in-vehicle ECUs 4. Note that even when the device control unit 30 of the in-vehicle device 3 has completed sending all the blocks to one in-vehicle ECU 4, it still determines the in-vehicle ECU 4 to which the blocks should be sent from the other in-vehicle ECUs that sent the start signal, and starts sending the blocks to that in-vehicle ECU 4.

[0135] In this way, the device control unit 30 of the in-vehicle device 3 performs processing for updating the programs of the multiple in-vehicle ECUs at substantially the same time. In this case, the device control unit 30 of the in-vehicle device 3 may acquire, from the program provider device, each update program to be applied to each of the in-vehicle ECUs to be updated. The device control unit 30 of the in-vehicle device 3 may then divide each of the update programs into blocks of a predetermined size and transmit each of the divided blocks to each of the in-vehicle ECUs. Alternatively, the update program acquired by the in-vehicle device 3 from the external server S1 (program provider device) may be configured as a single file, such as an archive file, and the device control unit 30 of the in-vehicle device 3 may associate each divided block with an in-vehicle ECU as a destination when dividing the update program into blocks. In this case, the blocks transmitted to each in-vehicle ECU 4 are blocks whose corresponding destinations indicate the in-vehicle ECU 4. Hereinafter, the blocks transmitted to each in-vehicle ECU may be intended to be blocks in the update program to be applied to that in-vehicle ECU.

[0136] 20 is a flowchart illustrating the correlation between the transmission control process and the program update process of the in-vehicle device 3 according to the fourth embodiment. In the program update process, the device control unit 30 of the in-vehicle device 3 receives an update program for the in-vehicle ECU 4 from the external server S1 (S901). In the transmission control process, the device control unit 30 also receives a stop signal or a start signal from each in-vehicle ECU 4 (S902). The device control unit 30 determines an in-vehicle ECU 4 to which to transmit a block of the update program from among the in-vehicle ECUs 4(1) to (n) (S903). In S903, the device control unit 30 determines, for example, the in-vehicle ECU 4 with the smallest number (hereinafter referred to as the ECU number) for distinguishing the in-vehicle ECU 4 from among the in-vehicle ECUs 4 that have transmitted a start signal to the in-vehicle device 3, as the in-vehicle ECU 4 to transmit the block. After determining the in-vehicle ECU 4 to which the block is to be transmitted in the transmission control process, the device control section 30 starts transmitting the block to the in-vehicle ECU 4 determined in S903 (S904).

[0137] The device control unit 30 generates blocks by preprocessing the update program received in the program update process (S905). The device control unit 30 transmits the generated blocks to the in-vehicle ECU 4 (S906). The device control unit 30 receives a next-order request signal from the in-vehicle ECU 4 (S907). The in-vehicle ECU 4 determines whether all blocks of the update program have been transmitted (S908). If not all blocks have been transmitted (S908: NO), the process returns to S905, and the process continues for the next block in the next order. If all blocks have been transmitted (S908: YES), the device control unit 30 of the in-vehicle device 3 returns to S903 in the transmission control process. Note that in S903 when the process returns from S908, the in-vehicle ECU 4 with the smallest ECU number among the in-vehicle ECUs 4 that have not received the update program and transmitted a start signal to the in-vehicle device 3 is determined to be the in-vehicle ECU 4 that will transmit the blocks.

[0138] When the in-vehicle ECU 4 that received the update program block (the in-vehicle ECU 4 determined in S903) transmits a stop signal, the device control unit 30 of the in-vehicle device 3 receives the stop signal (S909). The device control unit 30 stops transmitting the block to the in-vehicle ECU 4 that transmitted the stop signal (S910). The device control unit 30 determines the in-vehicle ECU 4 to which the update program block will be transmitted next (S911). In S911, the device control unit 30 determines, for example, the in-vehicle ECU 4 with the smallest ECU number among the in-vehicle ECUs that transmitted the stop signal or the start signal last to the in-vehicle device 3 as the in-vehicle ECU 4 to which the update program block will be transmitted next. The device control unit 30 starts transmitting the block to the in-vehicle ECU 4 determined in S911 (S912). When the device control unit 30 executes S912 in the transmission control processing, the device control unit 30 proceeds to S905 in the program update processing.

[0139] If the in-vehicle ECU 4 that transmitted the stop signal received in S909 or S914 related to the previous loop transmits a start signal, the device control unit 30 of the in-vehicle device 3 receives the start signal (S913). Furthermore, if the in-vehicle ECU 4 determined in S911 transmits a stop signal, the device control unit 30 receives the stop signal (S914). If the device control unit 30 receives a stop signal, it stops transmitting blocks to the in-vehicle ECU 4 that transmitted the stop signal (S915) and returns the process to S903. Note that in S903 when the process is returned from S915, the in-vehicle ECU 4 with the smallest ECU number among the in-vehicle ECUs that last transmitted a start signal, either a stop signal or a start signal, to the in-vehicle device 3 is determined to be the in-vehicle ECU 4 that will next transmit the update program block. The device control unit 30 of the in-vehicle device 3 may periodically obtain the number of free buffers from each in-vehicle ECU 4, and in S903 or S911, determine the in-vehicle ECU 4 with the most free buffers as the in-vehicle ECU 4 to transmit the block.

[0140] According to the above configuration and processing, the device control unit 30 of the in-vehicle device 3 sends a block to the in-vehicle ECU 4 that is sending the start signal, and when it receives a stop signal from that in-vehicle ECU 4, starts sending the block to other in-vehicle ECUs that are sending the start signal. This allows the device control unit 30 to send the block to one of the in-vehicle ECUs 4 while the other in-vehicle ECUs 4 are performing post-processing of the block, preventing waiting time before processing can start and shortening the time required to complete sending of the block to multiple in-vehicle ECUs 4.

[0141] (Appendix 1) an on-board ECU installed in a vehicle; an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update the program of the in-vehicle ECU; A program update method for updating a program of an in-vehicle ECU in an in-vehicle update system, comprising: the in-vehicle device sequentially transmits the update program to the in-vehicle ECU in blocks divided into predetermined sizes; When the in-vehicle ECU receives the blocks, the in-vehicle ECU stores the received blocks in a memory in sequence; the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a part of the memory as a work area; The in-vehicle device transmits the next block, which is the block immediately following the block for which post-processing is being performed, to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the memory. How to update the program.

[0142] (Appendix 2) an on-board ECU installed in a vehicle; an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update the program of the in-vehicle ECU; An update program for updating a program of the in-vehicle ECU of an in-vehicle update system including: the in-vehicle device sequentially transmits the update program to the in-vehicle ECU in blocks divided into predetermined sizes; When the in-vehicle ECU receives the blocks, the in-vehicle ECU stores the received blocks in a memory in sequence; the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a part of the memory as a work area; The in-vehicle device transmits the next block, which is the block immediately following the block for which post-processing is being performed, to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the memory. The update that causes the process to run.

[0143] (Appendix 3) an on-board ECU installed in a vehicle; an in-vehicle device that is connected to a maintenance device outside the vehicle, receives an update program transmitted from the maintenance device, and performs processing to update the program of the in-vehicle ECU; An in-vehicle update system comprising: the in-vehicle device sequentially transmits the update program to the in-vehicle ECU in blocks divided into predetermined sizes; When the in-vehicle ECU receives the blocks, the in-vehicle ECU stores the received blocks in a memory in sequence; the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a part of the memory as a work area; The in-vehicle device transmits the next block, which is the block immediately following the block for which post-processing is being performed, to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the memory. In-vehicle update system.

[0144] The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The technical features described in each embodiment may be combined with one another, and the scope of the present invention is intended to include all modifications within the scope of the claims and equivalents thereto. Furthermore, independent and dependent claims described in the claims may be combined with one another in any and all combinations, regardless of the reference format. Furthermore, while the claims use a format in which a claim references two or more other claims (multiple claim format), this is not limiting. Multiple claims (multiple multiple claims) that reference at least one other multiple claim may also be used. [Explanation of symbols]

[0145] 1. External communication device 3 Onboard equipment 30 Device control section 31 Storage section 311 Recording Media 32 In-vehicle communication unit 4 In-vehicle ECU 40 ECU control section 41 memory 42 Auxiliary storage 43 In-vehicle communication unit 5. In-vehicle network C vehicle N External network P1 Device Control Program P2 ECU control program S In-vehicle update system S1 External Server S2 terminal equipment T ECU Table

Claims

1. an on-board ECU mounted on a vehicle; an in-vehicle device that receives an update program transmitted from a program providing device and performs processing to update the program of the in-vehicle ECU; An in-vehicle update system comprising: the in-vehicle device sequentially transmits the update program to the in-vehicle ECU in blocks divided into predetermined sizes; When the in-vehicle ECU receives the blocks, the in-vehicle ECU stores the received blocks in a memory in sequence; the in-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a part of the memory as a work area; The in-vehicle device transmits the next block, which is the block immediately following the block for which post-processing is being performed, to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the memory. In-vehicle update system.

2. The program providing device is an external server outside the vehicle. The in-vehicle update system of claim 1 .

3. The in-vehicle device stops transmitting the block when the free space in the memory of the in-vehicle ECU becomes equal to or less than a first predetermined value.

3. An in-vehicle update system according to claim 1 or 2.

4. the memory of the in-vehicle ECU includes a plurality of buffers corresponding to the blocks to be received, the in-vehicle ECU performs post-processing on the blocks stored in the buffer by using the buffer as a work area; The in-vehicle device transmits the next block, which is the block immediately following the block for which post-processing is being performed, to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the block stored in the buffer.

3. An in-vehicle update system according to claim 1 or 2.

5. the on-board ECU receives the next block while performing post-processing on the block stored in the buffer; Storing the next block in a buffer different from the buffer in which the block undergoing post-processing is stored.

5. The in-vehicle update system of claim 4.

6. the memory of the in-vehicle ECU includes a plurality of buffers corresponding to the blocks to be received, The in-vehicle ECU performing post-processing on the blocks stored in the buffer by using the buffer as a work area; After performing post-processing on the block stored in the buffer, delete the block from the buffer; The free space in the memory of the vehicle-mounted ECU corresponds to the number of buffers that do not store the blocks among the plurality of buffers.

4. The in-vehicle update system of claim 3.

7. the on-vehicle ECU erases the block from the memory after performing post-processing on the block stored in the memory; The in-vehicle device starts transmitting the block when the free space in the memory of the in-vehicle ECU becomes equal to or larger than a second predetermined value.

3. An in-vehicle update system according to claim 1 or 2.

8. After storing the block in the memory, the in-vehicle ECU transmits a signal to the in-vehicle device requesting transmission of the next block in the next order before post-processing for the block stored in the memory is completed.

3. An in-vehicle update system according to claim 1 or 2.

9. When the free space in the memory becomes equal to or smaller than a first predetermined value, the in-vehicle ECU transmits a signal to the in-vehicle device requesting the stop of transmission of the block.

4. The in-vehicle update system of claim 3.

10. Two connections are established between the in-vehicle device and the in-vehicle ECU, The block is transmitted from the in-vehicle device to the in-vehicle ECU via one connection; In the other connection, a signal is transmitted from the in-vehicle ECU to the in-vehicle device requesting the stop of transmission of the block.

10. The in-vehicle update system of claim 9.

11. When the free space in the memory becomes equal to or larger than a second predetermined value, the in-vehicle ECU transmits a signal to the in-vehicle device requesting the start of transmission of the block.

10. The in-vehicle update system of claim 9.

12. The in-vehicle device acquiring information about the free space of the memory of the in-vehicle ECU; If the free space in the memory is equal to or less than a first predetermined value, the transmission of the block is stopped.

4. The in-vehicle update system of claim 3.

13. Two connections are established between the in-vehicle device and the in-vehicle ECU, In one connection, the block is transmitted from the in-vehicle device to the in-vehicle ECU, and a signal requesting transmission of the next block in the next order is transmitted from the in-vehicle ECU to the in-vehicle device; Through the other connection, a signal inquiring about the free space of the memory is transmitted from the in-vehicle device to the in-vehicle ECU, and information about the free space of the memory is transmitted from the in-vehicle ECU to the in-vehicle device.

13. The in-vehicle update system of claim 12.

14. The in-vehicle device If the free space in the memory is equal to or greater than a second predetermined value, start transmitting the block.

13. The in-vehicle update system of claim 12.

15. a plurality of the on-vehicle ECUs; When the transmission of the block to any one of the plurality of in-vehicle ECUs is stopped, the in-vehicle device starts transmitting the block of the update program to another in-vehicle ECU different from the one of the in-vehicle ECUs, the update program to be applied to the other in-vehicle ECU.

4. The in-vehicle update system of claim 3.

16. the in-vehicle ECU transmits a stop signal to the in-vehicle device requesting that transmission of the block be stopped when the available capacity of the memory becomes equal to or less than a first predetermined value; the in-vehicle ECU transmits a start signal to the in-vehicle device requesting the start of transmission of the block when the available capacity of the memory becomes equal to or greater than a second predetermined value; The in-vehicle device When the stop signal is received from any of the on-board ECUs, and starting transmission of the block of the update program to be applied to the in-vehicle ECU to the in-vehicle ECU that has transmitted the start signal, among the in-vehicle ECUs different from the one of the in-vehicle ECUs.

16. The in-vehicle update system of claim 15.

17. an on-board ECU mounted on a vehicle; an in-vehicle device that receives an update program transmitted from a program providing device and performs processing to update the program of the in-vehicle ECU; An in-vehicle update system comprising: The in-vehicle device and the in-vehicle ECU establish two connections. In-vehicle update system.

18. An in-vehicle device that receives an update program transmitted from a program providing device and performs processing to update a program of an in-vehicle ECU mounted in a vehicle, The update program is transmitted to the vehicle-mounted ECU in blocks divided into predetermined sizes, one after another. In the in-vehicle ECU, at least a part of the area of ​​the memory storing the blocks sequentially received by the in-vehicle ECU is used as a work area, and even during post-processing of the block stored in the memory, the next block following the block for which post-processing is being performed is transmitted to the in-vehicle ECU. In-vehicle device.

19. An on-board ECU mounted on a vehicle, receiving the update program in blocks of a predetermined size from the in-vehicle device that has acquired the update program transmitted from the program providing device; If the block is received, storing the received block in a memory; performing post-processing on the blocks stored in the memory by using at least a part of the memory as a work area; Even while post-processing is being performed on the block stored in the memory, the next block that follows the block being post-processed is received from the in-vehicle device. In-vehicle ECU.

Images