简介《箱变综合智能在线监控系统》是一份面向电力运维人员、配电室管理人员及电气自动化学习者的技术文档围绕箱式变电站环境温湿度、烟雾、防盗及设备状态监测梳理从站端采集、软件平台到移动客户端的整体监控方案。文档共1个doc文件约2.2MB内容涵盖“四遥”实现、HT500 Plus配电房一体化监控装置、传感器接入、视频监控、联动控制及历史数据查询等模块并给出箱变、变电站、配电室、环网柜、分支箱和开关站等场景的部署思路。已有649人学习适合用于了解箱变综合监控的系统架构、功能划分与联动逻辑也可作为环境监测、安防预警和设备远程控制方案的参考材料。读者可从中获取系统组成、核心装置能力、实时告警与联动抓拍录像等具体内容便于对照实际项目梳理监控需求和功能清单。1. 箱变环境监测的真实痛点为什么一套综合在线监控系统不能只做「看」夏天午后某园区一台箱变的柜内温度爬到 50 ℃ 以上除湿机没开、风机没转等运维人员两小时后赶到现场二次端子排上已经挂了一层凝露。这类工况下箱变综合智能在线监控系统要解决的不是「能不能看到数据」而是「看到之后谁去动作」。箱变环境监测的价值在闭环风机远程控制只是闭环最末端那一环前面还得有传感器接入、阈值判断、联动触发和告警留痕。这套方案适合正在做配电类毕设或课程设计的人也适合要给园区、分支箱、环网柜出一份可交付监控方案的人读完能照着把点位表、联动表和验收清单填出来。2. 总体架构设计站端、平台、移动端三层与四遥数据流箱变站点的特点是「点多、面散、单站设备少、通信质量不稳」。一台箱变里可能只有十来个传感器加四路摄像机但要管几十台就不可能每台都配一台服务器。方案采用分布式与模块化架构切成站端系统、软件平台、移动客户端三部分每层只干自己最擅长的事层与层之间靠标准协议和统一数据模型对接任何一层换实现都不影响另外两层。2.1 三层职责划分谁采集、谁计算、谁呈现站端系统负责「采集 就地判断」。部署在箱变低压侧的一体化监控装置接入温湿度、SF6/O2、水浸、烟感、红外双鉴等传感器和视频监控装置用光纤或有线网络优先、4/5G 无线兜底的方式把数据上送。它同时承担本地联动监控主机与远程服务器通信中断时水泵、风机仍要能自动启动。这条要求决定了后面所有的设计取舍——计算必须下沉不能把联动逻辑全放在平台上。软件平台基于 PC WEB提供设备状态监测、环境实时监控、安防监控、火灾消防等信息的检测与控制是一整套应用与数据管理平台。它做的是跨站聚合多站对比、电子地图、历史曲线、报表导出、录像检索。平台不参与毫秒级动作只做二次判断和人工遥控入口。移动客户端包含移动 WEB 与移动 APP 两套界面功能收敛成三块环境安全监测、设备控制、曲线查询。移动端不做复杂配置避免运维人员在手机上误改阈值。三层的计算分工可以概括成一句话站端保证「不断网也能活」平台保证「多站能对比」移动端保证「人不在现场也能处置」。我一般会在方案文档里把这条写成一张职责边界表答辩时被问到「为什么不用纯云端架构」直接翻到这页即可。容量规划是最容易被忽略的一步。单台监控主机最多支持 128 路环境参数采集器7 路 RS485 挂传感器、扩展采集器再往下挂末端探头。RS485 按 9600 波特率、单次往返约 30 ms 估算128 个从站轮询一轮差不多 4 秒采集周期取 5 秒比较稳妥如果现场探头只有 20 个周期可以压到 1 秒。这个算式看着粗糙但它决定了后面告警延时和录像预录时长怎么设先算清楚比事后调参省事。2.2 四遥数据流从 RS485 到 WEB 页面的四段链路遥测、遥信、遥控、遥调四条链路在实现上完全不是一回事混在一起设计就会出问题。遥测走模拟量温湿度、SF6/O2 浓度、电缆夹层水位、三相电压电流功率。传感器经 RS485 或 4-20 mA 接入监控主机做量程换算和越限判断再按固定周期上送。遥测允许丢点但不允许错值所以上报包里必须带质量位。遥信走开关量水浸、红外双鉴、烟感干接点、门禁、风机运行反馈、断路器位置。遥信的关键是变位上报加时间戳而不是周期性扫描后统一上送——否则同一秒内门被推开又关上平台侧完全看不到。遥控是下行链路平台下发命令监控主机校验后驱动 DO 输出再回读一次开关量状态确认动作到位。这里必须做「命令 回读」双确认只发不收的遥控在验收时一定会被打回。对风机、灯具这类设备用点动或短脉冲对空调这类带自保持的设备用保持型输出两种输出方式要在配置里区分开。遥调是参数下行把温度上限、湿度上限、SF6 报警值、录像预录时长这些阈值从平台推到站端落到监控主机本地配置文件里。遥调做完必须回读比对否则平台显示已下发、站端还是老阈值这种「假成功」在现场排查起来非常费时间。一条典型的上报报文长这样{ stationId: XB-A01, ts: 1730000000000, telemetry: { temp: 36.4, humidity: 71.2, sf6: 0, o2: 20.8, ua: 231.5 }, status: { fan: 1, ac: 0, pump: 0, door: 0, smoke: 0 }, quality: good, seq: 88213 }stationId是站点唯一编码建议按「区域-线路-箱变编号」拼不要用 IP 或设备序列号否则换设备后历史数据就断了血缘。ts用毫秒时间戳站端和平台必须同源对时。telemetry与status分开两个对象是因为它们在库里落在不同表、压缩策略也不同。quality用来标记该帧是否可信传感器断线时置为bad而不是直接不上送这样平台侧的完整性统计才有意义。seq是自增序号专门用来做补传去重后文讲断网补传还会用到它。2.3 通信通道与断网降级光纤、4G/5G 与本地自治通道选择上光纤优先、无线兜底是常规做法。光纤稳定、带宽足够跑四路高清视频无线适合老旧站点改造布线成本低但带宽和时延波动大视频只传抓拍图和报警前后各十几秒的短片不做 7×24 全量回传。链路健康检测靠心跳30 秒一次连续三次丢失判定离线。这里有个坑不要在判定离线时立刻切换通道否则无线信号弱的时候会来回切形成乒乓。我一般会加一个「切换后至少保持 5 分钟」的锁定期宁可多等几分钟也不要让通道反复重建。真正决定这套系统能不能验收的是断网时的表现。监控主机的本地联动逻辑独立运行网断了照常按阈值启停风机、水泵、空调采集数据写本地 TF 卡缓存网络恢复后按seq补传平台侧收到重复序号直接丢弃。按每帧 200 字节、5 秒一帧估算一天约 3.5 MB一张 8 GB 的卡存几个月不成问题。缓存写满的策略要提前定优先保留告警前后时段的数据普通遥测按天滚动覆盖这条规则最好写进方案文档不要留给现场临时决定。3. 站端采集与一体化监控装置接口清单、传感器接入与本地触屏站端是整套方案里最「硬」的部分。一体化监控装置基于 Cortex-A9 双核/四核工业级处理器具备硬件编解码能力支持 4 路高清 IPC 接入和 4 路视频实时预览、存储、回放对外提供千兆以太网、7 路 RS485、8 路 AD、8 路 DI可扩展至 24 路、8 路 DO可扩展至 24 路、3 路 USB Host、1 路 HDMI、1 路 LVDS 和 1 个 TF 卡接口配 7 寸或 10.1 寸人机交互界面。接口数量看着够用怎么分配才是设计活。3.1 硬件接口盘点与点位分配分配的原则有三条命令与反馈成对、同类信号集中、预留不少于 20%。下面这张表是我在类似项目里常用的分配模板可以直接改成自己站点的点位表。接口类型数量典型接入对象分配建议RS4857 路温湿度、SF6/O2、水浸、烟感、多功能电表、空调协议、除湿机按设备类型分路不要把不同厂商协议混在同一条总线上AD 输入8 路4-20 mA 水位变送器、变压器绕组温度、直流屏电压留 2 路备用量程拨码在调试时记录DI 输入8 路可扩 24红外双鉴、门磁、水浸开关量、烟感干接点、风机运行反馈、断路器位置每台被控设备至少配 1 路反馈不能只发命令不看结果DO 输出8 路可扩 24风机、照明、空调、给排水泵、除湿机、声光报警器声光报警单独占一路不与其他设备共用千兆网口1 路4 路高清 IPC摄像机与监控主机同网段单独划分 VLANTF 卡1 个断网缓存与本地录像索引工业级卡容量不小于 8 GBHDMI / LVDS各 1 路本地大屏或柜门显示屏与触摸屏同源输出便于柜外查看DI 与 DO 的对应关系要在点位表里写死。风机启动对应 DO1风机运行反馈对应 DI5这样平台侧看到「DO1 已输出但 DI5 无反馈」就能立刻判断是接触器坏了还是回路断了。只做单向输出的系统验收时一旦被问到「你怎么知道风机真的转了」是答不上来的。3.2 传感器接入与地址规划RS485 总线按手拉手串接A/B 线不能反接屏蔽层单点接地总线两端加终端电阻。地址规划建议按类型分段1-32 给温湿度33-48 给 SF6/O249-64 给水浸与烟感65-96 给多功能电表97 以后留给扩展采集器。分段的好处是现场加装探头时不用全表扫描找空地址看段号就知道该填哪个。采集参数上超时设 300 ms、重试 2 次、失败 3 次标记该从站为离线并产生一条设备通信告警。这条告警要和「环境越限告警」在平台上分开呈现否则传感器掉线会被误读成环境正常。4-20 mA 通道要做工程量换算公式不复杂但量程上下限一定要和变送器铭牌一致def ad_to_engineering(raw, raw_min0, raw_max4095, eng_min0.0, eng_max100.0): 把 AD 原始码值换算成工程量。 raw : AD 采样值12 位芯片范围 0-4095 eng_min/max: 变送器量程必须与铭牌一致例如水位 0-5 m 返回超出量程 5% 的值时置为无效避免断线时读数漂成 0 被当成正常 if raw raw_min or raw raw_max: return None ratio (raw - raw_min) / (raw_max - raw_min) value eng_min ratio * (eng_max - eng_min) if value eng_min - 0.05 * (eng_max - eng_min): return None return round(value, 2)这段函数的关键不是换算而是两个保护输入越界返回None输出低于量程下限 5% 也返回None。变送器断线时输出电流会掉到 0如果直接按比例换算水位会显示成一个「正常的小数值」值班人员根本发现不了。3.3 本地触屏3D 情景、视频预览与电能曲线7 寸工业触摸屏不是装饰。网断的时候它是现场唯一的人机入口。主界面我一般按「当前告警条 三个最常操作设备 视频缩略图」来排运维人员打开柜门第一眼就能看到有没有异常不用翻菜单。3D 情景模式把空调、风机、除湿机、烟雾传感器、摄像机按柜内实际位置摆进一张图里点图标看实时值、点按钮直接控制。视频监控页支持通道一至通道四切换硬件编解码保证四路同时预览不卡顿回放按时间轴拖动。电能分析页展示三相电压、电流、功率曲线配合多功能电表数据可以看出一相偏载这类问题。联动抓拍入口单独放一个图标点进去就是预设的设备报警联动抓拍记录按时间倒序列出图片和短片。触屏上的所有操作都要落操作记录谁在什么时候手动开了风机、把空调阈值从 35 ℃ 改成了 38 ℃。这条记录在事后追责和答辩演示时都用得上别省。4. 联动控制与告警闭环本地离线逻辑如何与远程遥控共存联动是这套系统的核心卖点也是最容易做成「演示时能用、现场就瘫」的部分。原因通常只有一个规则配置在平台侧站端只负责执行单条命令。一旦通信中断平台看不见、站端不敢动联动直接失效。4.1 联动规则表设计规则必须先落表再落代码。表格里至少要写清楚触发源、判断条件、动作对象、延时和优先级。下面是我常用的字段结构和几条典型规则。触发源条件动作延时优先级柜内温度 35 ℃ 启动 30 ℃ 停止空调 DO3持续 60 s中柜内温度 40 ℃风机 DO1 声光 DO6持续 30 s高柜内湿度 80% RH 启动 65% 停止除湿机 DO5持续 120 s中SF6 浓度超过设定值风机 DO1 声光 DO6立即最高水浸开关量闭合给排水泵 DO4 声光 DO6立即最高红外双鉴布防时段触发摄像机预置位 录像 声光 DO6立即高风机运行反馈DO1 输出后 10 s 无反馈产生设备故障告警10 s中这张表要支持一对多、多对一、多对多。SF6 泄漏一条触发源同时驱动风机和声光是一对多水浸开关量和电缆夹层水位越限都能启动排水泵是多对一烟感加红外双鉴同时成立才抓拍是多对多。配置用结构化格式存别写成散落在代码里的 if-else。{ ruleId: R-0012, enabled: true, trigger: { type: analog, point: temp, op: gt }, on: { value: 35.0, holdSec: 60 }, off: { value: 30.0, holdSec: 120 }, actions: [ { type: do, point: DO3, mode: hold }, { type: notify, channel: platform, level: warning } ], priority: 50, workMode: auto }on和off分开配置是为了做死区holdSec是持续时间mode区分保持型和脉冲型输出priority用于冲突仲裁——SF6 报警优先级高于温度两者同时触发时风机只能开不能关。workMode留出auto/manual/disabled三种状态检修时切到manual避免人在柜前干活被自动启动的风机吓一跳。4.2 本地联动逻辑实现联动引擎跑在监控主机上不依赖网络。核心逻辑不复杂难点在防抖、死区和优先级仲裁。from dataclasses import dataclass, field import time dataclass class Rule: point: str on_value: float off_value: float do_point: str hold_sec: int priority: int state: int 0 # 0 未触发 1 已触发 since: float 0.0 # 本次状态进入时间 hold_from: float 0.0 # 条件连续成立起始时间 def evaluate(rule: Rule, value, now, do_write, offlineTrue): 单条联动规则求值。 offlineTrue 表示与平台通信中断此时只允许本地自动逻辑生效。 返回新的 state便于上层做优先级仲裁后统一输出。 if rule.state 0 and value rule.on_value: if rule.hold_from 0.0: rule.hold_from now elif now - rule.hold_from rule.hold_sec: do_write(rule.do_point, 1, rule.priority) rule.state, rule.since, rule.hold_from 1, now, 0.0 elif rule.state 1 and value rule.off_value: if rule.hold_from 0.0: rule.hold_from now elif now - rule.hold_from rule.hold_sec: do_write(rule.do_point, 0, rule.priority) rule.state, rule.since, rule.hold_from 0, now, 0.0 else: rule.hold_from 0.0 # 条件中断即清零避免毛刺累积 return rule.statehold_sec的作用是过滤开门瞬间的温度尖峰和传感器毛刺没有它风机一天能被触发几十次。hold_from在条件中断时立刻清零这样「连续成立」才是真的连续而不是累计成立。do_write带上priority下层在多个规则争抢同一个 DO 时取优先级最高的那条低优先级的关闭请求直接被丢弃。offline参数看着没用到实际是在do_write里判断的离线状态下拒绝一切人工遥控命令只放行本地自动动作防止平台恢复瞬间把积压的遥控指令一股脑下发。这里有个血泪经验手动模式和自动模式必须互斥且有超时。运维人员手动开了风机两小时后忘了切回自动第二天温度报警也没人管。我的做法是手动操作后 30 分钟自动回落界面上给个倒计时提示比事后追查日志省事。4.3 告警记录与历史数据从告警到录像回放的链路告警必须是一条完整记录不能只是一行日志。每条告警记录事件性质、事件对象、事件内容、发生时间、事件原因和补充描述同时关联当时的抓拍图和录像片段。平台侧收到告警后自动弹出对应画面并发出声音提示值班人员点一下就能看到现场。存储上分两张表遥测和告警分开压缩策略不同CREATE TABLE t_telemetry ( station_id VARCHAR(32) NOT NULL, point_code VARCHAR(32) NOT NULL, ts TIMESTAMP NOT NULL, value NUMERIC(12,3), quality SMALLINT DEFAULT 0, -- 0 正常 1 可疑 2 无效 seq BIGINT, PRIMARY KEY (station_id, point_code, ts) ); CREATE TABLE t_alarm ( alarm_id BIGSERIAL PRIMARY KEY, station_id VARCHAR(32) NOT NULL, point_code VARCHAR(32), level SMALLINT, -- 1 提示 2 警告 3 严重 content VARCHAR(256), cause VARCHAR(256), occur_ts TIMESTAMP NOT NULL, clear_ts TIMESTAMP, media_path VARCHAR(512) -- 关联抓拍图或录像索引 );遥测表主键带上station_id和point_code是为了让「某站某点某时段」的曲线查询直接走索引。quality字段在画曲线时要区分颜色无效点不能当 0 画否则曲线会出现一个深坑看图的人会以为设备真的掉到 0。告警表里cause单独一列因为「原因」和「内容」在运维复盘时是两个问题内容是现象原因是判断。media_path存相对路径媒体文件本身放对象存储或本地磁盘别往数据库里塞二进制。平台侧还有一组统计指标值得在方案里写清楚验收时直接用得上完整性等于实收点数除以应收点数及时性等于时延不超过两个采集周期的记录占比一致性靠站端缓存序号与平台入库条数比对。三个数每周出一张报表比任何口头汇报都有说服力。5. 常见问题排查传感器误报、联动失效与通信中断的五个坑5.1 同一柜内两点温度差出 8 ℃现象是同一台箱变里上下两个温湿度探头读数长期差 6 到 8 ℃平台侧判断不出哪个是真的。原因多半在安装位置一个装在柜顶靠近出风口一个贴着柜壁靠近发热的母排测的根本不是同一个环境。探头没有防辐射罩时阳光直射也会把读数抬高三五度。解决办法是统一安装高度和位置距离发热元件不小于 30 cm避开空调出风口和柜门开启范围必要时加装百叶防辐射罩。标定时把两个探头放在同一环境静置 30 分钟偏差超过 2 ℃ 的换掉不要指望靠软件补偿修正。5.2 联动只在平台侧生效断网就瘫现象是演示时点哪动哪现场一拔网线风机就不受控了。原因是联动规则只配置在平台侧站端只接收执行命令本地没有规则表。解决办法是把规则表整体下发到监控主机站端维护一份本地副本并支持离线求值平台只做规则编辑和下发入口。改造完成后必须做断网演练拔掉上行链路人为把温度传感器加热到越限看风机是否在延时后启动。这一步不做方案里写的「本地联动」就只是纸面上的。5.3 通信中断后历史曲线出现空洞和重复点现象是断网一小时后恢复曲线里既有一段空白又有几个点重复出现两次。原因是站端缓存没有按序号补传恢复后只能从当前时刻重新开始或者补传时没有去重同一帧被写了两遍。解决办法是每条采集记录带自增seq缓存结构按seq顺序写入恢复后从断点序号开始补传平台侧建唯一索引重复的seq直接丢弃。补传带宽要限速别一恢复就把几天的缓存全推上去把 4G 链路堵死。5.4 告警时间与录像时间对不上现象是平台显示 14:03:20 有人闯入点开录像画面里的人在 14:05 才出现。原因是站端与平台没有统一对时监控主机和摄像机各自用自己的时钟时间偏移几分钟很常见。解决办法是全站启用 NTP 对时监控主机、摄像机、平台服务器指向同一时间源对时周期不长于 1 小时。录像检索时以站端时间戳为准平台侧只做展示不重新打时间。调试阶段可以写个小脚本同时抓一次站端时间和平台时间比对偏差超过 2 秒就查对时配置别等到验收当天才发现。5.5 DO 长期吸合把继电器和空调都搞坏了现象是用了半年空调压缩机频繁启停后损坏或者某一路 DO 的继电器触点粘死命令下了设备不停。原因有两个一是阈值没有死区温度在 35 ℃ 上下抖动空调被反复启停二是保持型输出被误配成脉冲型或者脉冲宽度设成了几十秒继电器长期通电发热。解决办法是启动和停止阈值至少拉开 3 到 5 ℃并加持续时间判断空调这类设备用保持型输出并在逻辑里加最短运行时间比如启动后 5 分钟内不允许停止风机、水泵这类用脉冲型脉宽控制在 1 秒左右。DO 回路上建议加中间继电器过渡让监控主机驱动小继电器、小继电器驱动接触器别让主机板载触点直接带负载。6. 验收与答辩用一份自测清单把四遥跑通到了这一步方案写得再漂亮也要靠一次实测数据收尾。我一般会在验收前一周自己先跑一遍清单把每一项都留下截图或日志答辩时按清单讲比讲架构图更能让人信服。验收项操作方法通过标准遥测准确性用标准温湿度计与平台读数同环境比对偏差 ≤ 2 ℃ / 5% RH遥信变位上送手动触发水浸、门磁各 3 次3 次全部上送时间戳误差 ≤ 2 s遥控双确认平台远程启动风机观察 DO 与 DI 反馈输出 10 s 内收到运行反馈遥调回读把温度上限改为 38 ℃ 后回读站端配置文件与平台显示一致本地联动断网状态下加热至越限延时后风机自动启动并存本地记录断网补传拔链路 30 分钟后恢复曲线无空洞、无重复点告警联动抓拍触发红外双鉴报警前后各 10 s 录像可回放报表导出导出任意一天历史数据Excel 可打开点数与曲线一致断网演练这项一定要单独留时间。做法很简单拔掉上行光纤用吹风机对着温湿度探头加热到 40 ℃ 以上观察风机是否在设定延时后启动同时在本地触屏上确认有告警记录恢复网络后再检查缓存是否补齐。整个过程录一段屏答辩时直接放比口头解释十遍都管用。答辩提问里出现频率最高的是三个为什么温度阈值定 35 ℃、为什么联动要放在站端、DO 容量怎么算。第一个回答结合柜内设备允许运行温度和当地夏季极端工况第二个回答断网自治顺带说一句「平台只做规则下发不做实时动作」第三个把点位表和 20% 预留量翻出来。这三个问题答顺了基本盘就稳了。从那以后我每次做这类方案都会在出图之前先把点位表和联动表填满再倒推需要多少路 DI/DO、几路 RS485、要不要扩展采集器。架构图画得再好看点位算错一样得返工。这套文档的结构就是上面这几章的顺序站端、平台、移动端三部分拆开你可以直接按自己的项目编号替换成对应章节。希望帮到你。本文还有配套的精品资源点击获取