企业官网建设流程全解析

简介：面向箱式变电站运维与配电自动化学习者的技术文档，围绕箱变环境温湿度、烟雾、防盗及风机等设备远程控制需求，梳理综合智能在线监控系统的建设思路。内容从系统概述、应用场景与分布式模块化架构展开，说明站端采集、软件平台和移动客户端三部分如何协同，并介绍配电房一体化监控装置的接口、人机界面与离线联动能力；同时覆盖数据与状态监测、远程控制、实时告警、历史查询、系统联动和综合展示等功能。压缩包内共1个doc文件，约2.2MB，适合作为方案选型、运维培训或课程设计的参考资料。已有649人学习，读者可据此了解“四遥”实现方式、传感器接入、告警联动逻辑及典型电力设施监控部署要点。

1. 箱变监控不是装个摄像头：先把需求立住

箱式变电站撒在城网各个角落，一个运维班一天跑三四个点，等巡检出温度超标、水浸、烟雾，往往已经晚了。箱变综合智能在线监控系统要干的事很直接：把箱变里的温湿度、烟雾、防盗、设备状态采上来，本地屏看得见，平台上管得住，手机上查得到，形成遥测、遥信、遥控、遥调的闭环。这套方案适合两类人：做电力物联网、配电自动化方向毕设或课程设计的学生，需要一套结构完整、能演示、能答辩的系统；以及要交一份配电房智能化改造方案的从业者，需要知道站端怎么配、平台怎么分模块、验收怎么过。后面按实际搭建顺序展开，从架构、接口、联动规则一路落到验收。

2. 总体架构设计：三层结构与四遥闭环的职责划分

做这套系统第一个要拍板的问题不是选什么传感器，而是联动逻辑放在哪。放平台，网络一断风机就停摆；只放站端，平台又看不到全貌。站端保底、平台可编排，两边都放，这才是三层架构真正的由来。架构定错，后面接口、数据库、联动规则全要返工，所以这一章先把职责边界划清楚。

2.1 为什么是分布式加模块化，而不是一台工控机全包

箱变的特点是点多、分散、无人值守，单台工控机全包的方案在实验室跑得通，到了现场第一个雷就是网络。一个站点断网，如果采集、判断、控制全在平台侧，那这个站点就等于瞎了。分布式架构的核心不是赶时髦，是把「能不能活下去」这件事下沉到每个站点：站端自己采、自己判断、自己动作，平台只做汇总、展示和远程编排。

模块化的价值在分期建设。环境监测、安防监视、视频监控、设备状态这几块，实际项目里很少一次上齐，常见的是先上温湿度和烟感，第二年再加视频和电能分析。如果站端程序把这些功能写死在一个大循环里，加一路摄像头就要改主流程，测试成本极高。按模块拆开之后，环境采集、安防采集、视频接入、联动控制各自是独立的进程或线程，通过一块共享的内存快照交换数据，新增模块只要往快照里注册点位，不碰别人的代码。

这里有个容易被忽略的设计点：站端和平台之间的数据契约要提前定死。点位编码、数据类型、单位、时间戳格式，这几样一旦在站端和平台两边各写一套，后面联调就是血泪经验。我的做法是先出一份点位表 Excel，站端按表生成配置，平台按表建库，两边用同一个编码，联调时对不上的概率能降一大半。

2.2 站端、软件平台、移动端三层的职责边界

三层不是平均分的，站端最重，平台最杂，移动端最轻。职责划不清，最常见的翻车是「平台越权」——平台直接下发一个控制命令，站端不校验就执行，结果平台侧误操作直接把风机频繁启停，现场设备遭殃。正确的边界是：平台下发的是意图，站端执行前必须做合法性校验和互锁判断。

这张表最该盯的是最后一列。很多方案在答辩时被问「断网了怎么办」，答不上来，就是因为设计时没把断网当成常态。箱变现场用 4G 上送，信号抖动是家常便饭，站端必须能在无平台的情况下跑完整套联动逻辑，这是底线。

2.3 四遥在系统里的映射关系

「四遥」这个词在电力行业是老概念，但落到具体点位上，很多同学会混。遥测是连续量，遥信是开关量状态，遥控是开关量输出，遥调是参数下发。区分清楚的标准很简单：看数据方向和数据类型。遥测、遥信是站端往平台送；遥控、遥调是平台往站端下。遥测带小数，遥信只有 0/1。

把这张表和后面的点位表对上，站端程序的结构基本就出来了：一个采集线程负责遥测遥信，一个控制线程负责遥控遥调，中间用快照和命令队列连接。答辩时老师问「四遥怎么实现的」，直接指这张表和对应的两个线程，比背概念管用。

2.4 数据模型：点位表、告警表、操作记录表

数据模型是整套系统的骨架。点位表定义「有什么」，告警表记录「发生了什么」，操作记录表记录「谁动了什么」。三张表建好，平台侧的实时监视、历史曲线、报表导出基本都是查这三张表的不同视图。

-- 点位定义表：一个传感器或执行器一行，站端与平台共用同一份编码 CREATE TABLE point_def ( point_id VARCHAR(32) PRIMARY KEY, -- 点位唯一编码，如 ENV_TEMP_01 station_id VARCHAR(32) NOT NULL, -- 站点编号 point_type TINYINT NOT NULL, -- 1遥测 2遥信 3遥控 4遥调 device_addr SMALLINT, -- RS485 从站地址 reg_addr SMALLINT, -- 寄存器或通道号 unit VARCHAR(8), -- 单位：℃ / %RH / ppm scale DECIMAL(6,3) DEFAULT 1, -- 原始值乘系数，如 0.1 alarm_hi DECIMAL(10,3), -- 高限阈值 alarm_lo DECIMAL(10,3), -- 低限阈值 deadband DECIMAL(10,3) DEFAULT 0, -- 回差，防抖动用 enabled TINYINT DEFAULT 1 ); -- 告警记录表：每条告警一行，关联点位和站点 CREATE TABLE alarm_log ( alarm_id BIGINT AUTO_INCREMENT PRIMARY KEY, point_id VARCHAR(32) NOT NULL, station_id VARCHAR(32) NOT NULL, level TINYINT NOT NULL, -- 1提示 2一般 3严重 event_type VARCHAR(32), -- 越限 / 变位 / 通信中断 event_value VARCHAR(64), -- 触发时的值 occur_time DATETIME NOT NULL, recover_time DATETIME, -- 恢复时间，未恢复为空 ack_user VARCHAR(32), -- 确认人 snapshot VARCHAR(256) -- 联动抓拍图片路径 );

点位表里scale和deadband这两个字段值得单独说。scale是原始寄存器值到工程量的换算系数，温湿度变送器常见的是 0.1，电表可能是 0.01，配错一位小数点，平台上的曲线就是十倍偏差，这种问题在现场排查起来非常玄学。deadband是回差，温度到 35℃ 启动空调，如果 34.9℃ 就关，设备会反复启停，加 2～3℃ 的回差，动作次数能降一个数量级。

告警表里的recover_time和snapshot是很多同学会漏的字段。没有恢复时间，历史告警查询就没法算持续时长；没有抓拍路径，入侵告警只能看到一条文字，答辩演示时说服力差一截。

2.5 通信链路：光纤优先，4G/5G 兜底

箱变上送的链路通常两种：光纤和无线。有条件的站点走光纤，稳定、带宽大，视频和采集数据可以一起传；不具备布线条件的走 4G/5G，成本低、部署快，但要接受带宽和时延的波动。实际工程里的做法是光纤为主、无线为备，站端检测到主链路断开自动切换，切换过程本地联动不受影响。

链路设计里有个参数要提前定：心跳周期和断线判定时间。心跳太密浪费流量，太疏断线发现慢。我一般设 30 秒心跳，连续 3 次收不到判为断线，也就是 90 秒内能发现，对箱变这种场景够用。断线期间站端把采集数据写本地 TF 卡或 flash，恢复后按时间戳补传，平台侧按时间去重。

提示：补传数据一定要带原始采集时间戳，不要用补传时刻，否则历史曲线会出现一段「假平台」，验收时一眼就能看出来。

3. 站端采集与控制：一体化监控装置的接口配置与传感器接入

站端是整套系统真正干活的地方。这一章围绕一台配电房一体化监控装置展开，讲清楚接口怎么用、总线怎么扩、传感器怎么标、配置怎么写。选型上它基于 Cortex-A9 双核/四核工业级处理器，带硬件编解码，支持 4 路高清 IPC 接入和 4 路视频实时预览、存储、回放，本地配 7 寸或 10.1 寸人机交互界面。这些参数不是为了堆配置，而是对应四个实际需求：视频要能本地存、总线要能挂得多、断网要能自己跑、现场要能手动操作。

3.1 接口清单与选型依据

先把接口摊开看，再谈为什么这么配。下表是这台装置的实际接口和本项目里的用途，答辩时可以直接拿这张表讲「硬件资源怎么分配」。

选型的核心逻辑是「接口数量要留余量」。7 路 RS485 看着多，实际一个站点挂温湿度、烟感、水浸、SF6、电表就用掉 5 路，再扩就没了。DI/DO 可扩展到 24 路这点很重要，箱变的联动对象不止风机水泵，还有照明、除湿机、声光报警，8 路往往不够用。选型时按满配算，别按当前需求算。

3.2 RS485 总线扩展与 128 路采集器的地址规划

装置本身支持通过 RS485 总线扩展采集器，最多可支持 128 路环境参数采集器。128 这个数字不是随便挂的，它受三个因素约束：从站地址空间、轮询周期、总线负载。标准 Modbus 从站地址 1～247，理论够用，但实际轮询一遍 128 个从站，每个从站读 2 个寄存器，按 9600 波特率算，一轮下来接近 2 秒。如果要求 1 秒刷新一次，就得拆总线或者提波特率。

我的做法是按物理区域分总线：1 号口挂温湿度，2 号口挂安防开关量，3 号口挂电表，4 号口挂扩展采集器。地址按「总线号 × 100 + 序号」编，比如 1 号口第 3 个从站是 103，这样现场看地址就知道挂在哪条线上，排查时不用翻图纸。

# 用命令行工具扫描 1 号 RS485 总线上在线的从站，确认地址规划有没有冲突 # -p 指定串口，-b 波特率，-r 起始地址，-c 扫描数量 modbus_scan -p /dev/ttyS1 -b 9600 -r 1 -c 32 # 输出示例：地址 1、2、3 在线，4～32 无响应 # 若出现两个设备响应同一地址，说明拨码开关重复，必须现场改掉

扫描命令在调试阶段要跑一遍，尤其是采购的采集器出厂地址可能都是 1，装上去不拨码就是地址冲突，表现是数据时有时无，特别像玄学故障。上线前把每条总线的地址清单落到文档里，后面换设备直接照单拨码。

波特率的选择也有讲究。9600 兼容性最好，但慢；19200 是常用折中；38400 以上对线材和距离敏感，箱变内电磁环境复杂，不建议盲目提高。线材用屏蔽双绞线，屏蔽层在装置侧单端接地，总线两端各加一个 120Ω 终端电阻，中间节点不要加。

3.3 传感器接入与量程标定

箱变里要采的量和对应传感器，按监测对象分四类：

环境类包括温度、湿度、SF6/O2 浓度。温湿度变送器一般走 RS485，直接读寄存器；SF6/O2 浓度传感器有走 RS485 的，也有 4-20mA 输出的，后者接 AD 通道，需要做量程换算。安防类包括红外双鉴、门磁、水浸，都是开关量，接 DI。消防类主要是烟感，多数是开关量输出，少数是总线制。设备状态类包括风机运行反馈、断路器位置，也是开关量。

量程标定是容易翻车的一步。以 4-20mA 的 SF6 传感器为例，量程 0～1000ppm，对应 4mA 是 0ppm，20mA 是 1000ppm。AD 采集到的是原始码值，要先换算成电流，再换算成浓度。这一步如果系数写错，平台上显示 800ppm 实际可能只有 300ppm，告警阈值就完全失效。

注意：每个模拟量点位上线前必须做两点标定，用信号发生器给 4mA 和 20mA，看平台显示是否为量程下限和上限，偏差超过 2% 就要查系数和接线。

开关量输入要注意触发方式。红外双鉴输出常开还是常闭，不同厂家不一样，配置里要写清楚上升沿触发还是下降沿触发，否则平台上的状态是反的，人明明没进去却一直显示入侵。

3.4 点位配置文件示例

站端程序不把点位写死在代码里，而是读一份配置文件。这样现场加点位、改阈值不用重新编译，也方便和平台的点位表对齐。

{ "station_id": "XB-001", "poll_cycle_ms": 1000, "rs485": [ { "port": "/dev/ttyS1", "baud": 9600, "parity": "N", "devices": [ { "addr": 1, "model": "温湿度变送器", "points": [ {"id": "ENV_TEMP_01", "type": "AI", "reg": 0, "scale": 0.1, "unit": "℃"}, {"id": "ENV_HUMI_01", "type": "AI", "reg": 1, "scale": 0.1, "unit": "%RH"} ] } ] } ], "ad": [ {"id": "ENV_SF6_01", "channel": 1, "min_ma": 4, "max_ma": 20, "range_lo": 0, "range_hi": 1000, "unit": "ppm"} ], "di": [ {"id": "SEC_IR_01", "channel": 1, "meaning": "红外双鉴", "trigger": "rising", "debounce_ms": 200}, {"id": "SEC_WATER_01", "channel": 2, "meaning": "水浸", "trigger": "rising", "debounce_ms": 500} ], "do": [ {"id": "CTRL_FAN_01", "channel": 1, "meaning": "排风机", "pulse_ms": 0}, {"id": "CTRL_AIRCON_01", "channel": 2, "meaning": "空调", "pulse_ms": 0} ] }

几个参数说明一下。poll_cycle_ms是采集周期，1000ms 对箱变场景够用，设太小会增加总线负载。scale是原始值乘系数，0.1 表示寄存器读数除以 10 才是实际温度。debounce_ms是去抖时间，水浸这种信号容易因凝露短时导通，设 500ms 能过滤掉大部分误报。pulse_ms为 0 表示保持型输出，适合风机空调这种需要持续通电的设备；如果控制的是需要点动的设备，设成对应的脉冲宽度。

3.5 本地触屏与离线运行

本地 7 寸工业触摸屏不是装饰。箱变现场运维人员不一定带电脑，出了告警第一时间是在屏上确认和处理。屏上要能看实时数据、能手动控制、能查告警记录、能回放视频，这四件事齐了，现场处置才闭环。

触屏界面一般做几个固定页：主界面看温湿度和告警状态，3D 情景页看空调、风机、除湿机、烟感、摄像机的分布和状态，视频页按通道切换四路画面，电能分析页看三相电压电流功率曲线，联动抓拍页看报警前后的抓拍记录。这些页面在站端本地渲染，不依赖平台，断网时照样能用。

离线运行的关键是联动逻辑内置。当监控主机与远程服务器通信中断时，控制主机要能离线实现水泵、风机的联动控制。实现方式是把联动规则引擎放在站端，规则从本地配置加载，平台下发的规则只是覆盖或补充，不是运行的必要条件。这一点在方案里要写死，不然验收时被问「平台挂了这套系统还能不能报警」，回答会很被动。

4. 联动控制与告警规则：从阈值到动作的完整链条

联动是这套系统里最容易做成「演示能用、现场不敢用」的部分。原因不在技术，在规则设计太随意：温度一到就开空调，降一点就关，设备一天启停几十次；SF6 报警了风机也启动，但没人知道风机关没关、关了没有。这一章把联动拆成可配置的四要素，再给三条典型链路的完整实现。

4.1 把联动抽象成条件、动作、延时、复位四要素

任何一条联动规则，本质上都是「什么条件下、持续多久、做什么动作、什么条件下撤销」。四要素缺一个，规则就是残缺的。

条件（when）是触发判断，比如温度大于 35℃。动作（do）是执行输出，比如启动空调。延时（hold_s）是条件持续多久才动作，用来过滤瞬时毛刺，温度传感器被阳光直射一下冲到 36℃ 不应该立刻开空调。复位（reset_when + reset_do）是恢复条件，必须有回差，否则在阈值附近来回抖。

规则之间还要有优先级和互锁。烟感报警时，风机要不要开？如果箱变内真的着火，开风机等于助燃，这时候应该是关风机、启动声光报警、切断非消防电源。这类互锁不写进规则里，现场就可能出大事。我的做法是给每条规则一个优先级，高优先级规则生效时，低优先级的输出被强制锁定。

4.2 温度、SF6、水浸三条典型联动链

温度链：温度超过 35℃，持续 10 秒，启动空调降温；温度低于 32℃，持续 60 秒，关闭空调。回差 3℃，复位延时比触发延时更长，防止临界点频繁动作。同时监测空调运行反馈，启动命令发出后 30 秒内没收到运行信号，报「空调启动失败」告警，这条比单纯报温度超限有用得多。

SF6 链：SF6 浓度超过 1000ppm，持续 5 秒，启动排风机、启动声光报警器、推送告警；浓度低于 800ppm 且持续 5 分钟，关闭风机。SF6 比空气重，泄漏后聚集在电缆沟和低处，所以风机启动后要持续运行一段时间再停，不能浓度一降就关。

水浸链：水浸开关量触发，持续 500ms（去抖），启动给排水系统、推送严重告警；水浸信号消失持续 60 秒，关闭排水。水浸往往伴随凝露误报，去抖时间要比其他开关量长，同时可以加一个「湿度同时高于 90%」的辅助条件来确认。

三条链的共同点是都有延时、都有复位条件、都有执行反馈校验。只写「条件满足就输出」的规则，是课程设计水平；加上延时、回差、反馈，才接近工程可用。

4.3 告警分级、去抖与事件记录字段

告警要分级，不分级的话平台上一片红，运维人员会直接忽略。一般分三级：提示级（通信闪断、电池电压偏低）、一般级（温湿度越限、风机故障）、严重级（烟感、SF6 泄漏、水浸、非法入侵）。严重级要联动声光、要推送手机、要在平台置顶。

去抖有两种做法：时间去抖和次数去抖。时间去抖是条件持续 N 秒才确认，次数去抖是连续 N 个采集周期都满足才确认。开关量用时间去抖更直观，模拟量用次数去抖更稳。阈值告警还要加死区，也就是前面说的回差，避免在阈值线上反复产生告警和恢复记录。

事件记录字段至少包括：事件性质、事件对象、事件内容、发生时间、事件原因、关联的录像和图片。这六项齐了，事后追溯才查得清。很多方案只记「温度告警」四个字，过一周再问「当时多少度、持续多久、处理了没有」，全查不到。

4.4 离线兜底与通信中断处理

通信中断在箱变场景是常态，不是异常。站端要检测两条链路：上行到平台的链路，下行到传感器的总线。上行断了，本地联动继续跑，数据缓存补传；下行某条总线断了，对应点位标为「通信中断」，不能沿用最后一次值做联动判断，否则会拿一个过期温度去决定开不开空调。

这里有个细节：通信中断本身也要产生告警，但级别不能太高，否则 4G 抖一下就是一条严重告警。我的做法是上行断线超过 5 分钟报一般级，下行总线断线立即报一般级，因为总线断了说明现场设备真出问题了。

4.5 规则引擎实现示例

下面这段是站端规则引擎的核心结构，Python 写出来是为了讲清楚逻辑，实际部署可以换成 C 或 Go，结构一样。

# 站端联动规则引擎：每个采集周期对快照做一次规则匹配 # snapshot 是当前所有点位值的字典，outputs 是待下发的控制命令 RULES = [ { "id": "R_TEMP_HIGH", "level": "WARN", "when": lambda s: s.get("ENV_TEMP_01", 0) > 35.0, # 触发条件 "hold_s": 10, # 持续 10 秒才动作 "do": {"CTRL_AIRCON_01": "ON"}, # 启动空调 "reset_when": lambda s: s.get("ENV_TEMP_01", 0) < 32.0, # 回差 3℃ "reset_hold_s": 60, # 复位也要持续 60 秒 "reset_do": {"CTRL_AIRCON_01": "OFF"}, "feedback": {"point": "DI_AIRCON_RUN", "timeout_s": 30, "fail_msg": "空调启动失败"} }, { "id": "R_SF6_LEAK", "level": "CRITICAL", "when": lambda s: s.get("ENV_SF6_01", 0) > 1000, "hold_s": 5, "do": {"CTRL_FAN_01": "ON", "CTRL_ALARM_01": "ON"}, "reset_when": lambda s: s.get("ENV_SF6_01", 0) < 800, "reset_hold_s": 300, # 持续通风 5 分钟再停 "reset_do": {"CTRL_FAN_01": "OFF", "CTRL_ALARM_01": "OFF"} }, { "id": "R_WATER", "level": "CRITICAL", "when": lambda s: s.get("SEC_WATER_01") == 1, "hold_s": 0.5, # 去抖 500ms "do": {"CTRL_PUMP_01": "ON"}, "reset_when": lambda s: s.get("SEC_WATER_01") == 0, "reset_hold_s": 60, "reset_do": {"CTRL_PUMP_01": "OFF"} } ] def evaluate(snapshot, now, state): """state 保存每条规则的计时状态，返回本次要下发的命令列表""" commands = [] for rule in RULES: st = state.setdefault(rule["id"], {"on_since": None, "off_since": None, "active": False}) # 触发分支：条件满足并持续够时间，且当前未激活 if not st["active"] and rule["when"](snapshot): st["on_since"] = st["on_since"] or now if now - st["on_since"] >= rule["hold_s"]: st["active"] = True st["off_since"] = None commands.extend(_to_cmd(rule["do"], rule["id"])) elif not rule["when"](snapshot): st["on_since"] = None # 条件消失，计时清零 # 复位分支：已激活且复位条件满足并持续够时间 if st["active"] and rule["reset_when"](snapshot): st["off_since"] = st["off_since"] or now if now - st["off_since"] >= rule["reset_hold_s"]: st["active"] = False st["on_since"] = None commands.extend(_to_cmd(rule["reset_do"], rule["id"])) elif st["active"]: st["off_since"] = None return commands

这段代码的几个设计取舍值得讲。hold_s和reset_hold_s分开，是因为触发和复位对时间的要求不一样，触发要快、复位要稳。on_since用「或」赋值，保证计时起点只记第一次满足的时刻，中间抖动不会重置计时。复位条件建立在active状态之上，规则没激活时不会执行复位动作，避免误关。

规则引擎只负责算命令，不直接操作硬件。命令进队列，由控制线程做互锁校验后下发，这样规则可以随便改，硬件操作始终走同一条路径。互锁校验的典型例子：烟感告警激活时，即使温度规则算出要开风机，控制线程也会因为「消防优先」锁而拒绝执行。

5. 避坑与常见问题排查

这套系统从实验室到现场，翻车点集中在几个固定位置。下面五条是我踩过或者见别人踩过的，按「现象 → 原因 → 解决」写，照着排查能省不少时间。

5.1 温度到了 35℃ 空调不启动

现象：平台显示箱变温度 36℃，联动规则配的是超过 35℃ 启动空调，但空调没反应，手动在平台上点启动又能用。

原因通常有三个：一是站端规则没加载，平台下发的规则只存了库，没同步到站端；二是 DO 通道配错，规则里写的是通道 2，实际接线在通道 3；三是空调本身有保护，断电后需要人工复位，装置发了命令但空调不执行。

解决顺序是先从站端日志看规则有没有触发、命令有没有下发，再看 DO 通道对应关系，最后到现场量继电器触点。我一般会在调试阶段加一个「手动强制输出」功能，绕过规则直接驱动 DO，能快速区分是规则问题还是硬件问题。

5.2 RS485 挂多了以后数据丢包

现象：单挂三五个传感器时数据正常，挂到二十个以上开始出现随机丢包，某些点位时有时无，换个采集周期又好了。

原因：总线负载过高或者信号反射。9600 波特率下轮询几十个从站，一轮时间变长，如果采集周期设得比一轮时间还短，就会出现上一轮没读完下一轮又开始。另外总线长了没加终端电阻，信号反射会导致误码。

解决：先算一轮轮询的理论时间，采集周期至少设成轮询时间的 1.5 倍；总线首末端加 120Ω 终端电阻；从站多了拆总线，别硬挂一条；线材换屏蔽双绞线，屏蔽层单端接地。如果还不行，把波特率降到 4800 试一次，能通说明是信号质量问题，不是协议问题。

5.3 入侵抓拍抓到的不是入侵时刻

现象：红外双鉴触发后，平台上的联动抓拍图片是触发之后几秒的画面，人已经走过去了，或者拍到的是空画面。

原因：抓拍命令是告警产生后才发给摄像机的，摄像机从收到命令到出图有延迟，加上网络传输，几秒钟就过去了。如果摄像机没开预录，根本抓不到触发前的画面。

解决：摄像机要开预录缓冲，一般设 5～10 秒；抓拍时取「触发前 5 秒到触发后 5 秒」的片段，而不是单帧；站端和摄像机做时间同步，NTP 对时周期设短一点，否则图片上的时间戳和告警时间对不上，验收时说不清。这一点在方案里要写成明确要求，不能指望现场临时调。

5.4 告警风暴把平台刷屏

现象：某个传感器接触不良，一秒内产生几十条告警和恢复记录，平台告警列表被刷满，真正严重的告警被淹没。

原因：阈值附近抖动加上没有去抖和抑制。开关量接触不良会产生毫秒级通断，模拟量在阈值线上波动会产生反复越限。

解决：开关量加时间去抖，配置里debounce_ms设 200～500ms；模拟量加回差，deadband设量程的 2%～5%；同一点位在 N 秒内重复告警做抑制，只记第一条和最后一条；平台侧做告警合并，同一个点位连续告警折叠显示。去抖参数不能一刀切，水浸和烟感的去抖时间就不一样，按信号特性分别配。

5.5 历史曲线出现断点或台阶

现象：历史曲线中间缺一段，或者某段时间的值是一条水平直线，明显是假数据。

原因：断点通常是通信中断期间没有补传，或者补传时时间戳用了补传时刻导致平台去重时丢掉。水平直线多半是采集失败后程序沿用了上一次的值，没有标无效。

解决：断网期间数据写本地缓存，恢复后带原始时间戳补传；采集失败的点位值要置为无效并打质量位，平台画曲线时遇到无效点断开，不要连直线；数据库里存原始值和采集时间，展示层再做插值和聚合。这一条在验收演示时特别容易被看出来，曲线一断老师就会问，提前做好比现场解释强。

6. 验收与答辩：把「能跑」变成「能证明」

验收这件事，很多人吃亏在「系统确实能跑，但讲不清楚」。答辩现场时间有限，评委不会等你慢慢操作，所以要提前准备一套可复现的演示脚本和一张验收对照表。我的习惯是把验收拆成四块：采集完整性、控制有效性、联动正确性、数据可追溯。

采集完整性看的是「该有的点位一个不少、数值在合理范围」。演示时打开平台实时监视页，对照点位表逐项核对，重点展示温湿度、SF6、水浸、烟感这几类。可以人为制造一次越限，比如用热风枪吹温湿度传感器，看平台曲线是否在几秒内响应。

控制有效性看的是「命令下得去、状态回得来」。演示远程启动风机，然后看 DI 反馈是否变成运行状态，再看本地触屏上是否同步。这一步能证明遥控链路是闭环的，不是只发命令不看结果。

联动正确性看的是「条件满足后动作对、复位也对」。提前配好一条温度联动，现场触发，展示空调启动、告警产生、抓拍生成、复位后自动关闭。如果时间允许，再演示一次断网联动：拔掉上行网线，重复触发，证明站端仍然动作。

数据可追溯看的是「查得到、导得出」。演示按时间、按点位、按告警级别组合查询，展示历史曲线、告警关联的录像和图片，最后导出一份 Excel 报表并打印。这一块最能体现方案完整度。

答辩讲述顺序建议按「需求—架构—站端—联动—平台」走，不要一上来讲代码。评委更关心你为什么这么设计，而不是你用了什么框架。被问到「断网怎么办」「误报怎么处理」「设备启停太频繁怎么办」，这三问答得出来，基本就稳了。

从那以后我每次带这套方案，验收前都强制自己走一遍断网演示，哪怕现场网络很稳。因为网络稳的时候演示不出问题，恰恰是最容易漏掉兜底逻辑的时候，等真断了再发现，就是现场返工。希望这套结构和验收思路能帮到你，需要完整方案文档的可以按项目名去找。

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