摘要：Plug and Charge 的目标是在车辆插枪后，利用 ISO 15118 证书完成车辆合同识别和充电授权，减少人工输入或刷卡步骤。OCPP 1.6J 发布时并未定义 ISO 15118 消息，因此相关系统需要通过 DataTransfer 机制承载证书管理和授权消息。本文根据Open Charge Alliance 发布的应用说明，介绍 OCPP 1.6J 与 ISO 15118 Plug and Charge的角色关系、消息封装、证书流程、在线与离线授权以及实现时需要关注的边界。本文讨论的是证书管理和自动鉴权，不包含 ISO 15118 智能充电。
一 技术背景
ISO 15118 将车辆与充电设备之间的通信扩展到应用层，Plug and Charge 则使用车辆中的合同证书表示充电合同。车辆建立充电通信后，充电设备可以从车辆侧获得合同证书和 eMAID，并由本地或中央系统完成验证。
OCPP 1.6J 原始规范没有定义 ISO 15118 的证书管理和 PnC 授权消息。OCA 的应用说明给出了一种过渡实现：借用 OCPP 2.0.1 中相关消息的字段语义，将消息 JSON放入 OCPP 1.6 的 DataTransfer.req 和 DataTransfer.conf 中。这样可以在保留OCPP 1.6J 连接方式的同时，传递 ISO 15118 PnC 所需的信息。
这种方式属于针对 OCPP 1.6J 的扩展约定。DataTransfer 不应被泛化为标准消息的替代品，否则容易造成互操作问题。对于普通 RFID 或其他外部识别方式，仍应使用OCPP 1.6 原有的 Authorize 流程。
二 系统角色
1 电动汽车 车辆保存合同证书及其证书链，并通过 ISO 15118 与充电设备建立会话。
2 充电设备 充当 ISO 15118 通信中的服务端，同时通过 OCPP 连接中央系统。它负责读取车辆侧证书信息、执行本地校验、转发证书请求和执行授权结果。
3 中央系统 负责与充电设备交互，保存设备证书和配置，并在需要时调用证书颁发机构或 OCSP响应服务完成证书签发与状态查询。
4 证书颁发机构 对充电设备生成的 CSR 进行签名，返回充电设备使用的 ISO 15118 证书。
5 OCSP 响应服务 根据证书序列号和颁发者信息返回证书状态，用于辅助判断合同证书是否仍然有效。
三 DataTransfer 封装方式
为了让不同实现能够识别同一组扩展消息，DataTransfer 的字段需要保持一致。vendorId 使用固定值 org.openchargealliance.iso15118pnc，messageId 表示内部承载的 ISO 15118 相关消息名称，data 则保存 JSON 格式的消息内容。
[2, "message-001", "DataTransfer", { "vendorId": "org.openchargealliance.iso15118pnc", "messageId": "SignCertificate", "data": "{"csr":""}"}]
应用说明列出的主要 messageId 包括 Authorize、CertificateSigned、DeleteCertificate、Get15118EVCertificate、GetCertificateStatus、GetInstalledCertificateIds、InstallCertificate、SignCertificate 和TriggerMessage。实现时需要区分请求方向和响应方向，并对 data 进行 JSON、长度和字段类型校验。
扩展消息只用于 ISO 15118 相关用例。例如，PnC 授权使用封装后的 Authorize，但普通外部识别仍使用 OCPP 1.6 原有消息。实现团队应将这种边界写入协议适配层，不要让业务代码根据消息名称随意切换授权路径。
四 充电设备证书安装
充电设备证书用于设备参与 ISO 15118 通信和相关安全流程。证书安装可以由中央系统发起，也可以由充电设备主动发起，两种方式最终都会经过密钥生成、CSR 提交、CA 签发和设备校验几个步骤。
1 生成密钥对 充电设备生成新的公钥和私钥。私钥应留在设备安全存储区域，不通过 OCPP 消息传输。
2 提交 CSR 设备通过封装后的 SignCertificate.req 发送 PEM 编码的 CSR。中央系统将 CSR转交给证书颁发机构。
3 返回签名证书 中央系统通过封装后的 CertificateSigned.req 将签名证书链返回给设备。
4 校验并安装 设备校验证书链、有效期、用途和签名，验证失败时返回 Rejected，验证通过后切换到新证书。
如果签名证书迟迟没有返回，设备不应无限制重复生成 CSR。可以通过CertSigningWaitMinimum 和 CertSigningRepeatTimes 配置退避等待时间和重试次数，达到上限后等待中央系统再次触发。
五 车辆合同证书安装与更新
车辆侧的合同证书安装或更新由 ISO 15118 会话触发。车辆将 CertificateInstallation请求发送给充电设备，充电设备再将原始 EXI 数据进行 Base64 编码，放入Get15118EVCertificate.req 的 exiRequest 字段，通过 DataTransfer 发送给中央系统。
1 确定动作 证书首次安装时使用 Install，已有证书更新时使用 Update。
2 转发 EXI 充电设备携带 ISO 15118 schema 版本和 Base64 编码的 exiRequest。
3 获取响应 中央系统处理证书请求，返回 Base64 编码的 exiResponse。
4 回传车辆 充电设备将 exiResponse 还原后发送给车辆，由车辆完成后续证书处理。
这一流程中，中央系统不应直接修改 EXI 内容。它主要负责转发和与相关证书服务交互，同时保留请求编号、设备编号、schema 版本和处理结果，便于排查编码或超时问题。
六 Plug and Charge 授权流程
车辆插枪后，车辆向充电设备提供合同证书和 eMAID。充电设备可以先在本地验证，也可以通过中央系统完成验证。在线场景下，充电设备发送封装后的 Authorize.req，其中可以携带 eMAID、证书以及用于 OCSP 查询的证书哈希信息。
车辆提供 ContractCertificate 和 eMAID -> 充电设备本地校验或发送 DataTransfer Authorize -> 中央系统返回证书状态和授权状态 -> 充电设备决定是否允许充电 -> 交易启动消息使用 eMAID 作为 idTag
中央系统的响应需要同时表达授权状态和证书状态。授权状态可以是 Accepted、Blocked、Expired 或 Invalid 等，证书状态还可能表示证书已撤销、证书链错误、证书过期或无法取得证书。设备端应分别保存这两类结果，避免只记录一个笼统的失败。
使用 PnC 授权时，封装后的 Authorize 替代普通 Authorize.req；使用普通外部识别方式时仍使用原有 Authorize.req。这是 OCPP 1.6 扩展实现中最容易混淆的协议边界。
七 离线授权与证书状态
充电设备离线时无法访问中央系统，因此是否允许继续校验合同证书需要通过配置决定。ContractValidationOffline 为 false 时，设备不能在离线状态下完成合同证书校验；为 true 时，设备尝试使用本地证书链验证合同证书。
本地证书验证通过后，还要结合 Local Authorization List 和 Authorization Cache判断 eMAID 是否允许交易。离线策略应在产品需求和运维配置中明确，不能把“证书格式正确”直接等同于“允许充电”。
证书状态查询可以通过 GetCertificateStatus 完成。请求中携带证书颁发者名称哈希、颁发者公钥哈希、证书序列号和 responderURL，中央系统返回 Base64 编码的 OCSP结果。对于证书撤销、OCSP 服务不可达和响应过期等情况，需要分别定义处理策略。
八 证书存储与安全边界
1 私钥保护 设备私钥只在设备侧生成和使用，服务端保存 CSR 和证书链时不能接触私钥。
2 证书分类 区分 V2GRootCertificate、MORootCertificate 和 V2GCertificateChain，安装和删除时校验证书用途，避免误删最后一张必要的根证书。
3 链长度控制 certificateChain 的长度受配置限制，设备需要在接收前校验长度、编码和链顺序。
4 操作审计 证书安装、更新、删除、授权和失败重试应记录设备编号、消息编号、时间和结果。
5 凭据脱敏 日志中不记录完整私密材料。CSR、证书链和 EXI 数据应根据排障需要设置访问范围。
九 实现与测试重点
协议开发不应只测试一条成功链路，还要覆盖证书无效、链不完整、证书过期、证书撤销、OCSP 超时、DataTransfer 被拒绝、设备离线和重复请求等情况。
1 封装测试 验证 vendorId、messageId、data JSON、字段长度和 Base64 编解码。
2 证书测试 验证 CSR 签发、证书链校验、根证书安装、证书删除保护和证书切换。
3 授权测试 验证在线授权、离线授权、缓存命中、eMAID 不存在和合同证书撤销。
4 异常测试 验证超时、重连、重复回执、未知 messageId、中央系统不支持扩展和重试退避。
5 边界测试 验证普通 Authorize 与 PnC Authorize 的分流，确认 EIM 场景不会误走 PnC 流程。
十 版本边界
基于 DataTransfer 的方案主要解决 OCPP 1.6J 与 ISO 15118 PnC 证书管理和授权的衔接问题。它不是 OCPP 1.6 原生定义的 ISO 15118 消息集合，也不能覆盖所有ISO 15118 功能。
特别需要注意的是，本文所述应用说明不包含 ISO 15118 智能充电功能。如果项目需要通过 OCPP 管理 ISO 15118 智能充电，应评估使用 OCPP 2.0.1，并按照对应版本的安全、证书和能源管理用例实现。
十一 结语
ISO 15118 Plug and Charge 的实现重点不是单独增加一个授权接口，而是建立一条从车辆合同证书、充电设备证书、中央系统到证书服务的完整链路。OCPP 1.6J 场景下，DataTransfer 提供了过渡性的消息承载方式，但实现必须严格区分扩展消息和原有OCPP 消息。
工程上应优先做好证书生命周期、消息封装、在线与离线策略、OCSP 处理和操作审计。在此基础上，再根据设备能力和协议版本扩展更多 ISO 15118 功能，才能保证授权结果可解释、故障可复现、证书可更新。
参考资料：Open Charge Alliance，Using ISO 15118 Plug and Charge with OCPP 1.6，v1.0，2020-09-16。本文为技术内容整理与概述。
