Detailed Description
The present application will be described in detail with reference to the accompanying drawings, and fig. 1 is a schematic flow chart of a fault diagnosis method for a parallel power supply system according to an embodiment of the present application, and the fault diagnosis method for the parallel power supply system will be described in detail.
Step S110, an example software control path sequence corresponding to an example system control software operation event sequence of the parallel power system is obtained. The example software control path sequence includes a first example software control path and a second example software control path. The first example software control path carries non-fault diagnosis knowledge points and the second example software control path carries fault diagnosis knowledge points.
In this embodiment, the server is first connected to a historical database of the parallel power supply system, and obtains an example control software operation event sequence of the parallel power supply system from the historical database, where the example control software operation event sequence is a series of states and operation instructions recorded by the control software in the past operation process of the power supply system, and the states and the control flows of the system in a specific time period are reflected by the arrangement according to a time sequence.
The server pre-processes the sequence of example control software operating events, including cleaning noise and extraneous data, to ensure accuracy and consistency of the data. The server then converts the preprocessed data into an example software control path sequence that includes two example software control paths, a first example software control path and a second example software control path.
The first exemplary software control path carries non-fault diagnosis knowledge points, namely control flow and behavior characteristics of the parallel power supply system in a normal running state. For example, it may be described how the parallel power system, upon receipt of a power-on command, gradually starts up individual components, as well as interactions and state changes between components.
The second example software control path carries fault diagnosis knowledge points, namely control flow and behavior characteristics of the power supply system when an abnormality or fault occurs. For example, it may be described how the power system triggers a fault protection mechanism, shuts down a faulty component, and sends an alarm message to maintenance personnel when it detects that a certain component is too hot.
Step S120, determining a software control flow state diagram corresponding to each of the example software control paths in the example software control path sequence, clustering according to a plurality of the software control flow state diagrams corresponding to the example software control path sequence, generating a plurality of state diagram groups, and determining a target state diagram group based on the software control flow state diagrams respectively corresponding to the plurality of state diagram groups.
In this embodiment, the server then analyzes the two example software control paths to determine their corresponding software control flow state diagrams. The software control flow state diagram is a graphical tool for describing the state of the system, and can better understand the control logic and state change of the system.
For each example software control path, the server generates a corresponding software control flow state diagram that includes a series of nodes representing different states of the system and edges representing transition relationships between the states. For example, in the state diagram of the first example software control path, one node may represent "power system on" and another node may represent "power system on" with an edge between them indicating a transition from "on" to "on" state.
Then, the server performs clustering operation according to the similarity and the difference of the software control flow state diagrams to generate a plurality of state diagram groups. The purpose of clustering is to categorize state diagrams with similar control logic and state changes into one class for subsequent analysis and processing. The server groups the software control flow state diagrams by using a clustering algorithm, and similar software control flow state diagrams are classified into one type to form different state diagram groups.
Finally, the server determines a target state diagram packet based on the software control flow state diagrams respectively corresponding to the plurality of state diagram packets. The target state diagram groupings should be representative and reflect typical control flow and behavioral characteristics of the power system under specific operating conditions. For example, if the current emphasis is on improving the diagnostic capabilities of the power system for overheat faults, the server may select a state diagram packet containing overheat fault processing logic as the target state diagram packet.
Step S130, adjusting the diagnosis knowledge points of the first example software control path corresponding to the target state diagram group to the fault diagnosis knowledge points, and generating a target example software control path sequence.
In this embodiment, after determining the target state diagram packet, the server adjusts the non-fault diagnosis knowledge points (i.e., control logic and behavior features in the normal running state) that are originally carried by the corresponding first example software control path in the target state diagram packet to be fault diagnosis knowledge points. Thus, these paths are remarked or interpreted based on the target state diagram packet (typically containing control logic associated with a particular fault) so that they can reflect the control flow and behavior characteristics of the power supply system in the fault state.
In this way, a new target example software control path sequence is generated, which includes not only the control logic of the power system in the normal operating state (provided by the second example software control path), but also indirectly the control logic and state change information in the event of a fault by adjusting the diagnostic knowledge points. Such a sequence of target example software control paths provides a richer and comprehensive data base for subsequent fault diagnosis network training.
And step S140, performing parameter learning on the initialized classification network based on the target example software control path sequence to generate a parallel power supply system fault diagnosis network.
In this embodiment, after the target example software control path sequence is generated, the server may begin training a fault diagnosis network that aims to learn how to diagnose faults in the power supply system based on the software control path.
The server first selects an appropriate deep learning framework and algorithm to construct the initial classification network. The network is then trained using the paths in the target example software control path sequence as input data and the corresponding fault diagnosis results as label data. By constantly learning and adjusting network parameters, the server will gradually increase the diagnostic capabilities of the network for power system failures.
During the training process, the server may use some optimization algorithms and regularization techniques to improve the performance and generalization ability of the network. For example, gradient descent algorithms may be used to accelerate the training process of the network and dropout techniques may be used to reduce the overfitting of the network. Meanwhile, the server divides training data and uses a cross-validation method to evaluate the performance and stability of the network.
Finally, the server generates a parallel power system fault diagnosis network which can accurately diagnose the fault type and cause of the power system according to the input software control path. In practical application, the parallel power system fault diagnosis network can be used as an important tool for power system fault diagnosis, and helps maintenance personnel to quickly and accurately locate and solve problems.
Step S150, a candidate software control path of a candidate system control software operation event is obtained, the candidate software control path is loaded to the parallel power system fault diagnosis network, a fault diagnosis result is generated, and if the fault diagnosis result reflects that the candidate software control path is the fault software control path, the candidate system control software operation event is output as the fault system control software operation event.
In this embodiment, after the fault diagnosis network is trained, the server may start to be practically applied. For example, new candidate system control software operational events may be continually acquired and corresponding candidate software control paths generated. The server then loads the candidate software control path into the fault diagnosis network to generate a fault diagnosis result.
If the fault diagnosis result shows that the candidate software control path represents a fault state, the server outputs the corresponding candidate system control software operation event as a fault system control software operation event and carries out corresponding processing. For example, an alarm may be raised to notify maintenance personnel to perform checks and repairs, or to automatically activate a backup system to ensure continued operation of the system.
If the fault diagnosis result shows that the candidate software control path does not represent any fault state, the server regards the corresponding candidate system control software operation event as a normal event and continues to monitor the operation state of the power supply system. By the mode, the server can realize real-time fault diagnosis and monitoring of the power supply system, and reliability and stability of the system are improved.
Based on the steps, the embodiment of the application remarkably improves the accuracy and efficiency of fault diagnosis of the parallel power supply system by comprehensively utilizing the example software control path sequence, the software control circulation state diagram and the deep learning technology. Specifically, first, by distinguishing and adjusting the example software control paths carrying different knowledge points, a target example software control path sequence more close to the actual fault scene is generated. And then, parameter learning is carried out on the initialized classification network by utilizing the target path sequences, and a fault diagnosis network of the parallel power supply system is successfully constructed. The parallel power supply system fault diagnosis network not only can automatically identify and distinguish system control software operation events under normal and fault states, but also can rapidly respond when faults are detected and output specific fault system control software operation events, thereby realizing early detection and accurate positioning of faults. In addition, the state diagram group is generated by clustering and the target state diagram group is determined, so that redundant information is effectively reduced, the efficiency of data processing and analysis is improved, and the real-time performance and reliability of fault diagnosis are further enhanced. Therefore, an intelligent and automatic solution is provided for fault diagnosis of the parallel power supply system, the maintenance cost is obviously reduced, and the overall operation stability and safety of the system are improved.
In one possible implementation, step S120 includes:
Step S121, determining a path vector association degree of the first and second example software control paths according to the software control flow state diagrams respectively corresponding to the first and second example software control paths.
Step S122, clustering a plurality of path vector association degrees corresponding to the exemplary software control path sequence, and generating the plurality of state diagram packets.
The method comprises the steps of determining a target state diagram group based on the corresponding path vector association degree of the state diagram groups.
In this embodiment, the server first needs to perform vectorization processing on each software control flow state diagram, that is, convert the nodes and edges in the software control flow state diagram into numerical vectors, which can be implemented by graph embedding technologies, such as Node2Vec, graph Convolutional Networks (GCN), and the like, which can map the nodes in the software control flow state diagram into a low-dimensional vector space, and retain the structural information between the nodes.
For the state diagrams of the first and second example software control paths, the server calculates vector representations thereof, respectively. The cosine similarity, euclidean distance, or other similarity measure is then used to calculate the degree of correlation between the two vectors, i.e., the path vector correlation, which reflects the degree of similarity of the two state diagrams in control logic and structure.
For example, assume that the state diagram of the first example software control path describes primarily a normal startup procedure of the power system, while the state diagram of the second example software control path describes a handling procedure of an overheat fault. The server converts the two state diagrams into vectors V1 and V2 by a graph embedding technique, and then calculates cosine similarity between V1 and V2 as their path vector relevance. Because of the significant differences in structure and control logic between the two flows, their path vector correlation will be relatively low.
Next, the server clusters all path vector associations using a clustering algorithm (e.g., K-means, DBSCAN, etc.). The clustering algorithm groups the state diagrams according to the similarity and the difference of the association degrees, so that the state diagrams in the same group have higher similarity, and the similarity between different groups is lower. During the clustering process, the server sets appropriate clustering parameters (e.g., number of clusters, distance threshold, etc.) to ensure that the clustering results are not too finely divided or too generalized. The server will calculate the degree of association of each state graph with the other state graphs and assign them to different clusters according to the degree of association.
For example, the server clusters the path vector association of all the state diagrams using the K-means algorithm, and sets the number of clusters to 3. Through iterative computation, the server finally divides the state diagrams into three groups, namely, one group containing state diagrams describing normal starting processes, one group containing state diagrams describing overheat fault processing processes, and the other group containing state diagrams describing other types of fault processing processes.
After the clustering operation is completed, the server obtains a plurality of state diagram groups, and the state diagrams in each state diagram group have similarity in control logic and structure. Next, the server needs to determine the target state diagram groupings according to the specific needs.
In detail, the server analyzes the path vector association of each state diagram group, and knows the similarity of the state diagrams in each state diagram group and the difference between the groups. By comparing the relevance profiles of the different packets, the server can initially determine which packets can contain the target state diagram.
For example, the server finds that the state diagram group describing the overheat fault processing flow has a low intra-group association degree variation (i.e., the similarity between intra-group state diagrams is high), and the association degree difference with other groups is significant, which indicates that the group may well contain the target state diagram related to the overheat fault.
Depending on the particular needs (e.g., to increase diagnostic capabilities of the overheat fault), the server may select a state diagram packet containing the associated control logic as the target state diagram packet. In this process, the server may incorporate domain knowledge, expert opinion, or historical data to assist in the determination.
For example, assuming that the current emphasis is on improving the capability of the power supply system to diagnose overheat faults, the server may select a state diagram packet containing an overheat fault processing flow as a target state diagram packet, where the state diagram in the packet details the control flow and behavior characteristics of the power supply system when overheat faults are detected, which is an important data base for subsequent fault diagnosis network training.
To ensure that the selected target state diagram groupings meet the actual requirements, the server may further verify and adjust them by communicating with domain experts, analyzing historical failure cases, or using cross-validation, etc. For example, the server compares the state diagrams in the target state diagram groupings with known overheat fault cases and finds them highly consistent in control logic and structure, indicating that the target state diagram groupings selected by the server are accurate and efficient. If a problem or deficiency is found during the verification process, the server will adjust the groupings in time or reselect the target state diagram groupings.
In another possible implementation manner, the determining the target state diagram packet based on the software control flow state diagrams respectively corresponding to the plurality of state diagram packets may further include outputting the state diagram packet including the fault software control flow state diagram in the plurality of state diagram packets as the target state diagram packet.
The step of determining the fault software control flow state diagram comprises the following steps:
Step A110, a set software control path sequence corresponding to the set system control software operation event sequence is obtained. The set software control path sequence includes a set non-faulty software control path and a set faulty software control path.
And step A120, determining a software control flow state diagram corresponding to each set software control path in the set software control path sequence.
And step A130, clustering according to a plurality of the set software control flow state diagrams corresponding to the set software control path sequence to generate a plurality of set state diagram groups.
And step A140, determining the weight of the set fault software control path corresponding to each set state diagram packet.
And step A150, outputting the set state diagram packet with the weight of the set fault software control path larger than the first threshold value as a fault state diagram packet.
And step A160, outputting the set software control flow state diagram in the fault state diagram group as the fault software control flow state diagram.
In this embodiment, the server is first connected to a configuration database or a simulation environment of the parallel power system, and obtains a series of configuration system control software operation event sequences from the configuration database or the simulation environment, where the event sequences are designed in advance and are used for simulating the operation states of the power system under specific conditions, including a normal state and a fault state. For example, the server obtains a sequence of events comprising a plurality of phases of power system start-up, steady operation, overload protection triggering, etc., which details the instructions received by the system control software, the operations performed, and the resulting state changes for each phase.
Then, the server analyzes the obtained sequence of the operation events of the setting system control software, and generates corresponding sequences of setting software control paths according to the logic relationship and the time sequence among the events, wherein the sequences of paths comprise setting non-fault software control paths (such as normal starting paths) and setting fault software control paths (such as overload protection paths).
For example, after the server analyzes the event sequence, a set non-failure software control path including "start instruction reception- > component initialization- > system steady operation", and a set failure software control path including "load increase- > overload detection- > failure source disconnection- > alarm transmission" are generated.
For each path in the set software control path sequence, the server generates corresponding software control flow state diagrams, and the state diagrams represent different states of the system and conversion relations among the states through nodes and edges.
For example, the server generates a state diagram for setting a non-faulty software control path, where the state diagram includes nodes such as "initial state", "start-up state", "steady running state", and the like, and transition edges between the nodes. Likewise, a state diagram including nodes such as "normal operation state", "overload detection state", "fault isolation state", and "alarm transmission state" is generated for setting the fault software control path.
The server clusters all the set software control flow state diagrams by using a clustering algorithm (such as K-means, DBSCAN and the like), and groups the state diagrams according to the similarity and the difference between the state diagrams. For example, the server clusters all the generated set software control flow state diagrams, and divides them into a plurality of set state diagram packets according to the types and the number of the nodes in the state diagrams and the conversion relations among the nodes, wherein the packets can include "normal operation flow packets", "fault processing flow packets", and the like.
In each set state diagram packet, the server calculates the weight of each set failed software control path. The calculation of the weights may be based on factors such as the complexity of the path, importance in fault handling, frequency of occurrence in historical fault records, and the like. For example, in the "failure processing flow packet", the server calculates weights of "overload protection path" and "short-circuit protection path". Since overload is a common type of failure in power supply systems and the operations and state transitions involved in the "overload protection path" are complex, the server gives it a high weight.
The server sets a first threshold value for screening the set state diagram packet containing the important fault handling procedure. And outputting the set state diagram packet with the weight of the set fault software control path larger than the first threshold value as a fault state diagram packet. For example, the server sets a weight threshold value of 0.8, and the weight of the overload protection path is found to be 0.9 by comparison and is larger than the threshold value. Therefore, the server outputs the set state diagram packet including the "overload protection path" as a failure state diagram packet.
Finally, the server outputs all set software control flow state diagrams in the fault state diagram group as fault software control flow state diagrams, and the state diagrams are used as important data bases for subsequent fault diagnosis network training. For example, the server outputs a software control flow state diagram corresponding to the overload protection path, and the state diagram details the control flow and behavior characteristics of the power supply system when the overload fault is detected, including key information such as state transition, operation instructions and the like.
Through the steps, the target state diagram group containing the fault software control flow state diagram is determined from the plurality of state diagram groups, and accurate and effective data support is provided for subsequent fault diagnosis network training.
In one possible implementation, step a130 includes:
and step A131, determining the set path vector association degree of the set non-fault software control path and the set fault software control path according to the set software control flow state diagrams respectively corresponding to the set non-fault software control path and the set fault software control path.
And step A132, clustering based on a plurality of set path vector association degrees corresponding to the set software control path sequence, and generating a plurality of set state diagram groups.
The method further includes outputting the sampled path vector correlations in the fault state diagram packet as set correlations. The sampled path vector correlations in the fault state diagram packet are less than the first correlations. The first degree of association is the degree of association in the fault state diagram packet other than the sample path vector degree of association.
The method comprises the steps of determining target state diagram groups based on the path vector association degrees respectively corresponding to the state diagram groups, and determining the target path vector association degrees in each state diagram group. The association degree of the target path vector in any one state diagram group is smaller than the second association degree in any one state diagram group. The second association degree in any one state diagram group is the association degree except the target path vector association degree in any one state diagram group. And outputting the state diagram group with the target path vector association degree not larger than the set association degree as the target state diagram group.
In this embodiment, the server has acquired the sequence of events for operating the set system control software and generated a corresponding sequence of set software control paths, including setting the non-faulty software control path and setting the faulty software control path. Next, the server needs to calculate the set path vector association between the set software control flow state diagrams corresponding to these paths.
The server firstly generates corresponding software control circulation state diagrams for each set software control path, and the software control circulation state diagrams represent the states of the system and the conversion relation of the states through nodes and edges.
Next, each state diagram is converted into a low-dimensional numerical vector, i.e., a vector representation of the state diagram, using diagram embedding techniques (e.g., node2Vec, graphSAGE, etc.), which can capture the structural information and key features of the state diagram.
For each pair of state diagrams of the set non-faulty software control path and the set faulty software control path, the server calculates the similarity between their corresponding vectors as the set path vector association. Common similarity measurement methods include cosine similarity, euclidean distance, and the like.
For example, assume that the server generates a set non-faulty software control path state diagram a representing a normal boot flow and a set faulty software control path state diagram B representing an overload protection flow. The server converts a and B into vectors VA and VB, respectively, by graph embedding techniques. Then, the server calculates cosine similarity between VA and VB to obtain set path vector association rAB. Because A and B differ significantly in structure and function, the value of rAB will be relatively low.
The server has calculated a plurality of set path vector association degrees, and then needs to perform clustering operation on the set software control flow state diagram according to the association degrees to generate a plurality of set state diagram groups.
In detail, the server selects an appropriate clustering algorithm (e.g., K-means, DBSCAN, etc.), and sets clustering parameters (e.g., number of clusters, distance threshold, etc.). Then, a clustering algorithm is executed with the set path vector association degree as an input. The algorithm assigns the state diagrams to different clusters according to the similarity and the difference of the association degrees. After the clustering is completed, the server obtains a plurality of set state diagram groups, and the state diagrams in each set state diagram group have higher similarity in structure and function. For example, the server uses the K-means algorithm to cluster the set path vector association, and sets the number of clusters to 3. After the clustering is completed, the server obtains three set state diagram groups, wherein, the group 1 comprises the state diagrams of normal operation flows, the group 2 comprises the state diagrams of various fault processing flows, and the group 3 can comprise the state diagrams of special cases or edge cases.
After determining the fault state diagram packet, the server needs to select a sampling path vector association degree from the fault state diagram packet as a reference for subsequent comparison, i.e. set the association degree.
In detail, the server calculates the path vector association of all state diagram pairs in the failure state diagram packet. Then, a relatively small value is selected from these path vector correlations as the sampled path vector correlation, which should be less than most other correlations in the packet to ensure its representativeness.
Analyzing, the server outputs the relevance of the sampling path vector as a set relevance for the subsequent target state diagram grouping determination process. For example, in the fault state diagram group, the server calculates the path vector association of all state diagram pairs and selects the smallest value among them as the sampled path vector association, denoted rSample, which reflects the smallest similarity between the fault process flow state diagrams, used as the set association for the subsequent comparison.
Having obtained a plurality of state diagram groupings and their corresponding path vector associations, the server now needs to determine a target state diagram grouping, i.e., a state diagram grouping that contains critical fault handling flows, from these associations.
In detail, for each state diagram packet, the server determines a target path vector association, which should be the relatively smaller of all associations within the state diagram packet, to ensure that it reflects the typical similarity between state diagrams within the state diagram packet. Then, the target path vector association degree of each state diagram group is compared with the set association degree. If the target path vector association is not greater than the set association, it is indicated that the state diagram within the state diagram packet is structurally similar to the fault process flow state diagram, possibly the target state diagram packet. Thus, the state diagram packet satisfying the condition can be output as the target state diagram packet.
For example, for the three previously obtained set state diagram groupings, the server calculates their target path vector associations, respectively. Assume that the target path vector association rTarget of packet 2 (failure process flow packet) is less than or equal to the set association rSample, while the target path vector association of packet 1 and packet 3 is greater than rSample. Thus, the server outputs packet 2 as a target state diagram packet, which is considered to contain the critical fault handling flow state diagram.
In one possible embodiment, the method further comprises:
Step B110, determining a software control node sequence corresponding to the first exemplary software control path and the second exemplary software control path respectively.
Step B120, determining a target shared software control path of the first and second example software control paths according to the software control node sequences corresponding to the first and second example software control paths, respectively.
Step B130, determining path unit values corresponding to the first exemplary software control path and the second exemplary software control path respectively.
Step B140, determining a first node association degree of the first example software control path and the second example software control path based on the path unit values respectively corresponding to the first example software control path and the second example software control path and the target shared software control path.
Step B150, determining a shared software control node of the first and second example software control paths according to the software control node sequences corresponding to the first and second example software control paths, respectively.
Step B160, determining a second node association degree of the first example software control path and the second example software control path based on the path unit values respectively corresponding to the first example software control path and the second example software control path and the shared software control node.
Step B170, determining the coding vector weights corresponding to the first and second exemplary software control paths according to the software control node sequences corresponding to the first and second exemplary software control paths, respectively.
Step B180, determining a third node association degree of the first exemplary software control path and the second exemplary software control path according to the coding vector weights respectively corresponding to the first exemplary software control path and the second exemplary software control path.
Step B190, determining a node association between the first exemplary software control path and the second exemplary software control path based on the first node association, the second node association, and the third node association.
Step S122 includes clustering a plurality of path vector associations and a plurality of node associations corresponding to the exemplary software control path sequence, to generate the plurality of state diagram packets.
In this embodiment, the server first parses the first and second exemplary software control paths, and converts the software control operation in each path into a series of software control nodes, thereby generating a corresponding sequence of software control nodes.
In detail, the server reads detailed steps of the first exemplary software control path, such as "start power- > initialize component- > steady operation", and converts these steps to a sequence of software control nodes, such as [ node 1: start power, node 2: initialize component, node 3: steady operation ]. Similarly, the server reads detailed steps of the second example software control path, such as "detect failure- > isolate failed component- > send alarm," and generates a corresponding sequence of software control nodes, such as [ node A: detect failure, node B: isolate failed component, node C: send alarm ].
The server analyzes the node sequences of the two example software control paths, finds out possible shared control flows or nodes between the two example software control paths, and forms a target shared software control path.
In detail, the server compares the two node sequences and finds that no direct node names are the same, but there may be logically similar control flows, such as "initialization component" may be implicit in the preparation before failure handling. Based on domain knowledge and expert judgment, the server assumes that the "initialization component" is a shared flow, but because of the different names, the server marks this part as logically shared, does not directly generate a shared node sequence, but is considered in subsequent association computation.
The server assigns each node a path unit value that reflects the importance or complexity of the node in the path. Then, based on the path unit value and the target shared software control path (logically), the first node association degree is calculated.
In detail, the server assigns a path unit value to each node, for example, node 1 (start power) may have a higher unit value because it is the start point of the path and critical. Because there is no direct target shared node sequence, the server calculates a hypothetical first node association based on the logical flow of the shared (e.g., the concept of an initialization component) and the path unit value, the association reflecting the similarity in logical flow between paths.
Although the direct node names may be different, the server may attempt to identify nodes that are functionally or functionally similar as shared software control nodes and calculate a second node association based on these nodes and path unit values.
In detail, the server, through domain knowledge or node description, identifies nodes that are functionally similar, such as "initialization components" and some of the ready nodes prior to failure handling may be considered shared. For the actually identified shared nodes, the server calculates a second node association degree based on path unit values of the nodes, wherein the second node association degree directly reflects importance of the shared nodes in two paths.
Next, the server generates a coded vector for each node and assigns weights according to the similarity or importance of these vectors. Then, a third node association is calculated based on the encoding vector weights.
In detail, the server generates a coded vector for each node using graph embedding techniques. Weights are assigned based on the similarity of the encoded vectors and the role of the nodes in the path. Based on the encoded vector weights, the server calculates a third node association that measures similarity between nodes from the perspective of vector space.
The server calculates a total node association of the first example software control path and the second example software control path by integrating the first node association, the second node association and the third node association. Then, clustering is performed based on the node association degrees and the path vector association degrees of the plurality of paths, and a state diagram packet is generated.
In detail, the server synthesizes three node association degrees according to a certain weight proportion (such as equal weight or adjustment according to importance), and obtains the total node association degree. Then, using the path vector association degree and the node association degree as input features, clustering all paths by using a clustering algorithm (such as K-means). After the clustering is completed, the server obtains a plurality of state diagram groups, and paths in each state diagram group have higher similarity in control logic, node similarity and overall structure.
Thus, relationships between the example software control paths can be analyzed more carefully, providing more accurate data packets for subsequent failure diagnosis network training.
In one possible embodiment, the method further comprises:
step C110, configuring a first setting execution instance corresponding to the software control node sequence in the example software control path. The first setting execution example comprises the steps of editing the software control node of the assignment class operation code into a first coding vector, editing the software control node of the judgment class operation code into a second coding vector, and editing the software control node of the circulation class operation code into a third coding vector.
The determining a software control flow state diagram corresponding to each of the example software control paths in the sequence of the example software control paths includes:
And converting each example software control path in the example software control path sequence into a first software control flow state diagram according to the first setting execution example.
And determining the software control circulation state diagram corresponding to each example software control path according to the first software control circulation state diagram corresponding to each example software control path.
In this embodiment, when the server processes the example software control path, it first needs to configure an execution instance to convert the software control nodes in the example software control path into different code vectors according to the type of the operation code, and this conversion facilitates the subsequent generation of the structured software control flow state diagram.
In detail, the server defines rules for the first set of execution instances that specify how the software control nodes for different types of opcodes should be converted into encoded vectors. Specifically, the rules include:
the software control node that assigns class opcodes (e.g., variable assignments, parameter settings, etc.) is compiled into a first encoded vector.
The software control node that determines the class opcode (e.g., conditional determination, branch selection, etc.) is compiled into a second encoded vector.
The software control node of the loop-like opcode (e.g., loop start, loop end, operation within the loop, etc.) is compiled into a third encoded vector.
Next, a specific coding scheme is defined for each type of coded vector, which may involve assigning a unique identifier to each opcode and defining the length, structure, etc. of the coded vector. For example, the first code vector may be a fixed length vector including fields indicating assignment type, assignment target, assignment value, etc., the second code vector may include fields for conditional expressions, branch selection, etc., and the third code vector may include fields for loop type, loop counter, critical operations within the loop, etc.
After the first set execution instance is configured, the server begins to transform each path in the sequence of example software control paths into a corresponding software control flow state diagram, which is divided into two main steps, namely, transforming the path into the first software control flow state diagram first, and then determining a final software control flow state diagram based on the preliminary state diagram.
In detail, the server reads a first example software control path in the sequence of example software control paths. Then, each software control node in the example software control path is traversed, and the node is converted into a corresponding code vector according to the operation code type (assignment class, judgment class, loop class) of the node and the rule of the first set execution instance. The coding vectors are used as nodes, and a preliminary software control circulation state diagram, namely a first software control circulation state diagram, is constructed according to the execution sequence and logic relation (such as sequence execution, conditional branching, loop iteration and the like) of the nodes in the path, wherein the state diagram takes the coding vectors as the nodes, and the directional edges among the nodes represent the execution sequence and the logic relation.
The first software control flow state diagram is then optimized and sorted, which may include removing redundant nodes, merging similar nodes, adjusting the direction of edges, etc., to ensure that the state diagram reflects the control logic of the path both succinctly and accurately. The server may also add additional labels or attributes to the nodes and edges in the state diagram, such as opcode names, execution conditions, number of loops, etc., as needed for use in subsequent analysis. Finally, the server determines the optimized state diagram as a software control flow state diagram corresponding to the example software control path, and stores the software control flow state diagram in a database for subsequent use.
Through the process, the example software control path can be converted into a structured software control flow state diagram, and powerful data support is provided for subsequent fault diagnosis network training.
In one possible embodiment, the method further comprises:
And step C120, configuring a second setting execution instance corresponding to the software control node sequence. The second setting execution example is an execution space of a configuration setting length. The set length corresponds to a set number of unit slots, and the set number of unit slots comprises a plurality of first unit slots and a plurality of second unit slots. Each first unit slot corresponds to an assignment type operation code, and the coding vector in each first unit slot is used for reflecting whether the assignment type operation code corresponding to each first unit slot exists in the software control node sequence. Each second unit slot corresponds to a non-assignment type operation code software control node. The non-assignment class operation codes include a judgment class operation code and a loop class operation code. The coding vector in each second unit slot is used for reflecting whether the non-assignment type operation code corresponding to each second unit slot exists in the software control node sequence.
The determining, according to the first software control flow state diagrams corresponding to the respective example software control paths, the software control flow state diagrams corresponding to the respective example software control paths includes:
And respectively converting each example software control path into a second software control flow state diagram according to the second setting execution example.
And determining the software control circulation state diagram corresponding to each example software control path according to the first software control circulation state diagram and the second software control circulation state diagram corresponding to each example software control path.
In this embodiment, when the software control node sequence is further processed, the server configures a second set execution instance, where the second set execution instance defines an execution space with a set length, and is used to efficiently represent and query the operation code types in the node sequence, where the execution space is divided into a plurality of unit slots, each slot corresponds to a different type of operation code, and whether the operation code of the corresponding type exists in the node sequence is marked by a coding vector.
In detail, the set length of the execution space and the unit slot allocation are first determined. The server presets a reasonable execution space length according to historical data and domain knowledge, and the length is enough to cover the requirements of most software control node sequences. The server then divides the execution space into a plurality of unit slots, including a plurality of first unit slots (corresponding to assigned class opcodes) and a plurality of second unit slots (corresponding to non-assigned class opcodes, such as decision class and loop class opcodes).
Next, a coding vector is configured for each unit slot. For each first unit slot, the server defines a coded vector, each element (or bit) in the vector corresponding to a particular assignment class opcode. If the opcode exists in the node sequence, the corresponding element is set to a particular value (e.g., 1), otherwise it is another value (e.g., 0). Similarly, for each second unit slot, the server also defines a coding vector to mark the presence of non-assigned class opcodes.
The rules and coding schemes of the second set execution instance are then stored in an internal database so as to be directly callable when processing the specific example software control path.
After the second set of execution instances is configured, the server begins to utilize the second set of execution instances to further transform the example software control path to generate a more refined software control flow state diagram that combines the previously generated first and second software control flow state diagrams.
The server reads an example software control path and traverses a sequence of software control nodes therein. For each node in the software control node sequence, the server finds a corresponding unit slot in the execution space of the second set execution instance according to the operation code type (assignment type, judgment type, circulation type). The server updates the encoding vector in the unit slot to set the corresponding element to a value indicating the presence of the opcode. The server constructs a second software control flow state diagram by traversing the whole node sequence and updating the coding vectors in the execution space, and the state diagram intuitively displays the existence and distribution condition of the operation codes in the node sequence based on unit slots and the coding vectors.
The server has generated a first software control flow state diagram and a second software control flow state diagram for each of the example software control paths. The first state diagram focuses on the execution order and logical relationships of the nodes, while the second state diagram focuses on the existence and distribution of the opcodes.
The server merges the two state diagrams. During the merging process, the server may keep the nodes and edges in the first state diagram as the main skeleton of the state diagram, and add the encoded vector information in the second state diagram as additional attributes to the corresponding nodes or edges.
After the combination is completed, the server obtains a more complete and refined software control circulation state diagram, and the software control circulation state diagram not only comprises the execution sequence and the logic relation of the nodes, but also clearly displays the existence and the distribution condition of the operation codes through the coding vector, thereby providing more abundant information for subsequent analysis and processing.
In one possible embodiment, the method further comprises:
And step C130, configuring a third setting execution instance corresponding to the software control node sequence. The third set execution instance includes dividing the sequence of software control nodes into two sub-sequences of software control nodes according to a target software control node in the sequence of software control nodes. And respectively converting the two software control node subsequences into software control flow state subgraphs according to the first setting execution example.
And C140, determining weighted calculation results of the two software control flow state subgraphs, and generating a software control flow state diagram.
The determining, according to the first software control flow state diagram and the second software control flow state diagram corresponding to the respective example software control paths, the software control flow state diagram corresponding to the respective example software control paths includes:
And respectively converting each example software control path into a third software control flow state diagram according to the third setting execution example.
And determining the software control circulation state diagram corresponding to each example software control path according to the first software control circulation state diagram, the second software control circulation state diagram and the third software control circulation state diagram corresponding to each example software control path.
In this embodiment, to analyze the structure and characteristics of the software control node sequence more deeply, the server is configured with a third setting execution instance that allows the server to divide the node sequence into two sub-sequences according to a specific target software control node, and convert the two sub-sequences into software control flow state subgraphs, respectively. Finally, the two subgraphs are calculated through weighting, and a comprehensive software control flow state diagram is generated.
In detail, the target software control node is first determined. The server determines one or more critical target software control nodes according to domain knowledge, historical data or user specification, wherein the nodes generally have special significance in the software control flow, such as decision points, branch points or loop starting points.
The segmentation software then controls the node sequence. The server traverses the software control node sequence to find the positions of all the target software control nodes. The node sequence is then split into two sub-sequences according to these positions. If there are multiple target nodes, the server may select one of them as a partitioning point, or partition each target node once, to generate multiple sub-sequences.
The transition subsequence is a software control flow state subgraph. For each sub-sequence, the server converts these sub-sequences into corresponding software control flow state subgraphs according to a first set execution instance (i.e., rules for converting assigned class, judgment class, and cyclic class opcodes into different coded vectors), similar to the method of generating the first software control flow state diagram before, but processing the split sub-sequences.
After obtaining two software control flow state subgraphs, the server needs to determine the relative importance or contribution between the two subgraphs and combine them into a comprehensive software control flow state diagram by weighting calculation.
In detail, the weight calculation rule is first determined. The server assigns different weights to the two sub-graphs based on domain knowledge, historical data, or user preferences. The weight may be assigned based on the number of nodes included in the subgraph, the complexity of the opcode, the importance of the subgraph in the overall flow, and the like.
Then, a weighting calculation is performed. The server performs a weighted summation or weighted merging operation on the two software-controlled flow state subgraphs according to the determined weighted calculation rule, and the process may involve direct weighting of nodes, edges or code vectors in the subgraphs, or may involve a more complex graph structure merging algorithm.
And finally, generating a comprehensive software control flow state diagram. After the weighting calculation is completed, the server obtains a comprehensive software control circulation state diagram which not only contains the information of the two subgraphs, but also reflects the relative importance between the subgraphs through the weighting calculation. The state diagram may be used for subsequent analysis, visualization or as input data to a fault diagnosis network.
In a previous step, the server has generated first, second, and third software control flow state diagrams for each of the example software control paths. Now, the server needs to combine these state diagrams to generate a more comprehensive and accurate software control flow state diagram.
In detail, first, state diagram information is integrated. The server first extracts key information in each state graph (first, second, third), such as nodes, edges, encoding vectors, weighted results, etc., which will be the basis for the subsequent merged state graph.
Then, a merge policy is determined. The server determines a suitable merging strategy based on the state diagram characteristics and demand analysis, which may involve merging nodes and edges, superposition of coded vectors, averaging or maximum selection of weighted results, etc.
Next, a merging operation is performed. The server merges the first, second and third software control flow state diagrams into a comprehensive state diagram according to the determined merge strategy. In the merging process, the server may need to deal with the problems of node-edge collision, normalization of coding vectors, adjustment of weighting results, and the like.
Finally, the state diagram is verified and optimized. After the merging is completed, the server verifies and optimizes the generated comprehensive software control flow state diagram. The verification process may include comparison with the original node sequence, consistency and integrity checking of the state diagram, and the like. The optimization process may involve simplifying the state diagram, removing redundant information, adjusting the layout, etc., to improve the readability and practicality of the state diagram.
Through the steps, the server can generate a comprehensive, accurate and easily understood software control circulation state diagram, and powerful support is provided for subsequent fault diagnosis, flow optimization and other works.
In one possible embodiment, the method further comprises:
And step C150, configuring a fourth setting execution example corresponding to the software control node sequence. The fourth set execution instance includes dividing the sequence of software control nodes into two sub-sequences of software control nodes according to a target software control node in the sequence of software control nodes. And respectively converting the two software control node subsequences into software control flow state subgraphs according to the second setting execution example. And determining weighted calculation results of the two software control circulation state subgraphs, and generating a software control circulation state diagram.
The determining the software control circulation state diagram corresponding to each example software control path according to the first software control circulation state diagram, the second software control circulation state diagram and the third software control circulation state diagram corresponding to each example software control path includes converting each example software control path into a fourth software control circulation state diagram according to the fourth setting execution example. And determining the software control circulation state diagram corresponding to each example software control path according to the first software control circulation state diagram, the second software control circulation state diagram, the third software control circulation state diagram and the fourth software control circulation state diagram corresponding to each example software control path.
In order to analyze and represent more closely the structure and flow characteristics of the sequence of software control nodes, the server is configured with a fourth set-up execution instance. The instance divides the sequence into two parts by identifying the target software control node and converts the two parts into a software control flow state subgraph based on the second set execution instance (the execution space configuring the set length). Finally, a comprehensive software control flow state diagram is generated by weighting and calculating the two sub-diagrams.
In detail, firstly, traversing the software control node sequence, and identifying target software control nodes according to preset rules or domain knowledge, wherein the nodes can be decision points, cycle starting points, key operation points and the like, and have important logic significance in the flow.
Once the target software control node is identified, the server takes the target software control node as a division point, and divides the software control node sequence into two subsequences, wherein the two subsequences represent the flow parts before and after the target node respectively.
The server then generates a corresponding software control flow state subgraph for each sub-sequence according to the second set execution instance, in which process, the server uses an execution space with a set length to map each node in the sub-sequence onto a corresponding unit slot of the execution space according to its operation code type (assignment class, judgment class, loop class, etc.), and generates a corresponding encoding vector to represent the existence and characteristics of the node.
After obtaining two sub-graphs of software control flow states, the server needs to determine the importance or contribution of the two sub-graphs in the overall flow, and combine them into a comprehensive software control flow state graph through weighted calculation.
The server assigns a weight to each sub-graph based on domain knowledge, historical data, or user preferences. The assignment of weights may be based on factors such as the complexity of the subgraph, the number of key nodes involved, the role in the overall flow, etc.
The server performs a weighted calculation on the two software-controlled flow state subgraphs according to the determined weighting rules, which may involve a weighted summation of nodes, edges or code vectors in the subgraphs, or may involve a more complex graph structure weighted merging algorithm.
After the weighting calculation is completed, the server merges the two weighted software control circulation state subgraphs into a comprehensive software control circulation state diagram, and the state diagram not only contains the information of the two subgraphs, but also reflects the relative importance between the subgraphs through the weighting calculation.
In the previous steps, the server has generated first, second, third, and fourth software control flow state diagrams for each of the example software control paths. Now, the server needs to combine these state diagrams to generate a more comprehensive and accurate software control flow state diagram.
The server first collects all information in the first, second, third, and fourth software control flow state diagrams corresponding to each example software control path, including nodes, edges, encoding vectors, weighted results, and the like.
The server determines a suitable merging strategy based on the state diagram characteristics and demand analysis, which may require consideration of complementarity, redundancy between the different state diagrams, and their importance in the overall process.
The server merges the four software control flow state diagrams into a comprehensive state diagram according to the determined merging strategy, and in the process, the server may need to deal with the problems of node and edge conflict, superposition of coding vectors, adjustment of weighting results and the like so as to ensure that the merged state diagram is comprehensive and accurate.
After the merging is completed, the server verifies and optimizes the generated comprehensive software control flow state diagram. The verification process includes comparison with the original node sequence, consistency and integrity checking of the state diagram, and the like. The optimization process may involve simplifying the state diagram, removing redundant information, adjusting the layout, etc., to improve the readability and practicality of the state diagram. Through the steps, the server can generate a comprehensive, accurate and easily understood software control circulation state diagram, and powerful support is provided for subsequent fault diagnosis, flow optimization and other works.
In one possible implementation, step S140 includes:
Step S141, loading each target example software control path in the target example software control path sequence into the initialized classification network, and generating a graph self-attention feature corresponding to each target example software control path.
Step S142, determining training diagnosis knowledge points corresponding to the target example software control paths according to the self-attention features of the corresponding diagrams of the target example software control paths.
Step S143, updating the network parameter information of the initialization classification network based on the training diagnosis knowledge points corresponding to the respective target example software control paths and the loss function values between the labeling diagnosis knowledge points corresponding to the respective target example software control paths, so as to generate the parallel power system fault diagnosis network.
In this embodiment, the target example software control path sequence includes control flow information of the power supply system in normal operation and fault states. The server now needs to load these paths into the initializing classification network and generate corresponding graph self-attention features for subsequent diagnostic knowledge point determination and parameter learning.
In detail, the path sequence is controlled for the target example software and the logical relationship between them.
For each target example software control path in the sequence, the server inputs it into an initialization classification network, which may be a neural network-based model, capable of processing the data of the graph structure. Inside the classification network, the server processes the incoming software control path using a graph self-attention mechanism. The graph self-attention mechanism allows the model to take into account all node and edge information in the graph when generating features and to give different weights according to their importance. Through the graph self-attention mechanism, the server generates corresponding graph self-attention features for each target example software control path, wherein the features are high-dimensional vectors, and key information and structural characteristics in the path are captured.
With the graph self-attention feature of each target example software control path, the server needs to determine corresponding training diagnostic knowledge points based on the graph self-attention features, which will be used for subsequent network parameter updates and fault diagnostics.
In detail, the server designs one or more classifiers (or regressors) that can receive as input the graph self-attention features and output corresponding diagnostic knowledge points. The diagnostic knowledge points may include information on fault type, fault location, fault severity, etc. For each target example software control path, the server inputs its graph self-attention features into the classifier, resulting in a corresponding training diagnostic knowledge point, which is a forward propagation process that does not involve updating of network parameters.
After determining the training diagnosis knowledge points, the server needs to calculate the loss function values between the knowledge points and the labeling diagnosis knowledge points, and update the parameters of the initialization classification network according to the loss function values, so as to generate the parallel power system fault diagnosis network.
In detail, the server obtains labeled diagnosis knowledge points corresponding to each target example software control path, wherein the labeled diagnosis knowledge points are determined by experts or historical data in advance and represent real fault information of the path. For each target example software control path, the server calculates a loss function value between its training diagnostic knowledge point and the labeling diagnostic knowledge point. The loss function value measures the difference between the two, and is the basis for the subsequent parameter updating. The server uses a back-propagation algorithm and an optimizer (e.g., gradient descent algorithm) to update the parameters of the initialized classification network. During the back propagation, the loss function values are used to calculate gradients for each parameter in the network, and then the parameter values are updated according to the gradients. The above steps are repeated until a stopping condition (such as convergence of the loss function value, reaching a preset number of iterations, etc.) is satisfied. In the iterative process, the parameters of the network are gradually optimized, and the diagnostic capability of the target example software control path is gradually improved. When the stop condition is satisfied, the server generates a final parallel power system fault diagnosis network that has learned the fault characteristics in the target example software control path, and is able to accurately diagnose the fault type and location of the power system.
Through the steps, the initialization classification network is trained into the parallel power supply system fault diagnosis network, and a powerful tool is provided for subsequent real-time fault diagnosis.
Fig. 2 illustrates a hardware structural view of a fault diagnosis system 100 for implementing the fault diagnosis method of the parallel power system according to an embodiment of the present application, and as shown in fig. 2, the fault diagnosis system 100 may include a processor 110, a machine-readable storage medium 120, a bus 130, and a communication unit 140.
In one possible design, the fault diagnosis system 100 may be a single server or a group of servers. The server farm may be centralized or distributed (e.g., the fault diagnosis system 100 may be a distributed system). In some embodiments, the fault diagnosis system 100 may be local or remote. For example, the fault diagnosis system 100 may access information and/or data stored in the machine-readable storage medium 120 via a network. For another example, the fault diagnosis system 100 may be directly connected to the machine-readable storage medium 120 to access stored information and/or data. In some embodiments, the fault diagnosis system 100 may be implemented on a fault diagnosis system. For example only, the fault diagnosis system may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an internal cloud, a multi-layer cloud, etc., or any aggregation thereof.
The machine-readable storage medium 120 may store data and/or instructions. In some embodiments, the machine-readable storage medium 120 may store data acquired from an external terminal. In some embodiments, the machine-readable storage medium 120 may store data and/or instructions that are used by the fault diagnosis system 100 to perform or use the exemplary methods described herein.
In a specific implementation, the one or more processors 110 execute computer executable instructions stored by the machine-readable storage medium 120, so that the processor 110 may execute the fault diagnosis method of the parallel power supply system according to the above method embodiment, where the processor 110, the machine-readable storage medium 120, and the communication unit 140 are connected through the bus 130, and the processor 110 may be used to control the transceiving actions of the communication unit 140.
The specific implementation process of the processor 110 may refer to the above-mentioned embodiments of the method executed by the fault diagnosis system 100, and the implementation principle and technical effects are similar, which are not repeated herein.
In addition, the embodiment of the application also provides a readable storage medium, wherein computer executable instructions are set in the readable storage medium, and when a processor executes the computer executable instructions, the fault diagnosis method of the parallel power supply system is realized.
It should be noted that in order to simplify the presentation of the disclosure and thereby aid in understanding one or more embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof. Similarly, it should be noted that in order to simplify the description of the present disclosure and thereby aid in understanding one or more embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof.