简介一份基于Java的摩天大楼电梯系统仿真项目源码包面向Java学习者、算法爱好者及建筑智能化开发者。项目覆盖单向、双向、观光、高速、消防等电梯类型并实现先来先服务、最近楼层优先、最少行程时间、预调度及群控等调度算法通过随机流量生成器模拟乘客呼叫适合用于理解电梯调度策略与面向对象建模过程。资源共75个文件以25份Java源码为核心另有13份xml配置、10份prefs工程状态记录及少量txt、md说明压缩包仅70KB结构紧凑便于快速导入与分析。目前已有402人学习下载。借助Elevator、Call、TrafficGenerator、Main等关键类可掌握模拟流量生成、呼叫请求封装、多电梯协同调度及运行状态管理的完整实现思路为大型建筑电梯系统设计提供可扩展的参考原型。1. ElevatorSimulation 到底在仿真什么把电梯选型这件事从估算变成实验摩天大楼电梯类型及算法仿真本质上是在做一件事把一栋 300 米以上高楼的垂直交通方案搬进离散事件仿真环境用虚拟乘客去压测电梯的配置与调度策略。我在参与某超高层项目的前期测算时最直观的感受是——电梯占用的核心筒面积、台数和调度算法直接决定大楼可用层率这不能用「经验系数 × 建筑面积」拍脑袋。仿真能回答的问题是分区设到多少层最省电梯双层轿厢比单轿厢多处理多少人目的层控制到底值不值它适合正在做超高层机电方案的工程师、研究垂直交通的团队以及想给电梯群控做算法仿真的开发者。2. 电梯类型拆解单轿厢、双层轿厢、双轿厢与分区策略怎么选2.1 单轿厢 分区摩天大楼的默认答案摩天大楼里最常见的配置不是「一堆单轿厢随便跑」而是把大楼在竖向上切成若干分区每个分区配独立的一组单轿厢电梯。比如 60 层的办公楼低区服务 1-20 层中区服务 21-40 层高区服务 41-60 层高区乘客从首层坐直达电梯或中途不停站的快速梯到分区转换层再换区内电梯。这样做的目的是压缩单次行程时间如果所有电梯都从一楼直达顶层轿厢在低区就满载了高区乘客要么等很久要么上不去。分区数量取决于两个约束核心筒放得下几组井道以及每组电梯的 5 分钟处理能力是否达标。我一般先按 6-10 层一个分区高度去试再把分区高度折算成井道面积和电梯台数分区过高会导致中间梯浪费时间过低会导致电梯组数爆炸。对于 400 米以上大楼常见的做法是引入空中大堂用大容量穿梭梯把客流先送到转换层再分散到各个分区这是比单纯分区更省井道的方案。单轿厢电梯的建模最简单一个井道、一个轿厢、一组上下按钮。仿真里它是最容易做对的基线所有算法对比都应该先拿这个配置跑通。单轿厢分区方案的选型要点分区高度8-12 个服务层比较常见具体按客流量调整电梯速度分区越长速度要求越高高区常用 6 m/s 以上停靠方式区内电梯可设单双层停靠进一步分流2.2 双层轿厢与双轿厢同一井道的两个思路双层轿厢是「一个轿厢壳里上下两层」每次停靠同时服务两层楼的人适合早高峰首层客流爆炸的场景。它的关键问题是乘客在首层要按目标楼层是奇数还是偶数选择进入哪一层仿真里必须给乘客生成对应的「轿厢层选择」属性否则会出现上层空载下层爆满的失真结果。双轿厢则是「同一井道里两个独立轿厢上下运行」两个轿厢各带各的目的楼层之间只保持最小安全间距。它比双层轿厢灵活因为不需要乘客按奇偶分流两个轿厢可以分别响应不同方向的请求。但调度复杂度翻倍两个轿厢在同一井道里追尾的风险决定了调度器必须持续做防碰撞检查比赛道里的车还难管。下面这张对比表是我做仿真前会先填好的用来判断当前项目到底该往哪个方向建模类型单井道效率乘客分流要求调度复杂度典型适用单轿厢1 部/井道无低中高层办公、住宅双层轿厢2 层/次停靠奇偶楼层中超大客流办公、枢纽双轿厢2 部/井道无但需防碰撞高高密度超高层空中大堂穿梭梯多区共享按分区/目的地中高400m 以上超高层选型不能只看「能装多少人」。我吃过一次亏某模拟项目X里为了追求 5 分钟处理能力直接换成双层轿厢结果仿真里等待时间确实下降了但轿厢内拥挤度和中间楼层停站次数暴涨因为偶数层客流被强行导进上层轿厢行程时间变长。后来我把「乘客对轿厢层可接受度」设成参数才让结果回到合理区间。2.3 类型选型到底在选什么核心筒面积、处理能力与成本电梯类型选型本质上是在三个指标之间做权衡核心筒面积占比、早高峰 5 分钟处理能力、以及系统造价。核心筒占楼面面积的比例每增加 1%可出租面积就少一大块对超高层来说这是每年千万级的租金差异。所以「多装几部电梯」从来不是第一选择优化调度和选择高载客电梯类型才是。5 分钟处理能力HC5是超高层垂直交通的核心指标表示早高峰 5 分钟内电梯系统能运走的总人数占该时段需求人数的比例。办公楼的常见目标是 12%-15%这直接由电梯台数、容量、速度和调度效率共同决定。仿真里我会把 HC5 当作硬性验收指标把平均候梯时间AWT当作体验指标两个都达标才算方案过关。值得注意的成本项还包括电梯的数量会增加井道、机房、导轨和控制系统造价而空中大堂要占用两层楼的建筑空间换取穿梭梯的效率。所有这些成本差异都应该在仿真里用「减少一台电梯 vs 增加一个分区」这样的对比试验来量化。仿真跑出来的不是一个绝对值而是多个方案之间的相对收益——这个相对收益才是给决策层看的东西。3. 客流与参数建模让仿真里的人流像早高峰一样真实好的算法离不开真实的输入。切忌用均匀到达的随机客流测试调度算法——很多看起来很好用的调度策略在均匀客流下「全员优秀」一到早高峰就现出原形。客流建模的粒度直接决定仿真结果可不可信。3.1 客流模型泊松到达不够用早高峰要分时变强度低密度时段午间、下午乘客到达可以近似为固定到达率 λ 的泊松过程相邻两位乘客的到达间隔服从指数分布。早高峰完全不同大量人员在 8:20-9:00 之间集中到达首层到达率是随时间变化的函数 λ(t)。我会把它建模成分段函数峰值时段到达率取平峰时段的 4-8 倍。乘客的目的楼层也不是均匀的。高层办公楼的典型分布是低区和中区占大比例、顶层和次顶层占小比例可以用幂律或分段比例来近似。仿真开始前我会生成一张「楼层-人数占比表」先统计每层办公人数再按人数占比生成目的地。这一步不能省否则高区电梯的负载会被严重低估。一个基本的早高峰客流生成逻辑可以这样表达def generate_morning_crowd(floors, pop_per_floor, peak_rate, start, peak): # floors: 楼层编号列表; pop_per_floor: 各楼层人数 # peak_rate: 峰值到达率(人/s); peak: 峰值时刻(秒) t start while t start 3600: if t peak: lam peak_rate * (0.2 0.8 * (t - start) / (peak - start)) else: lam peak_rate * max(0.1, 1.0 - (t - peak) / 1800) interval random.expovariate(lam) # 指数间隔 t interval dst weighted_choice(floors, pop_per_floor) passengers.append(Passenger(src0, dstdst, arrivalt))逻辑说明这段代码用一个随时间变化的 λ(t) 控制早高峰客流密度峰前线性爬升、峰后快速衰减符合我对多数办公楼的实测感受。到达间隔用指数分布生成乘客目的楼层按各层人数加权随机抽取。参数说明里有两个点很容易调错一是peak_rate的单位是「人/秒」不是「人/小时」写仿真框架时先换算二是pop_per_floor要和实际楼层人数成正比而不是和楼层序号成正比我曾经把高区人数设得和低区一样大导致高区电梯排队仿真失真。3.2 仿真参数清单速度、加速度、开关门时间怎么设电梯运动学参数是仿真的「物理层」这里的每一个数字都会直接作用到等待时间和行程时间。我常用的初始参数如下表参数典型值说明层高3.9 m影响平层位移计算额定速度4-10 m/s分区越高越快加速度1.0-1.5 m/s²高速梯建议取小值减少眩晕感加加速度jerk1.0-1.8 m/s³决定 S 型速度曲线开关门时间2.5-4.0 s含门完全打开/关闭乘客进出时间0.8-2.0 s/人高峰取大值轿厢容量1200-2300 kg按 75 kg/人折算加减速模型是新手最容易翻车的地方很多初版仿真用「全程匀加速到匀速」加速度跳变会让电梯运行时间比真实情况少 15% 以上。真实电梯采用 S 型速度曲线加速度变化率jerk有限制行程计算要分段加速段、匀速段、减速段。高层直驶工况下匀速段占比高误差还小但低速区频繁起停时S 型曲线和非 S 型曲线的时间差会非常明显。开关门时间还有个静态细节要注意门宽不同、厅门联动方式不同实际值会差不少。我一般把开关门时间拆成「开门 保持 关门」三段仿真里每段独立计时这样便于后面模拟故障和超时重开门比如有人挡门。3.3 分区策略参数化把「高区/中区/低区」变成可调参数分区策略在仿真里不应该写死在代码里而应该是一组参数分区数、每个分区的起始楼层和结束楼层、每区配几台电梯、是否设直达转换层。我用一个字典结构来承载这些配置方便在做对比实验时只改参数不动逻辑。zones [ {name: low, floor_range: (1, 15), cars: 4, express: False}, {name: mid, floor_range: (16, 30), cars: 4, express: True, sky_lobby: 15}, {name: high, floor_range: (31, 48), cars: 4, express: True, sky_lobby: 30}, ]这种做法的好处是当我需要试验「低区 15 层变成 18 层」时只改floor_range的结束值乘客分组和电梯指派逻辑完全复用。分区策略里还有两个隐性参数一是「跨区请求」是否允许——比如低区的人要上高区是让他坐穿梭梯还是允许区梯越区直达二是「空中大堂转换层」的候梯时间惩罚——人流在中转层二次候梯会显著影响总行程时间。仿真里我会给空中大堂的二次候梯单独加一个参数默认 20-40 秒很多估算模型不计算这一段实际乘坐体验的误差就出在这里。分区参数化以后选型对比就从「拍脑袋定分区」变成了「参数扫描找最优」。4. 调度算法在仿真里落地从 SCAN 到目的层分配有电梯类型和客流参数之后真正让仿真活起来的是调度器。调度器决定每个电梯在什么时刻响应什么请求。我建议从最简单的 SCAN 算法写起先跑通闭环再逐步升级到目的层控制。4.1 先跑通一个时间步进仿真骨架离散时间仿真是最容易理解的落地方式每个仿真步长0.1 秒或 0.25 秒更新一次所有电梯的位置、速度和乘客状态。楼层的位置我用连续浮点数表示比如电梯停在 10.0 表示平层在 10 层10.5 表示正在 10 层至 11 层途中。class Elevator: def __init__(self, capacity20, speed6.0, acc1.2): self.pos 0.0 # 当前位置(连续楼层), 1.0 表示平层在1楼 self.v 0.0 # 当前速度 m/s self.dir 0 # -1下行 / 0静止 / 1上行 self.passengers [] # 已上梯乘客 self.stops set() # 计划停靠的楼层(集合) self.door_open 0.0 # 开门计时 def distance_to(self, floor): return abs(floor - self.pos) * FLOOR_HEIGHT # 折算成米逻辑说明我用一个集合stops来记录计划停靠的楼层避免重复停同一层。distance_to将楼层层差折算成真实距离供调度器估算到达时间。参数说明capacity用人数kg 载重除以 75 折算比如 1500 kg 对应 20 人speed单位是 m/spos是连续楼层仿真里平层判断要比较的是距离而不是楼层整数本身。dir 0表示空闲状态后续调度里会把空闲电梯视为可被立即分配的对象。4.2 在仿真里实现 SCAN 调度与沿路响应SCAN 的核心思想是电梯沿一个方向持续运行响应沿途顺路请求到达该方向最远请求后再反向。它跟简化版 LOOK 的区别在于最远请求层的处理——LOOK 会直接掉头SCAN 在仿真里一般也按 LOOK 实现因为实际电梯不会真的跑到井道顶端。这里我直接用 LOOK 的常见实现方式。def look_schedule(car, calls): # calls: set of (floor, dir), 未分配的外部呼叫 # 1. 取同向且在前方的请求 forward [f for (f, d) in calls if (car.dir 0 and f car.pos) or (car.dir -1 and f car.pos)] if forward: farthest max(forward) if car.dir 0 else min(forward) car.stops.update({f for f in forward if f farthest}) car.dir 1 if car.dir 0 else -1 else: # 没有同向请求, 反转方向 car.dir 0 if not calls else (1 if next(iter(calls))[0] car.pos else -1)参数说明car.dir 0把静止状态0视为上行这样在无历史方向时优先向首层方向服务forward的过滤条件是关键——它必须同时兼容上行和下行所以代码里对上行和下行分别判断f car.pos和f car.pos。这里最容易写错的是方向判断忘了把dir 0的场景折进上行导致空闲电梯永远不响应请求。沿路响应的细节是电梯不能只在目标楼层停靠还要在运行途中检查是否有中间的顺路请求。这个逻辑我习惯放在每次位置更新的时刻判断而不是在排程时就一次性全部决定。def update_position(car, dt): # 判断是否到达下一停靠层 if car.stops: target min(car.stops) if car.dir 0 else max(car.stops) dist_to_target abs(target - car.pos) * FLOOR_HEIGHT if dist_to_target car.v * dt: car.pos target car.stops.remove(target) car.v 0.0 car.dir 0 else: car.pos car.pos car.dir * car.speed * dt / FLOOR_HEIGHT这段update_position是每个仿真步长都要调用的它处理「到达停靠层后停车」和「继续运行」两个分支。注意target的选取也是方向相关的下行时取min(stops)是错误的应该取当前下方最近的停靠层。这个 bug 我只在跑了十几个场景之后才定位出来表现是电梯总是先跑到最下边再往上运人。4.3 目的层控制从「上下按钮」到「按目的地排程」目的层控制系统DDC改变了乘客交互方式乘客在大厅终端输入目的楼层系统实时把乘客分配给最合适的一台电梯而不是按上下按钮让电梯盲扫。这种做法的收益在于系统知道每个乘客的目的地可以提前规划停站序列减少无效停靠。仿真里实现 DDC 的核心是一个「分配函数」对每个新请求计算各电梯的预估到达时间ETA选最小的电梯响应def assign_to_elevator(elevators, car_call, passenger): # car_call: (src_floor, dst_floor) # 返回被指派的电梯对象 best_elev, best_score None, float(inf) for ev in elevators: if len(ev.passengers) ev.capacity: continue eta_to_src ev.distance_to(car_call[0]) / max(ev.speed, 0.1) ride_time abs(car_call[1] - car_call[0]) / max(ev.speed, 0.1) score eta_to_src ride_time penalty(ev, car_call) if score best_score: best_score score best_elev ev if best_elev: best_elev.stops.add(car_call[0]) best_elev.stops.add(car_call[1]) return best_elev逻辑说明这段代码的评分函数是「电梯赶到乘客所在层的时间 乘客的预计乘坐时间 惩罚项」之和。penalty函数是关键我一般给它加两个约束一是若电梯当前运行方向与乘客需求方向相反加 30 秒惩罚避免把乘客塞进反向的电梯二是若停站数超过某个阈值比如 4 站额外加惩罚防止电梯变成「站站停」的慢车。DDC 的坑在于分配是一次性的分配完以后乘客不能反悔。真实系统里有「重新分配」机制当乘客等得太久系统可以撤销原分配并换一台电梯。仿真里我会用「最大等待时间」参数触发重新分配默认 90 秒超过就把该请求重新投入分配池。这个机制让 DDC 在极端拥挤场景下不会彻底锁死。5. 避坑仿真跑完都说好一上线就翻车的五个常见原因仿真结果和真实运营差异最大的五个地方我逐个踩过按「现象 → 原因 → 解决」列出来给后来者省点时间。5.1 平均等待时间比实测低 40%乘客进出时间取太小现象仿真报告平均候梯时间 22 秒某图像处理Demo项目上线后实测 34 秒。原因轿厢乘客进出时间设成 0.8 秒/人这是理想状态下无拥挤、无行李的值。早高峰轿厢里人挤人进出速度会显著下降尤其是一层多人同时下梯时后段的人会被前排堵住。解决按客流密度把进出时间建模成动态值。我常用的分段是轿厢载客率 0-50% 时取 0.8 秒/人50-80% 时取 1.2 秒/人80% 以上取 1.6-1.8 秒/人且每个停靠层最多允许 6-8 人同时上下剩余乘客排队依次进出。这个改动之后仿真等待时间普遍上浮 20%-30%反而更接近真实运营数据。5.2 电梯数量增加等待时间反而变差现象某个 42 层办公楼的对比实验里从 4 台电梯加到 6 台平均等待时间反而变长了 3 秒。原因单纯增加电梯而不调整分区和指派策略会导致多出的电梯在低负载时段空跑如果这些电梯和高负载电梯走同一个分区还会分散原有电梯的运力让原本集中运力快速清场变成了多台电梯都跑不满。解决把新增电梯放到高负载分区或者让它跨区支援。仿真里我常做一个「支援策略」当某分区候梯人数超过阈值比如 30 人相邻分区空闲电梯可以申请跨区协助。这个逻辑要放在调度器里做全局判断不能只靠局部规则。5.3 双层轿厢上层长期空载现象仿真跑 30 分钟早高峰双层轿厢的上层轿厢载客率只有下层的一半不到处理能力完全没体现出来。原因乘客的目的楼层分布没有做奇偶分流。双层轿厢的停靠规则决定了偶数层请求应由上层轿厢响应、奇数层由下层响应如果生成客流时没有把「偶数层乘客 → 上层」的映射关系写进乘客属性分配器就会把乘客都塞给下层。解决在乘客生成阶段就给每个乘客增加deck0/1属性甚至在首层大厅配置对应的引导区域。仿真里还要额外加一个「走错层」的小概率参数5% 左右因为现实里总有乘客走错轿厢层。5.4 单次仿真结果波动大同一个配置跑两次结论相反现象同一套参数连续跑两次一次显示 A 方案好一次显示 B 方案好整个对比实验没法下结论。原因没有固定随机种子。早高峰客流是随机生成的如果两次实验用的随机序列完全不同结果差异会被放大到掩盖方案之间的真实差距。解决所有对比实验固定同一个随机种子比如random.seed(20240)并且每组配置至少跑 20-30 个不同种子输出多次运行的平均值、最小值和 90 分位。这样再下结论时至少能说「在 30 个随机场景下 A 方案平均等待时间比 B 短 3 秒」。5.5 电梯加减速模型太理想运行时间对不上电梯实测现象仿真里电梯从 1 层到 30 层运行时间比电梯厂商给定值少 2 秒累计一天下来感觉系统「太快了」。原因用恒加速度模型替代了真实的 S 型速度曲线。恒加速度曲线的加速时间是速度/加速度而真实电梯为了舒适性会把加速度从 0 逐渐提升前半程的加速度达不到额定值导致加速段更长。解决在运动学模型里加上 jerk 参数。简化的梯形速度曲线分为三个阶段加速度线性爬升到额定值 → 匀速 → 减速复杂一点可以用完整的 S 曲线。我在仿真里用「jerk 1.5 m/s³」的梯形模型已经能把单程时间误差控制在 0.3 秒以内。6. 验证与调优先证明仿真可信再谈优化方向仿真最后一步是验证这一步不能省。第一层验证是手工场景测试安排 1 个人从 1 楼到 40 楼检查电梯行程时间是否等于「加速时间 匀速时间 减速时间 开关门时间」的累加。如果误差超过 1%先查运动学模型。第二层验证是客流一致性仿真结束统计「生成乘客数 到达乘客数 完成服务乘客数」的等式是否成立丢人是最常见的事故。我在调某跨平台系统时就用这个检查揪出过两个乘客在同一楼层上了两趟电梯的 bug。第三层验证是同基线对比把新方案和「单轿厢 SCAN 调度 固定分区」的基线配置做同随机种子对比只改一个变量。改两个变量以上得出的结论就无法归因这类实验等于白做。早期我犯过同时改分区和调度算法、结果波动到完全无法判断哪个变量起作用的错误后来都改成一次只动一个旋钮。最后是调优方向的选择顺序。先调分区低区/中区/高区的边界把各分区的 5 分钟处理能力拉平再调类型比如双轿厢 vs 双层轿厢最后才调调度算法参数。因为这个顺序的成本投入是递增的改分区只需要改几个楼层编号改轿厢类型涉及乘客属性和停站逻辑改调度算法则要重新验证整套闭环的稳定性。我自己的习惯是每轮对比实验都留一张表方案名、随机种子集合、平均候梯时间、最坏等待时间、5 分钟处理能力、核心筒面积预估。决策者要的不是「哪个最快」而是「哪个又快又省井道」所以把面积放进对比表里讨论起来会容易很多。毕竟电梯仿真的最终价值不是仿真本身而是帮我们把一个上千万的选型决策从「拍脑袋」变成「有据可查」。希望帮到你。本文还有配套的精品资源点击获取
