Estimating device and estimating system

Abstract

An estimating device 1 includes: a failure history accumulating unit 16 for storing a first abnormality signal which is transmitted from on-site equipment and which is capable of identifying an abnormality type; an action result registering unit 15 which, if the first abnormality signal has been received as a result of the occurrence of an abnormality in the on-site equipment, causes the failure history accumulating unit 16 to store the received first abnormality signal, and if an action result relating to the first abnormality signal indicates the possibility of a software malfunction of software corresponding to the on-site equipment, causes a software malfunction flag to be attached to the first abnormality signal stored in the failure history accumulating unit 16; and a malfunction calculating unit 17 which, if a second abnormality signal is newly received as a result of the occurrence of a failure of the on-site equipment, and if the abnormality type of the second abnormality signal and the abnormality type of the first abnormality signal to which the software malfunction flag has been attached match one another, determines that there is possibility that a software malfunction may be the cause of the second abnormality signal.

Description

Estimation device and estimation system

[0001] The present disclosure relates to an estimation device and an estimation system that estimate whether or not there is a possibility of a software malfunction when an abnormal signal is generated in a field device.

[0002] BACKGROUND ART Conventionally, there is known a device that estimates the cause of a hardware failure based on the hardware specifications of an elevator system (see, for example, Patent Document 1).

[0003] Japanese Patent Application Laid-Open No. 2021-134027

[0004] However, while conventional techniques such as those disclosed in Patent Document 1 can estimate the cause of a hardware failure based on the hardware specifications of an elevator system, they cannot address those caused by software defects.

[0005] Therefore, it is not possible to identify software that may be faulty, which makes it time-consuming to restore the software, and the cost of the software restoration work is enormous.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide an estimation device and an estimation system that can shorten the software recovery time and reduce the work costs required for software recovery.

[0007] The estimation device according to the present disclosure includes a failure history storage unit that stores abnormality signals transmitted from local equipment and capable of identifying the type of abnormality; a treatment result registration unit that, when an abnormality signal issued due to an abnormality occurring in the local equipment is received, stores the received abnormality signal in the failure history storage unit and, if there is a possibility that a software malfunction of the software corresponding to the local equipment is the cause of the abnormal signal being issued, attaches a software malfunction flag to the abnormality signal stored in the failure history storage unit; and a malfunction calculation unit that, when a new abnormality signal issued due to a failure occurring in the local equipment is received, determines that there is a possibility that a software malfunction is the cause of the new abnormality signal being issued if the abnormality signals stored in the failure history storage unit match the new abnormality signal and the matching abnormality signal has been attached with the software malfunction flag.

[0008] The estimation system according to the present disclosure includes an estimation device according to the present disclosure, a field device, and a maintenance terminal that restores the software using a patch program that resolves the software defect.

[0009] According to the present disclosure, it is possible to shorten the time required to restore software and reduce the work costs required for restoring software.

[0010] FIG. 1 is a diagram showing an example of the configuration of an estimation system in embodiment 1. FIG. 1 is a diagram showing an example of the processing configuration of a malfunction calculation unit of FIG. 1. FIG. 2 is a diagram showing an example of the elapsed time from updating software related to the elevator and elevator-related equipment of FIG. 1 until an abnormality signal is issued. FIG. 3 is a diagram showing an example of the time series transition of the total number of abnormality signal issuances of FIG. 3. FIG. 4 is a diagram showing an example of an implementation cycle of diagnostic operation of the elevator of FIG. 1. FIG. 5 is a diagram showing an example of software types and software update items included in the operation log during diagnostic operation of FIG. 5. FIG. 6 is a flowchart explaining the processing of the estimation system of FIG. 1. FIG. 7 is a flowchart explaining the time comparison processing of FIG. 7. FIG. 7 is a flowchart explaining the time series transition comparison and determination processing of FIG. 7. FIG. 8 is a flowchart explaining the operation log determination processing of FIG. 7. FIG. 9 is a flowchart explaining processing different from FIG. 10 in the operation log determination processing of FIG. 7. FIG. 10 is a diagram showing an example of the configuration of an estimation system in embodiment 2.

[0011] Embodiment 1. Fig. 1 is a diagram showing an example of the configuration of an estimation system according to Embodiment 1. As shown in Fig. 1, the estimation system includes an estimation device 1, an elevator 3, elevator-related equipment 4, communication equipment 5, a maintenance terminal 6, a communication line 7, a communication line 8, and a maintenance terminal 9.

[0012] The elevator 3 is installed in a multi-story building or the like. The elevator-related equipment 4 is various types of equipment connected to the periphery of the elevator 3. In the following description, at least one of the elevator 3 and the elevator-related equipment 4 will be referred to as local equipment.

[0013] The communication device 5 is a device that communicates with the elevator 3 and elevator-related devices 4 and the estimation device 1 via a communication line 7 .

[0014] The elevator 3, elevator-related equipment 4, and communication equipment 5 are provided for each property. In Fig. 1, the elevator 3, elevator-related equipment 4, and communication equipment 5 are illustrated as an example of one property. In the example of Fig. 1, illustration of other properties is omitted.

[0015] The maintenance terminal 6 is carried by a maintenance person, can be connected to the elevator-related equipment 4, and is used for various recovery operations of the elevator 3 and the elevator-related equipment 4. The maintenance terminal 6 also has a function of communicating with the estimation device 1 via a communication line 7. The maintenance terminal 9 has the same function as the maintenance terminal 6, and is a device that communicates with the estimation device 1 via a communication line 8. For example, if there is a possibility that the software of the elevator 3 and the elevator-related equipment 4 has a software malfunction, the maintenance person can execute a program to resolve the software malfunction via the maintenance terminal 6 or the maintenance terminal 9, and recover the software.

[0016] The communication lines 7 and 8 are composed of communication media. The communication media constituting the communication lines 7 and 8 may be either wired or wireless. The communication lines 7 include dedicated line networks and public line networks. The communication lines 8 include communication line networks.

[0017] The estimation device 1 functions as a monitoring center that monitors the elevators 3 and elevator-related equipment 4. The estimation device 1 includes a failure signal acquisition unit 11, a data processing unit 12, a property information DB 13, an equipment information storage unit 14, a treatment result registration unit 15, a failure history storage unit 16, a defect calculation unit 17, a failure cause estimation unit 18, a failure cause display unit 19, and a configuration management DB 31. The estimation device 1 also includes a communication unit 21 and a communication unit 22. The estimation device 1 can use the communication units 21 and 22 to manage multiple remote properties in an integrated manner.

[0018] The communication unit 21 has a function of communicating with the communication device 5 and the maintenance terminal 6 via the communication line 7. The communication between the communication device 5 and the data processing unit 12 uses a dedicated line network included in the communication line 7. The communication between the maintenance terminal 6 and the device information storage unit 14 uses a general line network included in the communication line 7.

[0019] The failure signal acquisition unit 11 has a function of acquiring an abnormality signal from the communication unit 21. The abnormality signal is transmitted from the field device to the communication unit 21 via the communication line 7.

[0020] The abnormality signal includes information that can identify the type of abnormality. The information that can identify the type of abnormality includes information that classifies the location where the abnormality has occurred and information that identifies the content of the abnormality.

[0021] For example, if an abnormality occurs in an electromagnetic relay, an error code that identifies that an abnormality has been detected in the main circuit electromagnetic relay among the main circuit electromagnetic relay and the safety circuit relay can be used as information that can identify the type of abnormality.

[0022] Furthermore, for example, an error code that identifies that an abnormality has occurred in the brake and that an abnormal release of the hoist brake has been detected can also be used as information that can identify the type of abnormality.

[0023] The data processing unit 12 has a function of updating software corresponding to the on-site devices via the communication device 5. The data processing unit 12 has a function of acquiring an operation log of the software corresponding to the on-site devices via the communication device 5. The data processing unit 12 has a function of acquiring an update history of the software corresponding to the on-site devices via the communication device 5. The data processing unit 12 stores the operation log and update history of the software corresponding to the on-site devices in the configuration management DB 31 as device information.

[0024] The operation log includes information on the type of software and information on the software startup time specified by the type of software. The process of storing the operation log in the configuration management DB 31 is executed periodically.

[0025] The update history includes information about the version of the software corresponding to the local device, the update date and time of the software corresponding to the local device, and the update contents.

[0026] That is, the configuration management DB 31 is provided on the estimation device 1 side, which functions as a server for remotely maintaining on-site equipment, and manages the version of software corresponding to the on-site equipment and the update date and time of the software corresponding to the on-site equipment.

[0027] The property information DB 13 stores configuration information of the local devices and contract information of the local devices.

[0028] The device information storage unit 14 has a function of managing the operation log and update history of software corresponding to the local device.

[0029] The device information accumulation unit 14 acquires at least one of an operation log and an update history of software corresponding to the local device, and stores it as device information.

[0030] The device information accumulation unit 14 acquires configuration information and contract information of the local devices from the property information DB. The device information accumulation unit 14 acquires operation logs of software corresponding to the local devices from the data processing unit 12. The device information accumulation unit 14 acquires update times and update histories of the software corresponding to the local devices from the data processing unit 12.

[0031] In other words, the device information accumulation unit 14 has a function of acquiring device information from both the data processing unit 12 and the property information DB 13 .

[0032] The processing result registration unit 15 has a function of attaching a software malfunction flag to an abnormal signal when the cause of the abnormal signal is unknown. The processing result registration unit 15 also has a function of registering the processing results of the maintenance personnel.

[0033] The treatment result is transmitted from the maintenance terminal 9 to the communication unit 22 via the communication line 8. The treatment result registration unit 15 can acquire the treatment result from the communication unit 22. The treatment result is registered by the maintenance person via the maintenance terminal 9 after the maintenance person performs recovery work on the on-site device after the abnormal signal is issued. Note that after performing the recovery work, the maintenance person can also immediately use the maintenance terminal 6 to transmit the treatment result via the communication line 7 and have it registered in the treatment result registration unit 15.

[0034] If the cause of the abnormal signal is unknown, the maintenance person registers this fact in the treatment result registration unit 15 via the maintenance terminal 9. If it is registered via the maintenance terminal 9 that the cause of the abnormal signal is unknown, the treatment result registration unit 15 determines that the cause of the abnormal signal may have been a software malfunction, and attaches a software malfunction flag to the abnormal signal.

[0035] If the cause of the failure is unknown and the result of the treatment is normal, the treatment result registration unit 15 may attach a software malfunction flag to the abnormal signal.

[0036] An example of a case where the result of the treatment is normal is when the elevator 3 normally arrives at the designated floor after the treatment by the maintenance worker. Another example of a case where the result of the treatment is normal is when the control program for the elevator 3 normally operates according to the software design specifications after the control program for the elevator 3 is restarted.

[0037] In other words, when the cause of the failure is unknown and the result of the treatment is normal, the treatment result registration unit 15 attaches a software malfunction flag to the abnormal signal, thereby achieving the following effect: That is, the result of the treatment performed by the maintenance technician can be more accurately uploaded to the estimation device 1 on the server side, indicating that there is a possibility of a software malfunction.

[0038] The failure history accumulation unit 16 has a function of storing abnormality signals transmitted from the field devices. When the abnormality type of the abnormality signal acquired from the failure signal acquisition unit 11 matches the abnormality type of the abnormality signal acquired from the treatment result registration unit 15, the failure history accumulation unit 16 stores the abnormality signal corresponding to the matching abnormality type. When a software malfunction flag is attached to the abnormality signal acquired from the treatment result registration unit 15, the failure history accumulation unit 16 stores the software malfunction flag together with the abnormality signal.

[0039] Furthermore, if the fault history accumulation unit 16 can identify the type of software based on the information input by the maintenance personnel, the accompanying software defect flag can be an individual flag that enables the type of software to be identified.

[0040] In other words, when an abnormality signal issued due to an abnormality occurring in the on-site device is received, the processing result registration unit 15 associates the received abnormality signal with the processing result and stores the result in the failure history accumulation unit 16. In particular, when the cause of the issuance of the abnormality signal is possibly a software malfunction, the processing result registration unit 15 attaches a software malfunction flag to the abnormality signal stored in the failure history accumulation unit 16. Furthermore, when the type of software can be identified, the processing result registration unit 15 can use an individual software malfunction flag that can identify the type of software.

[0041] The fault calculation unit 17 has a function to perform the following process when a new abnormality signal is received due to a failure occurring in a field device: That is, when the abnormality type of the new abnormality signal matches the abnormality type of the abnormality signal to which the software fault flag is attached, the fault calculation unit 17 has a function to determine that the cause of the new abnormality signal may be a software fault.

[0042] In addition, the defect calculation unit 17 has the function of determining whether there is a possibility of a software defect based on an abnormal signal accompanied by a software defect flag and at least one of the operation log and update history of the software corresponding to the local device.

[0043] The failure calculation unit 17 acquires the abnormality signal with the software failure flag attached from the failure history accumulation unit 16 .

[0044] The defect calculation unit 17 acquires at least one of the operation log and update history of the software corresponding to the on-site device from the device information accumulation unit 14 .

[0045] The defect calculation unit 17 will be described in detail later with reference to FIGS.

[0046] The failure cause estimation unit 18 estimates the cause of the software failure for software determined by the failure calculation unit 17 to have a possible software failure. The software failure cause estimation may be performed using existing technology. For example, the software failure cause may be estimated by checking whether or not the functions assumed in the software design specifications are functioning normally.

[0047] The failure cause display unit 19 displays the failure cause estimated by the failure cause estimation unit 18, and allows the maintenance personnel to recognize the failure cause. In particular, if an abnormality signal corresponding to an abnormality signal issued from a field device has been stored as an abnormality signal accompanied by a software malfunction flag, the failure cause display unit 19 can display that there is a possibility of a software malfunction, and notify the maintenance personnel that there may be a problem with the software.

[0048] Furthermore, the failure cause display unit 19 can display the cause of the software malfunction estimated by the failure cause estimation unit 18. The maintenance personnel can check the cause of the software malfunction displayed by the failure cause display unit 19. The failure cause display unit 19 can also display the type of software that may have a software malfunction estimated by the failure cause estimation unit 18. The maintenance personnel can check the software that may have a software malfunction. Thus, the maintenance personnel can identify the software that needs to be restored.

[0049] Fig. 2 is a diagram showing an example of the processing configuration of the defect calculation unit 17 in Fig. 1. As shown in Fig. 2, the defect calculation unit 17 has functions to execute a time comparison process, a time series transition comparison and determination process, and an operation log determination process.

[0050] The time comparison process, the time series transition comparison and determination process, and the operation log determination process will be described in detail below with reference to FIGS.

[0051] 3 is a diagram showing an example of the elapsed time from updating software related to the elevator 3 and elevator-related equipment 4 in FIG. 1 until an abnormality signal is issued. Here, the elapsed time is the time from updating the software until the updated software is started for the first time until an abnormality signal is issued. If the elapsed time is shorter than a preset threshold elapsed time, the estimation device 1 determines that the abnormality signal may be due to a software malfunction.

[0052] FIG. 4 is a diagram showing an example of the time series transition of the total number of abnormal signal alerts in FIG. 3. In the example of FIG. 4, the total number of abnormal signal alerts relative to the number of installed units of software version E is compared between the previous month and the current month. That is, FIG. 4 shows the total number of abnormal signal alerts relative to the number of installed units of software version E. In the example of FIG. 4, the total number of abnormal signal alerts relative to the number of installed units of software version E changes in a manner that is approximately proportional to the previous month and the current month. That is, the total number of abnormal signal alerts increases in proportion to the number of installed units, and when such a transition is observed, the estimation device 1 determines that there is a possibility that the abnormal signals are due to a software malfunction in version E.

[0053] 4 illustrates an example in which the number of installed units this month has increased compared to the previous month, but this is not limiting. For example, even if the number of installed units has decreased, the estimation device 1 finds that the total number of abnormal signal alerts has decreased in proportion to the number of installed units. In this way, when the number of abnormal signal alerts related to the same version of software changes in proportion to the number of installed units of the same version of software, the estimation device 1 can determine that a malfunction in the same version of software is likely to be the cause of the abnormal signal alert.

[0054] Although the example in Figure 4 shows a comparison on a monthly basis, the comparison is not limited to a monthly basis as long as it is performed over a relatively long period, such as a weekly period. Also, the same property may contain multiple on-site devices, and multiple pieces of software may exist to control each on-site device.

[0055] Fig. 5 is a diagram showing an example of a period during which diagnostic operation is performed for the elevator 3 in Fig. 1. In the example of Fig. 5, diagnostic operation is performed after the software is updated to the latest version. Here, the diagnostic operation is an operation for diagnosing whether the elevator 3 and elevator-related equipment 4 are operating normally, and is usually performed at night.

[0056] In the example of Figure 5, the operation log of the local equipment using the latest version of software immediately before the issuance of an abnormal signal and the operation log of a previous version older than the latest version indicate that diagnostic operation, which has the same function, was performed, so the estimation device 1 determines that the cause of the issuance of an abnormal signal may be a malfunction of the software related to the latest version.

[0057] In addition, if the operation log of the local equipment immediately before the abnormal signal was issued and the operation log of another property indicate that software with the same function was being implemented, the estimation device 1 will determine that a software malfunction may have been the cause of the abnormal signal being issued.

[0058] Fig. 6 is a diagram showing an example of software types and software update items included in the operation log during the diagnostic operation of Fig. 5. The software update history includes information on the update date and time and information on the update contents for each version. The operation log table includes information on software update items.

[0059] The operation log table of version C is derived from the operation log table. The operation log table of version C contains information on software update items and information on whether the software update items have actually been updated. The operation log immediately before the issuance of the abnormal signal contains information on the software type and information on the software startup time specified by the software type.

[0060] If the update item in the operation log table matches the software type in the operation log of the on-site device immediately before the issuance of an abnormal signal, the estimation device 1 determines that a software malfunction is likely the cause of the issuance of an abnormal signal. In other words, based on the operation log and the software update history, the estimation device 1 can identify the type of software that did not generate an abnormal signal before the update but generated an abnormal signal after the update.

[0061] 6, the operation log table for version C shows that the software functions related to "brake" and "abnormal sound" have been updated, and the operation log of the on-site device immediately before the abnormal signal was issued shows that "abnormal sound diagnosis" was performed. Therefore, the estimation device 1 determines that the software malfunction related to "abnormal sound" is likely to be the cause of the abnormal signal being issued.

[0062] The information on the update date and time and the information on the update contents included in the software update history can be used as detailed software information. Information on software update items included in the operation log table for each version and information on whether the software update items have actually been updated can also be used as detailed software information. Information on software update items included in the operation log table can also be used as detailed software information.

[0063] In other words, from the above description, the estimation device 1 mainly transitions through the following three phases.

[0064] <First Phase> Advance Preparation If a software-related response was taken as a result of past actions taken in response to an abnormal signal, or if the cause of the abnormal signal was unknown, a "software malfunction flag" indicating the possibility of a software malfunction is attached to the abnormal signal and stored in a database. In other words, if there is a possibility of a software malfunction, the abnormal signal is stored in a database as an abnormal signal with a software malfunction flag attached.

[0065] <Phase 2> Judgment based on the presence or absence of a flag When a new abnormal signal is received, a database storing past treatment results is referenced, and if a "software malfunction flag" is attached to the abnormal signal corresponding to the newly received abnormal signal, the maintenance worker performing the work in response to the new abnormal signal is notified that there is a possibility of a software malfunction.

[0066] <Third Phase> Identifying software functions based on at least one of the operation log and update history. Furthermore, at least one of the operation log and update history is acquired from the on-site device. When a new abnormality signal is received, at least one of the operation log and update history is further referenced to identify the possibility of a software malfunction and to identify the specific software type, and present this information to the maintenance worker performing work in response to the new abnormality signal.

[0067] The above first, second and third phases make it possible to:

[0068] When the estimation device 1, which functions as a center, receives an abnormality signal and issues an instruction to dispatch maintenance personnel, it is possible to shorten the recovery time by presenting information about the malfunction of the software itself as one of the possible treatment options.

[0069] For failures where the cause is unknown as a result of treatment, providing detailed software information makes it possible to improve the accuracy of cause estimation technology.

[0070] For failures with unknown causes, information on the possibility of software defects can be fed back to the software administrator, making it possible to detect software defects early.

[0071] Furthermore, by providing feedback to the software development department and the software management department with various pieces of information from the first, second, and third phases, it is possible to detect software defects early and improve the quality of the software.

[0072] Next, a series of estimation processes executed by the estimation system having the configuration shown in Fig. 1 will be described below. Fig. 7 is a flowchart illustrating the processes of the estimation system of Fig. 1.

[0073] In step S201, if an abnormality signal is issued, the estimation device 1 proceeds to the process of step S202, and if an abnormality signal is not issued, the estimation device 1 repeats the process of step S201 until an abnormality signal is issued.

[0074] In step S202, if the same abnormal signal is present, the estimation device 1 proceeds to processing in step S203, and if the same abnormal signal is not present, the estimation device 1 proceeds to processing in step S205. Specifically, the estimation device 1 compares the previously received abnormal signal stored in the failure history accumulation unit 16 with the currently issued abnormal signal to determine whether the same abnormal signal as the currently issued abnormal signal is present among the previously received abnormal signals.

[0075] In step S203, the estimation device 1 acquires the software detail information from the configuration management DB 31. Specifically, the estimation device 1 acquires the update history before the abnormality signal was issued from the software update history included in the software detail information.

[0076] In step S171, the estimation device 1 executes a time comparison process. Details of the time comparison process will be described with reference to FIG.

[0077] In step S172, the estimation device 1 executes a time series transition comparison and determination process. Details of the time series transition comparison and determination process will be described with reference to FIG.

[0078] In step S173, the estimation device 1 executes an operation log determination process. Details of the operation log determination process will be described with reference to FIGS.

[0079] It is sufficient that at least one of the processes from step S171 to step S173 is executed.

[0080] In step S204, the estimation device 1 determines the investigation order. The investigation order may be determined, for example, by giving the highest priority to the software malfunction that is most likely to be a software malfunction.

[0081] In step S205, the estimation device 1 presents treatment candidates.

[0082] In step S206, the estimation device 1 instructs a maintenance worker to be dispatched.

[0083] In step S207, if the estimation device 1 has recovered from the failure, the process proceeds to step S207, and if the estimation device 1 has not recovered from the failure, the process repeats step S207.

[0084] In step S208, if the cause of the abnormal signal is unknown, the estimation device 1 proceeds to processing in step S209, and if the cause of the abnormal signal is not unknown, the estimation device 1 proceeds to processing in step S211.

[0085] In step S209, if the cause is unknown and the corrective action is normal, the estimation device 1 attaches a software malfunction flag to the abnormality signal. If the cause is unknown and the corrective action is not normal, the estimation device 1 suspends the recovery work and stops the operation of the elevator 3 until the corrective action is normal.

[0086] In step S210, the estimation device 1 stores the software at the time of issuance of the abnormal signal in the failure history accumulation unit 16. Here, the estimation device 1 does not actually store the software, but stores the type of software in the failure history accumulation unit 16 in a state where it can be referenced.

[0087] In step S211, the estimation device 1 registers the result of the treatment in the failure history accumulation unit 16, and ends the process.

[0088] FIG. 8 is a flowchart illustrating the time comparison process of FIG.

[0089] The time comparison process is a process in which, if an abnormality signal is issued before a threshold time has elapsed since a software update, it is assumed that the cause of the abnormality signal is a malfunction of the updated software.

[0090] If an abnormality signal is issued the first time the software is operated after being updated, it may be assumed that the cause of the abnormality signal is in the updated software.

[0091] In step S1721, the estimation device 1 obtains the most recent software update date and time from the software update history, thereby determining the start point for counting the elapsed time.

[0092] In step S1722, the estimation device 1 calculates the elapsed time from the most recent software update date and time to the time when the abnormality signal was issued.

[0093] In step S1723, if the elapsed time is shorter than the preset threshold elapsed time, the estimation device 1 proceeds to processing in step S1724, and if the elapsed time is equal to or greater than the preset threshold elapsed time, the estimation device 1 terminates the time comparison processing.

[0094] In step S1724, the estimation device 1 determines that the cause of the abnormal signal is likely to be a software malfunction, and terminates the time comparison process. As a result, if the abnormal signal is issued before the threshold time has elapsed since the most recent software update date and time, the estimation device 1 can estimate, as software detail information, that there is a possibility of a malfunction in the updated software.

[0095] FIG. 9 is a flowchart illustrating the time series transition comparison and determination process of FIG.

[0096] The time series transition comparison and determination process is a process for determining whether the total number of abnormal signal alerts is changing in a proportional relationship with the total number of installed software units.

[0097] In step S1731, the estimation device 1 extracts the total number of installed software units and the total number of abnormal signal alerts for the previous month.

[0098] In step S1732, the estimation device 1 extracts the total number of installed software units and the total number of abnormal signal alerts for the current month.

[0099] In step S1733, if the total number of abnormal signal alerts between the previous month and the current month has increased in proportion to the number of installed devices, the estimation device 1 proceeds to the processing of step S1734. On the other hand, if the total number of abnormal signal alerts between the previous month and the current month has not increased in proportion to the number of installed devices, the estimation device 1 ends the time series trend comparison and determination processing.

[0100] In step S1734, the estimation device 1 determines that a software malfunction is likely to be the cause of the abnormal signal being issued, and terminates the time series transition comparison and determination process. As a result, the estimation device 1 can estimate, as software detail information, software that may be malfunctioning, based on the comparison result of the time series transition between the total number of installed units and the total number of abnormal signal issuances.

[0101] FIG. 10 is a flowchart illustrating the operation log determination process of FIG.

[0102] The operation log determination process in Figure 10 operates the same before and after a software update, but if an abnormal signal is issued after a software update, a first process can be performed in which it is determined that a malfunction in the updated software may be the cause of the abnormal signal.In addition, the operation log determination process is a common operation log, and if an abnormal signal is not issued in other properties but an abnormal signal is issued in this property, a second process can be performed in which it is determined that the software running in this property may be the cause of the abnormal signal.

[0103] In step S1741, the estimation device 1 acquires the operation log of the on-site device immediately before the abnormal signal is issued.

[0104] In step S1742, the estimation device 1 acquires the operation log of the previous version.

[0105] In step S1743, if the operation log of the on-site device immediately before the abnormal signal was issued is the same as the operation log of the previous version, the estimation device 1 proceeds to processing of step S1744. On the other hand, if the operation log of the on-site device immediately before the abnormal signal was issued is not the same as the operation log of the previous version, the estimation device 1 proceeds to processing of step S1745.

[0106] In step S1744, the estimation device 1 determines that a software malfunction may be the cause of the abnormal signal being issued. In this manner, the estimation device 1 performs the first process by performing the processes in steps S1741 to S1744.

[0107] In step S1745, the estimation device 1 acquires the operation log of the other property.

[0108] In step S1746, if the operation log of the local device immediately before the abnormal signal was issued is the same as the operation log of the other property, the estimation device 1 proceeds to processing in step S1747. On the other hand, if the operation log of the local device immediately before the abnormal signal was issued is not the same as the operation log of the other property, the estimation device 1 ends the operation log determination process.

[0109] In step S1747, the estimation device 1 determines that a software malfunction may have been the cause of the abnormal signal, and ends the operation log determination process. In this way, the estimation device 1 performs the second process by performing the processes in step S1741 and steps S1745 to S1747. As a result, the estimation device 1 can estimate software that may be malfunctioning from the comparison results of the operation logs.

[0110] FIG. 11 is a flowchart illustrating a process that is different from that shown in FIG. 10 in the operation log determination process shown in FIG.

[0111] The operation log determination process in Fig. 11 is a process in which if the most recent operation log contains content corresponding to a software update item, it can be assumed that the abnormality signal was triggered by a software update, and therefore it is assumed that a software malfunction is the likely cause of the abnormality signal being triggered. In other words, the operation log determination process in Fig. 11 is not based on a comparison process of operation logs, but rather on software that may be malfunctioning based on the most recent operation log and the software update item.

[0112] In step S17401, the estimation device 1 acquires the operation log of the on-site device immediately before the abnormal signal is issued.

[0113] In step S17402, the estimation device 1 acquires an operation log table.

[0114] In step S17403, if the updated item in the operation log table matches the software type in the operation log of the on-site device immediately before the issuance of an abnormal signal, the estimation device 1 proceeds to processing in step S17404. On the other hand, if the updated item in the operation log table does not match the software type in the operation log of the on-site device immediately before the issuance of an abnormal signal, the estimation device 1 terminates the operation log determination process.

[0115] In step S17404, the estimation device 1 determines that a software malfunction is likely to be the cause of the abnormal signal, and terminates the operation log determination process. As a result, the estimation device 1 can estimate, as software detail information, software that may be malfunctioning, based on the immediately preceding operation log and the software update items.

[0116] As explained above, when a new abnormality signal is received due to a fault in a field device, if there is an abnormality signal stored in the fault history storage unit 16 that matches the new abnormality signal and the matching abnormality signal is flagged with a software malfunction, it is determined that the cause of the new abnormality signal may be a software malfunction. This narrows down the causes of the new abnormality signal to software-related factors. This shortens the software recovery time and reduces the labor costs required for software recovery.

[0117] Furthermore, when the fault calculation unit 17 receives a new abnormality signal and determines that a software fault is likely the cause of the new abnormality signal, it further identifies detailed software information that is believed to be the cause of the software fault based on the device information. This allows a maintenance technician who views the determination result to narrow down the content of the recovery work. This further shortens the software recovery time and reduces the work costs required for software recovery.

[0118] Furthermore, when the fault calculation unit 17 receives a new abnormality signal, if it determines that the cause of the new abnormality signal is likely to be a software fault, it will display this fact. This allows the maintenance personnel to narrow down the cause of the new abnormality signal to the possibility of a software fault, thereby narrowing down the steps required for recovery.

[0119] Furthermore, if the time elapsed from the first startup of the updated software until a new abnormality signal is issued is shorter than a preset threshold elapsed time based on the update history, the defect calculation unit 17 determines that a defect in the updated software is likely to be the cause of the new abnormality signal being issued. Therefore, by monitoring the elapsed time after the software update, it is possible to identify that the updated software is likely to be the cause of the abnormality signal.

[0120] Furthermore, if the number of abnormal signal reports related to the same version of software changes in proportion to the number of installed units of the same version of software, based on the device information acquired from multiple on-site devices, the defect calculation unit 17 determines that there is a possibility that a defect in the same version of software is the cause of a new abnormal signal report. Therefore, by monitoring the time series change in the number of abnormal signal reports related to the same version of software, it is possible to identify the software that is the cause of the abnormal signal.

[0121] Furthermore, if the latest operation log of the latest version that was active immediately before the abnormality signal was issued matches the operation log of the previous version that is older than the latest version, the malfunction calculation unit 17 determines that the cause of the new abnormality signal is likely to be a malfunction of software related to the latest version, thereby making it possible to more accurately identify the software that is causing the abnormality signal.

[0122] Furthermore, if the software update items match the software type, the defect calculation unit 17 determines that there is a possibility that a software defect corresponding to the update items is the cause of the new abnormal signal being issued. Therefore, it is possible to identify the software that is the cause of the abnormal signal more accurately than when comparing the latest version's immediately preceding operation log with the operation log of a previous version that is older than the latest version.

[0123] As described above, the estimation device 1 can communicate with the elevators 3 and the elevator-related equipment 4 via the communication line 7. The estimation device 1 can also communicate with the maintenance terminal 6 via the communication line 7, and the estimation device 1 can also communicate with the maintenance terminal 9 via the communication line 8. Thus, the estimation device 1 can remotely maintain the elevators 3 and the elevator-related equipment 4, and can also perform overall management including other on-site equipment installed in different locations.

[0124] In addition, the estimation device 1 can compare the abnormal signal sent from the elevator 3 and the elevator-related equipment 4 to the estimation device 1 with information in the configuration management DB 31, and thereby present the issuance of the abnormal signal to maintenance personnel as one of the possible software malfunctions.

[0125] In addition, by extracting common information and treatment results caused by software defects for software administrators, software defects can be detected early.

[0126] Second Embodiment The second embodiment differs from the first embodiment in that the estimation device 1 includes a database that also includes information about the revision contents of the software.

[0127] 12 is a diagram showing an example of the configuration of the estimation system according to the second embodiment. As shown in FIG. 12, the estimation device 1 further includes a software revision table DB 33. The software revision table DB 33 includes information about the contents of software updates and an operation log table. The information about the contents of software updates and the operation log table are stored in the device information storage unit 14.

[0128] Therefore, the estimation device 1 already has the update contents of the software update history and the operation log table. Therefore, the estimation device 1 can execute processing using the update contents of the software update history and the operation log table without externally requesting the update contents of the software update history and the operation log table. This reduces the amount of information acquired via the communication line 7, allowing the estimation device 1 to reduce the communication delay time that must be taken into consideration. Therefore, the processing time of the estimation device 1 can be further shortened.

[0129] 1 Estimation device, 3 Elevator, 4 Elevator-related equipment, 5 Communication equipment, 6, 9 Maintenance terminal, 7, 8 Communication line, 11 Fault signal acquisition unit, 12 Data processing unit, 13 Property information DB, 14 Equipment information storage unit, 15 Treatment result registration unit, 16 Fault history storage unit, 17 Defect calculation unit, 18 Fault cause estimation unit, 19 Fault cause display unit, 21, 22 Communication unit, 31 Configuration management DB, 33 Software revision table DB.

Claims

1. a fault history storage unit that stores an abnormality signal that is transmitted from the on-site device and that can identify the type of abnormality; a processing result registration unit which, when an abnormality signal generated due to an abnormality occurring in the on-site device is received, stores the received abnormality signal in the failure history storage unit, and, when there is a possibility that a software malfunction of software corresponding to the on-site device is the cause of the generation of the abnormality signal, affixes a software malfunction flag to the abnormality signal stored in the failure history storage unit; a failure calculation unit which, when receiving a new abnormality signal newly issued due to a failure occurring in the on-site device, determines that there is a possibility that a software failure is the cause of the issuance of the new abnormality signal if an abnormality signal matching the new abnormality signal is found among the abnormality signals stored in the failure history accumulation unit and if the software failure flag is attached to the matching abnormality signal; a device information storage unit that acquires at least one of an operation log and an update history of the software and stores the acquired log as device information; When the malfunction calculation unit receives the new abnormal signal and determines that the software malfunction is likely the cause of the new abnormal signal, the estimation device further identifies detailed software information that is considered to be the cause of the software malfunction based on the equipment information.

2. the device information storage unit acquires and stores the update history as the device information, The estimation device according to claim 1, wherein the defect calculation unit determines, based on the update history, that a defect in the updated software may be the cause of the new abnormal signal being issued if the elapsed time from when the updated software is first started to when the new abnormal signal is issued is shorter than a predetermined threshold elapsed time.

3. the device information storage unit acquires and stores the operation log and the update history as the device information relating to each of a plurality of on-site devices that have already been installed; The estimation device according to claim 1, wherein the defect calculation unit determines, based on the equipment information acquired from the plurality of on-site devices, that when the number of abnormal signal reports related to the same version of software changes in proportion to the number of units of the same version of software installed, there is a possibility that a defect in the same version of software is the cause of the new abnormal signal report.

4. the device information storage unit acquires and stores the operation log as the device information, The estimation device of claim 1, wherein the malfunction calculation unit determines, based on the operation log, that there is a possibility that a malfunction of software related to the latest version is the cause of the new abnormal signal being issued if the previous operation log of the latest version that was activated immediately before the abnormal signal was issued matches the operation log of a previous version that is older than the latest version.

5. the device information storage unit acquires and stores the operation log as the device information, the operation log includes information on the type of the software and information on a software start time specified by the type of the software; The estimation device according to claim 1 , wherein, when the software update items match the type of software, the defect calculation unit determines that there is a possibility that a defect in the software corresponding to the update item is the cause of the new abnormality signal.

6. The estimation device according to any one of claims 1 to 5, further comprising a failure cause display unit that displays, when the malfunction calculation unit receives the new abnormal signal, that it is determined that the software malfunction is possibly the cause of the new abnormal signal.

7. The estimation device according to any one of claims 1 to 5, The on-site device; a maintenance terminal for restoring the software by a program for eliminating the software defect; An estimation system comprising:

8. An estimation device according to claim 6, The on-site device; a maintenance terminal for restoring the software by a program for eliminating the software defect; An estimation system comprising: