Fault diagnosis method of industrial network and electronic equipment

Abstract

The invention relates to an industrial network fault diagnosis method and an electronic device, and the method comprises the steps: obtaining the operation data of at least one network device in an industrial network; performing structured analysis on the log data by adopting a hierarchical analysis strategy to generate event data in a unified format; using a sliding time window to collect target event data and target performance index data generated by the target device within a preset duration, and obtaining network topology data of the target device; fusing the network topology data, the target event data and the target performance index data to generate a fault event vector; performing mode matching on the fault event vector by utilizing a preset rule engine to obtain a fault matching result of the target equipment; and under the condition that the fault matching result represents that the target equipment has the fault, determining a fault range according to the network topology data so as to generate a fault diagnosis result including the fault range. The problem of low fault diagnosis efficiency caused by insufficient integration of multi-source heterogeneous data is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent operation and maintenance of automation equipment, and in particular to a fault diagnosis method of an industrial network and an electronic device. BACKGROUND

[0002] As a key information infrastructure, the stability of the industrial Ethernet is crucial to industrial production, and as a core network device, the fault diagnosis of the industrial Ethernet switch is the core link to ensure the reliable operation of the network.

[0003] The current industrial network fault diagnosis field faces many outstanding problems, such as the difficulty in automatic analysis of heterogeneous logs, the difficulty in forming a complete fault view from isolated multi-modal data, the low diagnosis efficiency due to high dependence on operation and maintenance experience, and the long average fault repair time. Based on the rule base or single machine learning model, the diagnosis scheme also has the defects of rigid rules, insufficient data correlation, poor generalization ability, etc., and it is difficult to break through the core bottleneck of multi-source data integration, and it cannot meet the urgent needs of industrial networks for high reliability and intelligent diagnosis.

[0004] For the problem of low fault diagnosis efficiency due to insufficient integration of multi-source heterogeneous data in the fault diagnosis of the industrial network, an effective solution is needed. SUMMARY

[0005] The present application provides a fault diagnosis method of an industrial network and an electronic device to solve the technical problem of "low fault diagnosis efficiency due to insufficient integration of multi-source heterogeneous data".

[0006] According to an aspect of an embodiment of the present application, the present application provides a fault diagnosis method of an industrial network, comprising: acquiring running data of at least one network device in the industrial network, wherein the running data comprises log data and performance index data; using a hierarchical analysis strategy to structurally analyze the log data to generate event data in a unified format; using a sliding time window to collect target event data and target performance index data generated by a target device within a preset time length, and acquiring network topology data of the target device, wherein the network device comprises the target device; fusing the network topology data, the target event data and the target performance index data to generate a fault event vector; using a preset rule engine to perform pattern matching on the fault event vector to obtain a fault matching result of the target device; in the case that the fault matching result represents that the target device has a fault, determining a fault range according to the network topology data to generate a fault diagnosis result comprising the fault range, wherein the network topology data comprises the connection relationship between each network device.

[0007] Optionally, the log data is structured parsed by using a hierarchical parsing strategy to generate event data in a unified format, including: the log data is matched and parsed by using a predefined rule template library; if the parsing is successful, the event data is generated according to the matched rule output template, and if the parsing fails, an entity recognition and semantic analysis of the log data are performed by using a semantic parsing model to obtain the event data, wherein the semantic parsing model is obtained by training using domain corpus.

[0008] Optionally, the log data is matched and parsed by using a predefined rule template library, including: the rule template library is called, and a candidate rule set matched with the device attribute of the network device is screened out from the rule template library, wherein each candidate rule in the candidate rule set has a priority; the log data is matched with the regular expression of each candidate rule one by one in descending order of priority; if any candidate rule is matched with the log data successfully, it is determined that the parsing is successful, and if each candidate rule is matched unsuccessfully, it is determined that the parsing fails.

[0009] Optionally, after the entity recognition and semantic analysis of the log data are performed by using the semantic parsing model to obtain the event data, the method further includes: generating a new regular expression according to the text content of the log data; constructing a new output template corresponding to the new regular expression according to the event data; constructing a new rule according to the new regular expression and the new output template; and storing the new rule in the rule template library.

[0010] Optionally, the target event data and the target performance indicator data generated by the target device within a preset time length are collected by using a sliding time window, including: taking the unique identifier of the target device as a partition key, routing the event data and the performance indicator data belonging to the target device to the same message partition; and maintaining a sliding time window for the unique identifier to collect the target event data and the target performance indicator data reaching the sliding time window within the preset time length.

[0011] Optionally, the fault event vector is pattern matched by using a preset rule engine to obtain a fault matching result of the target device, including: inputting the fault event vector into the preset rule engine to enable the preset rule engine to perform pattern matching between the fault event vector and a rule library of the preset rule engine; and obtaining the fault matching result output by the preset rule engine, wherein the fault matching result is used to indicate whether the target device has a fault.

[0012] Optionally, the fault range is determined according to the network topology data to generate a fault diagnosis result including the fault range, including: determining the upstream device and / or the downstream device of the target device according to the connection relationship recorded in the network topology data; determining the upstream device and / or the downstream device as the fault range; extracting the fault type from the fault matching result, and taking the fault type and the fault range as the fault diagnosis result.

[0013] Optionally, the method further comprises generating the semantic parsing model in the following manner: obtaining text data in the field of industrial networks, and obtaining a plurality of sets of sample pairs labeled from the text data, wherein the text data comprises device operation logs, device configuration manuals, and fault analysis reports, and the sample pairs comprise target inputs and target outputs corresponding to the target inputs; pre-training an initial model using the text data to obtain an intermediate model; based on the sample pairs, fine-tuning the intermediate model using a single-turn instruction and a multi-turn dialogue interaction mode to obtain the semantic parsing model.

[0014] Optionally, after generating the fault diagnosis result comprising the fault range, the method further comprises: in the case that a query instruction is received from the target object, performing intent analysis on the query instruction to obtain an analysis result; if the analysis result is that the intent of the query instruction is ambiguous, initiating a multi-turn dialogue with the target object until a query intent with a clear intent is obtained; converting the query intent into a query statement, and using the query statement to find the fault diagnosis result and the corresponding fault repair strategy in the target database; and pushing the fault diagnosis result and the fault repair strategy to the target object.

[0015] According to another aspect of the embodiments of the present application, the present application provides a fault diagnosis apparatus for an industrial network, comprising: an acquisition module configured to acquire operation data of at least one network device in the industrial network, wherein the operation data comprises log data and performance index data; an analysis module configured to perform structural analysis on the log data using a hierarchical analysis strategy to generate event data in a unified format; a collection module configured to collect target event data and target performance index data generated by a target device within a preset time length using a sliding time window, and to acquire network topology data of the target device, wherein the network device comprises the target device; a fusion module configured to fuse the network topology data, the target event data, and the target performance index data to generate a fault event vector; a matching module configured to perform pattern matching on the fault event vector using a preset rule engine to obtain a fault matching result of the target device; and a determination module configured to determine a fault range according to the network topology data to generate a fault diagnosis result comprising the fault range in the case that the fault matching result indicates that the target device has a fault, wherein the network topology data comprises connection relationships between the network devices.

[0016] According to another aspect of the embodiments of the present application, the present application provides an electronic device, comprising a memory, a processor, a communication interface, and a communication bus, wherein the memory stores a computer program capable of running on the processor, the memory, the processor, and the communication interface communicate through the communication bus, and the processor implements the steps of the above method when executing the computer program.

[0017] According to another aspect of the embodiments of the present application, the present application further provides a computer readable medium having non-volatile program codes executable by a processor, the program codes causing the processor to perform the method described above.

[0018] The above technical solutions provided by the embodiments of the present application have the following advantages compared with related art. The present application provides an industrial network fault diagnosis method, comprising: obtaining running data of at least one network device in an industrial network, wherein the running data comprises log data and performance index data; using a hierarchical analysis strategy to structurally analyze the log data to generate event data in a unified format; using a sliding time window to collect target event data and target performance index data generated by a target device within a preset time length, and obtaining network topology data of the target device, wherein the network device comprises the target device; fusing the network topology data, the target event data and the target performance index data to generate a fault event vector; using a preset rule engine to perform pattern matching on the fault event vector to obtain a fault matching result of the target device; in the case that the fault matching result represents that the target device has a fault, determining a fault range according to the network topology data to generate a fault diagnosis result comprising the fault range, wherein the network topology data comprises connection relationships between the network devices. By using the hierarchical analysis strategy, heterogeneous log data is converted into event data in a unified format, then by using the sliding time window, event data and performance index data within a preset time length associated with a device are collected and fused to generate a fault event vector, finally by using the rule engine, a fault is quickly located, and the fault range is determined in combination with the network topology data, thereby solving the problem of low fault diagnosis efficiency caused by insufficient integration of multi-source heterogeneous data. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the accompanying drawings needed to be used in the embodiments or related art description will be briefly introduced. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0021] Figure 1 A hardware environment schematic diagram of an optional industrial network fault diagnosis method according to the embodiments of the present application; Figure 2 A flowchart of an optional industrial network fault diagnosis method according to the embodiments of the present application; Figure 3A schematic diagram of an optional industrial network fault diagnosis system according to an embodiment of the present application; Figure 4 A flowchart of an optional fault event vector generation method according to an embodiment of the present application; Figure 5 A schematic diagram of an optional hierarchical resolution strategy according to an embodiment of the present application; Figure 6 A flowchart of another optional industrial network fault diagnosis method according to an embodiment of the present application; Figure 7 A block diagram of an optional industrial network fault diagnosis apparatus according to an embodiment of the present application; Figure 8 An optional electronic device structure schematic diagram according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0023] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only for the convenience of the description of the present application, and have no specific meaning in itself. Therefore, "module" and "component" can be used interchangeably.

[0024] Industrial Ethernet as a key information infrastructure, its stability is crucial to industrial production, and industrial Ethernet switch as the core network equipment, its fault diagnosis is the core link to ensure the reliable operation of the network.

[0025] The current industrial network fault diagnosis field faces many outstanding problems, such as log heterogeneity difficult to automate analysis, multi-modal data isolated difficult to form a complete fault view, highly dependent on operation and maintenance experience leading to low diagnosis efficiency, long average fault repair time. The diagnosis scheme based on rule base or single machine learning model also has the defects of rigid rules, insufficient data correlation, poor generalization ability, etc., which is difficult to break through the core bottleneck of multi-source data integration, and cannot meet the urgent needs of industrial network for high reliability and intelligent diagnosis.

[0026] For the problem of low fault diagnosis efficiency due to insufficient integration of multi-source heterogeneous data in industrial network fault diagnosis, effective solutions are urgently needed.

[0027] To address the problems mentioned in the background art, according to one aspect of the embodiments of this application, an embodiment of a fault diagnosis method for industrial networks is provided.

[0028] Optionally, in the embodiments of this application, the above-described industrial network fault diagnosis method can be applied to, for example, Figure 1 The hardware environment shown consists of terminal 101 and server 103. Figure 1 As shown, server 103 is connected to terminal 101 via a network and can be used to provide services (data acquisition services, data parsing services, etc.) to the terminal or clients installed on the terminal. Database 105 can be set up on the server or independently of the server to provide data storage services for server 103. The network mentioned above includes, but is not limited to, wide area network, metropolitan area network or local area network. Terminal 101 includes, but is not limited to, PC, mobile phone, tablet computer, etc.

[0029] The fault diagnosis method for an industrial network in this embodiment can be executed by server 103, or it can be executed jointly by server 103 and terminal 101, such as... Figure 2 As shown, it includes: Step 201: Obtain the operating data of at least one network device in the industrial network, wherein the operating data includes log data and performance index data; Step 202: Use a hierarchical parsing strategy to perform structured parsing on the log data and generate event data in a unified format; Step 203: Use a sliding time window to collect target event data and target performance index data generated by the target device within a preset time period, and obtain the network topology data of the target device, wherein the network device includes the target device; Step 204: Merge network topology data, target event data, and target performance index data to generate a fault event vector; Step 205: Use a preset rule engine to perform pattern matching on the fault event vector to obtain the fault matching result of the target device; Step 206: If the fault matching result indicates that the target device has a fault, determine the fault range based on the network topology data to generate a fault diagnosis result that includes the fault range, wherein the network topology data includes the connection relationship between various network devices.

[0030] The application first converts heterogeneous log data into event data in a unified format through a hierarchical analysis strategy, breaking the problem of log format differences; then, with the help of a sliding time window, the event data and performance indicator data within a preset time period associated with the device are associated, and the fault event vector is generated by fusing the network topology data, breaking the "data island"; finally, the fault range is determined in combination with the network topology data, and the effective integration of multi-source data of logs, performance and topology is realized, providing complete data support for fault diagnosis.

[0031] The diagnostic method provided by the application can be applied to Figure 3 The diagnostic method provided by the application can be applied to The application provides a fault diagnosis system for the industrial network shown in the figure, which comprises a data acquisition layer, a data processing and analysis layer, an AI analysis and diagnosis layer, and an application interaction layer. The data acquisition layer is used to collect original log data, performance indicator data, device configuration state and network topology data from an industrial Ethernet switch through system log (Syslog), simple network management protocol / trap (SNMP, Simple Network Management Protocol) / trap, and link layer discovery protocol (LLDP, Link Layer Discovery Protocol). The data processing and analysis layer is used to convert the collected heterogeneous original data (log data, performance indicator data, etc.) into standardized JSON format data through a regular expression engine and a large language model (LLM, Large Language Model Semantic Parsing Engine) semantic analysis engine, and correct the analysis result of the LLM semantic analysis engine through artificial feedback of the application interaction layer to ensure data standardization. The AI analysis and diagnosis layer comprises a fault diagnosis engine, a case library and a rule library, which are used to fuse, analyze and reason the standardized JSON data, complete fault diagnosis by matching the case library and the rule library, and correct the matching result of the case library and the rule library through artificial feedback of the application interaction layer to continuously optimize the diagnosis accuracy, and the diagnosis result is stored in the case library. The application interaction layer comprises a Web control layer, a natural language processing (NLP, Natural Language Processing Interaction Interface) interactive interface and a work order pushing interface, which are used to realize artificial feedback (correcting analysis / matching results, updating cases / rules) through the Web control layer, provide natural language interaction capability through the NLP interactive interface, push the result through the work order pushing interface, and finally present the diagnosis result to the user in a visual and interactive form.

[0032] Specifically, Syslog-ng or Rsyslog is used as a log collector and deployed in an independent container. All network devices are configured to send log data to the collector's UDP 514 port. After the collector performs preliminary filtering on the log data, it pushes the raw log messages to the Kafka Topic named raw-syslog via the Kafka producer.

[0033] Specifically, it is developed based on the Snmp4j library and encapsulated as an independent microservice. According to the pre-configured device IP address and OID (Object Identifier) list, the service actively polls device performance indicators at regular intervals (such as every 60 seconds). The collected performance indicator data is serialized in JSON and pushed to the snmp-metrics Topic of Kafka.

[0034] Specifically, the topology discovery service is developed based on the LLDP protocol, which periodically discovers device connection relationships and stores network topology data in the topology table of the database.

[0035] Through standardized collection and hierarchical parsing, the standardized processing of heterogeneous logs and multi-source data is realized, greatly improving data availability. The sliding time window fusion mechanism ensures the accurate correlation of fault-related data, providing complete context for diagnosis. The fault range definition based on topology data makes the diagnosis results more comprehensive, facilitating the rapid positioning of the impact boundary for operation and maintenance personnel.

[0036] As an optional embodiment, a hierarchical parsing strategy is used to structure the log data and generate event data in a unified format, including: using a pre-defined rule template library to match and parse the log data; if the parsing is successful, generating event data according to the matched rule output template, if the parsing fails, enabling a semantic parsing model to perform entity recognition and semantic analysis on the log data to obtain event data, wherein the semantic parsing model is trained using domain-specific corpus.

[0037] A rule template library for industrial Ethernet switch logs is pre-built (covering various major brands). The rule template library uses a MySQL relational database for storage. Each rule in the library includes device manufacturer, device model, log type identifier, rule priority, regular matching pattern, and standard JSON output template fields. Rules are logically grouped by log type identifier.

[0038] When processing logs, a set of candidate rules is first selected based on the device manufacturer and model, and then matched in priority order. Multiple rules can be defined for the same type of log to achieve general-to-specific matching.

[0039] The semantic analysis model is a large language model optimized based on an open source base model and has been trained through industry Ethernet switch domain corpus (the detailed training process is described below).

[0040] The semantic analysis model is trained on massive industrial texts and can effectively perform entity recognition (such as device, port, and error type) and relationship extraction for non-standard, ambiguous, or misspelled logs.

[0041] The semantic analysis model can process difficult or non-standard log data that cannot be matched by regular expressions. Using the semantic analysis model for entity recognition and semantic analysis of log data, semantic error correction can also be performed. Ultimately, event data in JSON format consistent with the regular output_template format is obtained, which can break through format restrictions, accurately extract core information, and ensure comprehensive analysis.

[0042] The parsing logic of the hierarchical parsing strategy is: first, check if there is a rule in the rule template library that can match the log data. If there is, it means that the parsing is successful. If not, use the semantic analysis model to parse and process the log data. In simple terms, for standard logs (such as interface state changes), regular expressions are used for matching, and for logs that do not match, a fine-tuned LLM model is used for deep semantic understanding, error correction, and parsing. Regardless of which method is used for parsing, the final result is event data in a unified format (JSON format).

[0043] Event data includes, but is not limited to, basic event identification information, device and port association information, log source identification information, and original log trace information.

[0044] This embodiment combines the efficiency of regular expressions with the strong generalization ability of semantic analysis models to solve the problem of industrial Ethernet switch log heterogeneity. Regardless of the form of log data, it is parsed into the required event data, avoiding incomplete or even failed parsing due to non-uniform data formats.

[0045] As an optional embodiment, a predefined rule template library is used to match and parse log data, including: calling the rule template library and selecting a candidate rule set from the rule template library that matches the device attributes of the network device, wherein each candidate rule in the candidate rule set has a priority; the regular expressions of each candidate rule are matched with the log data one by one from high to low according to the priority; if any candidate rule matches the log data successfully, it is determined that the parsing is successful, and if it fails to match each candidate rule, it is determined that the parsing fails.

[0046] The pre-constructed rule template library is called to obtain device manufacturer and device model information of a network device to which the log data to be parsed belongs, and then a number of rules with completely matched attributes are filtered from the rule template library based on the information to form a candidate rule set. Table 1 is an example of a rule template library field structure table.

[0047] Table 1

[0048] Each rule in the candidate rule set is pre-provided with a priority field, the priority value ranges from 1 to 100, and the smaller the value, the higher the priority. The rules in the candidate rule set are sorted from high to low according to the priority field.

[0049] According to the sorted order, the regular expression in each candidate rule is extracted in turn and matched with the log data to be parsed until a matching rule is found or all candidate rules are traversed.

[0050] If the regular expression of any candidate rule completely matches the log data during the traversal process, it is directly determined that the parsing is successful; if the regular expressions of all candidate rules do not match the log data after the traversal, it is determined that the parsing fails.

[0051] The log formats of switches of different manufacturers and models have inherent differences, the rules are stored in the rule template library according to device attributes, irrelevant rules can be directly filtered, and the number of invalid matching times is reduced. At the same time, for a plurality of same type log rules that may exist under the same device attribute, the priority is sorted to ensure that special scene logs are matched with special rules and general logs are matched with general rules, to realize the precise matching logic from special to general, which not only guarantees the matching accuracy, but also improves the parsing efficiency.

[0052] As an optional embodiment, after the log data is subjected to entity recognition and semantic analysis using the semantic parsing model to obtain event data, the method further includes: generating a new regular expression according to the text content of the log data; constructing a new output template corresponding to the new regular expression according to the event data; constructing a new rule according to the new regular expression and the new output template; and storing the new rule in the rule template library.

[0053] The log data includes fixed words and variable parameters (such as port numbers and IP addresses), and the variable part is replaced by a corresponding regular wildcard through an algorithm (such as pattern generalization based on a specific delimiter and a word), thereby constructing a new regular expression that can match the same type of logs.

[0054] The output of the semantic analysis model is already normalized event data and is in a JSON structure. This JSON structure can be used as a template, and the field values therein can be associated with new regular expressions to form a complete rule record, which is stored in a rule template library. In this way, the next time the same type of log appears, the rule template library can be used to match and analyze the same type of log data, without the need to call the semantic analysis model again.

[0055] As an optional embodiment, the target event data and the target performance indicator data generated by the target device within a preset time length are collected using a sliding time window, including: taking the unique identifier of the target device as a partition key, routing the event data and the performance indicator data belonging to the target device to the same message partition; and maintaining a sliding time window for the unique identifier to collect the target event data and the target performance indicator data arriving at the sliding time window within a preset time length.

[0056] The event data of the target device output by the data processing and analysis layer and the performance indicator data of the target device acquired by the data acquisition layer are routed to the same message partition of Kafka through the routing mechanism of the Apache Kafka message queue, by taking the Internet Protocol (IP) address of the target device as the unique identifier (i.e., the partition key), to ensure the aggregation and storage of multi-source data of the same target device.

[0057] On the premise that all devices perform Network Time Protocol (NTP) time synchronization, a sliding time window is maintained for the unique identifier of each target device, and the preset time length can be adjusted as needed (for example, set to ±20 seconds, i.e., the first 20 seconds and the last 20 seconds of the fault occurrence). The corresponding message partition is listened to in real time, and the target event data and the target performance indicator data arriving within the sliding time window are all included in the window for temporary storage and association, to ensure that the relevant data before and after the fault occurrence is covered.

[0058] The network topology data includes the connection relationship between each network device, and is used to trace the upstream and downstream devices of the current device. Based on the Network Time Protocol time synchronization results of all network devices, the target event data and the target performance indicator data within the sliding time window are accurately aligned in time sequence based on the time stamp of the data. The core information of the target performance indicator data and the target event data, including event type, interface state, port error rate, and port utilization, is integrated, and the network topology data is added to generate a unified fault event vector containing device identifier, time stamp, structured event data, associated performance indicators, and upstream and downstream devices.

[0059] For example, the data of two Topics parsed-events (parsed log event data) and snmp-metrics (performance metric data) in Kafka are grouped by device through KeyBy (device_ip), and the log event data and performance metric data generated by the same device are associated in a sliding time window to form a unified fault event vector.

[0060] Figure 4 The generation method flowchart of the fault event vector provided in the present application is shown in the figure. After the SNMP service is collected, it is pushed to the kafka message queue, including collection time, CPU (Central Processing Unit, Central Processing Unit) utilization, port sending and receiving number, error packet number, port utilization, etc. The specific generation steps include: Step 401, consume two topics (parsed-events fault log events and snmp-metrics performance metric data in Kafka), and convert JSON messages into Parsed Event objects and Snmp Metric objects; Step 402, group by device ip; Step 403, define a time window (such as ±10s), and take out all performance metric data of the target device within 10s before and after the event from the Snmp Metric object, and associate the event and performance; Step 404, query the topology information of the target device in the database to determine the upstream and downstream devices. Since step 402 groups by ip, the performance data of the upstream and downstream devices within 20s can also be obtained; Step 405, obtain all log event data of the target device within 10s before and after the fault, which can be obtained from the database. (If the device is associated with a business, these data can also be obtained as auxiliary judgment); Step 406, combine the topology information, log event data and performance metric data into a complete fault event vector.

[0061] The present application provides an example of a fault event vector as follows: { "event_id": "event_20231001120523_192.168.1.1", / / Unique event ID "timestamp": "2023-10-01T12:05:23Z", / / Event occurrence time "primary_device": "192.168.1.1", / / Core device IP "parsed_log": {...}, / / Standard JSON output from parsing engine "related_metrics": [{…},], / / Associated performance metrics (SNMP) "topology_context": { / / Topology "directly_connected_devices": [ / / Directly connected devices (discovered via LLDP) { "local_interface": "GigabitEthernet1 / 0 / 1", / / Local interface "neighbor_device": "192.168.1.100", / / Neighbor device IP "neighbor_interface": "eth0", / / Neighbor interface "neighbor_type": "Switch", / / Device type } ], "affected_downstream_services": [ / / Affected downstream services (derived based on topology and device-associated services) { "service_name": "Production Line Control 1", / / Service name "impact_level": "CRITICAL", / / Impact level "path": "Core-Switch -> GigabitEthernet1 / 0 / 1 -> Switch(192.168.1.100)", / / Service path } ] } } Note: Performance metrics data is collected from a Simple Network Management Protocol (SNMP) collector, and network topology data is derived from device association relationships identified automatically using the Link Layer Discovery Protocol (LLDP). The event occurrence time (standard timestamp for fault events) follows the UTC (Coordinated Universal Time) time format and is synchronized based on the Network Time Protocol (NTP).

[0062] By integrating the three types of key data, event data after log data analysis, performance indicators, and network topology data, the scattered multi-source heterogeneous information is converted into structured and context-rich fault descriptions, ensuring that the preset rule engine can simultaneously determine faults based on fault phenomena (event data), device status (performance indicator data), and associated impacts (network topology data) when performing pattern matching, ultimately achieving accurate diagnosis of fault causes and impact ranges.

[0063] This embodiment realizes accurate aggregation of multi-source data of the same target device through partition key routing, efficiently filters out fault-related data with the help of a sliding time window, and completes data fusion in combination with time alignment, effectively breaking the dilemma of "data islands" of event data and performance indicator data.

[0064] As an optional embodiment, a preset rule engine is used to perform pattern matching on the fault event vector to obtain a fault matching result of the target device, including: inputting the fault event vector into the preset rule engine to enable the preset rule engine to perform pattern matching between the fault event vector and a rule library of the preset rule engine; and obtaining a fault matching result output by the preset rule engine, wherein the fault matching result is used to indicate whether the target device has a fault.

[0065] The preset rule engine provided in the application is a Drools rule engine.

[0066] The fault event vector is input into the Drools rule engine, and the fault event vector contains a unique event identifier, a timestamp, a core device Internet Protocol (IP) address, structured log data (i.e., event data), associated performance indicator data, and network topology data.

[0067] The Drools rule engine automatically loads a rule library stored in a MySQL relational database when the application is started, and the rule library contains.drl format rule files written based on expert knowledge of industrial network fault diagnosis. Each rule clearly defines the conditions and logic of fault determination. The Drools rule engine imports the fault event vector into the working memory, automatically traverses all rules in the rule library, and accurately compares the multi-dimensional data in the fault event vector with the rule conditions one by one to perform pattern matching operations.

[0068] After completing full rule matching, the Drools rule engine outputs a fault matching result, which directly indicates whether the target device has a fault. If there is a fault, the fault matching result also includes the fault type (such as interface interruption, link jitter, etc.), the device environment of the target device, etc.

[0069] The embodiment realizes the automatic processing of fault determination through the Drools rule engine, without the need for operation and maintenance personnel to manually check massive data, and greatly improves the efficiency of fault identification.

[0070] As an optional embodiment, determining the fault range according to the network topology data to generate a fault diagnosis result including the fault range, comprises: determining the upstream device and / or downstream device of the target device according to the connection relationship recorded in the network topology data; determining the upstream device and / or downstream device as the fault range; extracting the fault type from the fault matching result, and taking the fault type and the fault range as the fault diagnosis result.

[0071] The network topology data pre-stored in the database topology table is called, and the network topology data records the connection relationship between all network devices in the industrial Ethernet. According to the target device Internet Protocol (IP) address locked by the fault matching result, the connection relationship information corresponding to the target device is accurately extracted from the network topology data, and the directly associated upstream device and / or downstream device is determined.

[0072] In combination with the fault characteristics of the target device, the extracted upstream device and / or downstream device is directly defined as the fault influence range, ensuring that all associated devices that have a direct connection link with the target device and may be affected by the fault are covered.

[0073] From the fault matching result output from the preset rule engine, the specific fault type of the target device is extracted; the defined fault range and the extracted fault type are associated and integrated to generate a complete fault diagnosis result including the fault type and the affected device list (upstream device and / or downstream device).

[0074] The fault upstream and downstream associated devices are accurately positioned through the network topology data, the fault range is quickly defined, and the problem of fuzzy fault influence boundary in traditional manual troubleshooting is avoided. The fault type and the fault range are integrated into a complete fault diagnosis result, which provides clear fault core information and influence boundary for the operation and maintenance personnel.

[0075] The network topology graph is automatically constructed and maintained through the link layer discovery protocol such as LLDP. When a port Down log is parsed, the system can automatically associate the connected downstream device and evaluate the influence range to form a unified, context information-rich, multi-modal data associated fault event vector.

[0076] After obtaining the fault diagnosis result, the fault diagnosis result is input into the semantic analysis model, and the source device of the fault can be further determined through the semantic analysis model.

[0077] Next, the generation of the semantic analysis model is described.

[0078] As an optional embodiment, the method further comprises generating the semantic parsing model in the following manner: obtaining text data in the industrial network field, and obtaining a plurality of sets of sample pairs labeled from the text data, wherein the text data includes device operation logs, device configuration manuals, and fault analysis reports, and the sample pairs include target inputs and target outputs corresponding to the target inputs; pre-training an initial model using the text data to obtain an intermediate model; based on the sample pairs, fine-tuning the intermediate model using a single-turn instruction and a multi-turn dialogue interaction mode to obtain the semantic parsing model.

[0079] Text data in the industrial network field is collected, specifically including device operation logs (such as system logs Syslog) of common industrial Ethernet switches on the market, device configuration manuals, fault analysis reports, and maintenance records, etc.; the above text data is labeled by field experts, entities such as device Internet Protocol (IP) addresses, port numbers, and error types in the logs are extracted, the relationships between entities are clarified, and then a plurality of sets of sample pairs are constructed, each set of sample pairs containing a target input (i.e. an input instruction) and a corresponding target output (JSON data in the format of a regular expression output template).

[0080] The sample pair provided in the application is as follows: Target input: parse the log "1WARNDING: Ethernet5 / 3 link down alarm is Occur" Target output: { " event_type ": " link down", "facility": "LINEPROTO", "severity": "3", / / event severity level, the smaller the number, the more serious "mnemonic": "UPDOWN", / / short identifier for a specific event "interface": " Ethernet5 / 3", "oper_state": "down", / / current state of the interface "device_ip": "192.168.1.1", "raw_log": "1WARNDING: Ethernet5 / 3 link down alarm is Occur ", } On the basis of multiple sets of sample pairs, more training samples can be synthesized through synonym replacement, sentence transformation, etc. to enhance the generalization ability of the model and achieve the effect of data enhancement.

[0081] The open-source base model Qwen-Coder can be selected as the initial model, and the collected industrial network field text data is injected into the initial model for training using the pyTorch framework. Through pre-training, the model deeply learns the device configuration knowledge, network protocol specifications, common fault types and fault solutions related to industrial networks, masters the language patterns and professional terminology system in the operation and maintenance scene, and obtains an intermediate model with basic industrial network field knowledge.

[0082] Based on the constructed sample pairs, a single-round instruction and multi-round dialogue combined interaction mode is adopted to supervise and fine-tune the intermediate model. For example, in the single-round instruction mode, the model is input with the instruction "analyze the specified original log and generate standardized JSON" and the corresponding sample pairs, to teach the model to follow the fixed format requirements and understand the analysis intent; in the multi-round dialogue mode, for complex or ambiguous log samples, the analysis requirements are clarified through multi-round interaction to strengthen the model's entity recognition and semantic understanding ability for non-standard, error-containing logs. Finally, a semantic analysis model is obtained.

[0083] The trained semantic analysis model is encapsulated as a remote procedure call (gRPC) service, which can be called by the system background to process non-standard, ambiguous or spelling error-containing log data that cannot be matched by the regular expression engine, and output standardized JSON data consistent with the regular analysis result format.

[0084] During the use of the semantic analysis model, historical unrecognized logs, i.e. internal accumulated original log texts that cannot be recognized by the LLM, and manually annotated data, i.e. data annotated and corrected by operation and maintenance personnel through a web interface for unrecognized / incorrectly recognized logs, are collected. These data generated during system operation are higher quality training samples and are used for incremental fine-tuning of the model on a regular basis, so that the LLM model becomes the core content of accurately analyzing industrial switch network fault logs.

[0085] The pre-training of the domain-specific text data in this embodiment makes the model deeply fit the industrial network fault diagnosis scene, greatly improves the recognition accuracy of professional terms and fault types, and fine-tunes the single-round instruction and multi-round interaction mode based on sample pairs, ensuring that the model strictly follows the output format requirements and generates standardized data consistent with the regular analysis results, ensuring the unity of multi-modal data association. The generated semantic analysis model can effectively process non-standard, ambiguous logs that cannot be matched by regular expressions.

[0086] Figure 5A schematic diagram of the hierarchical resolution strategy provided in this application is shown in the figure, including: Raw log input: Receive raw log data generated by industrial network devices (such as switches) as the input source for the parsing process; Regular expression matching: Logs are matched primarily using the regular expression engine; If a match is successful, the log is directly converted into standardized structured data (such as a JSON string) and output to the diagnostic engine for subsequent processing; if a match fails (such as when the log is in a vendor-customized format or contains ambiguous content), it enters the LLM parsing stage. LLM parsing: The Large Language Model (LLM) semantic parsing engine is called via the gRPC interface to process unmatched logs. If LLM parsing is successful, structured data consistent with the regular expression matching result format is output and passed to the diagnostic engine. If LLM parsing fails, the log is marked as "pending" and enters the manual correction process. Manual correction and model optimization: For "pending" logs, the parsing results are adjusted through the manual correction interface, and then the LLM is incrementally trained based on the corrected data to continuously improve the model's parsing ability.

[0087] This application uses a regular expression engine (for efficient processing of standard logs) and an LLM engine (for comprehensive log parsing by covering non-standard logs). Simultaneously, through incremental training based on human feedback, the LLM continuously learns and gradually reduces parsing failures, forming a self-optimizing closed loop for parsing capabilities.

[0088] As an optional embodiment, after generating a fault diagnosis result including the fault range, the method further includes: upon receiving a query instruction from the target object, performing intent parsing on the query instruction to obtain a parsing result; if the parsing result indicates that the query instruction intent is ambiguous, initiating multiple rounds of dialogue with the target object until a clear query intent is obtained; converting the query intent into a query statement, and using the query statement to find the fault diagnosis result and the corresponding fault repair strategy in the target database; and pushing the fault diagnosis result and the fault repair strategy to the target object.

[0089] After obtaining the fault diagnosis results, the fault diagnosis results are first matched with the corresponding repair strategies, and then stored in the target database. The target database is also used to store structured diagnosis rules, historical fault cases, manual correction records, including the associated storage structure of fault characteristics-diagnosis results-repair strategies.

[0090] Regularly (e.g., weekly) check the manual correction record library. When a certain type of correction record accumulates to a certain number (e.g., 100 records), automatically trigger the model training task, use new data to incrementally train the LLM parsing model, and generate new regular expression rules, which are automatically updated to the rule library after review.

[0091] The application provides a visual interface and operation portal for operation and maintenance personnel in the application interaction layer. It is developed using Vue.js and Element Plus UI framework, and provides static resource services through Nginx, as well as log correction interface, diagnostic report visualization, topology display and other functions.

[0092] The application interaction layer receives query instructions issued by the target object (such as operation and maintenance personnel) through the natural language processing interaction interface. The query instruction supports text input and voice input. The received query instruction is transmitted to the integrated large language model interface, which analyzes the intent of the query instruction and determines whether the instruction is clearly directed to specific fault-related information (such as fault diagnosis results and repair strategies of specific equipment and specific workshops). The corresponding analysis result is obtained.

[0093] If the analysis result shows that the query instruction intent is ambiguous (such as only input "port down, what to do", without specifying the device name, IP or location), the application interaction layer initiates a follow-up question to the target object, gradually obtains key information in multiple rounds of dialogue, until the target object supplements the necessary information, forms a clear query intent, and ensures the accuracy of subsequent queries.

[0094] The clear query intent is converted into a query statement conforming to the structured query syntax through the natural language processing interface. Based on the query statement, the target database (MySQL relational database, including case library and rule library data tables) storing fault diagnosis results, historical fault cases and corresponding repair strategies is retrieved, and fault diagnosis results (including fault type, fault range, etc.) and corresponding fault repair strategies matching the query intent are accurately selected.

[0095] The retrieved fault diagnosis results and fault repair strategies are integrated and pushed to the target object in the form of a visual report through the application interaction layer. The report includes fault root cause, impact range, repair steps and estimated time.

[0096] For example, the application automatically converts complex fault results into easy-to-understand maintenance recommendation reports, using natural language to explain the root cause, impact range and repair steps, such as "root cause: Ethernet1 / 2 / 1 optical module aging; suggestion: replace SFP module, check optical fiber; estimated time: 15 minutes".

[0097] In addition, the application also includes a work order automatic pushing function, including: after the generation of a diagnosis result, a Restful API (Application Programming Interface) is called to generate a standardized maintenance work order in one click, and the work order is automatically pushed to the relevant person in charge through a work order pushing interface. The work order automatic pushing function can further shorten the fault repair cycle and improve the operation and maintenance efficiency.

[0098] The embodiment allows operation and maintenance personnel to quickly obtain the required fault diagnosis result and repair strategy without mastering professional commands or query syntax through natural language interaction, thereby greatly reducing the operation and maintenance threshold.

[0099] Figure 6 Another flowchart of the fault diagnosis method of the industrial network provided by the application is shown in the figure, which includes: Data collection: obtain the log, performance index and other original data of the industrial network equipment through a standard protocol to provide a basic data source for subsequent processing; Dual-engine analysis (regular and LLM): a hierarchical strategy of "regular expression engine + large language model (LLM) semantic analysis engine" is adopted to convert heterogeneous original data into a standardized format: the regular engine preferentially matches standard logs, and the LLM engine processes non-standard / fuzzy logs to ensure data unification; Multi-modal data correlation: through mechanisms such as a sliding time window, the standardized log data, performance index data and time sequence information of the same device are fused to generate a fault event vector containing complete context, breaking the "data island"; Rule engine diagnosis: input the fault event vector into the rule engine to match expert knowledge in the case library and rule library to automatically determine whether the device is faulty and the fault type; Generate diagnosis result: integrate the fault determination result and network topology data to generate a diagnosis result containing the fault type and impact range; Manual review and correction: manually check the diagnosis result: If the check result is correct, it is directly applied (the process ends), and if it needs to be corrected, the case library and rule library are updated after the result is adjusted, and the feedback is fed back to the "rule engine diagnosis" link to realize system self-optimization.

[0100] The above steps realize rapid fault identification through automatic data analysis, correlation and diagnosis, and through manual feedback to update the case / rule library, a closed loop of diagnosis and optimization is formed to continuously improve the accuracy and adaptability of system diagnosis.

[0101] The application provides a fault diagnosis method of an industrial network, comprising: obtaining running data of at least one network device in the industrial network, wherein the running data comprises log data and performance index data; using a hierarchical analysis strategy to structurally analyze the log data to generate event data in a unified format; using a sliding time window to collect target event data and target performance index data generated by a target device within a preset time length, and obtaining network topology data of the target device, wherein the network device comprises the target device; fusing the network topology data, the target event data and the target performance index data to generate a fault event vector; using a preset rule engine to perform pattern matching on the fault event vector to obtain a fault matching result of the target device; in the case that the fault matching result represents that the target device has a fault, determining a fault range according to the network topology data to generate a fault diagnosis result comprising the fault range, wherein the network topology data comprises connection relationships between the network devices. The heterogeneous log data is converted into event data in a unified format through the hierarchical analysis strategy, then the event data and performance index data within a preset time length associated with a device are collected through the sliding time window, and the fault event vector is generated by fusing, finally, the fault is quickly located through the rule engine, and the fault range is determined in combination with the network topology data, thereby solving the problem of low fault diagnosis efficiency caused by insufficient integration of multi-source heterogeneous data.

[0102] According to another aspect of the embodiments of the application, the application provides an industrial network fault diagnosis device, as shown in Figure 7 The device comprises: An acquisition module 701 is configured to acquire running data of at least one network device in the industrial network, wherein the running data comprises log data and performance index data. An analysis module 702 is configured to use a hierarchical analysis strategy to structurally analyze the log data to generate event data in a unified format. A collection module 703 is configured to use a sliding time window to collect target event data and target performance index data generated by a target device within a preset time length, and obtain network topology data of the target device, wherein the network device comprises the target device. A fusion module 704 is configured to fuse the network topology data, the target event data and the target performance index data to generate a fault event vector. A matching module 705 is configured to use a preset rule engine to perform pattern matching on the fault event vector to obtain a fault matching result of the target device. A determination module 706 is configured to, in the case that the fault matching result represents that the target device has a fault, determine a fault range according to the network topology data to generate a fault diagnosis result comprising the fault range, wherein the network topology data comprises connection relationships between the network devices.

[0103] It should be noted that the acquisition module 701 in this embodiment can be used to execute step 201 in the embodiments of the present application, the analysis module 702 in this embodiment can be used to execute step 202 in the embodiments of the present application, the collection module 703 in this embodiment can be used to execute step 203 in the embodiments of the present application, the fusion module 704 in this embodiment can be used to execute step 204 in the embodiments of the present application, the matching module 705 in this embodiment can be used to execute step 205 in the embodiments of the present application, and the determination module 706 in this embodiment can be used to execute step 206 in the embodiments of the present application.

[0104] Optionally, the analysis module 702 is further configured to match and analyze the log data by using a predefined rule template library; if the analysis is successful, event data is generated according to a matched rule output template; if the analysis fails, an entity recognition and semantic analysis of the log data are performed by using a semantic analysis model to obtain the event data, wherein the semantic analysis model is obtained by training using domain corpus.

[0105] Optionally, the analysis module 702 is further configured to call the rule template library, and filter a candidate rule set matched with the device attribute of the network device from the rule template library, wherein each candidate rule in the candidate rule set has a priority; the log data is matched with regular expressions of each candidate rule one by one in descending order of the priority; if any candidate rule is matched with the log data successfully, it is determined that the analysis is successful; if the log data is not matched with each candidate rule, it is determined that the analysis fails.

[0106] Optionally, the apparatus further comprises a processing module configured to, after the entity recognition and semantic analysis of the log data are performed by using the semantic analysis model to obtain the event data, generate a new regular expression according to text content of the log data; construct a new output template corresponding to the new regular expression according to the event data; construct a new rule according to the new regular expression and the new output template; and store the new rule in the rule template library.

[0107] Optionally, the collection module 703 is further configured to route the event data and the performance index data belonging to the target device to the same message partition by taking the unique identifier of the target device as a partition key; and maintain a sliding time window for the unique identifier to collect target event data and target performance index data reaching the sliding time window within a preset time length.

[0108] Optionally, the matching module 705 is further configured to input the fault event vector into a preset rule engine to enable the preset rule engine to perform pattern matching between the fault event vector and a rule library of the preset rule engine; and obtain a fault matching result output by the preset rule engine, wherein the fault matching result is used to indicate whether the target device has a fault.

[0109] Optionally, the determining module 706 is further configured to determine the upstream device and / or the downstream device of the target device according to the connection relationship recorded in the network topology data; determine the upstream device and / or the downstream device as the fault range; extract the fault type from the fault matching result, and take the fault type and the fault range as the fault diagnosis result.

[0110] Optionally, the apparatus further includes a generating module configured to generate the semantic parsing model in the following manner: obtaining text data in the industrial network field, and obtaining a plurality of groups of sample pairs labeled from the text data, wherein the text data includes device operation logs, device configuration manuals, and fault analysis reports, and the sample pair includes a target input and a target output corresponding to the target input; pre-training an initial model using the text data to obtain an intermediate model; based on the sample pair, fine-tuning the intermediate model using a single-turn instruction and a multi-turn dialogue interaction mode to obtain the semantic parsing model.

[0111] Optionally, the apparatus further includes a querying module configured to, after generating the fault diagnosis result including the fault range, in a case where a query instruction issued by a target object is received, perform intent analysis on the query instruction to obtain an analysis result; if the analysis result is that the query instruction intent is ambiguous, initiate a multi-turn dialogue with the target object until a query intent with a clear intent is obtained; convert the query intent into a query statement, and use the query statement to find the fault diagnosis result and the corresponding fault repair strategy in the target database; and push the fault diagnosis result and the fault repair strategy to the target object.

[0112] It should be noted that the above modules and the examples and application scenarios implemented by the corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules as part of the apparatus can run in the hardware environment as shown in Figure 1 .

[0113] According to another aspect of the embodiments of the present application, the present application provides an electronic device as shown in Figure 8 , which includes a memory 801, a processor 803, a communication interface 805, and a communication bus 807. The memory 801 stores a computer program executable on the processor 803. The memory 801 and the processor 803 communicate through the communication interface 805 and the communication bus 807. The processor 803 executes the computer program to implement the steps of the above method.

[0114] The memory, the processor in the electronic device above communicate through a communication bus and a communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0115] The memory can include a Random Access Memory (RAM) and can also include a non-volatile memory, such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the processor.

[0116] The processor above can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0117] According to another aspect of the embodiments of the present application, a computer readable medium having non-volatile program code executable by a processor is also provided.

[0118] Optionally, the specific examples in the embodiments can refer to the examples described in the above embodiments, and the embodiments will not be described here.

[0119] In the specific implementation, the embodiments of the present application can refer to the above various embodiments and have corresponding technical effects.

[0120] It can be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSP Devices), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.

[0121] For software implementation, the techniques described herein can be implemented with a processing unit that executes software routines or functions to perform the techniques described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented within the processor or external to the processor.

[0122] Those of ordinary skill in the art can understand that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those of ordinary skill in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0123] Those of ordinary skill in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0124] In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other ways. For example, the above-described device embodiments are only schematic, and the division of the modules is only a logical function division, and there can be another division way in actual implementation, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed units can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0125] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, i.e. may be located in one place, or may be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0126] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0127] The functions, if realized in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application can be embodied in the form of software products, and the computer software products are stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, and various program codes that can be stored in the medium. It should be noted that, in this paper, the relationship terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the processes, methods, articles or devices including a series of elements not only include those elements, but also include other elements not explicitly listed, or include elements inherent to such processes, methods, articles or devices. Without more limitations, the elements defined by the statement "including a" do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0128] The above is only a specific embodiment of the present application, so that those skilled in the art can understand or implement the present application. Various modifications of these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features applied herein.

Claims

1. A fault diagnosis method for an industrial network, characterized in that, include: Acquire operational data of at least one network device in an industrial network, wherein the operational data includes log data and performance indicator data; The log data is structured and parsed using a hierarchical parsing strategy to generate event data in a unified format; The target device generates target event data and target performance index data within a preset time period using a sliding time window, and obtains the network topology data of the target device, wherein the network device includes the target device; The network topology data, the target event data, and the target performance index data are fused to generate a fault event vector; The fault event vector is pattern matched using a preset rule engine to obtain the fault matching result of the target device; If the fault matching result indicates that the target device has a fault, the fault range is determined according to the network topology data to generate a fault diagnosis result that includes the fault range, wherein the network topology data includes the connection relationship between the various network devices.

2. The method according to claim 1, characterized in that, The step of using a hierarchical parsing strategy to perform structured parsing on the log data and generate event data in a unified format includes: The log data is matched and parsed using a predefined rule template library; If the parsing is successful, the event data is generated by outputting a template according to the matched rules. If the parsing fails, the semantic parsing model is activated to perform entity recognition and semantic analysis on the log data to obtain the event data. The semantic parsing model is trained using domain-specific corpus.

3. The method according to claim 2, characterized in that, The process of matching and parsing the log data using a predefined rule template library includes: The rule template library is invoked, and a set of candidate rules matching the device attributes of the network device is selected from the rule template library, wherein each candidate rule in the set of candidate rules has a priority. According to the priority from high to low, the log data is matched one by one with the regular expressions of each of the candidate rules; If any of the candidate rules matches the log data, the parsing is considered successful; if no match is found with any of the candidate rules, the parsing is considered unsuccessful.

4. The method according to claim 2, characterized in that, After using a semantic parsing model to perform entity recognition and semantic analysis on the log data to obtain the event data, the method further includes: Generate a new regular expression based on the text content of the log data; Based on the event data, construct a new output template corresponding to the new regular expression; Based on the new regular expression and the new output template, construct new rules; The new rule is stored in the rule template library.

5. The method according to claim 1, characterized in that, The method of collecting target event data and target performance index data generated by the target device within a preset time period using a sliding time window includes: Using the unique identifier of the target device as the partition key, the event data and performance index data belonging to the target device are routed to the same message partition; A sliding time window is maintained for the unique identifier to collect the target event data and the target performance index data that arrive at the sliding time window within the preset time period.

6. The method according to claim 1, characterized in that, The step of using a preset rule engine to perform pattern matching on the fault event vector to obtain the fault matching result of the target device includes: The fault event vector is input into the preset rule engine so that the preset rule engine performs pattern matching between the fault event vector and its own rule base. Obtain the fault matching result output by the preset rule engine, wherein the fault matching result is used to indicate whether the target device has a fault.

7. The method according to claim 1, characterized in that, The step of determining the fault range based on the network topology data to generate a fault diagnosis result that includes the fault range includes: The upstream and / or downstream devices of the target device are determined based on the connection relationships recorded in the network topology data. The upstream equipment and / or the downstream equipment are identified as the fault range; The fault type is extracted from the fault matching result, and the fault type and the fault range are used as the fault diagnosis result.

8. The method according to claim 2, characterized in that, The method further includes generating the semantic parsing model in the following manner: Acquire text data in the field of industrial networks, and obtain multiple sets of sample pairs by annotating the text data. The text data includes equipment operation logs, equipment configuration manuals and fault analysis reports. The sample pairs include target inputs and target outputs corresponding to the target inputs. The initial model is pre-trained using the text data to obtain an intermediate model; Based on the sample pairs, the intermediate model is fine-tuned using a single-turn instruction and multi-turn dialogue interaction mode to obtain the semantic parsing model.

9. The method according to claim 1, characterized in that, After generating fault diagnosis results that include the fault range, the method further includes: Upon receiving a query instruction from the target object, the query instruction is parsed to obtain the parsing result; If the parsing result indicates that the intent of the query instruction is ambiguous, then multiple rounds of dialogue are initiated with the target object until a clear query intent is obtained; The query intent is converted into a query statement, and the query statement is used to find the fault diagnosis results and corresponding fault repair strategies in the target database. The fault diagnosis results and the fault repair strategy are pushed to the target object.

10. An electronic device comprising a memory, a processor, a communication interface, and a communication bus, wherein the memory stores a computer program executable on the processor, and the memory and the processor communicate via the communication bus and the communication interface, characterized in that... When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

Images