JP7621887B2 - Equipment abnormality cause estimation device, equipment abnormality cause estimation system, and equipment abnormality cause estimation method - Google Patents

Description

The present invention relates to an equipment anomaly cause estimation device, an equipment anomaly cause estimation system, and an equipment anomaly cause estimation method that support maintenance work to deal with equipment anomalies.

Maintenance work is essential to keep equipment such as gas engines operating at all times. A related technique in this technical field is Patent Document 1. This document describes estimating abnormal parameters from equipment measurement values.

JP 2020-9080 A

However, the above-mentioned Patent Document 1 does not take into consideration a method for updating the physical model used in the estimation method. Therefore, if a change is required to the causal relationship inside the estimation model, it becomes impossible to update it.

Maintenance knowledge descriptions may contain ambiguous parts. Therefore, if a cause diagnosis system is created from the maintenance knowledge, the failure mode estimated by the cause diagnosis system will also be expressed ambiguously, making it impossible to clarify the cause of the abnormality.

Therefore, the objective of the present invention is to improve the accuracy of estimating the cause of anomalies.

In order to solve the above-mentioned problems, the equipment anomaly cause estimating device of the present invention is characterized in comprising: an asset knowledge database in which maintenance knowledge of equipment is accumulated; a diagnostic net generation unit that generates a maintenance knowledge Bayesian network from the asset knowledge database; a maintenance knowledge Bayesian network database that stores the maintenance knowledge Bayesian network; an anomaly cause estimating unit that estimates anomaly causes; a maintenance work report database that stores the anomaly causes and check item results; and an anomaly cause updating unit that clusters data on the check item results when a failure mode is input through a GUI of a terminal device for each of the anomaly causes accumulated in the maintenance work report database, and outputs the detailing targets and detailing results of the anomaly causes to the asset knowledge database.

The equipment anomaly cause estimating system of the present invention is characterized in comprising an asset knowledge database in which maintenance knowledge of equipment is accumulated, a diagnostic net generation unit that generates a maintenance knowledge Bayesian network from the asset knowledge database, a maintenance knowledge Bayesian network database that stores the maintenance knowledge Bayesian network, an anomaly cause estimating unit that estimates anomaly causes, a maintenance work report database that stores the anomaly causes and check item results, and an anomaly cause updating unit that clusters data on the check item results when a failure mode is input through a GUI of a terminal device for each of the anomaly causes accumulated in the maintenance work report database, and outputs the detailing targets and detailing results of the anomaly causes to the asset knowledge database.

The method for estimating the cause of an abnormality in equipment of the present invention is characterized by including the steps of: a diagnostic network generation unit generating a maintenance knowledge Bayesian network from an asset knowledge database in which maintenance knowledge of equipment is accumulated; a step of an abnormality cause estimation unit estimating an abnormality cause; a step of saving the abnormality cause and check item results in a maintenance work report database; and a step of an abnormality cause update unit clustering data of the check item results when input of a failure mode is accepted through the GUI of a terminal device , for each of the abnormality causes accumulated in the maintenance work report database, and outputting the detailing target and the detailing result of the abnormality cause to the asset knowledge database.
Other means will be described in the description of the embodiment of the invention.

The present invention makes it possible to improve the accuracy of estimating the cause of an abnormality.

1 is a block diagram showing an equipment abnormality cause estimation system according to an embodiment of the present invention; FIG. 2 is an explanatory diagram regarding maintenance knowledge data. FIG. 2 is an explanatory diagram of case data. FIG. 13 is a diagram showing failure mode occurrence probability. FIG. 13 is a diagram showing the probability of an abnormality occurring in a child node when a parent node is abnormal. FIG. 13 is a diagram showing the probability of an abnormality occurring in a child node when a parent node is normal. 13 is a flowchart of a process for generating a maintenance knowledge Bayesian network. FIG. 1 is a configuration diagram showing a maintenance knowledge Bayesian network. FIG. 13 is a diagram showing node data. FIG. 4 is a diagram showing link data. 13 is a flowchart showing model-specific maintenance knowledge Bayesian network processing. 13 is a flowchart of a cause estimation process. FIG. 11 is an explanatory diagram showing estimation result data. FIG. 11 is an explanatory diagram showing estimation result data. FIG. 13 is an explanatory diagram showing an estimation result notifying screen. FIG. 11 is an explanatory diagram showing maintenance work report data. 13 is a flowchart of an abnormality cause updating process. FIG. 2 is an explanatory diagram showing history data. FIG. 13 is a diagram showing an n-dimensional space to be mapped in cluster processing. FIG. 13 is a diagram showing update process result data. FIG. 13 is a diagram showing a Bayesian network before updating. FIG. 13 is a diagram showing an updated Bayesian network. FIG. 13 is an explanatory diagram showing an update of a failure mode wording. FIG. 13 is an explanatory diagram showing an update of a failure mode wording. 13 is a flowchart of a process for extracting a check item statement.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
FIG. 1 is a block diagram showing an equipment abnormality cause estimation system 9 according to the present embodiment.
The equipment anomaly cause estimation system 9 includes an asset knowledge database 1, a diagnostic net generation unit 2, a maintenance knowledge Bayesian network database 3, an anomaly cause estimation unit 4, a maintenance work report database 5, and an anomaly cause update unit 6. Note that the present invention is not limited to a system in which a plurality of devices are combined, and may be a single equipment anomaly cause estimation device.

The asset knowledge database 1 is a database in which maintenance knowledge is accumulated. Maintenance knowledge is information extracted from, for example, a maintenance manual or an FT (Fault Tree) diagram, and includes, for example, the maintenance knowledge data 71 shown in FIG. 2, the failure mode occurrence probability shown in FIG. 4, the child node abnormality occurrence probability when the parent node is abnormal shown in FIG. 5, and the child node abnormality occurrence probability when the parent node is normal shown in FIG. 6.

FIG. 2 is an explanatory diagram regarding the maintenance knowledge data 71. As shown in FIG.
The maintenance knowledge data 71 includes an abnormal event column, a functional failure column, a component column, a failure mode column, and a check item column.

The abnormal event column is a column where the name of the abnormal event is stored; in this case, a rise in temperature is stored. The functional failure column stores information that identifies the cause of the abnormal event. The functional failure column may also contain information about the component that corresponds to the functional failure. Note that one abnormal event may cause more than one functional failure.

The component column is a column that stores the name of the component that causes the functional failure. The failure mode column is a column that stores the failure mode related to the functional failure, i.e., the cause of the failure.

The check item column is a column for storing items to be checked, such as equipment sensor data, environment, equipment, components, etc. Check items are intended to identify phenomena that can occur when a failure mode occurs, and to check whether or not the phenomenon has occurred. There is not necessarily only one check item that corresponds to one failure mode.

FIG. 3 is an explanatory diagram of the case data 72. As shown in FIG.
The case ID column is a column for storing an identification number of a case related to an abnormal event. The abnormal event column is a column for storing the name of an abnormal event.
When an abnormal event occurs, the diagnostic net generating unit 2 assigns an identification number to the case, as shown in the case data 72, and executes processing related to the case. The diagnostic net generating unit 2 generates a maintenance knowledge Bayesian network 8 (see FIG. 8) from the asset knowledge database 1.

Returning to Figure 1, we will continue the explanation. The asset knowledge database 1 stores probability information that is set for the causal relationships of the maintenance knowledge Bayesian network 8 in Figure 8, which will be described later. Abnormal events and functional failures, functional failures and failure modes, and failure modes and check items all have cause-and-effect relationships, and below, when generating the maintenance knowledge Bayesian network 8, all information is generated as nodes to connect the causal relationships. In the maintenance knowledge Bayesian network 8, parent nodes and child nodes are connected by probability information of the causal relationships, and the following is an example.

The asset knowledge database 1 also stores three types of data. These three types of data are explained in Figures 4 to 6 below.

4 is a diagram showing the failure mode occurrence probability table 11. The failure mode occurrence probability table 11 is the first data stored in the asset knowledge database 1.
The failure mode occurrence probability table 11 includes a failure mode column, a state column, and a probability column. Based on this table, the occurrence probability of each failure mode can be known.

The failure mode column stores the name of the failure mode.
The state column stores Y or N, which respectively indicate the occurrence and non-occurrence of the failure mode. These states are set so that the sum of the probabilities of Y and N related to the same failure mode is 1.

The probability column stores the probability of the failure mode state. Here, the failure mode probability is set to a fixed value such as 50% for the failure mode states Y and N. However, this is not limited to this, and calculations can also be made from past history, etc. The probability of a failure mode occurring state is, for example, the value obtained by dividing the number of occurrences of the failure mode in the failure history by the total number of occurrences.

5 is a diagram showing a child node abnormality occurrence probability table 12 when a parent node is abnormal. The child node abnormality occurrence probability table 12 is the second data stored in the asset knowledge database 1.
The child node abnormality occurrence probability table 12 when the parent node is abnormal includes a parent node column, a status column, a child node column, a child node status column, and a probability column. The child node abnormality occurrence probability table 12 indicates the probability that a check item is abnormal or normal when a certain failure mode occurs.

The parent node column stores the name of the failure mode. In this table, the state column stores Y, which indicates the occurrence state of the failure mode.
The child node column stores the check item, here the sensor name. The child node status column stores the status of the check item, here the status of the sensor. The probability column stores the probability of the check item status, here the probability of the sensor status. In child node abnormality occurrence probability table 12, the sum of the abnormal and normal probabilities related to the status of the same check item is set to 1.0 (100%).

This second data can be set to a fixed value, such as 100% when abnormal and 0% when normal, or it can be calculated from past failure history.

6 is a diagram showing the child node abnormality occurrence probability table 13 when the parent node is normal. The child node abnormality occurrence probability table 13 is the third data stored in the asset knowledge database 1.
The child node abnormality occurrence probability table 13 includes a child node column, a child node state column, and a probability column.
The child node column stores the check item, here the sensor name. The child node status column stores the status of the check item, here the status of the sensor. The probability column stores the probability of the check item status, here the probability of the sensor status. In child node abnormality occurrence probability table 13, the sum of the abnormal and normal probabilities related to the status of the same check item is set to 1.0 (100%).
This third data can be set to a fixed value such as 0% when abnormal and 100% when normal, or can be calculated from the past failure history.

Returning to Figure 1 for further explanation, when an abnormality occurs in equipment and case information including a case ID and an abnormal event (which may also include model information) is input as shown in Figure 2, the diagnostic network generator 2 generates a maintenance knowledge Bayesian network 8 for inferring the cause. The maintenance knowledge Bayesian network 8 is illustrated in Figure 8, which will be described later.

The maintenance knowledge Bayesian network database 3 stores the maintenance knowledge Bayesian network 8 generated by the diagnostic net generating unit 2 .
The anomaly cause estimation unit 4 estimates the cause of an anomaly using the case information and the results of the check items (normal or abnormal) entered by the maintenance staff as input data, calculates the occurrence probability of the failure mode, and outputs it. The anomaly cause estimation unit 4 displays the calculated occurrence probability of the failure mode on the screen of the device. The details are shown in FIG. 12, which will be described later.

The maintenance work report database 5 is a database for storing maintenance work reports. The maintenance work report database 5 stores the abnormality causes estimated by the abnormality cause estimation unit 4, case information, and check item results input by maintenance personnel, etc.
The anomaly cause update unit 6 refers to the records in the maintenance work report database 5. When the anomaly cause update unit 6 finds an anomaly cause to be updated from the maintenance work report database 5, it creates an update command and updates the asset knowledge database 1. The anomaly cause update unit 6 clusters the data of the anomaly causes and check item results stored in the maintenance work report database 5 shown in Fig. 1, and outputs the anomaly cause detailing target and the detailing result.

<Maintenance knowledge Bayesian network generation process>
FIG. 7 is a flowchart of the generation process of the maintenance knowledge Bayesian network 8 .
This process is executed every time case information (a combination of a case ID and an abnormal event) such as that shown in FIG.

When this process is executed by the diagnostic net generation unit 2, the diagnostic net generation unit 2 generates a network ID in the form of a character string or the like, and receives the case information (step S10). The diagnostic net generation unit 2 searches the asset knowledge database 1 for abnormal event information in the case information, and acquires the contents of the matching abnormal event (step S11). The diagnostic net generation unit 2 generates network structure information using the acquired asset knowledge database 1 data (step S12), and ends the process of FIG. 7.

The network structure information generated by the diagnostic net generation unit 2 is, for example, a maintenance knowledge Bayesian network 8 shown in FIG. 8 described later. Specifically, the diagnostic net generation unit 2 generates node information from the acquired data in the asset knowledge database 1. The diagnostic net generation unit 2 generates the information of each cell in the asset knowledge database 1 into one line of note information in the node data 14 shown in FIG. 9 described later.

FIG. 8 is a diagram showing an example of the maintenance knowledge Bayesian network 8. As shown in FIG.
This maintenance knowledge Bayesian network 8 is composed of four hierarchical levels, from hierarchical levels 81 to 84. Hierarchical level 81 is a level of abnormal phenomena, and includes node 811. Node 811 is a node related to temperature rise. The maintenance knowledge Bayesian network 8 is a Bayesian network with a four-hierarchical structure of abnormal events, functional failures, failure modes, and check items, and each link arrow indicates a causal relationship. The start of the link arrow is the cause, or parent node. The end of the link arrow is the result, or child node.

Level 82 is a functional failure level, and includes nodes 821 to 823. Node 821 is a node related to insufficient capacity of the heat exchanger. Node 822 is a node related to insufficient capacity of the cooling pump. Node 823 is a node related to insufficient capacity of the cooling tower. Links leading to node 811 are connected to these nodes 821 to 823.

Hierarchy 83 is a hierarchy of failure modes, and includes nodes 831 to 834. Node 831 is a node related to a design flaw in the heat exchanger. Node 832 is a node related to fouling and clogging of the heat exchanger. Node 833 is a node related to fouling and clogging of the cooling pump. Node 834 is a node related to a deterioration in cooling tower performance. Links leading to node 821 are connected to nodes 831 and 832. A link leading to node 822 is connected to node 833. A link leading to node 823 is connected to node 834.

Hierarchy 84 is a hierarchy of check items, and includes nodes 841 to 844. Node 841 is a node related to the value of sensor #1. Node 842 is a node related to the value of sensor #2. Node 843 is a node related to the value of sensor #3. Node 844 is a node related to the damage status. Links directed to nodes 841 and 842 are connected to node 831. A link directed to node 842 is connected to node 832. Links directed to nodes 842 and 843 are connected to node 833. Links directed to nodes 842 and 844 are connected to node 834.

Note that the configuration of the maintenance knowledge Bayesian network 8 and the meaning of each layer are not limited to those shown in Figure 8.

FIG. 9 is a diagram showing the node data 14. As shown in FIG.
The node data 14 is stored in each node of the maintenance knowledge Bayesian network 8 shown in FIG. 8, and includes node information, type, and status. Nodes 831-834 in the failure mode hierarchy of hierarchy 83 and nodes 821-824 in the functional failure hierarchy also include component ID information. However, only one row of node information is generated with the same content. One row of information in this node data 14 corresponds to one node of the Bayesian network for cause estimation. The link information for this node is generated from the data in the asset knowledge database 1 acquired in step S11.

FIG. 10 is a diagram showing the link information 15. As shown in FIG.
The link information 15 includes parent node information and child node information. Like this link information 15, the diagnostic network generator 2 processes the information of the asset knowledge database 1 acquired in step S11 line by line, and inputs the parent node and the child node to generate link information representing a causal relationship. The maintenance knowledge Bayesian network 8 in FIG. 8 is configured based on the link information in FIG. 10.

FIG. 11 is a flowchart showing model-specific maintenance knowledge Bayesian network processing.
When the process starts, the diagnostic net generation unit 2 prepares prior probability information of the failure mode in the node information (step S40). Here, the diagnostic net generation unit 2 refers to first data related to failure mode occurrence probability information in the asset knowledge database 1, and searches and acquires the probability of the failure mode in the node information. The data obtained here is the first probability data for generating the net.

Next, the diagnostic net generation unit 2 searches and obtains second data related to child node abnormality occurrence probability information in the asset knowledge database 1 using the parent node and child mode information in the link information (step S41). The data obtained here is second probability data for generating the net.

Next, the diagnostic net generation unit 2 searches and acquires third data related to child node abnormality occurrence probability information in the asset knowledge database 1 using child mode information in the link information (step S42). The data obtained here is the third probability data for net generation.

The diagnostic network generation unit 2 outputs the first to third probability data for generating the processed node information and link information to the maintenance knowledge Bayesian network database 3 in the equipment abnormality cause estimation system 9 (step S43), and then ends the processing of FIG. 11.

<<Cause estimation process>>
Next, the cause estimation process will be described.
12 is a flowchart of the cause estimation process, which is executed every time case information is input.

When this process is executed, the diagnostic network generation unit 2 receives the network ID, network information, and case information (step S20). The diagnostic network generation unit 2 displays the node information for the check items contained in the received network information on the screen of a terminal (not shown) (step S21). While looking at the screen, the equipment maintenance worker checks the equipment according to the displayed check items and inputs the check results.

The diagnostic network generator 2 uses the network information to generate a maintenance knowledge Bayesian network 8 (step S22).
The diagnostic net generating unit 2 determines that an abnormal event node having the same content as the abnormality occurrence information in the case information is in an abnormal state. When the check item results are input, the diagnostic net generating unit 2 calculates the occurrence probability of a failure mode node using the maintenance knowledge Bayesian network 8 and displays it on the screen of a terminal (not shown) (step S23).

The output data is the case ID, the check item results, the probability of each state of all nodes in the network, and the network ID. In addition, the occurrence probability of the failure mode node shown in FIG. 13A and the input results of the check items shown in FIG. 13B are considered as estimation result data.

Fig. 13A is a diagram showing a failure mode occurrence probability 73. Fig. 13B is a diagram showing a check item input result 74. Fig. 13A and Fig. 13B together show the estimation result data.
The failure mode occurrence probability 73 in FIG. 13A includes a failure mode column, a state column, and a probability column.
The failure mode column stores the name of the failure mode.

The status column stores Y or N, which respectively indicate the occurrence or non-occurrence of the failure mode. These states are set so that the sum of the probabilities of Y and N related to the same failure mode is 1.0 (100%).
The probability column stores the probability of the failure mode state.

The check item input result 74 in FIG. 13B includes a check item column and a status column.
The check item column stores a check item, in this case the name of a sensor, and the status column stores a status related to the check item.

Returning to FIG. 12, the explanation continues. In step S23, the diagnostic net generation unit 2 assigns the probability of each state of all nodes in the network, referred to as the estimation result, and an estimation result ID. The diagnostic net generation unit 2 sorts in descending order the probability that a failure mode in the estimation result data will occur, that is, the probability that the failure mode node will become Y. In order to emphasize the higher probability, the diagnostic net generation unit 2 displays the failure modes in descending order of occurrence probability on a terminal device (not shown) connected to the equipment abnormality cause estimation system 9.

The diagnostic net generation unit 2 also highlights the functional failure node, which is a child node of the failure mode, and the node of the check item whose check item result is abnormal. The maintenance worker makes a judgment while looking at the results displayed on a terminal device (not shown), and selects the failure mode that he or she judges to be the cause.

14 is an explanatory diagram showing an estimation result notification screen 86. This estimation result notification screen 86 is displayed on the display of a terminal device (not shown).
The inference result notification screen 86 displays the maintenance knowledge Bayesian network 8, and each node of the failure mode is displayed with selection buttons 871 to 874. At the bottom of the inference result notification screen 86, a "Manually input inferred cause" button 88 is displayed.

Threshold values are set so that the probability of a failure mode occurring can be classified into three ranks: "high," "medium," and "low." On the estimation result notification screen 86, the corresponding nodes are colored in a color according to the threshold value, for example, "red," "pink," or "white." In FIG. 14, red is indicated by dark hatching, and pink is indicated by light hatching.

Clicking any of the selection buttons 871 to 874 on the node of each failure mode transitions to a dialog where the failure mode determined to be the cause can be selected. Clicking the "Manual input of inference result" button 88 transitions to a dialog where the inference results can be manually input. This allows the diagnostic net generation unit 2 to accept input of the failure mode determined to be the cause by the maintenance worker via the GUI (Graphical User Interface) of the terminal device.

Returning to Figure 12, we continue the explanation. The maintenance worker performs maintenance work, inputs each confirmed abnormality cause, judges whether it matches the estimated result, and inputs it into the GUI of the terminal device. The diagnostic net generation unit 2 receives, via the GUI of the terminal device, the result with the highest occurrence probability (estimated abnormality cause in Figure 15 described below), the result selected by the maintenance worker, the network ID, the selection result ID, and the network ID (step S24). The diagnostic net generation unit 2 generates a work report and outputs it as maintenance work report data 41 shown in Figure 15 described below (step S25), and ends the processing of Figure 12.

FIG. 15 is an explanatory diagram showing the maintenance work report data 41.
The maintenance work report data 41 includes a report ID field, a network ID field, an estimated result ID field, an estimated abnormality cause field, a cause determination result field, and a match field. Each row represents a piece of report data that constitutes the maintenance work report data 41.

The report ID column stores the identifier of the report data. The network ID column stores the identifier of the network. The estimation result ID column stores the identifier of the estimation result. The estimated anomaly cause column stores the input estimated anomaly cause. The cause determination result column stores the result determined by this equipment anomaly cause estimation system 9. The match column stores whether or not the input estimated anomaly cause matches the result determined by this equipment anomaly cause estimation system 9.

<<Anomaly Cause Update Process>>
Next, an abnormality cause update process will be described. This process is executed periodically, whenever an update execution instruction is received, or whenever approval is given by an administrator or the like.
FIG. 16 is a flowchart of the abnormality cause updating process.
When this process is executed, the abnormality cause update unit 6 reads the past history data 51, an example of which is shown in FIG. 17, from the maintenance work report database 5 (step S30).

FIG. 17 is an explanatory diagram showing the past history data 51.
The history data 51 includes a failure cause column and CK1 to CK4 columns.
The failure cause column stores the cause of failure determined in a certain failure mode. The failure causes stored in the failure cause column are the selection results in the maintenance work report data 41 of FIG.

The CK1 to CK4 columns store the check item input results when a record is generated in which a certain failure mode is determined to be the cause of the failure.

Figure 17 shows that the target failure mode is failure cause "FM1", and the CK1 to CK4 columns show the input results of four check items when a record is generated in which it is determined that failure cause "FM1" is the cause of the failure. The failure modes that are processed include all failure modes, failure modes manually specified by maintenance personnel, and failure modes that differ from the estimated cause and the cause determination result in the maintenance record. In this embodiment, the target check items are check items that are linked to the target failure mode. However, this is not limited to this, and it may be all check items stored in the asset knowledge database 1.

Returning to FIG. 16, the explanation will continue. The anomaly cause update unit 6 treats one record (one row) as one data set, maps all the data into n-dimensional space as shown in FIG. 18, and performs clustering processing (step S31).

FIG. 18 is a diagram showing n-dimensional space into which data is mapped.
The number of dimensions n is the number of check items, and in this case indicates a two-dimensional space composed of the CK1 column and the CK2 column. The calculation is performed assuming that "yes" indicating an abnormality in each check item is "1" and "No" indicating normality in each check item is "-1". The vertical axis of the graph indicates the CK1 axis, and the horizontal axis of the graph indicates the CK2 axis. Here, there are cluster 91 with three pieces of data, cluster 92 with three pieces of data, and cluster 93 with one piece of data.

Returning to FIG. 16, the explanation continues. In step S31, the anomaly cause update unit 6 performs clustering processing such as k-means, excludes clusters below a certain value, and calculates the ratio of the number of data belonging to each cluster to the total number. As shown in FIG. 18, the number of data belonging to cluster 3 is small, so it is excluded. Alternatively, a clustering process may be performed using a method such as random forest, and the number of clusters may be manually specified. Also, to manually assign weighting coefficients, values other than "1" and "-1" may be specified for yes and no, which are the input results of the check items.

In step S32, the anomaly cause update unit 6 sequentially compares the two clusters and uses the cluster center distance L to determine whether they are to be split. If the cluster center distance L is equal to or greater than a predetermined value, the anomaly cause update unit 6 selects the two clusters as targets for splitting. If the cluster center distance L is less than a predetermined value, the anomaly cause update unit 6 does not select the two clusters as targets for splitting. Here, as shown in FIG. 18, the cluster center distance L between cluster 91 and cluster 92 is equal to or greater than a predetermined value, and they are to be split.

The anomaly cause update unit 6 determines whether or not there is a cluster to be split (step S33). If there is a cluster to be split (Yes), the anomaly cause update unit 6 proceeds to step S34, and if there is no cluster to be split (No), the anomaly cause update unit 6 ends the processing of FIG. 16.

In step S34, the anomaly cause update unit 6 calculates the distance between the clusters other than the cluster to be split and the cluster to be split, and merges them with the cluster that is closest to the cluster. As shown in FIG. 18, cluster 93 is close to cluster 91, so it is merged with cluster 91. In addition, if a cluster can be merged with two or more clusters, the anomaly cause update unit 6 further divides the cluster into clusters that can be merged, or randomly determines the cluster to be merged.

Returning to FIG. 16 for further explanation, the anomaly cause update unit 6 then generates an update command and executes the update (S35), terminating the processing of FIG. 16. Through the processing of FIG. 16, the anomaly cause update unit 6 divides the failure mode by refining the anomaly cause, and outputs the clusters belonging to each record and the results after division to the asset knowledge database 1 or a terminal device (not shown). The diagnostic network generation unit 2 uses the results after division and stores them in the maintenance knowledge Bayesian network database 3.

FIG. 19 is a diagram showing the update process result data 21. As shown in FIG.
The update process result data 21 includes a failure cause column, CK1 to CK4 columns, a cluster column, and a post-division result column.

The failure cause column stores the cause of failure determined in a certain failure mode. The CK1 to CK4 columns store the input results of the check items when a record was generated in which a certain failure mode was determined to be the cause of the failure. The cluster column stores the cluster number to which this data belongs. The post-split result column stores the new results after splitting.

The anomaly cause update unit 6 divides the target failure mode, for example, dividing failure cause FM1 into "FM1a" and "FM1b." Therefore, the maintenance knowledge Bayesian network including the divided failure modes will look like FIG. 20A before the update, and like FIG. 20B after the update.

FIG. 20A is a diagram showing the maintenance knowledge Bayesian network 8A before updating.
This maintenance knowledge Bayesian network 8A includes nodes FM1 and FM2, nodes FF1, FF2, and EF, and nodes CK1 to CK4. A link is provided from node FM1 to node FF1, and links are provided to nodes CK1 to CK4.

A link is provided from node FM2 to node FF1, and links are provided to nodes CK1 to CK4. Node FF1 has a link to node EF. Node FF2 has a link to node EF.

FIG. 20B is a diagram showing the updated maintenance knowledge Bayesian network 8B.
This maintenance knowledge Bayesian network 8B includes nodes FM1a, FM1b, and FM2, nodes FF1, FF2, and EF, and nodes CK1 to CK4. Nodes FM1a and FM1b correspond to node FM1 in Fig. 20A. A link is provided from node FM1a to node FF1, and links are provided to nodes CK1 to CK4. A link is provided from node FM1b to node FF1, and links are provided to nodes CK1 to CK4.

A link is provided from node FM2 to node FF1, and links are provided to nodes CK1 to CK4. Node FF1 has a link to node EF. Node FF2 has a link to node EF.

Node FM1, whose failure cause is "cooling tower design defect," is split into nodes FM1a and FM1b. The newly generated nodes FM1a and FM1b related to the failure modes after splitting are linked to nodes CK1 to CK4, which are check items.

The update command for the failed node changes the information in asset knowledge database 1. Specifically, the information related to node FM1 in asset knowledge database 1 is copied and written separately for nodes FM1a and FM1b.

If a check item other than the check item linked to the failure mode before the split is added to the failure mode after the split, add information for that row. The probability information included in node FM1 is also copied and entered separately for nodes FM1a and FM1b. If a check item other than the check item linked to the failure mode before the split is added to the failure mode after the split, add information for that row. The value set in the probability information may be calculated using the input result of the updated check item.

<<Correction of the wording of the failure mode after division>>
As a method for correcting the wording of the failure mode after division, there is a method of calculating the percentage of abnormal check items among the results of the check items belonging to the failure mode after division and displaying the calculated percentage on the screen, as shown in Figures 21A and 21B.

Figure 21A is a diagram showing a failure mode statement table 75 for node FM1a. The failure mode statement table 75 includes a check item column, a check item statement column, and an abnormality rate column.

Figure 21B is a diagram showing a failure mode statement table 76 for node FM1b. The failure mode statement table 76 includes a check item column, a check item statement column, and an abnormality rate column. These statements are displayed on the screen of a maintenance worker's terminal device (not shown).

In these failure mode wording tables 75, if a certain percentage or more of the input results are abnormal, the abnormality rate column will be marked "high" and one row of data will be displayed in red. The maintenance staff will look at this terminal screen and correct the wording of the failure mode after division. For example, in the case of the failure mode wording table 75 related to failure cause "FM1a" shown in FIG. 20B, check items CK3 and CK4 are often abnormal. In the case of the failure mode wording table 76 related to failure cause "FM1b" shown in FIG. 20B, check item CK2 is often abnormal. The wording of check items CK3 and CK4 often appears as "cooling tower fan." In check item CK2, "cooling tower selection design record" often appears.

Therefore, the maintenance personnel can modify the failure mode wording for node FM1a to "Inappropriate cooling tower fan settings" and the failure mode wording for node FM1b to "Inappropriate cooling tower selection design records."

This process may be performed by using the data shown in Figures 20A and 20B to extract the wording of the check items through techniques such as natural language processing, such as "component name + fault name" or "component name + 'fault'".

FIG. 22 is a flowchart of a process for extracting the wording of a check item.
When the process starts, the anomaly cause update unit 6 identifies check items that belong to the failure mode after division (step S50).Then, the anomaly cause update unit 6 identifies check item statements that have a high rate of anomalies among the identified check items (step S51).

The anomaly cause update unit 6 extracts a combination of a component name and a fault name, or a combination of a component name and "fault" from the identified check item phrases (step S52). Then, the anomaly cause update unit 6 corrects the phrase of the post-split failure mode to the extracted phrase (step S53), and ends the process in Fig. 22. This process makes it possible to automatically set the phrase of the post-split failure mode.
This process may include a process in which the extracted wording is reviewed by a maintenance person or the like and the correction of the wording of the failure mode is approved.

(Modification)
The present invention is not limited to the above-described embodiment, and includes various modified examples. For example, the above-described embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to those having all of the configurations described. It is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. In addition, it is also possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

The above configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware such as an integrated circuit. The above configurations, functions, etc. may be realized by software by a processor interpreting and executing a program that realizes each function. Information such as the programs, tables, and files that realize each function can be stored in a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or on a recording medium such as a flash memory card or a DVD (Digital Versatile Disk).

In each embodiment, the control lines and information lines are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are interconnected.

1 Asset knowledge database 11 Failure mode occurrence probability table 12 Child node abnormality occurrence probability table 13 Child node abnormality occurrence probability table 14 Node data 15 Link data 2 Diagnostic net generation unit 21 Update processing result data 3 Maintenance knowledge Bayesian network database 4 Abnormality cause estimation unit 41 Maintenance work report data 5 Maintenance work report database 51 History data 6 Abnormality cause update unit 71 Maintenance knowledge data 72 Case data 73 Failure mode occurrence probability 74 Check item input result 75 Failure mode statement table 76 Failure mode statement table 8 Maintenance knowledge Bayesian network 8A, 8B Bayesian network 81 to 84 Hierarchy 811, 821 to 823, 831 to 834, 841 to 844 Node 86 Estimation result notification screen 871 to 874 Selection button 88 Estimated cause manual input button 9 Equipment abnormality cause estimation system 91 to 93 Cluster

Claims (12)

An asset knowledge database that accumulates equipment maintenance knowledge;
a diagnostic network generation unit that generates a maintenance knowledge Bayesian network from the asset knowledge database;
a maintenance knowledge Bayesian network database for storing the maintenance knowledge Bayesian network;
an anomaly cause estimation unit that estimates a cause of an anomaly;
a maintenance work report database for storing the abnormality causes and check item results;
an anomaly cause update unit that performs clustering of data of the check item results when a failure mode is input through a GUI of a terminal device for each of the anomaly causes stored in the maintenance work report database, and outputs the detailing target and the detailing result of the anomaly cause to the asset knowledge database;
An equipment abnormality cause estimating device comprising: the anomaly cause update unit maps and clusters the check item results related to the failure mode in a multidimensional space;
2. The equipment abnormality cause estimating device according to claim 1 . the anomaly cause update unit clusters the check item results related to the failure mode, and if the center distance between two clusters is equal to or greater than a predetermined value, the two clusters are subject to division;
2. The equipment abnormality cause estimating device according to claim 1 . The anomaly cause update unit clusters the check item results related to the failure mode and excludes clusters below a certain value .
2. The equipment abnormality cause estimating device according to claim 1 . the anomaly cause update unit performs clustering of check item results related to the failure mode, and combines a cluster including data less than a predetermined ratio with a cluster to be divided that is relatively close to a cluster center distance;
2. The equipment abnormality cause estimating device according to claim 1 . The anomaly cause update unit divides a failure mode by refining the anomaly cause,
The diagnostic network generation unit generates a maintenance knowledge Bayesian network database including the failure modes after the division.
2. The equipment abnormality cause estimating device according to claim 1 . the anomaly cause update unit calculates and outputs a ratio of abnormal check items among the results of check items belonging to the divided failure mode;
7. The equipment abnormality cause estimating device according to claim 6. the anomaly cause update unit extracts a combination of a component name and a fault name from a wording of a check item having a high rate of anomalies among the results of check items belonging to the failure mode after division;
2. The equipment abnormality cause estimating device according to claim 1 . the anomaly cause update unit extracts a combination of a component name and the word "failure" from the wording of a check item having a high rate of anomalies among the results of check items belonging to the failure mode after division;
2. The equipment abnormality cause estimating device according to claim 1 . The asset knowledge database stores a failure mode occurrence probability table, an abnormality occurrence probability table of a child node when a parent node of the maintenance knowledge Bayesian network is abnormal, and an abnormality occurrence probability table of the child node when the parent node is normal.
2. The equipment abnormality cause estimating device according to claim 1 . An asset knowledge database that accumulates equipment maintenance knowledge;
a diagnostic network generation unit that generates a maintenance knowledge Bayesian network from the asset knowledge database;
a maintenance knowledge Bayesian network database for storing the maintenance knowledge Bayesian network;
an anomaly cause estimation unit that estimates a cause of an anomaly;
a maintenance work report database for storing the abnormality causes and check item results;
an anomaly cause update unit that performs clustering of data of the check item results when a failure mode is input through a GUI of a terminal device for each of the anomaly causes stored in the maintenance work report database, and outputs the detailing target and the detailing result of the anomaly cause to the asset knowledge database;
An equipment abnormality cause estimation system comprising: A diagnostic network generation unit generates a maintenance knowledge Bayesian network from an asset knowledge database in which maintenance knowledge of equipment is accumulated;
An anomaly cause estimation unit estimates a cause of the anomaly;
storing the cause of the abnormality and the check item result in a maintenance work report database;
an anomaly cause update unit performs clustering of data of the check item results when a failure mode input is received through a GUI of a terminal device for each of the anomaly causes stored in the maintenance work report database, and outputs the detailing target and the detailing result of the anomaly cause to the asset knowledge database;
An equipment abnormality cause estimating method comprising:

Images