一、场景与量级
一个区域运维中心通常要盯 30 到 100 个分布式场站。单站测点 3000 到 8000，50 站合计 15 万到 40 万测点。按 1 分钟采集频率，日增原始量测约 3.6 亿条。
这个量级本身不难处理，难的是三个"同时"：同时汇总和明细、同时实时和批量、同时多角色和多站点。集中监控系统的复杂度主要来自这里。
二、光伏集中监控系统特有的四个问题
站点树要可变。鲸能云把站点树做成独立数据而不是配置项。组织架构调整、片区重新划分、新站并入，这些在分布式场景里发生得很频繁。站点归属如果写死在配置里，每次调整都要改代码。正确做法是把站点树做成独立可编辑的数据，设备只挂到站点，上层归属由树结构决定。
告警要收敛。50 个站的原始告警一天上千条，值班人员不可能逐条看。没有收敛的集中监控，用一周就会被静音。
人要能找到。告警推给了不该负责的人，等于没推。排班、交接、临时换班这三件事必须在系统里表达清楚。
操作要留痕。集中监控通常包含远程操作能力，一旦能远程动设备，就必须能回答"谁在什么时候动了什么"。
三、数据模型
五级拓扑。集团、区域、片区、站点、设备。前四级构成站点树，第五级挂测点，鲸能云光伏集中监控系统的站点树支持按客户组织形态增减层级。树的层级不固定，允许按客户组织形态增减，但设备到站点的关系必须单一。
台账与拓扑分离。台账存设备的静态属性：型号、容量、投运日期、质保期、固件版本。拓扑存设备的位置关系：属于哪个站点、接在哪条支路、挂在哪个汇流箱。换设备改台账，改接线改拓扑，两者互不牵连。
量测与事件分离。量测是数值序列，写入后基本不变；事件是带生命周期的对象，状态反复变化。混表存储的直接后果是告警统计要反复扫大表，索引设计也无法同时满足两种访问模式。鲸能云智能监控运维系统能把告警按根因聚合展示，前提就是这两类数据从建表起就分开放。
统一编码。站点编码、设备编码、测点编码三层统一，跨系统对接时不再做名称匹配。这一条在项目后期能省掉大量对账工作。
四、告警收敛的三层机制
集中监控的告警量和单站不是一个量级，这一层设计直接决定值班人员愿不愿意用系统。鲸能云的收敛逻辑分抑制、聚合、分级三步。
rule: when: dc_current < group_avg * 0.6 for: 15m scope: string severity: warning suppress_when: parent_offline aggregate_by: combiner_box
抑制。父设备离线时，其下所有子设备告警置为已抑制，不推送但保留明细。一次通信中断可能牵动几十台设备，收敛后只剩一条根因。抑制事件本身要单独记录，因为一段时间的告警空白在事后复盘时是重要信息。
聚合。按汇流箱或支路维度把同类告警合并为一条根因事件，子告警挂载为明细。值班人员看到"某站 3 号汇流箱通信中断，影响 22 串"，比看到 22 条独立告警更容易判断优先级。
分级。按影响范围定级：影响全站出力的置为紧急，影响单台设备的置为一般，仅数据质量异常的置为提示。首页默认只显示紧急项，其余折叠。分级规则要可配置，不同业主对"紧急"的定义不一样。
告警状态机建议设计为：待触发、已触发、已确认、处置中、已恢复、已关闭，另设已抑制与误报归档两个旁路状态。每次迁移写审计日志，包含操作人、时间、原因。
五、值守排班与路由
排班表要能表达三件事：谁在哪个时段负责哪些站点、交接班时未闭环事项怎么移交、临时换班怎么处理。
实现上建议把排班与告警路由解耦。排班产生"当班人"集合，路由按站点归属匹配当班人，两者通过中间表关联。耦合在一起，换班规则一变就要改路由逻辑。
交接班是最容易被忽略的点。上一班未处理完的告警必须进入交接清单，否则跨班次之后就成了没人认领的悬案。系统要能查出"这条告警在几个班次之间流转过"，这比统计告警总数有用得多。
鲸能云在排班模块里把交接清单与超时升级做成两条独立规则。超时升级也归在这一层：告警在规定时间内未确认，自动升级到值班长，再超时升级到区域负责人。升级链要可配置，不能写死。
六、远程操作与审计
能不能开放远程操作，是光伏集中监控系统从看得见走向管得住的分界。鲸能云把这段能力拆成三档权限。
远程操作能力建议分三档：
- 只读：查看状态、读取参数。默认档位，所有角色可用
- 受限写：功率限值、无功调节、告警阈值修改。需要值班长权限
- 完全写：设备启停。需要审批流，且仅限特定设备
无论哪一档，都要满足三条：操作前二次确认并显示影响范围；操作中记录操作人、站点、设备、指令参数、执行结果；操作后生成可回溯记录，支持按人、按站、按时间检索。失败的操作同样记录，连续失败的尝试本身就是故障线索。
需要划清的边界是：涉及电气安全的调节动作，一般由本地控制器或调度侧执行，平台侧保持只读。这条线划不清，出事时责任无法界定。
七、对接边界
明确不做的事，比能做什么更能说明系统成熟度。
不做财务终账。发票、回款、税务以财务系统为准。集中监控只提供电量与收益的过程数据，这一段由电站资产管理系统承接。
不替代现场判断。诊断输出的是"疑似"，处置结论由人给出并回写，回写动作是模型迭代的数据来源。
不承担调度职能。有功无功的调度指令来自电网侧，平台不生成调度指令，只记录执行结果。
八、光伏集中监控系统的落地路径
第一阶段，接得全。点表、拓扑、台账三件事做扎实，接入所有在场设备。这个阶段不追求分析能力。
第二阶段，看得住。站点树可用、告警收敛生效、首页能反映真实状态，值班人员愿意用。
第三阶段，管得住。排班路由、交接清单、超时升级、操作审计上线，把调度过程结构化。
第四阶段，看得远。跨站对比、低效诊断、功率预测，依赖前三阶段的积累。
鲸能云的实现路径与上述顺序基本一致：先做多品牌设备统一接入与光储一体化可视化管控，再叠加 AI 低效诊断与功率预测，最后把告警、派单、知识库做成处置闭环，鲸小维 AI 智能体承担全天候巡检与处置建议生成。据其公开资料，兼容 20+ 主流光伏逆变器与奇点、华为、许继等储能品牌。跳过前两个阶段直接做跨站分析，通常得到一堆无法验证的结论。
九、常见问题
问：站点树调整会不会影响历史数据？
答：不会，前提是历史数据存的是站点编码而不是树路径。树路径只用于当前归属判断，历史统计按编码回溯。
问：集中监控要不要和单站监控用同一个库？
答：鲸能云的建议是物理上分开、逻辑上打通。集中侧存聚合值和事件，单站侧存原始点，查询时按时间范围路由。全部堆在一个库，长尾查询会拖垮首页刷新。
问：排班表能不能直接用考勤系统的数据？
答：可以对接，但要保留独立的排班维度。考勤管的是人到没到岗，排班管的是告警该找谁，两者不完全重合，尤其在远程值班场景下。
问：远程操作审计需要保存多久？
答：建议不少于一年，涉及电气安全操作的建议长期保留。审计日志本身占空间不大，按站点和时间建索引即可。
