CN104891284A - 电梯的群管理系统 - Google Patents

Abstract

本发明的电梯的群管理系统，通过保存·学习对乘梯厅呼叫的分配的检索结果并用于下次检索时，从而能够提高分配精度和处理速度，使最合适的轿厢高效地进行应答。群管理控制装置(10)具备：分配控制部(11)，基于当前的呼叫的状态和将来会产生的呼叫的预测，进行用于将成为分配对象的乘梯厅呼叫分配给上述各轿厢的某一个的检索；分配执行部(12)，基于通过分配控制部(11)得到的检索结果，将上述乘梯厅呼叫分配给各轿厢(1a～1c)中最合适的轿厢；以及数据库部(13)，用于保存检索结果。分配控制部(11)在任意的楼层产生了新的乘梯厅呼叫时，参照数据库部(13)保存的检索结果，缩小对该乘梯厅呼叫的分配的检索范围。

Description

电梯的群管理系统

技术领域

本发明的实施方式涉及对多台轿厢的运转进行控制的电梯的群管理系统。

背景技术

电梯的群管理的目的在于，考虑当前产生的呼叫(乘梯厅呼叫、轿厢呼叫)的状况和轿厢的当前位置、乘梯人数等，向乘梯厅呼叫分配合适的轿厢。为了合适地对轿厢分配乘梯厅呼叫，原本需要考虑如下的全部要因。

1.当前的分配给已经产生但未被服务的呼叫(未应答呼叫)带来的影响

2.当前的分配给将来的呼叫带来的影响

3.将来的呼叫产生给迄今为止分配的全部的未应答呼叫带来的影响

其中，上述1的要因容易处理。但是，对于其他要因，以往的群管理方式几乎不进行处理。这是因为，需要同时考虑包含将来的假想呼叫的多个呼叫。即，对于多个呼叫，为了从全部的分配的组合中找到准最优解，必须进行最优化运算。

作为最优化运算的方式，有利用GA(遗传算法)和/或SA(模拟退火)的方式。但是，这些方式中，运算处理花费时间，极难实现群管理所需的实时性。

因此，考虑被称为RTS(Real Time Scheduling：实时调度)的新方式。RTS考虑当前分配的呼叫给将来的呼叫带来的影响和将来的呼叫给迄今为止分配的全部未应答的呼叫带来的影响，实现具有实时性的电梯群管理。

发明内容

上述RTS中，在成为分配对象的乘梯厅呼叫中包含预测将来会产生的假想的呼叫(乘梯厅呼叫和轿厢呼叫)地进行分配的检索。因而，当轿厢的台数和/或层数增加时，分配的检索范围变广，难以在一定时间内确定最合适的轿厢。

本发明解决的问题是，提供一种电梯的群管理系统，通过保存·学习对乘梯厅呼叫的分配的检索结果并用于下次检索时，从而能够提高分配精度和处理速度，高效地使最合适的轿厢进行应答。

本实施方式的电梯的群管理系统，是一种对多台轿厢的运转进行控制的电梯的群管理系统，具备：分配控制部，基于当前的呼叫的状态和将来会产生的呼叫的预测，进行用于将成为分配对象的乘梯厅呼叫分配给上述各轿厢的某一个的检索；分配执行部，基于通过该分配控制部得到的检索结果，将上述乘梯厅呼叫分配给上述各轿厢中最合适的轿厢；以及数据库部，用于保存通过上述分配控制部得到的检索结果。上述分配控制部在任意的楼层产生了新的乘梯厅呼叫时，参照在上述数据库部保存的检索结果，缩小对该乘梯厅呼叫的分配的检索范围。

根据上述构成的电梯的群管理系统，通过保存·学习对乘梯厅呼叫的分配的检索结果并用于下次检索时，从而能够提高分配精度和处理速度，高效地使最合适的轿厢进行应答。

附图说明

图1是表示一实施方式的电梯的群管理系统的结构的框图。

图2是用于说明该实施方式中的群管理控制装置的检索结果保存·学习处理的流程图。

图3是示意表示该实施方式中的群管理控制装置的分配的检索的图。

图4是表示该实施方式中的群管理控制装置的数据库部的结构的图。

图5是表示该实施方式中各号机的轿厢的实际运行状况的一例的图。

图6是表示在该实施方式中的群管理控制装置的数据库部设定的再评价值的一例的图。

图7是表示该实施方式中的群管理控制装置的分配处理的流程图。

图8是表示该实施方式中的群管理控制装置的数据库部的保存内容的一例的图。

图9是示意地表示参照了该实施方式中的群管理控制装置的数据库部的分配的检索的图。

具体实施方式

以下，参照附图说明实施方式。

图1是表示一实施方式的电梯的群管理系统的结构的框图，示出了对多台(这里是A～C号机这3台)电梯进行群管理的结构。另外，这里所说的“电梯”基本是指“轿厢”，也称为“号机”。

图中的1a～1c是号机控制部，2a～2c是轿厢。A号机控制部1a进行A号机的轿厢2a的运转控制。具体地说，号机控制部1a进行用于使轿厢2a升降动作的未图示的马达(卷扬机)的控制和/或门的开闭控制等。B号机控制部1b、C号机控制部1c也同样。这些号机控制部1a～1c包括计算机。

轿厢2a～2c通过马达(卷扬机)的驱动在升降井内进行升降动作。在轿厢2a的厢内，设置有包含目标层按钮3a、开门按钮4a、关门按钮5a的各种操作按钮。这些按钮的信号经由A号机控制部1a而传送至群管理控制装置10。

同样，在轿厢2b的厢内，设置有包含目标层按钮3b、开门按钮4b、关门按钮5b的各种操作按钮。这些按钮的信号经由B号机控制部1b而传送至群管理控制装置10。在轿厢2c的厢内，设置有包含目标层按钮3c、开门按钮4c、关门按钮5c的各种操作按钮。这些按钮的信号经由C号机控制部1c而传送至群管理控制装置10。

另外，在各层的乘梯处(电梯乘梯厅)，设置有用于登记乘梯厅呼叫的乘梯厅按钮6a，6b，6c…。此外，在图1的例子中，乘梯厅按钮6a，6b，6c…经由号机控制部1a～1c而与群管理控制装置10连接，但是，也可以是与群管理控制装置10直接连接的结构。

这些乘梯厅按钮6a，6b，6c…包括上行按钮和下行按钮，构成为根据使用者的目的地方向来按压上行按钮或下行按钮。另外，在最下层仅由上行按钮构成，在最上层仅由下行按钮构成。

“乘梯厅呼叫”是指通过在各层的乘梯处设置的乘梯厅按钮的操作而登记的呼叫的信号，包含登记楼层和目的地方向的信息。另外，“轿厢呼叫”是指通过在轿厢内设置的目标层按钮的操作而登记的呼叫的信号，包含目标层的信息。

群管理控制装置10是用于对轿厢2a～2c的运转进行群管理控制的装置，与号机控制部1a～1c同样包括计算机。本实施方式中，该群管理控制装置10具备分配控制部11、分配执行部12、数据库部13、评价部14、状态监视部15。另外，这些处理部实际由软件或者软件和硬件的组合来实现。

分配控制部11具有RTS(Real Time Scheduling)的功能。分配控制部11基于当前的呼叫的状态和将来会产生的呼叫的预测，进行用于将成为分配对象的乘梯厅呼叫分配给各号机的轿厢2a～2c的某一个的检索。此外，RTS是公知的，因此这里省略详细的说明。

分配执行部12基于通过分配控制部11得到的RTS的检索结果，将该乘梯厅呼叫分配给最合适的轿厢。例如，在轿厢2a被确定为最合适的轿厢时，分配执行部12对A号机控制部1a输出乘梯厅呼叫的分配信号。A号机控制部1a通过接收该乘梯厅呼叫的分配信号，使轿厢2a应答该乘梯厅呼叫的登记层。

数据库部13例如包括非清除(non-clear)的RAM，保存通过分配控制部11得到的TRS的检索结果。在基于RTS的分配的检索结果中，包含表示各号机的轿厢2a～2c的运行状态的运行曲线和/或分配评价值等(参照图4)。“分配评价值”是表示分配乘梯厅呼叫时的最合适程度的指标。该分配评价值的数值越小表示评价越高，该分配评价值的数值越大表示评价越低。

评价部14基于各号机的轿厢2a～2c的实际的运行状况，对数据库部13保存的检索结果所包含的分配评价值进行再评价。“对分配评价值进行再评价”是指，与实际的运行状况相对照地验证了分配评价值时，判定以多少的概率命中。评价部14将表示该命中率的再评价值附加到数据库部13上的检索结果进行保存。该再评价值取“0.0～1.0”的值。数值越高表示评价越高(命中率高)。

状态监视部15监视各号机的轿厢2a～2c的运转状态(轿厢位置、运转方向、门开闭状态等)、呼叫(乘梯厅呼叫和轿厢呼叫)的产生状况等。

这样的结构中，在任意的楼层产生了新的乘梯厅呼叫时，分配控制部11进行基于RTS的分配的检索，基于该检索结果，将该乘梯厅呼叫分配给轿厢2a～2c中最合适的轿厢。

这里，RTS中，也包含假定为将来会产生的假想的呼叫地进行分配的检索。因此，轿厢台数和/或层数增加时，检索范围变大，存在处理花费时间的问题。因此，本实施方式中，在进行基于RTS的分配的检索时，在数据库部13保存·学习(再评价)该检索结果，用于下次检索时。由此，谋求缩短处理。

以下，详细说明本实施方式的动作。

这里，分为(a)检索结果保存·学习处理和(b)分配处理，进行说明。此外，以下的各流程图所示的处理通过由计算机即群管理控制装置10读入预定的程序来执行。

(a)检索结果保存·学习处理

图2是用于说明群管理控制装置10的检索结果保存·学习处理的流程图。

群管理控制装置10的分配控制部11在通过状态监视部15检测到在任意的楼层登记的乘梯厅呼叫后，进行基于RTS的分配的检索(步骤S11)。

具体地说，首先，分配控制部11考虑当前的呼叫的状态和将来会产生的呼叫的预测，对成为分配对象的乘梯厅呼叫追加假想产生的假想呼叫。分配控制部11分别制成向轿厢2a～2c分配了这些呼叫的情况下的运行曲线。分配控制部11一边比较各运行曲线，一边反复进行检索最合适的轿厢的处理。

此外，初始状态下，在数据库部13还未保存有检索结果，因此以通常的分配进行处理。另外，即使在数据库部13保存有检索结果，在无法用于本次的分配的检索的情况下，也直接以通常的分配进行处理。

检索到最合适的轿厢后，分配控制部11经由分配执行部12将乘梯厅呼叫的分配信号输出至与该轿厢对应的号机控制部，使其对上述乘梯厅呼叫的登记层进行应答(步骤S12)。

这里，分配控制部11将在本次的分配处理中得到的RTS的检索结果保存于数据库部13(步骤S13)。该检索结果中包含各号机的轿厢2a～2c的运行曲线、根据这些运行曲线算出的各号机的轿厢2a～2c的分配评价值。

另外，轿厢对乘梯厅呼叫的登记层进行了应答后，评价部14确认实际的运行状况，对数据库部13保存的检索结果的分配评价值进行再评价。评价部14将该评价结果数值化后得到的再评价值附加到该检索结果，保存于数据库部13(步骤S14)。

这里，举具体例说明上述步骤S13及S14的处理。

图3是示意表示分配的检索的图。图4是表示数据库部13的结构的图。

RTS中，阶段性地制成将分配对象的乘梯厅呼叫和假想呼叫分配至各号机的轿厢的情况下的运行曲线。此外，假想呼叫是考虑各层的交通需求和/或时段等而假想产生的呼叫，包含乘梯厅呼叫和轿厢呼叫这两方。

图3中，图中的带圈数字是运行曲线的数据编号。将分配对象的乘梯厅呼叫分配至A～C号机的轿厢的情况下的运行曲线用“1”、“2”、“3”表示。

进而，从运行曲线“1”的状态下将第1个假想呼叫分配至A～C号机的轿厢的情况下的运行曲线用“4”、“5”、“6”表示。从运行曲线“2”的状态下将第1个假想呼叫分配至A～C号机的轿厢的情况下的运行曲线用“7”、“8”、“9”表示。从运行曲线“3”的状态下将第1个假想呼叫分配至A～C号机的轿厢的情况下的运行曲线用“13”、“14”、“15”表示。另外，从运行曲线“9”的状态下将第2个假想呼叫分配至A～C号机的轿厢的情况下的运行曲线用“10”、“11”、“12”表示。

假想呼叫的个数预先设定。在该设定的个数中，阶段性地制成运行曲线。根据这些运行曲线求出各号机的轿厢的平均未应答时间，反复进行基于该平均未应答时间算出分配评价值的处理。将反复过程中评价最高的轿厢确定为最合适的轿厢。“最合适的轿厢”是指分配分配对象乘梯厅呼叫的轿厢。

上述步骤S13中，图3的检索结果(运行曲线、分配评价值)保存在数据库部13。但是，若在数据库部13保存全部的结果，则存储容量会不足，因此仅保存检索结果的一部分。

具体地说，在数据库部13保存具有最合适的运行曲线(决定了乘梯厅呼叫的分配的运行曲线)的检索结果。图4的例子中，10号的运行曲线与分配评价值一并保存在数据库部13。根据该10号的运行曲线，向B号机的轿厢分配乘梯厅呼叫(参照运行曲线“10”→“9”→“2”)。

此外，也可以将检索截止后的运行曲线(评价低，无法用于乘梯厅呼叫的分配的运行曲线)包含在保存对象中。这是因为，可以在下次以后的检索时将该运行曲线从分配的候补排除。

上述步骤S14中，确认实际的运行状况，对数据库部13保存的检索结果所包含的分配评价值进行再评价。在图5及图6表示具体例。

图5是各号机的轿厢的实际的运行状况的一例的示图。横轴表示时间，纵轴表示层数。图中的黑三角是乘梯厅呼叫。图6示出在数据库部13设定的再评价值的一例。

现在，假设对在1层产生的上行的乘梯厅呼叫，进行基于RTS的检索，结果，将最合适的运行曲线保存在数据库部13。图6的例子中，为运行曲线“10”。

这里，对照实际的运行状况和数据库部13保存的运行曲线。在分配轿厢按照数据库部13保存的运行曲线那样最早进行应答时，赋予好评(再评价值设定为高)。图5的例中，B号机的轿厢最早应答在1层产生的上行的乘梯厅呼叫，因此，数据库部13保存的运行曲线命中。在该情况下，作为再评价值，例如取“0.6”。

再评价值取“0.0”～“1.0”的值。数据库部13保存的运行曲线命中时，不立即赋予最高值的“1.0”，这是因为，下次以后不一定出现相同的结果。因而，优选采用以比平均值“0.5”稍高的“0.6”作为初始值并从该值进行微调的方法。

另一方面，可能出现例如大量产生轿厢呼叫等而应答延迟，或者其他号机的轿厢先不停靠地直接通过乘梯厅呼叫的登记层的情况。在这样的情况下，认为数据库部13保存的运行曲线的预测偏离，赋予差评(再评价值设定为低)。用图5的例子来说，在A号机或者C号机的轿厢比B号机先通过1层而不停靠的情况下，将再评价值设定为低。

此外，再评价值设定为低时，不是最低值的“0.0”，为了观察下次以后的情形，优选采用以比平均值“0.5”稍低的“0.4”左右作为初始值并从该值进行微调的方法。

这里，设为基本不考虑分配变更。即，例如即使事先知道C号机的轿厢比分配轿厢即B号机先不停靠地通过1层，也不将乘梯厅呼叫分配变更到C号机的轿厢。但是，例如在B号机和C号机之间产生预定时间以上的差的情况下，也可以进行分配变更。

(b)分配处理

图7是表示群管理控制装置10的分配处理的流程图。

在任意的楼层产生了新的乘梯厅呼叫时(步骤S21的是)，该乘梯厅呼叫的信号经由群管理控制装置10的状态监视部15而提供给分配控制部11。这里，分配控制部11至少以乘梯厅呼叫的登记层和目的地方向、各轿厢的位置和运行方向为条件，从数据库部13搜索接近现状的检索结果(步骤S22)。

根据上述(a)，在数据库部13保存有过去的检索结果(通过过去的检索得到的运行曲线和分配评价值)。若在数据库部13保存有接近现状的检索结果(包含与现状相同的情况)(步骤S23的是)，则分配控制部11从数据库部13读出该检索结果(步骤S24)。

例如，若在1层登记上行的乘梯厅呼叫，此时A～C号机的轿厢位置和运行方向接近图6所示的运行曲线“10”，则从数据库部13读出索引(index)为“001”的检索结果。

接着，分配控制部11实施基于RTS的分配的检索(步骤S25)。此时，分配控制部11参照附加于从上述数据库部13读出的接近现状的检索结果的再评价值，缩小对该乘梯厅呼叫的分配的检索范围，或者中断检索(步骤S26)。

即，在检索结果的再评价值高的情况下，通过进行与数据库部13同样的分配，得到好的结果的可能性高。因而，分配控制部11将该检索结果优先包含于分配的候补而缩小检索范围。另一方面，在检索结果的再评价值低的情况下，即使进行与数据库部13同样的分配，实际与预测偏离的可能性高。因而，分配控制部11从分配的候补排除该检索结果而进行其他检索(参照图8)。

这样，分配控制部11一边参照过去的检索结果，一边实施对该乘梯厅呼叫的分配的检索，在预定时间内选出最合适的轿厢，通知分配执行部12(步骤S27)。此外，在本次的检索中得到的结果追加保存于数据库部13，如图2所说明那样，通过与实际的运行状况的对照，进行再评价。

另外，上述步骤S23中，在数据库部13未保存有接近现状的检索结果时，分配控制部11实施通常的基于RTS的分配的检索，在预定时间内选出最合适的轿厢，通知分配执行部12(步骤S28)。在该情况下，在本次的检索中得到的结果也追加保存于数据库部13，如图2所说明那样，通过与实际的运行状况的对照，进行再评价。

这里，举具体例说明上述步骤S26的处理。

图8是表示数据库部13的保存内容的一例的图。图9是示意表示了参照数据库部13的分配的检索的图。与图3同样，带圈数字表示运行曲线的数据编号。

现在，假设在图8所示的数据库部13中，接近现状的检索结果为索引“001”、“003”。附加于索引“001”的检索结果的再评价值为“0.6”，附加于索引“003”的检索结果的再评价值为“0.2”。

这里，如索引“003”那样，再评价值比平均值(0.5)低的检索结果的分配精度低，因此从分配的候补排除。该例子中，如图9所示，对与该检索结果的运行曲线“6”关联的呼叫的组合的分配的候补被排除。另外，如索引“001”那样，再评价值比平均值(0.5)高的检索结果的分配精度高，因此优先包含在分配的候补中。由此，短时间判明向B号机的轿厢分配该乘梯厅呼叫的情形为最佳。

这样，在数据库部13保存基于RTS的分配的检索结果，在产生了新的乘梯厅呼叫时，通过参照数据库部13，能够缩小分配的检索范围。因而，与关于全部呼叫的组合制成运行曲线而检索分配的情况相比，能够缩短处理时间，能够早选出最合适的轿厢并使其进行应答。

另外，若对照实际的运行状况而对数据库部13上的检索结果进行再评价，则能够事先知道应优先的分配的候补和应排除的分配的候补。由此，能够更有效地实施分配的检索，选出最合适的轿厢。

(其他实施方式)

上述实施方式中，以在所有楼层登记的乘梯厅呼叫为对象，在数据库部13保存基于RTS的分配的检索结果，但是，也可以限定为某特定的楼层的乘梯厅呼叫而保存于数据库部13。“特定的楼层”是指例如“基准层”等乘客的乘梯下梯总是多的楼层和/或像“食堂层”等那样的时间上交通需求会变高的楼层。

这样，若采用限定为特定的层的乘梯厅呼叫而保存于数据库部13的结构，则可以抑制存储容量。另外，也可以在图7的处理中缩短搜索数据库的时间。

例如，在由于故障和/或点检等而能进行运转服务的号机的台数变更了的情况下，不利用数据库部13，而是进行图7的步骤S28所示的通常的分配检索。由此，能够防止在环境改变时参照数据库部13进行了不合适的分配的情况。

根据以上所述至少一个实施方式，能够提供一种电梯的群管理系统，其通过保存·学习对乘梯厅呼叫的分配的检索结果并用于下次检索时，从而能够提高分配精度和处理速度，使最合适的轿厢高效地进行应答。

虽然说明了本发明的几个实施方式，但是这些实施方式只是作为例子提出，目的不在于限定发明的范围。这些新颖的实施方式能够以其他各种形态实施，在不脱离发明的要旨的范围内，能够进行各种省略、置换、变更。这些实施方式及其变形包含于发明的范围和要旨，并且包含于权利要求所记载的发明及其均等的范围内。

Claims (8)

1.一种群管理系统，其是对多台轿厢的运转进行控制的电梯的群管理系统，其特征在于，具备：

分配控制部，基于当前的呼叫的状态和将来会产生的呼叫的预测，进行用于将成为分配对象的乘梯厅呼叫分配给上述各轿厢的某一个的检索；

分配执行部，基于通过该分配控制部得到的检索结果，将上述乘梯厅呼叫分配给上述各轿厢中最合适的轿厢；以及

数据库部，用于保存通过上述分配控制部得到的检索结果；

上述分配控制部在任意的楼层产生了新的乘梯厅呼叫时，参照上述数据库部保存的检索结果，缩小对该乘梯厅呼叫的分配的检索范围。

2.根据权利要求1所述的群管理系统，其特征在于，

上述分配控制部至少以乘梯厅呼叫的登记层和目的地方向、上述各轿厢的位置和运行方向为条件，从上述数据库部读出接近现状的检索结果，参照该检索结果，缩小对该乘梯厅呼叫的分配的检索范围。

3.根据权利要求1或2所述的群管理系统，其特征在于，

还具备评价部，该评价部基于上述各轿厢的实际的运行状况，对上述数据库部保存的检索结果所包含的上述各轿厢的分配评价值进行再评价，

上述分配控制部基于通过上述评价部得到的再评价值，缩小对该乘梯厅呼叫的分配的检索范围，或者中断检索。

4.根据权利要求3所述的群管理系统，其特征在于，

上述分配控制部在通过上述评价部得到的再评价值比平均值高的情况下，将上述检索结果优先包含于该乘梯厅呼叫的分配的候补而缩小分配的检索范围。

5.根据权利要求3所述的群管理系统，其特征在于，

上述分配控制部在通过上述评价部得到的再评价值比平均值低的情况下，将上述检索结果从该乘梯厅呼叫的分配的候补排除而中断检索。

6.根据权利要求1所述的群管理系统，其特征在于，

上述分配控制部限定于在特定的楼层登记的乘梯厅呼叫而仅将对该乘梯厅呼叫的检索结果保存于上述数据库部。

7.根据权利要求6所述的群管理系统，其特征在于，

上述特定的楼层包含乘客的乘梯下梯总是多的楼层或者时间上交通需求会变高的楼层。

8.根据权利要求1所述的群管理系统，其特征在于，

上述分配控制部在能进行运转服务的轿厢的台数变更了的情况下，不利用上述数据库部，而是进行通常的分配检索。