简介这份PDF为DIN TS 70121-2024英文原版技术规范聚焦电动汽车与直流充电站之间的数字通信面向充电桩研发、汽车电子及标准合规测试人员是理解CCS组合充电系统通信流程的关键参考资料。文件共1个PDF约5.5MB文字层可复制并带书签便于全文检索与章节跳转目前已有68人学习。内容完整覆盖应用层消息描述、握手协议、服务发现与服务选择、充电参数交换等核心环节清晰说明EVCC如何发起通信、SECC如何响应服务请求并下发最大输出能力也列举了版本协商、服务范围与服务类别确认、外部支付支持等细节。可用于对接ISO/IEC相关标准、设计充电控制逻辑或排查互操作性问题。该标准原文227页结构严谨对充电流程、数据格式与通信时序均有系统性表述适合作为工程实现与标准比对的案头资料。1. DIN TS 70121-2024到底是什么充电桩通信工程师的第一份“结论性文档”拿到一份标注着“DIN TS 70121-2024英文原版可复制带书签.pdf”的文件时做欧标直流充电桩的人多半会先问三个问题这跟早先的DIN SPEC 70121是什么关系、2024版到底改了什么、手头的代码和测试用例要不要跟着动。这份PDF是德国标准化协会DIN发布的直流充电数字通信技术规范英文原版文字层完整、书签结构可用意味着它可以被当作工程基准——条款能被检索、复制、写进缺陷单和测试脚本。它解决的是非车载直流充电桩与电动汽车之间充电控制通信的互操作问题适合正在做或准备做欧标直流桩的嵌入式开发、测试、预认证工程师把它作为案头第一份参考文档。2. 从DIN SPEC到DIN TS70121的版本脉络与协议栈拆解2.1 70121在充电通信标准版图里的位置直流充电的场景比交流复杂得多桩端和车端不仅要协商电压电流还要在充电过程中持续交换电池状态、目标电流、故障信息最后还要安全地终止充电。IEC 61851系列负责物理层和最基本的充电状态机State A到F但它不管“报文怎么写”。真正定义“车和桩用什么样的消息格式对话”的是ISO 15118系列以及本文标题里这个从德国标准体系走出来的DIN TS 70121。DIN SPEC 70121最初是2014年发布的当时CCSCombined Charging System阵营急着要一个能直接落地的直流通信规范于是基于ISO 15118早期内容快速出了一版。很多欧标直流桩的PLC通信栈早期是照着DIN SPEC 70121做的。到2024年这个文档以DIN TS编号重新出现标识“Technical Specification”文件组织方式也更接近正式标准的章节颗粒度。对工程师来说编号变化意味着不能继续拿旧PDF当唯一基准需要重新核对引用文件、消息定义和安全参数。常见的误解是拿它直接等价于ISO 15118。实际上70121和15118在消息集合、SLAC时序、部分字段定义上有差异欧洲市场很多桩企的验证矩阵里70121是独立于15118的一条测试线。它面向的是“直流充电控制”这一个明确场景不是全场景补集。2.2 通信协议栈从SLAC到V2GTP再到EXI消息DIN TS 70121描述的通信过程可以拆成五层看每一层对应一个独立的调试维度物理层CPControl Pilot导线上叠加PLC信号物理介质规范走HomePlug Green PHY而不是普通的Wi-Fi或以太网。SLACSignal Level Attenuation Characterization握手这是很多人第一次接触“电力线上网做充电”时最困惑的部分。车和桩通过CP线做信号衰减特征化确认对方是合法PLC对端然后建立以太网级别的链路。TCP/IP与TLS链路建立后上层走标准TCP/IPTCP端口通常是6。TLS用于加密和身份验证证书处理在这里完成。V2GTPV2G Transfer Protocol承载在TCP之上的传输协议头部固定8字节包括版本、保留字段和载荷长度。很多“握手成功但解析失败”的问题根源是V2GTP版本字段和载荷长度没对齐。EXI消息层V2G消息比如SessionSetupReq、ChargeParameterDiscoveryReq在发送前被序列化成EXI二进制流。EXI是XML的紧凑二进制编码schema版本变了以后新老设备互相解析就会翻车。我一般建议团队把调试分成两段先在下电状态用PLC抓包工具确认SLAC做完、TCP能ping通再进入TLS和EXI消息调试。不要在没确认物理链路的情况下直接看应用层那是把黑匣子越滚越大。2.3 为什么英文原版是工作基准很多团队习惯先找中文翻译或二手解读但这类标准文档我强烈建议以英文原版做基准。原因有三个。第一规范性措辞在英文里有明确对应shall表示强制要求should表示推荐做法may表示允许的选项。中文二手内容很容易把这三者混成一团“应”字测试用例的断言级别就会被带偏。第二EXI schema里的字段名本身就是英文定义的测试脚本、日志解析、缺陷单里如果引用的是中文翻译字段跟原版对不上返工成本极高。第三标准更新时变更清单是按英文条款路径发布的比如“9.2.3 ChargeParameterDiscovery”没有英文原版做锚点新旧版本对照就得靠猜。所以拿到这份PDF以后第一件事不是翻目录看热闹而是确认三件事文字层是否完整可复制、书签树是否覆盖到三级条款、引用的外部标准清单是否明确。后文会给出具体的检查方法。3. 2024版更新怎么定位新旧版本对比的三个抓手3.1 先核对引用文件清单最容易走回头路的地方处理这类标准更新我拿到手的第一动作不是读正文而是打开引用文件那一节把表格里引用的ISO/IEC编号版本号记下来。DIN TS 70121作为直流通信规范引用最多的是IEC 61851系列的充电物理层标准、ISO 15118系列的V2G消息模型以及安全相关的证书规范。如果引用的版本号变了比如从ISO 15118-2的某个版本换到更新的版本就意味着消息schema底层逻辑可能同步更新了你在旧版本上维护的EXI编解码选项大概率要动。具体做法是这样把旧版PDF和新版PDF的目录页都导出成文本用diff工具对照一下引用文件表格。不需要读完整份文档就能定位变化范围。pdftotext -layout DIN_SPEC_70121_old.pdf - | sed -n /Normative references/,/Terms and definitions/p refs_old.txt pdftotext -layout DIN_TS_70121_2024.pdf - | sed -n /Normative references/,/Terms and definitions/p refs_new.txt diff refs_old.txt refs_new.txt-layout参数让pdftotext保留原来的换行缩进表格结构更清晰sed截取“规范性引用”章节到“术语定义”章节之间的内容。diff输出里的每一行改动都对应一个需要跟踪的变更点。如果旧版是2014年的DIN SPEC新旧差异会更明显别跳过这一步。3.2 抓消息定义与EXI Schema字段级别对比第二个抓手在消息定义部分。直流充电的典型流程是会话建立Session Setup→ 充电参数发现Charge Parameter Discovery→ 充电控制Power Delivery→ 终止充电Session Stop。2024版更新如果动了任何一个消息里的字段比如新增一个“Target Voltage Limit”或者调整某个枚举值你的桩端代码就必须同步。但我不会建议你把整份schema背下来。更实用的做法是在新版PDF的书签树里找到“Message Definitions”或“EXI Schema”相关章节把新旧两版的字段列表提取出来做一个并排清单。字段角度上看三类变更新增字段旧设备发来的消息里没有需要默认值兜底、删除字段新版本不再使用继续发送可能被对端当非法消息、类型变更比如从int变成unsigned int解析规则直接受影响。这里有一个经验很多厂商在实现时偷懒直接用早期版本生成的EXI编解码库没有重新跑schema生成步骤。结果就是2024版新车型发来的EXI流在老桩上解析出乱码。这不是算法问题是“schema版本没跟着更新”的典型症状。3.3 安全参数表TLS版本与证书处理最容易被忽略第三个抓手在安全章节。TLS参数这一块进度项目中最容易跳过因为它在静态代码里不显眼但影响最大——车桩之间的TLS握手失败整个PLC通信直接断掉而且故障现象会伪装成“SLAC后无响应”或“TCP连接建立失败”。我一般会在新版PDF里搜“TLS”关键字把协议版本、cipher suite列表、证书链处理方式逐项摘出来跟旧版比对。尤其注意两点TLS最低版本是否上调比如从1.0/1.1升到1.2以上以及证书验证是否要求更严格的信任链。老桩如果TLS栈还停留在早期实现遇到新车型大概率直接握手失败而且桩端日志里只会显示“Socket Closed”让人以为是TCP层问题实则是TLS版本协商失败。把这三个抓手的结论汇成一张表格记录“章节路径、变更类型、影响范围、处理动作”再进入开发就不会漏。这张表我通常直接放到git仓库的docs目录下作为版本迁移的审计记录。4. 把PDF变成可用的规范库提取、书签与版本管理4.1 先证明PDF能当工作基准文字层、书签与页面完整性检查标题里写了“可复制带书签”但这八个字不能只看表面。可复制依赖PDF里有完整的文字层如果来源是扫描再OCR的公式、表格、特殊字符很容易错位带书签则是能否快速定位条款的关键。拿到文件后第一件事是做一次质量核验确认它真的能作为工程基准而不是只能翻页看。pdfinfo DIN_TS_70121-2024_en.pdf | grep -E Pages|Title|Producer pdftotext -f 1 -l 10 DIN_TS_70121-2024_en.pdf - | head -30pdfinfo里重点看Pages数量是否完整、Producer字段是否正常pdftotext的-f 1 -l 10表示只提取第1到第10页如果前10页能正常输出文本而不是空白说明文字层基本可靠。如果这段命令输出大量乱码或空行那这份PDF可能只是扫描件套了层文字层复制出来的内容会有隐藏字符不能直接用于测试脚本。书签检查可以进一步用pypdf看结构# verify_pdf.py —— 检查书签结构与文本层完整性 from pypdf import PdfReader reader PdfReader(DIN_TS_70121-2024_en.pdf) print(总页数:, len(reader.pages)) outlines reader.outline # 书签树嵌套列表 flat_count 0 def walk(items, depth0): global flat_count for item in items: if isinstance(item, list): walk(item, depth 1) else: flat_count 1 print( * depth str(item)) walk(outlines) print(书签总条目数:, flat_count)reader.outline返回的是嵌套的书签树元素可能是字符串单条书签也可能是子列表一个包含下级书签的节点。递归展开后能看到最深层级是否到条款号级别。如果书签只到章级别比如只有“5 Communication”而没有“5.3.2 ChargeParameterDiscoveryReq”定位精确条款时就得靠全文搜索效率差很多。这一步如果发现书签深度不够我的做法是用“全文搜索手动标记”补一个外部索引而不要急着退回旧版。4.2 按书签建立条款级索引从书签树到项目WikiPDF书签是导航工具但我一般不建议长期依赖PDF阅读器里点来点去。规范文档在项目周期里会被反复引用缺陷单、会议纪要和测试报告里都会出现条款路径。我的做法是把书签树导出来转成Markdown格式作为项目Wiki里“规范索引”页面的基础让团队不用打开PDF就能检索条款号。# export_outline.py —— 把书签树导出为Markdown目录 from pypdf import PdfReader reader PdfReader(DIN_TS_70121-2024_en.pdf) def walk(items, depth0): lines [] for item in items: if isinstance(item, list): lines.extend(walk(item, depth 1)) else: if depth 0: lines.append(f# {item}) else: prefix * depth lines.append(f{prefix}- {item}) return lines lines walk(reader.outline) with open(DIN_TS_70121_outline.md, w, encodingutf-8) as fp: fp.write(\n.join(lines)) print(导出完成共, len(lines), 行)导出的Markdown里一级书签对应章标题二级三级对应条款小节。把它提交到git仓库后团队成员查“充电参数发现消息在哪个章节”就不用再打开PDF。另一个好处是后续做测试用例映射时这本身就是一张可以直接扩展的清单。我一般还会把这份索引跟“变更记录表”放一起每一条书签对应一个章节路径变更记录表里记录“该章节在新版中的状态”要么是未变更、要么是已核对、要么是需修改。规范库的管理逻辑应该跟代码库一致——可追溯、可评审、可回滚。4.3 用外部注释维护差异记录不污染原文很多PDF阅读器支持内嵌注释但我个人的习惯是主用外部注释比如在规范库目录下建一个notes/文件夹每个章节一个Markdown文件记录“旧版要求、新版要求、影响分析、负责人”。原因很简单PDF内嵌注释时如果多人用不同阅读器编辑容易产生冲突而且注释内容不便于和测试用例、缺陷单做关联检索。一个典型的规范库目录结构大概是DIN_TS_70121_2024/ ├── original_pdf/ # 原始PDF只读 ├── outline/ # 书签导出与条款索引 │ └── DIN_TS_70121_outline.md ├── notes/ # 条款级差异记录 │ ├── 05_communication.md │ ├── 06_security.md │ └── 09_messages.md ├── test_mapping/ # 条款到测试用例的映射表 │ └── mapping.csv └── README.md # 版本来源、核对时间、变更摘要original_pdf/目录里的文件设定为只读权限需要引用原文时从这里的PDF复制避免团队里流传多个版本导致引用错乱。notes目录下的文件按章节号命名比如05_communication.md对应第5章通信相关内容。README.md里记录核对人和日期这看起来是小事但后期做合规审计时能省掉很多“你当时为什么这么写”的解释成本。注意如果阅读器支持“附加注释”或“高亮”而不修改原文字层也可以接受但保存时务必保留书签结构否则重新打开后章节定位会丢失。5. 规范落地避坑5个常见的解读与使用问题5.1 现象把DIN TS 70121当成ISO 15118的等价替代项目组拿到2024版PDF后最常犯的错是在测试用例里直接引用ISO 15118的字段名和流程定义理由是“这个规范本来就从15118来的”。结果新车型按DIN TS 70121实现两边字段名对不上测试直接失败。原因早期DIN SPEC 70121确实大量沿用了15118的早期内容但2024版作为独立的DIN TS重新组织后消息集合和安全要求有自己的条款路径不能镜像引用。解决所有测试用例的字段定义和流程依据一律以DIN TS 70121-2024的条款路径为基准。ISO 15118的内容只作为背景理解不作为断言来源。5.2 现象EXI Schema新旧混用导致参数解析乱码有同事反馈SLAC正常、TCP也通了但收到ChargeParameterDiscovery响应后解析出来的电压值是负数看起来像字节序问题。排查了半天最后发现编解码器用的是旧版schema生成的EXI选项新版本消息里新增的字段被错误解析进了原有字段。原因EXI编码不是自描述的解码端必须按同一份schema实例化解码选项。新旧schema混用时编码端用新字段解码端按旧字段表读数据错位是必然的。解决确认新版PDF里的schema版本号重新生成EXI编解码选项并在代码的配置里把schema版本号固化到日志中方便后续排查。5.3 现象SLAC计时参数没校准充电启动不稳定现场反馈某款桩在特定车型上偶尔要等10秒以上才进入充电流程重试几次才能成功。查日志发现SLAC过程重复了多轮对端的衰减特征迟迟没有确认。原因SLAC过程中有一系列时间参数比如等待对端响应的时间窗口、重试上限。2024版如果调整了这些参数的取值或默认值老设备按旧参数等待就可能导致时序余量不足。解决对照规范里SLAC相关章节的时间参数表逐项核对桩端配置修改后做重复连接测试重点看在弱信号场景下的建立时间是否稳定。5.4 现象TLS版本未更新老桩连不上新车型最隐蔽的一类问题。充电启动黑屏桩端日志只有“TCP连接被断开”没有TLS错误信息。最后抓包才发现TLS ClientHello里声明的版本和cipher suite不满足新车型要求被对方直接断开连接。原因TLS握手是加密通信的第一步失败后上层应用根本接收不到任何业务报文错误信息被掩盖在socket异常里。解决核对安全章节里TLS最低版本、cipher suite列表更新嵌入式TLS栈配置。改完后用抓包工具回放握手过程确认协商出的版本和加密套件落在规范允许范围内。5.5 现象把“应”和“宜”混为一谈预认证直接卡住测试工程师做符合性检查时把所有“should”宜条款都当成“shall”应来测导致测试用例数量翻倍还出现一堆“未通过”项后来发现这些项只是推荐项不构成符合性缺陷。原因标准文档里规范性与推荐性条款混杂英文原版里“shall”和“should”区分明确但二手资料和口头传递里被简化成一个“应”字。解决在条款索引里为每个章节打上标签——Normative强制性或Informative资料性/推荐测试用例只对Normative条款做通过/失败断言Informative内容作为参考记录。6. 把规范条款变成测试用例最后一步的映射技巧拿到DIN TS 70121-2024并完成条款索引后下一步是把条款翻译成测试用例。我常用的映射表长这样条款路径测试项通过标准备注通信流程 / SessionSetupReq发送合法SessionSetupReq等待响应收到SessionSetupRes且错误码为OK响应时间窗口按规范设定消息定义 / ChargeParameterDiscovery注入不同电池容量参数桩端按参数计算电压电流范围验证数值边界EXI编码 / Schema版本使用新版Schema生成的报文解析无异常字段一一对应新旧schema混用则失败安全参数 / TLS版本用最低允许TLS版本握手握手成功协商版本在允许范围内TSL配置错误时直接fail安全参数 / 证书链验证导入测试证书链桩端正确识别并建立安全通道证书过期场景单独留用例我的习惯是在测试脚本里把“条款路径”写成一个字段比如test_5_3_2_charge_parameter_discovery失败的时候直接反查索引表定位到对应章节而不是靠记忆回想“这是哪个模块的bug”。反向追溯的方法类似抓包看到某个字段值异常先翻条款索引找到该字段的定义章节再回来判断是桩端发送错误、车端解析错误还是两端schema版本不匹配。这样排查问题就不靠玄学而是靠一份可检索的路径清单。做测试执行时我还会把“条款路径”和“测试结果”合并回mapping.csv里每跑一轮就更新一次到预认证前这份表就是最直接的符合性证据。回到开头那个问题这份“DIN TS 70121-2024英文原版可复制带书签.pdf”值不值得投入时间去消化我的答案是值得的。2024版带来的引用文件、EXI schema和TLS参数变化如果没有一份可复制、可检索的原文做基准团队很容易在旧版实现上继续走。我现在的习惯是拿到新版本先做条款路径登记再谈改代码。希望帮到你。本文还有配套的精品资源点击获取 DIN TS 70121-2024中文解读：直流充电通信协议栈与EXI/SLAC要点
简介这份PDF为DIN TS 70121-2024英文原版技术规范聚焦电动汽车与直流充电站之间的数字通信面向充电桩研发、汽车电子及标准合规测试人员是理解CCS组合充电系统通信流程的关键参考资料。文件共1个PDF约5.5MB文字层可复制并带书签便于全文检索与章节跳转目前已有68人学习。内容完整覆盖应用层消息描述、握手协议、服务发现与服务选择、充电参数交换等核心环节清晰说明EVCC如何发起通信、SECC如何响应服务请求并下发最大输出能力也列举了版本协商、服务范围与服务类别确认、外部支付支持等细节。可用于对接ISO/IEC相关标准、设计充电控制逻辑或排查互操作性问题。该标准原文227页结构严谨对充电流程、数据格式与通信时序均有系统性表述适合作为工程实现与标准比对的案头资料。1. DIN TS 70121-2024到底是什么充电桩通信工程师的第一份“结论性文档”拿到一份标注着“DIN TS 70121-2024英文原版可复制带书签.pdf”的文件时做欧标直流充电桩的人多半会先问三个问题这跟早先的DIN SPEC 70121是什么关系、2024版到底改了什么、手头的代码和测试用例要不要跟着动。这份PDF是德国标准化协会DIN发布的直流充电数字通信技术规范英文原版文字层完整、书签结构可用意味着它可以被当作工程基准——条款能被检索、复制、写进缺陷单和测试脚本。它解决的是非车载直流充电桩与电动汽车之间充电控制通信的互操作问题适合正在做或准备做欧标直流桩的嵌入式开发、测试、预认证工程师把它作为案头第一份参考文档。2. 从DIN SPEC到DIN TS70121的版本脉络与协议栈拆解2.1 70121在充电通信标准版图里的位置直流充电的场景比交流复杂得多桩端和车端不仅要协商电压电流还要在充电过程中持续交换电池状态、目标电流、故障信息最后还要安全地终止充电。IEC 61851系列负责物理层和最基本的充电状态机State A到F但它不管“报文怎么写”。真正定义“车和桩用什么样的消息格式对话”的是ISO 15118系列以及本文标题里这个从德国标准体系走出来的DIN TS 70121。DIN SPEC 70121最初是2014年发布的当时CCSCombined Charging System阵营急着要一个能直接落地的直流通信规范于是基于ISO 15118早期内容快速出了一版。很多欧标直流桩的PLC通信栈早期是照着DIN SPEC 70121做的。到2024年这个文档以DIN TS编号重新出现标识“Technical Specification”文件组织方式也更接近正式标准的章节颗粒度。对工程师来说编号变化意味着不能继续拿旧PDF当唯一基准需要重新核对引用文件、消息定义和安全参数。常见的误解是拿它直接等价于ISO 15118。实际上70121和15118在消息集合、SLAC时序、部分字段定义上有差异欧洲市场很多桩企的验证矩阵里70121是独立于15118的一条测试线。它面向的是“直流充电控制”这一个明确场景不是全场景补集。2.2 通信协议栈从SLAC到V2GTP再到EXI消息DIN TS 70121描述的通信过程可以拆成五层看每一层对应一个独立的调试维度物理层CPControl Pilot导线上叠加PLC信号物理介质规范走HomePlug Green PHY而不是普通的Wi-Fi或以太网。SLACSignal Level Attenuation Characterization握手这是很多人第一次接触“电力线上网做充电”时最困惑的部分。车和桩通过CP线做信号衰减特征化确认对方是合法PLC对端然后建立以太网级别的链路。TCP/IP与TLS链路建立后上层走标准TCP/IPTCP端口通常是6。TLS用于加密和身份验证证书处理在这里完成。V2GTPV2G Transfer Protocol承载在TCP之上的传输协议头部固定8字节包括版本、保留字段和载荷长度。很多“握手成功但解析失败”的问题根源是V2GTP版本字段和载荷长度没对齐。EXI消息层V2G消息比如SessionSetupReq、ChargeParameterDiscoveryReq在发送前被序列化成EXI二进制流。EXI是XML的紧凑二进制编码schema版本变了以后新老设备互相解析就会翻车。我一般建议团队把调试分成两段先在下电状态用PLC抓包工具确认SLAC做完、TCP能ping通再进入TLS和EXI消息调试。不要在没确认物理链路的情况下直接看应用层那是把黑匣子越滚越大。2.3 为什么英文原版是工作基准很多团队习惯先找中文翻译或二手解读但这类标准文档我强烈建议以英文原版做基准。原因有三个。第一规范性措辞在英文里有明确对应shall表示强制要求should表示推荐做法may表示允许的选项。中文二手内容很容易把这三者混成一团“应”字测试用例的断言级别就会被带偏。第二EXI schema里的字段名本身就是英文定义的测试脚本、日志解析、缺陷单里如果引用的是中文翻译字段跟原版对不上返工成本极高。第三标准更新时变更清单是按英文条款路径发布的比如“9.2.3 ChargeParameterDiscovery”没有英文原版做锚点新旧版本对照就得靠猜。所以拿到这份PDF以后第一件事不是翻目录看热闹而是确认三件事文字层是否完整可复制、书签树是否覆盖到三级条款、引用的外部标准清单是否明确。后文会给出具体的检查方法。3. 2024版更新怎么定位新旧版本对比的三个抓手3.1 先核对引用文件清单最容易走回头路的地方处理这类标准更新我拿到手的第一动作不是读正文而是打开引用文件那一节把表格里引用的ISO/IEC编号版本号记下来。DIN TS 70121作为直流通信规范引用最多的是IEC 61851系列的充电物理层标准、ISO 15118系列的V2G消息模型以及安全相关的证书规范。如果引用的版本号变了比如从ISO 15118-2的某个版本换到更新的版本就意味着消息schema底层逻辑可能同步更新了你在旧版本上维护的EXI编解码选项大概率要动。具体做法是这样把旧版PDF和新版PDF的目录页都导出成文本用diff工具对照一下引用文件表格。不需要读完整份文档就能定位变化范围。pdftotext -layout DIN_SPEC_70121_old.pdf - | sed -n /Normative references/,/Terms and definitions/p refs_old.txt pdftotext -layout DIN_TS_70121_2024.pdf - | sed -n /Normative references/,/Terms and definitions/p refs_new.txt diff refs_old.txt refs_new.txt-layout参数让pdftotext保留原来的换行缩进表格结构更清晰sed截取“规范性引用”章节到“术语定义”章节之间的内容。diff输出里的每一行改动都对应一个需要跟踪的变更点。如果旧版是2014年的DIN SPEC新旧差异会更明显别跳过这一步。3.2 抓消息定义与EXI Schema字段级别对比第二个抓手在消息定义部分。直流充电的典型流程是会话建立Session Setup→ 充电参数发现Charge Parameter Discovery→ 充电控制Power Delivery→ 终止充电Session Stop。2024版更新如果动了任何一个消息里的字段比如新增一个“Target Voltage Limit”或者调整某个枚举值你的桩端代码就必须同步。但我不会建议你把整份schema背下来。更实用的做法是在新版PDF的书签树里找到“Message Definitions”或“EXI Schema”相关章节把新旧两版的字段列表提取出来做一个并排清单。字段角度上看三类变更新增字段旧设备发来的消息里没有需要默认值兜底、删除字段新版本不再使用继续发送可能被对端当非法消息、类型变更比如从int变成unsigned int解析规则直接受影响。这里有一个经验很多厂商在实现时偷懒直接用早期版本生成的EXI编解码库没有重新跑schema生成步骤。结果就是2024版新车型发来的EXI流在老桩上解析出乱码。这不是算法问题是“schema版本没跟着更新”的典型症状。3.3 安全参数表TLS版本与证书处理最容易被忽略第三个抓手在安全章节。TLS参数这一块进度项目中最容易跳过因为它在静态代码里不显眼但影响最大——车桩之间的TLS握手失败整个PLC通信直接断掉而且故障现象会伪装成“SLAC后无响应”或“TCP连接建立失败”。我一般会在新版PDF里搜“TLS”关键字把协议版本、cipher suite列表、证书链处理方式逐项摘出来跟旧版比对。尤其注意两点TLS最低版本是否上调比如从1.0/1.1升到1.2以上以及证书验证是否要求更严格的信任链。老桩如果TLS栈还停留在早期实现遇到新车型大概率直接握手失败而且桩端日志里只会显示“Socket Closed”让人以为是TCP层问题实则是TLS版本协商失败。把这三个抓手的结论汇成一张表格记录“章节路径、变更类型、影响范围、处理动作”再进入开发就不会漏。这张表我通常直接放到git仓库的docs目录下作为版本迁移的审计记录。4. 把PDF变成可用的规范库提取、书签与版本管理4.1 先证明PDF能当工作基准文字层、书签与页面完整性检查标题里写了“可复制带书签”但这八个字不能只看表面。可复制依赖PDF里有完整的文字层如果来源是扫描再OCR的公式、表格、特殊字符很容易错位带书签则是能否快速定位条款的关键。拿到文件后第一件事是做一次质量核验确认它真的能作为工程基准而不是只能翻页看。pdfinfo DIN_TS_70121-2024_en.pdf | grep -E Pages|Title|Producer pdftotext -f 1 -l 10 DIN_TS_70121-2024_en.pdf - | head -30pdfinfo里重点看Pages数量是否完整、Producer字段是否正常pdftotext的-f 1 -l 10表示只提取第1到第10页如果前10页能正常输出文本而不是空白说明文字层基本可靠。如果这段命令输出大量乱码或空行那这份PDF可能只是扫描件套了层文字层复制出来的内容会有隐藏字符不能直接用于测试脚本。书签检查可以进一步用pypdf看结构# verify_pdf.py —— 检查书签结构与文本层完整性 from pypdf import PdfReader reader PdfReader(DIN_TS_70121-2024_en.pdf) print(总页数:, len(reader.pages)) outlines reader.outline # 书签树嵌套列表 flat_count 0 def walk(items, depth0): global flat_count for item in items: if isinstance(item, list): walk(item, depth 1) else: flat_count 1 print( * depth str(item)) walk(outlines) print(书签总条目数:, flat_count)reader.outline返回的是嵌套的书签树元素可能是字符串单条书签也可能是子列表一个包含下级书签的节点。递归展开后能看到最深层级是否到条款号级别。如果书签只到章级别比如只有“5 Communication”而没有“5.3.2 ChargeParameterDiscoveryReq”定位精确条款时就得靠全文搜索效率差很多。这一步如果发现书签深度不够我的做法是用“全文搜索手动标记”补一个外部索引而不要急着退回旧版。4.2 按书签建立条款级索引从书签树到项目WikiPDF书签是导航工具但我一般不建议长期依赖PDF阅读器里点来点去。规范文档在项目周期里会被反复引用缺陷单、会议纪要和测试报告里都会出现条款路径。我的做法是把书签树导出来转成Markdown格式作为项目Wiki里“规范索引”页面的基础让团队不用打开PDF就能检索条款号。# export_outline.py —— 把书签树导出为Markdown目录 from pypdf import PdfReader reader PdfReader(DIN_TS_70121-2024_en.pdf) def walk(items, depth0): lines [] for item in items: if isinstance(item, list): lines.extend(walk(item, depth 1)) else: if depth 0: lines.append(f# {item}) else: prefix * depth lines.append(f{prefix}- {item}) return lines lines walk(reader.outline) with open(DIN_TS_70121_outline.md, w, encodingutf-8) as fp: fp.write(\n.join(lines)) print(导出完成共, len(lines), 行)导出的Markdown里一级书签对应章标题二级三级对应条款小节。把它提交到git仓库后团队成员查“充电参数发现消息在哪个章节”就不用再打开PDF。另一个好处是后续做测试用例映射时这本身就是一张可以直接扩展的清单。我一般还会把这份索引跟“变更记录表”放一起每一条书签对应一个章节路径变更记录表里记录“该章节在新版中的状态”要么是未变更、要么是已核对、要么是需修改。规范库的管理逻辑应该跟代码库一致——可追溯、可评审、可回滚。4.3 用外部注释维护差异记录不污染原文很多PDF阅读器支持内嵌注释但我个人的习惯是主用外部注释比如在规范库目录下建一个notes/文件夹每个章节一个Markdown文件记录“旧版要求、新版要求、影响分析、负责人”。原因很简单PDF内嵌注释时如果多人用不同阅读器编辑容易产生冲突而且注释内容不便于和测试用例、缺陷单做关联检索。一个典型的规范库目录结构大概是DIN_TS_70121_2024/ ├── original_pdf/ # 原始PDF只读 ├── outline/ # 书签导出与条款索引 │ └── DIN_TS_70121_outline.md ├── notes/ # 条款级差异记录 │ ├── 05_communication.md │ ├── 06_security.md │ └── 09_messages.md ├── test_mapping/ # 条款到测试用例的映射表 │ └── mapping.csv └── README.md # 版本来源、核对时间、变更摘要original_pdf/目录里的文件设定为只读权限需要引用原文时从这里的PDF复制避免团队里流传多个版本导致引用错乱。notes目录下的文件按章节号命名比如05_communication.md对应第5章通信相关内容。README.md里记录核对人和日期这看起来是小事但后期做合规审计时能省掉很多“你当时为什么这么写”的解释成本。注意如果阅读器支持“附加注释”或“高亮”而不修改原文字层也可以接受但保存时务必保留书签结构否则重新打开后章节定位会丢失。5. 规范落地避坑5个常见的解读与使用问题5.1 现象把DIN TS 70121当成ISO 15118的等价替代项目组拿到2024版PDF后最常犯的错是在测试用例里直接引用ISO 15118的字段名和流程定义理由是“这个规范本来就从15118来的”。结果新车型按DIN TS 70121实现两边字段名对不上测试直接失败。原因早期DIN SPEC 70121确实大量沿用了15118的早期内容但2024版作为独立的DIN TS重新组织后消息集合和安全要求有自己的条款路径不能镜像引用。解决所有测试用例的字段定义和流程依据一律以DIN TS 70121-2024的条款路径为基准。ISO 15118的内容只作为背景理解不作为断言来源。5.2 现象EXI Schema新旧混用导致参数解析乱码有同事反馈SLAC正常、TCP也通了但收到ChargeParameterDiscovery响应后解析出来的电压值是负数看起来像字节序问题。排查了半天最后发现编解码器用的是旧版schema生成的EXI选项新版本消息里新增的字段被错误解析进了原有字段。原因EXI编码不是自描述的解码端必须按同一份schema实例化解码选项。新旧schema混用时编码端用新字段解码端按旧字段表读数据错位是必然的。解决确认新版PDF里的schema版本号重新生成EXI编解码选项并在代码的配置里把schema版本号固化到日志中方便后续排查。5.3 现象SLAC计时参数没校准充电启动不稳定现场反馈某款桩在特定车型上偶尔要等10秒以上才进入充电流程重试几次才能成功。查日志发现SLAC过程重复了多轮对端的衰减特征迟迟没有确认。原因SLAC过程中有一系列时间参数比如等待对端响应的时间窗口、重试上限。2024版如果调整了这些参数的取值或默认值老设备按旧参数等待就可能导致时序余量不足。解决对照规范里SLAC相关章节的时间参数表逐项核对桩端配置修改后做重复连接测试重点看在弱信号场景下的建立时间是否稳定。5.4 现象TLS版本未更新老桩连不上新车型最隐蔽的一类问题。充电启动黑屏桩端日志只有“TCP连接被断开”没有TLS错误信息。最后抓包才发现TLS ClientHello里声明的版本和cipher suite不满足新车型要求被对方直接断开连接。原因TLS握手是加密通信的第一步失败后上层应用根本接收不到任何业务报文错误信息被掩盖在socket异常里。解决核对安全章节里TLS最低版本、cipher suite列表更新嵌入式TLS栈配置。改完后用抓包工具回放握手过程确认协商出的版本和加密套件落在规范允许范围内。5.5 现象把“应”和“宜”混为一谈预认证直接卡住测试工程师做符合性检查时把所有“should”宜条款都当成“shall”应来测导致测试用例数量翻倍还出现一堆“未通过”项后来发现这些项只是推荐项不构成符合性缺陷。原因标准文档里规范性与推荐性条款混杂英文原版里“shall”和“should”区分明确但二手资料和口头传递里被简化成一个“应”字。解决在条款索引里为每个章节打上标签——Normative强制性或Informative资料性/推荐测试用例只对Normative条款做通过/失败断言Informative内容作为参考记录。6. 把规范条款变成测试用例最后一步的映射技巧拿到DIN TS 70121-2024并完成条款索引后下一步是把条款翻译成测试用例。我常用的映射表长这样条款路径测试项通过标准备注通信流程 / SessionSetupReq发送合法SessionSetupReq等待响应收到SessionSetupRes且错误码为OK响应时间窗口按规范设定消息定义 / ChargeParameterDiscovery注入不同电池容量参数桩端按参数计算电压电流范围验证数值边界EXI编码 / Schema版本使用新版Schema生成的报文解析无异常字段一一对应新旧schema混用则失败安全参数 / TLS版本用最低允许TLS版本握手握手成功协商版本在允许范围内TSL配置错误时直接fail安全参数 / 证书链验证导入测试证书链桩端正确识别并建立安全通道证书过期场景单独留用例我的习惯是在测试脚本里把“条款路径”写成一个字段比如test_5_3_2_charge_parameter_discovery失败的时候直接反查索引表定位到对应章节而不是靠记忆回想“这是哪个模块的bug”。反向追溯的方法类似抓包看到某个字段值异常先翻条款索引找到该字段的定义章节再回来判断是桩端发送错误、车端解析错误还是两端schema版本不匹配。这样排查问题就不靠玄学而是靠一份可检索的路径清单。做测试执行时我还会把“条款路径”和“测试结果”合并回mapping.csv里每跑一轮就更新一次到预认证前这份表就是最直接的符合性证据。回到开头那个问题这份“DIN TS 70121-2024英文原版可复制带书签.pdf”值不值得投入时间去消化我的答案是值得的。2024版带来的引用文件、EXI schema和TLS参数变化如果没有一份可复制、可检索的原文做基准团队很容易在旧版实现上继续走。我现在的习惯是拿到新版本先做条款路径登记再谈改代码。希望帮到你。本文还有配套的精品资源点击获取