簡介這份PDF為DIN TS 70121-2024英文原版技術(shù)規(guī)范聚焦電動汽車與直流充電站之間的數(shù)字通信面向充電樁研發(fā)、汽車電子及標(biāo)準(zhǔn)合規(guī)測試人員是理解CCS組合充電系統(tǒng)通信流程的關(guān)鍵參考資料。文件共1個PDF約5.5MB文字層可復(fù)制并帶書簽便于全文檢索與章節(jié)跳轉(zhuǎn)目前已有68人學(xué)習(xí)。內(nèi)容完整覆蓋應(yīng)用層消息描述、握手協(xié)議、服務(wù)發(fā)現(xiàn)與服務(wù)選擇、充電參數(shù)交換等核心環(huán)節(jié)清晰說明EVCC如何發(fā)起通信、SECC如何響應(yīng)服務(wù)請求并下發(fā)最大輸出能力也列舉了版本協(xié)商、服務(wù)范圍與服務(wù)類別確認(rèn)、外部支付支持等細(xì)節(jié)。可用于對接ISO/IEC相關(guān)標(biāo)準(zhǔn)、設(shè)計(jì)充電控制邏輯或排查互操作性問題。該標(biāo)準(zhǔn)原文227頁結(jié)構(gòu)嚴(yán)謹(jǐn)對充電流程、數(shù)據(jù)格式與通信時(shí)序均有系統(tǒng)性表述適合作為工程實(shí)現(xiàn)與標(biāo)準(zhǔn)比對的案頭資料。1. DIN TS 70121-2024到底是什么充電樁通信工程師的第一份“結(jié)論性文檔”拿到一份標(biāo)注著“DIN TS 70121-2024英文原版可復(fù)制帶書簽.pdf”的文件時(shí)做歐標(biāo)直流充電樁的人多半會先問三個問題這跟早先的DIN SPEC 70121是什么關(guān)系、2024版到底改了什么、手頭的代碼和測試用例要不要跟著動。這份PDF是德國標(biāo)準(zhǔn)化協(xié)會DIN發(fā)布的直流充電數(shù)字通信技術(shù)規(guī)范英文原版文字層完整、書簽結(jié)構(gòu)可用意味著它可以被當(dāng)作工程基準(zhǔn)——條款能被檢索、復(fù)制、寫進(jìn)缺陷單和測試腳本。它解決的是非車載直流充電樁與電動汽車之間充電控制通信的互操作問題適合正在做或準(zhǔn)備做歐標(biāo)直流樁的嵌入式開發(fā)、測試、預(yù)認(rèn)證工程師把它作為案頭第一份參考文檔。2. 從DIN SPEC到DIN TS70121的版本脈絡(luò)與協(xié)議棧拆解2.1 70121在充電通信標(biāo)準(zhǔn)版圖里的位置直流充電的場景比交流復(fù)雜得多樁端和車端不僅要協(xié)商電壓電流還要在充電過程中持續(xù)交換電池狀態(tài)、目標(biāo)電流、故障信息最后還要安全地終止充電。IEC 61851系列負(fù)責(zé)物理層和最基本的充電狀態(tài)機(jī)State A到F但它不管“報(bào)文怎么寫”。真正定義“車和樁用什么樣的消息格式對話”的是ISO 15118系列以及本文標(biāo)題里這個從德國標(biāo)準(zhǔn)體系走出來的DIN TS 70121。DIN SPEC 70121最初是2014年發(fā)布的當(dāng)時(shí)CCSCombined Charging System陣營急著要一個能直接落地的直流通信規(guī)范于是基于ISO 15118早期內(nèi)容快速出了一版。很多歐標(biāo)直流樁的PLC通信棧早期是照著DIN SPEC 70121做的。到2024年這個文檔以DIN TS編號重新出現(xiàn)標(biāo)識“Technical Specification”文件組織方式也更接近正式標(biāo)準(zhǔn)的章節(jié)顆粒度。對工程師來說編號變化意味著不能繼續(xù)拿舊PDF當(dāng)唯一基準(zhǔn)需要重新核對引用文件、消息定義和安全參數(shù)。常見的誤解是拿它直接等價(jià)于ISO 15118。實(shí)際上70121和15118在消息集合、SLAC時(shí)序、部分字段定義上有差異歐洲市場很多樁企的驗(yàn)證矩陣?yán)?0121是獨(dú)立于15118的一條測試線。它面向的是“直流充電控制”這一個明確場景不是全場景補(bǔ)集。2.2 通信協(xié)議棧從SLAC到V2GTP再到EXI消息DIN TS 70121描述的通信過程可以拆成五層看每一層對應(yīng)一個獨(dú)立的調(diào)試維度物理層CPControl Pilot導(dǎo)線上疊加PLC信號物理介質(zhì)規(guī)范走HomePlug Green PHY而不是普通的Wi-Fi或以太網(wǎng)。SLACSignal Level Attenuation Characterization握手這是很多人第一次接觸“電力線上網(wǎng)做充電”時(shí)最困惑的部分。車和樁通過CP線做信號衰減特征化確認(rèn)對方是合法PLC對端然后建立以太網(wǎng)級別的鏈路。TCP/IP與TLS鏈路建立后上層走標(biāo)準(zhǔn)TCP/IPTCP端口通常是6。TLS用于加密和身份驗(yàn)證證書處理在這里完成。V2GTPV2G Transfer Protocol承載在TCP之上的傳輸協(xié)議頭部固定8字節(jié)包括版本、保留字段和載荷長度。很多“握手成功但解析失敗”的問題根源是V2GTP版本字段和載荷長度沒對齊。EXI消息層V2G消息比如SessionSetupReq、ChargeParameterDiscoveryReq在發(fā)送前被序列化成EXI二進(jìn)制流。EXI是XML的緊湊二進(jìn)制編碼schema版本變了以后新老設(shè)備互相解析就會翻車。我一般建議團(tuán)隊(duì)把調(diào)試分成兩段先在下電狀態(tài)用PLC抓包工具確認(rèn)SLAC做完、TCP能ping通再進(jìn)入TLS和EXI消息調(diào)試。不要在沒確認(rèn)物理鏈路的情況下直接看應(yīng)用層那是把黑匣子越滾越大。2.3 為什么英文原版是工作基準(zhǔn)很多團(tuán)隊(duì)習(xí)慣先找中文翻譯或二手解讀但這類標(biāo)準(zhǔn)文檔我強(qiáng)烈建議以英文原版做基準(zhǔn)。原因有三個。第一規(guī)范性措辭在英文里有明確對應(yīng)shall表示強(qiáng)制要求should表示推薦做法may表示允許的選項(xiàng)。中文二手內(nèi)容很容易把這三者混成一團(tuán)“應(yīng)”字測試用例的斷言級別就會被帶偏。第二EXI schema里的字段名本身就是英文定義的測試腳本、日志解析、缺陷單里如果引用的是中文翻譯字段跟原版對不上返工成本極高。第三標(biāo)準(zhǔn)更新時(shí)變更清單是按英文條款路徑發(fā)布的比如“9.2.3 ChargeParameterDiscovery”沒有英文原版做錨點(diǎn)新舊版本對照就得靠猜。所以拿到這份PDF以后第一件事不是翻目錄看熱鬧而是確認(rèn)三件事文字層是否完整可復(fù)制、書簽樹是否覆蓋到三級條款、引用的外部標(biāo)準(zhǔn)清單是否明確。后文會給出具體的檢查方法。3. 2024版更新怎么定位新舊版本對比的三個抓手3.1 先核對引用文件清單最容易走回頭路的地方處理這類標(biāo)準(zhǔn)更新我拿到手的第一動作不是讀正文而是打開引用文件那一節(jié)把表格里引用的ISO/IEC編號版本號記下來。DIN TS 70121作為直流通信規(guī)范引用最多的是IEC 61851系列的充電物理層標(biāo)準(zhǔn)、ISO 15118系列的V2G消息模型以及安全相關(guān)的證書規(guī)范。如果引用的版本號變了比如從ISO 15118-2的某個版本換到更新的版本就意味著消息schema底層邏輯可能同步更新了你在舊版本上維護(hù)的EXI編解碼選項(xiàng)大概率要動。具體做法是這樣把舊版PDF和新版PDF的目錄頁都導(dǎo)出成文本用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參數(shù)讓pdftotext保留原來的換行縮進(jìn)表格結(jié)構(gòu)更清晰sed截取“規(guī)范性引用”章節(jié)到“術(shù)語定義”章節(jié)之間的內(nèi)容。diff輸出里的每一行改動都對應(yīng)一個需要跟蹤的變更點(diǎn)。如果舊版是2014年的DIN SPEC新舊差異會更明顯別跳過這一步。3.2 抓消息定義與EXI Schema字段級別對比第二個抓手在消息定義部分。直流充電的典型流程是會話建立Session Setup→ 充電參數(shù)發(fā)現(xiàn)Charge Parameter Discovery→ 充電控制Power Delivery→ 終止充電Session Stop。2024版更新如果動了任何一個消息里的字段比如新增一個“Target Voltage Limit”或者調(diào)整某個枚舉值你的樁端代碼就必須同步。但我不會建議你把整份schema背下來。更實(shí)用的做法是在新版PDF的書簽樹里找到“Message Definitions”或“EXI Schema”相關(guān)章節(jié)把新舊兩版的字段列表提取出來做一個并排清單。字段角度上看三類變更新增字段舊設(shè)備發(fā)來的消息里沒有需要默認(rèn)值兜底、刪除字段新版本不再使用繼續(xù)發(fā)送可能被對端當(dāng)非法消息、類型變更比如從int變成unsigned int解析規(guī)則直接受影響。這里有一個經(jīng)驗(yàn)很多廠商在實(shí)現(xiàn)時(shí)偷懶直接用早期版本生成的EXI編解碼庫沒有重新跑schema生成步驟。結(jié)果就是2024版新車型發(fā)來的EXI流在老樁上解析出亂碼。這不是算法問題是“schema版本沒跟著更新”的典型癥狀。3.3 安全參數(shù)表TLS版本與證書處理最容易被忽略第三個抓手在安全章節(jié)。TLS參數(shù)這一塊進(jìn)度項(xiàng)目中最容易跳過因?yàn)樗陟o態(tài)代碼里不顯眼但影響最大——車樁之間的TLS握手失敗整個PLC通信直接斷掉而且故障現(xiàn)象會偽裝成“SLAC后無響應(yīng)”或“TCP連接建立失敗”。我一般會在新版PDF里搜“TLS”關(guān)鍵字把協(xié)議版本、cipher suite列表、證書鏈處理方式逐項(xiàng)摘出來跟舊版比對。尤其注意兩點(diǎn)TLS最低版本是否上調(diào)比如從1.0/1.1升到1.2以上以及證書驗(yàn)證是否要求更嚴(yán)格的信任鏈。老樁如果TLS棧還停留在早期實(shí)現(xiàn)遇到新車型大概率直接握手失敗而且樁端日志里只會顯示“Socket Closed”讓人以為是TCP層問題實(shí)則是TLS版本協(xié)商失敗。把這三個抓手的結(jié)論匯成一張表格記錄“章節(jié)路徑、變更類型、影響范圍、處理動作”再進(jìn)入開發(fā)就不會漏。這張表我通常直接放到git倉庫的docs目錄下作為版本遷移的審計(jì)記錄。4. 把PDF變成可用的規(guī)范庫提取、書簽與版本管理4.1 先證明PDF能當(dāng)工作基準(zhǔn)文字層、書簽與頁面完整性檢查標(biāo)題里寫了“可復(fù)制帶書簽”但這八個字不能只看表面?？蓮?fù)制依賴PDF里有完整的文字層如果來源是掃描再OCR的公式、表格、特殊字符很容易錯位帶書簽則是能否快速定位條款的關(guān)鍵。拿到文件后第一件事是做一次質(zhì)量核驗(yàn)確認(rèn)它真的能作為工程基準(zhǔn)而不是只能翻頁看。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里重點(diǎn)看Pages數(shù)量是否完整、Producer字段是否正常pdftotext的-f 1 -l 10表示只提取第1到第10頁如果前10頁能正常輸出文本而不是空白說明文字層基本可靠。如果這段命令輸出大量亂碼或空行那這份PDF可能只是掃描件套了層文字層復(fù)制出來的內(nèi)容會有隱藏字符不能直接用于測試腳本。書簽檢查可以進(jìn)一步用pypdf看結(jié)構(gòu)# verify_pdf.py —— 檢查書簽結(jié)構(gòu)與文本層完整性 from pypdf import PdfReader reader PdfReader(DIN_TS_70121-2024_en.pdf) print(總頁數(shù):, 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(書簽總條目數(shù):, flat_count)reader.outline返回的是嵌套的書簽樹元素可能是字符串單條書簽也可能是子列表一個包含下級書簽的節(jié)點(diǎn)。遞歸展開后能看到最深層級是否到條款號級別。如果書簽只到章級別比如只有“5 Communication”而沒有“5.3.2 ChargeParameterDiscoveryReq”定位精確條款時(shí)就得靠全文搜索效率差很多。這一步如果發(fā)現(xiàn)書簽深度不夠我的做法是用“全文搜索手動標(biāo)記”補(bǔ)一個外部索引而不要急著退回舊版。4.2 按書簽建立條款級索引從書簽樹到項(xiàng)目WikiPDF書簽是導(dǎo)航工具但我一般不建議長期依賴PDF閱讀器里點(diǎn)來點(diǎn)去。規(guī)范文檔在項(xiàng)目周期里會被反復(fù)引用缺陷單、會議紀(jì)要和測試報(bào)告里都會出現(xiàn)條款路徑。我的做法是把書簽樹導(dǎo)出來轉(zhuǎn)成Markdown格式作為項(xiàng)目Wiki里“規(guī)范索引”頁面的基礎(chǔ)讓團(tuán)隊(duì)不用打開PDF就能檢索條款號。# export_outline.py —— 把書簽樹導(dǎo)出為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(導(dǎo)出完成共, len(lines), 行)導(dǎo)出的Markdown里一級書簽對應(yīng)章標(biāo)題二級三級對應(yīng)條款小節(jié)。把它提交到git倉庫后團(tuán)隊(duì)成員查“充電參數(shù)發(fā)現(xiàn)消息在哪個章節(jié)”就不用再打開PDF。另一個好處是后續(xù)做測試用例映射時(shí)這本身就是一張可以直接擴(kuò)展的清單。我一般還會把這份索引跟“變更記錄表”放一起每一條書簽對應(yīng)一個章節(jié)路徑變更記錄表里記錄“該章節(jié)在新版中的狀態(tài)”要么是未變更、要么是已核對、要么是需修改。規(guī)范庫的管理邏輯應(yīng)該跟代碼庫一致——可追溯、可評審、可回滾。4.3 用外部注釋維護(hù)差異記錄不污染原文很多PDF閱讀器支持內(nèi)嵌注釋但我個人的習(xí)慣是主用外部注釋比如在規(guī)范庫目錄下建一個notes/文件夾每個章節(jié)一個Markdown文件記錄“舊版要求、新版要求、影響分析、負(fù)責(zé)人”。原因很簡單PDF內(nèi)嵌注釋時(shí)如果多人用不同閱讀器編輯容易產(chǎn)生沖突而且注釋內(nèi)容不便于和測試用例、缺陷單做關(guān)聯(lián)檢索。一個典型的規(guī)范庫目錄結(jié)構(gòu)大概是DIN_TS_70121_2024/ ├── original_pdf/ # 原始PDF只讀 ├── outline/ # 書簽導(dǎo)出與條款索引 │ └── DIN_TS_70121_outline.md ├── notes/ # 條款級差異記錄 │ ├── 05_communication.md │ ├── 06_security.md │ └── 09_messages.md ├── test_mapping/ # 條款到測試用例的映射表 │ └── mapping.csv └── README.md # 版本來源、核對時(shí)間、變更摘要original_pdf/目錄里的文件設(shè)定為只讀權(quán)限需要引用原文時(shí)從這里的PDF復(fù)制避免團(tuán)隊(duì)里流傳多個版本導(dǎo)致引用錯亂。notes目錄下的文件按章節(jié)號命名比如05_communication.md對應(yīng)第5章通信相關(guān)內(nèi)容。README.md里記錄核對人和日期這看起來是小事但后期做合規(guī)審計(jì)時(shí)能省掉很多“你當(dāng)時(shí)為什么這么寫”的解釋成本。注意如果閱讀器支持“附加注釋”或“高亮”而不修改原文字層也可以接受但保存時(shí)務(wù)必保留書簽結(jié)構(gòu)否則重新打開后章節(jié)定位會丟失。5. 規(guī)范落地避坑5個常見的解讀與使用問題5.1 現(xiàn)象把DIN TS 70121當(dāng)成ISO 15118的等價(jià)替代項(xiàng)目組拿到2024版PDF后最常犯的錯是在測試用例里直接引用ISO 15118的字段名和流程定義理由是“這個規(guī)范本來就從15118來的”。結(jié)果新車型按DIN TS 70121實(shí)現(xiàn)兩邊字段名對不上測試直接失敗。原因早期DIN SPEC 70121確實(shí)大量沿用了15118的早期內(nèi)容但2024版作為獨(dú)立的DIN TS重新組織后消息集合和安全要求有自己的條款路徑不能鏡像引用。解決所有測試用例的字段定義和流程依據(jù)一律以DIN TS 70121-2024的條款路徑為基準(zhǔn)。ISO 15118的內(nèi)容只作為背景理解不作為斷言來源。5.2 現(xiàn)象EXI Schema新舊混用導(dǎo)致參數(shù)解析亂碼有同事反饋SLAC正常、TCP也通了但收到ChargeParameterDiscovery響應(yīng)后解析出來的電壓值是負(fù)數(shù)看起來像字節(jié)序問題。排查了半天最后發(fā)現(xiàn)編解碼器用的是舊版schema生成的EXI選項(xiàng)新版本消息里新增的字段被錯誤解析進(jìn)了原有字段。原因EXI編碼不是自描述的解碼端必須按同一份schema實(shí)例化解碼選項(xiàng)。新舊schema混用時(shí)編碼端用新字段解碼端按舊字段表讀數(shù)據(jù)錯位是必然的。解決確認(rèn)新版PDF里的schema版本號重新生成EXI編解碼選項(xiàng)并在代碼的配置里把schema版本號固化到日志中方便后續(xù)排查。5.3 現(xiàn)象SLAC計(jì)時(shí)參數(shù)沒校準(zhǔn)充電啟動不穩(wěn)定現(xiàn)場反饋某款樁在特定車型上偶爾要等10秒以上才進(jìn)入充電流程重試幾次才能成功。查日志發(fā)現(xiàn)SLAC過程重復(fù)了多輪對端的衰減特征遲遲沒有確認(rèn)。原因SLAC過程中有一系列時(shí)間參數(shù)比如等待對端響應(yīng)的時(shí)間窗口、重試上限。2024版如果調(diào)整了這些參數(shù)的取值或默認(rèn)值老設(shè)備按舊參數(shù)等待就可能導(dǎo)致時(shí)序余量不足。解決對照規(guī)范里SLAC相關(guān)章節(jié)的時(shí)間參數(shù)表逐項(xiàng)核對樁端配置修改后做重復(fù)連接測試重點(diǎn)看在弱信號場景下的建立時(shí)間是否穩(wěn)定。5.4 現(xiàn)象TLS版本未更新老樁連不上新車型最隱蔽的一類問題。充電啟動黑屏樁端日志只有“TCP連接被斷開”沒有TLS錯誤信息。最后抓包才發(fā)現(xiàn)TLS ClientHello里聲明的版本和cipher suite不滿足新車型要求被對方直接斷開連接。原因TLS握手是加密通信的第一步失敗后上層應(yīng)用根本接收不到任何業(yè)務(wù)報(bào)文錯誤信息被掩蓋在socket異常里。解決核對安全章節(jié)里TLS最低版本、cipher suite列表更新嵌入式TLS棧配置。改完后用抓包工具回放握手過程確認(rèn)協(xié)商出的版本和加密套件落在規(guī)范允許范圍內(nèi)。5.5 現(xiàn)象把“應(yīng)”和“宜”混為一談預(yù)認(rèn)證直接卡住測試工程師做符合性檢查時(shí)把所有“should”宜條款都當(dāng)成“shall”應(yīng)來測導(dǎo)致測試用例數(shù)量翻倍還出現(xiàn)一堆“未通過”項(xiàng)后來發(fā)現(xiàn)這些項(xiàng)只是推薦項(xiàng)不構(gòu)成符合性缺陷。原因標(biāo)準(zhǔn)文檔里規(guī)范性與推薦性條款混雜英文原版里“shall”和“should”區(qū)分明確但二手資料和口頭傳遞里被簡化成一個“應(yīng)”字。解決在條款索引里為每個章節(jié)打上標(biāo)簽——Normative強(qiáng)制性或Informative資料性/推薦測試用例只對Normative條款做通過/失敗斷言Informative內(nèi)容作為參考記錄。6. 把規(guī)范條款變成測試用例最后一步的映射技巧拿到DIN TS 70121-2024并完成條款索引后下一步是把條款翻譯成測試用例。我常用的映射表長這樣條款路徑測試項(xiàng)通過標(biāo)準(zhǔn)備注通信流程 / SessionSetupReq發(fā)送合法SessionSetupReq等待響應(yīng)收到SessionSetupRes且錯誤碼為OK響應(yīng)時(shí)間窗口按規(guī)范設(shè)定消息定義 / ChargeParameterDiscovery注入不同電池容量參數(shù)樁端按參數(shù)計(jì)算電壓電流范圍驗(yàn)證數(shù)值邊界EXI編碼 / Schema版本使用新版Schema生成的報(bào)文解析無異常字段一一對應(yīng)新舊schema混用則失敗安全參數(shù) / TLS版本用最低允許TLS版本握手握手成功協(xié)商版本在允許范圍內(nèi)TSL配置錯誤時(shí)直接fail安全參數(shù) / 證書鏈驗(yàn)證導(dǎo)入測試證書鏈樁端正確識別并建立安全通道證書過期場景單獨(dú)留用例我的習(xí)慣是在測試腳本里把“條款路徑”寫成一個字段比如test_5_3_2_charge_parameter_discovery失敗的時(shí)候直接反查索引表定位到對應(yīng)章節(jié)而不是靠記憶回想“這是哪個模塊的bug”。反向追溯的方法類似抓包看到某個字段值異常先翻條款索引找到該字段的定義章節(jié)再回來判斷是樁端發(fā)送錯誤、車端解析錯誤還是兩端schema版本不匹配。這樣排查問題就不靠玄學(xué)而是靠一份可檢索的路徑清單。做測試執(zhí)行時(shí)我還會把“條款路徑”和“測試結(jié)果”合并回mapping.csv里每跑一輪就更新一次到預(yù)認(rèn)證前這份表就是最直接的符合性證據(jù)?；氐介_頭那個問題這份“DIN TS 70121-2024英文原版可復(fù)制帶書簽.pdf”值不值得投入時(shí)間去消化我的答案是值得的。2024版帶來的引用文件、EXI schema和TLS參數(shù)變化如果沒有一份可復(fù)制、可檢索的原文做基準(zhǔn)團(tuán)隊(duì)很容易在舊版實(shí)現(xiàn)上繼續(xù)走。我現(xiàn)在的習(xí)慣是拿到新版本先做條款路徑登記再談改代碼。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取