西门子杯三部十层电梯这是很多参加过智能制造挑战赛的同学绕不开的一道坎。表面上看题目要求的是用一个PLC控制三部十层电梯但真正做进去才会发现这题的难点根本不在单台电梯的逻辑而在于多轿厢协同调度。三个人同时按外呼到底派谁去轿厢在十层一层有人在等二层也有人按了是顺路捎上还是各派各的这些才是拿高分和拿低分的分水岭。这篇内容我会按自己当时备赛的完整思路来梳理先拆解赛题逻辑再讲信号规划然后落到单梯控制和群控调度算法最后聊仿真调试和踩坑记录。无论是准备校赛、省赛还是国赛这套框架都能直接套用。1. 赛题逻辑与整体设计思路1.1 这题到底在考什么先说结论西门子杯三部十层电梯程序核心考核点是“多轿厢群控调度”而不是简单的单台电梯逻辑。很多第一次参赛的人容易陷入一个误区一上来就把所有精力放在单台电梯的开关门、平层、上下行这些基础逻辑上等写完了才发现三台电梯各自运行完全没有协作外呼信号来了一窝蜂全往目标楼层跑不仅效率低评委一眼就能看出没有调度策略。用大白话来说单台电梯的程序就像一个人自己出门买菜路线自己定、门自己开怎么走都行。但三部电梯放在一起就像一个小型出租车队乘客在楼下招手你不能三辆车全停过去得有一个调度中心决定让谁去接。群控算法就是这个调度中心的大脑它决定了系统整体效率的天花板。赛题通常给到的场景包含三个轿厢和十层楼每层都有上下行外呼按钮顶层只有下行、底层只有上行轿厢内部有十层内呼按钮还有一些开关门、检修、消防等外围信号。系统的评价指标一般围绕三个维度来打平均候梯时间、长时间候梯次数一般超过60秒算一次长候梯、以及整体运行能耗。高分的程序一定是在这三者之间找到了平衡点。1.2 为什么群控比单梯难写一个量级单梯程序本质是一个有限状态机状态无非是空闲、上行、下行、开关门、故障外加一套方向优先级的判断逻辑哪怕是十层楼几百行梯形图或SCL就能搞定。但三部电梯的难度在于原本“唯一的轿厢”变成了“三个可选项”所有判断都要从单线程变成多线程协同。举个例子一层有人按下行外呼A梯在一层附近、B梯在三层向下运行、C梯在八层正在上行。从距离上看A梯应该去但A梯可能刚开门正在上下客B梯三秒后就能到一层C梯虽然远但可以顺路接到一个去五层的乘客再转下来。这种情况没有一个“标准答案”拼的就是谁对场景的建模更细致、对优先级的定义更合理。另外一个容易忽略的点是“信号所有权”问题。外呼信号是所有电梯共享的但只能有一个轿厢去响应。你在程序里必须设计一套机制决定某层某个方向的外呼信号归属于哪个轿厢而且一旦分配出去其他轿厢就不能再被这个信号触发。这个逻辑写不好就会出现两部电梯同时开门抢人的场面在仿真评分里会被直接判定为调度异常。所以整体设计思路我建议走“分层解耦”的路线底层是单梯的状态机负责把每一部电梯的完整运行流程跑顺中层是外呼信号的登记和分配器负责把共享外呼信号按规则分配给具体轿厢上层是调度仲裁器负责在多个可响应的轿厢之间做决策。三层之间用变量接口连接调试的时候可以单独测试每一层出问题也好定位。2. 核心信号梳理与输入输出规划2.1 信号清单与地址规划做电梯控制第一件事不是写逻辑而是把I/O点全部理清楚。西门子杯电梯赛项用的仿真环境一般是EETElevator Simulation Tool它内置了完整的三部十层电梯模型通过共享变量和PLC通信。信号量看起来多其实归类之后也就五类我按自己的习惯整理了一份清单。第一类是外呼信号十层楼每层有上行和下行按钮具体点数是9个上行1-9层9个下行2-10层共18个数字量输入。第二类是内呼信号每个轿厢10个楼层按钮三部电梯共30个。第三类是轿厢状态反馈信号包括当前楼层、运行方向、平层信号、门区信号、开门到位、关门到位、超载、检修等。第四类是控制输出信号包括上行接触器、下行接触器、开门继电器、关门继电器。第五类是特殊信号包括消防返回、司机模式、锁梯等根据赛题要求选做。这里面最容易踩坑的是地址规划。外呼信号可以按“楼层方向”来命名比如UP_1表示一层上行DN_10表示十层下行虽然十层只有下行但建议统一预留位。三部电梯的内呼信号建议用“轿厢号楼层号”命名比如CAR1_F3表示1号梯的三层内呼。如果你在15个CPU版本里用那种自动分配的随机地址调试到后期一定会被自己坑到。我见过有人用M0.0到M19.7把所有外呼信号全塞进去最后看程序跟看密码本一样根本没法查。2.2 EET仿真环境的信号特点EET跑的是仿真模型信号映射和真实电梯有区别。它通过PLCSIM或真实PLC的通信接口交换变量电梯模型本身会模拟运行时间、开关门时间、乘客进出时间。这意味着你的程序不能像写干接点逻辑那样只关心“有没有信号”还得考虑时序配合。比如EET里轿厢到达目标楼层后模型会给出平层和门区信号你需要在收到平层信号后才能发开门指令不能提前开。门没关好就发运行指令仿真模型也会触发异常报警。刚开始调试的时候最容易遇到的怪现象就是逻辑上明明已经到了楼层但电梯就是不动作大概率就是门区或平层信号的时序没配合上。再比如外呼信号的取消方式EET模型不会自动帮你清掉已响应的外呼按钮灯你需要在自己程序里做“响应完成”逻辑把对应的外呼登记解除。有些同学没做这一层就会出现电梯到了楼层外呼灯还亮着被判定为响应失效。2.3 方向优先级与信号登记策略电梯控制里有个基本概念叫“顺向截梯”——电梯在上行途中只响应上行方向的外呼或者响应与当前运行方向一致的内呼。这个逻辑虽然基础但在外呼信号分配给多个轿厢时它的优先级要结合调度算法来定。我的实现思路是每个轿厢内部维护三张登记表——内呼登记表、上行外呼登记表、下行外呼登记表。外呼信号到来时先经群控仲裁逻辑决定归属哪个轿厢然后写入对应轿厢的外呼登记表。单梯在每一层停靠时判断条件是本层有“与当前方向一致”的登记信号或者本层是换向点、有反向登记信号。这里有一个细节很多教程不会讲电梯在空闲状态下默认的待命方向是什么如果电梯停在五层此时四层有人按上行、七层有人按下行两部梯都空闲那么谁去四层谁去七层如果只按“距离最近”分配四层和七层一样近都差一层就需要一个静态优先级参数来打破平衡比如“上行外呼优先分配给编号小的轿厢”“下行外呼优先分配给编号大的轿厢”。这个参数没有绝对的最佳值但要让评分时表现稳定建议在仿真中反复调。3. 单梯控制状态机与核心逻辑实现3.1 单梯状态的五段式划分单梯程序是整个系统的地基地基不稳调度算法写得再漂亮也没用。我把单梯运行流程切成五个状态空闲待命、响应运行、平层停靠、开关门、故障/检修。空闲待命轿厢无任何任务停在某一层门关闭。响应运行轿厢有目标楼层正在上行或下行。平层停靠轿厢到达目标楼层触发平层信号准备开门。开关门执行开门延时、关门检测、超时重关等动作。故障/检修消防、超载、检修开关激活时停运或转入特殊模式。这个五段式状态机用SCL编写最直观用梯形图写也可以但状态多了之后梯形图的触点组会非常臃肿。我建议至少把状态切换逻辑用SCL的CASE语句来写每个状态一个分支读起来和改起来都舒服很多。3.2 一次完整服务周期的时序拆解以“1号梯从五层响应一层上行外呼”为例完整时序应该是这样的群控仲裁分配一层上行外呼给1号梯1号梯的UP_1登记位置1。1号梯当前处于空闲状态检测到UP_1登记判定无反向任务启动下行。轿厢从五层下行逐层经过四层、三层、二层每层都判断是否有顺向停靠需求本例无。到达一层平层信号置位停止运行。开门继电器动作开门到位信号返回进入开门保持延时一般3-5秒。延时结束关门继电器动作关门到位信号返回轿厢进入空闲待命。将UP_1登记清零完成本次服务。这个流程看起来简单但每一步都有对应的信号锁存和定时器。特别容易出问题的是第4步平层信号的触发条件。你在写判断时要同时确认“当前楼层目标楼层”和“平层信号1”两个条件缺一不可否则轿厢可能在运行过程中经过目标层时误停或者到了目标层却因为平层信号没建立而冲过层。3.3 方向选定与换向逻辑方向判定是单梯逻辑里最容易写魔怔的部分。核心规则只有一条只要当前方向还有未响应的同向登记信号就保持方向不变只有在同向无信号、但反向有信号的情况下才允许换向。举个例子轿厢正在上行五层和七层都有上行外呼属于它那么它必须依次停靠五层、七层哪怕它在四层时接到了八层的内呼也不能先掉头。只有在所有上行登记包括内呼和顺向外呼全部清空后发现二楼有一个下行外呼等着它才会换向下行。这里有个容易忽略的边界十层楼的最顶层是一层、最底层是十层换向判断不仅依赖“有无反向信号”还要看“是否到了终点层”。如果轿厢已经到了顶层就算上行方向还有信号那也是无效信号不存在超过十层的楼层强制换向。所以换向逻辑一定要加上“当前楼层等于边界层”的硬性条件。3.4 开关门时序与超时保护开关门这块我记得第一次调试时被一个“假死”问题折磨了一晚上轿厢停靠后一直不开门程序里看登记信号是有的、平层信号也是有的但就是卡住不动。后来排查发现是门区信号保持时间太短程序扫描周期错过了它。EET仿真里轿厢平层后门区信号持续的时间有限如果PLC的扫描周期较长或者程序里用了带延时的判断就可能漏掉这个信号。解决办法是把这个信号做锁存一旦检测到门区信号就把它置位到一个内部保持位直到开门到位信号返回后再复位。这属于典型的“信号边沿捕捉”问题在写所有脉冲类信号时都要注意。另外一定要加开门超时保护。正常情况下开门延时结束就自动关门但如果有人在门口挡着仿真里表现为光幕或门阻力信号持续关门动作做了三次都失败程序就应该停止反复关门转为超时报警并且把轿厢锁定在驻停状态。如果不加这个保护仿真系统会判定为长时间门未关扣分很狠。4. 三梯群控调度算法的设计与实现4.1 常见调度策略对比群控调度算法有很多种从简单的到复杂的大致可以归为四类静态分区调度把十层楼按区域划分比如1-4层归1号梯、5-7层归2号梯、8-10层归3号梯。实现最简单但客流不均匀时效率很差比如高峰期所有人都从一层上车1号梯累死其他梯闲死。最近距离优先外呼信号来临时计算每个空闲轿厢到目标层的距离派最近的那个去。优势是响应快缺点是容易造成多个轿厢扎堆在同一区域。统一调度串联响应系统把各层外呼信号按楼层排序由一个专门的分配算法动态分配给最合适的轿厢考虑顺路捎带和负载平衡。这是赛题拿奖的主流方案。智能算法调度用模糊控制、遗传算法、专家系统等做预测性调度。听起来很高级但在PLC上实现复杂而且评估函数的参数要靠大量仿真数据调优时间成本高。我个人建议优先把第三种做到位性价比最高。4.2 统一调度模式的分配逻辑我采用的方案是“统一调度动态优先级打分”。每个外呼信号到来时不立刻拍板而是把所有轿厢按照可响应程度打一个分数分最高的获得归属权。打分项分三个方面来算距离分轿厢当前位置到外呼楼层的距离越短得分越高。如果轿厢正在运行预测它到目标层的时间而不是用绝对楼层差。顺路分如果轿厢正在上行这个外呼也是上行请求且轿厢尚未经过该楼层顺路分拉满如果轿厢正在下行、外呼是上行请求顺路分很低。负载分轿厢当前内呼登记数越少得分越高。这样避免某一部电梯任务堆积其他电梯闲置。打分模型可以做成加权公式比如总分 0.5 × 距离分 0.3 × 顺路分 0.2 × 负载分。权重没有固定标准我试过几组性价比最高的组合是0.5/0.3/0.2。你可以根据自己的调试感受调整但建议不要频繁改每次只改一个权重用仿真数据对比不然会分不清是哪个参数影响了结果。4.3 高峰期策略上行高峰触发条件三部十层电梯在平时客流下一个基础调度算法就够了但在上下班高峰期如果还用同一套策略会出现一个典型问题所有轿厢都被派到一层接人一层的外呼信号不断涌入轿厢在低楼层之间来回跑高楼层的人等很久。所以要设计高峰模式切换逻辑。我的实现方式是统计在最近2分钟内一层和二层登记的上行外呼信号次数如果超过设定阈值比如15次同时顶层区域下行外呼也超过一定量则判定为上行高峰系统自动切换为高峰调度策略。高峰策略下调度逻辑会发生三点变化一是优先保证把空载轿厢派往底层而不是就近响应中层的外呼二是轿厢在底层上满乘客后直接优先满足高层内呼中途不再响应顺向外呼快线直达模式三是如果一部轿厢正在上行且已满载后续上行外呼不再分配给该轿厢。这个策略对降低平均候梯时间效果非常明显也是评分里拉开差距的关键点。另外一个重要细节是高峰模式的恢复条件。如果客流恢复正常系统要能够自动退出高峰模式否则低层轿厢会一直执行快线策略造成中层和顶层的长候梯时间上升。我设置的恢复条件是连续3分钟内底层上行外呼登记数量低于阈值并且系统内没有待响应的长候梯信号才解除高峰模式。4.4 空闲停靠策略与节能优化评分指标里有一项是能耗三台电梯如果没事干就原地待着其实不算最优解。空闲停靠策略的目标是在不增加平均候梯时间的前提下把轿厢提前分布到最可能被呼叫的位置。最简单的空闲停靠策略是“就近停靠”轿厢完成任务后就停在最后一个服务楼层。这种策略在随机客流下表现一般但是实现成本最低。更进阶的做法是“预测停靠”比如早上8点到9点半倾向让一部轿厢停在一层待命另一部停在中间层五-六层还有一部留在顶层区域。这三个点是历史客流统计出来的高概率呼叫楼层仿真评分跑下来平均候梯时间能改善10%-15%。节能方面还有一个小技巧轿厢空闲时可以关闭轿厢照明和风扇输出EET模型里是有对应能耗统计的。虽然单个信号分值不大但一分之差也可能决定排名能拿的分尽量都拿。5. 实操过程与仿真调试经验5.1 从零搭建项目的完整步骤我用的开发环境是TIA Portal V16及以上版本CPU选的是S7-1200或S7-1500具体型号要对应赛方提供的EET接口版本。搭建项目时可以按以下步骤走第一步在TIA Portal里新建项目添加PLC设备设置好IP地址确保和PLCSIM或真实PLC在同一网段。第二步建立全局数据块用来存放所有外呼信号、内呼信号、轿厢状态和调度变量。第三步编写单梯控制功能块每个轿厢一个实例。第四步编写群控调度功能块处理外呼信号归属。第五步配置EET和PLC之间的通信接口把程序里的输入输出变量和仿真模型的信号对应起来。最后一步是联调。这里特别提醒数据块的变量排列顺序要尽量和EET的信号映射表一致并且做好注释。EET联调时它读取PLC变量的方式是定长数据区批量读取如果你的变量顺序乱或者中间插了一个不同数据类型的变量整个映射就会错位而且这种错位很隐蔽程序编译不报错但仿真模型里的信号跟实际逻辑完全对不上。5.2 分步调试法先单梯后群控不要一上来就全系统联调那样出了问题根本没法定位。我习惯的调试顺序是第一步单机开环测试。禁用群控分配逻辑手动给1号梯的内呼信号看它能不能按顺序完成目标楼层的停靠。这步通过后说明状态机和开关门逻辑没问题。第二步单机外呼测试。恢复外呼信号但强制所有外呼都分配给1号梯验证外呼登记和顺向截梯逻辑。第三步双梯竞争测试。恢复群控算法但只启用两部梯人为制造一些竞争场景比如同层同时按外呼看分配算法是否稳定。第四步三梯全量测试。把系统完整跑到仿真场景里连续跑几轮记录平均候梯时间和长候梯次数。每一步测试我建议都做一个简单的调试面板用HMI或者变量监控表把这些关键变量拉出来实时看轿厢当前状态、方向、目标楼层、外呼归属、高峰模式标志。只要这些变量一眼能看明白程序出没出问题基本就能判断个大概。5.3 常见问题与排查技巧实录调试过程中遇到的坑我整理成一张速查表很多问题是反复出现的。现象可能原因排查思路轿厢收到外呼信号但不响应外呼没分配给该轿厢或登记位被其他程序段复位检查群控分配逻辑看归属变量是否写入轿厢运行中在非目标楼层误停平层判断条件里缺少“当前楼层目标楼层”检查停靠判定是否为“楼层相等且平层信号有效”轿厢到达目标层但不开门门区信号被扫描周期漏掉给门区信号加置位锁存电梯关门后不动弹运行方向输出与平层信号时序冲突确认平层信号复位时机是否在启动运行之前外呼灯响应后不熄灭响应完成逻辑未编写在停靠开门时清除对应登记位高峰模式触发后不恢复恢复条件中的时间窗口一直不满足检查当前时间统计变量是否清零群控下两部电梯同时开门外呼信号没有在分配时加互锁增加“信号已分配”标志分配后他梯不可响应仿真偶发卡死、信号不刷新PLC和EET通信超时缩短PLC循环周期检查网络通信稳定性5.4 时间管理的建议西门子杯备赛时间紧张很多人最后几天还在调群控参数这是比较危险的状态。我的体感是整个程序的开发节奏应该这样分配第一周把单梯逻辑完整跑通第二周把群控调度的基本框架写完第三周集中做高峰策略和边界场景测试最后留几天做整体数据的微调而不是从头到尾都在改算法。边界场景里有三类必须测一是连续多楼层外呼时轿厢的顺向停靠顺序是否正确二是满载状态下外呼信号如何重新分配三是消防或检修模式下所有外呼信号应全部清除、轿厢应直接回到指定层。最后一个经常被忽略但赛题评委很喜欢在演示环节专门触发这类特殊工况。最后再分享一个我觉得很实用的小习惯修改程序前先把当前能正常运行的版本导出一份备份。群控调试时经常改一个权重就影响全局行为改完跑分不如上一版没有备份就得凭记忆往回改效率极低。有了备份每次改动都是可控的。我个人的体会是电梯群控这类项目真正难的不是某个算法有多精巧而是你要在有限时间内把所有模块的耦合关系理顺、把所有异常场景都覆盖到。稳扎稳打把基础逻辑写扎实比追求复杂算法更有利于拿分。如果你时间充裕后续还可以在调度模型里加入更多预测能力比如根据历史客流自动调节各层外呼信号的权重那是从“能跑”走向“跑得聪明”的路子。