JP2009157597A - Automatic distribution system for remote maintenance software, and automatic distribution method for remote maintenance software - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automatically distribute/execute a remote maintenance software. <P>SOLUTION: In this system, a center monitor 1 is connected with a plurality of local monitors 2 via a network 3, the local monitors 2 execute the remote maintenance software installed based on control from the center monitor 1, and the center monitor 1 analyzes incident information, based on information in a database part 13, when the incident information detected in monitoring-objective equipment is output to the center monitor 1, and determines the distribution-objective other remote maintenance software and the local monitor 2 serving as a distributed side, to be distributed. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a remote maintenance software automatic distribution system and a remote maintenance software automatic distribution method for monitoring and maintaining the operating states of a plurality of devices installed in remote locations.

Remote maintenance software is stored in the central unit on the network and distributed to the local terminal via the network, so that multiple devices connected to the local terminal can be monitored efficiently from a remote location, A remote maintenance system for grasping and collecting data is known (see, for example, Patent Document 1).
JP 2002-189599 A

  However, the above conventional techniques have the following problems.

(1) Even if the remote maintenance software is upgraded in accordance with the latest monitoring / diagnostic algorithm, it cannot be automatically distributed to the local terminal and executed.

(2) Since the distribution is not performed in consideration of the operating environment of the local terminal and the monitoring target, the optimum remote maintenance software cannot be automatically selected and distributed.

(3) Even if an incident (such as a sign of failure) is detected at the distribution destination of the software, a design for autonomously taking measures against the incident is not provided. For example, it is not possible to change the startup cycle of remote maintenance software or distribute different remote maintenance software.

  In view of the above-mentioned problems of the prior art, the present invention can flexibly cope with (1) upgrade of remote maintenance software, (2) the remote maintenance software is automatically selected in consideration of the operating environment of the distribution destination, and (3) An object is to provide a remote maintenance software automatic distribution system and a remote maintenance software automatic distribution method capable of autonomously responding to an incident.

  The remote maintenance software automatic distribution system according to the present invention distributes remote maintenance software for monitoring and diagnosing equipment and remotely controls execution of the remote maintenance software, and connects to the center monitoring device via a network. The remote monitoring software is executed based on the control from the center monitoring device, and the local monitoring device outputs the incident information detected in the device to the center monitoring device. Stores the remote maintenance software distributed from the device, monitors the operating status of the equipment by executing the remote maintenance software, and outputs incident information, and the center monitoring the incident information output from this software management unit Send to device A local communication unit, and the center monitoring device includes at least a database unit for storing related information of remote maintenance software, configuration information of the local monitoring device, and incident information, and a center for receiving incident information from the local monitoring device The communication unit, the monitoring information analysis unit that analyzes the incident information received by the center communication unit, determines other remote maintenance software to be newly distributed, determines the distribution destination, and makes a distribution request, and the monitoring information analysis A request management unit that distributes other remote maintenance software to a distribution destination via a center communication unit based on a distribution request output from the unit.

  The remote maintenance software automatic distribution method according to the present invention includes a computer system in which a plurality of local monitoring devices are connected to a center monitoring device having remote maintenance software for monitoring and diagnosing equipment. The remote maintenance software distributed from the storage area is stored in the storage area, the operation status of the monitored device is monitored by executing the remote maintenance software, and the detected incident information is transmitted to the center monitoring device, and the center The monitoring device receives and analyzes the incident information transmitted from the local monitoring device, analyzes the incident information analysis step for determining other remote maintenance software to be newly distributed according to the analysis result, and the distribution destination, and the center Monitoring device analyzes And software distribution step for distributing other remote maintenance software to the deployment based on the results, characterized in that it has.

  According to the present invention, (1) the remote maintenance software can be flexibly upgraded, (2) the remote maintenance software is automatically selected in consideration of the operating environment of the distribution destination, and (3) Provided are a remote maintenance software automatic distribution system and a remote maintenance software automatic distribution method that can autonomously cope.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an example of the overall configuration of an embodiment of the present invention. As shown in the figure, the remote maintenance software automatic distribution system according to the present embodiment includes a center monitoring device 1 and a local monitoring device 2, and a plurality of local monitoring devices 2 are connected to the network 3 in the center monitoring device 1. Connected through. One or a plurality of monitoring target devices are connected to the local monitoring device 2 provided in the monitoring target area (Local # 1 to N).

  FIG. 2 is a block diagram showing an example of the overall configuration of an embodiment of the present invention. As shown in the figure, the center monitoring apparatus 1 includes a software storage unit 11, a software information registration unit 12, a database unit 13, a registration information analysis unit 14, a monitoring / notification management unit 15, a monitoring information analysis unit 16, and a request management. The computer includes a unit 17 and a center communication unit 18.

  The software storage unit 11 is a storage device that stores remote maintenance software that performs device monitoring, diagnosis, data collection, and the like in the local monitoring device 2. Specific examples of remote maintenance software include a monitoring program that monitors equipment / equipment and notifies abnormality, a diagnostic program that diagnoses the soundness of the equipment / equipment in more detail, and a data collection program that collects measurement data on the equipment. Can be mentioned.

  The software information registration unit 12 is a program for registering related information of remote maintenance software distributed to the local monitoring device 2. For example, related information such as a distribution destination parameter, a storage location, a distribution schedule, an execution schedule, and version information is extracted from information described in the code of the remote maintenance software and registered. It should be noted that a system administrator or the like may input the remote maintenance software from an input screen (not shown) when storing the remote maintenance software.

  The database unit 13 is a database that stores related information of remote maintenance software, configuration information of the local monitoring device 2 that is a distribution destination, information on monitored devices, incident information detected by the remote maintenance software, and the like.

  FIG. 3 is a block diagram illustrating a configuration example of the database unit 13. As shown in the figure, the database unit 13 includes an incident occurrence history table 13a, an incident / software correspondence table 13b, an incident definition table 13c, a device / software correspondence table 13d, a device table 13e, a registered software management table 13f, metadata. A management table 13g, a schedule management table 13h, an equipment failure probability table 13i, an incident occurrence probability table 13j, and a local configuration management table 13k are included.

  FIG. 4 is a diagram showing a specific example of the incident occurrence history table 13a. As shown in the figure, the incident occurrence history table 13a includes data items such as the ID of an incident that has occurred, the monitoring target area, the occurrence date and time, and the contents of diagnosis.

  FIG. 5 is a diagram showing a specific example of the incident / software correspondence table 13b. As shown in the figure, the incident / software correspondence table 13b associates the ID of the incident with the ID of the remote maintenance software that detects the incident.

  FIG. 6 is a diagram showing a specific example of the incident definition table 13c. As shown in the figure, the incident definition table 13c records an incident ID, an incident level, and a corresponding FTA (fault tree analysis) file name. For example, the FTA file “Indt-A.ft” indicates that the incident “INDT-A” is defined as the top event. Note that the FTA file is created in advance.

  FIG. 7 is a diagram showing a specific example of the device / software correspondence table 13d. As shown in the figure, the device / software correspondence table 13d associates the ID of the remote maintenance software with the ID of the device that outputs incident information (abnormal report).

FIG. 8 is a diagram illustrating a specific example of the device table 13e. As shown in the figure,
The device table 13e records the configuration of devices installed in each local area. For example, “device A”, “device B”, and “device C” are installed in the monitoring target area “Local # 1” and are shown to be monitored by the local monitoring device 2.

  FIG. 9 is a diagram showing a specific example of the registered software management table 13f. As shown in the figure, the registered software management table 13f stores the ID, software name, software type, version, registration date, creation date, storage destination, and the like of the remote maintenance software stored in the software storage unit 11 as data. Include in the item.

  FIG. 10 is a diagram illustrating a specific example of the metadata management table 13g. As shown in the figure, the metadata management table 13g includes data items such as ID, local compatible model, local terminal compatible OS, and local terminal minimum memory as remote maintenance software metadata.

  FIG. 11 is a diagram showing a specific example of the schedule management table 13h. As shown in the figure, the schedule management table 13h records a schedule for distribution and execution of remote maintenance software, and includes software ID, schedule ID, distribution date and time, execution date and time, etc. in the data items.

  FIG. 12 is a diagram illustrating a specific example of the device failure probability table 13i. As shown in the figure, the device failure probability table 13i includes data items including IDs of devices installed in the local area, device names, and failure probabilities for a certain period.

  FIG. 13 is a diagram illustrating a specific example of the incident occurrence probability table 13j. As shown in the figure, the incident occurrence probability table 13j includes, in the data item, an incident ID (incident of failure, etc.), an incident name, and an occurrence probability in a certain period.

  FIG. 14 is a diagram showing a specific example of the local configuration management table 13k. As shown in the figure, the local configuration management table 13k is a table for managing the hardware and software configurations of the local monitoring device 2, and includes the local area name, OS, memory capacity, and installed remote maintenance software. Information etc. are included in the data item. The remote maintenance software is managed by three generations of “current”, which is the current program, “standby” for update processing, and “backup” for backup, and enables generation reversion.

  The registration information analysis unit 14 is a program that analyzes the information in the database unit 13 and determines the distribution destination when a new remote maintenance software registration notification is received from the software information registration unit 12.

  The monitoring / notification management unit 15 receives monitoring information such as incident information (abnormality notification), diagnosis result, monitoring log and the like generated in the local monitoring device 2 received by the center communication unit 18 and outputs the monitoring information to the monitoring information analysis unit 16. It is a program. The response result (Ack) to the request is notified to the request management unit 17.

  The monitoring information analysis unit 16 analyzes the incident information received from the local monitoring device 2 and output from the monitoring / notification management unit 15 based on the information in the database unit 13, and links the estimated failure factor of the incident that has occurred. It is a program that determines incidents that can occur, remote maintenance software that deals with incidents, and distribution destinations. Note that the monitoring information analysis unit 16 in this embodiment analyzes incident information by linking the information in the database unit 13 and the FTA file. The FTA file is created in advance by the following procedure.

(1) First, define an undesirable event for the system. Specifically, the factors that cause the system to lose its function are selected by collecting information from those who are familiar with the environment of the system to be introduced. For example, incidents that occur frequently in the past, such as power loss, are defined.

(2) Identify the factors that cause the event. For example, when the incident is a loss of power, a disconnection, a battery failure, etc. are applicable.

(3) A failure tree diagram is created in which a causal relationship with an event that causes a system failure is expressed in a tree shape using logical symbols (OR and AND). This work itself is performed by screening causality.

(4) A failure probability is assigned to each event (for example, a failure rate is calculated based on a past history such as the number of failure occurrences / total operation time [/ hr]), and a value obtained by multiplying a periodic inspection cycle is defined as a failure probability. )
In analysis, Bayesian theory is preferably applied. Bayesian theory is a “theory that predicts future behavior based on past data”, where P (A) is the probability of occurrence of event A (prior probability), and P (A | X) is event X. Assuming that the conditional probability (posterior probability) that event A will occur later is P (X)> 0, P (A | X) = P (X | A) * P (A) / P (X) Can be represented.

  When a certain incident occurs (detects a sign of a failure), the incident that can occur in a chain is predicted by applying it to Bayesian theory. In addition, since the occurrence probability characterized for each monitoring target area can be calculated, it is useful for analyzing the installed environment and the like (selecting the tendency of failure that occurs in a chain). For example, when an incident X occurs in a certain monitoring target area, and an incident Y often occurs within a certain period, past statistical data is collected and quantitatively calculated by calculating the occurrence probability. I can express.

  The request management unit 17 distributes, deletes, replaces, and starts configuration information transmission command information and remote maintenance software to the local monitoring device 2 based on requests output from the registration information analysis unit 14 and the monitoring information analysis unit 16. A program that creates control information such as a stop and outputs the control information to the center communication unit 18 for transmission. In the case of a distribution request, the remote maintenance software main body is distributed. Requests such as distribution / deletion / update of remote maintenance software are stored in a buffer (not shown) for a certain period, and the request management unit 17 accesses the buffer at a certain period according to the scheduling function, retrieves the request, and retrieves the center. It is preferable to cause the communication unit 18 to perform transmission. Further, the request management unit 17 has a function of performing generation management and distribution history management of the remote maintenance software itself.

  The center communication unit 18 is a communication device that performs communication with the local monitoring device 2.

  The local monitoring device 2 is a computer that includes a local communication unit 21, a software management unit 22, a software storage unit 23, and a management information storage unit 24. For example, board PC etc. are mentioned.

  The local communication unit 21 is a communication device that performs communication with the center monitoring device 1.

  The software management unit 22 receives the software distributed from the center monitoring apparatus 1 and stores the received information in a predetermined location in the management information storage unit 24 and the software storage unit 23. The distributed remote maintenance software is managed by version information of three generations “standby”, “current”, and “backup”. In addition, the software management unit 22 executes start / stop of software and installation of an upgraded version according to a schedule stored in the management information storage unit 24 and control information (request) from the center monitoring apparatus 1. In addition, the software operation is constantly monitored, and when an illegal operation is detected, a log is output and notified to the center monitoring apparatus 1. Further, the software management unit 22 collects data from the monitoring target device and notifies the center monitoring device 1 of the data.

  The software storage unit 23 is a storage device that stores remote maintenance software distributed from the center monitoring apparatus 1.

  The management information storage unit 24 is a storage device that stores hardware and software configuration information of the local monitoring device 2, device monitoring logs, schedule information transmitted from the center monitoring device 1, and the like.

  FIG. 15 is a flowchart illustrating a specific example of processing in the software information registration unit 12.

  In step S1501, the software storage unit 11 is referenced to check for the presence of remote maintenance software.

  In step S1502, the presence / absence of newly registered remote maintenance software is determined. If there is newly registered remote maintenance software, the process advances to step S1503. On the other hand, if there is no newly registered remote maintenance software, the process ends.

  In step S1503, a registration API (function) prepared in advance is called, and information extracted from the remote maintenance software code is registered in the registration software management table 13f, the metadata management table 13g, and the schedule management table 13h.

  In step S1504, a new registration notification is output to the registration information analysis unit 14, and the process ends.

  FIG. 16 is a flowchart illustrating a specific example of processing in the registration information analysis unit 14.

  In S <b> 1601, a new registration notification is acquired from the software information registration unit 12.

  In S1602, the distribution software distribution table is determined with reference to the registered software management table 13f, metadata management table 13g, schedule management table 13h, and local configuration management table 13k in the database unit 13.

  In S1603, the distribution request for the remote maintenance software newly registered in the request management unit 17 is output, and the process ends.

  FIG. 17 is a diagram illustrating processing in the software information registration unit 12 and the registration information analysis unit 14. In the figure, “software X” data is acquired from the registered software management table 13 f, metadata management table 13 g, and schedule management table 13 h, and the local configuration management table 13 k is set to “Local # 5”. It is indicated that the registration information analysis unit 14 performs analysis processing by acquiring information indicating that “Software X” of “Ver. 1” has been distributed in the monitoring device 2. Furthermore, it is shown that the registration information analysis unit 14 outputs a distribution request for newly registered remote maintenance software to the request management unit 17.

  FIG. 18 is a flowchart illustrating a specific example of processing in the monitoring / notification management unit 15.

  In S1801, the reception information in the center communication unit 18 is acquired.

  In S1802, it is determined whether the received information is a response result to the request from the request management unit 17. If it is determined as a response result, the received information is notified to the request management unit 17 (S1803), and the process ends. On the other hand, if it is determined as monitoring information or diagnostic information, the received information is output to the monitoring information analysis unit 16 (S1804), and the process is terminated.

  FIG. 19 is a flowchart illustrating a specific example of processing in the monitoring information analysis unit 16. FIG. 20 is a diagram for explaining processing in the monitoring information analysis unit 16.

  In S1901, an incident (sign of failure) that is monitoring information detected by the local monitoring device 2 is acquired, and the incident is written in the incident occurrence history table 13a.

  In S1902, referring to the incident / software correspondence table 13b, the remote maintenance software (monitoring program) corresponding to the detected incident is confirmed, the incident definition table 13c is referred to, and the FTA file linked to the incident is checked. Read, the cause (device) of Incident A is determined. FIG. 20 shows that the incident is an abnormality sign of power supply equipment, and the cause is a cooling fan, disconnection, or the like.

  In S1903, the importance level for the incident A (contribution ratio to the incident A and the influence level at the time of failure) is obtained using the FTA file, and ranking is performed in the distribution of the remote maintenance software.

  In S1904, the device / software correspondence table 13d is referred to using the device identified as the cause of the incident in the FTA file as a key, and the remote maintenance software to be distributed and the distribution destination are determined. For example, in the case of FIG. 20, a cooling fan rotational speed diagnosis program or the like corresponds to this case. When there is a cause (device) in the constructed FTA file, all local monitoring devices 2 that use the device determined to be abnormal are referred to the metadata management table 13g and the device table 13e. A request to distribute remote maintenance software to the request management unit 17 is output.

  In S1905, the local configuration management table 13k is referred to and it is determined whether or not the remote maintenance software (diagnosis program or monitoring program) has been distributed in the local monitoring device 2 that is the distribution destination. If it is determined that the distribution has been completed, the process advances to step S1906. On the other hand, if it is determined that it has not been distributed, the processing proceeds to S1908.

  In step S1906, the local configuration management table is referenced to determine the activation status of the remote maintenance software. If it is determined that the vehicle is stopped, the process advances to S1907. On the other hand, if it is determined that it is being activated, the process is terminated.

  In step S1907, a request for starting remote maintenance software is output to the request management unit 17, and the process ends.

  In step S1908, a remote maintenance software distribution request is output to the request management unit 17, and the process ends.

  The execution result of the remote maintenance software distributed by the above processing in the local monitoring device 2 is notified again to the monitoring information analysis unit 16, and the analysis processing is repeatedly performed. That is, the distribution and execution of the remote maintenance software are autonomously performed based on the incident information detected by the remote maintenance software in a certain local monitoring device 2. Similarly, when the diagnosis result is acquired, the activation cycle of the remote maintenance software can be changed according to the diagnosis result.

  In addition, remote maintenance software using an FTA file is also distributed as preventive maintenance for occurrence of second and third incidents that can be caused by the specified cause of failure (device).

  In addition, if there is no incident cause (device) data in the constructed FTA file, the maintenance personnel are notified and the maintenance is performed, and the result is reflected in the FTA file to identify the cause of the failure after the next time. It is preferable to make use of it.

  FIG. 21 is a flowchart illustrating a specific example of processing in the request management unit 17.

  In S2101, a request from the registration information analysis unit 14 or the monitoring information analysis unit 16 is acquired.

  In S2102, transmission information corresponding to the request is created. For example, in the case of a remote maintenance software distribution request, control information including a distribution destination and execution schedule information is generated as transmission information together with distribution target software.

  In S2103, the transmission information is output to the center communication unit 18 to perform transmission processing.

  In S 2104, it is determined whether or not the response result from the local monitoring device 2 has been acquired from the monitoring / notification management unit 15. If a response result is acquired here, the process advances to step S2105. On the other hand, when a response result is not acquired, it waits until a response result is acquired.

  In S2105, whether or not the hardware or software configuration of the local monitoring device 2 has changed is determined based on the requested processing content and the response result.

  If there is a change in the local configuration information, the process proceeds to S2106. On the other hand, if there is no change in the local configuration, the process is terminated.

  In S2106, the local configuration management table 13k is updated, and the process ends. For example, the case where remote maintenance software is distributed to the local monitoring device 2 is applicable.

  FIG. 22 is a flowchart illustrating a specific example of processing in the center communication unit 18.

  In S2201, a transmission function or a reception function is selected.

  If transmission processing is selected here, the process advances to step S2202. On the other hand, if the reception process is selected, the process proceeds to S2205.

  In S2202, transmission information is acquired from the request management unit 17.

  In S2203, the local monitoring apparatus 2 is connected and information is transmitted.

  In S2204, when a response from the local monitoring device 2 is received, the connection is disconnected and the process is terminated.

  In S2205, the transmission information from the local monitoring device 2 is received.

  In step S2206, the reception information is output to the monitoring / notification management unit 15, and the process ends.

  FIG. 23 is a flowchart illustrating a specific example of processing in the local communication unit 21.

  In S2301, a transmission function or a reception function is selected.

  Here, if the transmission process is selected, the process proceeds to S2302. On the other hand, if the reception process is selected, the process proceeds to S2305.

  In S2302, transmission information is acquired from the software management unit 22.

  In S2303, it connects to the center monitoring apparatus 1 and transmits information.

  In S2304, when a response from the center monitoring apparatus 1 is received, the connection is disconnected and the process is terminated.

  In S2305, the transmission information from the center monitoring apparatus 1 is received.

  In S2306, the received information is output to the software management unit 22 and the process is terminated.

  FIG. 24 is a flowchart illustrating a specific example of module management in the software management unit 22.

  In S2401, the reception information is acquired from the local communication unit 21.

  In S2402, it is determined whether or not remote maintenance software is distributed.

  If it is determined that remote maintenance software is distributed, the process advances to step S2403. On the other hand, if it is determined that there is no distribution, the process is terminated.

  In S2403, the distributed remote maintenance software is stored in a predetermined storage area, and the process ends. The storage area for storing the remote maintenance software is provided corresponding to version information of three generations of “standby”, “current”, and “backup”.

  FIG. 25 is a flowchart illustrating a specific example of execution control in the software management unit 22.

  In S2501, the reception information is acquired from the local communication unit 21.

  In S2502, it is determined whether or not the received information is a remote maintenance software activation request that is stopped. If it is determined that the request is an activation request, the process advances to step S2503. On the other hand, if it is determined that the request is not an activation request, the process proceeds to S2504.

  In step S2503, the remote maintenance software that has been stopped is activated, and the process ends.

  In step S2504, it is determined whether the received information is a request for stopping the active remote maintenance software. Here, if it is determined to be a stop request, the process proceeds to S2505. On the other hand, if it is determined that the request is not a stop request, the process proceeds to S2506.

  In S2505, the remote maintenance software being activated is stopped, and the process is terminated.

  In step S2506, it is determined whether the received information is a remote maintenance software deletion / replacement request. If it is determined that the request is a deletion / replacement request, the process advances to step S2507. On the other hand, if it is determined that the request is not a deletion / replacement request, the process advances to step S2508.

  In S2507, the remote maintenance software is deleted / replaced based on the received information, and the process ends.

  In step S2508, it is determined whether the local configuration information transmission request is received. If it is determined that the transmission request is local configuration information, the process advances to step S2509. On the other hand, if it is determined that the request is not a transmission request for local configuration information, the process ends.

  In S2509, the configuration information is output and the process ends.

  FIG. 26 is a flowchart showing a specific example of data collection in the software management unit 22.

  In S2601, it is determined whether or not the remote maintenance software operation is invalid (error information). If it is determined that there is error information, the process advances to step S2602. On the other hand, if it is determined that there is no error information, the process proceeds to S2603.

  In step S2602, error information is output to the local communication unit 21, and the process ends.

  In S2603, it is determined whether there is an abnormal report from the monitoring target device. If it is determined that there is an abnormal report, the process proceeds to S2604. On the other hand, if it is determined that there is no abnormality report, the process proceeds to S2605.

  In S2604, an abnormal report (incident information) is output to the local communication unit 21, and the process ends.

  In S2605, the presence / absence of diagnostic information about the monitoring target device is determined. If it is determined that there is diagnostic information, the process proceeds to S2606. On the other hand, if it is determined that there is no diagnostic information, the process is terminated.

  In S2606, diagnostic information about the monitoring target device is output, and the process ends.

  In this way, remote maintenance software that automatically distributes detailed measurement data of equipment installed in the monitored area and diagnostic information such as the cause of failure is output, and the center monitoring device 1 has logic to perform analysis and determination. As a result, a failure can be prevented in advance.

  Further, by providing the local monitoring device 2 with a function of executing software, it is possible to quickly cope with the latest diagnostic algorithm and version upgrade.

  In addition, it is possible to reduce the burden on the system administrator by automatically distributing remote maintenance software such as a monitoring program and a data collection program to the local monitoring device 2 in accordance with the distribution plan and the execution / update plan.

  In addition, the function of automatically collecting and notifying the distributed remote maintenance software version information and the monitoring log according to the schedule makes it possible to detect human errors such as erroneous maintenance by field maintenance personnel.

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, the constituent elements over different embodiments may be appropriately combined.

  For example, the remote maintenance software automatic distribution system can be linked with other systems. FIG. 27 is a diagram illustrating a specific example of cooperation between the remote maintenance software automatic distribution system and another system. In the figure, data collected by the remote maintenance software automatic distribution system is centrally managed by the XML-DB of the data integration system. XML-DB stores and manages automatically distributed results. This provides a system administrator with a graphical interface and fast data retrieval. In addition, it is possible to reduce the burden on the system administrator by providing a maintenance chart function for displaying a chart and a reporting function provided as a report formatted in a fixed format.

  Further, the communication between the center monitoring device 1 and the local monitoring device 2 may be performed wirelessly as well as wired. In this case, there is an advantage that monitoring can be performed using a mobile device such as a mobile phone or a notebook personal computer as the local monitoring device 2.

The figure which shows the example of whole structure of the remote maintenance software automatic distribution system which concerns on one Embodiment of this invention. 1 is a block diagram showing an example of the overall configuration of a remote maintenance software automatic distribution system according to an embodiment of the present invention. The block diagram which shows the structural example of the database part 13 which concerns on one Embodiment of this invention. The figure which shows the specific example of the incident occurrence log | history table 13a which concerns on one Embodiment of this invention. The figure which shows the specific example of the incident software corresponding table 13b which concerns on one Embodiment of this invention. The figure which shows the specific example of the incident definition table 13c which concerns on one Embodiment of this invention. The figure which shows the specific example of the apparatus and software corresponding | compatible table 13d which concerns on one Embodiment of this invention. The figure which shows the specific example of the apparatus table 13e which concerns on one Embodiment of this invention. The figure which shows the specific example of the registration software management table 13f which concerns on one Embodiment of this invention. The figure which shows the specific example of the metadata management table 13g which concerns on one Embodiment of this invention. The figure which shows the specific example of the schedule management table 13h which concerns on one Embodiment of this invention. The figure which shows the specific example of the apparatus failure probability table 13i which concerns on one Embodiment of this invention. The figure which shows the specific example of the incident occurrence probability table 13j which concerns on one Embodiment of this invention. The figure which shows the specific example of the local structure management table 13k which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the software information registration part 12 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the registration information analysis part 14 which concerns on one Embodiment of this invention. The figure explaining the process in the software information registration part 12 and the registration information analysis part 14 which concern on one Embodiment of this invention. The flowchart which shows the specific example of the process in the monitoring and notification management part 15 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the monitoring information analysis part 16 which concerns on one Embodiment of this invention. The figure explaining the process in the monitoring information analysis part 16 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the request | requirement management part 17 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the center communication part 18 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the process in the local communication part 21 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the module management in the software management part 22 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the execution control in the software management part 22 which concerns on one Embodiment of this invention. The flowchart which shows the specific example of the data collection in the software management part 22 which concerns on one Embodiment of this invention. The figure which shows the specific example of cooperation of a remote maintenance software automatic distribution system and another system.

Explanation of symbols

1 ... Center monitoring device,
2 ... Local monitoring device,
11: Software storage unit,
12 ... Software information registration part,
13 ... Database section,
14 ... registered information analysis department,
15 ... Monitoring / notification management unit,
16: Monitoring information analysis unit,
17 ... request management part,
18 ... Center Communication Department,
21 ... Local communication department,
22 ... Software management department,
23. Software storage unit,
24. Management information storage unit,
13a ... Incident occurrence history table,
13b ... Incident / software correspondence table,
13c ... Incident definition table,
13d: Device / software correspondence table,
13e ... Equipment table,
13f ... registered software management table,
13g ... metadata management table,
13h ... Schedule management table,
13i ... Equipment failure probability table,
13j: Incident occurrence probability table,
13k: Local configuration management table.

Claims (5)

A center monitoring device that distributes remote maintenance software for monitoring and diagnosing equipment and remotely controls execution of the remote maintenance software;
A local network is connected to the center monitoring device via a network, executes the distributed remote maintenance software based on control from the center monitoring device, and outputs incident information detected in the device to the center monitoring device. A monitoring device,
The local monitoring device is
A software management unit that stores the remote maintenance software distributed from the center monitoring device, monitors the operating state of the device by executing the remote maintenance software, and outputs the incident information;
A local communication unit that transmits the incident information output from the software management unit to the center monitoring device;
Comprising
The center monitoring device is
A database unit for storing at least related information of the remote maintenance software, configuration information of the local monitoring device, and the incident information;
A center communication unit that receives the incident information from the local monitoring device;
Other remote maintenance software that analyzes the incident information received by this center communication unit and newly distributes it, determines its distribution destination, and a monitoring information analysis unit that makes a distribution request,
A request management unit that distributes the other remote maintenance software to the distribution destination via the center communication unit based on the distribution request output from the monitoring information analysis unit;
A remote maintenance software automatic distribution system characterized by comprising: The center monitoring device further includes:
A software information registration unit for registering related information of the newly registered remote maintenance software in the database unit;
Analyzing related information registered in this software information registration unit to determine a distribution destination of the remote maintenance software from among the plurality of local monitoring devices, a registration information analysis unit for making a distribution request to the request management unit,
The remote maintenance software automatic distribution system according to claim 1, further comprising:   The remote maintenance software automatic distribution system according to claim 1 or 2, wherein the monitoring information analysis unit performs the analysis by referring to an FTA file in which a causal relationship between the incident information and the device is defined in advance. . In a computer system in which a plurality of local monitoring devices are connected to a center monitoring device having remote maintenance software for monitoring and diagnosing equipment,
The local monitoring device stores the remote maintenance software distributed from the center monitoring device in a storage area, monitors the operating state of the monitored device by executing the remote maintenance software, and detects the detected incident information. Incident information transmission step to be transmitted to the center monitoring device;
Incident information analyzing step in which the center monitoring device receives and analyzes the incident information transmitted from the local monitoring device, and determines other remote maintenance software to be newly distributed according to the analysis result, and the distribution destination When,
A software distribution step in which the center monitoring apparatus distributes the other remote maintenance software to the distribution destination based on the result of the analysis;
A remote maintenance software automatic distribution method characterized by comprising: A software information registration step in which the center monitoring device registers the related information of the newly registered remote maintenance software in a database;
A registration information analyzing step in which the center monitoring device analyzes the related information registered in the database and determines a distribution destination of the remote maintenance software from among the local monitoring devices connected to the center monitoring device;
A second software distribution step of distributing the newly registered remote maintenance software to the determined distribution destination;
The remote maintenance software automatic distribution method according to claim 4, further comprising: