箱变综合智能在线监控系统：四遥联动与站端闭环落地

简介：《箱变综合智能在线监控系统》面向箱式变电站、配电室、环网柜等电力设施的运维与安全管理人员，围绕箱变环境温湿度、烟雾、防盗及设备状态监测，梳理“四遥”（遥测、遥信、遥控、遥调）实现思路。文档从系统架构、站端采集、软件平台与移动端应用展开，并介绍配电房一体化监控装置 HT500 Plus 的接口、人机界面与离线联动能力，同时覆盖实时告警、历史数据查询、视频监控及风机、空调、水泵等联动控制逻辑，可作为方案选型与运维落地的参考。压缩包共1个doc文件，约2.2MB，内容以产品介绍和系统方案为主，结构完整，便于按章节查阅。已有649人学习下载，适合电力自动化从业者、系统集成商及相关专业学习者了解箱变智能监控的组成与功能边界。

1. 从一台箱变的高温告警说起：这套系统到底在管什么

去年最热的那几天，一个现场打来电话：箱变里温度表指针顶到头，人赶过去时空调还是关着的。这种局面在箱变综合智能在线监控系统上线之前很常见——箱变环境监测靠人跑站，风机远程控制只写在制度里。这套方案要解决的正是这类事：把箱式变电站、配电室、环网柜、分支箱里的温湿度、烟雾、水浸、门磁、红外双鉴这些信号采上来，做成本地能看、远端能控、断网还能自己动作的闭环。它面向的是跑配电运维的班组、做站端集成的工程商，以及要在既有箱变上补监控的改造项目。文档给的不是一个 App 界面，而是一套从传感器布点到平台表结构的完整落地口径。

2. 三段式架构：站端、平台、移动端各自守住哪一段

这份文档把系统拆成站端系统、软件平台、移动客户端三部分，用的是分布式加模块化的路子。这个拆法不是为了架构图好看，而是箱变这类点位天生分散、网络质量参差、又必须保证告警一条都不能丢。三段之间如果职责糊在一起，后面联调会非常难受：站端等平台下发指令才动作，平台一断，风机就不转了。

2.1 边界怎么划：谁做实时闭环，谁做长期账本

站端系统的职责是采集、计算、本地联动、本地呈现。它接的是各种物联网环境与设备监测传感器和视频监控装置，把数据算完就地显示在液晶屏上，同时决定「现在要不要启空调」「现在要不要拉声光报警器」。文档里那句「各个站点子系统独立运行，具备各自本地联动控制、异常报警功能」，是整个架构里最值钱的一条约束——它意味着实时控制闭环留在站端，平台不参与毫秒级的动作判定。

软件平台的职责是纳管和记账：设备状态监测、环境实时监控、安防监控、火灾消防信息的统一呈现，跨站点的对比、历史曲线、报表导出、权限与操作留痕。它向下发的是规则和参数（也就是遥调），不是「立刻给我合上那个 DO」。这个区别很关键，我见过不少项目在平台侧写了个「一键启风机」，结果 4G 抖一下，命令丢了，值班员以为启了，实际没启。

移动客户端是第三段，包括移动 WEB 和移动 APP。它面向的是不在中控室的人：环境安全监测、设备控制、曲线查询三块。我的习惯是移动端默认只读，控制类操作单独授权并且必须回显执行结果，不然手机上误触一下，现场风机就转起来了。

数据流向上以站端到平台为主，参数与规则反向下行。三种网络状态要说清楚：在线时平台实时收数、下发规则；弱网时站端降频上报、本地规则照跑；完全离线时站端独立闭环，恢复后补传。这三态是验收时必须逐条演示的，不然后面一定扯皮。

2.2 一台一体机的接口盘点：余量怎么留

站端的核心是那台配电房一体化监控装置。文档给的是一台基于 Cortex-A9 的双核/四核工业级处理器设备，带硬件编解码，支持 4 路高清 IPC 接入和 4 路视频实时预览、存储、回放，人机界面是 7 寸或 10.1 寸触摸屏。下文按代号 PU-500 叫它。接口清单值得单独摊开看，因为选型和报价的差异基本都出在余量上。

RS485 侧有个硬指标：通过总线扩展采集器，最多支持 128 路环境参数采集器。这个 128 是理论上限，不是施工建议。总线带载越多、线越长，反射和衰减越明显，常见做法是波特率 9600、0.75mm² 以上屏蔽双绞线、手拉手串接、末端加 120Ω 终端电阻，单路控制在 20~30 个节点以内，剩下的用另外几路分开带。

存储这块要提前算账，别等验收才发现录像只存了一天半。4 路 1080p 按 2Mbps 码率估，单路一天约 21GB，4 路就是 84GB，128G 的 TF 卡撑不到两天。所以 TF 卡只能定位成断网期间的应急缓存，长期存储要么走平台集中录像，要么把码率降下来、开移动侦测只录事件片段，再配合告警联动抓拍。

DI 和 DO 的电气细节也别省。DI 接干接点最省心，接湿接点必须确认电压等级和隔离；DO 输出能力有限，直接带接触器线圈的结果通常是触点粘连或者输出板烧掉，正确姿势是 DO 驱动中间继电器，再由继电器带接触器，线圈两端并续流二极管。

2.3 一条数据从传感器到屏幕的五段链路

把链路拆成五段，排查问题时能快速定位是哪一段出了岔子：传感层出的是数值本身不对，采集层出的是丢包和校验错，计算层出的是联动不触发，呈现层出的是屏幕不刷新，上送层出的是平台看不到。

上送报文的结构我一般按下面这个形态定，字段不多但每个都有用：

{ "site_id": "XB-0231", "ts": 1735689600000, "seq": 88213, "online": true, "telemetry": [ {"point": "TEMP_IN", "v": 41.6, "q": 0}, {"point": "HUMI_IN", "v": 68.2, "q": 0} ], "signal": [ {"point": "SMOKE", "v": 1, "q": 0}, {"point": "DOOR", "v": 0, "q": 0} ], "alarm": [ {"code": "TEMP_HIGH", "level": 2, "ts": 1735689580000, "val": 41.6, "thr": 35.0} ] }

site_id是站点唯一标识，平台侧所有查询都靠它分片；ts是采集时刻而不是发送时刻，弱网补传时这一点决定了曲线画得对不对；seq是自增序号，平台按它去重，断点续传不会写出两条一样的采样；q是质量位，0 表示正常、非 0 表示传感器断线或超量程，前端画曲线时要把它渲染成断点而不是 0 值，否则运维会以为温度真的掉到零度；alarm里同时带val和thr，回溯的时候不用再去翻当时的阈值配置。

上送通道优先光纤，没有光纤走 4G 无线。4G 下要克制：变化上报加定时心跳，温湿度这类缓变量 60 秒一次足够，别把 1 秒级的原始采样全推上去，流量费和平台写入压力都吃不消。

3. 四遥与联动规则：把「温度超 35℃ 启空调」写成可配置的东西

「四遥」——遥测、遥信、遥控、遥调——是这套系统的功能骨架。文档明确写了可对运行参数进行远方设置，对箱体内湿度、温度进行控制，温度超过 35℃ 自动启动空调降温，同时支持烟雾报警。这四类能力如果只是罗列在方案里，实施时很容易变成四套割裂的逻辑，真正落地要先把它们映射到具体点位和刷新策略上。

3.1 四遥在本项目里的具体落点

遥测里最容易做错的是刷新周期一刀切。烟感、水浸这类安全信号必须变位即报，秒级；温湿度 30 到 60 秒完全够用；如果现场接了电能表做「电能分析」，三相电压电流功率曲线的采样要 1 到 5 秒，否则画出来的功率曲线全是锯齿。文档里终端触屏的「电能分析」页面就是看三相电压、电流、功率监测曲线，采样率不够这个页面就没意义。

遥调经常被误解成「调设备」。在这个项目里它调的是参数：告警阈值、回差、确认延时、上报周期、空调的目标温度。把这些做成可下发、可版本化、可回滚的配置，比在代码里写死几个常量强太多，尤其是不同站点、不同季节的最优阈值本来就不一样。

3.2 一条联动规则的字段设计

文档列了一串联动场景：入侵触发时摄像机自动凝视目标并录像、启动声光报警器；室内温湿度越限自动报警并启动风机；SF6 泄漏自动启风机加声光报警；水浸报警自动启动给排水；还支持开关量输入联动开关量输出的一对多、多对一、多对多。这些要落到一张表里，就得先把规则表达清楚。

{ "rule_id": "R-TEMP-AC", "enabled": true, "priority": 20, "scope": ["XB-0231"], "trigger": {"point": "TEMP_IN", "op": "gt", "value": 35.0}, "confirm": {"duration_s": 60, "samples": 3}, "action": [ {"type": "do", "target": "AC_POWER", "cmd": "on"}, {"type": "notify", "channel": ["screen", "platform"], "level": 2} ], "release": {"point": "TEMP_IN", "op": "lt", "value": 30.0}, "cooldown_s": 300, "offline_exec": true }

trigger是触发条件，这里对应文档里「温度超过 35℃」；confirm是去抖，连续 60 秒内至少 3 个采样点都满足才动作，避免传感器一个毛刺就把空调拉起来；release是恢复条件，用 30℃ 而不是 34.9℃，这个 5℃ 的回差是防抖的关键，没有回差的话温度在 35℃ 上下晃，空调会疯狂启停；cooldown_s是冷却时间，空调压缩机停机后通常需要 3 分钟保护，300 秒是个稳妥值；offline_exec决定这条规则是否下装到站端本地执行，涉及安全的规则一律为 true；priority解决冲突，比如 SF6 泄漏的启风机规则优先级要高于温湿度规则。

一对多、多对一、多对多的开关量联动，实现上就是把trigger从单个对象改成数组，加一个logic字段取any或all。多对一就是一个动作被多条规则命中，靠priority和cooldown收敛；一对多就是action数组里放多个执行项。这套结构不复杂，但一定要在数据库里存成可编辑的配置，而不是散落在代码 if-else 里，否则现场改一次逻辑就得发一次版本。

3.3 告警从产生到归档的完整链路

一条告警要走完六步才算闭环。第一步产生，记录事件性质、事件对象、事件内容、发生时间、事件原因和描述信息，这些字段文档里写得很明确，建表时一个都别省。第二步去抖，用confirm那套逻辑压掉瞬时抖动。第三步分级，烟感、SF6 泄漏属于高等级，温湿度越限属于中等级，门磁打开属于提示级。第四步推送，本地屏幕弹窗加声音，平台推实时告警列表，移动端推消息。第五步联动，按规则启风机、启空调、拉声光报警器、触发摄像机抓拍录像。第六步归档，写库并关联抓拍图片和录像片段。

告警恢复要单独记一条事件，不要去改原记录的状态字段。原记录被覆盖之后，「这条告警持续了多久」就查不出来了，而持续时间恰恰是运维复盘时最关心的数据。历史查询里按组合条件筛、按曲线看趋势、按列表看告警、点进去直接看关联录像和照片，这套体验能不能站住，全看告警和媒体索引有没有在一开始就绑好。

4. 软件平台落地：数据模型、历史查询和电子地图

平台侧要做的事，文档归纳成在线检测数据浏览、综合分析、设备实时状态分析评估，还有检测数据完整性、一致性、采集及时性的统计。翻译成工程语言就是：点位建模要稳、时序数据要能查、媒体要能关联、报表要能导出。这几件事的地基都在表结构上。

4.1 七张表撑起一个站点

下面是我在这个场景里惯用的精简模型，字段做了裁剪，重点是关系：

CREATE TABLE site ( site_id VARCHAR(32) PRIMARY KEY, site_name VARCHAR(64) NOT NULL, site_type VARCHAR(16), -- 箱变/配电室/环网柜/分支箱/开关站 lng_lat VARCHAR(32), online_state TINYINT DEFAULT 0 ); CREATE TABLE device ( dev_id BIGINT PRIMARY KEY, site_id VARCHAR(32) NOT NULL, dev_type VARCHAR(24), -- PU500/温湿度/烟感/球机 dev_sn VARCHAR(48), install_at DATETIME ); CREATE TABLE point ( point_id VARCHAR(48) PRIMARY KEY, -- 全局唯一，如 XB-0231.TEMP_IN dev_id BIGINT NOT NULL, point_type TINYINT, -- 1遥测 2遥信 3遥控 4遥调 unit VARCHAR(8), quality TINYINT DEFAULT 0 ); CREATE TABLE sample ( point_id VARCHAR(48) NOT NULL, ts DATETIME NOT NULL, val DOUBLE, PRIMARY KEY (point_id, ts) ) PARTITION BY RANGE (TO_DAYS(ts)); CREATE TABLE alarm ( alarm_id BIGINT PRIMARY KEY, site_id VARCHAR(32), point_id VARCHAR(48), code VARCHAR(32), level TINYINT, val DOUBLE, thr DOUBLE, raised_at DATETIME, cleared_at DATETIME NULL, ack_by VARCHAR(32) NULL ); CREATE TABLE linkage_rule ( rule_id VARCHAR(32) PRIMARY KEY, site_id VARCHAR(32), cfg_json TEXT, version INT, enabled TINYINT ); CREATE TABLE media_clip ( clip_id BIGINT PRIMARY KEY, site_id VARCHAR(32), channel TINYINT, alarm_id BIGINT NULL, start_at DATETIME, end_at DATETIME, file_path VARCHAR(255) );

point表独立于device表，是这套模型里最重要的一条。设备会坏、会换型号、会挪位置，但点位的历史数据不能跟着丢。换设备时只改device记录、把point.dev_id迁移过去，历史曲线还是连续的。sample用(point_id, ts)联合主键天然去重，配合按时间分区，查一个月的数据不会把整表扫一遍。alarm里raised_at和cleared_at分开存，就避开了前面说的覆盖问题。media_clip留一个可空的alarm_id，有告警时绑告警，日常录像绑空，检索逻辑两条路都能走。

4.2 历史曲线与报表导出：别在明细表上直接画图

明细表只负责写，画图要读聚合表。常见做法是落一张分钟级聚合表，按point_id + 分钟存min / max / avg / last四个值。查一天曲线取分钟表，查一小时取秒级明细，查一个季度取小时表或天表。这样前端拖时间范围的时候不会突然卡住。

报表导出有几个坑值得提前避。一是导出必须走流式写，别把几万行拼成一个内存对象，Excel 组件一撑就内存溢出。二是导出要限时间跨度，比如单次不超过 31 天，超了让用户分批导。三是导出的列要和页面上的列一一对应，尤其是告警报表里的「事件原因」和「关联录像」这两列，运维拿去汇报就看这两项。文档里提到历史数据支持 Excel 格式导出备份、输出成报表并打印，这个需求很朴素，但做扎实的项目不多。

录像检索的关联条件是通道、时间、区域。区域检索在箱变场景里其实用得少，真正高频的是「点开这条告警，直接看前后 10 秒」。所以写入时就应该把告警时刻前后的片段标记出来，media_clip里存start_at和end_at，查询直接用时间区间命中索引，别在播放器里去算偏移量。

4.3 电子地图和 3D 情景页：能省则省的做法

文档提到电子地图支持图片导入、设备图元添加、设备信息查看及控制、设备告警提示，也提到终端触屏上的 3D 情景模式，用来监视空调、风机、除湿机、烟雾传感器、摄像机这些设备。这两块最容易做过头。

电子地图的实用做法是底图加百分比坐标。图元位置存成相对底图的百分比而不是像素绝对坐标，换分辨率、换屏幕尺寸都不用重画。告警时图元变红并闪烁，点击弹出该点位的实时值和最近一条告警，够用了。

「3D 情景」这四个字听着唬人，实际落地绝大多数是全景图或轴测图加一层热区，点热区跳转到对应设备面板。真做三维建模，成本翻好几倍，收益主要是演示效果。我的建议是先用图片加热区把 3D 情景页跑通，等甲方真的有三维需求再换渲染引擎，数据接口不用改。移动端同理，H5 复用平台页面比单独做一套 APP 省事，曲线查询和环境监测这两块在手机上用 H5 体验完全够。

5. 联调避坑：从 RS485 总线到 4G 上行的五条血泪经验

这套系统的功能列表看着不复杂，但现场联调阶段翻车的概率不低。下面五条是我在不同项目里反复遇到的，按现象、原因、解决写清楚，赶工期的可以直接当检查单用。

5.1 现场侧：总线、供电与输出回路

第一条，RS485 丢包。现象是平台上一批温湿度点位时有时无，采集器在线率在 80% 上下跳。原因基本是接线拓扑不对：施工队图省事从一台设备并出三路，做成了星形甚至树形，总线末端也没加终端电阻，信号反射导致校验错。解决办法是改成手拉手串接，末端并 120Ω 电阻，节点多的那一路拆到另外一路 RS485 上，长距离段加隔离收发器。改完之后在线率能到 99% 以上。

第二条，温湿度数值乱跳。现象是同一时刻相邻两个传感器差 8℃，或者湿度偶尔蹦到 99%。原因通常有两个：传感器和一体机不共地，或者屏蔽层两端都接了地形成地环流；再就是传感器和风机、水泵共用一路 24V 电源，启停瞬间把电源拉塌。解决办法是屏蔽层单端接地，传感器单独一路开关电源，必要时加 DC-DC 隔离模块，AD 采集通道加 RC 滤波。

第三条，DO 输出带不动或者烧板。现象是远程启风机时好时坏，或者用了一段时间某个 DO 通道常闭。原因是 DO 直接驱动了接触器线圈，感性负载断电瞬间的反电动势把输出管打穿。解决办法是 DO 先驱动中间继电器，继电器线圈两端并续流二极管，再由继电器触点带接触器，同时确认 DO 的公共端和负载电源的极性没接反。这条属于典型的省一个继电器赔一块板。

5.2 平台与网络侧：链路、时间与告警风暴

第四条，4G 下遥控指令下发失败。现象是平台点「启风机」转圈然后超时，站端毫无反应，但数据上报一直是正常的。原因是 4G 卡在运营商 NAT 后面，平台主动发起的下行连接根本到不了站端。解决办法是把下行改成拉模式：站端维持一条到平台的长连接，定时心跳，平台把指令塞进该站点的命令队列，站端心跳时取走并回执执行结果。这个改法还有个好处，指令有了明确的执行状态反馈，不再是「发了就不管」。

第五条，告警风暴。现象是某个下午值班员的手机被短信轰炸了几百条，最后他把通知关了。原因通常是阈值设得太贴边（比如温度阈值设 34.9℃，而现场夏天常态就在 34℃ 附近），又没有回差和延时确认，再加上每个点位单独推一条，同一件事推了几十遍。解决办法是阈值留余量、加回差和确认延时、同类告警在时间窗内合并成一条、按等级分通道推送。告警抑制不是把告警藏起来，而是让人看得过来。

还有一条不算坑但必须做：时间同步。站端 RTC 漂移加上 4G 网络时延，会让曲线错位、录像检索对不上号。站端一律配 NTP，取不到 NTP 时以平台下发的时间为基准，上送报文里带本地时间戳和时区，平台落库统一转 UTC。

6. 二次开发：把这份 doc 变成一张能验收的点位表

这份方案文档最大的价值不是文字，是它把功能边界、设备接口、联动场景都说清楚了，缺的是可执行的结构。我拿到这类文档的第一件事不是画架构图，而是抽点位表——把每个站点的每个测点列成一行，字段就这几个：

这张表一旦填完，设备选型余量、RS485 分路、DO 点数、平台建表全能倒推出来，谁也糊弄不了。二期要加 SF6 联动或者水浸联动，也只是在这张表上加行、在规则表里加一条配置，不用改代码。建议按三期验收：一期只做采集与展示，二期上联动与告警，三期接视频与移动端，每期都用离线拔网线的方式验一遍本地闭环。

我第一次做这类项目时，觉得规则写在代码里最快，结果现场要改一个阈值，我改了代码、打了包、远程指导值班员升级，折腾一下午。从那以后我每次交付前都强制走一遍「规则配置化 + 拔网线演练」，配置改不动的功能一律不算做完。希望帮到你。

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