简电云 | OCPP 1.6、OCPP 2.0.1 与 OCPP 2.1 有什么区别？一篇文章讲清协议演进与技术选型

在充电平台建设中，OCPP 版本并不只是一个连接参数。它会直接影响充电桩的数据模型、交易状态机、安全体系、智能充电能力，以及平台未来能否接入即插即充、双向充电和分布式能源调度。

目前工程中经常遇到三个版本：OCPP 1.6、OCPP 2.0.1 和 OCPP 2.1。OCPP 1.6 仍有较大的设备存量；OCPP 2.0.1 重构了设备、交易与安全模型；OCPP 2.1 则继续扩展双向充电、DER 控制和支付等能力。

本文从研发和架构视角比较三个版本。内容用于协议理解和系统设计，不替代 Open Charge Alliance 发布的正式规范、实施指南及一致性测试要求。

一、先看结论

最重要的判断是：OCPP 1.6 与 OCPP 2.0.1、2.1 不是简单的字段增量关系。特别是从 1.6 升级到 2.x，需要调整设备模型和交易处理逻辑，不能只替换消息名称。

OCPP 2.1 建立在 2.0.1 之上，官方在设计中考虑了 2.0.1 应用逻辑的延续性。但这不等于所有 2.0.1 设备都可以直接处理 2.1 报文。连接双方仍需协商协议版本，并根据各自支持的功能块进行处理。

二、协议框架发生了什么变化

1. OCPP 1.6：以动作消息为中心

OCPP 1.6 的模型比较直观。充电桩通过 BootNotification 上线，使用 StatusNotification 上报连接器状态，通过 StartTransaction 和 StopTransaction 建立交易边界，再用 MeterValues 上传计量值。

典型交易链路如下：

BootNotification
  -> StatusNotification
  -> Authorize
  -> StartTransaction
  -> MeterValues...
  -> StopTransaction

这种模型容易实现，也适合以“充电桩 + 枪口 + 订单”为核心的传统平台。不过，很多设备能力只能通过 GetConfiguration 和厂商自定义配置键描述。当设备包含多个控制器、显示屏、计量模块或复杂传感器时，平台很难用统一方式理解这些组件。

2. OCPP 2.0.1：按功能块和设备模型重构

OCPP 2.0.1 将协议拆分为多个功能块，例如配置管理、授权、交易、计量、智能充电、证书管理、固件管理和显示消息。平台可以根据项目范围选择需要实现的功能块。

更关键的变化是引入设备模型。充电站不再只是若干固定配置键，而是由组件、变量及属性组成：

ChargingStation
  -> EVSE
      -> Connector
  -> Meter
  -> Display
  -> Controller

Component + Variable + Attribute

平台通过 GetVariables、SetVariables、GetBaseReport 等消息读取配置和能力。相较于 1.6 的字符串键值，这种结构更适合自动发现、远程配置和跨厂商管理。

3. OCPP 2.1：在 2.0.1 基础上向能源系统扩展

OCPP 2.1 没有回到另一套完全独立的模型，而是在 2.0.1 基础上增加新的功能块和业务选项。它关注的不再只是“车辆从电网取电”，还包括车辆向外输出能量、充电站参与能源调度、现场费用计算，以及换电和临时支付。

因此，可以把三个版本的定位概括为：

OCPP 1.6：完成充电连接和基础运营
OCPP 2.0.1：建立可管理、可监控、可审计的充电基础设施
OCPP 2.1：让充电设施进一步参与能源与支付生态

三、交易模型：从开始和结束消息转向事件流

OCPP 1.6 的交易模型

OCPP 1.6 使用独立的开始与结束消息：

[
  2,
  "msg-101",
  "StartTransaction",
  {
   
    "connectorId": 1,
    "idTag": "A10001",
    "meterStart": 120035,
    "timestamp": "2026-09-20T08:00:00Z"
  }
]

平台返回一个整数 transactionId，后续 MeterValues 和 StopTransaction 使用该编号关联交易。

问题在于，真实交易可能由插枪、刷卡、远程启动、即插即充、设备离线或重启恢复等多种事件触发。仅用开始与结束两条消息，很难完整表达交易过程中的触发原因和状态变化。

OCPP 2.0.1 的交易模型

OCPP 2.0.1 使用统一的 TransactionEvent，通过 eventType 表达 Started、Updated 和 Ended：

[
  2,
  "msg-201",
  "TransactionEvent",
  {
   
    "eventType": "Started",
    "timestamp": "2026-09-20T08:00:00Z",
    "triggerReason": "Authorized",
    "seqNo": 0,
    "transactionInfo": {
   
      "transactionId": "TX-20260920-0001",
      "chargingState": "EVConnected"
    },
    "evse": {
   
      "id": 1,
      "connectorId": 1
    }
  }
]

这里有三个值得注意的变化：

• 交易标识由充电站侧生成，并使用字符串表达；
• seqNo 用于识别事件顺序和缺失；
• triggerReason 说明本次事件由授权、线缆连接、停止授权、远程命令或其他原因触发。

Updated 事件可携带计量值、充电状态和授权信息，平台不再依赖一组松散消息猜测交易状态。OCPP 2.1 延续该事件模型，并扩展固定费用、固定能量、固定时长以及强制重启后恢复交易等能力。

平台实现建议

同时支持多个版本时，不要让业务订单直接依赖协议消息。可以在接入层把三种协议统一成内部事件：

OCPP 原始消息
  -> 协议适配层
  -> TransactionStarted
  -> TransactionUpdated
  -> TransactionEnded
  -> 统一订单状态机

原始报文仍需保留，用于问题定位和争议复核；统一事件则供订单、计费、风控和通知服务消费。

四、设备与配置管理

OCPP 1.6：配置键模型

1.6 主要通过 GetConfiguration 和 ChangeConfiguration 管理设备。标准定义了一批配置键，但厂商经常增加自定义键，例如：

VendorMeterInterval
VendorDoorAlarmEnabled
VendorPowerModuleCount

平台需要针对不同厂商维护映射表。键名、数据类型、读写权限和取值范围通常依赖厂商文档。

OCPP 2.0.1 和 2.1：设备模型

2.x 使用“组件 + 变量 + 属性”定位配置项。例如，可以表达某个 EVSE 的可用状态、某个计量器的采样配置，或者显示组件的能力。

设备模型带来的工程价值包括：

• 能通过基础报告发现设备支持的组件和变量；
• 可以描述变量类型、单位、上下限、可读写性和监控能力；
• 支持设置变量监控，在阈值触发或数值变化时上报；
• 多 EVSE、多连接器和复杂硬件的层次更清晰。

但设备模型也明显增加了平台复杂度。平台需要保存设备报告、变量定义、属性值、监控规则和厂商扩展，并处理报告分片与版本变化。它不是把 GetConfiguration 改名为 GetVariables 就能完成的升级。

五、安全能力的差异

OCPP 1.6

1.6 项目可以使用 TLS、HTTP Basic Authentication 和客户端证书，但不同设备的实现完整度差异较大。部分安全能力来自后续发布的安全白皮书或安全扩展，而不是最初消息集合中的完整闭环。

因此，1.6 平台经常遇到以下问题：

• 设备长期使用固定密码；
• 证书申请、安装、更新和吊销依赖人工；
• 安全事件缺少统一的上报方式；
• 固件签名校验和安全升级由厂商私有实现。

OCPP 2.0.1

2.0.1 将安全能力纳入协议主体设计，包括安全配置、证书管理、签名固件、安全事件通知和安全日志等。平台可以通过协议完成证书签发请求、安装、删除和清单查询。

工程上仍需注意：协议支持安全功能，不代表部署后自动安全。CSMS 还需要建设设备身份、PKI、证书生命周期、密钥保护、固件签名、审计和告警响应体系。

OCPP 2.1

2.1 继承 2.0.1 的安全基础，同时增加安全动态二维码等与临时支付相关的能力。由于 2.1 涉及双向能量流和更多支付场景，授权边界、指令审计和金额校验的重要性进一步提高。

无论选择哪个版本，都不建议关闭服务端证书校验，也不应把设备序列号直接当成长期凭证。

六、智能充电与能源协同

OCPP 1.6：基础充电曲线

1.6 通过 SetChargingProfile、ClearChargingProfile 和 GetCompositeSchedule 支持基础智能充电。平台可以设置功率或电流上限，实现单桩限功率、站级负载均衡和分时控制。

其局限在于，设备能力、外部限制、车辆需求和电网约束的表达相对有限。不同厂商对多个 Profile 的叠加、优先级和离线执行也可能存在差异。

OCPP 2.0.1：更细的计划与约束

2.0.1 扩展了智能充电数据结构，可以更清晰地交换充电需求、充电计划、网络限制和功率调度信息，并与 ISO 15118 场景配合。适合在站级能源管理系统与 CSMS 之间建立更稳定的控制边界。

OCPP 2.1：双向充电与 DER 控制

2.1 新增双向充电功能块和 DER Control 功能块，并支持 ISO 15118-20 的双向功率传输。这意味着车辆和充电设施不仅是负载，也可能作为可控能源资源参与 V2H、V2B 或 V2G 场景。

对平台而言，数据模型要从“允许充多少电”扩展到：

• 当前允许输入或输出多少有功功率；
• 无功功率、功率因数等目标如何下发；
• 车辆电量需求、离站时间和可用能量如何参与计划；
• 电网、站级 EMS、CSMS 与车辆之间的控制优先级如何协调；
• 双向交易的计量、费用和结算如何区分。

这类能力不能只由 OCPP 服务单独完成，还需要充电设备、车辆、ISO 15118 通信、计量系统和能源管理系统共同支持。

七、ISO 15118 与即插即充

OCPP 1.6 没有完整覆盖 ISO 15118 证书生命周期。项目通常通过厂商扩展对接即插即充，平台之间的实现差异较大。

OCPP 2.0.1 增加 ISO 15118 相关支持，包括证书管理和 Plug & Charge 所需的后台协作能力。CSMS 可以参与合同证书链处理，而不是把全部证书逻辑留在设备私有接口中。

OCPP 2.1 进一步支持 ISO 15118-20，并把双向功率传输纳入协议能力。需要强调的是：支持 OCPP 2.1 不等于设备自动具备 ISO 15118-20 或 V2G 能力。硬件、电力电子模块、车辆通信栈、计量和认证范围都必须同时满足要求。

八、费用、支付与用户交互

在 OCPP 1.6 中，价格计算和支付一般由 CSMS 或外部支付系统负责。充电桩主要上传电量和交易数据。屏幕价格、支付终端、临时用户支付等能力通常依赖 DataTransfer 或厂商扩展。

2.0.1 增强了显示消息、价格信息和交易处理能力，使平台可以更规范地向充电站提供用户提示和费用相关信息。

2.1 增加了更多交易与支付选项：

• 支持固定费用、固定能量或固定时长的交易目标；
• 支持充电站本地费用计算；
• 支持预付卡余额约束；
• 支持内置或独立银行卡终端的临时支付；
• 支持安全动态二维码用于临时支付。

本地费用计算并不意味着平台可以放弃账单服务。平台仍要保存计费规则版本、设备计算结果、计量数据、税费与平台复算结果，并对差异进行处理。

九、OCPP 2.1 新增的换电能力

OCPP 2.1 增加了对两轮车、三轮车和电动汽车换电站的支持。这是 2.1 与前两个版本相比很容易被忽视的变化。

传统充电交易围绕 EVSE 和 Connector 展开；换电业务则需要管理电池身份、仓位、库存、充电状态、取出和归还过程。平台实现时还要关注：

• 电池与用户、车辆、仓门的绑定关系；
• 换出与换入电池的状态和计量信息；
• 电池健康度、温度和循环次数；
• 换电订单异常恢复；
• 电池资产调拨与全生命周期记录。

协议提供标准交互基础，但完整的换电运营仍需要资产、订单、计费和运维系统配合。

十、消息兼容性与接入层设计

1.6 与 2.x 不能直接互通

差异不仅体现在消息名，还包括枚举、标识类型、设备层次和交易状态机。例如：

建议使用协议适配层隔离差异：

WebSocket 接入
  -> 子协议协商
  -> OCPP 1.6 / 2.0.1 / 2.1 解码器
  -> Schema 校验
  -> 版本专属状态机
  -> 统一领域事件
  -> 订单、设备、计费、运维服务

WebSocket 握手应使用对应的 OCPP 子协议标识。服务器不能仅根据报文内容猜测版本，也不应允许连接建立后在同一会话中切换协议。

2.x 的兼容也需要协商

OCPP 2.1 尽量保持 2.0.1 应用逻辑可延续，但新增类型和功能仍要求双方明确支持范围。推荐在设备档案中记录：

• 协议版本及规范修订版；
• 支持的功能块；
• 设备模型报告版本；
• 安全配置和证书状态；
• ISO 15118、双向充电、DER、支付及换电能力；
• 已通过的一致性测试范围。

平台下发命令前，应以设备实际上报和经过验证的能力为准，而不是只看型号说明。

十一、如何选择协议版本

继续使用 OCPP 1.6 的情况

以下场景不一定需要立即升级：

• 已有大量稳定运行的 1.6 设备；
• 业务主要是启动、停止、计量、状态和基础负载均衡；
• 设备硬件不支持 ISO 15118 或复杂安全能力；
• 短期内没有 V2G、换电和现场支付需求。

此时应优先补齐 TLS、凭证轮换、日志审计、离线交易、幂等处理和厂商扩展治理，而不是为了版本号强行升级。

新项目选择 OCPP 2.0.1 的情况

2.0.1 适合需要以下能力的新建项目：

• 标准化设备管理和变量监控；
• 更完整的安全与证书生命周期；
• 稳健的交易事件模型；
• Plug & Charge 与 ISO 15118 协作；
• 更细的智能充电和用户显示能力。

选择设备时，应同时考察协议实现完整度、测试报告和功能块范围，不能只确认“支持 OCPP 2.0.1”。

选择 OCPP 2.1 的情况

若项目明确涉及以下方向，可以优先评估 2.1：

• ISO 15118-20；
• 双向充电和 V2X；
• DER 与站级能源系统协同；
• 现场银行卡或动态二维码支付；
• 本地费用计算和预付卡；
• 两轮车、三轮车或汽车换电。

由于 2.1 较新，设备、测试工具、证书体系和互操作经验仍需逐项确认。项目可以采用“平台先支持、设备按能力逐步接入”的方式，避免把所有新增功能绑定在同一期上线。

十二、从 1.6 迁移到 2.x 的实施建议

第一阶段：双协议接入

保留现有 1.6 链路，新建 2.x 接入服务。统一连接认证、会话管理、心跳、原始报文存储和指标监控，但版本专属 Schema 和状态机保持隔离。

第二阶段：建立统一领域模型

把 connectorId、EVSE、Connector、idTag、idToken、整数交易号和字符串交易号映射为平台内部稳定标识。不要直接复用某个版本的 DTO 作为数据库核心模型。

第三阶段：重构交易和设备中心

将订单处理改造成事件驱动状态机，支持乱序、重复、断网补传和重启恢复。设备中心增加组件、变量、属性、监控规则和能力报告存储。

第四阶段：建设安全基础设施

部署设备证书和 Plug & Charge 所需的 PKI 能力，建立证书申请、签发、安装、轮换、吊销和审计流程。签名固件和安全事件应进入统一安全运营体系。

第五阶段：按需开放高级功能

智能充电、ISO 15118、现场支付、双向充电、DER 和换电应分别进行互操作测试。不要用一次简单的远程启动成功，代替完整协议能力验证。

十三、常见误区

误区一：OCPP 2.0.1 只是 OCPP 1.6 增加了一些消息。 事实上，设备模型和交易模型已经发生结构性变化。

误区二：支持 OCPP 2.1 就等于支持 V2G。 协议只是必要条件之一，还需要车辆、充电设备、电网接口和计量结算能力。

误区三：启用 TLS 就完成了安全建设。 证书生命周期、设备身份、固件签名、密钥保护和安全审计同样重要。

误区四：设备声称支持某版本，就支持该版本全部功能。 OCPP 按功能块实施，应核对具体能力与一致性测试范围。

误区五：升级时可以直接复用原数据库字段。 2.x 的 EVSE、字符串交易标识、设备模型和事件序号通常要求重新设计核心数据结构。

结语

OCPP 1.6 的价值在于成熟和广泛部署；OCPP 2.0.1 的核心价值是重新建立设备管理、交易和安全基础；OCPP 2.1 则把协议进一步扩展到双向能源、DER、现场支付和换电场景。

技术选型不应只比较版本号，而应从设备能力、业务目标、安全要求、能源场景和运维成本出发。对于需要兼容存量设备的平台，较稳妥的方案不是一次性替换 1.6，而是建立多版本接入层和统一领域模型，再让新设备与高级功能逐步迁移到 2.x。

参考资料

• Open Charge Alliance：Open Charge Point Protocol 官方版本说明
• Open Charge Alliance：OCPP 1.6 Specification
• Open Charge Alliance：OCPP 2.0.1 Specification
• Open Charge Alliance：OCPP 2.1 Specification
• IEC 63584：OCPP 2.0.1 对应的国际标准版本