Data transfer method and in-vehicle relay device

Abstract

This onboard relay device, upon receiving a specific request from an external tool connected to a vehicle, transfers the specific request to a plurality of electronic control devices to which the specific request is to be transmitted and sets a communication period on the basis of the number of the plurality of electronic control devices and the load of a communication line. Upon receiving, from the plurality of electronic control devices, response data to the specific request, the onboard relay device transfers the response data received within a prescribed period to the external tool in each communication period.

Description

Technical Field

[0001] The present invention relates to a data transfer method and an in-vehicle relay device.

Background Art

[0002] Conventionally, a vehicle control device that communicates with an ECU mounted on a vehicle via a communication line to control a device is disclosed in Patent Document 1. In the vehicle control device disclosed in Patent Document 1, when transmitting response data for a specific request, the transmission interval of the frame of the response data is determined according to the congestion degree of the communication line.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above-described conventional vehicle control device, since the transmission interval is determined according to the congestion degree of the communication line, there is a problem that the load of the communication line cannot be reduced unless the communication line is actually congested.

[0005] Therefore, the present invention has been proposed in view of the above circumstances, and an object thereof is to provide an in-vehicle relay device and a data transfer method thereof that can predict an increase in the load of a communication line and prevent an increase in the load of the communication line in advance.

Means for Solving the Problems

[0006] To solve the above-mentioned problems, an in-vehicle relay device and its data transfer method according to one aspect of the present invention, upon receiving a specific request from an external tool connected to the vehicle, forwards the specific request to a plurality of electronic control devices that are the recipients of the specific request. Then, a communication cycle is set based on the number of the plurality of electronic control devices and the load on the communication line, and upon receiving response data for the specific request from the plurality of electronic control devices, the received response data is forwarded to the external tool within a predetermined time for each communication cycle. [Effects of the Invention]

[0007] According to the present invention, it is possible to predict an increase in the load on the communication line and prevent the increase in the load on the communication line in advance. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram showing the configuration of an in-vehicle control system equipped with an in-vehicle relay device according to one embodiment. [Figure 2] Figure 2 is a communication sequence diagram illustrating OBD communication by an in-vehicle control system. [Figure 3] Figure 3 is a flowchart showing the processing procedure for switching diagnostic modes by an in-vehicle relay device according to one embodiment. [Figure 4] Figure 4 is a flowchart showing the processing procedure for transferring the first frame by an in-vehicle relay device according to one embodiment. [Figure 5] Figure 5 is a flowchart showing the processing procedure for transferring response frames by an in-vehicle relay device according to one embodiment. [Figure 6] Figure 6 is a diagram illustrating the response frame transfer process by an in-vehicle relay device according to one embodiment. [Figure 7] Figure 7 is a diagram illustrating the response frame transfer process by an in-vehicle relay device according to one embodiment. [Modes for carrying out the invention]

[0009] Hereinafter, an embodiment to which the present invention is applied will be described with reference to the drawings. In the drawings, the same parts are denoted by the same reference numerals, and detailed descriptions are omitted.

[0010] [Configuration of the in-vehicle control system] Figure 1 is a block diagram showing the configuration of an in-vehicle control system equipped with an in-vehicle relay device according to this embodiment. As shown in Figure 1, the in-vehicle control system 1 comprises a gateway ECU (Electronic Control Unit) 3, domain ECUs 5 and 7, and a plurality of ECUs 10-18, each having a specific function, which are connected by buses B1-B6. The diagnostic tool 20 is connected to a diagnostic connector provided in the vehicle.

[0011] The Gateway ECU 3 is an in-vehicle relay device that connects to multiple ECUs 10-18 mounted in the vehicle via buses B1-B5 and relays data transmitted to buses B1-B5. Furthermore, the Gateway ECU 3 is a vehicle-mounted relay device that... Diagnostic connector When the diagnostic tool 20 is connected, the system connects to the diagnostic tool 20 via the external connection bus B6 and relays data communication between the diagnostic tool 20 and the ECU 10-18.

[0012] The gateway ECU 3 is equipped with a transfer buffer 23. The transfer buffer 23 is a storage unit that stores data received from multiple ECUs 10-18, and in particular stores the first frame and the response frame of the response data.

[0013] When such a gateway ECU 3 receives a diagnostic request from the diagnostic tool 20 requesting fault diagnosis, it forwards the diagnostic request to the ECUs 10-18 to which the diagnostic request is sent. Then, it sets a communication cycle based on the number of ECUs 10-18 and the bus load, and when it receives response data for the diagnostic request from the multiple ECUs 10-18, it forwards the received response data to the diagnostic tool 20 within a predetermined time for each communication cycle.

[0014] In addition, the gateway ECU 3 stores the received response data in the transfer buffer 23, retrieves the response data received within a predetermined time from the transfer buffer 23, and transfers it to the diagnostic tool 20 for each communication cycle.

[0015] The domain ECU 5 is an in-vehicle relay device that is connected to the gateway ECU 3 via the bus B1 and to the ECUs 12 - 18 via the buses B2 and B3, and relays the data transmitted between the bus B1 and the buses B2 and B3. Similarly, the domain ECU 7 is an in-vehicle relay device that is connected to the gateway ECU 3 via the bus B4 and to the ECUs 10 and 11 via the bus B5, and relays the data transmitted between the bus B4 and the bus B5.

[0016] The domain ECUs 5 and 7 each have transfer buffers 25 and 27. The transfer buffers 25 and 27 are storage units that store the data received from the plurality of ECUs 10 - 18, and particularly store the first frame and the response frames of the response data.

[0017] When such domain ECUs 5 and 7 receive a diagnostic request for requesting a fault diagnosis from the diagnostic tool 20 via the gateway ECU 3, they transfer the diagnostic request to the ECUs 10 - 18 that are the transmission targets of the diagnostic request. Then, the communication cycle is set based on the number of the plurality of ECUs 10 - 18 and the bus load. When receiving response data for the diagnostic request from the plurality of ECUs 10 - 18, the response data received within a predetermined time is transferred to the diagnostic tool 20 for each communication cycle.

[0018] In addition, the domain ECUs 5 and 7 store the received response data in the transfer buffers 25 and 27, retrieve the response data received within a predetermined time from the transfer buffers 25 and 27, and transfer it to the diagnostic tool 20 for each communication cycle.

[0019] ECU10 - 18 are electronic control units each having a specific function, such as an engine control ECU. ECU10 - 18 are ECUs subject to fault diagnosis by an on - vehicle diagnostic device (OBD: On - Board Diagnostics) and are the targets of diagnostic requests transmitted from the diagnostic tool 20. Therefore, when ECU10 - 18 receives a diagnostic request from the diagnostic tool 20, it returns the response data requested by the diagnostic request. Incidentally, transmission IDs, for example, are set as identification information for each of ECU10 - 18, and the identification information is added to the response data.

[0020] The diagnostic tool 20 is an external tool for performing fault diagnosis by OBD, such as a GST (General Scan Tool). When the diagnostic tool 20 is connected to the diagnostic connector provided in the vehicle at a repair shop or a dealer, it communicates with the ECU10 - 18 that is the target of fault diagnosis via OBD and collects various data for performing fault diagnosis.

[0021] Buses B1 - B6 are communication lines connecting the gateway ECU3, domain ECUs 5 and 7, multiple ECUs10 - 18, and the diagnostic tool 20, and the communication protocol is CAN (Controller Area Network). Bus B1 is a communication line connecting the gateway ECU3 and the domain ECU5. Bus B2 is a communication line connecting the domain ECU5 and ECUs12 - 15. Also, bus B3 is a communication line connecting the domain ECU5 and ECUs16 - 18. Bus B4 is a communication line connecting the gateway ECU3 and the domain ECU7. Bus B5 is a communication line connecting the domain ECU7 and ECUs10 and 11. Bus B6 is a communication line connecting the gateway ECU3 and the diagnostic connector, and the diagnostic tool 20 is connected to the diagnostic connector.

[0022] The gateway ECU3 and domain ECUs 5 and 7 are controllers composed of general-purpose electronic circuits, including a microcomputer, microprocessor, and CPU, and peripheral devices such as memory. The gateway ECU3 and domain ECUs 5 and 7 have computer programs installed for performing data transfer processing. Each function of the gateway ECU3 and domain ECUs 5 and 7 can be implemented by one or more processing circuits. These processing circuits may include, for example, programmed processing units including electrical circuits, and may also include devices such as application-specific integrated circuits (ASICs) or conventional circuit components arranged to perform the functions described in the embodiments.

[0023] [OBD communication] Next, we will describe the OBD communication when the diagnostic tool 20 is connected to the in-vehicle control system 1 according to this embodiment. Figure 2 is a communication sequence diagram of OBD communication by the diagnostic tool 20.

[0024] As shown in Figure 2, when the diagnostic tool 20 sends a diagnostic request R, the diagnostic request R is forwarded by the gateway ECU 3 and domain ECUs 5 and 7 and sent to ECUs 10-18.

[0025] Upon receiving a diagnostic request R, ECUs 10-18 each send back a first frame FF, which records the data size of the response data to be sent back to the diagnostic request R. The returned first frame FF is forwarded by domain ECUs 5 and 7 and gateway ECU 3 and sent to the diagnostic tool 20.

[0026] Upon receiving the first frame FF from each ECU 10-18, the diagnostic tool 20 transmits a flow control frame FC. The flow control frame FC records the number of consecutive transmissions of response frames, which are segments of the response data returned from ECU 10-18, and the communication interval between response frames. The transmitted flow control frame FC is forwarded by the gateway ECU 3 and domain ECUs 5 and 7 and sent to ECU 10-18.

[0027] Upon receiving the flow control frame FC, ECUs 10-18 divide the response data into multiple response frames RF, depending on the data size that can be transmitted in a single response frame. ECUs 10-18 then send back the divided response frames RF a number of times set for the number of consecutive transmissions, at the communication interval recorded in the flow control frame FC. The returned response frames RF are forwarded by domain ECUs 5 and 7 and gateway ECU 3 and sent to the diagnostic tool 20. Once each ECU 10-18 has sent back a response frame RF, the OBD communication by the diagnostic tool 20 is terminated.

[0028] [Mode switching process] Next, with reference to Figure 3, the mode switching process by the gateway ECU 3 according to this embodiment will be explained. Figure 3 is a flowchart showing the processing procedure for the mode switching process by the gateway ECU 3. However, the following explanation describes the case where the gateway ECU 3 performs the mode switching process, but the same process is performed in the domain ECUs 5 and 7.

[0029] As shown in Figure 3, in step S101, the gateway ECU 3 determines whether or not it has received a diagnostic request from the diagnostic tool 20 requesting fault diagnosis. If it has received a request, it proceeds to step S103. Since the diagnostic request has a function address, it is sent to the multiple ECUs 10-18 that are the target of fault diagnosis. On the other hand, if no diagnostic request has been received, the gateway ECU 3 continues to determine whether or not a diagnostic request has been received.

[0030] In step S103, when the gateway ECU3 receives a diagnostic request in step S101, it enables the diagnostic mode and starts the timer.

[0031] In step S105, the gateway ECU3 determines whether the timer started in step S103 has timed out. If it has not timed out, the process proceeds to step S107; if it has timed out, the process proceeds to step S111.

[0032] In step S107, the gateway ECU 3 determines whether or not it has received a first frame FF from ECUs 10-18. The first frame is a frame that records the data size of the response data sent back by ECUs 10-18. If the gateway ECU 3 has received a first frame, it proceeds to step S109; otherwise, it returns to step S105.

[0033] In step S109, when the gateway ECU3 receives the first frame in step S107, it restarts the timer and returns to step S105. As a result, the timer is restarted while the first frame is being received, and the diagnostic mode remains enabled.

[0034] In step S111, if the timer times out in step S105, the gateway ECU 3 disables the diagnostic mode and terminates the diagnostic mode, thus ending the mode switching process according to this embodiment.

[0035] [First frame transfer process] Next, with reference to Figure 4, the first frame forwarding process by the gateway ECU 3 according to this embodiment will be explained. Figure 4 is a flowchart showing the processing procedure for the first frame forwarding process by the gateway ECU 3. However, the following explanation describes the case where the gateway ECU 3 performs the first frame forwarding process, but the same process is performed in domain ECUs 5 and 7.

[0036] As shown in Figure 4, in step S201, the gateway ECU 3 determines whether or not it has received a frame from ECU 10-18. If it has received a frame, it proceeds to step S203. If it has not received a frame, it continues to determine whether or not it has received a frame.

[0037] In step S203, the gateway ECU3 determines whether the frame received in step S201 is the first frame. If it is the first frame, it proceeds to step S205; otherwise, it proceeds to step S207.

[0038] In step S205, the gateway ECU3 determines whether the diagnostic mode is enabled in the mode switching process described in Figure 3. If the diagnostic mode is enabled, the process proceeds to step S209; otherwise, the process proceeds to step S207.

[0039] In step S207, the gateway ECU 3 determines that the frame received in step S201 is not a frame for fault diagnosis. Then, it forwards the frame received in step S201 to the destination recorded in the frame, and terminates the first frame forwarding process according to this embodiment.

[0040] In step S209, the gateway ECU3 determines whether the frame received in step S201 is the first frame received since the diagnostic request was received. If it is the first frame received, the process proceeds to step 211; otherwise, the process proceeds to step S213.

[0041] In step S211, the gateway ECU3 starts the P2Delay timer. The timeout period started here is the waiting time to receive the first frame transmitted from ECUs 10-18.

[0042] In step S213, the gateway ECU 3 stores the first frame received in step S201 in the transfer buffer 23. First frames received within the timeout period are sequentially stored in the transfer buffer 23.

[0043] In step S215, the gateway ECU3 determines whether the P2Delay timer started in step S211 has timed out. If it has timed out, the process proceeds to step S217; otherwise, it returns to step S201.

[0044] In step S217, the gateway ECU 3 transfers the first frames stored in the transfer buffer 23 to the diagnostic tool 20 in the order they were received, thereby ending the first frame transfer process according to this embodiment.

[0045] In this way, by storing all first frames received within the timeout period in the transfer buffer 23 before transferring them, it is possible to prevent the transfer of missed first frames. For example, if frames were transferred in the order they were received without storing them in the transfer buffer 23, if the transfer of an earlier received first frame takes a long time, later received first frames may time out and cannot be transferred. Therefore, by storing the received first frames in the transfer buffer 23, all first frames sent within the timeout period are received and transferred. Thus, it is possible to prevent the transfer of missed first frames.

[0046] [Transferring the response frame] Next, with reference to Figure 5, the response frame forwarding process by the domain ECU 5 according to this embodiment will be described. Figure 5 is a flowchart showing the processing procedure for the response frame forwarding process by the domain ECU 5. However, the following description will explain the case where the domain ECU 5 performs the response frame forwarding process, but the same process is performed in the gateway ECU 3 and the domain ECU 7.

[0047] As shown in Figure 5, in step S301, domain ECU 5 determines whether or not it has received a frame from ECU 12-18. If it has received a frame, it proceeds to step S303. If it has not received a frame, it continues to determine whether or not it has received a frame.

[0048] In step S303, the domain ECU 5 determines whether the diagnostic mode is enabled in the mode switching process described in Figure 3. If the diagnostic mode is enabled, the process proceeds to step S305; otherwise, the process proceeds to step S307.

[0049] In step S305, the domain ECU 5 determines whether the frame received in step S301 is a response frame for diagnostic communication. A response frame is a frame obtained by dividing the response data sent back from ECUs 12-18 to a diagnostic request into frames according to the data size that can be sent in a single response frame. If it is determined to be a response frame, the process proceeds to step S309; ​​if it is determined not to be a response frame, the process proceeds to step S307.

[0050] In step S307, the domain ECU 5 determines that the frame received in step S301 is not a frame for fault diagnosis. Then, it forwards the frame received in step S301 to the destination recorded in the frame, and terminates the response frame forwarding process according to this embodiment.

[0051] In step S309, the domain ECU 5 stores the response frame received in step S301 in the transfer buffer 25.

[0052] In step S311, the domain ECU 5 acquires the response frames received during a predetermined transmission time slot from the transfer buffer 25. The transmission time slot is the time interval for communication assigned to the domain ECU 5. The domain ECU 5 may also store the acquired response frames in a temporary storage area to distinguish them from other frames.

[0053] In step S313, the domain ECU 5 determines whether there are any response frames with a long reception interval among the response frames acquired in step S311. Specifically, the domain ECU 5 determines whether there are any response frames among the acquired response frames in which the reception interval from the previous reception to the current reception is longer than the transmission time slot, which is a predetermined time. At this time, the domain ECU 5 confirms that the previously received response frame and the currently received response frame were transmitted from the same ECU by looking at the identification information such as the transmission ID attached to the response frame.

[0054] Furthermore, the first response frame after the flow control frame has been transmitted is determined by whether the time interval between the transmission of the flow control frame and the reception of the first response frame is longer than the transmission time slot. If there is a response frame with a long reception interval, the process proceeds to step S315; otherwise, the process proceeds to step S317.

[0055] In step S315, the domain ECU 5 enables the priority flag for the response frames that were determined to have a long reception interval in step S313. On the other hand, the priority flags for other response frames that were not determined to have a long reception interval are kept disabled without change. Alternatively, the response frames with the priority flag enabled and the response frames with the priority flag disabled may be stored in different memory areas within the transfer buffer 25.

[0056] In step S317, the domain ECU 5 sets the communication period T for forwarding the response frame to the diagnostic tool 20. The communication period T is set based on the number of ECUs to which the diagnostic request is sent and the bus load. Specifically, the domain ECU 5 calculates the communication period T using the following equation (1).

number

[0057] The total frame time in equation (1) is calculated using the following equations (2) and (3). [Math 2] Total frame time = Number of ECUs × Frame time ... (2)

number

[0058] Thus, since the communication cycle T is set based on the number of ECUs to which diagnostic requests are sent and the bus load, it is possible to set a communication cycle that anticipates an increase in the communication line load even if the load on the communication line has not actually increased. Furthermore, as shown in equations (1) and (2), the communication cycle T is set to be longer as the bus load increases and as the number of ECUs increases. Note that if multiple buses are connected, the domain ECU 5 sets the communication cycle T for each bus.

[0059] Here, the number of bits in the frame in equation (3) is a predetermined value, and the communication speed is also a value specified by the protocol. In the case of Figure 1, there are nine ECUs, ECU10-18. The bus load can be a value estimated through experimentation or simulation, for example, set to 55%.

[0060] One method for estimating bus load is to calculate the average bus load for each bus and use the maximum bus load as the bus load in equation (1). The average bus load can be obtained as the sum of the frame times defined in the frame definition document. Alternatively, the bus load in the communication path between the diagnostic tool 20 and ECU 10-18 can be monitored, and the maximum bus load can be used as the bus load in equation (1). Furthermore, the bus load in the communication path between the diagnostic tool 20 and ECU 10-18 can be uploaded to a server for statistical analysis, and the maximum bus load can be used as the bus load in equation (1).

[0061] In step S319, the domain ECU 5 forwards the response frames received within the transmission time slot acquired in step S311 to the diagnostic tool 20 at the communication cycle set in step S317.

[0062] For example, the case where domain ECU 5 forwards response frames received from buses B2 and B3 will be explained with reference to Figure 6. As shown in Figure 6, domain ECU 5 receives response frames F12-F18 transmitted from ECUs 12-18, respectively, within the transmission time slot TS1 and stores them in the forwarding buffer 25. Then, domain ECU 5 forwards the response frames F12-F18 stored in the forwarding buffer 25 within the transmission time slot TS1 to bus B1 in a batch during the communication cycle T1. In this way, domain ECU 5 can forward the response frames F12-F18 received within the transmission time slot TS to the diagnostic tool 20 at each communication cycle T.

[0063] Furthermore, when forwarding response frames F12-F18, Domain ECU 5 forwards them in the order they are received on the bus. For example, as shown in Figure 6, response frames F12, F13, F14, and F15 are received on bus B2 in that order, so Domain ECU 5 forwards response frames F12-F15 to bus B1 in this order. Similarly, on bus B3, response frames F16-F18 are forwarded to bus B1 in the order they are received. Note that Domain ECU 5 is configured to forward response frames from bus B2 first and response frames from bus B3 later.

[0064] Furthermore, if the domain ECU 5 finds a response frame among the response frames acquired in step S311 that has the priority flag enabled in step S315, it will prioritize forwarding the response frame with the priority flag enabled. In other words, among the received response frames, it prioritizes forwarding to the diagnostic tool 20 response frames whose reception interval from the previous reception to the current reception is longer than the transmission time slot.

[0065] For example, as shown in Figure 7, in transmission time slot TS1, response frames are transmitted from ECUs other than ECU17, but response frame F17 is not transmitted from ECU17. Then, in transmission time slot TS2, response frames F12-F18 are transmitted from all ECUs 12-18. Therefore, the reception interval between the last reception and the current reception of response frame F17 in transmission time slot TS2 is longer than that of the transmission time slot. So, domain ECU5 prioritizes forwarding response frames with such long reception intervals. For example, in the case of Figure 7, in communication cycle T2, response frame F17 with a long reception interval is forwarded at the beginning of the frame.

[0066] Once the response frame stored in the transfer buffer 25 is transferred, the response frame transfer process according to this embodiment is completed. As a result, the domain ECU 5 can transfer the response frame received from ECU 12-18 to the diagnostic tool 20 at each communication cycle T.

[0067] [Effects of the Embodiment] As described in detail above, when the in-vehicle relay device according to this embodiment receives a diagnostic request from the diagnostic tool 20 connected to the vehicle, it forwards the diagnostic request to the multiple ECUs 10-18 that are the recipients of the diagnostic request. Then, it sets a communication cycle based on the number of ECUs and the bus load, and when it receives response data for the diagnostic request from the ECUs 10-18, it forwards the received response data to the diagnostic tool 20 within a predetermined time for each communication cycle.

[0068] Conventionally, the transmission interval was determined according to the degree of congestion on the communication line, so it was not possible to reduce the load on the communication line until the communication line actually became congested. However, in the in-vehicle relay device according to this embodiment, the communication cycle is set based on the number of ECUs and the bus load, so even if the load on the communication line has not actually increased, it is possible to set a communication cycle that predicts an increase in the load on the communication line. Therefore, the in-vehicle relay device according to this embodiment can predict an increase in the load on the communication line and prevent an increase in the load on the communication line in advance.

[0069] Furthermore, the in-vehicle relay device according to this embodiment stores the received response data in a transfer buffer, retrieves the response data received within a predetermined time from the transfer buffer, and transfers it to the diagnostic tool 20 at each communication cycle. This allows the response data stored in the transfer buffer to be retrieved and transferred at the appropriate timing, thereby preventing an increase in the load on the communication line.

[0070] Furthermore, the in-vehicle relay device according to this embodiment sets the communication cycle to be longer as the load on the communication line increases. This allows the communication cycle to be set to be longer when an increase in the load on the communication line is anticipated, thereby preventing an increase in the load on the communication line in advance.

[0071] Furthermore, the in-vehicle relay device according to this embodiment sets the communication cycle to be longer as the number of ECUs 10-18 increases. This allows the communication cycle to be set to be longer when an increase in the number of ECUs is expected to increase the load on the communication line, thereby preventing an increase in the load on the communication line in advance.

[0072] Furthermore, in the in-vehicle relay device according to this embodiment, identification information is set for each of the multiple ECUs 10-18, and this identification information is added to the response data. As a result, the ECU that sent the response data can be recognized, and the response data can be accurately transferred.

[0073] Furthermore, the in-vehicle relay device according to this embodiment prioritizes the transfer of response data to the diagnostic tool 20 based on the reception interval between the previous reception and the current reception being longer than a predetermined time. This allows for the priority transfer of response data that may have been missed, thereby improving the reliability of communication.

[0074] Furthermore, in the vehicle-mounted relay device according to this embodiment, if multiple communication lines are connected, a communication cycle is set for each communication line. This allows for the setting of an optimal communication cycle for each communication line, thereby efficiently preventing an increase in the load on the communication lines.

[0075] The embodiments described above are merely examples of the present invention. Therefore, the present invention is not limited to the embodiments described above, and various modifications can be made to forms other than those described above, as long as they do not depart from the technical spirit of the present invention, depending on the design and other factors. [Explanation of Symbols]

[0076] 1. In-vehicle control system 3 Gateway ECU 5.7 Domain ECU 10-18 ECU B1-B6 Bus 20 Diagnostic Tools 23, 25, 27 Transfer buffer

Claims

1. A data transfer method for an in-vehicle relay device that is connected to multiple electronic control devices mounted on a vehicle via a communication line and relays data transmitted to the communication line, The in-vehicle relay device is When a specific request is received from an external tool connected to the vehicle, the specific request is forwarded to the plurality of electronic control units that are the recipients of the specific request. The communication cycle is set based on the number of the plurality of electronic control devices and the load of the communication line. A data transfer method that, upon receiving response data for a specific request from the plurality of electronic control devices, transfers the received response data to the external tool within a predetermined time period according to the communication cycle.

2. The data transfer method according to claim 1, wherein the in-vehicle relay device stores the received response data in a storage unit, retrieves the response data received within a predetermined time from the storage unit, and transfers it to the external tool at each communication cycle.

3. The data transfer method according to claim 1 or 2, wherein the in-vehicle relay device sets the communication cycle to be longer as the load on the communication line increases.

4. The data transfer method according to claim 1 or 2, wherein the in-vehicle relay device sets the communication cycle to be longer as the number of the plurality of electronic control devices increases.

5. The data transfer method according to claim 1 or 2, wherein each of the plurality of electronic control devices is set to identification information, and the response data is accompanied by the identification information.

6. The data transfer method according to claim 1 or 2, wherein the in-vehicle relay device prioritizes transferring response data to the external tool if the interval between the previous reception and the current reception is longer than the predetermined time.

7. The data transfer method according to claim 1 or 2, wherein the in-vehicle relay device sets the communication cycle for each communication line when multiple communication lines are connected.

8. An in-vehicle relay device comprising a controller that is connected to multiple electronic control devices mounted on a vehicle via communication lines and relays data transmitted to the communication lines, The aforementioned controller, When a specific request is received from an external tool connected to the vehicle, the specific request is forwarded to the plurality of electronic control units that are the recipients of the specific request. The communication cycle is set based on the number of the plurality of electronic control devices and the load of the communication line. An in-vehicle relay device that, upon receiving response data for a specific request from the plurality of electronic control devices, transfers the received response data to the external tool at each communication cycle within a predetermined time.

Images