JP7814613B2 - communication systems - Google Patents

Description

The present invention relates to a communication system.

Multiple in-vehicle devices that communicate with each other are known. Patent Document 1 describes an in-vehicle communication device that divides update data and transmits it to a destination device, determining the transmission interval based on the processing load of the destination device.

Japanese Patent Application Laid-Open No. 2021-039681

In conventional technology, the processing load of the destination device receiving the data was determined by the sender, which resulted in low accuracy of the processing load and the risk of data transmission failing.

The present invention aims to reduce the probability of data communication failure between devices and ensure more reliable data communication.

A communication system according to one aspect of the present invention comprises a master device that transmits a request message at a predetermined transmission interval requesting the execution of a predetermined process, and a slave device that receives the request message transmitted by the master device and transmits a response message corresponding to the received request message to the master device, wherein the slave device calculates the processing load of the slave device and transmits the response message to the master device including load information regarding the calculated processing load of the slave device, and the master device calculates the processing load of the master device, receives the response message transmitted by the slave device, and determines the process requested by the request message and the transmission interval of the request message based on the calculated processing load of the master device and the load information included in the received response message.

The present invention reduces the probability of data communication between devices failing, enabling more reliable data communication.

FIG. 1 is a schematic diagram showing the overall configuration of a communication system according to the first embodiment. FIG. 2 is a schematic diagram showing the hardware configuration of the first ECU. FIG. 3 is a schematic diagram showing the functional configuration of the first ECU and the second ECU. FIG. 4 is a schematic diagram showing data stored in the nonvolatile memory of the first ECU. FIG. 5 is a diagram showing a communication sequence of data communication performed between the first ECU and the second ECU. FIG. 6 is a flowchart of the process executed by the first ECU and the second ECU. FIG. 7 is a diagram showing a communication sequence of data communication performed between the first ECU and the second ECU.

First Embodiment
A communication system according to a first embodiment of the present invention will be described with reference to FIGS.

Figure 1 is a schematic diagram showing the overall configuration of a communication system 1 according to the first embodiment. The communication system 1 is composed of a first ECU 3 and a second ECU 4 mounted on a vehicle 2, and a management PC 5 provided outside the vehicle 2. The first ECU 3 and the second ECU 4 are electronic control units that control, for example, the engine, the brakes, etc. A network 7, such as a CAN (Controller Area Network), is provided inside the vehicle 2. The first ECU 3 and the second ECU 4 are connected to the network 7, enabling data communication between them.

Note that vehicle 2 is equipped with other ECUs, and these ECUs are also connected to network 7, but Figure 1 only illustrates first ECU 3 and second ECU 4 as representatives of these ECUs. Similarly, the following explanation will focus only on first ECU 3 and second ECU 4.

The vehicle 2 is provided with a maintenance interface 6. A management PC 5 can be connected to the interface 6 from outside the vehicle 2. The maintenance interface 6 is connected to a network 7 inside the vehicle 2. In other words, by using the interface 6, it is possible to connect the management PC 5 outside the vehicle to the network 7 and perform data communication between the management PC 5 and the first ECU 3 and second ECU 4.

Figure 2 is a schematic diagram showing the hardware configuration of the first ECU 3. Note that the second ECU 4 and the management PC 5 have the same hardware configuration as the first ECU 3, at least as far as the description of the embodiment is concerned, and therefore their description will be omitted.

The first ECU 3 is composed of a computer equipped with a processing device 11 such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or DSP (Digital Signal Processor), non-volatile memory 12 such as ROM (Read Only Memory), flash memory, or a hard disk drive, volatile memory 13 known as RAM (Random Access Memory), an input/output interface 14, and other peripheral circuits. These hardware components work together to run software and realize multiple functions. The first ECU 3 may be composed of a single computer or multiple computers. The processing device 11 may be an ASIC (application specific integrated circuit), FPGA (Field Programmable Gate Array), or the like.

The non-volatile memory 12 stores programs capable of executing various calculations. In other words, the non-volatile memory 12 is a storage medium (storage device) that can read programs that realize the functions of this embodiment. The volatile memory 13 is a storage medium (storage device) that temporarily stores the results of calculations performed by the processing unit 11 and signals input from the input/output interface 14. The processing unit 11 is a device that loads the programs stored in the non-volatile memory 12 into the volatile memory 13 and executes the calculations, and performs predetermined calculations on data taken in from the input/output interface 14, the non-volatile memory 12, and the volatile memory 13 in accordance with the programs.

The input section of the input/output interface 14 converts signals input from various other devices (such as the second ECU 4) via the network 7 into data that can be calculated by the processing device 11. The output section of the input/output interface 14 generates an output signal based on the calculation results of the processing device 11 and outputs that signal to various other devices (such as the second ECU 4) via the network 7.

Figure 3 is a schematic diagram showing the functional configuration of the first ECU 3 and the second ECU 4. The first ECU 3 includes a first load calculation unit 31, a first transmission/reception unit 32, a success/failure determination unit 33, an interval determination unit 34, and a process selection unit 35. The first load calculation unit 31 calculates the processing load of the first ECU 3. The processing load will be described in detail later. The first transmission/reception unit 32 transmits a request message requesting the execution of a predetermined process to the second ECU 4 at a predetermined transmission interval. The first transmission/reception unit 32 also receives a response message transmitted by the second ECU 4. The success/failure determination unit 33 determines whether the transmission of the request message by the first transmission/reception unit 32 was successful or unsuccessful. When the first transmission/reception unit 32 receives a response message, the interval determination unit 34 determines the transmission interval of the request message based on the processing load of the first ECU 3 and the load information contained in the received response message. The process selection unit 35 selects the predetermined process requested to be executed by the request message.

The second ECU 4 includes a second load calculation unit 41, a second transmission/reception unit 42, and a processing execution unit 43. The second load calculation unit 41 calculates the processing load of the second ECU 4. The second transmission/reception unit 42 receives a request message transmitted by the first ECU 3. The second transmission/reception unit 42 further transmits a response message corresponding to the received request message to the first ECU 3. Each time the second transmission/reception unit 42 receives a request message, the processing execution unit 43 executes the specified processing requested by the request message.

Note that the management PC 5 has the same functional configuration as the first ECU 3, at least as far as the description of the embodiment is concerned, and therefore its description will be omitted. That is, like the first ECU 3, the management PC 5 has a first load calculation unit 31, a first transmission/reception unit 32, a success/failure determination unit 33, an interval determination unit 34, and a processing selection unit 35.

For example, consider a case in which the second ECU 4 is instructed to execute a specification confirmation process by transmitting a request message. Such specification confirmation process is performed, for example, as a preprocessing step before the second ECU 4 executes a diagnostic process. In this case, the first ECU 3 first transmits a request message to the second ECU 4 requesting the second ECU 4's specification data (e.g., the individual number assigned to the second ECU 4 and the numbers of the various components constituting the second ECU 4). Upon receiving this request message, the second ECU 4 returns a response message to the first ECU 3 containing the second ECU 4's own specification data and load data (load information) indicating the processing load of the second ECU 4. The first ECU 3 reads the specification data from the received response message and determines the diagnostic process to be executed by the second ECU 4. The first ECU 3 further uses the load data (load information) contained in the response message to determine the interval for transmitting a similar request message and the process to be requested of the second ECU 4 the next time the first ECU 3 transmits a similar request message.

Similar processing can also be performed by the management PC 5 instead of the first ECU 3. In other words, the management PC 5 can also send a request message to the second ECU 4 requesting specification data for the second ECU 4.

Next, we will explain the processing load. In the first embodiment, the processing load of the first ECU 3 refers to the magnitude of the processing load of the processing device 11 provided in the first ECU 3. For example, the greater the amount of calculations per unit time by the processing device 11, the greater the processing load of the first ECU 3. Similarly, the processing load of the second ECU 4 refers to the magnitude of the processing load of the processing device 11 provided in the second ECU 4.

In the first embodiment, the processing load is represented by a numerical value between 0 and 1, called the load rate. When the processing load is at its lightest, the load rate is 0. When the processing load is at its highest, the load rate is 1.

The following describes how the first load calculation unit 31 calculates the processing load (load factor). The first load calculation unit 31 tallies the non-idle time of the processing device 11 for each predetermined unit of time (e.g., 1 millisecond). Non-idle time refers to the time during which the processing device 11 is performing some kind of calculation processing. The first load calculation unit 31 calculates the non-idle time divided by the unit time to calculate a load factor between 0 and 1. For example, if the processing device 11 is not performing any calculation processing during that unit of time, the load factor will be 0. On the other hand, if the processing device 11 is constantly performing calculation processing during that unit of time, the load factor will be 1.

The first load calculation unit 31 repeatedly stores the calculated load rate in a predetermined location in the volatile memory 13. Therefore, the latest load rate is always stored in that predetermined location in the volatile memory 13. For example, functional units that require the load rate, such as the first transmission/reception unit 32 and the interval determination unit 34, obtain the latest load rate by referring to (reading) that predetermined location in the volatile memory 13.

The method for calculating the processing load (load rate) by the second load calculation unit 41 is the same as that of the first load calculation unit 31, so a description thereof will be omitted. In other words, the second load calculation unit 41 calculates the load rate of the second ECU 4 in the same manner as the first load calculation unit 31 calculates the load rate of the first ECU 3 (or the management PC 5).

Figure 4 is a schematic diagram showing the data stored in the non-volatile memory 12 of the first ECU 3. A transmission interval table 91 and a processing content table 92 are pre-stored in the non-volatile memory 12 of the first ECU 3. In addition, the non-volatile memory 12 of the first ECU 3 also stores transmission interval data 93 and processing content data 94.

The transmission interval table 91 is a table for calculating the transmission interval of a request message from the processing load (load rate) of the first ECU 3 and the processing load (load rate) of the second ECU 4. The interval determination unit 34 calculates the transmission interval of a request message using the transmission interval table 91. The transmission interval table 91 shown in FIG. 4 stores predetermined transmission intervals for each combination of the processing load of the first ECU 3 and the processing load of the second ECU 4, which are classified into three levels: low, medium, and high. Since there are three types of processing load for the first ECU 3 (low, medium, high) and three types of processing load for the second ECU 4 (low, medium, high), the transmission interval table 91 stores transmission intervals for each of 3 x 3 = 9 combinations.

For example, a load rate of less than 0.4 is defined as low, a load rate of 0.4 or more but less than 0.8 as medium, and a load rate of 0.8 or more as high. When the load rate of the first ECU 3 is 0.5 and the load rate of the second ECU 4 is 0.2, the former corresponds to medium and the latter corresponds to low, respectively, so the interval determination unit 34 reads out the transmission interval corresponding to the combination of "the processing load of the first ECU 3 is medium" and "the processing load of the second ECU 4 is low" from the transmission interval table 91 and sets this as the new transmission interval.

It is desirable that the transmission interval determined by the transmission interval table 91 be set so that it is shorter the lower the processing load of the first ECU 3 and longer the higher the processing load of the first ECU 3. Similarly, it is desirable that the transmission interval determined by the transmission interval table 91 be set so that it is shorter the lower the processing load of the second ECU 4 and longer the higher the processing load of the second ECU 4. By setting it in this manner, when a request message is repeatedly sent multiple times, the processing requested of the second ECU 4 can be executed at an appropriate interval that is neither too short nor too long.

The number of processing load categories in the transmission interval table 91 may be greater (for example, five levels) or less (for example, two levels). Furthermore, the number of processing load categories for the first ECU 3 and the number of processing load categories for the second ECU 4 may be different.

The processing content table 92 is a table for selecting a process to be requested by a request message based on the processing load (load rate) of the first ECU 3 and the processing load (load rate) of the second ECU 4. The processing selection unit 35 uses the processing content table 92 to select a process to be requested to be executed by a request message. The processing content table 92 shown in FIG. 4 stores predetermined processes for each combination of the processing load of the first ECU 3 and the processing load of the second ECU 4, which are classified into three levels: low, medium, and high. Since there are three types of processing load for the first ECU 3 (low, medium, high) and three types of processing load for the second ECU 4 (low, medium, high), the processing content table 92 stores processes for each of the 3 x 3 = 9 combinations.

For example, a load rate of less than 0.4 is defined as low, a load rate of 0.4 to 0.8 as medium, and a load rate of 0.8 or more as high. When the load rate of the first ECU 3 is 0.5 and the load rate of the second ECU 4 is 0.2, the former corresponds to medium and the latter corresponds to low, respectively, so the processing selection unit 35 reads out the processing corresponding to the combination of "the processing load of the first ECU 3 is medium" and "the processing load of the second ECU 4 is low" from the processing content table 92 and sets this as the processing to be requested by the request message.

The processing content selected by the processing content table 92 is desirably set so that the lower the processing load of the first ECU 3, the greater the amount of calculation, and the higher the processing load of the first ECU 3, the less the amount of calculation. Similarly, the processing content selected by the processing content table 92 is desirably set so that the lower the processing load of the second ECU 4, the greater the amount of calculation, and the higher the processing load of the second ECU 4, the less the amount of calculation. By setting the processing content in this manner, it is possible to prevent the problem of the first ECU 3 or the second ECU 4 being too high to execute the processing requested in the request message when a request message is sent multiple times. Conversely, when the processing load of the first ECU 3 or the second ECU 4 is low and there is room to execute other processing, it is possible to request the execution of processing with a greater amount of calculation in the request message.

For example, consider a request message for performing so-called sequence control, which executes various processes in a predetermined order. In this case, if the processing load on the first ECU 3 or the second ECU 4 is high and a process that requires a large amount of calculation (such as data compression or decompression) cannot be executed, the various processes in the process content table 92 can be set so that a lighter process (such as a process that requires some parameters) that is scheduled after the process and that does not cause any problems if the order is changed is executed first.

The processing load classifications in the processing content table 92 may be more (for example, five levels) or less (for example, two levels). Furthermore, the number of processing load classifications for the first ECU 3 and the second ECU 4 may be different.

The transmission interval data 93 is data representing the transmission interval determined by the interval determination unit 34. Each time the interval determination unit 34 determines a transmission interval, it stores that transmission interval in the non-volatile memory 12 as the transmission interval data 93. In other words, by reading the transmission interval data 93 in the non-volatile memory 12, the latest (most recent) transmission interval can be obtained.

The processing content data 94 is data representing the processing selected by the processing selection unit 35. Each time the processing selection unit 35 selects a processing request by a request message, it stores the processing content in the non-volatile memory 12 as processing content data 94. In other words, by reading the processing content data 94 in the non-volatile memory 12, the latest (most recent) processing content to be requested can be obtained.

The transmission interval table 91, processing content table 92, transmission interval data 93, and processing content data 94 shown in Figure 4 each exist for each type of request message. For example, if multiple types of request messages are sent from the first ECU 3 to the second ECU 4, such as a request message to check the specifications of the second ECU 4 and a request message to have the second ECU 4 execute diagnostic processing, the various data shown in Figure 4 will exist for each of these multiple types of request messages. Note that this data can also be shared between different types of request messages.

Figure 5 shows the communication sequence of data communication between the first ECU 3 and the second ECU 4. First, at time t1, the first ECU 3 transmits a request message to the second ECU 4. This request message includes information indicating the type of processing the second ECU 4 is to execute, as well as information on various parameters required for that processing. When the second ECU 4 receives this request message at time t2, the second ECU 4 executes the processing requested by the request message at the following time t3. At time t4, when the execution of the processing is completed, the second ECU 4 transmits the request message and a response message corresponding to the processing to the first ECU 3. This response message includes various information related to the requested processing (e.g., the execution result of the processing and the values of the requested parameters), as well as load data (load information) indicating the latest processing load (load rate) of the second ECU 4. At time t5, when the reception of the response message is completed, the first ECU 3 determines the transmission interval for the request message. At time t6, when the transmission interval has elapsed since time t1, the first ECU 3 transmits a similar request message again. Note that the start point of the transmission interval may be time t5 instead of time t1.

Next, we will explain the failure to send a request message. In the first embodiment, the first ECU 3 expects a response message to be returned within a predetermined timeout period (e.g., 100 milliseconds) after sending a request message. This timeout period is predetermined for each type of request message. If a response message is not received within the predetermined timeout period after the first transceiver 32 sent the request message, the success/failure determination unit 33 determines that the transmission of the request message has failed.

If a request message fails to be sent even though the transmission interval and timeout period have been appropriately set in advance, it is believed that this is due to causes other than the processing load of the first ECU 3 or the second ECU 4. Examples include malfunctions caused by deterioration of components (semiconductor components, etc.) that make up the ECU, partial failures, and congestion on the network 7. If a malfunction occurs due to component deterioration or partial failures, the first ECU 3 or the second ECU 4 may automatically restart.

If the success/failure determination unit 33 determines that the transmission of a request message has failed, the first transceiver 32 transmits the next request message at a transmission interval longer than the transmission interval indicated by the transmission interval data 93 in the non-volatile memory 12. This reduces the probability that the transmission of the next request message will fail. Because the transmission interval data 93 is stored in the non-volatile memory 12, it will not be lost even if the first ECU 3 is automatically restarted.

In addition, if the success/failure determination unit 33 determines that the transmission of the request message has failed, rather than changing the transmission interval, the process requested in the request message may be changed to another process with a lower processing load than the process indicated by the process content data 94 in the non-volatile memory 12. Even in this case, the probability that the transmission of the next request message will fail can be reduced. Because the process content data 94 is stored in the non-volatile memory 12, it will not be lost even if the first ECU 3 is automatically restarted.

Figure 6 is a flowchart of the processing executed by the first ECU 3 and the second ECU 4. The left half of Figure 6 is the processing executed by the first ECU 3. The right half of Figure 6 is the processing executed by the second ECU 4. The first ECU 3 and the second ECU 4 repeatedly send and receive request messages and response messages by repeatedly executing the processing shown in Figure 6. First, the processing executed by the first ECU 3 will be explained.

In step S100, the first transmitter/receiver 32 transmits a request message to the second ECU 4 requesting the execution of a predetermined process. In step S110, the first transmitter/receiver 32 attempts to receive a response message transmitted by the second ECU 4. In step S120, the success/failure determination unit 33 determines whether the first transmitter/receiver 32 was successful in transmitting the request message. That is, it determines whether the first transmitter/receiver 32 was able to receive the response message transmitted by the second ECU 4 in step S110 before a predetermined timeout period has elapsed since the request message was transmitted in step S100. If it is determined that the transmission of the request message was successful, processing proceeds to step S130.

In step S130, the first load calculation unit 31 calculates the processing load (load rate) of the first ECU 3. For simplicity's sake, it is assumed that the calculation of the processing load (load rate) is performed only in step S130. However, as described above, the calculation of the processing load (load rate) is performed continuously at regular intervals, and the latest load rate is stored in the volatile memory 13. In step S140, the interval determination unit 34 determines the transmission interval of the request message based on the processing load of the first ECU 3 calculated in step S130 and the load information included in the response message received in step S110. The determined transmission interval is stored in the non-volatile memory 12. In step S150, the process selection unit 35 selects a predetermined process to be executed by the request message based on the processing load of the first ECU 3 calculated in step S130 and the load information included in the response message received in step S110. The content of the selected process is stored in the non-volatile memory 12.

On the other hand, if the success/failure determination unit 33 determines in step S120 that transmission of the request message failed, processing proceeds to step S160. In step S160, the interval determination unit 34 rewrites the transmission interval data 93 in the non-volatile memory 12 to represent a longer transmission interval. After that, when the time represented by the transmission interval data 93 in the non-volatile memory 12 has elapsed, the first ECU 3 again executes the processing shown in FIG. 6.

Next, the processing executed by the second ECU 4 will be described. In step S200, the second transceiver 42 receives the request message transmitted in step S100. In step S210, the processing execution unit 43 executes the processing requested by the request message received in step S200. In step S220, the second load calculation unit 41 calculates the processing load (load rate) of the second ECU 4. For simplicity's sake, the calculation of the processing load (load rate) is assumed to be performed only in step S220. However, as mentioned above, in reality, the processing load (load rate) is calculated at regular intervals, and the latest load rate is stored in the volatile memory 13. In step S230, the second transceiver 42 transmits a response message corresponding to the request message received in step S200 to the first ECU 3. This response message includes the results of the processing executed by the processing execution unit 43 in step S210 and information indicating the processing load (load rate) calculated by the second load calculation unit 41 in step S220.

This first embodiment provides the following effects:

(1) The second ECU 4 (slave device) calculates the processing load of the second ECU 4 (slave device) and transmits a response message containing load information related to the calculated processing load of the second ECU 4 (slave device) to the first ECU 3 (main device). The first ECU 3 (main device) calculates the processing load of the first ECU 3 (main device), receives the response message transmitted by the second ECU 4 (slave device), and determines the processing requested by the request message and the transmission interval of the request message based on the calculated processing load of the first ECU 3 (main device) and the load information contained in the received response message. This reduces the probability of data communication failure between devices, enabling more reliable data communication.

(2) The first ECU 3 (main device) stores the determined transmission interval in the nonvolatile memory 12, which is a nonvolatile storage device. When transmission of a request message fails, the first ECU 3 (main device) transmits the request message at a transmission interval longer than the transmission interval stored in the nonvolatile memory 12 (storage device). This allows the transmission interval to be calculated using the previous value, even when the device is stopped and restarted due to a transmission failure, thereby increasing the probability of successful transmission when retransmitting.

(3) The first ECU 3 (main device) stores the processing requested by the determined request message in the nonvolatile memory 12, which is a nonvolatile storage device. If the first ECU 3 (main device) fails to send the request message, it sends a request message requesting another processing with a lower processing load than the processing stored in the nonvolatile memory 12 (storage device). This allows the second ECU 4 to select the processing to be requested using the previous value, even when the device is stopped and restarted due to a processing failure, thereby increasing the probability of successful processing execution during a retry.

Second Embodiment
A communication system according to a second embodiment of the present invention will be described with reference to Fig. 7. Components that are the same as or equivalent to those described in the first embodiment will be given the same reference symbols, and differences will be mainly described.

For example, it may be necessary to have the second ECU 4 execute a process requiring relatively large amounts of data, such as a firmware update process (update data) or a security authentication process (authentication data). In the second embodiment, multiple request messages corresponding to one process are prepared, and large amounts of data are divided and assigned to the multiple request messages. The first ECU 3 sequentially transmits the multiple request messages at a determined transmission interval. Because it would be inefficient for the second ECU 4 to return a response message to each of the multiple request messages, the second ECU 4 returns a response message indicating whether it has successfully received all of the request messages up to that point each time it receives a predetermined number of request messages or a predetermined time has elapsed. The second ECU 4 stores load information indicating the processing load of the second ECU 4 in this response message, as in the first embodiment. The first ECU 3 receives a response message from the second ECU 4 even while it is in the middle of consecutively transmitting multiple request messages corresponding to one process, and determines the transmission interval for subsequent request messages based on its own processing load and the load information contained in the response message.

For example, suppose the first ECU 3 repeatedly transmits ten request messages corresponding to one process at a first transmission interval. After transmitting three request messages, the first ECU 3 receives a response message from the second ECU 4, revealing that the processing load on the second ECU 4 has increased. In this case, the first ECU 3 determines an appropriate transmission interval (longer than the transmission intervals for the first three messages), as in the first embodiment, and switches to transmitting the fourth and subsequent request messages at the determined transmission interval.

When the second ECU 4 receives all of the request messages corresponding to one process, it begins executing that one process. The process thereafter is the same as in the first embodiment. That is, when execution of that one process is completed, the second ECU 4 sends a response message indicating the processing results to the first ECU 3. The first ECU 3 receives the response message, checks the processing results, and uses the load information contained in the response message to determine a new transmission interval or select the processing content.

Figure 7 is similar to Figure 5 and shows the communication sequence of data communication between the first ECU 3 and the second ECU 4. First, at time t11, the first ECU 3 sends the first request message to the second ECU 4. Then, a certain time later, at times t12 and t13, the second and third request messages are sent, respectively. At time t14, when the second ECU 4 has received the third request message, it sends a response message to the first ECU 3. The first ECU 3 completes receiving this response message at time t15 and determines a new transmission interval. From time t16 onwards, the fourth and subsequent request messages are sent sequentially based on the new transmission interval determined here.

This second embodiment provides the following effects:

(1) The second ECU 4 (slave device) transmits one response message corresponding to the request messages transmitted by the first ECU 3 (main device) to the first ECU 3 (main device) each time the second ECU 4 (slave device) receives multiple request messages. When the first ECU 3 (main device) receives one response message transmitted by the second ECU 4 (slave device), it determines the transmission interval based on the calculated processing load of the first ECU 3 (main device) and the load information contained in the received response message. This allows the transmission interval to be changed even during data communication, thereby changing the success rate of data communication and the time required for data transfer. As a result, for example, if the processing load is increasing, the transmission interval can be lengthened to prevent errors from occurring. Conversely, if the processing load is decreasing, the transmission interval can be shortened to reduce the time required for data transfer.

The following variants are also within the scope of the present invention, and it is possible to combine the configurations shown in the variants with the configurations described in the above-mentioned embodiments, to combine the configurations described in the different embodiments above, or to combine the configurations described in the different variants below.

<Modification 1>
In the above-described embodiments, the first ECU 3 and the management PC 5 function as master devices that transmit request messages, and the second ECU 4 function as a slave device that transmits response messages. However, the present invention is not limited to these embodiments, and other devices may serve as master and slave devices. For example, the first ECU 3 and the management PC 5 may function as slave devices, and the second ECU 4 may function as a master device. Furthermore, a specific device may function as both a master and slave device.

<Modification 2>
In the first and second embodiments, the size of the request message may be changed depending on the processing load of the first ECU 3 and the second ECU 4. For example, in the second embodiment, when large data is divided into multiple request messages and transmitted, if the processing load is high, the number of divisions may be increased to reduce the data size of each request message. The main device in this modification determines the size of the request message based on the calculated processing load of the main device and the load information included in the received response message. The main device reduces the size of the request message as the processing load of the main device increases. Furthermore, the main device reduces the size of the request message as the processing load of the slave device increases. This configuration can further reduce the probability of failure of data communication between devices.

<Modification 3>
The main device may determine the transmission interval by a method other than referring to a table. For example, a formula may be defined that includes each load factor as a variable, and the transmission interval may be determined by substituting the load factor into the formula. In this case, it is desirable to predefine a lower limit and an upper limit for the transmission interval, and to set the transmission interval to the lower limit if the transmission interval determined by the formula is below the lower limit, or to set the transmission interval to the upper limit if it is above the upper limit.

The above describes embodiments of the present invention, but the above embodiments merely illustrate some of the application examples of the present invention and are not intended to limit the technical scope of the present invention to the specific configurations of the above embodiments.

1...Communication system, 2...Vehicle, 3...First ECU, 4...Second ECU, 5...Management PC, 6...Interface, 7...Network, 11...Processing device, 12...Non-volatile memory, 13...Volatile memory, 14...Input/output interface, 31...First load calculation unit, 32...First transmission/reception unit, 33...Success/failure determination unit, 34...Interval determination unit, 35...Processing selection unit, 41...Second load calculation unit, 42...Second transmission/reception unit, 43...Processing execution unit

Claims (5)

a main device that transmits a request message requesting execution of a predetermined process at a predetermined transmission interval;
a slave device that receives the request message transmitted by the master device and transmits a response message corresponding to the received request message to the master device,
The slave device
Calculating a processing load of the slave device;
transmitting the response message to the master device, the response message including load information relating to the calculated processing load of the slave device;
The main device is
Calculating a processing load of the main device;
receiving the response message sent by the slave device;
determining a process to be requested by the request message and the transmission interval of the request message based on the calculated processing load of the main device and the load information included in the received response message;
Communication system. 2. The communication system according to claim 1,
the slave device transmits to the master device one response message corresponding to the plurality of request messages each time the slave device receives the plurality of request messages transmitted by the master device;
when receiving the one response message transmitted by the slave device, the master device determines the transmission interval based on the calculated processing load of the master device and the load information included in the received one response message.
Communication system. 2. The communication system according to claim 1,
The main device is
storing the determined transmission interval in a non-volatile storage device;
When transmission of the request message fails, the request message is transmitted at a transmission interval longer than the transmission interval stored in the storage device.
Communication system. 2. The communication system according to claim 1,
The main device is
storing the processing requested by the determined request message in a non-volatile storage device;
When the transmission of the request message fails, the request message is transmitted to request another process having a lower processing load than the process stored in the storage device.
Communication system. 2. The communication system according to claim 1,
the main device determines a size of the request message based on the calculated processing load of the main device and the load information included in the received response message.
Communication system.