Machine learning based hierarchical software protection policy generation method and system

Abstract

The application discloses a machine learning-based hierarchical software protection strategy generation method and system, relates to the field of software protection, and comprises the following steps: obtaining device software information and historical running records; completing priority division of the device software to obtain software grading results; predicting the total resource consumption of a target device and generating a resource dynamic threshold; and using a software monitoring device to monitor the target device in real time and generating a software protection strategy in combination with real-time monitoring results and the software grading results. The application can effectively realize real-time protection of hierarchical software.

Description

Technical Field

[0001] This application relates to the field of software protection, and in particular to a method and system for generating hierarchical software protection strategies based on machine learning. Background Technology

[0002] In modern industry, different types of control equipment play a crucial role in various fields and are widely used. For example, control cabinets, due to their automation, energy-saving, protection, and communication functions, are widely used in industries such as manufacturing and construction. The normal operation and functionality of these electrical devices depend on their internal software, such as PLC software and HMI software. Therefore, when the software within a control device malfunctions, it can lead to the device failing to operate properly, causing serious consequences.

[0003] Existing software protection strategies mainly include assigning different levels of operating permissions, authorizing access through hardware tokens or multi-factor authentication (MFA), and enabling encryption protocols. While these strategies can achieve the goal of protecting the internal software of control equipment to a certain extent, they cannot provide real-time protection against software anomalies caused by internal factors such as insufficient PLC memory or CPU overload. Summary of the Invention

[0004] This application provides a method and system for generating hierarchical software protection strategies based on machine learning, which addresses the problem that existing technologies struggle to provide real-time protection for control device software.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, a machine learning-based method for generating hierarchical software protection strategies is provided, the method comprising:

[0007] Obtain the target device's software information and historical operation records;

[0008] Based on the device software information, the priority of all device software within the target device is determined, and a software classification result is obtained.

[0009] When the target device starts running, the total resource consumption of the target device is dynamically predicted by combining the device software information and historical operation records and through machine learning, and a dynamic resource threshold is generated based on the total resource consumption.

[0010] Based on the dynamic threshold of the resources, the target device is monitored in real time using a software monitoring device, and a software protection strategy is generated by combining the real-time monitoring results and the software classification results. The software monitoring device is pre-set inside the target device.

[0011] Optionally, the device software information includes hierarchical software types, software interaction logs, and device manuals, and the historical operation records include historical operation indicators and historical operation cycles.

[0012] Optionally, the step of prioritizing all device software within the target device based on the device software information to obtain the software classification result includes the following steps:

[0013] Based on the device software information, the interaction relationships between all device software within the target device are analyzed;

[0014] A software topology network is constructed using the device software as software nodes and the interaction relationships as node edges between all the software nodes.

[0015] For any of the device software, the topological importance of the device software is determined based on the network attributes of the software topology network;

[0016] The importance of all the device software is evaluated using the fuzzy hierarchy method, and the fuzzy importance of the device software is obtained.

[0017] By fusing the topological importance and the fuzzy importance, the overall importance of the device software is obtained;

[0018] Based on the overall importance of all the aforementioned devices, the software is prioritized and classified to obtain the software classification result.

[0019] Optionally, determining the topological importance of all device software based on the network attributes of the software topology network includes the following steps:

[0020] The node centrality of the software node corresponding to the device software is calculated based on the software topology network.

[0021] Calculate the neighbor centrality of all neighboring nodes of the software node;

[0022] The node heterogeneity of the software node is determined by combining the node centrality and the centrality of all its neighbors.

[0023] Traverse the neighbor nodes and calculate the neighbor heterogeneity of all the neighbor nodes;

[0024] The topological importance of the device software is calculated by combining the node heterogeneity and the heterogeneity of all the neighbors and using the cross-entropy formula.

[0025] Optionally, the step of using the fuzzy hierarchy method to complete the fuzzy evaluation of the importance of all the device software and obtain the fuzzy importance of the device software includes the following steps:

[0026] A hierarchical model of the device software is constructed based on pre-acquired software industry standards. The hierarchical model includes a target layer, a criterion layer, and a sub-criterion layer.

[0027] The evaluation factor set of the device software is divided according to the hierarchical structure model;

[0028] For any of the evaluation factor sets, the importance fuzzy evaluation among the evaluation factors in the evaluation factor set is completed using the evaluation fuzzy number, and a fuzzy judgment matrix is ​​constructed based on the importance fuzzy evaluation structure.

[0029] Convert the fuzzy judgment matrix into a fuzzy consistency matrix;

[0030] Based on the fuzzy consistency matrix, the evaluation ranking of all the evaluation factors is completed. The relative weights of all the evaluation factors are determined according to the evaluation ranking results, and all the relative weights are integrated into a relative weight set.

[0031] The single-factor evaluation of the evaluation factor set is completed based on fuzzy theory, and the factor evaluation matrix is ​​obtained.

[0032] The fuzzy importance of the device software is obtained by refining the matrix product of all the relative weight sets and the factor evaluation matrix using an anti-fuzzification algorithm.

[0033] Optionally, the step of combining device software information and historical operating records and dynamically predicting the total resource consumption of the target device through machine learning includes the following steps:

[0034] Preprocess the historical operating indicators;

[0035] The historical operating indicators after time series analysis are preprocessed are used to obtain time series operating indicators.

[0036] The timing features of the timing operation indicators are extracted using a sliding window, and the operation process of the target device is divided into multiple operation stages by combining the timing features with historical operation cycles.

[0037] An initial resource prediction model is constructed based on machine learning, and the initial resource prediction model is trained using preprocessed historical operating indicators to obtain a resource prediction model.

[0038] The device software information and the pre-acquired device operation information are input into a pre-built resource prediction model, and the resource prediction model outputs the total resource consumption of the target device in each of the operation stages.

[0039] Optionally, the step of using the resource dynamic threshold as a benchmark, monitoring the target device in real time with a software monitoring device, and generating a software protection strategy by combining the real-time monitoring results and the software classification results includes the following steps:

[0040] The software monitoring device collects the comprehensive operating indicators of all the equipment software in real time.

[0041] For any of the aforementioned device software, if all of the comprehensive operating indicators are less than or equal to the resource dynamic threshold, then it is determined that the device software has no abnormal indicators.

[0042] If the duration for which the comprehensive operating index is greater than the resource dynamic threshold exceeds a preset time threshold, it is determined that the device software has an abnormal index.

[0043] When the device software exhibits abnormal indicators, a software protection strategy is generated based on the software classification results.

[0044] Optionally, when the device software exhibits abnormal indicators, generating a software protection strategy based on the software classification results includes the following steps:

[0045] Based on the software classification results, all the device software is divided into core software and non-core software.

[0046] When the core software exhibits abnormal indicators, it outputs an alarm message.

[0047] When the non-core software exhibits abnormal indicators, determine whether there is parallel logic between the non-core software and the core software based on the device software information.

[0048] If there is parallel logic between the non-core software and any of the core software, then static isolation is implemented between the non-core software and the corresponding core software.

[0049] If there is no parallel logic between the non-core software and any of the core software, then the running permissions of the non-core software are restricted.

[0050] In a second aspect, this application provides a machine-readable storage medium storing instructions that cause a machine to execute a generation method based on a machine learning-based hierarchical software protection strategy as described in the first aspect.

[0051] Thirdly, this application provides a machine learning-based hierarchical software protection strategy generation system, comprising:

[0052] The memory is configured to store instructions; and

[0053] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the machine learning-based hierarchical software protection strategy generation method of the first aspect.

[0054] The above technical solution constructs a software topology network for the target device, and calculates the topological importance of each piece of software within the target device based on this network. To more accurately describe the importance of the software, a fuzzy hierarchical method is used to calculate the fuzzy importance of each piece of software. Combining topological importance and fuzzy importance, the overall importance of the target device is obtained, and the software is prioritized based on its overall importance. This prioritized software is then used to generate different hierarchical software protection strategies, achieving precise protection for software with different priorities. Furthermore, to more accurately monitor whether the software exhibits abnormal indicators, a resource prediction model is constructed using a support vector machine to predict the total resource consumption of the software at different operating stages. Based on this total resource consumption, a more precise dynamic resource threshold is set to determine whether the software is abnormal, thus generating a hierarchical software protection strategy. In summary, this application can effectively achieve real-time monitoring and protection of hierarchical software, ensuring the normal operation of the corresponding equipment.

[0055] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0056] Figure 1 A flowchart illustrating a machine learning-based hierarchical software protection strategy generation method provided in this application embodiment;

[0057] Figure 2 A structural diagram of a hierarchical model provided in an embodiment of this application;

[0058] Figure 3 This is a flowchart illustrating a process for generating a software protection strategy based on software classification results, provided as an embodiment of this application. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0060] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0061] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0062] Figure 1 The illustration schematically shows a flowchart of a method for generating a hierarchical software protection strategy based on machine learning, according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a method for generating a hierarchical software protection strategy based on machine learning, which may include the following steps:

[0063] S101. Obtain the device software information and historical operation records of the target device.

[0064] In this embodiment, the target device refers to electrical equipment such as control cabinets and DC cabinets. The device software information includes hierarchical software types, software interaction logs, and device manuals. Hierarchical software types refer to the types of device software built into the target device, such as PLC (Programmable Logic Controller) software, HMI (Human Machine Interface) software, and embedded system software. Software interaction logs are records of requests and responses between software programs, such as the PLC sending status data to the HMI and the HMI sending control commands to the PLC, as well as data transmission records between software programs, such as the PLC sending target speed (Hz) and acceleration parameters to the frequency converter. Software interaction logs can be obtained through online monitoring using debugging software (such as Beckhoff TwinCAT or B&R Automation Studio). The device manual is the operation and maintenance guide for the target device, which includes details of the target device's communication protocols and wiring diagrams. Historical operation records include historical operating indicators and historical operating cycles. Historical operating indicators refer to data such as CPU load rate and memory usage of all device software during the target device's operation, while the historical operating cycle refers to the target device's operating time.

[0065] S102. Based on the equipment software information, complete the priority division of all equipment software within the target equipment to obtain the software classification result.

[0066] In this embodiment, the interaction relationships between all device software within the target device are first analyzed based on the software interaction logs and device manual in the device software information. The device software is treated as nodes in a topology graph, i.e., software nodes, and the interaction relationships are used as edges connecting these software nodes to construct a software topology network. The topological importance of each device software is calculated using this software topology network. Specifically, the node centrality of each software node is first calculated based on the software topology network. Then, the degree centrality of all neighboring nodes of that software node is calculated using the same method. Based on the node centrality and degree centrality, the heterogeneity of the software node is calculated using the heterogeneity formula. The neighbor heterogeneity of all neighboring nodes of that software node is calculated using the same method. Finally, the node heterogeneity and all neighbor heterogeneity are input into the cross-entropy formula to calculate the cross-entropy of the device software. Cross-entropy can measure the difference in the amount of information contained in a random variable. The cross-entropy value can be used to quantify the differences in the distribution of software nodes. The larger the cross-entropy value, the greater the difference in the distribution of software nodes, indicating that the software node is more representative and more important. The calculated cross-entropy is mapped to the interval [0, 1] and used as the topological importance of the device software corresponding to the software node.

[0067] Next, the fuzzy importance of each device software is calculated using the fuzzy hierarchical method. The fuzzy hierarchical method (FAHP) is a multi-criteria decision-making method combining fuzzy mathematics and the analytic hierarchy process (AHP), aiming to solve the difficulties in consistency testing of the judgment matrix and the discrepancy between human thinking and mathematical models in traditional AHP. Its core idea is to quantify the decision-maker's subjective judgment by introducing fuzzy numbers (such as triangular fuzzy numbers), thereby improving the scientific and rational nature of the decision. The basic steps of the fuzzy hierarchical method include: establishing a hierarchical structure model, constructing a fuzzy judgment matrix, calculating weights and performing consistency testing and comprehensive decision analysis.

[0068] Finally, a fusion algorithm can be used to combine topological importance and fuzzy importance. First, weights are assigned to topological importance and fuzzy importance respectively; for example, a weight of 0.6 is assigned to topological importance and a weight of 0.4 to fuzzy importance. After weighting, the two are weighted and fused to obtain the overall importance of each device software. Based on the overall importance, the device software is divided into multiple priority levels, resulting in a software classification result. For example, first priority, second priority, third priority, and so on.

[0069] Topology network analysis focuses on the objective structural characteristics of software networks, quantifying the dependencies between device software through indicators such as node degree and betweenness centrality. Meanwhile, FAHP, through fuzzy mathematics and expert subjective judgment, incorporates deterministic factors such as software functionality, reliability, and security. The combination of these two methods achieves a dual mapping between system structure and business logic, avoiding the one-sidedness of a single method's perspective. Furthermore, the objective importance generated by topology network analysis (topological importance) complements the subjective importance based on industry experience in FAHP (fuzzy importance), avoiding cognitive biases in purely subjective evaluations and correcting for business value dimensions that might be overlooked in purely objective analysis. In conclusion, combining topology network analysis and fuzzy hierarchical analysis to evaluate the comprehensive importance of device software yields more accurate and objective results compared to evaluations using a single method.

[0070] S103. When the target device starts running, the total resource consumption of the target device is dynamically predicted by combining the device software information and historical operation records and through machine learning, and a dynamic resource threshold is generated based on the total resource consumption.

[0071] In this embodiment, historical operating metrics include data such as CPU load rate and memory usage. Total resource consumption refers to the total CPU usage and total memory usage of all device software within the target device. First, the historical operating metrics in the historical operating records are preprocessed. Preprocessing steps include aligning timestamps, handling missing values, and normalization. Then, the temporal features of the preprocessed historical operating metrics are extracted, and the current operation process of the target device is divided into multiple operating stages based on the temporal features and historical operating cycles, such as the initial stage, stable stage, and ending stage. Next, an initial resource prediction model is constructed based on machine learning. The preprocessed historical operating metrics are divided into an initial training set and an initial validation set according to time sequence. The initial resource prediction model is then trained to obtain a trained resource prediction model. Commonly used machine learning methods include Support Vector Machines (SVM), Random Forest, and Logistic Regression. Taking Least Squares Support Vector Machine (SVM) as an example, a resource prediction model is constructed based on Least Squares Support Vector Machines. Least Squares Support Vector Machine (LSSVM) is a machine learning algorithm based on statistical learning theory. It transforms the inequality constraints in traditional Support Vector Machines (SVM) into equality constraints and solves them using the least squares method, thus simplifying the model training process and achieving higher computational efficiency. LSSVM excels in regression prediction, especially when handling nonlinear, high-dimensional, and small-sample data. Its basic idea is to map training data to a high-dimensional feature space and find an optimal linear regression model within that space to ultimately predict test data. A resource prediction model can be used to predict the total resource consumption of a target device at different operating stages. Based on the corresponding total resource consumption, a dynamic resource threshold is generated. For example, the average resource consumption of each device's software can be calculated based on the total resource consumption, and then this calculated average resource consumption can be appropriately increased to serve as the dynamic resource threshold.

[0072] A resource prediction model built using least-squares support vectors can more accurately predict the total resource consumption required by the internal software of a target device during operation. Based on this precise total resource consumption, accurate dynamic resource thresholds are set for the software, enabling timely monitoring of any abnormal indicators and real-time control of its operational status. Furthermore, when abnormal indicators are detected, different software protection strategies are designed for core and non-core software based on their priority levels, thus achieving tiered protection for the software.

[0073] S104. Based on the dynamic threshold of resources, the target device is monitored in real time using a software monitoring device, and a software protection strategy is generated by combining the real-time monitoring results and the software classification results. The software monitoring device is pre-set inside the target device.

[0074] In this embodiment, when the target device starts running, a pre-installed software monitoring device collects comprehensive operational metrics of all device software in real time. The software monitoring device includes command-line tools, such as typing `top` or installing `htop` (using `sudo apt install htop`), which display the comprehensive operational metrics of all software in real time. Third-party software, such as PRTG Network Monitor and Datadog, can also monitor the comprehensive operational metrics of the device software. These comprehensive operational metrics include CPU load rate, memory usage, and other metrics during device software operation. A dynamic resource threshold is used as a benchmark to verify whether there are any abnormal metrics in the device software. If the comprehensive operational metrics of the device software, such as CPU load rate and memory usage, are all less than or equal to the dynamic resource threshold, it can be determined that the device software has no abnormal metrics. Conversely, if the comprehensive operational metrics are greater than the dynamic resource threshold and the duration exceeds a preset time threshold, it is determined that the device software has an abnormal metric. Next, based on the software classification results, all device software is divided into core software and non-core software.

[0075] When core software exhibits abnormal indicators, an alarm message is output through a pre-installed alarm device within the target device. This is because core software typically carries the critical business logic of the target device. If abnormal conditions such as abnormal CPU consumption or memory usage occur, it may lead to interruption of the target device's control logic, device shutdown, or even cascading failures. Therefore, once core software exhibits abnormal indicators, an alarm message needs to be output immediately to remind equipment maintenance personnel to check the target device in a timely manner and to provide the equipment maintenance personnel with the name of the abnormal device software, thereby improving the efficiency of equipment maintenance personnel's work and troubleshooting the equipment abnormality in the shortest possible time.

[0076] When non-core software exhibits abnormal metrics, determine whether parallel logic exists between the non-core and core software based on device software information. If parallel logic exists, static isolation measures are required to protect the core software from interference by non-core software anomalies. If no parallel logic exists between the non-core and any core software, directly restrict the non-core software's execution permissions. Furthermore, detecting parallel logic between non-core and core software can be done by analyzing the input and output response times between the software, or by examining the communication and signal interactions between device software. High-frequency data exchange or synchronization signals between two software programs, such as the use of shared memory, message queues, or event flags, may indicate they are coordinating parallel tasks. Monitor communication lines, such as Ethernet, CAN bus, or serial ports, using protocol analysis tools to check for periodic synchronization messages. Differentiated protection for device software of different priorities can avoid wasting protection resources, reduce the impact of device software anomalies on the target device's task execution process, and achieve refined management of the target device.

[0077] In one implementation, the device software information includes hierarchical software types, software interaction logs, and device manuals, while historical operation records include historical operation indicators and historical operation cycles.

[0078] In this embodiment, the target device refers to electrical equipment such as control cabinets and DC cabinets. The device software information includes hierarchical software types, software interaction logs, and device manuals. Hierarchical software types refer to the types of device software built into the target device, such as PLC (Programmable Logic Controller) software, HMI (Human Machine Interface) software, and embedded system software. Software interaction logs are records of requests and responses between software programs, such as the PLC sending status data to the HMI and the HMI sending control commands to the PLC, as well as data transmission records between software programs, such as the PLC sending target speed (Hz) and acceleration parameters to the frequency converter. Software interaction logs can be obtained through online monitoring using debugging software (such as Beckhoff TwinCAT or B&R Automation Studio). The device manual is the operation and maintenance guide for the target device, which includes details of the target device's communication protocols and wiring diagrams. Historical operation records include historical operating indicators and historical operating cycles. Historical operating indicators refer to data such as CPU load rate and memory usage of all device software during the target device's operation, while the historical operating cycle refers to the target device's operating time.

[0079] In one implementation, prioritizing all device software within the target device based on device software information to obtain software classification results includes the following steps:

[0080] Based on the device software information, the interaction relationships between all device software within the target device are analyzed;

[0081] A software topology network is constructed by using device software as software nodes and interaction relationships as nodes between all software nodes.

[0082] For any device software, the topological importance of the device software is determined based on the network attributes of the software topology network;

[0083] The importance of all equipment software is evaluated using the fuzzy hierarchy method, and the fuzzy importance of the equipment software is obtained.

[0084] By fusing topological importance and fuzzy importance, the overall importance of the device software is obtained;

[0085] Based on the overall importance, the priority of all equipment software is determined, resulting in a software classification result.

[0086] In this embodiment, the interaction relationships between all device software within the target device are first analyzed based on the software interaction logs and device manuals in the device software information. Specifically, natural language processing technology is first used to extract the interaction relationships between device software from the software interaction logs; that is, if there are request and response records or information transmission records between device software, it indicates that there is an interaction relationship between them. Next, a pre-trained entity recognition model is used to identify software entities in the software interaction logs, such as PLC and HMI. Then, the connection relationships between device software in the device wiring diagram can be abstracted into interaction relationships. The device software in the device wiring diagram is first extracted based on entity naming rules, and the physical connections between device software are taken as the interaction relationships between them. All device software are taken as nodes in the topology graph, i.e., software nodes, and request and response records, information transmission records, and physical connection relationships are taken as edges in the topology graph, i.e., node edges. The software nodes are connected through the node edges to obtain the software topology network.

[0087] The topological importance of each device software is calculated using a software topology network. Specifically, first, the node centrality of each software node in the device software is calculated based on the software topology network. The node centrality is calculated as (node ​​degree of the software node) / (total number of software nodes in the software topology network - 1). Next, the degree centrality of all neighboring nodes of the software node is calculated using the same method, i.e., neighbor centrality. Then, the heterogeneity of the software node is calculated using the heterogeneity formula, i.e., node heterogeneity. The heterogeneity of all neighboring nodes of the software node is calculated using the same method. Finally, the node heterogeneity and the heterogeneity of all neighbors are input into the cross-entropy formula to calculate the topological importance of the device software.

[0088] Next, the fuzzy hierarchical method is used to perform fuzzy evaluation of the importance of the software devices, thereby calculating the fuzzy importance of each software device. Fuzzy Hierarchical Method (FAHP) is a multi-criteria decision-making method combining fuzzy mathematics and Analytic Hierarchy Process (AHP), aiming to solve the difficulties in consistency testing of the judgment matrix and the discrepancy between human thinking and mathematical models in traditional AHP. Its core idea is to quantify the decision-maker's subjective judgment by introducing fuzzy numbers (such as triangular fuzzy numbers), thereby improving the scientific and rational nature of the decision. The basic steps of FAHP include: establishing a hierarchical structure model; constructing a fuzzy judgment matrix; calculating weights and performing consistency testing; and comprehensive decision analysis. After completing the above basic steps of FAHP, the importance evaluation of the software devices can be completed, and the fuzzy importance of each software device can be obtained.

[0089] Finally, a weighted average method is used to fuse topological importance and fuzzy importance. First, weights are assigned to topological importance and fuzzy importance respectively; for example, a weight of 0.6 is assigned to topological importance and a weight of 0.4 to fuzzy importance. After weighting, the two are weighted and fused to obtain the comprehensive importance of each device software. Based on the comprehensive importance, the device software is divided into multiple priority levels, resulting in a software classification result. For example, first priority, second priority, third priority, and so on.

[0090] Topology network analysis focuses on the objective structural characteristics of software networks, quantifying the dependencies between device software through indicators such as node degree and betweenness centrality. Meanwhile, FAHP, through fuzzy mathematics and expert subjective judgment, incorporates deterministic factors such as software functionality, reliability, and security. The combination of these two methods achieves a dual mapping between system structure and business logic, avoiding the one-sidedness of a single method's perspective. Furthermore, the objective importance generated by topology network analysis (topological importance) complements the subjective importance based on industry experience in FAHP (fuzzy importance), avoiding cognitive biases in purely subjective evaluations and correcting for business value dimensions that might be overlooked in purely objective analysis. In conclusion, combining topology network analysis and fuzzy hierarchical analysis to evaluate the comprehensive importance of device software yields more accurate and objective results compared to evaluations using a single method.

[0091] In one implementation, determining the topological importance of all device software based on the network attributes of the software topology network includes the following steps:

[0092] The node centrality of the software nodes corresponding to the device software is calculated based on the software topology network.

[0093] Calculate the neighbor centrality of all neighboring nodes of the software node;

[0094] The node heterogeneity of software nodes is determined by combining node centrality and the centrality of all neighbors.

[0095] Traverse the neighbor nodes and calculate the neighbor heterogeneity of all neighbor nodes;

[0096] The topological importance of the device software is calculated by combining node heterogeneity and the heterogeneity of all neighbors and using the cross-entropy formula.

[0097] In this embodiment, the node centrality of each software node in the device software is first calculated based on the software topology network. Node centrality refers to the degree centrality of a node. Degree centrality is determined by calculating the number of edges directly connected to the node (i.e., "node degree"). The higher the node degree, the higher the degree centrality, indicating that the node is more critical in the network. Therefore, it is often used to reflect the direct influence of a node on other nodes through direct connections. The node centrality is calculated as (node ​​degree of the software node) / (total number of software nodes in the software topology network - 1). Next, the degree centrality of all neighboring nodes of the software node is calculated using the same method, i.e., neighbor centrality. A neighboring node refers to other software nodes that are directly connected to the software node. For example, if the software node "inverter" is directly connected to the software node "PLC", then the software node "inverter" is a neighboring node of the software node "PLC". Then, the heterogeneity of the software node is calculated using the heterogeneity formula, i.e., node heterogeneity. The heterogeneity formula is as follows:

[0098]

[0099] in, Refers to software nodes The node centrality, Neighboring nodes Neighbor centrality, This represents the total number of software nodes in the software topology network.

[0100] The heterogeneity of all neighboring nodes of the software node is calculated using the same method; this is known as neighbor heterogeneity. Finally, the node heterogeneity and the total neighbor heterogeneity are input into the cross-entropy formula to calculate the topological importance of the device software. The cross-entropy formula is as follows:

[0101]

[0102] Refers to software nodes The heterogeneity of nodes, Representing neighboring nodes It is a software node The neighboring nodes, Represents software nodes The set of neighboring nodes.

[0103] Cross-entropy can measure the difference in the amount of information contained in a random variable. The cross-entropy value can be used to quantify the differences in the distribution of software nodes. The larger the cross-entropy value, the greater the difference in the distribution of software nodes, indicating that the software node is more representative and more important. The calculated cross-entropy is mapped to the interval [0, 1] and used as the topological importance of the device software corresponding to the software node.

[0104] In one implementation, the fuzzy importance assessment of all device software is completed using the fuzzy hierarchy method to obtain the fuzzy importance of the device software, including the following steps:

[0105] A hierarchical model of the device software is constructed based on pre-acquired software industry standards. The hierarchical model includes a target layer, a criterion layer, and a sub-criterion layer.

[0106] The evaluation factor set of the equipment software is divided according to the hierarchical structure model;

[0107] For any set of evaluation factors, the importance fuzzy evaluation among the evaluation factors in the set is completed by using the evaluation fuzzy number, and a fuzzy judgment matrix is ​​constructed based on the importance fuzzy evaluation structure.

[0108] Convert the fuzzy judgment matrix into a fuzzy consistent matrix;

[0109] The evaluation ranking of all evaluation factors is completed based on the fuzzy consistency matrix. The relative weights of all evaluation factors are determined according to the evaluation ranking results, and all relative weights are integrated into a relative weight set.

[0110] Based on fuzzy theory, a single-factor evaluation of the evaluation factor set is completed, and the factor evaluation matrix is ​​obtained.

[0111] The fuzzy importance of the device software is obtained by refining the matrix product of all relative weight sets and factor evaluation matrices using an anti-fuzzification algorithm.

[0112] In this embodiment, factors for measuring the importance of device software are first determined based on pre-obtained software industry standards. These factors include software functionality, software reliability, and software security, as well as corresponding metrics (such as software computational accuracy and interface compatibility). A hierarchical model of the device software is then constructed based on these factors. Figure 2 The hierarchical model includes an objective layer, a criterion layer, and sub-criterion layers. For example, the objective layer includes software importance, and the criterion layer (first-level indicators) includes software functionality. Software reliability Software security The criteria layer (secondary indicators) includes software functionality: software calculation accuracy. and interface compatibility Software reliability: software failure rate and software fault tolerance Software security: Data encryption strength and resistance to attack Next, based on the hierarchical structure model, multiple sets of evaluation factors for the equipment software are identified. These sets of evaluation factors include... , For the first One primary indicator, For the first The first primary indicator There are two secondary indicators, among which For example, the evaluation factor set can be... , , Next, evaluation fuzzy numbers are used to compare the relative importance of each evaluation factor in each evaluation factor set pairwise, resulting in a fuzzy evaluation of the importance among the evaluation factors. Commonly used evaluation fuzzy numbers include triangular fuzzy numbers and trapezoidal fuzzy numbers. Taking triangular fuzzy numbers as an example, a mathematical tool used to represent uncertainty or fuzziness, it is usually represented by three parameters: the center, left inflection point, and right inflection point. The center refers to the estimated or expected value of the fuzzy number; the left inflection point is the lower limit of the fuzzy number, representing the minimum value of fuzziness; and the right inflection point is the upper limit of the fuzzy number, representing the maximum value of fuzziness. Using triangular fuzzy numbers, fuzzy language can be transformed into quantifiable fuzzy numbers. For example, "software failure rate" A1 is more important than "software fault tolerance" A2, and can be converted into triangular fuzzy numbers A12=(3,5,7) and A21=(1 / 7,1 / 5,1 / 3). "Data encryption strength" B1 is slightly more important than "anti-attack capability" B2, and can be converted into triangular fuzzy numbers B12=(1,3,5) and B21=(1 / 5,1 / 3,1). To facilitate subsequent calculations, the triangular fuzzy numbers can be simplified into clear numbers using methods such as the centroid method or weighted average method. After normalizing the clear number to the interval [0,1], it can be used as matrix elements to construct a fuzzy judgment matrix. The matrix used to calculate fuzzy importance must satisfy logical consistency, that is, the comparison results should not contradict each other. Therefore, it is necessary to use a conversion formula to convert the fuzzy judgment matrix into a fuzzy consistency matrix. The conversion formula is as follows:

[0113]

[0114] in, It is the first The sum of the elements of the row matrix. For the first The sum of the elements of the row matrix. It is the matrix order. It refers to the fuzzy consistency matrix The element at a given position.

[0115] For example, the fuzzy judgment matrix P is transformed into a fuzzy consistent matrix Q as follows:

[0116]

[0117]

[0118] The evaluation factors in the evaluation factor set are ranked and calculated based on the fuzzy consistency matrix, thereby calculating the relative weight of each evaluation factor. The formula for calculating relative weights is as follows:

[0119]

[0120] in, You can directly take the smallest integer value, for example, when When it is 4, It can be 2. In the above formula, This is equivalent to assigning equal basic weights to each evaluation factor. This serves as a constraint, ensuring that the calculated relative weights are within a reasonable range. This is to standardize the relative weights. The formula for calculating relative weights is constructed based on the relative importance of each evaluation factor.

[0121] After calculating the relative weights of each row of the fuzzy consistency matrix using the aforementioned formula, the relative weights are integrated into a relative weight set. Next, the numerical values ​​corresponding to the evaluation factors are converted into linguistic variables and assigned corresponding membership degrees, such as "low," "medium," and "high." Software calculation accuracy (error > 5%) is converted into the linguistic variable "software calculation accuracy: low," and software calculation accuracy (error < 1%) is converted into the linguistic variable "software calculation accuracy: high." Data encryption strength (basic encryption) is converted into the linguistic variable "data encryption strength: low." The defined membership functions are used to construct the factor evaluation matrix for each evaluation factor set. For example, the membership degree for software calculation accuracy is [0, 0.3, 0.9], corresponding to "low," "medium," and "high," respectively. Fuzzy theory refers to the theory that uses the basic concepts of fuzzy sets or continuous membership functions. After calculating the relative weight set and factor evaluation matrix for each evaluation factor set, their product is calculated to obtain the comprehensive evaluation set. Finally, the comprehensive evaluation set is refined using an anti-fuzzification algorithm to obtain a specific numerical value reflecting the importance of the equipment software, i.e., the fuzzy importance. Commonly used defuzzification algorithms include the maximum membership method, the maximum average method, the centroid method, and the median method.

[0122] In one implementation, dynamically predicting the total resource consumption of the target device by combining device software information and historical operating records and using machine learning includes the following steps:

[0123] Preprocess historical operating indicators;

[0124] Time series analysis is performed on preprocessed historical operating indicators to obtain time series operating indicators.

[0125] The timing features of the timing operation indicators are extracted using a sliding window, and the operation process of the target equipment is divided into multiple operation stages by combining the timing features and historical operation cycles.

[0126] An initial resource prediction model was constructed based on machine learning, and the initial resource prediction model was trained using preprocessed historical operating indicators to obtain the resource prediction model.

[0127] The equipment software information and the pre-acquired equipment operation information are input into the pre-built resource prediction model, and the resource prediction model outputs the total resource consumption of the target equipment in each operation stage.

[0128] In this embodiment, historical operating metrics include data such as CPU load rate and memory usage. Preprocessing steps include timestamp alignment, missing value handling, and normalization. Timestamp alignment involves aligning the timestamps of data such as CPU load rate and memory usage. Missing value handling involves filling in missing historical operating metrics using interpolation (such as linear interpolation). Normalization involves standardizing data such as CPU load rate and memory usage using methods such as Z-score to eliminate dimensional differences. Next, the historical operating metrics are arranged chronologically to obtain time-series operating metrics. A sliding window is used to extract the time-series features of these metrics within a fixed time period. These time-series features include mean, variance, and autocorrelation function, reflecting the statistical characteristics of historical operating metrics over time. Based on the time-series features and historical operating cycles, the target device's operation is divided into multiple operating stages. The historical operating cycle refers to the target device's runtime. For example, multiple consecutive time periods with small differences in the mean of operating metrics are grouped into the same operating stage. Dividing the operating stages allows for more accurate prediction of the target device's total resource consumption in different operating stages. This is because the target device consumes different amounts of resources at different stages of operation. For example, the total resource consumption is low at the start-up stage, and then gradually increases until it stabilizes as the operating time increases. Total resource consumption refers to the total CPU usage, total memory usage, etc., of all device software within the target device.

[0129] Next, an initial resource prediction model is constructed based on machine learning. The preprocessed historical operating indicators are then divided into an initial training set and an initial validation set in chronological order. The initial resource prediction model is trained to obtain a fully trained resource prediction model. Furthermore, to improve the accuracy of the resource prediction model, historical device operating information is added to the initial training and validation sets, resulting in expanded training and validation sets. This historical device operating information includes historical API request volume, historical parallel task count, and other information. Commonly used machine learning methods include Support Vector Machines (SVM), Random Forests, and Logistic Regression. Taking Least Squares Support Vector Machine (LSSVM) as an example, a resource prediction model is constructed based on LSSVM. LSSVM is a machine learning algorithm based on statistical learning theory. It transforms the inequality constraints in traditional SVM into equality constraints and solves them using the least squares method, thus simplifying the model training process and achieving higher computational efficiency. LSSVM performs exceptionally well in regression prediction, especially when dealing with nonlinear, high-dimensional, and small-sample data. The basic idea is to map training data to a high-dimensional feature space and find an optimal linear regression model within that space to ultimately predict test data. The specific construction and training steps include:

[0130] 1.1 Select the kernel function based on the data characteristics of historical operating indicators. For example, the Gaussian kernel (RBF) is suitable for nonlinear problems, and the linear kernel is suitable for high-dimensional linearly separable data. Determine the regularization coefficient of the model and initially construct the initial resource prediction model.

[0131] 1.2 Construct the objective function and constraints of the initial resource prediction model. The objective function is used to minimize the model's complexity (regularization term) and the fitting error of the training data (loss term). The objective function is as follows:

[0132]

[0133] in, This represents the direction vector of the LSSVM in the feature space, which determines the position of the classification or regression hyperplane. The classification interval for the initial resource prediction model. This is the bias term for the initial resource prediction model, used to adjust the model's output bias so that the hyperplane can adapt to the data distribution. Indicates the first training set The difference between the predicted and actual values ​​of a sample. This represents the regularization parameter of the initial resource prediction model. This represents the total number of samples in the training set.

[0134] The constraints include:

[0135]

[0136] in, Indicates the first training set The target value for each sample regression. For the training set The feature vector of each sample This represents a mapping function used to map the original input space. Mapped to a high-dimensional feature space, Represents direction vector The transpose of .

[0137] 1.3 Initialize model parameters and regularization parameters. and kernel parameters (such as the bandwidth of the RBF kernel);

[0138] 1.4 The optimization problem (minimizing the sum of squared errors) is transformed into solving a system of linear equations by using the Lagrange multiplier method. Numerical methods such as Cholesky decomposition and conjugate gradient method are used to efficiently solve the system of equations to obtain the model parameters of the initial resource prediction model, namely the bias term and Lagrange multipliers of LSSVM.

[0139] 1.5. After iteratively training the initial resource prediction model based on the training results of the training set, evaluate the resource prediction model based on the model output results. The evaluation indicators include mean squared error (MSE) and mean absolute error (MAE). Cross-validate or time-series cross-validate the model using the validation set, continuously adjust the model parameters, and iteratively optimize the model until the preset maximum number of iterations is reached to obtain the trained resource prediction model.

[0140] Furthermore, since the constructed resource prediction model requires determining kernel parameters and regularization parameters, and considering the multiple parameters involved in the resource prediction process, traditional optimization algorithms are difficult to solve quickly and accurately, are time-consuming, and are prone to getting trapped in local optima. Therefore, intelligent optimization algorithms need to be selected to solve the model. Commonly used intelligent optimization algorithms include genetic algorithms, tabu search algorithms, simulated annealing algorithms, and salps swarm optimization algorithms. Taking the salps swarm optimization algorithm as an example, the salps swarm optimization algorithm (SSA) is an intelligent optimization algorithm that simulates the chain-like group behavior of salps. Salps are invertebrates living in the deep sea, and they forage and move through a chain-like structure. In the group, the leader is responsible for guiding the entire group towards the food source, while the followers adjust their positions under the leader's guidance. This chain-like structure gives salps a strong ability for global exploration and local exploitation, and it is mainly used to solve single-objective and multi-objective optimization problems. The specific optimization method includes the following steps:

[0141] 2.1 Parameter settings, which mainly include four types of parameters: number of groups, upper and lower bounds of variables, maximum number of iterations, and number of influencing factors;

[0142] 2.2 Initialize the population: Initialize a set of candidate solutions within the search space, where each candidate solution represents a tunicate individual;

[0143] 2.3 Calculate the fitness value (objective function value) of each individual corresponding to the candidate solution, determine the current optimal solution (food source location), and set the individual with the highest fitness as the leader and the other individuals as followers;

[0144] 2.4 The leader (the first individual in the chain) updates its own position based on the location of the food source;

[0145] 2.5 Followers adjust their positions according to the leader's updated position, eventually forming a chain structure, with the leader as the first node in the chain structure;

[0146] 2.6 Recalculate the fitness value of each candidate solution after the update, and update the chain structure according to the recalculated fitness value. Repeat the above steps until the preset maximum number of iterations is reached, and output the optimal kernel parameters and regularization parameters.

[0147] After constructing the resource prediction model, the device software information and pre-acquired device operation information are input into the pre-constructed resource prediction model. The resource prediction model then outputs the total resource consumption of the target device at each operational stage. Device operation information includes API request volume, number of parallel tasks, etc. API request volume refers to the number of API calls received by the system per unit time, which can be collected by adding an interceptor at the API entry point of the target device (such as the Controller layer). The number of parallel tasks can be extracted from the real-time operating system (RTOS) configuration table or task scheduling logs.

[0148] The resource prediction model, optimized using the tunic swarm optimization algorithm, can more accurately predict the total resource consumption required by the internal software of the target device during operation. Based on this precise total resource consumption, accurate dynamic resource thresholds are set for the software, enabling timely monitoring of any abnormal indicators and real-time control of the software's operational status. Furthermore, when abnormal indicators are detected, different software protection strategies are designed for core and non-core software based on their priority levels, thus achieving tiered protection for the software.

[0149] In one implementation, the software protection strategy is generated by using a software monitoring device to monitor the target device in real time based on a dynamic resource threshold, and combining the real-time monitoring results with the software classification results. This includes the following steps:

[0150] The software monitoring device collects comprehensive operating indicators of all equipment software in real time.

[0151] For any device software, if all comprehensive operating indicators are less than or equal to the dynamic resource threshold, it is determined that the device software has no abnormal indicators.

[0152] If the duration for which the comprehensive operating index exceeds the resource dynamic threshold exceeds the preset time threshold, it is determined that the equipment software has an abnormal index.

[0153] When the device software exhibits abnormal indicators, a software protection strategy is generated based on the software classification results.

[0154] In this embodiment, when the target device starts running, a pre-installed software monitoring device collects comprehensive operational metrics of all device software in real time. The software monitoring device includes command-line tools, such as typing `top` or installing `htop` (using `sudo apt install htop`), which display the comprehensive operational metrics of all software in real time. Third-party software, such as PRTG Network Monitor and Datadog, can also monitor the comprehensive operational metrics of the device software. These comprehensive operational metrics include indicators such as CPU load rate and memory usage during device software operation.

[0155] The dynamic resource threshold is used as a benchmark to verify whether the device software has any abnormal metrics. If the overall operating metrics of the device software, such as CPU load rate and memory usage, are all less than or equal to the dynamic resource threshold, it can be determined that the device software has no abnormal metrics. Conversely, if the overall operating metrics are greater than the dynamic resource threshold and the duration exceeds a preset time threshold, it is determined that the device software has an abnormal metric. The time threshold is set according to the software classification results of the device software. Device software with the first priority has the smallest corresponding time threshold, device software with the second priority has the second smallest corresponding time threshold, and so on, with device software with the lowest priority having the largest corresponding time threshold.

[0156] When device software malfunctions, a software protection strategy is generated based on the software classification results. Specifically, all device software is first divided into core software and non-core software according to the software classification results. For example, device software with the highest and second-highest priorities can be considered core software, while other device software with the third, fourth, and so on priorities can be considered non-core software. Employing different software protection strategies for core and non-core software enables precise protection of each device's software, allowing for refined management of the target device. Prioritizing the protection of core software can also reduce the consumption of protection resources to some extent.

[0157] When core software exhibits abnormal indicators, an alarm message is output through a pre-installed alarm device within the target device. This is because core software typically carries the critical business logic of the target device. If abnormal conditions such as abnormal CPU consumption or memory usage occur, it may lead to interruption of the target device's control logic, device shutdown, or even cascading failures. Therefore, once core software exhibits abnormal indicators, an alarm message needs to be output immediately to remind equipment maintenance personnel to check the target device in a timely manner and to provide the equipment maintenance personnel with the name of the abnormal device software, thereby improving the efficiency of equipment maintenance personnel's work and troubleshooting the equipment abnormality in the shortest possible time.

[0158] When non-core software exhibits abnormal metrics, the existence of parallel logic between the non-core and core software is determined based on device software information. If parallel logic exists between the non-core and core software, static isolation measures are required. The core software is deployed in an independent container or virtual machine to achieve process isolation. A "fault circuit breaker" mechanism is set up for the non-core software (e.g., automatic restart without interfering with other processes in case of anomalies) to protect the core software from interference by non-core software anomalies. When no parallel logic exists between the non-core software and any core software, the non-core software's operating state (e.g., crash, high load) will not directly affect the core software's logic or data flow. Therefore, the non-core software's running permissions can be directly restricted, limiting its CPU, memory, disk I / O, and other resource quotas to ensure it cannot preempt core software resources and reduce resource consumption. Furthermore, the spread of anomalies from the non-core software can be prevented. For example, if the non-core software exhibits abnormal metrics due to malicious attacks caused by its own vulnerabilities, restricting its running permissions can effectively prevent attackers from laterally penetrating the core software, thereby protecting the core software. Furthermore, detecting parallel logic between non-core and core software can be achieved by analyzing the input and output response times between the software. If two device software programs respond almost instantly to the same event without significant sequential delays, it may indicate that they are processing in parallel. For example, send a trigger signal to the system and observe whether the outputs of the two device software programs change simultaneously. If there is a sequence, it may be serial; if simultaneous, it may be parallel. In addition, the existence of parallel logic can be determined by examining the communication and signal interactions between the device software programs. If there is high-frequency data exchange or synchronization signals between the two software programs, such as the use of shared memory, message queues, or event flags, it may indicate that they are coordinating parallel tasks. By monitoring communication lines, such as Ethernet, CAN bus, or serial ports, protocol analysis tools can be used to check for periodic synchronization messages. Differentiated protection for device software with different priorities can avoid wasting protection resources, reduce the impact of device software anomalies on the task execution process of the target device, and achieve refined management of the target device.

[0159] In one implementation, when the device software exhibits abnormal indicators, generating a software protection strategy based on the software classification results includes the following steps:

[0160] S201. Based on the software classification results, all equipment software is divided into core software and non-core software.

[0161] S202. When the core software exhibits abnormal indicators, an alarm message is output.

[0162] S203. When non-core software exhibits abnormal indicators, determine whether there is parallel logic between the non-core software and the core software based on the equipment software information.

[0163] S204. If there is parallel logic between non-core software and any core software, implement static isolation between the non-core software and the corresponding core software.

[0164] S205. If there is no parallel logic between non-core software and any core software, then restrict the running permissions of the non-core software.

[0165] In this embodiment, all device software is first divided into core software and non-core software based on the software classification results. For example, device software with the first priority and the second priority can be considered core software, while other device software with the third, fourth, and so on priorities can be considered non-core software. Different software protection strategies are adopted for core software and non-core software, enabling precise protection of each device software, refined management of the target device, and prioritizing the protection of core software. This also reduces the consumption of protection resources to some extent.

[0166] When core software exhibits abnormal indicators, an alarm message is output through a pre-installed alarm device within the target device. This is because core software typically carries the critical business logic of the target device. If abnormal conditions such as abnormal CPU consumption or memory usage occur, it may lead to interruption of the target device's control logic, device shutdown, or even cascading failures. Therefore, once core software exhibits abnormal indicators, an alarm message needs to be output immediately to remind equipment maintenance personnel to check the target device in a timely manner and to provide the equipment maintenance personnel with the name of the abnormal device software, thereby improving the efficiency of equipment maintenance personnel's work and troubleshooting the equipment abnormality in the shortest possible time.

[0167] When non-core software exhibits abnormal metrics, the existence of parallel logic between the non-core and core software is determined based on device software information. If parallel logic exists between the non-core and core software, static isolation measures are required. The core software is deployed in an independent container or virtual machine to achieve process isolation. A "fault circuit breaker" mechanism is set up for the non-core software (e.g., automatic restart without interfering with other processes in case of anomalies) to protect the core software from interference by non-core software anomalies. When no parallel logic exists between the non-core software and any core software, the non-core software's operating state (e.g., crash, high load) will not directly affect the core software's logic or data flow. Therefore, the non-core software's running permissions can be directly restricted, limiting its CPU, memory, disk I / O, and other resource quotas to ensure it cannot preempt core software resources and reduce resource consumption. Furthermore, the spread of anomalies from the non-core software can be prevented. For example, if the non-core software exhibits abnormal metrics due to malicious attacks caused by its own vulnerabilities, restricting its running permissions can effectively prevent attackers from laterally penetrating the core software, thereby protecting the core software. Furthermore, detecting parallel logic between non-core and core software can be achieved by analyzing the input and output response times between the software. If two device software programs respond almost instantly to the same event without significant sequential delays, it may indicate that they are processing in parallel. For example, send a trigger signal to the system and observe whether the outputs of the two device software programs change simultaneously. If there is a sequence, it may be serial; if simultaneous, it may be parallel. In addition, the existence of parallel logic can be determined by examining the communication and signal interactions between the device software programs. If there is high-frequency data exchange or synchronization signals between the two software programs, such as the use of shared memory, message queues, or event flags, it may indicate that they are coordinating parallel tasks. By monitoring communication lines, such as Ethernet, CAN bus, or serial ports, protocol analysis tools can be used to check for periodic synchronization messages. Differentiated protection for device software with different priorities can avoid wasting protection resources, reduce the impact of device software anomalies on the task execution process of the target device, and achieve refined management of the target device.

[0168] In addition to the above, in the field of modern industrial control, overcurrent protection can be incorporated into the protection dimension to achieve more comprehensive protection of equipment software. Taking the overcurrent protection of equipment software for electrical electronic devices (target equipment) such as frequency converters, servo drives, and PLC controllers as an example, a combination of hardware sampling, intelligent algorithms, and hierarchical strategies is adopted. First, at the hardware level, high-precision Hall current sensors are used to collect the equipment's operating current data in real time. After being converted into digital signals by an ADC, the data is transmitted to the main control chip of the equipment, such as the CPU module of the PLC or the DSP processor of the frequency converter, providing basic data support for software overcurrent detection. At the software level, a multi-dimensional overcurrent characteristic model needs to be established. The sliding window technique is used to perform time-series analysis on parameters such as the effective value, peak value, and harmonic components of the current. Combined with overcurrent fault cases in historical operating data, such as the current mutation waveform during motor stall, an LSTM neural network is used to train an overcurrent prediction model to predict the current trend in the next 5-10ms and identify potential overcurrent risks in advance.

[0169] Next, it is necessary to set the overcurrent dynamic threshold. Specifically, based on the equipment power topology (such as the rated current and heat dissipation parameters of the inverter's IGBT module) and real-time load characteristics, a multi-level evaluation system including "current deviation," "heat loss rate," and "fault impact factor" is constructed using a fuzzy hierarchical method. The corresponding overcurrent dynamic threshold is calculated based on the evaluation results. Furthermore, based on the overcurrent dynamic threshold and the software classification results, the equipment software is subjected to graded protection. For example, when an overcurrent is detected, i.e., the current exceeds the current dynamic threshold, the core software (such as the inverter's vector control algorithm) activates a hot standby mechanism. Through pre-calculation buffering technology, seamless switching between primary and backup control modules is achieved, ensuring uninterrupted control. Non-core software implements resource isolation, such as suspending Modbus communication tasks and limiting CPU utilization to below 10% to prevent the spread of anomalies.

[0170] The present invention also discloses a machine-readable storage medium storing instructions for causing a machine to execute the above-described machine learning-based hierarchical software protection strategy generation method.

[0171] This invention also discloses a machine learning-based hierarchical software protection strategy generation system, comprising:

[0172] The memory is configured to store instructions; and

[0173] The processor is configured to retrieve instructions from memory and, when executing instructions, to implement the aforementioned machine learning-based hierarchical software protection strategy generation method.

[0174] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0175] The memory can be an internal storage unit of a computer device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) provided on the computer device. Furthermore, the memory can be a combination of internal storage units and external storage devices of a computer device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0176] This application also provides a machine-readable storage medium storing instructions that cause a machine to execute the above-described method for generating a machine-based hierarchical software protection strategy.

[0177] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0178] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0179] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0180] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0181] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0182] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0183] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0184] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0185] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating hierarchical software protection strategies based on machine learning, characterized in that, The method includes the following steps: Obtain the device software information and historical operation records of the target device, wherein the historical operation records include historical operation indicators and historical operation cycles; Based on the device software information, the interaction relationships between all device software within the target device are analyzed; A software topology network is constructed using the device software as software nodes and the interaction relationships as node edges between all the software nodes. For any of the device software, the node centrality of the software node corresponding to the device software is calculated based on the software topology network; Calculate the neighbor centrality of all neighboring nodes of the software node; The node heterogeneity of the software node is determined by combining the node centrality and the centrality of all its neighbors. Traverse the neighbor nodes and calculate the neighbor heterogeneity of all the neighbor nodes; The topological importance of the device software is calculated by combining the node heterogeneity and the heterogeneity of all the neighbors and using the cross-entropy formula. The importance of all the device software is evaluated using the fuzzy hierarchy method, and the fuzzy importance of the device software is obtained. By fusing the topological importance and the fuzzy importance, the overall importance of the device software is obtained; Based on the overall importance of all the above, the priority of all the device software is determined, and the software classification result is obtained; When the target device starts running, the historical operating indicators are preprocessed; The historical operating indicators after time series analysis are preprocessed are used to obtain time series operating indicators. The timing features of the timing operation indicators are extracted using a sliding window, and the operation process of the target device is divided into multiple operation stages by combining the timing features with historical operation cycles. An initial resource prediction model is constructed based on machine learning, and the initial resource prediction model is trained using preprocessed historical operating indicators to obtain a resource prediction model. The device software information and the pre-acquired device operation information are input into a pre-built resource prediction model. The resource prediction model outputs the total resource consumption of the target device in each of the operation stages, and generates a dynamic resource threshold based on the total resource consumption. Based on the dynamic threshold of the resources, the target device is monitored in real time using a software monitoring device, and a software protection strategy is generated by combining the real-time monitoring results and the software classification results. The software monitoring device is pre-set inside the target device.

2. The method according to claim 1, characterized in that, The device software information includes hierarchical software types, software interaction logs, and device manuals.

3. The method according to claim 1, characterized in that, The process of using the fuzzy hierarchy method to perform fuzzy evaluation of the importance of all the device software and obtain the fuzzy importance of the device software includes the following steps: A hierarchical model of the device software is constructed based on pre-acquired software industry standards. The hierarchical model includes a target layer, a criterion layer, and a sub-criterion layer. The evaluation factor set of the device software is divided according to the hierarchical structure model; For any of the evaluation factor sets, the importance fuzzy evaluation among the evaluation factors in the evaluation factor set is completed using the evaluation fuzzy number, and a fuzzy judgment matrix is ​​constructed based on the importance fuzzy evaluation results; Convert the fuzzy judgment matrix into a fuzzy consistency matrix; Based on the fuzzy consistency matrix, the evaluation ranking of all the evaluation factors is completed. The relative weights of all the evaluation factors are determined according to the evaluation ranking results, and all the relative weights are integrated into a relative weight set. The single-factor evaluation of the evaluation factor set is completed based on fuzzy theory, and the factor evaluation matrix is ​​obtained. The fuzzy importance of the device software is obtained by refining the matrix product of all the relative weight sets and the factor evaluation matrix using an anti-fuzzification algorithm.

4. The method according to claim 1, characterized in that, The step of generating a software protection strategy based on the dynamic threshold of the resources, using a software monitoring device to monitor the target device in real time, and combining the real-time monitoring results with the software classification results includes the following steps: The software monitoring device collects the comprehensive operating indicators of all the equipment software in real time. For any of the aforementioned device software, if all of the comprehensive operating indicators are less than or equal to the resource dynamic threshold, then it is determined that the device software has no abnormal indicators. If the duration for which the comprehensive operating index is greater than the resource dynamic threshold exceeds a preset time threshold, it is determined that the device software has an abnormal index. When the device software exhibits abnormal indicators, a software protection strategy is generated based on the software classification results.

5. The method according to claim 4, characterized in that, When the device software exhibits abnormal indicators, generating a software protection strategy based on the software classification results includes the following steps: Based on the software classification results, all the device software is divided into core software and non-core software. When the core software exhibits abnormal indicators, it outputs an alarm message. When the non-core software exhibits abnormal indicators, determine whether there is parallel logic between the non-core software and the core software based on the device software information. If there is parallel logic between the non-core software and any of the core software, then static isolation is implemented between the non-core software and the corresponding core software. If there is no parallel logic between the non-core software and any of the core software, then the running permissions of the non-core software are restricted.

6. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to execute the machine-based hierarchical software protection strategy generation method according to any one of claims 1 to 5.

7. A machine learning-based hierarchical software protection strategy generation system, characterized in that, include: The memory is configured to store instructions; as well as A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the machine learning-based hierarchical software protection strategy generation method according to any one of claims 1 to 5.

Images