OCPP 1.6 與 2.0.1 比較

2.0.1 並不是「加了更多報文的 1.6」。它重構了設定、交易與安全，而且兩者在任一方向上都不具備線路層相容性。

兩個版本共用一套傳輸——WebSocket 上的 OCPP-J——以及一套子協定協商機制，相似之處大致就到此為止。充電樁在 Sec-WebSocket-Protocol 中宣告 ocpp1.6 或 ocpp2.0.1，而同時支援兩者的 CSMS，實際上是在這個選擇背後跑著兩套獨立實作。

OCPP 1.6 仍是多數已部署硬體所使用的版本。2.0.1 則越來越多地成為新採購的硬性要求。多數營運方會在很長一段時間裡同時運行兩者——這正是這份比較有現實意義的原因。

報文對應關係

每則 1.6 報文在 2.0.1 中的去向。這不是一條遷移路徑——即便名稱沿用，酬載也已不同。

OCPP 1.6	OCPP 2.0.1	變化
`Authorize`	`Authorize`	用途相同。`idTag` 變為結構化的 `idToken` 物件。
`BootNotification`	`BootNotification`	`chargePointVendor`/`chargePointModel` 移入 `chargingStation` 物件。
`Heartbeat`	`Heartbeat`	用途未變。
`StartTransaction`	`TransactionEvent`	開始、結束與中途更新合併為一則帶 `eventType` 的報文。
`StopTransaction`	`TransactionEvent`	同上——`eventType: "Ended"`。
`MeterValues`	`TransactionEvent`	工作階段進行期間，電表資料隨 TransactionEvent 一併傳送。
`StatusNotification`	`StatusNotification`	現在依 EVSE 與連接器分別回報，而不再是扁平的連接器編號。
`ChangeConfiguration`	`SetVariables`	扁平的字串鍵變為裝置模型中可定址的變數。
`GetConfiguration`	`GetVariables`	同樣的變化，只是由寫改為讀。
`GetDiagnostics`	`GetLog`	做了一般化：既涵蓋診斷日誌，也涵蓋安全日誌。
`ReserveNow`	`ReserveNow`	ReserveNow 現已成為核心的一部分，而不再屬於選用檔。

這是其餘一切變化的源頭。OCPP 1.6 的設定是一張扁平的字串鍵值表——HeartbeatInterval、MeterValueSampleInterval——而一台充電樁的能力，就等於它恰好擁有哪些鍵。

2.0.1 以結構化的裝置模型取而代之：元件、變數，以及帶型別與約束的屬性。CSMS 可以直接請充電樁自我描述，而不必逐個試探鍵名再聽天由命。

這是一項扎實的改進，同時也是遷移工作量最大的單一來源，因為 1.6 設定層面的一切都無法直接平移。

在 1.6 中，一次工作階段是 StartTransaction、然後 MeterValues、再 StopTransaction——三種報文類型，各自的關聯規則不同，transactionId 由伺服端指派。

在 2.0.1 中，這三者統一為 TransactionEvent，eventType 取 Started、Updated 或 Ended，且交易編號由充電樁自己產生。離線處理因此大為簡化，因為充電樁再也不必等伺服端來為一次它已經開始的工作階段命名。

OCPP 1.6 在安全方面幾乎什麼都沒說。TLS 只是建議，認證不在範圍內，實務上的部署從明文 ws:// 到雙向 TLS 什麼都有。

2.0.1 定義了三種安全設定檔：TLS 上的 HTTP Basic、帶用戶端憑證的 TLS，以及雙向憑證認證的 TLS，並配有用於輪替憑證的管理報文。對於任何曾經要為一張充電網路填寫安全問卷的人來說，這是整次升級中最有價值的部分。

1.6 的連接器從 1 開始編號，0 表示整台充電樁。這種扁平模型無法表達這樣一個站點：兩個連接器共用一個功率模組，因而無法同時以滿功率充電。

2.0.1 在站點與連接器之間引入了 EVSE 這一明確層級，正是它讓多插座硬體上的負載分配得以正確進行。

兩個版本都有充電設定檔。2.0.1 增加了來自本地能源管理系統的充電限值、對 ISO 15118 的支援（隨插即充與雙向能量流動），以及對「什麼可以限制一次工作階段」遠為豐富的表達。

如果你的 1.6 智慧充電能運作，概念是可以轉移的。酬載則不行。

如果你正在為今年出貨的硬體開發韌體，多數網路接入它時用的仍是 1.6，而越來越多的標案要求 2.0.1。把協定層放在一層抽象之後——而不是讓 OCPP 報文型別貫穿你的商業邏輯——才是讓同時支援兩者變得划算的關鍵。

如果你在建構 CSMS，兩者都得支援，因為在可預見的時間裡，你客戶的車隊中兩種版本都會存在。

無論哪種情況，遷移成本都集中在設定與交易上，而不在傳輸層。把預算留給裝置模型。

完整的 1.6 報文集合記載於我們的 OCPP 1.6 參考文件，而 OcppPilot 以同一套 Go 介面實作了兩個版本。