边缘侧自动断电与云端平台的职责怎么划？断网时谁说了算？

结论：边缘计算 ｜ 自动断电 ｜ 违规负载识别 ｜ 断网演练 ｜ 策略版本 ｜ 就地优先 ｜ 智慧用电云平台

问题从哪来？

========================================

先说结论：保护与本地安全策略必须在断网时仍然可执行，云端不进必经路径。断网不是"系统降级到手动操作"，而是设备按本地已生效的最后一版策略继续运行：保护本体照常动作，边缘逻辑照常识别与判断，停掉的只是集中监视、远程指令、报表与工单推送。谁说了算要写在设备侧，不能等网络恢复再由平台补判。

这个结论听起来像常识，落到方案里却经常被绕开。常见写法是"平台识别违规负载后下发断电指令"——一句话把识别和执行都放到了云端。链路一断，识别停了，指令也发不出去，而现场负荷还在。真正该问的是：识别在哪一层做、执行由谁触发、策略版本怎么同步、冲突时按谁的优先。

一、先把三层功能拆开，别用一个"系统"全包？

层级 ｜ 承担什么 ｜ 断网时的状态

• 保护本体 ｜ 过载、短路、剩余电流保护与动作记录 ｜ 照常工作，不依赖任何通讯
• 边缘逻辑 ｜ 本地采集、违规负载识别、阈值判断、自动断电、就地联锁 ｜ 按本地已生效策略继续运行
• 云端平台 ｜ 策略下发与版本管理、集中监视、告警通知、报表、工单、跨项目对账 ｜ 暂停，恢复后补传与对账

三层的关系是逐层收窄：保护本体管"电能不能继续送"，这是电气安全底线；边缘逻辑管"按管理策略要不要断"，比如识别到违规大功率负载、离人之后的定时断电、温度持续上行后的本地处置；云端管"多个项目怎么看、怎么记、怎么派单"。前两层在设备里，第三层在机房或云上。

把识别放在边缘，好处不只是断网可用，还有时延和确定性：采样、判断、执行在一个设备内闭环，不经过公网往返，动作时刻和依据都能本地留痕。云端收到的是结果事件，不是"请帮我判断一下"。反过来，如果判断依赖云端，平台一次心跳超时、一次账号鉴权失败，都可能让本该执行的动作落空。

这里有个容易被混淆的点：边缘逻辑的自动断电，不等于保护动作。过载、短路、剩余电流保护由断路器本体按整定与产品标准执行；违规负载识别属于用电管理策略，两者触发条件、动作对象、复位方式都不同。方案里要分开列，调试时分开验，别把"智能断路器能自动断电"当成一句笼统的卖点。

二、断网之后，哪些还在、哪些真的停了？

还在的部分：本体保护与动作记录、本地采集与趋势缓存、边缘识别与本地策略执行、就地手动操作、本地联锁与检修挂牌、事件时间戳。这些功能的共同点是不依赖外部通讯，设备掉电重启后也应能按已保存的策略恢复。选型时值得问一句：策略是存在设备里还是只在平台里，设备重启后策略还在不在。

停掉的部分：远程分合闸指令、平台告警推送与手机通知、跨站点集中画面、报表生成、工单派发、策略在线修改与下发。这些恢复依赖网络，恢复之后要做两件事——补传断网期间缓存的事件与采样，以及对账，确认没有把重复事件算成两次动作。

半停的部分容易被漏掉：时钟。多站点断网期间如果对时中断，事件时间戳可能漂移，恢复后故障先后顺序拼不起来。所以本地时钟、对时策略、断网期间的时间可信度，要在方案里单独写一条。月度电量冻结同理，冻结时刻不一致，对账就永远差一截。

还有一类"看起来没断、其实已经不闭环"的情况：网络通但平台侧服务不可用，或者网关在线而设备离线。所以状态定义要分层——设备在线、网关在线、平台可达，三个状态分开监视，别用一个"在线率"糊过去。

断网现象 ｜ 该由哪层兜住 ｜ 恢复后核什么

• 违规负载仍在用电 ｜ 边缘识别 + 本地断电 ｜ 断电事件是否补传、有无重复记录
• 本地动作了平台没看到 ｜ 本地事件缓存 ｜ 时间戳与事件顺序
• 远程指令发不出去 ｜ 就地操作 + 挂牌 ｜ 未执行指令如何作废
• 多站点时间不齐 ｜ 本地时钟与对时策略 ｜ 事件顺序与冻结时点
• 报表少了一段数据 ｜ 本地趋势缓存 ｜ 补传完整性与口径

三、策略冲突怎么仲裁：就地优先、版本、二次确认？

冲突有四类，方案里逐条给规则，比运行时临时判断稳。

第一类，就地与远程冲突。原则通常是就地优先：柜前有人检修、挂牌、切换到就地状态时，远程指令应被拒绝并记一条"被拒绝"的事件，而不是静默丢弃。远程合闸尤其要做合闸前条件校验——有没有挂牌、有没有未复归的故障、就地/远方开关在哪个位置、检修态是否解除。这些条件属于安全回路，宜硬件实现，不能只靠平台界面上的一个弹窗。

第二类，边缘策略与保护动作冲突。保护动作优先级高于管理策略。比如剩余电流保护动作之后，管理侧的自动重合策略不应自行送电；哪些回路允许自动重合、重合次数与失败闭锁，要在调试阶段按场所性质定死，潮湿、人员密集场所通常不设自动重合。重合闸时间这类可调参数按产品规格书与整定单，不给通用数值。

第三类，策略版本冲突。平台下发新策略、设备本地还跑旧版，或者断网期间平台改了策略但没下发成功，都会造成"画面上是一套、现场是另一套"。做法是给每版策略编号、生效时刻、下发状态与设备回执，平台展示"当前各设备实际生效版本"，而不是"最近下发版本"。回执没回来就标未生效，别默认成功。

第四类，重复与幂等。网络恢复后补传、指令重试、告警合并，都可能让同一事件被处理两次。事件要有唯一编号，断电类动作要有明确的复位条件与人工确认环节，不能因为补传了一条旧事件就再动作一次。

四、违规负载识别与自动断电，边界落在哪？

识别这一侧：本地采集电压、电流、功率、功率因数与负荷曲线，按预设特征判断某类负载是否接入。判断在设备或边缘网关内完成，判据与阈值可配置，配置来源与版本可追溯。它不需要云端参与，也不该把原始高频采样全量上传去"让平台算"。

执行这一侧：先分回路性质。哪些回路允许管理策略自动断电（如非关键插座回路、公共照明、离人后的办公区支路），哪些回路必须人工确认或干脆不参与（如消防设施、应急照明、医疗设备、正在进行试验的回路），要在设计阶段列成清单并写进联动矩阵。这张清单比算法本身重要，划错了，自动断电就会变成新的风险源。

然后是动作方式。自动断电应当可撤销、可复位、可追溯：动作时刻、触发特征、策略版本、复位人、复位时刻都要留痕。复位不建议做成"平台点一下就送上"，应有现场确认环节，尤其涉及人员安全的回路。管理策略切断之后，本体保护仍独立存在，两者不互相替代。

再说断网演练。真正能验证这套边界的动作，是人为断开上行链路，看本地识别、判断、执行、留痕是否照常，恢复后补传与对账是否完整。演练要记录断网起止时刻、期间的动作事件、恢复后的补传条数与差异项，由运维与供货双方签字。

五、从方案到验收，把职责写成可核的条目？

方案阶段列三张表：功能分层表（哪件事在哪层做）、断网行为表（每类功能在断网时的状态与恢复动作）、回路清单（哪些回路允许管理策略自动断电，哪些排除）。三张表对应前面五节的内容，写成表格比写成散文更容易在图纸会审上过。

调试阶段逐项验：就地优先是否真的拦住远程指令、挂牌状态是否进平台、策略版本的下发与回执是否一致、断网演练的动作与补传是否完整、事件编号是否唯一。每项留试验条件与结果，别只写"合格"。

交付阶段把策略版本、回路清单、断网演练记录一并归档，跟点位与回路对照表、整定记录表放一起。运行阶段改策略留版本号、改动人、生效时刻；换值班员时，把"断网时该找谁、就地怎么操作"写进交接清单。

边界声明：本文讨论的是职责划分与验证方法，不替代设计文件，不对具体产品能力、定值或动作时间给通用数值。凡涉及保护整定、规范条款与联动设置，以现行有效版本标准原文、设计文件、厂家规格书和当地消防审查要求为准。电云谷智慧用电云平台负责集中监视、策略版本管理与操作留痕，本地识别与断电逻辑由设备侧承担，这个分工应写进项目的接口清单。