在大型机电物联网场景中，中央空调系统（冷热源、水泵、风机、末端）存在两个典型问题：热惯性大 和物理联锁复杂。传统基于云端定时轮询或简单阈值判断的控制方式，往往存在高延迟、易误判的问题。传感器数据带毛刺，控制指令经过云端往返后延迟明显，一旦下发顺序错误或流量过低，轻则机组频繁启停，重则导致蒸发器冻裂、设备停机。
本文介绍一种基于边缘计算架构的"预判 + 直发 + 保护"实现方案，重点讨论数据清洗、负荷预判、联锁控制和变流量安全保护的工程实现。
系统架构与数据流转
以某大型商业建筑中央空调系统为例，整体数据链路如下：
[传感器/设备层]
├── 室内外温湿度、供回水温度、流量、压差
├── 冷冻泵、冷却泵、冷却塔、主机、电动阀
└── 协议：Modbus RTU / Modbus TCP / BA系统私有协议
[边缘计算网关]
├── 多协议接入与解析
├── 数据清洗（滑动窗口 + 3-Sigma）
├── 负荷预判（时间序列模型）
├── 联锁控制（状态机）
├── 安全保护（低流量/压差强制介入）
└── 直发通道：控制指令直接下发至 PLC / 变频器
[云端平台]
├── 运行数据归档
├── 策略配置下发
├── 可视化展示
└── 不直接参与实时控制核心原则是：实时控制不下沉到云端，云端只做策略配置、数据归档和可视化。 边缘侧负责数据采集、清洗、预判、联锁和安全保护，控制指令通过直发通道直接作用于现场设备。
边缘侧数据清洗：剔除传感器毛刺
中央空调现场传感器数据常因通信干扰、设备重启、传感器漂移产生跳变。如果直接用于负荷预判或控制，会导致算法误判。常用做法是结合滑动窗口滤波和**3-Sigma（拉依达准则）**进行异常值剔除。
示例实现如下（Python）：
import numpy as np
from collections import deque
class SensorCleaner:
"""传感器数据清洗：滑动窗口 + 3-Sigma 异常剔除"""
def __init__(self, window_size: int = 20, sigma_threshold: float = 3.0):
self.window_size = window_size
self.sigma_threshold = sigma_threshold
self.buffer = deque(maxlen=window_size)
def update(self, value: float) -> float | None:
"""
输入原始采样值，返回清洗后的有效值。
若数据量不足或判定为异常，则返回 None。
"""
if not np.isfinite(value):
return None
self.buffer.append(value)
# 数据量不足时，暂不执行 3-Sigma 判断
if len(self.buffer) < 5:
return value
data = np.array(self.buffer)
mean = np.mean(data)
std = np.std(data, ddof=1)
# 标准差过小时，避免除零或误判
if std < 1e-6:
return value
z_score = abs(value - mean) / std
if z_score > self.sigma_threshold:
# 判定为异常跳变，使用窗口均值替代
return float(mean)
return value这段代码的工程含义是：
- 滑动窗口保留最近 N 个采样点，避免使用全局历史数据导致响应变慢；
- 3-Sigma用于识别明显偏离当前分布的跳变点；
- 异常值不直接丢弃，而是用窗口均值替代，避免控制链路出现空值；
- 清洗后的数据再进入负荷预判模型，能显著降低误触发概率。
负荷预判：从"事后响应"到"提前调度"
中央空调系统热惯性大，等室内温度升高再调节主机、水泵和阀门，能耗已经产生。因此需要在边缘侧引入负荷预判。
一种可行做法是使用轻量级时间序列模型，例如滑动窗口线性回归、指数平滑或小型 LSTM。工程上更推荐先使用低复杂度模型，例如：
Q_load(t+Δt) = f(
室外温度预测,
室内温度,
室内湿度,
历史冷负荷,
当前供回水温差,
末端阀门开度,
设备运行状态
)边缘侧不需要每次都将数据上传云端再等待返回结果。模型可以部署在边缘计算网关中，按分钟级周期运行。输出结果包括：
- 未来 15~60 分钟冷负荷预测；
- 建议供水温度；
- 建议水泵频率；
- 主机启停建议；
- 冷却塔风机运行建议。
需要注意的是，负荷预判只输出"建议值"，不能直接覆盖安全联锁。最终执行前必须经过联锁校验和安全保护判断。
安全联锁与变流量保护：边缘侧硬保护逻辑
中央空调机房设备存在严格联锁关系。典型启停顺序如下：
- 开机顺序：冷却塔风机 → 冷却泵 → 冷冻泵 → 主机；
- 停机顺序：主机 → 冷冻泵 → 冷却泵 → 冷却塔风机。
如果顺序错误，或冷冻水流量过低，可能导致主机保护停机，甚至蒸发器冻裂。因此，这类逻辑必须运行在边缘侧，不能依赖云端。
以下展示一种基于状态机的联锁与变流量保护实现：
enum SystemState {
STATE_IDLE,
STATE_STARTING,
STATE_RUNNING,
STATE_STOPPING,
STATE_FAULT
};
struct ChillerProtection {
float chilled_water_flow; // 冷冻水实时流量
float chilled_water_flow_min; // 冷冻水流量下限
float diff_pressure; // 供回水压差
float diff_pressure_min; // 压差下限
float diff_pressure_max; // 压差上限
float pump_freq; // 当前水泵频率
float pump_freq_min; // 水泵最低频率
float pump_freq_max; // 水泵最高频率
bool bypass_valve_open; // 旁通阀状态
};
SystemState run_interlock_control(struct ChillerProtection *sys) {
// 1. 低流量保护：优先保证蒸发器安全
if (sys->chilled_water_flow < sys->chilled_water_flow_min) {
sys->pump_freq = sys->pump_freq_min;
sys->bypass_valve_open = true;
return STATE_FAULT;
}
// 2. 压差过低：末端可能缺水
if (sys->diff_pressure < sys->diff_pressure_min) {
sys->pump_freq = increase_frequency(sys->pump_freq);
if (sys->pump_freq > sys->pump_freq_max) {
sys->pump_freq = sys->pump_freq_max;
}
sys->bypass_valve_open = false;
}
// 3. 压差过高：末端需求不足，可降低频率
if (sys->diff_pressure > sys->diff_pressure_max) {
sys->pump_freq = decrease_frequency(sys->pump_freq);
if (sys->pump_freq < sys->pump_freq_min) {
sys->pump_freq = sys->pump_freq_min;
}
sys->bypass_valve_open = true;
}
return STATE_RUNNING;
}这段逻辑的关键点在于：
- 低流量保护优先级最高，一旦触发，立即提升水泵频率并开启旁通阀；
- 压差异常时，系统自动调整水泵频率，而不是等待云端指令；
- 所有保护逻辑运行在边缘侧，即使网络中断，设备也不会失去安全边界；
- 负荷预判输出的频率建议，必须在该保护逻辑校验后才能下发。
控制指令直发：绕过云端，降低延迟
在传统架构中，控制链路通常是：
传感器 → 云端 → 算法 → 云端 → 现场设备这种链路存在两个问题：一是云端往返延迟不可控；二是网络异常时控制链路会中断。对于中央空调这种具有强物理约束的系统，延迟和中断都可能引发设备故障。
更稳妥的实现是：
传感器 → 边缘网关 → 本地算法 → 直发通道 → PLC/变频器云端只负责：
- 下发运行策略；
- 接收归档数据；
- 展示运行状态；
- 提供远程运维入口。
实时控制、联锁判断和安全保护都留在边缘侧。这样即使云端短暂不可用，现场系统仍能维持基本安全运行。
总结
中央空调全链路管控的难点不在界面展示，而在于如何把数据采集、边缘清洗、负荷预判、联锁控制和安全保护串成一条稳定链路。边缘计算的价值主要体现在三点：
- 本地自治：关键控制逻辑不依赖云端；
- 低延迟响应：控制指令通过直发通道直接作用于设备；
- 安全兜底：变流量、压差、联锁等保护逻辑优先于节能策略。
在工程落地中，算法可以迭代，界面可以更换，但底层数据治理和控制链路必须自洽。否则再复杂的节能模型，也难以在真实机房环境中稳定运行。欢迎同行在评论区讨论边缘计算在工控场景中的实现细节。