CN1220614C - 电梯目的楼层的呼叫控制方法及呼叫控制器 - Google Patents

Abstract

本发明涉及用于电梯逻辑结构的目的楼层呼叫控制方法呼叫控制器，其提高了运送能力，灵活并且耐用，具体地，它能够考虑到个人/群体乘客的运送需求。为了为注册的目的楼层呼叫确定最优运行次序，其通过基于情况的搜索方法为固定的、预定的最优标准计算目的楼层呼叫的服务。随着电梯瞬时位置的每个相关变化，确定全新的计划，然后运行电梯。通过运送量和/或使用的操作符定义，可以将控制技术服务需求调整到满足客户的需求。能够使用作为多代理系统而设置的目的控制系统来实现任何数目具有变化布局的电梯的逻辑控制，例如多楼层组。

Description

电梯目的楼层的呼叫控制方法及呼叫控制器

技术领域

本发明涉及电梯目的楼层的呼叫控制方法及呼叫控制器。

背景技术

按照公知的方式，电梯控制用于满足为大楼的不同楼层提供轿箱呼叫的目的。电梯的驱动仅被理解为“上行”，“下行”，“开门”，“关门”的命令。

在较大的建筑物中，通常安装一组二到八部电梯，为此，就需选择从一个楼层新输入之轿箱呼叫最为适宜出现的电梯，即所谓楼层呼叫。通常这就是具有到达该楼层的最短行进路径的电梯。但是，在该行进路径中，如果这组电梯中的每一部都不得不预先为其它楼层呼叫提供服务，然后乘客才能在该层登梯，则仅当他们按下对应的轿箱按钮，才知道其目的地。因此，由于总是存在关于要到达的目的地的不确定性，向电梯分派楼层呼叫就成问题。

因此，在电梯工业中，通过使用基于神经网络或者遗传算法的学习方法，可以观测大量的试验，以便熟练地“猜测”乘客的可能目的楼层。但是，这些方法的效果非常有限，因为仅只是粗糙的运行图，比如早晨的上楼高峰，可以各种可能性去认知它。但仍然不清楚哪一个乘客想在哪一个时候登梯，例如，他或者她在星期一早上大约10点37分在高楼层办公室的10层呼叫电梯。

解决控制问题的另一个出发点是所谓目的楼层呼叫控制器。利用目的楼层呼叫控制器，乘客在登梯或者登电梯轿箱之前，比如通过类似于电话的键盘，即所谓终端输入他们想要的目的楼层。根据终端位置，目的楼层控制就知道了登梯的楼层。在输入目的楼层之后，控制分配算法就弄清了电梯组中能够最快最舒适地将乘客运送到他或她的目的的电梯。终端指示电梯组中的该部电梯，乘客可以按照他或她自己的步幅进入相应标记的电梯。如果电梯为了乘客登梯而停靠，然后比如通过门框上的显示装置来确定乘客的目的地。在轿箱中不再出现任何用于输入目的地的按钮。按照这种方式，通过利用目的楼层呼叫控制器，可以将具有确定目的地的乘客分组，从而增加电梯系统的运送能力。

另外，从EP 0 699 617 A1得知这种目的呼叫控制器的示例，其用于识别每位乘客的位置。对于每个被识别的乘客，可以通过访问数据存储器，按照最优运送可能性的决定考虑关于登梯位置和下梯位置的附加数据、乘客空间需求和可能的附加服务需求。

这种以及其它常规目的楼层呼叫控制器都以基于分配规律的直接逼近算法为基础。按照每个特定实例的要求设计该分配算法并编程。在运行请求的情况下，即目的楼层呼叫的情况下，将与人和设备有关的、并通过适当传感系统检测的数据传递给分配算法，运行算法，用以确定运行次序。

如果在运行次序的执行期间出现新的附加运行请求，则修改已经计算的运行次序，以达到所述效果。但是，在这种情况下，仅可以进行简单的修改，其结果可以是仅仅执行与目的楼层呼叫有关并针对变化的前提不再是最优运行次序的修改运行次序。这会导致乘客较长的等待时间和/或运送时间。此外，在固定程序分配算法中，并不总是符合逻辑地和以不间断的方式来表达单独控制选项的相互关系，即所谓的服务需求。此外，用于计算运行次序，以特定需求形式创建的控制软件错综复杂。具体地讲，其缺点在于，以前创建的分配算法要付出相当的代价才能适用于不同特定客户的控制需求。实际上，为了适应变化的服务要求，不得不在每种情况下预备新的特定电梯分配算法并整体实现。

发明内容

于是，本发明的目的在于限定一种电梯设备的目的楼层呼叫控制器，除了能够增加运送能力之外，而且灵活并耐用，并具体考虑了乘客的单独和/或集体运送需求。

为了满足该目的，本发明提出了一种规划包括至少一部电梯的电梯设备的运行次序的方法，包括：a)、注册通过设置在电梯设备的楼层处的传感系统检测的、乘客的目的呼叫；其特征在于，b)、将目的呼叫记录在针对每个电梯的情况表示中，所述情况表示定义了该电梯的瞬时操作状态和希望的操作状态；c)、针对每个情况表示确定最优运行次序，所述最优是基于最小等待和/或服务和/或运行时间的；以及d)、预订与最佳的最优运行次序相对应的电梯，以满足目的呼叫。

此外，提供了一种目的楼层呼叫控制器，用于确定电梯设备的一部或者多部电梯的运行次序，包括：至少一个用于检测乘客的目的呼叫的注册装置；和用于为每部电梯确定运行次序的处理单元，其特征在于，所述处理单元包括：情况表示，所述情况表示中记录了目的呼叫，并且所述情况表示定义了电梯的瞬时操作状态和希望的操作状态；以及规划系统，所述规划系统针对情况表示确定最优运行次序，所述的最优是基于乘客的最小等待和/或服务和/或运行时间的。该关于装置的解决方案使用所谓规划系统提出了一种运送量的结构。

因此，根据本发明，提供一种本质上已为人们所了解的规划系统，以取代以前采用的特定用途的固定程序控制算法。规划程序根据基于环境的搜索程序来工作，并确定特定环境的最优运行次序，它与目的楼层呼叫和从电梯设备的瞬时操作状态开始的行动以及电梯设备要产生的目的状态有关。

根据以环境为基础的搜索程序的应用实际上提供了一些优点：在瞬时环境的任何有关变化情况下，例如，关于新的运行请求的注册，中断执行运行次序等，在执行的每个运行次序步骤之后的极端情况下，确定全新的实际运行次序，然后电梯驱动装置执行这一次序。

例如，利用每个有关变化的注册，在每个目的楼层呼叫的情况下，基于状态描述的实际情况，宣布合并电梯设备的瞬时操作状态和想要的目的操作状态。状态描述中说明的并且即将得到的电梯设备状态变化作为情况表示的一部分，以转换的形式传递给规划系统；下面将会说明所述情况表示。因此，利用每个注册的目的楼层呼叫，以环境搜索程序为基础，获得关于电梯设备运行状态的全部信息。因而，可以针对固定的、预定的最优化标准来计算目的楼层呼叫的最优服务。设计该计算程序，以便实际上可以按照给定的标准在实时需求的情况下找到最优值。

通过规划系统，按照可以在运行次序计划的执运行序中得到所要的状态变化的方式，制成确定的运行次序计划。

因此，带有本发明规划运行次序的电梯设备，按照每种特有的实际情况执行表示实际规划环境最优的运行次序。在这种情况下，可以按照完全不同的标准实现最优化，其中由电梯性能的提高、乘客等待时间/服务时间以及运行时间的减少，或者平稳运行管理的提高来产生最优化目的。

规划程序以有利的方式局限于时间方面，这是因为计算性能和存储器要求受到限制。搜索程序在有限计算资源种寻求最优或者近似最优的运行次序。用于这一目的的所谓“无论何时”算法已为本领域的技术人员所熟知，并且可将它用在这种搜索程序中。

按照本发明搜索程序的优选实施例，最好以转换的形式将状态描述与情况表示中的操作符描述一起传递给规划系统。

根据本发明，配置时，将操作符描述传达到目的楼层呼叫控制器；最好包括规定电梯设备基本状态转移的操作符。与所要构建的运行次序解决方案的基本模块一样，在要确定的运行次序规划基础上，形成所述操作符。在每个目的楼层呼叫分配或者具体规划任务的解决方案情况下，规划系统从操作符描述中选择要在方案中使用的操作符，并确定操作符参数的具体数值，以及运行次序规划中出现操作符的排列次序。这种排列次序规定操作符在规划中的执行次序，即运行次序。

与以前的固定程序分配算法相比，所述规划系统可以具有任何数目的操作符，包括那些可以满足安装时用户一方尚未出现的服务需求。如果在稍后的时候出现这些需求，那么，几乎不需要向规划系统传达这些服务得以被表达的相应情况表示。于是，系统可以立即解决这个任务。如果没有为出现的服务需求提供操作符，则规划系统中操作符的模块性将会保证能以简单的方式添加或取出新的操作符，而不致影响已存在的操作符。因此，通过改变可以得到的操作符数目以及操作符自身的定义，电梯设备可以简单灵活地适应客户所需有关运量结构的变化。

在通过本发明的电梯呼叫控制器控制电梯组的情况下，如果电梯组中没有要满足乘客单独服务需求的单独预约电梯，就要考虑到电梯设备连续工作情况下的服务需求。从原理上讲，电梯控制和各操作符按照下面的方式互相匹配：任何电梯在任何时刻以情况表示的方式执行所有预定的特别服务需求。如果需要，服务需求是结合在对组的操作中的准特别呼叫。

可按中心原则、分散原则或中心原则与分散原则相结合嵌入规划系统，作为目的楼层呼叫控制器。

在使用所谓中心作业管理器构成目的楼层呼叫控制器的情况下，这就是电梯的终端和单独作业管理器之间的判定界面。终端向中心作业管理器指示其运送查询。作业管理器对各注册目的楼层呼叫，即为了所谓作业而向每个单独电梯的作业管理器请求输送许可。中心作业管理器负有单独管理乘客的所有实际运送查询，即目的楼层呼叫的责任，并预约各个被选择的电梯的运送请求，即所谓的作业。终端从中心作业管理器收到作为(被)选择的电梯的确定响应，并将它们显示于其上(如“A”或“B”)。

因为所有的通信都通过中心控制的方式，即中心作业管理器来进行，所以终端和电梯之间的通信简单而便于组织。在中心作业管理器中以等待队列来组织作业，即所谓“先进先出”的数据结构。这种组织比较简单，并保证清晰的运行次序。

在中心原则情况下，终端仅需处理乘客的目的楼层呼叫输入以及中心作业管理器预约的电梯确认，并且终端需要用于这一目的的简单软件。使用简单而经济的终端能够实现该目的。

在作业管理器的分散结构情况下，终端通过通信网络的形式与电梯组中单独电梯的作业管理器相连接。终端为各自注册的目的楼层呼叫直接向单独电梯的作业管理器请求运送许可。终端独立地收集并比较这些许可，并确定乘客的最佳预订。在分散作业管理器的情况下，以并行的方式组织多个作业，其中可叠加查询和预订。

目的楼层呼叫控制器的分散原则的另一个优点在于，与中心原则相比，作业管理器对查询的反应较快，因为不必提供分离的中心控制，所以由于作业管理器的分散化和简化结构的缘故，增强了整个系统的稳定性。

目前，作为提供的分散实施例，终端装有智能预订软件。最好通过使用约定的网络协议执行终端与单独电梯的作业管理器之间的通信联系。单独电梯的作业管理器能够并行组织作业和正确管理其状态。

在目的楼层呼叫控制器中，作业管理器的中心原则和分散原则也可以彼此结合。可以在网络中出现任何数目的控制一部或者多部电梯的作业管理器。

按照本发明特别的优选发展，基于环境的目的楼层呼叫控制器表现为实现设备的全部管理的多代理系统(multi-agent system)，其中在该多代理系统中，所述规划系统是代理。电梯设备可以包括任何数目的具有任何布局的电梯。因此，也可以使多部电梯与一组不同数目的楼层相互协作，即所谓非一致多楼层组。

与所述多代理系统一样的构造使模块化能够实现目的楼层呼叫控制器，其中，可以依需变换各组成部分，即所谓代理，如规划系统，轿厢门，驱动装置和运行操纵员而不必非得改变整个系统。

多代理系统中控制事件的代理激活使所述系统相对于错误的发生而言实际上更为耐用。例如，如果某层的旋转门因错误的联系而失控，则要么作业管理器可以撤销运行，要么运行操纵员可以执行已经存在的计划。对于其它的乘客查询，可以向配置管理器传达错误，向系统所有的有关组成部分通知该电梯暂时不能在该层楼提供服务。组成部分的故障并不意味着整个系统的迅速崩溃，从而保证了乘客的安全。

附图说明

下面在附图中示出了本发明的实施例，并对其进行了详细的说明，其中作为组织电梯设备运量的多代理系统形成所述目的楼层呼叫控制器。

图1以图例的形式示出第一实施例，它具有控制各个电梯的分散作业管理器的目的楼层呼叫控制器；

图2示出在具有用以控制一组电梯之分散作业管理器的目的楼层呼叫控制器中所要求的以及所许可的作业池的结构示意图；

图3示出第一实施例的瞬时状态描述；

图4示出根据第一实施例确定运行次序的曲线图；

图5以图例的形式示出第二实施例结构，它具有作为终端和各个电梯之间界面的中心作业管理器的目的楼层呼叫控制器；

图6以方框电路图的形式示出中心作业管理器的等待队列中作业的结构；

图7示出第二实施例电梯A的瞬时状态描述；

图8示出第二实施例电梯B的瞬时状态描述；

图9示出具有停止指令的操作符构造，有如第二实施例中所用的那样。

具体实施方式

图1以图例的形式示出了根据本发明楼层呼叫控制器1的构造，它具有环境导出的各个电梯运量运行次序的规划。象多代理系统一样来构造目的楼层呼叫控制器。多代理系统的基础是能够通过三个装置与分散作业管理器4相连接的形式来通信联系的网络2，所述的三个装置，即分布在建筑物中的终端3.1，3.2，3.3，用来输入目的楼层呼叫控制器。

按照理想的方式，选择自动联网结构作为通信网络2。在本实施例中，实质上已为人们所知的网络具有指定的IRON。IRON帮助自动联网，而且它是配置自由控制的判定前提。

已知的自动联网的示例结构是“Jini”，“Universial Plug and Play(通用即插即用)”和“Bluetooth(蓝牙)”。在这种通信网络2中，能够联网的装置(所谓代理)登录并相互作用，而不用进行配置或者管理。所有这些装置的综合以及实现的服务因此而完全自动地运行。这种通信网络2最主要的方法是“注册”，“查找”，“通知”。

通过“注册”，各个装置登录网络并使其服务为人所知。

通过“查找”，一个装置可以找到另一个装置或者请求的服务。

通过“通知“，对于特定时间项目的信息，一个装置可以登录另一个装置。

在电梯组中，终端、驱动装置、轿箱门、中心作业管理器和/或分散作业管理器作为能够联网的装置登录。

—终端使用楼层位置和网络中的x，y坐标，以登录网络并向它们本身通知存在所有的管理器；

—驱动装置表示电梯控制的物理组成部分。它们获知有关可以到达的楼层信息，某楼层有多少个旋转门，以及位于哪一侧。此外，可以将关于特定时间，如选择器的变化和状态的变化(例如，行走，到达，停止)信息提交给驱动装置。

—轿箱门以属于哪一个驱动装置，设置在哪一个楼层和哪一侧打开的信息登录。通过这些信息，作业管理器立即找到一部电梯管多少个楼层和每个楼层有多少门。

—作业管理器使用有关它们表示哪一个驱动装置的信息登录网路；严格分散原则下的单一驱动装置或者严格中心原则下出现的所有驱动装置。

从原理上讲，任何数目的组成部分都可以登录到网络中。因此传统的电梯组概念成为多余，具体地说，布局完全不同的任何数目的电梯都可以出现在一个组中。

例如，如果十一部电梯驱动装置登录，其中的三部都仅有一个门，四部具有两层上的三个门，四部具有均匀分布在三层上的六个门，那么这就有了所谓的非一致多层电梯组，其包括：

三个带有一个门的单层电梯，

四个双层电梯，其中一层电梯具有一个门，另一层电梯具有两个门，

四个三层电梯，其中每层电梯有两个门。

在控制中，每个单独电梯的作业管理器能够识别和正确处理与驱动装置有关的一定数目的[楼]层和门。具体包括；

在多层电梯的情况下，规划系统通过出现的所有层来规划乘客的登梯和下梯。

作业管理器的运行操纵员在停止时，向乘客想要登梯或者下梯的层的所有门发出开门命令。

在这里使用的IRON通信网络2的情况下，代理可以相互通知在自己的操作逻辑中改变、预备数据和对数据进行综合。代理可以通过广播发现其它代理中的哪一个已经登录到网络中，并且与其它代理通信。此外，代理可以向另一个代理预订数据。

所述多代理系统的各个组成部分，即所谓代理，除是上述终端外，还是作业管理器4，它对电梯的逻辑控制和物理控制所需的所有组成部分进行综合。这里有规划系统或者规划器5、调度器(程序)6、轿厢门管理器7、运行操纵员8、电梯驱动装置9和观察器(程序)10。

终端3.1，3.2，3.3安装有智能预订软件，并直接向每个作业管理器4为各自的注册目的楼层呼叫请求运送许可。通过规定的网络协议执行终端与作业管理器4之间的通信联系。每个终端3.1，3.2，3.3都装备有配置管理器11所属的乘客识别装置，

实际建组物布局，例如，楼层数，进入区域，乘客分组，进入识别，服务需求等和乘客数据都存储在能够被呼叫的配置管理器11中。在注册目的楼层呼叫时，每个终端都可以从配置管理器11收集乘客数据，并将这些数据传递到调度器6。于是，每个终端检查注册的乘客是否具有进入想去的目的楼层的允许。如果检查成功，则终端向作业管理器4请求其运送许可。

规划器5本身考虑实际的和特定运量情况，来计划向新乘客提供最优服务，并且在这种情况下产生最优计划，然后传递给调度器6，用来控制电梯驱动装置9，后面将会说明所述的调度器。规划器5的起始点是情况表示，这在调度器6记录新乘客的每个时间点都是实际的，而观察器消除被运送的乘客数据。

调度器6通过两阶段规定的网络协议与三个终端3.1，3.2，3.3通信联系。它接收终端3.1，3.2，3.3的输入，并以情况显示的方式将其记录在规划器5，针对运送预订的乘客中新乘客的影响检查所生成的最优计划，并将运送许可传达给终端。如果譬如因该电梯的乘客组之间不可解决的矛盾而导致不能解决该问题而找不到办法，那么调度器6同样向对应的终端通知该事实。如果有乘客预订，则调度器6向运行操纵员8发送实际的运行次序计划。终端将其表示在显示器上。

观察器10监控电梯设备的状态，并更新规划器5的情况表示。如果确定电梯已经停止在某层，并且轿厢门正确地打开，那么所有的乘客都加上提出-boarded-的乘客-served-标记则把所有“登梯”的乘客标记为“已服务”，并且他们的目的地与该楼层相应。从当电梯到来时他们登梯算起，乘客一直等到标记为“已登梯(boarded)”。在这种情况下，观察器对计划或者运行操纵员的行为一无所知，仅仅由在驱动装置9和轿厢门管理器7预订的信息来维持。这与发生特殊操作是一样的，例如在火警的情况下触发控制，通过驱动装置9来处理控制，并中断运行操纵员的正常操作，以便保证情况表示按照实际状态发生的变化来更新。

运行操纵员查看各自的实际计划，也就是把相应的命令传输给电梯驱动装置9和门的驱动装置。根据时间表，从其实际的计划可以得知电梯停靠的下一站和轿厢门打开多长时间，以便所有的乘客具有足够的时间登梯和下梯。规划器5已经确定有多少乘客在停靠时改变状态。如果运行操纵员8不再有计划，他就放弃电梯，以便停放该电梯。在任何位置，运行操纵员8都可以对于调度器6向其发送的实际计划而调换其实际的运行计划。这种变化如何发生，取决于运行操纵员处于何种实现状态。因此，例如，在运行操纵员8可以行进到新计划的第一停靠站之前，需要首先结束启动的老计划的停靠步骤。

驱动装置9执行从运行操纵员8得到的行进和停止命令，除此之外，它获知电梯在各楼层之间的行进时间。为了最优化，它作出规划器5可以使用的行进时间表，同样报告电梯的实际所处位置和行进方向，或者是否刚刚停止过。

轿厢门管理器7管理电梯所有的轿厢门，并监控轿厢门是否正常地打开和关闭。在这种情况下，所述轿厢门可以开在轿箱的不同侧面。其同样确定门打开和关闭的时间，并将其传达给规划器5，以便最优化乘客服务时间。

作为在发生特别情况下执行独立行动的独立代理来实现每个代理。具体地，多数的驱动时间因此可以叠加。因此，例如，调度器可以同时接收不同终端3.1，3.2，3.3的查询，并向它们提交规划器5。分散的作业管理器可以并行运送多个作业的许可，同时仍保持其它作业的预订。仅当相应的终端预订时，作业管理器才是必须的。

由于调度器6传送许可和各自终端的预订之间在理论上可以经过任何长的时间，因此，在该期间内，另一个终端能够进行预订。在这种情况下，当终端发出它的预订时，调度器6必须检查所传送的许可是否仍然有效。查询和预订的随机叠加需要终端等待其预订的确认，在没有确认的情况下，寻找另一个作业管理器4的预订。如果因为电梯中的情况已经按照某种方式改变，以致出现已经预订的乘客和要预订的乘客之间的矛盾，从而再次规划同样未取得成功，则终端接收相应的反馈。

图2示出分散作业管理器4中请求并许可的作业1到作业4的作业池。每个终端1，2通常只有一个电梯想要预订的具体作业X或者作业Y。于是，终端将该作业发送给电梯组的所有作业管理器4，其从驱动数据得知相关的电梯是否既可以充当乘客的登梯楼层又可以充当乘客的下梯楼层。可以避免对电梯的不必要的请求，从原理上讲，这对运送也不构成问题。

分散作业管理器4中出现两种工作：一方面，存在作业X，它被请求，并且作业管理器4必须为其计算许可，另一方面，存在作业Y，作业管理器4已经传送了许可，但是尚不知道终端是否实际上预订了它。

这里以及图1所示的第一实施例的情况下只存在单独一个电梯。不过，所述电梯也可以是一组电梯的一部分。本发明可以毫无限制地应用于这种电梯组。在电梯组的情况下，同样，终端3.1，3.2，3.3直接向每个电梯的作业管理器4请求运送许可。终端3.1，3.2，3.3单独收集这些许可，比较并计算乘客的最优预订。所查询的每个电梯主题与其它主题无关，并考虑到特定电梯的实际运量情况计算其最优的运行次序计划，用来为新乘客提供服务。所查询的每个电梯主题的许可返回到终端，选择最优的许可和并委托相应的电梯运送乘客。如果作业管理器4确认与已经请求运送许可的终端相关的预订，则预订是必须的，并且在终端向用户示明。如果作业管理器不再报告，则终端同样有反应，并且不再无止境地等待所缺少的许可。

下面参考图1，以具有单电梯单轿箱门的电梯设备的规划问题为例，说明目前所述本发明目的楼层呼叫控制器的工作模式，所述电梯设备为具有七层f1到f7停靠点的大楼(未示出)提供服务。电梯轿箱目前停靠在f4层。乘客P1在f2等待并希望到达f7层，而乘客P2已经在轿箱之中并要从楼层f1到f5。根据本发明通过规划系统3来组织轿箱的运行次序。

观察器10按情况表示方式检测并实现电梯的特性，即电梯的瞬时工作状态。乘客P1，P2的特性和乘客P1，P2的具体目的楼层呼叫作为目的楼层呼叫控制器1的输入量，通过与配置管理器11相联系的终端3.1，3.2，3.3传递给调度器6。如图2所示，所述调度器6在规划器5的情况表示中将它们记录下来。

在每个规划程序中，例如(图3所示那样)，通过目的楼层呼叫的注册来启动哪一个，确定的操作状态和想要的目的状态，以及电梯状态要得到的改变都在规划系统可理解的状态描述14中以声明的方式合并。

图3所示的状态描述14在按McDermott et al.，1998的规划表示语言PDDL中得以表达。本领域的技术人员同样清楚，还有其它具有不同表达能力的建模语言，以及用来描述情况表示，而不改变本发明核心的建模语言。但是，在选择规划系统中，要注意的是要获得建模的适当能力的规划算法。

在如图4所示状态描述14的目的声明15中，规划系统3在开始获知报告的乘客P1，P2和大楼的楼层f1到f7。为每个对象引入象征性常数。这里对于电梯2，有等待乘客P1，已经在轿箱中的乘客P2和所有的七层楼f1到f7。

(:objects

(p1                           -   passenger)

(p2                           -   passenger)

(f1，f2，f3，f4，f5，f6，f7   -   floor))

调度器6从配置管理器11获得有关大楼拓扑结构的详细情况。其可以作为拓扑描述在状态描述14中以下面的形式来发现：

(upper f1 f2)(upper f1 f3)(upper f1 f4)

(upper f1 f5)(upper f1 f6)(upper f1 f7)

(upper f2 f3)(upper f2 f4)(upper f2 f5)

(upper f2 f6)(upper f2 f7)(upper f3 f4)

(upper f3 f5)(upper f3 f6)(upper f3 f7)

(upper f4 f5)(upper f4 f6)(upper f4 f7)

(upper f5 f6)(upper f5 f7)(upper f6 f7)

在拓扑描述16中，在每个实例中建立命令(upper？fi，？fj)，楼层fj在fi之上。大楼拓扑表示并非绝对必要。在简化中，在假设电梯可以提供任何一层到其它任何一层的服务的条件下，在本方法的其它实施例中可以省略大楼的拓扑16的外在描述。

包括登梯楼层，即“origin”和目的楼层，即“distin”的具有乘客P1和P2的目的楼层呼叫的实际运送请求17如下表示：

(:init(origin p1 f2)

(origin p2 f1)

(destin p1 f7)

(destin p2 f5)

(boarded p2).

根据前面规划的运行次序，运送请求17另外还包括信息“boardedP2”，即乘客P2已经登梯并在轿箱之中。观察器10将该信息插入状态描述。

基本上，在运行次序的规划范围中，每个乘客P1，P2有三种状态：“waiting”，“boarded”和“served”，它们如下定义：

waiting：乘客在电梯门前等待。这里的电梯最初停靠在乘客的开始位置，即“origin”，在此之后，处于乘客指示的目的楼层，即“destin”。

boarded：乘客位于轿箱中，并被运送到他或她的目的楼层，即“destin”，该目的楼层以前并未到达过，即served。

Served：乘客在他或她的目的楼层已经离开电梯轿箱，即“destin”。该运送请求结束，乘客非常满意该电梯所提供的服务。

在PDDL建模语言中，以两条命令-boarded？p-和-served？p-来表示这三种可能的状态。乘客P1等待电梯轿箱，并因此既不被注册为-boarded-也不被注册为-served-。

观察器10设置电梯轿箱的实际位置18，其按照状态表示如下表达：

(lift-at f4)).

规划系统15的目的19按照状态描述14如下表达：

(:goal(forall(？p-passenger)(served？p)).

现在搜索将所有的乘客P1，P2转换为-served-状态的最短次序，当乘客离开其目的楼层-destin-时，可以精确地得到该结果。

除了通过状态描述14对初始状态的描述和规划问题的目的状态外，同样也将操作符描述12传送到规划系统3。在此说明的实施例中，为了建立初始状态和目的状态之间的状态转移模型，还传送停靠操作符以及向上运行-up-操作符和向下运行操作符-down-。作为这些操作符-stop-，-up-，和-down-的其它选择，本领域的技术人员还知道其它的够使电梯达到想要的变化的操作符，在给定的情况下并采用适当定义的参数，不会改变本发明的核心。根据McDermott等人1998的PDDL的语法，这里可以获得以下的停靠操作符：

(define(domain miconic)

(:requirements :adl)

(types passenger-object)

           floor-object)

(:predicates

(origin？person-passenger？floor-floor)

(destination？person-passenger？floor-floor)

(boarded？person-passenger)

(served？person-passenger)

(lift-at？floor-floor))

(:action stop

   :parameters(？f-floor)

   :precondition(and(lift-at？f))

   :effect(and(forall(？p-passenger)(when(and(boarded？p)

        (destination？p？f))

(and(not(boarded？p))(served？p))))

(forall(？p-passenger)(when(and(origin？p？f)(not

(served？p)))(boarded？p)))))

向上运行操作符被表示为：

(:action up

        :parameters(？f1-floor？f2-floor)

        :precondition(and(lift-at？f1)(upper？f1 f2))

        :effect(and(lift-at？f2)(not(lift-at？f1))))

向下运行操作符被表示为：

(:action down

        :parameters(？f1-floor？f2-floor)

        :precondition(and(lift-at？f1)(upper？f1 f2))

        :effect(and(lift-at？f2)(not(lift-at？f1))))

停靠操作符用信号向电梯驱动装置9的控制通知轿箱必须停靠在楼层f1到f7的特定楼层。于是，这里所述的实施例中将停靠操作符被定义成使它包括轿厢门的打开和关闭。也可以把轿箱门的打开和关闭看作门管理器7的独立附加基本指令，或者可以对停靠操作符进行改进，以达到电梯还能打开和关闭门的效果。

向上运行操作符-up-和向下运行操作符-down-向驱动装置控制发出关于控制方法的指令，以使驱动装置9按照适当的方向运行。运行操纵员8按时间预置操作符控制驱动装置9的次序。

基本上只有在轿箱停靠时乘客状态才变化。在电梯轿箱在楼层的预定停靠的情况下，所有为了由轿箱运送而在该楼层-origin-等待的乘客都登梯，并且当该停靠处于他们的目的楼层-destin-时，所有的乘客都离开电梯。从而，在观察器10的帮助下，这里发生的变化被注册在停靠操作符中，并且在规划系统5的运行次序规划中得到考虑。同操作符-up-和-down-一样，如果-effect-中编码的标准都得到满足或者被输入，则作为驱动装置9的指令的停靠操作符同样有效。这里所示的实施例中，如果在停靠操作符中选择了？f＝f5，当-boarded p2-和-destin p2 f5-应用在作为操作符实例stop(f5)的-effect-的停靠操作符中时，则P2根据状态描述14和行为模型下梯。

操作符描述中或者作为状态描述14的数据而说明到那个程度的数据被传递到规划系统5，用于计算最优运行次序计划。

从其它技术领域可以清楚规划系统5。本实施例中的IPP规划系统3可见于Koehler等人的‘Extending planning graphs to an ADL subset’(1997)inSteel，5，Proceedings of the 4th European Conference on Planning，pp.273-285，Springer，Vol.1348 of LNAI，这可从http：//www.informatik.uni-freiburg.de/～koehler/ipp.html获得，其搜索满足规划目的13(:goal(forall(？p-passenger)(served？p))的STOP指令的可使用次序。同样可以使用其它的规划系统，只要它们能够检测并处理瞬时情况表示。

在理论上，在状态描述14的输出的情况下，规划系统5在由操作符描述可获得的操作符的基础上独立地选择实例，同样在确认的运行次序计划20中确定次序。规划系统5每一次都确定三种操作符-stop-，-up-，-down-的参数，产生所要的状态变化。

在本实施例中的结果是，规划的运行次序，即最优计划，有如图3中曲线所示。

Time step 0：up f4 f5

Time step 1：stop f5

Time step 2：down f5 f2

Time step 3：stop f2

Time step 4：up f2 f7

Time step 5：stop f7

把这个计算的最优计划13传递到调度器6。调度器在此基础上检查所产生的最优计划，新规划进来的乘客P1如何具有已经预订的乘客的运送效果，并将运送许可传达给终端。

这里描述的实施例中，为了规划，只出现目的楼层呼叫。因此，对于一件作业只要提供一个许可。因此，在分散作业管理器4的许可计算与各自终端的预订之间，没有其它终端3.1，3.2，3.3的其它作业预订。因此，在终端确认其预订是多余的，但是预订是即时而必要的。此时终端承担显示器上的指示，而调度器将实际的最优运行次序计划20传输给运行操纵员8。

运行操纵员8检查该实际的运行次序计划20，即其将相应的命令按照各自的操作符的形式传输给电梯9的驱动装置，以及轿厢门驱动装置。

该运行次序计划20具有这样的效果：电梯轿箱在步骤0从其所处的实际楼层f4行进到下一停靠站楼层f5。电梯轿箱按照步骤1-stop f5-停靠，而轿箱门在预订的时间打开，以便乘客P2下梯，并因此得到服务，“served”。在步骤2，电梯轿箱向下运行，从f5到f2，-down f5 f2-，并在步骤3停靠在楼层f2，-stop f2-。乘客P1在那里登梯。在步骤4，电梯向上运行，从f2到f7，-up f2 f7-，并在最后的步骤5停靠在路层f7-stopf7-。同样，乘客P1在这里下梯。通过该运行次序13，所有的乘客P1，P2都转换为状态-served-，并且因此得到运行次序计划的目的模式10。

同时，运行操纵员8执行最优运行次序计划13，观察器10监控电梯设备的状态，并不间断地更新规划器5的情况表示。在步骤1，它确定电梯已经停靠在楼层f5，并且轿厢门被正常地打开；它对乘客P2加上-served-标志。在步骤2，观察器10对在f2楼层等待的乘客加上标记-boarded-。因此，电梯轿箱停靠在楼层f7，并且，在轿厢门正常打开之后，观察器10同样在位置描述中将乘客P1设置为“served”，以及在楼层f7的状态表示5中设置电梯轿箱的实际位置9。

但是，并非必须完全执行产生的这个运行次序计划20，相反，如果在此之前已经完全实现乘客的状态或者特征和/或设备以相关方式的变化，根据本发明，启动下一个规划周期，并为新的规划位置创建最优运行次序计划20。因此不对计划进行修改。

图5示出本发明第二实施例的目的楼层呼叫控制器的示意结构和基本构造。目的楼层呼叫控制器25包括中心作业管理器26和两个分散作业管理器，配置管理器29，以及具有所有典型终端特性的终端30，通过通信装置31相互连接这些组成部分。分散作业管理器27，28的结构和功能示意性地与第一实施例的分散作业管理器4的相对应。

在这里，作为所谓电梯组运量分组控制来组织所述目的楼层呼叫控制器，所述的电梯组有两个电梯A和B，并在七层大楼中有停靠点。在这种情况下，规划任务如下表示：

在此时，电梯轿箱A向上运行；位于楼层f2并将到达楼层f3。电梯轿箱B位于楼层f1。电梯A运送限制进入楼层3和4并且目的楼层是f7的乘客P1，而电梯B空闲。在这种情况下，新的乘客P2作为VIP(贵宾)出现，其因为优先权的缘故，而在其它乘客之前被运送。乘客P2刚刚将她或他的从楼层3运送到楼层f7的请求发送出去。

本例中以下面的方式将乘客P2分配给电梯A、B之一：以尽可能少的停靠站来运送乘客P1，P2，并且要满足所希望的服务需求“VIP”和“进入限制”。

中心控制管理器26收集来自配置管理器29的终端的请求以及分别检测的与人有关的数据，即等待队列中的作业，这里的Job1到Job4，有如图6所示的那样。从队列中选择Job1并将其传输给各自电梯的分散作业管理器27，28。电梯A，B的分散作业管理器27，28之一独立于其它作业管理器，并在规划系统的帮助之下按预定的最优标准确定最佳运行次序方案，并将其作为许可返回给中心作业管理器26。中心作业管理器26检查所有的许可，从中选择最佳许可，并以最佳许可预订电梯上的乘客。在成功分配之后，将最佳电梯的标识传输给最初开始作业的终端30。终端30因此仅仅作为显示器。因此处理Job1，并将其删除。对于Job2等等，重复该程序，直至等待队列中的所有作业都已处理完毕。

对于作为实际规划任务作业的注册通信数据信息，开始时，电梯A，B的每个分散作业管理器27，28创建情况表示，该情况表示被传输到各自的规划系统21。所述情况表示包括状态描述32和操作符描述。

对于电梯A，在目标声明33中，规划系统获知报告的乘客P1、P2和大楼的楼层f1到f7。为每个对象引入象征性常数。此外，在对象(目标)声明33中为每个乘客P1，P2执行与一个或多个服务需求的联合，例如，“VIP”，“conflict”，“going_direct”等。

在根据配置管理器29识别乘客的范围中的每种情况下，服务需求都是已知的，并且将它们作为部分作业或者许可查询，从中心作业管理器26传递给单独电梯A，B的分散作业管理器27，28。可以按照电梯设备或者大楼的情况，或者按照一天中的时间来为所有的或者任何选择的乘客提供特定服务需求。此外，通过使用规划系统，对于确定运行次序，可以按照运量将其表示为各项服务需求，尤其是VIP需求的灵活加权。

提供如下的服务需求：

将所有的乘客分成两组“conflict_A”和“conflict_B”，他们可能从未进入过电梯；

“never_alone”型乘客，对于他们而言，在运行中，必须有以“attendant”型的乘客为形式的同伴。在这种情况下，运行中并非绝对总是需要相同的同伴，而是可以改变的；

“going_direct”型乘客，他们在行进中不停靠，直接到达他们的目的楼层；

“vip”型乘客，因为优先的缘故，他们在其它乘客之前被运送；

阐明限制进入特定楼层的乘客；

“going_up”型乘客，只向上运送他们；

“going_down”型乘客，只向下运送他们；

因此，乘客P1，P2可以容易成为多种服务需求的主体；但是，这些需求应该是不冲突的，从而也可以有效地运送乘客。例如，两个乘客P1，P2是本质上是冲突的，对此，声明以下的事项：

(P1(either conflict_A never alone))

(P2(either conflict_B attendant))

这里，电梯中不单独运送P1，他属于乘客组A。但系统所知道的唯一可能同伴P2属于乘客组B；乘客组A可能从未进入电梯。伴随于此，就与所排除的情况不同，当另一个不属于组B的同伴变得为系统所知时，则仅仅P1被运送。

对于电梯A，对象声明33包括已经在行进的乘客P1，即正常乘客，新乘客P2，即VIP，以及所有的七层楼f1到f7。

(:objects

(p1                       -passenger)

(p2                       -vip)

(f1，f2，f3，f4，f5，f6，f7-floor))

本实施例中，假设从每一层开始到其它每一层都可以得到服务，故省去了大楼的拓扑表达描述。

乘客P1和P2实际注册的运送请求34表示如下：

(:init(origin p1 f1)

(origin p2 f3)

(destin p1 f7)

(destin p2 f7)

(boarded p1)

运送请求34的基本原则就是一般假设当出现无对应的“boarded”信息时，乘客在楼层等待。准确地讲，这表示乘客P2在这里等待。其中对乘客P1的进入限制表示为：

(no-access p1 f3)

(no-access p1 f4)

电梯A的电梯轿箱2的实际位置在状态描述32中表示为：

(lift-at f2))

所有表达的事实加权为正确，而所有其它的加权为错误。

规划系统的目的36用公式表示为

(:goal(forall(？p-passenger)(served？p)).

搜索将所有乘客P1，P2转换为“served”状态的停靠站最短次序，当他们在目的楼层或者楼层f7下梯之后，就可以准确地得到该结果。

由于在本实施例中，仅确定一种停靠最少的次序，规划系统同样接收一个所谓的停靠操作符37，根据它，系统可构建有效的运行次序计划。图9示出停靠操作符32的例子。同前面状态描述32中一样，这里，用按McDermott等人1998的建模语言PDDL来说明。停靠操作符37包括说明性描述38，其中说明了在何时允许电梯A，B在楼层f1到f7中停靠。这里，在这种情况下或者为乘客或者为乘客组具体定义进入限制-no-access-，在电梯轿箱应该停靠的楼层f1到f7建立功能指令39，以及在电梯设备18的实际停靠状态下该停靠所具有的效果。功能指令39在这种情况下的前提表示特定用户想要的服务需求的转换。如图9所示的复杂停靠操作符，能够通过与乘客有关的所有服务需求和对象声明33来绕过规划系统21。

对于这里描述的规划示例来说，仅与图5中下划线表示的操作符32的前提条件有关，该前提用公式表示在出现VIP和具有进入限制的乘客时在楼层f1到f7停靠的条件。

把为每个电梯A创建的瞬时情况表示32传递给属于电梯A的规划系统。

本发明使用的合适规划系统独立于实际的规划问题来工作。本领域的技术人员清楚这种规划系统。

在第二实施例中，同样，来自Koehler等人的1997，Extending planninggraphs to an ADL subset(1997)，appearing in Steel，Proceedings of the 4thEuropean Conference on Planning，pp.273-285，Springer，Vol.1348 of LNAI，并且可在http：//www.informatik.uni-freiburg.de/～koehler/ipp.html获得的IPP规划系统下，搜索满足规划目的31的STOP指令的有效次序。同样可以使用其它的规划系统，只要它能够完全检测和处理瞬时情况表示。

在解决具体规划问题时，规划系统选择操作符描述23的要在运行次序计划中使用操作符，这里指停靠操作符37。如果在状态描述32中出现服务需求，例如“VIP”，“going_direct”等，则规划系统独立地检查操作符37的功能指令39的相应前提条件。如果在与呼叫有关的状态描述32中未出现作为前提条件的包括在操作符37中的服务需求，则被认为是操作符37的多余前提条件，而被自动丢弃。这里未考虑的服务需求的示例是前提条件-attendant-。然后确定操作符参数的具体数值和运行计划中出现操作符的排列次序。该排列次序确定运行次序中操作符的执行次序，并因此确定为各自目的楼层呼叫服务的运行次序。

规划系统不能够为电梯A找到解决方案：乘客P2应该立即被运送，即电梯A必须在f3停靠。但是，P1在电梯中，并不可进入f3。因此，在P1下梯之后才能在f3停靠，即电梯A必须首先行进至楼层f7；由于VIP条件，需要VIP在所有乘客之前被运送，所以反过来是不可允许的。

由于电梯B根本上并不知道乘客P1，故规划系统可以为电梯B毫无问题地解决位置42(图8)，因为他或者她实际上在电梯中处于中途，而仅仅乘客P2被报告。因此，规划系统中电梯B的对象声明43同样仅包括由服务需求VIP表示的新乘客P2，和所有的七层楼f1到f7。

(:objects

(p2                          -vip)

(f1，f2，f3，f4，f5，f6，f7  -floor))

此外，从任何一层开始到任何一层都可以得到服务。

乘客P2的实际运送请求44表示为

(:init

(origin p2 f3)

(destin p2 f7).

在状态描述42中电梯轿箱B的实际位置描述45表示为

(lift-at f1).

在电梯B的情况下，规划系统的目的表示式46与电梯A的相同。它与对象43和作为电梯B的情况表示42一部分的上述停靠操作符37一起转移到规划系统中。对于电梯B的运行次序规划，仅仅与操作符前提条件“停靠在出现VIP的楼层”有关，因为电梯B的状态描述32同样只把服务需求VIP转移到规划系统。在这种规划次序中，未予考虑按STOP操作符37的功能指令39的指示和前提条件形式提供的所有剩下的服务需求，从而不对运行次序计划24产生效果。

从该输入开始，规划系统21为电梯B产生下面的运行次序：

time step 1：(stop 3)

time step 2：(stop 7)，

它表示成功运送乘客P2的最少停靠次序。

如果在中心作业管理器26输入电梯A，B的运行计划结果，则对电梯A，B的两个运行次序许可进行加权。中心作业管理器26选择具有最佳许可的电梯。这里，最佳解决方案就是电梯B唯一可能的运行次序计划。因此，中心作业管理器预订电梯B上的乘客P2。电梯B在接收到预订之后，实现运行次序计划；所有其它的电梯按其原先的计划行进。

Claims (9)

1.一种规划包括至少一部电梯的电梯设备的运行次序的方法，包括：

a)、注册通过设置在电梯设备的楼层处的传感系统检测的、乘客的目的呼叫；其特征在于，

b)、将目的呼叫记录在针对每个电梯的情况表示中，所述情况表示定义了该电梯的瞬时操作状态和希望的操作状态；

c)、针对每个情况表示确定最优运行次序，所述最优是基于最小等待和/或服务和/或运行时间的；以及

d)、预订与最佳的最优运行次序相对应的电梯，以满足目的呼叫。

2.根据权利要求1所述的方法，所述设备具有多于一部的电梯，其特征在于，在步骤a)之后，传感系统将目的呼叫指示给中心作业管理器，中心作业管理器然后将目的呼叫发送给针对每个电梯的分散作业管理器，每个分散作业管理器然后执行步骤b)和c)，并将最优运行次序返回到中心作业管理器，然后中心作业管理器执行步骤d)。

3.根据权利要求1所述的方法，所述设备具有多于一部的电梯，其特征在于，在步骤a)之后，传感系统将目的呼叫指示给针对每个电梯的作业管理器，其执行步骤b)和c)，然后将最优运行次序返回到传感系统，然后传感系统执行步骤d)。

4.根据权利要求1-3之一所述的方法，其特征在于，在步骤d)之后，通过传感系统将预订的电梯的标识传输给乘客。

5.根据权利要求1-3之一所述的方法，其特征在于，步骤a)还包括识别发出目的呼叫的乘客的步骤，而步骤b)还包括将乘客数据记录在情况表示中的步骤。

6.一种目的楼层呼叫控制器，用于确定电梯设备的一部或者多部电梯的运行次序，包括：

至少一个用于检测乘客的目的呼叫的注册装置；和

用于为每部电梯确定运行次序的处理单元，其特征在于，所述处理单元包括：

情况表示，所述情况表示中记录了目的呼叫，并且所述情况表示定义了电梯的瞬时操作状态和希望的操作状态；以及

规划系统，所述规划系统针对情况表示确定最优运行次序，所述的最优是基于乘客的最小等待和/或服务和/或运行时间的。

7.根据权利要求6所述的目的楼层呼叫控制器，所述设备具有多于一部的电梯，其特征在于，注册装置可操作地通过通信网络与每个处理单元相连接。

8.根据权利要求7所述的目的楼层呼叫控制器，其特征在于所述通信网络允许注册装置和每个处理单元之间的直接通信，注册装置从与处理单元中其通信的处理单元预定最佳的最优运行次序。

9.根据权利要求7所述的目的楼层呼叫控制器，其特征在于所述通信网络包括中心作业管理器，用于从处理单元中与其通信的处理单元预订最佳的最优运行次序。

Images