Bus network fault analysis method and device, electronic equipment and storage medium
By statistically and analyzing the fault types of controllers in the CAN bus network, the problem of low convenience caused by adding hardware in the prior art is solved, and efficient fault location and cost reduction are achieved.
Patent Information
- Application Number
- CN202510677533.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-23
- Publication Date
- 2025-08-12
AI Technical Summary
In the prior art, CAN bus failure analysis requires additional hardware, resulting in low convenience and increased cost.
By counting the fault types of each controller, including message loss, controller entering a preset error state, and pin detection of bus failure, analyzing the cause of bus network failure, and using statistical results to locate faults.
The convenience and accuracy of bus network failure analysis can be improved without adding additional hardware and reduce the cost of failure analysis.
Smart Images
Figure CN120474894A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of intelligent analysis technology, and more specifically, to a bus network fault analysis method, device, electronic device, and storage medium. Background Art
[0002] The Controller Area Network (CAN) bus is a bus-type network in which all nodes (controllers) are connected. A short circuit or open circuit fault at any location will affect the entire CAN bus. Therefore, CAN bus faults need to be analyzed to locate the cause.
[0003] In the related art, it is necessary to add additional hardware to analyze CAN bus faults, which makes fault analysis inconvenient. Summary of the Invention
[0004] The embodiments of the present application provide a bus network fault analysis method, device, electronic device, and storage medium, which can improve the convenience of bus network fault analysis.
[0005] In a first aspect, an embodiment of the present application provides a method for analyzing a bus network fault, wherein the bus network includes a bus and a controller connected to the bus, and the method includes: performing statistics on at least one fault type of each controller to obtain statistical results corresponding to at least one fault type, wherein the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type, wherein the first fault type is the loss of a message sent by the controller, the second fault type is the controller entering a preset error state, and the third fault type is the detection of a bus fault by the controller pin; based on the statistical results corresponding to at least one fault type of each controller, the cause of the bus network fault is analyzed.
[0006] In this embodiment, by statistically analyzing at least one fault type of each controller, a statistical result corresponding to at least one fault type is obtained, and the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type. The first fault type is that a message sent by the controller is lost, the second fault type is that the controller enters a preset error state, and the third fault type is that a bus fault is detected by a pin of the controller. Then, based on the statistical result corresponding to at least one fault type of each controller, the cause of the bus network failure is analyzed. In this way, at least one fault type of the first fault type, the second fault type, and the third fault type can be set for each controller, and then the cause of the fault can be located using at least one fault type of the first fault type, the second fault type, and the third fault type. In this way, there is no need to add additional hardware to analyze the fault of the C bus network, thereby improving the convenience of fault analysis of the bus network.
[0007] In one possible implementation, there are multiple controllers, and based on the statistical results corresponding to at least one fault type of each controller, the fault cause of the bus network failure is analyzed, including: if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type and the third fault type of the multiple controllers do not occur, then it is determined that the fault cause of the bus network failure includes: a local fault of one of the controllers.
[0008] In this embodiment, there are multiple controllers. If the number of occurrences of the first fault type of one of the multiple controllers is not less than the number of occurrences of the first fault type of other controllers, and the number of occurrences of the first fault type of one of the controllers is at least once, and the second fault type and the third fault type of the multiple controllers do not occur, then the cause of the bus network failure is determined to include: a local fault of one of the controllers. In this way, the statistical results of the number of occurrences of the first fault type of multiple controllers and whether the second fault type and the third fault type occur can be combined to analyze whether one of the controllers has a local fault. In this way, the accuracy of determining whether the controller has a local fault can be improved.
[0009] In one possible implementation, there are multiple controllers. For any one of the multiple controllers, the messages sent by other controllers in the multiple controllers are monitored by any one controller, so that if any one controller does not receive the messages sent by other controllers within a preset interval, it records that the messages sent by other controllers are lost once, and statistics are performed on at least one fault type of each controller, including: obtaining the number of times the messages sent by other controllers are lost recorded by any one controller; and performing statistics on the number of times the messages sent by other controllers are lost recorded by any one controller to obtain the number of occurrences of the first fault type related to each controller.
[0010] In an embodiment, any controller monitors the messages sent by other controllers among a plurality of controllers, so that when any controller does not receive the messages sent by other controllers within a preset interval, it records that the messages sent by other controllers are lost once. Then, when counting at least one fault type of each controller, the number of times the messages sent by other controllers are lost recorded by any controller can be obtained; the number of times the messages sent by other controllers are lost recorded by any controller is counted, and the number of occurrences of the first fault type related to each controller is obtained. Since two controllers can detect whether the messages sent by each other are lost, this can improve the effectiveness and accuracy of message loss detection.
[0011] In one possible implementation, multiple controllers are interconnected via a bus, and based on statistical results corresponding to at least one fault type of each controller, a fault cause of the bus network is analyzed, including: based on the number of occurrences of a first fault type of each controller, at least one control pair is determined, the controller pair including a first controller and a second controller among multiple controllers, and the second controller records at least one occurrence of message loss to the first controller; based on the connection relationship between any two controllers among the multiple controllers, a wiring harness segment involved in at least one pair of controller pairs is determined; based on the wiring harness segment involved in each pair of controller pairs, the fault cause of the bus network failure is determined to include: a common wiring harness segment involved in each pair of controller pairs is broken.
[0012] In this embodiment, at least one control pair is determined based on the number of occurrences of the first fault type of each controller, and the controller pair includes a first controller and a second controller among multiple controllers, and the second controller records at least one occurrence of message loss to the first controller; based on the connection relationship between any two controllers among the multiple controllers, the wiring harness segments involved in each pair of controllers in at least one pair of controller pairs are determined; based on the wiring harness segments involved in each pair of controller pairs, the cause of the bus network failure is determined to include: the common wiring harness segment involved in each pair of controller pairs is broken. Since the faulty wiring harness segment is determined in combination with the connection relationship between multiple controllers and the number of occurrences of the first fault type, the accuracy of fault location can be improved.
[0013] In one possible implementation, there are multiple controllers, each controller includes a first pin connected to a first level line in a bus, and based on the statistical results corresponding to at least one fault type of each controller, the fault cause of the bus network failure is analyzed, including: if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then determining that the fault cause of the bus network failure includes: a wiring harness break between the first pin of one of the controllers and the first level line.
[0014] In this embodiment, if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then the fault cause of the bus network failure is determined to include: a harness break between the first pin and the first level line of one of the controllers, that is, the harness break is judged by combining the first fault type and the second fault type, which can improve the accuracy of the harness break judgment.
[0015] In one possible implementation, the controller also includes a second pin connected to a second level line in the bus, the level provided by the second level line is higher than the level provided by the first level line, and based on the statistical results corresponding to at least one fault type of each controller, analyzing the fault cause of the bus network fault, further including: if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then determining that the fault cause of the bus network fault includes: a wiring harness break between the second pin of one of the controllers and the second level line; or, if the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then determining that the fault cause of the bus network fault includes: a wiring harness break between the second pin of one of the controllers and the second level line and a wiring harness break between the first pin of one of the controllers and the first level line.
[0016] In this embodiment, if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the fault cause of the bus network failure is determined to include: a wiring harness break between the second pin of one of the controllers and the second level line; or, if the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the fault cause of the bus network failure is determined to include: a wiring harness break between the second pin of one of the controllers and the second level line and a wiring harness break between the first pin of one of the controllers and the first level line, that is, not only the wiring harness break between the first pin and the first level line can be located, but also the wiring harness break between the second pin and the second level line can be located, thereby improving the accuracy and comprehensiveness of wiring harness break positioning.
[0017] In one possible implementation, there are multiple controllers, each controller includes a first pin and a second pin, the first pin is connected to the first level line in the bus, the second pin is connected to the second level line in the bus, the level provided by the second level line is higher than the level provided by the first level line, and based on the statistical results corresponding to at least one fault type of each controller, the fault cause of the bus network failure is analyzed, including: if the second fault type and the third fault type of multiple controllers have occurred, then it is determined that the fault cause of the bus network failure includes: short circuit of the first level line and / or the second level line.
[0018] In this embodiment, if the second fault type and the third fault type of multiple controllers have occurred, the cause of the bus network failure is determined to include: short circuit of the first level line and / or the second level line, that is, the short circuit of the bus harness can also be located, thereby improving the accuracy and comprehensiveness of the fault analysis.
[0019] In the second aspect, an embodiment of the present application provides a fault analysis device for a bus network, wherein the bus network includes a bus and a controller connected to the bus, and the device includes: a statistical module for statistically analyzing at least one fault type of each controller to obtain statistical results corresponding to at least one fault type, wherein the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type, wherein the first fault type is the loss of a message sent by the controller, the second fault type is the controller entering a preset error state, and the third fault type is the detection of a bus fault by the controller's pin; a fault analysis module for analyzing the cause of a fault in the bus network based on the statistical results corresponding to at least one fault type of each controller.
[0020] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein: the memory is used to store computer programs; and the processor is used to execute the programs stored in the memory to implement the above method.
[0021] In a fourth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the above method is implemented. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Figure 1 A schematic diagram of a bus network architecture provided in an embodiment of the present application; Figure 2 A bus network fault analysis method provided in an embodiment of the present application; Figure 3 A schematic diagram of the connection relationship between multiple controllers provided in an embodiment of the present application; Figure 4A flowchart of another bus network fault analysis method provided in an embodiment of the present application; Figure 5 A schematic diagram of the structure of a bus network fault analysis device provided in an embodiment of the present application; Figure 6 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0023] In order to make the technical problems, technical solutions and beneficial effects solved by this application more clearly understood, this application is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.
[0024] The CAN bus is a bus-type network in which all nodes (controllers) are connected to a single twisted-pair cable. A short circuit or open circuit in any location can affect the entire CAN bus. Therefore, CAN bus fault analysis is necessary to locate the cause. Related technologies require additional hardware for CAN bus fault analysis, but this approach is inconvenient and increases the cost of fault analysis.
[0025] In view of this, embodiments of the present application provide a bus network fault analysis method, device, electronic device, and storage medium, which can improve the convenience of bus network fault analysis.
[0026] See also Figure 1 , Figure 1 This is a schematic diagram of the architecture of a bus 110 network provided in an embodiment of the present application. Figure 1 The bus 110 network shown may include the bus 110 and a controller 120 connected to the bus 110. The bus 110 may be, for example, a CAN bus or a Controller Area Network with Flexible Data-rate (CANFD) bus. The controller 120 in this embodiment may be, for example, an Electronic Control Unit (ECU). An ECU is a component in modern automobiles and industrial equipment responsible for monitoring and controlling the operation of various systems and components. It collects data through sensors, processes it through its internal microprocessor, and issues control commands to actuators, enabling automated and intelligent system management.
[0027] See also Figure 2 , Figure 2 A bus network fault analysis method is provided in an embodiment of the present application. Figure 2The method may be performed by an electronic device, which may be, for example, Figure 1 The controller shown, such as Figure 2 The method shown may include: S210. Statistics are collected on at least one fault type of each controller to obtain statistical results corresponding to the at least one fault type. The at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type. The first fault type is that a message sent by the controller is lost, the second fault type is that the controller enters a preset error state, and the third fault type is that a bus fault is detected by a pin of the controller. The statistical results corresponding to the first fault type indicate the number of occurrences, and the statistical results corresponding to the second fault type or the third fault type indicate whether an occurrence occurs.
[0028] In this embodiment, the controller and the bus, or between controllers, exchange messages. If a message sent by a controller is lost, for example, a message sent by the controller to the bus or between controllers, this can be considered a fault type, namely, the first fault type (also referred to as fault type 1). In this embodiment, there can be one or more controllers, and "multiple" means at least two. The preset error state can be an error state entered by the controller. In this embodiment, the error state can be, for example, a Bus-Off state (Bus-Off) in the CAN bus protocol. Bus-Off is an error recovery mechanism defined in the CAN bus protocol (ISO 11898). When a node frequently sends error frames, causing the error counter to exceed a threshold, it enters this state, forcing it to be isolated from the bus. For example, when the Transmit Error Counter (TEC) ≥ 255, the Bus-Off state is entered. It should be noted that in this embodiment, the second fault type (also referred to as fault type 2) can be considered to have occurred once when the controller enters the preset error state, or it can be considered to have occurred once after the controller enters the preset error state N times. N can be an integer not less than 2. Taking N=2 and the preset error state as the Bus-Off state as an example, if the controller enters the Bus-Off state twice, it is considered that the second fault type has occurred once. In this embodiment, a controller may include one or more pins, which are connected to the bus via the pins. If the controller pins detect a bus fault, it may be recorded as a third fault type (also referred to as fault type 3). It should be noted that for the third fault type, only controllers equipped with hardware fault detection capabilities need to count the third fault type, while controllers without hardware fault detection capabilities do not need to count the third fault type.
[0029] S220: Analyze the cause of the bus network failure based on the statistical results corresponding to at least one fault type of each controller.
[0030] In this embodiment, by statistically analyzing at least one fault type of each controller, a statistical result corresponding to at least one fault type is obtained, and the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type. The first fault type is that a message sent by the controller is lost, the second fault type is that the controller enters a preset error state, and the third fault type is that a bus fault is detected by a pin of the controller. Then, based on the statistical result corresponding to at least one fault type of each controller, the cause of the bus network failure is analyzed. In this way, at least one fault type of the first fault type, the second fault type, and the third fault type can be set for each controller, and then the cause of the fault can be located using at least one fault type of the first fault type, the second fault type, and the third fault type. In this way, there is no need to add additional hardware to analyze the fault of the C bus network, thereby improving the convenience of fault analysis of the bus network.
[0031] It should be noted that this embodiment can be to collect statistical results within a preset time period. When a bus network failure occurs within the preset time period, the cause of the bus network failure within the preset time period is analyzed based on the statistical results within the preset time period.
[0032] In a possible implementation, there are multiple controllers, and based on statistical results corresponding to at least one fault type of each controller, the cause of the bus network fault is analyzed, including: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and neither the second fault type nor the third fault type of the multiple controllers occurs, then it is determined that the cause of the bus network failure includes: a local failure of one of the controllers.
[0033] In this embodiment, the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, then it means that the first fault type has occurred in one of the controllers and the number of times the first fault type has been sent by one of the controllers is the largest.
[0034] For example, the statistical results of multiple controllers are described below in conjunction with Table 1.
[0035] Table 1 (ECU fault statistics) As shown in Table 1, the multiple ECUs include ECU1, ECU2, ECU3, ECU4, and ECU5, and ECU1, ECU2, ECU3, ECU4, and ECU5 are connected to the CAN1 bus respectively. For each ECU in ECU1, ECU2, ECU3, ECU4, and ECU5, there are counters (occurrence times) corresponding to fault type 1, fault type 2, and fault type 3 respectively. It should be noted that the numerical values corresponding to fault type 2 and fault type 3 can be the specific number of times fault type 2 and fault type 3 occur, for example, 0 indicates that the number of occurrences is 0, 1 indicates that the number of occurrences is 1, and 2 indicates that the number of occurrences is 2; it can also be a flag indicating whether fault type 2 and fault type 3 have occurred, for example, flag 1 indicates that it has occurred, and flag 0 indicates that it has not occurred.
[0036] For example, Fault Type 1 in the ECU1 column is the number of times all other ECUs in the network detected ECU1's message loss faults. Fault Type 2 in the ECU1 column is the number of times ECU1 detected a Bus-Off fault. Fault Type 3 in the ECU1 column is the number of times ECU1's pins detected a wiring harness fault.
[0037] For example, the situation where one of the controllers has a local failure is described below with reference to Table 2.
[0038] Table 2 (ECU fault statistics) As shown in Table 2, Fault Type 1 for EU1 has the highest occurrence count of 3. Fault Type 2 and Fault Type 3 for ECU2, ECU3, ECU4, and ECU5 are all 0, indicating that Fault Type 2 and Fault Type 3 have not occurred for ECU2, ECU3, ECU4, and ECU5. Therefore, the cause of the bus network failure is determined to be a local fault in ECU1. Specifically, a local fault in ECU1 could be a fault in ECU1 itself (e.g., a software fault such as a communication software failure) or a power outage (i.e., a power supply anomaly).
[0039] In general, the criteria for determining a local fault can include: ECUXXX fault type 1 (non-zero and the maximum value in this row) + fault type 2 (all zeros) + fault type 3 (all zeros). The result can be: it is determined that the ECUXXX node communication software is faulty or the ECU is powered off, not a wiring harness fault.
[0040] In this embodiment, there are multiple controllers. If the number of occurrences of the first fault type of one of the multiple controllers is not less than the number of occurrences of the first fault type of other controllers, and the number of occurrences of the first fault type of one of the controllers is at least once, and the second fault type and the third fault type of the multiple controllers do not occur, then the cause of the bus network failure is determined to include: a local fault of one of the controllers. In this way, the statistical results of the number of occurrences of the first fault type of multiple controllers and whether the second fault type and the third fault type occur can be combined to analyze whether one of the controllers has a local fault. In this way, the accuracy of determining whether the controller has a local fault can be improved.
[0041] In one possible implementation, there are multiple controllers. For any one of the multiple controllers, messages sent by other controllers are monitored by the controller so that if any one controller does not receive messages sent by other controllers within a preset interval, the controller records that the messages sent by other controllers are lost once. Statistics are collected on at least one fault type of each controller, including: The number of times that any controller records that messages sent by other controllers are lost is obtained; and the number of times that any controller records that messages sent by other controllers are lost is counted to obtain the number of occurrences of the first fault type related to each controller.
[0042] Among them, the other controllers can be controllers other than the any one controller in the multiple controllers. Exemplarily, the multiple ECUs include ECU1, ECU2, ECU3, ECU4, and ECU5. For ECU1, that is, when ECU1 acts as any one controller, ECU2, ECU3, ECU4, and ECU5 act as other controllers; for ECU2, that is, when ECU2 acts as any one controller, ECU1, ECU3, ECU4, and ECU5 act as other controllers, and so on. Detailed description is omitted here. Optionally, the controller can send messages periodically, and the preset interval time can be M multiples of the message sending period, where M can be a number greater than 1. For example, if M=5, the preset interval time is 5 times the message sending period.
[0043] For example, the message loss statistics of multiple controllers are described below with reference to Table 3.
[0044] Table 3 (ECI fault management table) As shown in Table 3, “-” indicates that the ECU does not detect whether the message it sends is lost. In other words, the two controllers can detect whether the messages sent by each other are lost.
[0045] In an embodiment, any controller monitors the messages sent by other controllers among a plurality of controllers, so that when any controller does not receive the messages sent by other controllers within a preset interval, it records that the messages sent by other controllers are lost once. Then, when counting at least one fault type of each controller, the number of times the messages sent by other controllers are lost recorded by any controller can be obtained; the number of times the messages sent by other controllers are lost recorded by any controller is counted, and the number of occurrences of the first fault type related to each controller is obtained. Since two controllers can detect whether the messages sent by each other are lost, this can improve the effectiveness and accuracy of message loss detection.
[0046] In one possible implementation, multiple controllers are interconnected via a bus. Analyzing a cause of a bus network failure based on statistical results corresponding to at least one fault type of each controller includes: Based on the number of occurrences of the first fault type of each controller, at least one control pair is determined, and the controller pair includes a first controller and a second controller among the multiple controllers, and the number of occurrences of message loss recorded by the second controller to the first controller is at least one; based on the connection relationship between any two controllers among the multiple controllers, the wiring harness segments involved in each pair of controllers in at least one pair of controller pairs are determined; based on the wiring harness segments involved in each pair of controller pairs, the cause of the bus network failure is determined to include: a common wiring harness segment involved in each pair of controller pairs is broken.
[0047] See also Figure 3 , Figure 3 This is a schematic diagram of the connection relationship between multiple controllers provided in an embodiment of the present application. Figure 3 As shown, ECU1 and ECU2 are connected through wiring harness segments 1 and 3, ECU1 and ECU3 are connected through wiring harness segments 1, 4, 5 and 6, ECU1 and ECU4 are connected through wiring harness segments 1, 4, 5 and 7, ECU1 and ECU5 are connected through wiring harness segments 1 and 2, ECU2 and ECU3 are connected through wiring harness segments 3, 4, 5 and 6, ECU2 and ECU4 are connected through wiring harness segments 3, 4, 5 and 7, ECU2 and ECU5 are connected through wiring harness segments 2 and 3, ECU3 and ECU4 are connected through wiring harness segments 6 and 7, ECU3 and ECU5 are connected through wiring harness segments 2, 4, 5 and 6, and ECU4 and ECU5 are connected through wiring harness segments 2, 4, 5 and 7. The connection diagram between multiple controllers can be organized as shown in Table 4.
[0048] Table 4 (ECU wiring harness connection table) Then, assume that the fault table is as shown in Table 5: Table 5 (ECI fault management table) As shown in Table 5, the control pairs are ECU1 and ECU2, ECU2 and ECU3, ECU2 and ECU4, and ECU2 and ECU5. Tables 4 and 5 show that the common wiring harness segment is 3, so the open circuit fault in wiring harness segment 3 can be located in this example.
[0049] In this embodiment, the fault marking table in Table 5 can be mapped to the corresponding cells in Table 4, and the common label obtained by searching for the same harness labels in all corresponding cells in Table 4 is the fault harness segment of the bus.
[0050] In this embodiment, at least one control pair is determined based on the number of occurrences of the first fault type of each controller, and the controller pair includes a first controller and a second controller among multiple controllers, and the second controller records at least one occurrence of message loss to the first controller; based on the connection relationship between any two controllers among the multiple controllers, the wiring harness segments involved in each pair of controllers in at least one pair of controller pairs are determined; based on the wiring harness segments involved in each pair of controller pairs, the cause of the bus network failure is determined to include: the common wiring harness segment involved in each pair of controller pairs is broken. Since the faulty wiring harness segment is determined in combination with the connection relationship between multiple controllers and the number of occurrences of the first fault type, the accuracy of fault location can be improved.
[0051] In one possible implementation, there are multiple controllers, each controller including a first pin connected to a first level line in a bus. Analyzing a cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller includes: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness between the first pin and the first level line of one of the controllers is broken.
[0052] In this embodiment, the first level line may be, for example, a low level line (CAN_L). The following describes the situation in which a wiring harness between the first pin of one controller and the first level line is disconnected in conjunction with Table 6.
[0053] Table 6 (ECU fault statistics) As shown in Table 6, the first fault type of ECU1 has the largest number of occurrences, and the second fault type of ECU2 has occurred, so it is determined that the wiring harness between the first pin of ECU1 and the first level line is broken, for example, CAN_L is broken.
[0054] In general, the criteria for determining whether CAN_L is open circuit may include: ECUXXX fault type 1 (non-0 and maximum) + at least one other node fault type 2 (non-0).
[0055] In this embodiment, if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then the fault cause of the bus network failure is determined to include: a harness break between the first pin and the first level line of one of the controllers, that is, the harness break is judged by combining the first fault type and the second fault type, which can improve the accuracy of the harness break judgment.
[0056] In one possible implementation, the controller further includes a second pin connected to a second level line in the bus, the second level line providing a higher level than the first level line, and analyzing a cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller, further comprising: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness break between the second pin and the second level line of one of the controllers; or, if the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness break between the second pin and the second level line of one of the controllers and a wiring harness break between the first pin and the first level line of one of the controllers.
[0057] In this embodiment, the second level line can be, for example, a high level line (CAN_H). CAN_L and CAN_H can be twisted pairs. By alternating the twisted pairs, the two lines are exposed to approximately equal external interference, thereby canceling out the interference at the receiving end through differential comparison. The first and second pins can be transceiver error (EER) pins. The transceiver monitors various operating parameters such as temperature, voltage, and bus status in real time. When an abnormality is detected, the transceiver determines that an error has occurred. Once an error is detected, the transceiver outputs an error signal through the ERR pin. This signal typically represents a level change (e.g., from high to low) to indicate the occurrence of an error. When the error condition disappears, the transceiver automatically restores the ERR pin to indicate that the error has been resolved.
[0058] The following describes the situation where the wiring harness between the second pin of one of the controllers and the second level line is broken in conjunction with Table 7.
[0059] Table 7 (ECU fault statistics) As shown in Table 7, the number of occurrences corresponding to the first fault type of ECU1 is the largest and is 3 times, and the second fault types of all ECUs have not occurred, and the third fault type of ECU1 has occurred, then it is determined that the wiring harness between the second pin of ECU1 and the second level line is broken, for example, it may be a CAN_N break.
[0060] In general, the criteria for determining whether CAN_N is open circuit can include: ECUXXX fault type 1 (non-0 and maximum) + other node fault type 2 (all 0) + ECUXXX fault type 3 (non-0 if any).
[0061] The following describes the situation in which the wiring harness between the second pin and the second level line and the wiring harness between the first pin and the first level line of one of the controllers is broken in conjunction with Table 8.
[0062] Table 8 (ECU fault statistics) As shown in Table 8, the number of occurrences corresponding to the first fault type of ECU1 is 1 (not necessarily the maximum), the second fault type of all ECUs has not occurred, and the third fault type of ECU1 has occurred. Therefore, it is determined that the wiring harness between the second pin and the second level line of ECU1 and the wiring harness between the first pin and the first level line are broken, for example, the CAN_L+CAN_N circuit may be broken. A CAN_L+CAN_N circuit break may also mean that the ECU is powered off.
[0063] In general, the criteria for determining whether CAN_L+CAN_N is open can include: ECUXXX fault type 1 (non-0) + other node fault type 2 (all 0) + ECUXXX fault type 3 (non-0 if any).
[0064] In this embodiment, if the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the fault cause of the bus network failure is determined to include: a wiring harness break between the second pin of one of the controllers and the second level line; or, if the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the fault cause of the bus network failure is determined to include: a wiring harness break between the second pin of one of the controllers and the second level line and a wiring harness break between the first pin of one of the controllers and the first level line, that is, not only the wiring harness break between the first pin and the first level line can be located, but also the wiring harness break between the second pin and the second level line can be located, thereby improving the accuracy and comprehensiveness of wiring harness break positioning.
[0065] In one possible implementation, there are multiple controllers, each controller including a first pin and a second pin, the first pin being connected to a first level line in a bus, the second pin being connected to a second level line in the bus, the second level line providing a higher level than the first level line, and analyzing a cause of a bus network failure based on statistical results corresponding to at least one fault type of each controller, including: If both the second fault type and the third fault type of the plurality of controllers have occurred, it is determined that the cause of the bus network fault includes: a short circuit of the first level line and / or the second level line.
[0066] In this embodiment, the first level line and / or the second level line is short-circuited, which may be CAN_H and CAN_L short-circuited, CAN_H short-circuited to the power supply or ground, CAN_L short-circuited to the power supply, etc., which is not limited here.
[0067] The following describes the situation where the first level line and / or the second level line is short-circuited with reference to Table 9.
[0068] Table 9 (ECU fault statistics) As shown in Table 9, if the second fault type and the third fault type have occurred in all ECUs, it is determined that the first level line and / or the second level line is short-circuited.
[0069] In general, the judgment criteria for wiring harness short circuit can include: all ECU fault type 2 (non-0) + all ECU fault type 3 (non-0 if any).
[0070] In this embodiment, if the second fault type and the third fault type of multiple controllers have occurred, the cause of the bus network failure is determined to include: short circuit of the first level line and / or the second level line, that is, the short circuit of the bus harness can also be located, thereby improving the accuracy and comprehensiveness of the fault analysis.
[0071] It should be noted that the table in this embodiment can be updated periodically according to settings, for example, once every 1 second, to improve the accuracy of fault location.
[0072] In conjunction with the above embodiments, this embodiment can locate faults including, but not limited to, local ECU faults, CAN harness disconnect faults, locating CAN harness disconnect points (also known as disconnected harness segments), and CAN harness short-circuit faults. For local ECU faults, refer to the descriptions in Table 2; for locating CAN harness disconnect segments, refer to the descriptions in Tables 4-5; for locating CAN harness disconnect points, refer to the descriptions in Tables 6-8; and for CAN harness short-circuit faults, refer to the descriptions in Table 9. These details are omitted here. Below, an exemplary embodiment of the device of this embodiment is described.
[0073] For ease of understanding, the following example provides a fault analysis process to illustrate this solution. Figure 4 , Figure 4 This is a flow chart of another bus network fault analysis method provided in an embodiment of the present application. Figure 4 The method shown may include: S410: Set three types of CAN bus conventional fault judgment methods.
[0074] The three types of CAN bus common faults include fault type 1, fault type 2, and fault type 3. Fault type 1: ECUA detects that the ECUB bus message is lost; Fault type 2: ECUA bus Bus-Off fault; Fault type 3: ECUA detects a hardware fault (some transceivers do not have hardware fault detection function).
[0075] S420. Design a table based on the CAN network topology.
[0076] The CAN network topology of this embodiment can refer to Figure 3For more information, please refer to the relevant descriptions of Tables 1, 3, and 4.
[0077] S430: Count the number of occurrences of the above three types of common faults according to the set time period, and update the data in the table.
[0078] In this embodiment, the updated tables may be Tables 1, 3, and 4.
[0079] S440: Automatically determine CAN bus related fault information according to the defined fault determination criteria.
[0080] In this embodiment, determining CAN bus related fault information may be determining the cause of the fault, such as ECU local fault, CAN harness disconnection fault, CAN harness disconnection point location, and CAN harness short circuit fault.
[0081] The ECU node local fault determination criteria are: ECUXXX fault type 1 (non-zero and the maximum value in this row) + fault type 2 (all zeros) + fault type 3 (all zeros). Result: The ECUXXX node communication software fault or ECU power failure is determined, not a wiring harness fault.
[0082] Among them, the wiring harness disconnect fault determination includes determination methods 1, 2, and 3. Method 1 determination criteria: ECUXXX fault type 1 (non-0 and maximum) + at least one other node fault type 2 (non-0). Determination result: ECUXXX CAN wiring harness CAN_L node is disconnected. Method 2 determination criteria: ECUXXX fault type 1 (non-0 and maximum) + other node fault type 2 (all 0) + ECUXXX fault type 3 (if any, non-0). Determination result: ECUXXX CAN wiring harness CAN_H is disconnected. Method 3 determination criteria: ECUXXX fault type 1 (non-0) + other node fault type 2 (all 0) + ECUXXX fault type 3 (if any, non-0). Determination result: ECUXXX CAN wiring harness (CAN_L + CAN_H) is disconnected or the ECUXXX controller is powered off.
[0083] Among them, the CAN harness break positioning method is to locate the common harness segment involved in the controller.
[0084] Among them, the judgment criteria for CAN harness short-circuit fault: all ECU fault type 2 (non-0) + all ECU fault type 3 (non-0 if any), judgment result: a harness short-circuit fault occurs in this network.
[0085] S450: Output the diagnosed CAN bus fault information.
[0086] In this embodiment, the fault information obtained in S440 may be output.
[0087] See also Figure 5 , Figure 5 This is a schematic diagram of the structure of a bus network fault analysis device provided in an embodiment of the present application. Figure 5 The device shown can be applied to electronic devices, and the device may include a data statistics module 510 and a fault analysis module 520, wherein: The statistical module 510 is used to collect statistics on at least one fault type of each controller to obtain statistical results corresponding to the at least one fault type, where the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type. The first fault type is the loss of a message sent by the controller, the second fault type is the controller entering a preset error state, and the third fault type is the detection of a bus fault by a pin of the controller. The fault analysis module 520 is used to analyze the cause of the bus network failure based on the statistical results corresponding to the at least one fault type of each controller.
[0088] In a possible implementation, there are multiple controllers. When analyzing the cause of a bus network failure based on statistical results corresponding to at least one fault type of each controller, the fault analysis module 520 may be used to: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and neither the second fault type nor the third fault type of the multiple controllers occurs, then it is determined that the cause of the bus network failure includes: a local failure of one of the controllers.
[0089] In a possible implementation, there are multiple controllers. For any one of the multiple controllers, messages sent by other controllers are monitored by the controller, so that if any one controller does not receive messages sent by other controllers within a preset interval, the controller records that the messages sent by other controllers are lost once. When the statistical module 510 collects statistics on at least one fault type of each controller, it can be used to: The number of times that any controller records that messages sent by other controllers are lost is obtained; and the number of times that any controller records that messages sent by other controllers are lost is counted to obtain the number of occurrences of the first fault type related to each controller.
[0090] In one possible implementation, multiple controllers are interconnected via a bus. The fault analysis module 520 analyzes the cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller, and can be used to: Based on the number of occurrences of the first fault type of each controller, at least one control pair is determined, and the controller pair includes a first controller and a second controller among the multiple controllers, and the number of occurrences of message loss recorded by the second controller to the first controller is at least one; based on the connection relationship between any two controllers among the multiple controllers, the wiring harness segments involved in each pair of controllers in at least one pair of controller pairs are determined; based on the wiring harness segments involved in each pair of controller pairs, the cause of the bus network failure is determined to include: a common wiring harness segment involved in each pair of controller pairs is broken.
[0091] In one possible implementation, there are multiple controllers, each of which includes a first pin connected to a first level line in the bus. The fault analysis module 520 analyzes the cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller, and can be used to: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness between the first pin and the first level line of one of the controllers is broken.
[0092] In one possible implementation, the controller further includes a second pin connected to a second level line in the bus, where the second level line provides a higher level than the first level line. The fault analysis module 520 may be used to analyze the cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller, and further include: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault types of other controllers in the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness break between the second pin and the second level line of one of the controllers, or, if the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault types of other controllers have not occurred, and the third fault type of one of the controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness break between the second pin and the second level line of one of the controllers and a wiring harness break between the first pin and the first level line of one of the controllers.
[0093] In one possible implementation, there are multiple controllers, each of which includes a first pin and a second pin, the first pin being connected to a first level line in the bus, and the second pin being connected to a second level line in the bus, the level provided by the second level line being higher than the level provided by the first level line. The fault analysis module 520 analyzes the cause of a bus network fault based on statistical results corresponding to at least one fault type of each controller, and can be used to: If both the second fault type and the third fault type of the plurality of controllers have occurred, it is determined that the cause of the bus network fault includes: a short circuit of the first level line and / or the second level line.
[0094] It should be noted that those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the devices and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. In the several embodiments provided in the present application, the coupling between modules can be electrical. In addition, the various functional modules in the various embodiments of the present application can be integrated into a processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules.
[0095] The present application also provides an electronic device 60, please refer to Figure 6 , including a processor 610 and a memory 620, wherein the memory 610 is used to store computer programs; the processor 620 is used to execute the programs stored in the memory 610 to implement the bus network fault analysis method introduced in any embodiment of the present application. The electronic device 60 can be, for example, a vehicle.
[0096] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the bus network fault analysis method introduced in any embodiment of the present application is implemented.
[0097] In this application, a plurality refers to two or more.
[0098] In this application, unless otherwise expressly defined, the terms "mounted," "connected," and "connected" should be interpreted broadly. For example, they can refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediary; and internal communication between two components. A person of ordinary skill in the art will understand the specific meanings of these terms in this application.
[0099] The terms "first," "second," "third," "fourth," etc. (if any) in this application are used to distinguish similar objects and are not necessarily used to describe a particular sequential order.
[0100] The term "and / or" in this application simply describes an association between related objects, indicating that three possible relationships exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this application generally indicates that the related objects are in an "or" relationship.
[0101] Unless otherwise specified, all steps of this application may be performed sequentially or randomly. For example, "a method includes steps A and B" means that the method may include steps A and B performed sequentially, or steps B and A performed sequentially. For example, "a method may also include step C" means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or steps A, C, and B, or steps C, A, and B, etc.
[0102] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.
Claims
1. A bus network fault analysis method, characterized in that: The bus network includes a bus and a controller connected to the bus, and the method includes: performing statistics on at least one fault type of each controller to obtain a statistical result corresponding to the at least one fault type, the at least one fault type including at least one of a first fault type, a second fault type, and a third fault type, the first fault type being loss of a message sent by the controller, the second fault type being entry of the controller into a preset error state, and the third fault type being detection of a bus fault by a pin of the controller, the statistical result corresponding to the first fault type indicating the number of occurrences, and the statistical result corresponding to the second fault type or the third fault type indicating whether the fault occurred; Based on the statistical results corresponding to the at least one fault type of each controller, a fault cause of the bus network fault is analyzed.
2. The method according to claim 1, characterized in that There are multiple controllers, and analyzing the cause of the bus network failure based on the statistical results corresponding to the at least one fault type of each controller includes: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and neither the second fault type nor the third fault type of the multiple controllers occurs, then it is determined that the cause of the bus network failure includes: a local failure of one of the controllers.
3. The method according to claim 1 or 2, characterized in that There are multiple controllers. For any one of the multiple controllers, messages sent by other controllers in the multiple controllers are monitored by the any one controller, so that if the any one controller does not receive messages sent by the other controllers within a preset interval, a message sent by the other controller is recorded as lost once. The statistics of at least one fault type of each controller include: Obtaining the number of times the message sent by the other controller is lost, recorded by any one of the controllers; The number of times the messages sent by the other controllers are lost and recorded by any one of the controllers is counted to obtain the number of times the first fault type occurs related to each controller.
4. The method according to claim 3, characterized in that The plurality of controllers are connected to each other via the bus, and the analyzing a cause of a fault in the bus network based on a statistical result corresponding to the at least one fault type of each controller includes: Determining at least one controller pair based on the number of occurrences of the first fault type of each of the controllers, the controller pair comprising a first controller and a second controller among the plurality of controllers, wherein the number of occurrences of message loss recorded by the second controller to the first controller is at least one; determining, based on a connection relationship between any two controllers among the plurality of controllers, a wiring harness segment involved in each pair of controllers in the at least one pair of controllers; Determining the cause of the bus network failure based on the harness segments involved in each pair of controllers includes: a common harness segment involved in each pair of controllers is broken.
5. The method according to claim 1, wherein There are a plurality of controllers, each of which includes a first pin connected to a first level line in the bus. Analyzing a cause of a fault in the bus network based on statistical results corresponding to the at least one fault type of each controller includes: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least once, and the second fault type of at least one of the other controllers has occurred, then the cause of the failure of the bus network is determined to include: a wiring harness between the first pin of one of the controllers and the first level line is broken.
6. The method according to claim 5, characterized in that The controller further includes a second pin connected to a second level line in the bus, the second level line providing a higher level than the first level line, and the analyzing a cause of a fault in the bus network based on the statistical results corresponding to the at least one fault type of each controller further includes: If the number of occurrences corresponding to the first fault type of one of the multiple controllers is not less than the number of occurrences corresponding to the first fault type of other controllers among the multiple controllers, and the number of occurrences corresponding to the first fault type of one of the controllers is at least one, and the second fault type of the other controllers has not occurred, and the third fault type of one of the controllers has occurred, then it is determined that the cause of the bus network failure includes: a harness break between the second pin and the second level line of one of the controllers; or If the first fault type of one of the controllers occurs at least once, the second fault type of the other controllers has not occurred, and the third fault type of one of the controllers has occurred, then the cause of the bus network failure is determined to include: a wiring harness break between the second pin of one of the controllers and the second level line, and a wiring harness break between the first pin of one of the controllers and the first level line.
7. The method according to claim 1, 5 or 6, characterized in that There are multiple controllers, each of which includes a first pin and a second pin, the first pin is connected to a first level line in the bus, the second pin is connected to a second level line in the bus, and a level provided by the second level line is higher than a level provided by the first level line. Analyzing a cause of a fault in the bus network based on statistical results corresponding to the at least one fault type of each controller includes: If both the second fault type and the third fault type have occurred in a plurality of controllers, it is determined that the cause of the bus network fault includes: the first level line and / or the second level line is short-circuited.
8. A bus network fault analysis device, characterized in that: The bus network includes a bus and a controller connected to the bus, and the device includes: a statistics module, configured to collect statistics on at least one fault type of each controller to obtain a statistical result corresponding to the at least one fault type, wherein the at least one fault type includes at least one of a first fault type, a second fault type, and a third fault type, wherein the first fault type is loss of a message sent by the controller, the second fault type is entry of the controller into a preset error state, and the third fault type is detection of a bus fault by a pin of the controller; A fault analysis module is used to analyze the cause of the fault of the bus network based on the statistical results corresponding to the at least one fault type of each controller.
9. An electronic device, characterized in that: comprising a processor and a memory, wherein: Memory for storing computer programs; A processor, configured to execute a program stored in a memory to implement the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.