明说·协议课第 13 讲｜从站级目标到某一把枪：Smart Charging 怎样闭环

最新推荐文章于 2026-09-20 16:45:29 发布

原创

最新推荐文章于 2026-09-20 16:45:29 发布 · 696 阅读

本讲依据 OCPP 1.6 Edition 2 及其 Errata、OCPP 2.0.1 Edition 4 与 2026-06 Errata、OCPP 2.1 Edition 2 与 2026-06 Errata、相应 Part 5 Certification Profiles、Part 6 Test Cases 和机器可读 Schema，以及《云快充平台协议 V2.1.0》与 GB/T 44130.4-2025 核对。协议事实的核对时间为 2026 年 9 月。设备最终支持哪些 Smart Charging 功能，仍以协议 Edition、功能块、配置变量、型号、固件、认证资料和现场报文为准。

第 12 讲结束时，园区车辆已经通过 APP-TACYB0511 完成授权。我们知道谁可以发起这笔交易，也能把授权决定、账户和交易关联起来。可是，授权成立只解决了“能不能充”的问题；对于一座公共充电与园区车队共用的光储充站，接下来更难回答的是“现在应该充多少”。

我们沿用同一个 ChargingSite。07:50，站内 EMS 根据变压器余量、光伏出力和非充电负荷，把充电区域的可用功率暂定为 300 kW。园区车辆计划 09:20 离场，平台为它当前所在的 EVSE 分配了 90 kW。十五分钟以后，这笔交易的现场功率却只有 62 kW；与此同时，公共区又有车辆接入，另一台设备还报告了本地可用功率下降。

这组数字用于演练协议行为和工程验收，不对应某个未经来源支持的真实事故。它之所以值得讨论，是因为 300 kW、90 kW 和 62 kW 分别属于不同层次：300 kW 是站点侧的业务约束，90 kW 是准备落到设备或交易上的控制意图，62 kW 才是某一时刻观察到的现场输出。把三者放在同一列里比较，很容易得到一个过早的结论——设备没有按 90 kW 执行。

实际情况可能完全不同。90 kW 在协议里也许尚未生效，也许被更严格的整台设备上限压低；设备可能只能向车辆提供 90 kW，而车辆当时只接受 62 kW；也可能控制计划确实没有安装成功，或者测量已经过期。我们需要沿着作用域、Profile 求值、协议受理、设备执行和计量证据逐层核对，才能说明 62 kW 究竟意味着合理受限、服务目标未达成，还是站级安全约束已经失守。

本讲由此建立一条可以验证的协议控制链：平台根据站级约束形成带作用域、有效期和版本的控制意图；设备依据 Profile purpose、stackLevel、本地约束和车辆需求求出当前可执行边界；平台再用计划查询、交易状态与现场测量判断目标是否达成。任何设置成功回执都只证明请求走到了相应协议阶段，不能代替执行结果。

一、300 kW 是站级约束，还不是任何一把枪的协议答案

EMS 给出的 300 kW 通常对应站内某个电气边界，例如充电区域在当前时段可以从变压器侧取得的最大功率。这个边界还没有说明三台 Charging Station 怎样分配，也没有说明一台双枪设备内部怎样分配，更没有说明某辆车是否愿意接受平台为它预留的功率。

从站级快照生成设备计划，至少要经过四次判断。首先是安全边界：变压器、进线、储能、光伏和非充电负荷共同决定当前可供充电使用的功率。其次是设备边界：每台 Charging Station 的模块、线缆、温度和本地负载均衡决定它能接受多大计划。再次是交易目标：离场时间、所需电量、服务等级和当前 SOC 决定某笔交易应分到多少。最后才是协议投影：把业务意图转换为目标设备真实支持的 OCPP Profile、YKC 功率修改或 GB/T 44130.4 功率调节策略。

这几个步骤之间不能用简单乘除替代。如果站级允许 300 kW，三台设备并不一定各得 100 kW；如果某台设备允许 120 kW，它的两个 EVSE 也不一定各得 60 kW。分配器应满足一项基本不变量：同一电气边界下，各设备可执行上限的合计不得超过当前站级可用充电功率。至于剩余容量怎样在交易间分配，则属于策略问题，需要在安全约束已经成立以后再处理。

图中把 EMS、CSMS、Charging Station、EVSE/交易和车辆放在不同层。EMS 形成站级约束，CSMS 负责分配并投影到桩—云协议；Charging Station 还要合并本地限制和车辆条件，最终输出由站级与 EVSE 侧测量回流。ISO 15118 车辆需求可以通过 OCPP 进入 CSMS，但它不会让 ISO 15118、OCPP 和 EMS 变成同一种协议。

为了让这条链可追溯，站级计算不宜只产生一个 limit=300000。一份可以进入生产的约束快照，至少还要说明作用对象、生成时间、有效区间、功率方向、测量边界、输入证据和策略版本。光伏数据迟到、总表质量异常或车辆离场计划变化时，平台才能判断当前计划应该继续沿用、降级，还是重新计算。

二、“最大功率”的含义，由作用域和生命周期共同决定

标题里的“某一把枪”便于业务沟通，落到协议时却必须更精确。OCPP 1.6 以 Charge Point 和 Connector 组织 Smart Charging；OCPP 2.x 改为 Charging Station 和 EVSE，Connector 是 EVSE 的物理连接点。平台领域模型还会有 ChargingSite，它可能包含多台 Charging Station、储能、光伏和非充电负荷，但 OCPP Charging Profile 并不直接以 ChargingSite 为标准作用域。

我们可以按下面的层次理解控制对象：

ChargingSite
  ├─ ChargingStationAsset A
  │    ├─ EVSEAsset 1 ─ ConnectorAsset ─ ChargingTransaction 74128
  │    └─ EVSEAsset 2 ─ ConnectorAsset ─ ChargingTransaction ...
  └─ ChargingStationAsset B
       └─ EVSEAsset 1 ─ ConnectorAsset ─ ChargingTransaction ...

同一个 90 kW，如果作用于整台 Charging Station，表示设备所有 EVSE 的合计不得超过 90 kW；如果作用于当前交易，表示这笔交易在有效区间内受到 90 kW 上限约束；如果作为默认交易策略，它会影响随后开始且没有更具体交易计划的交易。数值相同，作用对象和结束条件完全不同。

业务意图	OCPP 1.6 主要载体	OCPP 2.x 主要载体	生命周期要点
整台设备从电网取得的总上限	`ChargePointMaxProfile`，`connectorId=0`	`ChargingStationMaxProfile`，`evseId=0`	约束设备全部 Connector/EVSE 的合计值
新交易采用的默认策略	`TxDefaultProfile`，作用于 0 或具体 Connector	`TxDefaultProfile`，作用于 0 或具体 EVSE	不是当前交易的永久属性，具体作用规则应按版本处理
当前交易专属计划	`TxProfile`，只作用于具体 Connector	`TxProfile`，只作用于 `evseId>0`	服务相应交易；交易结束以后不能跨交易继承
外部系统在设备侧形成的约束	可能进入设备本地限制，没有同名 purpose	`ChargingStationExternalConstraints`	可以参与合并，但 CSMS 不得通过 `SetChargingProfile` 冒充外部来源设置

作用域判断还要和生命周期一起保存。交易 Profile 只按 EVSE 或 Connector 存进“设备影子”，却没有交易引用和有效区间，旧交易结束后就可能污染下一笔交易；反过来，站级上限若被错误拆成每个 EVSE 各 300 kW，设备合计值就会突破站内安全边界。我们需要保存的是“谁在什么时间对谁施加什么约束”，而不只是“当前限额是多少”。

三、OCPP 1.6 的求值核心，是 purpose、stackLevel 与 Composite Schedule

OCPP 1.6 已经提供了完整的 Smart Charging 主干。理解它的关键不在于记住几个 Action，而是按设备实际求值的顺序看清三件事：同一 purpose 中哪个 Profile 当前有效，不同 purpose 怎样共同约束交易，以及整台 Charge Point 的总量限制如何作用于多个 Connector。

3.1 三类 purpose 解决的是三种不同问题

ChargePointMaxProfile 表示整台 Charge Point 的共享限制，只能设置在 connectorId=0。它约束所有 Connector 的合计能量流，因此不能把该值解释成每个 Connector 都可以单独达到的功率。

TxDefaultProfile 是默认交易计划，可以放在 connectorId=0，也可以针对具体 Connector。它回答的是“没有交易专属计划时，新交易采用什么约束”。TxProfile 则服务当前交易，只能设置在 connectorId>0；同一交易存在 TxProfile 时，它取代交易侧的 TxDefaultProfile，再与整台设备的上限共同参与求值。指定 Connector 没有活动交易时下发 TxProfile，设备应丢弃请求并返回相应错误状态。

OCPP 1.6 Errata 还澄清了运行中更新默认计划的行为。新建或更新 TxDefaultProfile 时，正在运行且此前没有使用 Profile，或者正在使用原 TxDefaultProfile 的交易继续运行，并采用新的默认 Profile；删除默认 Profile 后，原来使用它的交易继续运行，但不再受该默认 Profile 约束。这个细节不能只放在文档备注里，它应该进入设备兼容性测试，因为运行中换策略与交易是否继续是两个不同问题。

3.2 stackLevel 只在同一 purpose 内比较

stackLevel 常被误解为所有 Profile 的全局优先级。规范的含义更窄：它用于同一 purpose 内的堆叠选择。当前时刻先结合 validFrom、validTo、chargingProfileKind、startSchedule、duration 与 startPeriod 判断哪些 Profile 有效，再在同一 purpose 中采用更高 stackLevel 的有效 Profile。

同一 purpose、同一 stackLevel 的新 Profile 会替换原 Profile。这会带来一个真实的时间空窗：如果旧 Profile 当前有效，而新 Profile 的 validFrom 在十分钟以后，安装新 Profile 以后旧项已经被替换，新项又尚未生效，设备可能在这十分钟回到较低层计划或默认行为。更新计划时，平台必须检查替换时刻和生效时刻是否连续，不能只比较 Profile ID。

3.3 跨 purpose 合并以后，才得到当前边界

对于一笔交易，设备先在 TxProfile 与 TxDefaultProfile 之间确定交易侧计划，再把它与 ChargePointMaxProfile 等有效限制合并。按时间区间看，Composite Schedule 不会高于参与合并计划中的更严格限制。

例如，交易专属计划允许 90 kW，整台设备当前上限只有 70 kW，这笔交易的 Composite Schedule 不会因为 TxProfile.stackLevel 更高就越过 70 kW。stackLevel 没有让交易计划覆盖整台设备上限的含义。若同一台设备还有其他 Connector 在充电，70 kW 还是设备合计约束，具体怎样分到每个 Connector 由设备本地负载管理继续决定。

W 与 A 也不能在缺少电气条件时直接换算。相数、相电压、接法和设备实际用相不明确，固定用 P=UI 或 P=√3UI 都可能得到错误承诺。平台若需要统一比较，必须保存换算所依据的电气条件、原始单位和公式；条件不足时，宁可把计划标为不可直接比较，也不要悄悄改成另一个单位。

3.4 远程启动前后，交易 ID 的处理路径不同

远程启动以前，OCPP 1.6 的 transactionId 尚未产生。此时可以把 purpose 为 TxProfile 的 Charging Profile 放进 RemoteStartTransaction.req，但 Profile 中不得填写 transactionId。设备会把它应用于随后启动的交易。

下面仍采用前几讲一致的 OCPP-J 数组格式，UniqueId 使用协议课统一约定的无连字符 UUID v4。示例时间使用 UTC；2026-08-31T23:50:00Z 对应上海时间 2026 年 9 月 1 日 07:50。

[
  2,
  "bbe79b5043854437b09fe4394f4c429b",
  "RemoteStartTransaction",
  {
    "connectorId": 1,
    "idTag": "APP-TACYB0511",
    "chargingProfile": {
      "chargingProfileId": 13021,
      "stackLevel": 2,
      "chargingProfilePurpose": "TxProfile",
      "chargingProfileKind": "Absolute",
      "validFrom": "2026-08-31T23:50:00Z",
      "validTo": "2026-09-01T01:20:00Z",
      "chargingSchedule": {
        "startSchedule": "2026-08-31T23:50:00Z",
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          { "startPeriod": 0, "limit": 90000 },
          { "startPeriod": 900, "limit": 72000 }
        ]
      }
    }
  }
]

设备对同一个 UniqueId 返回受理结果：

[
  3,
  "bbe79b5043854437b09fe4394f4c429b",
  { "status": "Accepted" }
]

这里的 Accepted 表示远程启动请求被接受，不表示交易已经开始，也不表示设备当前输出已经达到 90 kW。平台仍要等待 StartTransaction.req。假设设备随后建立交易并从 StartTransaction.conf 得到整数 transactionId=74128，平台才拥有可以用于后续交易专属计划的协议标识。

对于已经存在的交易，平台使用 SetChargingProfile.req，并在 csChargingProfiles 中携带实际 transactionId：

[
  2,
  "c9becbee21c6492e80566246f6399d19",
  "SetChargingProfile",
  {
    "connectorId": 1,
    "csChargingProfiles": {
      "chargingProfileId": 13022,
      "transaction

标签