JP3291642B2 - Failure support method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION The present invention classifies and stores past business execution cases as know-how in accordance with business procedures, and stores failure countermeasures in the event of a failure in order to efficiently execute a new business. The present invention relates to a failure countermeasure support method for providing support by using past business execution cases.

[0002]

2. Description of the Related Art Conventionally, accumulation / transmission of know-how in program development or the like has been conveyed verbally or acquired only by own experience. Accordingly, there is a support system for recovering from the occurrence of a failure in program development as a technology for supporting business execution. In other words, when an unskilled person develops a program, in order to prevent the same mistakes that occurred in the past from being repeatedly made, if the same mistakes are repeated with the history of unskilled people, it is possible to easily recover from the failure. Support system. This is to search for similar trouble data that has occurred in the past, and search for a trouble handling method at that time, thereby presenting a similar trouble handling method in the past to the job executor (user). In other words, if an error message is displayed due to a grammatical error during programming or the like, the stored history that led to the occurrence of the failure is searched, and if there is a similar failure of the same type in the past, it has occurred at the current state It proposes and proposes a method for correcting a failure. like this,
One of the prior arts is described in JP-A-6-103047. In the failure diagnosis type expert system, as a combination of the case data at the time of the failure and the actual cause obtained after the diagnosis, it is stored as a case database, and based on the new diagnosis situation and the frequency distribution of the failure cause in the case database. There is a method in which information effective for diagnosis is presented by estimating a probability distribution of a cause candidate of a diagnosis situation using a neural network. That is, a hierarchical set of similar cases is generated and used based on a database in which a phenomenon at the time of occurrence of a failure and a true failure cause are combined as cases. One such prior art is described in Japanese Patent Application Laid-Open No. 5-35484.

[0003]

The prior art described above is a system for assisting an unskilled person in recovering from a failure in the event that the unskilled person repeats the same mistake that has occurred in the past. That is, by searching whether the failure is the same (similar) failure that occurred in the past,
When a corresponding troubleshooting method is found, the troubleshooting method is presented to an unskilled person to provide troubleshooting support. However, if the same type of fault that occurred in the past could not be searched, the corresponding fault handling method could not be found as a search result, and the problem that the support information could not be obtained from the support system as an unskilled person. there were.
In other words, it is an important task for failure handling support to be able to determine whether a failure that has occurred at present is the same type as a similar case in the past. An object of the present invention is to construct a database of past trouble countermeasures in accordance with a trouble countermeasure process (identification of a phenomenon, assumption of a cause, and implementation of a countermeasure) by a business executor, and to partially generate a past Even if there is a failure countermeasure process similar to the above, the object of the present invention is to provide support information for the failure countermeasure to the business executor.

[0004]

In order to achieve the above object, the present invention provides a CPU, an input device for storing or retrieving case data including a plurality of items, and displaying the retrieved case data. An output device, a case database storing case data, a history management database storing search history data of case data, and a failure countermeasure support method in a computer system having a storage device.
When a search key for the item is input from the input device, case data is searched from the case database by the search key, the searched case data is displayed on the output device, and the searched case data or the searched case data is displayed. The search history data of the case data rearranged by the input device based on the searched one or more case data is read from the history management database, and the read search history data is updated and stored in the history management database. ,
The rearranged case data is stored in the case database. Also, a CPU, an input device for accumulating or retrieving case data including a plurality of items (phenomena, causes, and countermeasures), an output device for displaying the retrieved case data, and a case database storing the case data And a history management database storing search history data of case data, and a failure countermeasure support method in a computer system including a storage device, wherein when a search key for the item is input from the input device,
Using the search key, case data is searched from the case database, search history data of the searched case data is read from the history management database, and success / failure information of the countermeasure in the search history data of the searched case data is obtained. When the success is indicated, the searched case data is displayed on the output device, and when the success / failure information of the countermeasure in the search history data of the searched case data indicates a failure, the phenomena or causes have the same and different countermeasures. And retrieves case data indicating that the measure is successful from the case database, and displays the retrieved case data on the output device. Further, when the searched case data is displayed on the output device, the case data having a higher frequency information value in the search history data of the case data is sequentially displayed with higher priority. Further, the success / failure information of the countermeasure in the search history data of the searched case data indicates failure, and the case data having different countermeasures with the same phenomenon or cause and the countermeasure being successful is searched from the case database. Then, the combination of the items of the searched case data is changed to create new case data, search history data of the new case data is created, and the new case data is stored in the case database. Then, the search history data of the new case data is stored in the history management database. Further, when case data cannot be searched using the search key related to the input item, the search key is changed to broaden the search conditions until the case data can be searched. Further, when the case data cannot be searched even when the case database is searched using the search key relating to any of the phenomenon and the cause, the case database is searched using the field (product field or the like) relating to the occurred failure event as a search key. Like that.

[0005]

By means of the above means, case data retrieval (phenomena, causes, countermeasures) in accordance with the business process of the business executor enables narrowing down and searching similar past trouble countermeasure case data. That is, the phenomenon is identified for the occurred failure event, and it is searched whether or not there is a failure countermeasure case in which the same kind of phenomenon has occurred in the past. By displaying a plurality of case data ranges to be searched and displayed, including similar case data, the business executor can appropriately select the case data by judging. As a criterion for determining case data, a cause and countermeasure related to the searched phenomenon are also searched and displayed, thereby providing a display environment in which a business executor can more accurately search for similar case data. Also, in the case data search process, when identifying a fault event that has occurred in accordance with the search procedure for phenomena, causes, and countermeasures, the combination other than the combination of phenomena, causes, and countermeasures in the past case data is accurately determined. If selected as case data and the failure countermeasure is successful, it can be accumulated as case data combining new phenomena, causes, and countermeasures, and the case database is customized.

[0006]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A first embodiment of the present invention will be described below with reference to FIG. The details of the processing will be described later with reference to FIGS. FIG. 1 is a functional block diagram showing the configuration of the first embodiment of the present invention, together with a data flow and a control flow. Case data for accumulating and retrieving trouble countermeasure cases and search conditions are input from the input device 1 and stored in the storage device 2 (21, 2).
2, 23, 24, 25, 26, 27) and the external storage device 5 to control and execute accumulation and retrieval by the CPU 3. The result is output through the output device 4.

Next, the flow of data processing will be described.
The information input by the input device 1 is determined through the user interface unit 21 as to whether to search for a case, to store the case, or to predict a countermeasure result. When the case is searched by the determination, the similar case search unit 25 through the case data management unit 23, and the case automatic adjustment unit 26 for changing, adding, or deleting the search process.
Thus, an appropriate case is retrieved from the case database 29. The search process up to the target case is stored in the history management database 28. On the other hand, when accumulating cases, the editor 2 for media that edits text data and image data (moving images and still images)
4, the cases stored by the case storage unit 27 under the management of the case data management unit 23 are stored in the case database 2.
9 is stored. In the case accumulation process in the case accumulation unit 27, the automatic case adjustment unit 26 determines whether or not the accumulated case is related to the existing case data stored in the case database 29. The determination as to whether or not the newly stored case input by the worker and the existing stored case is related depends on the data input by the worker along with the newly stored case and the call from the history management database 28. This is performed based on the input history data. As a result of the determination, if there is a relationship, the case automatic adjustment unit 26 sets a link between the related cases,
The link information is written in the history data and stored in the history management database 28. Further, when the failure countermeasure result of the retrieved case is applied to the failure event targeted by the task executor, a simulation (prediction) for giving a prospect of whether the countermeasure is successful is given to the simulation unit 22. Do it. Existing case data serving as predictive material for simulating a failure countermeasure result is retrieved from the case database 29 through the similar case retrieval unit 25. As described above, the case search result and the countermeasure simulation result are displayed and output from the output device 4 through the user interface unit 21.

Next, a similar case search unit 25, a case automatic adjustment unit 26, and a case storage unit 2, which are the core of the failure countermeasure case processing.
7 is described in detail. FIG. 2 shows a detailed functional configuration of the similar case search unit 25. The similar case search unit includes a phenomenon search function 251 for searching for a phenomenon in the failure countermeasure work process, and a cause search function 2 for searching for a cause.
52, a similarity case determination function 254 for determining and searching for the most appropriate case by the search processing of the measure search function 253 for searching for measures and the phenomenon search function 251, the cause search function 252, and the measure search function 253. It is composed of When searching for a case, processing is performed by allocating to one of the phenomenon search function 251, the cause search function 252, and the countermeasure search function 253 according to an instruction of the case data management unit 23 based on the search condition. The search result is sent to the user interface unit 21 from the similar case determination function 254.
And output from the output device 4 for display. On the other hand, when simulating the search result, the similar case determination function 25
According to 4, a case similar to the simulation condition is searched from the case database 29, and the result is sent to the simulation unit 22.

Next, FIG. 3 shows a detailed functional configuration of the automatic case adjusting section 26. As shown in FIG. The case automatic adjustment unit 26 includes the case accumulation unit 2
7 and a case classification function 261 for classifying the extracted cases and the cases in the case retrieval process from the similar case retrieval unit 25. When storing the cases, the case data input and divided into product fields, phenomena, causes, countermeasures, and other related information (points to be paid attention to when executing the countermeasures) are stored in the case storage unit 27 as a case extraction function 62. Thus, only the cases of the phenomena, causes, and countermeasures are extracted to form a set of case data, and the product field of the cases to be accumulated as additional information and other related information are added. Next, case classification function 2
According to 61, the trouble countermeasure case data, which is a set of each item of the phenomenon, the cause, and the countermeasure, is classified according to the product field, and a link is provided between other related similar case data registered in the case database 29. By setting, a set of cases composed of items of phenomena, causes, and countermeasures is classified by related fault countermeasure cases. The classified case data is stored in the case database 29 as a set of case data. Further, tabulated data is configured based on the product field of the case stored as the additional information and other related information, and is stored in the history management database 28 as history data. On the other hand, when searching for a case, in the search process of similar case search along the phenomena, causes, and countermeasures items for the search target, when the phenomena, causes, countermeasures items are changed or added, etc. The history data is updated by the classification function 261 and the search history (excluding the overlap) is stored in the history management database 28.
Further, a search history of a similar case for searching for a similar case or a search history in which a countermeasure was successful is called from the history management database 28, and the search history information is sent to the similar case search unit 25.

Next, FIG. 4 shows a detailed functional configuration of the case accumulation unit 27. The case accumulating unit 27 divides trouble countermeasure case data input from the input device 1 through the media-specific editor unit 24 into a product field, a phenomenon, a cause, a countermeasure, and other related information; A division storing history data such as link information to a similar existing countermeasure case related to the case, frequency information at the time of re-accumulation of a search case, and classification information of a success case or a failure case in the history management database 28. It comprises a case attribute addition function 272. With the above, similar case search section 2
5. The detailed description of the functional configurations of the case automatic adjustment unit 26 and the case accumulation unit 27 is finished.

Next, FIG. 5 shows one table configuration of history data stored in the history management database 28 of FIG. The table configuration of FIG. 5 stores a history number column 2801 for storing the history number of the case search process, a classification code column 2802 for storing the classification code of the case data stored in the case database 29, and stores the case search frequency. Case data corresponding to the frequency column 2803 and the history number for
An origin history number column 2804 storing an origin history number for searching from an origin case from the set link;
Further, it is composed of a related destination history number column 2805 for storing a related destination history number for searching for a new related case, and a case number column 2806 for storing case numbers of case data corresponding to the history numbers.

Next, FIG. 6 shows a table configuration relating to case data stored in the case database 29 of FIG. 6 has a case number column 290 for storing case numbers for managing case data to be stored.
1. A history number column 2902 for storing a history number for specifying history data such as a search history corresponding to the stored case data, and a case data file name column 2903 for storing a file name storing the case data. ing.

Next, a table configuration of a temporary table used when performing each of the functional processes shown in FIGS. 2 to 4 will be described. First, FIG. 7 shows a table configuration of a table used when processing of the phenomenon search function 251 in the similar case search unit 25. The table configuration of FIG. 7 includes a phenomenon code column 2511 for storing a phenomenon code corresponding to a phenomenon case to be searched, a classification code column 2512 for storing a series of case classification codes of a phenomenon, a cause, and a countermeasure, a phenomenon, and a cause. , A case number column 2513 for storing a series of case numbers of countermeasures, a history number column 2514 for storing a corresponding history number, and a search condition column 2515 for storing search conditions for a phenomenon case. .

Next, FIG. 8 shows a table configuration of a table used when processing the cause search function 252 in the similar case search unit 25. The table configuration in FIG. 8 includes a cause code column 2521 for storing a cause code corresponding to a cause case to be searched, a classification code column 2522 for storing a series of case classification codes of a phenomenon, a cause, and a countermeasure, a phenomenon, and a cause. , A case number column 2523 for storing a series of case numbers of countermeasures, a history number column 2524 for storing the corresponding history number, and a search condition column 2525 for storing search conditions for the cause case. .

Next, FIG. 9 shows a table configuration of a table used when processing the countermeasure search function 253 in the similar case search unit 25. The table configuration in FIG. 9 includes a countermeasure code column 2531 for storing a countermeasure code corresponding to a countermeasure case to be searched, a classification code column 2532 for storing a series of case classification codes of phenomena, causes, and countermeasures, a phenomenon, a cause. , A case number column 2533 for storing a series of case numbers of countermeasures, a history number column 2534 for storing corresponding history numbers, and a search condition column 2535 for storing search conditions for countermeasure cases. .

Next, FIG. 10 shows a table configuration of a table used when processing the similar case determination function 254 in the similar case search unit 25. The table configuration of FIG. 10 has a phenomenon code column 254 for storing a phenomenon code.
1. Cause code column 254 for storing the cause code
2. Countermeasure code column 254 for storing a countermeasure code
3, a comparison case number column 2544 for storing case numbers of cases to be compared for similarity search, and a history number column 254 for storing history numbers of cases to be compared.
5, a determination column 2546 for storing information for determining whether or not the result of comparison is similar.

Next, FIG. 11 shows a table configuration of a table used when processing the case classification function 261 in the automatic case adjustment section 26. The table configuration in FIG.
A case number column 2611 for storing the case number corresponding to the case to be classified, and a case extraction number separately attached to the case extracted from the case extraction function 262 corresponding to the case stored in the case number. Case extraction number column 261
2. The classification code column 2613 for storing the classification code of the relevant case, the history number column 2614 for storing the history number of the relevant case, and the case data file name storing the relevant case in the case database 29. It consists of a case data file name column 2615 for storing.

Next, FIG. 12 shows a table configuration of a table used when processing the case extracting function 262 in the automatic case adjusting section 26. The table configuration in FIG.
A case number column 2621 for storing a case number corresponding to a case to be extracted, a case extraction number column 2622 for storing a case extraction number separately attached to a case that has been subjected to extraction processing from the case, and a case storage unit 27 Case storage number column 262 for storing the storage number of the case stored in
3, and a case data file name column 2624 for storing a case data file name in which the corresponding case is stored in the case database 29.

Next, FIG. 13 shows a table configuration of a table obtained by the processing of the case division function 271 in the case storage unit 27. The table configuration of FIG. 13 has a case number column 27 for storing case numbers corresponding to cases to be divided.
11. A case division number column 2712 for storing the number of case divisions into which the corresponding case is divided, and a case accumulation number column 271 for storing the case accumulation number of each divided case.
3, a divided case file name column 2714 for storing a divided case file name corresponding to each divided case. This table is stored in the history management database 28 as one of the history data.

Next, FIG. 14 shows a table configuration of a table obtained by the processing of the divided case attribute adding function 272 in the case storage unit 27. The table configuration in FIG. 14 includes a case accumulation number column 2721 for storing case numbers corresponding to accumulated cases, and an association source for storing a history number of an origin case for performing a similar search for accumulated cases. A history number column 2722, a history number column 272 storing related destination history numbers for searching for other similar cases from accumulated cases.
3. A case attribute code column 2724 for storing an attribute code for determining which case the corresponding stored case corresponds to, among phenomena, causes, countermeasures, or related information corresponding to one-point information on implementing the countermeasures. A frequency column 2725 for storing the search frequency of the stored case when the relevant case is an update of the existing case, and classification information indicating whether the failure countermeasure result by the corresponding stored case has succeeded or failed. And a success / failure discrimination column 2726. This table is stored in the history management database 28 as one of the history data.

The description of the table configuration of the tables for performing the respective functions shown in FIGS. 2 to 4 has been completed.

Next, FIG. 15 shows the main processing steps based on the configuration shown in FIGS. 1 to 14 and each table. In step 100, the input device 1 shown in FIG. 1 is used to accumulate trouble countermeasure cases or to input a target case, a search condition, and the like for performing a search. Details of the processing in step 100 will be described later with reference to FIG.

Next, in step 200, the processing contents for the target case input in step 100 (such as whether to search for a similar case or to accumulate new cases) are determined. As a result of the determination, if the process of accumulating the cases is performed, the process goes to step 300. If the similar cases in the past are searched, the process goes to step 400 to simulate the prediction of the countermeasure result of the searched case. If so, go to step 500. Details of the determination processing in step 200 will be described later with reference to FIG.

Next, in step 300 where the case accumulation process is performed in step 200, a process for accumulating case data for each medium such as text data and image data in the case database 29 of FIG. 1 is performed. For details of the processing of step 300, see FIG.
8 will be described later.

Next, in step 400, from the past case data stored in the case database 29, a case similar to the case data to be searched is narrowed down and searched in accordance with a maintenance work procedure of a phenomenon, a cause, and a countermeasure. . Details of step 400 will be described later with reference to FIG.

Next, in step 500, when the similarity searched case is applied to the target failure event, a process for presenting information for estimating whether or not the countermeasure is successful is performed. Do. Step 500
The details of this process will be described later with reference to FIG.

Steps 300 and 4 described above
After the processing of step 500 and step 500, the procedure goes to step 600. Next, in step 600, a process for storing or storing history data in the history management database 28 of FIG. I do. Details of the processing in step 600 will be described later with reference to FIG.

Next, in step 700, a process for storing the case data divided and classified into the applicable phenomena, causes, countermeasures, etc. of the trouble countermeasure case in the case database 29 of FIG. Details of the processing of step 700 will be described later with reference to FIG.

Next, in step 800, a process of displaying a search result of a similar case, information for estimating whether or not the failure countermeasure is successful, and the like using the output device of FIG. 1 is performed. An example of the display output screen will be described later with reference to FIG.

Next, step 100 will be described in detail. As shown in FIG. 16, in step 110,
When accumulating phenomena, causes, and countermeasures in the occurred failure event, case data is collectively input, and related data is also input. Next, in step 120, based on the input data in step 110, whether a new case is stored in the case database 29 of FIG. 1 as a failure countermeasure case, or a similar past case is searched, On the other hand, for a fault event that has occurred, a processing condition is set as to whether it is desired to predict whether the countermeasure is successful or not. However, when case data is entered as a set of phenomena, causes, and countermeasures, the case accumulation process is set as a processing condition. When searching for similar cases, search conditions for phenomena, causes, and countermeasures are set. I do.
Next, in step 130, it is determined whether or not the phenomena, causes, countermeasure data and processing conditions input in steps 110 and 120 are to be changed.
If it is determined that the phenomenon or the cause is to be changed, the process proceeds to step 110. Alternatively, as a result of the determination, when changing the processing conditions such as whether to store or search the case,
Go to step 120. If the result of determination is that there is no change, the process of step 100 ends. This concludes the detailed description of step 100.

Next, step 200 will be described in detail. As shown in FIG. 17, in step 210,
Based on the processing conditions input in step 120 of FIG. 16, it is determined whether or not case data is stored in the case database 29 of FIG. As a result of the determination, when the cases are stored in the case database 29, the process proceeds to step 220. On the other hand, if the result of determination is that a process other than the case accumulation process has been set, the process proceeds to step 230. Next, in step 220, a process of setting a temporary case accumulation flag for performing the case accumulation process is performed. Next, in step 230, it is determined whether or not similar cases in the past are searched from the case database 29. As a result of the determination, when a similar past fault measure case is searched from the case database 29, the process proceeds to step 240.
On the other hand, as a result of the determination, if a process other than the similar case search process has been set, the process proceeds to step 250. Next, in step 240, a process of setting a temporary similar case search flag for performing a process of searching for past similar cases is performed. Next, in step 250, it is determined whether or not to perform a simulation process of presenting information in order to predict whether or not the countermeasure result of the searched case data will succeed with respect to the occurred failure event. If the result of determination is that simulation processing is to be performed, step 26
Go to 0. On the other hand, if it is determined that processing other than the simulation processing is to be set, the process proceeds to step 270.
Next, in step 260, a process of setting a temporary case data simulation flag for performing a case data simulation process for estimating whether or not to succeed as a countermeasure against the generated failure event is performed. next,
In step 270, a process of determining the flag set in steps 220, 240, and 260 is performed. As a result of the determination, if the case accumulation flag is set, the process goes to step 300 in FIG. 15, and if the similar case search flag is set, the process goes to step 400 in FIG. If is set, the process proceeds to step 500 in FIG.
This concludes the detailed description of step 200.

Next, step 300 will be described in detail. As shown in FIG. 18, in step 310,
The input target case is divided into phenomena, causes, countermeasures, other related information, and the like, and a case attribute code (for example, P −001, Ca
-001, m-001) is set. Next, the case number column 2711 of the tables in the case division function 271 and the division case attribute addition function 272 shown in FIGS.
, The case number before division is stored, and the number of divided cases is set in the case number number column 2712, and a case attribute code for discriminating a phenomenon, a cause, a measure, and the like is set and stored in the case attribute code column 2724. Next, in step 320, a case accumulation number corresponding to the divided case data is set, and the case accumulation number is stored in the case accumulation number column 2721 and the case accumulation number column 2713. In addition, based on information input by a business executor or based on information retrieved from a case database or a history management database, related case data is obtained, and a related source history number for searching for a similar case with a case accumulation number, and a related destination. Set the history number,
4 are stored in the related source history number column 2722 and the related destination history number column 2723, respectively. Next, in step 330, it is determined whether or not the stored case is a success case based on the success or failure data input by the business executor. If the result of the determination indicates that the failure measure is a successful case, the process proceeds to step 340. On the other hand, if the result of the determination is that it is a failure case, the procedure proceeds to step 350. Next, in step 340, a success flag is set, and the set flag is stored in the success / failure discrimination column 2726 of FIG. Next, in step 350, a failure flag is set, and the set flag is stored in the success / failure discrimination column 2726 of FIG. Next, in step 360, whether the case data accumulated based on the data such as the partial rearrangement and the addition input by the business executor has been obtained by partially rearranging or adding the existing case data. Is determined. If the result of the determination is that the relevant case data has been partially re-arranged, the process proceeds to step 370. On the other hand, when accumulating completely new case data, the procedure goes to step 380. Next, in step 370, the past access frequency is stored in the frequency column 2725 of FIG. Step 3
At 80, 1 is stored in the frequency column 2725 of FIG. This concludes the detailed description of step 300.

Next, step 400 will be described in detail. As shown in FIG. 19, in step 410,
It is determined whether there is a search condition for the phenomenon. If the result of the determination is that there is a search condition relating to the phenomenon, the procedure proceeds to step 420. On the other hand, if the result of determination is that there is no search condition relating to the phenomenon, the procedure proceeds to step 430. next,
In step 420, the phenomenon code and the like are stored in the table of the phenomenon search function 251 of the similar case search unit 25 shown in FIG. 7, and the set search condition of the phenomenon is stored in the search condition column 2515. Next, in step 430, it is determined whether or not there is a search condition relating to the cause. If the result of the determination is that there is a search condition relating to the cause, the procedure proceeds to step 440. On the other hand, if the result of the determination is that there is no search condition relating to the cause, the procedure proceeds to step 450. Next, in step 440, the cause code and the like are stored in the table of the cause search function 252 of the similar case search unit 25 shown in FIG. 8, and the set search condition of the cause is stored in the search condition column 2525. Next, step 45
At 0, it is determined whether or not there is a search condition regarding the countermeasure. If the result of the determination is that there is a search condition for the countermeasure, the procedure goes to step 460. On the other hand, as a result of the determination,
If there is no search condition for the countermeasure, step 470
go to. Next, in step 460, the countermeasure code and the like are stored in the table of the countermeasure search function 253 of the similar case search unit 25 shown in FIG. 9, and the set search condition of the countermeasure is stored in the search condition column 2535. Next, in step 470, the history data of the history management database 28 and the case data of the case database 29 of FIG. 1 are sequentially called within the search conditions stored in FIGS. The case number and the history number are stored in the comparison case number column 2544 and the comparison history number column 2545 in FIG. 10, and the comparison of the same case or the same history data is performed, and the history contents of the called history data are compared. And 2541 to 254 in FIG.
This is done by comparing the codes of No. 3 and No. 3. As a result of the comparison, if any one of the above matches, it is regarded as a similar case, and the determination result is stored in the determination column 2546 of FIG.
This concludes the detailed description of step 400.

Next, step 500 will be described in detail. As shown in FIG. 20, in step 510,
It is determined whether the phenomenon, cause, and countermeasures are known, and whether the countermeasure results are also clear. If the result of the determination is not clear, go to step 520. On the other hand, as a result of the determination, the phenomenon, the cause, and the countermeasure are known, and if the countermeasure result is also clear, the process of step 500 is terminated. next,
In step 520, the similar case search unit 25 determines whether there is a similar phenomenon, cause, or countermeasure case in the past. This processing is performed in accordance with FIG.
Is the same as the processing shown in FIG. As a result of judgment, phenomenon, cause,
If any of the countermeasures includes a case similar to the occurred failure event, the process proceeds to step 530. On the other hand, as a result of the determination, if the similar case does not exist, the process proceeds to step 560. Next, in step 530, case data similar to any of the phenomenon, the cause, and the countermeasure is searched from the case database 29 of FIG. 1, and the countermeasure case at that time is called. Next, at step 540, the history data corresponding to the past similar case called at step 530 is called from the history management database 28 of FIG. Next, in step 550, from the history data called in step 540, data indicating whether the countermeasure result stored in the success / failure discrimination column 2726 in FIG. 14 is success or failure is called, and finally, in FIG. Step 80
At 0, information on whether the case is a success case or a failure case is displayed from the output device 4 in FIG. 1 together with the similar search case. On the other hand, in step 560, the fact that the countermeasure result of the failure case is unpredictable is displayed through the output device 4 in FIG. This concludes the detailed description of step 500.

Next, step 600 will be described in detail. As shown in FIG. 21, in step 610,
In step 300, step 400, and step 500, history data corresponding to a failure case (a case in which a phenomenon, a cause, and a measure are grouped) processed is called. Next, in step 620, it is determined whether the target case is stored or similar search is performed. As a result of the determination, when the cases are accumulated, the process proceeds to step 630.
On the other hand, if a similar case has been searched, the procedure goes to step 650. Next, in step 630, the existing phenomenon,
If the history data is stored with the same history number in the history management database 28 due to a change in the combination of the cause and the countermeasure case, the old history data is deleted. next,
In step 640, new history data (eg, new combinations of phenomena, causes, countermeasures, new settings, changes, and additions of related source and destination case data) corresponding to the stored case data are stored in the history management database of FIG. 28. On the other hand, in step 650, step 630
Similarly to the above, when a combination of a phenomenon, a cause, and a countermeasure similar to the occurred failure event is changed in the search process, when the history data is stored in the history management database 28 with the same history number, the old history data is deleted. to erase. Next, in step 660, similarly to step 640, the history data corresponding to the searched similar case data is stored in the history management database 28 of FIG.

Next, step 640 or step 6
The principle of changing the history data in 60 will be described with reference to FIG. As shown in FIG. 24, it is assumed that a series of case data of phenomena, causes, and countermeasures such as 91, 92, and 93 exist. At this time, if a phenomenon similar to the phenomenon P-003 occurs as a failure event (assuming that the product field, classification code, and the like are different), only 93 combination cases exist in the past cases. Is searched for unsuccessful cases. However, there is another countermeasure example such as 92 due to the common cause, which has been successfully performed in the past (processing in the simulation unit). Therefore, there are 94 possible combinations of the current failure event as another possible countermeasure. As a result, if the business executor takes the same countermeasures and succeeds, 94 in which the combination of the 93 phenomena, causes, and countermeasure cases is changed is added as a new successful case. This concludes the detailed description of step 600.

Next, step 700 will be described in detail. As shown in FIG. 22, in step 710, case data, such as phenomena, causes, and countermeasures, which have been processed up to step 600, are called. Next, step 7
At 20, it is determined whether the target case is to be stored or subjected to a similarity search. As a result of the determination, when the case is accumulated, the process proceeds to step 730. On the other hand, if similar case data is retrieved, the procedure goes to step 740. Next, in step 730, the stored case data is stored in the case database 29 of FIG. The history number corresponding to the stored case is stored in the history number column of FIG. 6, and the case data file name is stored in the case data file name column 2.
903. Next, in step 740,
Case data (phenomena, causes, countermeasures) by similar case search
It is determined whether or not the combination of has been changed. If the result of determination is that the combination has been changed, the flow proceeds to step 750. On the other hand, if the result of determination is that there is no change in the combination of case data, the process of step 700 ends. next,
In step 750, the case data in which the combination of the case data (phenomenon, cause, measure) changed in the search process is stored in the case database 29 of FIG.
This concludes the detailed description of step 700.

Next, an example of a case display output screen in step 800 is shown in FIG. First, in the left half of the display screen of the output (display) device 4, failure countermeasure example data (phenomenon, cause,
Countermeasures, related information, etc.) are displayed (401). Next, in the upper right part of the output device 4, the field (classification code) of the case data to be displayed and the failure location (keyword for the phenomenon search) are displayed (402). In the lower right part of the output device 4, a related field (classification code of related case) call button 403, a related phenomenon case call button 404, a related cause case call button 405, and a related measure case call button 406 of the displayed case are displayed. , And an execution confirmation button (OK button) 407 for each button function, and a button cancellation button (Cancel button) for each button function. This concludes the description of the example of the case display output screen in step 800.

Next, a second embodiment of the present invention will be described with reference to FIG.

Here, the configuration shown in FIGS.
And a processing procedure based on the table. Step 20
In 100, a failure event to be searched is input by the input device 1 of FIG. Next, step 2
In step 0200, a search key related to a phenomenon or cause is extracted from the search target input in step 20100. Details of step 20200 will be described later with reference to FIG. Next, in step 20300, it is determined whether or not the search key is related to the phenomenon or cause extracted in step 20200. If the result of the determination is that the key is a search key for a phenomenon, the process proceeds to step 20400. Details of step 20400 will be described later with reference to FIG. On the other hand, if it is the search key related to the cause, the process proceeds to step 20500.
Details of step 20500 will be described later with reference to FIG. Next, in step 20600, a search is made for a related countermeasure example including a search key for a phenomenon or cause. For details of step 20600, see FIG.
9 will be described later. Next, in step 20700, it is determined whether the retrieved case is a success case or a failure case. If the result of the determination is a successful case, step 208
Go to 00. On the other hand, in the case of a failure case, step 20
Go to 900. Next, in step 20900,
It is searched from the case database 29 of FIG. 1 whether another countermeasure case having the same or similar phenomenon or cause exists. Next, in step 20800, the search history data corresponding to the searched case data is called from the history management database 28 in FIG. I do. Next, in step 21000, the phenomena, causes, and countermeasures retrieved from the output device 4 are displayed and output through the user interface unit 21 in the storage device 2 in FIG. Next, in step 21100, when the business executor (user) selects a case from among the cases displayed in step 21000, history data such as search history and search frequency corresponding to the selected case, and case data Is changed and stored in the history management database 28 and the case database 29 in FIG. Details of step 21100 will be described later with reference to FIG.

Next, step 20200 will be described in detail. As shown in FIG. 26, in step 20210, it is determined whether or not a phenomenon case exists for the failure target input from step 20100 in FIG. If the result of the determination is that there is a phenomenon case, the procedure goes to step 20220. On the other hand, if there is no phenomenon case, the process proceeds to step 20230. Step 20220
In, a phenomenon case is extracted as a search key from cases to be searched by the case storage unit 27 of FIG. next,
In step 20230, as in step 20210, it is determined whether or not a cause case exists for the failure target input from step 20100 in FIG. If the result of the determination is that there is a cause case, the procedure proceeds to step 20240. On the other hand, when the cause case does not exist, the process ends and the process goes to step 20300. In step 20240, a cause case is extracted as a search key from the cases to be searched by the case storage unit 27 of FIG. This concludes the detailed description of step 20200.

Next, step 20400 will be described in detail. As shown in FIG. 27, in step 20410, it is determined whether or not a case including a search key related to a phenomenon exists in the case database 29 of FIG.
If the result of the determination is that the case exists in the case database 29, the process proceeds to step 20420. On the other hand, if it does not exist in the case database 29, the procedure goes to step 20440. In step 20440, it is determined whether or not to change the search key relating to the phenomenon corresponding to the occurred failure event. If it is determined that the search key related to the phenomenon is to be changed, the process proceeds to step 20420. On the other hand, if the search key related to the phenomenon is not changed, step 20
Go to 450. Next, in step 20420,
A failure case including a search key for a phenomenon is searched from the case database 29 of FIG. Next, step 2043
At 0, the history data corresponding to the case data including the search key related to the phenomenon is searched from the history management database of FIG. 1 and called. On the other hand, in step 20450, the search key of the occurred fault event to be searched is changed to the corresponding product field. Next, step 20
At 460, case data including a search key for the product field set at step 20450 is
It is determined whether or not it exists in the case database 29 of FIG. As a result of the judgment, the case data is stored in the case database 2
If it exists in step 9, the process goes to step 20480. On the other hand, if the case data does not exist in the case database 29, the procedure goes to step 20470. Step 2047
At 0, the search key for the product field is changed.
After the change, the determination is made again in step 20460. Next, in step 20480, a case including a search key related to the product field is searched from the case database 29 of FIG. Next, in step 20490, history data corresponding to the case searched in step 20480 is searched and called from the history management database of FIG. This concludes the detailed description of step 20400.

Next, step 20500 will be described in detail. As shown in FIG. 28, in step 20510, it is determined whether or not a case including a search key related to the cause exists in the case database 29 of FIG. If the result of the determination is that the case exists in the case database 29,
Go to step 20520. On the other hand, case database 2
If not, go to step 20540.
In step 20540, it is determined whether or not to change the search key relating to the cause of the occurred failure event. If it is determined that the search key related to the cause is to be changed, the process proceeds to step 20520. On the other hand, if the search key related to the cause is not changed, step 2055
Go to 0. Next, in step 20520, a failure case including a search key related to the cause is searched from the case database 29 of FIG. Next, in step 20530, history data corresponding to case data including a search key related to the cause is searched from the history management database of FIG. 1 and called. Next, regarding Step 20550 to Step 20590, Step 204 of FIG.
Since the processing is the same as Step 20490 from 50,
The description here is omitted. With the above, step 20500
Ends the detailed description of.

Next, step 20600 will be described in detail. As shown in FIG. 29, in step 20610, a countermeasure case stored in the case database 29 of FIG. 1 is extracted by combination with a phenomenon used as a search key or with a cause used as a search key. In the table (FIG. 9) in the measure search function 253 of the similar case search unit 25 in FIG. Next, in step 20620, a determination as to whether the case retrieved and stored in step 20610 is a success case or a failure case is made based on the history data called from the history management database 28 through the case accumulation unit 27 in FIG. Do. This concludes the detailed description of step 20600.

Next, step 21100 will be described in detail. As shown in FIG. 30, in step 21110, the history data (history number, classification code, frequency, related source history number, related destination history number, case number) corresponding to the searched case data is stored in the history management of FIG. Database 28
The search is updated to update the history data corresponding to the case selected by the user. Next, in step 21120, the history data updated in step 21120 is stored in the history management database 28 of FIG. Next, in step 21130, the case data selected in step 21110 is stored in the case database 29 of FIG.
To be stored. This concludes the detailed description of step 21100.

Next, the processing of the above embodiment will be specifically described with reference to FIG. First, as a failure example, it is assumed that a failure has occurred in a communication line between a host and a terminal. Therefore, a failure target case generated by the input device 1 of FIG. 1 is input. The input failure target case is stored in the case storage unit 27 of FIG.
In (2), the classification of the product (classification code (in this case, a local area network-related fault, which will be expressed as "LAN")), and if the phenomenon or the cause of the fault is clear, the input fault target To divide. Here, it is assumed that the timeout error in the communication line has been clarified as a failure phenomenon. Therefore, the similar case search unit 25 shown in FIG. 1 uses the case relating to the inputted phenomenon as a search key and retrieves the phenomenon (91) shown in FIG. 31 from the case data stored in the case database 29 of FIG.
0), cause (920), and countermeasure (930) can be searched for. However, the retrieved countermeasure examples (93
It can be seen that the countermeasure result of 0) is a case in which the trace has been performed but the solution has not been finally resolved. Therefore, a search is performed to determine whether any of the phenomena, causes, and countermeasures has the same type of fault countermeasures. As a result of the search, the phenomena with the same cause and the phenomena with different countermeasures (940) and the cause (9
20), Measures (950) It is assumed that a failure measure example could be searched. Here, as a combination of cases in the case database 29, a phenomenon (910), a cause (920), and a countermeasure (93)
0) and only the phenomenon (940), the cause (920), and the countermeasure (950), but even if the phenomenon is 910 (timeout error), the countermeasure (930) does not solve the failure. By presenting a countermeasure (950) having the same cause, the user (business executor) is supported. The change processing of the combination is performed by the case automatic adjustment unit 26 in FIG. Further, when the failure is actually recovered by the countermeasure shown in 950 in the phenomenon shown in 910, as a successful failure countermeasure example, as shown in FIG. 32, the phenomenon (910), the cause (920), and the countermeasure ( 950) is generated and stored in the case database 29, and a search history and a search frequency until the countermeasure case (950) is reached are stored as history data in the history management database 28 of FIG. According to the above processing procedure, the case database 29 to be searched is also customized each time the case search is performed.

[0047]

According to the present invention, a fault countermeasure process of a person performing a fault countermeasure task (identification of a phenomenon, assumption of a cause, implementation of a countermeasure).
Build a database of past troubleshooting cases according to the above, and provide information on troubleshooting to the business executor even if there is a partially similar troubleshooting process in the past for the failure that occurred. Can be. That is, the phenomenon in the past,
Even if a failure countermeasure example similar to a series of causes and countermeasures could not be identified, it is not a result that the corresponding failure countermeasure case could not be searched, but it is a case related to the phenomenon or cause. For example, it is possible to search and display, and as a trouble countermeasure as a combination of phenomena, causes, and countermeasures, even if there is no applicable case in the past, search and display cases that partially provide clues to the trouble countermeasures can do. In addition, by providing information on whether past countermeasures were successful or unsuccessful, even if the same case searched for was a failed case, another problem with a similar phenomenon or cause was added. From the countermeasure case, it is possible to provide information that enables the business executor to estimate another countermeasure that is likely to be successful, and it is possible to provide fault countermeasure support. Further, in the similar case search process, even if there are a plurality of cases corresponding to the search condition based on the past search frequency for the stored cases, it is possible to preferentially output as a search result the one with the highest frequency. In other words, it is possible to display frequently-used countermeasure examples by the countermeasure execution method performed by the past business executor.

[Brief description of the drawings]

FIG. 1 is a functional block diagram illustrating a configuration of a first exemplary embodiment of the present invention.

FIG. 2 is a functional configuration diagram of a similar case search unit.

FIG. 3 is a functional configuration diagram of a case automatic adjustment unit.

FIG. 4 is a functional configuration diagram of a case accumulation unit.

FIG. 5 is a table configuration of history data stored in a history management database.

FIG. 6 is a table configuration related to case data in a case database.

FIG. 7 is a table configuration of a table used at the time of processing of a phenomenon search function.

FIG. 8 is a table configuration of a table used at the time of processing of a cause search function.

FIG. 9 is a table configuration of a table used at the time of processing of a countermeasure search function.

FIG. 10 is a table configuration of a table used at the time of processing of a similar case determination function.

FIG. 11 is a table configuration of a table used at the time of processing of the case classification function.

FIG. 12 is a table configuration of a table used at the time of processing of a case extraction function.

FIG. 13 is a table configuration of a table obtained by processing of a case division function.

FIG. 14 is a table configuration of a table obtained by processing of a division case attribute addition function.

FIG. 15 is a flowchart showing a first embodiment of the present invention.

FIG. 16 is a detailed diagram of step 100 in FIG.

FIG. 17 is a detailed diagram of step 200 in FIG. 15;

FIG. 18 is a detailed diagram of step 300 in FIG.

FIG. 19 is a detailed diagram of step 400 in FIG.

FIG. 20 is a detailed diagram of step 500 in FIG.

FIG. 21 is a detailed diagram of step 600 in FIG.

FIG. 22 is a detailed diagram of step 700 in FIG. 15;

FIG. 23 is a diagram illustrating an example of a case display output screen according to the first embodiment of the present invention.

FIG. 24 is a diagram for explaining a principle of changing history data in the first embodiment of the present invention.

FIG. 25 is a flowchart showing a second embodiment of the present invention.

FIG. 26 is a detailed diagram of step 20200 in FIG. 25.

FIG. 27 is a detailed diagram of step 20400 in FIG. 25.

FIG. 28 is a detailed diagram of step 20500 in FIG. 25.

FIG. 29 is a detailed diagram of step 20600 in FIG. 25.

FIG. 30 is a detailed diagram of step 21100 in FIG. 25.

FIG. 31 is a diagram for explaining a specific case accumulation / search process according to the second embodiment of this invention.

FIG. 32 is a diagram for explaining a combination of case data newly generated in the search processing according to the second embodiment of the present invention.

[Explanation of symbols]

 REFERENCE SIGNS LIST 1 input device 2 storage device 3 CPU 4 output device 5 external storage device 21 user interface unit 22 simulation unit 23 case data management unit 24 media-specific editor unit 25 similar case search unit 26 automatic case adjustment unit 27 case storage unit 28 history management Database 29 Case Database

──────────────────────────────────────────────────の Continuing on the front page (72) Inventor Keiji Yajima 1099 Ozenji Temple, Aso-ku, Kawasaki-shi, Kanagawa Prefecture Hitachi Systems Co., Ltd. (56) References JP-A-7-44526 (JP, A) JP-A-6-325101 (JP, A) JP-A 5-89177 (JP, A) (58) Survey Field (Int.Cl. ⁷ , DB name) G06F 11/22 360

Claims (6)

(57) [Claims] 1. A CPU, an input device for storing or retrieving case data composed of a plurality of items, an output device for displaying retrieved case data, a case database storing case data, and case data A failure management support method in a computer system having a history management database storing search history data of the above and a storage device, wherein a search key relating to at least one of the items is input from the input device. When searched, case data is searched from the case database by the search key, and the searched case data is displayed on the output device. Based on the searched case data or the searched one or more case data, The search history data of the case data rearranged by the input device is read out from the history management database, Search history data update to the store in the history management database, fault tolerance support method characterized by storing the case data by the assembled replacement is performed in the case database was. 2. A CPU, an input device for storing or retrieving case data comprising phenomena, causes, and countermeasures, an output device for displaying the retrieved case data, and a case database storing the case data. And a history management database storing search history data of case data, and a failure countermeasure support method in a computer system including a storage device, wherein the input device relates to at least one of the items. When a search key is input, case data is searched from the case database by the search key, and search history data of the searched case data is read from the history management database, and search history data of the searched case data is read. When the success / failure information of the countermeasure in the above indicates success, the searched case data is output to the output device. When the success / failure information of the countermeasure in the search history data of the searched case data indicates a failure, the case data having the same phenomena or causes but different countermeasures and indicating the success of the countermeasure is stored from the case database. A failure countermeasure support method, comprising: searching and displaying the searched case data on the output device. 3. The failure countermeasure support method according to claim 2, wherein when the searched case data is displayed on the output device, priority is given to case data having a higher frequency information value in search history data of the case data. A trouble shooting support method characterized by displaying the information sequentially. 4. The failure countermeasure support method according to claim 2, wherein the success / failure information of the countermeasure in the search history data of the searched case data indicates failure, and the countermeasure has a different countermeasure with the same phenomenon or cause. When case data indicating that the countermeasure is successful is retrieved from the case database, the combination of items of the retrieved case data is changed to create new case data, and the search history data of the new case data is changed. Creating, storing the new case data in the case database,
A failure countermeasure support method, wherein the search history data of the new case data is stored in the history management database. 5. The failure countermeasure support method according to claim 2, wherein when case data cannot be searched using the search key for the input item, the search key is changed until the case data can be searched to broaden the search conditions. A failure countermeasure support method characterized by the following. 6. The trouble countermeasure support method according to claim 2, wherein when the case data cannot be searched by searching the case database using a search key related to any of the phenomenon and the cause, a field relating to the generated trouble event ( A failure countermeasure support method, wherein the case database is searched using a product field or the like as a search key.