升降机故障诊断系统的制作方法

本发明涉及升降机故障诊断系统，尤其适合应用于与发生了升降机故障时生成用于应对故障的故障原因查明恢复步骤有关的升降机故障诊断系统。

背景技术：

在正常的机械装置类的开发、生产中，虽然尽量避免由故障等问题导致的功能的降低或停止、或者谋求新技术的开发以及性能改善以便应对问题，但是很难避免由老化或干扰这样的突发原因所引起的问题。

为了应对这些状况，当前存在一种规则基础(rulebase)生成系统，其作为如下系统，即，将与机械装置类的机构部的问题发生事件有关的问题数据作为数据库，并且使用与设计数据一起积累在该数据库中的问题数据来对各种故障模式的影响(以下也称为“fmea”)进行解析的处理，将专家掌握的与故障原因查明恢复步骤有关的先进知识、技术等数字化，并且生成if～then～形式的规则基础的系统(参照专利文献1)。根据这样的规则基础生成系统，能够将规则基础的判断基准设为固定，并以长期形成均衡的规则的方式来实施维护。在像这样的现有的规则基础生成系统中，使用fmea处理来解析过去的故障履历，并生成故障状态-原因-调查-对策的故障搜索树。

专利文献

专利文献1：日本特开平6-95881

技术实现要素：

但是，电梯等升降机与一般的机械装置类不同，其具有即使在发生了故障的情况下，也会根据诸如轿厢内的荷重、轿厢的运转方向的轿厢的运行状态而使故障状态发生变化的复杂的故障模式，在上述现有的规则基础生成系统中，没有考虑这样的运行状态，无法应对像这样的复杂的故障模式。

本发明是考虑以上的问题而完成的，目的在于想要提供一种即使在根据轿厢的运行状态而使故障状态发生变化的情况下，也能够准确地查明故障的原因，缩短故障恢复时间的升降机故障诊断系统。

为了解决所涉及的问题，在本发明中，提供一种升降机故障诊断系统，其具备始终积累与装载在升降机的各轿厢中的负荷及轿厢的运转方向有关的非故障时及故障时的运行状态的运行信息管理部；以及积累关于发生在所述升降机中的故障而从外部输入的至少包含故障状态、原因、对策、管理编号以及故障发生日的故障日报的故障日报管理部，并且诊断所述升降机的故障，其特征在于，所述升降机故障诊断系统具备：故障状态管理部，其积累所述升降机中发生了故障时的所述升降机的故障状态；恢复步骤管理部，其管理用于从所述故障中恢复的故障原因查明恢复步骤；以及处理部，其生成为了从所述故障中恢复而使用的故障原因查明恢复步骤，所述处理部从所述故障日报管理部提取与在所述升降机中发生的故障相对应的包含所述故障状态、原因、对策、管理编号以及故障发生日的部分故障日报，并针对所述提取出的部分故障日报的内容，使用登记在所述故障状态管理部中的故障状态来进行筛选，由此进行分类，针对所述分类的结果，实施名称搜索，并将故障模式分配给汇总了多个所述故障信息的故障日志，当所述故障时的运行信息存在于所述运行信息管理部中时，从所述运行信息管理部中提取在各所述故障发生日观测到的数据即各所述故障时的运行信息，并在将各所述故障时的运行信息与所述各故障日志关联之后，进一步针对所述原因以及对策再次实施名称搜索，并对每一个所述故障时的运行信息生成对所述原因以及对策进行过整理的故障原因查明恢复步骤，并登记到所述恢复步骤管理部中。

根据本发明，即使在根据轿厢的运行状态而使故障状态发生变化时，也能够准确地查明故障的原因并缩短故障恢复时间。

附图说明

图1是表示本实施方式所涉及的升降机故障诊断系统的结构例的框图。

图2是表示本实施方式所涉及的升降机故障诊断系统的动作例的流程图。

图3是表示本实施方式所涉及的漏洞分类表格的一例的图。

图4是表示本实施方式所涉及的数据的一例的图。

图5是表示本实施方式所涉及的数据的一例的图。

图6是表示分配了本实施方式所涉及的故障时的运行信息的一例的图。

图7是表示实施本实施方式所涉及的名称搜索后的结果例的图。

图8是表示本实施方式所涉及的故障原因查明恢复处理的一例的流程图。

图9是表示客户侧的控制盘中的显示画面的一例的图。

附图标记说明

1……电梯1a……升降机控制部、2……远程监视装置、3……便携式终端、4……故障恢复支援系统、5……输入输出端口、6……故障日报数据库、7……故障状态数据库、8……机器管理数据库、9……维护员技能数据库、10……交通信息数据库、11……运行信息数据库、12……处理部、13……恢复步骤数据库、14……监视中心、15……维护工程师、16……专业技术人员、17……终端、18……控制盘、18a……升降机的状态、18b……恢复预估时刻、18c……状态栏、19……交通信息提供系统。

具体实施方式

以下，参照附图针对本发明的一实施方式进行详细描述。

(1)系统结构

图1是表示包含作为本实施方式所涉及的升降机故障诊断系统的一例的故障恢复支援系统4的系统整体的结构例的框图。故障恢复支援系统4连接到远程监视由升降机控制部1a控制的各升降机(以下示例为“电梯”)1的远程监视装置2、交通信息提供系统19、便携式终端3以及终端17。升降机控制部1a输出与各电梯1的运转控制有关的运转控制信息。此外，对各电梯1预先赋予各管理编号。

交通信息提供系统19由交通信息公司运营，对故障恢复支援系统4提供包含道路的拥堵信息的交通信息。便携式终端3如后所述，由实施与电梯1有关的维护作业的维护员15操作。终端17由不同于维护员15的专业技术人员16操作。该专业技术人员16是专门从事故障恢复支援系统4的操作的技术人员。

在故障恢复支援系统4中，例如，当电梯1发生故障时，维护员15向发生了该故障的现场出发，并确认该故障的状态。维护员15使用便携式终端3，将发生了该故障的电梯1的管理编号以及故障状态发送至监视中心14。

故障恢复支援系统4除了具备输入输出端口5以及处理部12，还具备数据库(以下，省略为db)6～11，13。输入输出端口5是在便携式终端3以及终端17之间的端口。从便携式终端3发送来的故障信息经由设置在上述监视中心14中的故障恢复支援系统4的输入输出端口5，被输入设置在上述监视中心14中的故障恢复支援系统4的处理部12。对于处理部12的详细内容，会与后述的故障恢复步骤生成处理一起进行说明。

db6～11、13相当于图示的故障日报db6、故障状态db7、危机管理db8、维护员技能db9、交通信息db10、运行信息db11以及恢复步骤db13。

从上述故障信息中，将在过去发生过的故障状态、调查内容、故障的原因以及对策等相互关联起来，按照故障发生日期和时间记录于故障日报db6中，对这些内容进行如后述那样进行管理，以便能够进行筛选。此外，故障状态即使与从故障状态db7中提取出的后述的漏洞分类相同，也会根据诸如轿厢内的装载量以及轿厢的运转方向这样的轿厢的运行信息而发生变化。

运行信息db11管理电梯1的故障时以及非故障时的运行信息，其细节稍后进行描述。在机器管理db8中，除了存储有电梯1的机器种类、设置环境以及设置场所等的电梯1的规格之外，不仅存储像该结构部件的大小、重量那样的规格信息，还存储该结构部件的库存状况。故障状态db7中，通过按照漏洞分类进行了分类的表格形式来管理电梯1可能发生的各种各样的故障状态。

维护员技能db9除了记录例如各候选维护员的移动方式以及便携式终端3的状态之外，还记录与所登记的各维护员接受过何种培训有关的培训受教履历、与各维护员在过去经历过何种维护作业有关的维护作业履历、各维护员的持有资格等。稍后描述维护员技能db9的详细内容。

交通信息db10暂时保管包含从交通信息提供系统19传送来的拥堵信息等的交通信息。交通信息db10在每一次从交通信息提供系统19传送来新的交通信息时进行更新。

上述机器管理db8、故障db6以及运行信息db11彼此相互将电梯1的管理编号作为关键字关联起来。这些机器管理db8、故障db6以及运行信息db11根据从升降机控制部1a输出的运转控制信息，通过手动在预定的时刻、或者按照预先决定的周期来定期地随时更新。

在恢复步骤db13中，登记有上述与用于按照漏洞分类来恢复故障的技术有关的故障原因查明恢复步骤。恢复步骤db13如后所述，将对故障状态进行名称搜索与汇总并分配的故障模式作为关键字，与故障状态db7的一部分的内容关联起来进行管理，其细节稍后进行描述。恢复步骤db13为了重新评估该内容，可以由维护员15通过便携式终端3来进行更新，或由专业技术人员16通过终端17来进行更新。

(2)故障恢复步骤生成处理

图2是表示由故障恢复支援系统4进行的故障恢复步骤生成处理的一例的流程图。该故障恢复步骤生成处理是为了通过故障恢复支援系统4的处理部12来生成某个故障的故障原因查明恢复步骤而被执行的。

首先，如后述的图4所示，处理部12从积累在故障日报db6中的故障日报中，提取包含与作为上述与故障有关的信息的问题信息(以下，也称为tcd)相对应的故障状态、原因、对策、管理编号以及故障发生日的一部分故障日报(步骤s1)。

处理部12如上所述，针对提取出的一部分的故障日报的内容，使用登记在故障状态db7中的tcd来进行筛选，由此进行分类(步骤s2)，并针对像这样的分类结果，实施所谓的名称搜索来汇总多个故障状态并分配故障模式(步骤s3)。也就是说，如后述的图5所示，汇总多个故障状态并在故障模式中被替换。此外，在以下的说明中，也将如此通过名称搜索而汇总出的信息称为“故障日志”。

接着，处理部12判定在运行信息db11中是否存在与该故障模式有关的故障时的运行信息(步骤s4)。在运行信息db11中不存在像那样的故障时的运行信息的情况下，处理部12不取得故障时的运行信息(步骤s9)，另一方面，在运行信息db11中存在像那样的故障时的运行信息的情况下，将管理编号作为关键字从运行信息db11中提取在各故障发生日观测到的数据、即各故障时的运行信息(相当于图示的电梯运行信息)(步骤s5)。

处理部12如后述的图6所示，将如上所述地提取出的各故障时的运行信息(相当于图示的电梯运行信息)与上述各故障日志(相当于图示的名称搜索结果即故障模式以及故障日报的内容)关联起来(步骤s6)。

之后，处理部12针对原因以及对策再次实施名称搜索(步骤s7)，如后述的图7所示，生成按照故障时的运行信息整理出原因以及对策的故障原因查明恢复步骤(相当于所谓的fta)(步骤s8)，并将其按照预定的顺序登记到恢复步骤db12中。

如此登记到恢复步骤db12中的故障原因查明恢复步骤不仅用于在恢复故障时进行参照，还能够用于查清产品改进或维护作业关键点(vitalpoint)。

另外，处理部12可以根据存储在维护员技能db9中的维护员15的技能，来变更像这样在恢复步骤db13中登记完成的各故障原因查明恢复步骤的顺序。例如，如果是有经验的维护员15，则能够一边针对故障的原因以及对策在某种程度上进行推测，一边继续进行调查，因此如果是像这样的有经验的维护员15，则有可能减少直到完成故障的恢复的故障恢复时间。因此，处理部12改变上述顺序以使故障恢复时间成为最短。

这里，处理部12不仅使特定的故障发生日作为从运行信息db11取得的故障时的运行信息的取得期间，还取而代之地，使该取得期间具有一定长度，例如，不只是该特定的故障发生日之前的预定的期间，也可以将其取代或者一并扩展到该特定的故障发生日之后的预定的期间。

于是，处理部12不仅对上述特定的故障发生日，而且对在时间上更大范围中的运行信息进行分析，由此能够在上述特定的故障发生日之前捕捉要发生该故障的前兆事件。而且，处理部12通过参照整备等维护作业实施前后的运行信息，还能够验证维护作业的效果。

接着列举具体例，来说明从发生某故障开始直到确定该故障的候选原因的流程。图3表示图1的故障状态db7的表格结构的一例。此外，在以下的说明中，tcd表示问题信息。

图示的tcd1～tcd8表示在发生了某特定的故障的情况下该故障的发生位置的一例。这些tcd1～tcd8最多可以登记8个，并与表示该故障的内容的故障模式一起，与表示发生该故障时的运行状态的运行信息对应起来进行管理。从图1所示的故障信息db7中提取故障模式。可以由上述专业技术人员16使用终端17来输入各运行信息，也可以设为自动地输入。

图4表示由图1所示的处理部12筛选了故障日报db6的内容后的结果的一例。在这里，作为一例，想要生成诸如“在启动时反转”这样的故障状态的故障原因查明恢复步骤的调查步骤。

这种情况下，处理部12参照故障日报db6，如图4所示，与tcd一起提取“fls动作”“在up时反转”等的同类的故障状态。此外，图示的up时表示轿厢在井道内上升时，dn时表示轿厢在井道内下降时。

处理部12针对这些提取出的故障状态，将tcd作为关键字实施名称搜索，如图5所示，对该名称搜索的结果分配“反转、脱出”的故障模式。

当完成如此对名称搜索的结果分配故障模式时，处理部12如图6所示，从运行状态db提取成为对象的故障时的运行信息“轿厢运转方向”“轿厢内装载”，并与故障模式结合。此外，“轿厢运转方向”表示电梯1的轿厢的运转方向，“轿厢内装载”表示轿厢内的装载量。

与此同时，处理部12如图所示，通过对故障日报的内容中的原因以及对策进行名称搜索来统一同义词，例如生成与用于按照漏洞分类来恢复故障的技术有关的故障原因查明恢复步骤(参照图7)。当完成像这样的名称搜索时，处理部12如图7所示，按照故障状态对原因以及对策进行分类并实施对原因的加权，并计算重要度作为该数值。该重要度在图7中被图示为原因中的括号内的数值。上述加权主要由故障件数决定。然而，在本实施方式中，进行像对维护作业关键点的内容提高重要度这样的处理也是有效的。此外，为了重新评估恢复步骤db13的内容，可以由维护员15通过便携式终端3来更新该内容，或由专业技术人员16通过终端17来进行更新。

(3)故障原因查明恢复处理

图8是表示故障原因查明恢复处理的一例的流程图。当对于电梯1在某现场(以下称为“故障发生现场”)发生故障时，处理部12参照维护员技能db9，根据各维护员15所持有的各便携式终端3的位置信息，列出能够去往故障发生现场并具有能够应对该故障的技能的维护员(以下，设为“候选维护员”)(步骤s11)。

处理部12基于根据候选维护员的位置信息、移动方式以及便携式终端3的状态而判定出的作业状态，计算从各候选维护员的当前位置到故障发生现场的移动所需时间。此外，在各候选维护员的移动方式为服务车的情况下，加上由交通信息提供系统19提供的交通信息的一部分即拥堵信息来计算移动所需时间(步骤s12)。

接着，处理部12在计算故障恢复时间时，根据在恢复同类故障时的规定的平均值来计算故障恢复时间(以下称为“平均故障恢复时间”)(步骤s13)。

此时，处理部12考虑由各候选维护员的培训受教履历、应对履历等决定的技能来校正平均故障恢复时间。具体而言，处理部12例如将技能较低的候选维护员的平均故障恢复时间设为1.2倍，另一方面将技能较高的候选维护员的平均故障恢复时间设为0.8倍(步骤s14)。

由于还存在根据故障的原因需要进行部件更换的情况，因此处理部12假设部件的更换，并参照机器管理db8，确定临近据点中的结构部件的库存状况、大小、重量并决定运输方式，计算该部件的运输所需的运输时间。

进而，处理部12在运输方式为服务车的情况下，与移动时间同样地加上拥堵信息(步骤s15)，并针对每一个候选维护员计算将上述移动所需时间、上述平均故障恢复时间以及上述运输时间相加而得的所需时间总和(步骤s16)。

处理部12对各候选维护员的所需时间总和进行比较，并针对各候选维护员中能够最快进行恢复的特定的维护员15所持有的便携式终端3发送故障恢复指示(步骤s17)。此时，处理部12在该故障恢复指示中包含有与故障发生现场有关的信息。

接收到该故障恢复指示的便携式终端3在视觉上或听觉上输出该故障恢复指示到其显示区域，接收到该指示的特定的维护员15快速前往故障发生现场。到达了故障发生现场的特定的维护员15，按照所述故障原因查明恢复步骤来调查故障的原因(步骤s18)，当查明原因时(步骤s19)，实施与其对应的对策来恢复故障(步骤s20)。

处理部12例如针对大客户，通过将上述各信息分发给该客户侧设备，使准备好作为该客户侧设备的一部分的图9所示的控制盘18显示包含电梯1的状态显示栏18a、表示从故障中恢复的故障恢复时间的恢复预估时刻显示栏18b、以及表示恢复作业进度状况的状态栏18c的画面。另一方面，处理部12针对小型客户，使用电子邮件来分发上述各信息，由此能够提供与上述画面基本相同的内容。如上所述，通过向客户提供准确的故障恢复时间，能够抑制利用者的不安感。

根据像以上的实施方式，即使在故障状态会根据轿厢的运行状态而发生变化时，也能够准确地查明原因，缩短故障恢复时间。

此外，处理部12如果使设置在用于未图示的某集体住宅的电梯层站中的防盗摄像头的显示屏，显示与上述客户侧的控制盘18相同的提示内容、即表示电梯1的状态显示栏18a、恢复预估时刻显示栏18b、以及恢复作业进度状况的状态栏18a，则对于该集体住宅的住户以及商业设施的利用者也能够发挥同样的效果。

(4)其他的实施方式

上述实施方式是用于说明本发明的示例，其主旨并不在于将本发明限定在这些实施方式中。本发明在不脱离其主旨范围内，能够以各种各样的方式来实施。例如，在上述实施方式中，说明了顺序执行各种程序的处理，但是并不限定于此。因此，只要处理结果中不存在矛盾，则可以构成为交换处理的顺序或者进行并行动作。

工业上的利用可能性

本发明能够广泛应用于与用于在发生了升降机的故障时应对故障的故障原因查明恢复步骤的生成有关的升降机故障诊断系统。