做了几年工业控制和自动化项目手里过过不少PLC程序但真正让我觉得“有点意思”的还是这个电梯群控分配与仿真的活儿。单台电梯的控制逻辑说白了就是状态机加顺序控制翻来覆去就那么点东西。但一旦把三台、四台电梯扔到一个楼里让它们自己商量着怎么接活、怎么避免空跑、怎么把高峰期的人尽快送走这里面的门道就完全不一样了。你在网上搜“电梯程序设计”、“PLC群控分配”、“仿真”能搜到一堆资料但大部分要么停留在理论算法层面要么就是只给个梯形图片段让人自己悟。我这篇就打算把从需求拆解、方案选型、算法设计到博图仿真调试的完整链条捋一遍把我实际踩过的坑和验证过的思路都写出来给正准备做类似项目的朋友一个能直接参考的底子。这个项目我定了个典型场景一栋6层楼3台电梯用西门子S7-1200系列PLC做控制核心配合TIA Portal博途和PLCSIM做仿真验证。选这个配置是因为它足够贴近实际商用环境又不至于复杂到没法在文章里讲透。不管你是自动化专业的在校学生还是刚入门准备接楼宇控制项目的工程师这篇文章应该都能帮你省下不少瞎折腾的时间。1. 项目需求与整体方案选型1.1 群控电梯到底在解决什么问题电梯群控全称是“多台电梯集中调度控制”。单台电梯的逻辑很简单有人按了楼层电梯判断方向关门运行到了开门。但多台电梯放在一起问题就来了——6楼有个人要下楼是派1号梯去还是3号梯去如果两台电梯都在1楼闲着是不是应该只让一台响应另一台待命如果所有电梯都在往上跑这时候1楼有人在等该让哪台梯中途折返去接这些问题本质上是一个多目标优化问题。你要同时照顾几个指标乘客平均候梯时间这个最直观等得越短越好。乘客乘梯时间不能光看候梯进了轿厢绕来绕去也烦。系统能耗电梯是大功率设备空跑一趟的电费也是实打实的成本。设备磨损频繁启停和开关门对机械部件损耗很大。群控分配算法就是在这些指标之间找平衡。纯做单台电梯的程序设计你不需要考虑这些但一旦做群控你的程序里就必须有一个独立的“调度决策”模块专门负责接收外呼信号然后根据每台电梯的当前位置、运行方向、已有任务列表算出该派谁去。1.2 为什么选PLC而不是单片机或工控机这个项目也有人用单片机做或者干脆用PC加组态软件做。但我坚持用PLC原因有三第一是可靠性。电梯涉及人身安全控制器必须在工业环境下长时间稳定运行。PLC的设计寿命和抗干扰能力是消费级单片机没法比的更关键的是PLC的扫描周期是确定的程序执行到哪一步、需要多少时间都可以精确掌控这对安全联锁逻辑至关重要。第二是维护门槛。电梯维保人员普遍熟悉梯形图出了故障能直接用编程器在线监控排查。你要是扔给他们一套C语言写的单片机程序现场维护基本就抓瞎了。这也是PLC在楼宇控制领域几十年不倒的核心原因。第三是仿真生态成熟。西门子博途自带的PLCSIM能很好地模拟S7-1200/1500的指令执行配合HMI仿真面板完全可以在没有实物电梯的情况下完成绝大部分逻辑验证。这套流程在工业界已经非常成熟。选S7-1200还有个现实考虑它支持结构化编程可以做函数块FB和全局数据块DB对群控这种需要“多个实例共享同一套逻辑”的场景特别合适。三台电梯的轿厢控制逻辑完全一样我只需要写一个FB然后调用三次、各自配上独立背景数据块就行代码量直接省了三分之二。1.3 仿真方案怎么选项目开始前我对比了几种仿真路线纯逻辑仿真用PLCSIM跑PLC程序用HMI仿真面板做可视化按钮和指示灯。优点是没有硬件成本、上手快适合验证控制逻辑本身缺点是没有电机、限位开关这些物理实体的动态响应。PLCFactory IO三维仿真Factory IO能搭建一个虚拟的电梯井道和轿厢通过OPC UA或数字量I/O协议与PLCSIM通信。视觉效果好能直观看到电梯的机械运动调试起来更有感觉。缺点是三方软件联调网络配置有点折腾对电脑性能也有要求。实物PLC触摸屏最接近真实但成本最高适合后期验证不适合初期开发调试。我最后的做法是分两步走程序开发阶段用纯逻辑仿真把算法和联锁逻辑全部跑通验证阶段接了Factory IO把机械动作和传感器信号也带进来做了闭环测试。这个组合在效率和真实性之间取得了最好的平衡。2. 系统架构与信号设计2.1 控制系统的分层结构群控电梯程序不能一上来就埋头写梯形图先得把系统架构想清楚。我习惯把整个控制程序分成三个层次执行层每台电梯的轿厢控制逻辑包括开关门控制、上下行接触器、楼层判断、内呼登记与消除。这一层只负责“把电梯开到指定楼层”不关心任务是谁派的。决策层群控分配逻辑负责接收所有电梯的厅外召唤信号评估各电梯的状态决定派哪台电梯去响应。这一层是群控项目与传统单梯项目的核心区别。交互层内外呼信号的采集与显示、HMI人机界面、故障报警与复位。这一层负责把人的意图翻译成机器信号再把机器状态反馈给人。这个分层最大的好处是解耦。执行层的程序可以先用单梯模式单独调试决策层暂时不参与等单梯逻辑完全可靠了再接上调度算法。反正我调试的时候深有体会混在一起写程序出了bug你根本分不清是电梯自己没跑对还是群控派错了单。2.2 点位表设计群控程序的“地基”任何PLC项目的起点都是I/O信号表也就是点位表。群控电梯的点位远比普通单梯多而且因为S7-1200的I/O区域是分散在不同字节上的点位规划得好不好直接决定你后面编写梯形图时有多顺手。我按以下分类设计了点位表每台电梯内部信号内呼按钮1楼到6楼共6个DI点当前楼层6个楼层传感器仿真中用接近开关或1个编码器反馈开关门到位信号、安全触板信号、开门按钮、关门按钮上下行接触器反馈、运行状态反馈每台电梯输出信号上行接触器、下行接触器、开门继电器、关门继电器楼层显示、方向显示接HMI或数码管厅外召唤信号1楼上行召唤、2楼上下行、3楼上下行、4楼上下行、5楼上下行、6楼下行召唤。合计11个DI点每个召唤对应一个指示灯输出用于告诉乘客“你的呼叫已被响应”这里有个容易忽略的细节厅外召唤按钮的登记信号和响应状态要分开。按钮按下只代表有人请求但电梯有没有派过去、派给了哪台这是另一回事。在群控系统里一个厅外召唤被响应后要么由指派电梯的某段逻辑消除这个登记要么由群控模块统一管理。我采用的是后者所有厅外召唤信号统一进决策层DB块由调度算法统一登记、派发和清除轿厢控制层看到的只是“我在运行过程中哪几层需要停下”。2.3 数据块规划三台电梯如何共享同一套逻辑S7-1200的FB支持多重背景和多实例这是群控项目最关键的程序架构手段。我建了这样一个数据块结构共享数据块Global DB里放三台电梯的公共状态和厅外召唤状态比如召唤登记位、召唤响应位、各电梯当前楼层、运行模式等。每台电梯单独的背景数据块Instance DB里放轿厢控制FB的私有数据包括内呼登记、目标楼层队列、开关门定时器、运行方向等。这样做的好处非常明显轿厢控制FB只写一遍三台电梯各调一次程序结构极其清晰。调试哪台电梯直接打开对应的背景数据块监控就行不用在密密麻麻的梯形图里找地址。而且以后如果要扩展到5台电梯只需要在OB1里再调两次FB再在数据块里加上对应的背景数据工作量很小。3. 核心调度算法三种群控方案对比与实现3.1 固定分区法最简单粗暴的方案就是把楼层区间静态分给每台电梯。比如3台电梯管6层1号梯管1-2层2号梯管3-4层3号梯管5-6层。哪个区间的厅外召唤就由哪台电梯响应。这个方案的优点是逻辑简单、没有竞争、程序量小缺点也明显——如果1-2层人特别多1号梯忙不过来而5-6层无人使用3号梯一直闲着也帮不上忙。这种负载不均衡在真实场景里非常常见所以固定分区法只适合低楼层、低流量的场景或者作为应急备份模式。我把它作为基准方案写进了程序里平时不用但可以通过HMI手动切换过去万一调度模块故障还能保证基本的运客能力。3.2 最小等待时间法这是目前商业电梯群控软件里最常用的经典算法。核心思路是当新的厅外召唤产生时系统分别计算每台电梯如果被派去响应这个召唤预计需要多少时间才能到达召唤楼层然后选择所需时间最短的那台电梯。计算预计到达时间需要建立一个相对精确的时间模型T 加速时间 匀速运行楼层数 × 单层运行时间 减速时间 沿途顺向停靠次数 × 停靠开门时间仿真环境里我把加速和减速时间合并为一个固定常数比如2秒单层运行时间设为1.5秒一次停靠开门到关门的时间设为3.5秒。这样每个电梯的预计响应时间就是一个可算的数值。这里有一个细节预测沿途顺向停靠次数时必须考虑“顺向”这个条件。比如某台电梯正在上行经过3楼时如果3楼有下行召唤那么电梯在该层是否要停这取决于电梯群控策略是否允许“顺向捎带”。我在这个项目里允许顺向捎带但只捎带方向一致的召唤。比如电梯正在上行时只响应上行召唤和内呼不响应下行召唤如果某层既有上行又有下行召唤那么电梯经过时会停靠开门一次解决双方向的乘客请求。3.3 综合评估法当前项目的选择最小等待时间法虽然经典但有个问题它只盯着“当前这个召唤谁去最快”没有考虑“这部电梯被派过去之后会不会耽误它已有的乘客”。比如1号梯正在往上走车上有5个乘客分别要去3、4、5楼这时候1楼有下行召唤论距离它最近但派它回头可能让整车人难受。反倒是2号梯虽然远一点但闲着没事跑一趟更平稳。所以我采用了综合评估法在最小等待时间的基础上加上了惩罚项评估分 预计到达时间 绕路惩罚 载客负载惩罚 任务均衡惩罚编写ST结构化文本风格的评估函数大致是这样的FUNCTION_BLOCK FB_Dispatch VAR_INPUT callFloor : INT; callDir : INT; END_VAR VAR_OUTPUT assignedElevator : INT; END_VAR // 对每台电梯计算评估分 // elevator[i].estimatedArrivalTime: 基于运动模型估算 // elevator[i].detourPenalty: 若目标楼层与当前方向相反加惩罚值 // elevator[i].loadPenalty: 基于轿厢内呼任务数量加权 // elevator[i].idlePenalty: 让长期空闲的电梯优先被指派绕路惩罚怎么定我实测了一个经验值如果调度目标楼层在当前电梯运行方向的反方向惩罚系数为15秒如果同方向但在后方惩罚系数为5秒如果正好在前方惩罚为0。这样既能让“顺路”的电梯优先接单又不会完全排除“折返”的方案。载客负载惩罚我直接用轿厢内未完成内呼数量作为负载指标每多一个内呼任务加2秒。这个值我调整过好几轮太大了会导致电梯频繁绕路去接新任务太小了又起不到平衡负载的作用。任务均衡惩罚是为了避免“强者恒强”的死亡螺旋某部电梯因为离得近被频繁指派结果所有任务都堆给它其他电梯闲死。我给每台电梯维护了一个“连续被指派次数”计数超过3次后每次加8秒惩罚强制让系统把新任务分配给相对空闲的电梯。实际仿真跑下来这个机制对整体效率的提升非常明显高峰期三台电梯的利用率能拉开到比较均衡的水平。4. PLC程序实现关键环节4.1 程序框架与扫描周期规划S7-1200的程序执行是按OB组织块扫描的。我的程序框架是这样组织的OB1主循环调用轿厢控制FB三次调用群控分配FB一次调用I/O刷新逻辑OB100暖启动初始化数据块复位所有输出OB10定时中断100ms调用时钟逻辑用于调度算法的时间戳计算这里有个值得注意的点电梯的开关门时间和运行时间都不短最长的运行动作可能要好几秒而PLC扫描周期只有几十毫秒。所以在定时器使用上我统一用了TON通电延时定时器而不是计数器取市场保证不管程序扫描到哪一步时间基准都是一致的。4.2 厅外召唤的登记与派发厅外召唤的登记逻辑是所有群控程序的基础。下面是厅外召唤登记与派发的梯形图设计思路我用指令风格描述关键段Network 1: 厅外召唤登记 A HMI_CallUp_2F // 2楼上行召唤按钮常开触点 AN CallRegister_2F_UP // 该召唤尚未登记 S CallRegister_2F_UP // 置位登记位 Network 2: 群控决策触发 A CallRegister_2F_UP // 有登记的召唤 AN DispatchDone_2F_UP // 尚未完成派发 S DispatchTrigger // 启动一次派发计算派发结果不是直接置位某台电梯的“去2楼上行”信号而是把“目标楼层方向”存入被指派电梯的待处理任务队列里。这个队列我放在每台电梯的背景数据块中用数组加指针的方式实现。轿厢控制FB在每个扫描周期检查自己的任务队列按顺序执行。4.3 轿厢运行方向决策与顺向截梯电梯运行方向决策是一个典型的“状态机”问题。每台电梯只有两个核心状态上行中、下行中外加一个静止待命状态。方向决策逻辑如下如果电梯当前没有任务则保持静止开门待命。如果电梯正在上行那么它只处理“当前楼层上方的同向内呼”和“当前楼层上方的上行厅外召唤”当所有上行方向的任务都完成再检查是否有下行任务有则换向没有则静止。下行时的逻辑对称。这里最难写的是“顺向截梯”的判断。我举一个场景1号梯正在上行已经过了3楼车上有人要去5楼。这时候4楼有人按了上行召唤。因为4楼在运行方向前方且召唤方向与电梯方向一致属于顺向召唤电梯到达4楼时应自动停车开门。但如果4楼按的是下行召唤除非该层同时有内呼否则电梯不在4楼停要把这个召唤留给其他电梯处理。具体到梯形图里这个判断就是一组比较指令Network: 顺向停靠判断上行方向示例 // 电梯运行方向上行且当前目标楼层4楼 A Elevator_Dir_UP A( A CarCall_Call4 // 4楼有内呼 O HallCall_4F_UP // 或4楼有上行外呼 ) StopRequest_4F // 输出4楼需要停车这段逻辑看起来简单但真正难的是把它放进一个循环或重复调用的FB里用通用的方式表达“任意一层的顺向停靠判断”。我的做法是把楼层参数作为FB的输入变量调用时分别传1楼、2楼……6楼的状态位而不是硬写六段几乎一样的程序。虽然梯形图里没法像高级语言那样写循环但通过多重背景和变量索引代码量还是能控制在合理范围。4.4 开关门逻辑与安全联锁开关门逻辑看起来简单但却是电梯程序里最容易出事的部分。我遵循的原则有几个开门条件必须严格执行电梯停止在平层区域楼层传感器有信号且处于静止状态才允许开门。关门优先级最高无论什么情况下只要有安全触板信号或者开门按钮信号正在进行的关门动作立即停止并重新开门。超时保护开门时间超过设定值我设了30秒仿真中可改自动尝试关门连续关门失败3次报警待机。这些安全联锁我用一个独立的安全FB实现放在所有动作逻辑之前相当于一个“总闸”——如果安全条件不满足所有输出都禁止。4.5 仿真HMI面板的设计思路为了验证群控逻辑我还在博途里做了一个HMI仿真面板。画面布局很朴素左边是三台电梯的轿厢状态区显示当前楼层、运行方向、开关门状态中间是厅外召唤按钮区每一层放上下行按钮和指示灯右边是群控调度监控区实时显示每台电梯的评估分和当前指派状态。这个面板对调试帮助极大。以前用纯软件仿真调试群控算法时根本看不到“系统为什么派了3号梯”只能对着变量表猜。有了HMI仿真面板就能直观看到每次召唤产生时各台电梯的评估分对比一眼就知道派谁对不对。5. 仿真验证的完整过程5.1 搭建PLCSIM仿真环境在博途里搭建仿真环境的步骤很直接但有几个设置点容易被新手忽略。我大概梳理一下在博途里创建项目选好CPU型号我用的CPU 1214C DC/DC/DC。编写完整程序后编译无误把程序下载到“PLCSIM”虚拟PLC中。开发机上需要提前安装S7-PLCSIM软件包注意版本要和TIA Portal一致我遇到过博途V16配PLCSIM V15的情况直接报通信错误。HMI画面用“仿真运行”模式启动HMI和PLCSIM之间不需要额外网络配置博途会自动打通。仿真时我刻意将运行速度调成“常速模式”不要用“快速模式”。群控算法里很多逻辑依赖真实时间估算到达时间、超时保护如果扫描周期被压缩时间模型全乱套程序的调度决策就会失真。这一点务必注意。5.2 多电梯联动仿真测试要点仿真测试不能只跑一遍看结果要有章法地覆盖各种工况。我的测试矩阵大概分这几类单呼派发测试某一层按召唤按钮观察哪台电梯被派出评估分是否符合预期。这一步主要验证调度算法的正确性。同时多呼测试多个楼层几乎同时按下召唤检查系统能否正确处理并发不丢任务、不重复派发。顺向截停测试电梯在上行途中前方楼层出现同向召唤检查能否精准停车。换向逻辑测试电梯到达顶层判断是否正确换向能不能处理反向任务。满载弃呼测试轿厢内呼任务很多时系统是否倾向不派新任务给这台电梯通过负载惩罚实现。故障模拟测试人为把某台电梯的楼层传感器信号置为故障状态观察系统是否将该电梯从调度候选列表中剔除并转移到其余电梯上。每个测试场景我都在HMI仿真面板里录了数据主要是各台电梯的任务响应时间、空跑次数、内呼平均等待时间。这些数据是评估算法好坏的客观依据不是靠感觉调参。5.3 仿真数据结果分析我跑了三组典型负荷场景低峰平均5分钟召唤2次、平峰5分钟6次、高峰5分钟12次每组模拟1小时运行。用三种算法固定分区、最小等待、综合评估分别跑同样的召唤序列记录关键技术指标。综合评估法在高峰期表现最好——总任务响应时间比最小等待法缩短了大约12%比固定分区缩短了近40%。最关键的是三台电梯的利用率从“单台超载、两台摸鱼”变成了“基本均衡”电梯机械磨损也分散了。这套仿真数据在后面写项目总结和评审汇报时特别有说服力建议大家都保留下来。6. 调试实录常见问题与排查技巧6.1 信号抖动与按钮误触发第一个遇到的实际问题是厅外召唤按钮信号抖动。仿真环境虽然不像真实现场那样有严重电气干扰但HMI按钮的点击信号还是可能产生多次上升沿导致同一个召唤被重复登记、重复派发。解决办法是在每个召唤输入前加一个去抖延时滤波器输入信号持续保持20ms以上才认为是有效信号。我用了一个统一的FC块封装去抖逻辑所有DI信号都过一遍。这个习惯到了真实项目现场绝对会救命——现场按钮信号抖动比仿真严重得多。6.2. 任务重复派发与死循环群控调试早期我发现一个怪现象某个楼层召唤明明已经被1号梯响应了但过几秒系统又把同一召唤派给了2号梯。查了很久发现问题出在“派发完成信号”的生成时机上。原来我的派发逻辑是在“电梯开始运行”时清除召唤登记而不是在“电梯到达召唤楼层”时清除。电梯响应过程中召唤一直处于“待处理”状态调度模块的触发条件又满足就重复派发了一次。正确的做法是把召唤登记位的清除时机放在“电梯到位开门”这个动作完成之后。因为只有电梯真正到了召唤楼层并且开了门乘客才算真正被服务到。这个逻辑我在代码里加了一个“到位确认”中间位彻底解决了重复派发问题。6.3 仿真HMI按钮无反应的排查有朋友在群里问过博途HMI仿真按钮没反应的问题我在调试中也遇到过。排查思路一般是先检查HMI变量是否与PLC变量正确关联路径对不对。博途里变量拖拽时经常出现关联丢失尤其是跨项目复制时。再检查HMI按钮的属性确认“操作模式”是“按下置位”而不是“切换”或“点动”模式不对会导致PLC收不到持续信号。还要确认PLCSIM处于运行状态状态栏的“RUN”指示灯亮着而不是停在“STOP”。最后检查数字量地址是否冲突多个按钮指向同一个I地址或Q地址时表现很诡异。我那次就是HMI变量关联丢了重新拖拽一遍就好了。这种问题最容易浪费一整天时间记下来能省很多麻烦。6.4 群控算法的稳定性问题群控调试到后期又出现了一个更难缠的问题调度决策频繁切换。当两台电梯的评估分差距很小时控制系统可能在几个扫描周期内反复切换派发对象表现为厅外召唤指示灯一会亮1号梯、一会亮2号梯电梯也在原地反复改变目标。原因是评估分计算涉及到时间参数时间一变化谁的分最低就在变化。解决办法是对派发结果加一个“锁定”机制一旦派发完成在设定时间内我设了5秒不重新评估这个召唤除非被派电梯报故障。这个方案在仿真里很有效避免了调度震荡。6.5 项目复盘哪些地方可以做扩展最后说点个人感受。这个群控电梯项目做完之后我最大的收获不是写了一堆梯形图而是学会了一件事任何看似复杂的控制系统核心都是把“决策算法”和“执行逻辑”分开先让执行逻辑绝对可靠再把决策算法逐步迭代替换进去优化指标。这个方法在很多工业自动化项目里都通用。如果你也想尝试这个方向我建议你从这个架构开始做先做单梯控制再扩展成群控最后再研究调度算法优化。中间遇到问题不要慌按照分层排查的思路逐级定位大部分问题都能找到原因。后续如果想再更进一步可以考虑引入模糊控制或基于时间预测的调度策略配合仿真实时跑数据去验证效果那就是一个很有竞争力的研究方向了。
