WO2022130789A1 - Cause inference system and cause inference method - Google Patents

Abstract

A network generation unit (111) of this cause inference system refers to a shared maintenance knowledge network (maintenance knowledge table (210)), and specifies, on the basis of an abnormal event, failure in a component related to the abnormal event, and checking items for checking the propriety of occurrence of the failure, thereby generating a maintenance knowledge network corresponding to the abnormal event. Next, the network generation unit (111) refers to a machine type table (220) to specify, on the basis of a machine type of a facility, a type of a component provided to the machine type of the facility, refers to a failure mode table 230 to remove, from the maintenance knowledge network corresponding to the abnormal event, failure which is not associated with the specified type of the component, and further removes remaining failure and unrelated checking items, thereby generating a maintenance knowledge network corresponding to the abnormal event and the machine type of the facility.

Description

Cause estimation system and cause estimation method

The present invention relates to a cause estimation system and a cause estimation method for estimating the cause of an abnormal event of equipment or equipment.

Maintenance work is essential to maintain the normal operation of equipment and devices placed in plants and facilities. In addition, when an abnormality (abnormal event, failure) occurs in equipment or equipment, it is required to promptly identify the cause and deal with it.
The equipment condition monitoring system described in Patent Document 1 makes it possible to estimate anomalous parameters from plant measured values and to estimate faulty equipment from anomalous parameters. The equipment status monitoring system stores equipment deterioration models that model the relationship between the normal measurement value database that stores plant measurement values when the plant equipment is normal and the parameters that affect the equipment failure. A model database, a device failure probability database in which the device failure probability is stored, and a device failure record database in which the device failure record is stored are provided, and the probability calculated from the database is set to set the physical model. , The presence or absence of abnormality is determined by comparing the measured value of the plant with the measured value at normal time, and the abnormality parameter is estimated, and the faulty equipment is estimated from the abnormality parameter using the physical model.

Japanese Unexamined Patent Publication No. 2020-909080

In the device condition monitoring system described in Patent Document 1, a physical model (network model used for estimating the cause of failure) in which a prior probability of failure and a conditional probability are set is prepared for each device to estimate the failed device. Used for. Therefore, even if the equipment and devices have the same configuration, if the models are different, it is necessary to prepare different physical models. Further, even if a common physical model is created between models of devices having the same configuration, the physical model cannot be updated if the internal causal relationship of the physical model is found to be different between the models.

The present invention has been made in view of such a background, and it is an object of the present invention to provide a cause estimation system and a cause estimation method capable of estimating a failure cause corresponding to a model based on a network model common to all models. And.

In order to solve the above-mentioned problems, the cause estimation system according to the present invention checks the relationship between an abnormal event of equipment and a failure of a component provided in the equipment, and a check for confirming whether or not the failure and the failure have occurred. It occurs in a common maintenance knowledge network that shows the relationship with items, a model table that associates the model of the equipment with the type of the component provided in the equipment of the model, the type of the component, and the type of the component. A network generation unit that performs information processing using a failure table associated with a failure is provided, and the network generation unit receives the abnormal event and the model of the equipment in which the abnormal event has occurred, and the common maintenance knowledge. With reference to the network, the failure of the component related to the abnormal event and the check item for confirming the occurrence of the failure are specified from the received abnormal event, and the maintenance corresponding to the abnormal event is performed. Generate a knowledge network, refer to the model table, identify the type of component provided in the model of the equipment from the received equipment model, refer to the failure table, and associate it with the specified component type. Failures that do not include the above are removed from the maintenance knowledge network corresponding to the abnormal event, and check items that are different from the check items for confirming the occurrence of failures that remain unremoved are further removed. Generate a maintenance knowledge network corresponding to the abnormal event and the model of the equipment.

According to the present invention, it is possible to provide a cause estimation system and a cause estimation method that enable estimation of a failure cause corresponding to a model based on a network model common to all models. Issues, configurations and effects other than those described above will be clarified by the description of the following embodiments.

It is an overall block diagram of the cause estimation system which concerns on 1st Embodiment. It is a functional block diagram of the maintenance knowledge network generation apparatus which concerns on 1st Embodiment. It is a data structure diagram of the maintenance knowledge table which concerns on 1st Embodiment. It is a data structure diagram of the model table which concerns on 1st Embodiment. It is a data structure diagram of the failure mode table which concerns on 1st Embodiment. It is a data structure diagram of the failure mode occurrence probability table which concerns on 1st Embodiment. It is a data structure diagram of the failure detection probability table which concerns on 1st Embodiment. It is a data structure diagram of the child node abnormality occurrence probability table which concerns on 1st Embodiment. It is a data composition diagram of the case information which concerns on 1st Embodiment. It is a flowchart of maintenance knowledge network generation processing corresponding to the abnormal event which concerns on 1st Embodiment. It is a figure which shows the structure of the maintenance knowledge network corresponding to the abnormal event which concerns on 1st Embodiment. It is a data structure diagram of the node information table which concerns on 1st Embodiment. It is a data structure diagram of the link information table which concerns on 1st Embodiment. It is a flowchart of maintenance knowledge network generation processing corresponding to the model which concerns on 1st Embodiment. It is a functional block diagram of the cause estimation apparatus which concerns on 1st Embodiment. It is a flowchart of the cause estimation process which concerns on 1st Embodiment. It is a data block diagram of the calculation result table of the failure mode which concerns on 1st Embodiment. It is a screen block diagram of the estimation result display screen which concerns on 1st Embodiment. It is a functional block diagram of the maintenance knowledge update device which concerns on 1st Embodiment. It is a data composition diagram of the estimation result evaluation table which concerns on 1st Embodiment. It is a screen block diagram of the update instruction screen which concerns on 1st Embodiment. It is a data structure diagram of the content of the update instruction of maintenance knowledge which concerns on 1st Embodiment. It is a data structure diagram of the update instruction content of the model specification which concerns on 1st Embodiment. It is a data composition diagram of the update instruction content of the probability information which concerns on 1st Embodiment. It is a flowchart of the update process performed by the update execution unit which concerns on 1st Embodiment. It is a functional block diagram of the cause estimation apparatus which concerns on 2nd Embodiment. It is a graph for demonstrating the classification of the sensor data using the event recognition model which concerns on 2nd Embodiment. It is a table for demonstrating the classification of the sensor data using the event recognition model which concerns on 2nd Embodiment. It is a figure for demonstrating the new data group which appeared in the graph with respect to the 3rd Embodiment. It is a functional block diagram of the maintenance knowledge update device which concerns on 3rd Embodiment. It is a flowchart of the event recognition model update process which concerns on 3rd Embodiment. It is a screen block diagram of the update instruction screen which concerns on 3rd Embodiment. It is a functional block diagram of the maintenance knowledge update device which concerns on 4th Embodiment. It is a data structure diagram of the asset knowledge database which concerns on 4th Embodiment.

≪Overview of cause estimation system≫
The cause estimation system is a check item for confirming the relationship between an abnormal event of equipment or equipment (hereinafter, also simply referred to as equipment) and the failure that causes the abnormal event, and whether or not the failure and the failure have occurred. It is equipped with a common maintenance knowledge network (also referred to simply as a maintenance knowledge network) that shows the relationship between the two. A failure is a failure of a component constituting the equipment (hereinafter, also referred to as a failure mode).

The cause estimation system stores as a model table whether or not there is a component for each equipment model, and whether or not a failure mode has occurred in a component of a different type (model number) for the same component but for each model. Further, the common maintenance knowledge network is given a probability that a failure mode will occur and a probability that a check item for confirming whether or not the failure mode has occurred will be abnormal when the failure mode occurs. Therefore, the common maintenance knowledge network can be regarded as a Bayesian network for estimating the cause of an abnormal event.

The cause estimation system receives notifications of the occurrence of an abnormal event and the model of the equipment in which the abnormal event has occurred, and generates a maintenance knowledge network corresponding to the abnormal event and the model. Specifically, the cause estimation system has a check item for confirming the relationship between the abnormal event that has occurred and the failure that causes the abnormal event, and the failure that causes the abnormal event and whether or not the failure has occurred. Generate a maintenance knowledge network corresponding to an abnormal event that shows the relationship between. In other words, the cause estimation system extracts only the part related to the abnormal event that has occurred from the common maintenance knowledge network, and generates the maintenance knowledge network corresponding to the abnormal event.

Next, the cause estimation system removes from the maintenance knowledge network corresponding to the abnormal event the failure mode that does not occur in the component that the model does not have or the component of the type that the model has, and the maintenance knowledge corresponding to the model. Create a network. In other words, from the maintenance knowledge network corresponding to the abnormal event, the maintenance knowledge network corresponding to the model in which the abnormal event occurred is generated. This is a maintenance knowledge network that responds to abnormal events and models.

The cause estimation system accepts the normality / abnormality of the check items from the equipment maintenance personnel and estimates the failure of the component that causes the abnormal event using the probability calculation method of the Bayesian network (when the component is in the failure mode). Calculate a certain probability) and present it to the maintenance staff. In addition, the cause estimation system has a function of comparing the cause of the failure investigated by the maintenance personnel with the estimated cause, calculating the matching rate, and changing the common maintenance knowledge network and the probability information.

The cause estimation system is equipped with a common maintenance knowledge network for estimating the cause of abnormal events common to all models. Therefore, it is not necessary to create a maintenance knowledge network for each model, and the creation cost can be reduced. In addition, it has a model table, and it is possible to generate an abnormal event and a maintenance knowledge network corresponding to the model from the common maintenance knowledge network, and use this as a Bayesian network to estimate the cause of the abnormal event (component in failure mode). Will be.

When changing the component of a model or adding a model, it can be handled by updating the model table. Moreover, when reviewing the common maintenance knowledge network, it is not necessary to review each model. Therefore, the maintainability of the knowledge data (maintenance knowledge network including model-specific information and probability information) required for cause estimation is improved.

<< Configuration of cause estimation system >>
FIG. 1 is an overall configuration diagram of the cause estimation system 10 according to the first embodiment. The cause estimation system 10 includes a maintenance knowledge network generation device 100, a cause estimation device 200, and a maintenance knowledge update device 400 that can communicate with each other.

<< Maintenance knowledge Network generator configuration >>
FIG. 2 is a functional block diagram of the maintenance knowledge network generation device 100 according to the first embodiment. The maintenance knowledge network generation device 100 includes a control unit 110, a storage unit 120, a communication unit 130, and an input / output unit 140. The communication unit 130 transmits / receives communication data to / from other devices including the cause estimation device 300 and the maintenance knowledge update device 400. User interface devices such as a display, keyboard, and mouse are connected to the input / output unit 140.

The storage unit 120 is composed of storage devices such as ROM (Read Only Memory), RAM (Random Access Memory), and SSD (Solid State Drive). The maintenance knowledge database 121, the model specification database 122, the probability information database 123, and the program 128 are stored in the storage unit 120. The program 128 includes a description of the procedure of the maintenance knowledge network generation process corresponding to the abnormal event (see FIG. 10 described later) and the maintenance knowledge network generation process corresponding to the model (see FIG. 14 described later).

≪Maintenance knowledge network generator: Maintenance knowledge database≫
The maintenance knowledge database 121 includes a maintenance knowledge table 210 (see FIG. 3 described later), and stores maintenance knowledge such as a maintenance manual and an FT diagram (Fault Tree Diagram). FIG. 3 is a data structure diagram of the maintenance knowledge table 210 according to the first embodiment. The maintenance knowledge table 210 stores check items (inspection items) for determining an abnormal event, a cause of the abnormal event, and whether or not a causative event has occurred. The maintenance knowledge table 210 is tabular data, and one row (record) is an abnormal event 211, a functional failure 212, a component 213, and a component identification information 214 (described as a component ID (Identifier) in FIG. 3). Includes failure mode 215 and column (attribute) of check item 216.

Abnormal event 211 is a symptom of an abnormality that occurs in the equipment. The functional failure 212 is a functional failure that causes the abnormal event 211. The number of functional failures 212 that cause one abnormal event 211 is not limited to one.
Component 213 is a component of equipment in which a functional failure 212 occurs. The number of functional failures 212 that can occur in one component 213 is not limited to one. The component identification information 214 is the identification information of the component 213.

The failure mode 215 (also referred to simply as a failure) is a failure phenomenon of the component 213 in which the functional failure 212 occurs. The number of failure modes 215 that can cause one functional failure 212 is not limited to one.
Check item 216 (inspection item) is a place to check / inspect / confirm the equipment status such as sensor data, environment, and component status of the equipment. The content of the check item 216 is a phenomenon that can occur when a failure mode occurs, and is a place to check whether or not this phenomenon has occurred. The number of check items 216 corresponding to one failure mode 215 is not limited to one.

Functional failure and abnormal event, failure mode and functional failure, and failure mode and check items are the relationship between cause and effect (causal relationship). The maintenance knowledge network shows this relationship in the form of a network. The maintenance knowledge table 210 shows the maintenance knowledge network for all abnormal events and all models. The maintenance knowledge network related to all these abnormal events and models is also referred to as the common maintenance knowledge network. Further, FIG. 11 described later is a maintenance knowledge network limited to one abnormal event "temperature rise", and is a maintenance knowledge network corresponding to the abnormal event. In the maintenance knowledge network, the causative node is also referred to as a parent node, and the resulting node is also referred to as a child node.

≪Maintenance knowledge network generator: Model specification database≫
Returning to FIG. 2, the model specification database 122 stores maintenance knowledge depending on the model of the equipment. The model specification database 122 stores the model table 220 (see FIG. 4 described later) and the failure mode table 230 (see FIG. 5 described later).

FIG. 4 is a data configuration diagram of the model table 220 according to the first embodiment. The model table 220 shows the model number (type) of the component provided in the equipment for each model. The model table 220 is tabular data, and one row (record) includes component identification information 221 (described as component ID in FIG. 4), component 222, and columns (attributes) of models 223 to 225.

The component identification information 221 and the component 222 correspond to the component identification information 214 (see FIG. 3) and the component 213, respectively, and indicate the components. Models 223 to 225 indicate model numbers (types) of components included in model A, model B, and model C, respectively. For models that do not have components, it is set to "0". Regarding the component of the "heat exchanger" whose component identification information 221 is "C1", the model number is "C1-2" in the model A, and the model C is not installed.

FIG. 5 is a data configuration diagram of the failure mode table 230 according to the first embodiment. The failure mode table 230 shows the possibility of failure mode occurring in the components of each model number. The failure mode table 230 is tabular data, and one row (record) is component identification information 231 (denoted as component ID in FIG. 5), component 232, model number 233, and failure mode 234 to 236 (FIG. 5). 3 Includes columns (attributes) of failure mode 215).

The component identification information 231 and the component 232 correspond to the component identification information 214 (see FIG. 3) and the component 213, respectively, and indicate the components. Model number 233 is the model number of the component (see models 223 to 225 in FIG. 4).
In FIG. 5, failure modes 234 to 236 include “heat exchanger design failure” and the like, “1” means that a failure mode may occur, and “0” means that there is no possibility. For example, for the "heat exchanger" whose model number 233 is "C1-2", the heat exchanger is dirty or has a failure mode, but a design failure failure mode does not occur.

≪Maintenance knowledge network generator: Probability information database≫
Returning to FIG. 2, the probability information database 123 stores the probability information given to the maintenance knowledge network. The probability information database 123 stores a failure mode occurrence probability table 240 (see FIG. 6 below), a failure detection probability table 250 (see FIG. 7 below), and a child node abnormality occurrence probability table 260 (see FIG. 8 below). do.

FIG. 6 is a data configuration diagram of the failure mode occurrence probability table 240 according to the first embodiment. The failure mode occurrence probability table 240 stores the prior probability that the failure mode will occur. The failure mode occurrence probability table 240 is tabular data, and one row (record) includes columns (attributes) of failure mode 241 and state 242, and probability 243.

The failure mode 241 corresponds to the failure mode of the component (see the failure mode 215 shown in FIG. 3). "Y" in state 242 indicates that the component is in failure mode 241 (state) and "N" is not in failure mode 241 (state). The probability 243 indicates the probability (prior probability) of the state 242 of the failure mode 241. The failure mode occurrence probability table 240 shown in FIG. 6 shows that the probability of a heat exchanger design failure is 50%.

As the probability 243, as shown in FIG. 6, 50% may be set for each of the failure modes 241. Further, the probability may be calculated and set based on the actual data. For example, in the failure history, the number of occurrences of the failure mode may be divided by the total number to set the probability that the failure mode will occur (state 242 is "Y").

FIG. 7 is a data configuration diagram of the failure detection probability table 250 according to the first embodiment. The failure detection probability table 250 stores the probability that the child node is abnormal or normal when the state of the parent node occurs. The failure detection probability table 250 is tabular data, and one row (record) contains columns (attributes) of a parent node 251 and a parent node state 252, a child node 253, a child node state 254, and a probability 255. include.

The parent node state 252 indicates whether or not the failure mode that is the parent node 251 has occurred (“Y”) (“N”). The child node state 254 indicates whether the check item (see the check item 216 shown in FIG. 3), which is the child node 253, is “normal” or “abnormal”. The probability 255 indicates the probability that the child node 253 is in the child node state 254 when the parent node 251 is in the parent node state 252.

As for the probability 255, as shown in FIG. 7, when the failure mode that is the parent node occurs (the state of the node in the failure mode that is the parent node is the failure mode), the check item of the child node becomes abnormal. The probability (the state of the node of the check item that is a child node is abnormal) may be set to 100%, and the probability of becoming normal may be set to 0%. Further, the probability may be calculated and set based on the actual data. For example, the history of occurrence of the failure mode that becomes the parent node 251 may be extracted from the failure history, and the number of abnormal / normal check items in the child node may be divided by the number of extracted history to set.

FIG. 8 is a data configuration diagram of the child node abnormality occurrence probability table 260 according to the first embodiment. The child node abnormality occurrence probability table 260 stores the probability that the child node (check item) is abnormal / normal when no abnormality has occurred in the parent node (failure mode). The child node abnormality occurrence probability table 260 is tabular data, and one row (record) includes a child node 261 and a child node state 262, and a column (attribute) of the probability 263.
The child node state 262 indicates the state (normal / abnormal) of the child node 261. The probability 263 indicates the probability that the child node 261 is in the child node state 262.

As the probability 263, as shown in FIG. 8, for each child node 261 (check item), the probability of becoming abnormal may be set to 0%, and the probability of becoming abnormal may be set to 100%. Further, the probability may be calculated and set based on the actual data. For example, from the failure history, the history in which the failure mode that is the parent node 251 (see FIG. 7) has not occurred is extracted, and the number of abnormal / normal check items in the child node is divided by the number of extracted history and set. You may.

≪Maintenance knowledge network generator: network generator≫
Returning to FIG. 2, the control unit 110 includes a network generation unit 111. The network generation unit 111 receives the matter information (see FIG. 9 to be described later) and generates a maintenance knowledge network (see FIG. 11 to be described later) corresponding to the abnormal event included in the matter information (see FIG. 10 to be described later). Subsequently, the network generation unit 111 generates a maintenance knowledge network corresponding to the model included in the matter information from the maintenance knowledge network corresponding to the abnormal event (see FIG. 14 described later). The maintenance knowledge network corresponding to the model also corresponds to the abnormal event, and is the maintenance knowledge network corresponding to the abnormal event and the model.

≪Maintenance knowledge network generator: Maintenance knowledge network generation process corresponding to abnormal events≫
FIG. 9 is a data structure diagram of the project information 500 according to the first embodiment. The matter information 500 includes identification information of the matter information 500 (described as a matter ID in FIG. 9), an abnormal event, and a model of equipment in which the abnormal event has occurred.

FIG. 10 is a flowchart of the maintenance knowledge network generation process corresponding to the abnormal event according to the first embodiment. Every time the matter information 500 is received, the network generation unit 111 executes the maintenance knowledge network generation process corresponding to the abnormal event included in the matter information 500, and generates the maintenance knowledge network corresponding to the abnormal event included in the matter information. In other words, the network generation unit 111 has an abnormal event included in the matter information 500 from the maintenance knowledge (common maintenance knowledge network, see the maintenance knowledge table 210 shown in FIG. 3) related to each abnormal event stored in the storage unit 120. Extract the maintenance knowledge network corresponding to.

In step S101, the network generation unit 111 receives the matter information 500 (see FIG. 9). The matter information 500 may be input by a maintenance worker from a user interface device connected to the input / output unit 140 (see FIG. 2), or may be received by the communication unit 130 as communication data.
In step S102, the network generation unit 111 generates network identification information (described as a network ID in FIG. 10) to be allocated to the maintenance knowledge network corresponding to the abnormal event to be generated from now on.
In step S103, the network generation unit 111 generates the maintenance knowledge network 510 (see FIG. 11 described later) corresponding to the abnormal event included in the matter information 500. Hereinafter, the generation procedure will be described while explaining the maintenance knowledge network 510.

FIG. 11 is a diagram showing a configuration of a maintenance knowledge network 510 corresponding to an abnormal event according to the first embodiment. The maintenance knowledge network 510 (hereinafter, also simply referred to as the maintenance knowledge network 510) corresponding to this abnormal event includes an abnormal event of the equipment (see the abnormal event 211 shown in FIG. 3) and a failure of a component provided in the equipment (see the failure mode 215). ), And the relationship between the failure and the check item (see check item 216) for confirming whether or not the failure has occurred. The maintenance knowledge table 210 (see FIG. 3) shows the maintenance knowledge network (common maintenance knowledge network) for all abnormal events, while the maintenance knowledge network 510 shows the maintenance corresponding to the abnormal events shown in the matter information 500. It is a knowledge network. Specifically, the maintenance knowledge network 510 includes four node groups 511 to 514.

The node group 511 includes a node of an abnormal event. The abnormal event included in the matter information 500 (see FIG. 9) is "temperature rise", and the node group 511 includes only the node of "temperature rise". When the matter information includes a plurality of abnormal events, the node group 511 includes the nodes of the plurality of abnormal events. The network generation unit 111 searches for and acquires the abnormal event 211 included in the matter information 500 by searching for the abnormal event 211 in the maintenance knowledge table 210 (see FIG. 3), and uses it as the node for the abnormal event in the maintenance knowledge network 510.

The node group 512 includes a node with a functional failure. A functional failure is the cause of an abnormal event, and is connected by an arrow (directed link) from the node (parent node) of the abnormal event to the node (child node) of the abnormal event. There may be multiple functional failures of the parent node whose child node is the node of one abnormal event. The network generation unit 111 searches the maintenance knowledge table 210 (see FIG. 3) for a record in which the abnormal event 211 is a child node (node of the abnormal event), and determines the functional failure 212 included in the record as a functional failure. Let it be a node. Even if the same functional failure is included in a plurality of records, only one node is used for the functional failure.

The node group 513 includes a node in a failure mode. The failure mode is the cause of the functional failure and is connected by an arrow pointing from the node (parent node) of the failure mode to the node (child node) of the functional failure. There may be a plurality of failure modes of a parent node having one functional failure node as a child node. The network generation unit 111 searches the maintenance knowledge table 210 (see FIG. 3) for a record in which the functional failure 212 is a child node (functional failure node), and sets the failure mode 215 included in the record to the failure mode. Let it be a node. Even if the same failure mode is included in a plurality of records, the number of nodes in the failure mode is one.

The node group 514 includes the node of the check item. The check items are the result of the failure mode, and are connected by an arrow from the node (parent node) of the failure mode to the node (child node) of the check item. There may be multiple failure modes of the parent node whose child node is the node of one check item. There may be multiple check items for a child node whose parent node is a node in one failure mode. The network generation unit 111 searches for a record in which the failure mode 215 is the parent node (failure mode node) in the maintenance knowledge table 210 (see FIG. 3), and checks the check item 216 included in the record as a check item. Let it be a node. Even if the same check item is included in a plurality of records, the number of check item nodes is one.

For each node, the status of the node, for example, whether or not a failure mode has occurred and whether the check items are normal / abnormal can be set. At the moment, it is set that the event has occurred only for the node of the abnormal event (see the double strikethrough of "No" included in the node of temperature rise).

Returning to FIG. 10, in step S104, the network generation unit 111 generates the network configuration information of the maintenance knowledge network 510. The network configuration information includes a node information table 520 (see FIG. 12 below) and a link information table 530 (see FIG. 13 below).

FIG. 12 is a data configuration diagram of the node information table 520 according to the first embodiment. The node information table 520 stores information related to the nodes constituting the maintenance knowledge network 510 (see FIG. 11). The node information table 520 is tabular data, and one row (record) includes node information 521, type 522, component identification information 523, and a column (attribute) of state 524.

The node information 521 is the content (name, label) of the node. Type 522 is a node type and is any one of "abnormal event", "functional failure", "failure mode", and "check item". The component identification information 523 indicates identification information (see component identification information 214 in FIG. 3) of the component in which the failure mode has occurred when the type 522 is "functional failure" or "failure mode". The state 524 indicates the state of the node, and indicates, for example, whether the check item is "normal" or "abnormal".

FIG. 13 is a data structure diagram of the link information table 530 according to the first embodiment. The link information table 530 stores information related to links (arrows, directed links) constituting the maintenance knowledge network 510. The link information table 530 is tabular data, and one row (record) shows a link having a parent node 531 as a parent node and a child node 532 as a child node.

The maintenance knowledge table 210 shown in FIG. 3 shows a shared maintenance knowledge network including various abnormal events 211. On the other hand, the node information table 520 shown in FIG. 12 and the link information table 530 shown in FIG. 13 show a maintenance knowledge network corresponding to the abnormal event that has occurred shown in the matter information 500 (see FIG. 9).

As described above, in the maintenance knowledge network generation process corresponding to the abnormal event, the received abnormal event (case information 500 shown in FIG. 9) is referred to with reference to the common maintenance knowledge network (maintenance knowledge table 210 shown in FIG. 3). (Refer to), the failure of the component related to the abnormal event (see the abnormal event 211) (see the failure mode 215) and the check item for confirming whether or not the failure has occurred (see the check item 216) are specified. , Generate a maintenance knowledge network corresponding to abnormal events.

In FIG. 10, after the network generation unit 111 generates the maintenance knowledge network 510 (see FIG. 11) corresponding to the abnormal event in step S103, the network configuration information of the maintenance knowledge network 510 corresponding to this abnormal event is generated in step S104. Generate. The network generation unit 111 may execute steps S103 and S104 in parallel. Specifically, each time a node is added to the maintenance knowledge network 510, the network generation unit 111 adds a record of node information corresponding to the node information table 520 and link information with an existing node to the link information table 530. You may do so.

≪Maintenance knowledge network generator: Maintenance knowledge network generation process corresponding to the model≫
FIG. 14 is a flowchart of the maintenance knowledge network generation process corresponding to the model according to the first embodiment. A process of changing (updating) the maintenance knowledge network 510 corresponding to the abnormal event common to all models to the maintenance knowledge network corresponding to the model in which the abnormal event has occurred will be described with reference to FIG. Since the maintenance knowledge network corresponding to this (abnormal event occurred) model also corresponds to the abnormal event, it is also referred to as the maintenance knowledge network corresponding to the abnormal event and the model.

As shown in the model table 220 (see Fig. 4), the equipment is not equipped with components depending on the model. Further, as shown in the failure mode table 230 (see FIG. 5), the failure mode may not occur in the component depending on the type (model number) of the component. The network generation unit 111 refers to the model information of the matter information 500 (see FIG. 9) and changes to the maintenance knowledge network corresponding to the model.

In step S131, the network generation unit 111 starts the process of executing steps S132 to S137 for each functional failure node included in the node group 512 (see FIG. 11).
In step S132, the network generation unit 111 determines whether or not the model has a component that causes a functional failure. If the network generation unit 111 is provided (step S132 → yes), it proceeds to step S134, and if it is not provided (step S132 → no), it proceeds to step S133. The component in which the functional failure occurs can be obtained by referring to the component identification information 214 of the record in which the functional failure 212 is the functional failure in the record of the maintenance knowledge table 210 (see FIG. 3). Further, whether or not the model has a component can be determined by referring to the model table 220 (see FIG. 4).

In step S133, the network generation unit 111 deletes the information related to the node of the functional failure and the node of the failure mode which is the parent node of the node of the functional failure from the node information table 520. Further, the network generation unit 111 deletes the link information related to the deleted node from the link information table 530.
In step S134, the network generation unit 111 starts the process of executing steps S135 to S136 for each failed node that is the parent node of the functionally failed node. If the node with the functional failure is deleted in step S133, the processes of steps S134 to S137 will not be executed.

In step S135, the network generation unit 111 determines whether or not a failure mode occurs in the component of the model number provided in the model. The network generation unit 111 proceeds to step S137 if it occurs (step S135 → yes), and proceeds to step S136 if it does not occur (step S135 → no). Whether or not a failure mode occurs can be determined by referring to the failure modes 234 to 236 in the record of the model number of the component provided in the model with the model number 233 in the record of the failure mode table 230 (see FIG. 5).

In step S136, the network generation unit 111 deletes the information related to the node in the failure mode from the node information table 520. Further, the network generation unit 111 deletes the link information related to the deleted node from the link information table 530.
In step S137, if the network generation unit 111 executes the processes of steps S135 to S136 for all the failure mode nodes that are the parent nodes of the functional failure nodes, the process proceeds to step S138. If there is an unprocessed failure mode node, the network generation unit 111 executes the processing of steps S135 to S136 for the failure mode node.

In step S138, if the network generation unit 111 executes the processes of steps S132 to S137 for all the functionally failed nodes included in the node group 512 (see FIG. 11), the process proceeds to step S139. If there is an unprocessed functional failure node, the network generation unit 111 executes the processing of steps S132 to S137 for the functional failure node.
As described above, in steps S131 to S138, the network generation unit 111 refers to the model table 220 (see FIG. 4) and specifies the type of the component provided in the model of the equipment from the received equipment model. Then, with reference to the failure mode table 230 (see FIG. 5), a failure (see failure modes 234 to 236) that does not include an association with the specified component type can be detected from the maintenance knowledge network corresponding to the abnormal event. Remove.

In step S139, the network generation unit 111 deletes the node of the functional failure or the failure mode, and deletes the information related to the node of the check item that is not linked from the node information table 520. In other words, the check items (unlinked check items) that are different from the check items for confirming the occurrence of the failure (failure mode) that remains without being removed are further removed, and the abnormal event and the relevant item are removed. Generate a maintenance knowledge network corresponding to the model of equipment.

At this point, the node information table 520 and the link information table 530 indicate the maintenance knowledge network corresponding to the model in which the abnormal event has occurred. The node information table 520 and the link information table 530 before the start of this process show the maintenance knowledge network corresponding to the abnormal event shown in the matter information 500. The component mounted on the model shown in the case information 500 and the result of extracting the failure occurring in the component are the maintenance knowledge network corresponding to the model. The node information table 520 and the link information table 530 at the end of step S139 indicate the maintenance knowledge network corresponding to this model, and indicate the abnormal event and the maintenance knowledge network corresponding to the model.

In step S140, the network generation unit 111 selects related records from the failure mode occurrence probability table 240 (see FIG. 6), the failure detection probability table 250 (see FIG. 7), and the child node abnormality occurrence probability table 260 (see FIG. 8). get. Specifically, the network generation unit 111 acquires a record of the failure mode occurrence probability table 240 in which the failure mode 241 is included in the failure mode remaining without being deleted in the node information table 520. Further, the network generation unit 111 is a record of the failure detection probability table 250, in which the parent node 251 is included in the failure mode remaining without being deleted, and the child node 253 is a check item remaining without being deleted. Get the records included. Further, the network generation unit 111 acquires the record included in the check items remaining without being deleted by the child node 261 in the record of the child node abnormality occurrence probability table 260.

In step S141, the network generation unit 111 generated the matter information 500 (see FIG. 9), the maintenance knowledge network corresponding to the abnormal event and the model, the probability information acquired in step S140, and step S102 (see FIG. 10). The network identification information is transmitted to the cause estimation device 300.

The maintenance knowledge network corresponding to the abnormal event and the model is the maintenance knowledge network shown in the node information table 520 (see FIG. 12) and the link information table 530 (see FIG. 13). This maintenance knowledge network is a maintenance knowledge network corresponding to the abnormal event shown in the case information 500 and further corresponding to the model shown in the case information 500. Further, by adding probability information, this maintenance knowledge network becomes a Bayesian network.

≪Characteristics of maintenance knowledge network generator≫
The maintenance knowledge table 210 (see FIG. 3, common maintenance knowledge network) stores failure modes and functional failures, functional failures and abnormal events, and the causal relationship between failure modes and check items as model-independent maintenance knowledge. To. The network generation unit 111 refers to the maintenance knowledge table 210 and generates a maintenance knowledge network common to all models corresponding to the abnormal events included in the received matter information 500 (see FIG. 9) (see FIG. 10).

The model number of the component provided in the model is stored in the model table 220 (see FIG. 4). The failure mode table 230 (see FIG. 5) stores the failure modes that occur in the components for each model number. The network generation unit 111 refers to the model table 220 and the failure mode table 230, and supports the model included in the matter information 500 while deleting the node and the link from the maintenance knowledge network common to all models corresponding to the generated abnormal event. Generate a maintenance knowledge network. This maintenance knowledge network is a maintenance knowledge network corresponding to abnormal events and models.

The failure mode occurrence probability table 240 (see FIG. 6) stores the prior probability that the failure mode will occur. The failure detection probability table 250 (see FIG. 7) stores the probability that the child node is abnormal or normal when the state of the parent node occurs. The child node abnormality occurrence probability table 260 (see FIG. 8) stores the probability that the child node (check item) is abnormal / normal when no abnormality has occurred in the parent node (failure mode). The network generation unit 111 acquires the probability information related to the maintenance knowledge network corresponding to the model from the failure mode occurrence probability table 240, the failure detection probability table 250, and the child node abnormality occurrence probability table 260, and converts them into abnormal events and models. It is transmitted to the cause estimation device 300 (see FIG. 1) together with the corresponding maintenance knowledge network.

Since the maintenance knowledge network generator 100 includes a common maintenance knowledge network for estimating the cause of an abnormal event common to all models, it is necessary to prepare maintenance knowledge (maintenance knowledge table 210) which is the basis of the maintenance knowledge network for each model. There is no. Therefore, the maintenance personnel can reduce the cost of preparing the maintenance knowledge. When changing the components of a model or adding a model, it becomes possible to handle it by updating the model table 220 (see FIG. 4). Moreover, when reviewing the maintenance knowledge network, it is not necessary to review each model. Therefore, the maintainability of the knowledge data required for cause estimation is improved.

≪Overview of cause estimation device≫
The cause estimation device 300 (see FIG. 1) receives the maintenance knowledge network corresponding to the model to which the probability information is given from the maintenance knowledge network generation device 100. The cause estimation device 300 estimates the cause of the abnormal event by acquiring the state (normal / abnormal) of the check items included in the maintenance knowledge network from the maintenance personnel and calculating the probability of occurrence of the failure mode of the component.

<< Configuration of cause estimation device >>
FIG. 15 is a functional block diagram of the cause estimation device 300 according to the first embodiment. The cause estimation device 300 includes a control unit 310, a storage unit 320, a communication unit 330, and an input / output unit 340. The communication unit 330 transmits / receives communication data to / from other devices including the maintenance knowledge network generation device 100 and the maintenance knowledge update device 400. User interface devices such as a display, keyboard, and mouse are connected to the input / output unit 340.

The storage unit 320 is composed of storage devices such as ROM, RAM, and SSD. The maintenance knowledge network database 350 and the program 328 are stored in the storage unit 320. The program 328 includes a description of the procedure of the cause estimation process (see FIG. 16 described later). The maintenance knowledge network database 350 stores the matter information received from the maintenance knowledge network generator 100, the maintenance knowledge network corresponding to the abnormal event and the model included in the matter information, the probability information related to the maintenance knowledge network, and the network identification information. Will be done.

In the following description, the description will be continued on the premise (assuming) that the maintenance knowledge network 510 (see FIG. 11) is output from the maintenance knowledge network generator 100. This premise is a premise for explaining the cause estimation device 300 with reference to FIG.
Specifically, in the maintenance knowledge network generation process corresponding to the model (see FIG. 14), it is premised that all the components are installed in the received model and the failure mode occurs in the component. Because of this premise, the node is not removed in the maintenance knowledge network generation process corresponding to the model, and the maintenance knowledge network 510 corresponding to the abnormal event becomes the maintenance knowledge network corresponding to the abnormal event and the model. The maintenance knowledge network 510 in the maintenance knowledge network database 350 is given the probability information acquired in step S140 (see FIG. 14), and can be regarded as a Bayesian network.

The control unit 310 includes a probability calculation unit 311, a cause estimation unit 312, an estimation result display unit 313, and a check result acquisition unit 314. The probability calculation unit 311 calculates the probability of the Bayesian network. Specifically, the probability calculation unit 311 refers to the network configuration information (see step S139 in FIG. 14) and the probability information (see step S140) of the maintenance knowledge network 510 stored in the maintenance knowledge network database 350, and refers to the Basian network. Calculate the probability of the node of.

The cause estimation unit 312 inquires of the maintenance personnel and acquires the status (normal / abnormal) of the chuck items included in the node group 514 of the maintenance knowledge network 510. Subsequently, the cause estimation unit 312 requests the probability calculation unit 311 to acquire the probability of occurrence of the failure mode.
The estimation result display unit 313 displays an estimation result display screen 620 (see FIG. 18 described later) including a maintenance knowledge network in which the display state of the node is changed according to the occurrence probability of the failure mode.
The check result acquisition unit 314 acquires the cause failure mode selected by the maintenance personnel and transmits it to the maintenance knowledge update device 400 (see FIG. 1).

<< Cause estimation device: Cause estimation processing >>
FIG. 16 is a flowchart of the cause estimation process according to the first embodiment.
In step S201, the cause estimation unit 312 acquires the check items of the maintenance knowledge network in the maintenance knowledge network database 350. Subsequently, the cause estimation unit 312 displays a check item on the display connected to the input / output unit 340, and prompts the maintenance personnel to check the check item and input the result. The maintenance personnel check (inspect, inspect) the sensor data and component status in the check items, and input the results.

In step S202, the cause estimation unit 312 acquires the check result input by the maintenance personnel.
In step S203, the cause estimation unit 312 sets the probability of the check item from the check result and generates a Bayesian network for cause estimation. For example, when the data of the "sensor 1" shows an abnormal value, the cause estimation unit 312 sets the probability of the "abnormal" state in the node information of the sensor 1 (see the node information table 520 shown in FIG. 12) to 100%. The probability of the "normal" state is set to 0%.

In step S204, the cause estimation unit 312 requests the probability calculation unit 311 to acquire the probability of failure occurrence (state 524 is “Y”) in the node in the failure mode (see the node information table 520 described in FIG. 12). The probability calculation unit 311 calculates the probability of the node in the failure mode, and outputs the calculation result in the form of the calculation result table 610 (see FIG. 17 described later). Further, the cause estimation unit 312 allocates the estimation result identification information to the check result and the calculation result table 610 acquired in step S202.

FIG. 17 is a data configuration diagram of the failure mode calculation result table 610 according to the first embodiment. The calculation result table 610 is tabular data, and one row shows the probability of each state of the node and includes columns (attributes) of failure mode 611, state 612, and probability 613. The failure mode 611 and the state 612 correspond to the node information 521 and the state 524 whose type 522 in the node information table 520 (see FIG. 12) is the "failure mode", respectively. The probability 613 indicates the probability that the failure mode 611 is in the state 612.

Returning to FIG. 16, in step S205, the estimation result display unit 313 displays the maintenance knowledge network on the estimation result display screen 620 (see FIG. 18 described later) according to the probability of the calculation result.
FIG. 18 is a screen configuration diagram of the estimation result display screen 620 according to the first embodiment. In the center of the estimation result display screen 620, a network substantially similar to the maintenance knowledge network 510 (see FIG. 11) is displayed. The difference from the maintenance knowledge network 510 will be described below.
In the node of the check item, the result of the check input by the maintenance personnel (see step S202 in FIG. 16) is displayed. Specifically, if the result is normal, the abnormality among the "normal / abnormal" of the node is erased by the double strikethrough, and if the result is abnormal, the normal among the "normal / abnormal" is erased. In addition, the node of the check item that was abnormal is highlighted (in FIG. 18, the node is hatched and described).

In the node of the failure mode, the node is highlighted based on the calculation result of the probability of the failure mode (see FIG. 17). More specifically, the higher the failure mode occurrence probability (probability 613 of the record in which the state 612 is "Y" in the calculation result table 610 shown in FIG. 17), the more conspicuously the highlight is displayed. In addition, nodes with functional failures that have a high probability of failure are also highlighted.

The maintenance worker selects the failure mode that he / she considers to be the cause of the abnormal event, and presses the selection button 621 arranged at the node of the failure mode. Instead of the selection button 621, the "selection result input" button 622 arranged at the lower side of the estimation result display screen 620 may be pressed, and the failure mode may be input from the displayed selection result input screen (not shown). .. The failure mode selected by the maintenance personnel is not limited to one, and may be multiple.

Returning to FIG. 16, in step S206, the check result acquisition unit 314 acquires the failure mode selected by the maintenance personnel. Next, the check result acquisition unit 314, along with the selected failure mode, sets the matter information, the maintenance knowledge network corresponding to the abnormal event and the model stored in the maintenance knowledge network database 350 (see FIG. 15), and the maintenance knowledge network. The probability information, the network identification information, the check result acquired in step S202, the calculation result table 610 (see FIG. 17), and the estimation result identification information are transmitted to the maintenance knowledge update device 400. The maintenance knowledge update device 400 includes case information, a selected failure mode, a maintenance knowledge network corresponding to an abnormal event and a model, probability information related to the maintenance knowledge network, network identification information, check results, calculation result table 610, and estimation. The result identification information is stored in the maintenance work report database 450 (see FIG. 19 described later).

≪Characteristics of cause estimation device≫
The cause estimation device 300 acquires the check results of the check items included in the maintenance knowledge network corresponding to the abnormal event and the model. Next, the cause estimation device 300 calculates the probability of the node in the failure mode by using the acquired check result and the maintenance knowledge network as the Bayesian network. On the estimation result display screen 620 (see FIG. 18), the cause estimation device 300 emphasizes and displays the node having the higher probability of the calculation result among the nodes of the maintenance knowledge network.
By looking at the estimation result display screen 620, the maintenance personnel can confirm which failure mode has a high probability of failure. In addition, the maintenance personnel can understand what kind of functional failure has occurred and led to an abnormal event due to the occurrence of the failure mode.

≪Overview of maintenance knowledge updater≫
The maintenance knowledge update device 400 (see FIG. 1) was acquired from the cause estimation device 300 as a Bayesian network in the maintenance knowledge network corresponding to the abnormal event (provided with probability information) and the model, or in step S202 (see FIG. 16). The state of the check item, the calculated probability (calculation result table 610 shown in FIG. 17), and the like are received. The maintenance knowledge update device 400 acquires a determined cause (which component had what failure (failure mode)) from the maintenance personnel who investigated the cause of the abnormal event. The maintenance knowledge update device 400 compares the cause estimated at a predetermined timing with the confirmed cause, displays the update instruction screen 640 (see FIG. 21 described later), and accepts the update instruction of maintenance knowledge and probability information. , Perform the update.

<< Configuration of maintenance knowledge updater >>
FIG. 19 is a functional block diagram of the maintenance knowledge updating device 400 according to the first embodiment. The maintenance knowledge update device 400 includes a control unit 410, a storage unit 420, a communication unit 430, and an input / output unit 440. The communication unit 430 transmits / receives communication data to / from other devices including the maintenance knowledge network generation device 100 and the cause estimation device 300. User interface devices such as a display, keyboard, and mouse are connected to the input / output unit 440.

The storage unit 420 is composed of storage devices such as ROM, RAM, and SSD. The maintenance work report database 450 and the program 428 are stored in the storage unit 420. The program 428 includes a description of the procedure of the maintenance knowledge update process (see FIG. 25 described later). In the maintenance work report database 450, case information, maintenance knowledge network corresponding to abnormal events and models, network identification information, probability information given to the maintenance knowledge network corresponding to abnormal events and models as a Basian network, and maintenance personnel are input. The check result, the probability information calculated from the check result and the Basian network (see FIG. 17), the estimation result identification information, and the failure mode selected as the cause by the maintenance personnel are associated and stored (step shown in FIG. 16). See S206). The maintenance work report database 450 stores the cause of the abnormality acquired by the abnormality cause acquisition unit 411, which will be described later.

The control unit 410 includes an abnormality cause acquisition unit 411, an update detection unit 412, an update instruction reception unit 413, and an update execution unit 414. In the abnormality cause acquisition unit 411, the maintenance personnel perform maintenance work, acquire the finally confirmed (finally confirmed) abnormality cause, and associate it with the case information, the estimation result identification information, etc., and add it to the maintenance work report database 450. save.
The update detection unit 412 monitors the data in the maintenance work report database 450 for a predetermined length of time, compares the cause (failure mode) estimated by the cause estimation device 300 with the finally confirmed abnormal cause, and evaluates the estimation result. Generate table 630 (see Figure 20 below). The update detection unit 412 calculates the match rate (the rate at which the result 635 is "match" in the estimation result evaluation table 630) and outputs it to the update instruction reception unit 413 described later.

FIG. 20 is a data structure diagram of the estimation result evaluation table 630 according to the first embodiment. The estimation result evaluation table 630 is for comparing the cause (failure mode) of the abnormal event generated for each matter information and the abnormal event estimated using the maintenance knowledge network corresponding to the model with the finally confirmed cause. It is data. The estimation result evaluation table 630 is tabular data, and one row (record) includes network identification information 631, estimation result identification information 632 (described as estimation result ID in FIG. 20), estimation cause 633, and final confirmation. Includes columns (attributes) for cause 634 and result 635.

The network identification information 631 is identification information (see step S102 in FIG. 10) allocated to the maintenance knowledge network corresponding to the abnormal event and the model. The network identification information 631 is identification information stored in the maintenance work report database 450 for a predetermined length of time.
The estimation result identification information 632 is the estimation result identification information stored in association with the network identification information 631 in the maintenance work report database 450. The estimation result identification information 632 is identification information (see step S204 in FIG. 16) assigned to the probability calculation result of the failure mode that causes the abnormal event estimated by the cause estimation device 300.

The probable cause 633 is the failure mode 611 in which the state 612 is "Y" and the probability 613 is the maximum in the calculation result table 610 (see FIG. 17) associated with the estimation result identification information 632 in the maintenance work report database 450. be.
The final confirmed cause 634 is the final confirmed abnormality cause (see the abnormality cause acquisition unit 411 shown in FIG. 19) associated with the estimation result identification information 632 in the maintenance work report database 450.
The result 635 indicates whether or not the probable cause 633 and the final confirmed cause 634 match. When the result 635 is "match", it means that the estimation of the cause estimation device 300 is correct, and the network configuration of the maintenance knowledge network as a Bayesian network and the given probability information are appropriate.

Returning to FIG. 19, the update instruction receiving unit 413 displays the update instruction screen 640 (see FIG. 21 described later) including the estimation result evaluation table 630 (see FIG. 20), and receives the update instruction from the maintenance personnel. It is desirable that the maintenance personnel who issue renewal instructions are veteran maintenance personnel who are familiar with the equipment.

FIG. 21 is a screen configuration diagram of the update instruction screen 640 according to the first embodiment. On the update instruction screen 640, the match rate and the estimation result evaluation table 630 are displayed. When the "History display" button is pressed, the estimation result is displayed. The estimation result is information related to the probability calculation of the Bayesian network including the check result acquired in step S202 (see FIG. 16) and the calculation result table 610 (see FIG. 17).

When the "Maintenance knowledge display" button is pressed, the maintenance knowledge including the maintenance knowledge table 210 (see FIG. 3) is displayed. When the "model specification display" button is pressed, specification information for each model including the model table 220 (see FIG. 4) and the failure mode table 230 (see FIG. 5) is displayed. When the "Probability information display" button is pressed, the probability of including the failure mode occurrence probability table 240 (see FIG. 6), the failure detection probability table 250 (see FIG. 7), and the child node abnormality occurrence probability table 260 (see FIG. 8). Information is displayed.

(Veteran) maintenance personnel consider the updated contents while looking at maintenance knowledge, specification information for each model, and probability information. When updating the maintenance knowledge, the maintenance personnel press the "maintenance knowledge update" button and input the update instruction content on the displayed maintenance knowledge update screen (not shown). When updating the specification information for each model, the maintenance staff presses the "update model specification" button and inputs the update instruction content on the displayed model specification update screen (not shown). When updating the probability information, the maintenance worker presses the "probability information update" button and inputs the update instruction content on the displayed probability information update screen (not shown).

When the "renewal request" button is pressed, a renewal request including the content of the renewal instruction is sent to the approver such as the administrator. When the approver approves the renewal request, the renewal included in the renewal instruction content is executed. For probability information updates, the update is performed without approval.
Returning to FIG. 19, the update instruction receiving unit 413 outputs the update instruction content input and approved by the maintenance personnel to the update execution unit 414. Hereinafter, the format of the update instruction content for each of maintenance knowledge, model specifications, and probability information will be described.

FIG. 22 is a data configuration diagram of the maintenance knowledge update instruction content 650 according to the first embodiment. The update instruction content 650 includes the update instruction content of the maintenance knowledge table 210 (see FIG. 3). The update instruction content 650 is tabular data, and one row (record) includes columns (attributes) of process 651, position 652, and content 653.
The process 651 indicates the type of process, and includes "addition", "update", and "deletion". The position 652 indicates the position to be updated in the maintenance knowledge table 210. The content 653 is a content to be added when the process 651 is "addition", and a content to be updated (rewritten) when the process 651 is "update".

The record for which the process 651 is "addition" indicates the update to add the record to the first row of the maintenance knowledge table 210. The abnormal event 211, functional failure 212, component 213, component identification information 214, failure mode 215, and check item 216 of the record are "temperature rise", "insufficient heat exchanger capacity", "heat exchanger", and "heat exchanger", respectively. "C1", "heat exchanger design failure" and "appearance damage status".

FIG. 23 is a data configuration diagram of the update instruction content 660 of the model specification according to the first embodiment. The update instruction content 660 includes the update instruction content of the model table 220 (see FIG. 4) or the failure mode table 230 (see FIG. 5). The update instruction content 660 is tabular data, and one row (record) includes a process 661, a table 662, a position 663, and a column (attribute) of the content 664. Table 662 indicates a table to be updated, and is a "model" indicating a model table 220 or a "failure mode" indicating a failure mode table 230. The process 661, the position 663, and the content 664 are the same as the process 651, the position 652, and the content 653 of the update instruction content 650 (see FIG. 22), respectively.

FIG. 24 is a data configuration diagram of the probability information update instruction content 670 according to the first embodiment. The update instruction content 670 uses data used for updating the failure mode occurrence probability table 240 (see FIG. 6), the failure detection probability table 250 (see FIG. 7), or the child node abnormality occurrence probability table 260 (see FIG. 8). show. The update execution unit 414, which will be described later, updates the failure mode occurrence probability table 240, the failure detection probability table 250, or the child node abnormality occurrence probability table 260 based on the indicated data.

The update instruction content 670 is tabular data, and one row (record) is selection 671, network identification information 672 (described as network ID in FIG. 24), and estimation result identification information 673 (estimation result in FIG. 24). ID), probable cause 674, final confirmed cause 675, and result 676 columns (attributes). The network identification information 672, the estimation result identification information 673, the estimation cause 674, the final confirmed cause 675, and the result 676 are the network identification information 631 in the estimation result evaluation table 630 (see FIG. 20), the estimation result identification information 632, and the estimation cause 633. , Final confirmed cause 634, and result 635, respectively. Selection 671 indicates whether or not the record is used for updating (“Y”) (“N”).

Returning to FIG. 19, the update execution unit 414 has a maintenance knowledge table 210 (see FIG. 3), a model table 220 (see FIG. 4), and a failure mode table 230 (see FIG. 5) based on the update instruction contents 650, 660, and 670. ), The failure mode occurrence probability table 240 (see FIG. 6), the failure detection probability table 250 (see FIG. 7), or the child node abnormality occurrence probability table 260 (see FIG. 8) is updated. The update execution unit 414 updates the maintenance knowledge table 210, the model table 220, and the failure mode table 230 based on the instructions in the update instruction contents 650 and 660 directly. The update execution unit 414, for example, adds a row in the table or updates the contents of the item shown at the position 652,663.

The update execution unit 414 updates the failure mode occurrence probability table 240, the failure detection probability table 250, or the child node abnormality occurrence probability table 260 according to the record in which the selection 671 is "Y" in the record of the update instruction content 670. The update execution unit 414 updates, for example, so that the relationship shown by the record in the failure detection probability table 250 (see FIG. 7) matches the relationship shown by the selected record. Here, the relationship shown by the record in the failure detection probability table 250 is a causal relationship between the failure mode and the check item shown in the record having a high probability 255. The relationship indicated by the selected record is the relationship between the failure mode (final confirmed cause 675) related to the record and the check item that is abnormal (see step S202 in FIG. 16), and the check item is determined by the final confirmed cause 675. It is a causal relationship that the abnormality of. The update execution unit 414 may update the probability information based on the selected record, for example, by using a method of Bayesian update.

FIG. 25 is a flowchart of the update process performed by the update execution unit 414 according to the first embodiment.
In step S301, the update execution unit 414 proceeds to step S302 if the update instruction content is an instruction to update the probability information (step S301 → YES), and proceeds to step S303 if the update instruction content is not probability information (step S301 → NO). The probability information is a failure mode occurrence probability table 240 (see FIG. 6), a failure detection probability table 250 (see FIG. 7), or a child node abnormality occurrence probability table 260 (see FIG. 8).
In step S302, the update execution unit 414 updates the probability information based on the update instruction content 670 (see FIG. 24).

In step S303, the update execution unit 414 proceeds to step S304 if the update instruction contents 650 and 660 are approved by the approver (step S303 → YES), and ends the update process if there is no approval (step S303 → NO).
In step S304, the update execution unit 414 proceeds to step S305 if the update instruction content is maintenance knowledge update instruction content 650 (step S304 → YES), and if the update instruction content is not maintenance knowledge update instruction content 650 (step S304 → NO). The process proceeds to step S306.
In step S305, the update execution unit 414 updates the maintenance knowledge table 210 based on the update instruction content 650.
In step S306, the update execution unit 414 updates the model table 220 or the failure mode table 230 based on the update instruction content 660.

≪Characteristics of maintenance knowledge updater≫
The maintenance knowledge update device 400 calculates the match rate between the cause estimation result (failure mode with the maximum probability) of the cause estimation device 300 and the cause of the final confirmation, and displays it together with the match / mismatch situation (described in FIG. 21). Refer to the update instruction screen 640).
By referring to the match / mismatch situation, the maintenance staff can consider where the problem lies in the maintenance knowledge, model specifications, and probability information, and in turn, instruct to update this information. You will be able to.

The maintenance knowledge is divided into a model-specific maintenance knowledge table 210 (see FIG. 3), a model-dependent maintenance knowledge model table 220 (see FIG. 4), and a failure mode table 230 (see FIG. 5). Therefore, it becomes possible to update the maintenance knowledge separately for the update common to all models and the update related to each model. As a result, the maintainability of maintenance knowledge is improved.
The probability information is updated based on the cause of the final confirmed anomalous event (component failure mode). By reflecting the abnormal event that actually occurred and the cause as the final confirmed fact, the probability information is changed to the numerical value suitable for the reality, and the accuracy of the cause estimation is improved.

<< Second Embodiment >>
In the first embodiment, the maintenance personnel check / inspect / inspect the check items and input the check items to the cause estimation device 300 (see step S202 in FIG. 16). In the second embodiment, the cause estimation device 300A (see FIG. 26 described later) receives the sensor data and determines whether the check item is normal or abnormal.

<< Second Embodiment: Configuration of Cause Estimating Device >>
FIG. 26 is a functional block diagram of the cause estimation device 300A according to the second embodiment. The event recognition model 360 is added to the storage unit 320, and the event recognition unit 315 is added to the control unit 310 as compared with the cause estimation device 300 (see FIG. 15) of the first embodiment. Further, the communication unit 330 receives sensor data (acquired value, sensor value) from a sensor that acquires the state of equipment (physical quantities such as temperature, pressure, and flow rate).

The event recognition model 360 is a machine learning model for classifying sensor data, and is a machine learning model that uses a classification method such as a clustering method such as k-means. The event recognition model 360 is, for example, a model that classifies one or more sensor data into a normal state or an abnormal state. The sensor data is classified based on a feature amount such as a maximum value or a change amount of the sensor data in a certain width period, in addition to the value itself.

FIG. 27 is a graph 710 for explaining the classification of sensor data using the event recognition model 360 according to the second embodiment. The axis of the graph 710 is a feature amount of one or a plurality of sensors according to "check item 1" (see FIG. 28 described later), which is one of the check items. The graph 710 is a graph having two axes (features), but may be a graph having one or three or more axes. The data group 711 (group) is a collection (cluster) of sensor data having similar feature quantities, and is a collection of sensor data when "check item 1" is in the normal state. The data group 712 is a collection of sensor data having similar feature quantities, and is a collection of sensor data when "check item 1" is in an abnormal state.

FIG. 28 is a table 720 for explaining the classification of sensor data using the event recognition model 360 according to the second embodiment. One row (record) of table 720 shows one data group on graph 710 (see FIG. 27) and contains columns (attributes) of group identification information 721, check item 722, state 723, and feature data 724. ..
The group identification information 721 is the identification information of the data group. The check item 722 is a check item related to the sensor data. The state 723 indicates whether the data group is "normal" or "abnormal" for the check item 722. The feature data 724 is a feature of the data group and indicates, for example, a range (region, for example, the coordinates and radius of the center) in the graph 710 of the data group. The record in which the group identification information 721 is "1" corresponds to the data group 711, and is a record indicating the data group in which the "check item 1" is "normal".

Returning to FIG. 26, the event recognition unit 315 receives the sensor data and uses the event recognition model 360 to determine whether the check item is normal or abnormal. Specifically, the event recognition unit 315 receives the sensor data and calculates the feature amount. Next, the event recognition unit 315 searches for which feature data 724 in the table 720 (see FIG. 28) the calculated feature amount corresponds to, and outputs the check items 722 and the state 723 of the corresponding records. The output check items 722 and state 723 are used in place of the check result (see step S202) input by the maintenance personnel in the cause estimation process (see FIG. 16).

<< Features of the second embodiment >>
The cause estimation device 300A acquires sensor data on behalf of the maintenance personnel and determines whether the check items are normal or abnormal. Maintenance personnel do not need to check / inspect check items or enter check results. Therefore, when an abnormal event occurs, the check result can be accurately input in a short time without any trouble, and the estimation result of the cause of the abnormal event can be obtained.

<< Third Embodiment >>
In the second embodiment, the event recognition unit 315 determines whether the check item is normal / abnormal from the sensor data using the event recognition model 360. In other words, the event recognition unit 315 determines which of the data groups 711 and 712 (see FIG. 27) contains the sensor data, and determines whether the check item is normal or abnormal. However, it is expected that sensor data (new data group) that is not included in any of the data groups 711 and 712 will appear with the operation of the equipment.

FIG. 29 is a diagram for explaining a new data group 713 appearing in the graph 710B according to the third embodiment. The sensor data included in the data group 713 is not included in the data group 711 corresponding to the existing normal state or the data group 712 corresponding to the abnormal state. Therefore, the event recognition unit 315 in the second embodiment cannot determine normality / abnormality, and the event recognition model 360 needs to be updated. In the third embodiment, when a new data group appears, it is detected and the maintenance knowledge is updated according to the instruction of the maintenance staff.
The cause estimation device 300B (not shown) according to the third embodiment is the same as the cause estimation device 300A according to the second embodiment. However, the cause estimation device 300B updates the table 720 (see FIG. 28) in response to the instruction of the maintenance knowledge update device 400B (see FIG. 30 described later).

<< Third Embodiment: Configuration of maintenance knowledge updating device >>
FIG. 30 is a functional block diagram of the maintenance knowledge updating device 400B according to the third embodiment. Hereinafter, information and functions added in comparison with the maintenance knowledge updating device 400 (see FIG. 19) according to the first embodiment will be described.

In addition to the information described in the first embodiment, the maintenance work report database 450B contains the event recognition model 360 (see table 720 shown in FIG. 28) and the output data of the event recognition unit 315 received from the cause estimation device 300B. A certain check result (normal / abnormal check item) is stored. The maintenance work report database 450B also stores sensor data (also referred to as new data group candidate data) that was received from the cause estimation device 300B and was desired to be determined to be normal or abnormal.

The update detection unit 412B detects a new data group and notifies the update instruction reception unit 413B. The update instruction receiving unit 413B displays the update instruction screen 640B (FIG. 32 described later), and receives maintenance knowledge from maintenance personnel and an update instruction of the event recognition model 360. The update execution unit 414B transmits the update instruction of the event recognition model 360 to the cause estimation device 300B according to the update instruction.

FIG. 31 is a flowchart of the event recognition model update process according to the third embodiment. The event recognition model update process is executed at a predetermined timing, for example, periodically.
In step S301, the update detection unit 412B calculates the feature amount of the new data group candidate data. In the following, the new data group candidate data will be described as a black triangle shown in Graph 710B (see FIG. 29).

In step S302, the update detection unit 412B determines whether the new data group candidate data includes the new data group. The update detection unit 412B proceeds to step S303 if a new data group is included (step S302 → YES), and ends the event recognition model update process if it is not included (step S302 → NO). The update detection unit 412B is new if, for example, in the graph 710B, a predetermined number or more of new data group candidate data is included in a predetermined size range (area) and the distance from other data groups is a predetermined value or more. Judge that the data group is included. In the following, the description will be continued assuming that the data group 713 is a new data group.

In step S303, the update detection unit 412B, as related information, includes an abnormal event (case information) at the time when the data group 713 is acquired, a maintenance knowledge network corresponding to the abnormal event and the model, and probability information related to the maintenance knowledge network. Acquires network identification information, check results input by maintenance personnel (not obtained from sensor data), calculation result table, estimation result identification information, final confirmed cause of abnormality, and so on.
In step S304, the update detection unit 412B generates an estimation result evaluation table 630 (see FIG. 20) from the related information acquired in step S303, calculates a match rate, and outputs it to the update instruction reception unit 413B.
In step S305, the update instruction receiving unit 413B displays the update instruction screen 640B (FIG. 32 described later) and receives maintenance knowledge from the maintenance staff and the update instruction of the event recognition model 360.

FIG. 32 is a screen configuration diagram of the update instruction screen 640B according to the third embodiment. An "event recognition model display" button and an "event recognition model update" button are added as compared with the update instruction screen 640 (see FIG. 21) according to the first embodiment.
When the "Event recognition model display" button is pressed, the graph 710B (see FIG. 29) and the table 720 (see FIG. 28) including the new data group 713 are displayed. The check items 722 and the state 723 of the records in the table 720 corresponding to the new data group 713 are blank. The group identification information 721 includes new group identification information, and the feature data 724 contains feature data corresponding to the data group 713.

The maintenance staff will consider the updated contents while looking at the maintenance knowledge, specification information for each model, probability information, and event recognition model. When updating the event recognition model, the maintenance worker presses the "event recognition model update" button and inputs the check items 722 and the state 723 of the displayed table 720.

Returning to FIG. 31, in step S306, the update execution unit 414B updates the maintenance knowledge, the model specification, and the probability information according to the update instruction in the same manner as the update execution unit 414 of the first embodiment. For the event recognition model, the table 720 updated in step S305 is transmitted to the cause estimation device 300B, and the cause estimation device 300B updates the table 720 stored by itself.

<< Third Embodiment: Features of the maintenance knowledge updating device >>
When a new data group appears due to the operation of the equipment, the maintenance knowledge update device 400B detects this data group and updates the update instruction screen 640B including an estimation result evaluation table related to the cause estimation of the related abnormal event ( (See FIG. 32) is displayed. The maintenance staff considers whether to add the new data group to the state of the check item and whether to update the maintenance knowledge and the probability information, and inputs the instruction. In this way, even if a new data group appears, the accuracy of estimating the cause of the abnormal event can be maintained and improved.

<< Fourth Embodiment >>
In the first embodiment, the maintenance staff examines the maintenance knowledge, the model specifications, and the updated contents of the probability information, and inputs the instruction. Since it is a human instruction, it is possible that updates / changes may be omitted or inconsistencies may occur. In the fourth embodiment, such omissions and contradictions are reduced by utilizing the asset knowledge.

FIG. 33 is a functional block diagram of the maintenance knowledge updating device 400C according to the fourth embodiment. The asset knowledge database 460 is added to the storage unit 420 as compared with the maintenance knowledge update device 400 (see FIG. 19) of the first embodiment.
FIG. 34 is a data structure diagram of the asset knowledge database 460 according to the fourth embodiment. The asset knowledge database 460 stores data such as maintenance knowledge analysis results. The asset knowledge database 460 is, for example, a FMEA (Failure Mode and Effects Analysis) sheet, which includes information such as failure mode, functional failure, and influence, and the causal relationship of the information is clear.

The asset knowledge database 460 is tabular data, and one row (record) is a column of causally related components 461, functional failure 462, failure mode 463, failure effect 464, cause 465, and inspection item 466. Includes (attribute). The component 461, the functional failure 462, the failure mode 463, the failure effect 464, and the inspection item 466 are the component 213, the functional failure 212, the failure mode 215, the abnormal event 211, and the check item 216 of the maintenance knowledge table 210 (see FIG. 3), respectively. It corresponds to. One record can also be regarded as a causal relationship between anomalous events, malfunctions, failure modes, and check items.

Returning to FIG. 33, the update instruction receiving unit 413C inspects the asset knowledge database 460 for omissions or inconsistencies when the maintenance personnel add a node or a link to the maintenance knowledge network.
For example, when an instruction to add a failure mode to a component is received, the update instruction receiving unit 413C inspects whether the failure mode has been added to another component of the same type. As a result of the inspection, if there is a component that has not been added, the update instruction receiving unit 413C displays a warning. Alternatively, the update instruction receiving unit 413C may display a message suggesting addition.

Further, for example, when an instruction to update a functional failure, a failure mode, and the two causal relationships is received, does the update instruction receiving unit 413C contradict the relationship between the functional failure 462 and the failure mode 463 included in the asset knowledge database 460? inspect. If a contradiction is found as a result of the inspection, the update instruction receiving unit 413C displays a warning including the content of the contradiction.
In addition, the update instruction receiving unit 413C has a causal relationship between an abnormal event and a functional failure that is not included in the asset knowledge database 460, a causal relationship between a functional failure and a failure mode, a causal relationship between an abnormal event and a failure mode, and a failure mode. You may be warned when you receive an instruction to add a causal relationship between the item and the check item, and a relationship between the component type (model number) and the failure that occurs in the component type.
The update instruction screen displayed by the update instruction receiving unit 413C includes an "asset knowledge display" button for displaying the contents of the asset knowledge database 460.

≪Characteristics of maintenance knowledge updater≫
By collating the maintenance knowledge and the updated contents of the model specifications input by the maintenance personnel with the asset knowledge database 460 (see FIG. 34), the maintenance knowledge updating device 400C can detect omissions and inconsistencies in the updated contents. As a result, maintenance personnel can easily determine the renewal work and reduce renewals including inconsistencies and omissions. In addition, since the message for adding the failure mode of the component can be displayed, the content that may need to be updated can be presented, so that the update instruction is efficiently supported.

<< Modification example: Update detection unit >>
When the update detection unit detects that the match rate (see the result 635 in FIG. 20) is lower than the predetermined value or a new data group (see the data group 713 in FIG. 29), the update detection unit notifies the maintenance personnel of this. You may.

≪Transformation example: Check items≫
In the above-described embodiment, the check items are normal / abnormal binary values, but the check items are not limited to this. For example, the check items for the damage status of the component may be three or more stages such as "none", "within 5 mm", "within 10 mm", and "more than 10 mm", or may be numerical values.

<< Modification example: Generation of maintenance knowledge network corresponding to the model >>
In the above-described embodiment, the maintenance knowledge network generator 100 generates a maintenance knowledge network corresponding to an abnormal event (see FIG. 10) and then generates a maintenance knowledge network corresponding to the abnormal event and the model (see FIG. 14). ing. The maintenance knowledge network generation device 100 may generate the maintenance knowledge network corresponding to the abnormal event and the model without generating the maintenance knowledge network corresponding to the abnormal event. For example, the maintenance knowledge network generator 100 refers to the maintenance knowledge table 210 (see FIG. 3) excluding the records of the components not provided in the model and the records including the failure mode that does not occur in the components provided in the model. A maintenance knowledge network corresponding to a model may be generated to generate a maintenance knowledge network corresponding to an abnormal event and a model.

≪Variation example: Maintenance knowledge network≫
The maintenance knowledge network described above includes check items for checking the state of the failure mode of the component. The cause estimation system may use a maintenance knowledge network that does not include check items and relationships (links) between check items and components. In other words, depending on the model, the component that causes the abnormal event may be presented together with the magnitude of the possibility of failure. If the equipment configuration is simple and it is easy to determine whether or not a component has failed, it is possible to present components with a high possibility of failure and streamline maintenance personnel's response work even if there are no check items. ..
Further, the above-mentioned maintenance knowledge network shows a causal relationship that the cause of the abnormal event is a functional failure and the cause of the functional failure is a failure mode. It may be a maintenance knowledge network in which there is no functional failure and the cause of the abnormal event is the failure mode.

≪Transformation example: Update instruction screen≫
The update instruction screen 640B includes the estimation result evaluation table 630 (see FIG. 20), but may not be included. It is assumed that the update of the table 720 (see FIG. 28) showing the event recognition model 360 (see FIG. 26) and the update of the maintenance knowledge table 210 and the like are obvious without referring to the estimation result evaluation table 630. The update instruction screen 640B that does not include the estimation result evaluation table 630 may be used.

≪Other variants≫
Although some embodiments of the present invention have been described above, these embodiments are merely examples and do not limit the technical scope of the present invention. For example, the cause estimation system 10 is composed of a maintenance knowledge network generation device 100, a cause estimation device 300, and a maintenance knowledge update device 400, but may be one device. The cause estimation system 10 may be used for estimating the cause of a failure in office equipment, home appliances, etc., in addition to equipment, equipment, and machines installed in plants and facilities.

In the above-described embodiment, the failure mode and the abnormal event have a causal relationship with a functional failure sandwiched between them. There may be a causal relationship in which there is no functional failure and the failure mode and the abnormal event are directly linked.
The maintenance knowledge network is a Bayesian network to which probability information is given, but it is not necessary to have probability information. In this case, the cause estimation system estimates the failure mode of all the components that may be the cause for the abnormal event regardless of the possibility.

The present invention can take various other embodiments, and further, various changes such as omission and replacement can be made without departing from the gist of the present invention. These embodiments and variations thereof are included in the scope and gist of the invention described in the present specification and the like, and are also included in the scope of the invention described in the claims and the equivalent scope thereof.

10 Cause estimation system 100 Maintenance knowledge network generator 111 Network generator 121 Maintenance knowledge database 122 Model specification database 123 Probability information database 210 Maintenance knowledge table (common maintenance knowledge network)
211 Abnormal event 215 Failure mode (component failure)
216 Check item 220 Model table 222 Component 223, 224, 225 Model (Model number (type) of component 222 provided in the equipment of the model)
230 Failure mode table (failure table)
233 Model number (type)
234,235,236 Failure mode (failure that occurs)
240 Failure mode occurrence probability table 250 Failure detection probability table 260 Child node error occurrence probability table 300, 300A Cause estimation device 311 Probability calculation unit 312 Cause estimation unit 313 Estimation result display unit 314 Check result acquisition unit 315 Event recognition unit 350 Maintenance knowledge network Database 360 Event recognition model 400, 400B, 400C Maintenance knowledge update device 411 Abnormality cause acquisition unit 412 Update detection unit 413 Update instruction reception unit 414 Update execution unit 450 Maintenance work report database 460 Asset knowledge database 500 Matter information 510 Maintenance knowledge network (abnormality) Maintenance knowledge network corresponding to the event)
520 node information table (maintenance knowledge network corresponding to abnormal events together with link information table 530, maintenance knowledge network corresponding to the model shown in FIG. 14 Maintenance knowledge network corresponding to abnormal events and models after generation processing)
530 link information table (maintenance knowledge network corresponding to abnormal events together with node information table 520, maintenance knowledge network corresponding to the model shown in FIG. 14 Maintenance knowledge network corresponding to abnormal events and models after generation processing)
640,640B update instruction screen

Claims (11)

1. A common maintenance knowledge network that shows the relationship between an abnormal event of equipment and a failure of a component provided in the equipment, and the relationship between the failure and a check item for confirming whether or not the failure has occurred.
   A model table that associates the model of the equipment with the type of the component provided in the equipment of the model,
   It is provided with a network generator that performs information processing using a failure table that associates the type of the component with the failure that occurs in the type of the component.
   The network generator
   Receive the abnormal event and the model of the equipment in which the abnormal event occurred.
   With reference to the common maintenance knowledge network, the failure of the component related to the abnormality event and the check item for confirming the occurrence of the failure are specified from the received abnormality event, and the abnormality event is specified. Generate a maintenance knowledge network corresponding to
   With reference to the model table, specify the type of component provided in the model of the equipment from the model of the received equipment.
   With reference to the failure table, failures that are not associated with the identified component type are removed from the maintenance knowledge network corresponding to the abnormal event.
   It is characterized by further removing check items that are different from the check items for confirming the occurrence of failures that remain unremoved, and creating a maintenance knowledge network corresponding to the abnormal event and the model of the equipment. Cause estimation system.
2. Further equipped with a cause estimation unit,
   The network generator
   With reference to the probability information including the probability that the failure will occur and the probability that the check item for confirming the occurrence of the failure will be abnormal when the failure occurs, refer to the probability information.
   The probability that the failure will occur in the maintenance knowledge network corresponding to the abnormal event and the model of the equipment, and the probability that the check items for confirming the occurrence of the failure will be abnormal when the failure occurs. And
   The cause estimation system according to claim 1, wherein the cause estimation unit receives whether or not the check item is abnormal and calculates the probability that the failure has occurred.
3. An update that receives the failure that caused the abnormal event, calculates the matching rate between the failure and the failure with the maximum probability calculated by the cause estimation unit, and notifies when the matching rate is lower than a predetermined value. The cause estimation system according to claim 2, further comprising a detection unit.
4. Further equipped with an update instruction reception unit and an update execution unit,
   The update instruction reception unit
   Display an update instruction screen including a comparison table between the failure that caused the abnormal event and the failure that has the maximum probability calculated by the cause estimation unit.
   Accepting at least one change instruction from the common maintenance knowledge network, the model table, the failure table, and the probability information,
   The update execution unit is
   The cause estimation system according to claim 3, wherein the update instruction receiving unit makes a change received.
5. Further equipped with an event recognition unit,
   The check item is a check item for confirming whether or not the check item is abnormal based on the sensor value acquired from the sensor provided in the equipment.
   The cause estimation system according to claim 2, wherein the event recognition unit determines whether or not the check item is abnormal based on the sensor value and outputs the error to the cause estimation unit.
6. The cause estimation system according to claim 5, wherein the event recognition unit classifies the sensor values into a data group using the feature amount of the sensor values and determines whether or not the check items are abnormal.
7. Equipped with an update detector
   The cause estimation system according to claim 6, wherein the update detection unit notifies when a sensor value that is not classified into any of the data groups is acquired.
8. Further equipped with an update instruction reception unit and an update execution unit,
   The update instruction reception unit
   When a sensor value that is not classified in any of the above data groups is acquired,
   At least one of an instruction to add a new data group, an instruction to change the common maintenance knowledge network, an instruction to change the model table, an instruction to change the failure table, and an instruction to change the probability information. Accepting one instruction,
   The update execution unit is
   The cause estimation system according to claim 7, wherein the update instruction receiving unit executes the received instruction.
9. The update instruction reception unit
   Refer to the asset knowledge database in which the component, the failure, the abnormal event, and the check item are associated and stored.
   When the instruction to change the common maintenance knowledge network includes the addition of a relationship between the anomalous event and the failure of a component of the equipment that is the cause of the anomalous event, which is not included in the asset knowledge database.
   When the instruction to change the common maintenance knowledge network includes the addition of a relationship between the failure and a check item for confirming whether or not the failure has occurred, which is not included in the asset knowledge database.
   When the instruction to change the failure table includes the addition of the component type and the failure that occurs in the component type, which is not included in the asset knowledge database, and
   The instruction to change the failure table includes the addition of the component type included in the asset knowledge database and the failure that occurs in the component type, and the instruction occurs in a component of a type different from the component type. The claim is characterized in that it does not include the addition of the failure, and if the asset knowledge database contains the failure that occurs in the different type of component, the warning is notified in at least one of the cases. The cause estimation system according to 4 or 8.
10. A common maintenance knowledge network that shows the relationship between abnormal events in equipment and failures of components in the equipment.
    A model table that associates the model of the equipment with the type of the component provided in the equipment of the model,
    It is provided with a network generator that performs information processing using a failure table that associates the type of the component with the failure that occurs in the type of the component.
    The network generator
    Receive the abnormal event and the model of the equipment in which the abnormal event occurred.
    With reference to the common maintenance knowledge network, the failure of the component related to the abnormal event is identified from the received abnormal event, and the maintenance knowledge network corresponding to the abnormal event is generated.
    With reference to the model table, specify the type of component provided in the model of the equipment from the model of the received equipment.
    With reference to the failure table, failures that are not associated with the specified component type are removed from the maintenance knowledge network corresponding to the abnormal event, and the maintenance knowledge network corresponding to the abnormal event and the model of the equipment is removed. A cause estimation system characterized by producing.
11. It is a cause estimation method of the cause estimation system.
    In the storage unit of the cause estimation system,
    A common maintenance knowledge network that shows the relationship between an abnormal event of equipment and a failure of a component provided in the equipment, and the relationship between the failure and a check item for confirming whether or not the failure has occurred.
    A model table that associates the model of the equipment with the type of the component provided in the equipment of the model,
    The failure table that associates the type of the component with the failure that occurs in the type of the component is stored.
    With reference to the step of receiving the abnormal event and the model of the equipment in which the abnormal event occurred and the common maintenance knowledge network, the failure of the component related to the abnormal event from the received abnormal event and the failure of the failure Specify the check items for confirming the correctness of the occurrence, refer to the step to generate the maintenance knowledge network corresponding to the abnormal event and the model table, and change the model of the received equipment to the model of the equipment. Steps to identify the type of component to be provided and the step to remove failures that are not related to the specified component type from the maintenance knowledge network corresponding to the abnormal event by referring to the failure table, and remain unremoved. It is characterized by further removing the check items that are different from the check items for confirming the correctness of the occurrence of the failure, and executing the step of generating the maintenance knowledge network corresponding to the abnormal event and the model of the equipment. Cause estimation method.

Images