箱变综合智能在线监控系统：四遥、本地联动与断网补传-尧图网站建设

简介：面向电力运维、配电自动化及箱变安全管理人员的《箱变综合智能在线监控系统》产品方案文档，聚焦箱式变电站环境温湿度、烟雾、防盗与设备状态的在线监测，以及风机、空调、灯具等远程控制需求，帮助读者理解“四遥”在低压配网场景中的落地方式。压缩包共1个doc文件，约2.2MB，内容为完整的产品介绍与系统方案，便于直接查阅和二次整理。文档围绕站端系统、软件平台和移动客户端三部分展开，涉及配电房一体化监控装置HT500 Plus的处理器、接口配置、人机界面与离线联动能力，并覆盖实时监测、系统控制、告警记录、历史数据查询、视频联动抓拍、电子地图和3D情景展示等模块。已有649人学习下载，可作为箱变监控方案选型、技术标书编写、运维培训与功能对照的参考材料。

1. 从一次箱变高温告警说起：这套系统到底解决什么问题

某运维班组在夏天接到一条告警：箱变内温度逼近 45℃，空调没开，柜内二次元件已经出现误动作。赶到现场开门散热、手动合上空调，前后折腾两个小时。这类场景在箱式变电站里并不少见，箱变空间小、散热差、长期无人值守，靠定期巡检根本压不住。箱变综合智能在线监控系统要解决的就是这件事：把箱变环境监测里的温湿度、烟雾、水浸、门禁红外这些信号，连同设备状态、视频画面一起采上来，做到遥测、遥信、遥控、遥调的“四遥”，温度超过 35℃ 自动启空调，SF6 泄漏自动开风机，风机远程控制不用再跑现场。这套方案适合正在做电力监控方向毕设或课程设计的同学，也适合要给配电室、环网柜、分支箱出一版可交付方案的从业者。

2. 需求拆解与技术选型：为什么用“站端 + 平台 + 移动端”三层分布式架构

2.1 从“四遥”反推功能清单与监测点

“四遥”这个词在电力监控方案里出现频率很高，但很多文档只把它写成一句口号，没有落到具体信号上。我的做法是先把它拆成四张清单，再拿清单去凑硬件。遥测对应连续量：箱变内温度、湿度、电缆夹层水位、SF6/O2 浓度、三相电压电流功率、风机与空调的运行电流。遥信对应开关量：门禁磁簧、红外双鉴、水浸探头、烟感、断路器位置、风机故障反馈。遥控对应可下发的启停命令：风机、灯光、空调、水泵、除湿机，以及摄像机的 P/T/Z。遥调对应参数下发：告警阈值、温度设定值、联动规则的启停标志。

拆完这四张清单，监测点的数量基本就定下来了。一个标准箱变站点，环境量六到十个，安防量四到八个，设备状态量八到十六个，控制回路四到六路，视频一到四路。清单直接决定站端装置需要多少路 DI/DO、多少路 RS485，也决定平台侧数据表要开哪些字段。不做这一步，后面选型只能拍脑袋，要么接口不够用，要么花冤枉钱买冗余。

提示：把四遥清单做成一张表，每行写清点位名称、信号类型、量程、告警阈值、联动对象。这张表后面点位表、数据库字段、验收单都要复用，改一处要同步改三处。

2.2 三层架构的职责边界与通信链路

系统按分布式、模块化拆成站端系统、软件平台、移动客户端三部分。站端系统部署在箱变低压侧，负责接传感器、接视频、本地显示、本地联动、断网缓存；软件平台基于 PC WEB，负责统一存储、告警推送、电子地图、报表和权限；移动端负责移动 WEB 和 APP 的看数与控数。三层的边界要划清楚，否则联调时容易互相推责任：站端说平台没下发，平台说站端没上报，最后查半天是协议字段对不上。

通信链路是这条架构的血管。有光纤的站点走光纤，没有敷设条件的走 4G/5G 无线，站端装置同时具备千兆以太网口和无线模块。上行协议用 MQTT 或 HTTP 都能做，关键是把“断网”当常态来设计：站端本地联动不依赖平台，平台侧要有断点续传和数据补召。我一般要求站端至少缓存七天的遥测和告警，网络恢复后按时间戳补传，避免平台曲线上出现“中间断一截”的尴尬。

还有个容易被忽略的点：各个站点子系统要能独立运行。管理中心看到的是汇总视图，但某个站点网络断了，这个站点的本地报警、本地联动、本地录像必须照常工作。这一条在验收时是要专门拔网线测的，不是写在文档里就算数。

2.3 核心装置选型：Cortex-A9 与多路 IO 的取舍

站端核心是一台配电房一体化监控装置，输入里给的配置是工业级 Cortex-A9 双核/四核处理器，带硬件编解码，支持 4 路高清 IPC 接入和 4 路视频实时预览、存储、回放。这个规格放在箱变场景里是够用的，因为箱变不是大型变电站，视频路数通常不超过 4 路，算力主要花在编解码和多路传感器轮询上，不在复杂算法上。

选型时我习惯拿一张需求对照表逐项打勾，避免被销售话术带偏：

这张表里最容易被低估的是本地触摸屏。很多方案为了省成本把屏砍掉，结果现场调试只能抱着笔记本插网线，巡检人员想看实时数据还得打电话问后台。7 英寸工业触摸屏看着不起眼，但它承担的是参数设置、状态监测、设备控制、视频预览回放、报警记录查询这些现场动作，属于“平时不用、用起来离不开”的部件。

另一个取舍是 DI/DO 的扩展方式。8 路 DI 对普通箱变够用，但环网柜、开关站这种点位多的场景就不够了，所以要选支持扩展到 24 路的型号。扩展不是简单加板卡，还要看装置固件是否支持扩展后的地址映射，否则点位表编到第 9 路就找不到对应寄存器。这一条在选型阶段问清楚，比后期换设备省事得多。

3. 站端系统设计：传感器接入、采集器扩展与本地联动怎么落地

3.1 环境与安防监测点位表

站端设计的第一步不是画图，是把点位表定死。点位表里每个点都要有唯一的点位编码，编码规则我一般用“站点编号-设备类型-序号”，比如 01-ENV-03 表示 1 号站点的第三个环境量。编码一旦定下来，接线、组态、数据库、告警规则全用它，后期排查时看到编码就能定位到物理位置。

下面是一个典型箱变站点的点位表片段：

| 点位编码 | 点位名称 | 信号类型 | 接口 | 量程/状态 | 告警阈值 | | 01-ENV-01 | 箱变内温度 | 4～20mA | AD1 | -20～80℃ | 高 35℃ | | 01-ENV-02 | 箱变内湿度 | 4～20mA | AD2 | 0～100%RH | 高 85%RH | | 01-ENV-03 | 电缆夹层水位 | 开关量 | DI1 | 有/无 | 有水位即告警 | | 01-ENV-04 | 烟感 | 开关量 | DI2 | 正常/报警 | 报警即联动 | | 01-SEC-01 | 门禁磁簧 | 开关量 | DI3 | 开/关 | 布防时开即告警 | | 01-SEC-02 | 红外双鉴 | 开关量 | DI4 | 正常/触发 | 触发即抓拍 | | 01-SEC-03 | 水浸探头 | 开关量 | DI5 | 正常/浸水 | 浸水即联动 | | 01-CTL-01 | 风机启停 | 开关量输出 | DO1 | 启/停 | 由联动规则驱动 | | 01-CTL-02 | 空调启停 | 开关量输出 | DO2 | 启/停 | 温度高 35℃ 启动 |

点位表定完之后，接线表跟着出，每个点位对应哪个端子、哪根线、什么颜色，全部写清楚。现场施工最怕“线接完了不知道哪根是哪根”，有了接线表，两个人一天能接完一个标准站。

3.2 RS485 总线扩展 128 路采集器的接线与编址

箱变里传感器分散在不同柜格，全部拉回主装置不现实，通常用 RS485 总线挂采集器，再由采集器接传感器。输入里给的能力是最多支持 128 路环境参数采集器，这个数量对一个中型配电室足够，但总线一长，编址和终端电阻就得讲究。

编址我一般按“总线号-采集器地址”两级来管，地址从 1 开始连续编，不跳号。跳号看着省事，后期换采集器时容易和新地址冲突。下面是一段扫描总线上在线采集器的脚本，调试阶段用来确认编址有没有重复：

# 扫描 RS485 总线上在线的采集器，确认地址无重复、无掉线 import serial import time def scan_bus(port="/dev/ttyS1", baudrate=9600, addr_range=range(1, 33)): online = [] ser = serial.Serial(port, baudrate, timeout=0.3) for addr in addr_range: # Modbus RTU 读保持寄存器，功能码 0x03，起始地址 0x0000，读 2 个寄存器 frame = bytes([addr, 0x03, 0x00, 0x00, 0x00, 0x02]) crc = crc16(frame) frame += bytes([crc & 0xFF, crc >> 8]) ser.write(frame) time.sleep(0.05) resp = ser.read(9) if len(resp) == 9 and resp[0] == addr: online.append(addr) ser.close() return online def crc16(data): crc = 0xFFFF for b in data: crc ^= b for _ in range(8): if crc & 0x0001: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 return crc if __name__ == "__main__": result = scan_bus() print("在线地址:", result) dup = [a for a in set(result) if result.count(a) > 1] print("重复地址:", dup if dup else "无")

这段脚本做三件事：按地址逐个发 Modbus RTU 读寄存器请求，收到合法应答就记为在线，最后统计有没有重复地址。port改成实际串口，baudrate要和采集器出厂设置一致，addr_range按项目实际编址范围改。扫描结果和点位表对不上，就说明现场有采集器没接线、地址拨错或者终端电阻没接。

总线布线还有两条经验：一是手拉手串联，不要星型分叉；二是在总线最末端接 120Ω 终端电阻，距离超过 100 米时降波特率到 4800。这两条不做，表现出来的现象是“白天好好的，晚上数据乱跳”，查起来非常费劲。

3.3 本地联动逻辑：断网时也要能启风机、开空调

这套系统最值得写进方案的一点，是本地联动不依赖平台。站端装置自己跑联动逻辑，监控主机与远程服务器通信中断时，控制主机仍能离线实现水泵、风机的联动控制。实现方式是把规则引擎放在站端，输入是本地点位，输出是本地 DO，平台只负责下发规则和收结果。

下面是一段站端联动逻辑的简化实现，覆盖温度越限启空调、SF6 泄漏启风机、水浸启排水三个典型场景：

# 站端本地联动引擎：不依赖平台，断网时照常执行 from datetime import datetime # 联动规则表，实际项目从本地配置文件加载 RULES = [ {"id": "R01", "point": "01-ENV-01", "op": ">", "threshold": 35, "action": "DO2", "action_desc": "启动空调", "delay_s": 10}, {"id": "R02", "point": "01-ENV-05", "op": ">", "threshold": 1000, "action": "DO1", "action_desc": "启动风机", "delay_s": 5}, {"id": "R03", "point": "01-SEC-03", "op": "==", "threshold": 1, "action": "DO4", "action_desc": "启动给排水", "delay_s": 0}, ] def evaluate(point_values, do_states, now=None): now = now or datetime.now() actions = [] for rule in RULES: val = point_values.get(rule["point"]) if val is None: continue hit = (rule["op"] == ">" and val > rule["threshold"]) or \ (rule["op"] == "==" and val == rule["threshold"]) if hit and do_states.get(rule["action"]) != 1: actions.append({ "rule_id": rule["id"], "action": rule["action"], "desc": rule["action_desc"], "ts": now.isoformat(), "reason": f'{rule["point"]}={val} 触发阈值 {rule["threshold"]}' }) return actions # 调用示例：温度 36.2℃，空调当前关闭 if __name__ == "__main__": values = {"01-ENV-01": 36.2, "01-ENV-05": 0, "01-SEC-03": 0} states = {"DO1": 0, "DO2": 0, "DO4": 0} for act in evaluate(values, states): print(act) # 实际项目中这里调用 DO 输出接口，并写本地操作记录

RULES里每条规则包含监测点、比较符、阈值、动作 DO、动作描述和延时。evaluate只做判断，不直接写 DO，把“判断”和“执行”分开，是为了方便加防抖和互锁。delay_s在实际项目里用定时器实现，避免温度在阈值附近抖动导致空调频繁启停。执行动作后要写一条本地操作记录，记录触发规则、触发值和时间，这条记录在断网恢复后要补传到平台，否则平台侧的告警链条是断的。

注意：联动规则一定要加互锁。比如 SF6 泄漏启风机的同时要禁止启动空调，水浸报警启排水的同时要切断相关区域电源。互锁不写在代码里，现场就会出现“该停的没停、该启的全启”的混乱场面。

3.4 视频接入与联动抓拍

视频部分输入里给的是支持 4 路高清 IPC 接入、4 路实时预览存储回放，具备硬件编解码。站端接 4 路摄像头，一路对着箱变门，一路对着柜内，一路对着通道，一路备用。平时按计划录像，触发报警时做联动抓拍，抓拍的是闯入时刻前后各一段，不是只抓一张图。

联动抓拍的配置要点有三个：预录时间、抓拍时长、上传策略。预录时间我一般设 5 秒，抓拍时长 30 秒，先存本地再按网络情况上传。网络差的时候只传抓拍片段和关键帧，不传整段录像，否则 4G 流量很快爆掉。站端支持 GPRS 远传到服务器或终端设备，这个能力在无固网的站点很实用。

视频和开关量的联动关系要写在规则表里，不要写死在代码里。比如“红外双鉴触发 → 对应通道摄像机启动录像 + 声光报警器”，这条规则在平台侧可配，站端执行。规则可配的好处是，不同站点摄像头位置不一样，现场调一次就能用，不用改程序。

4. 软件平台与移动端：数据模型、告警引擎与展示层

4.1 数据表设计与四遥数据模型

平台侧的数据模型要围绕“点位”来建，而不是围绕“设备”来建。设备会换、型号会变，点位编码是稳定的。核心表我一般分五张：站点表、设备表、点位表、遥测历史表、事件表。下面给出关键三张的建表语句：

-- 站点表：一个箱变/配电室一行 CREATE TABLE station ( station_id VARCHAR(16) PRIMARY KEY, -- 站点编号，如 01 station_name VARCHAR(64) NOT NULL, -- 站点名称 address VARCHAR(128), -- 安装位置描述 online TINYINT DEFAULT 0, -- 在线状态 0离线 1在线 updated_at DATETIME ); -- 点位表：四遥清单的数据库映射 CREATE TABLE point ( point_code VARCHAR(32) PRIMARY KEY, -- 点位编码，如 01-ENV-01 station_id VARCHAR(16) NOT NULL, point_name VARCHAR(64) NOT NULL, point_type VARCHAR(8) NOT NULL, -- YC遥测 YX遥信 YK遥控 YT遥调 unit VARCHAR(16), -- 单位，如 ℃、%RH high_limit DECIMAL(10,2), -- 高限阈值 low_limit DECIMAL(10,2), -- 低限阈值 enabled TINYINT DEFAULT 1, INDEX idx_station (station_id) ); -- 遥测历史表：按时间分区，实际项目按月分表 CREATE TABLE telemetry ( id BIGINT AUTO_INCREMENT PRIMARY KEY, point_code VARCHAR(32) NOT NULL, value DECIMAL(12,4) NOT NULL, quality TINYINT DEFAULT 0, -- 0正常 1可疑 2无效 collect_time DATETIME(3) NOT NULL, INDEX idx_point_time (point_code, collect_time) );

point_type用四个枚举值区分遥测、遥信、遥控、遥调，查询时按类型过滤。quality字段很多人会省掉，但现场传感器掉线、读数超量程是常事，没有质量位，历史曲线里就会混进一堆假数据。collect_time用毫秒精度，是为了断网补传时能按时间排序，不至于同一秒内多条数据顺序错乱。

历史表的数据量要提前算。一个站点 30 个遥测点，5 分钟采一次，一天 8640 条，一年 315 万条。十个站点就是三千万条，不做分区查询会明显变慢。我的做法是按月分表，查询时先定位月份，再查具体表。

4.2 告警阈值与联动规则配置

告警阈值不能写死在代码里，要能按站点、按季节调整。夏天箱变温度高限可以设 35℃，冬天可以放宽到 40℃，这些都应该在平台上配。规则配置我一般用 JSON 存，平台下发到站端，站端本地也存一份，断网时用本地这份。

{ "station_id": "01", "rules": [ { "rule_id": "R01", "point_code": "01-ENV-01", "condition": "value > 35", "level": "warning", "action": ["DO2"], "message": "箱变内温度越限，已启动空调", "delay_s": 10, "enabled": true }, { "rule_id": "R02", "point_code": "01-ENV-05", "condition": "value > 1000", "level": "critical", "action": ["DO1", "DO5"], "message": "SF6 浓度越限，启动风机与声光报警", "delay_s": 5, "enabled": true } ] }

condition用表达式而不是固定字段，是为了支持“大于、小于、等于、区间”多种判断。level分 warning 和 critical 两级，对应不同的推送方式和颜色。action是动作 DO 列表，支持一对多。delay_s是防抖延时，避免瞬时越限就动作。这份配置在平台改完后要能一键下发，站端收到后热加载，不用重启装置。

告警记录要完整，输入里写得很清楚：每条告警记录事件性质、事件对象、事件内容、发生时间、事件原因及描述信息。这五个字段缺一个，后期回溯都说不清。我还会额外加一个“确认人”和“确认时间”，用于区分“已处理”和“未处理”。

4.3 移动端与 3D 情景页面

移动端不是把 PC 页面缩小，而是重新组织信息层级。运维人员在外面最关心三件事：当前有没有告警、哪个站点、能不能远程处理。所以移动端首页应该是告警列表加站点状态，点进去才是环境曲线、设备控制、视频预览。输入里给的移动端功能包括环境安全监测、设备控制、曲线查询，这三块对应三个底部 tab，结构是合理的。

3D 情景页面是站端触摸屏上的亮点功能，用 3D 方式展示空调、风机、除湿机、烟雾传感器、摄像机等设备的位置和状态。做这个页面要注意两点：一是设备图元要和点位编码绑定，点图元能查到实时值；二是状态颜色要统一，正常绿色、告警红色、离线灰色，不要一个页面一套配色。3D 场景本质上是电子地图的一种，输入里提到的电子地图功能——图片导入、图元添加、设备信息查看、告警提示——这套逻辑可以复用。

视频监控页面支持多画面分割、全屏、图像信息叠加，叠加内容包括时间、地点、名称。这些信息要能配置开关，不是所有场景都需要叠加，比如对外展示时可能要关掉。

4.4 历史数据查询与报表导出

历史数据查询要支持组合条件，输入里要求按不同组合条件查询、曲线展示、告警列表展示、关联录像和照片查看、Excel 导出、报表打印、录像回放按通道和时间检索。这些功能落到实现上，核心是查询接口要能拼条件，不要给每个组合写一个接口。

-- 按站点、点位、时间范围查遥测曲线，配合前端做降采样 SELECT point_code, value, collect_time FROM telemetry WHERE point_code IN ('01-ENV-01', '01-ENV-02') AND collect_time BETWEEN '2025-06-01 00:00:00' AND '2025-06-02 00:00:00' ORDER BY collect_time ASC; -- 告警列表查询，关联站点名称 SELECT e.id, e.point_code, p.point_name, e.level, e.message, e.occur_time, e.confirm_user FROM event e LEFT JOIN point p ON p.point_code = e.point_code WHERE e.station_id = '01' AND e.occur_time >= '2025-06-01' ORDER BY e.occur_time DESC;

第一条查询返回原始点，前端画曲线时如果点数太多要做降采样，否则浏览器会卡。第二条查询带LEFT JOIN，是因为有些告警点位可能已经被删除，但告警记录要保留，用左连接不至于丢记录。导出 Excel 时我一般限制单次最多一万行，超过就提示缩小时间范围，避免服务端内存被打爆。

报表这块，输入里要求支持 Excel 导出备份、输出成报表并可打印。实际项目里我会做两张固定报表：日报（当天告警统计、越限次数、设备动作次数）和月报（站点可用率、告警趋势、TOP 故障点位）。固定报表比自由查询更常用，运维班组每天看的就是这两张。

5. 避坑与排查：这套系统最容易翻车的五个点

5.1 传感器读数漂移，曲线越走越偏

现象是温湿度曲线白天正常，运行一两个月后整体偏高或偏低，和手持表对不上。原因多半是传感器长期工作在高温高湿环境，探头老化，或者 4～20mA 回路供电不稳导致零点漂移。解决分三步：先用手持标准表在探头位置比对，确认是传感器问题还是采集通道问题；再检查 AD 通道的供电和屏蔽线接地；最后在平台侧加一个“校准偏移量”字段，允许按点位做软件补偿，补偿值记录在案，下次比对时能追溯。

5.2 联动误动作，风机空调频繁启停

现象是温度在阈值附近时，空调一会儿开一会儿关，风机也跟着抖。原因是规则只写了单边阈值，没有回差，也没有防抖延时。解决是给每条规则加回差和延时：启动阈值 35℃，停止阈值 33℃，中间 2℃ 的回差；动作前延时 10 秒，确认越限持续存在再执行。回差和延时都要能在平台配置，不能写死在代码里，否则不同站点没法调。

5.3 视频联动抓拍丢帧，关键时刻没录上

现象是红外触发后查录像，发现触发前后几秒是空的。原因通常是预录缓冲没开，或者摄像机的主码流和子码流配置不匹配，站端只存了子码流，回放时清晰度不够又找不到主码流。解决是站端开预录缓冲，至少保留触发前 5 秒；摄像机主码流用于存储，子码流用于预览；抓拍任务单独建一个录像计划，不和常规计划录像混在一起，避免被覆盖。

5.4 通信中断后数据补传，时间戳对不上

现象是断网恢复后，平台曲线中间有一段是平的或者跳变。原因是站端缓存没有统一时基，补传时用了本地时间而不是采集时间，或者补传顺序乱了。解决是站端采集时打毫秒级时间戳，缓存按时间戳排序，补传时带原始时间戳而不是发送时间；平台侧入库前做去重，同一点位同一时间戳只保留一条。这一条在断网演练时必须专门验证。

5.5 权限和操作记录缺失，出事说不清

现象是远程有人误操作合了风机，查日志只有“用户 admin 操作”，不知道是谁、在哪个终端、什么时间。原因是权限只做了登录校验，没做操作审计。解决是按角色分权限，遥控类操作要二次确认，所有控制命令写操作记录表，字段包括操作人、操作终端 IP、点位编码、命令内容、执行结果、时间。这张表在验收和事故回溯时比什么都有用。

6. 怎么验收与答辩：从点位表到联动演练的完整检查清单

验收这件事，很多人理解成“功能点一遍”，真正的分水岭在联动演练。我一般把验收拆成三段：静态核对、断网演练、联动演练。静态核对看三份表——点位表、接线表、告警阈值表，三份表要能互相对上：点位表里每个 DI 都能在接线表里找到端子号，阈值表里每个阈值都能在平台里找到对应配置项。对不上的地方当场记下来，不要等到答辩前再翻。

断网演练是这套系统最值得测的一项。拔掉站端上行网线，制造一次温度越限，看站端是否在本地启动空调、是否在液晶屏上弹出告警、是否把告警缓存下来；恢复网络后，看平台是否把这段时间的数据补传上来，时间戳是否连续。这一项过了，才说明“各个站点子系统独立运行”不是一句空话。

联动演练按场景走，一次只触发一个条件，记录从触发到执行的延迟。下面这张表是我常用的演练记录格式：

答辩时最容易被问的两个问题是“断网了怎么办”和“误报怎么处理”。第一个用断网演练的记录回答，第二个用阈值整定记录和告警确认流程回答。我还会额外准备一份“最坏情况清单”：传感器坏了、摄像头离线、平台磁盘满了，分别是什么表现、怎么恢复。这份清单比功能列表更能体现方案的完整度，评审也爱听。

从那以后我每次带项目，都会在验收前强制走一遍“拔网线 + 单点触发”的流程，哪怕时间再紧也不省这一步。希望帮到你。

本文还有配套的精品资源，点击获取

资讯详情

箱变综合智能在线监控系统：四遥、本地联动与断网补传