简介《箱变综合智能在线监控系统》面向箱式变电站、配电室、环网柜等电力设施的运维与安全管理人员围绕箱变环境温湿度、烟雾、防盗及设备状态监测梳理“四遥”遥测、遥信、遥控、遥调实现思路。文档从系统架构、站端采集、软件平台与移动端应用展开并介绍配电房一体化监控装置 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 叫它。接口清单值得单独摊开看因为选型和报价的差异基本都出在余量上。接口/资源文档给的规格现场一般接什么余量建议RS4857 路温湿度、烟感、水浸、SF6/O2、电能表、除湿机每路挂 20~30 节点留 1 路备用DI 开关量输入8 路可扩至 24 路门磁、红外双鉴、开关位置、设备故障干接点按实际点数上浮 30%DO 开关量输出8 路可扩至 24 路风机、水泵、灯光、空调、声光报警器大功率负载一律走中间继电器AD 模拟量输入8 路4~20mA 变送器、水位、压力注意共地与隔离以太网千兆平台上行、IPC 接入视频与数据建议分 VLANIPC 接入4 路高清枪机、球机带 PTZ码率决定存储天数USB / HDMI / LVDS / TF3 路 host / 1 / 1 / 1调试键鼠、外接大屏、本地存储TF 卡只做应急缓存RS485 侧有个硬指标通过总线扩展采集器最多支持 128 路环境参数采集器。这个 128 是理论上限不是施工建议。总线带载越多、线越长反射和衰减越明显常见做法是波特率 9600、0.75mm² 以上屏蔽双绞线、手拉手串接、末端加 120Ω 终端电阻单路控制在 20~30 个节点以内剩下的用另外几路分开带。存储这块要提前算账别等验收才发现录像只存了一天半。4 路 1080p 按 2Mbps 码率估单路一天约 21GB4 路就是 84GB128G 的 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 四遥在本项目里的具体落点类别典型点位采集/执行方式刷新与存储遥测温湿度、SF6/O2 浓度、水位、三相电压电流功率RS485 轮询、AD 变送器缓变量 30~60s电参量 1~5s全部入库遥信烟感、水浸、门磁、红外双鉴、开关位置、设备故障DI 干接点、RS485 状态字变位即报同时周期全量对时遥控风机、水泵、灯光、空调启停摄像机 P/T/ZDO 输出、继电器、IPC 云台协议执行后回读状态记操作日志遥调告警阈值、回差、延时、上报周期、空调设定温度平台下发规则与参数每次变更新增版本可回滚遥测里最容易做错的是刷新周期一刀切。烟感、水浸这类安全信号必须变位即报秒级温湿度 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决定这条规则是否下装到站端本地执行涉及安全的规则一律为 truepriority解决冲突比如 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 变成一张能验收的点位表这份方案文档最大的价值不是文字是它把功能边界、设备接口、联动场景都说清楚了缺的是可执行的结构。我拿到这类文档的第一件事不是画架构图而是抽点位表——把每个站点的每个测点列成一行字段就这几个字段说明示例point_id全局唯一点位编号XB-0231.TEMP_IN站点/设备归属关系1 号箱变 / PU-500类型遥测/遥信/遥控/遥调遥测采集方式RS485 地址寄存器、DI 通道、内部量485-3 / 0x0002量程与单位换算用-20~80 ℃阈值与回差触发与恢复35 / 30联动动作命中后执行什么启空调 屏弹窗这张表一旦填完设备选型余量、RS485 分路、DO 点数、平台建表全能倒推出来谁也糊弄不了。二期要加 SF6 联动或者水浸联动也只是在这张表上加行、在规则表里加一条配置不用改代码。建议按三期验收一期只做采集与展示二期上联动与告警三期接视频与移动端每期都用离线拔网线的方式验一遍本地闭环。我第一次做这类项目时觉得规则写在代码里最快结果现场要改一个阈值我改了代码、打了包、远程指导值班员升级折腾一下午。从那以后我每次交付前都强制走一遍「规则配置化 拔网线演练」配置改不动的功能一律不算做完。希望帮到你。本文还有配套的精品资源点击获取