Maintenance management system, maintenance management method, management server, and maintenance management program

Abstract

To integrally perform routine maintenance works which are generally held by various devices on a network.SOLUTION: A maintenance management system according to the present invention includes a first server to be connected to a maintenance terminal and a second server to be connected to a plurality of target devices. The first server has a common request unit for each maintenance type which transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server, and transmits, to the maintenance terminal, a response result of each of the plurality of target devices which is obtained through the second server for a common maintenance request. The second server has a response unit for each maintenance type which converts the common maintenance request from the common request unit for each maintenance type into a format that can be handled by each of the plurality of target devices, transmits the request to each of the corresponding plurality of target devices, converts the response result from each of the plurality of target devices into a format of the common request unit and transmits it to the corresponding common request unit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a maintenance management system and a maintenance management method. , management server The present invention can be applied to a maintenance management system that maintains and manages various devices connected to an IP (Internet Protocol) network using a common web interface. [Background technology]

[0002] For example, various devices such as VoIP (Voice over IP) devices, servers, IP network equipment such as routers and switches, and optical transmission devices are connected to IP networks.

[0003] Generally, maintenance management such as setting up equipment and monitoring equipment status uses a dedicated equipment interface for each model, and information obtained during maintenance is presented to maintenance workers through the equipment interface for each model. Note that the equipment interface referred to here is conscious of the interface necessary for maintenance work, and includes, for example, UI (User Interface), API (Application Programming Interface), communication interface, etc.

[0004] However, since the device interface differs depending on the device model, maintenance workers must perform different maintenance tasks for each model, which places a heavy burden on the maintenance workers. Therefore, it is desirable to be able to perform maintenance management for multiple device models in a common environment.

[0005] Conventional technologies for providing maintenance and operation using a web-based API include, for example, Patent Documents 1 and 2.

[0006] In Patent Document 1, a server provides a common Web API to a terminal device, the server accepts operation requests for a cash handling machine from the terminal device, converts the requests into an interface that the cash handling machine can accept, and inputs the requests into the cash handling machine. The common Web API is defined as "common" in that it absorbs differences in interfaces due to differences in models of cash handling machines.

[0007] Patent Document 2 describes a maintenance work support system that supports maintenance work by visualizing the history information of a web system in order to shorten the lead time to the source of a problem in an information system when analyzing the cause of the problem. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Application Publication No. 2018-128830 [Patent Document 2] Japanese Patent Application Laid-Open No. 2011-192230 Summary of the Invention [Problem to be solved by the invention]

[0009] However, the technology described in the above-mentioned Patent Document 1 has a problem in that it is not possible to use interfaces of various devices on an IP network because the object of maintenance is limited to a cash processing machine.

[0010] Furthermore, the technology described in Patent Document 2 is a maintenance and operation interface specialized for adding historical information related to information system failures, and like Patent Document 1, it has the problem that it cannot be used as an interface for various devices on an IP network.

[0011] In order to solve the above-mentioned problems, the present invention provides a maintenance management system and a maintenance management method that can perform integrated maintenance and operation of routine maintenance tasks that are generally performed on various devices on a network. , management server and maintenance management programs are required. [Means for solving the problem]

[0012] In order to solve the above problem, a first maintenance management system according to the present invention includes a first server connected to a maintenance terminal and a second server connected to a plurality of target devices, the first server having a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server and transmits a response result of each of the plurality of target devices to the common maintenance request, acquired via the second server, to the maintenance terminal, and the second server having a response unit for each maintenance type that converts the common maintenance request from the common request unit for each maintenance type into a format compatible with each of the plurality of target devices and transmits it to each of the corresponding plurality of target devices, and converts the response result from each of the plurality of target devices into a format of the common request unit and transmits it to the corresponding common request unit. The first server has a maintenance scenario storage unit that stores, for each target system having a plurality of target devices, a maintenance scenario that sets a plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system, and a maintenance execution unit that causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each target system. It is characterized by:

[0013] A second maintenance management method according to the present invention is a method for managing maintenance by a first server connected to a maintenance terminal, which includes a common request section for each maintenance type. and the Maintenance Executive Department. a second server connected to a plurality of target devices has a response unit for each maintenance type, the common request unit transmits a common maintenance request for each of the plurality of target devices from a maintenance terminal to the second server, the corresponding response unit converts the common maintenance request from the common request unit for each maintenance type into a format that can be handled by each of the plurality of target devices and transmits it to each of the corresponding plurality of target devices, the response unit converts a response result from each of the plurality of target devices into a format of the common request unit and transmits it to the corresponding common request unit, and the common request unit transmits the response result of each of the plurality of target devices to the common maintenance request, acquired from the response unit, to the maintenance terminal The maintenance execution unit of the first server refers to a maintenance scenario storage unit that stores, for each target system having a plurality of target devices, a maintenance scenario in which a plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set, and causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at the execution time set in the maintenance scenario for each target system. It is characterized by:

[0014] The third aspect of the present invention is a management server that cooperates with a linking server connected to a plurality of target devices and provides maintenance information for each of the plurality of target devices to a maintenance terminal, the management server including a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server and transmits a response result for each of the plurality of target devices to the common maintenance request, which is acquired through the linking server, to the maintenance terminal. a maintenance scenario storage unit that stores, for each target system having a plurality of target devices, a maintenance scenario in which a plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set; and a maintenance execution unit that causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each target system. It is characterized by:

[0016] No. 4 The present invention provides a maintenance management program that cooperates with a linking server connected to a plurality of target devices and provides maintenance information for each of the plurality of target devices to a maintenance terminal, the program comprising: a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server, and transmits a response result for each of the plurality of target devices to the common maintenance request, which is acquired via the linking server, to the maintenance terminal; a maintenance execution unit that references a maintenance scenario storage unit that stores, for each target system having a plurality of target devices, a maintenance scenario in which a plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set, and causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each target system; The present invention is characterized by the fact that it functions as a [Effects of the Invention]

[0018] According to the present invention, routine maintenance work that is generally performed on various devices on a network can be performed in an integrated manner. [Brief explanation of the drawings]

[0019] [Figure 1] 1 is an overall configuration diagram showing the overall configuration of a maintenance management system according to an embodiment; [Figure 2] FIG. 2 is an explanatory diagram for explaining the definition of an open API for routine maintenance according to the embodiment. [Figure 3] FIG. 10 is an overall configuration diagram showing the overall configuration of a maintenance management system according to a modified embodiment. [Figure 4] FIG. 10 is an overall configuration diagram showing the overall configuration of a maintenance management system according to a second embodiment. [Figure 5] FIG. 10 is an explanatory diagram illustrating an example of a configuration of a maintenance scenario according to the second embodiment. [Figure 6]FIG. 11 is a screen diagram showing an example of a registration screen for a maintenance scenario according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0020] (A) First embodiment The following describes the maintenance management system and the maintenance management method according to the present invention. , management server A first embodiment of the maintenance management program will be described in detail with reference to the drawings.

[0021] In this embodiment, a Web API (Application Program Interface) is defined that allows various devices on an IP network to call routine maintenance tasks generally performed by each device using a communication protocol such as HTTP or HTTPS, and the maintenance management system provides the Web API. Here, this Web API is called an "open API for routine maintenance tasks."

[0022] By utilizing an open API for routine maintenance work, the maintenance management system can access information about maintenance work from devices that make up multiple systems, making it possible to maintain and operate each device in an integrated manner.

[0023] (A-1) Configuration of the First Embodiment FIG. 1 is a diagram showing the overall configuration of a maintenance management system according to an embodiment.

[0024] 1, a maintenance management system 10 according to the embodiment includes a maintenance terminal 1, a management server 2, a linking server 3, devices 4 (4-1 to 4-N; N is a positive integer), and a routine maintenance work setting information storage unit 5. The maintenance management system 10 illustrated in FIG. 1 is connectable to an IP network.

[0025] The devices 4 (4-1 to 4-N) are devices that are subject to maintenance control and can be connected to an IP network. Various types of devices can be applied to the devices 4 (4-1 to 4-N), such as VoIP devices, servers, network devices, and optical transmission devices. Each of the devices 4-1 to 4-N has a device interface 41 corresponding to the model, and the device interface 41 operates using commands corresponding to the model, such as SSH (Secure Shell) or telnet.

[0026] The maintenance terminal 1 is a terminal operated by a maintenance person and performs maintenance control such as setting the devices 4 (4-1 to 4-N) and monitoring their status. The maintenance terminal 1 can be, for example, a personal computer, a smartphone, a tablet terminal, or the like, and is a terminal device having a display unit, an input unit, a control unit, a communication unit, and the like.

[0027] For example, the maintenance terminal 1 uses a web browser function to exchange web information that corresponds one-to-one with the open API for routine maintenance work with the management server 2, and utilizes the open API for routine maintenance work provided by the linking server 3, or executes routine maintenance work application software (also called a "maintenance work app") that has been installed in advance to utilize the open API for routine maintenance work. The API of web information that corresponds one-to-one with the open API for routine maintenance work, which the management server 2 provides to the maintenance terminal 1, is called the open GUI-API for routine maintenance work. In other words, the maintenance terminal 1 can use the open GUI-API for routine maintenance work provided by the management server 2 using a web browser, a maintenance work app, or the like.

[0028] The maintenance terminal 1 connects to the management server 2, displays a screen of the maintenance work defined by the open GUI-API for defined maintenance work on the display unit, and the desired maintenance work is selected by the maintainer. Then, the maintenance terminal 1 transmits a request including maintenance identification information (in this embodiment, an "API number" is used as an example) indicating the maintenance work selected on the screen to the management server 2 via the open GUI-API for defined maintenance work. Furthermore, the maintenance terminal 1 acquires maintenance information for each of the devices 4-1 to 4-N related to the requested maintenance work from the management server 2 via the open GUI-API for defined maintenance work, and displays a screen of the maintenance information for each of the devices 4-1 to 4-N on the display unit.

[0029] In other words, the maintenance terminal 1 requests integrated maintenance information for multiple devices 4 from the management server 2 using a command screen displayed on the display unit, and obtains information about each device 4 related to the requested maintenance and displays it on the display unit.

[0030] The management server 2 is the server that calls the system on the linking server 3 side, for example, via HTTP or HTTPS. In other words, the management server 2 implements clients 21 to 23 for each API number defined in the open API for routine maintenance work. In the following description, for example, a client with API number "1" will be described as client 21, etc. Each of the clients 21 to 23 displays the maintenance work for each API number on the display unit of the maintenance terminal 1.

[0031] The linked server 3 is a server that is called by the management server 2, for example, via HTTP or HTTPS. In other words, the linked server 3 implements servers 31 to 33 for each API number for clients corresponding to each API number. In the following description, for example, the server with API number "1" will be referred to as server 31, etc.

[0032] The clients 21 to 23 and the servers 31 to 33 are associated with each other by API number, and the client and server for each API number form a pair to exchange data. That is, the clients 21 to 23 and the servers 31 to 33 send and receive data specialized for maintenance work defined by the open API for routine maintenance work.

[0033] Furthermore, the servers 31 to 33 for each API number have a mutual conversion unit 35 that converts between a request defined in the open API for routine maintenance work and a request for the device interface 41 on which each device 4 depends. Therefore, when the servers 31 to 33 receive a request for an interface for maintenance work specialized for the API number from the clients 21 to 23 for each corresponding API number, they convert the request into a request for the device interface 41 on which each device 4 depends, and send the converted request to the device interface 41 of each device 4.

[0034] The mutual conversion unit 35 can be configured in various ways, and for example, converts a request (or response) defined in the routine maintenance work open API and a request (or response) of the device interface 41 on which each device 4 depends by referring to a correspondence table. For example, the correspondence table is stored in the routine maintenance work setting information storage unit 5. Note that a separate correspondence table may also be provided.

[0035] Here, the clients 21 to 23 for each API number and the corresponding servers 31 to 33 implement, for example, REST (Representational State Transfer), and transmit and receive data using REST.

[0036] Furthermore, in this embodiment, the case where the clients 21 to 23 and the servers 31 to 33 transmit and receive data using the HTTP or HTTPS communication protocol is exemplified, but the present invention is not limited to this as long as data transmission and reception is possible over an IP network.

[0037] FIG. 2 is an explanatory diagram for explaining the definition of the routine maintenance work open API according to the embodiment.

[0038] In Fig. 2, the open API for routine maintenance work is a common interface generally required for maintaining and operating the device 4, and here, examples of maintenance work names are shown as command input, alarm reception, file transfer, etc. "IN" and "OUT" define common interface parameters for each API number (or each maintenance work).

[0039] The open API for routine maintenance work has the following items: "API number," "name" indicating the name of the maintenance work, "summary" indicating an overview of the maintenance work, "IN" indicating the type of data input (received), and "OUT" indicating the type of data to be output (sent). Note that the items are not limited to these, and other items may be added.

[0040] The routine maintenance work open API is used with a communication protocol such as HTTP or HTTPS so that it can be used by the devices 4 on the IP network. Furthermore, the routine maintenance work open API conforms to REST so that it can be easily implemented by the clients 21 to 23 that are the calling side and the servers 31 to 33 that are the called side. That is, it is created in a data format such as JSON (JavaScript Object Notation).

[0041] For "API number: 1," a maintenance task for "Name: Command submission" is defined. The summary of the maintenance task for "Name: Command submission" is defined as "Summary: Execute the specified command and return a response," with "IN" defining the "command submission destination and command string," and "OUT" defining the format of the "command response string."

[0042] For example, in the management server 2, the client 21 with API number "1" transmits a command destination and a command string to the server 31 with API number "1" of the linkage server 3. The command destination can be a specific port number in each device 4, for example. In this case, the server 31 converts the command into a command that the device interface 41 of the device 4 to which the command is transmitted can handle, and then transmits the converted command to the device interface 41. When the server 31 receives a command response from the device interface 41 of the device 4, it converts the command response into a command response string format defined by the routine maintenance work open API. The server 31 then returns the command response string, converted into the command response string format defined by the routine maintenance work open API, to the client 21. Therefore, it is possible to transmit a maintenance-related command to the device interface 41 of one or more devices 4 to call up maintenance information such as the settings and status of each device 4.

[0043] For "API number: 2," maintenance work for "Name: Alarm reception" is defined. The summary of the maintenance work for "Name: Alarm reception" is defined as "Summary: Search the alarm journal at the specified time and return whether the corresponding alarm has been received," with "IN" defining "search start time, search end time, generating device, TrapID, search string," etc., and "OUT" defining "list of corresponding message information," etc.

[0044] For example, a client 22 with API number "2" of the management server 2 transmits data including a search start time, a search end time, a generating device, a Trap ID, and a search string to a server 32 with API number "2" of the linkage server 3. The server 32 converts the data into a request that can be handled by the device interface 41 of the target device 4, and transmits the data including the search start time, search end time, generating device, Trap ID, and search string to the device interface 41 of the device 4. The device 4 transmits a list of message information of the Trap IDs from the search start time to the search end time to the server 32. The server 32 outputs the list of received message information to the client 22. As a result, for example, if a fault has occurred in one or more devices 4, it is possible to receive a fault message or the like from the device 4.

[0045] For "API number: 3," the maintenance work for "Name: File Transfer" is defined. The summary of the maintenance work for "Name: File Transfer" is defined as "Summary: Transfer the specified file to the specified folder," with "IN" defining the "source file, destination directory," and "OUT" defining "OK or NG."

[0046] For example, a client 23 with API number "3" on the management server 2 transmits data including a transfer destination file and a transfer destination directory to a server 33 with API number "3" on the linkage server 3. The server 33 converts the request into one that the device interface 41 of the target device 4 can handle, and transmits the transfer destination file and the transfer destination directory to the device interface 41 of the device 4. The device 4 then transfers the specified file to the specified folder, and responds to the server 33 with either OK or NG as the file transfer result. The server 33 responds to the client 23 with either OK or NG as the file transfer result from the device 4.

[0047] The routine maintenance work setting information storage unit 5 stores setting information that can convert between commands defined by the routine maintenance work open API and commands on which the device interface 41 of each device 4 depends.

[0048] FIG. 1 illustrates, as an example, a case in which commands of a routine maintenance work open API used in a request or response to a certain maintenance work are associated with commands used by the device 4. For example, for a certain maintenance work, the device (device A) 4-1 in FIG. 1 uses commands such as "cmd_aa_1," "cmd_aa_2," "cmd_bb_1," etc. In this case, "cmd_aa_1," "cmd_aa_2," "cmd_bb_1," etc. are set as "A commands" used by the device (device A) 4-1.

[0049] The configuration of the routine maintenance work setting information storage unit 5 is not limited to the example of FIG. 1, as long as it is capable of converting commands of the routine maintenance work open API and commands of each device 4 to each other.

[0050] (A-2) Operation of the First Embodiment Next, the processing operation of the maintenance management system 10 according to the embodiment will be described.

[0051] The management server 2 displays the maintenance work for each API number on the display screen of the maintenance terminal 1, and the maintenance person activates the clients 21 to 23 for each API number on the display screen of the maintenance terminal 1.

[0052] For example, the maintenance terminal 1 displays a screen (e.g., a Web screen) related to the routine maintenance work open GUI-API corresponding to each maintenance type of the routine maintenance work open API, and the maintenance work for each API number is displayed on the screen of the maintenance terminal 1. The screen configuration displayed on the maintenance terminal 1 is not particularly limited. For example, the screen may display the API number and / or the name of the maintenance work, allowing the maintainer to select the API number or the name of the maintenance work. In any case, the screen of the maintenance terminal 1 allows the maintainer to select the desired API number or maintenance work. Then, when the maintainer makes a selection on the screen of the maintenance terminal 1, clients 21 to 23 for each corresponding API number are started on the management server 2.

[0053] At this time, the maintenance person may select a target device 4 from among the multiple devices 4 and input data content to be requested from the device 4 on the screen of the maintenance terminal 1. For example, all devices 4-1 to 4-N may be targeted, or some of the devices 4 may be targeted, and in the latter case, the target device 4 may be selectable.

[0054] Also, for example, when a maintainer desires to "Name: Command Entry" for "API Number: 1," the maintainer may be able to input on the screen the command entry destination (for example, the identification information of the target device 4, the port number of the device interface 41 of the device 4, etc.) and the command string of the command to be issued. Also, for example, in the case of "API Number: 2," the maintainer may be able to input on the screen the search start time, search end time, TradID, search string, etc., and in the case of "API Number: 3," the maintainer may be able to input on the screen the transfer source file, transfer destination directory, etc.

[0055] The clients 21 to 23 for each activated API number request, via REST, the activation of the servers 31 to 33 for each corresponding API number on the linked server 3. For example, the client 21 with API number "1" requests, via REST, the activation of the server 31 with API number "1."

[0056] On the linkage server 3, the servers 31 to 33 for each activated API number receive requests defined in the routine maintenance work open API from the corresponding clients 21 to 23. For example, the server 31 with API number "1" receives a request from the client 21 with the corresponding API number "1."

[0057] Then, in the servers 31 to 33 for each API number, the mutual conversion unit 35 converts the request defined in "IN" of the open API for routine maintenance work into a request on which the device 4 depends, and sends the converted request to the equipment interface 41 of the corresponding device 4.

[0058] For example, if the device interface 41 of the device 4 depends on SSH, the mutual conversion unit 35 refers to the routine maintenance work setting information storage unit 5, converts the request command defined in the routine maintenance work open API into an SSH command, and sends it to the corresponding device interface 41 of the device 4. The routine maintenance work setting information storage unit 5 is set so that it can convert into a protocol (command format) that the target device 4 depends on. In other words, it is possible to convert into a protocol (command format) for each model.

[0059] The device 4 returns the result of a request from one of the servers 31 to 33 for each API number to the server 31 to 33 for each API number. For example, the device interface 41 of the device 4 sends the result to the corresponding server 31 to 33 in a dependent command format.

[0060] In the servers 31 to 33 for each API number that receive the results from the device 4, the mutual conversion unit 35 converts the results from the device 4 into a response format defined in "OUT" of the open API for routine maintenance work, and returns the result to the corresponding client 21 to 23 via REST. For example, the mutual conversion unit 35 converts the results from the device 4 into a command response character string format defined in the open API for routine maintenance work, and returns the result to the corresponding client 21 to 23.

[0061] The clients 21 to 23 output the results received from the corresponding servers 31 to 33 onto the screen of the maintenance terminal 1.

[0062] The maintenance person can check the results of the requested maintenance work by checking the results for each API number displayed on the screen of the maintenance terminal 1. Even if the devices 4 are different models, the results of each device 4 can be called up for each API number and displayed on the screen.

[0063] (A-3) Effects of the First Embodiment As described above, according to the first embodiment, the maintenance management system utilizes the open API for routine maintenance work, thereby enabling integrated maintenance and operation of multiple devices present on a network.

[0064] (B) Second embodiment Next, the maintenance management system and the maintenance management method according to the present invention , management server A second embodiment of the maintenance management program will be described in detail with reference to the drawings.

[0065] (B-1) Basic concept The problems to be solved by the maintenance management system of the second embodiment and the basic technical concepts of the means for solving the problems will be described below.

[0066] Conventionally, when there are multiple routine maintenance tasks, the maintenance personnel must perform all of them, which poses a problem that takes time depending on the amount of work (referred to here as the "first problem"). For example, consider a case where one system uses multiple devices, and multiple routine maintenance tasks are required for each device. In this case, conventionally, the maintenance personnel must perform multiple routine maintenance tasks for each device, thereby completing routine maintenance tasks for all devices. This places a heavy workload on the maintenance personnel and takes a long time to complete the tasks.

[0067] Furthermore, there is a risk of some kind of problem occurring with the equipment, regardless of whether it is day or night. Therefore, when a failure occurs, maintenance personnel must carry out maintenance work to identify the failure, which creates a heavy workload (herein referred to as the "second problem").

[0068] In view of the above-mentioned problems, the second embodiment attempts to solve the first problem by defining the execution of multiple routine maintenance tasks as maintenance scenarios and enabling the routine maintenance tasks to be executed on a scenario-by-scenario basis. The second embodiment also attempts to solve the second problem by monitoring for the occurrence of a failure and enabling the execution of routine maintenance tasks corresponding to the failure when the failure occurs.

[0069] (B-2) Configuration of the Second Embodiment The overall configuration of the maintenance management system 10B of the second embodiment is basically the same as that of the maintenance management system 10 of the first embodiment. However, since the functions of the management server 2 of the second embodiment are different from those of the management server 2 of the first embodiment, the characteristic functions of the second embodiment will be described in detail centering around them.

[0070] FIG. 4 is an overall configuration diagram showing the overall configuration of the maintenance management system according to the second embodiment.

[0071] In FIG. 4, the maintenance management system 10B according to the second embodiment includes a maintenance terminal 1, a management server 2, a cooperation server 3, a device 4 to be maintained, and a routine maintenance work setting information storage unit 5.

[0072] On the cooperation server 3 side, each system has a system name, and servers 3m (M is a number indicating the API number, 1 < m < M) that are called for each API number of the open API for routine maintenance work are implemented.

[0073] For example, in FIG. 4, assume there is a system with the system name (system identification information) of "System A" that operates using devices A, B,..., N. The cooperation server 3-1 is a server that performs maintenance work on devices A, B,..., N used in "System A". The cooperation server 3-1 has servers 3m that are called for each API number of the open API for routine maintenance work.

[0074] Similar to the first embodiment, for each server 3m corresponding to an API number, it receives a request for an interface for maintenance work specialized for the API number from the client 2m, and performs a process of converting the request into a request for an interface depending on each device 4. The server 3m and the client 2m implement REST in the same manner as in the first embodiment. Note that the processing of the server 3m and the client 2m is basically the same as the processing of the first embodiment, and detailed description is omitted because it would be repetitive.

[0075] Similar to link server 3-1, link server 3-2 performs maintenance work on one or more devices 4 used by system B, and link server 3-X (X is an integer) performs maintenance work on one or more devices 4 used by system X. The types and number of devices 4 used by systems A to X, as well as the combination of devices 4, may differ from system to system. Therefore, link server 3 (3-1 to 3-X) implements servers 31 to 3n according to the types, number, combination, etc. of devices 4 used by the corresponding systems A to X.

[0076] 4, the management server 2 includes clients 21 to 2M for each API number, a trap monitor 201, a maintenance scenario registration and execution unit 202, a routine maintenance work execution unit 203, and a maintenance scenario storage unit 204.

[0077] When some kind of failure occurs in system A, B, or X that is operating using device 4, the trap monitor 201 acquires information about the failure that has occurred. For example, the trap monitor 201 can apply SNMP-Trap monitoring. Examples of failures include the failure or restart of a server that performs highly reliable processing such as session control for voice, data, etc., a hardware failure in a server or optical transmission device, or congestion caused by concentrated access to an Internet line or a telephone line. Of course, failures are not limited to these, and any failure that may occur in device 4 as a network device is also considered.

[0078] For example, the trap monitoring unit 201 can acquire fault information for each system from a management system or fault detection system operated by each system, such as system A, and monitor information about faults that have occurred in each system. As another method, the trap monitoring unit 201 may collect detailed call record information, such as a CDR, for each system, and perform machine learning independently using the collected data to determine that a fault has occurred when it can be determined that an abnormality has occurred. In other words, the trap monitoring unit 201 may acquire fault information from an external system, such as a management system for each system, or may determine an abnormality (i.e., a state that is different from normal) using processing such as original machine learning, and monitor for a fault or its precursor.

[0079] When the trap monitoring unit 201 receives information indicating the status of a monitored system from the monitored system, it determines whether the information matches preset monitoring conditions, and sends an alert including an alarm trigger ID (for example, an SNMP-Trap OID (object ID)) indicating the matching item to the maintenance scenario registration and execution unit 202. This is so that when the trap monitoring unit 201 acquires and detects information that a failure has occurred in a certain system, the maintenance scenario registration and execution unit 202 can read out the maintenance scenario associated with the monitoring trigger ID. This makes it possible to automatically perform routine maintenance work on each device 4 in the failed system according to the maintenance scenario of the failed system (i.e., the maintenance scenario associated with the monitoring trigger ID).

[0080] The maintenance scenario registration and execution unit 202 has a registration unit 221 that has a plurality of routine maintenance tasks and registers maintenance scenarios for performing these plurality of routine maintenance tasks for each system, and an execution unit 222 that executes the maintenance scenarios for each system. In other words, the maintenance scenario registration and execution unit 202 registers maintenance scenarios that determine the types and order of routine maintenance tasks to be performed on one or more devices 4 used by the system, and executes the maintenance scenarios for each system for each system.

[0081] The maintenance scenario storage unit 204 stores maintenance scenarios for each system. The configuration of the maintenance scenarios stored in the maintenance scenario storage unit 204 will be described later, but the maintenance scenario storage unit 204 stores maintenance scenarios each having a scenario config and a routine maintenance work config. The scenario config is scenario setting information such as the system name of the system to which this maintenance scenario is applied, the routine maintenance work to be performed, and when to perform it. The routine maintenance work config is detailed setting information related to the routine maintenance work set in the scenario config. The configuration of such maintenance scenarios will be described in detail in the section on operation.

[0082] The routine maintenance work execution unit 203 refers to the maintenance scenario storage unit 204 and issues instructions to clients 21 to 2M having API numbers defined in the open API for routine maintenance work in accordance with the maintenance scenario of each system, to execute maintenance work for each API number. By instructing clients 21 to 2M to execute maintenance work, the routine maintenance work execution unit 203 can request servers 31 to 3M of the linkage server 3 of each system to perform maintenance work using the open API for routine maintenance work, and the maintenance work of the corresponding device 4 can be automatically performed.

[0083] (B-3) Operation of the Second Embodiment Next, the processing operations in the maintenance management system 10B according to the second embodiment will be described with reference to the drawings.

[0084] (B-3-1) Overall processing First, the overall process flow for executing routine maintenance work in the maintenance management system 10B will be described.

[0085] In response to an input instruction from the maintainer, the maintenance terminal 1 requests the maintenance scenario registration and execution unit 202 of the management server 2 to display a maintenance scenario screen 12 in order to register a maintenance scenario.

[0086] The maintenance scenario registration and execution unit 202 has a registration unit 221 and an execution unit 222. The registration unit 221 provides the maintenance scenario screen 12 to the maintenance terminal 1 so that the maintenance scenario can be registered. The registration unit 221 acquires the created maintenance scenario through the maintenance scenario screen 12 provided to the maintenance terminal 1. The registration unit 221 then registers this maintenance scenario in the maintenance scenario storage unit 204.

[0087] As will be described later, multiple routine maintenance tasks are defined (set) in the maintenance scenario. In addition, the conditions for executing each maintenance scenario are set to either manual execution, automatic execution triggered by an alarm, or scheduled automatic execution.

[0088] When manual execution is set, the maintenance terminal is operated by a maintenance person to start up an execution unit 222, which reads out a maintenance scenario and starts up a routine maintenance work execution unit 203 corresponding to the maintenance scenario.

[0089] When alarm-triggered automatic execution is set, the trap monitoring unit 201 detects an alarm and activates the execution unit 222, which reads out the maintenance scenario corresponding to the alarm trigger ID included in the alarm from the trap monitoring unit 201, and the execution unit 222 activates the routine maintenance work execution unit 203 corresponding to the maintenance scenario.

[0090] When scheduled automatic execution is set, a start date (which may include time) is also set. When the time to start execution of a maintenance scenario in the maintenance scenario storage unit 204 arrives, the execution unit 222 reads out that maintenance scenario and activates the routine maintenance work execution unit 203 corresponding to that maintenance scenario.

[0091] Furthermore, the routine maintenance work execution unit 203 started by the execution unit 222 starts the client 2m (21 to 2M).

[0092] Here, multiple routine maintenance tasks are defined (set) in the maintenance scenario for each system, as will be described later. Furthermore, the maintenance scenario also sets the API number of each routine maintenance task and the host name of the target device 4.

[0093] The routine maintenance work execution unit 203 sequentially reads out a plurality of routine maintenance works defined in the maintenance scenario. Then, the routine maintenance work execution unit 203 starts up the client 2m corresponding to the API number of the routine maintenance work to be executed this time. The client 2m corresponding to the API number is started up in order according to the API numbers of the routine maintenance works set in the maintenance scenario.

[0094] The client 2m requests the corresponding server 3m in the linkage servers 3-1 to 3-X to start up via REST. The server 3m is started up by the client 2m. The server 3m converts the request defined in the routine maintenance work open API received at the time of startup into a device-dependent maintenance work interface and sends the converted request to the device 4.

[0095] The server 3m receives the result of the request returned from the device 4 and converts the result into "OUT" of the routine maintenance work open API. The server 3m returns the converted result to the client 2m via REST.

[0096] In the management server 2, the client 2m transmits the maintenance results received from the server 3m to the maintenance terminal 1, and the maintenance terminal 1 outputs the results on the screen. The maintenance person can check the results on the screen of the maintenance terminal 1. This allows the maintenance person to check the results of the requested maintenance scenario.

[0097] Although the example shown here is one in which the maintenance terminal 1 displays the maintenance results on the screen in real time, the maintenance scenario registration and execution unit 202 can also associate the maintenance results with a maintenance scenario and store them in the maintenance scenario storage unit 204. Therefore, the maintenance results can be searched for at a later date, not just displayed in real time.

[0098] Here, we will explain the operation when alarm-triggered automatic execution is set in the maintenance scenario for each system. When a system failure occurs, routine maintenance work is executed for that system according to the maintenance scenario. This is the processing when a failure occurs.

[0099] Here, alarm-triggered automatic execution is an operating mode in which, when the trap monitoring unit 201 detects a system failure, routine maintenance work defined in a maintenance scenario corresponding to the failure (a maintenance scenario associated with an alarm-triggered ID) is executed on the system in which the failure occurred.

[0100] When alarm-triggered automatic execution is set in a maintenance scenario, an alarm trigger ID is also set at the same time. The alarm trigger ID can be identification information that identifies an item related to a fault (monitoring), such as an OID (object ID) for SNMP-Trap monitoring. The execution unit 222 then reads out a maintenance scenario for which the alarm trigger ID included in the alarm from the trap monitor 201 is set, and starts the routine maintenance work execution unit 203 corresponding to the maintenance scenario for which the alarm trigger ID is set.

[0101] Thus, when a failure such as session control or line congestion occurs in a system, maintenance work must be performed on each device 4 in the system to identify the cause. Furthermore, failures can occur at any time of the day or night, and even in these days of a labor shortage, maintenance work must be performed as before. In light of this background, this embodiment enables efficient monitoring and efficient execution of maintenance work.

[0102] (B-3-2) Registration of maintenance scenarios Next, the operation of creating and registering a maintenance scenario for each system will be described.

[0103] Fig. 5 is an explanatory diagram illustrating an example of the configuration of a maintenance scenario according to the second embodiment. Fig. 6 is a screen diagram showing an example of a registration screen for a maintenance scenario according to the second embodiment.

[0104] As shown in Fig. 5, a maintenance scenario has a scenario configuration and a routine maintenance work configuration. A maintenance person can create a maintenance scenario for each system through the maintenance scenario registration screen shown in Fig. 6, which is displayed on the display unit of the maintenance terminal 1.

[0105] Scenario Config is setting information for a maintenance scenario. As illustrated in FIG. 5, Scenario Config has the following items: "Scenario Name," "System Name," "Routine Maintenance Work Information," "Target Device," "Execution Start Time," "Execution End Time," and "Execution Result." In this way, Scenario Config defines setting information such as which system this maintenance scenario is to be executed for, which routine maintenance work is to be executed for which device 4, etc. Scenario Config also stores the results of maintenance performed on the device 4. To identify when this maintenance result was executed, the results are associated with the system name, device, execution start time, execution end time, the number of the executed routine maintenance work, etc. Note that the items in Scenario Config are not limited to those illustrated in FIG. 5.

[0106] The "scenario name" is the value set on the screen when registering, modifying, or duplicating a maintenance scenario. In other words, the scenario name can be thought of as identification information for identifying a maintenance scenario.

[0107] "System name" is the name of the monitoring system selected on the screen when registering, changing, or duplicating a maintenance scenario. In other words, "system name" is the name of the system to which the maintenance system is applied. It is not limited to the system name (system name), and can also be system identification information such as the system number or ID, as long as it can identify the system.

[0108] "Routine maintenance work information" is information about routine maintenance work that is incorporated into a maintenance scenario. "Routine maintenance work information" is arranged in accordance with the number of routine maintenance work that is set on the screen when registering, changing, or duplicating a maintenance scenario. "Routine maintenance work information" has a "routine maintenance work number list" that contains the API number of each of the multiple routine maintenance work that is set. This "routine maintenance work number list" will be explained in detail when explaining the routine maintenance work configuration.

[0109] "Target device" is the host name of the device that is the target of this maintenance scenario execution.

[0110] "Execution start time" is the time when this maintenance scenario starts to be executed, and "execution end time" is the time when this maintenance scenario ends to be executed. "Execution result" is the result of maintenance performed according to the maintenance scenario. The execution result is the maintenance result of each device for each routine maintenance task.

[0111] Next, the routine maintenance work configuration shown in FIG. 5 will be described. The routine maintenance work configuration is detailed setting information related to the routine maintenance work set in the scenario configuration of the maintenance scenario. As shown in FIG. 5, the routine maintenance work configuration has the items "Work number," "API number," and "Execution process." In this way, the routine maintenance work configuration sets the API number of the routine maintenance work to be executed on the device 4, and the commands, data, information, etc. requested from the device 4 side (server 3m side) during the maintenance work. When there are multiple routine maintenance works, a routine maintenance work configuration is created and registered for each routine maintenance work.

[0112] The "job number" is a number that is set in advance for each routine maintenance job. The "job number" is different from the API number defined in the open API for routine maintenance jobs, and is a number that is set to identify the routine maintenance job number.

[0113] "API number" is the number defined in the open API for routine maintenance work. For example, "API number: 1" is "Command input (single)", "API number: 2" is "Alarm reception", and "API number: 3" is "File transfer".

[0114] "Execution process" is information requested by the routine maintenance work open API.

[0115] For example, when issuing a command to the device 4 (server 3m) using "API number: 1," the character string of the command is set in advance. Alternatively, the destination to which the command is to be issued may be set. The character string of this command can be set by the administrator via the registration screen.

[0116] For example, when checking whether a specific alarm has been received on the device 4 (server 3m) side with "API number: 2," an ID that identifies the alarm is set. In addition, alarm search start time, search end time, generating device, search string, etc. may also be set.

[0117] Furthermore, for example, when transferring a file to the device 4 (server 3m) side using "API number: 3", the destination directory is specified by a full path. In addition, the source file may be set.

[0118] As described above, the maintenance scenario has a scenario configuration and a routine maintenance work configuration, and the maintenance scenario is set via the maintenance scenario registration screen of FIG.

[0119] 6, the maintenance scenario registration screen 500 has a scenario name input section 501, a system name input section 502, a routine maintenance work setting section 503, a scenario execution condition setting section 504, a target device input section 505, a routine maintenance work setting list display section 506, a register button 507, a cancel button 508, and a change button 540. Note that the registration screen 500 is not limited to that shown in FIG. 6, and the input sections displayed on the registration screen 500 are not limited to those shown in FIG. 6.

[0120] A scenario name input section 501 and a system name input section 502 allow the scenario name and the system name to be input, for example, by text input.

[0121] The routine maintenance work setting section 503 is a section for setting routine maintenance work to be defined in a maintenance scenario. For example, in the example of Fig. 6, routine maintenance work that can be selected using a pull-down menu is displayed in a list 510, and the routine maintenance work is selected from the list 510. Note that the routine maintenance work setting section 503 is not limited to a pull-down menu as long as the routine maintenance work can be selected and set.

[0122] When a routine maintenance task is set in the routine maintenance task setting section 503 (for example, by selecting the "Add" button, the routine maintenance task selected at that time can be set), the name of the routine maintenance task (i.e., the routine maintenance task name) and task number are read out and displayed in the routine maintenance task setting list display section 506 described later.

[0123] The routine maintenance work setting unit 503 can set a plurality of routine maintenance works by setting the routine maintenance works one by one in order in the list 510. In other words, it is possible to register a maintenance scenario consisting of a plurality of routine maintenance works.

[0124] When multiple routine maintenance tasks are set, the order in which they are set will be the order in which the routine maintenance tasks are executed. If there is some problem with the order in which the routine maintenance tasks of a maintenance scenario are executed in order, the execution order can be corrected (changed) by changing the order in which the routine maintenance tasks are set in the list 510 of the routine maintenance task setting unit 503.

[0125] The scenario execution condition setting unit 504 can set conditions for executing the maintenance scenario. The scenario execution condition setting unit 504 can set any of manual execution, alarm-triggered automatic execution, and scheduled automatic execution.

[0126] When setting alarm-triggered automatic execution in the scenario execution condition setting unit 504, an alarm trigger ID is also set. This makes it possible to read out a maintenance scenario for which an alarm trigger ID is set when an alarm is detected by the trap monitoring unit 201. The trap monitoring unit 201 receives information indicating the state of the monitored object, detects an alarm containing an item (alarm trigger ID) that matches the pre-set monitoring conditions, and activates the maintenance scenario registration and execution unit 202. If multiple items match, the scenario execution unit 202 is instructed to execute multiple maintenance scenarios. It is possible to register not just one type of maintenance scenario for a single system, but multiple types of maintenance scenarios corresponding to multiple alarm trigger IDs.

[0127] The target device input unit 505 inputs the target device for which the specified routine maintenance work is to be performed. The target device input unit 505 inputs the host name of the device 4 by text input. Alternatively, if it is possible to link with a database that associates each device 4 existing in the system with the host name of each device 4, the target device input unit 505 may link with the database to enable selection of the device 4 for each system.

[0128] The routine maintenance work setting list display section 506 is a section that displays a list of information on specified routine maintenance work. In Fig. 6, for example, items include "No." indicating the work number of the routine maintenance work, "routine maintenance work name," "start time" indicating the start time of execution, "end time" indicating the end time of execution, and "reference to detailed information" for making it possible to refer to other setting information. Note that the items displayed in the routine maintenance work setting list display section 506 are not limited to these.

[0129] The routine maintenance work setting list display section 506 displays the work number and routine maintenance work name of the routine maintenance work selected in the routine maintenance work setting section 503. When multiple routine maintenance works are selected in the routine maintenance work setting section 503, the multiple routine maintenance works are displayed in the routine maintenance work setting list display section 506. The order in which they are displayed is the order in which they were selected in the routine maintenance work setting section 503.

[0130] That is, when a maintenance scenario for each system is executed, the routine maintenance work execution unit 203 executes the routine maintenance works in the order selected in the routine maintenance work setting unit 503 .

[0131] Furthermore, in the routine maintenance work setting list display section 506, the item "Reference detailed information" has a "Reference" button for each routine maintenance work. When the maintenance person selects "Reference" for each routine maintenance work, a screen 520 is displayed for setting detailed setting information for the routine maintenance work. On this screen 520, information regarding the "API number" and "execution process" of the routine maintenance work configuration can be set.

[0132] When the maintainer selects the register button 507, the entered maintenance scenario is registered. When the maintainer selects the change button 540, the changed maintenance scenario is registered. When the maintainer selects the cancel button 508, the maintenance scenario is deleted.

[0133] (B-4) Effects of the Second Embodiment As described above, according to the second embodiment, the automatic execution method of the routine maintenance work open API allows a plurality of routine maintenance works to be executed at once, thereby reducing the burden on the maintenance worker.

[0134] Furthermore, according to the second embodiment, by associating an alarm with a maintenance scenario, routine maintenance work can be performed when a failure occurs, enabling maintenance operations that reduce the burden of nighttime work.

[0135] (C) Other embodiments Although various modified embodiments have been mentioned in the above-described embodiment, the present invention can also be applied to the following modified embodiments.

[0136] (C-1) In the above-described embodiment, for the sake of convenience, the case where the clients 21 to 23 and the servers 31 to 33 are started for each API number is illustrated. However, the clients and servers are not limited to being separated by API number.

[0137] For example, when a maintenance person performs maintenance operations such as setting up devices 4 or monitoring their status on the screen of the maintenance terminal 1, it is sufficient if the results of each device 4 can be displayed by maintenance identification information such as a maintenance identifier, by maintenance type, or by maintenance work name. Therefore, clients and servers may be divided by maintenance type or by maintenance work name.

[0138] (C-2) In the above-described embodiment, an example was given of a case where servers 31 to 33 for each API number on the linked server 3 convert "IN" or "OUT" defined in the open API for routine maintenance work and a request or response in the command format on which the device 4 depends, but this is not limited to this.

[0139] For example, the clients 21 to 23 on the management server 2 may be able to access the routine maintenance work setting information storage unit 5, and of the "IN" and "OUT" of the routine maintenance work open API, the "OUT" may be converted and displayed on the screen of the maintenance terminal 1. Note that the conversion of "IN" may also be performed by the clients 21 to 23, but since conversion is required for each model of device 4, it is preferable to perform this on the server 31 to 33 side.

[0140] Also, for example, the clients 21 to 23 may provide the routine maintenance work setting information stored in the routine maintenance work setting information storage unit 5 to the maintenance terminal 1 to store it, and the maintenance terminal 1 may convert the parameters of the "OUT" definition into a response in the command format of each device 4 and display it on the screen. Conversely, the maintenance terminal 1 may convert the response in the command format of each device 4 into parameters of the "OUT" definition and display it on the screen.

[0141] (C-3) As illustrated in Figure 3, servers 31 to 33 for each API number on the linked server 3 can be connected to an integrated monitoring system 6 that monitors the maintenance status of multiple devices 4, making it possible to maintain and manage the devices 7 monitored by the integrated monitoring system 6.

[0142] In this case, too, by using the open API for routine maintenance work described in the above embodiment, the maintenance information (results) of each device 7 monitored by the integrated monitoring system 6 can be called up and displayed on the screen of the maintenance terminal 1.

[0143] (C-4) In the second embodiment described above, the management server 2 executes the various functions of the trap monitoring unit 201, the maintenance scenario registration and execution unit 202, the routine maintenance work execution unit 203, and the client 2m. However, the various functions executed by the management server 2 do not have to be implemented on the same physical server, and may be distributed across multiple physically different servers. [Explanation of symbols]

[0144] 1...maintenance terminal, 2...management server, 3...linkage server, 4 (4-1 to 4-N) device, 5...routine maintenance work setting information storage unit, 6...integrated monitoring system, 7...device, 10, 10A and 10B...maintenance management system, 21 to 23...client, 31 to 33...server, 35...mutual conversion unit, 41...device interface, 201...trap monitoring unit, 202...maintenance scenario registration and execution unit, 203...routine maintenance work execution unit, 204...maintenance scenario storage unit.

Claims

1. a first server connected to a maintenance terminal; a second server connected to a plurality of target devices; Equipped with The first server a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server, and transmits a response result of each of the plurality of target devices to the common maintenance request, which response result is acquired via the second server, to the maintenance terminal; The second server a response unit for each maintenance type that converts the common maintenance request from the common request unit for each maintenance type into a format that can be handled by each of the plurality of target devices and transmits the converted common maintenance request to each of the plurality of corresponding target devices, and also converts a response result from each of the plurality of target devices into the format of the common request unit and transmits the converted response result to the corresponding common request unit; The first server a maintenance scenario storage unit configured to store, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set; a maintenance execution unit that causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each of the target systems; have A maintenance management system characterized by:

2. The first server 2. The maintenance management system according to claim 1, further comprising a registration unit that sets, for each target system through the maintenance terminal, the common maintenance requests to be performed on each of the plurality of target devices that the target system has in sequence, sets execution processing for each of the plurality of common maintenance requests that have been set, and registers the maintenance scenario for the target system.

3. the first server includes a fault monitoring unit that monitors the occurrence of a fault in the target system; The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests in accordance with the maintenance scenario associated with a fault notification from the fault monitoring unit that detected the fault.

3. The maintenance management system according to claim 1 or 2.

4. a first server connected to the maintenance terminal includes a common request unit for each maintenance type and a maintenance execution unit; a second server connected to a plurality of target devices, the second server having a response unit for each maintenance type; the common request unit transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server; the corresponding response unit converts the common maintenance request from the common request unit for each maintenance type into a format that can be handled by each of the plurality of target devices, and transmits the converted common maintenance request to each of the plurality of corresponding target devices; the response unit converts the response result from each of the plurality of target devices into a format of the common request unit and transmits it to the corresponding common request unit; the common request unit transmits to the maintenance terminal a response result of each of the plurality of target devices to the common maintenance request, the response result being acquired from the response unit; The maintenance execution unit of the first server a maintenance scenario storage unit that stores, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed on each of the plurality of target devices of the target system are set, and causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each target system; A maintenance management method characterized by:

5. a management server that cooperates with a link server connected to a plurality of target devices and provides maintenance information for each of the plurality of target devices to a maintenance terminal, a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server, and transmits a response result of each of the plurality of target devices to the common maintenance request, which is acquired via the linking server, to the maintenance terminal; a maintenance scenario storage unit configured to store, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set; a maintenance execution unit that causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each of the target systems; A management server comprising:

6. The management server according to claim 5, further comprising a registration unit that sets, for each target system through the maintenance terminal, the common maintenance requests to be performed on each of the plurality of target devices possessed by the target system in sequence, sets execution processing for each of the plurality of common maintenance requests that have been set, and registers the maintenance scenario for the target system.

7. a failure monitoring unit that monitors the occurrence of a failure in the target system; The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests in accordance with the maintenance scenario associated with a fault notification from the fault monitoring unit that detected the fault.

7. The management server according to claim 5 or 6.

8. A maintenance management program that cooperates with a cooperation server connected to a plurality of target devices and provides maintenance information for each of the plurality of target devices to a maintenance terminal, Computer, a common request unit for each maintenance type that transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server, and transmits a response result of each of the plurality of target devices to the common maintenance request, which is acquired via the linking server, to the maintenance terminal; a maintenance execution unit that references a maintenance scenario storage unit that stores, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed on each of the plurality of target devices in the target system are set, and causes the common request unit to execute the plurality of common maintenance requests set in the maintenance scenario at an execution time set in the maintenance scenario for each target system; A maintenance management program characterized by functioning as follows.

9. Computer, The maintenance management program described in claim 8, characterized in that, for each target system, through the maintenance terminal, the common maintenance requests to be performed on each of the multiple target devices possessed by the target system are set in sequence, execution processing for each of the multiple common maintenance requests that have been set is set, and the program functions as a registration unit that registers the maintenance scenario for the target system.

10. Computer, a failure monitoring unit that monitors the occurrence of a failure in the target system; The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests in accordance with the maintenance scenario associated with a fault notification from the fault monitoring unit that detected the fault.

10. The maintenance management program according to claim 8 or 9.

Images