電動車充電的高階通訊（HLC）世界裡，「支援 ISO 15118」是一句需要追問三次的話：哪一版？哪些訊息集？資安開不開？ 因為現場真實存在三代協定，而車與樁各自支援的組合，決定了那三十秒的握手是成功還是「充電失敗，請重試」。
三代協定的定位
| DIN 70121 | ISO 15118-2 | ISO 15118-20 | |
|---|---|---|---|
| 定位 | 早期實用版 | 第一代國際標準 | 第二代國際標準 |
| 充電型態 | 僅 DC | AC ＋ DC | AC ＋ DC，架構重寫 |
| 傳輸安全 | 無 TLS | TLS 選用 | TLS 必要 |
| 即插即充（PnC） | 不支援 | 支援 | 支援，憑證架構強化 |
| 雙向能量（V2G/BPT） | 無 | 無正式支援 | 有 |
三者的實體層與網路層一脈相承：控制導引（CP）線上跑電力線通訊（PLC），連線建立走 SLAC（ISO 15118-3 定義）——所以底層握手長得像，分歧從協定版本協商開始。
版本協商：那三十秒裡發生的事
車端（EVCC）與樁端（SECC）建立網路連線後，第一件事是交換支援的應用協定清單（Supported App Protocol）：車端列出「我會講的版本」，樁端挑一個雙方都會的回覆。三種典型的失敗就藏在這裡：
- 交集為空：新車只帶 15118-20、舊樁只會 DIN 70121——直接無話可說
- 有交集但實作不全：雙方協商到 15118-2，但樁端某些選用訊息沒實作，流程走到一半斷線
- 協商成功、參數談崩：進入充電參數交換後，充電曲線、排程模式對不攏
這解釋了為什麼互通性問題總在真樁接上那天爆發：實驗室裡對著自家參考樁測，版本組合是固定的；現場的樁廠牌、韌體版本、實作品質百百種——包括行為不完全符合規範的樁，而使用者不會因為「是樁的錯」就原諒車廠。
PnC 把問題從協定拉到憑證
即插即充（Plug & Charge）讓插槍即完成身分認證與計費授權，體驗漂亮，工程上卻是整條憑證鏈的生命週期管理：車輛憑證的安裝與更新、合約憑證的簽發、樁端的信任鏈驗證、憑證過期與撤銷的處理。15118-20 進一步強化了這套架構（含憑證安裝流程的改版）——很多「充不了電」的案例，追到最後是憑證狀態問題，而不是通訊問題。這也把測試範圍從「訊息對不對」擴大到「憑證生命週期的每個狀態轉移」。
15118-20 的深度解析（含 BPT 雙向與 MCS 方向）另見：新一代電動車充電通訊標準：ISO 15118-20 深度解析
測試怎麼組織才追得上版本矩陣
車端一顆 EVCC 要面對「DIN／-2／-20 × AC／DC × PnC 開關 × 各家樁實作」的組合空間，人工測不完，務實的結構是：
- 一致性測試自動化：以標準測試案例庫（如 CANoe 的充電測試包）逐版本、逐訊息驗內容、順序、逾時、狀態機
- 互通性測試分層：先對參考實作、再對市售樁矩陣；把「不合規但市場存在」的行為納入案例庫——因為使用者一定會遇到
- 通訊與電氣同軸觀測：CP 線上的 PLC 訊號與協定訊息在同一時間軸對照（並接監聽），「握手斷在哪一步」才有波形佐證
下一步
從版本矩陣的測試策略到互通性驗證環境，歐特莫夫（Vector Informatik 合作夥伴）協助把「插上就充得了電」變成可驗證的工程目標。
- 📄 解決方案：電動車充電通訊驗證解決方案
- 📬 預約一次現況盤點