电梯调度算法迭代实战：从指标设计到多梯协同优化

电梯调度这个词听起来像是上世纪就研究透了的经典问题但真当我自己动手做一轮完整的迭代分析时才发现这里面的坑远比想象中多。早高峰写字楼、装配工厂的随机呼叫、医院病房楼的按压需求……每个场景对调度逻辑的要求都不一样指望一个策略通吃所有环境基本等于抽奖。这篇文章把我自己的那轮电梯调度迭代过程完整摊开基线怎么搭、指标怎么选、调度算法从单梯到多梯协作是怎么一步步调整的以及哪些调整收益最大又有哪些参数折腾死人却不涨效果。数据全部来自我自己跑的离散事件仿真和一段真实台账的回放验证不是教科书的空中楼阁。如果你正在学调度算法或者想用“迭代优化”的思路解决身边类似的问题这篇内容可以当一份操作手册来读。1. 电梯调度到底在优化什么为什么不能凭感觉调1.1 表面是写算法背后是系统权衡一个人站在电梯口按一下按钮电梯来了他进去到达目的层。这个动作看起来简单但背后是一个典型的“共享多资源排队调度”问题电梯是有限资源请求者分布在不同的楼层请求方向和目的层各不相同。电梯调度优化的本质是在多个互相冲突的目标之间做权衡。最常见的三组矛盾是平均等待时间与最大等待时间的矛盾。只压平均等待可能出现个别乘客在顶层等了三分钟没人管而整体统计很好看。运行效率与能耗的矛盾。电梯频繁响应所有请求会带来大量加减速和重复启停长时间累计的机械损耗和电费明显上升。乘客体验与系统复杂度的矛盾。复杂策略理论上更优但一旦电梯数量多、楼层高策略本身的不确定性会让乘客摸不清规律制造新的焦虑感。我自己做迭代分析最深的一点感受是如果你不知道自己在优化什么那么优化的过程就会变成盲目试探。开始之前先把目标函数定清楚后续所有迭代方向才有锚点。1.2 核心性能指标先定度量再谈优化迭代分析的第一步不是换算法而是把评价指标梳理出来。我常用下面这张表来框定效果指标缩写说明常用观察值平均等待时间AWT乘客发出呼叫到电梯开门接自己的平均耗时写