企业官网建设流程全解析

做了几年工业控制和自动化项目，手里过过不少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仿真面板做可视化按钮和指示灯。优点是没有硬件成本、上手快，适合验证控制逻辑本身；缺点是没有电机、限位开关这些物理实体的动态响应。
• PLC+Factory 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 项目复盘：哪些地方可以做扩展

最后说点个人感受。这个群控电梯项目做完之后，我最大的收获不是写了一堆梯形图，而是学会了一件事：任何看似复杂的控制系统，核心都是把“决策算法”和“执行逻辑”分开，先让执行逻辑绝对可靠，再把决策算法逐步迭代替换进去优化指标。这个方法在很多工业自动化项目里都通用。

如果你也想尝试这个方向，我建议你从这个架构开始做：先做单梯控制，再扩展成群控，最后再研究调度算法优化。中间遇到问题不要慌，按照分层排查的思路逐级定位，大部分问题都能找到原因。后续如果想再更进一步，可以考虑引入模糊控制或基于时间预测的调度策略，配合仿真实时跑数据去验证效果，那就是一个很有竞争力的研究方向了。