电梯系统中的分配决策计算的制作方法

文档序号:16809930发布日期:2019-02-10 13:30阅读:169来源:国知局
电梯系统中的分配决策计算的制作方法



背景技术:

电梯系统中的电梯控制可以在初始呼叫分配之后实现呼叫的再分配。这意味着,在某些情况下,将新电梯重新分配给已有呼叫将是有益的。然而,这种情况例如在使用即时呼叫分配的电梯系统中是不同的。即时呼叫分配的一个示例是目的地控制系统(dcs)。在即时呼叫分配中,通常不会重新分配已分配的呼叫。这可能导致这样的情况:在将呼叫分配给第一电梯之后,可能会发现用第二电梯服务该呼叫将是更有益和最优的。但是,如上面已经提到的,可能无法将已分配的呼叫中的呼叫重新分配给第一电梯,因为在目的地控制系统中,在给出呼叫之后立即向乘客发信号通知服务(分配的)电梯。

此外,电梯可能在为所有呼叫和分配给它的乘客服务之前变满。这在另一方面可能导致乘客服务水平降低,特别是在目的地控制系统中。



技术实现要素:

根据本发明的第一方面,提供了一种用于计算电梯系统中的分配决策的方法。该方法包括获得与电梯系统有关的历史乘客批次行程数据,其中,每个乘客批次行程包括行程的起始和目的地楼层、行程的乘客数量和行程的时间;基于乘客批次行程数据构建历史乘客运输统计;基于乘客运输统计对预期呼叫建模;以及在计算电梯系统中的后续分配决策时考虑建模的预期呼叫。

在一个实施例中,该方法还包括基于历史乘客运输统计估计电梯系统的电梯中的电梯负载;并且在计算电梯系统中的后续分配决策时考虑估计的电梯负载。

在一个实施例中,替代地或补充地,该方法还包括基于从历史乘客运输统计获得的乘客批次行程强度和批次大小分布以及模拟服务时间,对每个电梯旅程分别估计电梯系统的电梯中的电梯负载。

在一个实施例中,替代地或补充地,建模的预期呼叫包括至少一个层站(landing)和轿厢呼叫对。

在一个实施例中,替代地或补充地,建模的预期呼叫包括至少一个目的地呼叫。

在一个实施例中,替代地或补充地,乘客批次行程数据包括在预定的天周期内分别为每一天形成的建筑物起始-目的地矩阵。

在一个实施例中,替代地或补充地,电梯系统使用即时呼叫分配。

根据第二方面,提供了一种用于计算电梯系统中的分配决策的电梯控制装置。该装置包括至少一个处理器和连接到至少一个处理器的至少一个存储器。至少一个存储器存储程序指令,当该程序指令由至少一个处理器执行时使得所述装置获得与电梯系统有关的历史乘客批次行程数据,其中,每个乘客批次行程包括行程的起始和目的地楼层、行程的乘客数量和行程的时间;基于乘客批次行程数据构建历史乘客运输统计;基于乘客运输统计对预期呼叫建模;以及在计算电梯系统中的后续分配决策时考虑建模的预期呼叫。

在一个实施例中,至少一个存储器存储程序指令,当该程序指令由至少一个处理器执行时使得所述装置基于历史乘客运输统计估计所述电梯系统的电梯中的电梯负载;并且在计算电梯系统中的后续分配决策时考虑估计的电梯负载。

在一个实施例中,至少一个存储器存储程序指令,当该程序指令由至少一个处理器执行时使得所述装置基于从历史乘客运输统计获得的乘客批次行程强度和批次大小分布以及模拟服务时间,对每个电梯旅程分别估计电梯系统的电梯中的电梯负载。

在一个实施例中,替代地或补充地,建模的预期呼叫包括至少一个层站和轿厢呼叫对。

在一个实施例中,替代地或补充地,建模的预期呼叫包括至少一个目的地呼叫。

在一个实施例中,替代地或补充地,乘客批次行程数据包括在预定的天周期内分别为每一天形成的建筑物起始-目的地矩阵。

在一个实施例中,替代地或补充地,电梯系统使用即时呼叫分配。

根据第三方面,提供了一种包括程序代码的计算机程序,当该程序代码由至少一个处理单元执行时使得至少一个处理单元实施第一方面的方法。

在一个实施例中,计算机程序包含在计算机可读介质上。

根据第三方面,提供了一种包括多个电梯和根据第二方面的电梯控制装置的电梯系统。

附图说明

被包括以提供对本发明的进一步理解并构成本说明书的一部分的附图示出了本发明的实施例,并与说明书一起有助于解释本发明的原理。在图中:

图1a是示出用于计算电梯系统中的分配决策的方法的流程图。

图1b是示出用于计算电梯系统中的分配决策的方法的流程图。

图2a和2b公开了示出在电梯系统中进行分配决策的示例。

图3是示出在多轿厢电梯系统中操作电梯轿厢的装置的框图。

具体实施方式

图1a是示出用于计算电梯系统中的分配决策的方法的流程图。

在100处获得与电梯系统有关的历史乘客批次行程数据。每个乘客批次行程包括行程的起始和目的地楼层、行程的乘客数量(即,乘客批次大小)和行程的时间。乘客批次行程数据提供有关电梯系统中电梯的使用情况的历史实际数据。

在102处,基于乘客批次行程数据构建历史乘客运输统计。历史乘客运输统计可以基于建筑物起始-目的地(od)矩阵,建筑物od矩阵进而可以基于上述乘客批次行程。可以对每天d,d=1,2,...,d以及固定间隔[tk,tk+1],k=1,2,...,k分别形成建筑物特定od矩阵,其中d是周期中的天数,k是一天中的间隔数。例如,如果d被设置为“7”,则建筑物特定od矩阵覆盖每个工作日。

n×n建筑物特定od矩阵可表示为其中n是建筑物中楼层的数量,且b,b=1,2,...,b,表示批次大小(即,乘客数量)。建筑物特定od矩阵中的元素与乘客批次行程的强度(intensity)对应,乘客批次行程的强度等于在一天d的间隔k内从起始楼层i到目的地楼层j的批次大小b。

在电梯群组控制中,每个候选解决方案给出群组中电梯的呼叫分配。为了计算解决方案的成本或适应值,必须确定每个电梯的呼叫或乘客的服务顺序。这可以对每个电梯彼此独立地完成,例如,如下。

假设存在给定的一组呼叫,其中一些可能是虚拟呼叫。首先,呼叫的服务顺序由集中控制原理确定。然后,按该顺序模拟遍及呼叫电梯的路线。呼叫可以用节点表示。层站呼叫与单个起始节点对应,目的地呼叫与起始和目的地节点对应。令n=[n1,n2,...,nk]表示有序的节点集。呼叫n1的服务时间ti可以递归地计算为ti=ti-1+τi-1,i,其中,τi,j是从节点ni到节点nj的时间,即,从节点ni到节点nj的运行时间(flighttime)加上在节点ni处的停止时间。节点n0是电梯的当前位置,t0=0和τ01是电梯的当前位置和第一节点n1之间的飞行时间。

如果ni与现有或虚拟的层站呼叫对应,可以假设在服务层站呼叫ni时给出的一组虚拟轿厢呼叫被建模并且被添加到处于正确位置的路线。表1列出了不同呼叫类型和可以建模的项目的示例。

表1

一旦模拟结束,确定每次呼叫的服务时间。然后,可以使用目标函数来计算每个候选解决方案的适应值,即呼叫的分配。典型的目标函数是平均等待时间、平均行程时间或这两者的加权和。

在104处,基于乘客运输统计对预期呼叫(或“虚拟”呼叫)建模。令表示包含一天d的间隔k内每对楼层的乘客批次行程强度的矩阵。元素λijkd是从起始楼层i到目的地楼层j的行程强度。这里还假设批次行程根据泊松过程发生。此外,每对楼层的批次大小分布可以由矩阵定义。通过省略间隔和日指数,可以将到达从起始楼层i到目的地楼层j的下一对虚拟层站和轿厢呼叫或虚拟目的地呼叫的时间tij定义为:

其中,λij是根据泊松过程发生的从起始楼层i到目的地楼层j的以秒为单位的批次到达强度,γij是自从起始楼层i到目的地楼层j的上一次层站或目的地呼叫以来的时间。

因为λij是泊松过程的速率参数,1/λij是两次连续到达即两次连续呼叫之间的平均时间。那么,上面的等式意味着即使我们假设批次到达是根据泊松过程发生的,只有当自上一次呼叫以来的时间长于预定义的时间限制时,才假设该过程的健忘属性。可以利用例如模拟研究确定时间限制的合适的值。

当1/λij<γij,即,从起始楼层i到目的地楼层j有很多运输量,并且自上一次呼叫以来的时间长于平均到达间隔时间,则tij<0。在这种情况下,很自然地假设到下一次未来呼叫的时间将非常短,因此我们设tij=0。如果其中是预定义的时间范围,例如电梯周期时间,则产生从起始楼层i到目的地楼层j的、到达时间等于tcurrent+tij的一对虚拟层站和轿厢呼叫或虚拟目的地呼叫,其中tcurrent是例如计算新的分配决策的时刻。

每个起始楼层可能有几个目的地呼叫,因此,生成所有从起始楼层i到目的地楼层j的、使得的虚拟目的地呼叫。因为每次在起始楼层i上每个方向只能有一个层站呼叫,在朝同一方向的使得的所有虚拟层站和轿厢呼叫对中,可以选择到达时间最接近当前时间的虚拟层站和轿厢呼叫对。

令li表示该到达时间,即,

因此,在起始楼层i上的、朝由虚拟轿厢呼叫j定义的方向的、使得的下一个虚拟层站呼叫的到达时间是tcurrent+li。此外,例如,如果在起始楼层i处存在现有层站呼叫,则仅产生到目的地楼层j的使得的虚拟轿厢呼叫。

在106处,在计算后续分配决策时考虑至少一个建模的预期(或“虚拟”)呼叫。这提高了乘客的服务水平,因为电梯轿厢的分配变得更加优化。

图1b是示出用于计算电梯系统中的分配决策的方法的流程图。图1b中示出的实施例类似于图1a中所示的实施例,图1a已经示出了步骤100、102和104。

在108处,电梯中的负载基于历史乘客运输统计来建模。对于在图1a及其描述中更详细讨论的每个虚拟轿厢呼叫,乘客在一天d的间隔k内从起始楼层i行进到目的地楼层j的强度被估计为:

其中,ti是在楼层i上的层站呼叫的服务时间,并且ti在路线模拟期间被定义。e[yijkd]是与每次到达相关的乘客的预期数量,换句话说,是使用由矩阵定义的批次大小分布估计的预期批次大小,如前面已经说明的那样。λijkd是从起始楼层i到目的地楼层j的批次到达强度,即,被定义为的矩阵中的元素。

类似于对虚拟呼叫那样估计强度,如在图1a的描述中已经说明的那样。此外,如果有到服务现有或虚拟层站呼叫的楼层之前的楼层的现有轿厢或目的地呼叫,则也可以估计这对楼层的强度。原因是在层站呼叫楼层处登上电梯的乘客也可能正在前往由现有轿厢或目的地呼叫定义的楼层,而不仅是到由虚拟呼叫定义的楼层。

具有其起始和目的地楼层数量的估计强度可以存储在存储器中。对于电梯将实际服务的现有轿厢和目的地呼叫,只要它们不在目的地楼层被服务,就可以将强度保持在存储器中。对于虚拟轿厢和目的地呼叫,只要仍然可能减速到由强度定义的目的地楼层,就可以将强度保持在存储器中。估计强度的目的地楼层可以用节点表示。

当电梯路线的模拟结束时,估计强度的所有目的地节点通过以由路线定义的顺序迭代。在迭代过程中,可以使用两个规则将路线分成连续的电梯旅程。电梯旅程将结束于当前目的地节点,如果:

1、与下一个目的地节点相关联的强度的最小起始节点数(如果有的话)大于(小于)或等于当电梯运行方向为上升(下降)时到目前为止遇到的最大(最小)目的地节点数。

2、电梯在节点处改变其运行方向。

在一个实施例中,执行以下步骤:

1、在模拟由现有呼叫定义的路线期间,生成虚拟层站、轿厢和目的地呼叫,并且基于现有和虚拟轿厢和目的地呼叫的乘客批次行程统计来估计强度。

2、由强度定义的目的地节点通过以其服务顺序迭代,并且使用这两个规则将电梯路线划分为连续的电梯旅程。

在上述两个步骤之后,与每个电梯旅程相关的强度被用于定义电梯旅程的起始和目的地楼层。

在一个实施例中,接下来对每个电梯旅程单独估计电梯的负载,如下。

令xij表示从节点i到节点j的单个乘客到达的数量。假设到达是根据泊松过程发生的,xij遵循具有速率参数μij的泊松分布。在节点k停止后,电梯中的乘客数量不得超过电梯的容量。数学上这可以写作如下:

其中q是电梯容量,且p是在电梯旅程上的节点数量。

接下来,由于可能无法准确地知道xij,因此通过要求在节点k处停止之后超过电梯容量q的概率小于某个预定义的小概率α来考虑与它们相关的不确定性。假设xij是独立的,这可以表示如下:

其中上面的最终等式可以被认为是惩罚项,因为左手侧越小,电梯旅程期间不会超过电梯容量的可能性越大。单个电梯旅程的惩罚项可以写作如下:

其中β是比例因子,其值可以通过例如计算实验来确定。由此得出,整个路线的惩罚项是上述对各个电梯旅程的惩罚的总和。当被添加到所使用的目标函数时,整个路线的惩罚项可因此被使用。典型的目标函数是平均等待时间、平均行程时间或这两者的加权和。

在110处,在计算后续分配决策时考虑至少一个建模的预期(或“虚拟”)呼叫和建模的负载。然后,电梯群组控制能够基于乘客批次行程构建并使用历史乘客运输统计,以估计电梯在通过分配给它的呼叫的路线期间的负载,当计算分配决策时将该负载考虑在内,有助于提高乘客服务水平。

图2a和2b公开了示出在电梯系统中进行分配决策的示例。该示例假设目的地控制系统用于具有八个楼层以及两个电梯200和202的建筑物中。还假设其中一个电梯在最顶层楼层9处,另一个在最底层楼层1处。

另外,假设两个目的地呼叫,一个204从楼层8到楼层2,另一个206从楼层5到楼层1,大约在同一时间发生,并且基于最小化平均等待时间,第一个被分配给第一电梯200,第二个被分配给第二电梯202。接下来,假设在大约5秒后,当电梯200、202已经开始移动以服务目的地呼叫时,给出从楼层4到楼层6的新的目的地呼叫208。这已经在图2b中示出。

现在,从平均等待时间的角度来看,最佳分配是为第一电梯200重新分配从楼层5到楼层1的目的地呼叫,并将新的目的地呼叫208给第二电梯202。然而,通常这是不可能的,因为在目的地控制系统中,在给出呼叫之后立即向乘客发信号通知服务电梯。然而,如图1a的实施例中所示,当分配前两个呼叫时将新的目的地呼叫考虑为预测或虚拟目的地呼叫时,可以克服该问题。因此,在这种情况下,第一和第二目的地呼叫将首先被分配给第一电梯200,然后第二电梯202将服务后续的新的目的地呼叫208。

图3示出了用于计算电梯系统中的分配决策的电梯控制装置300的框图。装置300包括连接到至少一个存储器304的至少一个处理器302。至少一个存储器304可以包括至少一个计算机程序,当该至少一个计算机程序由处理器302或多个处理器执行时,使得装置300执行编程的功能。装置300还可以包括输入/输出端口和/或一个或多个物理连接器,其可以是以太网端口、通用串行总线(usb)端口、ieee1394(火线)端口和/或rs-232端口。图示的组件不是必需的或无所不包的,因为可以删除任何组件并且可以添加其他组件。

电梯控制装置300可以是被配置为仅实现上述公开的操作特征的电梯控制实体,或者它可以是较大的电梯控制实体例如群组控制器的一部分。

本发明的示例性实施例可以包括在任何合适的设备中,例如,包括能够执行示例性实施例的过程的服务器、工作站、个人计算机、便携式计算机。示例性实施例还可以存储与这里描述的各种过程有关的信息。

示例实施例可以在软件、硬件、应用逻辑或软件、硬件和应用逻辑的组合中实现。示例实施例可以存储与这里描述的各种方法有关的信息。该信息可以存储在一个或多个存储器中,例如硬盘、光盘、磁光盘、ram等。一个或多个数据库可以存储用于实现示例实施例的信息。可以使用包括在这里列出的一个或多个存储器或存储设备中的数据结构(例如,记录、表、阵列、字段、图形、树、列表等)来组织数据库。关于示例实施例描述的方法可以包括适当的数据结构,用于存储由一个或多个数据库中的示例实施例的设备和子系统的方法收集和/或生成的数据。

如计算机和/或软件领域的技术人员将理解的,可以使用根据示例实施例的教导编程的一个或多个通用处理器、微处理器、数字信号处理器、微控制器等方便地实现示例实施例的全部或一部分。如软件领域的技术人员将理解的,基于示例实施例的教导,普通技术的程序员可以容易地准备适当的软件。另外,如电气领域的技术人员将理解的,示例实施例可以通过准备专用集成电路或通过互连传统组件电路的适当网络来实现。因此,示例不限于硬件和/或软件的任何特定组合。存储在计算机可读介质中的任何一个或其组合上的示例可以包括用于控制示例实施例的组件的软件、用于驱动示例实施例的组件的软件、用于使示例实施例的组件能够与人类用户交互的软件等。这样的计算机可读介质还可以包括用于执行在实现示例实施例中执行的处理的全部或一部分(如果处理是分布式的)的计算机程序。示例的计算机代码设备可以包括任何合适的可解释或可执行代码机制,包括但不限于脚本、可解释程序、动态链接库(dll)、java类和小应用程序、完整的可执行程序等。

如上所述,示例实施例的组件可以包括用于保存根据教导编程的指令以及用于保持数据结构、表格、记录和/或这里描述的其他数据的计算机可读介质或存储器。在示例实施例中,应用逻辑、软件或指令集被保持在各种传统计算机可读介质中的任何一个上。在本文件的上下文中,“计算机可读介质”可以是能够包含、存储、通信、传播或传输指令以供指令执行系统、装置或设备例如计算机使用或与指令执行系统、装置或设备例如计算机结合使用的任何介质或工具。计算机可读介质可以包括计算机可读存储介质,该计算机可读存储介质可以是能够包含或存储指令以供指令执行系统、装置或设备例如计算机使用或与指令执行系统、装置或设备例如计算机结合使用的任意介质或工具。计算机可读介质可以包括参与向处理器提供指令以供执行的任何合适的介质。这种介质可以采用许多形式,包括但不限于非易失性介质、易失性介质、传输介质等。

虽然已经示出并描述并指出了应用于其优选实施例的基本新颖特征,但是应当理解的是,在不偏离本公开的精神的情况下,本领域技术人员可以对所描述的设备和方法的形式和细节进行各种省略和替换以及改变。例如,明确表明以基本相同的方式执行基本相同的功能以实现相同结果的那些元件和/或方法步骤的所有组合都在本公开的范围内。此外,应该认识到,结合任何公开的形式或实施例示出和/或描述的结构和/或元件和/或方法步骤可以作为设计选择的一般事项并入任何其他公开或描述或建议的形式或实施例中。选择。此外,在权利要求中,装置加功能条款旨在涵盖这里描述的执行所列举的功能的结构,并且不仅包括结构等效物,还包括等效结构。

申请人特此单独公开这里描述的每个单独的特征以及两个或更多这样的特征的任何组合,使得这些特征或组合能够按照本领域技术人员的公知常识基于本说明书作为一个整体来实施,而不管这些特征或特征的组合是否解决了这里公开的任何问题,并且不限于权利要求的范围。申请人指出,所公开的方面/实施例可以包括任何这样的单独的特征或特征的组合。鉴于上述描述,对于本领域技术人员来说显而易见的是,可以在本公开的范围内进行各种修改。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1