西门子PLC电梯群控实战：S7-1500以太网通信与调度算法解析

2020年那场西门子智能制造挑战赛离散行业自动化方向的赛题是6部10层电梯群控。现在回头看这套题其实精准踩中了工业控制里最典型的三个痛点多设备协同、实时通信、安全逻辑。当时不少队伍翻车不是不会写电梯程序而是把“6部10层”想成了“6个单梯程序”结果一联调就四处打架。这篇文章不做走马观花的介绍把我从赛题拆解、方案选型、调度算法设计、博途程序实现到现场调试的全部经验写下来。目标是给两类人看一是备赛学生能在方案层面少走弯路二是做电梯群控、物流分拣、多工位联动的工程师这套“通信调度安全”的套路是共通的。1. 赛题背景与需求拆解6部10层电梯群控到底在考什么1.1 任务书里的字面要求与真实考点任务书通常写得很简洁6部10层电梯采用以太网通信实现电梯基本运行、开关门、楼层召唤响应、内呼外呼处理、停电/故障应急等功能。字面上看每部电梯的逻辑都不复杂单梯程序在课程设计里都写过。但把6部放在一起再用以太网把PLC、触摸屏、仿真模型和上位机连成一张网难度就上来了。真实考点可以拆成四层第一层是单梯逻辑平层、开关门、方向判断、内呼存储、轿厢运行。第二层是通信组态PLC与仿真模型之间通过以太网交换数据触摸屏和上位机也要走同一张网IP规划、设备名、数据类型全部要提前定死。第三层是群控调度6部电梯面对同一个外呼谁去响应空闲梯停在哪一层怎么避免多辆电梯同时赶到同一楼层第四层是安全与异常急停、门锁断开、限位越程、故障锁定这些逻辑优先级高于一切正常调度。很多队伍在第四层摔得最惨。程序跑得欢快但安全逻辑没做好裁判一按急停电梯状态就乱掉直接扣分甚至判零。所以赛后我最大的体会是先把安全逻辑当核心再把调度当加分项。1.2 为什么“6部10层”会让很多人翻车先说一个最容易忽略的点10层楼有9个运行区间每部电梯有上行、下行、静止三类状态6部电梯同时运行理论上就是一个巨大的状态组合。如果程序里各梯互相独立、各管各的外呼一多必然出现三辆车同时响应7层、另外3辆停在1层发呆的荒诞场面。从系统角度看“6部10层”本质上是让一台PLC同时管理一个多智能体协作系统。难点不在单梯而在资源竞争一个外呼只能分配给一部电梯但这个决策必须在极短时间内做出并且要防止多车同时响应。任务动态性电梯运行中会不断进来新的内呼和外呼调度策略不能只做一次静态分配。反馈滞后电梯不是点一下就能立刻到达运行过程中楼层位置实时变化程序需要持续跟踪。换句话说这道题考的不是“你会不会写电梯”而是“你会不会设计一套规则让6台设备像一个整体一样工作”。理解了这一点后面所有方案取舍都有明确方向。2. 总体方案选型以太网通信与硬件架构设计2.1 以太网通信方案对比为什么不用传统总线赛题写明“采用以太网通信”所以第一件事就是放弃传统的RS485、Modbus RTU、MPI等串行方案。以太网的优势很明显带宽高、组网方便、设备兼容性好同时还能承载PROFINET实时协议和普通TCP/IP应用。比赛场景里PLC既要和仿真模型交换状态数据又要和触摸屏做HMI通信还要让C#上位机通过OPC UA读取变量用于评分显示一张以太网全部搞定了。当年很多队伍纠结一个问题PLC与电梯仿真模型之间的通信到底是走PROFINET还是走自定义TCPPROFINET适合分布式IO从站和驱动设备比如远程IO模块、G120变频器、仿真模型里的ET200SP优点是实时性高组态后在博途里直接映射IO地址。自定义TCP适合和电脑上位机、第三方设备通信C#里用Socket或S7协议库就能读写PLC数据。我最终采用的方案是混合使用CPU选用西门子S7-1500变频器和远程IO走PROFINET触摸屏和上位机走普通以太网再通过一个工业交换机把所有设备接到一张网里。这样既保证了实时控制的确定性又保留了上位机监控的灵活性。2.2 硬件选型与网络拓扑控制器我选了S7-1500而不是S7-1200原因很实际电梯群控程序体量不小FB块、背景DB、全局DB较多1200的程序存储空间和块数量有限1500的CPU无论是内存还是指令处理速度都更充裕调试时还能在线看到更多变量状态减少下载次数。如果预算受限1200也能跑但前提是程序结构要更精简变量管理得更严格。触摸屏当时用的是威纶通型号我记不太清但通讯方式很典型威纶通触摸屏通过以太网直连S7-1500在屏上建变量时选择西门子S7-1500驱动填入PLC的IP地址即可。变频器我选过ABB ACS580也有队伍用西门子G120。ABB变频器和西门子PLC通过Modbus TCP或PROFINET通信控制字、状态字的格式要对照变频器手册逐个位确认这个细节我在后面调试部分会展开。网络拓扑大概是这样的规划设备角色IP规划说明S7-1500 CPU主控制器192.168.0.10运行群控主程序触摸屏人机界面192.168.0.20威纶通/西门子面板以太网直连电梯仿真模型被控对象192.168.0.30通过PROFINET/以太网与PLC交换信号变频器电梯驱动192.168.0.31~36每部电梯一台或采用群控一体化方案上位机可选监控/评分192.168.0.50C#开发通过OPC UA读取变量工业交换机组网核心192.168.0.1建议采用网管型交换机方便排查IP规划这一块看着简单但比赛现场真有人因为多台设备IP冲突联调时PLC和触摸屏一会通一会断白白浪费一下午。所以我建议提前把IP表打印出来贴在调试台上谁都不许临时改IP。2.3 电梯仿真模型与数据交换思路赛题里的电梯模型如果是有实体的电控箱那每部梯会有门锁、平层开关、上下行接触器、内呼外呼指示灯等物理IO如果是纯仿真模型那很可能是通过通信报文把电梯状态字发给PLC。不管是哪种方式程序里强烈建议统一用“状态字命令字”的方式处理而不是散落的一大堆独立点位。我在项目里为每部电梯建了一个结构体数据块包含当前楼层编码用整型存储例如1层110层10。运行方向0静止、1上行、2下行。门状态0门锁闭、1门开到位、2门正在开关、3故障门。内呼登记字10个BOOL或一个WORD的位组合。外呼响应标志区分上下行方向。命令字启动运行、停止、开门、关门、急停等。把这些数据集中放到一个数组型的DB块里比如ElevatorData[1..6]好处是后面写群控算法时可以用循环遍历6部电梯的数据不用复制六遍逻辑。这就是工程化写法和课程设计的区别。3. 群控调度算法的设计与落地3.1 调度策略选型从先到先服务到分区动态分配最常见的入门策略是先到先服务也就是谁的呼叫先来谁先响应。这种策略在2部5层的小题里勉强能用但在6部10层场景下效率很差一部电梯正在往10层跑途中又来了一个1层外呼系统如果继续让这部电梯去接其他电梯反而闲置等待时间会明显拉长。我当时在调度策略上做了对比策略优点缺点适用场景先到先服务逻辑简单无法全局优化容易造成空跑小规模、低并发最短距离优先响应较快会造成多辆电梯聚集在同一区中等规模固定分区每梯负责固定楼层负载不均忙的忙死、闲的闲死楼层分布极均匀动态分区就近分配均衡性好响应快算法复杂度高需防抢单6部10层此类赛题最终我采用的是“动态分区就近分配”的混合策略。大致思路是每部电梯维护一个目标楼层队列队列按电梯运行方向排序。当有新的外呼产生时先判断这个外呼所在楼层落在哪个服务区内。服务区内有空闲电梯时让离目标楼层最近且运行方向顺路的电梯响应。如果区内没有空闲电梯则从相邻区找一辆行驶方向能“顺路带客”的电梯来处理。这个策略实现成本适中效果却很稳比赛时既不会出现多梯抢单也不会出现某部电梯闲到落灰。3.2 信号采集与状态判定防止重复登记和漏信号电梯程序里最烦人的不是复杂算法而是信号的可靠性。外呼按钮按下去如果程序用普通的电平读取PLC扫描周期内可能会读到多次就会重复登记。我用了博途里的R_TRIG和F_TRIG沿检测功能块来处理按钮信号只在按钮闭合那一刻登记一次松开后的电平变化不再触发。楼层位置信号也一样。电梯经过楼层时每层的到位开关会闪一下如果程序在上行过程中检测到5层到位信号它自然就停。但问题是电梯运行速度快、到位信号脉冲短PLC扫描周期如果太长可能漏掉这一帧信号。因此我专门用一个定时中断OB来处理位置信号采样。我当时的思路是正常逻辑放在OB1循环扫描里。用OB30循环中断每10ms对到位信号做一次采样把脉冲信号转换成“当前楼层”模型。如果检测到连续两次到位信号之间跳过了某个楼层说明信号异常立刻停止电梯并报警。这个设计看起来多花了一点点功夫但在现场运行中避免了我无数个掉线问题。3.3 派梯决策与防错杜绝多梯抢单群控最容易出的问题不是“没人去”而是“一窝蜂全去”。我调试时亲眼见过三辆电梯同时从不同楼层赶往7层就为了响应同一个外呼。裁判没扣分之前我自己先看傻了。后来我在派梯逻辑里加了“派梯锁定”机制系统一旦给某部电梯分配了外呼就把该外呼标记为“已被响应”其他电梯不再扫描这个呼叫。被选中电梯在运行途中每完成一个响应就清除对应的标记。如果被选中电梯因故障无法执行则由调度块在下一个周期重新分配。同时为了避免两辆空闲电梯同时判断“我最近”我在派梯判断里引入了一个微小的随机权值。当两部电梯距离目标楼层距离相同时系统随机选择其中之一而不是同时选中。这个细节虽然不起眼但能明显减少群控中的竞争冲突。调度核心用SCL写出来大概是这种感觉FUNCTION_BLOCK FB_Dispatcher // 遍历6部电梯计算每部电梯到当前外呼楼层的响应代价 FOR i : 1 TO 6 DO // 基础距离代价 distanceCost : ABS(currentFloor[i] - callFloor); // 顺路奖励同方向减权值 IF (elevatorDir[i] up AND callDir up AND currentFloor[i] callFloor) THEN cost : distanceCost - 2; ELSIF (elevatorDir[i] down AND callDir down AND currentFloor[i] callFloor) THEN cost : distanceCost - 2; ELSE cost : distanceCost 3; END_IF; // 故障/急停电梯直接排除 IF (faultFlag[i] TRUE) THEN cost : 9999; END_IF; // 取最小代价的电梯 IF (cost minCost) THEN minCost : cost; selectedElevator : i; END_IF; END_FOR;这段代码只是一个骨架真正的工程代码里还要处理目标队列、响应的确认信号、超时重派等逻辑。但核心思想很明确用代价函数做决策而不是简单比较距离。4. 程序结构与关键功能块实现4.1 博途项目架构与程序块规划拿到赛题第一件事不是急着写程序而是先把博途TIA Portal项目结构搭好。我当时建了一个S7-1500项目程序块规划大致如下程序块名称作用OB1主循环程序调用各FB块完成整体逻辑OB30循环中断程序10ms采样到位信号处理高速信号OB100初始化程序设置初始楼层、清空呼梯记录OB83故障诊断OB采集PROFINET设备掉站故障FB1FB_Elevator单梯控制功能块背景DB用数组生成6份FB2FB_Dispatcher群控调度功能块负责外呼分配FB3FB_Safety安全保护与急停块FB4FB_Alarm故障报警与复位块DB1DB_Elevators6部电梯数据集合数组类型DB2DB_Dispatcher群控算法运行变量区DB3DB_HMI触摸屏与上位机共享数据区使用FB块配合背景DB数组是核心技巧。如果我把单梯逻辑写成6份独立的FC一旦出现一个Bug就得改6遍但用FB_Elevator再分别生成DB_Elevator[1]到DB_Elevator[6]程序体量一下子减少很多。修改单梯逻辑时只动一个功能块就够了。4.2 轿厢控制核心FB块状态机设计单梯控制的本质是一个状态机。我定义的电梯状态包括空闲、响应内呼、响应外呼、运行、到达平层、开门、开门保持、关门、门故障。状态机必须明确描述“什么条件下从状态A切换到状态B”否则一但电梯在半路卡住程序就不知道该干嘛。SCL代码实现一组状态转移逻辑时我习惯先画一张状态表再写代码当前状态转移条件下一状态空闲有内呼/被派单运行运行到位信号1到达平层到达平层平层信号稳定开门开门开门到位信号开门保持开门保持延时1.5秒或内呼再次触发关门关门门锁闭信号空闲或继续运行实际代码里有个坑电梯到达平层后如果立刻开门门还没开完电梯的状态又因为某些信号跳回运行就会造成门没开就走的危险动作。解决方法是在平层后增加一个“平层锁定”标志只有门完全关闭且门锁回路闭合后才允许再次进入运行状态。这个标志必须在程序中全局使用HMI监控时也能直观看到。4.3 门机与平层控制信号可靠性是第一优先级电梯门控制看着简单但很容易出问题。门机动作通常有开到位、关到位、光幕、安全触板、开门超时等信号这些信号如果处理不当电梯会在运行中频繁误开门。我处理门保护信号的原则是光幕信号和开门信号并联只要光幕检测到有人电梯就必须保持开门状态不能强制关门。关门到位后延时100ms再确认门锁避免门锁继电器抖动导致信号误判。开门超时后报警但不反复尝试关门如果门因为某种原因关不上程序要先触发故障而不是无限循环试图关门。平层控制上我的做法是不只依赖一个到位开关而是同时读取上、下两个方向的位置信息。如果电梯在上行过程中收到5层到位信号但紧接着又收到4层信号说明编码器或传感器时序异常程序应当马上停车不能继续傻跑。4.4 安全保护与急停逻辑宁可误停不可漏停电梯赛题里最核心的评分项往往是安全逻辑。急停、门锁、限位、超速这几类保护任何一项没做好都可能导致比赛直接零分。我用专门的功能块FB_Safety管理全部安全逻辑优先级比群控调度、单梯控制都要高。急停块的处理逻辑我总结成三个原则冗余检测急停信号同时读PLC物理输入和通信状态字避免单一信号通道失效。最高优先级急停触发后立即清除所有电梯的运行命令包括变频器使能、抱闸松开信号、派梯队列。可恢复性故障排除后必须有手动复位信号不能自动恢复运行防止人员还没撤离电梯就突然启动。具体被复位前要检查的条件包括所有急停按钮均已释放、门全部关闭且门锁回路闭合、电梯处于平层区、没有未消除的报警。这些条件全部满足后才允许按复位按钮这个流程能防止很多危险场景。5. 调试实录现场遇到的典型问题与排查方法5.1 以太网通信时断时续赛前联调第一天我遇到了一个特别诡异的问题触摸屏和PLC通信正常但C#上位机通过OPC UA读取变量时每隔几分钟就会报一次超时。一开始我怀疑是电脑的问题换个电脑还是这样。后来查了一下午发现是交换机上同时接了一台视频监控摄像头。这个摄像头走的是普通视频流量数据量大得惊人直接把交换机的转发能力吃掉了。工业通信网络最忌讳的就是和非实时设备混跑高流量数据。排查网络问题的顺序我建议是先看物理链路网线、水晶头、交换机端口指示灯是否正常。再看IP冲突用工程软件扫描全部设备IP排除重复分配。然后看通信负载确认没有大流量设备占用网络。最后看PLC诊断缓冲区在博途里查看CPU的诊断事件看有没有PROFINET设备掉站记录。那次之后我严格要求现场所有设备必须按前面的IP表分配不允许任何人私自接设备到交换机上。5.2 六部电梯互相抢任务这个现象在第一次整系统联调时就出现了。我当时把派梯算法写好看着屏幕上6部电梯一个外呼触发三部车同时从不同楼层开过去。一开始我以为是距离计算写错了后来单步调试发现派梯逻辑确实只选中了一部电梯但另外两部电梯的运行队列里也残留着老的外呼记录。问题根源在于外呼响应标志没有被及时复位。之前电梯已经响应过一次该楼层但程序只在“完全到达且门开到位”时才清除标志而象征性的半路停车不会清理。于是我改成了“一旦电梯到达目标楼层且平层信号有效立即清除外呼标志”而不是等门完全打开。这里有个小经验群控程序的响应标志清除时机一定要和电梯状态绑定不能只靠定时器。定时器再准也会抖动状态信号才可靠。5.3 触摸屏与PLC数据同步问题威纶通触摸屏连接西门子S7-1500时用绝对地址导入标签很容易错位。尤其是DB块里的结构体变量HMI端解析时如果类型不匹配读出来的数据完全是乱的。我后来采用了一个更稳妥的办法在PLC里专门建一个DB_HMI数据块把所有需要显示和修改的数据平铺成单个变量不使用结构体嵌套。每个HMI变量对应一个绝对地址比如DB3.DBD0、DB3.DBX4.0。虽然牺牲了一点变量组织的美观度但触屏和上位机访问起来极其清晰调试效率大幅提升。如果你用的是西门子自家的精智面板问题会少一些因为博途可以直接关联符号变量。但用第三方触摸屏我还是建议用平铺数据区省得跟HMI驱动较劲。5.4 变频器启停与抱闸时序电梯运行要求极高的时序配合。变频器输出频率和抱闸打开时机如果配合不好电梯启动时会溜车停车时会有冲击感。ABB变频器与西门子PLC通信时控制字和状态字每一位都有明确含义。比如控制字的位0是ON/OFF1位7是故障复位状态字的位6是“运行准备好”位12是“运行中”。程序里必须先确认“运行准备好”再发送启动命令启动命令发出后变频器输出频率达到设定值时才能打开抱闸。我不止一次看到有队伍的电梯启动瞬间先溜一下然后猛地停住这就是因为抱闸打开得太早变频器还没建立励磁和力矩。反过来停车时如果先抱闸后降频也会产生急停感。正确顺序是先让变频器减速到零确认零速信号后再由PLC控制抱闸闭合最后关闭变频器使能。我当时的调试方法是在博图里同时监控变频器的输出频率和PLC送给抱闸的输出信号把它们放到同一个趋势图里看时间差反复调整发送命令的延时周期最终找到一个稳定的配合点。5.5 常见问题速查表故障现象可能原因排查手段触摸屏连不上PLCIP冲突、网线松动、HMI驱动选择错误检查IP表、换网线、重选驱动型号电梯运行中突然停车门锁信号丢失检查门锁回路和信号抖动增加滤波时间多梯抢单外呼标志未清零、距离判断相同调整清除时机派梯增加随机权值电梯停层过冲变频器减速曲线太陡、抱闸时序不对调整斜坡时间核对抱闸顺序变频器运行但电梯不走抱闸未打开、方向命令反向检查抱闸输出、检查方向信号映射上位机读变量偶尔超时网络混有视频流量、OPC UA节点过密隔离设备网段优化采集周期6. 赛后复盘这套程序还能往哪里用比赛结束之后我把这套程序重构了一遍拆掉赛题相关的限制发现它可以复用到很多真实场景。智慧园区里的多部电梯联动、工厂里AGV在多站点的派车调度、自动化产线里多个机械臂并发处理工位任务本质都是“多智能体协同以太网通信安全保护”的三件套。我做项目时的一个强烈体会是不要只盯着一场比赛而是通过赛题练出工程化思维。现在很多开发环境越来越强调快速迭代但PLC这种工业级设备最值钱的反而是稳定、可维护、安全冗余。给备赛的学生一个建议赛前一个月一定要找一个“最笨”的调试流程把每个变量、每个信号都打印出来检查一遍再去写算法。我见过太多队伍算法思路很漂亮结果信号采集就出问题最后输得莫名其妙。如果是工程场景的同行看到这篇文章我想说的是电梯群控只是多设备调度的缩影你完全可以把这里的动态分区、派梯代价函数、故障复位流程迁移到物流分拣、立体仓库、多主轴机床联动里。工业控制没有银弹但一套清晰的数据结构和状态机可以陪你走很远。