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

Description

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

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

Generally, maintenance management such as device settings and device status monitoring uses a dedicated device interface for each model, and information obtained during maintenance is presented to maintenance workers through that device interface. Note that the device interface referred to here refers to the interface required for maintenance work, and includes, for example, a UI (User Interface), API (Application Programming Interface), and communication interface.

However, because the device interface differs for each 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 common maintenance management for multiple device models.

Conventional technologies for providing maintenance and operation using web-based APIs include, for example, Patent Documents 1 and 2.

In Patent Document 1, a server provides a common web API to a terminal device, and the server accepts operation requests for the 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 interface differences due to differences in cash handling machine models.

Patent Document 2 describes a maintenance support system that supports maintenance work by visualizing the history information of web systems in order to shorten the lead time to identify the cause of an information system failure during maintenance work.

JP 2018-128830 A JP 2011-192230 A

However, the technology described in Patent Document 1 above has the problem that it limits maintenance to cash processing machines, making it impossible to use the interfaces of various devices on the IP network.

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 of not being usable as an interface for various devices on an IP network.

In order to solve the above-mentioned problems, the present invention requires a maintenance management system, a maintenance management method , a management server, and a maintenance management program that can comprehensively maintain and operate the routine maintenance tasks that are generally performed by various devices on a network.

In order to solve the above problems, a first maintenance management system according to the present invention comprises a first server connected to a maintenance terminal and a second server connected to a plurality of target devices, wherein the first server has 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 the response results of each of the plurality of target devices to the common maintenance request, obtained through the second server, to the maintenance terminal, and the second server has 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 is 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 results from each of the plurality of target devices into a common request unit format and transmits it to the corresponding common request unit, and 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 made to each of the plurality of target devices of 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 .

A second maintenance management method according to the present invention is characterized in that a first server connected to a maintenance terminal has a common request unit for each maintenance type and a maintenance execution unit , 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 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 is compatible with each of the plurality of target devices and transmits it to each of the corresponding plurality of target devices, the response unit converts the response result from each of the plurality of target devices into the format of the common request unit and transmits it to the corresponding common request unit, 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, and the maintenance execution unit of the first server references a maintenance scenario memory 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 for each of the plurality of target devices in the target system, 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 .

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, and is characterized by 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 the response results of each of the plurality of target devices to the common maintenance request, obtained through the linking server, to the maintenance terminal; a maintenance scenario memory 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 made for 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 the execution time set in the maintenance scenario for each target system .

A fourth aspect of the present invention is a maintenance management program that cooperates with a linking server connected to a plurality of target devices and provides a maintenance terminal with maintenance information for each of the plurality of target devices, and is characterized in that the program causes a computer to function as a maintenance execution unit that refers to 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 the response results of each of the plurality of target devices to the common maintenance request, obtained through the linking server, to the maintenance terminal, and a maintenance scenario memory 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 made to each of the plurality of target devices in the target system, 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 .

This invention enables the integrated maintenance and operation of routine maintenance tasks typically performed on 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. 10 is an explanatory diagram illustrating the definition of a routine maintenance work open API according to the embodiment. FIG. 10 is an overall configuration diagram showing the overall configuration of a maintenance management system according to a modified embodiment. FIG. 10 is a diagram showing the overall configuration of a maintenance management system according to a second embodiment. FIG. 10 is an explanatory diagram illustrating an example of a configuration of a maintenance scenario according to the second embodiment. FIG. 11 is a screen diagram showing an example of a registration screen for a maintenance scenario according to the second embodiment.

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

In this embodiment, a Web API (application program interface) is defined that allows various devices on an IP network to call routine maintenance tasks typically 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 referred to as an "open API for routine maintenance tasks."

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, enabling integrated maintenance and operation of each device.

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

In FIG. 1, the 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.

Devices 4 (4-1 to 4-N) are devices that are subject to maintenance control and can be connected to an IP network. Devices 4 (4-1 to 4-N) can be various types of devices, such as VoIP devices, servers, network equipment, and optical transmission equipment. Each of devices 4-1 to 4-N has a device interface 41 appropriate for its model, and the device interface 41 operates using commands appropriate for the model, such as SSH (Secure Shell) or telnet.

The maintenance terminal 1 is a terminal operated by a maintenance technician and performs maintenance control such as setting up and monitoring the status of the devices 4 (4-1 to 4-N). The maintenance terminal 1 can be, for example, a personal computer, smartphone, tablet terminal, or other device, and is a terminal device that has a display unit, input unit, control unit, communication unit, etc.

For example, the maintenance terminal 1 uses its web browser function to exchange web information that has a one-to-one correspondence with the routine maintenance work open API with the management server 2, utilizing the routine maintenance work open API provided by the linking server 3, or to implement pre-installed routine maintenance work application software (also referred to as a "maintenance work app") to utilize the routine maintenance work open API. The API of web information that has a one-to-one correspondence with the routine maintenance work open API, and that the management server 2 provides to the maintenance terminal 1, is called the routine maintenance work open GUI-API. In other words, the maintenance terminal 1 can use the routine maintenance work open GUI-API provided by the management server 2 using a web browser or maintenance work app, etc.

The maintenance terminal 1 connects to the management server 2 and displays a screen for maintenance work defined by the open GUI-API for defined maintenance work on the display unit, allowing the maintenance operator to select the desired maintenance work. The maintenance terminal 1 then sends a request to the management server 2 via the open GUI-API for defined maintenance work, including maintenance identification information (in this embodiment, an "API number" is used as an example) indicating the maintenance work selected on the screen. The maintenance terminal 1 also obtains maintenance information for each device 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 for the maintenance information for each device 4-1 to 4-N on the display unit.

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.

The management server 2 is the server that calls the system on the link 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 explanation, for example, a client with API number "1" will be referred to 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.

The linked server 3 is the 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 each client. In the following explanation, for example, the server with API number "1" will be referred to as server 31, etc.

Clients 21-23 and servers 31-33 are associated with each other by API number, and data is exchanged between clients and servers for each API number in pairs. In other words, clients 21-23 and servers 31-33 send and receive data specific to maintenance work defined by the open API for routine maintenance work.

Furthermore, the servers 31-33 for each API number have a mutual conversion unit 35 that converts between requests defined in the open API for routine maintenance work and requests for the device interface 41 on which each device 4 depends. Therefore, when the servers 31-33 receive a request for a maintenance work interface specific to the API number from the clients 21-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.

The mutual conversion unit 35 can be configured in a variety of ways. For example, it converts requests (or responses) defined in the routine maintenance work open API with requests (or responses) from the device interface 41 on which each device 4 depends, by referencing a correspondence table. For example, the correspondence table is stored in the routine maintenance work setting information storage unit 5. However, a separate correspondence table may also be provided.

Here, clients 21-23 for each API number and the corresponding servers 31-33 implement, for example, REST (Representational State Transfer), and use REST to send and receive data.

Furthermore, this embodiment illustrates an example in which clients 21-23 and servers 31-33 send and receive data using the HTTP or HTTPS communication protocol, but this is not limited to this as long as data can be sent and received over an IP network.

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

In Figure 2, the open API for routine maintenance work is a common interface generally required for maintaining and operating device 4. 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).

The open API for routine maintenance work has the following fields: "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 output (sent). Note that the fields are not limited to these, and other fields may be added.

The open API for routine maintenance work uses a communication protocol such as HTTP or HTTPS to make it available to devices 4 on an IP network. Furthermore, to facilitate easy implementation by the clients 21-23 that call it and the servers 31-33 that are called, the open API for routine maintenance work conforms to REST. In other words, it is created in a data format such as JSON (JavaScript Object Notation).

For "API Number: 1," a maintenance task with the name "Command Submission" is defined. The summary of the maintenance task with the name "Command Submission" is defined as "Summary: Execute the specified command and return a response." "IN" defines the "command submission destination and command string," and "OUT" defines the format of the "command response string."

For example, in the management server 2, a client 21 with API number "1" sends a command destination and a command string to a server 31 with API number "1" in 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 sent is compatible, and then sends 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 open API for routine maintenance work. The server 31 then returns the command response string, converted into the command response string format defined by the open API for routine maintenance work, to the client 21. Therefore, maintenance-related commands can be issued to the device interfaces 41 of one or more devices 4 to access maintenance information such as the settings and status of each device 4.

For "API Number: 2," a maintenance operation for "Name: Alarm Reception" is defined. The summary of the maintenance operation 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." "IN" defines the "search start time, search end time, generating device, Trap ID, search string," etc., and "OUT" defines the "list of corresponding message information," etc.

For example, a client 22 with API number "2" on the management server 2 sends data including a search start time, search end time, generating device, Trap ID, and search string to a server 32 with API number "2" on the linkage server 3. The server 32 converts this into a request that the device interface 41 of the target device 4 can handle, and sends 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 sends a list of message information for Trap IDs from the search start time to the search end time to the server 32. The server 32 outputs the received list of 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 that device 4.

For "API Number: 3," a maintenance task for "Name: File Transfer" is defined. The summary of the maintenance task 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."

For example, a client 23 with API number "3" on the management server 2 sends data including a destination file and a 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 sends the destination file and 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.

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

As an example, Figure 1 illustrates a case in which commands of the routine maintenance work open API used in requests or responses to certain maintenance work are associated with commands used by device 4. For example, for certain maintenance work, device (device A) 4-1 in Figure 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 the "A commands" used by 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 Figure 1, as long as it is capable of converting between commands of the routine maintenance work open API and commands of each device 4.

(A-2) Operation of the 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 launches the clients 21 to 23 for each API number on the display screen of the maintenance terminal 1.

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 maintenance terminal 1 screen. 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 either case, the screen on 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-23 for each corresponding API number are launched on the management server 2.

At this time, the maintenance person may select the target device 4 from among the multiple devices 4 and input the 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 only a portion of the devices 4 may be targeted; in the latter case, the target device 4 may be selectable.

For example, when a maintenance person desires "Name: Command Entry" for "API Number: 1," the maintenance person may be able to input on the screen the command destination (e.g., the identification information of the target device 4, the port number of the device 4's equipment interface 41, etc.) and the command string of the command to be issued. For example, in the case of "API Number: 2," the maintenance person may be able to input on the screen the search start time, search end time, Trad ID, search string, etc., and in the case of "API Number: 3," the maintenance person may be able to input on the screen the source file, destination directory, etc.

The clients 21-23 for each activated API number request, via REST, the servers 31-33 for each corresponding API number on the linked server 3 to be activated. For example, the client 21 with API number "1" requests, via REST, that the server 31 with API number "1" be activated.

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

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

For example, if the device interface 41 of the device 4 relies on SSH, the mutual conversion unit 35 references 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 device interface 41 of the corresponding device 4. The routine maintenance work setting information storage unit 5 is configured to enable conversion to the protocol (command format) on which the target device 4 relies. In other words, conversion to the protocol (command format) for each model is possible.

Device 4 returns the results of a request from one of servers 31-33 for each API number to the server 31-33 for the corresponding API number. For example, device 4's device interface 41 sends the results to the corresponding server 31-33 in the dependent command format.

When the servers 31-33 for each API number receive the results from the device 4, the mutual conversion unit 35 converts the results from the device 4 into the response format defined by "OUT" of the open API for routine maintenance work, and returns the results to the corresponding clients 21-23 via REST. For example, the mutual conversion unit 35 converts the results from the device 4 into the command response string format defined in the open API for routine maintenance work, and returns the results to the corresponding clients 21-23.

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

Maintenance personnel 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 for each device 4 can be called up for each API number and displayed on the screen.

(A-3) Effects of the First Embodiment As described above, according to the first embodiment, the maintenance management system can perform integrated maintenance and operation of multiple devices on a network by utilizing an open API for routine maintenance work.

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

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

Conventionally, when there are multiple routine maintenance tasks, the maintenance staff is required to perform all of them, which poses an issue of time depending on the amount of work (referred to here as the "first issue"). For example, consider a case where a single system uses multiple devices, and multiple routine maintenance tasks are required for each device. In this case, the maintenance staff would conventionally perform multiple routine maintenance tasks for each device, completing routine maintenance for all devices. This places a heavy workload on the maintenance staff and takes a long time to complete the tasks.

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

In view of the above-mentioned issues, the second embodiment attempts to solve the first issue by defining the execution of multiple routine maintenance tasks as maintenance scenarios and enabling routine maintenance tasks to be performed on a scenario-by-scenario basis. The second embodiment also attempts to solve the second issue by monitoring for the occurrence of failures and, when a failure occurs, enabling routine maintenance tasks to be performed in response to the failure.

(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 following detailed description will focus on the characteristic functions of the second embodiment.

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

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

The linked server 3 has a system name for each system 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.

For example, in Figure 4, assume there is a system with the system name (system identification information) "System A" that operates using device A, device B, ..., device N. Linking server 3-1 is a server that performs maintenance work on device A, device B, ..., device N used in "System A." Linking server 3-1 has server 3m that is called for each API number of the open API for routine maintenance work.

As in the first embodiment, the server 3m for each API number receives an interface request for maintenance work specific to the API number from the client 2m and converts that request into an interface request that is dependent on each device 4. The server 3m and client 2m implement REST, as in the first embodiment. Note that the processing of the server 3m and client 2m is basically the same as the processing in the first embodiment, and detailed explanation will be omitted to avoid duplication.

Note that, like linking server 3-1, linking server 3-2 performs maintenance work on one or more devices 4 used by system B, and linking server 3-X (X is an integer) performs maintenance work on one or more devices 4 used by system X. Furthermore, the types and number of devices 4 used by systems A to X, as well as the combinations of devices 4, may differ from system to system. Therefore, linking servers 3 (3-1 to 3-X) implement servers 31 to 3n that correspond to the types, numbers, and combinations of devices 4 used by the corresponding systems A to X.

In Figure 4, the management server 2 has clients 21-2M for each API number, a trap monitoring unit 201, a maintenance scenario registration and execution unit 202, a routine maintenance work execution unit 203, and a maintenance scenario storage unit 204.

When a fault occurs in system A, B, or X, which is operating using device 4, the trap monitoring unit 201 acquires information about the fault. For example, the trap monitoring unit 201 can apply SNMP-Trap monitoring. Examples of faults include the failure or restart of a server that performs highly reliable processing such as session control for voice or data, hardware failures in servers or optical transmission equipment, and congestion caused by concentrated access to Internet or telephone lines. Of course, faults are not limited to these, and faults that may occur in device 4 as a network device are also considered.

For example, the trap monitoring unit 201 can acquire fault information for each system from management systems or fault detection systems operated by each system, such as system A, and monitor information related to faults that occur in each system. As another method, the trap monitoring unit 201 can collect detailed call record information, such as CDR, for each system, and perform its own machine learning using the collected data to determine that a fault has occurred when it can determine that an abnormality has occurred. In other words, the trap monitoring unit 201 can acquire fault information from an external system, like the management system for each system, or it can use its own machine learning or other processing to determine abnormalities (i.e., states that are different from normal) and monitor for faults or their precursors.

When the trap monitoring unit 201 receives information indicating the status of the monitored system from the monitored system, it determines whether the information matches the preset monitoring conditions and sends an alert to the maintenance scenario registration and execution unit 202, including an alarm trigger ID (e.g., an SNMP-Trap OID (object ID)) indicating the matching item. 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 of the failed system in accordance with the maintenance scenario of the failed system (i.e., the maintenance scenario associated with the monitoring trigger ID).

The maintenance scenario registration and execution unit 202 has a registration unit 221 that has multiple routine maintenance tasks and registers maintenance scenarios for performing these multiple 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.

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 configuration information such as the system name of the system to which this maintenance scenario applies, 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.

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

(B-3) Operation of the 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 overall processing flow regarding the execution of routine maintenance work in the maintenance management system 10B will be described.

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

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.

As described below, multiple routine maintenance tasks are defined (set) in a maintenance scenario. Furthermore, for each maintenance scenario, the conditions for executing the maintenance scenario are set to either manual execution, automatic execution triggered by an alarm, or scheduled automatic execution.

When manual execution is set, the maintenance terminal is operated by the maintenance person to activate the execution unit 222, which then reads the maintenance scenario and activates the routine maintenance work execution unit 203 corresponding to that maintenance scenario.

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

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

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

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

The routine maintenance work execution unit 203 sequentially reads out multiple 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.

Client 2m sends a startup request to the corresponding server 3m in the linked servers 3-1 to 3-X via REST. Server 3m is started by client 2m. Server 3m converts the request defined in the routine maintenance work open API received at startup into a device-dependent maintenance work interface and sends the converted request to device 4.

Server 3m receives the request results returned from device 4 and converts them into "OUT" of the routine maintenance work open API. Server 3m returns the converted results to client 2m via REST.

On management server 2, client 2m sends the maintenance results received from server 3m to maintenance terminal 1, which then outputs the results on its screen. The maintenance person can check the results on the screen of maintenance terminal 1. This allows the maintenance person to check the results of the requested maintenance scenario.

Note that while 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, maintenance results can be searched for at a later date, rather than just displayed in real time.

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

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

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 the fault (monitoring), such as an OID (object ID) for SNMP-Trap monitoring. The execution unit 222 then reads out the maintenance scenario for which the alarm trigger ID included in the alarm from the trap monitoring unit 201 is set, and the execution unit 222 starts the routine maintenance work execution unit 203 corresponding to the maintenance scenario for which the alarm trigger ID is set.

As such, when a system failure such as session control or line congestion occurs, 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, so even in these times of labor shortages, maintenance work must be performed as before. Given this background, this embodiment enables efficient monitoring and efficient execution of maintenance work.

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

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

As shown in Figure 5, a maintenance scenario includes a scenario configuration and a routine maintenance work configuration. Maintenance personnel can create a maintenance scenario for each system via the maintenance scenario registration screen shown in Figure 6, which is displayed on the display unit of the maintenance terminal 1.

Scenario Config is the configuration information for a maintenance scenario. As illustrated in Figure 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 configuration information such as which system this maintenance scenario will be executed on, and which routine maintenance work will be executed on which device 4. Scenario Config also stores the results of maintenance performed on the device 4. To identify when the maintenance results were performed, these maintenance results are associated with the system name, device, execution start time and execution end time, the number of the routine maintenance work performed, etc. Note that the items in Scenario Config are not limited to those illustrated in Figure 5.

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 used to identify a maintenance scenario.

The "system name" is the name of the monitoring system selected on the screen when registering, modifying, or duplicating a maintenance scenario. In other words, the "system name" is the name of the system to which the maintenance system applies. 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.

"Routine maintenance work information" is information about routine maintenance work that is incorporated into a maintenance scenario. "Routine maintenance work information" is arranged in the same number as the number of routine maintenance work 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 for each of the multiple routine maintenance work sets. 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 the device on which this maintenance scenario will be executed.

The "Execution start time" is the time when this maintenance scenario began execution, and the "Execution end time" is the time when this maintenance scenario ended execution. The "Execution result" is the result of maintenance performed according to the maintenance scenario. The execution result is the maintenance result for each device for each routine maintenance task.

Next, we will explain the routine maintenance work configuration shown in Figure 5. 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 Figure 5, the routine maintenance work configuration has the fields "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, as well as the commands, data, information, etc. requested from the device 4 (server 3m) during the maintenance work. If there are multiple routine maintenance work, a routine maintenance work configuration is created and registered for each routine maintenance work.

The "job number" is a number set in advance for each routine maintenance task. The "job number" is different from the API number defined in the open API for routine maintenance tasks, and is a number set to identify the routine maintenance task number.

The "API number" is the number defined by the open API for routine maintenance work. For example, "API number: 1" is "Command submission (single)", "API number: 2" is "Alarm reception", and "API number: 3" is "File transfer".

"Execution process" is the information requested by the open API for routine maintenance work.

For example, when issuing a command to device 4 (server 3m) with "API number: 1," the command string is set in advance. Alternatively, the command's destination can be set. The command string can be set by an administrator via the registration screen.

For example, when checking whether a specific alarm has been received on device 4 (server 3m) using "API number: 2," an ID identifying that alarm is set. Other settings such as the alarm search start time, search end time, generating device, and search string may also be set.

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

As described above, a maintenance scenario has a scenario configuration and a routine maintenance work configuration, and the maintenance scenario is set via the maintenance scenario registration screen shown in Figure 6, which is provided on the maintenance terminal 1.

As illustrated in Figure 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 Figure 6, and the input sections displayed on the registration screen 500 are not limited to those in Figure 6.

The scenario name input section 501 and system name input section 502 allow you to enter the scenario name and system name, for example, by text input.

The routine maintenance work setting section 503 is the section where routine maintenance work defined in the maintenance scenario is set. For example, in the example of Figure 6, routine maintenance work that can be selected using a pull-down menu is displayed in list 510, and the routine maintenance work is selected from 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.

When a routine maintenance task is set in the routine maintenance task setting section 503 (for example, by selecting the "Add" button, the selected routine maintenance task 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, which will be described later.

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

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 any 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 list 510 of the routine maintenance task setting section 503.

The scenario execution condition setting unit 504 can set the conditions for executing the maintenance scenario. The scenario execution condition setting unit 504 can set either manual execution, automatic execution triggered by an alarm, or scheduled automatic execution.

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 the maintenance scenario for which the 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 status 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, it instructs the scenario execution unit 202 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.

The target device input unit 505 inputs the target device for which the specified routine maintenance work will 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 in the system with the host name of each device 4, the target device input unit 505 may link with that database to enable selection of a device 4 for each system.

The routine maintenance work setting list display section 506 is a section that displays a list of specified routine maintenance work. In Figure 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 detailed information" to enable reference to other setting information. Note that the items displayed in the routine maintenance work setting list display section 506 are not limited to these.

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 work are selected in the routine maintenance work setting section 503, the multiple routine maintenance work 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.

In other words, when executing a maintenance scenario for each system, the routine maintenance work execution unit 203 will execute the routine maintenance work in the order selected in the routine maintenance work setting unit 503.

In addition, 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 in which detailed setting information for the routine maintenance work is set. On this screen 520, information regarding the "API number" and "execution process" of the routine maintenance work configuration can be set.

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.

(B-4) Effects of the Second Embodiment As described above, according to the second embodiment, the automatic execution method of the open API for routine maintenance work can reduce the burden on the maintenance personnel by executing multiple routine maintenance work at once.

Furthermore, according to the second embodiment, by associating alarms with maintenance scenarios, routine maintenance work can be performed when a failure occurs, enabling maintenance operations that reduce the burden of nighttime work.

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

(C-1) In the above-described embodiment, for the sake of convenience, an example was given in which clients 21-23 and servers 31-33 are started for each API number. However, clients and servers are not limited to being separated by API number.

For example, when a maintenance technician performs maintenance operations such as setting up devices 4 or monitoring their status on the screen of the maintenance terminal 1, it is sufficient to be able to display the results of each device 4 by maintenance identification information such as a maintenance identifier, by maintenance type, or by maintenance work name. Therefore, it is also possible to divide clients and servers by maintenance type or maintenance work name.

(C-2) In the above-described embodiment, an example was given in which servers 31 to 33 for each API number on the linking server 3 convert "IN" or "OUT" defined in the open API for routine maintenance work and requests or responses in the command format on which the device 4 relies, but this is not limited to this.

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

For example, clients 21-23 may provide routine maintenance work setting information stored in the routine maintenance work setting information storage unit 5 to the maintenance terminal 1, which may then convert the "OUT" definition parameters into responses in the command format of each device 4 and display them on the screen. Conversely, the maintenance terminal 1 may convert the command format responses of each device 4 into "OUT" definition parameters and display them on the screen.

(C-3) As shown in Figure 3, servers 31-33 on the linking server 3 for each API number can connect to an integrated monitoring system 6 that monitors the maintenance status of multiple devices 4, enabling maintenance management of devices 7 monitored by the integrated monitoring system 6.

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.

(C-4) In the second embodiment described above, an example was given in which the management server 2 executes the various functions of the trap monitoring unit 201, maintenance scenario registration and execution unit 202, routine maintenance task execution unit 203, and 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.

1...Maintenance terminal, 2...Management server, 3...Linkage server, 4 (4-1 to 4-N) devices, 5...Routine maintenance work setting information storage unit, 6...Integrated monitoring system, 7...Devices, 10, 10A, and 10B...Maintenance management system, 21-23...Clients, 31-33...Servers, 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 (10)

a first server connected to a maintenance terminal;
a second server connected to a plurality of target devices;
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: 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. the first server includes a fault monitoring unit that monitors the occurrence of a fault in the target system;
The maintenance management system according to claim 1 or 2, characterized in that 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 . 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: 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: 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 . a failure monitoring unit that monitors the occurrence of a failure in the target system;
The management server according to claim 5 or 6, characterized in that 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 . 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. 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. Computer,
a failure monitoring unit that monitors the occurrence of a failure in the target system;
The maintenance management program according to claim 8 or 9, characterized in that 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 .