JP4358034B2 - Monitoring system - Google Patents

Description

  The present invention provides a device control request to an external device and updates the monitoring system table related to the device control request, and when the processing ends abnormally in the system or the external device, the external device table The present invention relates to a recovery system that performs recovery for ensuring consistency of data in a monitoring system table.

  In the field of communication and the like, a network operation system is provided to manage a network constituted by transmission devices such as NE (Network Element) and transmission paths connecting the transmission devices. The network operation system performs device control such as path setting for path setting, path change, path release, route band limiting, etc., and band control cancellation for setting communication paths (hereinafter referred to as paths) through a plurality of NEs. Execute.

  The network operation system manages, for example, information related to path setting in a table for path setting, makes a path setting request to a plurality of NEs located on the path, and stores a table for information related to path setting. Update. On the other hand, each NE that has received a path setting request updates a table related to path setting.

  In this way, the network operation system makes a plurality of device control requests to a plurality of NEs and updates the table of its own system related to the device control request. The plurality of NEs update their own table based on the device control request.

  However, there is a case where the processing at the NE regarding the device control request to the NE ends abnormally due to the NE device failure, transmission line failure, or the like. At this time, when a plurality of device control requests to a plurality of NEs are normally terminated in the network operation system or some NEs and abnormally terminated in other NEs, the contents of the network operation system table and the NE table are changed. Consistency is lost.

  For example, for a path setting request, a network operation system or NE that has ended normally means that the table has been set for a path, and an NE that has ended abnormally means that the table has not been set for a path. The consistency of the table contents of NEs that have ended normally and NEs that ended abnormally cannot be obtained. Therefore, it is necessary to perform recovery to ensure consistency between the contents of the network operation system table and the NE table.

  Hereinafter, a system that makes a device control request to a plurality of NEs, such as a network operation system, and updates the table of its own system is called a monitoring system. An external device that performs updating is referred to as a device for short. In addition, another network operation system when the network operation system makes a device control request to another NE via another network operation system is referred to as another system.

  As a conventional recovery method, a device that has made a device control request by the monitoring system is initialized to the initial state, and then a plurality of external devices are made by making a device control request based on the contents of the monitoring system table. There was a way to restore the device table.

  There exists the following patent document 1 as a prior art document.

In Patent Document 1, a monitoring system stores update information indicating update contents of a database in an update history file, and a history management map for managing whether or not update information is recorded in the update history file is provided for the update history file and the database. In the event of a failure recovery, the update information that is different from each other is extracted and updated, so that the update information lost during the memory expansion due to a system down failure during the database update operation can be recovered quickly. It is disclosed.
JP-A-9-204335

  However, the conventional recovery method has the following problems.

  The conventional recovery method has a problem that it takes time to initialize the apparatus state to the state immediately before or after execution, and it takes time to recover. In addition, when multiple devices related to the process cannot be returned to the initialization state due to a failure or the like, the recovery process cannot be completed, so the system cannot perform a process other than the recovery process and the system stops. was there.

  Conventionally, the contents of the table immediately before the failure occurred can be managed. However, in the process, that is, when a plurality of device control requests are made to each device, it is possible to manage which device control request has been processed. Therefore, recovery processing based on the processed state, for example, the external device cannot be recovered from the state before processing / the state after processing to the subsequent processing.

  For example, when the path setting device control request needs to make two device control requests, endpoint generation and cross-connect generation, the procedure for recovery processing will occur if the endpoint generation ends abnormally and the cross-connect generation ends abnormally. Therefore, since it is not possible to manage which device control request causes abnormal termination, it is not possible to recover from the state before processing / the state after processing. In the following description, not only returning to the state before the process execution but also proceeding to the state after the process execution is called a recovery process.

  Moreover, although patent document 1 can recover | restore the database of a monitoring system, there existed a problem that the database of an apparatus could not be recovered.

  The object of the present invention has been made in view of the above, and by performing a recovery process based on a processed state without performing an initialization process for an external apparatus, it is possible to quickly recover, and an apparatus failure It is to provide a monitoring system in which the system does not stop even when the recovery process cannot be performed due to the occurrence of the problem.

  According to one aspect of the present invention, the device control request is made to a plurality of external devices that update the first information table that stores device information based on the device control request, and processing related to the device control request is executed. A device control processing unit that updates a second information table for storing information, and when the device control request is made to the external device, a request content related to the device control request and an external device that is the device control request target A management information processing unit that stores management information to be specified in a third information table, and information before processing execution before the device control request stored in the second table related to the device control request is stored in the fourth information table. A pre-processing information storage unit stored in the information table, and management related to the device control request stored in the third information table when the processing for the device control request ends abnormally A recovery control unit that controls the external device to execute a device control request for setting the device state before or after the execution of the processing based on the request content specified by the information. A characteristic monitoring system is provided.

  According to the first aspect of the present invention, the pre-process execution information, the processing content, and the information for specifying the external device to be controlled stored in the second information table are stored in the third information table. It is possible to recover from the state before the device control request without initial setting and recovery, and quick recovery becomes possible.

  Before describing the embodiment of the present invention, the principle of the present invention will be described. FIG. 1 shows the principle of the present invention. As shown in FIG. 1, the monitoring system 10 includes second, third, and fourth information tables 12, 16, and 20, an apparatus control processing unit 14, a management information processing unit 16, a pre-processing information storage unit 22, and a recovery. A control unit 24 is provided. The plurality of external devices 4 # i (i = 1 to n) include a first information table 2 # i (i = 1 to n).

  The device control processing unit 14 makes a second information table 12 that makes a device control request to a plurality of external devices 4 # i (i = 1,...) And stores processing execution information related to the device control request. Update. The external device 4 # i (i = 1,...) Updates the first information table 2 # i that stores device information based on the device control request.

  When the management information processing unit 18 makes a device control request to the external device 4 # i (i = 1,...), The request content related to the device control request and the external device 4 # i ( Management information specifying i = 1,... is stored in the third information table 16. The pre-process execution information storage unit 22 stores in the fourth information table 20 the pre-process execution information stored in the second table 12 related to the apparatus control request and before performing the apparatus control request.

  When the process for the device control request is abnormally terminated, the recovery control unit 24 performs the process before the process execution based on the request content specified by the management information related to the device control request stored in the third information table 16 or Control is performed so that an external device 4 # i (i = 1,...) Issues a device control request for setting the device state after execution of processing. As a result, the external device 4 # i (i = 1,...) Is not initially set and recovered, but can be recovered from the state before the device control request, thereby enabling quick recovery.

  FIG. 2 is an overall configuration diagram including a monitoring system according to an embodiment of the present invention. The monitoring system is applied to a system that performs a plurality of processes that operate in synchronization through a plurality of devices and other monitoring systems. Here, in this embodiment, a case of a network operation system that monitors a network system constituted by a plurality of NEs and a plurality of transmission paths will be described as an example. As shown in FIG. 2, a plurality of monitoring systems 50, 100, a plurality of external devices 52 #A to 52 #D monitored by the monitoring system 50, and a transmission network 54, a relay system or a relay network 60 including transmission paths. And the network system is comprised from the transmission network 104 comprised by several 102 # A-102 # D and the transmission line monitored by the other monitoring system 100. FIG.

  A monitoring system (abbreviated as system) 50 is a system according to the present invention. The other monitoring system (abbreviated as another system) 100 is a system according to the present invention or a conventional system, and the system 50 makes a device control request to the devices 102 #A to 102 #D via the other system 100. . Devices 52 # A-52 # D and 102 # A-102 # D are NEs. The relay system or relay network 60 is a network that connects between the transmission networks 54 and 104.

  FIG. 3 is a block diagram of the system 50 in FIG. The system 50 includes an input / output unit 150, an operation processing unit 152, a plurality of processing units 154 # A and 154 # B, a recovery control input / output unit 156, a recovery control unit 158, an execution information table 160, a management ID table 162, and process management. An information table 164, a business name management information table 165, a pre-processing execution information table 166, a recovery scenario file 168, and an environment information table 170 are provided. The input / output unit 150 and the recovery control input / output unit 156 are realized by a program or a peripheral device operating on a computer such as a personal computer. The operation processing unit 152, the processing units 154 # A and 154 # B, and the recovery control unit 158 are realized by a program that operates on a computer. When this program runs on a computer, it is called a process. The tables 160, 162, 164, 166 are stored in a peripheral device such as a main memory or a magnetic disk. The recovery scenario file 168 is stored in a peripheral device such as a magnetic disk.

  The input / output unit 150 makes a control request for bandwidth limitation execution, bandwidth limitation release, path setting, path release, and statistical information output to the operation processing unit 152, and displays the control request result from the operation processing unit 152. When receiving a control request from the input / output unit 150, the operation processing unit 152 is a process that performs the following processing.

  (I) When executing a process related to a control request, when the own process updates the process execution information table 160, the management ID table 162 is referenced to generate a unique management ID for specifying the process. To do. The process management information table 164 is searched from the management ID, process number, and business name ID, and a unique process management number is generated. Management ID, process number, business name ID, process management number, execution result = execution in progress, recovery execution availability = initial state, and written in the process management information table 164. The process number is a number for specifying the process, and is, for example, a number given serially in the execution order of the process that executes the control request. The business name ID is a number for specifying the content of the control request. Examples of the business name include bandwidth control execution, bandwidth control release, device status monitoring, emergency, path setting, path release, etc. A business name ID is assigned in advance corresponding to the business name, and the relationship between the business name and the business name ID is stored in the business name table 165.

  (Ii) Before updating the process execution information table 160, the process execution information related to the update is acquired from the process execution information table 160. The management number ID, process management number, device control state, and pre-process execution information are written to the pre-process execution information table 162, and the process execution information table 160 related to device control is updated as necessary.

  (Iii) For a control request instructed by the input / output unit 150, another process that performs processing related to the request, for example, a process such as the processing unit 154 # A, is started. Note that the apparatus control performed by the other process may be performed by the own process 152 without starting the other process 154 # A.

  (Iv) When the execution result of the called process 154 # A is a normal end, if another process needs to be called, another process, for example, the processing unit 154 # B is activated.

  (V) When the execution result of the process 154 # B is normal termination and the processing related to the control request instructed from the input / output unit 150 is normally terminated, the own process 152 and the other processes 154 # A and 154 # B The generated pre-process execution information, process management information, and management ID are deleted from the pre-process execution information table 166, the process management information table 164, and the management ID table 162, respectively.

  When the processing units 154 # A and 154 # B are activated by the operation processing unit 152, the processing units 154 # A and 154 # B generate processing management information and write it in the processing management number table 164 in the same manner as the operation processing unit 152. The previous information is written in the pre-process execution information table 164. ii) A device control request is made to the devices 52 # A, 52 # B, the other system 100, etc., such as bandwidth limitation execution, bandwidth limitation cancellation, path setting, and the like. (Iii) When normal termination is notified from the devices 52 # A, 52 # B and the other systems 100, the processing execution information table 164 related to the device control request is updated and the execution result of the pre-processing information is set to executed. . The process execution information table 160 may be updated together with a device control request. (Iv) The processing result (normal end / abnormal end) is notified to the operation processing unit 152 of the parent process.

  The process execution information table 160 is a table for storing process execution information such as bandwidth limitation execution information and path setting information after execution of a process in response to a device control request to the devices 52 # A to 52 # D and 102 # A to 102 # D. It is. The management ID table 162 is a table that stores the management ID being executed.

  FIG. 4 shows the process management information table 164. As shown in FIG. 4, the process management information table 164 includes columns of a management ID, a process management number, a process number, a business name ID, an execution result, and whether recovery can be performed. The management ID, process management number, process number, and business name ID are as described above. As for the execution result, abnormal termination (-1), initial state (0), executing (1), executed (2) are updated according to the processing state. Whether or not recovery can be performed is information indicating whether or not recovery can be performed for the abnormal termination process and a series of other processes synchronized with the process when the process ends abnormally. Implementation possible (1) is set. The business name management information table 165 is a table that stores information indicating the relationship between the business name ID and the business name.

  FIG. 5 is a diagram showing the pre-process execution information table 166. As shown in FIG. 5, the pre-process execution information table 166 includes a management ID, a process management number, its own system state, device control state information, and another system control state. The management ID and the process management number are as described above. The own system status indicates the update target of the table related to the process. When the process updates only the process execution information of the own system (0), when the device control related to the own system is performed (1), State number information indicating whether the relevant device control only (2) or the device control related to the own system or the device control related to another system (3) is applicable is stored.

  The device control status is provided for each of the devices 52 # A to 52 # D monitored by the own system 50, and indicates information related to device control. The control status, device number, request type, route number, number of packets In addition, processing execution information such as path setting (not shown) and a control sequence number are stored. The control state indicates a process execution state such as unexecuted (0), executing (1), or already executed (2). The device number indicates a unique device number in the system 50. The request type indicates the contents of a device control request such as initialization, bandwidth control execution, bandwidth control release, and the like. The control sequence number indicates a control sequence number in units of request types such as initialization, block setting, block release, bandwidth limitation execution, bandwidth control release, end point generation for path setting, and cross connect generation.

  The other system control state is provided for each of the devices 102 # A to 102 # D monitored by the other system 100, and indicates information related to device control. The control state, system number, device number, request type, and route Stores processing execution information such as a number, the number of packets, and path setting (not shown). The control state is the same as described above. The device number indicates a unique device number in the other system 100. The request type is the same as described above. Here, since the control request via the other system 100 is a request type unit and not a control sequence unit, the control sequence number is not stored. When there are a plurality of other systems 100, other system numbers for specifying other systems are set. FIG. 15 shows an example of the state 14 described later.

  FIG. 6 is a diagram illustrating an example of a recovery scenario. The recovery scenario consists of an overall recovery scenario that indicates the recovery procedure for controlling the control procedure of the individual recovery scenario described later when the process is abnormal, and the process indicated by the business name ID, process management number, and control sequence number. It consists of an individual recovery scenario showing the recovery procedure. The recovery scenario includes a pre-process execution scenario for restoring to a pre-process execution state and a process execution scenario for updating to a post-process execution state.

  As shown in FIG. 6, for example, when bandwidth management execution (business name ID = 10005) is processing management number = 1, which is processing for updating the processing execution information table 160, an execution scenario before device control, that is, processing execution Based on the previous information table 166, when the processing management information is a process related to the bandwidth control execution of the device of the own system 50 when the processing execution information table 160 is restored to the state before the processing execution, the bandwidth control is performed. A device control execution scenario for making a request and a state after processing execution, or a device control pre-execution scenario for making the device and the table 160 a state before processing execution by making a bandwidth release request, or for performing bandwidth control of the device of the other system 100 When the related process management number = 3, the other system 100 and the table 160 are put into the pre-control execution state before the other system control. The recovery scenario file 168 stores a scenario for controlling the execution of the device and the table 160 of the other system in the control scenario, or a state scenario before executing the control of the device and the table 160 of the other system. Yes. The recovery scenario can be changed by replacing the recovery scenario file 168 without changing the recovery program. Although not shown, for device control including a plurality of subsequences, a recovery procedure is defined for each control sequence number corresponding to the subsequence.

  The environment information table 170 is a table for storing recovery conditions. The recovery conditions are conditions related to recovery, such as a recovery method, a retry upper limit, and a waiting time. The recovery method designates either automatic or manual recovery. A range for automatic / manual recovery is designated as necessary, such as whether the management process number and business name ID are automatic / manual or automatic / manual for the entire system. The retry upper limit specifies the upper limit of the number of retries when recovery fails, and the upper limit of the number of retries is specified like the management process number and business name ID unit or system unit. The waiting time designates a waiting time until the next retry, and the waiting time is designated like a management process number and a management ID unit or a system unit.

  The recovery control input / output unit 156 controls a man-machine interface for recovery control. Based on the recovery conditions stored in the environment information table 170, the recovery control unit 158 automatically performs (i) process management in accordance with a recovery instruction from the recovery control input / output unit 156 in the case of manual recovery and automatically in the case of automatic recovery. The recovery target is identified from the business name ID and processing management number stored in the information table 164 and the request type, control sequence number and device number stored in the pre-processing execution information table 166, and (ii) corresponds to the recovery target In accordance with the recovery procedure defined in the recovery scenario 168, the processing units 152, 154 # A, and 154 # B are activated, and the processing execution information table 160 is restored based on the contents of the pre-processing execution information table 166 (the own system Recovery), recovery to the state before device control / execution of device control, recovery before control of other systems, and execution of device control of other systems.

  Hereinafter, the operation of the system 50 of FIG. 2 will be described.

(A) Normal Processing FIGS. 7 to 10 are operation explanatory diagrams in the case of normal processing of the system 50. FIG. 7 shows the input / output unit 159, the operation processing unit 152 (process A), the device 52 # A, and the other system 100. It is a process sequence chart which shows the calling relationship of the apparatus 100 # A. FIG. 8 is a diagram showing the contents of the management ID table 162 and the process management number table 164 corresponding to the state numbers of FIG. FIG. 9 is a diagram showing the contents of the pre-processing information table 166 corresponding to the state number of FIG. FIG. 10 is a diagram showing processing execution information of the device 52 # A and the device 102 # A of the other system 100 corresponding to the state number of FIG.

  The input / output unit 150 requests the operation processing unit (process A) 152 to execute a control request, for example, bandwidth control (state 0). Process A receives a control request (state 1). As shown in FIG. 7 and FIG. 8, the process A searches the management ID table 162 from the business name ID corresponding to the business name related to the control request, for example, “1005”, and has a unique management ID (100 ) And the management ID and the business name ID are written in the management ID table 162 (state 2).

  The process A searches the processing management information table 164 on the basis of the management ID (100), the business name ID (10005), and the process ID (1001) to identify a unique processing management number (1), for example, “1”. As shown in FIG. 8, in the process management information table 164, a management ID (100), a process management number (1), a process number (1001), a business name ID (10005), and an execution result (execution) Medium (1)) is written into the process management information table 164 (state 3).

  As shown in FIG. 9, the process A acquires the management ID, the process management number, and the pre-process execution information related to the update of the own process A 152 from the process execution information table 160, and the management ID (100), the process management number (1) ), It is written in the pre-processing information table 166 together with its own system state (1) (state 4). The process A 152 updates the process execution information table 160.

  The process A activates the process A (process B) 52 # A, and passes the management ID (100) and the business name ID (10005) to the process B (state 5). The process B searches the processing management information table 164 based on the management ID (100), the business name ID (10005), and the process ID (1001), and generates a unique processing management number (2).

  As shown in FIG. 8, the process B includes a management ID (100), a processing management number (2), a process number (1002), a business name ID (10005), and an execution result (in execution ( 1)) is written into the process management information table 164 (state 6). The process B acquires the management ID, the process management number, and the pre-process execution information (route number = NULL, the number of packets = NULL) of the device 52 # A related to the update of the own process B from the process execution information table 160, and FIG. , Management ID (100), process management number (2), own system state (device control state = 2), control state (running = 1), device number of device 52 # A = 1, request type (Band control execution = 3) and the control sequence number (Band control execution = 3) are written in the pre-processing execution information table 166 (state 7). Thereafter, the process execution information table 160 is updated to the process execution information (route number = 18, number of packets = 2000) related to the device 50 # A. Note that when the band control execution sequence is divided into a plurality, the control sequence number is the corresponding sequence number.

  Process B makes a device control request for bandwidth control execution to device 52 # A. As shown in FIG. 9, the device 52 # A executes bandwidth control based on the bandwidth control execution request from the process B, and updates the table of the corresponding process execution information. For example, the route number 5 is updated to the number of restricted packets = 2000, and the restricted state = restricted packet present (1). When the processing ends normally, the device 52 # A returns a device control result (normal end) to the process B (state 8). When the process B returns a normal end response from the device 52 # A, the process B ends the execution result of the process management number information corresponding to the management ID (100) and the process management number (2) (state 9). . Process 2 in process B in state 5-9 ends normally. The process B returns to the process A a normal end (state 10).

  The process A activates the process A (process B) 52 # A, and passes the management ID (100) and the business name ID (10005) to the process B (state 11). State 11-13 is similar to state 5-7.

  The process B issues another system control request (bandwidth control execution) to the other system 100. As shown in FIG. 10, the other system 100 makes a bandwidth control request to the device 102 # A based on the bandwidth control execution request from the process B. The device 102 # A executes bandwidth control in accordance with the bandwidth control execution request, and updates the corresponding process execution information table. Based on the row request, bandwidth control is executed, and the corresponding processing execution information table is updated. For example, the route number is updated, the number of restricted packets = 2000, and the restricted state = restricted packet present (1).

  When the process ends normally, the apparatus 102 # A returns an apparatus control result (normal end) to the other system 100. When the normal end is returned from the device 102 # A, the other system 100 returns the other system control request result (normal end) to the process B (state 14). When the process B returns a normal end response from the other system 100, the process B ends the execution result of the process management number information corresponding to the management ID (100) and the process management number (3) (state 15). The process 3 in the state 11-15 in the process B ends normally. The process B returns to the process A a normal end (state 16).

  Process A returns the execution result of normal termination for process 2 and 3 from process B, so process pre-process information of management ID (100) and process management numbers (1), (2) and (3) is processed. Delete from the pre-execution information table 166 (state 17). The process A deletes the process management information of the management ID (100) and process management numbers (1), (2), and (3) from the process management information table 164 (state 18). Further, the process A deletes the management ID of the management ID (100) and the business name ID (10005) from the management ID table 162.

(B) Abnormal Processing FIGS. 11 to 14 are operation explanatory diagrams in the case of abnormal processing of the system 50. FIG. 11 shows the input / output unit 159, the operation processing unit 152 (process A), the device 52 # A, and the other system 100. It is a process sequence chart which shows the calling relationship of the apparatus 100 # A. FIG. 12 is a diagram showing the contents of the management ID table 162 and the process management number table 164 corresponding to the state numbers of FIG. FIG. 13 is a diagram showing the contents of the pre-processing information table 166 corresponding to the state number of FIG. FIG. 14 is a diagram showing processing execution information of the device 52 # A and the device 102 # A of the other system 100 corresponding to the state number of FIG.

  Here, the device 52 # A has normally terminated in response to the device control request to the device 52 # A by the process B, but the other system 100 or the device 102 # has responded to the other system control request to the other system 100 by the process B. An example of the abnormal end in A will be described.

  The input / output unit 150 issues a control instruction, for example, a bandwidth control request to the operation processing unit (process A) 152 (state 0). As shown in FIGS. 11 to 14, the state 1-13 is the same as the state 1-13 in FIGS. The process B issues another system control request (bandwidth control execution) to the other system 100. As shown in FIG. 11, it is assumed that the other system 100 issues a bandwidth control request to the device 102 # A based on the bandwidth control execution request from the process B, but terminates abnormally.

  The cause of the abnormal termination is an abnormality in the communication line connecting the other system 100 and the recovery system 50, a system abnormality in the other system 100, an apparatus abnormality in the device 102 # A, or a communication line connecting the other system 100 and the device 102 # A. It is abnormal. The process B knows that the other system control has ended abnormally because the other system 100 is not notified of an abnormality or does not respond within a certain time (state 14).

  In FIG. 10 where the other system control is normally completed, the process execution information of the other system is updated. However, in FIG. 14 where the other system control is abnormally ended, the process execution information of the other system is not updated. The process execution information for the device 102 # A has been updated in the process execution information table 160 to route number = 18 and the number of packets = 2000, but in the pre-process execution information table 166, the pre-process execution information (route number = NULL). , Number of packets = NULL).

  In process B, the execution result of the process management information of management ID (001), process ID (1003), and business name ID (10005) has been executed (2), and recovery execution possible column is set to recovery possible (-1) (State 15). Process B returns to process A that process 3 ended abnormally (state 16). Process A has a process ID (1001) process management information recovery execution propriety column in which the execution result is executing (1) in the process ID information of management ID (001) and business name ID (10005). Is set to recovery feasible (-1) (state 17).

(C) Change of Recovery Scenario FIG. 15 is a diagram showing a procedure for changing a recovery scenario. The restoration scenario can be replaced when the device control sequence is changed. The recovery control input / output unit 156 generates a replacement recovery scenario. The recovery scenario is created for each business content (business name ID) to be replaced, for example. The recovery control input / output unit (control client) 156 makes a replacement scenario replacement request to the replacement process of the recovery control unit 158.

  The replacement process notifies the control client that the request has been received. The control client transfers the recovery scenario to the replacement process and transfers the file. The replacement process instructs the operation processing unit 152 to block the business affected by the replacement corresponding to the business name ID related to the recovery scenario to be replaced. The business block process of the operation processing unit 152 blocks the business corresponding to the business name ID, that is, rejects the request even when there is a control request for the business name ID from the input / output unit 150, and terminates the replacement process normally. Notice. In the replacement process, the corresponding recovery scenario in the recovery scenario file 168 is replaced with a replacement scenario file.

  The replacement process instructs the business shutdown process to release the business shutdown corresponding to the business name ID. The business blocking process releases the business blocking corresponding to the business name ID and notifies the replacement process of normal termination. The replacement process returns a normal end response to the control client. As described above, since the recovery is performed based on the recovery scenario file 168, when the sequence of the devices 52 # A to 52 # D is changed, the program of the recovery control unit 158 is changed only by replacing the recovery scenario. Since there is no need, it is possible to easily cope with addition of functions.

(D) Recovery process (first embodiment)
In the first embodiment, for a plurality of processes, when the calling order of the processes and the end order of the processes are the same, that is, when the next process is called after the called process ends, Explain how to recover.

  In FIG. 16, the operation processing unit 152 (process A) performs device control processing (processing A) on the device 52 # A, the processing ends normally, and the process A activates the processing unit A154 # A, and processing B Performs device control (Process B-1) on device 52 # B, completes processing normally, and performs device control (Process B-2) on device 52 # C, and processing ends abnormally Is shown.

  FIG. 17 shows the contents of the process management information table 164 in the process sequence of FIG. In the process management information table 164, a field for setting the process start time is added to the above table, and the execution history is left. When process A performs apparatus control processing (process A) on apparatus 52 # A and completes normally (state 1), the process management information indicates that the execution result is being executed as shown in FIG. 1) Whether recovery can be performed is in the initial state (0).

  When process B performs apparatus control processing (process B-1) on apparatus 52 # B and the process ends normally (state 2), the execution result is executed as shown in FIG. Completed (2), whether or not restoration is possible is in the initial state. Furthermore, the process management information related to the process B-2 when the process B performs the apparatus control process (B-2) on the apparatus 52 # C and ends abnormally (state 3) is as shown in FIG. The execution result is abnormal end (-1), and the recovery execution availability is recovery execution possible (1). If the process A returns abnormally from the process B-2 (state 4), as shown in FIG. 17D, the process management information recovery process propriety of the processes A and B-1 is set to be executable (1). .

  FIG. 18 is a flowchart of the recovery process performed by the recovery control unit 158 according to the first embodiment of the present invention. In step S2, as shown in (2), the process management information in the process management information table 164 is periodically monitored, and the execution result of the last generated process management information record is abnormal for the same management ID. It is checked whether the end (NG) is “−1”. This is because the process management information of the same management ID is information about a group of processes requested to be controlled by the input / output unit 150, and these processes are targeted for recovery. Since the processing is performed sequentially instead of in parallel, whether the entire processing is normal end / abnormal end is determined by the final record for the management ID.

  In step S4, it is determined whether or not there is NG. If there is NG, the process proceeds to step S6, and if there is no NG, the process returns to step S2. In step S6, as shown in (4), the "business name ID", "process number", "processing start time", and "recovery execution possibility" of the final record are acquired. In step S8, the “business name” corresponding to the “business name ID” acquired in step S6 is acquired with reference to the business name management information table 165. As shown in FIG. 18, the business name management information table 165 stores a business name corresponding to the business name ID. For example, a business name whose “business name ID” is (10005) is execution of bandwidth control.

  FIG. 19 is a diagram showing a list of recovery targets. In step S10, the acquisition information is displayed on the recovery control input / output unit 156 as shown in (8), and the processing target item name is selected as shown in (10). The figure shows an example of a recovery target display screen. As shown in FIG. 19, the recovery target display selection screen displays the recovery control input with the selection items including the business name, process ID, processing start time, and recovery availability of the final processing management information records of all management IDs acquired in step S4. It is displayed on the output unit 156. In other words, not only those that can be recovered at the present time but also those that cannot be recovered are displayed. The operator selects a business name to be restored. For example, the operator selects restoration of bandwidth control execution. In step S12, for the selected business name, a recovery scenario execution request is made to the recovery execution process in descending order of the “process management number”.

  FIG. 20 is a diagram showing the flow of executing the recovery scenario. FIG. 21 shows an example of a recovery scenario based on the three process management information in FIG. 17 when process B-2 shown in FIG. 16 ends abnormally and processes A and B-1 end normally. Is. Since the recovery scenario is executed in descending order of the process management number, the process B-2 corresponding to the process management number = 3 is firstly recovered.

  As shown in (2), the recovery control unit 158 issues a process B-2 recovery scenario execution request to the process B corresponding to the process ID of the process management information to be recovered. The process B reads the recovery scenario defined in the recovery scenario 168 from the business name ID (10005) and the process management number (3) of the process management information for the process B-2. For example, the recovery scenario is assumed to be a pre-device control execution scenario that defines a control procedure for recovering the device state before device control.

  As shown in (4), the process B retrieves the pre-process execution information table 166 based on the management ID and the process management number of the process management information for the process B-2, and acquires the corresponding pre-process execution information. The process execution information table 160 is updated from the pre-process execution information and the state of the device 52 # C is recovered. For example, when the restoration target business name is “Bandwidth control execution” and the state is restored to the state before processing execution, a device control request “bandwidth control release” is executed to the device 52 # C. If the device control request consists of multiple control sequences, the recovery scenario defines the recovery procedure from each abnormally terminated control sequence, and therefore corresponds to the control sequence stored in the pre-processing execution information table 166 The state of the device 52 # C is recovered according to the procedure.

  As shown in (6), the recovery control unit 156 issues a recovery scenario execution request to the process A whose execution result of the next processing management information is abnormally terminated. Since the process A has already been restored for the process B-2 of the process B corresponding to the process ID of the process management information of the lowest process management number (3) according to the descending order of the process management numbers of the process management information. As shown in (8), the recovery process is restored without double activation, and as shown in (10), the process B corresponding to the process ID of the process management information of the next process management number (2) A recovery scenario execution request is made for process B-1.

  As shown in (12), process B executes the apparatus status of apparatus 52 # B according to the recovery scenario based on the process management information and process pre-execution information for process management number (2) of process B-1. Recover before. Since the process B-1 is normally completed, the apparatus 52 # B is restored according to the sequence reverse to the apparatus control request in the process B-1, and the process execution information table 160 is updated from the pre-process execution information. As a result, the device state of the device 52 # B is restored to the pre-process execution state, and the process execution information for the device 52 # B is restored to the pre-process execution state in the process execution information table 160. As shown in (14), the process A sets the apparatus status of the apparatus 52 # A before executing the process according to the recovery scenario based on the process management information and the process execution information for the process management number (1) for the process A. The process execution information table 160 is updated from the pre-process execution information.

  When the recovery process is completed, as shown in FIG. 17E, the management ID, process management information, and pre-process execution information related to recovery are deleted from the tables 162, 164, and 166. In the case of recovery to the post-process execution state, the process execution information table 160 is updated based on the pre-process execution information according to the recovery scenario 168, and the apparatus 102 # A in which the apparatus control has ended abnormally has failed. The apparatus control request is executed again, and the recovery process is skipped for the apparatus 52 # A for which the apparatus control has been normally completed.

  As described above, the apparatus information can be quickly recovered before the execution of the process or after the execution of the process based on the information before the execution of the process without performing the initial setting. Since the recovery is performed based on the recovery scenario, even if the recovery procedure is changed, the recovery scenario can be easily changed by replacing the recovery scenario.

(E) Recovery process (second embodiment)
The recovery processing method of the second embodiment is different from the method of the second embodiment when another process is called while the called process is being executed, and the order of the called process is different from the process end order. It is in.

  In FIG. 22, the operation processing unit 152 (process A) performs device control on the device 52 #A, the processing A ends normally, and the process B sequentially calls the processing B- 1 and B- 2 and processing B -1 and B-2 are performed in parallel, and the process B-2 ends abnormally before the process B-1, and then the process B-1 ends abnormally. FIG. 23 shows the contents of the process management information table 164 in the process sequence of FIG.

  When process A performs apparatus control processing (process A) on apparatus 52 # A and the process ends normally (state 1), the execution result is being executed as shown in FIG. 1) Whether recovery can be performed is in the initial state (0). The process B is performing the apparatus control process (process B-1) for the apparatus 52 # B, but the process management information being executed (state 2) shows that the execution result is as shown in FIG. Execution completed (2) and restoration execution availability are in the initial state (0). Furthermore, when the process B performs the apparatus control process (B-2) on the apparatus 52 # C while the process B-1 is being executed, the process management information for the process B-2 when the process B ends abnormally (state 3) is shown in FIG. As shown in FIG. 23 (c), the execution result is abnormal termination (-1), and the recovery execution availability is recovery implementation possible (1).

  When process A is notified of abnormal termination from process B-2 (state 4), as shown in FIG. 23 (d), the execution result for process A is abnormal termination (-1), and process B-1 Since the execution result of the process management information is being executed (1), whether or not recovery can be performed remains in the initial state (0). Processing B-1 is about device control for the device 52 # B, and processing B-1 when the device 52 # B is abnormally terminated due to an abnormality during initialization processing for the device 52 # X (state 2b). As shown in FIG. 23 (e), the process management information in FIG. 23 indicates that the execution result is abnormal termination (-1), and whether recovery is feasible (1). When the process A is notified of the abnormal end from the process B-1 (state 5), as shown in FIG. 23F, the execution result of the process management information for the process B-1 is the abnormal end (-1). Therefore, whether or not the recovery for process A can be executed is executable (1).

  FIG. 24 is a flowchart of the recovery process performed by the recovery control unit 158 according to the second embodiment of the present invention. In step S20, as shown in (2), the process management information in the process management information table 164 is periodically monitored, and the execution result of the process management information record for the same management ID is abnormal end (NG) “ -1 "is checked. The reason for checking not only the final record but also all records for the same management ID is that the final record corresponding to the last activated process is normal because the processes B-1 and B-2 are processed in parallel. However, it may be abnormal in other processes.

  In step S22, it is determined whether or not there is NG. If there is NG, the process proceeds to step S24, and if there is no NG, the process returns to step S20. In step S24, for the same “management ID”, it is confirmed whether or not recovery execution feasibility of the process management information whose execution result is abnormal termination (−1) is all feasible (1). In step S26, it is determined whether or not there is any implementation possible (1). If everything is feasible (1), the process proceeds to step S28. For example, after the process B-1 is completed, all the recovery execution availability is implementation possible (1), so the process proceeds to step S28. If there is something that cannot be performed, the process returns to step S24, and waits until it becomes all possible (1).

  As described above, when the calling order and the end order of the processes B-1 and B-2 may be different, the presence / absence of the business to be restored is not the last record for the management ID but all the records. Judgment is based on whether or not the execution result is abnormal, and the timing at which recovery can be performed is not the timing at which the final record can be recovered, but the timing at which recovery can be performed for all records where the execution result is abnormal It is. Since the process of step S28-step S34 is the same as the process of step S6-step S12 in FIG. 18, description is abbreviate | omitted. As described above, there are the same effects as in the first embodiment.

(F) Recovery processing (third embodiment)
In the first and second embodiments, the operator instructs recovery (manually), but in the third embodiment, each business name ID and process number is recovered by either manual or automatic method. For example, the recovery method identification, the upper limit to retry even if recovery fails (retry upper limit), and the waiting time until retry are input from the recovery control input / output unit 156, and the recovery control unit 158 inputs the environment information table 170. To store.

  FIG. 25 is a diagram showing a process call relationship, which is the same as FIG. FIG. 26 shows the contents of the process management information table 160. The state 1-4 is the same as the state 1-4 in FIG. 16, but the process management information in the state 1-4 is based on the business name ID and process number for the processes A, B-1, and B-2. Search the environment information table 170 to obtain the recovery method identification, retry upper limit and waiting time corresponding to the business name ID and process number, and write them together with the management ID, process management number, process number, etc. in the process management information table 160 Therefore, the recovery method identification, the retry upper limit, and the waiting time are added to the process management information in FIG.

  FIG. 27 is a flowchart of the recovery process performed by the recovery control unit 158 according to the third embodiment of the present invention. In step S50, as shown in (2), the process management information in the process management information table 164 is periodically monitored, and the execution result of the final process management information record for the same management ID is abnormally terminated (NG ) Check whether it is “−1”.

  In step S52, it is determined whether there is NG. If there is NG, the process proceeds to step S54, and if there is no NG, the process returns to step S50. In step S54, as shown in (4), it is checked whether or not the recovery method identification is automatic recovery (1) for the same “management ID”. If it is determined in step S56 that automatic recovery has been performed, the process proceeds to step S58. If it is manual recovery, the same processing as steps S6 to S12 in FIG. 18 is performed. When recovery fails, recovery is retried according to the retry upper limit and waiting time.

  In step S58, as shown in (6), a recovery scenario execution request is made for the automatic recovery target process. Requests are made in descending order of process management numbers. In step S60, it is determined whether the recovery is successful. If the recovery is successful, the process ends if the recovery is completed for the target of automatic recovery, and if there is an item for which automatic recovery is not completed, the process proceeds to step S61. In step S62, it is determined whether or not recovery has been completed for all recovery targets. If recovery has not been completed for all recovery targets, the process returns to step S58. If the recovery is finished, the process is finished.

  For example, as shown in FIGS. 26 and 27, process numbers 1003, 1002, and 1001 are automatically restored because the restoration method is an automatic method. If the process A with the process ID 1001 is abnormally terminated first and the processes with the process IDs 1002 and 1003 are not activated, that is, the process number 1001 is registered as the latest record, the “execution result” is “−”. In the case of “1”, the process ID 1001 can be enabled only manually even if automatic recovery is set.

  In step S62, it is determined whether or not the retry upper limit has become zero. When the retry upper limit becomes 0, the process ends. If the retry upper limit is not 0, the process proceeds to step S70. In step S64, as shown in (8), the retry upper limit of the corresponding record in the process management information table 164 is decremented by one. In step S72, as shown in (10), after waiting for the waiting time of the corresponding record, the process returns to step S58.

  As described above, in addition to the same effects as those of the first and second embodiments, when the recovery is automatically performed and the retry upper limit is set and the recovery fails, the operator tries by retrying to the retry upper limit. Man-hours for manually instructing recovery can be saved, and manual recovery and automatic recovery can be distinguished for each business name ID and process ID.

(G) Recovery processing (fourth embodiment)
In the fourth embodiment, the recovery of the system 50 and the devices 52 # A to 52 # D and 102 # A to 102 # D is performed in synchronization in the first to third embodiments. 52 # D and 102 # A to 102 # D can be disconnected to restore only the system state. Synchronizing the recovery of the system 50 and the devices 52 # A to 52 # D and 102 # A to 102 # D means that both the system 50 and the devices 52 # A to 52 # D and 102 # A to 102 # D are synchronized. It means that the system 50 and the devices 52 # A to 52 # D and 102 # A to 102 # D fail to be restored. The recovery of the system 50 refers to the recovery of the process execution information table 160.

  As shown in FIG. 28, the recovery control input / output unit 156 can select a recovery type flag for the selected business name in addition to selecting a business name to be recovered from the recovery target list. ing. The recovery type flag includes a mode in which only the system state is recovered in synchronization with the apparatus, and a mode in which only the system state is recovered by disconnecting from the apparatus.

  FIG. 29 is a flowchart of the recovery process performed by the recovery control input / output unit 156 and the recovery control unit 158 according to the fourth embodiment of the present invention. In step S100, when the recovery control input / output unit 156 displays the recovery type flag together with the recovery target list as shown in FIG. 27, the operator selects the recovery target flag from the recovery target list and selects the recovery type flag. And request recovery.

  In step S102, recovery processing in the system 50 is performed. Here, the recovery process is performed first in the system 50. However, the recovery process in the system 50 is performed in the corresponding processing order when the recovery process is performed in descending order of the process management numbers to be recovered. Also good. In step S104, it is determined whether or not the response in the system 50 is normal (the recovery process of the system 50 is successful). If normal, the process proceeds to step S106. If abnormal, the process proceeds to step S114. In step S106, recovery processing is performed on the devices and other systems (devices, etc.) in the order of descending processing management numbers according to the recovery scenario described above. In step S108, it is determined whether or not the response from the device or the like is normal. If normal, the process proceeds to step S111. If abnormal, the process proceeds to step S110.

  In step S110, it is determined whether or not “synchronization with device or the like” is selected as the recovery type flag. If “Synchronize with device etc.” is selected, the process proceeds to step S114. In step S114, the process is interrupted. In other words, when “synchronize with a device or the like” is selected, the processing is interrupted when a recovery abnormality occurs in any one of the system 50 or the device to be recovered. If “recover only the system state by disconnecting from the device” is selected, the process proceeds to step S111. On the other hand, if "Restore only system status by disconnecting from devices" is not selected, even if any one of the recovery errors occurs, the other devices can be recovered, Since a failure occurs in one device, etc., and a failure has occurred in the communication line that connects the system and the device, it is possible that a recovery abnormality will occur. It restores other devices.

  This is because device control requests and communication can be made to other restored devices. In step S112, it is determined whether or not recovery has been completed for all process management numbers. When the recovery is completed, the process ends. If the recovery has not been completed, the process returns to step S102 to perform a recovery process for the system 50 or the device that has not been recovered.

  If the recovery process is performed in descending order of the process management number, when "Restore only the system status by disconnecting from the device, etc." is selected, even if the recovery process of the device etc. ends abnormally, the following Perform recovery processing for systems and devices in descending order. As described above, the device whose recovery has ended abnormally is disconnected, and other devices and systems are preferentially recovered, so that the device control request can be made to the system 50, the device whose recovery has ended normally, or the like.

(H) Recovery processing (fifth embodiment)
The fifth embodiment differs from the fourth embodiment in the significance of the recovery type flag “recover only the system state by disconnecting from the device”. “Restoring only the state of the system by disconnecting from the device” refers to a recovery method in which only the system 50 is a recovery target, excluding the device and the like.

  FIG. 30 is a flowchart of the recovery process performed by the recovery control input / output unit 156 and the recovery control unit 158 according to the fifth embodiment of the present invention. The process of steps S150 to S154 is the same as the process of steps S100 to S104. In step S156, it is determined whether or not “synchronization with device or the like” is selected as the recovery type flag. If “synchronize with device, etc.” is not selected, the device is not subject to recovery, and the process proceeds to step S158. If “Synchronize with device” is selected, the process proceeds to step S160.

  In step S158, it is determined whether recovery has been completed for all process management numbers. When recovery is complete, the process ends. If the recovery is not completed, the process returns to step S152. In step S160, recovery processing of the device or the like is performed. In step S162, it is determined whether or not the response from the device or the like is normal. If the response is normal, the process proceeds to step S158. If the response is not normal, the process proceeds to step S164. In step S164, the process is interrupted. As described above, when “synchronization with devices and the like” is not selected, the system 50 is quickly recovered by performing the recovery process of only the system 50, and the control request other than the recovery process is performed. For example, operations such as device status monitoring can be performed.

(I) Recovery processing (sixth embodiment)
In the sixth embodiment, if the recovery type flag is not specified and recovery is attempted after a certain number of synchronizations with the device or the like, if the recovery is not successful, the system state is automatically disconnected and only the system state is recovered. Is.

  FIG. 31 is a flowchart of the recovery process executed by the recovery control unit 158 according to the sixth embodiment of the present invention. In step S200, recovery processing in the system 50 is performed. Here, the recovery process of the system 50 is performed first, but as described above, the process may be performed according to the descending order of the process management numbers. In step S202, it is determined whether or not the response in the system 50 is normal. If the response in the system 50 is normal, the process proceeds to step S204. If the response in the system 50 is not normal, the process proceeds to step S210.

  In step S204, recovery processing of the device or the like is performed. In step S206, it is determined whether or not the response from the device or the like is normal. If the response is normal, the process proceeds to step S207. If the response is not normal, the process proceeds to step S210. In step S207, recovery processing of the device or the like is performed. In step S208, it is determined whether or not recovery has been completed for all process management numbers. If the recovery is not completed, the process returns to step S200. When the recovery is completed, the process ends.

  In step S210, the number of restoration failures is counted up for the restoration process. In step S212, if the number of recovery failures is equal to or less than the specified number, the process returns to step S200 to perform recovery processing of the system 50 or the device that has failed to recover. When the number of restoration failures reaches the specified number, in step S214, the system 50 or other devices are restored by excluding the failed restoration device from the restoration target. As described above, when the device restoration fails, it is possible to quickly restore the device by automatically retrying up to the upper limit number of times. For devices that are not restored by the retry, the other devices and the own system 50 are restored. Therefore, other devices can be automatically restored.

(J) Recovery processing (seventh embodiment)
In the seventh embodiment, the recovery type request flag is applied only to a recovery request portion related to a specific device or the like, not for each operation (management ID) that makes a recovery processing request. The fact that a specific device cannot be recovered for a long time, for example, that a device related to the abnormal end cannot be recovered for a long time due to a failure due to an abnormal end in response to a device control request, in advance before recovery. This is known when the device is excluded from the recovery target and you want to manage the state separately from the system 50, but you want to recover the state of other devices etc. by synchronizing the state with the system 50. The form applies.

  FIG. 32 is a system configuration diagram of the monitoring system 200 for performing the recovery processing according to the seventh embodiment of the present invention, and the same components as those in FIG. 2 are denoted by the same reference numerals. As shown in the figure, a non-recovery table 210 is provided. The recovery target non-recovery table 210 stores device numbers of devices that are not recovery target. The device number corresponds to the device number registered in the pre-processing execution information table 166. The operator inputs a device number that is not a recovery target from the recovery control input / output unit 202, and the recovery control unit 204 registers it in the non-recovery target table 210.

  FIG. 33 is a flowchart of the recovery process executed by the recovery control unit 204 according to the seventh embodiment of the present invention. In step S250, recovery processing in the system 50 is performed. In step S252, it is determined whether or not the response in the system 50 is normal. If the response in the system 50 is normal, the process proceeds to step S253. If the response in the system 50 is not normal, the process proceeds to step S260.

  In step S253, recovery processing of the device or the like is performed. In step S254, it is determined whether or not the response from the device or the like is normal. If the response is normal, the process proceeds to step S256. If the response is not normal, the process proceeds to step S258. In step S256, it is determined whether recovery has been completed for all process management numbers. If the recovery is not completed, the process returns to step S250. When the recovery is completed, the process ends.

  In step S258, it is determined whether the abnormally terminated device or the like has been registered in the non-recoverable table 210. If registered in the non-recovery target table 210, the process proceeds to step S256. If not registered in the non-recovery table 210, the process proceeds to step S260. In step S260, the process is interrupted. As described above, even if the recovery process for the device or the like registered in the non-recovery table 210 is abnormally terminated, the other device or the like can be recovered in synchronization with the system 200 by ignoring this device or the like. it can. It is also possible to process a device or the like registered in the non-recovery target table 210 as a non-recovery target. In this way, devices that are known to be unrecoverable are registered as non-recoverable devices, so there is no need to perform unnecessary recovery processing on non-recoverable devices, enabling quick and lean recovery. Become.

  The present invention includes the following supplementary notes.

(Appendix 1)
A second information table that makes a device control request to a plurality of external devices that update a first information table that stores device information based on the device control request and stores processing execution information related to the device control request A device control processing unit for updating
A management information storage unit for storing, in a third information table, management information for specifying the content of the request related to the device control request and the external device targeted for the device control request when the device control request is made to the external device; ,
A pre-process execution information storage unit for storing pre-process execution information before performing the device control request stored in the second table related to the device control request in a fourth information table;
When processing for the device control request ends abnormally, based on the request content specified by the management information related to the device control request stored in the third information table, before or after the processing execution A recovery control unit that controls to execute the device control request for setting the device state to the external device;
A monitoring system comprising:

(Appendix 2)
The restoration control unit is configured to update the second information table before the update related to the device control request based on the pre-process execution information stored in the fourth information table corresponding to the device control request related to the abnormal termination. The monitoring system according to appendix 1, wherein the system is restored to the state of

(Appendix 3)
The device further includes an input unit for inputting a control request, the device control processing unit makes a plurality of device control requests to the plurality of external devices for the control request, and the management information storage unit performs the device control for the control request. A process management number indicating the order of requests is added to the management information and stored in the third information table, and the recovery control unit controls the apparatus based on the process management number stored in the third information table. The monitoring system according to appendix 2, wherein recovery is performed in the reverse order of the request order.

(Appendix 4)
Based on the management information stored in the third information table, a recovery output unit that displays the content of the control request that has not been completely restored due to the abnormal termination of the device control request, And a recovery input unit that inputs a recovery instruction in the management information stored in the third information table for the device control request related to the control request instructed to recover and the The monitoring system according to appendix 2, wherein the external device is restored based on the pre-process execution information stored in the information table 4.

(Appendix 5)
The management information storage unit adds execution state information set during execution of execution state information indicating a process execution state to the management information, stores the management state information in the third information table, and stores the execution state information in the external device The execution result indicating whether the abnormal end or the normal end is updated, and the recovery control unit determines whether or not the recovery process can be executed based on the execution state information, and the recovery process is executed. 4. The monitoring system according to appendix 3, wherein the recovery is performed when it is determined that it can be performed.

(Appendix 6)
The management information storage unit adds information specifying the content of each device control request to the management information when the device control request related to the control request is made multiple times to one external device. The restoration control unit specifies the content of the device control request based on the information specifying the content of the device control request, and stores the information in the third information table. The monitoring system according to supplementary note 1, wherein recovery processing for the external device is performed in an order reverse to the stored order.

(Appendix 7)
A recovery scenario file that stores a recovery scenario that defines a recovery procedure for each device control request is further provided, and the recovery control unit is configured to specify a device control request specified by management information stored in the third information table. The monitoring system according to appendix 1, wherein a recovery process is performed based on a recovery scenario stored in the recovery scenario file corresponding to.

(Appendix 8)
The device control request further includes an environment information table that stores a recovery method indicating whether to automatically or manually recover the device control request, and the recovery control unit automatically recovers the recovery method for the device control request. The monitoring system according to appendix 1, wherein the system is automatically restored when it is indicated.

(Appendix 9)
The monitoring system according to appendix 3, wherein the restoration control unit preferentially restores the second information table of the own system.

(Appendix 10)
The supplementary control unit according to claim 3, wherein the restoration control unit stops restoration of the external device and performs restoration processing for another external device when the restoration processing for the external device ends abnormally. Monitoring system.

(Appendix 11)
A fifth table for registering external devices not to be recovered; and the recovery control unit has priority over external devices not to be registered registered in the fifth table. The monitoring system according to appendix 3, wherein a recovery process is performed on the system.

It is a principle diagram of the present invention. 1 is an overall configuration diagram including a monitoring system according to an embodiment of the present invention. It is a block diagram of the system 50 in FIG. It is a figure which shows the process management information table 164. FIG. It is a figure which shows the pre-processing execution information table. It is a figure which shows an example of a recovery scenario. It is operation | movement explanatory drawing of the system in the case of normal completion. It is operation | movement explanatory drawing of the system in the case of normal completion. It is operation | movement explanatory drawing of the system in the case of normal completion. It is operation | movement explanatory drawing of the system in the case of normal completion. It is operation | movement explanatory drawing of the system in the case of abnormal termination. It is operation | movement explanatory drawing of the system in the case of abnormal termination. It is operation | movement explanatory drawing of the system in the case of abnormal termination. It is operation | movement explanatory drawing of the system in the case of abnormal termination. It is a figure which shows the change procedure of a recovery scenario. It is a figure which shows the calling relationship of the process in the case of abnormality in a serial process. It is a figure which shows the content of the process management information table in the process sequence of FIG. It is a flowchart of the recovery process by 1st Embodiment of this invention. It is a figure which shows a recovery object list. It is a figure which shows the flow of recovery scenario implementation. It is a figure which shows the example of recovery scenario implementation. It is a figure which shows the calling relationship of the process in the case of abnormality in a parallel process. It is a figure which shows the content of the process management information table in the process sequence of FIG. It is a flowchart of the recovery process by 2nd Embodiment of this invention. It is a figure which shows the calling relationship of a process. It is a figure which shows the content of the process management information table in the process sequence of FIG. It is a flowchart of the recovery process by 3rd Embodiment of this invention. It is a flowchart of the recovery process by 4th Embodiment of this invention. It is a figure which shows a recovery object list. It is a flowchart of the recovery process by 5th Embodiment of this invention. It is a flowchart of the recovery process by 6th Embodiment of this invention. It is a system configuration | structure figure of the monitoring system for implementing the recovery process by 7th Embodiment of this invention. It is a flowchart of the recovery process by 7th Embodiment of this invention.

Explanation of symbols

2 # i (i = 1 to n) First information table 4 # i (i = 1 to n) External device 10 Recovery system 12 Second information table 14 Device control processing unit 16 Third information table 18 Management information Processing unit 20 Fourth information table 22 Pre-processing information storage unit 24 Recovery control unit

Claims (3)

A second information table that makes a device control request to a plurality of external devices that update a first information table that stores device information based on the device control request and stores processing execution information related to the device control request A device control processing unit for updating
A management information storage unit for storing, in a third information table, management information for specifying the content of the request related to the device control request and the external device targeted for the device control request when the device control request is made to the external device; ,
A pre-process execution information storage unit for storing pre-process execution information before performing the device control request stored in the second table related to the device control request in a fourth information table;
When processing for the device control request ends abnormally, based on the request content specified by the management information related to the device control request stored in the third information table, before or after the processing execution A recovery control unit that controls to execute the device control request for setting the device state to the external device;
A monitoring system comprising:   The restoration control unit is configured to update the second information table before the update related to the device control request based on the pre-process execution information stored in the fourth information table corresponding to the device control request related to the abnormal termination. The monitoring system according to claim 1, wherein the system is restored to the state.   The device further includes an input unit for inputting a control request, the device control processing unit makes a plurality of device control requests to the plurality of external devices for the control request, and the management information storage unit performs the device control for the control request. A process management number indicating the order of requests is added to the management information and stored in the third information table, and the recovery control unit controls the apparatus based on the process management number stored in the third information table. The monitoring system according to claim 2, wherein recovery is performed in an order reverse to the order of requests.

Images