JP6525275B2 - Management device, information processing method, and program - Google Patents

Description

  The present invention relates to a management apparatus, an information processing method, and a program.

  When a failure occurs in software (software program) or hardware installed in an information processing apparatus (computer), electronic device, etc., the failure may be resolved by upgrading the version of the software or the hardware. . Therefore, in order to eliminate the failure, a worker who performs maintenance work may confirm the necessity of upgrading the software and hardware and may upgrade the software and hardware as appropriate. Then, after the version upgrade of software and hardware is completed, the operator repairs.

  In addition, when software and hardware needs to be upgraded in two or more stages, the worker can upgrade the versions in order, starting with the version currently installed in the device targeted for version upgrade. Do the work of Therefore, with respect to software and hardware, as the number of stages of versions to be upgraded increases, the working time of the worker increases in version upgrade work. Therefore, techniques have been proposed to reduce the working time of the worker in upgrading software and hardware (Patent Documents 1 and 2).

  In Patent Document 1, based on the fault content of software, the fault software is extracted, the current functional version number of the software is compared with the latest functional version number of the software in the patch information, and the patch of the version number difference Describes a technique for extracting and outputting.

  In Patent Document 2, in the hardware maintenance or hardware periodic inspection of a server targeted for maintenance management, the maintenance management server corresponds to a server corresponding to a reservation of hardware maintenance or hardware periodic inspection based on customer information. Techniques to direct to are described. Furthermore, in the technology described in Patent Document 2, when software update of a server that is a target of maintenance management occurs in the maintenance management server, whether the software update can be selected or not based on the customer information is given to the corresponding server. The technology to notify is described. Then, in the technology described in Patent Document 2, the maintenance management server performs an operation for hardware maintenance or hardware inspection of a server that is a target of maintenance management, or executes software update.

Unexamined-Japanese-Patent No. 2002-197170 JP, 2008-027149, A

  The disclosure of the above prior art documents is incorporated herein by reference. The following analysis is made from the point of view of the present invention.

  As described above, when a worker performs version upgrade of two or more stages with regard to software and hardware, as the number of stages of the version upgrade version increases, the worker's work time and workload increase.

  Furthermore, upgrading software or hardware by more than one stage may involve redundant work. For example, when upgrading a hardware version, a worker installs a part when upgrading one version, then removes the installed part when upgrading another version, and ends the upgrading work. There is. In that case, the work of attaching parts and the work of removing the same parts are redundant work.

  Also, for example, in the case of software version upgrade, it may be necessary to restart the device after executing the version upgrade patch program. In that case, if the device is restarted every time after execution of each patch program, the device may be restarted more than necessary. In that case, restarting the device more than necessary is a redundant process.

  In Patent Document 1, the details of the version difference patch to be output are not considered at all. That is, in Patent Document 1, it is not described at all whether or not the patch of the version number difference to be output includes redundant processing. Therefore, in the technique described in Patent Document 1, there is a possibility that redundant processing may be performed, and there is a possibility that the version of the device can not be efficiently upgraded.

  In Patent Document 2, details of work for hardware maintenance or hardware inspection and details of processing at the time of software update are not considered at all. That is, Patent Document 2 does not describe at all whether the operation for hardware maintenance or hardware inspection and the process at the time of software update include redundant operations and redundant operations. Therefore, even in the technique described in Patent Document 2, there is a possibility that redundant processing may be performed, and there is a possibility that the version of the device can not be efficiently upgraded.

  Then, this invention aims at providing the management apparatus, information processing method, and program which contribute to upgrading a device efficiently.

According to a first aspect of the present invention, a management device is provided. The management apparatus identifies two or more pieces of version upgrade information corresponding to the version upgrade from the first version to the second version with respect to software and / or hardware installed in the maintenance target device. A processing unit is provided. The version upgrade information includes action information for version upgrade. The version upgrade processing unit outputs information obtained by deleting the redundant action information from the identified version upgrade information and accumulating the version upgrade information.
As a modification of the first aspect, regarding software and / or hardware installed in the maintenance target device, two or more pieces of version upgrade information corresponding to the version upgrade from the first version to the second version are specified. A version upgrade processing unit, wherein the version upgrade information includes action information for version upgrade, and the redundant action information, a combination of redundant action information, and redundant conditions of the action information at least The version upgrade processing unit further determines whether the identified version upgrade information includes redundant action information, based on the redundant action database, further including a redundant action database that stores any of them. Contains redundant action information If, from the identified said upgrade information, deleting redundant the action information, and outputs the cumulative upgrade information.

According to a second aspect of the present invention, an information processing method is provided. In the information processing method, a management apparatus including a storage unit that stores version upgrade information, including action information for version upgrade regarding software and / or hardware, relates to the software and / or the hardware, A step of identifying two or more pieces of version upgrade information corresponding to the version upgrades from the first version to the second version is included.
Further, the information processing method includes the step of the management apparatus outputting accumulated version upgrade information in which redundant action information is deleted from the identified version upgrade information.
Note that the method is linked to a specific machine, which is a management device that manages action information for upgrading software and / or hardware.
As a modification of the second aspect, with regard to software and / or hardware, a combination of version upgrade information including redundant version action information, redundant version of the action information, redundant version of the action information, redundant version A management apparatus comprising: a storage unit storing a redundant action database storing at least one of conditions of action information, the first version to the second version with respect to the software and / or the hardware Identifying two or more pieces of version upgrade information corresponding to version upgrades, and whether the version upgrade information identified by the management device based on the redundant action database includes redundant the action information Determining whether the pipe Apparatus, may include redundant the action information, from said upgrade information identified, including deleting redundant the action information, and outputting a cumulative upgrade information.

According to a third aspect of the present invention, a program is provided. The program is a program that is executed by a computer that controls a management apparatus and includes a storage unit that stores version upgrade information, including action information for version upgrade regarding software and / or hardware. The program causes the computer to execute processing for specifying two or more pieces of upgrade information corresponding to the upgrade from the first version to the second version with respect to the software and / or the hardware.
Further, the program causes the computer to execute processing of outputting accumulated version upgrade information in which redundant action information is deleted from the specified version upgrade information.
As a modification of the third aspect, with regard to software and / or hardware, a combination of version upgrade information including redundant version action information, redundant version of the action information, redundant version of the action information, redundant version A program that is executed by a computer that controls a management apparatus, comprising: a storage unit that stores a redundant action database that stores at least one of conditions of action information, the software, and / or the hardware Processing of identifying two or more pieces of version upgrade information corresponding to version upgrades from the first version to the second version, and the version upgrade information identified based on the redundant action database is redundant Action information A process of determining whether or not it is included, and a process of outputting accumulated version upgrade information in which redundant action information is deleted from the identified version upgrade information when the redundant action information is included; Run it.
The program can be recorded on a computer readable storage medium. The storage medium can be non-transient such as a semiconductor memory, a hard disk, a magnetic recording medium, an optical recording medium, and the like. The invention can also be embodied as a computer program product.

  According to each aspect of the present invention, a management device, an information processing method, and a program that contribute to efficiently upgrading a device are provided.

It is a figure for explaining an outline of one embodiment. FIG. 1 is a block diagram showing an example of the entire configuration of a management system 10. It is a block diagram which shows an example of an internal structure of the management apparatus 100 and worker terminal 300 which concern on 1st Embodiment. It is a figure which shows an example of a restart necessity level. It is a figure which shows an example of the repair database. It is a figure which shows an example of the apparatus database 109 which concerns on 1st Embodiment. It is a figure which shows an example of the redundant action database 110 which concerns on 1st Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 1st Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 1st Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 1st Embodiment. It is a block diagram which shows an example of an internal structure of the management apparatus 100 and worker terminal 300 which concern on 2nd Embodiment. It is a figure which shows an example of the design information database 111 which concerns on 2nd Embodiment. It is a figure which shows an example of the apparatus database 109 which concerns on 2nd Embodiment. It is a figure which shows an example of the redundant action database 110 which concerns on 2nd Embodiment. It is a figure which shows an example of the redundant action database 110 which concerns on 2nd Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 2nd Embodiment. It is a block diagram which shows an example of an internal structure of the management apparatus 100 and worker terminal 300 which concern on 3rd Embodiment. It is a figure which shows an example of the design information database 111 which concerns on 3rd Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 3rd Embodiment. It is a block diagram which shows an example of an internal structure of the management apparatus 100 and the worker terminal 300 which concern on 4th Embodiment. It is a figure which shows an example of the disorder | damage | failure database 114 which concerns on 4th Embodiment. It is a flowchart which shows an example of a process of the management system 10 which concerns on 4th Embodiment. It is a block diagram which shows an example of an internal structure of the management apparatus 100 and the worker terminal 300 which concern on 5th Embodiment.

  First, an outline of one embodiment will be described with reference to FIG. The reference symbols of the drawings appended to this summary are added for convenience to each element as an example for aiding understanding, and the description of the summary is not intended to be limiting in any way. Also, connection lines between blocks in each block diagram include both bidirectional and unidirectional directions.

  As described above, there is a need for a management device that contributes to efficient device version upgrades.

  Then, the management apparatus 1 shown in FIG. 1 is provided as an example. The management device 1 includes two or more pieces of version upgrade information (3a shown in FIG. 1) corresponding to the version upgrade from the first version to the second version with respect to software and / or hardware installed in the maintenance target device. A version upgrade processing unit 2 is provided which specifies ~ 3d).

  Here, the maintenance target device is an information processing device (computer) or the like which is different from the management device 1. The first version means the version of software and / or hardware currently installed in the maintenance target device. Also, the second version means a version newer than the first version. In the following description, each version upgrade information is described as version upgrade information 3 when it is not necessary to distinguish each version. Moreover, although four version upgrade information 3 is shown in FIG. 1 for convenience of explanation, this is not the meaning which limits version upgrade information to four.

  The version upgrade information 3 includes action information (4a to 4d shown in FIG. 1) for version upgrade.

  Here, the action for version upgrade means a process, an operation, etc. performed for the version upgrade of software and / or hardware. The action information 4a to 4d for version upgrade is information for specifying an action for version upgrade. In the following description, action information for version upgrade is also simply referred to as action information. In the following description, each piece of action information is referred to as action information 4 when it is not necessary to distinguish them. In addition, although four action information 4 is shown in FIG. 1 for convenience of explanation, this is not the meaning which limits the action information 4 to four.

  The version upgrade processing unit 2 outputs accumulated version upgrade information 5 from which redundant action information is deleted from the identified version upgrade information 3. Redundant action information is information indicating redundant processing, redundant work, contradictory processing, and contradictory work. The accumulated version upgrade information 5 is information obtained by accumulating version upgrade information 3 in which redundant action information is deleted from the identified version upgrade information 3.

  For example, referring to FIG. 1, it is assumed that the version upgrade processing unit 2 specifies version upgrade information 3a to 3d. Then, it is assumed that the action information 4 a included in the version upgrade information 3 a and the action information 4 b included in the version upgrade information 3 b are redundant action information. In this case, the version upgrade processing unit 2 deletes the version upgrade information 3a, 3b including the redundant action information 4a, 4b from the version upgrade information 3a to 3d, and selects the version upgrade information 3c, 3d.

  Then, the version upgrade processing unit 2 generates and outputs accumulated version upgrade information 5 in which the version upgrade information 3 c and 3 d are accumulated. As a result, the management device 1 can output information indicating processes and operations that are not redundant among processes and operations performed to upgrade the software and / or hardware.

  And a worker and / or maintenance object apparatus can avoid performing useless processing and work by performing the work and processing for version upgrade based on the information which management device 1 outputs. Accordingly, the management device 1 contributes to efficiently upgrading the device.

First Embodiment
The first embodiment will be described in more detail using the drawings. In the following description, for convenience of explanation, information for identifying a maintenance target device and information for identifying a component will be expressed as a device name and a component name. The information for identifying the maintenance target device and the information for identifying the part may be a number, ID (Identification) or the like, and the details thereof are not limited as long as the device and the part can be identified.

  FIG. 2 is a block diagram showing an example of the entire configuration of the management system 10 according to the present embodiment. The management system 10 includes a management apparatus 100, one or more maintenance target devices 200, and one or more worker terminals 300. FIG. 2 is an example of the management system 10 according to the present embodiment, and the management system 10 according to the present embodiment is not limited to the configuration shown in FIG.

  The maintenance target device 200 is an information processing apparatus (computer), a board (electronic circuit board), or the like which is a maintenance target. Here, maintenance includes upgrading the software installed in the maintenance target device 200. Information for identifying each maintenance target device 200 is assigned to each maintenance target device 200. In the following description, it is assumed that an equipment name for identifying each maintenance target device 200 is assigned to each maintenance target device 200.

  The management device 100 is an information processing device (computer) that manages information related to the maintenance target device 200. Specifically, the management device 100 manages information on version upgrade of the maintenance target device 200 and information on a failure of the maintenance target device 200.

  Further, the management apparatus 100 supports the version upgrade process of the maintenance target device 200 using the information on the version upgrade of the maintenance target device 200. For example, the management apparatus 100 may manage a patch program required to upgrade the software installed in the maintenance target device 200. Then, the patch program may be transmitted to the maintenance target device 200. Then, the management apparatus 100 may control the process in which the maintenance target device 200 executes the patch program.

  The worker terminal 300 is an information processing apparatus (computer) operated by a worker who performs maintenance work and the like of the maintenance target device 200. The worker terminal 300 may be a personal computer (PC), a smartphone, a tablet terminal or the like, and the details thereof are not limited as long as the functions described in this document can be realized.

  The worker terminal 300 transmits information on the maintenance target device 200 to the management apparatus 100 via the network 20. For example, the worker terminal 300 may acquire the number of a slip related to a request for repair of the maintenance target device 200 (hereinafter, referred to as “repair slip number”) through the operation of the user. Then, the worker terminal 300 may transmit the repair slip number of the maintenance target device 200 to the management apparatus 100 via the network 20.

  Further, the worker terminal 300 requests the management apparatus 100 for information necessary for the maintenance of the maintenance target device 200 (hereinafter, referred to as “maintenance information”). Then, the management device 100 transmits the maintenance information of the maintenance target device 200 to the worker terminal 300 in response to the request. Then, the worker terminal 300 presents the received maintenance information to the user. The maintenance information may include information necessary to upgrade the maintenance target device 200. The maintenance information may also include information such as the device name, version, serial number, year of manufacture, and fault details of the maintenance target device 200.

  The management device 100 connects to one or more worker terminals 300 and one or more maintenance target devices 200 via the network 20. The network 20 may be the Internet, an intranet, a LAN (Local Area Network), or the like. There are various methods for realizing the network 20, but the details are not important. Depending on the implementation of the management system 10, the method of the network 20 is assumed to be different. Also, it goes without saying that the network method for connecting the management apparatus 100 and the maintenance target device 200 and the network method for connecting the management apparatus 100 and the worker terminal 300 may be different network methods.

  Next, with reference to FIG. 3, the internal configurations of the management device 100 and the worker terminal 300 according to the present embodiment will be described in detail. FIG. 3 is a block diagram mainly describing modules related to the management apparatus 100 and the worker terminal 300 according to the present embodiment. The management apparatus 100 and the worker terminal 300 may include modules (software, hardware) other than the modules shown in FIG.

  First, the internal configuration of the worker terminal 300 will be described with reference to FIG. The worker terminal 300 includes a communication unit 301, a control unit 302, an output unit 303, and an input unit 304. Furthermore, the worker terminal 300 is configured to include a memory (not shown) that stores information necessary for operating the worker terminal 300.

  The communication unit 301 controls the communication function of the worker terminal 300. The communication unit 301 is realized using an NIC (Network Interface Card) or the like.

  The output unit 303 outputs information to the outside. Specifically, when the control unit 302 acquires maintenance information of the maintenance target device 200 from the management apparatus 100, the output unit 303 outputs the acquired maintenance information. For example, the output unit 303 may output maintenance information of the maintenance target device 200 to a display device (not shown), a printing device (not shown) or the like.

  The input unit 304 receives an input operation of the user of the worker terminal 300. For example, the input unit 304 is realized using a keyboard, a mouse, a touch panel, and the like. The input unit 304 passes the received input to the control unit 302.

  Control unit 302 controls processing for operating worker terminal 300. The control unit 302 is realized by using a CPU (Central Processing Unit) or the like.

  The user of the worker terminal 300 may use the input unit 304 to input information on version upgrade of the maintenance target device 200 and information on a failure of the maintenance target device 200. Then, the control unit 302 of the worker terminal 300 may transmit the input information to the management apparatus 100 via the communication unit 301.

  Next, the internal configuration of the management apparatus 100 will be described with reference to FIG. The management apparatus 100 includes a communication unit 101, a control unit 102, an output unit 103, an input unit 104, and a storage unit 105. The storage unit 105 stores the version upgrade processing unit 106, the repair database 108, the device database 109, and the redundant action database 110. Also, the version upgrade processing unit 106 stores a version upgrade processing program 107.

  The communication unit 101 controls the communication function of the management apparatus 100. The communication unit 101 is realized using an NIC (Network Interface Card) or the like.

  The output unit 103 outputs the processing result executed by the program to the outside. For example, the output unit 103 may output the processing result executed by the program to a display device (not shown), a printing device (not shown) or the like.

  The input unit 104 receives an input operation of the user of the management apparatus 100. For example, the input unit 104 is realized using a keyboard, a mouse, a touch panel, and the like. The input unit 104 passes the received input to the control unit 102.

  The storage unit 105 stores information necessary for operating the management apparatus 100. The storage unit 105 is realized by a magnetic disk device, an optical disk device, or a semiconductor memory. The semiconductor memory is, for example, a solid state drive (SSD), may use a flash memory, or may include a dynamic random access memory (DRAM). Details of the modules stored in the storage unit 105 will be described later.

  The control unit 102 controls processing for operating the management apparatus 100. The control unit 102 is realized using a CPU or the like. The control unit 102 calls a program stored in the storage unit 105 and executes processing. Hereinafter, for convenience of description, that the control unit 102 calls a program stored in the storage unit 105 and executes a process is expressed as “the program executes the process”.

  As described above, the worker terminal 300 may transmit, to the management apparatus 100, the information on the version upgrade of the maintenance target device 200 and the information on the failure of the maintenance target device 200. Then, the control unit 102 may obtain, via the communication unit 101, information on version upgrade of the maintenance target device 200 and information on a failure of the maintenance target device 200.

  Alternatively, a manager of the maintenance target device 200, a maintenance person in charge, or the like may use the input unit 104 to input information on the version upgrade of the maintenance target device 200. Then, the control unit 102 may acquire information on the version upgrade of the maintenance target device 200 via the input unit 104.

  Specifically, the information on the version upgrade according to the present embodiment includes the device name and version of the maintenance target device 200, a patch program for version upgrade, and information on the necessity of restarting the maintenance target device 200. . In the following description, information on the necessity of restarting the maintenance target device 200 will be referred to as a restart necessity level. Details of the restart necessity level will be described later.

  In addition, the operator who has received the repair request for the maintenance target device 200, the worker who has completed the maintenance work, or the like may input information on the failure of the maintenance target device 200 using the input unit 104. Then, the control unit 102 may acquire information on a failure of the maintenance target device 200 via the input unit 104. Specifically, the information related to the failure according to the present embodiment may include information such as the device name, version, serial number, manufacturing year, and failure content of the maintenance target device 200.

  Then, when the control unit 102 acquires the information on the version upgrade of the maintenance target device 200, the control unit 102 stores the information on the version upgrade in the device database 109. That is, the device database 109 stores the device name and version of the maintenance target device 200, a patch program for upgrading the version, and information on the necessity of restarting the maintenance target device 200.

  In addition, when the control unit 102 acquires information on a failure of the maintenance target device 200, the control unit 102 stores information on the failure in the repair database 108. That is, the repair database 108 stores information such as the device name, version, serial number, manufacturing year, fault contents, etc. of the maintenance target device 200.

  Hereinafter, each module stored in the storage unit 105 will be described in detail.

  The version upgrade processing unit 106 specifies two or more pieces of version upgrade information corresponding to the version upgrade from the first version to the second version regarding software and / or hardware installed in the maintenance target device 200. . Each version upgrade information includes action information for version upgrade.

  That is, the first version corresponds to the version before the version upgrade with regard to the software to be upgraded. The second version corresponds to the version after the version upgrade of the software to be upgraded.

  In the following description, it is assumed that the first version is the version currently mounted on the maintenance target device 200. Also, as described above, the second version is a version newer than the first version. For example, the second version may be the latest version corresponding to software to be upgraded. Also, the second version may not be the latest version, but may be a version newer than the first version, and a version etc. that is practically guaranteed that the operation of the software becomes stable. .

  Further, in the case of software version upgrade, the action for version upgrade includes executing a patch program for version upgrade, restarting the device after executing the patch program, and the like.

  Here, the patch program is a program provided by the corresponding software maker. The patch program is a program for upgrading the corresponding software in one or more stages. Also, the patch program may be a program in which two or more programs are packaged together. In the following description, each patch program includes a program for upgrading a version of two or more stages and a program in which two or more programs are packaged together.

  Further, in the software version upgrade, the version upgrade information is information in which the information identifying the patch program is associated with the restart necessity level of the device. Here, the information for identifying a patch program is the name of a patch program for upgrading at least one version of the first version to the second version. Further, the restart necessity level is information indicating the necessity of restarting the device in the period from the application of the patch program to the device to the application of another patch program.

  Then, the version upgrade processing unit 106 outputs accumulated version upgrade information in which redundant action information is deleted from the identified version upgrade information. As described above, redundant action information is information indicating redundant processing, redundant work, contradictory processing, and contradictory work. Further, as described above, the cumulative version upgrade information is information obtained by accumulating version upgrade information in which redundant action information is deleted from the identified version upgrade information.

  FIG. 4 is a diagram showing an example of the restart necessity level. Specifically, FIG. 4 shows that when the reboot necessity level is 1, rebooting the device is optional after executing the patch program. Further, FIG. 4 shows that when the restart necessity level is 2, it is necessary to restart the device at any timing after applying the patch program. Further, FIG. 4 shows that when the restart necessity level is 3, it is necessary to restart the device after executing the patch program and before executing another patch program. In the following description, for convenience of explanation, the restart necessity level is assumed to be the information shown in FIG. However, FIG. 4 is not the meaning which limits a restart necessity level to the kind shown in FIG.

  The repair database 108 stores information on a request for repair of the maintenance target device 200. For example, the repair database 108 may store the repair slip number, the device name, the currently installed version, the manufacturing number, the manufacturing year, the failure content, and the part replacement history in association with one another.

  FIG. 5 shows an example of the repair database 108. As shown in FIG. For example, FIG. 5 shows that the repair slip number “1234567890” corresponds to the maintenance target device 200 of the device name “A”. Further, FIG. 5 shows that the maintenance target device 200 corresponding to the repair slip number “1234567890” is currently loaded with software of version = 1. Furthermore, FIG. 5 shows that the maintenance target device 200 corresponding to the repair slip number “1234567890” has not performed parts replacement. Further, for example, FIG. 5 shows that the parts c and f have been replaced in the maintenance target device 200 corresponding to the repair slip number “1234567894”.

  The device database 109 stores version upgrade information of software installed in the maintenance target device 200. Specifically, the device database 109 includes information for identifying a device, a third version that matches the second version, or a newer version than the second version, and version upgrade information for upgrading to a third version. And are stored in association with each other.

  The device database 109 also stores one or more patch programs corresponding to the software installed in the maintenance target device 200.

  For example, the management apparatus 100 may monitor a website of a software maker that provides a patch program. Then, when the software maker releases (releases) a patch program of a new version, the management device 100 acquires the patch program of the new version from the website of the software maker or the like, and acquires the patch program in the device database 109. You may store a patch program. Alternatively, the administrator of the management apparatus 100, the maintenance person of the maintenance target device 200, or the like may appropriately register a new version of the patch program in the device database 109. Then, when the management apparatus 100 stores a new patch program in the device database 109, the administrator of the management apparatus 100, the person in charge of maintenance of the maintenance target device 200, etc. have a restart necessity level corresponding to the patch program. You may set it.

  FIG. 6 shows an example of the device database 109. As shown in FIG. The device database 109 illustrated in FIG. 6 indicates information in which the device name, the latest version (the third version described above), and the version upgrade information are associated with each other. Further, the version upgrade information shown in FIG. 6 is information in which the pre-update version, the post-update version, and the action information for upgrading the corresponding pre-update version to the post-update version are associated. For example, in FIG. 6, in the maintenance target device 200 of the device name “A”, the version upgrade information corresponding to the version upgrade from version 1 to version 2 is the action information “execute patch program x1” and “restart” It is shown that “restart necessity level 2)” is included.

  The redundant action database 110 stores at least one of redundant action information combinations and redundant action information conditions. When redundant action database 110 stores redundant action information conditions, whether redundant processing after applying a patch program has redundant action information based on the order of restart necessity level is redundant action database 110? Stores the condition to determine whether or not.

  FIG. 7 shows an example of the redundant action database 110. As shown in FIG. The condition shown in FIG. 7 is an example, and the determination condition of redundant action information is not limited to the condition shown in FIG.

  Condition number 0001 shown in FIG. 7 indicates that the condition number is "when the number of times of execution of the patch program of restart necessity level 2 is more than one before the execution of the patch program of restart necessity level 3". Indicates that the condition of 0001 is satisfied. Then, FIG. 7 shows that the version upgrade processing unit is that “the restart processing corresponding to the patch program of the restart necessity level = 2 is redundant action information” when the condition of the condition number 0001 is satisfied. 106 indicates to make a decision.

  In addition, condition number 0002 shown in FIG. 7 indicates that “the number of times the patch program with restart necessity level 2 is executed more than once and the number of restart necessity level 3 is 0” in the entire version upgrade information. Indicates that the condition of the condition number 0002 is satisfied. Then, FIG. 7 shows that, when the condition of the condition number 0002 is satisfied, “the restart processing corresponding to the patch program of the restart necessity level 2 is performed one last time”. Further, FIG. 7 shows that when the condition of the condition number 0002 is satisfied, “restart processing other than the last among the restart processing corresponding to the patch program of restart necessity level 2 is redundant action information”. Indicates that the version upgrade processing unit 106 determines that the

  Further, condition number 0003 shown in FIG. 7 satisfies the condition number 0003 when "the number of times the patch program with restart necessity level 1 has been executed is 1 or more in the entire version upgrade information". Indicates Then, in FIG. 7, when the condition of the condition number 0003 is satisfied, the version upgrade processing unit 106 states that “the restart processing corresponding to the patch program of the restart necessity level 1 is redundant action information”. Indicates that it makes a decision.

  The version upgrade processing unit 106 will be described in more detail below.

  The version upgrade processing unit 106 identifies two or more pieces of upgrade information. Here, each of the version upgrade information specified by the version upgrade processing unit 106 corresponds to the version upgrade of at least one version. Specifically, the version upgrade processing unit 106 acquires, from the device database 109, one or more versions of upgrade information corresponding to version upgrades from the first version to the second version. Further, the version upgrade processing unit 106 acquires, from the device database 109, a patch program corresponding to the version upgrade from the first version to the second version.

  Then, the version upgrade processing unit 106 rearranges the specified version upgrade information such that the corresponding versions are in ascending order or descending order, and generates rearranged version upgrade information as a version upgrade information sequence. Then, the version upgrade processing unit 106 deletes redundant action information from the version upgrade information string based on the redundant action database 110 and cumulative version upgrade based on the version upgrade information string from which redundant action information is removed. Generate information.

  The storage unit 105 also stores a version upgrade processing program 107. The version upgrade processing program 107 is a program that causes the control unit 102 to execute the processing of the version upgrade processing unit 106.

  Next, the operation of the management system 10 according to the present embodiment will be described in detail. In the following description, the target device refers to the maintenance target device 200 that is the target of version upgrade.

  FIG. 8 is a flowchart showing an example of processing for identifying version upgrade information.

  First, the user of the worker terminal 300 inputs the repair slip number corresponding to the target device to be upgraded to the worker terminal 300. In that case, the worker terminal 300 transmits the input repair slip number to the management device 100 (step A001). Then, the management device 100 receives the repair slip number from the worker terminal 300 (step A002).

  In step A 003, the version upgrade processing unit 106 determines whether the received repair slip number is registered in the repair database 108 or not. If the received repair slip number is registered in the repair database 108 (YES branch at step A003), the process proceeds to step A004. On the other hand, when the received repair slip number is not registered in the repair database 108 (NO in step A003), the process of upgrading the target device is ended.

  In step A 004, the version upgrade processing unit 106 extracts the device name and version (that is, the first version) of the target device from the repair database 108 based on the repair slip number.

  In step A 005, the version upgrade processing unit 106 determines whether the device name of the extracted target device is registered in the device database 109. If the device name of the extracted target device is registered in the device database 109 (YES branch at step A005), the process proceeds to step A006. On the other hand, when the device name of the extracted target device is not registered in the device database 109 (NO in step A005), the process of upgrading the version of the target device is ended.

  In step A006, the version upgrade processing unit 106 extracts the latest version (the third version described above) and the version upgrade information from the device database 109 based on the device name.

For example, it is assumed that the version of the target device of device name “A” is upgraded from version = 1 to version = 5. Then, the version upgrade processing unit 106 refers to the device database 109 shown in FIG. In that case, the version upgrade processing unit 106 extracts the following version upgrade information (1) to (4) from the device database 109.
Version upgrade information (1): version before update = 1, version after update = 2
Action information (1-1): Execute patch program x1
Action information (1-2): restart (restart necessity level = 2)
Version upgrade information (2): version before update = 2, version after update = 3
Action information (2-1): Execute patch program x 2
Action information (2-2): restart (restart necessity level = 2)
Version upgrade information (3): version before update = 3, version after update = 4
Action information (3-1): Execute patch program x3
Action information (3-2): restart (restart necessity level = 3)
Version upgrade information (4): "Version before update = 4, Version after update = 5"
Action information (4-1): Execute patch program x 4
Action information (4-2): Restart (restart necessity level = 1)

  In step A 007, the version upgrade processing unit 106 determines whether the version of the target device (the version extracted from the repair database 108) matches the latest version. If the version of the target device matches the latest version (YES in step A 007), the version upgrade processing unit 106 transmits to the worker terminal 300 that the action for version upgrade is not necessary. (Step A008). Then, the worker terminal 300 receives and outputs that the action for version upgrade is unnecessary (step A009).

  On the other hand, if the version of the target device does not match the latest version (NO in step A007), the process moves to step A021 shown in FIG.

  FIG. 9 is a flowchart showing an example of processing for generating cumulative version upgrade information.

  In step A021, the version upgrade processing unit 106 generates a version upgrade information sequence based on the version upgrade information.

For example, it is assumed that the version upgrade processing unit 106 extracts the above version upgrade information (1) to (4) from the device database 109. In that case, the version upgrade processing unit 106 generates, as a version upgrade information sequence, a permutation arranged in the order of the version upgrade information (1) to (4). As a result, the generated version upgrade information sequence includes a sequence of action information arranged in the following order.
Action information (1-1): Execute patch program x1 Action information (1-2): Restart (restart necessity level = 2)
Action information (2-1): execute patch program x 2 action information (2-2): restart (restart necessity level = 2)
Action information (3-1): Execute patch program x3 Action information (3-2): Restart (restart necessity level = 3)
Action information (4-1): Execute patch program x4 Action information (4-2): Restart (restart necessity level = 1)

  In step A 022, the version upgrade processing unit 106 determines whether the device name of the target device is registered in the redundant action database 110. If the device name of the target device is registered in the redundant action database 110 (YES branch at step A 022), redundant action information associated with the device name is extracted (step A 023). Then, the process transitions to step A024. On the other hand, if the device name of the target device is not registered in the redundant action database 110 (NO branch at step A022), the process moves to step A024.

  In step A024, the version upgrade processing unit 106 determines whether the version upgrade information string includes redundant action information. When redundant action information associated with the device name is extracted (step A 023), the version upgrade processing unit 106 determines whether the version upgrade information string includes the extracted redundant action information. Will judge.

  Further, the redundant action database 110 may store a combination of redundant action information and a condition of redundant action information without being associated with a device name. In that case, the version upgrade processing unit 106 may refer to the redundant action database 110 to determine whether the version upgrade information string includes redundant action information.

  If the version upgrade information string includes redundant action information (YES branch at step A024), the process proceeds to step A025. If the version upgrade information string does not include redundant action information (NO branch at step A024), the process proceeds to step A026.

  In step A025, the version upgrade processing unit 106 deletes the action information corresponding to the redundant action information from the version upgrade information sequence. Then, the process transitions to step A026.

  In step A026, the version upgrade processing unit 106 generates accumulated version upgrade information based on the version upgrade information sequence. Then, the process transitions to step A041 shown in FIG.

  For example, it is assumed that the version upgrade processing unit 106 generates, as a version upgrade information sequence, a permutation arranged in the order of the above-described version upgrade information (1) to (4). In that case, from the version upgrade information string, the version upgrade processing unit 106 performs restart requirement level permutation, restart requirement level = 2, restart requirement level = 2, restart requirement level = 3, and so on. Extract the activation necessity level = 1.

  Then, the version upgrade processing unit 106 determines whether or not the version upgrade information string includes redundant action information with reference to the redundant action database 110 shown in FIG. 7. That is, the version upgrade processing unit 106 determines whether or not the permutation of the restart necessity level satisfies the condition numbers 0001 to 0003 shown in FIG. 7.

  Then, the version upgrade processing unit 106 determines that the action information (1-2) and the action information (2-2) are redundant action information based on the condition of the condition number 0001 shown in FIG. Further, based on the condition of the condition number 0003 shown in FIG. 7, the version upgrade processing unit 106 determines that the action information (4-2) is redundant action information. Therefore, the version upgrade processing unit 106 generates action information (1-2), action information (2-2), and action information (4−) from the version upgrade information sequence including version upgrade information (1) to (4). 2) Delete.

As a result, in the case of upgrading from version = 1 to version = 5 for the target device of the device name “A”, the version upgrade information string includes a row of action information arranged in the following order.
Action information (1-1): execute patch program x1 action information (2-1): execute patch program x2 action information (3-1): execute patch program x3 action information (3-2): restart action Information (4-1): Execute patch program x4

  Then, the version upgrade processing unit 106 sequentially performs the action information (1-1), the action information (2-1), the action information (3-1), the action information (3-2), and the action information (4-1). Generate cumulative version upgrade information, including a row of ordered action information.

  Further, for example, it is assumed that the version of the target device of the device name “A” is upgraded from version = 1 to version = 3. In that case, the version upgrade processing unit 106 generates, as a version upgrade information sequence, a permutation arranged in the order of the above version upgrade information (1) to (2). Then, the version upgrade processing unit 106 determines whether or not the permutation of the restart necessity level extracted from the version upgrade information (1) to (2) satisfies the condition numbers 0001 to 0003 shown in FIG. 7. .

  Then, based on the condition of the condition number 0002 shown in FIG. 7, the version upgrade processing unit 106 determines that the above action information (1-2) is redundant action information. On the other hand, the version upgrade processing unit 106 determines that the restart processing of the action information (2-2) is executed based on the condition of the condition number 0002 shown in FIG.

As a result, in the case of upgrading from version = 1 to version = 3 for the target device of the device name “A”, the version upgrade information string includes a row of action information arranged in the following order.
Action information (1-1): execute patch program x1 action information (2-1): execute patch program x2 action information (2-2): restart

  Then, the version upgrade processing unit 106 generates cumulative version upgrade information including a row of action information arranged in the order of the action information (1-1), the action information (2-1), and the action information (2-2). Do.

  Further, for example, it is assumed that the version of the target device of the device name “B” is upgraded from version = 1 to version = 4. In that case, the action information of “execute patch program y1”, “execute patch program y3”, and “execute patch program y4” is action information for upgrading from version = 1 to version = 4.

On the other hand, referring to FIG. 6, the patch program y2 is a program for upgrading from version = 1 to version = 3. Therefore, the version upgrade processing unit 106 can generate a version upgrade information string so as to reduce the number of times of execution of the patch program by selecting the version upgrade information including the action information “execute patch program y2”.

  FIG. 10 is a flow chart showing an example of processing for outputting the contents of the action for version upgrade.

  In step A041, the control unit 102 extracts action information for version upgrade from the version upgrade information sequence. In step A042, the control unit 102 transmits the content of the action for version upgrade to the worker terminal 300 via the communication unit 101. In step A043, the worker terminal 300 receives the content of the action for version upgrade from the management device 100 and outputs it.

For example, in the case of upgrading the version from version = 1 to version = 5 for the target device of the device name “A”, the management device 100 causes the worker terminal 300 to
Action information (1-1): execute patch program x1 action information (2-1): execute patch program x2 action information (3-1): execute patch program x3 action information (3-2): restart action Information (4-1): Notify that the patch program x4 needs to be processed in the order of execution.

[Modification 1]
As a modification 1 of the management system 10 according to the present embodiment, the management apparatus 100 may control the target device so as to execute the process specified by the action information included in the cumulative version upgrade information. That is, based on the accumulated version upgrade information, the management apparatus 100 uses the software installed in the target device from the currently installed version (first version) to the second version (for example, the latest version). You may upgrade to

[Modification 2]
As a modification 2 of the management system 10 according to the present embodiment, the management apparatus 100 transmits the content of the action for version upgrade to the worker terminal 300, and a patch program corresponding to the generated cumulative version upgrade information. , May be sent to the target device. Alternatively, the management device 100 may write the patch program corresponding to the generated cumulative version upgrade information to a portable storage medium. Here, the portable storage medium may be a DVD (Digital Versatile Disk), a USB (Universal Serial Bus), or the like, and the details thereof are not limited as long as the target device can be read.

  As described above, the management apparatus 100 according to the present embodiment deletes the action information indicating redundant restart processing from the action information for upgrading the version of the software. Then, the management device 100 according to the present embodiment outputs action information from which redundant restart processing has been deleted. Therefore, a worker who upgrades the maintenance target device 200 can avoid restarting the maintenance target device 200 more than necessary by using the management device 100 according to the present embodiment. Furthermore, by avoiding the maintenance target device 200 from restarting more than necessary, it is possible to reduce the time required to upgrade the maintenance target device 200. Therefore, the management system 10 according to the present embodiment contributes to efficiently upgrading the device.

  Furthermore, the management apparatus 100 according to the present embodiment may cause the corresponding maintenance target device 200 to execute the process for version upgrade based on the action information from which the redundant restart process has been deleted. As a result, the management system 10 according to the present embodiment contributes to efficiently upgrading the version of the device and contributes to reducing artificial work.

  Furthermore, the management apparatus 100 according to the present embodiment may generate a version upgrade information sequence so as to reduce the number of executions of the patch program. In that case, the management apparatus 100 according to the present embodiment deletes redundant restart processing and outputs action information in which the number of times of execution of the patch program is reduced. Therefore, the management system 10 according to the present embodiment contributes to more efficient version upgrading of the device by avoiding redundant restart processing and reducing the number of times of execution of the patch program.

Second Embodiment
Next, a second embodiment will be described in detail using the drawings.

  The present embodiment is an aspect of managing version upgrades of software and / or hardware of the maintenance target device. That is, in the present embodiment, maintenance includes upgrading of software and / or hardware installed in the maintenance target device. In the description of the present embodiment, the description of the parts overlapping with the above embodiment will be omitted. Furthermore, in the description of the present embodiment, the same components as those of the above-described embodiment are denoted by the same reference numerals, and the description thereof will be omitted. Further, in the description of the present embodiment, the description of the same effects as those of the above-described embodiment will be omitted. Hereinafter, the same applies to the other embodiments.

  The overall configuration of the management system 10 according to the present embodiment is as shown in FIG. FIG. 11 is a block diagram showing an example of the internal configuration of the management apparatus 100 and the worker terminal 300 according to the present embodiment. The difference between the management apparatus 100 shown in FIG. 11 and the management apparatus 100 shown in FIG. 3 is that the management apparatus 100 shown in FIG. 11 includes a design information database 111. In the following description, differences from the first embodiment will be described in detail with respect to each module shown in FIG. Specifically, hardware upgrade is described in detail in the following description. In the management system 10 according to the present embodiment, the software version upgrade is the same as in the first embodiment, and thus the description thereof is omitted.

  The design information database 111 stores information in which the part name of the maintenance target device 200 is associated with the information for identifying the position of each part. In the following description, information for identifying the position of a component is referred to as position information. Specifically, the hardware position information is information for identifying the position at which the hardware is attached (connected) in the maintenance target device 200. For example, it is assumed that the maintenance target device 200 is a substrate (electronic circuit substrate). In that case, the position information may be coordinate values representing the position at which the component is connected on the substrate.

  FIG. 12 shows an example of the design information database 111. As shown in FIG. Specifically, FIG. 12 associates and stores the device name, the component name, and the position information of each component. For example, FIG. 12 shows that the component with the component name “a” mounted on the device with the device name “A” is mounted at the position “1-1” in the device.

  The version upgrade processing unit 106 according to the present embodiment includes two or more versions corresponding to the version upgrade from the first version to the second version regarding software and / or hardware installed in the maintenance target device 200. Identify up information. Each version upgrade information includes action information for version upgrade regarding software installed in the maintenance target device 200 and / or hardware. The first version according to the present embodiment corresponds to a version before version upgrade with regard to software and / or hardware to be upgraded. Further, the second version according to the present embodiment corresponds to a version after version upgrade with regard to software and / or hardware to be upgraded.

  Here, the version upgrade information according to the present embodiment includes information identifying hardware, information identifying a position of a part included in hardware, action information corresponding to hardware, and information regarding connection of hardware And information associated with each other. In the following description, information on connection of hardware is referred to as connection information.

  Specifically, the action information on hardware may include information on attachment / detachment of the hardware. For example, action information for hardware may be replacing a part with another part, removing a part, attaching a new part, or the like.

  The hardware connection information includes information specifying the connection method of the hardware and / or information specifying the connection medium. For example, the hardware connection method may be a mechanical connection method, an electrical connection method, or the like. For example, the method of mechanically connecting may be fitting two or more parts and connecting the two or more parts. Alternatively, the method of mechanically connecting may be connecting two or more parts using soldering, screw fastening, or the like.

  The information specifying the connection medium of the hardware may be information specifying the type, form, material, etc. of the cable connecting two or more parts. Here, the form of the cable may be information such as the length and thickness of the cable.

  The version upgrade processing unit 106 according to the present embodiment determines whether the identified version upgrade information includes redundant action information or redundant connection information. Specifically, the version upgrade processing unit 106 according to the present embodiment performs redundant hardware based on the identity of the location information of the hardware, the identity of the action information, and the permutation of the information identifying the hardware. It is determined whether it is action information for the wear.

  Then, if the identified version upgrade information includes redundant action information or redundant connection information, the version upgrade processing unit 106 determines that the identified version upgrade information includes redundant action information.

  The device database 109 according to the present embodiment stores version upgrade information of software and / or hardware installed in the maintenance target device 200.

  FIG. 13 is a diagram showing an example of the device database 109 according to the present embodiment regarding hardware version upgrade. Specifically, the version upgrade information shown in FIG. 13 associates the version before update, the version after update, and the corresponding action information for upgrading the hardware from the version before update to the version after update. It is information.

For example, in the maintenance target device 200 of the device name “A”, it is assumed that the version is upgraded from version = 1 to version = 4. Then, the version upgrade processing unit 106 refers to the device database 109 shown in FIG. In that case, the version upgrade processing unit 106 extracts the following version upgrade information (11) to (13) from the device database 109.
Version upgrade information (11): version before update = 1, version after update = 2
Action information (11-1): Add part a Version up information (12): Before update version = 2, After update version = 3
Action information (12-1): Add part b Upgrade information (13): Before update version = 3, After update version = 4
Action information (13-1): Delete part a

  The redundant action database 110 according to the present embodiment stores at least one of redundant action information, a combination of redundant action information, and redundant action information conditions in association with information for identifying hardware. Specifically, in the present embodiment, the redundant action database 110 determines whether or not the hardware connection is redundant action information based on the identity of the action information and the permutation of the connection information. It may be configured including the conditions of

  FIG. 14 is a view showing another example of the redundant action database 110 according to the present embodiment. Specifically, FIG. 14 shows an example of the redundant action database 110 in the case of associating the combination of redundant action information with the information identifying hardware. More specifically, FIG. 14 shows information in which the device name, the latest version, and redundant action information are associated with each other. And FIG. 14 shows the information which matched the version before update, and action information as redundant action information.

  For example, it is assumed that the hardware version is upgraded from version = 1 to version = 4 in the maintenance target device 200 of the device name “A”. Then, the version upgrade processing unit 106 refers to the device database 109 shown in FIG. 13 and the redundant action database 110 shown in FIG. In that case, the version upgrade processing unit 106 determines that the above action information (11-1) and action information (13-1) are redundant action information based on the redundant action database 110 shown in FIG. Therefore, the version upgrade processing unit 106 deletes the action information (11-1) and the action information (13-1) from the version upgrade information sequence configured from the above version upgrade information (11) to (13).

  As a result, when upgrading the hardware version from version = 1 to version = 4 for the target device of the device name “A”, the version upgrade information sequence includes action information (11-1) and action information (13-1). ) But not the action information (12-1).

Then, when upgrading the hardware version from version = 1 to version = 4 for the target device of the device name “A”, the management device 100 causes the worker terminal 300 to
Action information (12-1): Notify that the part b needs to be added.

  FIG. 15 is a diagram showing another example of the redundant action database 110 according to the present embodiment. Specifically, FIG. 15 shows an example of the redundant action database 110 in the case of associating redundant action information conditions with information identifying hardware. The condition shown in FIG. 15 is an example, and the determination condition of redundant action information according to the present embodiment is not limited to the condition shown in FIG.

  The condition number 1001 shown in FIG. 15 is a condition corresponding to the device having the device name “A” or “B”. The condition number 1001 indicates that the condition of the condition number 1001 is satisfied in the case of “adding and deleting the same component at the same position”. Then, FIG. 15 shows that the version upgrade processing unit 106 states that “action information for adding the part and action information for deleting the part are redundant action information” when the condition of the condition number 1001 is satisfied. Indicates that it makes a decision.

  A condition number 1002 shown in FIG. 15 is a condition corresponding to the device having the device name “A” or “B”. The condition number 1002 indicates that “when the device, position and parts are the same, the connection method when the version is V1 is M1 and the connection method when the version is V2 smaller than V1 is other than M1”. Indicates that the condition of the condition number 1002 is satisfied. FIG. 15 shows that the version upgrade processing unit 106 determines that “the connection method when the version is V2 is redundant action information” when the condition of the condition number 1002 is satisfied.

  The condition number 1003 shown in FIG. 15 is a condition corresponding to the device having the device name “A” or “B”. Condition No. 1003 indicates “When the device, position and parts are the same, the connection medium when the version is V1 is M2 and the connection medium when the version is V2 smaller than V1 is other than M2” Indicates that the condition of the condition number 1003 is satisfied. When the condition shown in FIG. 15 satisfies the condition number 1003, the version upgrade processing unit 106 determines that “connection using a connection medium whose version corresponds to V2 is redundant action information”. Indicates

  For example, the above-described action information (11-1) and action information (13-1) are action information for "adding and deleting the same part". Then, referring to FIG. 12, the positional information of the part with the part name "a" mounted on the device with the equipment name "A" is single positional information (ie, "1-1"). Accordingly, the action information (11-1) and the action information (13-1) described above satisfy the condition of the condition number 1001 shown in FIG. Therefore, when the version upgrade processing unit 106 refers to the redundant action database 110 shown in FIG. 15, the action information (11-1) and the action information (13-1) are redundant based on the condition number 1001. It is determined that the action information is correct. As a result, the version upgrade processing unit 106 deletes the action information (11-1) and the action information (13-1) from the version upgrade information sequence, and generates cumulative action information. Then, the management device 100 notifies the worker terminal 300 that it is necessary to execute “add component b” (action information (12-1)).

  Also, for example, in the case of upgrading the version of the device from 1 to 2 with respect to the part of the part name “a” mounted on the device of the device name “A”, the part is , To connect with other parts. Then, in the case of upgrading the version of the device from 2 to 3 in the same device, part, and position, it is assumed that the part is fitted to and connected to another component. In that case, the connection method is changed in the same device, part, and position. Therefore, when referring to the redundant action database 110 shown in FIG. 15, the version upgrade processing unit 106 determines that the connection method using soldering is redundant action information based on the condition number 1002. As a result, the version upgrade processing unit 106 deletes, from the version upgrade information sequence, action information indicating a connection method using soldering, and generates accumulated action information. Then, the management device 100 notifies the worker terminal 300 that it is necessary to fit and connect the part with the part name “a” to another part.

  Also, for example, when upgrading the version of the device from 1 to 2 with respect to the component with the component name “a” mounted on the device with the device name “A”, the thickness is 5 mm (Millimeter; mm) To connect other parts with the cable. Then, in the case of upgrading the version of the device from 2 to 3 in the same device, part, and position, it is assumed that the connection is changed to a cable of 4 mm in thickness. In that case, the connection medium is changed in the same device, part, and position. Therefore, when referring to the redundant action database 110 shown in FIG. 15, the version upgrade processing unit 106 determines that the connection using the cable of 5 mm in thickness is redundant action information based on the condition number 1003. . The version upgrade processing unit 106 deletes, from the version upgrade information sequence, action information indicating connection with a 5 mm-thick cable, and generates cumulative action information. Then, the management device 100 notifies the worker terminal 300 that it is necessary to connect the component with the component name “a” with a 4 mm thick cable.

  Next, the operation of the management apparatus 100 according to the present embodiment will be described in detail. In the management system 10 according to the present embodiment, the processes of steps A001 to A009 shown in FIG. 8 and the processes of steps A021 to A026 shown in FIG. 9 are the same as in the first embodiment. Description is omitted.

  FIG. 16 is a flowchart showing an example of processing for outputting the contents of the action for version upgrade in the management system 10 according to the present embodiment.

  Here, the version upgrade processing unit 106 generates accumulated version upgrade information based on the version upgrade information sequence (step A026 shown in FIG. 9). Alternatively, the device name of the target device is not registered in the redundant action database 110 (NO branch of step A 022 shown in FIG. 9). In that case, the version upgrade processing unit 106 extracts action information for version upgrade from the cumulative version upgrade information (step A081 shown in FIG. 16).

  In step A082, the version upgrade processing unit 106 acquires component position information from the design information database 111. In step A 083, the version upgrade processing unit 106 associates the acquired position information with the extracted action information for version upgrade. In step A084, the control unit 102 transmits the content of the action for version upgrade and the corresponding position information to the worker terminal 300 via the communication unit 101. In step A085, the worker terminal 300 receives the content of the action for version upgrade and the corresponding position information from the management device 100 and outputs it.

  As described above, when upgrading software and / or hardware, the management apparatus 100 according to the present embodiment deletes action information indicating redundant work from the action information for version upgrade. Then, the management apparatus 100 according to the present embodiment outputs the action information from which the redundant work has been deleted. Therefore, a worker who upgrades the maintenance target device 200 can avoid performing unnecessary work by using the management apparatus 100 according to the present embodiment. As a result, the worker who upgrades the maintenance target device 200 can reduce the working time and improve the working efficiency. Therefore, the management system 10 according to the present embodiment contributes to the version upgrade of the device more efficiently.

Third Embodiment
Next, a third embodiment will be described in detail using the drawings.

  In this embodiment, in the hardware version upgrade, parts are replaced based on the life of the parts.

  The overall configuration of the information processing system 10 according to the present embodiment is as shown in FIG. FIG. 17 is a block diagram showing an example of the internal configuration of the management apparatus 100 and the worker terminal 300 according to the present embodiment. The difference between the management apparatus 100 shown in FIG. 17 and the management apparatus 100 shown in FIG. 11 is that the management apparatus 100 shown in FIG. 17 includes a life parts determination unit 112 and a life parts determination program 113. In the following description, differences from the above embodiment will be described in detail with respect to each module shown in FIG.

  The design information database 111 according to the present embodiment stores information in which the part name of the maintenance target device 200, the position information of each part, and the information related to the life are associated. In the following description, a period or a usable amount which can be guaranteed to operate properly after the start of use of the part is called a guaranteed life.

  FIG. 18 is a diagram showing an example of the design information database 111 according to the present embodiment. Specifically, the design information database 111 shown in FIG. 18 associates and stores the device name, the component name, the position information of each component, and the guaranteed life of each component. For example, FIG. 18 shows that the service life guaranteed to operate properly for the part with the part name “a” mounted on the apparatus with the apparatus name “A” is five years. Also, for example, FIG. 18 shows that the part having the part name “b” mounted on the apparatus having the apparatus name “A” has no life set. In FIG. 18, the guaranteed lifetime is represented by years, but this is not intended to limit the guaranteed lifetime to a period.

  The life part determining unit 112 calculates the remaining life of the part with respect to the part mounted on the maintenance target device 200, and generates action information for replacing the part based on the calculated remaining life. Here, the remaining life means the remaining period during which the part can be used normally or the remaining usable amount.

  Specifically, the lifetime component determination unit 112 extracts one or more component names corresponding to the device name and the guaranteed lifetime from the design information database 111 based on the device name. In the following description, the component corresponding to the component name extracted by the lifespan determining unit 112 is referred to as a determination target component.

  Then, the control unit 102 requests, via the communication unit 101, information on the usage record of the determination target component to the maintenance target device 200 on which the determination target component is mounted. The maintenance target device 200 transmits information on the usage record of the determination target component to the management device 100 in response to the request.

  For example, it is assumed that the component to be determined is a battery (for example, a lithium (Li) battery). In that case, the maintenance target device 200 mounting the battery may notify (send) the management device 100 of the capacity of the battery, the average power consumption of the maintenance target device 200, the total usage time of the determination target component, and the like. good.

  Further, for example, it is assumed that the component to be determined is a capacitor. In that case, the maintenance target device 200 mounting the capacitor may notify (send) the total usage time of the maintenance target device 200 mounting the capacitor, and the like to the management apparatus 100. The information on the usage record of the judgment target part may be different according to the type of the judgment target part, and the details are not important as long as it is information necessary to calculate the remaining life of the judgment target part. . Note that the total usage time is the total usage time or elapsed time starting from the point of replacement of the judgment target component.

  Then, the lifetime component determination unit 112 calculates the remaining lifetime of the determination target component based on the information on the usage record of the determination target component. Then, the life part determination unit 112 determines whether to replace the part based on the remaining life of the part and the guaranteed life.

  Specifically, with respect to a part whose usable amount is limited, the life part determining unit 112 may determine whether to replace the part based on the used amount and the usable amount. For example, it is assumed that the part to be judged is a battery. In that case, the lifetime component determination unit 112 determines the remaining lifetime of the battery based on the capacity of the battery, the average power usage of the maintenance target device 200 on which the battery is mounted, and the total usage time of the maintenance target device 200. It may be calculated. Then, when the difference between the calculated remaining life of the battery and the usable amount (guaranteed life) of the battery is lower than a predetermined threshold, the lifespan determining unit 112 may determine to replace the battery.

  Alternatively, with respect to a part whose usable time is limited, the life part determining unit 112 may determine whether to replace the part based on the total usage time and the usable time. For example, it is assumed that the judgment target component is a capacitor. In that case, if the difference between the total usage time of the capacitor and the usable time (guaranteed lifetime) of the capacitor is lower than a predetermined threshold, the lifespan determining unit 112 may determine to replace the capacitor.

  The storage unit 105 according to the present embodiment stores a life part determination program 113. The life part determination program 113 is a program that causes the control unit 102 to execute the processing of the life part determination unit 112.

  Next, the operation of the management system 10 according to the present embodiment will be described in detail.

  FIG. 19 is a flowchart showing an example of processing to determine whether or not replacement of parts is necessary based on the life of the parts.

  First, the control unit 102 transmits the contents of the action for version upgrade and the corresponding position information to the worker terminal 300 (step A 084 shown in FIG. 16). In that case, the lifetime component determination unit 112 extracts the serial number, the year of manufacture, and the device name from the repair database 108 based on the repair slip number (step A101 shown in FIG. 19).

  In step A102, the lifetime component determination unit 112 extracts location information of components and a guaranteed lifetime from the design information database 111 based on the extracted device name.

  In step A103, the life part determination unit 112 calculates the remaining life of the part. In step A104, the lifespan part determination unit 112 determines whether there is a part whose difference between the guaranteed life and the remaining life is lower than a predetermined threshold value. If there is a part whose difference between the guaranteed life and the remaining life is lower than a predetermined threshold (YES branch at step A104), the process goes to step A105. On the other hand, when there is no part whose difference between the guaranteed life and the remaining life is lower than the predetermined threshold (NO branch of step A104), the process of determining whether to replace the part is ended.

  In step A105, the life part determination unit 112 determines a part whose difference between the guaranteed life and the remaining life is lower than a predetermined threshold as a part to be replaced.

  In step A106, the life part determination unit 112 extracts a part replacement history from the repair database 108 based on the repair slip number. In step A107, the lifetime component determination unit 112 determines whether a component having a remaining lifetime equal to or less than a predetermined time is included in the component replacement history. If a part having a remaining life equal to or less than the predetermined time is included in the part replacement history (YES branch of step A107), the process proceeds to step A108. On the other hand, when a part having a remaining life equal to or less than the predetermined time is not included in the part replacement history (NO branch of step A107), the process transitions to step A109.

  In step A108, among the parts having a remaining life equal to or less than a predetermined time, parts included in the part replacement history are excluded from parts to be replaced.

  In step A109, the lifetime component determination unit 112 generates, as component replacement information, information in which the component to be replaced and the position information of the component are associated with each other.

  In step A110, the control unit 102 transmits component replacement information to the worker terminal 300 via the communication unit 101. In step A111, the worker terminal 300 receives and outputs component replacement information from the management device 100.

[Modification 1]
As a modification 1 of the management system 10 according to the present embodiment, the design information database 111 may further store a part replacement method, a part replacement procedure, matters to be noted by the operator at part replacement, and the like. Then, the life part determination unit 112 uses, as part replacement information, information in which the part to be replaced, the position information of the part, the replacement method of the part, the replacement procedure, the matter to be noted by the operator, etc. It may be generated.

  As described above, the management apparatus 100 according to the present embodiment deletes information indicating redundant processing and work from the action information for version upgrade, and determines whether to replace the part based on the life of the part. To judge. Therefore, when using the management system 10 according to the present embodiment, the worker efficiently upgrades the version of the maintenance target device 200 when performing an operation to solve a failure that has occurred in the maintenance target device 200, Parts can be replaced. Therefore, the management system 10 according to the present embodiment contributes to efficiently upgrading the device and contributes to efficiently maintaining the device.

Fourth Embodiment
Next, a fourth embodiment will be described in detail with reference to the drawings.

  In the present embodiment, when a failure occurs in the maintenance target device, the worker terminal 300 is notified of the content of the failure and the response method.

  The overall configuration of the management system 10 according to the present embodiment is as shown in FIG. FIG. 20 is a diagram showing an example of the internal configuration of the management apparatus 100 and the worker terminal 300 according to the present embodiment. The difference between the management apparatus 100 shown in FIG. 20 and the management apparatus 100 shown in FIG. 17 is that the management apparatus 100 shown in FIG. 20 includes the failure database 114, the failure handling processor 115, and the failure handling processing program 116. It is a point comprised including.

  The failure database 114 stores information in which the device name, the failure content, the component having the possibility of the failure cause (hereinafter referred to as a suspected component), and the failure handling method are associated.

  For example, a worker or the like who has performed a failure recovery operation of the maintenance target device 200 uses the worker terminal 300 etc. for the device name, the content of the failure, the component that is the cause of the failure, and the failure response method. ,input. Then, when the device name, the content of the failure, the component that is the cause of the failure, and the failure handling method are input, the management system 10 may register in the failure database 114.

  FIG. 21 shows an example of the failure database 114. As shown in FIG. For example, in the fault database 114 shown in FIG. 21, the fault contents corresponding to the device having the device name “A” are “power on”, “error display”, and “not recognized”.

  In the failure database 114 shown in FIG. 21, the component of the component name “d” is associated with the component “during power on” corresponding to the device having the device name “A” as a suspected component. Then, the failure response method of “replace the part d with the part i” is associated with the failure content of “do not turn on the power” corresponding to the device of the device name “A”.

  Further, in the failure database 114 shown in FIG. 21, the component of the component name “g” is associated with the failure content of “error display” corresponding to the device of the device name “A” as a suspected component. Then, the failure response method of “replace the part g with the part e” is associated with the failure content of “error display” corresponding to the device of the device name “A”.

  Further, in the failure database 114 shown in FIG. 21, the component with the component name “f” is associated with the failure content “not recognized” corresponding to the device with the device name “A” as a suspected component. Then, the failure response method “replace part f with part j” is associated with the failure content “do not recognize” corresponding to the device having the device name “A”.

  The failure handling processing unit 115 extracts a suspected part of the failure and a failure handling method from the failure database 114 based on the content of the failure. That is, the failure handling processing unit 115 refers to the history of failure occurrence registered in advance, and acquires the suspected component and the failure handling method corresponding to the content of the failure to be inquired.

  The storage unit 105 stores a failure handling processing program 116. The failure target processing program 116 is a program that causes the control unit 102 to execute the processing of the failure handling processing unit 115.

  Next, the operation of the management system 10 according to the present embodiment will be described in detail.

  FIG. 22 is a flowchart illustrating an example of processing for identifying a suspected component in accordance with the content of the failure.

  First, it is assumed that a failure has occurred in the maintenance target device 200. It is assumed that a person in charge of maintenance of the maintenance target device 200 upgrades the version of the software and / or hardware installed in the maintenance target device 200 as a failure recovery operation. Then, after completion of the failure recovery work, it is input to the worker terminal 300 whether or not the failure has been resolved. Then, the worker terminal 300 determines whether or not the information indicating that the fault has not been eliminated is input (step A201). If the information indicating that the failure has been eliminated is input (NO in step A201), the worker terminal 300 ends the version upgrade of the software and / or hardware of the maintenance target device 200 or the part replacement. It is determined that the process ends. On the other hand, when the information indicating that the fault is not eliminated is input (YES branch of step A201), the process proceeds to step A202.

  In step A 202, the control unit 302 transmits, via the communication unit 301, information that the failure has not been eliminated to the management apparatus 100. Then, the management apparatus 100 receives, from the worker terminal 300, information that the fault has not been eliminated (step A203).

  In step A 204, the failure handling unit 115 acquires the device name of the maintenance target device 200 from the repair database 108 based on the repair slip number. In step A205, the failure handling processor 115 determines whether the device name of the maintenance target device 200 is registered in the failure database 114 (step A205). If the device name of the maintenance target device 200 is registered in the failure database 114 (YES branch at step A205), the process proceeds to step A206. On the other hand, when the device name of the maintenance target device 200 is not registered in the failure database 114 (NO in step A205), the management device 100 ends the process.

  In step A206, the failure response processing unit 115 extracts failure content from the repair database 108 based on the repair slip number. In step A207, the failure handling processor 115 determines whether the extracted failure content is registered in the failure database 114 or not. If the extracted fault content is registered in the fault database 114 (YES branch at step A207), the process proceeds to step A208. On the other hand, when the extracted failure content is not registered in the failure database 114 (NO in step A207), the management apparatus 100 ends the process.

  In step A208, the failure handling processing unit 115 extracts from the failure database 114 the suspected component associated with the failure content and the failure handling method. That is, the failure handling processing unit 115 acquires the suspected component and the failure handling method corresponding to the failure contents based on the past failure contents registered in advance.

  Furthermore, in step A 209, the failure handling processing unit 115 extracts the position information of the suspected component from the design information database 111.

  In step A 210, the control unit 102 transmits the suspect component, the position information of the suspect component, and the failure handling method to the worker terminal 300 via the communication unit 101. In step A211, the worker terminal 300 receives the suspect part, the location information of the suspect part, and the failure handling method from the management device 100, and outputs it.

  As described above, the management apparatus 100 according to the present embodiment outputs a fault suspected component and a fault handling method based on the past fault history. Therefore, when a failure occurs in the maintenance target device 200, the worker who performs the failure recovery work efficiently refers to the suspected component output by the management apparatus 100 according to the present embodiment and the failure handling method. Can do recovery work. Therefore, the management system 10 according to the present embodiment contributes to efficiently upgrading the version of the device, and also contributes to supporting performing the fault recovery work efficiently.

Fifth Embodiment
Next, a fifth embodiment will be described in detail with reference to the drawings.

  In the present embodiment, processing is distributed to virtual machines.

  The overall configuration of the management system 10 according to the present embodiment is as shown in FIG. FIG. 23 is a block diagram showing an example of the internal configuration of the management apparatus 100 and the worker terminal 300 according to the present embodiment. The difference between the management apparatus 100 shown in FIG. 23 and the management apparatus 100 shown in FIG. 20 is that the management apparatus 100 shown in FIG. 23 includes a version upgrade processing virtual machine 400, a life part determination virtual machine 500, and failure handling processing. And the virtual machine 600.

  The version upgrade processing virtual machine 400 executes the processing described in the first embodiment and the second embodiment. The version upgrade processing virtual machine 400 includes a control unit 401 and a storage unit 402. The storage unit 402 stores a version upgrade processing program 403, a repair database 404, a design information database 405, a device database 406, and a redundant action database 407.

  The version upgrade processing program 403 corresponds to the version upgrade processing program 107 described in the first embodiment and / or the second embodiment. The control unit 401 calls the version upgrade processing program 403 and executes the processing described as processing executed by the version upgrade processing unit 106. Further, each database stored in the storage unit 402 corresponds to each database described in the first embodiment and / or the second embodiment.

  The lifetime component determination virtual machine 500 executes the processing described in the third embodiment. The life part determination virtual machine 500 includes a control unit 501 and a storage unit 502. The storage unit 502 stores a life part determination program 503, a repair database 504, and a design information database 505.

  The life part determination program 503 corresponds to the life part determination program 113 described in the third embodiment. The control unit 501 calls the life part determination program 503, and executes the processing described as the life part determination unit 112. Also, each database stored in the storage unit 502 corresponds to each database described in the third embodiment.

  Failure Handling Processing The virtual machine 600 implements the processing described in the fourth embodiment. The failure response processing virtual machine 600 includes a control unit 601 and a storage unit 602. The storage unit 602 stores a failure handling processing program 603, a repair database 604, a failure database 605, and a design information database 606.

  The failure handling processing program 603 corresponds to the failure handling processing program 116 described in the fourth embodiment. The control unit 601 calls the failure handling processing program 603, and executes the processing described as the failure handling processing unit 115. Also, each database stored in the storage unit 602 corresponds to each database described in the fourth embodiment.

[Modification 1]
As a first modification of the management apparatus 100 according to the present embodiment, the management apparatus 100 includes at least one virtual machine of the upgrade virtual machine 400, the life part determination virtual machine 500, and the failure handling process virtual machine 600. Of course, it may be configured to include. That is, the management apparatus 100 according to the present embodiment is configured to execute the processing described in at least one of the processing described in the first to fourth embodiments. Also good.

  As described above, the management apparatus 100 according to the present embodiment distributes processing to virtual machines. Therefore, the management apparatus 100 according to the present embodiment can further utilitarily execute the process of deleting redundant action information, the process of estimating the life of a part, the process of acquiring a suspected part and a failure solution method, and the like. . Therefore, the management system 10 according to the present embodiment exerts the same effects as those of the above-described embodiment, and contributes to performing processing more efficiently.

  In the above description, an example in which the management apparatus 100 acquires the repair slip number from the worker terminal 300 has been described. However, the management apparatus 100 may acquire the repair slip number based on the input operation to the input unit 104 of the management apparatus 100. That is, the management apparatus 100 may implement the above-described processing without the intervention of the worker terminal 300.

  Further, in the above description, for convenience of explanation, the database for upgrading the software and the database for upgrading the hardware have been described using different figures. However, this does not mean that the management apparatus 100 intends to include different databases depending on whether the object of version upgrade is software or hardware. Of course, one database may be configured to include information on software and hardware version upgrades.

  Some or all of the above-described embodiments may be described as in the following appendices, but are not limited thereto.

  (Supplementary Note 1) The management device according to the first aspect is as described above.

  (Supplementary Note 2) The system further comprises a redundant action database storing at least one of redundant action information, a combination of redundant action information, and redundant conditions of the action information, the version upgrade processing unit including: A management apparatus that determines whether the identified version upgrade information includes redundant action information based on a redundant action database.

  (Supplementary Note 3) The version upgrade processing unit identifies two or more pieces of the version upgrade information, and each of the identified version upgrade information corresponds to the version upgrade of at least one version, and the corresponding versions are in ascending or descending order. The specified version upgrade information is rearranged so that the rearranged version upgrade information is generated as a version upgrade information string, and based on the redundant action database, the version upgrade information string is redundantly generated. A management apparatus that deletes the action information and generates the cumulative version upgrade information based on the version upgrade information sequence from which the redundant action information is deleted.

  (Supplementary Note 4) The version upgrade information includes information for identifying a patch program and a restart necessity level of the device from the application of the patch program to the device to the application of another patch program. The redundant action database stores the condition for determining whether or not the restart process after applying the patch program is a redundant action based on the permutation of the restart necessity level, including the associated information. , Management device.

  (Supplementary Note 5) The version upgrade information relates to connection of the hardware, information identifying the hardware, information identifying a position of a component included in the hardware, action information corresponding to the hardware, and Connection information, and the redundant action database further includes at least one of a combination of redundant connection information and redundant connection information conditions; A management apparatus that determines that the identified version upgrade information includes redundant action information when the identified version upgrade information includes redundant action information or redundant connection information.

  (Supplementary Note 6) Information for identifying a device, a third version that matches the second version, or is newer than the second version, and the version upgrade information for upgrading to the third version The apparatus further includes a device database, which is stored in association with the device database, and the version upgrade processing unit acquires, from the device database, the version upgrade information corresponding to the version upgrade from the first version to the second version. Management device.

  (Supplementary Note 7) The management apparatus, wherein the version upgrade processing unit causes the maintenance target device to execute a process for version upgrade based on the generated cumulative version upgrade information.

  (Supplementary Note 8) A lifetime component that calculates the remaining life of the component with respect to the component mounted on the maintenance target device, and generates the action information indicating replacing the component based on the calculated remaining lifetime. A management apparatus further comprising a determination unit.

  (Supplementary Note 9) The device database stores one or more of the patch programs corresponding to the software, and the version upgrade processing unit upgrades the version from the first version to the second version. A management apparatus for acquiring the corresponding patch program from the device database.

  (Supplementary Note 10) The management apparatus, wherein the redundant action database stores at least one of a combination of redundant pieces of action information and a condition of redundant pieces of action information in association with information identifying the hardware.

  (Supplementary Note 11) The information processing method according to the second aspect is as described above.

  (Supplementary Note 12) The management device includes a redundant action database storing at least one of redundant action information, a combination of redundant action information, and redundant conditions of the action information, and the management device An information processing method including the step of determining whether the identified version upgrade information includes redundant action information based on the redundant action database.

  (Supplementary Note 13) The version upgrade specified so that the management apparatus specifies two or more pieces of the version upgrade information corresponding to the version upgrade of at least one version, and the corresponding versions are in ascending or descending order Rearranging information and generating the rearranged version upgrade information as a version upgrade information sequence; and deleting redundant action information from the version upgrade information sequence based on the redundant action database. And generating the cumulative version upgrade information based on the version upgrade information sequence from which the redundant action information is deleted.

  (Supplementary Note 14) The version upgrade information relates to the connection of the hardware, the information identifying the hardware, the information identifying the position of the part included in the hardware, the action information corresponding to the hardware, and Connection information, and the redundant action database includes at least one of a combination of redundant connection information and a condition of redundant connection information, and the management apparatus specifies An information processing method comprising the step of determining whether version upgrade information includes redundant action information or redundant connection information.

  (Supplementary Note 15) The management apparatus may upgrade the information to identify the device, a third version that matches the second version, or is newer than the second version, and the third version. A device database is provided, which stores the device version database in association with version upgrade information, and the management apparatus acquires, from the device database, the version upgrade information corresponding to the version upgrade from the first version to the second version. An information processing method, comprising the steps of:

  (Supplementary note 16) The action indicating that the managing apparatus calculates the remaining life of the part and the replacement of the part based on the calculated remaining life with respect to the part mounted on the maintenance target device An information processing method including the steps of generating information.

  (Supplementary note 17) An information processing method including the step of causing the maintenance target device to execute a process for version upgrade based on the generated accumulated version upgrade information.

  (Supplementary Note 18) This is a program according to the third aspect.

  The form shown in the above-mentioned appendix 18 can be expanded to the form shown in appendixes 12 to 17 similarly to the form shown in appendix 11.

  The disclosure of the above-mentioned patent documents is incorporated herein by reference. Within the scope of the entire disclosure of the present invention (including the scope of the claims), modifications and adjustments of the embodiment are possible based on the fundamental technical concept of the invention. In addition, various combinations or selections of various disclosed elements (including each element of each claim, each element of each embodiment, each element of each drawing, etc.) are possible within the scope of the entire disclosure of the present invention. is there. That is, the present invention of course includes the entire disclosure including the scope of the claims, and various modifications and alterations that can be made by those skilled in the art according to the technical concept. In particular, with regard to the numerical ranges described herein, it should be understood that any numerical value or small range falling within the relevant range is specifically described even if it is not otherwise described.

1, 100 management apparatus 2, 106 version upgrade processing unit 3, 3a to 3d version upgrade information 4, 4a to 4d action information 5 cumulative version upgrade information 10 management system 20 network 101, 301 communication unit 102, 302, 401, 501, 601 control unit 103, 303 output unit 104, 304 input unit 105, 402, 502, 602 storage unit 107, 403 version upgrade processing program 108, 404, 504, 604 repair database 109, 406 device database 110, 407 redundant action database 111 405, 505, 606 Design information database 112 Life parts judgment unit 113, 503 Life parts judgment program 114, 605 Failure database 115 Failure handling processing unit 116, 603 Failure handling processing Program 200 Maintenance target device 300 Worker terminal 400 Upgrade process virtual machine 500 Lifetime part judgment virtual machine 600 Failure handling process Virtual machine

Claims (9)

A version upgrade processing unit that identifies two or more pieces of upgrade information corresponding to the upgrade from the first version to the second version with respect to software and / or hardware installed in the maintenance target device;
The version upgrade information includes action information for version upgrade,
A redundant action database storing at least one of redundant action information, a combination of redundant action information, and redundant conditions of the action information;
The version upgrade processing unit
It is determined based on the redundant action database whether or not the identified version upgrade information includes redundant action information.
A management apparatus that outputs accumulated version upgrade information in which redundant action information is deleted from the identified version upgrade information when the redundant action information is included. The version upgrade processing unit
Identify two or more of the version upgrade information,
Each of the identified version upgrade information corresponds to at least one version upgrade,
The specified version upgrade information is rearranged so that the corresponding versions are in ascending or descending order, and the rearranged version upgrade information is generated as a version upgrade information sequence.
The redundant version action information is deleted from the version upgrade information string based on the redundant action database, and the cumulative version upgrade information is generated based on the version upgrade information string from which the redundant action information is deleted. The management device according to claim 1 . The version upgrade information is information in which information identifying a patch program is associated with a restart necessity level of the device during application of the patch program to the device and before application of another patch program. Including
Said redundant action database, on the basis of the restart requirement level permutation, restarting processing after the patch program applies, stores conditions for determining whether a redundant action to claim 1 or 2 Management device described. The version upgrade information includes information for identifying the hardware, information for identifying a position of a component included in the hardware, the action information corresponding to the hardware, and connection information on connection of the hardware. , Contains information associated with,
The redundant action database further includes at least one of a combination of redundant connection information and a condition of redundant connection information;
If the identified version upgrade information includes redundant action information or redundant connection information, the version upgrade processing unit determines that the identified version upgrade information includes redundant action information. The management apparatus according to any one of claims 1 to 3 . Information for identifying a device, a third version that matches the second version or is newer than the second version, and the version upgrade information for upgrading to the third version are stored in association with each other Further comprises an equipment database,
The version upgrade processing unit according to any one of claims 1 to 4 , wherein the version upgrade information corresponding to the version upgrade from the first version to the second version is acquired from the device database. Management device. The management apparatus according to any one of claims 1 to 5 , wherein the version upgrade processing unit causes the maintenance target device to execute a process for version upgrade based on the generated cumulative version upgrade information. With regard to a component mounted on the maintenance target device , calculating the remaining life of the component based on the information on the usage record from the maintenance target device , and replacing the part based on the calculated remaining life. The management apparatus according to any one of claims 1 to 6 , further comprising a lifespan part determination unit that generates the action information to be shown. Regarding software and / or hardware , at least any of the conditions of version upgrade information including redundant version of the action information including redundant version of the action information including redundant version of the action information including version upgrade action information Management device including a storage unit for storing a redundant action database, the storage unit corresponding to the version upgrade from the first version to the second version with respect to the software and / or the hardware, 2 Identifying the above version upgrade information,
The management apparatus determines, based on the redundant action database, whether the identified version upgrade information includes redundant action information;
Outputting accumulated version upgrade information in which the redundant action information is deleted from the identified version upgrade information when the management apparatus includes redundant the action information;
Information processing method including: Regarding software and / or hardware , at least any of the conditions of version upgrade information including redundant version of the action information including redundant version of the action information including redundant version of the action information including version upgrade action information A program for causing a computer that controls a management apparatus to execute, the program comprising: a storage unit that stores a redundant action database that stores
A process of identifying two or more pieces of upgrade information corresponding to the upgrade from the first version to the second version with respect to the software and / or the hardware;
A process of determining whether the identified version upgrade information includes redundant action information based on the redundant action database;
A process of outputting accumulated version upgrade information in which redundant action information is deleted from the identified version upgrade information when it includes redundant action information;
A program that causes the computer to execute.

Images