Strateginis OCPP 1.6J ir 2.0.1 palyginimas komercinių įkrovimo stočių operatoriams

Galutinis strateginis OCPP 1.6J ir 2.0.1 palyginimas pasauliniams komerciniams įkrovimo operatoriams: tinklo mastelio keitimo, pažangaus kibernetinio saugumo, ISO 15118 integravimo ir ilgalaikės infrastruktūros ateities užtikrinimo tvariam elektromobilių augimui įvaldymas.

Santrauka

Elektromobilių (EV) įkrovimo aplinka išgyvena seisminius pokyčius. Spartėjant pasauliniam naudojimui, pagrindiniai ryšio protokolai, reglamentuojantys elektromobilių tiekimo įrangos (EVSE) ir įkrovimo stotelių valdymo sistemų (CSMS) sąveiką, tapo komercinių įkrovimo operatorių (CPO) techninės strategijos pagrindiniu elementu. Atvirojo įkrovimo taškų protokolas (OCPP), kurį palaiko „Open Charge Alliance“ (OCA), iš paprastos pranešimų siuntimo sistemos išsivystė į sudėtingą, saugų ir labai keičiamo mastelio standartą.

Šiame vadove pateikiama išsami techninė perėjimo nuo OCPP 1.6J prie OCPP 2.0.1 analizė. Nagrinėjame architektūrinius skirtumus, saugumo patobulinimus, įrenginių valdymo paradigmas ir svarbų ISO 15118 integracijos vaidmenį. Pirkėjams ir operatoriams šis straipsnis yra pagrindinis šaltinis priimant pagrįstus pirkimo ir perkėlimo sprendimus sparčiai besivystančioje rinkoje.

1 skyrius: Elektromobilių įkrovimo standartų evoliucija: istorinis kontekstas

Atvirojo įkrovimo taškų protokolas (OCPP) gimė iš poreikio užtikrinti sąveikumą. Elektromobilių įkrovimo pradžioje techninės ir programinės įrangos gamintojai naudojo patentuotus protokolus, kurdami „uždarytus sodus“, kurie slopino konkurenciją ir inovacijas. OCPP 1.2 ir 1.5 įdiegimas padėjo pamatus, tačiau iš tikrųjų OCPP 1.6 suvienijo pramonę.

1.1 OCPP 1.6J dominavimas

2015 m. išleista OCPP 1.6 versija pristatė JSON per „WebSockets“ (1.6J) diegimą. Šis atsisakymas nuo SOAP pagrįsto pranešimų siuntimo žymiai sumažino kūrėjų išlaidas ir supaprastino diegimą. Ji pristatė tokias funkcijas kaip išmanusis įkrovimas ir papildomi būsenos pranešimai, todėl beveik dešimtmetį tapo pramonės standartu.

1.2 OCPP 2.0.1 atsiradimas

Nepaisant 1.6J sėkmės, pramonės augimas atskleidė jos apribojimus. Saugumo problemos, įrenginių valdymo sudėtingumas ir vietinės pažangios tinklo integracijos (V2G) palaikymo stoka paskatino sukurti OCPP 2.0, o vėliau ir patobulintą OCPP 2.0.1 (išleistą 2020 m.). OCPP 2.0.1 yra ne tik atnaujinimas; tai visiškas pertvarkymas, skirtas palaikyti naujos kartos didelės galios, išmanius ir saugius įkrovimo tinklus.

2 skyrius: Pagrindinės komunikacijos paradigmos: JSON, „WebSockets“ ir rėminės struktūros

Norint suprasti šių protokolų skirtumą, reikia pažvelgti į žemo lygio komunikaciją. Abu protokolai naudoja JSON per „WebSockets“, tačiau šių pranešimų struktūra ir apdorojimas labai skiriasi.

2.1 „WebSocket“ sluoksnis

Abi versijos naudoja nuolatinius „WebSocket“ ryšius, kurie leidžia užtikrinti dvipusį ryšį. Tai labai svarbu realiuoju laiku vykdomoms operacijoms, pavyzdžiui, įkrovimo sesijos sustabdymui mobiliojoje programėlėje arba momentinių gedimų įspėjimų gavimui.

2.2 Pranešimų rėmelių suskirstymas

Tipinį OCPP pranešimą sudaro pranešimo tipo ID, unikalus pranešimo ID, veiksmo pavadinimas ir naudingoji apkrova.

OCPP 1.6J rėmelio pavyzdys (BootNotification)

„json [2, „123456“, „Įkrovos pranešimas“, { „chargePointVendor“: „MidaPower“, „chargePointModel“: „Terra-X“, „chargePointSerialNumber“: „SN001“, „firmwareVersion“: „v1.2.3“ }]„

OCPP 2.0.1 rėmelio pavyzdys (BootNotification)

„json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Atkreipkite dėmesį į padidintą detalumą 2.0.1 versijoje.„reason“ laukas leidžia CSMS sistemai suprasti, ar paleidimas įvyko dėl perkrovimo, įjungimo ar stebėjimo funkcijos suveikimo, todėl pagerėja diagnostikos logika.

3 skyrius: Architektūrinės paradigmos pokytis: įrenginio modelis

Reikšmingiausias techninis nukrypimas OCPP 2.0.1 versijoje yra įvedimasĮrenginio modelis.

3.1 1.6J konfigūracijos raktų apribojimai

OCPP 1.6J versijoje aparatinės įrangos konfigūracija buvo valdoma naudojant išlyginamąjį „konfigūracijos raktų“ sąrašą (pvz.,Širdies plakimo intervalas, Ryšio skirtasis laikas). Įkrovikliams tampant sudėtingesniems (daugialypės jungtys, integruoti maitinimo moduliai, sudėtingos aušinimo sistemos), šis plokščias sąrašas tapo nevaldomas. Nebuvo standartizuoto būdo apibūdinti fizinės stoties hierarchijos.

3.2 2.0.1 įrenginio modelio metodas

OCPP 2.0.1 versijoje pristatomas hierarchinis modelis, kurį sudaroKomponentaiirKintamiejiKomponentas gali būti „valdiklis“, „jungtis“ arba „maitinimo modulis“. Kiekvienas komponentas turi kintamuosius, kurie nurodo jo būseną arba konfigūraciją (pvz.,Temperatūra, Įtampa, Maksimali srovė).

• KomponentasĮkrovimo stoties fizinė arba loginė dalis.
• Kintamasis: Konkretus to komponento atributas.
• CharakteristikosMetaduomenys, apibūdinantys kintamąjį (vienetas, diapazonas, prieigos tipas).

Tai leidžia standartizuoti stebėjimą. Operatorius dabar gali pateikti užklausą apie konkretaus maitinimo modulio temperatūrą naudodamas standartizuotą kelią, o ne pasikliauti konkrečiam tiekėjui skirtais nuosavybės teise priklausančiais raktais.

4 skyrius: Kibernetinis saugumas: nuo „geriausių pastangų“ iki privalomo TLS

Elektromobilių įkrovimo pradžioje saugumas dažnai buvo antraeilis dalykas. OCPP 1.6J siūlė saugumo profilius, tačiau jų įgyvendinimas tarp tiekėjų buvo nenuoseklus.

4.1 Apsaugos profiliai 1.6J versijoje

OCPP 1.6J apibrėžė tris saugumo profilius:

1. NeapsaugotasPaprasto teksto HTTP/WebSockets.
2. Pagrindinis autorizavimasTLS su vartotojo vardu/slaptažodžiu.
3. Sertifikatų pagrinduTLS su kliento pusės sertifikatais.

Problema buvo ta, kad daugelis įkroviklių liko 1 profilyje, todėl jie buvo pažeidžiami tarpininkavimo (MITM) atakų ir neteisėtos kontrolės.

4.2 Sugriežtinta 2.0.1 versijos pozicija

OCPP 2.0.1 užtikrina saugų ryšį. Jame integruotos pažangios saugumo funkcijos:

• Saugūs programinės įrangos atnaujinimaiPrivalomas programinės įrangos atvaizdų pasirašymas ir patikrinimas.
• Saugumo registravimasIšsamūs su saugumu susijusių įvykių žurnalai (pvz., nepavykę prisijungimo bandymai, sertifikato galiojimo pabaiga).
• Sertifikatų valdymasStandartizuoti pranešimai apie rotuotus ir atnaujintus sertifikatus (CSMS arba stoties vadovaujami).
• TLS 1.2/1.3: Palaikomi naujausi šifravimo standartai.

Komerciniams operatoriams tai sumažina didelio masto tinklo pažeidimų riziką ir užtikrina atitiktį naujiems kibernetinio saugumo reglamentams, taikomiems daiktų interneto įrenginiams.

5 skyrius: ISO 15118 integravimas: „Plug & Charge“ ir V2G

Elektromobilių įkrovimo ateitis – tai ne tik elektronų perkėlimas; tai išmanus duomenų ir energijos mainai. ISO 15118 yra tarptautinis transporto priemonių ir elektros tinklo (V2G) ryšio standartas, o jo integravimas su OCPP yra esminis 2.0.1 bruožas.

5.1 „Plug & Charge“ sudėtingumas

„Plug & Charge“ (PnC) leidžia vairuotojui tiesiog prijungti transporto priemonę prie elektros tinklo ir pradėti krauti nenaudojant programėlės ar RFID kortelės. Tam reikalinga sudėtinga viešojo rakto infrastruktūra (PKI), apimanti transporto priemonę, įkroviklį, operatorių ir tarpininką.

OCPP 1.6J versijoje baziniame protokole nebuvo PnC palaikymo. Tiekėjai turėjo įdiegti pasirinktinius plėtinius, dėl kurių kilo fragmentacija. OCPP 2.0.1 suteikia PnC „santechniką“, palaikydama:

• Sertifikato diegimasSutarčių sertifikatų perdavimas iš CSMS į EV per EVSE.
• AutorizacijaNaudojant iš transporto priemonės sertifikato gautą e-Mobility ID (eMAID).
• Užšifruotas ryšysUžtikrinant, kad tarp automobilio ir tinklo perduodami jautrūs atsiskaitymo duomenys būtų apsaugoti.

5.2 Išmanusis įkrovimas ir apkrovos balansavimas

Nors 1,6 J palaikė pagrindinį išmanųjį įkrovimą (siuntėNustatyti įkrovimo profilį), 2.0.1 versija tai pakelia į aukštesnį lygį. Ji leidžia:

• Išorinio signalo integravimasReagavimas į tinklo dažnio arba didmeninių kainų signalus realiuoju laiku.
• Dinaminis apkrovos valdymasDetalesnė energijos paskirstymo kontrolė objekte su šimtais jungčių.
• Transporto priemonės ir elektros tinklo (V2G)2.0.1 versijoje yra būtini duomenų laukai, skirti dvikrypčiam energijos srautui palaikyti, leidžiant elektromobiliams veikti kaip paskirstytiesiems energijos ištekliams (DER) tinkle.

5.3 Vartotojo sąsajos / UX patobulinimai

OCPP 2.0.1 palaiko informacijos rodymą tiesiai įkroviklio ekrane arba transporto priemonės prietaisų skydelyje, pavyzdžiui:

• Kainodara realiuoju laiku vietine valiuta.
• Numatomas laikas pasiekti 80 % įkrovos būseną (SoC).
• Išsami informacija apie kvitą, kai jis bus užpildytas.

6 skyrius: Išplėstinis įrenginių valdymas ir stebėjimas

Įkroviklio savininkui (CPO) įkroviklio kaina yra ne tik pirkimo kaina, bet ir bendros eksploatavimo išlaidos (TCO). Priežiūra ir prastovos yra didžiausi pelno žudikai. OCPP 2.0.1 šią problemą sprendžia užtikrindama pranašesnes stebėjimo galimybes.

6.1 Įvykiais pagrįstas ataskaitų teikimas

1.6J modelyje CSMS paprastai turėjo apklausti įkroviklį apie būseną arba laukti atsakymo.Būsenos pranešimas2.0.1 versijojeĮvykių stebėjimasSistema leidžia CSMS nustatyti slenksčius. Pavyzdžiui: „Pranešti man tik tada, kai vidinė temperatūra viršija 70 °C“ arba „Pranešti, jei įėjimo įtampa nukrenta žemiau 200 V“. Tai sumažina tinklo apkrovą ir leidžia atlikti aktyvią priežiūrą.

6.2 Operacijų tvarkymas: „TransactionEvent“

Vienas labiausiai kritikuojamų OCPP 1.6J aspektų buvo operacijų apdorojimas. Viena sesija, kurioje dalyvavoPradėti operacijąirStopTransactionpranešimus, tačiau nutrūkus tinklui, CSMS dažnai sunkiai sekėsi suderinti atsiskaitymo duomenis.

OCPP 2.0.1 pakeičia juos vienu, patikimuOperacijos įvykispranešimas. Šis pranešimas naudojamas visiems sandorio gyvavimo ciklo etapams (pradėtam, atnaujintam, užbaigtam) pranešti. Jame yra unikalusoperacijos IDkuris išlieka net ir įkrovikliui persikrovus, užtikrinant, kad neprarandami jokie įkrovimo duomenys – taigi ir pajamos.

6.3 Patobulinta diagnostika ir trikčių šalinimas

TheGauti žurnaląirDiagnostikos būsenos pranešimas2.0.1 versijos pranešimai yra labiau struktūrizuoti. Duomenų valdytojai (CPO) gali prašyti konkrečių tipų žurnalų (saugos, diagnostikos, vartotojo) ir nurodyti laiko intervalą. Tai leidžia nuotolinėms pagalbos komandoms išspręsti problemas nesiunčiant techniko į vietą, o tai žymiai sumažina veiklos sąnaudas.

7 skyrius: Programinės įrangos atnaujinimo mechanizmai: patikimumas ir atšauktos versijos

Programinės įrangos atnaujinimai yra besivystančios aparatinės įrangos gyvybės šaltinis, tačiau nepavykęs atnaujinimas gali sugadinti įkroviklį.

7.1 1.6J atnaujinimo procesas

1,6 J variklyjeAtnaujinti programinę įrangąKomanda buvo gana paprasta. Įkroviklis atsisiųsdavo atvaizdą ir bandydavo jį įdiegti. Nebuvo standartizuoto mechanizmo daugiapakopiams atnaujinimams ar patvirtintiems atšaukimams.

7.2 2.0.1 versijos kelių pakopų atnaujinimas

OCPP 2.0.1 pristato sudėtingesnį programinės įrangos atnaujinimų gyvavimo ciklą:

1. AtsisiųstiĮkroviklis nuskaito vaizdą ir patikrina jo kontrolinę sumą / parašą.
2. Įrengimas: Atnaujinimas taikomas antriniam skaidiniui.
3. PatvirtinimasSistema patikrina, ar nauja programinė įranga paleidžiama teisingai.
4. Aktyvinimas: Pagrindinis skaidinys yra perjungtas.

Jei kuris nors žingsnis nepavyksta, protokolas apibrėžia, kaip įkroviklis turėtų grįžti prie ankstesnės stabilios versijos ir pranešti konkretų gedimo kodą CSMS. Šis patikimumo lygis yra nekeičiamas didelio masto komerciniams diegimams.

7.3 Parašo tikrinimas

Siekiant užkirsti kelią kenkėjiškų veikėjų įsikėlimui į pažeistą programinę įrangą, 2.0.1 versijoje reikalaujama naudoti skaitmeninius parašus. Įkroviklis atsisakys vykdyti bet kokį kodą, nepasirašytą gamintojo privačiuoju raktu, taip suteikdamas svarbų apsaugos nuo aparatinės įrangos lygio įsilaužimų sluoksnį.

8 skyrius: Duomenų privatumas, atitiktis reglamentams ir BDAR

Elektromobilių įkrovimui tampant kasdiene paslauga, generuojamų asmens duomenų kiekis stulbina. Vieno įkrovimo seanso metu galima susieti naudotojo tapatybę, jo transporto priemonės buvimo vietą, kelionių įpročius ir finansinę informaciją.

8.1 Asmeniškai identifikuojama informacija (PII) OCPP sistemoje

Atsižvelgiant į Bendrąjį duomenų apsaugos reglamentą (BDAR) Europoje ir panašius įstatymus, tokius kaip CCPA Kalifornijoje, tokie duomenų taškai kaipidTag(RFID) arbaEVCCID(Transporto priemonės identifikatorius) laikomi asmenine asmenine informacija.

OCPP 2.0.1 suteikia geresnes duomenų anonimizavimo valdymo priemones. Pavyzdžiui,Pasirinktiniai duomenyslaukai leidžia operatoriams saugoti metaduomenis neatskleidžiant asmeninių duomenų pagrindinio protokolo žurnalams. Be to, patobulinti saugumo profiliai užtikrina, kad šie duomenys būtų šifruojami tiek perdavimo, tiek saugojimo metu.

8.2 Teisė būti pamirštam ir duomenų perkeliamumas

Struktūrizuotas 2.0.1 įrenginio modelio pobūdis palengvina CSMS teikėjams „duomenų ištrynimo“ užklausų įgyvendinimą. 1.6J sistemoje visų vartotojo ID egzempliorių paieška skirtinguose konfigūracijos raktuose ir žurnaluose buvo tikras košmaras rankiniu būdu. 2.0.1 versijoje aiškus įrenginio būsenos ir operacijų duomenų atskyrimas leidžia sukurti švaresnę duomenų bazės architektūrą.

8.3 Daiktų interneto saugumo įstatymų laikymasis

Daugelyje regionų šiuo metu priimami įstatymai, reikalaujantys, kad daiktų interneto įrenginiai turėtų unikalius slaptažodžius ir saugius atnaujinimo mechanizmus. Privalomas OCPP 2.0.1 TLS ir pasirašyta programinė įranga yra ne tik „malonu turėti“ funkcijos – tai teisiniai reikalavimai parduodant aparatinę įrangą tokiose rinkose kaip Kalifornija ir JK.

9 skyrius: Pirkėjo perspektyva: bendrosios nuosavybės kainos (TCO), investicijų grąža (ROI) ir strateginė migracija

Komercinio įkrovimo operatoriaus sprendimas rinktis – ar laikytis 1,6 J, ar pereiti prie 2.0.1 – yra finansinis.

9.1 Įgyvendinimo kaina

• OCPP 1.6JPigu įdiegti, plačiai palaikoma nebrangios įrangos, tačiau yra didelių paslėptų priežiūros išlaidų ir saugumo rizikos.
• OCPP 2.0.1Reikalingi galingesni procesoriai ir daugiau atminties EVSE. CSMS kūrimo išlaidos yra didesnės dėl protokolo sudėtingumo. Tačiau jis suteikia galimybę gerokai sutaupyti eksploatavimo išlaidas dėl nuotolinio valdymo ir didesnio patikimumo.

9.2 Mitas apie „sklandžią atnaujinimą“

Dažnai sakoma, kad 1.6J įkroviklius galima atnaujinti iki 2.0.1 versijos programinės įrangos pagalba. Iš tikrųjų tai retai kada pasitvirtina. 2.0.1 versijos atminties ir procesoriaus reikalavimai (ypač TLS sertifikatų tvarkymas ir sudėtingas įrenginio modelio JSON analizavimas) dažnai viršija senesnių 1.6J valdiklių galimybes.

9.3 Strateginiai migracijos keliai

CPO turėtų apsvarstyti „hibridinio tinklo“ metodą:

1. Senos svetainėsToliau naudoti 1,6 J esamus mažos galios kintamosios srovės įkroviklius.
2. Naujos nuolatinės srovės greitojo įkrovimo aikštelės: 2.0.1 įgaliojimas visiems naujiems didelio galingumo diegimams, siekiant palaikyti PnC ir V2G.
3. Tarpinio serverio sprendimaiNaudokite protokolo šliuzą, kuris gali išversti 1.6J pranešimus į 2.0.1 suderinamą formatą CSMS sistemai, taip sukurdamas vieną vieningą valdymo ataskaitų suvestinę.

10 skyrius: Ateities užtikrinimas: OCPP 2.1 ir kelias į autonominį įkrovimą

Net ir 2.0.1 versijai įgaunant populiarumo, „Open Charge Alliance“ jau dirba su OCPP 2.1. Ši būsima versija dar labiau išplės protokolo pasiekiamumą.

10.1 Dvikryptis įkrovimas (V2X)

Nors 2.0.1 versija palaiko bazinį V2G ryšį, 2.1 versija patobulins ryšį tarp transporto priemonės ir namų (V2H) ir transporto priemonės ir pastato (V2B), leisdama elektromobiliams maitinti namus elektros energijos tiekimo nutraukimo metu arba sumažinti komercinių pastatų didžiausią paklausą.

10.2 Belaidžio įkrovimo palaikymas

Atsiradus autonominėms transporto priemonėms (AV), rankinis įkrovimas taps nebeaktualus. OCPP 2.1 apims standartizuotus indukcinio (belaidžio) įkrovimo pranešimus, suderinimo valdymą ir energijos perdavimą be žmogaus įsikišimo.

10.3 Integracija su išmaniaisiais miestais

Tikėtina, kad būsimose versijose bus gilesnė integracija su eismo valdymo sistemomis ir atsinaujinančios energijos prognozėmis. Įkrovikliai galės „teikti pasiūlymus“ dėl energijos realaus laiko energijos rinkose, paversdami įkrovimo tinklus didžiulėmis virtualiomis elektrinėmis (VPP).

Techninis priedas: Išsamus pranešimų palyginimas

Siekdami pateikti išsamų techninį išsamumą, dabar analizuosime konkrečias pranešimų sekas ir kadrų skirtumus tarp dviejų versijų.

A.1 Autorizacijos srautas

1.6J versijoje autorizacija buvo dvejetainis atsakymas „Priimta“ arba „Užblokuota“.

1.6J Autorizacijos atsakymas:„json [3, "123456", { "idTagInfo": { "status": "Priimta", "expiryDate": "2026-12-31T23:59:59Z" } }]„

2.0.1 versijoje atsakyme pateikiama daugiau konteksto, pavyzdžiui,idTokentipas ir papildoma informacija apie vartotojo sąsają.

2.0.1 Autorizacijos atsakas:„json [3, "987654", { "idTokenInfo": { "status": "Priimta", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Sveikas sugrįžęs, Jonai! Jūsų likutis yra 45,00 USD" } } }]„

A.2 Širdies ritmo ir ryšio valdymas

OCPP 2.0.1 optimizuoja, kaip stotis įrodo, kad yra „gyva“. 1,6 J atveju, jei aŠirdies plakimasnepavykus, stotis dažnai tiesiog bandydavo dar kartą. 2.0.1 versijoje stotis gali naudotiPranešti apie įvykįmechanizmas, kuris praneša apie prarastą ryšį su antrine serveriu, tuo pačiu išlaikydamas ryšį su pagrindiniu serveriu.

A.3 Išsami metaduomenų lentelė

Išvada

Perėjimas nuo OCPP 1.6J prie 2.0.1 yra ne tik programinės įrangos atnaujinimas; tai esminė elektromobilumo ekosistemos evoliucija. Komerciniams operatoriams 1.6J simbolizuoja patikimą praeitį, o 2.0.1 – keičiamo dydžio, saugią ir išmanią ateitį.

Pasirinkus 2.0.1 šiandien, investicija į ilgaamžiškumą yra svarbi. Tai užtikrina, kad jūsų įranga bus suderinama su naujos kartos elektromobiliais, atitiks griežtėjančius kibernetinio saugumo reglamentus ir bus pasirengusi pelningoms V2G ir išmaniųjų tinklų integracijos galimybėms. Rinkai konsoliduojantis, operatoriai, turintys patikimiausius ir lanksčiausius protokolų rinkinius, pirmaus.

11 skyrius: Išsami analizė: pranešimų srauto analizė ir sekų diagramos

Šiame skyriuje analizuojame EVSE ir CSMS sąveikos sekas, siekdami parodyti 1.6J ir 2.0.1 veikimo skirtumus.

11.1 Paleidimo ir konfigūravimo seka

Kai įkroviklis pirmą kartą prisijungia prie tinklo, jis turi save identifikuoti ir sinchronizuoti savo konfigūraciją.

OCPP 1,6 J srautas:

1. „WebSocket“ ryšysUžmegzta per 80 arba 443 prievadą.
2. Įkrovos pranešimasStotis siunčia tiekėją, modelį ir serijos numerį.
3. GetConfigurationCSMS prašo visų raktų, kad patikrintų dabartinę būseną.
4. Keisti konfigūracijąCSMS atnaujina konkrečius raktus (pvz.,Širdies plakimo intervalas).
5. Būsenos pranešimasStotis praneša „Pasiekiama“.

OCPP 2.0.1 srautas:

1. Saugus TLS paspaudimasPrivalomas sertifikatų keitimas.
2. Įkrovos pranešimasĮskaitantpriežastis(pvz.,„PowerUp“).
3. GetBaseReportUžuot prašiusi visų raktų, CSMS prašo „bazinės ataskaitos“, kurioje pateikiama visa įrenginio modelio hierarchija.
4. Nustatyti kintamuosiusCSMS atnaujina kintamuosius. Atkreipkite dėmesį, kad 2.0.1 versija leidžia atlikti atominius atnaujinimus – viename pranešime nustatyti kelis kintamuosius ir užtikrinti, kad visi jie būtų sėkmingi arba nė vienas ne.
5. Pranešti apie įvykįStotis praneša pradines komponentų būsenas.

11.2 Išmanusis įkrovimo derinimas

Išmanusis įkrovimas yra ta vieta, kur 2.0.1 iš tiesų sužiba, ypač kai reikia tvarkyti kelis įkrovimo profilius.

1,6 J variklyje CSMS siunčiaNustatyti įkrovimo profilįkuris apibrėžia steko lygį ir tvarkaraštį. Jei stotis turi kelias jungtis, profilio tvarkymas dažnai būna dviprasmiškas.

2.0.1 versijojeNustatyti įkrovimo profilįyra aiškiai susietas suįkrovimo profilio paskirtis.

• Įkrovimo stoties maksimalus profilis: Apriboja visos stoties oro įsiurbimą.
• TXDefaultProfile: Numatytoji reikšmė bet kokiai naujai operacijai.
• TXProfile: Taikoma tik vykdomai operacijai.

Be to, 2.0.1 versija palaikoGetChargingStackLevelpranešimą, leidžiantį CSMS matyti, kurie profiliai šiuo metu yra aktyvūs ir kaip jiems prioritetus suteikia EVSE vidinis planuoklis.

11.3 Nuotolinis paleidimas ir valdymas

Nuotolinės komandos, pvz.Nuotolinio paleidimo operacija(1,6 J) buvo pakeistiUžklausos pradžios operacija(2.0.1). Pagrindinis skirtumas yra naudingoji apkrova. 2.0.1 versijoje CSMS gali apimtiįkrovimo profilistiesiai užklausoje. Tai reiškia, kad automobilis gali pradėti krauti reikiamu galios lygiu nedelsdamas, nelaukiant antro pranešimo, taip sumažinant delsą ir pagerinant tinklo stabilumą.

12 skyrius: Žemo lygio JSON schemos ir laukų palyginimai

Programuotojams ir sistemų integratoriams schemų pakeitimai yra daugiausiai darbo reikalaujanti migracijos dalis.

12.1 Išvardinti tipai (enumai)

OCPP 2.0.1 gerokai išplečia standartizuotų išvardijimų (Enum) skaičių, sumažindama „pasirinktinių“ būsenos kodų poreikį, kuris kamavo 1.6J diegimus.

• Priežasčių išvardijimai: Sargybinis šuo, Suplanuotas atstatymas, Nuotolinis atstatymas, Galios nuostoliai.
• Būsenos išvardijimai: Užimtas, Rezervuota, Nepasiekiama, Sugedęs2.0.1 versija pridedaPrieinama, Užimtas, Rezervuota, Nepasiekiama, Sugedęsbet su papildomais statusais, kad būtų daugiau informacijos.

12.2 Duomenų tipai ir vienetai

OCPP 2.0.1 versijoje įforminamas standartinių vienetų (SI) naudojimas. 1,6 J versijoje kartais dešimtainis tikslumas nebuvo apibrėžtas, o 2.0.1 versijoje naudojamasdešimtainisgalios ir energijos verčių tipai, užtikrinant nuoseklų atsiskaitymą už skirtingų tiekėjų įrangą.

13 skyrius: Atvejo analizė: pasaulinė CPO migracija iš 1,6 J į 2,0,1

Panagrinėkime hipotetinį „MegaCharge“ scenarijų – CPO su 10 000 įkrovimo taškų.

13.1 1 etapas: Auditas

„MegaCharge“ nustatė, kad 40 % jų 1,6 J variklių parko nepalaiko TLS 1.2. Tai reiškė, kad šie įkrovikliai negalėjo dalyvauti būsimose vyriausybės sutartyse.

13.2 2 etapas: CSMS atnaujinimas

Užuot kūrusi naują CSMS, „MegaCharge“ įdiegė „OCPP vertimo sluoksnį“. Šis sluoksnis apdorojo 1.6J ryšius su sena įranga ir 2.0.1 ryšius su nauja įranga, tačiau savo mobiliajai programėlei ir atsiskaitymo varikliui pristatė vieningą API.

13.3 3 etapas: Aparatinės įrangos keitimas

Didelio srauto vietose „MegaCharge“ pakeitė 1,6 J įkroviklius su 2.0.1 standartą atitinkančiais nuolatinės srovės greitaisiais įkrovikliais. Dėl to 15 % sumažėjo sesijų, kai nepavyko paleisti, daugiausia dėl tvirtesnio įkrovimo.Operacijos įvykistvarkymas 2.0.1 versijoje.

13.4 Investicijų grąžos analizė

Pradinė investicija siekė 2 mln. USD. Tačiau sumažėjęs techninės priežiūros iškvietimų skaičius (dėl įrenginio modelio diagnostikos) leido sutaupyti 400 tūkst. USD per metus. Be to, galimybė dalyvauti V2G dažnio atsako rinkose generavo papildomas 200 tūkst. USD metines pajamas. Atsipirkimo laikotarpis buvo maždaug 3,3 metų.

14 skyrius: Pirkėjo svarbiausias kontrolinis sąrašas OCPP 2.0.1 pirkimams

Vertindami naują aparatinę ar programinę įrangą, naudokite šį kontrolinį sąrašą, kad užtikrintumėte tikrą atitiktį:

14.1 Aparatinės įrangos (EVSE) reikalavimai

• [ ]3 saugumo profilio palaikymasAr jis palaiko kliento pusės sertifikatų valdymą?
• [ ]Dviejų branduolių procesoriusAr yra pakankamai laisvos vietos TLS šifravimui ir JSON analizei?
• [ ]Saugus elementas (SE)Ar plokštė turi techninės įrangos patikimo šaknies kodą raktams saugoti?
• [ ]ISO 15118-2/20 paruoštasAr valdiklis gali palaikyti aukšto lygio ryšį, reikalingą PnC?
• [ ]Ekrano galimybėsAr aparatinė įranga palaiko kainos / būsenos informacijos rodymą per OCPP?Duomenų perdavimasar vietinės žinutės?

14.2 Programinės įrangos (CSMS) reikalavimai

• [ ]Įrenginio modelio vizualizacijaAr prietaisų skydelyje gali būti rodomas įkroviklio hierarchinis vaizdas?
• [ ]Sertifikatų institucijos (CA) integracijaAr CSMS gali automatiškai išduoti ir keisti sertifikatus?
• [ ]Sandorių suderinimasKaip sistema tvarko „užstrigusias“ operacijas su senesniais 1,6 J įkrovikliais?
• [ ]Išmanus įkrovimo variklisAr jis palaiko 2.0.1 versijos išplėstinę steko lygio logiką?
• [ ]Mastelio keitimasAr „WebSocket“ tvarkyklės gali vienu metu valdyti daugiau nei 50 000 nuolatinių TLS ryšių?

15 skyrius: Dažniausiai pasitaikančių OCPP diegimo problemų šalinimas

Net ir turint standartą, įgyvendinimas skiriasi. Štai dažniausiai pasitaikantys „susipratimai“.

15.1 „WebSocket“ skirtojo laiko apribojimai

Daugelis tinklo užkardų uždaro nenaudojamus TCP ryšius. JeiŠirdies plakimo intervalasnustatytas per aukštas lygis, įkroviklis gali būti atjungtas.

• SprendimasUžtikrintiŠirdies plakimo intervalasyra mažesnis nei užkardos skirtasis laikas (paprastai 60–120 sekundžių).

15.2 Sertifikatų grandinės problemos

Dažna 2.0.1 versijos klaida yra „Nepatikimas sertifikatas“. Tai dažniausiai nutinka, kai įkroviklyje nėra įdiegtas CSMS šakninis sertifikato teikėjas.

• SprendimasNaudokiteĮdiegti sertifikatąpranešimą paleidimo metu, siekiant užtikrinti, kad pasitikėjimo grandinė būtų užbaigta.

15.3 JSON naudingosios apkrovos dydis

Kai kurie 2.0.1 pranešimai (pvz.,GetBaseReport) gali būti labai didelis. Jei įkroviklio buferis per mažas, pranešimas bus atmestas.

• SprendimasPatikrinkiteMaksimalus pranešimo dydiskintamąjį įrenginio modelyje ir užtikrinkite, kad CSMS laikytųsi šios ribos.

16 skyrius. Regioniniai reguliavimo peizažai ir protokolų įgaliojimai

Perėjimas prie OCPP 2.0.1 nėra vien tik technologijų nulemtas; tai vis labiau tampa teisiniu klausimu.

16.1 Europos Sąjunga (AFIR)

ES Alternatyviųjų degalų infrastruktūros reglamentas (AFIR) įpareigoja užtikrinti kainų skaidrumą ir sąveikumą. Nors jame nėra aiškiai įvardytas OCPP 2.0.1, reikalavimas dėl „duomenų dalijimosi realiuoju laiku“ ir „išmaniojo įkrovimo“ iš esmės paverčia 2.0.1 vieninteliu tinkamu naujos viešosios infrastruktūros standartu.

16.2 Šiaurės Amerika (NEVI)

Jungtinėse Valstijose Nacionalinė elektromobilių infrastruktūros (NEVI) formulės programa reikalauja, kad įkrovikliai būtų „sąveikūs“. Tokios valstijos kaip Kalifornija žengia dar toliau, o Kalifornijos energetikos komisija (CEC) siekia ISO 15118 palaikymo, kurį, kaip jau aptarėme, geriausia įgyvendinti naudojant OCPP 2.0.1.

16.3 Kinija ir Azijos bei Ramiojo vandenyno regionas

Nors Kinija turi savo standartus (GB/T), į eksportą orientuoti gamintojai daug investavo į OCPP 2.0.1. Tokiose rinkose kaip Australija ir Singapūras vyriausybės skelbiamuose viešųjų įkrovimo tinklų konkursuose dabar beveik išimtinai nurodomas OCPP 2.0.1 su 3 saugumo profiliu.

17 skyrius: Įgyvendinimo kodo fragmentai: esmė

Siekdami padėti kūrėjams, teikiame konceptualias JSON reprezentacijas sudėtingoms 2.0.1 užduotims.

17.1 Sertifikatų rotacijos srautas

Artėjant sertifikato galiojimo pabaigai, CSMS turi inicijuoti rotaciją.

1. CSMS siunčiaPasirašytas sertifikatas:„json [2, "CERT-01", "Pasirašytas sertifikatas", { "certificateChain": "-----SERTIFIKATO PRADŽIA-----\n...\n-----SERTIFIKATO PABAIGA-----", "certificateType": "V2G" }]„

2. Stotis reaguojaPriimta:„json [3, „CERT-01“, { „statusas“: „Priimta“ }]„

3. Stotis siunčiaSaugos įvykių pranešimas:„json [2, „EVT-99“, „SecurityEventNotification“, { „type“: „CertificateRotated“, „timestamp“: „2026-08-09T10:00:00Z“ }]„

17.2 Tinklą atitinkančio įkrovimo profilio nustatymas

Įsivaizduokite, kad tinklo operatorius turi apriboti elektros energijos tiekimą visame tinkle.

CSMS siunčiaNustatyti įkrovimo profilį:„json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absoliuti", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]„

18 skyrius: Išsamus OCPP 2.0.1 terminų žodynėlis

Siekdami užtikrinti aiškumą visoms suinteresuotosioms šalims, pateikiame išplėstinį žodynėlį.

• CSMS (Įkrovimo stotelių valdymo sistema): Debesijos platforma, valdanti įkroviklius.
• EVSE (Elektrinių transporto priemonių tiekimo įranga)Fizinė įkrovimo stotelė.
• OCPP (atvirojo įkrovimo taškų protokolas)Kalba, kuria jie kalba.
• OCA (Atvirojo mokesčio aljansas)Organizacija, kuri rašo kalbą.
• ISO 15118Protokolas tarp automobilio ir įkroviklio.
• PnC (prijunk ir įkrauk)Naudotojo patirtis, užtikrinama pagal ISO 15118 ir OCPP 2.0.1.
• V2G (transporto priemonė–elektra): Automobilio energijos siuntimas atgal į tinklą.
• V2X (transporto priemonė viskam)Apibendrinant galima pasakyti, kad tai V2G, V2H ir V2B.
• TLS (transporto sluoksnio saugumas)Šifravimas, kuris saugo duomenis.
• PKI (viešojo rakto infrastruktūra)Skaitmeninių sertifikatų sistema, naudojama saugumui užtikrinti.
• JSON (JavaScript objektų žymėjimas)Pranešimų formatas.
• WebSocketNuolatinis ryšio „vamzdis“, kuriuo teka pranešimai.
• Įrenginio modelisHierarchinis 2.0.1 būdas aprašo aparatinę įrangą.
• KomponentasAparatinės įrangos dalis (pvz., jungtis).
• KintamasisKomponento savybė (pvz., Būsena).
• AtributasMetaduomenys apie kintamąjį (pvz., Reikšmė, Keičiamumas).
• Operacijos įvykisVieningas visų seanso duomenų pranešimas 2.0.1 versijoje.
• Širdies plakimasPeriodinis „Aš gyvas“ signalas.
• Įkrovos pranešimasSignalas „Sveiki, aš čia“, kai įkraunamas įkroviklis.
• Duomenų perdavimasBendras pranešimas, skirtas tiekėjo plėtiniams (naudokite atsargiai!).

Baigiamosios mintys: navigacija daugiaprotokolių eroje

Svarbiausia, kad, kaip pirkėjui ar operatoriui, mes žengiame įdaugiaprotokolių eraPer ateinančius 3–5 metus 1,6 J ir 2,0,1 egzistuos kartu. Tačiau pusiausvyra sparčiai keičiasi.

Pasirinkdami OCPP 2.0.1 šiandien, jūs ne tik perkate protokolą; jūs perkate draudimą. Jūs užtikrinate, kad jūsų tinklas galės prisitaikyti prie naujų automobilių, naujų įstatymų ir naujų pajamų srautų. 2.0.1 sudėtingumas yra pažangos kaina – kaina, kuri atsiperka per pagerėjusį veikimo laiką, sumažintą riziką ir geresnę klientų patirtį.

Komercinis įkrovimas nebėra nišinė pramonės šaka; tai būsimos transporto sistemos pagrindas. Šį pagrindą statykite ant tvirtiausio įmanomo pagrindo: OCPP 2.0.1.

19 skyrius: Programų kūrimas OCPP 2.0.1 versijai: geriausia praktika programinės įrangos inžinieriams

Perėjimas nuo 1.6J kodo bazės prie 2.0.1 nėra pertvarkymas, o perrašymas. Kūrėjai turi priimti kitokį mentalinį modelį.

19.1 Asinchroniškumo priėmimas

Nors „WebSockets“ iš esmės yra asinchroniniai, 2.0.1 sudėtingumas reiškia, kad viena užklausa (pvz.GetBaseReport) apdorojimas ribotų išteklių EVSE gali užtrukti kelias sekundes. CSMS kūrėjai turi įdiegti patikimą skirtojo laiko ir pakartotinio bandymo logiką, kuri atsižvelgtų į skirtingą skirtingų aparatinės įrangos tiekėjų apdorojimo greitį.

19.2 Efektyvus JSON analizavimas

JSON analizavimas gali būti daug procesoriaus apkrovų reikalaujantis procesas. EVSE programinės įrangos kūrėjai turėtų naudoti srautinius analizatorius, o ne krauti visą naudingąją apkrovą į RAM. Tai ypač svarbu...Pranešti apie įvykįpranešimai, kuriuose viename kadre gali būti šimtai kintamųjų atnaujinimų.

19.3 Valstybės mašinos valdymas

2.0.1 versijoje operacijos būsenos mašina yra griežtesnė nei 1.6J versijoje. Kūrėjai privalo griežtai laikytis perėjimo taisyklių.Operacijos įvykisPavyzdžiui, negalite siųstiPasibaigėįvykis be išankstinio išsiuntimoPradėtaįvykis, skirtas tam konkrečiamoperacijos ID.

20 skyrius: Testavimas, patvirtinimas ir OCPP atitikties testavimo įrankis (OCTT)

Sąveikumas yra OCPP pažadas, tačiau jis įgyvendinamas tik atliekant griežtus bandymus.

20.1 OCA sertifikavimo vaidmuo

„Open Charge Alliance“ siūlo sertifikavimo programą. Pirkėjai turėtų ieškoti „OCPP 2.0.1 Certified“ ženklo. Šis sertifikatas užtikrina, kad diegimas praėjo automatizuotų testų rinkinį, apimantį visus privalomus profilius.

20.2 OCTT naudojimas

OCPP atitikties testavimo įrankis (OCTT) yra auksinis testavimo standartas. Jis imituoja ir CSMS, ir EVSE.

• EVSE gamintojams: Naudokite OCTT, kad patikrintumėte, ar jūsų stotis tvarko „laimingo kelio“ scenarijus ir kraštutinius atvejus (pvz., tinklo ryšio sutrikimus programinės įrangos atnaujinimo metu).
• CSMS teikėjamsNaudokite OCTT, kad užtikrintumėte, jog jūsų serveris gali apdoroti daugybę pranešimų ir griežtus 2.0.1 saugumo reikalavimus.

20.3 Lauko bandymai ir sąveikos festivaliai

Be automatinio testavimo, OCA organizuoja „Plugfests“, kurių metu tiekėjai atsiveža savo aparatinę ir programinę įrangą, kad galėtų ją išbandyti realiose situacijose. Būtent čia aptinkamos ir išsprendžiamos subtiliausios klaidos, pvz., sertifikatų nesuderinamumas ar nedideli JSON formatavimo skirtumai.

21 skyrius: Išsami lyginamoji lentelė: daugiau nei 60 OCPP 2.0.1 veiksmų

Siekdami pateikti išsamų vaizdą, suskirstome pagrindinius 2.0.1 versijos pranešimus į kategorijas ir palyginame juos su 1.6J versijos atitikmenimis.

21.1 Parengimas ir konfigūravimas

21.2 Operacijų tvarkymas

21.3 Saugumo ir programinės įrangos valdymas

21.4 Ką lentelė reiškia jūsų tinklui

Lentelėje vienas dalykas yra neabejotinas: OCPP 2.0.1 nėra kosmetinis 1.6J pervadinimas. Naujos pranešimų šeimos – įvedami kintamieji, įvykiais pagrįstos operacijos ir sertifikatų valdymas – yra pagrindiniai elementai, reikalingi „Plug & Charge“, išmaniajam įkrovimui ir reguliavimo ataskaitų teikimui. Įkroviklį, kuris kalba tik 1.6J, galima modifikuoti su šliuzu, tačiau CSMS, kuri kalba tik 1.6J, negali užtikrinti saugumo modelio, kurio vis dažniau reikalauja reguliuotojai ir automobilių gamintojai. Vertinant aparatinę įrangą, „2.0.1 paruoštas“ turėtų reikšti, kad programinė įranga bus pristatyta šiandien, o ne kitais metais. Kadangi OCPP 2.0.1 veikia naudojant JSON per „WebSocket“, o ne SOAP perdavimą kaip 1.6J, pranešimų srautai yra lengvesni ir daug lengviau derinami – praktinis pranašumas, kurį jūsų IT komanda pajus nuo pirmos dienos.

22 skyrius: Išvada: sprendimo dėl atnaujinimo priėmimas

Komerciniam operatoriui praktinės gairės yra aiškios:

• Nauji diegimai turėtų būti atliekami pagal numatytuosius nustatymus naudojant OCPP 2.0.1.Saugumo modelis, sertifikatų tvarkymas ir ISO 15118 integravimas yra būtinos sąlygos 2026 m. reguliavimo aplinkai.
• Esami 1,6 J variklių parkai nėra įstrigę.Valdomi šliuzai ir dviejų protokolų CSMS platformos užpildo spragą, kol palaipsniui diegiate 2.0.1 versijos techninę įrangą.
• Išbandykite prieš pasitikėdami.Naudokite OCTT, „plugfest“ ir etapinius diegimus – sąveikumas yra įrodytas lauke, o ne daromas remiantis duomenų lapu.
• Reikalaukite raštu pateikti migracijos kelią.Jūsų įkroviklio tiekėjas turėtų paskelbti programinės įrangos planą nuo 1.6J iki 2.0.1 su datomis, o ne miglotais pažadais.

Raginimas veikti: pasikalbėkite su MIDA Power apie savo protokolo strategiją

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.