在充電平臺(tái)建設(shè)中，OCPP版本并不只是一個(gè)連接參數(shù)。它會(huì)直接影響充電樁的數(shù)據(jù)模型、交易狀態(tài)機(jī)、安全體系、智能充電能力，以及平臺(tái)未來能否接入即插即充、雙向充電和分布式能源調(diào)度。

目前工程中經(jīng)常遇到三個(gè)版本：OCPP 1.6、OCPP2.0.1 和 OCPP 2.1。OCPP 1.6 仍有較大的設(shè)備存量；OCPP 2.0.1 重構(gòu)了設(shè)備、交易與安全模型；OCPP2.1 則繼續(xù)擴(kuò)展雙向充電、DER 控制和支付等能力。

本文從研發(fā)和架構(gòu)視角比較三個(gè)版本。內(nèi)容用于協(xié)議理解和系統(tǒng)設(shè)計(jì)，不替代 OpenCharge Alliance 發(fā)布的正式規(guī)范、實(shí)施指南及一致性測(cè)試要求。

一、先看結(jié)論

對(duì)比項(xiàng)

OCPP1.6

OCPP2.0.1

OCPP2.1

發(fā)布時(shí)間	2015 年	2020 年	2025 年
傳輸表示	JSON/WebSocket，也有 SOAP 版本	JSON/WebSocket	JSON/WebSocket
設(shè)備描述	固定配置鍵與消息字段	標(biāo)準(zhǔn)化設(shè)備模型	延續(xù)并擴(kuò)展設(shè)備模型
交易主模型	StartTransaction、StopTransaction	TransactionEvent	擴(kuò)展 TransactionEvent相關(guān)能力
安全能力	基礎(chǔ)能力，依賴安全擴(kuò)展與實(shí)施約束	安全配置、證書和安全事件進(jìn)入主規(guī)范體系	延續(xù)2.0.1，并適配新增業(yè)務(wù)能力
智能充電	基礎(chǔ)充電曲線與負(fù)載控制	更完整的充電計(jì)劃、外部約束和監(jiān)控能力	增強(qiáng)智能充電，并加入雙向充電與 DER控制
ISO 15118	不屬于完整原生能力	支持 ISO 15118 相關(guān)能力	增加 ISO 15118-20與雙向功率傳輸
支付	通常由平臺(tái)擴(kuò)展實(shí)現(xiàn)	支持價(jià)格、顯示消息等相關(guān)業(yè)務(wù)表達(dá)	增加預(yù)付卡、支付終端和安全動(dòng)態(tài)二維碼等場(chǎng)景
換電	無標(biāo)準(zhǔn)業(yè)務(wù)模型	無完整換電功能塊	增加電池?fù)Q電支持
適合場(chǎng)景	存量設(shè)備、功能相對(duì)穩(wěn)定的項(xiàng)目	新建公共充電、精細(xì)運(yùn)維和即插即充項(xiàng)目	V2X、能源協(xié)同、換電及新一代海外項(xiàng)目

Zui重要的判斷是：OCPP 1.6 與 OCPP2.0.1、2.1 不是簡(jiǎn)單的字段增量關(guān)系。特別是從 1.6 升級(jí)到2.x，需要調(diào)整設(shè)備模型和交易處理邏輯，不能只替換消息名稱。

OCPP 2.1 建立在 2.0.1之上，官方在設(shè)計(jì)中考慮了 2.0.1 應(yīng)用邏輯的延續(xù)性。但這不等于所有 2.0.1 設(shè)備都可以直接處理 2.1報(bào)文。連接雙方仍需協(xié)商協(xié)議版本，并根據(jù)各自支持的功能塊進(jìn)行處理。

二、協(xié)議框架發(fā)生了什么變化1.OCPP 1.6：以動(dòng)作消息為中心

OCPP 1.6的模型比較直觀。充電樁通過 BootNotification 上線，使用 StatusNotification上報(bào)連接器狀態(tài)，通過StartTransaction 和StopTransaction 建立交易邊界，再用 MeterValues 上傳計(jì)量值。

典型交易鏈路如下：

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

BootNotification
 -> StatusNotification
 -> Authorize
 -> StartTransaction
 -> MeterValues...
 -> StopTransaction

這種模型容易實(shí)現(xiàn)，也適合以“充電樁 + 槍口 +訂單”為核心的傳統(tǒng)平臺(tái)。不過，很多設(shè)備能力只能通過 GetConfiguration 和廠商自定義配置鍵描述。當(dāng)設(shè)備包含多個(gè)控制器、顯示屏、計(jì)量模塊或復(fù)雜傳感器時(shí)，平臺(tái)很難用統(tǒng)一方式理解這些組件。

2. OCPP2.0.1：按功能塊和設(shè)備模型重構(gòu)

OCPP 2.0.1將協(xié)議拆分為多個(gè)功能塊，例如配置管理、授權(quán)、交易、計(jì)量、智能充電、證書管理、固件管理和顯示消息。平臺(tái)可以根據(jù)項(xiàng)目范圍選擇需要實(shí)現(xiàn)的功能塊。

更關(guān)鍵的變化是引入設(shè)備模型。充電站不再只是若干固定配置鍵，而是由組件、變量及屬性組成：

展開

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

ChargingStation
 -> EVSE
     -> Connector
 -> Meter
 -> Display
 -> ControllerComponent + Variable + Attribute

平臺(tái)通過GetVariables、SetVariables、GetBaseReport 等消息讀取配置和能力。相較于 1.6的字符串鍵值，這種結(jié)構(gòu)更適合自動(dòng)發(fā)現(xiàn)、遠(yuǎn)程配置和跨廠商管理。

3. OCPP 2.1：在 2.0.1基礎(chǔ)上向能源系統(tǒng)擴(kuò)展

OCPP 2.1 沒有回到另一套完全獨(dú)立的模型，而是在2.0.1基礎(chǔ)上增加新的功能塊和業(yè)務(wù)選項(xiàng)。它關(guān)注的不再只是“車輛從電網(wǎng)取電”，還包括車輛向外輸出能量、充電站參與能源調(diào)度、現(xiàn)場(chǎng)費(fèi)用計(jì)算，以及換電和臨時(shí)支付。

因此，可以把三個(gè)版本的定位概括為：

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

OCPP 1.6：完成充電連接和基礎(chǔ)運(yùn)營(yíng)OCPP 2.0.1：建立可管理、可監(jiān)控、可審計(jì)的充電基礎(chǔ)設(shè)施OCPP2.1：讓充電設(shè)施進(jìn)一步參與能源與支付生態(tài)

三、交易模型：從開始和結(jié)束消息轉(zhuǎn)向事件流OCPP 1.6 的交易模型

OCPP 1.6使用獨(dú)立的開始與結(jié)束消息：

展開

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

[
 2,
 "msg-101",
 "StartTransaction",
 {
   "connectorId": 1,
   "idTag": "A10001",
   "meterStart": 120035,
   "timestamp": "2026-09-20T08:00:00Z"
 }
]

平臺(tái)返回一個(gè)整數(shù)transactionId，后續(xù)MeterValues 和StopTransaction 使用該編號(hào)關(guān)聯(lián)交易。

問題在于，真實(shí)交易可能由插槍、刷卡、遠(yuǎn)程啟動(dòng)、即插即充、設(shè)備離線或重啟恢復(fù)等多種事件觸發(fā)。僅用開始與結(jié)束兩條消息，很難完整表達(dá)交易過程中的觸發(fā)原因和狀態(tài)變化。

OCPP 2.0.1 的交易模型

OCPP 2.0.1 使用統(tǒng)一的TransactionEvent，通過eventType 表達(dá)Started、Updated和 Ended：

展開

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

[
 2,
 "msg-201",
 "TransactionEvent",
 {
   "eventType": "Started",
   "timestamp": "2026-09-20T08:00:00Z",
   "triggerReason": "Authorized",
   "seqNo": 0,
   "transactionInfo": {
     "transactionId": "TX-20260920-0001",
     "chargingState": "EVConnected"
   },
   "evse": {
     "id": 1,
     "connectorId": 1
   }
 }
]

這里有三個(gè)值得注意的變化：

交易標(biāo)識(shí)由充電站側(cè)生成，并使用字符串表達(dá)；

seqNo 用于識(shí)別事件順序和缺失；

triggerReason 說明本次事件由授權(quán)、線纜連接、停止授權(quán)、遠(yuǎn)程命令或其他原因觸發(fā)。

Updated 事件可攜帶計(jì)量值、充電狀態(tài)和授權(quán)信息，平臺(tái)不再依賴一組松散消息猜測(cè)交易狀態(tài)。OCPP2.1 延續(xù)該事件模型，并擴(kuò)展固定費(fèi)用、固定能量、固定時(shí)長(zhǎng)以及強(qiáng)制重啟后恢復(fù)交易等能力。

平臺(tái)實(shí)現(xiàn)建議

同時(shí)支持多個(gè)版本時(shí)，不要讓業(yè)務(wù)訂單直接依賴協(xié)議消息?？梢栽诮尤雽影讶N協(xié)議統(tǒng)一成內(nèi)部事件：

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

OCPP 原始消息
 -> 協(xié)議適配層
 -> TransactionStarted
 -> TransactionUpdated
 -> TransactionEnded
 -> 統(tǒng)一訂單狀態(tài)機(jī)

原始報(bào)文仍需保留，用于問題定位和爭(zhēng)議復(fù)核；統(tǒng)一事件則供訂單、計(jì)費(fèi)、風(fēng)控和通知服務(wù)消費(fèi)。

四、設(shè)備與配置管理OCPP 1.6：配置鍵模型

1.6 主要通過GetConfiguration 和ChangeConfiguration 管理設(shè)備。標(biāo)準(zhǔn)定義了一批配置鍵，但廠商經(jīng)常增加自定義鍵，例如：

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

VendorMeterIntervalVendorDoorAlarmEnabledVendorPowerModuleCount

平臺(tái)需要針對(duì)不同廠商維護(hù)映射表。鍵名、數(shù)據(jù)類型、讀寫權(quán)限和取值范圍通常依賴廠商文檔。

OCPP 2.0.1 和 2.1：設(shè)備模型

2.x 使用“組件 + 變量 +屬性”定位配置項(xiàng)。例如，可以表達(dá)某個(gè) EVSE 的可用狀態(tài)、某個(gè)計(jì)量器的采樣配置，或者顯示組件的能力。

設(shè)備模型帶來的工程價(jià)值包括：

能通過基礎(chǔ)報(bào)告發(fā)現(xiàn)設(shè)備支持的組件和變量；

可以描述變量類型、單位、上下限、可讀寫性和監(jiān)控能力；

支持設(shè)置變量監(jiān)控，在閾值觸發(fā)或數(shù)值變化時(shí)上報(bào)；

多EVSE、多連接器和復(fù)雜硬件的層次更清晰。

但設(shè)備模型也明顯增加了平臺(tái)復(fù)雜度。平臺(tái)需要保存設(shè)備報(bào)告、變量定義、屬性值、監(jiān)控規(guī)則和廠商擴(kuò)展，并處理報(bào)告分片與版本變化。它不是把GetConfiguration 改名為GetVariables 就能完成的升級(jí)。

五、安全能力的差異OCPP 1.6

1.6 項(xiàng)目可以使用 TLS、HTTP BasicAuthentication和客戶端證書，但不同設(shè)備的實(shí)現(xiàn)完整度差異較大。部分安全能力來自后續(xù)發(fā)布的安全白皮書或安全擴(kuò)展，而不是Zui初消息集合中的完整閉環(huán)。

因此，1.6平臺(tái)經(jīng)常遇到以下問題：

設(shè)備長(zhǎng)期使用固定密碼；

證書申請(qǐng)、安裝、更新和吊銷依賴人工；

安全事件缺少統(tǒng)一的上報(bào)方式；

固件簽名校驗(yàn)和安全升級(jí)由廠商私有實(shí)現(xiàn)。

OCPP 2.0.1

2.0.1將安全能力納入?yún)f(xié)議主體設(shè)計(jì)，包括安全配置、證書管理、簽名固件、安全事件通知和安全日志等。平臺(tái)可以通過協(xié)議完成證書簽發(fā)請(qǐng)求、安裝、刪除和清單查詢。

工程上仍需注意：協(xié)議支持安全功能，不代表部署后自動(dòng)安全。CSMS還需要建設(shè)設(shè)備身份、PKI、證書生命周期、密鑰保護(hù)、固件簽名、審計(jì)和告警響應(yīng)體系。

OCPP 2.1

2.1 繼承 2.0.1的安全基礎(chǔ)，同時(shí)增加安全動(dòng)態(tài)二維碼等與臨時(shí)支付相關(guān)的能力。由于 2.1涉及雙向能量流和更多支付場(chǎng)景，授權(quán)邊界、指令審計(jì)和金額校驗(yàn)的重要性進(jìn)一步提高。

無論選擇哪個(gè)版本，都不建議關(guān)閉服務(wù)端證書校驗(yàn)，也不應(yīng)把設(shè)備序列號(hào)直接當(dāng)成長(zhǎng)期憑證。

六、智能充電與能源協(xié)同OCPP 1.6：基礎(chǔ)充電曲線

1.6 通過SetChargingProfile、ClearChargingProfile 和 GetCompositeSchedule 支持基礎(chǔ)智能充電。平臺(tái)可以設(shè)置功率或電流上限，實(shí)現(xiàn)單樁限功率、站級(jí)負(fù)載均衡和分時(shí)控制。

其局限在于，設(shè)備能力、外部限制、車輛需求和電網(wǎng)約束的表達(dá)相對(duì)有限。不同廠商對(duì)多個(gè)Profile 的疊加、優(yōu)先級(jí)和離線執(zhí)行也可能存在差異。

OCPP 2.0.1：更細(xì)的計(jì)劃與約束

2.0.1 擴(kuò)展了智能充電數(shù)據(jù)結(jié)構(gòu)，可以更清晰地交換充電需求、充電計(jì)劃、網(wǎng)絡(luò)限制和功率調(diào)度信息，并與ISO 15118 場(chǎng)景配合。適合在站級(jí)能源管理系統(tǒng)與 CSMS 之間建立更穩(wěn)定的控制邊界。

OCPP 2.1：雙向充電與 DER 控制

2.1 新增雙向充電功能塊和 DER Control功能塊，并支持 ISO 15118-20 的雙向功率傳輸。這意味著車輛和充電設(shè)施不僅是負(fù)載，也可能作為可控能源資源參與 V2H、V2B或 V2G 場(chǎng)景。

對(duì)平臺(tái)而言，數(shù)據(jù)模型要從“允許充多少電”擴(kuò)展到：

當(dāng)前允許輸入或輸出多少有功功率；

無功功率、功率因數(shù)等目標(biāo)如何下發(fā)；

車輛電量需求、離站時(shí)間和可用能量如何參與計(jì)劃；

電網(wǎng)、站級(jí) EMS、CSMS與車輛之間的控制優(yōu)先級(jí)如何協(xié)調(diào)；

雙向交易的計(jì)量、費(fèi)用和結(jié)算如何區(qū)分。

這類能力不能只由 OCPP服務(wù)單獨(dú)完成，還需要充電設(shè)備、車輛、ISO 15118 通信、計(jì)量系統(tǒng)和能源管理系統(tǒng)共同支持。

七、ISO 15118 與即插即充

OCPP 1.6 沒有完整覆蓋 ISO 15118證書生命周期。項(xiàng)目通常通過廠商擴(kuò)展對(duì)接即插即充，平臺(tái)之間的實(shí)現(xiàn)差異較大。

OCPP 2.0.1 增加 ISO 15118相關(guān)支持，包括證書管理和 Plug & Charge 所需的后臺(tái)協(xié)作能力。CSMS可以參與合同證書鏈處理，而不是把全部證書邏輯留在設(shè)備私有接口中。

OCPP 2.1 進(jìn)一步支持 ISO15118-20，并把雙向功率傳輸納入?yún)f(xié)議能力。需要強(qiáng)調(diào)的是：支持 OCPP 2.1 不等于設(shè)備自動(dòng)具備 ISO 15118-20 或V2G 能力。硬件、電力電子模塊、車輛通信棧、計(jì)量和認(rèn)證范圍都必須同時(shí)滿足要求。

八、費(fèi)用、支付與用戶交互

在 OCPP 1.6 中，價(jià)格計(jì)算和支付一般由 CSMS或外部支付系統(tǒng)負(fù)責(zé)。充電樁主要上傳電量和交易數(shù)據(jù)。屏幕價(jià)格、支付終端、臨時(shí)用戶支付等能力通常依賴 DataTransfer或廠商擴(kuò)展。

2.0.1增強(qiáng)了顯示消息、價(jià)格信息和交易處理能力，使平臺(tái)可以更規(guī)范地向充電站提供用戶提示和費(fèi)用相關(guān)信息。

2.1 增加了更多交易與支付選項(xiàng)：

支持固定費(fèi)用、固定能量或固定時(shí)長(zhǎng)的交易目標(biāo)；

支持充電站本地費(fèi)用計(jì)算；

支持預(yù)付卡余額約束；

支持內(nèi)置或獨(dú)立銀行卡終端的臨時(shí)支付；

支持安全動(dòng)態(tài)二維碼用于臨時(shí)支付。

本地費(fèi)用計(jì)算并不意味著平臺(tái)可以放棄賬單服務(wù)。平臺(tái)仍要保存計(jì)費(fèi)規(guī)則版本、設(shè)備計(jì)算結(jié)果、計(jì)量數(shù)據(jù)、稅費(fèi)與平臺(tái)復(fù)算結(jié)果，并對(duì)差異進(jìn)行處理。

九、OCPP 2.1 新增的換電能力

OCPP 2.1增加了對(duì)兩輪車、三輪車和電動(dòng)汽車換電站的支持。這是 2.1 與前兩個(gè)版本相比很容易被忽視的變化。

傳統(tǒng)充電交易圍繞 EVSE 和 Connector展開；換電業(yè)務(wù)則需要管理電池身份、倉位、庫存、充電狀態(tài)、取出和歸還過程。平臺(tái)實(shí)現(xiàn)時(shí)還要關(guān)注：

電池與用戶、車輛、倉門的綁定關(guān)系；

換出與換入電池的狀態(tài)和計(jì)量信息；

電池健康度、溫度和循環(huán)次數(shù)；

換電訂單異常恢復(fù)；

電池資產(chǎn)調(diào)撥與全生命周期記錄。

協(xié)議提供標(biāo)準(zhǔn)交互基礎(chǔ)，但完整的換電運(yùn)營(yíng)仍需要資產(chǎn)、訂單、計(jì)費(fèi)和運(yùn)維系統(tǒng)配合。

十、消息兼容性與接入層設(shè)計(jì)1.6與 2.x 不能直接互通

差異不僅體現(xiàn)在消息名，還包括枚舉、標(biāo)識(shí)類型、設(shè)備層次和交易狀態(tài)機(jī)。例如：

OCPP1.6

OCPP2.x

ChargePoint	ChargingStation
connectorId 為主要設(shè)備位置標(biāo)識(shí)	EVSE.id + connectorId
idTag	idToken
StartTransaction/StopTransaction	TransactionEvent
GetConfiguration	GetVariables
ChangeConfiguration	SetVariables
DiagnosticsStatusNotification	更細(xì)的日志狀態(tài)及相關(guān)消息

建議使用協(xié)議適配層隔離差異：

展開

代碼語言：JavaScript

自動(dòng)換行

AI代碼解釋

WebSocket 接入
 -> 子協(xié)議協(xié)商
 -> OCPP 1.6 / 2.0.1 / 2.1
 -> Schema 校驗(yàn)
 -> 版本專屬狀態(tài)機(jī)
 -> 統(tǒng)一領(lǐng)域事件
 -> 訂單、設(shè)備、計(jì)費(fèi)、運(yùn)維服務(wù)

WebSocket 握手應(yīng)使用對(duì)應(yīng)的 OCPP子協(xié)議標(biāo)識(shí)。服務(wù)器不能僅根據(jù)報(bào)文內(nèi)容猜測(cè)版本，也不應(yīng)允許連接建立后在同一會(huì)話中切換協(xié)議。

2.x 的兼容也需要協(xié)商

OCPP 2.1 盡量保持 2.0.1應(yīng)用邏輯可延續(xù)，但新增類型和功能仍要求雙方明確支持范圍。推薦在設(shè)備檔案中記錄：

協(xié)議版本及規(guī)范修訂版；

支持的功能塊；

設(shè)備模型報(bào)告版本；

安全配置和證書狀態(tài)；

ISO15118、雙向充電、DER、支付及換電能力；

已通過的一致性測(cè)試范圍。

平臺(tái)下發(fā)命令前，應(yīng)以設(shè)備實(shí)際上報(bào)和經(jīng)過驗(yàn)證的能力為準(zhǔn)，而不是只看型號(hào)說明。

十一、如何選擇協(xié)議版本繼續(xù)使用 OCPP 1.6 的情況

以下場(chǎng)景不一定需要立即升級(jí)：

已有大量穩(wěn)定運(yùn)行的 1.6 設(shè)備；

業(yè)務(wù)主要是啟動(dòng)、停止、計(jì)量、狀態(tài)和基礎(chǔ)負(fù)載均衡；

設(shè)備硬件不支持 ISO 15118或復(fù)雜安全能力；

短期內(nèi)沒有V2G、換電和現(xiàn)場(chǎng)支付需求。

此時(shí)應(yīng)優(yōu)先補(bǔ)齊TLS、憑證輪換、日志審計(jì)、離線交易、冪等處理和廠商擴(kuò)展治理，而不是為了版本號(hào)強(qiáng)行升級(jí)。

新項(xiàng)目選擇 OCPP 2.0.1 的情況

2.0.1適合需要以下能力的新建項(xiàng)目：

標(biāo)準(zhǔn)化設(shè)備管理和變量監(jiān)控；

更完整的安全與證書生命周期；

穩(wěn)健的交易事件模型；

Plug & Charge 與 ISO 15118協(xié)作；

更細(xì)的智能充電和用戶顯示能力。

選擇設(shè)備時(shí)，應(yīng)同時(shí)考察協(xié)議實(shí)現(xiàn)完整度、測(cè)試報(bào)告和功能塊范圍，不能只確認(rèn)“支持 OCPP2.0.1”。

選擇 OCPP 2.1 的情況

若項(xiàng)目明確涉及以下方向，可以優(yōu)先評(píng)估2.1：

ISO 15118-20；

雙向充電和 V2X；

DER 與站級(jí)能源系統(tǒng)協(xié)同；

現(xiàn)場(chǎng)銀行卡或動(dòng)態(tài)二維碼支付；

本地費(fèi)用計(jì)算和預(yù)付卡；

兩輪車、三輪車或汽車換電。

由于 2.1較新，設(shè)備、測(cè)試工具、證書體系和互操作經(jīng)驗(yàn)仍需逐項(xiàng)確認(rèn)。項(xiàng)目可以采用“平臺(tái)先支持、設(shè)備按能力逐步接入”的方式，避免把所有新增功能綁定在同一期上線。

十二、從 1.6 遷移到 2.x的實(shí)施建議第一階段：雙協(xié)議接入

保留現(xiàn)有 1.6 鏈路，新建 2.x接入服務(wù)。統(tǒng)一連接認(rèn)證、會(huì)話管理、心跳、原始報(bào)文存儲(chǔ)和指標(biāo)監(jiān)控，但版本專屬 Schema 和狀態(tài)機(jī)保持隔離。

第二階段：建立統(tǒng)一領(lǐng)域模型

把connectorId、EVSE、Connector、idTag、idToken、整數(shù)交易號(hào)和字符串交易號(hào)映射為平臺(tái)內(nèi)部穩(wěn)定標(biāo)識(shí)。不要直接復(fù)用某個(gè)版本的 DTO作為數(shù)據(jù)庫核心模型。

第三階段：重構(gòu)交易和設(shè)備中心

將訂單處理改造成事件驅(qū)動(dòng)狀態(tài)機(jī)，支持亂序、重復(fù)、斷網(wǎng)補(bǔ)傳和重啟恢復(fù)。設(shè)備中心增加組件、變量、屬性、監(jiān)控規(guī)則和能力報(bào)告存儲(chǔ)。

第四階段：建設(shè)安全基礎(chǔ)設(shè)施

部署設(shè)備證書和 Plug & Charge 所需的PKI 能力，建立證書申請(qǐng)、簽發(fā)、安裝、輪換、吊銷和審計(jì)流程。簽名固件和安全事件應(yīng)進(jìn)入統(tǒng)一安全運(yùn)營(yíng)體系。

第五階段：按需開放gaoji功能

智能充電、ISO 15118、現(xiàn)場(chǎng)支付、雙向充電、DER和換電應(yīng)分別進(jìn)行互操作測(cè)試。不要用一次簡(jiǎn)單的遠(yuǎn)程啟動(dòng)成功，代替完整協(xié)議能力驗(yàn)證。

十三、常見誤區(qū)

誤區(qū)一：OCPP 2.0.1 只是OCPP 1.6 增加了一些消息。 事實(shí)上，設(shè)備模型和交易模型已經(jīng)發(fā)生結(jié)構(gòu)性變化。

誤區(qū)二：支持 OCPP 2.1就等于支持 V2G。 協(xié)議只是必要條件之一，還需要車輛、充電設(shè)備、電網(wǎng)接口和計(jì)量結(jié)算能力。

誤區(qū)三：?jiǎn)⒂?TLS就完成了安全建設(shè)。 證書生命周期、設(shè)備身份、固件簽名、密鑰保護(hù)和安全審計(jì)同樣重要。

誤區(qū)四：設(shè)備聲稱支持某版本，就支持該版本全部功能。OCPP按功能塊實(shí)施，應(yīng)核對(duì)具體能力與一致性測(cè)試范圍。

誤區(qū)五：升級(jí)時(shí)可以直接復(fù)用原數(shù)據(jù)庫字段。2.x 的EVSE、字符串交易標(biāo)識(shí)、設(shè)備模型和事件序號(hào)通常要求重新設(shè)計(jì)核心數(shù)據(jù)結(jié)構(gòu)。

結(jié)語

OCPP 1.6 的價(jià)值在于成熟和廣泛部署；OCPP2.0.1 的核心價(jià)值是重新建立設(shè)備管理、交易和安全基礎(chǔ)；OCPP 2.1則把協(xié)議進(jìn)一步擴(kuò)展到雙向能源、DER、現(xiàn)場(chǎng)支付和換電場(chǎng)景。

技術(shù)選型不應(yīng)只比較版本號(hào)，而應(yīng)從設(shè)備能力、業(yè)務(wù)目標(biāo)、安全要求、能源場(chǎng)景和運(yùn)維成本出發(fā)。對(duì)于需要兼容存量設(shè)備的平臺(tái)，較穩(wěn)妥的方案不是一次性替換1.6，而是建立多版本接入層和統(tǒng)一領(lǐng)域模型，再讓新設(shè)備與gaoji功能逐步遷移到 2.x。