CN117916186B - 维护管理系统 - Google Patents

Abstract

维护管理系统具有根据监视数据对电梯进行监视的监视装置、以及经由网络与监视装置连接的管理服务器。当在监视数据中包含电梯的故障前兆的情况下，监视装置将触发通报发送到管理服务器。管理服务器的处理器在从监视装置接收到触发通报的情况下执行以下处理：生成处理，使用触发通报和维护数据库，生成用于向电梯的乘员确认故障前兆因素的确认消息；发送处理，向乘员发送确认消息；接收处理，接收乘员对确认消息的应答消息；以及判定处理，根据应答消息判定是否需要维护员前往现场。

Description

维护管理系统

技术领域

本发明涉及维护管理系统，特别涉及针对电梯的故障前兆判断是否需要维护员前往的维护管理系统。

背景技术

在专利文献1中公开有与在乘客被困在轿厢内时救出乘客的方法有关的技术。在该技术中，在由于某些异常原因使电梯的轿厢紧急停止而使乘客被困在轿厢内时，根据来自与电梯进行通信的远程的监视中心的指令进行乘客的救出。

现有技术文献

专利文献

专利文献1：日本特开2006-44930号公报

发明内容

发明要解决的课题

电梯的监视装置始终监视电梯是否没有故障前兆。当在电梯发现了故障前兆的情况下，监视装置有时对远处的信息中心发送被称作触发通报的通报。接受触发通报的信息中心使维护员前往现场来应对故障。

但是，在触发通报中，有时包含乘员按压轿厢门等故障以外的因素。这种情况下，不能说使维护员前往现场必定是最好的判断。

本发明的目的在于，提供针对电梯的故障前兆能够抑制维护员的不必要前往的维护管理系统。

用于解决课题的手段

本发明被应用于维护管理系统，该维护管理系统具有根据电梯的监视数据对电梯进行监视的监视装置、以及经由网络与监视装置连接的管理服务器。监视装置构成为，当在监视数据中包含电梯的故障前兆的情况下，将与该故障前兆对应的通报即触发通报发送到管理服务器。管理服务器具有：服务器存储器，其存储有包含用于确定与触发通报对应的故障前兆因素的信息的维护数据库；以及处理器，其与服务器存储器结合。处理器构成为，在从监视装置接收到触发通报的情况下执行以下处理：生成处理，使用触发通报和维护数据库，生成用于向电梯的乘员确认故障前兆因素的确认消息；发送处理，向乘员发送确认消息；接收处理，接收乘员对确认消息的应答消息；以及判定处理，根据应答消息判定是否需要维护员前往现场。

此外，本发明被应用于维护管理系统，该维护管理系统具有根据电梯的监视数据对电梯进行监视的监视装置、以及经由网络与监视装置连接的管理服务器。管理服务器构成为，在从监视装置接收到与电梯的故障前兆对应的通报即触发通报的情况下，请求维护员前往现场。监视装置构成为执行以下处理：当在监视数据中包含故障前兆的情况下，生成用于向电梯的乘员确认故障前兆因素的确认消息；向电梯的乘员发送确认消息；接收乘员对确认消息的应答消息；根据应答消息判定是否需要维护员前往现场；以及在判定为需要维护员前往的情况下，将触发通报发送到管理服务器。

发明效果

根据本发明的维护管理系统，由电梯的乘员来进行故障前兆因素的确认。由此，针对电梯的故障前兆能够抑制维护员的不必要前往。

附图说明

图1是示出应用维护管理系统的电梯的例子的图。

图2是用于说明监视装置的结构的一例的框图。

图3是示出管理服务器的结构的一例的框图。

图4是示出管理服务器的处理器执行程序而实现的功能的功能框图。

图5是示出实施方式1的维护管理系统执行的监视处理的控制进程的流程图。

图6是示出实施方式1的维护管理系统执行的处理的控制进程的流程图。

图7是示出管理服务器的硬件资源的变形例的图。

图8是示出实施方式2的维护管理系统执行的处理的控制进程的流程图。

具体实施方式

下面，参照附图对本发明的实施方式进行说明。但是，在以下所示的实施方式中，在提及了各要素的个数、数量、量、范围等数量的情况下，除了特别明示的情况或在原理上明显确定为该数量的情况以外，本发明的思想不限定于该提及的数量。此外，除了特别明示的情况或明显在原理上确定为此的情况以外，以下所示的实施方式中说明的构造等在本发明的思想中不一定是必须的。

实施方式

1.实施方式的电梯的结构

图1是示出应用维护管理系统的电梯的例子的图。电梯具有轿厢1和对重2。轿厢1在井道3中上下移动。对重2在井道3中上下移动。井道3是形成于建筑物的上下延伸的空间。轿厢1和对重2被绳索4悬吊于井道3。在图1中，作为一例示出1：1绕绳方式的电梯装置。

绳索4卷绕于曳引机5。轿厢1由曳引机5驱动。控制盘6对曳引机5进行控制。即，轿厢1的移动由控制盘6控制。图1示出曳引机5和控制盘6设置于井道3的上方的机房7的例子。曳引机5和控制盘6也可以设置于井道3。曳引机5可以设置于井道3的顶部，也可以设置于井道3的底坑。

监视装置8与控制盘6连接。监视装置8经由网络9与外部设备进行通信。该外部设备包含管理服务器10。作为一例，管理服务器10设置于对该电梯进行管理的远程的信息中心。

本实施方式的维护管理系统100构成为包含监视装置8和管理服务器10。下面，还参照图1更加详细地说明构成维护管理系统100的监视装置8和管理服务器10的结构。

2.监视装置8的结构

图2是用于说明监视装置的结构的一例的框图。监视装置8具有控制装置20和轿厢内通话装置22。控制装置20具有处理器201和与处理器201结合的存储器202。在存储器202中存储有能够由处理器201执行的1个或多个程序203和与其相关联的各种数据204。处理器201执行程序203，由此实现处理器201的各种处理。程序203例如包含后述的电梯的监视程序。

监视装置8接收从控制盘6发送的监视数据。监视数据例如是电梯的控制对象设备的动作数据或呼梯数据。动作数据例如包含行驶状态、门的开闭状态、轿厢负荷或轿厢位置。呼梯数据例如包含电梯的呼梯登记、呼梯的分配或针对呼梯的响应的数据。所取得的监视数据被存储于存储器202。

此外，监视装置8根据监视数据对电梯的状态进行综合监视。典型地讲，监视装置8的处理器201通过执行程序203中包含的监视程序，始终监视电梯的动作是否包含故障前兆。下面，该处理被称作“监视处理”。在监视处理的结果为包含故障前兆的情况下，处理器201将与该故障前兆对应的通报作为触发通报存储于存储器202，并且发送到管理服务器10。

轿厢内通话装置22设置于轿厢1内的未图示的轿厢内操作盘。轿厢内通话装置22是具有麦克风和扬声器的语音通话装置。监视装置8的处理器201通过执行程序203中包含的通话程序，在轿厢内通话装置22与管理服务器10之间进行语音通话。下面，该处理被称作“通话处理”。典型地讲，在通话处理中，将从轿厢内通话装置22输入的语音信号经由网络9发送到管理服务器10，并且，从轿厢内通话装置22输出从管理服务器10经由网络9接收到的语音信号。

4.管理服务器10的结构

管理服务器10是用于根据从监视装置8发送的监视数据进行电梯的维护管理的装置。图3是示出管理服务器10的结构的一例的框图。

管理服务器10是1个计算机、或利用通信网络连接的多个计算机的集合体。管理服务器10具有1个或多个处理器30和与处理器30结合的1个或多个服务器存储器32。在服务器存储器32中存储有能够由处理器30执行的1个或多个程序321和与其相关联的各种数据322。数据322包含用于确定电梯的故障前兆因素的维护数据库323。换言之，维护数据库323是将电梯的故障前兆因素与触发通报对应起来的数据库。

处理器30执行程序321，由此实现处理器30的各种处理。图4是示出管理服务器10的处理器30执行程序而实现的功能的功能框图。如图4所示，处理器30具有生成处理部302、发送处理部304、接收处理部306和判定处理部308。

生成处理部302根据从监视装置8接收到的触发通报和后述的应答消息，生成用于向电梯的轿厢1内的乘员确认电梯中发生的故障前兆因素的确认消息。下面，该处理被称作“生成处理”。这里的故障前兆因素例如例示出电梯的门开闭不良、按钮不良、照明不良等。

门开闭不良是电梯的轿厢1的门未完全关闭或未完全打开的不良。除了设备的故障以外，门开闭不良还由于夹住异物、搬运货物的乘员按压门等而发生。按钮不良包含成为目的地楼层按钮等按钮被持续按压的状态或即使按压也没有反应的状态的不良。照明不良包含轿厢1内的照明的灯泡烧毁或闪烁等不良。

在维护数据库323中存储有与故障前兆因素对应的确认消息。在生成处理中，生成处理部302参照维护数据库323生成与故障前兆因素对应的确认消息。

发送处理部304向轿厢1内的乘员发送所生成的确认消息。下面，该处理被称作“发送处理”。在发送处理中，发送处理部304将确认消息发送到监视装置8。监视装置8通过通话处理从轿厢内通话装置22输出确认消息。

在听到确认消息的乘员使用轿厢内通话装置22讲出应答消息后，监视装置8经由网络9向管理服务器10发送应答消息。接收处理部306从监视装置8经由网络9接收应答消息。下面，该处理被称作“接收处理”。接收到的应答消息被用于生成处理和后述的判定处理。

判定处理部308根据应答消息判定是否需要维护员前往现场。下面，该处理被称作“判定处理”。在判定处理中，判定处理部308通过公知的语音识别功能来识别应答消息的内容。这里的语音识别功能的内容没有限定。判定处理部308根据识别出的应答消息的识别结果和触发通报的内容确定具体的故障前兆因素。然后，判定处理部308根据所确定的故障前兆因素判定是否需要维护员前往现场。

5.实施方式的维护管理系统中执行的具体的处理

使用图5和图6对由实施方式的维护管理系统100执行的处理的流程进行说明。

图5是示出实施方式1的维护管理系统执行的监视处理的控制进程的流程图。图5所示的进程是由监视装置8的处理器201反复执行的进程。

在图5所示的进程的步骤S100中，处理器201接收从控制盘6发送的监视数据。接收到的监视数据被存储于存储器202。在接下来的步骤S102中，处理器201执行程序203中包含的监视程序，由此监视电梯的动作是否包含故障前兆。在其结果是不包含故障前兆的情况下，本进程结束。另一方面，在电梯的动作包含故障前兆的情况下，处理进入步骤S104。在步骤S104中，处理器201生成触发通报，将其发送到管理服务器10。

图6是示出实施方式1的维护管理系统执行的处理的控制进程的流程图。该图所示的进程是由管理服务器10的处理器30反复执行的进程。

在步骤S112中，处理器30判定是否从监视装置8接收到触发通报。在其结果是未接收到触发通报的情况下，本进程结束。

另一方面，在步骤S112中接收到触发通报的情况下，处理进入步骤S114。在步骤S114中，处理器30对轿厢1内的乘员发送确认消息。这里，处理器30在生成处理部302中生成与触发通报对应的确认消息。例如，在触发通报包含门开闭不良的故障前兆的情况下，生成处理部302首先生成“这里是信息中心，请问轿厢内有人吗”等确认消息。处理器30在发送处理部304中经由网络9向监视装置8发送所生成的确认消息。在步骤S114的处理完成后，处理进入步骤S116。

监视装置8语音发送从轿厢内通话装置22接收到的确认消息。在听到确认消息的乘员使用轿厢内通话装置22讲出应答消息后，监视装置8经由网络9向监视装置8发送应答消息。

在步骤S116中，处理器30在接收处理部306中判定是否接收到来自乘员的应答消息。在其结果是未接收到应答消息的情况下，反复执行步骤S116的处理。另一方面，在接收到应答消息的情况下，处理进入步骤S118。

在步骤S118中，处理器30在判定处理部308中判定是否能够接受应答消息并确定故障前兆因素。这里，处理器30使用语音识别功能来识别接收到的应答消息的内容。然后，处理器30判定是否能够通过应答消息确定具体的故障前兆因素。在一例中，在应答消息为“当前，由于搬入货物而按压门使门未关闭。”的情况下，确定为故障前兆因素基于人工作业，进入步骤S120。

此外，在另一例中，在如应答消息为“电梯的门开闭的状态有些可疑。”那样仅通过应答消息的内容无法确定具体的故障前兆因素的情况下，进入步骤S122。在步骤S122中，处理器30在判定处理部308中判定确认消息是否重复了规定次数。这里的规定次数是为了确定故障前兆因素而发送的确认消息的上限次数。在步骤S122中判定为确认消息重复了规定次数的情况下，判断为无法确定故障前兆因素，进入步骤S124。另一方面，在确认消息未重复规定次数的情况下，判断为存在用于确定故障前兆因素的进一步的确认消息，再次进入步骤S114。然后，处理器30接受在步骤S116中接收到的应答消息，在生成处理部302中生成用于进一步筛选故障前兆因素的确认消息。在一例中，生成处理部302生成“有什么被门夹住吗”等确认消息。

在其结果是在步骤S116中接收到例如“好像夹住什么，已经恢复了。”这样的应答消息的情况下，处理进入步骤S118，确定为故障前兆因素是已经解决的物品的夹住。此外，在另一例中，在接收到“还有些可疑。”这样的应答消息的情况下，处理进入步骤S118，确定为故障前兆因素是设备的故障。在步骤S118中能够根据应答消息的内容确定故障前兆因素的情况下，处理进入步骤120，在依然无法确定故障前兆因素的情况下，处理再次进入步骤S122。这样，反复执行步骤S114～步骤S118和步骤122的处理，直到在步骤S118中确定故障前兆因素或在步骤S122中确认消息重复规定次数为止。

在步骤S120中，处理器30在判定处理部308中根据在步骤S118中确定的故障前兆因素判定是否需要维护员前往。例如，在步骤S118的处理中判断为故障前兆因素基于人工作业的情况下，判定处理部308判定为不需要维护员前往，进入步骤S126。或者，在步骤S118的处理中判断为故障前兆因素是已经解决的物品的夹住的情况下，判定处理部308判定为不需要维护员前往，进入步骤S126。或者，在步骤S118的处理中判断为故障前兆因素是设备的故障的情况下，判定为需要维护员前往，进入步骤S124。

在步骤S124中，处理器30请求维护员前往。此外，在步骤S124中，在生成处理部302中针对乘员生成已请求维护员前往的消息。

在步骤S126中，处理器30不请求维护员前往，在服务器存储器32中登记包含故障前兆因素的判定结果信息。该处理被称作“登记处理”。此外，在步骤S126中，在生成处理部302中针对乘员生成不请求维护员前往的消息。

根据这种维护管理系统100，得到以下这样的效果。

在生成触发通报的状况中，还包含大量由现场的电梯设备的处理不良引起的故障前兆。根据维护管理系统100，通过使位于轿厢1内的乘员确认具体的故障前兆因素，能够判断是否是需要维护员前往的状况。由此，能够减少维护员的不必要前往。

根据维护管理系统100，在未请求维护员前往的情况下，登记包含触发通报和故障前兆因素的判定结果信息。由此，以后能够参照发生了故障前兆时的详细状况，因此，在故障前兆因素的分析等中能够利用这些信息。

6.变形例

本发明的维护管理系统100能够采用如以下那样变形的方式。

有时轿厢1内的乘员希望与信息中心的操作员进行通话。因此，也可以在轿厢1内的轿厢内操作盘设置在与操作员直接通话时按下的对讲机按钮。这种情况下，在对讲机按钮的旁边粘贴记载为“按下对讲机按钮时，能够与操作员通话”的标签即可。

乘员的应答消息不限于基于语音的输入。即，应答消息也可以从设置于轿厢1内的触摸面板等显示装置输入，此外，还可以利用轿厢内操作盘的按钮类来输入。

在触发通报的故障前兆因素中，还存在轿厢1内的乘员很难通过目视等来确认的因素。因此，维护管理系统100也可以在管理服务器10接收到触发通报的情况下，判定是否应该向轿厢1内的乘员发送故障前兆因素的确认消息。该情况下，维护管理系统100例如将乘员能够确认的故障前兆因素的列表存储于维护数据库323，参照该列表来判定是否需要向乘员发送确认消息即可。

图7是示出管理服务器10的硬件资源的变形例的图。在图7所示的例子中，管理服务器10例如具有处理电路34，该处理电路34包含处理器30、服务器存储器32和专用硬件33。图7示出通过专用硬件33实现管理服务器10具有的功能的一部分的例子。也可以通过专用硬件33实现管理服务器10具有的功能的全部。作为专用硬件33，能够采用单一电路、复合电路、程序化的处理器、并行程序化的处理器、ASIC、FPGA或它们的组合。

实施方式2

2-1.电梯的维护管理系统的结构

实施方式2的维护管理系统具有与实施方式1的维护管理系统100相同的系统结构。实施方式2的电梯监视系统的系统结构参照实施方式1的说明，这里省略其说明。

2-2.实施方式2的维护管理系统的特征

在实施方式2的维护管理系统100中，在监视装置8判定为在监视数据中包含故障前兆的情况下，监视装置8使轿厢内的乘员确认故障前兆因素，判定是否需要发送触发通报。下面，沿着图8的流程图对由实施方式的维护管理系统100执行的处理的流程进行说明。

图8是示出实施方式2的维护管理系统执行的处理的控制进程的流程图。图8所示的进程是由监视装置8的处理器201反复执行的进程。在图8的步骤S202和S204中，处理器201执行与图5所示的进程的步骤S102和S104相同的处理。在步骤S204中判定为需要乘员确认故障前兆因素的情况下，处理进入步骤S206。

在步骤S206、S208、S210、212和S214中，处理器201执行与在图6所示的进程的步骤S114、S116、S118、S120和S122中由管理服务器10的处理器30执行的处理相同的处理。

在步骤S212的处理中判定为需要维护员前往的情况下，处理进入步骤S216，在判定为不需要维护员前往的情况下，本进程结束。在步骤S216中，处理器201向管理服务器10发送触发通报。接收到触发通报的管理服务器10请求维护员前往。

根据以上这种控制，在监视装置8中，能够使位于轿厢1内的乘员确认故障前兆因素。由此，能够在需要维护员前往的状况下发送触发通报，因此，能够减少维护员的不必要前往。

标号说明

3：井道；4：绳索；5：曳引机；6：控制盘；7：机房；8：监视装置；9：网络；10：管理服务器；20：控制装置；22：轿厢内通话装置；30：处理器；32：服务器存储器；100：维护管理系统；201：处理器；202：存储器；203：程序；204：数据；302：生成处理部；304：发送处理部；306：接收处理部；308：判定处理部；321：程序；322：数据；323：维护数据库。

Claims (5)

1.一种电梯的维护管理系统，该电梯的维护管理系统具有根据电梯的监视数据对所述电梯进行监视的监视装置、以及经由网络与所述监视装置连接的管理服务器，其中，

所述监视装置构成为，当在所述监视数据中包含所述电梯的故障前兆的情况下，将与该故障前兆对应的通报即触发通报发送到所述管理服务器，

所述管理服务器具有：

服务器存储器，其存储有包含用于确定与所述触发通报对应的故障前兆因素的信息的维护数据库；以及

处理器，其与所述服务器存储器结合，

所述处理器构成为，在从所述监视装置接收到所述触发通报的情况下执行以下处理：

生成处理，使用所述触发通报和所述维护数据库，生成用于向所述电梯的乘员确认所述故障前兆因素的确认消息；

发送处理，向乘员发送所述确认消息；

接收处理，接收乘员对所述确认消息的应答消息；以及

判定处理，根据所述应答消息判定是否需要维护员前往现场，

在所述判定处理中，所述处理器构成为，

识别所述应答消息，

根据所述应答消息的识别结果确定所述故障前兆因素，

根据所述故障前兆因素判定是否需要所述维护员前往。

2.根据权利要求1所述的电梯的维护管理系统，其中，

在所述发送处理中，所述处理器构成为，

向设置于所述电梯的轿厢内的语音通话装置发送基于语音的所述确认消息。

3.根据权利要求1或2所述的电梯的维护管理系统，其中，

所述处理器构成为，当在所述判定处理中判断为不需要所述维护员前往的情况下，执行登记所述触发通报和所述故障前兆因素的登记处理。

4.根据权利要求1或2所述的电梯的维护管理系统，其中，

所述触发通报包含所述电梯的门开闭不良的故障前兆。

5.一种电梯的维护管理系统，该电梯的维护管理系统具有根据电梯的监视数据对所述电梯进行监视的监视装置、以及经由网络与所述监视装置连接的管理服务器，其中，

所述管理服务器构成为，在从所述监视装置接收到与所述电梯的故障前兆对应的通报即触发通报的情况下，请求维护员前往现场，

所述监视装置构成为执行以下处理：

当在所述监视数据中包含所述故障前兆的情况下，生成用于向所述电梯的乘员确认故障前兆因素的确认消息；

向所述电梯的乘员发送所述确认消息；

接收乘员对所述确认消息的应答消息；

根据所述应答消息判定是否需要所述维护员前往现场；以及

在判定为需要所述维护员前往的情况下，将所述触发通报发送到所述管理服务器，

在所述判定是否需要前往的处理中，所述监视装置构成为，

识别所述应答消息，

根据所述应答消息的识别结果确定所述故障前兆因素，

根据所述故障前兆因素判定是否需要所述维护员前往。