充电通信部件专题站 · 功能落地类
EVCC支持Plug & Charge吗？车端支持只是五方之一
新能源汽车充电通信 · 自动认证落地 · 约3600字
EVCC支持Plug & Charge吗——多数面向CCS市场的产品都能给出肯定回答，但这个答案的实际价值有限。因为Plug & Charge不是一个车端功能，而是一条要跨五方才能闭环的链路：车端EVCC、桩端SECC与运营商、移动出行服务商、证书体系、以及跨运营商漫游。车端支持是必要条件，却远不是充分条件。本文讲清这五方各自的门槛、PnC与AutoCharge的区别、实际可用率怎么估，以及验收时该测什么。
阅读前提本文聚焦PnC的落地条件与生态。协议支持等级的分级判定见《EVCC支持ISO 15118吗》，通信时序与协议分层见《EVCC充电模块工作原理》，EVCC的整体职责见《EVCC充电模块作用》。
一、先分清三种"插枪就能充"
现实中至少有三种方式能做到少操作或零操作充电，用户体验相似，技术含义完全不同。把它们混为一谈，是选型阶段最常见的误判。
| 对比项 | Plug & Charge（PnC） | AutoCharge | EIM 外部识别 |
|---|
| 用户操作 | 插枪，无需任何操作 | 插枪，无需任何操作 | 刷卡 / App / 扫码 |
| 识别依据 | 车内合约证书 + 私钥签名 | EVCCID（PLC 模块 MAC 地址） | 车外凭证（卡 / 账号） |
| 安全性 | 可验证、可吊销、防冒用 | 无加密，标识可被伪造 | 取决于卡与账号体系 |
| 标准依据 | ISO 15118-2 / -20 标准功能 | 非标准功能，运营商自建 | ISO 15118 允许的方式之一 |
| 车端 EVCC 要求 | 证书存储 + 安装更新 + TLS 安全会话
投入最大 | 能建立基础通信、EVCCID 稳定不变
车端几乎零改动 | 基础协议即可，无证书需求
投入最小 |
| 跨运营商通用 | 可通用（需互认协议） | 不通用，仅限自建运营商 | 依卡与账号覆盖范围 |
图1 PnC、AutoCharge、EIM 三种认证方式对照
最容易混淆的一点AutoCharge 的体验像 PnC，但它不是 PnC。它用运营商自建的标识绑定实现，不跨运营商通用、无密码学保障；把它当 PnC 验收，会留下安全与互通隐患。
关键点如果供应商演示"插枪即充"，先问一句靠什么识别的。用EVCCID绑定的是AutoCharge，车端几乎不用改；用合约证书签名的才是PnC。两者的开发量、安全等级和跨网通用性完全不在一个量级。
二、PnC 的信任链：证书从哪来、由谁签
PnC的本质是"用密码学证明这辆车属于某个付费合约"。要成立，就必须有一套各方都认的信任链。理解这个层级，才能明白为什么车端支持只是其中一环。
V2G 根证书
信任锚，各方共同认可 |
| ▼ |
车企 OEM 子CA
整车厂持有 | 出行服务商 子CA
MO / eMSP 持有 | 证书服务方 子CA
CPS 签发中转 | 充电运营商 子CA
CPO 持有 |
| ▼ | ▼ | 中转 | ▼ |
车辆预置证书
出厂写入 EVCC
用于首次申请 | 合约证书
绑定付费合约
存于车端安全区 | 不签发叶证书
负责申请转发 | 充电桩证书
SECC 侧持有
用于 TLS 会话 |
每次会话：车用合约证书私钥签名 → 桩沿信任链校验至根证书 → 授权通过
桩端必须持有并信任对应的根证书与中间证书，否则校验失败 |
车端只负责左侧两个方框，其余全部在车外
这就是"EVCC支持PnC"却仍然充不上的结构性原因 |
图2 PnC 信任链结构与各方持有的证书（示意，具体层级与命名以适用标准版本为准）
三、五方责任矩阵：谁不到位都不行
| 参与方 | 必须做到 | 缺失时的现象 |
|---|
| 车端 EVCC | TLS会话、证书安全存储、安装与更新报文、有效期管理、回退逻辑 | 授权阶段失败或直接不进入PnC流程 |
| 整车厂 OEM | 产线预置证书与信任锚、生命周期管理、OTA通道 | 车辆无法完成首次证书申请 |
| 桩端 SECC / CPO | 开启ISO 15118与TLS、持有并更新根证书、支持证书安装中转 | 该站点只能刷卡，车侧一切正常 |
| 出行服务商 MO | 签发合约证书、绑定用户账单、维护吊销状态 | 证书拿不到，或有证书但无法结算 |
| 漫游与结算 | CPO与MO之间有互认协议与清算通道 | 本网可用、换一家运营商就被拒 |
责任边界提示零部件供应商能承诺的只有第一行。把"PnC能不能用"整体压给EVCC供应商，既不合理也不可执行。合理做法是：技术要求书里明确车端应实现的能力，同时由整车厂或项目方负责后四行的接入。
四、实际可用率怎么估：三个系数相乘
项目评审时经常出现的偏差是：车端支持率按100%算，就认为用户体验也接近100%。实际上PnC可用率是几个环节相乘的结果，任何一项不高，结果都会明显下降。
# PnC 实际可用率（估算方法，非市场数据）
可用率 = 车端就绪率 × 桩端支持率 × 漫游互认率
代入一组假设值说明量级关系：
车端就绪（证书有效） 0.95
桩端开启 PnC 0.30
漫游互认覆盖 0.70
→ 0.95 × 0.30 × 0.70 ≈ 0.20
含义：车端做到 95%，用户仍有约八成场次要靠刷卡
→ 所以回退 EIM 不是备用功能，而是主力路径
上面的系数只用于说明结构关系，具体数值随市场与年份变化很大，项目评估时应按目标区域实际调研值代入。要记住的是这个乘法结构本身：桩端支持率通常是最短板，而它不在车端控制范围内。
授权耗时也要算进体验
# PnC 比 EIM 多出来的时间开销
共同部分：SLAC + SDP + TCP —— 数秒量级
PnC 额外：TLS 握手 + 证书链校验 + 签名验证
首次会话额外：证书安装往返（需后台参与，明显更慢）
→ 日常会话：PnC 通常与刷卡相当或更快（省去人工操作）
→ 首次安装：可能长于常规等待，需在交互上给出提示
→ 若安全芯片算力不足，签名环节会成为瓶颈
五、证书生命周期：五种状态与对应行为
PnC失效大多不是"协议写错了"，而是证书处在某个未被处理的状态。技术要求书应当把五种状态的行为逐条定义清楚。
| 证书状态 | EVCC 应有行为 | 用户应看到什么 |
|---|
| 未安装 | 在支持的桩上发起安装；不阻塞本次充电 | 正常刷卡充电，后台静默完成安装 |
| 有效 | 直接用于授权 | 插枪即充 |
| 临近到期 | 按阈值提前触发更新，更新失败可重试 | 无感，仍然插枪即充 |
| 已过期 | 立即回退EIM，同时尝试重新安装 | 提示改用刷卡，充电不受影响 |
| 已吊销 | 停止使用并清理，回退EIM，等待重新签发 | 提示联系服务方，充电不受影响 |
核心原则任何证书异常都不应导致车辆无法充电。PnC是体验优化，不是充电的前置条件。把这条写进需求，能挡掉后续绝大多数现场事故。
六、真实工程场景
场景1：车端先做能力预埋，功能分期开放
常见做法是量产前完成TLS与证书存储能力、报文实现，但PnC默认关闭，先保证基础与ISO授权路径稳定。等证书体系和运营侧联调完成后，通过OTA分批开放。这样上市节点不被生态进度绑住。
场景2：商用车队的自建闭环
物流车队、公交场站这类"自有车、自有桩"的场景，PnC反而最容易落地：不涉及跨运营商漫游，证书体系可在自有范围内闭环，桩端配置可控。对这类项目，PnC的实际收益（免刷卡、免账号管理、司机零操作）比乘用车公共充电更明确。
场景3：把AutoCharge当过渡方案
部分运营商用EVCCID绑定实现类似体验，车端几乎无需改动。作为短期过渡有实用价值，但要清楚三点局限：标识可被伪造、不跨运营商通用、不属于标准功能。项目文件里应与PnC分开表述，避免验收时口径不一致。
七、故障案例：车桩都没问题，跨运营商就被拒
技术全部正确，缺的是一份互认协议
现象：某车型PnC功能验收通过，在合作运营商的站点插枪即充稳定可用。但用户反馈在另外几家运营商的站点，虽然桩上明确标注支持自动认证，插枪后仍然授权失败，只能刷卡。同一辆车、同一张证书，换回合作运营商站点又完全正常。
排查：
先排除车端：会话完整推进到授权阶段，TLS握手成功，证书未过期未吊销，说明车端能力与证书状态都正常。
看拒绝环节：失败发生在桩端返回授权结果时，而非证书校验阶段——桩能读懂证书，但不接受它。
核对签发方：证书由某出行服务商签发，失败站点所属运营商与该服务商之间没有生效的互认与清算安排。
复核站点标注：桩确实支持自动认证，但只对其已互认的服务商签发的证书放行——标注与实际可用范围不是一回事。
根因：不是技术故障，而是商务与漫游层面的覆盖缺口。PnC的授权链条最后一环是"运营商愿不愿意为这张证书出电、并向签发方结算"，这一环由协议关系决定，不由代码决定。
处理：车端无需改动，仅优化提示文案，让用户在被拒时清楚可以直接刷卡；同时由项目方推进与更多运营商的互认覆盖，并在用户手册中说明PnC的适用范围随覆盖扩展逐步提升。
经验PnC的排障要先分清是技术不通还是商务不通。看拒绝发生在哪一环：证书校验失败多为技术问题（信任锚、有效期、TLS配置）；校验通过但授权被拒，就要往互认与结算方向查。这个判断能省下大量无谓的车端排查。
八、验收该怎么测：六项必测
首次安装全流程：空白车辆从零完成证书安装并成功自动充电，记录耗时。
证书过期行为：人为把有效期改短，验证是否按预期回退EIM且充电不中断。
证书吊销行为：模拟吊销状态，验证是否停止使用并正确回退。
自动更新触发：验证临近到期阈值能否触发更新，更新失败能否重试。
不支持PnC的桩：在只支持基础协议的老桩上验证不会因PnC逻辑影响正常充电。
跨运营商实测：至少覆盖两家以上运营商，明确记录哪些站点可用、哪些不可用及原因。
这六项里，第二到第四项最容易在验收时被跳过——因为演示用的总是新证书。而现场事故几乎全部集中在这三项上。
九、常见问题 FAQ
EVCC支持Plug & Charge吗？
面向CCS市场的主流EVCC具备支持能力，但需具体确认：是否有TLS会话、证书安全存储、安装与更新报文、有效期管理与回退逻辑。这些齐全才叫车端就绪，而车端就绪只是五方之一。
车端支持了，为什么还是充不上？
因为还需要桩端开启ISO 15118与TLS、持有对应根证书，出行服务商签发合约证书并能结算，运营商之间有互认安排。任一环缺失，车端再完备也走不通。
PnC和AutoCharge有什么区别？
PnC用合约证书做密码学身份认证，属标准功能、可跨运营商；AutoCharge用EVCCID（PLC模块的MAC地址）绑定用户，无加密、标识可被伪造、由运营商自建且不通用。体验相似，技术性质完全不同。
支持ISO 15118就等于支持PnC吗？
不等于。ISO 15118允许用外部识别方式（刷卡、App）授权，这样实现同样合规。PnC需要额外的证书体系能力，必须在技术要求书里单独列条。
合约证书存在哪里，安全吗？
应存放在EVCC的安全存储区域（安全芯片或安全区），私钥不可导出。这是PnC安全性的基础，选型时要明确询问存储位置与密钥保护机制，而不只是问"支不支持证书"。
证书过期了车还能充电吗？
设计正确的话可以：应立即回退到刷卡等外部识别方式，同时后台尝试重新安装。如果证书异常会导致完全无法充电，说明回退逻辑缺失，这是必须在验收阶段暴露的缺陷。
交流充电能用PnC吗？
可以。ISO 15118同时定义了交流高级通信，交流侧同样能实现自动认证，且长时间停放场景与有序充电结合收益更高。前提是桩端支持交流高级通信，具体差异见《EVCC跟交流充电有关系吗》。
国内项目需要做PnC吗？
纯国标公共充电场景通常不涉及。但自有车队加自有桩的闭环项目值得考虑，因为不需要跨运营商漫游，落地难度最低、司机零操作的收益最直接。涉及出口CCS市场时则属必选项。
回到最初的问题：EVCC支持Plug & Charge吗？车端能力可以买到，也应该在选型阶段按证书存储、安装更新、有效期管理、回退逻辑四项逐条确认。但真正决定用户体验的，是桩端支持率和运营商之间的互认覆盖——这两项不在车端。把PnC当增值体验来规划，把回退EIM当主力路径来设计，项目风险就基本可控了。
本文属于 充电通信部件专题站 · 功能落地类，围绕EVCC对Plug & Charge的支持条件与落地要素整理。图示为结构与流程示意，证书层级命名以适用标准版本为准；第四节系数仅用于说明估算方法，不代表任何市场实测数据，项目评估请代入目标区域实际调研值。
沪ICP备2022023306号
