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

Abstract

[Problem] To provide an on-vehicle update system, etc. for shortening a time when an on-vehicle device transmits an update program to an on-vehicle ECU. [Solution] In an on-vehicle update system according to an embodiment of the present disclosure, the on-vehicle device sequentially transmits, to the on-vehicle ECU, the update program in blocks divided into a prescribed size, the on-vehicle ECU sequentially stores the received blocks in a memory when the blocks are received, the on-vehicle ECU performs post-processing on the blocks stored in the memory by using at least a partial region of the memory as a work region, and the on-vehicle device transmits the next block subsequent to the block being post-processed even when the on-vehicle ECU is currently performing post-processing on the blocks stored in the memory.

Description

In-vehicle update system, in-vehicle device, and in-vehicle ECU

[0001] This application claims priority to Japanese Patent Application No. 2024-059132 filed on April 1, 2024, and Japanese Patent Application No. 2024-179881 filed on October 15, 2024, and incorporates all of the contents of the aforementioned Japanese applications by reference.

[0002] A vehicle is equipped with an ECU (Electronic Control Unit) for controlling on-board devices such as drive control systems (e.g., engine control) and body systems (e.g., air conditioning control). The ECU includes an arithmetic 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 on-board devices by reading and executing control programs stored in the storage unit. The vehicle is also equipped with a communication device (on-board 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).

[0003] Japanese Patent Application Laid-Open No. 2017-97851

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

[0005] 1 is a schematic diagram illustrating the configuration of an in-vehicle update system; FIG. 2 is a block diagram illustrating the physical configuration of an in-vehicle device and an in-vehicle ECU according to a first embodiment; FIG. 3 is an explanatory diagram illustrating transitions in memory usage; FIG. 4 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a first embodiment; FIG. 5 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a first embodiment; FIG. 6 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a second embodiment; FIG. 7 is a flowchart illustrating a program update process of an in-vehicle device and an in-vehicle ECU to be updated according to a first embodiment; FIG. 8 is a flowchart illustrating a subroutine of post-processing of a block of an in-vehicle ECU to be updated according to a first embodiment; 1 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a second embodiment; FIG. 2 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a second embodiment; FIG. 3 is an explanatory diagram illustrating a processing flow (sequence) by an in-vehicle device and an in-vehicle ECU to be updated according to a second embodiment; FIG. 4 is a flowchart illustrating a transmission control process of an in-vehicle device and an in-vehicle ECU to be updated according to a second embodiment; FIG. 5 is a schematic diagram illustrating a configuration of an in-vehicle update system according to a third embodiment; FIG. 6 is a schematic diagram illustrating 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; FIG. 7 is a block diagram illustrating a physical configuration of an in-vehicle device and an in-vehicle ECU according to a fourth embodiment; FIG. 8 is a schematic diagram illustrating an outline of a processing flow (sequence) by an in-vehicle device and a plurality of in-vehicle ECUs to be updated according to the third embodiment;

[0006] [Problem to be Solved by the Present Disclosure] 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.

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

[0008] Effect of the Present Disclosure In an 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.

[0009] [Description of 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 aspect 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 receiving 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 on-board device of an on-board update system acquires an update program for an on-board ECU from an external server and divides the acquired update program into multiple blocks. The on-board device sequentially transmits the divided blocks (e.g., first block, second block, third block, etc.) to the on-board ECU (Electronic Control Unit). The on-board ECU stores the received update program blocks in memory and applies the update program corresponding to the blocks to the on-board ECU by post-processing the stored blocks (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 stepwise in the on-board ECU to update the on-board ECU. Note that the blocks received by the on-board ECU are stored in the memory area until post-processing is completed (ended). For example, after the on-board ECU stores the first block in memory, the on-board device transmits the block next to the first block (the second block) to the on-board 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 update program blocks 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 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. Note that the in-vehicle ECU may retry post-processing if the post-processing terminates abnormally. 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. Furthermore, the in-vehicle device can prevent blocks from being transmitted 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 aspect 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 buffer as a work area to perform post-processing on the blocks stored in the buffer, 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 aspect, the memory area of ​​the in-vehicle ECU is partitioned into multiple buffers each capable of storing a predetermined amount of data, and each buffer can store one block. In this case, the buffer is also used as a work area for post-processing one block, and the data amount (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). If a predetermined number of blocks (e.g., five) are transmitted as a set from the in-vehicle device to the in-vehicle 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 post-processing (work) coefficient. Even while the in-vehicle ECU is performing post-processing on a block stored in the buffer, the in-vehicle device can transmit update program blocks at short intervals by transmitting the next block following the block currently being post-processed to the in-vehicle ECU.

[0016] (4) In one aspect 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 shortening the time required for transmitting an update program from the in-vehicle device to the in-vehicle ECU.

[0018] (5) In one aspect of the in-vehicle update system 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 in-vehicle ECU stores blocks received from an in-vehicle device in a buffer in memory. The in-vehicle 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 in-vehicle 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 one aspect of the in-vehicle update system 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 erases 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, however, when the free memory capacity of the memory 41 becomes less than the second predetermined value, the in-vehicle device 3 stops transmitting the block.

[0022] (7) In an in-vehicle update system according to one aspect 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 one aspect of the in-vehicle update system of the present disclosure, when the free space in the memory falls below a first predetermined value, the in-vehicle ECU sends a signal to the in-vehicle device requesting that the transmission of the block be stopped.

[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 available to store the blocks.

[0026] (9) In an in-vehicle update system according to one aspect 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, the on-board ECU can transmit a signal to the on-board device requesting stop of block transmission to the on-board device.

[0028] (10) In one aspect 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 aspect, the in-vehicle ECU monitors the free memory capacity (number of free buffers). When the free memory capacity reaches or exceeds 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 transmitted, for example, via the other connection.

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

[0031] In this aspect, the on-board device periodically transmits a signal to the on-board ECU, for example, inquiring about the available memory space of the on-board ECU. When the on-board ECU receives the signal inquiring about the available memory space, it transmits information about the available memory space (a numerical value of the available memory space) to the on-board device. The on-board device determines whether the received (acquired) available memory space of the on-board 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 on-board ECU. This prevents the on-board device from transmitting blocks when there is no space in the on-board ECU memory to store the blocks. Note that the information about the available memory space may be information indicating whether the memory can store the blocks (e.g., a flag value indicating 0 if the memory is available and 1 if the memory is under load).

[0032] (12) In an in-vehicle update system according to one aspect 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 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 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 requesting transmission of another (next) block from the on-board device. The other connection is used for transmitting a signal inquiring about available capacity from the on-board device to the on-board ECU 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 from 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) for the available capacity of each on-board ECU. The on-board device may determine whether to stop transmitting the block to the on-board ECU based on the predetermined values ​​corresponding to the on-board ECU.

[0034] (13) In an in-vehicle update system according to one 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 the on-board device has stopped transmitting blocks to the on-board ECU, it periodically transmits a signal to the on-board ECU inquiring about the available memory space of the on-board ECU. When the on-board ECU receives the signal inquiring about the available memory space, it transmits the available memory space to the on-board device. The on-board device determines whether the received (acquired) available memory space of the on-board 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) transmitting blocks to the on-board ECU. This allows the on-board device to start (resume) transmitting blocks to the on-board ECU when the available memory space of the on-board 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 aspect 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 memory area that stores the blocks sequentially received by the in-vehicle ECU as a work area, and even while post-processing is being performed on the block stored in the memory, the in-vehicle ECU transmits the next block following the block for which post-processing is being performed to the in-vehicle ECU.

[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 aspect 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 from the in-vehicle device the next block that is immediately following the block for which post-processing is being performed.

[0039] In this embodiment, the on-board ECU can receive the next block in sequence 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 shortening the time required to send update programs.

[0040] (16) An in-vehicle update system according to one aspect 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 following the block for which post-processing is being performed to the in-vehicle ECU.

[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 an external server or a terminal device such as 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 undivided update program 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., first block, second block, third block, etc.) to the on-board ECU (Electronic Control Unit). The on-board ECU stores the received update program blocks in memory and applies the update program corresponding to the blocks to the on-board ECU by post-processing the stored blocks (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 in stages 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 its memory, the in-vehicle device transmits the block (second block) following the first block to the in-vehicle ECU. While the in-vehicle ECU is performing post-processing on 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 on the stored second block. In this way, even while the in-vehicle ECU is performing post-processing on a block (nth block), the in-vehicle device transmits the next sequential block (n+1th block) to the in-vehicle ECU. This allows the in-vehicle device to transmit update program blocks 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 aspect of the present disclosure includes a plurality of the in-vehicle ECUs, and when the in-vehicle device stops transmitting the block to one of the in-vehicle ECUs, it starts transmitting the block of the update program to another in-vehicle ECU that is different from one of the in-vehicle ECUs and that is applied to the other in-vehicle ECU.

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

[0046] (19) In one aspect 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 sends 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 sends 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, it starts transmitting the block to another in-vehicle ECU different from one of the in-vehicle ECUs that sent 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 ECU that can receive the block and transmitting the block to that 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 aspect 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 on-board device and the on-board ECU. One connection is used for transmitting a block of an update program from the on-board device to the on-board ECU and for transmitting a signal requesting transmission of another (next) block from the on-board device. The other connection is used for transmitting a signal inquiring about available space from the on-board device to the on-board ECU and for transmitting the available space from the on-board ECU to the on-board device. This allows the on-board device to inquire about available space from the on-board ECU even while transmitting a block or a signal requesting transmission of a block. This reduces the time it takes for the on-board device to transmit an update program to the on-board ECU.

[0050] [Details of the embodiment of the present disclosure] The present disclosure will be specifically described with reference to the drawings illustrating the embodiment. An in-vehicle device 3 according to the embodiment of the present disclosure will be described below with reference to the drawings. Note that the present disclosure 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, an embodiment 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 an in-vehicle ECU-side communication line (in-vehicle communication line 51) connecting the in-vehicle device 3 and the in-vehicle ECU 4 (ECU), and an external server-side communication line (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 a manufacturer of the in-vehicle ECU 4, for example. The programs or data are transmitted to the vehicle C as update programs, as described below, 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 manner is also referred to as an OTA (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 activation instructions for applying the transmitted update programs to the in-vehicle ECU 4. The in-vehicle ECU 4 installed in the vehicle C acquires update programs transmitted wirelessly from the external server S1 via the in-vehicle device 3 and applies the update programs (activation processing) in response to the activation instructions, thereby updating (reprogramming) the programs executed by the 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 update programs 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 containing control syntax and the like for processing by the in-vehicle ECU 4, and an external file containing data referenced when the program code is executed. When transmitting an update program, the external file containing the program code and data is transmitted from the external server S1, for example, as an encrypted archive file. When transmitting the update program, the external server S1 generates a package containing the update program and transmits the generated package to the vehicle C. The package includes, for example, package information (campaign information) that is information related to 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 communicatively connected by a harness such as a serial cable. The in-vehicle device 3 and the in-vehicle ECUs 4 are communicatively 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 Wi-Fi (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. 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 separate device from the in-vehicle device 3, and these devices are communicatively connected via 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 via an in-vehicle network 5 such as Ethernet.

[0058] The on-board device 3 is a gateway (on-board relay device) that manages multiple bus systems (segments), such as the on-board ECU 4 for a control system, the on-board ECU 4 for a safety system, and the on-board ECU 4 for a body system, and relays communications between the on-board ECUs 4 between these buses (segments). That is, the on-board device 3 is connected to each of the on-board communication lines 51 that make up the multiple buses (segments), and the on-board network 5 is configured by the multiple on-board communication lines 51 (segments) aggregated by the on-board device 3. The on-board device 3 functions as an Ethernet gateway when relaying Ethernet protocols and as a Layer 2 switch or Layer 3 switch when relaying TCP / IP protocols. In addition to relaying communications, the on-board device 3 may also function 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 on-board devices such as actuators connected to the on-board device 3. Alternatively, the on-board 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 exterior communication device 1, an update program (package) that the exterior 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 (the in-vehicle ECU 4 to be updated). In other words, 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 with 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. Alternatively, the device control program P1 may 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 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 communication line 51 is connected to the in-vehicle 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 on-board ECU 4 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 an ECU control program P2 (program product) and data pre-stored in the auxiliary storage unit 42. 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, for example, by 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 read-only memory (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 in the blocks 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 in the blocks received (e.g., 1.2 times the amount of data in 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 first block, second block, third block, and so on. When the in-vehicle ECU 4 receives a 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 initiated for the first block stored in the first buffer 411a. The post-processing includes decoding, decompressing, and restoring the block data, such as applying differences, or partially applying the data to the program to be updated (the 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 (while) 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, just as it did for the first block. Note that the post-processing of the first block and the post-processing of the second block are executed in parallel. 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, just as it did for the first and second blocks.

[0071] If the memory 41 has not yet completed post-processing of the first block when it 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 has fallen below a first predetermined value (the capacity of one buffer 4111) 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] A first block for which post-processing has been performed in the first buffer 411a is erased (released) from the first buffer 411a when the post-processing is completed. 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, a second block for which post-processing has been performed in the second buffer 411b is erased (released) from the second buffer 411b when the post-processing is completed. 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 4,113 buffers), 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. The ECU control unit 40 of the in-vehicle ECU 4 then 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 block, the ECU control unit 40 erases the block from the buffer 411 and makes the in-use buffer an empty buffer. 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 the first predetermined number), and starts transmitting blocks when the free space in the memory 41 becomes equal to or greater than a second predetermined value (when the number of free buffers becomes equal to or greater than the second predetermined number).

[0074] In the example shown in FIG. 3 , blocks sequentially received by the in-vehicle ECU 4 are stored in the order starting with the first buffer 411a, but this is not limited to this. 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). However, blocks 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 one buffer 4111, and the second predetermined value is the capacity of the other areas and three buffers 4111.

[0075] 4 to 6 are explanatory diagrams illustrating processing sequences (sequences) performed by the on-board device 3 and the on-board ECU 4 to be updated according to the first embodiment. The on-board device 3 and the on-board ECU 4 establish two communication connections, enabling two types of communication processes to be performed in parallel or in parallel. The on-board device 3 and the on-board ECU 4 to be updated are connected by, for example, using different destination port numbers in TCP / IP protocol communications. When the on-board device 3 and the on-board ECU 4 perform CAN communication, the two connections may be established by using different destination CANIDs. In this embodiment, the on-board device 3 and the on-board 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, the update program is divided into five blocks. The program update process stops when the number of free buffers falls to one or less, and starts (resumes) when the number of free buffers reaches three or more. 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 following 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 by preprocessing (S107), and 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 following 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 by preprocessing (S112), and 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 following 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) following 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 is equal to or less than a first predetermined value (equal to or less than the capacity of one buffer 411) (insufficient free memory capacity in the memory 41) (S201), and transmits a signal (stop signal) requesting the in-vehicle device 3 to stop transmitting the block (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, the device control unit 30 stops transmitting 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 has started (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 start of the post-processing of the third block, for example (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 a second predetermined value (the capacity of 4113 buffers 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 following 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 has started (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) following 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 following 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 for 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). Before the first block (first block) of the update program is transmitted, the free space in the memory 41 of the in-vehicle ECU 4 is greater than a 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 for the block stored in S35 (generates a subprocess) (S37). Note that even if the post-processing subroutine for the block (see FIG. 8) 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 continues with the next block. In this case, when the device control unit 30 of the in-vehicle device 3 returns the process, the ECU control unit 40 of the in-vehicle ECU 4 also returns the process 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] FIG. 8 is a flowchart illustrating a subroutine for post-processing a block of the on-board ECU 4 to be updated. The ECU control unit 40 of the on-board ECU 4 decrypts the block stored in the buffer 411 of the memory 41 (S371) and decompresses the decrypted 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 on-board ECU 4 may measure the free space (number of free buffers) in 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 available space in the memory 41 (S41). The ECU control unit 40 determines whether the available space measured in S41 is equal to or less than a first predetermined value (S42). If the available space is not equal to or less than the first predetermined value (greater than the first predetermined value) (S42: NO), the ECU control unit 40 returns the process to S41. If the available 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 blocks to the in-vehicle ECU 4 (S45). That is, the device control unit 30 does not execute the process of transmitting the blocks 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) transmitting the blocks to the in-vehicle ECU 4 (S50). That is, the device control unit 30 executes the process of transmitting the blocks 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, 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, 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) An in-vehicle device 3 according to embodiment 2 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 stores a first predetermined value for determining whether to stop transmitting blocks to the memory 41 of each in-vehicle ECU 4 connected to the in-vehicle device 3 via the in-vehicle communication line 51 so as to be able to communicate with the in-vehicle device 3, and a second predetermined value for determining whether to start transmitting blocks. The ECU table's management items (fields) 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 on-board ECU 4. The identification number of the on-board 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 on-board device 3 stops transmitting blocks to the on-board ECU 4 that is the target of a 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 on-board device 3 starts transmitting blocks to the on-board ECU 4 that is the target of a program update. The free space field stores information regarding the free space of the memory 41 of the on-board ECU 4 (the number of free buffers), which the on-board device 3 receives from the on-board ECU 4. The value stored in the free space field is updated each time the on-board device 3 receives information regarding the free space from the on-board 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, for example, in MB, that the memory 41 can store. 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 transmitting 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 if the in-vehicle device 3 has resumed transmitting blocks after stopping them but has not yet stopped transmitting 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 number of transmitted blocks 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. 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. 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 is similar to the process in the first embodiment (the process related to S101 to S131 shown in FIGS. 4 to 6 ). In the transmission control process, the device control unit 30 of the in-vehicle device 3 reads the first and second predetermined values ​​of the in-vehicle ECU 4 to be updated from the ECU table T (S601). The device control unit 30 transmits a signal (inquiry signal) to the in-vehicle ECU 4 to inquire 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, having 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). In S605, since the free space in the memory 41 is greater than the first predetermined value, the device control unit 30 again transmits an inquiry signal to the in-vehicle ECU 4 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 in S602 to S605 (S606 to S609 and S610 to S613). In S612, the ECU control unit 40 of the in-vehicle ECU 4 transmits information indicating that the number of free buffers is one to the in-vehicle device 3. Therefore, 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 4111 buffers). 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 4111 buffers), 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 in S615 to S618 (S619 to S622). Note that in S621, the ECU control unit 40 of the in-vehicle ECU 4 transmits information indicating that the number of free buffers is three to the in-vehicle device 3. Therefore, 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 (4,113 buffers). 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 (4,113 buffers), 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). Hereinafter, the device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 stop transmitting blocks in the program update process when it is determined in the same process as that in S605 that the available space in the memory 41 is equal to or less than a first predetermined value, and repeat the same processes as those in S615 to S618. Furthermore, the device control unit 30 of the in-vehicle device 3 and the ECU control unit 40 of the in-vehicle ECU 4 start (resume) transmitting blocks in the program update process when it is determined in the same process as that in S618 that the available space in the memory 41 is equal to or greater than a second predetermined value, and repeat the same processes as those in 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 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 about 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 regarding 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 to S72. Note that 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 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 before executing S33. The device control unit 30 transmits an inquiry signal to the in-vehicle ECU 4 (S79). Note that the device control unit 30 transmits an 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 regarding 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 to S79. Note that 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 the process (S33) of transmitting blocks to the in-vehicle ECU 4 that were not executed in the program update process (see FIG. 7 ) and resumes the program update process. The device control unit 30 returns the process to S72. 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 obtains 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] Third Embodiment An in-vehicle device 3 according to a third embodiment transmits an update program acquired from a 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 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. The terminal device S2 stores programs or data for controlling the in-vehicle ECU 4, which are created by the manufacturer of the in-vehicle ECU 4, in the storage unit S21. The programs or data are transmitted to the in-vehicle device 3 as update programs and 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 receive 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-order 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 when the free memory space falls below a first predetermined value, 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 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 space 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 resumes transmitting the block. Thereafter, the terminal device S2, the in-vehicle device 3, and the in-vehicle ECU 4 repeat the same process. As described above, two connections are established between the terminal device S2 and the in-vehicle device 3. This allows 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. The terminal device S2 generates blocks in response to the next-order request signal and transmits them to the in-vehicle device 3. The device control unit 30 of the in-vehicle device 3 transmits the received blocks 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. The device control unit 30 of the in-vehicle device 3 may also 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, so that blocks of the update program can be transmitted at short intervals, thereby shortening the time required to transmit the update program.

[0126] (Embodiment 4) The in-vehicle device 3 according to embodiment 4 receives a stop signal from an in-vehicle ECU 4, stops transmitting blocks to the in-vehicle ECU 4 (any of the in-vehicle ECUs 4) that sent the stop signal, 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 first embodiment (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 greater).

[0128] The on-board ECUs 4(1) to (n) are each connected to the in-vehicle communication unit 32 of the on-board device 3 via an in-vehicle communication line 51. Two connections are established between the in-vehicle communication unit 32 and each on-board ECU 4 via the in-vehicle communication line 51. The processing and communication between each on-board ECU 4 and the on-board 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 the in-vehicle device 3 and multiple 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 on-board ECU 4, if not performing post-processing of the block, transmits a start signal to the on-board device 3. The device control unit 30 of the on-board device 3 determines one of the on-board ECUs 4 that transmitted the start signal (on-board ECU 4(1) in the example shown in FIG. 19) as the on-board 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 on-board 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 falls below 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 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. In other words, each in-vehicle ECU 4 can transmit a stop signal or a start signal periodically depending on the number of free buffers. When a 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 an on-board ECU 4, the device control unit 30 of the on-board device 3 determines one of the on-board ECUs 4 that last transmitted either a stop signal or a start signal (on-board ECU 4(n) in the example shown in FIG. 19 ) as the on-board ECU 4 to which to transmit the next block. The device control unit 30 starts transmitting the block to the on-board ECU 4(n), and transmits the block based on the next-order request signal (see FIG. 4 ) transmitted from the on-board 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 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 blocks to other in-vehicle ECUs that sent start signals. This allows the device control unit 30 to send blocks to other in-vehicle ECUs 4 while one in-vehicle ECU 4 is performing post-processing of the block, thereby shortening the time required to complete sending 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 blocks to one in-vehicle ECU 4, it still determines which in-vehicle ECU 4 to send blocks to from the other in-vehicle ECUs that sent the start signal, and starts sending blocks to that in-vehicle ECU 4.

[0135] In this manner, 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 a 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 applied to that in-vehicle ECU.

[0136] FIG. 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 the in-vehicle ECU 4 to which to transmit the 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") that distinguishes the in-vehicle ECU 4 from among the in-vehicle ECUs 4 that transmitted the 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 unit 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 during 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 continues with the next block. 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 onboard ECU 4 that received the update program block (the onboard ECU 4 determined in S903) transmits a stop signal, the device control unit 30 of the onboard device 3 receives the stop signal (S909). The device control unit 30 stops transmitting the block to the onboard ECU 4 that transmitted the stop signal (S910). The device control unit 30 determines the onboard ECU 4 to which the update program block will be transmitted next (S911). In S911, the device control unit 30 determines the onboard ECU 4 with the smallest ECU number among the onboard ECUs 4 that last transmitted a stop signal or a start signal to the onboard device 3 as the onboard ECU 4 to which the update program block will be transmitted next. The device control unit 30 then begins transmitting the block to the onboard ECU 4 determined in S911 (S912). When the device control unit 30 executes S912 in the transmission control process, the device control unit 30 proceeds to S905 in the program update process.

[0139] If the on-board 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 on-board device 3 receives the start signal (S913). Furthermore, if the on-board 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 on-board 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 on-board ECU 4 with the smallest ECU number among the on-board ECUs 4 that last transmitted a start signal (either a stop signal or a start signal) to the on-board device 3 is determined to be the on-board ECU 4 that will next transmit the update program block. In addition, 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 transmitting the start signal, and when it receives a stop signal from that in-vehicle ECU 4, starts transmitting the block to other in-vehicle ECUs 4 that are transmitting the start signal. This allows the device control unit 30 to transmit the block to one of the in-vehicle ECUs 4 while the other in-vehicle ECUs 4 are performing post-processing of the block, thereby preventing the occurrence of wait times before the start of processing and shortening the time required to complete transmission of the block to multiple in-vehicle ECUs 4.

[0141] (Supplementary Note 1) A program update method for updating a program of an on-board ECU in an on-board update system including: an on-board ECU mounted on a vehicle; and an on-board device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update the program of the on-board ECU, wherein the on-board device transmits the update program to the on-board ECU sequentially in blocks divided into a predetermined size, the on-board ECU sequentially stores the received blocks in memory when receiving the blocks, the on-board 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 on-board device transmits to the on-board ECU the next block that is immediately following the block for which post-processing is being performed, even while the on-board ECU is performing post-processing on the block stored in the memory.

[0142] (Supplementary Note 2) An update program for updating a program of an on-board ECU in an on-board update system including: an on-board ECU mounted on a vehicle; and an on-board device that acquires an update program transmitted from an external server outside the vehicle and performs processing to update the program of the on-board ECU, wherein the on-board device sequentially transmits the update program to the on-board ECU in blocks divided into a predetermined size, the on-board ECU sequentially stores the received blocks in a memory when receiving the blocks, the on-board ECU performs post-processing on the blocks stored in the memory by using at least a partial area of ​​the memory as a work area, and the on-board device transmits to the on-board ECU, even while the on-board ECU is performing post-processing on the block stored in the memory, the on-board device transmits to the on-board ECU the next block that is immediately following the block for which post-processing is being performed.

[0143] (Supplementary Note 3) An in-vehicle update system including: an in-vehicle ECU mounted on a vehicle; and an in-vehicle device connected to a maintenance device outside the vehicle, acquiring update programs transmitted from the maintenance device, and performing processing to update a program of the in-vehicle ECU, wherein the in-vehicle device sequentially transmits the update program to the in-vehicle ECU in blocks divided into a predetermined size, the in-vehicle ECU sequentially stores the received blocks in memory when receiving 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 to the in-vehicle ECU the next block that follows the block for which post-processing is being performed, even while the in-vehicle ECU is performing post-processing on the block stored in the memory.

[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 claim may also be used.

[0145] REFERENCE SIGNS LIST 1 External communication device 3 On-board device 30 Device control unit 31 Storage unit 311 Recording medium 32 In-vehicle communication unit 4 On-board ECU 40 ECU control unit 41 Memory 42 Auxiliary storage unit 43 In-vehicle communication unit 5 On-board network C Vehicle N External network P1 Device control program P2 ECU control program S On-board update system S1 External server S2 Terminal device T ECU table

Claims

1. An in-vehicle update system comprising: an in-vehicle ECU mounted on a vehicle; and an in-vehicle device that receives an update program transmitted from a program provider 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 in blocks divided into predetermined sizes in sequence; when the in-vehicle ECU receives a block, the in-vehicle ECU stores the received block in sequence in memory; the in-vehicle ECU performs post-processing on the block stored in 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 memory, the in-vehicle device transmits to the in-vehicle ECU the next block that follows the block for which post-processing is being performed.

2. The in-vehicle update system according to claim 1, wherein the program providing device is an external server outside the vehicle.

3. The in-vehicle update system according to claim 1 or 2, wherein the in-vehicle device stops transmitting the blocks when the free space in the memory of the in-vehicle ECU falls below a first predetermined value.

4. The in-vehicle update system described in claim 1 or 2, wherein 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 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.

5. The in-vehicle update system according to claim 4, wherein 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 a buffer different from the buffer in which the block being post-processed is stored.

6. The in-vehicle update system described in claim 3, wherein 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, deletes the blocks from the buffers, and the free space in the memory of the in-vehicle ECU corresponds to the number of buffers out of the plurality of buffers that do not store the blocks.

7. The in-vehicle update system described in claim 1 or 2, wherein 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.

8. The in-vehicle update system according to claim 1 or 2, wherein the in-vehicle ECU, after storing the block in the memory, transmits a signal to the in-vehicle device requesting transmission of the next block in the sequence before post-processing for the block stored in the memory is completed.

9. The in-vehicle update system according to claim 3, wherein 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.

10. The in-vehicle update system according to claim 9, wherein two connections are established between the in-vehicle device and the in-vehicle ECU, one connection is used to transmit the block from the in-vehicle device to the in-vehicle ECU, and the other connection is used to transmit a signal from the in-vehicle ECU to the in-vehicle device requesting that transmission of the block be stopped.

11. The in-vehicle update system according to claim 9, wherein 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.

12. The in-vehicle update system according to claim 3, wherein the in-vehicle device acquires information regarding the free space of the memory of the in-vehicle ECU, and stops transmitting the blocks when the free space of the memory is equal to or less than a first predetermined value.

13. The in-vehicle update system according to claim 12, wherein two connections are established between the in-vehicle device and the in-vehicle ECU, one connection is used for transmitting the block from the in-vehicle device to the in-vehicle ECU and 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 transmitting information about the available capacity of the memory from the in-vehicle ECU to the in-vehicle device.

14. The in-vehicle update system according to claim 12, wherein 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.

15. An in-vehicle update system as described in claim 3, including a plurality of the in-vehicle ECUs, wherein when the in-vehicle device stops transmitting the block to any one of the plurality of in-vehicle ECUs, the in-vehicle device starts transmitting the block of the update program to another in-vehicle ECU different from any one of the in-vehicle ECUs, the block being applied to the other in-vehicle ECU.

16. The in-vehicle update system described in claim 15, wherein the in-vehicle ECU transmits a stop signal to the in-vehicle device requesting that transmission of the block be stopped when the free space in the memory becomes equal to or less than a first predetermined value, and the in-vehicle ECU transmits a start signal to the in-vehicle device requesting that transmission of the block be started when the free space in the memory becomes equal to or greater than a second predetermined value, and when the in-vehicle device receives the stop signal from any of the in-vehicle ECUs, it starts transmitting the block of the update program to be applied to the in-vehicle ECU to any other in-vehicle ECU different from any of the in-vehicle ECUs that transmitted the start signal.

17. 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 provider and performs processing to update the program of the in-vehicle ECU, wherein two connections are established between the in-vehicle device and the in-vehicle ECU.

18. An in-vehicle device that receives an update program transmitted from a program provider device and performs processing to update a program of an in-vehicle ECU mounted on a vehicle, the in-vehicle device transmitting the update program to the in-vehicle ECU sequentially in blocks divided into predetermined sizes, and using at least a portion of the memory area that stores the blocks sequentially received by the in-vehicle ECU as a work area, so that even while post-processing is being performed on the block stored in the memory, the in-vehicle device transmits to the in-vehicle ECU the next block that follows the block currently undergoing post-processing.

19. An on-board ECU mounted on a vehicle, which receives an update program transmitted from a program provider device in blocks divided into predetermined sizes from an on-board device that has acquired the update program, stores the received block in memory when the ECU receives the block, uses at least a portion of the memory as a work area to perform post-processing on the block stored in the memory, and receives the next block from the on-board device that is the block immediately following the block for which post-processing is being performed, even while the ECU is performing post-processing on the block stored in the memory.

Images