JP2002252699A - System for calculating estimated time of restoration and its method, and storage medium storing program of the method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To respond to a user who has requested to help restore a failure by automatically calculating an estimated time of restoration. SOLUTION: A case database setting up part 2 makes a deciding factor of restoration of equipment into a database from past cases. A database indexing part 3 indexes a similar case of a failure from the case database when it receives a request to help restore the failure. In the case that there is a past occurrence of a similar event, a database processing part 4 checks and selects check items of a case database 1 in response to an actual state of the failure and specifies the relevant check item, and, by this, takes in an extent of influence on an estimated time of restoration set up for each deciding factor of restoration and reflects it on calculation of the estimated time of restoration. In the case that there is no past occurrence of a similar even, it adds the estimated time of restoration for each factor of restoration, accumulates the added time and calculates an estimated time of restoration.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure recovery expected time calculation system and a failure recovery time calculation system capable of determining a failure recovery measure based on a failure state of a device, automatically calculating a recovery expected time from a recovery case, and responding to a user request. The present invention relates to a method and a recording medium on which a program according to the method is recorded.

[0002]

2. Description of the Related Art Maintenance of exchanges scattered at various bases nationwide
It is managed by a central or distributed operating system. 2. Description of the Related Art Conventionally, an operation terminal is connected to a centrally or distributedly arranged operation system, and by executing a maintenance command from the operation terminal to the operation system, a failure point of a device in the exchange and the operation system device is specified, and a recovery measure is taken. Was instructed. Conventionally, past failure cases and their recovery procedures are stored in a database as recovery measures, and operation personnel grasp and confirm failure details based on user requests by telephone or e-mail from system administrators or construction personnel. After retrieving and outputting this database, a response has been obtained, and measures have been taken to recover from the failure by replying to the user.

[0003]

By the way, when a user requests a failure recovery support, the most desired information of the user is the expected recovery time of the failure. When the user directly inquires about the estimated recovery time, the operator has notified the approximate estimated recovery time. FIG. 10A schematically shows a conventional process up to notification of an expected recovery time when a user requests a failure recovery support. As shown in the figure, the operator refers to the database described above and calculates and answers from the troubleshooting procedure.However, the answer differs depending on the skill of the answering operator, and there is a deviation from the actual situation, It was the present situation that gave anxiety or dissatisfaction.

The present invention has been made in view of the above circumstances, and converts a failure recovery determinant of a device into a database from past cases, and when a failure recovery support request is received, indexes similar failure cases from the case database. By confirming and selecting the check items of the case database according to the actual failure status, the failure recovery prospect determination element captures the degree of influence on the expected recovery time set in advance and reflects it in the calculation of the expected recovery time. A failure recovery expected time calculation system, a method thereof, and a program for the same, which automatically calculate the expected recovery time without giving sufficient training to all operators and do not cause the user to be uneasy or dissatisfied. It is an object of the present invention to provide a recorded recording medium.

[0005]

SUMMARY OF THE INVENTION In order to solve the above-mentioned problems, the present invention provides a case database structuring means for converting a failure recovery deciding element of a device into a database from past cases, and A case database indexing means for indexing similar failure cases from the case database, and checking and selecting check items of the case database according to an actual failure state to a recovery recovery time set in advance for each failure recovery probability determination element. And a data processing means for taking in the degree of influence and calculating the expected recovery time.

In the failure recovery expected time calculation system according to the present invention, the data processing means includes a point management means for managing the degree of influence on the expected recovery time for each of the recovery expected determination elements, and the case database. A recovery time-sequence slip creation means for generating a recovery time-sequence slip based on the required time for each step in which the point is reflected in the required time among the failure recovery procedure and the required time for each step obtained by indexing And characterized in that:

In the failure recovery expected time calculation system according to the present invention, the data processing means further accumulates a recovery expected time for each of the failure recovery expected elements when no similar failure case exists in the case database.
An arithmetic unit for accumulating the accumulation time and calculating an estimated failure recovery time is provided.

In the fault recovery expected time calculation system according to the present invention, a fault recovery measure monitoring means for monitoring the execution status of the fault recovery measure, and the result of the monitoring by the fault recovery measure monitoring means, the fault recovery expected time and the past When a predetermined time difference is recognized from the execution time in the failure case, the failure recovery expected time is corrected, and alarm generation means for notifying that the correction has been performed is provided.

With the above configuration, the case database constructing means converts the failure recovery prospect determination element of the device into a database from past cases, and the database indexing means indexes similar failure cases from the case database upon receiving a failure recovery support request. Then, when a similar event has occurred in the past, the data processing means confirms and selects the check items in the case database according to the actual failure status, thereby setting a recovery recovery preset determination element for each failure recovery prospect determination element in advance. The degree of influence on the estimated time is captured and reflected in the calculation of the estimated recovery time. If a similar event has not occurred in the past, the data processing means accumulates the estimated recovery time for each element of the estimated failure recovery, and calculates the estimated time of failure recovery by accumulating the accumulated times. As a result, it is possible to automatically calculate the estimated time of failure recovery without providing sufficient training to all operators, and by giving this to the requesting user, without giving the user anxiety, CS
(Customer Satisfaction) can be expected to improve. Note that the failure recovery prospective determinant means each of "failure date information", "occurrence event", "failure type", "rush situation", "measure procedure", "construction state", and "failure case". , For each predefined element,
It is assumed that a DB is constructed on a large-capacity hard disk device of the system by making the degree of influence on the expected recovery time into a point.

[0010] In order to solve the above-mentioned problems, the present invention provides:
Device failure recovery prospect determination element is converted from a past case into a database, and when a failure recovery support request is received, similar failure cases are indexed from the case database, and check items of the case database are checked according to actual failure conditions. The selection is such that the degree of influence on the estimated recovery time set in advance for each failure recovery expected determination element is taken in and reflected in the calculation of the estimated recovery time.

[0011] In order to solve the above problems, the present invention provides:
A computer readable recording medium that records a failure recovery expected time calculation program used in a failure recovery expected time calculation system that determines a failure recovery measure from a device failure situation, calculates a recovery expected time from a recovery case, and responds to a request. The failure recovery expected time calculation program includes a first step of converting a failure recovery expected determination element into a database from past cases, and a step of indexing a similar failure case from the case database upon receiving a failure recovery support request. Step 2 and checking and selecting the check items of the case database according to the actual failure state, thereby taking in the degree of influence on the expected recovery time set in advance for each failure recovery prospect determination element and calculating the expected recovery time. And reflecting the above steps to a computer. A recording medium recording a fault recovery expected time calculation program for rows.

Further, in the recording medium of the present invention, the third step includes a step of managing the degree of influence on the expected recovery time for each of the expected recovery decision elements by indexing the case database. A failure recovery procedure obtained and a step of creating a recovery time-series ticket based on the required time of each step in which the point is reflected in the required time among the required time of each step. This is a recording medium on which an estimated time calculation program is recorded.

[0013] In the recording medium of the present invention, the third step further includes, when there is no similar failure case in the case database, accumulating a possible recovery time for each of the possible failure recovery elements; A step of calculating the estimated time of failure recovery by accumulating the stacking time.

Further, in the recording medium of the present invention, the step of monitoring the implementation status of the failure recovery measure, and as a result of the monitoring, a predetermined time difference is recognized between the expected recovery time of the failure and the execution time in the past failure case. And a step of correcting the estimated time of failure recovery when issued, and issuing an alarm to notify that the correction has been made.

Further, in the program according to the present invention, a failure recovery measure is determined from a failure state of the device, and a predicted recovery time is calculated from a recovery case to calculate a predicted recovery time used in a predicted recovery time calculation system for responding to a request. A first step of converting a failure recovery prospect determination element into a database from past cases, a second step of indexing a similar failure case from the case database when a failure recovery support request is received, A third step of checking and selecting the check items in the database according to the actual failure status, taking in the degree of influence on the expected recovery time set for each failure recovery prospect determination element, and reflecting the influence on the calculation of the predicted recovery time. Calculation of the estimated time of failure recovery for causing the computer to execute the above steps Is a program.

Further, in the program according to the present invention, the third step is obtained by indexing and managing the degree of influence on the expected recovery time for each of the expected recovery decision elements, and indexing the case database. Failure recovery procedure and a step of creating a recovery time-series ticket based on the required time of each step in which the point is reflected in the required time among the required time of each step. This is a time calculation program.

Further, in the program according to the present invention, the third step further includes a step of, when there is no similar failure case in the case database, a step of stacking the estimated recovery time for each of the failure recovery expected elements; Calculating the estimated time of failure recovery by accumulating time.

Further, in the program of the present invention, the step of monitoring the implementation status of the failure recovery measure, and as a result of the monitoring, a predetermined time difference is recognized between the estimated failure recovery time and the execution time in the past failure case. Correcting the expected time of failure recovery, and issuing an alarm to notify that the correction has been made.

[0019]

FIG. 1 is a block diagram showing an embodiment of a failure recovery expected time calculation system according to the present invention. Here, the function of the internal configuration of the estimated failure recovery time calculation system of the present invention is shown. Each block shown here is specifically constituted by a peripheral LSI including a CPU and a memory, and the CPU executes a function of the block by reading out a program recorded in the memory and sequentially executing the program.

The estimated failure recovery time calculation system of the present invention comprises a case database (DB) 1 and a case DB construction unit 2.
, A DB index unit 3, a data processing unit 4, a check screen 5, a failure recovery measure monitoring unit 6, and an alarm generation unit 7. The case DB construction unit 2 has a function of constructing a DB of the failure recovery prospect determination element of the device from the past case on the case DB 1. As will be described later, the case DB 1 is converted into a DB by the case DB structuring unit 2 by converting the degree of influence on the estimated recovery time for each expected recovery decision element. DB index part 3
Has a function of indexing a failure case from the case DB1 when receiving a failure recovery support request. The data processing unit 4 uses the case DB 1
By checking and selecting the check items in accordance with the actual failure state, the failure recovery prospect determination element has a function of taking in the degree of influence on the expected recovery time set in advance and reflecting the influence on the calculation of the predicted recovery time.

The data processing unit 4 includes a point management unit 41
, A failure recovery scheduling slip creation unit 42 and an operation unit 43. The point management unit 41 has a function of managing the degree of influence on the expected recovery time for each of the expected recovery decision elements. Further, the failure recovery scheduling form creation unit 42 performs the failure recovery based on the required time for each process in which the points are reflected in the required time, of the failure recovery procedure and the required time for each process obtained by indexing the case DB1. It has a function to generate scheduling votes.
Furthermore, when there is no similar failure case in the case DB1, the calculation unit 43 has a function of accumulating the estimated recovery time for each of the estimated failure recovery elements and accumulating the accumulated time to calculate the estimated failure recovery time.

The check screen 5 has, for example, the screen configuration shown in FIG. 3 and displays a checkpoint input by an operator at the time of constructing a DB for each recovery-probability determining element, and displays data input in an interactive manner by the system. GUI (Graphical User Interface) taken in
It consists of. The details will be described in the section on DB construction.
The fault recovery measure monitoring unit 6 has a function of monitoring the execution status of the fault recovery measure. The alarm generation unit 7 monitors the fault recovery measure monitoring unit 6 and calculates the estimated time of failure recovery and the execution time of past failure cases. When a predetermined time difference is recognized between the time and the time, the estimated time of failure recovery is corrected, and an alarm is issued to notify the operator of the correction.

Here, the data structure of the case DB1 will be schematically described. The case DB 1 stores the “failure date information”, “occurrence event”, “fault type”, “rush situation”, “measure procedure”, “construction state”, and “failure case” by the case DB construction unit 2. A failure recovery prospect determination element is set, and a DB is constructed on a large-capacity hard disk device of the system, with the degree of influence of each element on the expected recovery time being pointed. The “failure occurrence date information” is a recovery possibility determination element having the occurrence date and day, the occurrence time zone, and the weather as input parameters. Case DB
When constructing 1, the operator utilizes the check screen 5 displayed on the display device to hear the failure status from the user and input it while interacting with the display screen, whereby the content is taken into the system, A DB is constructed. Inside the system, points are managed for each item.For example, if the failure date is weekday, the points will be low, and if the occurrence time is out of hours or the weather is rough, the points will be Set to be higher. The points are numerically managed, and setting and calculation are managed by a point management unit 41 incorporated in the data processing unit 4. The same applies to the recovery probability determining element described below.

"Occurrence event" means whether the occurrence problem is clarified, whether the problem is reproducible, the cause of the occurrence is clarified, the mechanism of occurrence is clarified,
The error log and the error message information are recovery probability determining elements having as input parameters whether they have been acquired. The “failure type” is a recovery prospect having a hardware device failure, whether the OS (basic software) can be operated normally, repeated execution of the restart process, and the possibility of returning to the old file of the application as input parameters. It is a deciding factor.

The "rush situation" is a recovery expectancy determining element having, as input parameters, whether a manual operation is required on site, the time of the rush, and the delivery time from the location where the spare package is deployed. The “measure procedure” is a recovery expectancy determining element having as input parameters whether the center system needs to be stopped, whether there is any peculiarity from the past occurrence problem history at the occurrence center, and whether there is a recovery measure procedure.

The "construction state" is a recovery-probability determining element having as input parameters whether the construction within the center accommodation range has been carried out or is underway, and the construction at the center has been carried out or underway. The "failure case" is a recovery probability determining element having as input parameters whether no event has occurred in the past or a similar event has occurred in the past. As described above, the degree of influence on the recovery time is as described above. Are converted into points and converted into a DB.

FIG. 2 is a flowchart cited for explaining the schematic operation of the embodiment of the present invention shown in FIG.
Hereinafter, the operation of the embodiment of the present invention shown in FIG. 1 will be schematically described with reference to the flowchart shown in FIG. First, the case DB constructing unit 2 converts the recovery probability determining factor into a DB based on past cases (step S21). More specifically, the operator hears a failure situation from the user, confirms and selects each checkpoint displayed on the check screen 5, and the case DB construction unit 2 takes in the data and registers it in the case DB1. (Step S22).

The data processing section 4 fetches the degree of influence (point) on the expected recovery time set in advance for each failure recovery expected determination element, and performs data processing so as to reflect the influence on the calculation of the expected recovery time. Then, the calculated expected recovery time is notified to the user who has requested the failure recovery support or the related department (steps S23 and S24). Notifications are made by telephone or e-mail. In order to calculate the expected recovery time from the expected recovery determination element, if the DB index unit 3 confirms that a past case exists in the case DB1 as a result of the case DB1 index, the data processing unit 4
Automatically calculates the required process and required time from the procedure for recovery and the required time for each process. If there is no past case in the case DB1, a check screen is displayed based on the result of hearing with the user. The required process and required time are calculated only by chronological confirmation and selection, and the expected recovery time is generated. Details for generating the expected recovery time will be described later.

Further, the operator constantly monitors the status of the fault recovery measures by means of the fault recovery measure monitoring unit 6, and the fault recovery device monitoring unit 6 detects the fault when the error is out of the error range of the expected value of the expected automatic recovery time. The expected recovery time is corrected, the alarm generator 7 is activated, and the operator is notified of the correction (step S25). Specifically, as a result of monitoring by the failure recovery measure monitoring unit 6, when a time difference of, for example, about 30 minutes is recognized between the estimated failure recovery time and the execution time in the past failure case, the estimated failure recovery time And an alarm is generated.

Hereinafter, a specific operation will be described. The DB index unit 3 searches the case DB 1 and, in the recovery prospect determination element,
It is determined whether or not a similar event has occurred in the past by indexing the "failure case". If a similar event has occurred in the past, the data processing unit 4 calculates the longest time and the shortest time from the case DB1 accumulated so far. For example, if the rushing time exceeds 30 minutes, the data processing unit 4 calculates the time. Is added to the longest time. If the time does not exceed 30 minutes, the time is subtracted from the longest time. Then, the average “estimated failure recovery time” is calculated from the occurrence rate. These are all executed by the calculation unit 43 incorporated in the data processing unit 4. Further, based on the failure recovery measure execution status obtained by the failure recovery measure monitoring unit 6, the error with the execution time of the past case is corrected to correct the "failure recovery expected time" and notify. Specifically, when the deviation from the initial expected time is 30 minutes or more, the estimated failure recovery time is corrected, the alarm generation unit 7 is activated, and the operator is notified by voice to that effect.

On the other hand, if a similar event has not occurred in the past in the recovery possibility determination element “failure case”, time is accumulated for each recovery possibility determination element. For example, "Construction state"
If there is, add 30 minutes, add 60 minutes if the center system needs to be stopped in the "measure procedure", and add 30 minutes if there is no recovery measure procedure. In addition, "rushing state"
If rushing is required at, add 60 minutes. Also,
If "hardware replacement" is required for "failure type", add 60 minutes, and if it is necessary to return the old file of the application, add 30 minutes. If there is no error information or the like in the "occurrence event", 30 minutes are added. All of these operations are performed by the operation unit 43 built in the data processing unit 4.
Done by If it is not clear whether necessary / unnecessary, presence / absence, etc., it is calculated as a predetermined value × 50%, and when it becomes clear, the normal time is calculated again. Further, the default value of the time can be arbitrarily changed and set before and after the operation of each adaptive system.

As described above, the data processing unit 4 sums up the times accumulated from the recovery expectancy determining elements to calculate the “failure recovery expected time”. Further, based on the failure recovery measure execution status obtained by the failure recovery measure monitoring unit 6, the error with the execution time of the past case is corrected to correct the "failure recovery expected time" and notify. Specifically, when the deviation from the initial expected time is 30 minutes or more, the estimated failure recovery time is corrected, the alarm generation unit 7 is activated, and the operator is notified by voice to that effect.

FIGS. 3 to 9 are views cited for describing the details of the operation of the embodiment of the present invention shown in FIGS. 1 and 2. FIG. Hereinafter, the operation of the embodiment of the present invention shown in FIG. 1 will be described in detail with reference to FIGS. FIG. 3 is a diagram showing a configuration example of the check screen shown in FIG. As shown in the figure, for each of the recovery determinants,
Check items are listed in the vertical direction, the status of each check item is set in advance, and the operator clicks a button via hearing with the user to take in the system. Also,
Points (1 to 4 points) are given to the contents set for each check item, and the points given based on the selected contents are reflected in the schedule magnification. Here, it is assumed that the point values set in the order from the left end of the screen toward the right are higher. If there is no corresponding content, the total points are calculated as 0 points. The setting and calculation of the points are performed by a point management unit 4 built in the data processing unit 4.
Done by

FIG. 4 is a diagram cited for explaining the relationship between the total number of points and the schedule magnification. The schedule magnification shown in FIG. 4 is set based on the input information selected and designated by the operator, and is reflected in the calculation of the expected time of failure recovery described later.

FIG. 5 shows the configuration of the tentative scheduling generated by the failure recovery scheduling slip creation unit 42 incorporated in the data processing unit 4. Here, it is assumed that the failure recovery deciding element is selected by the hardware failure and the software failure indicated by the “fault type”, and the recovery procedure and the template for the hardware failure are shown in FIG. And the process template is shown in (b). Here, steps from A to F are shown for each recovery procedure. In FIGS. 5A and 5B, the contents of the recovery measures for each process are shown in the frames. That is, in (a), the process A is on-site driving, the process B is a procedure check, the process C is stopped at the center, the package D is replaced at the process D, the center is started at the process E, and the normality is checked at the process F. Also,
In (b), process A is remote access, process B is information gathering, process C is review of measures and methods, process D is old file return, process E is measures implemented, and process F is normality confirmation.

FIG. 6 is a diagram cited for explaining the procedure leading to the creation of a formal scheduling slip in which the required time is set in the temporary scheduling slip when a past failure case exists in the case DB1. Here, a hardware failure is exemplified, and the estimated recovery time of the process A is 30.
Step B, 60 minutes, Step C, 20 minutes, Step D, 50 minutes
Minutes, step E is set to 20 minutes, and step F is set to 10 minutes. In addition, the processing start time in each step is shown in the figure (process A starts at 21:00, estimated recovery time is 30 minutes, process B starts at 21:30, estimated recovery time is 60 minutes, C Step 18 starts at 22:30 and the expected recovery time is 20 minutes, Step D starts at 22:50 and the expected recovery time is 50 minutes, Step E starts at 23:40 and the expected recovery time is 20 minutes. Assume that the expected recovery time is 10 minutes after the start of the process F at 0:00). In this case, the execution of the recovery procedure starts at 21:00, and 0:
The recovery measures are scheduled to end at 00, but the checkpoint is reflected in the expected recovery time of the B process and the D process. Here, by multiplying each by the schedule magnification of 1.5, the total processing time of the B process and the D process is calculated. Due to the influence of 165 minutes (expected impact time 55 minutes), the expected recovery time is 1:05.

FIG. 7 is a diagram cited for explaining a procedure leading to the creation of a formal scheduling slip in which the required time is set in the temporary scheduling slip when no past failure cases exist in the case DB1. FIGS. 8 and 9 show the contents of the input information relating to the failure recovery decision element at this time. Here also, a hardware failure is exemplified, and the estimated recovery time of the process A is 90 minutes, and the process B is an error log,
20 minutes to get some error information, 60 minutes for 40 minutes because construction information at the center is under construction, 20 minutes for process C, 60 minutes for hardware failure in D process, need to return old file Therefore, it is assumed that there is a total of 30 minutes, 99 minutes, E step is set to 20 minutes, and F step is set to 20 minutes. Also, the processing start time in each step is shown in the figure (Step A starts at 21:00, Step B starts at 21:00).
(Start at 2:30, Step C starts at 23:30, Step D starts at 23:50, Step E starts at 1:20, Step F starts at 1:40). In this case, 21: 0
The execution of the recovery procedure is started at 0, and the recovery is scheduled to end at 2:00. However, the checkpoint is reflected in the expected recovery time of the process B and the process D. Here, each is multiplied by the schedule magnification 1.1. In this way, step B and D
The total processing time of the process is 150 minutes (expected impact time 15
Minutes), the expected recovery time is 2:15
Indicates that

As described above, according to the present invention, when a measure is determined based on a failure situation, an expected recovery time is automatically calculated from a recovery case and answered to the requesting user.
FIG. 10 shows the processing procedure in comparison with the conventional example. That is, in FIG. 10 (b), when a user requests a failure recovery support, the operator hears the failure status, and refers to the case DB to appropriately confirm and select each recovery expectation determining element, whereby the system is checked. The estimated failure recovery time is automatically calculated internally, and the estimated failure recovery time obtained is answered to the requesting user.

In the embodiment of the present invention, only the mode in which the operator searches the case DB1 based on a user request via telephone or electronic mail and notifies the user of the expected recovery time through the same communication medium has been described. Builds a client-server system and allows the client to use it by implementing the present invention on the server,
Alternatively, by opening the case DB1 to the user via an open network such as the Internet, the burden on the operator is reduced, and a more efficient system can be constructed. Further, in the embodiment of the present invention, only the case where the system is used in the operation system of the exchange as the failure recovery expected time calculation system has been described as an example. Application is possible.

The case DB construction unit 2 in FIG.
A DB index unit 3, a data processing unit 4, a check screen 5, a failure recovery measure monitoring unit 6, an alarm generation unit 7, and a point management unit 41 incorporated in the data processing unit 4.
Programs for realizing the functions of the failure recovery scheduling slip creation unit 42 and the operation unit 43 are respectively recorded on computer-readable recording media, and the programs recorded on the recording media are stored in a computer constituting the present system. The failure recovery time calculation system of the present invention is constructed by causing the computer to read the program and sequentially execute the program.
The computer system referred to here includes an OS and hardware such as peripheral devices.

Further, if the computer system uses a WWW system, it also includes a homepage providing environment (or a display environment). The computer-readable recording medium includes a floppy (registered trademark) disk, a magneto-optical disk, a ROM, and a CD.
-A storage medium such as a portable medium such as a ROM or a hard disk built in a computer system. Further, the computer-readable recording medium is a volatile memory (RA) in a computer system that is a server or a client when a program is transmitted through a network such as the Internet or a communication line such as a telephone line.
As shown in M), a program holding a program for a certain period of time is also included.

The above program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the "transmission medium" for transmitting a program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. Further, the program may be for realizing a part of the functions described above. further,
What can realize the above-mentioned function in combination with a program already recorded in the computer system, that is, a so-called difference file (difference program) may be used.

The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and includes a design and the like without departing from the gist of the present invention. It is.

[0044]

As described above, according to the present invention, the failure recovery prospect determinant of a device is converted into a database from past cases, and when a failure recovery support request is received from a user, similar failure cases are indexed from the case database. By checking and selecting the check items in the case database according to the actual failure situation, the degree of influence on the expected recovery time set in advance for each failure recovery prospect determination element is reflected in the calculation of the expected recovery time. Yes, this makes it possible to automatically calculate the estimated time of failure recovery without providing sufficient training to all operators. Without giving, and improvement of CS can be expected. Although only the case where the operator searches the case DB based on a user request via telephone or e-mail and contacts the user via the same communication medium regarding the expected recovery time has been described, using the client server system Alternatively, by opening the database to the user via an open network such as the Internet, the burden on the operator is greatly reduced, and a more efficient system can be constructed.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a failure recovery estimated time calculation system according to the present invention.

FIG. 2 is a flowchart cited for explaining a schematic operation of the embodiment of the present invention shown in FIG. 1;

FIG. 3 is a diagram cited for describing an operation of the exemplary embodiment of the present invention, and is a diagram illustrating an example of a check screen configuration.

FIG. 4 is a diagram showing a relationship between points managed by a check point management unit shown in FIG. 1 and a schedule magnification.

FIG. 5 is a diagram showing an example of a configuration of a provisional scheduling slip generated and output by a failure recovery scheduling slip creating unit shown in FIG. 1;

FIG. 6 is a diagram cited for explaining a procedure in which a required time is set in a temporary scheduling slip when a past failure case exists in the case DB.

FIG. 7 is a diagram cited for explaining a procedure in which a required time is set in a tentative scheduling ticket when a past failure case does not exist in the case DB.

FIG. 8 is a diagram illustrating an example of input information when no past failure case exists in the case DB;

FIG. 9 is a diagram illustrating an example of input information when no past failure case exists in the case DB;

FIG. 10 is a processing conceptual diagram showing a comparison between a conventional example and the present invention in a processing procedure when a user requests a failure recovery support.

[Explanation of symbols]

1. Case database (DB), 2: Case DB construction unit,
3 DB search unit 4 Data processing unit 5 Check screen 6 Failure recovery monitoring unit 7 Alarm generation unit 4
1: Point management unit, 42: Failure recovery scheduling slip creation unit, 43: Operation unit

Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat II (Reference) G06F 17/30 340 G06F 17/30 340B 17/60 132 17/60 132 502 502 502

Claims (13)

[Claims] 1. A case database constructing means for converting a failure recovery determinant of a device into a database from past cases, and a case database indexing means for indexing similar failure cases from the case database upon receiving a failure recovery support request. Checking and selecting the check items in the case database according to the actual failure status, thereby taking in the degree of influence on the expected recovery time set in advance for each failure recovery prospect determination element and reflecting the data on the calculation of the expected recovery time. Means for calculating an estimated time of failure recovery. 2. The data processing means comprises: a point management means for managing the degree of influence on the expected recovery time for each of the expected recovery decision elements, and a fault recovery procedure obtained by indexing the case database. And recovery time-series slip creation means for generating a recovery time-series slip based on the time required for each step reflecting the points in the required time,
The estimated failure recovery time calculation system according to claim 1, further comprising: 3. The data processing means according to claim 1, further comprising: when a similar failure case does not exist in said case database, accumulates an estimated recovery time for each of said failure recovery expected elements, and accumulates said accumulated time to estimate a failure recovery estimated time. The estimated time of failure recovery calculation according to claim 1 or 2, further comprising a calculation unit for calculating the time. 4. A failure recovery measure monitoring means for monitoring the implementation status of the failure recovery measure, and a result of the monitoring by the failure recovery measure monitoring means, a predetermined time is set between the estimated failure recovery time and the execution time in the past failure case. When a time difference is found,
The estimated failure recovery time calculation system according to claim 1, further comprising: an alarm generation unit configured to correct the estimated failure recovery time and to notify that the correction has been made. 5. A failure recovery prospect determination element of a device is converted into a database from past cases, and when a failure recovery support request is received, similar failure cases are indexed from the case database, and check items of the case database are replaced with actual failure conditions. A failure recovery expected time calculation method characterized by taking in the degree of influence on a recovery expected time set in advance for each failure recovery expected determination element by confirming and selecting according to the following, and reflecting the influence on the calculation of the estimated recovery time. 6. A computer which records a failure recovery expected time calculation program for use in a failure recovery expected time calculation system used in a failure recovery expected time calculation system that determines a failure recovery measure based on a failure state of a device, calculates an expected recovery time from a recovery case, and responds to a request. A possible recording medium, wherein the estimated failure recovery time calculation program comprises: a first step of converting a failure recovery expected determination element into a database from past cases; and, upon receiving a failure recovery support request, a similar failure from the case database. A second step of indexing the case, and confirming and selecting the check items of the case database according to the actual failure state to capture the degree of influence on the expected recovery time set in advance for each failure recovery prospect determination element, A third step to be reflected in the calculation of the expected recovery time; Recording medium recording a fault recovery expected time calculation program executed by a computer. 7. The third step includes: a step of managing the degree of influence on the expected recovery time for each of the expected recovery decision elements; and a fault recovery procedure obtained by indexing the case database. Generating a recovery time-series slip based on the required time for each process in which the required time is reflected in the required time among the required times for each process. A recording medium on which a time calculation program is recorded. 8. The method of claim 3, further comprising: when there is no similar failure case in the case database, accumulating the estimated recovery time for each of the failure recovery prospect elements; 8. A recording medium on which the estimated failure recovery time calculation program according to claim 6 or 7, further comprising a step of calculating an estimated recovery time. 9. A step of monitoring the implementation status of the failure recovery measure, and, when a predetermined time difference is found between the estimated failure recovery time and the execution time in the past failure case as a result of the monitoring, 9. The recording medium according to claim 6, further comprising a step of correcting the estimated time and notifying the occurrence of the correction by issuing an alarm. 10. A failure recovery expected time calculation program used in a failure recovery expected time calculation system that determines a failure recovery measure from a device failure state, calculates a recovery expected time from a recovery case, and responds to a request. A first step of converting a recovery possibility determination element from a past case into a database, a second step of indexing a similar failure case from the case database upon receiving a failure recovery support request, A third step of taking in the degree of influence on the estimated recovery time set in advance for each failure recovery prospect determination element by confirming and selecting according to the failure situation of A failure recovery expected time calculation program for causing a computer to execute steps. 11. The third step includes: a step of managing the degree of influence on the estimated recovery time for each of the estimated recovery decision elements, and a failure recovery procedure obtained by indexing the case database. Generating a recovery time-series ticket based on the required time for each process in which the point is reflected in the required time among the required times for each process, the failure recovery prospect according to claim 10, Time calculation program. 12. The method according to claim 11, further comprising: when a similar failure case does not exist in the case database, accumulating the estimated recovery time for each of the failure recovery expected elements; 12. A failure recovery estimated time calculation program according to claim 10, further comprising a step of calculating an estimated recovery time. 13. A step of monitoring the implementation status of the failure recovery measure; and, as a result of the monitoring, when a predetermined time difference is recognized between the expected recovery time of the failure and the execution time in the past failure case, the failure recovery is performed. 13. The failure recovery estimated time calculation program according to claim 10, further comprising the steps of: correcting the estimated time, and issuing an alarm to notify that the correction has been made.