冷水机组物联网系统能否成功，关键取决于数据采集网关能否把不同品牌 PLC、仪表和电表的数据稳定地送上来：数据要带时间戳、带质量码，断网时也不能丢。工程上应按 “感知 — 边缘 — 网络 — 平台 — 应用” 五层来搭：南向用 Modbus RTU/TCP、BACnet MS/TP、BACnet/IP、OPC UA、S7 等协议接入；网关做点位映射、缩放、字节序转换、边缘告警和本地缓存；北向用 MQTT/TLS（多站点优先 Sparkplug B）上云；平台做时序存储、COP/ACOP 计算、告警工单和远程运维。一个能验收的项目，关键点位覆盖率 100%、数据完整率≥99%、端到端时延≤5 秒、告警准确率≥90%、控制写操作 100% 留痕，比堆大屏功能重要得多。
广州鲁邦通一、五层架构：网关是承上启下的那层
| 层级 | 主要组成 | 关键动作 | 出问题后的表现 |
|---|---|---|---|
| 感知层 | 温度 / 压力 / 流量传感器、电表、冷水机组 PLC、BMS | 测量、采集、本地控制 | 传感器装错，后面全错 |
| 边缘层 | 数据采集网关 | 协议转换、点位映射、缩放、边缘告警、本地缓存 | 网关宕机，数据断档 |
| 网络层 | 以太网、WiFi、4G/5G | 传输、加密、备份链路 | 网络抖动，时延和丢包上升 |
| 平台层 | 物联网平台、时序数据库、规则引擎 | 存储、计算、告警、工单 | 平台不稳，看不见也管不了 |
| 应用层 | 组态大屏、手机端、能效报表、运维工单 | 监控、分析、决策、闭环 | 只看不管，项目没有收益 |
现场调试时间主要花在协议和点位核对上，大屏通常不是重点。电子发烧友的案例里，前端是各品牌冷水机组 PLC，采集压缩机、水泵、冷却塔风机的启停、运行时间、故障报警，以及出水温度、回水温度、冷冻液流量、电压、功率等参数；网关再通过 5G/4G/WiFi/ 以太网把数据送到组态云平台，做组态监控、故障告警、远程控制和运维管理。这条链路里，网关是唯一同时面对 “南向异构设备” 和 “北向标准平台” 的节点。
电子发烧友网二、协议与接口：先解决 “接得进来”
冷水机组现场很少是单一协议。冷机主机可能是 Modbus RTU，楼宇自控可能是 BACnet MS/TP，电表是 Modbus TCP，高端控制器是 OPC UA，日系 PLC 还有 MC/FINS 这类协议。
| 协议 | 典型设备 | 物理层 | 网关要关注的点 |
|---|---|---|---|
| Modbus RTU | 冷机 PLC、电表、温度 / 流量仪表 | RS485/RS232 | 从站地址、寄存器地址、功能码、字节序 |
| Modbus TCP | 电表、PLC、网关 | 以太网 | 端口 502、Unit ID、并发连接数 |
| BACnet MS/TP | 楼宇自控、部分冷机控制器 | RS485 | MAC 地址、对象类型（AI/AV/BI/BV）、对象实例 |
| BACnet/IP | BMS、冷机控制器 | 以太网 | UDP 47808、BBMD、网络号 |
| OPC UA | 高端 PLC、BMS、能源管理系统 | 以太网 | Endpoint、安全策略、证书 |
| Siemens S7 | S7-1200/1500 | 以太网 | Rack/Slot、DB 块地址、优化块访问 |
| Mitsubishi MC / Omron FINS | 日系 PLC | 以太网 / 串口 | 网络号、站号、软元件地址 |
选型时不要只看 “支持 Modbus”。协议转换器、数据采集网关、IoT 网关是三个东西：协议转换器只做 Modbus↔BACnet 这类翻译；数据采集网关要多协议接入、点位建模、边缘计算、断网续传；IoT 网关还要设备管理、OTA、安全接入。采购清单按需求核对，别把协议转换器当数据采集网关买。
Industrial Monitor Direct三、点位清单：必采、选采、控制点分开
冷水机组物联网系统的点位不是越多越好，先分三类：必采（算能效、判故障）、选采（做诊断、做体验）、控制点（能远程写）。
| 类别 | 点位 | 典型来源 | 建议频率 | 用途 |
|---|---|---|---|---|
| 温度 | 冷冻水供水 / 回水温度 | 温度传感器、PLC AI | 5—30 秒 | 算 ΔT、冷量、COP |
| 温度 | 冷却水供水 / 回水温度 | 温度传感器、PLC AI | 5—30 秒 | 算冷凝器趋近温度 |
| 流量 | 冷冻水流量 | 电磁 / 超声波流量计、Modbus | 30 秒 —1 分钟 | 算冷量 |
| 压力 | 蒸发压力、冷凝压力 | 冷机 PLC | 5—30 秒 | 算饱和温度、趋近温度 |
| 电气 | 机组功率、电流、分项电表 | 电表、Modbus | 1—10 秒 | 算 COP、负载率 |
| 状态 | 启停、运行模式、故障代码 | PLC DI / 线圈 | 事件上报或 1 秒 | 状态、告警 |
| 辅机 | 水泵、冷却塔风机状态 | PLC DI | 事件上报或 1 秒 | 系统能效 |
| 环境 | 室外温湿度 | 温湿度传感器 | 1 分钟 | 工况归一化 |
| 诊断 | 振动、油压、制冷剂液位 | 振动传感器、PLC | 1—10 秒 | 预测性维护 |
采样频率要分层。状态和故障用事件上报，温度压力 5—30 秒，流量和电表 30 秒 —1 分钟。不要所有点都 1 秒：10 台机组、每台 200 点、1 秒采集，一天约 1.7 亿条，按每条 50 字节算超过 8GB，流量、存储和平台写入都会被拖垮。72 小时本地缓存、2000 个点位、1 分钟采集，大约 860 万条、430MB；如果全改 1 秒，直接放大 60 倍到约 26GB。网关存储和 SIM 流量要按这个量算，不能拍脑袋。
四、网关选型：七个硬指标
| 维度 | 必选 | 加分项 | 常见坑 |
|---|---|---|---|
| 协议覆盖 | Modbus RTU/TCP、BACnet MS/TP/IP、OPC UA、S7 | 日系 PLC、私有协议驱动、自定义脚本 | 只标 “支持 Modbus”，现场接不了 BACnet |
| 接口 | RS485/RS232、以太网、DI/DO | 4—20mA、脉冲输入 | 接口数量不够，临时加转换器 |
| 边缘计算 | 点位映射、缩放、字节序、阈值 / 变化率告警 | Node-RED、Lua/Python、Docker | 只能透传，所有计算压到云端 |
| 本地缓存 | 72 小时 —7 天、断网续传、原始时间戳 | 环形缓冲区、Parquet / 本地时序库 | 断网即丢，恢复后数据对不上 |
| 安全 | TLS、VPN、ACL、固件签名、默认关闭高危端口 | 安全启动、证书轮换、802.1X | 公网端口映射、默认口令 |
| 运维 | 远程配置、OTA、诊断日志、看门狗 | 批量升级、配置版本管理 | 换一个点位要跑现场 |
| 环境与授权 | 宽温、DIN 导轨、EMC | IP40、防雷、冗余电源 | 按点位收 License，越用越贵 |
一个实用的判断方法是：把点位表发给三家网关厂商，让他们各自给出 “协议 — 接口 — 点位 — 缓存 — 安全” 的逐项响应表。 谁能把 32 位浮点的字序、缩放系数、读写权限、断网续传讲清楚，谁才是真做过冷机项目。
五、边缘计算与数据质量：把 “原始寄存器” 变成 “可信点位”
| 点位 | 寄存器示例 | 类型 | 原始值→工程值 | 单位 | 读写 |
|---|---|---|---|---|---|
| 冷冻水出水温度 | 40001 | INT16 | ×0.1 | ℃ | R |
| 冷冻水回水温度 | 40002 | INT16 | ×0.1 | ℃ | R |
| 冷冻水流量 | 40003—40004 | UINT32 | ×0.01 | m³/h | R |
| 机组功率 | 40005—40006 | UINT32 | ×0.1 | kW | R |
| 启停 | 00001 | BOOL | — | — | R/W |
| 故障复位 | 00002 | BOOL | — | — | W |
| 温度设定 | 40101 | INT16 | ×0.1 | ℃ | R/W |
这张表只是示意，实际地址以厂家点表为准。真正容易出错的是四件事：
- 字节序 / 字序：32 位浮点常见 word swap、byte swap，读出来是乱码；先在网关里读原始值，再用厂家点表核对，不能猜。
- 缩放系数：有的品牌温度 ×1，有的 ×10；Daikin、Trane 这类设备在 BACnet 里的工程单位缩放不一样，写死一个系数一定出错。
- 时间戳：在网关侧打时间戳，不要用云端接收时间；网关要 NTP 对时，断网期间的时间不能漂。
- 质量码：通信失败、越界、冻结值要标 bad/uncertain，平台不能把 “最后一次值” 当 “当前值”。
建议每个点位统一成这个模型：设备ID + 点位名 + 原始值 + 工程值 + 单位 + 时间戳 + 质量码 + 采集周期。平台、告警、能效计算都只认这个模型，换网关、换协议时上层不用重做。
Industrial Monitor DirectCobler六、上云与安全：MQTT 是通道，Sparkplug B 是数据约定
| 方案 | 适合场景 | 优点 | 注意 |
|---|---|---|---|
| HTTP 轮询 | 低频、少量点位 | 简单、易调试 | 高频时开销大，不适合实时遥测 |
| MQTT 原始 JSON | 单站点、小规模 | 轻量、发布订阅 | 点位语义靠约定，换项目容易乱 |
| MQTT + Sparkplug B | 多站点、多设备、点位多 | 统一主题、Protobuf、强类型、NBIRTH/DBIRTH/NDEATH/DDEATH | 网关和平台都要支持 |
| OPC UA | 厂内系统集成 | 信息模型强、安全好 | 跨公网不如 MQTT 轻 |
Sparkplug B 的价值在于 “工业语义”：主题按 spBv1.0/Group/MessageType/EdgeNode/Device 组织，消息用 Protobuf，每个 Metric 带名称、类型、时间戳、工程单位；设备上线发 NBIRTH/DBIRTH，掉线发 NDEATH/DDEATH，平台能知道 “这个网关离线了、它最后有哪些点”。这比裸 MQTT 的 “数据突然不来” 要清楚得多。
HiveMQ网络安全按 “网关是 OT/IT 边界” 来做，不是当普通路由器：
- 4G/5G 用私有 APN/VPDN，只做出站连接，不做公网端口映射、不做 DDNS 暴露 PLC。
- MQTT 走 TLS 8883，QoS 1，设备一机一证书，证书可轮换。
- 远程维护走 VPN / 堡垒机，开前审批、全程录屏、事后审计；能读就不给写。
- 关闭 telnet、默认口令、调试端口；固件签名、安全启动；网关配置变更留版本。
- OT 侧划 VLAN，和办公网、互联网做防火墙隔离；平台侧做 DMZ。
七、能效计算：COP、ACOP、IPLV、kW/ton 别混着用
| 指标 | 定义 | 用在哪 | 注意 |
|---|---|---|---|
| COP | 名义工况下，制冷量 / 输入功率 | 选型、能效等级 | 是 “满负荷、规定工况” 的数 |
| ACOP | 实际运行工况下，制冷量 / 输入功率 | 现场能效监测 | 必须用实测流量、供回水温度、功率 |
| IPLV | 100%/75%/50%/25% 四个负荷点加权 | 评价部分负荷性能 | COP 口径：0.01A+0.42B+0.45C+0.12D |
| kW/ton | 单位冷量功耗，约 3.517/COP | 北美口径、横向对比 | 越低越好，和 COP 反向 |
| 系统能效 | 主机 + 水泵 + 冷却塔风机 | 机房 / 系统级评价 | 主机 COP 高不等于系统省电 |
冷量按 DB11/T 975—2021 的公式算：
Q = qv × ρ × C × (t回水 - t供水) / 3600
其中 qv 是使用侧平均水流量（m³/h），ρ 是水密度（kg/m³），C 是比热（kJ/(kg・℃)），t 是回水 / 供水温度（℃）。举例：流量 200 m³/h、回水 12℃、供水 7℃，ΔT=5℃，Q≈200×1000×4.1868×5/3600≈1163 kW；如果输入功率 220 kW，COP≈5.3，kW/ton≈0.66。
这里最容易被忽略的是误差：5℃ 温差下，温度传感器差 0.5℃，冷量就差约 10%。 所以温度探头要校准、要插到管道中心、要做好保温；流量计要满足直管段，电磁 / 超声波优先，插入式要谨慎。否则平台算出来的 COP 再漂亮，也是假数。
Chillerone国标口径也要对齐：GB 19577—2024《热泵和冷水机组能效限定值及能效等级》把 COP/IPLV 分 3 级，1 级最高；GB 55015—2021 对冷水机组 COP/IPLV 有强制性最低要求。平台做能效看板时，最好把 “名义工况 COP”“实际 ACOP”“IPLV 参考值” 分开显示，不要把设计值当成实时值。
建标库八、告警与预测性维护：从 “超阈值” 升级到 “看趋势”
| 等级 | 典型告警 | 通知方式 | 处置 |
|---|---|---|---|
| A 紧急 | 高压、低压、断水、压缩机过载 | 短信 / 电话 / 平台弹窗 | 立即停机或联锁，通知值班 |
| B 重要 | COP 持续偏低、趋近温度上升、振动上升 | 平台 + 微信 + 工单 | 30 分钟内确认，安排检修 |
| C 提示 | 滤网压差、运行时长、保养到期 | 日报 / 周报 | 计划性维护 |
告警要做三件事：分级、抑制、闭环。同设备同类型 5 分钟内只发一次；根因告警优先，衍生告警折叠；恢复要发 “已恢复”；每条告警带设备、点位、当前值、阈值、建议动作。只发一条 “温度异常” 的微信，运维人员还是要到现场猜。
预测性维护别只盯 COP。更稳的两个指标是：
- 冷凝器趋近温度 = 冷凝饱和温度 - 冷却水出水温度；持续上升，通常是冷凝器脏堵、冷却水流量不足。
- 蒸发器趋近温度 = 冷冻水出水温度 - 蒸发饱和温度；持续上升，通常是蒸发器脏堵、制冷剂不足。
这两个趋势比 “COP 低于 5 就报警” 可靠，因为它们对负荷变化没那么敏感。再加上压缩机电流 / 振动 / 油压的基线对比，才能做 “提前 30 分钟 —48 小时” 的预警。DROME 这类平台就是按 10 秒采集、72 小时本地缓存、30 分钟 —48 小时提前预警来设计的，思路可以借鉴，具体阈值要按自己设备的历史数据标定。
gizantech.com九、控制写操作：可以远程启停，但要按 “安全仪表” 来做
冷水机组物联网系统不能只采不控，也不能一上来就远程写压缩机加载。安全的做法是：
- 网关只写 PLC 的 “设定值 / 远程启停位”，不碰压缩机内部安全逻辑；冷机自身的高低压、防冻、断水保护必须保留。
- 写操作白名单：只允许温度设定、水泵启停、阀门开关这类非安全关键点；压缩机加卸载、故障复位要厂家确认。
- 前置条件：机组处于 “远程允许” 模式、无 A 类告警、操作人有权限、双人确认。
- 写后读回：写入后 3—5 秒读回校验；失败自动回滚；超时告警。
- 全程留痕：谁、什么时候、写了什么、原值、新值、结果、失败原因。
- 控制成功率≥99%，失败回滚 100%，操作日志 100%。
公网直接写 PLC 是大忌。远程控制要走 VPN / 堡垒机，网关侧做白名单和联锁，平台侧做权限和审计；能本地联锁的，绝不只靠云端判断。
十、部署与验收：30 天清单
| 周 | 工作 | 交付物 |
|---|---|---|
| 第 1 周 | 现场勘察：设备品牌、协议、点位表、网络、供电、接地 | 点位清单、网络拓扑 |
| 第 2 周 | 网关安装、协议连通、点位映射、字节序 / 缩放核对 | 点表、网关配置 |
| 第 3 周 | 上云、时序库、组态、告警、工单 | 平台看板、告警规则 |
| 第 4 周 | 试运行、数据质量核查、验收、培训 | 验收报告、运维手册 |
验收不要只看 “大屏能打开”，按这张表打分：
| 指标 | 建议门槛 | 测法 |
|---|---|---|
| 关键点位覆盖率 | 100% | 点表逐点对比实时值 |
| 数据完整率 | ≥99% | 24 小时应到 / 实到条数 |
| 端到端时延 | ≤5 秒 | 设备时间戳 vs 平台入库时间 |
| 时间同步误差 | ≤1 秒 | NTP 对时检查 |
| 告警准确率 | ≥90% | 注入 20 个故障，统计误报 / 漏报 |
| 控制成功率 | ≥99% | 20 次写操作，读回校验 |
| 失败回滚 | 100% | 模拟超时 / 断网 |
| 网关在线率 | ≥99.5% | 连续 30 天 |
| 安全暴露面 | 0 个公网端口 | 外部扫描 |
十一、成本结构与常见问题
| 成本项 | 计费方式 | 备注 |
|---|---|---|
| 网关硬件 | 按台 | 4G/5G 版高于有线版；宽温、防雷加钱 |
| 传感器 | 按点 | 流量计最贵，温度 / 压力次之 |
| 安装调试 | 按点 / 按天 | 老设备改造、停机窗口影响大 |
| 平台 | 按设备 / 按点位 / 年 | 注意 “按点位收 License” 的长期成本 |
| SIM / 流量 | 按 GB / 月 | 高频采集和断网补传都会吃流量 |
| 云资源 | 存储 / 时序库 / 计算 | 原始点 + 聚合点分开存 |
| 运维 | 远程 + 现场 | OTA、备件、巡检、变更 |
| 隐性成本 | 协议驱动、BMS 对接、网络改造 | 最容易超预算 |
常见问题，按出现频率排：
- 把协议转换器当数据采集网关，结果不能上云、不能缓存。
- 点位表没有单位、缩放、字节序，调试全靠猜。
- 所有点 1 秒采集，流量和存储爆炸。
- 断网丢数，时间戳用云端时间，COP 曲线出现假断档。
- 公网端口映射，PLC 直接暴露。
- 告警只发微信，没有分级、抑制、闭环。
- COP 不做工况归一化，不同负荷下直接对比。
- 流量计直管段不够、温度探头不校准，冷量算不准。
- 控制写操作没有联锁、没有读回、没有审计。
- 只看网关单价，不看协议覆盖和远程运维能力。
十二、三条判断
- 先定点位和协议，再选网关。 把设备品牌、协议、点表、采样频率、控制要求列清楚，再让厂商逐项响应；反过来先买盒子，现场一定返工。
- 网关的价值在 “数据质量 + 断网续传 + 远程运维”，不是 “能上云”。 能上云的网关很多，能把坏值标出来、断网不丢、远程能改点位的很少。
- 验收看数据完整率、时延、告警准确率、控制留痕。 大屏炫不炫不重要；数据有洞、告警不准、控制不敢用，项目就是失败的。
【常见问题】
问题 1：冷水机组物联网系统为什么一定要用数据采集网关？
回答 1：冷水机组物联网系统的现场设备可能是西门子、江森、开利、顿汉布什等不同品牌 PLC，协议可能是 Modbus RTU、BACnet MS/TP、BACnet/IP、OPC UA 或厂家私有协议，寄存器地址、数据类型、缩放系数都不一样。数据采集网关的作用是把这些异构数据统一成带设备 ID、点位名、单位、时间戳、质量码的标准模型，再通过 MQTT/TLS 上云；没有网关，平台要么接不进来，要么接进来一堆无法对齐的原始寄存器。
问题 2：冷水机组物联网系统的数据采集网关，Modbus 和 BACnet 怎么选？
回答 2：看设备侧支持什么，不是看平台喜欢什么。冷水机组 PLC 和电表多数支持 Modbus RTU/TCP；楼宇自控和部分冷机控制器用 BACnet MS/TP 或 BACnet/IP。数据采集网关最好同时支持 Modbus RTU/TCP、BACnet MS/TP/IP、OPC UA，并保留私有协议驱动扩展。只有 Modbus 的设备，用 Modbus 网关；只有 BACnet 的，用 BACnet 网关；混合现场选多协议网关，别用两个单协议网关拼，点位和时间戳会对不齐。
问题 3：冷水机组物联网系统采集哪些点位，采样频率怎么定？
回答 3：冷水机组物联网系统的必采点位分四类：温度（冷冻水供回水、冷却水供回水）、流量（冷冻水、冷却水）、电气（机组功率、电流、分项电表）、状态（启停、故障、运行模式、水泵 / 风机状态）。温度压力 5—30 秒一次，流量和电表 30 秒 —1 分钟一次，状态和故障用事件上报或 1 秒一次。不要所有点都 1 秒：10 台机组、每台 200 点、1 秒采集，一天约 1.7 亿条，流量和存储都会失控。
问题 4：冷水机组物联网系统的数据采集网关，断网了数据会丢吗？
回答 4：会丢，除非网关有本地缓存和断网续传。数据采集网关应在本地环形缓冲区保存 72 小时 —7 天的数据，每条记录带原始时间戳和质量码；网络恢复后按时间顺序重传，平台按 “设备 ID + 点位 + 时间戳” 做幂等去重。没有断网续传的网关，4G/5G 一抖动就出现数据断档，COP 和告警都会算错。
问题 5：冷水机组物联网系统上线后，怎么判断数据采集网关选对了？
回答 5：看五个硬指标：关键点位覆盖率 100%、数据完整率≥99%、端到端时延≤5 秒、时间同步误差≤1 秒、网关在线率≥99.5%；再看控制写操作是否 100% 留痕、失败是否 100% 回滚、有没有公网端口暴露。冷水机组物联网系统的网关价值不在 “能上云”，而在数据质量、断网续传和远程运维；大屏好看但数据有洞，项目就是失败的。
【参考资料】
[2026-11-13]（基于数据采集网关的冷水机组物联网系统）电子发烧友网
[2026-09-29]（暖通空调自控行业如何实现 PLC 远程监控与数字化升级）霜蝉科技
[2026-09-01]（制冷系统绩效评价与计算测试方法 中温冷水集中空调系统 编制说明）中国标准化研究院
[2026-08-03]（工厂空压机和冷水机组可视化监控管理方案）物通博联
[2026-07-30]（解决商场冷水机组实时数据采集的边缘计算网关厂商推荐）广州鲁邦通
[2026-07-16]（Integrating Mixed-Vendor and Legacy Systems Into One BMS）Cobler
[2026-06-15]（Industrial IoT Development for Smart Buildings）GizanTech
[2026-06-11]（BACnet to Modbus RTU Gateway: Integrate HVAC to PLC）Industrial Monitor Direct
[2026-05-19]（MQTT Sparkplug B IIoT: The Industrial Standard Your Plant Needs）vNode
[2026-04-16]（Modbus RTU to BACnet/IP Remote Chiller Integration Case Study）Chipkin
[2026-03-12]（How to Calculate Chiller Efficiency）ChillerOne
[2025-02-01]（热泵和冷水机组能效限定值及能效等级 GB 19577—2024）国家市场监督管理总局、国家标准化管理委员会
[2024-03-19]（Powering the Industrial Edge with MQTT）HiveMQ
[2022-01-01]（建筑节能与可再生能源利用通用规范 GB 55015—2021）建标库
[2021-06-22]（冷水机组节能监测 DB11/T 975—2021）北京市标准化管理信息平台
免责声明
本文依据电子发烧友网、霜蝉科技、物通博联、广州鲁邦通、Chipkin、Cobler、GizanTech、Industrial Monitor Direct、vNode、HiveMQ、ChillerOne、中国标准化研究院、GB 19577—2024、GB 55015—2021、DB11/T 975—2021 等公开资料整理，仅用于冷水机组物联网系统与数据采集网关的技术路径、选型和验收参考，不构成工程设计、设备选型、施工或投资建议。文中点位地址、寄存器示例、采样频率、缓存容量、验收门槛均为工程建议或示意，实际项目须以设备厂家点表、现场条件、合同要求和有资质设计单位的方案为准。不同品牌冷水机组的协议、缩放、字节序、控制权限差异很大，涉及远程写操作必须保留机组自身安全保护、做联锁与审计，严禁未经授权通过公网直接控制 PLC。文中引用的厂商案例和产品参数可能随时更新，读者应自行核实最新版本；因使用本文信息造成的任何直接或间接损失，作者不承担责任。