Vehicle-mounted update system, vehicle-mounted device, and vehicle-mounted ECU

Abstract

The present application provides a kind of shortening the time when vehicle-mounted device sends update program to vehicle-mounted ECU, and vehicle-mounted update system etc.. In the vehicle-mounted update system of the present disclosure, the vehicle-mounted device sends the update program to the vehicle-mounted ECU in the form of block divided according to specified size in sequence, the vehicle-mounted ECU stores the received block in memory in sequence when receiving the block, the vehicle-mounted ECU carries out post-processing for the block stored in the memory by using at least part of the area of the memory as working area, even during the vehicle-mounted ECU is executing post-processing for the block stored in the memory, the vehicle-mounted device sends the next block of the next order of the block being executed post-processing to the vehicle-mounted ECU.

Description

Technical Field

[0001] This technology relates to in-vehicle update systems, in-vehicle devices, and in-vehicle ECUs. This application claims priority based on Japanese Application No. 2024-059132, filed April 1, 2024, and Japanese Application No. 2024-179881, filed October 15, 2024, and incorporates all descriptions contained in those Japanese applications. Background Technology

[0002] The vehicle is equipped with an ECU (Electronic Control Unit) for controlling vehicle systems such as drive control systems (engine control, etc.) and body systems such as air conditioning control. The ECU includes a processing unit such as an MPU, a rewritable non-volatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs. It controls the vehicle equipment by reading and executing control programs stored in the storage unit. Furthermore, the vehicle is equipped with a communication device (vehicle device) with wireless communication capabilities, which can communicate with a program providing device connected to a network outside the vehicle. The program providing device can download (receive) the ECU's control program and update the ECU's control program (see, for example, Patent Document 1).

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2017-97851 Summary of the Invention

[0006] An embodiment of the vehicle update system disclosed herein includes: an on-board ECU and an on-board device, the on-board ECU being mounted on a vehicle, the on-board device receiving an update program sent from a program providing device and processing the program for updating the on-board ECU, wherein the on-board device sequentially sends the update program to the on-board ECU in the form of blocks divided according to a predetermined size, the on-board ECU, upon receiving the blocks, sequentially stores the received blocks in a memory, 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 working area, and even while the on-board ECU is performing post-processing on the blocks stored in the memory, the on-board device sends the next block in the next order of the blocks being post-processed to the on-board ECU. Attached Figure Description

[0007] Figure 1 This is a schematic diagram illustrating the structure of an onboard update system.

[0008] Figure 2 This is a block diagram illustrating the physical structure of the vehicle-mounted device and vehicle-mounted ECU according to Embodiment 1.

[0009] Figure 3 This is an explanatory diagram showing the changes in memory usage.

[0010] Figure 4 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 1.

[0011] Figure 5 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 1.

[0012] Figure 6 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 1.

[0013] Figure 7 This is a flowchart illustrating the program update process of the vehicle-mounted device and the vehicle-mounted ECU to be updated, as described in Embodiment 1.

[0014] Figure 8 This is a flowchart illustrating the post-processing subroutine of the block of the vehicle ECU that is being updated.

[0015] Figure 9 This is a flowchart illustrating the transmission control process of the vehicle-mounted device and the vehicle-mounted ECU of the update target in Embodiment 1.

[0016] Figure 10 This is an explanatory diagram showing an example of an ECU gauge.

[0017] Figure 11 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 2.

[0018] Figure 12 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 2.

[0019] Figure 13 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 2.

[0020] Figure 14 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device and the vehicle-mounted ECU to be updated in Embodiment 2.

[0021] Figure 15This is a flowchart illustrating the transmission control process of the vehicle-mounted device and the vehicle-mounted ECU of the update target in Embodiment 2.

[0022] Figure 16 This is a schematic diagram showing the structure of the vehicle update system in Embodiment 3.

[0023] Figure 17 This is a schematic diagram illustrating the processing flow (timing) of the terminal device, vehicle device, and vehicle ECU of the update target in Embodiment 3.

[0024] Figure 18 This is a block diagram illustrating the physical structure of the vehicle-mounted device and vehicle-mounted ECU in Embodiment 4.

[0025] Figure 19 This is a schematic diagram illustrating the processing flow (timing) of the vehicle-mounted device and the multiple vehicle-mounted ECUs of the updating object according to Embodiment 3.

[0026] Figure 20 This is a flowchart illustrating the connection between the transmission control processing and the program update processing of the vehicle-mounted device in Embodiment 4. Detailed Implementation

[0027] [The problem this disclosure aims to solve]

[0028] However, Patent Document 1 does not take into account the reduction in the time spent by the vehicle device in sending the control program to be updated (update program) to the vehicle ECU.

[0029] This disclosure was made in view of the following circumstances, and its purpose is to provide an in-vehicle system, etc., that shortens the time when the in-vehicle device sends an update program to the in-vehicle ECU.

[0030] [The Effects of This Disclosure]

[0031] In one embodiment of the vehicle update system disclosed herein, the time required for the vehicle device to send an update program to the vehicle ECU can be shortened.

[0032] [Description of embodiments of this disclosure]

[0033] First, embodiments of this disclosure will be described by way of example. Additionally, at least some of the embodiments described below may be combined arbitrarily.

[0034] (1) An in-vehicle update system according to one aspect of the present disclosure includes an in-vehicle ECU and an in-vehicle device, wherein the in-vehicle ECU is mounted on a vehicle, the in-vehicle device receives an update program sent from a program providing device, and processes the program for updating the in-vehicle ECU, wherein the in-vehicle device sends the update program sequentially to the in-vehicle ECU in the form of blocks divided according to a predetermined size, and the in-vehicle ECU, upon receiving the blocks, sequentially stores the received blocks in a 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 working area, and even while the in-vehicle ECU is performing post-processing on the blocks stored in the memory, the in-vehicle device will send the next block in the next order of the blocks being post-processed to the in-vehicle ECU.

[0035] In this method, the on-board device of the vehicle update system obtains the update program of the vehicle ECU from an external server and divides the obtained update program into multiple blocks. The on-board device sends the divided blocks sequentially (e.g., first block, second block, third block, etc.) to the vehicle ECU. The vehicle ECU stores the received update program blocks in memory, performs post-processing on the stored blocks (decoding, decompression, differential application, etc., or partial application to the update target program, etc.), thereby applying the update program involved in that block to the vehicle ECU for updating. That is, the update program is applied and updated in stages in the vehicle ECU. It should be noted that the blocks received by the vehicle ECU are stored in the memory area until the post-processing is completed (end). For example, after the vehicle ECU stores the first block in memory, the on-board device sends the next block (second block) to the vehicle ECU. The vehicle ECU can store the second block in a different area than the area where the first block is stored while the first block is being processed, and then begin processing the stored second block. In this way, even while the vehicle ECU is processing the next block (block n), the vehicle device can send the next block (block n+1) to the vehicle ECU, thus enabling the sending of update program blocks at short intervals and reducing the time spent sending update programs. It should be noted that the vehicle device can also be connected via wired connection to a maintenance device such as a diagnostic tool that stores update programs, and receive update programs from that device.

[0036] (2) In an on-board update system according to one aspect of the present disclosure, the on-board device stops sending the block when the free capacity of the memory of the on-board ECU falls below a first predetermined value.

[0037] In this method, from the time the block is received from the vehicle ECU until it is applied, the block occupies a region of the memory, and the available capacity of the memory decreases. Afterwards, when the block is applied (post-processing completes normally), the data associated with that block in the memory is deleted, the occupied (secured / allocated) region is released, and the available capacity increases. It should be noted that the vehicle ECU can also retry post-processing in the event of an abnormal termination. By stopping the transmission of blocks when the capacity of the vehicle ECU's memory falls below a first predetermined value, the vehicle device can send update program blocks at short intervals until the capacity of the vehicle ECU's memory decreases. Furthermore, it can prevent the transmission of blocks from the vehicle device when there is no area in the memory available for storing blocks, or when space is limited.

[0038] (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 the blocks to be received, and the in-vehicle ECU performs post-processing on the blocks stored in the buffers by using the buffers as working areas. Even while the in-vehicle ECU is performing post-processing on the blocks stored in the buffers, the in-vehicle device will send the next block in the next order of the blocks being post-processed to the in-vehicle ECU.

[0039] In this method, the memory area of ​​the vehicle ECU is divided into multiple buffers capable of storing a specified amount of data, with each buffer capable of storing one block. The buffers also serve as working areas for post-processing one block, and the amount of data (capacity) that a buffer can store is slightly larger than the data size of a block (e.g., 1.2 times the data size of a block). It should be noted that when a specified number of blocks (e.g., 5) are sent in groups from the vehicle device to the vehicle ECU, the buffers may also have the capacity to store these 5 blocks. In this case, the group of 5 blocks can also be equivalent to one block (processing unit block) as a processing unit corresponding to one buffer. That is, the buffer capacity is greater than or equal to the value obtained by multiplying the data size of the block, the number of blocks per processing unit, and the coefficient used for post-processing (work). Even while the vehicle ECU is performing post-processing on a block stored in the buffer, the vehicle device will send the next block in the next order of the blocks being post-processed to the vehicle ECU, thereby enabling the sending of update program blocks at shorter intervals.

[0040] (4) In an on-board update system according to one aspect of the present disclosure, the on-board ECU receives the next block while performing post-processing on the block stored in the buffer, and the on-board ECU stores the next block in a different buffer than the buffer storing the block in which post-processing is being performed.

[0041] In this method, the memory area of ​​the vehicle ECU is divided into multiple buffers capable of holding a specified amount of data, with each buffer capable of holding one block. While the vehicle ECU is performing post-processing on the block stored in the buffer, it receives the next block and stores it in a different buffer than the one storing the block currently undergoing post-processing. This allows the vehicle ECU to receive blocks sent from the vehicle device at shorter intervals, thus reducing the time required for sending update programs from the vehicle device to the vehicle ECU.

[0042] (5) 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 the block to be received, the in-vehicle ECU performs post-processing on the block stored in the buffer by using the buffer as a working area, the in-vehicle ECU deletes the block from the buffer after performing post-processing on the block stored in the buffer, and the free capacity of the memory of the in-vehicle ECU corresponds to the number of buffers among the plurality of buffers that do not store the block.

[0043] In this method, the vehicle ECU stores blocks received from the vehicle-mounted device in a buffer of the memory. The vehicle ECU uses the buffer as a working area to perform post-processing on the blocks stored in the buffer. After post-processing (completion), the post-processed blocks are deleted from the buffer. Thus, the buffer becomes an empty buffer without stored blocks, allowing the vehicle ECU to store newly received blocks in the empty buffer. That is, when blocks are stored in the buffer, the available memory capacity decreases; when blocks are deleted from the buffer, the available memory capacity increases. It should be noted that deleting blocks from the buffer can also include attribute changes such as write flags that allow overwriting while retaining the data stored in the buffer.

[0044] (6) In an in-vehicle update system according to one aspect of the present disclosure, after the in-vehicle ECU performs post-processing on the block stored in the memory, it deletes the block from the memory, and the in-vehicle device starts sending the block when the free capacity of the memory of the in-vehicle ECU becomes a second predetermined value or more.

[0045] In this method, after restoring the block stored in the memory, the vehicle ECU deletes the block from the memory, thereby releasing the area occupied by the block. This increases the memory capacity. When the free capacity of the vehicle ECU's memory becomes a second predetermined value or higher (increases), the vehicle device starts (restarts) sending blocks to the vehicle ECU, thereby shortening the time for sending update programs. The second predetermined value is a value larger than the first predetermined value. It should be noted that the first and second predetermined values ​​can also be the same, but in this case, if the free capacity of memory 41 is less than the predetermined value, the sending of blocks by the vehicle device 3 is stopped.

[0046] (7) In an in-vehicle update system according to one aspect of the present disclosure, after storing the block in the memory, the vehicle ECU sends a signal to the vehicle device requesting the transmission of the next block in the next order before the post-processing of the block stored in the memory is completed.

[0047] In this method, after the on-board ECU stores the received block in its memory, before completing the post-processing of that block, it sends a signal requesting the next block of the stored block to the on-board device during the update program. Therefore, the on-board device can send blocks to the on-board ECU at short intervals without waiting while the on-board ECU is post-processing previously received blocks, thus shortening the time for sending the update program. Furthermore, the on-board ECU 4 can perform post-processing on multiple blocks in parallel or concurrently.

[0048] (8) In an in-vehicle update system according to one aspect of the present disclosure, the in-vehicle ECU sends a signal to the in-vehicle device requesting to stop the transmission of the block when the free capacity of the memory becomes below a first predetermined value.

[0049] In this method, the vehicle ECU monitors the available capacity of the memory. When the vehicle ECU detects that the available capacity of the memory has fallen below a first predetermined value, it requests the vehicle device to stop sending blocks, thereby preventing the sending of blocks from the vehicle device when there is no area in the memory available for storing blocks.

[0050] (9) In an in-vehicle update system according to one aspect of the present disclosure, the in-vehicle device establishes two connections with the in-vehicle ECU, in one connection transmitting the block from the in-vehicle device to the in-vehicle ECU, and in the other connection transmitting a signal from the in-vehicle ECU to the in-vehicle device requesting the cessation of transmitting the block.

[0051] In this method, the vehicle-mounted device establishes two connections with the vehicle-mounted ECU. In one connection, the vehicle-mounted device transmits blocks to the vehicle-mounted ECU, and the vehicle-mounted ECU transmits signals requesting the transmission of other (next) blocks to the vehicle-mounted device. In the other connection, the vehicle-mounted ECU transmits signals requesting the vehicle-mounted device to stop transmitting blocks. Therefore, even while a block is being transmitted or a signal requesting the transmission of a block is being transmitted, the vehicle-mounted ECU can send a signal requesting the vehicle-mounted device to stop transmitting blocks if it detects that the available memory capacity has fallen below a first predetermined value.

[0052] (10) In an in-vehicle update system according to one aspect of the present disclosure, when the free capacity of the memory becomes a second predetermined value or more, the in-vehicle ECU sends a signal requesting the start of the transmission of the block to the in-vehicle device.

[0053] In this method, the on-board ECU monitors the available capacity of the memory (the number of free buffers). When the available capacity of the memory reaches or exceeds a second predetermined value, the on-board ECU requests the start (restart) of block transmission from the on-board device, thereby enabling it to receive update program blocks again. It should be noted that the signal for the start (restart) of block transmission from the on-board ECU to the on-board device is, for example, generated in a separate connection.

[0054] (11) In an in-vehicle update system according to one aspect of the present disclosure, the in-vehicle device obtains information related to the free capacity of the memory of the in-vehicle ECU, and if the free capacity of the memory is below a first predetermined value, the in-vehicle device stops sending the block.

[0055] In this method, the vehicle-mounted device periodically sends a signal to the vehicle-mounted ECU inquiring about the available memory capacity of the ECU. Upon receiving the signal inquiring about available capacity, the vehicle-mounted ECU sends information related to the available memory capacity (the numerical value of the available capacity) to the vehicle-mounted device. The vehicle-mounted device determines whether the received (acquired) available memory capacity of the vehicle-mounted ECU is below a first predetermined value. If it is below the first predetermined value, it stops sending blocks to the vehicle-mounted ECU. Thus, when there is no area in the vehicle-mounted ECU's memory available for storing blocks, it is possible to prevent the transmission of blocks from the vehicle-mounted device. It should be noted that the information related to the available memory capacity can also be information indicating whether the memory can store blocks (for example, a flag value indicating that storage is possible is represented by 0, and that storage is full is represented by 1).

[0056] (12) In an in-vehicle update system according to one aspect of the present disclosure, the in-vehicle device establishes two connections with the in-vehicle ECU. In one connection, the transmission of the block from the in-vehicle device to the in-vehicle ECU and the transmission of a signal from the in-vehicle ECU to the in-vehicle device requesting the transmission of the next block in the next sequence are performed. In the other connection, the transmission of a signal from the in-vehicle device to the in-vehicle ECU inquiring about the available capacity of the memory and the transmission of information from the in-vehicle ECU to the in-vehicle device related to the available capacity of the memory are performed.

[0057] In this method, the vehicle-mounted device and the vehicle-mounted ECU establish, for example, two connections. In one connection, the vehicle-mounted device transmits blocks to the vehicle-mounted ECU, and signals from the vehicle-mounted ECU requesting the transmission of other (next) blocks are transmitted to the vehicle-mounted device. In the other connection, the vehicle-mounted device transmits signals inquiring about available capacity to the vehicle-mounted ECU, and signals from the vehicle-mounted ECU to the vehicle-mounted device regarding available capacity are transmitted. Therefore, even while a block transmission or a signal requesting block transmission is in progress, the query for available capacity from the vehicle-mounted device to the vehicle-mounted ECU can be performed. Furthermore, when the vehicle system has multiple vehicle-mounted ECUs capable of communicating with the vehicle-mounted device, the vehicle-mounted device can store predetermined values ​​(a first predetermined value and a second predetermined value) for the available capacity of each vehicle-mounted ECU, and can determine whether to stop transmitting blocks to the vehicle-mounted ECU based on the predetermined value corresponding to the vehicle-mounted ECU.

[0058] (13) In one aspect of the vehicle update system of the present disclosure, the vehicle device begins to send the block when the free capacity of the memory is above a second predetermined value.

[0059] In this method, even after ceasing the transmission of blocks to the vehicle ECU, the on-board device periodically sends a signal to the vehicle ECU inquiring about the available memory capacity of the vehicle ECU. Upon receiving the signal inquiring about available memory capacity, the vehicle ECU sends its available memory capacity to the on-board device. The on-board device determines whether the received (obtained) available memory capacity of the vehicle ECU is greater than or equal to a second predetermined value. If it is greater than or equal to the second predetermined value, the on-board device begins (restarts) the transmission of blocks to the vehicle ECU. Thus, the on-board device can start (restart) the transmission of blocks to the vehicle ECU when the available memory capacity of the vehicle ECU becomes (increases) to or exceeds the second predetermined value, thereby shortening the time required to send update programs.

[0060] (14) An in-vehicle device of one aspect of the present disclosure receives an update program sent from an external server outside the vehicle and performs processing for updating a program of an in-vehicle ECU mounted in the vehicle, wherein the update program is sent sequentially to the in-vehicle ECU in the form of blocks divided according to a predetermined size, and in the in-vehicle ECU, even while post-processing of the blocks stored in the memory is being performed by using at least a portion of the area of ​​the memory storing the blocks received sequentially by the in-vehicle ECU as a working area, the next block in the next order of the blocks being post-processed is sent to the in-vehicle ECU.

[0061] In this method, the on-board device will send the next block of the next sequence to the on-board ECU even while the on-board ECU is performing post-processing for the block. Therefore, it is possible to send the update program block at short intervals and shorten the time when sending the update program.

[0062] (15) One aspect of the vehicle ECU of this disclosure is a vehicle ECU mounted in a vehicle, wherein an vehicle device that has received an update program sent from an external server outside the vehicle receives the update program sequentially in the form of blocks divided according to a predetermined size, and upon receiving the block, stores the received block in a memory, uses at least a portion of the memory as a working area, thereby performing post-processing on the block stored in the memory, and even while performing post-processing on the block stored in the memory, receives from the vehicle device the next block in the next order of the block being post-processed.

[0063] In this method, the vehicle ECU can receive the next block as the next in the sequence even while performing post-processing for the block. Therefore, the vehicle device can send program blocks to the vehicle ECU at short intervals, which can shorten the time when sending updated programs.

[0064] (16) An in-vehicle update system according to one aspect of the present disclosure includes: an in-vehicle ECU mounted in a vehicle; and an in-vehicle device that receives an update program sent from a program providing device and processes the program for updating the in-vehicle ECU, wherein the in-vehicle device sends the update program sequentially to the in-vehicle ECU in the form of blocks divided according to a predetermined size, and the in-vehicle ECU, upon receiving the blocks, sequentially stores the received blocks in a 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 working area, and the in-vehicle device sends the next block in the next order of the blocks being post-processed to the in-vehicle ECU even while the in-vehicle ECU is performing post-processing on the blocks stored in the memory.

[0065] In this method, the on-board unit of the vehicle update system obtains the update program for the on-board ECU from the program providing device. The program providing device may include a terminal device such as an external server, factory tool, or diagnostic tool. The program providing device sends the blocks obtained by dividing the update program to the on-board unit. It should be noted that, alternatively, the program providing device may send the update program before division to the on-board unit, and the on-board unit may divide the obtained update program into multiple blocks. The on-board unit sends the divided blocks sequentially (e.g., the first block, the second block, the third block, etc.) to the on-board ECU (Electronic Control Unit). The on-board ECU stores the received update program blocks in its memory, performs post-processing on the stored blocks (decoding, decompression, differential application, etc., or partial application to the update target program, etc.), thereby applying the update program involved in that block to the on-board ECU for updating. That is, the update program is applied and updated in stages in the on-board ECU. It should be noted that the blocks received by the on-board ECU are stored in the memory area until the post-processing is completed (end). For example, after the vehicle ECU stores the first block in memory, the on-board device sends the next block (the second block) to the vehicle ECU. The vehicle ECU can, while executing post-processing of the first block, store the second block in a different area than the area where the first block is stored, and begin post-processing of the stored second block. In this way, even while the vehicle ECU is executing post-processing for a block (the nth block), the on-board device will send the next block (the (n+1)th block) in the next sequence to the vehicle ECU, thus enabling the sending of update program blocks at short intervals and reducing the time spent sending update programs. It should be noted that the on-board device can also receive diagnostic processing instructions from a program providing device.

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

[0067] In this method, the on-board device can obtain updates from the outside via an external network.

[0068] (18) An in-vehicle update system according to one aspect of the present disclosure includes a plurality of said in-vehicle ECUs, wherein the in-vehicle device, when stopping the transmission of the block for one of the plurality of in-vehicle ECUs, begins to transmit the block of the update program to be applied to the other in-vehicle ECUs that are different from said one in-vehicle ECU.

[0069] In this method, when an on-board unit (OTU) has no available capacity and cannot receive new blocks, it sends blocks to other OTUs. It should be noted that the blocks sent to other OTUs are segments of the update program to be applied to those OTUs, and are different from the update program to be applied to OTUs that have stopped sending blocks. That is, the OTU can also obtain the respective update programs to be applied to each of the multiple OTUs from the program providing device while processing updates for each of the OTUs' individual programs. Therefore, the OTU can perform processing for other OTUs without waiting for available capacity in the OTUs, effectively performing at least a portion of the processing for multiple OTUs in parallel, thus shortening the time until processing for multiple OTUs is completed.

[0070] (19) In an in-vehicle update system according to one aspect of the present disclosure, when the free capacity of the memory is below a first predetermined value, the in-vehicle ECU sends a signal requesting the cessation of the transmission of the block to the in-vehicle device; when the free capacity of the memory is above a second predetermined value, the in-vehicle ECU sends a signal requesting the start of the transmission of the block to the in-vehicle device; when the in-vehicle device receives the signal requesting the cessation of the transmission of the block from the in-vehicle ECU, it starts the transmission of the block for the in-vehicle ECU that sent the signal requesting the start of the transmission of the block from other in-vehicle ECUs that are different from the in-vehicle ECU.

[0071] In this method, the on-board device can determine whether each of the multiple on-board ECUs can receive the block. Therefore, by identifying the on-board ECU capable of receiving the block and processing the block transmission for that ECU, standby time can be prevented, and the time until processing for multiple on-board ECUs is completed can be shortened.

[0072] (20) An in-vehicle update system according to one aspect of the present disclosure includes: an in-vehicle ECU mounted in a vehicle; and an in-vehicle device that receives an update program sent from a program providing device and processes the program for updating the in-vehicle ECU, wherein the in-vehicle device establishes two connections with the in-vehicle ECU.

[0073] In this method, the on-board device and the on-board ECU establish, for example, two connections. In one connection, the on-board device sends an update program block to the on-board ECU and sends signals requesting the transmission of other (next) blocks from the on-board ECU to the on-board device. In the other connection, the on-board device sends a signal inquiring about available capacity to the on-board ECU and sends signals regarding available capacity from the on-board ECU to the on-board device. Therefore, even while a block is being transmitted or a signal requesting a block is being sent, the query for available capacity from the on-board device to the on-board ECU can be performed. This reduces the time required for the on-board device to send the update program to the on-board ECU.

[0074] [Details of the embodiments of this disclosure]

[0075] This disclosure will be specifically described based on the accompanying drawings illustrating embodiments thereof. Hereinafter, the vehicle-mounted device 3 according to embodiments of this disclosure will be described with reference to the accompanying drawings. It should be noted that this disclosure is not limited to these examples, and as indicated by the claims, it is intended to include all modifications within the meaning and scope equivalent to the claims.

[0076] (Implementation Method 1)

[0077] The embodiments will now be described with reference to the accompanying drawings. Figure 1 This is a schematic diagram showing the structure of the vehicle update system S. Figure 2 This is a block diagram illustrating the physical structure of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 according to Embodiment 1. The vehicle-mounted update system S includes an external communication device 1 and the vehicle-mounted device 3 (update device) installed in the vehicle C, and sends an update program obtained from an external server S1 (program providing device, OTA server) connected via an external network N to the vehicle-mounted ECU 4 (Electronic Control Unit) installed in the vehicle C. In addition, the vehicle-mounted update system S includes a communication line (in-vehicle communication line 51) on the vehicle-mounted ECU side connected to the vehicle-mounted device 3 and the vehicle-mounted ECU 4 (ECU), and a communication line (out-of-vehicle communication line 52) on the external server side connected to the vehicle-mounted device 3 and the external communication device 1.

[0078] The external server S1 is, for example, a computer connected to an external network N such as the Internet or a public bus network. It has a storage unit S11 composed of RAM (Random Access Memory), ROM (Read Only Memory), or a hard disk, and functions as an external program provider. In the external server S1, programs or data used to control the vehicle ECU4, manufactured by the manufacturer of the vehicle ECU4, are stored in the storage unit S11. This program or data, as an update program, is sent to the vehicle C as described later to update the program or data of the vehicle ECU4 installed in the vehicle C. This external server S1 (program provider) is also called an OTA (Over-The-Air) server.

[0079] The on-board unit 3 functions as an OTA (Over-The-Air) host, sending an activation instruction. This activation instruction is used to send an update program obtained from the external server S1 to the on-board ECU 4, the target of the update, and to apply the sent update program to the on-board ECU 4. The on-board ECU 4, installed in vehicle C, obtains the update program sent wirelessly from the external server S1 via the on-board unit 3, applies the update program according to the activation instruction (activation process), thereby updating (reprogramming) the program executed by this ECU. It should be noted that the on-board unit 3 can also be connected to maintenance devices such as diagnostic tools via a wired connection. When the on-board unit 3 is connected to a diagnostic tool, the on-board unit 3 can, for example, obtain the update program stored in the diagnostic tool through communication using the UDS (Unified Diagnostic Service) protocol.

[0080] The following description assumes that the program includes program code containing control syntax for processing by the vehicle ECU 4, and an external file containing data referenced when executing the program code. When sending an update program, the external file containing this program code and data is sent from the external server S1, for example, as an encrypted archive file. When sending the update program, the external server S1 generates a data packet containing the update program and sends the generated data packet to the vehicle C. The data packet includes, for example, information related to the program update, i.e., data packet information (activity information), information related to the vehicle ECU 4 to be updated (target information), and the update program applied to the vehicle ECU 4 to be updated.

[0081] Vehicle C is equipped with an external communication device 1, an on-board device 3, a display device (not shown), and multiple on-board ECUs 4 for controlling various on-board devices. The external communication device 1 and the on-board device 3 are connected in a communicable manner, for example, via a wiring harness such as a serial cable. The on-board device 3 and the on-board ECUs 4 are connected in a communicable manner through an on-board network 5 that corresponds to communication protocols such as Ethernet (registered trademark) or CAN (Control Area Network).

[0082] The external communication device 1 includes an external communication unit (not shown) and an input / output (I / F) (interface) for communicating with the onboard device 3. The external communication unit is a communication device for wireless communication using mobile communication protocols such as LTE (registered trademark), 4G, 5G, and WiFi (registered trademark), and transmits and receives data with an external server S1 via an antenna 11 connected to the external communication unit. Communication between the external communication device 1 and the external server S1 is conducted, for example, via an external network N such as a public bus network or the Internet.

[0083] The input / output (I / F) of the external communication device 1 is a communication interface for, for example, serial communication with the on-board device 3. The external communication device 1 and the on-board device 3 communicate with each other via a wiring harness such as a serial cable connected between the input / output I / F. In this embodiment, the external communication device 1 is a device different from the on-board device 3, and these devices are connected in a communicative manner via the input / output I / F, but this is not a limitation. The external communication device 1 may also be a component of the on-board device 3 and built into it. Alternatively, the external communication device 1 and the on-board device 3 may be connected via an on-board network 5 such as Ethernet.

[0084] The vehicle-mounted device 3 is, for example, a gateway (vehicle relay device) that relays communication between multiple systems, including the vehicle-mounted ECU 4 of the control system, the vehicle-mounted ECU 4 of the safety system, and the vehicle-mounted ECU 4 of the body system. Specifically, the vehicle-mounted device 3 is connected to in-vehicle communication lines 51 that constitute these multiple buses (segments), forming a vehicle network 5. The vehicle-mounted device 3 functions as an Ethernet gateway in Ethernet protocol relays and as a Layer 2 or Layer 3 switch in TCP / IP protocol relays. The vehicle-mounted device 3 can also function as a power distribution device (PLB: Power LAN Box) that distributes and relays power from power sources such as secondary batteries and supplies power to in-vehicle components such as actuators connected to it, in addition to its communication-related relay functions. Alternatively, the vehicle-mounted device 3 can be a functional unit of the body ECU that controls the entire vehicle C. Alternatively, the vehicle-mounted device 3 may be an integrated ECU, which is composed of a central control device such as a vehicle computer and performs overall control of the vehicle C.

[0085] The vehicle-mounted device 3 includes a device control unit 30, a storage unit 31, and an in-vehicle communication unit 32. The vehicle-mounted device 3 is configured to receive an update program (data packet) from an external communication device 1 via wireless communication from an external server S1, preprocess the update program (segmentation or compression, etc.) via the vehicle network 5, and send the update program to the designated vehicle ECU 4 (the vehicle ECU 4 to be updated) in the form of blocks divided according to a predetermined size. In other words, the vehicle-mounted device 3 functions as an OTA (Over-The-Air) host (reprogramming host) that controls the program updates in the vehicle ECU 4 to be updated.

[0086] The device control unit 30 of the vehicle-mounted device 3 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), etc., and performs various control and calculation processes by reading and executing the device control program P1 (program product) and data pre-stored in the storage unit 31. It should be noted that the device control unit 30 can also be configured to process multiple processes in parallel using multiple CPUs (multi-CPU) or multi-core CPUs.

[0087] The storage unit 31 of the vehicle-mounted device 3 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory. The control program (device control program P1) of the vehicle-mounted device 3 is stored in the storage unit 31. Additionally, the update program obtained from the external server S1 is stored in the storage unit 31. The device control program P1 (program product) stored in the storage unit 31 can also be a program storing a device control program P1 (program product) that can be read from the recording medium 311 that can be read by the vehicle-mounted device 3. Alternatively, the device control program P1 can be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 31.

[0088] The in-vehicle communication unit 32 of the vehicle-mounted device 3 uses an input / output interface employing communication protocols such as Ethernet or CAN. The device control unit 30 communicates with in-vehicle devices such as the vehicle-mounted ECU 4 or other relay devices connected to the in-vehicle network 5 via the in-vehicle communication unit 32. Multiple in-vehicle communication units 32 are provided (four in this embodiment), and three of the four in-vehicle communication units 32 are respectively connected to in-vehicle side communication lines 51 (segments) constituting the in-vehicle network 5. By providing multiple in-vehicle communication units in this way, the in-vehicle network 5 is divided into multiple segments. For example, according to the function of the vehicle-mounted ECU 4 (control system function, safety system function, body system function), each vehicle-mounted ECU 4 is connected to each segment. The in-vehicle communication units 32 that are not connected to in-vehicle side communication lines 51 are connected to external communication lines 52, and these in-vehicle communication units communicate with the external communication device 1 via the external communication lines 52. It should be noted that... Figure 2 The image shows an in-vehicle communication unit 32 connected to an in-vehicle communication line 51 and an in-vehicle communication unit 32 connected to an out-of-vehicle communication line 52.

[0089] The vehicle-mounted ECU 4 includes an ECU control unit 40, a memory (main memory) 41, an auxiliary memory 42, and an in-vehicle communication unit 43. The vehicle-mounted ECU 4 is configured to post-process (decode, decompress, perform differential application, or partially apply to the update target program, etc.) the update program received from the vehicle-mounted device 3, and then apply the update program to itself. In other words, the vehicle-mounted ECU 4 functions as an OTA (Over-The-Air) target (reprogramming target) for program updates controlled by the vehicle-mounted device 3.

[0090] The ECU control unit 40 of the vehicle ECU 4 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), etc. It reads and executes the ECU control program P2 (program product) and data pre-stored in the auxiliary storage unit 42 to perform various control and calculation processes. It should be noted that the ECU control unit 40 can also be configured to process multiple processes in parallel through multiple CPUs (multi-CPU) or multi-core CPUs.

[0091] The memory 41 of the vehicle ECU 4 is, for example, composed of RAM. The memory 41 stores blocks of update programs received by the vehicle ECU 4 from the vehicle-mounted device 3. The ECU control unit 40 performs post-processing on the blocks stored in the memory 41, and the post-processed blocks are deleted from the memory 41 (volatile). It should be noted that the memory 41 can store different blocks in multiple regions (buffers 411), and the ECU control unit 40 can perform post-processing on blocks stored in multiple regions in parallel. It should also be noted that the regions or buffers of the memory 41 can be defined by the range of physical or logical address values ​​in the memory 41.

[0092] The auxiliary storage unit 42 of the vehicle ECU 4 is composed of non-volatile memory elements such as rewritable ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory. The control program (ECU control program P2) of the vehicle ECU 4 is stored in the auxiliary storage unit 42. Furthermore, the ECU control program P2 (program product) stored in the auxiliary storage unit 42 is sent from the vehicle device 3, post-processed by the ECU control unit 40, and then stored in the auxiliary storage unit. That is, the ECU control program P2 is a program that is subject to updating.

[0093] The in-vehicle communication unit 43 of the vehicle ECU4 uses an input / output interface that employs communication protocols such as Ethernet (Ethernet / registered trademark) or CAN. The vehicle ECU4 communicates with the vehicle device 3 or other vehicle ECU4s via the in-vehicle communication unit 43.

[0094] Figure 3 This is an explanatory diagram showing the changes in the usage status of memory 41. In Figure 3In this diagram, the upper side represents the past, and the lower side represents future points in time. The memory 41 is divided into regions of a predetermined capacity, each region serving as a buffer 411. Each buffer 411 can store blocks received one by one from the vehicle-mounted device 3 by the vehicle ECU 4. Hereinafter, buffers 411 storing blocks are designated as active buffers, and buffers 411 without stored blocks are designated as idle buffers. Furthermore, buffers 411 serve as working areas for the ECU control unit 40 to perform post-processing on the stored blocks. That is, the memory 41 contains multiple buffers 411 with capacities corresponding to the amount of data in the received blocks. It should be noted that since buffers 411 are used as working areas for post-processing of the stored blocks, the capacity of each buffer 411 is slightly larger than the amount of data in the received blocks (for example, 1.2 times the amount of data in the blocks). Additionally, when a received block can be stored in any buffer 411 within the idle buffers, the capacity of each buffer 411 is set to the capacity corresponding to the block with the largest amount of data among the predetermined received blocks.

[0095] exist Figure 3 In the example shown, the memory 41 is described as having four buffers 411 (first buffer 411a to fourth buffer 411d). The vehicle ECU 4 receives update program blocks sequentially from the vehicle device 3 in the order of first block, second block, third block, etc. When the vehicle ECU 4 receives the first block, the first block is stored in the first buffer 411a. The first buffer 411a becomes a buffer in use, and the first block stored in the first buffer 411a begins post-processing by the ECU control unit 40. Post-processing includes decoding, decompressing, restoring differential applications, etc., of the block data, or applying a portion of the update target program (ECU control program P2). That is, by post-processing the block, at least a portion of the ECU control program P2 stored in the auxiliary storage unit 42 is updated. The vehicle device 3 sends the next block in sequence before the vehicle ECU 4 completes the post-processing of the block (while executing), so the vehicle ECU 4 receives the second block before the post-processing of the first block is completed.

[0096] The second block received by the vehicle ECU 4 is stored in the second buffer 411b, which serves as an idle buffer. The ECU control unit 40 begins post-processing of the second block in the same manner as the first block. It should be noted that the post-processing of the first block and the post-processing of the second block are performed in parallel. Furthermore, the third block received by the vehicle ECU 4 is stored in the third buffer 411c, which serves as an idle buffer. The ECU control unit 40 begins post-processing of the third block in the same manner as the first and second blocks.

[0097] If the post-processing of the first block is not completed when the memory 41 stores the third block in the third buffer 411c, the number of free buffers in the memory 41 becomes 1. At this time, for example, if the ECU control unit 40 of the vehicle ECU 4 detects that the free capacity of the memory is below a first predetermined value (below the capacity of one buffer 411), it sends a stop signal (stop signal) to the vehicle device 3 requesting the cessation of block transmission. (Ref) Figures 4-6 When the vehicle-mounted device 3 receives a stop signal, it does not send a block to the vehicle-mounted ECU 4 until it receives a start signal (start signal) from the vehicle-mounted ECU 4 requesting the sending of the block.

[0098] When the first block, after post-processing is performed in the first buffer 411a, is removed (released) from the first buffer 411a upon completion of post-processing. It should be noted that removing a block from buffer 411 includes, for example, attribute changes such as setting the data stored in the block in buffer 411 to a write flag that allows overwriting. When the first block is removed, the first buffer 411a becomes an idle buffer. Similarly, when the second block, after post-processing is performed in the second buffer 411b, is removed (released) from the second buffer 411b upon completion of post-processing, the second buffer 411b becomes an idle buffer. When the transmission of the stop block by the vehicle device 3 is completed and the number of idle buffers increases by two, the number of idle buffers in the memory 41 becomes three. At this time, for example, if the ECU control unit 40 of the vehicle ECU 4 detects that the free capacity of the memory is below a second predetermined value (above the capacity of three buffers 411), it sends a stop signal (start signal) to the vehicle device 3 to begin (restart) the transmission of the block. (See reference) Figures 4-6 。 ).

[0099] Upon receiving a start signal from the vehicle ECU 4, the vehicle-mounted device 3 resumes block transmission, sending the fourth block to the vehicle ECU 4. The vehicle ECU 4 stores the received fourth block in the fourth buffer 411d, and the ECU control unit 40 begins post-processing of the fourth block, making the fourth buffer 411d an in-use buffer. Subsequently, the ECU control unit 40 of the vehicle ECU 4 stores the blocks received sequentially by the vehicle ECU 4 in each buffer 411 of the memory 41, and performs post-processing on the stored blocks. It should be noted that the blocks received by the vehicle ECU 4 are stored, for example, in the buffer 411 that has been idle for the longest time. That is, the fifth block is stored, for example, in the first buffer 411a. After completing the post-processing of the blocks, the ECU control unit 40 deletes the blocks from the buffers 411 and sets the in-use buffer to an idle buffer. When the free capacity of the memory 41 of the vehicle ECU 4 is below a first predetermined value (when the number of free buffers is below a first predetermined number), the vehicle device 3 stops sending blocks, and when the free capacity of the memory 41 is above a second predetermined value (when the number of free buffers is above a second predetermined number), the vehicle device 3 starts sending blocks.

[0100] exist Figure 3 In the example shown, the blocks received sequentially by the vehicle ECU4 are stored sequentially starting from the first buffer 411a, but this is not the only example. Figure 3 In the example shown, the number of buffers 411 whose remainders are obtained by dividing n by 4 (the number of buffers 411 contained in memory 41) is called the number of the nth block. However, as long as it is an idle buffer, the block received by the vehicle ECU 4 can be stored in any buffer 411. In addition, the number of buffers 411 included in memory 41 is not limited to 4. Furthermore, the first and second specified values ​​are not limited to the values ​​mentioned above. In the case where memory 41 includes areas other than the area of ​​buffers 411 (the area of ​​storage blocks) (other areas), for example, the first specified value becomes the capacity of the other areas and one buffer 411, and the second specified value becomes the capacity of the other areas and three buffers 411.

[0101] Figures 4-6This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated according to Embodiment 1. The vehicle-mounted device 3 and the vehicle-mounted ECU 4 establish two communication connections, enabling the two communication processes to be executed in parallel or concurrently. The vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated are established, for example, by using different port numbers as destinations in TCP / IP-based communication. It should be noted that, in the case of CAN communication between the vehicle-mounted device 3 and the vehicle-mounted ECU 4, the two connections can also be established by using different CANIDs as destinations. In this embodiment, the vehicle-mounted device 3 and the vehicle-mounted ECU 4 perform both transmission control processing and program update processing. Figures 4-6 The example shown illustrates the following: the update process is divided into 5 blocks. If there are fewer than 1 free buffer, the update process stops; if there are 3 or more free buffers, the update process starts (restarts). Figures 4-6 The number of idle buffers in each processing stage is displayed on the right.

[0102] The device control unit 30 of the vehicle-mounted device 3 receives the update program of the vehicle-mounted 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 sends the first block to the vehicle-mounted ECU 4 (S103).

[0103] The ECU control unit 40 of the vehicle ECU 4 stores the first block received from the vehicle device 3 in the first buffer 411a of the memory 41 (S104). The ECU control unit 40 sends a signal (next order request signal) to the vehicle device 3 requesting to be sent as the next block in the next order of the blocks stored in S104 (S105). The ECU control unit 40 begins post-processing of the first block (S106).

[0104] Upon receiving a next sequence request signal from the vehicle ECU4, the device control unit 30 of the vehicle device 3 generates the next block (second block) of the previously sent block through preprocessing (S107). The device control unit 30 then sends the second block to the vehicle ECU4 (S108).

[0105] The ECU control unit 40 of the vehicle ECU 4 stores the second block received from the vehicle device 3 in the second buffer 411b of the memory 41 (S109). The ECU control unit 40 sends a signal (next order request signal) to the vehicle device 3 requesting to be sent as the next block in the next order of the blocks stored in S109 (S110). The ECU control unit 40 begins post-processing of the second block (S111).

[0106] Upon receiving a next sequence request signal from the vehicle ECU 4, the device control unit 30 of the vehicle device 3 generates the next block (third block) of the previously sent block through preprocessing (S112). The device control unit 30 then sends the third block to the vehicle ECU 4 (S113).

[0107] The ECU control unit 40 of the vehicle ECU 4 stores the third block received from the vehicle device 3 in the third buffer 411c of the memory 41 (S114). The ECU control unit 40 sends a signal (next order request signal) to the vehicle device 3 requesting that the block to be sent be the next block in the next order of the blocks stored in S114 (S115). The ECU control unit 40 begins post-processing of the third block (S116). Upon receiving the next order request signal from the vehicle ECU 4, the device control unit 30 of the vehicle device 3 generates the next block (fourth block) of the last sent block through pre-processing (S117).

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

[0109] The post-processing of the first block, performed in the first buffer 411a, is completed, for example, after the post-processing of the third block begins (S118). Upon completion of the post-processing of the first block, the first block is removed from the first buffer 411a, and the first buffer 411a becomes an idle buffer.

[0110] The post-processing of the second block, performed in the second buffer 411b, is completed, for example, after the post-processing of the third block begins (S119). Upon completion of the post-processing of the second block, the second block is removed from the second buffer 411b, and the second buffer 411b becomes an idle buffer.

[0111] When a block is removed (released) from the first buffer 411a and the second buffer 411b and the first buffer 411a and the second buffer 411b become idle buffers, the ECU control unit 40 of the vehicle ECU 4 detects in the transmission control process that the free capacity of the memory is more than or equal to the second predetermined value (the capacity of the three buffers 411 is more than or equal to the free capacity) (S204), and sends a signal (start signal) to the vehicle device 3 to start (restart) the transmission of the requested block (S205).

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

[0113] When the transmission control processing begins (restarts), the device control unit 30 of the vehicle-mounted device 3 sends the fourth block to the vehicle-mounted ECU 4 (S120). The ECU control unit 40 of the vehicle-mounted ECU 4 stores the fourth block received from the vehicle-mounted device 3 in the fourth buffer 411d of the memory 41 (S121). The ECU control unit 40 sends a signal (next order request signal) to the vehicle-mounted device 3 requesting that the block be sent as the next block in the next order of the blocks stored in S121 (S122). The ECU control unit 40 begins post-processing of the fourth block (S123).

[0114] The post-processing of the third block, performed in the third buffer 411c, is completed, for example, after the post-processing of the fifth block begins (S124). Upon completion of the post-processing of the third block, the third block is removed from the third buffer 411c, and the third buffer 411c becomes an idle buffer.

[0115] Upon receiving a next sequence request signal from the vehicle ECU 4, the device control unit 30 of the vehicle-mounted device 3 generates the next block (the fifth block) of the previously sent block through preprocessing (S125). The device control unit 30 then sends the fifth block to the vehicle ECU 4 (S126), ending the processing.

[0116] The ECU control unit 40 of the vehicle ECU 4 stores the fifth block received from the vehicle device 3 in the first buffer 411a of the memory 41 (S127). The ECU control unit 40 sends a signal (next order request signal) to the vehicle device 3 requesting that the block be sent as the next block in the next order of the block stored in S127 (S128). The ECU control unit 40 begins post-processing of the fifth block (S129). It should be noted that the device control unit 30 of the vehicle device 3 may also send the signal to the vehicle ECU 4 by including, for example, a flag indicating that the last block is the last block in the last block included in the update program (the fifth block in this example). In this case, the ECU control unit 40 of the vehicle ECU 4 that receives the block containing the flag may not send the next order request signal to the vehicle device 3.

[0117] The post-processing of the fourth block, performed in the fourth buffer 411d, is completed, for example, after the post-processing of the fifth block begins (S130). Upon completion of the post-processing of the fourth block, the fourth block is removed from the fourth buffer 411d, and the fourth buffer 411d becomes an idle buffer.

[0118] The post-processing of the fifth block, which is performed 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 removed from the first buffer 411a, and the first buffer 411a becomes an idle buffer.

[0119] Figure 7 This is a flowchart illustrating the program update process of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated according to Embodiment 1. The device control unit 30 of the vehicle-mounted device 3 receives the update program of the vehicle-mounted ECU 4 from the external server S1 (S31). A block is generated by preprocessing the received update program (S32). The device control unit 30 sends the generated block to the vehicle-mounted ECU 4 (S33). It should be noted that before sending the first block (first block) of the update program, the free capacity of the memory 41 of the vehicle-mounted ECU 4 is greater than a first predetermined value. Therefore, the device control unit 30 of the vehicle-mounted device 3 sends the first block to the vehicle-mounted ECU 4 without checking the free capacity of the memory 41.

[0120] The ECU control unit 40 of the vehicle ECU 4 receives a block from the vehicle device 3 (S34) and stores the received block in the buffer 411 of the memory 41 (S35). The ECU control unit 40 sends a next sequence request signal to the vehicle device 3 (S36). The ECU control unit 40 starts the post-processing subroutine (generation subroutine) of the block stored in S35 (S37). It should be noted that even in the post-processing subroutine of the block (refer to...), the ECU control unit 40... Figure 8If the process is not completed, and the next block is received from the on-board unit 3, the cycle of S34 to S37 can be executed on that next block. That is, the ECU control unit 40 can perform post-processing on multiple blocks in parallel.

[0121] The device control unit 30 of the vehicle-mounted device 3 receives a next sequence request signal from the vehicle-mounted ECU 4 (S38). The vehicle-mounted ECU 4 determines whether all blocks of the update program have been sent (S39). If not all blocks have been sent (S39: No), processing returns to S32, and processing continues for the next block that becomes the next sequence. It should be noted that in this case, along with the device control unit 30 of the vehicle-mounted device 3 returning to processing, the processing of the ECU control unit 40 of the vehicle-mounted ECU 4 also returns to S34. If all blocks have been sent (S39: Yes), the device control unit 30 of the vehicle-mounted device 3 ends processing.

[0122] Figure 8 This is a flowchart illustrating the post-processing subroutine of the block of the vehicle ECU 4, which is being updated. The ECU control unit 40 of the vehicle ECU 4 decodes the block stored in the buffer 411 of the memory 41 (S371) and decompresses the decoded block (S372). The ECU control unit 40 applies the decompressed block to the ECU control program P2 (the program for updating the target) stored in the auxiliary storage unit 42 (S373). The ECU control unit 40 deletes the block from the buffer 411 (memory 41) of the memory 41 (S374) and terminates the subroutine. When a block is deleted from the buffer 411 of the memory 41, the buffer 411 becomes an idle buffer. It should be noted that the ECU control unit 40 of the vehicle ECU 4 can also measure the free capacity (number of free buffers) of the memory 41 based on the number of currently executing subroutines (subprocesses).

[0123] Figure 9 This is a flowchart illustrating the transmission control process of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated according to Embodiment 1. The ECU control unit 40 of the vehicle-mounted ECU 4 measures the free capacity of the memory 41 (S41). The ECU control unit 40 determines whether the free capacity measured in S41 is below a first predetermined value (S42). If the free capacity is not below the first predetermined value (greater than the first predetermined value) (S42: No), the ECU control unit 40 returns the process to S41. If the free capacity is below the first predetermined value (S42: Yes), the ECU control unit 40 sends a stop signal to the vehicle-mounted device 3 (S43).

[0124] The device control unit 30 of the vehicle-mounted device 3 receives a stop signal from the vehicle-mounted ECU 4 (S44). The device control unit 30 stops sending blocks to the vehicle-mounted ECU 4 (S45). That is, the device control unit 30 stops the program update process (see...) Figure 7 In the process of sending the block to the vehicle ECU4, the process (S33) is not executed, and the program update process is stopped in the stage before S33 is executed.

[0125] The ECU control unit 40 of the vehicle ECU 4 measures the free capacity (number of idle buffers) of the memory 41 (S46). The ECU control unit 40 determines whether the free capacity measured in S46 is greater than or equal to a second predetermined value (S47). If the free capacity is not greater than or equal to the second predetermined value (S47: No), the ECU control unit 40 returns the processing to S46. If the free capacity is greater than or equal to a first predetermined value (S47: Yes), the ECU control unit 40 sends a start signal to the vehicle device 3 (S48) and returns the processing to S41.

[0126] The device control unit 30 of the vehicle-mounted device 3 receives a start signal from the vehicle-mounted ECU 4 (S49). The device control unit 30 begins (re-starts) the transmission of blocks to the vehicle-mounted ECU 4 (S50). That is, the device control unit 30 performs program update processing (see...). Figure 7 The process of sending the block to the vehicle ECU 4 (S33), which was not executed in the previous step, is restarted to resume the program update process. It should be noted that as the ECU control unit 40 of the vehicle ECU 4 returns the process to S41, the device control unit 30 of the vehicle device 3 returns the process to S44.

[0127] Based on the above structure and processing, the vehicle-mounted device 3 can send the next block to the vehicle-mounted ECU 4 even while the vehicle-mounted ECU 4 is post-processing the update program. Block sending stops when the free capacity of the vehicle-mounted ECU 4's memory 41 decreases, and resumes when the free capacity increases. Therefore, update program blocks can be sent at short intervals, reducing the time spent sending the update program. It should be noted that the memory 41 of the vehicle-mounted ECU 4 is divided into buffers 411, with blocks stored in each buffer 411. However, the area in the memory 41 where blocks are stored can be variable.

[0128] (Implementation Method 2)

[0129] In Embodiment 2, the vehicle-mounted device 3 sends a signal (interrogation signal) to the vehicle-mounted ECU 4 at predetermined time intervals, inquiring about the available capacity (number of free buffers) of the memory 41 of the vehicle-mounted ECU 4. Upon receiving the interrogation signal, the vehicle-mounted ECU 4 sends information related to the available capacity of the memory 41 back to the vehicle-mounted device 3. Based on the received information related to the available capacity of the memory 41, the vehicle-mounted device 3 performs transmission control processing.

[0130] Figure 10 This is an explanatory diagram showing an example of an ECU gauge T. The ECU gauge T is stored in the storage unit 31 of the vehicle-mounted device 3 (see reference). Figure 2 The ECU table records a first predetermined value for determining the stop of block transmission to the memory 41 of each of the vehicle ECUs 4 connected to the vehicle-mounted device 3 via the in-vehicle communication line 51, and a second predetermined value for determining the start of block transmission. The management items (fields) of the ECU table include an identification number field, a buffer quantity field, a first predetermined value field, a second predetermined value field, a free capacity field, a transmission status field, and a number of transmitted blocks field.

[0131] The identification number field in ECU table T stores the identification number of each vehicle ECU 4. It should be noted that the identification number of the vehicle ECU 4 can also be represented by an IP address or MAC address, etc. The buffer quantity field stores the number of buffers 411 contained in memory 41 (the maximum number of free buffers). The first predetermined value field stores a first predetermined value indicating the free capacity of memory 41 at which the device control unit 30 of vehicle device 3 stops sending blocks to vehicle ECU 4 that are the target of program updates. The second predetermined value field stores a second predetermined value indicating the free capacity of memory 41 at which the device control unit 30 of vehicle device 3 starts sending blocks to vehicle ECU 4 that are the target of program updates. The free capacity field stores information related to the free capacity of memory 41 of vehicle ECU 4 received by vehicle device 3 from vehicle ECU 4 (the number of free buffers). Whenever vehicle device 3 receives information related to free capacity from vehicle ECU 4, the value stored in the free capacity field is updated. It should be noted that in Figure 8In the example shown, the first specified value, the second specified value, and the free capacity are represented by the number of free buffers, but are not limited to this. The first specified value, the second specified value, and the free capacity can also be represented by the amount of data that the memory 41 can store, for example, in MB. The transmission status field stores whether the vehicle device 3 is stopping the transmission of blocks to the vehicle ECU 4 or is executing the transmission. In the transmission status field, "Stopped" is stored if the vehicle device 3 stops the transmission of blocks and does not restart it, and "Executing" is stored if the vehicle device 3 stops the transmission of blocks for the first time, or if it stops the transmission of blocks and restarts it but does not stop it again. The value stored in the transmission status field is updated when the device control unit 30 of the vehicle device 3 stops or starts (restarts) the transmission of blocks. The number of blocks sent is stored in the number of blocks that the vehicle device 3 has sent to the vehicle ECU 4. It should be noted that the denominator of the "Number of Blocks Sent" field shows the total number of blocks contained in the update program sent to the vehicle ECU 4, while the numerator shows the number of blocks that have been sent to the vehicle ECU 4. The value of the "Number of Blocks Sent" field is updated each time the device control unit 30 sends a block.

[0132] Figures 11-14 This is an explanatory diagram illustrating the processing flow (timing) of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated in Embodiment 2. Figure 9 In the example shown, the following situation is illustrated: the update process is divided into 5 blocks. If the number of free buffers is 1 or less, the update process stops; if the number of free buffers is 3 or more, the update process starts (restarts). It should be noted that in the update process performed by the device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4, the processing is the same as in Embodiment 1. Figures 4-6 The same process as that involved in S101 to S131 shown. In the transmission control process, the device control unit 30 of the vehicle device 3 reads the first and second specified values ​​of the vehicle ECU 4, which is the program update target, from the ECU table T (S601). The device control unit 30 sends a signal (interrogation signal) to the vehicle ECU 4 to inquire about the free capacity (number of free buffers) of the memory 41 of the vehicle ECU 4 (S602).

[0133] The ECU control unit 40 of the vehicle ECU 4, which receives an interrogation signal from the vehicle device 3, measures the free capacity (number of free buffers) of the memory 41 (S603). The ECU control unit 40 sends information related to the measured free capacity (number of free buffers) to the vehicle device 3 (S604).

[0134] The device control unit 30 of the vehicle-mounted device 3, which receives information related to available capacity from the vehicle-mounted ECU 4, determines whether the available capacity of the memory 41 is less than or equal to a first predetermined value (a buffer 411) (S605). In S605, if the available capacity of the memory 41 is greater than the first predetermined value, the device control unit 30 sends an inquiry signal to the vehicle-mounted ECU 4 again after a predetermined time (S606). Thereafter, the device control unit 30 sends an inquiry signal to the vehicle-mounted ECU 4 periodically at predetermined time intervals. It should be noted that the predetermined time interval is, for example, twice the assumed time (preprocessing time) required for the device control unit to generate a block by preprocessing the update program. It should also be noted that if the preprocessing time varies depending on the block, the predetermined time interval may be an average or minimum value of the preprocessing time, etc.

[0135] The device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4 repeat the same processing as in S602 to S605 (S606 to S609 and S610 to S613). It should be noted that in S612, the ECU control unit 40 of the vehicle-mounted ECU 4 sends information indicating that there is one idle buffer to the vehicle-mounted device 3. Therefore, in S613, the device control unit 30 of the vehicle-mounted device 3 determines that the free capacity of the memory 41 is less than or equal to a first predetermined value (one buffer 411). When the device control unit 30 determines that the free capacity of the memory 41 is less than or equal to the first predetermined value (one buffer 411), it stops sending blocks during the program update process (S614).

[0136] Even after the stop block is sent, the device control unit 30 of the vehicle-mounted device 3 periodically sends an inquiry signal to the vehicle-mounted ECU 4. S615 to S617 are the same processes as those in S602 to S604. The device control unit 30 of the vehicle-mounted device 3 determines whether the free capacity of the memory 41 is greater than or equal to the second predetermined value (three buffers 411) (S618). In S618, the free capacity of the memory 41 is less than the second predetermined value, so the device control unit 30 sends an inquiry signal to the vehicle-mounted ECU 4 again after a predetermined time (S619).

[0137] The device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4 repeat the same processing as in S615-S618 (S619-S622). It should be noted that in S621, the ECU control unit 40 of the vehicle-mounted ECU 4 sends information indicating that there are three free buffers to the vehicle-mounted device 3. Therefore, in S622, the device control unit 30 of the vehicle-mounted device 3 determines that the free capacity of the memory 41 is at least the second predetermined value (three buffers 411). When the device control unit 30 determines that the free capacity of the memory 41 is at least the second predetermined value (three buffers 411), it starts (restarts) the transmission of blocks during the program update process (S623).

[0138] The device control unit 30 of the vehicle-mounted device 3 performs the same processing as that involved in S602-605 (S624-627 and S628-S631). Next, if the device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4 determine, in the same processing as in S605, that the free capacity of the memory 41 is below a first predetermined value, they stop sending blocks during the program update process and repeat the same processing as in S615-618. Furthermore, if the device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4 determine, in the same processing as in S618, that the free capacity of the memory 41 is above a second predetermined value, they start (restart) sending blocks during the program update process and repeat the same processing as in S602-605. The device control unit 30 of the vehicle-mounted device 3 and the ECU control unit 40 of the vehicle-mounted ECU 4 repeat the above processing until the program update process is completed.

[0139] Figure 15 This is a flowchart illustrating the transmission control process of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 to be updated in Embodiment 2. The device control unit 30 of the vehicle-mounted device 3 reads the first and second specified values ​​of the vehicle-mounted ECU 4 to be updated from the ECU table T (S71). The device control unit 30 sends an inquiry signal to the vehicle-mounted ECU 4 (S72).

[0140] The ECU control unit 40 of the vehicle ECU 4 receives an interrogation signal from the vehicle device 3 (S73). The ECU control unit 40 measures the free capacity of the memory 41 (number of free buffers) (S74). The ECU control unit 40 sends information related to the measured free capacity (number of free buffers) to the vehicle device 3 (S75).

[0141] The device control unit 30 of the vehicle-mounted device 3 receives information related to the available capacity from the vehicle-mounted ECU 4 (S76). The device control unit 30 determines whether the available capacity of the memory 41 is below a first predetermined value (whether the number of idle buffers is below a first predetermined number) (S77). If the available capacity of the memory 41 is not below the first predetermined value (the available capacity of the memory 41 is greater than the first predetermined value) (S77: No), the device control unit 30 returns the processing to S72. It should be noted that the device control unit 30 sends an inquiry signal again after a predetermined time has elapsed since the last inquiry signal was sent. If the available capacity of the memory 41 is below the first predetermined value (S77: Yes), the device control unit 30 stops sending blocks to the vehicle-mounted ECU 4 (S78). That is, the device control unit 30, during program update processing (see... Figure 7 In step S33, the process of sending the block to the vehicle ECU4 is not executed, and the program update process is stopped in the stage before executing S33. The device control unit 30 sends an interrogation signal to the vehicle ECU4 (S79). It should be noted that the device control unit 30 sends an interrogation signal again after a predetermined time has elapsed since the last interrogation signal was sent.

[0142] The ECU control unit 40 of the vehicle ECU 4 receives an interrogation signal from the vehicle device 3 (S80). The ECU control unit 40 measures the free capacity (number of free buffers) of the memory 41 (S81). The ECU control unit 40 sends information related to the measured free capacity (number of free buffers) to the vehicle device 3 (S82).

[0143] The device control unit 30 of the vehicle-mounted device 3 receives information related to the available capacity from the vehicle-mounted ECU 4 (S83). The device control unit 30 determines whether the available capacity of the memory 41 is greater than or equal to a second predetermined value (whether the number of idle buffers is greater than or equal to a second predetermined number) (S84). If the available capacity of the memory 41 is not greater than or equal to the second predetermined value (the available capacity of the memory 41 is less than the second predetermined value) (S84: No), the device control unit 30 returns the processing to S79. It should be noted that the device control unit 30 sends an inquiry signal again after a predetermined time has elapsed since the last inquiry signal was sent. If the available capacity of the memory 41 is less than or equal to a first predetermined value (S84: Yes), the device control unit 30 starts (restarts) the transmission of blocks to the vehicle-mounted ECU 4 (S85). That is, the device control unit 30 performs the program update process (see...). Figure 7 The process of sending the block to the vehicle ECU 4 that was not executed in S33 will restart the program update process. The device control unit 30 will return the process to S72. It should be noted that along with the device control unit 30 of the vehicle device 3 returning the process to S72, the ECU control unit 40 of the vehicle ECU 4 will return the process to S73.

[0144] Based on the above structure and processing, the vehicle-mounted device 3 can periodically obtain the free capacity of the memory 41 of the vehicle-mounted ECU 4. When the free capacity of the memory 41 of the vehicle-mounted ECU 4 decreases, the transmission of blocks is stopped, and when the free capacity increases, the transmission of blocks is restarted. Therefore, even in the post-processing of the update program, the vehicle-mounted ECU 4 can send the next block to the vehicle-mounted ECU 4. By sending the update program blocks at short intervals, the time for sending the update program can be shortened.

[0145] (Implementation Method 3)

[0146] In Implementation 3, the vehicle-mounted device 3 sends the update program obtained from the terminal device to each vehicle-mounted ECU 4.

[0147] Figure 16 This is a schematic diagram showing the structure of the vehicle-mounted update system S according to Embodiment 3. The vehicle-mounted device 3 of Embodiment 3 is connected to the terminal device S2 and obtains the update program from the terminal device S2.

[0148] The terminal device S2, such as a factory tool or diagnostic tool, is a computer connected to the vehicle-mounted device 3 via a wired connection. It has a storage unit S21 composed of RAM (Random Access Memory), ROM (Read Only Memory), or a hard disk, serving as a program provider either inside or outside the vehicle. In the terminal device S2, programs or data used to control the vehicle-mounted ECU 4, manufactured by the manufacturer of the ECU 4, are stored in the storage unit S21. This program or data is sent to the vehicle-mounted device 3 as an update program to update the program or data of the vehicle-mounted ECU 4 installed in the vehicle C. It should be noted that the terminal device S2 can also communicate with the vehicle-mounted device 3 via an external network N, antenna 11, and external communication device 1. Furthermore, the vehicle-mounted device 3 can also receive diagnostic processing instructions from the terminal device S2.

[0149] Figure 17 This is a schematic diagram illustrating the processing flow (timing) of the terminal device S2, the vehicle-mounted device 3, and the vehicle-mounted ECU 4 to be updated in Embodiment 3. Figure 17 As shown, the vehicle-mounted device 3 establishes two connections with the terminal device S2 and the vehicle-mounted ECU 4, respectively. In this embodiment, the terminal device S2, the vehicle-mounted device 3, and the vehicle-mounted ECU 4 perform two types of processing: transmission control processing and program update processing.

[0150] During the program update process, terminal device S2 sends blocks containing the segmented update program to vehicle-mounted device 3. The device control unit 30 of vehicle-mounted device 3 then sequentially sends the blocks received from terminal device S2 to vehicle-mounted ECU 4. It should be noted that terminal device S2 bases its decisions on the next-order request signal sent from vehicle-mounted ECU 4 during the program update process (see reference...). Figure 4 The vehicle ECU 4's ECU control unit 40 stores the received blocks in a buffer and performs post-processing. If the available memory capacity falls below a first predetermined value, a stop signal is sent to the vehicle device 3 during the transmission control process. Upon receiving the stop signal, the vehicle device 3's device control unit 30 sends a transmission stop request (stop signal) to the terminal device S2. Upon receiving the transmission stop request, the terminal device S2 stops the transmission of blocks.

[0151] The ECU control unit 40 of the vehicle ECU 4 performs post-processing of the received block. If the available memory capacity reaches a second predetermined value or higher, it sends a start signal to the vehicle device 3. Upon receiving the start signal, the device control unit 30 of the vehicle device 3 sends a data request (start signal) to the terminal device S2. Upon receiving the data request, the terminal device S2 resumes block transmission. Subsequently, the terminal device S2, vehicle device 3, and vehicle ECU 4 repeat the same process. As described above, the terminal device S2 and vehicle device 3 establish two connections. Therefore, even while a block is being transmitted from the terminal device S2 to the vehicle device 3, a transmission stop request or data request can be sent from the vehicle device to the terminal device S2. This shortens the time it takes for the terminal device S2 to send an update program to the vehicle device 3.

[0152] In this embodiment, the device control unit 30 of the vehicle-mounted device 3 sends the next sequence request signal, stop signal, and start signal received from the vehicle-mounted ECU 4 to the terminal device S2 as described above. Additionally, the terminal device S2 generates a block based on the next sequence request signal and sends it to the vehicle-mounted device 3. The device control unit 30 of the vehicle-mounted device 3 sends the received block to the vehicle-mounted ECU 4. That is, the terminal device S2 has the same functions as the vehicle-mounted device 3 described in Embodiment 1, and the vehicle-mounted device 3 in this embodiment functions as a relay device that sends programs, data, or signals received from the terminal device S2 to the vehicle-mounted ECU 4 without processing them. It should be noted that when the transmission control processing is performed using the UDS (Unified Diagnostic Service) protocol, the ECU control unit 40 of the vehicle-mounted ECU 4 can send a stop signal or start signal to the vehicle-mounted device 3 by responding to query signals based on the Response on Event function sent from the vehicle-mounted device 3 at predetermined intervals. In addition, the device control unit 30 of the vehicle-mounted device 3 can also receive the undivided update program from the terminal device S2 and generate a block by preprocessing the update program.

[0153] Based on the above structure and processing, the vehicle device 3 can send the next block of the update program received from the terminal device S2 to the vehicle ECU4 even when the vehicle ECU4 is in post-processing. When the free capacity of the memory 41 of the vehicle ECU4 decreases, the sending of the block can be stopped, and when the free capacity increases, the sending of the block can be restarted. Therefore, the update program blocks can be sent at short intervals, and the time for sending the update program can be shortened.

[0154] (Implementation Method 4)

[0155] In embodiment 4, the vehicle-mounted device 3 receives a stop signal from the vehicle-mounted ECU 4, and after sending a stop block for the vehicle-mounted ECU 4 (a certain vehicle-mounted ECU 4) that sent the stop signal, it sends a start block for other vehicle-mounted ECU 4s that are different from that certain vehicle-mounted ECU 4.

[0156] Figure 18 This is a block diagram illustrating the physical structure of the vehicle-mounted device 3 and the vehicle-mounted ECU 4 according to Embodiment 4. The structure of the vehicle-mounted ECU 4 in this embodiment is the same as that in the embodiment (see reference). Figure 2 Furthermore, the structure of the vehicle update system S is essentially the same as that of Implementation Method 1 (see [reference]). Figure 1 However, in this embodiment, the multiple vehicle ECUs 4 included in the vehicle update system S are explained separately. The vehicle update system S includes vehicle ECUs 4 (1) to (n) (n is an integer of 2 or more).

[0157] The vehicle-mounted ECUs 4(1) to (n) are respectively connected to the in-vehicle communication unit 32 of the vehicle-mounted device 3 via the in-vehicle communication line 51. The in-vehicle communication unit 32 and each vehicle-mounted ECU 4 establish two connections via the in-vehicle communication line 51. The processing and communication between each vehicle-mounted ECU 4 and the vehicle-mounted device 3 are the same as those in Embodiment 1 (see [reference]). Figures 3-9 ).

[0158] Figure 19 This is a schematic diagram illustrating the processing flow (timing) of the vehicle-mounted device 3 and the multiple vehicle-mounted ECUs 4 to be updated in Embodiment 3. Figure 19 As shown, the vehicle-mounted device 3 establishes two connections with each of the vehicle-mounted ECUs 4. The vehicle-mounted device 3 and the vehicle-mounted ECUs 4 perform two types of processing: transmission control processing and program update processing.

[0159] Each on-board ECU 4 sends a start signal to the on-board device 3 before performing post-processing of any block. The device control unit 30 of the on-board device 3 then selects one of the on-board ECU 4 that sent the start signal (in... Figure 19 In the example shown, the vehicle ECU 4 (1) is determined to be the transmitting block, and the transmission of the block begins. The device control unit 30, based on the next sequence request signal sent from the vehicle ECU 4 (1) during the program update process (see reference...), ... Figure 4 ), and send the blocks.

[0160] While storing the received blocks in a buffer, the ECU control unit 40 of the vehicle ECU 4 (1) performs post-processing. If the free capacity of the memory falls below a first predetermined value, a stop signal is sent to the vehicle device 3 during the transmission control process. Upon receiving the stop signal, the device control unit 30 of the vehicle device 3 stops transmitting blocks from the vehicle ECU 4 (1) that sent the stop signal. It should be noted that when the transmission control process is performed using the UDS protocol, the ECU control unit 40 of the vehicle ECU 4 sends a stop signal or a start signal to the vehicle device 3 by responding to an interrogation signal based on the Response on Event function sent from the vehicle device 3 at a predetermined period. That is, each vehicle ECU 4 can periodically send a stop signal or a start signal according to the number of free buffers. When a stop signal is received from a certain vehicle ECU 4, the device control unit 30 of the vehicle device 3 determines the vehicle ECU 4 that can perform post-processing when a block is received by receiving stop signals or start signals from the other vehicle ECU 4.

[0161] When a stop signal is received from the vehicle ECU 4, the device control unit 30 of the vehicle device 3 selects a vehicle ECU 4 (in which the last signal sent was the start signal) from the stop signal or start signal, and sets a specific vehicle ECU 4 (in Figure 19 In the example shown, vehicle ECU 4(n) is determined to be the next vehicle ECU to send the block. The device control unit 30 starts sending the block from vehicle ECU 4(n) based on the next sequence request signal sent from vehicle ECU 4(n) during the program update process (see reference). Figure 4 ), and send the blocks.

[0162] While storing the received blocks in a buffer, the ECU control unit 40 of the vehicle ECU 4(n) performs post-processing. If the available memory capacity is below a first predetermined value, a stop signal is sent to the vehicle device 3 during the transmission control process. Upon receiving the stop signal, the device control unit 30 of the vehicle device 3 stops transmitting blocks from the vehicle ECU 4(n) that sent the stop signal. In addition, if the number of idle buffers is above a second predetermined value, the ECU control unit 40 of the vehicle ECU 4(1) sends a start signal to the vehicle device 3.

[0163] Subsequently, the device control unit 30 of the vehicle-mounted device 3 sends a block to the vehicle-mounted ECU 4 that sent the start signal, and upon receiving a stop signal from that vehicle-mounted ECU 4, it sends a start block to other vehicle-mounted ECU 4s that sent start signals. Thus, the device control unit 30 can send blocks to other vehicle-mounted ECU 4s while the post-processing of a block performed by one vehicle-mounted ECU 4 is underway, reducing the time required to complete the sending of blocks to multiple vehicle-mounted ECU 4s. It should be noted that even after completing the sending of all blocks to one vehicle-mounted ECU 4, the device control unit 30 of the vehicle-mounted device 3 also determines which vehicle-mounted ECU 4 to send a block from the other vehicle-mounted ECU 4s that sent start signals, and begins sending blocks to that vehicle-mounted ECU 4.

[0164] In this way, the device control unit 30 of the vehicle-mounted device 3 processes the updates of the programs of multiple vehicle-mounted ECUs at substantially the same timing. At this time, the device control unit 30 of the vehicle-mounted device 3 can also obtain update programs to be applied to the respective vehicle-mounted ECUs that are the targets of the update from the program providing device. Based on this, the device control unit 30 of the vehicle-mounted device 3 can also divide each of these update programs into blocks of a predetermined size and send each of the divided blocks to each vehicle-mounted ECU. Alternatively, the update program obtained by the vehicle-mounted device 3 from the external server S1 (program providing device) may be a single file, such as an archive file. When the device control unit 30 of the vehicle-mounted device 3 divides the update program into blocks, it establishes a correspondence between the vehicle-mounted ECUs to which the blocks are sent and the divided blocks respectively. In this case, the blocks sent to each vehicle-mounted ECU 4 are blocks whose destinations are represented by the blocks that have established correspondences with each block. Afterwards, the blocks sent to each vehicle-mounted ECU may also refer to blocks in the update program to be applied to that vehicle-mounted ECU.

[0165] Figure 20 This is a flowchart illustrating the connection between the transmission control processing and the program update processing of the vehicle-mounted device 3 in Embodiment 4. In the program update processing, the device control unit 30 of the vehicle-mounted device 3 receives the update program from the external server S1 of the vehicle-mounted ECU 4 (S901). Additionally, in the transmission control processing, the device control unit 30 receives a stop signal or a start signal from each of the vehicle-mounted ECU 4 (S902). The device control unit 30 determines the vehicle-mounted ECU 4 from the vehicle-mounted ECU 4 (1) to (n) that will send the block of the update program (S903). In S903, the device control unit 30, for example, determines the vehicle-mounted ECU 4 with the smallest distinguishing number (hereinafter referred to as ECU number) among the vehicle-mounted ECU 4 that has sent a start signal to the vehicle-mounted device 3 as the vehicle-mounted ECU 4 to send the block. After determining the vehicle-mounted ECU 4 to send the block in the transmission control processing, the device control unit 30 starts sending the block to the vehicle-mounted ECU 4 determined in S903 (S904).

[0166] The device control unit 30 generates a block by preprocessing the update program received in the program update process (S905). The device control unit 30 sends the generated block to the vehicle ECU 4 (S906). The device control unit 30 receives a next sequence request signal from the vehicle ECU 4 (S907). The vehicle ECU 4 determines whether all blocks of the update program have been sent (S908). If not all blocks have been sent (S908: No), the process returns to S905, and processing continues for the next block that becomes the next sequence. If all blocks have been sent (S908: Yes), the device control unit 30 of the vehicle device 3 causes the process to return to the transmission control process in S903. It should be noted that in S903 when the process returns from S908, among the vehicle ECUs that have not received the update program, the vehicle ECU 4 with the smallest ECU number among the vehicle ECUs that sent the start signal to the vehicle device 3 is determined to be the vehicle ECU 4 to send the block.

[0167] When the vehicle control unit 30 of the vehicle-mounted device 3 receives a stop signal (S909) from the vehicle-mounted ECU 4 (the vehicle-mounted ECU 4 determined in S903) that has received an update program block, the device control unit 30 receives a stop signal. The device control unit 30 then stops sending blocks to the vehicle-mounted ECU 4 that sent the stop signal (S910). The device control unit 30 then determines the vehicle-mounted ECU 4 that will send the update program block next (S911). In S911, the device control unit 30, for example, determines the vehicle-mounted ECU 4 with the smallest ECU number among the vehicle-mounted ECU 4 that last sent a start signal to the vehicle-mounted device 3 from either the stop signal or the start signal as the vehicle-mounted ECU 4 that will send the update program block next. The device control unit 30 then begins sending blocks to the vehicle-mounted ECU 4 determined in S911 (S912). It should be noted that when the device control unit 30 executes S912 in the transmission control process, it causes the process to proceed to S905 in the program update process.

[0168] If the vehicle ECU 4 that sent the stop signal received in S909 or the previous cycle S914 sends a start signal, the device control unit 30 of the vehicle device 3 receives the start signal (S913). Alternatively, if the vehicle ECU 4 determined in S911 sends a stop signal, the device control unit 30 receives the stop signal (S914). Upon receiving the stop signal, the device control unit 30 stops sending the block to the vehicle ECU 4 that sent the stop signal (S915) and returns the process to S903. It should be noted that in S903, when the process returns from S915, the vehicle ECU 4 with the smallest ECU number among the vehicle ECU 4 that last sent a start signal to the vehicle device 3 is determined to be the vehicle ECU 4 that will next send the update program block. It should be noted that the device control unit 30 of the vehicle device 3 can also periodically obtain the number of idle buffers from each vehicle ECU 4. In S903 or S911, the vehicle ECU 4 with the most idle buffers is determined as the vehicle ECU 4 to send the block.

[0169] Based on the above structure and processing, the device control unit 30 of the vehicle-mounted device 3 sends a block to the vehicle-mounted ECU 4 that sends a start signal, and upon receiving a stop signal from that vehicle-mounted ECU 4, it sends start blocks to other vehicle-mounted ECU 4s that have sent start signals. Therefore, the device control unit 30 can send execution blocks to other vehicle-mounted ECU 4s during the post-processing of an execution block of a certain vehicle-mounted ECU 4, preventing standby time until processing begins and shortening the time required to send completion blocks to multiple vehicle-mounted ECU 4s.

[0170] (Note 1)

[0171] A program update method is disclosed for updating the program of an on-board ECU of an on-board update system. The on-board update system includes the on-board ECU mounted in a vehicle and an on-board device that receives an update program sent from an external server outside the vehicle and processes it for updating the program of the on-board ECU. The on-board device sends the update program sequentially to the on-board ECU in the form of blocks divided according to a specified size. Upon receiving the block, the vehicle ECU sequentially stores the received block in its memory. The vehicle ECU uses at least a portion of the memory as a working area to perform post-processing on the blocks stored in the memory. Even while the vehicle ECU is performing post-processing on the block stored in the memory, the on-board device will send the next block in the next order of the block being post-processed to the vehicle ECU.

[0172] (Note 2)

[0173] An update program is disclosed for updating the program of an on-board ECU in an in-vehicle update system. The in-vehicle update system includes the on-board ECU mounted in a vehicle and an on-board device that receives an update program sent from an external server outside the vehicle and processes it for updating the program of the on-board ECU. The on-board device sends the update program sequentially to the on-board ECU in the form of blocks divided according to a specified size. Upon receiving the block, the vehicle ECU sequentially stores the received block in its memory. The vehicle ECU uses at least a portion of the memory as a working area to perform post-processing on the blocks stored in the memory. Even while the vehicle ECU is performing post-processing on the block stored in the memory, the on-board device will send the next block in the next order of the block being post-processed to the vehicle ECU.

[0174] (Note 3)

[0175] An in-vehicle update system includes an in-vehicle ECU mounted in a vehicle and an in-vehicle device for receiving an update program sent from an external server outside the vehicle and processing a program for updating the in-vehicle ECU, wherein... The on-board device sends the update program sequentially to the on-board ECU in the form of blocks divided according to a specified size. Upon receiving the block, the vehicle ECU sequentially stores the received block in its memory. The vehicle ECU uses at least a portion of the memory as a working area to perform post-processing on the blocks stored in the memory. Even while the vehicle ECU is performing post-processing on the block stored in the memory, the on-board device will send the next block in the next order of the block being post-processed to the vehicle ECU.

[0176] The embodiments disclosed herein should be considered illustrative in all respects, not restrictive. The technical features described in the various embodiments can be combined with each other, and the scope of the invention is intended to include all variations within the claims and their equivalents. Furthermore, the independent and dependent claims described in the claims can be combined with each other in all combinations, regardless of the form of reference. Further, the claims may use a form that references two or more other claims (multiple claim form), but are not limited to this. A multiple claim form that references at least one multiple claim (multiple references to multiple claims) may also be used.

[0177] Explanation of reference numerals in the attached figures

[0178] 1. External communication device

[0179] 3 vehicle-mounted devices

[0180] 30 Device Control Unit

[0181] 31 Storage Department

[0182] 311 Recording Media

[0183] 32 Car Internal Communications Department

[0184] 4. Vehicle ECU

[0185] 40ECU control unit

[0186] 41 Memory

[0187] 42 Auxiliary Storage Unit

[0188] 43 Car Internal Communications Department

[0189] 5G vehicle network

[0190] Vehicle C

[0191] N External Network

[0192] P1 device control program

[0193] P2 ECU control program

[0194] S Vehicle Update System

[0195] S1 external server

[0196] S2 terminal device

[0197] T ECU table.

Claims

1. An in-vehicle update system, comprising an in-vehicle ECU and an in-vehicle device, wherein the in-vehicle ECU is mounted in a vehicle, and the in-vehicle device receives an update program sent from a program providing device and processes the program for updating the in-vehicle ECU, wherein... The on-board device sends the update program sequentially to the on-board ECU in the form of blocks divided according to a specified size. Upon receiving the block, the vehicle ECU sequentially stores the received block in its memory. The vehicle ECU uses at least a portion of the memory as a working area to perform post-processing on the blocks stored in the memory. Even while the vehicle ECU is performing post-processing on the block stored in the memory, the vehicle device will send the next block in the next order of the block being post-processed to the vehicle ECU.

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

3. The vehicle-mounted update system according to claim 1 or 2, wherein, When the free capacity of the memory of the vehicle ECU falls below a first predetermined value, the on-board device stops sending the block.

4. The vehicle-mounted update system according to claim 1 or 2, wherein, The memory of the vehicle ECU includes multiple buffers corresponding to the blocks to be received. The vehicle ECU uses the buffer as a working area to perform post-processing on the blocks stored in the buffer. Even while the vehicle ECU is performing post-processing on the block stored in the buffer, the vehicle device will send the next block in the next order of the block being post-processed to the vehicle ECU.

5. The vehicle-mounted update system according to claim 4, wherein, The vehicle ECU receives the next block while performing post-processing on the block stored in the buffer. The vehicle ECU stores the next block in a different buffer than the buffer that stores the block that is currently undergoing post-processing.

6. The vehicle-mounted update system according to claim 3, wherein, The memory of the vehicle ECU includes multiple buffers corresponding to the blocks to be received. The vehicle ECU uses the buffer as a working area to perform post-processing on the blocks stored in the buffer. After executing post-processing on the block stored in the buffer, the vehicle ECU deletes the block from the buffer. The available capacity of the memory of the vehicle ECU corresponds to the number of buffers among the plurality of buffers that do not store the block.

7. The vehicle-mounted update system according to claim 1 or 2, wherein, After executing post-processing on the block stored in the memory, the vehicle ECU deletes the block from the memory. When the free capacity of the memory of the vehicle ECU reaches or exceeds a second predetermined value, the vehicle-mounted device begins sending the block.

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

9. The vehicle-mounted update system according to claim 3, wherein, When the available capacity of the memory falls below a first predetermined value, the vehicle ECU sends a signal to the vehicle device requesting the cessation of the transmission of the block.

10. The vehicle-mounted update system according to claim 9, wherein, The vehicle-mounted device establishes two connections with the vehicle-mounted ECU. The transmission of the block from the on-board device to the on-board ECU is performed within a single connection. In another connection, a signal is sent from the vehicle ECU to the vehicle device requesting the cessation of the transmission of the block.

11. The vehicle-mounted update system according to claim 9, wherein, When the free capacity of the memory reaches or exceeds a second predetermined value, the vehicle ECU sends a signal to the vehicle device requesting the start of transmitting the block.

12. The vehicle-mounted update system according to claim 3, wherein, The on-board device obtains information related to the available capacity of the memory of the on-board ECU. When the available capacity of the memory is below a first predetermined value, the vehicle-mounted device stops sending the block.

13. The vehicle-mounted update system according to claim 12, wherein, The vehicle-mounted device establishes two connections with the vehicle-mounted ECU. Within a single connection, signals are transmitted from the on-board unit to the on-board ECU for the transmission of the block, and from the on-board ECU to the on-board unit for the transmission of the next block in the next sequence. In another connection, a signal is sent from the vehicle device to the vehicle ECU to inquire about the available capacity of the memory, and information related to the available capacity of the memory is sent from the vehicle ECU to the vehicle device.

14. The vehicle-mounted update system according to claim 12, wherein, When the free capacity of the memory is above a second predetermined value, the vehicle-mounted device begins sending the block.

15. The vehicle-mounted update system according to claim 3, wherein, Including multiple of the aforementioned vehicle-mounted ECUs, When the vehicle-mounted device stops sending the block for one of the plurality of vehicle-mounted ECUs, it begins sending the block of the update program to be applied to other vehicle-mounted ECUs that are different from the one vehicle-mounted ECU.

16. The vehicle-mounted update system according to claim 15, wherein, If the available capacity of the memory falls below a first predetermined value, the vehicle ECU will send a stop signal to the vehicle device requesting the cessation of transmitting the block. When the available capacity of the memory reaches or exceeds a second predetermined value, the vehicle ECU sends a start signal requesting the transmission of the block to the vehicle device. When the vehicle-mounted device receives the stop signal from one of the vehicle-mounted ECUs, it begins sending the block of the update program to be applied to the vehicle-mounted ECU that sent the start signal in another vehicle-mounted ECU that is different from the one that sent the start signal.

17. An in-vehicle update system, comprising an in-vehicle ECU and an in-vehicle device, wherein the in-vehicle ECU is mounted in a vehicle, and the in-vehicle device receives an update program sent from a program providing device and processes the program for updating the in-vehicle ECU, wherein... The vehicle-mounted device establishes two connections with the vehicle-mounted ECU.

18. An in-vehicle device that receives an update program sent from a program providing device and performs processing for updating the program of an in-vehicle ECU mounted in a vehicle, wherein... The update program is sent sequentially to the vehicle ECU in the form of blocks divided according to a specified size. In the vehicle ECU, even when post-processing of the blocks stored in the memory is being performed by using at least a portion of the area of ​​the memory storing the blocks received sequentially by the vehicle ECU as the working area, the next block in the next order of the blocks being post-processed will be sent to the vehicle ECU.

19. An on-board ECU, mounted in a vehicle, wherein, The on-board device that has received the update program sent from the program providing device receives the update program sequentially in the form of blocks divided according to a specified size. Upon receiving the block, the received block is stored in the memory. Post-processing of the blocks stored in the memory is performed by using at least a portion of the memory as a working area. Even while post-processing of the block stored in the memory is being performed, the next block that is to be post-processed is received from the vehicle-mounted device as the next block in the next order.

Images