Network system

Abstract

To identify an occurrence position of a communication failure when the communication failure has occurred in a large scale network system in which a plurality of repeating devices are included.SOLUTION: A network system 100 has a diagnostic mode. In the diagnostic mode, terminal ECUs 22, 23, 25, 26, 32, 33, 35, 36 transmit canalization confirmation messages including their own identifiers at a predetermined interval. A plurality of gateway ECUs 20, 30 transfer the canalization confirmation messages to a gateway ECU 10 via a trunk bus 40 and a redundant bus 50. Therefore, the gateway ECU 10 can identify an occurrence position of a communication failure on the basis of the transferred canalization confirmation messages.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a network system in which a plurality of relay devices are connected to each other so as to be able to communicate with each other, and each of the plurality of relay devices is connected to at least one end device via a communication bus. [Background technology]

[0002] For example, Patent Document 1 describes an information processing device for efficiently collecting information about an electronic control unit in which an abnormality has occurred. When an information processing device (gateway) detects that a vehicle ECU is operating abnormally at a timing when it should not be operating, it notifies a center server. When the center server receives the abnormality notification, it determines whether analysis is necessary, and if it determines that analysis is necessary, it instructs the gateway to acquire snapshot data. Upon receiving the instruction, the gateway identifies the ECU in which the abnormality has occurred and acquires snapshot data including memory dump data of the identified ECU. The snapshot data is sent to the center server and used for analysis. [Prior art documents] [Patent documents]

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

[0004] As described in Patent Document 1, when a vehicle is equipped with one gateway and each vehicle ECU is connected to that gateway, it is possible to use the gateway to detect where abnormal operation or communication failure is occurring in each vehicle ECU.

[0005] However, as the scale of a network system increases, it is conceivable to adopt a configuration in which multiple gateways (relay devices) are connected to each other so that they can communicate with each other, and at least one end device is connected to each of the multiple gateways via a communication bus. In such a configuration, since not all end devices are directly connected to one gateway, the conventional method has a problem in that, for example, when a communication failure occurs in one of the communication buses, it can be difficult to identify the location of the failure.

[0006] The present disclosure has been made in consideration of these points, and aims to provide a network system that is capable of identifying the location of a communication failure when a communication failure occurs in a large-scale network system that includes multiple relay devices. [Means for solving the problem]

[0007] In order to achieve the above object, a network system (100) according to the present disclosure is a network system in which a plurality of relay devices (10, 20, 30) are connected to each other so as to be able to communicate with each other, and at least one end device (12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36) is connected to each of the plurality of relay devices via a communication bus (11, 14, 21, 24, 31, 34), The plurality of relay devices are connected via a backbone bus (40) and a redundant bus (50), The network system includes a diagnostic mode, In diagnostic mode, The end device transmits a communication confirmation message including its own identifier at predetermined intervals, and At least one of the plurality of relay devices transfers the communication confirmation message transmitted from the terminal device to another relay device via the backbone bus and the redundant bus; The system is configured to include a diagnostic unit (S300-S350) that diagnoses the location of a communication failure if a communication failure occurs in the network system based on a communication confirmation message transferred via the backbone bus and the redundant bus while the diagnostic mode is running.

[0008] As described above, the network system according to the present disclosure has a diagnostic mode. In this diagnostic mode, an end device transmits a communication confirmation message including its own identifier at predetermined intervals. Furthermore, at least one of the multiple relay devices forwards the communication confirmation message transmitted from the end device to another relay device via the backbone bus and the redundant bus.

[0009] Therefore, when no communication failure occurs, a communication confirmation message periodically transmitted from an end device is transferred by at least one relay device via the backbone bus and the redundant bus and received by another relay device. In other words, when another relay device can successfully receive a communication confirmation message from an end device transferred by at least one relay device, it is assumed that no communication failure has occurred on the transmission path of the communication confirmation message, and conversely, when a communication confirmation message cannot be successfully received, it can be assumed that some kind of communication failure has occurred on the transmission path.

[0010] For example, if another relay device does not properly receive a communication confirmation message transferred by at least one relay device via the backbone bus, but properly receives a communication confirmation message transferred via the redundant bus, the diagnostic unit can diagnose that a communication failure has occurred in the backbone bus. Furthermore, the communication confirmation message includes an identifier of an end device. Therefore, if at least one relay device connected to an end device cannot receive a communication confirmation message from that end device, the diagnostic unit can diagnose that the communication failure is occurring in the communication bus connecting the at least one relay device and the specific end device, based on the fact that the at least one relay device cannot receive a communication confirmation message from the specific end device.

[0011] The reference numbers in parentheses above merely indicate an example of a correspondence with specific configurations in the embodiments described below, in order to facilitate understanding of the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

[0012] Furthermore, the technical features of the present disclosure other than those described above will become apparent from the following description of the embodiments and the accompanying drawings. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a configuration diagram showing a configuration of a network system according to an embodiment. [Figure 2] 10 is a flowchart showing a part of a process executed by some gateway ECUs to transfer a communication confirmation message from an end ECU. [Figure 3] 10 is a flowchart showing the remaining part of the processing executed by some of the gateway ECUs to transfer the communication confirmation message from the end ECU. [Figure 4] FIG. 10 is a diagram illustrating an example of a communication confirmation message to which communication notification information is added. [Figure 5] 10 is a flowchart showing a process executed by the gateway ECU to diagnose the location of a communication failure. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, an embodiment of a network system according to the present disclosure will be described with reference to the drawings. The network system according to the present disclosure can be used, for example, as an in-vehicle network system that enables various ECUs mounted on a vehicle to communicate with each other. However, application examples of the network system according to the present disclosure are not limited to in-vehicle network systems, and it can also be used as a network system including multiple ECUs for controlling robots, production equipment, buildings, etc.

[0015] Fig. 1 is a configuration diagram showing the configuration of a network system 100 according to this embodiment. As shown in Fig. 1, the network system 100 includes a plurality of gateway ECUs 10, 20, and 30 that function as relay devices, for example. Note that Fig. 1 shows an example in which the network system 100 includes three gateway ECUs, but the network system 100 may also be provided with two gateway ECUs, or with four or more gateway ECUs.

[0016] The network system 100 can use, for example, CAN (registered trademark, the same applies hereinafter) as a communication protocol. However, the communication protocol is not limited to CAN, and the network system 100 can employ various communication protocols such as CAN-FD, Ethernet (registered trademark), FlexRay (registered trademark), and LIN (Local Interconnect Network). Furthermore, in the network system 100, different types of communication protocols may be employed in the different communication buses 11, 14, 21, 24, 31, 34, 40, 50, and 60. In this case, each of the gateway ECUs 10, 20, and 30 is configured to have a conversion function for converting the protocol of a message when transferring a message between communication buses with different communication protocols.

[0017] The gateway ECU 10 is connected to a first communication bus 11 and a second communication bus 14. The gateway ECU 20 is connected to a third communication bus 21 and a fourth communication bus 24. The gateway ECU 30 is connected to a fifth communication bus 31 and a sixth communication bus 34. Note that while FIG. 1 shows an example in which two communication buses 11, 14, 21, 24, 31, 34 are connected to each of the gateway ECUs 10, 20, 30, the number of communication buses connected to each of the gateway ECUs 10, 20, 30 may be one, or three or more.

[0018] The first communication bus 11 is connected to end ECU 12 and end ECU 13 as end devices. The second communication bus 14 is connected to end ECU 15 and end ECU 16. The third communication bus 21 is connected to end ECU 22 and end ECU 23. The fourth communication bus 24 is connected to end ECU 25 and end ECU 26. The fifth communication bus 31 is connected to end ECU 32 and end ECU 33. The sixth communication bus 34 is connected to end ECU 35 and end ECU 36. Each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36 is, for example, an ECU (electronic control unit) for controlling a predetermined control object. Note that any of the end ECUs may calculate a predetermined physical quantity based on the detection results of a sensor. Furthermore, the number of end ECUs connected to each of the communication buses 11, 14, 21, 24, 31, and 34 may be one, or may be three or more.

[0019] Each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36 transmits and receives messages to each other to obtain information necessary for controlling each control target from and provide information to other end ECUs. Furthermore, each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36 is configured to repeatedly transmit a communication confirmation message including its own identifier at a predetermined interval when instructed to switch to a diagnostic mode by each of the gateway ECUs 10, 20, and 30 connected via the communication buses 11, 14, 21, 24, 31, and 34. The predetermined interval is set to be the same for all of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36.

[0020] When multiple end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 are connected to each communication bus 11, 14, 21, 24, 31, 34, it is preferable that the offset times from when the diagnostic mode is switched to when the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 start transmitting the connectivity confirmation message be set to be different. This makes it possible to alleviate communication congestion in a communication bus 11, 14, 21, 24, 31, 34 to which multiple end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 are connected, even if each of the multiple end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 sends a communication confirmation message.

[0021] The multiple gateway ECUs 10, 20, and 30 are connected to each other so as to be able to communicate with each other via a backbone bus 40, a redundant bus 50, and a diagnostic bus 60. The backbone bus 40 and the redundant bus 50 are used to transfer normal messages and communication confirmation messages between the multiple gateway ECUs 10, 20, and 30. In this manner, in this embodiment, the communication paths between the multiple gateway ECUs 10, 20, and 30 are duplicated. Therefore, even if a communication failure occurs in one of the backbone bus 40 and the redundant bus 50 due to a break or the like, messages can be sent and received via the other of the backbone bus 40 and the redundant bus 50. When a diagnostic device (not shown) is connected to the diagnostic connector 17 of the gateway ECU 10, the diagnostic bus 60 is used to send and receive diagnostic messages from the diagnostic device between the gateway ECU 10 and the gateway ECUs 20 and 30.

[0022] The gateway ECUs 10, 20, and 30 are computers that execute various processes such as relaying messages between the communication buses 11, 14, 21, 24, 31, 34, 40, and 50 connected thereto, and diagnosing the location of a communication fault.

[0023] The multiple gateway ECUs 10, 20, and 30 each include a processor, a memory, and a storage. The processor may be, for example, a CPU, an MPU, a GPU, or a DFP that executes predetermined processing according to software. The memory is a volatile storage medium, such as a RAM, that temporarily stores the results of the processor's calculations. The storage includes a non-volatile storage medium, such as a flash memory or a ROM. The storage stores a relay processing program for executing a process of relaying messages executed by the processor. Furthermore, the storage of each of the multiple gateway ECUs 10, 20, and 30 also stores a processing program executed in a diagnostic mode that diagnoses the location of a communication failure within the network system 100. Details of the processing program executed in the diagnostic mode in the multiple gateway ECUs 10, 20, and 30 will be described later. Note that some or all of the functions of the multiple gateway ECUs 10, 20, and 30 may be implemented by hardware, for example, using an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0024] As described above, the gateway ECU 10 has a diagnostic connector 17 to which a diagnostic device is connected. The diagnostic device transmits a message requesting the transmission of recorded diagnostic data when some abnormality occurs to, for example, the gateway ECUs 10, 20, and 30 and each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36 via the diagnostic bus 60. Then, when the diagnostic data is acquired from the gateway ECUs 10, 20, and 30 and each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36, the diagnostic device diagnoses whether or not an abnormality exists, and if an abnormality exists, the type of abnormality, based on the acquired diagnostic data.

[0025] The gateway ECU 10 further includes an exterior communication device 18. The exterior communication device 18 can communicate wirelessly with, for example, an externally installed management server. In a diagnostic mode described below, when the occurrence of a communication failure, the nature of the communication failure, and the location of the occurrence are identified, information about the communication failure may be transmitted to the management server. In this case, the management server may notify the vehicle user of the measures to be taken depending on the nature of the communication failure that has occurred. For example, if the communication failure is serious, the user may be notified to immediately bring the vehicle to a dealer or a service shop. In addition, the management server may provide the dealer or the service shop with information about the nature of the communication failure that has occurred. If the communication failure is minor, the management server may notify the user that the network system needs to be inspected, for example, during the next regular inspection.

[0026] Next, the diagnostic mode will be described in detail with reference to the flowcharts of Figures 2, 3, and 5. The diagnostic mode is executed when the vehicle is stopped and the respective terminal ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, and 36 periodically transmit communication confirmation messages without affecting the control of the vehicle. Specifically, for example, if the vehicle is an electric vehicle or a plug-in hybrid vehicle, the diagnostic mode can be executed while the secondary battery mounted on the vehicle is being charged. Alternatively, if the vehicle is an engine-equipped vehicle or a hybrid vehicle, the diagnostic mode can be executed when the vehicle is stopped and the main switch is turned off.

[0027] The diagnostic mode can be started, for example, by the gateway ECU 10 determining that the vehicle is in a state in which the diagnostic mode can be executed, and based on that determination, instructing the gateway ECUs 20 and 30 to execute the diagnostic mode. Alternatively, the diagnostic mode can be started by inputting a signal indicating that the vehicle is in a state in which the diagnostic mode can be executed to each of the gateway ECUs 10, 20, and 30 by an external device or switch.

[0028] When the diagnostic mode starts, the gateway ECUs 10, 20, 30 instruct each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 connected via the communication buses 11, 14, 21, 24, 31, 34 to switch to the diagnostic mode. Then, each of the end ECUs 12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36 transitions to the diagnostic mode in which it repeatedly transmits a communication confirmation message including its own identifier at predetermined intervals for a certain period of time.

[0029] In this embodiment, in the diagnostic mode, when the gateway ECUs 20 and 30 receive a communication confirmation message from the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36 connected to them, the gateway ECUs 20 and 30 are configured to forward the communication confirmation message to the gateway ECU 10. The flowcharts in Figures 2 and 3 show processing executed by the gateway ECUs 20 and 30 to forward the communication confirmation messages from the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36. When the diagnostic mode is started in the gateway ECUs 20 and 30, the processing shown in the flowcharts in Figures 2 and 3 is repeatedly executed at predetermined intervals individually for the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36 connected to them.

[0030] In the first step S100, the gateway ECUs 20 and 30 determine whether or not they have received a communication confirmation message from one of the terminal ECUs 22, 23, 25, 26, 32, 33, 35, and 36 connected to them. If it is determined that a communication confirmation message has been received, the gateway ECUs 20 and 30 proceed to step S110. If it is determined that a communication confirmation message has not been received, the gateway ECUs 20 and 30 proceed to step S190 in the flowchart of FIG. 3.

[0031] In step S110, since a communication confirmation message is received from one of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36, the gateway ECUs 20 and 30 add communication notification information indicating that no communication failure has occurred to the received communication confirmation message.

[0032] Here, the communication notification information will be described. FIG. 4 is a diagram showing an example of a communication confirmation message to which the communication notification information has been added. The communication confirmation message transmitted from each of the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36 includes, as the CAN message ID, a type of the transmitted message and identifier information for identifying the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36 that are the senders. In the example shown in FIG. 4, the communication notification information is added to the CAN message ID, and the CAN message ID is extended. However, the communication notification information may be added to the payload portion of the CAN message instead of the ID portion. Note that the communication confirmation message may or may not include data in the payload. If data is included, for example, when any abnormality information is recognized in each of the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36, the abnormality information may be included as data.

[0033] As shown in Figure 4, the communication notification information includes communication failure information (Backbone Fail main) indicating whether communication is impossible in the backbone bus 40, communication failure information (Backbone Fail sub) indicating whether communication is impossible in the redundant bus 50, communication failure information (Backbone Congestion main) indicating whether communication congestion (transmission backlog) has occurred in the backbone bus 40, communication failure information (Backbone Congestion sub) indicating whether communication congestion (transmission backlog) has occurred in the redundant bus 50, communication failure information (Local Fail) indicating whether communication is impossible in the communication buses 21, 24, 31, and 34 with each of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36, and communication failure information (Local Congestion) indicating whether communication congestion has occurred in the communication buses 21, 24, 31, and 34 with each of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36.

[0034] When gateway ECUs 20 and 30 detect a communication failure in communication buses 21, 24, 31, and 34, backbone bus 40, and / or redundant bus 50, they add communication notification information indicating the detected communication failure to a communication confirmation message. The method by which gateway ECUs 20 and 30 detect a communication failure in communication buses 21, 24, 31, and 34, backbone bus 40, and / or redundant bus 50 will be described later.

[0035] In step S120, the gateway ECUs 20 and 30 transfer the communication confirmation message to which the communication notification information has been added to the gateway ECU 10 via the backbone bus 40 and the redundant bus 50.

[0036] In step S130, the gateway ECUs 20 and 30 determine whether the communication confirmation message was successfully transferred via the backbone bus 40 and the redundant bus 50. In this determination, the gateway ECUs 20 and 30 transfer the communication confirmation message, but determine whether the transfer was successful or not, or whether the gateway ECUs 20 and 30 are unable to transfer the communication confirmation message because the communication load on the backbone bus 40 or the redundant bus 50 is high and the gateway ECUs 20 and 30 are waiting to send the communication confirmation message that they should have transferred.

[0037] Whether the transfer of the communication confirmation message was successful can be determined, for example, by the gateway ECUs 20 and 30 based on the monitoring results of whether the signal levels of the backbone bus 40 and the redundant bus 50 have changed in accordance with each bit of the transferred communication confirmation message. Specifically, when the gateway ECUs 20 and 30 detect a bit error in which the signal levels of the backbone bus 40 or the redundant bus 50 have not changed in accordance with each bit of the communication confirmation message, they can determine that the transfer of the communication confirmation message has failed on the backbone bus 40 or the redundant bus 50. On the other hand, when the gateway ECUs 20 and 30 detect that the signal levels of the backbone bus 40 and the redundant bus 50 have changed in accordance with each bit of the communication confirmation message, they can determine that the transfer of the communication confirmation message was successful on the backbone bus 40 and the redundant bus 50.

[0038] However, instead of or in addition to basing the determination on whether the signal levels of the backbone bus 40 and the redundant bus 50 have changed according to each bit of the transferred communication confirmation message, the determination on whether the transfer of the communication confirmation message has been successful can be based on whether the gateway ECUs 20 and 30 that transferred the communication confirmation message have received a reception confirmation message transmitted from the gateway ECU 10 via the backbone bus 40 and the redundant bus 50 in response to receiving the communication confirmation message. Specifically, if the gateway ECUs 20 and 30 receive a reception confirmation message for the communication confirmation message via the backbone bus 40 and the redundant bus 50, they can determine that the transfer of the communication confirmation message has been successful on the backbone bus 40 and the redundant bus 50. On the other hand, if the gateway ECUs 20 and 30 cannot receive a reception confirmation message for the communication confirmation message via the backbone bus 40 or the redundant bus 50, they can determine that the transfer of the communication confirmation message has failed on the backbone bus 40 or the redundant bus 50.

[0039] In step S140, the gateway ECUs 20 and 30 determine whether the inability to transfer the communication confirmation message via the backbone bus 40 or the redundant bus 50 is due to a failure to transfer the communication confirmation message or due to a transmission backlog in which the communication confirmation message to be transferred is waiting to be transmitted. If the cause is a transfer failure, the gateway ECUs 20 and 30 proceed to step S150. If the cause is a transmission backlog, the gateway ECUs 20 and 30 proceed to step S170.

[0040] In step S150, the gateway ECUs 20 and 30 determine whether the number of transfer failures of the communication confirmation message has reached a predetermined number or more. The number of transfer failures is counted for each communication confirmation message transmitted from each of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36. If it is determined that the number of transfer failures is greater than or equal to the predetermined number, the gateway ECUs 20 and 30 proceed to step S160. On the other hand, if it is determined that the number of transfer failures is less than the predetermined number, the gateway ECUs 20 and 30 end the processing shown in the flowchart of FIG. 2.

[0041] In step S160, because the number of times that the communication confirmation message transfer has failed on one of the backbone bus 40 and the redundant bus 50 has exceeded a predetermined number, the gateway ECUs 20 and 30 generate communication notification information including communication failure information indicating that communication is not possible between the backbone bus 40 and the redundant bus 50, and add the communication notification information to the communication confirmation message. Then, the gateway ECUs 20 and 30 transfer the communication confirmation message via the other of the backbone bus 40 and the redundant bus 50 that is able to communicate. At this time, it is desirable for the gateway ECUs 20 and 30 to stop transferring the communication confirmation message on the one of the backbone bus 40 and the redundant bus 50 that is unable to communicate.

[0042] In step S170, the gateway ECUs 20 and 30 determine whether the time spent waiting to transmit the communication confirmation message to be transferred, i.e., the transmission retention time, is equal to or greater than a predetermined time. If it is determined that the transmission retention time is equal to or greater than the predetermined time, the gateway ECUs 20 and 30 proceed to step S180. On the other hand, if it is determined that the transmission retention time is less than the predetermined time, the gateway ECUs 20 and 30 end the process shown in the flowchart in FIG. 2.

[0043] In step S180, gateway ECUs 20 and 30 cancel transmission of the communication confirmation message that is stuck in transmission because the transmission delay time of the communication confirmation message has reached a predetermined time or more on one of backbone bus 40 and redundant bus 50. Then, gateway ECUs 20 and 30 generate communication notification information including communication fault information indicating that a transmission delay has occurred on one of backbone bus 40 and redundant bus 50, and add this information to the communication confirmation message. Then, gateway ECUs 20 and 30 transfer the communication confirmation message via the other of backbone bus 40 and redundant bus 50, where no transmission delay has occurred.

[0044] In step S190 of the flowchart in Fig. 3, the gateway ECUs 20 and 30 determine whether a second predetermined time has elapsed without receiving a communication confirmation message from the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36. This second predetermined time is a time defined for determining whether communication is disabled via the communication buses 21, 24, 31, and 34 with the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36. If it is determined that the second predetermined time has elapsed, the gateway ECUs 20 and 30 proceed to step S200. On the other hand, if it is determined that the second predetermined time has not elapsed, the gateway ECUs 20 and 30 proceed to step S210.

[0045] In step S200, the gateway ECUs 20 and 30 generate communication notification information including communication failure information indicating that communication is not possible via the communication buses 21, 24, 31, and 34 with the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36. Furthermore, since the gateway ECUs 20 and 30 are unable to receive communication confirmation messages from the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36, they generate substitute communication confirmation messages on behalf of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36. The substitute communication confirmation message includes, as the identifier of the source ECU, the identifier of the end ECU 22, 23, 25, 26, 32, 33, 35, and 36 that is unable to receive the communication confirmation message. Then, the gateway ECUs 20 and 30 transmit the proxy communication confirmation message to which the communication notification information has been added to the gateway ECU 10 via the backbone bus 40 and the redundant bus 50.

[0046] In step S210, the gateway ECUs 20 and 30 determine whether a first predetermined time has elapsed without receiving a communication confirmation message from the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36. The first predetermined time is a time defined for determining whether communication congestion has occurred on the communication buses 21, 24, 31, and 34 with the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36, causing a delay in transmission of the communication confirmation message. The first predetermined time is set shorter than the second predetermined time. If the gateway ECUs 20 and 30 determine that the first predetermined time has elapsed, the gateway ECUs 20 and 30 proceed to step S220. On the other hand, if the gateway ECUs 20 and 30 determine that the first predetermined time has not elapsed, the gateway ECUs 20 and 30 end the processing illustrated in the flowcharts of FIGS. 2 and 3.

[0047] In step S220, the gateway ECUs 20 and 30 generate communication notification information including communication failure information indicating that communication congestion is occurring on the communication buses 21, 24, 31, and 34 with the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36. Furthermore, since the gateway ECUs 20 and 30 are unable to receive communication confirmation messages from the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36, they generate substitute communication confirmation messages on behalf of the end-point ECUs 22, 23, 25, 26, 32, 33, 35, and 36. The gateway ECUs 20 and 30 then transmit the substitute communication confirmation messages to which the communication notification information has been added to the gateway ECU 10 via the backbone bus 40 and the redundant bus 50.

[0048] Next, a process executed by the gateway ECU 10 to diagnose the location of a communication failure when a communication failure occurs in the network system 100, based on a communication confirmation message transferred via the backbone bus 40 and the redundant bus 50, will be described. Fig. 5 is a flowchart showing the process executed by the gateway ECU 10 to diagnose the location of a communication failure. The process shown in the flowchart in Fig. 5 is repeatedly executed at a predetermined interval.

[0049] 5 shows a process in which the gateway ECU 10 identifies, based on a communication confirmation message transferred from the other gateway ECUs 20 and 30, that a communication failure has occurred in the backbone bus 40, the redundant bus 50, and / or the communication buses 21, 24, 31, and 34 connecting the gateway ECUs 20 and 30 with the respective end ECUs 22, 23, 25, 26, 32, 33, 35, and 36. A communication failure in the communication buses 11 and 14 connecting the gateway ECU 10 with the end ECUs 12, 13, 15, and 16 is identified by processing in the gateway ECU 10 (not shown) based on a communication confirmation message periodically transmitted from each of the end ECUs 12, 13, 15, and 16.

[0050] In step S300, the gateway ECU 10 determines whether or not a communication confirmation message has been received via the backbone bus 40 and / or the redundant bus 50. If it is determined that a communication confirmation message has been received, the gateway ECU 10 proceeds to step S310. If it is determined that a communication confirmation message has not been received, the gateway ECU 10 ends the processing shown in the flowchart of FIG.

[0051] In step S310, the gateway ECU 10 determines whether or not the communication confirmation message has been received from both the backbone bus 40 and the redundant bus 50. If it is determined that the communication confirmation message has been received from both the backbone bus 40 and the redundant bus 50, the gateway ECU 10 proceeds to step S320. If it is determined that the communication confirmation message has been received from one of the backbone bus 40 and the redundant bus 50, the gateway ECU 10 proceeds to step S340.

[0052] In step S320, the gateway ECU 10 determines whether the received communication confirmation message is a proxy communication confirmation message generated by the gateway ECUs 20 and 30. Whether the message is a proxy communication confirmation message can be determined from the transmission message type included in the ID portion. If the message is determined to be a proxy communication confirmation message, the gateway ECU 10 proceeds to step S330. If the message is determined not to be a proxy communication confirmation message, it can be assumed that no communication failure has occurred, and the gateway ECU 10 ends the processing shown in the flowchart of FIG. 5.

[0053] In step S330, the gateway ECU 10 identifies the content of the communication failure based on the communication notification information added to the proxy communication confirmation message. Furthermore, the gateway ECU 10 identifies the location of the communication failure based on the identifier information of the sender ECU included in the ID portion of the proxy communication confirmation message. The gateway ECU 10 stores the identifiers of the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36 and connection information regarding the communication buses 21, 24, 31, and 34 to which the end ECUs 22, 23, 25, 26, 32, 33, 35, and 36 are connected. Therefore, the location of the communication failure can be identified based on the identifier information of the sender ECU. The content of the communication failure and the location of the communication failure are stored in the memory of the gateway ECU 10. Then, as described above, the gateway ECU 10 can transmit information about the communication failure to the management server via the exterior communication device 18.

[0054] In step S340, the gateway ECU 10 determines whether the communication notification information attached to the communication confirmation message received from one of the backbone bus 40 and the redundant bus 50 indicates a communication failure in the bus that cannot receive the communication confirmation message, based on the communication notification information. If the gateway ECU 10 determines that the communication notification information indicates a communication failure in the bus that cannot receive the communication confirmation message, the gateway ECU 10 proceeds to step S350. On the other hand, if the gateway ECU 10 determines that the communication notification information does not indicate a communication failure in the bus that cannot receive the communication confirmation message, the gateway ECU 10 determines that the communication failure is undetermined and temporarily ends the processing shown in the flowchart of FIG. 5.

[0055] In step S350, the gateway ECU 10 identifies the bus from which the communication confirmation message cannot be received as the location of the communication failure. Furthermore, the gateway ECU 10 identifies the nature of the communication failure based on the communication notification information. The nature of the communication failure and the location of the communication failure are stored in the memory of the gateway ECU 10. Thus, the gateway ECU 10 diagnoses that a communication failure has occurred in one of the backbone bus 40 and the redundant bus 50 based on the fact that the communication confirmation message cannot be received on one of the backbone bus 40 and the redundant bus 50 and the communication notification information added to the communication confirmation message transferred via the other of the backbone bus 40 and the redundant bus 50. This allows the gateway ECU 10 to more reliably identify the location of the communication failure.

[0056] The above describes preferred embodiments of the present disclosure, but the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms within the scope of the gist of the present disclosure.

[0057] For example, in the above-described embodiment, an example has been described in which the gateway ECU 10 diagnoses the occurrence of communication failures in the communication buses 21, 24, 31, and 34 connected to the respective gateway ECUs 20 and 30, in addition to the backbone bus 40 and the redundant bus 50. However, instead of a single gateway ECU diagnosing the occurrence of communication failures in the network system 100, multiple gateway ECUs may share the task of diagnosing the occurrence of communication failures in the network system 100.

[0058] For example, the gateway ECU 20 is configured to send a communication notification message to the gateway ECU 10, and the gateway ECU 10 is configured to diagnose communication failures in the backbone bus 40 and the redundant bus 50 between the gateway ECU 20 and the gateway ECU 20, and the communication buses 21 and 24 connected to the gateway ECU 20. The gateway ECU 30 is configured to send a communication notification message to the gateway ECU 20, and the gateway ECU 20 is configured to diagnose communication failures in the backbone bus 40 and the redundant bus 50 between the gateway ECU 20 and the gateway ECU 30, and the communication buses 31 and 34 connected to the gateway ECU 30. The gateway ECU 10 is configured to send a communication notification message to the gateway ECU 30, and the gateway ECU 30 is configured to diagnose communication failures in the backbone bus 40 and the redundant bus 50 between the gateway ECU 10 and the gateway ECU 10, and the communication buses 21 and 24 connected to the gateway ECU 10.

[0059] In the above-described embodiment, an example has been described in which the gateway ECU 10, as a diagnostic unit, diagnoses the occurrence of communication failures in the backbone bus 40, the redundant bus 50, and the communication buses 21, 24, 31, and 34 connected to the gateway ECUs 20 and 30. However, the diagnostic unit may be provided in, for example, a diagnostic device connected to the diagnostic connector or a management server that communicates via the exterior communication device 18.

[0060] In the above-described embodiment, the terminal ECUs 22, 23, 25, 26, 32, 33, 35, and 36 connected to the gateway ECUs 20 and 30 are configured to periodically transmit communication confirmation messages, but each gateway ECU 20 and 30 may also be configured to periodically transmit its own communication confirmation message. [Explanation of symbols]

[0061] 10: Gateway ECU, 11: First communication bus, 12: End ECU, 13: End ECU, 14: Second communication bus, 15: End ECU, 16: End ECU, 17: Diagnostic connector, 18: Exterior communication device, 20: Gateway ECU, 21: Third communication bus, 22: End ECU, 23: End ECU, 24: Fourth communication bus, 25: End ECU, 26: End ECU, 30: Gateway ECU, 31: Fifth communication bus, 32: End ECU, 33: End ECU, 34: Sixth communication bus, 35: End ECU, 36: End ECU, 40: Backbone bus, 50: Redundant bus, 60: Diagnostic bus, 100: Network system

Claims

1. A network system (100) in which a plurality of relay devices (10, 20, 30) are connected to each other so as to be able to communicate with each other, and at least one terminal device (12, 13, 15, 16, 22, 23, 25, 26, 32, 33, 35, 36) is connected to each of the plurality of relay devices via a communication bus (11, 14, 21, 24, 31, 34), The plurality of relay devices are connected via a backbone bus (40) and a redundant bus (50), the network system includes a diagnostic mode; In the diagnostic mode, The end device transmits a communication confirmation message including its own identifier at predetermined intervals, and At least one of the plurality of relay devices transfers the communication confirmation message transmitted from the terminal device to another relay device via the backbone bus and the redundant bus; A network system comprising a diagnostic unit (S300-S350) that diagnoses the location of a communication failure if a communication failure occurs in the network system based on the communication confirmation message transferred via the backbone bus and the redundant bus while the diagnostic mode is running.

2. 2. The network system according to claim 1, wherein said at least one relay device adds information about a communication failure that it has recognized to said communication confirmation message when said communication confirmation message is forwarded.

3. 3. The network system according to claim 2, wherein when a predetermined number of attempts to transmit the connectivity confirmation message are unsuccessful on one of the backbone bus and the redundant bus, the at least one relay device transfers the connectivity confirmation message, to which information about a communication failure that has occurred on one of the backbone bus and the redundant bus is added, via the other of the backbone bus and the redundant bus.

4. Three or more relay devices are connected to the backbone bus and the redundant bus, 3. The network system according to claim 2, wherein when a transmission congestion occurs in one of the backbone bus and the redundant bus such that the transmission waiting time of the communication confirmation message reaches a predetermined time, the at least one relay device transfers the communication confirmation message, to which information about the communication failure due to the transmission congestion that has occurred in one of the backbone bus and the redundant bus has been added, via the other of the backbone bus and the redundant bus where no transmission congestion is occurring.

5. 5. The network system of claim 3, wherein the diagnostic unit diagnoses that a communication failure has occurred in one of the backbone bus and the redundant bus based on the fact that the other relay device cannot receive the communication confirmation message on one of the backbone bus and the redundant bus, and on communication failure information attached to the communication confirmation message transferred via the other of the backbone bus and the redundant bus.

6. two or more end devices are connected to a communication bus connecting the at least one relay device and the end device; The network system described in claim 2, wherein when at least one of the relay devices determines that a communication failure due to communication congestion has occurred on the communication bus with at least one of the terminal devices based on the time during which the communication confirmation message is not received from at least one of the terminal devices reaching a first predetermined time, the relay device sends a proxy communication confirmation message to another relay device, which includes information about the communication failure due to communication congestion that has occurred on the communication bus with at least one of the terminal devices.

7. The network system described in claim 2, wherein when at least one of the relay devices determines that a communication failure has occurred on the communication bus with the terminal device, based on the fact that a second predetermined time has elapsed without receiving the communication confirmation message from the terminal device, the relay device sends a proxy communication confirmation message to the other relay device, which includes information about the communication failure that has occurred on the communication bus with the terminal device, preventing communication.

8. The network system according to claim 6 or 7, wherein the diagnostic unit diagnoses that a communication failure has occurred in a communication bus between the at least one relay device and the terminal device based on communication failure information added to the proxy communication confirmation message.

Images