JP7672275B2 - Countermeasure selection device, system, and countermeasure selection method - Google Patents

Description

The present invention relates to a countermeasure selection device.

In recent years, systems have been provided that use communication functions to collect data on on-site devices in factories and perform remote monitoring and control of facilities and equipment. On the other hand, as the number of connected devices increases and systems become more complex, the amount of work required to take measures when a failure occurs increases, and there is a demand for automating the planning of recovery measures. However, when there are multiple recovery measures for a failure that occurs, the optimal measure varies depending on the requirements of each system. For example, as a criterion for selecting a measure when a failure occurs in a part of a system, there are cases where time is prioritized to aim for early recovery, and cases where availability is prioritized to prioritize not affecting other system areas even if it takes time. In addition, there are cases where human costs are prioritized, where remote response is prioritized without dispatching workers to the site as much as possible. It is important to consider the recovery requirements for these various evaluation indexes and select and implement appropriate measures that conform to the requirements in terms of improving the system availability and reducing operating costs.

There is a technology that supports the selection of recovery measures for an occurrence of a failure, taking into consideration the stability and security of each measure. Patent Document 1 (JP 2020-86474 A) describes a recovery support device that includes an index value calculation means that calculates a predetermined index value for a recovery task sequence that indicates a procedure for recovering from an abnormality that has occurred in a group of devices that constitute a communication network, based on the recovery task sequence, and an output means that outputs the index value calculated by the index value calculation means to a predetermined output destination (see claim 1).

JP 2020-86474 A

In the background technology described in Patent Document 1, stability and safety are taken into consideration, but measures are not selected taking into consideration the preferences of customers and operators, which differ for each system, such as the aforementioned cost-related evaluation index. In actual operation, it is desirable to select measures that flexibly consider these arbitrary evaluation indexes. In addition, the output of evaluation values related to stability and safety encourages workers to select measures, but whether stability or safety should be emphasized depends on the system's operation policy, etc. Therefore, a certain level of knowledge and work experience with the system is required to select the optimal measure from a combination of evaluation values. In order to enable even workers with little knowledge and experience to implement recovery measures, it is desirable to output not only the evaluation values of each measure, but also the priority and ranking of the measures based on the viewpoint of specified requirements, and to uniquely indicate the measures to be taken.

The present invention was made in consideration of the above-mentioned problems, and aims to automatically select measures that conform to any recovery requirements for an occurring failure, and present the measures to be taken with a priority.

A representative example of the invention disclosed in the present application is as follows: That is, a countermeasure selection device for determining a recovery countermeasure for a failure that has occurred in a device itself or another device is configured by a computer having an arithmetic unit that executes a program and a storage device that stores the program and data, and includes countermeasure candidate management information that manages a list of recovery countermeasure candidates for the failure content, a countermeasure candidate selection unit that refers to the countermeasure candidate management information and selects recovery countermeasure candidates for the failure that has occurred, a countermeasure evaluation value management unit that manages evaluation values for each countermeasure for one or more evaluation indexes that are matters to be emphasized in recovery countermeasures, a recovery requirement management unit that manages recovery requirements including a weighted value indicating the priority for each evaluation index and the device to which the recovery requirements are applied, a countermeasure priority determination unit that determines the priority of the recovery countermeasure candidates based on one or more evaluation indexes, and a countermeasure priority determination unit that determines the priority of the recovery countermeasure candidates based on one or more evaluation indexes, and a countermeasure candidate selection ... a weighted value for each recovery requirement and an evaluation index for each recovery requirement; and an output unit for outputting recovery measure candidates with the determined priority, wherein the input unit includes an area in which an evaluation value managed by the recovery requirement management unit can be selected for each recovery requirement and evaluation index, an area in which a weighted value managed by the recovery requirement management unit can be set for each recovery requirement and evaluation index, and an area in which a recovery requirement managed by the recovery requirement management unit can be set for each of the own device or the other device, and the countermeasure priority determination unit calculates a total value of the evaluation values reflecting the weighted values in the recovery requirements applied to a device to be restored, for each recovery measure candidate selected by the countermeasure candidate selection unit, and determines a priority such that the higher the calculated total value, the higher the priority of the recovery measure candidate.

According to one aspect of the present invention, measures that conform to recovery requirements can be automatically selected and output with priorities assigned. Problems, configurations, and advantages other than those described above will become clear from the description of the following embodiment.

FIG. 2 is a diagram illustrating a system configuration and a hardware configuration of each device according to the first embodiment. 4 is a diagram illustrating an example of a configuration of a device information management table managed by a device information management unit of the management device according to the first embodiment; 1 is a diagram illustrating an example of a configuration of a countermeasure candidate management table managed by a countermeasure candidate selection unit of the management apparatus according to the first embodiment; 4 is a diagram showing an example of the configuration of an evaluation value management table managed by a countermeasure evaluation value management unit of the management apparatus according to the first embodiment; FIG. 1 is a diagram illustrating an example of a configuration of a recovery requirement weight management table managed by a recovery requirement management unit of the management apparatus according to the first embodiment; 1 is a diagram illustrating an example of a configuration of a recovery requirement application management table managed by a recovery requirement management unit of the management apparatus according to the first embodiment; 11 is a flowchart of a countermeasure selection process when a failure occurs in the first embodiment. 13 is a diagram showing an example of a screen display for outputting countermeasure candidates and priority information in the first embodiment; FIG. 11A and 11B are diagrams illustrating examples of screen displays for setting information of various tables managed by the management device in the first embodiment. FIG. 11 is a diagram illustrating a configuration example of a recovery requirement application management table managed by a recovery requirement management unit of the management apparatus according to the second embodiment. FIG. 13 is a diagram showing an example of the configuration of a countermeasure performance management table managed by a countermeasure evaluation value management unit of the management apparatus according to the third embodiment. FIG. 13 is a diagram showing an example of the configuration of an evaluation value management table managed by a countermeasure evaluation value management unit of a management apparatus according to a third embodiment. FIG. 13 is a diagram illustrating an example of a conversion function from a performance statistical value to an evaluation value in the third embodiment. 13 is a flowchart of a countermeasure selection process when a failure occurs in the third embodiment. FIG. 13 is a diagram illustrating a configuration example of a recovery requirement weight management table managed by a recovery requirement management unit of a management apparatus according to a fourth embodiment. 13 is a flowchart of a countermeasure selection process when a failure occurs in the fourth embodiment. FIG. 13 is a diagram illustrating a hardware configuration of an apparatus according to a fifth embodiment. 13 is a flowchart of a countermeasure selection process when a failure occurs in the fifth embodiment.

First, we will provide an overview of the system in this embodiment of the present invention.

In the management device that decides on recovery measures for an occurring failure, the candidate countermeasure selection unit manages a list of countermeasures for each type of failure as management information, and the countermeasure evaluation value management unit manages evaluation values for each countermeasure for each arbitrary evaluation index, such as the time required for the countermeasure and the cost. In addition, the recovery requirement management unit manages weighted values obtained by weighting the priority of each evaluation index for each recovery requirement, and further manages the recovery requirements applied to each managed device.

When a failure is detected by receiving an alert indicating the occurrence of an actual failure, the countermeasure candidate selection unit first selects countermeasure candidates corresponding to the failure that has occurred. Next, the recovery requirement management unit refers to the recovery requirements applied to the managed device to be recovered, and further obtains the weighted values for each evaluation index defined in the recovery requirement. Next, the countermeasure priority determination unit of the management device determines the priority of each countermeasure candidate in accordance with the recovery requirement. Specifically, a total evaluation value reflecting the weighted value (each evaluation value multiplied by a weight corresponding to the weighted value) is calculated for each countermeasure candidate, and the total evaluation value is used as the countermeasure priority, and the priority order of each countermeasure candidate is determined in descending order of value. The higher the evaluation value of a countermeasure for the evaluation index to be prioritized, the higher the calculated total evaluation value, so that a countermeasure in accordance with the recovery requirement can be selected with a high priority. Finally, the output unit outputs the countermeasure candidates together with the countermeasure priority (or priority order).

This type of countermeasure selection process makes it possible to automatically select and output appropriate countermeasure candidates according to recovery requirements with any evaluation index that should be prioritized. In addition, because prioritized countermeasure candidates are automatically output, even workers with little knowledge or experience can clearly determine which countermeasures should be prioritized, enabling appropriate disaster recovery work.

The following describes an embodiment of the present invention with reference to the drawings. Note that the embodiment described below does not limit the invention as claimed, and not all of the elements and combinations thereof described in the embodiment are necessarily essential to the solution of the invention.

In the following explanation, the information may be described as an "AAA table", but the information may be structured in any data structure. In other words, to show that the information is independent of the data structure, the "AAA table" can be referred to as "AAA information".

Below, a method for selecting measures according to an embodiment of the present invention will be described with reference to Figures 1 to 17. Example 1 will be described with reference to Figures 1 to 9, Example 2 with Figure 10, Example 3 with Figures 11 to 13, Example 4 with Figures 14 and 15, and Example 5 with reference to Figures 16 and 17.

Example 1
In the first embodiment, the basic form of the countermeasure selection process for a fault that has occurred will be described. First, the system configuration and the configuration of each device will be described with reference to Fig. 1. Next, the tables, i.e., the information, managed by the management device will be described with reference to Figs. 2 to 6. After that, the flow of the countermeasure selection process will be described with reference to Fig. 7, and examples of screen displays related to the output of countermeasure selection results and the input of information will be described with reference to Figs. 8 and 9.

In the following description of the embodiments, when there is no need to separately describe the components, they will be described without a subscript (e.g., device 101), and when they are separately described, they will be described with a subscript (e.g., device 101-a).

First, the system configuration and hardware configuration of each device in the first embodiment will be described with reference to FIG.

The system shown in FIG. 1 includes multiple devices 101 (101-a to 101-c) to be managed and a management device 102. The devices 101 and management device 102 are connected by wired or wireless communication, and the device 101 transmits data acquired from the installation site, operation information of the device itself, alerts, etc. to the management device 102. The management device 102 provides services using data received from the device 101, detects the occurrence of a failure in the device 101 by receiving an alert, etc., and selects and outputs measures for recovery. Note that FIG. 1 shows an example of a configuration in which a system A consisting of devices 101-a and 101-b and a system B consisting of device 101-c exist and these multiple systems are managed by one management device 102, but a configuration in which one management device 102 is provided for each system may also be used. The management device 102 may be installed at the same site as the device 101, or at a different location such as on the cloud.

Next, the hardware configuration of the device 101 will be described. As described above, the device 101 is a device that stores data acquired from the site and its own device's operating information in packets and transmits them, and has a communication function with the management device 102. The device 101 has various configurations depending on the type of data it acquires. For example, the device 101 may be a temperature measuring device that measures the temperature at the site, a camera device that acquires images of the site, or an aggregation device that aggregates and transmits data from other devices present at the site. In FIG. 1, the device 101 has a communication I/F 111, a CPU 112, and a storage device 113.

For example, when transmitting and receiving packets to and from the management device 102 via wireless communication, the communication I/F 111 has a transmitting unit that converts digital data to and from wireless signals and transmits the digital data as a wireless signal, and a receiving unit that extracts the digital data from the received wireless signal. When the device 101 transmits and receives packets not only to and from the management device 102 but also to and from other devices present at the site, the device 101 may be equipped with multiple communication I/Fs 111. These communication means may be any means, such as Ethernet (registered trademark), Wi-Fi (registered trademark), a telephone network, or an optical fiber line.

The CPU 112 is a calculation device that executes various computer programs stored in the storage device 113, thereby realizing the various functions of the device 101. Note that some of the processing performed by the CPU 112 by executing the computer programs may be executed by another calculation device (for example, hardware such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).

The storage device 113 has a storage device constituted by, for example, a read-only semiconductor memory (ROM) and a storage element constituted by, for example, a rewritable semiconductor memory (RAM), and stores computer programs that realize various processes, acquired data, etc. The storage device 113 may also have a non-volatile storage medium (magnetic disk drive, non-volatile memory, etc.).

The application program 114 manages various settings such as data acquisition methods and transmission schedules, and executes acquisition processing by the CPU 112 connected via an internal bus and transmission commands to the communication processing unit 115. In addition, the application program 114 may have a function of managing rules for generating alerts that notify the occurrence of a fault in the device itself (e.g., generating an alert when CPU usage exceeds a threshold value), and executing a command to send an alert to the communication processing unit 115 when a fault occurs.

The communication processing unit 115 executes transmission and reception processing in communication. Specifically, it executes packet assembly processing for packets to be transmitted and packet analysis processing such as judging whether a received packet is addressed to the device itself. The device 101 may be an independent device or an embedded device. As described above, the device 101 can be configured in various ways according to the type of on-site data to be acquired, and may also include, for example, a temperature sensor or a camera module.

Next, the hardware configuration of the management device 102 will be described. The management device 102 has a communication I/F 121, a CPU 122, an input unit 123, an output unit 124, and a storage device 125. The communication I/F 121, the CPU 122, and the storage device 125 are the same in terms of hardware as the communication I/F 111, the CPU 112, and the storage device 113 of the device 101 described above. In addition, the communication processing unit 127 is the same as the communication processing unit 115 of the device 101 described above.

The management device 102 is a computer system configured on one physical computer, or on multiple computers configured logically or physically, and may operate on a virtual computer constructed on multiple physical computer resources. For example, the application program 126, the communication processing unit 127, the device information management unit 128, the fault detection unit 129, the countermeasure candidate selection unit 130, the countermeasure evaluation value management unit 131, the recovery requirement management unit 132, and the countermeasure priority determination unit 133 may each operate on separate physical or logical computers, or multiple units may be combined to operate on a single physical or logical computer.

The input unit 123 is composed of, for example, a keyboard and a mouse, and is used by the operator to input various operations and settings. The output unit 124 is composed of, for example, an LCD monitor, and displays necessary screens and the results of various processes. However, in cases where input information is received from an external device via the communication I/F 121 and output information is provided to an external device, such as in a form of remote login to the management device 102 from another external device connected to the management device 102, the input unit 123 and the output unit 124 do not need to be installed in the management device 102.

The application program 126 is a program that provides the user with services that utilize collected data. For example, a program that provides the average value per unit time of on-site data (e.g., temperature) received from the device 101 performs data analysis processing such as calculating the average value from the collected data values. In addition, the application program 126 may also include a program that remotely sets and remotely manages the data transmission schedule from the device 101.

The device information management unit 128 manages the system to which each device 101 belongs. To manage the system to which each device 101 belongs, the device information management unit 128 manages a device information management table 128a, which will be described later in FIG. 2. However, when one management device 102 is provided for each system, the system to which the device 101 belongs is self-evident, and therefore the device information management unit 128 can be omitted.

The fault detection unit 129 detects the occurrence of a fault in the device 101 based on information received from the device 101. The fault detection method is not limited to a specific method, and any method may be used. For example, fault detection may be based on receiving an alert from the device 101 notifying the occurrence of a fault, or based on analysis of operation information received from the device 101.

The countermeasure candidate selection unit 130 selects countermeasure candidate for the fault detected by the fault detection unit 129. To select countermeasure candidate, the countermeasure candidate selection unit 130 manages the countermeasure candidate management table 130a described later in FIG. 3.

The countermeasure evaluation value management unit 131 manages the evaluation value by evaluation index for each countermeasure against a failure. The number and types of evaluation indexes are arbitrary, and any evaluation index related to a specified recovery requirement, such as the human cost and material cost incurred when implementing the countermeasure, the communication interruption time, and the time required for the countermeasure, may be set. The countermeasure evaluation value management unit 131 manages an evaluation value management table 131a, which will be described later in FIG. 4, in order to manage the evaluation value of the countermeasure by the evaluation index.

The recovery requirement management unit 132 manages information related to recovery requirements, and more specifically, manages the priority of each evaluation index for each recovery requirement as a weighted value. To manage the weighted value information, the recovery requirement management unit 132 manages a recovery requirement weighted value management table 132a, which will be described later in FIG. 5. Furthermore, the recovery requirement management unit 132 manages a list of recovery requirements applied to each device 101 using a recovery requirement application management table 132b, which will be described later in FIG. 6.

The countermeasure priority determination unit 133 calculates an execution priority according to a predetermined recovery requirement for each countermeasure candidate selected by the countermeasure candidate selection unit 130. The priority is calculated using an evaluation value and a weighted value, and details will be described later with reference to FIG. 7. After calculating the priority for each countermeasure candidate, the countermeasure priority determination unit 133 outputs the priority information together with the countermeasure candidate for the failure that has occurred via the output unit 124.

The device information management table 128a managed by the device information management unit 128 of the management device 102 will be described with reference to FIG. 2. The device information management table 128a manages information indicating which system each device 101 belongs to. FIG. 2 illustrates the configuration of the device information management table 128a in Example 1.

The device ID 201 is an identifier of the device 101. Specifically, the device ID 201 is a field in which the address, host name, etc. of the device 101 is entered, and the identifier of the device 101 may conform to the method adopted by the system. When each device 101 is identified by an IP address, MAC address, or unique identifier, these identifiers may be entered. In the example of FIG. 2, the identifier of the device 101 is indicated by the subscript in FIG. 1. The system ID 202 is an identifier of the system to which the device 101 entered in the device ID 201 belongs. The system identifier may also conform to the method adopted by each system. In the example of FIG. 2, the system identifier is indicated by the system name shown in FIG. 1.

By referring to the device information management table 128a, the device information management unit 128 of the management device 102 can grasp the system to which each device 101 belongs. In the example of FIG. 2, it can be determined that device 101-a (device ID: a) and device 101-b (device ID: b) belong to system A (system ID: System-A), and device 101-c (device ID: c) belongs to system B (system ID: System-B). The device information management table 128a may be registered by an operator when the system is constructed, or the system information stored in the packet transmitted by the device 101 may be acquired by the packet analysis process of the communication processing unit 127 and the information may be automatically registered. Also, as described above, when one management device 102 is provided for each system, the system to which the device 101 belongs is self-evident, so the device information management unit 128 can be omitted.

Referring to FIG. 3, the countermeasure candidate management table 130a managed by the countermeasure candidate selection unit 130 of the management device 102 will be described. The countermeasure candidate management table 130a manages a list of countermeasure candidates for each type of failure. FIG. 3 illustrates the configuration of the countermeasure candidate management table 130a in Example 1.

The fault ID 301 is an identifier for distinguishing the fault content. The naming convention for the fault identifier is arbitrary, and in the example of FIG. 3, a notation such as "Fault001" is used, but a specific fault content such as "radio interference occurrence" may be used as the identifier, for example, as shown in FIG. 3. The countermeasure ID 302 is an identifier for a countermeasure for recovering from the fault described in the fault ID 301. The naming convention for the countermeasure identifier is also arbitrary, and in the example of FIG. 3, a notation such as "Counter001" is used, but a specific countermeasure content such as "change of wireless channel" may be used as the identifier, for example, as shown in FIG. 3. In addition, as shown in FIG. 3, if there are multiple countermeasures for one fault, multiple countermeasure IDs 302 may be registered in the table for one fault ID 301.

By referring to the countermeasure candidate management table 130a, the countermeasure candidate selection unit 130 of the management device 120 can select countermeasure candidate according to the fault that has occurred. In the example of FIG. 3, when a fault caused by radio wave interference from other devices is detected at the installation site of the device 101 that uses wireless communication, it can be determined that countermeasure candidate selection should be made such as "changing the wireless channel" or "changing the installation location" to avoid the interference, or "replacing the antenna" to transmit with a stronger output than the interfering radio waves. Note that the countermeasure candidate management table 130a may be used to register faults and countermeasures anticipated during the system construction stage, or may be used to register new faults and corresponding countermeasures at any time when they are observed.

The evaluation value management table 131a managed by the countermeasure evaluation value management unit 131 of the management device 102 will be described with reference to FIG. 4. The evaluation value management table 131a manages evaluation values for each evaluation index related to recovery requirements for each countermeasure registered in the countermeasure candidate management table 130a. FIG. 4 shows an example of the configuration of the evaluation value management table 131a in Example 1.

The countermeasure ID 401 is an identifier of the same countermeasure as the countermeasure ID 302 in the countermeasure candidate management table 130a in FIG. 3. When the countermeasures described in the countermeasure candidate management table 130a and the evaluation value management table 131a are the same, the identifiers described in the countermeasure ID are the same. The evaluation value 402 is an evaluation value for each evaluation index regarding the countermeasure described in the countermeasure ID 401. In FIG. 4, the evaluation indexes include "personnel cost" (e.g., dispatching cost of workers), "physical cost" (e.g., cost of replacement parts), "communication interruption time" (interruption time of communication connecting the device 101 and the management device 102, or the device 101 and other devices), and "required time". However, as described above, the number, type, and name of the evaluation indexes to be managed are not limited, and may be arbitrarily defined according to the index to be considered as a recovery requirement. For example, an index such as "stability" may be set as in Patent Document 1.

In the example of FIG. 4, the evaluation value is defined as a range of "1 to 10" with a higher value indicating a higher evaluation, but the range of the evaluation value may be set arbitrarily. The method of setting the evaluation value is also arbitrary, and as described in Patent Document 1, the evaluation value may be calculated using machine learning based on past recovery information, or an original criterion may be set for each evaluation indicator to define the evaluation value. For example, in the case of "communication interruption time," no communication interruption may be assigned an evaluation value of 10 points, an interruption time of the order of several minutes may be assigned 7 points, an interruption time of the order of several hours may be assigned 4 points, and a day or more may be assigned 1 point.

By setting the evaluation value management table 131a, it is possible to manage which index each measure is superior in. For example, in FIG. 4, "wireless channel change" is superior in the index of "human cost" because it does not require dispatching a worker to change the settings remotely, and it is accompanied by a temporary "communication interruption time" due to restarting the device 101 associated with the setting change. In addition, "installation location adjustment" is superior in the index of "communication interruption time" because it does not require restarting the device 101 and does not cause communication interruption, but it is inferior to the measure "wireless channel change" in the index of "human cost" because it requires dispatching a worker or requesting work from a customer on-site, since it requires human labor to adjust the installation location. In this example, depending on whether "human cost" or "communication interruption time" is prioritized as a recovery requirement, which of "wireless channel change" and "installation location adjustment" should be selected differs, and by referring to the evaluation value information, it is possible to compare the superiority or inferiority of measures in accordance with the recovery requirements. The evaluation value management table 131a may be registered at the system construction stage, or may be updated at any time during system operation.

The recovery requirement weight management table 132a managed by the recovery requirement management unit 132 of the management device 102 will be described with reference to FIG. 5. The recovery requirement weight management table 132a manages the priority of each evaluation index for each recovery requirement. Specifically, the priority of each evaluation index is defined as a weight for the evaluation value, and if the priority of the evaluation index is high, a high weight is set. FIG. 5 shows an example of the configuration of the recovery requirement weight management table 132a in the first embodiment.

The recovery requirement ID 501 is an identifier for distinguishing recovery requirements. The naming convention for this identifier is arbitrary, and in the example of FIG. 5, a notation such as "Policy001" is used, but a name indicating the policy of the recovery requirement, such as "cost priority" as shown in FIG. 5, may be registered. The weighting value 502 expresses the priority of each evaluation index in the recovery requirement described in the recovery requirement ID 501 as a weighting value for the evaluation value. In the example of FIG. 5, the weighting value is defined in the range of "0 to 1", but the range of the weighting value may be set arbitrarily.

For example, in the example of FIG. 5, in the recovery requirement "Policy002" that prioritizes system availability, the weighting value for the evaluation index "communication outage time" is set higher than other indexes, reflecting the recovery requirement that the top priority is to prevent system outages due to communication interruptions. In the example of FIG. 5, the weighting value for other evaluation indexes is set to "0.1", but if there is no need to consider other evaluation indexes at all, the weighting value may be set to "0". On the other hand, for example, if a penalty cost is paid to the customer depending on the system outage time, it is desirable to consider the evaluation index "communication outage time" even in the recovery requirement "Policy001" that prioritizes cost. In that case, as illustrated in FIG. 5, by setting the weighting value for "communication outage time" a little higher, recovery requirements can be set that consider "communication outage time" while giving top priority to the indicators "personnel cost" and "physical cost" that are directly related to cost. By flexibly defining the detailed priority level that differs for each recovery requirement as a weighted value, any recovery requirement that matches the system operation policy or customer orientation can be expressed and managed in the recovery requirement weighted value management table 132a. Note that the recovery requirement weighted value management table 132a may be registered at the system construction stage, or may be registered or changed at any time during system operation.

The recovery requirement application management table 132b managed by the recovery requirement management unit 132 of the management device 102 will be described with reference to FIG. 6. The recovery requirement application management table 132b manages the recovery requirements applied to each device 101. FIG. 6 shows an example of the configuration of the recovery requirement application management table 132b in the first embodiment.

The device ID 601 and the system ID 602 are the identifiers of the device 101 and the system to which it belongs. As described in the explanation of the device information management table 128a in FIG. 2, the format of the identifiers is arbitrary. Note that if the identifier of the device 101 is entered in the device ID 601 field and there is no duplication of identifiers of the device 101 between systems, the device 101 can be uniquely identified by the device ID 601, and the system ID 602 may be left blank. Also, if one management device 102 is provided for each system, the system to which each device 101 belongs is self-evident, and so the system ID 602 field can be omitted.

The recovery requirement ID 603 is an identifier of the recovery requirement applied to the device 101 described in the device ID 601 and the system described in the system ID 602. The identifier described in the recovery requirement ID 603 is selected from the identifiers described in the recovery requirement ID 501 of the recovery requirement weight management table 132a in FIG. 5. When applying the same recovery requirement to all devices 101 belonging to a certain system, as shown in FIG. 6, the system identifier may be specified in the system ID 602 field and the wildcard "*" may be specified in the device ID 601 column. This is particularly effective when many devices 101 belong to the same system and it is troublesome to enter the identifiers of all devices 101 in the device ID 601. Of course, different recovery requirements may be applied to multiple devices 101 belonging to the same system, as shown in FIG. 6.

The countermeasure selection process by the management device 102 will be described with reference to FIG. 7. In terms of the general process flow, in the management device 102, when the fault detection unit 129 detects the occurrence of a fault in the device 101, the countermeasure candidate selection unit 130 selects countermeasure candidates for the fault that has occurred. Thereafter, the countermeasure priority determination unit 133 determines the countermeasure priority for each countermeasure candidate according to the recovery requirements, and the output unit 124 outputs the countermeasure candidates with the priority information attached. FIG. 7 is a flowchart of the countermeasure selection process in Example 1, and will be described in detail below.

In step S701 in FIG. 7, the fault detection unit 129 of the management device 102 detects the occurrence of a fault in the device 101. As described above, the fault detection method is arbitrary, such as detection based on receiving an alert, and if a fault is detected (YES), the process proceeds to step S702. At this time, if the management device 102 is managing multiple systems in an integrated manner, the device information management table 128a in FIG. 2 managed by the device information management unit 128 is referenced, and the system information to which the device 101 where the fault occurred belongs is obtained. If no fault is detected (NO), the process of step S701 is executed again after an arbitrary time has elapsed.

In step S702, the countermeasure candidate selection unit 130 refers to the countermeasure candidate management table 130a in FIG. 3 and selects countermeasure candidate for the fault detected in step S701. For example, if the fault is "occurrence of radio interference," the countermeasure candidate management table 130a in FIG. 3 selects three countermeasure candidate: "change wireless channel," "adjust installation location," and "replace antenna." When the process of step S702 ends, the process proceeds to step S703.

In step S703, the recovery requirement management unit 132 refers to the recovery requirement application management table 132b in FIG. 6, and acquires the recovery requirement to be applied to the device 101 that is the source of the failure detected in step S701. For example, if the device 101 that is the source of the failure is device 101-a (device ID: a), in the example of FIG. 6, the recovery requirement "Policy001 (cost priority)" is acquired. When the processing of step S703 ends, the process proceeds to step S704.

In step S704, the recovery requirement management unit 132 refers to the recovery requirement weight management table 132a in FIG. 5 to obtain a weight value for each evaluation index in the applied recovery requirement obtained in step S703. In the above example, since the applied recovery requirement is "Policy001", in the example of FIG. 5, the weight values obtained are "Evaluation index 1 (personnel cost): 1, Evaluation index 2 (physical cost): 1, Evaluation index 3 (communication interruption time): 0.5, Evaluation index 4 (required time): 0.1". When the processing of step S704 ends, the process proceeds to step S705.

In step S705, the countermeasure priority determination unit 133 refers to the evaluation value management table 131a in Fig. 4 managed by the countermeasure evaluation value management unit 131, obtains the evaluation value for each countermeasure candidate selected in step S702, and calculates a total evaluation value reflecting the weight value obtained in step S704. Specifically, when there are N types of evaluation indexes, the evaluation value of the countermeasure related to evaluation index i (1 ≤ i ≤ N) is xi, and the weight value in the applied restoration requirement is yi, the total evaluation value is defined by the following formula.
Total evaluation value = (x1 x y1) + ... + (xi x yi) + ... + (xN x yN)

In the above example, the weighting value of the applied restoration requirement "Policy001" is "Evaluation index 1:1, Evaluation index 2:1, Evaluation index 3:0.5, Evaluation index 4:0.1", and the evaluation value of "Counter001 (wireless channel change)" in the example of FIG. 4 is "Evaluation index 1:10, Evaluation index 2:10, Evaluation index 3:7, Evaluation index 4:10", so the total evaluation value for "wireless channel change" is calculated as 24.5 (=10x1+10x1+7x0.5+10x0.1). Similarly, the total evaluation value of "Counter002 (installation location adjustment)" is calculated as 20.5 (=5x1+10x1+10x0.5+5x0.1), and the total evaluation value of "Counter003 (antenna replacement)" is calculated as 9.6 (=1x1+5x1+7x0.5+1x0.1). Once processing in step S705 is complete, proceed to step S706.

In step S706, the countermeasure priority determination unit 133 determines the countermeasure priority as the total evaluation value, and determines the priority order of each countermeasure candidate in descending order of this value. After determining the priority order, the countermeasure candidates selected in step S702 are output from the output unit 124 together with the determined priority order or countermeasure priority (total evaluation value). An example of the screen display related to the output will be described later with reference to FIG. 8.

In the above example, in the cost-prioritized recovery requirement "Policy001", of the three countermeasure candidates, "wireless channel change" with the highest total evaluation value is determined to have the first priority (countermeasure priority: 24.5), "installation location adjustment" with the next highest total evaluation value is determined to have the second priority (countermeasure priority: 20.5), and "antenna replacement" is determined to have the third priority (countermeasure priority: 9.6), and this result is output via the output unit 124. As a result, in this example, it is possible to determine that "wireless channel change" is the optimal countermeasure. Note that when "Policy002" in FIG. 5 is applied, the total evaluation value of "wireless channel change" is calculated to be 10, the total evaluation value of "installation location adjustment" is calculated to be 12, and the total evaluation value of "antenna replacement" is calculated to be 7.7, so that "installation location adjustment" can be determined to be the optimal countermeasure in the uptime-prioritized recovery requirement "Policy002". In this way, by determining the countermeasure priority based on the weight value and the evaluation value, a countermeasure that conforms to the applied recovery requirement can be flexibly selected. Furthermore, since candidate countermeasures are output in order of priority, even workers with little knowledge or experience can easily determine the countermeasures that should be taken for the fault. When the processing of step S706 is completed, the countermeasure selection process of FIG. 7 is terminated.

With reference to FIG. 8, an example of a screen display that outputs candidate countermeasures and priority information selected in the countermeasure selection process of FIG. 7 will be described. FIG. 8 is a diagram showing an example of a screen display that is output in step S706 of FIG. 7. The output unit 124 of the management device 102 outputs data for displaying a display screen 800 shown in FIG. 8. The display screen 800 includes a display area 801 that displays fault information, and a display area 802 that displays countermeasure information for the fault that has occurred.

In the display area 801, fault information detected by the fault detection unit 129 of the management device 102 is displayed. In the example of FIG. 8, information on the device 101 from which the fault occurred, information on the system to which it belongs, and the fault details are displayed, and any other information, such as the time the fault was detected, may also be displayed as necessary.

Display area 802 displays countermeasure information for recovering from the fault information output to display area 801. In the example of FIG. 8, the recovery requirement information applied to the device 101 at the source of the fault among the information managed by the recovery requirement management unit 132, and countermeasure candidates selected by the countermeasure candidate selection unit 130 are displayed with the priorities determined by the countermeasure priority determination unit 133. Note that in the example of FIG. 8, the priorities of the countermeasure candidates are displayed, but in order to clearly show the degree of difference in priority between the priorities, the countermeasure priority (total evaluation value calculated in step S705 of FIG. 7) may also be displayed.

The screen display in FIG. 8 allows an operator to identify the details of the fault that has occurred and the device 101 and system from which the fault occurred. Furthermore, by referring to the prioritized countermeasure information, even an operator with no knowledge or experience can uniquely determine which countermeasure should be taken as a priority. Note that the screen is not limited to the example screen in FIG. 8, and may be a screen that displays, for example, a predetermined number of candidate countermeasures with high priority (e.g., one candidate countermeasure with the highest priority), and the display format of the fault information and countermeasure information is not limited to a specific method.

With reference to FIG. 9, an example of a screen display for setting information for various tables managed by the management device 102 will be described. FIG. 9 shows an example of a setting screen. The output unit 124 of the management device 102 outputs data for displaying the display screen 900 shown in FIG. 9. The display screen 900 includes a display area 901 for setting an evaluation value for each measure, a display area 902 for setting a weighting value for each recovery requirement, and a display area 903 for setting recovery requirements to be applied to each device.

The display area 901 is an area for setting the evaluation value management table 131a (Figure 4) managed by the countermeasure evaluation value management unit 131 of the management device 102. When an evaluation value for each evaluation index is selected for each countermeasure, the input value is set in the evaluation value management table 131a. Note that measures for failure recovery and evaluation indexes to be considered in the recovery requirements can be added at any time by operating the add button 904. The add button 904 can be used to add new countermeasures and new evaluation indexes that arise during the operation of the system.

The display area 902 is an area for setting the recovery requirement weight management table 132a (FIG. 5) managed by the recovery requirement management unit 132 of the management device 102. When the weight value of each evaluation index is selected for each recovery requirement, the input value is set in the recovery requirement weight management table 132a. When an evaluation index is added using the add button 904 in the display area 901, the evaluation index column in the display area 902 is also automatically added. In addition, the add recovery requirement button 904 is provided in the display area 902, making it possible to add recovery requirements during the operation of the system.

The display area 903 is an area for setting the recovery requirement application management table 132b (FIG. 6) managed by the recovery requirement management unit 132 of the management device 102. When the recovery requirements to be applied to each device 101 and each system are selected, the input values are set in the recovery requirement application management table 132b. In addition, an add device and system button 904 is provided in the display area 903, making it possible to add a device 101 during the operation of the system.

In addition to managing the information in various tables on the screen of FIG. 9, it is also possible to manage it through the input and output of external files. For this reason, the example screen display of FIG. 9 is provided with a file input button 905 and a file output button 906. Operating the file input button 905 loads the various table values saved in an external file onto the screen of FIG. 9. Operating the file output button 906 outputs the table values entered on the screen of FIG. 9 to an external file. This makes it easy to achieve linkage with external files in which table values are stored. However, the inclusion of a file input/output function is optional.

The setting screen for the information of various tables as shown in FIG. 9 makes it easy to change the various table values midway, and can flexibly accommodate the addition of the above-mentioned countermeasures, evaluation indexes, recovery requirements, and devices 101. Note that the example screen display in FIG. 9 has display areas for setting the evaluation value management table 131a in FIG. 4, the recovery requirement weight value management table 132a in FIG. 5, and the recovery requirement application table in FIG. 6, but similarly, display areas for setting the device information management table 128a in FIG. 2 and the countermeasure candidate management table 130a in FIG. 3 may be provided. Also, the example screen display in FIG. 9 illustrates a form in which table values are selected and set in a pull-down format, but the setting values may be directly input, and various input formats can be adopted.

In this embodiment, the screens of FIG. 8 and FIG. 9 are displayed and operated via the input unit 123 and output unit 124 of the management device 102. However, as described above, for example, by remotely logging in to the management device 102, an external device may receive information via the communication I/F 121, output display data for displaying the screens of FIG. 8 and FIG. 9 on the external device via the communication I/F 121, and display the screen on the display of the external device. In this case, the input unit 123 and the output unit 124 may be omitted.

As described above, according to this embodiment, when a failure occurs in the device 101, candidate countermeasures that conform to the recovery requirements can be automatically selected for the failure that has occurred, and candidate countermeasures can be output with a countermeasure priority that reflects any recovery requirement. This makes it possible to take appropriate countermeasures that conform to the recovery requirements, thereby improving the system's operating rate and reducing the countermeasure costs required for recovery. Furthermore, because priority information is clearly indicated for each candidate countermeasure, even workers with little knowledge or experience can easily determine the appropriate countermeasure.

Example 2
In the first embodiment, a countermeasure selection process in which a single recovery requirement is applied to each device 101 has been described. On the other hand, there may be cases in which different recovery requirements should be applied as appropriate depending on the situation. For example, there may be cases in which a recovery requirement of "cost priority" is applied during the construction period of the system, and "availability priority" is applied after the system starts operating. In this example, it is desirable that the recovery requirement applied to the device 101 is automatically changed from "cost priority" to "availability priority" at the time the system starts operating. Therefore, in the second embodiment, assuming a change in recovery requirements according to the operation phase of the system, etc., a form in which the applied recovery requirement is changed by a change in time or an excess of a threshold value of a specific parameter is described.

In the second embodiment, the configuration of the recovery requirement application management table 132b managed by the recovery requirement management unit 132 of the management device 102 will be described with reference to FIG. 10. Note that the various configurations and processes related to the second embodiment are the same as those of the first embodiment except for the configuration of the recovery requirement application management table 132b shown in FIG. 10, and therefore the description thereof will be omitted.

Figure 10 shows an example of the configuration of the recovery requirement application management table 132b in the second embodiment. The fields of device ID 601, system ID 602, and recovery requirement ID 603 are the same as the fields of the recovery requirement application management table 132b in the first embodiment in Figure 6, and their description will be omitted. The recovery requirement application management table 132b in the second embodiment has fields of judgment parameter 1003, judgment condition 1004, and threshold value 1005, and when the conditions described in the relevant field groups are satisfied, the recovery requirement described in recovery requirement ID 1006 is applied.

The judgment parameters 1003 are information on parameters that are used to judge whether the recovery requirements are applied. In the example of FIG. 10, the current time and packet error rate are exemplified, but the parameter type and name entered in the field are arbitrary. For example, parameters such as CPU usage rate may be used as the operation information of the device 101.

The judgment condition 1004 is a magnitude relationship with respect to the threshold value 1005. In addition to the magnitude relationships illustrated in FIG. 10, conditions such as "= (match)" and "≠ (mismatch)" can be set. The notation format in this field is arbitrary, and may be written as an inequality sign or a character string such as "less than."

Threshold 1005 is the threshold of judgment parameter 1003. In the example of FIG. 10, if the time is defined in judgment parameter 1003, the threshold may be defined in any format according to the parameter type, such as by entering time information in the field. In the example of FIG. 10, for example, if the current time is before "2020/10/01 00:00:00", the recovery requirement of "Policy001 (cost priority)" is applied to device 101-a (device ID: a), and after the time described in threshold 1005 is exceeded, the recovery requirement of "Policy002 (availability priority)" is applied. Therefore, for example, if you want to change the recovery requirement to be applied before and after the system starts operating as described above, you can set the operation start time in the threshold 1005 field. On the other hand, for device 101-b (device ID: b), for example, the recovery requirement "Policy 003 (balanced priority)" is applied while the packet error rate in communication with the management device 102 is within 50%, and when it exceeds 50%, "Policy 004 (time priority)" is applied. In this way, when the packet error rate increases and a failure occurs at a level that interferes with data collection, the recovery requirement is changed to "time priority" to aim for early recovery. In this way, by setting a parameter related to the performance index in the judgment parameter 1003, it is possible to switch the recovery requirement according to the system quality. Of course, if you want to apply one recovery requirement at all times as in Example 1, you can simply leave the judgment parameter 1003, judgment condition 1004, and threshold value 1005 undefined, as shown in FIG. 10.

The judgment parameters 1003 defined in the recovery requirement application management table 132b in the second embodiment may define the personnel required for recovery, in addition to the time judgment conditions shown in FIG. 10 and the judgment conditions for the operating state of the device.

Note that, although other configurations and processes are similar to those of the first embodiment, in step S703 of the countermeasure selection process of FIG. 7 in the second embodiment, when obtaining the recovery requirements to be applied to the source of the failure by referring to the recovery requirement application management table 132b of FIG. 10, the recovery requirements to be applied are determined not only based on the device ID 1001 and the system ID 1002, but also by taking into consideration the judgment parameters 1003, the judgment conditions 1004, and the threshold value 1005.

As described above, according to this embodiment, the recovery requirements to be applied can be dynamically changed according to the operation phase and quality of the system, and appropriate measures can be selected in response to the changing recovery requirements. Of course, in the first embodiment, too, an operator can monitor changes in time and specific parameters and change the recovery requirements to be applied using the screen in FIG. 9 or the like, but if the judgment conditions are registered in advance in the recovery requirement application management table 132b as in this embodiment, the recovery requirements to be applied can be automatically switched and the measure selection process can be executed without human intervention.

Example 3
In the third embodiment, a form in which an evaluation value of a measure is set and updated based on the actual value of each evaluation index when the measure is actually executed will be described. When taking measures against an occurred failure, the actual values of the cost and the time required may differ from the assumptions made when the evaluation value was established. In selecting measures that conform to the recovery requirements, it is desirable to set an evaluation value that reflects the actual situation. In the third embodiment, a form in which the actual values of each evaluation index that occurs when the measure is executed are recorded and the evaluation value is determined based on the actual information will be described.

In Example 3, in addition to the evaluation value management table 131a, the countermeasure evaluation value management unit 131 of the management device 102 in FIG. 1 manages a countermeasure performance management table 131b that manages performance values for each evaluation index generated when a countermeasure is implemented. Of the tables managed by the countermeasure evaluation value management unit 131 of the management device 102 in Example 3, FIG. 11 shows the countermeasure performance management table 131b, and FIG. 12 shows the evaluation value management table 131a. In addition, the countermeasure selection process, including updating of the evaluation value based on performance information, will be described with reference to FIG. 13. Note that the various configurations and processes related to Example 3 are the same as those of the first or second embodiment except for the configurations and processes shown in FIG. 11 to FIG. 13, and therefore descriptions of these will be omitted.

The countermeasure performance management table 131b managed by the countermeasure evaluation value management unit 131 of the management device 102 will be described with reference to FIG. 11. When taking countermeasures against an occurrence of a failure, the worker records the recovery results and the performance values for each evaluation index in the countermeasure performance management table 131b. FIG. 11 shows an example of the configuration of the countermeasure performance management table 131b in the third embodiment.

Measure ID 1101 is an identifier of the measure implemented for the occurring failure. The format of the measure identifier may be the same as the format of measure ID 302 in measure candidate management table 130a in FIG. 3 and measure ID 401 in evaluation value management table 131a in FIG. 4.

The execution date and time 1102 is the date and time when the measure described in the measure ID 1101 was implemented. The date and time may be expressed in any format.

Recovery result 1103 is a field in which whether or not the countermeasure described in countermeasure ID 1101 has actually resulted in recovery from the failure is recorded. In the example of FIG. 11, recovery result 1103 is recorded as "o" or "x", but the format is arbitrary. Note that the execution date and time 1102 and recovery result 1103 fields are not required. However, by providing a recovery result 1103 field and recording the recovery result, for example, if the recovery probability by each countermeasure is included in the evaluation index, the recovery probability can be calculated using the recovery result 1103 field.

Actual value 1104 is a field in which the actual actual value that occurs as a result of taking measures for each evaluation index related to the recovery requirement is recorded. In the example of FIG. 11, when recording the actual value in the actual value 1104 field, the unit information at the time of writing may be set arbitrarily for each evaluation index. Actual value 1104 may be a value that is aggregated for each device or system.

Each time a countermeasure is actually taken in the real environment, the recovery results and performance values are recorded and accumulated in the countermeasure performance management table 131b in FIG. 11, so that an evaluation value that more accurately reflects the actual situation can be set in the evaluation value management table 131a in FIG. 12, which will be described later. Note that the countermeasure performance management table 131b in FIG. 11 may record any information, such as the identifier of the device 101 that was the target of the countermeasure or the identifier of the system to which the device 101 belongs.

The evaluation value management table 131a managed by the countermeasure evaluation value management unit 131 of the management device 102 will be described with reference to Figures 12A and 12B. The evaluation value management table 131a of the third embodiment manages performance statistics (performance average in the example of Figure 12A) for each evaluation index for each countermeasure based on performance information recorded in the countermeasure performance management table 131b described above, and sets an evaluation value based on the performance statistics. Figure 12A shows the configuration of the evaluation value management table 131a in the third embodiment, and Figure 12B shows an example of a conversion function from performance statistics to an evaluation value.

First, the measure ID 401 in FIG. 12A is an identifier of the measure, and is the same as the measure ID 401 in the evaluation value management table 131a in the first embodiment in FIG. 4. The format of the measure identifier may be the same as the measure ID 302 in the measure candidate management table 130a in FIG. 3 and the format of the measure ID 401 in the evaluation value management table 131a in FIG. 4.

The performance statistics 1202 are performance statistics for each evaluation index related to the measure described in the measure ID 1201. Specifically, the statistics are calculated based on the performance values recorded in the measure performance management table 131b in FIG. 11, and in the example of FIG. 12A, the average value for each evaluation index is calculated and recorded as the performance statistics. However, the information recorded in the field of the performance statistics 1202 is not limited to the average value, and statistical information suited to the purpose, such as a maximum value or a minimum value, can be used.

The evaluation value 1203 is an evaluation value for each evaluation index related to the measure described in the measure ID 1201. However, the evaluation value 1203 in the third embodiment is set based on the performance value described in the performance statistics 1202. In the example of FIG. 12A, the best performance statistics is the highest evaluation value (10 points), and the worst performance statistics is the lowest evaluation value (1 point), and the performance statistics are normalized in the range of "1 to 10 points" for each evaluation index and converted into an evaluation value. The evaluation values described in FIG. 12A show an example of linear normalization (conversion) as shown by the solid line in FIG. 12B, but if you want to give a large inclination to the evaluation value for a performance value that exceeds a certain threshold, you may use a conversion function as shown by the dashed line in FIG. 12B. Also, in the example of FIG. 12A, the best and worst performance statistics are calculated for each evaluation index and converted into an evaluation value, but if you have the same type of evaluation axis (cost, etc.), such as "evaluation index 1 (human cost)" and "evaluation index 2 (physical cost)", you may combine multiple evaluation indexes to set the best and worst performance statistics. For example, in the example of FIG. 12A, if the best and worst performance statistical values are calculated using only evaluation index 1, the best will be 967 yen and the worst will be 37,000 yen, but when evaluation index 2 is combined, the best will be 0 yen and the worst will be 37,000 yen, and the performance values of evaluation index 1 and evaluation index 2 may be converted to each evaluation value in the range of "0 yen to 37,000 yen." In this way, the conversion function from the performance statistical value to the evaluation value may be set arbitrarily.

The countermeasure selection process when a fault occurs in the third embodiment will be described with reference to Fig. 13. The third embodiment includes a procedure of selecting countermeasure candidates for the fault that has occurred, outputting the countermeasure candidates with attached priority information, recording the actual performance value that has occurred after the countermeasure is implemented, and recalculating and updating the evaluation value based on the performance value information. Fig. 13 is a flowchart of the countermeasure selection process, and the details will be described below. However, since steps S701 to S706 in Fig. 13 are the same as those in the first or second embodiment in Fig. 7, their description will be omitted, and the process of steps S1307 and S1308 after the output of the countermeasure candidates is completed will be described.

In step S1307, after the worker or the like has implemented the countermeasure, the recovery results and the actual values for each evaluation index are registered together with the information on the countermeasure taken in the countermeasure performance management table 131b in FIG. 11 managed by the countermeasure evaluation value management unit 131. The registration in step S1307 may be performed manually by the worker, or, for example, the management device 120 may actually measure the communication interruption time that occurred when the countermeasure was implemented and automatically register the actual measured value in the countermeasure performance management table 131b. When the processing in step S1307 ends, the process proceeds to step S1308.

In step S1308, the performance values and evaluation values written in the evaluation value management table 131a (FIG. 12) of the countermeasure evaluation value management unit 131 are recalculated and updated. Specifically, the countermeasure performance management table 131b updated in step S1307 is referenced, the field of performance statistics 1202 in the evaluation value management table 131a in FIG. 12 is updated, and the evaluation value for each evaluation index of evaluation value 1203 is recalculated and updated based on the new performance statistics. When the processing of step S1308 is completed, the countermeasure selection processing of FIG. 13 is terminated.

The countermeasure selection process in FIG. 13 allows the evaluation value to be set based on the performance value at the time the countermeasure was implemented, making it possible to select a countermeasure that better reflects the characteristics of the actual environment. In particular, if the performance value changes, for example, the time required for the countermeasure to be implemented gradually shortens due to environmental changes or the worker's improvement in the countermeasure implementation proficiency, the evaluation value can be set each time based on the performance value as in steps S1307 to S1308 in FIG. 13, thereby setting an evaluation value that tracks the fluctuations in the performance value. Note that in the example in FIG. 13, the performance value is registered and the evaluation value is updated in steps S1307 to S1308 every time a countermeasure is implemented, but the performance value may be registered and the evaluation value updated periodically, for example, once a week, at a timing that is not linked to the timing of the countermeasure implementation.

As described above, the countermeasure selection process according to this embodiment sets evaluation values that reflect performance values, making it possible to select countermeasures that are more in line with actual characteristics. As described above, even if the performance values for each countermeasure fluctuate over time due to environmental changes, etc., the evaluation values are updated to track these fluctuations, making it possible to select countermeasures that always reflect the characteristics of the actual environment.

Example 4
In the first to third embodiments, the countermeasure priority determination unit 133 unconditionally determines countermeasure candidates with high total evaluation values as high priority. However, as examples of recovery requirements, constraints such as "countermeasures whose total of human cost and physical cost exceeds 50,000 yen are excluded from candidates" or "countermeasures that involve communication interruption for one hour or more are excluded from candidates" may be set. Therefore, in the fourth embodiment, it is possible to set constraints that countermeasure candidates should satisfy for each recovery requirement.

In the fourth embodiment, FIG. 14 is a diagram showing a recovery requirement weight management table 132a managed by the recovery requirement management unit 132 of the management device 102, and FIG. 15 is a flowchart of a countermeasure selection process when a failure occurs. Note that the various configurations and processes related to the fourth embodiment are the same as those of the first to third embodiments except for the configurations and processes shown in FIG. 14 and FIG. 15, and therefore the description thereof will be omitted.

Figure 14 shows an example of the configuration of the recovery requirement weight management table 132a in the fourth embodiment. In this embodiment, as in the first to third embodiments, the recovery requirement weight management table 132a manages the weight for each recovery requirement, and in order to further manage the constraint conditions that the candidate measures must satisfy, new fields are provided for the countermeasure feasibility determination index 1402 and the minimum evaluation value condition 1403. Countermeasures that satisfy the conditions described in the field group for the applied recovery requirement become the candidate measures, and even if the total evaluation value is excellent, if the condition is not met, the countermeasure is excluded from the candidate measures. The fields for the recovery requirement ID 501 and the weight value 502 are the same as the fields in the recovery requirement weight management table 132a in the first embodiment in Figure 5, and their explanations are omitted. The newly provided countermeasure feasibility determination index 1402 and minimum evaluation value condition 1403 will be explained below.

The countermeasure feasibility determination index 1402 is an evaluation index that serves as a criterion for determining whether a countermeasure candidate is suitable for the recovery requirement described in the recovery requirement ID 501. In the example of FIG. 14, it is described in a format such as "index 1", but the format is arbitrary as long as it indicates the type of evaluation index related to the recovery requirement. In addition, when determining whether a countermeasure candidate is suitable based on a combination of multiple evaluation indexes, such as the above-mentioned "total value of human cost and physical cost", it is possible to define a combination of evaluation indexes such as "index 1 + index 2" as shown in the example of FIG. 14.

The minimum evaluation value condition 1403 is an evaluation value that must be satisfied for one or more evaluation indexes described in the countermeasure feasibility judgment index 1402 to be considered as a countermeasure candidate. For example, in the example of FIG. 14, the recovery requirement of "Policy001 (cost priority)" indicates that if the combined evaluation value of evaluation index 1 (personnel cost) and evaluation index 2 (physical cost) is not 13 or more, the measure is excluded from the countermeasure candidate. Note that in the example of FIG. 14, the minimum evaluation value condition 1403 defines the threshold value for the feasibility of the countermeasure candidate as an evaluation value, but in cases where the actual value can be calculated backward from the evaluation value as in Example 3, a value for a specific evaluation index (such as money or time) may be defined. By managing the recovery requirement weight value management table 132a as shown in FIG. 14, any constraint condition that each measure must satisfy can be set for each recovery requirement.

The countermeasure selection process when a failure occurs in the fourth embodiment will be described with reference to FIG. 15. In the fourth embodiment, after countermeasure candidates for the occurred failure are selected, when the countermeasure priority determination unit 133 calculates the total evaluation value for each countermeasure candidate, the recovery requirement weight management table 132a in FIG. 14 is referenced, and countermeasures that do not satisfy the constraint conditions set in the applied recovery requirements are excluded from the candidates. FIG. 15 is a flowchart of the countermeasure selection process in the fourth embodiment, and details are described below. However, since steps S701 to S704 and step S706 in FIG. 15 are the same as steps S701 to S704 and step S706 in the first and second embodiments in FIG. 7, their explanations will be omitted, and the process of excluding countermeasures that do not satisfy the constraint conditions in the newly added step S1505 will be described.

In step S1505, the total evaluation value according to the recovery requirement is calculated for each candidate countermeasure, which is the same as step S705 in FIG. 7. However, at this time, the countermeasure priority determination unit 133 refers to the recovery requirement weight management table 132a in FIG. 14 managed by the recovery requirement management unit 132, and excludes from the candidates countermeasures that do not satisfy the constraint conditions set in the recovery requirement to be applied. For example, if the occurring fault is "Fault001 (occurrence of radio interference)" in FIG. 3, and "Counter001 to Counter003" are selected as countermeasure candidates for this, and the recovery requirement to be applied is "Policy001 (cost priority)" in FIG. 14, countermeasures with a combined evaluation value of evaluation index 1 (personnel cost) and evaluation index 2 (physical cost) of less than 13 are excluded from the candidates. That is, in this example, in the evaluation value management table 131a in FIG. 4, the measure "Counter003 (antenna replacement)" is excluded from the candidate measures because the combined evaluation value of evaluation index 1 and evaluation index 2 is 6, and the two candidate measures "Counter001" and "Counter002" are selected. When the processing of step S1505 ends, the process proceeds to step S1506, where the measure priorities are calculated for the remaining candidate measures after excluding measures that do not satisfy the constraint conditions, and output processing is executed.

The countermeasure selection process in FIG. 15 can automatically output countermeasure candidates that satisfy the constraint conditions set for each recovery requirement. Note that, for the sake of simplicity, the countermeasure selection process in FIG. 7 in Examples 1 and 2 has been described as a process for excluding countermeasures that do not satisfy the constraint conditions, but this process may be applied to Example 3 by replacing step S1305 in FIG. 13 with step S1505 in FIG. 15.

As described above, by setting the constraint conditions according to this embodiment, measures that satisfy any constraint conditions set for each recovery requirement can be selected and output. In particular, in cases where a communication interruption of a certain period of time or more would cause severe damage to the system, by setting the constraint conditions appropriately, it is possible to extract and select only safe measures for the operation of the system.

Example 5
In the first to fourth embodiments, the management device 102 determines a countermeasure for a failure that occurs in the device 101, but the device 101 may determine the countermeasure by itself. The advantage of executing the countermeasure selection process in the management device 102 is that the processing load on the device 101 is reduced, but on the other hand, by having the device 101 determine the countermeasure by itself, the countermeasure can be determined in a shorter time than if the management device 102 determines the countermeasure. Therefore, in the fifth embodiment, a description will be given of a form in which the device 101 determines a countermeasure for a failure that occurs in the device itself.

In the fifth embodiment, FIG. 16 shows the hardware configuration of the device 101, and FIG. 17 is a flowchart of the countermeasure selection process by the device 101. Note that the various configurations and processes of the fifth embodiment are the same as those of the first to fourth embodiments except for those shown in FIG. 16 and FIG. 17, and therefore the description thereof will be omitted.

The hardware configuration of the device 101 in the fifth embodiment will be described with reference to FIG. 16. The communication I/F 1601, CPU 1602, storage device 1605, application program 1606, and communication processing unit 1607 in FIG. 16 are the same as the communication I/F 111, CPU 112, storage device 113, application program 114, and communication processing unit 115 in FIG. 1 mounted on the device 101 in the first embodiment, respectively, except for the content of the processing executed by the CPU 1602, and therefore description thereof will be omitted. Note that if the management device 102 does not exist and there is no need to transmit data acquired by the device 101 or operation information of the device itself, the communication I/F 1601 may not be mounted.

In the fifth embodiment, the device 101 detects a failure of its own device and executes processes from selecting countermeasure candidates to determining priorities and outputting. Therefore, the device 101 of the fifth embodiment has an input unit 1603, an output unit 1604, a fault detection unit 1609, a countermeasure candidate selection unit 1610, a countermeasure evaluation value management unit 1611, a recovery requirement management unit 1612, and a countermeasure priority determination unit 1613, which are the same as the input unit 123, the output unit 124, the fault detection unit 129, the countermeasure candidate selection unit 130, the countermeasure evaluation value management unit 131, the recovery requirement management unit 132, and the countermeasure priority determination unit 133 of FIG. 1 that are installed in the management device 102 of the first embodiment. The device information management unit 128 of FIG. 1 installed in the management device 102 of the first embodiment is not installed in the device 101 of the fifth embodiment because it manages a system to which other devices belong. Furthermore, the failure detection unit 1609 of the device 101 differs from the failure detection unit 129 of the management device 102 in that it does not detect failures of other devices, but detects failures that occur in the device itself by any method based on alert information generated by the device itself. The recovery requirement application management table 132b (FIG. 6 or FIG. 10) managed by the recovery requirement management unit 1612 of the device 101 may be in a form that manages only the recovery requirements that are applied to the device itself. Note that, in the case of receiving input information from an external device or providing output information to an external device via the communication I/F 1601, such as a form of remotely logging in to the device 101 from another external device, the input unit 1603 and the output unit 1604 do not need to be installed in the device 101.

The countermeasure selection process by the device 101 when a failure occurs will be described with reference to FIG. 17. FIG. 17 is a flowchart of the countermeasure selection process of the fifth embodiment. The countermeasure selection process of the fifth embodiment is the same as the countermeasure selection process of FIG. 1, except that in step S1701, a failure in the device itself is detected, rather than a failure in another device.

In step S1701, the fault detection unit 1608 of the device 101 detects the occurrence of a fault in the device itself. If a fault is detected (YES), the process proceeds to step S1702. If no fault is detected (NO), the process of step S1701 is executed again after an arbitrary time has elapsed.

In step S1702, the countermeasure candidate selection unit 1610 refers to the countermeasure candidate management table 130a in FIG. 3 and selects countermeasure candidate for the failure detected in step S1701. When the processing in step S1702 ends, the process proceeds to step S1703.

In step S1703, the recovery requirement management unit 1612 refers to the recovery requirement application management table 132b in FIG. 6 or FIG. 10, and acquires the recovery requirements to be applied to the own device. When the processing of step S1703 ends, the process proceeds to step S1704.

In step S1704, the recovery requirement management unit 1612 refers to the recovery requirement weight management table 132a in FIG. 5 or FIG. 14, and obtains weights for each evaluation index in the applied recovery requirement obtained in step S1703. When the processing in step S1704 ends, the process proceeds to step S1705.

In step S1705, the countermeasure priority determination unit 1613 refers to the evaluation value management table 131a in FIG. 4 or FIG. 12A managed by the countermeasure evaluation value management unit 1611, obtains the evaluation value for each countermeasure candidate selected in step S1702, and calculates a total evaluation value reflecting the weighted value obtained in step S1704. When the processing in step S1705 ends, the process proceeds to step S1706.

In step S1706, the countermeasure priority determination unit 1613 determines the countermeasure priority as the total evaluation value, and determines the priority order of each countermeasure candidate in descending order of this value. After determining the priority order, the countermeasure candidate selected in step S1702 is output from the output unit 1604 together with the determined priority order or countermeasure priority (total evaluation value). When this process ends, the flowchart for the countermeasure selection process in FIG. 17 ends.

The countermeasure selection process in FIG. 17 allows the device 101 to automatically select and output countermeasure candidates together with priority information for a failure that occurs in the device itself. Note that, for the sake of simplicity, the countermeasure selection process by the device 101 has been described based on the countermeasure selection process in FIG. 7 in Examples 1 and 2. However, step S701 in FIG. 13 or step S701 in FIG. 15 may be replaced with step S1701 in FIG. 17, and the process in Examples 3 and 4 may be applied to the countermeasure selection process of the device 101.

As described above, this embodiment allows the device 101 to determine countermeasures for a failure that occurs within the device itself, without the need for the management device 102. For example, since the device 101 can detect a failure within itself earlier than the management device 102 can detect the failure, as described above, countermeasures can be determined in a shorter time from the occurrence of a failure than if the management device 102 were to determine the countermeasures.

The present invention is not limited to the above-described embodiments, but includes various modified examples and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to having all of the configurations described. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added, deleted, or replaced with other configurations.

Furthermore, each of the configurations, functions, processing units, processing means, etc. described above may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, hard disk, or SSD (Solid State Drive), or in a recording medium such as an IC card, SD card, or DVD.

In addition, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily represent all control lines and information lines necessary for implementation. In reality, it is safe to assume that almost all components are interconnected.

101: device, 102: management device, 111: communication I/F, 112: CPU, 113: storage device, 114: application program, 115: communication processing unit, 121: communication I/F, 122: CPU, 123: input unit, 124: output unit, 125: storage device, 126: application program, 127: communication processing unit, 128: device information management unit, 129: fault detection unit, 130: countermeasure candidate selection unit, 131: countermeasure evaluation value management unit, 132: recovery requirement management unit, 133: countermeasure priority determination unit

Claims (8)

A countermeasure selection device that determines a recovery countermeasure for a failure that occurs in its own device or another device,
The computer includes a processor that executes a program and a memory device that stores the program and data.
Countermeasure candidate management information for managing a list of recovery measure candidates for the contents of the failure;
a countermeasure candidate selection unit that refers to the countermeasure candidate management information and selects a recovery countermeasure candidate for the failure that has occurred;
a countermeasure evaluation value management unit that manages evaluation values for each countermeasure with respect to one or more evaluation indexes that are important matters in a recovery countermeasure;
a recovery requirement management unit that manages recovery requirements including weighted values indicating the priority of each of the evaluation indexes and devices to which the recovery requirements are applied;
a countermeasure priority determination unit that determines priorities of the candidate recovery measures based on one or more of the evaluation indexes;
an input unit that receives an input of an evaluation value for each of the measures and the evaluation index, a weighted value for each of the restoration requirements and the evaluation index, and an apparatus to which the restoration requirements are applied;
an output unit that outputs the recovery measure candidates with the determined priorities;
The input unit includes:
an area in which an evaluation value to be managed by the measure evaluation value management unit can be selected for each measure and evaluation index;
an area in which a weighting value managed by the restoration requirement management unit can be set for each restoration requirement and evaluation index;
a region in which a recovery requirement managed by the recovery requirement management unit can be set for each of the own device or the other device;
the countermeasure priority determination unit calculates, for each candidate recovery measure selected by the candidate recovery measure selection unit, a total value of the evaluation values reflecting the weighted values in the recovery requirements applied to the device to be restored, and determines the priority of the candidate recovery measure so that the higher the calculated total value, the higher the priority of the candidate recovery measure. The countermeasure selection device according to claim 1,
The countermeasure selection device according to claim 1, wherein the evaluation index includes an index prioritizing the cost required for failure recovery or an index prioritizing time. The countermeasure selection device according to claim 1,
The countermeasure selection device, wherein the restoration requirement management unit manages restoration requirements that are switched in response to predetermined conditions and applied to the device. The countermeasure selection device according to claim 3,
The countermeasure selection device, wherein the predetermined condition includes a time condition or an operating state condition of the device. The countermeasure selection device according to claim 1,
The measure evaluation value management unit
Record the recovery results and the performance values of the evaluation indicators when the measures are implemented,
Calculating an average value of the performance values for each of the measures and each of the evaluation indexes;
a countermeasure selection device which calculates and registers an evaluation value for each countermeasure based on the average value. The countermeasure selection device according to claim 1,
the restoration requirement management unit manages a lower limit evaluation value that the evaluation index should satisfy for each of the restoration requirements;
The countermeasure selection device, wherein the countermeasure priority determination unit excludes, from candidates, countermeasures whose evaluation index does not satisfy the lower limit evaluation value. A device constituting the system;
A system including a management device that determines a recovery measure for a failure that occurs in the device,
The management device includes:
The computer includes a processor that executes a program and a memory device that stores the program and data.
Countermeasure candidate management information for managing a list of recovery measure candidates for the contents of the failure;
a countermeasure candidate selection unit that refers to the countermeasure candidate management information and selects a recovery countermeasure candidate for the failure that has occurred;
a countermeasure evaluation value management unit that manages evaluation values for each countermeasure with respect to one or more evaluation indexes that are important matters in a recovery countermeasure;
a recovery requirement management unit that manages recovery requirements including weighted values indicating the priority of each of the evaluation indexes and devices to which the recovery requirements are applied;
a countermeasure priority determination unit that determines priorities of the candidate recovery measures based on one or more of the evaluation indexes;
an input unit that receives an input of an evaluation value for each of the measures and the evaluation index, a weighted value for each of the restoration requirements and the evaluation index, and an apparatus to which the restoration requirements are applied;
an output unit that outputs the recovery measure candidates with the determined priorities assigned thereto;
The input unit includes:
an area in which an evaluation value to be managed by the measure evaluation value management unit can be selected for each measure and evaluation index;
an area in which a weighting value managed by the restoration requirement management unit can be set for each restoration requirement and evaluation index;
a region in which a recovery requirement managed by the recovery requirement management unit can be set for each of the devices;
The system is characterized in that the countermeasure priority determination unit calculates a total value of the evaluation values reflecting the weighted values in the recovery requirements applied to the device to be restored, for each candidate recovery measure selected by the candidate countermeasure selection unit, and determines a priority such that the higher the calculated total value, the higher the priority of the candidate recovery measure. A countermeasure selection method in which a countermeasure selection device determines a recovery countermeasure for a failure occurring in a device itself or another device, comprising:
The countermeasure selection device includes a calculation device for executing a program and a storage device for storing the program and data,
the storage device stores countermeasure candidate management information for managing a list of recovery countermeasure candidates for a failure content;
The countermeasure selection method includes:
an input step in which the computing device receives input of an evaluation value for each measure and each evaluation index, a weighted value for each restoration requirement and each evaluation index, and a device to which the restoration requirement is applied;
a countermeasure candidate selection step in which the computing device refers to the countermeasure candidate management information and selects a recovery countermeasure candidate for the failure that has occurred;
a countermeasure evaluation value management step in which the computing device manages the evaluation value for each countermeasure with respect to one or more evaluation indexes that are important matters in a recovery countermeasure;
a recovery requirement management procedure in which the computing device manages the recovery requirements including weighted values indicating priorities of the evaluation indexes and devices to which the recovery requirements are applied;
a countermeasure priority determination step in which the computing device determines priorities of the recovery countermeasure candidates based on one or more evaluation indexes;
an output step in which the computing device outputs the recovery measure candidates with the determined priorities assigned thereto;
In the input step, the arithmetic device selects an evaluation value managed by the countermeasure evaluation value management step for each countermeasure and evaluation index, sets a weight value managed by the recovery requirement management step for each recovery requirement and evaluation index, and sets a recovery requirement managed by the recovery requirement management step for each of the own device or the other device;
The countermeasure selection method is characterized in that, in the countermeasure priority determination procedure, the computing device calculates, for each recovery measure candidate selected in the countermeasure candidate selection procedure, a total value of the evaluation values reflecting the weighted values in the recovery requirements applied to the device to be restored, and determines the priority of the recovery measure candidate so that the higher the calculated total value, the higher the priority of the recovery measure candidate.

Images