JPH07271589A - Fault diagnostic device - Google Patents

Abstract

PURPOSE:To provide a fault diagnostic device capable of reducing the maintenance cost of a knowledge base and improving the success of a fault search. CONSTITUTION:When a faulty phenomenon is inputted, in an inference mechanism part 14, the cause of a fault is searched by inference by utilizing knowledge data stored in a knowledge base part 16 and a hypothesis is generated. A maintenance person verifies a searched result derived in the inference mechanism part 14 and as the result, inputs the result of verification such as whether or not the fault is dissolved and whether or not a faulty part is specified, etc. Then, in an example registration part 15b, whether the cause search of this time is a success or a failure is judged from the inputted verified result, storage as a success example in the knowledge base of a diagnostic example type knowledge data storage part 16a provided in the knowledge base part 16 is performed in the case of the success and the storage as a failure example is performed in the case of the failure. As the result, the knowledge data are stored, and for instance, the hypothesis stored as the failure example is not derived in the next time and thereafter and the success rate of the fault search is gradually improved as the fault search is repeated.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure diagnosing device for investigating a cause of a failure associated with a defective phenomenon of a vehicle, an aircraft, etc. by utilizing a so-called expert system, and in particular, by accumulating the search result as a diagnosis case. The present invention relates to a failure diagnosis device that automatically collects data.

[0002]

2. Description of the Related Art In recent years, an expert system has been adopted in various fields such as medicine, architecture, and chemistry to utilize a computer as a clue for problem solving. This expert system is a system in which the knowledge of a specialist in a certain specific field is input to a computer and it is possible to solve a complicated problem at a level equivalent to that of a specialist.

Conventionally, this expert system has been adopted for vehicle failure diagnosis, for example, as disclosed in JP-A-62-62.
As disclosed in Japanese Patent No. 6846, a defect phenomenon is input, and a fundamental cause of failure (fault location) causing the phenomenon is detected using knowledge data stored in a knowledge base. It is known to search by inference.

[0004]

By the way, in such a conventional failure diagnosis device, a failure cause is searched for by utilizing independent knowledge data such as rule-type knowledge data and case-type knowledge data as a knowledge base, Alternatively, as shown in the above-mentioned prior art, there is a method for investigating the cause of a failure by using different knowledge data such as rule-type knowledge data and case-type knowledge data. If it is not acquired without exception, a clear hypothesis cannot be derived.

However, in fields such as vehicles and aircrafts, technological advances in control systems are remarkable, and the contents of diagnoses to be handled tend to become more complicated. In such fields, a knowledge base is constructed without omission. If you try to do so, not only will the development cost be enormous, but the content of the inquiry will be redundant, which is not convenient.

On the other hand, it is not feasible to construct a successive knowledge base in the fields of vehicles, aircrafts, etc., in order to cope with the complicated diagnosis contents, because it takes a huge amount of time and maintenance cost.

The present invention has been made in view of the above circumstances, and it is possible to effectively deal with complicated diagnostic contents with an existing knowledge base while suppressing maintenance costs required for repairing the knowledge base. The purpose is to provide a user-friendly fault diagnosis device.

[0008]

In order to achieve the above object, a first failure diagnosis apparatus according to the present invention uses a knowledge base unit for storing knowledge data necessary for failure diagnosis and a cause of failure using this knowledge data. The inference mechanism unit for investigating by means of inference and the technical information collecting unit are provided.
The data collection unit that collects the input data of the result of verifying the hypothesis generated by the inference mechanism unit, and the verification result is accumulated in the knowledge base unit as a successful case when the defect phenomenon is resolved. And a case registration unit.

In order to achieve the above object, the second failure diagnosis apparatus according to the present invention is a knowledge base section for storing knowledge data necessary for failure diagnosis, and an inference for inferring a failure cause by using this knowledge data. A mechanism section and a technical information collecting section, and a data collecting section that collects input data as a result of verifying the hypothesis generated by the inference mechanism section in the technical information collecting section, and a result of the verification, a defect phenomenon is resolved. If not, a case registration unit for accumulating the result of this inquiry as a failure case in the knowledge base unit is provided.

[0010]

[Operation] In the first failure diagnosing device, when a maintenance worker inputs a defect phenomenon, the inference mechanism unit searches the knowledge data stored in the knowledge base unit for an event corresponding to the defect phenomenon, and then, Based on this phenomenon, the cause of failure is inferred by using the above knowledge data to derive a hypothesis.

According to the hypothesis output from the failure diagnosis device, the maintenance staff replaces the parts or inspects predetermined places to verify whether the trouble phenomenon has been eliminated or the cause of the trouble has been clarified. Enter the result.

[0012] Then, the data collected at the dormitory is collected by the data collection unit, and when the case registration unit judges from the data inputted into the data collection unit that the defect has been solved, this time, Accumulate the results of the inquiry in the knowledge base section as successful cases.

In the second failure diagnosing device, when a maintenance worker inputs a trouble phenomenon, the inference mechanism unit searches the knowledge data stored in the knowledge base unit for an event corresponding to the trouble phenomenon. Based on an event, the above knowledge data is used to investigate the cause of failure by inference to derive a hypothesis.

According to the hypothesis output from the failure diagnosis device, the maintenance staff replaces the parts or inspects predetermined places to verify whether the malfunction phenomenon has been resolved or the cause of the failure has been clarified. Enter the result.

Then, the input data is collected by the data collection unit, and when the case registration unit judges from the data input to the data collection unit that the defect is still unresolved, this time, The result of the inquiry is stored in the knowledge base section as a failure case.

[0016]

Embodiments of the present invention will be described below with reference to the drawings.

In the present embodiment, the description will be made while describing the malfunction phenomenon of the fuel system of the aircraft as an example of the failure diagnosis target.

As shown in FIG. 8, the failure diagnosing device A according to the present embodiment comprises a device body 1 and an input pen 2, and information is input to the device body 1 using the input pen 2. The touch screen 1a is provided.

The failure diagnosis device A is installed in an airport maintenance department or the like, and when a trouble phenomenon is input to the touch screen 1a by using the input pen 2, the built-in computer causes or troubles the trouble phenomenon. Investigate the location and display necessary information such as the search result and the inspection procedure on the touch screen 1a to support the maintenance staff.

As shown in FIG. 1, the computer incorporated in the apparatus main body 1 has a window processing section 12, a system control section 13, an inference mechanism section 14, a technical information collecting section 15, and a knowledge as a function for executing a failure diagnosis. A base section 16 and an operation record data section 17 are configured. The touch screen 1a is composed of an input unit 11a and a display unit 11b.

The window processing section 12 is provided with a character recognition section 12a and an operation input section 12b as preprocessing, and a display control section 12c as postprocessing.

In the character recognition section 12a, handwritten characters such as a trouble phenomenon input by the maintenance staff with the input pen 2 in the pen input window (see FIG. 10) displayed on the touch screen 1a are converted into character codes, The commands are output to the system control unit 13. When the graphics or menu displayed on the touch screen 1a is selected with the input pen 2 in the operation input unit 12b, commands corresponding to the graphics are output to the system control unit 13. Further, the display control unit 12c causes the display unit 11b to display characters, graphics and the like based on the signal output from the system control unit 13.

The system control section 13 is provided with a man-machine interface control section 13a, an operation mode control section 13b, and a system management section 13c.
The man-machine interface control section 13a performs execution processing according to the commands from the window processing section 12. Alternatively, it outputs character data, graphics data, etc. to the display control unit 12c. The operation mode control unit 13b controls the operation mode of the entire device including peripheral devices such as interruption / restart of diagnostic processing, printing of maintenance records, and data transfer of the order management system according to the use mode selected by the maintenance personnel. To do. The system management unit 13c manages the entire system such as the operating state of the system and data management.

Further, the inference mechanism section 14 is provided with a character string retrieval section 14a, a rule-based inference section 14b, a case-based inference section 14c, and an inference control section 14d.

In the character string search unit 14a, the character string representing the trouble phenomenon input by the maintenance staff is decomposed using the separation characters ("."",""Ga""wa" etc.) registered in advance, Using this decomposed character string, a character string that is the same as or similar to the above character string is extracted from the knowledge data stored in each of the knowledge data storage units 16a to 16c of the knowledge base 16 to be described later in character string units. The search is performed in word units or character units, and the knowledge data stored in each of the knowledge data storage units 16a to 16c is totaled.

In the rule-based inference unit 14b, the knowledge data stored in the failure tree analysis (fault tree analysis; hereinafter abbreviated as "FTA") type knowledge data storage unit 16b provided in the knowledge base unit 16 is stored. And failure mode impact analysis (matrix with confidence factor, hereafter "FME
(Hereinafter abbreviated as “CA”) knowledge data stored in the type knowledge data storage unit 16c is used to infer the cause of failure or the location of the failure by inference to generate a hypothesis (details will be described later in a flowchart).

In the case-based reasoning unit 14c, the knowledge data stored in the diagnosis case type knowledge data storage unit 16a of the knowledge base unit 16 is the same as or similar to the defect phenomenon searched by the character string search unit 14a. , And a hypothesis of the cause or location of the failure is generated.

Then, the inference control section 14d judges the consistency of the hypotheses generated by the inference sections 14b and 14c, and if the hypotheses match, the hypothesis is output as a conclusion hypothesis.

The technical information collector 15 is a data collector 15
It is composed of a and a case registration unit 15b. In the data collection unit 15a, the above-mentioned hypothesis by replacing the parts according to the data entered during the maintenance work such as defect items, inspection points, measurement values, etc., which the maintenance personnel input to the device body at the time of failure investigation, and the above-mentioned conclusion hypothesis. As a result of the verification of (1), input data of (whether the defect has been solved, still not solved, or whether the cause of the failure has been identified) is collected. In the case registration unit 15b, based on the data input to the data collection unit 15a, the search result (both success case and failure case) of this time is used as a diagnosis case, and a diagnosis case type knowledge data storage unit 16 to be described later.
It is stored in the knowledge data of a.

The knowledge base unit 16 includes a diagnostic case type knowledge data storage unit 16a for storing diagnostic case type knowledge data, an FTA type knowledge data storage unit 16b for storing FTA type knowledge data, and an FMEC for storing FMECA type knowledge data.
It is composed of an A-type knowledge data storage unit 16c and an electronic manual data storage unit 16d that stores electronic manual data.

The above-mentioned diagnostic case type knowledge data is a data base in which the search results of past failure causes are summarized as an example.
As shown in FIG. 11, a failure phenomenon (or a location where the failure has occurred), a failure cause of the failure and its remedy, a defective component, a type of knowledge source, and the like are stored for each diagnostic case. The knowledge source of the diagnosis case data includes a defect record slip, a maintenance record slip, and an interview with a maintenance worker.

As shown in FIG. 9, the defect record sheet is provided with a column for recording the "defects and inspection points" found by the occupant and a column for recording the "procedures" performed by the maintenance personnel. There is. The maintenance record sheet records "defective phenomena" that occurred at the time of inspection, as well as "defective parts" and "fault status" entered in the department that performed the work.

The interview is a collection of the non-textualized maintenance procedures conducted for the maintenance staff, know-how such as failure investigation, and reflected in the diagnosis cases.

The FTA-type knowledge data stored in the FTA-type knowledge data storage unit 16b is designed to analyze design materials and experience of experienced maintenance personnel, and to logically identify failure phenomena and failure causes for each system of component parts. 14 and is expressed by a set of rules. As shown in FIG. 14, each component is classified into rules (rules 1 to 6 in the figure), and each rule is linked in a chain through an intermediate hypothesis. Has been. For example, rule 2 shows the conclusion hypothesis (fuel leakage, etc.) when "Booster pump abnormality" is the intermediate hypothesis, and rule 4 is the conclusion hypothesis (fueling leak) is the intermediate hypothesis (tightening) (Defect, internal defect of pump, etc.) is indicated.

On the other hand, the FMECA type knowledge data is expressed in a matrix table format, and analyzes the experience of skilled maintenance personnel, reliability information of parts or systems, etc., and as shown in FIG. And the cause of failure are shown in a tabular form as a so-called FMECA table in which each part or system is classified, and the failure mode column describes the failure mode of the part or system, the effect of the failure, and the method of detecting the failure. Has been done. Moreover, the certainty factor is specified in the area surrounded by each grid. This certainty factor is set in consideration of MTBF (mean time between failures) of parts or systems, the number of possible causes of failure for the same failure phenomenon, or the number of actual occurrences of failures. The degree indicates the depth of the causal relationship between the failure phenomenon and the cause of failure.

The computerized manual data is text and graphics data representing inspection, replacement, or assembly procedure of components and the like. For example, as shown in FIG. 23, the touch screen of the apparatus body 1 described above. 1a,
The data of the booster / pump graphic and the inspection procedure of the booster / pump are read from the electronic manual data and displayed in the window.

Further, the operation record data section 17 is composed of a maintenance record data storage section 17a and a work progress temporary storage section 17b. The maintenance record data storage section 17a contains measures for trouble phenomena and inspection results. , And the result of maintenance such as the status of trial operation is stored for each case. Further, in the work progress temporary storage unit 17b, for example, in the case of interruption for arranging replacement parts during maintenance and then restarting failure diagnosis, it is possible to continue from the interrupted maintenance work. In order to do so, the progress of maintenance performed by the maintenance staff or the maintenance status is sequentially stored.

Next, the failure diagnosis procedure will be described with reference to the flowcharts of FIGS. In this embodiment, a malfunction of the fuel system of the aircraft will be described as an example.

This failure diagnosis is executed according to the inference processing routine of FIG.

First, when the maintenance worker selects "start diagnosis" from the menu displayed on the touch screen 1a of the apparatus body 1 of the failure diagnosis apparatus A, as shown in FIG. A window and a pen input window for inputting this trouble phenomenon in text representation are displayed, and the inference process is started.

In step S1, the maintenance staff refers to the form such as the malfunction record slip 21 (see FIG. 9) handed over, and the necessary matters such as the movable state of the system of the aircraft, or the malfunction transmitted from the occupant or the like. The phenomenon (symptom) is input to the touch screen 1a using the input pen 2.

After the maintenance staff completes the inspection, maintenance record data such as the treatment and the trial operation status can be written in the action column of the defect recording form 21 shown in FIG. 9 (FIG. 27, FIG. 27). 30).

On the other hand, in step S2, the symptom such as the measurement value obtained by the tester connection is directly input according to the inquiry displayed in step S12 described later.

When the necessary items have been entered in the fields such as the trouble phenomenon input window on the touch screen 1a and the "end of input" window is selected by the input pen 2, the entered information (date, month, day, (Duties, contents, etc.) are output as input data and stored in the memory in step S3.

Then, in step S4, the degree of similarity between the failure phenomenon input in step S1 and stored in step S3 and the event of the knowledge data stored in each of the knowledge data storage units 16a to 16c is calculated. .

The calculation of the similarity is performed by the character string search unit 14a.
Is performed by the following procedure.

(1) First, each of the above knowledge data storage units 16a
Character strings (sentences) whose similarity is to be calculated are taken out from the respective knowledge data of 16c. It should be noted that each character string is provided with an ID (self-certification) number for associating with the knowledge data stored in each of the knowledge data storage units 16a to 16c.

(2) Next, the character string assigned with this ID number is decomposed into each unit of string, word and character, and stored in the working memory for each knowledge data. The "disassembled character string" stored in each working memory has the same ID number as that before disassembly.

Here, the "string" refers to the character string itself, and the "word" is a blank character or a pre-registered separating character (".", ",", "Ga", " ”
Etc.), for example, the string "engine does not start"
Is disassembled into "engine" and "without starting".

The character means to decompose a character string into a predetermined number of characters. For example, the character string "engine does not start", "engine", "start", "do not move", or " It is disassembled every three characters such as "d", "jinjin", "was started", "do not", or "en", "jinga", "started", "zu", etc.

(3) Next, the "ignored word (" but "," iwa ", etc.) registered in advance is deleted from the" decomposed character string "stored in the working memory.

(4) After that, the "decomposed character string" is replaced with a "synonymous phrase (" abnormal "" is regarded as "fault" etc.) registered in advance. "

(5) On the other hand, the character string of the trouble phenomenon (symptom) input by the maintenance worker is decomposed into each unit of string, word and character, as in the above (1) to (4).

(6) Then, the "decomposed character string" stored in the working memory is searched using the decomposed character string of the trouble phenomenon.

For example, the degree of similarity between the character string extracted from the knowledge data stored in each of the knowledge data storage units 16a to 16c and "The engine does not start" input by the maintenance personnel is as follows. Become.

[0056] (7) Next, data that completely matches in each unit of string, word, or character is totaled for each ID number, and the totaled result is output to the corresponding inference units 14b and 14c as the similarity. When totaling, the weighting coefficient is used for each string, word, or character.

As a result, each of the knowledge data storage units 1 indicates that the malfunction phenomenon “fuel piece is reduced”, “left tank is not reduced and consumption is from right side”
The degree of similarity with the knowledge data stored in the knowledge data 6a to 16c is as follows.

Among the knowledge data stored in the diagnostic case type knowledge data storage unit 16a, the diagnostic cases for which similarity is calculated are as shown in FIG. 11, and the similarity of each diagnostic case is The value becomes 12. In this, case-1048
“Cruising at 3000 ft” “Left tank does not consume fuel”
Is the highest similarity, that is, the case where the input failure phenomenon and symptom are the closest.

Further, in the knowledge data stored in the FTA type knowledge data storage unit 16b, the tree for which the similarity is calculated is the "fuel system malfunction" as shown in FIG.
Is a tree made up of a chain of rules with the top event as, and the similarity of each hypothesis is as follows.

1) Rule 5 "Internal defect in the pump itself" →
3, 2) "Fuel leakage", which is an intermediate hypothesis between rules 2 and 4 →
40, 3) "Fuel leak" of Rule 3 → 40, 4) "Booster pump abnormality" which is an intermediate hypothesis between Rule 1 and Rule 2 → 3, 5) "Transfer, which is an intermediate hypothesis between Rule 1 and Rule 3" 6) In Rule 1 i) "Fuel shut-off valve error" → 35, ii) "Fuel sub-tank error" → 36, iii) "Fuel indication system failure" → 38, is there.

On the other hand, the FMECA type knowledge data storage unit 16
In the knowledge data stored in c, the phenomenon for which the similarity is calculated is as shown in FIG. 17, and in this, the similarity is “fuel piece reduction” as shown in FIG. It shows a high value.

In step S4, each knowledge data storage unit 1
When the similarity between the knowledge data stored in 6a to 16c and the failure phenomenon is calculated, the following steps S5 and S are performed.
6 and S7 are executed in parallel (concurrent processing), and in each of steps S5, S6 and S7, the cause of failure is inferred and hypothesized based on the knowledge data stored in the knowledge data storage units 16a to 16c. To generate.

That is, in step S5, the cause of failure is sought by case-based reasoning to generate a hypothesis, using the knowledge data stored in the diagnosis case type knowledge data storage section 16a. In step S6, the failure cause is searched for by rule-based reasoning using the knowledge base stored in the FTA type knowledge data storage unit 16b, and a hypothesis is generated. Further, in step S7, the cause of failure is searched for by rule-based reasoning using the knowledge base stored in the FMECA type knowledge data storage unit 16c, and a hypothesis is generated.

First, generation of a hypothesis by the diagnosis case inference in step S5 will be described. This diagnostic case inference is executed by the case-based inference unit 14c, and is specifically executed according to the hypothesis generation routine by the diagnostic case inference shown in FIG.

In step S31, hypotheses are narrowed down based on the similarity of each case of the knowledge data stored in the diagnostic case type knowledge data storage unit 16a calculated in step S4 of the inference processing routine. The narrowing down of this hypothesis is judged by whether the similarity is equal to or more than a preset "threshold value". For example, if the "threshold value" is 10,
As shown in FIG. 1 and FIG. 12, “case-1048” is a hypothesis generated by diagnostic case inference. In the knowledge data shown in FIGS. 11 and 12, there is only one case that exceeds the “threshold value”, but when there are a plurality of cases having a similarity higher than the “threshold value”, , They are all hypotheses based on diagnostic case inference.

Then, in step S32, the reliability of the hypotheses narrowed down in step S31 is calculated. This reliability serves as a reference when resolving a conflict with a hypothesis obtained by other inference (FTA inference or FMECA inference), and the similarity calculated in step S4 of the above inference processing routine is multiplied by a coefficient. And calculated. In addition,
In this embodiment, as shown in FIG. 13, the coefficient for calculating the reliability is set to 1.

Then, the cases narrowed down in step S31 are output to the inference control section 14d as "hypotheses by diagnosis case inference", and step S8 of the inference processing routine is executed.
Return to.

Next, generation of a hypothesis by FTA inference in step S6 will be described. This FTA inference is executed by the rule-based inference unit 14b, and is specifically executed according to the hypothesis generation routine by FTA inference shown in FIG.

First, in step S41, a rule having a "fuel system malfunction" as a top event in the knowledge data stored in the FTA type knowledge data storage unit 16b calculated in step S4 of the inference processing routine is used. Hypotheses are narrowed down by selecting hypotheses whose similarity is equal to or more than a preset "threshold" based on the similarity of each hypothesis of the tree formed by the chain.

For example, when the "threshold value" is set to 15,
In the FTA-type knowledge data of FIG. 14, the above-mentioned a) “fuel leakage”, which is an intermediate hypothesis between rules 2 and 4, b) “fuel leakage” of rule c) i) of rule 1, “fuel shut off. "Valve abnormality" ii) "Fuel sub-tank abnormality" iii) "Faulty indication of fuel indicating system" is narrowed down.

Then, in step S42, a route connecting the hypotheses narrowed down in step S42 is searched. In FIG. 14, the “phenomenon in the fuel system”, which is the top phenomenon, is the “defect phenomenon” this time, and the root extending in the left direction from the defect phenomenon has a causal relationship with this phenomenon, that is, It is a "hypothesis". As shown in FIG. 15, the routes connecting the hypothesis selected in step S41 with the above-mentioned trouble phenomenon are 5 of routes 1-5.
Get on the street.

Then, in step S43, the completeness of the route searched in step S42 is calculated. The higher the degree of perfection, the stronger the connection (causal relationship) between the failure phenomenon and the cause of failure, the higher the value. The completeness of the route searched in FIG. 15 is as follows.

1) Route 1 → 50 2) Route 2 → 50 3) Route 3 → 50 4) Route 4 → 30 5) Route 5 → 30 Then, in step S44, based on the completeness, this completeness is determined in advance. The hypothesis is narrowed down by whether it is equal to or more than the set "threshold". For example, when the "threshold value" is set to 20, all of the routes 1 to 5 are targeted.

Next, in step S45, the reliability of the hypotheses narrowed down in step S44 is calculated,
The respective hypotheses are output to the inference control unit 14d as "hypotheses by FTA inference" and the process returns to step S8 of the inference processing routine.

The reliability is set by multiplying the completeness by a coefficient. For example, the "threshold" is set to 20,
When the coefficient is 1, as shown in FIG.
The “hypothesis based on A inference” applies to all routes 1 to 5.

Next, step S of the above inference processing routine.
Generation of a hypothesis by FMECA inference performed in 7 will be described. This FMECA inference is executed by the rule-based inference unit 14b similarly to the FTA inference, and specifically, it is performed according to a hypothesis generation routine by FMECA inference shown in FIG.

First, in step S51, the phenomena to be diagnosed this time are narrowed down from each phenomenon of the knowledge data stored in the FMECA type knowledge data storage unit 16c. This phenomenon is narrowed down by selecting a phenomenon whose similarity is equal to or more than a preset "threshold" based on the similarity calculated in step S4 of the above inference processing routine for the phenomenon corresponding to the defective phenomenon. To do. For example, when the “threshold” is set to 10, the so-called FM shown in FIG.
The phenomena displayed in the ECA table are narrowed down to "fuel decrease", "fuel piece decrease", and "fuel tank remaining amount cannot be corrected" (see FIG. 18).

Then, in step S52, the certainty factor corresponding to the phenomenon narrowed down in step S51 is set to the FM.
Obtained from the ECA table. For example, in the so-called FMECA table shown in FIG. 17, the certainty factor corresponding to “fuel reduction” is 1
6,21,63, the certainty factor corresponding to "fuel depletion" is 5
0, 31, 46, and the certainty factors corresponding to "fuel tank remaining amount cannot be corrected" are 40, 60.

Then, in step S53, a certainty factor equal to or higher than a preset "threshold value" is selected from the above certainty factors to narrow down the hypotheses. For example, the above "threshold"
When is set to 20, as shown in FIG. 17, the certainty factor surrounded by a thick frame is targeted, and in step S54, the component and the cause corresponding to this certainty factor are selected.

Then, in step S55, the reliability of the part or cause selected in step S54 is calculated, and the reliability and the hypothesis are set as "hypothesis by FMECA inference", for example, data as shown in FIG. Output to the inference control unit 14d, and return to step S8 of the inference processing routine.

In the present embodiment, the reliability is calculated by multiplying the sum of the values obtained by multiplying the similarity and the certainty factor by the coefficient, which is shown in the table below.

[0082] Then, the process returns to step S8 of the inference processing routine shown in FIG. 2, and it is determined whether the hypotheses generated in steps S5, S6, and S7 conflict, and if they conflict, the hypotheses are resolved according to preset criteria. This hypothesis conflict resolution is executed by the inference control unit 14d shown in FIG. 1, and is specifically performed according to the hypothesis conflict resolution routine of FIG.

First, in step S61, the hypotheses generated in steps S5, S6 and S7 are summarized in a table. The hypotheses generated in steps S5, S6, and S7 are aggregated for each inference, for example, as shown in the table in FIG. 20, and ranked according to the calculated reliability.

Then, in step S62, the consistency of the hypotheses generated in steps S5, S6, and S7 is obtained from the object of failure, attribute, and the like. For example, in FIG. 20, the rank 1 of the hypothesis based on the diagnostic case inference and the rank 1 of the hypothesis based on the FMECA inference are consistent in that the defective component is “booster pump”, but the rank of the hypothesis based on the diagnostic case inference is 1 and the hypothetical rank 1 based on FTA inference are common in that the defective phenomenon is "a malfunction of the fuel system", but the defective parts compete with each other. Similarly, in order 1 of the above-mentioned hypothesis based on FTA inference and the hypothesis based on FMECA inference, defective parts are in conflict.

Next, in step S63, the consistency of the hypotheses calculated in step S62 is collated with a preset "standard of judgment of consistency" to determine whether or not there is consistency. In this embodiment, the "matching criterion" is defined as "all defects having the highest reliability of the hypothesis in each inference match", and the matching is judged according to this definition.

As a result, for example, as shown in FIG.
When all the hypotheses of rank 1 generated by each inference do not match, it is determined that there is no consistency in step S64, the process proceeds from step S64 to step S65, the inference frequency measurement count value C is incremented, and the process proceeds to step S66. move on.

In step S66, the inference frequency measurement count value C and the set value N are compared, and when C≤N,
It is determined that "diagnosis is not completed", and the process proceeds to step S67. In step S67, data for re-inference is created from the hypotheses collected in step S61 according to a certain standard. If this criterion is defined as, for example, "selecting the one with the highest reliability of each hypothesis", the re-inference data is created based on the FMECA inference rank 1 hypothesis in the summary table of FIG. (See FIG. 21), this data is output together with the information of “diagnosis not completed”, and step S9
Return to.

On the other hand, when it is judged that C> N in the above step S66, that is, when the hypotheses do not match even after the re-inference is repeated a set number of times, the process proceeds to step S68.
The conflict is resolved according to a preset priority criterion.

In the priority order in this embodiment, the hypothesis based on the most logically constructed FTA type knowledge data is given the highest priority, and when no hypothesis is generated by this FTA type knowledge data, the FMECA type knowledge data is set. The hypothesis based on the diagnostic case type knowledge data is adopted when the hypothesis is not generated in either of the knowledge data. Then, in accordance with this priority order, the hypothesis in which the conflict is resolved is output as the search result together with the information of "diagnosis completed", and the routine is exited. If the cause of the failure cannot be sought in any of the knowledge data, the information of "hypothesis not established" and "diagnosis completed" is output in step S68, and the process returns to step S9.

On the other hand, in step S64, when the hypotheses generated in steps S5, S6, and S7 are matched, the hypothesis is used as a search result, and the process branches to step S69 to calculate the inference frequency count value C. After clearing
Output the above inquiry result together with the information of "Diagnosis completed",
Return to step S9.

Then, step S9 of the inference processing routine.
Returning to step S10, it is determined whether "inference is completed" based on the information created in step S8. If "inference is completed", the process proceeds to step S10. If "inference is not completed", the process is completed. Return to S4.

When it is judged in step S9 that "inference is not completed" and the process returns to step S4, the trouble phenomenon stored in the memory in step S3 and the input data such as a predetermined measurement value and the step S8 ( Step S6
The similarity between the character string combining the “re-inference data” created in 7) and the knowledge data stored in each of the knowledge data storage units 16a to 16c is calculated again.

In the data for re-inference of FIG. 21, "fuel depletion", "left tank not reduced", "only consumed from right", "booster pump", and "improper operation of own" are given as character strings. , The character strings and the knowledge data storage unit 16 described above.
defect phenomenon of knowledge data stored in a to 16c,
Comparing defective parts, causes of failure, etc., the degree of similarity is calculated by logical operation or the like.

Then, according to the similarity of each piece of knowledge data, the cause of the failure is sought by re-inference in steps S5, S6 and S7.

As a result, in the diagnostic case inference in step S5, the hypothesis generated based on the diagnostic case type knowledge data is not changed even at the time of re-inference, so the same inference result as the previous time is output.

On the other hand, in the FTA inference executed in step S6, as shown in FIG. 14, from the character string obtained by the similarity calculation, "fuel system failure" and "booster / pump abnormality" are "phenomenon". The causal relationship between the hypothesis that is the cause of the failure and the phenomenon is strongest in the route 5 shown in FIG. 15. Therefore, as shown in FIG. 22, the reliability of the route 5 is as high as 80, and the FTA is high. Inference hypothesis ranking 1
become.

On the other hand, in the FMECA inference in step S7, as shown in FIG. 17, there is a character string that coincides with "fuel depletion", the hypothesis remains unchanged, and the same result is output.

As a result, in step S64 of the hypothesis conflict resolution routine of FIG. 7, which is executed in step S8, as shown in the table of FIG. The predefined "matching criterion" is satisfied, it is determined in step S64 that there is consistency, and the process branches to step S69 to clear the inference frequency measurement count value C, and then the search result. Is output together with the information of "diagnosis completed", and the process returns to step S9.

When it is determined in step S9 that "inference is completed", the process proceeds to step S10, it is determined whether there is another inspection item, and if there is an inspection item, the process branches to step S11 to perform maintenance. Or, narrow down the contents of the inquiry to the user. Through this inquiry, the conclusion hypothesis of this time is verified and used as information when a new hypothesis is generated. That is, for example, in the FTA type knowledge base,
As shown in FIG. 15, the conclusion hypothesis of rule 4 is linked to the [fuel leak] that is linked to the intermediate booster / pump abnormality of rule 2 by the rule. Therefore, specify the location that identifies the abnormality of the booster / pump by interview,
By inspecting this location, the failure location can be further narrowed down.

Then, in step S12, the contents of the inquiry narrowed down in step S11 are displayed on the touch screen 1a of the apparatus main body 1, and at the same time, the work contents such as related inspection procedures and necessary information are displayed, for example, in FIG. Display as shown in. Then, the process returns to steps S1 and S2, and waits for the maintenance staff to input the inspection result.

Then, the maintenance person touches the touch screen 1 described above.
When the inspection result is input to the a from the input pen 2 or the tester, this data is stored in step S3, and in step S4, the input character string, the character string of "input data" up to the previous time, and the measurement result are stored. Based on this, the degree of similarity with each piece of knowledge data is recalculated, and in steps S5, S6, and S7 and below, inference is performed again based on each piece of knowledge data to investigate the cause of the failure.

Then, after the inference is completed, the process proceeds from step S9 to step S10, and if there is no inspection item for verifying the hypothesis, the process proceeds to step S13 as it is, and it is determined whether or not the cause of the failure can be searched.

If the cause of failure can be sought, step S
At 14, for example, as shown in FIG. 24, the result of reasoning and the reasoning are displayed on the touch screen 1a, and the mechanic
Confirm this content and enter the "OK" window. Pen 2
If selected by, in step S15, information such as a procedure for replacing parts corresponding to the temporary construction, necessary procedure, etc. is displayed,
The process proceeds to step S16, and waits for the input of the treatment result from the maintenance staff, that is, the result of whether or not the malfunction is resolved.

When the maintenance staff replaces the parts presented on the touch screen 1a or inspects the necessary parts, the trouble phenomenon is resolved, or if the failure part can be identified, the verification is performed. Enter the content.

Then, the inquiry result by this inference is judged to be successful, and the confirmation screen of the result is displayed on the touch screen 1a in step S17. On the touch screen 1a, for example, as shown in FIG. 25, the history of the inquiry, the verification result, and the like are displayed, and the fact that the present inquiry is successful and the result of the inquiry is accumulated as a successful case. Display a dialog box.

When the maintenance worker confirms the contents of the dialog box and selects the "OK" window with the input pen 2, first, in step S18, the knowledge data stored in the FMECA type knowledge data storage unit 16c is stored. , The certainty factor (see FIG. 17) that connects the phenomenon selected in the present inquiry with the cause or the component is updated with a relatively high value because the present inquiry is successful.

Then, in step S19, the knowledge data stored in the diagnosis case type knowledge data storage unit 16a is added to the knowledge data.
The inquiry result of this time is added as a successful case, for example, “case-5721” in FIG. 26 and accumulated.

Next, in step S20, the history of this investigation is stored in the maintenance record data storage unit 17a together with supplementary information such as the date of diagnosis, the name of the person who made the diagnosis, and the failure diagnosis ends.

The data stored in the maintenance record data storage section 17a can be taken out via an external printing machine or the like. For example, as shown in FIG.
You can add up and add up.

On the other hand, in accordance with the rationale presented in step S14 above, in accordance with the treatment procedure displayed in step S15 above, parts have been replaced or necessary parts have been inspected, and as a result, the defect phenomenon has not been resolved. Alternatively, if the failure location is not specified, if the user inputs the fact in step S16, in step S17, the touch screen 1a is displayed, for example, as shown in FIG. , The dialog box
A confirmation screen is displayed to the effect that this inquiry was unsuccessful and to register as a failure case.

Then, when the maintenance staff confirms the contents of the dialog box and selects the "OK" window with the input pen 2, the FMECA is selected in step S18.
The certainty factor (see FIG. 17) of the knowledge data stored in the type knowledge data storage unit 16c that connects the phenomenon and the cause or the component selected in the present inquiry to each other, as shown in FIG. Update with a relatively low value.

Then, in step S19, the diagnostic case type knowledge data storage unit 16 is set with the result of the current inquiry as a diagnostic case.
For example, as shown in FIG. 29, the knowledge data stored in a is added as “case-5721” and accumulated.

By the way, in the fault diagnosing measure A, in steps S5, S6 and S7, when a satisfactory hypothesis is not generated and the cause of the fault cannot be investigated, or the conclusion derived by inference is based on the experience of oneself. If it is judged to be a mistake or if the failure investigation is unsuccessful this time, the maintenance personnel can make an independent investigation and acquire the result as knowledge.

That is, in the step S13, when the cause of failure cannot be searched as a result of the inference using the knowledge data, or when the same search result as the failure case is derived, The process branches to step S21, where the maintenance personnel independently investigate the failure.

Then, as a result of the inquiry, when the trouble phenomenon is resolved, in step S22, the background of the inquiry by the maintenance staff is input to the touch screen 1a. Then, in step S23, knowledge for accumulating as a knowledge base is acquired based on the input data, and the process returns to step S17 to display the inquiry result confirmation screen on the touch screen 1a.

When this display screen is confirmed and the "OK" window is selected by the input pen 2, step S18
Then, in the knowledge data stored in the FMECA type knowledge data storage unit 16c, the certainty factor (see FIG. 17) connecting the failure cause or the replacement part and the failure phenomenon clarified by this original inquiry is Update with a relatively high value.

Then, in step S19, the knowledge data stored in the diagnostic case type knowledge data storage unit 16a is added to
The result of this inquiry is added as a successful case and stored, for example, as “case-5722” in FIG.

As a result, as shown in "Case-5721",
Even if the conclusion hypothesis sought by inference fails, as shown in "Case-5722", by accumulating the independently sought knowledge in diagnostic case type knowledge data, if a similar failure occurs, It is possible to interpolate other knowledge data without generating a hypothesis similar to the failure case again by inference.

Then, the process proceeds to step S20, the history of this investigation is stored in the maintenance record data storage unit 17a, and the failure diagnosis is finished.

The data obtained by the maintenance worker's own inquiry is obtained by connecting the external printing machine as described above.
As shown in FIG. 30, it can be taken out to the outside by writing it on the defect recording form 21 or the like.

As described above, in the present invention, by verifying the hypothesis obtained by inference and inputting the result, it is possible to feed back to the knowledge base whether the search for the failure cause by inference is successful or unsuccessful. If successful, the knowledge data stored in the diagnostic case type knowledge data storage unit 16a is automatically updated. Therefore, by using the fault diagnosis apparatus A, a large amount of knowledge is accumulated and the success rate is gradually increased. Can be obtained. As a result, not only the maintenance cost of the knowledge base can be reduced, but also the usability is improved.

Further, since the maintenance staff's unique inquiry result can be acquired as knowledge, the potential knowledge of the maintenance staff can be acquired relatively easily, and the knowledge base can be constructed more precisely. . Furthermore, by registering failure cases, not only will conclusion hypotheses not be derived in the subsequent failure diagnosis, which will not only improve the efficiency of maintenance work, but will also input this failure case and the above-mentioned unique inquiry results. By combining the functions with the existing knowledge base, it is possible to effectively deal with the complicated diagnosis contents, and by using the failure diagnosis apparatus A, the success rate of the failure diagnosis can be increased similarly to the above. You can Moreover, by referring to the failure cases and the original inquiry results when revising the knowledge base, the inquiry results by inference can be narrowed down more precisely.

The present invention is not limited to the above embodiments, and the target of failure diagnosis is not limited to an aircraft, but may be an automobile, a vehicle such as a railroad, or a ship.

[0124]

As described above, according to the present invention,
By verifying the inquiry result obtained by inference and inputting the result, it is possible to feed back whether the inquiry result is successful or unsuccessful and accumulate knowledge, so that the failure diagnosis device is used enough It is easy to use.

As a result, not only the maintenance cost required for the modification of the knowledge base can be suppressed, but also the complicated diagnostic contents can be effectively dealt with by the existing knowledge base, and high reliability is ensured. Obtainable.

[Brief description of drawings]

FIG. 1 is a functional block diagram of a failure diagnosis device.

FIG. 2 is a flowchart showing an inference processing routine.

FIG. 3 is a flowchart showing an inference processing routine (continued)

FIG. 4 is a flowchart showing a hypothesis generation routine by diagnostic case inference.

FIG. 5 is a flowchart showing a hypothesis generation routine by FTA type knowledge base inference.

FIG. 6 is a flowchart showing a hypothesis generation routine by FMECA type knowledge base inference.

FIG. 7 is a flowchart showing a hypothesis conflict resolution routine.

FIG. 8 is an external view of the failure diagnosis device

FIG. 9 is an explanatory diagram showing a defect recording form.

FIG. 10 is an explanatory diagram showing an input screen of a defect phenomenon.

FIG. 11 is an explanatory diagram showing diagnosis case type knowledge data.

FIG. 12 is an explanatory diagram showing the calculation result of the similarity in the diagnosis case type knowledge base inference.

FIG. 13 is an explanatory diagram showing a hypothesis based on a diagnosis case type knowledge base inference by reliability.

FIG. 14 is an explanatory diagram showing FTA type knowledge data.

FIG. 15 is an explanatory diagram of a route search result in FTA type knowledge base inference.

FIG. 16 is an explanatory diagram showing a result of hypothesis generation by FTA type knowledge base inference.

FIG. 17 is an explanatory diagram of FMECA type knowledge data.

FIG. 18 is an explanatory diagram of a calculation result of similarity by FMECA type knowledge base inference.

FIG. 19 is an explanatory diagram showing a result of hypothesis generation by FMECA type knowledge base inference.

FIG. 20 is an explanatory diagram showing aggregation of hypotheses obtained by each inference.

FIG. 21 is an explanatory diagram of re-inference data.

FIG. 22 is an explanatory diagram showing aggregation of hypotheses obtained by re-inference.

FIG. 23 is an explanatory diagram showing a display screen during an interview.

FIG. 24 is an explanatory diagram showing a display screen of inference results and reasoning.

FIG. 25 is an explanatory diagram showing a display screen for confirmation of a successful inquiry result.

FIG. 26 is an explanatory diagram of diagnostic case type knowledge data in which a new successful case is registered.

FIG. 27 is an explanatory diagram showing a defect record sheet in which details of measures are described.

FIG. 28 is an explanatory view showing a display screen for confirmation of a failed inquiry result.

FIG. 29 is an explanatory diagram of diagnostic case type knowledge data in which new failure cases and successful cases independently searched for are registered.

FIG. 30 is an explanatory diagram showing a defect record sheet in which the contents of the measures by the original inquiry are described.

[Explanation of symbols]

 14 Inference Mechanism Section 15 Technical Information Collection Section 15a Data Collection Section 15b Case Registration Section 16 Knowledge Base Section

 ─────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Yasuo Kagei 1-7-2 Nishishinjuku, Shinjuku-ku, Tokyo Fuji Heavy Industries Ltd. (72) Inventor Masaaki Furuyama 1-2-7 Nishishinjuku, Shinjuku-ku, Tokyo Fuji Heavy Industries Ltd. (72) Inventor Kunihiro Abe 1-7-2 Nishishinjuku, Shinjuku-ku, Tokyo Inside Fuji Heavy Industries Ltd.

Claims (2)

[Claims] 1. A knowledge base section (16) for storing knowledge data necessary for failure diagnosis, an inference mechanism section (14) for inferring a failure cause by inference using this knowledge data, and a technical information collecting section ( 15), and a data collection unit (15a) for collecting input data as a result of verifying the hypothesis generated by the inference mechanism unit (14) in the technical information collection unit (15); A failure diagnosing device comprising: a case registration unit (15b) for accumulating the result of inquiry this time as a successful case in the knowledge base unit (16) when the phenomenon is resolved. 2. A knowledge base section (16) for storing knowledge data necessary for failure diagnosis, an inference mechanism section (14) for inferring a failure cause by inference using this knowledge data, and a technical information collecting section ( 15), and a data collection unit (15a) for collecting input data as a result of verifying the hypothesis generated by the inference mechanism unit (14) in the technical information collection unit (15); A failure diagnosing device comprising: a case registration unit (15b) for accumulating the search result of this time as a failure case in the knowledge base unit (16) when the phenomenon is not resolved.