箱变综合智能在线监控系统：四遥闭环、本地联动与验收实践

简介：《箱变综合智能在线监控系统》Word文档面向电力运维、配电室管理及自动化集成人员，聚焦箱式变电站内部温湿度、烟雾、防盗与设备状态的在线监测和远程控制需求，帮助梳理从传感器采集到“四遥”落地的整体方案。文档围绕站端系统、软件平台与移动客户端三部分展开，涉及配电房一体化监控装置HT500 Plus、环境与安防参数监测、风机灯具空调远程启停、告警联动抓拍录像、历史曲线查询及电子地图展示等模块，并说明7/10.1英寸人机界面、通信中断时的本地联动控制与移动端查看方式，对箱变环境监测和风机远程控制场景交代较完整。压缩包内含1个doc文件，大小约2.2MB，便于直接查阅和归档。目前已有649人学习下载，可据此了解系统分层架构、装置接口与联动规则，也能为方案编写、设备选型或运维培训提供功能对照。

1. 箱变监控别再靠人往现场跑：一份 .doc 里的“四遥”闭环

箱式变电站大多散落在路边、小区角落、厂区边缘，一个运维班组管几十个点，靠人巡检一天跑不完三处。箱变综合智能在线监控系统要解决的就是这件事：把箱变环境监测里的温湿度、水浸、烟雾、SF6/O2 浓度变成能远程读到的数，把风机远程控制、空调启停、水泵排水变成能下发的命令，凑成一个遥测、遥信、遥控、遥调的闭环。这份 .doc 不是源码包，是一套完整的方案说明，从站端传感器接线、一体化监控装置的接口清单，一直写到平台功能、移动端界面和联动规则。适合正在做配电房无人值守改造的电气工程师、做系统集成的施工方，以及要给项目写技术方案、需要一份可对照的配置基线的人。它最值钱的地方不是功能列表，是那套“采集—判断—动作—留痕”的链路描述，照着它能把一个现场从图纸落到能验收。

2. 三层架构落地：站端、平台、移动端各接哪一段数据

文档把系统切成站端、软件平台、移动端三块，用的是分布式加模块化的思路。这个切法听着像套话，落到施工上其实是三条清晰的边界：站端负责“拿到真数据并能在断网时自己动手”，平台负责“把几十个站的数据归一、存储、出报表”，移动端负责“人不在机房时能看一眼、能下一个指令”。边界划不清，最常见的后果是联动逻辑写在了平台侧，网一断，风机就不转了。

2.1 站端系统：从传感器到主机的接线与轮询

站端是整个系统的地基。它的物理构成可以拆成四层：传感器层、采集层、执行层、视频层。传感器层是温湿度变送器、水浸绳、烟感、SF6/O2 复合探头、红外双鉴探测器、门磁；采集层是一体化监控装置本身加上 RS485 扩展采集器；执行层是 DO 继电器输出经中间继电器去带动风机、空调、水泵、灯光、除湿机的接触器；视频层是网络高清摄像机接到主机的 IPC 通道或者独立走 PoE 交换机。

接线之前先做地址规划，这一步偷懒，后面调试能让人崩溃。我一般的做法是画一张 Excel 表，把每一路 RS485 挂什么、站号多少、寄存器起始地址多少、量程和单位是什么全部写死，再照着表去配主机。表长这样：

有了这张表，轮询脚本就好写了。现场调试阶段我习惯先用一台笔记本挂到 RS485 总线上做预读，确认每个站号都能应答、数值在合理区间，再去动主机配置，这样能把“传感器坏”和“主机配错”两类问题分开。

# 站端预调试：用笔记本先验证 RS485 总线上的设备是否可读 # 依赖 pip install pymodbus pyserial from pymodbus.client import ModbusSerialClient import time client = ModbusSerialClient( port="/dev/ttyUSB0", # USB 转 485 的串口，Windows 下改成 COM3 之类 baudrate=9600, # 与现场设备一致，长总线优先 9600 而不是 19200 parity="N", # 常见 8N1，部分电表是 8E1，按说明书改 stopbits=1, timeout=1.0, # 单次超时，总线长了要放宽到 1.5~2 s retries=2 # 重试两次，超过就报通信中断 ) def read_holding(slave, addr, count): rr = client.read_holding_registers(address=addr, count=count, slave=slave) if rr.isError(): print(f"站号 {slave} 地址 {addr} 读取失败") return None return rr.registers for slave in (1, 3, 5): # 按地址规划表逐个站号探活 regs = read_holding(slave, 0x0000, 2) print(f"slave={slave} raw={regs}") # 原始寄存器值，先看有没有数再看对不对 time.sleep(0.2) # 站间留间隔，避免总线冲突 client.close()

这段代码干的事很有限：逐个站号发一帧 03 功能码读保持寄存器，拿到原始值。它不负责换算，也不负责存库，目的只是把“总线上到底有没有活设备”这件事确认掉。baudrate要和现场设备拨码一致，长度超过 300 米的总线我基本都会降到 9600；timeout设太小会把正常应答判成超时，尤其在接了七八个从站之后；retries给 2 次是为了滤掉偶发干扰，如果某个站号稳定重试三次全挂，那基本就是接线或者地址错了，别怀疑脚本。原始值一定要先打出来看，很多“温度 6553.5℃”的问题，本质是寄存器被当成有符号数解析了。

轮询周期要分层，不要一把梭。环境量 5 秒一次足够，气体浓度 10 秒，电能数据 60 秒，安防 DI 走中断或者 500 毫秒扫描。全都按 1 秒轮，总线负载会飙上去，最后表现为“偶尔读不到数”，非常难查。

2.2 软件平台：实时库、告警、历史三条链路

平台侧在文档里被描述成“设备状态监测、环境实时监控、安防监控、火灾消防”的一整套应用和数据管理平台。把它拆开看，实际是三条并行的链路在跑。

第一条是实时链路。站端数据上来之后先进实时库，刷新周期跟采集周期对齐，界面上的数值、曲线、3D 情景里的设备状态都从这儿取。实时链路追求的是“延迟低、刷新稳”，不是“存得全”。

第二条是告警链路。每条测点带阈值、带死区、带延时确认，超限之后生成一条告警记录，记录里必须有事件性质、事件对象、事件内容、发生时间、事件原因。文档里特别提到告警要能“自动推出画面、发出声音提示”，这个功能在夜班无人值守时是刚需，配置上要绑到具体的摄像机预置位，不然推出来的画面拍的是墙。

第三条是历史链路。历史数据要支持组合条件查询、曲线展示、Excel 导出、报表打印，录像要能按通道、时间、区域检索回放。这条链路决定了系统能不能应付检查，字段设计上建议直接按“测点 ID + 时间戳 + 值 + 质量码”建宽表，质量码用来标记这个点是实测、是补传、还是通信中断期间的插值，导出报表时能省掉一堆解释。

-- 历史数据表的最小可用结构：宽表 + 质量码，方便导出和补传 CREATE TABLE hist_measure ( point_id VARCHAR(32) NOT NULL, -- 测点唯一编码，如 XB01.TEMP.CAB ts TIMESTAMP NOT NULL, -- 采集时标，统一存 UTC，展示时再转本地 val NUMERIC(12,3), -- 数值，开关量用 0/1 quality SMALLINT DEFAULT 0, -- 0 正常 1 补传 2 中断插值 3 越限 PRIMARY KEY (point_id, ts) ); -- 按站点+时间段导出，报表核对时最常用的一条 SELECT point_id, ts, val, quality FROM hist_measure WHERE point_id LIKE 'XB01.%' AND ts >= '2024-06-01 00:00:00' AND ts < '2024-06-02 00:00:00' ORDER BY ts;

quality这个字段看着多余，出过一次问题就知道它值钱。现场 4G 断了两小时，平台补传上来一批数据，如果不打标，报表上会出现一条平直的温度曲线，事后没人能说清那段时间到底是真稳定还是没数据。point_id用“站点.类型.位置”的层级编码，好处是做前缀查询特别快，导出某个站的全部测点一条 LIKE 就够了。时间统一存 UTC 是血泪经验，跨时区项目少踩一次坑。

2.3 移动端与 3D 情景：不是把 WEB 缩小一号

文档里移动端给了三块：环境安全监测、设备控制、曲线查询，另外终端触屏上有 3D 情景、视频监控、电能分析、联动抓拍。很多项目在移动端翻车，是因为把它当成 WEB 端的等比缩放来做，一屏塞十几个测点，手指点不中，最后没人用。

移动端的取舍原则很清楚：只放“需要立刻做决定”的信息。实时告警、当前温湿度、风机和空调的运行状态、四路视频的缩略画面，这些必须有；历史报表、电子地图图元编辑、联动规则配置，这些放回 PC WEB。设备控制尤其要收敛，遥控指令下发前必须有二次确认，且要带操作人记录——文档里提到的“操作记录统一分类存储”，在移动端比在 WEB 端更重要，因为手机谁都能拿到。

3D 情景模式在演示时效果很好，实际使用中要注意两点：模型里的设备状态点要绑到真实测点，不能是静态图片；点击设备弹出的控制面板要限权限，别让参观的人一点就把风机停了。电子地图同理，支持图片导入和图元添加之后，图元坐标一定要跟现场平面图核对一遍，我见过图元全堆在左上角的项目，纯属没做校准。

3. 一体化监控装置选型：7 路 RS485 和 24 路 DI 是怎么算出来的

选型最怕两种极端：一种是什么都往主机上堆，最后接口不够用扩展板凑；另一种是图便宜选了个接口刚好够的型号，现场加两个传感器就得换设备。文档里那台装置给的接口是 7 路 RS485、8 路 AD、8 路 DI 可扩到 24 路、8 路 DO 可扩到 24 路、千兆网口、4 路 IPC 接入、3 路 USB、HDMI 和 LVDS 各一路、一个 TF 卡槽，配 7 寸或 10.1 寸触摸屏，处理器是 Cortex-A9 双核/四核工业级，带硬件编解码。这套配置对应的是一个中等规模配电房，选它之前先把自己的点位算清楚。

3.1 接口逐项对照表：RS485 / AD / DI / DO 各接什么

把接口和现场设备一一对应，是选型阶段最该做的事。下面这张表是我按常见配置整理的对照，实际项目按现场增减：

几个数要自己算一遍。文档里说 RS485 总线通过扩展采集器最多支持 128 路环境参数采集器，这个 128 是整机能力上限，不是单路能力。7 路总线分摊下来，每路挂 18 个左右就到顶了，而工程上单路超过 16 个从站，轮询一圈的时间会明显拉长，告警响应就慢了。所以我的做法是：单路控制在 12 个以内，超过就拆总线或者加一路扩展。

DO 的容量是另一个高频坑。8 路 DO 是继电器输出，触点容量通常只有几安，直接带接触器线圈勉强可以，带空调压缩机那是绝对不行的。正确链路是 DO → 中间继电器（DC24V 线圈）→ 空调/风机的控制回路接触器，中间继电器同时起到隔离作用，避免强电串回主机烧板子。这一层不加，现场迟早要换主板。

3.2 算力与存储：4 路 IPC 接入后还剩多少余量

Cortex-A9 双核/四核这个级别，跑 4 路 1080p 的硬件编解码是够的，但“够”有前提：码率不能放开。4 路 1080p 按 4 Mbps 主码流算，一路一天约 42 GB，4 路一天接近 170 GB，一张 128 GB 的 TF 卡连一天都存不满。所以本地存储的策略必须明确：要么降码率走子码流存，要么只存事件录像（告警触发前后各 10 秒），要么把 TF 卡定位成断网缓存而不是长期存储。

我一般按这个公式估：

单路日容量(GB) ≈ 码率(Mbps) × 3600 × 24 ÷ 8 ÷ 1024

4 Mbps 算出 42.2 GB，2 Mbps 算出 21.1 GB，512 Kbps 的子码流只有 5.3 GB。文档里提到“对闯入时刻前后图像信息进行捕获”，那就说明它本来就是事件录像的思路，按事件存，TF 卡 128 GB 能撑很久。

算力余量还要留给界面。7 寸或 10.1 寸触摸屏上同时跑实时曲线、视频预览、告警弹窗，处理器负载会上去。调试阶段可以在主机上开个负载观察，四路视频全开 + 曲线刷新时 CPU 长期高于 80%，就要考虑把视频预览降到两路，或者把录像挪到独立 NVR。别等到夏天高温降频才发现卡顿，那时候人已经在现场了。

3.3 本地联动与断网续传：主机必须自己能干活

文档里有一句话分量最重：“当监控主机与远程服务器通信中断时，控制主机可离线实现水泵、风机的联动控制”。这句话是整个方案可不可用的分水岭。分布式架构的价值不在“分布式”这三个字，在于每个站点能独立活着。

落地时要做三件事。第一，联动规则必须下装到主机本地执行，平台侧的规则只做补充和覆盖，不能作为唯一执行点。第二，主机要能判断“上行链路断了”，判断依据一般是心跳超时，我习惯设 3 个心跳周期，比如 10 秒一次心跳，30 秒没收到就切本地模式。第三，本地模式下的动作要留痕，等链路恢复后补传，不然事后查不到“那天风机为什么转了”。

断网续传的缓存策略也要定：缓存多久、缓存满了怎么办、补传的优先级。常见做法是环境量和告警优先补传，视频抓拍次之，补传数据打上“补传”标记，进历史库时和实时数据分开存。这样报表上不会出现时间错乱的假曲线。

4. 风机远程控制与温湿度联动：阈值、回差、延时三个参数怎么定

风机远程控制这件功能，演示时点一下按钮风机转了就算成功，真正上线后能不能用，全看阈值、回差、延时这三个参数怎么配。文档里给的例子是“温度超过 35℃，自动启动空调降温”，这是一个起点，不是一个可以直接抄的配置。

4.1 35℃ 启动不是唯一答案：回差与延时怎么配

只有上限没有回差，是现场最常见的翻车方式。温度到 35℃ 启动降温，降到 34.9℃ 停止，下一分钟又到 35℃，设备就在那儿反复启停，压缩机寿命直接打折。正确做法是给一个回差带，比如 35℃ 启动、32℃ 停止，中间 3℃ 是死区，落在死区里不动作。

延时确认是第二道保险。传感器受局部气流影响会瞬跳，比如开门那一下温度冲到 36℃，如果立刻动作，一天能启停几十次。常规配置是：连续 3 分钟超过上限才启动，连续 3 分钟低于下限才停止。启动延时可以短一点（1 分钟），停止延时给长一点（5 分钟），避免刚停又启。

湿度控制的参数习惯不太一样。除湿机一般设 75%RH 启动、65%RH 停止，回差 10 个百分点，因为湿度变化本来就慢。SF6 泄漏和缺氧是安全类，逻辑完全不同：O2 浓度低于 19.5% 必须立即报警并强制启动风机，不设延时、不做回差，宁可误动不可不动。这类“安全优先”的联动要在规则表里单独标出来，和舒适性调节分开管理。

4.2 联动规则表怎么落：一对多、多对一的开关量映射

文档提到支持开关量输入联动开关量输出，且支持一对多、多对一、多对多。这句话在配置上意味着你需要一张映射矩阵，而不是几条 if-else。矩阵的好处是现场改起来快，也方便验收时逐条打点。

{ "rules": [ { "id": "R001", "desc": "柜内高温启动排风机与空调", "enabled": true, "priority": 10, "triggers": [ {"point": "XB01.TEMP.CAB", "op": ">", "value": 35.0, "delay_s": 60} ], "reset": [ {"point": "XB01.TEMP.CAB", "op": "<", "value": 32.0, "delay_s": 300} ], "actions": [ {"type": "DO", "channel": 1, "state": 1}, {"type": "DO", "channel": 2, "state": 1} ], "local_only": false }, { "id": "R002", "desc": "SF6 泄漏或缺氧强制排风，安全类不设延时", "enabled": true, "priority": 100, "triggers": [ {"point": "XB01.SF6", "op": ">", "value": 1000, "delay_s": 0}, {"point": "XB01.O2", "op": "<", "value": 19.5, "delay_s": 0} ], "reset": [{"point": "MANUAL.RESET", "op": "==", "value": 1, "delay_s": 0}], "actions": [ {"type": "DO", "channel": 1, "state": 1}, {"type": "DO", "channel": 8, "state": 1} ], "local_only": true } ] }

这份规则表里有几个设计点值得说。priority是冲突裁决用的，R002 的安全优先级必须高于 R001，否则高温停风机的逻辑可能把排风关掉，那就是事故。local_only标记这条规则必须下装到主机本地，断网也要执行，安全类和消防类都该打这个标。reset不写“条件不满足就停”，而是写一个明确的反向条件加延时，这样能避免边界值抖动。SF6 这条的复位走人工确认，因为气体泄漏不能靠数值自己降下来就判断安全，得有人到现场看过。

一对多的场景就是一条规则带多个 DO 动作，比如高温同时启风机和空调。多对一的场景是多个 DI 触发同一个 DO，比如红外双鉴、门磁、视频移动侦测任意一个触发都启动声光报警，那就在triggers数组里放三条，actions用一个。多对多就是组合，配的时候注意别让两条规则同时控制同一个 DO 又要求不同状态，这种冲突在调试期表现为“设备自己乱动”，很难查。

4.3 空调、风机、除湿机、水泵的启停互斥约束

同一个环境里挂了三四种执行设备，互斥关系不理清，电费会说话。最典型的是空调和风机：夏天高温时两个同时开，风机把冷气全抽走，空调一直满负荷运行，温度还降不下来。合理的策略是分场景：温度超限优先启空调，风机按定时或者气体报警才启；如果气体报警必须排风，那就强制关空调，安全优先于舒适。

除湿机和加湿器（如果有）不能同时运行，这是硬互斥。除湿机和水泵之间也要注意，水浸报警启动排水泵时，如果除湿机装在低位，要考虑是否需要切断，避免设备泡水。灯光控制相对简单，一般跟门磁或者视频联动，人进去灯亮，走了一会儿灯灭，主要作用是配合摄像机取像。

这些互斥关系最好在规则表里显式写出来，用一个interlock字段声明，比如“DO1 为 1 时强制 DO2 为 0”。别指望调试时凭记忆去规避，一个现场跑三个月，配置改过七八轮，没人记得住当初为什么这么设。写成配置，下次换人维护还能看懂。

5. 现场排查：五类高频翻车与处置顺序

现场调试期的问题，八成集中在通信、联动、执行、视频、告警这五个方向。下面这五条是我踩过的，按“现象 → 原因 → 解决”记下来，照着顺序查能省不少时间。

5.1 通信类与执行类

现象一：温湿度曲线呈周期性尖刺，数值偶尔跳到 -40℃ 或 99%RH。原因通常是 RS485 总线干扰，可能是屏蔽层两端都接了地形成地环流，也可能是总线末端没加终端电阻，长线反射导致误码。还有一种情况是信号线和动力线走在同一个线槽里，风机一启停数据就跳。 解决顺序：先把屏蔽层改成单点接地，一般在主机侧接地；再在总线最远端并一个 120Ω 终端电阻；然后把信号线与动力电缆分开走线，实在分不开就换屏蔽双绞并穿金属管。改完观察 24 小时，尖刺消失说明对路。如果还有，把波特率从 19200 降到 9600 再试。

现象二：平台上下发风机启动，界面显示已执行，现场风机没动。原因多半在执行回路，不在通信。常见有三种：DO 继电器触点容量不够，带不动接触器线圈；中间继电器线圈电压和 DO 输出不匹配，比如 DO 给的是干接点而中间继电器要 DC24V；空调或风机本身有本地控制面板，处于“本地优先”状态，外部信号被忽略。 解决：先用万用表量 DO 端子动作时是否导通，导通就往下量中间继电器，不导通就回头查配置里通道号对不对。确认执行链路通了，再去把设备本地的控制模式切到“远程允许”。这一条在空调上特别常见，说明书里往往写得很小。

现象三：拔掉网线测试断网联动，风机不启动。原因是联动规则只配在平台侧，主机本地没有规则，或者本地规则下装了但没启用。分布式架构里，站端离线自治是设计目标，但配置时很容易图省事全丢在平台上。 解决：把安全类和执行类规则全部标记为本地执行，在主机界面里逐条确认规则状态是“已生效”；然后做断网演练，拔网线等心跳超时（一般 30 秒），看 DO 是否动作、动作记录是否写进本地日志；恢复网络后核对补传记录。这个演练建议每个站都做一遍，别抽样。

5.2 视频、数据与告警类

现象四：实时视频能看，回放和联动抓拍经常缺图、时间戳对不上。原因有两层。存储层是 TF 卡写满后循环覆盖策略没配对，或者卡本身是消费级，写入寿命到了开始丢块；时间层是主机和摄像机没做 NTP 对时，两边差几十秒，按时间检索自然找不到。 解决：换成工业级 TF 卡，容量按前面那个公式重算；把录像策略改成事件触发为主，告警前后各留 10 秒；主机和所有 IPC 统一指向同一个 NTP 源，时区设一致。做完之后连续抓拍 20 次，看 20 次里能查到几次，低于 18 次就还得查。

现象五：告警记录刷屏，同一个温度越限一分钟推十几条。原因是阈值没配回差、没有延时确认，也没有告警抑制。数值在阈值上下抖动，每抖一次产生一条记录，值班的人很快就对告警麻木了。 解决：给越限告警加死区和延时确认，同一测点同一类型的告警设合并窗口，比如 5 分钟内只保留一条并累计次数；恢复通知也加延时，避免“越限—恢复”成对刷。改完之后观察一周，告警条数应该降到原来的十分之一以下，且每条都是真需要人看的。

注意：排查顺序建议从“电源和执行回路”开始，再查通信，最后查软件配置。现场大部分“系统问题”最后都落在接线端子松了、接触器坏了、卡满了这三件事上。

6. 验收动作清单：把“能看到”变成“敢签字”的四步

功能演示通过和系统验收通过，中间差着一整套验证动作。我现在的习惯是分四步走，每一步都有可量化的判据，签验收单之前必须全绿。

第一步是单点校验。拿地址规划表，逐个测点做物理打点：温度探头用手捂或者用热风枪吹，看平台数值是否跟着动、量程是否对；水浸绳蘸水看 DI 是否变位；每个 DO 通道强制输出一次，看现场设备是否动作、状态是否回读一致。这一步最枯燥，也最能暴露问题，128 个测点打完基本一天，但能把“接线接错通道”这类低级错误全清掉。

第二步是联动校验，重点是断网。把上行网线拔掉，等心跳超时，逐条触发安全类规则，看本地是否执行、是否留痕；恢复网络后核对补传数据是否完整、是否打了补传标记。这一步一定要在白天做，别留到夜里，因为恢复网络后可能会有大量补传，需要人盯着。

第三步是稳定性观察，建议不少于 72 小时。关注三个指标：

第四步是数据出口校验。把历史数据按站点、按时间段导出成 Excel，和现场手工记录的温度计、湿度计读数对一遍，偏差在传感器精度范围内才算过。报表能打印、曲线能拉出来、录像能按通道和时间检索到，这三件事看着基础，实际项目里总有一项是半成品。

提示：验收前把“操作记录”功能打开并测一遍。谁在什么时间远程停了哪台风机，这条记录在事后追责时比任何截图都管用。

说个自己的教训。早些年做一个配电房项目，功能演示很顺，我当场就签了初验，结果投运第三天下暴雨，水浸报警触发，排水泵没启——原因是那条联动只配在平台侧，而恰好那天上行链路在维护。后来我把“断网演练”写进了自己每个项目的验收必做项，不管工期多紧，拔一次网线只要十分钟，出了事就是几十万的抢修和一堆解释不清的记录。从那以后我每次上电调试前，都会先把本地联动规则单独过一遍，再去看平台功能，顺序反了就容易自我安慰。希望帮到你。

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