JPH0795286B2 - Failure diagnosis method - Google Patents

Description

Description: FIELD OF THE INVENTION The present invention relates to a failure diagnosis method, and more specifically, it is suitable for diagnosis of a failure that requires a complicated test procedure and is applied to, for example, a network or an electronic device. Regarding diagnostic methods.

[Background of the Invention]

Recently, electronic devices such as computers have become widespread with the progress of the information-oriented society, but in the fields of maintenance and diagnosis, there are many demands to make failure diagnosis and maintenance work as automated as possible.

In the past, when maintaining or diagnosing electronic devices such as computers, general maintenance personnel read and understand the maintenance / diagnosis manuals jointly created by the designer and specialized maintenance personnel in advance. . The work often involved tests that required complicated switch operations, and the work was extremely troublesome. Further, since the maintenance / diagnosis manual created as described above is of the float chart type, it is difficult for a general maintenance staff to understand what principle the relation between items is based on. However, it was difficult to deal flexibly with different causes of failure. Furthermore, it was difficult for anyone other than the person in charge of creating the manual to update the manual by adding a new cause of failure or a test method.

For example, when a subscriber i tries to call another subscriber j in a private branch exchange, he picks up the handset and turns the dial, and the dial tone does not come back forever. After that, when the maintenance personnel who received the notification from the subscriber i examined the maintenance manual, it was found that the failure symptom was not described. At this time, the maintenance personnel examine the operation sequence of the private branch exchange, etc., and further utilize the failure diagnosis know-how to identify the failure range,
The source of failure must be identified. In this case, you may not want to wait for the opportunity to utilize the existing maintenance manual in the process of failure diagnosis, or you may be able to utilize the existing maintenance manual when the failure range is separated to some extent. In this way, the maintenance staff investigates, considers,
During the trial and error test, some or all of the system becomes unusable. At this time, there is a possibility that the system may be down for a long time depending on the extent of the failure and how the maintenance personnel deal with it. Further, it is assumed that the maintenance personnel finally finds the failure source, takes appropriate action, and the system is restored again. At this time, there arises a problem of how the maintenance staff in charge makes use of the new maintenance / diagnosis know-how acquired in the maintenance work at the next opportunity. In other words, in the conventional method of using the maintenance / diagnosis manual, it takes time and time to collect and process the maintenance / diagnosis communication form created by the maintenance staff at the service center, process it, and perform the next maintenance manual update. In addition, there is a problem that it is not easy for the maintenance staff to accurately reflect the know-how acquired at the site on the maintenance manual due to the expression means, the number of sheets, etc.

[Object of the Invention]

An object of the present invention is to eliminate such a conventional defect and provide a failure diagnosis method for diagnosing while automatically selecting a test operation for failure diagnosis.

Another object of the present invention is to provide a failure diagnosis method that allows general maintenance personnel to flexibly deal with a failure that is not expected in advance and to easily change or add a test method. is there.

[Outline of Invention]

In order to achieve the above object, in the failure diagnosis method according to the present invention, the test item to be executed for the diagnosis target object is registered in advance in the first table with the correspondence relationship between the symptoms of the failure occurring in the diagnosis target object and the test items. And the cause of the failure determined according to the test result for the test item, or the relationship with the test item to be executed next is registered in the second table in advance, and the failure is detected in the diagnosis target. , The diagnostic device automatically selects the test item to be executed first from the first table according to the failure symptom, and determines the failure item from the second table according to the test result for the test item. A feature is that a cause or a test item to be executed next is obtained, and tests are sequentially executed for the test items according to the second table until the failure cause is specified. To.

Further, in the modified example of the present invention, data for displaying the function of the diagnosis target object as a combination of operation sequences including a plurality of operation elements, and diagnostic know-how prepared corresponding to each of the operation elements are stored in advance. By registering, when the diagnostic object shows a failure symptom whose failure cause cannot be identified by the automatic diagnosis according to the first table and the second table, the operation of the diagnostic object based on the above data. The sequence diagram is displayed on the display screen, and when the maintenance staff designates one operation element on the operation sequence diagram, the diagnostic know-how corresponding to the operation element is displayed on the display screen.

Example of Invention

 First, a first embodiment of the present invention will be described.

FIG. 1 is a block diagram of a failure diagnosis device showing an embodiment of the present invention.

In FIG. 1, reference numeral 1 is a general control unit, 2 is a general control memory, 3 is an input / output unit for maintenance personnel, and 4 is a coupling unit for a failure diagnosis target.

The input / output unit 3 for maintenance personnel includes a display unit 9 for displaying the contents of operation instructions to the maintenance personnel and the progress of diagnosis, and an input unit 10 for receiving the input operation by the maintenance personnel.

First, regarding the maintenance / diagnosis manual for the CPU power supply shown in FIG. 2, the Petrinet-type graph of FIG. 3 corresponding to the above failure diagnosis procedure is stored in the integrated control memory 2 of FIG. "Present state of petrinet with expanding application fields", Nikkei Electronics, June 9, 1980, pp. 146-169) is stored.

FIG. 3 is a diagram in which the failure diagnosis procedure of FIG. 2 is replaced with a Petrinet type graph.

In FIG. 3, arrows indicate the paths through which the events that occur propagate. For example, if event 31 (power supply abnormality of the CPU chassis) occurs, event 34 (check the fan of the system chassis) occurs. Shows. Also, the gate indicates an AND condition. For example, if event 34 (check the fan of the system chassis) and event 33 (the fan turns) occur at the same time, gate 36 opens and event 39 (CPU chassis (Turn on the power switch of).

FIG. 4 is a block diagram of the synchronous step definition table in the integrated control memory 2 of FIG. Failure symptoms shown in Fig. 3
As for the synchronization between 31 (power failure of CPU chassis) and test operation 34 (check fan of system chassis), as shown in the synchronization step 1 shown in FIG.
1, 34 is registered as the output event number. Also test operation
34 (check fan of system enclosure) and test results 33
(For turning the fan) and for test operation 39 (turn on the power switch of the CPU chassis), wait for the synchronization.
As shown in synchronous step 2 in the figure, the input event number is 34
And 33 and 39 as the output event number are registered.

The specific contents of each event indicated by these event Nos. And information regarding execution are described in the propagation management table 6 in FIG.
In FIG. 5, it is stored in the form shown in FIG.

In FIG. 5, the propagation state includes a propagation waiting state and a propagating state. The propagation waiting state is indicated by “0” and the propagating state is indicated by “1”. This indicates whether the event content corresponding to the event number is being propagated or is waiting to be propagated. The event No. in each column is as follows from the event information stored in the display message table 7 or the test operation message table 8 in FIG. It is a pointer that gives a starting point for searching for event information to be transmitted to the combining unit 4 for the target.

That is, the display message table 7 corresponds to the first event corresponding to the event number activated by the central control unit 1 in accordance with the synchronous step definition table 5 and the propagation management table 6.
Register the event information to be sent to the display section in the figure.

FIG. 6 is a block diagram of the display message table 7 of FIG. Register the corresponding message for the event number related to events other than the test operation.

For example, in FIG. 6, the display message “power failure of CPU chassis” is registered in correspondence with event No. 31.

When an event other than the test operation occurs, the integrated control unit 1 displays the corresponding message on the display unit 9 in FIG. 1 and provides the maintenance personnel with information regarding the failure diagnosis progress.

FIG. 7 shows the test operation message table 8 of FIG.
It is a block diagram of.

In FIG. 7, the test operation content “Check system enclosure fan” is registered in the display message field 82 corresponding to the event No. 34. In the transmission signal column 83, the signal K1 to be transmitted to the coupling unit 4 for the failure diagnosis target in FIG. 1 is registered. In the received signal column 84 and the propagated event column 85, the signal J1 received corresponding to the test result 33 (Huang turns) and the event No. 39 propagating at that time are registered as a pair, and the received signal column 86 and In the propagation event column 87, the signal H1 received corresponding to the test result 35 (the fan does not rotate) and the event No. 41 propagating at that time are registered as a pair.

The overall control unit 1 uses these tables to control the synchronization of the propagation of a plurality of events.

FIG. 8 is a diagram showing the configuration of the overall control unit 1 in FIG.

In FIG. 8, 91 is an event propagation determination unit, and 92 is a propagation event N.
o. Reading unit, 93 is a test result generating unit, 94 is a message reading unit, 95 is a test message transmitting unit, 96 is a test result signal latch unit, and 97 is a display message transmitting unit. The event propagation determination unit 91 reads the input event No. and the output event No. from the synchronous step definition table 5 and the propagation management table 6, and determines the synchronous step No. that can be propagated according to the flow chart shown in FIG. Select it and send it to the propagation event number reading unit 92.

Here, the flow chart of FIG. 9 performs the following processing.

(1) In step 901, 1 is set as the synchronous step No. to be checked first in the synchronous step definition table of FIG.

(2) In step 902, the synchronous steps No. 1 to 1 in FIG.
It is determined whether all 5 have been examined.

(3) At step 904, the input event No. 31 is read corresponding to the synchronous step 1 of FIG.

(4) In step 905, the input event No. 31 read in (3) above is examined in the propagation management table of FIG. 5 and the corresponding propagation state is identified as bit 0, that is, the state of waiting for propagation.

(5) In step 906, the result checked in (4) above is
If all the input event numbers read in (3) above are being propagated, go to the next step 907, otherwise go to step 908.
Go to.

(6) In step 907, the synchronization step No. is set to the propagation event N.
o. Send to the reading section.

(7) At step 908, the next synchronization step N to be checked.
o. is set.

According to the flow chart shown in FIG. 10, the propagating event No. reading unit 92 first uses the synchronous step No. sent from the event propagating determination unit 91 in step 1001 to find the corresponding information from the synchronous step definition table (FIG. 4). Read the output event No.
It is sent to the message reading unit 94. And step 10
At 02, all the input event numbers in the propagation management table of FIG. 5 are set to “0” waiting for propagation, and at step 1003, the output event numbers of the propagation management table of FIG. 5 are being propagated to “1”.
And As a result, event N in the propagation management table in Fig. 5
Propagation state 1 of o.31 is 0, propagation state 0 of event No. 34 is 1
Changes to.

Based on the event number sent from the propagation event No. reading unit 92, the message reading unit 94 first follows the flow chart shown in FIG. Whether the obtained event number is in the display message table 7 or the test operation table 8 is determined by referring to the display message table (FIG. 6) and the test operation table (FIG. 7). Then the propagation event
If the event No. sent from the No. reading unit 92 is a test operation, the message in the column corresponding to the event No. in FIG. 7 is read in Step 1103, and otherwise 110 in FIG. 6 is read. Of these, the message in the column corresponding to the event number is read. When the message of FIG. 7 is read in step 1103, in step 1104 the display message 82 is sent to the display message transmitting section 97, and in step 1105 the transmission signal is sent to the test message transmitting section 95. The integrated control unit 1 automatically performs a test according to the transmission signal on the failure diagnosis target connected through the connection unit 4. Then, the result is received by the test result signal latch unit 96 as a reception signal and further transferred to the test result generating unit 93. Based on the signal received from the test result signal latch section 93, the test result generating section 93 reads out the propagation event paired with the received signal from the test operation table of FIG. 7, and the propagation management of FIG. The propagation status of the corresponding propagation event No. in the table is set to "1" during propagation.

For example, if the received signal J1 is received during the test operation of event No. 34, the propagation management event No. 39 is read according to the table of FIG. 7, and then the event of FIG. Change the propagation state corresponding to No. 39 to "1" during propagation.

Then, the process flow of the event propagation determination unit 91 (FIG. 9) is 90.
The process returns to 8.

By repeating the above operation, the overall control unit automatically generates the test operation signal and identifies the cause of the failure in the failure diagnosis according to the sequence stored in the table in the integrated control memory.

The display message 82 is displayed by the display message transmission unit 97.
It is transmitted to and displayed on the display unit 9 of FIG. When the test for the failure diagnosis target is automatically performed as described above, a display message for notifying the maintenance staff of the current diagnosis status is displayed on the display unit 9. When the automatic diagnosis cannot be performed, the display unit 9 displays the diagnostic know-how prepared in advance for the failure diagnosis target as a display message. The maintenance staff performs a test according to these diagnostic know-how, and inputs the result from the input unit 10.

If the true source of the failure can be identified for the given failure symptom according to this procedure, the operation ends. However, the failure source estimation result obtained by this procedure may not always be correct. This occurs when there is a leak in the maintenance / diagnosis manual as shown in FIG. For example, assume that a failure source such as "ALM lamp deterioration" that is not shown in FIG. 2 has occurred and brings about the same failure symptoms and test results as 26 "Hiuse disconnection". At this time, if the failure diagnosis is performed according to FIG. In this case, the maintenance / diagnosis work is continued as follows.

(1) The maintenance staff examines other information, for example, the design drawing or specifications of the diagnosis target, makes an inquiry to the relevant department of the manufacturer, and performs a new operation for estimating the true failure source. In this case, as one piece of information that can be referred to, a directed graph showing the operation principle as shown in FIG. 12 obtained by partially changing the direction of the arrow of the directed graph showing the test procedure of FIG. 3 is used. The true source of failure is 44 in the directed graph of Figure 12.
It has the same effect as when the "Hiuse disconnection" occurs. That is, when a true failure source occurs, failure symptoms
31 “CPU chassis power failure” occurred, and then test operation 34
When "Check the fan of the system case" is executed, the test result 33 "The fan turns around" occurs, and then the test operation 39 "Turn on the power switch of the CPU case".
Performing the test results in test result 38 "ALM lamp not lit". The true failure source is estimated based on such characteristics of the true failure source.

(2) After the true failure source "ALM lamp deterioration" is discovered, the maintenance personnel operates the "I / O section 3 for maintenance personnel" in Fig. 1 to make the first error in Fig. 3. A box of 46 "ALM lamp deterioration" is created and added to Fig. 3 so that it is connected to the same gate as the failure source estimated to be "fuse blown" 44. This is because the input event 38,3 is newly added to the column 6 of the synchronous step in the synchronous step definition table of FIG.
This is equivalent to adding the item of 9, output event 46. If you update the table like this, the same 46 "ALM
If "lamp deterioration" occurs, it will be narrowed down to at least two failure source candidates, 44 "use of fuse" and 46 "ALM lamp deterioration". However, at this stage
No new test items will be added to distinguish between 45 “use off” and 46 “ALM lamp deterioration”.

(3) Experienced maintenance specialists at the stage when new failure source candidates such as 46 “ALM lamp deterioration” in (2) above were accumulated to some extent in 2 “Integrated control memory” in FIG. 2. Using the experience, know-how, knowledge, etc., the house etc. perform new test operations, add test results and reconstruct the directed graph for the directed graph to which new failure source candidates have been added.
Recreate the directed graph for maintenance / diagnosis so that fault diagnosis can be performed efficiently, including the added fault source candidates.

Next, a second embodiment of the present invention will be described.

FIG. 13 shows an example of a directed graph showing the operation of the failure diagnosis target. In FIG. 13, a portion excluding a range surrounded by a dotted line represents an operation sequence in the case where a failure does not occur, and a range within a dotted line represents an operation when the failure occurs. This directed graph is created as follows.

(1) Modeling of normal operation: The diagnosis target is considered as a sequential machine, and the operation sequence is expressed using Petrinet. The box (□) in Fig. 13 indicates one "operation" of the system, the gate (transition) indicates "switching" of the operation, and the arc → indicates switching between those operations. Represents the order relation of. The small black dot (•) token in the box indicates that the operation is “in execution”. The gate is an AND gate, and when all the operations of the input side box are completed, the operation is switched to the output side box. At this time, the token moves from the input box to the output box accordingly.

(2) Provision of diagnostic know-how: The diagnostic know-how is classified into two types.

(A) Random diagnosis know-how: A failure source that causes a certain operation to fail to execute, and when the failure source occurs,
A list of test methods to confirm it. This can be modeled by drawing an arc from the box representing its operation and coupling it to a Petrinet representing the test procedure for the failure source, as shown by blocks 1326 and 13231 in FIG. If there are a large number of failure source candidates, the random diagnostic know-how does not include information to isolate them.

(B) Structured diagnosis know-how: Random diagnosis know-how is structured so as to include information for separating a large number of failure source candidates. As shown in blocks 1327 and 13232 in FIG. 13, this can be converted back into a diagnostic procedure that limits the range of failure sources in a tree-like manner depending on the test and the test result. The structured diagnostic know-how can include the specialist know-how such as in which order the tests should be performed to find the failure source most efficiently.

When the diagnostic know-how is expressed by a Petrinet and is coupled with a normally operating Petrinet as shown in FIG. 13, it can be modeled as a failure source that causes a malfunction by setting the gate of the coupling portion as a passage priority gate. In other words, if any failure source occurs, the token of the relevant box escapes to the passage priority gate, and the next gate in the normal operation petrinet cannot fire. This means that the operation of the relevant box becomes inoperative.

The Petrinet, which is the directed graph created in this way, is replaced with the synchronous step definition table in the same manner as the directed graph of FIG. 3 is replaced with the synchronous step definition table of FIG. Stored in the memory 2 for use. FIG. 14 shows an operation flow in the event propagation determination section 91 of FIG. 8 in the second embodiment.

In the operation sequence of FIG. 13, a certain input operation 1301
It is assumed that the expected output operation 1304 “B4” is not obtained for “B1”. This fault symptom example is used to describe a fault source estimation method that causes a malfunction of the box operation.

Step 1402 Determining token passing path: If the failure does not occur, determine the series of boxes and gates that the token should have been passing. In the example of Fig. 13, 1301 "B1" → 1312 "G1" → 1302 "B2" surrounded by a dotted line
→ 1313 “G2” → 1303 “B3” → 1314 “G3” → 1304 “B4” →
The 1315 "G4" path corresponds to this.

Step 1403 Setting the firing status of the gate: Of the gates in the token passing path, after the input operation is performed, (a) the gate that has fired, (b) the gate that has not fired, and (c) the gate where any of the above is unknown Classify into three. Example (a) ... 13
12 "G1", (b) ... 1314 "G3", 1315 "G4", (c) ...
1313 "G2".

Step 1404 Limitation of failure range: When the direction of the arc during normal operation (excluding the arc for connecting the diagnostic know-how) is reversed, when certain diagnostic know-how X is reachable from certain gate G, the diagnostic know-how X is It is assumed that it is reachable from the gate G in the opposite direction. The initial failure source candidates are all the failure source boxes included in the diagnostic know-how that can be reached in the reverse direction from the gate in the token passage path.

(A) The box included in the diagnostic know-how that is reachable in the opposite direction from the gate that fired is rejected from the failure source candidates.

Example 1301 Reject the failure source associated with “B1” from the failure source candidates.

(B) The box included in the diagnostic know-how that is reachable in the forward direction from the gate that has not fired is rejected from the failure source candidates.

Example 1304 Reject the failure source associated with "B4" from the failure source candidates.

Step 1407 Utilization of diagnostic know-how: Utilizing diagnostic know-how from failure source candidates that have not been rejected and executing a predetermined test, the failure source is estimated. The diagnostic know-how is utilized in the same manner as in Example 1 based on the maintenance / diagnosis directed graph obtained by inversely converting the diagnostic know-how that was not rejected, such as 1325 “Diagnostic procedure”. Make an estimate. In addition, when a plurality of diagnostic know-how remains without being rejected, it is to be examined in the order of a predetermined priority.

〔The invention's effect〕

As described above, according to the present invention, the occurrence of the test operation and the identification of the failure source are automatically performed, and the complexity of the conventional test operation and the test erroneous operation can be reduced.

Moreover, this table configuration can be easily converted into a Petrinet type graph by constructing an appropriate screen editor. Here, as shown in Fig. 12, the Petrinet-type graph can show the operating principle of the fault diagnosis target by reversing all the directions of the arrows and then changing the arrows around the test operation by a simple procedure. As described above, according to the present invention, the first table showing the correspondence relationship between the symptom of a failure occurring in the diagnosis target and the test item, the test item to be executed for the diagnosis target, and the test item thereof. Is prepared in advance and a second table showing the relationship between the cause of the failure determined in accordance with the test result of the above, or the relationship with the test item to be executed next, and when the failure is detected in the diagnosis target, The test for the test item corresponding to the symptom is executed from the table of No. 1 and the second
The cause of the failure or the test item to be executed next is found from the table in Table 1, and the tests are sequentially executed for the test items according to the second table until the cause of the failure is specified. The cause of failure can be found.

Furthermore, when a failure symptom different from the prepared failure symptom is newly detected, the operation sequence is changed according to the data for displaying the function of the diagnosis object as a combination of operation sequences including a plurality of operation elements. When it is displayed on the display screen and the maintenance staff specifies one operation element on the operation sequence diagram, the diagnostic know-how prepared corresponding to the operation element is displayed on the display screen. The maintenance personnel can find the cause of the failure according to this diagnostic know-how.

[Brief description of drawings]

FIG. 1 is an example of the configuration of a failure diagnosis apparatus showing an embodiment of the present invention, FIG. 2 is an example of a conventional maintenance / diagnosis manual, and FIG.
FIG. 4 is a diagram showing the fault diagnosis procedure shown in FIG. 2 in a Petrinet type graph, FIG. 4 is a configuration diagram of a synchronous step definition table in FIG. 1, FIG. 5 is a propagation management table in FIG. Fig. 7 is a display message table in Fig. 1, Fig. 7 is a test operation table in Fig. 1, Fig. 8 is a block diagram of the general control unit in Fig. 1, and Fig. 9 is an event propagation determination unit in Fig. 8. Treatment of flow chart, No.
FIG. 10 is a processing flow chart of the propagation event No. reading unit in FIG. 8, FIG. 11 is a processing flow chart of the message reading unit in FIG. 8, and FIG. 12 is a Petrinet-type graph for expressing the fault diagnosis procedure in FIG. 13 is an example of a directed graph representing the operation of the failure diagnosis target in the second embodiment, FIG. 14 is a diagram of FIG. 8 in the second embodiment, and FIG. 10 is an operation flow of the event propagation determination unit 91.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Ryoichi Sasaki 1099 Wanganji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Hitachi Ltd. Systems Development Laboratory Address: 1099 Company Hitachi, Ltd. System Development Laboratory (56) References "Measurement and Control" Vol. 22, No. 9 (Sho 58-9-10) P. 59-63

Claims (3)

[Claims] 1. A first table showing a correspondence between a symptom of a failure occurring in a diagnostic object and a test item, a test item to be executed for the diagnostic object, and a test result obtained for the test item. Second table defining the relationship between the cause of the failure determined by the above or a test item to be executed next, and a first data group for displaying the function of the diagnostic object as a combination of operation sequences including a plurality of operation elements And a second data group for displaying the diagnostic know-how prepared corresponding to each of the above operating elements is stored in advance in the memory, and the first data group is stored according to the symptom of the failure occurring in the diagnosis object. The test item to be executed first is selected from the table, and the cause of the failure or the next execution is executed from the second table according to the test result of the diagnostic object made for the test item. The test items that should be tested are obtained, and the diagnostic operation is sequentially performed on the test items defined in the second table until the cause of failure is specified. If the cause of failure is found, the cause of failure is displayed on the display screen. If the failure cause cannot be identified by the failure diagnosis according to the second table, an operation sequence diagram of the diagnosis object is displayed on the display screen based on the first data group, and the operation sequence is displayed on the display screen. A failure diagnosing method characterized in that, when one of the operating elements is designated, diagnostic know-how concerning the operating element is displayed on a display screen based on the second data group. 2. The structured second data group represents a relationship between a symptom of a failure, at least one candidate cause of the failure and a test item for identifying a true cause. The fault diagnosis method according to item 1, wherein the fault diagnosis method comprises data. 3. The diagnostic know-how is displayed on the display screen in a form in which test items for confirming whether or not each of the failure cause candidates related to the operating element is a true failure cause are listed. The failure diagnosis method according to item 1, wherein: