OCPP 1.6J 與 2.0.1 在商業充電業者的策略比較

OCPP 1.6J 與 2.0.1 版本面向全球商業充電運營商的權威戰略比較：掌握網絡可擴展性、高級網絡安全、ISO 15118 集成以及面向未來的長期基礎設施，助力電動汽車可持續發展

執行摘要

電動車充電領域正經歷著翻天覆地的變化。隨著全球電動車普及速度的加快，電動車供電設備（EVSE）與充電站管理系統（CSMS）之間互動的底層通訊協定已成為商業充電營運商（CPO）技術策略的核心。由開放充電聯盟（OCA）維護的開放充電點協定（OCPP）已從一個簡單的訊息傳遞框架發展成為一個複雜、安全且高度可擴展的標準。

本指南對從 OCPP 1.6J 過渡到 OCPP 2.0.1 進行了詳盡的技術分析。我們探討了架構差異、安全增強、裝置管理範式以及 ISO 15118 整合的關鍵角色。對於採購者和營運商而言，本文是他們在快速成熟的市場中做出明智採購和遷移決策的權威參考。

第一章：電動車充電標準的演進：歷史背景

開放充電樁協議 (OCPP) 的誕生源於對互通性的需求。在電動車充電的早期階段，硬體製造商和軟體供應商使用專有協議，形成了“圍牆花園”，扼殺了競爭和創新。 OCPP 1.2 和 1.5 的推出奠定了基礎，但真正實現產業統一的是 OCPP 1.6。

1.1 OCPP 1.6J 的主導地位

OCPP 1.6 於 2015 年發布，引入了基於 WebSocket 的 JSON (1.6J) 實作。這項從基於 SOAP 的訊息傳遞方式的轉變顯著降低了系統開銷，並簡化了開發人員的實作。它還引入了智慧充電和額外的狀態通知等功能，使其成為近十年的行業標準。

1.2 OCPP 2.0.1 的起源

儘管1.6J標準取得了成功，但行業的快速發展也暴露了其局限性。安全問題、設備管理複雜性以及缺乏對高級電網整合（V2G）的原生支持，促使OCPP 2.0的開發，隨後又推出了改進後的OCPP 2.0.1（於2020年發布）。 OCPP 2.0.1並非簡單的更新，而是一次徹底的重新設計，旨在支援下一代高功率、智慧且安全的充電網路。

第二章：底層通訊範式：JSON、WebSocket 與框架結構

要理解這些協定之間的區別，必須考察其底層通訊方式。雖然兩種協定都使用基於 WebSocket 的 JSON 數據，但訊息的結構和處理方式卻截然不同。

2.1 WebSocket 層

這兩個版本都採用持久性 WebSocket 連接，從而實現全雙工通訊。這對於即時操作至關重要，例如透過行動應用停止充電或接收即時故障警報。

2.2 資訊框架分解

典型的 OCPP 訊息由訊息類型 ID、唯一訊息 ID、操作名稱和有效載荷組成。

OCPP 1.6J 幀範例（啟動通知）

“json [2, "123456", "BootNotification", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]“

OCPP 2.0.1 幀範例（啟動通知）

“json[2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "firmwareVersion": "SN-Z-99", "firmwareVersion": "v2.`請注意 2.0.1 版本中粒度的增加。`reason` 欄位讓 CSMS 了解啟動是由於重啟、上電還是看門狗觸發引起的，從而實現更好的診斷邏輯。

第三章：架構典範轉移：設備模型

OCPP 2.0.1 中最重要的技術變化是引進了設備型號.

3.1 1.6J 配置鍵的局限性

在 OCPP 1.6J 中，硬體配置是透過「配置鍵」的扁平清單進行管理的（例如，心跳間隔, 連線逾時隨著充電樁變得越來越複雜（多介面、整合式電源模組、複雜的冷卻系統），這種扁平化的清單變得難以管理。當時還沒有一種標準化的方法來描述充電樁的物理層級結構。

3.2 2.0.1 設備模型方法

OCPP 2.0.1 引入了一個分層模型，該模型由以下部分組成：成分和變數組件可以是“控制器”、“連接器”或“電源模組”。每個組件都有表示其狀態或配置的變數（例如，溫度, 電壓, 最大電流).

• 成分充電站的物理或邏輯組成部分。
• 多變的該組件的特定屬性。
• 特徵：描述變數的元資料（單位、範圍、存取類型）。

這樣就實現了標準化監控。操作員現在可以使用標準化的路徑查詢特定電源模組的溫度，而無需依賴廠商特定的專有金鑰。

第四章：網路安全：從「盡力而為」到強制TLS

在電動車充電技術的早期階段，安全性往往被忽略。 OCPP 1.6J 提供了安全設定文件，但不同廠商的實作方式並不一致。

4.1 1.6J 中的安全設定文件

OCPP 1.6J 定義了三個安全性設定檔：

1. 不安全：純文字 HTTP/WebSocket。
2. 基本驗證：使用使用者名稱/密碼的 TLS 加密。
3. 基於證書：使用客戶端憑證的 TLS。

問題在於許多充電器仍然處於 Profile 1 狀態，這使得它們容易受到中間人 (MITM) 攻擊和未經授權的控制。

4.2 2.0.1 版本的強化立場

OCPP 2.0.1 強制要求安全通訊。它原生整合了進階安全功能：

• 安全韌體更新：韌體映像的強制簽章和驗證。
• 安全日誌記錄：安全相關事件的詳細日誌（例如，登入嘗試失敗、憑證過期）。
• 證書管理：輪換和更新憑證的標準化訊息（CSMS 主導或站點主導）。
• TLS 1.2/1.3支援最新的加密標準。

對於商業營運商而言，這降低了大規模網路入侵的風險，並確保符合物聯網設備的新興網路安全法規。

第五章：ISO 15118 整合：即插即用與 V2G

電動車充電的未來不僅是電子的傳輸；它還關乎數據和能量的智慧交換。 ISO 15118 是車網通訊 (V2G) 的國際標準，它與 OCPP 的整合是 2.0.1 版本的核心特徵。

5.1 即插即充的複雜性

即插即用 (PnC) 技術允許駕駛員只需將車輛插入電源即可開始充電，無需使用應用程式或 RFID 卡。這需要複雜的公鑰基礎設施 (PKI)，涉及車輛、充電器、營運商和清算中心。

在 OCPP 1.6J 中，基礎協定並不支援 PnC（圖形化和內容控制）。供應商必須實現自訂擴展，導致協議碎片化。 OCPP 2.0.1 透過支援以下功能為 PnC 提供了「底層架構」：

• 證書安裝：透過電動車充電設備將合約證書從 CSMS 傳遞到電動車。
• 授權：使用從車輛證明書匯出的電動車 ID (eMAID)。
• 加密通訊確保車輛與電網之間傳輸的敏感計費資料受到保護。

5.2 智慧充電與負載平衡

雖然 1.6J 支援基本的智慧充電（發送一個設定充電設定檔），2.0.1 版本進一步提升了這一點。它允許：

• 外部訊號集成對電網頻率或批發價格訊號做出即時響應。
• 動態負載管理對擁有數百個連接器的站點進行更精細的電源分配控制。
• 車網互動（V2G）：2.0.1 版本包含支援雙向能量流動的必要資料字段，允許電動車作為電網的分散式能源 (DER) 運作。

5.3 使用者介面/使用者體驗改進

OCPP 2.0.1 支援將資訊直接顯示在充電器螢幕或車輛儀錶板上，例如：

• 以當地貨幣即時定價。
• 達到 80% 電量 (SoC) 的預計時間。
• 完成後將提供詳細收據。

第六章：高階設備管理與監控

對於認證二手設備製造商 (CPO) 而言，充電器的成本不僅僅是購買價格，還包括總擁有成本 (TCO)。維護和停機時間是最大的利潤殺手。 OCPP 2.0.1 透過卓越的監控功能解決了這個問題。

6.1 事件驅動型報告

在 1.6J 模式下，CSMS 通常需要輪詢充電器狀態或等待。狀態通知在 2.0.1 版本中，事件監控該系統允許客戶監控管理系統 (CSMS) 設定閾值。例如：「僅當內部溫度超過 70°C 時才通知我」或「當輸入電壓低於 200V 時才報告」。這可以減少網路流量並實現主動維護。

6.2 事務處理：事務事件

OCPP 1.6J 最受詬病的方面之一是其對交易的處理方式。一次會議涉及開始交易和停止交易雖然訊息可以正常發送，但如果發生網路中斷，CSMS 經常難以核對計費資料。

OCPP 2.0.1 用一個單一、強大的組件取代了這些組件。交易事件消息。此訊息用於報告事務的所有生命週期階段（開始、更新、結束）。它包含一個唯一的交易 ID即使充電器重啟，這種機制仍然有效，確保不會失去充電數據，從而避免收入損失。

6.3 改進的診斷和故障排除

這取得日誌和診斷狀態通知2.0.1 版本中的訊息結構更加清晰。首席產品長 (CPO) 可以請求特定日誌類型（安全性、診斷、使用者）並指定時間範圍。這使得遠端支援團隊無需派遣技術人員到現場即可解決問題，從而顯著降低營運成本 (OpEx)。

第七章：韌體更新機制：可靠性和回滾

韌體更新是硬體不斷發展的生命線，但更新失敗可能會導致充電器變磚。

7.1 1.6J 更新過程

在 1.6J 中，更新韌體命令相對簡單。充電器會下載鏡像檔案並嘗試安裝。當時沒有標準化的多階段更新機製或經過驗證的回滾機制。

7.2 2.0.1 多步驟更新

OCPP 2.0.1 為韌體更新引入了更完善的生命週期管理：

1. 下載充電器獲取影像並驗證其校驗和/簽名。
2. 安裝更新已套用至輔助分割區。
3. 確認系統檢查新韌體是否能正確啟動。
4. 啟用設定主分區已切換。

如果任何步驟失敗，則該協定規定了充電器應如何回滾到先前的穩定版本，並將具體的故障碼報告給CSMS（客戶服務管理系統）。對於大規模商業部署而言，這種可靠性是不可妥協的。

7.3 簽名驗證

為防止惡意攻擊者上傳被竄改的韌體，2.0.1 版本強制要求使用數位簽章。充電器將拒絕執行任何未經製造商私鑰簽署的程式碼，從而為抵禦硬體級攻擊增加了一層關鍵的保護。

第八章：資料隱私、監管合規和GDPR

隨著電動車充電成為日常必需品，產生的個人數據量令人震驚。一次充電就能將使用者的身分、車輛位置、出行模式和財務資訊關聯起來。

8.1 OCPP 中的個人識別資訊 (PII)

在歐洲《一般資料保護規範》(GDPR) 和加州類似法律（例如 CCPA）的背景下，資料點（例如…）id標籤（RFID）或EVCCID（車輛識別碼）被視為個人識別資訊。

OCPP 2.0.1 為資料匿名化提供了更好的控制措施。例如，自訂數據欄位允許運營商儲存元數據，而無需將個人識別資訊 (PII) 暴露給核心協議日誌。此外，增強的安全性設定檔可確保這些資料在傳輸和預存程序中均經過加密。

8.2 被遺忘權和資料可攜性

2.0.1 設備模型的結構化特性使得客戶成功管理系統 (CSMS) 提供者能夠更輕鬆地實現「資料刪除」請求。在 1.6J 系統中，要從分散的配置鍵和日誌中找到使用者 ID 的所有實例，手動操作簡直是一場噩夢。而在 2.0.1 版本中，設備狀態和事務資料的清晰分離使得資料庫架構更加簡潔。

8.3 遵守物聯網安全法律

許多地區現在都通過了法律，要求物聯網設備必須擁有唯一的密碼和安全的更新機制。 OCPP 2.0.1 強制要求的 TLS 加密和韌體簽章並非「錦上添花」的功能，而是在加州和英國等市場銷售硬體的法律要求。

第九章：買方視角：總擁有成本、投資報酬率與策略遷移

對於商業充電業者而言，是繼續使用 1.6J 還是升級到 2.0.1 是財務問題。

9.1 實施成本

• OCPP 1.6J實施成本低，低成本硬體支援廣泛，但維護成本高，且有安全風險。
• OCPP 2.0.1：需要電動車充電設備配備更強大的處理器和更大的記憶體。由於協議的複雜性，CSMS 的開發成本更高。然而，它透過遠端管理和更高的可靠性，顯著降低了營運成本。

9.2 「平穩升級」的迷思

人們常說1.6J充電器可以透過軟體升級到2.0.1版本。但實際上，這種情況很少發生。 2.0.1版本對記憶體和CPU的要求（尤其是處理TLS憑證和複雜的裝置模型JSON解析）通常超出了舊款1.6J控制器的處理能力。

9.3 策略性遷移路徑

首席採購官應考慮採用「混合網路」方法：

1. 遺留網站：繼續對現有的低功率交流充電器運行 1.6J。
2. 新直流快速充電站：強制要求 2.0.1 對所有新的高功率部署提供支援 PnC 和 V2G。
3. 代理解決方案使用協定網關，將 1.6J 訊息轉換為 CSMS 相容的 2.0.1 格式，從而實現單一的統一管理儀表板。

第十章：面向未來：OCPP 2.1 與自主充電之路

即使 OCPP 2.0.1 正在獲得廣泛認可，開放充電聯盟也已經在著手開發 OCPP 2.1。這個未來的版本將進一步擴大該協議的覆蓋範圍。

10.1 雙向充電 (V2X)

雖然 2.0.1 支援基本的 V2G，但 2.1 將改進車家 (V2H) 和車樓 (V2B) 的通信，使電動車能夠在停電期間為家庭供電或削減商業建築的高峰需求。

10.2 支援無線充電

隨著自動駕駛汽車（AV）的普及，手動插拔充電線將逐漸淘汰。 OCPP 2.1 將包含用於感應式（無線）充電的標準化訊息，實現無需人工幹預的對準和能量傳輸管理。

10.3 與智慧城市的融合

未來的版本可能會與交通管理系統和再生能源預測進行更深入的整合。充電樁將能夠在即時能源市場中「競價」電力，從而將充電網路轉變為龐大的虛擬電廠（VPP）。

技術附錄：深入分析資訊對比

為了提供最深入的技術分析，我們現在將分析兩個版本之間的特定訊息序列和幀差異。

A.1 授權流程

在 1.6J 版本中，授權是一個二元回應，即「已接受」或「已封鎖」。

1.6J AuthorizeResponse：“json[3, "123456", { "idTagInfo": { "status": "已接受", "expiryDate": "2026-12-31T23:59:59Z" } }]“

在 2.0.1 版本中，回應包含更多上下文訊息，例如：idToken使用者介面的類型和附加資訊。

2.0.1 AuthorizeResponse：“json[3, "987654", { "idTokenInfo": { "status": "已接受", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content"", "personalMessage": { "format": "UTF8", "content"", 歡迎回來為你的餘額！"“

A.2 心跳與連結管理

OCPP 2.0.1 優化了網站證明自身「存活」的方式。在 1.6J 的功率下，如果一個心跳如果失敗，網站通常會不斷重試。在 2.0.1 版本中，站點可以使用通知事件一種機制，用於報告與輔助後端的連接已斷開，同時仍與主後端保持心跳。

A.3 詳細元資料表

結論

從OCPP 1.6J到2.0.1的過渡不僅是一次軟體更新，更是電動出行生態系統的一次根本性變革。對於商業業者而言，1.6J代表著可靠的過去，而2.0.1則代表著可擴展、安全且智慧的未來。

選擇 2.0.1 版本是對未來的投資。它能確保您的硬體與新一代電動車相容，符合日益嚴格的網路安全法規，並為 V2G 和智慧電網整合帶來的巨大機會做好準備。隨著市場整合，擁有最強大、最靈活的協定棧的營運商將引領潮流。

第十一章：深入探討：訊息流分析與序列圖

在本章中，我們將分析 EVSE 和 CSMS 之間的交互序列，以顯示 1.6J 和 2.0.1 之間的操作差異。

11.1 啟動和配置順序

充電器首次連接到網路時，必須進行自我識別並同步其配置。

OCPP 1.6J 流量：

1. WebSocket 連接：透過 80 號或 443 號埠建立。
2. 啟動通知：站點發送供應商、型號和序號。
3. 取得配置CSMS 請求所有按鍵以檢查目前狀態。
4. 更改配置：CSMS 更新特定鍵（例如，心跳間隔).
5. 狀態通知站點報告“可用”。

OCPP 2.0.1 流程：

1. 安全TLS握手強制性證書交換。
2. 啟動通知包括原因（例如，能量提升).
3. 取得基礎報表CSMS 不要求所有金鑰，而是要求“基本報告”，其中提供了裝置型號的完整層次結構。
4. 設定變數CSMS 會更新變數。請注意，2.0.1 版本支援原子更新——即在一條訊息中設定多個變量，並確保所有變量都成功更新，否則全部失敗。
5. 通知事件：站點報告初始組件狀態。

11.2 智慧充電協商

智慧充電是 2.0.1 版本真正大放異彩的地方，尤其是在處理多種充電模式方面。

在 1.6J 時，CSMS 發送一個設定充電設定檔它定義了堆疊層級和調度。如果一個網站有多個連接器，則設定檔處理通常會變得模糊不清。

在 2.0.1 版本中，設定充電設定檔明確地與一個充電設定檔用途.

• 充電站 MaxProfile限制整個站點的進氣量。
• TXDefaultProfile：任何新交易的預設值。
• TXProfile：特指正在進行的交易。

此外，2.0.1 支持取得充電堆疊級別訊息，使 CSMS 能夠看到哪些設定檔目前處於活動狀態，以及 EVSE 的內部排程器如何確定它們的優先順序。

11.3 遠端觸發和控制

遠端命令遠端啟動事務（1.6J）已被替換為請求啟動事務（2.0.1）主要區別在於有效載荷。在 2.0.1 版本中，CSMS 可以包含一個充電設定檔直接在啟動請求中執行。這意味著車輛可以立即以正確的功率等級開始充電，無需等待第二個訊息，從而降低延遲並提高電網穩定性。

第十二章：底層 JSON 模式與欄位比較

對於開發人員和系統整合商而言，架構變更是遷移過程中最耗費人力的部分。

12.1 枚舉型別（枚舉）

OCPP 2.0.1 大大擴展了標準化枚舉的數量，減少了對困擾 1.6J 實現的「自訂」狀態碼的需求。

• 原因枚舉: 監督機構, 定時重置, 遠端重置, 功率損耗.
• 狀態枚舉: 佔領, 預訂的, 不可用, 故障2.0.1 版本新增可用的, 佔領, 預訂的, 不可用, 故障但還有子狀態以提供更多詳細資訊。

12.2 資料型態和單位

OCPP 2.0.1 正式規定了標準單位（SI）的使用。 1.6J 有時未定義小數精度，而 2.0.1 則使用標準單位。十進位用於定義功率和能量值類型，確保不同供應商硬體之間的計費一致性。

第十三章：案例研究：全球 CPO 從 1.6J 到 2.0.1 的遷移

讓我們來看一個假設的場景：“MegaCharge”，一個擁有 10,000 個充電樁的 CPO 專案。

13.1 第一階段：審計

MegaCharge發現其1.6J充電樁車隊中有40%不支援TLS 1.2。這意味著這些充電樁不符合即將簽訂的政府合約的資格。

13.2 第二階段：CSMS升級

MegaCharge 沒有建立新的 CSMS，而是實作了一個「OCPP 轉換層」。該層處理舊硬體的 1.6J 連接和新硬體的 2.0.1 連接，但向其行動應用程式和計費引擎公開了一個統一的 API。

13.3 第三階段：硬體更換

對於高流量站點，MegaCharge 將 1.6J 充電器替換為符合 2.0.1 標準的直流快速充電器。結果，「啟動失敗」的次數減少了 15%，這主要歸功於更強大的充電器。交易事件處理 2.0.1。

13.4 投資報酬率分析

初始投資為200萬美元。然而，由於設備型號的診斷功能減少了維護次數，每年節省了40萬美元。此外，參與V2G頻率響應市場還能帶來每年20萬美元的額外收入。投資回收期約3.3年。

第十四章：OCPP 2.0.1採購的買方終極核對清單

在評估新的硬體或軟體時，請使用此清單以確保真正符合規格：

14.1 硬體（電動車充電設備）要求

• [ ]支援安全性設定檔 3它是否支援客戶端憑證管理？
• [ ]雙核心處理器是否有足夠的資源來支援 TLS 加密和 JSON 解析？
• [ ]安全元件（SE）主機板是否有用於儲存密鑰的硬體信任根？
• [ ]ISO 15118-2/20 已就緒控制器能否處理 PnC 所需的高階通訊？
• [ ]顯示能力硬體是否支援透過OCPP顯示價格/狀態訊息資料傳輸還是原生訊息？

14.2 軟體（CSMS）要求

• [ ]設備模型可視化儀錶板能否顯示充電器的層級視圖？
• [ ]憑證授權單位 (CA) 集成CSMS能否自動核發和輪換憑證？
• [ ]交易對帳系統如何處理來自 1.6J 傳統充電器的「掛起」交易？
• [ ]智慧充電引擎它是否支援 2.0.1 版本的高階堆疊層級邏輯？
• [ ]可擴展性WebSocket 處理程序能否同時管理超過 50,000 個持久性 TLS 連線？

第十五章：OCPP 常見實施問題的檢驗

即使有了標準，具體實現方式也會有所不同。以下是一些最常見的“陷阱”。

15.1 WebSocket 超時

許多網路防火牆會關閉空閒的 TCP 連線。如果心跳間隔如果設定過高，充電器可能會斷開連接。

• 解決方案： 確保心跳間隔低於防火牆的超時時間（通常為 60-120 秒）。

15.2 憑證鏈問題

2.0.1 版本中常見的故障是「不受信任的憑證」錯誤。這通常發生在充電器未安裝 CSMS 的根 CA 時。

• 解決方案使用安裝證書在調試過程中發送訊息，以確保信任鏈完整。

15.3 JSON 有效載荷大小

一些 2.0.1 訊息（例如取得基礎報表）可能非常大。如果充電器的緩衝區太小，它將丟棄該訊息。

• 解決方案檢查最大訊息大小在設備模型中設定變量，並確保 CSMS 遵守此限制。

第十六章：區域監管環境和議定書要求

向 OCPP 2.0.1 過渡不僅僅是技術驅動的；它越來越成為一個法律問題。

16.1 歐盟（AFIR）

歐盟的《替代燃料基礎設施法規》(AFIR) 強制要求價格透明和互通性。雖然該法規沒有明確提及 OCPP 2.0.1，但其中對「即時資料共享」和「智慧充電」的要求實際上使得 2.0.1 成為新建公共基礎設施唯一可行的標準。

16.2 北美洲（NEVI）

在美國，國家電動車基礎設施（NEVI）公式計畫要求充電樁必須「可互通」。加州等州更進一步，加州能源委員會（CEC）正在推動ISO 15118標準的支持，正如我們之前討論過的，該標準最好透過OCPP 2.0.1來實現。

16.3 中國和亞太地區

雖然中國有自己的標準（GB/T），但以出口為導向的製造商在OCPP 2.0.1方面投入巨大。在澳洲和新加坡等市場，政府對公共充電網路的招標現在幾乎全部指定使用具備安全設定檔3的OCPP 2.0.1。

第十七章：實作程式碼片段：“細節之處”

為了幫助開發人員，我們為複雜的 2.0.1 任務提供概念性的 JSON 表示。

17.1 證書輪換流程

當憑證即將到期時，CSMS 必須觸發輪替。

1. CSMS 發送憑證簽名:“json[2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]“

2. 車站回應公認:“json[3, "CERT-01", { "status": "已接受" }]“

3. 電台發送安全事件通知:“json[2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]“

17.2 設定電網響應式充電方案

想像一下，電網營運商需要削減整個電網的電力供應。

CSMS發送設定充電設定檔:“json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "charging:Kindv" "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]“

第十八章：OCPP 2.0.1 術語綜合詞彙表

為確保所有利害關係人都能清楚理解，我們提供了一個擴展詞彙表。

• CSMS（充電站管理系統）：控制充電器的後端雲端平台。
• 電動車供電設備 (EVSE)實體充電站。
• OCPP（開放式充電點協定）他們所說的語言。
• OCA（開放收費聯盟）編寫該語言的組織。
• ISO 15118：汽車與充電器之間的協定。
• PnC（即插即充）：由 ISO 15118 和 OCPP 2.0.1 實現的使用者體驗。
• V2G（車輛到電網）將汽車產生的電力輸回電網。
• V2X（車聯網）V2G、V2H 和 V2B 的總稱。
• TLS（傳輸層安全協定）：用於保護資料安全的加密技術。
• PKI（公鑰基礎設施）用於安全的數位證書系統。
• JSON（JavaScript 物件表示法）訊息的格式。
• WebSocket持久連接是訊息流經的「管道」。
• 設備型號：分層方式 2.0.1 描述了硬體。
• 成分硬體的一部分（例如，連接器）。
• 多變的組件的屬性（例如，狀態）。
• 屬性：關於變數的元資料（例如，值、可變性）。
• 交易事件：2.0.1 版本中所有會話資料的統一訊息。
• 心跳週期性的「我還活著」訊號。
• 啟動通知充電器啟動時發出的“你好，我在這裡”信號。
• 資料傳輸：針對特定供應商擴展的「通用」訊息（請謹慎使用！）。

結語：駕馭多協定時代

作為買家或營運商，最重要的收穫是我們正在進入一個多協定時代未來3-5年內，1.6J和2.0.1將並存。然而，這種平衡正在迅速改變。

選擇 OCPP 2.0.1，您購買的不僅僅是一個協議，更是一份保障。它確保您的網路能夠適應新車型、新法規和新的收入來源。 2.0.1 的複雜性是進步的代價——而更高的正常運作時間、更低的風險和更優質的客戶體驗，將為您帶來豐厚的回報。

商業充電不再是小眾產業；它是未來交通系統的支柱。而建構這支柱，必須建立在最堅實的基礎上：OCPP 2.0.1。

第十九章：針對 OCPP 2.0.1 的開發：軟體工程師的最佳實踐

從 1.6J 程式碼庫過渡到 2.0.1 不是重構，而是重寫。開發人員必須轉變思維模式。

19.1 擁抱異步性

雖然 WebSocket 本質上是非同步的，但 2.0.1 版本的複雜性意味著單一請求（例如取得基礎報表在資源受限的電動車充電設備 (EVSE) 上，處理此類請求可能需要幾秒鐘。 CSMS 開發人員必須實現穩健的逾時和重試邏輯，以應對不同硬體供應商處理速度的差異。

19.2 高效率的 JSON 解析

JSON 解析會消耗大量 CPU 資源。對於電動車充電設備 (EVSE) 韌體，開發人員應該使用基於流的解析器，而不是將整個有效負載加載到 RAM 中。這一點對於以下情況尤其重要：通知事件訊息中，單一幀內可以包含數百個變數更新。

19.3 狀態機的處理

2.0.1 版本中事務的狀態機比 1.6J 版本更嚴格。開發者必須嚴格遵循轉換規則。交易事件例如，你不能發送一個結束事件發生時未事先發送開始針對該特定事件交易 ID.

第20章：測試、驗證和OCPP合規性測試工具（OCTT）

互通性是 OCPP 的承諾，但只有透過嚴格的測試才能實現。

20.1 OCA認證的作用

開放充電聯盟提供認證課程。買家應尋找“OCPP 2.0.1 認證”標籤。此認證確保該實施方案已通過涵蓋所有強制性規範的一系列自動化測試。

20.2 使用 OCTT

OCPP 合規性測試工具 (OCTT) 是測試的黃金標準。它能夠模擬 CSMS 和 EVSE。

• 面向電動車充電設備製造商：使用 OCTT 驗證您的網站是否能夠處理「正常路徑」場景和極端情況（例如韌體更新期間的網路中斷）。
• 適用於CSMS提供者使用 OCTT 來確保您的後端能夠處理 2.0.1 版本中種類繁多的訊息和嚴格的安全要求。

20.3 現場測試和互通性測試

除了自動化測試之外，OCA 還會組織「互通性測試」（Plugfest），讓供應商攜帶各自的硬體和軟體在真實場景中進行相互測試。正是在這種測試中，最細微的漏洞——例如證書不相容或細微的 JSON 格式差異——才能被發現和解決。

第21章：深度比較表：OCPP 2.0.1的60多項行動

為了提供完整的參考，我們對 2.0.1 的主要訊息進行了分類，並將其與 1.6J 的對應訊息進行了比較。

21.1 配置和配置

21.2 交易處理

21.3 安全和韌體管理

21.4 該表格對您的網路意味著什麼

表格清晰地表明了一點：OCPP 2.0.1 並非 1.6J 的簡單更名。新增的消息族——類型化變數、事件驅動事務和證書管理——是即插即用、智慧充電和監管報告所必需的底層架構。僅支援 1.6J 的充電器可以透過網關進行改造，但僅支援 1.6J 的 CSMS 無法滿足監管機構和汽車製造商日益增長的安全模型要求。在評估硬體時，「支援 2.0.1」應表示韌體已於今日發布，而非計劃於明年發布。此外，由於 OCPP 2.0.1 基於 JSON over WebSocket 而非 1.6J 的 SOAP 傳輸，訊息流更加輕量級，也更容易調試——您的 IT 團隊從第一天起就能感受到這一實際優勢。

第22章：結論：做出升級決定

對於商業運營商而言，實際操作指導原則很明確：

• 新部署應預設使用 OCPP 2.0.1。安全模型、證書處理和 ISO 15118 整合是 2026 年監管環境的先決條件。
• 現有的 1.6J 機隊並未閒置。當您逐步引入 2.0.1 原生硬體時，託管網關和雙協定 CSMS 平台可以彌補差距。
• 先測試再信任。使用 OCTT、插拔測試和分階段推廣——互通性是在實際應用中得到驗證的，而不是從資料表中假設的。
• 要求以書面形式提供遷移方案。您的充電器供應商應該發布從 1.6J 到 2.0.1 的韌體路線圖，並給出具體的日期，而不是含糊其辭的承諾。

行動呼籲：與 MIDA Power 探討您的協議策略

MIDA Power ships OCPP 1.6J and 2.0.1 on every charger, with field-upgradeable firmware and a cloud platform that manages mixed-protocol fleets in a single dashboard. Contact sales@midapower.com for our protocol migration guide, OCTT test reports, and a free compatibility review of your existing network.