企业官网建设流程全解析

简介：「ISO15118资料整理.docx」是一份面向电动汽车充电通信学习者的标准梳理文档，适合研发、测试及协议入门人员理解车端与充电桩之间的通信机制与安全体系。压缩包仅含1个docx文件，约2.83MB，篇幅按背景架构、通信、证书安全、会话交互四部分组织，目录层级清晰，便于按主题查阅。内容围绕半在线与在线通信模式、V2GMessage、EXI、V2G Transfer Protocol及TCP/UDP/TLS分层展开，并讨论数字证书、证书责任链、签名认证与证书种类等安全要点。会话交互部分还涉及握手、消息结构、交直流相关消息、充电识别模式、时序与错误处理，可帮助读者建立从协议栈到证书体系再到实际消息流程的整体认知。已有4020人学习，适合作为标准入门与项目排错时的参考材料。

1. 从一根充电枪说起：ISO15118 到底在管什么

给车插上充电枪，屏幕却提示“正在协商”，很多人第一次遇到会以为桩坏了。ISO15118 这套电动汽车与充电站之间的通信标准，管的正是插枪之后那场看不见的对话：车怎么自报身份、桩怎么确认安全、双方怎样约定充多少电、什么时候开始、什么时候停。它不负责电池内部怎么发生化学反应，也不负责把电物理送进电池，而是负责“先谈清楚再通电”的规则。搞懂它，再看充电失败、证书报错、消息超时这些现象，就不至于只会拔枪重插。

2. 为什么充电还要“对话”：ISO15118 的背景架构与关键角色

2.1 从“通电”到“协商”：标准出现的真实动因

把充电想成住酒店，基础信号通信像前台只问一句“住不住”，确认有人、有房、能进门；高级双边数字通信则像完整入住系统，要登记身份、选房型、交押金、开发票，还要把账单同步给后台。ISO15118 出现的背景，是电动汽车和充电桩来自不同厂商，支付、身份识别、负载均衡、反向送电这些需求又越来越复杂，如果没有一套共同语言，每换一个桩就要重新对暗号，测试和运营都会变成玄学。

这份资料在开篇就把定位说得很清楚：ISO15118 用来制定一个“全面”的电动汽车与充电设备交互协议，详细规定 EV 与 EVSE 之间的通信细节，包括在通信网络中探测并发现车辆，而后建立桩通信控制器 SECC 和车辆通讯控制器 EVCC 之间基于 IP 协议的通信。这里的关键词是“交互”，不是“供电”。电怎么从桩走到电池，属于另一层工程问题；车和桩先要把身份、权限、计划、安全通道谈拢，后面才轮到能量真正流动。

标准覆盖的范围很宽：智能识别、无线协商、充电与反向充电控制、优化、支付、负载均衡、网络安全和私密性。它也明确不涉及电动车内部电池与其他部件的通信。这个边界很重要，因为很多初学者一看到“充电协议”就以为它连电池管理系统的内部报文也管，结果拿应用层日志去解释电芯温度异常，方向一开始就偏了。ISO15118 更像充电过程的“外交语言”，不是电池内部的“生理指标”。

从架构上看，它同时适用于充电桩给电动汽车电池充电，也适用于反向把电动汽车电池的电能反馈给家庭或分布式电网。正向和反向都走同一套对话框架，只是业务目标不同。这样设计的好处是，车和桩不用为“买电”和“卖电”各造一套完全不同的通信系统；坏处是概念变多，测试时必须先分清当前场景到底是在充电、放电，还是只做身份认证。

2.2 EVCC、SECC 与 SA：谁在跟谁说话

先记住两个主角色。EVCC 是车辆通讯控制器，可以理解为车里的“通信发言人”；SECC 是充电设备通信控制器，可以理解为桩里的“通信接待员”。一份充电交互日志里反复出现的 EVCC 和 SECC，就是这两个发言人在对话。它们之间支持有线或无线的高级双边数字通信，也就是 HLC。通信建立起来之后，才有后面的会话、认证、充电参数协商。

但现实中的充电不只有车和桩。ISO15118 还引入了次要角色 SA，全称 Secondary Actor，指充电过程中间接起作用、或者需要间接交互的角色。这个设定让协议复杂度上升，因为 SECC 和 EVCC 不能假设“全世界只有我们俩”，还要能智能处理与 SA 的关系。有些场景没有 SA 也能完成，有些场景必须和 SA 交换证书、计量回执、清算信息，所以协议必须留出接口。

这张表不需要死记。真正要抓住的是“谁掌握什么信息”。EMOCH 和 EMSP 更靠近账户、授权、清算；DCH、DSO、EMS 更靠近电网需求和功率安排；OEM 靠近设备与证书来源；FO 和 CSO 更靠近车队与站点运营。测试时看到某个字段来自 SA，不要下意识把它当成桩内本地字段；看到某个证书由 SA 提供，也不要以为它一定由 SECC 现场签发。

清算所这个词容易让人发懵。通俗地说，它像交易双方之间的“记账与对账中心”：不是直接给车充电的人，但负责让授权、数据和钱能对得上。资料里提到它最初用于交易结算场景，这个背景不用深挖，记住“它管对账和可信”就够了。对协议测试来说，SA 的存在意味着消息可能不只两个方向，还可能出现后台参与；日志里如果只有 EVCC 和 SECC 的往返，却找不到证书来源，就要考虑是不是漏了 SA 侧。

2.3 HLC、基础信号与无线充电的边界

ISO15118 里有两类容易被混在一起的通信概念：基础信号通信和 HLC 通信。基础信号通信只包含车辆状态交互、能源传输流程启动、安全控制导引这些基础内容；HLC 则包含身份识别、支付、负载均衡、能源传输控制及增值服务。换句话说，基础信号让双方知道“现在能不能开始”，HLC 让双方谈“你是谁、怎么付、充多少、何时调整”。

只有 EV 和 EVSE 都配备 HLC 设备，才可以进行基于 HLC 模式的信息通信。现实中的设备状态可以分成三种：不支持、支持、必须。这个区分在测试计划里很关键。两边都“支持”不代表每次都会走 HLC，可能还要看场景配置；一边“必须”而另一边“不支持”，那就不是简单降级，而是场景直接不成立。看到充电能启动但支付流程缺失，先查 HLC 能力协商，不要一上来怀疑报文编码。

无线通信是 2019 年新增的内容，和有线传输相比多了额外要求。最直观的一点是，充电过程中在司机接通 plug-in 之前就应该开启 HLC 通信，像电磁波无线充电这种没有明显插入动作的过程更是如此。无线通信要建立在“发现”和“协商”上，SECC 的无线接口应该能发现电动汽车的识别模块。它和手机连 Wi-Fi 不完全一样：手机可以在范围内看到一堆接入点再随便选一个，电动车无线充电则要考虑停稳、避免一串可用 SECC 造成误选，所以 SECC 端要广播识别信息与必要的发现、协商握手信息，每个 SECC 可以控制一个或多个充电桩，但每个充电桩只和一个 SECC 建立链接；EVCC 端则要能做到不需要司机参与就能发现并协商。

提示：无线充电里的“发现”不是让司机拿手机点列表，而是车和桩在后台完成识别与协商。

这个边界对排障很有用。有线场景下，插枪动作本身就是一个强提示；无线场景下，没有明显的“插入”事件，日志里可能很早就出现发现与协商消息。若还按有线思维等 plug-in 之后再抓包，就会觉得“怎么什么都没发生”。反过来说，看到无线发现消息很早出现，也不代表已经开始充电，它只是把对话的门敲开了。

2.4 反向送电与回溯：为什么协议要留后手

正向能量传输 FPT 是对电池充电，反向能量传输 RPT 则把电动车当成分布式能源，把电池里的电反馈给外部负载或电网。资料里给了一个很直观的区别：交流系统中双向转换器在 EV 内，进行电能双向切换；直流系统中这部分双向转换器位于中间方形区域，也就是电动车能源系统 EV Power System。这个位置差异会影响测试时观察哪一侧的功率变化，不能只看桩端读数就下结论。

回溯是 2019 年新增的需求，目的是增加多方在能源交换时的可信度与可靠性。打个比方，普通充电像一手交钱一手交电，回溯更像给每次能量交换留一张可查的凭据，事后能对上“谁在什么时候交换了多少”。这类需求在单向充电时存在感不强，一旦涉及反向送电、多方结算、计量回执，就会变得重要。资料把它单独列出来，说明测试时不能只盯实时消息，还要看回执和记录能不能闭环。

3. 一条消息怎样穿过七层：ISO15118 的通信分层与 EXI 压缩

3.1 OSI 第 3 到第 7 层：为什么只测上半截

ISO15118-2 在 OSI 网络分层中处于第 3 到第 7 层，数据链路层和物理层由 ISO15118-3 阐述。这个划分很像寄快递：物理层是卡车、道路和包裹实际怎么运，数据链路层是装卸和站点交接，第 3 到第 7 层则是面单怎么写、编号怎么排、签收怎么确认、包裹内容是什么格式。测试时如果只需要验证应用消息、证书、会话时序，可以用上位机模拟，不必每次都上真实充电硬件；但如果问题出在信号质量、链路建立、物理接口，那就不是第 3 到第 7 层能单独解释的。

资料里强调严格分层保证了各层的独立性。一个数据请求从 OSI 顶层逐级向下传输，可能经过分包，把 PDU 分成多个数据包，再通过点对点传输到另一端；另一端把同一 PDU 的数据组织起来，自底向上逐级传递，最后把请求送到顶层。顶层收到指令后产生 m+1 的响应数据，响应再走一遍类似路径。这个描述听起来抽象，落到排障上就是一句话：不要拿应用层的错误码去解释传输层的断链，也不要用传输层重连成功证明业务会话已经恢复。

3.2 半在线与在线：两种连接通信模式

ISO15118-2 定义了两种常用的连接通信模式：半在线和在线。半在线最容易被误解成“完全离线”。资料里的解释很关键：半在线可以理解为离线模式为主，但 SECC 这一端会每隔一段时间在线一下，获取一些即将过期的授权证书等。也就是说，它平时不靠后台实时参与充电流程，但并不是永远不联系外界。半在线状态下，SECC 与 SA 之间的通信仅用于一些信息交互，比如交换证书或者计量回执数据，这部分不是实时的，与实际的充电流程无关。

在线模式则不同，SECC 会立即将充电首选项发送到智能配电系统，也就是 Smart Grid 或 Demand Clearing House。通俗地说，半在线像你出门前把证件复印好带在身上，大部分时候不需要再回公司盖章；在线像每次办业务都要实时连上总部核验，总部还会根据当前电网情况给你一个建议。两者不是“高级”和“低级”的关系，而是后台参与时机不同。

资料还提到，在确定的情况下，标准强制要求 EVCC 与 SECC 之间建立 TLS 安全通道进行数据通信，其他一些情况下 TLS 是可选的。半在线状态下的即插即充 PnC 实例，基于 TLS 单向验证通道。这里不要把“半在线”和“无 TLS”画等号，也不要把“在线”和“一定双向证书认证”画等号。模式讲的是后台参与方式，TLS 讲的是传输安全通道，两者不是同一个维度。

3.3 应用层 V2GMessage 与表示层 EXI

应用层处理包含 SDP，也就是 SECC Discovery Protocol，以及应用消息的处理。资料以 SessionSetupReq 为例：这条消息属于应用层消息，内容很简单，只有 6 个字节长度的 EVCCID，用来定义 EV 可读的标识信息，包括以十六进制表示的六位 MAC 地址信息。别小看这 6 个字节，它决定了后续会话能不能把“这辆车”和“这次充电”关联起来。

表示层采用 XML 类型数据来描述 V2G 消息集，再按 W3C EXI 1.0 的定义执行。EXI 全称 Efficient XML Interchange，允许以二进制形式使用并传输基于 XML 的消息，提高处理速度、降低存储占用。资料里给了一个很抓眼球的数字：相对于同等信息的 XML 文档，EXI 格式可以将其大小压缩 100 倍。这个“100 倍”容易让人误以为 EXI 是某种万能压缩算法，其实它依赖预定义文件，也就是 schema，标识如何把规范数据转换成 EXI 语法。编码和解码必须使用同一套规范定义，否则就会出现“字都认识，拼起来不对”的情况。

下面这段 XML 只保留 SessionSetupReq 相关类型的核心结构，用来理解“6 字节限制”落在哪里：

<!-- 只保留 evccIDType 的核心限制，便于理解字段边界 --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:iso:15118:2:2013:MsgDataTypes"> <xs:simpleType name="evccIDType"> <xs:restriction base="xs:hexBinary"> <xs:maxLength value="6"/> </xs:restriction> </xs:simpleType> </xs:schema>

这段 schema 的逻辑很直接：evccIDType继承hexBinary，最大长度限制为 6。参数含义是，EVCCID 按十六进制二进制表达，长度上限 6 字节；超过这个边界的值不应该被当成合法 EVCCID 继续解析。XML 文档看起来冗长，转成 EXI 后同样内容可能只剩很短的二进制串。资料里展示过一条 SessionSetupResp 的 XML 与 EXI 对比，EXI 只有 28 字节，十分精简。这里的关键不是背字节数，而是理解“应用层看到的是结构化消息，表示层看到的是按 schema 编码后的二进制流”。

EXI 的应用层通信设置也有边界：命名空间采用urn:iso:15118:2:2013，代表按第二版协议规定的方法编解码；EXIOptions 使用默认 EXI 编码选项；EXI 头部按 ISO15118 需要填充，可选 EXI Cookie 不使用，Presence Bit 总为 0，消息里不需要添加 EXI Options 相关内容；不符合 EXI 头部定义的消息应被舍弃。通俗地说，EXI 不是“随便压一下再解”，而是双方拿着同一本字典，按同一套省略规则说话。字典版本不对，或者省略规则不一致，解出来的内容就会翻车。

3.4 V2G Transfer Protocol 与 TCP/UDP/TLS 的位置

会话层是 V2G Transfer Protocol，传输层列出 TCP、UDP、TLS。这里最容易被混为一谈：TCP 是可靠字节流，UDP 更轻量，TLS 是在传输通道上加安全隧道。V2G Transfer Protocol 基于 TCP，能够确保 EVCC 与 SECC 之间的可靠数据传输。注意“基于 TCP”说的是承载关系，不是“V2G Transfer Protocol 等于 TCP”。会话层还管一次交互怎么开始、怎么组织、怎么结束，TCP 只负责把字节送到对面。

UDP 出现在传输层列表里，不代表所有 V2G 业务消息都走 UDP。发现类交互和业务会话对可靠性的要求不同，具体哪条消息走哪种承载，要回到对应章节的定义，不能凭名字猜。TLS 也不是“认证”的同义词：它保护传输通道，业务身份还要看证书、签名和会话消息。把这三者分开看，日志里的现象会清楚很多：TCP 连不上是传输通道问题，TLS 握手失败是安全通道问题，TLS 通了但 SessionSetupRes 返回错误，才是业务会话问题。

4. 证书不是“附件”：ISO15118 的证书体系与签名安全

4.1 数字证书与证书责任链

数字证书包含电动汽车或充电站的身份信息和公钥信息，用来做身份验证和加密通信。通俗地说，证书像一张带公章的身份证：上面写着“我是谁”，还带着一把公钥；公章不是自己盖的，而是由上一级机构签的。证书责任链就是这张身份证背后的证明链，由证书颁发机构逐级签发，用来验证电动汽车或充电站的身份。验签时不是只看最后一张证书，而是沿着链往上走，直到一个双方都信任的根。

资料里把证书签名认证和签名计算方法单独列出来，说明它不是“配好证书就完事”。签名认证通常先把内容做哈希，再用私钥对哈希结果签名；验证方用公钥验签，确认内容没被改、签名确实来自持有私钥的一方。这里最容易犯的错是把“证书有效”当成“业务一定通过”。证书有效只说明身份材料在有效期内、链能走通；业务是否授权，还要看证书用途、消息里的账户标识、签名保护域是否覆盖了关键字段。

证书责任链的另一个作用是划清责任。车辆证书、充电站证书、后台系统证书各有签发者，合同证书又和用户账户、服务提供商相关。链上任何一环缺失，表现可能不是“证书错误”四个大字，而是某条消息验签失败、某个字段不被接受、或者会话走到一半超时。排障时先确认“缺的是哪一环”，比盲目替换整包证书更有效。

4.2 证书种类与证书关系

资料列出多种证书类型，包括电动汽车证书、充电站证书、backend 系统证书等，并强调证书之间的关系。对初学者来说，不用一开始背全所有证书名，先抓住三类问题：这张证书证明谁？由谁签发？在哪个消息里被验证？车辆证书证明车辆身份，充电站证书证明桩身份，后台系统证书服务后台角色；合同证书则更靠近用户与服务提供商之间的合同关系，常用于即插即充场景。

资料里还出现 ContractSignatureCertChain、ContractSignatureEncryptedPrivateKey、DHpublickey、eMAID 这些字段名。它们出现在证书更新或安装相关消息里，分别对应合同签名证书链、加密后的合同私钥、迪菲赫尔曼公钥和账户标识。看到“EncryptedPrivateKey”不要以为私钥会明文传，资料明确说 SA 会用短暂的会话 key 加密私钥再传给 EVCC，这个短暂 key 的传递使用短静态迪菲赫尔曼密匙协商协议。合同证书再由 SA 传递给 EVCC，XML 签名也使用这个合同证书。

4.3 XML 签名到底签了什么

摘要签名是 W3C 推荐的、用于满足 XML 形式 V2G 数据真实性要求的设计，消息加密方式采用椭圆曲线数字签名算法 ECDSA。资料特别说明，XML 签名并不是所有消息都做，仅针对 AuthorizationReq 以及 PnC 支持的方法实现。这个限制很重要：看到一条普通消息没有签名，不要立刻判定“安全缺失”；看到一条带签名的消息，也不要以为整条链路的每个字段都被保护。

一条 XML 形式的 V2G 消息里，需要加密的签名位于 Header 中，Header 包含 SessionID 和 Signature。Signature 里又有 SignatureInfo 与 SignatureValue，SignatureInfo 描述签名算法信息，SignatureValue 是签名主体。签名的生成普遍分两步：先收集签名数据体，再按固定算法对数据体签名。通俗地说，先划定“要盖章的那几页”，再拿私钥盖下去；如果保护域划错了，盖得再漂亮也可能漏掉关键内容。

这张表只用来建立“保护域”的概念，不要求背全字段。真正验签失败时，先看三件事：签名侧是谁、验证侧是谁、保护域有没有覆盖出错字段。比如授权请求失败，先查合同证书链和签名值；计量回执失败，先查回执内容有没有被中间环节改写；计费参数相关字段失败，先确认签名保护域是否只覆盖了特定业务字段。把这三问走完，比反复换证书更能定位问题。

4.4 OpenSSL 测试证书生成放在哪

资料附录 A 是 OpenSSL 测试证书生成。这个安排很实用：正文讲证书关系和签名规则，附录放测试证书怎么造。测试环境里，证书链、密钥用法、扩展项稍有偏差，表现就可能从“握手失败”变成“消息能发但验签不过”。下面这段命令只用于本地理解证书字段，不替代协议规定的证书模板和扩展项：

# 仅用于本地理解证书字段，真实测试证书需按项目模板补齐扩展项 openssl ecparam -name prime256v1 -genkey -noout -out test-vehicle-key.pem openssl req -new -key test-vehicle-key.pem -out test-vehicle.csr -subj "/CN=test-evcc/O=ExampleLab" openssl x509 -req -in test-vehicle.csr -signkey test-vehicle-key.pem -days 30 -out test-vehicle-cert.pem

第一行生成椭圆曲线私钥，prime256v1是曲线参数；第二行生成证书签名请求，-subj里的CN和O都是占位符，不能当成真实机构信息；第三行用同一把私钥自签一张有效期 30 天的测试证书。逻辑上这只是“自己给自己盖章”，适合看字段和跑通解析，不适合验证完整责任链。真实测试里，车辆证书、桩证书、合同证书的签发关系要按资料里的证书关系来搭，否则链验不过，后面消息签名再对也没用。

5. 易混区别：半在线、HLC、EXI 和证书链别再混着叫

5.1 半在线不是离线：它只是“偶尔回一次后台”

易混点：把半在线当成完全离线，看到 SECC 和 SA 有通信就觉得模式配错了。为什么混？因为“半在线”字面上像“一半离线”，而实际充电过程中大部分时间确实不靠后台实时参与，很容易让人忽略它仍会周期性同步。怎么区分？看 SECC 是否每隔一段时间在线获取即将过期的授权证书，看 SECC 与 SA 的交互是不是只做证书交换、计量回执这类信息交互，看它是否实时影响当前充电流程。半在线的关键不是“永不联网”，而是“后台不深度参与当前时序”。完全离线则连这种周期性同步都没有。排障时先看时间线：如果后台交互发生在充电前或充电后，别把它误判成充电中断的原因。

5.2 HLC 不是“高级充电线”：它指高级双边数字通信

易混点：把 HLC 理解成充电功率更高、线缆更高级，或者认为只要插上就能走 HLC。为什么混？因为 HLC 里的“High Level”听起来像“高级硬件”，实际上它指高级双边数字通信，重点在通信能力，不在电压电流。怎么区分？看双方是否都配备 HLC 设备，看消息里是否出现身份识别、支付、负载均衡、能源传输控制、增值服务这些应用层内容，看基础信号通信是否只覆盖车辆状态、流程启动和安全控制导引。只有 EV 和 EVSE 都具备 HLC 能力，才谈得上 HLC 信息通信；设备状态还分不支持、支持、必须。充电功率高不代表 HLC 一定启用，充电功率低也不代表只能走基础信号。

5.3 EXI 不是压缩包：它是 XML 的二进制编码规则

易混点：把 EXI 当成 zip、gzip 之类的通用压缩，认为解不开就先换解压工具。为什么混？因为 EXI 确实能把 XML 压得很小，资料里还给了“压缩 100 倍”这种直观数字，听起来像压缩算法。怎么区分？EXI 依赖预定义 schema，编码和解码要用同一套规范定义；它按urn:iso:15118:2:2013命名空间的规则处理，EXI 头部、EXIOptions、Presence Bit 都有协议约定。通用压缩包解出来还是原来的 XML 字节，EXI 解出来要按 schema 还原结构。遇到解码失败，先查 schema 版本、命名空间和 EXI 选项，不要先怀疑网络把二进制改了。翻车现场往往不是“压坏了”，而是两边字典不是同一版。

5.4 合同证书不是车辆证书：持有者和用途不同

易混点：看到“证书”两个字就认为都是同一套身份材料，验签失败时整包替换。为什么混？因为车辆证书、充电站证书、合同证书都参与安全链路，日志里又都可能出现证书链和签名值。怎么区分？看持有者和用途：车辆证书证明车辆身份，充电站证书证明桩身份，合同证书更靠近用户合同与 PnC 支付授权，常和 EMAID、ContractSignatureCertChain、加密私钥、DH 公钥一起出现。合同证书由 SA 侧相关方提供，EVCC 成功验证后存储；车辆证书不直接代表支付账户。排障时先问“这条消息的签名侧和验证侧是谁”，再问“这里需要证明身份还是证明合同关系”，别把两件事混成一件事。

5.5 会话不是 TCP 连接：SessionID 和连接状态要分开看

易混点：TCP 连接还在，就认为业务会话一定正常；或者 TCP 重连成功，就认为充电会话已经恢复。为什么混？因为两者都叫“连接”，日志里又常常相邻出现。怎么区分？V2G 会话以 SessionSetupReq 为起始，消息 Header 里有 SessionID；TCP 是传输层通道，TLS 是在通道上加的安全层。TCP 通、TLS 通，只说明路和隧道没问题；SessionSetupRes 返回非 OK，说明业务会话没建起来；会话建立后某条消息超时，可能是时序、证书或对端处理问题。看日志先分层：TCP/TLS 握手失败是一类，SessionSetup 失败是一类，会话中消息失败又是一类。把这三类混在一起，排障就会变成拔枪重插的循环。

6. 什么时候该翻这份资料：三个边界和一个排障习惯

这份《ISO15118 资料整理》最适合放在手边当索引，而不是从头到尾当小说读。它把背景架构、通信、证书与安全、会话交互四篇收在一起，遇到具体消息时按目录跳转，比在庞大协议里盲翻更省时间。适合用的场景很明确：你要理解 EVCC 与 SECC 的交互框架，要查半在线与在线的差别，要弄懂 V2GMessage 怎么经过 EXI 编码，要理清证书链和 XML 签名保护域，或者要设计应用层测试用例。这些都属于第 3 到第 7 层以及安全、会话范畴，资料里的表格和消息示例能直接当查表用。

不适合用的场景也要说清楚。电池内部 BMS 通信、电芯温度异常、物理层信号质量、数据链路层硬件故障，不该拿这份资料硬解释；支付清算的完整商业流程、生产证书签发制度，也不是这份整理稿的重点。它讲的是车与桩之间的通信协议，不是万用维修手册。下面这张表可以当快速判断：

举个具体例子：日志里 AuthorizationReq 的签名验证失败，最容易出现的反应是“证书坏了，换一套”。按这份资料的思路，先确认签名侧是 EVCC、验证侧是 SECC，再看合同证书链是否完整、加密私钥有没有正确传递、签名保护域是否覆盖了整个消息体。如果 TCP 和 TLS 都正常，SessionSetup 也过了，问题更可能落在证书链或签名数据本身，而不是传输通道。这个顺序能省掉很多无效重试。

血泪经验是，充电问题最怕一上来就猜。从那以后我每次拿到充电失败日志，都先强制走一遍“先分层、再会话、后证书”三问：TCP/TLS 通不通，SessionSetup 过没过，签名和证书链对不对。三问答完，再去看具体消息，踩坑次数会少很多。如果你准备系统过一遍，建议把这份整理资料放在手边，先读背景架构建立角色感，再按通信、证书、会话交互查表；希望帮到你。

本文还有配套的精品资源，点击获取