JP2023017682A - Maintenance management system, maintenance management method, management server, cooperation server, and maintenance management program - Google Patents

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

The present invention relates to a maintenance management system, a maintenance management method, and a maintenance management program, and can be applied, for example, to a maintenance management system that maintains and manages various devices connected to an IP (Internet Protocol) network using a common WEB interface. is.

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

In general, maintenance management such as device settings and monitoring of device status uses a dedicated device interface for each model. are doing. Note that the device interface mentioned here is an interface necessary for maintenance work, and includes, for example, a UI (User Interface), an API (Application Programming Interface), a communication interface, and the like.

However, since the device interface differs for each device model, maintenance workers need to perform maintenance work that differs for each model, which increases the burden on the maintenance worker. Therefore, it is desired to be able to perform maintenance management for multiple types of apparatuses in common.

Conventionally, there are, for example, Patent Literatures 1 and 2, etc., as conventional techniques for providing maintenance and operation using a web-based API.

In Patent Document 1, a server provides a common Web API to a terminal device, the server receives an operation request regarding a cash handling machine from the terminal device, converts the request into an interface that the cash handling machine can accept, Throw it into the cash machine. The common Web API is defined as "common" in that it plays a role of absorbing interface differences due to differences in cash processing machine models.

Patent Literature 2 describes a maintenance work that supports maintenance work by visualizing history information of a web system in order to shorten the lead time to the location of the cause when analyzing the cause of an information system failure in the maintenance work of the information system. A business support system is described.

JP 2018-128830 A JP 2011-192230 A

However, the technique described in the above-mentioned Patent Document 1 has a problem that the interface of various devices on the IP network cannot be used because the maintenance target is specified as the cash processing machine.

Further, the technique described in Patent Document 2 is a maintenance operation interface that specializes in adding history information related to information system failures, and is used as an interface for various devices on an IP network, similar to Patent Document 1. I have a problem that I can't.

In order to solve the above-described problems, the present invention provides a maintenance management system, maintenance management method, and maintenance management capable of performing integrated maintenance and operation of routine maintenance work generally held by various devices on a network. A program is sought.

In order to solve such a problem, a maintenance management system according to a first aspect of the present invention comprises a first server connected to a maintenance terminal and a second server connected to a plurality of target devices. The server transmits a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server, and transmits the response results of each of the plurality of target devices to the common maintenance request obtained through the second server and a common request unit for each maintenance type, which is transmitted to the maintenance terminal, and the second server 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. conversion and transmission to each of a plurality of corresponding target devices, and conversion of the response result from each of the plurality of target devices into the format of the common request section and transmission to the corresponding common request section. It is characterized by having a response part for each.

In a maintenance management method according to a second aspect of the present invention, a first server connected to a maintenance terminal has a common request part for each maintenance type, and a second server connected to a plurality of target devices has a maintenance a response unit for each type, wherein 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, and the corresponding response unit includes a common request unit for each maintenance type converts the common maintenance request from the , into the format of the common request part and transmits to the corresponding common request part, and the common request part transmits the response results of each of the plurality of target devices to the common maintenance request, which are obtained from the response part, to the maintenance terminal. characterized by

A third aspect of the present invention is a management server that cooperates with a cooperation server connected to a plurality of target devices and provides maintenance information of each of the plurality of target devices to a maintenance terminal, wherein and a common request unit for each maintenance type that transmits to the maintenance terminal a response result of each of the plurality of target devices to the common maintenance request, which is obtained through the cooperation server. It is characterized by

A fourth aspect of the present invention is a cooperation server that cooperates with a management server that is connected to a maintenance terminal to obtain maintenance information of a plurality of connected target devices, from a common request unit for each maintenance type on the management server: converting the acquired common maintenance request for each of the plurality of target devices into a format that each of the plurality of target devices can handle, and transmitting the request to each of the corresponding plurality of target devices; It is characterized by having a response part for each maintenance type, which converts the response result from the

A fifth aspect of the present invention is a maintenance management program that cooperates with a link server connected to a plurality of target devices to provide a maintenance terminal with maintenance information for each of the plurality of target devices, wherein the computer receives information from the maintenance terminal. Common for each maintenance type, in which a common maintenance request for each of a plurality of target devices is sent to the cooperation server, and a response result of each of the plurality of target devices to the common maintenance request obtained through the cooperation server is sent to the maintenance terminal. It is characterized by functioning as a request part.

A sixth aspect of the present invention is a maintenance management program for acquiring maintenance information of a plurality of connected target devices in cooperation with a management server connected to a maintenance terminal, wherein The common maintenance request for each of the plurality of target devices acquired from the common request unit is converted into a format that can be handled by each of the plurality of target devices, and is transmitted to each of the corresponding plurality of target devices. It is characterized by functioning as a response section for each maintenance type that converts the response result from each target device into the format of the common request section and transmits it to the corresponding common request section.

According to the present invention, it is possible to perform integrated maintenance and operation of routine maintenance work generally held by various devices on a network.

1 is an overall configuration diagram showing the overall configuration of a maintenance management system according to an embodiment; FIG. FIG. 4 is an explanatory diagram for explaining the definition of an open API for routine maintenance work according to the embodiment; It is a whole block diagram which shows the whole structure of the maintenance management system based on deformation|transformation embodiment. FIG. 11 is an overall configuration diagram showing the overall configuration of a maintenance management system according to a second embodiment; FIG. 11 is an explanatory diagram illustrating a configuration example of a maintenance scenario according to the second embodiment; FIG. FIG. 11 is a screen diagram showing an example of a maintenance scenario registration screen according to the second embodiment;

(A) First Embodiment Hereinafter, a first embodiment of a maintenance management system, a maintenance management method, and a maintenance management program according to the present invention will be described in detail with reference to the drawings.

In this embodiment, for example, a communication protocol such as HTTP or HTTPS is used to define a Web API (application program interface) for calling routine maintenance work generally possessed by various devices on an IP network from each device. A system provides the Web API described above. Here, this Web API is called "open API for routine maintenance work".

By utilizing the open API for routine maintenance work, the maintenance management system can call up information about maintenance work from devices that constitute a plurality of systems, and can maintain and operate each device in an integrated manner.

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

1, a maintenance management system 10 according to the embodiment includes a maintenance terminal 1, a management server 2, a link server 3, devices 4 (4-1 to 4-N; N is a positive integer), and routine maintenance work setting information storage. It has part 5. A maintenance management system 10 illustrated in FIG. 1 is connectable to an IP network.

The devices 4 (4-1 to 4-N) are devices subject to maintenance control, and devices connectable to the IP network. Devices 4 (4-1 to 4-N) can be various types of devices 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 is represented by SSH (Secure Shell), telnet, etc. Works with commands, etc.

The maintenance terminal 1 is a terminal operated by a maintenance person, and performs maintenance control such as setting and status monitoring of the devices 4 (4-1 to 4-N). The maintenance terminal 1 can be a personal computer, a smart phone, 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.

For example, the maintenance terminal 1 exchanges Web information corresponding to the open API for routine maintenance work one-to-one with the management server 2 using the Web browser function, and uses the open API for routine maintenance work provided by the cooperation server 3. or run pre-installed routine maintenance work application software (also referred to as a "maintenance work application") to utilize the routine maintenance work open API. The Web information API provided by the management server 2 to the maintenance terminal 1 and having a one-to-one correspondence with the regular maintenance work open API is called a regular maintenance work open GUI-API. In other words, the maintenance terminal 1 can use the open GUI-API for regular maintenance work provided by the management server 2 by using a Web browser, a maintenance work application, or the like.

The maintenance terminal 1 is connected to the management server 2, displays a screen of 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 maintenance person. Then, the maintenance terminal 1 sends a request including maintenance identification information indicating the maintenance work selected on the screen (in this embodiment, as an example, "API number") via the open GUI-API for definition maintenance work. to the management server 2. Further, the maintenance terminal 1 acquires maintenance information of 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 4-N maintenance information screen is displayed on the display unit.

In other words, the maintenance terminal 1 requests the management server 2 for integrated maintenance information of a plurality of devices 4 on the command screen displayed on the display unit, and acquires information of each device 4 related to the requested maintenance. and display it on the display.

The management server 2 is a server that calls the system on the cooperation server 3 side using, for example, 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, the client with API number “1” is described as client 21 or the like. Each of the clients 21 to 23 displays the maintenance work for each API number on the display section of the maintenance terminal 1. FIG.

The cooperation server 3 is a server that is called from the management server 2 by, for example, HTTP or HTTPS. That is, the cooperation server 3 implements servers 31 to 33 for each API number for each client for each API number. In the following description, for example, the server with API number "1" is described as server 31 or the like.

The clients 21 to 23 and the servers 31 to 33 are associated with each API number, and the client and server for each API number are paired to exchange data. That is, the clients 21 to 23 and the servers 31 to 33 transmit and receive data specific to maintenance work defined by the open API for routine maintenance work.

Also, the servers 31 to 33 for each API number have a mutual conversion unit 35 that converts between requests defined by the open API for routine maintenance work and requests to 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, the server 31 to 33 receives the request for a device interface 41 depending on each device 4. It converts it into a request, and transmits the converted request to the device interface 41 of each device 4 .

Various configurations can be applied to the mutual conversion unit 35. For example, the request (or response) defined by the open API for routine maintenance work and the request (or response) of the device interface 41 on which each device 4 depends are supported. Refer to the table and convert. For example, it is assumed that the correspondence table is stored in the routine maintenance work setting information storage unit 5 . Note that a separate correspondence table may be provided independently.

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.

Further, in this embodiment, a case where the clients 21 to 23 and the servers 31 to 33 exchange data using the HTTP or HTTPS communication protocol is exemplified. Not limited.

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

In FIG. 2, the routine maintenance work open API is a common interface that is generally required to maintain and operate the device 4. Here, examples of maintenance work names include command input, alarm reception, file transfer, etc. The case is exemplified. “IN” and “OUT” define common interface parameters for each API number (or each maintenance work).

The open API for routine maintenance work includes "API number", "name" indicating the name of the maintenance work, "outline" indicating the outline of the maintenance work, "IN" indicating the type of input (received) data, output (transmit ) has an item “OUT” indicating the type of data to be processed. Items are not limited to these, and other items may be added.

The routine maintenance work open API is used with a communication protocol such as HTTP or HTTPS in order to make it available for the device 4 on the IP network. Also, in order to facilitate implementation by the clients 21 to 23 on the calling side and the servers 31 to 33 on the called side, the routine maintenance work open API shall conform to REST. That is, for example, it is created in a data format such as JSON (Javascript Object Notation).

"API number: 1" defines maintenance work with "name: command input". The outline of the maintenance work of "Name: Command input" is defined as "Overview: Execute the specified command and return the response", and "IN" defines "Command input destination, command string". and "OUT" defines the format of the "command response character string".

For example, in the management server 2 , the client 21 with the API number “1” transmits the command input destination and the command character string to the server 31 with the API number “1” of the cooperation server 3 . A command input destination can be a specific port number or the like in each device 4 . In this case, the server 31 converts the command into a command that can be handled by the device interface 41 of the device 4 to which the command is input, and the server 31 transmits the converted command to the device interface 41 . When the server 31 receives the command response from the device interface 41 of the device 4, it converts the command response into the format of the command response character string defined by the open API for routine maintenance work. Then, the server 31 sends back to the client 21 the command response character string converted into the format of the command response character string defined by the open API for routine maintenance work. Therefore, maintenance information such as settings and states of each device 4 can be called by inputting a command related to maintenance to the device interface 41 of one or a plurality of devices 4 .

"API number: 2" defines maintenance work with "name: alarm reception". The outline of the maintenance work for "Name: Receiving Alarm" is defined as "Overview: Search the alarm journal at the specified time and return whether or not the corresponding alarm has been received." "Search start time, search end time, generator, TrapID, search character string" and the like are defined, and "list of applicable message information" and the like are defined in "OUT".

For example, the client 22 with the API number "2" of the management server 2 sends the server 32 with the API number "2" of the cooperation server 3 a search start time, a search end time, a generator, a TrapID, and a search character string. Send data. The server 32 converts the data including the search start time, the search end time, the generator, the TrapID, and the search character string into a request that the device interface 41 of the target device 4 can handle, and sends the data including the search character string to the device interface 41 of the device 4 . Send to The device 4 transmits to the server 32 a list of TrapID message information from the search start time to the search end time. The server 32 outputs a list of received message information to the client 22 . As a result, for example, if there is a failed device among the one or more devices 4 , it is possible to receive a failure message or the like from that device 4 .

"API number: 3" defines maintenance work with "name: file transfer". The outline of the maintenance work of "Name: File transfer" is defined as "Overview: Transfer the specified file to the specified folder", and "IN" is defined as "Transfer source file, transfer destination directory". and "OUT" is defined as "OK or NG".

For example, the client 23 with the API number "3" of the management server 2 transmits data including the transfer destination file and the transfer destination directory to the server 33 with the API number "3" of the cooperation server 3. FIG. The server 33 converts the request into a request that can be handled by the device interface 41 of the target device 4 , and transmits the transfer destination file and the transfer destination directory to the device interface 41 of the device 4 . Then, the device 4 transfers the specified file to the specified folder, and responds OK or NG to the server 33 as a result of the file transfer. The server 33 responds to the client 23 with the file transfer result OK or NG from the device 4 .

The routine maintenance work setting information storage unit 5 stores setting information capable of interconverting commands defined by the routine maintenance work open API and commands on which the device interface 41 of each device 4 depends.

FIG. 1 illustrates, as an example, a case where a command of an open API for routine maintenance work used in requesting or responding to a certain maintenance work is associated with a command used by the device 4 . For example, it is assumed that the device (device A) 4-1 in FIG. 1 uses commands such as "cmd_aa_1", "cmd_aa_2", "cmd_bb_1", . 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.

The configuration of the routine maintenance work setting information storage unit 5 is not limited to the example shown in FIG.

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

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. FIG.

For example, the maintenance terminal 1 displays a screen (for example, a web screen) related to the open GUI-API for routine maintenance work corresponding to each maintenance type of the open API for routine maintenance work. Maintenance work for each number is displayed. A 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 so that the maintenance person can select the API number or the name of the maintenance work. In any case, the screen of the maintenance terminal 1 allows the maintenance person to select the desired API number or maintenance work. When the maintenance person makes a selection on the screen of the maintenance terminal 1, the clients 21 to 23 for each corresponding API number are activated in the management server 2. FIG.

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

Further, for example, when the maintenance person desires "API number: 1" and "name: command input", the maintenance person requests the command input destination (for example, the identification information of the target device 4, the device interface 41 of the device 4, etc.). port number, etc.) and the command character string of the command to be issued may be input on the screen. For example, in the case of "API number: 2", the maintenance person can input search start time, search end time, TradID, search character string, etc. on the screen. The maintenance person may be allowed to input the original file, transfer destination directory, etc. on the screen.

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

On the cooperation server 3, the servers 31-33 activated for each API number receive requests defined by the open API for regular maintenance work from the corresponding clients 21-23. For example, the server 31 with API number "1" receives a request from the corresponding client 21 with API number "1".

Then, in the servers 31 to 33 for each API number, the mutual conversion unit 35 converts the request defined by "IN" of the open API for routine maintenance work into a request on which the device 4 depends, and after the conversion is sent to the device interface 41 of the corresponding device 4 .

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, and transmits the request command defined by the routine maintenance work open API to SSH. , and transmitted to the device interface 41 of the corresponding device 4 . The routine maintenance work setting information storage unit 5 is set so as to be able to convert to a protocol (command format) on which the target device 4 depends. In other words, conversion to a protocol (command format) for each model is possible.

The device 4 returns the results of requests from any of the servers 31 to 33 for each API number to the servers 31 to 33 for each corresponding API number. For example, the device interface 41 of the device 4 sends the results in dependent command format to the corresponding servers 31-33.

In the servers 31 to 33 for each API number that have received the result from the device 4, the mutual conversion unit 35 converts the result from the device 4 into a response format defined by "OUT" of the open API for routine maintenance work, Reply to the corresponding client 21-23 via REST. For example, the mutual conversion unit 35 converts the result from the device 4 into the command response character string format defined by the open API for routine maintenance work, and returns it to the corresponding clients 21 to 23 .

The clients 21-23 output the results received from the corresponding servers 31-33 to the screen of the maintenance terminal 1. FIG.

The maintenance person can confirm the result of the requested maintenance work by confirming the result for each API number displayed on the screen of the maintenance terminal 1 . Even if the device 4 is a different model, the result of each device 4 can be called for each API number and displayed on the screen.

(A-3) Effect of the First Embodiment As described above, according to the first embodiment, the maintenance management system utilizes the open API for routine maintenance work to Equipment can be maintained and operated in an integrated manner.

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

(B-1) Basic Concept A problem to be solved by the maintenance management system of the second embodiment and a technical basic concept of means for solving the problem will be described.

Conventionally, when there is a plurality of routine maintenance tasks, maintenance personnel must perform all routine maintenance tasks, and there is a problem that it takes time depending on the amount of work (here, referred to as "first problem"). . For example, consider a case where one system uses multiple devices and each device requires multiple routine maintenance tasks. In this case, conventionally, a maintenance person performs a plurality of routine maintenance work for each device, and performs routine maintenance work for all the devices. Then, the work burden on the maintenance person is heavy, and the work takes a long time.

Also, at any time of the day or night, something can go wrong with the device. Therefore, when a failure occurs, maintenance personnel need to carry out maintenance work to identify the failure, and there is also a problem that the work load is heavy (here, referred to as "second problem").

In view of the problems described above, the second embodiment defines the execution of a plurality of routine maintenance work as a maintenance scenario, and allows routine maintenance work to be performed on a scenario-by-scenario basis, thereby solving the first problem. and In addition, the second embodiment attempts to solve the second problem by monitoring the occurrence of failures and performing routine maintenance work according to the failures when the failures occur.

(B-2) Configuration of 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. 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 mainly described in detail.

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

4, a maintenance management system 10B according to the second embodiment has a maintenance terminal 1, a management server 2, a link server 3, a maintenance target device 4, and a regular maintenance work setting information storage unit 5. FIG.

The linking server 3 has a system name for each system unit, and implements a server 3m (M is a number indicating the API number, 1<m<M) that is called for each API number of the open API for routine maintenance work. do.

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

The server 3m for each API number receives from the client 2m a request for an interface for maintenance work specialized for the API number, as in the first embodiment, and converts the request into an interface request dependent on each device 4. Perform conversion processing. The server 3m and the client 2m implement REST 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 thereof will be omitted to avoid redundant description.

Note that the linking servers 3-2 and 3-X, like the linking server 3-1, perform maintenance work for one or a plurality of devices 4 used by the system B, and the linking server 3-X (X is an integer) performs maintenance work on one or more devices 4 used by system X. Further, the types and numbers of the devices 4 used by the systems A to X, the combination of the devices 4, and the like may differ from system to system. Therefore, the link servers 3 (3-1 to 3-X) implement servers 31 to 3n according to the types, numbers, combinations, etc. of the devices 4 used in the corresponding systems A to X.

4, the management server 2 has clients 21 to 2M for each API number, a trap monitor unit 201, a maintenance scenario registration/execution unit 202, a regular maintenance work execution unit 203, and a maintenance scenario storage unit 204. FIG.

A trap monitoring unit 201 acquires information about a failure that has occurred in system A, B, or X operating using apparatus 4 . For example, the trap monitor 201 can apply SNMP-Trap monitoring. Here, failures are, for example, failures and restarts of servers that perform highly reliable processing such as session control of voice and data, failures of hardware such as servers and optical transmission equipment, failures of Internet lines and telephones. Congestion or the like caused by concentrated access to a line can be exemplified. Of course, the failure is not limited to this, and other failures that may occur in the device 4 as a network device can be considered.

For example, the trap monitoring unit 201 can acquire failure information for each system from a management system, failure detection system, or the like operated in each system such as system A, and monitors information about failures occurring in each system. . As another method, the trap monitoring unit 201 collects detailed call record information such as CDR for each system, performs machine learning on its own using the collected data, and determines that a failure has occurred when it can be determined to be abnormal. You may make it possible to judge. In other words, the trap monitoring unit 201 may acquire failure information from an external system such as the management system of each system, or determine an abnormality (that is, a state different from normal) by unique processing such as machine learning. Or you may make it monitor the precursor.

When the trap monitoring unit 201 receives information indicating the status of the monitoring target from the system to be monitored, it determines whether or not the preset monitoring conditions are met, and generates an alarm trigger ID (for example, An alert including an SNMP-Trap OID (object ID) is provided to the maintenance scenario registration/execution unit 202 . This enables the maintenance scenario registration/execution unit 202 to read the maintenance scenario associated with the monitoring trigger ID when the trap monitor unit 201 acquires/detects information that a failure has occurred in a certain system. It is for As a result, according to the maintenance scenario of the failed system (that is, the maintenance scenario associated with the monitoring trigger ID), routine maintenance work can be automatically executed for each device 4 of the failed system.

The maintenance scenario registration/execution unit 202 includes a registration unit 221 that has a plurality of routine maintenance work, registers a maintenance scenario for performing these routine maintenance work for each system, and executes the maintenance scenario for each system. and an execution unit 222 that performs That is, the maintenance scenario registration/execution unit 202 registers a maintenance scenario that determines the type and order of routine maintenance work to be executed on one or more devices 4 used by the system, and registers the maintenance scenario for each system. for each system.

The maintenance scenario storage unit 204 stores maintenance scenarios for each system. The configuration of 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 configuration and a regular maintenance work configuration. The scenario configuration is scenario setting information such as the system name of the system to which this maintenance scenario is applied, routine maintenance work to be performed, and when to perform the maintenance work. The routine maintenance work configuration is detailed setting information regarding routine maintenance work set in the scenario configuration. The configuration of such a maintenance scenario is detailed in the Operation section.

The routine maintenance work execution unit 203 refers to the maintenance scenario storage unit 204, and according to the maintenance scenario of each system, the client 21 to 2M with the API number defined in the routine maintenance work open API, Issue instructions to perform maintenance work. The routine maintenance work execution unit 203 instructs the clients 21 to 2M to execute the maintenance work, so that maintenance work can be requested to the servers 31 to 3M of the cooperation server 3 of each system using the routine maintenance work open API. The maintenance work of the device 4 to be performed can be automatically performed.

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

(B-3-1) Overall Processing First, the flow of overall processing regarding execution of routine maintenance work in the maintenance management system 10B will be described.

The maintenance terminal 1 requests the maintenance scenario registration/execution unit 202 of the management server 2 for the maintenance scenario screen 12 in order to register the maintenance scenario according to the input instruction of the maintenance person.

The maintenance scenario registration/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 to register the maintenance scenario. 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 .

In the maintenance scenario, as will be described later, a plurality of routine maintenance tasks are defined (set). Further, in the maintenance scenario for each scenario, one of manual execution, alarm-triggered automatic execution, and reserved automatic execution is set as a condition for executing the maintenance scenario.

When manual execution is set, the maintenance terminal activates the execution unit 222 by the operation of the maintenance person, the execution unit 222 reads out the maintenance scenario, and the routine maintenance work execution unit 203 according to the maintenance scenario is executed by the execution unit 222. is activated.

When alarm-triggered automatic execution is set, the trap monitoring unit 201 detects an alarm and activates the execution unit 222, and the execution unit 222 executes a maintenance scenario corresponding to the alarm-triggered ID included in the alarm from the trap monitoring unit 201. , and the execution unit 222 activates the routine maintenance work execution unit 203 according to the maintenance scenario.

When the reservation automatic execution is set, the start date (which may include the time) is set at the same time. When the execution start time of the maintenance scenario stored in the maintenance scenario storage unit 204 comes, the execution unit 222 reads the maintenance scenario and activates the regular maintenance work execution unit 203 according to the maintenance scenario.

Furthermore, the routine maintenance work execution unit 203 activated by the execution unit 222 activates the client 2m (21 to 2M).

Here, in the maintenance scenario for each system, a plurality of routine maintenance tasks are defined (set) as described later. Furthermore, in the maintenance scenario, the API number of each routine maintenance work and the host name of the device 4 that is the target device are also set.

The routine maintenance work execution unit 203 sequentially reads a plurality of routine maintenance work defined in the maintenance scenario. Then, the routine maintenance work execution unit 203 activates the client 2m corresponding to the API number of the routine maintenance work to be executed this time. Activation of the client 2m corresponding to the API number is performed in order according to the API number of the routine maintenance work set in the maintenance scenario.

The client 2m requests activation of the corresponding server 3m among the cooperation servers 3-1 to 3-X via REST. The server 3m is activated by the client 2m. The server 3m converts the request defined by the routine maintenance work open API received at startup into a device-dependent maintenance work interface, and transmits the converted request to the device 4. FIG.

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 by REST.

In the management server 2, the client 2m transmits the maintenance result received from the server 3m to the maintenance terminal 1, and the maintenance terminal 1 outputs the result on the screen. The maintenance person can confirm the result on the screen of the maintenance terminal 1. FIG. This allows the maintenance person to confirm the result of the requested maintenance scenario.

In this example, the maintenance terminal 1 displays the maintenance result on the screen in real time, but the maintenance scenario registration/execution unit 202 stores the maintenance result in the maintenance scenario storage unit 204 in association with the maintenance scenario. It is also possible to Therefore, maintenance results can be retrieved at a later date, not limited to real-time display.

Here, the operation when the maintenance scenario for each system is set to automatic execution upon alarm will be described. To execute routine maintenance work according to a maintenance scenario for a system when a system failure occurs. This is processing when a failure occurs.

Here, when the trap monitoring unit 201 detects a system failure, the alarm-triggered automatic execution executes routine maintenance work defined in a maintenance scenario corresponding to the failure (maintenance scenario associated with an alarm-triggered ID). This is the mode of operation to execute for the system in which it occurred.

When alarm-triggered automatic execution is set in the maintenance scenario, an alarm-triggered ID is also set at the same time. As the alarm trigger ID, it is possible to apply identification information that identifies an item related to a failure (monitoring), such as an OID (object ID) for SNMP-Trap monitoring. Then, the execution unit 222 reads the maintenance scenario set with the alarm trigger ID included in the alarm from the trap monitor unit 201, and executes the regular maintenance work execution unit 203 according to the maintenance scenario set with the alarm trigger ID. Unit 222 is activated.

Thus, when a failure such as session control or line congestion occurs in the system, it is necessary to perform maintenance work on each device 4 of the system in order to identify the cause. In addition, failures can occur day or night, and even in these days when there is a shortage of human resources, it is necessary to perform maintenance as before. Even in view of such a background, according to this embodiment, efficient monitoring and maintenance work can be performed efficiently.

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

FIG. 5 is an explanatory diagram illustrating a configuration example of a maintenance scenario according to the second embodiment. FIG. 6 is a screen diagram showing an example of a maintenance scenario registration screen according to the second embodiment.

As illustrated in FIG. 5, the maintenance scenario has a scenario config and a routine maintenance work config. A maintenance person can create a maintenance scenario for each system through the maintenance scenario registration screen shown in FIG.

Scenario config is maintenance scenario setting information. As illustrated in FIG. 5, the scenario configuration includes "scenario name", "system name", "routine maintenance work information", "target device", "execution start time", "execution end time", and "execution result". as items. In this way, the scenario configuration defines setting information such as which system and which device 4 should perform which routine maintenance work in this maintenance scenario. The scenario config also holds the results of maintenance performed on the device 4 . In order to specify when the maintenance result was executed, the maintenance result is associated with the system name, device, execution start time and execution end time, number of executed routine maintenance work, and the like. Note that the items of the scenario configuration are not limited to those illustrated in FIG.

"Scenario name" is the value set on the screen when registering, changing, or duplicating a maintenance scenario. In other words, the scenario name can also be said to be identification information for specifying the maintenance scenario.

"System name" is the name of the monitoring system selected on the screen when registering, changing, or duplicating the maintenance scenario. That is, "system name" is the name of the system to which the maintenance system is applied. The information is not limited to the system name (name of the system), and may be system identification information such as the system number, ID, etc., as long as the system can be specified.

“Routine maintenance work information” is information related to routine maintenance work incorporated in the maintenance scenario. The "routine maintenance work information" is arranged by the number of routine maintenance work set on the screen when registering, changing, or duplicating a maintenance scenario. The 'routine maintenance work information' has a 'routine maintenance work number list' containing API numbers for each of a plurality of routine maintenance work to be set. This "routine maintenance work number list" will be explained in detail when explaining the routine maintenance work configuration.

"Target device" is the host name of this maintenance scenario execution target device.

The "execution start time" is the execution start time when execution of this maintenance scenario is started, and the "execution end time" is the execution end time when execution of this maintenance scenario is finished. "Execution result" is the result of maintenance executed according to the maintenance scenario. The execution result is the maintenance result of each device for each routine maintenance work.

Next, the regular maintenance work configuration illustrated in FIG. 5 will be described. The routine maintenance work configuration is detailed setting information regarding routine maintenance work set in the scenario configuration of the maintenance scenario. As illustrated in FIG. 5, the routine maintenance work configuration has items of "work number", "API number", and "execution process". In this way, the regular maintenance work configuration sets the API number of the regular maintenance work to be executed on the device 4, and the command, data, information, etc. requested from the device 4 side (server 3m side) in the maintenance work. If there are multiple routine maintenance tasks, a routine maintenance work configuration is created and registered for each routine maintenance work.

"Work number" is a number set in advance for each routine maintenance work. The "work number" is a number set to identify the routine maintenance work number, unlike the API number defined in the routine maintenance work open API.

"API number" is a number defined in the open API for routine maintenance work. For example, "API number: 1" is "command input (single-shot)", "API number: 2" is "alarm reception", and "API number: 3" is "file transfer".

The “execution process” is information requested by the open API for routine maintenance work.

For example, when a command is input to the device 4 (server 3m) with "API number: 1", the character string of the command is set in advance. Alternatively, the command input destination may be set. The character string of this command can be set by the maintenance person through the registration screen.

For example, with "API number: 2", when confirming whether or not a specific alarm has been received on the device 4 (server 3m) side, an ID specifying the alarm is set. In addition, alarm search start time, search end time, generator, search character string, etc. may be set.

Furthermore, for example, when transferring a file to the device 4 (server 3m) with "API number: 3", the transfer destination directory is specified with a full path. Alternatively, a transfer source file may be set.

As described above, the maintenance scenario has a scenario config and a regular maintenance work config, and the maintenance scenario is set through the maintenance scenario registration screen of FIG.

As shown in FIG. 6, the maintenance scenario registration screen 500 includes 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 It has a work setting list display portion 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 section displayed on the registration screen 500 is not limited to that shown in FIG.

A scenario name input section 501 and a system name input section 502 can input a scenario name and a system name by text input, for example.

A routine maintenance work setting unit 503 is a part for setting routine maintenance work defined in a maintenance scenario. For example, in the example of FIG. 6, a list 510 of routine maintenance work that can be selected from a pull-down menu is displayed, and a routine maintenance work is selected from the list 510 . Note that the routine maintenance work setting unit 503 is not limited to the pull-down if the routine maintenance work can be selected and set.

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

The routine maintenance work setting unit 503 can set a plurality of routine maintenance work by sequentially setting routine maintenance work one by one in the list 510 . That is, it is possible to register a maintenance scenario consisting of a plurality of regular maintenance tasks.

Note that when a plurality of routine maintenance tasks are set, the order in which they are set is the order in which the routine maintenance tasks are performed. When performing routine maintenance work in a maintenance scenario in order, if there is a problem with the order, the routine maintenance work setting order is changed in the list 510 of the routine maintenance work setting unit 503 to correct the execution order ( change) is also possible.

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 reserved automatic execution.

When the scenario execution condition setting unit 504 sets alarm-triggered automatic execution, an alarm-triggered ID is also set. Thus, when an alarm is detected by the trap monitoring unit 201, the maintenance scenario in which the alarm trigger ID is set can be read. Note that the trap monitoring unit 201 receives information indicating the state of the monitoring target, detects an alarm containing an item (alarm trigger ID) matching preset monitoring conditions, and activates the maintenance scenario registration execution unit 202 . However, if there is a match in a plurality of items, the scenario execution unit 202 is instructed to execute a plurality of maintenance scenarios. It is possible to register not only one type of maintenance scenario for one system, but also multiple types of maintenance scenarios corresponding to each of a plurality of alarm trigger IDs.

A target device input unit 505 inputs a target device for performing specified routine maintenance work. The target device input unit 505 inputs the host name of the device 4 by text input. As another method, if it is possible to cooperate 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 cooperates with the database to Each device 4 may be selected.

A routine maintenance work setting list display portion 506 is a portion for displaying list information of specified routine maintenance work. In FIG. 6, for example, "No" indicating the work number of routine maintenance work, "Routine maintenance work name", "Start time" indicating execution start time, "End time" indicating execution end time, and other setting information are shown. Items such as "refer to detailed information" are included to enable referencing. Items to be displayed in the regular maintenance work setting list display unit 506 are not limited to these.

A routine maintenance work setting list display portion 506 displays the work number and routine maintenance work name of the routine maintenance work selected in the routine maintenance work setting portion 503 . When a plurality of routine maintenance work items are selected in the routine maintenance work setting section 503 , the plurality of routine maintenance work items are displayed in the routine maintenance work setting list display section 506 . The displayed order is the order selected in the routine maintenance work setting unit 503 .

That is, when executing a maintenance scenario for each system, the routine maintenance work execution unit 203 sequentially executes the routine maintenance work in the order selected by the routine maintenance work setting unit 503 .

Further, in the routine maintenance work setting list display portion 506, the item "refer to 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 for setting detailed setting information for routine maintenance work is displayed. On this screen 520, it is possible to set information related to the "API number" and "execution process" of the routine maintenance work configuration.

When the registration button 507 is selected by the maintenance person, the input maintenance scenario is registered. When the change button 540 is selected by the maintenance person, the changed maintenance scenario is changed and registered. When the cancel button 508 is selected, the maintenance scenario is deleted.

(B-4) Effect of Second Embodiment As described above, according to the second embodiment, a plurality of routine maintenance tasks can be executed at once by the automatic execution method of the open API for routine maintenance work. It is possible to reduce the burden on the maintenance person.

Further, according to the second embodiment, by associating an alarm with a maintenance scenario, regular maintenance work can be performed when a failure occurs, and maintenance operation can be performed to reduce the burden of nighttime work.

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

(C-1) In the above-described embodiment, for convenience of explanation, the case where the clients 21 to 23 and the servers 31 to 33 are activated for each API number was exemplified. However, the client server is not limited to sorting by API number.

For example, when a maintenance person performs maintenance operations such as setting and monitoring the status of the device 4 on the screen of the maintenance terminal 1, maintenance identification information such as a maintenance identifier, maintenance type or maintenance work name is assigned to each device 4. It would be nice to be able to display the results of Therefore, the client/server may be classified according to maintenance type or maintenance work name.

(C-2) In the above-described embodiment, the servers 31 to 33 for each API number on the cooperation server 3 are "IN" or "OUT" defined by the open API for routine maintenance work, and the device 4 depends on them. Although the case of converting a command format request or response is exemplified, the present invention is not limited to this.

For example, the clients 21 to 23 on the management server 2 can access the routine maintenance work setting information storage unit 5, and convert "OUT" out of "IN" and "OUT" of the routine maintenance work open API. may be displayed on the screen of the maintenance terminal 1. The conversion of "IN" may be performed by the clients 21-23.

Further, for example, the clients 21 to 23 provide the maintenance terminal 1 with the routine maintenance work setting information stored in the routine maintenance work setting information storage unit 5, and cause the maintenance terminal 1 to store the parameters defined as "OUT". , may be converted into a response in the command format of each device 4 and displayed on the screen. Conversely, the maintenance terminal 1 may convert the response in the command format of each device 4 into a parameter defined as "OUT" and display it on the screen.

(C-3) As illustrated in FIG. 3, the servers 31 to 33 for each API number on the cooperation server 3 are connected to the integrated monitoring system 6 that monitors the maintenance status of the plurality of devices 4, and the integrated monitoring system Maintenance of the device 7 monitored by 6 is also possible.

In this case also, by using the routine maintenance open API described in the above embodiment, the maintenance information (result) of each device 7 monitored by the integrated monitoring system 6 is called up and displayed on the screen of the maintenance terminal 1. be able to.

(C-4) In the second embodiment described above, the management server 2 executes various functions of the trap monitoring unit 201, the maintenance scenario registration/execution unit 202, the regular maintenance work execution unit 203, and the client 2m. bottom. However, the various functions executed by the management server 2 do not have to be implemented by the physically same server, and may be distributed on a plurality of physically different servers.

DESCRIPTION OF SYMBOLS 1... maintenance terminal, 2... management server, 3... cooperation server, 4 (4-1 to 4-N) apparatus, 5... routine maintenance work setting information storage unit, 6... integrated monitoring system, 7... apparatus, 10 and 10A and 10B... maintenance management system, 21 to 23... client, 31 to 33... server, 35... mutual conversion unit, 41... equipment interface, 201... trap monitoring unit, 202... maintenance scenario registration/execution unit, 203... regular maintenance work execution unit, 204...maintenance scenario storage unit;

Claims (18)

a first server connected to a maintenance terminal;
a second server connected to the plurality of target devices;
the first server
transmitting a common maintenance request for each of the plurality of target devices from the maintenance terminal to the second server, and obtaining a response from each of the plurality of target devices to the common maintenance request through the second server; having a common request unit for each maintenance type that transmits a result to the maintenance terminal;
the second server,
converting 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 transmitting the request to each of the corresponding plurality of target devices; A maintenance management system, comprising a response unit for each maintenance type, which converts a response result from each of the target devices in the above into the format of the common request unit and transmits the response result to the corresponding common request unit. wherein the response unit for each of the maintenance types of the second server has a mutual conversion unit that performs mutual conversion between the interface of each of the plurality of target devices and the interface of the common request unit for each of the maintenance types. The maintenance management system according to claim 1. the maintenance type related to the common maintenance request includes command submission for each of the plurality of target devices;
The response unit related to the command input,
converting a request including a command input destination and a command string obtained from the corresponding common request unit into a command according to a protocol on which each of the plurality of target devices depends and transmitting the request to each of the plurality of target devices; death,
converting a response result to the request obtained from each of the plurality of target devices into a command response character string in a predetermined format and transmitting the result to the corresponding common request unit;
3. The maintenance management system according to claim 1, wherein the common request unit displays a screen including response results from each of the plurality of target devices on the maintenance terminal. a setting information storage unit having setting information that associates a command on which each of the plurality of target devices depends with a command related to the common maintenance request;
4. The maintenance management according to claim 3, wherein the first server refers to the setting information and causes the maintenance terminal to display a screen obtained by converting a response result from each of the plurality of target devices. system. the first server
a maintenance scenario storage unit for storing, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed for each of the plurality of target devices of the target system is 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 the execution time set in the maintenance scenario for each of the target systems. The maintenance management system according to any one of claims 1 to 4. the first server
for each target system, through the maintenance terminal, sequentially setting the common maintenance request to be made to each of the plurality of target devices possessed by the target system, and executing processing relating to each of the plurality of set common maintenance requests; 6. The maintenance management system according to claim 5, further comprising a registration unit that sets the maintenance scenario of the target system and registers the maintenance scenario. The first server comprises a failure monitoring unit that monitors occurrence of a failure in the target system,
3. The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests according to the maintenance scenario associated with the failure notification from the failure monitoring unit that detected the failure. The maintenance management system according to 5 or 6. A first server connected to the maintenance terminal has a common request part for each maintenance type,
A second server connected to a plurality of target devices has a response unit for each maintenance type,
the common request unit transmitting 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 sends the request to each of the plurality of corresponding target devices. send to
the response unit converts a response result from each of the plurality of target devices into the format of the common request unit and transmits the result to the corresponding common request unit;
The maintenance management method, wherein the common request unit transmits a response result of each of the plurality of target devices to the common maintenance request, which is acquired from the response unit, to the maintenance terminal. A management server 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,
transmitting a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server, and sending a response result of each of the plurality of target devices to the common maintenance request, obtained through the linking server, to the A management server characterized by having a common request part for each maintenance type, which is transmitted to a maintenance terminal. a maintenance scenario storage unit for storing, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed for each of the plurality of target devices of the target system is 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 the execution time set in the maintenance scenario for each of the target systems. 10. Management server according to claim 9. for each target system, through the maintenance terminal, sequentially setting the common maintenance request to be made to each of the plurality of target devices possessed by the target system, and executing processing relating to each of the plurality of set common maintenance requests; 11. The management server according to claim 10, further comprising a registration unit that sets the maintenance scenario of the target system and registers the maintenance scenario. A fault monitoring unit that monitors the occurrence of a fault in the target system,
3. The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests according to the maintenance scenario associated with the failure notification from the failure monitoring unit that detected the failure. 12. The management server according to 10 or 11. A cooperation server that acquires maintenance information of a plurality of connected target devices in cooperation with a management server connected to a maintenance terminal,
converting a common maintenance request for each of the plurality of target devices acquired from a common request unit for each maintenance type on the management server into a format that can be handled by each of the plurality of target devices; and converts the response result from each of the plurality of target devices into the format of the common request section and transmits the result to the corresponding common request section. A cooperation server characterized by having: 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,
the computer,
transmitting a common maintenance request for each of the plurality of target devices from the maintenance terminal to the linking server, and sending a response result of each of the plurality of target devices to the common maintenance request, obtained through the linking server, to the A maintenance management program characterized by functioning as a common request unit for each maintenance type, which is transmitted to a maintenance terminal. the computer,
a maintenance scenario storage unit for storing, for each target system having the plurality of target devices, a maintenance scenario in which the plurality of common maintenance requests to be performed for each of the plurality of target devices of the target system is set;
functioning as a maintenance execution unit that 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; The maintenance management program according to claim 14, characterized by: The computer sequentially sets the common maintenance request to be made to each of the plurality of target devices of the target system for each of the target systems through the maintenance terminal, and relates to each of the set common maintenance requests 16. The maintenance management program according to claim 15, which functions as a registration unit that sets execution processing and registers the maintenance scenario of the target system. the computer,
Functioning as a failure monitoring unit that monitors the occurrence of failures in the target system,
3. The maintenance execution unit causes the common request unit to execute the plurality of common maintenance requests according to the maintenance scenario associated with the failure notification from the failure monitoring unit that detected the failure. The maintenance management program according to 15 or 16. A maintenance management program for acquiring maintenance information of a plurality of connected target devices in cooperation with a management server connected to a maintenance terminal,
the computer,
converting a common maintenance request for each of the plurality of target devices acquired from a common request unit for each maintenance type on the management server into a format that can be handled by each of the plurality of target devices; and converts the response result from each of the plurality of target devices into the format of the common request section and transmits the result to the corresponding common request section. A maintenance management program characterized by functioning as

Images