pea_bänner

OCPP 1.6J ja 2.0.1 strateegiline võrdlus äriliste laadimisjaamade operaatorite jaoks

OCPP 1.6J ja 2.0.1 lõplik strateegiline võrdlus ülemaailmsete äriliste laadimisjaamade operaatorite jaoks: võrgu skaleeritavuse, täiustatud küberturvalisuse, ISO 15118 integratsiooni ja pikaajalise infrastruktuuri tulevikukindluse tagamine elektrisõidukite jätkusuutliku kasvu jaoks.

Kokkuvõte

Elektriautode laadimismaastik on läbimas seismilist muutust. Ülemaailmse kasutuselevõtu kiirenedes on elektriautode laadimisseadmete (EVSE) ja laadimisjaamade haldussüsteemide (CSMS) vahelist suhtlust reguleerivad aluseks olevad sideprotokollid muutunud kommertslaadimisoperaatorite (CPO) tehnilise strateegia keskpunktiks. Open Charge Alliance'i (OCA) hallatav avatud laadimispunkti protokoll (OCPP) on arenenud lihtsast sõnumside raamistikust keerukaks, turvaliseks ja väga skaleeritavaks standardiks.

See juhend pakub põhjalikku tehnilist analüüsi üleminekust OCPP 1.6J-lt OCPP 2.0.1-le. Uurime arhitektuurilisi erinevusi, turvalisuse täiustusi, seadmehalduse paradigmasid ja ISO 15118 integratsiooni kriitilist rolli. Ostjatele ja operaatoritele on see artikkel lõplikuks viiteks teadlike hanke- ja migreerimisotsuste tegemiseks kiiresti areneval turul.


1. peatükk: Elektriautode laadimisstandardite areng: ajalooline kontekst

Avatud laadimispunkti protokoll (OCPP) sündis koostalitlusvõime vajadusest. Elektriautode laadimise algusaegadel kasutasid riistvaratootjad ja tarkvaratarnijad patenteeritud protokolle, luues „piiratud aedu“, mis lämmatasid konkurentsi ja innovatsiooni. OCPP 1.2 ja 1.5 kasutuselevõtt pani aluse, kuid OCPP 1.6 ühendas valdkonna tõeliselt.

1.1 OCPP 1.6J domineerimine

2015. aastal välja antud OCPP 1.6 tutvustas JSON over WebSockets (1.6J) implementatsiooni. See SOAP-põhisest sõnumivahetusest loobumine vähendas oluliselt arendajate üldkulusid ja lihtsustas rakendamist. See tutvustas selliseid funktsioone nagu nutikas laadimine ja täiendavad olekuteated, muutes selle peaaegu kümneks aastaks tööstusstandardiks.

1.2 OCPP 2.0.1 teke

Vaatamata 1.6J edule paljastas tööstuse kasv selle piirangud. Turvalisuse probleemid, seadmehalduse keerukus ja täiustatud võrguintegratsiooni (V2G) natiivse toe puudumine viisid OCPP 2.0 ja seejärel täiustatud OCPP 2.0.1 (ilmus 2020. aastal) väljatöötamiseni. OCPP 2.0.1 ei ole lihtsalt värskendus; see on täielik ümberkujundamine, mille eesmärk on toetada järgmise põlvkonna suure võimsusega, nutikaid ja turvalisi laadimisvõrke.


2. peatükk: Aluseks olevad suhtlusparadigmad: JSON, WebSockets ja raamstruktuurid

Nende protokollide erinevuse mõistmiseks tuleb vaadata madala taseme suhtlust. Mõlemad protokollid kasutavad JSON-i WebSocketsi asemel, kuid nende sõnumite struktuur ja käitlemine erinevad oluliselt.

2.1 WebSocketi kiht

Mõlemad versioonid kasutavad püsivaid WebSocket-ühendusi, mis võimaldavad täisdupleks-sidet. See on kriitilise tähtsusega reaalajas toimingute jaoks, näiteks laadimisseansi peatamiseks mobiilirakendusest või koheste rikketeadete vastuvõtmiseks.

2.2 Sõnumiraami jaotus

Tüüpiline OCPP-teade koosneb sõnumitüübi ID-st, unikaalsest sõnumi ID-st, toimingu nimest ja kasulikust koormusest.

OCPP 1.6J raami näide (BootNotification)

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

OCPP 2.0.1 raami näide (BootNotification)

„json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Pange tähele versioonis 2.0.1 suurenenud detailsust.„reason` väli võimaldab CSMS-il aru saada, kas alglaadimine oli tingitud taaskäivitamisest, sisselülitamisest või valvekoera käivitamisest, mis võimaldab paremat diagnostilist loogikat.


3. peatükk: Arhitektuurilise paradigma muutus: seadmemudel

OCPP 2.0.1 kõige olulisem tehniline erinevus on järgmise kasutuselevõtt:Seadme mudel.

3.1 1.6J konfiguratsioonivõtmete piirangud

OCPP 1.6J-s hallati riistvara konfiguratsiooni ühetaolise „konfiguratsioonivõtmete” loendi abil (ntSüdamelöögi intervall, Ühenduse ajalõpp). Laadijate keerukamaks muutudes (mitme pistikuga, integreeritud toitemoodulid, keerukad jahutussüsteemid) muutus see ühetaoline nimekiri hallatavaks. Jaama füüsilise hierarhia kirjeldamiseks puudus standardne viis.

3.2 Seadme mudeli 2.0.1 lähenemisviis

OCPP 2.0.1 tutvustab hierarhilist mudelit, mis koosneb järgmistest osadest:KomponendidjaMuutujadKomponent võib olla „kontroller“, „pistik“ või „toitemoodul“. Igal komponendil on muutujad, mis esindavad selle olekut või konfiguratsiooni (ntTemperatuur, Pinge, Maksimaalne vool).

  • KomponentLaadimisjaama füüsiline või loogiline osa.
  • Muutuja: Selle komponendi spetsiifiline atribuut.
  • OmadusedMuutujat kirjeldavad metaandmed (ühik, vahemik, juurdepääsutüüp).

See võimaldab standardiseeritud jälgimist. Operaator saab nüüd konkreetse toitemooduli temperatuuri kohta päringuid teha standardiseeritud teekonna kaudu, selle asemel et tugineda müüjapõhistele patenteeritud võtmetele.


4. peatükk: Küberturvalisus: parimast pingutusest kohustusliku TLS-i juurde

Elektriautode laadimise algusaegadel oli turvalisus sageli teisejärguline. OCPP 1.6J pakkus turvaprofiile, kuid nende rakendamine oli müüjate lõikes ebaühtlane.

4.1 Turvaprofiilid versioonis 1.6J

OCPP 1.6J defineeris kolm turvaprofiili:

  1. TagatisetaLihttekstilised HTTP/WebSocketid.
  2. PõhiautentimineTLS kasutajanime/parooliga.
  3. SertifikaadipõhineTLS kliendipoolsete sertifikaatidega.

Probleem oli selles, et paljud laadijad jäid profiilile 1, mis muutis nad haavatavaks vahemehe (MITM) rünnakute ja volitamata kontrolli suhtes.

4.2 Versiooni 2.0.1 karastunud hoiak

OCPP 2.0.1 nõuab turvalist suhtlust. See integreerib täiustatud turvafunktsioonid otse süsteemi:

  • Turvalised püsivara värskendusedPüsivara kujutiste kohustuslik allkirjastamine ja kontrollimine.
  • TurvalogimineTurvalisusega seotud sündmuste (nt ebaõnnestunud sisselogimiskatsed, sertifikaadi aegumine) üksikasjalikud logid.
  • Sertifikaatide haldusStandardiseeritud sõnumid vahetatud ja uuendatud sertifikaatide kohta (CSMS-i või jaama juhitud).
  • TLS 1.2/1.3: Toetab uusimaid krüpteerimisstandardeid.

Ärioperaatorite jaoks vähendab see ulatuslike võrgukompromiteerimiste ohtu ja tagab vastavuse IoT-seadmete uutele küberturvalisuse eeskirjadele.


5. peatükk: ISO 15118 integratsioon: pistik ja laadimine ning V2G

Elektriautode laadimise tulevik ei seisne ainult elektronide liigutamises; see puudutab intelligentset andmete ja energia vahetust. ISO 15118 on rahvusvaheline standard sõiduki ja elektrivõrgu (V2G) vaheliseks kommunikatsiooniks ning selle integreerimine OCPP-ga on 2.0.1 määravaks tunnuseks.

5.1 Ühenda ja laadi – keerukus

Laadimise ja ühendamise funktsioon (PnC) võimaldab juhil lihtsalt sõiduki vooluvõrku ühendada ja laadimist alustada ilma rakendust või RFID-kaarti kasutamata. See nõuab keerukat avaliku võtme infrastruktuuri (PKI), mis hõlmab sõidukit, laadijat, operaatorit ja arvelduskoda.

OCPP 1.6J-s puudus baasprotokollis PnC tugi. Tootjad pidid rakendama kohandatud laiendusi, mis viis killustatuseni. OCPP 2.0.1 pakub PnC jaoks vajalikku tuge, toetades:

  • Sertifikaadi paigaldamineLepingusertifikaatide edastamine CSMS-ist EV-sse EVSE kaudu.
  • VolitamineKasutades sõiduki sertifikaadist tuletatud e-mobiilsuse ID-d (eMAID).
  • Krüpteeritud sideTagades auto ja elektrivõrgu vahel edastatavate tundlike arveldusandmete kaitse.

5.2 Nutikas laadimine ja koormuse tasakaalustamine

Kuigi 1.6J toetas põhilist nutikat laadimist (saatesMäära laadimisprofiil), 2.0.1 tõstab seda taset. See võimaldab:

  • Välise signaali integreerimineReaalajas reageerimine võrgu sagedusele või hulgihinna signaalidele.
  • Dünaamiline koormuse haldamine: Detailsem kontroll energiajaotuse üle sadade pistikutega saidil.
  • Sõidukilt võrku (V2G)2.0.1 sisaldab vajalikke andmevälju kahesuunalise energiavoo toetamiseks, võimaldades elektrisõidukitel toimida võrgu hajutatud energiaressurssidena (DER).

5.3 Kasutajaliidese/UX täiustused

OCPP 2.0.1 toetab teabe kuvamist otse laadija ekraanil või sõiduki armatuurlaual, näiteks:

  • Reaalajas hinnakujundus kohalikus valuutas.
  • Eeldatav aeg 80% laetuse taseme saavutamiseks.
  • Täpne kviitungiinfo pärast täitmist.

6. peatükk: Täiustatud seadmehaldus ja jälgimine

Laadija omaniku jaoks ei ole laadija hind ainult ostuhind, vaid ka kogukulu (TCO). Hooldus ja seisakud on suurimad kasumit kahjustavad tegurid. OCPP 2.0.1 lahendab selle probleemi suurepäraste jälgimisvõimaluste abil.

6.1 Sündmuspõhine aruandlus

1.6J versioonis pidi CSMS tavaliselt laadija olekut küsima või vastust ootama.Staatuse teavitusVersioonis 2.0.1 onSündmuste jälgimineSüsteem võimaldab CSMS-il määrata läviväärtusi. Näiteks: „Teavita mind ainult siis, kui sisetemperatuur ületab 70 °C” või „Teata, kui sisendpinge langeb alla 200 V”. See vähendab võrguliiklust ja võimaldab ennetavat hooldust.

6.2 Tehingute käsitlemine: tehingusündmus (TransactionEvent)

Üks OCPP 1.6J enim kritiseeritud aspekte oli tehingute käsitlemine. Seanss hõlmasAlusta tehingutjaTehingu peataminesõnumeid, kuid võrgukatkestuse korral oli CSMS-il sageli raskusi arveldusandmete ühildamisega.

OCPP 2.0.1 asendab need ühe kindla ja töökindla lahendusega.Tehingu sündmussõnum. Seda sõnumit kasutatakse tehingu kõigi elutsükli etappide (alustatud, uuendatud, lõppenud) teatamiseks. See sisaldab unikaalsettehingu IDmis püsib isegi pärast laadija taaskäivitamist, tagades, et laadimisandmeid – ja seega ka tulu – ei lähe kaotsi.

6.3 Täiustatud diagnostika ja tõrkeotsing

SeeGetLogijaDiagnostika oleku teavitusVersioonis 2.0.1 on sõnumid struktureeritumad. CPO-d saavad taotleda konkreetseid logitüüpe (turvalisus, diagnostika, kasutaja) ja määrata ajavahemiku. See võimaldab kaugtoe meeskondadel probleeme lahendada ilma tehnikut kohale saatmata, vähendades oluliselt tegevuskulusid.


7. peatükk: Püsivara uuendamise mehhanismid: töökindlus ja tagasipööramised

Püsivara uuendused on areneva riistvara elujõud, kuid ebaõnnestunud uuendus võib laadija rikkuda.

7.1 1.6J uuendusprotsess

1,6J puhulPüsivara värskendamineKäsk oli suhteliselt lihtne. Laadija laadis alla pildi ja proovis seda installida. Mitmeastmeliste värskenduste või kinnitatud tagasipööramiste jaoks puudus standardne mehhanism.

7.2 Mitmeastmeline värskendus 2.0.1

OCPP 2.0.1 tutvustab püsivara värskenduste keerukamat elutsüklit:

  1. Laadi allaLaadija laadib pildi ja kontrollib selle kontrollsummat/allkirja.
  2. PaigaldamineVärskendus rakendatakse teisejärgulisele partitsioonile.
  3. KontrollimineSüsteem kontrollib, kas uus püsivara käivitub õigesti.
  4. AktiveeriminePeamine partitsioon on vahetatud.

Kui mõni samm ebaõnnestub, määratleb protokoll, kuidas laadija peaks naasma eelmisele stabiilsele versioonile ja edastama konkreetse veakoodi CSMS-ile. See usaldusväärsuse tase ei ole suuremahuliste äriliste juurutuste puhul läbiräägitav.

7.3 Allkirja kontrollimine

Pahatahtlike isikute takistamiseks ohustatud püsivara üleslaadimisel nõuab versioon 2.0.1 digitaalallkirjade kasutamist. Laadija keeldub käivitamast koodi, mis pole tootja privaatvõtmega allkirjastatud, lisades riistvaratasemel häkkimiste eest kriitilise kaitsekihi.


8. peatükk: Andmekaitse, regulatiivse vastavuse ja isikuandmete kaitse üldmäärus (GDPR)

Kuna elektriautode laadimine muutub igapäevaseks kasutusviisiks, on tekkivate isikuandmete hulk hämmastav. Üks laadimisseanss võib siduda kasutaja identiteedi, tema sõiduki asukoha, reisimustrid ja finantsteabe.

8.1 Isiku tuvastamist võimaldav teave (PII) OCPP-s

Euroopa isikuandmete kaitse üldmääruse (GDPR) ja sarnaste seaduste, näiteks California CCPA kontekstis on andmepunktid, näiteksidTag(RFID) võiEVCCID(Sõiduki identifikaatorit) peetakse isikut tuvastavaks teabeks.

OCPP 2.0.1 pakub paremaid andmete anonüümseks muutmise juhtelemente. NäiteksKohandatud andmedväljad võimaldavad operaatoritel salvestada metaandmeid ilma isikuandmeid põhiprotokolli logidesse paljastamata. Lisaks tagavad täiustatud turvaprofiilid, et need andmed on krüptitud nii edastamise kui ka salvestatud olekus.

8.2 Õigus olla unustatud ja andmete ülekandmine

2.0.1 seadmemudeli struktureeritud olemus lihtsustab CSMS-teenuse pakkujatel andmete kustutamise taotluste rakendamist. 1.6J süsteemis oli kasutaja ID kõigi eksemplaride leidmine erinevatest konfiguratsioonivõtmetest ja logidest käsitsi õudusunenägu. Versioonis 2.0.1 võimaldab seadme oleku ja tehinguandmete selge eraldamine puhtamat andmebaasi arhitektuuri.

8.3 Asjade interneti turvalisust käsitlevate seaduste järgimine

Paljudes piirkondades võetakse praegu vastu seadusi, mis nõuavad IoT-seadmetelt unikaalseid paroole ja turvalisi värskendusmehhanisme. OCPP 2.0.1 kohustuslik TLS ja allkirjastatud püsivara pole lihtsalt „head, mida omada” funktsioonid – need on riistvara müümise seaduslikud nõuded sellistel turgudel nagu California ja Ühendkuningriik.


9. peatükk: Ostja vaatenurk: kogukulud, investeeringutasuvus ja strateegiline migratsioon

Kommertslaadimisjaamade operaatori jaoks on otsus jääda 1,6J juurde või minna üle 2.0.1-le rahaline.

9.1 Rakendamise maksumus

  • OCPP 1.6JOdav rakendada, laialdaselt toetatud odava riistvaraga, kuid toob kaasa suured varjatud kulud hoolduse ja turvariskide näol.
  • OCPP 2.0.1Nõuab võimsamaid protsessoreid ja rohkem mälu EVSE-s. CSMS-i arenduskulud on protokolli keerukuse tõttu kõrgemad. See pakub aga märkimisväärset tegevuskulude kokkuhoidu kaughalduse ja parema töökindluse kaudu.

9.2 Müüt „Sujuvast uuendamisest”

Tihti öeldakse, et 1.6J laadijaid saab tarkvara abil versioonile 2.0.1 uuendada. Tegelikkuses see harva nii on. 2.0.1 mälu- ja protsessorinõuded (eriti TLS-sertifikaatide käsitlemine ja seadmemudeli keerukas JSON-parsimine) ületavad sageli vanemate 1.6J kontrollerite võimalusi.

9.3 Strateegilised rändeteed

CPO-d peaksid kaaluma „hübriidvõrgu” lähenemisviisi:

  1. Vananenud saididJätkata olemasolevate väikese energiatarbega vahelduvvoolulaadijate kasutamist 1,6 J juures.
  2. Uued alalisvoolu kiirlaadimispunktidMandaat 2.0.1 kõigi uute suure võimsusega juurutuste jaoks, et toetada PnC-d ja V2G-d.
  3. Puhverserveri lahendusedKasutage protokolliväravat, mis suudab CSMS-i jaoks teisendada 1.6J sõnumeid 2.0.1-ühilduvasse vormingusse, võimaldades ühtset halduspaneeli.

10. peatükk: Tulevikukindlus: OCPP 2.1 ja tee autonoomse laadimise poole

Isegi kui 2.0.1 on populaarsust kogumas, töötab Open Charge Alliance juba OCPP 2.1 kallal. See tulevane versioon laiendab protokolli ulatust veelgi.

10.1 Kahesuunaline laadimine (V2X)

Kuigi 2.0.1 toetab põhilist V2G-d, täiustab 2.1 sõiduki ja kodu (V2H) ning sõiduki ja hoone (V2B) vahelist sidet, võimaldades elektriautodel toita kodusid elektrikatkestuste ajal või vähendada ärihoonete tippnõudlust.

10.2 Juhtmevaba laadimise tugi

Autonoomsete sõidukite (AV) levikuga muutub käsitsi laadimine iganenuks. OCPP 2.1 sisaldab standardiseeritud sõnumeid induktiivse (juhtmevaba) laadimise, joondamise ja energiaülekande haldamiseks ilma inimese sekkumiseta.

10.3 Integratsioon nutikate linnadega

Tulevased iteratsioonid näevad tõenäoliselt ette sügavamat integratsiooni liikluskorraldussüsteemide ja taastuvenergia prognoosidega. Laadijad saavad reaalajas energiaturgudel energia eest pakkumisi teha, muutes laadimisvõrgud massiivseteks virtuaalseteks elektrijaamadeks (VPP-deks).


Tehniline lisa: Sõnumite võrdluste põhjalik analüüs

Täieliku tehnilise ülevaate saamiseks analüüsime nüüd kahe versiooni konkreetseid sõnumijärjestusi ja kaadrite erinevusi.

A.1 Autoriseerimisvoog

Versioonis 1.6J oli autoriseerimine binaarne vastus „Aktsepteeritud” või „Blokeeritud”.

1.6J Autoriseerimisvastus:„json [3, "123456", { "idTagInfo": { "status": "Vastu võetud", "expiryDate": "2026-12-31T23:59:59Z" } }]„

Versioonis 2.0.1 sisaldab vastus rohkem konteksti, näiteksidTokentüüp ja lisateave kasutajaliidese kohta.

2.0.1 Autoriseerimisvastus:„json [3, "987654", { "idTokenInfo": { "status": "Vastu võetud", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Tere tulemast tagasi, John! Teie saldo on 45,00 dollarit" } } }]„

A.2 Südamelöögid ja ühenduse haldamine

OCPP 2.0.1 optimeerib seda, kuidas jaam tõestab oma „elujõudu“. 1,6J puhul, kui aSüdamelöökebaõnnestus, proovis jaam sageli lihtsalt uuesti. Versioonis 2.0.1 saab jaam kasutadaTeavita sündmustmehhanism, mis teatab ühenduse katkemisest teisese taustasüsteemiga, säilitades samal ajal ühenduse esmase serveriga.

A.3 Üksikasjalik metaandmete tabel

Funktsioon OCPP 1.6J OCPP 2.0.1
Transport JSON WebSocketsi kaudu JSON WebSocketsi kaudu
Turvalisus Valikuline TLS, põhiautentimine Kohustuslik TLS, kliendi sertifikaadid
Seadme mudel Lameda konfiguratsioonivõtmed Hierarhilised komponendid/muutujad
ISO 15118 Ainult pikendus Natiivne tugi (PnC, V2G)
Tehingu ID CSMS-i loodud EVSE loodud
Nutikas laadimine Põhiline (profiilid) Täiustatud (võrgusignaalid, V2X)
Sõnumid ~30 tegevust ~60 tegevust
Ekraanitugi Puudub Natiivsõnumite tugi

Kokkuvõte

Üleminek OCPP 1.6J-lt versioonile 2.0.1 ei ole pelgalt tarkvarauuendus; see on elektrilise mobiilsuse ökosüsteemi põhimõtteline areng. Kommertsettevõtjate jaoks esindab 1.6J usaldusväärset minevikku, samas kui 2.0.1 esindab skaleeritavat, turvalist ja intelligentset tulevikku.

2.0.1 valimine täna on investeering pikaealisusse. See tagab, et teie riistvara ühildub järgmise põlvkonna elektriautodega, vastab karmistuvatele küberturvalisuse eeskirjadele ning on valmis V2G ja nutivõrkude integreerimise tulusateks võimalusteks. Turu konsolideerudes on kõige vastupidavamate ja paindlikumate protokollipakkidega operaatorid need, kes eest vedavad.


11. peatükk: Süvaanalüüs: sõnumivoo analüüs ja järjestusskeemid

Selles peatükis analüüsime EVSE ja CSMS-i interaktsioonijärjestusi, et demonstreerida 1.6J ja 2.0.1 tööpõhimõtteid.

11.1 Käivitus- ja konfiguratsioonijärjestus

Kui laadija esimest korda võrguga ühendub, peab see end tuvastama ja oma konfiguratsiooni sünkroonima.

OCPP 1.6J vool:

  1. WebSocketi ühendus: Loodud pordi 80 või 443 kaudu.
  2. BootNoticeJaam saadab tarnija, mudeli ja seerianumbri.
  3. GetConfigurationCSMS taotleb kõiki võtmeid praeguse oleku kontrollimiseks.
  4. Konfiguratsiooni muutmineCSMS uuendab teatud võtmeid (ntSüdamelöögi intervall).
  5. Staatuse teavitusJaam teatab, et on saadaval.
OCPP 1.6J ja 2.0.1 strateegiline võrdlus äriliste laadimisjaamade operaatorite jaoks

OCPP 2.0.1 voog:

  1. Turvaline TLS-käepigistusKohustuslik sertifikaadivahetus.
  2. BootNoticeSisaldabpõhjus(nt.PowerUp).
  3. GetBaseReportKõikide võtmete küsimise asemel küsib CSMS „baasaruannet“, mis annab seadmemudeli täieliku hierarhia.
  4. Muutujate määramineCSMS uuendab muutujaid. Pange tähele, et versioon 2.0.1 lubab aatomivärskendusi – määrates ühes sõnumis mitu muutujat ja tagades, et kõik õnnestuvad või mitte ükski ei õnnestu.
  5. Teavita sündmustJaam annab teada komponentide esialgsetest olekutest.

11.2 Nutikas laadimisläbirääkimised

Nutikas laadimine on see, kus 2.0.1 tõeliselt särab, eriti mitme laadimisprofiili haldamisel.

1.6J režiimis saadab CSMS aMäära laadimisprofiilmis määratleb pinu taseme ja ajakava. Kui jaamal on mitu pistikut, on profiilide käsitlemine sageli mitmetähenduslik.

Versioonis 2.0.1Määra laadimisprofiilon otseselt seotudlaadimisprofiilEesmärk.

  • Laadimisjaama maksimaalne profiil: Piirab kogu jaama sisselaskevõimsust.
  • TXDefaultProfile: Vaikimisi iga uue tehingu puhul.
  • TXProfile: Spetsiifiline käimasolevale tehingule.

Lisaks toetab 2.0.1 järgmist:Laadimisstacki taseme hankiminesõnum, mis võimaldab CSMS-il näha, millised profiilid on hetkel aktiivsed ja kuidas EVSE sisemine ajakava neid tähtsuse järjekorda seab.

11.3 Kaugkäivitus ja -juhtimine

Kaugkäsklused, näiteksKaugkäivitustehing(1,6 J) on asendatudRequestStartTransaction(2.0.1). Peamine erinevus seisneb kasulikus koormuses. Versioonis 2.0.1 võib CSMS sisaldadalaadimisprofiilotse käivituspäringus. See tähendab, et auto saab kohe õigel võimsustasemel laadimist alustada, ilma teist teadet ootamata, vähendades latentsusaega ja parandades võrgu stabiilsust.


12. peatükk: Madala taseme JSON-skeemi ja väljade võrdlused

Arendajate ja süsteemiintegraatorite jaoks on skeemimuudatused migratsiooni kõige töömahukam osa.

12.1 Loendtüübid (enumid)

OCPP 2.0.1 laiendab oluliselt standardiseeritud enumite arvu, vähendades vajadust „kohandatud” olekukoodide järele, mis vaevasid 1.6J implementatsioone.

  • Põhjuste loendid: Valvekoer, Ajastatud lähtestamine, Kauglähtestamine, Võimsuskadu.
  • Staatuse loendid: Okupeeritud, Reserveeritud, Pole saadaval, Vigane. 2.0.1 lisabSaadaval, Okupeeritud, Reserveeritud, Pole saadaval, Viganeaga üksikasjalikuma teabe saamiseks alamstaatuste lisamisega.

12.2 Andmetüübid ja ühikud

OCPP 2.0.1 formaliseerib standardühikute (SI) kasutamise. Kui 1,6J puhul jäi kümnendsüsteemi täpsus mõnikord määratlemata, siis 2.0.1 kasutabkümnendtüübid võimsuse ja energia väärtuste jaoks, tagades järjepideva arvelduse eri tarnijate riistvara puhul.


13. peatükk: Juhtumiuuring: ülemaailmne CPO migratsioon 1,6J-lt 2,0,1-le

Vaatame hüpoteetilist stsenaariumi „MegaCharge” ehk 10 000 laadimispunktiga CPO-d.

13.1 1. etapp: Audit

MegaCharge avastas, et 40% nende 1,6J laadijatest ei toetanud TLS 1.2. See tähendas, et need laadijad ei olnud eelseisvateks valitsuse lepinguteks kõlblikud.

13.2 2. etapp: CSMS-i uuendamine

Uue CSMS-i loomise asemel rakendas MegaCharge „OCPP tõlkekihi“. See kiht käsitles vana riistvara puhul 1.6J ühendusi ja uue riistvara puhul 2.0.1 ühendusi, kuid oma mobiilirakendusele ja arveldusmootorile avaldas ühtse API.

13.3 3. etapp: Riistvara asendamine

Suure liiklusega laadimisjaamades asendas MegaCharge 1,6J laadijad 2.0.1-ühilduvate alalisvoolu kiirlaadijatega. Tulemuseks oli 15% vähenemine „käivitusnõrkuste” seansside arvus, peamiselt tänu töökindlamale laadijale.Tehingu sündmuskäitlemine versioonis 2.0.1.

13.4 ROI analüüs

Esialgne investeering oli 2 miljonit dollarit. Väiksemad hoolduskõned (tänu seadmemudeli diagnostikale) säästsid aga 400 000 dollarit aastas. Lisaks genereeris V2G sageduskarakteristiku turgudel osalemise võimalus 200 000 dollarit aastas täiendavat tulu. Tasuvusaeg oli ligikaudu 3,3 aastat.


14. peatükk: Ostja lõplik kontrollnimekiri OCPP 2.0.1 hanke jaoks

Uue riist- või tarkvara hindamisel kasutage vastavuse tagamiseks järgmist kontroll-lehte:

14.1 Riistvara (EVSE) nõuded

  • [ ]Turvaprofiili 3 tugiKas see toetab kliendipoolset sertifikaatide haldust?
  • [ ]Kahetuumaline protsessorKas TLS-krüptimiseks ja JSON-i parsimiseks on piisavalt vaba ruumi?
  • [ ]Turvaline element (SE)Kas plaadil on võtmete salvestamiseks riistvaraline usaldusjuur?
  • [ ]ISO 15118-2/20 valmisKas kontroller suudab hakkama saada PnC jaoks vajaliku kõrgetasemelise kommunikatsiooniga?
  • [ ]Kuvari võimekusKas riistvara toetab hinna/olekuinfo kuvamist OCPP kaudu?Andmeülekannevõi natiivsed sõnumid?

14.2 Tarkvara (CSMS) nõuded

  • [ ]Seadme mudeli visualiseerimineKas armatuurlaual saab kuvada laadija hierarhilist vaadet?
  • [ ]Sertifitseerimisasutuse (CA) integratsioonKas CSMS saab sertifikaate automaatselt väljastada ja vahetada?
  • [ ]Tehingute leppimineKuidas süsteem käsitleb 1,6J vanade laadijate „rippuvaid“ tehinguid?
  • [ ]Nutikas laadimismootorKas see toetab versiooni 2.0.1 täiustatud pinutaseme loogikat?
  • [ ]SkaleeritavusKas WebSocketi käitleja suudab samaaegselt hallata üle 50 000 püsiva TLS-ühenduse?

15. peatükk: Levinud OCPP rakendamise probleemide tõrkeotsing

Isegi standardi korral on rakendused erinevad. Siin on kõige levinumad viperused.

15.1 WebSocketi ajalõpud

Paljud võrgu tulemüürid sulgevad jõudeolevad TCP-ühendused. KuiSüdamelöögi intervallkui see on liiga kõrgeks seatud, võib laadija olla lahti ühendatud.

  • LahendusVeendugeSüdamelöögi intervallon madalam kui tulemüüri ajalõpp (tavaliselt 60–120 sekundit).

15.2 Sertifikaadiahela probleemid

Levinud tõrge versioonis 2.0.1 on viga „Usaldamatu sertifikaat“. See juhtub tavaliselt siis, kui laadijal pole CSMS-i juursertifitseerimisasutust installitud.

  • LahendusKasutageInstallisertifikaatsõnum kasutuselevõtu ajal, et tagada usaldusahela terviklikkus.

15.3 JSON-i kasuliku koormuse suurus

Mõned 2.0.1 sõnumid (näiteksGetBaseReport) võib olla väga suur. Kui laadija puhver on liiga väike, siis see sõnumi kustutab.

  • LahendusKontrolligeMaksimaalne sõnumi suurusmuutuja seadmemudelis ja veenduge, et CSMS seda piirangut järgib.

16. peatükk: Piirkondlikud regulatiivsed maastikud ja protokollilised mandaadid

Üleminek OCPP 2.0.1-le ei ole ainult tehnoloogia poolt ajendatud; see on üha enam ka õiguslik küsimus.

16.1 Euroopa Liit (AFIR)

EL-i alternatiivkütuste taristu määrus (AFIR) nõuab hinna läbipaistvust ja koostalitlusvõimet. Kuigi see ei nimeta otseselt OCPP 2.0.1, muudab „reaalajas andmete jagamise” ja „nutika laadimise” nõue 2.0.1 sisuliselt ainsaks elujõuliseks standardiks uue avaliku taristu jaoks.

16.2 Põhja-Ameerika (NEVI)

Ameerika Ühendriikides nõuab riiklik elektrisõidukite infrastruktuuri (NEVI) valemiprogramm, et laadijad oleksid „koostalitlusvõimelised“. Sellised osariigid nagu California lähevad veelgi kaugemale, kusjuures California Energiakomisjon (CEC) surub peale ISO 15118 tuge, mida, nagu me juba arutasime, on kõige parem rakendada OCPP 2.0.1 kaudu.

16.3 Hiina ja Aasia ja Vaikse ookeani piirkond

Kuigi Hiinal on oma standardid (GB/T), on ekspordile orienteeritud tootjad suuresti investeerinud OCPP 2.0.1-sse. Sellistel turgudel nagu Austraalia ja Singapur on avalike laadimisvõrkude valitsuste pakkumismenetlustes nüüd peaaegu eranditult täpsustatud OCPP 2.0.1 koos turvaprofiiliga 3.


17. peatükk: Rakenduskoodi lõigud: „Põhidetailid”

Arendajate abistamiseks pakume keerukate 2.0.1 ülesannete jaoks kontseptuaalseid JSON-esitusi.

17.1 Sertifikaatide rotatsioonivoog

Kui sertifikaadi kehtivusaeg läheneb aegumisele, peab CSMS käivitama rotatsiooni.

1. CSMS saadabSertifikaatAllkirjastatud:„json [2, "CERT-01", "Sertifikaadi allkiri", { "certificateChain": "-----SERTIFIKAADI ALGUS-----\n...\n-----SERTIFIKAADI LÕPP-----", "certificateType": "V2G" }]„

2. Jaam vastabVastu võetud:„json [3, "CERT-01", { "status": "Vastu võetud" }]„

3. Jaam saadabTurvasündmuse teavitus:„json [2, "EVT-99", "TurvalisuseSündmuseNotifikatsioon", { "tüüp": "SertifikaadiPööramine", "ajatempel": "2026-08-09T10:00:00Z" }]„

17.2 Võrgupõhise laadimisprofiili seadistamine

Kujutage ette, et võrguoperaator peab võrgus võimsust piirama.

CSMS saadabMäära laadimisprofiil:„json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absoluutne", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]„


18. peatükk: OCPP 2.0.1 terminite põhjalik sõnastik

Kõigile sidusrühmadele selguse tagamiseks pakume laiendatud sõnastikku.

  • CSMS (laadimisjaama haldussüsteem): Tagaserveri pilveplatvorm, mis juhib laadijaid.
  • EVSE (elektrisõidukite toiteseadmed)Füüsiline laadimisjaam.
  • OCPP (avatud laadimispunkti protokoll)Keel, mida nad räägivad.
  • OCA (Avatud Laengu Liit)Organisatsioon, mis keelt kirjutab.
  • ISO 15118Auto ja laadija vaheline protokoll.
  • PnC (ühenda ja laadi)Kasutajakogemus, mille on võimaldanud ISO 15118 ja OCPP 2.0.1.
  • V2G (sõidukilt võrku)Auto energia tagasi elektrivõrku saatmine.
  • V2X (sõidukilt kõigele)V2G, V2H ja V2B üldmõiste.
  • TLS (transpordikihi turvalisus)Krüptimine, mis hoiab andmeid turvaliselt.
  • PKI (avaliku võtme infrastruktuur)Turvalisuse tagamiseks kasutatav digitaalsete sertifikaatide süsteem.
  • JSON (JavaScripti objektitähistus)Sõnumite vorming.
  • WebSocketPüsiv ühendus „toru“, mille kaudu sõnumid liiguvad.
  • Seadme mudelVersioonis 2.0.1 kirjeldatakse riistvara hierarhilisel viisil.
  • KomponentRiistvara osa (nt pistik).
  • MuutujaKomponendi omadus (nt Status).
  • AtribuutMuutuja metaandmed (nt väärtus, muudetavus).
  • Tehingu sündmus: Kõigi seansiandmete ühtne sõnum versioonis 2.0.1.
  • SüdamelöökPerioodiline „Ma olen elus“ signaal.
  • BootNotice„Tere, ma olen siin“ signaal, mis kostab laadija käivitumisel.
  • AndmeülekanneÜldine teade müüjapõhistele laiendustele (kasutage ettevaatlikult!).

Lõppmõtted: mitmeprotokollilise ajastu navigeerimine

Ostja või operaatorina on kõige olulisem järeldus see, et me sisenememitmeprotokolliline ajastuJärgmise 3–5 aasta jooksul eksisteerivad 1,6 J ja 2,0,1 koos. Tasakaal on aga kiiresti nihkumas.

Valides OCPP 2.0.1 juba täna, ei osta te mitte ainult protokolli, vaid ka kindlustust. Te tagate, et teie võrk suudab kohaneda uute autode, uute seaduste ja uute tuluallikatega. 2.0.1 keerukus on edusammude hind – hind, mis tasub end ära parema tööaja, väiksema riski ja parema kliendikogemuse kaudu.

Äripindade laadimissüsteem ei ole enam nišitööstus; see on tulevase transpordisüsteemi selgroog. Ehitage see selgroog võimalikult tugevale alusele: OCPP 2.0.1.


19. peatükk: OCPP 2.0.1 jaoks arendamine: parimad tavad tarkvaraarendajatele

Üleminek 1.6J koodibaasist 2.0.1-le ei ole refaktoreerimine; see on ümberkirjutamine. Arendajad peavad omaks võtma teistsuguse mõttemudeli.

19.1 Asünkroonsuse omaksvõtmine

Kuigi WebSocketid on oma olemuselt asünkroonsed, tähendab 2.0.1 keerukus seda, et üks päring (ntGetBaseReport) võib ressursipiiranguga EVSE-l töötlemine võtta mitu sekundit. CSMS-i arendajad peavad rakendama robustse ajalõpu ja uuesti proovimise loogika, mis arvestab erinevate riistvaratootjate erineva töötlemiskiirusega.

19.2 Tõhus JSON-i parsimine

JSON-i parsimine võib olla protsessorimahukas. EVSE püsivara puhul peaksid arendajad kasutama voogupõhiseid parsereid, selle asemel et kogu koormust RAM-i laadida. See on eriti oluline järgmiste rakenduste jaoks:Teavita sündmustsõnumid, mis võivad ühes kaadris sisaldada sadu muutujate uuendusi.

19.3 Olekumasina haldamine

Versioonis 2.0.1 on tehingu olekumasin jäigem kui versioonis 1.6J. Arendajad peavad üleminekureegleid rangelt järgima.Tehingu sündmusNäiteks ei saa te saataLõppenudsündmus ilma eelnevalt saatmataAlustatudselle konkreetse sündmuse jaokstehingu ID.


20. peatükk: Testimine, valideerimine ja OCPP vastavustestimise tööriist (OCTT)

Koostalitlusvõime on OCPP lubadus, kuid see realiseerub ainult range testimise kaudu.

20.1 OCA sertifitseerimise roll

Open Charge Alliance pakub sertifitseerimisprogrammi. Ostjad peaksid otsima silti „OCPP 2.0.1 Certified”. See sertifikaat tagab, et rakendus on läbinud automatiseeritud testide komplekti, mis hõlmavad kõiki kohustuslikke profiile.

20.2 OCTT kasutamine

OCPP vastavustesti tööriist (OCTT) on testimise kuldstandard. See simuleerib nii CSMS-i kui ka EVSE-d.

  • EVSE tootjatele: Kasutage OCTT-d, et kontrollida, kas teie jaam saab hakkama „õnneliku tee” stsenaariumide ja äärmusjuhtumitega (näiteks võrguühenduse katkestused püsivara värskendamise ajal).
  • CSMS-teenuse pakkujateleKasutage OCTT-d, et tagada oma taustsüsteemi võimekus käsitleda suurt hulka sõnumeid ja 2.0.1 rangeid turvanõudeid.

20.3 Välikatsetused ja interop-festivalid

Lisaks automatiseeritud testimisele korraldab OCA nn „Plugfeste“, kus müüjad toovad oma riist- ja tarkvara reaalsetes stsenaariumides üksteise vastu testimiseks. Seal avastatakse ja lahendatakse kõige peenemad vead – näiteks sertifikaatide ühildumatus või väikesed JSON-vormingu erinevused.


21. peatükk: Sügavvõrdlev tabel: OCPP 2.0.1 enam kui 60 toimingut

Täieliku ülevaate pakkumiseks kategoriseerime versiooni 2.0.1 peamised sõnumid ja võrdleme neid versiooni 1.6J vastetega.

21.1 Ettevalmistus ja seadistamine

2.0.1 Tegevus 1,6 J ekvivalent Funktsioon
BootNotice BootNotice Registreerimine CSMS-is.
GetBaseReport GetConfiguration Hankige seadme täielik konfiguratsioon struktureeritud aruandena.
Muutujate määramine SetConfiguration Muutke konfiguratsiooniväärtusi skeemi valideerimise ja vea korral tagasipööramise abil.
Muutujate hankimine GetConfiguration Loe konfiguratsiooni ja jälgi väärtusi tipitud metaandmetega.
Aruandeandmed (mitte ükski) Saatke CSMS-i perioodilisi andmearuandeid (kasutus, komponentide olek, sündmused).
Lähtesta Lähtesta Taaskäivitage jaam kaugjuhtimise teel, lisades auditeerimisjälgede jaoks põhjuskoodi.

21.2 Tehingute käitlemine

2.0.1 Tegevus 1,6 J ekvivalent Funktsioon
Tehingu sündmus Alusta tehingut / Tehingu peatamine Ühtne, sündmustepõhine tehingute aruandlus koos põhjuskoodide ja vahepealsete värskendustega.
GetTransactionStatus (mitte ükski) Päringu esitamine tehingu praeguse oleku kohta pärast taasühendamist või taaskäivitamist.
Andmeülekanne Andmeülekanne Tarnijapõhised laiendusteated, nüüd skeemi järgi valideeritud.

21.3 Turvalisus ja püsivara haldus

2.0.1 Tegevus 1,6 J ekvivalent Funktsioon
SertifikaatAllkirjastatud (mitte ükski) Paigaldage CSMS-ilt saadud allkirjastatud sertifikaat (TLS, ISO 15118).
Allkirjasertifikaat (mitte ükski) Taotle CSMS-i sertifitseerimisasutuselt uue sertifikaadi allkirjastamist.
GetInstalledCertificateIds (mitte ükski) Loetlege installitud sertifikaadid auditi ja vastavusaruannete jaoks.
Püsivara värskendamine Püsivara värskendamine Planeeritud püsivara värskendus koos olekuteadete ja tagasipööramise signaaliga.

21.4 Mida tabel teie võrgu jaoks tähendab

Tabel teeb ühe asja eksimatuks: OCPP 2.0.1 ei ole 1.6J kosmeetiline ümbernimetus. Uued sõnumiperekonnad – tüüpmuutujad, sündmustepõhised tehingud ja sertifikaatide haldus – on pistikprogrammi "Plug & Charge", nutika laadimise ja regulatiivse aruandluse jaoks vajalikud torustiku elemendid. Laadijale, mis räägib ainult 1.6J-d, saab paigaldada lüüsi, kuid CSMS, mis räägib ainult 1.6J-d, ei suuda pakkuda regulaatorite ja autotootjate üha enam nõutavat turvamudelit. Riistvara hindamisel peaks "2.0.1-valmis" tähendama, et püsivara tarnitakse täna, mitte järgmisel aastal. Ja kuna OCPP 2.0.1 töötab JSON-over-WebSocket'i, mitte 1.6J SOAP-transpordi peal, on sõnumivoogud kergemad ja palju lihtsamini silutavad – praktiline eelis, mida teie IT-meeskond tunneb esimesest päevast alates.

22. peatükk: Kokkuvõte: uuendamise otsuse tegemine

Äriettevõtja jaoks on praktiline juhis selge:

  • Uued juurutused peaksid vaikimisi kasutama OCPP 2.0.1.Turvamudel, sertifikaatide käsitlemine ja ISO 15118 integratsioon on 2026. aasta regulatiivse keskkonna eeltingimused.
  • Olemasolevad 1,6J mootoriga autopargid ei ole hätta jäänud.Hallatavad lüüsid ja kaheprotokollilised CSMS-platvormid täidavad lünga, samal ajal kui te juurutate järk-järgult 2.0.1-natiivset riistvara.
  • Enne usaldamist testi.Kasutage OCTT-sid, plugfeste ja etapiviisilisi juurutusi – koostalitlusvõime on praktikas tõestatud, mitte andmelehelt eeldatud.
  • Nõua kirjalikult rändetee kirjeldust.Laadija müüja peaks avaldama püsivara tegevuskava versioonilt 1.6J versioonile 2.0.1 koos kuupäevade, mitte ebamääraste lubadustega.

Üleskutse tegutsemisele: arutage MIDA Poweriga oma protokollistrateegiat

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.


Postituse aeg: 09.08.2026

Jäta oma sõnum:

Kirjuta oma sõnum siia ja saada see meile