明说·协议课 第 14 讲｜V2G 不是“把功率写成负数”

本讲以 OCPP 2.1 Edition 2 Part 2 的 Q 章、相关设备模型与数据类型为规范主线，以 Part 4 OCPP-J、Part 5 Certification Profiles、Part 6 Test Cases、2026-06 Errata，以及截至 2026 年 9 月可取得的 PICS CS 1.0.3、PICS CSMS 1.0.1 校准报文和测试边界。ISO 15118-20:2022 只用于标识车—桩责任；国内并网、保护和市场规则若未取得并核对项目适用的一手正文，本讲不作全国统一结论。协议事实的核对时间为 2026 年 9 月。

第 13 讲结束时，我们已经把站级约束、Charging Profile、设备求值和现场测量连成一条单向控制链。园区的光储充站不再只会回答“计划有没有下发”，而是能够继续追问：计划作用于哪一层，设备当前采用哪份约束，车辆实际取了多少功率。

现在，园区希望在一个调节时段内让车辆向外释放 20 kW。站级分配器给出目标，协议适配器生成负向计划，Charging Station 返回 Accepted。平台页面很快亮起绿色状态：V2G 成功。

可是现场可能一度电也没有送回来。

也可能 EVSE 已经观察到反向功率，园区并网点仍在从电网取电。再往前一步，即使并网点确实出现了出口功率，这段功率也可能错过调度时窗，没有达到持续时间或基线要求，更没有进入结算。这里的 20 kW 是一组验收推演数据，不对应未经来源支持的客户事故。它揭示的问题却非常真实：我们把一条控制消息走通，究竟证明了什么？

OCPP 2.1 为双向功率传输补上的并不只是一个负号。它提供 V2X 能力发现、即时与延迟授权、能量传输方式协商、双向运行模式和按交易上报的测量证据。但协议每向前走一步，只能证明这一层参与方已经声明或观察到了什么。车辆同意放电、EVSE 具备双向功率级、站点允许反送、并网点出现净变化、某项电网服务达标，仍然是不同问题。

所以本讲要建立的主线是：负值只说明平台表达了一次放电控制意图。我们要沿着能力声明、本次授权、能量方式协商、实效控制和反向测量逐层取证，再核对测量来源、项目声明的电气边界和验收条件，才能判断结果究竟停在 V2X 控制、走到了本讲所说的 V2G 电网边界，还是已经完成更高一层的电网服务与结算。

一、-20 kW 已经受理，现场仍可能一度电也没有送回去

OCPP 2.1 的 ChargingSchedulePeriodType 可以表达双向控制。在 chargingRateUnit=W 时，正 setpoint 表示希望车辆充电，负 setpoint 表示希望车辆放电；limit 是充电侧上限，通常为非负值；dischargeLimit 是放电边界，使用负值。这三个字段处理的是目标与边界，语义并不相同（OCPP 2.1 Edition 2 Part 2，Q.2.1）。

下面是一份只为说明符号语义而裁剪的 SetChargingProfile。消息 ID 使用去掉连字符的 UUID v4，只是这套课程的示例约定。OCPP-J 真正要求的是：消息 ID 为最长 36 个字符的字符串，同一发送方在相同 Charging Station 标识的连接范围内保持唯一，响应原样复用请求 ID；协议没有强制 UUID 格式（Part 4，4.1.4、4.2.2）。

[2,"8f861bd641d24ab38fc647b964dbc237","SetChargingProfile",{
  "evseId":1,
  "chargingProfile":{
    "id":14021,
    "stackLevel":3,
    "chargingProfilePurpose":"TxProfile",
    "chargingProfileKind":"Absolute",
    "transactionId":"tx-20260901-74128",
    "validFrom":"2026-09-01T10:00:00Z",
    "validTo":"2026-09-01T10:15:00Z",
    "chargingSchedule":[{
      "id":1,
      "startSchedule":"2026-09-01T10:00:00Z",
      "duration":900,
      "chargingRateUnit":"W",
      "chargingSchedulePeriod":[{
        "startPeriod":0,
        "operationMode":"CentralSetpoint",
        "setpoint":-20000,
        "limit":10000,
        "dischargeLimit":-25000
      }]
    }]
  }
}]

这段报文能证明 CSMS 表达了什么：在有效窗口内，它希望这笔交易尽量跟随 -20000 W 的目标；若向放电方向跟随，不能越过 -25000 W 的边界；充电方向又受 10000 W 上限约束。它不能证明车辆允许放电，不能证明车—桩已选中双向方式，也不能证明该 Profile 在设备当前求值链里胜出。

即使设备随后返回：

[3,"8f861bd641d24ab38fc647b964dbc237",{"status":"Accepted"}]

我们新增的证据也只是“这次设置请求得到了接受响应”。设备仍可能因为能力、授权、车辆需求、本地保护、更高优先级约束或计划生命周期而没有形成反向输出。把这一响应直接映射成 V2GActive=true，等于从协议受理一步跨过了执行和物理结果。

工程上至少要保留五个彼此独立的判断：

第 13 讲建立的 ControlIntent → ProtocolProjection → EffectiveControl → ControlEvidence 仍然有效，只是到了双向场景，前面还要加上三段：CapabilitySnapshot → AuthorizationDecision → EnergyTransferAgreement。少掉任何一段，负数都可能只是一个孤立的字段。

二、先问电能送到哪里，V1G、V2H、V2B 与 V2G 才不会混成一类

行业里最容易引起争论的往往不是技术，而是同一个缩写背后站着不同的电气边界。有人看到车辆能放电就称为 V2G；有人要求必须把电卖回公共电网；还有人把参与调频和结算也写进定义。我们不必先争一个唯一词义，可以先问两个更可执行的问题：电能送到了哪里，以及项目声称提供了什么服务。

“V2G 电网边界结果”是本讲为了项目声明和验收而采用的工程标签，不是 OCPP 的官方状态，也不是对 V2G 的普遍定义。它不要求项目一定进入电力市场，更不要求完成结算。反过来，结算没有完成，也不能抹掉已经发生并被核对的物理交互。

这些标签也不总是互斥。车辆向园区输出 20 kW 时，建筑负荷若有 15 kW，前 15 kW 先表现为减少园区从电网取电，剩余 5 kW 才可能穿过并网点。这个过程可以同时具有 V2B 的能量去向和电网侧的可观察变化。如果调度目标本来就是把园区进口功率从 100 kW 降到 80 kW，那么并网点仍处于进口并不代表服务必然失败；它是否达标，要看项目约定的是净出口、削峰，还是相对基线的负荷变化。

因此，平台上的 v2xType 最好不是一个代替所有判断的枚举。我们至少还要保存：声明的能量目的地、电气边界标识、允许的功率方向、是否涉及公共电网、是否关联服务产品、验收规则版本和证据来源。这样，当项目从“园区削峰”升级到“公共电网互动”时，我们修改的是声明和验收边界，不是把同一条 EVSE 测量换个标签。

三、OCPP 2.1 为什么写 V2X，以及这套协议到底管到哪里

OCPP 2.1 Part 2 的 Q 章有意采用 V2X。规范把 V2G、V2H、V2B、V2L 都放在这个上位词下，并把 V2H、V2B 描述为 V2G 的特殊情形；V2L 因为不需要 OCPP 通信，不属于该功能块关注的链路。这里的分类与很多项目按电能去向所做的业务分类并不冲突，只是观察角度不同（Part 2，Q.1）。

规范还解释了另一个命名原因：ISO 15118 语境中的 V2G communication interface 指车辆与充电站之间的通信接口。如果我们继续用 V2G 泛指所有双向电能业务，很容易把“车—桩怎样通信”和“电能最后送到哪里”说成同一件事。OCPP 因而在 Q 章后续用 V2X 讨论双向功率传输。

这也给我们一条很清楚的责任分界：

车辆  ←── ISO 15118-20 / CHAdeMO 等 ──→  Charging Station
                                         │
                                         │ OCPP 2.1
                                         ▼
                                       CSMS
                                         │
                       站点 EMS / 聚合控制 / 上游调度与市场接口
                                         │
                                  PCC 与项目计量证据

OCPP 负责 Charging Station 与 CSMS 之间的能力声明、授权上下文、能量方式信息、控制计划和测量报告。ISO 15118-20 等协议处理车辆与充电设备之间的服务选择和双向参数。站点 EMS 处理站内资源、保护边界和聚合约束；上游系统处理调度、考核与结算。它们是前后衔接的责任层，不是几套可相互替代的同层协议。

还要把“协议证据”和“独立物理事实”分开。Charging Station 通过 OCPP 上报 Power.Active.Export，能够形成一条来源明确的设备报告，适合进入审计链；但报文名称本身没有自动完成电表校准、测点映射、拓扑核验和防篡改验证。越靠近合同 PCC 和结算，我们越要说明：谁测的、在哪里测的、何时测的、方向怎样定义、准确度和时间质量怎样、这块表是否有资格承担相应结果。

所以我们不会说“OCPP 只能看到 EVSE”。OCPP 可以承载具体 EVSE、整站入口和配置的上游测量。我们同样不会因为看到了 evseId=0、location=Inlet 或 UpstreamMeasurands，就把这个样本直接认作项目的合同 PCC。协议给了表达能力，项目还要给出测点身份和信任边界。

四、第一步不是下发负值，而是通过 Device Model 发现能力

一个声称支持 OCPP 2.1 的设备，不代表每个 EVSE 都支持双向