JP7491745B2 - Fault countermeasure proposal device, fault countermeasure proposal method, and fault countermeasure proposal program - Google Patents

Description

The present invention relates to a fault countermeasure proposal device, a fault countermeasure proposal method, and a fault countermeasure proposal program.

Determining appropriate countermeasures for equipment failure requires a high level of skill. Unskilled workers cannot easily identify the underlying cause of a failure that is occurring right in front of their eyes. Even if a countermeasure that seems capable of solving the immediate problem is implemented, the failure will not be resolved if the countermeasure does not address the underlying cause of the failure. Conversely, if the underlying cause is identified, the failure can be resolved immediately by implementing a countermeasure that addresses it.

The manufacturing quality management method in Patent Document 1 proposes countermeasures using a fault tree. This fault tree has multiple events, or "what is going on" at the root and each leaf, and has logical operators at each branch point. Countermeasures (management items) are associated with the leaf events (fundamental causes).

JP2002-351537A

In Patent Document 1, when a new measure is added, the event corresponding to the measure must be found from among many leaf events. This work is particularly time-consuming when the branching of the fault tree is complex and the number of leaves is large.
Therefore, an object of the present invention is to omit the work of taking measures against events in a fault tree.

The fault countermeasure proposal device of the present invention comprises a fault information receiving unit that receives an event indicating a fault, a fault tree reference unit that acquires events that may be the cause of the accepted event by referring to a given tree that has the events hierarchically, and an application proposal unit that acquires countermeasure information corresponding to the acquired possible causative event from correspondence information that stores countermeasure information on applications that can be used as a countermeasure for the event in association with the event, and proposes the acquired countermeasure information , wherein the fault tree reference unit acquires the event with the shortest hierarchical distance from the starting event when there are multiple candidates for the possible causative event, and acquires the event with the shortest hierarchical distance when there are multiple candidates with the shortest hierarchical distance, and acquires the event with the largest number of logical products through which to pass, and the records of the correspondence information are increased based on user operation when a new application for the fault is added .
Other means will be described in the description of the embodiment of the invention.

The present invention makes it possible to eliminate the need to take countermeasures against events in a fault tree.

1 is a diagram illustrating a configuration of a fault countermeasure proposal device according to a first embodiment. FIG. This is an example of a fault tree (FT). 11 is an example of application information. 4 is a flowchart of a processing procedure according to the first embodiment. 13 is an example of a failure information reception screen. 13 is a diagram illustrating the configuration of a fault countermeasure proposal device according to a second embodiment. FIG. 13 is a flowchart of a processing procedure according to a second embodiment. 13 is an example of a failure information reception screen. 13 is an example of the failure information reception screen (continuation).

The following describes in detail a first embodiment and a second embodiment for carrying out the present invention with reference to the drawings. Compared to the first embodiment, the second embodiment adds a process for analyzing text entered by a user. The first and second embodiments are examples of providing a scientific and technical calculation application as a measure to solve a failure of a product consisting of many parts. However, the concept of the present invention is not limited to the example of providing a scientific and technical calculation application, and can be applied to an example of providing any information useful in solving the failure.

First Embodiment
(Configuration of the fault countermeasure proposal device)
1 is a diagram for explaining the configuration of a fault countermeasure proposal device 1 in the first embodiment. The fault countermeasure proposal device 1 is a general computer, and includes a central control device 11, an input device 12 such as a mouse and a keyboard, an output device 13 such as a display, a main memory device 14, an auxiliary memory device 15, and a communication device 16. These are interconnected by a bus. The auxiliary memory device 15 stores a fault tree (also called "FT") 31, application information 32, and applications 33 (all of which will be described in detail later).

The fault information receiving unit 21, FT reference unit 22, and application proposal unit 23 in the main memory device 14 are programs. The central control unit 11 reads these programs from the auxiliary memory device 15 and loads them into the main memory device 14 to realize the functions of each program (described in detail below). The auxiliary memory device 15 may be configured independent of the fault countermeasure proposal device 1. The fault countermeasure proposal device 1 can communicate with a terminal device 3 via a network 2. The terminal device 3 is used when a user operates the fault countermeasure proposal device 1 from a remote location.

(application)
The application 33 is software that performs calculations, inspections, simulations, etc. to solve failures of products or parts. The applications 33 include applications that have been developed in-house or licensed and stored in the auxiliary storage device 15 by the administrator of the failure countermeasure proposal device 1, as well as applications that have been stored in any external device (not shown) and made public. The application 33 in FIG. 1 is a collection of many such applications.

(Fault Tree)
Fig. 2 is an example of a fault tree (FT) 31. The FT 31 has a number of events 41 to 46 and a number of branches 47 and 48. In Fig. 2, an event is represented by a rectangle with a dashed line, and includes a product or part and a phenomenon. Now, let us look at the event 41 about a product. The event 41 includes a product node 51 marked "Product E" and a phenomenon node 52 marked "Phenomenon E". This means that "Product E shows phenomenon E". A phenomenon is a specific situation of a failure, such as "electric leakage", "heating", "ignition", "deformation", "fracture", etc.

Let's look at event 42, which is about a part. Event 42 includes part node 53 labeled "part A" and phenomenon node 54 labeled "phenomenon A." This means that "part A exhibits phenomenon A." The phenomenon here is also a specific situation of a failure. The same is true for events 43 to 46.

FT31 has a tree structure with an event about the product as the root and events about multiple parts as leaves. FT31 is used to find the root cause of a failure by tracing events "top-down" from the root to the leaves. A root cause here is an event that has no other events on its terminal side (the leaf side, the right side of Figure 2). Events 42, 44 to 46 are root causes.

Branch 47 is a "logical sum" branch. Hereinafter, this is also simply referred to as logical sum 47. Branch 48 is a "logical product" branch. Hereinafter, this is also simply referred to as logical product 48. Logical sum 47 indicates that if at least one of the events directly connected to the leaf side occurs, an event directly connected to the root side will always occur. That is, if phenomenon A occurs in part A, phenomenon B occurs in part B, or phenomenon C occurs in part C (at least one case), phenomenon E will always occur in product E, which has parts A to C as components. On the other hand, logical product 48 indicates that if all of the events directly connected to the leaf side occur, an event directly connected to the root side will always occur. That is, if phenomenon D occurs in part D and phenomenon H occurs in part H, phenomenon B will always occur in part B, which has parts D and H as components.

The auxiliary storage device 15 stores a large number of FTs 31 as shown in FIG. 2 for each combination of product and phenomenon. The fault countermeasure proposal device 1 updates the FTs 31 based on past fault examples, thereby always keeping each FT 31 up to date.

(Application Information)
3 is an example of the application information 32. In the application information 32, a target product and a target part are stored in a target product/target part column 102 and a target phenomenon is stored in a target phenomenon column 103 in association with an application name stored in an application name column 101.

The application name in the application name column 101 is the name of each application 33. Note that other information related to the application 33 (such as an overview of the processing performed by the application 33) may also be stored in this column. The contents stored in this column correspond to "countermeasure information."
The target product/target part in the target product/target part column 102 is the name of the product or part that is the target of the application 33 .
The target phenomenon in the target phenomenon column 103 is the phenomenon that is the target of the application 33 .

For example, look at the first line in Figure 3. The events that application A targets are phenomenon P of product A, phenomenon Q of product A, phenomenon R of product A, phenomenon P of product B, ..., phenomenon R of part K, totaling 12 events. Furthermore, in addition to the above, the events that application A targets may be phenomenon P, phenomenon Q, or phenomenon R of any product or part, or even any phenomenon of product A, product B, part H, or part K.

In this way, application information 32 is correspondence information that has a structure that allows the name of an application corresponding to an event, which is a combination of a product or part and a phenomenon, to be obtained using the event as a search key. When a new application 33 is added as a countermeasure against a failure, the user adds a record to application information 32. At this time, the user does not need to be aware of FT 31 at all.

(Processing Procedure)
Fig. 4 is a flowchart of a processing procedure in the first embodiment. Hereinafter, Fig. 5 will be referred to as appropriate during the explanation of the flowchart.

In step S201, the fault information receiving unit 21 of the fault countermeasure proposal device 1 receives an event. Specifically, first, the fault information receiving unit 21 displays a fault information receiving screen 61 (FIG. 5) on the output device. Note that hereinafter, when simply referring to an output device or an input device, this includes the output device or input device of the terminal device 3.

Secondly, the failure information receiving unit 21 receives the name of the failed product or part input by the user via an input device such as a keyboard in an input field 62. For the sake of convenience in the following explanation, it is assumed here that "personal computer" is input.
Thirdly, the malfunction information receiving unit 21 receives input of the malfunction situation (phenomenon) by the user via an input device such as a keyboard in an input field 63. For the sake of convenience in the following explanation, it is assumed here that "burning smell" is input.
Fourth, the malfunction information receiving unit 21 receives the user pressing the send button 64 .

In step S202, the FT reference unit 22 of the fault countermeasure proposal device 1 searches for FTs 31. Specifically, the FT reference unit 22 searches for FTs 31 that have the event "Product = PC, Phenomenon = Burning smell." As a result of this search, one or more FTs 31 may or may not be found to be relevant. Here, for the sake of convenience in the following explanation, it will be assumed that only one such FT 31 was found to be relevant.

In step S203, the FT reference unit 22 determines whether or not the FT 31 can be acquired. Specifically, if the corresponding FT 31 exists (step S203 "Yes"), the FT reference unit 22 proceeds to step S204, and otherwise (step S203 "No"), the FT reference unit 22 proceeds to step S209.

In step S204, the FT reference unit 22 acquires the cause. Specifically, the FT reference unit 22 traces the FT 31 to the leaf (end) side starting from the starting event "Product = PC, Phenomenon = Burning smell" of the relevant FT 31, and acquires all events (causes) at the end of the starting point. At this time, many events other than the starting event that the user is not aware of are acquired in advance.

In step S204, the FT reference unit 22 may obtain only the root cause. Specifically, the FT reference unit 22 starts from the starting event "Product = PC, Phenomenon = Burning smell" of the relevant FT 31 and traces the FT 31 to the leaf (terminal) side to obtain the root cause. If there are multiple root causes, the FT reference unit 22 obtains, for example, the one with the shortest hierarchical distance from the starting event. If there are multiple root causes with the shortest hierarchical distance, the FT reference unit 22 obtains, for example, the one with the largest number of logical products.

The FT reference unit 22 can accept any narrowing conditions from the user in order to adjust the number of (root) causes obtained in step S204. For the sake of convenience in the following explanation, it is assumed here that the event "Part = power supply unit, phenomenon = poor contact" is obtained as the root cause.

In step S205, the application suggestion unit 23 of the fault countermeasure proposal device 1 searches the application information 32. Specifically, the application suggestion unit 23 searches the application information 32 using the search keys "target part = power supply unit, target phenomenon = poor contact" and obtains the application name of the corresponding record. As a result of this search, one or more application names may or may not be found. Here, for the sake of convenience in the following explanation, it will be assumed that multiple such application names are found.

In step S206, the application suggestion unit 23 determines whether or not the application can be acquired. Specifically, if the corresponding application name exists (step S206 "Yes"), the application suggestion unit 23 proceeds to step S207, and otherwise (step S206 "No"), the application suggestion unit 23 proceeds to step S209.

In step S207, the application suggestion unit 23 suggests applications. Specifically, the application suggestion unit 23 displays the names of the corresponding applications on the output device 13. At this time, the application suggestion unit 23 simultaneously displays the following message.
・"These applications may be able to solve the problem."
・"Please check the link for details about the application."
・"Select the name of the application you want and the application will start."
More generally, the application suggestion unit 23 may display information (measure information) related to the application 33 .

At this time, the application suggestion unit 23 may display on the output device 13 the FT that was the basis for suggesting the application. This FT includes the starting event "PC, burning smell" and the root cause event "power supply, poor contact," and a user who sees this can learn the causal relationship between the two.

In step S208, the application suggestion unit 23 provides an application. Specifically, first, the application suggestion unit 23 accepts a user's selection of any one of the application names displayed on the output device 13.
Secondly, the application suggestion unit 23 launches the application 33 having the selected application name itself or downloads it to the terminal device 3 .

In step S209, the application suggestion unit 23 displays a message that the application cannot be suggested.
・"Sorry, but I can't find any applications that might solve the problem."
Then, the processing procedure ends.

Second Embodiment
(Configuration of the fault countermeasure proposal device)
Fig. 6 is a diagram for explaining the configuration of a fault countermeasure proposal device 1 in the second embodiment. The fault countermeasure proposal device 1 in Fig. 6 differs from the fault countermeasure proposal device 1 in Fig. 1 only in that the main memory device 14 has a fault information reception/analysis unit 24 instead of the fault information reception unit 21. Although not shown, the fault countermeasure proposal device 1 may also have both the fault information reception unit 21 and the fault information reception/analysis unit 24.

(Processing Procedure)
Fig. 7 is a flowchart of the processing procedure in the second embodiment. Hereinafter, Fig. 8 and Fig. 9 will be referred to as appropriate during the explanation of the flowchart. The flowchart in Fig. 7 is obtained by replacing step S201 in the flowchart in Fig. 4 with steps S201a to S201c. Therefore, hereinafter, only steps S201a to S201c will be explained.

In step S201a, the fault information reception/analysis unit 24 of the fault countermeasure proposal device 1 receives the event in text form. Specifically, first, the fault information reception/analysis unit 24 displays the fault information reception screen 71 (FIG. 8) on the output device 12.

Secondly, the malfunction information receiving and analyzing unit 24 receives a sentence explaining the malfunction input by the user via the input device 12 such as a keyboard in the input field 72. For the sake of convenience in the following explanation, it is assumed here that "the belt broke" is input.
Thirdly, the failure information receiving and analyzing unit 24 receives the user pressing the send button 73 .

In step S201b, the malfunction information reception analysis unit 24 analyzes the event. Specifically, first, the malfunction information reception analysis unit 24 breaks down the sentence received in “second” of step S201a into morphemes such as “the belt broke.”
Secondly, the failure information reception and analysis unit 24 recognizes the first noun that appears as a "product" or "part" and recognizes the last verb, adjective, noun, etc. that appears as a "phenomenon". If the last verb that appears is a conjugated form of the verb "to do", the verb, adjective, noun, etc. immediately preceding it is recognized as a "phenomenon". Here, the failure information reception and analysis unit 24 acquires an event including a "belt" as a product or part and "breakage" as a phenomenon. However, the event here is a "provisional event" that has not been confirmed by the user.

In step S201c, the failure information reception/analysis unit 24 receives editing of the event. Specifically, first, the failure information reception/analysis unit 24 displays a failure information reception screen (continued) 74 ( FIG. 9 ) on the output device 13. In an input field 75, "belt" is displayed as a product or part, and in an input field 76, "break" is displayed as a phenomenon.
Secondly, the failure information receiving and analyzing unit 24 receives, as necessary, the user's input of the truly intended product or part in the input field 75 and the truly intended phenomenon in the input field 76 .
Thirdly, the failure information receiving and analyzing unit 24 receives the user pressing the send button 77 .
The malfunction information reception/analysis unit 24 may omit step S201c. In other words, the malfunction information reception unit 21 may recognize the tentative event as an event truly intended by the user.

(Variation: Automatic Generation of FT)
In the above, it has been assumed that the FT 31 is given. However, the FT reference unit 22 can also generate the FT 31. In this case, the FT reference unit 22 performs the following process.
<1> The FT reference unit 22 accepts the user's input of a product or part and a phenomenon on the failure information acceptance screen 61 (FIG. 5).

<2> The FT reference unit 22 accesses an arbitrary external device via the network 2 and acquires public fault information including the received phenomenon. The public fault information is a public document that describes multiple pieces of information corresponding to the events of this embodiment together with their mutual causal relationships. The public fault information does not necessarily have to explain FT.
<3> The FT reference unit 22 creates an FT including the received event based on the acquired public fault information.
<4> The FT reference unit 22 acquires the causative event from the created FT. The subsequent processing is the same as that described above.

(Effects of this embodiment)
The effects of the fault countermeasure proposal device of this embodiment are as follows.
(1) The fault countermeasure proposal device has correspondence information that associates events with countermeasures, separate from FT. Therefore, even if new countermeasures are added, there is no need to associate new countermeasures with FT events.
(2) The troubleshooting proposal device can identify the root cause.
(3) The fault countermeasure proposal device can express an event by dividing it into products, etc. and phenomena.
(4) The fault countermeasure proposal device can associate a countermeasure application with a combination of a product, etc. and a phenomenon.

(5) The fault countermeasure proposal device allows the user to input a phenomenon that has actually occurred.
(6) The fault countermeasure proposal device allows the user to input a description of a fault that has actually occurred in natural sentences.
(7) The fault countermeasure proposal device can display the results of the text analysis to the user.
(8) The fault countermeasure proposal device can create an FT.

The present invention is not limited to the above-described embodiments, but includes various modified examples. For example, the above-described embodiments have been described in detail to make the present invention easier to understand, and are not necessarily limited to those having all of the configurations described. It is also possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, for example, by designing a part or all of them as an integrated circuit. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as a program, table, file, etc. that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.
In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other.

REFERENCE SIGNS LIST 1 Fault countermeasure proposal device 2 Network 3 Terminal device 11 Central control device 12 Input device 13 Output device 14 Main memory device 15 Auxiliary memory device 16 Communication device 21 Fault information reception unit 22 Fault tree (FT) reference unit 23 Application proposal unit 24 Fault information reception and analysis unit 31 Fault tree (FT)
32 Application Information 33 Application

Claims (10)

a failure information receiving unit that receives an event indicating a failure;
a fault tree reference unit that acquires events that may be the cause of the received event by referring to a given tree that hierarchically includes the events;
acquiring countermeasure information corresponding to the acquired possible causal event from correspondence information that stores countermeasure information related to an application that can be used as a countermeasure for the event in association with the event;
an application suggestion unit that proposes the acquired countermeasure information;
Equipped with
The fault tree reference unit includes:
If there are multiple candidates for the event that may be the cause, select the one with the shortest hierarchical distance from the starting event, and if there are multiple candidates with the shortest hierarchical distance, select the one with the largest number of logical products through which the event passes;
The correspondence information record includes:
When a new application for a fault is added, the number of failures increases based on the user's operation.
A fault countermeasure proposal device characterized by the above. The events that may cause the above-mentioned problems are as follows:
When tracing events from the root to the leaf in a fault tree, there are no other events on the leaf side of the event in question .
2. The fault countermeasure suggestion device according to claim 1, The event is
The product or part involved in the failure and the symptom of the failure must be included.
3. The fault countermeasure suggestion device according to claim 2, further comprising: The correspondence information is
the countermeasure information is stored in association with a combination of the product or part and the phenomenon;
4. The fault countermeasure suggestion device according to claim 3, The failure information receiving unit
accepting a user's input of a combination of the product or part and the phenomenon;
5. The fault countermeasure suggestion device according to claim 4, a failure information receiving and analyzing unit that receives a sentence indicating a failure and extracts the product or the part and the phenomenon from the received sentence by performing a morphological analysis of the received sentence;
6. The fault countermeasure suggestion device according to claim 5, The failure information reception and analysis unit
accepting editing of the extracted products or parts and the phenomena by a user;
7. The fault countermeasure suggestion device according to claim 6, The fault tree reference unit includes:
creating said tree if said tree is not given;
8. The fault countermeasure suggestion device according to claim 7, The failure information receiving unit of the failure countermeasure proposal device includes:
Accepts events that indicate a failure,
The fault tree reference unit of the fault countermeasure proposal device includes:
obtaining events that may be the cause of the received event by referencing a given tree that hierarchically contains the events;
The application proposal unit of the failure countermeasure proposal device
acquiring countermeasure information corresponding to the acquired possible causal event from correspondence information that stores countermeasure information related to an application that can be used as a countermeasure for the event in association with the event;
Propose the acquired countermeasure information;
The fault tree reference unit further comprises:
If there are multiple candidates for the event that may be the cause, select the one with the shortest hierarchical distance from the starting event, and if there are multiple candidates with the shortest hierarchical distance, select the one with the largest number of logical products through which the event passes;
The correspondence information record includes:
When a new application for a fault is added, the number of failures increases based on the user's operation.
A method for proposing countermeasures against a fault in a fault countermeasure proposing device, comprising: Computer,
a failure information receiving unit that receives an event indicating a failure;
a fault tree reference unit that acquires events that may be the cause of the received event by referring to a given tree that hierarchically includes the events;
acquiring countermeasure information corresponding to the acquired possible causal event from correspondence information that stores countermeasure information related to an application that can be used as a countermeasure for the event in association with the event;
an application suggestion unit that proposes the acquired countermeasure information;
and make it work .
The fault tree reference portion further includes:
execute a process of obtaining the candidate for the event that may be the cause, if there are a plurality of candidates for the event that may be the cause, which has the shortest hierarchical distance from the starting event, and further, if there are a plurality of candidates for the event that has the shortest hierarchical distance, which has the largest number of logical products through which the event passes;
The correspondence information record includes:
When a new application for a fault is added, the number of failures increases based on the user's operation.
A program that proposes solutions to malfunctions.

Images