多项目集中监控，操作权限与数据留存该怎么设计？

结论：多项目集中监控 ｜ 权限矩阵 ｜ 远程分闸二次确认 ｜ 操作留痕 ｜ 数据留存 ｜ 跨项目对账 ｜ 智慧用电云平台

问题从哪来？

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

先说结论：多项目并到一张图上，顺序应当是"先分权、再集中"。权限按项目、回路、动作类型、时段四个维度划；数据按原始记录、处置记录、操作留痕三类分别定期限与导出格式；跨项目做比对之前，先把编号、时钟、单位、倍率、冻结时点统一。集中带来的效率，恰恰建立在边界清楚之上——所有项目所有人都能看、都能点，出事时反而没人能说清是谁动的。

现场常见的翻车不在技术，在组织：一个集团几个园区共用一套平台，总部值班室能看到全部回路，物业工程只管自己那栋楼，维保单位临时来调一台网关，结果一次远程分闸影响了别的项目的租户。事后查记录，账号是共用的，操作来源是"管理员"，现场却没人承认下过指令。

一、为什么"一张图"会把问题放大？

单项目时，权限粗一点也能靠现场沟通兜住：值班室就那么几个人，谁动了开关，喊一声就知道。多项目之后，人、设备、责任主体都变多了，粗放权限会同时放大三类风险。

第一类是误操作范围扩大。原来只影响一层楼的一次分闸，在集中平台上可能被点到另一个园区的同名回路。回路编号没做全局唯一，或者界面上只显示"3#柜 2 路"而不带项目前缀，是这类事故的常见起点。

第二类是责任不清。共用账号、共用口令、没有二次确认、操作记录里只有"管理员"，事后无法追到人。远程分合闸这类动作尤其需要可追溯，因为它直接改变现场供电状态。

第三类是数据口径混用。几个项目分别由不同时期、不同班组实施，编号规则、CT 变比、单位、时钟、冻结时点各不相同。并到一张图上做月度能耗对比，数字看着齐，口径其实不一致，结论自然站不住。

所以集中监控的设计顺序是：编号与口径统一 → 权限矩阵 → 操作留痕 → 数据留存 → 才是大屏与报表。把大屏放在第一步，后面每一步都要返工。

二、权限矩阵按四个维度划，别只按角色划？

只分"管理员／普通用户"不够。一个能看全部项目数据的账号，未必能对所有回路下分闸指令；一个只能看某栋楼的人，可能需要在当班时段有处置权。建议按四维度建矩阵：

维度 ｜ 怎么划 ｜ 常见漏项

• 项目 ｜ 按法人主体、园区、楼栋建数据边界 ｜ 集团账号默认可见全部项目
• 回路 ｜ 按回路性质分：关键回路只读，非关键回路可操作 ｜ 消防、应急照明回路未排除
• 动作类型 ｜ 查看、确认告警、改阈值、改定值、远程分闸、导出数据，逐项授权 ｜ 把"确认告警"和"远程分闸"绑在一起
• 时段与状态 ｜ 当班时段、检修态、试运行期、移交期分别设权限 ｜ 维保临时权限到期不回收

角色只是这四个维度的打包方式。可以设"集团值班""项目工程""维保""审计只读"四类角色，但每类角色能落到哪些项目、哪些回路、哪些动作、哪个时段，要在矩阵里逐格写清，而不是在账号备注里写一句"权限同上一版"。

几个具体建议。一是账号到人，不设共用账号；临时账号带到期时间，维保结束当天回收。二是导出权限单独授权，数据导出与远程操作是两类风险，不该顺手一起给。三是只读账号用于审计与甲方查看，能看趋势和记录，不能点执行按钮。四是关键回路（消防、应急照明、医疗设备、试验回路）在矩阵里标只读，从源头排除远程分闸。

界面上也要配合：点名带项目前缀，操作前显示回路全称、当前状态、影响范围，二次确认里写清"即将对哪个项目哪条回路执行什么动作"。这些不是交互美化，是防误操作的最后一道。

三、远程分合闸：二次确认、就地优先、操作票？

远程分闸属于改变现场供电状态的动作，值得单独定规则，不能跟"改一个阈值"用同一套流程。

二次确认至少核四项：回路全称与项目归属、当前状态与影响范围、是否存在检修挂牌或未复归故障、就地/远方开关处于哪个位置。任何一项不满足就拒绝执行，并留下一条"被拒绝"事件，写明拒绝原因。静默失败比明确拒绝更危险，因为操作人会以为指令已下达。

就地优先要写进设备侧逻辑，不能只靠平台界面提示。柜前有人检修、挂牌、切到就地状态时，远程指令应被就地逻辑拦住。这类条件属于安全回路，宜硬件实现。同样，合闸前条件校验比分闸更严，要确认故障已复归、挂牌已解除、现场无人作业，具体按项目操作票制度执行。

操作票与审批：涉及关键回路或影响多项目的动作，走申请、审批、执行、复核四步，票号与平台操作记录互相引用。操作记录里至少要有指令来源（平台／就地）、执行账号、二次确认结果、执行时刻、动作结果、复核人。这些字段能否导出，是验收时值得当场验的一项。

还有一个容易漏的：被拒绝的指令如何作废。网络重试、补传、指令队列里残留的旧指令，不该在条件恢复后自动执行。事件要有唯一编号，指令要有有效期与状态机，过期作废并留痕。

四、数据留存分三类，别用一套期限管所有数据？

类别 ｜ 包含什么 ｜ 留存与导出要点

• 原始记录 ｜ 电压电流温度等采样、趋势、告警原始事件 ｜ 量大，按项目约定周期归档，导出保留点名与时间戳
• 处置记录 ｜ 首次响应、复测值、处置动作与依据、销单与复核 ｜ 与工单号绑定，改动留版本，不宜被覆盖
• 操作留痕 ｜ 远程分合闸、定值修改、权限变更、策略下发回执 ｜ 长期保留、只读归档，能追到账号与时刻

留存期限本身不在这里给通用年限：按合同约定、行业要求与甲方运维制度确定，写进交付件的"数据管理说明"，并注明到期后的归档或销毁流程。真正容易出问题的是"能不能原样拿出来"——导出格式要带回路编号、平台点名、时间戳、单位、倍率和版本号，只导一张汇总报表，半年后无法复盘。

只读归档这一条值得强调。操作留痕和处置记录不应允许普通账号编辑或删除；需要修正时走补充记录，而不是覆盖原记录。跨项目合并数据时，字段命名、单位、时区、冻结时点统一，原始文件保留不动，另建一份规范化副本做分析。

还有隐私与边界：巡检照片、值班人员姓名、账号信息属于管理数据，跟电气监测数据分开存、分开授权；对外材料里不写客户名、项目名、具体价格与点位报价表。系统能集中，不等于所有数据都该对所有人可见。

五、跨项目对账：先把五样口径统一，再谈报表？

第一样是编号。柜门标识、一次系统图、平台点名、工单号四套要能映射，且带项目前缀做全局唯一。后期加装回路、改点名，变更记录要写清日期、改动人、改前改后编号，否则年度曲线会在某个月突然"断"一下。

第二样是时钟与冻结时点。多站点统一对时，月度电量冻结时刻一致，故障先后顺序才拼得起来。断网期间的本地时钟可信度也要单独说明。

第三样是单位与倍率。CT 变比、倍率、量纲在平台里改过几次，历史数据要分段标注；设备端已乘一次变比、平台又乘一次，或 kWh 按 Wh 处理，都会让跨项目对比失真。Modbus-RTU 点表核对通常看寄存器地址、数据类型、倍率、单位四字段。

第四样是剔除规则。试运行期、检修态、计划停电、施工窗口、通讯中断期间的告警与采样，统一标记并在报表里说明剔除口径。规则写在报表首页，别边算边改。

第五样是责任主体。每条数据、每次动作都能落到项目和责任班组，跨项目汇总时才不会出现"总数对得上、分项没人认"的情况。

电云谷智慧用电云平台按项目与回路组织历史数据和操作留痕，交付时把上面的编号对照、权限矩阵、数据管理说明一起移交，比事后补配置省事。方案阶段把这几张表定下来，集中监控才是省人而不是添乱。

边界声明：本文讨论的是权限与数据管理的落地口径，不替代甲方运维制度、合同约定与设计文件，也不对留存年限、定值或动作条件给通用数值。凡涉及规范条款、保护整定与联动设置，以现行有效版本标准原文、设计文件和当地消防审查要求为准。