简介箱变综合智能在线监控系统.doc 面向电力运维人员及配电房、箱式变电站管理人员聚焦箱变环境温湿度、烟雾与防盗监测以及遥测、遥信、遥控、遥调四类远程能力可用于安全监控、设备状态监测与安全预警方案的学习与参考。压缩包内仅含1个doc文档约2.2MB以方案说明文字为主覆盖系统概述、应用场景、分布式模块化架构以及配电房一体化监控装置的处理器与接口配置。文档依次阐述数据与状态监测、风机灯具及空调远程控制、实时告警、历史数据曲线查询与报表导出、设备联动抓拍录像等功能并给出软件平台、移动端与终端触屏的配套设计便于读者理解从站端采集到平台管理的整体链路。已有649人学习下载适合需要编写箱变监控技术方案或选型说明的工程人员参考。1. 需求先行箱变「可观、可测、可控」为什么不能靠加人巡检先从一个具体的账算起。城区配电网络里的箱式变电站预装式变电站散落在路口、小区、园区单点无人值守靠人跑一圈巡检一天覆盖十几台就到头了遇到高温、进水、烟雾这类突发情况等巡检员赶到现场最佳处置窗口早就过了。箱变综合智能在线监控系统要解决的就是这件事以箱变内的环境温湿度、烟雾、水浸、红外防盗和设备状态为监测对象用配电房一体化监控装置把传感器数据汇聚起来本地屏实时显示同时上送软件平台与移动端落地遥测、遥信、遥控、遥调四项能力。这套结构适合两类人直接拿去改做电力物联网方向毕设或课设的学生以及要给配电房出一份可交付监控方案的工程人员。2. 需求拆解与总体架构站端、平台、移动端三层怎么分工很多方案书写到架构这一章就开始画大框三层五层一摆看着完整但真到联调阶段就发现没人说得清哪一层该干什么。箱变监控这类系统的架构其实不复杂难点在于职责边界必须切干净哪些能力必须留在站端哪些可以放到平台哪些只是移动端的展示壳子。边界一旦模糊后面所有问题都会以「现场不动作」的形式暴露出来。我的习惯是先不碰架构图而是把需求文档里的功能条目一条条拆成「谁产生数据、谁处理数据、谁消费数据」拆完再回头看架构三层结构基本就自己浮出来了。下面按这个顺序走。2.1 把「四遥」拆成可以验收的功能条目「四遥」是个很抽象的提法写在方案书里没问题但没法验收。把它翻译成具体量、采集方式和验收动作才能变成开发任务和测试用例。我通常会在设计阶段就把这张表定下来后面点表、数据库字段、接口报文全部从它派生。四遥分类具体监测量采集方式验收动作遥测箱变内温度、湿度、SF6/O2 浓度、电缆夹层水位、三相电压/电流/功率RS485 传感器、AD 输入、电能表逐点比对现场仪表读数与平台显示值遥信水浸告警、红外双鉴、烟感、门磁、设备运行/停止状态、通信链路状态DI 输入、传感器开关量逐一触发平台告警列表须出现对应条目遥控风机启停、灯具启停、空调启停、水泵启停、摄像机 P/T/ZDO 输出、IPC 云台指令平台下发现场设备实际动作并回传状态遥调告警阈值、空调启停温度点、联动关系、轮询周期平台下发参数帧改一次阈值触发一次越限观察告警是否按新阈值产生这张表有个隐藏价值它把「遥调」从一句玄学话变成了四个具体参数。遥调是四遥里最容易被忽略、也最容易在答辩时被追问的一项——远程改阈值到底改的是装置里的哪个寄存器、改完断电是否保留这些细节写清楚方案的可信度立刻不一样。2.2 三层架构的职责边界站端、平台、移动端各管什么按前面拆出来的条目系统天然分成三块。站端系统部署在箱变低压侧负责接入环境传感器、安防传感器、视频监控装置做本地计算、本地显示、本地联动再通过光纤或 4G/5G 无线上送。软件平台是基于 PC WEB 的应用与数据管理平台承担跨站点的状态监测、环境实时监控、安防监控、火灾消防信息的集中展示和集中控制。移动客户端是移动 WEB 和移动 APP 形态的终端界面做的是环境安全监测、设备控制、曲线查询这类轻量操作。职责划分上我一般这么切站端保证「一定能动」平台保证「看得全、管得住」移动端保证「随手能看、紧急能停」。三者的功能看起来有重叠比如都能看温湿度、都能控风机但重叠部分的数据源必须唯一——所有实时值都来自站端的最后一次采集平台和移动端不各自轮询设备。这一点不写清楚后面就会出现平台显示 28℃、手机显示 31℃ 的尴尬场面用户第一反应是「这系统不准」实际是两个通道各查各的。模块化则体现在功能域上环境监测、安防监视、视频监控、设备控制、告警管理、历史数据每个域在站端、平台、移动端各有一份实现接口完全一致。这样做的直接好处是某个站点只配了环境传感器没配摄像机平台侧把视频模块关掉即可其余模块照常运行不需要为每个站点单独裁一套代码。站端向平台的上行报文我一般约定成四类结构固定避免后期字段乱加# 站端 - 平台 上行报文约定字段名即数据库列名减少映射层 UPSTREAM { telemetry: { # 遥测按点位批量上报 station_id: ST-0001, ts: 1730000000, # 采集时间戳秒级 points: {TEMP01: 31.4, HUMI01: 62.0, SF6_01: 0.0} }, signal: { # 遥信变位上报 周期全量 station_id: ST-0001, points: {DI_WATER: 0, DI_INFRARED: 1, COMM_OK: 1} }, alarm: { # 告警事件性质/对象/内容/时间/原因/描述 六要素齐全 station_id: ST-0001, level: major, object: DI_WATER, content: 电缆夹层水浸告警, reason: 水位开关闭合, ts: 1730000000 }, heartbeat: {station_id: ST-0001, ts: 1730000000, offline_ctrl: 1} }四个报文类型对应四张表字段不做二次加工平台入库时不需要写转换逻辑联调阶段能省掉大量对字段的时间。offline_ctrl这个字段是站端自治状态的标志位1 表示站端正在离线运行本地联动平台看到这个值就知道该站点的遥控指令暂时不可靠界面上要给出提示。2.3 站端自治断网后系统还必须保住哪三件事分布式架构里最容易被写漏的一条是站端在通信中断时到底还能干什么。这条如果只在方案书里写一句「具备本地联动能力」验收时基本等于没有。我会把它拆成三件必须保住的事逐条做验证。第一件本地采集与本地显示不能停。温湿度、烟感、水浸这些量继续按周期采集7 寸或 10.1 寸的工业触摸屏上继续刷新实时值运维人员到现场打开柜门就能看到当前状态而不是面对一块黑屏。第二件本地联动控制不能停。温度超过 35℃ 自动启动空调降温、SF6 泄漏自动启动风机并声光报警、水浸报警自动启动给排水这些逻辑必须跑在装置本体上不能放在平台侧。放在平台上断网就等于断了保护。第三件本地告警与本地存储不能丢。告警记录写本地库联动抓拍的图片和录像存 TF 卡或本地硬盘通信恢复后按时间戳补传。补传机制要带幂等键避免重复入库。这三件事在实现上对应一个很朴素的状态机站端维护一个online/offline标志由心跳超时切换所有遥控指令的下发路径都先看这个标志。离线时平台指令直接拒绝并回一条「站端离线」而不是默默发出去等超时——后者在现场排查时非常折磨人属于典型的黑匣子体验。提示站端自治的三件事建议在方案书里单独列一节并配一条验收项「断网 30 分钟后恢复检查本地告警记录与补传数据是否完整」。这一条写进去方案的专业度会明显不同。3. 站端硬件设计一体化监控装置的选型与接入清单硬件这一章在很多方案里会被写成产品参数罗列读起来像说明书。真正有用的是把参数翻译成设计约束处理器选到什么档位够用、接口留多少余量、点位表怎么排。下面按选型逻辑而不是产品清单来讲。3.1 主控选型为什么工业级双核起步、编解码要硬件做箱变监控装置的工作负载有两块是吃资源的一是多路视频接入与本地录像回放二是多路 RS485 轮询加联动逻辑的实时计算。这两块性质不同前者是持续的大吞吐后者是周期性的小计算但要求响应及时。视频这块4 路高清 IPC 接入、4 路实时预览与本地存储回放如果靠软件编解码CPU 占用会直接顶满联动逻辑的响应就会被拖慢表现出来就是「报警了但风机晚启动十几秒」。所以选型上硬件编解码是硬要求不是加分项。处理器我一般看工业级 Cortex-A9 双核或四核这一档双核能跑起来四核在多路视频同时预览时余量更舒服。存储和接口同样要看实际TF 卡接口用于本地录像和告警图片容量按「4 路 × 7 天」估低于这个天数的方案在现场基本会被要求返工千兆以太网口用于光纤或局域网回传USB host 口留给调试和导出HDMI 与 LVDS 用于本地屏。这些不是参数炫技每一条都对应一个现场动作。3.2 接口预算表RS485、DI/DO、AD、IPC 的余量怎么留接口数量是最容易在设计阶段算错的地方。按一台箱变的典型配置列一张预算表比对着参数表拍脑袋可靠得多。接口类型装置能力典型占用建议余量RS4857 路温湿度 1 路、SF6/O2 1 路、水浸 1 路、电能表 1 路、预留扩展采集器 1 路保留 2 路空置DI 输入8 路可扩至 24 路烟感、红外双鉴、门磁、水泵状态、风机状态、市电失电首批不扩容扩容位预留在柜内DO 输出8 路可扩至 24 路风机、灯具、空调、水泵、声光报警器至少留 3 路AD 输入8 路温度变送器、湿度变送器4-20mA留 4 路IPC 接入4 路箱变内 2 路、柜门 1 路、周边 1 路满配不再增环境采集器扩展通过 RS485 总线最多 128 路单站点通常 816 路按站点规模分段DO 余量这一项特别值得强调。很多现场在调试阶段临时加一个声光报警器、加一路排水泵如果 DO 已经占满就只能换装置或者加继电器板工期立刻被动。我在做点位规划时会给 DO 至少留三路空位这一条属于血泪经验。RS485 总线能挂 128 路采集器是理论值实际工程里一条总线挂太多节点轮询周期会被拉长某一路掉线还会拖累整条总线的响应。我一般单条总线控制在 16 个节点以内超过就分段用不同 RS485 口并行轮询。3.3 点位表设计一张表管住传感器、联动与告警点位表是整个站端配置的核心传感器接入、联动规则、告警阈值、平台展示全部从这张表来。它同时是给开发看的配置、给调试看的清单、给验收看的依据。字段我通常这么定{ point_id: TEMP01, station_id: ST-0001, name: 箱变内温度, type: telemetry, source: {bus: RS485_1, addr: 1, func: 03, reg: 0}, unit: ℃, scale: 0.1, range: [-20, 80], alarm: {high: 45, high_deadband: 2, delay_s: 30}, linkage: [DO_FAN, DO_AIRCON], enable: true }几个字段需要解释。source描述物理采集路径bus是哪个 RS485 口、addr是从站地址、func是 Modbus 功能码、reg是寄存器起始地址调试时直接照这个去查。scale是缩放系数传感器原始值 314 乘以 0.1 得 31.4℃这个系数每个点位独立不要全局统一设一个。range用于坏点过滤超出量程的读数直接标为无效不参与联动也不入库否则一个传感器故障会引发一连串误动作。alarm里的high_deadband是死区触发阈值 45℃、回差 2℃ 意味着降到 43℃ 以下才复位这一项直接决定告警会不会反复抖动。delay_s是持续时间确认越限持续 30 秒才产生告警滤掉瞬时扰动。linkage字段把点位和 DO 通道绑起来联动关系在配置层可改不需要改代码。这也是前面说的「联动关系自由设置」的落地方式——不是给用户一个可视化编辑器就完事底层必须有这张表撑着。注意点位表的point_id一旦上线就不要改。它同时出现在数据库主键、告警记录、历史曲线、Excel 导出模板里改一次要牵动四五处属于典型的后悔药没处买。4. 采集、联动与四遥实现从寄存器到控制指令的完整链路设计定完剩下的是一条数据链路传感器寄存器 → 采集轮询 → 数据模型 → 联动判断 → 控制输出 → 告警归档。这条链路上每一环单独看都不难难的是异常情况下的行为一致性。下面的实现示例用 Python 写逻辑可以直接映射到装置侧的 C 或 Go 实现。4.1 采集层轮询调度与坏点处理轮询调度要解决的是「一条总线上挂十几个节点怎么保证每个点位的采集周期稳定」。最朴素的做法是顺序轮询简单但慢稍微工程化的做法是按点位优先级分组快变量温度、水浸这类联动触发源高频慢变量电能、累计量低频。import time POLL_GROUPS { fast: {interval: 2, points: [TEMP01, HUMI01, DI_WATER, DI_INFRARED]}, slow: {interval: 30, points: [METER_KWH, METER_U, METER_I]}, } def read_point(point): 按点位表读取单个点位返回 (value, valid) raw modbus_read(point[source][bus], point[source][addr], point[source][reg], point[source][func]) if raw is None: return None, False # 通信失败标记无效 value raw * point[scale] lo, hi point[range] if not (lo value hi): return None, False # 超量程判为坏点 return round(value, 2), True def poll_loop(): last {g: 0 for g in POLL_GROUPS} while True: now time.time() for gname, g in POLL_GROUPS.items(): if now - last[gname] g[interval]: continue for pid in g[points]: pt POINTS[pid] val, ok read_point(pt) if ok: cache[pid] (val, now) check_alarm(pt, val) # 有效值才进入告警判断 else: cache[pid] (cache.get(pid, (None, 0))[0], now) fail_count[pid] 1 if fail_count[pid] 3: # 连续 3 次失败才判通信故障 raise_comm_alarm(pid) last[gname] now time.sleep(0.5)这段代码有两个设计点值得说明。一是坏点处理通信失败和超量程都返回validFalse但两者的告警语义不同通信失败累计 3 次才报「采集通道异常」超量程直接报「传感器数据异常」前者可能是总线问题后者大概率是传感器本身坏了现场处理方式完全不一样不能混成一条告警。二是check_alarm只在有效值时调用避免传感器故障时用无效值去做联动判断这是误动作的主要来源之一。慢变量的 30 秒周期不是随便定的。电能类累计量变化慢高频采集除了浪费总线带宽没有收益而一条 16 节点的 RS485 总线如果全部按 2 秒轮询实际完成一轮的时间可能已经超过 3 秒快变量的「2 秒周期」就成了纸面参数。4.2 联动规则四类典型场景的触发与复位条件联动是这套系统里最容易被认可、也最容易出错的部分。触发条件好写复位条件常常被忘掉结果风机启动后再也不停或者声光报警器一直响到有人到现场手动复位。我一般把每条联动都写成「触发条件 复位条件 最小运行时长」三要素。温度联动箱变内温度超过 35℃ 启动空调降温这是需求里写死的点。工程上要补的是回差和最小运行时长温度降到 33℃ 以下停空调且空调一旦启动至少运行 5 分钟避免在阈值附近反复启停把压缩机搞坏。SF6 联动SF6 浓度越限或 O2 浓度低于设定值时启动风机并启动声光报警器。这条的关键是传感器安装位置——SF6 比空气重探头要装在柜体下部O2 探头同理装在顶部基本测不到东西。这一条我在现场见过不止一次翻车。水浸联动水位开关闭合触发给排水系统启动同时推送告警到平台。复位条件是水位开关断开并持续 60 秒防止水面波动导致排水泵频繁启停。入侵联动红外双鉴触发后关联摄像机自动转向目标区域并启动录像同时启动声光报警器。这条的难点在「关联摄像机」的映射关系需要在点位表里维护「探测器 → 摄像机通道 → 预置位」的对应关系一个探测器可以关联多台摄像机一台摄像机也可以被多个探测器触发。def evaluate_linkage(pid, value, now): pt POINTS[pid] rule LINKAGE_RULES[pid] active rule[active] if not active and value rule[on]: for do in rule[actions]: do_set(do, 1, sourcelinkage, min_runtimerule[min_run_s]) rule[active] True raise_alarm(pid, 联动触发, f{pt[name]} 越限 {value}{pt[unit]}) elif active and value rule[off] and now - rule[start_ts] rule[min_run_s]: for do in rule[actions]: do_set(do, 0, sourcelinkage) rule[active] False rule[start_ts] nowdo_set里带一个source参数用来区分这条输出是联动触发的还是人工遥控触发的。人工遥控期间联动要暂时让位否则运维人员在平台上停了风机两秒后联动又把它拉起来现场会以为系统失控。这个优先级规则必须在设计阶段就写进方案不能靠调试时临时打补丁。4.3 遥控与遥调下发链路的三道校验遥控是四遥里风险最高的一项因为它直接驱动现场设备。我的做法是下发链路强制三道校验身份与权限、站端在线状态、指令与当前状态的冲突检查。第一道权限。平台侧的操作账号分级普通查看账号不能下发控制指令控制类操作需要二次确认。方案里如果只写「支持远程控制风机、灯具、空调启停」验收时被问到「谁能控、怎么防误控」答不上来会很被动。第二道在线状态。下发前检查站端心跳离线直接拒绝并记录一条「遥控失败站端离线」。这一条比超时返回友好得多运维一眼能看出是通信问题还是设备问题。第三道冲突检查。比如空调已经处于运行状态再下发一次启动指令装置侧要幂等处理并回「当前状态已为目标状态」而不是机械地再动作一次。def remote_control(station_id, do_channel, target, operator): if not has_permission(operator, control): return {code: 403, msg: 无控制权限} if not station_online(station_id): log_fail(station_id, do_channel, 站端离线) return {code: 503, msg: 站端离线指令未下发} cur get_do_state(station_id, do_channel) if cur target: return {code: 200, msg: 状态已一致无需动作} seq send_command(station_id, do_channel, target, timeout8) if seq is None: log_fail(station_id, do_channel, 指令超时) return {code: 504, msg: 指令超时请核查现场} # 指令下发后必须回读实际状态不能只认发送成功 actual wait_state(station_id, do_channel, target, timeout10) return {code: 200 if actual target else 500, msg: 执行成功 if actual target else 执行未确认请人工核查}最后那段回读是整段代码里最重要的部分。「指令发送成功」和「设备真的动了」是两件事中间隔着继电器、接触器、设备本体三层。只认发送成功平台界面显示「已启动」但现场风机没转这种状态不一致在验收时会被直接判不合格。遥调的实现路径比遥控简单本质是写参数帧但有两点必须写进方案一是参数下发后要回读校验二是关键参数掉电保存。告警阈值、空调启停温度点这些改完如果断电丢失下次上电又回到默认值运维会以为系统有问题。4.4 数据落库与告警归档让事后追溯有据可查历史数据查询是需求里明确要求的按不同组合条件查询、曲线展示、告警列表、关联录像和照片直接查看、Excel 导出备份、报表打印、录像按通道/时间和区域检索。这些功能背后是一张设计得当的表结构。-- 遥测历史表按点位时间建联合索引支撑曲线查询和导出 CREATE TABLE t_telemetry ( id BIGSERIAL PRIMARY KEY, station_id VARCHAR(32) NOT NULL, point_id VARCHAR(32) NOT NULL, value NUMERIC(12,3), ts TIMESTAMPTZ NOT NULL, quality SMALLINT DEFAULT 0 -- 0 正常 1 坏点 2 补传 ); CREATE INDEX idx_tm_pt_ts ON t_telemetry (point_id, ts DESC); -- 告警表六要素齐全并挂接抓拍与录像索引 CREATE TABLE t_alarm ( id BIGSERIAL PRIMARY KEY, station_id VARCHAR(32) NOT NULL, object VARCHAR(64) NOT NULL, -- 事件对象 content VARCHAR(255) NOT NULL, -- 事件内容 level VARCHAR(16) NOT NULL, -- 事件性质一般/重要/紧急 reason VARCHAR(255), -- 事件原因 ts TIMESTAMPTZ NOT NULL, media_id BIGINT, -- 关联抓拍/录像 ack_by VARCHAR(64), ack_ts TIMESTAMPTZ ); CREATE INDEX idx_al_station_ts ON t_alarm (station_id, ts DESC);quality字段是补传机制的关键。站端离线期间的记录在本地缓存恢复后批量上送入库时标记为 2报表里能区分「实时采集」和「补传数据」。没有这个字段事后查数据时看到时间断档说不清是设备没采还是网络没传追溯就成了糊涂账。media_id把告警和抓拍录像关联起来。入侵告警触发时前后各若干秒的图像被捕获并存储告警列表里点进去直接看这条链路要打通到存储层不能只在界面上放个按钮。Excel 导出看似简单实际有个坑导出模板的列顺序要和平台界面一致点位名称用中文名而不是point_id否则交到运维手里没人看得懂。这个小细节在验收演示时很加分。5. 避坑与排查现场联调最容易翻车的五个点这一章按「现象 → 原因 → 解决」写。这五条都来自实际项目里反复出现的场景不是理论推演写在方案里能明显减少后期返工。5.1 现象RS485 点位时有时无一轮能读到下一轮读不到原因通常有三个层次。最表层是总线接线A/B 接反、屏蔽层单端接地没做好、终端电阻该装没装长距离总线上表现为随机丢包。中间层是节点数量超限一条总线挂了二三十个采集器轮询周期被拉长主站超时时间设得又短读不到就判失败。最深层是电源问题多个传感器共用一路 12V线损导致末端电压不足传感器工作不稳定。解决顺序是先测物理层用万用表量末端电压低于传感器最低工作电压就先解决供电再查终端电阻超过 100 米的 RS485 总线两端各加 120Ω最后调整轮询策略把单条总线节点降到 16 个以内超时时间按「最慢节点响应时间 × 节点数 × 2」设别用默认值。5.2 现象平台下发启动指令界面显示成功风机不转原因一般是 DO 通道直接驱动了接触器线圈。装置 DO 输出能力有限直接带感性负载浪涌电流会把继电器触点打粘第一次动作正常几次之后就粘连或者彻底不动作。还有一种情况是共地问题控制回路和装置不在同一参考地输出信号电平漂移接触器根本不吸合。解决办法是在 DO 和接触器之间加一级中间继电器线圈两端并续流二极管控制回路单独走一路电源并做好共地。方案里要把这条写进「配套集成设备」章节明确给出继电器板和电源模块的配置要求别等到现场再补。5.3 现象断网之后温度超标了但空调没启动原因是联动逻辑写在了平台侧。设计阶段如果没明确「联动必须跑在站端」开发图省事把规则放平台在线时一切正常断网就全线失效。这类问题在实验室里永远测不出来只有到现场断网才暴露。解决办法是把联动全部下放到站端装置的本地逻辑里平台的联动配置只作为「参数下发通道」把规则同步到站端实际执行在站端。验收时加一项断开上行网络人工制造一次温度越限观察空调是否按规则启动。这一项做不做方案的可信度差一个档次。5.4 现象告警列表里同一条告警反复出现一天几百条原因是阈值附近抖动加上没有死区和持续时间确认。温度在 35℃ 上下浮动每穿过一次阈值就产生一条告警水浸开关在水面波动时反复通断红外探测器被树枝扫到就触发。解决办法是三个参数一起上死区触发 35℃、复位 33℃、持续时间确认越限持续 30 秒才告警、告警抑制窗口同一对象 5 分钟内只产生一条新告警后续合并计数。这三个参数要能在平台上配置且配置项要写进遥调清单。告警风暴一旦发生运维会直接关掉告警功能那整套监控就白做了。5.5 现象告警抓拍的图片对不上时间事后查不到对应录像原因是站端、平台、摄像机三方的时钟不同步。摄像机用自己的时钟装置用自己的平台用服务器时间三者差几分钟抓拍图片上的时间戳和告警记录时间就对不上倒查录像时按时间检索根本找不到那一段。解决办法是统一时钟源。站端装置、摄像机、平台全部指向同一个时间源做 NTP 同步同步周期设成小时级抓拍和录像文件命名里带绝对时间戳而不是相对序号告警记录里同时存「设备本地时间」和「平台接收时间」两个字段排查时能看出链路延迟。这一条属于典型的平时看不出问题、出事时救命的设计。6. 验收与答辩用一张验收表证明系统真的能跑方案写得好不好最后都落在「能不能演示、演示的是不是真的」上。我通常会在交付前自己做一张验收表逐项走一遍走完这张表答辩时被问到哪里都不慌。验收项操作步骤通过标准遥测准确性现场温湿度计与平台显示同时读数偏差在传感器精度范围内超量程显示为无效遥信变位逐一触发水浸、红外、烟感、门磁平台 3 秒内出现对应告警恢复后自动复位遥控执行平台下发风机、灯具、空调启停现场设备实际动作回读状态一致遥调生效修改温度阈值与空调启停点按新阈值触发断电重启后参数保留本地联动断网后制造温度越限、SF6 越限、水浸站端独立完成联动本地屏有告警记录断网补传断网 30 分钟后恢复历史数据完整补传数据标记正确视频联动触发入侵告警摄像机转向预置位并录像告警可回看录像历史查询与导出按条件查询曲线、导出 Excel、打印报表数据一致中文点位名正确列顺序与界面一致走这张表有两个技巧。一是顺序不能乱先做遥测遥信这些「读」的操作再做遥控遥调这些「写」的操作最后做断网和联动这种破坏性测试否则前面刚配好的状态会被后面的测试打乱。二是每一项都要留证据截图、录像、导出的 Excel 文件答辩时被问到「你怎么证明联动真的在站端跑」直接放断网测试的录像比任何描述都管用。答辩环节最常被追问的三个问题我在准备时会提前想好答案。第一个是「为什么用分布式而不是集中式」答的是站端自治能力断网可运行、单点故障不影响全网。第二个是「联动逻辑放在哪一层」答站端执行、平台配置并给出断网验证的证据。第三个是「告警怎么防止误报和漏报」答死区加持续时间确认加抑制窗口三个参数并现场演示改阈值的效果。有个细节值得单独提演示前把平台界面的时间显示改成和现场一致把点位中文名、单位、量程都核对一遍。我见过演示时温度显示「314」没乘缩放系数的也见过单位标成「%」实际是「℃」的这类问题不影响系统功能但会让人瞬间对整套方案失去信任。从那以后我每次提交方案前都会强制走一遍这张验收表哪怕是给自己看的 Demo。表里每一行通过方案才有底气说「这套东西能落地」而不是「这套东西设计得挺完整」。希望帮到你。本文还有配套的精品资源点击获取