057 虚拟电厂聚合商工程链:准入 × 调度对接 × 结算口径 × 27 号令 4 区

057 虚拟电厂聚合商的市场主体侧工程链:准入 × 调度对接 × 结算口径 × 27 号令 4 区落位

作者 :杭州领祺科技工程团队 · 2026-10-23

本文定位 :配网储能 P1 深化稿。357 号把独立储能、虚拟电厂、负荷聚合商一并纳入「电力领域新型经营主体」,220 号把这件事在省级层面做成可落地的准入与实体化细则。但从「政策承认我是主体」到「调度真的把指令发到我的资源上、结算真的按我的计量点出账」,中间隔着一条市场主体侧 的工程链。本文只讲这条链的四段:准入 → 调度对接 → 结算口径 → 27 号令 4 区落位 ,并把它串成一条可验收的路径。

产品范围 :领祺 7 产品一体栈 PEMS300 / PBox6218E / PBox848F / PBox6220-PQCT / PBox8620 / PBox6219A / PFCS-3000B;3 配套独立硬件(电力专用网闸、纵向加密认证装置、时钟同步源)协同部署。

可信度标注 :(A 官方)可溯源官方文号或公开标准;(B 推导)基于公开政策口径与产品公开能力推导;(C 参考)行业通行做法与待核项;(D 警示)业内高频误用。

政策口径 :357 号、220 号、114 号、27 号令、1656 号仅作边界条件引用,只写「文号 + 文件名 + 主题边界」,不写条款序号、不写具体量化指标与考核数值;一切具体条文、门槛与考核口径,以国家发改委、国家能源局、省级电网公司与电力交易机构后续印发的实施细则,以及业主实际签署的并网调度协议、结算协议为准。


〇 概览:身份拿到了,工程链才刚开始

357 号解决的问题是身份 :《关于支持电力领域新型经营主体创新发展的指导意见》把独立储能、虚拟电厂、负荷聚合商明确为「电力领域新型经营主体」,等于给聚合商发了一张「可以参与电力系统运行与市场交易」的入场券。220 号《山东省促进虚拟电厂高质量发展方案》作为 357 号的下位省级文件,把这张券在省内做成可核验的准入动作:谁可以当聚合商、聚合商要具备什么实体化条件、怎么接到省级平台、怎么参与调用与结算(A 官方,具体细则以省级印发文件与实施细则原文为准)。

政策层面的这条线是清晰的。工程层面不清晰的地方在另一头:调度侧 和结算侧看到的东西,跟聚合商自己以为的,往往不是同一套。

  • 调度侧看到的是一串可调资源对象:调度命名、遥测点号、遥信点号、调节范围、爬坡能力、指令通道地址。它不认「我是一家虚拟电厂」,它只认「我这条指令发给谁、谁给我回执、回执里的实际值跟我下发的目标值差多少」。
  • 结算侧看到的是一串计量点:关口表编号、计量点属性、冻结时刻、抄表曲线、结算单元归属。它也不认「我聚合了一批用户」,它只认「这几个计量点在某个时段内的电量差,归到哪个结算单元」。
  • 聚合商自己看到的往往是第三套东西:一张资源清单 (哪些业主签了委托、哪些设备接进了平台、哪些能调、哪些只是台账上有)。这三套东西不打通,就会出现一种很典型的状态------平台上线了、大屏亮着、政策文件也贴在墙上,但调度第一次真正下令时,回执对不上;第一次出结算单时,口径对不上。

本文把这条链拆成四段(B 推导):

  1. 准入------把「政策身份」换成「系统里的可调资源对象」。路径是:注册备案 → 平台接入 → 并网与涉网测试 → 计量装置就位 → 主体身份确认。五步走完,聚合商在调度侧才真正「存在」。
  2. 调度对接 ------把「可调资源对象」接进「指令---执行---反馈---偏差」的闭环。核心不是接口能不能通,而是指令有没有唯一标识、执行有没有带时标的回执、偏差有没有可复算的原始数据。
  3. 结算口径------把「闭环产生的数据」换成「能对账的结算单元」。核心是结算单元的边界、计量点的绑定、冻结时刻的统一、争议时的举证顺序。
  4. 27 号令 4 区落位------把上面三段涉及的每一个系统、每一段数据流,放回安全分区里。VPP 平台在哪一区、聚合商侧设备在哪一区、跨区走什么通道、边界靠什么守,这四问不答清楚,前面三段做得再顺也过不了合规。

这四段的关系不是并列,是串联:准入决定你能不能进场,调度决定你进场后有没有数据,结算决定这些数据能不能变成账,落位决定这条链是不是合规地跑着。任何一段断掉,后面全废(D 警示)。

〇.1 与已发期号的显式边界

这一节把边界写死,避免同一批读者在几篇稿子里反复读到同一段话(B 推导)。本文与四篇前作的分工如下,逐篇说明它写了什么、本文不写什么:

  • 与 031(配网/台区储能的设备通信与安全架构) :031 的重心是设备侧 ------云-管-边-端 4 层模型、27 号令 4 区的站内落位、7 款产品在配网/台区场景的 A/B/C 级分工清单。它回答的是「这套东西怎么建、每台设备干什么」。本文不写 设备选型逻辑、不重述云-管-边-端 4 层、不重列产品能力清单与分级理由。本文的 §七 虽然也出现 7 产品,但矩阵的行是市场主体侧的四个环节 (准入 / 调度 / 结算 / 落位),列是 27 号令 4 区,单元格回答的是「这个环节在这一区由谁承接、数据从哪来往哪去 」,不回答「这台设备性能如何、为什么选它」。一句话:031 是建 ,本文是用。
  • 与 037(配电侧/台区侧二次系统通信架构选型决策树) :037 的重心是决策树 ------给定台区条件、通道条件、合规条件,怎么在若干通信方案里选一条。本文不写 任何决策树、不给选型条件分支、不比较通道方案的优劣。本文涉及的通道只讲接口形态与时序(指令报文长什么样、回执带什么字段、偏差怎么算),不讲「该选哪种通道」。
  • 与 039(集中式独立储能的三收益模型) :039 的重心是收益结构 ------容量、电量、辅助服务三条收益栏怎么构成,产品在收益栏里怎么分工。本文不写 任何收益模型、不写收益率、不写分成比例、不写任何金额与单价。本文的 §六 只讲结算口径:结算单元怎么划、计量点怎么绑、冻结时刻怎么统一、对账差异怎么举证。口径是「怎么算得清」,不是「怎么把收益算出来」,这两件事在工程上完全分离(D 警示:把口径问题当成收益问题讨论,是最常见的跑偏方式)。
  • 与 036(绿电直连项目的二次系统) :036 的重心是单一绿电直连项目 的二次系统与 4 区合规。本文不写 绿电直连、不写源荷直连的接入方式、不写单一项目内部的二次系统设计。本文讨论的聚合对象是配网侧分散资源 (用户侧储能、可调负荷、台区储能),聚合关系是商务代理关系 + 调度代理关系,不是物理直连关系。

小结 :031 讲建、037 讲选、039 讲收益结构、036 讲单一项目直连;本文讲市场主体侧的流程链 ------一个聚合商从「有身份」到「能被调度、能被结算、能过合规」要走完的四段。四篇前作是本文的前置知识,不是本文的重复内容。

〇.2 四个关键词在工程上的落点

本文四个关键词各自对应一类可验收的产出物,这也是后文所有章节的组织依据(B 推导):

关键词 工程落点 可验收产出物 主要承接方
准入 从政策身份到系统对象 准入材料包 + 平台接入记录 + 涉网测试报告 + 计量点清单 + 主体身份确认单 聚合商 + 省级平台 + 供电公司 + 交易机构
调度对接 从系统对象到闭环数据 指令日志 + 执行回执 + 偏差复算表 + 通信中断处置记录 聚合商 + 调度机构 + 场站/资源侧控制器
结算口径 从闭环数据到可对账口径 结算单元台账 + 计量点绑定表 + 冻结曲线 + 对账差异单 聚合商 + 计量专业 + 结算专业
4 区落位 从流程到合规边界 分区落位表 + 跨区通道清单 + 边界设备配置基线 聚合商 + 网络安全专业 + 调度自动化专业

这张表的价值在于:四段流程每一段都必须留下可核验的产出物。只有流程没有产出物的,验收时一律按未完成处理(C 参考,各家验收细则不同,以合同与实施细则为准)。

〇.3 与 357 号 / 220 号的口径关系(只写边界,不写条文)

为避免政策引用被过度解读,本文对三份文件的用法做如下限定(A 官方 + B 推导):

  • 357 号 只用于界定主体身份:独立储能、虚拟电厂、负荷聚合商属于电力领域新型经营主体。本文不引它的条款序号,不引申它的支持措施细节,不把它的表述改写成技术指标。
  • 220 号 只用于界定省级准入与实体化的方向:省级层面要求聚合商具备实体化条件、接入省级管理平台、接受调用与考核。本文不写它的具体门槛数值、不写它的申报时间窗、不写它的考核档位------这些一律以省级实施细则原文为准。
  • 114 号 只用于界定容量侧机制的存在性:发电侧容量电价机制是独立存在的政策口径。本文不写它的补偿水平、不写它与 VPP 的具体挂钩方式;039 已讲过收益结构,本文不重复。
  • 27 号令 只用于界定安全分区与跨区边界:安全区 I 区 / II 区 / III 区 / IV 区的划分,生产控制大区与管理信息大区的边界,横向隔离与纵向加密的强制要求。本文只写「某个系统应该落在哪个区、跨区该走什么通道」,不写测评方法细则(测评方法见后续合规专题)。
  • 1656 号 只用于界定新能源集成融合的方向性要求,在本文中仅出现在「聚合资源里含新能源与储能混合」的场景描述里,不作为本文主线(主线是 357 号与 220 号)。

一 现象:聚合商侧的四类断点

过去两年我们在配网储能与用户侧聚合项目上反复见到的失败形态,收敛成四类。每一类都不是「设备坏了」,而是链路上少了一环(B 推导)。

1.1 身份断点:登记了主体,没登记代理关系

典型现场:聚合商在省级平台完成了主体注册,营业执照、法人信息、技术系统说明都交了,账号也开出来了。但调度侧的可调资源台账里,查不到这批资源挂在谁名下。

原因往往很朴素:注册时提交的是企业身份 ,而调度需要的是代理关系 ------哪一份委托协议、覆盖哪些用户、每个用户的哪个计量点、代理的时段与品种、谁有权代表这些资源接受调度指令。这三样东西在商务侧是合同,在系统侧必须变成结构化字段。合同签了、系统没录,等于没签(D 警示)。

后果:平台侧显示「已接入 N 个资源」,调度侧显示「该主体无关联可调资源」。第一次真正需要调用时,调度找不到对象,只能临时改走需求响应的老路径,聚合商的角色被降级为「报数的」。

1.2 接口断点:指令下得去,回执上不来

典型现场:调度侧的指令通道通了,遥测也上来了,看起来一切正常。但调度的运行日志里,这批指令的状态长期停在「已下发」,没有「已确认」「执行中」「已完成」。

深一层看,是两个细节没做:

  • 指令没有唯一标识的回执。调度下发一条调节指令,聚合商侧收到了、执行了,但回执里没有带回指令标识与时标,调度侧无法把「这条回执」和「那条指令」配对上,只能人工判断。
  • 执行侧的「实际值」不是同一时刻的。回执里带的实际功率,取的是本地控制器的采样值,采样时刻与调度要求的上送时刻错开;错开之后,调度算出来的偏差里混进了时延,考核时说不清是谁的问题。

后果:偏差考核的口径争议变成常态。聚合商认为「我执行到位了」,调度认为「你的反馈对不上目标」。争议的根不是执行力,是报文里少字段(D 警示)。

1.3 计量断点:结算单元和计量点没绑死

典型现场:结算单下来,聚合商拿自己的平台数据去核,怎么算都对不上。追下去通常是三件事之一:

  • 结算单元的边界与计量点清单不一致。结算单元是按「一个聚合商 + 一个品种 + 一组计量点」划的,但实际绑定时漏了几个点,或者把不该进的点放进来了。
  • 冻结时刻不统一。结算取的是计量装置的冻结数据(整点或整刻冻结),聚合商平台取的是自己采集的瞬时值再积分;两条曲线在负荷波动大的时段差得很明显。
  • 子表与关口表的关系没写清楚。聚合商内部用子表做分摊,对外结算只认关口表;一旦有人拿子表去对关口表,必然对不上,然后开始怀疑计量装置有问题。

后果:每次结算都要人工拉平,且「拉平」的过程没有留痕,下个月重复一遍。争议一旦升级,举证责任在聚合商侧,而聚合商手上只有平台截图,没有可复算的原始冻结数据(D 警示)。

1.4 落位断点:业务上想直连,安全上必须跨区

典型现场:VPP 平台部署在管理信息大区(或直接放在园区信息网),调度指令从生产控制大区过来,中间没有合规通道。工程上常见的三种「绕过」做法:

  • 让平台运维用一台双网卡机器同时连两边,人工拷贝文件;
  • 在信息侧放一台能直连调度前置的转发程序,走一条未登记的链路;
  • 把调度指令改成「人工转发」------调度打给值班员,值班员在平台上手工录一条指令。

这三种做法都能让业务「看起来跑起来了」,但都直接落在 27 号令的禁止面上:生产控制大区与管理信息大区之间必须横向隔离,跨区数据交换必须经电力专用网闸;纵向通信必须经纵向加密认证装置;安全区 I 区 / II 区不允许与非生产控制类系统直接互联(A 官方,27 号令)。

后果:平时不出事,一测评就是硬伤;更严重的是「人工转发」那条路径把指令时延拉长到不可控,偏差考核必然吃亏,而这笔账最后会被记到「聚合商响应能力不足」上(D 警示)。


二 根因:四个工程断层

四类断点背后不是四个技术难题,而是四个工程习惯上的断层(B 推导)。

2.1 断层一:身份层与设备层脱耦

政策身份是法人级的,调度对象是设备级的。中间缺一层「代理关系模型」:主体 → 代理协议 → 资源集合 → 计量点集合 → 调度对象。多数项目把这一层放在合同附件里(纸质),没有放进系统(结构化)。于是每次人员变动、每次资源增减,都要重新人工对一遍,且没有人能回答「当前这个调度对象到底覆盖哪几个计量点」。

纠正方向 :把代理关系做成一张可查询的表,且这张表是准入材料的核心件,不是附属件。谁签的、覆盖谁、覆盖哪个点、有效期到哪天、谁有权接受指令,五个字段缺一不可。

2.2 断层二:时序层缺闭环设计

调度对接的本质是时序问题,不是协议问题。一条完整的链要有时标:下发时刻、收到时刻、执行时刻、实际值采样时刻、上送时刻。五个时刻里缺任何一个,偏差就无法归因。

多数项目的接口设计只做到「能通」:报文结构对、点号对、量纲对,就算联调通过。但没有指令标识 (无法配对)、没有回执确认 (无法判断是否执行)、没有时标一致性要求(无法区分是响应慢还是采样错位)。这三样东西不写进接口规范,后面所有的偏差争议都是口说无凭。

纠正方向:把「五时刻 + 指令标识 + 回执状态机」写进接口规范,作为联调验收项,而不是运行期再补。

2.3 断层三:量测层基线不统一

结算争议的绝大多数根因,是三方各用各的基线:调度用遥测(秒级、可能有死区压缩)、聚合商用平台采集(分钟级、可能有补采)、结算用计量冻结(刻级、法定计量器具)。三条曲线本来就不该完全一致,但项目上常被当成「应该一致」,一旦不一致就互相怀疑。

正确做法是承认三条曲线各有用途 :遥测用于实时监视与偏差预警,平台采集用于内部考核与资源排序,计量冻结用于对外结算。对外只认计量冻结,且必须能在争议时把三条曲线摆在一起,说明差异来源。

纠正方向:在准入阶段就把「结算用哪条曲线、监视用哪条曲线、内部考核用哪条曲线」写进协议,并在系统里做三条曲线的对照视图。

2.4 断层四:边界层让业务便利优先于分区合规

VPP 平台天然想「一个平台看全部」:看调度指令、看资源状态、看计量数据、看市场结果。这种「一个平台全看」的诉求,与 27 号令的分区要求天然冲突------因为调度指令在生产控制大区,市场与结算数据在管理信息大区,两者之间必须隔离。

冲突不可怕,可怕的是用「临时通道」去化解冲突。临时通道一旦上线,就会变成长期通道,因为没人愿意在业务跑起来之后再去拆。

纠正方向 :在设计阶段就把「哪些数据必须留在生产控制大区、哪些可以出到管理信息大区、出区走哪个网闸的哪个服务端口」定成一张表,作为架构基线。后文 §七 的落位矩阵就是这张表的骨架。


三 领祺方案:准入 / 调度 / 结算 / 落位 四步法

前面两节把问题拆开了,这一节给出可执行的四步。四步之间用阶段门(Gate)串起来:每一步的产出物齐备并通过检查,才允许进入下一步。这么做不是为了流程好看,而是因为后一步的问题会掩盖前一步的问题------准入没做完就去调调度,联调时根本分不清是准入的锅还是调度的锅(B 推导)。

3.1 四步法总览

步骤 目标 关键产出物 阶段门(进入下一步的条件)
第一步 准入 从政策身份到系统里的可调资源对象 代理关系表、平台接入记录、涉网测试报告、计量点清单、主体身份确认单 五件产出物齐备且口径一致,调度侧台账能查到该主体及其资源
第二步 调度对接 指令、执行、反馈、偏差形成可复算闭环 接口规范、联调记录、指令日志与回执、偏差复算表 联调场景全通过,含通信中断场景;每条指令都能查到五时刻
第三步 结算口径 闭环数据能落到可对账的结算单元 结算单元台账、计量点绑定表、冻结曲线、对账差异单与处置记录 用一个历史周期做端到端对账,差异可解释且有留痕
第四步 4 区落位 全链路回到 27 号令的分区边界 分区落位表、跨区通道清单、边界设备配置基线 每条跨区数据流都有合规通道与登记记录

四步法与 357 号 / 220 号的关系是对齐而不是替代 (A 官方 + B 推导):357 号给身份,220 号给省级准入方向,本文的四步是把这两份政策语言翻译成工程动作与产出物。每一步的具体门槛值、时限、考核档位,均以国家发改委、国家能源局、省级电网公司与交易机构后续印发的实施细则为准,本文不代拟。

3.2 第一步:准入------五个卡口,一次做对

准入不是一次申报,而是五道卡口(B 推导)。这五道卡口的顺序是固定的,因为后面的卡口依赖前面的产出物:

  1. 主体资格与代理关系------法人资格、聚合业务范围、与资源业主的委托协议、代理的品种与时段;
  2. 平台接入------聚合商的资源与计量数据接入省级管理平台,通道形态与点表规格;
  3. 并网与涉网测试------资源侧的调节能力、通信可靠性、保护配合、涉网行为验证;
  4. 计量装置就位------关口表与子表安装、封印与检定状态、计量点与资源的绑定关系;
  5. 主体身份确认------在调度、交易、计量、结算各专业口径下,同一主体同一资源的名称、编号、边界完全一致。

卡口顺序颠倒的典型代价:先接平台后补代理关系,等于把未经授权的资源挂进调度台账,出了问题连责任主体都指不出来(D 警示)。代理关系必须在接入之前。

3.3 第二步:调度对接------把「能通」升级为「闭环」

调度对接的验收标准不是「链路 ping 通」,而是四段时序都能被复算(B 推导):

  • T-1 段(能力与基线):聚合商上送可调能力、资源状态、基线口径说明;调度侧核定并回执;
  • T0 段(指令下达):调度下发含唯一指令标识、目标值、时限、量纲的指令;聚合商侧回「已接收 / 已确认」;
  • T1 段(执行):聚合商把指令分解到资源侧控制器执行,回「执行中 / 已完成」,并带上实际值与其采样时标;
  • T2 段(反馈与偏差):偏差由双方各自用同一份原始数据复算,复算口径一致才有争议基础。

这四段里最容易被省掉的是 T-1 段的能力上送。没有能力上送,调度只能按最保守的方式调用,聚合商的可调空间永远用不满(D 警示)。

3.4 第三步:结算口径------先定口径,再谈对账

结算这一段,顺序同样重要:先定结算单元与计量点绑定,再谈对账。原因是对账争议九成出在绑定关系上,而不是出在加减法上(B 推导)。本文 §六 展开。

3.5 第四步:4 区落位------把流程放进分区边界

前三步产生的系统与数据流,落到 27 号令的分区里:VPP 平台的业务功能 与数据出区需求分别在哪一区、聚合商侧设备在哪一区、跨区数据流走哪条通道、边界设备承担什么职责。这一步在 §七 用矩阵回答(B 推导)。


四 聚合商准入专题:五道卡口与材料闭环

本节把 §3.2 的五道卡口逐条展开。每张卡口给三件事:要达成什么 / 谁交付什么 / 什么情况会被退回。退回原因是实战中最有价值的部分(C 参考)------它把「做得好」翻译成「不做什么就不会被退」。

五道卡口的上位依据是 357 号对电力领域新型经营主体的身份界定,下位落地依据是 220 号在省级层面对聚合商提出的方向性要求,两者之间由省级实施细则衔接(A 官方)。本文只写工程动作与产出物,不代拟任何申报表格与门槛数值。

4.1 卡口一:主体资格与代理关系

要达成:在系统里建立一条从「法人主体」到「具体计量点」的可查询链路。

聚合商需要交付的材料包括:法人资格证明与经营范围说明、聚合业务范围说明、与每个资源业主的委托协议要点、代理覆盖的资源清单与对应计量点清单、代理生效与终止时点、代理关系变更的报送机制。

必须结构化入库的五个字段(B 推导,字段名以各省平台实际表单为准):

字段 含义 缺它会怎样
主体标识 聚合商在调度与交易口径下的唯一编号 调度侧无法把指令挂到主体上
资源标识 被代理资源的唯一编号(按调度命名规则) 指令下发到「一个集合」而不是「一个对象」
计量点标识 资源对应的关口/子表计量点编号 结算时无法把电量归集到结算单元
代理范围 代理的市场品种、可调时段、能力范围 调度调用越界,或资源闲置
有效期与变更 代理起止与变更报送机制 合同到期后资源仍留在台账上

常见退回原因:

  • 委托协议只到「用户」层级,没落到计量点------调度和结算都要按点走,止步于用户层的协议无法绑定;
  • 同一台设备的计量点与调度命名对不上(一个用设备资产号,一个用台区编号),交叉表没人维护;
  • 代理关系没有变更报送机制------首批数据是准确的,三个月后就开始漂移;
  • 聚合范围跨了不同电压等级或不同台区,但协议与台账没分开表达。

4.2 卡口二:平台接入

要达成:聚合商的资源、遥测、计量、状态四类数据,按平台规定形态与点表规格接入;同时具备接收调度指令与回传执行结果的能力。

接入要区分三条独立通道(B 推导):

  1. 数据上行通道------资源状态、遥测、可调能力、计量数据的采集与上送;
  2. 指令下行通道------调度指令的接收、解析、分发与回执;
  3. 计量采集通道 ------面向结算的计量数据采集,路径与前两条可能不同,权限与保留策略也可能不同。

三条通道混成一条是常见错误:一旦计量数据与实时遥测共用一条上行链路,既容易在策略上被当成「同一类数据」处理,也容易在实现上把高频实时数据与低频结算数据用同一套缓存与补采策略,导致结算数据的完整性受影响(C 参考)。

常见退回原因:

  • 点表只交了静态属性 (额定功率、投运时间),没有交动态属性(当前可调范围、当前状态、当前通信质量);
  • 上行没有质量位------坏值与有效值不区分,调度侧只能按「有数据」处理;
  • 接入只做了单向------数据上来了,指令下不去,主体不具备被调用的资格;
  • 接入协议版本与点表版本没有绑定,平台升级后点表漂移,问题在半年后才暴露。

4.3 卡口三:并网与涉网测试

要达成:验证资源在并网与调度条件下行为正确、指令执行可靠、通信异常时的行为可预期。

测试项按「四类」组织(具体测试规程、判据与阈值以国家能源局、省级电网公司发布的并网检测与涉网测试规程、以及业主与电网签署的并网调度协议为准,本文不写任何判定数值):

类别 关注点 典型测试动作
调节能力类 可调范围、响应特性、爬坡特性、调节精度 给定目标值的阶跃与斜坡指令,观察执行曲线
通信可靠性类 指令接收可靠性、超时重发、断链后的行为 模拟通信中断,观察本地行为与恢复后的补报
保护与安全类 保护配合、越限与紧急状态下的行为 触发异常条件,确认设备与策略的处置顺序
计量一致类 执行动作与计量记录是否同步 调指令的同时比对执行回执与计量冻结曲线

常见退回原因:

  • 只在理想网络 下测过,没有做断链测试;
  • 只测了聚合平台侧 的响应,没有测资源侧的响应,两段时延被当成一段;
  • 测试用的指令集与实际运行的指令集不一致(联调用的是内部调试码,不是调度真实下达的编码与点号);
  • 应急策略写成了文档没有落进配置------文档写「通信中断则保持当前出力」,配置里却是「保持最后一条有效指令」。

4.4 卡口四:计量装置就位

要达成:面向结算的计量链路成立,计量点与资源、与结算单元的绑定关系唯一且可审计。

这一卡口要交付四样东西(B 推导):

  • 关口计量点清单------含计量点编号、装设位置、对应的主体与资源、计量对象(关口/分项/设备);
  • 计量装置技术档案------检定状态、封印状态、二次回路接线方式、通讯方式;
  • 冻结与采集约定------冻结时刻、采集周期、缺失补采规则、时钟同步要求;
  • 对账用数据通道的开通与验证记录------这条通道与实时遥测通道是分开的(见 4.2)。

时钟是这一卡口最容易被忽略、后果最重的一项:结算用冻结数据,冻结时刻由装置内时钟决定,装置时钟偏移会让不同计量点的冻结数据落在不同真实时刻上。对账时表现为「系统性偏差」而非「随机误差」,最容易被误判成计量装置有问题(C 参考)。

常见退回原因:

  • 计量点属性填错(关口与分项混淆),结算时才发现;
  • 计量装置与通信装置的时标源不一致,两个钟各走各的;
  • 采集通道没有做缺失补采的验证------平时看不出,掉线那天才发现数据补不回来;
  • 子表与关口表的包含关系没有台账,分摊逻辑写在代码里,审计时无法还原。

4.5 卡口五:主体身份确认

要达成 :同一主体、同一资源,在调度、交易、计量、结算四个专业口径下,名称、编号、边界完全一致。

这一卡口是纯粹的「一致性工程」:把四套编号做一张对照表,逐条核对,差异清零,并指定唯一的维护责任人与变更流程。听起来琐碎,但它是争议处理时最先被调用的东西------争议一旦发生,第一句永远是「你这条记录里的资源编号,跟结算单上的计量点编号,是不是同一个」(C 参考)。

常见退回原因 :调度命名用台区编号、计量用计量点编号、交易用用户编号,三套并行却无对照表;或者对照表做了但没人负责更新。

4.6 准入材料包清单(交付物视角)

下表是聚合商在准入阶段应当形成的材料包。文件名与格式以省级平台与供电公司的实际要求为准;本表的价值在于列出「不交就退」的项(B 推导):

序号 材料 主要内容 缺口时的典型后果
1 主体资格与经营范围说明 法人资格、业务范围、承接能力说明 无法完成主体注册
2 代理关系表 主体---资源---计量点---代理范围---有效期 调度侧查不到可调资源
3 资源清单与可调能力表 资源对象、额定与可调范围、状态定义 调用能力无法评估
4 平台接入方案与点表 通道形态、点表、版本绑定关系 接入联调反复返工
5 涉网测试报告 调节、通信、保护、计量一致四类测试记录 不得参与调用
6 计量点清单与技术档案 点号、属性、检定与封印、时标安排 无法建立结算单元
7 冻结与采集约定书 冻结时刻、采集周期、补采与对时规则 结算数据对不齐
8 四专业编号对照表 调度/交易/计量/结算编号映射 争议无法举证
9 主体身份确认单 各专业口径确认签署 台账挂不上主体
10 网络安全分区与通道方案 分区落位、跨区通道、边界设备基线 联调被合规审查卡回

五 调度对接时序专题:指令---执行---反馈---偏差的四段时序

调度对接是这四段链条里**最容易做成「看起来能用」**的一段,也是最容易在第一次真调用时崩掉的一段。本节把时序拆到字段级。

需要先说明边界:357 号明确了虚拟电厂等新型经营主体可参与电力系统运行与调用,但调用的组织形式、指令形态、偏差口径与考核方式,均以并网调度协议和调度机构发布的接口规范为准(A 官方)。本文给的是工程侧的字段清单与时序骨架,不是调度规程的复述。

5.1 四段时序总览

段 时点 发起方 通道 核心内容 留存证据
T-1 调度周期前 聚合商 上行 可调能力、状态、基线口径、检修计划 能力申报记录 + 回执
T0 调度周期内 调度机构 下行 调节指令(目标值、时限、量纲、标识) 指令日志(含下发时刻)
T0+ 收到后 聚合商 上行 接收确认 / 执行确认 / 拒绝说明 回执(含接收时刻)
T1 执行中 聚合商 上行 执行中状态、实际值及其采样时标 执行日志
T1+ 完成后 聚合商 上行 完成回执、最终实际值、异常说明 完成回执
T2 周期后 双方各自 离线 偏差复算与归因 偏差复算表

「双方各自复算」这一条是关键:偏差不能只有一方算。调度侧按它自己的数据算一遍,聚合商侧按自己留存的数据算一遍,两边的结论不一致时,分歧点本身就是最好的排查入口(D 警示:一方独算的偏差表一旦被质疑,全链路失去可信度)。

5.2 指令标识与状态机

一条指令从下发到闭环,最少要有六个状态,且每个状态转换都要带时刻(C 参考,状态命名以各方接口规范为准):

状态 含义 谁产生 后续动作
下发 调度已发出 调度侧 等待接收确认
已接收 聚合商侧收到且校验通过 聚合商侧 分解到资源侧
已确认 接受并承诺执行 聚合商侧 等待执行
执行中 已下发到资源侧,正在调整 聚合商侧 持续上送实际值
已完成 达到目标并稳定 聚合商侧 触发偏差复算
异常终止 拒绝、超时、资源故障、通信中断 聚合商侧 进入偏差与例外处置

关键要求 :状态不可跳变。调度侧从「下发」到「已完成」之间,如果聚合商侧从未回过「已接收」,那么在争议中「指令是否到达」这一条就不可辩。状态机的价值不在软件实现,在于它把口头争议变成状态记录(D 警示)。

5.3 报文要素:一条回执里必须有的东西

下表是本文对「最小可用回执」的建议要素集(B 推导)。它不规定任何数值判据,只规定字段的语义必须存在:

要素 语义 缺它会怎样
指令标识 与调度下发指令一一对应的唯一标识 无法配对,偏差无从计算
资源/对象标识 该指令作用到的调度对象 无法确定责任边界
目标值与量纲 指令要求达到的目标及其单位 无法判断是否达标
实际值与其采样时刻 执行结果与该结果的采集时刻 偏差混入时延误差
接收时刻 / 执行完成时刻 本地处理的时间证据 责任时点无法划分
状态与异常码 当前状态与异常原因 只能事后翻日志
质量位 数据有效性与测量质量 坏值被当成有效值参与偏差计算
设备侧时间与主站时间 两端时钟对照 时钟漂移不可见

5.4 谁在哪一侧

调度对接里最常见的扯皮是「这一侧到底该谁负责」。下表把责任边界钉死(B 推导,具体以并网调度协议为准):

环节 调度机构侧 聚合商侧 资源侧(业主/场站)
可调能力上送 接收并核定 汇总、申报、口径说明 提供真实能力与状态
指令生成与下达 负责 接收、校验、确认 ---
指令分解 不介入 负责(把总指令分解到各资源) ---
物理执行 不介入 监视与协调 负责实际调节
执行回执 接收 汇总、编帧、上送 提供实际值与时标
偏差复算 负责并给出结论 复核并申辩 提供本地记录
例外处置 发起 执行与上报 配合

「聚合商负责分解、资源侧负责执行」这一层的划分,直接决定了偏差归因的落点:如果聚合商把分解后的目标值直接下给资源侧,资源侧只负责跟随,那么分解误差由聚合商承担 ;反之如果资源侧自行解释,解释偏差由资源侧承担。这两种模式都可以做,但必须在协议里写清楚,不能默认(C 参考)。

5.5 偏差的四类来源与复算方法

偏差不是单一原因。工程上常见的四类来源,每类的复算方法不同(B 推导):

偏差来源 典型表现 复算方法 责任落点
执行偏差 实际值没到目标值 用执行回执的实际值与目标值直接比对 聚合商与资源侧
时延偏差 值最终到了,但晚了 用时间序列做响应过程分析 通信与执行链路
基线偏差 双方对「原来该是多少」理解不同 用双方基线数据交叉比对 基线口径协商
计量偏差 执行记录与计量曲线对不上 用计量冻结曲线与执行日志对齐 计量与采样链路

复算的原料必须来自原始记录 :指令日志、接收与执行回执、平台采集曲线、计量冻结数据、装置与通信日志。任何一次复算都不应依赖人工誊抄的数字(D 警示)。

5.6 通信中断与降级

通信中断时,VPP 侧的处置逻辑必须在联调阶段就测过,而不是运行期临时决定。要点(B 推导):

  • 本地自治边界------断链期间,聚合商侧是保持最后状态、回到安全值、还是继续按计划执行,策略必须事先写死并落进配置;
  • 失联标记------失联时段的数据必须带失联标记,恢复后补报时保留标记,不能与正常数据混在一起;
  • 恢复后对齐------恢复后要做的第一件事是把失联时段的实际执行与计量冻结做一次对齐,确认「实际发生了什么」;
  • 偏差归属------失联期间产生的偏差,归属按协议约定,不要在争议现场临时解释。

这一段是 053 期号讲过的边缘自治思路在市场主体侧的应用,但本文只取「失联标记 + 恢复后对齐 + 归属事先约定」这三点用于调度对接的接口设计,不重述自治分档机制。


六 结算口径与对账专题:结算单元、计量点、对账与争议

结算这一段最容易出现的误区,是把它当成「把数字加起来」。结算口径要回答的是四个问题:算什么(一组计量点)→ 按什么时点算(冻结时刻)→ 用哪份数据算(法定计量数据)→ 算完不一样找谁(举证顺序)。这四问在准入阶段就要定,不能留到出账时再谈(B 推导)。

按 357 号的主体定位,聚合商以自身名义参与结算,被代理的业主通常不单独构成对外结算主体;220 号在省级层面对聚合商的实体化与规范化运行提出要求,具体的结算规则与颗粒度设置以电力交易机构发布的规则和省级实施细则为准(A 官方)。

边界提醒 :本节只写口径,不写任何金额、单价、收益率或分成比例。收益结构与三栏收益模型由 039 讲,本文不重复、不推导、不量化。

6.1 结算单元:结算颗粒的边界

结算单元可以理解成**「谁、哪个品种、哪一组计量点」三要素的交集**(B 推导,命名与颗粒设置以各省市结算规则与实施细则为准):

  • 谁------一个市场主体。聚合商以自己的名义结算,其聚合的资源电量在主体内部再分摊;被代理的业主不是对外结算主体。
  • 哪个品种------同一批计量点,如果同时参与多个市场品种,通常按品种拆成不同结算单元,否则品种之间的偏差会互相污染。
  • 哪一组计量点 ------结算单元的物理边界。这一条最容易出错:结算单元的边界必须与计量点的物理边界一致,不能出现「一个结算单元里有几个点没绑上」或「同一个点出现在两个结算单元里」。

工程上要落成一张结算单元台账,字段至少包含:单元编号、所属主体、对应品种、包含的计量点清单、计量点角色、启用时点、变更记录、与代理关系表的对接关系。台账的维护责任人与变更流程与 4.1 的代理关系表保持一致,避免两套表各说各话(C 参考)。

6.2 计量点绑定:三类点三种角色

027/031/036/037 各稿中反复出现的关口表 / 分项表 / 设备表三类计量点,在本文的结算口径里各有一个明确角色(B 推导):

计量点类别 在结算口径里的角色 常见误用
关口计量点 对外结算的主依据,聚合商与电网之间结算以此为准 用分项点或平台采集值替代关口点出账
分项计量点 内部分摊依据,用于把关口电量分到各资源与各业主 直接拿分项点对外出账
设备计量点 设备级核对依据,用于执行回执与计量曲线的交叉校验 完全不用,导致执行偏差无法归因

三条使用原则:

  1. 对外只认关口。结算单上的电量,来源必须是关口计量点的冻结数据;
  2. 分摊在内、不外泄。内部怎么把关口电量分给业主,是聚合商与业主之间的事,不进入对外结算文件;
  3. 设备点是核对用的。执行回执说「这台储能实际出力如何」,计量点说「这口表记了多少」,两者对不上时就是偏差线索,对得上时就是执行证据。

6.3 三条曲线与冻结时刻

聚合商平台上通常同时存在三条曲线,它们本就不该完全一致,各有用途(B 推导):

曲线 来源 用途 能否用于对外结算
实时遥测 调度/监控通道 实时监视、偏差预警、调度交互 否
平台采集 聚合商采集链路 内部考核、资源排序、结算预演 否(除非协议明确约定)
计量冻结 法定计量装置 对外结算与争议举证 是

三条曲线要在同一张对照视图上看,差异必须能被解释。常见的可解释差异来源(C 参考):

  • 采样周期不同(遥测秒级、平台分钟级、冻结刻级);
  • 死区压缩与数据标幺化处理;
  • 补采与插值造成的形状平滑;
  • 时钟不同步导致的相位错位。

冻结时刻必须统一:同一结算单元内所有计量点采用同一冻结时刻,且装置时钟与主站时钟保持同步。冻结时刻不统一,结算单元内的电量加总就失去意义------这是工程上最容易犯、也最难向业主解释的错误(D 警示)。

6.4 对账流程:四步闭环

对账不是一次性动作,而是每个结算周期都要跑的闭环(B 推导):

  1. 日清分------按日核对当日应结算量与计量冻结量,差异当日标记、当日定位,不留到月底;
  2. 月度对账------以结算单元为单位,逐单元比对全月各时段电量,输出差异清单;
  3. 差异单------每个差异生成一条差异单,写明差异时段、差异量级、差异方向、已定位的原因或待查项;
  4. 处置与闭环------按原因分类流转:属于采集缺失的走补采,属于绑定错误的走台账修正,属于计量装置问题的走计量专业处理,属于口径理解不同的走协议澄清。

差异单是争议的原材料。没有差异单,月底对不上时只能靠回忆和截图,一轮争议下来谁都说服不了谁(C 参考)。

6.5 争议处理:五类证据与举证顺序

当差异无法在结算周期内消除,进入争议流程。本文的建议举证顺序是(B 推导,具体以各省市争议处理规则与协议约定为准):

顺序 证据类型 回答的问题 保管方
1 调度指令日志 下发了什么、什么时候下发 调度机构侧 / 平台侧留档
2 接收与执行回执 是否收到、是否执行、实际值多少 聚合商侧
3 计量冻结数据 实际计了多少 计量专业 / 装置存储
4 通信日志 链路是否中断、中断时段与时长 通信/网络侧
5 人工操作与变更记录 是否有人工干预、干预时点 值班与运维侧

举证顺序的原则是「先指令、再执行、后计量」:调度先证明「我下了什么」,聚合商再证明「我做了什么」,计量最后证明「实际记了多少」。顺序反了,争议会变成各说各话(D 警示)。

另一个原则:原始记录优先于汇总结果。汇总表可以是任何一方后做的,原始记录(指令日志、回执、冻结数据)是共同认可的事实来源。

6.6 结算口径落地清单

编号 口径项 要回答的问题 产出物
S-1 结算单元定义 主体/品种/计量点三要素怎么组合 结算单元台账
S-2 计量点角色 关口/分项/设备各用在哪 计量点绑定表
S-3 冻结时刻 何时取数、是否全单元统一 冻结与采集约定
S-4 曲线对照 三条曲线差异如何解释 三曲线对照视图
S-5 补采规则 缺失如何补、补不了怎么办 补采规则说明 + 记录
S-6 对账周期 日清分 / 月对账的职责分工 对账作业手册
S-7 差异单 差异怎么登记、怎么闭环 差异单模板 + 台账
S-8 举证顺序 争议时先看什么 争议处理约定
S-9 主体分摊 内部如何分给业主 分摊规则(内部,不对外)
S-10 时钟与对时 装置、主站、平台的时标关系 对时方案 + 记录

七 27 号令 4 区 × VPP 环节 × 7 产品落位矩阵

7.1 分区前提

按 27 号令《电力监控系统安全防护规定》,电力监控系统按安全区 I 区 / II 区 / III 区 / IV 区 划分,生产控制大区 (含安全区 I 区 / II 区)与管理信息大区 (含安全区 III 区 / IV 区)之间必须采取横向隔离 措施,安全区 I 区 / II 区与安全区 III 区 / IV 区之间不得直接互联;生产控制大区内部跨安全区 I 区 / II 区的纵向通信必须采取纵向加密认证措施(A 官方,27 号令;具体测评要求以国家能源局发布的配套规定与测评细则为准)。

VPP 主体侧的系统落位遵循三条基本判断(B 推导):

  • 调度指令相关的系统与数据在生产控制大区,落在安全区 I 区 / II 区;
  • 市场、结算、经营分析类系统在管理信息大区,落在安全区 III 区 / IV 区;
  • 跨区数据流 必须经电力专用网闸(横向隔离),并按最小必要原则定义方向、协议、点表与时限。

7.2 落位矩阵

下表回答的问题是「这个市场主体侧的环节,在哪一区、由哪台设备承接、数据从哪来、往哪去 」。它不回答设备选型理由、通信方案比较与产品性能(那是 031 与 037 的范围)。产品能力以产品手册与出厂参数为准(B 推导 + A 官方 27 号令):

市场主体侧环节 安全区 I 区 安全区 II 区 安全区 III 区 安全区 IV 区 领祺 7 产品落位
主体注册 / 备案 / 资质 --- --- 主体档案与资质受理 归档 PBox6219A(管理信息侧档案与数据汇聚)
代理关系与资源台账 --- 资源对象建模 代理关系与台账维护 归档留痕 PEMS300(主体台账主数据)
平台接入(上行) --- 资源状态与遥测接入 上行汇聚与规约转换 --- PBox6218E(边缘采集与转发)+ PBox6219A(汇聚上送)
平台接入(下行指令) 调度接入前置 指令解析与执行编排 --- --- PEMS300(指令解析、分解、状态机)
指令分解与协调执行 --- 集群功率协调与分解 --- --- PFCS-3000B(聚合协调)+ PBox8620(就地自适应协调)
资源侧执行与电气量核对 --- 资源侧控制与量测 --- --- PBox6220-PQCT(电能质量与量测核对)
计量数据采集(结算用) --- 计量采集接入 计量数据归档 结算数据集 PBox6218E(计量采集通道)+ PBox6219A(归档汇聚)
结算单元与对账 --- --- 结算单元台账与对账作业 报表与档案 PEMS300(结算数据组织与对账)
边缘自治与失联兜底 --- 边缘自治节点 --- --- PBox848F(边缘侧安全接入与本地兜底)
跨区数据交换 安全区 I 区 / II 区 → 安全区 III 区 / IV 区:经电力专用网闸,按方向与点表白名单放行 3 配套独立硬件:电力专用网闸 + 纵向加密认证装置 + 时钟同步源

矩阵读法:同一条业务链在不同环节落在不同的区。这就是为什么「把 VPP 平台整体放在一个区」在合规上不成立------一个平台同时承载调度指令(生产控制大区)与市场结算数据(管理信息大区),它的出区路径就必须被逐条定义(D 警示)。

7.3 PBox848F 的定位:三句不能绕开的否定

本节保留一条明确的否定式表述,因为它在方案讨论中被反复误挂(B 推导 + C 参考):PBox848F 是边缘侧的安全接入与本地自治节点,承担采集、就地控制兜底与会话访问控制职能;它不是横向隔离装置,不能替代电力专用网闸,也不能替代独立纵向加密认证装置。 安全区 I 区 / II 区与安全区 III 区 / IV 区之间的横向隔离必须由电力专用网闸承担,生产控制大区内部的纵向加密认证必须由独立纵向加密认证装置承担------这两件事不因任何一台边缘设备的引入而改变(A 官方,27 号令)。

7.4 跨区数据流清单

跨区不是「一条通道」,而是「一组被明确定义的数据流」。下表是本文建议逐条登记的清单格式(B 推导):

编号 数据流 方向 源区 → 目的区 承载设备 关键约束
X-1 资源状态与遥测(聚合结果) 生产控制大区 → 管理信息大区 安全区 II 区 → 安全区 III 区 电力专用网闸 周期、白名单点表、限值
X-2 计量冻结数据 生产控制大区 → 管理信息大区 安全区 II 区 → 安全区 III 区 电力专用网闸 低频、完整性校验、归档留痕
X-3 结算单元台账变更 管理信息大区 → 生产控制大区 安全区 III 区 → 安全区 II 区 电力专用网闸 变更需二次确认、留痕
X-4 调度指令 生产控制大区内纵向 安全区 I 区 → 安全区 II 区 纵向加密认证装置 指令标识、认证、留痕
X-5 执行回执 生产控制大区内纵向 安全区 II 区 → 安全区 I 区 纵向加密认证装置 回执与指令一一对应

X-1 至 X-3 是横向 (跨大区),X-4 至 X-5 是纵向 (大区内跨安全区)。横向与纵向是两套不同的装置、两套不同的配置,不能互相替代------这也是 §7.3 那三句否定存在的意义(D 警示)。

7.5 边界守则:六条不可让渡项

  1. 无网闸不出区------任何从生产控制大区到管理信息大区的数据流,必须经电力专用网闸,且按点表白名单放行,不做「整库复制」;
  2. 无纵向加密不上行------安全区 I 区 / II 区之间的业务通信,经独立纵向加密认证装置;
  3. 不因业务便利破例------任何以「联调」「演示」「临时」为名的临时通道,必须有到期时间与拆除记录;
  4. 不共用账号与介质------跨区两侧的运维账号、U盘、跳板策略分开管理;
  5. 不留后门通道------远程运维通道必须走安全区 I 区 / II 区 / III 区 / IV 区 允许的既定路径,不另辟蹊径;
  6. 旁路要主动排查------已建成的通道要定期核查是否存在未登记的数据流,排查记录留档。

这六条在 031 与 052 的合规检查中已有更细的清单,本文不重复清单内容,只强调在市场主体侧新增了聚合商与业主两类新的边界点------聚合商侧设备往往是分散在用户现场、业主自建网络里的,边界数量远多于单一站场(C 参考)。


八 落地清单:从材料包到配置基线

前面七节把方法论讲完了。这一节给一张可以拿去核对现场的清单。清单按四段组织,每段三列:检查项、证据、责任方。所有条目都不含数值判据------判据以实施细则与协议为准(B 推导)。

清单的编制依据是 357 号与 220 号确定的准入与调用框架,以及 27 号令确定的分区边界要求;四段之间用阶段门串起来,任一段的产出物缺失,后续段落一律按未完成处理(B 推导)。

8.1 准入段清单

# 检查项 证据 责任方
A-1 法人资格与业务范围清楚,可承接聚合业务 资质文件与经营范围说明 聚合商
A-2 代理关系表覆盖到计量点级,五字段齐全 代理关系表(主体/资源/计量点/范围/有效期) 聚合商 + 业主
A-3 资源清单含动态属性(可调范围、状态、通信质量) 资源清单与点表 聚合商
A-4 平台接入三条通道分别定义并验证 接入方案 + 联调记录 聚合商 + 平台
A-5 涉网测试四类(调节/通信/保护/计量一致)均完成 测试报告 聚合商 + 检测方
A-6 计量点清单与资源绑定唯一 计量点绑定表 聚合商 + 计量专业
A-7 冻结与采集约定、对时方案已签 约定书 + 对时记录 聚合商 + 计量专业
A-8 四专业编号对照表差异清零 对照表 + 核对记录 聚合商
A-9 主体身份确认单已签 确认单 各专业会签
A-10 分区落位与跨区通道方案已审 落位表 + 通道清单 聚合商 + 网络安全

8.2 调度段清单

# 检查项 证据 责任方
D-1 接口规范含指令标识、状态机、五时刻 接口规范文本 聚合商 + 调度
D-2 回执要素齐全(目标值/实际值/采样时刻/质量位/异常码) 报文样例与解析记录 聚合商
D-3 联调覆盖正常、异常、断链、恢复四类场景 联调记录 双方
D-4 断链策略已落进配置而非只写在文档 配置基线截图/导出 聚合商
D-5 指令日志与回执可按指令标识追溯 追溯演练记录 聚合商
D-6 偏差复算双方各自可独立完成 复算表样例 双方

8.3 结算段清单

# 检查项 证据 责任方
S-1 结算单元台账与代理关系表一致 两表交叉核对记录 聚合商
S-2 计量点角色(关口/分项/设备)标注清楚 绑定表 聚合商 + 计量
S-3 冻结时刻全单元统一,时钟同步有记录 约定书 + 对时记录 计量专业
S-4 三曲线对照视图可用,差异可解释 对照视图 + 说明 聚合商
S-5 补采规则经断链验证 补采演练记录 聚合商 + 采集方
S-6 差异单模板与流转路径确定 模板 + 流程说明 聚合商 + 结算专业
S-7 举证顺序写入协议或作业手册 协议条款索引 / 手册 双方

8.4 落位段清单

# 检查项 证据 责任方
Z-1 每个系统标注所属安全区(安全区 I 区 / II 区 / III 区 / IV 区) 分区落位表 聚合商 + 网络安全
Z-2 每条跨区数据流登记方向、协议、点表 跨区数据流清单 聚合商
Z-3 横向跨区经电力专用网闸,纵向经纵向加密认证装置 设备配置基线 网络安全
Z-4 无未登记的临时通道,历史临时通道已拆除 排查记录 网络安全
Z-5 生产控制大区与管理信息大区的运维账号分离 账号清单 运维
Z-6 边界设备职责表述准确(不越位、不缺位) 设备职责说明 聚合商

九 12 周落地路线(6 阶段)

节奏按「两周一阶段」设计,每阶段末设一个阶段门评审 。总时长可根据项目规模压缩,但顺序不建议压缩(B 推导)。路线与 220 号的省级推进方向对齐,具体申报窗口、评审安排与并网检测排期以省级主管部门与电网公司当年的工作部署为准(A 官方)。

阶段 周次 主要动作 阶段门产出
阶段一 · 现状盘点 第 1-2 周 资源清单摸底、代理关系梳理、计量点核对、现有系统分区现状评估 资源与计量点基线表、分区现状图、缺口清单
阶段二 · 准入攻坚 第 3-4 周 代理关系结构化、平台接入方案、点表定义、材料包成形 准入材料包(§4.6 十项)、接入方案
阶段三 · 涉网与计量 第 5-6 周 涉网测试四类、计量装置核对与对时、冻结与采集约定 测试报告、计量点绑定表、对时记录
阶段四 · 调度联调 第 7-8 周 接口规范定稿、四类场景联调、断链演练、状态机验证 联调记录、接口规范、断链处置记录
阶段五 · 结算试算 第 9-10 周 结算单元建模、三曲线对照、选一个历史周期端到端对账 结算单元台账、对账报告、差异单样例
阶段六 · 落位与评审 第 11-12 周 分区落位表定稿、跨区通道登记、边界基线、合规自查 落位表、通道清单、配置基线、自查报告

阶段之间允许交叠,但不允许跳序。最常被压缩的是阶段三(涉网与计量)------因为它看起来「只是测试」。实践上这一阶段省下来的时间,会在阶段五的对账里成倍付出(D 警示)。


十 避坑:八个高频误用与纠正

以下八条来自配网储能与用户侧聚合项目的实际反馈,每条给「现象 / 后果 / 纠正」(B 推导 + C 参考)。

10.1 把「已接入平台」当成「已完成准入」

现象 :平台账号开通、数据能看到,就认为准入完成开始等调用。

后果 :调度侧台账里没有可调资源对象,第一次调用落空。

纠正:以「调度侧能否查到该主体的资源对象并下发指令」作为准入完成的判据,不以平台账号为判据。

10.2 用平台采集数据对外出账

现象 :平台曲线完整、刷新快,直接拿来做结算预演并对业主出数。

后果 :与计量冻结数据系统性不一致,逐月解释,信任透支。

纠正:对外只用计量冻结;平台数据只用于内部预演,并在预演报告上标注「非结算数据」。

10.3 代理协议只签到用户层

现象 :协议写了「代理某用户的可调资源」,没有落到计量点。

后果 :资源能调、电量分不清,结算无法归集。

纠正:协议附件必须含计量点清单,且与平台台账一一对应。

10.4 指令回执不带指令标识

现象 :回执只有「已执行」和时间,没有对应关系。

后果 :并发多条指令时无法配对,偏差无法归因。

纠正:把指令标识列为回执必备字段并纳入联调验收项。

10.5 断链策略只写在方案里

现象 :方案写「断链保持当前出力」,配置里是「保持最后指令」或「默认归零」。

后果 :断链时行为与承诺不符,事故分析时无据可依。

纠正:断链策略必须导出配置基线并与方案逐条比对,作为阶段门证据。

10.6 用边缘设备替代专用安防设备

现象 :为省设备,把跨区数据交换直接接到边缘节点上,认为「它也有安全功能」。

后果 :直接违反 27 号令的横向隔离与纵向加密要求,测评不通过。

纠正:横向隔离由电力专用网闸承担,纵向加密由独立纵向加密认证装置承担;边缘设备承担的是采集、兜底与访问控制,职责不能混(详见 §7.3)。

10.7 把安全区 I 区 / II 区的数据「整库」搬到安全区 III 区 / IV 区

现象 :为了做分析,把生产控制大区的数据整体同步到信息侧。

后果 :数据流不受控、点表失控、审计无法说清「哪些数据出过区」。

纠正:按点表白名单逐条登记数据流,只出必要字段,出区频次与时延受控。

10.8 结算口径靠口头约定

现象 :双方口头认可「按冻结数据算」,但没有书面口径,也没有差异单流程。

后果 :第一次差异就成了罗生门,越往后越难谈。

纠正:结算口径写进协议附件,差异单流程写进作业手册,两者都在阶段五前定稿。


十一 合规 + 可信度

11.1 可信度标注汇总

标注 本文中的对应内容
A 官方 357 号(新型经营主体身份)、220 号(省级 VPP 方案)、114 号(发电侧容量电价机制)、27 号令(安全分区与跨区要求)、1656 号(新能源集成融合方向);产品命名与产品手册中的功能定位
B 推导 四步法、五卡口、四段时序、结算单元三要素、三条曲线分工、落位矩阵的区级划分与设备承接关系、12 周路线
C 参考 各专业验收细则的差异、状态机状态命名、差异单流转路径、争议举证顺序的行业通行做法
D 警示 临时通道、人工转发指令、双网卡跳板、口头口径、以平台数据对外出账等高风险做法

11.2 明确不写的内容(边界声明)

为避免过度承诺,本文不写以下内容,读者不应从本文推导出这些结论(B 推导):

  • 不写任何政策条款序号与条文原文;
  • 不写任何量化门槛、考核档位、补偿水平、时限数值;
  • 不写任何金额、单价、收益率、分成比例;
  • 不写设备选型决策树与通道方案比较(见 037);
  • 不写云-管-边-端分层模型与产品分工分级(见 031);
  • 不写收益模型与三栏收益结构(见 039);
  • 不写绿电直连项目的二次系统设计(见 036)。

11.3 待核项

编号 待核内容 核验途径
T-1 220 号省级实施细则中的准入材料清单与提交形态 省级主管部门公开文件、省级电网公司受理指南
T-2 各省 VPP 管理平台的接口形态与点表规范版本 平台方发布的技术规范
T-3 各交易机构对结算单元颗粒度的具体设置 交易机构结算规则
T-4 涉网测试的具体项目与判定规程 国家能源局及省级电网公司发布的检测规程
T-5 偏差考核的具体口径与归属规则 并网调度协议、实施细则
T-6 争议处理的时限与流程 结算协议、交易机构争议处理规则

以上六项本文均按「以实施细则与协议为准」处理,不作数值化表述。

11.4 读者对象与使用建议

本文面向三类读者(B 推导):聚合商的技术与商务负责人 (按 §四 五卡口逐条自查)、电网侧调度与计量专业人员 (按 §五 时序与 §六 口径核对接口与结算单元)、系统集成与设备方(按 §七 矩阵确认每一环节的区级落位与设备职责边界)。建议的阅读顺序是 §〇 → §四 → §五 → §六 → §七 → §八,其余章节按需回看。三类读者如果只看一页,建议看附录 A 与附录 C:前者对应 357 号与 220 号落下来的准入动作,后者对应结算口径与 27 号令 4 区的落位关系。


附录 A · 聚合商准入五卡口速查

卡口 一句话判据 最容易缺的东西
一 主体与代理 调度台账能查到「主体---资源---计量点」链路 协议未落到计量点
二 平台接入 三条通道(上行/下行/计量)分别可用 下行通道未验证
三 涉网测试 四类测试有报告,含断链场景 断链未测、只测平台侧
四 计量就位 关口/分项/设备角色清楚,冻结与对时已定 时钟不同步、补采未验
五 身份确认 四专业编号对照差异清零 对照表无人维护

五道卡口的排列顺序对应 357 号的主体身份界定与 220 号的省级准入方向之间的工作分解;顺序颠倒会导致责任主体不清与台账回溯困难(C 参考)。

附录 B · 调度对接时序与偏差处置速查

事项 要留的证据 一句话要点
能力上送 申报记录 + 回执 没有能力上送,调度只能保守调用
指令下达 指令日志(含标识与时标) 指令无标识,后面全乱
接收确认 回执(含接收时刻) 「是否到达」只能靠状态记录说清
执行与回执 实际值 + 采样时刻 + 质量位 采样时刻错位会被算成响应慢
偏差复算 双方各自的复算表 一方独算的偏差不成立
断链处置 配置基线 + 失联标记 + 恢复对齐记录 策略要在配置里,不在文档里
争议举证 指令日志 → 回执 → 冻结数据 → 通信日志 先指令、再执行、后计量

附录 C · 结算口径与 4 区落位速查

结算口径项 要点 落位提示
结算单元 主体 × 品种 × 计量点组 台账在安全区 III 区,变更需跨区回传生产控制大区确认
计量点角色 对外认关口、内部分项、核对设备 计量采集在安全区 II 区接入,归档到安全区 III 区
冻结与对时 全单元统一冻结时刻 对时链路与计量采集链路同源
三条曲线 遥测/采集/冻结各有用途 遥测在安全区 II 区,冻结数据经网闸出区
对账与差异单 日清分、月对账、差异单闭环 对账作业在安全区 III 区,结果留档安全区 IV 区
争议举证 原始记录优先、顺序固定 证据分散在安全区 I 区 / II 区 / III 区,调取需授权与留痕

一句话收束 :357 号给了聚合商一张身份,220 号给了省级层面的准入路径,而真正决定这家聚合商能不能被调度、能不能被结算、能不能过合规审查的,是本文这四段工程链------准入把身份换成了对象,调度把对象换成了数据,结算把数据换成了口径,落位把口径守在了分区里(B 推导)。

相关推荐
大陈子编程2 小时前
动态规划(C++):从入门到实战的完整指南
1024程序员节
Godspeed Zhao2 小时前
具身智能系统概论——边缘计算和云端协调
人工智能·边缘计算·1024程序员节
JavaPub-rodert2 小时前
不用 React、Vue,也不用后端:王仕宇是怎么把 JavaPub Tools 做成 Web + Electron 双端产品的
1024程序员节
桐盛科技2 小时前
基于边缘计算网关的 Modbus 与 DL/T 645 协议数据清洗与断网续传实现
边缘计算·1024程序员节
u1301302 小时前
GitHub 热榜项目:日榜(2026-10-24)
人工智能·github·1024程序员节
sbjdhjd2 小时前
从黑板事实到长链路剪枝:AI 渗透测试 Agent 的实验、失效与改造
人工智能·网络安全·数据挖掘·php·agent·剪枝·1024程序员节
Xxtaoaooo9 小时前
双11避坑:我用 WorkBuddy + TextIn xParse 做了个「避坑对比台」,商品详情图丢进去,参数矛盾自动现形
人工智能·1024程序员节·textin·workbuddy·ai数据层基础设施