A two-wheeled vehicle fault positioning method, system and related products

Abstract

The application discloses a two-wheeled vehicle fault positioning method and system and related products. A pre-constructed fault correlation graph is acquired. For each fault correlation link in the fault correlation graph, link collection data of the fault correlation link within a preset time period is acquired, the link collection data including vehicle data uploaded by a two-wheeled vehicle cluster in a region covered by the fault correlation link and link backend operation data. For each link node in the fault correlation link, a node fault confidence corresponding to the link node is obtained through calculation and processing based on the link collection data. A link node with the highest node fault confidence in the fault correlation graph is taken as a fault root cause node of the two-wheeled vehicle within the preset time period, wherein the fault root cause node is a node with the greatest impact in two-wheeled vehicle Internet of Vehicles backend operation. In this way, the two-wheeled vehicle fault positioning performance is improved.

Description

Technical Field

[0001] This application relates to the field of two-wheeled vehicle technology, and in particular to a two-wheeled vehicle fault location method, system and related products. Background Technology

[0002] With the continuous advancement of intelligentization and connectivity in electric two-wheelers, the electric two-wheeler vehicle networking industry is developing rapidly. Vehicle networking service platforms need to access and manage a massive number of distributed vehicle-mounted terminal devices nationwide. Currently, the backend architecture of two-wheeler vehicle networking generally adopts a four-level distributed backend architecture: terminal layer - gateway layer - service layer - data layer. The terminal layer consists of the vehicle-mounted T-BOX (vehicle-mounted remote information processing terminal) module, responsible for collecting data such as vehicle positioning, battery status, and operating conditions, and reporting it via the TCP (Transmission Control Protocol) private protocol. The gateway layer is a multi-regional deployed gateway cluster, undertaking functions such as terminal connection, data forwarding, and protocol conversion. The service layer includes core business services such as positioning, battery status, payment callback, and remote control, supporting user applications (APP) and management platform calls. The data layer uses a distributed TiDB database cluster to store massive amounts of business data such as vehicle trajectory, status records, and transaction logs.

[0003] In the actual operation and maintenance of this four-tiered architecture, faults can easily propagate and spread along the terminal-gateway-service-data link, and anomalies at any level can affect the overall platform's business stability. Related technical solutions primarily achieve fault identification by separately detecting each layer within the architecture. This involves deploying independent detection tools at the terminal, gateway, service, and data layers to collect operational metrics for each layer and identify local anomalies, thereby enabling subsequent maintenance work. However, this layered, independent detection approach only achieves anomaly identification at a single layer, resulting in fragmented alarm information. Maintenance personnel find it difficult to trace the causal transmission relationship of faults, accurately pinpoint the root cause, and experience low fault-finding efficiency.

[0004] Therefore, how to improve the fault location performance of two-wheeled vehicles is a key issue that urgently needs to be addressed by those skilled in the art. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, system, and related products for locating faults in two-wheeled vehicles, thereby improving the performance of fault location for these vehicles.

[0006] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a method for locating faults in two-wheeled vehicles, including: Obtain a pre-constructed fault association map, wherein the fault association map is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. For each fault-related link in the fault association map, the link collection data of the fault-related link within a preset time period is obtained, wherein the link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster in the area covered by the fault-related link, and the back-end operation data of the link; For each link node in the fault-related link, the node fault confidence level corresponding to the link node is obtained by calculation and processing based on the link collection data. The link node with the highest fault confidence in the fault association graph is taken as the root cause node of the two-wheeled vehicle fault within the preset time period, wherein the root cause node is the node with the greatest impact on the back-end operation and maintenance of the two-wheeled vehicle network.

[0007] In one feasible implementation, acquiring the link data of the fault-related link within a preset time period includes: Based on this fault association link, determine the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link; Within a preset time period, vehicle data uploaded by the two-wheeled vehicle cluster in the area, as well as link backend operation data generated by the gateway, the service instance, and the data table, are collected.

[0008] In one feasible implementation, the step of calculating and processing the link-collected data to obtain the node fault confidence level corresponding to the link node includes: The link collection data is extracted and processed to obtain multiple fault features corresponding to the link collection data, wherein the multiple fault features include at least the percentage of abnormal terminal numbers, gateway packet loss rate, service response time, and number of slow queries in data tables. Based on the multiple fault features, the fault feature weights corresponding to the multiple fault features are determined respectively, wherein the greater the impact of the fault feature on the root cause determination, the higher the corresponding fault feature weight. The node fault confidence level is obtained by calculating and processing based on the multiple fault features and the fault feature weights corresponding to the multiple fault features.

[0009] In one feasible implementation, before calculating the node fault confidence level corresponding to the link node based on the plurality of fault features and the fault feature weights corresponding to the plurality of fault features, the method further includes: Obtain the prior probability that the link node is the root cause node, and obtain the conditional probability of each fault feature occurring when the link node fails. The step of calculating and processing based on the multiple fault features and their corresponding fault feature weights to obtain the node fault confidence level for the link node includes: Based on whether the multiple fault features are abnormal, the prior probability, the conditional probability of each fault feature occurring when the link node fails, and the fault feature weights corresponding to the multiple fault features are calculated and processed to obtain the node fault confidence level corresponding to the link node.

[0010] In one feasible implementation, after identifying the link node with the highest fault confidence in the fault correlation graph as the root cause node of the two-wheeled vehicle's fault within the preset time period, the method further includes: Based on the root cause node of the fault, the fault association graph is traversed to obtain the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables corresponding to the root cause node of the fault. Based on the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables, the node fault level corresponding to the root cause node is determined. The node fault level includes a first fault level, a second fault level, and a third fault level, wherein the severity of the third fault level is greater than that of the second fault level, and the severity of the second fault level is greater than that of the first fault level.

[0011] In one feasible implementation, the method further includes: If the node failure level is the first failure level, then the first self-healing strategy is executed, wherein the first self-healing strategy includes restarting the abnormal service instance and simultaneously cleaning up the service instance cache and resetting the thread pool. If the node failure level is the second failure level, then the second self-healing strategy is executed, wherein the second self-healing strategy includes database index optimization, connection pool expansion, traffic shaping, and service instance expansion. If the node failure level is the third failure level, then the third self-healing strategy is executed, wherein the third self-healing strategy includes switching the primary gateway of the failure area to the backup gateway, updating the routing rules, and isolating the failure node.

[0012] In one feasible implementation, the process of obtaining the percentage of abnormal terminal numbers is as follows: Based on the vehicle data uploaded by the two-wheeled vehicle cluster in the area, the vehicle information corresponding to each two-wheeled vehicle is obtained; For each two-wheeled vehicle, if there is an original abnormal code in the vehicle information corresponding to the two-wheeled vehicle, then the terminal model and batch number corresponding to the two-wheeled vehicle are obtained from the vehicle information corresponding to the two-wheeled vehicle. Using the anomaly code mapping table, the target anomaly code corresponding to the two-wheeled vehicle is determined based on the original anomaly code, terminal model, and batch number. The anomaly code mapping table is used to unify the anomaly code specifications for different terminal models and batch numbers, and the target anomaly code is used to determine that the two-wheeled vehicle is in a terminal anomaly state. The number of two-wheeled vehicles with target anomaly codes within the area is counted, along with the total number of two-wheeled vehicles within the area. Based on the ratio of the number of two-wheeled vehicles with target anomaly codes to the total number of two-wheeled vehicles, the percentage of terminal anomalies is obtained.

[0013] The second aspect of this application provides a two-wheeled vehicle fault location system, including: The fault association graph acquisition unit is used to acquire a pre-constructed fault association graph, wherein the fault association graph is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. The link data acquisition unit is used to acquire the link collection data of each fault-related link in the fault association map within a preset time period. The link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster in the area covered by the fault-related link, and the link backend operation data. The node confidence acquisition unit is used to calculate and process the link data collected for each link node in the fault-related link to obtain the node fault confidence corresponding to the link node. The root cause node determination unit is used to identify the link node with the highest fault confidence in the fault association graph as the root cause node of the two-wheeled vehicle fault within the preset time period, wherein the root cause node is the node with the greatest impact on the back-end operation and maintenance of the two-wheeled vehicle network.

[0014] In one feasible implementation, the link data acquisition unit is specifically used for: Based on this fault association link, determine the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link; Within a preset time period, vehicle data uploaded by the two-wheeled vehicle cluster in the area, as well as link backend operation data generated by the gateway, the service instance, and the data table, are collected.

[0015] In one feasible implementation, the node confidence acquisition unit includes: The fault feature acquisition unit is used to extract and process the link collection data to obtain multiple fault features corresponding to the link collection data, wherein the multiple fault features include at least the percentage of abnormal terminal numbers, gateway packet loss rate, service response time, and number of slow queries in the data table. The feature weight determination unit is used to determine the fault feature weights corresponding to the multiple fault features based on the multiple fault features, wherein the greater the influence of the fault feature on the root cause determination, the higher the corresponding fault feature weight. The node confidence calculation unit is used to perform calculations based on the multiple fault features and the fault feature weights corresponding to the multiple fault features to obtain the node fault confidence corresponding to the link node.

[0016] In one feasible implementation, the system further includes: The prior conditional probability acquisition unit is used to acquire the prior probability of the link node as the root cause node, and to acquire the conditional probability of each fault feature occurring when the link node fails. The node confidence calculation unit is specifically used for: Based on whether the multiple fault features are abnormal, the prior probability, the conditional probability of each fault feature occurring when the link node fails, and the fault feature weights corresponding to the multiple fault features are calculated and processed to obtain the node fault confidence level corresponding to the link node.

[0017] In one feasible implementation, the system further includes: The association graph traversal unit is used to traverse the fault association graph based on the fault root cause node to obtain the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables corresponding to the fault root cause node. The fault level determination unit is used to determine the node fault level corresponding to the root cause node based on the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables. The node fault level includes a first fault level, a second fault level, and a third fault level, wherein the severity of the third fault level is greater than that of the second fault level, and the severity of the second fault level is greater than that of the first fault level.

[0018] In one feasible implementation, the system further includes: The first self-healing execution unit is used to execute a first self-healing strategy if the node failure level is the first failure level, wherein the first self-healing strategy includes restarting the abnormal service instance and simultaneously cleaning up the service instance cache and resetting the thread pool. The second self-healing execution unit is used to execute a second self-healing strategy if the node failure level is the second failure level, wherein the second self-healing strategy includes database index optimization, connection pool expansion, traffic shaping, and service instance expansion. The third self-healing execution unit is used to execute a third self-healing strategy if the node failure level is the third failure level. The third self-healing strategy includes switching the primary gateway of the fault area to the backup gateway, updating routing rules, and isolating the faulty node.

[0019] In one feasible implementation, the fault feature acquisition unit is specifically used for: Based on the vehicle data uploaded by the two-wheeled vehicle cluster in the area, the vehicle information corresponding to each two-wheeled vehicle is obtained; For each two-wheeled vehicle, if there is an original abnormal code in the vehicle information corresponding to the two-wheeled vehicle, then the terminal model and batch number corresponding to the two-wheeled vehicle are obtained from the vehicle information corresponding to the two-wheeled vehicle. Using the anomaly code mapping table, the target anomaly code corresponding to the two-wheeled vehicle is determined based on the original anomaly code, terminal model, and batch number. The anomaly code mapping table is used to unify the anomaly code specifications for different terminal models and batch numbers, and the target anomaly code is used to determine that the two-wheeled vehicle is in a terminal anomaly state. The number of two-wheeled vehicles with target anomaly codes within the area is counted, along with the total number of two-wheeled vehicles within the area. Based on the ratio of the number of two-wheeled vehicles with target anomaly codes to the total number of two-wheeled vehicles, the percentage of terminal anomalies is obtained.

[0020] A third aspect of this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the two-wheeled vehicle fault location method as described in any one of the first aspects of the embodiments of this application.

[0021] The fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the two-wheeled vehicle fault location method as described in any one of the first aspects of this application.

[0022] Compared with the prior art, this application has the following beneficial effects: In this application's technical solution, firstly, a pre-constructed fault association map is obtained. This map is built based on multiple fault association links, each including a terminal node, a gateway node, a service node, and a data table node. The terminal node at the start of the link points to the gateway node, the gateway node points to the service node, and the service node points to the data table node at the end of the link. Next, for each fault association link in the map, link collection data is acquired within a preset time period. This data includes vehicle data uploaded by the two-wheeled vehicle cluster within the area covered by the link, as well as backend operational data. Thus, this application constructs a full-level fault association topology covering terminals, gateways, services, and data tables, associating the originally independent and dispersed four-level architecture nodes as a whole. It also integrates front-end vehicle data with backend operational data from each level, breaking the problem of independent detection and data fragmentation at each level in traditional solutions, and achieving the fusion and aggregation of fault data across the entire vehicle network link.

[0023] Subsequently, for each node in the fault-related link, calculations are performed based on the collected link data to obtain the node fault confidence level. Finally, the link node with the highest fault confidence level in the fault association graph is selected as the root cause node of the two-wheeled vehicle fault within a preset time period, where the root cause node is the node with the greatest impact on the backend operation and maintenance of the two-wheeled vehicle network. In this way, by calculating the fault confidence level of each node in the link one by one, this application quantifies the degree of fault contribution of each node in a probabilistic manner, and selects the node with the highest confidence level and the greatest impact as the root cause of the fault from a global association perspective. This effectively solves the defects of fragmented hierarchical detection alarms, chaotic fault causal relationships, and inability to accurately locate the root cause in related technical solutions, and realizes integrated and accurate full-link fault location in the two-wheeled vehicle network scenario, significantly improving fault investigation efficiency and platform operation and maintenance stability, thereby improving the fault location performance of two-wheeled vehicles. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a two-wheeled vehicle fault location method provided in this application embodiment; Figure 2 This is a schematic diagram of link acquisition data in a two-wheeled vehicle fault location method provided in an embodiment of this application; Figure 3A flowchart illustrating the process of obtaining node fault confidence in a two-wheeled vehicle fault location method provided in this application embodiment; Figure 4 A complete flowchart of a two-wheeled vehicle fault location method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a two-wheeled vehicle fault location system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0027] It should be noted that the "first" and "second" in the names such as "first" and "second" (if they exist) mentioned in the embodiments of this application are only used as name identifiers and do not represent the first and second in order.

[0028] As described earlier, with the continuous advancement of the intelligentization and connectivity of electric two-wheelers, the electric two-wheeler vehicle networking industry is developing rapidly. Vehicle networking service platforms need to access and manage the massive number of vehicle-mounted terminal devices distributed nationwide. Currently, the backend of two-wheeler vehicle networking generally adopts a four-level distributed backend architecture: terminal layer - gateway layer - service layer - data layer. The terminal layer is the vehicle-mounted T-BOX module, which is responsible for collecting data such as vehicle positioning, battery status, and operating conditions, and reporting them through a TCP private protocol. The gateway layer is a gateway cluster deployed in multiple regions, which undertakes functions such as terminal connection, data forwarding, and protocol conversion. The service layer includes core business services such as positioning, battery status, payment callback, and remote control, supporting user APP and management platform calls. The data layer adopts a distributed TiDB database cluster to store massive amounts of business data such as vehicle trajectory, status records, and transaction logs.

[0029] In the actual operation and maintenance of this four-tiered architecture, faults can easily propagate and spread along the terminal-gateway-service-data link, and anomalies at any level can affect the overall platform's business stability. Related technical solutions primarily achieve fault identification by separately detecting each layer within the architecture. This involves deploying independent detection tools at the terminal, gateway, service, and data layers to collect operational metrics for each layer and identify local anomalies, thereby enabling subsequent maintenance work. However, this layered, independent detection approach only achieves anomaly identification at a single layer, resulting in fragmented alarm information. Maintenance personnel find it difficult to trace the causal transmission relationship of faults, accurately pinpoint the root cause, and experience low fault-finding efficiency.

[0030] Therefore, how to improve the fault location performance of two-wheeled vehicles is a key issue that urgently needs to be addressed by those skilled in the art.

[0031] In view of this, embodiments of this application provide a method, system, and related products for locating faults in two-wheeled vehicles, aiming to improve the performance of fault location for two-wheeled vehicles. First, a pre-constructed fault association map is obtained. This map is built based on multiple fault association links, each including a terminal node, a gateway node, a service node, and a data table node. The terminal node at the start of the link points to the gateway node, the gateway node points to the service node, and the service node points to the data table node at the end of the link. Next, for each fault association link in the fault association map, link collection data for that link is obtained within a preset time period. This data includes vehicle data uploaded by the two-wheeled vehicle cluster within the area covered by the link, and backend operational data. Thus, this application constructs a full-level fault association topology covering terminals, gateways, services, and data tables, associating the originally independent and dispersed four-level architecture nodes as a whole. Simultaneously, it integrates front-end vehicle data and backend operational data from each level, breaking the problem of independent detection and data fragmentation at each level in traditional solutions, and realizing the fusion and aggregation of fault data across the entire vehicle network link.

[0032] Subsequently, for each node in the fault-related link, calculations are performed based on the collected link data to obtain the node fault confidence level. Finally, the link node with the highest fault confidence level in the fault association graph is selected as the root cause node of the two-wheeled vehicle fault within a preset time period, where the root cause node is the node with the greatest impact on the backend operation and maintenance of the two-wheeled vehicle network. In this way, by calculating the fault confidence level of each node in the link one by one, this application quantifies the degree of fault contribution of each node in a probabilistic manner, and selects the node with the highest confidence level and the greatest impact as the root cause of the fault from a global association perspective. This effectively solves the defects of fragmented hierarchical detection alarms, chaotic fault causal relationships, and inability to accurately locate the root cause in related technical solutions, and realizes integrated and accurate full-link fault location in the two-wheeled vehicle network scenario, significantly improving fault investigation efficiency and platform operation and maintenance stability, thereby improving the fault location performance of two-wheeled vehicles.

[0033] In order to enable those skilled in the art to better understand the technical solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] Figure 1 A flowchart illustrating a two-wheeled vehicle fault location method provided in an embodiment of this application. (In conjunction with...) Figure 1 As shown, the two-wheeled vehicle fault location method provided in this application embodiment may include: S101: Obtain a pre-built fault correlation map.

[0035] In this step, the fault association graph is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. In other words, the architectural relationship of each fault association link is: terminal node → gateway node → service node → data table node.

[0036] Among them, terminal nodes can be understood as two-wheeled vehicle terminal clusters divided by geographical regions, such as East China regional terminal clusters, South China regional terminal clusters, etc. Node attributes include region ID (identifier), total number of terminals, and terminal online rate; gateway nodes can be understood as gateway instances deployed in a region, and node attributes include gateway ID, region, number of concurrent connections, and data packet loss rate; service nodes can be understood as core business service instances, such as location service, battery service, payment service, etc., and node attributes include service ID, interface response time, and error rate; data table nodes can be understood as core business data tables in the TiDB cluster, and node attributes include data table name, average query time, and index hit rate.

[0037] Understandably, the fault correlation graph contains multiple independent fault correlation links corresponding to different business scenarios. For example: Fault correlation link A: East China regional terminal cluster → East China gateway → Location service → Data table A; Fault correlation link B: East China regional terminal cluster → East China gateway → Battery service → Data table A; Fault correlation link C: South China regional terminal cluster → South China gateway → Battery service → Data table B. Multiple links are pieced together to form a complete full-link fault topology graph.

[0038] It should be noted that this application can realize the visualization and persistent storage of fault association graphs based on the Neo4j graph database, and can also synchronize with the dynamic changes of the backend architecture in real time, such as adding gateway instances, adding business services, adding data tables, etc., to ensure that the graph topology structure is always consistent with the actual operating architecture of the Internet of Vehicles, and to ensure the authenticity and validity of the graph data.

[0039] It should also be noted that the edge weight corresponding to each directed edge in the fault association graph can be calculated using formula (1) in this application. The edges in the graph are used to represent the data flow direction and fault propagation relationship between two adjacent nodes. The edge weights are calculated through statistical analysis of historical fault data and can reflect the degree of impact of upstream node faults on downstream nodes. Formula (1) is specifically reflected as follows:

[0040] in, The weight representing the influence from node i to node j ranges from [0,1]. A higher weight indicates a greater probability that a failure in node i will cause a failure in node j. For example, if the weight of the edge from the East China gateway node to the location service node is 0.92, it means that when the East China gateway fails, there is a 92% probability that the location service synchronization will be abnormal.

[0041] S102: For each fault-related link in the fault association map, obtain the link acquisition data of that fault-related link within a preset time period.

[0042] In this step, the preset time period can be understood as a pre-defined time window used for unified data collection across the four-layer architecture, forming time-consistent, full-domain operation and maintenance data. The preset time period can be set to 1 minute or 5 minutes; no specific limitation is made here. Link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster within the coverage area of ​​the fault-related link, as well as backend operation data. Vehicle data can be understood as terminal data actively reported by all two-wheeled vehicle-mounted terminals within the link coverage area, reflecting the real-time operating status, online status, and fault / anomaly information of the front-end terminal devices. Backend operation data can be understood as the performance data generated in real-time by the three types of backend nodes—gateway, service, and data table—in the fault-related link, reflecting the operating load, performance status, and potential anomalies of the backend architecture.

[0043] The process of "obtaining the link data of the fault-related link within a preset time period" in this application is as follows: First, based on this fault association link, the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link are determined. Then, within a preset time period, terminal data uploaded by each two-wheeled vehicle in the two-wheeled vehicle cluster within the region can be collected. The terminal data includes at least the vehicle's unique identifier, region, online status, heartbeat interval, original error code, and data reporting time. The terminal data uploaded by each two-wheeled vehicle is then used as vehicle data.

[0044] Simultaneously, within a preset time period, gateway data generated by the corresponding gateway, service data generated by the corresponding service instance, and data table data generated by the corresponding data table are collected. Gateway data includes at least the number of TCP connections, MQTT (Message Queuing Telemetry Transport Protocol) forwarding latency, packet loss rate, port status, and concurrent access volume. Service data includes at least interface response time, request success rate, thread pool utilization, JVM (Java Virtual Machine) memory, and call error rate. Data table data includes at least core table query time, index hit rate, number of slow queries, connection pool utilization, and storage and CPU (Central Processing Unit) load. Gateway data, service data, and data table data are then used as backend runtime data for the link.

[0045] Thus, this application collects data uniformly based on a preset time period, ensuring that all data belongs to the same fault analysis window. The data are strongly correlated and comparable, and can completely and accurately reflect the fault transmission status of the entire link within the same time period. This avoids the underlying problems of data fragmentation and inability to perform linked analysis in traditional solutions from the data source, and greatly improves the comprehensiveness and accuracy of subsequent fault calculations.

[0046] like Figure 2 As shown, Figure 2This diagram illustrates the acquisition of link data in a two-wheeled vehicle fault location method provided in this embodiment of the application. Figure 2 In this process, link data corresponding to each fault-related link is collected in a structured manner (region → gateway → service → data table) to provide a basis for fault correlation analysis.

[0047] S103: For each link node in the fault-related link, perform calculations based on the link data collected to obtain the node fault confidence level corresponding to that link node.

[0048] Next based on Figure 3 This application describes the process of "calculating and processing the data collected from the link to obtain the node fault confidence level corresponding to the link node," as follows: Figure 3 As shown, Figure 3 This is a flowchart illustrating the process of obtaining node fault confidence in a two-wheeled vehicle fault localization method provided in this application embodiment. Figure 3 This includes steps S1031-S1033, which are specifically described as follows: S1031: Extract and process the data collected from the link to obtain multiple fault characteristics corresponding to the data collected from the link.

[0049] In this step, multiple fault characteristics include at least the percentage of abnormal terminals, gateway packet loss rate, service response time, and number of slow queries in the data table. The percentage of abnormal terminals refers to the ratio of the number of two-wheeled vehicle terminals reporting error codes within the link coverage area to the total number of terminals in the area, reflecting the overall situation of batch failures, hardware anomalies, or reported anomalies at the front-end terminals. The gateway packet loss rate refers to the proportion of data packets lost during the gateway's reception of terminal messages and forwarding of service messages, representing gateway congestion, traffic overload, and forwarding failures. The service response time refers to the average time taken for a business service to process a single interface request, representing service lag, excessive load, and insufficient processing capacity. The number of slow queries in the data table refers to the number of SQL (Structured Query Language) queries with execution times exceeding a threshold within a preset period, reflecting database index failure and low query efficiency.

[0050] It should be noted that multiple fault characteristics may also include terminal offline rate, terminal heartbeat loss rate, average terminal reporting latency, gateway concurrent connection overrun rate, protocol conversion failure rate, service call error rate, service thread pool utilization rate, and database connection pool utilization rate. These fault characteristics can be selected based on specific application requirements.

[0051] Among them, the terminal offline rate refers to the proportion of terminals that fail to report heartbeats normally or remain offline within a preset period, out of the total number of terminals in the area, used to characterize group anomalies such as terminal disconnection, power outage, and communication interruption; the terminal heartbeat loss rate refers to the proportion of times a terminal should have reported heartbeats but failed to do so on time, out of the total number of times it should have reported them theoretically, used to judge unstable communication links and signal fluctuations between terminals and gateways; the average terminal reporting latency refers to the average time taken for all two-wheeled vehicle terminals in the area from data collection to reporting to the gateway, used to reflect uplink communication congestion, data backlog, and reporting delays; and the gateway concurrent connection over-limit rate refers to the percentage of time the number of real-time concurrent connections to the gateway exceeds the maximum threshold, used to judge excessive gateway access pressure and connection resource issues. Failures caused by resource exhaustion; Protocol conversion failure rate refers to the proportion of packets that fail to be parsed or have incorrect formats when the gateway converts between the TCP / MQTT private protocol and the backend protocol, reflecting gateway protocol processing anomalies; Service call error rate refers to the proportion of requests that return exceptions, errors, or access denials from the service interface, reflecting service logic anomalies, dependency anomalies, and business failures; Service thread pool utilization rate refers to the ratio of the number of currently active threads in the service thread pool to the total number of threads, used to determine service resource exhaustion, thread blocking, and processing queue backlog; Database connection pool utilization rate refers to the proportion of the number of occupied connections in the database connection pool to the total number of connections, used to characterize database connection resource exhaustion, request queuing, and service blocking.

[0052] The process for obtaining the percentage of abnormal terminals in this application is as follows: First, based on vehicle data uploaded by the two-wheeled vehicle cluster within the region, vehicle information corresponding to each two-wheeled vehicle is obtained. This vehicle information can be understood as terminal data, including at least the original fault code, terminal model, and batch number. Then, for each two-wheeled vehicle, if the original fault code exists in its corresponding vehicle information, the terminal model and batch number are retrieved from that information. It's understandable that a suspected fault is only determined if a vehicle reports an original fault code. Extracting the terminal model and batch number is crucial because different manufacturers and batches of terminals use different encoding methods for the same fault. Only by combining hardware information can the corresponding fault rules be accurately matched, avoiding misjudgments or missed diagnoses caused by directly using the original fault code.

[0053] Next, using an anomaly code mapping table, based on the original anomaly code, terminal model, and batch number corresponding to the two-wheeled vehicle, the target anomaly code is determined. The anomaly code mapping table standardizes anomaly codes for different terminal models and batch numbers, and the target anomaly code determines that the two-wheeled vehicle is in a terminal anomaly state. Understandably, this application uses an anomaly code mapping table to convert the disorganized and inconsistent original anomaly codes, combined with terminal hardware information, into a unified standard target anomaly code, eliminating coding differences caused by different terminal models and production batches, achieving consistent terminal fault judgment standards across the entire region, and ensuring fair and accurate anomaly identification.

[0054] Finally, the number of two-wheeled vehicles with the target anomaly code within the statistical area, and the total number of two-wheeled vehicles within the area, are counted. Based on the ratio of the number of two-wheeled vehicles with the target anomaly code to the total number of two-wheeled vehicles, the percentage of terminal anomalies is obtained. Understandably, after standardizing the fault determination criteria, this application calculates the percentage of faulty terminals within the statistical area and the total number of terminals to obtain standardized fault characteristics. This directly reflects the scale of group terminal anomalies and provides a quantifiable and comparable core indicator for subsequent fault confidence calculations.

[0055] Thus, this application solves the problem of inaccurate fault identification caused by inconsistent original abnormal codes of two-wheeled vehicles from multiple manufacturers and batches by unifying the terminal fault judgment standard through model and batch matching and abnormal code mapping. It accurately counts the proportion of terminal abnormalities in a region, making the fault feature data real, standardized, and comparable. At the same time, it upgrades the identification of single terminal faults to the quantification of regional group abnormalities, providing accurate front-end input features for subsequent full-link fault confidence calculation, effectively improving the accuracy and reliability of overall fault location.

[0056] As shown in Table 1, Table 1 is a schematic table of mapping rules in a two-wheeled vehicle fault location method provided in the embodiments of this application. In Table 1, by associating the original fault code, terminal model, and batch number, the non-standard fault codes reported by multiple versions and batches of T-BOX terminals are uniformly mapped to standard target fault codes, and the fault type, fault impact level, propagation path, and initial confidence level are simultaneously marked, thereby realizing the uniformity of terminal fault judgment criteria and ensuring accurate and reliable front-end terminal fault identification.

[0057] Table 1

[0058] As shown in Table 2, this table illustrates the anomaly code mapping table in a two-wheeled vehicle fault location method provided in this application embodiment. Table 2 allows for precise matching of the target anomaly code using the original anomaly code, terminal model, and batch number, while simultaneously associating attributes such as fault type, impact level, and propagation path. Unmatched unknown anomaly codes are automatically recorded and trigger manual review. Upon successful review, a new rule is added to the rule base, enabling dynamic iteration of the rule base. In this way, this application solves the problems of inconsistent anomaly codes across different batches of T-BOX terminals and the potential for errors in manual interpretation. It avoids the inefficiency of traditional methods that rely on manual inspection of each vehicle, reviewing logs, and comparing data, shortens fault identification time, avoids delays and business interruptions during peak periods due to large-scale vehicle reporting, and improves the accuracy of fault identification.

[0059] Table 2

[0060]

[0061] S1032: Based on the multiple fault features, determine the fault feature weights corresponding to the multiple fault features respectively.

[0062] In this step, the greater the influence of a fault feature on root cause determination, the higher its corresponding weight; conversely, the smaller the influence, the lower its corresponding weight. In other words, a larger fault feature weight indicates that the fault feature has appeared an average of more times in historical faults and has a stronger influence on root cause determination. Specifically, this application uses a neural network model to predict each fault feature and obtain its corresponding weight. The weight ranges from 0 to w to 1, and the sum of all weights is 1.

[0063] The neural network model is trained and constructed based on a historical fault sample dataset. This application first extracts multi-dimensional features such as the proportion of terminal anomalies, gateway packet loss rate, service response latency, and number of slow queries in data tables, as well as corresponding root cause labels, from the historical fault database to construct a historical fault sample dataset; then, through forward propagation and backward gradient update of the neural network, it learns the correlation strength between different fault features and fault root causes, outputs the optimal weight distribution, and completes the training of the neural network model.

[0064] For example, based on the trained neural network model, the weights for the following can be output: the percentage of abnormal terminal connections (0.30), the gateway packet loss rate (0.25), the service interface response timeout (0.20), the data table query time (0.15), the JVM memory usage rate (0.06), and the thread pool blocking rate (0.04). Thus, this application, through differentiated feature weighting, strengthens the decision-making weight of high-contribution features in root cause localization, weakens the interference caused by low-contribution features, and significantly improves the accuracy and confidence stability of fault localization.

[0065] S1033: Calculate and process based on the multiple fault features and the fault feature weights corresponding to the multiple fault features respectively to obtain the node fault confidence level corresponding to the link node.

[0066] Thus, this application achieves a quantitative assessment of the fault status of a four-level architecture by extracting multi-dimensional fault features, matching corresponding feature weights, and combining weighted calculations to obtain node fault confidence. By screening key fault features and eliminating redundant data, the targeting of fault analysis is improved. Weights are assigned based on the degree of influence of features on the fault, aligning with actual operation and maintenance scenarios and avoiding errors caused by equal judgment. Simultaneously, the ambiguous abnormal device status is transformed into comparable probability values, effectively solving the problem that traditional solutions can only qualitatively identify anomalies and cannot distinguish between primary and secondary faults, significantly improving the accuracy of fault root cause identification.

[0067] It should be noted that before performing calculations based on multiple fault features and their respective fault feature weights to obtain the node fault confidence of the link node, this application may also perform the following process: obtaining the prior probability of the link node as the root cause node, and obtaining the conditional probability of each fault feature occurring when the link node fails.

[0068] The prior probability can be understood as the basic probability that a certain link node will fail alone and become the root cause of a failure, based on historical failure data without considering the current failure characteristics. For example, the prior probability of the East China gateway is 0.12, representing that the gateway has a failure risk for an average of 12% of the time in its history. The conditional probability is obtained based on historical failure data. When a certain link node fails, the probability that a certain failure characteristic will appear abnormally in historical failures is used to characterize the historical correlation between node failure and abnormal failure characteristics.

[0069] Specifically, the process of "calculating and processing based on multiple fault features and the fault feature weights corresponding to the multiple fault features to obtain the node fault confidence of the link node" is as follows: Based on whether multiple fault features are abnormal, the prior probability, the conditional probability of each fault feature occurring when the link node fails, and the fault feature weights corresponding to the multiple fault features are calculated and processed to obtain the node fault confidence of the link node.

[0070] Understandably, in this application, for each fault characteristic, a comparison is made between the fault characteristic and its corresponding threshold. If the fault characteristic is greater than its corresponding threshold, it is determined that the fault characteristic is abnormal; if the fault characteristic is not greater than its corresponding threshold, it is determined that the fault characteristic is normal. For example, if the threshold for gateway packet loss rate is set to 3%, and the real-time packet loss rate of 4.2% > 3%, then the fault characteristic is determined to be abnormal; if the threshold for service response time is set to 200ms, and the real-time service response time of 180ms < 200ms, then the fault characteristic is determined to be normal.

[0071] Then, only the fault features judged as abnormal are selected. The prior probabilities, conditional probabilities of each abnormal fault feature when the link node fails, and fault feature weights are calculated to obtain the node fault confidence level for that link node. Alternatively, both abnormal and normal fault features are considered simultaneously. The prior probabilities, conditional probabilities of abnormal fault features when the link node fails, fault feature weights of abnormal fault features, conditional probabilities of normal fault features (obtained by subtracting the corresponding conditional probability from 1), and fault feature weights of normal fault features are calculated to obtain the node fault confidence level for that link node.

[0072] Thus, this application achieves standardized judgment of fault features through threshold discrimination, and then introduces prior probability, historical conditional probability and feature weights for weighted Bayesian operation, which deeply integrates real-time status, historical fault patterns and feature importance, avoids misjudgment by a single indicator, achieves accurate quantification of node fault probability, and provides a reliable basis for subsequent screening of global fault root causes.

[0073] In one feasible implementation, the node fault confidence can be obtained by formula (2), which is specifically reflected as follows:

[0074] in, The node failure confidence (posterior probability) is represented by the i-th link node. This represents the prior probability corresponding to the i-th link node. The conditional probability of the k-th fault feature occurring when the i-th link node fails is represented. The fault feature weights represent the fault feature weights corresponding to the k-th fault feature. Characteristic evidence factors This represents the product symbol, which is the total probability that all nodes exhibit the current set of fault characteristics. It is used for normalization to ensure that the sum of the confidence scores of all nodes is 1, without affecting the comparison of the relative sizes between nodes.

[0075] S104: The link node with the highest fault confidence in the fault association graph is taken as the root cause node of the two-wheeled vehicle fault within the preset time period.

[0076] In this step, the root cause node is the node with the greatest impact on the backend operation and maintenance of the two-wheeled vehicle network. This can be understood as the link node most likely to cause a two-wheeled vehicle failure within a preset time period and having the greatest impact on backend operation and maintenance. Specifically, in this application, the link node with the highest failure confidence in the fault correlation graph, and whose failure confidence is greater than a preset confidence level (e.g., 90%), can be considered the root cause node of the two-wheeled vehicle failure within the preset time period. If the highest node failure confidence is lower than the preset confidence level, manual review is triggered.

[0077] In one feasible implementation, after performing the operation of identifying the link node with the highest fault confidence in the fault association graph as the root cause node of the two-wheeled vehicle's fault within a preset time period, this application may also perform the following process: First, the fault correlation graph can be traversed based on the root cause node to obtain the number of affected terminals, services, gateways, and data tables corresponding to the root cause node. Understandably, based on the directed edges of the graph, a breadth-first traversal is performed starting from the root cause node. All nodes traversed represent the scope of the fault's impact. The number of affected terminals (the sum of the number of terminals among the traversed terminal nodes), services (the sum of the number of service nodes among the traversed service nodes), gateways (the sum of the number of gateway nodes among the traversed gateway nodes), and data tables (the sum of the number of data table nodes among the traversed data tables) are quantified numerically.

[0078] Specifically, the number of affected terminals refers to the total number of two-wheeled vehicle terminals affected by the failure of the root cause node, resulting in communication or data reporting anomalies; the number of affected services refers to the number of backend business services that cannot operate normally due to the failure of the root cause node; the number of affected gateways refers to the number of gateway devices that experience data forwarding anomalies due to the failure of the root cause node; and the number of affected data tables refers to the number of backend database tables that experience read / write anomalies or data anomalies due to the failure of the root cause node. For example, if the East China gateway node is the root cause, traversing the graph reveals 1200 affected terminals, 4 affected services, 2 affected gateways, and 3 affected data tables.

[0079] Then, based on the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables, the node fault level corresponding to the root cause node can be determined. The node fault level includes a first fault level (minor fault), a second fault level (medium fault), and a third fault level (major fault). The severity of the third fault level is greater than that of the second fault level, and the severity of the second fault level is greater than that of the first fault level.

[0080] As shown in Table 3, Table 3 is a schematic table illustrating the determination of fault level in a two-wheeled vehicle fault location method provided in this application embodiment. Table 3 shows the node fault level corresponding to the root cause node based on the number of affected terminals, specifically determined by the threshold of the number of affected terminals and the importance of the business. The importance of the business includes at least non-core business, core business, and important business. Non-core business (weight 0.4) can be understood as log service, statistical report service, and configuration management service; core business (weight 1.0) can be understood as vehicle data reporting, location service, battery status service, and remote control service; important business (weight 0.7) can be understood as payment callback service, order service, and user management service.

[0081] Table 3

[0082] Thus, this application accurately counts the multi-dimensional impact range of faults through fault correlation graphs, enabling direct location of abnormal phenomena to root cause nodes within seconds, and classifying fault levels. This avoids relying solely on a single indicator to judge the severity of a fault, facilitating the priority handling of high-level faults, achieving graded fault handling and rapid operation and maintenance response, and improving the efficiency of fault handling in the backend of the vehicle network.

[0083] It should be noted that the edge weights in the fault association graph in this application can also be used for accurate traversal of the fault impact range, linkage correction of node fault confidence, refined judgment of fault level, sorting of fault source path, and control of fault alarm priority. At the same time, they can be used to optimize the parameters of the neural network model and realize the self-iterative update of the fault location model.

[0084] In one feasible implementation, after determining the fault level, this application can execute a differentiated self-healing strategy, as follows: If the node failure level is the first failure level, the first self-healing strategy is executed. The first self-healing strategy includes automatically restarting the abnormal service instance, and simultaneously cleaning up the service instance cache and resetting the thread pool. The specific execution logic is to automatically evict the abnormal Pod (the smallest scheduling unit in K8s) through the K8s API (Container Orchestration Platform Application Programming Interface) and schedule a new service instance to start, without any manual intervention throughout the process.

[0085] If the node failure level is the second failure level, the second self-healing strategy will be executed. The second self-healing strategy includes automatically performing database index optimization, connection pool expansion, traffic shaping, and service instance expansion. The specific execution logic is as follows: for database performance bottlenecks, automatically execute ANALYZE TABLE (automatically perform table statistics information collection) to update statistics and rebuild inefficient indexes; for excessive service load, automatically expand the number of service instances, adjust the traffic allocation ratio, and switch non-core traffic to standby instances.

[0086] If the node failure level is level three, a third self-healing strategy is executed. This strategy includes automatically switching the primary gateway in the failure area to the backup gateway, updating routing rules, and isolating the failure node. Specifically, the logic involves using DNS (Domain Name System) and a load balancer to redirect terminal traffic in the failure area to the backup gateway cluster, synchronously isolating the failure gateway instance to prevent the failure from spreading, and simultaneously triggering a high-level alarm to push it to operations and maintenance personnel. In this way, this application avoids the situation where existing self-healing methods simply restart the service, enabling the execution of differentiated self-healing strategies to ensure that core business operations are restored first.

[0087] It should also be noted that after the self-healing process is completed, this application automatically verifies the recovery effect to form a complete operation and maintenance closed loop. Specifically, it re-collects key indicators such as terminal online rate, data reporting success rate, service interface response time, and database query time in the faulty area, and calculates the fault recovery rate. Finally, if the fault recovery rate is less than the preset recovery rate (e.g., 95%), the self-healing is deemed to have failed, an upgrade alarm is automatically triggered, and fault details are pushed to operation and maintenance personnel for manual intervention; if the fault recovery rate is not less than the preset recovery rate, the self-healing is deemed successful, the fault log is recorded, and the closed loop ends.

[0088] The fault recovery rate can be calculated using formula (3), which is specifically shown below:

[0089] like Figure 4 As shown, Figure 4 This is a complete flowchart of a two-wheeled vehicle fault location method provided in an embodiment of this application. Figure 4First, for each fault-related link in the fault association graph, link data (multi-dimensional data acquisition) is acquired within a preset time period for that link. Then, the acquired link data is processed to obtain multiple fault features (including data digitization), and the acquired link data is matched to the corresponding fault-related links in the fault association graph. Next, for each link node in that fault-related link, calculations are performed based on the acquired link data to obtain the node fault confidence level. The link node with the highest node fault confidence level in the fault association graph is identified as the root cause node of the two-wheeled vehicle's fault within the preset time period. Finally, the corresponding fault level is determined based on the influence range of the root cause node, and a matching self-healing strategy is executed. Furthermore, the self-healing effect can be verified by evaluating the execution results of the self-healing strategy.

[0090] In summary, this application constructs a full-link fault association graph of terminal-gateway-service-data table and combines it with a weighted Naive Bayes algorithm to achieve intelligent matching and judgment of fault root causes, optimizing traditional minute-level manual fault location to second-level intelligent location, significantly improving the efficiency of fault investigation and root cause identification. Simultaneously, this application establishes a complete abnormal code standardization mapping mechanism, which can uniformly normalize various non-standard abnormal codes reported by multiple versions and batches of T-BOX terminals, eliminating data difference interference caused by different terminal batches and models, effectively reducing the probability of fault misjudgment, and reducing the cost of manual log verification and data comparison. Based on this, this application automatically classifies fault severity levels according to the scope of fault impact and matches differentiated self-healing strategies for light, medium, and severe faults. For minor faults, it performs service restarts; for medium faults, it performs database parameter optimization; and for severe faults, it performs gateway link switching, achieving fully unattended automated operation and maintenance, ensuring continuous high availability of core services. In response to the complex scenarios of sudden surges in traffic during morning and evening peak hours and massive concurrent reporting from terminals, this application can quickly identify faults, suppress the cross-level spread of faults, effectively avoid large-scale vehicle data reporting delays and business interruptions, and significantly improve the system's peak stability and overall service quality in scenarios with massive terminals.

[0091] Based on the two-wheeled vehicle fault location method provided in the above embodiments, this application can also provide a two-wheeled vehicle fault location system. The two-wheeled vehicle fault location system will now be described in conjunction with the embodiments and accompanying drawings.

[0092] Figure 5 This is a schematic diagram of the structure of a two-wheeled vehicle fault location system provided in an embodiment of this application. (Combined with...) Figure 5 As shown in the embodiment of this application, the two-wheeled vehicle fault location system includes: The fault association graph acquisition unit 501 is used to acquire a pre-constructed fault association graph, wherein the fault association graph is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. The link data acquisition unit 502 is used to acquire the link collection data of each fault-related link in the fault association map within a preset time period, wherein the link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster in the area covered by the fault-related link, and the link backend operation data. The node confidence acquisition unit 503 is used to calculate and process the link collected data for each link node in the fault-related link to obtain the node fault confidence corresponding to the link node. The root cause node determination unit 504 is used to identify the link node with the highest node fault confidence in the fault association map as the root cause node of the two-wheeled vehicle fault within the preset time period, wherein the root cause node is the node with the greatest impact on the back-end operation and maintenance of the two-wheeled vehicle network.

[0093] In one feasible implementation, the link data acquisition unit 502 is specifically used for: Based on this fault association link, determine the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link; Within a preset time period, vehicle data uploaded by the two-wheeled vehicle cluster in the area, as well as link backend operation data generated by the gateway, the service instance, and the data table, are collected.

[0094] In one feasible implementation, the node confidence acquisition unit 503 includes: The fault feature acquisition unit is used to extract and process the link collection data to obtain multiple fault features corresponding to the link collection data, wherein the multiple fault features include at least the percentage of abnormal terminal numbers, gateway packet loss rate, service response time, and number of slow queries in the data table. The feature weight determination unit is used to determine the fault feature weights corresponding to the multiple fault features based on the multiple fault features, wherein the greater the influence of the fault feature on the root cause determination, the higher the corresponding fault feature weight. The node confidence calculation unit is used to perform calculations based on the multiple fault features and the fault feature weights corresponding to the multiple fault features to obtain the node fault confidence corresponding to the link node.

[0095] In one feasible implementation, the system further includes: The prior conditional probability acquisition unit is used to acquire the prior probability of the link node as the root cause node, and to acquire the conditional probability of each fault feature occurring when the link node fails. The node confidence calculation unit is specifically used for: Based on whether the multiple fault features are abnormal, the prior probability, the conditional probability of each fault feature occurring when the link node fails, and the fault feature weights corresponding to the multiple fault features are calculated and processed to obtain the node fault confidence level corresponding to the link node.

[0096] In one feasible implementation, the system further includes: The association graph traversal unit is used to traverse the fault association graph based on the fault root cause node to obtain the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables corresponding to the fault root cause node. The fault level determination unit is used to determine the node fault level corresponding to the root cause node based on the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables. The node fault level includes a first fault level, a second fault level, and a third fault level, wherein the severity of the third fault level is greater than that of the second fault level, and the severity of the second fault level is greater than that of the first fault level.

[0097] In one feasible implementation, the system further includes: The first self-healing execution unit is used to execute a first self-healing strategy if the node failure level is the first failure level, wherein the first self-healing strategy includes restarting the abnormal service instance and simultaneously cleaning up the service instance cache and resetting the thread pool. The second self-healing execution unit is used to execute a second self-healing strategy if the node failure level is the second failure level, wherein the second self-healing strategy includes database index optimization, connection pool expansion, traffic shaping, and service instance expansion. The third self-healing execution unit is used to execute a third self-healing strategy if the node failure level is the third failure level. The third self-healing strategy includes switching the primary gateway of the fault area to the backup gateway, updating routing rules, and isolating the faulty node.

[0098] In one feasible implementation, the fault feature acquisition unit is specifically used for: Based on the vehicle data uploaded by the two-wheeled vehicle cluster in the area, the vehicle information corresponding to each two-wheeled vehicle is obtained; For each two-wheeled vehicle, if there is an original abnormal code in the vehicle information corresponding to the two-wheeled vehicle, then the terminal model and batch number corresponding to the two-wheeled vehicle are obtained from the vehicle information corresponding to the two-wheeled vehicle. Using the anomaly code mapping table, the target anomaly code corresponding to the two-wheeled vehicle is determined based on the original anomaly code, terminal model, and batch number. The anomaly code mapping table is used to unify the anomaly code specifications for different terminal models and batch numbers, and the target anomaly code is used to determine that the two-wheeled vehicle is in a terminal anomaly state. The number of two-wheeled vehicles with target anomaly codes within the area is counted, along with the total number of two-wheeled vehicles within the area. Based on the ratio of the number of two-wheeled vehicles with target anomaly codes to the total number of two-wheeled vehicles, the percentage of terminal anomalies is obtained.

[0099] The system provided in this application embodiment has the same beneficial effects as the method provided in the above embodiments, and can improve the fault location performance of two-wheeled vehicles, which will not be described in detail here.

[0100] like Figure 6 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application. Figure 6 The computer device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0101] like Figure 6 As shown, the computer device 12 is represented in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processor units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processor units 16).

[0102] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0103] Computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0104] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0105] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0106] Computer device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the computer device 12, and / or with any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, computer device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 20. Figure 6 As shown, network adapter 20 communicates with other modules of computer device 12 via bus 18. It should be understood that, although... Figure 6 As not shown, it can be used in conjunction with computer device 12 with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0107] The processor unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the two-wheeled vehicle fault location method provided in the embodiments of this application.

[0108] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the two-wheeled vehicle fault location method described in this application.

[0109] In practical applications, the computer-readable storage medium can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0110] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0111] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0112] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0114] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for locating faults in a two-wheeled vehicle, characterized in that, include: Obtain a pre-constructed fault association map, wherein the fault association map is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. For each fault-related link in the fault correlation map, obtain the link acquisition data for that fault-related link within a preset time period, including: Based on this fault association link, determine the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link; Within a preset time period, vehicle data uploaded by the two-wheeled vehicle cluster in the area, as well as link backend operation data generated by the gateway, the service instance, and the data table, are collected. The link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster in the area covered by the fault-related link, and link backend operation data. For each link node in this fault-related link, calculations are performed based on the collected link data to obtain the node fault confidence level corresponding to that link node, including: The link collection data is extracted and processed to obtain multiple fault features corresponding to the link collection data, wherein the multiple fault features include at least the percentage of abnormal terminal numbers, gateway packet loss rate, service response time, and number of slow queries in data tables. Based on the multiple fault features, the fault feature weights corresponding to the multiple fault features are determined respectively, wherein the greater the impact of the fault feature on the root cause determination, the higher the corresponding fault feature weight. The node fault confidence level corresponding to the link node is obtained by calculating and processing based on the multiple fault features and the fault feature weights corresponding to the multiple fault features. The link node with the highest fault confidence in the fault association graph is taken as the root cause node of the two-wheeled vehicle fault within the preset time period, wherein the root cause node is the node with the greatest impact on the back-end operation and maintenance of the two-wheeled vehicle network.

2. The method according to claim 1, characterized in that, Before calculating and processing the node fault confidence level corresponding to the link node based on the plurality of fault features and the fault feature weights corresponding to the plurality of fault features, the method further includes: Obtain the prior probability that the link node is the root cause node, and obtain the conditional probability of each fault feature occurring when the link node fails. The step of calculating and processing based on the multiple fault features and their corresponding fault feature weights to obtain the node fault confidence level for the link node includes: Based on whether the multiple fault features are abnormal, the prior probability, the conditional probability of each fault feature occurring when the link node fails, and the fault feature weights corresponding to the multiple fault features are calculated and processed to obtain the node fault confidence level corresponding to the link node.

3. The method according to claim 2, characterized in that, After identifying the link node with the highest fault confidence in the fault correlation graph as the root cause node of the two-wheeled vehicle's fault within the preset time period, the method further includes: Based on the root cause node of the fault, the fault association graph is traversed to obtain the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables corresponding to the root cause node of the fault. Based on the number of affected terminals, the number of affected services, the number of affected gateways, and the number of affected data tables, the node fault level corresponding to the root cause node is determined. The node fault level includes a first fault level, a second fault level, and a third fault level, wherein the severity of the third fault level is greater than that of the second fault level, and the severity of the second fault level is greater than that of the first fault level.

4. The method according to claim 3, characterized in that, The method further includes: If the node failure level is the first failure level, then the first self-healing strategy is executed, wherein the first self-healing strategy includes restarting the abnormal service instance and simultaneously cleaning up the service instance cache and resetting the thread pool. If the node failure level is the second failure level, then the second self-healing strategy is executed, wherein the second self-healing strategy includes database index optimization, connection pool expansion, traffic shaping, and service instance expansion. If the node failure level is the third failure level, then the third self-healing strategy is executed, wherein the third self-healing strategy includes switching the primary gateway of the failure area to the backup gateway, updating the routing rules, and isolating the failure node.

5. The method according to claim 1, characterized in that, The process for obtaining the percentage of abnormal terminals is as follows: Based on the vehicle data uploaded by the two-wheeled vehicle cluster in the area, the vehicle information corresponding to each two-wheeled vehicle is obtained; For each two-wheeled vehicle, if there is an original abnormal code in the vehicle information corresponding to the two-wheeled vehicle, then the terminal model and batch number corresponding to the two-wheeled vehicle are obtained from the vehicle information corresponding to the two-wheeled vehicle. Using the anomaly code mapping table, the target anomaly code corresponding to the two-wheeled vehicle is determined based on the original anomaly code, terminal model, and batch number. The anomaly code mapping table is used to unify the anomaly code specifications for different terminal models and batch numbers, and the target anomaly code is used to determine that the two-wheeled vehicle is in a terminal anomaly state. The number of two-wheeled vehicles with target anomaly codes within the area is counted, along with the total number of two-wheeled vehicles within the area. Based on the ratio of the number of two-wheeled vehicles with target anomaly codes to the total number of two-wheeled vehicles, the percentage of terminal anomalies is obtained.

6. A fault location system for a two-wheeled vehicle, characterized in that, include: The fault association graph acquisition unit is used to acquire a pre-constructed fault association graph, wherein the fault association graph is constructed based on multiple fault association links. Each fault association link includes a terminal node, a gateway node, a service node, and a data table node. The terminal node, which is the starting point of the link, points to the gateway node, the gateway node points to the service node, and the service node points to the data table node, which is the ending point of the link. The link data acquisition unit is used to acquire link collection data for each fault-related link in the fault association map within a preset time period, including: Based on this fault association link, determine the region corresponding to the terminal node, the gateway corresponding to the gateway node, the service instance corresponding to the service node, and the data table corresponding to the data table node in this fault association link; Within a preset time period, vehicle data uploaded by the two-wheeled vehicle cluster in the area, as well as link backend operation data generated by the gateway, the service instance, and the data table, are collected. The link collection data includes vehicle data uploaded by the two-wheeled vehicle cluster in the area covered by the fault-related link, and link backend operation data. The node confidence level acquisition unit is used to calculate and process the link collection data for each link node in the fault-related link to obtain the node fault confidence level corresponding to that link node, including: The link collection data is extracted and processed to obtain multiple fault features corresponding to the link collection data, wherein the multiple fault features include at least the percentage of abnormal terminal numbers, gateway packet loss rate, service response time, and number of slow queries in data tables. Based on the multiple fault features, the fault feature weights corresponding to the multiple fault features are determined respectively, wherein the greater the impact of the fault feature on the root cause determination, the higher the corresponding fault feature weight. The node fault confidence level corresponding to the link node is obtained by calculating and processing based on the multiple fault features and the fault feature weights corresponding to the multiple fault features. The root cause node determination unit is used to identify the link node with the highest fault confidence in the fault association graph as the root cause node of the two-wheeled vehicle fault within the preset time period, wherein the root cause node is the node with the greatest impact on the back-end operation and maintenance of the two-wheeled vehicle network.

7. A computer device, characterized in that, include: Processor, memory, system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform the two-wheeled vehicle fault location method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a terminal device, cause the terminal device to perform the two-wheeled vehicle fault location method according to any one of claims 1-5.

Images