企业官网建设流程全解析

做了个中央空调水系统的组态仿真项目，用组态王6.55把所有设备搬到了屏幕上，冷冻水泵、冷却水泵、冷却塔、冷水机组、各种阀门温度压力测点，全部能看能控，还能模拟温度波动、压差变化，自动跑启停逻辑。这篇文章把从工程搭建、变量规划、画面设计、脚本逻辑，到仿真调试的完整过程写清楚，适合正在学组态软件、准备做暖通上位机监控，或者想快速验证控制逻辑的人参考。这套仿真做完，下一步接真实PLC也只是换数据源的问题。

1. 中央空调水系统到底在控什么，为什么值得做仿真

1.1 循环控制系统的真实构成

中央空调的循环控制系统，简单说是让冷冻水、冷却水两路水循环跑起来，把房间里的热量最终搬到室外去。这个词听起来很大，拆开看其实设备就几类：冷水机组负责制冷，冷冻水泵把低温冷冻水送到各个空调末端，末端吸收房间热量之后水温升高，回水再回到机组降温；冷却水泵负责把冷却水送到冷却塔，冷却塔通过风机和喷淋把冷凝器的热量散到空气里。整个系统看着是水在转，核心控制目标却很多：要保证冷冻水供水温度稳定，要保证最不利末端有足够的压差，要保证冷却水流量和温差正常，还要考虑机组台数和泵的启停顺序。

这套系统在真实机房里的情况是：地下一层或者楼顶机房里几十台设备同时运行，自控柜里一堆继电器和模块，上位机画面上密密麻麻都是数据。做过楼宇自控的人都知道，冷冻站控制逻辑如果写得不好，最常见的表现就是机组频繁启停、水泵空转、供回水压差忽高忽低。这些问题在现场调试的时候非常痛苦，因为真实系统不可能让你随便改逻辑反复试，试错成本太高。仿真环境最大的价值就是可以把这些逻辑问题先暴露出来。

1.2 仿真不是画个好看画面那么简单

很多人以为组态仿真就是用组态王画几个泵、几根管子，然后让画面动起来。真做起来会发现，组态王仿真项目的难点不在画面，而在逻辑。你要让系统在模拟条件下真的跑起来：温度传感器值会随时间变化，PID调节器要根据偏差自动调节阀门开度，冷水机组要根据运行时间或者负荷自动加减载。这些逻辑如果在仿真里跑不通，接上真设备大概率也跑不通。

这个仿真项目的意义，说白了就是先把控制策略验证一遍。冷冻水出水温度超过设定值之后，是应该先调冷水机组出力，还是先调水泵频率？冷却水泵和冷水机组之间有没有执行严格的联锁关系？冬天过渡季节冷却塔什么时候可以停？这些策略性问题，靠文字描述永远说不清，写进脚本、跑出曲线、看到阀门在正确时机开大关小，逻辑对不对就一目了然了。而且对于刚入行的工程师来说，在仿真环境里把控制逻辑玩明白，比直接去现场改程序安全得多，效率也高得多。

1.3 组态王6.55在这个项目里担什么角色

组态王作为上位机组态软件，在项目里承担三层工作。第一层是人机界面，提供设备流程图、运行状态、趋势曲线、报警窗口这些直观展示；第二层是数据中转站，通过驱动和PLC或者模拟设备交换数据，在开发环境里用仿真PLC或者脚本模拟真实数据采集；第三层是逻辑运算平台，用命令语言写定时任务、数据改变触发任务，实现自动控制功能。6.55这个版本在脚本语法、报警管理、趋势控件、报表功能上相对成熟，做中小型机房监控仿真足够用了。

我这次选择组态王而不是脚本语言加前端框架来做仿真，原因很简单：组态软件本身就是干这个的，变量管理、图形动画、历史数据存储这些能力都已经封装好了，我可以把精力集中在控制逻辑上。整个项目做下来，你会发现从新建工程到最后仿真运行，路径非常清晰：先定义变量，再搭画面，然后写脚本，最后运行调试，每一步都可以独立验证。

2. 工程搭建与变量体系设计

2.1 新建工程时的几个习惯

打开组态王6.55之后，第一步新建工程，我习惯把工程路径设置成纯英文，比如D:\HVAC_Sim，工程名也用英文，项目描述里写中文说明。这样做不是矫情，组态王虽然对中文路径支持得越来越好，但在历史数据存储、报表导出、外部接口调用的时候，偶发编码问题确实存在，英文路径能避开的坑尽量避开。

开发环境里默认的演示画面可以先不用管，新建工程后会生成一个初始画面，我自己建了一个主画面叫“冷冻站总览”，把工程类型设成“模拟运行”，这样在没有真实PLC的情况下可以直接用内存变量跑逻辑。组态王6.55的“工程浏览器”界面里，左侧树形菜单管理着变量、画面、命令语言、设备、报警、报表等所有资源，这个结构一定要熟悉，后面所有操作都从这儿进。

2.2 变量类型选型与命名规范

变量是组态系统里最核心的东西，等于控制系统的“数据库”。组态王变量分I/O变量和内存变量两大类，I/O变量需要和外部设备通信，内存变量只在本机内部使用。在纯仿真阶段，我建议先把所有传感器和执行机构都定义成内存变量，用脚本模拟变化，后面接真实PLC的时候再改成I/O变量，修改成本很低。变量类型又分离散、整型、实型、字符串等，离散对应开关量，实型对应模拟量，选择不对后面做动画连接和脚本运算都会出问题。

我按系统功能做了变量规划，核心变量是温度和压差等过程值，这些要用实型；泵、阀、机组状态是开关量，用离散型；PID输出和阀门开度是百分比，用整型或实型都行。变量命名上我用了“区域_设备_属性”的格式，比如FRZ_WT_SUP表示冷冻水供水温度，COOL_PUMP_A_RUN表示冷却水泵A运行状态。这样命名有两个好处：一是写脚本的时候变量名能看出物理含义，二是做数据归档和报表统计时筛选非常方便。

定义变量的时候一定注意“变化灵敏度”这个参数，它代表变量值变化多少个单位时才记录一次。仿真阶段模拟的高频微小波动可能会让历史趋势曲线看起来非常毛糙，我把过程变量的变化灵敏度设成0.1，既不会漏掉有意义的变化，又不会把无谓的噪声全存进去。另外每个过程变量最好都设置合理的初始值，比如冷冻水供水温度初始7℃，回水12℃，这样工程一启动画面上的数据就是有意义的，不会全是0。

2.3 用脚本模拟传感器信号变化

不连PLC的情况下，需要自己模拟传感器信号。最直接的办法是写一段周期执行的命令语言，让关键温度随时间变化。我用了“应用程序命令语言”里的“运行时”周期执行，周期设为1000毫秒，脚本里让冷冻水回水温度在12℃上下波动，模拟末端负荷变化：

// 模拟冷冻水回水温度：基础值12度，叠加正弦波和随机扰动 \本站点\FRZ_WT_RET = 12.0 + 1.5 * sin(\本站点\Sim_Time * 0.05) + (\本站点\Sim_Noise - 0.5); // 模拟冷却水回水温度：和机组运行状态相关 if (\本站点\CHILLER_A_RUN == 1) { \本站点\CLD_WT_RET = 30.0 + 1.2 * sin(\本站点\Sim_Time * 0.03); } else { \本站点\CLD_WT_RET = 26.0; }

这里用到的Sim_Time是自己在数据词典里建的内存实型变量，每周期加0.01，相当于仿真时钟。Sim_Noise是随机扰动变量，用组态王的随机函数生成。这么做的目的是让趋势曲线看起来像真实系统，而不是一根笔直的线段。你在调试控制逻辑时，希望看到传感器值有小幅度连续变化，这样才能判断PID调节方向对不对，有没有超调，响应快不快。

3. 监控画面设计与动画连接

3.1 画面分区要符合操作员的使用习惯

画面设计不是越炫越好，操作员看这个画面的核心诉求是：一眼就知道系统现在正不正常，异常时能找到控制按钮。我的主画面采用四分区布局。左侧是整个冷冻站工艺流程图，泵、阀、机组按实际位置布置，管路用粗线条连接；右上区域是操作控制面板，放启停按钮、设定值输入框、模式切换开关；右下区域放关键参数实时显示和报警摘要；顶部的横向区域留作趋势曲线和运行统计的切换入口。

画设备图标有个经验：先把所有泵、阀、机组做成“图库”里的元件，之后多个画面复用。组态王自带图库里有泵和阀门的基本图形，但细节不够，我习惯用基本图元自己拼一个简化图标，比如冷冻水泵用圆形加箭头，阀门用三角形加调节杆，机组用矩形加型号文字。这样整个画面的设备看起来风格统一，操作员培训时也好认。

3.2 动画连接：让画面会“说话”

动画连接是组态画面最基础也最容易出问题的一步。它的原理很简单：画面对象的某个属性绑定一个表达式，表达式值变了，属性跟着变。比如泵的运行状态绑定动画，运行时图标填充成绿色，停止时灰色；管道的流量用一组小短线移动来表示，流动速度绑定流量值；阀门开度用对象的“填充”属性绑定阀门开度百分比。

这里有个实操细节，组态王的填充动画是基于对象内部基准位置的，画阀门主体时必须保证基准点在填充方向的边缘，否则开度显示会反向或者不全。我刚开始做的时候阀门开度显示总是从50%直接跳到100%，后来查了半天发现是基准位置设错了。解决方式是在图库编辑器里重新设置对象的锚点，确保填充方向是从左到右或者从中心向两侧展开。每个动画连接做完，验证方法是在数据词典里手动改变量的值，观察画面有没有正确响应，这步一定不能省。

3.3 控制按钮和输入限制

控制面板里的按钮，我用的是组态王的“按钮”对象，关联一个内存离散变量的“按下”动作。按钮表面文字要同时标明设备和动作，比如“冷冻水泵A启动”“冷冻水泵A停止”。操作上有个讲究：启动按钮和停止按钮要分别做成两个按钮，不要用一个切换按钮。原因是操作员习惯看到明确的状态指令，而不是自己去猜当前按一下是启动还是停止。

数值输入框用来输入温度设定值、压差上限、PID参数等，绑定对应变量的“值输入”连接。值输入连接有个容易被忽略的参数：上下限。我把冷冻水供水温度设定值的输入范围限制在5℃到15℃之间，PID积分时间限制在1到600秒之间，超过范围直接拒绝输入。这个限制虽然简单，但能避免很多误操作事故，在现场系统里尤其重要，一个错误设定值可能导致整个冷冻站运行异常。

4. 控制逻辑与脚本实现

4.1 启停顺序控制：机组保护的第一道防线

中央空调系统的启停顺序是有严格逻辑的，理由也很简单：如果冷水机组已经启动了，冷冻水泵还没工作，蒸发器里的水不流动，会导致蒸发温度过低，严重时候冻裂蒸发器；如果冷却塔没开，冷却水温度过高，冷凝器压力会飙升，机组高压报警甚至跳机。所以启动顺序必须是冷冻水泵先启动，冷却水泵随后启动，冷却塔风机再跟上，最后才允许冷机启动。停机顺序相反，先停冷机，再停冷却塔风机和冷却水泵，最后停冷冻水泵。

在组态王里我用命令语言实现这个顺序。最稳妥的写法是用一个状态机变量StepState表示当前处于启动过程的第几步，每一步有条件进入下一步。贴一段启动顺序的简化脚本：

// 启动按钮按下，且系统当前停机状态 if (\本站点\StartBtn == 1 && \本站点\SysState == 0) { \本站点\StepState = 1; \本站点\SysState = 1; \本站点\FRZ_PUMP_A_RUN = 1; } // 冷冻水泵启动5秒后，启动冷却水泵 if (\本站点\StepState == 1 && \本站点\FRZ_PUMP_A_RUN == 1) { if (\本站点\Timer_Step1 >= 5) { \本站点\CLD_PUMP_A_RUN = 1; \本站点\StepState = 2; \本站点\Timer_Step1 = 0; } } // 冷却水泵和冷却塔延时后再允许启冷机 if (\本站点\StepState == 2) { if (\本站点\Timer_Step2 >= 10) { \本站点\CHILLER_A_RUN = 1; \本站点\StepState = 3; } }

这里的Timer_Step1和Timer_Step2是定时器变量，在周期执行脚本里每秒加1。实际写的时候不能把定时器递增和顺序判断写在同一个周期脚本的同一位置，否则定时器无法累计。我习惯把定时器递增单独放一段，顺序判断放另一段，逻辑清晰也方便排查。中间延时不是为了好看，冷水机组的油分离器、冷媒系统需要时间建立稳定的压差，直接开机很容易报故障。

4.2 温差、压差调节与简化PID实现

运行逻辑跑通之后，要处理调节逻辑。冷冻水系统最常见的调节对象是压差旁通阀。当末端负荷降低，用户关闭了部分风机盘管或者VAV风阀，冷冻水流量变小，而水泵频率没变时，供回水压差会升高。这时候旁通阀要开大，让一部分冷冻水从供水直接旁通到回水，维持压差稳定，同时保证冷水机组蒸发器有足够的流量。

压差调节我用的是简化PID。组态王自身有PID调节控件，但那个控件更偏回路仪表，在脚本里实现一个数字PID其实更灵活，也更适合教学和调试。数字PID的位置式写法很直接：

// 偏差计算 \本站点\PID_Dev = \本站点\FRZ_DP_SET - \本站点\FRZ_DP; // 积分累计，做限幅防止积分饱和 \本站点\PID_Integral = \本站点\PID_Integral + \本站点\PID_Dev * 0.1; if (\本站点\PID_Integral > 200) \本站点\PID_Integral = 200; if (\本站点\PID_Integral < -200) \本站点\PID_Integral = -200; // 微分项，注意用当前偏差减上次偏差 \本站点\PID_Derivative = (\本站点\PID_Dev - \本站点\PID_LastDev) / 0.1; // PID输出，输出限幅到0-100 \本站点\BYPASS_VALVE_OPEN = \本站点\PID_KP * \本站点\PID_Dev + \本站点\PID_KI * \本站点\PID_Integral + \本站点\PID_KD * \本站点\PID_Derivative; if (\本站点\BYPASS_VALVE_OPEN > 100) \本站点\BYPASS_VALVE_OPEN = 100; if (\本站点\BYPASS_VALVE_OPEN < 0) \本站点\BYPASS_VALVE_OPEN = 0; \本站点\PID_LastDev = \本站点\PID_Dev;

这个脚本里的0.1是采样周期，也就是脚本的执行周期。要注意的是，组态王周期执行脚本如果设成100毫秒，而程序里手动清零或者累加定时器时，要保证和时间基准一致，否则PID参数就乱套了。我这次统一用0.1秒作为PID采样周期，所有定时器也按这个基准调整。

PID参数整定我用的方法是先调Kp后调Ki最后微调Kd。仿真环境下没有真实噪声，所以Kd可以用得很小甚至为0，因为微分项在真实系统里会放大传感器噪声，现场调试时很多人会把Kd拿掉。另外偏差方向和执行机构方向的关系要搞清楚，在这个压差调节场景里，当实际压差高于设定值时，旁通阀要开大，PID输出增大对应阀门开度增大，这是正作用；反过来如果是温度控制冷却水泵频率，回水温度高于设定值时频率要提高，也是正作用。如果做反了，调节回路立刻发散，温度越调越高。

4.3 互锁、防抖与运行保护策略

所有设备之间除了启停顺序，还要有互锁条件。比如冷却水泵没运行时，冷水机组绝对不允许启动；冷却塔风机要至少启动一个，冷却水温度才能可控。这些互锁条件可以在脚本里每次执行时都检查一遍，一旦条件不满足就强制停机。

信号抖动是控制系统里非常常见的现实问题。真实的压力变送器在附近有大功率设备启停时，读值可能瞬跳；接近开关在触点临界时也会频繁通断。仿真环境里没有这个现象，但逻辑里必须考虑。我的处理方式是给所有数字量开入加一个“延时确认”：一个信号持续为1达到2秒以上，才认为真的发生了，否则忽略。脚本里就用定时器累计，reset条件是有信号变0。

温度信号做保护也一样，比如冷冻水供水温度如果低于2℃或者高于12℃，持续10秒，就要触发报警并且降低机组负荷。直接用瞬时值做保护很容易因为干扰误动作，加一个持续时间判断就能滤掉大多数虚假信号。

4.4 群控策略的仿真验证思路

冷冻站群控是比单台启停更高层的控制逻辑，核心是让整个系统按需出力，达到节能效果。常见策略有三种：根据供回水温差调节冷冻水泵频率，维持温差恒定；根据冷却水回水温度调节冷却塔风机台数；根据总负荷估算决定开几台冷机几台水泵。

在仿真环境里验证群控策略特别有意思。我构造了这样一个场景：模拟末端负荷从100%逐渐降到40%，看系统怎么响应。冷冻水回水温度会下降，温差变小，PID输出让水泵频率降低；同时总负荷降到某一台冷机额定容量的70%以下时，群控脚本发出减机指令，先开旁通阀保证冷机最小流量，再停掉一台冷机和对应水泵。这套逻辑如果只看描述好像很简单，实际跑起来会发现很多问题，比如减机时刻的确定标准是什么，加减机的回滞区间怎么设，两台冷机轮换运行的时间累计怎么记录。这些问题在仿真里跑通一遍，拿到现场才会真的稳。

5. 仿真运行、调试与问题排查记录

5.1 手动注入信号驱动控制流程

仿真调试最常用的一种方法，是手动改变量值来模拟外部信号，然后观察控制逻辑的响应。运行工程之后，我打开“数据词典”或者直接用“变量调试”功能，把冷冻水回水温度改成18℃，同时把供回水压差改成预设值的1.3倍，这时候应该看到旁通阀开度在增大，冷却水泵频率开始升高，画面的动画状态也在变化。

这种手动注入的方式效率很高，但要注意组态王运行环境下手动改值是有时效的，下次周期执行脚本可能会覆盖掉。为了稳定测试，我更推荐在命令语言里做一个“仿真场景”功能：一个内存离散变量作为场景1开关，置1时自动把温度、压差、负荷等变量更新为场景预设的一组值，便于反复测试同一场景下的逻辑。比如场景1模拟夏季满负荷，场景2模拟部分负荷，场景3模拟冷却塔故障，每个场景都有一组预设数据。这样调试的时候不用一个一个变量去改，一键切场景，效率高得多。

5.2 趋势曲线、报警与报表配置

趋势曲线是控制效果最直观的验证工具。组态王的实时趋势曲线控件可以绑定多条变量曲线，我把它放到顶部的趋势页面里，同时显示冷冻水供回水温度、冷却水供回水温度、压差和阀门开度。曲线意在使用，比如温度设定值改了之后，能清楚看到回水温度经过多长时间到达新的稳定点，超调量是多大。

历史趋势曲线需要先配置存储，这个很容易漏。数据词典里每个变量都有“记录”属性，必须勾选了记录，历史趋势控件才能读取到历史数据。还要设置记录的方式：定时记录还是变化记录。对温度这种变化较平缓的过程量，我用定时记录，周期1秒钟；对于报警状态这种开关量，变化记录更合适。历史数据存储在组态王工程目录下，默认的存储时间范围要留意，不然长时间运行后磁盘会越来越大。

报警配置上，我给关键模拟量设置了高低限报警，比如冷冻水供水温度上限12℃、下限2℃，冷却水回水温度上限38℃；数字量报警处理的是设备故障状态。报警记录要设置报警组，方便分类查看，同时绑定了报警声音。有一件事必须强调：报警限的触发值要留回差，比如上限12℃，事件型报警触发后要回落到11.5℃才会解除。如果没有回差，测量值在12℃附近波动时，报警会不停地触发、恢复、再触发，操作员会直接疯掉。

表格是排查问题的利器，把仿真运行中遇到的典型问题汇总成速查表，对以后做现场调试也有参考价值。

5.3 常见问题的深层原因与处理思路

上面表格里的问题，处理思路再说细一点。画面动画不流动这个问题，九成原因都是变量引用路径写错了。组态王变量引用格式是“\本站点\变量名”，很多人会打成“\变量名”或者漏掉本站点前缀，编译还不报错，运行画面就是不动。我的排查习惯是优先在“变量调试”里确认变量值有变化，再看动画连接表达式，最后检查基准点。

PID输出饱和的问题更值得聊。仿真中PID输出打到100%一直不回来，通常是因为积分项累积到上限之后没有再释放。这是积分饱和现象，在位置式PID里必须做抗积分饱和处理：当输出达到上限时，停止积分累积甚至做积分退火。脚本里用if判断输出是否超过限幅值，如果是就把积分项往回拉一点。很多PID仿真项目看似能运行，实际输出长期卡死，就是因为没做这一步，一定不要省。

启停顺序乱跳，本质是状态机没有做好闭环。状态机里每一步必须考虑“进入条件”“执行动作”“离开条件”三个要素，同时要防止某个分支把状态拉回去。我加了一个SysState锁定变量，一旦系统进入启动流程就不再响应启动按钮，只有流程完整走完或者触发停止流程时才解除，这样按钮怎么按都不会打乱顺序。

5.4 从仿真到现场还要做的几件事

仿真调试通过，只是万里长征走完第一步。接真实系统的时候，有几个事仿真环境里模拟不了，但必须提前想清楚。一个是真实传感器的信号噪声和响应滞后，仿真里的正弦波干扰是理想化的，现场温度变送器可能有毛刺，压力变送器可能有零点漂移，这些要靠滤波和定期校验解决。另一个是执行机构的物理死区，阀门定位器有最小动作量，变频器有最小输出频率，PID输出在死区内来回震荡会损坏执行器，所以现场PID参数必须根据实际设备重新整定。

从工程实施角度，仿真环境里验证过的画面布局和控制逻辑可以直接复用，但设备地址映射、Modbus寄存器表、IO点表要重新逐点核对。仿真时用内存变量随手定义的点位，到了现场要对应到真实PLC的寄存器地址，这个过程比想象中琐碎，容易出错，我在项目里是专门做了一张点位映射表，一个点一个点过，确保没有遗漏。

项目做完之后留下的几条经验

这个中央空调循环控制系统的组态仿真，做下来最大的体会是：组态软件的价值不在于画了多少好看的画面，而在于把控制逻辑跑通、跑对、跑稳。调试PID的时候，我在仿真环境里反复调参，看到了温度曲线从剧烈振荡慢慢收敛到平稳跟踪，那种感觉挺有成就感的，而且完全不担心把真设备弄坏，这种试错自由是仿真环境独有的。

最后分享一个小习惯：每次修改脚本或者画面之前，我都会把工程做一个完整备份，命名带上日期，比如HVAC_Sim_20250601。组态王的工程备份很简单，整个工程目录压缩一份就行，回滚起来非常快。调试过程中改了一半发现思路错了，直接恢复上一次的备份再继续，能省下大量返工时间。这个习惯在真实项目和仿真项目里都适用，推荐给所有做组态的朋友。