充電樁對車講 ISO 15118（見 EVCC 與 SECC 那篇），對後台講的則是 OCPP（Open Charge Point Protocol）——樁與中央管理系統（CSMS）之間的開放協定。樁能不能被遠端啟停、能不能參與電力調度、換一家營運平台要不要換樁，全看這一層。
OCPP 在管什麼
一條 OCPP 連線（WebSocket 上的 JSON 訊息）承載四類日常：
- 生命週期：樁開機報到、心跳、狀態回報（可用、充電中、故障）、韌體更新與診斷檔上傳
- 授權與交易：使用者驗證（卡片、App、隨插即充）、充電交易的開始／結束與電量回報——這是計費的資料來源
- 遠端操作：遠端啟動／停止、解鎖接頭、重啟、變更組態——客服電話背後的那些動作
- 智慧充電：後台下發充電曲線（Charging Profile），限制單樁或整站的功率包絡——場站契約容量管理與電網互動的基礎
1.6 與 2.0.1：不是小改版
市場上 1.6 仍是存量主流，但兩版的差距是架構級的：
| OCPP 1.6 | OCPP 2.0.1 | |
|---|---|---|
| 裝置模型 | 簡單（Connector 為主） | 分層元件模型（Station/EVSE/Connector），組態與監控粒度大增 |
| 資安 | 基本（依部署自求多福） | 內建資安檔次：TLS、憑證管理、安全事件通知 |
| 與 ISO 15118 的銜接 | 無原生支援 | 原生支援（憑證安裝、PnC 授權流程過後台） |
| 智慧充電 | 有，較基礎 | 更完整（多層曲線、更新機制） |
| 監控與診斷 | 有限 | 變數監控、事件通知框架 |
選版的實務判斷：新建場站以 2.0.1 為目標（資安與 PnC 是趨勢的必要條件）；既有 1.6 樁隊則規劃過渡——後台要同時講兩種話，這是選 CSMS 時的硬性問題。
「支援 OCPP」的水很深
OCPP 的訊息很多是選配，兩個都「支援 OCPP 1.6」的產品，實作的訊息集可能差一大截。採購與整合時要問到訊息層級：
- 智慧充電支援到什麼程度？（有沒有實作 Charging Profile 的堆疊與優先序）
- 離線行為？斷線時本地授權清單怎麼運作、交易紀錄怎麼補傳
- 韌體更新與診斷檔的流程完不完整
- 資安檔次實作到哪一級（純 TLS？雙向憑證？）
互通性測試因此是場站專案的必經站：樁端模擬（測後台）與後台模擬（測樁）兩個方向都要有，異常情境（斷線重連、訊息亂序、非法值、時間偏移）比正常流程更值得花時間——營運中出事的都是這些。
三個介面方向，最後一個常被留到最後
一支樁其實有三個對外方向：對車（15118／61851）、對後台（OCPP）、對電網與場域（負載管理、能源系統整合）。專案裡最常見的順序錯誤，是把第三個方向留到樁都佈完才想——結果契約容量不夠、動態調度做不了，回頭改的是整站的組態與後台邏輯。三個方向在規劃期就要一起上桌。
下一步
從 OCPP 版本策略、CSMS 選型到樁後台互通測試，歐特莫夫（Vector Informatik 合作夥伴）協助把場站營運的通訊層一次規劃到位。