A device information processing method, device and computer device based on ontology modeling

Abstract

This application relates to a method, device, and computer device for processing device information based on ontology modeling. The method includes: obtaining the device operation data, environmental monitoring data, device historical data, and device data ontology model of a target device set; standardizing the data structures of the device operation data, environmental monitoring data, and device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data; performing device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model to obtain device fault analysis data; performing data-driven risk causal analysis on the device fault analysis data to obtain a data-driven risk analysis result; and using the data-driven risk analysis result to generate risk elimination data for any device in the target device set. Using this method can effectively handle abnormal situations caused by dynamic and complex environments and device characteristics.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method, apparatus, and computer device for processing device information based on ontology modeling. Background Art

[0002] In traditional technologies, the processing of device information usually relies on rule - based or hard - coded methods to collect, store, analyze, and process device data. Specifically, real - time data of devices is obtained through sensors or device interfaces, and these data are transmitted to a central processing system through communication protocols. Then, the system classifies, filters, and analyzes the device information according to preset algorithms, and the processed information can be used for device status monitoring, performance evaluation, etc. In addition, traditional technologies also rely on manually set thresholds and conditions to trigger alarms or automatically execute operations. Therefore, traditional technologies lack flexibility and intelligence in processing device information and are difficult to effectively handle abnormal situations caused by dynamic and complex environments and device characteristics. Summary of the Invention

[0003] Based on this, it is necessary to provide a method, apparatus, computer device, computer - readable storage medium, and computer program product for processing device information based on ontology modeling that can effectively handle abnormal situations caused by dynamic and complex environments and device characteristics.

[0004] In a first aspect, this application provides a method for processing device information based on ontology modeling, including:

[0005] Obtaining device operation data, environmental monitoring data, device historical data, and a device data ontology model of a target device set;

[0006] According to the data standardization settings in the device data ontology model, standardizing the data structures of the device operation data, the environmental monitoring data, and the device historical data to obtain device operation standardized data;

[0007] According to the semantic reasoning rules in the device data ontology model, performing device fault analysis on the device operation standardized data to obtain device fault analysis data;

[0008] Performing data - driven risk causal analysis on the device fault analysis data to obtain a data - driven risk analysis result; the data - driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0009] In a second aspect, this application also provides a device for processing device information based on ontology modeling, including:

[0010] A data acquisition module, configured to acquire device operation data, environment monitoring data, device historical data, and a device data ontology model of a target device set;

[0011] A data conversion module, configured to standardize the data structures of the device operation data, the environment monitoring data, and the device historical data according to the data standardization settings in the device data ontology model, to obtain device operation standardized data;

[0012] A fault analysis module, configured to perform device fault analysis on the device operation standardized data according to the semantic reasoning rules in the device data ontology model, to obtain device fault analysis data;

[0013] A risk analysis module, configured to perform data-driven risk causality analysis on the device fault analysis data, to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0014] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0015] Acquire device operation data, environment monitoring data, device historical data, and a device data ontology model of a target device set;

[0016] According to the data standardization settings in the device data ontology model, standardize the data structures of the device operation data, the environment monitoring data, and the device historical data, to obtain device operation standardized data;

[0017] According to the semantic reasoning rules in the device data ontology model, perform device fault analysis on the device operation standardized data, to obtain device fault analysis data;

[0018] Perform data-driven risk causality analysis on the device fault analysis data, to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0019] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0020] Acquire device operation data, environment monitoring data, device historical data, and a device data ontology model of a target device set;

[0021] Standardize the data structures of the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data;

[0022] Perform device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model to obtain device fault analysis data;

[0023] Perform data-driven risk causal analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0024] In a fifth aspect, the present application also provides a computer program product, including a computer program, which when executed by a processor implements the following steps:

[0025] Obtain the device operation data, environmental monitoring data, device historical data, and device data ontology model of the target device set;

[0026] Standardize the data structures of the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data;

[0027] Perform device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model to obtain device fault analysis data;

[0028] Perform data-driven risk causal analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0029] The above-mentioned device information processing method, device, computer device, storage medium, and computer program product based on ontology modeling obtain the device operation data, environmental monitoring data, device historical data, and device data ontology model of the target device set; according to the data standardization settings in the device data ontology model, standardize the data structures of the device operation data, environmental monitoring data, and device historical data to obtain device operation standardized data; according to the semantic inference rules in the device data ontology model, perform device fault analysis on the device operation standardized data to obtain device fault analysis data; perform data-driven risk causal analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0030] By introducing the device data ontology model, the device operation data, environment monitoring data, and historical data are standardized, effectively solving the heterogeneity problem of different data sources, ensuring the unity of data at the structural and semantic levels, and thus enhancing the accuracy and reliability of data fusion. The device fault analysis based on semantic reasoning rules can deeply explore the implicit associations between data, quickly locate potential fault points, and identify abnormal trends, avoiding diagnostic omissions caused by single rules or insufficient associations in traditional fault analysis. Subsequently, through data-driven risk causal analysis, a causal chain is formed between the fault phenomena and potential risks, further clarifying the key risk sources and risk propagation paths, greatly improving the accuracy and guiding value of the analysis results. The finally generated targeted risk elimination data can effectively handle abnormal situations caused by the dynamically changing complex environment and device characteristics. Furthermore, when no abnormal situation occurs, it can provide refined operation and maintenance plans for each device in the target device set, not only improving the device's fault prevention and adaptive capabilities, but also significantly reducing the impact of systemic risks on the overall device operation efficiency and business continuity, providing strong support for the management and optimization of the device's entire life cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] To more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0032] Figure 1 It is an application environment diagram of the device information processing method based on ontology modeling in an embodiment;

[0033] Figure 2 It is a schematic flowchart of the device information processing method based on ontology modeling in an embodiment;

[0034] Figure 3 It is a schematic flowchart of the method for obtaining device operation standardized data in an embodiment;

[0035] Figure 4 It is a schematic flowchart of the method for obtaining device operation attribute data in an embodiment;

[0036] Figure 5 It is a schematic flowchart of the method for obtaining device fault analysis data in an embodiment;

[0037] Figure 6 It is a schematic flowchart of the method for obtaining device fault reasoning data in an embodiment;

[0038] Figure 7Schematic flowchart of a method for obtaining data-driven risk analysis results in an embodiment;

[0039] Figure 8 Schematic flowchart of a method for obtaining risk diffusion analysis results in an embodiment;

[0040] Figure 9 Structural block diagram of a device information processing device based on ontology modeling in an embodiment;

[0041] Figure 10 Internal structure diagram of a computer device in an embodiment. Detailed implementation manners

[0042] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0043] A device information processing method based on ontology modeling provided by an embodiment of the present application can be applied to an application environment as Figure 1 shown. Among them, the terminal 102 communicates with the server 104 through a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or placed in the cloud or other network servers. The server 104 obtains the device operation data, environment monitoring data, device historical data, and device data ontology model of the target device set through the terminal 102; standardizes the data structures of the device operation data, environment monitoring data, and device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data; performs device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model to obtain device fault analysis data; performs data-driven risk causal analysis on the device fault analysis data to obtain data-driven risk analysis results; the data-driven risk analysis results are used to generate risk elimination data for any device in the target device set. Among them, the server 104 can be implemented by an independent server or a server cluster composed of multiple servers.

[0044] In an exemplary embodiment, as Figure 2 shown, a device information processing method based on ontology modeling is provided. Taking the method applied to the Figure 1 server as an example, the method includes the following steps 202 to 208. Among them:

[0045] Step 202, obtain the device operation data, environment monitoring data, device historical data, and device data ontology model of the target device set.

[0046] Among them, the target device set can be a set of all devices that need to perform data collection, monitoring, fault analysis, and risk assessment in a specific application scenario. These devices can be machines of the same type, or multiple devices operating in different environments. The composed set covers the device resources that need to be optimized and managed, aiming to improve the operation efficiency and security of the devices through data analysis.

[0047] Among them, the device operation data can be various performance data generated in real time when the device is in normal or abnormal states, including but not limited to parameters such as temperature, pressure, current, and rotation speed. These data reflect the current working state of the device.

[0048] Among them, the environmental monitoring data can be various external condition data of the environment where the device is located, including environmental factors such as air temperature and humidity, noise, vibration, and air pressure.

[0049] Among them, the device historical data can be the previous operation records, maintenance records, fault logs, and repair histories of the device since it was put into use.

[0050] Among them, the device data ontology model can be an abstract description of the device and its various related data. It aims to standardize and normalize device information by defining the structure, attributes, types, and their mutual relationships of device data.

[0051] Specifically, through the multi-source data acquisition module, the device operation data, environmental monitoring data, and device historical data of the target device set are obtained in real time or in batches respectively. The operation data includes the operation status of the device and key indicators (such as temperature, current, pressure, etc.); the environmental monitoring data covers the external conditions of the environment where the device is located (such as humidity, temperature, vibration, etc.); the historical data comes from the long-term operation records, fault logs, and maintenance records of the device. Protocol adaptation technology (such as Modbus, OPC, HTTP, etc.) is used for data acquisition to ensure compatibility with different types of devices. At the same time, the device data ontology model is introduced, which includes the structured definition of device data, data types, attribute constraints, and the knowledge expression of device functions and relationships. High-efficiency encryption protocols are used for data transmission to ensure data integrity and security, and the data is stored in a distributed database after reception to provide data support for subsequent processing.

[0052] In a specific embodiment, the source of device repair and support data is the historical data during the device usage process, generally involving four aspects of information: device information, test information, maintenance information, and fault information. The designed data table is shown in Table 1.

[0053]

[0054] By analyzing the existing equipment usage quality information, all data is defined into four basic categories: equipment information, test information, maintenance information, and failure cases.

[0055] In a specific embodiment, for the construction of the equipment data ontology model, ontology editing and knowledge acquisition software is used as the ontology modeling tool. A complete ontology consists of classes, object / data properties, and individuals. The exported ontology is saved in the OWL format. Taking equipment information as an example, the ontology modeling steps are shown as follows:

[0056] 1. Create classes: Create a root class "Equipment". Under the "Equipment" class, create subclasses: equipment model, equipment name, equipment number, equipment composition, assembly information, production information, and equipment distribution date.

[0057] 2. Define data properties: Define corresponding data properties for each class. For example: equipment model: string; equipment name: string; equipment number: string; equipment distribution date: date.

[0058] 3. Define object properties: Create object properties to represent the relationships between classes. For example: hasComponent: from "Equipment" to "Equipment Composition"; hasAssemblyInfo: from "Equipment" to "Assembly Information"; hasManufacturerInfo: from "Equipment" to "Production Information".

[0059] 4. Create classes for complex structures (such as assembly information and production information): Create classes for complex structures. For example: Assembly Information: manufacturer name: string; contact information: string. Production Information: manufacturer name: string; contact information: string.

[0060] 5. Define data properties for complex structures: Define data properties for complex structures. For example, the "manufacturer name" and "contact information" properties of the "Assembly Information" class. The "manufacturer name" and "contact information" properties of the "Production Information" class.

[0061] 6. Create individuals: Create individuals for each class. For example: "Equipment" individual: Equipment A; "Equipment Composition" individuals: Component 1, Component 2; "Assembly Information" individual: Assembly Information A; "Production Information" individual: Production Information A.

[0062] Step 204: Standardize the data structures of the device operation data, environmental monitoring data, and device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data.

[0063] Among them, the data standardization settings can be rules and processes for uniformly processing data collected from different sources and in different formats, including data cleaning, format unification, missing value filling, outlier identification, etc.

[0064] Among them, the device operation standardized data can be consistent data obtained after data standardization processing, including unified format data of various performance indicators during the operation of the device, and these data can eliminate data heterogeneity.

[0065] Specifically, in the data preprocessing stage, through the standardization settings in the device data ontology model, the collected device operation data, environmental monitoring data, and device historical data are cleaned, transformed, and unified. Cleaning includes outlier identification and elimination (such as using methods like box plots and statistical rules) and missing value filling (such as time series interpolation or mean filling); data transformation maps data fields from different sources to the standard fields defined by the ontology model; format unification normalizes numerical data to the range of 0 - 1 through normalization processing, or performs encoding transformation on categorical data (such as One - Hot Encoding). At the same time, the timestamps of the data are aligned through interpolation algorithms to ensure the temporal consistency of multi - dimensional data. The standardized data is stored in a unified data structure to generate device operation standardized data, and can dynamically support the invocation of other application modules.

[0066] Step 206: Perform device fault analysis on the device operation standardized data according to the semantic reasoning rules in the device data ontology model to obtain device fault analysis data.

[0067] Among them, the semantic reasoning rules can be a rule system established based on the device data ontology model, used to infer potential fault patterns and device behaviors from existing data through reasoning. These rules combine the working principle of the device, historical fault experience, and abnormal patterns, and can deduce possible fault causes based on the real - time data of the device, thereby realizing intelligent diagnosis of the device state.

[0068] Among them, the device fault analysis data can be the results of fault prediction and fault cause analysis obtained by analyzing the device operation data, especially in combination with the historical fault patterns, environmental factors, and current operating status of the device. It usually includes information such as quantified fault probability, fault type, and fault point location, and combines non - quantified data (such as operator reports and logs) to comprehensively evaluate the health status of the device.

[0069] Specifically, in the fault analysis phase, a rule-based inference engine is constructed through the semantic inference rules in the device data ontology model. This inference engine uses logical reasoning techniques combined with historical fault patterns to perform semantic-level analysis on the standardized device operation data. Inference rules are conditions such as "when the device temperature is too high and the pressure is abnormal, there may be a pipeline blockage", and automated judgment is achieved through a condition-action rule library. At the same time, pre-signals of abnormal patterns are identified through correlation analysis. For example, whether the current spike during device startup will cause subsequent temperature increase problems. The inference result is output as device fault analysis data, including information such as potential fault causes, fault probabilities, and similarities to historical faults, supporting subsequent risk causal analysis.

[0070] In a specific embodiment, the device fault analysis data includes the comprehensive results of quantitative data and non-quantitative data. The quantitative data may include specific values such as the temperature of the device (e.g., the temperature rises to 85°C), current (e.g., the current fluctuation exceeds 10A of the normal range), vibration frequency (e.g., the vibration amplitude reaches 1.5 times the vibration standard), etc. These data are monitored and recorded in real time by sensors. The non-quantitative data includes historical records of device faults, abnormal situations reported by operators (such as "strange noises occur when the device starts"), fault categories (such as "overload", "short circuit", or "overheat"), and related environmental factors (such as "too high room temperature" or "high humidity"). These data are collected through manual records or system logs, providing context information during device operation. By synthesizing these quantitative and non-quantitative data, fault analysis can reveal the root causes of device faults and provide strong support for subsequent risk assessment and preventive measures.

[0071] Step 208, perform data-driven risk causal analysis on the device fault analysis data to obtain a data-driven risk analysis result.

[0072] Among them, data-driven risk causal analysis can be to use advanced data mining and machine learning methods and mathematical model methods to establish a causal relationship model between device faults and potential risk factors through statistical analysis of device fault and abnormal data. By analyzing the mutual influence between different risk factors, the risk sources most likely to cause faults can be identified.

[0073] Among them, the data-driven risk analysis result can be a risk assessment report obtained through in-depth analysis of device operation, environmental monitoring, and fault data. This report usually combines quantitative results (such as risk probability, risk index) and qualitative descriptions (such as risk factors, causal relationship diagrams).

[0074] Specifically, based on the device failure analysis data, a data-driven causal analysis model is constructed, and causal graphs (Causal Graphs) or structural equation models (SEM) are used to define the causal relationship network between the failure phenomena and risk sources. Machine learning methods such as Bayesian networks or / and mathematical models of risk path analysis are used to perform probability inference on possible risk paths, and combined with the statistical characteristics of historical failure data, the key influencing factors of failures are identified. This analysis process includes causal inference, sensitivity analysis, and visualization of risk propagation paths, clarifying the contribution degrees of various risk factors and possible risk diffusion directions. For example, abnormal vibration may trigger performance degradation through the mechanical aging path, and then lead to the risk of shutdown. The results of data-driven risk analysis are presented in various different data forms, and at the same time, a specific risk chain diagram and key risk source location information are generated for each device.

[0075] In a specific embodiment, the results of data-driven risk analysis also include quantitative data and non-quantitative data. The quantitative data can show the failure probability of the device, such as "the failure occurrence probability of overheating of the device is 25%", and at the same time, a chart is presented to show the contribution degrees of various risk factors to the overall risk, such as the influence weights of temperature, vibration, load, etc. on device failures. Secondly, causal relationship diagrams (such as Bayesian networks or causal graphs) show the relationships between risk factors, such as "high temperature (temperature > 90°C) may trigger a short circuit in the circuit, further leading to the risk of shutdown", and the risk values of each node are visualized as the depth of color, with dark colors indicating high risks. The non-quantitative data is presented in text form, such as "Device A has reported overheating problems many times in the past 6 months, and the ambient temperature is relatively high", and combined with the summary of failure modes in historical data, a "device overheating risk" label and corresponding operation suggestions are generated, such as "It is recommended to strengthen the device heat dissipation measures" or "Replace overheated components in a timely manner". Through this multi-level and multi-form data fusion, the risk analysis results provide a comprehensive risk profile for decision-makers, helping to formulate precise risk control strategies.

[0076] Combined with the results of data-driven risk analysis and the device data ontology model, personalized risk elimination data is generated for each device. Through built-in optimization algorithms (such as genetic algorithms or reinforcement learning algorithms), support is provided for the formulation of risk mitigation strategies, including adjusting operating parameters (such as reducing device load), regularly replacing high-risk components, improving environmental conditions (such as enhancing heat dissipation or vibration damping measures), etc. The risk elimination data is presented in a structured and operable form, such as providing a specific maintenance guide manual or alarm reminder information for device operators, and at the same time generating an optimized device operation strategy, which is automatically pushed to the device management system to achieve precise and proactive risk management, maximizing the operating stability and service life of the device.

[0077] In the above device information processing method based on ontology modeling, device operation data, environmental monitoring data, device historical data, and the device data ontology model of the target device set are obtained; according to the data standardization settings in the device data ontology model, the data structures of the device operation data, environmental monitoring data, and device historical data are standardized to obtain standardized device operation data; according to the semantic reasoning rules in the device data ontology model, device fault analysis is performed on the standardized device operation data to obtain device fault analysis data; data-driven risk causal analysis is performed on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0078] By introducing the device data ontology model, the standardization processing of device operation data, environmental monitoring data, and historical data effectively solves the heterogeneity problem of different data sources, ensures the unity of data at the structural and semantic levels, and thus enhances the accuracy and reliability of data fusion. The device fault analysis based on semantic reasoning rules can deeply explore the implicit associations between data, quickly locate potential fault points, and identify abnormal trends, avoiding diagnostic omissions caused by single rules or insufficient associations in traditional fault analysis. Subsequently, through data-driven risk causal analysis, a causal chain is formed between the fault phenomenon and potential risks, further clarifying the key risk sources and risk propagation paths, greatly improving the accuracy and guiding value of the analysis results. The finally generated targeted risk elimination data can effectively cope with abnormal situations caused by the dynamically changing complex environment and device characteristics. Further, when no abnormal situation occurs, it can provide a refined operation and maintenance plan for each device in the target device set, not only improving the device's fault prevention and adaptive capabilities, but also significantly reducing the impact of systemic risks on the overall device operation efficiency and business continuity, providing strong support for the management and optimization of the device's entire life cycle.

[0079] In an exemplary embodiment, as Figure 3 shown, according to the data standardization settings in the device data ontology model, the data structures of the device operation data, environmental monitoring data, and device historical data are standardized to obtain standardized device operation data, including steps 302 to 306. Among them:

[0080] Step 302, according to the data standardization settings in the device data ontology model, perform attribute mapping on the device operation data, environmental monitoring data, and device historical data to obtain device operation attribute data.

[0081] Among them, attribute mapping can be a process of one-to-one correspondence between the fields in the device operation data, environmental monitoring data, and device historical data collected from different data sources and the predefined standard attributes in the device data ontology model.

[0082] Among them, the device operation attribute data can be various qualified attribute data during the device operation obtained after attribute mapping processing. These data include, but are not limited to, performance indicators such as the temperature, pressure, current, and vibration of the device, as well as the working state and load condition of the device.

[0083] Specifically, during the attribute mapping process, each field in the device operation data, environmental monitoring data, and device historical data needs to be analyzed in detail to ensure its consistency with the standard attributes in the device data ontology model. This includes identifying and calibrating information such as the type, range, and unit of the device data. For example, the "temperature" in the device operation data may contain different units (Celsius or Fahrenheit), while the ontology model stipulates a unified unit (such as Celsius). Through the unit conversion rule, ensure that all data fields match the standard attributes in the ontology model. In addition, for environmental monitoring data from different sources, such as "humidity", there may be different value ranges or data precisions. By comparing the attribute standards defined in the ontology model, map the fields of each data source to the corresponding standardized attributes, so that data from different sources have consistent attribute definitions, and the device operation attribute data is obtained.

[0084] Step 304, fill in the missing values of the device operation attribute data to obtain the device filled attribute data.

[0085] Among them, missing value filling can be a process of supplementing or filling these missing values by using certain methods when there are blank or incomplete data in the dataset.

[0086] Among them, the device filled attribute data can be the device dataset obtained after completing the missing value filling, in which all vacant or missing data fields have been completed by appropriate methods. These filled data maintain the same format and unit as the original data, and the quality of the data after filling is improved, making it more complete and reliable. Through the device filled attribute data.

[0087] Specifically, the process of filling in missing values of device operation attribute data needs to adopt different methods according to the data type and missing pattern. For time series data (such as device temperature and pressure data), interpolation methods (linear interpolation, spline interpolation, etc.) are often used to fill in missing values, which can maintain the time continuity of the data. For example, if the temperature data at a certain time point is missing, the interpolation method will use the temperature values at the previous and subsequent time points to calculate and fill in the missing value. For other non-time series data (such as device status markers or environmental data), the mean filling method, the most common value filling method, or prediction methods based on machine learning (such as the K-nearest neighbor algorithm, regression analysis, etc.) can be used to predict the missing data. These filling methods can be selected according to the data missing pattern (completely random missing, systematic missing, etc.) to ensure that the filled data does not introduce bias or distortion, and obtain the device filled attribute data.

[0088] Step 306, perform standardization rule conversion on each data information in the device filled attribute data to obtain the device operation standardized data.

[0089] Among them, the standardization rule conversion can be to eliminate the dimensional differences between different data sources or different data types of the device data, so that the data can be compared and analyzed under the same standard.

[0090] Specifically, in the stage of performing standardization rule conversion on each data information in the device filled attribute data, standardization methods will be applied to numerical data. Common methods include "Min-Max Normalization", which scales the data to the interval from 0 to 1, or "Z-score standardization" (zero-mean processing), which makes the data follow a standard normal distribution by subtracting the mean and dividing by the standard deviation. For categorical data with multiple classes of attributes, encoding methods such as One-Hot Encoding are used to convert the categorical data into binary vectors. For categorical data with multiple levels (for example, the working status of the device ranges from "normal", "warning" to "fault"), the label encoding method (Label Encoding) can be used to convert it into integer values. All these standardization conversions ensure that the device data has consistent dimensions and ranges between different sources, and obtain the device operation standardized data.

[0091] In this embodiment, by performing attribute mapping, missing value filling, and standardization rule conversion on device operation data, environmental monitoring data, and device historical data, it helps to improve the consistency and integrity of the data. Attribute mapping makes various types of data compatible and integrated by unifying the structures of different data sources, eliminating the differences between the data. Missing value filling solves the problem of missing data and avoids the analysis errors and inaccuracies caused by null values. Standardization rule conversion unifies the units and dimensions of different data, ensuring that the data can be compared and analyzed on the same scale. After being processed through these steps, the data quality is significantly improved, providing a more reliable and accurate basis for subsequent device fault diagnosis, risk analysis, and decision support.

[0092] In an exemplary embodiment, as Figure 4 shown, according to the data standardization settings in the device data ontology model, perform attribute mapping on the device operation data, environmental monitoring data, and device historical data to obtain device operation attribute data, including steps 402 to 404. Among them:

[0093] Step 402, determine the simple structure creation classes, complex structure creation classes, simple structure data attributes, complex structure data attributes, and defined object attributes in the data standardization settings.

[0094] Among them, the simple structure creation classes generally refer to simple data models composed of basic data types (such as integers, floating-point numbers, strings, etc.). These classes only contain a single data element and have no complex nesting or sub-structures. For example, temperature, pressure, device status, etc. can be classified as simple structure classes. The complex structure creation classes contain multiple attributes or more complex data relationships and are usually composed of multiple sub-classes, data fields, or nested structures. For example, the "fault record" class of a device may include multiple attributes such as fault type, fault occurrence time, and maintenance situation. Such a class is a complex structure class.

[0095] The simple structure data attributes refer to the basic data fields contained in the simple structure classes, such as the current temperature and pressure values of the device. They are directly measurable and usually exist in numerical form. The complex structure data attributes refer to the attributes that contain multiple related data fields in the complex structure classes. For example, the "fault type" and "maintenance record" in the device fault log are complex structure data attributes. These attributes usually contain multi-level detailed information and may be associated with other device or environmental data. The defined object attributes refer to the specific information related to the device defined in the device data ontology model (such as device model, location, maintenance cycle, etc.). These attributes provide detailed background and context information for subsequent data processing, analysis, and management.

[0096] Specifically, in the initial stage of data standardization setting, it is necessary to define the structure types in the data model. This includes determining the "simple structure creation class" and "complex structure creation class" and their respective attribute types. The simple structure creation class usually refers to a class that contains a single data element or basic data type (such as numerical values, strings, etc.), while the complex structure creation class may contain multiple attributes or nested data structures. Then, clarify the "simple structure data attributes" and "complex structure data attributes" included in each structure. The simple structure data attributes are usually directly available numerical data (such as temperature, pressure, etc.), while the complex structure data attributes may involve multiple sub-attributes (such as the fault type and maintenance records of the device). Finally, defining object attributes means mapping the specific information related to the device (such as device model, location, maintenance cycle, etc.) into the data structure for subsequent processing and management.

[0097] Step 404, map the device operation data, environmental monitoring data, and device historical data according to the simple structure creation class, complex structure creation class, simple structure data attributes, complex structure data attributes, and defined object attributes to obtain the device operation attribute data.

[0098] Specifically, after defining the structure classes and attributes in the data standardization setting, map the device operation data, environmental monitoring data, and device historical data to these structure classes. This process needs to divide the data into different categories through the simple structure class and complex structure class. For each field in the device operation data (such as temperature, pressure, current, etc.), map it to the corresponding data attribute in the simple structure creation class according to the nature of the data. For example, the temperature field is mapped to the "temperature attribute"; for the environmental monitoring data and device historical data. If they contain more complex associated information (such as the device's fault log and repair record), they need to be mapped to the data attributes in the complex structure creation class; this mapping ensures that all information of the device is organized according to the standard structure in the ontology model, facilitating unified processing. Finally, all the device operation data, environmental monitoring data, and device historical data will be sorted into device operation attribute data, and these data are structurally in line with the standard setting, facilitating subsequent analysis and decision-making.

[0099] In this embodiment, by determining the simple structure creation class, complex structure creation class, simple structure data attributes, complex structure data attributes, and defining object attributes in the data standardization settings, and mapping the device operation data, environmental monitoring data, and device historical data according to these settings, the structured and standardized processing of data can be effectively achieved. This process can uniformly convert data from different sources and types into data with clear attributes and structures, ensuring the consistency and operability of data in subsequent analysis. Through attribute mapping, the differences between device data are eliminated, the expression form of data becomes standardized, thereby improving the efficiency and accuracy of data processing and analysis. This standardized processing method provides a clearer and more reliable data basis for device fault prediction, risk analysis, and decision support, helping to improve the intelligent level of the system.

[0100] In an exemplary embodiment, as Figure 5 shown, according to the semantic inference rules in the device data ontology model, device fault analysis is performed on the standardized device operation data to obtain device fault analysis data, including steps 502 to 506. Among them:

[0101] Step 502, according to the standardized device operation data, determine the device data inference framework corresponding to the semantic inference rules.

[0102] Among them, the device data inference framework can be a logical structure constructed based on the device data ontology model and semantic inference rules, which provides the basis and path for data analysis in device fault analysis.

[0103] Specifically, according to the standardized device operation data, identify and select the inference framework corresponding to the semantic inference rules in the device data ontology model. Among them, the device data inference framework is a logical framework constructed based on semantic inference rules for inferring and analyzing the operating state of the device. This framework usually includes various performance indicators, fault modes, working environments of the device, and the mutual relationships between devices. When constructing the device data inference framework, the system combines the standardized device operation data (such as temperature, pressure, load, etc.) with the fault inference rules to determine the position and role of each data point in the inference framework, thereby providing a basis for subsequent fault inference. The determination of the inference framework is the core part of semantic inference, which provides the support of rules and structures for the subsequent inference analysis.

[0104] Step 504, according to the device data inference framework, perform device fault inference on the standardized device operation data to obtain device fault inference data.

[0105] Among them, device fault reasoning can be a process of analyzing the operation data of a device by applying semantic reasoning rules on the basis of a device data reasoning framework, so as to infer possible device fault types or risks.

[0106] Among them, device fault reasoning data can be the result data generated through the device fault reasoning process, usually including information such as inferred potential fault types, probabilities of fault occurrence, possible fault causes and influencing factors.

[0107] Specifically, after determining the device data reasoning framework, the system will analyze the standardized data item by item according to the preset reasoning rules of the device data reasoning framework (such as threshold judgment based on statistics, causal reasoning rules or expert knowledge base rules). For each key indicator (such as device temperature, pressure, vibration amplitude, etc.), the system will judge whether it is within the normal range according to historical data and the operating environment. If the data exceeds the normal range, the reasoning engine will trigger the corresponding fault reasoning rules. For example, if the temperature is too high and the device load is large, the system may infer the risk of an electrical fault. Further, the reasoning rules may also combine environmental data (such as humidity, air pressure, etc.) and device historical fault data to comprehensively judge the potential fault modes under multiple factors. This process usually adopts methods such as machine learning algorithms, Bayesian inference or rule engines to help the system obtain device fault reasoning data.

[0108] Step 506: Organize the device fault reasoning data according to the fault structure analysis rules of the device data ontology model to obtain device fault analysis data.

[0109] Among them, the fault structure analysis rules can be standardized rules used to classify, sort and organize the device fault reasoning data. These rules are designed to organize information such as the fault modes, fault causes, influencing factors, and fault data of the device in a structured form for subsequent analysis and decision-making. These rules usually include fault classification, priority sorting, causal relationship modeling, etc.

[0110] Specifically, according to the fault structure analysis rules in the device data ontology model, the device fault reasoning data usually includes information such as fault modes, probabilities of fault occurrence, possible fault causes and related performance data. These data need to be structurally analyzed, sorted and organized, that is, classified, sorted and associated according to the rules of the device fault model to generate clear device fault analysis data. For example, the system will classify different types of faults (such as mechanical faults, electrical faults, etc.) separately and sort them according to importance and urgency. Through the application of the fault structure analysis rules, the finally obtained device fault analysis data can provide a basis for subsequent risk assessment, maintenance decision-making and optimization measures.

[0111] In this embodiment, by determining a device data inference framework corresponding to semantic inference rules based on standardized device operation data and performing device fault inference on it, in-depth analysis of the device state and early prediction of potential faults can be achieved. This process enables the operation data of the device to be structurally analyzed through the semantic inference framework, automatically identifying potential fault patterns and abnormal conditions, providing strong support for fault warning. By applying fault structure analysis rules to organize the inference results, relevant data on device faults can be systematically presented, making fault diagnosis more accurate and efficient. This method improves the accuracy and timeliness of device fault detection, helps optimize device maintenance strategies, reduces downtime, lowers maintenance costs, and ensures the long-term stable operation of the device.

[0112] In an exemplary embodiment, as Figure 6 shown, according to the device data inference framework, device fault inference is performed on the standardized device operation data to obtain device fault inference data, including steps 602 to 606. Among them:

[0113] Step 602, use the device data inference framework to execute semantic inference rules to infer the initial device fault data and the initial device fault mode in the standardized device operation data.

[0114] Among them, the initial device fault data can be preliminary fault information deduced by the semantic inference rules from the standardized device operation data, and these data usually come from the real-time operation state of the device, such as sensor data of temperature, pressure, vibration, etc.

[0115] Among them, the initial device fault mode can be the fault type or fault state matched by the initial device fault data.

[0116] Specifically, the system selects appropriate semantic inference rules to analyze the standardized device operation data according to the setting of the semantic inference rules of the device data inference framework. These semantic inference rules may include threshold-based judgments (for example, when the device temperature exceeds 80°C, it is inferred as an overheating fault), causal relationship inferences (such as "too high vibration frequency will cause mechanical wear"), fault patterns that appear in the device historical data, and inference rules for abnormal data in the device (abnormal statistical algorithms, abnormal analysis algorithms), etc. Further, the system executes applying the semantic inference rules to the standardized device operation data based on the device data inference framework and uses the specific inference details and inference algorithms in the semantic inference rules (such as rule engines or Bayesian inferences) to obtain the initial fault data and the initial device fault mode.

[0117] Step 604, fuse the initial device fault data into the initial device fault mode to obtain device fault link data.

[0118] Among them, the device failure link data can be a data set formed by connecting the initial device failure data with the corresponding failure modes through causal relationships to form a multi-level failure propagation path.

[0119] Specifically, the system associates the preliminary failure data (such as too high temperature, abnormal pressure, etc.) with the corresponding initial device failure modes to form an associated failure data unit. For example, if a data point of "too high temperature" appears during the operation of the device, this data point may be associated with the "overheat failure mode" to form a preliminary link of "too high temperature → overheat failure mode". The system not only needs to simply pair the single failure data with the failure modes, but also needs to consider the multiple relationships between devices and failure propagation. For example, too high temperature of a certain device may first cause damage to electrical components, resulting in system shutdown, thus forming a multi-level failure link. In this way, the system integrates all the initial failure data and initial failure modes to form complete device failure link data, and ensures that the causal relationships between the links can accurately reflect the failure propagation path, providing a basis for subsequent risk analysis and decision-making.

[0120] Step 606, perform link anomaly analysis on the device failure link data to obtain device failure analysis data.

[0121] Among them, the link anomaly analysis can be to deeply analyze the data in the device failure data link, aiming to discover possible abnormal failure data or inconsistent reasoning results in the link.

[0122] Specifically, the system will review each link in the entire device failure link data to check whether the data conforms to the preset logical order. For example, the failure link of a certain device may start from "abnormal temperature", and then infer "electrical failure" through the "overheat failure mode". If the data in a certain link in the device failure link data (such as the inference of electrical failure) does not match the data in other links, the system will mark it as abnormal. In addition, the system also needs to check whether there are any omissions or errors in the data in the device failure link data, such as failure data that the device fails to record or abnormal jumps in the reasoning process. If a data point in the device failure link data is inconsistent with the normal failure propagation mode, it may mean that there are deviations in the failure reasoning rules or data missing. Through the device failure link data anomaly analysis, the system can identify the unconventional parts in the failure chain, and then adjust the reasoning rules or fill in the missing data.

[0123] When it is determined that the link is correct, perform anomaly analysis on the device failure link data. For example, the system may find that the data values of a certain failure mode in the link are abnormal, such as the temperature anomaly not matching the vibration mode, or the failure data of a certain device component (such as too low voltage) not conforming to the actual operating state. Through this anomaly analysis, the system can discover "abnormal failure data" or inconsistent data points in the link data. These abnormal data may originate from device failures, data acquisition errors, or problems with the inference model. Once abnormal data in the link is discovered, the system will mark it as device failure inference data. This data includes the abnormal data identified in the failure link, the error points in the inference process, and the potential root causes of the failure.

[0124] In this embodiment, by using the device data inference framework to execute semantic inference rules, it is possible to effectively infer the initial device failure data and failure modes from the standardized device operation data, realizing the early identification of potential device failures. Fusing the initial device failure data with the failure modes, and further constructing the device failure link data, can reveal the propagation path and causal relationship of the failure in each component or system of the device, providing systematic information for subsequent failure analysis. Performing link anomaly analysis on the device failure link data can deeply explore potential problems in the failure propagation process, identify abnormal links, and help locate the failure source and potential risk points. This series of processes helps to improve the accuracy and timeliness of device failure detection, optimize maintenance decisions, reduce unplanned downtime of the device, and improve the overall reliability and security of the system.

[0125] In an exemplary embodiment, as Figure 7 shown, perform data-driven risk causal analysis on the device failure analysis data to obtain the data-driven risk analysis result, including steps 702 to 708. Among them:

[0126] Step 702, perform risk causal analysis on the device failure analysis data to obtain the risk causal analysis result.

[0127] Among them, risk causal analysis can be a process of identifying and understanding the causal relationship between device failures or system problems. In this analysis, the system constructs a causal chain between the failure or risk factors by evaluating the device failure analysis data. Its purpose is to clarify which factors are the root causes of the failure or risk, and which factors will lead to further failures or system failures.

[0128] Among them, the risk causal analysis result can be a specific conclusion obtained after analysis, describing the causal relationship between different failure data or risk factors.

[0129] Specifically, the system extracts relevant information such as fault modes, fault roots, fault occurrence frequencies, and equipment operating environments from equipment fault analysis data, and uses statistical methods (such as regression analysis, Bayesian networks) or machine learning techniques (such as decision trees, neural networks) to establish a causal relationship model between fault data. For example, the system can deduce the main data and main causes of electrical faults based on historical data. Further, the main data and main causes of electrical faults may trigger equipment damage data and the serious consequences of equipment damage. Through this analysis, the system identifies the relationships between different fault modes, fault factors, and fault data, and evaluates the impact degree of each factor on risk, and finally generates a risk causal analysis result.

[0130] Step 704: Perform graphical conversion on the risk causal analysis result to obtain risk causal graphical data.

[0131] Among them, graphical conversion can be a process of presenting the abstract risk causal analysis result in a graphical form. Through graphical representation, complex causal relationships and risk propagation paths are transformed into intuitive charts or images, making the data easier to understand and analyze.

[0132] Among them, risk causal graphical data can be a data format that presents the risk causal analysis result in a graphical way. These data include visual charts or images of fault modes, fault data, risk factors, and their mutual relationships. Graphical data usually contains multiple nodes, each node represents an equipment fault, fault data, risk mode, or risk factor, and the connections between nodes represent the causal relationships or influence paths between different faults or risks.

[0133] Specifically, the system will convert different output data and output results of the risk causal analysis result into forms such as charts, flowcharts, or network diagrams. In this graphical process, each fault mode, equipment component, or risk factor will be used as a node in the graph, and the fault data is marked on the node (the node is usually circular or rectangular). The connections between nodes represent causal relationships or risk propagation paths. For example, a line in the graph may connect the "too high temperature" fault mode and the "overheat" fault mode, indicating that abnormal temperature will cause equipment overheating, and mutual reasoning and prediction can be carried out through the fault data on the nodes. Each node can contain specific risk values, such as the probability of fault occurrence or risk severity. In this way, the graphical risk causal diagram can help decision-makers quickly identify the key risk points in the equipment system and their mutual influence relationships, so as to optimize the decision-making process.

[0134] Step 706: Perform risk diffusion analysis on the risk causal graphical data to obtain a risk diffusion analysis result.

[0135] Among them, the risk diffusion analysis can be to simulate the process of how risk factors spread from one component to other components in a device or system, and is used to reveal how faults or risks spread through a causal chain and ultimately affect the stability of the entire system or device.

[0136] Among them, the risk diffusion analysis result can be a specific conclusion obtained based on the risk diffusion analysis process, revealing the propagation path of risk factors in the device system and its influence degree.

[0137] Specifically, the system uses risk causal visualization data to perform risk diffusion analysis and simulate how faults or risk factors spread within a device or system. The core of the risk diffusion analysis is to identify how a local fault (such as a single component fault) affects other device components or subsystems, thereby leading to a more extensive system-level fault. The system analyzes the connections and propagation paths between various risk nodes by constructing a diffusion model and evaluates how a fault may trigger a chain reaction. For example, in a complex device, the failure of a certain sensor may cause incorrect outputs of multiple system modules and ultimately lead to a complete shutdown of the device. To achieve diffusion analysis, the system usually adopts graph theory methods, combines the node and edge information of risk causal visualization data, and simulates the transfer effects between various fault modes and fault data. Through this analysis, the system can identify which fault points may become the source of diffusion risk, as well as the propagation speed and scope of fault diffusion, and obtain the risk diffusion analysis result. The diffusion analysis result provides decision-makers with a detailed view of the fault spread path, helps them identify high-risk areas, and take targeted risk prevention measures.

[0138] Step 708, perform risk control optimization on the risk diffusion analysis result to obtain a data-driven risk analysis result.

[0139] Among them, the risk control optimization can be to adjust and improve the device management and maintenance strategies to reduce the probability of device failures and the impact of risk diffusion.

[0140] Specifically, the system analyzes the data of key risk points and fault propagation paths in the risk diffusion analysis results, evaluates the effectiveness of existing control measures (such as monitoring frequency, redundancy configuration, maintenance cycle, etc.), and optimizes them. For example, if the analysis finds that a certain key component has a high risk of fault diffusion, the system may recommend increasing the monitoring frequency of this component or designing a redundant system to reduce the impact of single-point failures. At the same time, the system can also adjust the control strategy through a data-driven method based on the maintenance history and operation data of the equipment to minimize risk exposure and optimize resource allocation. The optimization process may include aspects such as adjusting the maintenance plan, increasing spare part inventory, and improving equipment design. Finally, the optimized risk control measures will be output as data-driven risk analysis results, which include adjusted risk control data and strategies, risk mitigation data, measures and their expected effects.

[0141] In this embodiment, by performing risk causal analysis on the equipment fault analysis data, the causal relationship between equipment faults and the risks they trigger can be deeply identified and understood, helping the system to predict potential risk sources and their possible consequences in advance. Converting the risk causal analysis results into an image makes complex risk data more intuitive and easier to understand, providing a clear risk view for decision-makers. Next, by performing risk diffusion analysis on the risk causal image data, the propagation process of risks in the system can be simulated, the impact on other equipment or system components can be evaluated, and then the key risk diffusion paths can be identified. Finally, based on the risk diffusion analysis results, risk control optimization can be carried out to accurately formulate effective risk management strategies, mitigate the impact of potential faults, optimize resource allocation, and improve the risk resistance ability of the system. This series of steps effectively enhances the scientific nature and forward-looking nature of risk management, helps reduce the economic losses caused by equipment faults, and improves the stability and safety of equipment and systems.

[0142] In an exemplary embodiment, as Figure 8 shown, performing risk diffusion analysis on the risk causal image data to obtain risk diffusion analysis results includes steps 802 to 808. Among them:

[0143] Step 802, analyze the node risk status information of each node in the risk causal image data to obtain the node risk analysis data of each node.

[0144] Among them, the node risk status information can be the health status or risk condition of each equipment node (such as equipment components, sensors, or risk factors) at a specific moment.

[0145] Among them, the node risk analysis data can be data obtained through multi-dimensional analysis and calculation based on the node risk status information, further evaluating the overall risk degree of the node.

[0146] Specifically, the system analyzes the risk status information of each node in the risk causal graphical data. Each node usually represents a possible failure type, failure data, failure mode, risk factor, or system component of a device, and the risk status of the node reflects the degree of risk corresponding to the node, such as the harm degree of the failure occurrence, the health status of the device, the expected lifespan, etc. The system obtains the specific risk analysis data of each node through quantitative analysis of these node states (such as failure probability based on historical data, anomaly detection of monitoring data, etc.). These data may include information such as the failure rate, risk index, stability assessment of the node, helping the system to comprehensively understand the current state and potential threats of each risk node.

[0147] Analyzing the node risk status information of each node in the risk causal graphical data, the calculation formula corresponding to the node risk analysis data of each node is

[0149] where R i (t + 1) is the risk value of node i at time t + 1; In(i) is the set of parent nodes connected to node i; P ji (t) is the dynamic risk propagation probability from node j to node i at time t; R j (t) is the risk value of node j at time t; W ji (t) is the dynamic weight from node j to node i; α is the attenuation rate; β i is the sensitivity of the node to environmental factors; d ji is the physical or logical distance between two nodes; F i (t) is the external environmental effect on node i at time t, f j (t) is the state influence factor of node j, f k (t) is the state influence factor of any parent node in the set of parent nodes connected to node i, and k is the identifier of any parent node in the set of parent nodes connected to node i.

[0150] Among them, the dynamic risk propagation probability is obtained by analyzing historical failure data and statistically analyzing the correlation of failures between different nodes. For example, analyzing the relationship between sensor failures and control signal losses in past failure events; or using statistical methods such as regression analysis and maximum likelihood estimation (MLE) to calculate the probability from historical data.

[0151] Among them, the risk value of node j at time t is usually used to quantify the operating status and failure risk of node j of a device or system module at time t. The calculation of the risk value depends on multiple factors, such as real-time monitoring data, historical failure data, device health status, and environmental factors, etc.

[0152] Among them, the dynamic weight calculates the health status of the node in real time according to the data of device sensors (such as temperature, pressure, vibration, etc.), and updates the obtained weight according to the health status. For example, if the sensor fails frequently, the weight is increased, indicating that it has a greater impact on the subsequent module.

[0153] Among them, the attenuation rate is determined by regression analysis after estimating the attenuation characteristics of risk propagation between different devices and modules through experiments or historical data.

[0154] Among them, the external environment effect uses sensors to collect environmental data and maps it to the risk value of the node; or it is determined by analyzing the impact of environmental factors on the device according to historical data or theoretical models.

[0155] Among them, the sensitivity of environmental factors is determined by the technical specifications provided by the device manufacturer to determine the sensitivity of the device to environmental changes; or it is determined based on historical data to calculate the response ability of the device to environmental factors (such as temperature, humidity, etc.).

[0156] Among them, the physical distance between two nodes is determined based on the geometric distance in space; the logical distance between two nodes is determined by the direct or indirect dependency relationship between device modules. For example, the signal transmission between sensors and controllers and actuators forms a logical dependency relationship. The logical distance reflects the intensity or degree of influence of this dependency relationship.

[0157] Among them, the state influence factor is defined by monitoring the failure rate or abnormal frequency of each node. The higher the abnormal occurrence frequency of the node, the greater its impact on other nodes.

[0158] Among them, f k (t) is the state influence factor of any parent node in the set of parent nodes connected to node i. The state influence factor is defined by monitoring the failure rate or abnormal frequency of any parent node in the set of parent nodes connected to node i.

[0159] Step 804, identify the key risk analysis data corresponding to each risk key node from the node risk analysis data of each node.

[0160] Among them, the key risk analysis data can be the risk data obtained by identifying and analyzing the nodes that are crucial to the system security and stability. These data focus on the key nodes that may trigger system-level risks or affect the system operation once a failure occurs.

[0161] Specifically, the node risk analysis data of each node in the system is screened to identify the key risk nodes in the system. Key risk nodes generally refer to those nodes that have a greater impact on the overall system security and stability. These nodes may be important links in the fault chain, or their failures may trigger major system-level problems. By sorting, evaluating, and comparing the node risk analysis data, the system identifies the most risky nodes and extracts these nodes to generate detailed node risk analysis data as the key risk analysis data.

[0162] Step 806, determine the key risk path according to each key risk analysis data.

[0163] Specifically, after identifying the key risk nodes, the system will further derive the key risk path based on these key risk analysis data. The key risk path refers to the path in the system that starts from a certain fault or risk factor, passes through a series of risk nodes, and finally affects the overall performance or security of the system. The system will analyze the causal relationships and risk propagation paths between each key risk node. For example, the system uses graph theory, causal reasoning, or network analysis algorithms to determine these paths and evaluate the potential contribution of each path to the system risk, and identify those chains that may trigger cascading failures or risk spread. If the failure of a key node affects multiple subsequent nodes, resulting in a chain reaction, then these nodes and the connections between them constitute a key risk path.

[0164] Step 808, obtain the risk diffusion analysis result according to each key risk analysis data and the key risk path.

[0165] Specifically, after determining the key risk path, the system combines the key risk analysis data and the key risk path to conduct risk diffusion analysis. The goal is to simulate and analyze how these key risk nodes and paths spread within the device or system and ultimately affect the overall stability and security of the system. Based on the previous key risk analysis data (such as the failure probability of nodes, the failure propagation speed, the system redundancy design, etc.), combined with the causal relationships of the key risk path and the mutual dependencies between devices, the system applies them to the diffusion model (such as algorithms based on graph theory, propagation models, etc.) to analyze the way of risk transfer from one node to other nodes, and calculate the speed and scope of risk diffusion. Finally, the system comprehensively considers the device redundancy design, fault tolerance mechanism, and the amplification effect of risk transfer to obtain the risk diffusion analysis result, clarify which paths and nodes are the most risky, and which areas may lead to system-level failures, so as to provide decision support for subsequent risk control and optimization measures.

[0166] In this embodiment, by analyzing the node risk status information of each node in the risk causal visualization data, the potential risk situation of each node can be comprehensively understood, which helps to identify the nodes with higher risks and their failure probabilities. Further, extracting the key risk analysis data from the node risk analysis data helps to accurately locate the key nodes that may cause system-level impacts once a failure occurs. By identifying these key nodes and their related data, the diffusion path of risks in the system can be determined, revealing how failures spread to other nodes or system parts through causal relationships. Finally, based on these key risk analysis data and risk paths, the obtained risk diffusion analysis results not only help to predict the propagation trend of risks, but also provide effective decision-making support for risk prevention and control and emergency response, improving the security and reliability of the system and reducing potential losses and failure impacts.

[0167] It should be understood that although the steps in the flowcharts involved in the above embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least some of the steps or stages in other steps or other steps.

[0168] Based on the same inventive concept, an embodiment of the present application also provides an ontology modeling-based device information processing device for implementing the above-mentioned ontology modeling-based device information processing method. The implementation solution provided by this device to solve problems is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the ontology modeling-based device information processing device provided below can refer to the limitations on an ontology modeling-based device information processing method in the above text, and will not be repeated here.

[0169] In an exemplary embodiment, as Figure 9 shown, an ontology modeling-based device information processing device is provided, including: a data acquisition module 902, a data conversion module 904, a fault analysis module 906, and a risk analysis module 908, where:

[0170] The data acquisition module 902 is used to acquire the device operation data, environmental monitoring data, device historical data, and device data ontology model of the target device set;

[0171] A data conversion module 904, configured to standardize the data structures of device operation data, environment monitoring data, and device historical data according to the data standardization settings in the device data ontology model, so as to obtain device operation standardized data;

[0172] A fault analysis module 906, configured to perform device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model, so as to obtain device fault analysis data;

[0173] A risk analysis module 908, configured to perform data-driven risk causality analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set.

[0174] In one embodiment, the data conversion module 904 is further configured to perform attribute mapping on the device operation data, environment monitoring data, and device historical data according to the data standardization settings in the device data ontology model to obtain device operation attribute data; perform missing value filling on the device operation attribute data to obtain device filled attribute data; perform standardization rule conversion on each data information in the device filled attribute data to obtain device operation standardized data.

[0175] In one embodiment, the data conversion module 904 is further configured to determine a simple structure creation class, a complex structure creation class, simple structure data attributes, complex structure data attributes, and defined object attributes in the data standardization settings; map the device operation data, environment monitoring data, and device historical data according to the simple structure creation class, complex structure creation class, simple structure data attributes, complex structure data attributes, and defined object attributes to obtain device operation attribute data.

[0176] In one embodiment, the fault analysis module 906 is further configured to determine a device data inference framework corresponding to the semantic inference rules according to the device operation standardized data; perform device fault inference on the device operation standardized data according to the device data inference framework to obtain device fault inference data; organize the device fault inference data according to the fault structured analysis rules in the device data ontology model to obtain device fault analysis data.

[0177] In one embodiment, the fault analysis module 906 is further configured to execute the semantic inference rules using the device data inference framework to infer initial device fault data and an initial device fault mode in the device operation standardized data; fuse the initial device fault data into the initial device fault mode to obtain device fault link data; perform link anomaly analysis on the device fault link data to obtain device fault inference data.

[0178] In one embodiment, the risk analysis module 908 is further configured to perform risk causality analysis on the device failure analysis data to obtain a risk causality analysis result; perform graphical conversion on the risk causality analysis result to obtain risk causality graphical data; perform risk diffusion analysis on the risk causality graphical data to obtain a risk diffusion analysis result; and perform risk control optimization on the risk diffusion analysis result to obtain a data-driven risk analysis result.

[0179] In one embodiment, the risk analysis module 908 is further configured to analyze the node risk state information of each node in the risk causality graphical data to obtain node risk analysis data for each node; identify key risk analysis data corresponding to each risk key node from the node risk analysis data of each node; determine a key risk path according to the key risk analysis data of each node; and obtain a risk diffusion analysis result according to the key risk analysis data of each node and the key risk path.

[0180] Each module in the above device for processing device information based on ontology modeling can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor of the computer device in hardware form or be independent of the processor, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above respective modules.

[0181] In an exemplary embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 10 shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store server data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, it implements a method for processing device information based on ontology modeling.

[0182] Those skilled in the art can understand, Figure 10The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have a different component layout.

[0183] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0184] In one embodiment, a computer-readable storage medium is provided, storing a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0185] In one embodiment, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in the above method embodiments.

[0186] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with relevant regulations.

[0187] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in this application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in this application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.

[0188] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0189] The above-described embodiments only represent several implementation manners of this application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of this application. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several modifications and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application should be subject to the appended claims.

Claims

1. An equipment information processing method based on ontology modeling, characterized in that The method includes: Obtaining the device operation data, environmental monitoring data, device historical data, and device data ontology model of the target device set; Standardizing the data structures of the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data; Performing device fault analysis on the device operation standardized data according to the semantic inference rules in the device data ontology model to obtain device fault analysis data; Performing data-driven risk causality analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set; The performing data-driven risk causality analysis on the device fault analysis data to obtain a data-driven risk analysis result includes: Performing risk causality analysis on the device fault analysis data to obtain a risk causality analysis result; Performing graphical conversion on the risk causality analysis result to obtain risk causality graphical data; Performing risk diffusion analysis on the risk causality graphical data to obtain a risk diffusion analysis result; Performing risk control optimization on the risk diffusion analysis result to obtain the data-driven risk analysis result; The performing risk diffusion analysis on the risk causality graphical data to obtain the risk diffusion analysis result includes: Analyzing the node risk status information of each node in the risk causality graphical data to obtain node risk analysis data for each of the nodes; Identifying key risk analysis data corresponding to each risk key node from the node risk analysis data of each of the nodes; Determining a key risk path according to each of the key risk analysis data; Obtaining the risk diffusion analysis result according to each of the key risk analysis data and the key risk path; The calculation formula for analyzing the node risk status information of each node in the risk causality graphical data to obtain node risk analysis data for each of the nodes is Among them, R i (t + 1) is the risk value of node i at time t + 1; In(i) is the set of parent nodes connected to node i; P ji (t) is the dynamic risk propagation probability from node j to node i at time t; R j (t) is the risk value of node j at time t; W ji (t) is the dynamic weight from node j to node i; α is the decay rate; β i is the sensitivity of the node to environmental factors; d ji is the physical or logical distance between two nodes; F i (t) is the external environmental impact on node i at time t, f j (t) is the state influence factor of node j, f k (t) is the state influence factor of any parent node in the set of parent nodes connected to node i, and k is the identifier of any parent node in the set of parent nodes connected to node i.

2. The method according to claim 1, characterized in that The standardizing the data structures of the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardized data includes: Performing attribute mapping on the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation attribute data; Performing missing value filling on the device operation attribute data to obtain device filled attribute data; Performing standardized rule conversion on each data information in the device filled attribute data to obtain the device operation standardized data.

3. The method according to claim 2, wherein The performing attribute mapping on the device operation data, the environmental monitoring data, and the device historical data according to the data standardization settings in the device data ontology model to obtain device operation attribute data includes: Determine the simple structure creation class, complex structure creation class, simple structure data attributes, complex structure data attributes, and defined object attributes in the data standardization settings; Map the device operation data, environment monitoring data, and device historical data according to the simple structure creation class, complex structure creation class, simple structure data attributes, complex structure data attributes, and defined object attributes to obtain the device operation attribute data.

4. The method according to claim 1, characterized in that, Based on the semantic reasoning rules in the device data ontology model, perform device fault analysis on the device operation standardization data to obtain device fault analysis data, including: Determine the device data reasoning framework corresponding to the semantic reasoning rules according to the device operation standardization data; Perform device fault reasoning on the device operation standardization data according to the device data reasoning framework to obtain device fault reasoning data; Organize the device fault reasoning data according to the fault structured analysis rules of the device data ontology model to obtain the device fault analysis data.

5. The method according to claim 4, characterized in that, The performing device fault reasoning on the device operation standardization data according to the device data reasoning framework to obtain device fault reasoning data includes: Use the device data reasoning framework to execute the semantic reasoning rules to infer the initial device fault data and initial device fault mode in the device operation standardization data; Fuse the initial device fault data into the initial device fault mode to obtain device fault link data; Perform link anomaly analysis on the device fault link data to obtain the device fault reasoning data.

6. An apparatus for processing device information based on ontology modeling, characterized in that, The device includes: A data acquisition module for acquiring the device operation data, environment monitoring data, device historical data, and device data ontology model of a target device set; A data conversion module for standardizing the data structures of the device operation data, environment monitoring data, and device historical data according to the data standardization settings in the device data ontology model to obtain device operation standardization data; A fault analysis module for performing device fault analysis on the device operation standardization data according to the semantic reasoning rules in the device data ontology model to obtain device fault analysis data; A risk analysis module for performing data-driven risk causality analysis on the device fault analysis data to obtain a data-driven risk analysis result; the data-driven risk analysis result is used to generate risk elimination data for any device in the target device set; The performing data-driven risk causality analysis on the device fault analysis data to obtain a data-driven risk analysis result includes: Perform risk causality analysis on the device fault analysis data to obtain a risk causality analysis result; Perform graphical conversion on the risk causality analysis result to obtain risk causality graphical data; Perform risk diffusion analysis on the risk causality graphical data to obtain a risk diffusion analysis result; Perform risk control optimization on the risk diffusion analysis result to obtain the data-driven risk analysis result; Performing risk diffusion analysis on the risk-cause visualized data to obtain the risk diffusion analysis result, including: Analyzing the node risk status information of each node in the risk-cause visualized data to obtain the node risk analysis data of each node; Identifying the key risk analysis data corresponding to each risk key node from the node risk analysis data of each node; Determining the key risk path according to each key risk analysis data; Obtaining the risk diffusion analysis result according to each key risk analysis data and the key risk path; The calculation formula for analyzing the node risk status information of each node in the risk-cause visualized data to obtain the node risk analysis data of each node is Among them, R i (t + 1) is the risk value of node i at time t + 1; In(i) is the set of parent nodes connected to node i; P ji (t) is the dynamic risk propagation probability from node j to node i at time t; R j (t) is the risk value of node j at time t; W ji (t) is the dynamic weight from node j to node i; α is the attenuation rate; β i is the sensitivity of the node to environmental factors; d ji is the physical or logical distance between two nodes; F i (t) is the external environmental impact on node i at time t, f j (t) is the state influence factor of node j, f k (t) is the state influence factor of any parent node in the set of parent nodes connected to node i, and k is the identifier of any parent node in the set of parent nodes connected to node i.

7. A computer device, comprising a memory and a processor, the memory storing a computer program, 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 5.

Images