JPH07281903A - Fault diagnostic device - Google Patents

Abstract

PURPOSE:To provide a fault diagnostic device which can surely collect the examples by fetching the present example as a success or failure example after the validity of treatment is confirmed even if the result of the treatment carried out according to the cause of a fault investigated by inference is not immediately confirmed. CONSTITUTION:At an example register part 15b, the present example is temporarily registered in a diagnostic example type knowledge data storage part 16a as the 'invalid' one if the validity of treatment is not immediately confirmed when the treatment is carried out based on the factor of a fault investigated by inference. Then the invalid example is fetched in the part 16a as the 'valid' one when the validity of the treatment is confirmed, and the knowledge data are updated. Thus the example is fetched as the knowledge data after the validity of treatment is confirmed so that the wrong examples are never fetched. As a result, the examples can be surely collected as the success or failure ones.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure diagnosis apparatus which uses a so-called expert system to search for a cause of a failure leading to a defective phenomenon of a vehicle, an aircraft or the like.

[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 failure cause (fault location) causing the phenomenon is explored using knowledge data represented by a set of rules. There are known ones that can be used, or those that can be searched using knowledge data that stores past diagnosis cases.

By the way, the knowledge data for storing the past diagnostic cases is a collection of past cases that actually occurred, and the symptoms and causes are uniquely described. Therefore, if the cause of failure is investigated as a result of failure diagnosis,
One case data is completed by this failure cause and the inputted trouble phenomenon. By registering this case data and updating the knowledge base, when a similar trouble phenomenon occurs thereafter, this case data is It can be used to immediately investigate the cause of failure.

[0005]

However, the above-mentioned search results merely predict the cause of failure or the location of the failure, and even if the corresponding parts are replaced, the failure phenomenon is still not solved, or In some cases, no abnormality is found even if the corresponding defective part is inspected.

If such an erroneous inquiry result is taken in and updated as knowledge data in the knowledge base, accurate case collection cannot be performed, and if a similar trouble phenomenon occurs thereafter, this erroneous inquiry will occur. The hypothesis is generated by the knowledge data obtained, which has a great influence on the accuracy of searching for the cause of failure.

The present invention has been made in view of the above circumstances, and it is possible not only to take the result of the search for the cause of the failure as knowledge data into the knowledge base unit but also to update the knowledge base due to an erroneous case. It is an object of the present invention to provide a failure diagnosis device capable of preventing and accurately collecting cases.

[0008]

In order to achieve the above object, a failure diagnosis apparatus according to the present invention uses a knowledge base unit for storing knowledge data necessary for failure diagnosis, and a defect input by using this knowledge data. The reasoning mechanism part for investigating the cause of failure corresponding to the phenomenon by reasoning and the search result by the reasoning mechanism part are registered in the knowledge base part as a case, and after the effectiveness of the treatment is confirmed, the case is described as knowledge data. It is characterized in that it comprises a case registration unit incorporated in the knowledge base unit.

[0009]

[Operation] In the failure diagnosis device according to the present invention, when the cause of failure is sought as a result of inference using knowledge data stored in the knowledge base, the result of this search is registered as an example in the knowledge base. To do.

On the other hand, the maintenance staff or the like takes measures such as replacement of the corresponding parts according to the result of the inquiry and confirms the effectiveness of the measures. Then, as a result of the action, when the malfunction phenomenon is resolved, the registered case is taken into the knowledge base unit as a successful case. Further, when the trouble phenomenon is not eliminated even if the measures are taken, the registered case is taken into the knowledge base unit as a failure case.

[0011]

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

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

As shown in FIG. 4, 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 by 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 or the like is input to the touch screen 1a using the input pen 2, the built-in computer causes the trouble phenomenon or The failure location is searched, and necessary information such as the search result and the inspection procedure is displayed on the touch screen 1a to support the maintenance personnel.

As shown in FIG. 1, a computer incorporated in the apparatus main body 1 is provided with a system control unit 13 as a function of controlling the entire system, and a window processing unit 12 and an inference unit as a function of executing a failure diagnosis. Mechanism 1
4, a technical information collecting unit 15, a knowledge base unit 16, and an operation record data unit 17 are configured.

The touch screen 1a is composed of an input section 11a and a display section 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.

The character recognition unit 12a converts a handwritten character such as a trouble phenomenon input by the maintenance staff using the input pen 2 into a pen input window (see FIG. 7) displayed on the touch screen 1a into a character code. , 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 unit 13 is provided with a man-machine interface control unit 13a, an operation mode control unit 13b, and a system management unit 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. In the operation mode control unit 13b, the use mode is fixed to the normal failure search mode or the case registration mode in accordance with the use mode selected and input by the maintenance staff, and the interruption / restart of the diagnostic process and the order management are performed. Controls the operation mode of the entire device including peripheral devices such as system data transmission. In the system management unit 13c, the system operation status, data management, etc.
Manage the entire system.

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

The case-based reasoning unit 14a searches the knowledge data stored in the diagnosis case type knowledge data storage unit 16a of the knowledge base unit 16 for a phenomenon which is the same as or similar to the trouble phenomenon input by the maintenance personnel. Then, a hypothesis of the failure cause or the failure location is generated.

In the rule-based reasoning unit 14b, the knowledge data stored in the rule-based knowledge data storage unit 16b provided in the knowledge base unit 16 based on the same or similar phenomenon as the trouble phenomenon input by the maintenance personnel or the like. The cause of failure or the location of failure is investigated by inference using to generate a hypothesis.

Then, the inference control section 14c judges the consistency of the hypotheses generated by the inference sections 14a and 14b, and derives a concluding 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, input data such as trouble items, inspection points, measured values, etc., which are input to the apparatus main body 1 by the maintenance personnel when investigating the cause,
Also, input data such as the history of the original investigation of the cause of failure or the location of failure and the contents of measures are collected and stored in the maintenance record data storage unit 17b described later for each case.

In the case registration unit 15b, the inquiry result by inference, the original inquiry process of the maintenance personnel and the like, the contents of the treatment, etc. are temporarily registered in the diagnostic case type knowledge data storage unit 16a, which will be described later, as a case of this time. Next, when the trouble is resolved as a result of taking measures such as replacing parts according to the inquiry result, the registered case is taken as a successful case into the diagnostic case type knowledge data storage unit 16a, and the knowledge data storage unit 16a is acquired. Update the knowledge data stored in. On the other hand, when it is confirmed that the trouble phenomenon is still not resolved even if the above-mentioned measures are taken, the registered case is taken as a failure case into the diagnostic case type knowledge data storage unit 16a and stored in the knowledge data storage unit 16a. Update the knowledge data that is being provided.

The knowledge base unit 16 includes a diagnostic case type knowledge data storage unit 16a for storing diagnostic case type knowledge data, a rule type knowledge data storage unit 16b for storing rule type knowledge data, and an electronic unit for storing computerized manual data. And the manual data storage section 16c.

The above-mentioned diagnostic case type knowledge data is a data base that summarizes the search results of past failure causes as examples,
As shown in FIG. 10 or FIG. 12, for each case, a failure phenomenon (or a location where the failure occurs), a cause of failure and its remedy, a defective part, a type of knowledge source, and effectiveness as knowledge data Etc. are stored. The knowledge source of the diagnostic case type knowledge data includes a defect record form, a maintenance record form, and an interview with a maintenance worker. In this interview, know-how such as non-textualized maintenance procedures and cause investigations conducted for maintenance personnel were collected and reflected in the diagnosis cases. Further, the validity is “invalid” until the validity of the treatment result of the diagnosis case is confirmed, and becomes “valid” when the validity is confirmed, and thereafter it can be used as knowledge data. Become.

As shown in FIGS. 6 and 13, the defect record sheet has a column for recording "defective matters and inspection points" discovered by the occupant and a column for recording "procedures" performed by maintenance personnel. Is provided. 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 rule-type knowledge data stored in the rule-type knowledge data storage unit 16b is analyzed by analyzing design materials and experience of experienced maintenance personnel and the like, and the failure phenomenon and the cause of failure are logically analyzed for each system of component parts. It is expressed as a set of rules after being dynamically analyzed, and in certain cases, a certainty factor may be attached to show the depth of connection between the intermediate hypothesis and the conclusion hypothesis.

Specifically, as rule type knowledge data,
Failure tree analysis (FTA) type knowledge data that theoretically analyzes the causal relationship between failure phenomena and failure causes and is represented in a tree as a temporary collection, and connects failure phenomena and failure causes with a certainty factor Failure mode effect analysis arranged in matrix form (matrix with confidence factor; FM
ECA) type knowledge data is adopted.

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. The data of the booster / pump graphic and the inspection procedure of the booster / pump can be read from the electronic manual data and displayed on the window 1a.

The operation record data section 17 is composed of a work progress temporary storage section 17a and a maintenance record data storage section 17b.

In the work progress temporary storage section 17a, for example, in the case of interruption for arranging replacement parts during maintenance and then restarting the failure diagnosis, it is possible to continue from the interrupted maintenance work. To be able to
The progress of the maintenance performed by the maintenance staff or the maintenance status is sequentially stored. Further, the maintenance record data storage unit 17b stores, for each case, measures against trouble phenomena, inspection results, and status of test operation, or maintenance information when a maintenance worker or the like independently searches for a cause of failure. .

Next, the failure diagnosis procedure will be described with reference to FIGS.
In accordance with the flowchart shown in FIG. 5, a description will be given while appropriately illustrating the malfunction of the fuel system of the aircraft.

When the power switch of the apparatus body 1 is turned on,
As shown in FIG. 5, a use mode selection screen is displayed on the touch screen 1a of the apparatus body 1, and a maintenance worker or the like selects the current use mode (window) from the displayed mode with the input pen 2. In step S1, the use mode selected by the input pen 2 is determined. This usage mode includes a normal failure search mode and a case registration mode. In this case registration mode, a case in which the validity of the treatment result has not been confirmed is called, and the treatment result indicating whether the failure search has succeeded or failed is input.

In the following description, the case where the failure investigation mode is selected will be described first, and then the case registration mode will be described.

When the maintenance worker selects the normal failure search mode (start of diagnosis) in step S1, the process proceeds to step S2, where the current use mode is fixed to the failure search mode,
The process proceeds to the inference execution routine for fault investigation in steps S3 and S4 and thereafter.

When the process proceeds to the inference execution routine, the touch screen 1a has a window for inputting a defect phenomenon and a pen input window for inputting the defect phenomenon in a text expression as shown in FIG. Is displayed.

Therefore, in step S3, the maintenance worker or the like refers to the form such as the defect recording form 21 (see FIGS. 6 and 13) handed over to each window, and it is necessary to determine the movable state of the aircraft system. An item and a defect item, or a defect phenomenon (symptom) transmitted from an occupant or the like is input using the input pen 2. In step S4, the measured value from the tester connected to the inspection location of the aircraft is directly input. Then, after completing the input of necessary items and selecting (pointing) the "end of input" button with the input pen 2, the process proceeds to step S5, and the input information (date, mission, contents, etc.)
Is stored in the internal memory as input data.

Next, steps S6 and S7 are executed in parallel (concurrent processing), and in each of steps S6 and S7, the diagnostic case type knowledge data storage unit 1 provided in the knowledge base unit 16 is executed.
Based on the respective knowledge data stored in 6a and the rule-type knowledge data storage unit 16b, the cause of failure is inferred to be investigated and a hypothesis is generated.

That is, in step S6, the cause of failure is sought by case-based reasoning to generate a hypothesis. This case-based reasoning is executed by the case-based reasoning unit 14a of the above-mentioned reasoning mechanism unit 14, and utilizes the diagnosis case type knowledge data stored in the diagnosis case type knowledge data storage unit 16a of the knowledge base unit 16. To generate a hypothesis. This diagnostic case type knowledge data is registered in advance, or is composed of past cases explored using this failure diagnosis apparatus A,
At the time of inference, a defect phenomenon similar to or the same as the defect phenomenon input in step S3 is selected from each knowledge data, and the cause corresponding to the defect phenomenon at this time is selected based on the selected knowledge data. A hypothesis for solving a malfunction phenomenon such as a target part or required treatment is generated.

In step S7, the cause of failure is searched for by rule-based reasoning and a hypothesis is generated. This rule-based inference is based on the rules of the inference mechanism unit 14 described above.
The hypothesis is generated by using the rule type knowledge data stored in the rule type knowledge data storage unit 16b of the knowledge base unit 16, which is executed by the base inference unit 14b.
This rule-based knowledge data is expressed as a set of rules by analyzing design materials and experience of experienced maintenance personnel, and logically analyzing failure phenomena and failure causes for each system of component parts. In this case, based on this knowledge data, the route connecting the trouble phenomenon and the cause which seems to have the deepest causal relationship to this trouble phenomenon is searched for according to the rule, and a hypothesis for conclusion is generated.

When the inference is completed in the above steps S6 and S7 and the hypothesis is generated, the process proceeds to step S8,
The consistency of the hypotheses generated by the inference units 14a and 14b is determined.

This judgment of the consistency of the hypothesis is executed by the inference control section 14c of the inference mechanism section 14, and when the hypotheses generated in the above steps S6 and S7 conflict, the 1 Focus on one hypothesis and resolve the conflict.

As a criterion for resolving this hypothesis conflict,
For example, the knowledge data stored in each of the knowledge data storage units 16a and 16b are prioritized, or the certainty factor indicating the strength of the connection between the failure phenomenon and the failure cause is calculated for the generated hypothesis. For example, select the one with the highest certainty.

When one hypothesis is narrowed down in step S8, the process proceeds to step S9, and it is determined whether the inference is completed. For example, if the hypotheses generated in steps S6 and S7 match, or even if the inference is repeated a preset number of times or more, the hypotheses generated in steps S6 and S7 do not match, and therefore one When the hypotheses are narrowed down, or no hypotheses are generated at all, it is judged that the inference is completed. On the other hand, in step S6,
If the hypotheses generated in S7 conflict with each other and there is room for re-inference, it is determined that the inference is not completed.

When the inference is not completed, the process returns to steps S6 and S7, and the inference is performed again by combining the input data stored in the internal memory and the hypothesis narrowed down in step S8. When the inference is completed, the process proceeds to step S10.

In step S10, it is determined whether or not there is another inspection item. If there is an inspection item, the process branches to step S11. Whether or not there is an inspection item is determined by, for example, whether it is necessary to verify the hypothesis derived as a conclusion or to further scrutinize it.

Then, when it is judged in the above step S10 that there is an inspection item, and the process branches to step S11, the contents of the inquiry required for this inspection item are narrowed down, and the step S
At 12, the contents of the inquiry are displayed on the touch screen 1a, and at the same time, the contents of work such as related inspection procedures and necessary information are displayed as shown in FIG. 8, for example. Then, the process returns to steps S3 and S4 and waits for the input of the inspection result from the maintenance staff or the like.

When a maintenance worker or the like inputs the inspection result to the touch screen 1a by using the input pen 2 or directly inputs the measurement result from the tester, step S5
Then, this input data is stored in the internal memory, and in steps S6 and S7, the cause of the failure is sought by re-inference based on each knowledge data.

After the inference is completed, the process proceeds from step S9 to step S10. If it is determined in this step S10 that there are no other inspection items such as hypothesis verification, the process proceeds to step S13, and the cause of failure can be investigated. Determine whether

When the cause of the failure can be investigated, step S
14, the reasoning result and the reasoning are displayed on the touch screen 1a as shown in FIG. 9, and when the maintenance staff or the like confirms the content, the reasoning shown in step S14 is performed in step S15. Determine whether the action corresponding to the result is possible on the spot. When the treatment is difficult on the spot, for example, according to the inference result shown in FIG. 9, the booster / pump needs to be replaced, but the parts cannot be procured, or it is necessary to perform the work in a dedicated workshop. Such is the case.

When the maintenance staff or the like determines that it is difficult to perform the treatment on the spot, for example, "File (F)" displayed in the title bar of FIG. 9 is selected.
Then, the save screen is displayed on the touch screen 1a, and the routine jumps from step S15 to step S20. Then, on this save screen, enter the supplementary items at the time of this failure diagnosis, such as points that the maintenance staff particularly noticed, or the data that you forgot to enter, and click "Save".
If you select, the maintenance data of this time is the operation record data section 1
No. 7 is stored in the work progress temporary storage unit 17a, and the inference process ends.

Then, when necessary measures are taken in accordance with the search result and the maintenance data stored in the work progress temporary storage section 17a is read, the failure diagnosis is restarted and the diagnosis is continued from the display screen of step S14. It will be.

On the other hand, when the maintenance staff or the like refers to the reason for inference shown in FIG. 9 and determines that the treatment can be performed on the spot, “OK” in the dialog box displayed on the left half of the figure. Select the button with the input pen 2 (point)
Then, the process proceeds to step S16, the treatment result input screen is displayed, and the maintenance staff or the like inputs the treatment result. As a result of this treatment, for example, the specified parts were replaced,
If it takes some time to determine whether the problem has been resolved, enter "-replace, -watch",
If fast disconnection is possible, enter "-replacement, -test run, -good".

Then, when the input of the treatment result is completed, the process proceeds to step S17, and the touch screen 1a displays a selection screen as to whether or not the treatment result can be quickly disconnected. The case where the treatment result can be quickly cut is a case where, for example, "-replacement, -test run, -good" is input in the above step S16, and the case where the quick disconnection cannot be made, for example, the defect phenomenon is still solved even if the parts are replaced. However, this is the case when "-exchange, -see state" is input in step S16.

Then, if the treatment result is something that cannot be promptly selected, a button to that effect is selected, and step S21 is performed.
In the case registration unit 15b, the current diagnosis result is stored in the diagnosis case type knowledge data storage unit 16a, for example, as shown in FIG.
As shown in “Case-5721” of 0, the validity is registered as “invalid”. This effectiveness is a criterion for judging whether it can be effectively used as knowledge data, and when it is confirmed that the trouble phenomenon has been resolved at the time of completion of the treatment, or is still not resolved. , The knowledge data is taken into the diagnostic case type knowledge data storage unit 16a as valid and the knowledge data is updated. However, when the treatment is completed, the trouble phenomenon cannot be resolved, but it is not possible to quickly disconnect, and it is necessary to see the situation for a while. The gender is set as "invalid" and the knowledge base is not updated only by registering.

Then, returning to step S20, information such as supplementary items noticed by the maintenance personnel is input to complete the failure diagnosis. This supplementary item is the maintenance record data storage unit 17b.
Is stored for each case.

On the other hand, in step S16, when the current treatment result is, for example, "-replacement, -test operation, -good" is input, the current treatment result can be fast-judged. When the fact that the search has been completed is input, the process proceeds to step S18, and a confirmation screen is displayed on the touch screen 1a to the effect that the search result of this time is successful. This confirmation screen is displayed, for example, by displaying the history of the inquiry and the fact that the result of this inquiry is successful, as shown in the right half of FIG.

Then, the maintenance staff or the like confirms the inquiry result confirmation screen displayed on the touch screen 1a, and if there is any correction, corrects it as necessary and selects the "confirmation end" button. When the dialog box shown in is displayed, and the user understands this, the process proceeds to step S19, and the above described case of validity is taken into the diagnosis case type knowledge data storage unit 16a as “effective” and the present case is taken as a success case. Then, the knowledge data is updated.

Then, in step S20, in the same manner as described above, supplementary items are input to complete the failure diagnosis.

By the way, when the hypothesis is not generated as a result of the inference in the above steps S6 and S7, the maintenance staff or the like tries to independently investigate the failure. Whether or not the cause can be investigated in this fault diagnosis is judged in the above step S13, and if the cause cannot be investigated, step S25.
Branched to and maintenance personnel and others independently investigate the cause from their own knowledge and experience. Then, in step S26, the contents thereof, that is, the background of the inquiry, the treatment contents, etc. are input.
Then, in step S27, the unique inquiry result is acquired as knowledge, the process returns to step S18, and the inquiry result confirmation screen is displayed in the same manner as described above. The unique inquiry result is taken as a success case and is taken into the diagnosis case type knowledge data storage section 16a of the knowledge base section 16 as "effectiveness", and the knowledge data is updated. Then, step S20
Proceed to to enter the supplementary items that maintenance personnel have noticed, such as the precautions for inspection, and complete the failure diagnosis.

As a result, by inputting a unique inquiry result, the potential maintenance ability of a maintenance worker or the like can be acquired as knowledge.

On the other hand, after the treatment is completed, the above step S21
Then, a case ("Case-572" in FIG. 10 that is once registered as "invalid" in the diagnosis case type knowledge data storage unit 16a is registered.
1)) is confirmed, the device body 1 is turned on.
N, and in step S1, the case registration mode is selected from the initially displayed use mode selection screen (see FIG. 5).
Then, the process branches to step S31, and the use mode is fixed to the case registration mode, and in step S32, the maintenance worker or the like applies the corresponding case number (for example, “case-572 in FIG. 10”).
1)) is input or selected to call the case stored in the diagnosis case type knowledge data storage unit 16a.

Next, in step S33, it is determined whether the previous failure diagnosis was successful, and if the maintenance engineer or the like inputs that it is successful, the process returns to step S18 and the touch screen 1a
The inquiry result confirmation screen is displayed on. This confirmation screen is displayed, for example, as shown in the right half of FIG. 14, and when the displayed contents are corrected as shown in the right half of FIG. 11, and the “confirmation end” button is selected, When the dialog box shown on the left half of the figure is displayed and you confirm the contents and select the "OK" button, step S
At 19, the case is taken into the diagnostic case type knowledge data storage unit 16a as a successful case, and the knowledge data is updated. At this time, as described in FIG. 12, the description item of the validity of the “case-5721” becomes “valid”, and thereafter, this case can be used as knowledge data at the time of failure investigation.

When the failure search result once registered as "invalid" is checked after the completion of the treatment, and it is confirmed that the failure search result is a failure, step S33.
Then, if a failure is input, the process proceeds to step S34, a confirmation screen as shown in the right half of FIG. 14 is displayed on the touch screen 1a, and if the "end confirmation" button is selected, the same screen is displayed. When the dialog box as shown on the left half is displayed, and if the user understands this, in step S35, the case called this time is regarded as a failure case in the diagnosis case type knowledge data storage unit 16a by setting its effectiveness as "effective". Captured and knowledge data updated.

Then, the process returns to step S20, the supplemental items are input by the history of the investigation and the contents of the treatment, and the failure diagnosis is finished.

As described above, in the present embodiment, when the treatment according to the result of the search for the cause of the failure is completed, even if the validity of this treatment cannot be immediately confirmed, the registration is made first, so that the omission of the collection of cases is eliminated. Further, since it is not used as knowledge data until the effectiveness of the treatment is confirmed, erroneous knowledge data is not accumulated. Furthermore,
Since the above case is made available as knowledge data after confirming the effectiveness, it is possible to accurately collect the success case and the failure case.

Further, the present invention is not limited to the above-mentioned embodiments, and for example, 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.

[0070]

As described above, according to the present invention,
When the cause is sought by inference, if the effectiveness of the action according to the sought result cannot be immediately determined, it is only registered as a case, and when the effectiveness can be confirmed later, this case is taken into consideration Since the data is updated, the knowledge base is not updated by an erroneous case, and not only the successful case but also the failed case can be collected as an accurate case.

Further, since the inquiry result is once registered as a case, there is no omission of collection of cases, and the knowledge base can be maintained relatively easily.

[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 an external view of the failure diagnosis device.

FIG. 5 is an explanatory diagram showing a use mode selection screen.

FIG. 6 is an explanatory diagram showing a defect recording form in which a defect phenomenon is described.

FIG. 7 is an explanatory diagram showing an input screen for a defect phenomenon.

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

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

FIG. 10 is an explanatory diagram of diagnostic case type knowledge data for accumulating knowledge data before validity confirmation.

FIG. 11 is an explanatory diagram showing a display screen for confirmation of inquiry results.

FIG. 12 is an explanatory diagram of diagnostic case type knowledge data for accumulating knowledge data after validity confirmation.

FIG. 13 is an explanatory diagram showing a defect record sheet in which details of investigation and details of treatment are described.

FIG. 14 is an explanatory diagram showing a display screen for confirming that failure cases are accumulated.

[Explanation of symbols]

 14 Inference mechanism 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 (1)

[Claims] 1. A knowledge base section (16) for storing knowledge data required for failure diagnosis, and an inference mechanism section for inferring a failure cause corresponding to an input failure phenomenon by inference using this knowledge data ( 1
4) and the inquiry result by the inference mechanism section (14) are registered in the knowledge base section (16) as a case, and after the effectiveness of the treatment is confirmed, the case is regarded as knowledge data in the knowledge base section (16). And a case registration unit (15b) which is incorporated into the failure diagnosis device.