A method for constructing a traceability graph between devices based on real-time analysis of communication requests

Abstract

The present application relates to the field of equipment monitoring technology, and discloses a method for constructing a traceability graph between devices based on real-time analysis of communication requests, including the following steps: step a, identifying the type of communication protocol, analyzing the protocol characteristics of the communication request data packet to determine the type of protocol used for communication between devices; step b, parsing the content of the communication request, extracting information such as device ID, communication protocol, request type, data size, timestamp, etc., and standardizing it into a data structure in a unified format; step c, mapping the device identification with the device communication protocol to ensure the consistency of the device identification between different protocols. By real-time analysis of communication requests between devices, a traceability graph between devices can be constructed dynamically and timely, and the communication behavior between devices can be fully tracked. This real-time update mechanism ensures that the communication relationship between devices can reflect the latest status of the device at any time, reduces the lag of traditional static monitoring methods, and helps to discover problems in device communication more quickly.

Description

Technical Field

[0001] The present invention relates to the technical field of equipment monitoring, and in particular to a method for constructing an inter-equipment traceability graph based on real-time analysis of communication requests. Background Art

[0002] With the rapid development of IoT technology and intelligent devices, the communication network between devices has become more and more complex, and the types of devices involved are also increasing. In the fields of industrial automation, intelligent manufacturing, power systems, etc., devices exchange data and control each other through various communication protocols to ensure the normal operation and efficient operation of the system. However, with the expansion of equipment scale and the diversification of communication networks, how to effectively monitor, manage and diagnose the communication behavior between devices has become a key challenge in system management. Especially when equipment failure or abnormality occurs, it becomes crucial to discover and locate the problem in real time.

[0003] At present, traditional equipment monitoring and fault diagnosis methods mostly rely on manual inspections or post-analysis based on historical data. These methods usually require a lot of manual intervention and cannot achieve real-time, automated fault identification and diagnosis. In some systems, the communication protocols between devices are diverse, and the equipment manufacturers and models are different, resulting in poor interoperability between devices and difficulty in unified monitoring and analysis of device communication behaviors. In addition, most existing technologies lack real-time dynamic tracking of communication between devices, cannot update the communication relationship and status between devices in a timely manner, and are difficult to support efficient traceability between cross-protocol and heterogeneous devices.

[0004] Therefore, existing equipment monitoring systems generally have problems such as insufficient real-time performance, poor adaptability, and weak fault prediction capabilities. They are unable to effectively cope with complex communication scenarios and fault emergency needs between devices. Especially in terms of communication anomaly detection and fault prediction between devices, they often rely on manual analysis and experience judgment, resulting in delayed fault response, affecting the stability and operation efficiency of the system.

[0005] Existing inter-device communication monitoring systems mostly rely on static protocol parsing and data analysis methods, and are unable to provide real-time, dynamic device communication relationship traceability diagram construction. In addition, traditional systems usually lack sufficient flexibility and intelligence in multi-protocol, multi-device environments, and are unable to automatically identify and predict device failures. Existing technologies cannot meet the real-time monitoring needs in large-scale, heterogeneous device networks, resulting in communication anomalies between devices that are difficult to detect in a timely manner, affecting the stability of the system and the efficiency of fault handling. Therefore, there is an urgent need for a new method that can construct a traceability diagram in real time in dynamic inter-device communication, and perform real-time detection and intelligent prediction of abnormal behaviors between devices to improve the efficiency and accuracy of device monitoring. Summary of the invention

[0006] In view of the shortcomings of the prior art, the present invention provides a method for constructing a traceability graph between devices based on real-time analysis of communication requests, which solves the problem of constructing a traceability graph between devices in real time and automatically detecting communication anomalies and predicting faults in a complex, heterogeneous communication network between devices.

[0007] The method for constructing a traceability graph between devices based on real-time analysis of communication requests includes the following steps: Step a, identifying the communication protocol type, analyzing the protocol characteristics of the communication request data packet to determine the protocol type used for communication between devices; Step b, parsing the communication request content, extracting information such as device ID, communication protocol, request type, data size, timestamp, etc., and standardizing it into a data structure in a unified format; Step c: Mapping the device identification to the device communication protocol to ensure the consistency of the device identification between different protocols; Step d: Based on the communication requests between devices, a traceability graph between devices is constructed in real time, device nodes are added, and the communication relationships between devices are recorded. The attributes of the edges include the communication request type, data volume, and timestamp. Step e: Analyze the communication behavior between devices in real time, perform anomaly detection in combination with the traceability diagram, and predict potential failures or abnormal events of the device based on the communication behavior.

[0008] Preferably, in step a, identification of the communication protocol type is achieved by parsing header features, protocol fields or custom identifiers of data packets, supporting automatic identification and processing of multiple communication protocols.

[0009] Preferably, the data standardization format in step b adopts JSON format, including device ID, device type, protocol type, request type, data size and request timestamp, and ensures that data of all devices can be processed according to unified standards.

[0010] Preferably, the device identification mapping in step c uses a device unique identifier to ensure consistency between different device protocols and update device status information during each communication.

[0011] Preferably, the traceability graph in step d is stored and managed through a graph database. The nodes in the traceability graph represent devices. Each device node has attributes such as device ID, device type, protocol type, and device status. The edges represent the communication relationship between devices. The attributes of the edges include request type, data volume, and timestamp information.

[0012] Preferably, the anomaly detection module in step e is based on a graph analysis algorithm, identifies anomalies through statistical analysis of factors such as communication frequency and data traffic, and performs fault warning in combination with device status.

[0013] Preferably, the fault prediction module in step e is based on a timing analysis model, utilizes historical communication data of the device, predicts the type of fault that may occur in the device through a machine learning algorithm, and automatically generates a fault warning.

[0014] Preferably, the update mechanism of the traceability graph is based on event triggering. When a device initiates a communication request, the traceability graph is automatically updated to add new device nodes or update the communication edges between devices.

[0015] Preferably, data storage is managed using a distributed graph database, and the data storage process includes compression, deduplication, and index optimization.

[0016] The present invention provides a method for constructing a traceability graph between devices based on real-time analysis of communication requests. It has the following beneficial effects: 1. The present invention can dynamically and timely build a traceability diagram between devices and comprehensively track the communication behavior between devices by real-time analysis of communication requests between devices. This real-time update mechanism ensures that the communication relationship between devices can reflect the latest status of the devices at any time, reduces the lag of traditional static monitoring methods, helps to discover problems in device communication more quickly, avoids information delays or omissions under traditional methods, and thus improves the accuracy and timeliness of device communication monitoring.

[0017] 2. The present invention adopts a flexible communication protocol parsing mechanism, which can support a variety of different communication protocols and heterogeneous communication environments between devices. Through a unified parsing module, the present invention can adapt to the communication formats of different devices, whether it is TCP / IP protocol, Modbus protocol, CAN bus protocol or industrial Ethernet protocol, and can achieve effective communication data parsing and traceability diagram construction. This makes the method suitable for a wider range of application scenarios and can achieve efficient equipment monitoring and fault detection in a complex equipment network environment.

[0018] 3. The present invention can automatically identify abnormal communication behaviors between devices and predict potential device failures or communication interruptions by introducing an anomaly detection mechanism based on rules, statistics, and machine learning. Through real-time monitoring of device communication behaviors, the system can promptly detect abnormal patterns in device communications, such as abnormal communication frequencies, data loss, or response delays, thereby effectively preventing the occurrence of device failures and identifying failure risks in advance through intelligent prediction. This not only improves the speed of fault response, but also reduces equipment downtime and improves the reliability and stability of equipment operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 The present invention is a flow chart of the method. DETAILED DESCRIPTION

[0020] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0021] Please see attached Figure 1 The embodiment of the present invention provides a method for constructing a traceability graph between devices based on real-time analysis of communication requests, including: 1. Communication request parsing module In the method for constructing a traceability graph between devices based on real-time parsing of communication requests of the present invention, the communication request parsing module is one of the core components, which is responsible for real-time parsing of data packets of communication requests between devices, identifying communication protocols, extracting key data and performing standardized processing. This module realizes the identification of communication requests of cross-protocol devices by parsing data packets of different protocols, and provides basic data support for the subsequent construction of traceability graphs and anomaly detection. The functions of the communication request parsing module include not only protocol identification, but also detailed parsing and standardization of communication request contents, ensuring that in a multi-protocol environment between devices, communication requests of different protocol types can be uniformly managed and processed.

[0022] In this embodiment, the communication request parsing module is implemented in the following aspects: Protocol type identification The primary task of the communication request parsing module is to identify the type of protocol used by the communication request. The communication protocols between different devices may be different, such as HTTP, Modbus, MQTT, CoAP, etc. Each protocol has a unique data packet structure and fields. In this embodiment, the communication request parsing module identifies the protocol type by analyzing the header information or custom field characteristics of the request data packet. For example, if the header of the data packet contains a "GET" or "POST" field, the data packet belongs to the HTTP protocol; if the function code of the data packet conforms to the data frame structure of the Modbus protocol, it can be determined that the data packet uses the Modbus protocol. Through the matching of the protocol header information or the data packet format, the communication request parsing module can automatically identify the communication protocol, and forward the data to the corresponding parsing module for subsequent processing according to the protocol type. The protocol identification formula is: ;

[0023] in, is the header information of the data packet, f is the protocol identification function, and returns the communication protocol type.

[0024] Communication request content analysis After identifying the protocol type, the communication request parsing module will parse the specific content of the request and extract key information. This information includes but is not limited to: Device ID: Each device has a unique identifier. The device ID is used to identify the device that initiates the communication or the target device.

[0025] Device type: Function or category information of the device, such as sensor, actuator, gateway, etc.

[0026] Request type: The specific operation type of the communication request, such as read data, write data, etc.

[0027] Data size: The amount of data transmitted in a communication request, which can be obtained through the length field in the data packet or the number of bytes in the data frame.

[0028] Timestamp: The time when the request is initiated. By parsing the timestamp field in the request packet, the exact moment when the device request occurs is recorded.

[0029] Data analysis formula: ;

[0030] in, Represents the i-th field in the data packet, g is the parsing function, and i is the field index.

[0031] These data will be extracted in the communication request parsing module and converted into a unified data structure format (such as JSON format) to facilitate subsequent processing and storage. The standardized data structure unifies the formats of different protocol data packets and provides a universal data input for the construction of subsequent traceability graphs.

[0032] Data format standardization In this embodiment, the communication request parsing module converts the parsed request content into a standardized format, such as JSON format. JSON format can effectively represent information such as device ID, device type, request type, data volume, timestamp, etc., and ensure uniform processing of cross-protocol devices. This standardized format has the following characteristics: Clear device information: The data of each communication request includes key information such as device ID and device type, which can clearly identify the device identity.

[0033] Consistent communication content: Regardless of the protocol used by the original data packet, the standardized format gives the request data a unified structure, simplifying subsequent processing and storage.

[0034] Strong scalability: New communication protocols or device types can be supported by adding new fields to ensure the flexibility and scalability of the system.

[0035] Cross-protocol support Since the communication between devices may involve multiple protocols, the communication request parsing module needs to have the ability to handle different protocols. This embodiment adopts a protocol adaptation method, and modularizes the parsing methods of different protocols so that the communication request parsing module can dynamically support new protocols. For example, if the system needs to support the new industrial protocol ModbusRTU, only a new parsing module for the Modbus protocol needs to be added without affecting the existing protocol parsing logic. Each protocol parsing module is responsible for extracting the corresponding data fields according to the protocol features, and uniformly formatting the parsing results into JSON objects. This approach not only meets the needs of cross-protocol parsing, but also enhances the flexibility and scalability of the system.

[0036] Real-time and high efficiency In this embodiment, the communication request parsing module adopts an efficient parsing algorithm to ensure that data parsing can be completed quickly and accurately during the real-time transmission of device requests. By optimizing the characteristic matching of the protocol and the segmentation of data packets, the communication request parsing module can complete the processing of requests with low latency. In addition, the module adopts an event-driven approach, and the parsing operation is triggered when the device communication request arrives. There is no delay backlog, which ensures the real-time and high efficiency of the system.

[0037] Error handling and data validation During the communication request parsing process, data format errors or protocol parsing failures may occur. To this end, the communication request parsing module includes an error handling mechanism. When a parsing failure occurs, it will automatically retry or log, and return an appropriate error code to the device initiator. At the same time, the module verifies the integrity of the data to ensure that the transmitted data has not been tampered with and to ensure the accuracy of the traceability map data.

[0038] The communication request parsing module in this embodiment, through real-time parsing of communication requests between devices, identifies the type of communication protocol, extracts information such as device ID, request type, data volume, timestamp, etc. in the request, and standardizes it into a unified format, ensuring compatibility between different devices and protocols and efficient data processing. In addition, the communication request parsing module also has functions such as cross-protocol support, real-time parsing, and error handling, providing strong data support for the subsequent construction of traceability diagrams and analysis of communication behaviors between devices. Through this module, the traceability diagram between devices can be updated in real time, supporting efficient monitoring of device communication behaviors, anomaly detection, and fault warning.

[0039] 2. Device identity mapping and consistency management In the method for constructing a traceability graph between devices based on real-time parsing of communication requests of the present invention, the device identification mapping and consistency management module is responsible for ensuring the consistency and uniqueness of the device identifier. With the increasing number of communication requests between devices, especially in a cross-protocol, multi-device environment, the device identifiers may be encoded and represented in different ways. Therefore, how to uniformly manage device identification and ensure consistency across protocols and devices has become a key issue in the process of constructing the traceability graph. This module introduces a unique device identifier (UID) to map device identifications under different protocols, ensuring that each device in the system can be identified with a unified and unique identifier, providing accurate device data support for the subsequent construction of the traceability graph and the monitoring of communication behaviors between devices.

[0040] In this embodiment, the implementation of device identification mapping and consistency management includes the following aspects: Assignment and management of device unique identifiers (UIDs) During the communication process between devices, each device needs to have a unique identifier (UID), which serves as the "identity" of the device in the traceability graph. In order to ensure the uniqueness and cross-protocol consistency of device identifiers, this embodiment adopts a centrally managed device ID allocation mechanism. When a new device is first connected to the network, the system assigns it a unique device UID. The device UID will remain unchanged throughout the life cycle of the device as a unique identifier for the device in the system. The device's UID is not affected by the protocol type or the device's communication behavior, ensuring the uniqueness of the device under different protocols.

[0041] Cross-protocol device identifier mapping In actual applications, different devices may interact through different communication protocols, such as Modbus protocol, HTTP protocol, MQTT protocol, etc. In this case, the same device may have different identifiers under different protocols. In order to deal with this cross-protocol communication problem, the device identification mapping and consistency management module manages the device identifier through a mapping table. The mapping table records the mapping relationship between the identifier of each device under different protocols and the unique device UID. When the device initiates a communication request, the communication request parsing module will look up the corresponding UID from the mapping table and uniformly map the device identifier to the UID. In this way, the system can ensure that the uniqueness of the device is always guaranteed regardless of the protocol used by the device.

[0042] Maintaining consistent device identifiers During the life cycle of a device, its identifier should remain consistent. To ensure the consistency of the device identifier, the system registers the identifier when the device is first connected, and all subsequent device communication requests should use the UID of the device. The system uses a centralized device management module to ensure that the UID of the device does not change during device replacement, upgrades, or maintenance. If the device changes the protocol or the device identifier changes, the system will update the mapping table to ensure that a unified and consistent UID is used in subsequent communication requests.

[0043] Device status synchronization and update The device identification mapping and consistency management module not only manages the unique identifier of the device, but is also responsible for maintaining the synchronization and update of the device status. Each device in the system will have a status information associated with its UID, such as the device's current working status, communication status, and the last communication time. When the device initiates communication through different protocols, the system will update its status information based on the device UID. In this way, each device node in the traceability graph can reflect the real-time status of the device, ensuring the accuracy of the traceability graph data.

[0044] Device identifier conflict resolution mechanism When a device accesses a network or changes a protocol, a device identifier conflict may occur. To avoid this situation, the device identifier mapping and consistency management module in this embodiment is designed with a conflict detection and resolution mechanism. When the system finds a device identifier conflict, it will reassign a unique device UID by verifying the device's unique identification information such as the MAC address and IP address, and update the mapping relationship table to ensure that each device has a unique and consistent identifier in the system.

[0045] Dynamic update and management of device identifier mapping The device identification mapping table is not static, but is updated in real time according to the dynamic access and communication changes of the device. When a new device joins the network, the system automatically assigns it a UID and updates the mapping table; when the device protocol changes, the system will also update the device's identifier mapping in a timely manner. The device identification mapping and consistency management module ensures the consistency and reliability of the device identifier in the entire system through this dynamic update mechanism.

[0046] Data consistency verification mechanism In order to ensure the accuracy of device identifier mapping, this embodiment also introduces a data consistency verification mechanism. After each communication request is resolved, the system will verify the device identifier to ensure that the device always uses the same UID throughout the communication process. If an inconsistent device identifier or a mapping error is detected, the system will automatically correct the identifier and record the error information to ensure the reliability of the device identifier.

[0047] The device identification mapping and consistency management module in this embodiment solves the problem of identifier consistency in a multi-protocol, multi-device environment by allocating a unique device identifier (UID) and managing its cross-protocol mapping. The system ensures the accuracy and consistency of device identifiers by dynamically updating the device identifier mapping table, thereby ensuring the accuracy of subsequent traceability diagram construction and device communication behavior analysis. In addition, the module also effectively avoids device identifier conflicts and errors through conflict detection mechanisms, data consistency verification mechanisms and other means, ensuring the reliability and stability of the system. Through the implementation of this module, the traceability diagram between devices can accurately reflect the identity and status of each device, providing a stable data foundation for subsequent anomaly detection and fault prediction.

[0048] 3. Construction and update of traceability graph In the method for constructing a traceability graph between devices based on real-time parsing of communication requests of the present invention, the traceability graph construction and update module is responsible for constructing a real-time traceability graph between devices according to communication requests between devices, and updating the traceability graph in real time when the device status or communication behavior changes. The traceability graph is a visual graph that reflects the relationship and communication process between devices, which can help users clearly understand the behavior and status changes of the devices. By constructing and updating the traceability graph in real time, this module not only provides a detailed tracing path for device communication, but also helps to realize behavior monitoring, fault warning and anomaly detection between devices.

[0049] In this embodiment, the implementation of the provenance graph construction and update includes the following aspects: Structural design of traceability diagram When constructing a provenance graph, its basic structure must first be clarified. In this embodiment, the provenance graph consists of device nodes and communication relationship edges between devices. Each device is represented in the provenance graph by its unique device identifier (UID) as a node, and communication requests between devices are represented by directed edges. The nodes of the provenance graph not only represent the identity of the device, but also can contain the current status information of the device, such as device type, working status, communication status, etc. Each edge represents a communication request between devices, and the attributes of the edge include request type, data transmission volume, request time, etc.

[0050] The process of constructing a traceability graph The construction of the traceability graph is based on real-time device communication request data. The specific construction process is as follows: Communication request reception and analysis: The communication request first passes through the communication request analysis module to extract information such as the device UID, device type, request type, data volume and timestamp.

[0051] Update of traceability graph node: After receiving a communication request, the system will check whether the device node already exists in the traceability graph according to the device UID in the request. If not, a new node will be created for the device and the basic information of the device will be recorded. If the device node already exists, the device status information (such as the device's working status, the last communication time, etc.) will be updated.

[0052] Creation and update of traceability graph edges: Whenever communication is initiated between two devices, the system creates a directed edge in the traceability graph to represent the communication relationship between the devices. The direction of the edge represents the initiator and receiver of the communication, and the attributes of the edge include detailed information such as request type and data volume. If there is a corresponding communication relationship between the devices, the system will update the attribute information of the edge (such as accumulated data volume, update request time, etc.) to keep the communication record up to date.

[0053] Visual display of the traceability graph: By constructing the traceability graph, the system can display the communication relationship between devices to the user through a visual interface, allowing the user to intuitively understand the interaction between devices and the device status.

[0054] Real-time update of traceability graph The traceability graph not only needs to be initially constructed when a device communication request arrives, but also needs to be updated in real time when the device status or communication behavior changes. The specific update mechanism includes: Device status update: When the status of a device changes (such as device failure, device upgrade, device offline, etc.), the system will automatically update the corresponding device node in the traceability diagram and update the device status information.

[0055] Communication behavior update: If the communication behavior between devices changes, such as the type, frequency, or data volume of communication requests, the system will promptly update the edge attribute information in the traceability graph to reflect the latest status of communication between devices.

[0056] Dynamic maintenance of the traceability graph: During the entire system operation, the construction and update of the traceability graph is a continuous process. Whenever a new device is added, the device status changes, or a communication request occurs between devices, the system will update the traceability graph in real time based on the new information to ensure that the information in the graph always reflects the latest status of the device in the system.

[0057] Anomaly detection and alerting of traceability graphs The traceability diagram is not only a tool for displaying the communication relationship between devices, it can also be used as an effective means of anomaly detection. In this embodiment, abnormal behavior detection and alarm in device communication can be achieved through real-time update and analysis of the traceability diagram. For example: Abnormal device behavior: If a device frequently initiates communication requests in a short period of time, or the amount of data requested increases abnormally, the system can detect the abnormal situation in time through the changes in the edge attributes in the traceability graph and trigger an alarm mechanism.

[0058] Device failure or abnormal status: If a device has not updated its communication record for a long time in the traceability graph, or the device status changes abnormally (such as the device goes offline, the device cannot communicate, etc.), the system can detect the device failure or abnormality through the changes in the device node in the traceability graph and send an alarm notification.

[0059] Abnormal communication path: If the traceability diagram finds that the communication path between devices does not meet expectations (for example, the direction of the communication request is wrong, the amount of requested data is unreasonable, etc.), the system will also promptly discover the communication anomaly through analysis of the traceability diagram and trigger an alarm.

[0060] Historical Records and Retrospective Analysis of Tracing Graphs The traceability graph is not only a tool for real-time updates, it can also record the historical communication behavior of the device and provide support for subsequent retrospective analysis. In this embodiment, the system saves the historical records of communication between devices and traces back the historical communication between devices based on the traceability graph. For example, when a device failure occurs, the system can trace back the historical communication records to find the communication request before the failure occurs and analyze the root cause of the failure. The historical traceability graph can also be used for performance analysis, fault diagnosis and system optimization.

[0061] Data storage and management of traceability graphs The data structure of the provenance graph needs to be stored and managed efficiently. To achieve this, this embodiment uses a graph database (such as Neo4j, ArangoDB, etc.) to store and manage the data of the provenance graph. The graph database can efficiently store the communication relationship between devices through the optimized graph data structure and support fast query and update operations. The system continuously maintains and manages the provenance graph through the graph database to ensure that the provenance graph can be efficiently updated as the device communication changes.

[0062] The traceability graph construction and update module in this embodiment can accurately reflect the communication behavior and state changes between devices by constructing and dynamically updating the traceability graph between devices through real-time analysis based on device communication requests. Through the traceability graph, users can not only intuitively understand the communication relationship between devices, but also realize device behavior monitoring, anomaly detection and fault warning. In addition, the historical record function of the traceability graph provides strong support for backtracking analysis and fault diagnosis, helping users to deeply analyze the system operation and improve the efficiency and accuracy of device management.

[0063] 4. Anomaly detection and intelligent prediction In the method for constructing a traceability graph between devices based on real-time analysis of communication requests of the present invention, the anomaly detection and intelligent prediction module is responsible for automatically detecting abnormal behaviors between devices based on the device communication behaviors and device status information in the traceability graph, and predicting the occurrence of device failures or abnormal situations through intelligent prediction technology. With the increase in the number of devices and the complexity of communication behaviors, traditional manual monitoring methods often fail to detect potential problems in a timely manner, resulting in low system efficiency and even major failures. This module combines the device communication data and device status information in the traceability graph, and uses data analysis and machine learning technology to monitor abnormal behaviors between devices in real time, and can predict potential failure risks, effectively improve the operating reliability of the equipment, reduce downtime, and provide forward-looking decision support for operation and maintenance personnel.

[0064] In this embodiment, the implementation of anomaly detection and intelligent prediction includes the following aspects: Abnormal behavior detection mechanism The abnormal behavior detection mechanism aims to identify abnormal communication behaviors between devices or abnormal fluctuations in device status. In this embodiment, abnormal behavior detection is based on real-time data of communication requests between devices and device status information in the traceability diagram, and is performed in the following ways: Rule-based anomaly detection: A series of rules for normal communication behavior are defined in the system, such as the maximum communication frequency of each device, the threshold of the amount of data in a single communication, the shortest interval of communication between devices, etc. Once the device communication behavior exceeds the scope of these rules, the system will determine it as abnormal communication. For example, if a device frequently sends a large number of data requests in a short period of time, or if a device sends a request that does not comply with the protocol during the communication process, the anomaly detection mechanism can be triggered.

[0065] Statistical anomaly detection: Statistical analysis of historical data on device communications is performed to establish normal communication patterns for each device (such as communication frequency, data volume, etc.). When a device's communication behavior deviates significantly from the historical normal pattern, the system identifies it as an anomaly. For example, a sudden drop in the communication frequency of a device, or an abnormal increase in the amount of communication data, may indicate that the device is faulty or abnormal.

[0066] Anomaly detection based on machine learning: This embodiment also uses machine learning algorithms (such as anomaly detection algorithms, clustering algorithms, etc.) to model the communication behavior between devices and automatically identify abnormal patterns. By learning a large amount of historical communication data, the model can automatically identify the characteristics of normal and abnormal behaviors. When the communication behavior of the device deviates significantly from the learned normal pattern, the system will trigger an alarm.

[0067] Intelligent prediction mechanism The goal of the intelligent prediction mechanism is to predict the occurrence of equipment failure or system abnormality based on the existing equipment status and communication behavior. To achieve this goal, this embodiment introduces machine learning and data mining technology, combined with the equipment's traceability diagram and historical data, to predict potential failure risks in advance. The intelligent prediction mechanism mainly includes the following steps: Data collection and feature extraction: The system extracts the communication behavior data and status information of the device from the traceability graph as the input features of the prediction model. These features include the device's communication frequency, request type, data volume, device working status, and historical fault records.

[0068] Model training: Based on historical equipment failure data, supervised learning or unsupervised learning algorithms (such as support vector machines, random forests, neural networks, etc.) are used to train prediction models. The model identifies potential failure risks by learning the communication mode and the change pattern of equipment status before the equipment fails. For example, by analyzing the equipment's communication frequency, request response time and other characteristics, it is predicted that the equipment may fail in the next period of time.

[0069] Fault prediction and risk assessment: Once the model training is complete, the system will predict device faults based on real-time device communication data and status information. When the system detects that the behavior or status of a device is deviating from the normal mode, the prediction model will determine that the device is at risk of failure and conduct a risk assessment of the failure based on the prediction results. For example, if the communication frequency of the device gradually decreases and the device status frequently switches to an abnormal state, the system may predict that the device will fail in the short term and respond in advance.

[0070] Warning and early warning mechanism of prediction results: Based on the fault prediction results, the system will issue early warnings to operation and maintenance personnel, notifying them in advance of possible equipment failures or abnormalities, helping them take measures before the failure occurs. The early warning information includes the predicted time of the failure, possible causes of the failure, and the scope of the failure. Operation and maintenance personnel can make decisions based on this information, such as replacing equipment in advance and scheduling maintenance.

[0071] Self-optimization and updating of intelligent prediction models In order to improve the prediction accuracy, the intelligent prediction model needs to be continuously optimized and updated. In this embodiment, the intelligent prediction model performs self-optimization in the following ways: Real-time update and feedback mechanism: Whenever a device fails or anomalies, the system will record the time, location, and cause of the failure and feed it back to the prediction model. By learning from actual failure data, the model can adjust weights and parameters to improve prediction accuracy.

[0072] Incremental learning and online training: In order to adapt to the ever-changing device communication mode and status information, the model adopts incremental learning for online training. The system will periodically update the model based on the new device communication data and status information to keep the model up to date to adapt to the dynamic changes in device behavior.

[0073] Model evaluation and adjustment: The accuracy of the prediction model is evaluated regularly, and the evaluation indicators include prediction accuracy, recall rate, F1 value, etc. If the evaluation results show that the prediction effect of the model has declined, the system will adjust the model's algorithm or parameters for retraining and optimization.

[0074] Visual display of anomaly detection and intelligent prediction The results of anomaly detection and intelligent prediction not only need to be promptly reported, but also need to be displayed to users through visualization. The system can display detected abnormal events, predicted failure risks, and the health status of the equipment through a graphical interface. Users can view the communication status, failure warnings, and risk assessment results of the equipment in real time through charts, dashboards, etc. In addition, the system also supports the generation of historical reports to help users analyze the long-term operation trends and failure patterns of the equipment, and further optimize the equipment's operation and maintenance strategies.

[0075] The anomaly detection and intelligent prediction module in this embodiment can effectively identify abnormal behaviors between devices and predict potential failure risks by real-time monitoring of device communication behaviors and status information, combined with machine learning and data analysis technology. Through rule-based, statistical, and machine learning anomaly detection, the system can promptly detect abnormal communication behaviors or status fluctuations of devices; through the intelligent prediction mechanism, the system can predict equipment failures in advance, provide forward-looking decision support for operation and maintenance personnel, and reduce equipment downtime and failure losses. In addition, the self-optimization mechanism of the intelligent prediction model ensures the accuracy and real-time nature of the prediction results, providing a strong guarantee for the long-term operation and maintenance of the system. Example

[0076] This embodiment uses the equipment monitoring system in an intelligent manufacturing factory as a scenario to illustrate how to use the device traceability graph construction method based on real-time analysis of communication requests to perform device communication monitoring, traceability graph construction and anomaly detection.

[0077] Scenario description: In a smart manufacturing factory, multiple devices on the production line (such as robots, sensors, PLC controllers, etc.) communicate through industrial Ethernet. Each device can initiate communication requests to other devices, such as transmitting sensor data, receiving control commands, etc. The factory's production management system requires real-time monitoring of device status and communication behavior to quickly identify potential failures and optimize production processes.

[0078] Provenance graph construction and update When a device in the factory sends or receives a communication request, the system first analyzes the request content through the communication request parsing module, extracting information such as the UID of the request initiating device and the receiving device, the request type, the data volume, and the request time. Then, based on this information, the system dynamically builds a traceability diagram between devices.

[0079] For example, if sensor A sends a data request to robot B, the system will create a directed edge from sensor A to robot B in the provenance graph, and the attributes of the edge include data volume, request type (such as "sensor data"), and timestamp. As communication between devices continues, the provenance graph will continue to update, adding or updating device nodes and communication relationships between devices to reflect the latest communication status of the devices.

[0080] Anomaly detection and intelligent prediction The system also monitors device communication behavior in real time and predicts possible failures through anomaly detection and intelligent prediction modules. Assume that robot B's communication frequency is abnormal, such as frequently requesting data from sensor A in a short period of time, which may indicate that robot B has a communication problem or failure.

[0081] In this case, the system uses a rule-based anomaly detection mechanism to determine whether the communication behavior exceeds the normal range. For example, the rule set by the system is "receive a maximum of 5 sensor data requests per hour". If the request frequency of robot B exceeds this threshold, the system will trigger anomaly detection.

[0082] Furthermore, the system uses intelligent prediction capabilities to analyze the communication patterns and historical failure data of Robot B to predict whether Robot B is likely to fail. For example, if the number of requests from Robot B is on an upward trend and the response time is increasing, the prediction model may indicate that Robot B is about to fail, and the system will issue an early warning to the maintenance personnel.

[0083] Alerting and decision support Once an anomaly is detected or a fault is predicted, the system will display the traceability diagram between devices to the operation and maintenance personnel through a graphical interface, and highlight the abnormal device nodes or communication paths. At the same time, the system will provide detailed warning information, such as "Robot B has initiated more than 20 data requests in the past hour, and there may be a hardware failure" and "The prediction model shows that Robot B may fail in the next 12 hours."

[0084] Based on the real-time monitoring data and fault prediction information provided by the system, operation and maintenance personnel can conduct equipment inspections, adjust production processes or arrange maintenance in a timely manner, thereby improving production efficiency and reducing equipment downtime.

[0085] This embodiment realizes real-time monitoring and fault prediction of intelligent manufacturing factory equipment through the construction method of inter-device traceability graph based on real-time analysis of communication requests, combined with anomaly detection and intelligent prediction technology. The system can not only dynamically build and update the communication relationship graph between devices, but also identify and predict equipment failures in advance based on the real-time behavior and historical data of the equipment, providing reliable decision support for operation and maintenance personnel. Example

[0086] This embodiment uses the device monitoring system in the smart grid as a scenario to illustrate how to use the device traceability graph construction method based on real-time analysis of communication requests to perform device communication monitoring, traceability graph construction and anomaly detection.

[0087] Scenario Description In smart grids, many devices (such as substation controllers, smart meters, power sensors, etc.) exchange information through wireless communication networks. Real-time data such as the grid's operating status, load data, and equipment health information needs to be transmitted between different devices. Power operators hope to monitor the communication behavior of these devices and promptly detect equipment failures or communication anomalies, thereby improving the reliability and security of the grid.

[0088] Provenance graph construction and update Whenever devices in the power grid (such as controller C and power sensor D in the substation) communicate, the system first parses the content of the communication request through the communication request parsing module to extract relevant information, such as the ID of the sending device, the ID of the receiving device, the communication type (such as data upload, control command, etc.), the size and timestamp of the data packet, etc.

[0089] For example, if controller C sends a load data request to power sensor D, the system will create a communication path from controller C to sensor D in the traceability graph, including the request type ("load data request"), data volume (e.g. "10MB"), and request time (e.g. "2024-12-15 08:00"). As device communications increase, the traceability graph will continue to be updated, and device nodes and communication paths will be expanded and updated based on new request information.

[0090] Anomaly detection and intelligent prediction The system monitors the communication behavior and device status between devices in real time through the anomaly detection and intelligent prediction module, and identifies abnormal communication patterns or device failures. Assume that power sensor D frequently receives load data requests from controller C in a short period of time, and the device's response time gradually increases, which may indicate that there is a problem with the processing capacity of sensor D.

[0091] In this case, the system first checks whether the device communication behavior complies with the predetermined rules through the rule-based anomaly detection function. For example, the system may set "each device can process a maximum of 3 data requests per minute". If the request frequency of sensor D exceeds this threshold, the system will trigger anomaly detection.

[0092] Furthermore, the system uses machine learning models to analyze the historical data of the device, learn the normal communication behavior pattern of the device, and predict the possible failure of the device in combination with the current communication data. For example, if sensor D has frequently experienced response delays in the past 24 hours, and the system detects its state change trend through intelligent prediction algorithms, the system may predict that the device will fail in the next few hours and issue an alarm in advance.

[0093] Alerting and decision support When an abnormal detection or fault prediction occurs, the system will immediately send an alarm to the operation and maintenance personnel. The operation and maintenance personnel view the traceability diagram through the graphical interface, and the system will mark the abnormal communication path and display the relevant device information and status. For example, the communication path between controller C and sensor D will be highlighted in red, and the system will provide a warning that "Sensor D has received too many data requests in the past 10 minutes, and the response time has exceeded the threshold."

[0094] In addition, the system also provides early warning information based on predictions, such as: "The prediction model shows that sensor D may fail in the next 2 hours. It is recommended to check the equipment status and perform maintenance." Operation and maintenance personnel can make decisions quickly based on these warning information. For example, if the status of sensor D has been predicted to be abnormal, the operation and maintenance personnel can dispatch backup sensors in advance to avoid data collection interruptions in the power grid and ensure the reliability of power grid operation.

[0095] This embodiment plays an important role in the monitoring and fault prediction of smart grid equipment through the construction method of inter-device traceability graph based on real-time analysis of communication requests. Through real-time monitoring of inter-device communication behavior and device status, combined with anomaly detection and intelligent prediction technology, the system can effectively identify device anomalies and predict potential failures. This method not only improves the operating efficiency of the power grid, but also reduces the losses caused by sudden failures, providing scientific decision-making support for power operators.

[0096] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for constructing a traceability graph between devices based on real-time analysis of communication requests, characterized in that: The following steps are involved: Step a, identifying the communication protocol type, analyzing the protocol characteristics of the communication request data packet to determine the protocol type used for communication between devices; Step b, parsing the communication request content, extracting information such as device ID, communication protocol, request type, data size, timestamp, etc., and standardizing it into a data structure in a unified format; Step c: Mapping the device identification to the device communication protocol to ensure the consistency of the device identification between different protocols; Step d: Based on the communication requests between devices, a traceability graph between devices is constructed in real time, device nodes are added, and the communication relationships between devices are recorded. The attributes of the edges include the communication request type, data volume, and timestamp. Step e: Analyze the communication behavior between devices in real time, perform anomaly detection in combination with the traceability diagram, and predict potential failures or abnormal events of the device based on the communication behavior.

2. The method for constructing a device traceability graph based on real-time analysis of communication requests according to claim 1 is characterized in that: In step a, the communication protocol type is identified by parsing the header features, protocol fields or custom identifiers of the data packet, supporting automatic identification and processing of multiple communication protocols.

3. The method for constructing a device traceability graph based on real-time analysis of communication requests according to claim 1, characterized in that: The data standardization format in step b adopts JSON format, including device ID, device type, protocol type, request type, data size and request timestamp, and ensures that the data of all devices can be processed according to unified standards.

4. The method for constructing a traceability graph between devices based on real-time analysis of communication requests according to claim 1, characterized in that: The device identification mapping in step c uses the device unique identifier to ensure consistency between different device protocols and update the device status information during each communication.

5. The method for constructing a device traceability graph based on real-time analysis of communication requests according to claim 1, characterized in that: The traceability graph in step d is stored and managed through a graph database. The nodes in the traceability graph represent devices. Each device node has device ID, device type, protocol type, and device status attributes. The edges represent the communication relationship between devices. The attributes of the edges include request type, data volume, and timestamp information.

6. The method for constructing a device traceability graph based on real-time analysis of communication requests according to claim 1, characterized in that: The anomaly detection module in step e is based on a graph analysis algorithm. It identifies anomalies through statistical analysis of factors such as communication frequency and data traffic, and provides fault warnings based on the device status.

7. The method for constructing a traceability graph between devices based on real-time analysis of communication requests according to claim 1, characterized in that: The fault prediction module in step e is based on the timing analysis model, uses the historical communication data of the device, and uses a machine learning algorithm to predict the type of fault that may occur in the device and automatically generates a fault warning.

8. The method for constructing a device traceability graph based on real-time analysis of communication requests according to claim 1, characterized in that: The traceability graph is updated based on event triggers. When a device initiates a communication request, the traceability graph is automatically updated to add new device nodes or update the communication edges between devices.

9. The method for constructing a traceability graph between devices based on real-time analysis of communication requests according to claim 1, characterized in that: Data storage is managed using a distributed graph database, and the data storage process includes compression, deduplication, and index optimization.

Images